Azure Networking in comparison with OnPrem Networking

By being freshly certified as an Azure Network Engineer Associate, I thought it could be a good timing to share what I’ve learned about networking in the Azure cloud. I’ve worked for many years with traditional network equipment and I was thrilled to learn networking in the Cloud. I was confused at first then amazed by what could be achieved in the cloud. If you too have knowledge in traditional networking and want to jump into networking in the cloud, read on and I hope to make you want to learn more about it at the end of this blog.

Designing a network

A traditional on-premises (OnPrem for short) network is by nature physically located in some data center and so it is designed to connect physically the equipment together. Those connections are done locally and for communication outside its premises, we have a local connection to the backbone that is our gateway to remote equipment in remote data center. This backbone connection is still physical and usually use optical fibers.

With Networking in the cloud we use Software Defined Network (SDN) which means that the underlying physical infrastructure in the data center is managed by the cloud provider, here Azure, and is invisible to the users. Everything in the cloud is an object that we attach to another object in order to connect them together. Those objects are linked to a physical location (the geographical area of the data center that is hosting those objects). Interestingly, the objects connected together may not be located in the same geographical data center. So when designing a network in the cloud we can think globally on how we want to connect everything together but are free from location contraints. This is very powerful to easily connect offices of a company (the famous Contoso that is always used as an example in Azure documentation) that has a world wide presence.

Being liberated from that physical constraint is amazing! Anyone who has worked on traditional network has for sure spent a significant amount of time checking those Small Form-factor Pluggable (SFPs) and the fiber cables as part of their troubleshooting. This is now all gone in the cloud as the provider, here Azure, will take care of all of this!

Budgeting a network

When it comes to evaluate the cost of an OnPrem networking project, we will include the cost of the physical network equipment as well as the cables, the connectors and everything that build that physical network. For the network equipment we also include the price of licensing in order to activate the specific features we need. This is quite simple and the total cost will be the sum of the amount of those various physical equipment and the licenses required.

In the cloud on the other side, we don’t take care of the physical equipment, we pay for services and capacities and that is not simple at all! Each service in Azure has several pricing tiers which is called SKU (Stock-Keeping-Unit) with several capacities and options. To add to this complexity, when services associate together they often need a common SKU. Also if resources we associate are not in the same geographical area then we sometimes need a higher SKU. So designing a large network can quickly becomes a headache. With great flexibility comes great complexity. Of course Cloud providers are aware of this and so they provide their own calculator to work out all the options and figures. Here is the one from Azure.

Networking elements

In addition to network elements being objects in the cloud, some concepts we are used to with traditional networking are different or non-existent in the cloud. OnPrem we basically have one network interface per subnet whereas in the Azure cloud it is a good practice to reuse the same interface and add several IP address to it. Also all the Layer 2 (L2) concepts we are used to OnPrem, doesn’t exist in the cloud anymore. No VLAN, L2 broadcast or multicast, spanning-tree,… in the cloud. In Azure we define an IP address space (called a VNET) that will contain one or several subnet in it. We then attach a Virtual Network Interface Card (vNIC) to a Virtual Machine and to a subnet, each of those element being an object (called a resource in Azure) in the cloud.

When doing the IP Planning OnPrem, we plan our subnet ranges and in each range we know that the first IP address and the last one are reserved (network address and broadcast). So the smallest subnet we can use has a range of /30 with 2 non-reserved IP address available. This is what is used for subnet between routers.

In Azure, a subnet has 5 IP address reserved. The first one and last one are still used for the network address and broadcast. In addition, the second one is reserved for the default gateway and the third and forth ones are reserved to map the Azure DNS IPs to the VNET space. This means that the smallest subnet we can have in Azure is /29 with 3 non-reserved IP address available.

Routing

When configuring L3 routing OnPrem we need the interface to be in the same L3 subnet than its gateway. Also all the destinations in the routing table are IP addresses. All the traffic going to a destination outside of a subnet has its gateway as the next hop. There is also some L2 mechanism going on for an interface in a subnet to reach its gateway.

