We are currently using VSRP (Layer2/3) where we have a single IP as the gateway per VLAN. We are considering moving to VRRP (Layer3) which requires 3 IPs, 1 virtual and 2 real ones. This means that we now need 2 extra IPs from each of our client's VLANs. We can probably persuade our clients to give up those IPs but what I'm worried about is human error. Some of our clients have large IT staff and if we tell a couple people:

  • Me: From now on do NOT use .2 and .3
  • Client: Sure, no problem, you got it!
  • The remaining IT staff forget/didn't read/weren't told

Few months/years later. Someone adds a server with .2 and .3 (I know they will be stupid to do it - but it could happen) and then they blame us for the downtime. Sure, we could show them a copy of the notice with the big red warning and be off the hook as far as our responsibility for the mess, but still, it won't change the fact that they were down. Or let's even say it's not a person who was negligent: let's say their DHCP range was configured 10 years ago to use .2 to .5 and they didn't realize the conflict until a new device was plugged in. Or let's say there is a powered off device that uses .2. Initial ARP audit shows no .2 and everyone agrees that it's safe to take away from the client. A couple of months later they turn on the device, and there is trouble.

Is there a way to eliminate the human error and/or reduce the damage from the assignment of a conflicting IP. By the way, what happens when there is a conflicting gateway anyway? - I'm assuming we'll get intermittent on/off internet connectivity as the conflicting device and the router fight over ARP. Is there a way to block a user device from using a reserved IP in the first place?

Normal duplicate addressing defences should take care of this particular situation.

Specifically, when the client assigns .2 to some server, which is clashing with .2 already on your second router, the server will generate errors when it tries to bring the interface up, as pretty much all OS test for this. Misconfigured server will normally ARP for its own address as it comes up, and your VRRP routers will answer on the addresses for the real and virtual routers.

A similar thing should happen if there's a DHCP server giving out .2 by accident, as the DHCP server should ping or ARP for the address before leasing it out.

If you control the switch you could lock the routers' addresses to their ethernet addresses or use other defences; from the router's point of view this looks just like an ARP spoofing attack by the misconfigured host.

Lastly, I believe your main route (to the virtual address) will continue to work even if the physical addresses are being taken over by misconfigured hosts, as the VRRP inter-router communication happens over multicast.

In general I think it's wise to take into account any likely operational error. In this particular case I'd set it up on the bench with your actual equipment and try some egregiously awful client configurations.

I tend to agree with @jonathanjo but otherwise:

It is often forsaken, but VRRP - contrary to Cisco HSRP - does NOT require that the primary address of the interfaces belong to the same network as the virtual address. (In fact a VRRP advertisement packet can contain several virtual IP addresses).

So you can also assign whichever IP you want to the routers and avoid the issue entirely.

  • That is good news. I did some googling on the subject and I found that what you are saying is true. However, it seems to be device specific and/or complex (using NAT). Is that what you are referring to when you say "forsaken"? If so, unfortunately we can't afford to have forsaken network config. It has to be a standard easy to understand setup. – user3280964 Sep 13 at 22:11
  • No, I just mean many people don't know it. You can perfectly have interface real address 192.168.1.1 and virtual IP 10.0.0.1. No NAT or anything special required. It is possible that some device don't support it tough. – JFL Sep 14 at 6:47
  • From what I can see Arista supports this eos.arista.com/a-comparison-of-virtual-ip-commands but Juniper doesn't. Unlucky for us we are planning to go with Juniper because Arista doesn't have big enough BGP routing table size. – user3280964 Sep 14 at 17:56

A simplicistic, hand-hewn idea:

Are .2 and .3 (or whichever addresses you plan to use for VRRP later on) free to use today?

Then grab them now, and configure the them as IP alias (or ip address <ip> <mask> secondary in Cisco speech) on the current interface of one of the routers.

If that doesn't mix well with the current VRRP setup, consider adding a VRF/routing-instance to the router with a single additional interface, assign the .2 and .3 to that interface, and connect it to another port of the LAN switch.

Add an inbound traffic filter to that interface denying (not dropping) all traffic but ARP and ICMP Echo request to the interface IPs, so any attempt to talk to these IPs will trigger an ICMP unreachable from the router to the initiator. That should help most client-side software to fail its connection attempt quickly and gently, instead of running into timeouts.

Duplicate address detection mechanisms of modern OSs should prevent most addressing collisions, as jonathanjo already pointed out.

Collisions might still happen, but they will make uncooperative users/admins stand out of the crowd ["ah.. you took the .2? and now the freshly installed server won't... ? yes? Oh yes, by all means, please do revisit the addressing guidelines of 17 months ago..."].

With the addresses being secondaries or on a separate interface, any of these collisions won't hurt the current operating state of the router.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.