RIP and RIPng Metrics

In this post we will look at a few things relating to metric calculations in RIPv2 and RIPng.  The topology and configurations are shown below.  All interfaces on all routers run RIPv2 with no auto-summary and RIPng:

R1:
ipv6 unicast-routing
!
interface Loopback1
 ip address 1.1.1.1 255.255.255.0
 ipv6 address 2001:0:0:1111::1/64
 ipv6 rip asdf enable
!
interface Serial0/0
 ip address 10.0.12.1 255.255.255.0
 ipv6 address 2001:12::1/64
 ipv6 rip asdf enable
!
router rip
 version 2
 passive-interface default
 no passive-interface Serial0/0
 network 1.0.0.0
 network 10.0.0.0
 no auto-summary
!
ipv6 router rip asdf


R2:
ipv6 unicast-routing
!
interface Loopback1
 ip address 2.2.2.2 255.255.255.0
 ipv6 address 2001:0:0:2222::2/64
 ipv6 rip asdf enable
!
interface Serial0/0
 ip address 10.0.12.2 255.255.255.0
 ipv6 address 2001:12::2/64
 ipv6 rip asdf enable
!
interface Serial0/1
 ip address 10.0.23.2 255.255.255.0
 ipv6 address 2001:23::2/64
 ipv6 rip asdf enable
!
router rip
 version 2
 passive-interface Loopback1
 network 2.0.0.0
 network 10.0.0.0
 no auto-summary
!
ipv6 router rip asdf


R3:
ipv6 unicast-routing
!
interface Loopback1
 ip address 3.3.3.3 255.255.255.0
 ipv6 address 2001:0:0:3333::3/64
 ipv6 rip asdf enable
!
interface Serial0/0
 ip address 10.0.23.3 255.255.255.0
 ipv6 address 2001:23::3/64
 ipv6 rip asdf enable
!
interface Serial0/1
 ip address 10.0.34.3 255.255.255.0
 ipv6 address 2001:34::3/64
 ipv6 rip asdf enable
!
router rip
 version 2
 passive-interface Loopback1
 network 3.0.0.0
 network 10.0.0.0
 no auto-summary
!
ipv6 router rip asdf


R4:
ipv6 unicast-routing
!
interface Loopback1
 ip address 4.4.4.4 255.255.255.0
 ipv6 address 2001:0:0:4444::4/64
 ipv6 rip asdf enable
!
interface Serial0/0
 ip address 10.0.34.4 255.255.255.0
 ipv6 address 2001:34::4/64
 ipv6 rip asdf enable
!
router rip
 version 2
 network 4.0.0.0
 network 10.0.0.0
 no auto-summary
!
ipv6 router rip asdf


The routing tables of each router look like this:

Notice that the RIPng routes are listed as 1 hop higher than the equivalent RIPv2 routes.  For example, R2 sees R1’s loopback as 1 hop in RIPv2 and 2 hops in RIPng.  Let’s take a look at the RIPv2 and RIPng updates on R2 being received from R1 and sent to R3:

R2#debug ip rip
Mar 1 00:46:36.895: RIP: received v2 update from 10.0.12.1 on Serial0/0
Mar 1 00:46:36.895: 1.1.1.0/24 via 0.0.0.0 in 1 hops
Mar 1 00:46:40.167: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 00:46:40.167: RIP: build update entries
Mar 1 00:46:40.167: 1.1.1.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 00:46:40.171: 2.2.2.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 00:46:40.171: 10.0.12.0/24 via 0.0.0.0, metric 1, tag 0


R2#debug ipv6 rip
Mar 1 00:46:55.487: RIPng: response received from FE80::C601:9FF:FEFC:0 on Serial0/0 for asdf
Mar 1 00:46:55.487: src=FE80::C601:9FF:FEFC:0 (Serial0/0)
Mar 1 00:46:55.491: dst=FF02::9
Mar 1 00:46:55.491: sport=521, dport=521, length=52
Mar 1 00:46:55.491: command=2, version=1, mbz=0, #rte=2
Mar 1 00:46:55.491: tag=0, metric=1, prefix=2001:0:0:1111::/64
Mar 1 00:46:55.491: tag=0, metric=1, prefix=2001:12::/64
Mar 1 00:47:14.139: RIPng: Sending multicast update on Serial0/1 for asdf
Mar 1 00:47:14.139: src=FE80::C602:9FF:FEFC:0
Mar 1 00:47:14.139: dst=FF02::9 (Serial0/1)
Mar 1 00:47:14.143: sport=521, dport=521, length=92
Mar 1 00:47:14.143: command=2, version=1, mbz=0, #rte=4
Mar 1 00:47:14.143: tag=0, metric=1, prefix=2001:12::/64
Mar 1 00:47:14.143: tag=0, metric=1, prefix=2001:23::/64
Mar 1 00:47:14.143: tag=0, metric=1, prefix=2001:0:0:2222::/64
Mar 1 00:47:14.147: tag=0, metric=2, prefix=2001:0:0:1111::/64


