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

 < Free Open Study > 

Just as with IBGP, EBGP routes might not get installed in the IP routing table, resulting in a lack of IP traffic reachability to those routes. Multiple causes of this problem might exist, depending on which EBGP scenario is being looked at.

The most common causes of EBGP routes not getting installed are as follows :

  • BGP routes are dampened.

  • The BGP next hop is not reachable in case of multihop EBGP.

  • The multiexit discriminator (MED) value is infinite.

The sections that follow discuss these causes and how to resolve the problem based on the cause.

EBGP-Learned Route Not Getting Installed in IP Routing TableCause: BGP Routes Are Dampened

Dampening is the way to minimize instability in a local BGP network caused by unstable BGP routes from EBGP neighbors. RFC 2439, "BGP Route Flap Damping," describes in detail how dampening works. In short, dampening is the way to assign a penalty for a flapping BGP route. A withdrawal of a prefix is considered a flap. A penalty of 1000 is assigned for each flap; if the flap penalty reaches the suppress limit because of continued flaps (default 2000), the BGP path is suppressed and is taken out of the routing table. This penalty is decayed exponentially based on the half-life time (default 15 minutes). When the penalty reaches the reuse value (default 750), the path is unsuppressed and is installed in the routing table and advertised to other BGP neighbors. Any dampened path can be suppressed only until the max suppress time (default 60 minutes). Dampening is applied only to EBGP neighbors, not to IBGP neighbors.

BGP dampening is off by default; the following BGP command turns on dampening:

  router bgp 109   bgp dampening  

Cisco IOS Software allows dampening parameters to be changed and are defined as follows:

  router bgp 1009   bgp dampening   half-life-time reuse suppress maximum-suppress-time  

Here, the value range for the options is as follows:

  • half-life-time Range is 1 to 45 minutes. Current default is 15 minutes.

  • reuse Range is 1 to 20,000. Default is 750.

  • suppress Range is 1 to 20,000. Default is 2000.

  • max-suppress-time Maximum duration that a route can be suppressed. Range is 1 to 255. Default is four times half-life-time.

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

Figure 15-22. Problem-Resolution Flowchart

graphics/15fig22.gif

Debugs and Verification

Figure 15-23 shows a simple EBGP setup between R1 and R2 in AS 109 and AS 110, respectively. R2 has advertised 100.100.100.0/24 to R1. To show how dampening works, R2 is made to flap 100.100.100.0/24 multiple times. Removing the route in R2's routing table and putting it back can simulate flapping. R1 receives these flaps and, if configured with dampening, assigns penalties per flap.

Figure 15-23. EBGP Setup to Demonstrate Route Dampening

graphics/15fig23.gif

Example 15-53 shows the necessary debugs run to observe the dampening feature in R1 running Cisco IOS Software.

Example 15-53 Observing the BGP Dampening Feature
 R1#  debug ip bgp dampening 1  R1#  debug ip bgp updates 1  access-list 1 permit 100.100.100.0 0.0.0.0 

Most of the BGP debugs can be run along with an access list to limit the output created by these debugs. Access list 1 is permitting only 100.100.100.0.

Example 15-54 shows the debug output and flap statistics in BGP output.

Example 15-54 Debugs to Verify Dampening of 100.100.100.0/24
 Dec 13 03:33:57.966 MST: BGP(0): 131.108.1.2 rcv UPDATE about 100.100.100.0/24 --  withdrawn  Dec 13 03:33:57.966 MST: BGP(0): charge penalty for 100.100.100.0/24 path 110 with         halflife-time 15 reuse/suppress 750/2000 Dec 13 03:33:57.966 MST: BGP(0):  flapped 4 times since 00:02:58  . New  penalty is 3838  R1#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 17 Paths: (1 available,  no best path)  Flag: 0x208   Not advertised to any peer   110, (  suppressed due to dampening  )     131.108.1.2 from 131.108.1.2 (10.0.0.3)       Origin IGP, metric 0, localpref 100, valid, external       Dampinfo: penalty 3793,  flapped 4 times in 00:03:13  , reuse in 00:35:00 

