On 3/23/21 12:13 PM, Dumitru Ceara wrote:
On 3/23/21 5:05 PM, Numan Siddique wrote:
On Fri, Mar 19, 2021 at 2:20 AM Mark Michelson <[email protected]> wrote:
Self-originated ARPs are intended to be sent to the "owning" router for
a given IP address, as well as flooded to non-router ports on a logical
switch.
When trying to determine the owning router for an IP address, we would
iterate through load balancer and NAT addresses, and check if these IP
addresses were "reachable" on this particular router. Reachable here
means that the NAT external IP or load balancer VIP falls within any of
the networks served by this router. If an IP address were determined not
to be reachable, then we would not try to send ARPs for that particular
address to the router.
However, it is possible (and sometimes desired) to configure NAT floating
IPs on a router that are not in any subnet handled by that router.
In this case, OVN refuses to send ARP requests to the router on which the
floating IP has been configured. The result is that internally-generated
traffic that targets the floating IP cannot reach its destination,
since the router on which the floating IP is configured never receives ARPs
for the floating IP.
This patch fixes the issue by removing the reachability checks
altogether. If a router has a NAT external IP or load balancer VIP that
is outside the range of any of its configured subnets, we still should
send ARPs to that router for those requested addresses.
Reported at: https://bugzilla.redhat.com/show_bug.cgi?id=1929901
Signed-off-by: Mark Michelson <[email protected]>
Thanks for addressing this.
Acked-by: Numan Siddique <[email protected]>
@Dumitru - Since you had added the code to limit ARPs. Can you please
also take a look at this patch ?
Hi Mark, Numan,
I've been thinking about this for a while. I think this needs at least:
Fixes: 1e07781310d8 ("ovn-northd: Fix logical flows to limit ARP/NS broadcast
domain.")
OK, I can either just add that to the commit when I merge, or if I need
to put a new version up for review, I can add it to the new version then.
With the latest changes in ovn-kubernetes I think that the above was not
needed anyway. Mark, do you have more details about this by any chance?
I'm not sure which changes in ovn-kubernetes you're referring to here.
Initial bug report was here:
https://mail.openvswitch.org/pipermail/ovs-discuss/2020-June/050287.html
To quote from that e-mail:
"Question though is why any Pod on the logical switch would send an ARP
for an IP that is not in its subnet. A packet from a Pod towards a non
subnet IP should ARP only for the default gateway IP."
The above holds true for the scenario I'm working here. The key is that
this is a self-originated ARP from OVN, not an ARP from a pod/VM.
The use case I'm solving here is OpenStack floating IPs. It's not
common, but it is expected that a user is able to assign a floating IP
to a router that does not service that floating IP's subnet. They also
expect all other VMs in the cluster to be able to reach the target VM
via its floating IP.
So let's say you have a setup like:
EXT-ROUTER
^
|
v
VM1 <-> LS1 <-> LR1 <-> LS-PUB <-> LR2 <-> LS2 <-> VM2
In this case, LR1 and LR2 both have distributed gateway router ports on
them (the ports going to LS-PUB). They also have default static routes
that point to the EXT-ROUTER. LR2's gateway router port IP address is
172.18.1.1/24. An OpenStack user configures a floating IP for VM2 of
172.18.2.100. This translates to a dnat_and_snat entry on LR2 for that
address, which is NOT in the subnet configured on that router. Now VM1
wants to ping 172.18.2.100. In this case, when the ping reaches LR1, LR1
needs to ARP to find where 172.18.2.100 is. The ARP needs to target LR2
since that's where the floating IP is configured. If the ARP only goes
to EXT-ROUTER, EXT-ROUTER won't be able to respond to the ARP properly,
and connectivity cannot be established.
Thanks,
Dumitru
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
