Page Comparison

...

Contents
Azure Installation Guide
Copyright Statement
Preface
Document conventions
About this Guide
Installing the System
Before you begin
Learning about Azure
Installing the Azure CLI
Key Azure Concepts
Azure routing tables
Network security groups
Installation Options
Create required resources
Create resource group
Create storage account
Create virtual network (optional)
Create subnets (optional)
Create public IP (optional)
Create NICs
Create a vRouter VM
Obtaining and launching the Brocade CloudTAP ARM template
Configuring route tables
Configuring a network security group for a NIC
Configuring a network security group for a subnet
Accessing the instance remotely
Terminating an instance
Configuration Examples
Example: Azure routing configuration
Example: vRouter flow monitoring
Example: vRouter ERSPAN monitoring with IPsec
Upgrading the System
Before upgrading
Upgrading a vRouter in Azure
Azure Feature Restrictions
Azure feature restrictions
List of Acronyms

...

© 2020 IP Infusion Inc. All Rights Reserved.
This documentation is subject to change without notice. The software described in this document and this documentation are furnished under a license agreement or nondisclosure agreement. The software and documentation may be used or copied only in accordance with the terms of the applicable agreement. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or any means electronic or mechanical, including photocopying and recording for any purpose other than the purchaser's internal use without the written permission of IP Infusion Inc.
IP Infusion Inc.3965 Freedom Circle, Suite 200Santa Clara, CA 95054+1 408-400-1900
http://www.ipinfusion.com/.
For support, questions, or comments via E-mail, contact:
support@ipinfusion.com.
Trademarks:
IP Infusion is a trademark of IP Infusion. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Use of certain software included in this equipment is subject to the IP Infusion, Inc. End User License Agreement at http://www.ipinfusion.com/license. By using the equipment, you accept the terms of the End User License Agreement.

...

Command syntax conventions
Bold and italic text identify command syntax components. Delimiters and operators define groupings of parameters and their logical relationships.

...

This guide describes how to install and configure DANOS-Vyatta edition on the Microsoft Azure cloud hosting environment.

...

...

The Azure portal has limited support for managing virtual machines with multiple network interfaces, Brocade recommends using the Azure CLI.
Microsoft provides a cross-platform CLI for Azure, which is available at http://azure.microsoft.com/en-gb/documentation/articles/xplat-cli-install/ and can be installed on Windows, Mac OS, and Linux.
After you have installed the CLI, log in to your Azure account.
$ azure login
The Azure CLI has the following modes:

...

ASM is now deprecated. New deployments must use ARM instead. If is assumed for this guide that you have the Azure CLI set to the ARM mode.
To set the Azure CLI to the ARM mode, enter the following command.
$ azure config mode arm
The Azure CLI provides extensive help topics. To display the top-level help topics, enter the following command.
$ azure help
To display help information about a specific command, enter the following command.
azure help <command>

...

The Azure network is different than a traditional Ethernet network.
Resources within an Azure subnet do not share the same Layer 2 broadcast domain, and the destination MAC address is not used by the Azure network to decide where to send a frame.
If you configure a route in your VM to send traffic with another Azure VM as the next hop, the traffic is delivered to the destination without passing through the next hop. Azure maintains its own routing tables for each subnet and provides a unique packet-forwarding environment based upon its own proprietary rules.
By default, each subnet uses the system route table. The system route table contains the following rules:

...

To send local traffic by way of an intermediate hop, you must create a user-defined route table and associate it with the subnet on which the traffic will originate. You can then add routes to the route table. Routes consist of:

...

In addition, for Express Route users, there is a BGP route table. Routing is done using a longest prefix match across all route tables. If the same prefix is in multiple tables, routes are applied with the following priority (with 1 being the highest priority):

...

Because of this approach to packet handling by the Azure network, the routing capability of vRouter in Azure is limited. The routes on the vRouter determine which interface packets leave, but do not have any affect beyond that. To configure packets to leave through a particular interface, configure a static route with a next hop of the first host address in the subnet (for example, for 10.0.4.0/24, the first host address is 10.0.4.1). This address is the address of the Azure infrastructure gateway for that subnet.

