On 7/29/25 12:22 PM, Dumitru Ceara wrote:
> On 7/28/25 10:19 PM, Han Zhou wrote:
>> On Mon, Jul 28, 2025 at 8:30 AM Ilya Maximets <i.maxim...@ovn.org> wrote:
>>>
>
> Hi Ilya, Han,
>
>>> OVN routers are configured to drop any traffic with a destination
>>> being one of the Reserved Multicast Addresses (RFC 4291).
>>>
>>> This is done by matching on all the bits of ipv6.dst, except for bits
>>> 112-116 that cover all the addresses. Once installed into OVS, this
>>> turns into a following match:
>>>
>>> ipv6_dst=ff00::/fff0:ffff:ffff:ffff:ffff:ffff:ffff:ffff
>>>
>>> We fixed a large chunk of IPv6 datapath flow explosion issues by
>>> turning on prefix tacking in the flow classifier in OVS in commit
>>> 89e43f7528b0 ("controller: Fix IPv6 dp flow explosion by setting flow
>>> table prefixes."). However, prefix tracking doesn't work for masks
>>> that are not contiguous. That means that if a packet reaches a
>>> classifier subtable with non-contiguous mask, all the bits of that
>>> mask will be un-wildcarded. It's not a huge problem in a general case,
>>> because most non-contiguous masks would typically match on just a few
>>> bits. But ip6.mcast_rsvd is matching on 124 bits, un-wildcarding them
>>> for most of the IPv6 traffic traversing a router and causing creation
>>> of a separate exact-match datapath flow per destination IP.
>>>
>>> For setups that handle large amount of traffic from many different
>>> external addresses this issue makes IPv6 handling significantly harder
>>> than IPv4, causing much higher load on the datapath with potential
>>> overflow of datapath flow tables and a subsequent upcall storm.
>>> Even without the overflow, OVS spends a lot of time revalidating all
>>> these datapath flows burning CPU cycles.
>>>
>>> In general, since the number of external IP addresses is virtually
>>> unlimited, there should be no configuration where OVN exact-matches
>>> them, otherwise it will be a significant datapath scaling issue.
>>>
>>> Fix that by replacing a non-contiguous bit-match with a match on an
>>> address set where all the reserved multicast addresses are just listed
>>> directly. There are only 16 of them, so this should not be a huge
>>> problem to have extra 15 OpenFlow rules per router, but it will allow
>>> OVS to use prefix tracking for these flows and avoid creating separate
>>> datapath flow per destination IP.
>>>
>>> Also adding a simple lsp-to-external routing test case to make sure
>>> we don't have exact matches in this simple common use case.
>>>
>>> The OVS classifier can likely be improved to handle non-contiguous
>>> masks better, but it's not how the prefix tracking is designed, so
>>> it's not a simple task.
>>>
>>> Fixes: 677a3ba4d66b ("ovn: Add MLD support.")
>>> Reported-at: https://issues.redhat.com/browse/FDP-1557
>>> Signed-off-by: Ilya Maximets <i.maxim...@ovn.org>
>>> ---
>>> lib/logical-fields.c | 8 ++-
>>> tests/ovn.at | 151 +++++++++++++++++++++++++++++++++++++++++++
>>> 2 files changed, 157 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/lib/logical-fields.c b/lib/logical-fields.c
>>> index e479a78c1..f19eb579b 100644
>>> --- a/lib/logical-fields.c
>>> +++ b/lib/logical-fields.c
>>> @@ -266,8 +266,12 @@ ovn_init_symtab(struct shash *symtab)
>>>
>>> /* Predefined IPv6 multicast groups (RFC 4291, 2.7.1). */
>>> expr_symtab_add_predicate(symtab, "ip6.mcast_rsvd",
>>> - "ip6.dst[116..127] == 0xff0 && "
>>> - "ip6.dst[0..111] == 0x0");
>>> + "ip6.dst == { "
>>> + "ff00::0, ff01::0, ff02::0, ff03::0, "
>>> + "ff04::0, ff05::0, ff06::0, ff07::0, "
>>> + "ff08::0, ff09::0, ff0a::0, ff0b::0, "
>>> + "ff0c::0, ff0d::0, ff0e::0, ff0f::0 "
>>> + "}");
>
> These are functionally equivalent and, playing devil's advocate a bit,
> it's extremely hard to prevent suboptimal matches to be added by OVN
> developers without having a very deep understanding of how the OVS
> clasifier works.
>
> I'm not sure how we can improve the developer experience, to be honest.
> Do you have any ideas by any chance?
The best idea I have is adding tests for at least some basic topologies,
which I did in this patch. That will at least prevent re-introducing
similar issues in the future. I tried to make the test more general so
it covers the use-case pattern and not the particular issue.
We can add more tests like this one, but I'm not sure how to solve the
problem of developer experience in general. As in any sufficiently
complex systems, there will always be some pitfalls and quirks that can
only be a sort of tribal knowledge or at most documented in some way,
which doesn't really solve the problem either.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
