yifan writes: > James Carlson wrote: > There's another issue. The VRRP RFC states that the backup routers must > be configured to send the same Router Advertisement options as the > address owner. I think it makes no sense for VRRP to find some way to > sync the RA option setup between master and backups. Thus it should be > the router administrator who guarantees that the master and backups have > same setup on RA options. And ndpd.conf surely should be used for that.
Yes; that's what I think should be done. > >For what it's worth, the VRRP I-D that you're reading > >(vrrp-unified-spec) is weird in that it goes into extreme detail on > >IPv6 issues (section 8.2.2), but completely ignores the identical IPv4 > >issues. > > > > Isn't section 8.1.2 for corresponding IPv4 issues? It completely glosses over the issue. It doesn't address IPv4 RDISC at all (which is a subset of IPv6's RA mechanism), nor does it address the more general issue of router-to-host communication or why some things are "in" the list and some things are "out." The actual issue here is that in order to be a competent router, you need to continue advertising the information that the hosts on your network need. If that means advertising RIP, then that has to be done. If it means sending RDISC messages, then that's included. What you must not do (for routing purposes) is impersonate the address owner. So, for example, responding to SNMP messages sent to the virtual IP address in any way would be an error. It'd be an error because the non-owner doesn't have the same context, and the client sending those requests would end up with a confused mess if a fail-over happened in the middle of a MIB walk. I think section 8.1 is essentially defective. > >I think it's necessary to take it with a grain of salt. > > > >(I'll see if I can't get clarification from the author.) There seems to be a big discussion about Accept_Mode on the [EMAIL PROTECTED] mailing list. If you're not monitoring that list now, you probably should be. > >That's one possibility. Another might be to put the existing > >IFF_NOLOCAL flag to some good use or invent a new interface flag. > > > > To make it work, in addition to using an interface flag to block all > traffic on link layer for backup state, there must be another filter on > IP layer to do the "forward only" job for master state. Yes. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