...

Network security groups (NSGs) are the Azure implementation of a firewall. They are simple, stateless access control lists (ACLs).
An NSG has a name and rules, where each rule consists of the following:

...

Azure provides some default tags, which can be used to represent address ranges in a way that is portable across virtual networks. The default tags are:

...

The rules in an NSG are processed in order of increasing priority. If a rule is matched, the associated access decision is made and rule processing stops. Give more specific rules a lower priority number so that they are processed first.
It is recommended that you jump the priority of each rule you add by 100, leaving some room to add intermediate rules at a later date. Each NSG has six pre-loaded rules, which provide some relatively secure defaults. These pre-loaded rules cannot be deleted, but are assigned a low priority so they can be overridden by adding rules at a higher priority. The pre-loaded rules are as follows:

An NSG can be associated with a subnet or a NIC. If an NSG is associated with a subnet, it applies to all resources present in that subnet. An NSG can be associated with multiple subnets or NICs (or both); however each subnet or NIC can be associated with only one NSG.

...

In the Azure Resource Manager model, each resource belongs to a resource group. Resource groups are a grouping of resources that you want to manage together.
For example, it is likely that you will want to manage the NICs, storage account, and VM of a vRouter together, so they should be placed in the same resource group.
A resource group can be created with the Azure CLI using the azure group create <name> <location> command as follows:
$ azure group create vRouter westus info: Executing command group create + Getting resource group vRouter + Creating resource group vRouter info: Created resource group vRouter data: Id: /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRouter data: Name: vRouter data: Location: westus data: Provisioning State: Succeeded data: Tags: null data: info: group create command OK

...

A storage account is required to store your vRouter VM's disk image. If you are creating multiple vRouters to enable high availability, you should also create multiple storage accounts, to avoid having the storage account be a single point of failure.
The storage account must be a Storage account, rather than a BlobStorage account. The name of the storage account must be globally unique within Azure, as it is used as part of the storage account URL. Storage accounts can be created by using the azure storage account create <name> command as follows:
$ azure storage account create -sku-name LRS kind Storage location westus -resource-group vRouter vrouterdeploy info: Executing command storage account create + Checking availability of the storage account name + Creating storage account info: storage account create command OK

...

If you are deploying vRouter into an existing virtual network, you can skip this step.
A virtual network is given a name and an address space. You can create a virtual network by using the azure network vnet create <resource-group> <name> <location> command as follows:
$ azure network vnet create --address-prefixes 10.0.0.0/16 vRouter Net westus info: Executing command network vnet create + Looking up the virtual network "Net" + Creating virtual network "Net" data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/ Microsoft.Network/virtualNetworks/Net data: Name : Net data: Type : Microsoft.Network/virtualNetworks data: Location : westus data: Provisioning state : Succeeded data: Address prefixes: data: 10.0.0.0/16 info: network vnet create command OK

...

If you are placing all of the NICs of your vRouter in existing subnets, you can skip this step.
If you have to create any new subnets, you can create them by using the azure network vnet subnet create <resource-group> <vnet-name> <name> command as follows:
$ azure network vnet subnet create --address-prefix 10.0.0.0/24 vRouter Net Frontend-Subnet info: Executing command network vnet subnet create + Looking up the virtual network "Net" + Looking up the subnet "Frontend-Subnet" + Creating subnet "Frontend-Subnet" data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/ Microsoft.Network/virtualNetworks/Net/subnets/Frontend-Subnet data: Name : Frontend-Subnet data: Provisioning state : Succeeded data: Address prefix : 10.0.0.0/24 info: network vnet  subnet create command OK

...

