This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(118.4, 15%, 21%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAS%3C/text%3E%3C/svg%3E)
Does load balancer probes in AKS service, sends any data over TCP connection? Suppose I have created a Load balancer type service and external IP is assigned to service. Then, probing starts. Meanwhile, my application is listening on the service port in pod/container to receive actual traffic and load balancer probing also over TCP connection. How can I distinguish between these two incoming traffic whether it is normal or load balancer health check probe?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(134.4, 59%, 23%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECM%3C/text%3E%3C/svg%3E)
Thank you for reaching out.
I understand you want to know about how to differentiate if the request being sent to the load balancer is a health probe request or actual traffic.
When a TCP health probe is set up on Azure Load Balancer the TCP probes initiate a connection by performing a three-way open TCP handshake with the defined port. TCP probes terminate a connection with a four-way close TCP handshake. There is no payload associated with these probes.
How can I distinguish between these two incoming traffic whether it is normal or load balancer health check probe?
All the health probes are sent with source IP of 168.63.129.16. This way you can distinguish between the health probe and actual traffic. This is currently documented here.
Additional reference:
Hope this helps! Please let me know if you have any additional questions. Thank you!
@ChaitanyaNaykodi-MSFT Thank you for your answer.
In the pod, I am receiving backend pool IPs as client IPs which is trying to connect my application. My application is listening on 0.0.0.0 IP and there I see issue but if my application listen's on pod's IP then this issue is not seen. So the source IP is not 168.63.129.16. It is something else (10.224.0.10, 10.224.0.199) and the backend pool name is Kubernetes.
I just don't know why this weird issue is seen. Is there any way to mitigate this issue?
Thank you for getting back. I have reached to the team internally regarding the issue here. As I get more information regarding the issue above.
The request flow for accessing applications that are hosted on an AKS cluster is as follows
Client >> DNS name >> AKS load balancer IP address >> AKS nodes >> Pods
Depending on the type of node configured, you can perform some packet captures to understand what source and destination IP addresses of the traffic being sent here.
You can also perform a packet capture for the pod
Thanks! Please let me know if you have any additional questions. Thank you!