BGP

BGP does not use metrics for best patch selection. Instead it uses a series of Path attributes. toc =BGP neighbor relationships=

Neighbor relationships are formed over a TCP connection (Port 179), the only routing protocol to do so. They exchange BGP update messages which contain the routing information. To form a neighbor, each router must have the other's IP address explicitly configured. If BGP receives a neighbor request from a router whose address was not configured, the request is rejected.

One the BGP session is brought up, the neighbors exchange BGP open messages. This brings them to the established state, at which point they can begin to exchange BGP update messages.

BGP neighbor relationships can be forcefully closed with the //**#neighbor  shutdown**// command. All neighbors can be reset with //**#clear ip bgp** *//



Internal BGP Peers

 * Peers within the same AS are considered iBGP peers
 * Often use the loopback address for peering to increase availability
 * Can use peer-groups to configure, which allows configuration to be grouped and applied to a neighbors with a single command. BGP routers will also only generate one set of update messages for the peer group, reducing overhead.

External BGP Peers

 * For eBGP connections, IOS defaults the TTL to 1. If the peer if more than 1 hop away, you must specify the TTL with the multihop option in the neighbor command

Neighbor requirements

 * The source IP address on received connection requests must match the IP configured in the neighbor command
 * A routers ASN (configured in router bgp [asn]) must must the peers ASN in the neighbor command. (Exception is confederations)
 * The RIDs must be unique
 * Authentication must pass if configured

BGP also uses keepalive and hold timers, which do not have to match. If they are different, the lowest of the two values are used.

BGP Neighbor states
= = =Building the BGP table=

The BGP topology table, or RIB, contains the NLRI and Path attributes learned by BGP.

Using the //network// command
The network command in BGP differs from IGPs. When a network command is configured, it will look for a route exactly matching that configured with the network command, and if found, places that information into the NLRI table. If that route is removed from the routing table, BGP deletes the information about that route and notifies its neighbors that the route has been withdrawn. The syntax of the command is: //** #network { network-number [mask network-mask ]} [route-map map-tag ] **//

Redistribution
Since BGP uses PAs to determine the best route, there is no requirement to set the metric when redistributing into BGP. If a metric is set, BGP assigns this value to the Multi Exist Discriminator (MED)

Impact of auto-summary
Similar to IGPs, the configuration of auto-summary causes a classful summarized route to be advertised if any component subnets exist. However, unlike IGPs, BGP will summarize only routes injections due to redistribution or the network command. The behaviors vary depending on which is being evaluated:


 * **redsitribute**: If the redistribution would inject **//subnets//** of a classful network, instead inject just the classful network
 * **network**: For network commands that list a classful network and no netmask, inject the summary if at least one component subnet exists. The component subnets are still injected

Manual summarization and AS_PATH
The **#aggregate-address** command can be used to summarized a prefix of any length, and based on any routes in the BGP table.

The AS_PATH attribute consists of four different segments:


 * 1) AS_SEQ: The idea of the AS_PATH representing all ASNs in order, through which the route has been advertised.
 * 2) AS_SET: An unordered list of all the ASNs in the AS_SEQ
 * 3) AS_CONFED_SEQ
 * 4) AS_CONFED_SET

The //**#aggregate-address**// command can create a summary for which the AS_SEQ is null. This happens when the component subnets of a summary have differing AS_SEQ values and therefore, an accurate path through the network cannot be determined. This can create routing loops since the AS_SEQ is used to prevent them by determine the AS' through which the route has already been advertised. This problem is solved by the AS_SET segment.

A manual summary can be be done by creating a static route with the destination of null0, then matching that route with a network command. This method would not suppress any of the component routes.

