Physical Versus Logical Connections

External BGP neighbors have a restriction on being physically connected. BGP drops any updates from its external BGP peer if the peer is nonconnected. Some situations, however, arise where external neighbors cannot be on the same physical segment. Such neighbors are logically, but not physically connected. An example would be running BGP between external neighbors across non-BGP routers. In this situation, Cisco offers an extra knob to override this restriction. BGP would require some extra configuration to indicate that its external peer is not physically attached.

---

Troubleshooting:  
Nondirectly connected external neighbors need extra configuration.

---

In Cisco's implementation, nondirectly connected EBGP peers are referred to as EBGP multihop. In figure 5-2, 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.

Figure 5-2  External BGP multihop environment.

On the other hand, neighbors within the same autonomous system (internal neighbors) have no restrictions whatsoever on whether the peer router is physically connected. As long as there is IP connectivity between the two neighbors, BGP requires no extra configuration. In figure 5-2, RT1 and RT4 are logically but not physically connected. Because both are in the same AS, no additional configuration is needed for them to run IBGP.

Obtaining an IP Address

The neighbor's IP address could be the address of any of the routers' interfaces, such as Ethernet, Token Ring, or Serial. Keep in mind that the stability of the neighbor connection will rely on the stability of the IP address you choose.

---

Troubleshooting:  
Session stability depends on stability of neighbor IP addresses.

---

If the IP address belongs to an Ethernet card that has some hardware problems and is shutting down every few minutes, the neighbor connection and the stability of the routing updates will suffer. Cisco has introduced a loopback interface; this is actually a virtual interface that is supposed to be up at all times. Tying the neighbor connection to a loopback interface will make sure that the session is not dependent on any hardware interface that might be problematic.

Adding loopback interfaces is not necessary in every situation (it actually requires more configuration). If external BGP neighbors are directly connected and the IP addresses of the directly connected segment are used for the neighbor negotiation, a loopback address is of no added value. If the physical link between the two peers is problematic, then the session will break with or without loopback.

---

Troubleshooting:  
Ch. 10, pp. 300-305. Building Peering Sessions

---

Authenticating the BGP Session

As you have already seen in Chapter 4, "Interdomain Routing Basics," the BGP message header allows authentication. Authentication is a measure of precaution against hackers who might present themselves as one of your BGP peers and feed you wrong routing information. Authentication between two BGP peers gives the capability to validate the session between you and your neighbor by using a combination of passwords and keys upon which you both agree. A neighbor that tries to establish a session without the use of these specific passwords and keys will not be permitted. The authentication feature uses the Message-Digest Algorithm version 5 (MD5) [1]. The discussion of the authentication algorithm itself is beyond the scope of this book.

BGP Continuity Inside an AS

To avoid creating routing loops inside the AS, BGP does not advertise to internal BGP peers routes that are learned via other IBGP peers. Thus, it is important to maintain a full IBGP mesh within the AS—that is, every BGP router in the AS has to build a BGP session with all other BGP routers inside the AS. Figure 5-3 illustrates one of the common mistakes administrators make when setting BGP routing inside the AS.

Figure 5-3  Common BGP continuity mistake.

---

Troubleshooting:  
Building full IBGP meshes to ensure connectivity.

---

In the situation illustrated in figure 5-3, an ISP has three POPs (Point Of Presence) in San Jose, San Francisco, and Los Angeles. Each POP has multiple non-BGP routers and a BGP border router running EBGP with other ASs. The administrator sets an IBGP connection between the San Jose border router and the San Francisco border router. He sets another IBGP connection between the SF border router and the LA border router. In this configuration, EBGP routes learned via SJ will be given to SF, EBGP routes learned via SF are given to SJ and LA, and EBGP routes learned via LA are given to SF. Routing in this picture is not complete; EBGP routes learned via SJ will not be given to LA, and EBGP routes learned via LA will not be given to SJ. This is because the SF router will not pass on IBGP routes between SJ and LA. What is needed is an additional IBGP connection between SJ and LA (shown via the dotted line). You will see in Chapter 8, "Controlling Large-Scale Autonomous Systems," how this situation could be handled by using the concept of route reflectors, an option that scales much better in cases where the AS has a large number of IBGP peers.