SD-WAN

nevermind wind, no matter rain

VMware SD-WAN eBGP with Azure Route Server

Objective

The objective of this post is to document how to connect site(s) with VMware SD-WAN Edge to Azure VNet(s), where in the Azure side there is a transit VNet with virtual edge forming eBGP with Azure Route Server (https://docs.microsoft.com/en-us/azure/route-server/overview). Let’s take a look at the following figures which show the “before” and “after”.

Figure 1 – Before deploying virtual edge and Route Server

Figure 1 shows there are two VNets, namely SG-VNET1 (10.210.0.0/17) and SG-VNET2 (10.210.218.17). In SG-VNET1, there is a Linux VM called VNet1-Linux with IP address 10.210.0.4. In SG-VNET2, there is a Linux VM called VNet2-Linux with IP address 10.210.128.4. There is a SD-WAN Edge called RT-Spoke1 with LAN subnet 10.11.1.0/24, and let’s call this 10.11.1.0/24 location Spoke1 Site. As shown in the diagram, at this point, the VNets and Spoke1 Site are not connected. The next figure shows the end state this post would achieve.

Figure 2 -After deploy virtual edge and Route Server

In order to let Spoke1 Site connects to the two VNet, a transit VNet called SG-VNet-Transit is created. And then Route Server will be created in SG-VNet-Transit. Furthermore, a couple of virtual SD-WAN Edges (Azure-SG-Edge1 and Azure-SG-Edge2) are deployed in SG-VNet-Transit, this pair of SD-WAN Edges will form eBGP with the Route Server, they are also the “hub” for RT-Spoke1. The SG-VNet-Transit VNet will add VNet peering (https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview) with SG-VNET1 and SG-VNET2. The VNet peering will allow the SG-VNET1 (10.210.0.0/17) and SG-VNET2 (10.210.128.0/17) address space advertised from the Route Server to Azure-SG-Edge1 and Azure-SG-Edge2. The VNet peering also allows the routes Route Server learnt from the virtual edge (which is 10.11.1.0/24) to be available at SG-VNET1 and SG-VNET2.

The reason of having two virtual edges in the transit VNet is for redundancy. In this post, the Azure-SG-Edge1 will be acting as a primary edge while Azure-SG-Edge2 is a standby. The method used to achieve primary and standby is AS Path prepend at BGP peer configuration of Azure-SG-Edge2.

The upcoming sections will show the step-by-step how to of deploying the virtual edges and Route Server.

VMware SD-WAN eBGP with Azure Route Server

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top