Re: OSPF slow reconvergence

I should also mention that it depends... for instance, the neighbor would
be brought down immediately if a point-to-point link fails (like Gig E).
Also, convergence would be much faster if another equal cost path is in the
routing table. Basically it depends on the network design, type of failure,
etc.
On Apr 29, 2011 10:07 AM, "Ronnie Angello" <ronnie.angello_at_gmail.com> wrote:
> It would detect loss of neighbor within that time, but it still has to
> generate and propagate an LSA, run SPF, and update the forwarding tables.
> The failure detection is just a piece of convergence.
> On Apr 29, 2011 10:00 AM, "Matt Sherman" <matt.sherman2_at_gmail.com> wrote:
>> Hello,
>>
>> Just curious if anyone can shed some light on this. If you have OSPF
hello
>> and dead timers set to 1 and 4 respectively, shouldn't OSPF reconverge
>> within 4 seconds of the loss of a neighbor? When I look at the routing
>> debugs in Dynamips it takes 6 seconds from the notification of OSPF being
>> down until the alternate route is added into the table.
>>
>> I have a real world scenario where we are peering Cisco ASA firewalls
with
>> Nortel ERS 8600 switches. The lowest the Nortel / Avaya engineers will
>> allow us to go down to is 1 and 4. The switches do not have millisecond
>> timers anyway so the lowest possible is 1 and 2. It's taking close to 10
>> seconds in that case which is not a good thing for VOIP.
>>
>> Just wondering if this is the expected behavior for OSPF. The Avaya
>> engineers don't think so but testing in Dynamips seems to confirm it is.
>>
>> Thanks,
>> Matt
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Fri Apr 29 2011 - 10:11:04 ART