Highlighted debug and show command output shows that 100.100.100.0/24 has flapped four times in 3 minutes and 13 seconds. For each flap, a penalty of 1000 is assigned; because the suppress limit of 2000 has been exceeded, 100.100.100.0/24 is suppressed and removed from the routing table.

Solution

If R1 wants to reinstall 100.100.100.0/24, it can do the following:

  1. Wait for the penalty to go below the reuse limit (750).

  2. Remove dampening altogether from the BGP configuration.

  3. Clear the flap statistics.

Example 15-55 shows how the dampened path can be cleared and immediately get installed in the routing table. debug ip bgp update 1 is on to display the activity in the BGP process.

Example 15-55 Clearing BGP Dampening Through a Command Line with Debugs On
 R1#  clear ip bgp dampening 100.100.100.0   Dec 13 03:36:56.205 MST: BGP(0): Revise route installing 100.100.100.0/24   ->   131.108.1.2 to main IP table  

The output in Example 15-55 came from debug ip bgp update 1 running to display activity of 100.100.100.0/24 going into the IP routing table. Example 15-56 shows the final BGP routing table entries.

Example 15-56 BGP Routing Table Entries
 R1#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 18 Paths: (1 available, best #1, table Default-IP-Routing-Table)  Flag: 0x208   Not advertised to any peer  110     131.108.1.2 from 131.108.1.2 (10.0.0.3)       Origin IGP, metric 0, localpref 100, valid, external, best R1#  show ip route 100.100.100.0  Routing entry for 100.100.100.0/24   Known via "bgp 109", distance 20, metric 0   Tag 110, type external   Last update from 131.108.1.2 00:02:45 ago   Routing Descriptor Blocks:   * 131.108.1.2, from 131.108.1.2, 00:02:45 ago       Route metric is 0, traffic share count is 1       AS Hops 1, BGP network version 0 

EBGP-Learned Route Not Getting Installed in IP Routing TableCause: BGP Next Hop Not Reachable in Case of Multihop EBGP

In a multihop EBGP session, EBGP speakers are not directly connected. Peering between loopback addresses of adjacent routers also is considered multihop.

This problem of an EBGP multihop route not getting installed in an IP routing table is identical to the IBGP next hop issue; however, most of the commonly seen problems occur when the router fails to resolve the next-hop address to an interface.

In this problem, the multihop EBGP next hop is reachable through a BGP route whose next hop is again the original multihop BGP next hop. For example, to reach prefix A, the next hop is prefix B; to reach prefix B, the next hop is again B. This is considered a recursion problem in which a router cannot resolve to an interface to reach the next hop B.

Figure 15-24 shows how R2 will not install routes from R1 whose next hop cannot be resolved to an interface.

Figure 15-24. R2 Fails to Install Routes from R1 Because of Next Hop/Interface Resolution

graphics/15fig24.gif

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

Figure 15-25. Problem-Resolution Flowchart

graphics/15fig25.gif

Debugs and Verification

R1 and R2 are peering to each other's Loopback addresses. R1 is advertising 100.100.100.0/24 to its multihop EBGP neighbor R2 with a next hop of 131.108.10.1.

R2 has a default route that it uses to form a BGP neighbor relationship with R1, but failure to resolve the next hop to an interface results in routes not getting installed in the routing table.

Example 15-49 shows that R2 is receiving 100.100.100.0/24 from R1 with the next hop of 131.108.10.1. However, this next hop is advertised by R1 to R2 only through BGP. Notice in the output of Example 15-57 that the next hop for BGP update of 131.108.10.1/32 is 131.108.10.1. R2 can never resolve the reachability for 131.108.10.1 through any physical interface. In Cisco IOS Software, BGP can detect this behavior and marks 100.100.100.0/24 as an unacceptable route to go in Best Path calculation and thus never go in the IP routing table.

