Troubleshooting Private BGP Monitoring Sessions

This article applies to private BGP monitors that peer with a ThousandEyes-hosted route collector. For configuration instructions, see Configuring a Private BGP Monitor.

The ThousandEyes platform uses routes received from your Border Gateway Protocol (BGP) speaker to display each BGP test target's reachability from your network's perspective.

Data for the target prefix typically appears within five minutes after you create a test. If you enable Include covered prefixes, covered prefixes can take up to three hours to appear after you create the test because ThousandEyes uses routing information base (RIB) files to discover them.

If you cannot establish a BGP connection after you configure your routers to peer with the ThousandEyes route collector, review the following sections.

Incorrect Router Configuration

If your peering session is not uploading BGP announcements to the ThousandEyes route collector, review your router's configuration for errors. The following example shows a Juniper router configuration for establishing a BGP session with ThousandEyes:

set protocols bgp group thousandeyes-peer peer-as 65315
set protocols bgp group thousandeyes-peer type external
set protocols bgp group thousandeyes-peer multihop
set protocols bgp group thousandeyes-peer local-address xxx.xxx.xxx.xxx
set protocols bgp group thousandeyes-peer authentication-key <auth-key>
set protocols bgp group thousandeyes-peer import reject-all
set protocols bgp group thousandeyes-peer neighbor <thousandeyes-bgp-peer-ip-address>

Use the ThousandEyes BGP peer IP address provided in the email for this peering request. Do not use an address from a previous private BGP monitor configuration or another source.

Mismatched BGP MD5 Passwords

ThousandEyes requires BGP MD5 authentication for devices that peer with its route collector. Configure your router with the shared password, sometimes called a key. BGP MD5 uses the shared password and specific TCP header fields to authenticate the peer and verify each TCP segment. If the password is missing from either side or the passwords do not match, you might see messages like the following:

*Sep 21 00:08:26.639: %TCP-6-BADAUTH: No MD5 digest from 10.10.10.1(23217) to 10.10.10.2(179)
*Sep 21 00:08:26.959: %TCP-6-BADAUTH: Invalid MD5 digest from 10.10.10.1:23217 to 10.10.10.2:179

Verify that the password configured for the MD5 hash matches the password you provided to ThousandEyes.

Firewall and Packet Filter Rules

If the device that peers with the ThousandEyes route collector is behind a firewall or packet filter, the firewall or packet filter must permit connections to the collector's IP address on the standard BGP service port, 179/TCP. Check your firewall logs for dropped or rejected packets from your router to the collector on destination port 179/TCP. Add an appropriate rule if needed to allow your router to connect to ThousandEyes on port 179/TCP.

You might see firewall logs showing dropped or rejected connection attempts from ThousandEyes to your router on port 179/TCP. Blocking connections in this direction does not prevent the exchange of BGP information. Modify your firewall rules only if your router cannot connect to ThousandEyes.

Network Address Translation and Port Address Translation

BGP MD5 authentication computes a hash from parts of the IP and TCP headers, including the source and destination IP addresses and ports. Network address translation (NAT), port address translation (PAT), and network and port address translation (NAPT) change these values and are therefore incompatible with BGP MD5 authentication. If NAT translates a router interface from a non-routable RFC 1918 address to a routable address before the traffic reaches the ThousandEyes route collector, the MD5 hash comparison fails. The receiver might generate an error message like the following:

*Sep 21 00:08:26.959: %TCP-6-BADAUTH: Invalid MD5 digest from 10.10.10.1:23217 to 10.10.10.2:179

Changes to port numbers, sequence numbers, or other fields used by the BGP MD5 hash produce the same error. The following section describes a common example.

Cisco PIX/ASA

BGP MD5 authentication might fail if the TCP connection passes through a Cisco PIX/ASA. In addition to NAT, two PIX/ASA configuration settings can prevent successful MD5 authentication for packets that traverse the device:

• Cisco PIX/ASA software version 6.0 and later randomizes the sequence and acknowledgment numbers in TCP headers by default. Changing sequence numbers causes an MD5 authentication error. To use BGP MD5 authentication through a Cisco PIX/ASA, disable sequence-number randomization for the router's TCP connections to the ThousandEyes route collector. If necessary, disable sequence-number randomization globally. For configuration options and details, see the Cisco article ASA/PIX: BGP through ASA Configuration Example, or contact the Cisco Technical Assistance Center.

• Cisco PIX/ASA software version 7.0 and later overwrites the TCP options field used by the BGP MD5 algorithm by default. The firewall replaces the 18-byte MD5 option—kind (1 byte), length (1 byte), and MD5 hash (16 bytes)—with TCP no-operation (NOP) option bytes. Because the packet no longer contains the BGP MD5 authentication credentials, the receiver drops it and might log an error like the following:

*Sep 21 00:025:16.427: %TCP-6-BADAUTH: No MD5 digest from 10.10.10.10(23217) to 10.10.10.2(179)

Summary

To troubleshoot a private BGP monitoring session:

• Review the BGP session configuration.

• Check the firewall and packet filter rules.

• Disable NAT.

• Disable TCP random number sequencing.

• Disable TCP MD5 rewriting.

Learn More

• To review or update the monitor configuration, see Private BGP Monitoring.

• After the session is established, see Visualizing BGP Routes to confirm that the monitor has a route to the target prefix.

• To inspect announcements and withdrawals received from BGP monitors, see Using the BGP Updates Table.