can I use HSRP with one router and two ISP links?

[Samiullah Osman]

hello 

I have a 3900 cisco router. it has 3 interfaces, our company has to internet service providers. can I use HSRP with one router and tow internet links?

[MHM Cisco World · Accepted solution]

https://www.mustbegeek.com/configure-policy-based-routing-on-cisco-router/

for HSRP no you can not use it 
but you can use PBR as shown in example above

[Samiullah Osman]

in this case how can I configure NAT with two different out bands?  

I really appreciate your help.

[Richard Burts]

@Joseph W. Doherty high marks for a creative solution. I am reasonably confident that if you configure this on real hardware that it would be accepted. But I am not sure that it will really produce the desired results. What ip address would devices on G0/1 have? If they are getting their address via DHCP then they would be in 192.168.2.0. This introduces a second subnet that will require additional configuration on the firewall to route the new subnet and to NAT for the new subnet. If you manage to get the devices to use ip addresses in 192.168.1.0 then they would arp for their gateway (which is 192.168.1.1) and the IOS device would reject the arp request (if you turn on debug for arp you would see error messages about "wrong cable").

And the most basic problem with this solution is that it would require 4 interfaces on the router but the original post is quite clear that the router has only 3 interfaces.

The original poster asks a follow up question " how can I configure NAT with two different out bands". The answer is that NAT when there are 2 outbound interfaces is configured using a route map (rather than the usual implementation that just references an acl). The route map would have 2 match statements, the first match would be for the outbound interface and the second match would be for the acl.

[Joseph W. Doherty]

Hey @Richard Burts, great questions, all!

I'm afraid you've lost me on why this solution would require 4 interfaces?  Possibly because I only used 1 "real" network in my prior posting?  For issues in my own mind, separate and before seeing your posting, I "fleshed out" a more representative PT implementation - hopefully to test whether it was actually workable, i.e.:

Router0, in the above, would the on-site router, with links to two different ISP routers.

The Router#(1)s, were a copy of the original 3 routers, with a switch added and links moved to it.

Router0 has:

interface GigabitEthernet0/0/0
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto
!
interface GigabitEthernet0/0/1
ip address 192.168.2.1 255.255.255.0
duplex auto
speed auto

Changed to, on Router0(1):

interface GigabitEthernet0/0/0
ip address 192.168.1.10 255.255.255.0
duplex auto
speed auto
standby 0 ip 192.168.1.1
standby priority 255
standby preempt
standby 1 ip 192.168.2.1
!
interface GigabitEthernet0/0/1
ip address 192.168.2.10 255.255.255.0
duplex auto
speed auto
standby 1 ip 192.168.2.1
standby 1 priority 255
standby 1 preempt
standby 0 ip 192.168.1.1

Which results in:

Router#sh stan b
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Gig0/0/0 0 255 P Active local 192.168.2.10 192.168.1.1
Gig0/0/0 1 100 Standby 192.168.2.10 local 192.168.2.1
Gig0/0/1 1 255 P Active local 192.168.1.10 192.168.2.1
Gig0/0/1 0 100 Standby 192.168.1.10 local 192.168.1.1

Which, although it looks good, does not work when you shut a link.

