Further to the following, section 8.3.2 explicitly allows there to be more than one VRRP router to be configured with priority 255, by virtue of the use of SHOULD rather than MUST):
8.3.2. Recommendations Regarding Setting Priority Values A priority value of 255 designates a particular router as the "IPvX address owner" for the VRID. VRRP Routers with priority 255 will, as soon as they start up, preempt all lower- priority routers. For a VRID, only a single VRRP Router on the link SHOULD be configured with priority 255. If multiple VRRP Routers advertising priority 255 are detected, the condition SHOULD be logged (subject to rate-limiting). With apologies for not including this in the original report. Quentin Armitage On Mon, 2025-02-17 at 06:05 -0800, RFC Errata System wrote: > The following errata report has been submitted for RFC9568, > "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid8298 > > -------------------------------------- > Type: Technical > Reported by: Quentin Armitage <quen...@armitage.org.uk> > > Section: 7.1 > > Original Text > ------------- > It MUST verify that the VRID is configured on the receiving > interface and the local router is not the IPvX address owner > (Priority = 255 (decimal)). > > If any one of the above checks fails, the receiver MUST discard the > packet, SHOULD log the event (subject to rate-limiting), and MAY > indicate via network management that an error occurred. > > Corrected Text > -------------- > It MUST verify that the VRID is configured on the receiving > interface. > > If any one of the above checks fails, the receiver MUST discard the > packet, SHOULD log the event (subject to rate-limiting), and MAY > indicate via network management that an error occurred. > > It SHOULD verify that the local router is not the IPvX address owner > (Priority = 255 (decimal)) and log the event (subject to > rate-limiting) and MAY indicate via network management that a > misconfiguration was detected. > > Notes > ----- > Although it is clearly a configuration error, if two (or more) VRRP routers > are configured > as the address owner for the same VRID, if received VRRP packets are just > dropped (as > specified in section 7.1), all such routers will remain in Active state, will > continue > sending VRRP adverts, and will respond to ARP/ND requests. This will make > communication > with any VIP unachievable, or at best unreliable. > > If the VRRP packets are not dropped, but processed in the normal way, in > section 6.4.3 - > "Active", following "If an ADVERTISEMENT is received", then: > . If the Priority in the ADVERTISEMENT is greater than the > local Priority or the Priority in the ADVERTISEMENT is equal > to the local Priority and the primary IPvX address of the > sender is greater than the local primary IPvX address (based > on an unsigned integer comparison of the IPvX addresses in > network byte order), then: > ... > Transition to the {Backup} state > > will cause all except one of the VRRP routers to revert to Backup state, and > the VRRP > instance will be stable. > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC9568 (draft-ietf-rtgwg-vrrp-rfc5798bis-18) > -------------------------------------- > Title : Virtual Router Redundancy Protocol (VRRP) Version 3 for > IPv4 and > IPv6 > Publication Date : April 2024 > Author(s) : A. Lindem, A. Dogra > Category : PROPOSED STANDARD > Source : Routing Area Working Group > Stream : IETF > Verifying Party : IESG _______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
