What will you learn in this blog?
- What is Azure Virtual Network Manager’s UDR management feature?
- How UDR management simplifies route settings
- How you can automate routing behavior for the following scenarios:
- Spoke virtual networks communicate to each other in a hub and spoke topology via a firewall in the hub
- Spoke virtual networks in two hub and spoke topologies communicate via firewalls in the hubs
What is Azure Virtual Network Manager?
Azure Virtual Network Manager (AVNM) is a highly scalable and available network management solution that allows customers to simplify and scale their networks in Azure.
Learn more about AVNM in our public documentation.
What is AVNM's UDR management feature and what is it solving?
User-defined route (UDR) management is a feature in AVNM that allows customers to describe their desired routing behavior via routing configurations that consist of routing rules. Upon deployment of the routing configuration, AVNM orchestrates UDRs to create the desired behavior.
AVNM aims to make managing routing behaviors easier and faster. Customers usually want to achieve different routing behaviors, and they usually create UDRs by hand or use custom scripts – however, these methods are complex and can cause mistakes, especially at scale. AVNM’s UDR management can simplify the process for you.
How does UDR management work?
UDR management configuration and rule collections
Similar to AVNM’s security admin feature, the UDR management feature is structured as a configuration that can contain multiple routing rule collections, which each can contain multiple routing rules.
Users create a routing configuration to define the desired routing behavior. Eventually, the user will need to deploy the routing configuration for the routing behavior described in its rules to take effect.
Within a routing configuration, there can be multiple rule collections. The function of the rule collection is to associate its rules with one or more target network groups, enabling users to achieve reusability and simplicity without recreating the same UDRs across several resources.
In a rule collection, route rules specify the desired routing behavior for all the members of its rule collection’s target network group(s), which can consist of subnets or virtual networks (VNets).
After the routing configuration (containing rule collection(s) targeting network group(s)) is deployed to the desired regions, then all the targeted subnets will receive the UDRs described in the routing configuration. Even after deployment, subnets that are newly created or added to the target network group(s) will receive the routing configuration’s UDRs – meaning users do not need to manually touch route tables.
Local route setting
You can select whether you want to create a local routing behavior so that if the source and destination are in the same VNet or subnet, then traffic routes directly to the destination.
You can choose from the following behaviors:
- If the source and destination are in the same VNet, route to the destination directly.
- If the source and destination are in the same subnet, route to the destination directly.
- None of the above behavior.
The local route setting is especially useful when you create a routing configuration, intending for “traffic to go to 0/0 via an NVA but not when the destination is in the same VNet or subnet.”
Selecting "Direct routing within virtual network" or "Direct routing within subnet" creates a UDR with a "virtual network" next hop for local traffic routing within the same VNet or subnet. However, if the destination CIDR is fully contained within the source CIDR under these selections and direct routing is selected, a UDR specifying a network appliance as the next hop won't be set up.
Route rule
Each route rule consists of the following attributes:
- Name
- Destination type
- IP address
- Destination IP addresses/CIDR ranges
- Service tag
- IP address
- Next hop type
- Virtual network gateway
- Virtual network
- Internet
- Virtual appliance
- Next hop address
Use Azure Firewall as the next hop
In AVNM’s UDR management, you can also easily choose an Azure Firewall as the next hop by importing Azure Firewall private IP address in your AVNM’s scope. AVNM will use the IP of the Azure Firewall you choose as the next hop.
For each type of next hop, please refer to the public documentation on UDRs.
Sample use cases
Below, we are going to demonstrate how you can use AVNM’s UDR management to create common routing behaviors.
Scenario I – route all traffic to Azure Firewall in a hub and spoke topology but not in the local VNet
Many customers want to route all traffic to an Azure Firewall, except the destination is in the same VNet since workloads in the same VNet are trusted.
Traditionally, creating such settings are cumbersome as new UDRs need to be created for each new subnets, and all route tables have different UDRs.
AVNM’s UDR management can achieve this scenario shown below in just a few steps.
Step 1. Create Network Manager
In the Azure Portal, click “Create network manager” and enable the user-defined routing feature.
Step 2. Create a spoke network group
After the successful creation of your Azure Virtual Network Manager resource, in the Network Groups page, select the button "Add a network group."
Create a network group by naming it and adding VNets to the group. You can add VNets manually as static group members, or automatically as dynamic group members through conditional statements.
Here, we are going to create a network group of spoke VNets in the hub and spoke topology with the condition of VNets’ name containing “ANMDemo-Spoke.”
Step 3. Create a routing configuration and rule collection
Navigate to the Configurations page under Settings and select "Create" with the type "Routing configuration," and add a rule collection, where the target network group is your spoke network group.
Step 4. Create routing rules
Create the following rule.
By using the above rule, you can easily route all traffic to an Azure Firewall, except the destination is in the same VNet to reduce latency for routing and inspection cost if the traffic within the same VNet is trusted. All new subnets in the VNets belonging to the spoke network group can automatically get the necessary UDRs to make this routing behavior happen.
Step 5. Commit the configuration
Deploy the configurations, and the target regions to commit your desired configuration(s).
Variation – route all traffic to Azure Firewall in a hub and spoke topology but trusted VNets can communicate directly
In this topology, some spoke VNets are directly connected by using AVNM's direct connectivity, unlike the hub and spoke topology above. This topology helps some trusted VNets communicate directly without the hub's firewall. This way, the latency between these VNets can be reduced. You can monitor the traffic between these VNets by using virtual network flow logs.
Step 1. Create a network group of trusted VNets
- In your Network Manager resource, navigate to the Network groups page under Settings and select Create and create a network group with the member type Virtual network.
- In the newly created network group, select Group members and click Add to add existing VNets.
Step 2. Create a connectivity configuration
- In your Network Manager resource, navigate to the Configurations page under Settings and select Create - Connectivity configuration and create connectivity configurations.
- In the Topology tab, select the Hub and spoke option and choose a hub VNet where the trusted spoke VNet is selected, and add the network group created in Step 1. Also check the Enable connectivity within network group option to enable direct connectivity within trusted VNets.
Step 3. Commit the configuration
Deploy the connectivity configuration to the target region to commit your desired configuration.
In your Network Manager resource, navigate to the Deployments page under Settings and click Deploy configurations – Connectivity configuration.
In Connectivity configurations, select Connectivity configuration you have created, and select the target regions where the configuration to be deployed.
Click Next and review the configuration to be deployed, then click Deploy.
Scenario II – spoke to spoke across two hubs (two hub and spoke topologies)
Some customers use a hub and spoke architecture for each region. It required many manual operations to do cross-hub and spoke with FWs/NVAs in the past because users needed many UDRs to be set up by hand, and when there were changes in spoke VNets, such as adding new spoke VNets and subnets, they also needed to change UDRs and route tables.
With UDR management, you can create the following:
|
Route rule collection for spoke network group 1: Target network group = spoke network group 1 Add a route rule for each spoke VNet in hub and spoke 2: go to the spoke via FW1 in region 1
Route rule collection for AzFw1 network group 1 (network group of subnets): Target network group = network group consisting of only AzFw1 subnet Add a route rule for: go to the spokes via FW2 in region 2
Route rule collection for spoke network group 2: Target network group = spoke network group 2 Add a route rule for each spoke VNet in hub and spoke 1: go to the spoke via FW2 in region 2
Route rule collection for AzFw network group 2 (network group of subnets): Target network group = network group consisting of only AzFw2 subnet Add a route rule: go to the spokes via FW2 in region 2 |
Note: you can create a network group of subnets for the subnet of Azure Firewall or any other firewall.
You need to add a route rule to the associated rule collection and deploy the configuration when there is a new spoke VNet in the environment. The rest will be orchestrated by AVNM.
In this scenario, we’ll create the following multi-hub and spoke topologies to work with a routing configuration.
Prerequisites:
- VNets and Azure Firewall instances already exist. Please reference Azure Firewall's tutorial for setup.
- Azure Firewall needs to have network rules to allow cross-region traffic.
- VNets in each hub are connected to each other and connect to the spoke VNets in the local region. You can reference AVNM's connectivity configuration documentation to configure a hub and spoke topology in each region.
- Create a VM in a spoke VNet to confirm network connectivity across regions.
Note: if you manually create VNet peerings, you need to check the "Allow <VNet name> to receive forwarded traffic from the peered virtual network" option, otherwise the forwarded traffic received from your Azure Firewall will be dropped. See the VNet peering public documentation for more information.
Step 1. Create network groups
Create these four network groups to archive multiple hub and spoke topologies in your existing network manager resource. Also, in this demo, we assume that each spoke has two VNets.
- Network group for spoke VNets in WestUS2
- Network group for AzureFirewallSubnet in WestUS2
- Network group for spoke VNets in EastUS
- Network group for AzureFirewallSubnet in EastUS
- Create network group for spoke VNets in WestUS2
In your Network Manager resource, navigate to the Network groups page under Settings and select Create and create a network group with member type Virtual Network.
After successfully creating the network group, add spoke VNets in WestUS2 as group members.
Note: In this demo, we're manually adding members, but it's also possible to adopt a configuration where VNets are automatically added using Azure Policy. - Create network group for AzureFirewallSubnet in WestUS2
In your Network Manager resource, navigate to the Network groups page under Settings and select Create and create a network group with member type Subnet.
After successfully creating the network group, add AzureFirewallSubnet in WestUS2 as a group member. - Create network group for spoke VNets in EastUS
Repeat the same procedure outlined in (1) for EastUS.
- Create network group for AzureFirewallSubnet in EastUS
Repeat the same procedure outlined in (2) for EastUS.
Done! Now we have created four network groups with the appropriate VNets and subnets included. We’ll create routing rules for each of these network groups in a later step.
Step 2. Create a routing configuration and rule collections
Create a routing configuration with four rule collections. Each rule collection needs to be attached to a corresponding network group created in Step 1.
Note: A routing configuration is a resource that contains multiple rule collections, and each rule collection includes rule(s) that describes actual routing information. The relationship of these resources are as follows:
- Create routing configuration
In your Network Manager resource, navigate to the Configurations page under Settings and select Create and select Routing configuration.
In the Create a routing configuration pane, input a configuration name, and click Next.
In the Rule collections tab, click Add to create rule collections.
Create four rule collections as follows without rules. Each rule collection has a 1:1 relationship with the network groups created in Step 1.Click Next and Create the routing configuration.
We have attached a rule collection to each network group, but there are no routing rules yet in the rule collections. Now we need to create the actual routing rules for each rule collection in the next step to achieve cross-region connectivity.
Step 3. Create routing rules for each rule collection
In this step, we’ll create routing rules in the following Rule collections which was created in the previous step.
- RuleCol-Spoke-WestUS2
- RuleCol-FWSubnet-WestUS2
- RuleCol-Spoke-EastUS
- RuleCol-FWSubnet-EastUS
- Routing rules for RuleCol-Spoke-WestUS2
We need to add routing rules for the WestUS2 spoke VNets. For this example, we’ll create a 0/0 route (default route) with the local Firewall as the next hop. This configuration not only allows filtering of traffic towards the internet but also enables using the local Firewall as a router to facilitate communication between spokes across regions.
In your Network Manager resource, navigate to the Configurations page under Settings and select the rule configuration created in Step 2.
In the rule configuration, select the rule collection for the spoke VNets in WestUS2.
Click Add to create a rule. Destination IP addresses/CIDR ranges is the default route (0/0), Next hop type is Virtual appliance, and Next hop address is your Azure Firewall IP Address in WestUS2.
Click Add to create the rule. - Routing rules for RuleCol-FWSubnet-WestUS2
We need to add routing rules for the Azure Firewall subnet. We need to add the address prefix used in the remote region, because spoke VNets in each region don’t know any of the address prefixes in the remote region. Therefore, to facilitate communication between spokes in different regions, it's necessary to relay traffic to the firewall in each region, and we'll create a routing rule here for that purpose.
Note: In this demo, we create a summary of the address prefixes used in the remote region instead of creating each VNet’s address prefix (e.g. address prefixes used in the remote region are 10.0.0.0/22, 10.0.11.0/0, 10.0.12.0/24, and these prefixes can be summarized by 10.0.0.0/16).
Summarizing address prefixes offers the benefit of not needing to change the routing rules for the firewall subnet even if new spokes are added to each region. However, it's important to pre-define the address prefixes used in each region, including for future use.
In the rule configuration, select the rule collection for the Azure Firewall subnet in WestUS2.
Click Add to create the rule. Destination IP addresses/CIDR ranges is a summary of the address prefixes used in the remote region, Next hop type is Virtual appliance, and Next hop address is your remote Azure Firewall IP Address in EastUS.
Click Add to create the rule.The AzureFirewallSubnet has a requirement to have a default route (0.0.0.0/0) with next hop type internet. Then we have to add this rule in this rule collection.
- Routing rules for RuleCol-Spoke-EastUS
Repeat the same procedure outlined in (1) for EastUS. - Routing rules for RuleCol-FWSubnet-EastUS
Repeat the same procedure outlined in (2) for EastUS.From the above steps, we have defined the configurations, but there have been no changes in the actual environment yet. In the next step, we will deploy the defined configuration and ensure that routing is operational.
We can see all the defined rules at a glance from Routing Configuration - Rules.
Step 4. Commit the configuration
Deploy the routing configuration to the target region to commit your desired configuration.
In your Network Manager resource, navigate to the Deployments page under Settings and click Deploy configurations – Routing configuration.
In User defined routing configurations, select the routing configuration you have created, and select the target regions where the configuration needs to be deployed.
Click Next and review the configuration to be deployed, then click Deploy.
Once the configuration is successfully deployed, you’ll be able to see the route tables created by Network Manager are automatically linked to the subnet(s).
Select one of the VNets targeted by the routing configuration and navigate to Subnets and select the link of the route table attached to the subnet.
You’ll be able to confirm the defined routes exist in this route table.
You can also check if VMs located in different regions can connect to each other.
Step 5. Adding spoke VNet to the existing multi-hub-spoke topologies
All you need to do is add the new spoke VNet to the existing network group, and network manager will automatically detect the membership change and apply defined routing rules to the new VNet. Similarly, when removing a VNet from the network group, the applied routing rule will be automatically removed as well.
In summary
By using UDR management, you can simplify the configuration and maintenance of routing behaviors. With network groups and routing rules, you can define and apply routing rules to multiple VNets without manually configuring route tables for each VNet or subnet. You can also easily add or remove VNets from the network groups and have the routing rules automatically update route tables for you accordingly. This makes it easy for users to manage various routing behaviors for different topologies.
