Border Gateway Protocol (BGP)

History of BGP

The first network was ARPANET, which the department of defense developed, and the Advanced Research Project Agency designed it. In Arpanet, only one network exists, which was handled by the single administrator. All the routers were the part of the single network, and the routing was performed with the help of the GGP (Gateway to Gateway Routing Protocol). The GGP was the first protocol among all the routing protocols. The autonomous system numbers were not used in the GGP protocol. 

When the internet came into the market, then GGP started creating the problem. As the internet backbone became large due to which the routing table was also large, which led to the maintenance issue. To resolve this issue, the ARPANET was divided into multiple domains, known as autonomous systems. Each autonomous system can be handled individually, and each system has its own routing policy, and the autonomous system contains the small routing database. When the autonomous system concept was implemented, then the first routing protocol came known as RIP that runs on the single autonomous system. To connect the one autonomous system with another autonomous system, EGP (Exterior Gateway Protocol) protocol was developed. The EGP protocol was launched in 1984, defined in RFC 904. The EGP protocol was used for five years, but it had certain flaws due to which the new protocol known as Border Gateway Protocol (BGP) was developed in 1989, defined in RFC 1105.

There are many versions of BGP, such as:

• BGP version 1: This version was released in 1989 and is defined in RFC 1105.
• BGP version 2: It was defined in RFC 1163.
• BGP version 3: It was defined in RFC 1267.
• BGP version 4: It is the current version of BGP defined in RFC 1771. 

What is an autonomous system?

The Internet is a network of networks. It is broken up into hundreds of thousands of smaller networks known as autonomous systems (ASes). Each of these networks is essentially a large pool of routers run by a single organization.
If we continue to think of BGP as the Postal Service of the Internet, ASes are like individual post office branches. A town may have hundreds of mailboxes, but the mail in those boxes must go through the local postal branch before being routed to another destination. The internal routers within an AS are like mailboxes. They forward their outbound transmissions to the AS, which then uses BGP routing to get these transmissions to their destinations.

• An AS is a group of routers that share similar routing policies and operate within a single administrative domain.
• An AS typically belongs to one organization.
• If an AS connects to the public Internet using an exterior gateway protocol such as BGP, then it must be assigned a unique AS number which is managed by the Internet Assigned Numbers Authority (IANA).
• AS numbers can be between 1 to 65,535.
• Regional internet registry (RIR) manages the AS numbers between 1 and 64,512.
• The 64,512 - 65,535 numbers are reserved for private use (like IP Private addresses).
• The IANA is enforcing a policy whereby organizations that connect to a single provider use an AS number from the private pool.

Note:
The AS pool of addresses was predicted to run out by 2012.
For this reason, the IETF has released RFC 4893 and RFC 5398.
These RFCs describe BGP extensions to increase the AS number from the two-octet (16-bit) field to a four-octet (32-bits) field, increasing the pool size from 65,536 to 4,294,967,296 values

Border Gateway Protocol (BGP) is the postal service of the Internet. When someone drops a letter into a mailbox, the Postal Service processes that piece of mail and chooses a fast, efficient route to deliver that letter to its recipient. Similarly, when someone submits data via the Internet, BGP is responsible for looking at all of the available paths that data could travel and picking the best route, which usually means hopping between autonomous systems.
BGP is the protocol that makes the Internet work by enabling data routing. When a user in Singapore loads a website with origin servers in Argentina, BGP is the protocol that enables that communication to happen quickly and efficiently.

BGP Features

The following are the features of a BGP protocol:

• Open standard: It is a standard protocol which can run on any window device.
• Exterior Gateway Protocol: It is an exterior gateway protocol that is used to exchange the routing information between two or more autonomous system numbers.
• InterAS-domain routing: It is specially designed for inter-domain routing, where interAS-domain routing means exchanging the routing information between two or more autonomous number system.
• Supports internet: It is the only protocol that operates on the internet backbone.
• Classless: It is a classless protocol.
• Incremental and trigger updates: Like IGP, BGP also supports incremental and trigger updates.
• Path vector protocol: The BGP is a path vector protocol. Here, path vector is a method of sending the routes along with routing information. A path vector protocol defines a route as a pairing between a destination and the attributes of the path to that destination.
• Configure neighborhood relationship: It sends updates to configure the neighborhood relationship manually. Suppose there are two routers R1 and R2. Then, R1 must send the configure command saying that you are my neighbor. On the other side, R2 also must send the configure command to R1, saying that R1 is a neighbor of R2. If the configure commands match, then the neighborhood relationship will get developed between these two routers.
• Application layer protocol: It is an application layer protocol and uses TCP protocol for reliability.
• Metric: It has lots of attributes like weight attribute, origin, etc. BGP supports a very rich number of attributes that can affect the path manipulation process.
• Administrative distance: If the information is coming from the external autonomous system, then it uses 20 administrative distances (eBGP). If the information is coming from the same autonomous system, then it uses 200 administrative distances(iBGP).

BGP Peers (Neighbors)

For BGP to function, BGP routers (called speakers) must form neighbor relationships (called peers).
There are two types of BGP neighbor relationships:

• iBGP Peers – BGP neighbors within the same autonomous system.
• eBGP Peers – BGP neighbors connecting separate autonomous systems.

By default, BGP assumes that eBGP peers are a maximum of one hop away. This restriction can be bypassed using the ebgp-multihop option with the neighbor command.
iBGP peers do not have a hop restriction and are dependent on the underlying IGP of the AS to connect peers together. By default, all iBGP peers must be fully meshed within the Autonomous System.

BGP Peers Messages

BGP forms its peer relationships through a series of messages.

OPEN Message
First, an OPEN message is sent between peers to initiate the session. It is used to establish a BGP adjacency. Both sides negotiate session capabilities before a BGP peering establishes. The OPEN message contains the BGP version number, ASN of the originating router, Hold Time, BGP Identifier, and other optional parameters that establish the session capabilities.

• BGP Version – must be the same between BGP peers
• Hold Time - The Hold Time attribute sets the Hold Timer in seconds for each BGP neighbor.

Upon receipt of an UPDATE or KEEPALIVE, the Hold Timer resets to the initial value. If the Hold Timer reaches zero, the BGP session is torn down, routes from that neighbor are removed, and an appropriate update route withdraw message is sent to other BGP neighbors for the impacted prefixes. The Hold Time is a heartbeat mechanism for BGP neighbors to ensure that the neighbor is healthy and alive.
When establishing a BGP session, the routers use the smaller Hold Time value contained in the two router’s OPEN messages. The Hold Time value must be at least three seconds, or zero. For Cisco routers the default hold timer is 180 seconds.

• BGP Identifier

The BGP Router-ID (RID) is a 32-bit unique number that identifies the BGP router in the advertised prefixes as the BGP Identifier. The RID can be used as a loop prevention mechanism for routers advertised within an autonomous system. The RID can be set manually or dynamically for BGP. A nonzero value must be set for routers to become neighbors. The dynamic RID allocation logic varies between the following operating systems.

• IOS: IOS nodes use the highest IP address of the any up-loopback interfaces. If there is not an up-loopback interface, then the highest IP address of any active up interfaces becomes the RID when the BGP process initializes.
• IOS XR: IOS XR nodes use the IP address of the lowest up loopback interface. If there is not any up-loopback interfaces, then a value of zero (0.0.0.0) is used and prevents any BGP adjacencies from forming.
• NX-OS: NX-OS nodes use the IP address of the lowest up loopback interface. If there is not any up-loopback interfaces, then the IP address of the lowest active up interface becomes the RID when the BGP process initializes.

KEEPALIVE
BGP does not rely on the TCP connection state to ensure that the neighbors are still alive. Keepalive messages are exchanged every one-third of the Hold Timer agreed upon between the two BGP routers. Cisco devices have a default Hold Time of 180 seconds, so the default Keepalive interval is 60 seconds. If the Hold Time is set for zero, no Keepalive messages are sent between the BGP neighbors.
 
UPDATE
The Update message advertises any feasible routes, withdraws previously advertised routes, or can do both. The Update message includes the Network Layer Reachability Information (NLRI) that includes the prefix and associated BGP PAs when advertising prefixes. Withdrawn NLRIs include only the prefix. An UPDATE message can act as a Keepalive to reduce unnecessary traffic.
 
