This worked fine, both add and replace (and del later) via the kernel
ended up propagated correctly to vpp.
My kernel version is 6.8.0-44-generic from Ubuntu 24.04.
Best,
Andre
On 8/18/25 5:01 AM, Stanislav Zaikin via lists.fd.io wrote:
Let's try to reproduce it manually first.
Can you run
ip route add 1.2.3.4/32 <http://1.2.3.4/32> via x.y.z.w dev uplink1
protocol bgp (and check that everything is propagated in both linux and vpp)
ip route replace 1.2.3.4/32 <http://1.2.3.4/32> via a.b.c.d dev
external protocol bgp (and check again)
If the "replace" code doesn't work for some reason - you'll see the
inconsistency between linux and vpp and we can decide how to debug further.
BTW what kernel do you use?
On Thu, 14 Aug 2025 at 15:24, Andre Nathan via lists.fd.io <http://
lists.fd.io> <andre=digirati.com...@lists.fd.io
<mailto:digirati.com...@lists.fd.io>> wrote:
Hi Stanislav
Yes, I found that commit while trying to understand the issue. I've
done
the test in VPP 25.06 and there was no difference in behavior, which
makes sense since I was on 24.10, which includes the replace code.
Do you know if there's any sysctl or other kind of setting which could
cause the netlink messages not to be delivered to VPP?
Best,
Andre
On 8/13/25 4:51 AM, Stanislav Zaikin via lists.fd.io <http://
lists.fd.io> wrote:
> Hi Andre,
>
> Replaces were supported a long time ago [0]. Did you have a
chance to
> check on newer vpp?
>
> [0] - https://gerrit.fd.io/r/c/vpp/+/38854 <https://gerrit.fd.io/
r/c/vpp/+/38854> <https://gerrit.fd.io/r/c/ <https://gerrit.fd.io/r/c/>
> vpp/+/38854>
>
> On Wed, 13 Aug 2025 at 00:41, Andre Nathan via lists.fd.io
<http://lists.fd.io> <http://
> lists.fd.io <http://lists.fd.io>>
<andre=digirati.com...@lists.fd.io <mailto:digirati.com...@lists.fd.io>
> <mailto:digirati.com...@lists.fd.io
<mailto:digirati.com...@lists.fd.io>>> wrote:
>
> When inspecting captured netlink messages on wireshark, I noticed
> that first a “route add” message is sent with flags CREATE
and EXCL
> with my other router as the gateway. This is the route from
the iBGP
> session which ends up in the VPP FIB. Then a second “route add”
> message is sent with flags CREATE and REPLACE, with the
uplink peer
> router as the gateway. This route is not installed in the VPP
FIB,
> though it is in the kernel routing table, as I showed in the
> previous email.
>
> I’m not sure if LCP is simply not getting the second message
or if
> it gets it but doesn’t install the route due to some error.
>
> Thanks,
> Andre
>
>
> > Em 11 de ago. de 2025, à(s) 16:24, Andre Nathan via
lists.fd.io <http://lists.fd.io>
> <http://lists.fd.io <http://lists.fd.io>>
<andre=digirati.com...@lists.fd.io <mailto:digirati.com...@lists.fd.io>
> <mailto:digirati.com...@lists.fd.io
<mailto:digirati.com...@lists.fd.io>>> escreveu:
> >
> > Hi
> >
> >> On 8/8/25 3:14 PM, Matthew Smith via lists.fd.io <http://
lists.fd.io> <http://
> lists.fd.io <http://lists.fd.io>> wrote:
> >> You could try adding del-dynamic-on-link-down to the linux-cp
> section of your startup.conf and see if that helps.
> >
> > I've tried this parameter, but it didn't make a difference
when
> bringing the iBGP session down.
> >
> > Now that I'm inspecting this more closely, I've found some
> strange behavior where the VPP routes don't match the ones
installed
> by Bird.
> >
> > In this case, I've started bird with the uplink BGP session
> enabled, and afterwards started the iBGP session. I've
noticed the
> VPP FIB has ~24k routes pointing to my other router, that is,
> learned via the iBGP session. This is weird because routes
via the
> other router should only be used in case the BGP session with the
> uplink peer goes down, as they by definition have one extra
hop, and
> are therefore "worse".
> >
> > I've checked that bird is indeed selecting the uplink route as
> the preferred one. One example:
> >
> > # birdc show route for 45.181.63.0/24
<http://45.181.63.0/24> <http://45.181.63.0/24 <http://45.181.63.0/24>>
> > BIRD 2.16.1 ready.
> > Table master4:
> > 45.181.63.0/24 <http://45.181.63.0/24>
<http://45.181.63.0/24 <http://45.181.63.0/24>> unicast [uplink_ipv4
> 17:44:31.966] * (100) [AS269170i]
> > via x.y.z.w on uplink1
> > unicast [ibgp_ipv4 17:44:31.609] (100)
[AS269170i]
> > via a.b.c.d on external
> >
> > The kernel route is in agreement:
> >
> > # ip route show 45.181.63.0/24 <http://45.181.63.0/24>
<http://45.181.63.0/24 <http://45.181.63.0/24>>
> > 45.181.63.0/24 <http://45.181.63.0/24>
<http://45.181.63.0/24 <http://45.181.63.0/24>> via x.y.z.w dev uplink1
> proto bird metric 32
> >
> > But the route in VPP is through my other router (a.b.c.d):
> >
> > # vppctl show ip fib 45.181.63.0/24
<http://45.181.63.0/24> <http://45.181.63.0/24 <http://45.181.63.0/24>>
> > ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto
> flowlabel ] epoch:0 flags:none locks:[adjacency:1, default-
route:1,
> lcp-rt:1, ]
> > 45.181.63.0/24 <http://45.181.63.0/24>
<http://45.181.63.0/24 <http://45.181.63.0/24>> fib:0 index:18181
locks:2
> > lcp-rt-dynamic refs:1 src-flags:added,contributing,active,
> > path-list:[77] locks:49272 flags:shared,popular, uPRF-
list:69
> len:1 itfs:[7, ]
> > path:[103] pl-index:77 ip4 weight=1 pref=32 attached-
> nexthop: oper-flags:resolved,
> > a.b.c.d BondEthernet0
> > [@0]: ipv4 via a.b.c.d BondEthernet0: mtu:1500 next:8
flags:
> [] 12b9c288223f3cfdfe9ec4e40800
> >
> > forwarding: unicast-ip4-chain
> > [@0]: dpo-load-balance: [proto:ip4 index:18182 buckets:1
uRPF:69
> to:[0:0]]
> > [0] [@5]: ipv4 via a.b.c.d BondEthernet0: mtu:1500 next:8
> flags:[] 12b9c288223f3cfdfe9ec4e40800
> > ipv4-VRF:180, fib_index:1, flow hash:[src dst sport dport
proto
> flowlabel ] epoch:0 flags:none locks:[lcp-rt:1, ]
> > 0.0.0.0/0 <http://0.0.0.0/0> <http://0.0.0.0/0
<http://0.0.0.0/0>> fib:1 index:49 locks:2
> > default-route refs:1 entry-flags:drop, src-
> flags:added,contributing,active,
> > path-list:[66] locks:2 flags:drop, uPRF-list:62 len:0
itfs:[]
> > path:[92] pl-index:66 ip4 weight=1 pref=0 special: cfg-
> flags:drop,
> > [@0]: dpo-drop ip4
> >
> > forwarding: unicast-ip4-chain
> > [@0]: dpo-load-balance: [proto:ip4 index:50 buckets:1 uRPF:62
> to:[0:0]]
> > [0] [@0]: dpo-drop ip4
> >
> >
> >
> > I don't really know how to explain that.
> >
> >
> >
> >
> >
> >
>
>
>
>
>
> --
> Best regards
> Stanislav Zaikin
>
>
>
>
--
Best regards
Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#26275): https://lists.fd.io/g/vpp-dev/message/26275
Mute This Topic: https://lists.fd.io/mt/114547460/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
