Caveats in Azure Networking for Cisco Engineers

Azure networking can be challenging to grasp, especially if you’re accustomed to the OSI model perspective from Cisco certifications, where network device behavior aligns closely with physical and data-link layer constructs.

The need for this documentation emerged when I first worked in an Azure environment and discovered that two peered virtual networks (VNets) could still communicate, even though I had blocked traffic between their subnets.

A VNet is the foundational network entity in Azure, acting as a secure container for subnets and other network resources. Think of it as a router, though it operates purely at Layer 3 and all networks within can reach each other by default.

Traffic within a VNet, including between its subnets, incurs no additional cost, except when egressing to the internet. In contrast, traffic between peered VNets carries a minimal charge.

As noted earlier, two VNets are fully isolated by default. Once peered, however, all subnets within each VNet can communicate without requiring explicit route definitions. Peering establishes a next-hop route with a lower administrative distance to the peered VNet’s networks, managed automatically by Azure’s underlying fabric.

Unlike tools like EVE-NG, where links emulate physical cables (Layer 2 behavior), Azure VNet peering operates strictly at Layer 3, offering no tenant-level control over Layer 2 forwarding.

To regulate traffic between peered VNets, you must introduce a user-defined route (UDR) directing traffic to a routing appliance, such as a network virtual appliance (NVA). Similarly, to segment networks within a VNet, a UDR must force via default routes to a routing appliance interface who has interfaces within each subnet.

For stub networks with no additional peered VNets, a default route (0.0.0.0/0) to the appliance often suffices. A key point about VNet peering is that it is non-transitive, similar to BGP behavior.

For example, if VNet 1 is peered with VNet 2, and VNet 2 is peered with VNet 3 (1<-> 2 <-> 3), VNet 1’s networks are not advertised to VNet 3. To enable communication between VNet 1 and VNet 3, you must establish a direct peering (1 <-> 3).

For a hub-and-spoke topology—where transitive routing is desired—you’d need to deploy a routing appliance (e.g., an NVA) in the hub VNet, configure UDRs, and potentially leverage Azure Virtual WAN or a similar solution, as native VNet peering does not support transitive routing.