Hi Alexander, Could you please see if this fixes your issue: https://gerrit.fd.io/r/c/vpp/+/44256
thanks neale From: [email protected] <[email protected]> on behalf of Alexander Maltsev via lists.fd.io <[email protected]> Date: Tuesday, 25 November 2025 at 9:53 pm To: [email protected] <[email protected]> Subject: Re: [vpp-dev] Adj neighbor updates doesn't update exported routes in other tables You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> I'm not sure how to configure it without pushing routes through linux-cp (particularly, my /24 ipv4-glean entry, which is important to reproduce this). If that's not a problem, here it is. Have DPDK (probably not important, just anything with MAC address) ethernet device with linux-cp enabled. In my case it is called eth1_9c, and its lcp tap is tap23 itf-pair: [2] eth1_9c lcp.01K8MBW6DT5A6P6ZFWK1ZMTFF7 tap23 23 type tap # # just to make sure neighbor is not known beforehand - important for repro! # vppctl set ip neighbor del eth2_c5 192.168.50.1 42:fe:5b:8a:19:5d # # ip route flush table 1 # ip route add 192.168.50.0/24 dev tap23 src 192.168.50.2 table 1 # ip route add default via 192.168.50.1 table 1 # ip route show table 1 default via 192.168.50.1 dev tap23 192.168.50.0/24 dev tap23 scope link src 192.168.50.2 # vppctl show ip fib table 1 ipv4-VRF:1, fib_index:4, flow hash:[src ] epoch:0 flags:none locks:[lcp-rt:1, ] 0.0.0.0/0 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:52 buckets:1 uRPF:76 to:[0:0]] [0] [@5]: ipv4 via 192.168.50.1 eth2_c5: mtu:1500 next:10 flags:[features ] 42fe5b8a195d5254008850c50800 0.0.0.0/32 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:53 buckets:1 uRPF:68 to:[0:0]] [0] [@0]: dpo-drop ip4 192.168.50.0/24 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:57 buckets:1 uRPF:74 to:[0:0]] [0] [@4]: ipv4-glean: [src:0.0.0.0/0] eth2_c5: mtu:1500 next:3 flags:[] ffffffffffff5254008850c50806 192.168.50.1/32 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:60 buckets:1 uRPF:79 to:[0:0]] [0] [@3]: arp-ipv4: via 192.168.50.1 eth2_c5 192.168.50.2/32 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:58 buckets:1 uRPF:73 to:[0:0]] [0] [@11]: dpo-receive: 0.0.0.0 on local0 224.0.0.0/4 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:55 buckets:1 uRPF:70 to:[0:0]] [0] [@0]: dpo-drop ip4 240.0.0.0/4 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:54 buckets:1 uRPF:69 to:[0:0]] [0] [@0]: dpo-drop ip4 255.255.255.255/32 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:56 buckets:1 uRPF:72 to:[0:0]] [0] [@11]: dpo-receive: 0.0.0.0 on local0 Even though in table 0 I have 192.168.50.1/32 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:59 buckets:1 uRPF:75 to:[0:0]] [0] [@5]: ipv4 via 192.168.50.1 eth2_c5: mtu:1500 next:10 flags:[features ] 42fe5b8a195d5254008850c50800 and no arp-ipv4 entries (according to logs/debugging, they were inserted, but then immediately resolved via fib_walk_sync. But not in table1). In fib logs, by problemmatic entry is marked as attached_export, and I've confirmed via debugger how it gets created. I know how to make it work, e.g. Index: vpp-24.02/src/vnet/fib/fib_entry.c =================================================================== --- vpp-24.02.orig/src/vnet/fib/fib_entry.c +++ vpp-24.02/src/vnet/fib/fib_entry.c @@ -1471,6 +1471,7 @@ fib_entry_back_walk_notify (fib_node_t * fib_source_t best_source; fib_entry_t *fib_entry; fib_entry_src_t *bsrc; + bool update_covers = false; fib_entry = fib_entry_from_fib_node(node); bsrc = fib_entry_get_best_src_i(fib_entry); @@ -1509,6 +1510,8 @@ fib_entry_back_walk_notify (fib_node_t * FIB_NODE_BW_REASON_FLAG_INTERFACE_DELETE & ctx->fnbw_reason) { fib_entry_src_action_reactivate(fib_entry, best_source); + if (ctx->fnbw_reason == FIB_NODE_BW_REASON_FLAG_ADJ_UPDATE && best_source == FIB_SOURCE_ADJ) + update_covers = true; } /* @@ -1535,6 +1538,17 @@ fib_entry_back_walk_notify (fib_node_t * fib_entry_get_index(fib_entry), ctx); + if (update_covers) { + fib_entry_src_t *esrc = fib_entry_src_find(fib_entry, best_source); + FIB_ENTRY_DBG(fib_entry, "update covers"); + if (esrc) { + fib_entry_src_action_cover_change(fib_entry, esrc); + FIB_ENTRY_DBG(fib_entry, "removed"); + fib_entry_src_action_installed(fib_entry, best_source); + FIB_ENTRY_DBG(fib_entry, "installed"); + } + } + return (FIB_NODE_BACK_WALK_CONTINUE); } It is not a complicated patch, but would very much prefer a better solution, as I can't imagine this is how it supposed to be.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#26596): https://lists.fd.io/g/vpp-dev/message/26596 Mute This Topic: https://lists.fd.io/mt/116387408/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
