|
Hi,
You will find a discussion we have currently with julian regarding VRRP
VMAC handling, and the best way to handle.
The problem : Linux kernel doesn't permit to work with many MAC on a single
NIC (only one at a time)
For the moment we have some way to solve this problem :
1. Do not handle VMAC just send gratuitous ARP during VRRP VIP takeover
2. Use a userspace ARP daemon replying ARP request => At this point we
think that userspace is probably not the rught place to handle this
issue...
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....
If someone has any other point of view or idea, fill free to join this
thread.
Best regards,
Alexandre
---------------[ Previous discusion ]---------------
Hi Julian,
>> > Regarding to ARP, I have patches that fix the ARP probes to
>> >always announce the preferred source address as source IP in our ARP
>> >probes.
>>
>> This can be a solution ! very very interresting
>
> Yes, it avoids the ARP proves "who-has XXX tell VIP"
>and replace them with "who-has XXX tell PRIMARY_DEVICE_UNIQUE_IP"
>
>> >IIRC, what you want is to control with what VMAC to send
>> >the ARP replies?
>>
>> In fact I want that : during IP takeover, VIP is set to backup LVS
>> director. I want that MAC associated with this VIP (the VMAC so), reply
to
>> ARP request. So remote host will not see that IP takeover appear.
>
> Yes. So, if the physical device see the remote ARP probe they
>must not reply, at least with their unique MAC. This is something like
>the VIP is set on device "lo" even in the director and lo/hidden=1.
>But then someone should reply "VIP is-at VMAC".
Yes exactly ! :)
>> > What changes you need in the kernel? The ARP replies?
>> >Something else? I'm not sure you need to send TCP and UDP with
>> >VMAC src, it is needed only for ARP, IMO.Is it correct? Please,
>> >tell me if you think that all this stuff is resolved in your work
>>
>> Yes ARP replies... In fact currently I use simple gratuitous ARP to
update
>> remote caches... but during IP takeover using this technic I have a TTL
>> expiration... Do you think that gratuitous ARP using the real NIC and
ARP
>
> Which TTL expires?
Probing the current VRRP implementation during IP takeover when I let a
ping on a VRRP VIP (on a third party workstation). When takeover appear, I
have TTL expiration (I do not understand really why...)... no packets are
lost but IP takeover introduce this strange TTL expiration (probably due to
gratuitous ARP to update cache, or my switch, ...). If I use VMAC (one at a
time), no TTL expiration... because MAC address still the same for the VIP
takeover.
>> replie to VMAC will solve this expiration ? in a first step gratuitous
ARP
>> will update arp cache and if remote try to resolv ARP we reply to ARP
>> request sending a ARP reply with the VMAC... Need you sentiment on that
>> point... If you agree then this will definately solve my problems :)
>
> I don't understand it completely. What you consider as desired
>behavior?
We consider 2 LVS directors (LD1 & LD2) LD1 own VIP1. VIP1 correspond to
VMAC1 so ARP requests to VIP1 reply VMAC1. If LD1 crash => takeover of VIP1
on LD2 and LD2 must reply to ARP request to VIP1 with VMAC1.
=> We extend this axiome for many VMAC.
=> Gratutitous ARP are not really needed during takeover... only if we are
using switch... need to update switch CAM table (VMAC1 change from switch
port1 to switch port2 for example).
Best regards,
Alexandre
|
