IP subnet routing
Chapter 3. Routing Protocols
3.4 Exterior Routing Protocols
3.4.2 Border Gateway Protocol (BGP-4)
The Border Gateway Protocol (BGP) is a draft standard protocol. Its status is elective. It is described in RFC 1771.
The Border Gateway Protocol is an exterior gateway protocol used to exchange network reachability information among ASs (see Figure 70 on page 98).
BGP-4 was introduced in the Internet in the loop-free exchange of routing information between autonomous systems. Based on Classless Inter-Domain Routing (CIDR), BGP has since evolved to support the aggregation and reduction of routing information.
In essence, CIDR is a strategy designed to address the following problems:
Exhaustion of Class B address space
Routing table growth
CIDR eliminates the concept of address classes and provides a method for summarizing n different routes into single routes. This significantly reduces the amount of routing information that BGP routers must store and exchange. (See 2.1.7, “Classless Inter-Domain Routing (CIDR)” on page 45 for details.)
AS1
3376\3376FCZD OSPF/RIP
OSPF/RIP BGP Speaker
AS2
AS3
OSPF/RIP BGP Speaker ASX
ASX OSPF/RIP
OSPF/RIP OSPF/RIP BGP Speaker OSPF/RIP
OSPF/RIP
OSPF/RIP BGP Speaker
OSPF/RIP BGP Speaker
OSPF/RIP
OSPF/RIP
OSPF/RIP
Figure 95. BGP Speaker and AS Relationship
Before giving an overview of the BGP protocol, we define some terms used in BGP:
BGP speaker
A system running BGP (see Figure 95).
BGP neighbors
A pair of BGP speakers exchanging inter-AS routing information. BGP neighbors may be of two types:
Internal A pair of BGP speakers in the same autonomous system. Internal BGP neighbors must present a consistent image of the AS to their external BGP neighbors. This is explained in more detail below.
External A pair of BGP neighbors in different autonomous systems.
External BGP neighbors must be connected by a BGP connection as defined below. This restriction means that in most cases where an AS has multiple BGP inter-AS connections, it will also require multiple BGP speakers.
BGP session
A TCP session between BGP neighbors that are exchanging routing information using BGP. The neighbors monitor the state of the session by sending a keepalive message regularly. (The recommended interval is 30 seconds.)6
AS border router (ASBR)
A router that has a connection to multiple autonomous systems.
Note: The nomenclature for this type of router is somewhat varied. RFC 2328, which describes OSPF, uses the term AS boundary router.
RFC 1771 and 1772, which describe BGP, use the terms border router and border gateway. We use the first term consistently when describing both OSPF and BGP. BGP defines two types of AS border routers, depending on its topological relationship to the BGP speaker that refers to it.
Internal A next hop router in the same AS as the BGP speaker.
External A next hop router in a different AS from the BGP speaker.
The IP address of a border router is specified as a next hop destination when BGP advertises an AS path (see below) to one of its external neighbors.
Next hop border routers must share a physical connection (see below) with both the sending and receiving BGP speakers. If a BGP speaker advertises an external border router as a next hop, that router must have been learned of from one of that BGP speaker's peers.
AS connection
BGP defines two types of inter-AS connections:
Physical connection
An AS shares a physical network with another AS, and this network is connected to at least one border router from each AS.
Since these two routers share a network, they can forward packets to each other without requiring any inter-AS or intra-AS routing protocols. (That is, they require neither an IGP nor an EGP to communicate.)
BGP connection
A BGP connection means that there is a BGP session between a pair of BGP speakers, one in each AS. This session is used to communicate the routes through the physically connected border routers that can be used for specific networks. BGP requires that the BGP speakers must be on the same network as the physically connected border routers so that the BGP session is also
independent of all inter-AS or intra-AS routing protocols. The BGP speakers do not need to be border routers, and vice versa.
Note: The term BGP connection can be used to refer to a session between two BGP speakers in the same AS.
Traffic type
BGP categorizes traffic in an AS as one of two types:
6 This keepalive message is implemented in the application layer, and is independent of the keepalive message available in many TCP implementations.
local Local traffic is traffic that either originates in or terminates in that AS. That is, either the source or the destination IP address is in the AS.
transit Transit traffic is all non-local traffic.
One of the goals of BGP is to minimize the amount of transit traffic.
AS type
An AS is categorized as one of three types:
stub A stub AS has a single inter-AS connection to one other AS. A stub AS only carries local traffic.
multihomed
A multihomed AS has connections to more than one other AS but refuses to carry transit traffic.
transit A transit AS has connections to more than one other AS and carries both and local transit traffic. The AS may impose policy restrictions on what transit traffic will be carried.
AS number
A 16-bit number uniquely identifying an AS. This is the same AS number used by EGP.
AS path
A list of all of the AS numbers traversed by a route when exchanging routing information. Rather than exchanging simple metric counts, BGP
communicates entire paths to its neighbors.
Routing policy
A set of rules constraining routing to conform to the wishes of the authority that administers the AS. Routing policies are not defined in the BGP protocol, but are selected by the AS authority and presented to BGP in the form of implementation-specific configuration data. Routing policies can be selected by the AS authority in whatever way that authority sees fit. For example:
A multihomed AS can refuse to act as a transit AS. It does this by not advertising routes to networks other than those directly connected to it.
A multihomed AS can limit itself to being a transit AS for a restricted set of adjacent ASs. It does this by advertising its routing information to this set only.
An AS can select which outbound AS should be used for carrying transit traffic.
An AS can also apply performance-related criteria when selecting outbound paths:
An AS can optimize traffic to use short AS paths rather than long ones.
An AS can select transit routes according to the service quality of the intermediate hops. This service quality information could be obtained using mechanisms external to BGP.
It can be seen from the definitions above that a stub AS or a multihomed AS has the same topological properties as an AS in the ARPANET architecture. That is, it never acts as an intermediate AS in an inter-AS route. In the ARPANET
architecture, EGP was sufficient for such an AS to exchange reachability
information with its neighbors, and this remains true with BGP. Therefore, a stub
AS or a multihomed AS can continue to use EGP (or any other suitable protocol) to operate with a transit AS. However, RFC 1772 recommends that BGP is used instead of EGP for these types of AS because it provides an advantage in
bandwidth and performance. Additionally, in a multihomed AS, BGP is more likely to provide an optimum inter-AS route than EGP, since EGP only addresses reachability and not distance.
3.4.2.1 Path Selection
Each BGP speaker must evaluate different paths to a destination from the border router(s) for an AS connection, select the best one that complies with the routing policies in force and then advertise that route to all of its BGP neighbors at that AS connection.
BGP is a vector-distance protocol but, unlike traditional vector-distance protocols such as RIP where there is a single metric, BGP determines a preference order by applying a function mapping each path to a preference value and selects the path with the highest value. The function applied is generated by the BGP
implementation according to configuration information. However, BGP does not keep a cost metric to any path which is sometimes thought of as a shortcoming, but there is no mechanism in place for BGP to collect a uniform cost for paths across the multitude of today's service provider networks.
Where there are multiple viable paths to a destination, BGP maintains all of them but only advertises the one with the highest preference value. This approach allows a quick change to an alternate path should the primary path fail.
3.4.2.2 Routing Policies
RFC 1772 includes a recommended set of policies for all implementations:
A BGP implementation should be able to control which routes it announces.
The granularity of this control should be at least at the network level for the announced routes and at the AS level for the recipients. For example, BGP should allow a policy of announcing a route to a specific network to a specific adjacent AS. Care must be taken when a BGP speaker selects a new route that cannot be announced to a paticular external peer, while the previously selected route was announced to that peer. Specifically, the local system must explicitly indicate to the peer that the previous route is now infeasible.
BGP should allow a weighting policy for paths. Each AS can be assigned a weight and the preferred path to a destination is then the one with the lowest aggregate weight.
BGP should allow a policy of excluding an AS from all possible paths. This can be done with a variant of the previous policy; each AS to be excluded is given an infinite weight and the route selection process refuses to consider paths of infinite weight.
Routing Updates from BGP Routers
BGP Router Input
Policy
Routing Updates to BGP Routers
Routing Table Decision
Process
Routes to be Used
Output Policy
3376\3376FCZB
Figure 96. BGP Process and Routing Policies
See Figure 96 regarding the BGP process and routing policies:
1. Routing updates are received from other BGP routers.
2. Input policy engine filters routes and performs attribute manipulation.
3. Decision process decides what routes the BGP router will use.
4. Output policy engine filters routes and performs attribute manipulation for routes to be advertised.
5. Routing updates are advertised to other BGP routers.
3.4.2.3 AS Consistency
BGP requires that a transit AS present the same view to every AS using its
services. If the AS has multiple BGP speakers, they must agree on two aspects of topology: intra-AS and inter-AS. Since BGP does not deal with intra-AS routing at all, a consistent view of intra-AS topology must be provided by the interior routing protocol(s) employed in the AS. Naturally, a protocol such as OSPF (see 3.3.4,
“Open Shortest Path First (OSPF)” on page 112) that implements synchronization of router databases lends itself well to this role. Consistency of the external topology may be provided by all BGP speakers in the AS having BGP sessions with each other, but BGP does not require that this method be used, only that consistency be maintained.
3.4.2.4 Routing Information Exchange
BGP only advertises routes that it uses itself to its neighbors. That is, BGP
conforms to the normal Internet hop-by-hop paradigm, even though it has additional information in the form of AS paths and theoretically could be capable of informing a neighbor of a route it would not use itself.
When two BGP speakers form a BGP session, they begin by exchanging their entire routing tables. Routing information is exchanged via UPDATE messages (see below for the format of these messages). Since the routing information contains the complete AS path to each listed destination in the form of a list of AS numbers in addition to the usual reachability and next hop information used in traditional vector distance protocols, it can be used to suppress routing loops and to eliminate the counting-to-infinity problem found in RIP. After BGP neighbors have performed their initial exchange of their complete routing databases, they only exchange updates to that information.
3.4.2.5 Protocol Description
BGP runs over a reliable transport layer connection between neighbor routers. BGP relies on the transport connection for fragmentation, retransmission,
acknowledgement and sequencing. It assumes that the transport connection will close in an orderly fashion, delivering all data, in the event of an error notification.
Practical implementations of BGP use TCP as the transport mechanism.
Therefore, BGP protocol data units are contained within TCP packets. Connections to the BGP service on a router use TCP port 179.
The BGP protocol comprises four main stages:
Opening and confirming a BGP connection with a neighbor router
Maintaining the BGP connection
Sending reachability information
Notification of error conditions
Notification Open
Keep Alive
Update
ASX
BGP
ASY
BGP
3376\3376FCZA Figure 97. BGP Messages Flow between BGP Speakers
Opening and Confirming a BGP Connection: BGP communication between two routers commences with the TCP transport protocol connection being established.
Once the connection has been established, each router sends an open message to its neighbor.
The BGP open message, like all BGP messages, consists of a standard header plus packet-type specific contents. The standard header consists of a 16-octet maker field, which is set to all ones when the autentication code is 0, the length of the total BGP packet, and a type field that specifies the packet to be one of four possible types:
1. OPEN7