[133799] in North American Network Operators' Group
RE: OSPF convergence - WAN links
daemon@ATHENA.MIT.EDU (Jeff Saxe)
Fri Dec 17 08:59:34 2010
From: Jeff Saxe <jsaxe@briworks.com>
To: Rafael Ganascim <rganascim@gmail.com>, "nanog@nanog.org" <nanog@nanog.org>
Date: Fri, 17 Dec 2010 05:59:26 -0800
In-Reply-To: <AANLkTikUPyXO6Ksy2Bt82wTTa=Uf1dFsSTTMdt2w0771@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
If your routers support Bidirectional Forwarding Detection (BFD), then I wo=
uld suggest using that. It doesn't actually modify the hello timers or any =
other timers of any protocol; it merely acts as a supplementary protocol ru=
nning under (or alongside, I guess) the main routing protocol, and its spec=
ialty is detecting failure along MAN circuits, virtual circuits, Ethernet V=
LANs, and other kinds of circuits in which you don't actually see a Link Do=
wn when the circuit is interrupted.
http://en.wikipedia.org/wiki/Bidirectional_Forwarding_Detection
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fs_bfd.html
The nice thing about BFD is that it's optional on a per-interface and per-p=
eer basis, so you don't have to tune the hellos aggressively for the other =
10 peers who are on simple, local, or serial links just to get quicker fail=
ure detection for that one guy who's off on a virtual circuit. So in your c=
ase, on a Cisco for example, it might be as simple as
interface Gig0/0/2
bfd interval 800 min_rx 50 multiplier 7
ip ospf bfd
(You'd have to do this on both sides of the link.) Now when the OSPF neighb=
or is established, it will also try to establish a back-and-forth-packet BF=
D session to the same OSPF neighbor, and if it does successfully establish =
it, then it will keep sending packets every 800 milliseconds. Then if the B=
FD packets stop coming for 800ms*7=3D5.6 seconds, then BFD will inform OSPF=
that the neighbor is down, even if OSPF hasn't "naturally" discovered that=
yet. "show bfd neighbors" to see whether it's working. You can tune BFD ve=
ry aggressively if you want... 50ms intervals and multiplier of maybe 5 or =
3 I think, so you can make a failure occur in 250ms or less, if the applica=
tion is that sensitive.
In my experience it works great and does exactly what it's designed for. I =
use it for BGP peers within my AS and with some customers.
-- Jeff Saxe
Blue Ridge InternetWorks
Charlottesville, VA
________________________________________
From: Rafael Ganascim [rganascim@gmail.com]
Sent: Friday, December 17, 2010 8:33 AM
To: nanog@nanog.org
Subject: OSPF convergence - WAN links
Hi all,
I have a network with a lot of FastEthernet WAN connections (some
metro-ethernet), and using the OSPF as IGP. Today, the OSPF timers are the
defaults (hello 10s, dead 40s, SPF initial timer 5s, etc). When a link come=
s
down, the convergence time takes ~45s (ok, it's right).
There are a lot of documents explaining about tuning OSPF convergence time,
but on LAN environments. I didn't find any references about this OSPF tunin=
g
on WAN ethernet links (just serial, frame-relay, etc) and things related t=
o
it (such as packet loss, rtt, 'never lost of carrier', etc).
I think that, if the timers are aggressive, any flap on the ISP network can
cause a re-convergence... if the timers are high, the convergence time on
down links is high too.
What factors are you considering when tuning this OSPF timers on this type
of link? What 'tecnologies' are you using (such as Fast Hellos, incremental
SPF, etc) ?
Thanks,
Rafael
