Cisconinja’s Blog

Archive for April, 2009

RIP Timers

Posted by Andy on April 27, 2009

This post will take a look at the various timers used in RIP and RIPng, and some of the differences between how they are supposed to work and how they actually do work .  RIPv2 with no auto-summary and RIPng are enabled for every interface on each router.  The topology and configurations of each router are shown below:

rip-timers3

R1:
ipv6 unicast-routing
!
interface Serial0/0
 ip address 10.0.12.1 255.255.255.0
 ipv6 address 2001:DB8:0:12::1/64
 ipv6 address FE80::1 link-local
 ipv6 rip test enable
!
router rip
 version 2
 network 10.0.0.0
 no auto-summary
!
ipv6 router rip test

R2:
ipv6 unicast-routing
!
interface Serial0/0
 ip address 10.0.12.2 255.255.255.0
 ipv6 address 2001:DB8:0:12::2/64
 ipv6 address FE80::2 link-local
 ipv6 rip test enable
!
interface Serial0/1
 ip address 10.0.23.2 255.255.255.0
 ipv6 address 2001:DB8:0:23::2/64
 ipv6 address FE80::2 link-local
 ipv6 rip test enable
!
router rip
 version 2
 network 10.0.0.0
 no auto-summary
!
ipv6 router rip test

R3:
ipv6 unicast-routing
!
interface FastEthernet0/0
 ip address 10.0.34.3 255.255.255.0
 ipv6 address 2001:DB8:0:34::3/64
 ipv6 address FE80::3 link-local
 ipv6 rip test enable
!
interface Serial0/0
 ip address 10.0.23.3 255.255.255.0
 ipv6 address 2001:DB8:0:23::3/64
 ipv6 address FE80::3 link-local
 ipv6 rip test enable
!
router rip
 version 2
 network 10.0.0.0
 no auto-summary
!
ipv6 router rip test

R4:
ipv6 unicast-routing
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.0
 ipv6 address 2001:DB8:0:4444::4/64
 ipv6 address FE80::4 link-local
 ipv6 rip test enable
!
interface FastEthernet0/0
 ip address 10.0.34.4 255.255.255.0
 ipv6 address 2001:DB8:0:34::4/64
 ipv6 address FE80::4 link-local
 ipv6 rip test enable
!
router rip
 version 2
 passive-interface Loopback0
 network 4.0.0.0
 network 10.0.0.0
 no auto-summary
!
ipv6 router rip test

The update interval configured under the routing process controls when RIP updates are sent.  Updates are sent at the configured interval minus a random amount of time up to 15% of the update interval.  For RIPv1/RIPv2, the update period can also be controlled per interface using ip rip advertise.  This command is nowhere to be found in Cisco’s documentation, but it does just what it sounds like it should.  Here R2 is configured to send updates out S0/1 every 10 seconds (minus the random jitter time), while S0/0 continues to use the default of 30 seconds:

R2:
interface Serial0/1
 ip rip advertise 10

R2#debug ip rip
Mar 1 00:10:55.471: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.0.12.2)
Mar 1 00:10:55.471: RIP: build update entries
Mar 1 00:10:55.471: 4.4.4.0/24 via 0.0.0.0, metric 3, tag 0
Mar 1 00:10:55.471: 10.0.23.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 00:10:55.471: 10.0.34.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 00:11:00.967: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 00:11:00.967: RIP: build update entries
Mar 1 00:11:00.967: 10.0.12.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 00:11:09.515: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 00:11:09.515: RIP: build update entries
Mar 1 00:11:09.515: 10.0.12.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 00:11:19.343: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 00:11:19.343: RIP: build update entries
Mar 1 00:11:19.343: 10.0.12.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 00:11:23.023: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.0.12.2)
Mar 1 00:11:23.023: RIP: build update entries
Mar 1 00:11:23.023: 4.4.4.0/24 via 0.0.0.0, metric 3, tag 0
Mar 1 00:11:23.027: 10.0.23.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 00:11:23.027: 10.0.34.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 00:11:29.131: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 00:11:29.131: RIP: build update entries
Mar 1 00:11:29.131: 10.0.12.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 00:11:38.599: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 00:11:38.599: RIP: build update entries
Mar 1 00:11:38.599: 10.0.12.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 00:11:47.939: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 00:11:47.939: RIP: build update entries
Mar 1 00:11:47.939: 10.0.12.0/24 via 0.0.0.0, metric 1, tag 0

RIPng does not have a way of controlling the update period per interface.  RIPv1/RIPv2 also support the configuration of a flash update threshold, designed to suppress flash updates from being sent if the next periodic update is due to be sent in less than the configured interval.  We will configure R4 with a flash update threshold of 30 seconds and shutdown it’s loopback interface:

R4:
router rip
 flash-update-threshold 30

1-rip-flash-interval1

R4:
interface Loopback0
 shutdown

R4#debug ip rip
Mar 1 00:31:23.931: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.4)
Mar 1 00:31:23.931: RIP: build flash update entries
Mar 1 00:31:23.931: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 00:31:32.103: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.0.34.4)
Mar 1 00:31:32.103: RIP: build update entries
Mar 1 00:31:32.103: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0

Unfortunately the command does not seem to work.  With an update period of 30 seconds and flash update threshold of 30 seconds, all flash updates should be suppressed.  R4 sends a flash update about the unreachable network out F0/0, even though the periodic update is due about 9 seconds later.  A search showed that some other people have run into this problem as well:

flash-update-threshold??

Flash-update-threshold, has anyone seen this work in a lab?

 

The invalid/timeout timer is 180 seconds by default in RIPv2:

2-r3-show-ip-protocols1

The invalid timer is reset for a route each time an update is received for it from the best route source.  The current routing table on R3 looks like this:

2-r3-show-ip-route1

R3 has learned 2 routes from RIP.  4.4.4.0/24 was learned on F0/0 from R4 and 10.0.12.0/24 was learned on S0/0 from R2.  As expected, both routes were last heard from less than 30 seconds ago since no updates were missed.  Now we will shut down R4 F0/0 so that R3 stops receiving RIP updates from it:

R4:
interface FastEthernet0/0
 shutdown

R3 receives the last update from R4 at 00:52:06.079, just prior to shutting down the interface:

R3#debug ip rip
Mar 1 00:52:06.079: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 00:52:06.079: 4.4.4.0/24 via 0.0.0.0 in 1 hops

Since no updates about 4.4.4.0/24 are received from R4, the timer for the route continues incrementing:

3-r3-show-ip-route1

Just over 180 seconds after the last update was received, log messages show that the route has been deleted and entered holddown.  We can also see that a flash update is sent for the route a couple seconds later, using poison-reverse rules to advertise it as unreachable out both S0/0 and F0/0.  The route continues to be included in periodic updates out each interface as well:

R3#debug ip rip
R3#debug ip routing
Mar 1 00:55:09.315: RT: delete route to 4.4.4.0 via 10.0.34.4, rip metric [120/1]
Mar 1 00:55:09.315: RT: SET_LAST_RDB for 4.4.4.0/24
OLD rdb: via 11.13.11.13
Mar 1 00:55:09.319: RT: no routes to 4.4.4.0, entering holddown
Mar 1 00:55:09.319: RT: NET-RED 4.4.4.0/24
Mar 1 00:55:11.323: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 00:55:11.323: RIP: build flash update entries
Mar 1 00:55:11.323: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 00:55:11.327: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 00:55:11.327: RIP: build flash update entries
Mar 1 00:55:11.327: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 00:55:27.775: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 00:55:27.775: RIP: build update entries
Mar 1 00:55:27.775: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 00:55:27.779: 10.0.12.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 00:55:27.779: 10.0.23.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 00:55:30.955: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 00:55:30.955: RIP: build update entries
Mar 1 00:55:30.955: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 00:55:30.955: 10.0.34.0/24 via 0.0.0.0, metric 1, tag 0

There are a couple confusing things about the debug outputs shown above.  First, although it says the route has been deleted from the routing table, it actually is still in both the routing table and RIP database at this point.  The route is listed as “possibly down”, but continues to be used for forwarding packets:

4-r3-show-ip-route1

4-r3-rip-database1

R3#debug ip packet
R3#ping 4.4.4.4 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:

Mar 1 00:55:48.871: IP: tableid=0, s=10.0.34.3 (local), d=4.4.4.4 (FastEthernet0/0), routed via RIB
Mar 1 00:55:48.871: IP: s=10.0.34.3 (local), d=4.4.4.4 (FastEthernet0/0), len 100, sending

Another possibly confusing thing is that the output shows the route entering holddown.  We will look at what happens when a route enters holddown and the circumstances that cause the holddown timer to be used later, but for now it is important to note that the behavior we are seeing – the route showing up as possibly down in both the routing table and RIP database, and poison-reverse being used to advertise the route as unreachable immediately in flash updates and then periodically in regular updates – is caused by the invalid timer expiring, not by entering the holddown state.  To show this, we will set the holddown timer to 0.  We will also reduce the invalid timer to 120 and keep the other timers at their defaults:

R3:
router rip
 timers basic 30 120 0 240

5-r3-show-ip-protocols1

After bringing R4 F0/0 back up and allowing the network to converge, we will shut it down again:

R4:
interface FastEthernet0/0
 shutdown

R3 receives the last update from R4 at 01:12:57.635, just prior to the shutdown:

R3#debug ip rip
Mar 1 01:12:57.635: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 01:12:57.639: 4.4.4.0/24 via 0.0.0.0 in 1 hops

A little over 120 seconds later, the route again shows up as possibly down in the routing table and RIP database, and is advertised as unreachable:

R3#debug ip routing
R3#debug ip rip

Mar 1 01:14:59.551: RT: delete route to 4.4.4.0 via 10.0.34.4, rip metric [120/1]
Mar 1 01:14:59.555: RT: SET_LAST_RDB for 4.4.4.0/24
OLD rdb: via 11.13.11.13
Mar 1 01:14:59.555: RT: no routes to 4.4.4.0, entering holddown
Mar 1 01:14:59.555: RT: NET-RED 4.4.4.0/24
Mar 1 01:15:01.559: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 01:15:01.559: RIP: build flash update entries
Mar 1 01:15:01.559: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 01:15:01.563: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 01:15:01.563: RIP: build flash update entries
Mar 1 01:15:01.563: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 01:15:03.639: RT: 4.4.4.0 came out of holddown
Mar 1 01:15:15.451: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 01:15:15.451: RIP: build update entries
Mar 1 01:15:15.451: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 01:15:15.455: 10.0.12.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 01:15:15.455: 10.0.23.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 01:15:21.479: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 01:15:21.479: RIP: build update entries
Mar 1 01:15:21.479: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 01:15:21.483: 10.0.34.0/24 via 0.0.0.0, metric 1, tag 0

5-r3-show-ip-route1

5-r3-rip-database1

 

 

There are a few differences in the use of the invalid timer in RIPng, mostly related to naming and display output.  Instead of the invalid timer, RIPng (at least in IOS syntax) calls it the route timeout or expiration timer.  Instead of counting upward from the time the last route update was heard, RIPng counts downward starting at the value of the invalid timer, and the timer is only shown in the RIP database:

6-r3-ripng-database1

Like RIPv1 and RIPv2, RIPng uses a 180 second invalid timer by default:

6-r3-ripng1

We will shut down R4 F0/0 so that R3 stops receiving updates from it:

R4:
interface FastEthernet0/0
 shutdown

Note: RIPng on R4 would sometimes send a flash update advertising all known networks as unreachable as it was shutdown.  I’m not sure why it happened sometimes and not others, but it may be necessary to filter the route inbound on R3 or outbound on R4 instead of shutting down R4 F0/0 in order to see the invalid timer expire if this keeps occuring.

R3 receives the last update from R4 at 01:33:14.979, just prior to the shutdown:

R3#debug ipv6 rip
Mar 1 01:33:14.979: RIPng: response received from FE80::4 on FastEthernet0/0 for test
Mar 1 01:33:14.979: src=FE80::4 (FastEthernet0/0)
Mar 1 01:33:14.979: dst=FF02::9
Mar 1 01:33:14.979: sport=521, dport=521, length=52
Mar 1 01:33:14.983: command=2, version=1, mbz=0, #rte=2
Mar 1 01:33:14.983: tag=0, metric=1, prefix=2001:DB8:0:4444::/64
Mar 1 01:33:14.983: tag=0, metric=1, prefix=2001:DB8:0:34::/64

180 seconds later, the invalid timer expires and the route is removed from the routing table. Flash updates are sent about the unreachable route 1 second later, followed by the regular periodic updates a few seconds after that:

R3#debug ipv6 routing
R3#debug ipv6 rip

Mar 1 01:36:14.983: IPv6RT0: rip test, Delete backup for 2001:DB8:0:34::/64
Mar 1 01:36:14.983: RIPng: 2001:DB8:0:34::/64, expired, ttg is 0
Mar 1 01:36:14.983: RIPng: Deleting 2001:DB8:0:34::/64
Mar 1 01:36:14.983: IPv6RT0: rip test, Delete 2001:DB8:0:4444::/64 from table
Mar 1 01:36:14.983: RIPng: 2001:DB8:0:4444::/64, expired, ttg is 120
Mar 1 01:36:14.983: RIPng: Triggered update requested
Mar 1 01:36:14.983: RIPng: Next RIB walk in 2000
Mar 1 01:36:14.983: IPv6RT0: Event: 2001:DB8:0:4444::/64, Del, owner rip, previous None
Mar 1 01:36:15.983: RIPng: generating triggered update for test
Mar 1 01:36:15.983: RIPng: Sending multicast update on Serial0/0 for test
Mar 1 01:36:15.983: src=FE80::3
Mar 1 01:36:15.983: dst=FF02::9 (Serial0/0)
Mar 1 01:36:15.987: sport=521, dport=521, length=32
Mar 1 01:36:15.987: command=2, version=1, mbz=0, #rte=1
Mar 1 01:36:15.987: tag=0, metric=16, prefix=2001:DB8:0:4444::/64
Mar 1 01:36:15.991: RIPng: Suppressed null multicast update on FastEthernet0/0 for test
Mar 1 01:36:16.983: RIPng: Next RIB walk in 118000
Mar 1 01:36:29.099: RIPng: Sending multicast update on Serial0/0 for test
Mar 1 01:36:29.099: src=FE80::3
Mar 1 01:36:29.099: dst=FF02::9 (Serial0/0)
Mar 1 01:36:29.103: sport=521, dport=521, length=72
Mar 1 01:36:29.103: command=2, version=1, mbz=0, #rte=3
Mar 1 01:36:29.103: tag=0, metric=1, prefix=2001:DB8:0:23::/64
Mar 1 01:36:29.103: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 01:36:29.103: tag=0, metric=16, prefix=2001:DB8:0:4444::/64
Mar 1 01:36:29.107: RIPng: Sending multicast update on FastEthernet0/0 for test
Mar 1 01:36:29.107: src=FE80::3
Mar 1 01:36:29.107: dst=FF02::9 (FastEthernet0/0)
Mar 1 01:36:29.111: sport=521, dport=521, length=72
Mar 1 01:36:29.111: command=2, version=1, mbz=0, #rte=3
Mar 1 01:36:29.111: tag=0, metric=1, prefix=2001:DB8:0:23::/64
Mar 1 01:36:29.111: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 01:36:29.111: tag=0, metric=2, prefix=2001:DB8:0:12::/64

