When configuring the Border Gateway Protocol (BGP) Router, you may encounter issues where dynamic routing doesn’t work as expected due to configuration problems. This article provides a handy set of troubleshooting commands to address these issues effectively.
Check the Following
If BGP is not working correctly, the following points should be looked at more closely.
- Active Route to the Remote Peer: Ensure there is an active route available to the BGP neighbor.
- TCP Port 179: Verify whether TCP port 179, which is crucial for BGP operations, is open and not blocked by any firewalls.
- TCP Session Status: Investigate the status of the TCP session to confirm that the underlying transport layer is stable.
- BGP Session Status: Check the current status of the BGP session to understand if there are any session-related issues.
- Examine Received and Advertised Prefixes: Review the prefixes that are being received from and advertised to the BGP peer, to ensure correct network advertisements.
Essential Steps for Troubleshooting
Real-Time Debug
Real-time debugging is invaluable for observing how BGP messages are processed. To activate real-time debugging in a FortiGate environment, use the following commands:
FGT01# diagnose debug reset
FGT01# diagnose ip router bgp all enable
FGT01# diagnose ip router bgp level info
FGT01# diagnose debug enable
No Active Route Scenario
If no active route to the BGP neighbor exists, the real-time debug will typically show:
BGP: 10.10.10.11-Outgoing [FSM] State: Idle Event: 3
BGP: 10.10.10.11-Outgoing [NETWORK] FD=26, Sock Status: 113-No route to host
BGP: 10.10.10.11-Outgoing [FSM] State: Connect Event: 18
In most cases, it is recommendable, to add a static route to the BGP neighbor IP address. By configuring a static route, you ensure the communication to the neighbor even if the dynamic routing is completely offline.
BGP TCP Session and States
To perform a more detailed troubleshooting, you can obtain an overview of the BGP neighbor states by executing the following command, which provides a comprehensive view of each neighbor’s status:
If a number appears instead of “State”, it indicates that the BGP connection is established and it shows the number of prefixes received from the BGP neighbor. Here is an example of a possible output:
FGT01# get router info bgp summary
VRF 0 BGP router identifier 172.17.100.1, local AS number 3500
BGP table version is 4
5 BGP AS-PATH entries
0 BGP community entries
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.10.10 4 4000 98051 98057 4 0 0 4d20h36m 12
10.10.10.11 4 3000 0 0 4 0 0 0d0h0m Idle
Total number of neighbors 2
BGP States Explained
- Idle: Initial state
- Connect: Waiting for a successful three-way TCP connection
- Active: Unable to establish the TCP session
- OpenSent: Waiting for an OPEN message from the peer
- OpenConfirm: Waiting for the keepalive message from the peer
- Established: Peers have successfully exchanged OPEN and keepalive messages
To find out the number of prefixes that have been accepted by a particular BGP neighbor, the command get router info bgp neighbors will be useful. This command also delivers crucial details about the current state of the BGP neighbor, including the count of messages exchanged, and more.
FGT01# get router info bgp neighbors
VRF 0 neighbor table:
BGP neighbor is 10.10.10.10, remote AS 4000, local AS 3500, external link
BGP version 4, remote router ID 172.16.100.1
BGP state = Established, up for 4d20h37m
Last read 00:00:03, hold time is 15, keepalive interval is 5 seconds
Configured hold time is 15, keepalive interval is 5 seconds
Neighbor capabilities:
Route refresh: advertised and received (old and new)
Address family IPv4 Unicast: advertised and received
Address family VPNv4 Unicast: advertised and received
Address family IPv6 Unicast: advertised and received
Address family VPNv6 Unicast: advertised
Address family L2VPN EVPN: advertised
Received 98065 messages, 1 notifications, 0 in queue
Sent 98069 messages, 2 notifications, 0 in queue
Route refresh request: received 0, sent 0
NLRI treated as withdraw: 0
Minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP table version 4, neighbor version 4
Index 1, Offset 0, Mask 0x2
Inbound soft reconfiguration allowed
Community attribute sent to this neighbor (both)
12 accepted prefixes, 12 prefixes in rib
14 announced prefixes
Restart BGP
To force a full exchange of BGP routing tables between peers:
FGT01# execute router clear bgp ip <IP address of neighbor>
It’s also possible to perform a soft reset (without interruptions) by using the following command:
FGT01# execute router clear bgp all soft (in/out)
FGT01# execute router clear bgp ip <IP address of neighbor> soft (in/out)
- in: refresh only received BGP routes.
- out: refresh only advertised BGP routes.
Checking Received and Advertised Prefixes
To check if prefixes from a BGP neighbor have been received or to view those advertised to other BGP neighbors, use the following commands:
FGT01# get router info bgp neighbors <IP address of neighbor> received-routes
FGT01# get router info bgp neighbors <IP address of neighbor> advertised-routes
MultiHop
It is possible that the following error message is displayed in the real-time debug:
BGP: 10.10.10.11-Outgoing [RIB] Update: Prefix 192.168.10.0/24 path_id 0 denied due to non-connected next-hop
Typically, the TTL for an eBGP session is configured with a value of 1, requiring the neighboring router to be directly connected. To bypass this constraint, the ebgp-enforce-multihop option allows connectivity between neighbors that are not directly connected. A typical application of this setup is for load balancing across multiple links between two routers. Additionally, due to recursive lookup, if multiple equal-cost IGP paths to the BGP next hop exist, load sharing towards a BGP destination is automatically enabled. MultiHop is enabled as follows:
config router bgp
config neighbor
edit "10.10.10.10"
set ebgp-enforce-multihop enable
next
end
end
