On 1/5/26 11:03 PM, Alexandra Rukomoinikova wrote:
> When a logical router port has multiple IPv4 addresses from different
> networks, northd generates multiple TTL exceeded flows with identical
> match conditions but different actions (different ICMP reply source IPs).
> This causes non-deterministic behavior where replies may use an incorrect
> source IP not belonging to the original packet's network.
>
> The fix adds source IP network matching to flow generation, ensuring
> ICMP TTL exceeded replies always originate from an IP in the same
> network as the destination of the original packet.
>
> Reported-at: https://issues.redhat.com/browse/FDP-2870
> Signed-off-by: Alexandra Rukomoinikova <[email protected]>
> ---
Hi. Thanks for the patch!
It is an interesting problem. Though, it seems like the real solution
would be a fair bit more complicated than what's presented here.
The current code is not correct for neither IPv4 not IPv6, but in
different ways. The IPv4 code is non-deterministic as we may be replying
with different source address every time, which is not good, as some of
those addresses may not be reachable by the packet source. However,
it seems like in IPv6 case we have the network match and we will actually
not even reply to a packet forwarded to us from a network that is not
directly attached to the router port. Which is also incorrect.
The full solution here, AFAIU, is to actually perform a route lookup
on the packet source IP and use the nexthop network as a source for
the ICMP error. This is very similar to the issue we fixed earlier
for the SNAT:
af6e83707568 ("northd: Use next-hop network for SNAT when
lb_force_snat_ip=router_ip.")
But the implementation may be a little more complicated as we do not
already have a routing result here.
A much simpler, but not fully correct solution would be to match the
source network as it is done in this patch, but we also need a lower
priority logical flow that will capture all the packets from networks
not directly attached to this router port. And there we would need to
just reply from the first address, if we don't want to perform a full
route lookup. This will ignore all the routing configuration including
policies and stuff and will reply from a wrong IP whenever the packet
is from a remote network, but will surely be better than what we have
today.
Thoughts?
Dumitru, since you're the reporter of this issue, what do you think?
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
