In my previous post, I explained some basic concepts here and there. Hopefully, you now understand what a computer network looks like, and what basic concepts you should take care of to create one. With this post, I try to dive deeper into the concept of Subnets. Subnets are smaller, more manageable segments of your network. There are more strategies that you can use to organize your network (with subnets). For example, you can have subnets per service, department, or application tier. Although choosing such a strategy is good to start with, it doesn’t take you all the way because some resources have exceptions when integrating into your Virtual Network. For example, some resources require a dedicated subnet. So the subnet is reserved for that resource only. Other resources demand a certain name for your subnet, and so on.

Address Ranges

Similar to your Virtual Network, Subnets have a certain size in terms of address space. Let’s say you have a network with a CIDR of 10.0.0.0/26. That makes your network has 64 IP addresses available. When you now create two subnets (of equal size), you would create one 10.0.0.0/27 subnet (with 32 addresses) giving it a range of 10.0.0.0 to 10.0.0.31. And one subnet 10.0.0.32/27 takes the addresses 10.0.0.32 to 10.0.0.63. It is important to think of how to organize your network upfront for the simple reason that moving subnets around or resizing them can be challenging.

Imagine you need more IP addresses available in the network described above. You decide to expand your network to a /25 network, so it contains 128 available addresses. Now when you again want two subnets of equal size, you cannot simply change the /27 of each subnet to /26 because that would make IP addresses overlap. And more important, the subnets potentially contain resources with already assigned IP addresses. This means that Azure will deny your request to move/change your subnet. Instead, I think it is a good idea to create a new subnet, move resources over, and then remove the old subnets. Although that sounds easy, it can sometimes be more of a challenge than expected.

Finally, you need to know that Azure takes 5 IP addresses per subnet. The first four addresses, so in the example of the first subnet above (10.0.0.0 to 10.0.0.3) are taken for the Network Address, the Azure gateway and to map the Azure DNS IP addresses to the network space. The last IP address of the subnet (so 10.0.0.31) is reserved as a network broadcast address.

Network Security Groups (NSGs)

Each subnet can be assigned a Network Security Group (or NSG). I always refer to an NSG as a mini-firewall, because to most people this describes its purpose fairly well. NSGs are used to control inbound and outbound traffic to Network Interfaces (NICs), Virtual Machines, and Subnets. A Network Security Group is on the basis of a set of network traffic rules. NSGs can be associated to one or more subnets. So if multiple subnets share the same demand of incoming and outgoing traffic, an NSG can be reused.

The rules defined in an NSG can be based on various parameters such as source and destination IP addresses, ports, and protocols. When you create an NSG, it comes with a default set of rules to allow all outbound traffic and deny all incoming traffic. You then customize these rules to your specific needs. The rules in an NSG are configured with a certain priority to indicate the order in which the rules are applied. If you configure conflicting rules, the rule with the highest priority will be applied. The lower the priority number, the higher the priority.

Documentation

One final note is about maybe the most boring part, documentation. However, as a Software Engineer, I believe that your code should be self-explaining and the amount of documentation should be limited to what people actually read. But for networks, this is different. Especially when working with larger networks that serve multiple teams, it is a good idea to keep the documentation up-to-date. When integrating a new service or feature in your network, think of how to organize it in your network and reserve a certain address space in your network. Then update the documentation so other teams will understand your network and don’t (for example) try to claim the same address space resulting in a conflict.

VLAN

According to my friend Jan de Vries, often people confuse VNet subnets with VLan concepts. In my opinion, we’re now comparing apples with pears. So just to make sure everyone is on the right track, here are some key differences:

• Scope
  VNet Subnet: Typically used in the context of cloud computing and virtual networks.
  VLAN: Commonly used in traditional (physical) network setups, although virtual LANs (VLANs) can also be implemented in virtualized environments.

• Layer
  VNet Subnet: Operates at the network layer (Layer 3) of the OSI model.
  VLAN: Operates at the data link layer (Layer 2) of the OSI model.

• Implementation
  VNet Subnet: Primarily used in cloud platforms like Azure for organizing resources within a virtual network.
  VLAN: Historically used in physical network infrastructure, virtual LANs can be implemented in virtualized environments and managed switches.

Last modified on 2023-11-23