The simplest (and probably the most common) overlay topology for our SD-WAN/ADVPN solution implements a simple 1:1 overlay-to-underlay mapping, when connecting the Spokes (Edges) to the Hubs. What does it mean?

Suppose you have two WAN links on every site, INET and MPLS. You will define the two respective overlays on your Hub(s) and you will refer to them using ol_type in your profile. So your profile will look something like this:

# Device Profiles #}
{% set profiles = {

    'Hybrid': {
      'interfaces': [
        {
          'name': 'port1',
          'role': 'wan',
          'ol_type': 'INET',
          'ip': 'dhcp',
          'dia': true
        },
        {
          'name': 'port4',
          'role': 'wan',
          'ol_type': 'MPLS',
          'ip': 'dhcp'
        },
        {
          'name': 'port5',
          'role': 'lan',
          'ip': lan_ip
        }
      ]
    }     

  }
%}

The Jinja Templates will connect every WAN link on the Spoke to the overlay defined by the ol_type parameter. So in the above case, two overlay tunnels will be generated, one from "port1" and another from "port4":

This may be good for most cases (and in INET/MPLS topologies it will even be the only feasible option), but sometimes a more complex Spoke-to-Hub connectivity would be preferred.

Assuming that both WAN links on the Spoke are Internet connections (so there is no MPLS), we may want to build the following overlay topology, which we call Many-to-One:

Another variation is Full-Mesh (don't get confused: we are not talking about a full-mesh network topology, where all sites are connected to each other; we are only talking about a full-mesh connectivity between a Spoke and a Hub!):

To summarize:

• In Many-to-One, a Spoke builds multiple tunnels (one from each of its WAN links) towards the same overlay endpoint on the Hub.

• In Full-Mesh, a Spoke builds tunnels from each of its WAN links towards each of the overlay endpoints on the Hub.

The good news is: our Jinja Templates now allow you to build these topologies! But only for the "BGP on Loopback" designs (including the multi-vrf one). That's due to the limitations of the "BGP per Overlay" design itself.

Let's see how to configure it and what results you will get.

The main caveat is with the tunnel naming. Our usual naming convention for the overlay tunnels is:

H<hub_index>_<ol_type>

It's easy to see that we have a problem here... For example, if a Spoke wants to build two tunnels towards the INET overlay, one from "port1" and another from "port2" (Many-to-One), both these tunnels will be called "H1_INET". So they'll collapse with each other!

Similarly, if a Hub has two overlays, ISP1 and ISP2, and a Spoke wants to build a Full-Mesh from "port1" and "port2", this will result in four tunnels, but two of them will be called "H1_ISP1" and the other two - "H1_ISP2". Again, they'll collapse with each other!

Seems like the solution is trivial: we just need to add a prefix (or an index) indicating the Spoke's WAN link! But we had to consider the following:

1. The easiest would be just to change the naming convention for all, automatically adding a WAN link index. So it would always be:

   H<hub_index>_<ol_type>_<wan_index> 
   

   But this wastes two extra characters in the tunnel name, and we know that its length is limited. Plus it will look ugly for those who don't really need those indexes - for example, for those who use the classical INET/MPLS topology or for those who are fine with the 1:1 mapping.

2. We could make it user's responsibility to always configure a certain prefix (or enable the index) when there are naming conflicts. That solves the previous problem, but wouldn't it be really cool if the Jinja Templates were adding the WAN link index automatically and only when needed? That is, only if otherwise there would be a naming conflict!

After thinking for a while, we have implemented both options: the automatic (implicit) one and the manual (explicit) one.

The new changes apply only to the "BGP on Loopback" designs ("bgp-on-loopback" and "bgp-on-loopback-multi-vrf"). They are currently implemented only for the release/7.2 branch.

When we build Spoke-to-Hub tunnels, we follow the usual logic, but we are tracking all the generated tunnel names. If a conflict is detected, we add an index to the conflicting name. For example, if there are two tunnels to be named "H1_INET", one of them will end up being called "H1_INET_2".

So here is how you would define the "Many-to-One" profile:

# Device Profiles #}
{% set profiles = {

    'ManyToOne': {
      'interfaces': [
        {
          'name': 'port1',
          'role': 'wan',
          'ol_type': 'INET',
          'ip': 'dhcp',
          'dia': true
        },
        {
          'name': 'port2',
          'role': 'wan',
          'ol_type': 'INET',
          'ip': 'dhcp',
          'dia': true
        },
        {
          'name': 'port5',
          'role': 'lan',
          'ip': lan_ip
        }
      ]
    }     

  }
%}

RESULT: The overlay tunnels will be called H1_INET and H1_INET_2.

And here is how you would define a Full-Mesh profile (note how the same WAN interface appears twice!):

# Device Profiles #}
{% set profiles = {

    'FullMesh': {
      'interfaces': [
        {
          'name': 'port1',
          'role': 'wan',
          'ol_type': 'ISP1',
          'ip': 'dhcp',
          'dia': true
        },
        {
          'name': 'port2',
          'role': 'wan',
          'ol_type': 'ISP2',
          'ip': 'dhcp',
          'dia': true
        },
        {
          'name': 'port1',
          'role': 'wan',
          'ol_type': 'ISP2'
        },        
        {
          'name': 'port2',
          'role': 'wan',
          'ol_type': 'ISP1'
        },
        {
          'name': 'port5',
          'role': 'lan',
          'ip': lan_ip
        }
      ]
    }        

  }
%}

RESULT: The overlay tunnels will be called H1_ISP1, H1_ISP2, H1_ISP2_2 and H1_ISP1_2.

Notes:

• There is no change to the naming conventions for the profiles that do not use these topologies. The indexes are only added when otherwise there would be a name conflict

• Note that the indexes do not represent an ordinal number of a WAN interface. They are merely added to avoid the naming conflict, the exact value of the index does not signify anything in particular.

We also offer a more explicit manual option, for those who don't like the automatic (and quite meaningless) indexes described above. We introduce a new parameter ul_name that can be configured for an interface in the profile. It represents the name of the local transport to which the interface in question is connected.

Whenever the value of ul_name is set, all the tunnels terminated on this interface will use the following naming convention:

<ul_name>-H<hub_index>_<ol_type>

As you can see, the tunnel name now includes the "local side". And here is how you would define the "Full-Mesh" profile:

# Device Profiles #}
{% set profiles = {

    'FullMesh': {
      'interfaces': [
        {
          'name': 'port1',
          'role': 'wan',
          'ul_name': 'ISP1',
          'ol_type': 'ISP1',
          'ip': 'dhcp',
          'dia': true
        },
        {
          'name': 'port2',
          'role': 'wan',
          'ul_name': 'ISP2',
          'ol_type': 'ISP2',
          'ip': 'dhcp',
          'dia': true
        },
        {
          'name': 'port1',
          'role': 'wan',
          'ul_name': 'ISP1',
          'ol_type': 'ISP2'
        },        
        {
          'name': 'port2',
          'role': 'wan',
          'ul_name': 'ISP2',
          'ol_type': 'ISP1'
        },
        {
          'name': 'port5',
          'role': 'lan',
          'ip': lan_ip
        }
      ]
    }        

  }
%}

RESULT: The overlay tunnels will be called ISP1-H1_ISP1, ISP2-H1_ISP2, ISP1-H1_ISP2 and ISP2-H1_ISP1.

Although this method uses more characters, it is also more human-readible. Looking at the tunnel name, you can clearly see from what local link and to what remote link it builds the tunnel.