VMware SD-WAN Edge Interface Types and WAN Overlay
search cancel

VMware SD-WAN Edge Interface Types and WAN Overlay

book

Article ID: 303415

calendar_today

Updated On:

Products

VMware SD-WAN by VeloCloud

Issue/Introduction

This document provides details of various interface types supported by a VMware SD-WAN Edge and then covers the difference between interfaces, sub-interfaces, and the WAN overlay and how they interact.


Environment

VMware SD-WAN by VeloCloud

Resolution

Interface Types

Each VMware SD-WAN Edge model line has a different number of interfaces.  Each Edge model will present a different combination of interfaces which are by default either L2 switched or L3 routed. Beginning with Release 3.1.0, a user may configure the Edge to convert all L2 switched interfaces into L3 routed interfaces.  Edge models that may be so configured include the Edge 510, 6x0 (610/620/620N/640/640N/680/680N), 840, 2000, 3x00 (3400/3800/3810), and all types of Virtual Edge. 

Note: Edge models 500 and 520/540 do not have this capability.

 


Configuring an interface is done by navigating to Configure > Edge > Device > Interface Settings on the VMware SD-WAN Orchestrator.  For the interface you wish to configure, select Edit.

An L2 switched interface may be configured as either an access or trunk port with associated VLAN IDs. Then a VLAN interface (similar to SVI in the Cisco IOS) is automatically created once one or more VLANs are assigned to the L2 switchport.

One area of concern for those getting started with VMware SD-WAN is that the above table indicates you may only bind a WAN overlay to a physical interface. A user may question how the VMware SD-WAN Edge would support a scenario where an interface from an upstream switch or the service provider (SP) is configured with 802.1Q and carries one or more VLANs? The answer is that the Edge supports building multiple WAN overlays with different 802.1Q VLAN IDs from the same L3 primary port. This is covered in detail in the "Multiple Overlays Per Physical Interface and Sub-Interface" section later in this article.

WAN Overlay

A WAN overlay may be configured as Auto-Detect or User Defined. By default, all routed interfaces are configured to Auto-Detect the tunnel. 

When configured for default Auto-Detect, every routed interface, once an IP address is assigned, will send a tunnel initiation packet toward the closest VMware SD-WAN Gateway assigned by the Orchestrator. If the tunnel initiation packet reaches the Gateway, the Gateway will respond and the tunnel will be created automatically and reported to the Orchestrator.

In the above topology, assuming the WAN overlay remains as the default for all interfaces (auto-detect), there will be no tunnel created on the interface facing the LAN switch. However, if the MPLS has Internet breakout or the tunnel initiation packet can reach the Gateway from the MPLS, the tunnel will be automatically created as a public overlay over the MPLS network. This is an undesired behavior because the Edge will not be able to differentiate between the private and public overlay.

Note: If a site lacks public WAN overlays, and there is a need to use the MPLS link for the WAN overlay to the Gateway, check the setting SD-WAN Service Reachable.  This option is available only if the WAN overlay is User Defined. 



When using the SD-WAN Service Reachable option, please ensure that the MPLS network has proper routing configured for all Public SD-WAN Addresses (listed below the option) so they are reachable via the MPLS network.

Key Points: To ensure correct behavior in this topology: 

  • For an interface that uses an MPLS link only, configure the WAN Overlay setting for User Defined Overlay.

  • If a site lacks public WAN overlays, and there is a need to use the MPLS link for the WAN overlay to the Gateway, check the setting SD-WAN Service Reachable.

  • For an interface that does not need the WAN Overlay, e.g. LAN-side facing, uncheck the WAN overlay checkbox. This interface will handle non-tunnel traffic only.

  • For an interface that has a WAN overlay and is also used to send traffic to the LAN side, e.g. off-path insertion design, check the WAN Overlay checkbox.

WAN Overlay Options

1. One Overlay Per Physical Interface


The above topology represents a typical hybrid WAN branch. The Gateway terminates two WAN interfaces, one public and one private. Note: the Edge can terminate the MPLS interface directly if it is Ethernet (copper or fiber). In this scenario, there is a one-to-one relationship between the physical interface and WAN overlay. The physical interface itself can be configured for 802.1Q as well. The WAN overlay bound to the interface inherits all the networking information including IP address, next-hop, and VLAN ID.

