On 1/30/25 11:47 AM, Dumitru Ceara wrote: > 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. >
Please ignore my previous email. I just realized that in the case above FRR-VIFX and LRPX would have the same IP essentially making the routes as "blackhole". >> 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
