[c-nsp] Fast IGP on 6500 gigE
All, Given a mix of 6748-SFP, 6704 and 6716 linecards, with SXI software, and OSPF over SVIs, what are people successfully using to speed up link loss and subsequent IGP convergence? Our config broadly looks like: int Vlan38xx description p2p to another router ip address 192.168.0.2 255.255.255.254 ip ospf network point-to-point int Te1/1 switchport switchport mode trunk switchport trunk native vlan 38xx router ospf 1 ispf nsf network 192.168.0.0 0.0.0.255 ...and then the various LDP BGP configs on top. I'm assuming I want some combination of: 1. debounce / carrier-delay (what's the difference) on the gigE 2. IP event dampening on the SVI 3. faster timers on the SFP process; possibly as a conservative start: timers throttle spf 10 100 5000 timers throttle lsa all 10 100 5000 timers lsa arrival 80 The idea is that most routers are dual-attached, so I just want to underlying IGP to converge quickly. I'll tackle the LDP and BGP later... I'm not able to use BFD (since it doesn't work on SVIs under SXI) and I'm only worried about physical link-down - we don't have any weird layer2 between routers except in a few out-of-the way places, and they can just suffer. I realise some of these answers are it depends on the size of your network; there are ~25 routers participating in the OSPF, all reasonably recent and modern, it's a single area 0 design, and it has ~58 p2p loopbacks (via router LSAs) another 18 E2 routes. It seems to take ~6msec for an OSPF adjacency to form between two routers, almost all of which is in INIT-2WAY so I'm guessing SPF is going to be pretty quick. Suggestions welcome, although ask Cisco to tell you is less helpful; I'd like to have some independent understanding of how we arrived at the numbers, and be able to repeat the process in future ;o) ___ cisco-nsp 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] Fast IGP on 6500 gigE
Hi, you've written most routers are dual-attached, so the concern mostly is failure detection and not re-establishment of a neighbor I think. If you go into debounce or carrier-delay you'll raise the convergence time as a link failure will be ignored for a short time before processes are notified. OSPF should immediately react on an link-down event, so I'd try to speed it up this way. If you use 2 separate SVI for the 2 connections and each VLAN has only 1 port it is allowed in (either a single access port or exactly 1 trunk port) the SVI should go down along with that single port. Playing around the timers I keep for last resort - as there's always the risk to de-stabilize the network seriously (I've seen people trying to get the last second out of a protocol resulting in occasional burn-downs far too often). regards, Marcus -Ursprüngliche Nachricht- Von: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] Im Auftrag von Phil Mayers Gesendet: Montag, 16. März 2009 17:45 An: cisco-nsp@puck.nether.net Betreff: [c-nsp] Fast IGP on 6500 gigE All, Given a mix of 6748-SFP, 6704 and 6716 linecards, with SXI software, and OSPF over SVIs, what are people successfully using to speed up link loss and subsequent IGP convergence? Our config broadly looks like: int Vlan38xx description p2p to another router ip address 192.168.0.2 255.255.255.254 ip ospf network point-to-point int Te1/1 switchport switchport mode trunk switchport trunk native vlan 38xx router ospf 1 ispf nsf network 192.168.0.0 0.0.0.255 and then the various LDP BGP configs on top. I'm assuming I want some combination of: 1. debounce / carrier-delay (what's the difference) on the gigE 2. IP event dampening on the SVI 3. faster timers on the SFP process; possibly as a conservative start: timers throttle spf 10 100 5000 timers throttle lsa all 10 100 5000 timers lsa arrival 80 The idea is that most routers are dual-attached, so I just want to underlying IGP to converge quickly. I'll tackle the LDP and BGP later... I'm not able to use BFD (since it doesn't work on SVIs under SXI) and I'm only worried about physical link-down - we don't have any weird layer2 between routers except in a few out-of-the way places, and they can just suffer. I realise some of these answers are it depends on the size of your network; there are ~25 routers participating in the OSPF, all reasonably recent and modern, it's a single area 0 design, and it has ~58 p2p loopbacks (via router LSAs) another 18 E2 routes. It seems to take ~6msec for an OSPF adjacency to form between two routers, almost all of which is in INIT-2WAY so I'm guessing SPF is going to be pretty quick. Suggestions welcome, although ask Cisco to tell you is less helpful; I'd like to have some independent understanding of how we arrived at the numbers, and be able to repeat the process in future ;o) ___ cisco-nsp 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] Fast IGP on 6500 gigE
Marcus.Gerdon wrote: Hi, you've written most routers are dual-attached, so the concern mostly is failure detection and not re-establishment of a neighbor I think. Correct If you go into debounce or carrier-delay you'll raise the convergence time as a link failure will be ignored for a short time before processes are notified. Further reading indicates that carrier/debounce are by default as low as you can safely get them on a 6500, so I think I can disregard these. OSPF should immediately react on an link-down event, so I'd try to speed it up this way. If you use 2 separate SVI for the 2 connections We're already doing this. and each VLAN has only 1 port it is allowed in (either a single access port or exactly 1 trunk port) the SVI should go down along with that single port. It does. Interestingly info I've read indicates that routed interfaces signal upper-layer protocols much faster than SVI interfaces, which is something I'll have to investigate. Playing around the timers I keep for last resort - as there's always the risk to de-stabilize the network seriously (I've seen people trying to get the last second out of a protocol resulting in occasional burn-downs far too often). Hmm. Further digging has some pretty concrete recommendations from Cisco in presentations and such suggesting: timers throttle spf 10 100 5000 timers throttle lsa all 10 100 5000 timers lsa arrival 80 e.g. http://www.ciscoexpo.sk/slides/41-vsettey_fast_convergence.pdf The default SPF initial delay is 5 *whopping* seconds; which means that, no matter how fast your link detection and SPF propagation is, it'll be at least 5 seconds before you even *start* trying to converge. Having read the docs, I have a hard time seeing how changing these can burn down the network - the spf and lsa timers have exponential backoff. Would you care to elaborate on the failure modes you have seen? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
