The Azure CLI

Another tool that can be used when managing networks is the Azure CLI. With the Azure CLI, you can basically do everything you could do using the Azure portal, but this time using a more robust and automation-friendly tool that can be run on any platform.

To create a peering with the CLI, you will need to use the following command:

az network vnet peering create [-h] [--verbose] [--debug] [--output {json,jsonc,table,tsv}] [--query JMESPATH] --resource-group RESOURCE_GROUP_NAME --vnet-name NAME --name VIRTUAL_NETWORK_PEERING_NAME --remote-vnet-id REMOTE_VIRTUAL_NETWORK [--allow-vnet-access] [--allow-forwarded-traffic] [--allow-gateway-transit] [--use-remote-gateways] [--subscription _SUBSCRIPTION]

The command is structured in a way that helps us understand its particular steps. This is why it contains the main category (network), service (vnet), feature (peering), and action (create). While it is quite rich, you will actually only need four parameters:

• Resource group
• VNet name
• Name of the peering
• The peer resource ID

For the purpose of this exercise, we will create a third VNet named azureadministrator-euw-vnet3. Here, you can find the full command we used to create peering between two of my networks. By providing the following parameters, Azure will connect the two VNets:

• --vnet-name: The VNet from which the VNet communication will originate
• --name: The peering name
• --remote-vnet-id: The destination VNet

Let's see what the command looks like:

$ az network vnet peering create -g "azureadministrator-euw-rg" --vnet-name "azureadministrator-euw-vnet3" --name "SecondPeering" --remote-vnet-id "/subscriptions/.../resourceGroups/azureadministrator-euw-rg/providers/Microsoft.Network/virtualNetworks/azureadministrator-euw-vnet2"

Once the peering is created, you will get the following output:

{
  ...,
  "id": "/subscriptions/.../resourceGroups/azureadministrator-euw-rg/providers/Microsoft.Network/virtualNetworks/azureadministrator-euw-vnet3/virtualNetworkPeerings/SecondPeering",
  ...
  },
  "remoteVirtualNetwork": {
    "id": "/subscriptions/.../resourceGroups/azureadministrator-euw-rg/providers/Microsoft.Network/virtualNetworks/azureadministrator-euw-vnet2",
    ...
  },
  ...
}

The result of running the preceding command (while not mentioned in this book) will give you the full description of the created resource. It will also contain the full identifiers of the networks connected. The only challenge here is to obtain the VNet ID, which is required to complete the operation; you can obtain it with a single Azure CLI command:

$ az network vnet list

The list of VNets should be presented in a JSON array:

[
  {
    "addressSpace": {
      "addressPrefixes": [
        "10.0.0.0/24"
      ]
    },
    ...,
    "id": "/subscriptions/.../resourceGroups/azureadministrator-euw-rg/providers/Microsoft.Network/virtualNetworks/azureadministrator-euw-vnet2",
    ...
  }
  ...
]

As in the previous command example, here, you will also see the full description of particular resources (VNets). This time, however, you will see a full list of them. Of course, if you are interested in the existing peerings, you can also find them with the CLI:

$ az network vnet peering list --resource-group "azureadministrator-euw-rg" --vnet-name "azureadministrator-euw-vnet3"

Similar to a list of VNets, the list of peerings is presented as a JSON array:

[
  {
    ...,
    "id": "/subscriptions/.../resourceGroups/azureadministrator-euw-rg/providers/Microsoft.Network/virtualNetworks/azureadministrator-euw-vnet1/virtualNetworkPeerings/vnets-peering",
    ...,
    "remoteAddressSpace": {
      "addressPrefixes": [
        "10.1.0.0/28"
      ]
    },
    "remoteVirtualNetwork": {
      "id": "/subscriptions/.../resourceGroups/azureadministrator-euw-rg/providers/Microsoft.Network/virtualNetworks/azureadministrator-euw-vnet2",
      ...
    },
   ...
  }
]

With the full description, you will be able to see, for example, what the second network in the peering configuration is. To make the peering fully functional, you have to create a connection from vnet1 to vnet2 and vice versa. Once this configuration is completed, the peering status should change its value from Initiated to Connected, as shown in the following figure:

Once two VNets are peered, you can connect to the services provisioned inside them as if they were a single network. Peering also gives you the following benefits:

• The latency between two VMs hosted inside two peered networks (assuming they are in the same region) is the same as it would be if those two VMs were inside a single VNet.
• Traffic between peered VNets is routed through the internal Azure infrastructure. It does not reach the public internet or any kind of a gateway.
• If you want to secure access to a specific VNet or a subnet, you can use a network security group to achieve that kind of functionality (as opposed to disallowing communication between networks).
• Even if your networks are peered, you can still use the gateway to connect to the on-premises network.
• VNet peering also works for networks that are not in the same region. This, however, does not guarantee private traffic or low-latency communication.

To make sure that the connection between our networks is configured correctly, we deployed two VMs: aa1 and aa2. The former has a private address of 10.0.0.4 and the latter 10.1.0.4. To test the connection, we use the ping command:

As you can see, the first VM sees the second one, even though they are not in the same VNet. With that VNet feature, you can create a global private network connecting your services and machines.

With the peering capability, you can create advanced topologies that contain networks from different sites and connect multiple services.

Note that one of the most important features of the peering ability is the fact that you can connect both Azure VNet and on-premise networks. If you do this, you can leverage the bidirectional communication while still ensuring that it is kept private.

This section should help you understand what peering between different VNets involves and how it works. In the next section, you will see an alternative to peering: VNet-to-VNet connection.