4.3 Border Gateway Protocol (BGP)

Border Gateway Protocol version 4 (BGP-4), which is defined in RFC 1771, is a classless interdomain routing protocol used primarily to provide and exchange network reachability information between domains or autonomous systems. It uses TCP port 179 and supports CIDR. BGP-4 is one of the methods used to make a connection to the Internet via an Internet service provider (ISP). BGP-4 is increasingly important in larger environments to communicate with the Internet agent or (ISP). However, if your network is a simple one, using static and default routes may be configurations that are more appropriate.

BGP-4 is an extremely complex path vector protocol that is used within the Internet and multinational organizations. Its main purpose is to connect very large networks that are mainly autonomous systems. It makes use of routing updates. At the start of a session, full routing updates are sent. Thereafter, trigger updates are sent while the session is active. This makes BGP-4 appropriate in these environments. The protocol is not interested in communicating a full knowledge of every subnet within the organization. It takes summarization to the extreme, communicating only that which is defined, as necessary. The routing update carries a list of autonomous system numbers and aggregated prefix addresses, as well as some policy routing information. The little information that it carries is extremely important, so great efforts are made to ensure the reliability of the transport carrying the updates and to ensure that the databases are synchronized. This is the pinnacle of hierarchical routing design. Because of this, the transport medium for BGP is TCP, which provides an additional layer of reliability. Policy-based routing is another distinctive characteristic of BGP-4. Unlike interior routing protocols, BGP-4 can be configured to advocate one path above another. This is done in a more sophisticated and controlled manner than can the metric afforded to the interior routing protocols.

BGP-4 is connection-oriented. When a neighbor is seen, a TCP peering session is established and maintained. BGP-4 probes keepalives sent out periodically to sustain the link and maintain the session. These keepalives are the 19 byte header used in the BGP updates. Having established the session, the routing tables are exchanged and synchronized. The routers now send incremental updates only when changes occur. The update refers to a single path and the networks that may be reached via that path. Having corrected the routing table, the BGP-4 process propagates the change to all neighbors, with a few exceptions, based on an algorithm to ensure a loop-free network.

4.3.1 BGP Messages Types

The BGP-4 operation uses four different message types. These are:

OPEN messages, which are the first messages to be sent after a TCP session has been established between one or more BGP peers. This message is used to identify the AS that the router is a member of and to agree on protocol parameters and the protocol timers that the peers will use during the session.
KEEPALIVE messages, which are used to maintain connections and verify paths held by the router sending the keepalive message;
UPDATE messages, which contains the actual topology information sent between two BGP routers. An UPDATE message can contain a new route and/or routes to be withdrawn, but can only contain one new route; and
NOTIFICATION messages, which is used to inform the receiving BGP router of errors. As soon as a BGP router sends a NOTIFICATION message, it immediately terminates its BGP connection.

The message information is contained in various message fields that are specific to the message type. However, a common message header precedes the fields of each message type. The common header contains three fields: a marker field, which is up to 2 bytes long and is used for security and synchronization; the length field, which indicates the size of the entire BGP message including the header; and the type field, which indicates the type of message being sent.

4.3.2 Types of BGP-4

There are two types of BGP-4: Internal BGP-4 (iBGP-4) and External BGP-4 (eBGP-4). The difference depends on the function of the routing protocol. The router will determine if the peer BGP-4 router is going to be an external BGP-4 peer or an internal BGP-4 peer by checking the autonomous system number in the open message that was sent.

Internal BGP-4 is used within an autonomous system (AS). It conveys information to all BGP-4 routers within the domain and ensures that they have a consistent understanding of the available networks. Internal BGP-4 is used within an ISP or a large organization to coordinate the knowledge of that AS. The routers are not required to be physical neighbors on the same medium, and are often located on the edges of the network. Internal BGP-4 is used to convey BGP-4 information about other ASs across a transit autonomous system. Another routing protocol, an interior routing protocol such as OSPF, is used to route the BGP-4 packets to their remote locations. To achieve this, internal BGP requires the destination BGP neighbor's IP address to be contained within the normal routing table kept by another routing protocol.
External BGP-4 complies with the common perception of an external routing protocol; it sends routing information between differing ASs. Therefore, the border router between different ASs is the external BGP router.

