Re: [c-nsp] IP LFA in ring topology
Yes Mark, you are absolutely right. With the advent of NG-MVPN we can finally bye bye the PIM in our backbones. Though now with MPLS all the way to access/pre-aggregation layer I'd like to see MVPN support there as well, namely ME3600x/-cx/3800x platforms. adam -Original Message- From: Mark Tinka [mailto:mark.ti...@seacom.mu] Sent: Friday, May 03, 2013 10:59 PM To: cisco-nsp@puck.nether.net Cc: Adam Vitkovsky; 'Saku Ytti' Subject: Re: [c-nsp] IP LFA in ring topology On Friday, November 30, 2012 10:46:47 AM Adam Vitkovsky wrote: And that would be AWESOME, I didn't quite get the idea of creating other RIP like protocols in favor of existing link-state protocols -same goes for PIM vs ISIS Don't look now, but PIM moved into BGP a little while back :-). 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/
Re: [c-nsp] CRS-1 FP-40
Hello Tin, We are using FP-40 instead of the MSC, and it is working fine with no bad experience at all, we are not affected by its limitations as we did not need the extra features found in the MSC, so i encourage you to go for it if it is sufficient for your needs. On Tue, Nov 3, 2009 at 6:13 PM, Tin Nguyen tin.ngu...@sasktel.sk.ca wrote: Hello all, I am looking to learn of any good or bad deployment experience with the new Cisco CRS-1 FP-40 module. Besides the limitations outlined in cisco's datasheet (less pps and QoS queue than MSC-40), is there any other gotcha's that you have found in testing or deployment? Thank you for sharing your experiences in this matter, Tin ___ cisco-nsp 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] Ang: Making SUP720 cope better under BGP load
I can vouch for the asr9k in regards too performance. But the software still is not as stable as you might want. On May 2, 2013 9:52 AM, gustav.ulan...@steria.se wrote: Hello Simon. We are using asr1k for peering purposes and Sup2T in the core. We also have some sup 720 as PE routers. We find that the ASR1001 is alot faster at establishing our BGP sessions than both sup 720 and 2T. I would look into the ASR9001. Seems to be much better box than an ASR 1k box when you spec it to be able to push around 40G. Often turns out cheaper than ASR1k boxes also. Gustav Uhlander Communication Infrastructure Engineer Steria AB Kungsbron 13 Box 169 SE-101 23 Stockholm Sweden Tel: +46 8 622 42 15 Fax: +46 8 622 42 23 Mobile: +46 70 962 71 03 gustav.ulan...@steria.se www.steria.se -cisco-nsp-boun...@puck.nether.net skrev: - Till: cisco-nsp@puck.nether.net Från: Simon Lockhart ** Sänt av: cisco-nsp-boun...@puck.nether.net Datum: 2012-12-07 14:29 Ärende: [c-nsp] Making SUP720 cope better under BGP load All, I'm currently using SUP720-3BXL's in my BGP border devices. Obviously the SUP720 is not a particularly fast CPU, so it is pretty slow at bringing up a lot of BGP sessions. On one particular box, I've got 250 BGP neighbours - 1 full table transit, 2 IGP to route-reflectors, and the rest are peering sessions at an IXP. Recently, the IXP did maintenance causing the interface to drop, and it bought the box to its knees. The BGP Router process takes all the available CPU while it tries to re-establish the BGP sessions. While this is happening, the SUP720 seems to give up processing other stuff in a timely manner - and I see MPLS LDP drop, OSPF neighbours drop, and then BGP sessions drop due to hold timer expires. With all these drops, it causes even more CPU load, and the cycle continues. I've been talking to other SUP720 using ISPs, and it seems that some see this same effect, and others don't. Currently running 12.2(33)SXJ3 Are there any tweaks that I can apply to the IOS config to make the SUP720 cope better in this sort of situation? I'd be happy for the BGP sessions to take a lot longer to re-establish, if it didn't kill everything else in the process... And, as a follow-on question, given that the SUP720 is so under-powered for BGP, what other options do I have which would cope better? SUP-2T? Or, if I need to move away from the 6500, what's good for BGP routing with about 20-40G of throughput (i.e. 4-8 * 10GE ports)? How does the ASR9k or ASR1k range fair for BGP performance? Many thanks in advance, 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/ ** ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IP LFA in ring topology
On Sunday, May 05, 2013 01:43:44 PM Adam Vitkovsky wrote: Yes Mark, you are absolutely right. With the advent of NG-MVPN we can finally bye bye the PIM in our backbones. Though now with MPLS all the way to access/pre-aggregation layer I'd like to see MVPN support there as well, namely ME3600x/-cx/3800x platforms. I'm generally optimistic, so I think it will come some day. The platform still has a long way to grow. That said, the ASR9000 is getting decent NG-MVPN support, and I beleive focus is also going into the ASR1000. Watch for mLDP to gain initial support, and RSVP-TE will follow suit. Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] CRS-1 FP-40
On Sunday, May 05, 2013 04:08:55 PM Abdelfattah Ghattas wrote: We are using FP-40 instead of the MSC, and it is working fine with no bad experience at all, we are not affected by its limitations as we did not need the extra features found in the MSC, so i encourage you to go for it if it is sufficient for your needs. I've ran both the FP-40 and FP-140. They just work, particularly in a BGP-free MPLS core. The key differences between the FP and MSC is the forwarding capacity. The FP-40 is rated at 45.5Mpps while the MSC-40 is 60Mpps, although both will do line rate. When used as an edge router, the FP-40 will also handle significantly fewer entries related to typical edge features such as number of VRF's per line card, number l2vpn pw's per line card, e.t.c. The FP-40 also has fewer QoS queues than the MSC-40. If you ever heard of the ASR14000 that never did get off the ground, well, that is what became the FP-40. The FP forwarding processors were initially developed by Cisco for customers that wanted to use the CRS as a peering or border router, but felt the MSC was too big. The ASR14000 idea was born, but as with the current ASR9000 (personal opinion), I guess Cisco saw the potential for overlap in the core routing space, hence the FP-40. One processing engine I've never quite used but have always been curious about is the LSP (Label Switch Processor): http://www.cisco.com/en/US/prod/collateral/routers/ps5763/data_sheet_c78-659947.html It is aimed at operators that have a strong need for MPLS- based cores, where in all likelihood, pretty much any packet running through the router will be MPLS-based. My main issue with such a line card is how well it supports IPv6, since IPv6 control planes for LDP and RSVP are still not yet out the cave, and the last thing you need is IPv6 falling over because the LSP either didn't support it or supported a very scaled down version of it. That aside, I exclusively purchase FP-40's or FP-140's for my CRS deployments. I wouldn't touch an MSC. Too much bang for too much buck. Hope this helps. Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Sup2T / EARL8 Netflow oddities
Jeroen van Ingen writes: Our university upgraded from Cat6k/Sup720-3B to Cat6k/Sup2TXL a while ago. Recently a few researchers who use our NetFlow data noticed that the NetFlow exports sometimes contain strange values: there are flow records with a negative duration (flow end before flow start time) and some exported flows are far (1 month) in the past or future. We're currently running IOS 15.1(1)SY. Has anyone else noticed something similar? Yes, in all releases since we got our first Sup 2Ts. Quite annoying. No idea whether this was already reported to Cisco as a bug. If this happens, the start time looks reasonable, but the end time is typically around 4194 seconds *lower* than the start time. In my own code, I fix this by increasing the end time by 4194 seconds (maybe 4195 would be better). If anyone wants to check their NetFlow v9 exports: Wireshark will show flowsets containing flow records with negative duration when using the display filter 'cflow.timedelta 0'. Great tip, thanks! As an illustration, here's an extract of a decoded trace of Netflow v9 packets from one of our Sup 2T routers. It shows the range of the time differences: $ tshark -V -d udp.port==9910,cflow -r ce3-flows.pcap 'cflow.timedelta 0' | grep 'Duration: -' [Duration: -4194.05000 seconds] [Duration: -4194.05000 seconds] [Duration: -4194.05000 seconds] [Duration: -4194.05000 seconds] [Duration: -4194.05000 seconds] [Duration: -4194.05000 seconds] [Duration: -4194.05000 seconds] [Duration: -4194.05000 seconds] [Duration: -4194.05000 seconds] [Duration: -4194.1 seconds] [Duration: -4194.1 seconds] [Duration: -4194.1 seconds] [Duration: -4194.05000 seconds] [Duration: -4194.05000 seconds] [Duration: -4194.05000 seconds] [...] -- 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/
