Azure-cli: [Network] LoadBalancer inbound NAT rule CLI/portal discrepancies

Created on 26 May 2017  路  10Comments  路  Source: Azure/azure-cli

  • [ ] The portal allows you to select a service from a dropdown to immediately populate the protocol and
    frontend-port fields. This seems like a pure convenience.
  • [ ] The portal allows you to select the target backendIpConfiguration (target VM) but the CLI does not.
  • [x] The portal allows you to use "default" port mapping, which basically means the the backend-port is the same as the frontend-port.
Compute Network

Most helpful comment

2 cents here for getting the command signature closer to people's mental model

  1. For az network lb inbound-nat-rule create command, suggest expose --vm or --backend-ip-configuration argument, so executing one command will set up all. Currently, having to run az network nic ip-config inbound-nat-rule add to get the backend ip configuration plugged in is rather hard for people to figure out. I guess --vm would be used more often, --backend-ip-configuration will only be useful when the VM has more nics or more than one ip-config per nic, which would be rare under the scale-out context
  2. At high level, suggest stronger support for adding a VM/AV-Set into a LB, say az network lb add-vm, which should eliminate more boiler-plate scripts including adding VMs to the BE pool.

So yes, I agree with the initiatives mentioned early

Note that currently, to hook up the rule to the VM, you would need to do the following:

network lb create ...
network lb inbound-nat-rule create ...
network nic ip-config inbound-nat-rule add ...
It's very unintuitive.

All 10 comments

Note that currently, to hook up the rule to the VM, you would need to do the following:

network lb create ...
network lb inbound-nat-rule create ...
network nic ip-config inbound-nat-rule add ...

It's very unintuitive.

@tjprescott When you are saying
network nic ip-config inbound-nat-rule add ...
I've tried with this kind of command:
az network nic ip-config inbound-nat-rule add --inbound-nat-rule RULE_NAME --lb-name LB_NAME --ip-config-name ipConfigNode --resource-group GROUP_NAME --nic-name NIC_NAME
I'm getting this kind of error:
Resource /subscriptions/S/resourceGroups/G/providers/Microsoft.Network/loadBalancers/LB/inboundNatRules/R referenced by resource /subscriptions/S/resourceGroups/G/providers/Microsoft.Network/networkInterfaces/NIC was not found. Please make sure that the referenced resource exists, and that both resources are in the same region.

They are in the same region... Also, when asking details about my inbound-rule, I'm getting backendIpConfiguration: null.
I have to set the backend configuration through the Azure portal... What am I missing!? :)

Az Cli version: 2.0.12+dev

Got it!

I've changed the --inbound-nat-rule NAME by --inbound-nat-rule ID

But, it is not quite clear in the docs provided here: https://docs.microsoft.com/en-us/cli/azure/network/nic/ip-config/inbound-nat-rule#add

It says, _The name or ID of an existing inbound NAT rule._

2 cents here for getting the command signature closer to people's mental model

  1. For az network lb inbound-nat-rule create command, suggest expose --vm or --backend-ip-configuration argument, so executing one command will set up all. Currently, having to run az network nic ip-config inbound-nat-rule add to get the backend ip configuration plugged in is rather hard for people to figure out. I guess --vm would be used more often, --backend-ip-configuration will only be useful when the VM has more nics or more than one ip-config per nic, which would be rare under the scale-out context
  2. At high level, suggest stronger support for adding a VM/AV-Set into a LB, say az network lb add-vm, which should eliminate more boiler-plate scripts including adding VMs to the BE pool.

So yes, I agree with the initiatives mentioned early

Note that currently, to hook up the rule to the VM, you would need to do the following:

network lb create ...
network lb inbound-nat-rule create ...
network nic ip-config inbound-nat-rule add ...
It's very unintuitive.

Once the knack stuff is done (pray it is soon!) I would like to continue this project.

@christiankuhtz, please check out this item and input here any other suggestions you have.
I shall work on it this week.

@yugangw-msft thank you. reading ;-)

This would be a really nice feature if added. Spent a couple hours figuring this out today as it's not intuitive to have the TARGET available in portal but not in the CLI.
Wrote this shell script to handle this in our automation.
resrouce_group="yourResourceGroupName"
loadbalancer_name="YourLBname"
natrule_name="yourNATruleName"
nic_name="yourNICname"
ipconfig_name="this part was trickier since I didn't know where to find this. I ended up using this.
ipconfig_name=$(echo $nic_name | sed -e 's/VNIC/IIP/g')

az network lb inbound-nat-rule create -g $resrouce_group --lb-name $loadbalancer_name -n $natrule_name --protocol Tcp --frontend-port 80 --backend-port 8080

az network nic ip-config inbound-nat-rule add -g $resrouce_group --nic-name $nic_name --inbound-nat-rule $natrule_name --lb-name $loadbalancer_name --ip-config-name $ipconfig_name

Due to the perceived amount of engineering effort needed to simplify these scenarios balanced against the lack of customer asks in this area, we have decided to not pursue these changes.

Does the load balancer and the virtual machine have to be in the same resource group?

Was this page helpful?
0 / 5 - 0 ratings