RIP is a fairly simple protocol and most CCIE R&S students don’t worry about it too much. There are however a number of ‘pitfalls’ that you need to be aware of. One of them is configuring RIP to advertise a default route in combination with IP SLA and object tracking. I will show you how to do this with the following three routers:

The topology above is simple enough. Three routers connected to each other and we will configure RIP on R1 and R2. The idea is to advertise a default route on R2 towards R1 but only when it can reach the IP address of R3. Let’s start by enabling RIP on R1 and R2:

R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#network 192.168.12.0

R2(config)#router rip
R2(config-router)#version 2
R2(config-router)#no auto-summary 
R2(config-router)#network 192.168.12.0

Next step is to enable IP SLA on R2 so that it will ping the IP address of R3:

R2(config)#ip sla 1
R2(config-ip-sla)#icmp-echo 192.168.23.3 
R2(config-ip-sla-echo)#timeout 100
R2(config-ip-sla-echo)#frequency 1
R2(config-ip-sla-echo)#exit
R2(config)#ip sla schedule 1 start-time now life forever

We will use IP SLA to ping R3 and make it run forever. Just to be sure we’ll verify that it is working:

R2#show ip sla statistics 

Round Trip Time (RTT) for	Index 1
	Latest RTT: 24 milliseconds
Latest operation start time: *00:17:09.647 UTC Fri Mar 1 2002
Latest operation return code: OK
Number of successes: 87
Number of failures: 0
Operation time to live: Forever

IP SLA is working as it should. We are receiving replies to our ping requests. Now let’s see if we can configure that default route for RIP on R2:

R2(config-router)#default-information originate ?
  route-map  Route-map reference
  <cr>

The only option we have is to use a route-map in combination with our default route. Let’s use a route-map:

R2(config-router)#default-information originate route-map TRACK_LINK

I’ll use a route-map called TRACK_LINK. Now we’ll take a look at the options for our route-map:

R2(config-route-map)#match ?
  as-path           Match BGP AS path list
  clns              CLNS information
  community         Match BGP community list
  extcommunity      Match BGP/VPN extended community list
  interface         Match first hop interface of route
  ip                IP specific information
  ipv6              IPv6 specific information
  length            Packet length
  local-preference  Local preference for route
  metric            Match metric of route
  mpls-label        Match routes which have MPLS labels
  nlri              BGP NLRI type
  policy-list       Match IP policy list
  route-type        Match route-type of route
  source-protocol   Match source-protocol of route
  tag               Match tag of route

I can’t match my route-map directly to IP SLA so we’ll have to be creative here. Think about IP SLA for a moment…we can tie it to a static route using object tracking. We will create a match statement here that matches a certain prefix, and for this prefix we will create a static route that is tracked by IP SLA. It doesn’t matter what prefix we use as long as it is in the routing table:

R2(config-route-map)#match ip address prefix-list DUMMY_PREFIX

I will call the prefix-list DUMMY_PREFIX. Let’s create that prefix-list:

R2(config)#ip prefix-list DUMMY_PREFIX permit 11.11.11.0/24

I will use prefix 11.11.11.0 /24. This prefix is not in use for this topology…now we will create a static route for this prefix:

R2(config)#ip route 11.11.11.0 255.255.255.0 null0 track 1

Above is where the magic happens. I created a static route for 11.11.11.0 /24 and I’ll point it to the null0 interface to get it in the routing table. The track 1 keyword enables object tracking. Whenever object 1 fails we will remove this static route from the routing table. Let’s link object 1 to IP SLA 1:

R2(config)#track 1 rtr 1

This will link object 1 to IP SLA 1. Whenever our ping to R3 fails, the static route that we just created will be removed from the routing table. Let’s verify our work here: