本文解释了Azure的软件定义网络（虚拟网络）与传统本地网络的电缆定义网络之间的区别。作者解释了传统网络中电缆定义网络的工作原理，并对比了Azure虚拟网络中软件定义网络的优势，包括自服务、可扩展性和灵活性。文章还详细阐述了虚拟网络的概念，并解释了虚拟网络对等连接和直接连接的工作原理。

💻 **传统网络：电缆定义网络** 在传统网络中，数据包的传输依赖于物理连接，即电缆。每个网络设备都通过电缆连接到其他设备，形成一个固定的网络拓扑结构。这种方式使得网络的配置和管理相对简单，但同时也存在一些局限性，例如扩展性差、灵活性不足、配置复杂等。 例如，一个典型的本地防火墙通常具有多个以太网端口，连接到不同的网络，例如外部网络、管理网络、站点间连接、DMZ、内部网络和安全区域等。每个端口连接到一个子网，子网中包含一个或多个交换机，这些交换机只连接到该子网中的服务器。交换机通过上行链路连接到防火墙的相应端口，从而定义了该子网的安全上下文。这意味着DMZ网络中的服务器必须通过防火墙，通过电缆连接到防火墙，才能访问其他子网。 简而言之，在传统网络中，如果不存在物理连接，则无法建立连接。这种方式使网络变得可预测，但同时也限制了网络的灵活性和扩展性。

📢 **Azure虚拟网络：软件定义网络** Azure是一个云平台，它需要支持自服务功能。这意味着用户可以自行创建和配置网络，而无需依赖Microsoft员工。Azure的软件定义网络基于VXLAN技术，它隐藏了底层物理网络的复杂性，并为用户提供了虚拟网络，用户可以在虚拟网络中创建自己的地址和前缀，并使用它们。 在Azure中，用户可以使用门户、脚本、基础设施即代码或API来创建和配置网络。当用户创建虚拟网络时，Azure会创建一个映射，该映射记录了连接到虚拟网络的NIC（用户显式创建的NIC或连接到网络的平台资源的NIC），并跟踪这些NIC所在的Hyper-V主机。虚拟网络的目的是定义哪些NIC可以相互通信，以确保多租户云环境中的隔离。 虚拟网络对等连接不会创建物理连接，而是改变了Azure Fabric维护的映射。想象一下一个韦恩图，当实现对等连接时，定义哪些可以相互通信的循环将有一个新的圆圈。VNet1有一个包含其NIC的圆圈，VNet2有一个包含其NIC的圆圈。现在创建了一个新的圆圈，它包含VNet1和VNet2，VNet1中的任何源都可以直接（使用封装/解封装）与VNet2中的任何目标通信，反之亦然，而无需通过虚拟网络中的任何资源。

📡 **虚拟网络工作原理** 在Azure中，当数据包从源到目标传输时，不会经过任何物理跳跃。这是因为Azure的虚拟网络是软件定义的，数据包的传输是通过Azure Fabric进行封装和解封装来实现的。Azure Fabric维护着一个映射，记录了虚拟网络中所有NIC的地址和所在主机，当数据包需要从一个虚拟网络传输到另一个虚拟网络时，Azure Fabric会将数据包封装到一个新的数据包中，并将新的数据包发送到目标主机。目标主机收到数据包后，会对数据包进行解封装，并将原始数据包发送到目标NIC。 例如，当一个数据包从一个VPN网关发送到一个对等连接的虚拟网络时，数据包会先到达VPN网关的虚拟机，然后被Azure Fabric封装到一个新的数据包中，并发送到目标虚拟网络中的目标虚拟机。目标虚拟机收到数据包后，会对数据包进行解封装，并将原始数据包发送到目标NIC。 由于数据包的传输是通过Azure Fabric进行封装和解封装来实现的，因此Azure虚拟网络中不存在传统的网络路由概念，例如默认网关、traceroute等。用户需要使用Azure提供的工具，例如Test-NetConnection或Network Watcher Connection Troubleshoot/Connection Monitor来进行网络故障排查。

📣 **虚拟网络安全** 在Azure虚拟网络中，安全是通过网络策略和网络安全组来实现的。网络策略可以定义哪些虚拟网络可以相互通信，以及哪些端口可以访问。网络安全组可以定义哪些IP地址可以访问虚拟机，以及哪些端口可以访问。 由于Azure虚拟网络是软件定义的，因此用户需要了解Azure路由，并使用BGP或用户定义路由来实现所需的流量控制。例如，如果用户希望将一个虚拟网络中的流量发送到另一个虚拟网络中的防火墙，则需要使用BGP或用户定义路由来配置路由规则，以确保流量能够到达防火墙。

