Install on Azure without CMS
For supported software information, click here.
This article describes how to install, or instantiate, a Versa branch device on Microsoft Azure without creating a cloud management system (CMS) connector between Versa Director and the Versa Operating SystemTM (VOSTM) device. To perform this installation, you upload the VOS software image to the Azure portal, and then you create an Azure active directory application for the software.
Note that the procedure described in Install on Azure, in which you establish a CMS connector between Versa Director and the VOS device in Azure, is the preferred method to install Azure in a Versa branch. However, when you are not able to perform the regular installation, for example, if Versa Director is not connected to the internet, you can follow the installation procedures in this article.
To install a Versa branch device on Azure without creating a CMS connector, you do the following:
- Create a Versa image in Azure.
- Create a Versa VM.
- Add availability sets in Azure (optional).
- Peer Versa VNFs to an Azure virtual router BGP endpoint.
- Deploy dual Versa VNFs in Azure.
Create a Versa Image in Azure
For VOS Releases 21.1.0 and earlier, you must manually create a VOS images in Azure. For VOS Releases 21.1.0 and later, the images are available in Microsoft Azure Marketplace, and you can skip this section.
Before you create a Versa image, create an Azure blog storage account and then request that Versa Networks Customer Support move the desired .vhd image (for example, 20.2.vhd for Release 20.2) to the blob account.
To create a blob storage account:
- In Azure, navigate to Storage Accounts and click + Add. The Create storage account window displays.
- Select the Basics tab, and in the Account Kind field, select Storage v2.
- In the Location field, ensure that you create the storage account in the region where you are deploying the Versa VNF.
- Enter other required information.
- Navigate to the storage account you created in Step 1 (here, versavhd), and in the left menu bar, select Shared Access Signature.
- In the Allow Services, Allowed Resource Types, and Allowed Permissions group of fields, click all the options.
- In the Start field, select a date that is earlier than the current date and select a time that is at least 15 to 30 minutes before the current time, as recommended by Microsoft.
- In the End field, select an end date that is a day or two after the current date.
- Click Generate SAS and Connection String.
- Save the generated SAS token to a notepad.
- In your storage account, navigate to Blobs, and then click + Container to create a blobs container. The New container window displays.
- In the Name field, enter a name for the container to use as reference for the image.
- Configure the appropriate access level rights as shown in the following image, and then click OK.
- Share the blob URL (displayed in the Properties section of the blob account) and the SAS token for the storage account (displayed in the shared access signature section) with Versa Networks Customer Support so that they can copy the .vhd image to the storage blob account.
- After Versa Networks Customer Support has transfered the .vhd file, create an image in Azure Avere for the .vhd file. To do this, in Azure, navigate to Images and then click +Create. The Create an Image screen displays.
- In the Storage Blob field, click Browse and select the .vhd file transferred by Versa Networks Customer Support.
- Enter any other required information.
- Click Review + Create to create the Versa image.
Create a Versa VM
Next, create a virtual machine (VM) for the Versa VNF:
- In Azure, navigate to Virtual Machines, and then click + Add. The Create a Virtual Machine screen displays. Enter information for the following fields.
Field Description Resource Group Select the resource group. Virtual Machine Name Select a name for the Versa VNF. Region Select the region in which to deploy the Versa VNF. Availability Options To deploy the Versa VNF in a specific Availably Zone within a region, select Availability Zone. Availability Zone Select the zone, as shown in the screenshot in Step 1. -
For high availability (HA), you can deploy a second Versa VNF in a different zone for geodiversity. If geodiversity HA is not required for a dual Versa VNF deployment, you can deploy multiple Versa VNFs in the same Availability Set, as shown in the following screenshot. For more information, see Add Availability Sets in Azure, below.
- In the Image field, click See All Images. Then, select My Images and select the image you created in Create a Versa Image in Azure, above.
- In the Size field, select the appropriate size for the Versa VNF (here, Standard F8s_v2). To view all available sizes, click See All Sizes.
- Create an SSH key pair to allow SSH connections to the management port. There are multiple options for creating an SSH key pair. The following example shows using PuTTYgen in Windows OS. Select RSA 2048, and then generate the private key.
- Save the private key to your desktop, and save the public key to a notepad.
- To enter the public key in the Azure VM, select Use Existing Public Key in the SSH Public Key Source field.
- In the SSH Public Key field, enter the public key you saved in Step 6. The inbound port rules allow only SSH, as shown in the following screenshot.
Note that if you ssh to the VM from a Linux machine instead of selecting Use Existing Public Key and generating a key pair on your own, you can select Generate New Key Pair. Doing this automatically places the public key in the VM, and you can download the .pem file after you create the VM. You can then use the .pem file from a Linux machine to ssh to the VM. - Click Next: Disks >. The Disks tab displays. On this tab, use the default values.
- Click Next Networking >. The Networking tab displays. Enter information for the following fields.
Field Description Virtual Network Select Hub-VNet. Subnet Select the management subnet that you created in the Hub-VNet. Ensure that a new public IP address is assigned. NIC Network Security Group Select Advanced. Configure Network Security Group Create a new network security group (NSG). - Click Next: Management >. The Management tab displays.
- In the Monitoring group of fields, in the Boot Diagnostics field, select Enable with Managed Storage Account.
- Click Review + Create to create the VM.
- If you generated the SSH key pair on your own, after the VM is created, select Reset Password in the left menu bar.
- Enter the username and public key again, and then click Update.
- Navigate to the NSG that was created for the management interface (here, Versa5-nsg).
-
Ensure that the source IP address range for the SSH rule allows only permitted (customer) management IP addresses.
- Under Settings, select the Networking tab and locate the public IP address assigned to the management interface.
You can now ssh to the VM using the public IP address of the management interface. If you are using PuTTY from a Windows machine, you must use the SSH PPK file generated earlier for the first login. Then, you can enable password authentication in the VM's SSH file, which allows you to log in to the VM using the default username and password thereafter. - Log in to the VM using the PPK file username and passphrase. If you used Azure to generate the new key pair, transfer the .pem file to a Linux machine and ssh from the Linux machine instead of using PuTTY, as shown in the following sample screenshots.
- After you log in to the VM, become the administrator:
$ sudo su admin
- Edit the SSH configuration:
$ sudo vi /etc/ssh/sshd_config
- Change password authentication from no to yes.
- Type quit to exit.
- Restart the SSH service:
$ sudo service ssh restart
- Log out of the VM and then log back in using the traditional login username and password (admin/versa123) without using the SSH key pair.
- Shut down the VM within Azure by clicking Overview in the left menu bar, and then clicking Stop.
- After you shut down the VM, add the remaining interfaces (WAN transport and LAN) to the Versa VNF. Note that the order to add the interfaces is important. For example, if you want internet, MPLS, and LAN, to be on VNI-0/0, 0/1, and 0/2, respectively, you must add the interfaces in the same order: internet subnet, MPLS subnet, and LAN subnet.
To attach an interface, select Networking under Settings in Azure and click Attach network interface. The Attach network interface window displays.
- Click Create and attach network interface. In the Create Network Interface screen, enter information for the following fields.
Field Description Name Enter an interface name (here, VersaINTERNET). Subnet Select the subnet from which the interface receives an IP address. NIC Network Security Group Select None. Private IP Address Assignment Select Static and assign an unused IP from the subnet as the static address - Click create to add the interface to the VM.
- Click the interface name, here, VersaINTERNET.
- Select IP configurations in the left menu, and ensure that IP Forwarding is enabled.
- Click save and then click ipconfig1.
- Associate a public IP address, and then choose an existing public IP address or create a new one.
- Click save.
- Repeat Steps 28 through 34 to add the remaining interfaces. For MPLS and LAN interfaces, you do not need to associate a public IP address, so you can skip these steps for these two interface types.
- Restart the VM by selecting the Overview page and clicking Start.
After the instance is up and running, you can ssh back into the device using the management (MGMT) interface and onboard the device to the Versa Director, similar to any CPE deployment. For more information, see Create Provider Organizations.
Note that while creating the device workflow in Versa Director, the bind data for the device must be based on the private IP address for the internet interface and not the public IP address that was associated with the interface in Step 33, above. The next hop for internet and PIP interfaces is the first usable IP address in their respective Azure subnets. For example, the default gateway for the subnet 172.16.26.0/27 is 172.16.26.1, as shown below:
[admin@Versa: ~] $ cd /opt/versa/scripts/ [admin@Versa: scripts] $ sudo ./staging.py -l SDWAN-Branch@customer.com -r Controller-DC1-staging@customer.com -n 411 -c ip-address -w 0 -s 172.16.26.21/27 -g 172.16.26.1
To view the appliance, in the Director view, go to Administration > Appliances.
If you deploy a Versa VNF as an internet breakout, for the rest of the locations associated with the SD-WAN fabric, ensure that you deploy the Versa VNF using both the DIA and gateway options in the device template. Also, if you are deploying using internet breakout, you can deploy NGFW services at the same time.
To deploy a Versa VNF using DIA and gateway options, and to deploy NGFW at the same time:
- In Director view, select the Workflows tab in the top menu bar.
- Select Template > Templates in the left menu bar.
- Click the Add icon to create a new template.
- Select the Tunnels tab.
- Select DIA and Gateway for the split tunnel you select.
- Select the Services tab, and then select NGFW under Service Templates.
- For information about configuring other fields in the Create Template screen, see Create Device Templates.
- Click Save.
Add Availability Sets in Azure
You can add availability sets to install VMs in different fault and update domains. Each fault domain shares a common power source and network. Using availability sets provides resiliency, or high availability (HA) within a datacenter (availability zone). Performing this step is optional.
Note that the VMs deployed in an availability set are automatically placed into different fault and update domains. Because you deploy only two Versa VNFs in the availability set, you need only two of domains of each set.
To add an availability set:
- In Azure, click + Create in the Availability sets section. The Create Availability Set window displays.
- In both the Fault Domains and Update Domains, enter 2 to create two of each domain in the availability set.
- Enter other required information.
- Click Review and Create.
Peer Versa VNFs to an Azure Virtual Router BGP Endpoint
To create EBGP peering between Versa VNFs and the Azure BGP endpoint or virtual routers (VRs), you must obtain the AS number (ASN) and IP address of the virtual routers. You can do this using PowerShell, which is the same way that you created the virtual routers. For example:
PS C:\Users\user-name> Get-AzVirtualRouter -RouterName VersaVR -ResourceGroupName resource-group-name Name : VersaVR ResourceGroupName : VNSPOCRG Location : eastus Id : /subscriptions/310a5c8e-3b71-4ad2-bcaf-8f829fbee7c5/resourceGroups/VNSPOCRG/providers/Microsoft.Net work/virtualHubs/VersaVR Etag : Type : Microsoft.Network/virtualHubs ProvisioningState : Succeeded HostedSubnet : /subscriptions/310a5c8e-3b71-4ad2-bcaf-8f829fbee7c5/resourceGroups/VNSPOCRG/providers/Microsoft.Net work/virtualNetworks/Hub-VNet/subnets/VR-Subnet VirtualRouterAsn : 65515 VirtualRouterIps : {172.16.26.132, 172.16.26.133} Peerings : [ { "PeerAsn": 65002, "PeerIp": "172.16.26.109", "ProvisioningState": "Succeeded", "Name": "Versa2" }, { "PeerAsn": 65002, "PeerIp": "172.16.26.108", "ProvisioningState": "Succeeded", "Name": "Versa3" } ]
Here, the AS number is 65515 and the router has two IP addresses, one for each virtual router. The Versa VNFs peer with the Azure virtual router using the LAN interface. Because the Versa VNF LAN interface and the virtual router are on separate subnets in the Hub-V-Net (the virtual router is in its own dedicated subnet), you must configure a static route on the Versa VNF for the virtual router (here, 172.16.26.132) that points towards the Azure default gateway (route table) for the LAN subnet. This route table is the first usable IP address of the LAN subnet.
Configure a Static Route on the Versa VNF
To configure a static route on the Versa VNF for the virtual router:
- In Director view:
- Select the Configuration tab in the top menu bar.
- Select Templates > Device Templates in the horizontal menu bar.
- Select an organization in the left menu bar.
- Select a post-staging template in the main pane. The view changes to Appliance view.
- Select the Configuration tab in the top menu bar.
- Select Networking > Virtual Routers in the left menu bar.
- Click the Add icon. The Configure Virtual Router popup window displays.
- Select Static Routing in the left menu bar. The following screenshot shows that 172.16.26.132 is configured with static routes. For more information, see Configure Static Routes.
After you configure a static route on the Versa VNF for the virtual router, you can ping the virtual routerss from the LAN interface on Versa VNF. For example:
admin@azure-cli> ping 172.16.26.132 routing-instance Customer1-LAN-VR source 172.16.26.110 PING 172.16.26.132 (172.16.26.132) from 172.16.26.110 : 56(84) bytes of data. 64 bytes from 172.16.26.132: icmp_seq=1 ttl=128 time=3.36 ms 64 bytes from 172.16.26.132: icmp_seq=2 ttl=128 time=3.31 ms 64 bytes from 172.16.26.132: icmp_seq=3 ttl=128 time=3.40 ms 64 bytes from 172.16.26.132: icmp_seq=4 ttl=128 time=7.55 ms 64 bytes from 172.16.26.132: icmp_seq=5 ttl=128 time=3.35 ms
Configure EBGP Peering to Virtual Routers
You can now configure eBGP peering to the virtual routers, starting with the Versa VNFs. The following illustration shows the peering from Versa to the virtual routers, with each Versa VNF peering to both virtual routers for redundancy.
If you deploy the Versa VNF as a internet breakout gateway, a BGP instance exists in the customer's LAN virtual router. You can use the same BGP instance and build a new peer group to the Azure virtual router IP addresses, as illustrated in the following procedure example:
- In Director view:
- Select the Configuration tab in the top menu bar.
- Select Templates > Device Templates in the horizontal menu bar.
- Select an organization in the left menu bar.
- Select a post-staging template in the main pane. The view changes to Appliance view.
- Select the Configuration tab in the top menu bar.
- Select Networking > Virtual Routers in the left menu bar.
- Select the customer LAN VR from the main tab. The Edit Configure Virtual Router popup window displays.
- Select the BGP tab in the left menu bar. The main pane displays a list of the BGP instances that are already configured.
- Select the BGP instance that exists in the customer's LAN VR. The Edit BGP screen displays and this BGP instance uses local AS number 64514 by default.
- Select the BGP Peer Group tab.
- Click the Add icon. In the Add Peer Group popup window, enter information for the following fields. The following example uses the Edit Peer Group screen.
Field Description Type Select EBGP. Peer AS Enter 65515 as the Azure VR AS number. Local AS Enter 65002 as the local AS number. Neighbors (Tab) Select, and click the Add icon to add neighbors. Here, 172.16.26.132 and 172.16.26.132 are the neighbor IP addresses for this peer group. - For information about configuring other fields, see Configure a BGP Peer Group.
- Click OK.
If you did not deploy the Versa VNF as an internet breakout gateway, the BGP instance may not exist in the customer's LAN VR. In this case, you can add a BGP instance 3014 and the appropriate BGP and neighbor attributes, with a local AS number of 65002. Alternatively, you can configure BGP and static routing when you create the device template. For more information, see Create Device Templates.
To complete the BGP setup between the Versa VNF and Azure virtual routers, create creating the peering on the Azure virtual router in PowerShell using a Versa LAN IP address and ASN 65002. For example:
PS C:\Users\user-name> Add-AzVirtualRouterPeer -PeerName "Versa4" -PeerIp "172.16.26.110" -PeerAsn "65002" -VirtualRouterName "VersaVR" -ResourceGroupName VNSPOCRG Name : VersaVR ResourceGroupName : VNSPOCRG Location : eastus Id : /subscriptions/310a5c8e-3b71-4ad2-bcaf-8f829fbee7c5/resourceGroups/VNSPOCRG/providers/Microsoft.Net work/virtualHubs/VersaVR Etag : Type : Microsoft.Network/virtualHubs ProvisioningState : Succeeded HostedSubnet : /subscriptions/310a5c8e-3b71-4ad2-bcaf-8f829fbee7c5/resourceGroups/VNSPOCRG/providers/Microsoft.Net work/virtualNetworks/Hub-VNet/subnets/VR-Subnet VirtualRouterAsn : 65515 VirtualRouterIps : {172.16.26.132, 172.16.26.133} Peerings : [ { "PeerAsn": 65002, "PeerIp": "172.16.26.109", "ProvisioningState": "Succeeded", "Name": "Versa2" }, { "PeerAsn": 65002, "PeerIp": "172.16.26.108", "ProvisioningState": "Succeeded", "Name": "Versa3" }, { "PeerAsn": 65002, "PeerIp": "172.16.26.110", "ProvisioningState": "Succeeded", "Name": "Versa4" } ]
Verify the BGP peering on the Versa VNF device:
admin@Azure-cli> show bgp neighbor org organization-name brief routing-instance: Customer1-Control-VR Neighbor Uptime State PfxRcd PfxSent local-port remote-port 10.1.64.1 19:11:56 Established 93 12 39230 179 10.1.64.2 n/a Connect 0 0 0 0 routing-instance: Customer1-LAN-VR Neighbor Uptime State PfxRcd PfxSent local-port remote-port 172.16.26.132 00:00:34 Established 4 20 50752 179 172.16.26.133 00:00:34 Established 4 24 49936 179
Finally, ensure that the BGP routes learned from the Azure virtual routers are redistributed to the SD-WAN overlay IBGP control plane. To do this, ensure that BGP that part of the redistribution policy in the customer LAN virtual router has an action of Accept as shown in the following configuration example:
- In Director view:
- Select the Configuration tab in the top menu bar.
- Select Templates > Device Templates in the horizontal menu bar.
- Select an organization in the left menu bar.
- Select a post-staging template in the main pane. The view changes to Appliance view.
- Select the Configuration tab in the top menu bar.
- Select Networking > Virtual Routers in the left menu bar.
- Select the customer LAN VR from the main tab. The Edit Configure Virtual Router popup window displays.
- Select the Redistribution Policies tab in the left menu bar.
- In the General tab, select the BGP redistribution policy that you want to edit (here, Default-Policy-To-BGP). The Edit Redistribution Policy popup window displays.
- Click the BGP term (here, T4-BGP) under Terms. The Edit Redistribution Policy > Edit Term popup window displays.
- Select the Action tab, and then select Accept in the Accept/Reject field, to accept all traffic for the route.
- For more information about other fields, see Configure Redistribution Policies.
- Click OK.
Deploy Dual Versa VNFs in Azure
When deploying dual Versa VNFs in Azure, either in separate availability zones or in the same availability zone or availability set, you do not deploy them as a traditional VOS high availability (HA) pair. That is, you do not deploy dual Versa VNFs by selecting Redundant Pair in the Workflows template. Instead, you install them in Azure as two standalone Versa VNFs, because the dot1.q tagging that is required for the cross-connect of a traditional VOS HA pair is not supported.
Both Versa VNFs deployed in Azure must peer with the Azure virtual router in the same way as described in Peer Versa VNFs to an Azure Virtual Router BGP Endpoint, above. Both Versa VNFs learn the spoke VNET routes and advertise them to the SD-WAN fabric. This is the same for the default route to internet if you have configured both Versa VNFs to act as internet breakout gateways for other SD-WAN sites.
Both Versa VNFs must advertise these networks with different route distinguishers to Versa Controller nodes, which allows the Controller nodes to reflect both routes to other SD-WAN locations. You change the route distinguisher only on one Versa VNF.
Change the Route Distinguisher
To change the route distinguisher on one of the Versa VNF devices:
- In Director view:
- Select the Configuration tab in the top menu bar.
- Select Templates > Device Templates in the horizontal menu bar.
- Select an organization in the left menu bar.
- Select a post-staging template in the main pane. The view changes to Appliance view.
- Select the Configuration tab in the top menu bar.
- Select Networking > Virtual Routers in the left menu bar.
- Select the customer LAN VR (here, Customer1-LAN-VR) from the main tab. The Edit Configure Virtual Router popup window displays.
- Change the Route Distinguisher value by one, here, from 2L:2 to 2L:3.
- For more information about the other fields, see Set Up a Virtual Router.
- Click OK.
Verify whether the route tables of a remote device outside of the Azure infrastructure show the routes for both Versa VNFs:
admin@versa-cli> show route routing-instance lan-vr-name Routes for Routing instance : Customer1-LAN-VR AFI: ipv4 Codes: E1 - OSPF external type 1, E2 - OSPF external type 2 IA - inter area, iA - intra area, L1 - IS-IS level-1, L2 - IS-IS level-2 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 + - Active Route Prot Type Dest Address/Mask Next Hop Age Interface Name ---- ---- ----------------- --------- --- -------------- BGP N/A +0.0.0.0/0 10.1.64.124 02:28:26 Indirect BGP N/A +0.0.0.0/0 10.1.64.125 00:00:29 Indirect BGP N/A 172.16.26.0/24 10.1.64.124 03:14:24 Indirect BGP N/A +172.16.26.0/24 10.1.64.125 00:00:29 Indirect BGP N/A +172.16.26.96/27 10.1.64.124 2w6d20h Indirect BGP N/A +172.16.26.96/27 10.1.64.125 03:14:24 Indirect BGP N/A 172.16.27.0/24 10.1.64.124 03:14:24 Indirect BGP N/A +172.16.27.0/24 10.1.64.125 00:00:29 Indirect BGP N/A 172.16.28.0/24 10.1.64.124 03:14:24 Indirect BGP N/A +172.16.28.0/24 10.1.64.125 00:00:29 Indirect BGP N/A 172.16.29.0/24 10.1.64.124 03:14:24 Indirect BGP N/A +172.16.29.0/24 10.1.64.125 00:00:29 Indirect
Configure Active and Standby Versa VNF Devices
To route traffic through the Versa VNFs in a symmetrical and deterministic manner, you configure the Versa VNFs such that traffic is routed through one Versa VNF that acts as the active device and fails over to the other Versa VNF that acts as a standby device.
To do this, the standby Versa VNF device must advertise a lower local preference value than the primary Versa VNF, which forces the remote SD-WAN devices to forward traffic to the primary device. In the following example, the Versa VNF with the next hop 10.1.64.125 is configured as the secondary device by changing the local preference that it advertises to 90 for the redistributed BGP routes in the Customer-LAN-VR.
- In Director view:
- Select the Configuration tab in the top menu bar.
- Select Templates > Device Templates in the horizontal menu bar.
- Select an organization in the left menu bar.
- Select a post-staging template in the main pane. The view changes to Appliance view.
- Select the Configuration tab in the top menu bar.
- Select Networking > Virtual Routers in the left menu bar.
- Select the customer LAN VR from the main tab. The Edit Configure Virtual Router popup window displays.
- Select the Redistribution Policies tab in the left menu bar.
- In the General tab, select the BGP redistribution policy that you want to edit (here, Default-Policy-To-BGP). The Edit Redistribution Policy popup window displays.
- Click the BGP term (here, T4-BGP) under Terms. The Edit Redistribution Policy > Edit Term popup window displays.
- Select the Action tab, and in the Local Preference field, enter 90.
- For information about other fields, see Configure Redistribution Policies.
- Click OK. This forces other SD-WAN sites to forward their traffic to the primary Versa VNF, at 10.1.64.124.
To verify that traffic is being routed based on the preference values:
admin@versa-cli> show route routing-instance lan-vr-name Routes for Routing instance : Customer1-LAN-VR AFI: ipv4 SAFI: unicast Codes: E1 - OSPF external type 1, E2 - OSPF external type 2 IA - inter area, iA - intra area, L1 - IS-IS level-1, L2 - IS-IS level-2 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 + - Active Route Prot Type Dest Address/Mask Next Hop Age Interface Name ---- ---- ----------------- -------- --- -------------- BGP N/A +0.0.0.0/0 10.1.64.124 02:28:26 Indirect BGP N/A +0.0.0.0/0 10.1.64.125 00:00:29 Indirect BGP N/A 172.16.26.0/24 10.1.64.124 03:14:24 Indirect BGP N/A +172.16.26.0/24 10.1.64.125 00:00:29 Indirect BGP N/A +172.16.26.96/27 10.1.64.124 2w6d20h Indirect BGP N/A +172.16.26.96/27 10.1.64.125 03:14:24 Indirect BGP N/A 172.16.27.0/24 10.1.64.124 03:14:24 Indirect BGP N/A +172.16.27.0/24 10.1.64.125 00:00:29 Indirect BGP N/A 172.16.28.0/24 10.1.64.124 03:14:24 Indirect BGP N/A +172.16.28.0/24 10.1.64.125 00:00:29 Indirect BGP N/A 172.16.29.0/24 10.1.64.124 03:14:24 Indirect BGP N/A +172.16.29.0/24 10.1.64.125 00:00:29 Indirect
Configure Symmetrical Traffic
You must ensure that traffic forwarded from hosts in the spoke VNETs is forwarded to the same Versa VNF, to keep traffic symmetrical. To do this, you prepend AS numbers on the standby Versa VNF when it advertises routes to the Azure BGP endpoint.
To configure the AS prepending, you create a peer and peer group policy in the BGP instance in the LAN VR, and then you prepend the local AS number twice in AS path.
To configure the peer and peer group policy:
- In the Configure Virtual Router > BGP popup window, select the Peer/Group Policy tab. Click the Add icon. The Add BGP Instance Peer/Group Policy popup window displays.
- Enter a name for the peer group policy (here, Prepend-To-Azure).
- Click the Add icon to add a term. The Add BGP Instance Add Peer/Group Policy Add Term popup window displays.
- Enter a name for the term (here, T1).
- Select the Action tab, and in the AS Path Prepend field, enter the AS number twice (here, 64514 64514).
- Click OK.
Then, add the peer and peer group policy to the neighbors configuration for the Azure endpoint as an export policy:
- In the Add BGP Instance window, select the Peer Group tab.
- Select the peer group to which to add the peer and peer group policy, or click the Add icon to add a peer group. In this example, the peer and peer group policy are added to an existing peer group, Azure. The Edit BGP Instance Edit Peer Group popup window displays.
- Select the Advanced tab.
- In the Policy group of fields, in the Export field, select the peer and peer group policy you created above (here, Prepend-To-Azure).
- Click OK.
This configuration forces hosts in the Azure spoke VNETs to forward traffic to the primary Versa VNF. In the following example, this behavior is displayed in the effective routes taken from a spoke VNETs VM route table (here, 172.16.26.109 is the LAN interface of the primary VNF):
With this configuration, the spoke Versa VNFs and remote SD-WAN sites forward traffic to the primary Versa VNF in asymmetrical manner. If the primary Versa VNF goes down, the route tables switch to the secondary Versa VNF.
To verify the behavior from an SD-WAN branch:
admin@versa-cli> show route routing-instance lan-vr-name Codes: El· OSPF external type 1, E2 · OSPF external type 2 IA - inter area, iA - intra area, Ll - IS-IS level-1, L2 - IS-IS level-2 Nl - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 RTI - Learnt from another routing-instance + - Active Route Prot Type Dest Address/Mask Next hop Age Interface name ---- ---- ----------------- ------- --- -------------- BGP N/A +0.0.0.0/0 10.1.64.125 00:08:56 Indirect BGP N/A +172.16.26.0/24 10.1.64.125 00:08:52 Indirect BGP N/A +172.16.26.96/27 10.1.64.125 03:35:05 Indirect BGP N/A +172.16.27.0/24 10.1.64.125 00:08:52 Indirect BGP N/A +172.16.28.0/24 10.1.64.125 00:08:52 Indirect BGP N/A +172.16.29.0/24 10.1.64.125 00:08:52 Indirect
The following is an example of the Azure spoke VNET VM route table:
Verify VOS Deployment on Azure
The section provides information about how to verify a VOS deployment on an Azure public cloud infrastructure.
Verify Azure Components
You can verify the status of all Azure components from the Azure portal or using Microsoft PowerShell.
To verify the status of a Versa VNF instance from Azure, select Virtual Machines on the Home page:
To confirm the status of peering between the hub VNET where the Versa VNFs exist and the spoke VNETs where the customer applications exist, navigate from the Azure Home page to the hub VNET and then check the Peerings section:
An NSG may be applied to an entire subnet, to the interface of an instance, or both. To verify where an NSG is applied, check the Subnets section in the Hub VNET.
You can also check the interface of VM for NSGs:
In the following example, you can see a network from a remote branch attached to the SD-WAN fabric. Both Versa VNFs in Azure are advertising them to the BGP endpoint in Azure and those routes are propagating to the route tables attached to instance interfaces in the spoke VNETs. 172.16.26.109 and 172.16.26.108 are the LAN interface IP addresses for Versa VNFs:
Routes from both Versa VNFs are displayed because AS prepending is not configured and so the route table uses both VNFs. However, when AS prepending is configured on one of the Versa VNFs, traffic from the spoke VNETs is routed to a specific Versa VNF, as shown in the following output from the effective routes:
You can also verify the status of the BGP endpoint and its peers by running the Get-AzVirtualRouter –RouterName router-name –ResourceGroupName –resource-group-name CLI command from PowerShell. For example:
PS C:\Users\user-name> Get-AzVirtuaRouter VersaVR -ResourceGroupName: VNSPOCRG Name :VersaVR ResourceGroupName : VNSPOCRG Location : eastus Id : /subscriptions/310a5c8e-3b71-4ad2-bcaf-8f829fbee7c5/resourceGroups/VNSPOCRG/providers/Microsoft.Network/virtualHubs/VersaVR Etag : Type : Microsoft.Network/virtualHubs ProvisioningState : Succeeded HostedSubnet : /subscriptions/310a5c8e-3b71-4ad2-bcaf-8f829fbee7c5/resourceGroups/VNSPOCRG/providers/Microsoft.Network/virtualNetworks/Hub-VNet/subnets/VR-Subnet VirtualRouterAsn : 65515 VirtualRouterIps : {172.16.26.132, 172.16.26.133} Peerings : [ { "PeerAsn": 65520, "Peerlp": "172.16.26.109", "ProvisioningState": "Succeeded", "Name": "Versa2" }, { "PeerAsn": 65520, "Peerlp": "172.16.26.108", "ProvisioningState": "Succeeded", "Name": "Versa3" } ]
Verify Versa Components
To verify the BGP connection to the Azure BGP endpoint, run the show bgp neighbor brief CLI command. For example:
admin@Azure-cli> show bgp neighbor brief routing instance: Customer-Control-VR Neighbor V MsgRcvd MsgSent Uptime State/PfxRcd PfxSent AS l8.t.64.1 4 10304 99S4 2d23h50m 79 172.16.26.132 4 454 480 03:13:52 4 12 65515 169.254.0.2 4 456 453 03:16:55 1 15 64513 routing-instance: Customer1-LAN-VR Neighbor V MsgRcvd MsgSent Uptime State/PfxRcd PfxSent AS l69.254.0.3 4 9933 9922 03:16:50 15 1 6451412 64512 l0.1.64.2 4 0 8 n/a connect 0 64512 routing-instance: Customer1-LAN-VR Neighbor V MsgRcvd MsgSent Uptime State/PfxRcd PfxSent AS
To view details about what is advertised to the BGP endpoint as well as the AS prepending that may be present, run the show route table ipv4.unicast routing-instance routing-instance-name advertise-protocol bgp neighbor-address neighbor-ip-address. In the example below, the local-AS is prepended twice (highlighted) to the beginning of the AS path that was added when it was advertising to the Azure BGP endpoint:
admin@Azure-c1i> show route table ipv4.unicast routing-instance Customer1-LAN-VR advertising-protocol bgp neighbor-address 172.16.26.132 Routes for Routing instance : Customerl.LAN-VR AFI: ipv4 SAFI: unicast Prefix/Mask Next-hop MED Lclpref AS path 0.0.0.0/0 172.16.26.108 0 0 65520 64514 65520 65520 64513 172.16.26.96/27 172.16.26.108 0 0 65520 64514 65520 65520 192.168.3.112/30 172.16.26.108 0 0 65520 64514 65520 65520 192.168.3.144/32 172.16.26.108 0 0 65520 64514 65520 65520 192.168.3.145/32 172.16.26.108 0 0 65520 64514 65520 65520 192.168.10.0/24 172.16.26.108 0 0 65520 64514 65520 65520 192.168.20.0/24 172.16.26.108 0 0 65520 64514 65520 65520 192.168.20.2/32 172.16.26.108 0 0 65520 64514 65520 65520 192.168.20.5/32 172.16.26.108 0 0 65520 64514 65520 65520 192.168.120.0/24 172.16.26.108 0 0 65520 64514 65520 65520 192.168.222.0/24 172.16.26.108 0 0 65520 64514 65520 65520 206.64.200.120/29 172.16.26.108 100 0 65520 64514 65520 65520 6073 701 13666
To view more details about what is advertised via BGP to the SD-WAN fabric, run the show route table l3vpn.ipv4.unicast routing-instance routing-instance-name advertising-protocol bgp CLI command. The following example shows the local preference that is advertised from the VNF for the redistributed default (for internet breakout) and spoke VNET routes:
admin@Azure-c1i> show route table l3vpn.ipv4.unicast routing-instance Customer1-Control-VR advertising-protocol bgp Routes for Routing instance : Customer1-Control-VR AFI: ipv4 SAFI: unicast Routing entry for 0.0.0.0/0 Peer Address : 10.1.64.1 Route Distinguisher: 2L:3 Next-hop : 10.1.64.117 VPN Label : 24705 local Preference : 110 AS Path : 64513 Origin : Egp MED : 0 Community : [ N/A ] Extended community : [ target:2L:2 ] Routing entry for 172.16.26.0/24 Peer Address : 10.1.64.1 Route Distinguisher: 2L:3 Next-hop : 10.1.64.117 VPN Label : 24705 local Preference : 110 AS Path : 65520 65515 Origin : Egp MED : 0 Community : [ N/A ] Extended community : [ target:2L:2 ]
For a remote branch on the other side of the SD-WAN fabric, the route table looks as if neither Versa VNF in Azure has the BGP local preference adjusted. For example (10.1.64.117 and 10.1.64.124 are the Azure VNFs):
admin@Azure-c1i> show route routing-instance Customer1-LAN-VR Routes for Routing instance : Customer1-LAN-VR AFI: ipv4 SAFI: unicast Codes: El - OSPF external type 1, E2 - OSPF external type 2 IA - inter area, iA - intra area, L1 - IS-IS level-1, L2 - IS-IS level-2 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 RTI - Learnt from another routing-instance + - Active Route Prot Type Dest Address/Mask Next Hop Age Interface name ---- ---- ----------------- -------- --- -------------- BGP N/A +0.0.0.0/0 10.1.64.117 05:47:22 Indirect BGP N/A +0.0.0.0/0 10.1.64.124 06:01:43 Indirect conn N/A +169.254.7.234/31 0.0.0.0 4w5d04h tvi-0/2626.0 local N/A +169.254.7.234/32 0.0.0.0 4w5d04h directly connected BGP N/A +172.16.26.0/24 10.1.64.117 05:47:23 Indirect BGP N/A +172.16.26.0/24 10.1.64.124 06:01:43 Indirect BGP N/A +172.16.26.96/27 10.1.64.117 06:02:13 Indirect BGP N/A +172.16.26.96/27 10.1.64.124 3d02h20m Indirect BGP N/A +172.16.27.0/24 10.1.64.117 05:47:23 Indirect BGP N/A +172.16.27.0/24 10.1.64.124 06:01:43 Indirect BGP N/A +172.16.28.0/24 10.1.64.117 05:47:23 Indirect BGP N/A +172.16.28.0/24 10.1.64.124 06:01:43 Indirect BGP N/A +172.16.29.0/24 10.1.64.117 05:47:23 Indirect BGP N/A +172.16.29.0/24 10.1.64.124 06:01:43 Indirect
If the local preference on the VNF in Azure is configured to act as the standby router, the CLI output is similar to the following example (here, the local preference of 10.1.64.117 is lower that what 10.1.64.124 is advertising):
admin@Azure-c1i> show route routing-instance Customer1-LAN-VR Routes for Routing instance : Customer1-LAN-VR AFI: ipv4 SAFI: unicast Codes: El - OSPF external type 1, E2 - OSPF external type 2 IA - inter area, iA - intra area, Ll - IS-IS level-1, L2 - IS-IS level-2 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 RTI - Learnt from another routing-instance + - Active Route Prot Type Dest Address/Mask Next Hop Age Interface name --- ---- ----------------- -------- --- -------------- BGP N/A 0.0.0.0/0 10.1.64.117 00:00:13 Indirect BGP N/A +6.0.0.0/0 10.1.64.124 06:08:16 Indirect conn N/A +169.254.7.234/31 0.0.0.0 4w5d04h tvi-0/2626.0 local N/A +169.254.7.234/32 0.0.0.0 4w5d04h directly connected BGP N/A 172.16.26.0/24 10.1.64.117 00:00:13 Indirect BGP N/A +172.16.26.0/24 10.1.64.124 06:08:16 Indirect BGP N/A +172.16.26.96/27 10.1.64.117 00:01:02 Indirect BGP N/A +172.16.26.96/27 10.1.64.124 3d02h27m Indirect BGP N/A 172.16.27.0/24 10.1.64.117 00:00:13 Indirect BGP N/A +172.16.27.0/24 10.1.64.124 06:08:16 Indirect BGP N/A 172.16.28.0/24 10.1.64.117 00:00:13 Indirect BGP N/A +172.16.28.0/24 10.1.64.124 06:08:16 Indirect BGP N/A 172.16.29.0/24 10.1.64.117 00:00:13 Indirect BGP N/A +172.16.29.0/24 10.1.64.124 06:08:16 Indirect BGP N/A +192.168.3.112/30 10.1.64.1 3w3d03h Indirect BGP N/A +192.168.3.144/32 10.1.64.124 3d02h27m Indirect BGP N/A +192.168.3.145/32 10.1.64.117 00:01:02 Indirect conn N/A +192.168.10.0/24 0.0.0.0 4w5dOlh vni-0/6.136 local N/A +192.168.10.5/32 0.0.0.0 4w5dOlh directly connected
Additionally, to view the adjusted local preference in the Layer 3 VPN route table on the receiving router, run the show route table l3vpn.ipv4.unicast routing-instance routing-instance-name receive-protocol bgp CLI command (here, local preference is changed default to 90). For example:
admin@Azure-c1i> show route table l3vpn.ipv4.unicast routing-instance Customer1-Control-VR advertising-protocol bgp Routes for Routing instance : Customer1-Control-VR AFI: ipv4 SAFI: unicast Routing entry for 0.0.0.0/0 Peer Address : 10.1.64.1 Route Distinguisher: 2L:9 Next-hop : 10.1.64.117 VPN Label : 24706 local Preference : 90 AS Path : 64513 Origin : Egp MED : 0 Community : [ 8009:8009] Extended community : [ target:2L:2 ] Preference : Default
Supported Software Information
Releases 20.2 and later support all content described in this article.