If you want the vRouter to be accessible on the public Internet, you must assign it a public IP address by using the azure network public-ip create <resource-group> <name> <location> command. The following example uses the domain name label of vrouter1 and shows how to create the public IP in the West US region. The FQDN for the IP address is vrouter1.westus.cloudapp.azure.com. The domain name label must be unique within the Azure region.
$ azure network public-ip create -domain-name-label vrouter1 vRouter vRouter1-IP  westus info: Executing command network public-ip create warn: Using default idle-timeout 4 warn: Using default allocation-method Dynamic warn: Using default -ip-version IPv4 + Looking up the public ip "vRouter1-IP" + Creating public ip address "vRouter1-IP" data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/ Microsoft.Network/publicIPAddresses/vRouter1-IP data: Name : vRouter1-IP data: Type : Microsoft.Network/publicIPAddresses data: Location : westus data: Provisioning state : Succeeded data: Allocation  method : Dynamic data: IP version : IPv4 data: Idle timeout in minutes : 4 data: Domain name label : vrouter1 data: FQDN : vrouter1.westus.cloudapp.azure.com info: network public-ip create command OK

...

The number of NICs that can be attached to your vRouter VM varies depending on the VM size. For more details about the mapping of VM size to maximum number of NICs, see https://azure.microsoft.com/en-gb/documentation/articles/virtual-machines-linux-sizes/
Each NIC belongs to a subnet and can optionally have a public IP address attached to it. The NIC is always assigned an IP address within your subnet address range, and the Azure infrastructure gateway uses NAT to translate the public IP address to the NIC IP address. In addition, each NIC has an IP-forwarding setting, which tells the Azure fabric whether it should expect this NIC to send packets with a different source IP address than its own. Enable this setting on any vRouter NIC that acts as part of the data path.
A NIC can be created by using the azure network nic create <resource-group> <name> <location> command as follows.
$ azure network nic create -subnet-vnet-name Net subnet-name Frontend-Subnet public-ip-name vRouter1-IP -private-ip-address 10.0.0.4 --enable-ip-forwarding true vRouter vRouter1-Frontend-NIC westus info: Executing command  network nic create + Looking up the network interface "vRouter1-Frontend-NIC" + Looking up the subnet "Frontend-Subnet" + Looking up the public ip "vRouter1-IP" + Creating network interface "vRouter1-Frontend-NIC" data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/Microsoft.Network/networkInterfaces/vRouter1-Frontend-NIC data: Name : vRouter1-Frontend-NIC data: Type : Microsoft.Network/networkInterfaces data: Location : westus data: Provisioning state : Succeeded data: Internal domain name  suffix : wlsosiwaajyerbkjndrs4x1gzc.dx.internal.cloudapp.net data: Enable IP forwarding : true data: IP configurations: data: Name : default-ip-config data: Provisioning state : Succeeded data: Private IP address : 10.0.0.4 data: Private IP version : IPv4 data: Private IP allocation  method : Static data: Public IP address : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/ Microsoft.Network/publicIPAddresses/vRouter1-IP data: Subnet : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/ Microsoft.Network/virtualNetworks/Net/subnets/Frontend-Subnet data: info: network nic create command OK

...

The CloudTAP ARM template is listed in the Azure Marketplace. All Azure users are able to create CloudTAPs without having to contact Brocade and can integrate CloudTAP into their solution quickly and easily.
To create CloudTAPs, perform these steps:

...

