TestDrive

VMware SD-WAN - TestDrive Lab Guide

Updated on

VMware SD-WAN delivers a highly reliable and secure application-centric service for even the most latency-sensitive applications, independent of the underlying links.  This is achieved by leveraging a simplified cloud-based platform that delivers the required business agility, performance, and simplicity.  VMware SD-WAN ensures the secure delivery of traffic across various transports including the internet.  It uniquely delivers simplified management with elimination of traditional CLI-based configuration and monitoring.

Follow the steps below for a walkthrough of the VeloCloud lab environment.

Before you Begin

In order to complete this product walkthrough please make sure you have the following:

  • A valid account in the VMware TestDrive environment, sign up here if you do not have one.
  • TCP & UDP ports 80, 443, 8443; and if using PCoIP, both TCP & UDP 4172
  • An Horizon Client installed on your machine.

Section 1:  Enabling a VMware SD-WAN Lab Instance and Accessing the RDSH Jumpbox

First, open a web browser of your choice and navigate to portal.vmtestdrive.com. Select LOG IN. If you do not already have an account, please reference the instructions found here.

Enter your TestDrive Username and Password and select ENTER.

Next, locate the VMware SD-WAN product under the Security tab.  Toggle Enable Product switch to enable a lab instance for your account.

You'll get a notification that the product is being turned on for your account. Once the provisioning is complete, the SD-WAN service will update and show a count down timer. This is how much time you have left to use your SD-WAN environment.

Once the service finishes provisioning, expand the product tile to see the information and credentials you will need for the lab.

The credentials section shows you the TestDrive Credentials username and password to use for Workspace ONE to access the Horizon Desktop.  This section also shows URLs and credentials you will need for your lab instance.  Please refer back to these credentials as you follow the steps in the guide.

Click LAUNCH and LAUNCH VIA WORKSPACE ONE.

A new tab will open with Workspace ONE. Enter your TestDrive Username and Password, then hit Sign In.

Next, search for SD-WAN.  In the search results, click on the VMware SD-WAN desktop icon to launch the RDSH desktop via HTML access or Horizon Client access.

Now you'll be on the VMware SD-WAN RDSH desktop.

Section 2:  Accessing the Connections Home Page and the Orchestrator

Within the VMware SD-WAN RDSH desktop, launch Google Chrome from the shortcut on the desktop and enter the Guacamole URL listed in the SD-WAN product tile on the TestDrive portal and hit Enter.

Below is an example of the formatted URL to enter.  Please use the one listed in your own Portal view.

At the Guacamole login screen, enter the Username and Password listed in your own Portal view.

After successful login, you will be presented with the Home Page which gives you access to all the sites and devices.

To access sites with + sign, expand the connection by clicking on the + sign.  The below figure shows expansion of the DC1 Site.  Expanding a site allows you to access all the resources available for that site.

With the multiple connections shown, you have the option to click on a connection to access it and use the browser back button to navigate back to the home page to access other connections or you can right click on each connection to open it in a separate browser tab.

Below is an example of using a right click to open the DC1-CLIENT-01 in a new browser tab.

To access the Orchestrator, open a new browser tab and go to https://vco12-usvi1.velocloud.net OR launch the VCO 12 shortcut found on the desktop.

At the Orchestrator login screen, enter the VCO Username and VCO Password listed in your own Portal view, then click the LOGIN button.

After successful login, you will be taken to the Network Overview page.  Proceed with the next steps of the walkthrough guide.

Lab Design Walkthrough

High-Level Architecture

The topology has the following sites - 

  • Data Centers – 2 (Data Center 1, Data Center 2) 
  • Branches – 2 (SFO Branch, NYC Branch) 

The topology has the following WAN Circuits – 

  • DHCP-based Internet Access at all sites. Each site has its own public IP. 
  • Private MPLS Access at all sites. 

VMware SD-WAN components in this topology – 

  • Edges are deployed in the Data Centers and the Branches.  
  • VMware-hosted Orchestrator to manage and monitor the SASE network. 
  • VMware-hosted SASE POPs which provide Gateway and Security services.  


More information on the components here

