BGP is a protocol designed to ease the interactions of large-scale IP networks (ex. The Internet). Much more information is available if you Google for Avi Freedman.
The Border Gateway Protocol performs routing services internal to and between autonomous systems. An autonomous system is, in this discussion, an IP network under the control of a single individual or organization. BGP is, as other noders have said, the glue that holds the Internet together. It is responsible for all hierarchical routing on the Internet and is the protocol used by Internet providers to exchange dynamic routing information with each other.
BGP advertises routes to neighbors (also called peers). These routes consist of the IP prefix and length (also called mask - yes, the same as a subnet mask). Attached to these routes are attributes that define details about the route. BGP primarily uses an attribute called the AS_PATH in its path determination algorithm, but it can (and does) use several additional attributes.
Types of routes
You may often hear network engineers talking about a full or partial route table. "Full routes" mean routes for the whole Internet; "partial routes" may mean routes only to certain destinations. You can further classify (or use similar terminology) routes into peering and transit routes. Transit routes offer you connectivity to the whole Internet; peering routes only to a certain network. When someone talks about peering, they're usually talking about finding themselves preferential access to certain network(s).
What kind of protocol is it?
Since BGP uses an AS_PATH for path determination, it is described as a path vector protocol. This is similar to a distance vector protocol, like RIP or EIGRP - hop count is used as the metric there. BGP's hops are autonomous systems that the route (and the data) will transit. If you advertise a route to your peer, you are promising that you have the ability to deliver the data. This promise will be repeated, given certain criteria, to all your peers, and they will repeat it to their peers. Each "promise" will be tagged with information which supports it.
How does it work?
When BGP is operating to do inter-autonomous system routing (eBGP), it tries to advertise routes wherever possible. When it is operating within an autonomous system, it will never readvertise routes -- although there are ways to get around this rule, such as route reflectors and confederations. This means that for BGP to work within an autonomous system (iBGP) your BGP relationships have to be fully meshed. So, be aware of this when you are speaking BGP to people outside your internetwork: BGP, the protocol, will allow you to make gross misconfigurations and you will advertise those misconfigurations to your peers. It does not protect you from yourself. This has led to several Internet routing collapses. Make sure you know what you're doing.
BGP maintains copies of two databases when its process is running. These databases are called Adj-RIB-In and Adj-RIB-Out. They contain incoming and outgoing routes, respectively. When a route is selected by BGP, it is inserted into the forwarding table of the router.
BGP uses the following criteria as part of its determination process, as well as some additional information:
- WEIGHT. Prefer the path with the largest. Weight is a Cisco-specific parameter, local to the router upon which it is configured.
- LOCAL_PREF. Prefer the path with the largest.
- Origination point. If the path was originated locally, or via redistribution from an IGP, prefer this path. Paths sourced by the network or redistribute commands are preferred above paths generated via the aggregate-address command.
- AS_PATH. Prefer the path with the shortest AS_PATH. This can be turned off on some BGP implementations.
- Origin type. IGP, EGP, and incomplete, in that order. Lowest first.
- Multi-exit discriminator. Prefer the path with the lowest. Typically, this is only compared for paths that originate from the same autonomous system, but it can be utilized for somewhat effective routing control as long as a good relationship exists between your multiple transit providers
.
- External over internal. Since BGP is primarily used as an external routing protocol, prefer externally-originated path over internally-originated paths.
- Lowest metric to next hop. The next hop in BGP is generated by the advertising router. You must be able to reach this router in some way for your packet to be delivered appropriately; typically you know how to reach this router via a static route or a route advertised by an IGP.
- Multiple paths. BGP can insert multiple paths for a given route into the routing table if you tell it to.
- Multiple paths, part II. Use the path that you got first if they're both equal. This allows you to reduce churn.
- Use the router ID as a tiebreaker.
So, what about route reflectors and confederations?
A route reflector is a tool in BGP used to get around the full mesh behavior of iBGP. Routes are sent to a single route server or machine, and "reflected" or rebroadcasted to route reflector clients. This allows every router to peer with the reflector, as opposed to peering with every other router on the internetwork.
Confederations are a tool for creating clouds of private autonomous systems which communicate with each other. This allows you to keep internetwork size down and control routing advertisements in a manner similar to the area concept in OSPF.
Policy control
BGP includes several mechanisms for control of incoming and outgoing routes. These include communities, prefix maps, route maps, etc. A detailed discussion of these mechanisms is better left to a face-to-face discussion with another network engineer, or by reading Bassam Halabi's excellent book, Internet Routing Architectures, Cisco Press.
Summary
BGP is a protocol used for IP routing within or external to an autonomous system. It is the sole protocol used to perform interdomain hierarchical routing. It allows control over path distribution, both incoming and outgoing, and a highly evolved route selection mechanism. It is not without its problems, but until something better comes along, it's all we've got.
(Some information derived from the Cisco TAC sections on BGP.)