BGP Fundamentals

A Border Gateway Protocol (BGP) primer that provides an in-depth overview of each component of the BGP protocol.  BGP message types, the finite state machine and path attributes are discussed to provide the necessary knowledge of how the protocol works.

Introduction and Background

BGP Fundamentals

BGP first became an Internet standard in 1989 and was originally defined in RFC 1105.  It was then adopted as the EGP of choice for inter-domain routing.  The current version, BGP-4, was adopted in 1995 and is defined in RFC 1771.  BGP-4 supports Classless Inter Domain Routing (CIDR) and is the routing protocol that people use in today to route between autonomous systems.  

It has proven to be scalable, stable and provides the mechanisms needed to support complex routing policies. When people talk about “BGP” today, they implicitly mean BGP-4.  There is no need to specify the –4 version number because no one uses earlier versions, and very few vendors even still support them.

BGP continues to evolve through the Internet standards process work at the IETF, the latest draft version is draft-ietf-idr-bgp4-17.txt.  As the Internet routing requirements change, BGP is extended to continue to provide these knobs needed to control routing information and to support the new requirements.  The base RFC has been extended by several RFCs and I-Ds that define new features.

Riverstone’s RapidOS also continues to evolve, as we implement support for the latest extensions that are being defined.  For a full list of supported features by version, please consult the Appendix.

Protocol Mechanics

BGP uses TCP to establish a reliable connection between two BGP speakers on port 179.  Exactly one TCP session is established between each peer for each BGP session.  No routing information can be exchanged until the TCP session has been established.  This implies that each BGP speaker must have working IP connectivity between them first, which is usually provided by a directly connected interface or the IGP.  For added security, MD5 signatures can be used to authenticate each TCP segment.

We call BGP a path vector protocol, because it stores routing information as a combination of a destination and attributes of the path to that destination.  The protocol uses a deterministic route selection process to select the best route from multiple feasible routes, using the path attributes as criteria.  Characteristics such as delay, link utilization or router hops are not considered in this process.  The route selection process is key to understanding and implementing BGP policies and is discussed in its own section on the RS Routing Model.

Unlike most IGP protocols, BGP only sends a full routing update once when a BGP session is established and then only sends incremental changes.  BGP only recalculates routing information relative to these updates, there is no regular process that must update all of its routing information like the SPF calculations in OSPF or IS-IS.  

Although IGP convergence may be faster, an IGP will simply not scale to support the number of routes needed for inter-domain routing.  IGPs also lack the path attributes that BGP carries, which are essential for selecting the best route and building routing policies.  BGP is the only protocol that is suitable for use between autonomous systems, because of the inherent support for routing policies that the path attributes provide.  

These policies allow you to accept, reject or change routing information before it is used to make forwarding decisions.  This ability gives network operators a high degree of protection from accepting routing information they might not want, and the ability to control routing information according to their particular needs.  Neither OSPF or IS-IS provide policies to reject or change routing information, and thus should not be run between autonomous systems.

BGP runs in two modes: EBGP and IBGP.  EBGP (Exterior BGP) is run between different autonomous systems, and IBGP (Interior BGP) is run between BGP routers in the same autonomous system.  The behavior of the BGP speaker is different in each of these modes and these differences are further discussed in the Path Attributes section.

Message Types

Five message types are used by BGP to negotiate parameters, exchange routing information and indicate errors.  Each message can be between 19 and 4096 bytes long, and relies on TCP/IP for delivery, sequencing and fragmentation.  This implies that multiple BGP messages can be sent in one TCP segment.  A common 19-byte message header is used for each message, and certain messages also contain data depending on the message type.  The Type-Length-Value (TLV) format is often used to provide flexibility, extensibility and ease in processing of the messages and their data.

Leave a Comment