2. Multiple Overlays Per Physical Interface


This example topology shows another scenario where the Edge terminates only ONE physical interface. However, in this instance there is an upstream switchport which is configured as trunk to pass multiple VLANs with different 802.1Q tags to the Edge. This is typical for some service providers (SP) that choose to deliver both MPLS and Internet over the same physical interface.
 
This may be an area of confusion for those that already familiar with Cisco or Juniper routers. Traditionally with a router, you always tie the tunnel source to an interface or a sub-interface. That is not the case when using an SD-WAN Edge.

From the Edge configuration perspective, the WAN overlay just needs to be associated with a physical interface. There is an additional configuration section within the WAN overlay to specify the IP address, next-hop, and VLAN ID if they differ from the physical interface to which the WAN overlay is bound.

Let’s assume this interface is GE3. The SP provides two VLAN IDs: 101 and 102, over this interface. We need to configure the corresponding WAN overlay for both public and private networks. 

The GE3 is configured with the IP address of the first VLAN on this interface, which is VLAN 101 and its corresponding IP address and next-hop to reach the Internet.


The next step is to create the WAN overlay that is bound to this interface. This is a public WAN overlay and since we will use the same IP address, next-hop, and VLAN ID for building this overlay, it can inherit the information from the physical interface (GE3) to which it is bound. The optional configuration is left empty.


Next we will configure the second WAN overlay over this same port (GE3). This will be for the private WAN overlay. Since the IP address, next-hop, and VLAN ID assigned to the private network is different from what is configured on the physical interface, we will need to specify the optional configuration in the WAN overlay.


These configurations are sufficient to create two WAN overlays--one for the public network using VLAN 101, and another for the private network using VLAN 102, with both over the same physical interface (GE3).

3. Multiple Overlays Per Physical Interface and Sub-Interface

When is a sub-interface required? A sub-interface is not needed to create a WAN overlay since the IP address, next-hop, and VLAN ID are configured in the WAN overlay itself. Also, the WAN overlay is bound to a physical interface only, and not to a sub-interface. As a result, an IP address (whether or not it is an IP address used by a WAN overlay) must be assigned to the physical interface.

A sub-interface is required for performing routing protocol peering (i.e. BGP or OSPF), and to be able to send the traffic into the underlay for those routes learned through a routing protocol or static route. There must be a corresponding interface or sub-interface to receive and send the underlay traffic.

The previous scenarios only focused on building a WAN overlay over a private network.  But those scenarios did not include a requirement to do any BGP or OSPF peering over the private network with a Service Provider’s (SE) Provider Edge router (PE), or send the traffic into the MPLS underlay. 

Consider the following topology:  

 


This topology adds the requirement that the Edge needs to do BGP peering with the SP PE over VLAN 102. We already have the WAN overlay created for the private network through VLAN 102 using IP address 10.211.0.2 and next-hop 10.211.0.1. Note that 10.211.0.1 is the SP PE router which is also running BGP. 

In order for the Edge to establish BGP (or OSPF) peering with the SP PE, it requires a sub-interface:

 


Then you will be able to configure BGP (or OSPF) peering to 10.211.0.1. The Gateway field can also be left blank. For any routes learned through the BGP or OSPF peering, the Edge will send the traffic into the underlay using the sub-interface.

Summary

Below are the key takeaways and best practices for using WAN overlay and sub-interfaces:

  • WAN overlay can be specified only on the routed interface.

  • Disable WAN overlay on interfaces that do not need one (for example, LAN-facing interfaces).

  • Configure user-defined overlays for interfaces that connect to a private network.

  • The WAN overlay is bound to the physical interface only. VMware SD-WAN can specify the IP address, next-hop, and VLAN ID at the WAN overlay level so if you only need to build the overlay, a sub-interface is not required.

  • A sub-interface is needed if there are multiple VLANs carried over the same physical interface, and there is a need to do BGP or OSPF peering or sending traffic into the underlay (for a particular VLAN ID).

  • An IP address must always be assigned to the physical interface regardless of whether or not that IP address will be used for user defined overlays.

 

Powered by Wolken Software