Do you have a good reason to use BGP aggregation?

For the last 10 years, I've been preaching that you should use static BGP prefix advertising (with the network mask router configuration command) to advertise your IP address space into the public Internet, not the BGP aggregation. I might see some use for BGP aggregation in enterprise networks (or MPLS VPN networks) using BGP as the core routing protocol with other routing protocols serving the edge, but I cannot find a good scenario where BGP aggregation in public Internet would be a good solution. Do you use BGP aggregation in your network? Do you have a good scenario that you'd like to share with us? Write a comment.

BGP route reflector details

BGP route reflectors have been supported in Cisco IOS well before I started to develop the first BGP course for Cisco more than a decade ago (one of the early ABCT course descriptions is still available online thanks to the Wayback machine). It’s a very simple feature, so I was pleasantly surprised when I started digging into it and discovered a few rarely known details. Read all about the BGP route reflector details in the article I wrote in the CT³ wiki.

Unequal-bandwidth EBGP load balancing

EIGRP was always described as the only routing protocol that can do unequal-cost load sharing. As it turns out, BGP is another one (although it's way more limited than EIGRP). For example, if you have two links into a neighbor AS, you can load-share across them proportionally to their bandwidth. You can find all the details, sample configurations and router printouts in the CT³ wiki.

Next-hop fixup in partially-meshed NBMA networks

Shahid has sent me an interesting observation: he was running RIP in partially-meshed Frame Relay network and wanted to use static host routes to fix next-hop problems, but somehow they didn't work as expected. I ran a series of scenarios testing RIP, OSPF, EIGRP and BGP and found that some of the old tricks don't work any more. Furthermore, it's almost impossible to run RIP over partially-meshed NBMA network, as the default RIP next-hop processing messes up your routing table. The details are explained in the Next-hop fixup in partially-meshed NBMA networks article in the CT³ wiki.

This article is part of You've asked for it series.

How obscure can it get?: BGP IPv6 printouts

If you want to display any IPV6-related BGP objects (neighbors, routes …) you can use the familiar BGP commands, but have to prefix them with show ip bgp ipv6 unicast. For example, to display the BGP neighbors active in the IPv6 address family, you would use show ip bgp ipv6 unicast summary command. I doubt you like so much typing (I don't, just entering the IPv6 addresses is enough for me); luckily Cisco IOS has aliases - just configure alias exec bgpv6 show ip bgp ipv6 unicast and (for consistency) alias exec bgpv4 show ip bgp ipv4 unicast.With these aliases, the BGP IPv6 maintenance and troubleshooting becomes almost enjoyable:

PE-C#bgpv6 summary ¦ begin Neighbor
Neighbor    V    AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down  State/PfxRcd
10.0.1.1    4 65000      18      21     11   0    0 00:12:49        2
10.0.1.2    4 65000      20      20     11   0    0 00:12:50        2
FEC0:C0FF:EE00::11:2
            4 65100     984    1086     11   0    0 16:16:33        2
PE-C#bgpv6 regexp 65100
BGP table version is 11, local router ID is 10.0.1.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> FEC0::1:3/128    FEC0:C0FF:EE00::11:2
                                            0             0 65100 i
*> FEC0:1:0:3::/64  FEC0:C0FF:EE00::11:2
                                            0             0 65100 i

Simple CLI extensions: handling special characters

Last week I've described how you can extend the exec-mode CLI commands with almost no knowledge of Tcl. A bit more work is required if your commands include Tcl special characters (quotes, braces or backslashes).

For example, to display all routes advertised by customers of AS X, you'd use the following show command: show ip bgp regexp _X_([0-9]+)(_\1)*$ (the regular expression is explained in the AS-path based filter of customer BGP routes post). This command cannot be entered as a Tcl string with variable substitution; Tcl would interpret the [ and \ characters. You could enter the whole command in curly braces, but then there would be no variable substitution that we need to insert command line parameters. To make Tcl happy, use the following Tcl commands:

1. set cmd {first-part-of-command} stores the command prefix into the cmd variable;
2. append cmd $argv appends the command line arguments to the command;
3. append cmd {rest-of-command} appends the rest of the IOS exec command;
4. puts [exec $cmd] executes the command and prints the results.

For example, the following code will display the customers of a BGP AS specified in the command line (after being stored in a flash file and defined in an alias, of course):

set cmd {show ip bgp regexp _}
append cmd $argv
append cmd {_([0-9]+)(_\1)*$}
puts [exec $cmd]

Multihomed EIGRP sites in MPLS VPN network

Deploying EIGRP as the PE-CE routing protocol in MPLS VPN networks is easy if all sites have a single PE-CE link and there are no backdoor links between the sites. Real life is never as simple as that; you have to cope with various (sometimes undocumented) network topologies. Even that would be manageable if the customer networks would have a clean addressing scheme that would allow good summarization (that happens once in a blue moon) or if the MPLS VPN core could announce the default route into the EIGRP sites (wishful thinking; the customer probably has one or more Internet exit points).

In the end, you’re left with two-way route redistribution between core MP-BGP and edge EIGRP, resulting in nightmarish scenarios (probably a good half of the blog posts of the CCIE candidates talk about redistribution horrors). Fortunately, Cisco implemented two extra features supporting EIGRP-to-MP-BGP redistribution: BGP cost community and BGP Site-of-Origin. The Multihomed MPLS VPN sites running EIGRP article I wrote in CT³ wiki describes how you can use both features to get a reliable network even when doing two-way redistribution.

Is Internet melting down?

A while ago I’ve read a post about the potential Internet meltdown by Michael Morris. He provided an amazingly accurate analysis of the facts … and ended with a wrong conclusion. To understand the whole issue, please thoroughly read his text in its entirety before proceeding.

Back? OK. As I said, his analysis was great, but the conclusions were wrong. Regardless of whether we use IPv4 (and advertise smaller and smaller prefixes) or IPv6, the problem is the same: everyone wants to have chunks of non-aggregatable provider-independent public address space (so you can freely move between Service Providers) and everyone advertises these PI prefixes to multiple service providers (because multihoming is so cheap these days). Even networks that are not multihomed today use their own PI address space and private AS numbers to connect to a single ISP, so they could get multi-homed in a second if they feel like it.

The growth of the Internet routing tables thus has nothing to do with the prefix sizes and version of IP, but with the requirements of the end-customers to have immediate capability to switch service providers at will. As long as this trend persists (and I cannot see it stopping, as Internet is considered a commodity these days), the routing tables will grow, regardless of whether we use IPv4 or IPv6 or CLNS or something not invented yet.

Simple EIGRP in MPLS VPN networks

A few days ago I've been involved in an interesting EIGRP-within-MPLS/VPN troubleshooting session. I wanted to reproduce the behavior in the lab, so I set up a simple EIGRP lab … and realized that it's been a while since we wrote the MPLS and VPN Architectures, Volume II, which covers EIGRP used as PE-CE routing protocol. To make things more interesting, a few details have changed in the meantime; you have to configure the following features to get EIGRP running within MPLS/VPN environment:

• The autonomous-system command within the VRF address family is mandatory, even if the VRF AS number matches the EIGRP process number.
• The default BGP-to-EIGRP redistribution metric has to be configured, otherwise remote EIGRP routes will not be redistributed even though they have EIGRP metric encoded in extended BGP communities.
• Things work best if you disable auto-summary on PE-routers.

You can find more details and complete configuration examples in the EIGRP in MPLS VPN networks article I wrote in the CT³ wiki.

BGP default route

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. The article I wrote in the CT³ wiki describes the functionality and caveats of BGP default routing.

Display locally originated BGP routes

Displaying the BGP routes originated in the local AS is simple: you just filter the BGP table with a regular expression matching an empty AS path. Displaying routes originated by the local router is tougher. You could use the fact that the local routes have the weight set to 32768:

PE-A#show ip bgp quote-regexp "^$" | inc Network|32768
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.1.1/32      0.0.0.0                  0         32768 i

This would work if you don’t play with BGP weights in network statements. If you’ve changed the weights, you should filter the routes based on the BGP next-hop: locally originated routes have the next-hop 0.0.0.0 and all other routes should have a non-zero BGP next-hop. To filter BGP routes based on the next-hop you have to:

• Define an access-list that matches desired next-hop (0.0.0.0)
• Define a route-map that uses the access-list to match IP next hop.
• Display BGP routes matched by a route-map.

A sample configuration and show command printout is included below:

ip access-list standard AllZeros
 permit 0.0.0.0
!
route-map NextHopSelf permit 10
 match ip next-hop AllZeros

PE-A#show ip bgp route-map NextHopSelf | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.1.1/32      0.0.0.0                  0         32768 i

To make this command simpler to use, define an alias: alias exec mybgp show ip bgp route-map NextHopSelf | begin Network.

BGP Templates on MPLS VPN PE-routers

BGP session and policy templates are a fantastic feature if you want to design scalable, easy to maintain BGP configurations. The IOS documentation doesn't even mention how they could be used in designs using multiple address families, for example in MPLS VPN networks; the article I wrote in the CT³ wiki should resolve any ambiguities.

Display BGP routes originated in the local AS

The easiest way to display BGP routes originating in the local autonomous system is to use the regular expression ^$ (empty AS-path) in the show ip bgp regexp command, for example:

PE-A#show ip bgp regexp ^$
BGP table version is 10, local router ID is 10.0.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.1.1/32      0.0.0.0                  0         32768 i
r>i10.0.1.2/32      10.0.1.2                 0    100      0 i

If you want to apply a show filter to the printout of this command, you have to use the quote-regexp variant; otherwise the rest of the line is interpreted as regular expression. To skip the header explaining the BGP status code (we know them by heart by now, don’t we?), use …

PE-A#show ip bgp quote-regexp "^$" | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.1.1/32      0.0.0.0                  0         32768 i
r>i10.0.1.2/32      10.0.1.2                 0    100      0 i

… and end with the eye candy – define this command as an alias: alias exec localbgp show ip bgp quote-regexp "^$" | begin Network.

Use the explicit "address-family ipv4" in BGP configurations

If you use multiprotocol BGP (MP-BGP) in your network to support MPLS VPN, IPv6 or IP Multicast over BGP, it's best if you go all the way and configure an explicit ipv4 address family; the resulting BGP configuration is significantly easier to read and understand as the session-specific parameters are clearly separated from the routing-specific parameters and the IPv4 settings are nicely grouped in an explicit section.

To change the format of the BGP configuration, configure the IPv4 address family with the address-family ipv4 unicast router configuration command (the neighbor statements and other configuration settings pertinent to IPv4 configuration are automatically moved into the new address family) or manually activate a BGP neighbor for IPv4 route exchange with the neighbor activate router configuration command.To illustrate the differences between the traditional BGP configuration and the per-address-family configuration, consider a simple MPLS VPN+Internet setup. First the traditional approach:

router bgp 65000
 template peer-policy Internal
  send-community both
 exit-peer-policy
 !
 template peer-session Internal
  remote-as 65000
  update-source Loopback0
 exit-peer-session
 !
 no synchronization
 bgp log-neighbor-changes
 network 10.0.1.1 mask 255.255.255.255
 neighbor 10.0.1.5 inherit peer-session Internal
 neighbor 10.0.1.5 description PE-C(RR)
 neighbor 10.0.1.5 inherit peer-policy Internal
 no auto-summary
 !
 address-family vpnv4
  neighbor 10.0.1.5 activate
  neighbor 10.0.1.5 send-community extended
 exit-address-family

... and the changed configuration after the address-family ipv4 command has been entered:

router bgp 65000
 template peer-policy Internal
  send-community both
 exit-peer-policy
 !
 template peer-policy InternalV6
  send-label
  inherit peer-policy Internal 1
 exit-peer-policy
 !
 template peer-session Internal
  remote-as 65000
  update-source Loopback0
 exit-peer-session
 !
 bgp log-neighbor-changes
 neighbor 10.0.1.5 inherit peer-session Internal
 neighbor 10.0.1.5 description PE-C(RR)
 !
 address-family ipv4
  no synchronization
  network 10.0.1.1 mask 255.255.255.255
  neighbor 10.0.1.5 activate
  neighbor 10.0.1.5 inherit peer-policy Internal
  no auto-summary
 exit-address-family
 !
 address-family vpnv4
  neighbor 10.0.1.5 activate
  neighbor 10.0.1.5 send-community extended
 exit-address-family

Policy Routing with BGP Quick Learning Module

Our developers have just released the BGP Policy Routing E-Lesson that accompanies the Scalable Policy Routing IP Corner article. The lesson contains an instructor-led presentation that explains the concepts and a remote lab where you configure and test the solution without endangering the operations of your live network.

If you'd like to review the e-lesson and write/blog about it and the concept of short e-learning modules covering very specific technologies or design scenarios, send me a message describing what you'd like to do and I'll organize the access to the e-lesson for you.

Conditional BGP route origination

Sebastian Majewski has found an interesting feature: if you use the network route-map BGP configuration command to originate BGP prefixes and use the match conditions within the route-map, BGP inserts the IP prefix in the BGP table only if the source route in the IP routing table satisfies the route-map conditions. More details and a sample router configuration are available in CT³ wiki.

Multihoming to a single ISP

A while ago Greig asked an interesting question:

Would it be possible to explain in detail a scenario where dual-as and as-overide is being used and another scenario where dual-as (using no-prepend / replace-as), as-overide and remove-private-as are used?

I decided to start from the last item. The neighbor remove-private-as option is used in scenarios where you run BGP between public and private AS numbers to collect IP prefixes and advertise these prefixes to the rest of the world as belonging to the public AS. The most common design in this category is multihoming to a single ISP.

This article is part of You've asked for it series.

BGP load sharing across multiple AS-paths

Sebastian Majewski has contributed a short article to the CT³ Wiki explaining a hidden Cisco IOS router configuration command that can bypass the limitations of the IBGP multipath load sharing in scenarios where the paths across which you want to load-share cross different upstream autonomous systems.

Scalable Policy Routing

If “policy routing” reminds you of nightmarish spaghetti solutions of hop-by-hop route-maps, read my latest IP Corner article, Scalable Policy Routing. It describes how you can use a distance vector routing protocol (BGP is used in the article, but you could do the same with EIGRP or even RIP) to solve common policy routing problems in a highly scalable way.

A bug in the IOS “section” filter

The section filter of the show commands contains a nasty bug (at least in the IOS release 12.4T) in IOS release 12.2SRC: if a line in the section matches the same regular expression as the section header, the rest of the section is not printed.I guess this sounds a bit perplexing, so here's an example. When using the router bgp regular expression in a section filter appended to the show running command, the whole BGP configuration is displayed:

PE-A#show run ¦ section router bgp
router bgp 65000
 template peer-policy Internal
  send-community both
 exit-peer-policy
 !
 template peer-session Internal
  remote-as 65000
  update-source Loopback0
 exit-peer-session
 !
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.0.1.5 inherit peer-session Internal
 neighbor 10.0.1.5 description PE-C(RR)
 neighbor 10.0.1.5 inherit peer-policy Internal
 no auto-summary
 !
 address-family vpnv4
  neighbor 10.0.1.5 activate
  neighbor 10.0.1.5 send-community extended
 exit-address-family

However, if you use bgp as the regular expression, the printout starts with the router bgp command, but stops abruptly after the first line containing the string bgp, skipping the rest of the section:

PE-A#show run ¦ section bgp
router bgp 65000
 template peer-policy Internal
  send-community both
 exit-peer-policy
 !
 template peer-session Internal
  remote-as 65000
  update-source Loopback0
 exit-peer-session
 !
 no synchronization
 bgp log-neighbor-changes