The Border Gateway Protocol routing information is usually exchanged between competing business entities -- Internet Service Providers (ISPs) -- in an open, hostile environment (public Internet). BGP is thus very security-focused (for example, all adjacent routers have to be configured manually), and decent BGP implementations provide a rich set of route filters to allow the ISPs to defend their networks and control what they advertise to their competitors.
In BGP terminology, an independent routing domain (which almost always means an ISP) is called an autonomous system.
BGP is always used as the routing protocol of choice between ISPs (external BGP) but also as the core routing protocol within large ISP networks (internal BGP).
All other routing protocols are concerned solely with finding the optimal path toward all known destinations. BGP cannot take this simplistic approach because the peering agreements between ISPs almost
- AS path -- the complete path documenting which autonomous systems a packet would have to travel through to reach the destination.
- Local preference -- the "internal cost" of a destination, used to ensure AS-wide consistency.
- Multi-exit discriminator -- this attribute gives adjacent ISPs the ability to prefer one peering point over another.
- Communities -- a set of generic tags that can be used to signal various administrative policies between BGP routers.
As the focus of BGP design and implementation was always on security and scalability, it's harder to configure than other routing protocols, more complex (more so when you start configuring various routing policies), and one of the slowest converging routing protocols.
The slow BGP convergence dictates a two-protocol design of an ISP network:
- An internal routing protocol (most often, OSPF or IS-IS) is used to achieve fast convergence for internal routes (including IP addresses of BGP routers).
- BGP is used to exchange Internet routes.
A failure within the core network would thus be quickly bypassed thanks to fast convergence of OSPF or IS-IS, whereas BGP on top of an internal routing protocol would meet the scalability, security and policy requirements. Even more, if you migrate all your customer routes into BGP, the customer problems (for example, link flaps between your router and customer's router) will not affect the stability of your core network.
Because of inherent BGP complexity, customers and small ISPs would deploy BGP only where needed, for example on peering points and a minimal subset of core routers (the ones between the peering points), as shown in the following diagram.
The BGP-speaking routers would also have to generate a default route into the internal routing protocol to attract the traffic for Internet destinations not known to other routers in your network.
As your ISP business grows, however, your customers will start requiring BGP connectivity (any customer who wants to achieve truly redundant Internet access has to have its own AS and exchange BGP information with its ISPs), and you'll be forced to deploy BGP on more and more core and edge routers (see the following picture). It's therefore best that you include BGP on all core and major edge routers as part of your initial network design. Even though you might not deploy it everywhere with the initial network deployment, having a good blueprint will definitely help you when you have to scale the BGP-speaking part of your network.
BGP requires a full mesh of internal BGP sessions (sessions between routers in the same autonomous system). You could use BGP route reflectors or BGP confederations to make your network scalable.
There is also another excellent reason why you'd want to deploy BGP throughout your network: Novel network service, for example MPLS-based virtual private networks (VPNs), large-scale quality-of-service deployments, or large-scale differentiated Web caching implementations rely on BGP to transport the information they need.
About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting, and operating large service provider and enterprise WAN and LAN networks and is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. You can read his blog here: http://ioshints.blogspot.com/index.html.
This was first published in June 2007