IBGP neighbors not coming up

BGP sessions not formed

IBGP neighbors stuck in active/idle state

Check for IP reachability between the BGP neighbors using ping command. If ping fails, configure IGP in the network for IBGP reachability or configure static route.

If IP reachability is there, check for the BGP configuration on both sides. Ensure that the AS numbers on both sides (peers) and the local AS / remote AS are same for IBGP. Use “show run bgp” to verify the configuration.

 

Verify that the bgp router ids are different on both sides using “show run bgp” or show ip bgp Summary” command.

 

If the IBGP peering is over any address family other than IPV4/unicast, explicit neighbor activation need to be configured for that address-family.

Eg:- neighbor < peer address> activate (for address-families other than default/ipv4 unicast)

 

If configurations are correct, check for tcp connection status using “netstat –tpln “command at shell prompt. If tcp connections are not in CONNECTED State, check whether the BGP neighborship is configured over loopback interface or normal/physical interface.

 

If the neighborship/peering is over loopback interface on both sides, then explicit “neighbor <peer loopback address> update source loopback” need to be configured on both peers. If loopback interface is used only on one side (peer), the above configuration need to be applied on the other side (peer).

 

If bgp md5 authentication is enabled, ensure that the passwords match on both sides. Verify that “debug ip bgp “does not throw any message like “No md5 digest ****“ or “Invalid md5 digest “.

EBGP neighbors not coming up

EBGP sessions not formed

EBGP neighbors stuck in Active/idle state

Check for IP reachability between the BGP neighbors using ping command. If ping fails, verify IP address config and configure static route if the ebgp peers are not directly connected.

 

Verify the EBGP config is correct using the “show run bgp” command. For EBGP the AS numbers are different on both side and the local AS/remote AS should be reverse on both peers.

 

Verify that the bgp router ids are different on both sides, using “show run bgp” or show ip bgp Summary” command.

 

If the EBGP peering is over any address family other than IPV4/unicast, explicit neighbor activation need to be configured for that address-family.

Eg:- neighbor < peer address> activate (for address-families other than default/ipv4 unicast).

 

If configurations are proper, check for tcp connection status using “netstat –tpln” command at shell prompt. If tcp connections are not in CONNECTED State, check whether the BGP neighborship is configured over loopback interface or normal/physical interface.

 

If the neighborship/peering is over loopback interface on both sides then explicit “neighbor <peer loopback address> update source loopback” need to be configured on both peers. If loopback interface is used only on one side (peer), the above config need to be applied on the other side (peer).

 

If EBGP neighbors are not directly connected, configure the bgp multihop config with appropriate ttl value. The “ttl“ value should be greater than or equal to number of hops, the bgp peer is away.

Eg: neighbor < peer address> ebgp-multihop <ttl value>.

 

If bgp md5 authentication is enabled, ensure that the passwords match on both sides. Verify that “debug ip bgp “does not throw any message like “No md5 digest ****“ or “Invalid md5 digest “.

EBGP session should come up and verify the EBGP neighbors are in Established state using the command “Show ip bgp summary” or “show ip bgp neighbors”.

BGP peering flaps

BGP session flaps

BGP establishes and drops

Check for the BGP peer flap cause/reason from the notification field in “show ip bgp neighbor < peer address>.

If the reason is “Hold timer expiry” then keepalives are not received/ processed.

If keepalives are not received, check the peer router “show ip bgp summary” and verify that the sent msg field is getting incremented.

 

If Keepalives are received but not processed then keepalives are getting stuck behind the Update messages. In other words the update messages are taking longer time to process or the system is configured beyond the claimed BGP limits.The keepalives getting queued can be verified from the “show ip bgp summary” output In Q/OutQ field.If the system is configured with in the scalability limits, please call up support team for help.

 

If the reason is “Administer configured” then the administrator has modified the fields which could trigger BGP session reset. Eg:- BGP Graceful restart configuration.If the flapping is continuous, check for interface flap, bad connectors and bgp process unstable at other end and traffic and rate limiting parameters. Check for interoperability issues too.

 

If the reason is “Malformed packet” then BGP has received a invalid packet from the peer. This is mostly caused by oversized BGP packet as BGP TLVs are variable length. Please call up the support team for help.

 

If none of these, then the issue could be PATH MTU related.Try pinging the peer with various size packet like above 1500 bytes etc. Normal ping succeeds but extended ping fails.Trouble shooting the path MTU issues is beyond the scope of this document.Please call up the support team.

Missing routes

Routes not seen in BGP table

Irregular network connectivity

For IBGP peers, the topology should be fully meshed if no Route Reflectors are configured. If Route Reflectors are used, ensure IBGP is established between all iBGP peer and the RRs and between the RRs.

If confederations are configured to avoid IBGP mesh, ensure that the confederation configuration is proper.

 

Route origination issues - If BGP is not originating the route and If the route is injected via “network prefix” command, Verify that the exact match (not best match) for the route exists in the RIB (IP RIB) using the “show ip route | include prefix “. If exact match does not exist, add a static route for the exact prefix and verify the static route is active in the RIB. BGP should originate the route now.

 

Aggregate route origination issue - If route aggregation is configured and aggregate route is missing in BGP table (“Show ip bgp”) but available in IP RIB (“show ip route”), then the configuration is not complete. For route aggregation, route needs to be there in BGP table.Add the aggregated route in BGP via the “network <aggregate prefix/mask>. Now the aggregated route can be seen in the “Show ip bgp” command also.

 

Originator/cluster id collisions - If Router reflectors are used and topology is proper, still routes not populated. The problem could be clashing cluster ids and router/originator ids. To debug this issue, check for the BGP table from the originator of the route using “show ip bgp “

Check whether the route is advertised to the peer using the “show ip bgp neighbor <peer address> advertised-routes” command.

Check whether the route is received at the peer using the “show ip bgp neighbor <peer address>“ at the peer router.

If route is not received, check for the access-list configured on the peer router.

If access list are also permitting the route, enable bgp debugs and clear the bgp session using “clear ip bgp <peer-address> out “and figure out the reason for the denial of the route.

If the reason for route ignore/drop is “originator id same as router id” Change the router ids in one of the router.

If the reason for route ignore/drop is “reflected from same cluster” then the All RRs are not peered with each other. Ensure ibgp peering between all RRs.

 

Filtering issues - If Routes are not seen with proper configuration, look for the filters/route-maps configured at the inbound and outbound of each peer. Verify that there are no typos in the filters or in the expressions used for filtering.Verify that access-list configured are for exact match.

 

Community config/mismatch issues – verify the configuration has “neighbor <peer address> send community“ to advertise the community strings. Ensure that the community match strings configured via route-map are matching/correct/proper.

 

IBGP meshing issues – Routes are marked as valid and internal but not marked as the best in the “show ip bgp” output. The nexthop for the route (mostly ebgp route) is not reachable and hence not advertised to peer. Configure static route or IGP for nexthop reachability.Another reason for missing route in an IBGP network is that not fully meshed. Ensure that IBGP is fully meshed or use RR + peer group config for ease of maintenance

High CPU utilization

In case of recursive BGP routes, ie where BGP nexthop is also learned via BGP, recursive look up may end up in invalid/illegal. IT is advisable to learn the BGP Nexthop via IGP also.

Route flapping could be one cause for High CPU utilization.

Routing loops caused by lack of IBGP meshing. Use RR or ensure IBGP full meshing.