CCIE Review – BGP

CCIE Review – BGP

Border Gateway Protocol

BGP is an EGP for routing between autonomous systems. It is described in RFC 4271 in great detail.

The primary function of a BGP speaking system is to exchange network
   reachability information with other BGP systems.  This network
   reachability information includes information on the list of
   Autonomous Systems (ASes) that reachability information traverses.

BGP is a path vector protocol. Among its noteworthy features:

Reliable updates

Triggered updates

Path attributes

Large networks; Internet centric

BGP can often be found in:

Customer networks connected to one or more ISP’s

Service Provider (transit networks)

Large Enterprise network cores

TCP Port 179

BGP is manually configured at both ends of a connection. TCP Port 179 is the session establishment facilitator. Its Finite State Machine indicators are Idle, Connect, Active, OpenSent, OpenConfirm and Established. It defaults to 60 second Keepalive’s for connection maintenance, and can use an MD5 shared secret between peers for security.

Best Path

In processing its routes, BGP has as its primary goal selecting the best path from among the choices made available from its peer establishments. All routes received from peers are retained in memory, however.

Best Path/Route Preference

Exclude route with an unreachable next hop

Weight (highest value, Cisco proprietary)

Local-preference (highest value within AS)

Locally originated (next hop, default weight value 32768 if applicable)

AS-Path (shortest)

Origin code (igp,egp,incomplete(?))

MED (mulri-exit discriminator, lowest value)

EBGP paths before IBGP

IBGP, closest IGP neighbor

EBGP oldest paths (age)

BGP router-id (lowest)

The best valid and reachable routes are propagated to BGP neighbors as well as placed into the IP route table after checking administrative distances

see also:

Local Route Injection

Network configuration commands

Redistribution by another routing protocol

Route Summarization

If auto summary is enabled, BGP summarizes routes to classful boundaries. Auto-summary, since IOS release 12.2(8T) is no longer the default behavior, hence locally introduced BGP routes are not summarized.

IBGP versus EBGP

BGP peers that share the same AS number are IBGP peers. Conversely, BGP peers that do not share the same AS number are EBGP peers.

However, other differences exist:

Packets sent to EBGP peers have a default ttl of 1

The next hop field is updated with the last EBGP peer, but is not when the peering is IBGP

eBGP neighbors do not advertise routes to eBGP neighbors in an AS that is contained with in the AS_PATH. (FIX THIS)

IBGP routes have an AD of 200 whereas EBGP routes have an AD of 20

and perhaps the greatest difference:

IBGP routes are subject to the rule of synchronization if enabled

For an IBGP route to make it into the BGP routing table that exact prefix must first exist in the IGP route table.

Another way of stating it:

Routes learned by BGP must be present in the IGP route table before they can be advertised to remote peers.

The rule of synchronization guarantees that a route is known within an AS regardless if BGP is even running. A route advertised by IBGP not conforming to the rule of synchronization could potentially be black holed by a non-speaking neighbor. Synchronization speaks to the implied requirement of a full mesh topology. The expense of full mesh IBGP to counter such black holes can be avoided with tools such as route reflection and confederations.

Synchronization as a default has been disabled since IOS 12.2(8T), however that in itself does not solve the issue.


The BGP process is begun in global configuration mode with the command:

R3(config)#router bgp 65001


Public and private numbers are available based on circumstances. The established private range is 64512-65535 according to rfc 1930:

The Internet Assigned Numbers Authority (IANA) has reserved the
   following block of AS numbers for private use (not to be advertised
   on the global Internet):

                           64512 through 65535

This rfc also establishes criteria for obtaining AS numbers

A single instance BGP process is allowed per router:

R3(config)#router bgp 65001

R3(config-router)#router bgp 65002

BGP is already running; AS is 65001

As discussed earlier, IBGP and EBGP are easily determined by the neighbors BGP relates to. Note that in either case the neighbor syntax is remote-as.

R3(config-router)#router bgp 65001

R3(config-router)#neighbor remote-as 65001

R3(config-router)#neighbor description same_as

R3(config-router)#neighbor remote-as 65002

R3(config-router)#neighbor description external_as