7-r3-show-ipv6-route1 

7-r3-ripng-database1

As shown in the routing table above, when the invalid timer expires the route is immediately removed from the routing table, unlike RIPv1 and RIPv2.  In the RIPng database, it is listed as expired, and 2 additional timers that we will look at shortly are now listed as well for the failed route.  One other difference compared to RIPv1/RIPv2 is that by default RIPng does not use poison-reverse.  When R3 sent flash updates about the unreachable route, the update on F0/0 was suppressed (the message at 01:36:15.991) because the only route to be advertised in the flash update was known on that interface.  The periodic update on F0/0 (at 01:36:29.111) also does not include a route entry for 2001:db8:0:4444::/64.  Poison-reverse can be enabled at the routing process in RIPng as shown below:

R3:
ipv6 router rip test
 poison-reverse

However, this is not the same as RIPv1/2 behavior.  RIPv1/2 use poison-reverse only for unreachable routes, with all other routes using simple split-horizon rules (if split-horizon is enabled).  RIPng uses split-horizon with poison-reverse for all non-directly-connected routes regardless of their metric if it is enabled.  With all interfaces once again enabled and the network converged, R3’s routing table and RIPng updates look like this:

8-r3-show-ipv6-route1

R3#debug ipv6 rip
Mar 1 01:42:38.311: RIPng: Sending multicast update on Serial0/0 for test
Mar 1 01:42:38.311: src=FE80::3
Mar 1 01:42:38.311: dst=FF02::9 (Serial0/0)
Mar 1 01:42:38.315: sport=521, dport=521, length=92
Mar 1 01:42:38.315: command=2, version=1, mbz=0, #rte=4
Mar 1 01:42:38.315: tag=0, metric=1, prefix=2001:DB8:0:23::/64
Mar 1 01:42:38.315: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 01:42:38.315: tag=0, metric=16, prefix=2001:DB8:0:12::/64
Mar 1 01:42:38.319: tag=0, metric=2, prefix=2001:DB8:0:4444::/64
Mar 1 01:42:38.319: RIPng: Sending multicast update on FastEthernet0/0 for test
Mar 1 01:42:38.319: src=FE80::3
Mar 1 01:42:38.323: dst=FF02::9 (FastEthernet0/0)
Mar 1 01:42:38.323: sport=521, dport=521, length=92
Mar 1 01:42:38.323: command=2, version=1, mbz=0, #rte=4
Mar 1 01:42:38.323: tag=0, metric=1, prefix=2001:DB8:0:23::/64
Mar 1 01:42:38.323: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 01:42:38.327: tag=0, metric=2, prefix=2001:DB8:0:12::/64
Mar 1 01:42:38.327: tag=0, metric=16, prefix=2001:DB8:0:4444::/64

2001:db8:0:12::/64, known on S0/0, is advertised back out S0/0 as unreachable.  2001:db8:0:4444::/64, known on F0/0, is advertised back out F0/0 as unreachable.

 

Next we will look at the flush timer, first in RIPv1/2.  The flush timer controls when a route that has not been updated is removed entirely from the routing table and RIP database.  We will be using the same scenario again, where R4 F0/0 fails.  First we will set the timers back to their defaults:

R3:
router rip
 default timers basic

The default flush timer is 240 seconds in RIPv1/2:

9-r3-show-ip-protocols

Now we will shut down R4 F0/0 again:

R4:
interface FastEthernet0/0
 shutdown

R3 receives the last update from R4 at 00:25:11.695, just prior to the shutdown:

R3#debug ip rip
Mar 1 00:25:11.695: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 00:25:11.695: 4.4.4.0/24 via 0.0.0.0 in 1 hops

A little over 180 seconds later, the invalid timer expires.  Like we saw earlier, the route is listed as possibly down in the routing table and RIP database, and is advertised as unreachable using poison-reverse.  The route continues to be advertised in periodic updates until the flush timer expires, after approximately 240 seconds:

R3#debug ip routing
R3#debug ip rip
Mar 1 00:28:14.927: RT: delete route to 4.4.4.0 via 10.0.34.4, rip metric [120/1]
Mar 1 00:28:14.927: RT: SET_LAST_RDB for 4.4.4.0/24
OLD rdb: via 11.13.11.13
Mar 1 00:28:14.931: RT: no routes to 4.4.4.0, entering holddown
Mar 1 00:28:14.931: RT: NET-RED 4.4.4.0/24
Mar 1 00:28:16.931: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 00:28:16.931: RIP: build flash update entries
Mar 1 00:28:16.931: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 00:28:16.931: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 00:28:16.931: RIP: build flash update entries
Mar 1 00:28:16.931: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 00:28:38.879: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 00:28:38.879: RIP: build update entries
Mar 1 00:28:38.879: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 00:28:38.883: 10.0.34.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 00:28:40.039: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 00:28:40.039: RIP: build update entries
Mar 1 00:28:40.039: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 00:28:40.039: 10.0.12.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 00:28:40.039: 10.0.23.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 00:29:08.763: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 00:29:08.763: RIP: build update entries
Mar 1 00:29:08.763: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 00:29:08.767: 10.0.34.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 00:29:09.463: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 00:29:09.463: RIP: build update entries
Mar 1 00:29:09.463: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 00:29:09.463: 10.0.12.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 00:29:09.467: 10.0.23.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 00:29:14.931: RT: delete subnet route to 4.4.4.0/24
Mar 1 00:29:14.931: RT: NET-RED 4.4.4.0/24
Mar 1 00:29:14.935: RT: delete network route to 4.0.0.0
Mar 1 00:29:14.935: RT: NET-RED 4.0.0.0/8

Using default timers, this means the route is advertised as unreachable for 60 seconds.  Once the flush timer expires and the 2nd delete message appears in the logs, the route is removed and no longer included in updates or used for forwarding.

 

In RIPng, the flush timer is called the garbage collection timer.  The garbage collect timer is 120 seconds by default and does not start until the invalid timer expires, unlike RIPv1/2 where the flush timer begins at the time the last update was received:

10-r3-ripng

Now we will shut down R4 F0/0 again:

R4:
interface FastEthernet0/0
 shutdown

R3 receives the last update from R4 at 00:31:20.699, just prior to the shutdown:

R3#debug ipv6 rip
Mar 1 00:31:20.699: RIPng: response received from FE80::4 on FastEthernet0/0 for test
Mar 1 00:31:20.699: src=FE80::4 (FastEthernet0/0)
Mar 1 00:31:20.703: dst=FF02::9
Mar 1 00:31:20.703: sport=521, dport=521, length=52
Mar 1 00:31:20.703: command=2, version=1, mbz=0, #rte=2
Mar 1 00:31:20.703: tag=0, metric=1, prefix=2001:DB8:0:4444::/64
Mar 1 00:31:20.703: tag=0, metric=1, prefix=2001:DB8:0:34::/64

180 seconds later, the invalid timer expires, and the behavior that we saw earlier when the RIPng invalid timer expires begins.  The RIP database shows how long the route will continue to be advertised (the garbage collect timer).  The route continues to be advertised in periodic updates using simple split-horizon rules until the garbage collect timer expires, after approximately 300 total seconds:

R3#debug ipv6 routing
R3#debug ipv6 rip

Mar 1 00:34:20.703: IPv6RT0: rip test, Delete backup for 2001:DB8:0:34::/64
Mar 1 00:34:20.703: RIPng: 2001:DB8:0:34::/64, expired, ttg is 0
Mar 1 00:34:20.703: RIPng: Deleting 2001:DB8:0:34::/64
Mar 1 00:34:20.707: IPv6RT0: rip test, Delete 2001:DB8:0:4444::/64 from table
Mar 1 00:34:20.707: RIPng: 2001:DB8:0:4444::/64, expired, ttg is 120
Mar 1 00:34:20.707: RIPng: Triggered update requested
Mar 1 00:34:20.707: RIPng: Next RIB walk in 2000
Mar 1 00:34:20.711: IPv6RT0: Event: 2001:DB8:0:4444::/64, Del, owner rip, previous None
Mar 1 00:34:21.707: RIPng: generating triggered update for test
Mar 1 00:34:21.707: RIPng: Sending multicast update on Serial0/0 for test
Mar 1 00:34:21.707: src=FE80::3
Mar 1 00:34:21.707: dst=FF02::9 (Serial0/0)
Mar 1 00:34:21.711: sport=521, dport=521, length=32
Mar 1 00:34:21.711: command=2, version=1, mbz=0, #rte=1
Mar 1 00:34:21.711: tag=0, metric=16, prefix=2001:DB8:0:4444::/64
Mar 1 00:34:21.715: RIPng: Suppressed null multicast update on FastEthernet0/0 for test

10-r3-ripng-database

R3#debug ipv6 routing
R3#debug ipv6 rip

Mar 1 00:34:26.715: RIPng: Sending multicast update on Serial0/0 for test
Mar 1 00:34:26.715: src=FE80::3
Mar 1 00:34:26.715: dst=FF02::9 (Serial0/0)
Mar 1 00:34:26.719: sport=521, dport=521, length=72
Mar 1 00:34:26.719: command=2, version=1, mbz=0, #rte=3
Mar 1 00:34:26.719: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 00:34:26.719: tag=0, metric=1, prefix=2001:DB8:0:23::/64
Mar 1 00:34:26.719: tag=0, metric=16, prefix=2001:DB8:0:4444::/64
Mar 1 00:34:26.723: RIPng: Sending multicast update on FastEthernet0/0 for test
Mar 1 00:34:26.723: src=FE80::3
Mar 1 00:34:26.723: dst=FF02::9 (FastEthernet0/0)
Mar 1 00:34:26.727: sport=521, dport=521, length=72
Mar 1 00:34:26.727: command=2, version=1, mbz=0, #rte=3
Mar 1 00:34:26.727: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 00:34:26.727: tag=0, metric=1, prefix=2001:DB8:0:23::/64
Mar 1 00:34:26.727: tag=0, metric=2, prefix=2001:DB8:0:12::/64
Mar 1 00:34:56.207: RIPng: Sending multicast update on Serial0/0 for test
Mar 1 00:34:56.207: src=FE80::3
Mar 1 00:34:56.207: dst=FF02::9 (Serial0/0)
Mar 1 00:34:56.211: sport=521, dport=521, length=72
Mar 1 00:34:56.211: command=2, version=1, mbz=0, #rte=3
Mar 1 00:34:56.211: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 00:34:56.211: tag=0, metric=1, prefix=2001:DB8:0:23::/64
Mar 1 00:34:56.211: tag=0, metric=16, prefix=2001:DB8:0:4444::/64
Mar 1 00:34:56.215: RIPng: Sending multicast update on FastEthernet0/0 for test
Mar 1 00:34:56.215: src=FE80::3
Mar 1 00:34:56.215: dst=FF02::9 (FastEthernet0/0)
Mar 1 00:34:56.219: sport=521, dport=521, length=72
Mar 1 00:34:56.219: command=2, version=1, mbz=0, #rte=3
Mar 1 00:34:56.219: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 00:34:56.219: tag=0, metric=1, prefix=2001:DB8:0:23::/64
Mar 1 00:34:56.219: tag=0, metric=2, prefix=2001:DB8:0:12::/64
Mar 1 00:35:23.631: RIPng: Sending multicast update on Serial0/0 for test
Mar 1 00:35:23.631: src=FE80::3
Mar 1 00:35:23.631: dst=FF02::9 (Serial0/0)
Mar 1 00:35:23.635: sport=521, dport=521, length=72
Mar 1 00:35:23.635: command=2, version=1, mbz=0, #rte=3
Mar 1 00:35:23.635: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 00:35:23.635: tag=0, metric=1, prefix=2001:DB8:0:23::/64
Mar 1 00:35:23.635: tag=0, metric=16, prefix=2001:DB8:0:4444::/64
Mar 1 00:35:23.639: RIPng: Sending multicast update on FastEthernet0/0 for test
Mar 1 00:35:23.639: src=FE80::3
Mar 1 00:35:23.639: dst=FF02::9 (FastEthernet0/0)
Mar 1 00:35:23.643: sport=521, dport=521, length=72
Mar 1 00:35:23.643: command=2, version=1, mbz=0, #rte=3
Mar 1 00:35:23.643: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 00:35:23.643: tag=0, metric=1, prefix=2001:DB8:0:23::/64
Mar 1 00:35:23.643: tag=0, metric=2, prefix=2001:DB8:0:12::/64
Mar 1 00:35:53.387: RIPng: Sending multicast update on Serial0/0 for test
Mar 1 00:35:53.387: src=FE80::3
Mar 1 00:35:53.387: dst=FF02::9 (Serial0/0)
Mar 1 00:35:53.391: sport=521, dport=521, length=72
Mar 1 00:35:53.391: command=2, version=1, mbz=0, #rte=3
Mar 1 00:35:53.391: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 00:35:53.391: tag=0, metric=1, prefix=2001:DB8:0:23::/64
Mar 1 00:35:53.391: tag=0, metric=16, prefix=2001:DB8:0:4444::/64
Mar 1 00:35:53.395: RIPng: Sending multicast update on FastEthernet0/0 for test
Mar 1 00:35:53.395: src=FE80::3
Mar 1 00:35:53.395: dst=FF02::9 (FastEthernet0/0)
Mar 1 00:35:53.399: sport=521, dport=521, length=72
Mar 1 00:35:53.399: command=2, version=1, mbz=0, #rte=3
Mar 1 00:35:53.399: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 00:35:53.399: tag=0, metric=1, prefix=2001:DB8:0:23::/64
Mar 1 00:35:53.399: tag=0, metric=2, prefix=2001:DB8:0:12::/64
Mar 1 00:36:19.371: RIPng: Sending multicast update on Serial0/0 for test
Mar 1 00:36:19.371: src=FE80::3
Mar 1 00:36:19.371: dst=FF02::9 (Serial0/0)
Mar 1 00:36:19.375: sport=521, dport=521, length=72
Mar 1 00:36:19.375: command=2, version=1, mbz=0, #rte=3
Mar 1 00:36:19.375: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 00:36:19.375: tag=0, metric=1, prefix=2001:DB8:0:23::/64
Mar 1 00:36:19.375: tag=0, metric=16, prefix=2001:DB8:0:4444::/64
Mar 1 00:36:19.379: RIPng: Sending multicast update on FastEthernet0/0 for test
Mar 1 00:36:19.379: src=FE80::3
Mar 1 00:36:19.379: dst=FF02::9 (FastEthernet0/0)
Mar 1 00:36:19.383: sport=521, dport=521, length=72
Mar 1 00:36:19.383: command=2, version=1, mbz=0, #rte=3
Mar 1 00:36:19.383: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 00:36:19.383: tag=0, metric=1, prefix=2001:DB8:0:23::/64
Mar 1 00:36:19.383: tag=0, metric=2, prefix=2001:DB8:0:12::/64
Mar 1 00:36:20.703: RIPng: Deleting 2001:DB8:0:4444::/64
Mar 1 00:36:20.703: RIPng: Next RIB walk in 159284

