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? 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 * 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? 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
