Load Balancer Degraded for 3 days

Rafael Aguilar 0 Reputation points
2026-04-20T12:25:05.1733333+00:00

Hi,

My Azure load balancer is in degraded status for 3 days. The insights shows that connection to backends are not connecting with the vip but the VMs are using the same vnet and subnet as the LB. I can connect to the VMs directly using the port that is configured in the rules section.

Azure Load Balancer
Azure Load Balancer

An Azure service that delivers high availability and network performance to applications.

0 comments

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-04-20T12:25:33.7833333+00:00

    For a Standard Load Balancer that has been in Degraded state for several days and where VMs are reachable directly but not via the VIP, focus on data path and health probe validation.

    Use these steps end to end:

    1. Verify resource health and scope of impact
      • In the Azure portal, go to Monitor > Service health > Resource health.
      • Filter by Resource type = load balancer and select the affected load balancer.
      • Confirm the status is Degraded (Data Path Availability < 90% and > 25% for at least two minutes) and check the timeline to see when it started and whether it is continuous or intermittent.
      • If Data Path Availability is close to 0% for long periods, treat it similar to an unavailable data path and continue with the next steps.
    2. Use Load Balancer insights to pinpoint the issue
      • Open the load balancer in the portal and go to the Insights / Metrics view.
      • On the Frontend and backend availability tab, review at least a 30‑minute window that falls within the degraded period.
      • Confirm whether Data Path Availability drops correlate with specific time ranges or are constant.
      • Check Health Probe Status for each backend pool and rule:
        • If Health Probe Status shows no healthy backend instances for the affected rule(s), the problem is likely configuration (NSG, UDR, firewall, probe port/app).
        • If at least one backend instance is healthy for all rules but Data Path Availability is still degraded, this points more toward a platform issue.
    3. Validate health probe reachability from the Load Balancer For the rule(s) that are failing:
      • Confirm the probe configuration (protocol, port, path if HTTP) matches what the backend VM is actually listening on.
      • On one backend VM:
        1. Ensure the application/service is listening on the probe port.
        2. Ensure the OS firewall allows the probe port.
      • From another VM in the same VNet, run a connectivity test to the backend VM’s probe port (for example, using PsPing as recommended):
        • ps ping <backend-VM-IP>:<probe-port>
      • If PsPing fails, collect simultaneous Netsh traces on both the backend VM and the test VM and analyze:
        • If no incoming packets arrive at the backend VM on the probe port, suspect NSG or UDR misconfiguration blocking or redirecting traffic.
        • If incoming but no outgoing packets are seen from the backend VM, suspect local firewall or application issues blocking responses.
    4. Check NSGs, UDRs, and Azure Firewall
      • Ensure NSGs on the subnet and NIC explicitly allow:
        • Inbound probe traffic from the Load Balancer (probe port and rule port).
        • Inbound client traffic to the rule port from expected source IP ranges.
      • If using user-defined routes (UDRs) or Azure Firewall:
        • Verify that probe and data-path traffic from the Load Balancer to the backend VMs is not being forced to another destination before reaching the backend (for example, via a route to a firewall or NVA that drops it).
        • Adjust routes or firewall rules so that Load Balancer probe and data-path traffic can reach the backend VMs directly or is explicitly allowed through the firewall.
    5. Test with an alternate probe type
      • Temporarily change the probe type (for example, from HTTP to TCP) and:
        • Update NSG and firewall rules to allow the new probe port.
        • Confirm whether the backend instances become healthy with the simpler TCP probe.
      • If TCP probes succeed but HTTP probes fail, the issue is likely with the HTTP endpoint configuration or application behavior.
    6. Distinguish configuration vs platform issue
      • If, after fixing NSGs/UDRs/firewall and validating probe reachability, Health Probe Status shows at least one healthy backend for each rule but Data Path Availability remains degraded for the same period, this indicates a potential Azure platform problem.
      • In that case:
        • Capture screenshots/metrics from Load Balancer insights (Data Path Availability and Health Probe Status).
        • Open an Azure support ticket and include:
          • Load balancer resource ID
          • Time range of degradation
          • Confirmation that backend instances are healthy and probes succeed from within the VNet
          • Any Netsh trace evidence showing correct probe/data-path behavior.
    7. If the load balancer ever shows as Unavailable
      • If Data Path Availability drops below 25% (status Unavailable) and there are healthy backends, this is explicitly called out as a likely Azure platform issue; rely on resource health and support to track and resolve.

    Following these steps will isolate whether the 3‑day degraded state is due to NSG/UDR/firewall/probe configuration or an underlying platform issue that requires Microsoft support.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Ravi Varma Mudduluru 12,625 Reputation points Microsoft External Staff Moderator
    2026-04-20T13:31:44.1933333+00:00

    Hello @ Rafael Aguilar,

    Thank you for reaching out to Microsoft Q&A.

    I understand that your load balancer is staying in a Degraded state because none of your backend VMs are passing health probes on the VIP even though you can hit the VMs directly on the same port.

    The most common reason for this exact scenario (backends not reachable via the VIP, same VNet/subnet, but data port connects directly) is that the health probes are failing. Probes use a separate path (from Azure’s infrastructure IP 168.63.129.16) and a probe-specific port/protocol/path they’re independent of your load-balancing rule.

    Here’s the quickest way to fix it:

    1. Open the health probe attached to your rule and note the exact probe port, protocol, and path (if HTTP/HTTPS).
    2. On each backend VM, confirm the application is actually listening on that probe port (netstat/ss on Linux, or check services).
    3. Check the NSG on the subnet or VM NIC — make sure there’s an Allow rule (priority ~100) for source AzureLoadBalancer service tag to your probe port. Any higher-priority Deny rule will block the probe.
    4. Also verify the VM’s guest firewall (Windows Firewall or iptables/firewalld) allows inbound traffic from 168.63.129.16 on the probe port.

    Once probes start succeeding, the LB status should flip back to Available within a couple of minutes.

    Reference docs:

    • https://learn.microsoft.com/en-us/troubleshoot/azure/load-balancer/load-balancer-troubleshoot-health-probe-status

    • https://learn.microsoft.com/en-us/troubleshoot/azure/load-balancer/troubleshoot-rhc

    • https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-custom-probe-overview

    If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.