Hi Numan, I have a question about your patch https://github.com/ovn-org/ovn/commit/8d13579bf5b390c1dcf1e737f918e05407f8692c It's been a while since it was merged, but we only noticed it breaks some of our test cases now, during an upgrade.
Here's our scenario: we have a private network with a router attached to it. That router can have 2 DGP ports on it — one used for interconnect connectivity, and a second one used for VTEP. We're planning to keep using this setup going forward, so I wanted to ask for your advice on the best way to fix this, and how you originally envisioned this feature working for routers with multiple DGP ports. The problem, as I see it: On the switch side, a chassis-redirect (cr) port is only created when two conditions hold: there is exactly one DGP on the router, and the switch has no localnet port. In our setup we have more than one DGP port on the router, so that condition fails, and no cr-port gets created for the switch. This breaks connectivity: the packet stays on the node hosting the VM, enters the router pipeline locally, and gets dropped since router is not in local datapath since controller consider this cr-port switch part for adding datapath to locals. Here's what I was thinking about support centralized routing for several dgps to fix this , but I'd love your take — maybe you have a better approach in mind. Consider a switch with no localnet port, to which several DGPs of the same router are attached via peer LSPs. A packet entering this switch and destined "for the router" can fall into one of two categories based on ip.dst: 1)The address does not belong to a network locally connected to this DGP (or it's an unknown OVN address that doesn't match any connected/NAT/LB network). In this case, the packet is unconditionally redirected to the DGP attached to this switch, without trying to precompute on the switch which DGP of the router should ultimately handle it. From there, one of two things happens: either that DGP routes the packet out directly (if it's the correct egress), or, if the packet actually needs to leave via a different DGP of the same router, the existing lr_in_gw_redirect mechanism redirects it to the right chassis once it's already inside the router. That said, I don't think this works for NAT as-is — for NAT we'd need additional rules to redirect the packet to the right gateway (in the multi-DGP NAT case, the user either specifies the gateway explicitly via gateway_port, or OVN computes it based on the subnet). 2)The address belongs to a subnet directly served by this DGP — in that case the packet is likewise redirected to the DGP local to this switch. I'm not sure yet how to handle distributed NAT under this scheme, though. Thanks in advance for any thoughts! _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
