HSRP: Virtual/Interface IP address allocation

Unanswered Question
Jul 3rd, 2008
User Badges:
  • Bronze, 100 points or more

Hi,

This query is regarding the virtual IP address allocation in HSRP.


What if the virtual IP chosen to be of a different subnet from the interface IP?


According to RFC 2281, this is something achievable though I'm curious to know the consequences(if any).


RFC 2281 says "The IP address SHOULD belong to the primary subnet in use on the LAN, but MUST differ from the addresses allocated as interface addresses on all routers and hosts

on the LAN, including virtual IP addresses assigned to other HSRP groups."


One question remains with respect to the subnet being used by the virtual address.

Will this address take the subnet mask of the interface address, or will just be a /32.


The other question is: what are the cons of having these assignments from two different networks?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.8 (4 ratings)
Loading.
Edison Ortiz Fri, 07/04/2008 - 17:35
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

The HSRP IP address is used as the "gateway" for hosts on that LAN. For those hosts to be able to reach the HSRP IP Address, they must be on the same subnet. Therefore, assigning a HSRP IP Address in a different subnet than the LAN physical interface provides no benefit.


HTH,


__


Edison.



rsgamage1 Sun, 07/06/2008 - 23:51
User Badges:
  • Bronze, 100 points or more

Here's a scenario which my original query is of practical importance.


When two different administrative boundaries connect via a multi-access or a broadcast network (e.g. Ethernet LAN-to-LAN) this kind of an allocation may be required. Here, a /30 network is used for connecting peer gateways, and a network transparent to the remote peer is used for HSRP.


One choice would be that a larger network (e.g. /29) could be used in the HSRP side so that two additional IPs from the allocated larger network could be used as interface IPs.


However, the downside is that this wastes public IPs allocated for peer connectivity.


My question remains with regard to the RFC, that according to my understanding it provides some leeway to use IPs of different networks (doesn't the use of word "SHOULD" imply the same?). I'm not nitpicking here, but trying to get a certain point clarified.


Thanks for your time.







Edison Ortiz Mon, 07/07/2008 - 03:57
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

You can use IPs from different networks in a broadcast domain, that subject is not the issue at hand.


1) HSRP serves as a first hop redundancy protocol for hosts in a LAN.


2) The proper configuration is having the physical interfaces and the HSRP virtual IP address in the same subnet. The hosts must also be in the same subnet as the address above for reachability.


3) If you don't meet the requirements from step 2, how useful is HSRP in the network if the hosts can't reach it. In other words, for host-to-host reachability, devices must be in the same network or use a device on that network as a 'gateway' to that subnet. This 'gateway' must have reachability to both subnets 'even' if they reside in the same broadcast network.


Reading RFCs is great but please apply the RFCs into a lab and see it for yourself.


HTH,


__


Edison.

rsgamage1 Mon, 07/07/2008 - 05:41
User Badges:
  • Bronze, 100 points or more

I see your point now. I've emulated it locally and it doesn't work. Many thanks.


In my scenario, it is a LAN gateway of the remote network that sits on one side; thus the control we have is minimal.


It appears that, unless the other party agrees to have a higher network mask (with waste of a few IPs), there's no way to run HSRP on the remote link.


Is there any workaround/ or an alternative approach to achieve this?



Edison Ortiz Mon, 07/07/2008 - 06:49
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

Is there any workaround/ or an alternative approach to achieve this?



Not to my knowledge.


__


Edison.

rsgamage1 Mon, 07/07/2008 - 23:54
User Badges:
  • Bronze, 100 points or more

I see this as a limitation (literally a drawback).


If you take any POSIX related VRRP implementation (keepalived for e.g.), they have an enormous amount of flexibility when it comes to IP address management.


It allows you to run VRRP on one interface and assign virtual IPs to other interfaces upon failure of the active link/router. There I do not see any constraint such as what I've come across w.r.t. HSRP implementation.


To elaborate a bit, if I can run an HSRP instance using a particular interface, there is no way to assign virtual IPs to other active interfaces of the device upon state transition.


Hope I've not overlooked any key fact here.


Is there any other Cisco feature that helps in achieving this objective? Here I'm focusing, mainly on router fail-over.





Joseph W. Doherty Mon, 07/07/2008 - 15:23
User Badges:
  • Super Bronze, 10000 points or more

From what you describe, would using HSRP addresses based on secondary addresses be of any use?

rsgamage1 Tue, 07/08/2008 - 01:01
User Badges:
  • Bronze, 100 points or more

Using secondary addresses, how would you tackle the issue with IP subnets I've described?

rsgamage1 Tue, 07/08/2008 - 02:59
User Badges:
  • Bronze, 100 points or more

I've emulated this using the broadcast address of the original network (with the expanded netmask).


