[Xorp-hackers] xorp svn VRRP centos

[Ben Greear]

On 02/25/2010 05:59 AM, Eric S. Johnson wrote:
>
> 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:

If it compiles fine, then maybe a run-time check in xorp itself would
work.  Attempt to do the set with netlink, check to see if it worked,
if it fails, then fall back to the ioctl (and set flag to no longer
try netlink for the rest of this run).

That should get rid of that #define entirely.

> 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?

That seems lame.  That code is only valid if netlink exists, but then they
disable it..so probably in the history of xorp, that code was never executed
if I understand these comments correctly.

> 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.

Well, on the wire the frame will be a minimum size of 60 bytes (not counting ether CRC),
but it can easily be padded with crap that is not logically part of the packet
and doesn't need to be passed up to user-space.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com