This article is part of a larger series of articles titled “Azure Networks for Architects“. This is a “foundation” article that explains slightly different perspective about Networks and its underlying protocol stack. The article also provides a mapping between Azure constructs and general networking terms used.
Unless we are building a monolithic solution deployed standalone with no interaction to any other entity we are talking about a solution that involves “network” in them. Networks are very important while designing Azure Solutions. I can’t imagine any decent solution on Azure that does not involve having your own network unless we go for pure PaaS/SaaS based solutions.
“If two or more than two entities are connected with each other, they form a network”. Two things are important to understand here :
(1) “entity”: which means not necessarily computers
(2)”connected”: which means they are simply connected (they may not be actually communicating).
Avoiding much of complexity, in software application scenario, if you have two or more components deployed separately (typically presentation, service, business and data layers) you’d need to establish connectivity between them. You can do so by including them as part of a network. There are other non-network oriented ways for connectivity too but as I said, avoiding much complexity…
We see networks everywhere… at our home (wifi), at offices (Ethernet), Cell Phones etc. So, the fundamental process includes two steps:
- Creating a network
- Joining entities (typically compute devices) to the network
Since network is a grouping of devices for communication purpose, it is only natural to think that networks must be having a standard language that devices can use to communicate. Yes, you are correct. A network is incomplete unless we specify what language can devices speak in it. Every network supports a specific communication “protocol” that devices will use to talk between each other. So, that also means that every device that wish to connect to a network must understand that communication protocol.
There are different kind of network protocols and you choose one based on the requirements. For example, we use standards like GSM and CDMA for creating networks for cell phones, while we use TCP/IP for creating computer networks (both wifi and ethernet). These networks are different from each other, not only because they use different protocols (from software perspective), but also because they use different radio frequencies for communication. So, we need hardware (specific for a network) on the device that wants to join a given network. This is the reason why your phone probably has an antenna for connecting to GSM, a wifi adapter for connecting to computer networks and maybe another antenna for CDMA network. Coming back to point, computer networks are largely based on TCP/IP protocol suit (just like cellphones are GSM/CDMA based) and so are Azure Networks (did you really think of creating a GSM network on Azure 🙂 ). Going forward, I’ll use the term “device” instead of “entities” as we are moving closer to computer networks.
At this point I’d also want to give very minimal details about how protocols are stacked. These are basic but important concepts. There are many concepts that are “derived” and may not be written explicitly on documentation of product. These are few of those basic concepts from network perspective.
From user perspective, protocols start from layer 4 of OSI model on Azure. You don’t need to go into deep details of the layers of OSI (though some people claim they understand OSI…). What this means is following:
We don’t have access to physical layer wires, wifi etc… they are managed by Microsoft.
We don’t have access to data link layer… the software that interacts directly with physical layer. Networks are created on top of this layer and Microsoft did implement their own backbone network on this layer. But this network is inaccessible to cloud users.
At layer 3 (network layer), we get the protocol called IP. Protocols like TCP, UDP and ICMP are implemented on top of IP. When “user” creates a network on Azure (called vNet in Azure terminology), it is created by Microsoft at layer 3 (the network (IP) layer). There are many versions of IP. Version 4 and Version 6 (IPv6) are of most interest. Microsoft creates vNet using IPv4. So, that means IPv6 is not supported on azure vNets as of today.
Network on Azure (vNet) is called virtual network because is implemented using software. This means that supporting IPv6 in future is merely a matter of upgrading software. In fact, support for IPv6 will be one of the few major announcements that you’d see in future. One question that may come into mind is, whether we can create VLANS on Azure or not? VLANS are also software created networks but they are created at layer 2 and the main purpose of VLANs was to join separate physical networks into one using software. But, on Azure, we don’t have access to layer 2 so we cannot create VLANS. vNets are created using a technique called overlay network. Overlay Network is built on top of other networks and it allows creating multiple networks (with conflicting address space) on top of same underlying shared network. Its done using technology similar to hyper-v network Virtualization (some say overlays are different than virtualization) using NVGRE where each customer’s network ID is added to each frame (not packet because packet is layer 3 concept and we need isolation at layer 2). I think if I go any further, it will dilute the topic. But the key thing is that you don’t get dedicated network on Azure. Its a shared space and data from multiple tenants flow on same infrastructure.
This is the layer that we get to see and work as cloud users. At this layer we get protocols like TCP, UDP and ICMP are implemented on top of IPv4. There are many protocols that can be used by applications on top of IP layer. For each protocol, IP header’s protocol field has a number mentioned. You can see all common protocol numbers here.
Azure networks support only TCP, UDP and ICMP protocols and you need to keep this in mind before planning for a solution to be deployed on Azure Networks. Your solution may sometimes have the need to use other protocols than TCP, UDP and ICMP. Most of the protocols that software applications use are implemented on top of these. For example, http is implemented on top of TCP.
There are some protocols may run but not supported. The term supported means, if anything goes wrong, you can’t call Microsoft AND updates that Microsoft deploys on Azure “may” break your existing scenarios. Basically, you are on your own even though some protocols may work technically.
Even though TCP, UDP and ICMP are supported, the protocols that are implemented on top of these may not be “supported”… though technically possible. An example will be SNMP. SNMP uses UDP but so it gives an impression that SNMP should be supported. The reality is, even though technically you can use SNMP but it will NOT be “supported” by Microsoft because Microsoft gives SNMP as part of Windows OS and this feature of Windows OS is not supported yet. So its more of OS feature supportability rather than technical supportability. If you are planning to use any product on Azure you must do following:
(1) If you plant to build your own product using a specific protocol “directly”, check whether the protocol itself is supported or not
(2) If you plan to use a product/product feature (say SNMP using Windows Server) then you need to check whether the product feature is supported by vendor (Microsoft in case of Windows Server SNMP) on Azure or not
Some of the protocols are available for specific purposes only. As an example, IPSec is used to provide data security between “device-devices”, between “network-network” and between “device-network”. On Azure, IPSec can be used to provide secure connectivity between “network-network” (that too between two non-azure network-azure vNet and not used between two azure vNets) but is NOT supported for other use cases.
- Networks have a “language” that every entity/device should know how to speak. This means devices must be equipped with both software protocol (e.g., TCP/IP) as well as necessary hardware (Ethernet/Wifi).
- Azure provides multiple virtual hardware concepts to join networks. The primary ones include Network Interface Cards (NIC) and Virtual Network Adapters (in form of VPN).
- Azure networks supports only UDP, TCP and ICMP on top of IPv4. IPv6 is not supported yet. This is very important to keep in mind while designing solutions on Azure. Keep a checklist of protocols that your solution needs and see if it is supported or not as part of technical feasibility analysis.
- Even if a protocol is supported, check if the vendor of the product that you wish to use on Azure supports it or not.
- The actual underlying network on Azure is “shared” between tenants and isolation is provided using overlay networks. So, in reality, packets of multiple customers flow on same channel but they are still isolated and secure because users don’t get access to lower layers of networking stack. This is important from compliance perspective. Some organizations want a separate dedicated physical network which is NOT possible on Azure. In those scenarios, we go for hybrid approach to move only those components to Azure that can afford shared space.
I hope you enjoyed this small article that build foundation of networking concepts and how it is related with Azure from supportability perspective.
In the next article, I’ll talk about “when should we create networks”.
This series is also mirrored at blogs.comtecinfo.com. The links in this article below will be updated as and when new articles are posted.
Contact us for: