OSPF and EIGRP Convergence Understanding.

[JohnTylerPearce]

Let's say in my OSPF network, with 3 areas, area 0, area 1, area 2, all areas are connected correctly, no virtual-links, etc.

Now, in Area 0, R1 links to R2, noticed via (network pulses | carrier-delay), that the link has gone down, will it immediately

start to reconverge or will it continue to wait until the hold time?

I'm assuming if the link is not down, and it noticed no Hellos received for more than the Holdtime it will obvously

re converge.

Now, let's say R1 only has 1 link to R2, I'm assuming R2 will send a LSU/LSA with max cost 16,777,215, letting all other

routes know that this route has gone down?

My other question is, with EIGRP, when it has the same thing happen, I know EIGRP will immediately look in its topology table, for a Feasible Successor Route, and if it can't find one, it will look for a "Possible" route, which doesn't pass the Feasbility Condition, but as of this moment it's the only option, now if it can't find any of these it will start the query process etc etc.

I'm assuming if it installs a router, it will send out an EIGRP multicast update 224.0.0.10, to let all other routers know of this new route?

I'm trying to get really technical in udnerstanding the BIG picture if you will.

[Richard Burts]

John

I appreciate trying to understand the BIG picture, but there are a number of technical details that get in the way trying to understand your question and to formulate good answers.

- What kind of link connects R1 and R2? If it were P2P serial link then a link failure could be immediately detected.  If it is Ethernet then detection of the failure becomes more complicated and may depend on not receiving hello packets.

- Is it an environment where something like BFD might be deployed that would make immediate detection possible?

- If the connection is some multi-access network like Ethernet, then for OSPF there are questions such as which router is DR that complicate the situation.

There are similar questions with EIGRP except to the question about DR.

I am a little puzzled with your paragraph about the process in EIGRP, especially the part about a "Possible" route. EIGRP is fairly straightforward in this. When an EIGRP router loses a route to some prefix then it will look for a feasible successor. If it finds a feasible successor then that is immediately put into the routing table. If there is no feasible successor then the EIGRP router puts the prefix into the active state and begins the query process for that prefix.

HTH

Rick

[Peter Paluch · Accepted solution]

John and Rick,

Please allow me to join.

While I agree that to answer this question as precisely as possible, we would need to know better the network in question. However, some general ideas can be answered right away.

Now, in Area 0, R1 links to R2, noticed via (network pulses | carrier-delay), that the link has gone down, will it immediately start to reconverge or will it continue to wait until the hold time? 

As soon as an OSPF router notices an OSPF-enabled interface going down, it will drop all adjacencies over that interface, issue an updated LSA that omits this link, flood it, and recalculate the shortest path tree. As other routers receive the updated LSA, they also recalculate the new shortest path tree on their own. There may be artificial delays involved regarding to origination of LSAs, scheduling the SPF runs, but the basic algorithm stands.

I'm assuming if the link is not down, and it noticed no Hellos received for more than the Holdtime it will obvously re converge.

If the link towards a neighbor does not go down then there is no event on which OSPF could react. As a result, the router would need to wait for the Dead interval to expire to know that the neighbor is no longer reachable.

Now, let's say R1 only has 1 link to R2, I'm assuming R2 will send a LSU/LSA with max cost 16,777,215, letting all other routes know that this route has gone down?

The max cost can be used with LSA types 3, 4, 5, 7, but this is not usually done. With LSAs 1 and 2, if a link goes down, the affected router simply generates a new LSA that does not claim this link to be present anymore. If the updates LSA does not list the link then it's not there. It's that simple. With LSA types 3-5, 7, routers usually perform a premature aging procedure on these LSAs rather than claiming infinite cost: they simply originate the LSA with the Age set to 3600 seconds, causing the LSA to be flushed from other routers' LSDBs.

My other question is, with EIGRP, when it has the same thing happen, I  know EIGRP will immediately look in its topology table, for a Feasible  Successor Route, and if it can't find one, it will look for a "Possible"  route, which doesn't pass the Feasbility Condition, but as of this  moment it's the only option, now if it can't find any of these it will  start the query process etc etc.

With EIGRP, this is the true process:

1. After you detect a distance increase to a destination, check your topology table and find a neighbor providing the new least total cost path.
2. If you have found such a neighbor, check whether this neighbor is a Feasible Successor. If there is no such neighbor at all, or if the neighbor is not a Feasible Successor, put the destination into the Active state and start sending Queries. Otherwise, promote the Feasible Successor into the Successor role and start using it as the next hop.

Rick, note this is in a slight contradiction to what you have stated - and what most sources state, but this approach is what EIGRP really does. There are situations in which a Feasible Successor provides a worse backup path than a neighbor that does not pass the Feasibility Condition check but that nevertheless is loop-free. Sticking to Feasible Successor would cause EIGRP to be satisfied with a worse-than-best path if the current Successor failed.

I'm assuming if it installs a router, it will send out an EIGRP  multicast update 224.0.0.10, to let all other routers know of this new  route?

I am sorry - I am losing you here, John. Can you perhaps rephrase this?

Best regards,

Peter

[JohnTylerPearce]

First of all, thanks to Peter and Rick from providing "exceptional" feel back.

First to Rick,

I understand aout BFD, and it's a very good idea to use this technology. I have actually implemented this at my current job.

Also, I understand with Ethernet, it's completely possible, that a direct link from R1 and R2, may be through a switch, So while R2 could be done, the link from R1 to the switch port can stil be up.

To Peter,

Sorry, I think I was thinking about something totally different and typed it out (Have you ever done that?)

Sometimes I do so much studying, have questions left unanswered, working as a Tier III Network Engineer, etc etc, that I forgot to ask question on this board, so I try to type stuff as fast as possible.

It makes complete sense, that if in a single area, that if a link went down, it would generate an LSA, without it including this link (Hence the LSA Type 1's responibility). So all the other routers in the area, would know not see this link, and obviously have to recalculate the SPT.

Sometimes keeping up with your CCNP, Studying for CCIE, maintaiing all knowledge of MCITP Enterprise Administrator, and a variety of VMware technologies, can cause your brain to be mush lol..

Once again, thanks Peter and RIck for the great help, this is exactly what I was looking for.

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

There may be artificial delays involved regarding to origination of LSAs, scheduling the SPF runs, but the basic algorithm stands.

John, just wanted to add, regarding Peter's mention of "artificial delays", indeed there are, and on Cisco platforms there are often OSPF configuration options to change certain timers to improve OSPF's convergence time.  Cisco's defaults aren't too bad, but if you're working to support VoIP, and faster convergence is needed, you'll want to learn more about them.