4.3.3 BGP-4 Synchronization

Before iBGP-4 can propagate a route into another AS handing it over to eBGP-4, the route must be totally known within the AS. In other words, the Internal Gateway Protocol (IGP) or internal routing protocol must be synchronized with BGP-4. This ensures that if traffic is sent into the AS, the interior routing protocol can direct it to its destination. It thus prevents traffic from being forwarded to unreachable destinations and reduces unnecessary traffic. It also ensures consistency within the AS.

Synchronization is enabled by default, but, in some case it may be useful to turn off synchronization, such when all the routers in the AS are running BGP-4, or when all the routers inside the AS are meshed, or when the AS is not a transit domain, i.e., an AS that is used to carry BGP-4 updates from one AS to another

4.3.4 BGP-4 Policy-Based Routing

Policy-based routing allows you to define how traffic will be routed at the AS level. This is a level of control above the dynamic routing protocol. Given that many variables in BGP-4 can influence dynamic routing; this is a very high level of control. This other dimension distinguishes BGP-4 from other routing protocols. Policy-based routing is a form of static routing enforced by specialized access lists called route maps.

There are some rules that are associated with Policy routing. These rules are:

Traffic can be directed on either the source address or both the source and destination addresses.
It affects only the next hop in the path to the destination.
It does not affect the destination of the packet, only the path used to get to the destination.
It does not allow traffic sent into another AS to take a different path from the one that would have been chosen by that AS.
It is possible to influence only how traffic will get to a neighboring AS, not how it will be routed within that AS.
It is configured on the inbound interface because it examines the source address

4.3.5 BGP-4 Attributes

Attributes in BGP-4 are used to determine the best path, and are the metric for BGP-4. However, they also carry information that decisions are based on. The variables describe characteristics or attributes of the path to the destination. These characteristics can be used to distinguish the paths, and this allows a choice to be made among the paths. Furthermore, some of the information carried in the update messages is more important than others. Because of this, it has been categorized by importance.

There are two types of attributes: well-known attributes and optional attributes. The well-known attributes are those attributes that are mandatory, while the optional attributes are optional. Both types of attributes are subdivided into two further categories, allowing for considerable granularity. The categories of BGP-4 attributes are listed below:

Mandatory; and
Discretionary.

Optional

Routers may not recognize optional attributes. If this is the case, it marks the update as partial and sends the update, complete with attributes, to the next router. Thus, the optional attributes traverse the router unchanged, if they are not recognized. The two subcategories are:

Transitive; and
Nontransitive.

Nontransitive attributes are dropped if they fall onto a router that does not understand or recognize the attribute. These attributes will not be propagated to the BGP-4 peers. Unrecognized nontransitive 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.

The table below lists the various BGP-4 attributes supported by Cisco.

Category	Description
Well-known	These are required and are therefore recognized by all BGP-4 implementations. It does not need to be present in the update messages, but if they are, all routers running BGP-4 will recognize and act on the information contained. The two subcategories are: Mandatory; and Discretionary.
Optional	Routers may not recognize optional attributes. If this is the case, it marks the update as partial and sends the update, complete with attributes, to the next router. Thus, the optional attributes traverse the router unchanged, if they are not recognized. The two subcategories are: Transitive; and Nontransitive. Nontransitive attributes are dropped if they fall onto a router that does not understand or recognize the attribute. These attributes will not be propagated to the BGP-4 peers. Unrecognized nontransitive 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.

