[Xorp-hackers] xorp svn VRRP centos

[Eric S. Johnson]

greearb at candelatech.com said:

> The final hack seems to be that HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN bit.

> Could you temporarily remove your change there and send me the build
> errors?  Hopefully I can figure out how to write a scons rule to
> auto-detect whether it's broken or not... 

It (svn xorp) compiles fine and runs without the define of 
HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN. The problem is that 
scons doesn't detect that HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN on
centos 5, so when the router becomes the primary VRRP router for a network
it goes into the code that tries to use netlink, fails, and vrrp
aborts.

There is a else clause in

fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc

that works (or at least doesn't have vrrp process die)

#ifndef HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN

	code that uses netlink and doesn't work and makes vrrp go south

#else // HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN

    //
    // XXX: a work-around in case the kernel doesn't support setting
    // the flags on an interface by using netlink.
    // In this case, the work-around is to use ioctl(). Sigh...
    //
	code that use a ioctl instead and seems to work.

#endif


In 1.6 the configure has a test, and sets that define appropriately 
in config.h.

Hmm, just checked and xorp-1.6/config/aclinux.m4 has this:

dnl ---------------------------------------------------------------
dnl Check for netlink sockets in the build environment (AF_NETLINK)
dnl ---------------------------------------------------------------
dnl
dnl Note that if we have netlink sockets, then we unconditionally set
dnl HAVE_NETLINK_SOCKETS_SET_MTU_IS_BROKEN and
dnl HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN to 1.
dnl The reason for this is because if we attempt to set the MTU or the
dnl interface flags on a Linux system (e.g., Linux RedHat-7.x with
dnl kernel 2.4-x), this is a no-op: nothing happens, but the kernel doesn't
dnl return an error. The test whether we can really set the MTU and the
dnl interface flags in the kernel is rather complicated, and would require
dnl root privileges. Enjoy... :-(
dnl

So maybe you can just piggy back on test of AF_NETLINK like 1.6 did?



With that patch, vrrp *almost* works. It does the right thing 
on an interface that is in backup/standby mode (nothing). When 
an interface becomes master for the virtual address, it changes 
the MAC address correctly to the VRRP mac. But it does not add
the layer 3 (IP) virtual address to the interface.

It seems to be designed such that a fake arp daemonish section of 
code would respond to arp requests on behalf of the virtual IP.
That code has some errors I have found (like throwing away frames
that are smaller than the "minimum ethernet frame size" (which 
doesn't exist for full duplex ethernet), but so far even correcting that
hasn't made it work. I am still working through that code.

More info coming as it develops. 

E



E