Category: BGP

Soon after I wrote the Designing Fast Converging BGP Networks article (you’ll find it somewhere in this list, one of my regular readers sent me an interesting problem: BGP sessions would be lost in his (IS-IS based) core network if he would use fall-over on IBGP neighbors and the BGP router would have a primary and a backup path to the IBGP neighbor.

It turned out to be an interesting side effect of aggressive route table purge following a link failure: the route to BGP neighbor was removed from the routing table before IS-IS ran SPF and installed an alternate route, and BGP decided it’s time to give up and terminate the session.

We all know that the global BGP table is exploding (see the Active BGP entries graph) and that it will eventually reach a point where the router manufacturers will not be able to cope with it via constant memory/ASIC upgrades (Note: a layer-3 switch is just a fancy marketing name for a router). The engineering community is struggling with new protocol ideas (for example, LISP) that would reduce the burden on the core Internet routers, but did you know that we could reduce the overall BGP/FIB memory consumption by over 35% (rolling back the clock by two and a half years) if only the Internet Service Providers would get their act together.

A few months ago, a small ISP was able to disrupt numerous BGP sessions in the Internet core by prepending over 250 copies of its AS number to the outbound BGP updates. While you should use the bgp maxas-limit command to limit the absolute length of AS-path in the inbound updates, you might also want to drop all excessively prepended BGP paths.

For more details, read the Filter Excessively Prepended BGP Paths article.

Cisco IOS allows up to 32 routing protocols contributing routes into a routing table (two of them are always connected and static). The limitation applies to the global routing table as well as to each individual VRF; the architectural reason for the limit is a 32-bit mask that’s used in Cisco IOS to mark individual routing protocols. The routing protocol ID (as displayed by the show ip protocol summary command) is thus limited to values 0 to 31. With value 0 being reserved for connected routes and value 1 for static routes, 30 values are left to number the routing protocols.

Due to the implementation details of Cisco IOS, the BGP, RIP and each EIGRP routing process consume routing protocol ID in all VRFs (regardless of whether they are used or not). You can view the IDs of individual routing protocols with the show ip protocol [vrf name] summary command.

A week ago AS13214 experienced internal problems and started readvertising all BGP routes (the whole Internet) as part of its autonomous system (AS). A similar incident occurred last November. In both cases, the problem did not spread very far, which indicates that the major ISPs have implemented BGP filters and prefix limits.

One can only hope that every ISP in the world would have done the same. If you’re an ISP and you haven’t configured the BGP maximum prefix feature on your customer BGP sessions yet, please do so ASAP. A good starting point would be a configuration example provided by Cisco (it’s also accessible from the Service Provider Security Best Practices).

I’ve got this question from Pete:

Which community will be sent if only "neighbor {ip-address} send-community" is configured?

Quick answer: only the standard BGP communities are propagated.

Here’s a weird requirement that you could get on a really hard CCIE preparation lab (and hopefully never in a live network): redistribute external OSPF routes from selected ASBRs into BGP without using a route map on the redistribution router.

For example, assuming R1 and R2 insert external routes into OSPF, you want only routes from R1 to be redistributed into BGP on R3, but you cannot use route maps on R3.

One of the readers of my BGP Route Reflectors article spotted an “obvious deviation from how we always though the route reflectors work”:

An IBGP route received from a route-reflector client is sent to all IBGP peers, including the client from which it was received.

A quick lab test confirmed the validity of my claims: a BGP route reflector does send an update back to the client from which it was received (and it’s perfectly legal according to the updated BGP Route Reflector RFC).

The Cisco IOS BGP Local-AS feature allows a BGP-speaking router to impersonate an autonomous system different from the one configured with the router bgp global configuration command. Its primary use facilitated seamless AS mergers; later additions made it applicable to AS renumbering scenarios. In the meantime, most other network operating systems implemented equivalent features (netlab can configure local AS functionality on over a dozen platforms)

The BGP Local-AS feature is usually configured with the neighbor IP-address local-as AS-number router configuration command. Subsequent IOS releases added the no-prepend keyword to clean up the AS path, as well as replace-as and dual-as keywords to support AS renumbering.

Multihop EBGP sessions are the traditional way to implement EBGP load balancing on parallel links. EBGP session is established between loopback interfaces of adjacent routers (see the next diagram; initial router configurations are included at the bottom of the article) and static routes (or an extra instance of a dynamic routing protocol) are used to achieve connectivity between loopback interfaces (BGP next-hops). The load balancing is an automatic result of the recursive route lookup of BGP next hops.