Data Center Design

  • Each Data Center will have a VMware SDWAN Cluster of 2 Edges each. 
  • Each Edge in the Cluster will – (LAN side config) 
    • Connect on the LAN side on GE2 to DC(X)-SW-01 (Core at the Data Center). 
    • In the Global Segment, form BGP Peering with DC(X)-SW-01 and receive routes of local subnets and the DCI routes. 
    • Advertise to the DC(X)-SW-01, routes from the Branches. 
  • Each Edge in the Cluster will – (MPLS side config) 
    • Connect to MPLS Router on GE4. 
    • Be configured with a static IP. 
    • Form tunnels over MPLS with Branch Edges. 
  • Each Edge in the Cluster will – (Internet side config) 
    • Connect to Internet Router on GE3. 
    • Receive a DHCP IP. 
    • Form tunnels over Internet with Branch Edges. 
  • The Edges will connect to the VMware SASE Orchestrator and SASE Gateways over Internet. 

Branch Design

SFO Branch

  • SFO has a VMware SDWAN Edge.
  • LAN side -
    • Edge is connected to the switch SFO-SW-1 on GE2.
    • Edge is connected to Client SFO-Guest-1 on GE5.
    • In the Global Segment, the Edge will form BGP Peering with SFO-SW-1.
    • In the Guest Segment, create a sub interface on GE5 and advertise this subnet to the overlay. This sub interface will be the default gateway for all the guest users at the site.
  • WAN side -
    • Edge is connected to Internet router on GE3.
    • Edge is connected to MPLS router on GE4.
    • The Edge will form overlay tunnels to its Data center hubs over Internet and MPLS.

NYC Branch

  • NYC has a VMware SDWAN Edge.
  • LAN side -
    • Edge is connected to the switch NYC-SW-1 on GE2. 
    • In the Global Segment, the Edge will form BGP Peering with NYC-SW-1. 
  • WAN side -
    • Edge is connected to Internet router on GE3.
    • Edge is connected to MPLS router on GE4.
    • The Edge will form overlay tunnels to its Data center hubs over Internet and MPLS.

Profiles

This page will display the Profiles that are already created and how many Edges they're being used by. The Quick Start Profile is a default profile that isn't used in this lab. The Branch Profile is being used by the NYC and SFO branches. The data centers are each using their own profile.

With VMware SD-WAN, all configurations start with a Profile. The Profiles provide a configuration template that can be applied to multiple Edges. When an Edge is attached to a Profile, it inherits the configuration so that only the site-specific information such as IP addresses will be required. Future configuration updates are also automated because any changes made to the Profile will be pushed to all the Edges attached to that Profile.

In this lab environment, there are four profiles that are already created but with minimal configuration. In the following steps, well introduce you to our Profiles in the Orchestrator.

1.   In the Orchestrator, select the Configure tab and then on the left menu, select Profiles.

This page will display the Profiles that are already created and how many Edges they're being used by. The Quick Start Profile is a default profile that isn't used in this lab. The Branch Profile is being used by the NYC and SFO branches. The data centers are each using their own profile.

2.   From the Profiles page, select the DC1-Hub-Profile

This should bring you to the Device configuration where you'll find configuration for interfaces, VLANs, routing, overlay tunnels, and any other general networking features.

3.   On the DC1-Hub-Profile, scroll down to and expand the Cloud VPN section under VPN Services.

The Cloud VPN configuration controls how overlay tunnels are built between Edges. At hubs, the only required configuration is to turn the Cloud VPN feature on. Thats because the hubs will respond to the branches that attempt to build tunnels. Well explain this section in more detail later in the guide.

4.   Continue scrolling to BGP under the Routing & NAT section

This section has also come preconfigured in the lab with the local ASN and a filter list. The only thing required for BGP on a specific Edge would be adding the neighbor information.

Edge Provisioning

After the Profile is configured, an Edge can be deployed. The Edge needs to be attached to a Profile and then any site-specific information such as IP addresses should be configured. Once the specific Edge configuration is completed, it can be activated. 

There are two methods of activation: Auto-Activation and Email Activation. With Auto-Activation, the Edge only needs to be powered on and connected to the Internet. The email activation requires a user at the site to connect to the Edge and then click a URL that was provide by the Orchestrator. While the email activation does require a manual step, its made with non-technical people in mind that may be doing the installation. It also supports automatically provisioning static IP addresses whereas Auto-Activation will require DHCP on the Internet circuit. More info on both methods can be found in the References section.

