Re: [c-nsp] -48vdc lab power
We ended up placing a small-ish Emerson system in our office with a breaker panel and some telcoflex leads to the bench, really works nicely for testing this stuff and was not super expensive but allows bigger loads (ie ASR 9ks to be powered as well). John -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mike Sent: Thursday, May 22, 2014 11:16 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] -48vdc lab power On 05/22/2014 07:30 AM, Julien Goodwin wrote: On 22/05/14 14:38, Mike wrote: So I have a whole pile of new Cisco ASR1k and ME3600's which are intended for installation in a telco environment and all have -48vdc power supplies. There is a necessary detour however, I need to set these up in my lab environment so I can test configurations and get things as dialed-in as possible in advance of physical installation out at the telco locations. I don't want to buy AC power supplies for all of this just for testing there has to be a suitable -48vdc power system available somewhere that would be suitable to plug into my ac power and have enough juice to run all of this? Does anyone have any recommendations? The magic search term is 48 rectifier (actually -48, but you can't search for that on eBay). Tyco Eltek are two of the common vendors. I presume you've actually confirmed that the sites are native-DC, that's getting increasingly rare. Thanks both you and the previous poster who pointed me in the right direction. In this case, I'm in actual telco central offices and yes they are straight -48vdc all the way, ac is verboten. Mike- ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] interesting ASR 9k bgp multipath issue
so, I have some internally anycasted prefixes (DNS resolvers) as well as bgp maximum paths set to allow both ibgp and ebgp multipath. Oddly, as you can see below the multipath appears to think two paths are identical even when they have different IGP metrics (path #1 and path #2), any idea if this is a bug or how to fix it?Obviously if the IGP cost is the same it should load share, but if not it really should not be doing what is shown below since the paths are not equal. This behavior does not happen on the other cisco platforms we use, they only multipath to destinations that have the same IGP cost or are locally connected via EBGP with the same policy.This is not a huge issue since i can work around it, but it is annoying as it should not be happening. If anyone has ideas of knobs to tweak that would be awesome as my google foo is turning up precious little that is applicable. example route: RP/0/RSP0/CPU0:cr2-sea-b#show bgp ipv4 unicast 208.76.152.9 Sun Mar 30 08:54:24.730 UTC BGP routing table entry for 208.76.152.9/32 Versions: Process bRIB/RIB SendTblVer Speaker 5317470453174704 Last Modified: Mar 30 07:37:05.725 for 01:17:19 Paths: (3 available, best #1) Advertised to update-groups (with more than one peer): 0.1 0.14 Path #1: Received by speaker 0 Advertised to update-groups (with more than one peer): 0.1 0.14 64524, (Received from a RR-client) 208.76.153.79 (metric 16) from 208.76.153.79 (208.76.153.79) Origin incomplete, metric 10, localpref 200, valid, internal, best, group-best, multipath, import-candidate, import suspect Received Path ID 0, Local Path ID 1, version 53174704 Community: 11404:800 Path #2: Received by speaker 0 Not advertised to any peer 64524 208.76.153.79 (metric 16) from 208.76.153.116 (208.76.153.79) Origin incomplete, metric 10, localpref 200, valid, internal, import suspect Received Path ID 0, Local Path ID 0, version 0 Community: 11404:800 Originator: 208.76.153.79, Cluster list: 208.76.153.116 Path #3: Received by speaker 0 Not advertised to any peer 64524 208.76.153.118 (metric 2546) from 208.76.153.118 (208.76.153.118) Origin incomplete, metric 10, localpref 200, valid, internal, multipath, import-candidate, import suspect Received Path ID 0, Local Path ID 0, version 0 Community: 11404:800 RP/0/RSP0/CPU0:cr2-sea-b# John van Oppen Spectrum Networks Direct: 206-973-8302 Main: 206-973-8300 ___ 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] interesting ASR 9k bgp multipath issue
Yes, I did, but my point is that behavior is not the same or at least appears not to be the same on IOS, I want ibgp multipath but only for things with matching IGP metrics, is there a way to tweak that. -Original Message- From: Oliver Boehmer (oboehmer) [mailto:oboeh...@cisco.com] Sent: Monday, March 31, 2014 11:26 AM To: John van Oppen; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] interesting ASR 9k bgp multipath issue so, I have some internally anycasted prefixes (DNS resolvers) as well as bgp maximum paths set to allow both ibgp and ebgp multipath. Oddly, as you can see below the multipath appears to think two paths are identical even when they have different IGP metrics (path #1 and path #2), any idea if this is a bug or how to fix it?Obviously if the IGP cost is the same it should load share, but if not it really should not be doing what is shown below since the paths are not equal. John, what exactly did you configure in your BGP address-family? It looks like you enabled maximum-paths eibgp n, which also considers paths with different metrics as multipath candidates. oli ___ 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] interesting ASR 9k bgp multipath issue
It sure was not in this case, it was pretty obviously 50-50 from my traceroute testing -Original Message- From: Vitkovský Adam [mailto:adam.vitkov...@swan.sk] Sent: Monday, March 31, 2014 2:12 PM To: John van Oppen; 'Oliver Boehmer (oboehmer)'; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] interesting ASR 9k bgp multipath issue If I recall correctly the load-sharing should be proportional to the matric so in your case 254:1 in favor of the path with metric 10. adam ___ 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] interesting ASR 9k bgp multipath issue
So, to be clear, here is an example of this working right on a 6500 with IOS (multipath on the ibgp route that is the same IGP cost and not on the one that is not): cr1-pdx#show ip bgp 64.187.160.0 BGP routing table entry for 64.187.160.0/20, version 562475581 Paths: (2 available, best #1, table Default-IP-Routing-Table) Multipath: eBGP iBGP Flag: 0x1000 Advertised to update-groups: 1 3 5 6 7 8 54858 208.76.153.78 (metric 516) from 208.76.153.116 (208.76.153.116) Origin IGP, metric 0, localpref 115, valid, internal, multipath, best Community: 11404:993 11404:4000 11404:4010 Originator: 208.76.153.78, Cluster list: 208.76.153.116 54858 208.76.153.79 (metric 516) from 208.76.153.117 (208.76.153.117) Origin IGP, metric 0, localpref 115, valid, internal, multipath Community: 11404:993 11404:4000 11404:4010 Originator: 208.76.153.79, Cluster list: 208.76.153.117 cr1-pdx#show ip bgp 208.76.152.9 BGP routing table entry for 208.76.152.9/32, version 562275567 Paths: (3 available, best #1, table Default-IP-Routing-Table) Multipath: eBGP iBGP Not advertised to any peer 64524 208.76.153.79 (metric 516) from 208.76.153.116 (208.76.153.116) Origin incomplete, metric 10, localpref 200, valid, internal, best Community: 11404:800 Originator: 208.76.153.79, Cluster list: 208.76.153.116 64524 208.76.153.79 (metric 516) from 208.76.153.117 (208.76.153.117) Origin incomplete, metric 10, localpref 200, valid, internal Community: 11404:800 Originator: 208.76.153.79, Cluster list: 208.76.153.117 64524 208.76.153.118 (metric 2050) from 208.76.153.118 (208.76.153.118) Origin incomplete, metric 10, localpref 200, valid, internal Community: 11404:800 cr1-pdx# -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of John van Oppen Sent: Monday, March 31, 2014 2:37 PM To: 'Vitkovský Adam'; 'Oliver Boehmer (oboehmer)'; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] interesting ASR 9k bgp multipath issue It sure was not in this case, it was pretty obviously 50-50 from my traceroute testing -Original Message- From: Vitkovský Adam [mailto:adam.vitkov...@swan.sk] Sent: Monday, March 31, 2014 2:12 PM To: John van Oppen; 'Oliver Boehmer (oboehmer)'; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] interesting ASR 9k bgp multipath issue If I recall correctly the load-sharing should be proportional to the matric so in your case 254:1 in favor of the path with metric 10. adam ___ 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] interesting ASR 9k bgp multipath issue
ah, I guess I did not realize the difference if iegp load sharing. Thanks all for pointing that out, good thing for a Monday. -Original Message- From: Oliver Boehmer (oboehmer) [mailto:oboeh...@cisco.com] Sent: Monday, March 31, 2014 9:39 PM To: John van Oppen; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] interesting ASR 9k bgp multipath issue Yes, I did, but my point is that behavior is not the same or at least appears not to be the same on IOS, I want ibgp multipath but only for things with matching IGP metrics, is there a way to tweak that. IOS also behaves the same if configured the same (with maximum-paths eigbp).. as Jared pointed out, you want to enable maximum-paths ibgp n (and possibly maximum-paths ebgp n if you also want to load-share eBGP peers). the configuration of maximum-paths eibgp n is not a shortcut for and hence is different to maximum-paths ibgp n maximum-paths ebgp n oli -Original Message- From: Oliver Boehmer (oboehmer) [mailto:oboeh...@cisco.com] Sent: Monday, March 31, 2014 11:26 AM To: John van Oppen; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] interesting ASR 9k bgp multipath issue so, I have some internally anycasted prefixes (DNS resolvers) as well as bgp maximum paths set to allow both ibgp and ebgp multipath. Oddly, as you can see below the multipath appears to think two paths are identical even when they have different IGP metrics (path #1 and path #2), any idea if this is a bug or how to fix it?Obviously if the IGP cost is the same it should load share, but if not it really should not be doing what is shown below since the paths are not equal. John, what exactly did you configure in your BGP address-family? It looks like you enabled maximum-paths eibgp n, which also considers paths with different metrics as multipath candidates. oli ___ 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] NTP DDoS
We had well over 100 gbit/sec of that lovely traffic headed towards our network (AS11404) a few days ago... That was fun.Secure your networks please, this is getting annoying... John -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Aaron Sent: Monday, February 17, 2014 6:30 PM To: sledge...@gmail.com; 'Cisco NSPs' Subject: Re: [c-nsp] NTP DDoS My gosh! NTP ddos attacks are coming like crazy lately. Y'all getting hit ? I'm going to need to setup a bgp injection thingy with my upstream providers to signal a /32 for my victim(s) in my network so I can selective blackhole traffic in the cloud prior to it hitting my internet links. this is getting really bad Aaron -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Richard Clayton Sent: Tuesday, February 11, 2014 3:36 PM To: Cisco NSPs Subject: [c-nsp] NTP DDoS Seems to be doing the rounds, had a fault open for a couple of days with a 100Mb Ethernet customer, reported fault was packet loss, Cacti showed an upstream flatline of 30Mb and an increase in downstream, as the circuit traffic had recently increased 1st line support presumed that the BT Wholesale circuit had an Etherflow bandwidth restriction so raised the fault which ping ponged back and forth until BT washed their hands of it (rightly so on this occasion) When it was escalated to me I noticed 'no buffer' and 'pause input' packet counters were going nuts on the LAN interface, the packet counters were 10k packets/sec, I enabled 'ip route-cache flow' on the WAN interface and there it was, 1000's of NTP connections. In summary the Cisco 1921 gave up at 30Mb/s with no buffer left, usually runs fine at 100Mb/s with no NAT config, customer had public IP on LAN switch for management and open NTP, LOL. Sledge ___ 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] VSS to vPC - vPC to Etherchannel
That was years ago, and is not good advice today. Propably wasn't good advice then, but that depends on how many years ago... Agreed.LACP is the way to go, avoids all kinds of problems. Static mode bundles fall into the same category in my mind as forcing speed/duplex on Ethernet, just a bad/old idea that bites you in the butt in many common failure scenarios.What Gert points out about knowing both sides are configured right with LACP has saved us many times from a potential black-hole as a result of a loopback cable or tech placing a patch cable incorrectly. That being said, on the IP side of our network (ie routed interfaces) we just use ECMP for most everything these days due to it being even easier to deal with from a troubleshooting and management standpoint. Thanks, 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] SIP 400 reload due to power supply issue
Based on looking at that output, I would question if you have all the inputs on the power supply hooked up.My recollection (although we mostly use the 6500s) is that the 2500 watt supplies (producing ~2300 watts) are the biggest DC supplies that only take one circuit. I think the 2700 watt supplies require two feeds to reach full output. Thanks, John van Oppen Spectrum Networks Direct: 206-973-8302 Main: 206-973-8300 From: cisco-nsp-boun...@puck.nether.net [cisco-nsp-boun...@puck.nether.net] on behalf of Francisco López [f...@transtelco.net] Sent: Friday, February 01, 2013 12:26 PM To: zaid Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] SIP 400 reload due to power supply issue You second power supply just have 1319.22 Watts, and you need 1431.36 Watts to operate normally, when your power 1 comes down your power 2 do not have enough power to run properly. Best regards. On Fri, Feb 1, 2013 at 1:09 PM, zaid zaidoo...@yahoo.com wrote: Hi I have 7606 chassis equipped with SIP 400 that reloading from time to time due to power supply issue, i don't know why in spite of the available power is 1237.74 Watts show power system power redundancy mode = redundant system power redundancy operationally = non-redundant system power total = 2669.10 Watts (63.55 Amps @ 42V) system power used = 1431.36 Watts (34.08 Amps @ 42V) system power available = 1237.74 Watts (29.47 Amps @ 42V) Power-Capacity PS-Fan Output Oper PS Type Watts A @42V Status Status State -- --- -- -- -- - 1PWR-2700-DC2669.10 63.55 OK OK on 2PWR-2700-DC1319.22 31.41 OK OK on Pwr-Allocated Oper Fan Type Watts A @42V State -- --- -- - 1FAN-MOD-6SHS180.18 4.29 OK Pwr-Requested Pwr-Allocated Admin Oper Slot Card-Type Watts A @42V Watts A @42V State State -- --- -- --- -- - - 1WS-X6724-SFP125.16 2.98 125.16 2.98 onon 27600-SIP-200240.24 5.72 240.24 5.72 onon 37600-SIP-400265.02 6.31 265.02 6.31 onon 5RSP720-3C-GE310.38 7.39 310.38 7.39 onon 6(Redundant Sup) - - 310.38 7.39 - - I have this log also Feb 1 20:10:43 UTC: %C7600_PWR-SP-4-PSOUTPUTDROP: Power supply 1 output has dropped Feb 1 20:10:43 UTC: %C7600_PWR-SP-4-UNDERPOWERED: insufficient power to operate all FRU s in system. Feb 1 20:10:43 UTC: %C7600_PWR-SP-4-DISABLED: power to module in slot 3 set off (FRU-power denied) Any idea please if the problem with the power supply or the power source . ZH ___ 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/ -- *TRANSTELCO | **Francisco Lopez* | Engineering MX: +52 (656) 257 - 1106 | US: +1 (915) 217 - 2235 ___ 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] C3550-12T - Gig copper ports won't link at 1Gb
Are you saying that the link does not come up with both ends in auto/auto? At least on copper, that would indicate to me that you either have a bad switch or bad cabling... Are you sure the unit you have is good?I am plugged into a 3550-12T here at home with a few machines and auto works fine with every nic I have tried. 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] C3550-12T - Gig copper ports won't link at 1Gb
You sure your cabling is good?I have seen this issue when there are 100 mbit/sec crossover cables involved (ie only crossing over two of the pairs) built or something similar. We use lots of 3550-12Ts to this day and they are still quite decent if they fit what you need. In your position, I would probably blame it on cabling and start there with any investigation. 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] OIR on 7600s: Pretty much evil?
I really think Geoffrey is onto the true cause.I have never had a problem when inserting cards confidently. It is also worth noting that while it does stall the bus, DFC forwarded traffic is unaffected.We run 100% DFCs in all of our 6500s and the only traffic I have seen dropped during the brief stall is pings or routing updates towards the box, forwarded traffic keeps going along nicely. It is also worth noting that SSO is similar on 6500/7600s, it really only works well when the box is all DFC based. Thanks, John van Oppen / AS11404 -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Geoffrey Pendery Sent: Thursday, November 11, 2010 6:56 AM To: John Neiberger Cc: Gert Doering; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OIR on 7600s: Pretty much evil? I'll second Gert - I've personally performed close to 100 OIRs on a variety of 6500 chassis, and never had it cause a problem. There was a previous thread almost exactly like this, BTW - if you feel like searching the archive. It was half-filled with OIR always fails, I call it Online Insert and Reboot! and half-filled with I've never had a problem, ever. Works like a charm. A couple people explained the bus stall behavior: As you're sliding the blade in, it stalls the bus when it first makes contact, then releases the stall once it's all the way in. My take-away from that thread was that it's a self-fulfilling prophecy: The techs who approach it confidently, expecting no problems, slide the blade in quickly and experience none. The techs who are worried and skeptical, slide the blade in slowly and cautiously - and their caution leads to a reboot. That said, the others in this thread are also correct - if your RP is doing stuff on tight timers, especially BFD, even a very short bus stall can still be service impacting. And of course, it's better to plan a maintenance window expecting problems and be pleasantly surprised than to assume it's no big deal and get hit with an outage. -Geoff On Thu, Nov 11, 2010 at 2:00 AM, Gert Doering g...@greenie.muc.de wrote: Hi, On Wed, Nov 10, 2010 at 03:01:21PM -0700, John Neiberger wrote: I'm just curious to hear your thoughts on OIR on this platform. Is this something that you prefer to avoid? Do you have any OIR-related horror stories you'd like to share? On 6500/7600 (and 7200), we *never* had any issues. On 7500, the R in OIR translates to Reboot. 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-35655025 g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-...@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] Continous BGP session resets on SRD3
We have limits of 100 set for as path length on the upstream routers, this did
not solve the problem.
I think the issue almost has to be 32 bit ASNs. The router on our network
that was ingressing the troublesome prefix was/is running
s72033-adventerprisek9_wan-mz.122-33.SXI1.bin and it was unaffected, the
affected routers were all either customers on other non-affected routers or
iBGP peers of the router where the prefix came into the network.
John van Oppen
Spectrum Networks
http://spectrumnetworks.us
Direct: 206.973.8302
Main: 206.973.8300
-Original Message-
From: Rodney Dunn [mailto:rod...@cisco.com]
Sent: Thursday, June 17, 2010 7:09 AM
To: Gordon Bezzina
Cc: John van Oppen; 'Kostas Fotiadis'; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Continous BGP session resets on SRD3
We are working to get some clarification on this.
In the interim...
Can anyone prove they saw this when either:
a) The upstream speaker did not have the AS Path limit configured to
something lower (say less than 200)?
b) The upstream speaker was running with code *newer* than one of these:
15.1(01.07.01)PIA14 15.1(01.05.01)PIA13 15.1(01)XB 15.0(01.01)SID
15.0(01)M 12.4(24.06.06)PIL12 12.4(24.06.05)PIB12 12.4(24.06)PI11l
12.2(33.01.21)MCP05 12.2(33)ZI 12.2(33)XNE 12.2(33)SXI02
12.2(32.08.17)REC186 12.2(32.08.15)YCA273.10 12.2(32.08.11)XJC273.11
12.2(32.08.11)SX277 12.2(32.08.06)YCA246.10 12.2(32.08.01)YCA273.15
12.0(32)SY10
From what Shimol and I appear to have gleaned so far it's an issue
between a 4byte AS (new) speaker and and non 4 byte (old) speaker *and*
the 4byte AS (new) upstream speaker is on a version of code older than
one of the ones above.
Can folks confirm/deny if their deployment where they saw this either
did or did not match those conditions above?
Read it carefully as it can be tricky.
Thanks,
Rodney
On 6/17/10 12:19 AM, Gordon Bezzina wrote:
Hi,
The other end is a GSR, but I do not have control on.
Anyhow performed emergency upgrade my 7600 from SRD3 to SRE1, did the trick.
It now works without any problems.
Thanks to all.
Best Regards
Gordon
-Original Message-
From: John van Oppen [mailto:jvanop...@spectrumnet.us]
Sent: L-Erbgħa, 16 ta' Ġunju 2010 17:43
To: Kostas Fotiadis; Gordon Bezzina
Cc: cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] Continous BGP session resets on SRD3
We saw this issue about 8 hours ago too... It appeared to affect GSRs
running anything older than gsr-k4p-mz.120-32.SY9.bin as well as 7200s
running non-current versions of IOS. Our 6500s were all fine but they
are all running at least s72033-adventerprisek9_wan-mz.122-33.SXI1.bin.
This sure looked like it was tickling CSCeh13489 but we already limit the
maximum AS-path length to well-under 255 and that did not seem to protect us.
We ended up doing an emergency upgrade of the GSRs involved.
John van Oppen
Spectrum Networks
Direct: 206-973-8302
Main: 206-973-8300
From: cisco-nsp-boun...@puck.nether.net [cisco-nsp-boun...@puck.nether.net]
on behalf of Kostas Fotiadis [kostas.fotia...@oteglobe.net]
Sent: Wednesday, June 16, 2010 4:41 AM
To: Gordon Bezzina
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Continous BGP session resets on SRD3
Hi Gordon,
Just hang-up the phone with TAC.
We also had the same issue this morning.
One session was iBGP and the other eBGP.
Engineer said, undocumented bug, needs to do more research and get back to be.
Don't know what he did and fix it. I guess you need to open a case...
Good luck,
Kostas
On 16/6/2010 12:37 μμ, Gordon Bezzina wrote:
Hi,
Since this morning I am experiencing a weird problem on one of my full
feeds link.
My router is a 7606 with dual RSP720-3CXL-GE and running SRD3.
I have a multihop bgp peer to get the full bgp feed from my customer.
Suddenly this morning the connection started flapping. With the
following error message:
Jun 16 07:40:03 CEST: %BGP-5-ADJCHANGE: neighbor W.X.Y.Z vpn vrf XX Up
Jun 16 07:42:36 CEST: %BGP-5-ADJCHANGE: neighbor W.X.Y.Z vpn vrf XX
Down BGP Notification sent Jun 16 07:42:36 CEST: %BGP-3-NOTIFICATION:
sent to neighbor W.X.Y.Z 3/4 (invalid flags for attribute) 3 bytes
00
15w6d: BGP: 217.15.96.9 Bad attributes Jun 16 07:42:36 CEST:
%BGP-4-MSGDUMP: unsupported or mal-formatted message received from
W.X.Y.Z:
012B 0200 0001 1040 0101 02C0
119A
0226
3D77 22E0 04F9 3065 0003 0065 0003 0065 C288
22E4
22E4 22E4 22E4 22E4 22E4 22E4 22E4
22E4
22E4 22E4 22E4 22E4 22E4 22E4 22E4
22E4
22E4 22E4 22E4 22E4 22E4 22E4 22E4
22E4
22E4 22E4 22E4 22E4 22E4 22E4 4002 4E02
263D
7722
E004 F930 655B A05B A0C2 8822 E422 E422 E422 E422 E422 E422 E422 E422
E422
E422
Jun
Re: [c-nsp] Continous BGP session resets on SRD3
We saw this issue about 8 hours ago too... It appeared to affect GSRs running
anything older than gsr-k4p-mz.120-32.SY9.bin as well as 7200s running
non-current versions of IOS. Our 6500s were all fine but they are all
running at least s72033-adventerprisek9_wan-mz.122-33.SXI1.bin.
This sure looked like it was tickling CSCeh13489 but we already limit the
maximum AS-path length to well-under 255 and that did not seem to protect us.
We ended up doing an emergency upgrade of the GSRs involved.
John van Oppen
Spectrum Networks
Direct: 206-973-8302
Main: 206-973-8300
From: cisco-nsp-boun...@puck.nether.net [cisco-nsp-boun...@puck.nether.net] on
behalf of Kostas Fotiadis [kostas.fotia...@oteglobe.net]
Sent: Wednesday, June 16, 2010 4:41 AM
To: Gordon Bezzina
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Continous BGP session resets on SRD3
Hi Gordon,
Just hang-up the phone with TAC.
We also had the same issue this morning.
One session was iBGP and the other eBGP.
Engineer said, undocumented bug, needs to do more research and get back
to be.
Don't know what he did and fix it. I guess you need to open a case...
Good luck,
Kostas
On 16/6/2010 12:37 μμ, Gordon Bezzina wrote:
Hi,
Since this morning I am experiencing a weird problem on one of my full feeds
link.
My router is a 7606 with dual RSP720-3CXL-GE and running SRD3.
I have a multihop bgp peer to get the full bgp feed from my customer.
Suddenly this morning the connection started flapping. With the following
error message:
Jun 16 07:40:03 CEST: %BGP-5-ADJCHANGE: neighbor W.X.Y.Z vpn vrf XX Up
Jun 16 07:42:36 CEST: %BGP-5-ADJCHANGE: neighbor W.X.Y.Z vpn vrf XX Down BGP
Notification sent
Jun 16 07:42:36 CEST: %BGP-3-NOTIFICATION: sent to neighbor W.X.Y.Z 3/4
(invalid flags for attribute) 3 bytes 00
15w6d: BGP: 217.15.96.9 Bad attributes
Jun 16 07:42:36 CEST: %BGP-4-MSGDUMP: unsupported or mal-formatted message
received from W.X.Y.Z:
012B 0200 0001 1040 0101 02C0 119A
0226
3D77 22E0 04F9 3065 0003 0065 0003 0065 C288
22E4
22E4 22E4 22E4 22E4 22E4 22E4 22E4
22E4
22E4 22E4 22E4 22E4 22E4 22E4 22E4
22E4
22E4 22E4 22E4 22E4 22E4 22E4 22E4
22E4
22E4 22E4 22E4 22E4 22E4 22E4 4002 4E02 263D
7722
E004 F930 655B A05B A0C2 8822 E422 E422 E422 E422 E422 E422 E422 E422 E422
E422
Jun 16 07:42:42 CEST: %BGP_SESSION-5-ADJCHANGE: neighbor W.X.Y.Z IPv4
Unicast vpn vrf XX topology base removed from session BGP Notification sent
The sequence is as follows:
It basically goes up, starts getting the feed, then at around 290K routes it
logs this error and resets the session. It will
Then start over again.
Note that this does not seem to be the route dampening issue - I do not even
have dampening enabled on my router.
Also mls cef is set at 350K for IPv4 and free RAM is over 1G
Any ideas?
Thanks/Regards
Gordon
___
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] Continous BGP session resets on SRD3
yep, that is what I was wondering too...It appeared to be coming in on one of our peers (we were seeing adjacencies between the old IOS routers and one of our peering routers as the location of the clearing). Unfortunately from my hotel room at nanog it was not easy to do much other than upgrade the IOSes, I would have loved to get an actual packet capture since the error messages did not indicate the prefix involved. John van Oppen Spectrum Networks Direct: 206-973-8302 Main: 206-973-8300 From: Nick Hilliard [n...@foobar.org] Sent: Wednesday, June 16, 2010 9:04 AM To: John van Oppen Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Continous BGP session resets on SRD3 On 16/06/2010 16:57, John van Oppen wrote: We saw this issue about 8 hours ago too... It appeared to affect GSRs running anything older than gsr-k4p-mz.120-32.SY9.bin as well as 7200s running non-current versions of IOS. Interesting. Given that several other people are seeing exactly the same problems right now, I wonder is this is some form of bogus prefix floating around? 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] what is it with 3550s?
Do either the 3550s or 3750s do ipv6 BGP? My read of the specifications is that they don't but a real world confirmation would be nice as we are trying to figure out if we need to move in the direction of force10 (which clearly support multiprotocol BGP) as we start swapping out our 3500s which we use with iBGP as customer facing aggregation in a few places. Thanks, John van Oppen -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Asbjorn Hojmark - Lists Sent: Sunday, February 21, 2010 2:09 PM To: TCIS List Acct Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] what is it with 3550s? On Sun, 21 Feb 2010 15:37:29 -0600, you wrote: Also, we've been looking more towards the Cisco's because the Juniper EX series seem to require a feature license for even basic BGP on the 2200/3200 series. Så does Cisco. BGP is in IP Services on the switches. -A ___ 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] IPV6 again
yep, it is based on the netblocks the resolvers are in, we have it enabled too and had to provide the subnets that our resolvers send their outbound queries from. John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mikael Abrahamsson Sent: Wednesday, February 03, 2010 4:15 AM To: Phil Mayers Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] IPV6 again On Wed, 3 Feb 2010, Phil Mayers wrote: Does anyone know the details - do the google DNS servers choose to reply with based on AS-path of the querying IP, or netblock? Inbound interface? When I talked to google, they wanted to know what netblock(s) my resolvers were in, so I guess it's based on that. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] OT : AristaNetworks Switches
We have a few of them in production, since this is non-cisco shoot me an email off-list and I can chat about them. John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ash Net Sent: Tuesday, November 10, 2009 3:47 PM To: Cisco-nsp Subject: [c-nsp] OT : AristaNetworks Switches Hi Folks, A bit offtopic but wondering if anybody has had the chance of evaluating/Deploying AristaNetwork Switching products. they are currently offering low latency 10Gig switching products and appear to be competing in the same space as Nexus platform. Any feedback would be greatly appreciated, Thanks in advance ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Enhanced download procedure
Yep, that was like my brute force solution to the one upstream of mine that does not support RADB based filters, I have cron sending updates to their support@ email address automatically on my behalf... I even got a call back from a senior person there after that went on for about a month as I was apparently causing nearly daily updates (we have about 70 ASNs downstream)... Good times. I could not agree with Justin more that the best way to fix such issues is to cause the annoying feature to be painful for people within the organization responsible for the annoying feature. John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Justin Shore Sent: Friday, September 18, 2009 5:55 PM To: Dale W. Carder Cc: Cisco Mailing list Subject: Re: [c-nsp] Enhanced download procedure Dale W. Carder wrote: Is there a workaround? I found a workaround. I couldn't download a file due to some stupid java error, so I opened a tac case for them to give me the file. Maybe after this happens enough times and costs them real money it will get fixed. That's even better than my idea of asking your account team to get you the files. Genius! I feel a rash of network upgrades coming next week. Unfortunately I'm afraid that I may be forced to open several TAC cases to support my needs. Pity. Justin ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] Multiple power supply failures. Advise needed
I have never seen a piece of network gear that is AC which does not have the electrical ground bonded to the chassis, I was under the impression that bonding is required for safety.The only time I have ever seen this is a floating positive side on -48v gear, but even that is not terribly common. We have several POPs that are on the tops of hills where we are exposed to lighting and I can say that not having all of one's grounds bonded is a really bad idea. Contrary to popular belief, grounds are not really required to be at the same potential to the ground but rather to be the common potential across the entire site, preventing current from flowing across the data circuits between pieces of gear by providing the lowest resistance path for any leakage or differentials between the gear. This common electrical plane is earthed due to safety and static dissipation reasons since it would be bad from a safety prospective to have the racks at a different potential than the ground the people are in the building are standing on (let alone a pain for copper data circuits). --John -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Justin Shore Sent: Tuesday, September 01, 2009 3:03 PM To: Michael Ulitskiy Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Multiple power supply failures. Advise needed Unless you scrapped the paint off of every joint between the chassis through the mounting brackets to the rack then you aren't guaranteed a good connection. That's why most telco screw kits come with the star washer to help scrap the paint of the rack and why most telco equipment frames and mounting kits are a non-painted alloy. Data equipment isn't generally made to the same standards. So for example if you rack up a 3750 you're using non-painted mounting brackets on a painted 2-post. The chassis is also painted so you most likely aren't making a connection between the chassis and the bracket and thus not the 2-post. The ground in the power plane should never be connected within the chassis to the chassis itself. The power plane should never share anything common with the chassis. The chassis should always be grounded separately. Now beyond the panel at the site ground they'll likely meet up again but within the powered equipment they should never touch. Ie, the ground conductor in the L5-20R that your colo provider dropped in your cage should not internally connect to the chassis of the device. The electronics within the device should be insulated from the chassis and the chassis should have an external ground connection that you connect either to the frame or to a ground bar on the frame. Depending on the equipment (thinking telco for a minute) the equipment is sometimes insulated from the frame and connects to a ground bar that is also insulated from the frame as well. There are a lot of telco standards out there that are meant for specific applications. Bottom line, always ground the chassis with the supplied hardware either to a grounded frame or to a ground bar within the frame that goes back to a site ground bar. Not all manufacturers adhere to those standards though... Justin Michael Ulitskiy wrote: Sure, but what the proper grounding is? Does it mean that I have to run a dedicated grounding wire to every piece of equipment? The racks are properly grounded (according to provider) and every server is screwed to them. The power is provided via NEMA L5-20P twisted lock connecter with proper grounding (according to provider). There I currently have tripp lites followed by managed APC PDUs. All equipment is plugged in into APC grounded outlet. Does it not qualify for proper grounding? I also personally went there with a voltmeter and check for voltage between metal parts per Seth Mattinen suggestion and I found 0 voltage. This may sound silly, but I'm taking any chances. What else I can do? ___ 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] 6500 sup720-3bxl crash
Has anyone seen this reload cause before? Sounds like bad memory but the memory addresses are pretty non machine sounding some I am wondering if it is a software bug. Cache error detected! CPO_ECC (reg 26/0): 0x00F3 CPO_CACHERI (reg 27/0): 0x8400 CP0_CAUSE (reg 13/0): 0x4400 Real cache error detected. System will be halted. Error: Primary data cache, fields: , 1st dword Actual physical addr 0x, virtual address is imprecise. Imprecise Data Parity Error Software version is: s72033_sp-ADVIPSERVICESK9_WAN-M), Version 12.2(33)SXI, RELEASE SOFTWARE (fc2) Thanks, 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] 6500 sup720-3bxl crash
Ok, that is what I figured.I guess I could swap-in my spare sup, think it is worth bothering? John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -Original Message- From: Eninja [mailto:eni...@gmail.com] Sent: Sunday, April 26, 2009 4:25 PM To: o...@ovh.net Cc: John van Oppen; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 6500 sup720-3bxl crash Sig 20 = cache parity exception aka parity errors. Take no action for now and only replace mem/board should this recur within a 12-month window. In the meantime, ensure you follow proper ESD procedures when handling devices/modules/memory etc. Eninja On Apr 26, 2009, at 10:23 PM, o...@ovh.net wrote: Hmmm ... same today morning !? Cache error detected! CPO_ECC (reg 26/0): 0x009F CPO_CACHERI (reg 27/0): 0xA000 CP0_CAUSE (reg 13/0): 0x0800 Real cache error detected. System will be halted. Error: Primary data cache, fields: data, Actual physical addr 0x, virtual address is imprecise. Imprecise Data Parity Error Imprecise Data Parity Error Interrupt exception, CPU signal 20, PC = 0x40E7BE6C = Start of Crashinfo Collection (07:05:17 GMT Sun Apr 26 2009) = IOS (tm) s72033_sp Software (s72033_sp-IPSERVICESK9-M), Version 12.2(18)SXF14, RELEASE SOFTWARE (fc1) On Sun, Apr 26, 2009 at 01:13:05PM -0700, John van Oppen wrote: Has anyone seen this reload cause before? Sounds like bad memory but the memory addresses are pretty non machine sounding some I am wondering if it is a software bug. Cache error detected! CPO_ECC (reg 26/0): 0x00F3 CPO_CACHERI (reg 27/0): 0x8400 CP0_CAUSE (reg 13/0): 0x4400 Real cache error detected. System will be halted. Error: Primary data cache, fields: , 1st dword Actual physical addr 0x, virtual address is imprecise. Imprecise Data Parity Error Software version is: s72033_sp-ADVIPSERVICESK9_WAN-M), Version 12.2(33)SXI, RELEASE SOFTWARE (fc2) Thanks, 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/ ___ 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] 6500 TCAM overflows; certain hosts unreachable?
Do you have a reason you can't do a partial BGP feed with a default route between the 7200s and the 6500s to lower the table size? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nate Carlson Sent: Wednesday, December 03, 2008 9:26 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] 6500 TCAM overflows; certain hosts unreachable? We're having some really odd issues with a pair of 6500's. We know that our TCAM table is overflowed, but it's worked fine up until now (new pair of SUP720-10GE's on order, but not here yet, of course.) Here's the TCAM errors we are getting, which are pretty typical: Dec 3 10:29:18: %MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched Dec 3 10:31:49: %MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched Dec 3 10:38:10: %MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched Our CPU load looks ok: cat2: CPU utilization for five seconds: 3%/1%; one minute: 6%; five minutes: 7% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 177 1033718361003824268102 0.90% 0.44% 0.39% 0 Port manager per 8620705308 326963504 63 0.32% 0.09% 0.08% 0 IP Input 3 52 149348 0.32% 0.03% 0.00% 1 Virtual Exec 68 4432208 3722355 1190 0.08% 0.03% 0.01% 0 esw_vlan_stat_pr 105 2177564 4944501440 0.08% 0.01% 0.00% 0 IP RIB Update 5 160343340 8258274 19416 0.00% 0.82% 0.90% 0 Check heaps cat1: CPU utilization for five seconds: 0%/0%; one minute: 6%; five minutes: 7% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1598375448 466005765211 0.32% 0.58% 0.58% 0 ARP Input 3 24 123195 0.16% 0.01% 0.00% 1 Virtual Exec 105 1696000 4795797353 0.08% 0.01% 0.00% 0 IP RIB Update 1 0 124 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 11072 3505348 3 0.00% 0.00% 0.00% 0 Load Meter 4 0 2 0 0.00% 0.00% 0.00% 0 IpSecMibTopN 5 161516388 8266617 19538 0.00% 1.04% 0.98% 0 Check heaps We have meshed BGP between these two 6500's and a pair of 7200's, one with a NPE-G1 and one with a NPE-G2. The ISP connections are on the 7200's, and we have the routes coming back to the 6500's via iBGP. These problems all started early this morning, when we swapped the NPE-G1 for a NPE-G2. After that, we started having intermittent connectivity issues to various IP's on the internet. When we saw those issues, we swapped the G1 back in, with the same config (verified via Rancid.) From our hosts connected to the 6500's, some remote IP's work fine, IE (mtr report): $ mtr --report 216.250.164.1 HOST: nagios Loss% Snt Last Avg Best Wrst StDev 1. x.x.207.140.0%10 108.6 11.4 0.3 108.6 34.2 2. x.x..207.229 0.0%101.2 0.7 0.4 1.2 0.3 3. 207-250-239-5.static.twtelec 0.0%10 79.7 33.6 0.9 103.9 44.0 4. peer-02-so-0-0-0-0.chcg.twte 0.0%10 12.2 12.7 11.6 19.1 2.3 5. min-edge-12.inet.qwest.net0.0%10 11.7 11.5 11.2 12.1 0.3 6. 67.130.18.94 0.0%10 13.2 12.3 11.9 13.2 0.4 7. c4500-1.bdr.mpls.iphouse.net 0.0%10 12.6 13.3 12.3 18.9 2.0 8. c2801-1-uplink.msp.technical 0.0%10 14.1 12.9 12.0 14.1 0.6 9. oxygen.msp.technicality.org 0.0%10 12.6 12.8 12.1 14.1 0.6 Other remote IP's, we lose packets at the first .14 hop (which is the 6509): $ mtr --report 67.135.105.97 HOST: nagios Loss% Snt Last Avg Best Wrst StDev 1. x.x.207.14 40.0%100.2 12.9 0.2 74.3 30.1 2. ??? 100.0100.0 0.0 0.0 0.0 0.0 3. min-edge-10.inet.qwest.net 80.0%100.9 1.2 0.9 1.6 0.5 4. min-core-01.inet.qwest.net 90.0%101.3 1.3 1.3 1.3 0.0 5. ??? 100.0100.0 0.0 0.0 0.0 0.0 6. 205.171.139.30 70.0%10 11.1 11.2 11.0 11.5 0.2 Of course, all the people reporting connectivity issues to us are on IP's like this where the first hop goes bad. Now, the real odd part, is that from the same 6509, coming from the .14 address, I can hit those IP's without any issues: -- start of output -- 511-cat1#ping Protocol [ip]: Target IP address: 67.135.105.97 Repeat count [5]: 50 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 66.187.207.14 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 50, 100-byte
Re: [c-nsp] Transparent LAN over Layer3
I would second that as well. We use l2tpv3 all over the place, with Ethernet. We mostly do it with 7200VXRs as endpoints but I have a few 12000s running with OC48s as tunnel server cards and those work nicely as well and it is a quite elegant solution when MPLS is not possible or only rather simple transport functionality is required. John van Oppen Spectrum Networks LLC 206.973.8302 (Direct) 206.973.8300 (main office) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Boyle Sent: Tuesday, September 30, 2008 7:39 PM To: Paul Stewart; 'Michael K. Smith'; 'cisco-nsp' Subject: Re: [c-nsp] Transparent LAN over Layer3 At 10:20 PM 9/30/2008, Paul Stewart wrote: Yes, we own the end to end network however it's a routed network in those segments... router--router--router--switch--switch--router--router--router-- rout er specifically...;) If we could hand them off a few VLAN's we would just do that and not even use Q-in-Q unless we really needed to... but basically I'm looking for layer2 transport via layer3 devices... and there's no option for MPLS in this setup... Take a look at L2TPv3. We use it for all kinds of crazy transport here. Taking a T1 from one city and one carrier and delivering it to a customer in our datacenter, handing ATM PVCs off from one router to another ATM PVC on another router 100 miles away. We haven't used it for Ethernet, but that sure seems a lot less complicated than the things we are doing. Anything you put in on one side is transparently trunked to the other side. It works great and gives you many of the benefits of MPLS without the need to have a network which supports MPLS end to end. It is especially useful for small POPs and locations with older gear. -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 Well done is better than well said. - Benjamin Franklin ___ 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] combining multiple dsl lines
We use per-packet all the time, in our experience the lines tend to all degrade together since the degradation seems to be in the building trunk or off somewhere in the ATM cloud on the provider (qwest in this case)...We do also run eBGP with private ASNs to all customers who have multiple links as well to detect failed lines. That being said, it sounded like the original requester did not have control of both ends of the line which makes most real solutions a bit moot. John van Oppen Spectrum Networks LLC 206.973.8302 (Direct) 206.973.8300 (main office) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Steele Sent: Wednesday, July 23, 2008 4:47 PM To: Wayne Lee; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] combining multiple dsl lines You're still going to need something on the CPE side to detect a failed route unless you plan on running a routing protocol to your customers, I won't bother going into the Linux side of things seeing as this is a Cisco list but in my experience per-packet is only good if the lines are really well matched or you don't plan on running any/much real-time traffic over it, ie voip, unfortunately with the nature of dsl and its vulnerability to weather and various other nasties in your last mile copper run things just have to many variables for me to consider it a reliable inplementation for someone planning to use it with per-packet and real time traffic where out of order packets can become a problem. Good to hear you are having success with it though. We have used cef per packet with great success on PPPoA DSL links here in the UK, we use radius to add/remove the extra routes when a connection bounces. The CPE is a linux box which is not running any NAT. Works for us Wayne ___ 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] temperature reading GSR
Also worth noting that graphing them with SNMP is also useful to identify long-term trends. I realized we had people putting stuff in a rack next to us backwards (ie hot output into the cold isle) once that way. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete Templin Sent: Monday, March 03, 2008 11:33 AM To: eliran h Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] temperature reading GSR eliran h wrote: I've typed the command: show environment temperatures Slot # Hot Sensor Inlet Sensor (deg C) (deg C) 0 27.528.0 Cisco specify a temperature range for each line card, Do I need to focus in the HOT sensor or the Inlet sensor? Both. High temps at the inlet indicate insufficient cold air. High temps at the hot sensor indicate poor airflow - think airflow restrictions, failed fans, etc. Consider using SNMP to track these. You should then be able to pull the warning and critical thresholds on a per-card basis to know when you're running hot. pt ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP Filtering Policy with regular expressions
The solution to what you are describing is really using community strings to tag routes coming from customers then filtering announcements based on those tags. Google is your friend here. If not, hit me off-list for some cisco config examples. John van Oppen Spectrum Networks LLC 206.973.8302 (Direct) 206.973.8300 (main office) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michalis Palis Sent: Monday, January 21, 2008 1:34 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] BGP Filtering Policy with regular expressions Hello all I am trying to write a BGP policy using regular expressions for outgoing filtering. I need to allow customer AS numbers to be announced by our network as well as any prepends they send or any AS behind our customer's AS. e.g allow 12345 678 9123 12345 12345 etc I did try the follwing which seems to work but I am not sure if I will have any security problems. ^12345_ for AS12345 and anything behind AS12345 Any suggestions will be appreciated ___ 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] Bridge L2 network across WAN
That would be a great application for l2tpv3, assuming you don't need to move a huge amount of data and don't have MPLS enabled. Hit me up off-list for the config examples. John van Oppen Spectrum Networks LLC 206.973.8302 (Direct) 206.973.8300 (main office) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geyer, Nick Sent: Tuesday, January 08, 2008 5:47 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Bridge L2 network across WAN Hi Everyone, I am hoping someone can help me out here. We have an old legacy network which is just a flat L2 network across multiple sites connected by fibre. For various reasons this fibre will no longer be available for use, so I need to find another way to keep this L2 network intact. There is a routed network between all the buildings, so I am hoping there is some sort of bridge scenario to carry this L2 traffic across. My plan at the moment was to connect these l2 switches at the sites into a 2811 at each site which in turn will be connected into the routed network. So basically I am after a way to bridge this l2 network across the 2811's/routed network. Any help would be extremely appreciated. Regards, Nikolas Geyer. ___ 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] Interesting latency spikes
Are you seeing spikes on forwarded packets or just on packets destined for the router? Spikes on ICMP destined for the router is normal due to BGP scanner. Spikes on forwarded traffic is not, can you send a trace route to the endpoint that shows the problem? Thanks, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Storey Sent: Monday, December 24, 2007 2:11 AM To: Bryan Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Interesting latency spikes On 24/12/2007, at 7:42 PM, Bryan wrote: Greetings, we are running a 6500 chassis, sup2/msfc2 dual homed to 2 providers (yes, I know and we are planning to upgrade in the next month). We have some customers with game servers on our network and we are seeing lag spikes apx every 3 minutes. MTR shows Avg at ~12ms and spikes to ~150. I suspect that the BGP scanner process might be causing the issues. However, I never see the cpu on the router go above 80% 1 44 17978927124544 100 90 80 70 60 50 * 40** 30** 20* ** 10 *** * 051122334455 0505050505 CPU% per second (last 60 seconds) 4778754688876557876468988999546888655788664678875767887657 7163799555351156480612934999592332319372336057459088251731 100 90 *** * * * 80*** *** *** ***** *** 70 * *** *** *** *** *** * 60 * ** * * * ** * * 50 ** 40 ** 30 ** 20 *###**##***#**####***# 10 ## 051122334455 0505050505 CPU% per minute (last 60 minutes) * = maximum CPU% # = average CPU% FORONA-6509-2#sh proc cpu sorted CPU utilization for five seconds: 5%/2%; one minute: 13%; five minutes: 11% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 263 6221468 40883926152 2.23% 0.48% 0.41% 0 Port manager per 9 2723328 3661803743 0.47% 0.66% 0.64% 0 ARP Input 117 2785304 12256987227 0.39% 0.40% 0.40% 0 IP Input 167 477508 1339180356 0.15% 0.05% 0.05% 0 CEF process 171 49200 2089338 23 0.07% 0.00% 0.00% 0 FM core 158 205104175215 1170 0.07% 0.08% 0.07% 0 Adj Manager 6 6812124368585 18481 0.00% 0.83% 1.15% 0 Check heaps snip FORONA-6509-2#sh proc cpu sorted | include BGP 114 920940 1628069565 0.00% 0.01% 0.00% 0 BGP Router 115 85344596499143 0.00% 0.00% 0.00% 0 BGP I/O 12139258684233887 167863 0.00% 6.48% 6.36% 0 BGP Scanner /snip Cisco Internetwork Operating System Software IOS (tm) s222_rp Software (s222_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(18)SXF10, RELEASE SOFTWARE (fc1) ROM: System Bootstrap, Version 12.2(17r)S1, RELEASE SOFTWARE (fc1) BOOTLDR: s222_rp Software (s222_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(18)SXF10, RELEASE SOFTWARE (fc1) Cisco WS-C6509 (R7000) processor (revision 2.0) with 458752K/65536K bytes of memory. Processor board ID SCA044404GJ R7000 CPU at 300Mhz, Implementation 0x27, Rev 3.3, 256KB L2, 1024KB L3 Cache Last reset from power-on SuperLAT software (copyright 1990 by Meridian Technology Corp). X.25 software, Version 3.0.0. Any Ideas are greatly appreciated. I dont believe routing is handled by the SUP, unless perhaps it cant be handled by the MSFC, and the packet is punted to the SUP for processing. So the spikes you are seeing probably arent related to the CPU utilisation of the SUP. Im not too familiar with the 6500/7600 series platforms, but can you perhaps get CPU statistics for each of the line cards and/or the MSFC and see how they are fairing up? ___ 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] Level3/Cogent/HVDataNet specific routing problem -looking for suggestions
If you are trying to influence the return-traffic from cogent to go to you via another upstream and not level3, you can use the level3 community that will prepend a few times to cogent. We do this with great success as we have three providers and try to keep some tier 1s coming in each of them based on how close the peerings between providers are. If you want specific help with level3 communities you can email me off-list and I will send you some examples on what we do as we also have AS3356 transit and keep all of the traffic from cogent - us on another upstream for performance reasons. Thanks, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Crawford Sent: Friday, November 16, 2007 10:08 AM To: 'Tim Durack'; 'Cisco-nsp' Subject: Re: [c-nsp] Level3/Cogent/HVDataNet specific routing problem -looking for suggestions The prepeding should have nothing to do with your lack of connectivity through Cogent. All the prepending would do is possibly make another route look more desireable due to the as-path. They already append their ASN when you pass through their AS. As a second note... are you allowing UDP ports for traceroute? I can trace 208.74.141.252 with ICMP, but with UDP I drop right at your edge. Cisco uses UDP by default. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Durack Sent: Friday, November 16, 2007 8:47 AM To: Cisco-nsp Subject: [c-nsp] Level3/Cogent/HVDataNet specific routing problem - looking for suggestions Having difficulties with routing through a Level3 circuit: Traceroute using 67.99.58.158 source address: RTR-3#traceroute 38.102.194.142 Type escape sequence to abort. Tracing the route to HudsonValleyDataNet.demarc.cogentco.com (38.102.194.142) 1 67.99.58.157 [AS 6395] 8 msec 4 msec 4 msec 2 so-7-0-0.edge5.NewYork1.Level3.net (4.68.63.17) [AS 6395] 12 msec 4 msec 4 msec 3 ae-32-89.car2.NewYork1.Level3.net (4.68.16.132) [AS 6395] 4 msec 4 msec 4 msec 4 COGENT-COMM.car2.NewYork1.Level3.net (4.68.111.46) [AS 6395] 8 msec 4 msec 4 msec 5 v3503.na21.b001105-25.jfk05.atlas.cogentco.com (38.20.32.162) [AS 6395] 12 msec 12 msec 8 msec 6 HudsonValleyDataNet.demarc.cogentco.com (38.102.194.142) [AS 6395] 152 msec * 8 msec Traceroute using 208.74.141.252 source address: RTR-3#traceroute Protocol [ip]: Target IP address: 38.102.194.142 Source address: 208.74.141.252 Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to HudsonValleyDataNet.demarc.cogentco.com (38.102.194.142) 1 67.99.58.157 [AS 6395] 4 msec 4 msec 4 msec 2 so-7-0-0.edge5.NewYork1.Level3.net (4.68.63.17) [AS 6395] 4 msec 4 msec 4 msec 3 ae-32-89.car2.NewYork1.Level3.net (4.68.16.132) [AS 6395] 4 msec ae-22-79.car2.NewYork1.Level3.net (4.68.16.68) [AS 6395] 4 msec 4 msec 4 COGENT-COMM.car2.NewYork1.Level3.net (4.68.111.46) [AS 6395] 20 msec 4 msec 5 * * * 6 * * * 7 I'm assuming 208.74.141.0/24 is getting dropped at hop 5 due to filtering. Not having issues anywhere else. I have a ticket open with Level3, but would like to see if I can work around this with some community triggered prepending. Looking at Level3's community support, I think I could get 208.74.141.0/24 prepended for Cogent peering: customer traffic engineering communities - Prepending 65001:0 - prepend once to all peers 65001:XXX - prepend once at peerings to AS XXX 65002:0 - prepend twice to all peers 65002:XXX - prepend twice at peerings to AS XXX 65003:0 - prepend 3x to all peers 65003:XXX - prepend 3xat peerings to AS XXX 65004:0 - prepend 4x to all peers 65004:XXX - prepend 4xat peerings to AS XXX So something like: route-map level3-out set community 65001:174 ! Does that have a chance of working? Do I have to soft-reset the session to get the community propagated? Thanks, Tim: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] OC3 Throughput
Max it can do or max you should do to keep service from turning nasty? John van Oppen Spectrum Networks LLC 206.973.8302 (Direct) 206.973.8300 (main office) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Stewart Sent: Friday, November 16, 2007 7:01 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] OC3 Throughput Hi folks... Looking for input on *realworld* maximum throughput on an OC-3 circuit? This is a Cisco 7206VXR with a OC-3 card with l2tp tunnels coming into the router servicing PPPOE clients over ADSL. Thanks, ___ 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] Understanding TCAM/route limitations in the GSR..
This is the easiest way since it shows percentage for engine2 cards. routershow ip cef res Hardware resource allocation status summary Green (Normal), Yellow (Caution) Red (Alarm) Slot HW Resource NameUtil Alert 2E2_Rx_PLU30G 2E2_Rx_TLU24G 3E2_Rx_PLU30G 3E2_Rx_TLU24G John van Oppen Spectrum Networks LLC 206.973.8302 (Direct) 206.973.8300 (main office) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew Weaver Sent: Tuesday, October 30, 2007 8:14 AM To: 'Mikael Abrahamsson'; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Understanding TCAM/route limitations in the GSR.. And which of the metrics below is the 'key'? Free Memory (Free Memory excluding chunks) --- PLU SDRAM: 50927616 bytes (50575360 bytes) TLU SDRAM: 32861600 bytes (31612160 bytes) PSA SSRAM: 809728 bytes ( 795776 bytes) ? Thanks Mikael the GSR is a total mystery in some ways. -Drew -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mikael Abrahamsson Sent: Tuesday, October 30, 2007 10:52 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Understanding TCAM/route limitations in the GSR.. On Tue, 30 Oct 2007, Pete Templin wrote: Very helpful information...what commands should I be using to assess where I'm at regarding Eng2 TCAM size? show controllers psa mem on the LC in question is a good starting point. -- Mikael Abrahamssonemail: [EMAIL PROTECTED] ___ 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] Understanding TCAM/route limitations in the GSR..
I needed an answer to this question too and from what I can tell the answer is as follows: The GRP-B is just a route processor, so the only limitation is ram and CPU speed... assuming convergence times are not an issue, once it runs out of ram, you have a problem...As of today, I am running about 170 MB free on my GRP-B with the most bgp peers (2 full routes + 80 peers + 5 customers + 8 internal routers). Engine0 linecards are not TCAM limited as they run in software, so when the card runs out of ram, that is the limit of its TCAM. We have 256 MB of ram on all our engine0 cards, they run with about 100 MB of free ram as of today. Engine2 cards (three port gigE) for example have already run out of TCAM if they are running ACLs or MPLS. With a straight IPv4 table and no ACLs ours seem to run right at 30% utilization (show ip cef resource). The newer cards have larger TCAMs. If I missed anything, please add it... Then newer cards will have to be commented-on by others as we don't have any data as our network is mostly the older cards. John van Oppen Spectrum Networks LLC 206.973.8302 (Direct) 206.973.8300 (main office) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew Weaver Sent: Monday, October 29, 2007 9:40 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Understanding TCAM/route limitations in the GSR.. Hi, I know I've been quite the pest as of late ;-) I have been recently scouring the net and Cisco's site seeking information on TCAM (or route memory) limitations on the GRP-B (or the GSR) in general. Do they suffer from the same limitations (worse, or better?) with TCAM exhaustion from routes that the 7600/6500 series does? Does anyone know what the shelf-life of a GRP-B would be? I haven't really been able to find any hard data on it. 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/
Re: [c-nsp] overruns on a gig-e circuit?
The other alternative is to turn off all the ACLs on the card, which may be ok depending on your situation (ie an internal backbone link).I did some testing and with the current full table engine 2 cards are at about 1/3 of the FIB capacity (according to the cef stats on the card) if all other features are disabled (MPLS and hardware ACLs): gsr#show ip cef res Hardware resource allocation status summary Green (Normal), Yellow (Caution) Red (Alarm) Slot HW Resource NameUtil Alert 2E2_Rx_PLU23G 2E2_Rx_TLU24G 3E2_Rx_PLU23G 3E2_Rx_TLU24G -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lasher, Donn Sent: Friday, September 07, 2007 9:08 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] overruns on a gig-e circuit? Engine2 cards have some serious FIB hardware limitations: Summary of Limitations: --- Recent ehancements to the ACL software have increased the memory required to store the forwarding table on Engine 2 LCs. The extent of the limitation depends on which ACL configuration is used. If ACL packet filters are not configured on an interface, the input ACL limitation applies. The 4 port OC12 POS, 1 port OC48 POS, and 3 port GigE LCs can support up to 448 lines of ACLs in hardware. The configuration of an input ACL on these cards will result in a limitation of 171,000 routes. The configuration of an output ACL on any interface in the router will result in a route limit of 110,000 for these cards. The 16 port OC3 POS and 4 port OC12 ATM LCs can support up to 128 lines of ACLs in hardware. The configuration of an input ACL on these cards will result in a route limitation of 205,000 routes. The configuration of an output ACL on any interface in the router will result in a route limit of 190,000 for these cards. With the current route table at well over 200k routes, engine2 cards run out of memory and crash if used on a router with full BGP tables. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew Weaver Sent: Friday, September 07, 2007 7:53 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] overruns on a gig-e circuit? Hi, I just replaced a link between two GSR 12000s using old engine 1 cards with shiny new engine 2 cards. The old Engine 1 cards didn't display any overruns But the new engine 2 cards are displaying overruns Example: Router-A 186 input errors, 0 CRC, 0 frame, 186 overrun, 0 ignored Router-B 236 input errors, 0 CRC, 0 frame, 236 overrun, 0 ignored Granted, there are only 236 overruns per each 100million packets but before we weren't seeing any, Anyone have any thoughts? 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/
Re: [c-nsp] GSR-12008 -----%SYS-2-CHUNKBOUNDS
I am assuming you mean the interface on the line card is shutdown. If so, that is the normal behavior as dCEF is still enabled on a card with no active interfaces. (at least it was like this on the 1 port gigE card I was looking at the other day). John van Oppen Spectrum Networks LLC 206.973.8302 (Direct) http://spectrumnetworks.us -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lane Sent: Tuesday, September 04, 2007 6:19 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] GSR-12008 -%SYS-2-CHUNKBOUNDS Anyone experience this CEF memory issue on a line card that is SHUTDOWN? %SYS-2-CHUNKBOUNDS: Could not find the sibling to allocate memory from. Chunk CEF: 1 path ch, total free 34684 inuse 225716. - This line card has not been configured for use, yet the router is sending the message above. Google search came up with this: %SYS-2-CHUNKBOUNDS: Could not find the sibling to allocate memory from. Chunk [chars], total free [dec] inuse [dec] *Explanation *A software error occurred. *Recommended Action *Copy the error message exactly as it appears, and report it to your technical support representative Site is remote, my only hope is to either reseed LC or replace. Any other suggestions would be appreciated. Thanks -- //CL ___ 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] maximum dCEF routes on GSR engine 2 cards
I am running into a problem where I am running out of dCEF resources on a couple of engine 2 line cards (both of the suspect cards are three port gigE cards) in my 12008s. Anyone have hints on getting this usage under control or at least some actual numbers on what the actual maximum routing table size in the hardware forwarding table (since the E2_RX_TLU indicator seems to indicate forwarding entries). Interestingly this is not affecting the engine 0 line cards in the routers, and I was wondering if anyone else with a full view of the routing table was having this happen? It seems on my side to just have started one day and immediately have gone from a yellow alarm to 100% utilization, so it seems to me like something could be wonky. routershow ip cef re Hardware resource allocation status summary Green (Normal), Yellow (Caution) Red (Alarm) Slot HW Resource NameUtil Alert 2E2_Rx_PLU29G 2E2_Rx_TLU100 R 3E2_Rx_PLU29G 3E2_Rx_TLU100 R Both cards are the following: router#show cef line 3 CEF linecard slot 3, status up, fibhwidb sync, fibidb sync, adj sync Sequence number 20688, Maximum sequence number expected 21193, Seq Epoch 2 Send failed 0, Out Of Sequence 0, drops 0 Linecard CEF reset 2, reloaded 2 2091179 elements packed in 32971 messages(72011038 bytes) sent 32 elements cleared 0/0/0 xdr elements in LowQ/MediumQ/HighQ 247773/34/286 peak elements on LowQ/MediumQ/HighQ Keepalive timer will expire in 00:05:59 Init window timer is not running Input packets 1904878439, bytes 1322133076937 Output packets 1631996819, bytes 1062121911533, drops 0 UTI input packets 0, bytes 0 UTI output packets 0, bytes 0 0 proc sw, 0 proc sw fail, 0 hdr error CEF Table statistics: Table nameVersion Prefix-xdr Status Default404607 702947 Active, sync, table-up router#show diag 3 SLOT 3 (RP/LC 3 ): 3 Port Gigabit Ethernet MAIN: type 68, 800-6376-05 rev B0 Deviation: 0 HW config: 0x00SW key: 00-00-00 PCA: 73-4775-07 rev C0 ver 2 Design Release 2.0 S/N SAD09100D9E MBUS: Embedded Agent Test hist: 0x00RMA#: 00-00-00RMA hist: 0x00 DIAG: Test count: 0xTest results: 0x FRU: Linecard/Module: 3GE-GBIC-SC= Processor Memory: MEM-GRP/LC-256= Packet Memory: MEM-LC1-PKT-256= L3 Engine: 2 - Backbone OC48 (2.5 Gbps) MBUS Agent Software version 1.100 (RAM) (ROM version is 2.41) ROM Monitor version 16.12 Fabric Downloader version used n/a (ROM version is 10.1) Primary clock is CSC 1 Board is analyzed Board State is Line Card Enabled (IOS RUN ) Insertion time: 15w2d (1d09h ago) Processor Memory size: 268435456 bytes TX Packet Memory size: 134217728 bytes, Packet Memory pagesize: 8192 bytes RX Packet Memory size: 134217728 bytes, Packet Memory pagesize: 8192 bytes 0 crashes since restart Any ideas on optimization would be appreciated. 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 dCEF routes on GSR engine 2 cards
I only need MPLS two LCs (I am doing some layer 2 Ethernet over MPLS) in the router, so would it work to disable MPLS globally then just enable tag-switching on the couple of interfaces I need it on? (neither are on the engine 2 cards) John -Original Message- From: Oliver Boehmer (oboehmer) [mailto:[EMAIL PROTECTED] Sent: Sunday, July 29, 2007 9:13 AM To: John van Oppen; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] maximum dCEF routes on GSR engine 2 cards John van Oppen mailto:[EMAIL PROTECTED] wrote on Sunday, July 29, 2007 11:48 AM: Yep, that is what I thought. With that last command it looks like MPLS could be the culprit, any advice to that end would be welcome. Well, do you use MPLS on this node? I only see a few IGP routes, so not sure what this router's role is in your MPLS network. Looks like you're not running any ACLs on the interfaces. You might want to try enabling no access-list hardware psa and reload the LCs, not sure if it helps (haven't dealt with E2 in a while).. In any case: Even if you can free up some memory now, with the growing Internet table I fear you'll run out of resources on these LCs sooner or later. oli ___ 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/