Attribute	Category	Code	Preference	Description
AS_Path	Well-known, mandatory	2	Shortest path	This attribute is a sequence of the ASs that the packet has traversed.
Next hop	Well-known, mandatory	3	Shortest path or IGP metric	This attribute states the next hop on the path for the router to take. In EBGP-4, this will be the source address of the router that sent the update. In IBGP-4, for routes originated outside the AS, the address will still be the source address of the router that sent the update.
Multiple Exit Discriminator (MED)	Optional, nontransitive	4	Lowest value	This attribute informs routers outside the AS which path to take into the AS. It is known as the external metric of a route. Therefore, it is passed between the ASs, but it will not be propagated into a third AS.
Local preference	Well-known, discretionary	5	Highest value	This attribute is used to tell routers within the AS how to exit the AS if multiple paths exist. It is passed solely between IBGP peers.
Atomic aggregate	Well-known, discretionary	6	Information not used in path selection	This attribute states that the routes have been aggregated and that some information has been lost.
Aggregator	Optional, transitive	7	Information not used in path selection	This attribute states the BGP-4 router ID and autonomous system number of the router that was responsible for aggregating the route.
Community	Optional, transitive	8	Information not used in path selection	This is the capability to tag certain routes that have something in common. They are thereby made members of the same club or community. This is often used in conjunction with another attribute that will affect route selection for the community. For example, the use of the local preference and community attributes would allow the network administrators and other privileged beings to use the high-speed link to the Internet, while others shared a fractional T1. Communities have no geographical or logical limits. BGP-4 can filter on incoming or outgoing routes for filtering, redistribution, or path selection.
Originator ID	Optional, nontransitive	9	Information not used in path selection	The route reflector appends this attribute. It carries the router ID of the originating router in the local autonomous system. It is used to prevent loops.
Cluster list	Optional, nontransitive	10	Information not used in path selection	This attribute identifies the routers involved in the route reflection. It shows the reflection path that has been taken and is used to prevent looping errors.
Weight	Cisco-defined		Highest value	This is a Cisco proprietary attribute used in route selection. It is local to the router and is not propagated to other routers. Therefore it has no compatibility problems.

4.3.6 Basic BGP-4 Configuration

To connect to another AS, you must configure the start of the routing process, the networks to be advertised, and the BGP-4 neighbor that the routing process will be synchronizing routing tables with over a TCP session.

4.3.7 Starting the Routing Process

You can configure the routing process using the same command as seen for the interior routing protocols. The syntax for this command is:

router bgp autonomous_system_number

4.3.8 Defining the Networks to Be Advertised

To define the network that is to be advertised for the AS, you can use the following network command:

network network number mask network mask

For each network you must issue a separate network command. The network command determines the networks that are originated by the router. This command does not identify the interfaces upon which to run BGP; instead, it states the networks that are to be advertised by BGP. The network command must include all the networks in the AS to be advertised, not just those that are directly connected to the router.

4.3.9 Identifying Neighbors and Defining Peer Groups

In IBGP-4, the remote autonomous system number that is defined for the BGP-4 peer will be the same; in EBGP-4, these numbers will differ. The syntax is as follows:

neighbor ip_address | peer_group_name remote-as autonomous_system_number

The use of the peer_group_name allows the identification of this router as a member of a peer group. A peer group is a group of neighbors that share the same update policy. This is the mechanism by which routers can be grouped to simplify configuration.

4.3.10 Forcing the Next-Hop Address

On a multiaccess network, the rule is that the source address of a packet is that of the router that originated the packet onto the network. This can cause problems on a NBMA network that appears to be a multiaccess network but that in reality may not have full connectivity to all the routers on the network. If the source address is the address of the initiating router, the other routers may not have a path to this next hop, and packets will be dropped. To overcome this problem, you can use the neighbor command to configure the next-hop address to be that of the transmitting router. The syntax for this command is:

neighbor { ip_address | peer_group } next-hop-self

4.3.11 Disabling Synchronization

Synchronization is enabled by default, but, in some case it may be useful to turn off synchronization such as if the IBGP-4 network is fully meshed. You can use the no synchronization command to turn off synchronization. This allows routers to advertise routes into BGP-4 before the IGP has a copy of the route in its routing table.

4.3.12 Aggregating Routes

To summarize or aggregate routes within the BGP-4 domain, you can use the aggregate-address command in config-router mode. The syntax for this command is:

aggregate-address ip_address subnet_ma.sk [ summary-only ] [ as-set ]

This command has two optional parameters:

the summary-only parameter, which suppresses the specific routes and propagate only the summary route;
and the as-set parameter, which records all the AS that have been traversed in the update message. This is the default configuration.

4.3.13 Effecting BGP-4 Configuration Changes

After you perform configuration changes in BGP-4, you must reset the TCP session between neighbors. You can accomplish this by using the clear ip command. The syntax for his command is:

clear ip bgp { * | ip_address }[ soft [ in | out ] ]