All the Edges in this lab have already been created and activated. To demonstrate the process of provisioning an Edge, we’ll walk through creating a sample Edge in the following steps. 

1.   In the Orchestrator, select the Configure tab and then on the left menu, select Edges.

This screen will display all Edges that are configured, what Profile they’re using, their software version, and other information. You should see the six Edges that are already created for the lab here.

2.   On the Edge configuration page, click Add Edge.

The Provision an Edge screen will appear and allow you to configure the Edge Name, model, profile, and other options.

For this example, add the Edge with the following information, everything else can be left default for now:

  • Name: Test-ZTP
  • Model: Virtual Edge
  • Profile: Branch Profile
  • Edge License: ENTERPRISE 10 Gbps

3.   Click Next and then on the following screen, click Add Edge

4.   Explore the Edge configuration that was inherited from the Profile.

After adding the Edge, you’ll be taken to the device configuration page. Before the Edge is activated, you’ll see the activation key displayed at the top of the page. We also haven’t added much to the Branch Profile yet but you can still see some differences from the Profile configuration in the previous section. For example, you won’t be able to make many configuration changes here because we want to enforce standardization across your sites whenever possible. When a site does need a unique configuration that differs from the Profile, you can use the Override check box.

5.  Go to the Overview tab

When using the email activation method, this is done from the overview tab. After sending the activation email to the on-site personnel, they’ll connect to the Edge and click the URL provided in the email. This URL will tell the Edge the Orchestrator name, the activation key, and will automatically provision any static IP addresses for Internet circuits. 

Clustering and High Availability

For physical device redundancy, there are two different options depending on the use case.

High Availability (HA) operates by connecting two Edges together that become mirror images of each other and are managed and configured as a single device. The Edges are deployed to a site as a pair and will be in an Active/Standby mode. If the Active Edge loses connectivity or a physical interface goes down, well failover to the standby device. While the Edges are in an Active/Standby mode, its important to note that well use all WAN circuits as Active/Active even when theyre connected to our Standby Edge.

While Clustering does provide redundancy, the main use case for clustering is for scale. HA is limited to the scale of a single device whereas clustering essentially combines the resources of multiple Edges. All devices in the cluster are Active and will be managed separately. The Orchestrator will automatically control which cluster member that branch Edges will build tunnels to.

Due to limitations of this lab environment, we cant show HA but well configure Clusters for the two data centers. For more information on HA, please see the references section.

Configuration Exercise: Clustering at the Data Centers

In the following steps, we’ll create two clusters, one for each data center.

1.   Navigate to the Configure tab and then click Network Services on the left.

2.   Under the SD-WAN Destinations section, open Clusters and Hubs, and then click New.

For DC1, name the cluster DC1-Cluster and select the checkboxes for DC1-VCE-01 and DC1-VCE-02. Save changes.

3.   Repeat the previous step for DC2.

4.   You should now see two clusters listed, each with two edges.

5.   Navigate to the Monitor tab.

On the Network Overview tab, you should see that all four of the DC Edges have Cluster listed in the HA column.

6.   Navigate to the Network Services tab on the left. Then select Edge Clusters.

This page should display your clusters and provide an overview of their resource usage.

Interfaces

In this reading exercise, you will understand how interfaces are configured in VMware SDWAN.

The exercise will review the interface configuration on DC1-VCE-01. The steps can be followed to review configuration on other Edges.

1.  Navigate to the Configure tab and then click Edges on the left panel.

2.   Select DC1-VCE-01. The Device tab on the edge will be visible.

 This will take you to the device configuration tab. 

3.   Scroll down and expand the Interfaces section under Connectivity. This will list all the interfaces on the Edge. Review the following

  • Interfaces GE1 to GE8 are listed. This will depend on device type. For device type = virtual, these interfaces will be listed.
  • GE3 has a DHCP address, WAN link is configured as ‘Auto-Detect’. This is the Internet facing WAN interface.
  • GE3 has a Static address, WAN link is configured as ‘User Defined’. This is the MPLS facing WAN interface.
  • GE2 has a Static address, WAN link is not enabled. This is the LAN facing interface of the Edge.

4.   Click on GE3.

