Problem: IBGP-Learned Route Not Getting Installed in IP Routing Table

‚  < ‚  Free Open Study ‚  > ‚  

The most common causes of this problem are as follows :

  • IBGP routes are not synchronized.

  • The BGP next hop is not reachable .

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 Synchronized

IBGP 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

graphics/15fig18.gif

Figure 15-19 shows the flowchart to follow to resolve this problem.

Figure 15-19. Problem-Resolution Flowchart

graphics/15fig19.gif

Debugs and Verification

Example 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 IBGP
 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  _____________________________________________________________________________________ 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/24
 R2#  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.

Solution

A network operator can choose to work around this problem in two ways:

  • Synchronize all BGP routes.

  • Turn off synchronization.

Synchronizing All IBGP Routes

The 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 R1
 R2#  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 Synchronization

This 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 ‚  > ‚  


Troubleshooting IP Routing Protocols
Troubleshooting IP Routing Protocols (CCIE Professional Development Series)
ISBN: 1587050196
EAN: 2147483647
Year: 2002
Pages: 260

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net