On 8/8/24 17:56, [email protected] wrote: > On Thu, 2024-08-08 at 16:56 +0200, Dumitru Ceara wrote: >> On 8/8/24 15:37, [email protected] wrote: >>> Thank you for the confirmation. >>> >>> As for the context of the current "experimental" implementation. >>> Would >>> you say that it's OK if we then redirect all LRP IP's (as currently >>> proposed) and properly document that this feature causes traffic to >>> all >>> LRP IPs to be redirected. Therefore it's incompatible with, for >>> example, creating load balancer on LRP with port 179? >>> >> >> It's actually incompatible with any load balancer to be created that >> has >> VIP=<any LRP IP>. Same for NATs. > > Sorry if I wasn't clear, but I was referring to an implementation that > would redirect only traffic that matches: > * ip.dst == LRP_IP && tcp.dst == 179 (Traffic from peer to our daemon) > * ip.dst == LRP_IP && tcp.src == 179 (Replies to our daemons requests) > > These are static rules without any conntrack involvement. I have it > deployed right now and I see NATed traffic from the hosts behind NAT > working fine. > (above I'm using port 179 as example, same is true for the BFD port) > >> >> What if we combine it with a filter like Vladislav suggested? But >> not >> match on any IPs explicitly. Then the user could just configure >> multiple IPs (e.g., IP1, IP2) on the LRP and decide which of them >> should >> be redirected by adding a filter on "ip.dest == IP2" (for example). >> >> That would allow you to: >> a. redirect all traffic (no filter or filter == "1") >> b. redirect traffic for select IPs (filter == "ip.dest == X") >> c. do more complex things (responsibility of the user if things >> break?) >> >> What do you think? > > To me personally, the option that lets user directly inject rules into > OVN seems bit fragile and prone to errors/unexpected behavior. However > that's not to say that I wouldn't implement it this way if maintainers > are OK with this approach. > I realize that we are very close to the freeze, but part of me still > hopes that this feature will make it in :D. Properly implementing free- > form rules via option is going to take a lot of time > (implementation/input sanitation/testing/documentation). Perhaps we > could open it up for the discussion in the further cycle development? >
OK, you're right it's not something we can do now. > I have an implementation based on your original feedback (i.e. with > 'routing-protocol-redirect' and 'routing-protocols' options) that: > * Allows redirecting BGP (179) and BFD (3784) > * works for BGP in both directions > * does not produce duplicate ARP replies I still don't understand how the 'bgp-daemon' VIF resolves the mac address of its BGP peer. ARP replies are unicast and destination mac is the 'bgp-daemon' MAC address which happens to be the LRP MAC address too. But maybe I can understand it better from the system test.. > * doesn't seem to break regular SNATed traffic. > > I plan to post it (hopefully today), after updating docs and tests, for > consideration. Would that be OK, or are there any other issues that > would block the first experimental implementation? > If it works like this it's probably fine. Thanks for the hard work on this! Regards, Dumitru > Martin. > >> >>> Martin. >>> >>> On Thu, 2024-08-08 at 15:29 +0200, Dumitru Ceara wrote: >>>> On 8/8/24 14:42, Dumitru Ceara wrote: >>>>>> Would it be useful to redirect only traffic for LRP's IPv6 >>>>>> LLA? >>>>>> @Vladislav, in your setups, do you use ipv4 or ipv6 LLAs for >>>>>> setting up >>>>>> BGP peering? >>>>>> >>>>> I'll let Vladislav comment on this. I do think IPv4 might be a >>>>> requirement on the long term for us downstream though. >>>> >>>> An addendum here, I meant non-LLA IPv4 (globally routable but >>>> maybe >>>> also >>>> private). >>>> >>> >> > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
