Example: Azure routing configuration
This example shows how to configure Azure routing tables which must be set up correctly to direct traffic to the router.
Azure uses its own routing tables, which must be configured correctly to direct traffic to the router. 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 router to have an interface in the originating subnet when it is acting as the next hop. It is likely that the router has different requirements for route tables and NSGs than your other Vyatta NOS VMs, it is recommended that you put each router interface in its own subnet, not shared with any other Vyatta NOS 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 router, 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.
$ 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$ 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$ 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-rtWhen 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 Vyatta NOS, a forwarding decision is made using Vyatta NOS internal routing table.
Because 10.0.11.0/24 is not a directly connected subnet of the router, 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.