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 |
|