Gateways sharing same IP

mathieuploton · ‎02-09-2012

Hello,

I would like to add redundancy to a design but I am stuck with Cisco HSRP/VRRP limitation (virtual IP should be in the same subnet than the physical IPs).

Basically, I provide to my customers, a /29 public subnet, 5 available hosts as 1 IP in this subnet is my gateway.

Instead of one gateway, I would like to have two gateways for redundancy. And of course, I dont want to consume 3 publics (one virtual and 2 physical) or extend the subnet. So my initial idea was to use 2 private real IP and one public IP. Which works fine by the way with Huawei Firewalls (VRRP).

But I test it with GNS3 and it does not work.

The two gateways are Cisco 3845.

Is there a solution to this?

darren.g · ‎02-09-2012

mathieuploton wrote:
Hello,
I would like to add redundancy to a design but I am stuck with Cisco HSRP/VRRP limitation (virtual IP should be in the same subnet than the physical IPs).
Basically, I provide to my customers, a /29 public subnet, 5 available hosts as 1 IP in this subnet is my gateway.
Instead of one gateway, I would like to have two gateways for redundancy. And of course, I dont want to consume 3 publics (one virtual and 2 physical) or extend the subnet. So my initial idea was to use 2 private real IP and one public IP. Which works fine by the way with Huawei Firewalls (VRRP).
But I test it with GNS3 and it does not work.
The two gateways are Cisco 3845.
Is there a solution to this?

The problem with this configuration is that the "virtual" IP is not the Ip used as the source for packets goign OUT the interface, as far as I know.

So your inbound traffic works, because the "public" IP is advertised and the "private" IP addresses behind the VRRP just accept the packets - but when you return (ack, or originated traffic), the private IP address of the phsyical interface originating (or answering) the traffic is used - which can't be routed in "public" space, so gets dropped at the next router hop.

You can verify this by putting a small switch (or hub) in-line with your "outbound" link and running a sniffer or packet capture on the link - and see what source IP address is being used on the packets.

I could be 100% wrong with this - the only time I tried to make a similar setup work was with Juniper routers, and they may have done things completely different to Cisco - so try to packet sniff and see.

I can't, off the top of my head, figure out a work around for this beside using 3 IP addresses for each VRRP/HSRP group - one for each interface and one for the virtual. Someone smarter than me may chime in here - or tell me I'm a moron and am completely wrong in the Cisco world. :-)

Cheers.

mathieuploton · ‎02-09-2012

Actually with HSRP in GNS3, it simply does not work. When I configure a virtual IP that does not belong to the same subnet as the real interface, there is no hello packet sent between the routers. The standby mode is not working.

darren.g · ‎02-09-2012

mathieuploton wrote:

Actually with HSRP in GNS3, it simply does not work. When I configure a virtual IP that does not belong to the same subnet as the real interface, there is no hello packet sent between the routers. The standby mode is not working.

You know, you could try configuring all three IP addresses in the HSRP/VRRP group with private addresses and do NAT to your single public address. Not sure if you can NAT two interfaces to a single public IP, though.

As for GNS3 not working - GNS doesn;t support *all* features, so it's possible this is soemthing that just won't work on it.

Cheers

mathieuploton · ‎02-10-2012

I am not sure how it can work with NAT. My customers are in the /29 public subnet and will point the gateway to a public IP. Then on the GW I configure three private addresses NATed to a public one ?

I think the public GW will not be reachable from the customer.

mlund · ‎02-10-2012

Hi

I got it to work with GNS. Here are the config

hostname r4

interface FastEthernet0/0

ip address 10.1.1.2 255.255.255.0

standby 2 ip 10.1.1.1

standby 2 ip 123.123.123.1 secondary

!

interface FastEthernet0/1

ip address 10.2.1.2 255.255.255.0

standby 3 ip 10.2.1.1

standby 3 ip 124.124.124.1 secondary

!

ip classless

ip route 123.123.123.0 255.255.255.0 FastEthernet0/0

ip route 124.124.124.0 255.255.255.0 FastEthernet0/1

hostname r3

interface FastEthernet0/0

ip address 10.1.1.3 255.255.255.0

standby 2 ip 10.1.1.1

standby 2 ip 123.123.123.1 secondary

!

interface FastEthernet0/1

ip address 10.2.1.3 255.255.255.0

standby 3 ip 10.2.1.1

standby 3 ip 124.124.124.1 secondary

!

ip classless

ip route 123.123.123.0 255.255.255.0 FastEthernet0/0

ip route 124.124.124.0 255.255.255.0 FastEthernet0/1

r3#sh stand

FastEthernet0/0 - Group 2

State is Standby

1 state change, last state change 00:33:33

Virtual IP address is 10.1.1.1

Secondary virtual IP address 123.123.123.1 (wrong subnet for this interface)

Active virtual MAC address is 0000.0c07.ac02

Local virtual MAC address is 0000.0c07.ac02 (v1 default)

Hello time 3 sec, hold time 10 sec

Next hello sent in 2.048 secs

Preemption disabled

Active router is 10.1.1.2, priority 100 (expires in 9.280 sec)

Standby router is local

Priority 100 (default 100)

Group name is "hsrp-Fa0/0-2" (default)

FastEthernet1/0 - Group 3

State is Active

2 state changes, last state change 00:32:12

Virtual IP address is 10.2.1.1

Secondary virtual IP address 124.124.124.1 (wrong subnet for this interface)

hostname r2

interface FastEthernet0/0

ip address 124.124.124.99 255.255.255.0

ip route 0.0.0.0 0.0.0.0 124.124.124.1

hostname r1

interface FastEthernet1/1

ip address 123.123.123.99 255.255.255.0

!

ip route 0.0.0.0 0.0.0.0 123.123.123.1

r2#ping 123.123.123.99

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.99, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/42/112 ms
r2#

/Mikael

mathieuploton · ‎02-12-2012

Thanks, I will try this !

EDIT: I tried and indeed that works. I will try on real devices now.

Peter Paluch · ‎05-01-2012

Hello Mikael,

Whoa, this is a very interesting workaround! Quite ingenious, I would say. I just hope Cisco is not going to implement some sanity checks into its HSRP implementation and ignore those secondary vIP address for which there is no appropriate secondary address configured on the interface. That's the weak point of this... but if it works why not use it?

Best regards,

Peter