11-r3-ripng-database

 

 

Next we will look at the holddown timer, first in RIPv1/2.  The holddown timer prevents updates for a route from being accepted until it expires under certain conditions.  By default, the holddown timer is 180 seconds:

12-r3-show-ip-protocols

For testing out the holddown timer, we will add an additional link between R1 and R4:

rip-timers22

R1:
interface Serial0/1
 ip address 10.0.14.1 255.255.255.0
 ipv6 address 2001:DB8:0:14::1/64
 ipv6 address FE80::1 link-local
 ipv6 rip test enable
 

R4:
interface Serial0/0
 ip address 10.0.14.4 255.255.255.0
 ipv6 address 2001:DB8:0:14::4/64
 ipv6 address FE80::4 link-local
 ipv6 rip test enable

The holddown timer is perhaps the most confusing and poorly explained of the RIP timers.  The sources I’ve looked at each say slightly different things about what it does, none of which is completely correct.  We will first look at what the holddown timer doesn’t do by testing out what various sources say about it.  From Routing TCP/IP Volume 1:

If the distance to a destination increases (for example, the hop count increases from two to four), the router sets a holddown timer for that route. Until the timer expires, the router will not accept any new updates for the route.

and also:

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).

This says if the metric from the current best source increases, the route is placed in holddown.  R3 currently has a 1 hop route to 4.4.4.0/24 through R4.  We will offset the metric for the route by 1 outbound on R4 and see if the route gets placed in holddown:

R4:
access-list 1 permit 4.4.4.0

!
router rip
 offset-list 1 out 1 FastEthernet0/0

R3#debug ip routing
R3#debug ip rip

Mar 1 02:38:09.167: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 02:38:09.171: 4.4.4.0/24 via 0.0.0.0 in 2 hops
Mar 1 02:38:09.171: RT: rip's 4.4.4.0/24 (via 10.0.34.4) metric changed from distance/metric [120/1] to [120/2]
Mar 1 02:38:09.171: RT: NET-RED 4.4.4.0/24
Mar 1 02:38:09.175: 10.0.12.0/24 via 0.0.0.0 in 2 hops
Mar 1 02:38:09.175: 10.0.14.0/24 via 0.0.0.0 in 1 hops
Mar 1 02:38:11.175: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 02:38:11.175: RIP: build flash update entries - suppressing null update
Mar 1 02:38:11.175: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 02:38:11.179: RIP: build flash update entries
Mar 1 02:38:11.179: 4.4.4.0/24 via 0.0.0.0, metric 3, tag 0

12-r3-show-ip-route

Instead of placing the route in holddown, R3 accepts the increased metric immediately, records it in the RIP database and routing table, and sends a flash update on S0/0 2 seconds later about the increased metric.

 

 

From the 12.4 Command Reference:

A route enters into a holddown state when an update packet is received that indicates the route is unreachable. The route is marked inaccessible and advertised as unreachable. However, the route is still used for forwarding packets. When holddown expires, routes advertised by other sources are accepted and the route is no longer inaccessible.

Based on this description, if we shut down R4’s loopback so that it is advertised as unreachable, R3 should place the route into holddown.  If we bring it back up a few seconds later, the update should be ignored by R3.  Let’s test this out:

R4:
interface Loopback0
 shutdown

R3#debug ip routing
R3#debug ip rip

Mar 1 02:56:04.723: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 02:56:04.723: 4.4.4.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Mar 1 02:56:04.727: RT: del 4.4.4.0/24 via 10.0.34.4, rip metric [120/2]
Mar 1 02:56:04.727: RT: delete subnet route to 4.4.4.0/24
Mar 1 02:56:04.727: RT: NET-RED 4.4.4.0/24
Mar 1 02:56:04.731: RT: delete network route to 4.0.0.0
Mar 1 02:56:04.731: RT: NET-RED 4.0.0.0/8
Mar 1 02:56:06.731: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 02:56:06.731: RIP: build flash update entries
Mar 1 02:56:06.731: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 02:56:06.735: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 02:56:06.735: RIP: build flash update entries
Mar 1 02:56:06.735: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0

R4:
interface Loopback0
 no shutdown

R3#debug ip routing
R3#debug ip rip

Mar 1 02:56:19.587: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 02:56:19.587: 4.4.4.0/24 via 0.0.0.0 in 2 hops
Mar 1 02:56:19.591: RT: SET_LAST_RDB for 4.4.4.0/24
NEW rdb: via 10.0.34.4
Mar 1 02:56:19.591: RT: add 4.4.4.0/24 via 10.0.34.4, rip metric [120/2]
Mar 1 02:56:19.591: RT: NET-RED 4.4.4.0/24
Mar 1 02:56:21.595: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 02:56:21.595: RIP: build flash update entries - suppressing null update
Mar 1 02:56:21.595: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 02:56:21.599: RIP: build flash update entries
Mar 1 02:56:21.599: 4.4.4.0/24 via 0.0.0.0, metric 3, tag 0

R3 receives the flash update from R4 advertising 4.4.4.0/24 as unreachable, removes it from the routing table, and sends a flash update on S0/0 advertising it as unreachable.  When R4’s loopback comes back up and R3 receives a flash update advertising it as reachable 15 seconds later, R3 accepts the update immediately – so the route is clearly not in holddown.  The count-to-infinity problem – which the holddown timer is supposed to prevent – can even occur in this scenario with some unlucky timing of updates.  With all interfaces back up and the network converged, we will shutdown the R4 loopback again:

R4:
interface Loopback0
 shutdown

R3 receives the flash update from R4 at 03:11:03.063 and immediately deletes the route:

R3#debug ip routing
R3#debug ip rip

Mar 1 03:11:03.063: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 03:11:03.063: 4.4.4.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Mar 1 03:11:03.063: RT: del 4.4.4.0/24 via 10.0.34.4, rip metric [120/2]
Mar 1 03:11:03.063: RT: delete subnet route to 4.4.4.0/24
Mar 1 03:11:03.063: RT: NET-RED 4.4.4.0/24
Mar 1 03:11:03.063: RT: delete network route to 4.0.0.0
Mar 1 03:11:03.063: RT: NET-RED 4.0.0.0/8
Mar 1 03:11:03.067: 10.0.12.0/24 via 0.0.0.0 in 2 hops
Mar 1 03:11:03.067: 10.0.14.0/24 via 0.0.0.0 in 1 hops

R2’s periodic update timer for the R2-R3 link happens to expire right after this.  R2 has not gotten the flash update yet that 4.4.4.0/24 is unreachable, so R2’s update includes 4.4.4.0/24 with a metric of 3.  R3 receives the periodic update from R2 at 03:11:04.987, approximately 1.9 seconds after the flash update was received from R4:

R3#debug ip routing
R3#debug ip rip

Mar 1 03:11:04.987: RIP: received v2 update from 10.0.23.2 on Serial0/0
Mar 1 03:11:04.987: 4.4.4.0/24 via 0.0.0.0 in 3 hops
Mar 1 03:11:04.991: RT: SET_LAST_RDB for 4.4.4.0/24
NEW rdb: via 10.0.23.2
Mar 1 03:11:04.991: RT: add 4.4.4.0/24 via 10.0.23.2, rip metric [120/3]
Mar 1 03:11:04.995: RT: NET-RED 4.4.4.0/24
Mar 1 03:11:04.995: 10.0.12.0/24 via 0.0.0.0 in 1 hops
Mar 1 03:11:04.995: 10.0.14.0/24 via 0.0.0.0 in 2 hops

At 03:11:05.063, exactly 2 seconds after the flash update from R4 was received, R3 sends a flash update for 4.4.4.0/24 – however the flash update does not list the route as unreachable, which caused the flash update to occur in the first place, but rather in it’s current state.  This is key to what allows the problem to occur.  Flash updates are delayed for 2 seconds and once the delay period expires, updates are sent for the route in whatever current state it is in.  R3 increments the metric and sends a flash update for the route back to R4.  R3 does not send a flash update for the route to R2 due to split-horizon rules:

R3#debug ip rip
Mar 1 03:11:05.063: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 03:11:05.063: RIP: build flash update entries
Mar 1 03:11:05.063: 4.4.4.0/24 via 0.0.0.0, metric 4, tag 0
Mar 1 03:11:05.067: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 03:11:05.067: RIP: build flash update entries - suppressing null update

R4 receives the update from R3, adds the route to the RIP database and routing table, and starts the 2 second delay for it’s flash update about the route:

R4#debug ip routing
R4#debug ip rip

Mar 1 03:11:05.203: RIP: received v2 update from 10.0.34.3 on FastEthernet0/0
Mar 1 03:11:05.203: 4.4.4.0/24 via 0.0.0.0 in 4 hops
Mar 1 03:11:05.207: RT: SET_LAST_RDB for 4.4.4.0/24
NEW rdb: via 10.0.34.3
Mar 1 03:11:05.207: RT: add 4.4.4.0/24 via 10.0.34.3, rip metric [120/4]
Mar 1 03:11:05.207: RT: NET-RED 4.4.4.0/24
 

R2 receives a flash update from R1 at about the same time advertising the route as unreachable. R2 removes the route from the routing table and also starts it’s 2 second flash update delay for the route:

R2#debug ip routing
R2#debug ip rip

Mar 1 03:11:05.739: RIP: received v2 update from 10.0.12.1 on Serial0/0
Mar 1 03:11:05.739: 4.4.4.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Mar 1 03:11:05.743: RT: del 4.4.4.0/24 via 10.0.12.1, rip metric [120/2]
Mar 1 03:11:05.743: RT: delete subnet route to 4.4.4.0/24
Mar 1 03:11:05.743: RT: NET-RED 4.4.4.0/24
Mar 1 03:11:05.747: RT: delete network route to 4.0.0.0
Mar 1 03:11:05.747: RT: NET-RED 4.0.0.0/8

On R4, the 2 second delay for the flash update expires from the time it was received with a hop-count of 4 from R3.  No further updates about the route have been received during the delay period, so the hop-count is incremented and the route is advertised to R1:

R4#debug ip rip
Mar 1 03:11:07.211: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.4)
Mar 1 03:11:07.211: RIP: build flash update entries - suppressing null update
Mar 1 03:11:07.211: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.14.4)
Mar 1 03:11:07.215: RIP: build flash update entries
Mar 1 03:11:07.215: 4.4.4.0/24 via 0.0.0.0, metric 5, tag 0

On R2, the 2 second delay expires as well from the time it was received with an unreachable metric from R1.  No further changes have occurred so the route is advertised as unreachable out all interfaces:

R2#debug ip rip
Mar 1 03:11:07.747: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.12.2)
Mar 1 03:11:07.747: RIP: build flash update entries
Mar 1 03:11:07.747: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 03:11:07.751: RIP: sending v2 flash update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 03:11:07.751: RIP: build flash update entries
Mar 1 03:11:07.751: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
 

R3 receives the flash update from R2, deletes the route, and starts the 2 second flash update delay.  However, the update arrives too late, as R3 already incorrectly advertised the route to R4 approximately 3 seconds earlier.  This results in 2 circles of updates, 1 advertising the route as unreachable and 1 with an incrementing hop-count.  The 2 updates will circulate approximately every 8 seconds (4x the flash update delay) and the route will be continually added and removed until eventually the incrementing hop-count reaches 16:

R3#debug ip routing
R3#debug ip rip
Mar 1 03:11:08.143: RIP: received v2 update from 10.0.23.2 on Serial0/0
Mar 1 03:11:08.143: 4.4.4.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Mar 1 03:11:08.147: RT: del 4.4.4.0/24 via 10.0.23.2, rip metric [120/3]
Mar 1 03:11:08.147: RT: delete subnet route to 4.4.4.0/24
Mar 1 03:11:08.147: RT: NET-RED 4.4.4.0/24
Mar 1 03:11:08.151: RT: delete network route to 4.0.0.0
Mar 1 03:11:08.151: RT: NET-RED 4.0.0.0/8
Mar 1 03:11:10.151: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 03:11:10.151: RIP: build flash update entries
Mar 1 03:11:10.151: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 03:11:10.155: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 03:11:10.155: RIP: build flash update entries
Mar 1 03:11:10.155: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 03:11:11.235: RIP: received v2 update from 10.0.23.2 on Serial0/0
Mar 1 03:11:11.235: 4.4.4.0/24 via 0.0.0.0 in 7 hops
Mar 1 03:11:11.239: RT: SET_LAST_RDB for 4.4.4.0/24
NEW rdb: via 10.0.23.2
Mar 1 03:11:11.239: RT: add 4.4.4.0/24 via 10.0.23.2, rip metric [120/7]
Mar 1 03:11:11.239: RT: NET-RED 4.4.4.0/24
Mar 1 03:11:13.243: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 03:11:13.243: RIP: build flash update entries
Mar 1 03:11:13.243: 4.4.4.0/24 via 0.0.0.0, metric 8, tag 0
Mar 1 03:11:13.247: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 03:11:13.247: RIP: build flash update entries - suppressing null update
Mar 1 03:11:14.483: RIP: received v2 update from 10.0.23.2 on Serial0/0
Mar 1 03:11:14.483: 4.4.4.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Mar 1 03:11:14.483: RT: del 4.4.4.0/24 via 10.0.23.2, rip metric [120/7]
Mar 1 03:11:14.487: RT: delete subnet route to 4.4.4.0/24
Mar 1 03:11:14.487: RT: NET-RED 4.4.4.0/24
Mar 1 03:11:14.487: RT: delete network route to 4.0.0.0
Mar 1 03:11:14.487: RT: NET-RED 4.0.0.0/8
Mar 1 03:11:16.487: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 03:11:16.487: RIP: build flash update entries
Mar 1 03:11:16.487: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 03:11:16.491: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 03:11:16.491: RIP: build flash update entries
Mar 1 03:11:16.491: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 03:11:19.375: RIP: received v2 update from 10.0.23.2 on Serial0/0
Mar 1 03:11:19.375: 4.4.4.0/24 via 0.0.0.0 in 11 hops
Mar 1 03:11:19.375: RT: SET_LAST_RDB for 4.4.4.0/24
NEW rdb: via 10.0.23.2
Mar 1 03:11:19.379: RT: add 4.4.4.0/24 via 10.0.23.2, rip metric [120/11]
Mar 1 03:11:19.379: RT: NET-RED 4.4.4.0/24
Mar 1 03:11:21.379: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 03:11:21.379: RIP: build flash update entries
Mar 1 03:11:21.379: 4.4.4.0/24 via 0.0.0.0, metric 12, tag 0
Mar 1 03:11:21.383: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 03:11:21.383: RIP: build flash update entries - suppressing null update
Mar 1 03:11:22.587: RIP: received v2 update from 10.0.23.2 on Serial0/0
Mar 1 03:11:22.587: 4.4.4.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Mar 1 03:11:22.587: RT: del 4.4.4.0/24 via 10.0.23.2, rip metric [120/11]
Mar 1 03:11:22.591: RT: delete subnet route to 4.4.4.0/24
Mar 1 03:11:22.591: RT: NET-RED 4.4.4.0/24
Mar 1 03:11:22.591: RT: delete network route to 4.0.0.0
Mar 1 03:11:22.595: RT: NET-RED 4.0.0.0/8
Mar 1 03:11:24.595: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 03:11:24.595: RIP: build flash update entries
Mar 1 03:11:24.595: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 03:11:24.599: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 03:11:24.599: RIP: build flash update entries
Mar 1 03:11:24.599: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0 
Mar 1 03:11:27.619: RIP: received v2 update from 10.0.23.2 on Serial0/0
Mar 1 03:11:27.619: 4.4.4.0/24 via 0.0.0.0 in 15 hops
Mar 1 03:11:27.623: RT: SET_LAST_RDB for 4.4.4.0/24
NEW rdb: via 10.0.23.2
Mar 1 03:11:27.623: RT: add 4.4.4.0/24 via 10.0.23.2, rip metric [120/15]
Mar 1 03:11:27.627: RT: NET-RED 4.4.4.0/24
Mar 1 03:11:29.627: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 03:11:29.627: RIP: build flash update entries
Mar 1 03:11:29.627: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 03:11:29.631: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 03:11:29.631: RIP: build flash update entries - suppressing null update
Mar 1 03:11:30.139: RIP: received v2 update from 10.0.23.2 on Serial0/0
Mar 1 03:11:30.139: 4.4.4.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Mar 1 03:11:30.139: RT: del 4.4.4.0/24 via 10.0.23.2, rip metric [120/15]
Mar 1 03:11:30.139: RT: delete subnet route to 4.4.4.0/24
Mar 1 03:11:30.143: RT: NET-RED 4.4.4.0/24
Mar 1 03:11:30.143: RT: delete network route to 4.0.0.0
Mar 1 03:11:30.143: RT: NET-RED 4.0.0.0/8
Mar 1 03:11:32.147: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 03:11:32.147: RIP: build flash update entries
Mar 1 03:11:32.147: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 03:11:32.151: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 03:11:32.151: RIP: build flash update entries
Mar 1 03:11:32.151: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0

 

 

From Cisco Press ICND 2:

After hearing a poisoned route, start a holddown timer for that one route. Until the timer expires, do not believe any other routing information about the failed route, because believing that information may cause a routing loop. However, information learned from the neighbor that originally advertised the working route can be believed before the holddown timer expires.

This says the same thing as the command reference, with the addition of allowing information from the original route source to be believed during the holddown.  We will test this out on R2.  With all interfaces up again, R2 currently has a 2-hop route to 4.4.4.0/24 through R1:

13-r2-show-ip-route

The route through R3 is 3 hops because of the offset-list we applied on R4 F0/0 earlier, so it is not in the routing table or RIP database.  If the route is advertised as unreachable by R1, and then R2 receives an update from R3 advertising it as metric 3, it should be ignored based on the definition above.  To test this out, we will first shut down R4 F0/0 and then shut down R4’s loopback:

R4:
interface FastEthernet0/0
 shutdown
!
interface Loopback0
 shutdown

R4 sends a flash update advertising the route as unreachable, and R1 sends a flash update to R2.  R3 does not receive an update from R4 so it will continue advertising 4.4.4.0/24 to R2 as reachable until the invalid timer expires for the route:

R2#debug ip routing
R2#debug ip rip

Mar 1 04:09:43.699: RIP: received v2 update from 10.0.12.1 on Serial0/0
Mar 1 04:09:43.699: 4.4.4.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Mar 1 04:09:43.703: RT: del 4.4.4.0/24 via 10.0.12.1, rip metric [120/2]
Mar 1 04:09:43.703: RT: delete subnet route to 4.4.4.0/24
Mar 1 04:09:43.703: RT: NET-RED 4.4.4.0/24
Mar 1 04:09:43.707: RT: delete network route to 4.0.0.0
Mar 1 04:09:43.707: RT: NET-RED 4.0.0.0/8
Mar 1 04:09:43.707: 10.0.14.0/24 via 0.0.0.0 in 1 hops
Mar 1 04:09:45.707: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.12.2)
Mar 1 04:09:45.707: RIP: build flash update entries
Mar 1 04:09:45.707: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 04:09:45.711: RIP: sending v2 flash update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 04:09:45.711: RIP: build flash update entries
Mar 1 04:09:45.711: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 04:09:55.147: RIP: received v2 update from 10.0.23.3 on Serial0/1
Mar 1 04:09:55.147: 4.4.4.0/24 via 0.0.0.0 in 3 hops
Mar 1 04:09:55.151: RT: SET_LAST_RDB for 4.4.4.0/24
NEW rdb: via 10.0.23.3
Mar 1 04:09:55.151: RT: add 4.4.4.0/24 via 10.0.23.3, rip metric [120/3]
Mar 1 04:09:55.155: RT: NET-RED 4.4.4.0/24
Mar 1 04:09:55.155: 10.0.14.0/24 via 0.0.0.0 in 2 hops
Mar 1 04:09:55.155: 10.0.34.0/24 via 0.0.0.0 in 1 hops
Mar 1 04:09:57.155: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.12.2)
Mar 1 04:09:57.155: RIP: build flash update entries
Mar 1 04:09:57.155: 4.4.4.0/24 via 0.0.0.0, metric 4, tag 0
Mar 1 04:09:57.159: RIP: sending v2 flash update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 04:09:57.159: RIP: build flash update entries - suppressing null update

R2 receives one of R3’s periodic updates about 12 seconds after hearing of the unreachable route from R1 and, despite what the book says, accepts the information immediately from R3.  Until the invalid timer expires on R3, all 4 routers have incorrect routing information.  R4 now believes it has a 5-hop route to it’s own former network through R1:

14-r4-show-ip-route

If R4 F0/0 comes back up before the invalid expires on R3, a different type of count-to-infinity problem occurs.  R3 still believes it has a route to 4.4.4.0/24 through R4 since it did not receive the update advertising it as unreachable while R4 F0/0 was down.  R4 believes it knows 4.4.4.0/24 through R1, so split-horizon will not prevent R4 from advertising it to R3 now that F0/0 is back up.  An increased metric received does not cause holddown to occur as we saw earlier, so when R3 receives an update from R4, a single circle of updates occurs with the metric increasing by 5 each time (4 routers + 1 from the offset) until it reaches 16:

R2#debug ip routing
R2#debug ip rip

Mar 1 04:11:08.355: RIP: received v2 update from 10.0.23.3 on Serial0/1
Mar 1 04:11:08.355: 4.4.4.0/24 via 0.0.0.0 in 8 hops
Mar 1 04:11:08.359: RT: rip's 4.4.4.0/24 (via 10.0.23.3) metric changed from distance/metric [120/3] to [120/8]
Mar 1 04:11:08.359: RT: NET-RED 4.4.4.0/24
Mar 1 04:11:10.363: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.12.2)
Mar 1 04:11:10.363: RIP: build flash update entries
Mar 1 04:11:10.363: 4.4.4.0/24 via 0.0.0.0, metric 9, tag 0
Mar 1 04:11:10.367: RIP: sending v2 flash update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 04:11:10.367: RIP: build flash update entries - suppressing null update
Mar 1 04:11:16.475: RIP: received v2 update from 10.0.23.3 on Serial0/1
Mar 1 04:11:16.479: 4.4.4.0/24 via 0.0.0.0 in 13 hops
Mar 1 04:11:16.479: RT: rip's 4.4.4.0/24 (via 10.0.23.3) metric changed from distance/metric [120/8] to [120/13]
Mar 1 04:11:16.479: RT: NET-RED 4.4.4.0/24
Mar 1 04:11:18.483: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.12.2)
Mar 1 04:11:18.483: RIP: build flash update entries
Mar 1 04:11:18.483: 4.4.4.0/24 via 0.0.0.0, metric 14, tag 0
Mar 1 04:11:18.487: RIP: sending v2 flash update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 04:11:18.487: RIP: build flash update entries - suppressing null update
Mar 1 04:11:24.703: RIP: received v2 update from 10.0.23.3 on Serial0/1
Mar 1 04:11:24.703: 4.4.4.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Mar 1 04:11:24.703: RT: del 4.4.4.0/24 via 10.0.23.3, rip metric [120/13]
Mar 1 04:11:24.703: RT: delete subnet route to 4.4.4.0/24
Mar 1 04:11:24.703: RT: NET-RED 4.4.4.0/24
Mar 1 04:11:24.707: RT: delete network route to 4.0.0.0
Mar 1 04:11:24.707: RT: NET-RED 4.0.0.0/8
Mar 1 04:11:26.707: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.12.2)
Mar 1 04:11:26.707: RIP: build flash update entries
Mar 1 04:11:26.707: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 04:11:26.707: RIP: sending v2 flash update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 04:11:26.707: RIP: build flash update entries
Mar 1 04:11:26.707: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0

 

 

So what exactly causes holddown to occur?  Earlier when we looked at the invalid timer, we saw the route placed into holddown when the invalid timer expired.  As it turns out, this is the only time that the holddown timer is used.  Let’s look at an example where we can see this being used.  We will shut down R4 F0/0.  The last update is received at 04:36:16.207.  After 180 seconds, the invalid expires and we see the message about the route entering holddown:

R3#debug ip rip
Mar 1 04:36:16.207: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 04:36:16.211: 4.4.4.0/24 via 0.0.0.0 in 2 hops
Mar 1 04:36:16.211: 10.0.12.0/24 via 0.0.0.0 in 2 hops
Mar 1 04:36:16.211: 10.0.14.0/24 via 0.0.0.0 in 1 hops

R4:
interface FastEthernet0/0
 shutdown

R3#debug ip routing
R3#debug ip rip
Mar 1 04:39:19.843: RT: delete route to 4.4.4.0 via 10.0.34.4, rip metric [120/2]
Mar 1 04:39:19.843: RT: SET_LAST_RDB for 4.4.4.0/24
OLD rdb: via 11.13.11.13
Mar 1 04:39:19.843: RT: no routes to 4.4.4.0, entering holddown
Mar 1 04:39:19.843: RT: NET-RED 4.4.4.0/24
Mar 1 04:39:19.843: RT: delete route to 10.0.14.0 via 10.0.34.4, rip metric [120/1]
Mar 1 04:39:19.843: RT: SET_LAST_RDB for 10.0.14.0/24
OLD rdb: via 11.13.11.13
Mar 1 04:39:19.843: RT: no routes to 10.0.14.0, entering holddown
Mar 1 04:39:19.843: RT: NET-RED 10.0.14.0/24
Mar 1 04:39:21.843: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 04:39:21.843: RIP: build flash update entries
Mar 1 04:39:21.843: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 04:39:21.843: 10.0.14.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 04:39:21.843: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 04:39:21.843: RIP: build flash update entries
Mar 1 04:39:21.843: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 04:39:21.843: 10.0.14.0/24 via 0.0.0.0, metric 16, tag 0

R3 receives an update from R2 advertising 4.4.4.0/24 with hop-count 3 a few seconds later, but the update is ignored because the route is in holddown:

R3#debug ip routing
Mar 1 04:39:38.135: RIP: received v2 update from 10.0.23.2 on Serial0/0
Mar 1 04:39:38.135: 4.4.4.0/24 via 0.0.0.0 in 3 hops
Mar 1 04:39:38.139: 10.0.12.0/24 via 0.0.0.0 in 1 hops
Mar 1 04:39:38.139: 10.0.14.0/24 via 0.0.0.0 in 2 hops

Let’s bring R4 F0/0 back up and see if R3 accepts the update from the original source:

R4:
interface FastEthernet0/0
 no shutdown

R3#debug ip rip
Mar 1 04:40:01.583: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 04:40:01.583: 4.4.4.0/24 via 0.0.0.0 in 2 hops
Mar 1 04:40:01.587: 10.0.12.0/24 via 0.0.0.0 in 2 hops
Mar 1 04:40:01.587: 10.0.14.0/24 via 0.0.0.0 in 1 hops

R3 ignores the update from the original source as well during the holddown period and continues advertising the route as unreachable out both interfaces:

R3#debug ip rip
Mar 1 04:40:05.363: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 04:40:05.363: RIP: build update entries
Mar 1 04:40:05.363: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 04:40:05.367: 10.0.14.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 04:40:05.367: 10.0.34.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 04:40:13.039: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 04:40:13.039: RIP: build update entries
Mar 1 04:40:13.039: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 04:40:13.043: 10.0.12.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 04:40:13.043: 10.0.14.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 04:40:13.043: 10.0.23.0/24 via 0.0.0.0, metric 1, tag 0

60 seconds after the invalid expired, the flush timer expires and the route is deleted:

R3#debug ip routing
Mar 1 04:40:19.843: RT: delete subnet route to 4.4.4.0/24
Mar 1 04:40:19.843: RT: NET-RED 4.4.4.0/24
Mar 1 04:40:19.843: RT: delete network route to 4.0.0.0
Mar 1 04:40:19.843: RT: NET-RED 4.0.0.0/8
Mar 1 04:40:19.843: RT: delete subnet route to 10.0.14.0/24
Mar 1 04:40:19.843: RT: NET-RED 10.0.14.0/24

When R3 receives the next periodic update from R4 a few seconds later, 4.4.4.0/24 and 10.0.14.0/24 are added back to the routing table and RIP database:

R3#debug ip routing
R3#debug ip rip
Mar 1 04:40:30.083: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 04:40:30.083: 4.4.4.0/24 via 0.0.0.0 in 2 hops
Mar 1 04:40:30.087: RT: SET_LAST_RDB for 4.4.4.0/24
NEW rdb: via 10.0.34.4
Mar 1 04:40:30.087: RT: add 4.4.4.0/24 via 10.0.34.4, rip metric [120/2]
Mar 1 04:40:30.087: RT: NET-RED 4.4.4.0/24
Mar 1 04:40:30.091: 10.0.12.0/24 via 0.0.0.0 in 2 hops
Mar 1 04:40:30.091: 10.0.14.0/24 via 0.0.0.0 in 1 hops
Mar 1 04:40:30.095: RT: SET_LAST_RDB for 10.0.14.0/24
NEW rdb: via 10.0.34.4
Mar 1 04:40:30.095: RT: add 10.0.14.0/24 via 10.0.34.4, rip metric [120/1]
Mar 1 04:40:30.095: RT: NET-RED 10.0.14.0/24

Wait a minute, if the holddown timer is 180 seconds by default shouldn’t updates be ignored for another 120 seconds?  If the flush timer expires before the holddown timer does, the route no longer exists in either the RIP database or routing table so any updates will be accepted for it.  Therefore, the effective holddown period is the lesser of the configured holddown timer and the flush minus the invalid timer.  Let’s repeat this with a holddown timer of 30 seconds to demonstrate this:

R3:
router rip
 timers basic 30 180 30 240

R3#debug ip rip
Mar 1 04:50:25.167: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 04:50:25.167: 4.4.4.0/24 via 0.0.0.0 in 2 hops
Mar 1 04:50:25.171: 10.0.12.0/24 via 0.0.0.0 in 2 hops
Mar 1 04:50:25.171: 10.0.14.0/24 via 0.0.0.0 in 1 hops

R4:
interface FastEthernet0/0
 shutdown

The routes enter holddown at 04:53:27.827:

R3#debug ip routing
R3#debug ip rip

Mar 1 04:53:27.823: RT: delete route to 4.4.4.0 via 10.0.34.4, rip metric [120/2]
Mar 1 04:53:27.823: RT: SET_LAST_RDB for 4.4.4.0/24
OLD rdb: via 11.13.11.13
Mar 1 04:53:27.827: RT: no routes to 4.4.4.0, entering holddown
Mar 1 04:53:27.827: RT: NET-RED 4.4.4.0/24
Mar 1 04:53:27.827: RT: delete route to 10.0.14.0 via 10.0.34.4, rip metric [120/1]
Mar 1 04:53:27.831: RT: SET_LAST_RDB for 10.0.14.0/24
OLD rdb: via 11.13.11.13
Mar 1 04:53:27.831: RT: no routes to 10.0.14.0, entering holddown
Mar 1 04:53:27.831: RT: NET-RED 10.0.14.0/24
Mar 1 04:53:29.827: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 04:53:29.827: RIP: build flash update entries
Mar 1 04:53:29.827: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 04:53:29.831: 10.0.14.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 04:53:29.831: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 04:53:29.831: RIP: build flash update entries
Mar 1 04:53:29.831: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 04:53:29.835: 10.0.14.0/24 via 0.0.0.0, metric 16, tag 0

After bringing R4 F0/0 back up, R3 receives a periodic update from R4 a little over 30 seconds after the routes entered holddown.  We see a log message stating that the routes have come out of holddown and the new routing information has been accepted:

R3#debug ip routing
R3#debug ip rip

Mar 1 04:53:59.203: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 04:53:59.203: 4.4.4.0/24 via 0.0.0.0 in 2 hops
Mar 1 04:53:59.203: RT: 4.4.4.0 came out of holddown
Mar 1 04:53:59.203: RT: SET_LAST_RDB for 4.4.4.0/24
NEW rdb: via 10.0.34.4
Mar 1 04:53:59.203: RT: add 4.4.4.0/24 via 10.0.34.4, rip metric [120/2]
Mar 1 04:53:59.203: RT: NET-RED 4.4.4.0/24
Mar 1 04:53:59.203: 10.0.12.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Mar 1 04:53:59.207: 10.0.14.0/24 via 0.0.0.0 in 1 hops
Mar 1 04:53:59.207: RT: 10.0.14.0 came out of holddown
Mar 1 04:53:59.207: RT: SET_LAST_RDB for 10.0.14.0/24
NEW rdb: via 10.0.34.4
Mar 1 04:53:59.207: RT: add 10.0.14.0/24 via 10.0.34.4, rip metric [120/1]
Mar 1 04:53:59.211: RT: NET-RED 10.0.14.0/24
Mar 1 04:54:01.203: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 04:54:01.203: RIP: build flash update entries - suppressing null update
Mar 1 04:54:01.203: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 04:54:01.207: RIP: build flash update entries
Mar 1 04:54:01.207: 4.4.4.0/24 via 0.0.0.0, metric 3, tag 0
Mar 1 04:54:01.207: 10.0.14.0/24 via 0.0.0.0, metric 2, tag 0

 

So now we’ve seen how the holddown timer actually works, but this brings up another question:  If the route isn’t being placed in holddown when an unreachable update is received, what exactly is happening and how does the router know how long to pass the unreachable advertisement along?  The behavior is similar to when the invalid timer first expires on a router, with 2 exceptions:

1.  The route is not placed in holddown

2.  The route is maintained only in the RIP database.  It is removed from the routing table immediately and therefore not used to forward packets.

A router receiving an unreachable advertisement keeps the route in the RIP database for (flush – invalid) seconds and continues including it in updates as long as it is there.  This means that when an unreachable route is received, the actual values of the flush and invalid are not important for controlling how long the route continues to be advertised, only the difference between them.  To demonstrate this, we will change the flush and invalid timers on R1, R2, and R3.  The flush timer on R1 will be lowered to 180, the same as the invalid.  The invalid timer on R2 will be lowered to 60 while keeping the default flush of 240.  The invalid and flush will both be set to very high values on R3 while maintaining the difference of 60 between the two:

R1:
router rip
 timers basic 30 180 180 180

R2:
router rip
 timers basic 30 60 180 240

R3:
router rip
 timers basic 30 10000 180 10060

We will then shut down R4’s loopback.  All other interfaces are up, so the other 3 routers will learn of the failed route by an unreachable advertisement rather than by their invalid timer expiring:

R4:
interface Loopback0
 shutdown

Each of the routers hears of the failed route at approximately 05:34:33.  R1, whose (flush – invalid) is 0 seconds, keeps the failed route in the RIP database just long enough to send a flash update out all interfaces.  There is no log message showing when a route is removed from the RIP database, but we can see that at the first periodic update the route is no longer included:

R1#debug ip routing
R1#debug ip rip

Mar 1 05:34:32.799: RIP: received v2 update from 10.0.14.4 on Serial0/1
Mar 1 05:34:32.799: 4.4.4.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Mar 1 05:34:32.799: RT: del 4.4.4.0/24 via 10.0.14.4, rip metric [120/1]
Mar 1 05:34:32.803: RT: delete subnet route to 4.4.4.0/24
Mar 1 05:34:32.803: RT: NET-RED 4.4.4.0/24
Mar 1 05:34:32.803: RT: delete network route to 4.0.0.0
Mar 1 05:34:32.807: RT: NET-RED 4.0.0.0/8
Mar 1 05:34:32.807: 10.0.23.0/24 via 0.0.0.0 in 2 hops
Mar 1 05:34:32.807: 10.0.34.0/24 via 0.0.0.0 in 1 hops
Mar 1 05:34:34.807: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.12.1)
Mar 1 05:34:34.807: RIP: build flash update entries
Mar 1 05:34:34.807: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 05:34:34.811: RIP: sending v2 flash update to 224.0.0.9 via Serial0/1 (10.0.14.1)
Mar 1 05:34:34.811: RIP: build flash update entries
Mar 1 05:34:34.811: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 05:34:46.087: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (10.0.14.1)
Mar 1 05:34:46.087: RIP: build update entries
Mar 1 05:34:46.087: 10.0.12.0/24 via 0.0.0.0, metric 1, tag 0

Mar 1 05:34:46.091: 10.0.23.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 05:34:48.039: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.0.12.1)
Mar 1 05:34:48.039: RIP: build update entries
Mar 1 05:34:48.039: 10.0.14.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 05:34:48.043: 10.0.34.0/24 via 0.0.0.0, metric 2, tag 0

R2’s flush – invalid is 180 seconds, which is approximately how long the route continues to be advertised for.  Only the last of it’s periodic updates that include 4.4.4.0/24 and the first of it’s periodic updates that exclude it are shown to keep the output shorter:

R2#debug ip routing
R2#debug ip rip
Mar 1 05:34:35.691: RIP: received v2 update from 10.0.12.1 on Serial0/0
Mar 1 05:34:35.691: 4.4.4.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Mar 1 05:34:35.691: RT: del 4.4.4.0/24 via 10.0.12.1, rip metric [120/2]
Mar 1 05:34:35.695: RT: delete subnet route to 4.4.4.0/24
Mar 1 05:34:35.695: RT: NET-RED 4.4.4.0/24
Mar 1 05:34:35.695: RT: delete network route to 4.0.0.0
Mar 1 05:34:35.695: RT: NET-RED 4.0.0.0/8
Mar 1 05:34:37.699: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.12.2)
Mar 1 05:34:37.699: RIP: build flash update entries
Mar 1 05:34:37.699: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 05:34:37.703: RIP: sending v2 flash update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 05:34:37.703: RIP: build flash update entries
Mar 1 05:34:37.703: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0

15-r2-show-ip-route

15-r2-rip-database

R2#debug ip rip
R2#debug ip routing

Mar 1 05:37:11.683: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 05:37:11.683: RIP: build update entries
Mar 1 05:37:11.683: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 05:37:11.687: 10.0.12.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 05:37:11.687: 10.0.14.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 05:37:13.375: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.0.12.2)
Mar 1 05:37:13.375: RIP: build update entries
Mar 1 05:37:13.375: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 05:37:13.379: 10.0.23.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 05:37:13.379: 10.0.34.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 05:37:39.963: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.0.12.2)
Mar 1 05:37:39.963: RIP: build update entries
Mar 1 05:37:39.963: 10.0.23.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 05:37:39.967: 10.0.34.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 05:37:40.167: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 05:37:40.167: RIP: build update entries
Mar 1 05:37:40.167: 10.0.12.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 05:37:40.167: 10.0.14.0/24 via 0.0.0.0, metric 2, tag 0

16-r2-rip-database

R3’s flush – invalid is 60 seconds, and even though we set them to very high values, we can see that the failed route is advertised for 60 seconds just like the default.  Again, only the last periodic update including 4.4.4.0/24 and first periodic update excluding it are shown:

R3#debug ip routing
R3#debug ip rip

Mar 1 05:34:35.407: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 05:34:35.407: 4.4.4.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Mar 1 05:34:35.411: RT: del 4.4.4.0/24 via 10.0.34.4, rip metric [120/2]
Mar 1 05:34:35.411: RT: delete subnet route to 4.4.4.0/24
Mar 1 05:34:35.411: RT: NET-RED 4.4.4.0/24
Mar 1 05:34:35.415: RT: delete network route to 4.0.0.0
Mar 1 05:34:35.415: RT: NET-RED 4.0.0.0/8
Mar 1 05:34:37.415: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 05:34:37.415: RIP: build flash update entries
Mar 1 05:34:37.415: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 05:34:37.419: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 05:34:37.419: RIP: build flash update entries
Mar 1 05:34:37.419: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 05:35:35.875: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 05:35:35.875: RIP: build update entries
Mar 1 05:35:35.875: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 05:35:35.879: 10.0.14.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 05:35:35.879: 10.0.34.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 05:35:37.163: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 05:35:37.163: RIP: build update entries
Mar 1 05:35:37.163: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 05:35:37.167: 10.0.12.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 05:35:37.167: 10.0.23.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 05:36:02.035: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.0.23.3)
Mar 1 05:36:02.035: RIP: build update entries
Mar 1 05:36:02.035: 10.0.14.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 05:36:02.039: 10.0.34.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 05:36:05.587: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 05:36:05.587: RIP: build update entries
Mar 1 05:36:05.587: 10.0.12.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 05:36:05.591: 10.0.23.0/24 via 0.0.0.0, metric 1, tag 0

 

 

Next, we will look at the holddown timer in RIPng.  The holddown timer in RIPng is quite a bit different than in RIPv1/v2.  The default setting for the holddown timer is 0 seconds, so it is not even used in RIPng unless explicitly configured:

17-r3-ripng

If it is enabled, the holddown timer in RIPng works similarly to how the holddown timer in RIPv1/v2 is supposed to work.  Holddown in RIPng is activated by either of the following:

1.  The invalid timer expiring (same as RIPv1/v2)

2.  An unreachable route advertisement being received from the best route source 

We’ve already seen a route placed in holddown when the invalid expired in RIPv2, so let’s try it with an unreachable route advertisement in RIPng.  We will set a holddown timer of 60 seconds on R3 to test this out and keep the other timers at their defaults:

R3:
ipv6 router rip test
 timers 30 180 60 120

Next we will shutdown R4’s loopback:

R4:
interface Loopback0
 shutdown

R3 deletes the route to 4.4.4.0/24 right away after receiving an update from R4.  In the RIP database, we see that the holddown timer has begun counting down:

R3#debug ipv6 routing
R3#debug ipv6 rip

