BGP routing protocol suddenly stopped working.

Ochoa, Antonio 0 Reputation points
2026-08-25T17:52:07.9733333+00:00

BGP routing protocol suddenly stopped working. We configured 2 IPSec tunnels between Azure and On premise FTDs, to share routing information enabled BGP, everything was working good until last Saturday(Aug/22/2026). Are you aware of any changes in Azure that could be triggering this issue?. In summary, the IPSec Tunnel is UP but the BGP is no working. I enabled a packet capture in the On premise FTD and found the FTD is sending BGP packets to Azure but Azure is not responding, there were no changes on the On premise Network (Cisco FTD) neither the Azure environment, it just suddenly failed. What could be the root cause ?

Azure Virtual Network
Azure Virtual Network

An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.

0 comments No comments

1 answer

Sort by: Most helpful
  1. AI answer

    2026-08-25T17:52:29.4466667+00:00

    The most likely root cause is a BGP session failure on top of an otherwise healthy IPsec tunnel, caused by configuration mismatch, peer IP/ASN issues, APIPA configuration issues, or route advertisement problems rather than a general Azure platform change.

    Use this troubleshooting path:

    1. Verify the IPsec tunnel is truly healthy
      • In Azure portal, open the Connection resource and confirm Status = Connected.
      • BGP runs over the IPsec tunnel. If the tunnel drops intermittently, BGP will also fail.
    2. Check current BGP peer state in Azure
      • In Azure portal, go to Virtual network gateway > Monitoring > BGP peers.
      • Review State, messages sent/received, and route counts.
      • A healthy peer shows State: Connected.
      • For more detail, run:
             Get-AzVirtualNetworkGatewayBgpPeerStatus -ResourceGroupName <resource-group> -VirtualNetworkGatewayName <gateway-name>
        
    3. Revalidate the core prerequisites even if nothing was intentionally changed
      • Gateway SKU must not be Basic.
      • VPN type must be Route-based.
      • Azure VPN gateway ASN and on-prem ASN must be different.
      • Do not use reserved ASNs.
      • The on-prem BGP peer IP must not be the same as the VPN device public IP.
      • The local network gateway must contain the correct BGP peer IP.
      • A common mistake is peering the on-prem device to the gateway public IP instead of the Azure BGP peer IP from the GatewaySubnet.
    4. Check APIPA usage if the Cisco FTD uses 169.254.x.x for BGP
      • Azure VPN Gateway requires matching APIPA BGP IP addresses when APIPA is used.
      • The supported APIPA range for VPN Gateway is 169.254.21.0 - 169.254.22.255.
      • If the peer uses APIPA outside that range, BGP will not establish correctly.
    5. Check whether Azure is learning or dropping routes
      • In Virtual network gateway > Monitoring > BGP peers, review Routes received.
      • If the session is up but route count is 0, Azure is not learning routes from the on-prem peer.
      • Run:
             Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName <resource-group> -VirtualNetworkGatewayName <gateway-name>
        
      • Routes with Origin: EBgp are from the on-prem peer.
    6. Verify the on-prem device is advertising valid routes Check the Cisco FTD or upstream router for:
      • BGP enabled on the correct interface
      • Intended prefixes included in network statements or route table
      • No outbound route filters blocking prefixes
    7. Check for prefix-limit drops
      • Azure VPN Gateway supports up to 4,000 prefixes per BGP peer.
      • If the on-prem device advertises more than 4,000 prefixes, Azure drops the BGP session entirely.
      • This can look like “tunnel up, BGP stopped.”
      • Query diagnostic logs for disconnect events:
             AzureDiagnostics
             | where Category == "RouteDiagnosticLog"
             | where OperationName == "BgpDisconnectedEvent"
             | project TimeGenerated, Message, Resource
             | order by TimeGenerated desc
        
    8. Correlate BGP failure with tunnel or IKE events Use these diagnostics:
      • RouteDiagnosticLog for BgpRouteUpdate, BgpConnectedEvent, BgpDisconnectedEvent
      • IKEDiagnosticLog for IKE control-plane issues
      • TunnelDiagnosticLog for tunnel state changes
    9. Set or review monitoring for recurrence
      • In Virtual network gateway > Alerts > Create alert rule
      • Use BGP Peer Status metric with condition less than 1
      • Use BGP Routes Learned to detect sudden route-count changes

    If the tunnel is connected, Azure shows the peer as not connected or unknown, and the FTD is sending BGP packets with no response, the highest-probability causes from the documented checks are:

    • wrong BGP peer IP configured on either side
    • ASN mismatch or reserved ASN use
    • APIPA misconfiguration
    • local network gateway BGP peer IP mismatch
    • Azure dropping the session because more than 4,000 prefixes are being advertised
    • underlying tunnel/IKE instability visible in diagnostic logs

    If these checks do not identify the issue, submit an Azure support request and include the exact time the failure started, BGP peer status output, learned-route output, and Route/IKE/Tunnel diagnostic log events around the outage.


    References:

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

    Was this answer helpful?

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.