RFC 1267
Border Gateway Protocol 3 (BGP-3)
RFC 1267: A Border Gateway Protocol 3 (BGP-3) 🌸
okay bestie, RFC 1267 is giving protocol main character energy 💅 It's from October 1991 and it's part of the Network Working Group 🧚
K. Lougheed (cisco Systems) and Y. Rekhter (T.J. Watson Research Center, IBM Corp.) wrote it. It's an IAB standards track protocol, and it obsoletes RFC 1105 and RFC 1163 🎀
part 1 of 7 🫶 more parts are coming, so stay tuned!
Status of This Memo 📜
okay so this memo, along with its companion doc "Application of the Border Gateway Protocol in the Internet", defines an inter-autonomous system routing protocol for the Internet 🌐 It's an IAB standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 💬 For the standardization state and status, check the current edition of the "IAB Official Protocol Standards". Distribution of this memo is unlimited 🦋
1. Acknowledgements 🫶
Huge thanks to Guy Almes (Rice University), Len Bosack (cisco Systems), Jeffrey C. Honig (Cornell Theory Center), and everyone in the Interconnectivity Working Group of the Internet Engineering Task Force, which Guy Almes chaired 💖
We also have to explicitly thank Bob Braden (ISI) for reviewing this document and for his constructive, valuable comments 🙈
And we want to shout out Bob Hinden, Director for Routing of the Internet Engineering Steering Group, plus the team of reviewers he pulled together to look at earlier versions. That team was Deborah Estrin, Milo Medin, John Moy, Radia Perlman, Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya. They brought a strong mix of toughness, professionalism, and courtesy 👑
2. Introduction ✨
BGP is an inter-Autonomous System routing protocol, and it's built on what people learned from EGP as defined in RFC 904 [1] and from EGP usage in the NSFNET Backbone as described in RFC 1092 [2] and RFC 1093 [3] 🌈
The main job of a BGP speaking system is to swap network reachability information with other BGP systems 💌 That info includes the full path of Autonomous Systems (ASs) that traffic has to transit to reach those networks. It's enough to build a graph of AS connectivity, which means routing loops can be pruned and some AS-level policy decisions can be enforced. Routing loops MAY be pruned, and some policy decisions MAY be enforced 🔥
Now, if you want to know which policies BGP can enforce, you MUST focus on one rule: an AS can only advertise to its neighbor ASs the routes it actually uses itself 🧠 That rule matches the "hop-by-hop" routing paradigm that basically runs the whole current Internet. Some policies can't work with hop-by-hop, so they need stuff like source routing to enforce. For example, BGP doesn't let one AS send traffic to a neighbor AS and have that traffic take a different route than the traffic that started in the neighbor AS 🙃 On the flip side, BGP can support any policy that follows hop-by-hop. Since the current Internet only uses hop-by-hop, and BGP can handle any policy that follows that paradigm, BGP is highly applicable as an inter-AS routing protocol for today's Internet 💖
A more complete breakdown of which policies BGP can and can't enforce is out of scope for this doc, but check out the companion document on BGP usage [5] 📚
BGP runs over a reliable transport protocol 🫶 That means it doesn't need to do explicit update fragmentation, retransmission, acknowledgement, or sequencing. Any authentication scheme the transport protocol uses MAY be used on top of BGP's own authentication mechanisms. The error notification mechanism in BGP assumes the transport protocol supports a "graceful" close, meaning all outstanding data gets delivered before the connection closes 🎀
BGP uses TCP [4] as its transport protocol. TCP meets BGP's transport requirements and is in virtually every commercial router and host, so it's a total safe bet 💅 In the following descriptions, "transport protocol connection" can be understood to mean a TCP connection. BGP uses TCP port 179 to set up its connections 🦋
This memo uses the term "Autonomous System" (AS) throughout 🌸 The classic definition is a set of routers under one technical administration, using an interior gateway protocol and common metrics to route packets inside the AS, and an exterior gateway protocol to route packets to other ASs. Since that definition came out, it's become super common for one AS to use several interior gateway protocols and sometimes several sets of metrics. The point of "Autonomous System" here is that even with multiple IGPs and metrics, the AS's administration looks to other ASs like it has one coherent interior routing plan, and it presents a consistent picture of which networks are reachable through it ✨ From the outside, an AS can be treated as monolithic: reachability to networks directly connected to the AS MUST be equivalent from all of the AS's border gateways 👑
The planned use of BGP on the Internet, including topology, how BGP and IGPs interact, and enforcing routing policy rules, is covered in a companion document [5]. This doc is the first in a series planned to explore different aspects of BGP application 🧚
Send comments to the BGP mailing list at iwg@rice.edu 💜
3. Summary of Operation 📦
Two systems form a transport protocol connection with each other. They swap messages to open and confirm the connection parameters 🤝 The first data flow is the entire BGP routing table. Incremental updates get sent whenever the routing tables change. BGP doesn't need a periodic refresh of the whole table, so a BGP speaker MUST keep the current version of the entire BGP routing tables of all its peers for as long as the connection lasts 🧠 KeepAlive messages get sent periodically to make sure the connection is still alive 💓 Notification messages get sent in response to errors or special conditions. If a connection runs into an error condition, a notification message gets sent and the connection closes 🙈
Hosts running BGP don't have to be routers 🌈 A non-routing host could swap routing info with routers over EGP or even an interior routing protocol. Then that non-routing host could use BGP to swap routing info with a border router in another AS. What this architecture implies and how it could be used is for further study 🔍
If an AS has multiple BGP speakers and it's providing transit service for other ASs, then the AS MUST take care to keep a consistent view of routing inside it 🫶 The interior routing protocol gives a consistent view of the AS's interior routes. A consistent view of the exterior routes can come from having all of the BGP speakers inside the AS keep direct BGP connections with each other. Using a common set of policies, the BGP speakers agree on which border routers will act as exit/entry points for particular networks outside the AS 💅 That info then goes to the AS's internal routers, possibly through the interior routing protocol. Care MUST be taken to make sure the interior routers have all been updated with transit information before the BGP speakers announce to other ASs that they're providing transit service 🚨
Connections between BGP speakers in different ASs are called "external" links. BGP connections between BGP speakers in the same AS are called "internal" links 🦋
4. Message Formats 📨
This section describes the message formats BGP uses 🎀
Messages get sent over a reliable transport protocol connection. A message is only processed after it's been entirely received. The maximum message size is 4096 octets. All implementations are REQUIRED to support this maximum message size. The smallest message that MAY be sent is a BGP header with no data portion, which is 19 octets 🌸
4.1 Message Header Format 🍓
Every message has a fixed-size header. There MAY or may not be a data portion after the header, depending on the message type. Here's how the fields are laid out 👇
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Marker |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Marker:
This is a 16-octet field holding a value the receiver of the message can predict 🔮 If the Type of the message is OPEN, or if the Authentication Code used in the OPEN message of the connection is zero, then the Marker MUST be all ones. Otherwise, the value of the marker can be predicted by some computation specified as part of the authentication mechanism being used. The Marker can be used to detect loss of synchronization between a pair of BGP peers, and to authenticate incoming BGP messages 🕵️♀️
Length:
This is a 2-octet unsigned integer that gives the total length of the message, including the header, in octets 📏 So, for example, it lets you find the Marker field of the next message in the transport-level stream. The value of the Length field MUST always be at least 19 and no greater than 4096, and it MAY be further constrained depending on the message type. No "padding" of extra data is allowed after the message, so the Length field MUST have the smallest value required given the rest of the message 🙅♀️
Type:
This is a 1-octet unsigned integer that gives the type code of the message. These type codes are defined:
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE4.2 OPEN Message Format ✨
okay bestie, so after a transport protocol connection is set up, the very first message each side sends is an OPEN message 💌. If the OPEN is acceptable, a KEEPALIVE comes back to confirm it 🫶. Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages MAY be exchanged ✨.
Besides the fixed-size BGP header, the OPEN message has these fields 🎀:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Autonomous System |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth. Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version
Version time 🔢! This 1-octet unsigned integer shows the protocol version number of the message. The current BGP version number is 3.
My Autonomous System
This 2-octet unsigned integer shows the Autonomous System number of the sender 🌸.
Hold Time
This 2-octet unsigned integer shows the maximum number of seconds that may elapse between the receipt of successive KEEPALIVE and/or UPDATE and/or NOTIFICATION messages ⏳.
BGP Identifier
This 4-octet unsigned integer shows the BGP Identifier of the sender. A given BGP speaker sets the value of its BGP Identifier to the IP address of one of its interfaces. The value is determined on startup and is the same for every local interface and every BGP peer 🦋.
Authentication Code
This 1-octet unsigned integer shows which authentication mechanism is being used 🔐. Whenever an authentication mechanism is specified for use within BGP, three things MUST be included in the specification:
- the value of the Authentication Code which indicates use of the mechanism,
- the form and meaning of the Authentication Data, and
- the algorithm for computing values of Marker fields.
Only one authentication mechanism is specified as part of this memo:
- its Authentication Code is zero,
- its Authentication Data MUST be empty (of zero length), and
- the Marker fields of all messages MUST be all ones.
The semantics of non-zero Authentication Codes are outside the scope of this memo.
Note that a separate authentication mechanism MAY be used in establishing the transport level connection 💜.
Authentication Data
This is a variable-length field, and its form and meaning depend on the Authentication Code. If the Authentication Code is zero, the Authentication Data field MUST have zero length. The semantics of a non-zero length Authentication Data field are outside the scope of this memo.
Note that the length of the Authentication Data field can be figured out from the message Length field with this formula:
Message Length = 29 + Authentication Data LengthThe minimum length of the OPEN message is 29 octets (including message header) 🧚.
4.3 UPDATE Message Format 💅
UPDATE messages are how routing information gets transferred between BGP peers 🚚. The information in an UPDATE packet can be used to build a graph showing how the various Autonomous Systems relate to each other 🕸️. By applying rules we'll get to, routing information loops and some other anomalies may be detected and removed from inter-AS routing. literally iconic 👑.
Besides the fixed-size BGP header, the UPDATE message has these fields (note that all fields may have arbitrary alignment) 🎀:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Path Attributes Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Path Attributes /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Total Path Attribute Length
This 2-octet unsigned integer shows the total length of the Path Attributes field in octets 📏. Its value MUST allow the (non-negative integer) number of Network fields to be determined as specified below.
Path Attributes
A variable length sequence of path attributes is present in every UPDATE 🌈. Each path attribute is a triple <attribute type, attribute length, attribute value> of variable length.
Attribute Type is a two-octet field made up of the Attribute Flags octet followed by the Attribute Type Code octet 🧩:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr. Flags |Attr. Type Code|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The high-order bit (bit 0) of the Attribute Flags octet is the Optional bit. It says whether the attribute is optional (if set to 1) or well-known (if set to 0) 🚦.
The second high-order bit (bit 1) of the Attribute Flags octet is the Transitive bit. It says whether an optional attribute is transitive (if set to 1) or non-transitive (if set to 0). For well-known attributes, the Transitive bit MUST be set to 1. (See Section 5 for a discussion of transitive attributes 👀.)
The third high-order bit (bit 2) of the Attribute Flags octet is the Partial bit. It says whether the information contained in the optional transitive attribute is partial (if set to 1) or complete (if set to 0). For well-known attributes and for optional non-transitive attributes, the Partial bit MUST be set to 0.
The fourth high-order bit (bit 3) of the Attribute Flags octet is the Extended Length bit. It says whether the Attribute Length is one octet (if set to 0) or two octets (if set to 1). Extended Length MAY be used only if the length of the attribute value is greater than 255 octets 📦.
The lower-order four bits of the Attribute Flags octet are unused. They MUST be zero (and MUST be ignored when received) 🙈.
The Attribute Type Code octet contains the Attribute Type Code. Currently defined Attribute Type Codes are discussed in Section 5 💖.
If the Extended Length bit of the Attribute Flags octet is set to 0, the third octet of the Path Attribute contains the length of the attribute data in octets.
If the Extended Length bit of the Attribute Flags octet is set to 1, then the third and the fourth octets of the Path Attribute contain the length of the attribute data in octets.
The remaining octets of the Path Attribute represent the attribute value, and they're interpreted according to the Attribute Flags and the Attribute Type Code.
The meaning and handling of Path Attributes is discussed in Section 5 🫶.
Network
Each 4-octet Internet network number indicates one network whose Inter-Autonomous System routing is described by the Path Attributes 🌍. Subnets and host addresses are specifically not allowed. The total number of Network fields in the UPDATE message can be figured out with this formula:
Message Length = 19 + Total Path Attribute Length + 4 * #NetsThe message Length field of the message header and the Path Attributes Length field of the UPDATE message MUST be such that the formula results in a non-negative integer number of Network fields ✨.
The minimum length of the UPDATE message is 37 octets (including message header) 🎀.
4.4 KEEPALIVE Message Format 🫧
BGP does not use any transport protocol-based keep-alive mechanism to figure out if peers are reachable 🙅♀️. Instead, KEEPALIVE messages get exchanged between peers often enough that the hold time (as advertised in the OPEN message) never runs out. A reasonable maximum time between KEEPALIVE messages would be one third of the Hold Time interval ⏰.
A KEEPALIVE message consists of only the message header and has a length of 19 octets 💜.
4.5 NOTIFICATION Message Format ✨
okay bestie so a NOTIFICATION message gets sent whenever an error condition is detected 🚨, and the BGP connection gets closed immediately after it goes out 💀. no cap, that's the whole vibe.
Past the fixed-size BGP header, the NOTIFICATION message has these fields 🎀:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error code | Error subcode | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Error Code 🔥
This is a 1-octet unsigned integer that tells you what type of NOTIFICATION you're looking at 💅. these are the codes that have been defined:
Error Code Symbolic Name Reference
1 Message Header Error Section 6.1
2 OPEN Message Error Section 6.2
3 UPDATE Message Error Section 6.3
4 Hold Timer Expired Section 6.5
5 Finite State Machine Error Section 6.6
6 Cease Section 6.7Error Subcode 🫶
This 1-octet unsigned integer gives more specific info about the nature of the error ✨. each Error Code can have one or more Error Subcodes attached to it. if there's no appropriate Error Subcode defined, then a zero (Unspecific) value gets used in the Error Subcode field.
Message Header Error subcodes:
1 - Connection Not Synchronized.
2 - Bad Message Length.
3 - Bad Message Type.OPEN Message Error subcodes:
1 - Unsupported Version Number.
2 - Bad Peer AS.
3 - Bad BGP Identifier.
4 - Unsupported Authentication Code.
5 - Authentication Failure.UPDATE Message Error subcodes:
1 - Malformed Attribute List.
2 - Unrecognized Well-known Attribute.
3 - Missing Well-known Attribute.
4 - Attribute Flags Error.
5 - Attribute Length Error.
6 - Invalid ORIGIN Attribute
7 - AS Routing Loop.
8 - Invalid NEXT_HOP Attribute.
9 - Optional Attribute Error.
10 - Invalid Network Field.Data 🧚
This variable-length field is used to figure out why the NOTIFICATION happened 🔍. what goes in here depends on the Error Code and Error Subcode, so check out Section 6 below for the deets 📖.
Also, the length of the Data field can be worked out from the message Length field with this formula:
Message Length = 21 + Data LengthThe minimum length of a NOTIFICATION message is 21 octets (including the message header) 🌸.
5. Path Attributes 🦋
this section is all about the path attributes of the UPDATE message 💖.
path attributes fall into four separate categories:
- Well-known mandatory.
- Well-known discretionary.
- Optional transitive.
- Optional non-transitive.
okay so well-known attributes must be recognized by every BGP implementation 👑. some of them are mandatory and must be included in every UPDATE message, and others are discretionary, meaning they may or may not show up in a particular UPDATE. the table further down tells you which is which.
All well-known attributes must be passed along (after proper updating, if necessary) to other BGP peers 🫶.
in addition to the well-known ones, each path can carry one or more optional attributes. it is not required or expected that every BGP implementation supports every optional attribute 🙈. how an unrecognized optional attribute gets handled is decided by the Transitive bit in the attribute flags octet. paths with unrecognized transitive optional attributes should be accepted. if a path with an unrecognized transitive optional attribute is accepted and passed along to other BGP peers, that attribute must go along with the path to those peers with the Partial bit in the Attribute Flags octet set to 1. if a path with a recognized transitive optional attribute is accepted and passed along, and the Partial bit was already set to 1 by some previous AS, the current AS does not set it back to 0 ✨. unrecognized non-transitive optional attributes must be quietly ignored and not passed along to other BGP peers 🤫.
new transitive optional attributes may be attached to the path by the originator or by any other AS in the path 🦋. if they aren't attached by the originator, the Partial bit in the Attribute Flags octet is set to 1. the rules for attaching new non-transitive optional attributes depend on the specific attribute, and the documentation of each new non-transitive optional attribute is expected to include those rules. (the description of the INTER-AS METRIC attribute gives an example 👀.) all optional attributes, both transitive and non-transitive, may be updated (if appropriate) by ASs in the path 💅.
the sender of an UPDATE message should order the path attributes in ascending order of attribute type 🔢. the receiver of an UPDATE message must be prepared to handle path attributes that show up out of order, so be ready 💪.
the same attribute cannot appear more than once within the Path Attributes field of a particular UPDATE message 🚫.
the table below lists the attribute type code, attribute length, and attribute category for the path attributes defined in this document 🍓:
Attribute Name Type Code Length Attribute category
ORIGIN 1 1 well-known, mandatory
AS_PATH 2 variable well-known, mandatory
NEXT_HOP 3 4 well-known, mandatory
UNREACHABLE 4 0 well-known, discretionary
INTER-AS METRIC 5 2 optional, non-transitiveORIGIN 🌈
the ORIGIN path attribute defines where the path information came from 🧭. the data octet can take these values:
Value Meaning
0 IGP - network(s) are interior to the originating AS
1 EGP - network(s) learned via EGP
2 INCOMPLETE - network(s) learned by some other meansAS_PATH 🛣️
the AS_PATH attribute lists the ASs that must be traversed to reach the networks in the UPDATE message 🗺️. since an AS identifier is 2 octets, the length of an AS_PATH attribute is twice the number of ASs in the path. the rules for building an AS_PATH attribute are covered in Section 9 📚.
if a previously advertised route has become unreachable, the AS_PATH path attribute of that unreachable route may be truncated when it's passed in the UPDATE message ✂️. truncation happens by constructing an AS_PATH attribute that consists of only the autonomous system of the sender of the UPDATE message. to keep the truncated AS_PATH semantically correct, the sender also sends the ORIGIN path attribute with the value INCOMPLETE 🙌. note that truncation may be done only over external BGP links 🚧.
NEXT_HOP 🏠
the NEXT_HOP path attribute defines the IP address of the border router that should be used as the next hop to the networks in the UPDATE message 📍. if this border router belongs to the same AS as the BGP peer that advertises it, it's called an internal border router. if it belongs to a different AS than the BGP peer advertising it, it's called an external border router 🧐.
a BGP speaker can advertise any internal border router as the next hop, provided that the interface associated with that border router's IP address (as specified in the NEXT_HOP path attribute) shares a common subnet with both the local and remote BGP speakers 🔗. a BGP speaker can advertise any external border router as the next hop, provided that the IP address of that border router was learned from one of the BGP speaker's peers, and the interface associated with that IP address (as specified in the NEXT_HOP path attribute) shares a common subnet with the local and remote BGP speakers 🫶. a BGP speaker needs to be able to support disabling advertisement of external border routers 🛑.
the NEXT_HOP path attribute only has meaning on external BGP links 🌐. BUT if a NEXT_HOP path attribute shows up in an UPDATE message received over an internal BGP link, that does not count as an error 🙅♀️.
UNREACHABLE 🚷
the UNREACHABLE attribute is used to tell a BGP peer that some of the previously advertised routes have become unreachable 📴.
INTER-AS METRIC 📏
the INTER-AS METRIC attribute may be used on external (inter-AS) links to tell apart multiple exit or entry points to the same neighboring AS 🚪. its value is a 2-octet unsigned number, called a metric. all other factors being equal, the exit or entry point with the lower metric should be preferred 🏆. if it's received over external links, the INTER-AS METRIC attribute may be propagated over internal links to other BGP speakers within the same AS. it is never propagated to BGP speakers in neighboring AS's 🙅♀️.
if a previously advertised route has become unreachable, the INTER-AS METRIC path attribute may be omitted from the UPDATE message 👋.
6. BGP Error Handling. 🚨
this section covers the actions to take when errors are detected while processing BGP messages 🛠️.
when any of the conditions described here are detected, a NOTIFICATION message gets sent with the indicated Error Code, Error Subcode, and Data fields, and then the BGP connection is closed 🔒. if no Error Subcode is specified, then a zero must be used 0️⃣.
"the BGP connection is closed" means two things: the transport protocol connection has been closed, and all resources for that BGP connection have been deallocated 🧹. routing table entries associated with the remote peer are marked as invalid ❌. the fact that those routes have become invalid is passed to other BGP peers before the routes are deleted from the system 📣.
unless it's specified explicitly, the Data field of the NOTIFICATION message sent to indicate an error is empty 🫙.
6.1. Message Header error handling ✨
Okay so every error we catch while processing the Message Header gets reported by sending a NOTIFICATION message with Error Code Message Header Error 💅. The Error Subcode spells out exactly what went wrong 🔍.
The Marker field has to be all ones if the message is an OPEN 🌈. For every other type of BGP message, the expected Marker value is determined based on the Authentication Code in the BGP OPEN message, plus the actual authentication mechanism (if that Authentication Code is non-zero) 🔐. If the Marker isn't the expected one, that's a synchronization error, so the Error Subcode is Connection Not Synchronized 🙈.
If any of these length problems show up, the Error Subcode is Bad Message Length 📏:
- the
Lengthfield is less than 19 or greater than 4096 - the
Lengthof an OPEN message is less than the minimum OPEN length - the
Lengthof an UPDATE message is less than the minimum UPDATE length - the
Lengthof a KEEPALIVE message is not equal to 19 - the
Lengthof a NOTIFICATION message is less than the minimum NOTIFICATION length
The Data field holds the erroneous Length field 💖.
If the Type field isn't recognized, the Error Subcode is Bad Message Type 🧚. The Data field holds the erroneous Type field ✨.
6.2. OPEN message error handling 🦋
Every error found while processing the OPEN message gets reported by sending a NOTIFICATION message with Error Code OPEN Message Error 💜. Again, the Error Subcode gives the specifics 🎀.
If the version number in the Version field of the received OPEN message isn't supported, the Error Subcode is Unsupported Version Number 🫶. The Data field is a 2-octet unsigned integer, and it's the largest version number we support that's still lower than the one the remote BGP peer bid (the version in the received OPEN message) 🍓.
If the Autonomous System field of the OPEN message is unacceptable, the Error Subcode is Bad Peer AS 🙅♀️. Deciding which Autonomous System numbers are acceptable is outside the scope of this protocol 🌸.
If the BGP Identifier field of the OPEN message is syntactically incorrect, the Error Subcode is Bad BGP Identifier 🪪. Syntactically correct here means the BGP Identifier field represents a valid IP host address ✅.
If the Authentication Code of the OPEN message isn't recognized, the Error Subcode is Unsupported Authentication Code 😤. If the Authentication Code is zero, then the Authentication Data must be of zero length. Otherwise, the Error Subcode is Authentication Failure 🚫.
If the Authentication Code is non-zero, the matching authentication procedure gets invoked 🔑. If that procedure fails (based on the Authentication Code and Authentication Data), the Error Subcode is Authentication Failure 💀.
6.3. UPDATE message error handling 🌷
Every error found while processing the UPDATE message gets reported by sending a NOTIFICATION message with Error Code UPDATE Message Error 📮. The error subcode tells you the specifics 🔎.
Error checking for an UPDATE message starts with the path attributes 👑. If the Total Attribute Length is too large (meaning Total Attribute Length + 21 is more than the message Length), or if the Number of Network fields (a non-negative integer) can't be computed as in Section 4.3, the Error Subcode is Malformed Attribute List 😭.
If any recognized attribute has Attribute Flags that conflict with its Attribute Type Code, the Error Subcode is Attribute Flags Error 🚩. The Data field holds the erroneous attribute (type, length and value) 🧁.
If any recognized attribute has an Attribute Length that conflicts with the expected length (based on its attribute type code), the Error Subcode is Attribute Length Error 📐. The Data field holds the erroneous attribute (type, length and value) 🍰.
If any of the mandatory well-known attributes are missing, the Error Subcode is Missing Well-known Attribute 🕵️♀️. The Data field holds the Attribute Type Code of the missing well-known attribute 🏷️.
If any of the mandatory well-known attributes aren't recognized, the Error Subcode is Unrecognized Well-known Attribute 🤷♀️. The Data field holds the unrecognized attribute (type, length and value) 🎁.
If the ORIGIN attribute has an undefined value, the Error Subcode is Invalid Origin Attribute 🥀. The Data field holds the unrecognized attribute (type, length and value) 📦.
If the NEXT_HOP attribute field is syntactically or semantically incorrect, the Error Subcode is Invalid NEXT_HOP Attribute 🚧.
The Data field holds the incorrect attribute (type, length and value) 💅. Syntactic correctness means the NEXT_HOP attribute represents a valid IP host address 🧠. Semantic correctness only applies to external BGP links, and it means the interface tied to the IP address in the NEXT_HOP attribute shares a common subnet with the receiving BGP speaker 🌐.
The AS route in the AS_PATH attribute gets checked for AS loops 🔁. To detect loops, you scan the full AS route (from the AS_PATH attribute) and make sure each AS shows up at most once ☝️. If a loop turns up, the Error Subcode is AS Routing Loop 🌀. The Data field holds the incorrect attribute (type, length and value) 💔.
If an optional attribute is recognized, its value gets checked 🔍. If there's an error, the attribute is discarded and the Error Subcode is Optional Attribute Error 🫧. The Data field holds the attribute (type, length and value) 🎀.
If any attribute appears more than once in the UPDATE message, the Error Subcode is Malformed Attribute List 👯♀️.
Each Network field in the UPDATE message gets checked for syntactic validity ✨. If a Network field is syntactically incorrect, or contains a subnet or a host address, the Error Subcode is Invalid Network Field 🙃.
6.4. NOTIFICATION message error handling 🫠
If a peer sends a NOTIFICATION message and there's an error in that message, unfortunately there's no way to report it using a follow-up NOTIFICATION message 😩. Any error like that, such as an unrecognized Error Code or Error Subcode, should be noticed, logged locally, and brought to the attention of the peer's administration 📝. How to do that part is outside the scope of this document 🤷♀️.
6.5. Hold Timer Expired error handling ⏰
If a system doesn't receive successive KEEPALIVE and/or UPDATE and/or NOTIFICATION messages within the period set in the Hold Time field of the OPEN message, then the NOTIFICATION message with Hold Timer Expired Error Code must be sent and the BGP connection closed 🛑.
6.6. Finite State Machine error handling 🎰
Any error the BGP Finite State Machine detects (like getting an unexpected event) gets reported by sending a NOTIFICATION message with Error Code Finite State Machine Error 🧩.
6.7. Cease 💤
If there aren't any fatal errors (the ones listed in this section), a BGP peer can choose to close its BGP connection at any time by sending a NOTIFICATION message with Error Code Cease 👋. But the Cease NOTIFICATION message must not be used when a fatal error from this section does exist 🚫.
6.8. Connection collision detection 💫
If a pair of BGP speakers try to set up a TCP connection to each other at the same time, two parallel connections between them might end up forming 🤯. We call that a connection collision 💥. Clearly, one of those connections has to close 🙅♀️.
To decide which BGP connection to keep during a collision, there's a convention based on the BGP Identifier 🪄. You compare the BGP Identifiers of the peers involved and keep only the connection initiated by the BGP speaker with the higher-valued BGP Identifier 👑.
When the local system receives an OPEN message, it has to check all of its connections that are in the OpenSent state 👀. If one of them is a connection to a remote BGP speaker whose BGP Identifier matches the one in the OPEN message, the local system runs this collision resolution procedure 🧠:
- Compare the BGP Identifier of the local system to the BGP Identifier of the remote system (as specified in the OPEN message).
- If the local BGP Identifier is less than the remote one, the local system closes the BGP connection that already exists (the one already in the OpenSent state), and accepts the BGP connection initiated by the remote system 🫶.
- Otherwise, the local system closes the newly created BGP connection (the one tied to the newly received OPEN message), and keeps using the existing one (the one already in the OpenSent state) 🎀.
Comparing BGP Identifiers is done by treating them as (4-octet long) unsigned integers 🔢.
A connection collision with existing BGP connections that are in either the OpenConfirm or Established states causes the newly created connection to be closed unconditionally 🔒. Heads up: a connection collision can't be detected with connections in the Idle, Connect, or Active states 🙅♀️.
Closing the BGP connection that results from the collision resolution procedure is done by sending a NOTIFICATION message with Error Code Cease 💅.
7. BGP Version Negotiation 🦋
BGP speakers may negotiate the protocol version by making multiple attempts to open a BGP connection, starting with the highest version number each one supports 🪜. If an open attempt fails with Error Code OPEN Message Error and Error Subcode Unsupported Version Number, then the BGP speaker has the version number it tried, the version number its peer tried, the version number its peer passed in the NOTIFICATION message, and the version numbers it supports 📋. If the two peers support one or more common versions, they can quickly figure out the highest common version 🏆. To support BGP version negotiation, future versions of BGP must retain the format of the OPEN and NOTIFICATION messages 🫶✨.
8. BGP Finite State machine ✨
okay so this section is the BGP Finite State Machine (FSM), which is basically the rulebook for how a BGP connection moves through its moods 💅 there's a quick overview of what BGP does in each state, and if you want the condensed version, check out Appendix 1 🎀
BGP starts out in the Idle state, bestie 🌸
Idle state 💤
Idle is giving "do not disturb." BGP refuses all incoming BGP connections, and no resources get allocated to the BGP neighbor 🙈 When the Start event shows up (triggered by either the system or an operator), the local system sets up all its BGP resources, starts the ConnectRetry timer, and kicks off a transport connection to the other BGP peer. While that's happening, it keeps listening for a connection the remote BGP peer might start, and then it moves to Connect 🦋 The exact value of the ConnectRetry timer is a local matter, but it should be big enough to give TCP time to initialize 🧚
Any other event that lands in Idle just gets ignored, no drama 💖
Connect state 🔌
In Connect, BGP is waiting for the transport protocol connection to finish 👀
If the transport protocol connection succeeds, the local system clears the ConnectRetry timer, finishes its initialization, sends an OPEN message to its peer, and moves to OpenSent 🔥
If the transport protocol connect fails (for example, a retransmission timeout), the local system restarts the ConnectRetry timer, keeps listening for a connection the remote BGP peer might start, and switches to the Active state 😭
When the ConnectRetry timer expires, the local system restarts the ConnectRetry timer, starts a transport connection to the other BGP peer, keeps listening for a connection from the remote BGP peer, and stays in Connect 🫶
The Start event gets ignored in the Active state, so that's a no from BGP 💅
For any other event (from either system or operator), the local system lets go of all BGP resources tied to this connection and goes back to Idle 💀
Active state 🌈
In Active, BGP is trying to find a BGP neighbor by starting a transport protocol connection ✨
If the transport protocol connection succeeds, the local system clears the ConnectRetry timer, finishes initialization, sends an OPEN message to its peer, sets its hold timer to a large value, and moves to OpenSent 🎀
When the ConnectRetry timer expires, the local system restarts the ConnectRetry timer, starts a transport connection to the other BGP peer, keeps listening for a connection the remote BGP peer might start, and changes its state to Connect 🧚
Here's a plot twist 😳 If the local system spots a remote peer trying to set up a BGP connection, and that peer's IP address isn't one it expects, the local system restarts the ConnectRetry timer, rejects that attempt, keeps listening for a connection from the remote BGP peer, and stays in Active 🙅♀️
The Start event is ignored in Active, same as before 💜
For any other event (from either system or operator), the local system releases all BGP resources tied to this connection and goes back to Idle 🍓
OpenSent state 📨
In OpenSent, BGP just waits for an OPEN message from its peer 👑 Once one arrives, every field gets checked for correctness. If the BGP message header checking or OPEN message checking finds an error (see Section 6.2), or there's a connection collision (see Section 6.8), the local system sends a NOTIFICATION message and changes its state to Idle 🙈
If there are no errors in the OPEN message, BGP sends a KEEPALIVE message and sets a KeepAlive timer ✨ The hold timer, which was originally set to an arbitrary large value (see above), gets replaced with the value from the OPEN message. If the Autonomous System field matches our own, the connection is an "internal" connection. Otherwise, it's "external". (This will effect UPDATE processing as described below.) Finally, the state changes to OpenConfirm 💖
If a disconnect notification comes in from the underlying transport protocol, the local system closes the BGP connection, restarts the ConnectRetry timer, keeps listening for a connection the remote BGP peer might start, and goes into the Active state 😭
If the hold time expires, the local system sends a NOTIFICATION message with the error code Hold Timer Expired and changes its state to Idle 💀
In response to the Stop event (from either system or operator), the local system sends a NOTIFICATION message with Error Code Cease and changes its state to Idle 🛑
The Start event is ignored in OpenSent 🙅♀️
For any other event, the local system sends a NOTIFICATION message with Error Code Finite State Machine Error and changes its state to Idle 🔥
Whenever BGP moves from OpenSent to Idle, it closes the BGP (and transport-level) connection and releases all resources tied to that connection 🧹
OpenConfirm state 🤝
In OpenConfirm, BGP waits for a KEEPALIVE or NOTIFICATION message 👀
If the local system receives a KEEPALIVE message, it changes its state to Established 🎉
If the hold timer expires before a KEEPALIVE message arrives, the local system sends a NOTIFICATION message with error code Hold Timer expired and changes its state to Idle 😭
If the local system receives a NOTIFICATION message, it changes its state to Idle 💀
If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer 💖
If a disconnect notification comes in from the underlying transport protocol, the local system changes its state to Idle 💔
In response to the Stop event (from either system or operator), the local system sends a NOTIFICATION message with Error Code Cease and changes its state to Idle 🛑
The Start event is ignored in OpenConfirm 🙅♀️
For any other event, the local system sends a NOTIFICATION message with Error Code Finite State Machine Error and changes its state to Idle 🔥
Whenever BGP moves from OpenConfirm to Idle, it closes the BGP (and transport-level) connection and releases all resources tied to that connection 🧹
Established state 👑
This is the main character era 🌟 In Established, BGP can swap UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer 💜
If the local system receives an UPDATE or KEEPALIVE message, it restarts its Holdtime timer ⏱️
If the local system receives a NOTIFICATION message, it changes its state to Idle 💀
If the local system receives an UPDATE message and the UPDATE message error handling procedure (see Section 6.3) detects an error, the local system sends a NOTIFICATION message and changes its state to Idle 🙈
If a disconnect notification comes in from the underlying transport protocol, the local system changes its state to Idle 💔
If the Holdtime timer expires, the local system sends a NOTIFICATION message with Error Code Hold Timer Expired and changes its state to Idle 😭
If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer 💖
Each time the local system sends a KEEPALIVE or UPDATE message, it restarts its KeepAlive timer 🔁
In response to the Stop event (from either system or operator), the local system sends a NOTIFICATION message with Error Code Cease and changes its state to Idle 🛑
The Start event is ignored in Established 🙅♀️
For any other event, the local system sends a NOTIFICATION message with Error Code Finite State Machine Error and changes its state to Idle 🔥
Heads up, bestie 🚨 Whenever BGP moves from Established to Idle, it closes the BGP (and transport-level) connection, releases all resources tied to that connection, and deletes all routes derived from that connection. Yes, all of them 🥺
9. UPDATE Message Handling ✨
okay so an UPDATE message can ONLY be received when you're in the Established state 💖 that's the rule. when one shows up, every field gets checked for validity, the way Section 6.3 spells out 🎀
if an optional non-transitive attribute is unrecognized, it just gets quietly ignored 🙈 no drama. but if an optional transitive attribute is unrecognized, the Partial bit (that's the third high-order bit in the attribute flags octet) gets set to 1, and the attribute is kept around so it can be passed along to other BGP speakers 🦋
if an optional attribute IS recognized and has a valid value, then it depends on what kind of attribute it is. it can get processed locally, retained, and updated if needed so it can be propagated to other BGP speakers 💅
if the network and the path attributes tied to a route to that network are correct, then the route gets compared with the other routes to the same network 🌸
when a BGP speaker gets a new route from a peer over an external BGP link, it SHALL advertise that route to the other BGP speakers in its autonomous system with an UPDATE message if either of these happens:
a) the newly received route is considered to be better
than the other routes to the same network (as listed
in the UPDATE message) that have been received over
external BGP links, or
b) there are no other acceptable routes to the network
(as listed in the UPDATE message) that have been
received over external BGP links.and when a BGP speaker gets an unreachable route from a BGP peer over an external BGP link, it SHALL advertise that route to all the other BGP speakers in its autonomous system, saying it's become unreachable, if this condition happens:
a) a corresponding acceptable route to the same destination
was considered to be the best one among all routes to that
destination that have been received over external BGP links
(that is the local system has been advertising the
route to all other BGP speakers in its autonomous system
before it received the UPDATE message that reported it
as unreachable).whenever a BGP speaker picks a new route (from all the routes it got from external and internal BGP peers), or figures out that the reachable destinations inside its own autonomous system have changed, it SHALL generate an UPDATE message and forward it to each of its external peers (the ones connected over external BGP links) 🔥
if a route in an UPDATE came in over an internal link, it is NOT propagated over any other internal link. the reason is that all BGP speakers inside a single AS form a completely connected graph (see above) 🧚
if the UPDATE message gets propagated over an external link, the local AS number gets prepended to the AS_PATH attribute, and the NEXT_HOP attribute is updated with the IP address of the router that should be used as the next hop to the network. if the UPDATE message gets propagated over an internal link, then the AS_PATH attribute and the NEXT_HOP attribute are passed along unmodified 🍓
generally speaking, the rules for comparing routes against each other are OUTSIDE the scope of this document 🙃 there are two exceptions though:
- if the local AS appears in the AS path of the new route being considered, then that new route cannot be viewed as better than any other route. if such a route were ever used, a routing loop would result. 💀
- in order to achieve successful distributed operation, only routes with a likelihood of stability can be chosen. so an AS MUST avoid using unstable routes, and it MUST NOT make rapid spontaneous changes to its choice of route. quantifying the terms "unstable" and "rapid" in the previous sentence will require experience, but the principle is clear 👑
10. Detection of Inter-AS Policy Contradictions ✨
okay this one is so important bestie 😭 BGP doesn't have a central authority deciding routing policies across ASs, and the policies aren't exchanged via the protocol itself. so it's totally possible for a group of ASs to have a set of routing policies that can't all be satisfied at once. that can cause an indefinite oscillation of the routes in that group of ASs 🌀
to help catch this, all BGP speakers MUST observe the following rule. if a route to a destination that the local system is currently using is determined to be unreachable (for example, because an UPDATE message for this route came in with the UNREACHABLE attribute), then, BEFORE switching to another route, this local system MUST advertize this route as unreachable to all the BGP neighbors it previously advertized this route to 💖
this rule lets other ASs tell apart two different situations:
- the local system chose a new route because the old route became unreachable.
- the local system chose a new route because it preferred it over the old route. the old route is still viable.
in the first case, an UPDATE message with the UNREACHABLE attribute will be received for the old route. in the second case it won't 🦋
sometimes this lets a BGP speaker notice that its policies, combined with the policies of some other AS, can't all be satisfied at the same time. for example, look at this situation with AS A and its neighbor AS B. B advertises a route with a path like <B,...>, where A isn't in the path. A then decides to use that path and advertises <A,B,...> to all its neighbors. later B advertises <B,...,A,...> back to A, without ever declaring its earlier path <B,...> unreachable. clearly A prefers routes via B and B prefers routes via A. their combined policies can't be satisfied 😬
an event like that SHOULD be noticed, logged locally, and brought to the attention of AS A's administration. the means to do this, however, is outside the scope of this document. a more complete procedure for detecting these policy contradictions is also outside the document 🌸
the rules above give a mechanism to detect a set of routing policies that can't be satisfied at the same time, but the protocol itself does NOT provide any mechanism for suppressing the route oscillation that these unsatisfiable policies might cause 🙅♀️ the reason is that routing policies are viewed as external to the protocol and as determined by the local AS administrator 💅
Appendix 1. BGP FSM State Transitions and Actions 🎀
this appendix talks about the transitions between states in the BGP FSM in response to BGP events 🧚 here's the list of states and events:
BGP States:
1 - Idle
2 - Connect
3 - Active
4 - OpenSent
5 - OpenConfirm
6 - Established
BGP Events:
1 - BGP Start
2 - BGP Stop
3 - BGP Transport connection open
4 - BGP Transport connection closed
5 - BGP Transport connection open failed
6 - BGP Transport fatal error
7 - ConnectRetry timer expired
8 - Holdtime timer expired
9 - KeepAlive timer expired
10 - Receive OPEN message
11 - Receive KEEPALIVE message
12 - Receive UPDATE messages
13 - Receive NOTIFICATION messagethe table below describes the state transitions of the BGP FSM and the actions those transitions trigger 🍓
Event Actions Message Sent Next State
--------------------------------------------------------------------
Idle (1)
1 Initialize resources none 2
Start ConnectRetry timer
Initiate a transport connection
others none none 1
Connect(2)
1 none none 2
3 Complete initialization OPEN 4
Clear ConnectRetry timer
5 Restart ConnectRetry timer none 3
7 Restart ConnectRetry timer none 2
Initiate a transport connection
others Release resources none 1
Active (3)
1 none none 3
3 Complete initialization OPEN 4
Clear ConnectRetry timer
5 Close connection 3
Restart ConnectRetry timer
7 Restart ConnectRetry timer none 2
Initiate a transport connection
others Release resources none 1
OpenSent(4)
1 none none 4
4 Close transport connection none 3
Restart ConnectRetry timer
6 Release resources none 1
10 Process OPEN is OK KEEPALIVE 5
Process OPEN failed NOTIFICATION 1
others Close transport connection NOTIFICATION 1
Release resources
OpenConfirm (5)
1 none none 5
4 Release resources none 1
6 Release resources none 1
9 Restart KeepAlive timer KEEPALIVE 5
11 Complete initialization none 6
Restart Holdtime timer
13 Close transport connection 1
Release resources
others Close transport connection NOTIFICATION 1
Release resources
Established (6)
1 none none 6
4 Release resources none 1
6 Release resources none 1
9 Restart KeepAlive timer KEEPALIVE 6
11 Restart Holdtime timer KEEPALIVE 6
12 Process UPDATE is OK UPDATE 6
Process UPDATE failed NOTIFICATION 1
13 Close transport connection 1
Release resources
others Close transport connection NOTIFICATION 1
Release resources
---------------------------------------------------------------------the following is a condensed version of the above state transition table 🫶
Events| Idle | Active | Connect | OpenSent | OpenConfirm | Estab
| (1) | (2) | (3) | (4) | (5) | (6)
|--------------------------------------------------------------
1 | 2 | 2 | 3 | 4 | 5 | 6
| | | | | |
2 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
3 | 1 | 4 | 4 | 1 | 1 | 1
| | | | | |
4 | 1 | 1 | 1 | 3 | 1 | 1
| | | | | |
5 | 1 | 3 | 3 | 1 | 1 | 1
| | | | | |
6 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
7 | 1 | 2 | 2 | 1 | 1 | 1
| | | | | |
8 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
9 | 1 | 1 | 1 | 1 | 5 | 6
| | | | | |
10 | 1 | 1 | 1 | 1 or 5 | 1 | 1
| | | | | |
11 | 1 | 1 | 1 | 1 | 6 | 6
| | | | | |
12 | 1 | 1 | 1 | 1 | 1 | 1 or 6
| | | | | |
13 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
---------------------------------------------------------------Appendix 2. Comparison with RFC 1163 ✨
To detect and recover from a BGP connection collision, a brand-new field called the BGP Identifier has been added to the OPEN message 🆔. There's also new text in Section 6.8 that spells out exactly how collisions get detected and recovered from, so no more guessing 💅.
The new document no longer restricts the border router that shows up in the NEXT_HOP path attribute to be part of the same Autonomous System as the BGP Speaker. Big glow-up 🌸.
The new document also optimizes and simplifies how information about previously reachable routes gets exchanged 🫶.
Appendix 3. Comparison with RFC 1105 🦋
Everything in Appendix 2 applies here too, plus the stuff below 💖.
Minor changes to the RFC1105 Finite State Machine were necessary so it could work with the TCP user interface that 4.3 BSD provided 🔧.
The Up/Down/Horizontal relations that RFC1105 had? Those are gone from the protocol, bye 👋.
Here's how the message format changed from RFC1105:
- The Hold Time field has been removed from the BGP header and moved into the
OPENmessage ⏱️. - The version field has been removed from the BGP header and moved into the
OPENmessage 🔢. - The Link Type field has been removed from the
OPENmessage 🚫. - The
OPEN CONFIRMmessage has been eliminated. In its place, confirmation is now implicit, provided by theKEEPALIVEmessage 🫧. - The format of the
UPDATEmessage got a major makeover. New fields were added so it can support multiple path attributes 💅. - The Marker field has been expanded, and its role got broadened to support authentication 🔐.
Quick naming note, because it gets confusing 🙈: BGP as specified in RFC 1105 is often called BGP-1, BGP as specified in RFC 1163 is called BGP-2, and BGP as specified in this document is called BGP-3 🎀.
Appendix 4. TCP options that may be used with BGP 🧚
If a local system's TCP user interface supports the TCP PUSH function, then each BGP message SHOULD be transmitted with the PUSH flag set. Setting the PUSH flag forces BGP messages to get transmitted promptly to the receiver 🚀.
If a local system's TCP user interface supports setting precedence for a TCP connection, then the BGP transport connection SHOULD be opened with precedence set to the Internetwork Control (110) value (see also [6]) 👑.
Appendix 5. Implementation Recommendations 🌈
This section presents some implementation recommendations. Let's go, bestie 🫶.
5.1 Multiple Networks Per Message
The BGP protocol lets you put multiple networks with the same AS path and next-hop gateway into one message. Making use of this capability is highly RECOMMENDED 💖. With one network per message, the receiver takes a big overhead hit. The system overhead goes up because of all those extra messages coming in, and the cost of scanning the routing table for flash updates to BGP peers and other routing protocols (plus sending the associated messages) gets paid multiple times too 😭.
One way to build messages with lots of networks per AS path and gateway, starting from a routing table that isn't organized per AS path, is to build many messages while you scan the routing table. As each network gets processed, a message for its AS path and gateway is allocated if it doesn't exist yet, and the new network gets added to it. If that message already exists, the new network is just appended. If the message doesn't have room for the new network, it gets transmitted, a new message is allocated, and the new network goes into the new message 🧁. Once the entire routing table has been scanned, all the allocated messages are sent and their resources are released ✨.
Maximum compression happens when all networks share a gateway and common path attributes, which makes it possible to send many networks in one 4096-byte message 🏆.
When you're peering with a BGP implementation that doesn't compress multiple networks into one message, you MAY need to take steps to reduce the overhead from the flood of data received when a peer is acquired or a significant network topology change occurs 🌊. One method is to limit the rate of flash updates. This eliminates the redundant scanning of the routing table to provide flash updates for BGP peers and other routing protocols. The downside is that it increases the propagation latency of routing information 🥺. If you pick a minimum flash update interval that isn't much greater than the time it takes to process the multiple messages, that latency stays low. Honestly, a better method would be to read all received messages before sending updates 🧠.
5.2 Processing Messages on a Stream Protocol
BGP uses TCP as its transport mechanism. Because TCP is a stream, all the data for a received message doesn't necessarily arrive at the same time. That makes it hard to process the data as messages, especially on systems like BSD Unix, where you can't tell how much data has been received but not processed yet 😩.
One method for this situation is to first try reading just the message header. For the KEEPALIVE message type, that's a complete message. For other message types, the header SHOULD first be verified, especially the total length. If all the checks pass, the specified length minus the size of the message header is the amount of data left to read. An implementation that would "hang" the routing information process while trying to read from a peer could set up a message buffer (4096 bytes) per peer and fill it with data as it becomes available, until a complete message has been received 🎀.
5.3 Processing Update Messages
In BGP, all UPDATE messages are incremental 📈. Once a particular network is listed in an UPDATE message as reachable through an AS path and gateway, that information is expected to be retained indefinitely 💜.
For a route to a network to be removed, it MUST be explicitly listed in an UPDATE message as unreachable, or come with new routing information to replace the old. Note that a BGP peer will only advertise one route to a given network, so any announcement of that network by a particular peer replaces any previous information about that network received from the same peer 🔄.
One useful optimization: unreachable networks don't need to be advertised with their original attributes. Instead, all unreachable networks could be sent in a single message, perhaps with an AS path consisting of the local AS only and with the origin set to INCOMPLETE 🧹.
This approach has the obvious advantage of low overhead. If all routes are stable, only KEEPALIVE messages get sent, and there's no periodic flood of route information 😌.
Here's the catch, though 🙈. A consistent view of routing information between BGP peers is only possible over the course of a single transport connection, since there's no mechanism for a complete update. To cover that, BGP peers MUST transition to the Idle state when a transport connection fails 🚨.
5.4 BGP Timers ⏰
BGP employs three timers: ConnectRetry, Holdtime, and KeepAlive.
The suggested value for the ConnectRetry timer is 120 seconds.
The suggested value for the Holdtime timer is 90 seconds.
The suggested value for the KeepAlive timer is 30 seconds.
An implementation of BGP SHALL allow any of these timers to be configurable 🛠️.
5.5 Frequency of Route Selection 🗓️
An implementation of BGP SHALL allow a border router to set the minimum amount of time that must elapse between selection and subsequent advertisement of better routes that a given BGP speaker received from BGP speakers located in adjacent ASs ⏳.
Since fast convergence is needed within an AS, deferring selection doesn't apply to better routes chosen as a result of UPDATEs from BGP speakers located in the advertising speaker's own AS 🏃♀️. To avoid long-lived black holes, it also doesn't apply to advertising previously selected routes that have become unreachable. In both of these situations, the local BGP speaker MUST select and advertise such routes immediately ⚡.
If a BGP speaker received better routes from BGP speakers in adjacent ASs but hasn't advertised them yet because the time hasn't elapsed, then receiving any routes from other BGP speakers in its own AS SHALL trigger a new route selection process. That process will be based on updates from BGP speakers in both the same AS and adjacent ASs 🔍.
References 📚
[1] Mills, D., "Exterior Gateway Protocol Formal Specification", RFC 904, BBN, April 1984.
[2] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET Backbone", RFC 1092, T.J. Watson Research Center, February 1989.
[3] Braun, H-W., "The NSFNET Routing Architecture", RFC 1093, MERIT/NSFNET Project, February 1989.
[4] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981.
[5] Rekhter, Y., and P. Gross, "Application of the Border Gateway Protocol in the Internet", RFC 1268, T.J. Watson Research Center, IBM Corp., ANS, October 1991.
[6] Postel, J., "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, DARPA, September 1981.
Security Considerations 🔒
Security issues are not discussed in this memo. 😱 Dramatic, I know, but this one is a total open book on the security front, so keep your guard up and handle it with care 🫣.
Authors' Addresses 💌
Kirk Lougheed cisco Systems, Inc. 1525 O'Brien Drive Menlo Park, CA 94025
Phone: (415) 326-1941 Email: LOUGHEED@CISCO.COM
Yakov Rekhter T.J. Watson Research Center IBM Corporation P.O. Box 218 Yorktown Heights, NY 10598
Phone: (914) 945-3896 Email: YAKOV@WATSON.IBM.COM
📦 where this page comes from
- ietf: rfc1267 1991-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms