Routing Protocols

Mock Lab 6 Analysis – RIP Summary Address and Default Routes

I ran into this strange problem while doing Mock Lab 6, and I thought it warranted an article because it highlights why the order of operations that IOS performs certain tasks is important.

Let’s say you have this scenario:

R4 is a border router between two routing domains, OSPF and RIPv2. We are doing mutual redistribution between OSPF and RIPv2. Simple enough.

R4:

router ospf 1
 version 2
 router-id 150.1.4.4
 log-adjacency-changes
 redistribute rip subnets
 network 150.1.4.4 0.0.0.0 area 0
 network 176.1.45.4 0.0.0.0 area 45
 network 176.1.145.4 0.0.0.0 area 0
!
router rip
 version 2
 redistribute ospf 1 metric 1
 passive-interface default
 no passive-interface Ethernet0/0.46
 network 176.1.0.0
 no auto-summary

Let’s have a look at the route table of both R4 and R6 to verify that we have connectivity

R4:

R4#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     54.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
R       54.1.7.0/24 [120/1] via 176.1.46.6, 00:00:01, Ethernet0/0.46
R       54.1.7.254/32 [120/1] via 176.1.46.6, 00:00:01, Ethernet0/0.46
R    212.18.1.0/24 [120/2] via 176.1.46.6, 00:00:01, Ethernet0/0.46
R    212.18.0.0/24 [120/2] via 176.1.46.6, 00:00:01, Ethernet0/0.46
R    212.18.3.0/24 [120/2] via 176.1.46.6, 00:00:01, Ethernet0/0.46
     176.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
C       176.1.145.0/24 is directly connected, Serial1/0
C       176.1.45.5/32 is directly connected, Serial1/1
C       176.1.45.0/24 is directly connected, Serial1/1
C       176.1.46.0/24 is directly connected, Ethernet0/0.46
C       176.1.4.0/24 is directly connected, Ethernet0/0.4
R    212.18.2.0/24 [120/2] via 176.1.46.6, 00:00:03, Ethernet0/0.46
     150.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
C       150.1.4.0/24 is directly connected, Loopback0
O       150.1.5.5/32 [110/782] via 176.1.145.5, 00:00:04, Serial1/0
O       150.1.1.1/32 [110/782] via 176.1.145.1, 00:00:04, Serial1/0

R6:

R6#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     54.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       54.1.7.0/24 is directly connected, Loopback1
C       54.1.7.254/32 is directly connected, Virtual-Access1
R    212.18.1.0/24 [120/1] via 54.1.7.254, 00:00:01, Virtual-Access1
R    212.18.0.0/24 [120/1] via 54.1.7.254, 00:00:01, Virtual-Access1
R    212.18.3.0/24 [120/1] via 54.1.7.254, 00:00:01, Virtual-Access1
     176.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
R       176.1.145.0/24 [120/1] via 176.1.46.4, 00:00:05, Ethernet0/0
R       176.1.45.5/32 [120/1] via 176.1.46.4, 00:00:05, Ethernet0/0
R       176.1.45.0/24 [120/1] via 176.1.46.4, 00:00:05, Ethernet0/0
C       176.1.46.0/24 is directly connected, Ethernet0/0
R       176.1.4.0/24 [120/1] via 176.1.46.4, 00:00:05, Ethernet0/0
R    212.18.2.0/24 [120/1] via 54.1.7.254, 00:00:02, Virtual-Access1
     150.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
C       150.1.6.0/24 is directly connected, Loopback0
R       150.1.4.0/24 [120/1] via 176.1.46.4, 00:00:06, Ethernet0/0
R       150.1.5.5/32 [120/1] via 176.1.46.4, 00:00:06, Ethernet0/0
R       150.1.1.1/32 [120/1] via 176.1.46.4, 00:00:06, Ethernet0/0

The routing table looks good, and it looks like all routes from OSPF on R4 are being passed into RIP and are seen by R6. We should now have connectivity from R4 to BB1 (54.1.7.254).

R4#ping 54.1.7.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 54.1.7.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/48/52 ms

Let’s do some summarization. We want to summarize at the 176.1.0.0/16 and 150.1.0.0/16 network boundaries on R4 before we send them to R6.

R4:

interface Ethernet0/0.46
 encapsulation dot1Q 46
 ip address 176.1.46.4 255.255.255.0
 ip summary-address rip 176.1.0.0 255.255.0.0
 ip summary-address rip 150.1.0.0 255.255.0.0

R6:

R6#clear ip route *
R6#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     54.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       54.1.7.0/24 is directly connected, Loopback1
C       54.1.7.254/32 is directly connected, Virtual-Access1
R    212.18.1.0/24 [120/1] via 54.1.7.254, 00:00:01, Virtual-Access1
R    212.18.0.0/24 [120/1] via 54.1.7.254, 00:00:01, Virtual-Access1
R    212.18.3.0/24 [120/1] via 54.1.7.254, 00:00:01, Virtual-Access1
     176.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       176.1.46.0/24 is directly connected, Ethernet0/0
R       176.1.0.0/16 [120/1] via 176.1.46.4, 00:00:02, Ethernet0/0
R    212.18.2.0/24 [120/1] via 54.1.7.254, 00:00:00, Virtual-Access1
     150.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       150.1.6.0/24 is directly connected, Loopback0
R       150.1.0.0/16 [120/2] via 176.1.46.4, 00:00:02, Ethernet0/0

You can see above that the routes have been summarized correctly on R6. This summarization will in turn be passed onto BB1 and connectivity from R4 will be maintained because of this.

So far so good. Okay now for the fun part. R6’s only connection to the rest of the network is via R4. Let’s send a default-route to R6 from R4. But this isn’t an ordinary default route. We want to make sure that R6 doesn’t pass on that default-route it learns from R4 onto BB1. BB1 should still get the 176.1.0.0/16 and 150.1.0.0/16 summaries though. Sounds simple. Oh and we can only do the configuration on R4 (Evil mock lab writers!).

Let’s try this:

R4:

router rip
 default-information originate route-map DEFAULT
!
route-map DEFAULT permit 10
 set metric 15
!

On R4, we are generating a default route with a route-map attached. The route-map forces a metric of 15 on the default route. This way when R6 gets it, it should have a metric of 15. RIP’s maximum metric is 16 so when BB1, gets this route it will be marked as invalid (ie not accept the route).

Let’s verify this on R6:

R6#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 176.1.46.4 to network 0.0.0.0

     54.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       54.1.7.0/24 is directly connected, Loopback1
C       54.1.7.254/32 is directly connected, Virtual-Access1
R    212.18.1.0/24 [120/1] via 54.1.7.254, 00:00:10, Virtual-Access1
R    212.18.0.0/24 [120/1] via 54.1.7.254, 00:00:10, Virtual-Access1
R    212.18.3.0/24 [120/1] via 54.1.7.254, 00:00:10, Virtual-Access1
     176.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       176.1.46.0/24 is directly connected, Ethernet0/0
R       176.1.0.0/16 [120/15] via 176.1.46.4, 00:00:13, Ethernet0/0
R    212.18.2.0/24 [120/1] via 54.1.7.254, 00:00:11, Virtual-Access1
     150.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       150.1.6.0/24 is directly connected, Loopback0
R       150.1.0.0/16 [120/15] via 176.1.46.4, 00:00:13, Ethernet0/0
R*   0.0.0.0/0 [120/15] via 176.1.46.4, 00:00:15, Ethernet0/0

R6#debug ip rip
RIP protocol debugging is on
R6#cle
5d20h: RIP: received v2 update from 176.1.46.4 on Ethernet0/0
5d20h:      0.0.0.0/0 via 0.0.0.0 in 15 hops
5d20h:      150.1.0.0/16 via 0.0.0.0 in 15 hops
5d20h:      176.1.0.0/16 via 0.0.0.0 in 15 hops
5d20h: RIP: sending v2 flash update to 224.0.0.9 via Virtual-Access1 (54.1.7.6)
5d20h: RIP: build flash update entries
5d20h:  0.0.0.0/0 via 0.0.0.0, metric 16, tag 0
5d20h:  54.1.7.0/24 via 0.0.0.0, metric 1, tag 0
5d20h:  150.1.0.0/16 via 0.0.0.0, metric 16, tag 0
5d20h:  176.1.0.0/16 via 0.0.0.0, metric 16, tag 0
5d20h:  176.1.46.0/24 via 0.0.0.0, metric 1, tag 0

