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:
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 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
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)#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 184.108.40.206/24
I will use prefix 220.127.116.11 /24. This prefix is not in use for this topology…now we will create a static route for this prefix:
R2(config)#ip route 18.104.22.168 255.255.255.0 null0 track 1
Above is where the magic happens. I created a static route for 22.214.171.124 /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:
Very useful topic , many thanks for this.
with this command “ip route 126.96.36.199 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.
when R1 state is like below,
Schould R3 be also like... Continue reading in our forum
In this topology I, am tracking 188.8.131.52 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 184.108.40.206 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
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.
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 0.0.0.0/0 route pointing to 220.127.116.11 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?