BGP runs in either of the following modes on the process the router, as shown in Figure 1:
Internal BGP (IBGP)
External BGP (EBGP)
When BGP runs within an AS, it is called IBGP; however, when it runs between ASs, it is called EBGP.
Speaker: Any router that sends BGP messages is called a BGP speaker. The speaker receives or generates new routing information and then advertises the routing information to other BGP speakers. After receiving a route from another AS, the BGP speaker compares the route with its local routes. If the route is better than its local routes, or the route is new, the speaker advertises it to all its other remote BGP speakers except the one that has advertised the route.
Peer: BGP speakers that exchange messages with each other are called peers.
BGP runs by sending five types of messages: Open, Update, Notification, Keepalive, and Route-refresh.
Open: first message sent after a TCP connection is set up. An Open message is used to set up a BGP peer relationship. After a peer receives the Open message and negotiation between the local device and peer succeeds, the peer sends a Keepalive message to confirm and maintain the peer relationship. Then, the peers can exchange Update, Notification, Keepalive, and Route-refresh messages.
Update: This type of message is used to exchange routes between peers. An Update message can advertise multiple reachable routes with the same attributes and can be used to delete multiple unreachable routes.
An Update message can be used to advertise multiple reachable routes that share the same set of attributes. These attributes are applicable to all destinations (expressed by IP prefixes) in the network layer reachability information (NLRI) field of the Update message.
An Update message can be used to withdraw multiple unreachable routes. Each route is identified by its destination address (using the IP prefix), which identifies the routes previously advertised between BGP speakers.
An Update message can be used only to delete routes. In this case, it does not need to carry the route attributes or NLRI. When an Update message is used only to advertise reachable routes, it does not need to carry information about routes to be withdrawn.
Notification: If error conditions are detected, BGP sends Notification messages to its peers. The BGP connections are then torn down immediately.
Keepalive: BGP periodically sends Keepalive messages to peers to ensure the validity of BGP connections.
Route-refresh: This type of message is used to request that peers re-send all reachable routes to the local device.
If all BGP devices are enabled with the route-refresh capability and an import routing policy changes, the local device sends Route-refresh messages to its peers. Upon receipt, the peers re-send their routing information to the local device. This ensures that the local BGP routing table is dynamically updated and the new routing policy is used without tearing down BGP connections.
The BGP Finite State Machine (FSM) has six states: Idle, Connect, Active, OpenSent, OpenConfirm, and Established.
Three common states during the establishment of BGP peer relationships are Idle, Active, and Established.
In the Idle state, BGP denies all connection requests. This is the initial status of BGP.
In the Connect state, BGP decides subsequent operations after a TCP connection is established.
In the Active state, BGP attempts to set up a TCP connection. This is the intermediate status of BGP.
In the OpenSent state, BGP is waiting for an Open message from the peer.
In the OpenConfirm state, BGP is waiting for a Notification or Keepalive message.
In the Established state, BGP peers can exchange Update, Route-refresh, Keepalive, and Notification messages.
The BGP peer relationship can be established only when both BGP peers are in the Established state. Both peers send Update messages to exchange routes.
BGP adopts TCP as its transport layer protocol. Therefore, a TCP connection must be available between the peers. BGP peers negotiate parameters by exchanging Open messages to establish a BGP peer relationship.
After the peer relationship is established, BGP peers exchange BGP routing tables. BGP does not require a periodic update of its routing table. Instead, Update messages are exchanged between peers to update their routing tables incrementally if BGP routes change.
BGP sends Keepalive messages to maintain the BGP connection between peers.
If BGP detects an error (for example, it receives an error message), BGP sends a Notification message to report the error, and the BGP connection is torn down accordingly.
BGP route attributes are a set of parameters that describe specific BGP routes, and BGP can filter and select routes based on these attributes. BGP route attributes are classified into the following four types:
Well-known mandatory: This type of attribute can be identified by all BGP devices and must be carried in Update messages. Without this attribute, errors occur in the routing information.
Well-known discretionary: This type of attribute can be identified by all BGP devices. As this type of attribute is optional, it is not necessarily carried in Update messages.
Optional transitive: This indicates the transitive attribute between ASs. A BGP device may not recognize this type of attribute, but will still accept messages carrying it and advertise them to other peers.
Optional non-transitive: If a BGP device does not recognize this type of attribute, the device ignores it and does not advertise messages carrying it to other peers.
The most common BGP route attributes are as follows:
The Origin attribute defines the origin of a BGP route and has the following three types:
IGP: This type of attribute has the highest priority. IGP is the Origin attribute for routes obtained through an IGP in the AS from which the routes originate. For example, the Origin attribute of the routes imported to the BGP routing table using the network command is IGP.
EGP: This type of attribute has the second highest priority. The Origin attribute of the routes obtained through EGP is EGP.
Incomplete: This type of attribute has the lowest priority and indicates the routes learned through other modes. For example, the Origin attribute of the routes imported by BGP using the import-route command is Incomplete.
The AS_Path attribute records the numbers of all ASs through which a route passes from the local end to the destination in the distance-vector order.
When a BGP speaker advertises a local route:
When advertising the route beyond the local AS, the BGP speaker adds the local AS number to the AS_Path list and then advertises this attribute to peer routers through Update messages.
When advertising the route within the local AS, the BGP speaker creates an empty AS_Path list in an Update message.
When a BGP speaker advertises a route learned from the Update message of another BGP speaker:
When advertising the route beyond the local AS, the BGP speaker adds the local AS number to the far left side of the AS_Path list. From the AS_Path attribute, the BGP device that receives the route learns the ASs through which the route passes to the destination. The number of the AS closest to the local AS is placed on the far left side of the list, and the other AS numbers are listed next to the former in sequence.
When advertising the route within the local AS, the BGP speaker does not change its AS_Path attribute.
The AS_Confed_Sequence and AS_Confed_Set attributes are used to prevent routing loops and select routes among the member ASs in a confederation.
Different from the Next_Hop attribute in an IGP, the Next_Hop attribute in BGP is not necessarily the IP address of a peer router. In most cases, the Next_Hop attribute complies with the following rules:
When advertising a route to an EBGP peer, a BGP speaker sets the Next_Hop of the route to the address of the local interface used to establish the EBGP peer relationship.
When advertising a locally generated route to an IBGP peer, a BGP speaker sets the Next_Hop of the route to the address of the local interface used to establish the IBGP peer relationship.
When advertising a route learned from an EBGP peer to an IBGP peer, a BGP speaker does not change the Next_Hop of the route.
The MED is transmitted only between two neighboring ASs, and the AS that receives the MED does not advertise it to a third AS.
Similar to the metric used by an IGP, the MED is used to determine the optimal route when traffic enters an AS. If the router running BGP obtains multiple routes from different EBGP peers and these routes have different next hops but the same destination, the BGP device selects the route with the smallest MED value.
The Local_Pref attribute indicates the preference of a BGP route on the router. It is available only to IBGP peers and is not advertised to other ASs.
The Local_Pref attribute determines the optimal route for the traffic that leaves an AS. When a BGP router obtains multiple routes to the same destination address but with different next hops through IBGP peers, the route with the largest Local_Pref value is selected.