Azure Routing Table

Category
Azure Virtual Network – Blog No 2
Time to Read
25 Minutes
Who should read this blog?
If you want to learn about the types of routes on Azure and how routing preference works?
Azure Routing Table

Preface

Azure Routing Table is no different than traditional routing tables from a functioning perspective but very different from how they are populated

I still remember the hours spent understanding the concept of routing, creating different routing scenarios on GNS3, and then irritating my colleagues about a new thing I discovered while doing the Lab. Those days! Duh!

Well, to my dismay Cloud made routing so easy, No scope left about bragging about my hard-earned routing skills. 🙂


Traditional Routing

  • Learning of the Routes – There could be different types of routes based on how they are learned, for example – connected, static, RIP, Eigrp, OSPF, BGP, etc. Each protocol has an administrative distance.
  • Populating the Routing Table – A route/prefix will be selected and added to the routing table based on the lowest administrative distance method it is learned. If two routes are learned through the same AD value, the route metric becomes the tiebreaker.
  • Forwarding Process – The Packet will perform a lookup of the routing table and will choose the Longest prefix.

Azure Routing

Azure Routing is like plug-and-play, everything within a virtual network is by default connected, and as soon begins expanding the virtual network either by Vnet-Peering, Virtual Network Gateway/Vnet-to-Vnet connection, or service end-points. Those routes are also installed by default and can not be edited.

However if a requirement emerges, to overcome the default routing behavior custom routes known as user-defined routes are used which are then applied on the subnet under a Virtual Network.

Azure Routing table

The Cartoon pretty much sums up the routing difference between Azure and the traditional way.

Here is the way how routes are populated in Azure-

System Routes

These are automatically created by Azure and are used for routing traffic to Azure services, virtual appliances, and virtual network gateways. System routes are created based on the configuration of your virtual network and cannot be modified or deleted. They are further subdivided into 2 categories –

Default

These default routes are created as soon as a virtual network is created. These routes behave differently based on the Next hop type –

Virtual network: For example if I create a virtual network with the prefix 10.1.0.0/16. The first entry will address prefix 10.1.0.0./16 with a next-hop type virtual network. Think of this like a connected network in traditional networking.

Internet: As soon as you create a vnet in Azure, everything in that vnet will have default outbound internet access. and the second route helps in achieving the same.

None: Traffic routed to the None next hop type is dropped, rather than routed outside the subnet. Azure automatically creates default routes for the following address prefixes:

  • 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16: Reserved for private use in RFC 1918.
  • 100.64.0.0/10: Reserved in RFC 6598.

SourceAddress prefixesNext hop type
DefaultUnique to the virtual networkVirtual network
Default0.0.0.0/0Internet
Default10.0.0.0/8None
Default172.16.0.0/12None
Default192.168.0.0/16None
Default100.64.0.0/10None
Default

Optional Default Routes

As already explained a virtual network is a boundary and within the boundary, everyone can talk to each other.

However, One vnet can not talk to another vnet as they are different networks by default.

It often happens that one vnet has to talk to resources on another vnet.

Well, it is possible and there are two ways –

  • VNet Peering
  • Vnet-to-vnet connection (using Virtual network gateway)

In this case too, routes are learned and identified differently based on the Next hop type field.

VNet peering: For example, if a hub vnet 10.1.0.0/16 has a vnet peering with another vnet spoke vnet 172.16.0.0/16. Any machine on hub vnet will be able to reach the resource on the spoke vnet due to vent peering. If you see the route table of the machine on Hub vnet you will see a route added as –

172.16.0.0/16 with Next hop type Vnet Peering. No BGP protocol is supported in this case.

Vnet-to-Vnet connection:

Vnet peering traffic goes via the Azure backbone. One can also use Vnet-to-Vnet connection(similar to site-to-site VPN ) to connect two different vnets over the internet, however in this case each Vnet should contain a virtual network gateway that will form a VPN over the internet. BGP protocol (optional) is supported in this case.

A machine in hub vnet that has a Vnet-to-Vnet connection with spoke vnet will learn the spoke vnet prefix 172.16.0.0/16 with next-hop type as Virtual network gateway. Even if the BGP protocol is being used over the connection next hop type will be seen as a Virtual network gateway.

A Virtual Network Gateway is also used to connect to the On-premises offices, where Virtual Network Gateway forms a site-to-site connection with on-premises Router or Firewall. BGP is supported in this scenario(optional).