Looks like we got the default route with a metric of 15, and we are sending it on the BB1 with a metric of 16. Looks great, but take a look closer.

The Mock Lab 6 solution guide, presents the answer above. Now, I don’t really like this solution because check out the metrics for the 176.1.0.0/16 and the 150.1.0.0/16 routes. They are 15 on R6 as well! Why? Well think about how rip chooses a metric when it summarizes a route. The Cisco documentation states “RIPv2 route summarization requires that the lowest metric of the “best route” of an aggregated entry, or the lowest metric of all current child routes, be advertised. The best metric for aggregated summarized routes is calculated at route initialization or when there are metric modifications of specific routes at advertisement time, and not at the time the aggregated routes are advertised.”

So when RIPv2 summarizes a route, it choses the lowest metric of all the routes that it is summarizing and then advertises that as the metric. So why do we have the 176.1.0.0/16 and 150.1.0.0/16 networks advertised as 15? Well, what I think is happening is for some crazy reason IOS considers the 0.0.0.0/0 route a child of these summaries, so they get its metric. Crazy! I don’t think that should happen, but okay. When I change the metric on the default route, these summaries will get that as well. The only reason I can think of for this is because the default route is generated first, then the summary-addresses are calculated.

So how do we fix this? Well let’s try this:

R4:

router rip
 default-information originate
 offset-list DEFAULT out 14 Ethernet0/0.46
!
ip access-list standard DEFAULT
 permit 0.0.0.0

We’ve changed the default-information originate to one with a route-map and then we’ve applied an offset-list to change the metric to 14 of that default route. “Hang on a sec Arden, didn’t you just say that whatever you change the default route metric it will change the summary route metric as well?”. Let’s take a look at R4:

R4#debug ip rip
RIP protocol debugging is on
R4#clear ip route *
5d20h: RIP: sending v2 flash update to 224.0.0.9 via Ethernet0/0.46 (176.1.46.4)
5d20h: RIP: build flash update entries
5d20h:  0.0.0.0/0 via 0.0.0.0, metric 15, tag 0
5d20h:  150.1.0.0/16 via 0.0.0.0, metric 2, tag 0
5d20h:  176.1.0.0/16 via 0.0.0.0, metric 1, tag 0

Well take a look at that! Only the 0.0.0.0/0 route (default) has the offset-list applied. Makes sense. We had our access list only choose the default. But if you think about this, this must also mean that the offset-list is applied AFTER the summaries are generated. There is very little difference in the logic of either solutions, only this one works! We are setting a metric on both of the solutions, but the offset-list sets the metric AFTER the summaries.

So, IOS will generate the default route, summarize the routes, then apply the offset list. I haven’t been able to find documentation that supports this theory (the closest I could find was Tassos’s post but it mentions nothing on order), but it is the only explanation I could come up with.

Brian Dennis from Internetwork highlighted some of the other order of operations that IOS takes when performing certain tasks (QoS Order of Operations, IOS Egress and Ingress Order of Operations, BGP Order of Preference), but I can’t find any references for order with regards to this problem. Anybody else experience something similar, or know of any good order of operations references with regards to this?

Update: This seems to be a bug in the 12.2 IOS. I am able to reproduce this on the home lab, but it does not appear in the 12.4 series of IOS. Thanks to Jared Scrivener for pointing that out!

© 2008 Arden Packeer. All rights reserved. The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway. This material is not sponsored or endorsed by Cisco Systems, Inc. Cisco, Cisco Systems, CCIE and the CCIE Logo are trademarks of Cisco Systems, Inc. and its affiliates