Fwd: RIP Timers

Mate, don't give up :-)

Topology realy simple

3 Routers each with 2 FastEthernet full mash no switchs

The Advertising router R1 have a loopback interface with network *
10.0.150.0/24 (see diagram)*

illustration diagram
                     R1
                   / \
                  / \
                 R2----R3

once you shut the interface from R1 to R3
R3 will get the *10.0.150.0/24 from R2 with higher metric*
*As it has already a lower metric and he didn't receive an update from R1 he
will start count the holddown timer.*
*
*
*at the end of the timer he will update the table with the higher metric. if
he would received an update from R1 directly during that time the counter
would be terminated.*
*
*
*
*
*The invalidate Timer is different (but you can try now in your own setup),
instead of shutting down the interface between R1 to R3 just remove the
loopback interface what R1 will do he will multicast a poison route to
10.0.150.0/24 by sending the network with metric 16.... come on do the lab
and see the rest yourself*
*
*
On Mon, Mar 22, 2010 at 12:27 PM, Cristian Matei <cristian.matei_at_datanets.ro
> wrote:

> Hi Shiran,
>
>
>
> I can guarantee youre wrong here; if you could just let me
> know the exact topology youre using here.
>
> One thing: if routers are directly connected than how is Fa0/0 still up, if
> you terminated the interface on the other end; or by terminating you mean
> you removed it from the RIP process with passive?
>
>
>
>
>
> Of course, if u dont want to continue you can live on with this assumption
> J
>
> 10.0.0.0/24 is subnetted, 4 subnets
>
> R 10.0.2.0 [120/1] via 10.0.1.2, 00:00:03, FastEthernet1/0
>
> C 10.0.0.0 is directly connected, FastEthernet0/0
>
> C 10.0.1.0 is directly connected, FastEthernet1/0
>
> *R 10.0.150.0 [120/2] via 10.0.1.2, 00:00:03, FastEthernet1/0*
>
>
>
> Regards,
>
> Cristian.
>
>
>
> *From:* shiran guez [mailto:shiranp3_at_gmail.com]
> *Sent:* Monday, March 22, 2010 11:57 AM
>
> *To:* cristian.matei_at_datanets.ro
> *Cc:* Erwin van Harrewijn; kebramccie_at_gmail.com; ccielab_at_groupstudy.com;
> tosara_at_gmail.com
> *Subject:* Re: RIP Timers
>
>
>
> no cristian it is not due to Invalidate timer, that is the holddown and
> they are not connected through a switch they are directly connected.
>
>
>
> I think this ping pong is going on too long, you can keep on argue on that
> but I choose now to back off as I do not see any benefit from
> this discussion.
>
>
>
> Have a good day :-)
>
> On Mon, Mar 22, 2010 at 11:11 AM, Cristian Matei <
> cristian.matei_at_datanets.ro> wrote:
>
> Hi Shiran,
>
>
>
> I believe routers are NOT directly connected but through a
> switch, correct?
>
>
>
> What youre seeing below happening is due to the INVALID timer and NOT the
> holddown timer.
>
>
>
> *Mar 1 00:11:29.471: RIP: build flash update entries
>
>
> *Mar 1 00:11:29.471: 10.0.150.0/24 via 0.0.0.0, metric 16, tag 0 *<<
> holddown timer ended ~180 sec*
>
> *Mar 1 00:11:33.819: RIP: received v2 update from 10.0.1.2 on
> FastEthernet1/0
>
> *Mar 1 00:11:33.823: 10.0.2.0/24 via 0.0.0.0 in 1 hops
>
>
> *Mar 1 00:11:33.827: 10.0.150.0/24 via 0.0.0.0 in 2 hops
> * << updating Table*
>
>
>
>
>
> Regards,
>
> Cristian.
>
>
>
> *From:* shiran guez [mailto:shiranp3_at_gmail.com]
> *Sent:* Monday, March 22, 2010 10:29 AM
>
>
> *To:* cristian.matei_at_datanets.ro
> *Cc:* Erwin van Harrewijn; kebramccie_at_gmail.com; ccielab_at_groupstudy.com;
> tosara_at_gmail.com
> *Subject:* Re: RIP Timers
>
>
>
> and just to add to that:
>
>
>
> ########### BEFORE notice to route *10.0.150.0/24 installed with metric 1*
>
> *Gateway of last resort is not set*
>
> * *
>
> * 10.0.0.0/24 is subnetted, 4 subnets*
>
> *R 10.0.2.0 [120/1] via 10.0.1.2, 00:00:12, FastEthernet1/0*
>
> * [120/1] via 10.0.0.2, 00:00:14, FastEthernet0/0*
>
> *C 10.0.0.0 is directly connected, FastEthernet0/0 *
>
> *C 10.0.1.0 is directly connected, FastEthernet1/0 *
>
> *R 10.0.150.0 [120/1] via 10.0.0.2, 00:00:02, FastEthernet0/0*
>
> * *
>
> *Mar 1 00:07:53.527: RIP: received v2 update from 10.0.0.2 on
> FastEthernet0/0
>
> *Mar 1 00:07:53.531: 10.0.2.0/24 via 0.0.0.0 in 1 hops
>
>
> **Mar 1 00:07:53.535: 10.0.150.0/24 via 0.0.0.0 in 1 hops *
>
>
> *Mar 1 00:07:54.267: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet0/0 (10.0.0.1)
>
>
> *Mar 1 00:07:54.271: RIP: build update entries
>
>
> *Mar 1 00:07:54.271: 10.0.1.0/24 via 0.0.0.0, metric 1, tag 0
>
>
> ########### "Suddenly" I terminated interface one of the interfaces on
> router
>
> *10.0.0.2 making him advertise the network trough a diffrent interface and
> causing a "suddent" increase in metric to 10.0.150.0/24 now lets count
> together*
>
> *Mar 1 00:07:54.523: RIP: received v2 update from 10.0.1.2 on
> FastEthernet1/0
>
> *Mar 1 00:07:54.527: 10.0.2.0/24 via 0.0.0.0 in 1 hops
>
>
> *Mar 1 00:07:54.531: 10.0.150.0/24 via 0.0.0.0 in *2 hops*
>
>
> *Mar 1 00:07:55.175: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet1/0 (10.0.1.1)
>
>
> *Mar 1 00:07:55.179: RIP: build update entries
>
>
> *Mar 1 00:07:55.179: 10.0.0.0/24 via 0.0.0.0, metric 1, tag 0
>
>
> *Mar 1 00:07:55.183: 10.0.150.0/24 via 0.0.0.0, metric 2, tag 0
>
>
> *Mar 1 00:08:19.039: RIP: received v2 update from 10.0.0.2 on
> FastEthernet0/0
>
> *Mar 1 00:08:19.043: 10.0.2.0/24 via 0.0.0.0 in 1 hops
>
>
> *Mar 1 00:08:19.047: 10.0.150.0/24 via 0.0.0.0 in 1 hops
>
>
> *Mar 1 00:08:21.531: RIP: received v2 update from 10.0.1.2 on
> FastEthernet1/0
>
> *Mar 1 00:08:21.531: 10.0.2.0/24 via 0.0.0.0 in 1 hops
>
>
> *Mar 1 00:08:21.531: 10.0.150.0/24 via 0.0.0.0 in 2 hops
>
>
> *Mar 1 00:08:21.783: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet1/0 (10.0.1.1)
>
>
> *Mar 1 00:08:21.787: RIP: build update entries
>
>
> *Mar 1 00:08:21.787: 10.0.0.0/24 via 0.0.0.0, metric 1, tag 0
>
>
> *Mar 1 00:08:21.791: 10.0.150.0/24 via 0.0.0.0, metric 2, tag 0
>
>
> *Mar 1 00:08:24.107: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet0/0 (10.0.0.1)
>
>
> *Mar 1 00:08:24.111: RIP: build update entries
>
>
> *Mar 1 00:08:24.111: 10.0.1.0/24 via 0.0.0.0, metric 1, tag 0
>
>
> R0#
>
>
> R0#
>
>
> R0#sh ip rou
>
>
> Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
>
>
> D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
>
>
> N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
>
>
> E1 - OSPF external type 1, E2 - OSPF external type 2
>
>
> i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS
> level-2
>
> ia - IS-IS inter area, * - candidate default, U - per-user static
> route
>
> o - ODR, P - periodic downloaded static route
>
>
>
>
> Gateway of last resort is not set
>
>
>
> 10.0.0.0/24 is subnetted, 4 subnets
>
> R 10.0.2.0 [120/1] via 10.0.1.2, 00:00:18, FastEthernet1/0
>
> [120/1] via 10.0.0.2, 00:00:21, FastEthernet0/0
>
> C 10.0.0.0 is directly connected, FastEthernet0/0
>
> C 10.0.1.0 is directly connected, FastEthernet1/0
>
> R 10.0.150.0 [120/1] via 10.0.0.2, 00:00:21, FastEthernet0/0 *<<<
> notice that we do not change the route during the holddown timer*
>
> ....
>
> ....
>
> *Mar 1 00:11:29.471: RIP: build flash update entries
>
>
> *Mar 1 00:11:29.471: 10.0.150.0/24 via 0.0.0.0, metric 16, tag 0 *<<
> holddown timer ended ~180 sec*
>
> *Mar 1 00:11:33.819: RIP: received v2 update from 10.0.1.2 on
> FastEthernet1/0
>
> *Mar 1 00:11:33.823: 10.0.2.0/24 via 0.0.0.0 in 1 hops
>
>
> *Mar 1 00:11:33.827: 10.0.150.0/24 via 0.0.0.0 in 2 hops
> * << updating Table*
>
> *Mar 1 00:11:33.931: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet1/0 (10.0.1.1)
>
>
> *Mar 1 00:11:33.935: RIP: build update entries
>
>
> *Mar 1 00:11:33.935: 10.0.0.0/24 via 0.0.0.0, metric 1, tag 0
>
>
> *Mar 1 00:11:35.831: RIP: sending v2 flash update to 224.0.0.9 via
> FastEthernet0/0 (10.0.0.1)
>
>
> *Mar 1 00:11:35.835: RIP: build flash update entries
>
>
> *Mar 1 00:11:35.835: 10.0.150.0/24 via 0.0.0.0, metric 3, tag 0
>
>
> *Mar 1 00:11:35.839: RIP: sending v2 flash update to 224.0.0.9 via
> FastEthernet1/0 (10.0.1.1)
>
>
> *Mar 1 00:11:35.843: RIP: build flash update entries - suppressing null
> update
>
> *Mar 1 00:11:40.403: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet0/0 (10.0.0.1)
>
>
> *Mar 1 00:11:40.407: RIP: build update entries
>
> *Mar 1 00:11:40.407: 10.0.1.0/24 via 0.0.0.0, metric 1, tag 0
>
> *Mar 1 00:11:40.411: 10.0.2.0/24 via 0.0.0.0, metric 2, tag 0
>
> *Mar 1 00:11:40.411: 10.0.150.0/24 via 0.0.0.0, metric 3, tag 0
>
> *Mar 1 00:12:01.123: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet1/00.0.1.1)
>
> *Mar 1 00:12:01.127: RIP: build update entries
>
> *Mar 1 00:12:01.127: 10.0.0.0/24 via 0.0.0.0, metric 1, tag 0
>
> *Mar 1 00:12:02.447: RIP: received v2 update from 10.0.1.2 on
> FastEthernet1/
>
> *Mar 1 00:12:02.451: 10.0.2.0/24 via 0.0.0.0 in 1 hops
>
> *Mar 1 00:12:02.451: 10.0.150.0/24 via 0.0.0.0 in 2 hopssh ip rip
> databou
>
> Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
>
> D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
>
> N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
>
> E1 - OSPF external type 1, E2 - OSPF external type 2
>
> i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS
> level-2
>
> ia - IS-IS inter area, * - candidate default, U - per-user static
> rout
>
> o - ODR, P - periodic downloaded static route
>
>
>
> Gateway of last resort is not set
>
>
>
> 10.0.0.0/24 is subnetted, 4 subnets
>
> R 10.0.2.0 [120/1] via 10.0.1.2, 00:00:03, FastEthernet1/0
>
> C 10.0.0.0 is directly connected, FastEthernet0/0
>
> C 10.0.1.0 is directly connected, FastEthernet1/0
>
> *R 10.0.150.0 [120/2] via 10.0.1.2, 00:00:03, FastEthernet1/0*
>
> R0#
>
>
>
>
>
> On Mon, Mar 22, 2010 at 9:57 AM, shiran guez <shiranp3_at_gmail.com> wrote:
>
> Simplify, here is quate from a nice book i recommend
>
> *CCIE Professional Development Routing TCP/IP, Volume I, Second Edition
> By Jeff Doyle - CCIE No. 1919, Jennifer Carroll - CCIE No. 1402*
>
> "The third timer is the holddown timer, although RFC 1058 does not call for
> the use of holddowns. The Cisco implementation of RIP does use them. An
> update with a hop count higher than the metric recorded in the route table
> will cause the route to go into holddown for 180 seconds (again, six update
> periods)."
>
>
>
>
>
> On Mon, Mar 22, 2010 at 9:46 AM, Cristian Matei <
> cristian.matei_at_datanets.ro> wrote:
> > Hi Shiran,
> >
> > If you read my *book* you'll understand. Holddown timer NEVER
> kicks
> > in just when the metric for a prefix increases; maximum hop count of 15
> is
> > the protection for it.
> >
> > Regards,
> > Cristian.
> >
> > -----Original Message-----
> > From: shiran guez [mailto:shiranp3_at_gmail.com]
> > Sent: Monday, March 22, 2010 9:34 AM
> > To: cristian.matei_at_datanets.ro
> > Cc: Erwin van Harrewijn; kebramccie_at_gmail.com; ccielab_at_groupstudy.com;
> > tosara_at_gmail.com
> > Subject: Re: RIP Timers
> >
> > Hi Cristian
> >
> > Sorry I do not have the time to read your book bellow, but I think you
> > missed my point the basic rule is that when an update shows the metric
> > for an existing route to have increased sufficiently, there is a loop.
> > The route should be removed and put into holddown.
> >
> > Dont think there is a real need to get into the full story, and you
> > are correct as I said what is happening in Sarad scenario perfectly
> > normal.
> >
> >
> > On Sun, Mar 21, 2010 at 9:39 PM, Cristian Matei
> > <cristian.matei_at_datanets.ro> wrote:
> >> Hi Shiran,
> >>
> >> HOLDDOWN timer is NOT when you suddenly get a higher metric for
> an
> >> already installed route. See below my initial post on this thread. To
> >> quickly answer the question still, the problem you're seeing here is a
> >> normal behavior: basically RIP is NOT using holddown timer to converge
> in
> >> the case of direct "neighbor" failures. Read my post below, and if
> things
> >> are still unclear let me know where exactly.
> >>
> >> ####################################################
> >> Hi Sarad,
> >>
> >>
> >> First of all you're confusing the invalid timer with the hold down
> timer.
> >> Secondly , I believe we're speaking about RIPv1/v2 for IPv4 as RIPnG for
> >> IPv6 behaves a little bit differently. Now, each routing protocol needs
> to
> >> know how to converge in any of the 2 failure cases:
> >>
> >>
> >> 1. direct failures, meaning a prefix advertised inside the
> >> routing domain is down; here the router owning the prefix will start
> >> advertising this(depends on the routing protocol what exactly and how
> it's
> >> advertised) and all routers inside the routing domain need to converge
> > asap.
> >> 2. indirect failures, meaning a interconnect link between
> >> routers inside the routing domain is down (routing protocol runs over
> that
> >> interconnect), thus invalidating some prefixes; here each router needs a
> > way
> >> to determine that a "neighbor"/routing protocol speaker is not reachable
> > any
> >> longer, thus making some prefixes no longer reachable.
> >>
> >>
> >> RIP makes no difference and needs ways to converge in both cases.
> >>
> >> For the first case, the convergence is based on a combination of flash
> >> routing updates (known incorrectly as triggered updates) and
> > split-horizon,
> >> poison-reverse with split-horizon rules. Basically in this case the
> >> convergence is almost instant. So to detail a bit, in RIP when a prefix
> is
> >> down, the owner will advertise it as unreachable with metric 16; all the
> > RIP
> >> speakers receiving this will instantly remove the prefix from RT, send
> > flash
> >> updates on all RIP enabled interfaces for that prefix with a metric of
> 16;
> >> the prefix is no longer used for packet forwarding (as is no longer
> > present
> >> in the RT); RIP speakers (except the router that owned the prefix) will
> >> still keep the prefix in their databases and the prefix will be included
> > in
> >> the following regular updates (at each 30 second by default) for the
> >> FLUSH-INVALID amount of seconds (by default for 240-180=60 seconds which
> >> means 2 regular updates). Since the hold down timer is not used, any
> >> following update for that prefix, with any metric (lower or higher than
> > the
> >> initial one) is accepted by the RIP speakers. So here no timers are
> needed
> >> for RIP speakers to remove the unreachable prefix from RT; invalid and
> > flush
> >> timers are important for how long the prefix is kept in the RIP database
> > but
> >> NOT for RT convergence.
> >>
> >> For the second case, the convergence is based on INVALID timer, HOLD
> DOWN
> >> timer and FLUSH timer. When an update about a prefix is no longer
> received
> >> by a RIP speaker from the next-hop it has in its RT (so actually the RIP
> >> speaker that advertised the prefix) for as long as the INVALID timer
> this
> > is
> >> the point where the things start to happen; so first of all a router
> will
> >> still forward packets towards that destination, although unreachable for
> > 180
> >> seconds (the default INVALID timer); after the invalid timer reaches 0
> >> seconds, the prefix enters in the hold-down state (this means all
> updates
> >> about that prefix, regardless of having a lower or higher metric are
> >> ignored); the router will KEEP this time the prefix in the RT but in the
> >> "possibly down state" and in the RIP database as well in the same state
> >> (this means the router still uses that path for packet forwarding). Also
> > it
> >> will start advertising the prefix as unreachable on all enabled RIP
> >> interfaces by a flash update and following regular updates. The prefix
> > will
> >> remain in the hold down state for the minimum (HOLD DOWN timer, FLUSH
> > timer
> >> - INVALID timer); by default this means minimum (180,240-180)= minimum
> >> (180,60) means 60 seconds. After 60 seconds the router will remove the
> >> prefix from both RT and RIP database, stop advertising the prefix as
> >> unreachable and stop ignoring updates about that prefix (meaning at this
> >> point any updates about that prefix will be subject for the RT).
> >>
> >>
> >> Just for fun, another RIP topic which is unclear is the split-horizon.
> Lot
> >> of people "know" that if RIP receives an update about prefix
10.0.0.0/8on
> >> its Fa0/0 interface, the router will not send regular updates about
> >> 10.0.0.0/8 out that interface; this is somehow true but not entirely;
> the
> >> router will NOT send updates about 10.0.0.0/8 out on Fa0/0 ONLY and
> ONLY
> > if
> >> it prefers(puts in the RT) that route in order to reach
10.0.0.0/8prefix.
> >> For example if you have R1 that receives updates about 10.0.0.0/8 on
> Fa0/0
> >> with metric of 3 and about 10.0.0.0/8 on Fa0/1 with metric of 4, it
> will
> > put
> >> in the RT the one with metric 3. This means it will send regular RIP
> > updates
> >> about 10.0.0.0/8 out on Fa0/1 but NOT out on Fa0/0 which is its best
> path.
> >>
> >>
> >> I hope the post was not too long, but clear enough.
> >>
> >>
> >> ##################################################
> >>
> >> Regards,
> >> Cristian.
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> >> shiran guez
> >> Sent: Sunday, March 21, 2010 8:45 PM
> >> To: Erwin van Harrewijn
> >> Cc: kebramccie_at_gmail.com; ccielab_at_groupstudy.com; tosara_at_gmail.com
> >> Subject: Re: RIP Timers
> >>
> >> I think you are a little bit confused with the timers
> >>
> >> invalidate timer is when you didn't get a route update on a route that
> >> is in your table for ~180 sec (that is the status you are in)
> >> holdown timer is when suddenly you get a higher metric for an already
> >> installed route (lets say you have 1.1.1.0/24 with metric of 2 and
> >> suddenly you get that route with a metric of 3 then your router will
> >> start to count the hold down timer)
> >>
> >> between the invalidate and the flash timer if you receive an update
> >> for your route with a better metric your router immediately update the
> >> routing table and that is exactly what happened in your scenario
> >>
> >> hope that sort your mind a Little
> >>
> >>
> >> On Sun, Mar 21, 2010 at 8:30 PM, Erwin van Harrewijn <erwin_at_f1x0r.nl>
> > wrote:
> >>> Hi Shiran,
> >>>
> >>> I would have expected that the hold-down timer would have prevented
> >>> the newly learned route to the 1.1.1.0/24 network to be installed in
> >>> the routing table "already"
> >>> Since there is only 16 seconds between the moment the route was
> >>> invalidated and the newly learned route was received. The hold-down
> >>> timer could not have been expired yet.
> >>>
> >>> So why is that route installed in the routing-table?
> >>>
> >>> Thanks,
> >>> Erwin
> >>>
> >>
> >>
> >>
> >> --
> >> Shiran Guez
> >> MCSE CCNP NCE1 JNCIA-ER CCIE #20572
> >> http://cciep3.blogspot.com
> >> http://www.linkedin.com/in/cciep3
> >> http://twitter.com/cciep3
> >>
> >>
> >> Blogs and organic groups at http://www.ccie.net
> >>
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> > --
> > Shiran Guez
> > MCSE CCNP NCE1 JNCIA-ER CCIE #20572
> > http://cciep3.blogspot.com
> > http://www.linkedin.com/in/cciep3
> > http://twitter.com/cciep3
> >
> >
>
> --
>
> Shiran Guez
> MCSE CCNP NCE1 JNCIA-ER CCIE #20572
> http://cciep3.blogspot.com
> http://www.linkedin.com/in/cciep3
> http://twitter.com/cciep3
>
>
>
>
> --
> Shiran Guez
> MCSE CCNP NCE1 JNCIA-ER CCIE #20572
> http://cciep3.blogspot.com
> http://www.linkedin.com/in/cciep3
> http://twitter.com/cciep3
>
>
>
>
> --
> Shiran Guez
> MCSE CCNP NCE1 JNCIA-ER CCIE #20572
> http://cciep3.blogspot.com
> http://www.linkedin.com/in/cciep3
> http://twitter.com/cciep3
>

--
Shiran Guez
MCSE CCNP NCE1 JNCIA-ER CCIE #20572
http://cciep3.blogspot.com
http://www.linkedin.com/in/cciep3
http://twitter.com/cciep3
--
Shiran Guez
MCSE CCNP NCE1 JNCIA-ER CCIE #20572
http://cciep3.blogspot.com
http://www.linkedin.com/in/cciep3
http://twitter.com/cciep3
Blogs and organic groups at http://www.ccie.net