Hi Numan, Sorry for the noise — I wrote some complete drivel below =) I figured 
out how to do it and will send the patch, thanks!

> 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

Reply via email to