Jon, BTW, this is caused by a patch to remove interface reuse on VXLAN tunnel deletion. So it was definitely not from your patch which was previous to this one. I missed it when I review the patch.
Thanks for finding this and appreciate your help, John From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of John Lo (loj) Sent: Friday, February 23, 2018 5:44 PM To: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] VXLAN Instances Not Freed Properly? 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<mailto:vpp-dev@lists.fd.io>>; John Lo (loj) <l...@cisco.com<mailto: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
