Configuring public preview VNET Peering in Azure
As promised , after testing VNET peering, I post a small instruction how you can try it out in your Microsoft Azure subscription.
Since this feature is not yet part of the main service, you need to register your subscription to participate in the public preview for VNET peering. This can be done using the following PowerShell command:
The output of the command will show you that your subscription is now in the status " Registering ". You will have to wait some time until this process is complete. Check whether the registration is completed, you can:
As a result, you should see the status " Registered ":
If you have not yet registered and have not used the public preview of the network-related functions, then you will also need to register the network functions provider itself:
When configuring VNET peering, it is important to understand that this connection needs to be configured on both sides (this is especially true for setting up peering between subscriptions). We need a VNET object for which we want to configure the connection and the VNET id with which we want to associate it.
An example of setting up peering between two networks in one subscription:
')
If you look at the properties of these links with:
Then you will notice that you have some pretty interesting properties that you can, either set when creating a connection, or change later:
AllowVirtualNetworkAccess
Determines whether the address space of the remote VNET is included in the Virtual_network tag.
AllowForwardedTraffic
Defines the behavior (accept / reject) in relation to traffic coming through this connection, but not directly from the remote VNET.
AllowGatewayTransit
Allows the remote network to use the gateway on your network.
UseRemoteGateways
Allows you to use Gateway on a remote network. AllowGatewayTransit must be enabled on the remote network. Your network should not have its own gateway.
As you can see, the July update made available a new and very interesting tool for organizing virtual networks in the Microsoft Azure cloud.
Register for the public preview
Since this feature is not yet part of the main service, you need to register your subscription to participate in the public preview for VNET peering. This can be done using the following PowerShell command:
Register-AzureRmProviderFeature -ProviderNameSpace Microsoft.Network -FeatureName AllowVnetPeering: The output of the command will show you that your subscription is now in the status " Registering ". You will have to wait some time until this process is complete. Check whether the registration is completed, you can:
Get-AzureRmProviderFeature -ProviderNameSpace Microsoft.Network -FeatureName AllowVnetPeering As a result, you should see the status " Registered ":
If you have not yet registered and have not used the public preview of the network-related functions, then you will also need to register the network functions provider itself:
Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Network Configure VNET peering
When configuring VNET peering, it is important to understand that this connection needs to be configured on both sides (this is especially true for setting up peering between subscriptions). We need a VNET object for which we want to configure the connection and the VNET id with which we want to associate it.
An example of setting up peering between two networks in one subscription:
$vnet1 = Get-AzureRmVirtualNetwork -ResourceGroupName TestResourceGroup -Name TestFirstVnet $vnet2 = Get-AzureRmVirtualNetwork -ResourceGroupName TestResourceGroup -Name TestSecondVnet Add-AzureRmVirtualNetworkPeering -Name LinkToSecondVnet -VirtualNetwork $vnet1 -RemoteVirtualNetworkId $vnet2.Id Add-AzureRmVirtualNetworkPeering -Name LinkToFirstVnet -VirtualNetwork $vnet2 -RemoteVirtualNetworkId $vnet1.Id ')
If you look at the properties of these links with:
Get-AzureRmVirtualNetworkPeering -ResourceGroupName TestResourceGroup -VirtualNetwork TestFirstVnet Then you will notice that you have some pretty interesting properties that you can, either set when creating a connection, or change later:
AllowVirtualNetworkAccess
Determines whether the address space of the remote VNET is included in the Virtual_network tag.
AllowForwardedTraffic
Defines the behavior (accept / reject) in relation to traffic coming through this connection, but not directly from the remote VNET.
AllowGatewayTransit
Allows the remote network to use the gateway on your network.
UseRemoteGateways
Allows you to use Gateway on a remote network. AllowGatewayTransit must be enabled on the remote network. Your network should not have its own gateway.
As you can see, the July update made available a new and very interesting tool for organizing virtual networks in the Microsoft Azure cloud.
Source: https://habr.com/ru/post/307142/
All Articles