Both updates look the same – R1’s loopback is received from R1 as metric 1 and advertised to R3 as metric 2.  The reason for the difference in metric in the routing table and RIP database is that RIPng metrics are incremented inbound before being added to the routing table/RIP database, while RIPv1 and RIPv2 metrics are incremented outbound.  Equivalent RIPng routes will always show up as 1 hop higher than RIPv2 routes if no offsets are applied.

 

Next we will look at a bug that is present in many IOS versions that results in RIPv1 and RIPv2 hop counts not incrementing.  We will turn RIPv2 auto-summary back on for R3 and R4:

R3:
router rip
 auto-summary


R4:
router rip
auto-summary


R3 stops advertising 1.1.1.0/24 and 2.2.2.0/24 and starts advertising 1.0.0.0/8 and 2.0.0.0/8 to R4.  After R4’s flush timer expires for the /24 routes, it’s routing table now looks like this:

1.0.0.0/8 has the same metric as the old /24 route, but 2.0.0.0/8 is listed as metric 1 instead of metric 2.  Let’s take a look at sent and received updates in the direction of R1 to R4.  R3 receives the same routes and metrics from R2:

R3#debug ip rip
Mar 1 01:01:37.891: RIP: received v2 update from 10.0.23.2 on Serial0/0
Mar 1 01:01:37.891: 1.1.1.0/24 via 0.0.0.0 in 2 hops
Mar 1 01:01:37.895: 2.2.2.0/24 via 0.0.0.0 in 1 hops
Mar 1 01:01:37.895: 10.0.12.0/24 via 0.0.0.0 in 1 hops


When the summarized routes are advertised to R4, 1.0.0.0/8 is incremented but 2.0.0.0/8 is advertised as metric 1, the same metric it was received as:

R3#debug ip rip
Mar 1 01:01:41.647: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (10.0.34.3)
Mar 1 01:01:41.647: RIP: build update entries
Mar 1 01:01:41.647: 1.0.0.0/8 via 0.0.0.0, metric 3, tag 0
Mar 1 01:01:41.651: 2.0.0.0/8 via 0.0.0.0, metric 1, tag 0
Mar 1 01:01:41.651: 3.0.0.0/8 via 0.0.0.0, metric 1, tag 0
Mar 1 01:01:41.651: 10.0.12.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 01:01:41.651: 10.0.23.0/24 via 0.0.0.0, metric 1, tag 0


R4 receives the update from R3:

R4#debug ip rip
Mar 1 01:01:41.679: RIP: received v2 update from 10.0.34.3 on Serial0/0
Mar 1 01:01:41.679: 1.0.0.0/8 via 0.0.0.0 in 3 hops
Mar 1 01:01:41.683: 2.0.0.0/8 via 0.0.0.0 in 1 hops
Mar 1 01:01:41.683: 3.0.0.0/8 via 0.0.0.0 in 1 hops
Mar 1 01:01:41.683: 10.0.12.0/24 via 0.0.0.0 in 2 hops
Mar 1 01:01:41.687: 10.0.23.0/24 via 0.0.0.0 in 1 hops


When R4 sends an update out loopback1, 1.0.0.0/8 is again incremented and 2.0.0.0/8 is not.  3.0.0.0/8, which was received as metric 1, is also not incremented:

R4#debug ip rip
Mar 1 01:01:56.191: RIP: sending v2 update to 224.0.0.9 via Loopback1 (4.4.4.4)
Mar 1 01:01:56.191: RIP: build update entries
Mar 1 01:01:56.191: 1.0.0.0/8 via 0.0.0.0, metric 4, tag 0
Mar 1 01:01:56.195: 2.0.0.0/8 via 0.0.0.0, metric 1, tag 0
Mar 1 01:01:56.195: 3.0.0.0/8 via 0.0.0.0, metric 1, tag 0
Mar 1 01:01:56.195: 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0


