‚ < ‚ Free Open Study ‚ > ‚ |
The most common causes of this problem are as follows :
The sections that follow discuss these causes and how to resolve the problem based on the cause. IBGP-Learned Route Not Getting Installed in IP Routing Table ‚ Cause: IBGP Routes Are Not SynchronizedIBGP will not install or propagate a route to other BGP speakers unless IBGP-learned routes are synchronized. Synchronization means that for an IBGP-learned route, there must exist an identical route in the IP routing table provided by an IGP (OSPF, IS-IS, and so on). This means that the IGP must hold all external BGP routing information. This can be accomplished by redistributing EBGP into an IGP at the border routers of an AS. In Figure 15-18, R1 is originating 100.100.100.0/24 to its IBGP neighbor, R2 (13.108.10.2). R2 is configured to form IBGP neighbors with R1 and is originating nothing. Figure 15-18. R1 Advertising 100.100.100.0/24 to IBGP Neighbor R2, Which Checks for Synchronization of BGP Routes Figure 15-19 shows the flowchart to follow to resolve this problem. Figure 15-19. Problem-Resolution Flowchart Debugs and VerificationExample 15-40 is the relevant BGP configuration needed in R1 and R2 to originate and receive 100.100.100.0/24 through IBGP. Example 15-40 Configuring R1 and R2 to Originate and Receive 100.100.100.0/24 Through IBGPR1# router bgp 109 network 100.100.100.0 mask 255.255.255.0 neighbor 131.108.10.2 remote-as 109 neighbor 131.108.10.2 update-source Loopback0 ip route 100.100.100.0 255.255.255.0 Null0 _____________________________________________________________________________________ R2# router bgp 109 neighbor 131.108.10.1 remote-as 109 neighbor 131.108.10.1 update-source Loopback0 Example 15-41 shows that R2 has received an IBGP update for 100.100.100.0/24. Example 15-41 R2's BGP Routing Table Entry Indicates That an IBGP Update Was Received for 100.100.100.0/24R2# show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 3 Paths: (1 available, no best path ) Flag: 0x208 Not advertised to any peer Local 131.108.10.1 from 131.108.10.1 (131.108.10.1) Origin IGP, metric 0, localpref 100, valid, internal, not synchronized R2# show ip route 100.100.100.0 % Network not in table The output in Example 15-41 also explains that BGP finds no best-path candidate to be installed in IP routing table. The reason is that this particular BGP update is not synchronized. SolutionA network operator can choose to work around this problem in two ways:
Synchronizing All IBGP RoutesThe solution of turning off synchronization needs no further explanation. Synchronizing all BGP routes, however, requires some more detailed coverage. To synchronize 100.100.100.0/24, R1 must advertise this route in its IGP so that R2 can receive it through both IBGP and IGP. Example 15-42 shows that R1 is advertising this route by redistributing static routes in OSPF, and R2 receives it as an external OSPF route and in normal IBGP as well. Example 15-42 Configuration Needed to Advertise All Routes Advertised Through IBGP and IGP (OSPF)R1# router ospf 1 redistribute static subnets network 131.108.1.0 0.0.0.255 area 0 R1# router bgp 109 network 100.100.100.0 mask 255.255.255.0 neighbor 131.108.10.2 remote-as 109 neighbor 131.108.10.2 update-source Loopback0 ip route 100.100.100.0 255.255.255.0 Null0 The configuration in Example 15-42 shows that OSPF is redistributing static routes; the only static route shown is 100.100.100.0/24. BGP is also advertising the same prefix to R2, as demonstrated in Example 15-43. Example 15-43 Output to Show R2 Is Receiving a Synchronized IBGP Route from R1R2# show ip route 100.100.100.0 Routing entry for 100.100.100.0/24 Known via "ospf 1" , distance 110, metric 20, type extern 2, forward metric 10 Redistributing via ospf 1 Last update from 131.108.1.1 on Ethernet0, 00:07:21 ago Routing Descriptor Blocks: * 131.108.1.1, from 131.108.10.1, 00:07:21 ago, via Ethernet0 Route metric is 20, traffic share count is 1 R2# show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 4 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x208 Not advertised to any peer Local 131.108.10.1 from 131.108.10.1 (131.108.10.1) Origin IGP, me tric 0, localpref 100, valid, internal, synchronized , best In Example 15-43, BGP now marks this route as synchronized and will install this route in its IP routing table. It also will propagate this route to other BGP speakers. In Example 15-43, the routing table chooses the OSPF route instead of the IBGP route because of the lower administrative distance of 110 over 200. NOTE In the case of OSPF, Cisco IOS Software expects the OSPF router ID (RID) and the BGP RID for R1, the advertising router, to be identical for synchronization to work properly. There is no such restriction for any other IGPs. Turning Off SynchronizationThis method is widely used in almost all BGP networks. Example 15-44 provides the necessary configuration to accomplish this. Example 15-44 Turning Off Synchronization R2# router bgp 109 no synchronization As seen in the previous section, all routes in BGP must also be redistributed in IGP to have synchronization in the IBGP network. With the size of BGP tables these days (more than 110,000 entries), it is not recommended that you redistribute all BGP routes into an IGP. Therefore, it becomes common practice to turn off synchronization instead. |
‚ < ‚ Free Open Study ‚ > ‚ |