![]() ![]() |
9.3 | ![]() |
Configuring BGP | |
9.3.4 | ![]() |
EBGP multihop |
These example configurations have shown how to configure EBGP and IBGP.
However, what is the difference between the configuration types?
Figure ![]() RTZ and RTY have established an EBGP session. EBGP peers are normally directly connected, but there are certain exceptions to this requirement. In contrast, IBGP peers merely require TCP/IP connectivity within the same AS. As long as RTY can communicate with RTW using TCP, both routers can establish an IBGP session. If needed, an IGP such as OSPF can provide IBGP peers with routes to each other. In a typical configuration, an IBGP router maintains IBGP sessions with all other IBGP routers in the AS, forming a logical full mesh. This is necessary because IBGP routers do not advertise routes learned by way of IBGP to other IBGP peers, to prevent routing loops. In other words, if the IBGP routers are to exchange BGP routes with each other, configure a full mesh. An alternative to this approach is configuring a route reflector. Information on route reflectors can be obtained from the Cisco web site. As noted, EBGP neighbors must be directly connected to establish an
EBGP session. However, look again at RTW and RTU in Figure
This command enables the specification of how many hops, up to 255, separate the EBGP peers. The following commands could be applied to the routers in the example:
In general, EBGP multihop is designed to allow the development of economical AS edge router solutions. A single router with sufficient RAM and CPU power to support BGP is used to handle the BGP routing needs. This router does not have to be an expensive modular, chassis based system. EBGP multihop allows inexpensive edge routers to provide sufficient WAN interfaces for the autonomous systems connectivity needs.
|