On Mon, Jan 26, 2026 at 5:56 PM Ilya Maximets <[email protected]> wrote:

> On 1/26/26 3:00 PM, Ales Musil via dev 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 an option which when enabled will add extra flows
> > that match on the MAC specified by the option (within the range)
> > or any MACs.
> >
> > [0] https://datatracker.ietf.org/doc/html/rfc5798
> > Reported-at: https://issues.redhat.com/browse/FDP-2979
> > Signed-off-by: Ales Musil <[email protected]>
> > ---
> > v2: Rebase on top of latest main.
> >     Add missing checks in the test.
> >     Rename the option to "port-security-allow-vrrpv3-arp-nd".
> >     Allow the list of MACs to be specified in the option.
>
> I don't think we finished the discussion on v1, and it seems like
> v2 is taking the "worst of both worlds" approach when it comes to
> user experience, i.e. having a very long option name and also
> forcing to specify all the MAC addresses twice.  Why can't we just
> allow all the specified MAC addresses and not require listing them
> again in the port_security column?
>

I disagree, as stated on v1 there is a way for user to define which MAC
is allowed for regular traffic via port_security. The only case where it
doesn't work is mixing port_security MAC and VRRPv3 inner MAC of
arp/nd. Adding another option that does the same thing as port_security
and in addition to that allows the inner MAC to be different doesn't seem
any better. I would argue that it makes it even more confusing. So it
seems we have reached an impasse.


> Best regards, Ilya Maximets.
>
>
Regards,
Ales
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to