This bug, which prevents the hop count from incrementing, occurs whenever a received route has metric 1 and is summarized before being advertised.  If the received metric is greater than 1, the hop count continues to increment like normal.  This occurs for RIPv1 routes when they are summarized at classful boundaries, RIPv2 auto-summary routes, and RIPv2 interface summary routes.  The bug occurred in various 12.4 mainline IOS versions that were tested and no longer occurred in 12.4(20)T, so it appears to have been fixed in some 12.4 T-train release.

 

Summary routes in both RIPv2 and RIPng use the lowest metric of any child route within their range as the metric for the summary route.  To demonstrate this, we will first create a few more loopbacks on R1 and redistribute them into RIP with various metrics.  We will also turn auto-summary off again on R3 and R4:

R1:
router rip
 no network 1.0.0.0
!
interface Loopback1
 no ipv6 rip asdf enable
!
interface Loopback2
 ip address 1.1.2.1 255.255.255.0
 ipv6 address 2001:0:0:1112::1/64
!
interface Loopback3
 ip address 1.1.3.1 255.255.255.0
 ipv6 address 2001:0:0:1113::1/64
!
interface Loopback4
 ip address 1.1.4.1 255.255.255.0
 ipv6 address 2001:0:0:1114::1/64
!
ip access-list standard Loop1
 permit 1.1.1.0
ip access-list standard Loop2
 permit 1.1.2.0
ip access-list standard Loop3
 permit 1.1.3.0
ip access-list standard Loop4
 permit 1.1.4.0
!
route-map RIPv2 permit 10
 match ip address Loop1
 set metric 3
!
route-map RIPv2 permit 20
 match ip address Loop2
 set metric 4
!
route-map RIPv2 permit 30
 match ip address Loop3
 set metric 5
!
route-map RIPv2 permit 40
 match ip address Loop4
 set metric 6
!
router rip
 redistribute connected route-map RIPv2
!
ipv6 prefix-list Loop1 seq 5 permit 2001:0:0:1111::/64
!
ipv6 prefix-list Loop2 seq 5 permit 2001:0:0:1112::/64
!
ipv6 prefix-list Loop3 seq 5 permit 2001:0:0:1113::/64
!
ipv6 prefix-list Loop4 seq 5 permit 2001:0:0:1114::/64
!
route-map RIPng permit 10
match ipv6 address prefix-list Loop1
set metric 3
!
route-map RIPng permit 20
match ipv6 address prefix-list Loop2
set metric 4
!
route-map RIPng permit 30
match ipv6 address prefix-list Loop3
set metric 5
!
route-map RIPng permit 40
match ipv6 address prefix-list Loop4
set metric 6
!
ipv6 router rip asdf
 redistribute connected route-map RIPng


R3:
router rip
 no auto-summary


R4:
router rip
 no auto-summary


Before creating the summary routes, let’s verify that the redistributed routes have the correct metrics:

R1#debug ip rip
Mar 1 01:33:23.859: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.0.12.1)
Mar 1 01:33:23.859: RIP: build update entries
Mar 1 01:33:23.859: 1.1.1.0/24 via 0.0.0.0, metric 3, tag 0
Mar 1 01:33:23.863: 1.1.2.0/24 via 0.0.0.0, metric 4, tag 0
Mar 1 01:33:23.863: 1.1.3.0/24 via 0.0.0.0, metric 5, tag 0
Mar 1 01:33:23.863: 1.1.4.0/24 via 0.0.0.0, metric 6, tag 0


R1#debug ipv6 rip
Mar 1 01:33:54.007: RIPng: Sending multicast update on Serial0/0 for asdf
Mar 1 01:33:54.007: src=FE80::C601:9FF:FEFC:0
Mar 1 01:33:54.011: dst=FF02::9 (Serial0/0)
Mar 1 01:33:54.011: sport=521, dport=521, length=112
Mar 1 01:33:54.011: command=2, version=1, mbz=0, #rte=5
Mar 1 01:33:54.011: tag=0, metric=3, prefix=2001:0:0:1111::/64
Mar 1 01:33:54.011: tag=0, metric=1, prefix=2001:12::/64
Mar 1 01:33:54.015: tag=0, metric=4, prefix=2001:0:0:1112::/64
Mar 1 01:33:54.015: tag=0, metric=5, prefix=2001:0:0:1113::/64
Mar 1 01:33:54.015: tag=0, metric=6, prefix=2001:0:0:1114::/64


Now we will create the summary routes:

R1:
interface Serial0/0
 ip summary-address rip 1.1.0.0 255.255.248.0
 ipv6 rip asdf summary-address 2001:0:0:1110::/60


