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?
Best Answer
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.