Re: [c-nsp] CoPP Hardware Counters on RSP720/7600
Hello, with CoPP enabled and flood ping to the RSP720 I don't have higher CPU utilization than is normal on my box. Without CoPP and ICMP flood (ping -f -s 1400) the CPU util goes to 90% - 99%. CPU utilization for five seconds: 96%/21%; one minute: 44%; five minutes: 20% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 19423910192 426932747 56 46.38% 20.81% 5.12% 0 IP Input The CPU utilization with CoPP enabled is depend on what rate you doing policing for particular class, e.g. how many ICMP packet you are conforming to the RSP. Regards, David On 9/22/08, Sebastian Wiesinger [EMAIL PROTECTED] wrote: * Ozgur Guler [EMAIL PROTECTED] [2008-09-22 14:31]: Hi Sebastian, Have you confirmed that mls qos is enabled globally? CoPP needs mls qos in order to work in HW. Yes, mls qos is enabled. I tried doing a flood-ping with hping3 and have around 30-40% of CPU usage. This seems a little bit high, but I heard from others that without CoPP the session to the RSP720 would just freeze. With my CoPP enabled I was able to work without delay on the RSP720. I couldn't test the situation without CoPP but I hope I can do so tonight. Regards, Sebastian -- GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ 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] X2 and WAN PHY
Hi list According to http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/installation/note/78_16705.html the X2 family is missing DWDM transceivers and WAN PHY transceivers. Does someone know if/when WAN PHY will be available in X2 formfactor? Or is there a third party that works in the 6708 module?+ //MKS ___ 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] vs wism modules
Hi Folks. Does anyone know if there is a whitepaper available that describes exactly what wism module does and work regarding packet flows tunnel setups and so on. What impact has it on a cat6500's performance. /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] X2 and WAN PHY
The only X2 DWDM optics I have seen are: http://www.ghipsystems.com/en/Products/X2-en/X2-en.html Website says: *X2 Modules for 10G-Ethernet, 10G-Fibre Channel, and OC192/STM-64* so I assume they will work for WAN PHY. (I have no experience with these, just found them when googling.) Tim: On Tue, Sep 23, 2008 at 4:02 AM, MKS [EMAIL PROTECTED] wrote: Hi list According to http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/installation/note/78_16705.html the X2 family is missing DWDM transceivers and WAN PHY transceivers. Does someone know if/when WAN PHY will be available in X2 formfactor? Or is there a third party that works in the 6708 module?+ //MKS ___ 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] Debugging Cisco VPN Client Software ... Is it even possible ?
Hi all, From the _client_ perspective can anyone recommend any tools/techniques to debug Cisco VPN client problems ? (they drive me mad). These are mostly Windows based clients connecting to a cisco vpn concentrator. I tend to trawl through event logs and client vpn logs and really have no real success with debugging. The VPN client really feels like a black box :( Any hot tips with how to debug VPN clients not being able to connect into a vpn concentrator (from the _client_ perspective) ? Thanks! -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ 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] Conditional BGP
Hi folks.. We have a couple of customers that are looking to purchase an Internet connection from us - this will be a BGP feed to each customer as they are multihomed today etc. Normally, we would just supply a full table and let them decide what to do with it. In this scenario, they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. Thanks for your input. Paul ___ 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] Conditional BGP
On Tuesday 23 September 2008 08:37:56 Paul Stewart wrote: Hi folks.. We have a couple of customers that are looking to purchase an Internet connection from us - this will be a BGP feed to each customer as they are multihomed today etc. Normally, we would just supply a full table and let them decide what to do with it. In this scenario, they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. Thanks for your input. Paul Paul, Most providers offer three options: full routes, partial (customer) routes, and default route only. Allowing the customer to select from these options allows them to choose the option that they can best support. To implement these options, you can create as-path access list and prefix list templates and apply them outbound as needed. Stephen Kratzer Network Engineer CTI Networks, Inc. ___ 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] debugging all incoming traffic on an interface
Have you tried using debug ip packet or debug packet with debug condition interface? --- On Mon, 22/9/08, Jason Lixfeld [EMAIL PROTECTED] wrote: From: Jason Lixfeld [EMAIL PROTECTED] Subject: [c-nsp] debugging all incoming traffic on an interface To: cisco-nsp@puck.nether.net Date: Monday, 22 September, 2008, 11:52 PM I'm trying to give a local ILEC an idea on where to look to troubleshoot an issue on a bridged DSL circuit. It terminates directly onto a WIC-1ADSL interface in a 2651 on the one side and a VLAN on the other side. Can't pass traffic over it, but the inbound packet counters are incrementing on the 2651 side, however I have no idea what kind of traffic is actually hitting the interface, nor do I know what the source or destination of the traffic is. My question in all of this is what's the best way to see all the traffic coming into this interface? Attaching a access-list 100 permit ip any any log-input to the interface and/or subinterface via ip access-group didn't show anything - the interface counters incremented while the access-list counter didn't. I can't debug the ATM (sub)interface, nor can I configure a SPAN port on an ATM (sub)interface. Anyone know how I might go about this? I suppose in a worst case scenario, I could hook up a DSL modem to the line and plug that into a wireshark box, but I'm hoping there's a more localized solution. Thanks in advance.___ 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] Conditional BGP
On Tuesday 23 September 2008 08:37:56 Paul Stewart wrote: Hi folks.. We have a couple of customers that are looking to purchase an Internet connection from us - this will be a BGP feed to each customer as they are multihomed today etc. Normally, we would just supply a full table and let them decide what to do with it. In this scenario, they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. Thanks for your input. Paul Forgot to mention that they'll still need to set local pref to always prefer the primary provider. Stephen Kratzer Network Engineer CTI Networks, Inc. ___ 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] debugging all incoming traffic on an interface
0n Mon, Sep 22, 2008 at 06:52:21PM -0400, Jason Lixfeld wrote: Attaching a access-list 100 permit ip any any log-input to the interface and/or subinterface via ip access-group didn't show anything - the interface counters Curious ... since I dont have the luxury to play with cisco kit all day (jack of trades ...) can someone please give me a quick explanation as to how creating an ACL on an interface helps with debugging that interface ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ 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] Conditional BGP
Thank you ... so really the best solution for us to offer is what we already do - full table. Also, since we support a full list of communities the customer has complete control over when/where they get advertised. Or a simple approach for the customers would be heavy prepending and low local-pref (which would keep the traffic down but not zero due to our peering etc). Thanks very much, Paul -Original Message- From: Stephen Kratzer [mailto:[EMAIL PROTECTED] Sent: September 23, 2008 9:00 AM To: cisco-nsp@puck.nether.net Cc: Paul Stewart Subject: Re: [c-nsp] Conditional BGP On Tuesday 23 September 2008 08:37:56 Paul Stewart wrote: Hi folks.. We have a couple of customers that are looking to purchase an Internet connection from us - this will be a BGP feed to each customer as they are multihomed today etc. Normally, we would just supply a full table and let them decide what to do with it. In this scenario, they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. Thanks for your input. Paul Paul, Most providers offer three options: full routes, partial (customer) routes, and default route only. Allowing the customer to select from these options allows them to choose the option that they can best support. To implement these options, you can create as-path access list and prefix list templates and apply them outbound as needed. Stephen Kratzer Network Engineer CTI Networks, Inc. ___ 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] Conditional BGP
Paul, They would need to do two things. 1) AS prepend on the routes they advertise to you, so the AS path is longer than their path through Cogent. This will force most of their inbound traffic via Cogent. 2) Local pref setting for routes received from you to make them less desirable than the routes from Cogent. The default is 100, so they could set your routes to 90 or something. Both of these are set using a route-map on their side. I'm assuming that there isn't anything they would want to prefer to route through you (your peers/customers - Or if Level3 or someone de-peers Cogent again), but that can be tweaked with route-maps and prefix-list filters. David Paul Stewart wrote: Hi folks.. We have a couple of customers that are looking to purchase an Internet connection from us - this will be a BGP feed to each customer as they are multihomed today etc. Normally, we would just supply a full table and let them decide what to do with it. In this scenario, they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. Thanks for your input. Paul ___ 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] debugging all incoming traffic on an interface
On Tue, Sep 23, 2008, Wilkinson, Alex wrote: 0n Mon, Sep 22, 2008 at 06:52:21PM -0400, Jason Lixfeld wrote: Attaching a access-list 100 permit ip any any log-input to the interface and/or subinterface via ip access-group didn't show anything - the interface counters Curious ... since I dont have the luxury to play with cisco kit all day (jack of trades ...) can someone please give me a quick explanation as to how creating an ACL on an interface helps with debugging that interface ? Assuming your platform is compatible, it'll log stuff in the logging area. Just sure you've got a larger logging buffer and its set to debug (I think?) so it captures all of your packets. Adrian ___ 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] SIP-600
If I have a SIP-600 in a 7600 and SPA 1 port 10GbE. Lets say I have 5 gig of traffic on the 10 gig card, can I also have a 5 port GeE and thus oversubscribe the SIP-600? or will the 5 port card be disabled? Thanks //MKS ___ 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] debugging all incoming traffic on an interface
On Tue, September 23, 2008 2:07 pm, Wilkinson, Alex wrote: Curious ... since I dont have the luxury to play with cisco kit all day (jack of trades ...) can someone please give me a quick explanation as to how creating an ACL on an interface helps with debugging that interface ? access-list 100 permit ip any any log Will dump everything to the log. Eventually. Don't try this on busy interfaces, kids! :) Seriously, it's useful if you don't seem to be sending or receiving anything at all, or for proving which side of a device the problem lies, for example an ACL both inbound and outbound: permit icmp any any log permit ip any any on a customer-facing interface, then pinging into the customer's network from the other side of your own network can show that routing is working, that packets traverse your network into the customer's network, but that nothing comes back from the customer. Regards, Tim. ___ 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] Conditional BGP
On Tue, 23 Sep 2008, Paul Stewart wrote: We have a couple of customers that are looking to purchase an Internet connection from us - this will be a BGP feed to each customer as they are multihomed today etc. Normally, we would just supply a full table and let them decide what to do with it. In this scenario, they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. I wouldn't call this conditional BGP. We have a few customers doing this, and in most cases they do this because they don't have big enough routers to handle multiple full bgp tables. The typical setup is to use route-maps to set localpref on received routes (making the primary provider's route(s) preferred) and on sent routes to do several prepends to make the backup path less preferable to the internet. In such a setup, the customer probably doesn't need more than default routes from each provider. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] Conditional BGP
Hi, My choice : Inject them a default route ask them to prepend their prefixes to you rgs a. rahman isnaini rangkayo sutan Paul Stewart wrote: Hi folks.. We have a couple of customers that are looking to purchase an Internet connection from us - this will be a BGP feed to each customer as they are multihomed today etc. Normally, we would just supply a full table and let them decide what to do with it. In this scenario, they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. Thanks for your input. Paul ___ 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] Conditional BGP
If you want to only give them a default, they could use static object tracking to override your default with their own provider. If that provider drops, the static that's tracked (with an AD lower than BGP) will go away, and your default would now be used. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Stewart Sent: Tuesday, September 23, 2008 9:13 AM To: [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Conditional BGP Thank you ... so really the best solution for us to offer is what we already do - full table. Also, since we support a full list of communities the customer has complete control over when/where they get advertised. Or a simple approach for the customers would be heavy prepending and low local-pref (which would keep the traffic down but not zero due to our peering etc). Thanks very much, Paul -Original Message- From: Stephen Kratzer [mailto:[EMAIL PROTECTED] Sent: September 23, 2008 9:00 AM To: cisco-nsp@puck.nether.net Cc: Paul Stewart Subject: Re: [c-nsp] Conditional BGP On Tuesday 23 September 2008 08:37:56 Paul Stewart wrote: Hi folks.. We have a couple of customers that are looking to purchase an Internet connection from us - this will be a BGP feed to each customer as they are multihomed today etc. Normally, we would just supply a full table and let them decide what to do with it. In this scenario, they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. Thanks for your input. Paul Paul, Most providers offer three options: full routes, partial (customer) routes, and default route only. Allowing the customer to select from these options allows them to choose the option that they can best support. To implement these options, you can create as-path access list and prefix list templates and apply them outbound as needed. Stephen Kratzer Network Engineer CTI Networks, Inc. ___ 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] Conditional BGP
IMHO, it's best to offer three options to the customer, full routes, partial routes, or a default route only. That is, say Here are three possible configurations, which one do you want? On Tuesday 23 September 2008 09:13:25 Paul Stewart wrote: Thank you ... so really the best solution for us to offer is what we already do - full table. Also, since we support a full list of communities the customer has complete control over when/where they get advertised. Or a simple approach for the customers would be heavy prepending and low local-pref (which would keep the traffic down but not zero due to our peering etc). Thanks very much, Paul -Original Message- From: Stephen Kratzer [mailto:[EMAIL PROTECTED] Sent: September 23, 2008 9:00 AM To: cisco-nsp@puck.nether.net Cc: Paul Stewart Subject: Re: [c-nsp] Conditional BGP On Tuesday 23 September 2008 08:37:56 Paul Stewart wrote: Hi folks.. We have a couple of customers that are looking to purchase an Internet connection from us - this will be a BGP feed to each customer as they are multihomed today etc. Normally, we would just supply a full table and let them decide what to do with it. In this scenario, they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. Thanks for your input. Paul Paul, Most providers offer three options: full routes, partial (customer) routes, and default route only. Allowing the customer to select from these options allows them to choose the option that they can best support. To implement these options, you can create as-path access list and prefix list templates and apply them outbound as needed. Stephen Kratzer Network Engineer CTI Networks, Inc. ___ 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] c4000
On Monday 22 September 2008 18:59:02 adrian kok wrote: Hi all ls any different to setup vlan between catalyst 4000 and 2960? I need to setup the cisco2800 to have vlan this 4000 switch ls it easy? how setup the trunk port in 4000 switch? I still have CatOS switches in my LAN; they work, work well, and there's no need to upgrade what isn't broken. It IS a different interface, though. The two best books I have on the subject are Kennedy Clark's Cisco LAN Switching (which is old enough to still deal with the older Catalysts) and Cisco Field Manual: Catalyst Switch Configuration. I personally, for VLAN and trunking 'things' find the CatOS interface more intuitive and more powerful than the IOS interface; and I have switches with both, incidentally. Although none of my IOS switches have interface range capabilities; when dealing with lots of ports, the CatOS port ranging capability is very handy, and less error-prone in typing (repetitive typing of bridge-group or switchport commands is both a drag and an error center). In my LAN, I have all switches set to VTP transparent mode, and I've not yet needed to prune VLANs from trunks, so my setup is fairly simple. In that environment, setting up trunks is very simple. The only thing you need to think hard about is getting the native VLAN right. All my trunks are 802.1Q, so take the following config snippets in that context: [snip] #vtp set vtp mode transparent set vlan 1 name default type ethernet mtu 1500 said 11 state active set vlan 101 name erc-10-250-130-link type ethernet mtu 1500 said 100101 state active set vlan 103 name smiley type ethernet mtu 1500 said 100103 state active set vlan 105 name erc-72 type ethernet mtu 1500 said 100105 state active set vlan 192 name old-internal type ethernet mtu 1500 said 100192 state active set vlan 201 name 12012-uplink type ethernet mtu 1500 said 100201 state active [snip] #standby ports set standbyports enable [snip] #module 1 : 2-port 1000BaseX Supervisor IIIG set vlan 192 1/2 set vlan 201 1/1 set trunk 1/2 on dot1q 1-1005 ! #module 2 : 2-port 1000BaseX Supervisor IIIG set vlan 192 2/1-2 set trunk 2/2 on dot1q 1-1005 ! #module 3 : 3-port 1000BaseX Ethernet set vlan 192 3/1-3 set trunk 3/1 on dot1q 1-1005 set trunk 3/2 on dot1q 1-1005 set trunk 3/3 on dot1q 1-1005 ! [snip] Hope that helps. Like I said, my setup is fairly simple, and vlan pruning on trunks has not yet become an issue, so none are pruned currently. Your mileage may vary; your setup may be complex enough to think carefully about what vlans propagate over which trunks. -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 http://www.pari.edu ___ 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] Conditional BGP
they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. I'm currently doing this with Cogent and another provider. I get default routes from both and simply prepend my AS a few times on the backup connection. In your situation this would mean that all of the config is on the customer side. e.g.: router bgp ... neighbor backup route-map prepend_outbound out neighbor x.x.x.x peer-group backup ... route-map prepend_outbound permit 10 set as-path prepend James Paul Stewart wrote: Hi folks.. We have a couple of customers that are looking to purchase an Internet connection from us - this will be a BGP feed to each customer as they are multihomed today etc. Normally, we would just supply a full table and let them decide what to do with it. In this scenario, they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. Thanks for your input. Paul ___ 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] debugging all incoming traffic on an interface
I have. There are no interface conditions on either of those debug [ip] packet commands. Also, debug interface doesn't allow me the option of my ATM interface(s). On 23-Sep-08, at 9:03 AM, Ozgur Guler wrote: Have you tried using debug ip packet or debug packet with debug condition interface? --- On Mon, 22/9/08, Jason Lixfeld [EMAIL PROTECTED] wrote: From: Jason Lixfeld [EMAIL PROTECTED] Subject: [c-nsp] debugging all incoming traffic on an interface To: cisco-nsp@puck.nether.net Date: Monday, 22 September, 2008, 11:52 PM I'm trying to give a local ILEC an idea on where to look to troubleshoot an issue on a bridged DSL circuit. It terminates directly onto a WIC-1ADSL interface in a 2651 on the one side and a VLAN on the other side. Can't pass traffic over it, but the inbound packet counters are incrementing on the 2651 side, however I have no idea what kind of traffic is actually hitting the interface, nor do I know what the source or destination of the traffic is. My question in all of this is what's the best way to see all the traffic coming into this interface? Attaching a access-list 100 permit ip any any log-input to the interface and/or subinterface via ip access-group didn't show anything - the interface counters incremented while the access-list counter didn't. I can't debug the ATM (sub)interface, nor can I configure a SPAN port on an ATM (sub)interface. Anyone know how I might go about this? I suppose in a worst case scenario, I could hook up a DSL modem to the line and plug that into a wireshark box, but I'm hoping there's a more localized solution. Thanks in advance. ___ 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] Debugging Cisco VPN Client Software ... Is it even possible ?
Usually I find that client VPN log along with Concentrator log are enough. You could try to use Wireshark on the client machine for more detail information. Luan - Luan Nguyen Chesapeake NetCraftsmen, LLC. www.NetCraftsmen.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilkinson, Alex Sent: Tuesday, September 23, 2008 8:27 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Debugging Cisco VPN Client Software ... Is it even possible ? Hi all, From the _client_ perspective can anyone recommend any tools/techniques to debug Cisco VPN client problems ? (they drive me mad). These are mostly Windows based clients connecting to a cisco vpn concentrator. I tend to trawl through event logs and client vpn logs and really have no real success with debugging. The VPN client really feels like a black box :( Any hot tips with how to debug VPN clients not being able to connect into a vpn concentrator (from the _client_ perspective) ? Thanks! -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ 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] Conditional BGP
My choice would be full routing tables from both ISP's, the customer to change his local pref on the backup link. if done correctly his own address space will not be advertised to the backup ISP as it would be advertised from the the backup ISP to the client. When the primary link fails the backup BGP link would see its own prefix's disappear and start advertising its own prefix's out the backup link with a 60 sec delay of course. Thus avoiding problems with private peering arrangements, where asymetric routing happens. Good luck have fun Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of a. rahman isnaini r.sutan Sent: 23 September 2008 14:19 To: Paul Stewart Cc: 'cisco-nsp' Subject: Re: [c-nsp] Conditional BGP Hi, My choice : Inject them a default route ask them to prepend their prefixes to you rgs a. rahman isnaini rangkayo sutan Paul Stewart wrote: Hi folks.. We have a couple of customers that are looking to purchase an Internet connection from us - this will be a BGP feed to each customer as they are multihomed today etc. Normally, we would just supply a full table and let them decide what to do with it. In this scenario, they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. Thanks for your input. Paul ___ 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/ ___ 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] Conditional BGP
Thanks to everyone for all the replies both offlist and onlist... quite a few of them! ;) Anyways, we're going to offer all three options to these customers - I want to put the control in their court which as Stephen and others have suggested. Then the responsibility is on the customer which route they prefer (sorry, bad pun). Currently these customers are both getting full tables and could handle an additional table with no issues at all. Appreciate the feedback from everyone.. Paul -Original Message- From: Church, Charles [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 9:19 AM To: Paul Stewart; cisco-nsp Subject: RE: [c-nsp] Conditional BGP Wouldn't having them prepend their AS enough times for prefixes towards you and a low local preference for routes from you (on their end) solve this? That way all the configuration is on their end. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Stewart Sent: Tuesday, September 23, 2008 8:38 AM To: 'cisco-nsp' Subject: [c-nsp] Conditional BGP Hi folks.. We have a couple of customers that are looking to purchase an Internet connection from us - this will be a BGP feed to each customer as they are multihomed today etc. Normally, we would just supply a full table and let them decide what to do with it. In this scenario, they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. Thanks for your input. Paul ___ 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] Kevin White is out of the office.
I will be out of the office starting 23/09/2008 and will not return until 02/10/2008. Please contact Marcus Burbidge x2510 or Peter Smith x6501 for any urgent issues ** This transmission is confidential and must not be used or disclosed by anyone other than the intended recipient. Neither Tata Steel UK Limited nor any of its subsidiaries can accept any responsibility for any use or misuse of the transmission by anyone. For address and company registration details of certain entities within the Corus group of companies, please visit http://www.corusgroup.com/entities ** ___ 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] Conditional BGP
On Tue, Sep 23, 2008 at 09:23:16AM -0500, James Slepicka wrote: they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. I'm currently doing this with Cogent and another provider. I get default routes from both and simply prepend my AS a few times on the backup connection. In your situation this would mean that all of the config is on the customer side. e.g.: router bgp ... neighbor backup route-map prepend_outbound out neighbor x.x.x.x peer-group backup ... route-map prepend_outbound permit 10 set as-path prepend avoid manual peer-groups.. templates using 'inherit peer-(session|policy)' are more flexible and easier to change later. if your neighbors have the same outbound policy, they'll get stuffed into the same update group w/o the peer-group. and to answer the OP question: this is a question of local policy for the customer. give them lots of options. let them use weight (and/or localpref, if they have multiple routers in the AS) to determine egress. give them communities if that will help their route selection decision making. i wouldn't go much further than the previous suggestions of 'full routes', 'customer routes', 'default origination' unless $customer is paying you to rig something up or you're feeling particularly nice. finally, 'down' can mean a lot of things and your customer needs to figure out if that means 'interface loss', 'loss across cogent' (frequent occurrence), 'latency spike', etc. in IOS, using IP SLA and a track object is probably the best way to implement those checks. -- bill ___ 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] Conditional BGP
Thanks Bill... finally, 'down' can mean a lot of things and your customer needs to figure out if that means 'interface loss', 'loss across cogent' (frequent occurrence), 'latency spike', etc. in IOS, using IP SLA and a track object is probably the best way to implement those checks This is a very good point - there's a good reason they need backup when using a Cogent feed ;) Sorry, couldn't resist saying that... their viewpoint will be loss across cogent I'm sure... I believe they will want a full feed and just look after it all - or we can offer them a managed customer prem router solution and take care of it for them Take care, Paul -Original Message- From: bill fumerola [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 12:26 PM To: James Slepicka Cc: Paul Stewart; 'cisco-nsp' Subject: Re: [c-nsp] Conditional BGP On Tue, Sep 23, 2008 at 09:23:16AM -0500, James Slepicka wrote: they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. I'm currently doing this with Cogent and another provider. I get default routes from both and simply prepend my AS a few times on the backup connection. In your situation this would mean that all of the config is on the customer side. e.g.: router bgp ... neighbor backup route-map prepend_outbound out neighbor x.x.x.x peer-group backup ... route-map prepend_outbound permit 10 set as-path prepend avoid manual peer-groups.. templates using 'inherit peer-(session|policy)' are more flexible and easier to change later. if your neighbors have the same outbound policy, they'll get stuffed into the same update group w/o the peer-group. and to answer the OP question: this is a question of local policy for the customer. give them lots of options. let them use weight (and/or localpref, if they have multiple routers in the AS) to determine egress. give them communities if that will help their route selection decision making. i wouldn't go much further than the previous suggestions of 'full routes', 'customer routes', 'default origination' unless $customer is paying you to rig something up or you're feeling particularly nice. finally, 'down' can mean a lot of things and your customer needs to figure out if that means 'interface loss', 'loss across cogent' (frequent occurrence), 'latency spike', etc. in IOS, using IP SLA and a track object is probably the best way to implement those checks. -- bill ___ 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] Debugging Cisco VPN Client Software ... Is it even possible ?
what kinda issues are you having ?i've rarely found a problem that required debugging and all... regards, On Tue, 2008-09-23 at 20:27 +0800, Wilkinson, Alex wrote: Hi all, From the _client_ perspective can anyone recommend any tools/techniques to debug Cisco VPN client problems ? (they drive me mad). These are mostly Windows based clients connecting to a cisco vpn concentrator. I tend to trawl through event logs and client vpn logs and really have no real success with debugging. The VPN client really feels like a black box :( Any hot tips with how to debug VPN clients not being able to connect into a vpn concentrator (from the _client_ perspective) ? Thanks! -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ 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/ Please note: This email and its content are subject to the disclaimer as displayed at the following link http://www.is.co.za/legal/E-mail+Confidentiality+Notice+and+Disclaimer.htm. Should you not have Web access, send a mail to [EMAIL PROTECTED] and a copy will be emailed to 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] Conditional BGP
Paul Stewart wrote: What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. They can control their outbound fairly easily. They should make sure they're getting the same level (default-only, partial, full) of routes from you as from Cogent - if they take more from you, those routes are more-specific and would win regardless. I'd suggest they take default-only from you (or more but filter out everything but default so they can change on the fly later) and whatever they wish from Cogent. Controlling inbound is often tougher. Any smart provider sets a higher local pref on customer routes than on transit/peer routes (make money rather than pay money), so if you do this you'll need to make an exception for them (or offer the exception via communities). Otherwise, you'll prefer their announcement no matter how many prepends they do, and if that happens for a minute, your transits will likely prefer your propagation no matter how many prepends they do. Even if you don't do this today, if Cogent goes down, you'll choose the direct link (it's the only one live) and your transits will do the same thing (your routes have customer LP in their network). When Cogent comes up, your transits will ignore the Cogent-propagated route since it's only peer LP. They'd have to bounce the link to you to restore their preferred balance. You'll need to find out how to accomplish the same thing in your providers' networks as well. (Been there, done that, got the t-shirt.) pt ___ 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] Conditional BGP
Thanks Pete yeah, thought that through as well - been there done that ;) We'll offer them a full feed (well, all three options but I know they'll want a full feed I believe - that's what they get via Cogent as well) and then they can control everything - with communities as well on our side. We always local-pref customers 300, peers 200, transit 100 and been caught on that before hehe... I'm happy if the decisions are on the customer and we're just the provider Take care, Paul -Original Message- From: Pete Templin [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 1:06 PM To: Paul Stewart Cc: 'cisco-nsp' Subject: Re: [c-nsp] Conditional BGP Paul Stewart wrote: What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. They can control their outbound fairly easily. They should make sure they're getting the same level (default-only, partial, full) of routes from you as from Cogent - if they take more from you, those routes are more-specific and would win regardless. I'd suggest they take default-only from you (or more but filter out everything but default so they can change on the fly later) and whatever they wish from Cogent. Controlling inbound is often tougher. Any smart provider sets a higher local pref on customer routes than on transit/peer routes (make money rather than pay money), so if you do this you'll need to make an exception for them (or offer the exception via communities). Otherwise, you'll prefer their announcement no matter how many prepends they do, and if that happens for a minute, your transits will likely prefer your propagation no matter how many prepends they do. Even if you don't do this today, if Cogent goes down, you'll choose the direct link (it's the only one live) and your transits will do the same thing (your routes have customer LP in their network). When Cogent comes up, your transits will ignore the Cogent-propagated route since it's only peer LP. They'd have to bounce the link to you to restore their preferred balance. You'll need to find out how to accomplish the same thing in your providers' networks as well. (Been there, done that, got the t-shirt.) pt ___ 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] debugging all incoming traffic on an interface
Hello Alex: -Original Message- From: [EMAIL PROTECTED] [mailto:cisco-nsp- [EMAIL PROTECTED] On Behalf Of Wilkinson, Alex Sent: Tuesday, September 23, 2008 6:07 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] debugging all incoming traffic on an interface 0n Mon, Sep 22, 2008 at 06:52:21PM -0400, Jason Lixfeld wrote: Attaching a access-list 100 permit ip any any log-input to the interface and/or subinterface via ip access-group didn't show anything - the interface counters Curious ... since I dont have the luxury to play with cisco kit all day (jack of trades ...) can someone please give me a quick explanation as to how creating an ACL on an interface helps with debugging that interface ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. AFAIK it doesn't. However, you can apply ACL's to your debug setup as a filter. The filter below would only match traffic from 192.168.1.0/24 to 192.168.2.0/24 debug ip packet 199 access-list 199 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 log Regards, Mike PGP.sig 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] debugging all incoming traffic on an interface
Might this help if you get on 12.4(20)T: http://supportwiki.cisco.com/ViewWiki/index.php/Tech_Insights:Utilizing_the_New_Packet_Capture_Feature On Tue, Sep 23, 2008 at 10:42:00AM -0400, Jason Lixfeld wrote: I have. There are no interface conditions on either of those debug [ip] packet commands. Also, debug interface doesn't allow me the option of my ATM interface(s). On 23-Sep-08, at 9:03 AM, Ozgur Guler wrote: Have you tried using debug ip packet or debug packet with debug condition interface? --- On Mon, 22/9/08, Jason Lixfeld [EMAIL PROTECTED] wrote: From: Jason Lixfeld [EMAIL PROTECTED] Subject: [c-nsp] debugging all incoming traffic on an interface To: cisco-nsp@puck.nether.net Date: Monday, 22 September, 2008, 11:52 PM I'm trying to give a local ILEC an idea on where to look to troubleshoot an issue on a bridged DSL circuit. It terminates directly onto a WIC-1ADSL interface in a 2651 on the one side and a VLAN on the other side. Can't pass traffic over it, but the inbound packet counters are incrementing on the 2651 side, however I have no idea what kind of traffic is actually hitting the interface, nor do I know what the source or destination of the traffic is. My question in all of this is what's the best way to see all the traffic coming into this interface? Attaching a access-list 100 permit ip any any log-input to the interface and/or subinterface via ip access-group didn't show anything - the interface counters incremented while the access-list counter didn't. I can't debug the ATM (sub)interface, nor can I configure a SPAN port on an ATM (sub)interface. Anyone know how I might go about this? I suppose in a worst case scenario, I could hook up a DSL modem to the line and plug that into a wireshark box, but I'm hoping there's a more localized solution. Thanks in advance. ___ 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/ ___ 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] Debugging Cisco VPN Client Software ... Is it even possible ?
C'mon Alex. You turn logging on on the client. Worst case you can look up the error messages on cisco.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilkinson, Alex Sent: Tuesday, September 23, 2008 7:27 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Debugging Cisco VPN Client Software ... Is it even possible ? Hi all, From the _client_ perspective can anyone recommend any tools/techniques to debug Cisco VPN client problems ? (they drive me mad). These are mostly Windows based clients connecting to a cisco vpn concentrator. I tend to trawl through event logs and client vpn logs and really have no real success with debugging. The VPN client really feels like a black box :( Any hot tips with how to debug VPN clients not being able to connect into a vpn concentrator (from the _client_ perspective) ? Thanks! -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ 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] Best bet 65 IOS for mcast?
Hi Got a client running 33SXH1 in their network. Is SXF still the best bet for stable mcast? Or are there necessary widgets in SXH nowadays? It's a pair of 3BXLs with DFC'ed 6708s and 6748. Merci beaucoup Christian ___ 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] Weird OSPF meltdown
On Fri, Sep 19, 2008 at 02:45:48AM -0300, Rubens Kuhl Jr. wrote: Every once in a while one of ME6524 routers starts getting hammered by one customer or the other... the symptom is that all adjacencies go down and stay stuck at EXCHANGE phase. hammered by what? CPU doesn't go up, and CoPP is applied; OSPF is authenticated on every adjacency (which are all point-to-point on SVIs), and we don't see any strange neighbors. Why are the neighbors going down? Hold time expired? If so you have to figure out why those frames are dropped. It occurs more often with Internet access static connected route customers, but has now happened on a VRF as well. The only solution is disconnecting the customer; provisioning the customer on SVI or on routerport doesn't seem to have any effect. Is it OSPF going down on an interface other than where this hammering is coming from? I'm assuming you mean it's a flood of traffic. IOS is 12.2(18)ZU2; Sham-Link on this IOS is vulnerable but we are not using it. Any thoughts ? Rubens ___ 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] Debugging Cisco VPN Client Software ... Is it even possible ?
Wilkinson, Alex wrote: Any hot tips with how to debug VPN clients not being able to connect into a vpn concentrator (from the _client_ perspective) ? Yes. Don't mix Vista with Cisco's VPN client. Justin ___ 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] c4000
Hi, On Tue, Sep 23, 2008 at 04:12:13AM +0100, Mario Spinthiras wrote: Wouldn't it be a lot wiser to migrate to IOS ? I know this is possible and I'm sure it's a step forward than anything else. Can anyone shed some light on the worthiness of migrating to IOS other than the obvious (consistency , easier) On the cat4000 (as far as I know), you have no choice - it depends on the Supervisor version in use. Older ones are catos-only, newer ones are IOS-only. Only on the cat6500, you can choose. gert -- Gert Doering Mobile communications ... right now writing from * Sardegna, Italy * ___ 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] GVRP implementation
Hello All, Before planning a small deployment I wanted to know if any of you had made use of GVRP (via GARP) on production Cisco machines. Do they provide the same result as does VTP? Regards, Mario. http://www.blupenguin.com/ ___ 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] Weird OSPF meltdown
On Tue, Sep 23, 2008 at 4:40 PM, Rodney Dunn [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 02:45:48AM -0300, Rubens Kuhl Jr. wrote: Every once in a while one of ME6524 routers starts getting hammered by one customer or the other... the symptom is that all adjacencies go down and stay stuck at EXCHANGE phase. hammered by what? We could not get packet traces of all the mishaps, but in one of them there was a flood of mDNS(Multicast DNS) packets. CPU doesn't go up, and CoPP is applied; OSPF is authenticated on every adjacency (which are all point-to-point on SVIs), and we don't see any strange neighbors. Why are the neighbors going down? Hold time expired? If so you have to figure out why those frames are dropped. Yes, hold time expired. Our current theory is CoPP itself dropping the packets. We have some large ACLs describing critical, normal and undesired traffic; if some OSPF frames don't flow thru the critical ACL, the normal category would only fill up during floods. There are terms on the critical ACL to match OSPF packets, but may be it's not matching all of them. It occurs more often with Internet access static connected route customers, but has now happened on a VRF as well. The only solution is disconnecting the customer; provisioning the customer on SVI or on routerport doesn't seem to have any effect. Is it OSPF going down on an interface other than where this hammering is coming from? I'm assuming you mean it's a flood of traffic. The inbound interface for the flood doesn't run OSPF, only the upstream links to other routers. Rubens ___ 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] SXH3 ghost bugs - more details
Gert, Seems they are not planning a special rebuild for this unfortunately. We are trying to get them to build a engineering special generally available for TAC if you have a SR open they should be able to get it. Sorry... Rodney On Mon, Sep 22, 2008 at 09:04:45AM -0400, Rodney Dunn wrote: They are Gert. Let me check on it... On Sat, Sep 20, 2008 at 09:29:53PM +0200, Gert Doering wrote: Hi, On Fri, Sep 19, 2008 at 07:23:36PM +0200, Peter Rathlev wrote: CSCsu59917 SXF15: IPv4/v6 BGP routes not cleared when source routes is gone Severity: 1 - catastrophic. Indeed... makes me wonder why they are not doing an SXH rebuild on their own, instead of making us wait 4-6 weeks for a bugfix for a *catastrophic* (!!) bug. (No news from our case yet regarding an interim rebuild) thanks, gert -- Gert Doering Mobile communications ... right now writing from * Sardegna, Italy * ___ 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/ ___ 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] NPE-G2 Gigabit Ignored Errors
Hank, Every time I've ever worked on this it's microburst. The only real way to fix it is a hardware forwarding box that can do packets at line rate gige. Rodney On Sun, Sep 14, 2008 at 09:38:26AM +0300, Hank Nussbacher wrote: At 02:43 PM 12-09-08 -0400, Rodney Dunn wrote: Rodney, On a related note, we are seeing input overruns on almost all native GigaE ports on the NPE-G1. Example on 12.4(21): GigabitEthernet0/2 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is 0009.446d.ac1a (bia 0009.446d.ac1a) MTU 1500 bytes, BW 100 Kbit, DLY 10 usec, reliability 255/255, txload 23/255, rxload 13/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, link type is force-up, media type is SX output flow-control is unsupported, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 52874000 bits/sec, 13178 packets/sec 30 second output rate 92696000 bits/sec, 14626 packets/sec 13055246077 packets input, 7473426491146 bytes, 0 no buffer Received 48343 broadcasts, 0 runts, 0 giants, 0 throttles 315 input errors, 0 CRC, 0 frame, 315 overrun, 0 ignored 0 watchdog, 2937496 multicast, 0 pause input 0 input packets with dribble condition detected On 12.4(18): GigabitEthernet0/1 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is 0009.449b.2c1b (bia 0009.449b.2c1b) MTU 9000 bytes, BW 100 Kbit, DLY 10 usec, reliability 255/255, txload 29/255, rxload 41/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 00:04:00 Last input 00:00:01, output 00:00:00, output hang never Last clearing of show interface counters never Input queue: 0/2048/0/3 (size/max/drops/flushes); Total output drops: 139963 Queueing strategy: fifo Output queue: 0/1024 (size/max) 30 second input rate 163604000 bits/sec, 25284 packets/sec 30 second output rate 113775000 bits/sec, 23142 packets/sec 138829558726 packets input, 110625630435301 bytes, 0 no buffer Received 1170089 broadcasts, 0 runts, 0 giants, 0 throttles 42963 input errors, 0 CRC, 0 frame, 42963 overrun, 0 ignored 0 watchdog, 2939379 multicast, 0 pause input 0 input packets with dribble condition detected On 12.4(9)T2: GigabitEthernet0/2 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is 0009.449b.441a (bia 0009.449b.441a) MTU 1500 bytes, BW 45 Kbit, DLY 10 usec, reliability 255/255, txload 21/255, rxload 60/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters never Input queue: 0/1024/369/79002147 (size/max/drops/flushes); Total output drops: 82 Queueing strategy: fifo Output queue: 0/1024 (size/max) 30 second input rate 105976000 bits/sec, 13665 packets/sec 30 second output rate 38207000 bits/sec, 11394 packets/sec 2996785111 packets input, 3073612701 bytes, 2279 no buffer Received 500907287 broadcasts, 0 runts, 0 giants, 2483 throttles 8348 input errors, 0 CRC, 0 frame, 8348 overrun, 0 ignored 0 watchdog, 497602409 multicast, 0 pause input 0 input packets with dribble condition detected Any ideas why? -Hank On Fri, Sep 12, 2008 at 02:40:04PM -0400, Clayton Zekelman wrote: No luck... didn't fix it. Is it fixed in a subsequent release? Are there any other parameters I can tune? Not really because you can't tune the rx ring depth. Check 'sh controller'. What does 'sh proc cpu sort | excl 0.00' say? Can you post the configuration..I'm curious what your features look like because the more you have the less pps you get through this box..it's all done in software and can't do all features at line rate during a microburst. sh int stat Rodney GigabitEthernet0/1 is up, line protocol is up Hardware is MV64460 Internal MAC, address is 001a.6d30.091b (bia 001a.6d30.091b) Description: to gig-fastiron Ethernet11 MTU 1500 bytes, BW 100 Kbit, DLY 10 usec, reliability 255/255, txload 23/255, rxload 48/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP
[c-nsp] Virtualization in an enterprise
I am currently investigating using vrf-lite within our company to support some research requests. I have some hesitation about maintaining it, though, especially in a smaller enterprise environment (4 network techs, ~10 branches). I am comfortable with the technology, but don't want to increase the complexity of the network without significant advantages. More importantly, I don't want to limit the applicant pool if we need to hire someone down the road. Does anyone here have input on support and maintenance of this within an enterprise environment? We have sites connected by MPLS (BGP with the provider, but no other MPLS or vrf type features) with redundancy through an IPSEC VPN over our internet links. Thanks for any input that you can provide. Josh ___ 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] Virtualization in an enterprise
I am currently investigating using vrf-lite within our company to support some research requests. I have some hesitation about maintaining it, though, especially in a smaller enterprise environment (4 network techs, ~10 branches). I am comfortable with the technology, but don't want to increase the complexity of the network without significant advantages. More importantly, I don't want to limit the applicant pool if we need to hire someone down the road. Does anyone here have input on support and maintenance of this within an enterprise environment? We have sites connected by MPLS (BGP with the provider, but no other MPLS or vrf type features) with redundancy through an IPSEC VPN over our internet links. Thanks for any input that you can provide. Josh ___ 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] NPE-G2 Gigabit Ignored Errors
That's only applicable if you have a lot of process switched traffic and you see input drops in 'sh int'. If you do see input queue drops and the throttle count in 'sh int' is going up you might be impacted by that bug. Rodney On Sun, Sep 14, 2008 at 10:21:41AM +0300, Hank Nussbacher wrote: At 02:16 PM 12-09-08 -0400, Rodney Dunn wrote: I don't suspect that is going to help because the ignores are not increasing that would point to: CSCse05447 Externally found moderate defect: Resolved (R) 7200 ethernet interfaces should not throttle on input queue full drops Most likely you are seeing micro burst that are coming in faster than the CPU can drain the rx ring. Rodney Can't view it: Information contained within bug ID CSCse05447 is only available to Cisco employees. It is our policy to make all externally-facing bugs available in Bug Toolkit so the system administrators have been automatically alerted to the problem. By choosing to save this bug, you may be notified when the decision to make this bug available to you has been made. Note: Some product enhancement requests and documentation error bugs may not be available in Bug Toolkit. -Hank ___ 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] Weird OSPF meltdown
The problem with rate limiters is they will drop critical traffic (multicast OSPF) alongside multicast garbage from the customers. There is no hardware CoPP on the path of multicast traffic, so it's up to the CPU to survive such a flooding. Rubens On Tue, Sep 23, 2008 at 6:49 PM, Rodney Dunn [EMAIL PROTECTED] wrote: If it's a lot of punts and the hardware rate limiters don't catch them you would overrun the RP cpu or the ibc interface going up to the RP. Rodney On Tue, Sep 23, 2008 at 06:46:38PM -0200, Rubens Kuhl Jr. wrote: On Tue, Sep 23, 2008 at 4:40 PM, Rodney Dunn [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 02:45:48AM -0300, Rubens Kuhl Jr. wrote: Every once in a while one of ME6524 routers starts getting hammered by one customer or the other... the symptom is that all adjacencies go down and stay stuck at EXCHANGE phase. hammered by what? We could not get packet traces of all the mishaps, but in one of them there was a flood of mDNS(Multicast DNS) packets. CPU doesn't go up, and CoPP is applied; OSPF is authenticated on every adjacency (which are all point-to-point on SVIs), and we don't see any strange neighbors. Why are the neighbors going down? Hold time expired? If so you have to figure out why those frames are dropped. Yes, hold time expired. Our current theory is CoPP itself dropping the packets. We have some large ACLs describing critical, normal and undesired traffic; if some OSPF frames don't flow thru the critical ACL, the normal category would only fill up during floods. There are terms on the critical ACL to match OSPF packets, but may be it's not matching all of them. It occurs more often with Internet access static connected route customers, but has now happened on a VRF as well. The only solution is disconnecting the customer; provisioning the customer on SVI or on routerport doesn't seem to have any effect. Is it OSPF going down on an interface other than where this hammering is coming from? I'm assuming you mean it's a flood of traffic. The inbound interface for the flood doesn't run OSPF, only the upstream links to other routers. Rubens ___ 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] c4000
From: Gert Doering [EMAIL PROTECTED] On the cat4000 (as far as I know), you have no choice - it depends on the Supervisor version in use. Older ones are catos-only, newer ones are IOS-only. Only on the cat6500, you can choose. Another pointer: http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a0080094713.shtml This is the best practices document for CatOS switches. Incidentally, even non-fabric Cat6K's can do native IOS mode, as it's a Supervisor/MSFC combo deal that goes back all the way to Sup1 and MSFC1. Sup2/MSFC2 without the fabric cards work well in Cat6K non-fabric chassis. Which begs the point: there should have been no technical reason Native IOS mode could not have been done with Catalyst 5500 with SupIIIG/RSFC or SupIII/RSM (although the RSM/Supervisor coupling is looser); or am I missing something the MSFC/ Cat6K supervisor has in the way of linkage? RSM of course being based on 7500 RSP technology, and RSFC based on 7200 NPE200 technology, may have been part of the difference (RSFC has more features, even with an older IOS, at least per feature navigator and it's wildly accurate assessments (no feature lists yet for 12.0(32)S11 on 12000 GRP...)). I know, moot point as RSFC/RSM and the whole Cat5K series is EOL'ed, but a guy can dream. -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 828-862-5554 www.pari.edu ___ 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] How does the egress PE determine which VRF the VPN label is for?
Given the scenario in which the packet has reached the egress PE, how
does the router then determine which VRF the packet is destined for
based on the remaining VPN label? I understand the concept of there
being two labels, an IGP label and a VPN label. I'm just not sure how
the egress PE is able to deduce that the VPN label is for a particular
VRF.
Eg:
PE1 - P1 - P2 - PE2
*** First, a CEF lookup is performed on PE1 at the time the IP packet
enters the ingress PE from an interface belonging to VRF TEST and shows
that the following tags/labels {4771 44169} are pushed onto the IP
packet.
PE1#sh ip cef vrf TEST 172.16.66.2
172.16.66.2/32, version 58, epoch 0, cached adjacency 203.10.x.x
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with Gi0/0.11, 203.10.x.x, tags imposed: {4771
44169}
Flow: Origin AS 0, Peer AS 0, mask 32
via 210.15.x.x, 0 dependencies, recursive
next hop 203.10.x.x, GigabitEthernet0/0.11 via 210.15.x.x/32
valid cached adjacency
tag rewrite with Gi0/0.11, 203.10.x.x, tags imposed: {4771 44169}
*** The label packet then uses the IGP label to determine the LSP and
ends up at PE2 with just the VPN label left {44169}.
*** PE2 checks it's mpls forwarding table and finds the following entry:
PE2#sh mpls forwarding-table label 44169
Local OutgoingPrefixBytes tag Outgoing Next Hop
tagtag or VC or Tunnel Id switched interface
44169 Aggregate 172.16.66.2/32[V] 5752
*** From the book MPLS Fundamentals, it says - Aggregate means that
the aggregating LSR needs to remove the label of the incoming packet and
must do an IP lookup to determine the more specific prefix to use for
forwarding this IP packet.
What I don't get from that explaination is:
- What is involved in doing an IP lookup as the next step?
- How does the router figure out that the prefix 172.16.66.2 is a route
belonging to VRF TEST?
- Is it something to do with MP-BGP because when I do a BGP lookup on
the prefix, I see the word aggregate followed by the VRF name. How
does this information then tie in with what's contained in the mpls
forwarding table to deduce that it's VRF TEST we want.
PE2#sh ip bgp vpnv4 rd 4854:100660 172.16.66.2
BGP routing table entry for 4854:100660:172.16.66.2/32, version 811
Paths: (1 available, best #1, table TEST)
Advertised to peer-groups:
NS-MPLS-VPN
Local
0.0.0.0 from 0.0.0.0 (203.17.x.x)
Origin incomplete, metric 0, localpref 100, weight 32768, valid,
sourced, best
Extended Community: RT:4854:100660,
mpls labels in/out 44169/aggregate(TEST)
Everything is working fine - I'm just trying to understand the little
intricate details of MPLS VPN's that make them work, so I can picture it
in my mind.
Thanks.
Andy
Probably an easy question, but what is the next step that a router takes
to find the next interface or next hop it needs to send the VPN label
to?
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
Please notify the sender immediately by email if you have received this
email by mistake and delete this email from your system. Please note that
any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of the organisation.
Finally, the recipient should check this email and any attachments for
the presence of viruses. The organisation accepts no liability for any
damage caused by any virus transmitted by this email.
___
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] Configure Cisco Ace using XML
I know it was possible to configure Cisco CSS devices by posting an xml file to them. After migrating from the CSS to the ACE module I will need to do the same thing but I am having problems finding example xml files. Anyone have anything that I could use to get started? Robert Teller Washington Dental Service Network Administrator (206) 528-2371 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] # The information contained in this e-mail and subsequent attachments may be privileged, confidential and protected from disclosure. This transmission is intended for the sole use of the individual and entity to whom it is addressed. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this message in error, please e-mail the sender at the above e-mail address. # ___ 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] Conditional BGP
Could you guys recommend some good books or other documentation on some of these BGP best practice methodologies? I am a BGP novice but would like to get myself more up to speed on BGP kung fu. I found this current thread somewhat fascinating. Thanks Brandon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Stewart Sent: Tuesday, September 23, 2008 10:15 AM To: 'Pete Templin' Cc: 'cisco-nsp' Subject: Re: [c-nsp] Conditional BGP Thanks Pete yeah, thought that through as well - been there done that ;) We'll offer them a full feed (well, all three options but I know they'll want a full feed I believe - that's what they get via Cogent as well) and then they can control everything - with communities as well on our side. We always local-pref customers 300, peers 200, transit 100 and been caught on that before hehe... I'm happy if the decisions are on the customer and we're just the provider Take care, Paul -Original Message- From: Pete Templin [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 1:06 PM To: Paul Stewart Cc: 'cisco-nsp' Subject: Re: [c-nsp] Conditional BGP Paul Stewart wrote: What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. They can control their outbound fairly easily. They should make sure they're getting the same level (default-only, partial, full) of routes from you as from Cogent - if they take more from you, those routes are more-specific and would win regardless. I'd suggest they take default-only from you (or more but filter out everything but default so they can change on the fly later) and whatever they wish from Cogent. Controlling inbound is often tougher. Any smart provider sets a higher local pref on customer routes than on transit/peer routes (make money rather than pay money), so if you do this you'll need to make an exception for them (or offer the exception via communities). Otherwise, you'll prefer their announcement no matter how many prepends they do, and if that happens for a minute, your transits will likely prefer your propagation no matter how many prepends they do. Even if you don't do this today, if Cogent goes down, you'll choose the direct link (it's the only one live) and your transits will do the same thing (your routes have customer LP in their network). When Cogent comes up, your transits will ignore the Cogent-propagated route since it's only peer LP. They'd have to bounce the link to you to restore their preferred balance. You'll need to find out how to accomplish the same thing in your providers' networks as well. (Been there, done that, got the t-shirt.) pt ___ 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] Conditional BGP
Brandon Price wrote: Could you guys recommend some good books or other documentation on some of these BGP best practice methodologies? I am a BGP novice but would like to get myself more up to speed on BGP kung fu. I found this current thread somewhat fascinating. That's a tough question to answer well. To date, I haven't found many books that give the real-world knowledge needed to make one a pro. A few recommendations do come to mind though: 1) Ask a few folks for sample configs (I'll ping separately offlist and we'll figure out which ones I can send that'll make sense). 2) View the NANOG presentation archives. Several come to mind; I'll try to compile a list of suggestions, or just browse away. 3) Be the router. Use 3x5 notecards or something, and think through the BGP decision process for a single prefix sometime, as though you're each relevant router along a particular path. When I have to troubleshoot a problem, I go through this myself router-by-router, and it works (since...it's...what really happens!) quite well. pt ___ 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] Conditional BGP
The classics on BGP are Routing TCP/IP vol 1 and 2 by Doyle and Internet Routing Architectures by Sam Halabi. If you understand those, you understand enough to have some BGP kung fu. On Tue, Sep 23, 2008 at 4:34 PM, Brandon Price [EMAIL PROTECTED] wrote: Could you guys recommend some good books or other documentation on some of these BGP best practice methodologies? I am a BGP novice but would like to get myself more up to speed on BGP kung fu. I found this current thread somewhat fascinating. Thanks Brandon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Stewart Sent: Tuesday, September 23, 2008 10:15 AM To: 'Pete Templin' Cc: 'cisco-nsp' Subject: Re: [c-nsp] Conditional BGP Thanks Pete yeah, thought that through as well - been there done that ;) We'll offer them a full feed (well, all three options but I know they'll want a full feed I believe - that's what they get via Cogent as well) and then they can control everything - with communities as well on our side. We always local-pref customers 300, peers 200, transit 100 and been caught on that before hehe... I'm happy if the decisions are on the customer and we're just the provider Take care, Paul -Original Message- From: Pete Templin [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 1:06 PM To: Paul Stewart Cc: 'cisco-nsp' Subject: Re: [c-nsp] Conditional BGP Paul Stewart wrote: What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. They can control their outbound fairly easily. They should make sure they're getting the same level (default-only, partial, full) of routes from you as from Cogent - if they take more from you, those routes are more-specific and would win regardless. I'd suggest they take default-only from you (or more but filter out everything but default so they can change on the fly later) and whatever they wish from Cogent. Controlling inbound is often tougher. Any smart provider sets a higher local pref on customer routes than on transit/peer routes (make money rather than pay money), so if you do this you'll need to make an exception for them (or offer the exception via communities). Otherwise, you'll prefer their announcement no matter how many prepends they do, and if that happens for a minute, your transits will likely prefer your propagation no matter how many prepends they do. Even if you don't do this today, if Cogent goes down, you'll choose the direct link (it's the only one live) and your transits will do the same thing (your routes have customer LP in their network). When Cogent comes up, your transits will ignore the Cogent-propagated route since it's only peer LP. They'd have to bounce the link to you to restore their preferred balance. You'll need to find out how to accomplish the same thing in your providers' networks as well. (Been there, done that, got the t-shirt.) pt ___ 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/ ___ 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] How does the egress PE determine which VRF the VPN label is for?
On Wed, Sep 24, 2008 at 09:57:12AM +1000, Andy Saykao wrote:
Given the scenario in which the packet has reached the egress PE, how
does the router then determine which VRF the packet is destined for
based on the remaining VPN label? I understand the concept of there
being two labels, an IGP label and a VPN label. I'm just not sure how
the egress PE is able to deduce that the VPN label is for a particular
VRF.
Eg:
PE1 - P1 - P2 - PE2
*** First, a CEF lookup is performed on PE1 at the time the IP packet
enters the ingress PE from an interface belonging to VRF TEST and shows
that the following tags/labels {4771 44169} are pushed onto the IP
packet.
PE1#sh ip cef vrf TEST 172.16.66.2
172.16.66.2/32, version 58, epoch 0, cached adjacency 203.10.x.x
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with Gi0/0.11, 203.10.x.x, tags imposed: {4771
44169}
Flow: Origin AS 0, Peer AS 0, mask 32
via 210.15.x.x, 0 dependencies, recursive
next hop 203.10.x.x, GigabitEthernet0/0.11 via 210.15.x.x/32
valid cached adjacency
tag rewrite with Gi0/0.11, 203.10.x.x, tags imposed: {4771 44169}
*** The label packet then uses the IGP label to determine the LSP and
ends up at PE2 with just the VPN label left {44169}.
*** PE2 checks it's mpls forwarding table and finds the following entry:
PE2#sh mpls forwarding-table label 44169
Local OutgoingPrefixBytes tag Outgoing Next Hop
tagtag or VC or Tunnel Id switched interface
44169 Aggregate 172.16.66.2/32[V] 5752
*** From the book MPLS Fundamentals, it says - Aggregate means that
the aggregating LSR needs to remove the label of the incoming packet and
must do an IP lookup to determine the more specific prefix to use for
forwarding this IP packet.
What I don't get from that explaination is:
- What is involved in doing an IP lookup as the next step?
It means the aggregate just tells the PE that the ip address
is connected and in a particular VRF. There are different ways to
implement it. per prefix lables, aggregats for only connected in a vrf, etc.
- How does the router figure out that the prefix 172.16.66.2 is a route
belonging to VRF TEST?
based on the local VPN label allocated for either all connected or that
specific route. A table is maintained to map them. That's why you
can do 'sh ip bgp vpnv4 vrf blah and it show the vpnv4 label.
- Is it something to do with MP-BGP because when I do a BGP lookup on
the prefix, I see the word aggregate followed by the VRF name. How
does this information then tie in with what's contained in the mpls
forwarding table to deduce that it's VRF TEST we want.
Different protocols can insert labels in the lfib. ie: ldp, bgp, etc.
BGP can allocate a lable for VPNV4 prefixes and then advertise that to remote
PE's to tell them what label to send with. Then ldp sends labels hop by
hop to get to the PE's loopback (outer label as we call it).
PE2#sh ip bgp vpnv4 rd 4854:100660 172.16.66.2
BGP routing table entry for 4854:100660:172.16.66.2/32, version 811
Paths: (1 available, best #1, table TEST)
Advertised to peer-groups:
NS-MPLS-VPN
Local
0.0.0.0 from 0.0.0.0 (203.17.x.x)
Origin incomplete, metric 0, localpref 100, weight 32768, valid,
sourced, best
Extended Community: RT:4854:100660,
mpls labels in/out 44169/aggregate(TEST)
Everything is working fine - I'm just trying to understand the little
intricate details of MPLS VPN's that make them work, so I can picture it
in my mind.
Thanks.
Andy
Probably an easy question, but what is the next step that a router takes
to find the next interface or next hop it needs to send the VPN label
to?
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
Please notify the sender immediately by email if you have received this
email by mistake and delete this email from your system. Please note that
any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of the organisation.
Finally, the recipient should check this email and any attachments for
the presence of viruses. The organisation accepts no liability for any
damage caused by any virus transmitted by this email.
___
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] Conditional BGP
Try BGP Design and Implementation. It's the new BGP bible. ISBN: 1-58705-109-5 tv - Original Message - From: Brandon Price [EMAIL PROTECTED] To: Paul Stewart [EMAIL PROTECTED]; Pete Templin [EMAIL PROTECTED] Cc: cisco-nsp cisco-nsp@puck.nether.net Sent: Tuesday, September 23, 2008 6:34 PM Subject: Re: [c-nsp] Conditional BGP Could you guys recommend some good books or other documentation on some of these BGP best practice methodologies? I am a BGP novice but would like to get myself more up to speed on BGP kung fu. I found this current thread somewhat fascinating. Thanks Brandon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Stewart Sent: Tuesday, September 23, 2008 10:15 AM To: 'Pete Templin' Cc: 'cisco-nsp' Subject: Re: [c-nsp] Conditional BGP Thanks Pete yeah, thought that through as well - been there done that ;) We'll offer them a full feed (well, all three options but I know they'll want a full feed I believe - that's what they get via Cogent as well) and then they can control everything - with communities as well on our side. We always local-pref customers 300, peers 200, transit 100 and been caught on that before hehe... I'm happy if the decisions are on the customer and we're just the provider Take care, Paul -Original Message- From: Pete Templin [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 1:06 PM To: Paul Stewart Cc: 'cisco-nsp' Subject: Re: [c-nsp] Conditional BGP Paul Stewart wrote: What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. They can control their outbound fairly easily. They should make sure they're getting the same level (default-only, partial, full) of routes from you as from Cogent - if they take more from you, those routes are more-specific and would win regardless. I'd suggest they take default-only from you (or more but filter out everything but default so they can change on the fly later) and whatever they wish from Cogent. Controlling inbound is often tougher. Any smart provider sets a higher local pref on customer routes than on transit/peer routes (make money rather than pay money), so if you do this you'll need to make an exception for them (or offer the exception via communities). Otherwise, you'll prefer their announcement no matter how many prepends they do, and if that happens for a minute, your transits will likely prefer your propagation no matter how many prepends they do. Even if you don't do this today, if Cogent goes down, you'll choose the direct link (it's the only one live) and your transits will do the same thing (your routes have customer LP in their network). When Cogent comes up, your transits will ignore the Cogent-propagated route since it's only peer LP. They'd have to bounce the link to you to restore their preferred balance. You'll need to find out how to accomplish the same thing in your providers' networks as well. (Been there, done that, got the t-shirt.) pt ___ 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/ ___ 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] Conditional BGP
2) View the NANOG presentation archives. Several come to mind; I'll try to compile a list of suggestions, or just browse away. Search the presentation archive for Smith and BGP. Philip Smith's BGP tutorials are outstanding. ___ 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] How does the egress PE determine which VRF the VPN label is for?
Argh worked it out. The VRF is seen if you include the detail in the
command.
PE2#sh mpls forwarding-table detail | begin _44169_
44169 Aggregate 172.16.66.2/32[V] 5752
MAC/Encaps=0/0, MRU=0, Tag Stack{}
VPN route: TEST
No output feature configured
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
Please notify the sender immediately by email if you have received this
email by mistake and delete this email from your system. Please note that
any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of the organisation.
Finally, the recipient should check this email and any attachments for
the presence of viruses. The organisation accepts no liability for any
damage caused by any virus transmitted by this email.
___
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] debugging all incoming traffic on an interface
It may, however it doesn't appear 12.4 is supported on the 2651. On 23-Sep-08, at 1:27 PM, Rodney Dunn wrote: Might this help if you get on 12.4(20)T: http://supportwiki.cisco.com/ViewWiki/index.php/Tech_Insights:Utilizing_the_New_Packet_Capture_Feature On Tue, Sep 23, 2008 at 10:42:00AM -0400, Jason Lixfeld wrote: I have. There are no interface conditions on either of those debug [ip] packet commands. Also, debug interface doesn't allow me the option of my ATM interface(s). On 23-Sep-08, at 9:03 AM, Ozgur Guler wrote: Have you tried using debug ip packet or debug packet with debug condition interface? --- On Mon, 22/9/08, Jason Lixfeld [EMAIL PROTECTED] wrote: From: Jason Lixfeld [EMAIL PROTECTED] Subject: [c-nsp] debugging all incoming traffic on an interface To: cisco-nsp@puck.nether.net Date: Monday, 22 September, 2008, 11:52 PM I'm trying to give a local ILEC an idea on where to look to troubleshoot an issue on a bridged DSL circuit. It terminates directly onto a WIC-1ADSL interface in a 2651 on the one side and a VLAN on the other side. Can't pass traffic over it, but the inbound packet counters are incrementing on the 2651 side, however I have no idea what kind of traffic is actually hitting the interface, nor do I know what the source or destination of the traffic is. My question in all of this is what's the best way to see all the traffic coming into this interface? Attaching a access-list 100 permit ip any any log-input to the interface and/or subinterface via ip access-group didn't show anything - the interface counters incremented while the access-list counter didn't. I can't debug the ATM (sub)interface, nor can I configure a SPAN port on an ATM (sub)interface. Anyone know how I might go about this? I suppose in a worst case scenario, I could hook up a DSL modem to the line and plug that into a wireshark box, but I'm hoping there's a more localized solution. Thanks in advance. ___ 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/ ___ 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] multiple PPPOE sessions
Dear All Is there any tester which can make multiple PPPOE sessions, need to test radius max limit concurrent sessions, I was searching for a software base solution for it since last night but I guess there is no software initiate for this purpose if any one knows either software which can accomplished the same task or any hard based solution please reply. Thanks Regards Farhan Ali Khan ___ 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] c4000
Earlier switches run CATOS There is a difference between set base CLIs [CAT 4K] and normal CLIs commands [2960] For 2960 Vlan 10 Name engineering Interface x/x Switchportt access vlan 10 Or for trunk / Access Switchport mode access / trunk For CAT 4K Run borth cmd from enable mode Set vlan 10 name engineering Set vlan 10 x/x // where x/x is your interface number like fas0/1 Set vlan 10 x/a-b // x is module name and a - b is port range By default, Fast Ethernet and Gigabit Ethernet ports are in auto mode. If the port on the other end of the link is in desirable mode or on, a port in auto mode automatically becomes a trunk port. set trunk x/x desirable dot1q set trunk x/x dot1q verify it by show trunk clear -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of adrian kok Sent: 23 September, 2008 3:59 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] c4000 Hi all ls any different to setup vlan between catalyst 4000 and 2960? I need to setup the cisco2800 to have vlan this 4000 switch ls it easy? how setup the trunk port in 4000 switch? Thank you Send instant messages to your online friends http://uk.messenger.yahoo.com ___ 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/
