Let's try to reproduce it manually first. Can you run ip route add 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 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 <andre= 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 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> > > > > On Wed, 13 Aug 2025 at 00:41, Andre Nathan via lists.fd.io <http:// > > lists.fd.io> <andre=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> <andre=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> 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> > > > BIRD 2.16.1 ready. > > > Table master4: > > > 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> > > > 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> > > > 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> 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> 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 (#26271): https://lists.fd.io/g/vpp-dev/message/26271 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] -=-=-=-=-=-=-=-=-=-=-=-
