I could apologize for every possible thing i could do wrong, being a new list member, but i'll just issue one all-inclusive apology and be done with it, hoping that i don't offend anyone. Here's my problem: There is a Linux implementation of VRRP (RFC 2338), but it doesn't work very well, so i have been trying to get it to work properly in my environment. I have run into the following problems, which lead to the following questions: 1) The original author used rtnetlink to communicate with the kernel routing table, but he must not have done it quite right, because it didn't work. Quick background: In VRRP, there are (at least) two routers, one of which is the master, and the other(s) of which are backup(s). If the master fails a backup takes over. Mind You, the backup takes over the MAC address for all purposes, but is not allowed to reply to packets addressed to the IP address of the master. It only routes things sent to the MAC address of the master. (This is simplified. See the RFC for a complete picture.) The author errantly changed the MAC and IP address of the router, the idea being that the router needs to reply to ARP requests for the MAC address of the master IP address. The problem comes when the MAC address is changed. First question: a) is it possible to change the MAC address without turning the network interface off? The previous author didn't think so, and i'm inclined to agree. So, the interface is taken down and brought back up with the new parameters. This clears the kernel routing cache, which is bad. VRRP routers (the master, actually) send out multicast packets every second. When the backup transitions to the master and is required to shutdown and start up the interface, it properly leaves and rejoins the multicast group (and can see multicast messages from other VRRP routers on the same network), but it will never again receive a multicast packet from the master if the master comes back online (meaning it will not relinquish control to the master as it should). The packet is dropped somewhere in the kernel, and it looks like it's because there isn't an entry in the kernel routing table with type RTN_UNICAST for the hash of saddr, daddr, etc. Second question: b) Can someone explain to me what i'm missing here? Why is it being dropped? 2) I figured, hey, changing the IP address isn't the right way to do this anyway. It should change the MAC address and do proxy ARP for the master IP address. That is, in essence, what the RFC says. So, i tried setting this up. The problem is, the kernel seems to want packets to GO somewhere for any addresses it does proxy ARP for, but that's not what i want. I want to drop any packets coming to me for the master IP address, but i still want to reply to ARP. I even tried adding a blackhole route to the master IP address, but the kernel wants packets to LEAVE the machine before it proxies. The only way around this for now seems to be to add a route to another random interface (lo doesn't work ... i tried), then block the outgoing packets for that IP address with iptables. Next question: a) Is there a way to cajole the kernel into doing proxy ARP the way i want it to? 3) Just a question: Can anyone else think of a better way to achieve the result i am looking for? 4) It really seems to me like VRRP is something that should be implemented in the kernel networking code. Anything in userspace is too cludgy. Question: Is this something that the kernel developers would be likely to accept into the kernel if i were to code it? Kernel versions: Attempted with 2.4.9 RedHat build, and 2.4.18 personal build, Thanks for any pointers. -& -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
