Category: BGP

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]

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).

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.

For more details watch ‌Upcoming Internet Challenges and Surviving the Internet Default Free Zone webinars.

We described EIGRP-in-VRF in MPLS and VPN Architectures, Volume II. 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.

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.

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.

Multihoming to a single ISP is a design scenario in which a customer uses multiple Internet connections to the same Internet Service Provider. This design provides resilience against link and device failures, but does not provide protection against major outages within the Service Provider network.

There are three major decisions to be made when designing multihoming to single ISP:

• Will the customer use provider-assigned or provider-independent address space?
• Should the customer use static or dynamic routing with the ISP?
• When using dynamic routing with BGP, does the customer need its own public autonomous system?

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.

One of the first things you have to do when configuring BGP with your ISP is to ensure you won’t become a transit AS. Decent ISPs filter out things that don’t belong to you from your updates, but not everyone cares (including some really big names), and so small organizations manage to bring down large parts of the Internet just with a few fat fingers.

Here’s the BGP configuration you should use on Cisco IOS: apply AS-path access-list to outbound updates with neighbor filter-list command:

In a previous post I've described how you can use neighbor local-as feature to fix AS-number mismatch between adjacent autonomous systems. However, without additional options, the local-as is inserted in the AS-path of incoming BGP updates before any inbound filters. Your inbound filters thus have to match the local-as as well.

Cisco documentation has always claimed there were four well-known communities (the Internet community being one of them), while the RFC 1997 lists three well-known values. Unfortunately, many people blindly copy the IOS documentation without asking themselves “what the heck is the Internet community”.

If you want to match IP address as well as the subnet mask of a BGP route, you can use extended IP access-lists to match both. The extended access-lists can be used in neighbor distribute-list in/out router configuration command or in a match ip address command within a route-map.

When I've included a few slides on this feature in the first BGP course I've developed for Cisco (that was probably somewhere around 1994), the results in the class were always the same: total confusion that needed an hour of whiteboard examples to dissolve. You can find a few examples that will help you understand this arcane feature in a post written by Brian Dennis.

The use of extended IP ACL as a route matching mechanism was made obsolete by the ip prefix-list command, which was introduced in 12.0T. As 12.0T reached End-of-Engineering in the previous millennium, it's a safe bet that the only place where you might still be required to use extended ACLs to match IP routes is in the CCIE lab.

When Kate Gerwig, my wonderful editor from SearchTelecom.com, and myself agreed on the contents of the “Building customer-resilient BGP networks” article, we had no idea that it would become extremely relevant just days before it was published. The article describes the tools a Service Provider should use to ensure that its customers cannot harm its BGP routing data (and consequently its other customers and the Internet at large).

On February 24th, someone in Pakistan decided to block local access to YouTube … and someone else decided that the best way to approach the problem was to block the whole world’s access to YouTube.