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 ip sla 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:
Hi Rene,
Very useful topic , many thanks for this.
Question 1
with this command “ip route 11.11.11.0 255.255.255.0 null0 track 1”, do you mean that we have created static route for R1 via "default-information originate " command, due to reaching ip 192.168.23.3 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,
Schould R3 be also like
... Continue reading in our forumHi Onur,
Hello Manuel.
The dummy route that you indicated above will not work for two reasons. First the route must be in the format:
ip route
network-address subnet-mask Next-Hop-address/interfacetrack1
I believe you meant the following:
ip route 0.0.0.0 0.0.0.0 192.168.23.3 track 1
If this is the case, then this would not work either, because 0.0.0.0 0.0.0.0 is a legitimate route and would affect your routing. You must use a network address that does not exist in your topology. Also, it is always safer to use the
... Continue reading in our forumnull0
interface as the next hop interface so no accHello Anthony
As mentioned in the previous post, the routing entry that you suggest…
I hope this has been helpful!
Laz
Hi Lazaros,
Would you please explain the following:
we can’t connect IP SLA directly with static route, we have to do it with object tracking:
R1(config)# track 1 rtr 1
.This will link object 1 with IP SLA 1
R2(config)# track 1 ip sla 1
My confusion is, in the above commands in R1 track 1 represents IP SLA and rtr represents object tracking if I am right.
But in R2 track 1 represents object tracking and ip sla as its name implies represents ip sla1.
R1(config)# ip sla schedule 1 start-time now life forever
In the command above the ip sla operation number