Category: BGP

You've probably already heard the phrase "When the only tool you have is a hammer, everything looks like a nail" (and seen people acting according to it). Likewise, if you have an IOS release with EEM support, a lot of things that would require smart design could be solved in a brute-force way with a few EEM applets. For example, the problem of the BGP default route could be solved “easily” with a few applets that track syslog messages reporting when the BGP neighbors go up/down.

Sometimes you'll see a weird route status (RIB-failure) in your BGP table, for example:

GW#show ip bgp ¦ include r>
r> 10.2.0.0/16      10.0.1.2                 0             0 65001 i

A more thorough investigation of the BGP entry does not give you a lot of additional information:

GW#show ip bgp 10.2.0.0
BGP routing table entry for 10.2.0.0/16, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
Flag: 0x820
  Advertised to update-groups:
        1    2
  65001
    10.0.1.2 from 10.0.1.2 (10.0.1.2)
      Origin IGP, metric 0, localpref 100, valid, external, best

The “mistery” is solved when you inspect the entry in the IP routing table:

GW#show ip route 10.2.0.0
Routing entry for 10.2.0.0/16
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1

The GW router has a static route that collides with the EBGP route and thus the BGP route cannot be inserted in the IP routing table (as the static route has administrative distance 1).

Let's conclude with a few interesting facts about the RIB failures:

• The RIB failure feature was introduced in IOS release 12.2T; prior to that, the BGP routes with higher administrative distance than other route sources were silently ignored (similar to all other routing protocols).
• You can display BGP routes that are not inserted in the IP routing table with the show ip bgp rib-failure command, which also explains why the BGP route was not inserted in the IP routing table.
• The BGP routes that are not used due to higher administrative distance are still advertised to all BGP peers (contrary to what most other distance-vector routing protocols do), unless you configure bgp suppress-inactive (introducted in 12.2T and 12.0(26)S).

