Description
Facts:
- BGP can be used as an Inter or Intra-Autonomous system routing protocol.
- eBGP for Inter, and iBGP for Intra.
- eBGP AD is 20, iBGP AD is 200.
- BGP is a distance vector protocol.
- BGP does not use multicast or broadcast in discovering peers.
- BGP requires to manually define what wanted - this includes neighbor peering.
- BGP is an Application Layer protocol which uses TCP 179 (any of the peers can act as server).
- BGP uses 'path attributes' to select best route to destination.
- BGP peers do not have to be directly connected (but both peers most have reachability to each other, either through static routing or IGP routing protocols).
- BGP's primary function is to exchange NLRI (Network Layer Reachability Information) with another BGP router it is peering with by using updates.
- NLRI is made from 'prefix' and 'length'. Prefix is the Network Address, Length is the Network Mask. NLRI example: /24, 10.0.0, /16, 10.0, /8, 10.
- BGP message types: Open, Keep-alive, Notification & Update.
- BGP states: BGP has 6 states – IDLE, CONNECT, ACTIVE, OPEN SENT, OPEN CONFIRM, ESTABLISHED. These states can be helpful in troubleshooting why BGP peering failed.
Scope
FortiGate v6.2.
FortiGate v6.4.
FortiGate v7.0.
FortiGate v7.2.
Solution
Scenario 1: BGP Peering Issue.
BGP is deployed to exchange NLRI with the other BGP peers.
However, this will not happen until the BGP state is in ESTABLISHED.
Though there are time when the BGP is in ESTABLISHED state and will still NOT send the routes expected to peer(s), this is because other conditions are not fulfilled.
Things to check:
- Ensure the peer is reachable. It is possible to ping the Remote peering IP by sourcing it with the local peering IP to ensure L3 reachability.
- Ensure TCP 179 is not blocked by Firewall somewhere in the middle.
- Ensure the peer is not configured with a wrong IP address.
- Make sure not to configure the wrong IP in the peering config.
- Ensure the AS is correctly configured. If a FortiGate is configured to expect peer from AS 'YY', but it instead keeps getting peering request from AS 'ZZ', it will not peer.
- Ensure the password matches on both ends if one is used.
Scenario 2: Network/Subnet did not make it to the Routing table.
Things to check:
- AS_PATH contains the local AS: BGP will not install subnets which contained its own AS, meaning the route originating from the same AS, or if it has traversed the AS before (i.e. loops).
- Inbound Policy denied the subnet/route: check the inbound Route-Map and ensure it’s not the one blocking the subnet(s).
- NEXT_HOP is not reachable by the BGP router: If the next hop to reach such NLRI is down or not accessible by the BGP router, installing the subnet in the routing table will not fix the problem. Ensure the next hop IP is reachable from the BGP router under troubleshooting, as this may be the reason the route is not making it to the routing table.
- Synchronization is enabled: If synchronization is enabled on the FortiGate and the subnet is not known by an IGP, the route will not be installed in the routing table. It is possible to disable synchronization to resolve this. Additionally, note that on FortiGate, synchronization was disabled by default.
