• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 541
  • Last Modified:

Cisco IOS - Provide a secondary/backup route to a specific subnet

How do I setup routes to allow for a secondary route to become active in the event of an issue with a primary route ?

I have two sites, each with two IOS routers.

R1 and R2 are a HSRP pair in the primary site, and R3 and R4 are a HSRP pair in a satellite site.

There is a private link between R1 and R3, and a second private link between R2 and R4.

The attached document shows the current configuration. I want the following two subnets to communicate with each other.

192.168.10.0/24 - on R1 and R2
192.168.12.0/24 - on R3 and R4

These subnets should communicate over the primary link between R1 and R3 under normal circumstances. If that link fails then the traffic between the subnets needs to move to the link between R2 and R4.

Will the ip route entries on each router, as shown in the attached document, produce the desired affect ?

If not, what is the preferred/recommended way to achieve this ?

TIA Redundant-Routing-Configuration.pdf
0
ccfcfc
Asked:
ccfcfc
  • 12
  • 7
  • 7
  • +3
4 Solutions
 
SanjeevlokeCommented:
static seems fine ..
what type of links are those serial or ethernet ?
if ethernet just static wont switchover to second route for that u have to configure IP SLA with track of static route..

0
 
SanjeevlokeCommented:
if links are ethernet buy HSRP tracking u can just do failover no need of all static routes ..
every router will have just one default route to WAN.

in HSRP u have to track WAN IP with IP SLA so that prorirty of failed WAN link router reduces and
passive router become active and traffic flows through it  ..

0
 
ccfcfcAuthor Commented:
Sanjeevloke,

Thanks for the replies.

The links are ethernet, which would explain why nothing happens when the link drops based on your first response.

I'm trying to avoid the whole router failing over.

The links between the sites occasionally go down but there has been no need to failover between the routers for over two years, so I would prefer that the route changes to use the alternate link when necessary rather than switching the whole router.

Can you point me to any documentation that details the IP SLA process, as I haven't used this before ?
0
Evaluating UTMs? Here's what you need to know!

Evaluating a UTM appliance and vendor can prove to be an overwhelming exercise.  How can you make sure that you're getting the security that your organization needs without breaking the bank? Check out our UTM Buyer's Guide for more information on what you should be looking for!

 
SanjeevlokeCommented:
ok sure....
0
 
SanjeevlokeCommented:
ip sla monitor 10
type echo protocol ipIcmpEcho 172.29.139.134 source-ipaddr 172.29.139.132  --------Remote WAN ip
frequency 300
ip sla monitor schedule 10 start-time now life forever


track 1 rtr 10 reachability

ip route 0.0.0.0 0.0.0.0 1.1.1.1 track 10 ---------Primary route
0
 
mikebernhardtCommented:
It would be a lot easier to just use a dynamic routing protocol like EIGRP to manage this. Just configure it on all 4 routers and they will take care of the whole thing. Messing with IP SLA and HSRP seems like a more complicated configuration to avoid dynamic routing.

The very simplest way to do it would be on all 4 routers to just add the following:
router eigrp 1
 network 192.168.0.0 255.255.0.0
 no auto-summary

that's it!
0
 
SteveJCommented:
Agree with mikebernhardt. If possible use EIGRP.

Steve
0
 
ccfcfcAuthor Commented:
If I implement EIGRP will I need to remove the HSRP elements of my config ?
0
 
mikebernhardtCommented:
They have nothing to do with each other and they can co-exist. But if the only purpose of the HSRP is to have a single next-hop address for your static routes, then you can remove it. You will have to remove the static routes once EIGRP is configured though.
0
 
ccfcfcAuthor Commented:
So, if I do the following.....

1. Setup EIGRP and include all networks present across all four routers.
2. Remove any HSRP entries.

This will give me resilience if any router fails, or any interface or link to any router fails.

Is that correct ?
0
 
mikebernhardtCommented:
Yes, but are you using HSRP for any LAN operations or only for your routing? Don't remove the HSRP if it's also giving you a resilient default gateway on LANs. that is completely independent of routing.
0
 
