Subnet Level Peering Overview

Key Concepts

• Virtual Network (VNET)
• IPv4/IPv6 Address Spaces
• Subnets
• VNET Peering
• Network Interface Card (NIC)
• Routes
• Private Link
• Network Address Translation (NAT)
• Azure CLI

Virtual Networks and Peering

• A virtual network (VNET) is composed of one or more IPv4 address spaces (e.g., 10.10.0.0/16) and can also include IPv6 address spaces.
• VNETs are bound to a specific subscription and region.
• Multiple VNETs are common, often with specialized functions (e.g., a hub VNET for core services, connectivity to other clouds, or on-premises networks via ExpressRoute or Site-to-Site VPN).
• VNET peering enables connectivity between VNETs, allowing them to learn each other's IP address spaces.
• Traditionally, VNET peering exposes the entire IP address space of both VNETs, requiring no overlap in their IP ranges.
• Communication can be limited using Network Security Groups (NSGs), Azure Firewall, or Network Virtual Appliances (NVAs), but the entire address space is still exposed.

Subnet Level Peering: The New Capability

• The video introduces a new feature: subnet-level peering, which allows for more granular control over the IP address spaces exposed during VNET peering.
• Instead of exposing the entire VNET address space, you can now specify individual subnets to be peered.
• This is useful when:
  • There is some overlap in IP ranges between VNETs.
  • You don't want to expose the entire IP space of a VNET.
  • You want to peer only IPv6 address spaces.
• Alternative solutions like Private Link exist for overlapping IP ranges, using Network Address Translation (NAT) to enable communication. Private Link offers more control but might not be the desired approach in all scenarios.

Configuration and Implementation

• The peerCompleteVnet parameter in the Azure CLI or templates controls whether to peer the entire VNET or specific subnets.
• Setting peerCompleteVnet to false requires specifying both localSubnetName and remoteSubnetName for the peering connection. Wildcards are not supported; each subnet must be explicitly listed.
• The documentation shows the peerCompleteVnet parameter can be set to zero, F, false, N, or no to disable complete VNET peering.
• If using a remote gateway, the gateway subnet must be included in the allowed subnets.
• The peering connection must be created in both directions.
• Only one connection can exist between each pair of virtual networks. You cannot have both complete VNET peering and subnet-level peering between the same two VNETs.
• Subnets can be added or removed from existing subnet-level peering connections, requiring a re-synchronization of the connection.

Demonstration and Example

• The video demonstrates subnet-level peering using two VNETs: a main VNET and "spoke3."
• The main VNET has the address space 10.10.0.0/16 and is divided into three subnets.
• The "spoke3" VNET has the address space 10.103.0.0/16 and is also divided into multiple subnets.
• The example creates a peering connection where only the "infra" subnet of the main VNET is peered with subnets "subnet2" and "subnet3" of "spoke3."
• The Azure CLI is used to create the peering connections in both directions, specifying peerCompleteVnet as false and listing the specific subnets.
• After the peering is established, the routes on the network interface card (NIC) of a virtual machine in the "infra" subnet of the main VNET are examined.
• The routes show that the NIC only knows about the IP address spaces of "subnet2" and "subnet3" of "spoke3" (10.103.1.0/24 and 10.103.2.0/24), and not the entire 10.103.0.0/16 address space.

Benefits and Use Cases

• Limited IP Space Exposure: Reduces the attack surface by only exposing necessary subnets.
• Overlapping IP Ranges: Enables peering even with some overlapping IP ranges (though Private Link is still recommended for more complex scenarios).
• IPv6 Only Peering: Allows peering of only IPv6 address spaces, excluding IPv4.
• Specific Requirements: Provides granular control over what is shared between VNETs, catering to specific security or network design requirements.

Conclusion

Subnet-level peering is a valuable new feature that provides more control and flexibility when connecting virtual networks in Azure. By allowing administrators to specify which subnets are peered, it enhances security, simplifies network management, and enables new scenarios that were previously difficult or impossible to implement. The ability to limit IP space exposure, handle overlapping IP ranges, and peer only IPv6 address spaces makes subnet-level peering a powerful tool for modern cloud networking.