Re: OSPF slow reconvergence

Matt,
Convergence time is equal to sum of detection, propogation,process and
update.
 
So, you may have to consider these timers for excat convergence
time caculation.
 
Also, Dynamips will give testing results on higher side.
Regards,
Aman
 From: Alexei Monastyrnyi <alexeim73_at_gmail.com>
To: Matt Sherman
<matt.sherman2_at_gmail.com>
Cc: Cisco certification <ccielab_at_groupstudy.com>
Sent: Friday, 29 April 2011 9:14 AM
Subject: Re: OSPF slow reconvergence
Matt,
try to google OSPF tuning, there is quite q bit of good articles
covering the subject. As for Dynamips, you should not rely on it for
this
sort of performance tests, it is always going to show poor results
because it
runs as a regular bunch of threads and compete for CPU
resources with other
applications running on top of host OS. Try it on a
real gear, there are
remote labs out there which you can play with just
for 12 dollars per 3
hours.

HTH
A.

On 4/30/2011 12:00 AM, Matt Sherman 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
>
>
Received on Sun May 01 2011 - 09:22:24 ART