ccfcfcAuthor Commented:
Yes, HSRP is giving me resilient default gateways. Apologies if I didn't make that clear.

Apologies also for the dumb questions. I haven't used EIGRP before so I'm on a steep learning curve.
0
 
SanjeevlokeCommented:
I agree with running EIGRP/OSPF between sites is a better solution..
But if someone is new it will be difficult for troubleshooting when issue appears ...
0
 
SteveJCommented:
No, just get familiar with what the routing table looks like when everything is normal. Once you have it installed and running, break some things and take note of what hsppens.

Steve
0
 
ipajonesCommented:
Running EIGRP on all routers is the best solution as inidicated by @mikebernhardt.  By doing so you'll find that R3 will have a backup route (feasible successor) to 192.168.10.0 and 192.168.11.0 via R4 and this similar pattern will be true for all routers.  However, you still need HSRP to provide a single resilient gateway to the end-user devices.  One other comment;  with HSRP you don't need necessarily to use an IP SLA as HSRP allows you to track an interface directly.  So under the interface where HSRP is configured just track the relevant WAN link using the track interface command:

# standby <HSRP-Group-Number> track <int> <priority-decrement>

Open in new window

You can then automatically failover the VIP to the standby router even if the router itself hasn't failed.  This stops traffic destined for the remote network from being re-routed across the local network to the alternative router but instead automatically uses the alternative router since it has become active after the tracked link has failed. Using EIGRP should ensure that no traffic would be dropped since the backup route would be used in the small amount time before HSRP fails over.  EIGRP convergence when a backup route exists is almost instant, whereas HSRP may drop a packet.

--IJ
0
 
SanjeevlokeCommented:
His links are Ethernet so i dont think ....track of interface will work without IP SLA ..
If links were serial no issues ...
0
 
ipajonesCommented:
@sanjeevloke:  Why not ?  You can track the ethernet interfaces just like a serial interface, when the link drops the interface will go down.
0
 
SanjeevlokeCommented:
no ethernet interface wont go down as its protocol stays up only ..
0
 
mikebernhardtCommented:
I think that in this simple network, no standby tracking is required. All 4 routers will be communicating with each other via EIGRP. If a WAN link goes down on the router that currently has the HSRP address, that router will still have routes to the remote site via the 2nd router. It's not a big deal if the traffic takes an extra router hop before crossing the WAN.

If you want to really optimize traffic flow, then IP SLA would be useful. The problem with HSRP tracking here is that you could have a service outage that keeps the physical link up but the MPLS cloud is down, effectively causing the WAN to be down.

But again, what's the big deal? If a router dies then HSRP will fail over for the users at that site. If a WAN link dies, the traffic will simply take an alternate path and no one but the network admin will even know. That's the beauty of a dynamic routing protocol vs. static routes. There isn't going to be a whole lot of EIGRP troubleshooting to do on a network like this, and you can learn the basics of how it works.
0
 
mikebernhardtCommented:
For the author's benefit: The way EIGRP works in a nutshell is that 2 routers become "neighbors" and exchange information about routes. The router uses the best path to the remote site, which in your case would normally be the connected WAN link. If that link is bad for any reason, the 2 routers can't talk, so those routes drop. At each site, the 2 routers there would communicate across the LANs to each other, again sharing their all of routing information. So the router with the bad WAN link will simply take the next-best route through its partner router and across the other WAN link.

Easy, huh?

0
 
ccfcfcAuthor Commented:
So, based on the responses to my initial question and the network diagram that I have attached, would the following router configurations be correct to ensure that -

1. My routers will failover under HSRP in the event of interface issues and the default gateway addresses for connected devices will remain the same.
2. Traffic will be routed over the private links between the sites using the preferred link under normal circumstances and the second link if there are issues with the preferred link.



Router 1

interface Vlan100
 ip address 192.168.10.1 255.255.255.0
 standby 10 ip 192.168.10.254
 standby 10 priority 150
 standby 10 preempt
 standby 10 track GigabitEthernet0/0 60