For traffic to pass through the vRouter, the Azure route tables must be configured.
The following example shows a vRouter with an IP address of 10.0.0.4 on its primary NIC. The route table is to be configured so that any traffic originating in the App-Subnet subnet (10.0.3.0/24) destined for the DB-Subnet subnet (10.0.2.0/24) passes through the vRouter.
First, create a route table. This can be done by using the azure network route-table create <resource-group> <name> <location> command as follows:
$ azure network route-table create vRouter App-Route-Table westus info: Executing  command network route-table create + Looking up Route Table "App-Route-Table" + Creating Route Table "App-Route-Table" data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/ Microsoft.Network/routeTables/App-Route-Table data: Name : App-Route-Table data: Type : Microsoft.Network/routeTables data: Location : westus data: Provisioning state : Succeeded info: network route-table create command OK
Next, add a route to the route table; this route applies to any traffic destined for the 10.0.2.0/24 address range and sends the traffic to the specified virtual appliance. To create a route, use the azure network route-table route create <resource-group> <route-table-name> <name> command as follows:
$ azure network route-table route create -address-prefix 10.0.2.0/24 --next-hop-type VirtualAppliance -next-hop-ip-address 10.0.0.4 vRouter App-Route-Table DB-Route info: Executing command network route-table route create + Looking up Route Table "App-Route-Table" + Looking up route "DB-Route" in route table "App-Route-Table" + Creating route "DB-Route" in a route table "App-Route-Table" data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/ Microsoft.Network/routeTables/App-Route-Table/routes/DB-Route data: Name : DB-Route data: Provisioning state : Succeeded data: Next hop type : VirtualAppliance data: Next hop IP address : 10.0.0.4 data: Address prefix : 10.0.2.0/24 info: network route-table route create command OK
Finally, associate the route table to a subnet. In this case, the App-Route-Table route table is to be associated with the App-Subnet subnet. This association is done using the --route-table-name option of the azure network vnet subnet set <resource-group> <vnet-name> <name> command as follows:
$ azure network vnet subnet set --route-table-name App-Route-Table vRouter Net App-Subnet info: Executing command network vnet subnet set + Looking up the virtual network "Net" + Looking up the subnet "App-Subnet" + Looking up Route Table "App-Route-Table" + Updating subnet "App-Subnet" data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/ Microsoft.Network/virtualNetworks/Net/subnets/App-Subnet data: Name : App-Subnet data: Provisioning state : Succeeded data: Address  prefix : 10.0.3.0/24 data: Route Table id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/ Microsoft.Network/routeTables/App-Route-Table info: network vnet subnet set command OK

...

