[c-nsp] SUP-2T and ingress netflow + microflows policing
Hi I'm currently using 6500 with SUP720 and 67xx CFC linecards (mainly almost all are 6704-10GE). Is SUP-2T (PFC4) changes anything about possible simultaneous features configured on one interface comparing to SUP720 (PFC3) ? My goal is to have ingress netflow and microflow policing configured on same interface simultaneous. When I have configured these features together on SUP720 then 6500 causing me error: %FM-4-FLOWMASK_REDUCED: Features configured on interface TenGigabitEthernet4/3 have conflicting flowmask requirements, some features may work in software I have to disable netflow or microflow policing on interface to go back to hardware forwarding instead of punt to CPU. My configuration: interface TenGigabitEthernet4/3 description TSIC04 ip address x.x.x.x 255.255.255.252 ip access-group SPOOFING-IN in no ip redirects no ip unreachables no ip proxy-arp ip flow ingress ip policy route-map PBR load-interval 30 ipv6 address .. ipv6 enable ipv6 nd ra suppress ipv6 traffic-filter SPOOFING-INv6 in no ipv6 mld router no cdp enable hold-queue 1500 in ! class-map match-any servers-low match access-group 100 ! policy-map microflows-police class servers-low police flow mask dest-only 2000 50 conform-action transmit exceed-action drop class class-default ! ! about 20 hosts access-list 100 permit ip any host x.x.x.x access-list 100 permit ip any host x.x.x.x access-list 100 permit ip any host x.x.x.x access-list 100 permit ip any host x.x.x.x access-list 100 permit ip any host x.x.x.x access-list 100 permit ip any host x.x.x.x access-list 100 permit ip any host x.x.x.x access-list 100 permit ip any host x.x.x.x access-list 100 permit ip any host x.x.x.x access-list 100 permit ip any host x.x.x.x BTW. Can also Sup2-T/PFC4 solve all issues with IPv6 ? Eg. full ipv6 acls instead of compressed like on PFC3, ipv6 copp, ipv6 hardware pbr ? Robert ___ 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] Maximum number of VRF-Lite instances in ISR G2 routers
Dear All, I am starting a project to implement VRF-lite for some customers, does anybody know (or have a link to some Cisco documentation) the maximum number of VRF-lite instances in the different ISR G2 routers models of Cisco? Thanks, Matteo ___ 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] Maximum number of VRF-Lite instances in ISR G2 routers
On Wed, 2011-07-13 at 10:01 +0200, Matteo Castelli ML wrote: I am starting a project to implement VRF-lite for some customers, does anybody know (or have a link to some Cisco documentation) the maximum number of VRF-lite instances in the different ISR G2 routers models of Cisco? I tried creating a bunch of VRFs on a plain 2801 with 128M RAM running 12.4(24)T3 Enterprise Base. It's not a G2, but the results should not be worse. It seems that the number of VRFs is only limited by memory. Statistics for processor memory: #VRFs Total(b) Used(b) Free(b) Lowest(b) Largest(b) 300 55234624 33762740 21471884 21387108 21400832 400 55234624 38923612 16311012 16234112 16255268 500 55234624 44236524 10998100 10934664 10919836 600 55234624 49404172 5830452 57545445763496 700 55234624 54614228 620396557736 555396 After the 700th VRF the box logged this: 005493: Jul 13 10:26:52.299 CEST: %AAA-3-ACCT_LOW_MEM_TRASH: AAA unable to handle accounting requests due to insufficient processor memory and could be trashing the queued accounting records Keep in mind that this is a lab test, no traffic et cetera. My guess is that the raw number of VRFs supported on a G2 would be something in the ballpark of 1000 or more. I would also guess that the limiting factor would be forwarding performance before number of VRFs. I don't have a G2 readily available to test though. The VRFs were created as: ip vrf testnumber rd 1:number ! -- Peter ___ 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] sup2T software release notes have hit
On 07/12/2011 03:34 PM, Mark Tinka wrote: On Tuesday, July 12, 2011 02:29:25 PM Alan Buxey wrote: Use the sfp+ adapter? I saw that too. My point is I'm guessing the card could be cheaper (and faster) if smaller sockets were used. Also, XFP would give us better distance as of now, but sure, SFP+ will eventually catch up. I just think any sensible vendor should be using XFP as a minimum for 10Gbps optics; not X2 or XENPAK. Cisco seem to have a real blindspot for 10G transceivers. The explanation back in the day was that Cisco had a lot of customers wanting to run 10gig over old multimode fibre, and thus needed the LX4 transceiver which required a physically bigger housing to fit all the bits into. I wonder if that's still their reasoning for X2? ___ 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] SUP-2T and ingress netflow + microflows policing
On 07/13/2011 07:12 AM, Robert Hass wrote: Hi I'm currently using 6500 with SUP720 and 67xx CFC linecards (mainly almost all are 6704-10GE). Is SUP-2T (PFC4) changes anything about possible simultaneous features configured on one interface comparing to SUP720 (PFC3) ? My goal is to have ingress netflow and microflow policing configured on same interface simultaneous. Yes, I believe so. AIUI, there are more flowmasks in the PFC4/DFC4, which means you can have more features with conflicting flowmasks enabled at the same time. I don't have the numbers to hand; talk to your account manager for details, but I'm reasonably sure the PFC4 does this better. My configuration: You didn't list your netflow config. I take it you're unable or unwilling to change your netflow flowmask to match that required by the microflow policer? BTW. Can also Sup2-T/PFC4 solve all issues with IPv6 ? Eg. full ipv6 acls instead of compressed like on PFC3, ipv6 copp, ipv6 hardware pbr Yes to all, I believe. Also IPv6 uRPF in hardware. Again, check with your account manager to be sure. ___ 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] IPv6 Stateful IOS Firewall
According to the documentation at http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-sec_trfltr _fw_ps10592_TSD_Products_Configuration_Guide_Chapter.html The following should suffice as a simple stateful IPv6 firewall (no reflection or zoning): ! ipv6 unicast-routing ipv6 cef ipv6 inspect udp idle-time 120 ipv6 inspect tcp max-incomplete host 250 block-time 0 ipv6 inspect name cbac-ipv6 tcp ipv6 inspect name cbac-ipv6 udp ipv6 inspect name cbac-ipv6 icmp ipv6 inspect name cbac-ipv6 ftp ! int X/Y desc WAN ipv6 enable ipv6 traffic-filter ipv6-internet-in in ipv6 inspect cbac-ipv6 out ! ipv6 access-list ipv6-internet-in permit icmp fe80::/64 any nd-na permit icmp fe80::/64 any nd-ns deny ipv6 any any log ! However, this results in some odd behaviour, when debug ipv6 inspect detailed is enabled and traffic is sent through the firewall, the following message is logged for every packet : Jul 13 09:54:14 BST: FIREWALL: acl or insp_list not found Can somebody tell me what I'm missing? #sh ver | in UNIV Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.0(1)M2, RELEASE SOFTWARE (fc2) #sh lic Index 1 Feature: ipbasek9 Period left: Life time License Type: Permanent License State: Active, In Use License Count: Non-Counted License Priority: Medium Index 2 Feature: securityk9 Period left: Life time License Type: Permanent License State: Active, In Use License Count: Non-Counted License Priority: Medium Index 3 Feature: datak9 Period left: 8 weeks 4 days License Type: Evaluation License State: Active, Not in Use, EULA not accepted License Count: Non-Counted License Priority: None Index 4 Feature: SSL_VPN Period left: 8 weeks 4 days License Type: Evaluation License State: Active, Not in Use, EULA not accepted License Count: 75/0/0 (Active/In-use/Violation) License Priority: None Index 5 Feature: ios-ips-update Thanks in advance Dave. ___ 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] Maximum number of VRF-Lite instances in ISR G2 routers
On Wed, 13 Jul 2011, Peter Rathlev wrote: On Wed, 2011-07-13 at 10:01 +0200, Matteo Castelli ML wrote: I am starting a project to implement VRF-lite for some customers, does anybody know (or have a link to some Cisco documentation) the maximum number of VRF-lite instances in the different ISR G2 routers models of Cisco? I tried creating a bunch of VRFs on a plain 2801 with 128M RAM running 12.4(24)T3 Enterprise Base. It's not a G2, but the results should not be worse. It seems that the number of VRFs is only limited by memory. Statistics for processor memory: #VRFs Total(b) Used(b) Free(b) Lowest(b) Largest(b) 300 55234624 33762740 21471884 21387108 21400832 400 55234624 38923612 16311012 16234112 16255268 500 55234624 44236524 10998100 10934664 10919836 600 55234624 49404172 5830452 57545445763496 700 55234624 54614228 620396557736 555396 If I remember correctly another limitation that affects the number of VRFs is the number of software IDBs that are available in each platform. show idb will show how many are available, and how they are used. Regards, John ___ 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] Maximum number of VRF-Lite instances in ISR G2 routers
On Wed, 2011-07-13 at 11:58 +0300, John Kougoulos wrote: If I remember correctly another limitation that affects the number of VRFs is the number of software IDBs that are available in each platform. show idb will show how many are available, and how they are used. I actually suspected that, but show idb didn't change when just creating VRFs. I therefore think the IDB is only involved in how many logical interfaces you can have, though I'm not sure. From my test-box, with 200 VRFs created: Router#show idb Maximum number of Software IDBs 1200. In use 6. HWIDBs SWIDBs Active 2 2 Inactive2 4 Total IDBs 4 6 Size each (bytes)2888 1432 Total bytes 11552 8592 Type SIdx Idx St,O,Sh Interface Name (subblocks) --- H 1 2 U,U,R FastEthernet0/0 (HW SB CDP(5), MAC ADDR(3), MTU MIN MAX(2), Ether(1)) H 2 3 U,U,R FastEthernet0/1 (HW IP ACCESS(7), DOT1Q(6), HW SB CDP(5), MAC ADDR(3), MTU MIN MAX(2), Ether(1)) S 1 2 U FastEthernet0/0 (Ether-OAM(9), SW CDP(8), ARP IDB Subblock(7), Dynamic DNS Updates(6), NetBIOS(5), Ether-OAM-PD(2), KEEPALIVE(1)) S 2 3 U FastEthernet0/1 (ARP IDB Subblock(7), Dynamic DNS Updates(6), ACL(11), Ether-OAM(9), SW CDP(8), NetBIOS(5), Ether-OAM-PD(2), KEEPALIVE(1)) Key: SIdx=Sort Index, Idx=hw_if_index or if_number St=Current State, O=Old State, Sh=Shadow State A=Admindown, D=Down, G=Going Down, I=Init R=Reset, T=Testing, U=Up, X=Deleted Router# It has two deleted dot1q subinterfaces on one of the physical interfaces at this time according to show ip interface brief. -- Peter ___ 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] SUP-2T and ingress netflow + microflows policing
I take it you're unable or unwilling to change your netflow flowmask to match that required by the microflow policer? My mls netflow configuration below: mls ipv6 acl compress address unicast mls aging fast time 5 threshold 16 mls aging long 64 mls aging normal 32 mls netflow interface mls netflow usage notify 90 120 mls flow ip interface-full mls nde sender version 5 mls sampling packet-based 64 32000 ip flow-export source Vlan632 ip flow-export version 5 origin-as ip flow-export destination 10.55.78.15 3 ip flow-export destination 10.55.79.15 3 You think I can change something here to have same flowmasks ? Robert ___ 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] SUP-2T and ingress netflow + microflows policing
On 07/13/2011 10:29 AM, Robert Hass wrote: You think I can change something here to have same flowmasks ? Hmm. I'm a bit surprised TBH; there are two usable flowmasks on the sup720 for IPv4; you're using one (interface-full) for netflow, so you should be able to use another (destination) for your microflow policer. What does: sh platform hardware capacity netflow ...say? Disclaimer: I've only ever used microflow policing in the lab, and that was ages ago, so I might be misremembering how it works. ___ 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] Maximum number of VRF-Lite instances in ISR G2 routers
It will also depend on how many routes are in each VRF. David Rothera On Wed, Jul 13, 2011 at 9:33 AM, Peter Rathlev pe...@rathlev.dk wrote: On Wed, 2011-07-13 at 10:01 +0200, Matteo Castelli ML wrote: I am starting a project to implement VRF-lite for some customers, does anybody know (or have a link to some Cisco documentation) the maximum number of VRF-lite instances in the different ISR G2 routers models of Cisco? I tried creating a bunch of VRFs on a plain 2801 with 128M RAM running 12.4(24)T3 Enterprise Base. It's not a G2, but the results should not be worse. It seems that the number of VRFs is only limited by memory. Statistics for processor memory: #VRFs Total(b) Used(b) Free(b) Lowest(b) Largest(b) 300 55234624 33762740 21471884 21387108 21400832 400 55234624 38923612 16311012 16234112 16255268 500 55234624 44236524 10998100 10934664 10919836 600 55234624 49404172 5830452 57545445763496 700 55234624 54614228 620396557736 555396 After the 700th VRF the box logged this: 005493: Jul 13 10:26:52.299 CEST: %AAA-3-ACCT_LOW_MEM_TRASH: AAA unable to handle accounting requests due to insufficient processor memory and could be trashing the queued accounting records Keep in mind that this is a lab test, no traffic et cetera. My guess is that the raw number of VRFs supported on a G2 would be something in the ballpark of 1000 or more. I would also guess that the limiting factor would be forwarding performance before number of VRFs. I don't have a G2 readily available to test though. The VRFs were created as: ip vrf testnumber rd 1:number ! -- Peter ___ 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] sup2T software release notes have hit
On 13/07/2011 09:45, Phil Mayers wrote: The explanation back in the day was that Cisco had a lot of customers wanting to run 10gig over old multimode fibre, and thus needed the LX4 transceiver which required a physically bigger housing to fit all the bits into. I wonder if that's still their reasoning for X2? Being a XENPAK, X2 uses XAUI instead of XFI, which means that XAUI client side transceivers (e.g. lx4, cx4, etc) need a serdes if you want to run them on XFP. Obviously, a serdes takes up space, which an XFP doesn't have, but I guess if it's a CX4 interface you'll need to build external housing anyway, which could hold the serdes. So you end up with ugly beasts like this: http://www.equip-u.com/shop/images/products_computers/stc_XFP-CX4.jpg Maybe some cisco designers just like X2? Maybe Cisco have lots of experience with X2 and the architectural move to XFI interfaces would mean board redesigns? Difficult to tell really. I have to say that as a customer, I view X2 as a serious barrier to buying certain types of cisco kit, and am frankly astounded that they are still pushing out new board designs which use this format. Bizarre. Nick, working in an X2-free environment ___ 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] Cat4500 High CPU with Multicast Stream
Hello group, I have a customer with a few 3560/3750's and one 4500/SUP5 acting as the core switch. For some reason, when a user start one multicast stream, the 4500 suffers high cpu utilization and the network is affected. Only the 4500 suffers of this problem, the 3560/3750's don't have any complaints. I see that the 4500 is a CEF based platform and I know that IP Multicast is not supported in the CEF path. So I was expecting to have this traffic switched in hardware or fast-switched. But a packet capture shows me that the traffic goes to the cpu. I used this debug and output to confirm this: debug platform packet all receive buffer show platform cpu packet buffered The processes that eat most of the cpu are Cat4k Mgmt LoPri and Cat4k Mgmt HiPri. We thought this could be a bug and we upgraded the 4500 to the latest release but the problem is exactly the same. The multicast stream is processed by the cpu. Anyone has seen this before ? Is this normal behavior of the 4500 ? Usually the multicast streams are destined to 224.x.x.x. The end users do not respect the 239 rule. Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net ___ 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] Cat4500 High CPU with Multicast Stream
Check the ttl on the multicast stream. A ttl of 1 will cause it to hit the CPU of your first hop router. On Jul 13, 2011 8:02 AM, Antonio Soares amsoa...@netcabo.pt wrote: Hello group, I have a customer with a few 3560/3750's and one 4500/SUP5 acting as the core switch. For some reason, when a user start one multicast stream, the 4500 suffers high cpu utilization and the network is affected. Only the 4500 suffers of this problem, the 3560/3750's don't have any complaints. I see that the 4500 is a CEF based platform and I know that IP Multicast is not supported in the CEF path. So I was expecting to have this traffic switched in hardware or fast-switched. But a packet capture shows me that the traffic goes to the cpu. I used this debug and output to confirm this: debug platform packet all receive buffer show platform cpu packet buffered The processes that eat most of the cpu are Cat4k Mgmt LoPri and Cat4k Mgmt HiPri. We thought this could be a bug and we upgraded the 4500 to the latest release but the problem is exactly the same. The multicast stream is processed by the cpu. Anyone has seen this before ? Is this normal behavior of the 4500 ? Usually the multicast streams are destined to 224.x.x.x. The end users do not respect the 239 rule. Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net ___ 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] Cat4500 High CPU with Multicast Stream
I will check that, in fact the 4500 is the first hop router. Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) mailto:amsoa...@netcabo.pt amsoa...@netcabo.pt http://www.ccie18473.net http://www.ccie18473.net From: Chris Evans [mailto:chrisccnpsp...@gmail.com] Sent: quarta-feira, 13 de Julho de 2011 13:12 To: Antonio Soares Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cat4500 High CPU with Multicast Stream Check the ttl on the multicast stream. A ttl of 1 will cause it to hit the CPU of your first hop router. On Jul 13, 2011 8:02 AM, Antonio Soares amsoa...@netcabo.pt wrote: Hello group, I have a customer with a few 3560/3750's and one 4500/SUP5 acting as the core switch. For some reason, when a user start one multicast stream, the 4500 suffers high cpu utilization and the network is affected. Only the 4500 suffers of this problem, the 3560/3750's don't have any complaints. I see that the 4500 is a CEF based platform and I know that IP Multicast is not supported in the CEF path. So I was expecting to have this traffic switched in hardware or fast-switched. But a packet capture shows me that the traffic goes to the cpu. I used this debug and output to confirm this: debug platform packet all receive buffer show platform cpu packet buffered The processes that eat most of the cpu are Cat4k Mgmt LoPri and Cat4k Mgmt HiPri. We thought this could be a bug and we upgraded the 4500 to the latest release but the problem is exactly the same. The multicast stream is processed by the cpu. Anyone has seen this before ? Is this normal behavior of the 4500 ? Usually the multicast streams are destined to 224.x.x.x. The end users do not respect the 239 rule. Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net ___ 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] How do ACLs effect throughput
Dear all, My organisation has two (old) Cisco 2600 series routers deployed in two remote sites, one 2620 and one 2621. So far these routers have been performing very well, however we are now looking at substantially increasing the bandwidth of the WAN links that connect these two remote sites to the central office. At present these remote sites connect to the central office via 4Mbps ADSL lines and we will be upgrading these to 100Mbps (full-duplex) optical fibre links. We are essentially trying to determine whether these old routers will still be able to handle the increased traffic load or whether we need to upgrade the routers as well. The information we have managed to find so far suggests that these routers would be able to cope if all packet switching is done in CEF. The set-up in these remote sites is quite simple and we only use extended IP access lists in order to control access to certain VLANs. Does anybody know whether these ACLs would cause the traffic to be punted from CEF to process switching? Many thanks Terence ___ 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 do ACLs effect throughput
Hi Terence. Is this what you where looking for perhaps? http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerp erformance.pdf Ciao JC -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Terence Scott Sent: Wednesday, July 13, 2011 10:52 AM To: Cisco-NSP Subject: [c-nsp] How do ACLs effect throughput Dear all, My organisation has two (old) Cisco 2600 series routers deployed in two remote sites, one 2620 and one 2621. So far these routers have been performing very well, however we are now looking at substantially increasing the bandwidth of the WAN links that connect these two remote sites to the central office. At present these remote sites connect to the central office via 4Mbps ADSL lines and we will be upgrading these to 100Mbps (full-duplex) optical fibre links. We are essentially trying to determine whether these old routers will still be able to handle the increased traffic load or whether we need to upgrade the routers as well. The information we have managed to find so far suggests that these routers would be able to cope if all packet switching is done in CEF. The set-up in these remote sites is quite simple and we only use extended IP access lists in order to control access to certain VLANs. Does anybody know whether these ACLs would cause the traffic to be punted from CEF to process switching? Many thanks Terence ___ 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] Cat4500 High CPU with Multicast Stream
Antonio Soares amsoa...@netcabo.pt wrote: I have a customer with a few 3560/3750's and one 4500/SUP5 acting as the core switch. For some reason, when a user start one multicast stream, the 4500 suffers high cpu utilization and the network is affected. Only the 4500 suffers of this problem, the 3560/3750's don't have any complaints. I see that the 4500 is a CEF based platform and I know that IP Multicast is not supported in the CEF path. So I was expecting to have this traffic switched in hardware or fast-switched. But a packet capture shows me that the traffic goes to the cpu. I used this debug and output to confirm this: debug platform packet all receive buffer show platform cpu packet buffered The processes that eat most of the cpu are Cat4k Mgmt LoPri and Cat4k Mgmt HiPri. We thought this could be a bug and we upgraded the 4500 to the latest release but the problem is exactly the same. The multicast stream is processed by the cpu. Anyone has seen this before ? Is this normal behavior of the 4500 ? Usually the multicast streams are destined to 224.x.x.x. The end users do not respect the 239 rule. Sounds like the following might help: http://www.gossamer-threads.com/lists/cisco/nsp/128799?do=post_view_threaded It's the following lines you might need: mls rate-limit multicast ipv4 non-rpf 100 10 mls rate-limit multicast ipv4 partial 250 100 Or something similar to them. Cheers -- Alexander Clouter .sigmonster says: I'm not tense, just terribly, terribly alert! ___ 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] Cat4500 High CPU with Multicast Stream
The TTL=1, they use VLC and this is the default TTL value. We found in the meanwhile that if the stream is sent to 239.x.x.x, there is no impact on the 4500's cpu. If the stream destination is somewhere in the 224.x.x.x range, the cpu goes to the maximum. The packets are processed by the cpu. I understand the 4500 is listening to the 224.0.0.0/24 address space, so this must the reason we have this behavior. We don't have IP Multicast enabled. I'm thinking about enabling IP Multicast and only accept the 239 range. Any comments ? Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Antonio Soares Sent: quarta-feira, 13 de Julho de 2011 13:26 To: 'Chris Evans' Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cat4500 High CPU with Multicast Stream I will check that, in fact the 4500 is the first hop router. Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) mailto:amsoa...@netcabo.pt amsoa...@netcabo.pt http://www.ccie18473.net http://www.ccie18473.net From: Chris Evans [mailto:chrisccnpsp...@gmail.com] Sent: quarta-feira, 13 de Julho de 2011 13:12 To: Antonio Soares Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cat4500 High CPU with Multicast Stream Check the ttl on the multicast stream. A ttl of 1 will cause it to hit the CPU of your first hop router. On Jul 13, 2011 8:02 AM, Antonio Soares amsoa...@netcabo.pt wrote: Hello group, I have a customer with a few 3560/3750's and one 4500/SUP5 acting as the core switch. For some reason, when a user start one multicast stream, the 4500 suffers high cpu utilization and the network is affected. Only the 4500 suffers of this problem, the 3560/3750's don't have any complaints. I see that the 4500 is a CEF based platform and I know that IP Multicast is not supported in the CEF path. So I was expecting to have this traffic switched in hardware or fast-switched. But a packet capture shows me that the traffic goes to the cpu. I used this debug and output to confirm this: debug platform packet all receive buffer show platform cpu packet buffered The processes that eat most of the cpu are Cat4k Mgmt LoPri and Cat4k Mgmt HiPri. We thought this could be a bug and we upgraded the 4500 to the latest release but the problem is exactly the same. The multicast stream is processed by the cpu. Anyone has seen this before ? Is this normal behavior of the 4500 ? Usually the multicast streams are destined to 224.x.x.x. The end users do not respect the 239 rule. Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net ___ 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] Cat4500 High CPU with Multicast Stream
On Wed, 2011-07-13 at 12:59 +0100, Antonio Soares wrote: Usually the multicast streams are destined to 224.x.x.x. The end users do not respect the 239 rule. Beware that traffic to 224.0.0.0/24 (Local Network Control Block) is _always_ process switched and will never be blocked by any switch. As long as these addresses are used the traffic will be punted. I could imagine that the LNCB addresses were used exactly because they're always forwarded. They might have tried using 239-addresses (Organization-Local Scope) but maybe couldn't get it to work. Typically Cisco access switches are running IGMP Snooping, and will not forward multicast traffic without either an IGMP Snooping Querier or a PIM enabled device on the VLAN (unless it's LNCB). If all traffic is intra-VLAN you could just add ip igmp snooping querier to the relevant SVI and move the clients to 239.x.y.z addresses. You could also block traffic to these multicast addresses on the SVIs with (hardware) ACLs. Beware that OSPF, HSRP et cetera actually use LNCB addresses, and it's probably not smart to block these. -- Peter ___ 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] Underrun/runt issue on trunk interface between 2 switchs
Hey Guys, I am having a weird issue between 2 switchs that I hope someone can help out with. One end of the trunk is a cisco WS-C3548-XL running 12.0(5.3)WC(1) code The other end is a ProCurve J9086A Switch 2610-24/12PWR software Version: R.11.25 On the Procurve end I see absolutely nothing in the way of errors. But on the Cisco end I see an excessive amount of runts as per the following: sho int fastEthernet 0/1 FastEthernet0/1 is up, line protocol is up Hardware is Fast Ethernet, address is 0008.2117.b141 (bia 0008.2117.b141) MTU 1500 bytes, BW 10 Kbit, DLY 100 usec, reliability 250/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive not set Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:23, output 00:00:00, output hang never Last clearing of show interface counters 01:31:18 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 5000 bits/sec, 4 packets/sec 5 minute output rate 7000 bits/sec, 7 packets/sec 31492 packets input, 5362556 bytes Received 14259 broadcasts, 3929 runts, 0 giants, 0 throttles 3929 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 2081 multicast 0 input packets with dribble condition detected 41094 packets output, 6605873 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out Relevent config for each port is very basic as per the following: Cisco: interface FastEthernet0/1 duplex full speed 100 switchport trunk encapsulation dot1q switchport mode trunk end HP Procurve: interface 24 speed-duplex 100-full vlan 10 name X-VLAN untagged 13-21,27-28 ip address 10.16.52.245 255.255.255.0 tagged 1-5,22-26 exit I've tried changing the cable between the 2 switchs as well as changing the port on both ends. This didn't make any changes. I then decided to change it from a trunk to an access port on both sides.. When I did this I again saw no errors on the Procurve end of the link. However I then started to see overruns on the Cisco switch as per the following: Hardware is Fast Ethernet, address is 0008.2117.b155 (bia 0008.2117.b155) MTU 1500 bytes, BW 0 Kbit, DLY 0 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive not set Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:02:32, output 00:02:04, output hang never Last clearing of show interface counters 00:07:56 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 1342 packets input, 166570 bytes Received 711 broadcasts, 0 runts, 0 giants, 0 throttles 9 input errors, 9 CRC, 0 frame, 9 overrun, 9 ignored 0 watchdog, 118 multicast 0 input packets with dribble condition detected 990 packets output, 168402 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out This isn't occuring on any other interface on the Cisco switch. Also, it is not occuring on any other switch connecting of the Procurve switch either. Does anyone have any ideas what coulld be causing this? Also worth nothing the input counts above are over only 20 or so minutes. The counters were cleared prior. ___ 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] Suspect MTU Issues
2011/7/12 Gert Doering g...@greenie.muc.de Hi, On Tue, Jul 12, 2011 at 07:46:00PM +, Leigh Harrison wrote: There is a legacy layer 2 network which has had an mpls network built over it. A link between two of the data centres is a dark fibre between two Cisco 3750E switches running on the ten gig ports with a variety of vlans passing over a dot1q trunk. Both of these switches are pretty much out of the box and have a standard system mtu of 1500 You have an MTU problem. If you want to send (1500 byte + extra header bytes) packets over a link with a MTU of 1500 - FAIL. gert It's actually going to be 1500 - header sizes. So 1500 - MPLS (4bytes) = 1496 possibly - IPSEC (20 Bytes) = 1476 ___ 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] Suspect MTU Issues
Hi, On Wed, Jul 13, 2011 at 09:38:56AM -0400, Keegan Holley wrote: You have an MTU problem. If you want to send (1500 byte + extra header bytes) packets over a link with a MTU of 1500 - FAIL. It's actually going to be 1500 - header sizes. So 1500 - MPLS (4bytes) = 1496 possibly - IPSEC (20 Bytes) = 1476 The input packet is 1500 bytes (+ethernet headers, not counted on IOS MTU settings), you tack 4 byte MPLS on it - your egress packet is 1504 (+ethernet header). So if your intermediate switches only allow 1500, you have a FAIL. Which is what I said, just in more words. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpM04t9pPz2O.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] How do ACLs effect throughput
Hi Terence, As per the Cisco Router Performance link already posted by someone else these routers will NOT handle anything much above 10Mbps (and even that is a struggle). You are going to require an upgrade. If you are planning on trying to use the full 100Mbps link then you should in theory be looking at 3800 or any of the G2 ISR models (1900/2900/3900). I don't have any personal experience with them, but someone else might have something to add about real world performance from them. If you want something cheap and second hand you could look at an old 7200 with NPE-300/400/G1 in it. You should be able to get an I/O card that has 2x 10/100 ports on it, so not need to add any modules to it. You will also need to consider how the services are handed off to you. If they are fiber then you might want to look at a router that has SFP ports built into it instead of having to use an external fibre/copper converter. A quick check shows that 3800, some of the 2900 and all of the 3900 have SFP ports on them. http://www.cisco.com/en/US/products/ps10537/prod_series_comparison.html As for the question of how ACL's affect throughput, I'm not sure if there is any real hit on these routers ? Perhaps someone else might be able to elaborate if they know one way or the other. regards, Tony. --- On Wed, 13/7/11, Terence Scott terence.sc...@um.edu.mt wrote: From: Terence Scott terence.sc...@um.edu.mt Subject: [c-nsp] How do ACLs effect throughput To: Cisco-NSP cisco-nsp@puck.nether.net Received: Wednesday, 13 July, 2011, 6:52 PM Dear all, My organisation has two (old) Cisco 2600 series routers deployed in two remote sites, one 2620 and one 2621. So far these routers have been performing very well, however we are now looking at substantially increasing the bandwidth of the WAN links that connect these two remote sites to the central office. At present these remote sites connect to the central office via 4Mbps ADSL lines and we will be upgrading these to 100Mbps (full-duplex) optical fibre links. We are essentially trying to determine whether these old routers will still be able to handle the increased traffic load or whether we need to upgrade the routers as well. The information we have managed to find so far suggests that these routers would be able to cope if all packet switching is done in CEF. The set-up in these remote sites is quite simple and we only use extended IP access lists in order to control access to certain VLANs. Does anybody know whether these ACLs would cause the traffic to be punted from CEF to process switching? Many thanks Terence ___ 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] IPv6 Stateful IOS Firewall
If anyone is interested I've been building an IPv6 specific router config/template for routing and security. I've been trying to work with the team Cymru but progress is slow. Looking for collaborators Ping me offline if interested. -Hammer- I was a normal American nerd -Jack Herer On 07/13/2011 03:57 AM, David Freedman wrote: According to the documentation at http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-sec_trfltr _fw_ps10592_TSD_Products_Configuration_Guide_Chapter.html The following should suffice as a simple stateful IPv6 firewall (no reflection or zoning): ! ipv6 unicast-routing ipv6 cef ipv6 inspect udp idle-time 120 ipv6 inspect tcp max-incomplete host 250 block-time 0 ipv6 inspect name cbac-ipv6 tcp ipv6 inspect name cbac-ipv6 udp ipv6 inspect name cbac-ipv6 icmp ipv6 inspect name cbac-ipv6 ftp ! int X/Y desc WAN ipv6 enable ipv6 traffic-filter ipv6-internet-in in ipv6 inspect cbac-ipv6 out ! ipv6 access-list ipv6-internet-in permit icmp fe80::/64 any nd-na permit icmp fe80::/64 any nd-ns deny ipv6 any any log ! However, this results in some odd behaviour, when debug ipv6 inspect detailed is enabled and traffic is sent through the firewall, the following message is logged for every packet : Jul 13 09:54:14 BST: FIREWALL: acl or insp_list not found Can somebody tell me what I'm missing? #sh ver | in UNIV Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.0(1)M2, RELEASE SOFTWARE (fc2) #sh lic Index 1 Feature: ipbasek9 Period left: Life time License Type: Permanent License State: Active, In Use License Count: Non-Counted License Priority: Medium Index 2 Feature: securityk9 Period left: Life time License Type: Permanent License State: Active, In Use License Count: Non-Counted License Priority: Medium Index 3 Feature: datak9 Period left: 8 weeks 4 days License Type: Evaluation License State: Active, Not in Use, EULA not accepted License Count: Non-Counted License Priority: None Index 4 Feature: SSL_VPN Period left: 8 weeks 4 days License Type: Evaluation License State: Active, Not in Use, EULA not accepted License Count: 75/0/0 (Active/In-use/Violation) License Priority: None Index 5 Feature: ios-ips-update Thanks in advance Dave. ___ 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] Cat4500 High CPU with Multicast Stream
Unfortunately the 4500 doesn't have the mls options you mentioned. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Alexander Clouter Sent: quarta-feira, 13 de Julho de 2011 13:59 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cat4500 High CPU with Multicast Stream Antonio Soares amsoa...@netcabo.pt wrote: I have a customer with a few 3560/3750's and one 4500/SUP5 acting as the core switch. For some reason, when a user start one multicast stream, the 4500 suffers high cpu utilization and the network is affected. Only the 4500 suffers of this problem, the 3560/3750's don't have any complaints. I see that the 4500 is a CEF based platform and I know that IP Multicast is not supported in the CEF path. So I was expecting to have this traffic switched in hardware or fast-switched. But a packet capture shows me that the traffic goes to the cpu. I used this debug and output to confirm this: debug platform packet all receive buffer show platform cpu packet buffered The processes that eat most of the cpu are Cat4k Mgmt LoPri and Cat4k Mgmt HiPri. We thought this could be a bug and we upgraded the 4500 to the latest release but the problem is exactly the same. The multicast stream is processed by the cpu. Anyone has seen this before ? Is this normal behavior of the 4500 ? Usually the multicast streams are destined to 224.x.x.x. The end users do not respect the 239 rule. Sounds like the following might help: http://www.gossamer-threads.com/lists/cisco/nsp/128799?do=post_view_threaded It's the following lines you might need: mls rate-limit multicast ipv4 non-rpf 100 10 mls rate-limit multicast ipv4 partial 250 100 Or something similar to them. Cheers -- Alexander Clouter .sigmonster says: I'm not tense, just terribly, terribly alert! ___ 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] Cat4500 High CPU with Multicast Stream
I have the same CPU problem but on a 3750. How would I add a similar rate-limit for our ghost traffic? That command does not work on 12.2(52)SE. Thank you, Christina Message: 9 Date: Wed, 13 Jul 2011 13:59:28 +0100 From: Alexander Clouter a...@digriz.org.uk To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cat4500 High CPU with Multicast Stream Message-ID: geh0f8-ujm@chipmunk.wormnet.eu Antonio Soares amsoa...@netcabo.pt wrote: I have a customer with a few 3560/3750's and one 4500/SUP5 acting as the core switch. For some reason, when a user start one multicast stream, the 4500 suffers high cpu utilization and the network is affected. Only the 4500 suffers of this problem, the 3560/3750's don't have any complaints. I see that the 4500 is a CEF based platform and I know that IP Multicast is not supported in the CEF path. So I was expecting to have this traffic switched in hardware or fast-switched. But a packet capture shows me that the traffic goes to the cpu. I used this debug and output to confirm this: debug platform packet all receive buffer show platform cpu packet buffered The processes that eat most of the cpu are Cat4k Mgmt LoPri and Cat4k Mgmt HiPri. We thought this could be a bug and we upgraded the 4500 to the latest release but the problem is exactly the same. The multicast stream is processed by the cpu. Anyone has seen this before ? Is this normal behavior of the 4500 ? Usually the multicast streams are destined to 224.x.x.x. The end users do not respect the 239 rule. Sounds like the following might help: http://www.gossamer-threads.com/lists/cisco/nsp/128799?do=post_view_threaded It's the following lines you might need: mls rate-limit multicast ipv4 non-rpf 100 10 mls rate-limit multicast ipv4 partial 250 100 Or something similar to them. Cheers -- Alexander Clouter .sigmonster says: I'm not tense, just terribly, terribly alert! ___ 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] Routing based on traffic type question
Hi, This is a new one for me and wanted to get some pointers / possible config examples. We have a branch office that is presently being fed back to a pop via single T1 which is about as vanilla as can be expected. It’s a simple connected /30 with a few /29 blocks routed for the inside interfaces. On my end is a Cisco 7206VXR with a channelized DS3 which receives the circuit and I have full access to this device to make changes as needed. The branch office is being upgraded to a wireless connection which will attach to a different segment on the same router and we will be migrating their routed blocks to the new connection as you’d expect using entirely static routing. The issue is we’d like to leave the T1 in place and simply use that for VOIP traffic while leaving the rest of the traffic to traverse the wireless link. How would I split the two effectively? I have definite destinations for all their VOIP traffic which are also on my network so there are specific soft switches that the branch uses. Is this a case for policy based routing? Does anyone have anything like this in place that they could provide some snippets to give me a starting point. Any pointers would be appreciated. Is this even possible? Thank you Scott ___ 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] Cat4500 High CPU with Multicast Stream
It seems I need some sort of CoPP protection. I found a very nice document: Infrastructure Protection on Cisco Catalyst 6500 and 4500 Series Switches http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a0080825564.pdf I'm now reading the section CoPP on Catalyst 4500. Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: Peter Rathlev [mailto:pe...@rathlev.dk] Sent: quarta-feira, 13 de Julho de 2011 14:20 To: Antonio Soares Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cat4500 High CPU with Multicast Stream On Wed, 2011-07-13 at 12:59 +0100, Antonio Soares wrote: Usually the multicast streams are destined to 224.x.x.x. The end users do not respect the 239 rule. Beware that traffic to 224.0.0.0/24 (Local Network Control Block) is _always_ process switched and will never be blocked by any switch. As long as these addresses are used the traffic will be punted. I could imagine that the LNCB addresses were used exactly because they're always forwarded. They might have tried using 239-addresses (Organization-Local Scope) but maybe couldn't get it to work. Typically Cisco access switches are running IGMP Snooping, and will not forward multicast traffic without either an IGMP Snooping Querier or a PIM enabled device on the VLAN (unless it's LNCB). If all traffic is intra-VLAN you could just add ip igmp snooping querier to the relevant SVI and move the clients to 239.x.y.z addresses. You could also block traffic to these multicast addresses on the SVIs with (hardware) ACLs. Beware that OSPF, HSRP et cetera actually use LNCB addresses, and it's probably not smart to block these. -- Peter ___ 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] sup2T software release notes have hit
On 07/13/2011 03:46 PM, Mark Tinka wrote: On Wednesday, July 13, 2011 04:45:43 PM Phil Mayers wrote: Cisco seem to have a real blindspot for 10G transceivers. The explanation back in the day was that Cisco had a lot of customers wanting to run 10gig over old multimode fibre, and thus needed the LX4 transceiver which required a physically bigger housing to fit all the bits into. I wonder if that's still their reasoning for X2? We run multi-mode 10Gbps on XFP on Juniper's quite happily Specifically LX4 transceivers? ___ 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] Cat4500 High CPU with Multicast Stream
It seems I found an explanation: http://www.ryanhicks.net/blog/2008/12/cisco-4500-intermittant-high-cpu-utilization---part-2.html The 4500 is capable of handling much higher volumes of multicast traffic, and it has distributed hardware processing of multicast. It turns out that the 224.0.0.0/24 range is reserved for L2 local multicast, such as routing protocols, All routers, All hosts, etc. Because of this fact, the 4500 was designed to send all multicast traffic destined to any address in this range directly to the CPU weather it was needed/subscribed, or not. I think an inbound 224.0.0.0/24 multicast filter should be considered a basic security requirement for every network in order to prevent inadvertant or intentional DoS against the switched infrastructure regardless of weather multicast is officially in use on the network! Now my question, is this limitation specific to the 4500's ? Or does it mean that we can bring down any catalyst network with a good multicast stream ??? This is scaring... Guys, what methods do you use to control this ? Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: Antonio Soares [mailto:amsoa...@netcabo.pt] Sent: quarta-feira, 13 de Julho de 2011 15:54 To: 'Peter Rathlev'; 'Alexander Clouter' Cc: 'cisco-nsp@puck.nether.net' Subject: RE: [c-nsp] Cat4500 High CPU with Multicast Stream It seems I need some sort of CoPP protection. I found a very nice document: Infrastructure Protection on Cisco Catalyst 6500 and 4500 Series Switches http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a0080825564.pdf I'm now reading the section CoPP on Catalyst 4500. Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: Peter Rathlev [mailto:pe...@rathlev.dk] Sent: quarta-feira, 13 de Julho de 2011 14:20 To: Antonio Soares Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cat4500 High CPU with Multicast Stream On Wed, 2011-07-13 at 12:59 +0100, Antonio Soares wrote: Usually the multicast streams are destined to 224.x.x.x. The end users do not respect the 239 rule. Beware that traffic to 224.0.0.0/24 (Local Network Control Block) is _always_ process switched and will never be blocked by any switch. As long as these addresses are used the traffic will be punted. I could imagine that the LNCB addresses were used exactly because they're always forwarded. They might have tried using 239-addresses (Organization-Local Scope) but maybe couldn't get it to work. Typically Cisco access switches are running IGMP Snooping, and will not forward multicast traffic without either an IGMP Snooping Querier or a PIM enabled device on the VLAN (unless it's LNCB). If all traffic is intra-VLAN you could just add ip igmp snooping querier to the relevant SVI and move the clients to 239.x.y.z addresses. You could also block traffic to these multicast addresses on the SVIs with (hardware) ACLs. Beware that OSPF, HSRP et cetera actually use LNCB addresses, and it's probably not smart to block these. -- Peter ___ 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] Routing based on traffic type question
Scott, Yes, policy routing will work, using it to off-load http and other non time sensitive traffic for a customer. Using static object tracking to avoid black-holing towards a dead next hop. Chuck On Jul 13, 2011 10:54 AM, Scott Granados sc...@granados-llc.net wrote: Hi, This is a new one for me and wanted to get some pointers / possible config examples. We have a branch office that is presently being fed back to a pop via single T1 which is about as vanilla as can be expected. It’s a simple connected /30 with a few /29 blocks routed for the inside interfaces. On my end is a Cisco 7206VXR with a channelized DS3 which receives the circuit and I have full access to this device to make changes as needed. The branch office is being upgraded to a wireless connection which will attach to a different segment on the same router and we will be migrating their routed blocks to the new connection as you’d expect using entirely static routing. The issue is we’d like to leave the T1 in place and simply use that for VOIP traffic while leaving the rest of the traffic to traverse the wireless link. How would I split the two effectively? I have definite destinations for all their VOIP traffic which are also on my network so there are specific soft switches that the branch uses. Is this a case for policy based routing? Does anyone have anything like this in place that they could provide some snippets to give me a starting point. Any pointers would be appreciated. Is this even possible? Thank you Scott ___ 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] Cat4500 High CPU with Multicast Stream
On Wed, 2011-07-13 at 16:03 +0100, Antonio Soares wrote: It seems I found an explanation: http://www.ryanhicks.net/blog/2008/12/cisco-4500-intermittant-high-cpu-utilization---part-2.html ... Now my question, is this limitation specific to the 4500's ? Or does it mean that we can bring down any catalyst network with a good multicast stream ??? I think any Cisco device, maybe any router/switch of any brand, would always receive 224.0.0.0/24. Otherwise a lot of things wouldn't work out of the box, e.g. HSRP, OSPF, PIM et cetera. It's at least also a limitation of 6500/7600 switches. The 6500/7600 can't handle multicast traffic in hardware CoPP by the way. (I don't know about the 4500, but it seems it can.) Software CoPP is better than nothing, but it's still possible to cause problems from a regular workstation. ACL filtering as close to the edge as possible is the only real solution. -- Peter ___ 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] sup2T software release notes have hit
On 13/07/2011 15:56, Mark Tinka wrote: Part number: FTLX8511D3-CS Serial number: FNS14510S11 the FTLX8511D3 is an SR transceiver, not an LR4. The electrical interface on an SR transceiver is 10G, not 4 x 3.125G, i.e. no serdes required. Juniper have this one locked down. I never have to wonder whether an optical module on any Juniper router will work on any Juniper switch, even though the different platforms may have different product names for the same optical module. It just works. To be completely fair on vendors, transceiver compatibility is a bit of a nightmare. For an equivalent sort of comparison, I have heard it said that it's a bit like an IDE driver or a SATA driver in some respects - the basic instruction set is relatively simple, but according as you support more devices, you end up with more device-quirks management in your code than actual driver code. Nick ___ 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] sup2T software release notes have hit
On Wednesday, July 13, 2011 04:45:43 PM Phil Mayers wrote: Cisco seem to have a real blindspot for 10G transceivers. The explanation back in the day was that Cisco had a lot of customers wanting to run 10gig over old multimode fibre, and thus needed the LX4 transceiver which required a physically bigger housing to fit all the bits into. I wonder if that's still their reasoning for X2? We run multi-mode 10Gbps on XFP on Juniper's quite happily :-). Mark. signature.asc Description: This is a digitally signed message part. ___ 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] sup2T software release notes have hit
On Wednesday, July 13, 2011 07:20:15 PM Nick Hilliard wrote: Maybe some cisco designers just like X2? Maybe Cisco have lots of experience with X2 and the architectural move to XFI interfaces would mean board redesigns? Difficult to tell really. I have to say that as a customer, I view X2 as a serious barrier to buying certain types of cisco kit, and am frankly astounded that they are still pushing out new board designs which use this format. Bizarre. Interestingly, our ASR9010's ship with and use XFP's for multi-mode just fine: #sh controllers TenGigE0/0/0/0 Wed Jul 13 22:49:35.019 MYT Operational data for interface TenGigE0/0/0/0: snip ... Phy: Media type: R fiber over 850nm optics Optics: Vendor: CISCO-FINISAR Part number: FTLX8511D3-CS Serial number: FNS14510S11 snip ... # Works like a charm. Why the 6500 is still encumbered with X2 or XENPAK is beyond me. I think this just reinforces how Cisco really have no harmony for some of these tiny but important details. When it comes to optical modules or interfaces, every BU seems to play their own game. Even the Nexus 7000 BU seem to have embraced SFP+, but they do still have some X2 line cards as well. Juniper have this one locked down. I never have to wonder whether an optical module on any Juniper router will work on any Juniper switch, even though the different platforms may have different product names for the same optical module. It just works. Mark. signature.asc Description: This is a digitally signed message part. ___ 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] Cat4500 High CPU with Multicast Stream
On 07/13/2011 04:03 PM, Antonio Soares wrote: Now my question, is this limitation specific to the 4500's ? Or does it mean that we can bring down any catalyst network with a good multicast stream ??? High traffic to 224.0.0.0/24 breaks a *lot* of kit. It's not just Cisco or Catalyst. Applications emitting lots of traffic to this range should be considered no different to applications emitting lots of traffic to the broadcast address; they're broken and should be disconnected from the network. This is scaring... Guys, what methods do you use to control this ? Disciplinary procedures. ___ 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] sup2T software release notes have hit
On Wednesday, July 13, 2011 10:59:03 PM Phil Mayers wrote: Specifically LX4 transceivers? No, SR. Sorry, thought the issue was multi-mode support itself, not the need for an LX4 transceiver. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ 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] sup2T software release notes have hit
On Wednesday, July 13, 2011 11:17:57 PM Nick Hilliard wrote: the FTLX8511D3 is an SR transceiver, not an LR4. The electrical interface on an SR transceiver is 10G, not 4 x 3.125G, i.e. no serdes required. Yes, fair point. Thought the issue was just about needing multi-mode for 10Gbps, not the specific LX4 transceiver. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ 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] Cat4500 High CPU with Multicast Stream
Thanks, I'm feeling better now :) So in my case, one 4500 with ip routing enabled and ip multicast-routing disabled, what could be simple and quick to implement ? I'm think about storm-control multicast in all ports (all ports are .1q trunks in this case). The 4500 is the L2 aggregator and first hop router. Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers Sent: quarta-feira, 13 de Julho de 2011 16:34 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cat4500 High CPU with Multicast Stream On 07/13/2011 04:03 PM, Antonio Soares wrote: Now my question, is this limitation specific to the 4500's ? Or does it mean that we can bring down any catalyst network with a good multicast stream ??? High traffic to 224.0.0.0/24 breaks a *lot* of kit. It's not just Cisco or Catalyst. Applications emitting lots of traffic to this range should be considered no different to applications emitting lots of traffic to the broadcast address; they're broken and should be disconnected from the network. This is scaring... Guys, what methods do you use to control this ? Disciplinary procedures. ___ 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] IP GRE tunnel up/down
Howdy, I am trying to establish a GRE/IP tunnel over the Internet: interface Tunnel1 description GRE-Tunnel ip unnumbered GigabitEthernet7/0/0 no ip directed-broadcast tunnel source Loopback1 tunnel destination x.x.x.x end Pretty much no matter what I do the interface status is always: Tunnel1 is up, line protocol is down I've read that tunnels should be up/up unless you are using keepalives and it detects a failure. Does anyone have any insight they can share on this? thanks, -Drew ___ 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] Cat4500 High CPU with Multicast Stream
On 07/13/2011 04:46 PM, Antonio Soares wrote: Thanks, I'm feeling better now :) So in my case, one 4500 with ip routing enabled and ip multicast-routing disabled, what could be simple and quick to implement ? I'm not familiar with Cat4500 I'm afraid. On a 6500 I would do this: ip access-list standard DENY_MULTI deny 224.0.0.0 15.255.255.255 int VlanXXX ip multicast boundary DENY_MULTI ...it might work on that platform. As others have pointed out, some legitimate traffic uses 224.0.0.0/24 e.g. HSRP, VRRP, PIM, OSPF, etc. so be careful with this. Or use a plain access list on the ethernet port. ___ 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] sup2T software release notes have hit
On 07/13/2011 04:34 PM, Mark Tinka wrote: On Wednesday, July 13, 2011 10:59:03 PM Phil Mayers wrote: Specifically LX4 transceivers? No, SR. Sorry, thought the issue was multi-mode support itself, not the need for an LX4 transceiver. AIUI, Cisco has (or believes it has) a lot of customers with crappy old multimode that they can't replace, and is over-length for traditional 10gig transceivers. Hence the LX4, which gives you (marginally) better range than other 10gig multimode transceivers, but needs room for the built-in CWDM - therefore we end up with enterprise kit using the bigger Xenpak/X2 form-factor. ___ 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] IP GRE tunnel up/down
On Wed, 2011-07-13 at 11:19 -0400, Drew Weaver wrote: Pretty much no matter what I do the interface status is always: Tunnel1 is up, line protocol is down I've read that tunnels should be up/up unless you are using keepalives and it detects a failure. Is the destination reachable? I.e. what does show ip route destination IP address tell you? An unreachable destination would result in up/down. What platform/software are you using? And what's the complete output of show interface Tunnel1? -- Peter ___ 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] Cat4500 High CPU with Multicast Stream
I will be applying CoPP today: http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/50sg/configur ation/guide/cntl_pln.html Something like: Switch(config)# qos Switch(config)# macro global apply system-cpp Switch(config)# policy-map system-cpp-policy Switch(config-pmap)# class system-cpp-ip-mcast-linklocal Switch(config-pmap-c)# police 32000 1000 conform-action transmit exceed-action drop Switch(config-pmap-c)# end I will let you know if it works as expected. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: Phil Mayers [mailto:p.may...@imperial.ac.uk] Sent: quarta-feira, 13 de Julho de 2011 16:53 To: Antonio Soares Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cat4500 High CPU with Multicast Stream On 07/13/2011 04:46 PM, Antonio Soares wrote: Thanks, I'm feeling better now :) So in my case, one 4500 with ip routing enabled and ip multicast-routing disabled, what could be simple and quick to implement ? I'm not familiar with Cat4500 I'm afraid. On a 6500 I would do this: ip access-list standard DENY_MULTI deny 224.0.0.0 15.255.255.255 int VlanXXX ip multicast boundary DENY_MULTI ...it might work on that platform. As others have pointed out, some legitimate traffic uses 224.0.0.0/24 e.g. HSRP, VRRP, PIM, OSPF, etc. so be careful with this. Or use a plain access list on the ethernet port. ___ 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] Routing based on traffic type question
Hi, thanks, I thought that was heading in the right direction. So I found this example here... http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfpbr_ps1835_TSD_Products_Configuration_Guide_Chapter.html In this example, they use only simple access lists matching an individual IP address and setting some bits. Instead of a simple IP acl can I use something more complex where it say matches on a type of service bit or given port and acts else forwards normally or is a full IP at /32 length as granular as I can get? The example they provide seems simple but not sure what will happen if I define my acl more granular. Will any accept ACL expressions work or what’s my limiter the doc is a little confusing. Thanks and thanks for the pointer, I really appreciate it. Scott From: Chuck Church Sent: Wednesday, July 13, 2011 11:21 AM To: Scott Granados Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Routing based on traffic type question Scott, Yes, policy routing will work, using it to off-load http and other non time sensitive traffic for a customer. Using static object tracking to avoid black-holing towards a dead next hop. Chuck On Jul 13, 2011 10:54 AM, Scott Granados sc...@granados-llc.net wrote: Hi, This is a new one for me and wanted to get some pointers / possible config examples. We have a branch office that is presently being fed back to a pop via single T1 which is about as vanilla as can be expected. It’s a simple connected /30 with a few /29 blocks routed for the inside interfaces. On my end is a Cisco 7206VXR with a channelized DS3 which receives the circuit and I have full access to this device to make changes as needed. The branch office is being upgraded to a wireless connection which will attach to a different segment on the same router and we will be migrating their routed blocks to the new connection as you’d expect using entirely static routing. The issue is we’d like to leave the T1 in place and simply use that for VOIP traffic while leaving the rest of the traffic to traverse the wireless link. How would I split the two effectively? I have definite destinations for all their VOIP traffic which are also on my network so there are specific soft switches that the branch uses. Is this a case for policy based routing? Does anyone have anything like this in place that they could provide some snippets to give me a starting point. Any pointers would be appreciated. Is this even possible? Thank you Scott ___ 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] IP GRE tunnel up/down
If it cannot make the original connection it will show up/down Can you route from the source to the tunnel destination and are there any firewalls that would block the GRE protocol? Can the destination route back to the source loopback1? -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Drew Weaver Sent: Wednesday, July 13, 2011 11:20 AM To: cisco-nsp Subject: [c-nsp] IP GRE tunnel up/down Howdy, I am trying to establish a GRE/IP tunnel over the Internet: interface Tunnel1 description GRE-Tunnel ip unnumbered GigabitEthernet7/0/0 no ip directed-broadcast tunnel source Loopback1 tunnel destination x.x.x.x end Pretty much no matter what I do the interface status is always: Tunnel1 is up, line protocol is down I've read that tunnels should be up/up unless you are using keepalives and it detects a failure. Does anyone have any insight they can share on this? thanks, -Drew ___ 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] 7600 SUP32 support VPDN?
Hi experts, Does that 7604 with SUP32 support Broadband users? If yes what image would support that? I feed up from searching the command vpdn enable? Regards, Amin ___ 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] Suspect MTU Issues
2011/7/13 Gert Doering g...@greenie.muc.de Hi, On Wed, Jul 13, 2011 at 09:38:56AM -0400, Keegan Holley wrote: You have an MTU problem. If you want to send (1500 byte + extra header bytes) packets over a link with a MTU of 1500 - FAIL. It's actually going to be 1500 - header sizes. So 1500 - MPLS (4bytes) = 1496 possibly - IPSEC (20 Bytes) = 1476 The input packet is 1500 bytes (+ethernet headers, not counted on IOS MTU settings), you tack 4 byte MPLS on it - your egress packet is 1504 (+ethernet header). So if your intermediate switches only allow 1500, you have a FAIL. I just wanted to show that 1500 bytes is too big as is 1499, 1498, and 1497, which was also part of the original question. Also, that it get's worse with IPsec or other protocols that would add headers such as tunneled IPv6. We are ultimately saying the same thing. It's not good to run MPLS with the MTU set to 1500. ___ 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] IP GRE tunnel up/down
Hi, On Wed, Jul 13, 2011 at 12:20:17PM -0400, Matthew Huff wrote: If it cannot make the original connection it will show up/down There is no connection to be made for a GRE tunnel. Can you route from the source to the tunnel destination and are there any firewalls that would block the GRE protocol? Can the destination route back to the source loopback1? All not relevant, unless tunnel keepalive is active. Normally, the tunnel is down if either source or destination IP are not set (like loopback1 has no IP) or if there is no route to the destination IP address. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpp3nbD5CKLz.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] redundancy via VPN
I would like to add some redundancy to our network. we currently have a MAN connection between two sites. Each site also has internet connectivity with other providers (not our MAN provider). Which is the better way to add redundancy over those internet connections: GetVPN, or DMVPN using GRE or is there a better option yet? TIA Scott ___ 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] IP GRE tunnel up/down
Can you route from the source to the tunnel destination and are there any firewalls that would block the GRE protocol? Can the destination route back to the source loopback1? All not relevant, unless tunnel keepalive is active. Normally, the tunnel is down if either source or destination IP are not set (like loopback1 has no IP) or if there is no route to the destination IP address. Yes - or -imho- if the platform does not support it like a GSR without a tunnel server card. -Sascha ___ 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] 7206VXR 23-inch rack brackets?
My Google-fu is failing me, or such items are made of unobtanium. Does Cisco make a rack-mount kit for 7200 routers going into 23-inch telco racks? If so can someone provide a part number? If not, I can use aftermarket filler brackets but I would prefer the cleaner installation of stock brackets. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ 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] 7206VXR 23-inch rack brackets?
The only reference I've found is here: http://www.cisco.com/en/US/products/hw/routers/ps341/prod_technical_refe rence09186a0080092120.html It refers to a third-party manufacturer (Newton Instrument, P/N 2079590331). However, the document is old and searching the manufacturer's site for it doesn't return anything. You might be able to call them and see if they still manufacture/carry this part. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jay Hennigan Sent: Wednesday, July 13, 2011 3:02 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] 7206VXR 23-inch rack brackets? My Google-fu is failing me, or such items are made of unobtanium. Does Cisco make a rack-mount kit for 7200 routers going into 23-inch telco racks? If so can someone provide a part number? If not, I can use aftermarket filler brackets but I would prefer the cleaner installation of stock brackets. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ 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] 7206VXR 23-inch rack brackets?
On Wed, 13 Jul 2011, Jay Hennigan wrote: Does Cisco make a rack-mount kit for 7200 routers going into 23-inch telco racks? If so can someone provide a part number? If not, I can use aftermarket filler brackets but I would prefer the cleaner installation of stock brackets. Never seen them. We've always used the 19-23 spacers for the 7206's when going into 23 racks. -- Jon Lewis, MCP :) | 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] IP GRE tunnel up/down
Hi, On Wed, Jul 13, 2011 at 08:19:54PM +0200, Sascha Pollok wrote: Yes - or -imho- if the platform does not support it like a GSR without a tunnel server card. Oh, good point. We don't have any of these funny platforms... *duck* gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgp66wUeJ6NgM.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cat4500 High CPU with Multicast Stream
What is the address range used by ghost ? I've heard that ghost can kill a network. But if it not using the 224.0.0.0/24 range and you have at least ip igmp snooping on every switch, I don't see how this could affect the network. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Christina Klam Sent: quarta-feira, 13 de Julho de 2011 15:11 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cat4500 High CPU with Multicast Stream I have the same CPU problem but on a 3750. How would I add a similar rate-limit for our ghost traffic? That command does not work on 12.2(52)SE. Thank you, Christina Message: 9 Date: Wed, 13 Jul 2011 13:59:28 +0100 From: Alexander Clouter a...@digriz.org.uk To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cat4500 High CPU with Multicast Stream Message-ID: geh0f8-ujm@chipmunk.wormnet.eu Antonio Soares amsoa...@netcabo.pt wrote: I have a customer with a few 3560/3750's and one 4500/SUP5 acting as the core switch. For some reason, when a user start one multicast stream, the 4500 suffers high cpu utilization and the network is affected. Only the 4500 suffers of this problem, the 3560/3750's don't have any complaints. I see that the 4500 is a CEF based platform and I know that IP Multicast is not supported in the CEF path. So I was expecting to have this traffic switched in hardware or fast-switched. But a packet capture shows me that the traffic goes to the cpu. I used this debug and output to confirm this: debug platform packet all receive buffer show platform cpu packet buffered The processes that eat most of the cpu are Cat4k Mgmt LoPri and Cat4k Mgmt HiPri. We thought this could be a bug and we upgraded the 4500 to the latest release but the problem is exactly the same. The multicast stream is processed by the cpu. Anyone has seen this before ? Is this normal behavior of the 4500 ? Usually the multicast streams are destined to 224.x.x.x. The end users do not respect the 239 rule. Sounds like the following might help: http://www.gossamer-threads.com/lists/cisco/nsp/128799?do=post_view_threaded It's the following lines you might need: mls rate-limit multicast ipv4 non-rpf 100 10 mls rate-limit multicast ipv4 partial 250 100 Or something similar to them. Cheers -- Alexander Clouter .sigmonster says: I'm not tense, just terribly, terribly alert! ___ 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] Suspect MTU Issues
This discussion brings me neatly onto my follow on question then:- On the ME3600X switches they will allow me to set interface mtu of up to 9800 bytes. Some of my team are arguing that we only need 1548, some are saying 1600. We've got dark fibre, so should we be going for the maximum mtu size possible on the box (taking into account max mtu of the box it plugs into), or is there a good all rounder for mtu size? What mtu will cause me the least pain in years to come? Thanks for all of the valuable insight so far. Leigh Sent from my iPhone - apologies for any spelling or grammar mistakes On 13 Jul 2011, at 18:57, Keegan Holley keegan.hol...@sungard.com wrote: 2011/7/13 Gert Doering g...@greenie.muc.de Hi, On Wed, Jul 13, 2011 at 09:38:56AM -0400, Keegan Holley wrote: You have an MTU problem. If you want to send (1500 byte + extra header bytes) packets over a link with a MTU of 1500 - FAIL. It's actually going to be 1500 - header sizes. So 1500 - MPLS (4bytes) = 1496 possibly - IPSEC (20 Bytes) = 1476 The input packet is 1500 bytes (+ethernet headers, not counted on IOS MTU settings), you tack 4 byte MPLS on it - your egress packet is 1504 (+ethernet header). So if your intermediate switches only allow 1500, you have a FAIL. I just wanted to show that 1500 bytes is too big as is 1499, 1498, and 1497, which was also part of the original question. Also, that it get's worse with IPsec or other protocols that would add headers such as tunneled IPv6. We are ultimately saying the same thing. It's not good to run MPLS with the MTU set to 1500. ___ 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/ This email has been scanned by Webroot for the presence of known Viruses and Spam. ___ 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] Suspect MTU Issues
That depends on your use. Some technologies such as certain types of storage replication perform better without jumbo frames. Some won't even use them. Generally speaking the maximum supported by all of your devices would be the best thing to configure as long as it doesn't break some other application. 2011/7/13 Leigh Harrison lharri...@convergencegroup.co.uk This discussion brings me neatly onto my follow on question then:- On the ME3600X switches they will allow me to set interface mtu of up to 9800 bytes. Some of my team are arguing that we only need 1548, some are saying 1600. We've got dark fibre, so should we be going for the maximum mtu size possible on the box (taking into account max mtu of the box it plugs into), or is there a good all rounder for mtu size? What mtu will cause me the least pain in years to come? Thanks for all of the valuable insight so far. Leigh Sent from my iPhone - apologies for any spelling or grammar mistakes On 13 Jul 2011, at 18:57, Keegan Holley keegan.hol...@sungard.com wrote: 2011/7/13 Gert Doering g...@greenie.muc.de Hi, On Wed, Jul 13, 2011 at 09:38:56AM -0400, Keegan Holley wrote: You have an MTU problem. If you want to send (1500 byte + extra header bytes) packets over a link with a MTU of 1500 - FAIL. It's actually going to be 1500 - header sizes. So 1500 - MPLS (4bytes) = 1496 possibly - IPSEC (20 Bytes) = 1476 The input packet is 1500 bytes (+ethernet headers, not counted on IOS MTU settings), you tack 4 byte MPLS on it - your egress packet is 1504 (+ethernet header). So if your intermediate switches only allow 1500, you have a FAIL. I just wanted to show that 1500 bytes is too big as is 1499, 1498, and 1497, which was also part of the original question. Also, that it get's worse with IPsec or other protocols that would add headers such as tunneled IPv6. We are ultimately saying the same thing. It's not good to run MPLS with the MTU set to 1500. ___ 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/ This email has been scanned by Webroot for the presence of known Viruses and Spam. ___ 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] UDLD misbehaviour
Hello my friends, I had some problems on an optical fibre between two 6509 switches and UDLD kicked in to avoid STP loops, but when the switch tried to recover from the error-disable state, the link went up, even with optical fibre problems. This misbehaviour caused a major outage in the network. I couldn't find any known bug for the current IOS version 12.2(33)SXI3. I worked around the issue keeping the interface in a shutdown state until I resolved the cabling issue. Can someone shed some light on the solution? 09:20:24.737: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet2/4/10, changed state to down 09:20:24.757: %LINK-3-UPDOWN: Interface TenGigabitEthernet2/4/10, changed state to down 09:20:24.994: %PM-SW2_SPSTBY-4-ERR_DISABLE: udld error detected on Te2/4/10, putting Te2/4/10 in err-disable state 09:20:24.710: %UDLD-SW1_SP-4-UDLD_PORT_DISABLED: UDLD disabled interface Te2/4/10, aggressive mode failure detected 09:20:24.710: %PM-SW1_SP-4-ERR_DISABLE: udld error detected on Te2/4/10, putting Te2/4/10 in err-disable state 09:20:25.203: %LINEPROTO-SW1_SP-5-UPDOWN: Line protocol on Interface TenGigabitEthernet2/4/10, changed state to down 09:20:25.203: %LINK-SW1_SP-3-UPDOWN: Interface TenGigabitEthernet2/4/10, changed state to down 09:20:55.004: %PM-SW1_SP-4-ERR_RECOVER: Attempting to recover from udld err-disable state on Te2/4/10 09:20:55.119: %PM-SW2_SPSTBY-4-ERR_RECOVER: Attempting to recover from udld err-disable state on Te2/4/10 09:20:56.362: %LINK-3-UPDOWN: Interface TenGigabitEthernet2/4/10, changed state to up 09:20:56.333: %LINK-SW1_SP-3-UPDOWN: Interface TenGigabitEthernet2/4/10, changed state to up I will really appreciate any input. Cheers. ___ 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] redundancy via VPN
On Wed, 13 Jul 2011, Scott Voll wrote: I would like to add some redundancy to our network. we currently have a MAN connection between two sites. Each site also has internet connectivity with other providers (not our MAN provider). Which is the better way to add redundancy over those internet connections: GetVPN, or DMVPN using GRE or is there a better option yet? TIA Scott ___ If your topology is simple enough, and the set of routes manageable / nicely aggregated - why not just a VPN that will get used by virtue of following the default route ? In other words, assuming OSPF/BGP/BFD-static etc on the MAN connection - when that goes away, the more specific to the other site is gone. Assuming default flows toward the internet devices, if they can do VPN, it will get used by virtue of not having the more specific MAN route. For something more complex, I'd look at some kind of dynamic protocol, and using the same one if you can get away with it (i.e. no mutual distribution, filtering, etc). BGP has good knobs to influence this, OSPF/EIGRP would take a tunnel bandwidth into account and should work as well. I've historically also done this with GRE from devices riding an IPSEC tunnel that only encrypted the GRE endpoints. I assume nowadays in IOS with VTI's you can do this more elegantly. On ASA (at least code I've touched) there isn't much at your disposal WRT IPSEC stuff. Not very flexible or dynamic. Other vendors fare differently because you can run OSPF/BGP on their firewalls, and actually have the VPN manifest as an 'interface'. Kill multiple birds with one stone. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 SH1-0151. This is the serial number, of our orbital gun. ___ 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] SUP-2T and ingress netflow + microflows policing
On Wed, Jul 13, 2011 at 11:37 AM, Phil Mayers p.may...@imperial.ac.uk wrote: sh platform hardware capacity netflow ...say? #sh platform hardware capacity netflow Netflow Resources TCAM utilization: Module Created Failed %Used 5 53474 0 20% ICAM utilization: Module Created Failed %Used 5 1 0 0% Flowmasks: Mask# TypeFeatures IPv4: 0 reservednone IPv4: 1 Intf FulIntf NDE L3 Feature IPv4: 2 unused none IPv4: 3 reservednone IPv6: 0 reservednone IPv6: 1 unused none IPv6: 2 unused none IPv6: 3 reservednone Rob ___ 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] Suspect MTU Issues
On 07/13/2011 10:13 PM, Leigh Harrison wrote: This discussion brings me neatly onto my follow on question then:- On the ME3600X switches they will allow me to set interface mtu of up to 9800 bytes. Some of my team are arguing that we only need 1548, some are saying 1600. We've got dark fibre, so should we be going for the maximum mtu size possible on the box (taking into account max mtu of the box it plugs into), or is there a good all rounder for mtu size? What mtu will cause me the least pain in years to come? In an ideal world, you pick the largest value that all your kit can support (e.g. we use 9212 as our untagged ethernet MTU, 9100 as our IP MTU). Too big is not harmful. However, you often find some links can't support that big an MTU, and they end up running e.g. 1530. Provided that path MTU discovery works (so that multihop protocols like iBGP and LDP don't get blackholed) this works OK in my experience, but I've heard of others having problems, so you may feel safer with a consistent, lower value. The important thing is that your network MTU exceeds your payload MTU by at least the transport overhead. Bearing in mind the large diversity of payload MTUs, depending on what services you're running. If for example you are doing EoMPLS of normal 1500-byte ethernet with no or one vlan tag, the payload can be up to 1518 bytes, and the overhead is 2 MPLS labels, giving 1524. OTOH L3VPNs of 1500-byte IP traffic typically need 1508. But in principle other MPLS services like TE can add one or more labels, and of course you may find you need to move jumbos as payload at a later date... ___ 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] UDLD misbehaviour
On Wed, Jul 13, 2011 at 16:15, Leonardo Gama Souza leonardo.so...@nec.com.br wrote: Hello my friends, I had some problems on an optical fibre between two 6509 switches and UDLD kicked in to avoid STP loops, but when the switch tried to recover from the error-disable state, the link went up, even with optical fibre problems. This misbehaviour caused a major outage in the network. I couldn't find any known bug for the current IOS version 12.2(33)SXI3. I worked around the issue keeping the interface in a shutdown state until I resolved the cabling issue. Can someone shed some light on the solution? It looks like UDLD did its job just fine. The trouble is the configuration of errdisable recovery. By default, the switch will not recover any errdisabled port. This causes the port to stay disabled until resolution of the underlying problem, allowing an engineer to resolve before executing a manual bounce of the port. show errdisable recovery will show your current settings. The defaults are all to be disabled and a timer of 300 seconds. Andy ___ 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 Q-in-Q should work in VMWare...
Curious on feedback about this: http://blinking-network.blogspot.com/2011/07/physical-cabling-dependencies-inhibit.html Basically, I think VMWare should support MPLS or Q-in-Q in a meaninful way (no VLAN 4095 hackery). Sadly the Nexus 1000v supports neither (or so I'm told). Even if it or vSwitch did support it, it probably wouldn't work the right way. VLAN differentiation in a multi-tenant environment should not have physical dependencies on the ESX host. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.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] UDLD misbehaviour
I was thinking the same think. Automatic recovery usually is not a good thing. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Andrew Koch Sent: quarta-feira, 13 de Julho de 2011 23:30 To: Leonardo Gama Souza Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] UDLD misbehaviour On Wed, Jul 13, 2011 at 16:15, Leonardo Gama Souza leonardo.so...@nec.com.br wrote: Hello my friends, I had some problems on an optical fibre between two 6509 switches and UDLD kicked in to avoid STP loops, but when the switch tried to recover from the error-disable state, the link went up, even with optical fibre problems. This misbehaviour caused a major outage in the network. I couldn't find any known bug for the current IOS version 12.2(33)SXI3. I worked around the issue keeping the interface in a shutdown state until I resolved the cabling issue. Can someone shed some light on the solution? It looks like UDLD did its job just fine. The trouble is the configuration of errdisable recovery. By default, the switch will not recover any errdisabled port. This causes the port to stay disabled until resolution of the underlying problem, allowing an engineer to resolve before executing a manual bounce of the port. show errdisable recovery will show your current settings. The defaults are all to be disabled and a timer of 300 seconds. Andy ___ 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] Underrun/runt issue on trunk interface between 2 switchs
I readsomething similar to that.. Which is why I tried using a straight access port instead of trunk between both switchs. When I did that I started receiving overruns instead. :( 2011/7/14 Jon Harald Bøvre j...@bovre.no Hi We had similar problems with a 3524XL some years ago. Server connected using ISL, switch trunking using dot1q. Switch strips off ISL header, replace with dot1q. Resulting in runts. Could be somethibg to consider Jon h bøvre Sent from my iPad On 13. juli 2011, at 15:29, Brad Clausen overkil...@gmail.com wrote: Hey Guys, I am having a weird issue between 2 switchs that I hope someone can help out with. One end of the trunk is a cisco WS-C3548-XL running 12.0(5.3)WC(1) code The other end is a ProCurve J9086A Switch 2610-24/12PWR software Version: R.11.25 On the Procurve end I see absolutely nothing in the way of errors. But on the Cisco end I see an excessive amount of runts as per the following: sho int fastEthernet 0/1 FastEthernet0/1 is up, line protocol is up Hardware is Fast Ethernet, address is 0008.2117.b141 (bia 0008.2117.b141) MTU 1500 bytes, BW 10 Kbit, DLY 100 usec, reliability 250/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive not set Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:23, output 00:00:00, output hang never Last clearing of show interface counters 01:31:18 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 5000 bits/sec, 4 packets/sec 5 minute output rate 7000 bits/sec, 7 packets/sec 31492 packets input, 5362556 bytes Received 14259 broadcasts, 3929 runts, 0 giants, 0 throttles 3929 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 2081 multicast 0 input packets with dribble condition detected 41094 packets output, 6605873 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out Relevent config for each port is very basic as per the following: Cisco: interface FastEthernet0/1 duplex full speed 100 switchport trunk encapsulation dot1q switchport mode trunk end HP Procurve: interface 24 speed-duplex 100-full vlan 10 name X-VLAN untagged 13-21,27-28 ip address 10.16.52.245 255.255.255.0 tagged 1-5,22-26 exit I've tried changing the cable between the 2 switchs as well as changing the port on both ends. This didn't make any changes. I then decided to change it from a trunk to an access port on both sides.. When I did this I again saw no errors on the Procurve end of the link. However I then started to see overruns on the Cisco switch as per the following: Hardware is Fast Ethernet, address is 0008.2117.b155 (bia 0008.2117.b155) MTU 1500 bytes, BW 0 Kbit, DLY 0 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive not set Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:02:32, output 00:02:04, output hang never Last clearing of show interface counters 00:07:56 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 1342 packets input, 166570 bytes Received 711 broadcasts, 0 runts, 0 giants, 0 throttles 9 input errors, 9 CRC, 0 frame, 9 overrun, 9 ignored 0 watchdog, 118 multicast 0 input packets with dribble condition detected 990 packets output, 168402 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out This isn't occuring on any other interface on the Cisco switch. Also, it is not occuring on any other switch connecting of the Procurve switch either. Does anyone have any ideas what coulld be causing this? Also worth nothing the input counts above are over only 20 or so minutes. The counters were cleared prior. ___ 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] 7600 SUP32 support VPDN?
Hi Amin, --- On Thu, 14/7/11, ccie c...@axizo.com wrote: Does that 7604 with SUP32 support Broadband users? No. regards, Tony. ___ 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] sup2T software release notes have hit
On Wednesday, July 13, 2011 11:57:10 PM Phil Mayers wrote: AIUI, Cisco has (or believes it has) a lot of customers with crappy old multimode that they can't replace, and is over-length for traditional 10gig transceivers. Hence the LX4, which gives you (marginally) better range than other 10gig multimode transceivers, but needs room for the built-in CWDM - therefore we end up with enterprise kit using the bigger Xenpak/X2 form-factor. Yes, I suppose that's when the LX4 transceiver would come into its own. In our case, we use SR transceivers for all multi-mode runs (50um), which all appear to be spec.'ed for up to 300m, but we've only really run them up to 20m at the most. I'd consider an LX4 transceiver because then it gets you single-mode fibre support. But in our specific environment, we don't have old multi-mode runs, so it's cheaper to just go with SR optics for 850nm, and regular 1310nm and 1550nm optics for single-mode. That said, I do understand that some houses may have old multi-mode fibre which they can't replace, and deploying the LX4 transceiver would be a cheaper option. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ 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] ppp encrypt mppe and cef
Hello, Is MPPE encryption supported in the CEF path? According to cisco doc at http:/www.cisco.com/en/US/docs/ios/12_1t/12_1t5/feature/guide/dt_pptp.html it should, but in my tests all pptp virtual access created with CEF disabled and I can't get more than 10M from 7200-NPE400 with 100% CPU. IOS 12.4(25c). Config is straightforward: vpdn enable ! vpdn-group PPTP ! Default PPTP VPDN group accept-dialin protocol pptp virtual-template 1 ip tos reflect ip pmtu ip mtu adjust ! interface Virtual-Template1 ip unnumbered Loopback0 ip nat inside ip virtual-reassembly timeout 1 ip tcp adjust-mss 1346 no logging event link-status no snmp trap link-status peer default ip address pool HQ-VPN-POOL ppp encrypt mppe auto ppp authentication ms-chap ms-chap-v2 callin ppp ipcp dns 8.8.8.8 8.8.4.4 ppp ipcp wins 192.168.0.110 ! AS3#sh ip int vi5 Virtual-Access5 is up, line protocol is up ... IP fast switching is disabled IP fast switching on the same interface is disabled IP Flow switching is enabled IP CEF switching is disabled ... If I remove ppp encrypt mppe auto line then CEF is enabled OK. Does anybody know if there's a way to run MPPE in the CEF path? Thanks, -- Michael Ulitskiy ___ 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/
