Category: BGP

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?

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

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.

Petr Lapukhov describes an interesting scenarion in his post BGP Time-Based Policy Routing: a multi-homed customer that uses one upstream link (for example, more reliable but slower one) during the work hours, switching to the other upstream link (faster, less reliable) after that.

He uses BGP communities to achieve the switch (perfect solution if your ISP supports them) and time-based ACL in a route-map to set the community based on time-of-day. As Cisco changed the way BGP imports local routes in IOS release 12.3T, he then devises an ingenious solution based on reliable static routing to trigger a change in the IP routing table.

The optimum solution is way simpler: you just configure two EEM applets to perform clear ip route network command at appropriate times.

BGP implementation on Cisco IOS gives you a number of filtering options, including prefix filters, AS path filters and route maps. While it might be tempting to learn just the most versatile tool available (route maps) and discard all the others, judicious use of all available tools can simplify your router configurations.

For example, an Internet Service Provider might want to filter incoming updates received from the customers to ensure they’re not advertising transit routes and advertise only IP prefixes they actually own. Inbound route maps might also be needed to attach BGP communities to inbound routes or set BGP attributes (for example, local preference) based on communities attached to incoming routing updates.

Any serious (or at least security-aware) ISP should not blindly accept BGP routes from its customers but at the very minimum do some sanity checks on them. For example, if a multi-homed customer is clumsy enough to advertise BGP routes between service providers, it’s nice if you still stop him from turning into a transit AS. The required filter is conceptually quite simple: all the BGP routes from the customer should contain only his AS number in the AS-path.

The initial non-scalable approach is obvious: accept only the AS paths that have exactly the customer’s AS number in the AS path. For example, if your customer’s AS number is 65001, you could use this filter: ip as-path access-list 100 permit ^65001$.