Azure Loadbalancer Fundamentals, How to use NSGs with Azure Classic Loadbalancer?(2/3)
This blog is a continuation of my first article here:
Lets dive into some more Loadbalancer fundamental concepts.
1. What are the two main SKU options in Classic LoadBalancer /Differences between ‘Basic’ and ‘Standard’ SKU of the Classic Loadbalancer?
Basic:
-Backend pool size is restricted to only 300 instances
-Backend pool restricted to a single availability set (cannot proceed without availability sets either)
-Backend pool VMs CANNOT span Availability Zones
-No SLA
-Free of cost
-Frontend cannot be zone-redundant
Standard:
-Backend pool size can scale out to 1000 instances
-Backend pool can span any virtual machine in a single virtual network, including blends of scale sets, availability sets, and machines
-Backend pool VMs CAN span Availability Zones
-Offers 99.99% SLA
-The Standard tier load balancer is a paid-for feature using a complex set of consumption-based charges
-Offers Zone-redundant and Zonal frontends for inbound and outbound traffic
Detailed list of differences can be noted in the table below:
2. What are the 2 ways of Configuring the Backend Pool/attaching VMs to the Pool?
There are two ways of configuring(attaching VMs to) a backend pool:
i. Network Interface Card (NIC)
ii. IP address and Virtual Network (VNET) Resource ID
i.Network Interface Card (NIC)
Configure your backend pool by NIC when using existing virtual machines and virtual machine scale sets. This method builds the most direct link between your resource and the backend pool.
You can only attach virtual machines in Azure region that have a standard SKU public IP configuration or no public IP configuration. All IP configurations must be on the same virtual network.
ii.IP Addresses
When preallocating your backend pool with an IP address range which you plan to later create virtual machines and virtual machine scale sets, configure your backend pool by IP address and VNET ID combination. (though already created VMs can also be added in this manner)
You can only add resources’ IP address in the Virtual Network. The configuration is associated with the IP address and will apply to any resource which has this IP address assigned.
3. (Loadbalancer’s backend pool) Can the same VM belong to 2 Loadbalancer Pools?
A VM can belong to one Internal LB’s backend pool and one External LB’s backend pool ;but not to 2 pools of same LB.
4. Do Health Probes need any NSG rules to work/are there any default rules created by Azure in each NSG to handle Health Probe Traffic?
You might wonder what’s the meaning of this default NSG rule- AllowAzureLoadBalancerInBound?
Basically this rule means allow “Azure Load Balancer Health Probe”.
When an Azure Load Balancer get created, it will probe backend to detect if the backend service is healthy or not, the probe packet is sent from source address “AzureLoadBalancer” .The IP address of “AzureLoadBalancer” is always 168.63.129.16.
So, probes from LB are being allowed inbound into backend VM by a default inbound rule.
No special NSG rules are neeeded to be created for allowing Health Probe traffic unless default rules are overridden with custom rules.
Now we jump into NSGs for actual incoming traffic from Internet Clients :
5. LB traffic flow and NSG application:
i. The Client on Internet initiates HTTPS traffic to destination of Loadbalancer Frontend, NOT the destination of backend pool VM IP(Private IP).
Source IP is Client’s Public IP and source port is random high port.
Target port is 443(HTTPS).
ii. The Loadbalancer changes 2 things, DST IP and DST PORT.
The Loadbalancer rule defines which port to listen on for incoming traffic and which port to send traffic to (towards backend VMs).
Destination IP is modified to one of the backend pool VM’s Private IP Addresses.(Unless Floating IP concept used).
Destination port is changed from 443 to 80 as per a sample loadbalancer rule,for this example.
Loadbalancer DOES NOT change source IP address or source port.
iii. The backend VMs see the traffic initiating from the Client NOT the Loadbalancer.
Ie src ip/port=IP/port of ‘client’ NOT the ‘loadbalancer’
It must, however, be noted that the Loadbalancer has already modified the DST IP(=backend VM private IP) and DST PORT(port that backend VM listens on,as defined in LB Rule) in the packet as defined above.
This is the most important point and forms the basis for NSG rule creation on backend VMs(NIC or Subnet level). The above talks about source IP,source port,destination IP and destination port ,the 4 vital components in a NSG rule.
iv. For reply traffic, source IP is VM’s private IP , source port is 80 ,destination IP is the internet client(NOT Loadbalancer) and destination port is the internet client’s port which was randomly selected initially(same port maintained for reply traffic).
v. Azure would route this traffic via the Loadbalancer.
vi. Since the source is a private IP which is non routable on internet(packets must contain Public IPs not Private IPs), the Loadbalancer does a NATting of source IP from backend VM IP to its own frontend IP(Public) for communication to happen.
Eventhough ‘source’ is not actually being routed as such(and ‘destination’ is already public IP) ,packet cannot contain Private IP address as source to be routed over Internet.
vii. It must also be noted that the source port is also changed to match the target port where client initially sent the request.
This was a bit lengthy explanation but is absolutely necessary to define the NSG at the VM NIC/Subnet level (Especially recall the fact that the Loadbalancer changes DST IP and DST Port on the packet received from Internet Client).
It is advised to click and expand the below images to digest the details:
Do note that I have restricted the target IP in the NSG Rule,instead of allowing entire subnet.
VMs can belong to same subnet and hence make use of single NSG attached to the subnet level.
Getting lengthy for this post, catch you in the next one for a few more remaining concepts!