Example 15-57 EBGP Multihop Will Not Be Capable of Resolving the Next Hop
 R2#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x208   Not advertised to any peer   109  131.108.10.1  from 131.108.10.1 (131.108.10.1)       Origin IGP, metric 0, localpref 100, valid, external, best R2#  show ip bgp 131.108.10.1  BGP routing table entry for 131.108.10.1/32, version 5 Paths: (1 available, no best path) Flag: 0x208   Not advertised to any peer   109  131.108.10.1 (inaccessible)  from 131.108.10.1 (131.108.10.1)       Origin IGP, metric 0, localpref 100, valid, external R2#  show ip route 131.108.10.1  Routing entry for 131.108.10.1/32   Known via "bgp 110", distance 20, metric 0   Tag 109, type external   Last update from 131.108.10.1 00:00:38 ago   Routing Descriptor Blocks:  * 131.108.10.1  , from 131.108. 10.1,  00:00:38  ago       Route metric is 0, traffic share count is 1       AS Hops 1 R2#  show ip route 131.108.10.1  Routing entry for 131.108.10.1/32   Known via "bgp 110", distance 20, metric 0   Tag 109, type external   Last update from 131.108.10.1 00:00:38 ago   Routing Descriptor Blocks:  * 131.108.10.1  , from 131.108. 10.1,  00:00:04  ago       Route metric is 0, traffic share count is 1       AS Hops 1 

Note the time stamp in IP route output; it is resetting every minute.

This route in Example 15-57 will keep coming and going every minute as the Cisco IOS Software BGP scanner process detects such inconsistencies in the BGP next hop and removes that route.

Solution

The solution to this problem based on this cause is to simply have a more specific route for the next-hop address. In the case of EBGP, this is commonly done by having a static route for the multihop EBGP peering address.

This instance is observed in the case of multihop EBGP sessions when the next-hop address is not directly connected and the IP routing table must have an explicit route to the next-hop address.

The simple solution lies in creating a static route from R2 to reach the R1 loopback, which is the next hop of all prefixes advertised by R1 to R2. This can be done with the following command on R2:

  ip route 131.108.10.1 255.255.255.255 131.108.1.1  

The static route 131.108.10.1 is the loopback address of R1, and 131.108.1.1 is the physical interface address of R1.

EBGP-Learned Route Not Getting Installed in the Routing TableCause: Multiexit Discriminator (MED) Value Is Infinite

In Cisco IOS Software, if a multiexit discriminator (MED) is set to infinite 4294967295, the router will not install this route in the routing table.

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

Figure 15-26. Problem-Resolution Flowchart

graphics/15fig26.gif

Debugs and Verification

In Cisco IOS Software, an infinite MED in a BGP update makes it incapable of entering the routing table. This rare occurrence is typically the result of misconfiguration.

Example 15-58 shows the output of the BGP table for prefix 100.100.100.0/24. Notice the metric value of 4.29 billion, which Cisco IOS Software considers as infinite. Example 15-58 also shows how R2 can be configured to set the MED value equal to 4.29 billion. The infinite metric sometimes is used in route servers, which provide a mirror view of the Internet BGP table. Setting the metric to infinity prohibits such routes from going in the IP routing table, so no IP traffic will use those routes. This case is discussed here just to show a corner case of a BGP path not getting installed in the routing table. Such a configuration is not seen in real BGP networks.

Example 15-58 BGP Route Table for Prefix 100.100.100.0/24 Indicates a Metric Set to Infinity
 R2#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 0 Paths: (1 available, no best path)   Not advertised to any peer   1     172.16.126.1 from 172.16.126.1 (172.16.1.1)       Origin IGP, metric  4294967295  , localpref 100, valid, external R2#  show ip route 100.100.100.0  % Network not in table R2#  router bgp 2   no synchronization   neighbor 172.16.126.1 remote-as 1   neighbor 172.16.126.1 route-map SET_MED in  R2#  show route-map SET_MED  route-map SET_MED, permit, sequence 10   Match clauses:   Set clauses:     metric 4294967295   Policy routing matches: 0 packets, 0 bytes 
 < 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