Let's start with an overview, of the network we are reviewing. We have one virtual WAN with two virtual hubs. One in East US and one in West Europe. The hubs are connected with a hub-to-hub connection. East US has two VNets with the 10.100 and 10.110 prefix. Our West Europe site has a VNet with the prefix 10.210 and a site-to-site VPN, with the remote site at subnet 10.200. Let's go into the Virtual WAN portal, and open the virtual WAN. Here we are in the Virtual WAN portal. First let's look at the East US Hub. To view and modify routing information, go to Routing under Connectivity. Here are the two route tables. Default is the one in use, none will not propagate routing information, to other networks.

Let's go to effective routes. Select the default route table. This could take a few seconds to open. We have a route for 10.100 and 10.110, the next hub is a virtual network connection. We also have the 10.210 network, that's on the remote hub. Let's look at the network diagram again. There is our 10.100 and 10.110 network, and the 10.210, but we didn't see the 10.200, located over the site to site VPN. We should see that. Let's look at the West Europe hub, to see what's going on. We go back to VirtualWAN. West Europe Hub. Here we are in the West Europe Hub. The site-to-site VPN is showing as provisioning.

Let's go to VPN site-to-site. And here we can see the problem. The site-to-site VPN is not connected. The virtual machine running routing and remote access, is shut down every night for this lab. Because the link was not available, the routes are not showing in the routing table. I'll pause here and start the server so the site will connect. Okay, now it shows connected. I wouldn't recommend shutting down servers in production, but this is a lab and it makes for a good example. Let's go back to the East US Hub. We go to routing, effective routes and select the default route table. This looks better, now both 10.210 and 10.200 are showing, with the next hubs set to the remote hub. WEuropeHub more specifically.

There are two points to recognize. First the route to the remote site-to-site location, was removed and added based on the link availability. This is what dynamic routing is for. When the location is not available, it's removed from the route table. Second, while the 10.100 and 10.110 connection, is giving a specific next hop location, East US 2 Connect and East US Connect, the 10.210 and 10.200 are simply specifying the remote hub, WEuropeHub as the next hub. Let's go look at the WEuropeHub and compare.

We go back to the VirtualWAN, going to the WEuropeHub, routing, effective routes, and we'll select the default route table. Here in the West Europe Hub, we have the 10.200 and 10.210 network, with the next hub showing the connection. But now the 10.100 and 10.110 network, are showing the remote hub as the next hub. In both cases the hub knew that, the subnets were on the other hub. It didn't know or care to know what interface it was on, it just needs to know the next hub, where to send that traffic.

One last thing before we go. If we run into trouble, maybe routing isn't behaving like it should, Microsoft recommends doing a hub reset, before contacting support. This can be done by going to the overview page in the hub, and issue a hub reset. Resetting the hub will take a few minutes to finish. That is how to view the routing configuration, on a routing table and issue a hub reset.