Service chaining and hub-and-spoke networks
A common way to reduce duplication of resources is to use a hub-and-spoke network topol- ogy. In this approach, shared resources (such as domain controllers, DNS servers, monitoring systems, and so on) are deployed into a dedicated hub VNet. These services are accessed from multiple applications, each deployed to their own separate spoke VNets.
As discussed earlier in this skill, VNet peering is not transitive. This means there is no auto- matic connectivity between spokes in a hub-and-spoke topology. Where such connectivity is required, one approach is to deploy additional VNet peerings between spokes. However, with a large number of spokes, this can quickly become unwieldy.
FIGURE 4-6 VNet peerings do not have a transitive relationship
An alternative approach is to deploy a network virtual appliance (NVA) into the hub through user-defined routes (UDRs) to route inter-spoke traffic through the NVA. This is known as service chaining, and it enables spoke-to-spoke communication without requiring additional VNet peerings, as illustrated in Figure 4-7.
FIGURE 4-7 Service chaining allows for the use of common services across VNet peerings
To transit traffic from one spoke VNet to another spoke VNet via an NVA in the hub VNet, the VNet peerings must be configured correctly. By default, a peering connection will only accept traffic originating from the VNet to which it is connected. This will not be the case for traffic forwarded between spoke VNets via an NVA in a hub VNet. To permit such traffic, the Allow Forwarded Traffic setting must be enabled for those VNet peerings.
Shared virtual network gateways
Suppose you want two peered VNets, called VNet-A and VNet-B, to send traffic to an external network via a virtual network gateway. Rather than deploy two virtual network gateways, it is much simpler and more cost-efficient for both VNets to share a single gateway. This can be achieved with local or global peering.
Suppose the virtual network gateway is deployed to VNet-A, allowing VNet-A to communi- cate with the external network. By default, only traffic originating in VNet-A is permitted to use this gateway, and the external network is only able to connect to VMs in VNet-A. To allow con- nectivity between VNet-B and the external network, the following settings must be configured:
- Enable VNet-B To Use VNet-A’s Remote Gateway This setting must be enabled on the peering connection from VNET-B to VNET-A. This informs VNET-B of the availability of the gateway in VNET-A. Note that to enable this setting, VNET-B cannot have its own virtual network gateway.
- Allow Gateway In VNet-A To Forward Traffic To VNet-B This option must be enabled on the peering connection from VNET-A to VNET-B. This permits traffic from VNET-B to use VNET-A’s gateway to send traffic to the external network. Gateway transit can be used for S2S, P2S, and VNet to VNet.
Note that in this case, the Allow VNet-B To Receive Forwarded Traffic From VNet-A peering option is not required.