NOTIFICATION Message
A Notification message is sent when an error is detected with the BGP session, such as a hold timer expiring, neighbor capabilities change, or a BGP session reset is requested. This causes the BGP connection to close.

As a BGP peer session is forming, it will pass through several states. This process is known as the BGP Finite-State Machine (FSM):

BGP State (Finite-State Machine)

Idle State:

• Refuse all incoming BGP connections.
• Start the initialization of event triggers.
• Initiates a TCP connection with its configured BGP peer.
• Listens for a TCP connection from its peer.
• Changes its state to Connect.
• If an error occurs at any state of the FSM process, the BGP session is terminated immediately and returned to the Idle state. Some of the reasons why a router does not progress from the Idle state are:

TCP port 179 is not open.
A random TCP port over 1023 is not open.
Peer address configured incorrectly on either router.
AS number configured incorrectly on either router.

Connect State:

• Waits for successful TCP negotiation with peer.
• BGP does not spend much time in this state if the TCP session has been successfully established.
• Sends Open message to peer and changes state to OpenSent.
• If an error occurs, BGP moves to the Active state. Some reasons for the error are:

TCP port 179 is not open.
A random TCP port over 1023 is not open.
Peer address configured incorrectly on either router.
AS number configured incorrectly on either router. 

Active State:

• If the router was unable to establish a successful TCP session, then it ends up in the Active state.
• BGP FSM tries to restart another TCP session with the peer and, if successful, then it sends an Open message to the peer.
• If it is unsuccessful again, the FSM is reset to the Idle state.
• Repeated failures may result in a router cycling between the Idle and Active states. Some of the reasons for this include:

TCP port 179 is not open.
A random TCP port over 1023 is not open.
BGP configuration error.
Network congestion.
Flapping network interface.

OpenSent State:

• BGP FSM listens for an Open message from its peer.
• Once the message has been received, the router checks the validity of the Open message.
• If there is an error it is because one of the fields in the Open message does not match between the peers, e.g., BGP version mismatch, the peering router expects a different My AS, etc. The router then sends a Notification message to the peer indicating why the error occurred.
• If there is no error, a Keepalive message is sent, various timers are set and the state is changed to OpenConfirm.

OpenConfirm State:

• The peer is listening for a Keepalive message from its peer.
• If a Keepalive message is received and no timer has expired before reception of the Keepalive, BGP transitions to the Established state.
• If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state.

Established State:

• In this state, the peers send Update messages to exchange information about each route being advertised to the BGP peer.
• If there is any error in the Update message then a Notification message is sent to the peer, and BGP transitions back to the Idle state. 

BGP Path Attributes

• BGP utilizes several attributes to determine the best path to a destination.
• BGP metrics are called path attributes. 
• Path attributes are a set of BGP metrics describing the path to a network (route).
• A BGP update message includes a variable-length sequence of path attributes describing the route.
• A path attribute consists of three fields:

Attribute type
Attribute length
Attribute value

• As we know that path-vector routing is used in the border gateway routing protocol, which contains the routing table that shows the path information. 
• The path attributes provide the path information. The attributes that show or store the path information are known as path attributes. This list of attributes helps the receiving router to make a better decision while applying any policy. Let's see the different types of attributes.

Each BGP update consists of one or more IP subnets and a set of attributes attached to them. Some of the attributes are required to be recognized by all BGP implementations. Those attributes are called well-known BGP attributes.
Attributes that are not well-known are called optional.
Each attribute is identified by a code:

• Origin – Code 1
• AS-Path - Code 2
• Next Hop - Code 3
• MED - Code 4
• Local Preference - Code 5
• Automatic Aggregate - Code 6
• Aggregator - Code 7
• Community - Code 8

ORIGIN

ORIGIN is a well-known mandatory attribute that defines the origin of the path information.
The ORIGIN attribute is generated by the speaker that originates the associated routing information. Its value SHOULD NOT be changed by any other speaker.
The data octet can assume the following values:

• 0 à IGP

The route is interior to the originating AS and normally occurs when a network command is used to advertise the route via BGP.
An origin of IGP is indicated with an “i” in the BGP table.