This will bring in the interface-specific configuration on this interface. 

Notice that ‘Enable WAN Link’ is checked. This configuration is required for all WAN facing interfaces. 

5.   Scroll down to the IPv4 Settings to look at addressing information. 

Notice that ‘Addressing Type’ is set to DHCP.

6.   Click on CANCEL to go back to the Interfaces list. Then Click on GE4.

Notice that ‘Enable WAN Link’ is checked.

7.   Scroll down to the IPv4 Settings to look at addressing information.  

Notice that ‘Addressing Type’ is set to Static with an IP Address, CIDR Prefix, and Gateway configured. 

8.   Click on CANCEL to go back to the Interfaces list. Click on GE2.

Notice that ‘Enable WAN Link’ is not checked. This is the required configuration for LAN (Non-WAN) interfaces at a site. 

9.   Scroll down to the IPv4 Settings to look at addressing information. Notice that ‘Addressing Type’ is set to Static with an IP Address, CIDR Prefix and Gateway configured.

Overlays

An SD-WAN overlay is a virtual network that sits on top of an existing physical network. VMware SD-WAN provides different overlay options for connecting to private (MPLS) or public (Internet) networks.

In this section, you will learn about how WAN interfaces and overlays are configured in the VMware SDWAN solution.

In the Lab, Internet overlays are pre-configured for all the sites. MPLS overlays are preconfigured for the Data Center Edges.

We will first look at how the WAN Overlays are configured for the Data Center Edge. We will specifically look at how DC1-VCE-01 is configured. Other Data Center Edges can be reviewed in a similar way.

1.  Navigate to the Configure tab and then click Edges on the left panel.

Select DC1-VCE-01

Scroll to the Interfaces section under Connectivity.

Expand Interfaces.

2.  Continue to scroll down to the WAN Link Configuration section.

Two WAN Links have been defined  one each for Internet and MPLS.

3.  Click on the WAN Link with Type ‘Auto Detect’ – Amazon.com.  

When configured as 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. As you can see below, the Name of the Provider – ‘Amazon.com’ and the public IP address of this WAN interface is automatically detected by the solution. 

4.  Click on CANCEL to go back to the list of WAN Links. Now click on the WAN Link with type User Defined - MPLS.

User Defined links are typically Private Links. Review the configuration on this WAN Link.

  • Link type is set to ‘Private’. 
  • A name is entered.  
  • SD-WAN Service Reachable is checked. If a site lacks public WAN overlays, and there is a need to use the MPLS link to communicate with the VMware SDWAN Gateway, check the setting SD-WAN Service Reachable.  This option is available only if the WAN overlay is User Defined. This option is a recommended setting even if the site has a public WAN Overlay to ensure management redundancy. 
  • Interface GE4 is checked. This will ensure that this Overlay is formed on Interface GE4. 

5. To monitor the interfaces and the overlays, select Monitor from the top menu and select Edges from the left panel. Click on DC1-VCE-01.

  1. In the overview section, the two overlays will be listed.
    • The MPLS overlay is formed over Interface GE4. Latency, Jitter and Packet loss can be viewed here too.
    • The Internet overlay is listed as Amazon.com. It is formed over Interface GE3.

In the next exercise, Private MPLS interface and overlays for the Branch Edges will be configured.

Configuration Exercise: Interface and Overlays

1. Navigate to the Configure tab and then click Profiles on the left panel. Select Branch-Profile.

2.   Scroll to the Interfaces section under Connectivity. Expand Interfaces.

3. Click on GE4.

Configure the following

  • Description = MPLS WAN
  • Verify Enable WAN Link is checked.

4. Scroll down to the IPv4 settings and configure the following

  • Addressing Type = Static
  • WAN Link = User Defined.
  • Click on SAVE.

5.   Click SAVE CHANGES.

6.   Click on Edges on the left panel and select SFO-VCE-01.

7.   Scroll to the Interfaces section under Connectivity. Expand Interfaces and click on GE4.

8.   Verify that the description and other configuration is inherited from the Profile for all the interfaces.

9. Scroll to the IPv4 Settings section and configure the IP on the interface

  • IP Address = 172.16.25.1
  • CIDR Prefix = 24
  • Gateway = 172.16.25.2
  • Click SAVE