A neighbor can be shutdown from within the BGP process::

R3(config-router)#router bgp 65001

R3(config-router)#neighbor shutdown

MD5 is the only authentication type BGP uses, simply:

R3(config-router)#neighbor password cisco


Auto-summary can be enabled with the auto-summary command in the BGP process and at minimum one subnet for that major network must exist in the forwarding table in order to be advertised. With the default no auto-summary a mask is required to denote networks that exist outside their classful boundaries. (Since no auto-summary is the default, there is no reference to it in the output of show running-config)

R3(config)#router bgp 65001

R3(config-router)#netw mask

Route maps may also be used with network statements to ascribe attributes to prefixes upon insertion to the BGP table.

R3(config-router)#netw mask

R3(config-router)#netw mask route-map THIS_MAP

This can be useful for:

Setting local preference

Setting the weight of a local route

Manipulating BGP communities

Manipulating MED (metric)

and also


Redistributed routes have an origin code of ? or incomplete. It is likely to only see origin codes of i and ?, as source internal or source other than internal (redistributed), because e (EGP) is no longer supported.

R1#sh ip bgp | inc Origin

Origin codes: i – IGP, e – EGP, ? – incomplete

It is important to note that BGP treats incomplete routes as inferior in it’s selection process. Adjustments can be made using distribute lists, prefix-lists and route maps to compensate for this behavior.

A further note on classless networks:

As stated above be sure to announce networks operating outside their default class with the mask command. Another method to announce a network outside of class is to utilize a static route pointing to null0. This ensures creating a matching entry in the IP forwarding table.


Route summarization may be used to suppress individual routes in favor of an aggregate advertisement.

There must be a member network in the BGP table of the summarized space.

R1(config-router)#aggregate-address ?

advertise-map Set condition to advertise attribute

as-confed-set Generate AS confed set path information

as-set Generate AS set path information

attribute-map Set attributes of aggregate

route-map Set parameters of aggregate

summary-only Filter more specific routes from updates

suppress-map Conditionally filter more specific routes from updates


Regular Expression Path Filtering/Matching

Regular Expressions may be used to match/extract patterns ala Unix GREP (Global Regular Expression Parser). These can be used as simple searches to return a matched value to the terminal, or as parameters within policy control for AS Path filtering.

An expression or string of characters can be matched by a substring, as in:

11 will match | 11 1011 11001 10101 | the first three left to right but not 10101

Enclose ranges in brackets

The pipe symbol | is an ‘or” operator

Use . to match on a single character

^ matches the beginning of the string

$ matches the end of the string

_ matches any

() can group smaller expressions into larger

\ removes special character meaning

* repeats zero or more times

? repeats zero or one times

+ repeats one or more times


_400_ All routes through AS 400

^400$ Directly connected to AS 400

^400_. Networks behind AS 400

^ [0-9]+$ AS paths with only one AS

^$ Locally originated

.* Everything matches

Inbound AS path filters will select routes that are allowed.

Routes meeting selection criteria are matched inbound/ingress or outbound/egress from the perspective of the filtering router. On ingress, routes not matching the criteria are dropped. On egress, routes not matching the criteria are not forwarded to the egress neighbor but are still used locally.

Use an access list to set matching criteria:

ip as-path access-list (number) permit/deny (regular-expression)

ip as-path access-list 1 deny ^100$

Use filter-list to match the access-list to the neighbor in/out

neighbor filter-list 1 in

Show commands

show ip bgp regexp

show ip as-path-access-list

show ip bgp filter-list

Prefix Lists

Prefix lists are used to filter updates from other BGP speakers. Prefix lists offer flexibility by allowing matches delineated with the operators greater than/ge and less than/le. Without these operators an exact match results. A range up to /32 is assumed if only ge is used. A range of le to the le-value is assumed if only le is used. A range between upper and lower values can be determined if both are used together.

Router configuration syntax:

neighbor (address | peer-group) prefix-list (prefix-listname) in/out

This can be useful to suppress routes or in path manipulation.

To suppress network updates within advertisements use:

ditribute-list (acl number | name) prefix-list (prefix-list-name) out (interface | process | AS number)

Show command:

show ip prefix-list

