Hi, Iām checking the implementation of GTPU performance enhancement with bypass ip-lookup after gtpu_encap. I started up a VPP with hardware interface configuration only, and do following configuration: ip route add 0.0.0.0/0 via 18.1.0.1 create gtpu tunnel src 1.1.1.1 dst 1.1.1.4 teid-in 3 teid-out 4 ip route add 1.2.3.4/32 via gtpu_tunnel0
A host route created: 17@1.1.1.4/32 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:18 buckets:1 uRPF:20 to:[2:72]] [0] [@12]: dpo-load-balance: [proto:ip4 index:16 buckets:1 uRPF:8 to:[0:0] via:[270:17056]] [0] [@5]: ipv4 via 18.1.0.1 eth0.181: mtu:9000 0004969829b40209c0d2bbc3810000b50800 And the packet to 1.2.3.4 will be encapsulated via GTP and send to ip4-load-balance directly. Then I do another test, ip route add 0.0.0.0/0 via 18.1.0.1 create gtpu tunnel src 1.1.1.1 dst 1.1.1.4 teid-in 3 teid-out 4 ip route del 0.0.0.0/0 via 18.1.0.1 VPP crashed when deleting the default route, both on debug and release version. I think it is a bug. I did same test on VXLAN, and it also crashed. I assume the relation between default route and route to 1.1.1.4 is established via below code in vnet_gtpu_add_del_tunnel. t->sibling_index = fib_entry_child_add (t->fib_entry_index, gtm->fib_node_type, t - gtm->tunnels); I uncommented the two lines, but vpp still crashed. In summary, my question is : 1ć Is it a bug of the crash when deleting default route in that scenario? 2ć What is the usage of fib_entry_child_add related code? BR/Lollita Liu
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12440): https://lists.fd.io/g/vpp-dev/message/12440 Mute This Topic: https://lists.fd.io/mt/30283902/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-