Subject: Re: [VRRP] newbie vrrp question

From: "M. T. Hollinger" <[email-masked]>
Date: Thu, 13 Nov 2003 23:27:21 -0500

At today's meeting, we discussed this thread and, I believe, achieved a
resolution.  Still, since I'd already written up a paragraph further
explaining why I think routers should accept and respond to packets like
pings (er, ICMP ECHO_REQUESTs) even if they don't have priority 255, here it
is:

I think it's presumptuous for us to assume that the network administrator
will want alarms going off the entire time the "IPv6 address owner" is
unavailable.  VRRP provides 255 priorities, suggesting that there might be
more than one Backup Router available for a single VRID.  Since there may be
several BR's available, and it may take several days to get the main router
back online after a hardware failure, I believe the current Master should go
ahead and respond to pings.  Also, it should respond to SNMP queries because
the person wishing to query the router may know only the IPv6 address of the
virtual router.  If the current Master is not the "address owner", it could
take a lot of work to figure out the non-VRRP link-local address of the
Master.

Today, Bob Hinden (the document author) commented that he has seen
implementations which do respond, and it doesn't seem to break VRRP.  I
expect this behavior in some implementations will be a configuration
parameter.  There seemed to be consensus to weaken the "MUST NOT" language
in the current draft, and Bob agreed to update the next revision of the
draft to reflect that decision.

            - M

_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "Don Provan" <[email-masked]>
Date: Fri, 14 Nov 2003 10:08:18 -0800

Mr. Hollinger and I have been having a "spirited debate" about
this topic offline, but I don't think we need to hash over it
here. But I did want to mention that it has brought up an
interesting disagreement about what a network manager wants to
see. In a nutshell, I've been contending that a network manager
is more interested in the state of his individual components,
while Mr. Hollinger believes the network manager mainly wants
to know what services are working with individual component
status being secondary.

Anyway, I'm OK with softening the MUST NOT about responding
to non-owner VR addresses. (Since my implementation does
actually respond, it would be somewhat hypocritical for me
to not support that.) But I'd like to request that this be
accompanied by a clear statement of why it is advantageous
for non-owners to not respond and what is given up when they
do.

What? Oh, dang, you're right. OK....

I started with the explanation Bob sent out a couple of weeks ago
in response to the original question, reworded and expanded it a
little to come up with this as an initial proposal:

"Master routers that do not own the VR address SHOULD NOT accept
packets addressed to the IP address of the owner. This makes it easier
to detect that one of the routers is down. Historically, redundancy
protocols that did not have the behavior have made it difficult for
network management systems detect that one of the routers had failed
because the IP address still responded to pings, SNMP queries, etc.
Routing protocols can also be confused if an address jumps from one
physical router to another. The desired behavior when one of the
routers fails is to have user traffic keep flowing, but to have all
network management bells start ringing.

"A router which respond to VR addresses they do not own make it
easier for end nodes to discover whether the routing service is
available, but at the expense of being able to discover the state
of the individual components."

Alas, the documents don't really leave a good place for this to
be added, so I'll leave that to people with more experience at
spec layout.

-don

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of M. T.
> Hollinger
> Sent: Thursday, November 13, 2003 8:27 PM
> To: [email-masked]
> Subject: Re: [VRRP] newbie vrrp question
>
>