Scribd
Upload
43 views2 pages

BGP Troubleshooting Summary

Uploaded by

Fooz fooz
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
43 views2 pages

BGP Troubleshooting Summary

Uploaded by

Fooz fooz
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

The Cisco Troubleshooting Labs Course

BGP Troubleshooting Summary

1. Check the BGP Neighborship: Check if the BGP neighborship is up (Established)


or not using the command show ip bgp summary, and if not:
 Check if the neighbor command is configured with the correct IP (an existed IP
on the other router) and AS number using the above mentioned command
(show ip bgp summary) and correct the issue if this was the case. If the other
router (the neighbor) is configured correctly for its packets to reach the local
router, then the log message peer in wrong AS will be shown on the local
router which is another indication of the issue.
 Check if the IP address configured in the neighbor command is reachable or
not using the show ip route IP_route command.
 Check if the other router (the neighbor) is configured with correct IP in the
neighbor command, which should be the IP address that it expects the BGP
packets to come from. By default, the BGP router uses the IP of the outgoing
interface that is used to reach the neighbor for establishing the peering, which
can be seen in the routing table. If not, then either:
a) configure the neighbor command on the other router with this IP (of
the outgoing interface on the local router),
b) or use the update-source keyword with the neighbor command on the
local router to use the IP address that the other router expects the BGP
packets to come from (typically of a loopback interface).

A basic way to test the peering up to layer3 is to telnet to port 179 with
specifying the source address. Another way is to use the debug ip tcp
transaction command to check for the TCP three-way hand shake is failing
because of this issue (where RST/closes and bad messages will be displayed).
The update-source/neighbor matching criteria needs to be on one way only
for peering to come up. When the update-source (to use loopback interfaces)
is configured on one side only, the BGP peering will come up with insuring that
this side will be always the TCP client. This is because its session establishment
request will be accepted unlike the one from the other side.

 Check if one of these console message appears (which need the command log-
neighbor-changes to be enabled which indicates MD5 authentication issue :
a) %TCP-6-BADAUTH: No MD5 digest which means the other side does
not have authentication configured
b) %TCP-6-BADAUTH: Invalid MD5 digest which means the other side has
a different password configured.
The Cisco Troubleshooting Labs Course

 If the two neighbors are external (i.e. are in different ASes and therefore eBGP
is used), then the TTL of BGP packets sent between the two neighbors will be
set to 1 based on the assumption that the directly connected interfaces IP
addresses will be used for peering. Therefore, if the two eBGP neighbors are
not directly connected or using their loopback interface for the peering
establishment, then the first device in the path will drop BGP packets with TTL
equal to 1 sent between them. There are two ways to solve the TTL issue
when configuring eBGP:
a) Using the ebgp-multihop option which increases the TTL value.

b) Using the disable-connected-check option which does not increase TTL


value, but allows the router to send packets with TTL value of 1 when
establishing eBGP peering between IP addresses not on the same
subnet. Now, the peering will be established if the two routers are
directly connected even if the update-sources are loopback interfaces
because a TTL value of 1 is fine. However, if the direct link(s) between
the two routers failed, the peering will go down even if there is another
indirect route between the two routers unlike what the case is with
the ebgp-multihop option because the TTL will become zero while
transiting the first router in the path. This design (i.e. using the disable-
connected-check option) is used where you do not want to reroute the
BGP session around network failures. This can also save memory
resources in case of failures because the ebgp-multihop option offers
redundancy but keeps the failed routes beside the best routes in the
BGP table.
Note: Unlike iBGP, which is normally configured between loopback interfaces,
the majority of EBGP sessions are configured between directly connected interfaces.
Therefore, ebgp-multihop is not frequently required. An example of where eBGP
between loopback interfaces can be useful is when two external neighbors are
directly connected with multiple links (such as multiple ATM or Frame Relay virtual
circuits) for redundancy, but only a single eBGP session is desired. If the link being
used by eBGP fails, the session can be rerouted over an alternative link.

You might also like