09-25-2009 07:45 AM - edited 03-01-2019 04:25 PM
Let's take a look at how we can change our default route using IP SLA.
First we create our IP SLA. In this example we want to ping our default gateway of our primary internet connection. In the above diagram that would relate to 11.b.c.d.
ip sla monitor 10
type echo protocol ipIcmpEcho 11.b.c.d
timeout 1000
frequency 3
threshold 2
ip sla monitor schedule 1 life forever start-time now
Next we create a tracked object. This one points to the reachability of the IP SLA. Note that the number 10 relates to the ip sla monitor number.
track 10 rtr 1 reachability
Next we create an ACL. This permits ICMP to our default gateway. This is used in our route map to determine the reachability.
ip access-list 101 permit icmp any host 11.b.c.d echo
Next we create our route map. We macth on the ACL we just created, then set the next hop as the preferred provider IP (11.b.c.d). You must set the interface to null0.
route-map DEFAULT-ROUTE-POLICY permit 10
match ip address 101
set ip next-hop 11.b.c.d
set interface null 0
Next we create a local routing policy to use our newly created route map.
ip local policy route-map DEFAULT-ROUTE-POLICY
Finally we put in our default routes. The first default route points to our preferred provide and we append the tracking to it. We then add the second default route with a higher weight (floating static route). What this does for us is the router will track the preffered default route. If for some reason we lose connectivity (from the IPS SLA) the route will be removed and any secondary default route will be added. In this example the new default route will point to 10.136.5.200
ip route 0.0.0.0 0.0.0.0 11.b.c.d track 10
ip route 0.0.0.0 0.0.0.0 192.168.4.5 200
Let's take a look at see what happens when we fail over. First let's check IP SLA and make sure it's working.
Router#show ip sla statistics
Round Trip Time (RTT) for Index 10
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *19:41:46.411 UTC Sun Jul 14 2002
Latest operation return code: Timeout
Number of successes: 233
Number of failures: 0
Operation time to live: Forever
Great, that's working. Now let's check the routing table.
Router#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 11.b.c.d to network 0.0.0.0
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.2.0 is directly connected, Vlan1
S* 0.0.0.0/0 [1/0] via 11.b.c.d
Looks good there. Let's take a look at the tracking.
Router#show ip route track-table
ip route 0.0.0.0 0.0.0.0 11.b.c.d track 10 state is [up]
Everything is working when the preferred provider is up. From a client lets do a trace route so we know what way where we're going.
Now let's take that circuit down and see if it properly fails over.
*Jul 14 19:47:05.327: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0, changed state to down
*Jul 14 19:47:05.327: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
*Jul 14 19:47:06.331: %LINK-3-UPDOWN: Interface FastEthernet0, changed state to down
*Jul 14 19:47:06.363: %TRACKING-5-STATE: 10 rtr 1 reachability Up->Down
Router#
Let's take a look at the tracking state.
Router#show ip route track-table
ip route 0.0.0.0 0.0.0.0 11.b.c.d track 10 state is [down]
Router#
Finally let's check the routing table.
Router#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 192.168.4.5 to network 0.0.0.0
C 192.168.4.5.0/24 is directly connected, Vlan2
S* 0.0.0.0/0 [254/0] via 192.168.4.5
Router#
Lets try another trace route from the client.
Everything is working! Let's check to make sure when the preferred provider come back on line that we go back to routing out that way.
*Jul 14 19:54:03.395: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
*Jul 14 19:54:04.387: %LINK-3-UPDOWN: Interface FastEthernet0, changed state to up
*Jul 14 19:54:05.387: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0, changed state to up
Router#
Router#
*Jul 14 19:54:41.367: %TRACKING-5-STATE: 10 rtr 1 reachability Down->Up
Router#show ip route track-table
ip route 0.0.0.0 0.0.0.0 11.b.c.d track 10 state is [up]
Router#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 11.b.c.d to network 0.0.0.0
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.2.0 is directly connected, Vlan1
S* 0.0.0.0/0 [1/0] via 11.b.c.d
Router#
It failed back correctly. A final test from the client workstation and we're good to go.
URL Reference: http://www.cisco.com/en/US/docs/ios/dial/configuration/guide/dia_rel_stc_rtg_bckup_ps6350_TSD_Products_Configuration_Guide_Chapter.html
**Thanks for the corrections J.B.**
Should the command
ip sla monitor schedule 1 life forever start-time now
actually be
ip sla monitor schedule 10 life forever start-time now
since we are trying to reference
ip sla monitor 10
type echo protocol ipIcmpEcho 11.b.c.d
timeout 1000
frequency 3
threshold 2
Yes it should be. Good catch.
is it possible to use the IPSLA command with the SF300 switch ?
Are the access list, route map, and local policy necessary for this to work?
I don't believe so.
I would like to test this in a virtual lab environment first, but in Cisco Packet Tracer Student 6.1 when I type ip sla it says invalid input detected at '^' marker. (pointed at sla).
ip ? shows oinly these commands on a virtual 2811 router.
access-list Named access-list
cef Cisco Express Forwarding
default-gateway Specify default gateway (if not routing IP)
default-network Flags networks as candidates for default routes
dhcp Configure DHCP server and relay parameters
domain IP DNS Resolver
domain-lookup Enable IP Domain Name System hostname translation
domain-name Define the default domain name
flow-export Specify host/port to send flow statistics
forward-protocol Controls forwarding of physical and directed IP broadcasts
ftp FTP configuration commands
host Add an entry to the ip hostname table
inspect Context-based Access Control Engine
ips Intrusion Prevention System
local Specify local options
name-server Specify address of name server to use
nat NAT configuration commands
route Establish static routes
routing Enable IP routing
ssh Configure ssh options
tcp Global TCP parameters
So how am I supposed to learn and practice this without taking down the production network? I would try GS3 but they don't emulate 2811 routers, and that's what I have so my cisco account will not let me download any other ios router version.
Cisco Packet Tracer is very limited in functionality, so it's not surprising that it doesn't support IP SLA commands. IP SLA is a CCNP concept, Packet Tracer is for CCNA students.
The commands are slightly different in different versions of IOS. For example on the Catalyst 3750 that I implemented this on the following isn't recognized:
ip sla monitor 10
Instead, I had to use:
ip sla 10
The differences are minor, but they are there. For learning purposes I would try to use GNS3 with whatever version of IOS you can get your hands on.
Yes.
The local policy ensures that the router-generated Ipsla pings are sent to 11.b.c.d using a next-hop of 11.b.c.d.
Otherwise, the router would choose the current default route (192.168.4.5) as the next hop for 11.b.c.d. In this case the ping might succeed, causing the track to come up (incorrectly). This would inevitably lead to route flapping.
The local policy and route map are essential to this setup, quite clever really.
Hey,
I have same routing issue, but I can't find what will be your next-hop for the second static route.
I will appreciate if you can look to my routing issue:
https://supportforums.cisco.com/discussion/13184431/routing-issue
Hey,
Your explanation got me curious and yes you are right, the route-map and policy routing ensures that the ping tests are sent directly to 11.b.c.d. I was curious what the local policy command was for, but for those who doesn't know (like me a few hours ago), this command is necessary for the solution above since the icmp echo packets are generated by the router itself.
An alternative solution that I thought of would be to specify the source interface for the ip sla command.
ip sla 1
icmp-echo 11.b.c.d source-interface Serial0/0/0;
then the ip policy routing (local policy & route-map) wouldn't be necessary (i guess) since the ping tests will always come out of the correct interface. :D
Please advise the tweak for failing over to backup link and NOT to failback without manual intervention.
so in other words, the essence of this local policy and route-map is basically saying "mr router, when you generate any icmp echo, don't send it to anywhere but to 11.b.c.d".
Also, arvyleandro, I dont think this type of router would allow you to configure "ip sla 1" with adding the monitor. As in "ip sla monitor 1"
so in other words, the essence of this local policy and route-map is basically saying "mr router, when you generate any icmp echo, don't send it to anywhere but to 11.b.c.d".
Yes. Because the ICMP echo is generated locally, this traffic is not forwarded by router policies. So you need the local policy to ensure that router generated traffic is forwarded to the right IP.
http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c/qcfpbr.html#wp1001002
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: