|
Hi ratz,
La pèche ? :)
>> The VRRP code will be finish quickly (but still too busy to give a fixed
>> date) after my current fight with NIC MII-registers....
>
>:) http://marc.theaimsgroup.com/?l=linux-kernel&m=101145413118679&w=2
>and http://marc.theaimsgroup.com/?l=linux-kernel&m=101727648020657&w=2
a :) nice, and exactly what is needed for linux !. When developing
networking code such zebra, VRRP, ... link state monitoring is really
needed and must be included into the state machine code to not perturbe the
network protocol native functionality.
This mean that without NIC link state/hardware state monitoring it can
introduce a side effect in many protocol. For example in VRRP, if the
instance is in BACKUP state <=> waiting for remote MASTER adverts. If we
unplug the BACKUP NIC but the MASTER still active, then BACKUP will not
receive MASTER adverts and deduce MASTER is down... so will transit to
MASTER state ....
This side effect is very noisy and can be sometime worked around with some
logics algo but still some side effect (for me "sync_instance" without link
state reporting introduce a noisy loop into the state machine :/).
Link state like MII-register monitoring is really needed and must be used
in routing soft (like zebra :) as Stefan mention in his LKML mail).
=> VRRP RFC spec must be complete with a FAULT state drived according to
the NIC availibility.
=> This FAULT_STATE is really needed in the VRRP FSM => It place the VRRP
instance in a "waiting for advert" state without the timeout handling for
BACKUP_STATE. That way we are clean and effective :)
When I read the LKML post from Stefan it introduce some questions :
When we develop a network software userspace like BGP, VRRP, ... (zebra in
short) what is the best way to handle NIC state activity and state
transition ?
For me the ideal solution would be a netlink broadcast message on
IFF_RUNING validity. Nice but need to patch/rebuild kernel. And need to
wait for official integration patch.... But for me it is the final wanted
functionality for NIC state notification.
If we look on MII code, MII is present on most NIC so monitoring
MII-register is the right way IMHO to handle NIC state notification. MII
transciever can be probed from userspace using a specific ioctl to
SIOCGMIIPHY. This userspace tool can be generic and portable to other
kernels to permit support of this for kernel 2.2 users.
IMHO MII polling (in the VRRP code) can be done throught a MII probe before
each sending VRRP advert thread. That way the soft will monitor MII
transceiver every secondes (since in MASTER state adverts are sent every
secondes). And in BACKUP state if the VRRP state machine want to transit to
MASTER state (no remote MASTER adverts received) MII probe will detect if
this is the remote MASTER down or a link loose from itself. => So the MII
states will condition the new VRRP FAULT_STATE. => That way takeover will
be more quicker enven sync_instance because probe will be done in both
states MASTER & BACKUP.
>> The Sebastien Petit VRRP code (freevrrpd) is nice, but since keepalived
>> framework is based on a generic I/O scheduler (the one from zebra), the
>> port to other UNIX env can be more quicker...
>
>Seems to be the french people's most liked RFC. I wonder if this is
>already translated to french (couldn't resist)
:))) this is exactly what I was thinking when I received the previous mails
:) strange...
>> If you want docs on VRRP, I will be disponible for writing after my MII
>> hack...
>
>What part is still missing?
For the MII I need to export mii-diag code into a layer1.c lib in
keepalived. Basically functions probing MII transiver. The functions will
be :
o int mii_tranceiver_present(int ifindex); => checking MII availibility
throught SIOCGMIIPHY ioctl call
o struct MII *mii_probe(int ifindex); => probing and fetching MII infos =>
during VRRP bootstrap
o int mii_linkup(int ifindex); => does MII report a properly functional
link beat ?
that is all :)
=> I need to find time to code that part, I have been too busy with a
multi-level proxy architecture.
=> Will try today :) or this week end
>> PS: try to free my time for attempting OLS :)... not easy.... too busy
:/
>
>You'll better show up or I'll drag you up there. Seriously now, you
>really need to sign up or you won't get a place anymore.
:) I need to obtain agreements from my employer before... Is there a sign
up deadline ? signup is needed for OLS passport ?
Best regs,
Alexandre
|