• 1 à EGP

(Obsolete) The route is learned via EGP which is considered a historic routing protocol and is not supported on the Internet.
An origin of EGP is indicated with an “e” in the BGP table.

• 2 à INCOMPLETE

The route’s origin is unknown or is learned via some other means and usually occurs when a route is redistributed into BGP.
An incomplete origin is indicated with a “?” in the BGP table.

AS_PATH

AS_PATH is a well-known mandatory attribute. This attribute identifies the autonomous systems through which routing information carried in the Update message has passed. When a route is advertised from the local AS to another AS, each passed AS number is added into the AS_PATH attribute, allowing the receiver to determine the ASs for routing back the message.

• The path segment type is a 1-octet length field with the following values defined:
• The path segment length is a 1-octet length field, containing the number of ASes (not the number of octets) in the path segment value field.
• The path segment value field contains one or more AS numbers, each encoded as a 2-octet length field.

The AS_PATH attribute contains a list of AS numbers to reach a route.
Usually, a BGP router does not receive routes containing the local AS number to avoid routing loops.
In some applications, you can apply a routing policy to control BGP route selection by modifying the AS_PATH length.
By configuring an AS path filtering list, you can filter routes based on AS numbers contained in the AS_PATH attribute.

The AS-Path attribute is applied to outbound routes, dictating the best inbound path. Two things can be accomplished with the AS-Path attribute, prepend or filter.

AS-Path Prepend

To prepend to (or add to) the existing AS-Path results in a longer AS-Path, which makes the route less desirable for inbound traffic:
RouterB(config)# access-list 5 permit 10.5.0.0 0.0.255.255
RouterB(config)# route-map ASPREPEND permit 10
RouterB(config-route-map)# match ip address 5
RouterB(config-route-map)# set as-path prepend 200 200
RouterB(config-route-map)# route-map ASPREPEND permit 20
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 route-map ASPREPEND out

The artificial AS-Path information is not added to a route until it is advertised to an eBGP peer.
RouterC’s BGP routing table will now look as follows:
RouterC# show ip bgp
 Network Next Hop Metric LocPrf Weight Path
* 10.5.0.0 172.16.1.1 0 100 0 100 200 200 i
*> 10.5.0.0 172.17.1.1 0 100 0 100 i

Notice the inflated AS-Path through RouterB. RouterC will prefer the path through RouterD to reach the 10.5.0.0/16 network.

AS-Path Filtering
Additionally, routes can be filtered based on AS-Path values, using an aspath access-list. This requires the use of regular expressions:

^ = Start of a string
$ = End of a string
. = Any one character
* = Any one or more characters, including none
+ = Any one or more characters
? = Any one character, including none
_ = Serves the function of virtually all of the above

The following examples illustrate the use of regular expressions:

^100_ = learned from AS 100
_100$ = originated from AS 100
^$ = originated locally
.* = matches everything
_100_ = any instance of AS 100

To configure RouterF to only accept routes that originated from AS100:
RouterF(config)# ip as-path access-list 15 permit _100$
RouterF(config)# route-map ASFILTER permit 10
RouterF(config-route-map)# match as-path 15
RouterF(config)# router bgp 50
RouterF(config-router)# neighbor 10.5.1.1 route-map ASFILTER in

To view what BGP routing entries the AS-Path access-list will match:
RouterF# show ip bgp regexp _100$

NEXT_HOP

This is a well-known mandatory attribute that defines the IP address of the border router that should be used as the next hop to the destinations listed in the Network Layer Reachability field of the UPDATE message.
Therefore, for eBGP, the next-hop address is the IP address of the neighbor that sent the update.
The BGP next-hop attribute is also necessary when routes received from an ebgp speaker which plays the role of an edge router, are advertised to an ibgp speaker within the same AS.

For iBGP, when a route is advertised to an iBGP speaker and sourced into the BGP as-group, all iBGP routers will have for next-hop the ip address of the ebgp neighbor.
To prevent the iBGP next hop problem, we can make sure that a route advertised to an ibgp router; echoes the IP address of the router sourcing that route into the AS to the ibgp neighbors; and not the IP address of the ebgp speaker which originally advertised this route.
To avoid potential this, it is better to make use of the “next-hope-self” attribute to force the iBGP speaker to set the next-hop of the route advertised to its own IP address.