You might have been there before: the BGP neighbor becomes reachable after you fix a fault in the network, but the BGP session takes “forever” to be established (actually, the hold off is less than a minute, but time is running slower when you are waiting for the network to recover). However, when testing the BGP fast peering session deactivation, I made an interesting discovery: the restart time is improved as well; as soon as the path to the BGP neighbor appears in the IP routing table, the BGP session is established. The debugging printouts from my router are included below (I've used neighbor 10.0.3.3 fall-over configuration command):

03:28:42: RT: add 10.0.3.3/32 via 10.2.0.2, ospf metric [110/75]
03:28:42: RT: NET-RED 10.0.3.3/32
03:28:44: RT: Try lookup less specific 10.0.3.3/32, default 1
03:28:44: RT: Found subnet on less specific 10.0.3.3/32
03:28:44: %BGP-5-ADJCHANGE: neighbor 10.0.3.3 Up

Designing and operating large BGP networks has always been a challenge, as you have to deploy BGP on all core routers and design a hierarchy of internal BGP routers to get around the full-mesh limitation. When MPLS was introduced, it gave us means of deploying BGP only on the network edges, with the core routers carrying just the information about the BGP next hops.

As I know some of you run large networks, could you help me understand what you're using (without giving away too much information, of course):

• Are you running a BGP network without MPLS or are you using BGP on the edges and MPLS transport in the core?
• If you have a large number of BGP routers, do you have a nice hierarchy of BGP route reflectors (or confederations) or ad-hoc implementation where every router has all neighbors as RR-clients?

Full disclosure: I might use the information you give me in an upcoming article.

We all know that BGP is meant to converge slowly… well, the MPLS/VPN service providers tend to disagree, as their users are not used to minute-long convergence times. One of the major components of slow BGP convergence is the time it takes a router to discover that a neighbor has disappeared. Traditionally, the BGP keepalive packets were sent every minute and it took up to three minutes to discover that a neighbor is down.

Of course you could fine-tune those times with the neighbor timers configuration command, but the reduced timers resulted in increased TCP traffic and consequently increased CPU load, which could reach tens of percents if the timers were set to a few seconds and the router had lots of BGP neighbors.

The primary mission of Border Gateway Protocol (BGP) (transport of Internet routing between ISPs) has influenced the implementation of BGP default route origination, advertisements and propagation. This article describes the functionality and caveats of BGP default routing. All router configurations and printouts are taken from a sample network illustrated in the following diagram:

Default Route Origination in BGP

Contrary to some other routing protocols, you cannot redistribute default route (0.0.0.0/0) from the IP routing table into BGP.

For example, if PE-A has a static default route …

PE-A#show ip route static | begin Gateway
Gateway of last resort is 10.0.7.6 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 10.0.7.6
      10.0.0.0/8 is variably subnetted, 31 subnets, 3 masks
S 10.2.17.0/24 [1/0] via 10.0.1.6

… and you have configured redistribution of static routes into BGP …

router bgp 65000
 address-family ipv4
  network 10.0.1.1 mask 255.255.255.255
  redistribute static

… the default route will not appear in the BGP table (but all other static routes will).

PE-A#show ip bgp | include Network|32768
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.1.1/32      0.0.0.0                  0         32768 i
*> 10.2.17.0/24     0.0.0.0                  0         32768 ?

To originate the default route into the BGP table you should use the network statement:

router bgp 65000
 address-family ipv4
  network 0.0.0.0

After the network statement for the default route has been configured, BGP inserts the prefix 0.0.0.0/0 into the BGP table:

PE-A#show ip bgp | include Network|32768
BGP table version is 13, local router ID is 10.0.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-fa              
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          0.0.0.0                  0         32768 i
*> 10.0.1.1/32      0.0.0.0                  0         32768 i
*> 10.2.17.0/24     0.0.0.0                  0         32768 ?

Default Route Propagation

Once the default route has been inserted in the BGP table, the router propagates it like any other IP prefix. For example, after the default route has been inserted in the BGP table of PE-A, it’s automatically propagated to Site-A. The following printout also illustrates that the Site-A router has received the default route from PE-A as well as through PE-B and Site-B routers; the default route is thus propagated on IBGP and EBGP sessions.

Site-A#show ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 13
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
        1
  65000
    10.0.8.2 from 10.0.8.2 (10.0.1.4)
      Origin IGP, localpref 100, valid, internal
  65000
    10.0.7.5 from 10.0.7.5 (10.0.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, best

Default Route in Outbound Advertisement

In most design scenarios, you’d like to advertise the BGP default route to EBGP neighbors without having a BGP default route in your own BGP table. For example, an ISP might decide to advertise only the BGP default route and local BGP networks to customers multi-homed to a single ISP. To advertise a BGP default route to a BGP neighbor, use the neighbor default-originate router configuration command.

For example, when the IP prefix 0.0.0.0/0 is removed from the BGP table with the no network command and the default route advertisement is configured on EBGP session from PE-A to Site-A …

router bgp 65000
 address-family ipv4
  no network 0.0.0.0
  neighbor 10.0.7.6 default-originate

… Site-A still receives the default route.

Site-A#show ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 16
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
        1
  65000
    10.0.7.5 from 10.0.7.5 (10.0.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, best

Conditional Default Route Advertisement

The unconditional default route advertisement from PE router to CE routers could lead to traffic black holes. If PE-A loses connectivity to the network core (see the next diagram) but still advertises the default route to Site-A, it will attract the traffic from AS 65100 and subsequently drop it due to failed uplink. It’s thus best to configure conditional advertising of the BGP default route to BGP neighbors.

In the sample network, the presence of the IP prefix 10.0.1.8/32 originated in AS 65104 indicates that the core network is available. To configure conditional BGP default route advertisement, you have to:

• Configure an IP access list or IP prefix list that exactly matches the desired IP prefix in the IP routing table.

ip prefix-list CoreNet seq 5 permit 10.0.1.8/32

• Configure a route map using the access list or prefix list to match the IP prefix. The route map can contain other match clauses. In our example, it also matches the AS path with an AS-path access list:

route-map Default_From_65104 permit 10
 match ip address prefix-list CoreNet
 match as-path 100
!
ip as-path access-list 100 permit _65104$

• Configure conditional advertising of the default route with the neighbor default-originate route-map configuration command.

router bgp 65000
 address-family ipv4
  neighbor 10.0.7.6 default-originate route-map Default_From_65104

Martin Kluge sent me an interesting BGP question: he has two upstream links and runs BGP on both. Since his router is low on RAM, he cannot accept full routing, so he’s just announcing his IP prefix and using static default routing toward upstream ISPs.