If you are expecting the vRouter to handle traffic only on certain ports, then attaching an NSG to the vRouter NIC can be useful for security and reduce the risk of a denial of service attack being successful.
The following example shows how to configure an NSG that allows access to an OpenVPN server and to SSH for management and how to attach the NSG to the NIC of the vRouter.
First, create a network security group by using the azure network nsg create <resource-group> <name> <location> command as follows.
$ azure network nsg create vRouter OVPN-NSG westus info: Executing command network nsg create + Looking up the network security group "OVPN-NSG" + Creating a network security group "OVPN-NSG" data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/Microsoft.Network/networkSecurityGroups/OVPN-NSG data: Name : OVPN-NSG data: Type : Microsoft.Network/networkSecurityGroups data: Location : westus data: Provisioning state : Succeeded data: Security rules: data: Name Source IP Source Port Destination IP Destination Port Protocol Direction Access Priority data: ----------------------------- ----------------- ----------- -------------- ---------------- -------- --------- ------ -------- data: AllowVnetInBound VirtualNetwork * VirtualNetwork * * Inbound Allow 65000 data: AllowAzureLoadBalancerInBound AzureLoadBalancer * * * * Inbound Allow 65001 data: DenyAllInBound * * * * * Inbound Deny 65500 data: AllowVnetOutBound VirtualNetwork * VirtualNetwork * * Outbound Allow 65000 data: AllowInternetOutBound * * Internet * * Outbound Allow 65001 data: DenyAllOutBound * * * * * Outbound Deny 65500 info: network nsg create command OK
Next, add any rules for the NSG by using the azure network nsg rule create <resource-group> <nsg-name> <name> command to add rules to allow SSH and OpenVPN inbound.
$ azure network nsg rule create -protocol Tcp source-address-prefix "" --source-port-range "" destination-address-prefix "" --destination-port-range 22 access Allow priority 200 direction Inbound vRouter OVPN-NSG AllowSSHInbound info: Executing command network nsg rule create + Looking up the network security group "OVPN-NSG" + Looking up the network security rule "AllowSSHInbound" + Creating a network security rule "AllowSSHInbound"   data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/Microsoft.Network/networkSecurityGroups/OVPN-NSG/securityRules /AllowSSHInbound data: Name : AllowSSHInbound data: Type : Microsoft.Network/networkSecurityGroups/securityRules data: Provisioning state : Succeeded data: Source IP :  data: Source Port :  data: Destination IP :  data: Destination Port : 22 data: Protocol : Tcp data: Direction : Inbound data: Access : Allow data: Priority : 200 info: network nsg rule create command OK $ azure network nsg rule create protocol Udp source-address-prefix "" --source-port-range "" destination-address-prefix "" --destination-port-range 1194 access Allow priority 300 -direction Inbound vRouter OVPN-NSG AllowOVpnInbound info: Executing command network nsg rule create + Looking up the network security group "OVPN-NSG" + Looking up the network security rule "AllowOVpnInbound" + Creating a network security rule "AllowOVpnInbound" data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/Microsoft.Network/networkSecurityGroups/OVPN-NSG/securityRules /AllowOVpnInbound data: Name : AllowOVpnInbound data: Type : Microsoft.Network/networkSecurityGroups/securityRules data: Provisioning state : Succeeded data: Source IP :  data: Source Port :  data: Destination IP :  data: Destination Port : 1194 data: Protocol : Udp data: Direction : Inbound   data: Access : Allow data: Priority : 300 info: network nsg rule create command OK
Finally, associate the NSG with the vRouter NIC, verifying that you have added all the rules you require beforehand, as any traffic not permitted by a rule is dropped. When the NSG is ready, associate it with the NIC by using the --network-security-group-name option of the azure network nic set <resource-group> <name> command as follows.
$ azure network nic set --network-security-group-name OVPN-NSG vRouter vRouter1-Frontend-NIC info: Executing command network nic set + Looking up the network interface "vRouter1-Frontend-NIC" + Looking up the network security group "OVPN-NSG" + Updating network interface "vRouter1-Frontend-NIC" data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/ Microsoft.Network/networkInterfaces/vRouter1-Frontend-NIC data: Name : vRouter1-Frontend-NIC data: Type : Microsoft.Network/networkInterfaces data: Location : westus data: Provisioning state : Succeeded data: MAC address : 00-0D-3A-34-8F-DF data: Internal domain name  suffix : wlsosiwaajyerbkjndrs4x1gzc.dx.internal.cloudapp.net data: Enable IP forwarding : true data: Network security group : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/ Microsoft.Network/networkSecurityGroups/OVPN-NSG data: IP configurations: data: Name : default-ip-config data: Provisioning state : Succeeded data: Private IP address : 10.0.0.4 data: Private IP version : IPv4 data: Private IP allocation  method : Static data: Public IP address : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/ Microsoft.Network/publicIPAddresses/vRouter1-IP data: Subnet : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/ Microsoft.Network/virtualNetworks/Net/subnets/Frontend-Subnet data: info: network nic set command OK

...

Implementing NSGs for an entire subnet might be necessary.
A previous example shows how to configure a route table so that all traffic from App-Subnet to DB-Subnet passes through a vRouter. The following example shows how to use an NSG so that traffic from anywhere other than App-Subnet cannot enter DB-Subnet. Only VMs in App-Subnet are able to reach DB-Subnet, and their traffic passes through a vRouter for firewall and monitoring.
First, create a network security group by using the azure network nsg create <resource-group> <name> <location> command as follows.
$ azure network nsg create vRouter DB-Subnet-NSG westus info: Executing command network  nsg create + Looking up the network security group "DB-Subnet-NSG" + Creating a network security group "DB-Subnet-NSG" data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/ Microsoft.Network/networkSecurityGroups/DB-Subnet-NSG data: Name : DB-Subnet-NSG data: Type : Microsoft.Network/networkSecurityGroups data: Location : westus data: Provisioning state : Succeeded data: Security rules: data: Name Source IP Source Port Destination IP Destination Port Protocol Direction Access Priority data: ----------------------------- ----------------- ----------- -------------- ---------------- -------- --------- ------ -------- data: AllowVnetInBound VirtualNetwork * VirtualNetwork * * Inbound Allow 65000 data: AllowAzureLoadBalancerInBound AzureLoadBalancer * * * * Inbound Allow 65001 data: DenyAllInBound * * * * * Inbound Deny 65500 data: AllowVnetOutBound VirtualNetwork * VirtualNetwork * * Outbound Allow 65000 data: AllowInternetOutBound * * Internet * * Outbound Allow 65001 data: DenyAllOutBound * * * * * Outbound Deny 65500 info: network nsg create command OK
Next, create an NSG rule to allow traffic to pass from the App-Subnet to the DB-Subnet by using the azure network nsg rule create <resource-group> <nsg-name> <name> command as follows.
$ azure network nsg rule create -protocol "" source-address-prefix "10.0.3.0/24"  --source-port-range "" destination-address-prefix "10.0.2.0/24" destination-port-range ""  --access Allow -priority 200 --direction Inbound vRouter DB-Subnet-NSG AllowAppInbound info: Executing command network nsg  rule create + Looking up the network security group "DB-Subnet-NSG" + Looking up the network security rule "AllowAppInbound" + Creating a network security rule "AllowAppInbound" data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/Microsoft.Network/networkSecurityGroups/DB-Subnet-NSG/security Rules/AllowAppInbound data: Name : AllowAppInbound data: Type : Microsoft.Network/networkSecurityGroups/securityRules data: Provisioning state : Succeeded data: Source IP : 10.0.3.0/24 data: Source Port :  data: Destination IP : 10.0.2.0/24 data: Destination Port : * data: Protocol : * data: Direction : Inbound data: Access : Allow data: Priority : 200 info: network nsg rule  create command OK
There is a default inbound rule to allow all traffic within the virtual network. The rule is overridden with a higher-priority rule.
$ azure network nsg rule create -protocol "" source-address-prefix VirtualNetwork  --source-port-range "" destination-address-prefix VirtualNetwork destination-port-range ""  --access Deny -priority 4096 --direction Inbound vRouter DB-Subnet-NSG DenyVnetInbound info: Executing command network nsg  rule create + Looking up the network security group "DB-Subnet-NSG" + Looking up the network security rule "DenyVnetInbound" + Creating a network security rule "DenyVnetInbound" data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/Microsoft.Network/networkSecurityGroups/DB-Subnet-NSG/security Rules/DenyVnetInbound data: Name : DenyVnetInbound data: Type : Microsoft.Network/networkSecurityGroups/securityRules data: Provisioning state : Succeeded data: Source IP : VirtualNetwork data: Source Port :  data: Destination IP : VirtualNetwork data: Destination Port : * data: Protocol : * data: Direction : Inbound data: Access : Deny data: Priority : 4096 info: network nsg rule  create command OK
Finally, associate the NSG with the subnet. Confirm that you have added all the rules you require before doing this, as any traffic not permitted by a rule is dropped. When the NSG is ready, associate it with the NIC using the --network-security-group-name option of the azure network vnet subnet set <resource-group> <vnet-name> <name> command as follows.
$ azure network vnet subnet set --network-security-group-name DB-Subnet-NSG vRouter Net DB-Subnet info: Executing command network vnet subnet set + Looking up the virtual network "Net" + Looking up the subnet "DB-Subnet" + Looking up the network security group "DB-Subnet-NSG" + Updating subnet "DB-Subnet" data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/ Microsoft.Network/virtualNetworks/Net/subnets/DB-Subnet data: Name : DB-Subnet data: Provisioning state : Succeeded data: Address prefix : 10.0.2.0/24 data: Network Security Group id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/ Microsoft.Network/networkSecurityGroups/DB-Subnet-NSG info: network vnet subnet set command OK
If you find that you are having network issues and suspect that NSGs could be to blame, check which NSG is associated with a subnet.
$ azure network vnet subnet show vRouter Net DB-Subnet info: Executing command network vnet subnet show + Looking up the virtual network "Net" + Looking up the subnet "DB-Subnet" data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/Microsoft.Network/virtualNetworks/Net/subnets/DB-Subnet data: Name : DB-Subnet data: Provisioning state : Succeeded data: Address prefix : 10.0.2.0/24 data: Network Security Group id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/Microsoft.Network/networkSecurityGroups/DB-Subnet-NSG info: network vnet subnet show command OK
Then check the rules in the NSG.
$ azure network nsg show vRouter DB-Subnet-NSG info: Executing command network nsg show + Looking up the network security group "DB-Subnet-NSG" data: Id : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/vRoute r/providers/Microsoft.Network/networkSecurityGroups/DB-Subnet-NSG data: Name : DB-Subnet-NSG data: Type : Microsoft.Network/networkSecurityGroups data: Location : westus data: Provisioning state : Succeeded data: Security rules: data: Name Source IP Source Port Destination IP Destination Port Protocol Direction Access Priority data: ---------------------------- --------------- ---------- ------------- -------------- ------ ------- ---- ------- data: AllowAppInbound 10.0.3.0/24 * 10.0.2.0/24   Inbound Allow 200 data: DenyVnetInbound VirtualNetwork * VirtualNetwork   Inbound Deny 4096 data: AllowVnetInBound VirtualNetwork * VirtualNetwork   Inbound Allow 65000 data: AllowAzureLoadBalancerInBound AzureLoadBalancer     Inbound Allow 65001 data: DenyAllInBound   *   Inbound Deny 65500 data: AllowVnetOutBound VirtualNetwork * VirtualNetwork   Outbound Allow 65000 data: AllowInternetOutBound   Internet   Outbound Allow 65001 data: DenyAllOutBound   *   Outbound Deny 65500 info: network nsg show command OK
To disassociate an NSG from a subnet, use the Azure Portal.

...

Azure does not provide serial console access to VMs, and you can access your vRouter VM only by using SSH.
You must have specified an admin username while creating the VM, which you can use as the user in the SSH command. For the host name, you can use either the public IP address or the DNS name assigned to the public IP address.
$ ssh azureuser@vrotuer1.westus.cloudapp.azure.com
If you used the CloudTAP template, the vRouter instances are behind a load balancer with port forwarding configured to each instance. You have to provide a port argument for the SSH command to be able to access an instance.
$ ssh -p 2200 azureuser@cloudtap1.westus.cloudapp.azure.com

...

Issuing the poweroff command within vRouter does not deallocate the VM, and you continue to be charged. If you have finished using a vRouter instance temporarily, you can deallocate the instance, while allowing it to be resumed later by using the azure vm deallocate <resource-group> <name> command as follows.
$ azure vm deallocate vRouter vRouter1 info: Executing command vm deallocate + Looking up the VM "vRouter1" + Deallocating the virtual machine "vRouter1" info: vm deallocate command OK
To bring a deallocated VM back up, use the azure vm start <resource-group> <name> command as follows.
$ azure vm start vRouter vRouter1 info: Executing command vm start + Looking up the VM "vRouter1" + Starting the virtual machine "vRouter1" info: vm start command OK
If you have finished using a vRouter instance permanently, you can delete it by using the azure vm delete <resource-group> <name> command as follows.
$ azure vm delete vRouter vRouter1 info: Executing command vm delete + Looking up the VM "vRouter1" Delete the virtual machine "vRouter1"? [y/n] y + Deleting the virtual machine "vRouter1" info: vm delete command OK

...

Azure uses its own routing tables, which must be configured correctly to direct traffic to the vRouter. This is also required for the flow monitoring and ERSPAN examples presented the following sections. Because the Azure network handles the delivery of packets according to its own route tables, there is no requirement for a vRouter to have an interface in the originating subnet when it is acting as the next hop. It is likely that the vRouter has different requirements for route tables and NSGs than your other VMs, it is recommended that you put each vRouter interface in its own subnet, not shared with any other VMs.
The following example shows how to configure the Azure route tables so that traffic from the app-subnet (10.0.10.0/24) to the db-subnet (10.0.11.0/24) goes through the vRouter, entering through dp0s17. The default Azure routing configuration causes traffic to be delivered directly, so it is necessary to create a route table, add a rule to it, and attach it to the app-subnet.
In this example, the resource group the virtual network is called erspan. Start by creating the route table, named app-rt.
$ azure network route-table create erspan app-rt ukwest info:    Executing command network route-table create + Looking up Route Table "app-rt" + Creating Route Table "app-rt" data:    Id                              : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/ERSPAN /providers/Microsoft.Network/routeTables/app-rt data:    Name                            : app-rt data:    Type : Microsoft.Network/routeTables data:    Location                        : ukwest data:    Provisioning state              : Succeeded info:    network route-table create command OK
Next, create a route, specifying the IP address of dp0s17 (10.0.2.4) as the next hop. The route is named db-route.
$ azure network route-table route create -address-prefix 10.0.11.0/24 --next-hop-type VirtualAppliance -next-hop-ip-address 10.0.2.4 ERSPAN app-rt db-route info:    Executing command network route-table route create + Looking up Route Table "app-rt" + Looking up route "db-route" in route table "app-rt" + Creating route "db-route" in a route table "app-rt" data:    Id                              : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/ERSPAN /providers/Microsoft.Network/routeTables/app-rt/routes/db-route data:    Name                            : db-route data:    Provisioning state              : Succeeded data:    Next hop type                   : VirtualAppliance data:    Next hop IP address             : 10.0.2.4 data:    Address prefix                  : 10.0.11.0/24 info:    network route-table route create command OK
Finally, attach this route table to the app-subnet.
$ azure network vnet subnet set --route-table-name app-rt ERSPAN erspan app-subnet info:    Executing command network vnet subnet set + Looking up the virtual network "erspan" + Looking up the subnet "app-subnet" + Looking up Route Table "app-rt" + Updating subnet "app-subnet" data:    Id                              : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/ERSPAN /providers/Microsoft.Network/virtualNetworks/erspan/subnets/app-subnet data:    Name                            : app-subnet data:    Provisioning state              : Succeeded data:    Address prefix                  : 10.0.10.0/24 data:    Route Table id                  : /subscriptions/00000000-0000-0000-0000-0000000000000/resourceGroups/ERSPAN /providers/Microsoft.Network/routeTables/app-rt
When 10.0.10.4 sends a packet to 10.0.11.4, the packet leaves its NIC and the Azure network checks its route table to determine what action to take. This packet matches the route that was added. The packet is delivered to 10.0.2.4, the datapath-in interface. Within the vRouter, a forwarding decision is made using the vRouter internal routing table.
Because 10.0.11.0/24 is not a directly connected subnet of the vRouter, the route matches the default route obtained from the Azure DHCP server, meaning that the packet is forwarded by way of 10.0.1.1, through the datapath-out interface. When the packet leaves the datapath-out interface, the Azure network consults the route table for the datapath-out subnet, which contains only the system routes. The local virtual network route is matched, and the Azure network delivers the packet to 10.0.11.4.

...

Before upgrading, save your existing configuration file for reference. Your configuration file is named config.boot and is located in the /config directory.

...

The add system image method of performing upgrades is not supported on Azure Marketplace vRouter images. Upgrades must be performed by moving configuration to a new vRouter that is running the new version as follows:

...

Azure routing is a unique environment and many router features behave differently than would be expected in a typical router environment.
Azure feature restrictions include the following:

...

Acronym

...

Description

...

ACL

...

Access Control List

...

ARM

...

Azure Resource Manager

...

ASM

...

Azure Service Manager

...

CLI

...

Command-line interface

...

FQDN

...

Fully Qualified Domain Name

...

NIC

...

Network Interface Card

...

NSG

...

Network Security Group

...

VM

...

Virtual Machine

...

Vnet

...

• Bring up Virtual SD-Edge in Azure

• Known Issues & Work Arounds