Hello Pavan
This command uses a particular syntax depending on the IOS version you are using. Take a look at this NtworkLessons note on the topic of IP SLA tracking syntax for more information.
If you have further questions, please let us know!
I hope this has been helpful!
Laz
New command instead of track 1 rtr 1 seems to be -
track 1 ip sla 1 reachability
Hello David
You are correct. The syntax used in the lesson refers to IOS versions before 12.2(33). Take a look at this NetworkLessons note on the syntax used for tracking IP SLAs for more info.
I hope this has been helpful!
Laz
Hello, everyone!
If we have an object tracker that tracks the IP SLA operation state applied to the primary default static route, if the IP SLA operation fails, the default route is uninstalled due to the state of that object going down.
My question is, what if there is a server on the internet, like 5.5.5.5/32 that I want the icmp-echo operation to verify connectivity to? If operation fails and the primary route is uninstalled, the backup default route is installed, the IP SLA operation will go back up because connectivity will be restored which will reinstall the primary default static route only for it to go down again.
Iâve heard that we can fix this by creating a specific static route pointing towards the destination on the primary link. This would effectively prevent route flapping as the backup path would never be used to reach the 5.5.5.5 destination due to most specific prefix length routing.
My question is though, does this mean that this destination will be completely unreachable until the primary default route is reinstalled? Because if the primary path has connectivity problems, the primary default route will go down and the specific state route is still pointing over the primary link, if a packet destined to 5.5.5.5 was sent, wouldnât it go to a possible dead end?
Also, what is the difference between these two?
When would I want to use one over another?
Thatâs all, thank you!
Hello David
Yes, you are correct, creating a specific static route for 5.5.5.5/32 over the primary link will prevent route flapping. However, if the primary path does have connectivity problems, the traffic to 5.5.5.5 will indeed hit a dead end as the specific static route is still pointing over the primary link, even though the SLA will reroute all the rest of the traffic over the secondary link.
There are a couple of solutions to this. The first is to use a destination for your IPSLA that isnât mission critical. For example, if you want to be able to reach a server with an IP address of 5.5.5.5, use the IP address of another device on the same subnet, say, the default gateway of that server (i.e. 5.5.5.6, or some other address on the same subnet). This presupposes that you can get that information somehow, but you can probably find some auxiliary IP address that you can use for that purpose. So if you lose connectivity to, say, 5.5.5.6, your IP SLA will kick in, but you will still be able to reach 5.5.5.5 via the secondary link.
Another solution is to use Policy Based routing (PBR). PBR can be used to change the next hop IP address for traffic matching certain criteria, thus overruling your routing table. You can have your IP SLA test always go over the primary link, and if that fails have the IP SLA kick in. But all your other traffic, using PBR, will be able to reach the intended destination via the secondary link.
Concerning the difference between the reachability and state keywords for the track command, this Cisco command reference documentation clarifies this quite nicely. Essentially, the difference has to do with whether or not the response to the echo request comes before or after the set threshold. Take a look at the documentation and if you have any more questions, let us know!
I hope this has been helpful!
Laz