MULTI_EXIT_DISC (MED)

• The Multiple Exit Discriminator (MED) attribute, also called the metric, provides a hint to external neighbors about the preferred path into an AS that has multiple entry points.
• MED can be used to advertise to your neighbors how they should enter your AS.
• MED is exchanged between autonomous systems.
• The lowest MED is the preferred path.
• MED is propagated to all routers within the neighbor AS but not passed along any other autonomous systems.
• MED (also called metric) is exchanged between autonomous systems, and you can use it to let the other AS know which path they should use to enter your AS.

Local Preference

• The Local Preference attribute provides an indication to the “local” routers in the AS about which path is preferred to exit the AS.
• Local preference is the second BGP attribute.
• You can use local preference to choose the outbound external BGP path.
• Local preference is sent to all internal BGP routers in your autonomous system.
• Not exchanged between external BGP routers.
• Local preference is a well-known and discretionary BGP attribute.
• Default value is 100.
• The path with the highest local preference is preferred

ATOMIC_AGGREGATE

Atomic aggregate is a Well-Known Discretionary attribute; it must be recognized by all BGP implementations and does not have to exist in all BGP updates.
The Atomic Aggregate attribute is attached to a route that is created as a result of route summarization (called aggregation in BGP). It signals that information that was present in the original routing updates may have been lost when the updates were summarized into a single entry.
Attribute is set to either True or False with “true” alerting other BGP routers that multiple destinations have been grouped into a single update.

• The Atomic Aggregate attribute informs BGP peers that the local router is using a less specific (aggregated) route to a destination.
• If a BGP speaker 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 speaker used an aggregated route.
• When you use the Atomic Aggregate attribute, 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 is the RID of the router that performs the route aggregation. 
• Atomic Aggregate is a well-known attribute and Aggregator is an optional, transitive attribute.
• When some routes are aggregated by an aggregator, the aggregator does attach its Router-ID to the aggregated route into the AGGREGATOR_ID attribute and it sets the ATOMIC_AGGREGATE attribute or not; based on whether the AS_PATH information of the aggregated routes were preserved or not.

Atomic aggregation used to inform the neighbor that the originated router aggregated routes
Aggregator attributes specify the IP & ASN of the router that does

Community

• A Community is a numerical value that can be attached to certain routes as they pass a specific point in the network. 
• The community value can then be checked at other points in the network for filtering or route selection purposes. 
• BGP configuration may cause routes with a specific community value to be treated differently than others.
• More than one BGP community per route allowed.  By default, communities are stripped in outgoing BGP updates.
• Private range: 0x00010000 – 0xFFFEFFFF

BGP communities can be assigned using one of three 32-bit formats:

• Decimal (1000000)
• Hexadecimal (0x1A2B3C)
• AA:NN (100:20)

The AA:NN format specifies a 16-bit AS number (the AA), and a 16-bit generic community identifier (NN). By default, the decimal format for communities will be displayed when viewing a route. To force the router to display the AA:NN format:

RouterA(config)# ip bgp-community new-format

A BGP community is bit of “extra information” that you can add to one of more prefixes which is advertised to BGP neighbors. This extra information can be used for things like traffic engineering or dynamic routing policies. There are 4 well known BGP communities that you can use or you can pick a numeric value that you can use for your own policies.

• Internet: advertise the prefix to all BGP neighbors.
• No-Advertise: don’t advertise the prefix to any BGP neighbors.

When you add the no-advertise community to a prefix then the receiving BGP router will use and store the prefix in its BGP table, but it won’t advertise the prefix to any other neighbors.

• No-Export: don’t advertise the prefix to any eBGP neighbors.

The well-known BGP community no export tells BGP neighbors to advertise a prefix only to iBGP neighbors.

 

• Local-AS: don’t advertise the prefix outside of the sub-AS (this one is used for BGP confederations).

The local AS community is a well-known BGP community and can be used for BGP confederations. It’s basically the same as the no export community but this one works for within the sub-AS of a confederation. Prefixes that are tagged are only advertised to other neighbors in the same sub-AS, not to other sub-AS’es or eBGP routers.

