Re: [c-nsp] cisco BRAS operational questions
On Thu, Jan 19, 2012 at 2:54 PM, Patrick Cole wrote: >> For troubleshooting purposes, we find it helpful to be able to use >> tcpdump to capture packets. We do it by mac address and sometimes by >> customer PPP interface. Aside from having a span port on the switch, is >> there any way we could get a feed from the 7201 for this purpose? > > You should be able to do with with the IOS images that have lawful intercept. > I am not sure if there is another way I don't know about. IOS Embedded Packet Capture http://www.cisco.com/en/US/products/ps9913/products_ios_protocol_group_home.html or IP Traffic Export http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gt_rawip.html I've read up on both but haven't implemented either. HTH -- Jon Simola CCNA Security ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] cisco BRAS operational questions
Thu, Jan 19, 2012 at 12:23:53PM -0800, Mike wrote: > Hello, > > I am considering going to a cisco 7201 for PPPoE subscriber > termination, and I am trying to figure out how I would duplicate some > features of my current (linux based) pppoe solution. I use radius and am > certain %85 of what I do is stock-and-trade for the cisco solution, the > devil is in some custom things we've come to depend on. > > * per-customer ip filtering Cisco AVpair attributes ip:inacl or ip:outacl or lcp:interface-config with "ip access-group " > Most customers have a default ip filter which drops all rfc1918 > addresses, invalid source addresses, and prevents direct-to-smtp > connections other than to our mail hosts. A very small subset of > subscribers have a slightly modified filter which permits > smtp-to-anywhere. I want to be able to set this via radius attributes > but have no clue how I'd give any given subscriber one filter list vs > another. The filter rules themselves could certainly be pretty static > and not changing often, I just need to be able to tell the box which set > of rules should apply per customer. > > * captive portal / source routing Radius attribute 104 allows you to specify private routes for a subscriber. Effectively like they're in their own private routing table. Use GRE tunnels and policy route maps to send traffic to your captive portal server and redirect traffic to a web page as required. > Certain customers may need to have different routing than the > default 'to internet' gateway. For example, I have a captive portal > system > that works by returing custom web pages for any request that gets routed to > it, such as if you make this box's ip the 'default gateway' used by a > customer. I would need to be able to tell the cisco to route all packets > from some given customer - either by source ip address or, preferably, > by interface - down to this alternate gateway. > > * diagnostic intercept > > For troubleshooting purposes, we find it helpful to be able to use > tcpdump to capture packets. We do it by mac address and sometimes by > customer PPP interface. Aside from having a span port on the switch, is > there any way we could get a feed from the 7201 for this purpose? You should be able to do with with the IOS images that have lawful intercept. I am not sure if there is another way I don't know about. Patrick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] cisco BRAS operational questions
Hello, I am considering going to a cisco 7201 for PPPoE subscriber termination, and I am trying to figure out how I would duplicate some features of my current (linux based) pppoe solution. I use radius and am certain %85 of what I do is stock-and-trade for the cisco solution, the devil is in some custom things we've come to depend on. * per-customer ip filtering Most customers have a default ip filter which drops all rfc1918 addresses, invalid source addresses, and prevents direct-to-smtp connections other than to our mail hosts. A very small subset of subscribers have a slightly modified filter which permits smtp-to-anywhere. I want to be able to set this via radius attributes but have no clue how I'd give any given subscriber one filter list vs another. The filter rules themselves could certainly be pretty static and not changing often, I just need to be able to tell the box which set of rules should apply per customer. * captive portal / source routing Certain customers may need to have different routing than the default 'to internet' gateway. For example, I have a captive portal system that works by returing custom web pages for any request that gets routed to it, such as if you make this box's ip the 'default gateway' used by a customer. I would need to be able to tell the cisco to route all packets from some given customer - either by source ip address or, preferably, by interface - down to this alternate gateway. * diagnostic intercept For troubleshooting purposes, we find it helpful to be able to use tcpdump to capture packets. We do it by mac address and sometimes by customer PPP interface. Aside from having a span port on the switch, is there any way we could get a feed from the 7201 for this purpose? Thanks all. Mike- ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Bridging multiple inner VLAN's
Hi, On 20 January 2012 00:41, Brian Christopher Raaen wrote: > You mentioned an ASR9k. I'm pretty sure that you can do the requested > task, based on my testing with bridging on an ASR. What was it that > didn't work for you with the ASR? In our particular case we don't know the exact mappings (mappings are done by an external service provider), so can't create subinterfaces (EFPs) with the right tag impositions. In those circumstances ASR9k can not remove vlan tags on ingress and then for the return traffic impose them back onto the packet, as they are not stored in any map (only the MAC addresses are). If you know your vlans then there is no problem - you just need to configure them and make sure that the mac addresses remain unique across vlans. kind regards Pshem ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] VRF import default route from global routing table on the Same PE with internet and NNI to a provider
I am trying to figure a way to import a default route from the global routing table into a customer's VRF to provide internet access. This customer's site is on another's provider network that we interconnect with using a NNI and option b. Our PE has MPLS L3 VPNs, NNI Link to a provider, and full internet routes. So here is the layout Cust---Provider1---NNI_LINKPEInternet So I see three ways of doing this. 1. Configuring a Internet gateway and attach it off the PE using vlans Cust-Provider--NNI_LINK---PE---dot1qtrunk--InternetGateway--PE--Internet PE G0/0 Vlan10 vrf CUST ip addr 10.1.1.2/30 Ineternetgateway G0/0 vlan 10 No vrf Ip addr 10.1.1.1/30 Internetgateway G0/1 Ip addr 2.2.2.2/30 PE G0/1 IP addr 2.2.2.1/30 2. I know the global commands won't work because that requires a dedicated "Internet Gateway Router" and the route back to the customer's CE won't work because of the NNI Link and the customer is not directly attached to our PE 3. Loopback Cable on the PE one side in the vrf and the other in the internet routing table. G0/0.10 MPLS VRF Interface Vlan 10 Vrf cust Ip addr 10.1.1.2/30 G0/1.10 Internet Routing Vlan 10 Ip addr 10.1.1.1/30 If there is another way to do this let me know. Thanks in advance. Erik CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR 1006 //
It is not clear what you are trying to do. Are you using the dedicated VRF port (Management Ethernet interface) or simply trying to use the VTYs with a standard configuration? My understanding is the VRF for the Management Ethernet Interface is fixed and cannot be changed. LR Mack McBride Network Architect -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of omar parihuana Sent: Thursday, January 19, 2012 10:00 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ASR 1006 // Hi guys, I'm disappointed with ASR 1k6, i tried to configure a management interface but this interface belong to vrf-management... I have two RP and I would like to configure a only virtual interface in order to tie both RP management interface (like ASR9K or CRS-1)... is it possible that configuration other question: is it possible to change the vrf for management Interface... Rgds. -- Omar E.P.T - Certified Networking Professionals make better Connections! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] ASR 1006 //
Hi guys, I'm disappointed with ASR 1k6, i tried to configure a management interface but this interface belong to vrf-management... I have two RP and I would like to configure a only virtual interface in order to tie both RP management interface (like ASR9K or CRS-1)... is it possible that configuration other question: is it possible to change the vrf for management Interface... Rgds. -- Omar E.P.T - Certified Networking Professionals make better Connections! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] vss upgrade failiure
Hi all. I was trying to upgrade a running 6500-vss envoriment from s72033-adventerprise_wan-mz.122-33.SXI3.bin to s72033-adventerprisek9_wan-mz.122-33.SXI5.bin. I loaded the software to both sup-bootdisk on master and slave. Updated the bootvar.: BOOT variable = sup-bootdisk:s72033-adventerprisek9_wan-mz.122-33.SXI5.bin,12;sup-bootdisk:s72033-adventerprise_wan-mz.122-33.SXI3.bin,1; CONFIG_FILE variable does not exist BOOTLDR variable does not exist Configuration register is 0x2102 Standby is up Standby has 1048576K/65536K bytes of memory. Standby BOOT variable = sup-bootdisk:s72033-adventerprisek9_wan-mz.122-33.SXI5.bin,12;sup-bootdisk:s72033-adventerprise_wan-mz.122-33.SXI3.bin,1; Standby CONFIG_FILE variable does not exist Standby BOOTLDR variable does not exist Standby Configuration register is 0x2102 After this I reloaded the peer. The peer came up and I could see the vss was running, but the linecards on the peer never showed up. The never came online. The linecard is a WS-X6708-10GE and a WS-X6724-SFP. The 2 sup's is VS-S720-10G with MSFC3 Has anyone seen this before ?? I been trying to find a bug, that could refer to this with out any luck. /Arne ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 7200 -> 6503
Hi, On Thu, Jan 19, 2012 at 04:59:58PM +1100, John Elliot wrote: > The 6500's and 7600's look pretty similar(7600 supports more WAN cards?) It's the same hardware, except that the 7600 comes from a different business unit that likes to annoy customers. For more details, check the c-nsp archives. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpYvjojcBPTq.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Ambiguous ACL "log" in 12.2(58)SE2?
Jeff, Dne 18.1.2012 22:46, Jeff Kell napsal(a): Hrmm... looks like this release is attempting to take multiple services: Grote-Uplink(config-ext-nacl)#101 permit tcp any host 192.168.128.74 eq smtp syslog ftp That was *accepted*. So a trailing "log" on a "tcp" permit is ambiguous with "login" (rlogin/513), and it's impossible to make it unambiguous (apparently). What's going on here? TCP ACLs on existing switches with trailing "log" are having those statements removed at startup and causing a bit of havoc... Anyone else seeing this? Running c3560e-universalk9-mz.122-58.SE2.bin on a WS-C3560X-24T-S with an IP services license. I just tried this on one of our 2960's running 12.2(58)SE1 and it's impacted as well. 2960, 12.2(58)SE1 switchX(config-ext-nacl)#permit tcp any any eq 80 log % Ambiguous command: "permit tcp any any eq 80 log" Version 15.0(1)SE is affected by this too. 2960S, 15.0(1)SE switchY(config-ext-nacl)#permit tcp any any eq 80 log % Ambiguous command: "permit tcp any any eq 80 log" Last version which can handle 'log' append on 2960 I have found is 12.2(55)SE2 Jiri Jeff On 1/18/2012 10:14 AM, Jeff Kell wrote: Running into this on a 3560X IP Services (context is accepted by everything else...) Grote-Uplink(config-ext-nacl)#85 permit tcp any any eq 9100 log % Ambiguous command: "85 permit tcp any any eq 9100 log" Grote-Uplink(config-ext-nacl)#85 permit tcp any any eq 9100 log ! log % Ambiguous command: "85 permit tcp any any eq 9100 log ! log" Grote-Uplink(config-ext-nacl)#85 permit tcp any any eq 9100 log % Ambiguous command: "85 permit tcp any any eq 9100 log " Grote-Uplink(config-ext-nacl)# What's up with that? Jeff ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Bridging multiple inner VLAN's
You mentioned an ASR9k. I'm pretty sure that you can do the requested
task, based on my testing with bridging on an ASR. What was it that
didn't work for you with the ASR?
Brian Raaen
Network Architect
Zcorum
On Wed, Jan 18, 2012 at 7:08 PM, Pshem Kowalczyk wrote:
> Hi,
>
> On 19 January 2012 12:43, Dave Weis wrote:
>
> {cut}
>
>>>I'm not entirely sure if I understand you correctly, but if you strip
>>>the inner vlan on the ingress how would you know what inner vlan to
>>>assign to all egress packets that should go towards that internal tag
>>>of 54? For that to work the device that does the operation would have
>>>to remember not only the MAC address but also the inner vlan from the
>>>ingress packets.
>>>We solved this by making the BRAS interpret double tags and that
>>>worked well for us.
>>
>> That's a great question, I would suppose it has to keep a table of MAC to
>> inner tag as they are stripped.
>
> We looked at doing that on ASR9k and it turned out that the vlans are
> never stored. Perhaps ME switches offer more in that space.
>
>> Are you using PPPoE on your BRAS? This is for a legacy setup with 1000+
>> bridged modems at the far end.
>
> Yes, we are. The frames come double-tagged (as in your case) and the
> BRAS keeps track of all the tags (we use Huawei ME60 as the BRAS, but
> I suspect this is quite standard feature), that allows us to simply
> carry the traffic across our network in a VPLS.
>
> kind regards
> Pshem
> ___
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] getting a current mib from cisco
On 1/18/12, Justin M. Streiner wrote: > On Wed, 18 Jan 2012, Lee wrote: > >> What's the trick for getting a current MIB from Cisco? > > Is this a case of not being to find the right/most up-to-date MIB file, or > is this a case of the right/most up-to-date MIB file not matching the > version of code you're running? It's a case of the most up to date MIB needs to be updated. The comments in the mib say it was last updated in 2004: REVISION "20041228Z" DESCRIPTION "Updated 'CiscoOptionalFeature' TC for the 'extendedCredit' feature. " TAC did get me an updated mib but it's still missing some values and the updated mib hasn't made it into v2.tar.gz yet. > I normally download what I need from ftp://ftp.cisco.com/pub/mibs/ I downloaded http://download-sj.cisco.com/pub/mibs/v2/v2.tar.gz and extracted the files I needed from that. I just tried ftp://ftp.cisco.com/pub/mibs/v2/v2.tar.gz & it's got the same problem. CiscoOptionalFeature in CISCO-FEATURE-CONTROL-MIB.my defines values 1-19 and a nexus 4000 returns values larger than 19 >> Do I give up and close the case when I get enough >> info out of Cisco to solve my immediate problem or do I hold out until >> there's a new CISCO-FEATURE-CONTROL-MIB.my released on cisco.com & the >> issue is resolved for everyone? > > If you're not getting a satisfactory response from the TAC, don't hesitate > to take it up with your account manager/account team and then they can try > to get you some answers internally. They have tried. Apparently they don't have any more leverage with the DE than TAC does. Lee ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] macsec on 6500 linecards
On 01/19/2012 07:47 AM, selamat pagi wrote: Hi, Looking for a list with linecards which do support mac-sec. I am particularly interessted in WS-X6824-SFP-2T MACSEC is only available on 6900 series linecards. A (largely useless, IMO) subset of TrustSec is supported on 6800 series linecards (or 6700s upgraded with a DFC4; same thing basically) See: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-658388.html ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
