-1

If we have one VM after the Azure load balancer (external) at first. The TCP connection will be routed to VM1.

--connection1 packet--> Azure Load Balancer (20.20.20.20) --connection1 packet--> VM1

Then we add a new VM after the lb.

--connection1 packet--> Azure Load Balancer (20.20.20.20) ----> VM1 
                                                          --connection1 packet--> VM2

Normally the connection would still be routed to VM1 as there is connection tracking. But this is not guranteed because the Azure load balancer is implemented as a distributed software load balancer as described in this article.

So the packet might be routed to VM2. The expected behaviour is that the packet could get inside VM2 and gets a TCP RST to end this connection. But it turns out the packet would be dropped before it gets inside VM2.

I hope to know why this packet is dropped. Is it because the NAT?

Robin
  • 1
  • 2

1 Answers1

0

I have gone through the article, and I am not sure that I am correctly spotting the reason: The reason may be based on the Traffic Manager routing methods of azure. As in the article, they 've used a weighted random load policy. You can make look at this link for reference to various methods of handling traffic methods.

I am not damn sure, I just replied maybe this could be the reason.