BGP Route Selection Process

1. Prefer the path with the highest weight. This is a value that is local to the router and it’s Cisco proprietary. The default value is 0 for all routes that are not originated by the local router.
2. The local preference is used within an autonomous system and exchanged between iBGP routers. We prefer the path with the highest local preference. The default value is 100.
3. Prefer the path that the local router originated. In the BGP table, you will see next hop 0.0.0.0. You can get a path in the BGP table through the BGP network command, aggregation, or redistribution. A BGP router will prefer routes that it installed into BGP itself over a route that another router installed in BGP.
4. Prefer the path with the shortest AS path length. For example, AS path 1 2 3 is preferred over AS path 1 2 3 4 5.
5. Prefer the lowest origin code. There are three origin codes: IGP, EGP, INCOMPLETE. IGP is lower than EGP and EGP is lower than INCOMPLETE.
6. Prefer the path with the lowest MED. The MED is exchanged between autonomous systems.
7. Prefer eBGP (external BGP) over iBGP (internal BGP) paths.
8. Prefer the path within the autonomous system with the lowest IGP metric to the BGP next hop.
9. Determine if multiple paths require installation in the routing table for BGP Multipath.
10. When both path are external, prefer the path that we received first, in other words, the oldest path.
11. Prefer the path with the lowest BGP neighbor router ID. The router ID is based on the highest IP address. If you have a loopback interface, then the IP address on the loopback will be used. The router ID can also be manually configured.
12. If the originator or router ID is the same for multiple paths, prefer the path with the minimum cluster list length.
13. Prefer the path with the lowest neighbor IP address. If you have two eBGP routers and two links in between, then the router ID will be the same. In this case, the neighbor IP address is the tiebreaker.

BGP Route Dampening

Route dampening “suppresses” routes that are flapping, minimizing unnecessary convergence and updates. If a route flap (goes up and down), it is assigned a penalty (default is 1000). All routes start with a penalty of 0, and the local router maintains a history of routes that have flapped. Once the penalty reaches a specific threshold, the route is suppressed. When a route is suppressed, it is neither advertised nor used locally on the router.

First, the routes to be “observed” must be identified using an access-list or prefix-list:

Router(config)# ip prefix-list MYLIST seq 10 permit 10.1.0.0/16
Router(config)# ip prefix-list MYLIST seq 20 permit 10.2.0.0/16

Next, dampening values must be configured using a route-map:

Router(config)# route-map MYMAP permit 10
Router(config-route-map)# match ip address prefix-list MYLIST
Router(config-route-map)# set dampening 15 750 2000 60

The above values for the set dampening command represent the defaults.

• The 15 (measured in minutes) indicates the half-life timer. If a route is assigned a penalty, half of the penalty will decay after this timer expires.
• The 750 (arbitrary penalty measurement) indicates the bottom threshold. Once a penalized route falls below this threshold, it will no longer be suppressed.
• The 2000 (arbitrary penalty measurement) indicates the top threshold. If a route flaps to the point that its penalty exceeds this threshold, it is suppressed.
• The 60 (measured in minutes) indicates the maximum amount of time a route can be suppressed.

Finally, route-dampening must be enabled under the BGP process:

Router(config)# router bgp 100
Router(config-router)# bgp dampening route-map MYMAP

BGP Backdoor

Recall that an external BGP route has an Administrative Distance (AD) of 20, which is less than the default AD of IGP’s, such as OSPF or EIGRP. Under certain circumstances, this may result in sub-optimal routing. If both an IGP route and eBGP route exist to the same network, and the IGP route

should be preferred, there are two workarounds:

• Globally change BGP’s default Administrative Distance values.
• Use the BGP network backdoor command.

Cisco does not recommend changing BGP’s default AD values. If necessary, however, the distance bgp will adjust the AD for external, internal, and locally-originated BGP routes, respectively:
Router(config)# router bgp 100
Router(config-router)# distance bgp 150 210 210

The preferred workaround is to use the BGP network backdoor command, which adjusts the AD for a specific eBGP route (by default, from 20 to 200), resulting in the IGP route being preferred:
Router(config)# router bgp 100
Router(config-router)# network 10.5.0.0 mask 255.255.0.0 backdoor