Mar 1 01:39:28.967: RIPng: response received from FE80::4 on FastEthernet0/0 for test
Mar 1 01:39:28.967: src=FE80::4 (FastEthernet0/0)
Mar 1 01:39:28.967: dst=FF02::9
Mar 1 01:39:28.971: sport=521, dport=521, length=92
Mar 1 01:39:28.971: command=2, version=1, mbz=0, #rte=4
Mar 1 01:39:28.971: tag=0, metric=1, prefix=2001:DB8:0:14::/64
Mar 1 01:39:28.971: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 01:39:28.971: tag=0, metric=2, prefix=2001:DB8:0:12::/64
Mar 1 01:39:28.971: tag=0, metric=16, prefix=2001:DB8:0:4444::/64
Mar 1 01:39:28.975: RIPng: 2001:DB8:0:4444::/64, path FE80::4/FastEthernet0/0 unreachable
Mar 1 01:39:28.975: IPv6RT0: rip test, Delete 2001:DB8:0:4444::/64 from table
Mar 1 01:39:28.975: RIPng: 2001:DB8:0:4444::/64, expired, ttg is 60
Mar 1 01:39:28.979: RIPng: Triggered update requested
Mar 1 01:39:28.979: IPv6RT0: Event: 2001:DB8:0:4444::/64, Del, owner rip, previous None
Mar 1 01:39:29.979: RIPng: generating triggered update for test
Mar 1 01:39:29.979: RIPng: Sending multicast update on Serial0/0 for test
Mar 1 01:39:29.979: src=FE80::3
Mar 1 01:39:29.979: dst=FF02::9 (Serial0/0)
Mar 1 01:39:29.979: sport=521, dport=521, length=32
Mar 1 01:39:29.979: command=2, version=1, mbz=0, #rte=1
Mar 1 01:39:29.979: tag=0, metric=16, prefix=2001:DB8:0:4444::/64
Mar 1 01:39:29.979: RIPng: Suppressed null multicast update on FastEthernet0/0 for test

17-r3-ripng-database

If we bring R4’s loopback back up before the holddown expires, R3 receives a flash update from R4.  R3 also receives a flash update from R2 since R1 and R2 are using default timers and therefore did not place the route into holddown.  R3 ignores the flash updates from both routers, and even generates log messages showing that the updates were ignored because of holddown:

R3#debug ipv6 rip
Mar 1 01:39:43.867: RIPng: response received from FE80::4 on FastEthernet0/0 for test
Mar 1 01:39:43.867: src=FE80::4 (FastEthernet0/0)
Mar 1 01:39:43.871: dst=FF02::9
Mar 1 01:39:43.871: sport=521, dport=521, length=32
Mar 1 01:39:43.871: command=2, version=1, mbz=0, #rte=1
Mar 1 01:39:43.871: tag=0, metric=1, prefix=2001:DB8:0:4444::/64
Mar 1 01:39:43.871: RIPng: 2001:DB8:0:4444::/64, held-down, ignoring update
Mar 1 01:39:47.815: RIPng: response received from FE80::2 on Serial0/0 for test
Mar 1 01:39:47.815: src=FE80::2 (Serial0/0)
Mar 1 01:39:47.819: dst=FF02::9
Mar 1 01:39:47.819: sport=521, dport=521, length=32
Mar 1 01:39:47.819: command=2, version=1, mbz=0, #rte=1
Mar 1 01:39:47.819: tag=0, metric=3, prefix=2001:DB8:0:4444::/64
Mar 1 01:39:47.819: RIPng: 2001:DB8:0:4444::/64, held-down, ignoring update

The next periodic update is ignored as well.  The first periodic update that arrives after the holddown timer has expired is accepted and the route is added back to the routing table (R2’s update arrives earlier so the metric changes when R4’s update arrives):

R3#debug ipv6 routing
R3#debug ipv6 rip

Mar 1 01:40:37.131: RIPng: response received from FE80::2 on Serial0/0 for test
Mar 1 01:40:37.131: src=FE80::2 (Serial0/0)
Mar 1 01:40:37.131: dst=FF02::9
Mar 1 01:40:37.131: sport=521, dport=521, length=92
Mar 1 01:40:37.135: command=2, version=1, mbz=0, #rte=4
Mar 1 01:40:37.135: tag=0, metric=1, prefix=2001:DB8:0:12::/64
Mar 1 01:40:37.135: tag=0, metric=1, prefix=2001:DB8:0:23::/64
Mar 1 01:40:37.135: tag=0, metric=2, prefix=2001:DB8:0:14::/64
Mar 1 01:40:37.135: tag=0, metric=3, prefix=2001:DB8:0:4444::/64
Mar 1 01:40:37.139: RIPng: 2001:DB8:0:4444::/64, metric changed to 4
Mar 1 01:40:37.139: RIPng: 2001:DB8:0:4444::/64, added path FE80::2/Serial0/0
Mar 1 01:40:37.139: IPv6RT0: rip test, Route add 2001:DB8:0:4444::/64 [new]
Mar 1 01:40:37.143: IPv6RT0: rip test, Add 2001:DB8:0:4444::/64 to table
Mar 1 01:40:37.143: IPv6RT0: rip test, Adding next-hop FE80::2 over Serial0/0 for 2001:DB8:0:4444::/64, [120/4]
Mar 1 01:40:37.143: RIPng: Triggered update requested
Mar 1 01:40:37.147: IPv6RT0: Event: 2001:DB8:0:4444::/64, Add, owner rip, previous None
Mar 1 01:40:37.779: RIPng: response received from FE80::4 on FastEthernet0/0 for test
Mar 1 01:40:37.779: src=FE80::4 (FastEthernet0/0)
Mar 1 01:40:37.783: dst=FF02::9
Mar 1 01:40:37.783: sport=521, dport=521, length=92
Mar 1 01:40:37.783: command=2, version=1, mbz=0, #rte=4
Mar 1 01:40:37.783: tag=0, metric=1, prefix=2001:DB8:0:14::/64
Mar 1 01:40:37.783: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 01:40:37.787: tag=0, metric=1, prefix=2001:DB8:0:4444::/64
Mar 1 01:40:37.787: tag=0, metric=2, prefix=2001:DB8:0:12::/64
Mar 1 01:40:37.787: RIPng: 2001:DB8:0:4444::/64, metric changed to 2
Mar 1 01:40:37.787: RIPng: 2001:DB8:0:4444::/64, added path FE80::4/FastEthernet0/0
Mar 1 01:40:37.791: IPv6RT0: rip test, Route add 2001:DB8:0:4444::/64 [better metric 2, 4]
Mar 1 01:40:37.791: IPv6RT0: rip test, Adding next-hop FE80::4 over FastEthernet0/0 for 2001:DB8:0:4444::/64, [120/2]
Mar 1 01:40:37.791: RIPng: Triggered update requested, delaying
Mar 1 01:40:37.795: IPv6RT0: Event: 2001:DB8:0:4444::/64, Mod, owner rip, previous None
Mar 1 01:40:38.143: RIPng: generating triggered update for test
Mar 1 01:40:38.143: RIPng: Sending multicast update on Serial0/0 for test
Mar 1 01:40:38.143: src=FE80::3
Mar 1 01:40:38.143: dst=FF02::9 (Serial0/0)
Mar 1 01:40:38.147: sport=521, dport=521, length=32
Mar 1 01:40:38.147: command=2, version=1, mbz=0, #rte=1
Mar 1 01:40:38.147: tag=0, metric=2, prefix=2001:DB8:0:4444::/64
Mar 1 01:40:38.151: RIPng: Suppressed null multicast update on FastEthernet0/0 for test

This partially agrees with what the last two sources had to say about how the holddown timer was supposed to work in RIPv1/v2 (however the route does not continue to be used for forwarding during the holddown and information from the original source is not accepted prior to the holddown expiring, as they say).  The Routing TCP/IP Volume 1 description of the holddown timer, which said that when a metric increases the route should be placed in holddown, still does not happen in RIPng.  R3’s current routing table looks like this:

18-r3-show-ipv6-route

R3’s best route to 2001:db8:0:14::/64 is 2 hops through R4.  We will change the hop-count added to routes received on R3 F0/0 from 1 to 7:

R3:
interface FastEthernet0/0
 ipv6 rip test metric-offset 7

When the next periodic update arrives from R4 on F0/0, R3 immediately updates the metric for the route and continues to keep it in the routing table:

R3#debug ipv6 routing
R3#debug ipv6 rip

Mar 1 01:55:46.315: RIPng: response received from FE80::4 on FastEthernet0/0 for test
Mar 1 01:55:46.315: src=FE80::4 (FastEthernet0/0)
Mar 1 01:55:46.319: dst=FF02::9
Mar 1 01:55:46.319: sport=521, dport=521, length=92
Mar 1 01:55:46.319: command=2, version=1, mbz=0, #rte=4
Mar 1 01:55:46.319: tag=0, metric=1, prefix=2001:DB8:0:34::/64
Mar 1 01:55:46.319: tag=0, metric=1, prefix=2001:DB8:0:14::/64
Mar 1 01:55:46.319: tag=0, metric=1, prefix=2001:DB8:0:4444::/64
Mar 1 01:55:46.323: tag=0, metric=2, prefix=2001:DB8:0:12::/64
Mar 1 01:55:46.323: RIPng: 2001:DB8:0:34::/64, metric changed to 8
Mar 1 01:55:46.323: RIPng: 2001:DB8:0:14::/64, metric changed to 8
Mar 1 01:55:46.323: IPv6RT0: rip test, Route add 2001:DB8:0:14::/64 [worse metric 8, 2]
Mar 1 01:55:46.327: RIPng: 2001:DB8:0:4444::/64, metric changed to 8
Mar 1 01:55:46.327: IPv6RT0: rip test, Route add 2001:DB8:0:4444::/64 [worse metric 8, 2]
Mar 1 01:55:46.327: RIPng: Triggered update requested
Mar 1 01:55:46.331: IPv6RT0: Event: 2001:DB8:0:14::/64, Mod, owner rip, previous None
Mar 1 01:55:46.331: IPv6RT0: Event: 2001:DB8:0:4444::/64, Mod, owner rip, previous None

A periodic update arrives just after this from R2, advertising the route as metric 2 (3 after R3 adds 1 to it).  R3 replaces the route from R4 with this one immediately:

R3#debug ipv6 routing
R3#debug ipv6 rip
Mar 1 01:55:47.003: RIPng: response received from FE80::2 on Serial0/0 for test
Mar 1 01:55:47.003: src=FE80::2 (Serial0/0)
Mar 1 01:55:47.007: dst=FF02::9
Mar 1 01:55:47.007: sport=521, dport=521, length=72
Mar 1 01:55:47.007: command=2, version=1, mbz=0, #rte=3
Mar 1 01:55:47.007: tag=0, metric=1, prefix=2001:DB8:0:12::/64
Mar 1 01:55:47.007: tag=0, metric=1, prefix=2001:DB8:0:23::/64
Mar 1 01:55:47.007: tag=0, metric=2, prefix=2001:DB8:0:14::/64
Mar 1 01:55:47.011: RIPng: 2001:DB8:0:14::/64, metric changed to 3
Mar 1 01:55:47.011: RIPng: 2001:DB8:0:14::/64, added path FE80::2/Serial0/0
Mar 1 01:55:47.011: IPv6RT0: rip test, Route add 2001:DB8:0:14::/64 [better metric 3, 8]
Mar 1 01:55:47.015: IPv6RT0: rip test, Adding next-hop FE80::2 over Serial0/0 for 2001:DB8:0:14::/64, [120/3]
Mar 1 01:55:47.015: RIPng: Triggered update requested, delaying
Mar 1 01:55:47.019: IPv6RT0: Event: 2001:DB8:0:14::/64, Mod, owner rip, previous None

Posted in IPv6, RIP | Leave a Comment »

VLSM Usage and Mismatched Subnet Masks in RIPv1

Posted by Andy on April 12, 2009

In this post we will look at what happens when a router using VLSM attempts to advertise the variably subnetted address space with RIPv1.  We will also look at what happens when opposite ends of a link are configured with different subnet masks in RIPv1.  The topology and configurations are shown below:

ripv1-vlsm

R1:
interface Loopback1
 ip address 10.1.1.1 255.255.255.0
!
interface Loopback2
 ip address 10.1.2.1 255.255.255.0
!
interface Loopback3
 ip address 10.1.3.1 255.255.255.0
!
interface Loopback4
 ip address 10.1.4.1 255.255.255.0
!
interface Loopback5
 ip address 10.1.5.1 255.255.255.192
!
interface Loopback6
 ip address 10.1.6.65 255.255.255.192
!
interface Loopback7
 ip address 10.1.7.129 255.255.255.192
!
interface Loopback8
 ip address 10.1.8.193 255.255.255.192
!
interface Serial0/0
 ip address 10.0.12.1 255.255.255.0

R2:
interface Loopback1
 ip address 10.2.1.2 255.255.255.0
!
interface Loopback2
 ip address 10.2.2.2 255.255.255.0
!
interface Loopback3
 ip address 10.2.3.2 255.255.255.0
!
interface Loopback4
 ip address 10.2.4.2 255.255.255.0
!
interface Loopback5
 ip address 10.2.5.2 255.255.255.192
!
interface Loopback6
 ip address 10.2.6.65 255.255.255.192
!
interface Loopback7
 ip address 10.2.7.129 255.255.255.192
!
interface Loopback8
 ip address 10.2.8.193 255.255.255.192
!
interface Serial0/0
 ip address 10.0.12.2 255.255.255.0

We will enable RIPv1 for the 10.0.0.0 network on each router.  We will also configure all loopback interfaces as passive interfaces so that there isn’t so much debug output:

R1:
router rip
 passive-interface default
 no passive-interface Serial0/0
 network 10.0.0.0

R2:
router rip
 passive-interface default
 no passive-interface Serial0/0
 network 10.0.0.0

R1 and R2 send only routes that have the same mask as the outgoing interface.  All /24 networks are sent and added to each other’s routing tables, and neither has knowledge of the other /26 networks:

R1#debug ip rip
*Mar 1 00:26:03.619: RIP: sending v1 update to 10.0.12.2 via Serial0/0 (10.0.12.1)
*Mar 1 00:26:03.623: RIP: build update entries
*Mar 1 00:26:03.623: subnet 10.1.1.0 metric 1
*Mar 1 00:26:03.623: subnet 10.1.2.0 metric 1
*Mar 1 00:26:03.623: subnet 10.1.3.0 metric 1
*Mar 1 00:26:03.627: subnet 10.1.4.0 metric 1
*Mar 1 00:26:05.643: RIP: received v1 update from 10.0.12.2 on Serial0/0
*Mar 1 00:26:05.643: 10.2.1.0 in 1 hops
*Mar 1 00:26:05.647: 10.2.2.0 in 1 hops
*Mar 1 00:26:05.651: 10.2.3.0 in 1 hops
*Mar 1 00:26:05.651: 10.2.4.0 in 1 hops

1-r1-route-table

1-r2-route-table

 

Next, we will change R2 to use a /26 mask on S0/0:

R2:
interface Serial0/0
 ip address 10.0.12.2 255.255.255.192

