BGP Troubleshooting

From CT3

Jump to: navigation, search

Contents

The route is received but not present in the BGP table

AS_PATH includes the local AS

If a route advertised by an external (eBGP) neighbor includes the local AS in its AS_PATH attribute, the route will be rejected. This is a loop prevention mechanism used by BGP, and it is a fundamental concept of the protocol. However, there may be instances when you want to bend this rule and allow such routes anyway. This can be accomplished by appending the allowas-in keyword to a neighbor statement:

Router(config-router)# neighbor 1.2.3.4 allowas-in

As this configuration results in somewhat abnormal BGP behavior, exercise caution to avoid creating routing loops.

Rejection by inbound policy

Routes may be being unintentionally blocked by an inbound route-map applied to the BGP neighbor. This can be inspected by comparing the output of two variations of the show ip bgp neighbor command:

Router# show ip bgp nei 172.16.0.2 received-routes
BGP table version is 6, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  192.168.2.0      172.16.0.2             100             0 65200 ?
*  192.168.3.0      172.16.0.2             100             0 65200 ?

Total number of prefixes 2

The first command displays all routes being advertised by the specified neighbor. Note that inbound soft-reconfiguration must be enabled for the neighbor in order for this command to produce any useful output.

Router# show ip bgp nei 172.16.0.2 routes
BGP table version is 6, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  192.168.3.0      172.16.0.2             100             0 65200 ?

Total number of prefixes 1

This second command lists all routes from the neighbor which have been entered into the routing table. The above output reveals that only one of the advertised routes (192.168.3.0/24) is being allowed through the inbound routing policy for this neighbor. When this happens, double-check the route-map applied inbound.

The route is in the BGP table but has not been selected

A better route exists

NEXT_HOP is inaccessible

If the router doesn't know how to reach a route's next hop, a recursive lookup will fail, and the route can't be added to BGP. For example, if a BGP router receives a route for 10.0.0.0/8 with a NEXT_HOP attribute of 192.168.0.1, but doesn't have an entry in its routing table for a subnet containing 192.168.0.1, the received route for 10.0.0.0/8 is useless and won't be installed in the routing table.

Synchronization is enabled and the route is not known by an IGP

If synchronization is enabled, BGP requires each route to be known by an IGP before placing it in the routing table. This is considered legacy behavior and isn't typically enforced on modern networks. Synchronization is easily disabled:

Router(config-router)# no synchronization

In fact, synchronization is disabled by default beginning with IOS release 12.2(8)T.

The route has been selected but is not in the routing table

RIB failure

The command show ip bgp rib-failure can explain why a BGP route may not be entered in the RIB.

The route is selected and in the routing table but is not advertised

iBGP split horizon restrictions

iBGP-learned routes will not be propagated to iBGP neighbors unless route reflection or confederations have been configured.

'no-export' or 'no-advertise' set on the route

Personal tools

CT3

Main menu