‚ < ‚ Free Open Study ‚ > ‚ |
Problem: Nondirectly Connected External BGP Neighbors Not Coming UpAs discussed in Chapter 14, in some cases, EBGP neighbors are not directly connected. BGP neighbor relationships can be established in the following situations as well:
EBGP multihop can be used for several reasons. Peering between loopbacks between EBGP typically is done when multiple interfaces exist between the routers, and IP traffic needs to be load-shared among those interfaces. Another scenario might be one in which an edge router cannot run BGP and, therefore, EBGP must be run between a nonedge device in one AS and an edge router in another. A neighbor relationship must be established before any BGP updates and IP traffic can flow from one AS to another. This section addresses most of the common causes in which nondirectly connected EBGP neighbor relationships won't establish. Figure 15-4 shows that AS 109 and AS 110 are forming an EBGP neighbor relationship between the loopback interfaces. Such a connection will be considered nondirectly connected. Figure 15-4. Nondirectly Connected EBGP Session Between the Loopback Interfaces The most common possible causes of this problem are as follows :
Nondirectly Connected External BGP Neighbors Not Coming Up ‚ Cause: Route to the Nondirectly Connected Peer Address Is Missing from the Routing TableFigure 15-5 shows the flowchart to follow to fix this problem. Figure 15-5. Problem-Resolution Flowchart When BGP tries to peer the neighbor relationship with IP addresses that are not directly connected, as shown in Figure 15-4, the IP routing table must have the route to that IP address. In Figure 15-4, R1 is configured to peer with Loopback 0 of R2, and R2 is configured to peer with Loopback 0 of R1. This is a common practice when multiple connections exist between R1 and R2 and load sharing over these multiple lines is required. Debugs and VerificationExample 15-8 shows the relative configuration of both Routers R1 and R2. Example 15-8 Configurations for R1 and R2 in Figure 15-4R1# router bgp 109 neighbor 131.108.10.2 remote-as 110 neighbor 131.108.10.2 ebgp-multihop 2 neighbor 131.108.10.2 update-source Loopback0 _____________________________________________________________________________________ R2# router bgp 110 neighbor 131.108.10.1 remote-as 109 neighbor 131.108.10.1 ebgp-multihop 2 neighbor 131.108.10.1 update-source Loopback0 In Example 15-8, Routers R1 and R2 are configured to peer with each other's loopback IP address. ebgp-multihop 2 means that R1 and R2 peering addresses could be two hops away. update-source means that the source of BGP packets is the Loopback the 0 IP address because both routers accept only BGP packets sourced with the Loopback 0 IP address of other router. The output in Example 15-9 shows the neighbor relationship between R1 and R2. Example 15-9 show ip bgp Command Output Displays the BGP Neighbor Relationship Between R1 and R2R1# show ip bgp summary BGP router identifier 131.108.10.1, local AS number 109 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 131.108.10.2 4 110 3 3 0 0 0 00:03:21 Active R1# show ip bgp neighbors 131.108.10.2 BGP neighbor is 131.108.10.2, remote AS 110, external link BGP version 4, remote router ID 0.0.0.0 BGP state = Active Last read 00:04:20, hold time is 180, keepalive interval is 60 seconds Received 3 messages, 0 notifications, 0 in queue Sent 3 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0 Minimum time between advertisement runs is 30 seconds For address family: IPv4 Unicast BGP table version 1, neighbor version 0 Index 2, Offset 0, Mask 0x4 0 accepted prefixes consume 0 bytes Prefix advertised 0, suppressed 0, withdrawn 0 Connections established 1; dropped 1 Last reset 00:04:21, due to User reset External BGP neighbor may be up to 2 hops away. No active TCP connection The highlighted output in Example 15-9 shows that R1's neighbor relationship with R2 is in the Active state and that the BGP relationship is not complete. The configuration shown in Example 15-8 is a required configuration when configuring an EBGP connection to a nondirectly connected peer; however, one thing that is not controlled by BGP configuration is the reachability to peer addresses. Example 15-10 shows that R1 cannot reach the loopback interface of R2 because R1 does not have the route to reach R2. Example 15-10 R1 Cannot Ping R2's Loopback Interface and Has No Route to Reach R2R1# ping 131.108.10.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 131.108.10.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) R1# show ip route 131.108.10.2 % Subnet not in table In R1, BGP will send its packets to peer 131.108.10.2, but packets will be dropped by R1 because no routing reachability is available for 131.108.10.2. SolutionBGP relies on an IP routing table to reach a peer address. In the example in Figure 15-4, R1 must have a route to the loopback interface of R2, and R2 must have a route to the loopback interface of R1. It is irrelevant how the route to the peer address is learned, as long as the route is present in the routing table. Administrators of R1 and R2 can choose to run a dynamic IP routing (an IGP) between each other (for example, using OSPF), or they could nail a static route to each other. Using a static route is a common practice. A simple rule of thumb is that R1 and R2 must have most specific routes for each other's loopback addresses through any other protocol other than BGP. To configure a static route on R1 to reach multihop EBGP neighbors, you would enter the following: ip route 131.108.10.2 255.255.255.255 131.108.1.2 R1 has a host static route for R2's loopback interface with a next hop of 131.108.1.2, which is R2's Ethernet interface IP address. Similarly, R2 should have a static route for R1's loopback interface. This will ensure that both routers have reachability to multihop EBGP neighbors. Nondirectly Connected External BGP Neighbors Not Coming Up ‚ Cause: ebgp-multihop Command Is Missing in BGP ConfigurationFigure 15-6 shows the flowchart to follow to fix this problem. Figure 15-6. Problem-Resolution Flowchart By default, in Cisco IOS Software, BGP packets sent to an external BGP neighbor have their IP Time To Live (TTL) set to 1. If an EBGP neighbor is not directly connected, the first device in the path will drop BGP packets with TTL equal to 1 to that EBGP neighbor. Debugs and VerificationReturning to the network in Figure 15-4, R1 is trying to peer EBGP to R2's Loopback 0 interface, which is considered more than one hop away. Example 15-11 shows the configuration of R1. Example 15-11 R1's Configuration to Form EBGP Multihop Neighbor RelationshipR1# router bgp 109 neighbor 131.108.10.2 remote-as 110 neighbor 131.108.10.2 update-source Loopback0 Example 15-12 shows the output to verify that nondirectly connected EBGP neighbors are either coming up or not coming up. Example 15-12 show ip bgp Command Output Verifies if the EBGP Neighbors Are Coming UpR1# show ip bgp summary BGP router identifier 131.108.10.1, local AS number 109 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 131.108.10.2 4 110 25 25 0 0 0 00:00:51 Idle R1# show ip bgp neighbors 131.108.10.2 BGP neighbor is 131.108.10.2, remote AS 110, external link BGP version 4, remote router ID 0.0.0.0 BGP state = Idle Last read 00:00:15, hold time is 180, keepalive interval is 60 seconds Received 25 messages, 0 notifications, 0 in queue Sent 25 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0 Minimum time between advertisement runs is 30 seconds For address family: IPv4 Unicast BGP table version 1, neighbor version 0 Index 2, Offset 0, Mask 0x4 0 accepted prefixes consume 0 bytes Prefix advertised 0, suppressed 0, withdrawn 0 Connections established 4; dropped 4 Last reset 00:02:18, due to User reset External BGP neighbor not directly connected. No active TCP connection The highlighted output shows that BGP neighbor is in the Idle state, in which no resources are allocated to BGP neighbor. This might be because the other side has not received any BGP negotiation from R1 or because R1 has not received anything from R2. SolutionUse the ebgp-multihop command to increase the IP TTL value to the desired number. Example 15-13 shows the required configuration on R1 to bring up the EBGP neighbor R2. Example 15-13 Using ebgp-multihop to Increase the IP TTL Value R1# router bgp 109 neighbor 131.108.10.2 remote-as 110 neighbor 131.108.10.2 ebgp-multihop 2 neighbor 131.108.10.2 update-source Loopback0 The ebgp-multihop 2 command sets the IP TTL value to 2 rather than the default of 1. This way, if a BGP speaker is two hops away, the BGP packet will reach it; otherwise , it would have been dropped by the intermediate device because of the IP TTL expiration. Example 15-15 shows the debug ip packet output and sniffer capture in R2 of BGP packets from R1 to R2. ebgp-multihop is set to 5, as shown in the configuration of Example 15-14. Example 15-14 Setting ebgp-multihop to 5 R1# 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 Example 15-15 debug ip packet and Sniffer Capture in R2 of BGP Packets from R1 to R2 IP: s=131.108.10.1 (Ethernet0), d=131.108.10.2, len 59, rcvd 4 TCP src=179, dst=13589, seq=1287164041, ack=1254239588, win =16305 ACK 04009210: 0000 0C47B947 00000C09 ...G9G.... 04009220: 9FEA0800 45C00028 00060000 04 069B2F .j..E@.(......./ 04009230: 836C0A01 836C0A02 00B33515 4CB89089 .l...l...35.L8.. 04009240: 4AC22D64 50103FB1 CA170000 00000000 JB-dP.?1J....... 04009250: 0000C8 ..H The debug shows that R2 is receiving a BGP packet on TCP port 179 from source 131.108.10.1 (R1). In the sniffer capture, the highlighted hex value 04 is the IP TTL value of 4. The IP TTL value is 4 because R2 decremented the TTL by 1. This example of capturing packets through sniffer is shown to illustrate the use of the ebgp-multihop command in BGP to increase the IP TTL of a BGP packet. Nondirectly Connected External BGP Neighbors Not Coming Up ‚ Cause: update-source interface Command Is MissingBy default in Cisco IOS Software, the source of the BGP packet is the outgoing interface IP address as taken from the routing table. In BGP, the neighbor's IP address must be statically defined in configuration. If an EBGP speaker does not receive a BGP update from a IP source that is identical to what it has configured, it rejects that update. The update-source command in BGP changes the source address of the IP packet. Instead of picking the outgoing interface as a source IP address, BGP packets will be sourced with the interface IP address configured with the update-source command. Figure 15-7 shows the flowchart to follow to fix this problem. Figure 15-7. Problem-Resolution Flowchart Debugs and VerificationExample 15-16 displays output from R1 to shows R1's IP routing table entry for R2's loopback 131.108.10.2 and R1's outgoing interface address to reach R2's loopback interface. Example 15-16 R1 IP Routing Table Entry for R2's Loopback InterfaceR1# show ip route 131.108.10.2 Routing entry for 131.108.10.2/32 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 131.108.1.2 Route metric is 0, traffic share count is 1 R1# show ip route 131.108.1.2 Routing entry for 131.108.1.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via Ethernet0 Route metric is 0, traffic share count is 1 R1# show interfaces ethernet 0 Ethernet0 is up, line protocol is up Hardware is Lance, address is 0000.0c09.9fea (bia 0000.0c09.9fea) Internet address is 131.108.1.1 /24 All IP packets destined for 131.108.10.2 have a source address of 131.108.1.1, which is the outgoing interface address of R1, as shown in Example 15-16. Example 15-17 shows a simple BGP configuration of R1 and R2 (as depicted in the network in Figure 15-4), peering with each other's loopback. The configuration in Example 15-17 does not result in an EBGP neighbor relationship because the IP source address of BGP packets won't be what R2 is configured to expect. The working configuration is shown in the "Solution" section. Example 15-17 R1/R2 BGP Configuration with Peering with Loopback InterfacesR1# router bgp 109 neighbor 131.108.10.2 remote-as 110 neighbor 131.108.10.2 ebgp-multihop 2 _____________________________________________________________________________________ R2# router bgp 110 neighbor 131.108.10.1 remote-as 109 neighbor 131.108.10.1 ebgp-multihop 2 The problem comes in when R1 sends its BGP packets to its configured neighbor 131.108.10.2. The source IP address of those BGP packets will be 131.108.1.1, the out-going interface address. R2 is expecting BGP packets from R1 with the source address of R1's loopback 131.108.10.1, the peering address, so it will reject these BGP packets. Example 15-18 shows the output of the debug ip bgp that shows how R2 rejects packets from R1. Example 15-18 debug ip bgp Command Output Reveals R2 Rejecting Packets from R1R1# debug ip bgp 04:42:10: BGP: 131.108.10.2 open active, local address 131.108.1.1 04:42:10: BGP: 131.108.10.2 open failed: Connection refused by remote host SolutionR1 should be configured with the update-source command, using the neighbor statement for R2 to accept any BGP packets from R1. The update-source command ensures that the source address is that of Loopback 0, which R2 expects. Example 15-19 shows the necessary configuration addition in R1 and R2 to form an EBGP multihop neighbor relationship. Example 15-19 Correct Configuration of R1 and R2 to Form EBGP Multihop Neighbor RelationshipR1# router bgp 109 neighbor 131.108.10.2 remote-as 110 neighbor 131.108.10.2 ebgp-multihop 2 neighbor 131.108.10.2 update-source Loopback0 _____________________________________________________________________________________ R2# router bgp 110 neighbor 131.108.10.1 remote-as 109 neighbor 131.108.10.1 ebgp-multihop 2 neighbor 131.108.10.1 update-source Loopback0 |
‚ < ‚ Free Open Study ‚ > ‚ |