R2 stops sending the /24 routes in updates and begins sending the /26 routes:

R2#debug ip rip
*Mar 1 00:36:36.751: RIP: received v1 update from 10.0.12.1 on Serial0/0
*Mar 1 00:36:36.751: 10.1.1.0 in 1 hops
*Mar 1 00:36:36.751: 10.1.2.0 in 1 hops
*Mar 1 00:36:36.751: 10.1.3.0 in 1 hops
*Mar 1 00:36:36.751: 10.1.4.0 in 1 hops
*Mar 1 00:36:58.327: RIP: sending v1 update to 255.255.255.255 via Serial0/0 (10.0.12.2)
*Mar 1 00:36:58.327: RIP: build update entries
*Mar 1 00:36:58.331: subnet 10.2.5.0 metric 1
*Mar 1 00:36:58.331: subnet 10.2.6.64 metric 1
*Mar 1 00:36:58.331: subnet 10.2.7.128 metric 1
*Mar 1 00:36:58.331: subnet 10.2.8.192 metric 1

Because mask information is not carried in routing updates in RIPv1, the mask of the receiving interface is also used for determining the mask of received routes.  R2 interprets R1’s routes as all having /26 masks.  As a result, only the first 1/4 of the address space of each route is reachable from R2.  Once the flush timer expires for the old routes after changing the mask, R2’s route table now looks like this:

2-r2-route-table

R1 interprets all the routes received from R2 as having /24 masks.  Of the 4 routes received from R2, only 10.2.5.0 is a valid subnet address using a /24 mask.  Since the other 3 are invalid /24 subnets, they are instead interpreted as host routes and added with a /32 mask:

2-r1-route-table

The result is that R1 will attempt to route traffic in the range 10.2.5.64 – 10.2.5.255 to R2 when it should not, and will not route any traffic to the other 3 /26 networks when it should.

Posted in RIP | Leave a Comment »

Some Strange Static Routing Issues

Posted by Andy on April 8, 2009

In this post we will look at two static routing issues that I have yet to find an explanation for.  R1 and R2 are connected by 3 serial interfaces, one using a subnet of a class A network, one a class B, and one a class C:

static-routing-topology2

R1:
interface Serial0/0
 ip address 10.0.12.1 255.255.255.252
interface Serial0/1
 ip address 172.16.12.1 255.255.255.252
interface Serial0/2
 ip address 192.168.12.1 255.255.255.252

R2:
interface Serial0/0
 ip address 10.0.12.2 255.255.255.252
interface Serial0/1
 ip address 172.16.12.2 255.255.255.252
interface Serial0/2
 ip address 192.168.12.2 255.255.255.252

The first issue occurs when all of the following are true:

 

  • The static route is configured with a next-hop address

 

  • At least 1 subnet of the major network specified by the next-hop address in the static route statement is present in the routing table, but no subnets that match the specific IP address

 

  • The best match for the IP address specified in the static route is the default route

 

  • The default route is configured with an exit interface

 

Static routes matching all of these conditions are not entered in the routing table even though there is a match for the next-hop address using the default route.  If no subnets of the major network exist in the routing table, or if the best match is anything but the default route and is configured with an exit interface, the static route will be installed.  Let’s look at a few examples.  First we will add the default route using an exit interface:

R1:
ip route 0.0.0.0 0.0.0.0 Serial0/0

1-show-ip-route

Next we will add a couple static routes with random next-hop addresses:

R1:
ip route 1.0.0.0 255.0.0.0 21.1.1.1
ip route 2.0.0.0 255.0.0.0 22.1.1.1

The next-hop for both routes resolves to the default route.  No subnets of 21.0.0.0/8 or 22.0.0.0/8 exist in the routing table.  Both routes are installed:

R1#debug ip routing
Mar 1 00:25:16.899: RT: SET_LAST_RDB for 1.0.0.0/8
NEW rdb: via 21.1.1.1
Mar 1 00:25:16.899: RT: add 1.0.0.0/8 via 21.1.1.1, static metric [1/0]
Mar 1 00:25:16.903: RT: NET-RED 1.0.0.0/8
Mar 1 00:25:19.275: RT: SET_LAST_RDB for 2.0.0.0/8
NEW rdb: via 22.1.1.1
Mar 1 00:25:19.275: RT: add 2.0.0.0/8 via 22.1.1.1, static metric [1/0]
Mar 1 00:25:19.275: RT: NET-RED 2.0.0.0/8

Next we will try to add static routes with next-hop addresses in the same major networks as the directly connected subnets used on the serial links:

R1:
ip route 3.0.0.0 255.0.0.0 10.255.255.50
ip route 4.0.0.0 255.0.0.0 172.16.255.50
ip route 5.0.0.0 255.0.0.0 192.168.12.50

One subnet of each classful network exists, but none of them match the next-hop address.  The best match on all 3 next-hop addresses should be the default route.  However, none of these 3 routes are installed in the routing table:

2-show-ip-route

If we add a static route to 21.21.21.0/24 with a next-hop of another random address, the route is added just like the first 2 routes because no subnets of the major network exist.  However, this also causes the 1.0.0.0 network to be removed after several seconds when the router realizes it now has a subnet of 21.0.0.0/8, but no specific subnet of the classful network to reach 21.1.1.1 – the next-hop for 1.0.0.0:

R1:
ip route 21.21.21.0 255.255.255.0 23.1.1.1

R1#debug ip routing
Mar 1 00:38:03.331: RT: SET_LAST_RDB for 21.21.21.0/24
NEW rdb: via 23.1.1.1
Mar 1 00:38:03.331: RT: add 21.21.21.0/24 via 23.1.1.1, static metric [1/0]
Mar 1 00:38:03.335: RT: NET-RED 21.21.21.0/24
Mar 1 00:38:55.619: RT: del 1.0.0.0 via 21.1.1.1, static metric [1/0]
Mar 1 00:38:55.619: RT: delete network route to 1.0.0.0
Mar 1 00:38:55.619: RT: NET-RED 1.0.0.0/8
Mar 1 00:38:55.623: RT: NET-RED 0.0.0.0/0

3-show-ip-route

This classful behavior only occurs when the best match is the default route.  If we add two /1 networks to cover the entire range covered by the default route and configure them with exit interfaces just like the default route, all of the static routes we configured match one of the two /1 static routes and are added to the routing table:

R1:
ip route 0.0.0.0 128.0.0.0 Serial0/0
ip route 128.0.0.0 128.0.0.0 Serial0/0

4-show-ip-route

 

 

 

 

The second issue occurs when all of the following things are true:

 

  • The static route is configured with a next-hop address

 

  • The best match for the IP address specified in the static route is another static route configured with a next-hop address or a route learned from a routing protocol

 

  • The best match route uses a less specific mask than the route being configured

 

  • The range of the best match route includes the range of the route being configured

 

Static routes meeting all of these conditions are not installed in the routing table, even though the next-hop address may resolve to a valid route.  Let’s look at a couple examples of this.  First we will remove all of the static route statements from the previous example:

R1:
no ip route 0.0.0.0 0.0.0.0 Serial0/0
no ip route 0.0.0.0 128.0.0.0 Serial0/0
no ip route 1.0.0.0 255.0.0.0 21.1.1.1
no ip route 2.0.0.0 255.0.0.0 22.1.1.1
no ip route 3.0.0.0 255.0.0.0 10.255.255.50
no ip route 4.0.0.0 255.0.0.0 172.16.255.50
no ip route 5.0.0.0 255.0.0.0 192.168.12.50
no ip route 21.21.21.0 255.255.255.0 23.1.1.1
no ip route 128.0.0.0 128.0.0.0 Serial0/0

We will enable RIP between R1 and R2 on S0/0 and create a loopback interface on R2 to be advertised with RIP. We will also create a static route with a next-hop of R2’s S0/0 interface IP address:

R1:
router rip
 network 10.0.0.0
!
ip route 4.0.0.0 255.0.0.0 10.0.12.2

R2:
interface Loopback0
 ip address 2.2.2.2 255.0.0.0
!
router rip
 network 2.0.0.0
 network 10.0.0.0

R1 adds both routes with a next-hop of 10.0.12.2:

5-show-ip-route

Next we will create some static routes with next-hop addresses that match these 2 routes:

R1:
ip route 2.0.0.0 254.0.0.0 2.255.255.1
ip route 2.0.0.0 255.128.0.0 2.255.255.1
ip route 4.0.0.0 254.0.0.0 4.255.255.1
ip route 4.0.0.0 255.128.0.0 4.255.255.1
ip route 4.0.0.0 255.128.0.0 4.1.1.1

Only the 1st and 3rd routes are installed in the routing table.  These two routes both use a less specific mask than the best match for their next-hop addresses:

6-show-ip-route

The three /9 routes, which use a more specific mask than the best match for their next-hop, are not installed.  There is the risk that a route could be self-recursive if, after being installed, the best route to it’s next hop is itself.  We can see that this is true for the 4.0.0.0/9 route with a next-hop of 4.1.1.1.  If installed, the best route to it’s next-hop address would be itself.  However the other two /9 routes do not have this problem since their next-hop addresses are both outside of their own range.  If installed, their next-hop would resolve to the two /8 routes, both of which are valid. 

This issue only occurs when the matching route uses a next-hop address.  If we change 4.0.0.0/8 to use an exit interface rather than a next-hop address, R1 installs the route to 4.0.0.0/9 via 4.255.255.1 several seconds later after it’s next scan of the routing table.  The other, self-recursive route to 4.0.0.0/9 via 4.1.1.1 remains uninstalled, as it should:

R1:
no ip route 4.0.0.0 255.0.0.0 10.0.12.2
ip route 4.0.0.0 255.0.0.0 Serial0/0

R1#debug ip routing
Mar 1 01:24:57.171: RT: SET_LAST_RDB for 4.0.0.0/8
NEW rdb: is directly connected
Mar 1 01:24:57.171: RT: add 4.0.0.0/8 via 0.0.0.0, static metric [1/0]
Mar 1 01:24:57.171: RT: NET-RED 4.0.0.0/8
Mar 1 01:25:34.571: RT: network 4.0.0.0 is now variably masked
Mar 1 01:25:34.571: RT: SET_LAST_RDB for 4.0.0.0/9
NEW rdb: via 4.255.255.1
Mar 1 01:25:34.575: RT: add 4.0.0.0/9 via 4.255.255.1, static metric [1/0]
Mar 1 01:25:34.575: RT: NET-RED 4.0.0.0/9

7-show-ip-route

Posted in Static Routing | Leave a Comment »

Static Routing – differences between specifying an exit interface, an IP address, and both

Posted by Andy on April 5, 2009

In this post we will look at some of the differences between configuring static routes with an exit interface, an IP address, and both an exit interface and an IP address.  The topology and initial configurations are shown below:

static-routing-topology

R1:
ipv6 unicast-routing
!
interface FastEthernet0/0
 mac-address 0000.0000.0001
 ip address 10.0.13.1 255.255.255.0
 ipv6 address 2001:DB8:0:13::1/64
 ipv6 address FE80::1 link-local
!
interface Serial0/0
 ip address 10.0.12.1 255.255.255.0
 ipv6 address 2001:DB8:0:12::1/64
 ipv6 address FE80::1 link-local

R2:
ipv6 unicast-routing
!
interface Serial0/0
 ip address 10.0.12.2 255.255.255.0
 ipv6 address 2001:DB8:0:12::2/64
 ipv6 address FE80::2 link-local
!
interface Serial0/1
 ip address 10.0.23.2 255.255.255.0
 ipv6 address 2001:DB8:0:23::2/64
 ipv6 address FE80::2 link-local

R3:
ipv6 unicast-routing
!
interface FastEthernet0/0
 mac-address 0000.0000.0003
 ip address 10.0.13.3 255.255.255.0
 ipv6 address 2001:DB8:0:13::3/64
 ipv6 address FE80::3 link-local
!
interface Serial0/0
 ip address 10.0.23.3 255.255.255.0
 ipv6 address 2001:DB8:0:23::3/64
 ipv6 address FE80::3 link-local
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.0
 ipv6 address 2001:DB8:0:3::3/64
 ipv6 address FE80::3 link-local

First we will configure a static route to R3’s loopback on R1 by specifying an outgoing interface:

R1:
ip route 3.3.3.0 255.255.255.0 FastEthernet0/0
ipv6 route 2001:DB8:0:3::/64 FastEthernet0/0

R1#debug ip routing
R1#debug ipv6 routing

Mar 1 00:08:07.339: RT: SET_LAST_RDB for 3.3.3.0/24
NEW rdb: is directly connected

Mar 1 00:08:07.343: RT: add 3.3.3.0/24 via 0.0.0.0, static metric [1/0]
Mar 1 00:08:07.343: RT: NET-RED 3.3.3.0/24

Mar 1 00:08:55.963: IPv6RT0: static, Route add 2001:DB8:0:3::/64 [new]
Mar 1 00:08:55.963: IPv6RT0: static, Add 2001:DB8:0:3::/64 to table
Mar 1 00:08:55.967: IPv6RT0: static, Adding next-hop :: over FastEthernet0/0 for 2001:DB8:0:3::/64, [1/0]
Mar 1 00:08:55.967: IPv6RT0: Event: 2001:DB8:0:3::/64, Add, owner static, previous None

The IPv4 route shows up in the routing table as directly connected to F0/0:

1-r1-show-ip-route

Some sources say that the default AD for IPv4 static routes with only an exit interface specified is 0, but as shown below the AD is 1, so this may have been changed at some point in IOS:

1-r1-show-ip-route-3

The IPv6 route is listed in the routing table as pointing to an unspecified address with an exit interface of F0/0:

1-r1-show-ipv6-route

IPv4 static routes configured with only an exit interface on a broadcast network rely on proxy-ARP to determine the next hop.  If we attempt to send traffic to 5 different addresses on the 3.3.3.0/24 subnet, R1 sends an ARP for each of them and R3 replies using proxy-ARP:

R1#ping 3.3.3.1
R1#ping 3.3.3.2
R1#ping 3.3.3.3
R1#ping 3.3.3.4
R1#ping 3.3.3.5

1-r1-show-arp

This could result in a large amount of broadcast traffic and a large ARP cache on R1, especially if the static route was a default route used for internet traffic.

IPv6 uses NDP for address resolution, which does not have a similar function to proxy-ARP for answering requests on behalf of other nodes.  Therefore, R3 does not reply to neighbor solicitations sent by R1 for addresses on the 2001:db8:0:3::/64 subnet.  Even if the NS is for 2001:db8:0:3::3 (R3’s loopback address), R3 does not send an NA because NDP messages are link-local in scope and the NS arrives on the wrong interface:

R1#ping 2001:db8:0:3::3
. . . . .

If we add a static neighbor cache entry on R1 for the address, R1 does not need to send an NS to determine the layer-2 address and R3’s loopback is now reachable:

R1:
ipv6 neighbor 2001:DB8:0:3::3 FastEthernet0/0 0000.0000.0003

1-r1-show-neighbor

R1#ping 2001:db8:0:3::3
!!!!!

Obviously this is not scalable as it would require a static neighbor cache entry using R3’s layer-2 address for every IPv6 address that could potentially be reached by the static route on R1.

If F0/0 goes down on R1, both static routes are removed from the routing table:

R1:
interface FastEthernet0/0
 shutdown

Mar 1 00:25:01.907: IPv6RT0: connected, Delete 2001:DB8:0:13::1/128 from table
Mar 1 00:25:01.911: IPv6RT0: connected, Delete 2001:DB8:0:13::/64 from table
Mar 1 00:25:01.915: IPv6RT0: static, Delete 2001:DB8:0:3::/64 from table
Mar 1 00:25:01.919: RT: is_up: FastEthernet0/0 0 state: 6 sub state: 1 line: 1 has_route: True
Mar 1 00:25:01.923: RT: interface FastEthernet0/0 removed from routing table
Mar 1 00:25:01.923: RT: del 10.0.13.0/24 via 0.0.0.0, connected metric [0/0]
Mar 1 00:25:01.923: RT: delete subnet route to 10.0.13.0/24
Mar 1 00:25:01.927: RT: NET-RED 10.0.13.0/24
Mar 1 00:25:01.927: RT: Pruning routes for FastEthernet0/0 (1)
Mar 1 00:25:01.959: RT: delete route to 3.3.3.0 via 0.0.0.0, FastEthernet0/0
Mar 1 00:25:01.959: RT: no routes to 3.3.3.0, flushing
Mar 1 00:25:01.959: RT: NET-RED 3.3.3.0/24
Mar 1 00:25:01.963: RT: delete network route to 3.0.0.0
Mar 1 00:25:01.963: RT: NET-RED 3.0.0.0/8
Mar 1 00:25:01.967: IPv6RT0: Event: 2001:DB8:0:13::1/128, Del, owner connected, previous None
Mar 1 00:25:01.967: IPv6RT0: Event: 2001:DB8:0:13::/64, Del, owner connected, previous None
Mar 1 00:25:01.967: IPv6RT0: Event: 2001:DB8:0:3::/64, Del, owner static, previous None

2-r1-show-ip-route

2-r1-show-ipv6-route

 

Next we will change the static route statements to use a next-hop address instead of an exit interface:

R1:
interface FastEthernet0/0
 no shutdown
!
no ip route 3.3.3.0 255.255.255.0 FastEthernet0/0
no ipv6 route 2001:DB8:0:3::/64 FastEthernet0/0
ip route 3.3.3.0 255.255.255.0 10.0.13.3
ipv6 route 2001:DB8:0:3::/64 2001:DB8:0:13::3

The IPv4 and IPv6 routes are both listed in the routing table with a next-hop address only.  In order to find the outgoing interface, a recursive lookup is performed on the next-hop address:

3-r1-show-ip-route

3-r1-show-ipv6-route1

If we send traffic to 5 different addresses on the 3.3.3.0/24 subnet again, R3 only needs to send an ARP request for the first one to determine the layer-2 address for the specified next-hop, 10.0.13.3:

R1#ping 3.3.3.1
R1#ping 3.3.3.2
R1#ping 3.3.3.3
R1#ping 3.3.3.4
R1#ping 3.3.3.5

3-r1-show-arp

Likewise, if we send traffic to 5 different addresses on the 2001:db8:0:3::/64 subnet, R1 only needs to determine the L2 address for the specified next-hop, 2001:db8:0:3::3:

R1#ping 2001:db8:0:3::1
R1#ping 2001:db8:0:3::2
R1#ping 2001:db8:0:3::3
R1#ping 2001:db8:0:3::4
R1#ping 2001:db8:0:3::5

3-r1-show-neighbor

The static routes remain in the routing table as long as the next-hop can be resolved to a valid route in the routing table.  In this case, if F0/0 goes down on R1, the directly connected routes to 10.0.13.0/24 and 2001:db8:0:13::/64 are removed.  Since these are the only routes that can be used to resolve the next hop addresses, the static routes are also removed:

R1:
interface FastEthernet0/0
 shutdown

4-r1-show-ip-route2

4-r1-show-ipv6-route4

However, consider what would happen instead if RIP were being used on the 2 serial links and the fast ethernet link.  We will enable RIP and RIPng for each of these links on each router:

R1:
router rip
 network 10.0.0.0
!
ipv6 router rip test
!
interface FastEthernet0/0
 ipv6 rip test enable
!
interface Serial0/0
 ipv6 rip test enable

R2:
router rip
 network 10.0.0.0
!
ipv6 router rip test
!
interface Serial0/0
 ipv6 rip test enable
!
interface Serial0/1
 ipv6 rip test enable

R3:
router rip
 network 10.0.0.0
!
ipv6 router rip test
!
interface FastEthernet0/0
 ipv6 rip test enable
!
interface Serial0/0
 ipv6 rip test enable

Now we will shut down R1’s F0/0 again:

R1:
interface FastEthernet0/0
 shutdown

R1 deletes the routing table entries for 3.3.3.0/24 and 2001:db8:0:3::/64 like before:

R1#debug ip routing
R1#debug ipv6 routing

Mar 1 01:02:07.947: IPv6RT0: connected, Delete 2001:DB8:0:13::1/128 from table
Mar 1 01:02:07.951: IPv6RT0: static, Route add 2001:DB8:0:3::/64 [owner]
Mar 1 01:02:07.951: IPv6RT0: connected, Delete 2001:DB8:0:13::/64 from table
Mar 1 01:02:07.951: IPv6RT0: rip test, Backup call for 2001:DB8:0:13::/64
Mar 1 01:02:07.955: IPv6RT0: rip test, Route add 2001:DB8:0:13::/64 [new]
Mar 1 01:02:07.955: IPv6RT0: rip test, Add 2001:DB8:0:13::/64 to table
Mar 1 01:02:07.955: IPv6RT0: rip test, Adding next-hop FE80::3 over FastEthernet0/0 for 2001:DB8:0:13::/64, [120/2]
Mar 1 01:02:07.963: IPv6RT0: rip test, Delete 2001:DB8:0:13::/64 from table
Mar 1 01:02:07.963: IPv6RT0: Delete next-hop FE80::3/FastEthernet0/0 for 2001:DB8:0:23::/64
Mar 1 01:02:07.963: IPv6RT0: static, Delete 2001:DB8:0:3::/64 from table
Mar 1 01:02:07.971: RT: is_up: FastEthernet0/0 0 state: 6 sub state: 1 line: 1 has_route: True
Mar 1 01:02:07.971: RT: del 10.0.23.0/24 via 10.0.13.3, rip metric [120/1]
Mar 1 01:02:07.975: RT: NET-RED 10.0.23.0/24
Mar 1 01:02:07.975: RT: interface FastEthernet0/0 removed from routing table
Mar 1 01:02:07.975: RT: del 10.0.13.0/24 via 0.0.0.0, connected metric [0/0]
Mar 1 01:02:07.979: RT: delete subnet route to 10.0.13.0/24
Mar 1 01:02:07.979: RT: NET-RED 10.0.13.0/24
Mar 1 01:02:07.983: IPv6RT0: Event: 2001:DB8:0:13::1/128, Del, owner connected, previous None
Mar 1 01:02:07.983: IPv6RT0: Event: 2001:DB8:0:13::/64, Del, owner connected, previous None
Mar 1 01:02:07.983: IPv6RT0: Event: 2001:DB8:0:23::/64, Path, owner rip, previous None
Mar 1 01:02:07.987: IPv6RT0: Event: 2001:DB8:0:3::/64, Del, owner static, previous None
Mar 1 01:02:08.607: %SYS-5-CONFIG_I: Configured from console by console
Mar 1 01:02:08.979: RT: del 3.3.3.0/24 via 10.0.13.3, static metric [1/0]
Mar 1 01:02:08.979: RT: delete subnet route to 3.3.3.0/24
Mar 1 01:02:08.983: RT: NET-RED 3.3.3.0/24
Mar 1 01:02:08.983: RT: delete network route to 3.0.0.0
Mar 1 01:02:08.983: RT: NET-RED 3.0.0.0/8
Mar 1 01:02:09.943: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
Mar 1 01:02:09.947: RT: is_up: FastEthernet0/0 0 state: 6 sub state: 1 line: 1 has_route: False
Mar 1 01:02:10.943: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
Mar 1 01:02:10.947: RT: is_up: FastEthernet0/0 0 state: 6 sub state: 1 line: 1 has_route: False

A few seconds later, R1 receives a RIPng update from R2 which includes a route to 2001:db8:0:13::/64 from R3. R1 also receives a RIP update from R2 which includes a route to 10.0.13.0/24 that was learned from R3. R1 adds these routes to it’s routing table:


Mar 1 01:02:19.919: IPv6RT0: rip test, Route add 2001:DB8:0:13::/64 [new]
Mar 1 01:02:19.919: IPv6RT0: rip test, Add 2001:DB8:0:13::/64 to table
Mar 1 01:02:19.919: IPv6RT0: rip test, Adding next-hop FE80::2 over Serial0/0 for 2001:DB8:0:13::/64, [120/3]
Mar 1 01:02:19.919: IPv6RT0: Event: 2001:DB8:0:13::/64, Add, owner rip, previous None

Mar 1 01:02:24.587: RT: SET_LAST_RDB for 10.0.13.0/24
NEW rdb: via 10.0.12.2

Mar 1 01:02:24.591: RT: add 10.0.13.0/24 via 10.0.12.2, rip metric [120/2]
Mar 1 01:02:24.591: RT: NET-RED 10.0.13.0/24

A few seconds later, R1 realizes that it now has a valid route to the next hop for each of it’s static routes and adds both routes to the routing table:

Mar 1 01:02:56.135: RT: SET_LAST_RDB for 3.3.3.0/24
NEW rdb: via 10.0.13.3

Mar 1 01:02:56.135: RT: add 3.3.3.0/24 via 10.0.13.3, static metric [1/0]
Mar 1 01:02:56.139: RT: NET-RED 3.3.3.0/24

Mar 1 01:03:00.223: IPv6RT0: static, Route add 2001:DB8:0:3::/64 [new]
Mar 1 01:03:00.223: IPv6RT0: static, Add 2001:DB8:0:3::/64 to table
Mar 1 01:03:00.223: IPv6RT0: static, Adding next-hop 2001:DB8:0:13::3 over Null for 2001:DB8:0:3::/64, [1/0]
Mar 1 01:03:00.227: IPv6RT0: Event: 2001:DB8:0:3::/64, Add, owner static, previous None

5-r1-show-ip-route

5-r1-show-ipv6-route1

R2 does not have a route to 3.3.3.0/24 or 2001:db8:0:3::/64 so traffic to these subnets from R1 will fail.  Even if R2 did have a route, it may be undesirable for these routes to be installed on R1 in the event that F0/0 on R1 goes down because traffic must traverse 2 slow serial links to reach it’s destination.  Another example of a situation that could occur is if R1 had a default route pointing out of a different interface to an ISP and F0/0 went down, the next-hop for the static route would resolve to the default route and R1 would keep the static routes in the routing table and send traffic destined for R3’s subnet out the interface connected to the ISP.

 

By specifying both an exit interface and a next-hop address, this behavior can be changed.  We will remove both static routes on R1 and add new static routes specifying both:

R1:
interface FastEthernet0/0
 no shutdown
!
no ip route 3.3.3.0 255.255.255.0 10.0.13.3
no ipv6 route 2001:DB8:0:3::/64 2001:DB8:0:13::3
ip route 3.3.3.0 255.255.255.0 FastEthernet0/0 10.0.13.3
ipv6 route 2001:DB8:0:3::/64 FastEthernet0/0 2001:DB8:0:13::3

The IPv4 and IPv6 static routes are listed in the routing table with both their outgoing interface and next-hop address:

6-r1-show-ip-route

6-r1-show-ipv6-route1

Using this method avoids the problems that we saw occur when specifying only the exit interface on a broadcast network.  It also will only keep the static routes in the routing table if the exit interface is up (which may or may not be desirable, depending on the situation).  If we shutdown F0/0 on R1 again, R1 learns the routes to 10.0.13.0/24 and 2001:db8:0:13::/64 again via RIP and RIPng.  However, R1 does not install the static routes even though their next-hop addresses resolve to known routes because F0/0 is down:

R1:
interface FastEthernet0/0
 shutdown

7-r1-show-ip-route

7-r1-show-ipv6-route

Having reachability to the next-hop address does not actually have anything to do with the static routes being installed or not when both an exit interface and an IP address are used.  We will bring F0/0 back up on R1 and then change the static routes to use a next-hop that is known out of a different interface:

R1:
interface FastEthernet0/0
 no shutdown
!
no ip route 3.3.3.0 255.255.255.0 FastEthernet0/0 10.0.13.3
no ipv6 route 2001:DB8:0:3::/64 FastEthernet0/0 2001:DB8:0:13::3
ip route 3.3.3.0 255.255.255.0 FastEthernet0/0 10.0.12.2
ipv6 route 2001:DB8:0:3::/64 FastEthernet0/0 2001:DB8:0:12::2

The IP address in the static route statements points to a directly connected network known out of S0/0.  Nevertheless, both routes are installed in the routing table and traffic matching the route will use F0/0:

8-r1-show-ip-route

8-r1-show-ipv6-route

Even if the next-hop is an address for which R1 has no matching route, the static route is still installed in the routing table:

R1:
no ip route 3.3.3.0 255.255.255.0 FastEthernet0/0 10.0.12.2
no ipv6 route 2001:DB8:0:3::/64 FastEthernet0/0 2001:DB8:0:12::2
ip route 3.3.3.0 255.255.255.0 FastEthernet0/0 5.5.5.5
ipv6 route 2001:DB8:0:3::/64 FastEthernet0/0 5555:5555:5555:5555::5

9-r1-show-ip-route

9-r1-show-ipv6-route

Traffic to these static routes will fail since R1 attempts to use ARP/NDP to perform address resolution on the invalid next-hop address out of the configured exit interface, but if the exit interface were instead a point-to-point interface, the configuration would work even though the next-hop address is incorrect.

Posted in IPv6, Static Routing | Leave a Comment »