Re: [vpp-dev] VXLAN Instances Not Freed Properly?

[John Lo (loj)]

Hi Jon,

I see the problem in the delete path where the hash_unset() call is using the 
tunnel instance instead of the user_instance of the tunnel starting at about 
line 558 of vxlan.c:

      vnet_delete_hw_interface (vnm, t->hw_if_index);
      hash_unset (vxm->instance_used, instance);

Do you mind submit a patch to fix it, please?

Regards,
John

From: Jon Loeliger [mailto:j...@netgate.com]
Sent: Friday, February 23, 2018 4:57 PM
To: vpp-dev <vpp-dev@lists.fd.io>; John Lo (loj) <l...@cisco.com>
Subject: VXLAN Instances Not Freed Properly?

John, et al,

I stumbled across this interesting behavior in VXLAN tunnels:

vpp# create vxlan tunnel src 1.2.3.4 dst 10.11.12.13 vni 1 instance 101
vxlan_tunnel101
vpp# create vxlan tunnel src 1.2.3.4 dst 10.11.12.13 vni 1 instance 101 del
vpp# create vxlan tunnel src 1.2.3.4 dst 10.11.12.13 vni 1 instance 101
create vxlan tunnel: Instance is in use

And note the actual interface has been removed, so 101 should be free:

vpp# show int
              Name               Idx       State          Counter          Count
TenGigabitEthernet6/0/0           1        down
TenGigabitEthernet6/0/1           2        down
TenGigabitEthernet6/0/2           3        down
TenGigabitEthernet6/0/3           4        down
local0                            0        down

I was pretty sure this was working, but I might have botched that patch somehow?
Any chance you stumbled into this problem?

It might be worth noting that the equivalent GRE does work:

vpp# create gre  tunnel src 1.2.3.4 dst 10.11.12.13 instance 14
gre14
vpp# create gre  tunnel src 1.2.3.4 dst 10.11.12.13 instance 14 del
DELETED
vpp# create gre  tunnel src 1.2.3.4 dst 10.11.12.13 instance 14
gre14

I feel like this might be some typo or easy oversight in the VXLAN case.

Thanks,
jdl