On Thu, Feb 12, 2026 at 2:14 PM Dumitru Ceara <[email protected]> wrote:
> On 2/11/26 10:37 AM, Ales Musil wrote: > > The RFC defines a Virtual Router Redundancy Protocol [0], in order > > for that protocol to work the workload might "spoof" MAC address > > within ARP or ND request/response. This wasn't allowed as the port > > security is specifically designed against spoofing and checks if > > the port security MAC address is the same for source of ARP/ND > > and the inner source/target address. To make the port security > > compliant add a special literal which when specified will allow > > user to add any/all MAC addresses defined by VRRPv3. The traffic > > from and to those additional MAC addresses will be allowed as > > well as permutations of ARP/ND inner MACs combined with the > > physical MAC as a source. > > > > [0] https://datatracker.ietf.org/doc/html/rfc9568 > > Reported-at: https://issues.redhat.com/browse/FDP-2979 > > Signed-off-by: Ales Musil <[email protected]> > > --- > > v4: Rebase on top of latest main. > > Update the RFC url. > > Add Jacob's ack. > > v5: Rebase on top of latest main. > > Address nits pointed out by Dumitru. > > Add extra test for invalid VRRPv3 MAC. > > Update the wording in documentation. > > Remove acks as the code changed. > > Do not populate flows for physical MAC when VRRP is specified. > > v6: Rebase on top of latest main. > > Update the documentation formatting. > > Update the behavior when masked portion of MAC is non-zero. > > Address some nits. > > Update testing. > > Remove all acks as the patch has changed. > > v7: Update the tests. > > Update the documentation according to Ilya's suggestion. > > v8: Rebase on top of latest main. > > Address nits. > > Adjust the test. > > --- > > Hi Ales, > > [...] > > > diff --git a/ovn-nb.xml b/ovn-nb.xml > > index aab091883..85ac7b61b 100644 > > --- a/ovn-nb.xml > > +++ b/ovn-nb.xml > > @@ -2057,6 +2057,23 @@ > > addresses within an element may be space or comma separated. > > </p> > > > > + <p> > > + Each element in the set also supports the special prefix > "VRRPv3" > > + that allows specification of single physical MAC and multiple > > + VRRPv3 MAC addresses. As for non VRRPv3 entries, multiple IP > > + addresses can be associated with the specified MACs. > "VRRPv3" with > > + a single physical MAC translates to allowing traffic for the > whole > > + "VRRPv3" range of MACs. See more in the examples. > > + > > + When the port security configuration entry contains the > VRRPv3 label, > > + the behavior for physical MAC (the first specified) is > different. > > + The installed flows will allow traffic from/to VRRP MACs + > IPs. > > + The physical MAC is there to properly allow ARP/ND with given > > + VRRP MACs. To allow traffic that is not related to virtual > router, > > + e.g., IP traffic with a physical MAC as a source, a regular > port > > + security entry should be added separately. > > + </p> > > + > > <p> > > This column is provided as a convenience to cloud management > systems, > > but all of the features that it implements can be implemented > as ACLs > > @@ -2102,6 +2119,44 @@ > > 255.255.255.255, and any address in 224.0.0.0/4. The host > may not > > send or receive any IPv6 (including IPv6 Neighbor > Discovery) traffic. > > </dd> > > + > > + <dt><code>"VRRPv3 <PHYSICAL_MAC>"</code></dt> > > + <dd> > > + The host may send ARP/ND packets with physical MAC as a > source and > > + any of the VRRPv3 MACs as inner SHA/TLL/SLL - > 00:00:5e:00:01:00/40 > > + for IPv4 and 00:00:5E:00:02:00/40 for IPv6. It may also > send or > > Nit: we're a bit inconsistent here, either both addresses should be > "00:00:5E..." or "00:00:5e". Probably the latter. > > > With this addressed and with Ilya's comments addressed I think we're > finally good: > > Acked-by: Dumitru Ceara <[email protected]> > > > + receive any traffic with any of VRRPv3 MAC addresses as a > source > > + or destination. But not with the physical MAC address. > > + </dd> > > + > > + <dt><code>"VRRPv3 <PHYSICAL_MAC></code> > > + <code><VRRPV3_MACv4_1>/[<MASK1>]</code> > > + <code><VRRPV3_MACv4_N></code> > > + <code><VRRPV3_MACv6_1>/[<MASK2>]</code> > > + <code><VRRPV3_MACv6_N>"</code></dt> > > + <dd> > > + Same as the previous example, but allowed VRRPv3 MAC > addresses are > > + limited to the specified ones. The specified VRRPv3 MAC > addresses > > + must have a correct prefix - 00:00:5e:00:01 for IPv4 and > > + 00:00:5e:00:02 for IPv6. VRRPv3 MACs can be provided with > a mask > > + with a prefix between /40 and /48. > > + </dd> > > + > > + <dt><code>"VRRPv3 <PHYSICAL_MAC></code> > > + <code><VRRPV3_MACv4_1>/[<MASK1>]</code> > > + <code><VRRPV3_MACv4_N></code> > > + <code><VRRPV3_MACv6_1>/[<MASK2>]</code> > > + <code><VRRPV3_MACv6_N></code> > > + <code><VRRPV3_IPv4_1>/[<MASK1>]</code> > > + <code><VRRPV3_IPv4_N></code> > > + <code><VRRPV3_IPv6_1>/[<MASK2>]</code> > > + <code><VRRPV3_IPv6_N>"</code></dt> > > + <dd> > > + The same as the previous example, but the provided IP > addresses > > + further restrict the inner IP for ARP/ND. As well as > IP/IPv6 > > + traffic to/from given VRRPv3 MACs. The IP address format > is the > > + same as for the regular port security entry. > > + </dd> > > </dl> > > </column> > > </group> > > Thanks, > Dumitru > > Thank you Ilya and Dumitru, I have addressed the remaining comments and merged this into main. Regards, Ales _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
