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 Blogs and organic groups at http://www.ccie.netReceived on Mon Mar 22 2010 - 10:28:31 ART
This archive was generated by hypermail 2.2.0 : Thu Apr 01 2010 - 07:26:35 ART