BGP
This section covers BGP theory and design concepts. The current version of BGP, Version 4, is defined in RFC 1771 (March 1995). BGP is an interdomain routing protocol. What this means is that you use BGP to exchange routing information between autonomous systems. The primary function of BGP is to provide and exchange network-reachability information between domains or autonomous systems. BGP is a path vector protocol that is suited for setting routing policies between autonomous systems. In the enterprise campus architecture, BGP is used in the Internet connectivity module.
BGP is the de facto standard for routing between service providers on the Internet because of its rich features. You can also use it to exchange routes in large internal networks. The Internet Assigned Numbers Authority (IANA) reserved TCP Port 179 to identify the BGP protocol. BGPv4 was created to provide CIDR, a feature that was not present in the earlier versions of BGP. BGP is a path-vector routing protocol; it is neither a distance-vector nor link-state routing protocol.
BGP Neighbors
BGP is usually configured between two directly connected routers that belong to different autonomous systems. Each autonomous system is under different technical administration. BGP is frequently used to connect the enterprise to service providers and to interconnect service providers, as shown in Figure 12-1. The routing protocol within the enterprise could be any interior gateway protocol (IGP). Common IGP choices include RIPv2, EIGRP, Open Shortest Path First (OSPF), and Intermediate System-to-Intermediate System (IS-IS). BGPv4 is the only deployed exterior gateway protocol (EGP). AS numbers are a managed resource allocated by the American Registry of Internet Numbers (ARIN). In IP, the AS numbers 64,512 through 65,535 are allocated to IANA and are designated for private use.
)
Figure 12-1 BGP Neighbors
Before two BGP routers can exchange routing updates, they must become established neighbors. After BGP routers establish a TCP connection, exchange information, and accept the information, they become established neighbors and start exchanging routing updates. If the neighbors do not reach an established state, they do not exchange BGP updates. The information exchanged before the neighbors are established includes the BGP version number, AS number, BGP router ID, and BGP capabilities.
eBGP
eBGP is the term used to describe BGP peering between neighbors in different autonomous systems. As required by RFC 1771, the eBGP peers share a common subnet. In Figure 12-2, all routers speak eBGP with routers in other autonomous systems. Within AS 500, the routers communicate using iBGP, which is covered next.
)
Figure 12-2 eBGP Used Between Autonomous Systems
iBGP
iBGP is the term used to describe the peering between BGP neighbors in the same AS. iBGP is used primarily in transit autonomous systems. Transit autonomous systems forward traffic from one external AS to another external AS. If transit autonomous systems did not use iBGP, the eBGP-learned routes would have to be redistributed into an IGP and then redistributed into the BGP process in another eBGP router. Normally the number of eBGP routes is too large for an IGP to handle.
iBGP provides a better way to control the routes within the transit AS. With iBGP, the external route information (attributes) is forwarded. The various IGPs that might be used do not understand or forward BGP attributes, including AS paths, between eBGP routers.
Another use of iBGP is in large corporations where the IGP networks are in smaller independent routing domains along organizational or geographic boundaries. In Figure 12-3, a company has decided to use three independent IGPs: one for the Americas; another for Asia and Australia; and another for Europe, the Middle East, and Africa. Routes are redistributed into an iBGP core.
)
Figure 12-3 iBGP in a Large Corporation
Other Uses of iBGP
The CCDA should know at a high level these other uses for IBGP:
- Applying policies in the internal AS with the help of BGP path attributes—BGP path attributes are covered in a later section.
- QoS Policy Propagation on BGP (QPPB)—QPPB uses iBGP to spread common QoS parameters from one router to other routers in the network. It classifies packets using IP precedence bits based on BGP community lists, BGP AS paths, and access lists. After packets are classified, QoS features can enforce policies.
- Multiprotocol BGP peering of Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPN)—The multiprotocol version of BGP is used to carry MPLS VPN information between all PE routers within a VPN community.
Route Reflectors
iBGP requires that all routers be configured to establish a logical connection with all other iBGP routers. The logical connection is a TCP link between all iBGP-speaking routers. The routers in each TCP link become BGP peers. In large networks, the number of iBGP-meshed peers can become very large. Network administrators can use route reflectors to reduce the number of required mesh links between iBGP peers. Some routers are selected to become the route reflectors to serve several other routers that act as route-reflector clients. Route reflectors allow a router to advertise or reflect routes to clients. The route reflector and its clients form a cluster. All client routers in the cluster peer with the route reflectors within the cluster. The route reflectors also peer with all other route reflectors in the internetwork. A cluster can have more than one route reflector.
In Figure 12-4, without route reflectors, all iBGP routers are configured in an iBGP mesh, as required by the protocol. When Routers A and G become route reflectors, they peer with Routers C and D; Router B becomes a route reflector for Routers E and F. Routers A, B, and G peer among each other.
)
Figure 12-4 Route Reflectors
Routers A and G are configured to peer with each other and with Routers B, C, and D. The configuration of Routers C and D is different from the rest; they are configured to peer with Routers A and G only. All route reflectors in the same cluster must have the same cluster ID number.
Router B is the route reflector for the second cluster. Router B peers with Routers A and G and with Routers E and F in its cluster. Routers E and F are route-reflector clients and peer only with Router B. If Router B goes down, the cluster on the right goes down because no second route reflector is configured.
Confederations
Another method to reduce the iBGP mesh within an AS is BGP confederations. With confederations, the AS is divided into smaller, private autonomous systems, and the whole group is assigned a confederation ID. The private AS numbers or identifiers are not advertised to the Internet but are contained within the iBGP networks. The routers within each private AS are configured with the full iBGP mesh. Each private AS is configured with eBGP to communicate with other semiautonomous systems in the confederation. External autonomous systems see only the AS number of the confederation, and this number is configured with the BGP confederation identifier.
In Figure 12-5, a confederation divides the AS into two.
)
Figure 12-5 BGP Confederations
Routers A, B, and G are configured for eBGP between the private autonomous systems. You configure these routers with the bgp confederation identifier command. The confederation identifier number is the same for all routers in the network. You use the bgp confederation peers command to identify the AS number of other private autonomous systems in the confederation. Because Routers A and G are in AS 10, the peer confederation to Router B is AS 20. Router B is in AS 20, and its peer confederation to Routers A and G is AS 10. Routers C and D are part of AS 10 and peer with each other and with Routers A and G. Routers E and F are part of AS 20 and peer with each other and with Router B.
BGP Administrative Distance
The Cisco IOS Software assigns an administrative distance to eBGP and iBGP routes, as it does with other routing protocols. For the same prefix, the route with the lowest administrative distance is selected for inclusion in the IP forwarding table. Because iBGP-learned routes do not have metrics associated with the route as IGPs (OSPF and EIGRP) do, iBGP-learned routes are less trusted. For BGP, the administrative distances are
- eBGP routes—20
- iBGP routes—200
BGP Attributes, Weight, and the BGP Decision Process
BGP is a protocol that uses route attributes to select the best path to a destination. This subsection describes BGP attributes, the use of weight to influence path selection, and the BGP decision process.
BGP Path Attributes
BGP uses several attributes for the path-selection process. BGP uses path attributes to communicate routing policies. BGP path attributes include next hop, local preference, AS path, origin, multiexit discriminator (MED), atomic aggregate, and aggregator. Of these, the AS path is one of the most important attributes: It lists the number of AS paths to reach a destination network.
BGP attributes can be categorized as well-known or optional. Well-known attributes are recognized by all BGP implementations. Optional attributes do not have to be supported by the BGP process; they are used on a test or experimental basis.
Well-known attributes can be further subcategorized as mandatory or discretionary. Mandatory attributes are always included in BGP update messages. Discretionary attributes might or might not be included in the BGP update message.
Optional attributes can be further subcategorized as transitive or nontransitive. Routers must advertise the route with transitive attributes to its peers even if it does not support the attribute locally. If the path attribute is nontransitive, the router does not have to advertise the route to its peers.
The following subsections cover each attribute category.
Next-Hop Attribute
The next-hop attribute is the IP address of the next IP hop that will be used to reach the destination. The next-hop attribute is a well-known mandatory attribute. With eBGP, the eBGP peer sets the next hop when it announces the route. Multiaccess networks use the next-hop attribute where there is more than one BGP router.
Local Preference Attribute
The local preference attribute indicates which path to use to exit the AS. It is a well-known discretionary attribute used between iBGP peers and is not passed on to external BGP peers. In Cisco IOS Software, the default local preference is 100. The higher local preference is preferred.
The default local preference is configured on the BGP router with an external path; it then advertises its local preference to internal iBGP peers. Figure 12-6 shows an example of the local preference attribute where Routers B and C are configured with different local preference values. Router A and other iBGP routers then receive routes from both Router B and Router C. Router A prefers using Router C to route Internet packets because it has a higher local preference (400) than Router B (300). The arrows represent the paths taken to go out of the AS.
)
Figure 12-6 BGP Local Preference
Origin Attribute
Origin is a well-known mandatory attribute that defines the source of the path information. Do not confuse the origin with comparing whether the route is external (eBGP) or internal (iBGP). The origin attribute is received from the source BGP router. There are three types:
- IGP—Indicated by an i in the BGP table. Present when the route is learned by way of the network statement.
- EGP—Indicated by an e in the BGP table. Learned from EGP.
- Incomplete—Indicated by a ? in the BGP table. Learned from redistribution of the route.
In terms of choosing a route based on origin, BGP prefers routes that have been verified by an IGP over routes that have been learned from EGP peers, and BGP prefers routes learned from eBGP peers over incomplete paths.
AS Path Attribute
The AS path is a well-known mandatory attribute that contains a list of AS numbers in the path to the destination. Each AS prepends its own AS number to the AS path. The AS path describes all the autonomous systems a packet would have to travel to reach the destination IP network. It is used to ensure that the path is loop-free. When the AS path attribute is used to select a path, the route with the fewest AS hops is preferred. In the case of a tie, other attributes, such as MED, break the tie. Example 12-1 shows the AS path for network 200.50.32.0/19. To reach the destination, a packet must pass autonomous systems 3561, 7004, and 7418. The command show ip bgp 200.50.32.0 displays the AS path information.
Example 12-1. AS Path Attribute
Router#show ip bgp 200.50.32.0
BGP routing table entry for 200.50.32.0/19, version 93313535
Paths: (1 available, best #1)
Not advertised to any peer
3561 7004 7418
206.24.241.181 (metric 490201) from 165.117.1.219 (165.117.1.219)
Origin IGP, metric 4294967294, localpref 100, valid, internal, best
Community: 2548:182 2548:337 2548:666 3706:153
MED Attribute
The MED attribute, also known as a metric, tells external BGP peers the preferred path into the AS when multiple paths into the AS exist. In other words, MED influences which one of many paths a neighboring AS uses to reach destinations within the AS. It is an optional nontransitive attribute carried in eBGP updates. The MED attribute is not used with iBGP peers. The lowest MED value is preferred, and the default value is 0. Paths received with no MED are assigned a MED of 0. The MED is carried into an AS but does not leave the AS.
Consider the diagram shown in Figure 12-7. With all attributes considered equal, consider that Router C selects Router A as its best path into AS 100 based on Router A's lower router ID (RID). If Router A is configured with a MED of 200, then that will make Router C select Router B as the best path to AS 100. No additional configuration is required on Router B, because the default MED is 0.
)
Figure 12-7 MED Attribute
Community Attribute
Although it is not an attribute used in the routing-decision process, the community attribute groups routes and applies policies or decisions (accept, prefer) to those routes. It is a group of destinations that share some common property. The community attribute is an optional transitive attribute of variable length.
Atomic Aggregate and Aggregator Attributes
The atomic aggregate attribute informs BGP peers that the local router used a less specific (aggregated) route to a destination without using a more specific route.
If a BGP router selects a less specific route when a more specific route is available, it must attach the atomic aggregate attribute when propagating the route. The atomic aggregate attribute lets the BGP peers know that the BGP router used an aggregated route. A more specific route must be in the advertising router's BGP table before it propagates an aggregate route.
When the atomic aggregate attribute is used, the BGP speaker has the option to send the aggregator attribute. The aggregator attribute includes the AS number and the IP address of the router that originated the aggregated route. In Cisco routers, the IP address used is the RID of the router that performs the route aggregation. Atomic aggregate is a well-known discretionary attribute, and aggregator is an optional transitive attribute.
Weight
Weight is assigned locally on a router to specify a preferred path if multiple paths exist out of a router for a destination. Weights can be applied to individual routes or to all routes received from a peer. Weight is specific to Cisco routers and is not propagated to other routers. The weight value ranges from 0 to 65,535. Routes with a higher weight are preferred when multiple routes exist to a destination. Routes that are originated by the local router have a default weight of 32,768.
You can use weight instead of local preference to influence the selected path to external BGP peers. The difference is that weight is configured locally and is not exchanged in BGP updates. On the other hand, the local preference attribute is exchanged between iBGP peers and is configured at the gateway router.
When the same destinations are advertised from both Router B and Router C, as shown in Figure 12-8, Router A prefers the routes from Router C over Router B because the routes received from Router C have a larger weight (600) locally assigned.
)
Figure 12-8 BGP Weight
BGP Decision Process
By default, BGP selects only a single path to reach a specific destination (unless you specify maximum paths). The Cisco implementation of BGP uses a simple decision process. When the path is selected, BGP puts the selected path in its routing table and propagates the path to its neighbors.
To select the best path to a destination, Cisco routers running BGP use the following algorithm in the following order:
- If the specified next hop is inaccessible, drop the path.
- If the path is internal, synchronization is enabled, and the path is not in the IGP, drop the path.
- Prefer the path with the largest weight. (This step is Cisco-specific, and weight is localized to the router.)
- Prefer the path with the largest local preference. iBGP uses this path only to reach the preferred external BGP router.
- Prefer the path that was locally originated via a network or aggregate BGP subcommand or through redistribution from an IGP. Local paths sourced by network or redistribute commands are preferred over local aggregates sourced by the aggregate-address command. (This step is Cisco-specific.)
- If no route was originated, prefer the route that has the shortest AS path. (This step is Cisco-specific.)
- If all paths have the same AS path length, prefer the path with the lowest origin type. Paths with an origin type of IGP (lower) are preferred over paths originated from an EGP such as BGP, and EGP origin is preferred over a route with an incomplete origin. (This step is Cisco-specific.)
- If the origin codes are the same, prefer the path with the lowest MED attribute. An eBGP peer uses this attribute to select a best path to the AS. (This step is a tiebreaker, as described in the RFC that defines the BGP.)
- If the paths have the same MED, prefer the external (eBGP) path over the internal (iBGP) path. (This step is Cisco-specific.)
- If the paths are still the same, prefer the path through the closest IGP neighbor (best IGP metric). (This step is a tiebreaker, as described in the RFC that defines the BGP.)
- Prefer the path with the BGP neighbor with the lowest router ID. (The RFC that defines the BGP describes the router ID.)
After BGP decides on a best path, it marks it with a > sign in the show ip bgp table and adds it to the IP routing table.
BGP Summary
The characteristics of BGP follow:
- BGP is an exterior gateway protocol (EGP) used in routing in the Internet. It is an interdomain routing protocol.
- BGP is a path vector routing protocol suited for strategic routing policies.
- It uses TCP port 179 to establish connections with neighbors.
- BGPv4 implements CIDR.
- eBGP is used for external neighbors. It is used between different autonomous systems.
- iBGP is used for internal neighbors. It is used within an AS.
- BGP uses several attributes in the routing-decision algorithm.
- It uses confederations and route reflectors to reduce BGP peering overhead.
- The MED (metric) attribute is used between autonomous systems to influence inbound traffic.
- Weight is used to influence the path of outbound traffic from a single router, configured locally.