Hi Jon, All VPP tunnel creation uses the mechanism of returning a sw_if_index of the created tunnel. The name of the tunnel is then followed by a number being the instance or index to the tunnel struct vector. Thus, the first VXLAN tunnel created is called vxlan_tunnel0 followed by vxlan_tunnel1, etc. The number is incrementing unless tunnels are deleted and created again where a newly created tunnel will reuse the last deleted tunnel, hence its name. If all previously deleted tunnels are used up, then the tunnel name number will start incrementing again. I am not sure if it is feasible to follow this behavior to “predict” tunnel name.
BTW, GRE tunnels are created and named the same way. You added TEB (transparent ethernet bridging) support to GRE. Have you not been using it and bothered by how to predict name of created GRE tunnels? It is not a good idea to tie tunnel name to VNI as it is not a unique ID to identify VXLAN tunnels. It is quite common for existence of multiple VXLAN tunnels with the same VNI with different remote end point IP addresses. A bridge domain (BD) may have multiple VXLAN tunnels with the same VNI to several remote servers where the same overlay network exist. It is quite common to use the ID for BD or VLAN as the VNI for all its VXLAN tunnels to make it easier to track their usage. I suppose it is feasible to provide another set of VXLAN tunnel create/delete API to allow caller to specify instance or number of the tunnel, similar to what you did for loopback interface. One complication for the new API is that, upon VXLAN tunnel deletion, the interface created for the tunnel is not really deleted by the current code but put into a reuse pool. When more tunnels are created, any interface from reuse pool with its existing interface name will be used for the new tunnel, before new interfaces are created. If a interface is reused upon tunnel creation, its interface name may not match the specified tunnel instance/number of the new tunnel creation API. One way to overcome this may be to not keep interface in reused pool on tunnel deletion. Thus, tunnel creation would always create new interface. For backward compatibility, I suppose we can keep the tunnel create/delete API as is so interfaces of deleted tunnels are kept for reuse. The new API will then always create/delete interface on tunnel create/delete. This would put a restriction that user should not mix the usage of new or old APIs. Regards, John From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Jon Loeliger Sent: Wednesday, January 31, 2018 3:13 PM To: vpp-dev <vpp-dev@lists.fd.io> Subject: [vpp-dev] VXLAN Tunnel IF Names Hey Developers, I've turned my attention to the wondrous world of VXLANs! And with that, I stare into the Vast VXLAN API Abyss... My first question, as usual, involves the SW IF that is created by the vxlan tunnel create API call. The IF has a name that is once-again unknowable by the User who creates the tunnel unless direct inspection takes place. Can we somehow invert the naming responsibility here so that the API states either the name or the unique integer used to form the the SW IF tunnel name? Or perhaps it can be formed using the VNI number? Inspecting the reply return value isn't good enough; we need to be able to know, in advance, what the tunnel SW IF name will be. This is, again, the same naming problem we've had in the past with Loopback IFs, bridges, and recently memif socket names. If directly using the VNI won't work, I can work up a patch to allow user numbering in the style of, say, bridges, if that would be helpful. Thanks, jdl
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
