Support FAQ: How to Troubleshoot BGP on Palo Alto Networks Firewalls

[JayGolf]

Most days, BGP runs quietly in the background. BGP advertises routes that keep your WAN, VPN, cloud environments, and public services connected and reachable. Until it doesn’t. And when BGP breaks, it’s not just a routing issue, it’s unreachable services and frustrated users.

This guide will help you troubleshoot BGP on Palo Alto Networks firewalls, so you can quickly identify the problem and get traffic flowing again.

Understand the Basics: Is It You or Them?

Before diving deep into logs and captures, start by asking:

• Is this a new BGP configuration that never came up, or an existing session that suddenly stopped working?
  
  
• Is the problem BGP-related or does it point to a larger connectivity or firewall policy issue? 

Many BGP issues boil down to basic reachability, misconfigurations, or route filtering errors. Let’s walk through how to systematically rule those out. 

Start with the Transport

Before you jump to BGP configurations, always remember that BGP won't even attempt to negotiate unless the underlying TCP session (port 179) can be established.

If the basic IP reachability or session is broken, BGP will stay silent.

1. Check Interfaces and Zones:
   
   
1. Confirm the interface is physically up, has the correct assigned IP, and is placed in the intended zone.
   
   
2. Ensure the virtual router routing table has the correct next-hop to the peer.

1. Ping the Peer IP (Basic Reachability Check):
   
   

• Verify your firewall can reach the BGP neighbor IP from the correct interface and virtual router.
  
  
• This also validates that the firewall’s routing table has a path to the BGP neighbor.
  
  
  

1. Review Security Policies:
   
   

• Confirm you are explicitly allowing the BGP App-ID (TCP/179) in both directions:
  
  
• From the local zone to the BGP peer’s zone.
  
  
• From the BGP peer’s zone to the local zone.

Always start by verifying Layer 3 and Layer 4 connectivity, before diving into BGP-level config.

Check this helpful KB on learning about BGP Neighbor Adjacency. 

Check BGP Session Status

Once you’ve confirmed the underlying transport is open and reachable, your next move is to see what the BGP session is doing. 

Before jumping into the CLI, you can check the System Logs in the GUI (Monitor -> Logs -> System). These logs can provide early hints about BGP negotiation failures, mismatched parameters, or TCP resets. You can filter the system logs to show events related to routing ( subtype eq routing ). 

Why start with the system logs?

• They can quickly show if the firewall is attempting to open the BGP session.
  
  
• You'll often see useful error messages such as:
  
  
• "BGP peer x.x.x.x, Connection rejected."
  
  
• "BGP peer x.x.x.x, Wrong AS number."
  
  
• "BGP peer x.x.x.x, Hold timer expired."
  
  
• System logs can also confirm if your firewall is sending or receiving BGP connection attempts, or if the session is being actively torn down due to policy or config errors.
  
  

Use the CLI to Confirm the Session State

After reviewing the system logs, you can validate the current BGP session state by entering show routing protocol bgp peer.

This command shows real-time status of your BGP peers. Here’s what the session states mean:

• Idle / Active
  No TCP session established. Go back and double-check transport, routing, peer IP, and security policies.
  
  
• Connect
  TCP handshake is trying but hasn't completed—this still points to possible transport or routing issues.
  
  
• OpenSent / OpenConfirm
  TCP is up and BGP messages are being exchanged, but something is preventing the session from finalizing. Check AS numbers, BGP passwords, and timer mismatches.
  
  
• Established
  Success! The session is up. If routes aren’t flowing as expected, you’ll want to investigate import/export policies or route filters.
  

If the CLI shows your session is stuck in Active or Connect, it’s usually still a basic connectivity or transport issue. Head back to the earlier steps to double-check transport and policy.

Review BGP Configuration (Local and Peer Settings)

If your BGP session is stuck in OpenSent or OpenConfirm, or even if it's Established but routes aren’t flowing, the next step is to double-check your BGP configuration on both sides.

Key items to verify in the PAN Firewall GUI or CLI:

• Local AS Number
  
  
• Confirm the local AS number matches what your peer expects.
  

• On Palo Alto:
  Network > Virtual Routers > <VR> > BGP > General
  
  

• CLI:
  show routing protocol bgp peer <peer-IP>

• Peer IP Address
  

• Ensure the correct peer IP address is configured.
  
• Peer AS Number
  

• The peer AS must match the remote device's local AS.
  
  
• Authentication (if configured)
  
  
• Confirm both sides have the same MD5 password.
  

• A mismatch here will cause the session to hang in OpenSent or get rejected.
  
  

• On Palo Alto:
  Network > Virtual Routers > <VR> > BGP > Peer Group > <peer> > Authentication
  
  

1. BGP Timers
   
   
• Ensure your keepalive and hold timers are aligned with the peer.
  
  
2. Advanced Options
   
   
• If using multi-hop eBGP, confirm that EBGP multihop is enabled. Default is set to 1.
  
  
• Verify address families (IPv4, IPv6) match what the peer supports.
  
  
• Check for any route-reflector, route-server, or additional features that might require matching settings.

Check Route Advertisements and Filters

Once your BGP session is established, confirm that routes are actually being exchanged.

View Advertised and Received Routes:

1. Go to:
   Network > Virtual Routers > [Your VR] > BGP > Peer Group > [Your Peer]
   
   
2. Click on More Runtime Stats.
   
   
3. Under RIB Out, view the routes being advertised.
   
   
4. Under RIB In, view the routes being received.
   
   

View Local Routing Table

1. Go to:
   Network > Virtual Routers > [Your VR]
   
   
2. Click More Runtime Stats.
   
   
3. View the Routing Table tab.
   
   

Review Filters and Policies

• Check if Export Rules (under BGP > Export Rules) are blocking intended prefixes.
  
  
• Review Import Rules (under BGP > Import Rules) to ensure you're not accidentally discarding routes from the peer.
  
  
• Confirm any Redistribution Profiles are properly set up if you're trying to redistribute static, connected, or other routes into BGP.

If you're seeing routes in RIB In, but they're missing from the local routing table, check:

• Administrative distances (BGP may lose to another protocol like static or OSPF).
  
  
• Route filtering policies.
  
  
• Overlapping or conflicting routes.

Wrapping It Up

BGP troubleshooting can feel overwhelming, especially when the symptoms impact critical services across WAN, VPN, and cloud environments. Break it down step by step to make it more manageable:

1. Start with the transport layer.
2. Check the BGP session state.
3. Validate key configurations.
4. Review the routes being exchanged.

For more examples, use cases, and configuration tips, check out the Knowledge Base resource list for BGP Configuration and Troubleshooting.

[DanielPurton]

Hey Jay, 
Under the section "View Advertised and Received Routes" you mention that you can view the RIB in. Its actually the Local RIB(Loc-RIB) table. The RIB in(Adj-RIBs-In) table isn't viewable on the Palo as far as I know.

Adj-RIBs-In: Routing information received and unprocessed
Loc-RIB: Routes installed and used by the firewalls BGP process 
Adj-RIBs-Out: Advertised prefixes to other BGP peers.

If anyone knows how to view the Adj-RIBs-In table on a palo please let me know. You can infer some of the information from the mp-log routed.log file however what you're really looking at there is changes. I've found this to be an issue when I'm told someone is advertising something to you yet its not being learned.