The problem is, all HSRP groups, require a physical interface IP to support them.  PT did provide a warning message ("% Warning: address is not within a subnet on this interface") when adding a HSRP group IP w/o a supporting interface IP.  I suspect, a physical secondary IP would satisfy HSRP, but also suspect it would be considered an overlapping network and could not be configured w/o VRF.  (NB: PT version being used, 8.2.0.0162, doesn't support secondary addresses or VRF.)

As mentioned, above, I had other issues in mind, which include issues like if WAN links were using /30 or /31 networks, and when you convert current interface's physical address, to virtual, whether you have any address space left for a new physical interface address, or another address for the backup interface.  (I.e. for network 192.168.1.0/24, we only need 2 IPs to start with, but will need 4 IPs with HSRP.)

Another issue that came to mind, if the primary IP interface fails, will router re-route using the backup interface's secondary IP (I think it should, but if we need to use VRFs, that muddies the waters because the two WAN interfaces would be in different VRFs).

Rick brings up DHCP (on WAN?).  We should be able to convert using a static IP, although, of course, if ISP changes IP assignment or network, it will break.  (DHCP on a WAN interface should also, ideally, be using a DHCP loaded route, and unsure how a DHCP WAN interface would impact NAT or a FW "tied to it".)

Further regarding NAT and/or FW, don't see the need for adding another subnet, just that both WAN links networks would/should be "known" as reachable on two interfaces, rather than just one.

Is using HSRP/MHSRP still possible?  I believe it still might be, but it now looks like VRF would be required to avoid the overlapping networks, of physical interface IPs (including secondaries?).

To the OP, again, what are you trying to accomplish?  By adding a switch, and assuming we can backstop a WAN interface failure on the router, by adding a switch, we've add 3 more points of failure, i.e. the two switch interfaces and the switch itself.  (NB: for switch interface connecting to router, its failure would impact network the same as if router interface failed, but now there's two interface's in series, which, I believe, doubles the change of such a logical failure.)

Yea, in theory, if we can switch over from a (your) router failed WAN interface, we may avoid disrupting some in-flight traffic.

As for other options, assuming you're willing to add external switches, you might do something like create a two (or even three) link port-channel from your router to a "smart" (stacked) switch.  Logically, topology would likely be what you have now, but physically you might have more effective bandwidth and additional redundancy.

[Joseph W. Doherty]

Ah, an additional requirement, not mentioned in OP, although as ISPs were mentioned, should not have been unexpected.  (My bad, I haven't even thought about that aspect, because of the bulk of my experience.)

Your NAT is tied to (just?) two WAN interface IPs provided from your ISP (i.e. one from each?)?  (As typically found in homes or within small/medium businesses.)

Or, do you have your own AS public IP network, which you access via two ISPs?  For the latter, your NAT would be tied to one or more of your AS public IPs, correct?

If your NAT is tied to your WAN interface IPs, your MHSRP IPs would become what you're using now on your WAN interfaces, but I don't know whether NAT would support that.

Most of my experience has been in large Enterprises with NAT tied to a public AS IP(s), hosted within a DMZ, i.e. NAT not tied to the ISP WAN links.  I.e. for such, NAT would not be an issue relative to the WAN links, themselves.)

If you could better describe your topology, and exactly what you would like to accomplish, and not, possibly, with having to use specific technologies, we could likely provide better recommendations.

[balaji.bandi]

HSRP only work with 2 Device to be part of the HSRP Group.

Since you have only 1 device  and are connected to TWO ISP, suggest to use any BGP if possible

or as suggested PBR  if you looking to split the Load between ISP - 

Example X subnet need to go to ISP1

Example Y subnet needs to go to ISP2

But if you looking Fail over - then you need to use EEM and IP SLA to detect the failure and run EEM Script.

Note Edited : (forgot to add config la example )

https://www.balajibandi.com/?p=1643

[brodynienow7]

Having the same problem with this. I think HSRP with one router is completely fine to work with.

[Joseph W. Doherty]

Yes, you can, but to obtain redundancy benefits (I'm assuming that's your goal) from using HSRP, you need one or more external switches, and how much you might do depends much on how "smart" your external switches are.

From a redundancy standpoint, having two Internet links, regardless of failure of one of their paths, other should continue to provide Internet access.  I.e. except for lost  of Internet "bandwidth", failure of an Internet path should not be critical.

However, assuming one of your three interfaces is the "inside" facing interface, loss of it would disconnect all Internet access.

BTW, considering failure of a 3900 interface, alone (i.e. the router, as a whole doesn't drop), is probably much less likely than some issue with an Internet path (also probably not caused by failure of its 3900 interface, alone).

[Richard Burts]

To use HSRP you must have 2 routing devices connected to each other, and to other non routing devices all in the same subnet. As I understand the original post the environment described does not have this.So HSRP is not possible here.

The original post says that the router has 3 interfaces. One interface for first ISP, another interface for second ISP, and third interface for the inside network. Since the inside network is connected on only a single interface there is no redundancy for the inside network. Since there are 2 interfaces for ISP there are possibilities for redundancy with ISPs. I suggest these possibilities:

- 2 static default routes (configured with same Administrative Distance). This would result in load sharing with some traffic using each ISP.

- 2 static default routes one configured with a higher Administrative Distance. This would result in traffic preferring the first static route (lower AD) and failing over to the second ISP if the first one has problems. (you might also need some type of tracking to verify reachability of first ISP).

- run BGP with both ISP and have each ISP advertise just a default route. This would result in load sharing between ISP.

[Joseph W. Doherty]

"To use HSRP you must have 2 routing devices connected to each other, and to other non routing devices all in the same subnet. As I understand the original post the environment described does not have this.So HSRP is not possible here."

Indeed, the environment described would not support HSRP, which is why I mentioned needing external switches.

What I actually had in mind is using MHSRP, whose features, I believe (?), are also provided by any platform that supports HSRPv2 (which I'm assuming a 3900 does).

The real question is, can MHSRP be used between a pair of interfaces on the same device?

I believe (?) you can (I could, though, be very much mistaken - and, unfortunately, don't have a lab to test - @Richard Burts do you know for 100% sure, it would not work?).  If MHSRP does not work between interfaces on the same device, VRF might, or might not, allow the MHSRP config.  (If it does, we're getting into a rather "messy/complex" config.)

Even assuming MHSRP could be used, as I envisioned, I would recommend against doing that, because, again, all you're doing is "protecting" against a single router/ISP interface failure.

From the rest of Rick's reply, I believe he's assuming OPlooking to accomplish either some form of load sharing between ISPs or failure of a primary ISP over to a secondary.  Here, as Rick often writes, there's really insufficient information in the OP to make the goals clear (as you only literally ask about using HSRP with a couple of ISP links, not further clarifying how/why you want to use HSRP).  HSRP if often used for primary to secondary failure situations, and with MHSRP it might also be used for load sharing, but if either of those are your goals, what Rick suggests are much, much better approaches than using some variant of HSRP.

The only advantage, that comes to my mind, if something like MHSRP could be made to work on the same device, if one of your router's ISP/interfaces failed (again there's external switches), the traffic would continue to flow back in on the backup interface (but now I'm not so sure about outbound traffic, as I think some more on it - keep in mind, HSRP is a FHRP, not so much oriented for router-to-router redundancy, more oriented for host to its gateway redundancy).

If your goal is primary/secondary failovers or load sharing, do keep in mind, you have much control for how you might direct your to Internet traffic (like other posters suggestions of PBR, EEM scripts, etc.), but the converse can often be more difficult to manage/accomplish especially if you have your own AS IP(s).

[Richard Burts]

@Joseph W. Doherty external switches is an interesting suggestion. But I do not see how that would address the situation described in the original post.

You say "The real question is, can MHSRP be used between a pair of interfaces on the same device?" MHSRP requires that the interfaces be in the same subnet. And I am not aware of any version of IOS that allows 2 interfaces on a layer 3 device to be in the same subnet (attempts to do this result in the error about overlapping address). The closest I can think of something that does this would be IRB, which does allow 2 physical interfaces to be in the same subnet, but in this case the IP address is not on the physical interface but is on the virtual interface.

Yes I do frequently comment about posts that ask questions without providing much detailed information to work with - and this is one of those situations.

I interpret the original post to be asking about HSRP providing redundancy. Unfortunately with a single interface for the inside network there is no possibility of redundancy. But with 2 interfaces for outside there are alternatives for redundancy and that is what I discussed. 

[Joseph W. Doherty]

". . . external switches is an interesting suggestion. But I do not see how that would address the situation described in the original post."

Rick, because, you need, as you correctly note, to get HSRP interfaces on the same network.  I.e. without them, you have no way to "bridge", at L2, interfaces for HSRP purposes.

"MHSRP requires that the interfaces be in the same subnet."

Agreed, for the same group.  Of course, though, MHSRP does support multiple different networks on the same interface (as different groups).

"And I am not aware of any version of IOS that allows 2 interfaces on a layer 3 device to be in the same subnet (attempts to do this result in the error about overlapping address)."

Yea, that's what I'm unsure about with MSRP, I'm thinking it might work because of their virtual nature.  However, assuming MHSRP behaves like physical interface IPs do, i.e. multiple interfaces, in same network, not allowed on same device, then VRF should allow it because you can have even the same physical IP on different interfaces, same device, if those interfaces are in different VRFs.

Anyway, to reiterate, I wholly agree with Rick (nor I believe, suggested otherwise) that just the hardware described in OP is insufficient.  Again, this is why I wrote to make HSRP work at all, you need extra external hardware, such as switches.

Rick doesn't believe MSRP could work because Cisco's IOS restricting usage of interface IP sharing the same network on the same device.  What I'm unsure about, whether the (rarely?) used MHSRP would work, I think it might, but again, as noted in my prior reply, I could be very much wrong/mistaken, at least if not also using VRFs.

With VRF, I know you can have interfaces, on same device, with overlapping network usage, as long as they are in different VRFs (an exception to Rick's [general] statement about no IOS allowing such, to his awareness).  So, with VRFs, I would expect MHSRP to work (actually, and BTW, cannot say for 100% certainly, because I have not tried this, nor have the hardware to test) on the same device, but if VRFs becomes involved, this is becoming a very "messy/complex" "solution".  Even if MHSRP worked without VRFs, external L2 bridging is still needed, and all you really accomplish is providing redundancy for (just) a single interface failure on your router.

If OP's goal is beyond just being able to use HSRP, such as providing redundancy or better load sharing, what Rick and others have suggested would be much better approaches.

Lastly, my initial posting was counter point to other postings that HSRP could not be used.  With the caveat of a requirement of an additional L2 bridging device, like a switch, I still believe on your 3900, yes HSRP might be used; but assuming I'm correct, again, I wouldn't recommend this approach.

If I don't recommend such an approach, why bring it up?  Well, I like to, on occasion, try to "think-outside-the-box", and encourage others to do likewise.  Such thinking can sometimes be useful for interim and/or long-term solutions.

A very old joke, which highlights "thinking-outside-the-box", goes as follows:  (warning, by today's standards, following might not be politically correct)

A fellow was driving along the road, at night, an had a tire blowout driving past a "nut house".

He stopped, and started to change the tire.  While doing so, a patient of the institution, came up to the fence and stared at him.

This made the fellow, so nervous, he overturned the hub cap holding the dismounted tire's lug nuts, losing them.

He then said to himself, oh no, what can I do?

The patient staring at him, spoke for the first time, and said "Just take one lug nut from all your other wheels so you can get to the next repair station".

The driver then spoke to the patient "Yes, of course, that should work.  Ah, hope you don't mind me saying, I'm a bit surprised by your suggesting this, as you're a patient, here."

The patient then replied "Hey, I might be a nut, but I'm not stupid!".

BTW, at one firm I worked at for 10 years, another engineer called me a "mad scientist"; which no one else, or even I (laugh), disputed.

[Joseph W. Doherty]

PS:

As noted earlier, don't have an equiped lab to test, but do have a copy of PT, v. 7.3.0.0838, and was able to do this:

interface GigabitEthernet0/0
ip address 192.168.1.254 255.255.255.0
duplex auto
speed auto
standby 0 ip 192.168.1.1
!
interface GigabitEthernet0/1
ip address 192.168.2.253 255.255.255.0
duplex auto
speed auto
standby 0 ip 192.168.1.1

Router#sh stan b
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Gig0/0 0 100 Active local 192.168.2.253 192.168.1.1
Gig0/1 0 100 Standby 192.168.1.254 local 192.168.1.1

PT believes you can do what I thought you might, but I wouldn't take PT as being much of a guarantee that's this is truly workable.

I will say, I was surprised PT accepted the above, as often PT is very feature lacking (for example, the 2900's IOS is VRF unaware).

I'll also note, a point @Richard Burts brought up, if you try to place two interfaces, on the PT's 2900 router, in the same network, it's rejected (as expected), i.e. g0/0 and g0/1 being in different subnets isn't by accident.  Further, you need a physical interface IP for HSRP to activate.

Laugh, also the engineer who tagged me as a "mad scientist" also thought of me as a "stick in the mud".  The latter because I don't believe in doing something "new" and/or "cool", just because you can, it has to serve a real business purpose.  Also, because it has to really work, without issues (one of the issues that often arises with "new").

I've often surprised people when a commercial solution comes along to solve something I've solved in some "zany" way, I push to migrate to it.  I.e. they are surprised I'm not tied to "my" ("zany") solution.  This because, in the real world, on-going maintenance is much easier if you don't need to support "home grown" (espeically "zany") solutions.