cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
605
Views
10
Helpful
3
Replies

Measuring routing protocol convergence in a small topology

Adasko
Level 1
Level 1

Hi friends,

I hope you can help. I am running a project where I want to test EIGRP and OSPF convergence on a small topology with 4 routers and 2 end hosts (PCs). However, I am struggling to understand how to calculate the convergence upon a link failure and device failure in the network.

I have ran a simulation where I have sent a modified packet continuously in the network from PC1 to PC2. During this time, I have simulated a link failure and that’s where OSPF started to reconverge. From the event log it shows that OSPF reconverged within milliseconds. But when I read online, many suggest that convergence can be determined by the number of packets lost in the transmission.

I also ran a basic ping -t command in real-time but when I performed the link failure, there was no visible downtime from the pings received on the machine. 

I am still new to Cisco Packet Tracer therefore wonder, does anyone know how these time data can be gathered from a Cisco simulator?

I would very much appreciate your help.

 

3 Replies 3

balaji.bandi
Hall of Fame
Hall of Fame

Its all depends on the topology and redistribution taking place - you may notice 1 ping loss if the timers are tweaked in the best way.

since you are connected directly with a small topology you will not see that difference when you ping PC1 to PC2

May extend the network with more Routers in the path like ABR/ASBR/Stub routers in the path, you may see small difference of ping loss if you have dual path in the network.

The good thing is OSPF do support up to 16maximum paths, you can also control using maximum path X

more information can be find here :

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/15-sy/iro-15-sy-book/m_iro-update.html

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Hello, 

Packet Tracer is (obviously) a simulation tool, so it might not be the best for monitoring and detecting microsecond or millisecond delays. It has a simulation mode which displays delays (see screenshot).

In general. EIGRP is faster than OSPF. EIGRP also supports unequal cost load balancing, which is a useful feature.

Joseph W. Doherty
Hall of Fame
Hall of Fame

"But when I read online, many suggest that convergence can be determined by the number of packets lost in the transmission."

Well, much depends, I guess, what you mean by convergence.  Further, packet loss, when it's impacted by a convergence event, would be a very gross or inexact way of measuring convergence time.

To me, a converged network is one where all the routers have an accurate representation of the actual current state of the network's topology.  If there's any network topology change (which might be logical or physical) the network will need to re-converge to once again have an accurate representation of the actual current state of the network's topology.

Regarding using drops as a convergence metric, consider two routers with dual routed links between them, if running OSPF or EIGRP, I can have both links with same or different costs, but I change one of those links metric, I might shift traffic around on one of the links.  Will doing this, cause any packet drops?  It should not.  Is this a convergence event?  Well, the router you change will, with OSPF or EIGRP, "notify" its routing peers of the change, so they can update their representation of the topology.

Now instead of one router with two links, I have two separate routers, downstream of another router.  Each of those routers has a link that will reach the same destination.  Again, changing a cost metric, traffic may shift its actual path through the network.  In this situation, unlike the prior, packet loss may occur, although no links are down.  This because, unlike before, the upstream router, and even the other router with a link to destination, will re-converge so as to redirect that destination's packets to the "new" better path.

Interestingly, in the last example, whether there's packet loss or not, much depends on whether the topology change is "better" path now available, or you've lost the "best" path.  (The latter, may cause routing loops while network re-converges.)

The only "true" way, to measure convergence time, would be somehow log the time of some topology event, and then log the times all the routers have correctly processed event.  (Understand, depending on the topology change, correct operations might not require all routers to have converged, but the network isn't fully converged until all do.)

How to get the times, from each router, might require debugging options and/or advanced logging options.

Lastly, whatever time PT takes, likely would not represent actual times using "real" equipment.

Also, understand, actual convergence times also can much depend on how various OSPF and EIGRP Cisco timers are set, and what the events are.  (For example, if there's a "flapping" event, Cisco has [increasing long] back-off timers, to delay notifying routers of the event.)

Review Cisco Networking for a $25 gift card