This topic is to discuss the following lesson:
Very useful topic , many thanks for this.
with this command “ip route 184.108.40.206 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,
R1#show ip route rip R* 0.0.0.0/0 [120/1] via 192.168.12.2, 00:00:12, FastEthernet0/0
Schould R3 be also like below
R3 state is also like below.
R3#show ip route rip R* 0.0.0.0/0 [120/1] via 192.168.23.2, 00:00:12, FastEthernet0/0
Am i right?
- 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.
- That's right, R3 will also learn the default route from R2.
In this topology I, am tracking 220.127.116.11 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 18.104.22.168 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 a look to findout what’s going wrong. Thanks
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 22.214.171.124 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?
The problem is that we can only “attach” the default route to a route-map. We need something to match in the route-map so that’s why I picked a dummy prefix. We put this dummy route in the routing table and attach object tracking to it.
We then attach IP SLA to object tracking.
When IP SLA fails, the object tracking fails and the dummy prefix is removed from the routing table.
This triggers the route-map and the default route is no longer advertised anymore…
In this example, R2 is only advertising a default route. That doesn’t mean automatically that it knows a default route itself. If you want to use R3 for all unknown traffic then yes, you should add a default route towards R3. In this example I only explained how to advertise a default route in combination with IP SLA.
As per configuration, We have created a IP SLA instance and track a dummy static route with this instance. When ping not responded for the ip 192.168.12.2 then the dummy ip route will no longer in routing table.My questins is how or In which logic the Route-map will kick in and default route will not advertise when dummy ip route will no longer in routing table.Could you please clarify the step by step logic , how its working ??
The route-map has the following match rule:
match ip address prefix-list DUMMY_PREFIX
And it is attached under the RIP process so it is actively monitored.
what if i created the dummy with the below command
R2(conf t )#ip route 0000.0000 192.168.23.3 track 1
will that be fine ?
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/interface
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
null0 interface as the next hop interface so no accidental unintentional routing takes place. Also, the
null0 interface will guarantee that the route will be entered into the routing table.
I hope this has been helpful!
Hi Rene, rather than using the null interface here, would using the static route
_ip route 192.168.23.3 255.255.255.255 F0/1 track 1_
work the same?
As mentioned in the previous post, the routing entry that you suggest…
I hope this has been helpful!
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 1 and ip sla schedule 1 should be the same or not?
R2(config-router)# default-information originate route-map TRACK_LINK
in the RIP default route configuration we just require the default-information originate command to advertise default route in RIP why do we need route-map?
And the last thing i should write is that RIP Reliable Default Route with IP SLA totally confused me if possible simlify it to me.
thanks in advance.
Its because of simplicity that tracking object provides, its either UP or it is DOWN.
It may be confusing, but “track 1 rtr 1” and “track 1 ip sla 1” are both doing exactly same thing. It is linking track up/down status with sla results. “rtr” is old configuration command, Cisco just renamed it to “ip sla” making it more intuitive.
Yes, you are correct. “ip sla schedule #” is referecing to what ever number you configured in “ip sla #”.
After we create ip sla, we also have to schedule when system has to start executing this sla. In this actual example system is going to start sla right after you hit enter and sla is going to be active forever.
When you are originating default route you can use two additional keywords, “always” or “route-map”. In case you use “always” then default route is going to be originated always. In case you use “route-map” then default route is going to be originated only if it is permitted by route-map, in other words only if the route referenced in route-map is in routing table. In this specific example is referenced route 126.96.36.199/24 .
Thanks Michal now it is clear.