RE: VRRP Advertisement packet dropped by Linux IP stack

"Don Provan" <[email protected]>
Newsgroups gmane.ietf.vrrp
Message-ID <[email protected]>
Hi, Luong. I saw your message before Christmas, but I didn't have
time to respond. This is really largely a Linux discussion, so
we should take further discussion off line.

The important observation is that VRRP actually *requires* that
the backup router *never* owns the IP address. (In practice, I'd
say there's some slack here, but there actually isn't any question
about the spec's position.) So you should *not* set it up as a
secondary address for the interface except on the owner. I found
that avoiding setting the IP address cleared up lots of Linux
issues. Unfortunately, to avoid adding the IP address as a
secondary, I had to modify the ARP table maintenance IOCTL to
allow an ARP table entry to be set including a specific MAC
mapping. More on that in a second.

An ARP mapping from the VR IP to the VR MAC is *all* that Linux (or
any system, really) needs to know about the VR IP address. It's
almost all Linux needs to know about the MAC address: the other
thing is that the MAC address has to be added to the ethernet's
list of MAC addresses to receive. For my drivers, this just meant
adding it as if it was a multicast MAC address, but other drivers
(and hardware) might require something specific to unicast MAC
addresses.

My work was with Linux 2.4, and I haven't gotten a chance to look
at whether 2.6 is significantly different. I'll try to take a peek
this week and see if I can send you a patch.

-don provan

-----Original Message-----
From: Luong Ngo [mailto:[email protected]]
Sent: Friday, December 22, 2006 6:03 PM
To: [email protected]
Subject: [VRRP] VRRP Advertisement packet dropped by Linux IP stack 


Hello all,

I have VRRP running on Linux kernel 2.6.14 and  here is the situation I am in.
My simple configuration has 1 master and 1 backup VRRP router. I start with the master router is down, and so the backup router takes over the VR IP, the current implementation is that when a backup router takes over the VRIP, it would go add the VR IP to the local interface as a secondary IP of that interface. And this is causing the problem. When the master router comes up, it starts sending out the advertisement messages with the source IP is the VR IP. These packets arrive at the backup routers and they are dropped by the IP stack in Linux and my guess is that it checks the source IP and realize Source IP is the same as local interface's IP which is added when the backup transition to master state for the virtual router (this check is in fib_validate_source function of file net/ipv4/fib_frontend.c). 

Has anyone encountered this problem? Is it wrong to add the VRIP to the local interface? All help is greatly appreciated.

Happy Holidays.

-Luong

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

_______________________________________________
vrrp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/vrrp
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.