Hi Jon, I feel I must ask ☺ “That <X> has to match a VPP interface by name. But what name?” why does it need to match a VPP interface name? shouldn’t <X> = MyVxlan23. Your control plane maintains mappings between MyVxlan23 and VPP’s sw_if_index.
/neale From: <vpp-dev-boun...@lists.fd.io> on behalf of Jon Loeliger <j...@netgate.com> Date: Friday, 2 February 2018 at 22:08 To: "John Lo (loj)" <l...@cisco.com> Cc: vpp-dev <vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] VXLAN Tunnel IF Names On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>> wrote: Hi Jon, Hi John, Thanks for taking the time to get back to me on this! All VPP tunnel creation uses the mechanism of returning a sw_if_index of the created tunnel. I know. I get that. It works. 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. Right. I am not sure if it is feasible to follow this behavior to “predict” tunnel name. It is not. The problem is not just "predict it", but the user has to be able to know the associated SW IF name at the time that the (vxlan tunnel) create API call happens. The reason for that is because the very next thing the API call user is going to want to do is configure that interface. Short of interrogating the system, there is no way to know the IF name. (I understand that the name can be obtained from the sw_if_index. That's not what I mean.) Consider this series of PEUDO API calls that are being issued by some client front-end. Think of this as a batch of CLI commands: vxlan MyVxlan23 source 1.2.3.4 destination 10.11.12.13 vni 19 exit interface <X> do stuff to interface like apply an ACL or whatever exit There is no way to batch-run those as there is a step needed to determine what <X> is. It could be "vxlan_tunnel..." anything. That <X> has to match a VPP interface by name. But what name? The entire transactional history of VXLANs must be known in order to guess the next 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? I've not touched GRE yet. However, it is next on my list to fix! My current plan is to submit essentially the same patch there too. 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. Excellent! Thank you for this insight! That makes total sense now! 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. This is the route I was headed: Just like loopback interface naming! In this case, the above example would be, perhaps, something like this: vxlan MyVxlan23 instance 101 source 1.2.3.4 destination 10.11.12.13 vni 19 exit interface vxlan_tunnel101 do stuff to interface like apply an ACL or whatever exit 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. I solved that by making a trivial vxlan_name_renumber() function, and then calling vnet_interface_name_remumber(sw_if_index, instance) to update the previously captured "vxlan_tunnel<X>" name and rename it using the new instance number. 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. To me, that sounds like a whole bunch of really unnecessary code replication and fragile separation of API results that will invariably get mixed up and cause mysterious failures. Instead, I maintain the original instance allocation scheme when there is no requested Instance Id made by the CLI or API user. I have submitted a patch to Gerrit. When this passes "verify", I'll add you to be a Reviewer! HTH, jdl
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
