Designing an Azure Virtual WAN
Implementing an Azure Virtual WAN Architecture
The course is part of these learning pathsSee 1 more
Organizations use site-to-site VPNs and ExpressRoute to connect on-premises networks to Azure. As an organization grows, so does the complexity of implementing and managing connectivity between the cloud and on-premises locations.
In this course, we review Azure Virtual Wide Area Network (WAN). Azure Virtual WAN creates a hub-and-spoke topology that provides a single interface for managing branch connectivity, user access, and connectivity between VNets. We also cover how Azure Virtual WAN hubs connect with other network resources to create a full mesh topology that serves as a backbone of a hybrid network.
- Design an Azure Virtual WAN architecture
- Understand the SKUs and related features of a Virtual WAN
- Create a Virtual WAN hub
- Create a network virtual appliance (NVA) in a virtual hub
- Configure virtual hub routing
- Understand connection units and scale units
- System or network administrators with responsibilities for connecting an on-premises network to Azure
- Anyone preparing for the Azure AZ-700: Designing and Implementing Microsoft Azure Networking Solutions exam
- A basic understanding of networking, routing, and VPN concepts
- An Azure subscription (sign up for a free trial at https://azure.microsoft.com/free/ if you don’t have a subscription)
Welcome back, in this lesson, we review and configure Azure Virtual Hub Routing. Routing defines how resources on one subnet locate resources on another subnet. This could be a direct connected subnet, a resource connected through one or more subnets, or a resource on the internet where there are many subnets, or hops, between them. Before we get into that, let's review IP addresses. There are two types of IP addresses, a public IP is what's used to host resources on the internet. When we talk about IP addresses within a Vnet or Azure Virtual WAN, we are referring to a private IP address. Private IP addresses are specific blocks of IP addresses reserved for use within a private network. These addresses cannot route on the public internet, sometimes they're referred to as non-routable IP addresses. Because they are private, they are available to use on our internal networks.
The three blocks of addresses include a class A, that starts with 10, a class B that starts with 172.16 and ends at 172.31, and a class C that starts with 192.168. As we design and deploy routing solutions in an internal network, it's important to understand that private IP addresses are for internal use only. If a packet with a private IP tries to leave the internal network boundary it's dropped at the first public router. Also, any public IP address should not be used for internal networks. For example, if we assigned a 172.60 subnet to an internal network, it may work for internal traffic, but if any public resource used an IP from that same 172.60 subnet, the user on the internal network would not be able to access it because they would be routed to the internal subnet instead of to the public.
Also, we cannot have the same subnets represented more than once on the private network. If we had two 10.20.0.0 networks, clients would have problems communicating with resources in either network. This is easy to avoid in new deployments, but as we add hybrid connectivity to our on-premises network with Azure, or add networks through mergers and acquisitions, the potential for overlapping subnets will increase. Take time to inventory and plan network additions to avoid any IP address conflicts.
Now that we understand what private IP addresses are, let's talk about routing them. Routing, in its simplest form, is how IP Packets from one subnet get to another subnet. To do this, router uses a routing table. The routing table is a list of subnets the router knows about and how to access the subnets the router is aware of. There are two types of routes that can be part of a routing table. A static route, this is a manually defined route. This is the simplest to configure, but has some downsides.
First, any changes need to be manually configured. Also, if there is a problem with the subnet, there is no way for a static route to identify the problem and mark it as unavailable or find alternate paths. A more common option is dynamic routing. Dynamic routes learn about neighboring subnets and pass that information along, forming a dynamic routing table. Dynamic routing can assign weights, or values to each path, providing for optimal routing when there are multiple paths to the same destination. With dynamic routing, any changes in the network are automatically updated and if there's a problem with a subnet, dynamic routing can find alternate paths to the resource through another subnet.
Dynamic routing is based on a routing protocol. There are several available. Routing Internet Protocol, or RIP, Open Shortest Path First, or OSPF and Border Gateway Protocol or BGP, are just a few. Azure Virtual Hubs use BGP for dynamic routing. We can also add static routes if needed. If we add static routes, those will take priority over any paths learned from BGP. Let's talk about specific features of Azure Virtual WAN routing. A Virtual WAN uses connections for routing configuration. There are four types of connections. They include site-to-site VPN connections that connect a remote site to a VPN Gateway. An Express Route connection that connects an ExpressRoute gateway to an express route circuit A Point-to-site VPN that connects a VPN user to a Point-to-site VPN gateway. And a hub virtual network connection that connects a VNet to a virtual hub.
Routing is configured for each of these connections when its set up. All connections are added to the Default route table. A connection is associated to only one routing table. This populates the connection information in that routing table. Multiple connections can be associated to the same routing table, but a connection can only be associated to one routing table. Associating the connection to the routing table adds connection information to that routing table, providing a map of what interfaces to send IP traffic based off the destination subnet. The virtual WAN can propagate routing information from the virtual hub to on-premises routers with BGP. Allowing propagation provides networks connected by site-to-site VPN, Point-to-site VPN or Express Route to dynamically learn about available networks over the connection. There's also a none route table in each virtual hub. Propagating a route to the none table will in effect prevent routes from propagating from that connection.
Route tables can be logically grouped together with labels. This is helpful when propagating routes from connections to multiple route tables. All hubs have a default route table with the label of default. When a connection is propagated to default, it's automatically applied to all default route tables across every hub in the Virtual Network. Routing can be tricky, and in complicated environments, sometimes things don't work as expected. If you run into problems, there's a reset option available in the virtual hub portal intended to bring resources, such as routing tables, the hub router and other virtual hub resources back to it's provisioned state. Using the hub reset is suggested prior to contacting Microsoft with connectivity issues. In the demo coming up, we'll view routing information on a virtual WAN and how to do a hub reset.
Travis Roberts is a Cloud Infrastructure Architect at a Minneapolis consulting firm, a Microsoft MVP, MCT, and author. Travis has 20 years of IT experience in the legal, pharmaceutical, and marketing industries and has worked with IT hardware manufacturers and managed service providers. In addition, Travis has held numerous technical certifications throughout his career from Microsoft, VMware, Citrix, and Cisco.