Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!NSIPO.ARC.NASA.GOV!medin From: medin@NSIPO.ARC.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) Newsgroups: comp.protocols.tcp-ip Subject: Re: Serious Routing Problems Message-ID: <9007311833.AA22548@nsipo.arc.nasa.gov> Date: 31 Jul 90 18:33:13 GMT References: <61620@bu.edu.bu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 31 Kent, I'm a little confused here. Line flapping should be fixed by having hystersis in the up/down line protocol. It's been our experience that OSPF in our system reroutes completely after about 3 seconds on average after the dead link is detected. OSPF has it's timers set up in a way as to avoid link flap causing a lot of simultaneous LSP flooding, due to deliberate jitter in the timers (LSP's being flooded from all the gateways connected to a down net). As for link up/downs going on every few seconds, we haven't had experience with that sort of situation, but in the case of a link that flaps every couple of minutes, that seems to work fine. Because link-state protocols flood the topology information, and then the routers recompute the routing tables more or less in parallel, convergence can happen very quickly, and you also can do without the complicated holddowns and such needed to prevent route looping in vector-distance protocols. This should be true for any reasonably well implemented link-state protocol. It's just easy to do this part right. You can certainly screw up in other ways, but if you want fast convergance, fast enough to avoid lining up hundreds of user TCP connections against a wall and killing them in rapid sucession, you really need to use a link-state protocol. This is one reason why noone has bothered to build a new vector distance IGP in quite some time. Even the new proprietary IGP's these days are link-state based... BARRNET also runs OSPF now, and those guys can tell you more about how it's performance has been. Thanks, Milo