[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-vrrp
Subject:    Re: [VRRP] Scope of Valid VRRP Configurations
From:       "M. T. Hollinger" <myth () ucx ! lkg ! dec ! com>
Date:       2003-11-13 6:38:58
Message-ID: 008701c3a9c2$b4771b00$b6308182 () PORTABRAIN
[Download RAW message or body]

Since nobody has yet taken the bait and responded to the question I posted
Tuesday about Rtr0 being the primary master for multiple VRID's, I thought I
would send out some additional thoughts of my own on the same topic.

Again, I would clarify "may participate in one or more virtual routers"; can
a router participate as "IPv6 address owner" in more than one VR on a given
interface?  Note that a unique IPv6 address must be assigned to each, which
is fine because an IPv6 node can certainly own multiple addresses.

Partly for that reason, I would favor always assigning a unique IPv6 address
for each VRID, at least as an option, rather than overloading a link-local
address previously held by one of the participating routers.

I suggest clarifying the meaning of "IPv6 address owner" when multiple IP
addresses are used.  The current definition says, "the VRRP router that has
the virtual router's IPv6 address as real interface address," but that seems
to reflect an overly limited view.  Later in the existing document, a
parenthetical explanation says, "the local router is not the IPv6 Address
owner (Priority equals 255 (decimal))," which seems to me a better
definition.  However, if that's the definition, why not say so up front, in
the Definitions section?

We may wish to add clarifying text like:

    A priority value of 255 designates a particular rotuer
    as the "IPv6 address owner".  Care must be taken not
    to configure more than one router on the link in this
    way for a single VRID.

Perhaps in the same section, the text could also say:

    When there are multiple Backup Routers, their priority
    values should be uniformly distributed.  For example,
    if one BR has the default priority of 100 and another
    BR is added, a priority of 50 would be a better choice
    for it than 99 or 100 to facilitate faster convergence.

This clarification might be useful to dispel any notion that because the
protocol includes a provision for a tie-breaker, configuring multiple
routers with the same priority value is a good idea.  Taking the defaults,
someone setting up a Master Router and two BR's might leave the MR's
priority at 255 and both BR's at 100.  Oops.  They will then both have the
same Skew_Time, and both will try to grab control at the same instant
following a failure of the old Master.

Alternatively, the new claryifying text might say:

    Priority values SHOULD NOT be equal for two or more
    participating routers and SHOULD differ by at least 10.

We could also clarify, in the equal priority tie-breaking case, to use the
sender's address from the IP header -- not the IP address field in the VRRP
packet, which would be the one associated with the VRID in question, the
same for both participating routers.  Looking at the IP header will require
more cross-layer communication than some router implementations may offer,
but it's the only way to make the tie-breaker work.

The draft says, "It may be useful to support an override of the immediate
convergence to the preferred path," but then goes on to define a protocol
where the "IPv6 address owner" always preempts the current Master, even if
preemption is disabled.  If we expect that many deployments will be limited
to a single Backup Router, doesn't that make the preemption setting pretty
useless?

Building on my earlier observation that the notion of which router "owns" an
IPv6 address is rather arbitrary, I would propose a tweak to the design and
say:

    Routers with priority 255 will, as soon as they start up,
    preempt all lower priority routers.  Configure no more than
    one router on the link with priority 255.  If no router has
    this priority, and preemption is disabled, then no
    preemption will occur.

OK, so where would these new addresses come from?  One option might be to
use, by default, an IPv6 link-local address from a range reserved for VRRP
(much as the current draft does for the MAC address).  This would serve as a
convenient flag for troubleshooting purposes that VRRP is in use, but the
big win would be ease of configuration.  Rather than having to type in a
VRID number and a big long IPv6 address, you could just type in the VRID
number and take the associated default address.  Since it's so easy to make
a typo while entering an IPv6 address, we could avoid a lot of configuration
errors by generating the address automatically.

Duplicate Address Detection could even help to contain problems arising from
misconfigurations where, for example, two routers with prio=255 are
inadvertently connected to the same link, because they would be trying to
use the same IPv6 address.  We would probably want to disable DAD during
failover (upon transition from Backup to Master state) for performance
reasons, but it would be great to use at startup (transition from Initialize
to Master).

Another interesting option would be Cryptographically Generated Addresses,
as proposed in the SEND WG.  At some point, VRRP routers will probably need
to participate in secure neighbor discovery, and being able to generate and
share CGA's among participating routers may come in handy.  It's too early
to say exactly how that will work, and I certainly wouldn't advocate
delaying this nearly-complete VRRP work on the basis of early work in
another group.  However, leaving some latitude in this document around how a
network administrator might choose to allocate an IPv6 address for each VRRP
router sounds like a good idea and should not delay our progress.

           - M


_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp



[prev in list] [next in list] [prev in thread] [next in thread]