cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
46534
Views
84
Helpful
18
Replies
LondonCisco
Beginner

Is it possible in IOS to have two static routes for the same subnet, one a higher priority and "failover" between the 2?

Hi All

Is it possible in IOS to have for a particular subnet:

a) Two static routes?

b) Make one static route a higher priority than the other?

c) If one static router "goes down", failover to the lower priority static route?

We have a l2tp/vpdn connection to a supplier which can be accessed via two vlans/routes. I would like to make one route the preferred one but the "route" to failover if the preferred route goes down.

Again, many thanks in advance for all responses!

Thanks

John

2 ACCEPTED SOLUTIONS

Accepted Solutions

LondonCisco wrote:

Hi Reza

That looks like what I would want to know.

Out of interest, do you know or know of a link that explains what circumstances causes a router to "drop a static route"? It is not clear from the articles I have found up to konw.

Thanks

John

A static toute configured in a Cisco will disappear from the routing table if the interface it's connecting via is down or not connected.

So if you have

ip route 192.168.0.0 255.255.255.0 172.16.1.2

And an interface configured as 172.16.1.1/30 which is UP, the route to 192.168.0.0 will exist in your routing table.

If the interface 172.16.1.1 is down (either physically or administratively), the route to 192.168.0.0 will be removed from the routing table.

So if you've got a flapping link or something which is causing the interface your route is going "out" to go up and down, the route would appear, then disappear, then re-appear depending on the state of the link.

Cheers.

View solution in original post

Hi John,

Hope the below explaination will help you...

R1(config)# ip route 0.0.0.0 0.0.0.0 2.2.2.2

R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 10

If you notice the Administrative Distance for the secondary route pointing to ISP2 is increased to 10 so that it becomes the backup link.

The above configuration with just two floating static routes partially accomplishes our requirement as it will work only in the scenario where the routers interfaces connected to the WAN link are in up/down or down/down status. But in a lot of situations we see that even though the links remain up but we are not able to reach the gateway, this usually happens when the issue is at the ISP side.

In such scenarios, IP SLAs becomes an engineer's best friend. With around six additional IOS commands we can have a more reliable automatic failover environment.

Using IP SLA the Cisco IOS gets the ability to use Internet Control Message Protocol (ICMP) pings to identify when a WAN link goes down at the remote end and hence allows the initiation of a backup connection from an alternative port. The Reliable Static Routing Backup using Object Tracking feature can ensure reliable backup in the case of several catastrophic events, such as Internet circuit failure or peer device failure.

IP SLA is configured to ping a target, such as a publicly routable IP address or a target inside the corporate network or your next-hop IP on the ISP's router. The pings are routed from the primary interface only. Following a sample configuration of IP SLA to generate icmp ping targeted at the ISP1s next-hop IP.

R1(config)# ip sla 1

R1(config)# icmp-echo 2.2.2.2 source-interface FastEthernet0/0

R1(config)# timeout 1000

R1(config)# threshold 2

R1(config)# frequency 3

R1(config)# ip sla schedule 1 life forever start-time now

The above configuration defines and starts an IP SLA probe.

The ICMP Echo probe sends an ICMP Echo packet to next-hop IP 2.2.2.2 every 3 seconds, as defined by the “frequency” parameter.

Timeout sets the amount of time (in milliseconds) for which the Cisco IOS IP SLAs operation waits for a response from its request packet.

Threshold sets the rising threshold that generates a reaction event and stores history information for the Cisco IOS IP SLAs operation.

After defining the IP SLA operation our next step is to define an object that tracks the SLA probe. This can be accomplished by using the IOS Track Object as shown below:

R1(config)# track 1 ip sla 1 reachability

The above command will track the state of the IP SLA operation. If there are no ping responses from the next-hop IP the track will go down and it will come up when the ip sla operation starts receiving ping response.

To verify the track status use the use the “show track” command as shown below:

R1# show track

Track 1

IP SLA 1 reachability

Reachability is Down

1 change, last change 00:03:19

Latest operation return code: Unknown

The above output shows that the track status is down. Every IP SLAs operation maintains an operation return-code value. This return code is interpreted by the tracking process. The return code may return OK, OverThreshold, and several other return codes.

Different operations may have different return-code values, so only values common to all operation types are used. The below table shows the track states as per the IP SLA return code.

Tracking

Return Code

Track State

Reachability

OK or over threshold

(all other return codes)

Up

Down

The Last step in the IP SLA Reliable Static Route configuration is to add the “track” statement to the default routes pointing to the ISP routers as shown below:

R1(config)# ip route 0.0.0.0 0.0.0.0 2.2.2.2 track 1

R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 10

The track number keyword and argument combination specifies that the static route will be installed only if the state of the configured track object is up. Hence if the track status is down the secondary route will be used to forward all the traffic.

Please rate the helpfull posts.

Regards,

Naidu.

View solution in original post

18 REPLIES 18
Reza Sharifi
Hall of Fame Expert

Hi John,

Yes, it is possible.  for the primary route you define a static route and use the default admin distance/metric which is 1

for the secondary route you define a second static route and make the admin distance/metric higher then 1.

The lower metric is the primary route

HTH

Hi Reza

That does help alot. However, there is still an area which I'm not sure of - and I think looking at it - my original post was not clear/correct.

Assuming that we have static routes as follows (which I think is what you are suggesting):

ip route X.X.X.X 255.255.255.0 Y.Y.Y.Y 1

ip route X.X.X.X 255.255.255.0 Z.Z.Z.Z  10

I would like to router to failover to the "secondary" static route if the "end destination" i.e. the subnet X.X.X.X is not available via Y.Y.Y.Y. If I understand what I have read on the internet properly, the static route will only be replaced in the routing table if Y.Y.Y.Y is not available, not if any hop between Y.Y.Y.Y and X.X.X.X goes down.

Is my understanding correct? And if so, how do you get around this?

Thanks

John

The articles I have seen are:

"Static routes do not dynamically adapt to network topology changes or equipment failures."

http://www.inetdaemon.com/tutorials/internet/ip/routing/static/

"Static routes stay in the routing table  even if the next hop gateway becomes unavailable. Unless physical  failure they are removed from the routing table only if the  corresponding layer two or layer three protocol is down"

http://www.mreji.eu/content/default-static-route-failoverload-balancing-part-i

Hi John,

I think, you are looking for IP sla tracking command

have a look:

http://www.cisco.com/en/US/docs/ios/12_3/12_3x/12_3xe/feature/guide/dbackupx.html

Assuming that we have static routes as follows (which I think is what you are suggesting):

ip route X.X.X.X 255.255.255.0 Y.Y.Y.Y 1

ip route X.X.X.X 255.255.255.0 Z.Z.Z.Z  10

Correct, for the first route you don't have to specify 1, because that is default.

HTH

Hi Reza

That looks like what I would want to know.

Out of interest, do you know or know of a link that explains what circumstances causes a router to "drop a static route"? It is not clear from the articles I have found up to konw.

Thanks

John

LondonCisco wrote:

Hi Reza

That looks like what I would want to know.

Out of interest, do you know or know of a link that explains what circumstances causes a router to "drop a static route"? It is not clear from the articles I have found up to konw.

Thanks

John

A static toute configured in a Cisco will disappear from the routing table if the interface it's connecting via is down or not connected.

So if you have

ip route 192.168.0.0 255.255.255.0 172.16.1.2

And an interface configured as 172.16.1.1/30 which is UP, the route to 192.168.0.0 will exist in your routing table.

If the interface 172.16.1.1 is down (either physically or administratively), the route to 192.168.0.0 will be removed from the routing table.

So if you've got a flapping link or something which is causing the interface your route is going "out" to go up and down, the route would appear, then disappear, then re-appear depending on the state of the link.

Cheers.

View solution in original post

Hi Darren

Thanks, that is very helpful. If ok with you, could we explore how this affects our current setup at work?

If I understand rightly from your example below:

ip route 192.168.0.0 255.255.255.0 172.16.1.2

The static route will only be removed from the routing table if the interface 172.16.1.1 goes down (either physically or administratively). Therefore, if any link between (and including) 172.16.1.2 and 192.168.0.1 (say) went down, the static route would not be removed and 192.168.0.1 would not be available.

The reason that I want to understand this as best we can, is that we have 2 externally provided vlans to a common service supplier (LAC/LNS fyi). I would like to failover between the 2 vlans if the route to LAC service fails i.e. the router cannot reach the LAC service.

My original thought was 2 routes as follows:

ip route X.X.X.X 255.255.255.0 Y.Y.Y.2 1

ip route X.X.X.X 255.255.255.0 Z.Z.Z.2  10

But if Y.Y.Y.2 went down, Y.Y.Y.1 would still be up on our router and therefore the router would still be using the Y.Y.Y.2 static route, despite traffic failing to get to X.X.X.X.

Is this correct?

And then, if I am correct, the obvious need for ip sla tracking as this is sending echo requests to the final destinatinon i.e. X.X.X.X - monitoring whether this reachable or not!

Thanks!