The following list define some characteristics of the //**#aggregate-address**// command:


 * A summary is not created if no matching NLRI exist in the BGP table for the defined address
 * If all component subnets are withdrawn, so is the summary
 * The NEXT_HOP of the summary, as seen in the BGP table, is set to 0.0.0.0
 * The NEXT_HOP of the summary, as advertised to neighbors, is set to the update-source associated with each neighbor
 * If the AS_SEQ of all component subnets match, the AS_SEQ of the summary route will be set to that.
 * The AS_SEQ is set to null if there is a difference in the AS_SEQ of the component subnets
 * If the **as-set** option is specified, an AS_SET segment is created for the summary contained the AS_SEQ of the component routes. This only occurs if the AS_SEQ of the summary is null
 * By default, the component subnets are also advertised. This can be changed so only the summary is advertised with the **summary-only** option. The //**#suppress-map**// command can be used to advertise a subnet of the components.



Adding default routes
Default routes can be injected in 3 ways:


 * 1) Using the network command
 * 2) Using the redistribute command
 * 3) Using the //**#neighbor [neighbor-id] default-information route-map [route-map-name]**// subcommand

When injecting a default using the network command, a 0.0.0.0/0 route must exist in the routing table. If this route is removed from the routing table, BGP will also withdrawn the default route.

Injecting a default route via redistribution requires some additional configuration. First, the //**#default-information originate**// command must exist, then you must use #redistribute static.

Using the neighbor command, a route is not even injected into the local BGP table. Instead, it is advertised directly to the specified neighbor. This method also does not even check for the existence of a default route in the routing table, but it can be configured to. With the route map option, the IP routing table is checked and a default is advertised if a permit clause is matched. The **route-map check-default** option will cause BGP to check for the existence of a default route before advertising.

ORIGIN PA
Depending on how a route is injected into the BGP table, one of 3 ORIGIN PA codes may be assigned: IGP, EGP or incomplete. This can be a bit confusing. Routes injected into the BPG table from an IGP have an origin code of incomplete. EGP is a reference the predecessor of BGP and should not be seen in modern networks.



When used with the aggregate-address command, a few other rules apply:


 * If the **as-set** option is not used, the origin code **i** is applied
 * If the **as-set** option is used, and all component subnets have the origin code i, then the origin code i is applied
 * If the **as-set** option is used, and the component subnets have varying origin codes, the origin code ? is applied.

=Advertising routes to neighbors=

Not all routes are advertised to every neighbor: While the BGP best selection process is a bit complicated, it can be summed up in the following four basic steps:


 * 1) Choose the route with the shortest AS_PATH
 * 2) If tie, prefer an eBGP route over an iBGP route
 * 3) If tie, choose route with lowest metric
 * 4) If tie, choose iBGP route with lowest RID of advertising router

For a route to be considered "best" the NEXT_HOP of the route must be one of the following:


 * 0.0.0.0, meaning it was injected locally
 * Reachable via an existing route in the routing table

When advertising updates, the NEXT_HOP behaviors can vary depending on the type of peer: //*Note that the NEXT_HOP PA cannot be set via a route map. The above methods are the only solution for altering it.//

When troubleshooting, you can view the routes sent to a neighbor with **#sh ip bgp neighbor  advertised-routes** and routes received from a neighbor with //**#sh ip bgp neighbor  received-routes** (For this command to work,// **#****neighbor  soft-reconfiguration inbound** must be configured).

As a result of BGP not altering the next-hop of some routes, a recursive route lookup may be required.

=Building the IP routing Table=

Adding eBGP learned routes
There are only two requirements for adding an eBGP route to the IP routing table


 * The route must be considered a "best" route
 * If the same route has been learned by a iBGP router or static routes, the AD for the external routes must be lower

The AD of BGP routes are 20 for external and 200 for both internal and locally injected. These can be overridden in two ways:


 * The //**#distance bgp  **// command
 * The //**#distance {ip-address {wildcard-mask}} [ip-standard-list | ipextended-list]**// bgp subcommand

Backdoor routes
The //**#network backdoor**// command can be used if you want to use a private link to reach a network instead of a eBGP learned route. The following actions occur when using this:


 * The local AD (default is 200) is used when referencing the specified route
 * The route is not advertised with BGP from the configured router

Adding iBGP learned routes
The same two requires as eBGP learned routes apply


 * Must be a "best route"
 * Must have a better AD than any other routing sources

An important concept to iBGP learned routes is **//bgp synchronization.//** This is configured via the **//#synchronization//** BGP subcommand. Synchronization causes iBGP learned routes not to be considered "best" unless the exact prefix was learned via IGP and is installed in the routing table. The Ideally, to make sync work, the BGP routes would be redistributed into the IGP. This is seldom used today due to the large number of routes that would be injected.

Additional logic is required for OSPF, in that the RID of both BGP and OSPF on the advertising router must match for the route to be considered best with synchronization.

Confederations
Confederations further subdivide iBGP into sub-AS systems. Peers within the same sub-AS are considered confederation iBGP peers and those outside are considered confederation eBGP peers.

Basically, the confederation peers act like they would outside of the confederations in that the confederation iBGP peers will not advertised to each other with the eBGP peers will. Inside of a confederation, the iBGP peers should be fully meshed. The CONFED AS_PATH segments are used to prevent routing loops.

When configuring the ASNs used in confederation, it is best practice to use a subnet of private ASN numbers (64512 - 65535).

Some other points to consider about confederations:


 * The confederation eBGP peers act the same as normal eBGP including the use of a TTL of 1, requiring a multihop configuration in some situations.
 * Confederations are not considered part of the AS_PATH when selecting the best route
 * The confederations PA values are removed when the updates are advertised outside of a confederation

In configuration, its important to note that the routers TRUE ASN will no longer be configured using the router bgp command.

Route reflectors
Route reflectors provide the same results as confederations, in that it allows a way to advertise iBGP routes to other iBGP peers. In a route reflector design, some routers are configured as servers and are allowed to receive and advertise iBGP routes to peers. The only configured is placed on the RR server and all other routers act like normal BGP peers.

The only case in which a RR will not reflect an iBGP route is if that route is learned from a non-client. A typical design consists of multiple RR clusters with each RR peer to each other. Routing loops are prevented with the following:


 * CLUSTER_LIST: The cluster ID is added to a CLUSTER_LIST PA. RRs discard updates in which their cluster ID is already listed.
 * ORIGINATOR_ID: Lists the RID of the first iBGP peer to advertise the route. If a router sees it own RID, it does not use or advertise the route.
 * RRs only reflect routes considered to be the "best"

Clients are configured with the command //**#neighbor route-reflector-client**// and clusters are configured with //**#bgp cluster-id <#>**//

=Route filtering and Summarization=

There are four main tools that can be used to filter BGP routes:


 * Distribution lists
 * Prefix Lists
 * AS_PATH filter lists (//**#neighbor filter-list**//)
 * Route maps

These tools all share the following attributes:


 * All can filter incoming or outgoing updates per neighbor or per peer group
 * Peer group configurations are processed only once, instead of once per neighbor
 * Filters cannot be applied to a single neighbor if that neighbor is in a peer group
 * Each tool examines the BGP update message
 * If a filter is changed, a **clear** command is required before the change take effect

The tools differ in what they can match in the BGP update message.

Filtering based on NLRI
Distribute lists can use an extended ACL to match the prefix length. This is not possible with an IGP.

Prefix-lists and route-maps act the same way in all routing protocols. Route maps often do not provide a better solution than the other tools. However, only routes maps can provide the following functionality:


 * Matching logic that combines either prefix/length, AS_PATH or other BGP PAs
 * The setting of BGP PAs to manipulate best path selection

suppress-maps
Suppress-maps are used with the aggregate-address command. The option references a route map, with any component subnets matching the permit clause being suppressed. The route is not removed fromt he BGP table, but only suppressed.

unsuppress-maps
The opposite of of suppress-maps, these allow specific routes through when summarizing.

Matching the AS_PATH
AS_PATH filters are normally to filter based on this PA. The filter is applied with the filter-list option in the neighbor command. It requires two steps:


 * 1) Configure the AS_PATH filter using: //**#ip as-path access-list {permit|deny} regex**//
 * 2) Apply the filter: #neighbor filter-list  {in|out}

Those paths matching a deny on the as-path ACL are filtered.

Soft Reconfiguration
Soft reconfiguration allows a BGP router to reapply its routing policie without bringing down the BGP peers. This is done via the command:

//**clear ip bgp {* | neighbor-address | peer-group-name } [soft [in | out]]**//

The soft option alone with reapply the policies in both directions. Soft reconfiguration is supported automatically for sent update, but must be configured for received updates with //**#neighbor  soft-reconfiguration inbound.**// This causes the router to keep a copy of the received updates fromt he specified neighbor.

Note that software configuration will not help for policies that affect the local injection of routes.

=BGP Path Attributes=

BGP PAs can be classified into a few different categories. The first, well known, means a BGP implementation must support the PA. If support is not required, the PA is classified as optional.

Well known PAs can be either of the following:


 * Mandatory - Must be in every BGP update
 * Discretionary - Not required in every update

Optional PAs are either:


 * Transitive - The router should silently forward the PA without needing to consider the meaning
 * Nontransitive - The router should remove the PA from the update before forwarding



Decision Process
The following lists how BGP decides a best route among multiple matching NLRIs


 * 1) Is the NEXT_HOP Reachable
 * 2) Highest Administrative weight
 * 3) Cisco proprietary setting on the local router. Not advertised via updates. can be changed via the //**#neighbor route-map**// in or //**#neighbor weight**// commands. Route map is preferred is both exist.
 * 4) Highest LOCAL_PREF
 * 5) Allows routers in an AS with multiple exist points to choose the best route for a NLRI. To configure, the router that is the desired exist points set the LOCAL_PREF and advertised to iBGP peers. Default is 100. Configured with the //**#neighbor route-map in**// command
 * 6) Is route locally injected?
 * 7) Shortest AS_PATH
 * 8) [[image:http://i.imgur.com/6G3bt.png]]
 * 9) Private ASNs can only be removed when sending an eBGP update, and will not be removed with the current AS_SEQ contains both public and private ASNs or if the ASN of the eBGP is already in the AS_PATH
 * 10) ORIGIN PA
 * 11) Can be set manually in a route map with set origin
 * 12) Smallest MED
 * 13) Allows routers in one AS to tell routers in another AS how good the advertised route is. The default is 0, can be changed with //**#bgp bestpath med missing-as-worst**//. The receiving AS does not advertise it out to any other AS'. Configured via set metric inside a route map.
 * 14) By default, a router will ignore the MED if the neighboring ASNs to a single NLRI do not match. This can be changed with //**#bgp always-compare-med.**//
 * 15) BGP can sometimes pick a best route based on the order of the routes in the BGP table. This behavior can be changed with //**#bgp deterministic-med**//
 * 16) Neighbor Type
 * 17) IGP metric for NEXT_HOP

This decision process does not rule out routes until a winner has been selected. If you have 5 routes, and two have the highest local pref, all 5 routes are still considered in step 4.

Two tiebreaker options also exist:


 * 1) Choose eBGP or iBGP route with lowest RID. eBGP routes are preferred
 * 2) If the existing best route is eBGP, the route will not be replaced if a new route comes into the table. This behavior can be changed with //**#bgp bestpath compare-routerid**//
 * 3) Smallest neighbor ID

Multiple routes
BGP logic for selecting multiple routes is as follows:


 * If a best route was selected in steps 1-9, the only a single route is added to the routing table
 * If a best route was selected via the tiebreakers, BGP considers adding multiple routes to the routing table

Note that even if multiple routes are added, BGP will still selected a best route, and only that route is advertised to peers.

Multiple paths can be configured with the //**#maximum-paths**// BGP command. This applies only to eBGP routes. For iBGP routes, use //**#maximum-paths ibgp**//

=BGP Communities=

A path attribute which allows routers to applies routing polices to all routes within the same community to configure:


 * 1) Sending router must use //**#neighbor send-community both**//
 * 2) Set community string with a route map. The additive keyword wont replace existing communities
 * 3) //**#set community none**// to clear
 * 4) **#set comm-list delete** to remove individual community
 * 5) Two formats: Old which is decimal, new with is AA:NN
 * 6) To use new: ip bgp-community new-format

Some reserved community values exist:



=**Command Reference**=



= =