📥 **总结** Azure的软件定义网络与传统网络的电缆定义网络有很大的区别。在Azure虚拟网络中，用户可以自行创建和配置网络，而无需依赖Microsoft员工。Azure虚拟网络隐藏了底层物理网络的复杂性，并为用户提供了虚拟网络，用户可以在虚拟网络中创建自己的地址和前缀，并使用它们。Azure虚拟网络中的安全是通过网络策略和网络安全组来实现的。用户需要了解Azure路由，并使用BGP或用户定义路由来实现所需的流量控制。

In this post, I will explain why Azure’s software-defined networking (virtual networks) differs from the cable-defined networking of on-premises networks.

Background

Why am I writing this post? I guess that this one has been a long time coming. I noticed a trend early in my working days with Azure. Most of the people who work with Azure from the infrastructure/platform point of view are server admins. Their work includes doing all of the resource stuff you’d expect, such as Azure SQL, VMs, App Services, … virtual networks, Network Security Groups, Azure Firewall, routing, … wait … isn’t that networking stuff? Why isn’t the network admin doing that?

I think the answer to that question is complicated. A few years ago I added a question to the audience to some of my presentations on Azure networking. I asked who was a ON-PREMISES networking admin versus an ON-PREMISES something-else. And then I said “the ‘server admins’ are going to understand what I will tech more easily than the network admins will”. I could see many heads nodding in agreement. Network admins typically struggle with Azure networking because it is very different.

Cable-Defined Networking

Normally, on-premises networking is “cable-defined”. That phrase means that packets go from source to destination based on physical connections. Those connections might be indirect:

Appliances such as routers decide what turn to take at a junction pointFirewalls either block or allow packetsOther appliances might convert signals from electrons to photons or radio waves.

A connection is always there and, more often than not, it’s a cable. Cables make packet flow predictable.

Look at the diagram of your typical on-premises firewall. It will have ethernet ports for different types of networks:

ExternalManagementSite-to-site connectivityDMZInternalSecure zone

Each port connects to a subnet that is a certain network. Each subnet has one or more switches that only connect to servers in that subnet. The switches have uplinks to the appropriate port in the firewall, thus defining the security context of that subnet. It also means that a server in the DMZ network must pass through the firewall, via the cable to the firewall, to get to another subnet.

In short, if a cable does not make the connection, then the connection is not possible. That makes things very predictable – you control the security and performance model by connecting or not connecting cables.

Software-Defined Networking

Azure is a cloud, and as a cloud, it must enable self-service. Imagine being a cloud subscriber, and having to open a support call to create a network or a subnet. Maybe they need to wait 3 days while some operators plug in cables and run Cisco commands. Or they need to order more switches because they’ve run out of capacity and you might need to wait weeks. Is this the hosting of the 2000’s or is it The Cloud?

Azure’s software-defined networking enables the customer to run a command themselves (via the Portal, script, infrastructure-as-code, or API) to create and configure networks without any involvement from Microsoft staff. If I need a new network, a subnet, a firewall, a WAF, or almost anything networking in Azure (with the exception of a working ExpressRoute circuit) then I don’t need any human interaction from a support staff member – I do it and have the resource anywhere from a few seconds to 45 minutes later, depending on the resource type.

This is because the physical network of Azure is overlayed with a software-defined network based on VXLAN. In simple terms, you have no visibility of the physical network. You use simulated networks that hide the underlying complexities, scale, and addressing. You create networks of your own address/prefix choice and use them. Your choice of addresses affects only your networks because they actually have nothing to do with how packets route at the physical layer – that’s handled by traditional networking at the physical layer – but that’s a matter only for the operators of the Microsoft global network/Azure.

A diagram helps … and here’s one that I use in my Azure networking presentations.

In this diagram, we see a source and a destination running in Azure. In case you were not aware:

Just about everything in Azure runs in a virtual machine, even so-called serverless computing. That virtual machine might be hidden in the platform but it is there. Exceptions might include some very expensive SKUs for SAP services and Azure VMware hosts.The hosts for those virtual machines are running (drumroll please) Hyper-V, which as one may now be forced to agree, is scalable

The source wants to send a packet to a destination. The source is connected to a Virtual Network and has the address of 10.0.1.4. The destination is connected to another virtual network (the virtual networks are peered) and has an address of 10.10.1.4. The virtual machine guest OS sends the packet to the NIC where the Azure fabric takes over. The fabric knows what hosts the source and destination are running on. The packet is encapsulated by the fabric – the letter is put into a second envelope. The envelope has a new source address, that of the source host, and a new destination, the address of the destination host. This enables the packet to traverse the physical network of Microsoft’s data centres even if 1000s of tenants are using the 10.x.x.x prefixes. The packet reaches the destination host where it is decapsulated, unpacking the original packet and enabling the destination host to inject the packet into the NIC of the destination.