Outbound Route Filtering

ORF is a prefix type BGP feature enabled as a capability code (code 3) between BGP speakers. The crux of the ORF capability is to filter updates before they are sent, thus reducing overhead. When enabled, the BGP speaker can install an inbound prefix list filter to its peer as an outbound filter.

ORF messages contain:

AFI/SAFI Address Family Identifier (AFI: IPV4,IPV6) and Subsequent Address Family Identifier (Unicast, Multicast, Encapsulation, et al) for use with the filter.

When to refresh (immediate/deferred)

List of ORF entries where the filter is defined


ORF Types:

ORF type 1 filter based on Network Layer Reachability Information (NLRI)

ORF type 2 filters based on standard BGP community attributes

ORF type 3 filters based on extended BGP community attributes

ORF type 128 filters based on Cisco-Proprietary implementation of prefix filtering (prefix lists)


ORF type 1 actions

ADD: adds a line to a prefix list on the remote peer

DELETE: removes a line from a previously installed filter on a remote peer

DELETE ALL: removes all previously installed filters on a remote peer

To advertise ORF capabilities to a peer in either address family or router configuration mode use:


neighbor (address) capability orf (prefix-list) [send | receive | both]

Use clear ip bgp neighbor prefix-filter to refresh


Route Maps

Filter on prefixes from an AS

Filter BGP attributes

Modify BGP attributes

Match clauses:

IP networks and masks, prefix-lists and access-lists

Route originator

Next hop

Origin code

Tag value of an IGP route

AS path


IGP route type

Set parameters


Next hop



Local preference


Route maps can be applied on inbound or outbound routing information for a neighbor. If a route map

does not explicitly permit a route, that route will be implicitly denied.


neighbor (address) route-map (name) in | out

show ip bgp route-map


Cisco IOS 11.2 introduced soft reconfiguration to alleviate the impact of clear ip bgp *. When soft-reconfiguration inbound is set for a neighbor, the router stores those neighbor received routes as a supplemental copy in memory prior to filtering. After route-map and filtering changes have been completed, use clear ip bgp (address) soft in privileged exec mode.


Likewise, after route-map and filtering changes have been applied outbound, use clear ip bgp (address) soft out in privileged exec mode.


Route refresh as a capability was introduced with rfc 2918 . The route refresh capability allows the local router to request a copy of the Adj-RIB- out from its peer.


Participation in this operation is advertised during session establishment. With Cisco equipment (and some others) this is the deafult. Verification of this capabilty (code 2) can be achieved with:

R1#show ip bgp neighbor | begin capabil

Neighbor capabilities:

Route refresh: advertised and received(new)

Four-octets ASN Capability: advertised and received

Address family IPv4 Unicast: advertised and received

Enhanced Refresh Capability: advertised and received

Multisession Capability:

Stateful switchover support enabled: NO for session 1



Well Known Mandatory

Must appear in updates; must be supported by the BGP software implementation.

Origin: Route origination


EGP (deprecated)

? (incomplete; redistributed)

AS-Path: the AS numbers comprising the path of the route

Next-Hop: address of the next hop router


Well Known Discretionary

May or may not appear in updates; must be supported by the BGP software implementation.

Local Preference: exchanged by routers within the same AS (iBGP) to prefer an exit to another AS (eBGP)

Atomic Aggregate: Tags a route as an NLRI summary


Optional Transitive

Aggregator: Address and AS of the aggregating router

Community: Tagging, used to carry information either within or between AS’s


Optional Non Transitive

Multi Exit Discriminator: (Metric) An indicator for multiple entry points into an AS, between AS’s

Originator ID: RR Carries the BGP Identifier of the originator of the route in the local AS

Cluster List: RR Lists the Cluster ID’s for loop prevention


Influencing Route Selection


A Cisco proprietary attribute that can be used to influence local routing policy, meaning, for that router

neighbor (address | peer-group) weight (weight)


Higher weights are preferred. The default weight is 32,768 for locally originated networks ( and 0 for all other networks


Filter lists and route maps may also be used for weight manipulation, ie:


neighbor (address | peer-group) filter-list (acl number) in | out | weight (weight)

R3(config)#route-map WEIGHT permit 10

R3(config-route-map)#set ?

as-path Prepend string for a BGP AS-path attribute

automatic-tag Automatically compute TAG value

clns OSI summary address

comm-list set BGP community list (for deletion)

community BGP community attribute

dampening Set BGP route flap dampening parameters

default Set default information

extcomm-list Set BGP/VPN extended community list (for deletion)

extcommunity BGP extended community attribute

global Set to global routing table

interface Output interface

ip IP specific information

ipv6 IPv6 specific information

level Where to import route

local-preference BGP local preference path attribute

metric Metric value for destination routing protocol

metric-type Type of metric for destination routing protocol

mpls-label Set MPLS label for prefix

origin BGP origin code

tag Tag value for destination routing protocol

traffic-index BGP traffic classification number for accounting

vrf Define VRF name

weight BGP weight for routing table


Local Preference

Can be used to influence routing policy within the AS. This attribute is not sent in updates to eBGP neighbors. Use weight or local preference not both. For iBGP and local routes the default is 100; for all others the default is 0.


Local preference is used:

In route maps with set local-preference

In router configuration mode with bgp default local-preference. This new default value is applied to

all locally originated and neighbor incoming updates


AS Path Prepending

A path selection mechanism used to influence return traffic to an AS from multiple providers. Padding a current best path with one or more instances of the sending AS effects a longer path, making it less likely used for return traffic. AS path prepending affects outgoing updates in eBGP. Only the sending AS is used for prepending to avoid loop prevention conflicts.


The set as-path prepend command is used in route maps


Multi Exit Discriminator (MED/METRIC)

MED influences routing between eBGP neighbors by attempting to establish a preferred path into an AS that has multiple entry points. The default is 0 and a lower value is preferred. MED is low on the preference scale which means it has no impact if a more preferred attribute is set.


Highest weight (cisco proprietary)

Highest local preference (LOCAL_PREF)

Prefer locally originated route (

Shortest AS_PATH

Lowest origin code (i before e before ?)

Lowest multi exit discriminator (MED)

eBGP before iBGP

If no external route, select the path with the lowest IGP cost to the next hop router (iBGP)

Choose most recent route (age)

Choose lowest BGP RID


As stated above, MED is optional non transitive. However, if the router is originating networks with the network command or redistribution, the metric from the routing table is used as the MED attribute value.


Using the default-metric command in router configuration mode causes redistributed routes to use that MED value. MED can be set in route maps for inbound and outbound updates with set metric. For confederations use bgp bestpath med confed to influence route selection. Routes originated in the confederation will have their MED values compared.

BGP Communities

A community is a group of destinations which share some common property. As mentioned earlier, the community attribute is optional transitive. When set, the community atrtribute allows for routing based on groupings of destinations with route maps. Routers can use this tag (community) to perform actions.

A router can tag incoming and outgoing updates, as well as redistributed routes. Communities are stripped in outgoing updates by default.

The type code for the community attribute is 8, and is expressed as a 32 bit number. The default community is internet (0).

BGP standards define several well known communities:

Local-AS used in confederations to prevent sending packets outside the local AS

no-export stays within the AS; not advertised to eBGP peers

no-advertise not advertised to any peer, iBGP or eBGP

internet advertise as normal; default

As optional transitive, routers not supporting communitties pass them unaltered

The 32 bit community value has 2 parts; high order and low order

(AS-number:low-order 16 bits) often represented as (AA:NN)

High order 16 bits is the AS that defines the community

Low order 16 bits are locally significant

The use of communities requires planning.

First: define administrative policy goals

Second: engineer filtering and path policies to meet these goals

Third: define communities

Configuration steps:

1) tag bgp communities

2) propagate the tagged communities

3) match acl’s to those communities (community-lists)

4) configure route maps to match on the community lists with BGP attributes

5) apply the oute maps either inbound or outbound

Tagging is accomplished through route maps. Unless the additive option is specified, the set keyword will overwrite the existing tag

The route map is applied for inbound or outbound updates thus:

neighbor (ip address) route-map (map name) in | out

To apply a route map for redistribution use:

redistribute (protocol) route-map (map name)

Community tags are stripped in outbound updates by default. Use send-community to propagate the tags:

neighbor (ip address) send-community

BGP peer groups may be used to consolidate community propagation towards neighbors.

Both standard and expanded community access lists can be used to identify community attributes in routing updates. The standard range is 1-99, the expanded range is 100-199 and names may also be used

They are evaluated sequentially

Without a match, the route is implicitly denied


The keyword internet replaces any, to match any at the end of the list


r1(config)#ip community-list ?

<1-99> Community list number (standard)

<100-500> Community list number (expanded)

expanded Add an expanded community-list entry

standard Add a standard community-list entry

r1(config)#ip community-list expanded ?

WORD Community list name

r1(config)#ip community-list expanded LIST ?

deny Specify community to reject

permit Specify community to accept

r1(config)#ip community-list expanded LIST permit ?

LINE An ordered list as a regular-expression

r1(config)#ip community-list expanded LIST permit _200_

Note the use of regexp in the expanded format.

Communities are converted to an ordered string and matched with regexp. *. may be used to match any community value.

A community list referenced in a route map will match routes that include at least some of the communities. The exact keyword may be used to ensure all communities contained in the route are included in the match.

Route Reflectors

BGP peers in the same AS must all form a distinct iBGP session with one another. For obvious reasons this can be troublesome. The concept of route reflectors was developed to overcome this requirement. Route reflectors are fully functional iBGP speakers that maintain a logical full mesh in an AS that is not a physical full mesh. Route reflectors forward routes from other iBGP speakers to their respective clients, thus forming a cluster.

Configuring route reflectors:

Apply a cluster-id to the reflectors

Configure the route reflector with iBGP sessions that are destined for their clients

For the clients, only configure BGP sessions with their reflectors

Remove the iBGP neighbor on both sides of the session

Configure the cluster-id:

bgp cluster-id (id)

Configure the client:

neighbor (address) route-reflector-client


Confederations are another method to solve the full mesh requirement. Subautonomous systems are used within the primary AS to consolidate the amount of connections actually required. Interestingly, the confederation id is the AS that encompasses the group, whereas the BGP processes are illustrated in the smaller ellipses within as below:


router bgp 2

bgp confederation identifier 1

bgp confederation peers 3

network mask

neighbor remote-as 2

neighbor remote-as 3

neighbor remote-as 65001

The confederation peers is not the number of peers, but the peering AS.

For example R1 AS 2 peers with R3 AS 3 within confederation AS 1. Further, AS 65001 peers with the confederation AS 1 for routers 1 and 2 as normal through eBGP.

Peer Groups

Peer groups may be assigned to limit the amount of configuration required for multiply connected neighbors with the same qualities. Peer groups will also cut down on processing overhead. The policies assigned to the group are inherited by the members.

In this simple peer grouping note the authentication is set for the peer group PEERS which includes the neighbors

65001#sh run | b router

router bgp 65001

neighbor PEERS peer-group

neighbor PEERS password cisco

neighbor remote-as 1

neighbor peer-group PEERS

neighbor remote-as 1

neighbor peer-group PEERS

Network Backdoor

eBGP has a default administrative distance of 20 which makes it the preferred route over an IGP route. Using the network backdoor router configuration command, a route sourced from an external neighbor will instead be forced to the administrative distance of 200.

Neighbor Maximum-prefix

Use the neighbor maximum-prefix command in router configuration mode to set the maximum prefixes a router may learn from a neighbor.

Route Dampening

Used for suppressing unstable routes, route dampening is a technique to remove updates about a flapping route until the destination becomes stable.

Use the bgp dampening router configuration mode command to achieve this.

Other important commands:

show ip bgp neighbors (address) Displays detailed neighbor information

show ip bgp Displays the routes in the BGP table

show tcp brief Displays the veracity of tcp connections

debug ip tcp transactions Displays all tcp transactions

debug ip bgp events Displays significant BGP events

debug ip bgp keepalives Displays BGP keepalive packets

debug ip bgp updates Displays incoming or outgoing BGP updates

debug ip bgp updates acl Displays incoming and outgoing updates that match on an acl