Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

VMware SD-WAN Edge Interface Types and WAN Overlay (74846)

Last Updated: 3/21/2024Categories: InformationalTotal Views: 24809Language:
English

54 like this article

Subscribe to get an email
newsletter with new updates

54 people found this helpful Please provide article feedback:

Purpose

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.

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.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

KB
•
Download and Install VMware Fusion (2014097)

Results 1-2 of 2

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

Related Versions:

VMware SD-WAN by VeloCloud

Take Our Survey

Support Assistant