John

Hi,

it will depend which type of link tou have between your router and the next-hop.

if it is a point-to-point( PPP,HDLC, point-to-point Frame-relay subinterface) then if the other end goes down, yours will too and so you don't need tracking.

if it is a multipoint( Frame-relay, ethernet) and you have a device in between your ends then when one end goes down the other will still stay up and that's where tracking comes into place.

Regards.

Alain

Don't forget to rate helpful posts.

Hi John,

Hope the below explaination will help you...

R1(config)# ip route 0.0.0.0 0.0.0.0 2.2.2.2

R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 10

If you notice the Administrative Distance for the secondary route pointing to ISP2 is increased to 10 so that it becomes the backup link.

The above configuration with just two floating static routes partially accomplishes our requirement as it will work only in the scenario where the routers interfaces connected to the WAN link are in up/down or down/down status. But in a lot of situations we see that even though the links remain up but we are not able to reach the gateway, this usually happens when the issue is at the ISP side.

In such scenarios, IP SLAs becomes an engineer's best friend. With around six additional IOS commands we can have a more reliable automatic failover environment.

Using IP SLA the Cisco IOS gets the ability to use Internet Control Message Protocol (ICMP) pings to identify when a WAN link goes down at the remote end and hence allows the initiation of a backup connection from an alternative port. The Reliable Static Routing Backup using Object Tracking feature can ensure reliable backup in the case of several catastrophic events, such as Internet circuit failure or peer device failure.

IP SLA is configured to ping a target, such as a publicly routable IP address or a target inside the corporate network or your next-hop IP on the ISP's router. The pings are routed from the primary interface only. Following a sample configuration of IP SLA to generate icmp ping targeted at the ISP1s next-hop IP.

R1(config)# ip sla 1

R1(config)# icmp-echo 2.2.2.2 source-interface FastEthernet0/0

R1(config)# timeout 1000

R1(config)# threshold 2

R1(config)# frequency 3

R1(config)# ip sla schedule 1 life forever start-time now

The above configuration defines and starts an IP SLA probe.

The ICMP Echo probe sends an ICMP Echo packet to next-hop IP 2.2.2.2 every 3 seconds, as defined by the “frequency” parameter.

Timeout sets the amount of time (in milliseconds) for which the Cisco IOS IP SLAs operation waits for a response from its request packet.

Threshold sets the rising threshold that generates a reaction event and stores history information for the Cisco IOS IP SLAs operation.

After defining the IP SLA operation our next step is to define an object that tracks the SLA probe. This can be accomplished by using the IOS Track Object as shown below:

R1(config)# track 1 ip sla 1 reachability

The above command will track the state of the IP SLA operation. If there are no ping responses from the next-hop IP the track will go down and it will come up when the ip sla operation starts receiving ping response.

To verify the track status use the use the “show track” command as shown below:

R1# show track

Track 1

IP SLA 1 reachability

Reachability is Down

1 change, last change 00:03:19

Latest operation return code: Unknown

The above output shows that the track status is down. Every IP SLAs operation maintains an operation return-code value. This return code is interpreted by the tracking process. The return code may return OK, OverThreshold, and several other return codes.

Different operations may have different return-code values, so only values common to all operation types are used. The below table shows the track states as per the IP SLA return code.

Tracking

Return Code

Track State

Reachability

OK or over threshold

(all other return codes)

Up

Down

The Last step in the IP SLA Reliable Static Route configuration is to add the “track” statement to the default routes pointing to the ISP routers as shown below:

R1(config)# ip route 0.0.0.0 0.0.0.0 2.2.2.2 track 1

R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 10

The track number keyword and argument combination specifies that the static route will be installed only if the state of the configured track object is up. Hence if the track status is down the secondary route will be used to forward all the traffic.

Please rate the helpfull posts.

Regards,

Naidu.

View solution in original post

Hi Naidu

That is very helpful and very complete! That helps immensely with understanding IP SLA.

John

HI Naidu

A quick query - is IP SLA a standard feature on all routers/Cisco IOS, or is there someway of checking that it is installed on a router?

Thanks

John

Hello Naidu,

 

Could you do this with one extra route? so you have two bakcup routes?

 

Thanks in advance for your response

Excellent article and description of how to use IP SLAs!

So I'm guessing you'd not just configure this on one side of the circuits, but on both routers on either ends of the circuits, correct?

Hello Naidu, what options do you have monitoring static route reachability if you run ios version 12.2(35)se5? Upgrading the IOS would be too much of a pain. Please let me know, thanks.

 

Henry

paramar@hotmail.com