RIP Default Information Originate w/ Route-Map

I found an unexpected circumstance with RIP's default-information originate command, when using route-maps.

Here is the reference diagram:

....where X is the router number.

All interfaces are up, RIPv2 is setup to advertise network 0.0.0.0.  Auto-summary is disabled.

I'd like to inject a default from R1 to R3.  This can be accomplished with this configuration:

route-map just_fa01 permit 10
 set interface FastEthernet0/1

router rip
 default-information originate route-map just_fa01

No issues thus far, this technically works:

R3#sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "rip", distance 120, metric 1, candidate default path
  Redistributing via rip
  Last update from 192.168.13.1 on FastEthernet0/0, 00:00:00 ago
  Routing Descriptor Blocks:
  * 192.168.13.1, from 192.168.13.1, 00:00:00 ago, via FastEthernet0/0
      Route metric is 1, traffic share count is 1

R2#sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "rip", distance 120, metric 2, candidate default path
  Redistributing via rip
  Last update from 192.168.23.3 on FastEthernet0/1, 00:00:00 ago
  Routing Descriptor Blocks:
  * 192.168.23.3, from 192.168.23.3, 00:00:00 ago, via FastEthernet0/1
      Route metric is 5, traffic share count is 1

Notice R2 learns the route from R3, as we'd expect.

Of course, the problem is, this gets advertised from R1 -> R3, R3 -> R2, and then R2 back to R1. This is because there's no split horizon happening at R2, because we didn't advertise the route to R2, and R2 has no idea it came from R1.  R1 will actually take it's own default, and this loops around the next work until a hop count of 16 occurs ("counting to infinity").  Then the route is pulled, and a new one is introduced, and the problem starts all over again.

You can see the counting to infinity problem quite easily on any of the routers:

R3#
*Mar  1 00:58:23.807: RT: rip's 0.0.0.0/0 (via 192.168.13.1) metric changed from distance/metric [120/1] to [120/4]
R3#
*Mar  1 00:58:29.891: RT: rip's 0.0.0.0/0 (via 192.168.13.1) metric changed from distance/metric [120/4] to [120/7]
R3#
*Mar  1 00:58:35.971: RT: rip's 0.0.0.0/0 (via 192.168.13.1) metric changed from distance/metric [120/7] to [120/10]
I've described a solution to this problem in another blog post here:
http://brbccie.blogspot.com/2012/10/rip-summarization-null0-routes.html

My answer is to add a static route to null0 for the summarization.  In this case, the summarization is to a default route.  So let's add one and see what happens:

R1(config)#ip route 0.0.0.0 0.0.0.0 null0

The counting to infinity stops:

R3#
*Mar  1 01:00:37.427: RT: add 0.0.0.0/0 via 192.168.13.1, rip metric [120/1]
*Mar  1 01:00:37.431: RT: NET-RED 0.0.0.0/0
*Mar  1 01:00:37.431: RT: default path is now 0.0.0.0 via 192.168.13.1
*Mar  1 01:00:37.431: RT: new default network 0.0.0.0
*Mar  1 01:00:37.435: RT: NET-RED 0.0.0.0/0
*Mar  1 01:01:08.007: RT: NET-RED 0.0.0.0/0
*Mar  1 01:02:08.007: RT: NET-RED 0.0.0.0/0

We have the appropriate route on R3:

R3#sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "rip", distance 120, metric 1, candidate default path
  Redistributing via rip
  Last update from 192.168.13.1 on FastEthernet0/0, 00:00:00 ago
  Routing Descriptor Blocks:
  * 192.168.13.1, from 192.168.13.1, 00:00:00 ago, via FastEthernet0/0
      Route metric is 1, traffic share count is 1

We have the default on R2, but... hold the phone!:

R2#sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "rip", distance 120, metric 1, candidate default path
  Redistributing via rip
  Last update from 192.168.12.1 on FastEthernet0/0, 00:00:07 ago
  Routing Descriptor Blocks:
  * 192.168.12.1, from 192.168.12.1, 00:00:07 ago, via FastEthernet0/0
      Route metric is 1, traffic share count is 1

R2 learned that route from R1!  We were expecting it via R3, as before, because R1 has a route-map telling it not to advertise a default towards R2.

The intent of using a route-map with default-information originate is to use either "match ip address", to check for the existence of a specific route as a condition of originating a default, and "set interface", for the reasons we've shown above.  Commonly these two are used together --- match route X, then send a default out interface Y.

My hypothesis for this issue, although I cannot find any reference to this in the Cisco documentation, is because a default is statically created on the originating router, the route-map we apply is deliberately ignored.  I believe the thought process in the router is "why should I check for the existence of a specific route when I clearly have a default in my routing table?".  Without consulting the route-map, it has no idea about the set interface command, and therefore sends the default to all neighbors.

I welcome comments on this!   Does anyone have a documented or more specific reason as to why this is happening?

Jeff Kronlage