Re: Vrrp Implementation issue over LinuxIp

> Well, I think you're asking the wrong question. The real
> question is how to you make the interface send an ARP reply
> when it's supposed to. I always find it fascinating that
> there's really no good reason for the non-owner system to
> know the VR IP address at all except for ARP, so you're
> best off if you can avoid attaching it to an interface
> to begin with instead of attaching it and trying to
> suppress the results.

Well, sometimes you want to be able to ping, traceroute or
do SNMP queries to the system using the virtual address. So
having the virtual address installed allows that pretty easily.
But if all you need to do is forward atrffic through the system,
then yes, you only need ARP.

One way to prevent the backup from ARPing is to only install
the virtual address (or ARP entry) when the system is master.

> You just add them as if they were multicast MAC addresses
> you want your hardware to accept for delivery

This will work most of the time, but check the driver for the
ethernet device you're using.

Devices have a limit for the number of multicast MACs they can
filter perfectly. If you reach that limit, the driver removes the filters
from the device, changes the device to allow all multicast through,
and the driver filters MACs in software.

If you're adding VRRP MAC addresses as multicast MAC addresses,
and you reach the device's limit, the VRRP traffic may get dropped
by the device when it starts software filtering, because the virtual MAC
is not really multicast.

This will show up if you have a lot of virtual routers running on the same
interface, or if the device has a small number of MAC filters it can support,
or depending on how the device driver is implemented. Try it and see.

Peter

_______________________________________________
vrrp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/vrrp