The clear ip command disconnects the session between the neighbors and re-establishes it using the new configuration that has been entered. The soft option does not tear down the sessions, but it resends the updates. The in and out options allow the configuration of inbound or outbound soft updates. The default is for both.

4.3.14 Verifying Basic BGP-4 Configuration

There are a number of show commands, as well as a debug command, that can be used to trouble shoot the BGP-4 configuration. These commands are:

show ip bgp, which displays the BGP routing table.
show ip bgp paths, which displays the topology table.
show ip bgp summary, which displays information about the TCP sessions.
show ip bgp neighbors, which displays information about the TCP connections to neighbors.
debug ip bgp [ dampening | events | keepalives | updates ], which displays live

information of events as they occur. These options limit the output to the specific type of information.

4.3.15 Advanced BGP-4 Configuration

4.3.15.1 Configuring Route Reflectors

With internal BGP-4, a fully meshed configuration is required to ensure full connectivity. An IBGP-4 router will propagate a route if it is a route generated by the transmitting router, or if it is a connected route. If the router was learned via an update from a BGP-4 peer within the same AS, it can propagate this route only to an EBGP-4 peer. For this reason, IBGP-4 peers must all be fully meshed to have a complete knowledge of the network. The problem is that BGP-4 maintains up-to-date and accurate routing information by sending incremental updates across a TCP connection. The TCP connection is a costly in network resources. The greater the number of connections, the greater the number of required resources. The n (n - 1) / 2 equation can be used to determine the number of required IBGP-4 sessions, when n is the number of routers.

The problem presented by a fully meshed IBGP-4 network can be solved by proper network design. If a hub-and-spoke network were developed, this would streamline the TCP connections. This is a good thing, but it does require some additional design and configuration. The solution is the implementation of route reflectors and the network design that they support. The only design requirement is that the IBGP-4 route reflectors must be fully meshed to ensure the correct propagation of updates.

A route reflector is a router that has been configured to forward routing updates to neighbors or peers within the same AS. These IBGP-4 peers need to be identified in the configuration. The route reflector defies the split horizon rule that states that the IBGP-4 router will not propagate a route that was learned from a peer within the same AS. However, when a router has been configured as a route reflector, it forwards learned paths from IBGP-4 peers to other IBGP-4 peers. It forwards only to those routers that have been identified as route reflectors and to IBGP/EBGP neighbors clients. This means that a logical hub-and-spoke design can be implemented within an AS between IBGP-4 peers, thus reducing the number of required IBGP-4 sessions.

A route reflector is a router that forwards updates to its clients. When a client, i.e., a router that receives updates from a route reflector, sends an update to the route reflector, it is forwarded or reflected to the other clients. Therefore, both a route reflector and a client form a unit, called a cluster, that shares information. The AS is divided into clusters, and there must be at least one route reflector per cluster. The route reflector connects to other route reflectors. These route reflectors need to be fully meshed. This is to ensure that the IBGP-4 routing tables are complete. Furthermore, non-clients must be fully meshed with the route reflector. When the route reflector forwards an update, the Originator-ID attribute is set. This is the BGP-4 router ID of the router that originated the path. The purpose of this attribute is not to award honors to the originating router, but so that if this router receives back the update, it will see its own ID and will ignore the packet. This prevents the possibility of routing loops. If there are multiple route reflectors in the cluster, to provide redundancy, then the originating router is identified by the Cluster-ID attribute. This serves the same purpose as the Originator-ID in preventing routing loops.

A neighbor command is used to configure a route reflector. The syntax for this command is:

neighbor ip_address route-reflector-client

You can use the no form of this command, as in no neighbor ip_address route-reflector-client, to remove a router as a client.

In this command, the ip_address is the IP address of the neighboring router being identified as a client while the route-reflector-client parameter points to the client of the route reflector. The client is not configured and is unaware of its change of status. It does nothing but continue to send updates to the route reflector, which forwards them unchanged to other clients.

4.3.15.2 Controlling BGP-4 Traffic

BGP-4 updates can be controlled. It is often advantageous to limit the way that the BGP-4 routing updates are propagated. This not only streamlines the traffic flow on the network, but it also simplifies the network and its maintenance. Designing how the routing information should be forwarded through the network forms a basic level of security and can reduce the possibility of routing loops. Filtering is a means of traffic control. There are three main types of filtering on a Cisco router. These are:

