8.4 BGP Basic Configuration
8.4.4
Compare and contrast EBGP and IBGP configurations
In the example, router A (RTA) and router B (RTB) are running EBGP, and RTB and router C (RTC) are running IBGP. Notice that the EBGP peers are directly connected and the IBGP peers are not. IBGP routers do not have to be directly connected, as long as there is some IGP running that allows the neighbors to reach one another.

External BGP neighbors are generally restricted to being physically connected; BGP drops any updates from its external BGP peer if the peer is not connected. Some situations, however, arise where external neighbors cannot be on the same physical segment -- for example running EBGP across non-BGP routers. In this situation, Cisco offers an extra knob to override this restriction.

In the Cisco implementation, nondirectly connected EBGP peers are referred to as EBGP multihop. In the example, RT2 is not able to run BGP, but RT1 and RT3 are. Thus, external neighbors RT1 and RT3 are logically connected and peer with one another via EBGP multihop.

Following is an example of the information that the command sh ip bgp neighbors will show you. Notice the BGP state; anything other than established indicates that the peers are not up. You should also notice that the BGP version is 4 and the remote router ID (the highest IP address on the router, typically). The table version is the state of the table -- any time new information comes in, the version will increase. A version that constantly increments indicates that a route is flapping.

#sh ip bgp neighbor
BGP neighbor is 129.225.17.1, remote AS 2, external link
BGP version 4, remote router ID 172.16.16.6
BGP state = Established, table version = 3, up for 0:10:59
Last read 0:00:29, hold time is 180, keepalive interval is 60 seconds
Minimum time between advertisement runs is 30 seconds
Received 2828 messages, 0 notifications, 0 in queue
Sent 2826 messages, 0 notifications, 0 in queue
Connections established 11; dropped 10