On 1/29/26 7:36 AM, Ales Musil wrote: > On Tue, Jan 27, 2026 at 7:47 PM Ilya Maximets <[email protected]> wrote: > >> On 1/27/26 2:49 PM, Dumitru Ceara wrote: >>> On 1/27/26 2:28 PM, Ilya Maximets wrote: >>>> On 1/27/26 2:21 PM, Dumitru Ceara wrote: >>>>> On 1/27/26 2:07 PM, Ilya Maximets wrote: >>>>>> On 1/27/26 1:29 PM, Dumitru Ceara wrote: >>>>>>> On 1/27/26 12:54 PM, Ilya Maximets wrote: >>>>>>>> On 1/27/26 10:44 AM, Dumitru Ceara wrote: >>>>>>>>> Hi Ales, Ilya, >>>>>>>>> >>>>>>>>> On 1/27/26 7:27 AM, Ales Musil via dev wrote: >>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> Just for tracking, the v1 discussion: >>>>>>>>> >>>>>>>>> >> https://www.mail-archive.com/[email protected]/msg100992.html >>>>>>>>> >>>>>>>>>>> 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? >>>>>>>>>>> >>>>>>>>> >>>>>>>>> One thing we didn't discuss on-list until now, which makes me favor >>>>>>>>> Ales' v2 proposal is: >>>>>>>>> >>>>>>>>> If we allow all the specified MAC addresses and don't require >> listing >>>>>>>>> them again in the port_security column, then with the following >>>>>>>>> configuration: >>>>>>>>> >>>>>>>>> - port_security=[<physical-MAC>] >>>>>>>>> - port-security-allow-vrrpv3=[<VRRP-MAC1>, <VRRP-MAC2>] >>>>>>>>> >>>>>>>>> we would: >>>>>>>>> a. allow traffic from <physical-MAC> >>>>>>>>> b. allow ARPs with eth.src=<physical-MAC> && arp.sha=<physical-MAC> >>>>>>>>> (same for ND) >>>>>>>>> c. allow traffic from <VRRP-MAC1> and <VRRP-MAC2> >>>>>>>>> d. allow ARPs with eth.src=<physical-MAC> && arp.sha=<VRRP-MAC1> >>>>>>>>> and ARPs with eth.src=<physical-MAC> && arp.sha=<VRRP-MAC2> >>>>>>>>> (same for ND) >>>>>>>>> >>>>>>>>> However, if we look at the non-VRRP case, users can rely on >>>>>>>>> port_security today to further restrict the traffic they allow on >>>>>>>>> a logical port by also specifying a list of allowed IP addresses >>>>>>>>> (or CIDRs) for each mac. That is, if: >>>>>>>>> >>>>>>>>> port_security=["<physical-MAC1> IP1 IP2", "<physical-MAC2> IP3 >> IP4"] >>>>>>>>> >>>>>>>>> Then for that LSP traffic is allowed only if it's from/for >>>>>>>>> <physical-MAC1> _and_ one of IP1 or IP2 OR if it's from/for >>>>>>>>> <physical-MAC2> _and_ one of IP3 or IP4. >>>>>>>>> >>>>>>>>> Back to the VRRP case, if we go with Ilya's suggestion, if users >>>>>>>>> also want to further restrict port security to only allow the VRRP >>>>>>>>> VIP for a given VRID the only way to achieve that would be: >>>>>>>>> >>>>>>>>> - port_security=["<physical-MAC>", "<VRRP-MAC1> VIP1", >> "<VRRP-MAC2> VIP2"] >>>>>>>>> - port-security-allow-vrrpv3=[<VRRP-MAC1>, <VRRP-MAC2>] >>>>>>>> >>>>>>>> But this will not allow actual routing, i.e. this will only allow >> the >>>>>>>> virtual router to route packets between VIP1 and VIP2. Is that a >> common >>>>>>>> or desired configuration? It's practically a router for two IPs >> that >>>>>>>> belong to that same router...? >>>>>>>> >>>>>>> >>>>>>> That's a good point, I was stuck in my "traditional" OVN view of >> things. >>>>>>> >>>>>>> In this case the VRRP VR is probably the gateway (for some of the >> other >>>>>>> LSPs in the switch) so it wouldn't really make sense to configure the >>>>>>> VIP into port_security, just the VRRP mac, as it's valid to accept >>>>>>> packets with destIP == "external" and dmac == "VRRP-MAC". >>>>>>> >>>>>>>>> So users would still have to duplicate the VRRP MACs in some of the >>>>>>>>> cases. I don't have stats about it but my guess is in most >> deployments >>>>>>>>> port security usually includes both the MACs and the IPs of the >> workloads. >>>>>>>> >>>>>>>> If that's the case then we should not introduce the new option at >> all, >>>>>>>> but allow multiple MAC addresses within the port_security record, so >>>>>>>> OVN can generate rules for permutations of these MAC addresses with >> the >>>>>>>> corresponding IP addresses. For simplicity, we may restrict the >> number >>>>>>>> of addresses to some fairly small number or allow masking. This >>>>>>>> will be the most versatile and user-friendly configuration as no new >>>>>>>> knobs will be required, no duplication, and the option will also not >>>>>>>> be tied to VRRP, so can be re-purposed for other things, >> potentially. >>>>>>>> >>>>>>> >>>>>>> So, to clarify, your suggestion is to change allowed values for >>>>>>> port_security to be a list of: >>>>>>> "MAC1 MAC2 .. MAC_N IP1 IP2 .. IP_M" >>>>>>> >>>>>>> vs the current: >>>>>>> >>>>>>> "MAC1 IP1 IP2 .. IP_M" >>>>>>> >>>>>>> right? >>>>>> >>>>>> Right. >>>>>> >>>>>>> >>>>>>> And generate port security flows that allow: >>>>>>> - IP packets to/from MAC-X,IP-Y where X=[1..N], Y=[1..M] >>>>>>> - ARP packets with eth.src=MAC-X,ARP.sha=MAC-Y,ARP.spa=IP-Z where >>>>>>> X=[1..N], Y=[1..N], Z=[1..M] >>>>>>> - ND packets too as above >>>>>>> >>>>>>> So 2 x M x N ^ 2 + M x N flows. >>>>>>> >>>>>>> I guess that's doable and up to the user to not add too many mac >> addresses. >>>>>> >>>>>> With the port-security-allow-vrrpv3-arp-nd="MAC1 MAC2 .. MAC_N" >>>>>> we also need the port-security=["MACX IP1 IP2 .. IP_M", >>>>>> "MAC1 IP1 IP2 .. IP_M", >>>>>> "MAC2 IP1 IP2 .. IP_M", >>>>>> ... >>>>>> "MAC_N IP1 IP2 .. IP_M"] >>>>>> >>>>>> in order to allow the actual routed traffic, which is >>>>>> >>>>>> - N x M just for port security itself. >>>>>> - M x N ^ 2 for the ARP/ND >>>>>> >>>>>> Which is exactly the same as with the multiple MACs in the same >>>>> >>>>> True. >>>>> >>>>>> port security record, but with a huge pile of extra repeated >>>>>> configuration in the database. We also have no control over >>>>>> the MACs in different port security records, so it's harder to >>>>>> find duplicates, which is important as only the half of these >>>>>> flows will be unique. >>>>>> >>>>>> Note: these IPs are IPs of the other LSPs from which this VR >>>>>> is routing the traffic, i.e. the traffic source. If we consider >>>>> >>>>> Maybe I'm misunderstanding what you're saying here but that's not how >>>>> port_security works, it's not an ACL, it should contain addresses (MACs >>>>> and IPs) owned by the LSP it's applied on. >>>> >>>> Routers route traffic from someone else. It means that traffic >>>> that enters OVN from this LSP will have someone else's source IP. >>>> If this IP is not in the port security configuration, the packet >>>> will be dropped. Or am I missing something? >>>> >>> >>> Ah, so it's actually traffic coming from "outside" the vrouter, towards >>> other LSPs that would have this issue. Because from OVN perspective >>> it's traffic originating from the vrouter LSP. >>> >>> But in that case it would be a wide range of IPs that would have to be >>> allowed as "source". So probably in practice we'd no see this being >> used. >>> >>>>> >>>>>> that source traffic IPs do not overlap between VRIDs, then the >>>>>> config becomes simpler, but the same is true for the multiple >>>>>> MAC in the same port-security option, it will become: >>>>>> "MAC_PHY MAC_V1 IP_SET_1", "MAC_PHY MAC_V1 IP_SET_2". We'll >>>>>> be repeating the MAC_PHY here, but it doesn't seem too bad in >>>>>> comparison with the v2 option. >>>>>> >>>>>>> >>>>>>> But it will also be hard to implement the "any VRRP MAC" semantics >> and >>>>>>> users will have to add 512 MACs if they want that behavior. Which >>>>>>> would mean that, in order to have this generic solution, we'd >> probably >>>>>>> need to allow masked MACs, something like: >>>>>>> >>>>>>> "MAC1/mask1 MAC2/mask2 .. MAC_N/mask_N IP1 IP2 .. IP_M" >>>>>>> >>>>>>> Which becomes very complex very quickly IMO (if I try to put myself >> in >>>>>>> the shoes of a user). >>>>>> >>>>>> If we use prefixes instead of arbitrary masks, /40 doesn't seem >>>>>> too complicated. >>>>>> >>>>> >>>>> Sure, for VRRP MACs it's a relatively easy to read: >>>>> 00:00:5E:00:00:00/40 >>>>> >>>>> But in general, this can be any MAC and prefix, e.g.: >>>>> 00:00:12:34:56:78/33 >>>>> >>>>> which is incorrect actually, it should be (I think): >>>>> 00:00:12:34:00:00/33 >>>>> >>>>> Which makes me step back and think about what we're trying to fix here: >>>>> the problem that triggered this long discussion is the fact that VRRP >>>>> ARPs use the physical MAC as ethernet source and the virtual mac as ARP >>>>> source and port security didn't allow that. >>>>> >>>>> So it really feels to me like we're over-engineering at this point. >>>>> >>>>> I know new knobs are not nice, and it would be a very specific VRRP >> knob >>>>> but it really feels to me like the alternatives are a bit of >>>>> over-engineering at this point. >>>> >>>> That's why the original proposal was to just have a simple knob that >>>> allows all VRRP and the routed traffic, i.e. port-security-allow-vrrpv3. >>>> That is simple, targeted, and doesn't force users to put a ton of >>>> duplicated addresses into the port security. >>>> >>> >>> But that did mean, adding implicit port_security rules for VRRP routed >>> traffic and VRRP ARPs, duplicating what port_security does for the >>> former, just that it would be for all VRRP macs (or for a subset >>> specified by MAC/ID). >>> >>> So it still feels to me like the config duplication (most likely in >>> practice we won't have more than a handful of VRRP MACs) is not such a >>> huge compromise as it doesn't "hide" some port security rules. >>> >>> I know internally we had a discussion about the statement in our docs >>> saying that port security is "a convenience to cloud management systems, >>> but all of the features that it implements can be implemented as ACLs". >>> >>> Implementing your suggestion would create another (in lack of a better >>> term) layer of abstraction. I.e., the users reading the config: >>> >>> port_security=[MAC1 MAC2] >>> port-security-allow-vrrpv3=[VRRP-MAC1/yes] >>> >>> would have to interpret it as: >>> >>> "allow traffic from this LSP only if: >>> - it originates from MAC1 or MAC2 or VRRP-MAC1 if it's plain IP >>> - it originates from MAC1 or MAC2 and it's an ARP with SHA=VRRP-MAC1 >>> >>> allow traffic to this LSP only if >>> - it's destined to MAC1 or MAC2 or VRRP-MAC2 if it's plain IP" >>> >>> Which is, aside from the duplication of config, exactly the same >>> behavior as proposed by this v2 patch. >> >> The behavior is not the argument from my side. I'm just trying to argue >> for a better UX, i.e. easier to understand configuration. >> >> Both 'port-security-allow-vrrpv3' and the >> 'port-security-allow-vrrpv3-arp-nd' >> are modifiers applied to the port security, which require extra >> understanding. >> In other words, just looking at the port security, user can't have a full >> picture of what is allowed and what is not and will have to do the mental >> math to map things onto each other in different combinations, as both >> options >> will affect every port security entry separately. >> >> The mutli-MAC port security syntax approach ("MAC1 MACN IP1 IPN") has an >> advantage of keeping everything in the same place, so if you look at port >> security, you know what it allows. >> >> The exact syntax may be a bit convoluted and may use some work, I agree. >> >> For example, in practice, I'm not sure we'll need more than one "physical" >> MAC, so having an option to allow multiple MACs generically is probably not >> necessary. We could come up with a distinct syntax for VRRP-allowed port >> security, e.g. >> "VRRPv3 <MAC_PHY> <VRRP_MAC1> <VRRP_NET/plen> <IP_1> <IP_NET/plen>". >> This would mean: >> >> 1. Allow IP traffic from VRRP_MAC1 or VRRP_NET/plen + IP_1 or IP_NET/plen. >> 2. Allow ARP from MAC_PHY with VRRP_MAC1 or VRRP_NET/plen as SHA and >> IP_1 or IP_NET/plen as SIP. >> >> No inter-operation or side effects on other entries within port-security >> column on the same port. >> >> The "any v4" config would look like: >> >> port-security=["02:12:34:56:78:9a 192.168.1.2", >> "VRRPv3 02:12:34:56:78:9a 00:00:5e:00:01:00/40"] >> >> We may also omit the masked MAC address meaning "any", e.g. >> >> port-security=["02:12:34:56:78:9a 192.168.1.2", >> "VRRPv3 02:12:34:56:78:9a"] >> >> IMO, seems more clear what it does, and no mental math required. >> >> If we want to restrict the VR to only some particular networks: >> >> port-security=[ >> "02:12:34:56:78:9a 192.168.1.2", >> "VRRPv3 02:12:34:56:78:9a 00:00:5e:00:01:00/40 192.168.1.0/24 >> 10.10.0.0/16"] >> >> This would allow forwarding between internal subnet 192.168.1.0/24 and >> some external subnet 10.10.0.0/16. Though, as you mentioned, it seems >> like not a particularly useful restriction to apply as the external >> traffic subnet would likely need to be pretty large. >> >> WDYT? >> >> >> Summarizing all proposals with configuration that allows all the >> required types of traffic, including ARP, normal IP, and routed IP: >> >> 1. "arp-nd option" (I added /40 syntax to avoid listing all 255 MACs). >> >> - Any VRID: >> port-security-allow-vrrpv3-arp-nd="any" >> port-security=["MAC-PHY", "VRRP-v4MAC/40", "VRRP-v6MAC/40"] >> >> - 2 VRID, Any IP: >> port-security-allow-vrrpv3-arp-nd="VRRP-MAC1 VRRP-MAC2" >> port-security=["MAC-PHY", "VRRP-MAC1", "VRRP-MAC2"] >> >> - 2 VRID, Specific IPs: >> port-security-allow-vrrpv3-arp-nd="VRRP-MAC1 VRRP-MAC2" >> port-security=["MAC-PHY", "VRRP-MAC1 IPs-1", "VRRP-MAC2 IPs-2"] >> >> >> 2. "full allow-vrrp". >> >> - Any VRID: >> port-security-allow-vrrpv3=["any"] >> port-security=["MAC-PHY"] >> >> - 2 VRID, Any IP: >> port-security-allow-vrrpv3=["VRRP-MAC1", "VRRP-MAC2"] >> port-security=["MAC-PHY"] >> >> - 2 VRID, Specific IPs: >> port-security-allow-vrrpv3=["VRRP-MAC1 IPs-1", "VRRP-MAC2 IPs-2"] >> port-security=["MAC-PHY"] >> >> >> 3. "multi-MAC port-security". >> >> - Any VRID: >> port-security=["MAC-PHY VRRP-v4MAC/40 VRRP-v6MAC/40"] >> >> - 2 VRID, Any IP: >> port-security=["MAC-PHY VRRP-MAC1", "MAC-PHY VRRP-MAC2"] >> >> - 2 VRID, Specific IPs: >> port-security=["MAC-PHY VRRP-MAC1 IPs-1", "MAC-PHY VRRP-MAC2 IPs-2"] >> >> >> 4. "VRRP-specific port-security". >> >> - Any VRID: >> port-security=["MAC-PHY", "VRRPv3 MAC-PHY"] >> >> - 2 VRID, Any IP: >> port-security=["MAC-PHY", >> "VRRPv3 MAC-PHY VRRP-MAC1 VRRP-MAC2"] >> >> - 2 VRID, Specific IPs: >> port-security=["MAC-PHY", >> "VRRPv3 MAC-PHY VRRP-MAC1 IPs-1", >> "VRRPv3 MAC-PHY VRRP-MAC2 IPs-2"] >>
Thanks for summarizing this Ilya! >> >> My preference here is 4, as it is explicit and the least verbose >> for a simple config and still fairly simple for the complex case. >> It also tells the full store in a single place with no mental math >> required. >> >> Next in priotity would be 2, as it is the most concise. Then 3 >> and then 1. Note that 1 is not really what this patch is proposing >> as it also adds prefix matches on MAC addresses. >> >> For the implementation complexity point raised by Ales, it feels >> like the option 4 should not be hard to implement as a fairly >> standalone thing, as it doesn't impose side effects on any other >> port security entries. >> >> Best regards, Ilya Maximets. >> >> > Based on the discussion I will attempt to make the version 4 > work in v3. Let's see how it goes. > I agree, version 4 seems the way forward now. > Thanks, > Ales > Regards, Dumitru _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