Access list, which is used in BGP-4 for the creation of route maps. It is also used to filter updates sent from a peer based on the AS path. In addition, other technologies use access lists for standard filtering.
Prefix list/distribute list, which filter routing updates, particularly in redistribution. From Cisco IOS version 11.2, ISPs were given prefix lists, which are a more efficient form of filtering. Prefix lists filter based on the prefix of the address. This option was made a part of the general release IOS in version 12.0. Both prefix lists and distribute lists filter on network numbers, not autonomous system paths, for which access lists are used.
Route maps, which is a sophisticated access list that defines criteria upon which a router acts when a match is found for the stated criteria. It is used in BGP-4 for setting the attributes that determine the basis for selecting the best path to a destination.

You can create an entry in a prefix list and assigns a sequence number to the entry by issuing the

ip prefix-list command. The syntax for this command is:

ip prefix-list list_name [ seq seq_number ] { deny | permit }

network/length [ ge ge_value ] [ le le_value ]

In this command, the seq option can be used to manually specify the sequence number. The network/length parameter states the prefix to be matched and the length of the prefix. The ge keyword is used if the prefix is greater than the value stated in the list, while the le keyword is used if the prefix is less than the value stated in the list.

You can configure a router to use a prefix list as a filter in distributing routes by using the following neighbor command:

neighbor { ip_address | peer_group }

prefix-list prefix-list-name { in | out }

4.3.15.3 Redundant Connections into the Internet

An enormous amount of traffic leaves an organization in search of the Internet. This is not only the use of email as a means of communication, but also people doing research on the Internet. The majority of it is valid work. As the use of the Internet expands as both an individual tool and a major mechanism of finance and commerce, it becomes increasingly necessary for the network administrator to provide constant access to the Internet, with load balancing and redundancy. This can be achieved by having more than one link to the Internet. This is called multihoming.

There are some concerns about connecting to more than one ISP. The ISPs may not each be propagating the same routes into or from the Internet. If the providers are sending subsets of the required routes, there could be a major problem with connectivity if the link to one of the providers fails. In addition, it is possible that if you are connected to two different ISPs, your AS could become a transit autonomous system between the ISPs. This could happen if a router in the AS of one ISP sees a path to a destination via the other ISP's AS and your AS provides the best route to the AS of the other ISP. Configuration at the ISP level is the solution to these concerns and is dealt with when setting up the service. Therefore, it is important that the need for multihoming is raised during the negotiations so that the ISP is aware of the need for the additional configuration.

4.3.15.4 Determining the BGP-4 Path by Configuring the Attributes

You can configure BGP-4 to take a path to a destination based on different criteria. The local preference attribute, and the weight attribute can be configured to influence the choice of path.

The weight attribute selects the exit path out of the router when there are multiple paths to the same destination. The higher the weight value, the better the path. To configure the weight attribute, you can use the neighbor command. The syntax for this command is:

neighbor { ip_address | peer_group_name } weight weight

In this command, ip_address is the IP address of the neighboring router; peer_group_name identifies the BGP-4 peer group, if there is one; and weight weight specifies the weight attribute and its value. This is used in route selection. The default is 327 68, but the range extends from 0 to 65535.

The local preference attribute can be configured by using the bgp default local-preference command. The syntax for this command is:

bgp default local-preference value

In this command, value has a range from 0 to 4,294,967,295.

4.3.16 Verifying Advanced BGP-4 Configuration

There are a number of show commands that can be used to troubleshoot the advanced BGP-4 configuration.

These commands are:

show ip prefix-list [ detail | summary ], which displays information about all prefix lists, including the hit count, which is the number of times that a match has been found for the criteria in the prefix list. This is very important in troubleshooting for capacity planning and security.

show ip prefix-list [detail | summary] name, which displays a table showing the entries in a prefix list identified by name.

show ip prefix-list name [ network/length ], which displays the filtering associated with the node based on the absolute of the defined prefix.

show ip prefix-list name [ seq seq_number ], which displays the prefix list entry with a given sequence number.

show ip bgp, which displays all the values of all the BGP-4 attributes and their status.