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

RIP Summarization & Null0 Routes

Here's oddity I came across today with RIP.

This scenario is simple enough I'm not even going to bother creating a diagram.

Take two routers, connect two Ethernet interfaces from each router to the other router.
In our scenario, we'll use:
R1: Fa0/0 192.168.0.1  ->  R2 Fa0/0 192.168.0.2
R2: Fa0/1 10.0.0.1        ->  R2 Fa0/1 10.0.0.2

OER/PfR Configuration [Part 2 of 2]

We'll be picking up right where we left off in part 1, transitioning our topology from dynamips 7200s to dynamips 3725s.  The 7200s had too many issues running BGP under dynamips, and also had many bugs with OER's interoperability with BGP.  We'll also be using OER v2.1 (12.4(15)T) instead of OER v2.2 (12.4(24)T) for this section.

Our new topology looks very similar to the old, but note that the interface numbers have all changed:

 

OER/PfR Configuration [Part 1 of 2]

In this two-part document, I will cover my OER/PFR labbing experience, covering static routing, BGP (inbound and outbound), PBR, including all the things that stumped me for any length of time.

This document assumes a basic level understanding of what function OER and PfR is intended to accomplish.  If you’d like an introduction, I highly recommend the first hour of Brian Dennis’ PfR video at http://www.ine.com/all-access-pass/training/playlist/ccie-rs-pfr-vseminar/-pfr--vseminar-22200011.html.

I will be covering only the features in 12.4T.  I understand that PfR is much more mature in IOS 15, however, my first goal is to clarify this topic for CCIE studies, and 12.4T is the version presently on the CCIE R&S.

This is the topology I will be referencing for this document: