Microsoft AZ-700: Implement Virtual Network Traffic Routing

Notes from MS Learn AZ-700 Module 1:Introduction to Azure Virtual Networks – Unit 9: Implement Virtual Network Traffic Routing

Azure automatically creates route tables for each subnet in a VNet and adds system default routes. Override some Azure system routes with custom routes, add more custom routes to a table. Azure routes outbound based on the routes in the subnets route table

• System Routes
  • Azure automatically creates system routes in each subnet in a VNet
  • You cannot create or remove system routes
  • Override with custom routes

• Default Routes
  • Each route contains address prefix and next hop type
  • When VNet is created Azure creates the following default system routes for each subnet within a VNet (Table taken from MS Learn)
    • 
  • Next Hop Types
    • Virtual Network
      • Routes traffic between address ranges within address space of VNet
      • Created for each address range created within a VNet
      • Azure automatically routes traffic between subnets in a range
    • Internet
      • Routes traffic by address prefix to internet
      • Default 0.0.0.0/0 for anything that isn’t in a specific range or Azure servicce
        • Can override with custom routes
    • None
      • Traffic is dropped
      • Azure automatically creates default routes for RFC 1918 and RFC 6598 (100.64.0.0/10)

• Optional Default Routes
  • Azure adds default system routes for Azure capabilities enabled. Optional default route to either specific subnets within VNet or all subnets in VNet.
  • Potential Azure added routes and types (table taken from MS Learn)
    • 
  • Next Hop Types
    • VNet Peering
      • When peering created between two VNets route added for each address range within the space of each VNet
    • Virtual Network Gateway
      • When virtual network gateway added to VNet Azure adds one or more routes of this type. Source is VNet Gateway because gateway adds route to the subnet
        • Limits to number of routes propagated to an Azure Virtual Network Gateway so summarize on prem routes to largest address ranges possible
    • VirtualNetworkServiceEndpoint
      • Azure adds public IP address for certain services when enabling a service endpoing to a service
      • Enabled for individual subnets within a VNet – only added to route table of subnet the service endedpoing is enabled for
      • Public address for Azure services change – Azure updates route table as needed
    • VNet Peering and VirtualNetworkServiceEndpoint next hop only added to subnet route table created through Azure Resource Manager deployment model – Not added to those created through classic deployment model

• Custom Routes
  • Used to override default routes Azure creates using user-defined routes (UDR). Think when you want traffic to route through a FW
  • User-defined Routes
    • Custom (static) route to override Azure default system routes or add other routes to subnet route table
    • Subnet can have zero or one route table associated
    • When route table created and associated – combines with or overrides default routes Azure adds to subnet
    • Can specify next hop type when creating
      • Virtual Appliance
        • VM running a network app such as FW
        • When creating route with next hop type Virtual Appliance specify next hop IP
          • Private IP of NIC on VM
          • Private IP of Azure internal load balancer
      • Virtual Network Gateway
        • Specify when traffic desired to be destined for specific address prefix to route to a virtual network gateway
          • Virtual Network Gateway must be type VPN
      • None
        • Specify when dropping traffic to a prefix is desired
      • Virtual Network
        • Specify when overriding default routing in VNet is desired
      • Internet
        • Specify when traffic to a specific prefix is desired destined to Internet

• Configuring User-Defined Routes
  • Create a Routing Table
    • Name
    • Subscription
    • Resource Group
    • Location
    • Optional – Decide to use Virtual Network Gateway Route Propagation
      • With this routes automatically added to route table for all subnets that it’s enabled
  • Create a Custom Route
    • Name
    • Destination Type
    • Destination IP Addresses/CIDR ranges
    • Next Hop Type
    • Next Hop Address
  • Associate Route Table
    • Select VNET
    • Select Subnet

• Secure a VNet using forced tunneling
  • Redirect all Internet-bound traffic back to on-prem via Site-2-Site VPN
  • If not used Internet bound traffic travels of Azure direct to internet
  • Configured using Azure PowerShell – can’t be done via Azure Portal
  • Configuring forced tunneling
    • VNet Subnet has built-in system routing table with three groups of routes
      • Local VNet Routes
        • Direct to destination VM in same VNet
      • On-premises Routes
        • Route to Azure VPN gateway
      • Default Route
        • Direct to internet

• Configure Azure Route Server
  • Azure Route Server for simplified dynamic routing between network virtual appliance (NVA) and VNet
  • Fully managed service with HA
  • Simplied configuration, management and deployment of NVA
    • No manual update to routing table on NVA needed when VNet addresses updated
    • No manual updates needed to User-Define Route when NVA announces new routes or removes routes
    • Peer multiple instance of NVA with Azure Route Server
    • Interface between NVA and Azure Route Server on common standard protocol – BGP
    • Deploy in any new or existing VNet

• View Effective Routes in Azure Portal
  • Search for VM in Portal
  • Select VM
  • Select Networking in the settings
  • Select the NIC
  • Select Effective Routes under the “Support + Troubleshooting” section in the settings panel

• View Effective. Routes using Azure PowerShell
  • In Azure Powershell
    • Get-AzEffectiveRouteTable `
      -NetworkInterfaceName myNic1 `
      -ResourceGroupName myRG `

• Resolve Routing Issue
  • Sample steps you can take
    • Add customer route to override
    • Change/remove a custom route that may be problem
    • Verify route table associated to correct subnet (that contains the NIC)
    • Verify device operating as intended E.g. Azure VPN Gateway or NVA