10.   Scroll down to the WAN Link Configuration section. Click on ADD USER DEFINED WAN OVERLAY to add the Private MPLS Overlay.

11. Configure the following

  • Link type = Private
  • Name = MPLS
  • Check SD-WAN Service Reachable

12.   Scroll down and select GE4 as the interface for this overlay. Then click on UPDATE LINK.

13.   Click on SAVE CHANGES to complete the configuration.

Cloud VPN

The Cloud Virtual Private Network (VPN) allows a VPNC-compliant IPsec VPN connection that connects VMware SDWAN Edges and VMware SDWAN Edges to Non SDWAN Destinations. 

Cloud VPN supports the following traffic flows: 

  • Branch to SD-WAN Hub – 

The SD-WAN Hub is an Edge deployed in Data Centers for branches to access Data Center resources. In this lab, Clusters in DataCenter1 and DataCenter2 will be setup as hubs for the two branches. This will be configured at the profile level i.e. Branch-Profile.  

In the diagram below, SFO Branch forms Tunnels to both datacenters on all common WAN circuits – Internet and MPLS.  

  • Branch to Branch VPN – 

Branch to Branch VPN supports configurations for establishing a VPN connection between branches for improved performance and scalability.  

Branch to tunnels can be of two types – 

  • Branch to Branch Transit – 

In this scenario, the branch-to-branch traffic will traverse the hubs.  

  • Branch to Branch Dynamic – 

In this scenario, the branches will form dynamic tunnels with each other whenever there is traffic between them. The tunnels will be torn down if there is no traffic for a period of 300 seconds. 

In this lab, the branches will form dynamic branch to branch to tunnels with each other. In the diagram below, the SFO and NYC branches form tunnels over all common WAN circuits – Internet and MPLS. 

Configuration Exercise: Cloud VPN

In this exercise, you will configure Cloud VPN for the branches. Note that all Cloud VPN configuration is done at the Profile level.

  1. Select the Monitor tab on the top. Select Network Overview on the left panel.

Confirm that SFO-VCE-01 and NYC-VCE-01 only have 1 link in the Links column. This is because currently they only have a tunnel formed towards the Gateway.

  1. Select the Configure tab and then on the left menu, select Profiles. Click on Branch-Profile.

 

  1. On the ‘Branch-Profile’, scroll down to the VPN services section and expand Cloud VPN.  

Configure the following – 

  • Turn on Cloud VPN. 
  • Check Enable Branch to hubs. 
  • Click on EDIT HUBS on the right. 
  1. In the Add Hubs screen, check the required Edge Clusters  DC1-Cluster and DC2-Cluster and click on the right pointing arrow between the two columns as highlighted in the picture below.
  1. The final configuration should mirror the picture below. Once done, Click on UPDATE HUBS at the bottom right.
  1.  The configuration screen goes back to the Profile page.   Scroll to the Branch-to-Branch VPN section.

 

  1. Configure the following – 
    • Check Enable Branch to Branch VPN 
    • Select Hubs for VPN. Hubs will be used for the first few packets of the session while the dynamic tunnels are built. 
    • Click on EDIT HUBS on the right. 
  1. In the Add Hubs screen, check the required Edge Clusters  DC1-Cluster and DC2-Cluster in the Hubs column and click on the right pointing arrow between the two columns as highlighted in the picture below.
  1. The final configuration should mirror the picture below. Once done, Click on UPDATE HUBS at the bottom right.
  1. Once back to the Profile Page, click SAVE CHANGES on the bottom right.
  1. These changes at the Profile Level will be applied to Edges using this profile. To verify this, select Edges from the left panel and click on SFO-VCE-01. Scroll down to the Cloud VPN section and expand it. The configuration should mirror the profile.
  1. To verify, if the tunnels are up, select Diagnostics on the top menu. Select Remote Diagnostics from the left Panel. This will display all the edges. Now click on SFO-VCE-01.
  1. It will take a few seconds for the Edge diagnostics to load. The diagnostics page will provide a list of commands that can be run directly on the Edge. Scroll down to find the List Paths command.

14. Select the desired Peer under List Paths.

  1. Select DC1-Cluster from the dropdown and click on RUN.

