On 4/24/26 12:48 PM, Rukomoinikova Aleksandra wrote:
>>> static uint16_t
>>> -route_source_to_offset(enum route_source source)
>>> +calc_priority(int plen,
>>> + enum route_source source,
>>> + bool override_connected,
>>> + bool is_src_route,
>>> + bool has_protocol_match)
>>> {
>> I think the problem is in this function, the new way of calculating
>> priority will never allow a policy=src route to be selected over a
>> policy=dst route that has a shorter prefix.
>>
>> The way OVN currently works is (as documented):
>>
>> <p>
>> When multiple routes match a packet, the longest-prefix match is chosen.
>> For a given prefix length, a <code>dst-ip</code> route is preferred over
>> a <code>src-ip</code> route.
>> </p>
>>
>> But with your code, if we have two routes:
>> a. policy=src-ip, prefix=1.1.1.1/32 => calc_priority() returns 384
>> b. policy=dst-ip, prefix=0.0.0.0/0 => calc_priority() returns 1552
>>
>> So "a" will never be preferred over "b", breaking the way routing
>> currently works. More details in:
>>
>> https://mail.openvswitch.org/pipermail/ovs-dev/2025-September/426004.html
>
> Hi Dumitru! Thanks a lot for that suggestion; it would have been much
> harder for me to figure this out without it. I'm thinking about adding a
> test or changing the original tests for routes so that they don't just
> print the priority in logical rules, but compare these priorities to
> make it easier to track down such issues. I can prepare a separate patch
> for this.
Hi Alexandra,
Yes, a test for this would be ideal. It would prevent us from breaking
the behavior in the future.
Thanks,
Dumitru
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
