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]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to