BGP Summarization

Routes that are redistributed into BGP are automatically summarized. To disable auto-summary:
Router(config)# router bgp 100
Router(config-router)# no auto-summary

To manually create a summary address for the following group of networks:
172.16.0.0/24; 172.16.1.0/24; 172.16.2.0/24; 172.16.3.0/24
The aggregate-address command must be used:
Router(config)# router bgp 100
Router(config-router)# aggregate-address 172.16.0.0 255.255.252.0

BGP’s default configuration is to send both the summary (aggregated) address and the more specific individual routes. To only send the summary route:
Router(config)# router bgp 100
Router(config-router)# aggregate-address 172.16.0.0 255.255.252.0 summary-only

To suppress (or summarize) only specific routes, instead of all routes, a route-map must be used:
Router(config)# access-list 5 permit 172.16.0.0 0.0.0.255
Router(config)# access-list 5 permit 172.16.1.0 0.0.0.255
Router(config)# route-map SUPPRESS permit 10
Router(config-route-map)# match ip address 5
Router(config)# router bgp 100
Router(config-router)# aggregate-address 172.16.0.0 255.255.252.0 summary-only route-map SUPPRESS

The access-list details the routes that should be suppressed. To allow the summarized routes to retain their AS-Path information:
Router(config)# router bgp 100
Router(config-router)# aggregate-address 172.16.0.0 255.255.252.0 summary-only route-map SUPPRESS as-set

BGP Confederations

Confederations are an alternative method to alleviate the requirement that all iBGP routers be fully meshed. Confederations are essentially ASs within an AS, and are sometimes referred to as sub-AS’s.
In the above example, RouterA belongs to AS 777 and RouterB belongs to AS 888. Both of those AS’s belong to a parent AS of 300. RouterA and RouterB will form an eBGP peer session.
Configuration is simple:

RouterB(config)# router bgp 888
RouterB(config-router)# bgp confederation identifier 300
RouterB(config-router)# bgp confederation peer 777
RouterB(config-router)# neighbor 10.1.1.1 remote-as 777
RouterB(config-router)# neighbor 172.16.1.2 remote-as 500

Notice that the sub-AS (777) is used in the router bgp statement.
Additionally, the parent AS must be specified using a bgp confederation identifier statement. Finally, any confederation peers must be identified.
RouterC will be unaware of RouterB’s confederation status. Thus, RouterC’s neighbor statement will point to AS 300, and not AS 888:

RouterC(config)# router bgp 500
RouterC(config-router)# neighbor 172.16.1.1 remote-as 300

iBGP Source IP Address

Problem

• BGP does not accept unsolicited updates. It must be aware of every neighboring router and have a neighbor statement for it.
• For example, when a router creates and forwards a packet, the IP address of the outbound interface is used as that packet’s source address by default.
• For BGP packets, this source IP address must match the address in the corresponding neighbor statement on the other router or the routers will not establish the BGP session.
• This is not a problem for eBGP neighbors as they are typically directly connected.
• When multiple paths exist between IBGP neighbors, the BGP source address can cause problems

Solution

Establish the IBGP session using a loopback interface.

Router(config-router)# neighbor {ip-address | peer-group-name} update-source loopback interface-number

• Informs the router to use a loopback interface address for all BGP packets.
• Overrides the default source IP address for BGP packets.
• Typically, only used with IBGP sessions.
• As a bonus, physical interfaces can go down for any number of reasons, but loopbacks never fail.

Basic Configuration

Router(config)#

router bgp autonomous-system	Define BGP as the IP routing protocol. Only one instance of BGP can be configured on the router at a single time.
neighbor {ip-address | peer group-name} remote-as autonomous-system	Identify peer router with which to establish a BGP session.

• The autonomous-system value is either an internally generated number (if not connecting to a provider network) or obtained from an ISP or RIR.
• The autonomous-system value is used to identify if the session is with internal BGP (IBGP) peers or with external BGP (EBGP) peers.
• If the value is the same as the router’s AS, then an IBGP session is attempted.
• If the value is not the same as the router’s AS, then an EBGP session is attempted.