Let’s check how the summaries are being advertised on R1:

R1#debug ip rip
Mar 1 01:33:11.163: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.0.12.1)
Mar 1 01:33:11.163: RIP: build update entries
Mar 1 01:33:11.163: 1.1.0.0/21 via 0.0.0.0, metric 4, tag 0


R1#debug ipv6 rip
Mar 1 01:33:43.747: RIPng: Sending multicast update on Serial0/0 for asdf
Mar 1 01:33:43.747: src=FE80::C601:9FF:FEFC:0
Mar 1 01:33:43.751: dst=FF02::9 (Serial0/0)
Mar 1 01:33:43.751: sport=521, dport=521, length=52
Mar 1 01:33:43.751: command=2, version=1, mbz=0, #rte=2
Mar 1 01:33:43.751: tag=0, metric=1, prefix=2001:12::/64
Mar 1 01:33:43.751: tag=0, metric=3, prefix=2001:0:0:1110::/60


RIPng used the lowest child metric (3) as the metric for the summary route.  RIPv2, however, gave it a metric of 4.  This relates to another possible bug, where routes redistributed into RIPv2 that are manually summarized have an additional hop added to the metric.  Some additional info can be found here.  Let’s try putting the RIPv2 summary on R2 instead and see if this goes away:

R1:
interface Serial0/0
 no ip summary-address rip 1.1.0.0 255.255.248.0


R2#debug ip rip
Mar 1 01:46:25.751: RIP: received v2 update from 10.0.12.1 on Serial0/0
Mar 1 01:46:25.755: 1.1.1.0/24 via 0.0.0.0 in 3 hops
Mar 1 01:46:25.755: 1.1.2.0/24 via 0.0.0.0 in 4 hops
Mar 1 01:46:25.755: 1.1.3.0/24 via 0.0.0.0 in 5 hops
Mar 1 01:46:25.755: 1.1.4.0/24 via 0.0.0.0 in 6 hops
Mar 1 01:46:47.503: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 01:46:47.503: RIP: build update entries
Mar 1 01:46:47.503: 1.1.1.0/24 via 0.0.0.0, metric 4, tag 0
Mar 1 01:46:47.507: 1.1.2.0/24 via 0.0.0.0, metric 5, tag 0
Mar 1 01:46:47.507: 1.1.3.0/24 via 0.0.0.0, metric 6, tag 0
Mar 1 01:46:47.507: 1.1.4.0/24 via 0.0.0.0, metric 7, tag 0
Mar 1 01:46:47.507: 2.2.2.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 01:46:47.511: 10.0.12.0/24 via 0.0.0.0, metric 1, tag 0


R2:
interface Serial0/1
 ip summary-address rip 1.1.0.0 255.255.248.0


R2#debug ip rip
Mar 1 01:47:41.935: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 01:47:41.935: RIP: build update entries
Mar 1 01:47:41.935: 1.1.0.0/21 via 0.0.0.0, metric 4, tag 0
Mar 1 01:47:41.939: 2.2.2.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 01:47:41.939: 10.0.12.0/24 via 0.0.0.0, metric 1, tag 0


R2 now correctly uses the lowest child metric as the metric for the summary.

 

 

As mentioned earlier, the bug where routes received with a hop count of 1 are not incremented applies to manual summary routes also.  If any child route has a metric of 1 the summary route metric will not be incremented.  To demonstrate this we will change the seed metric of R1 Loopback1 to 1:

R1:
route-map RIPv2 permit 10
 match ip address Loop1
 set metric 1


R2#debug ip rip
Mar 1 02:02:15.843: RIP: received v2 update from 10.0.12.1 on Serial0/0
Mar 1 02:02:15.843: 1.1.1.0/24 via 0.0.0.0 in 1 hops
Mar 1 02:02:15.847: 1.1.2.0/24 via 0.0.0.0 in 4 hops
Mar 1 02:02:15.847: 1.1.3.0/24 via 0.0.0.0 in 5 hops
Mar 1 02:02:15.847: 1.1.4.0/24 via 0.0.0.0 in 6 hops
Mar 1 02:02:27.599: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (10.0.23.2)
Mar 1 02:02:27.599: RIP: build update entries
Mar 1 02:02:27.599: 1.1.0.0/21 via 0.0.0.0, metric 1, tag 0
Mar 1 02:02:27.603: 2.2.2.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 02:02:27.603: 10.0.12.0/24 via 0.0.0.0, metric 1, tag 0


The advertised metric remains at 1.