It should show the two paths  one over each WAN Circuit. Note that the Internet Link will be listed as Amazon since the lab runs on AWS. Note the Local and remote IPs in both cases. The remote IP will be the WAN interface IP of the Edge in DC1-Cluster that SFO-VCE-01 connects to. Check to see if the VPN is UP and note the other parameters like Bandwidth, Latency, Jitter, Loss. Also make a note of the Mode. Since this is a Branch to Hub tunnel, the Mode will be static.

16. Select DC2-Cluster from the dropdown and click on RUN and verify all the fields.

  1. Select Gateway from the dropdown and click on RUN.

Note that the Edge connects to multiple Gateways over both Internet and MPLS (since SDWAN Reachable is turned ON).

  1. To continue the verification, select Monitor from the top menu and select Edges from the left panel. Click on SFO-VCE-01.

In the overview section. Verify that there are two links listed  Internet and MPLS. See details of the WAN circuits like Interface, Throughput/Bandwidth, Latency, Jitter and Loss.

  1. Select Paths from the menu on the top.

Verify that one Edge from DC1-Cluster and one Edge from DC2-Cluster is listed.

  1. Click on the Edge from DC1-Cluster (DC1-VCE-01 for example).

This will retrieve statistics for all the paths towards DC1-VCE-01. Use the dropdown to see different path stats like average throughput, Bandwidth, Latency, Jitter, Loss on each path.

  1. Repeat all the steps to verify tunnels between NYC-VCE-01 and the Data Centers.

22. Note that the Branch-to-Branch VPN tunnels between SFO-VCE-01 and NYC-VCE-01 are not up yet. These tunnels will be up when you simulate traffic between the branches. This will be done in the Connectivity section.

Routing - BGP

In the VMware SDWAN solution, BGP can be configured either on the LAN (towards L3 routers at the site) or the WAN (towards a CE/PE to get all underlay routes from a Private WAN). 

In the lab, BGP will be used on the LAN of all the sites.  

BGP will be configured on both the Profile level and the Edge level. 

In DataCenter1 – 

  • Each Edge in the Cluster forms BGP with DC1-SW-01.  
  • Each Edge in the Cluster will advertise to DC1-SW-01, subnets from Branches that it has formed SD-WAN overlay tunnels to. 
  • The Cluster will receive routes from DC1-SW-01, subnets of local resources at the DC – 10.101.1.0/24 and subnets from the DCI from Data Center2 – 10.102.1.0/24. 

Lets do a walkthrough of the BGP configuration on DC1-VCE-01.

  1. In the Orchestrator, select the Configure tab and then on the left menu, select Profiles.

 

  1. Select DC1-Hub-Profile and scroll down to the Routing & NAT section and expand the BGP section. 

Note the following – 

  • BGP is turned ON. 
  • Local ASN is configured. The same ASN can be applied to multiple edges or this can be overridden with a different ASN. 
  • Filters are configured. These filters can be used by any Edge using this Profile. The Filter “deny_default_accept_all” has two entries – 
    • The first entry is to deny a default route. Note that the “Exact Match” field is checked. 
    • The second entry will accept all other routes from the neighbor. 
  1. To view the Edge specific BGP configuration, select the Configure tab and then on the left Menu, select Edges. Click on DC1-VCE-01.
  1. On the devices tab, scroll down to the Routing & NAT section and expand the BGP section. 

Note the following – 

  • BGP is turned ON. This is inherited from the Profile. 
  • Local ASN is configured as 65002.  
  • Filters are inherited from the Profile. 
  • Neighbor is configured. 
    • Neighbor IP is 10.101.2.1. 
    • Neighbor ASN is 65001. 
    • Inbound and outbound filter is set to the filter inherited from the Profile. 

 

  1. To monitor the status of BGP, navigate to the Monitor tab on the top and click on the Routing tab on the left menu. Then click on BGP Edge Neighbor State on the right. 

Note the following – 

  • Edge Name = DC1-VCE-01 
  • Neighbor IP details 
  • Verify State is “Established”.  
  1. To get additional details on BGP, navigate to the Diagnostics tab on the top and click on Remote Diagnostics on the left menu.
  1. Click on DC1-VCE-01 and scroll down to the Route Table Dump section and click on Run on the right.
  1. Verify the routes and look for routes with Type = BGP in the output.
  1. Scroll down to the Troubleshoot BGP - Show BGP Summary section and click on Run. Verify the BGP neighborship output.
  1. Scroll down to the Troubleshoot BGP - Show BGP Table section and click on Run. Verify the routes.