e.g:


1.1.1.2/30: remote gateway


1.1.1.1: Standby IP of local gateways(R1 & R2)


R1: HSRP interface IP 1.1.1.3/29

R2: HSRP interface IP 1.1.1.3/29 secondary


I see the duplicate IP assignment notification.

" %IP-4-DUPADDR: Duplicate address....."


However, the reachability and the fail-over works. What do you think of the idea? Any serious concerns?


I appreciate your valued feedback on this.

Joseph W. Doherty Tue, 07/08/2008 - 05:46
User Badges:
  • Super Bronze, 10000 points or more

That's interesting! Not what I had in mind. I was thinking it might be possible to have a secondary HSRP without a corresponding physical address. I.e. Your physical addresses would be in a different subnet from the HSRP address. Don't know if you could do this, and it does bring along the question of how the HSRP address would know its network mask, although that might not be required.


However, since you touched on expanding the subnet mask on your side, and assuming you wouldn't need IP broadcasts, you could have the physical interfaces at addresses in a larger subnet address space and just keep the HSRP address in the /30.


You also mentioned, in another prior post, VRRP. Some of the later Cisco platforms support VRRP. If your does, again, I wonder whether it might be possible to define a non-owned VRRP gateway, either directly or as a secondary without requiring the physical interfaces to have addresses within that subnet.


As to concerns about what you've discovered, it's the type of thing, even if it appears to work, that often finds a problem later on.


The better solution, if one can be found to work, I think, is to keep the virtual gateway address within the /30 and the physical interfaces addresses either in a different subnet or outside the address space scope of the other router.

rsgamage1 Tue, 07/08/2008 - 06:10
User Badges:
  • Bronze, 100 points or more

......


Having the standby IP of a different subnet does not simply work.(As discussed already)


As far as I can see Cisco VRRP behaves in the same manner.

Configuration choices are also limited compared to other open source implementations as I indicated in one of my previous posts.





rsgamage1 Thu, 07/10/2008 - 07:10
User Badges:
  • Bronze, 100 points or more

Hi,


Here's the what I've done with the original broadcast address.


If you have a close look, you'd see that I have swapped the two IPs assigned on the physical interface (two networks)..So R1 sends HSRP packets with 10.1.9.9 whereas R2 sends them with 10.1.8.1.



Remote Gateway: 10.1.9.8/30


R1

==

interface FastEthernet0/0

ip address 10.1.9.9 255.255.255.248

ip address 10.1.8.1 255.255.255.248 secondary

standby priority 105 preempt

standby ip 10.1.9.7

:

.


R2(backup)

==

interface FastEthernet0/1

ip address 10.1.8.2 255.255.255.248

ip address 10.1.9.9 255.255.255.248 secondary

standby preempt

standby ip


What kind of issues would I encounter with this setup?


Could there be any service/application level problems(Voice/Data..etc)?


Thanks for your thoughts/suggestions.

rsgamage1 Thu, 07/10/2008 - 07:22
User Badges:
  • Bronze, 100 points or more

My apologies, some typos..


Let me put everything once again.


Here's the what I've done with the original broadcast address.


If you have a close look, you'd see that I have swapped the two IPs assigned on the physical interface (two networks)..


R1 sends HSRP packets with 10.1.9.99 whereas R2 sends them with 10.1.8.2.


Remote Gateway: 10.1.9.98/30

[Network 10.1.9.96/30]



R1

==

interface FastEthernet0/0

ip address 10.1.9.99 255.255.255.248

ip address 10.1.8.1 255.255.255.248 secondary

standby priority 105 preempt

standby ip 10.1.9.97

:

.

R2(backup)

==

interface FastEthernet0/1

ip address 10.1.8.2 255.255.255.248

ip address 10.1.9.99 255.255.255.248 secondary

standby preempt

standby ip


What kind of issues would I encounter with this setup?


Could there be any service/application level problems(Voice/Data..etc)?


Thanks for your thoughts/suggestions.


Edison Ortiz Fri, 07/11/2008 - 11:33
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

What kind of issues would I encounter with this setup?


I've never seen a setup of that kind, I can't comment how well that is going to work.


__


Edison.

rsgamage1 Sat, 07/12/2008 - 08:02
User Badges:
  • Bronze, 100 points or more

I've deployed it in the production network and seems to be working fine.


Because of the Virtual IP/MAC concept, I think it would not give any trouble as long as reachability is maintained.


Especially for a fail-over scenario this would be feasible and duplicate IP address (Secondary) issue wouldn't be of a serious concern.



rsgamage1 Mon, 07/14/2008 - 00:21
User Badges:
  • Bronze, 100 points or more

Wouldn't this be a feasible solution for remote provider assigned IP subnet(typically /30) for the interconnection?



Actions

This Discussion