Martin Kluge sent me an interesting BGP question: he has two upstream links and runs BGP on both. Since his router is low on RAM, he cannot accept full routing, so he’s just announcing his IP prefix and using static default routing toward upstream ISPs.

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. This article describes the functionality and caveats of BGP default routing. All router configurations and printouts are taken from a sample network illustrated in the following diagram:

Internal BGP (IBGP) sessions (BGP sessions within your autonomous system) are identified by the neighbor’s AS number being identical to your AS number. While the external BGP (EBGP) sessions are usually established between directly connected routers, IBGP sessions are expected to be configured across the network.

The current best practice is to configure IBGP sessions between the loopback interfaces of the BGP neighbors, ensuring that the TCP session between them (and the BGP adjacency using the TCP session) will not be disrupted after a physical link failure as long as there is an alternate path toward the adjacent router.

The routing information you source into the public Internet with BGP should be as accurate and stable as possible. The best way to achieve this goal is to statically configure the IP prefixes you’ve been allocated on your core routers and advertise them into BGP:

• BGP will only advertise an IP prefix if a matching entry is found in the IP routing table. To ensure the IP prefix you want to advertise is always present, configure an IP static route to null interface, unless you're advertising a connected interface (example: Internet edge router on a DMZ segment).
• Most public IP prefixes advertised today do not fall on the classful network boundary. To advertise a classless prefix, you have to configure the prefix and the mask in the BGP routing process.

Configuring a large number of similar BGP peers on a router and ensuring that the changes in your routing policy or BGP design are applied to all of them can be a management nightmare. BGP peer groups were the only scalability tool available on Cisco IOS until the IOS release 12.3T and they had significant limitations as they were also used as a performance improvement tool.

IOS releases 12.0S and 12.3T introduced peer templates, a scalable hierarchical way of configuring BGP session parameters and inbound/outbound policies. For example, to configure the session parameters for all your IBGP sessions, use the following session template:

BGP route reflectors have been supported in Cisco IOS well before I started to develop the first BGP course for Cisco in mid 1990s. It’s a very simple feature, so I was pleasantly surprised when I started digging into it and discovered a few rarely known details.

The Basics

Route reflector is an IBGP feature that allows you to build scalable IBGP networks. The original BGP protocol (RFC 1771) contained no intra-AS loop prevention mechanism; routers were therefore prohibited from sending routes received from an IBGP peer to another IBGP peer, requiring a full-mesh of IBGP sessions between all BGP routers within an AS.

I thought I knew all there is to know about the AS-path prepending before the February 2009 incident, which prompted me to focus on this particular Cisco IOS feature.

For example, did you know you could do inbound AS-path prepending? I didn’t, until Rodney Dunn from Cisco mentioned it in an e-mail exchange. Did you ever wonder whether the AS-path prepending affects inbound or outbound AS-path filters? I had a hunch it doesn’t, but was never sure. Time to figure out all the gory details…

Following my IBGP or EBGP in an enterprise network post a few people have asked for a more graphical explanation of IBGP/EBGP differences. Apart from the obvious ones (AS path does not change inside an AS) and more arcane ones (local preference is only propagated on IBGP sessions, MED of an EBGP route is not propagated to other EBGP neighbors), the most important difference between IBGP and EBGP is BGP next hop processing.

This is a nice email I got from an engineer struggling with multi-homing BGP setup:

We faced a problem with our internet routers a few days back. The engineer who configured them earlier used the syntax: network x.x.x.x mask y.y.y.y route-map PREPEND to influence the incoming traffic over two service-providers.

... and of course it didn’t work.

I got a follow-up question to the Should I use 6PE or native IPv6 post:

Am I remembering correctly that if you run IPv6 native throughout the network you need to enable BGP on all routers, even P routers? Why is that?

I wrote about BGP-free core before, but evidently wasn’t clear enough, so I’ll try to fix that error.

Imagine a small ISP with a customer-facing PE-router (A), two PE-routers providing upstream connectivity (B and D), a core router (C), and a route reflector (R). The ISP is running IPv4 and IPv6 natively (no MPLS).