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.

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

Internal BGP (IBGP) sessions (BGP sessions within your autonomous system) are identified by the neighbor’s AS number being identical to your AS number. While the external BGP (EBGP) sessions are usually established between directly connected routers, IBGP sessions are expected to be configured across the network.

The current best practice is to configure IBGP sessions between the loopback interfaces of the BGP neighbors, ensuring that the TCP session between them (and the BGP adjacency using the TCP session) will not be disrupted after a physical link failure as long as there is an alternate path toward the adjacent router.

The routing information you source into the public Internet with BGP should be as accurate and stable as possible. The best way to achieve this goal is to statically configure the IP prefixes you’ve been allocated on your core routers and advertise them into BGP:

• BGP will only advertise an IP prefix if a matching entry is found in the IP routing table. To ensure the IP prefix you want to advertise is always present, configure an IP static route to null interface, unless you're advertising a connected interface (example: Internet edge router on a DMZ segment).
• Most public IP prefixes advertised today do not fall on the classful network boundary. To advertise a classless prefix, you have to configure the prefix and the mask in the BGP routing process.

Configuring a large number of similar BGP peers on a router and ensuring that the changes in your routing policy or BGP design are applied to all of them can be a management nightmare. BGP peer groups were the only scalability tool available on Cisco IOS until the IOS release 12.3T and they had significant limitations as they were also used as a performance improvement tool.

IOS releases 12.0S and 12.3T introduced peer templates, a scalable hierarchical way of configuring BGP session parameters and inbound/outbound policies. For example, to configure the session parameters for all your IBGP sessions, use the following session template:

router bgp 65001
 template peer-session IBGP
  remote-as 65001
  description IBGP peers
  password s3cr3t
  update-source Loopback0

After the session template has been configured, adding a new IBGP peer takes just a single configuration command (two if you want to add neighbor description):

router bgp 65001
 neighbor 10.0.1.2 inherit peer-session IBGP
 neighbor 10.0.1.2 description R2

Policy templates are similar to session templates, and contain neighbor parameters that influence processing of prefixes of an individual BGP address family (example: filtering of inbound updates).

Continuing the IBGP example, you might want to group route reflector clients in a policy template, and ensure the route reflector propagating all BGP communities to them:

router bgp 65001
 template peer-policy Internal
  route-reflector-client
  send-community both
 exit-peer-policy

After defining a policy template, you can apply it to multiple address families, for example:

router bgp 65001
 neighbor 10.0.1.2 inherit peer-session IBGP
 neighbor 10.0.1.2 description R2
!
 address-family ipv4
  neighbor 10.0.1.2 activate
  neighbor 10.0.1.2 inherit peer-policy Internal
 exit-address-family
 !
 address-family vpnv4
  neighbor 10.0.1.2 activate
  neighbor 10.0.1.2 inherit peer-policy Internal

BGP route reflectors have been supported in Cisco IOS well before I started to develop the first BGP course for Cisco in mid 1990s. It’s a very simple feature, so I was pleasantly surprised when I started digging into it and discovered a few rarely known details.

The Basics

Route reflector is an IBGP feature that allows you to build scalable IBGP networks. The original BGP protocol (RFC 1771) contained no intra-AS loop prevention mechanism; routers were therefore prohibited from sending routes received from an IBGP peer to another IBGP peer, requiring a full-mesh of IBGP sessions between all BGP routers within an AS.

I thought I knew all there is to know about the AS-path prepending before the February 2009 incident, which prompted me to focus on this particular Cisco IOS feature.

For example, did you know you could do inbound AS-path prepending? I didn’t, until Rodney Dunn from Cisco mentioned it in an e-mail exchange. Did you ever wonder whether the AS-path prepending affects inbound or outbound AS-path filters? I had a hunch it doesn’t, but was never sure. Time to figure out all the gory details…

Following my IBGP or EBGP in an enterprise network post a few people have asked for a more graphical explanation of IBGP/EBGP differences. Apart from the obvious ones (AS path does not change inside an AS) and more arcane ones (local preference is only propagated on IBGP sessions, MED of an EBGP route is not propagated to other EBGP neighbors), the most important difference between IBGP and EBGP is BGP next hop processing.

This is a nice email I got from an engineer struggling with multi-homing BGP setup:

We faced a problem with our internet routers a few days back. The engineer who configured them earlier used the syntax: network x.x.x.x mask y.y.y.y route-map PREPEND to influence the incoming traffic over two service-providers.

... and of course it didn’t work.

I got a follow-up question to the Should I use 6PE or native IPv6 post:

Am I remembering correctly that if you run IPv6 native throughout the network you need to enable BGP on all routers, even P routers? Why is that?

I wrote about BGP-free core before, but evidently wasn’t clear enough, so I’ll try to fix that error.

Imagine a small ISP with a customer-facing PE-router (A), two PE-routers providing upstream connectivity (B and D), a core router (C), and a route reflector (R). The ISP is running IPv4 and IPv6 natively (no MPLS).