On 1/30/25 9:16 AM, Felix Huettner via dev wrote: > On Wed, Jan 29, 2025 at 10:28:23PM +0100, Frode Nordahl wrote: >> ons. 29. jan. 2025, 12:16 skrev Felix Huettner via dev < >> ovs-dev@openvswitch.org>: >> >>> This brings in needed changes so that the ovs submodule exports route >>> table related functionality. >>> >>> As the ovs submodule has bumped its DPDK version we need to do so as >>> well. >>> >>> Signed-off-by: Felix Huettner <felix.huettner@stackit.cloud> >>> --- >>> > > Hi Frode, > >> >> Note that there is one prerequisite patch that has not merged on the OVS >> side yet [0], so ci wont pass until that gets in. Martin spotted the issue >> and sent a patch. > > thanks a lot for that one. I hope i mentioned it in the cover letter. > >> >> We were discussing the reasoning for changing the route type, I have not >> reviewed that bit in detail yet and at a high level it may appear to make >> sense. >> >> Would be interesting to hear your reasoning for the change? > > You mean why advertised routes are using blackhole? > > So i did not want to include the nexthop IP in the Advertised_Route > table if possible as that would just duplicate a lot of entries. > Because of this we would not have the nexthop IP readily available. >
I don't think we should include the nexthop IP in SB.Advertised_Route. I mean, in the end, the router is aware of the routes it advertises _regardless of which interface the traffic destined for the route is received on_. But I think the routes we inject in linux (for whatever we advertise) should include next-hop if we want the host to be able to send traffic to them. I'll try an example: FRR-VIF1 -- LS --- LRP1 (1.1.1.1/24) --- LR --- LRP3 (3.3.3.1/24) FRR-VIF2 -- --- LRP2 (2.2.2.1/24) Assuming we're advertising "connected" I guess the two FRR instances should learn: FRR-VIF1: 3.3.3.0/24 via 1.1.1.1 FRR-VIF2: 3.3.3.0/24 via 2.2.2.1 If routing-protocol-redirect is used, that'd have to be configured on LRP1 and LRP2, so it could allow us to determine which LRP's IP should be configured as next-hop when injecting linux routes. > I then also assumed that BGP is mostly used together with > routing-protocol-redirect. In this case we already know the respective > IP of the LRP as that IP is also used for the redirect linux interface. > > I therefor saw no real need to include the nexthop IP anywhere as we > already have it at the relevant locations. And the route type that best > matched the conditions of having a prefix, but no nexthop was blackhole. > > If there is a need to have the nexthop IPs included in the linux routes > we could definately change that. During implementation i just did not > saw the need and took the simpler path. > If we could just always include nexthop IPs in the linux routes we create, I'd prefer that, I think. However, I'm not exactly sure yet how ovn-kubernetes will be able to consume the OVN BGP support we're adding in this release. It might be that they don't use routing-protocol-redirect. In which case we might need a way to specify through config which IP ovn-controller to use as next-hop when installing the linux routes. But that's something we can add later when we get a better idea about the ovn-kubernetes use case. > Hope that clarifies this. > > Thanks a lot, > Felix > Regards, Dumitru >> >> 0: >> https://patchwork.ozlabs.org/project/openvswitch/patch/20250123152125.17973-1-martin.kal...@canonical.com/ >> >> -- >> Frode Nordahl >> >> v4->v5: update the dpdk version based on ovs changes >>> v3->v4: added >>> >>> ovs | 2 +- >>> utilities/containers/prepare.sh | 2 +- >>> 2 files changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/ovs b/ovs >>> index 7b1ce8e2a..a3c06c309 160000 >>> --- a/ovs >>> +++ b/ovs >>> @@ -1 +1 @@ >>> -Subproject commit 7b1ce8e2a08454839c52b8cc02fdde5c78e7c40e >>> +Subproject commit a3c06c309ab9f21fd9ce4e8dca542119d46be9c5 >>> diff --git a/utilities/containers/prepare.sh >>> b/utilities/containers/prepare.sh >>> index 49bb2ac91..6922d8c6b 100755 >>> --- a/utilities/containers/prepare.sh >>> +++ b/utilities/containers/prepare.sh >>> @@ -1,7 +1,7 @@ >>> #!/bin/bash -xe >>> >>> DPDK_GIT=https://dpdk.org/git/dpdk >>> -DPDK_VER=23.11 >>> +DPDK_VER=24.11 >>> >>> function compile_sparse() >>> { >>> -- >>> 2.47.1 >>> >>> >>> _______________________________________________ >>> dev mailing list >>> d...@openvswitch.org >>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >>> > _______________________________________________ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
