|
This example demonstrates the different
types of BGP peering sessions you will encounter. An IBGP peering
session is formed within AS3, between the loopback address of RTA
and a physical address of RTF. An EBGP session is also formed
between AS3 and AS1 by using the two directly connected IP addresses
of RTA and RTC. Another EBGP session is formed between RTF in AS3
and RTD in AS2, using IP addresses that are not on the same segment
(multihop).
It is important to remember that the
BGP peers will never become established unless there is IP
connectivity between the two peers. In this example, OSPF is used to
establish the required internal connectivity between RTD and RTE.
Note: Click on topology to view
command outputs.
In RTF's configuration, you can see
the ebgp-multihop 2
command being used as part of the neighbor configuration. This is an
indication that the exterior BGP peer is not directly connected and
can be reached at a maximum of two hops away. Remember that EBGP
multihop is applicable only with EBGP, and not with IBGP.
The example also shows how the peer
connection will look after the neighbors are in an established
state. From RTF's point of view, neighbor 172.16.2.254 is an
internal neighbor that belongs to AS3. The neighbor connection is
running BGP Version 4 with a table version of 2. The table version
changes every time the BGP table is updated.
The other RTF neighbor, 192.68.12.1,
is also in an Established state. This is an external neighbor that
belongs to AS2. Note that the display indicates that this neighbor
is two hops away and is configured using the ebgp-multihop
command.
|