|
Hello Kyle,
>> The problem : Linux kernel doesn't permit to work with many MAC on a
single
>> NIC (only one at a time)
>
>It took me some time to figure out the purpose of this discussion -- I
>think the reason for this is so you can have multiple virtual routers on
>one physical interface yes?
with VRRP VMAC handling... Yes
>The problem is that the RFC calls for a unique MAC address per virtual
>router, and the Linux kernel does not permit multiple MAC addresses on a
>single interface. So, assuming I'm understanding the problem correctly...
Yes you got it. Many VIP in VRRP Intance identified by a single unique
VRID. If Multiple VRID in MASTER state on the same NIC, linux kernel
doesn't permit reply with each VRID VMAC associated.
>> 3. Aplpy a kernel space patch to reply ARP requests for VRRP VIP => so
we
>> will be able to handle as many VMAC as VRRP Virtual Router => That way
we
>> will be RFC compliant.
>> 4....
>
>Why not extend this to virtual interfaces (sub-interface in Cisco-speak)
>that just happen to use another interface to send traffic out of?
Yes you can try setting up a dummy interface via netlink interface and then
setting its MAC... Netlink permit that... But when you dump the ARP traffic
you will see that MAC address associated to this VMAC will be the MAC
address of the NIC interface owning the IP address in the same network.
>Kind of
>like the bonding driver... except it behaves as a physical device to all
>user-space tools in all ways -- don't just load balance traffic across
>multiple physical interfaces, you could have multiple virtuals per
>physical, or layer multiple virtuals on top of multiple physicals, etc.
hmm... bonding driver permit setting up a MAC address for a specific
bonding interface ? this bonding interface reply with this setted MAC ?
Regards,
Alexandre
|
