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 about the list of
Autonomous Systems (ASes) that reachability information traverses.
BGP is a path vector protocol. Among its noteworthy features:
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.
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 0.0.0.0, default weight value 32768 if applicable)
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
Local Route Injection
Network configuration commands
Redistribution by another routing protocol
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 126.96.36.199 remote-as 65001
R3(config-router)#neighbor 188.8.131.52 description same_as
R3(config-router)#neighbor 184.108.40.206 remote-as 65002
R3(config-router)#neighbor 220.127.116.11 description external_as
A neighbor can be shutdown from within the BGP process::
R3(config-router)#router bgp 65001
R3(config-router)#neighbor 18.104.22.168 shutdown
MD5 is the only authentication type BGP uses, simply:
R3(config-router)#neighbor 22.214.171.124 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 10.10.10.0 mask 255.255.255.0
Route maps may also be used with network statements to ascribe attributes to prefixes upon insertion to the BGP table.
R3(config-router)#netw 10.10.10.0 mask 255.255.255.0
R3(config-router)#netw 10.10.10.0 mask 255.255.255.0 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)
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 126.96.36.199 255.255.0.0 ?
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
ROUTE SELECTION/POLICY CONTROL
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 188.8.131.52 filter-list 1 in
show ip bgp regexp
show ip as-path-access-list
show ip bgp filter-list
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 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 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
Filter on prefixes from an AS
Filter BGP attributes
Modify BGP attributes
IP networks and masks, prefix-lists and access-lists
Tag value of an IGP route
IGP route type
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 http://tools.ietf.org/rfc/rfc2918.txt . 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 184.108.40.206 | begin capabil
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
Stateful switchover support enabled: NO for session 1
BGP PATH ATTRIBUTES
Well Known Mandatory
Must appear in updates; must be supported by the BGP software implementation.
Origin: Route origination
? (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
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 http://tools.ietf.org/html/rfc4456 Carries the BGP Identifier of the originator of the route in the local AS
Cluster List: RR http://tools.ietf.org/html/rfc4456 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 (0.0.0.0) 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
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
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 (0.0.0.0)
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.
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
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.
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 220.127.116.11 mask 255.255.255.0
neighbor 192.168.12.2 remote-as 2
neighbor 192.168.13.3 remote-as 3
neighbor 18.104.22.168 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 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 22.214.171.124 remote-as 1
neighbor 126.96.36.199 peer-group PEERS
neighbor 188.8.131.52 remote-as 1
neighbor 184.108.40.206 peer-group PEERS
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.
Use the neighbor maximum-prefix command in router configuration mode to set the maximum prefixes a router may learn from a neighbor.
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