James Carlson wrote:
Sebastien Roy writes:
On Wed, 2008-10-29 at 17:01 +0800, Yifan Xu wrote:
Sebastien Roy wrote:
Pardon my interjection, but what does this have to do with router
advertisements (Jim's original question)? You're describing the need to
do proxy ND (static neighbor cache entries), which seems unrelated.
Sorry I didn't state it clearly. As I understand, to send
RA messages, in.ndpd requires the source IP address to be
applied on the interface. While in non-accept mode and
non-owner mode this is not true, the IP won't be configured
on the interface. Thus the vrrpd needs to forge and send
RA messages. Please correct me if I were wrong.
I don't see anything above describing why vrrpd needs to be the thing
that forges these RA messages. Any adequately privileged application is
able to forge RA messages, and in.ndpd is well-positioned to do that
since it consumes all of the required RA configuration that is contained
in /etc/inet/ndpd.conf. In order for vrrpd to do anything useful, it
would need to parse /etc/inet/ndpd.conf (just like in.ndpd), reply to
router solicitations (just like in.ndpd), and all of that would be a lot
of complex and duplicate code.
Using in.ndp to send RA messages has a slight difference. The
source IP address of the messages will be the link-local address
of the interface, instead of the proxied IP address. That works
for forwarding packets. But I am not sure whether it conforms
the standard strictly. The RFC requires a master "Must send ND
Router Advertisement for the virtual router".** If this statement
could be comprehended as we don't have to use the virtual IP
for Router Advertisement, then I agree we should use in.ndpd
instead of creating duplicated code.
**
I think more detail is needed in the design document describing exactly
how the RS/RA handling actually works, along with a description of why
the more natural alternate design choice of having in.ndpd do neighbor
discovery wasn't chosen.
+1
In fact, I'd go further: attempting to forge RA messages from inside
some other daemon is just a bug. The best it can do is cause code
duplication.
The very same issue should exist for the IPv4 equivalents: ICMP Router
Discovery messages and RIP broadcasts, at least, and probably ICMP
redirects as well.
The implication of all of this is that implementing the "forward only"
semantics of VRRP merely by installing a proxy ARP/ND entry is
probably not sufficient to get robust behavior. This really does need
to look and act like a regular interface in terms of sending packets,
but one where most local reception is inhibited.
One way to avoid using proxy ARP/ND is to apply an ipfilter "block out"
rule implicitly for each virtual IP to help realize this "forward only" job.
That should work but it makes things a bit complicated. A non-accept
mode VRRP configuration needs to have dependency on ipfilter and the
auto-applied rules would be visible through ipf interface.
Opinions?
Yifan
_______________________________________________
networking-discuss mailing list
[email protected]
