Header
Home | Set as homepage | Add to favorites
  Search the Site     » Advanced Search
Sections
Syndication


Blogroll:

||||| ALL Cisco-Network ARTICLES |||||  
CCIE Journey,
The CCIE Journey,


IGRP Convergence

Nov 27,2008 by alperen

image

IGRP Convergence
Despite the leaps and bounds Cisco has taken in improving RIP convergence, IGRP still converges
according to the standard theory, by default, taking quite a bit of time if left to its own
devices, but resulting in an environment that is more resistant to some forms of network instability.
IGRP resets its invalid and holddown timers each time an update is received, including
triggered updates, but IGRP does not immediately reset its flush timer when it receives a triggered
update that a route is down. It waits until the next scheduled update time to start the flush
timer. What this means is that the flush time could be as much as 90 seconds longer than configured,
when measured from the triggered update that advertises the route as unreachable. A
well-placed clear ip route * command will speed things along, though.
The following process can be modeled in the lab by issuing the shutdown command on the interface
of Router D that faces Router F. Using Figure 1.2 as an example, let’s take a look at IGRP
convergence, keeping in mind that the following enumerated list is not necessarily in chronological
order, nor could an exact order be guaranteed:
1. Router D detects the failure on the link to Router F. Router D poisons this directly connected
route in its own routing table by removing it, as well as the route for the Ethernet
segment off of Router F, because this link was in the path to get there. Router D sends a triggered
update to Routers C and E.
2. Router F detects the failure on the same link and poisons the route locally, as well as any
routes with Router D’s nearest interface address or Router F’s interface on that link as a
next hop. Router F sends out a triggered update to Router E, detailing these lost routes.
3. Router C sends a triggered update to Router B, and Router B sends one to Router A. Routers A,
B, C, and E all start invalid and holddown timers for each of the inaccessible routes, unless there
was one or more equal-cost paths (or unequal, with use of the variance command) to one or
more of them, in which case the downed route will be removed and all traffic will use the
remaining route or routes. At the next scheduled update time for each route, the routers will
start the routes’ flush timers, unless the original source notifies the routers that the links are back
up, in which case the route is reinstated as an operational routing table entry.
One tricky point of contention here is that the routing table will likely say “is
possibly down” next to the destination network, even when the route has been reestablished.
Attempts at verifying connectivity through ping or traceroute should
meet with success, regardless. Some nominal amount of time after the holddown
timer expires, you’ll be able to observe the route entry returning to its normal state.
Issuing the clear ip route * command will speed the process along.
4. Router D broadcasts a request to Router C. Both Router D and Router F broadcast a
request to Router E, basically to all remaining active interfaces, asking for the entire routing
table of each router in hopes of jump-starting new methods of access to the lost networks.
Router C sends back a poison-reverse response to Router D for those routes it originally
learned through Router D that are affected by the outage. Router E does the same for
Router F.
26 Chapter 1  Routing Principles
5. It’s where Router D and its downed WAN link are concerned that Router E could create a slight
mess initially. The good news is that Router D will learn the alternate—and currently the only—
route to the Ethernet segment off of Router F. Router D’s request may well arrive at Router E
before Router F’s triggered update, as three keepalives must be missed before Router F will consider
the link down and you manually shut the link down on Router D’s side. In such a case,
Router E will unicast its reply to Router D that the downed link is available through Router E.
This is because Router E had an equal-cost alternative path to the downed network that it
learned through Router F. So, to advertise Router E’s alternative path to Router D as accessible
is not a violation of the poison-reverse rule. That’s only for affected routes that Router E learned
through Router D, of which there are none. Router E is content to advertise only a single route
for each unique destination, and the route through Router F will do nicely—or will it? Because
Router D removed its own directly connected route entry, there is nothing stopping it from
using this new advertisement that once looked suboptimal when Router D itself had direct
access to this network. The triggered update from Router F initiates a triggered update from
Router E, and a subsequent resetting of all the appropriate timers, which serves to set Router D
straight that the network is truly down.
6. At this point, it appears that the route is possibly down, but the path through Router E
apparently has become engraved in the routing table, while attempts to ping an interface
on the downed network will no doubt fail. This is only IGRP’s optimism showing
through, erring on the side of too much information. Remember, even after the link has
been re-established, this confusing entry will remain, and the holddown timer will have
to expire before the entry is cleaned up and joined by its equal-cost partner. Again, clear
ip route * works like a charm here to get you back to where you feel you should be.
Additionally, watching the festivities through debug ip igrp transactions will clarify
this process and reassure you that Router D has been informed that the route truly is
down, in any direction. Still, Router D is confused enough to return alternating destination
unreachable messages, instead of the usual timing out, during ping, as long as the
network remains down.
7. Router D then sends a triggered update out all active interfaces participating in the IGRP
routing process for the appropriate autonomous system, which includes this new entry.
8. Routers A, B, and C receive this update in turn. They would ignore the new route since it is
in holddown, but because each one receives the update from the source of the original route,
they each implement the new route, although the entry in the table will not appear to change
until after the holddown timer expires. Because they point to the previous next hop still,
connectivity will tend to be maintained. While in holddown, each router will continue to use
poison reverse for the affected routes, back toward their respective advertising router.
9. Once all holddown timers expire, respective routing tables are then updated with an accurate
routing table entry.
Without triggered updates and dumb luck or the smart design of the IGRP protocol that gets
these routers to continue to use suspect routes to successfully pass traffic, the time it could take
for Router A to converge could be the detection time, plus the holddown time, plus two update
times, plus another update time, which is over 490 seconds.
251 times read

Related news

» IGRP Timers
by alperen posted on Nov 27,2008
» RIP Convergence
by alperen posted on Nov 27,2008
» EIGRP Convergence
by alperen posted on Nov 27,2008
» IGRP Features
by alperen posted on Nov 27,2008
» Adjusting Timers
by admin posted on Jul 21,2008
Did you enjoy this article?
(total 0 votes)

comment Comments (0 posted) 

More Top News
CCSP-Cisco Certified Security Professional
Most Popular
Most Commented
Featured Author