Acee at al, Many thanks for your response. I do feel though that I should add a bit more of my reasoning for why I submitted this erratum.
RFC 5798 in section 8.3.2 (Recommendations Regarding Setting Priority Values) states: A priority value of 255 designates a particular router as the "IPvX address owner". Care must be taken not to configure more than one router on the link in this way for a single VRID. Routers with priority 255 will, as soon as they start up, preempt all lower-priority routers. No more than one router on the link is to be configured with priority 255, especially if preemption is set. RFC 9568 changes this to state: 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). My interpretation of this change is that RFC 9568 now explicitly permits, through the use of SHOULD rather than MUST, there to be more than one router with priority 255, and that it is therefore no longer a misconfiguration for more than one router to be configured with priority 255. In note though that section 5.2.4 (Priority) states that the address owner MUST use priority 255 and that backup routers MUST use priorities 1-254 and section 6.1 states that priority 255 is reserved for the router that owns the IPvX address and that 1-254 is available for backup routers. The use of "the" rather than "a" for "the address owner" and "the router than owns" does seem to infer that there can be only one router with priority 255. I had assumed that the change to section 8.3.2 was intentional, and therefore, in order to allow that to work, section 7.1 (which sets out the functions to be performed when a VRRP packet is received) which states "MUST verify ... the local router is not the IPvX address owner (Priority - 255)", and that if the check fails "the receiver MUST discard the packet" needs to be changed to allow a receiver with local priority 255 to receive and process VRRP packets. If on the other hand the requirement is that only one router has priority 255 then section 8.3.2 needs to be changed to revert to the previous position, or perhaps be stonger, and state that there MUST NOT be more than one router with priority 255. In any event, my understanding is that the requirement in section 7.1 to drop any received VRRP packet if the receiver has local priority 255 is not necessary, but merely a matter of efficiency. The actions specified in section 6.4.3 still work if they are processed by an address owner but have the added benefit that should there be two or more routers with priority 255, the tie-breaker based on primary IP address will stop them both being in active state simultaneously and continually. Perhaps 7.1 should be changed (especially since section 8.3.2 now appears to permit more than one router to have priority 255) to be that a router with local priority 255 MAY discard a received packet, rather than MUST, so that implementations can handle the situation of there being more than one router configured with priority 255 if they see that as beneficial, without that implementation then being non- conformant with the RFC. With many thanks, Quentin P.S. My understanding is the a Cisco VRRP implementation does not discard received VRRP packets when the local priority is 255 and uses the primary IP address tie-breaker to ensure that only one router is the active router; presumably that is non-compliant with section 7.1. On Wed, 2025-02-19 at 20:19 -0500, Acee Lindem wrote: > Hi Quentin, et al, > > I think this Errata should be rejected. Trying to handled a misconfiguration > rather than > logging it as an error is not an errata change but something that could be > proposed in a > draft (along with any other such proposed changes). > > Thanks, > Acee > > > On Feb 17, 2025, at 10:25, Quentin Armitage <quen...@armitage.org.uk> wrote: > > > > 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
