|
Re,
>> comment ca va ? :)
>
>Pas mal, merci. Depuis des mois des maladies folles et assez de
>travaille j'essaie de recouperer ma vie. J'espere que tu vas bien?
Ben j'arrete pas de turbiner... Et j'ai pas assez de temps pour faire tout
ce que je voudrais... mais sinon ca va :)
>> Yes, I will add hooks on this in the framework.... My only limitation is
my
>> validate time :/
>
>I thought about something like that was missing but I didn't know the
>code. How do you intend to do it?
My current problem is exactly that :
1. Constat : Before sending any adverts to the VRRP multicast group, we
need to be sure that we will able to send it. Otherwise we deduce that the
interface is unavailable and we must remove the VRRP VIPs and stop sending
adverts. When interface will come UP we will restart sending VRRP advert.
2. Current implementation : Currenlty we never stop sending advert even if
if is IFF_DOWN. That way when interface became UP we do not have to restart
sending advert... It is implicit... For me this was a rapid develop way...
But it sound nasty.... I agree....
3. Requested code modification (adding full 1. ) :
3.1 Create a netlink func in the vrrp_ipaddress.c called
netlink_address_ipv4_isset(...) performing a netlink call to retreive info
on a specific IP address and return 1 or 0 if IP address is set on an
interface (can verify that the IP is set on the proper interface too)
3.2 If IP is set throught our netlink call, we need to create a func to
retreive specifics link state. For example if SWITCH/HUB where the NIC is
plugged into burnt, then NIC link will be down... So we need to determine
this event... What is the best way to code this ? netlink ? MII register
fetched ? => MII register gave nice informations but it is not a generic
chipset present on all NIC :/
=> I need some point of view/cons here... What is the most effective way
to handle this ?
4. Integration in the keepalived code :
4.1 Integrate a call of that 2 func into the VRRP code : vrrp.c in func
vrrp_send_pkt(...) before calling sendto(...).
4.2 When we can't send advert according to the 3. func we register a
thread_timer(...) to periodicaly pool for interface state... If became
avalable need to register the sending advert thread.
4.3 If using VRRP with IPSEC-AH we need to handle something like a "ipsec
seq_number recover" to not send VRRP adverts with a seq_number already
proceeded, otherwise it will be dropped by receivers...
This is my current wishes for VRRP framework.
Best regards,
Alexandre
|
