Simple Border Gateway Protocol (BGP) troubleshooting

In BGP troubleshooting, a structured approach can quickly lead you from initial problem diagnosis to the solution. This article focuses on a simple scenario with a single BGP-speaking router in your network.

p>Border Gateway Protocol (BGP) is without doubt the most complex IP routing protocol currently deployed in the Internet. Its complexity is primarily due to its focus on security and routing policies - BGP is used to exchange cooperative information (Internet routes) between otherwise competing entities (service providers) and has to be able to implement whatever has been agreed upon in the inter-provider peering agreements. (These agreements often have little to do with technically optimum solutions.)

However, a structured approach to BGP troubleshooting, as illustrated in this article and its follow-up article (Troubleshooting BGP networks), can quickly lead you from initial problem diagnosis to the solution. In this article, we'll focus on a simple scenario with a single BGP-speaking router in your network (see the following diagram). Similar designs are commonly used by multi-homed customers and small Internet Service Providers (ISPs) that do not offer BGP connectivity to their customers.

Is it a BGP problem?

Before jumping into BGP troubleshooting, you have to identify the source of the connectivity problem you're debugging (usually you suspect that BGP might be involved if one of your customers reports limited or no Internet connectivity beyond your network). Perform a traceroute from a workstation on the problematic LAN; if the trace reaches the first BGP-speaking router (or, even better, gets beyond the edge of your network) router, you're probably dealing with a BGP issue. Otherwise, check whether the BGP-speaking router advertises a default route into your network (without a default route, other routers in your network cannot reach the Internet destinations).

NOTE: If you don't have access to a LAN-attached workstation, you can perform the traceroute from the customer premises router, but you have to ensure that the source IP address used in the traceroute packets is the router's LAN address.

Troubleshooting BGP adjacencies

BGP has to establish TCP session between adjacent BGP routers before they can exchange routes. The first check is thus the status of the BGP sessions between the routers.

The BGP neighbours are configured manually, and the two most probable configuration errors are:

  • Neighbour IP address mismatch: The destination IP address configured on one BGP neighbour has to match the source IP address (or the IP address of the directly connected interface) configured on the other.
  • AS number mismatch: The neighbour AS number configured on one side of the BGP session has to match the actual BGP AS number used by the neighbour.

You could also have a problem with packet filters deployed on the BGP-speaking router. These filters have to allow packets to and from TCP port 179.

Troubleshooting route propagation

If your users want to receive traffic from the Internet, the IP prefix assigned to your network must be visible throughout the Internet. To get there, three steps are needed:

  • Your BGP router must insert your IP prefix into its BGP table.
  • The IP prefix must be advertised to its BGP neighbours.
  • The IP prefix must be propagated throughout the Internet.

Is the route inserted into BGP?

Most routing protocols automatically insert directly connected IP subnets into their routing tables (or databases). Owing to security requirements, BGP is an exception; it will originate an IP prefix only if it's manually configured to do so (for example, Cisco routers use the network statement to configure advertised IP prefixes).

Note: Another option is route redistribution, which is highly discouraged in the Internet environment.

Furthermore, to avoid attracting unroutable traffic, BGP will announce a configured IP prefix only if there's a matching route in the IP routing table. You could generate the matching IP route through route summarisation, but it's usually best to configure a static route pointing to a null interface (or its equivalent).

To check whether your IP prefix is in your BGP routing table, use a BGP show command (for example, show ip bgp prefix mask on a Cisco router).

Is the route advertised to your neighbours?

By default, all IP prefixes residing in the BGP table are announced to all BGP neighbours. Owing to security and routing policy requirements, the default behaviour is usually modified with a set of output and input filters. If you have applied output filters toward your BGP neighbours, you have to check whether these filters allow your IP prefix to be propagated to the external BGP neighbours. The command to display routes advertised to a BGP neighbour on a Cisco router is show ip bgp neighbour ip-address advertised.

Is the route visible throughout the Internet?

Even if you've successfully announced your IP prefix to your BGP neighbours, it might still not be propagated throughout the Internet. It's hard to figure out exactly what's propagated beyond the boundaries of your network; the tools that can help you are called BGP looking glasses. Using these tools, you can inspect BGP tables at various points throughout the Internet and check whether your IP prefix has made it to those destinations.

There are a few factors that could cause your IP prefix to be blocked somewhere in the Internet. The most common one is BGP route flap dampening: If an IP prefix flaps (disappears and reappears) too often in a short period of time -- for example, you clear your BGP sessions or change your BGP configuration -- the prefix gets blocked for an extended period of time (by default, up to an hour). If your IP prefix is dampened, there's nothing you can do except wait it out. You could also have an invalid (or missing) entry in IP routing registries, or there may be inbound filters at one of the upstream ISPs. In all these cases, it's best if your upstream ISP can help you resolve the problem (which is, at this point, beyond the scope of technical BGP troubleshooting).

About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting, and operating large service provider and enterprise WAN and LAN networks and is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and web technologies. His books published by Cisco Press include and EIGRP Network Design. You can read his blog here: http://ioshints.blogspot.com/index.html.

Read more on Data centre networking