This is why you cannot implement GRE networking in Azure.

Virtual Networks Aren’t What You Think

The software-defined networking in Azure maintains a mapping. When you create a virtual network, a new map is created. It tells Azure that NICs (your explicitly created NICs or those of platform resources that are connected to your network) that connect to the virtual network are able to talk to each other. The map also tracks what Hyper-V hosts the NICs are running on. The purpose of the virtual network is to define what NICs are allowed to talk to each other – to enforce the isolation that is required in a multi-tenant cloud.

What happens when you peer two virtual networks? Does a cable monkey run out with some CAT6 and create a connection? Is the cable monkey creating a virtual connection? Does that connection create a bottleneck?

The answer to the second question is a hint as to what happens when you implement virtual network peering. The speed of connections between a source and destination in different virtual networks is the potential speed of their NICs – the slowest NIC (actually the slowest VM, based on things like RSS/VMQ/SR-IOV) in any source/destination flow is the bottleneck.

VNet peering does not create a “connection”. Instead, the mapping that is maintained by the fabric is altered. Think of it being like a Venn Diagram. Once you implement peering, the loops that define what can talk to what has a new circle. VNet1 has a circle encompassing its NICs. VNet2 has a circle encompassing its NICs. Now a new circle is created that encompasses VNet1 and VNet2 – any source in VNet1 can talk directly, using encapsulation/decapsulation) to any destination in VNet2 and vice versa without going through some resource in the virtual networks.

You might have noticed before now that you cannot ping the default gateway in an Azure virtual network. It doesn’t exist because there is no cable to a subnet appliance to reach other subnets.

You also might have noticed that tools like traceroute are pretty useless in Azure. That’s because the expected physical hops are not there. This is why using tools like test-netconnection (Windows PowerShell) or Network Watcher Connection Troubleshoot/Connection Monitor are very important.

Direct Connections

Now you know what’s happening under the covers. What does that mean? When a packet goes from source to destination, there is no hop. Have a look at the diagram below.

It’s not an unusual diagram. There’s an on-prem network on the left that connects to Azure virtual networks using a VPN tunnel that is terminated in Azure by a VPN Gateway. The VPN Gateway is deployed into a hub VNet. There’s some stuff in the hub, including a firewall. Services/data are deployed into spoke VNets – the spoke VNets are peered with the hub.

One can immediately see that the firewall, in the middle, is intended to protect the Azure VNets from the on-premises network(s). That’s all good. But this is where the problems begin. Many will look at that diagram and think that this protection will just work.

If we take what I’ve explained above we’ll understand really what will happen. The VPN Gateway is implemented in the platform as two Azure virtual machines. Packets will come in over the tunnel to one of those VMs. Then the packets will hit the NIC of the VM to route to a spoke VNet. What path will those packets take? There’s a firewall in the pretty diagram. The firewall is placed right in the middle! And that firewall is ignored. That’s because packets leaving the VPN Gateway VM will be encapsulated and go straight to the NIC of the destination NIC in one of the spokes as if it were teleported.

To get the flow that you require for security purposes you need to understand Azure routing and either implement the flow via BGP or User-Defined Routing.

Now have a look at this diagram of a virtual appliance firewall running in Azure from Palo Alto.

Look at all those pretty subnets. What is the purpose of them? Oh I know that there’s public, management, VPN, etc. But why are they all connecting to different NICs? Are there physical cables to restrict/control the flow of packets between some spoke virtual network and a DMZ virtual network? Nope. What forces packets to the firewall? Azure routing does. So those NICs in the firewall do what? They don’t isolate, they complicate! They aren’t for performance, because the VM size controls overall NIC throughput and speed. They don’t add performance, they complicate!

The real reason for all those NICs is to simulate eth0, eth1, etc that are referenced by the Palo Alto software. It enables Palo Alto to keep the software consistent between on-prem appliances and their Azure Marketplace appliance. That’s it – it saves Palo Alto some money. Meanwhile, Azure Firewall using a single IP address on the virtual network (via the Standard tier load balancer, but you might notice each compute instance IP as a source) and there is no sacrifice in security.

Wrapping Up

There have been countless times over the years when having some level of understanding of what is happening under the covers has helped me. If you grasp the fundamentals of how packets rally get from A to B then you are better prepared to design, deploy, operate, or troubleshoot Azure networking.

The post Azure’s Software Defined Networking first appeared on Aidan Finn, IT Pro.