On 8/8/24 18:13, Dumitru Ceara wrote: > 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! >
I forgot to mention, it would be great if you could already mark it "experimental" in the ovn-nb documentation. Thanks! > 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
