Re: [c-nsp] TCN's - Causing brief outages on ASR1K
Switches can have rate-limiters (aka storm-control measures) to control broadcast, multicast and unknown-unicast. BPDU's are layer-2 multicast. Your issues sounds like you're losing BPDUs. Try "debug spanning-tree root" to see if it's causing root changes. If you are running a lot of VLANs worth of BPDUs, you might be bumping into a limit somewhere on your network or a peer's. It's because of problems like this, that STP shouldn't cross administrative-domains. On 18 Dec 2014, at 4:09 pm, CiscoNSP List wrote: >> >> This seems like..."interesting" advice. At that point, you might as >> well just turn spanning-tree off. This is somewhere around cutting off >> your foot to stop your toe bleeding. >> >> That said: This seems like "design problem" not so much "gear >> problem". Why are you running spanning tree with devices you don't >> administratively control? And if you do control them, why the hell are >> you seeing TCNs so often if your network is stable? > > > We dont control the device this port is connected to, and when the port was > configured, bpdufilter was not enabled(12months ago)TCN's have only > recently been "arriving" on this port. > > >> >> -Blake >> >> On Wed, Dec 17, 2014 at 8:35 PM, CiscoNSP List >> wrote: >>> Another update on thisTAC are recommending that we enable bpdufilter on >>> "all" ports, as any port that is root and receives a TCN will cause an >>> "outage"we have bpdufilter enabled on customer facing ports(to other >>> switches), but some of our legacy equipment/connections would be missing >>> this command Im sureI find it incredibly difficult to believe that we >>> have not been hit by this in the past, if this is "expected" behaviour on >>> any switch. >>> >>> Would love to hear from any switching experts on TAC's recommendation, and >>> have we just been "lucky" not to be impacted by this in the past? >>> >>> >>> Cheers. >>> >>> From: cisconsp_l...@hotmail.com >>> To: peteli...@templin.org; mrantoinemonn...@gmail.com; luky...@hotmail.com; >>> cisco-nsp@puck.nether.net >>> Subject: RE: [c-nsp] TCN's - Causing brief outages on ASR1K >>> Date: Tue, 16 Dec 2014 10:51:07 +1100 >>> >>> >>> >>> >>> Thanks for all the replies. >>> >>> Just an update to this - No issues for 4 days (with spanning-tree portfast >>> trunk enabled on trunk port from 4948 -> ASR), then this morning, another >>> TCN was received on an AGG port(On the 4948) to a carrier (The TCN's (Since >>> we are now looking for them)) seem to only arrive on 2 ports...both being >>> carrier AGG ports, with multiple vlans, and to the same carrier.we do >>> not have any visibility into the carriers network >>> >>> This TCN did also cause OSPF+LDP flaps on the ASRagain, only for a >>> ~5seconds >>> >>> It's "RRR"(So highest priority) with TAC, but we are still in the same >>> place we were over a week ago.as you can imagine, customers are not >>> impressed! >>> >>> >>> Date: Mon, 15 Dec 2014 09:04:43 -0800 From: peteli...@templin.org To: mrantoinemonn...@gmail.com; luky...@hotmail.com; cisconsp_l...@hotmail.com; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] TCN's - Causing brief outages on ASR1K You can run RSTP or MST all day long on a switch to get rapid STP convergence, but you'll only gain the rapidness of RSTP/MST on ports where they neighbor is actually participating in the correct STP variant. Routers don't participate in STP, so the 4948 has to treat those ports as legacy STP. Whenever there's a root placement event, the 4948 has to block the port until the STP process/timers can confirm that there's no superior root bridge hiding inside or behind the router. Now, if there's a small enough event going on that SHOULDN'T be causing a root placement event but IS, that could be a bug in the 4948 code. However, I'd say very strongly that you SHOULD have portfast [trunk] towards any devices that aren't participating in the STP process, unless those devices are capable of creating an L2 loop. > On 12/15/2014 1:18 AM, Antoine Monnier wrote: > A TCN will cause all the learned MAC addresses to be flushed by the > switiches, but it will not "block" traffic. So the TCN on its own should > not be the cause of OSPF and LDP flaps. > > Is your switch running out of space for all the learned MAC addresses? > > I dont see how enabling "portfast trunk" would help in that scenario (it > should only change the behavior if an interface flaps). > Has the source of TCN being identified? Configuring ports as "portfast" > will lower the probability of generating TCN, that may be why they advised > you to do this. However applying to a port that is stable (no interface > flap) is not really going to help for this specific problem. > > > >> On Mon, Dec 15, 2014 at 9:06 AM, Lukas Trib
Re: [c-nsp] TCN's - Causing brief outages on ASR1K
On 18/12/2014 05:59, Blake Dunlap wrote: This seems like..."interesting" advice. At that point, you might as well just turn spanning-tree off. This is somewhere around cutting off your foot to stop your toe bleeding. That said: This seems like "design problem" not so much "gear problem". Why are you running spanning tree with devices you don't administratively control? And if you do control them, why the hell are you seeing TCNs so often if your network is stable? That happens very often when you buy inter-pops links from your town's metro ethernet carrier. ___ 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] ASR1006 Memory issue
Hi Tim, Could you elaborate on rommon version comment please. I will be upgrading myself shortly. Thanks Ivan On 16/Dec/2014 2:39 a.m., Tim Warnock wrote: Watch your rommon version too. -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jordi Magrané Roig Sent: Monday, 15 December 2014 11:34 PM To: mark.ti...@seacom.mu; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASR1006 Memory issue Hello, Lukas and Mark, thanks for the information. I'm planning to upgrade the device but it will take some weeks. My worry is to check now if the device has problems. Somebody knows how I could check if the device is working fine? Thanks! From: mark.ti...@seacom.mu To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASR1006 Memory issue Date: Mon, 15 Dec 2014 13:51:32 +0200 CC: luky...@hotmail.com; jordimagr...@hotmail.com On Monday, December 15, 2014 01:08:32 PM Lukas Tribus wrote: I suggest you ugprade to the latest rebuild of a supported long-term support branch (3.10S?). I'd say go to 3.10(4)S, which is 15.3(3)S4. We were on 15.4(2)S earlier and that has some serious BGP bugs that lead to router crashes, as well as other random crashes. Suffice it to say, Cisco say 3.10(4)S is their recommended release for this platform. Mark. ___ 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] newbie questions about jumbo packets
Hi Scott, please see inline below: At 07:09 AM 12/18/2014 Thursday, Scott Voll announced: I'm working on my Nexus 5k's. I need to adjust QoS for the first time. I'm following the white papers about input QoS, Network QoS, and Queuing QoS. I currently have a very simple network QoS with MTU of 9216 to allow jumbo frames on the pair of Nexus (storage). But now that I'm adjusting QoS I will be classifying my traffic, rather than just using the default. On n5k you use the network-qos (NQ) policy to adjust the MTU for all ports in the box. This does not change any other QoS behaviors, either internal or external to the box. For example, it does not cause the switch to mark/remark packets or classify/queue any differently than before. Note that on nexus in general, there is some level of 'baseline' classification for queuing purposes, typically at least a low/high priority queue to ensure network control traffic is prioritized. More granular configs are possible but out of the box it's pretty basic. What happens if I add jumbo frames to all my network classifications and it's not enabled everywhere (other switches connected(Ethernet))? If you enable jumbos on some switches but not all, obviously if a jumbo passes to a switch with it disabled, it will be dropped. I Believe on networks where the MTU is smaller it will just down size to the standard 1500. Is that correct? Most network gear does not fragment, or only fragments in software, so this is something to avoid. Hope that helps, Tim 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/ Tim Stevenson, tstev...@cisco.com Routing & Switching CCIE #5561 Distinguished Engineer, Technical Marketing Data Center Switching Cisco - http://www.cisco.com +1(408)526-6759 ___ 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] SDN
LOL. after so many years, this list does not stop making me more and more surprised, thank you, you made my day. 2014-12-18 7:35 GMT+01:00 cool hand luke : > > On 12/17/2014 04:21 AM, GNANESH wrote: > >> I need to understand and setup SDN in my office environment. Can you help >> me out with necessary videos and installation guides ? >> > > 1. could you be a little more vague? > > 2. is google broken? if google doesn't have what you need, then... > > 3. reply w/ your timeline and your training budget. > > /chl > > ___ > 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] newbie questions about jumbo packets
I'm working on my Nexus 5k's. I need to adjust QoS for the first time. I'm following the white papers about input QoS, Network QoS, and Queuing QoS. I currently have a very simple network QoS with MTU of 9216 to allow jumbo frames on the pair of Nexus (storage). But now that I'm adjusting QoS I will be classifying my traffic, rather than just using the default. What happens if I add jumbo frames to all my network classifications and it's not enabled everywhere (other switches connected(Ethernet))? I Believe on networks where the MTU is smaller it will just down size to the standard 1500. Is that correct? 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] ASR9k question
> Nick Hilliard > Sent: Wednesday, December 17, 2014 6:11 PM > On 17/12/2014 09:14, R LAS wrote: > > does anybody knows the maximum number of VPLS instances supported > on > > ASR9k ? > > > > Is there a reference on cisco.com ? > > I was able to find numbers of pseudowires but I'm not currently sure > > i'ts the same... > > Router# show l2vpn capability > > note that there are a pile of line-card dependencies here, and that the > documentation says: "To achieve the scale values, subinterfaces must be > evenly allocated between the line card's physical ports." > > Nick > Also if you have Trident LCs it also depends on whether you have L2 or L3 scale profile enabled. 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] Understanding ASR1k / ESP40 capacity
Think not only throughput but about pps also. According to cisco doc ESP40 has ~20Mpps capacity, ESP20 has the same limitation. So, you pick out all resources from QFP. RA write the report where you can see this limitation - http://www.slideshare.net/RouterAnalysis/cisco-asr-1000-series-testing-results-and-analysis 04.10.2014 18:56, Pete Lumbis пишет: All, > >I'm banging my head against a brick wall trying to get sensible answers >from >Cisco TAC, so thought I'd ask the educated masses who may have come across >this before... > >I've got a Cisco ASR1004 with RP2, ESP40, 2 * SIP40's, and 8 * 10GE ports. > >A snapshot of usage on these ports at peak is: > >Interface RxBps RxPps TxBps TxPps >Te0/0/0 4,385,563,000 515,508906,118,000 339,997 >Te0/1/0 3,942,338,000 419,696984,150,000 358,436 >Te0/2/0 3,949,993,000 425,192933,257,000 349,145 >Te0/3/0 4,375,526,000 512,858873,284,000 334,751 >Te1/0/0 1,186,440,000 454,714 5,474,029,000 630,916 >Te1/1/0 622,154,000 244,056 3,181,689,000 338,190 >Te1/2/0 711,493,000 253,275 3,211,560,000 340,950 >Te1/3/0 1,218,873,000 437,195 4,831,708,000 568,488 > >TOTAL20,392,380,000 3,262,494 20,395,795,000 3,260,873 > >I'm seeing throughput issues on a portchannel consisting of Te0/0/0 and >Te0/3/0 >(it won't go over 10Gbps aggregate) > >Cisco TAC are telling me if I add TxBps and RxBps totals together, I get >40Gbps, >so I've reached capacity of the QFP (i.e. ESP40). > >My arguement against this is that a packet which enters the router on >Te0/0/0, >goes through the SIP40 in slot 0, through the ESP40, through the SIP40 in >slot >1, and out through Te1/0/0 is still just one packet, so should only need >to be >counted once through the ESP, and once for each SIP. Hence, the throughput >on >the ESP is only 20.3Gbps on those numbers above. > >If I poll ceqfpUtilProcessingLoad by SNMP, I see peaks of around 65%, which >would correlate with this level of throughput. > >I'm assuming there are others of you using this platform. What sort of >throughput are you seeing? Am I right, or is the Cisco TAC engineer? > >TIA, > >Simon ___ 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/