interface Vlan200
 ip address 192.168.11.1 255.255.255.0
 standby 20 ip 192.168.11.254
 standby 20 priority 150
 standby 20 preempt
 standby 20 track GigabitEthernet0/0 60
router eigrp 1
 network 192.168.10.0 255.255.0.0
 network 192.168.11.0 255.255.0.0
 network 192.168.12.0 255.255.0.0
 network 192.168.20.0 255.255.0.0
 no auto-summary

Router 2

interface Vlan100
 ip address 192.168.10.2 255.255.255.0
 standby 10 ip 192.168.10.254
 standby 10 preempt
 standby 10 track GigabitEthernet0/0
interface Vlan200
 ip address 192.168.11.2 255.255.255.0
 standby 20 ip 192.168.11.254
 standby 20 preempt
 standby 20 track GigabitEthernet0/0
router eigrp 1
 network 192.168.10.0 255.255.0.0
 network 192.168.11.0 255.255.0.0
 network 192.168.12.0 255.255.0.0
 network 192.168.20.0 255.255.0.0
 no auto-summary

Router 3

interface GigabitEthernet0/0.1
 ip address 192.168.13.1 255.255.255.0
 standby 10 ip 192.168.13.254
 standby 10 priority 150
 standby 10 preempt
 standby 10 track GigabitEthernet0/1
router eigrp 1
 network 192.168.10.0 255.255.0.0
 network 192.168.11.0 255.255.0.0
 network 192.168.12.0 255.255.0.0
 network 192.168.20.0 255.255.0.0
 no auto-summary

Router 4

interface GigabitEthernet0/0
 ip address 192.168.13.2 255.255.255.0
 standby 10 ip 192.168.13.254
 standby 10 priority 90
 standby 10 preempt
 standby 10 track GigabitEthernet0/1
router eigrp 1
 network 192.168.10.0 255.255.0.0
 network 192.168.11.0 255.255.0.0
 network 192.168.12.0 255.255.0.0
 network 192.168.20.0 255.255.0.0
 no auto-summary
0
 
ipajonesCommented:
Routers 3 and 4:
The wildcard mask used in the network command is incorrect, it's like a wildcard mask used in ACL's, it's not the same as a subnet mask, if fact you can think of it as an inversed subnet mask.  In addition, the network commands identify the interfaces on the device that you want to enable with EIGRP, therefore from your diagram as you only have interfaces in the .20 and .12 subnets you don't need to reference .10 and .11 on routers 3 and 4.

EIGRP config for routers 3 and 4:

router eigrp 1
  network 192.168.12.0 0.0.0.255
  network 192.168.20.0 0.0.0.255
  no auto-summary

Open in new window


That's it.  Equally understand that you could just do "network 192.168.12.0" without the wildcard mask as this would match any inteface with an IP in the 192.168.12.0 classful class C network.

Looking at the HSRP config on 3 & 4 I don't understand where the .13 subnet has come from ?  I thought the VIP was 12.254 ?  Also on R3 you need to change the default decrement of 10 on the track command otherwise the priority won't be decremented enough such that the standby router takes over.

Routers 1 and 2:
Following the same login EIGRP config for routers 1 and 2 as follows:

router eigrp 1
  network 192.168.10.0 0.0.0.255
  network 192.168.11.0 0.0.0.255
  network 192.168.20.0 0.0.0.255
  no auto-summary

Open in new window


HSRP config looks ok for 1 and 2.  Router 1 will be active for both HSRP groups.



0
 
