quote of the day, karl solie...

just because it's old, doesn't mean it doesn't count... just weed out what's no longer useful... this from ccie practical studies volume 2...

go get em karl:

If the BGP peers are not able to reach each other using TCP port 179, you can use a number of TCP troubleshooting commands to troubleshoot the connection. As a best practice (that will save you many a headache), however, it is better to verify the router configuration for inaccuracies before troubleshooting a problem that might end up being a typo.

• Verify that the local BGP ASN is entered correctly.
• Verify that the remote peer's BGP ASN and IP address are entered correctly.
• Verify that the interfaces connecting the two peers are up and operational.
• If the peers are not directly connected, verify that they have a valid route (to and from) to reach each other.
• Check routers along the path between the peers for access lists or route policies that might be dropping or rerouting BGP traffic.
• Check logs for interface instabilities. Are routes flapping along the route between the BGP peers? Are any of the interfaces heavily congested or dropping packets? Keep in mind that BGP uses rather small packets for OPEN and KEEPALIVE messages. These packets are delayed if other larger packets are monopolizing a congested interface.
• If something has changed in the path between the two BGP peers, verify that it is not affecting the BGP session—for example, a new switch configuration, new access lists, a firewall, new routing policies, and so on.

Don't spend time troubleshooting BGP when it is not the problem! Establish a general layered troubleshooting methodology; it will be the number one troubleshooting tool and your best friend when you encounter a problem.

1. Layer 1

   - Check your cabling; verify that all cables are connected and that the interface is in a line up and protocol up state. Don't spend time troubleshooting BGP when you have a Layer 1 problem.

   - If you are using a serial link, make sure that you have set the correct clock rate. If you are using a channel service unit/data service unit (CSU/DSU), make sure it is properly configured and the line is up.

   - If you are using an Ethernet interface, make sure that the speed and duplex are set correctly on the router and switch.

   - Check the router and switch interfaces for errors; if there are errors, fix the error and then proceed with your troubleshooting. If you are using a Token Ring interface, make sure the router is configured to use the right ring speed, and that it has a good connection to the multistation access unit (MSAU) or switch.
   (note: I supported a 16mbps token ring network from '94 to '97)

2. Layer 2

   - If you are using an Ethernet connection, make sure that the switch port has been assigned to the proper VLAN.

   - Make sure that the VLAN is properly configured, and that there are no spanning-tree topology problems on the switch.

   - On an ATM interface, verify that the maximum transmission unit (MTU) is properly configured on both sides of the connection.

   - Verify that you are using the correct virtual path identifier/virtual channel identifier (VPI/VCI) pair, and that you have configured a valid ATM map for Layer 2 to Layer 3 connectivity. On a Frame Relay connection, verify that your local and remote data-link connection identifiers (DLCIs) and Local Management Interface (LMI) type are correctly set to match the values generated on the switch.

   - Verify that LMI is up and that the interface is not flapping.

   - If you are making a PPP connection, make sure PPP is configured on both sides of the connection.

   - Before proceeding to the next step, verify that your interface is not in a line up protocol down state.

3. Layer 3

   - Verify that you have configured the right IP address and subnet mask on the interface, check the other side of the connection, and verify that it is on the same subnet (if directly connected) or that it is what you think it is.

   - Make sure there is a valid route to reach your destination in the IP routing table. Trace the connection through any routers along the path, and verify that they have a path to and from each of the routers that they must reach for packets to reach your source and destination networks.

   - Check static routes for typos; make sure that any redistributed routes are actually being properly propagated.

   - If multiple paths are in use, verify that there are no routing loops.

   - If authentication is in use by any routing protocols, make sure that they are both using the correct passwords.

   - On nonbroadcast multiaccess (NBMA) networks, such as ATM or Frame Relay, make sure that you have proper support for Layer 2 to Layer 3 mappings, and that protocols such as Open Shortest Path First (OSPF) are configured for the proper network type.

   - Before proceeding to the next step, verify that you are able to reach the destination network from the source network and vice versa.

4. Layer 4

   - Check for any access lists or firewalls that might be dropping TCP packets.

   - Verify that you have connectivity on TCP port 179. One BGP speaker, the passive TCP host, will receive a TCP request on port 179, and the other speaker, the active TCP host, will use a random TCP source port (beginning at 11,000) to initiate the TCP session.

   - Check for retransmissions, out-of-order packets, or other TCP symptoms that might be pointing to network congestion or invalid configurations.

After verifying that all the prior conditions are not affecting the BGP session, use TCP show and debug commands to help narrow down the culprit.

TCP Command	Command Description
show tcp	This command displays detailed information on each TCP session that the local router has formed with a remote peer. It can be used with BGP to show whether the local and remote BGP peers have formed an established TCP session, and show details about that session.
show tcp [brief][all] [| include 179]	This command displays a brief status of each of the TCP sessions that the local router has formed with a remote router. This is a basic summary command that you can use as another tool to verify the BGP TCP connection between peers.
debug ip tcp transactions	This command, which should be used with caution on a production router, displays information about TCP session changes. It enables you to troubleshoot a BGP TCP session, displaying information about TCP retransmissions or state changes.
debug ip tcp packet [in | out | address IP-address | port port-number]	This command displays detailed information about TCP packets. It can be used with the in, out, address, or port arguments to specify particular traffic, and must be used with extreme caution on a production router. With this command, you can monitor TCP packets sent and received by the local router. This information enables you to determine the cause of an unstable BGP TCP session and resolve route flapping or general connectivity issues.

If the show tcp command output for the peer IP address used for the BGP session is anything other than ESTAB, troubleshoot the TCP connection.