Subject: RE: [VRRP] comments on vrrp-ipv6-spec-04.txt

From: Radia Perlman <[email-masked]>
Date: Wed, 28 May 2003 16:45:41 -0700 (PDT)

How about having an additional tie breaker in addition to
the priority (e.g., the source address in the layer 2 header)?
I was also starting to worry about the behavior with two
routers that aren't priority 255, but they're both
the same priority. I don't have the spec handy (I'm offsite
at a meeting with not enough time to look up the spec), but
if I remember correctly, they will both defer, because it
says to defer if you see something with your priority or greater.

It seems like you could get into a situation where the two routers
"simultaneously" (perhaps because they are several bridge-hops away
from each other) issue advertisements, see the other side's ad,
and then shut off for the timeout interval, and then retry, again
simultaneously...

So it seems like if there were some tie breaker so one of them
would win (even in the priority=255 case), things would be safer.

Radia

	From: [email-masked]
		Re: vrrp behavior under misconfiguration scenarios
	
	the current vrrp behavior drops misconfigured Advertisement,
	which may trigger multiple Master.  for most failure scenario 
	the effect on the network ranges between no change in behavior or
	duplicated packets.  the effect on the end-user/end-host experience 
	is typically no change in behavior (i.e. connectivity is maintained).
	
	with a modified vrrp behavior to accept misconfigured
	Advertisement the failure scenarios effect on the network 
	ranges between no change in behavior or blackholed default router 
	addresses.  the effect on the end-user/end-host 
	experience may be no change or Internet loss of connectivity.
	
	my preference was for a high availability protocol to err 
	toward the failure state that typically maintains end-host 
	connectivity during the transient misconfiguration.  long 
	term neither failure mode is acceptable.  and my real hope 
	is that the specification properly mandates all error checks
	and notification requirements to alert the administrator and
	minimize these transient.
	_______________________________________________
	vrrp mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/vrrp

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

---

From: [email-masked]
Date: Wed, 28 May 2003 19:44:33 -0700

--- Radia Perlman <[email-masked]> wrote:

> How about having an additional tie breaker in
> addition to the priority (e.g., the source address 
> in the layer 2 header)?

the layer 2 source mac address for a vrid Advertisement
is always going to be identical.  independent of sender
it's the vmac.  :-(

the tie breaker is infact in place.  it's comparing 
the Advertisement source ip address and the receiving
interface ip address.  

the IPv4 (VRRPv2) 1.2 Definitions 
defined the 'Primary IP Address' per-interface as 
the ip address the router will use if it sends an 
Advertisement.  and 7.2 Transmitting VRRP Packets
mandates setting source ip address to interface
primary address.  then in the 6.4.3 Master state 
description it specifies tie breaker based on the 
Advertisement sender primary ip address (the vrrp
packet ip source address) and the local interface
primary ip address.

the IPv6 (VRRPv3) draft appears to assume use of a
single link-local ip address per-interface, so I guess 
it dropped the definition and use of term 'Primary IP 
Address'.  the 7.2 Transmitting VRRP Packets seems
fairly explicit in setting vrrp Advertisement ip source
to link-local IPv6 address.  I think the 6.4.3 Master
state description for the ip address based tie 
breaker could be made a bit more explicit in that
the 'IPv6 Address' mentioned are the vrrp Advertisement
source address and the receiving router link-local address.

danny

---

From: Gurudeep Kamat <[email-masked]>
Date: Thu, 29 May 2003 21:04:35 -0700 (PDT)

Hi,

While this topic is being discussed, there is probably
a simple change required to the VRRP algorithm to help
obtain deterministic convergence/pre-emption in the
equal priorities case.

The problem happens when then are two backups with
equal priorities, say A with higher IP address and B
with lower IP address. Pre-emption is turned on.

If B is already the master before A comes up, or B
manages to become a Master first and sends an
advertisement which reaches A.. before A transitions
to Master, then B will remain the master. Thus,
breaking the understanding that if backups have equal
priorities, then the backup with the higher interface
IP will become the Master.

This is because the interface IP has been considered
in the Master state handling, but not in the backup
state handling. 

When a VRRP router starts, it first goes to INIT mode
and from there to the BACKUP mode and then decides if
it has to transition to Master. Please see Page 16-17
of the RFC 2338 Section 6.4.2, the following lines of
the algorithm for the BACKUP to behave when it
receives an advertisement from the current master. 

   If Preempt_Mode is False, or If the Priority in the
ADVERTISEMENT is greater than or equal to the local
Priority, then:
   o Reset the Master_Down_Timer to
Master_Down_Interval

Thus, a backup if it hears an adverisement from the
current master with a greater or "EQUAL" priority, it
just keeps re-setting its Master_Down_Timer and
therefore the Master_Down_Timer never triggers and it
never pre-empts.

This part of the algorithm can be modified as follows,

(If Preempt_Mode is False), or
(If the Priority in the ADVERTISEMENT is greater than
the local priority),or
(If the Priority in the ADVERTISEMENT is equal to the
local Priority and the primary IP Address of the
sender is greater than the local primary IP
Address), then:
    o Reset the Master_Down_Timer to
Master_Down_Interval

In this case, if a new VRRP router comes up and hears
from the current master which has the same priority
but a lower IP Address, it will NOT reset its
Master_Down_Timer and thus after Master_Down_Interval
the timer will trigger and it will become the Master
and send an advertisement. The other router which has
the same priority but lower IP address will hear this
advertisement and will become the backup (This part is
correct in RFC 2338, Page: 18, Section 6.4.3). Thus a
backup with equal priority but Higher IP
address will pre-empt.

Thanks,
Gurudeep

> ----- Original Message ----- 
> From: <[email-masked]>
> To: "Radia Perlman" <[email-masked]>;
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, May 28, 2003 7:44 PM
> Subject: RE: [VRRP] comments on
> vrrp-ipv6-spec-04.txt
> 
> 

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: [email-masked]
Date: Fri, 30 May 2003 12:56:28 -0700

--- Gurudeep Kamat <[email-masked]> wrote:
>> However, it is a simple one line change and I believe 
>> can be considered at least for the Ipv6 version.

a bit of additional history I will add is that the original
development of the protocol processing rules did not overlook
this simple one line change.  that behavior was explicitly
rejected.  this is to provide support for:
> 2.3 Minimization of Unnecessary Service Disruptions
>   Once Master election has been performed then any unnecessary
>   transitions between Master and Backup routers can result in a
>   disruption in service.  The protocol should ensure after Master
>   election that no state transition is triggered by any Backup router
>   of equal or lower preference as long as the Master continues to
>   function properly.
and that behavior is further re-inforced in:
> 3.0 VRRP Overview
>   ... A Backup router will not
>   attempt to pre-empt the Master unless it has higher priority.  This
>   eliminates service disruption unless a more preferred path becomes
>   available. ...

all that being said I do agree with your statement that 
the working group can consider the change.  if a majority 
now prefer the convergence behvior you describe rather than 
the original 'minimize disruption' model then the protocol
behvior and associated supporting text should be updated.

danny