‚ < ‚ Free Open Study ‚ > ‚ |
BGP requires a neighbor relationship to be established before any information is exchanged between BGP speakers . BGP does not dynamically discover routers interested in running BGP; instead, BGP is configured with a specific neighbor IP address. Like most other dynamic protocols, BGP uses periodic keepalive messages to ensure availability of BGP neighbors. The keepalive timer is one third of the holdtime. If three consecutive keepalive messages are missed from a particular BGP neighbor, the holdtime expires and that neighbor is considered dead. In RFC 1771, the suggested value for the holdtime is 90 seconds, and the suggested value for the keepalive timer is 30 seconds. These values are negotiated between BGP neighbors when the neighbors first come up. RFC 1771 also requires that "an implementation of BGP must allow these timers to be configurable." When BGP is configured with a neighbor IP address, it goes through a series of stages before it reaches the desired Established state in which BGP has negotiated all the required parameters and is willing to exchange BGP routes. BGP goes through the following stages of neighbor relationship, per RFC 1771:
Figure 14-2 highlights a simple BGP state machine that runs while BGP is in operation. Some details are left out for simplicity. Refer to RFC 1771 for a more detailed examination of the BGP state machine operation. Figure 14-2. BGP State Machine External BGP Neighbor RelationshipsThis section explains a sample configuration of EBGP sessions. In Figure 14-3, R1 and R2 belong to different autonomous systems ‚ 109 and 110, respectively. Figure 14-3. External BGP Neighbor Relationship Example There are two ways to configure when peering EBGP:
The peering relationship with R1 and R2 in Case 1 means that the R1 peering IP address is in the same subnet as its own physical interface. The configuration for this case is as follows : R1#: router bgp 109 neighbor 131.108.1.2 remote-as 110 R1 in Figure 14-3 has an interface with an IP address of 131.108.1.1. Figure 14-4 shows two scenarios of multihop EBGP sessions indicative of the peering relationship in Case 2. In this figure, EBGP peering between R1 and R2 is done with each other's loopback addresses. This is typically seen when multiple connections exist between the two autonomous systems and both links should carry traffic. Either each AS runs two separate BGP neighbor relationships on two separate physical interfaces, or they can configure one BGP neighbor to the loopback and configure two static routes to reach each other's loopback. The latter method is preferable because it saves an extra BGP neighbor relationship. Figure 14-4. EBGP Peering Relationship Through Loopback Interfaces In Figure 14-5, R3 in AS 110 might not be capable of running BGP, so R1 and R2 must peer with each going through R3. Figure 14-5. EBGP Peering Relationship Through a Third-Party Router In both cases of Figure 14-4 and Figure 14-5, it is assumed that all routers have reachability to R1 and R2's loopback addresses. Loopback addresses are used because they are virtual interfaces and they never go down like physical interfaces do. Even if one physical interface goes down, BGP between loopbacks remains up as long as they exist as redundant paths to each other's loopbacks. Example 14-1 shows a sample configuration of R1 to configure multihop EBGP session. Example 14-1 Sample Configuration of R1 to Show Multihop EBGP SessionR1#: router bgp 109 neighbor 131.108.10.2 remote-as 110 neighbor 131.108.10.2 ebgp-multihop 5 neighbor 131.108.10.2 update-source Loopback0 ebgp-multihop 5 means that neighbor 131.108.10.2 can be only five hops away from R1, and the Time To Live (TTL) field in the IP header is set to 5. update-source Loopback0 means that all BGP updates are sourced from the Loopback 0 address of R1. R2 uses 131.108.10.1 as the next -hop address for all routes learned through R1. Internal BGP Neighbor RelationshipsAssume that R1 and R2 belong to the same AS, 109, as shown in Figure 14-6. Figure 14-6. Internal BGP Neighbor Relationship Example If R1 and R2 are IBGP neighbors, meaning that they are BGP neighbors in the same AS, the configuration cases can be any of the following:
NOTE The neighbor 131.108.10.2 ebgp-multihop command is not needed. In cases of IBGP, the TTL in the IP header is set to 255 in Cisco IOS Software because it is assumed that IBGP neighbors might not be physically directly connected. In addition, an IBGP neighbor relationship can also be established between loopback addresses that are considered a multihop away from each other. In case of a physical failure in the network, IBGP can use alternate physical paths, if they exist, to reach the loopback of the BGP neighbor. This way, IBGP remains intact, even in the case of physical failures along the way. |
‚ < ‚ Free Open Study ‚ > ‚ |