John, When a resource is reused from that freed pool, is it assigned the same IDs (name and sw_if_index)? To prevent any confusion and race conditions, it is better to assign them new unique IDs (e.g. increment the vxlan_tunnel number in the name, use a unique ID for any internal index such as sw_if_index).
Such reuse strategy has caused a lot of issues in other implementations of various protocols or infra services when you have asynchronous requests that carry the resource identifier. The typical case is to have one “entity” deleting the tunnel, another unrelated one creating a new tunnel (and thus reusing the same name/ID) and yet another entity working on the previous tunnel (because it has not been aware yet of its deletion) which then incorrectly impacts the new tunnel. The use case that Matej describes below is actually not that far fetched (assign the old tunnel to a BD will succeed but would be catastrophic to the new tunnel). Also displaying resources from that freed pool in a show command is confusing for the user because they cannot be distinguished from valid interfaces that are in the down state (would be best to skip them in the show command). Thanks Alec From: <vpp-dev-boun...@lists.fd.io> on behalf of "Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)" <mklot...@cisco.com> Date: Tuesday, January 10, 2017 at 6:59 AM To: "John Lo (loj)" <l...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] Deleting VXLAN interface doesn't delete it from interface dump Reusing removed VXLAN interfaces sounds good. However I put deleted vxlan_tunnel interface UP, then assign it to a bridge domain and add pg interface to this bridge domain. When I sent a traffic to pg interface VPP crashes with build-root/install-vpp_lite-native/vpp/bin/vpp[10393]: received signal SIGSEGV, PC 0x7f8e63b7744d, faulting address 0xfffffffffffffffc in /var/log/syslog Regards, Matej From: John Lo (loj) Sent: 10. januára 2017 14:14 To: Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco) <mklot...@cisco.com>; vpp-dev@lists.fd.io Subject: RE: [vpp-dev] Deleting VXLAN interface doesn't delete it from interface dump Yes, this is the expected behavior. These deleted VXLAN tunnels in the down state are placed in a pool so that it can be reused when more VXLAN tunnels are created later. On creating a VXLAN tunnel, any of these deleted ones are reused first, before new interfaces are created for the VXLAN tunnel. Regards, John From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco) Sent: Tuesday, January 10, 2017 3:45 AM To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: [vpp-dev] Deleting VXLAN interface doesn't delete it from interface dump Hi, I’m trying delete VXLAN tunnel interfaces and after they are deleted they are still in show interfaces but with down state. vat# exec create vxlan tunnel src 172.16.1.1 dst 172.16.1.2 vni 1 vat# exec create vxlan tunnel src 172.16.1.1 dst 172.16.1.2 vni 2 vat# exec create vxlan tunnel src 172.16.1.1 dst 172.16.1.2 vni 3 vat# exec create vxlan tunnel src 172.16.1.1 dst 172.16.1.2 vni 2 del vat# exec show vxlan tunnel [0] src 172.16.1.1 dst 172.16.1.2 vni 1 sw_if_index 3 encap_fib_index 0 fib_entry_index 19 decap_next l2 [2] src 172.16.1.1 dst 172.16.1.2 vni 3 sw_if_index 5 encap_fib_index 0 fib_entry_index 19 decap_next l2 vat# exec show interface Name Idx State Counter Count vxlan_tunnel0 3 up vxlan_tunnel1 4 down vxlan_tunnel2 5 up Is this expected behavior or should I open a Jira ticket? Loopbacks and subinterfaces are deleted also from show interface. Thanks, Matej
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
