Create 3 VNETS where all traffic is routed through one VNET (hub and spoke)

Question

I'm trying to figure out how to answer I question I recently had on an exam. The requirements are as follows:

1. You plan on creating 100 VMs across 3 virtual networks (vnetA, vnetB, and vnetC)
2. All traffic must be routed through vnetA
3. All virtual machines must be able to talk to each other via private IP
4. Solution must not require any virtual gateways
5. Solution must minimize the number of peerings.
6. Solution must not require any network virtual appliance (VM acting as router)

To me, this sounds like a hub and spoke topology where I perform the following steps.

1. Create vnet peering from vnetA to vnetB (allow forwarded traffic)
2. Create vnet peering from vnetB to vnetA
3. Create vnet peering from vnetA to vnetC (allow forwarded traffic)
4. Create vnet peering from vnetC to vnetA

Now I need the spoke to spoke connectivity (between vnetB and vnetC) but it has to pass through vnetA which is where I get confused. My first thought was to simply enable Allow gateway transit/Use remote gateways options between the two peerings above, but it doesn't allow that due to vnetA not having virtual network gateway (I even tried adding a GatewaySubnet to vnetA).

I can't seem to use a custom route table attached to the subnets of vnetB and vnetC to specify a next hop unless I use a virtual appliance which can't be used in this solution.

Anyone have any ideas on how they would approach this problem?

Answer 1

This requires Hub and Spoke Design:

1. Create VNET Peering between VNET A and VNET B
2. Create VNET Peering between VNET B and VNET A
3. Create VNET Peering between VNET C and VNET B
4. Create VNET Peering between VNET B and VNET C
5. Add a Subnet Gateway in VNET B
6. Allow Gateway Transit on VNET B -VNET A Peering
7. Allow Gateway Transit on VNET B -VNET C Peering
8. Create Virtual Network Gateway in VNET B
9. Create Routing Tables
10. Attach Routing Tables to VNET A and VNET B Subnets
11. Enable Remote Gateway on VNET A - VNET B Peering
12. Enable Remote Gateway on VNET C - VNET B Peering

Answer 2

The question does not say that NVAs cannot be used, but any deployment of such would constitute you deploying a routing solution. The question explicitly states what you would do before configuring IP routing, and so the answer may not be as complicated as you expect.

You do not need a gateway subnet or virtual gateways to implement a hub and spoke topology assuming that you are going to provision, for example, a VM with IP Forwarding enabled on the vNIC to act as a router.

1. Create your 3 subnets, in your example vnetA, vnetB and vnetC
2. From vnetA, create a peering with VNETb using the Resource Manager Deployment Model
3. Ensure "Allow forwarded traffic from vnetA to vnetB" is enabled
4. Repeat steps 2 & 3, substituting vnetB for vnetC

And that's it. Now when you configure IP routing you will provision a router VM or some other Network Virtual Appliance (NVA) in the hub network and create a Route Table for later application to vnetB and vnetC specifying the router VM's internal IP as the next hop.

Answer 3

As far as I know, it's impossible to meet all the requirements 1-6. Since peering connections are non-transitive eventhough Transitive network flow between peered vnets is on MS roadmap from this feedback here, you have to create VNet peering between VNetB and VNetC. But this method will add the number of peerings and traffic Between VNetB to VNetC will not be routed via VNetA.

After having a quick test, select Allow forwarded traffic is not enough. This configuration option is necessary when configuring virtual networking appliances within your hub VNet so that transit traffic can route through the hub. More details here.

Allow forwarded traffic: Check this box to allow traffic forwarded by a network virtual appliance in a virtual network (that didn't originate from the virtual network) to flow to this virtual network through a peering. For example, consider three virtual networks named Spoke1, Spoke2, and Hub. A peering exists between each spoke virtual network and the Hub virtual network, but peerings don't exist between the spoke virtual networks. A network virtual appliance is deployed in the Hub virtual network, and user-defined routes are applied to each spoke virtual network that route traffic between the subnets through the network virtual appliance. If this checkbox is not checked for the peering between each spoke virtual network and the hub virtual network, traffic doesn't flow between the spoke virtual networks because the hub is not forwarding the traffic between the virtual networks. While enabling this capability allows the forwarded traffic through the peering, it does not create any user-defined routes or network virtual appliances. User-defined routes and network virtual appliances are created separately. Learn about user-defined routes. You don't need to check this setting if traffic is forwarded between virtual networks through an Azure VPN Gateway.

To conclude, you have to create a VPN gateway for the hub-spoke network or use a virtual appliance as the hub and create UDR for the spoke network. Or simply create a peering between VNetB and VNetC.

Answer 4

You're on the right path mate. This all needs to be ARM; when you peer VNET A and B, all you need to do is select "Allow virtual network access from VNET A/B = Enabled" for the peering between A and B and B and A. Then, for the peering between B and A only, select "Allow forwarded traffic from VNETA = Enabled".

You don't need any peering between B and C.
Allow forwarded traffic means that traffic not originating from VNET A (so VNET C) is allowed to come into VNET B.

Repeat the same process between B and C. Then you'll have a hub and spoke design. Traffic from B will get to C via A. Because you're not traversing any traffic to ExpressRoute or a VPN or a classic VNET, you don't need any gateway.