Category: BGP

TL&DR: QPPB works in MPLS VPNs… with a few limitations (at least in Cisco IOS implementation).

And now for the long story: A while ago I’ve noticed that my LinkedIn friend Joe Cozzupoli changed his status to something like “trying to get QPPB to work in MPLS VPN environment”. I immediately got in touch with him and he was kind enough to send me working configurations; not just for the basic setup, but also for Inter-AS Option A, B and C labs.

Knowing that QPPB relies on CEF, I doubted it would work as well on VRF interfaces as it does in pure IP environments, so I decided to do a few tests of my own. Here are the limitations I found:

It looks like we’re bound to experience a widespread BGP failure once every few months. They all follow the same pattern:

• A “somewhat” undertested BGP implementation starts advertising paths with “unexpected” set of attributes.
• A specific downstream BGP implementation (and it could be a different implementation every time) a few hops down the road hiccups and sends a BGP notification message to its upstream neighbor.
• BGP session must be reset following a notification message; the routes advertised over it are lost and withdrawn, causing widespread ripples across the Internet.
• The offending session is reestablished seconds later and the same set of routes is sent again, causing the same failure and a session reset. If the session stays up long enough, some of the newly received routes might get propagated and will flap again when the session is reset.
• The cyclical behavior continues until a manual intervention.

I’ve sent a link to my Filter excessively prepended AS-paths article as an answer to a BGP route-map question to the NANOG mailing list and got several interesting questions from Dylan a few hours later. As they are pretty common, you might be interested in them as well.

In my environment, we are not doing full routes. We have partial routes from AS X and then fail to AS Y. Is their any advantage for someone like me to do this, as we are not providing any IP transit so we are not passing the route table to anyone else?

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.

For more details, read the What Exactly Happens after a Link Failure blog post.

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.

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

I’ve always thought that Cisco introduced the BGP Local-AS feature into IOS to support complex MPLS VPN design scenarios. Obviously I was wrong, the early documentation always describes an ISP AS merging scenario. Unfortunately, all the articles I’ve found skip some important details: they describe the basics and the configuration commands, but forget to mention the impact on the AS paths received by the ISP customers.

I described those details in an article that has disappeared from the Internet sometime in 2019, but fortunately archive.org retained a copy of it.

Would you like me to migrate that article to ipSpace.net? Send me a message and I just might do it...

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.