Configuration Exercise: BGP at the branches.

In this exercise, you will configure BGP at SFO-VCE-01. 

At the SFO Branch, 

  • The Edge will form BGP with SFO-SW-01.  
  • The Edge will advertise to DC1-SW-01, subnets it learns on the overlay from the Data Center Clusters – 10.101.1.0/24 and 10.101.2.0/24. 
  • The Edge will receive routes from SFO-SW-01, local subnets at the site – 10.21.2.0/24. 
  1. In the Orchestrator, select the Configure tab and then on the left menu, select Profiles.

 

  1. Select Branch-Profile and scroll down to the Routing & NAT section and expand the BGP section.  

Configure the following – 

  • Turn ON BGP. 
  • Configure Local ASN = 65012 
  • Click on SAVE CHANGES on the bottom right. 
  1. To configure the Edge specific BGP configuration, select the Configure tab and then on the left Menu, select Edges.
  1. Click on SFO-VCE-01. On the devices tab, scroll down to the Routing & NAT section and expand the BGP section. Check the ‘Override’ option. 

Override will allow to edit configuration at the Edge Level. 

  1. Scroll down to the Neighbors section and click ‘+’ button. 

Configure the following – 

  • Neighbor IP = 10.21.1.1 
  • ASN = 65011 

Note the ‘Additional Options’ section with different BGP neighbor options. 

Click SAVE CHANGES on the bottom right. 

 

  1. To monitor the status of BGP, navigate to the Monitor tab on the top and click on the Routing tab on the left menu. Then click on BGP Edge Neighbor State on the right.  

Note the following –  

  • Edge Name = SFO-VCE-01  
  • Neighbor IP details  
  • Verify State is “Established”.   

 

  1. To get additional details on BGP – 
    • Navigate to the Diagnostics tab on the top.  
    • Click on Remote Diagnostics on the left menu.  
    • Click on SFO-VCE-01.  
    • Scroll down to the “Route Table Dump section”.  
    • Click on “Run” on the right.  

Verify the routes and look for routes with Type = “BGP” in the output.  

 8.     Scroll down to the “Troubleshoot BGP – Show BGP Summary” section and click on Run. Verify the BGP neighborship output.  

 9.   Scroll down to the “Troubleshoot BGP – Show BGP Table” section and click on Run. Verify the routes.   

  1. Perform the same configuration and verify routes on NYC-VCE-01.

Overlay Flow Control

The Overlay Flow Control (OFC) page displays a summarized view of all the routes in your network. Along with the routes, information such as what site is advertising the route, route type, and the metrics are included. Its important to note that this is the view of the overall control plane of the network and the routing table of an individual Edge may differ due to configuration or potential routing issues.

OFC also provides the ability to change VPN exit preferences and global advertise flags. These configurations should rarely be modified and wont be covered in this guide. The reference documentation will provide additional information on these sections.

The following steps will provide an overview of how to navigate the OFC page.

  1. Select the Configure tab and then on the left menu, select Overlay Flow Control.

You should now be on the Overlay Flow Control page where you can browse the routes in the network or use the search box to find specific routes or sites.

  1. Click the arrow on the left to expand the first route 10.101.1.0/24

This is the route for DC1 but it is also advertised across the data center interconnect to DC2. You can observe the four Edges that are advertising the route as well as the route type.

  1. Under the Route Type column for 10.101.1.0/24, click the word metrics.

This window shows the Edges advertising the route as well as the attributes or metrics. In this situation where multiple data centers are advertising the same route; our control plane will look at the BGP metrics to determine what site to prefer. For this route, the AS path length from DC1 is 2 but the route advertised from DC2 is 4. All branches will prefer DC1 for this route unless the Edges at DC1 go down. The branches would then automatically failover to DC2.

  1. Close the metrics window and expand the 10.102.1.0/24 route.

This is the route for DC2 and you can observe that the preferences are flipped from the previous route.

  1. You can also click on the metrics for this route and see that the AS path is opposite from what we previously saw.
Next Article Securing Modern Applications with CBC Container Security