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?

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.

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.

Source	Address prefixes	Next hop type
Default	Unique to the virtual network	Virtual network
Default	0.0.0.0/0	Internet
Default	10.0.0.0/8	None
Default	172.16.0.0/12	None
Default	192.168.0.0/16	None
Default	100.64.0.0/10	None

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.

Source	Address prefixes	Next hop type	Subnet within virtual network that route is added to
Default	Prefixes advertised from on-premises via BGP or configured in the local network gateway	VNet peering	All
Virtual network gateway	Prefixes advertised from on-premises via BGP, or configured in the local network gateway	Virtual network gateway	All
Default	Multiple	VirtualNetworkServiceEndpoint	Only the subnet a service endpoint is enabled for.

---

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

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.

---