VirtualNetworkServiceEndpoint: Azure is a public cloud that offers a lot of platform services and you can leverage these services inside your vnet. For example – Azure Active Directory, Storage, Web Apps, and many more.

These services could have a range of public IP prefixes, so once we add a service endpoint connection to any of the platform services, all the related prefixes to that service are injected into the vnet with the next hop type as VirtualNetworkServiceEndpoint.

SourceAddress prefixesNext hop typeSubnet within virtual network that route is added to
DefaultPrefixes advertised from on-premises via BGP or configured in the local network gatewayVNet peeringAll
Virtual network gatewayPrefixes advertised from on-premises via BGP, or configured in the local network gatewayVirtual network gatewayAll
DefaultMultipleVirtualNetworkServiceEndpointOnly the subnet a service endpoint is enabled for.
Optional Default Routes

Custom Routes

You create custom routes by either creating user-defined routes or by exchanging BGP routes between your on-premises network gateway and an Azure virtual network gateway.

User-defined routes

These are routes that you create and manage to direct traffic to specific destinations. User-defined routes can be used to override the default system routes and configure custom routing for your virtual network. These are similar to static routes and are relevant only to a subnet under a vnet where they are enforced.

While defining the User-defined routes you get these options to define Next-hop-type as Virtual Network, Internet, Virtual Network Gateway, None, and Virtual Appliance ( Firewall or similar devices).

BGP

Border Gateway Protocol (BGP) is a dynamic routing protocol that allows you to exchange routing information with your on-premises network and other Azure virtual networks. BGP routes are created and managed through BGP peering and can be used to route traffic between networks. BGP is used especially in the case of express-route and VPN-type connections.

When you exchange routes with Azure using BGP, a separate route is added to the route table of all subnets in a virtual network for each advertised prefix. The route is added with the Virtual network gateway listed as the source and next hop type.


Route-selection Criterion

When outbound traffic is sent from a subnet, Azure selects a route based on the destination IP address, using the longest prefix match algorithm. For example, a route table has two routes: One route specifies the 10.1.0.0/24 address prefix, while the other route specifies the 10.1.0.0/16 address prefix. Azure routes traffic destined for 10.1.0.100, to the next hop type specified in the route with the 10.1.0.0/24 address prefix, because 10.1.0.0/24 is a longer prefix than 10.1.0.0/16, even though 10.1.0.100 is within both address prefixes.

Azure routes traffic destined to 10.1.1.100, to the next hop type specified in the route with the 10.1.0.0/16 address prefix, because 10.1.1.100 isn’t included in the 10.1.0.0/24 address prefix, therefore the route with the 10.1.0.0/16 address prefix is the longest prefix that matches.

If multiple routes contain the same address prefix, Azure selects the route type, based on the following priority:

  1. User-defined route
  2. BGP route
  3. System route

A Snapshot of the Routing table

Azure Routing table

One important field to notice here is State, it could be either Active or Invalid.

For example, if I add a user-defined route for 0.0.0.0/0 with the next-hop type as a virtual appliance, Since for the same network UDR is always preferred over the default route. User-defined route for 0.0.0.0/0 will be in the state Active while the default route for 0.0.0.0/0 with next-hop type internet will be shown in the Invalid state.


Conclusion:

Azure routing tables can be used to control the flow of traffic in virtual networks and manage network traffic between different regions or on-premises networks. They offer flexible routing options and can be customized to meet specific network requirements.

Related Posts

Azure Traffic Manager

Category Azure Traffic Manager – Blog No 1 Time to Read 25 Minutes Who should read this blog? If you want to learn about the Traffic Manager…

What VPN types are supported by Azure

Category Azure VPN – Blog No 1 Time to Read 25 Minutes Who should read this blog? If you want to learn about the VPN tunnel types…

What is Azure Load Balancer?

Category Azure Load Balancer – Blog No 1 Time to Read 25 Minutes Who should read this blog? If you want to learn about the load balancer…

Azure Vnet Peering

Category Azure Virtual Network – Blog No 3 Time to Read 25 Minutes Who should read this blog? If you want to learn about Vnet peering and…

Configuring Azure NSG

Category Azure NSG – Blog No 2 Time to Read 15 Minutes Who should read this blog? If you want to configure NSG Configuring Azure NSG Preface…

Azure NSG

Category Azure NSG – Blog No 1 Time to Read 20 Minutes Who should read this blog? If you want to understand NSG in simple words. Azure…

Leave a Reply

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

Verified by MonsterInsights