RIP Reliable Default Route with IP SLA

RIP is a fairly simple protocol, and most CCIE 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:

rip reliable default route topology

The topology above is simple enough. Three routers are 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
R2(config)#router rip
R2(config-router)#version 2
R2(config-router)#no auto-summary 

The 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-echo)#timeout 100
R2(config-ip-sla-echo)#frequency 1
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

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

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

R2(config)#ip route null0 track 1

Above is where the magic happens. I created a static route for /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 ip sla 1

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

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 791 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

1636 Sign Ups in the last 30 days

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!


Forum Replies

  1. Hi Rene,

    Very useful topic , many thanks for this.

    Question 1

    with this command “ip route null0 track 1”, do you mean that we have created static route for R1 via "default-information originate " command, due to reaching ip from R2.

    when R2 can not reach R3 , “R2#default-information originate route-map TRACK_LINK” is autmatically removed and there is no default route for R1.

    Question 2

    when R1 state is like below,

    R1#show ip route rip
    R* [120/1] via, 00:00:12, FastEthernet0/0

    Schould R3 be also like

    ... Continue reading in our forum

  2. Hi Onur,

    1. We need a "dummy" route, something that is in the routing table but it doesn't matter what it is or where it points to. In that case, it's best to point it to the null interface. I've added object tracking to this dummy router, it doesn't have anything to do with the default-information originate command (which is for the default route). When IP SLA fails, this dummy route will be removed from the routing table. The default route will disappear because the dummy route is now gone.
    2. That's right, R3 will also learn the default route from R2.


    Hello Rene,

    In this topology I, am tracking which is hosted on R5 using a track 1 on R1 which is being called in Standby 1 to decrement priority by 90.

    when i am running a continous ping to from PC1, Serial interfaces on all the routers in the path starts flapping.

    Even when i run a ping to Serial interface of R3 from PC1, Both R1 and R3 starts flapping.

    I tried to change the bandwidth of the serial interfaces but no it was of no help.

    I have attached router logs of R1 and R2 along with the config, Please have

    ... Continue reading in our forum

  4. Hi Shivam,

    I see you are using GNS3.

    GNS3 works very well to test different topologies/protocols but it doesn’t do a good job when you are actually trying to send traffic through your virtual routers. It’s possible that this is causing your links to flap.

    Changing the bandwidth doesn’t do anything btw, this is just a “cosmetic” change that we can use to influence (routing) protocols.


  5. Rene my confusion is with the DUMMY_PREFIX. Why are you pointing a non-existing subnet to null0 and that creates a default route to R3.
    Do not we need a route pointing to and that will advertised as the default route towards R1 when we use the default information originate command in R2?

    How R2 knows the default gateway is R3?



10 more replies! Ask a question or join the discussion by visiting our Community Forum