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