mikebernhardtCommented:
The reason I used 16 bit masks (and it's true, they should be inverse masks) was to have a single command that would cover all interfaces. If you add another LAN later it will be included automatcially so you don't have to remember to add it. If you want to specify the networks then you don't need the mask at all because EIGRP will use the classful mask by default, which is /24.

A few things about HSRP:
1. You don't need to use a standby group, though it's fine that you're using 10. If you leave that out it puts the interface into group 0. Each interface on a router is independent so they don't need to be in separate groups.
2. There's no point using standby tracking on the interface with the lower HSRP priority, as it's already the standby.
3. As ipajones said, you need to make the tracking decrement to less than the backup, not the same.
4. You don't want to use standby preempt on both sides of the HSRP. You just want to make sure the the primary interface takes over again when it can if it failed previously.

So I would do this much simpler config:
Router 1
interface Vlan100
 ip address 192.168.10.1 255.255.255.0
 standby ip 192.168.10.254
 standby priority 100
 standby preempt
 standby track GigabitEthernet0/0 15
interface Vlan200
 ip address 192.168.11.1 255.255.255.0
 standby ip 192.168.11.254
 standby priority 100
 standby preempt
 standby track GigabitEthernet0/0 15
router eigrp 1
 network 192.168.0.0 0.0.255.255
 no auto-summary

Router 2

interface Vlan100
 ip address 192.168.10.2 255.255.255.0
 standby ip 192.168.10.254
 standby priority 90
interface Vlan200
 ip address 192.168.11.2 255.255.255.0
 standby ip 192.168.11.254
 standby priority 90
router eigrp 1
 network 192.168.0.0 0.0.255.255
 no auto-summary

Router 3
interface GigabitEthernet0/0.1
 ip address 192.168.13.1 255.255.255.0
 standby ip 192.168.13.254
 standby priority 100
 standby preempt
 standby track GigabitEthernet0/1 15
router eigrp 1
 network 192.168.0.0 0.0.255.255
 no auto-summary

Router 4
interface GigabitEthernet0/0
 ip address 192.168.13.2 255.255.255.0
 standby ip 192.168.13.254
 standby priority 90
router eigrp 1
 network 192.168.0.0 0.0.255.255
 no auto-summary
0
 
mikebernhardtCommented:
Have I answered your question satisfactorily? If we're done, you should accept an answer so that the question will be closed.
0
 
ipajonesCommented:
...or answers !  :)
0
 
ccfcfcAuthor Commented:
I'm waiting for an opportunity to arrange a maintenance window so that I can make and test the config changes.

It may not be quick as they take some time to schedule on this system.
0
 
mikebernhardtCommented:
Got it, no problem. Just making sure you didn't abandon the question.
0
 
ccfcfcAuthor Commented:
Quick update.

I'm still waiting for a maintenance window to be arranged so that I can implement and test the changes.
0
 
ipajonesCommented:
In my view a working solution was provided and the points should be split between @mikebernhardt and @ipajones.

Thank you.
--IJ
0
 
mikebernhardtCommented:
Agree with ipajones.
0
 
digitapCommented:
I've requested that this question be deleted for the following reason:

Not enough information to confirm an answer.
0
 
mikebernhardtCommented:
The question was abandoned some time ago and both of us experts agreed that the points should be split between us. We have him thorough answers and he promised to try them then never returned. Points should be awarded.
0
 
ipajonesCommented:
I agree with @mikebernhardt in that a working solution was provided and that the points should be split between @mikebernhardt and @ipajones for the answers we provided.  Please clarify why you say not enough information was provided ?

Thanks
--IJ
0
 
ipajonesCommented:
In my opinion the comments (http:#36961337 and http:#36978825) complimented and clarified some points regarding the initial solution provided by @mikebernhardt (http:#36963085).  Comment http:#36981103 by @mikebernhardt also provided more details and clarification.

The answers and details provided enough information to enable the asker to setup EIGRP to provide backup routes (Feasible successors) given the topology provided.

Some guidance with regard to HSRP and directly tracking an interface within the HSRP config was also provided and this included a discussion as whether HSRP was definitely required.

--IJ
0
 
mikebernhardtCommented:
Having just looked through this thread again, I'm going to go with ipajones explanation or which comments were most helpful. If I was to grade the answers, I would accept my answer http:#36981103 with a strong assist by ipajones 2 answers http:#36961337 and http:#36978825. I have no problem with splitting points evenly between us.

The question was essentially about how to provide a resilient backup solution. We suggested dynamic routing and also differentiated and clarified the proper use of HSRP and IP SLA vs. routing in order to deal with various failure scenarios.
0
 
mikebernhardtCommented:
I don't see the points awarded...
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 12
  • 7
  • 7
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now