On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj) <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
  • [vpp-dev] VXL... Jon Loeliger
    • Re: [vpp... John Lo (loj)
      • Re: ... Jon Loeliger
        • ... Jon Loeliger
          • ... John Lo (loj)
            • ... Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
        • ... Neale Ranns (nranns)
          • ... John Lo (loj)
            • ... Neale Ranns (nranns)
              • ... Ed Warnicke
                • ... Florin Coras
      • Re: ... Jon Loeliger
        • ... John Lo (loj)

Reply via email to