1.2 Virtual Network Peering & Global Peering

Virtual Network Peering & Global Peering

Virtual Network Peering seamlessly connects two Azure Virtual Networks at Layer 3. Once peered, virtual machines and private endpoints across both VNets communicate as if they were residing within the same physical network, utilizing private IP addresses directly.

Peering traffic travels entirely across the high-speed Microsoft global backbone network. It never traverses the public internet, encounters encryption/decryption overhead (unless explicitly configured via MACsec or IPsec), or passes through gateway bottlenecks.

---

1. Regional vs. Global VNet Peering

Azure supports two geographic scopes of virtual network peering:

1. Regional VNet Peering: Interconnects virtual networks residing within the same Azure region (e.g., East US to East US).
2. Global VNet Peering: Interconnects virtual networks residing across different Azure regions or different continents (e.g., East US to West Europe or Southeast Asia).

---

2. Peering Prerequisites & Address Space Mechanics

To establish a successful peering link between two VNets, the following conditions must be satisfied:

• No Overlapping Address Space: The address spaces of the two VNets must not overlap in any IPv4 or IPv6 prefix. Even a single overlapping /24 within a /16 block will cause peering creation to fail.
• Bidirectional Link Establishment: Peering consists of two independent unidirectional links: VNet-A to VNet-B, and VNet-B to VNet-A. The peering status becomes Connected only when both links are created and point to each other. If one side is deleted, the remaining link transitions to Disconnected and traffic halts.

+-----------------------------------------------------------------------------+
|                     BIDIRECTIONAL PEERING STATE MACHINE                     |
|                                                                             |
|   [VNet-A: 10.1.0.0/16]                     [VNet-B: 10.2.0.0/16]           |
|            |                                         |                      |
|            |--- (1) Admin creates link to VNet-B --->|  Status: Initiated   |
|            |<-- (2) Admin creates link to VNet-A ----|  Status: Connected   |
|                                                                             |
|   Both sides must reach 'Connected' state for SDN route injection!          |
+-----------------------------------------------------------------------------+

[!TIP] Dynamic Address Space Modification: Previously, changing or adding an address prefix required tearing down all existing peerings. Modern Azure SDN supports Address Space Sync: you can add a new address prefix to a peered VNet and trigger a synchronization action to inject the new routes into peered VNets without downtime.

3. The Non-Transitive Peering Rule & Inter-Spoke Routing

Virtual network peering is strictly non-transitive across the Azure SDN fabric.

The Non-Transitive Principle

If VNet A is peered to Hub VNet B, and Hub VNet B is peered to VNet C:

• Workloads in VNet A CANNOT communicate with workloads in VNet C through the native peering fabric.
• Azure SDN does not automatically route packets across intermediate peered hops.

+-----------------------------------------------------------------------------+
|                       NON-TRANSITIVE PEERING LIMITATION                     |
|                                                                             |
|   [Spoke VNet A] <==== Peered ====> [Hub VNet B] <==== Peered ====> [Spoke VNet C]
|     (10.1.0.0/16)                     (10.0.0.0/16)                   (10.2.0.0/16)
|          |                                                                 |
|          X----------------- Direct Native Traffic BLOCKED -----------------X
|                                                                             |
|   RESOLUTION: Place Azure Firewall / NVA in Hub VNet B + Attach UDR to Spokes
+-----------------------------------------------------------------------------+

Enabling Transitive Inter-Spoke Communication:

To route traffic between Spoke A and Spoke C through the Hub:

1. Deploy an Azure Firewall or third-party Network Virtual Appliance (NVA) inside Hub VNet B (e.g., private IP 10.0.1.4).
2. Associate a User-Defined Route (UDR) table to the subnets in Spoke A with a route for 10.2.0.0/16 setting Next Hop Type = Virtual Appliance and Next Hop IP = 10.0.1.4.
3. Associate a matching UDR table to the subnets in Spoke C for destination 10.1.0.0/16 pointing to 10.0.1.4.
4. Enable AllowForwardedTraffic on the peering configurations between the Hub and the Spokes.

---

4. Service Chaining: Peering Plus UDRs

Microsoft's term for deliberately steering peered traffic through an intermediate appliance is service chaining, and it is named directly in the AZ-700 objectives. Service chaining is not a switch you turn on — it is the combination of three things you already have:

The canonical hub-and-spoke chain

1. Peer Spoke A and Spoke B to the Hub, with Allow forwarded traffic enabled on the hub side of each peering.
2. Deploy the firewall or NVA in the hub.
3. On each spoke subnet, associate a route table with a UDR for the other spoke's prefix — or 0.0.0.0/0 — whose next hop type is Virtual appliance and whose next hop address is the appliance's private IP.
4. Traffic now flows Spoke A → Hub appliance → Spoke B, giving you inspection, logging, and policy enforcement on east-west traffic that peering alone would have delivered directly.

Gateway transit is the same idea applied to hybrid traffic: instead of chaining through an appliance, the spoke chains through the hub's VPN or ExpressRoute gateway, which is why the two tasks appear in the same blueprint bullet.

[!IMPORTANT] Service chaining needs both halves. Enabling Allow forwarded traffic without a UDR changes nothing — the spokes still take the direct system route to each other. Writing the UDR without Allow forwarded traffic on the hub peering causes the hub to drop the forwarded packets. Exam scenarios routinely present one half and ask what is missing.

---

5. Peering Configuration Flags & Gateway Transit

Every peering link exposes four critical configuration flags that govern routing behavior and security:

+-----------------------------------------------------------------------------+
|                        PEERING CONFIGURATION FLAGS MATRIX                   |
|                                                                             |
|   Flag Name                    Default   Purpose & Operational Impact       |
|   --------------------------   -------   ---------------------------------- |
|   AllowVirtualNetworkAccess    Enabled   Injects peered VNet address space  |
|                                          into default system routing tables.|
|   AllowForwardedTraffic        Disabled  Allows traffic NOT originating     |
|                                          from within peered VNet (NVA flow).|
|   AllowGatewayTransit          Disabled  (HUB ONLY) Allows peered spokes to |
|                                          utilize hub's VPN/ER Gateway.      |
|   UseRemoteGateways            Disabled  (SPOKE ONLY) Directs spoke to use  |
|                                          the hub's gateway for on-prem path.|
+-----------------------------------------------------------------------------+

Gateway Transit Rules for Hub-and-Spoke Topologies:

1. Hub Peering Link Configuration: Set AllowGatewayTransit = true on the peering link located in the Hub VNet pointing to the Spoke VNet.
2. Spoke Peering Link Configuration: Set UseRemoteGateways = true on the peering link located in the Spoke VNet pointing to the Hub VNet.
3. Mutual Exclusivity Constraint: A Spoke VNet cannot enable UseRemoteGateways if that Spoke VNet already contains its own Virtual Network Gateway (VPN Gateway or ExpressRoute Gateway). Only one gateway path can be active.