In the cloud as we get rid of L2 and associate objects together, the routing logic is much more flexible. This part is a bit baffling when you learn it for the first time. First, you don’t only have the option to specify an IP address as a destination, you can also set a service tags that represents a group of IP address prefixes from a given Azure service. Also the next hop is not an IP address but a label that represents a group of IP address prefixes. For example for any destination going outside of Azure, you just set the label “Internet” as the next hop.

Inside a VNET, the routing between the subnet is done automatically, no need to configure it through a L3 gateway as OnPrem. This routing is done in a VNET because Azure creates a default routing table and automatically add in it the route that corresponds to each created subnet. Finally and this is quite mind blowing at first, you can create a resource called User Defined Route (UDR) in which you can create static routes, assign it to one or several subnets and those routes will override those in the default routing table.

Security

When it comes to block traffic in OnPrem network, we basically use a dedicated equipment called a Firewall and/or we use some Access Control List (ACL) in the routing equipment. We then need to configure carefully the traffic we want to filter and verify the Firewall/ACL are in the proper subnet and on the right path to be efficient.

In Azure the filtering concept stays the same (IP packets have the same structure whatever it is OnPrem or in the cloud), however as you know now by reading this blog it is much more flexible. You can create an object called a Network Security Group (NSG) which is some kind of ACL, and attach it to one or several vNIC or subnets (or both). Also you can create a Firewall resource from Azure (which is a Firewall as a service) and attach it to a VNET. With a UDR you can then route all traffic in a subnet to go through this Firewall. Just like that! It is also possible in Azure to use Firewall from 3rd-party and as easily route traffic to them.

Regarding security OnPrem, we can use some tools for analyzing malicious traffic or preventing DDOS attacks but it takes time and a careful design to implement and configure them properly. In Azure they are services we can activate or just use (Basic DDOS is active by default) and we can easily produce several graphs to observe such traffic. Again we benefit from the nature of the cloud to easily get those information. Also all the signatures and last knowledge about security threat are automatically integrated into those tools in the cloud so there is no more need to plan and automate those updates as we do OnPrem.

Troubleshooting

Finally let’s talk about troubleshooting. OnPrem we all used the usual tools which are ping, traceroute and Wireshark. Beyond those we could use additional tools but for a complete monitoring of the network we should rely on installing probes to collect traffic at different point of our network and send it to a central server which in turn will give us some nice diagrams.

In Azure we don’t use ping, traceroute and Wireshark anymore (even if we can still use them in a Virtual Machine) but use the tools provided by Azure instead. The monitoring of traffic is much easier for the user as all the probing part is taken care of by Azure so we just have to choose the endpoints. Awesome!

There are a lot of applications in Azure that helps you troubleshooting and monitor your network. Azure Network Watcher for example is a collection of tools that allows you to troubleshoot connection issues, check if the traffic will be allowed or denied by an NSG rule, monitor connectivity, store some logs and much more.

Wrap up

As I’ve learned networking in the cloud quite recently, I was amazed (and still are!) by the flexibility and ease of creating a network in Azure. In this blog I’ve only scratched the surface of what we can do in Azure (and just regarding Networking). There are a lot of services that provide various kind of load balancing, traffic distribution and gateway to interconnect with an OnPrem network. Also Azure provides a DNS by default for resources in Azure to use but in addition it is very easy to create its own Private DNS Zone and link it to subnet. We can also create a Public DNS Zone in Azure.

Yes I’ve kept it for the end: you will rarely replace your OnPrem network completely with a cloud one. You will connect to it and then have an hybrid network. This means you will still need to know how to configure networking in both world! The icing on the cake is that Azure cloud is using the Border Gateway Protocol (BGP) dynamic routing protocol everywhere! So learning networking in the cloud is not a recycling of your old networking knowledge, instead you’ll need to stack up this new knowledge. Keep learning!