CCIE BGP
Resources:
CCIE Professional Development Routing TCP-IP Volume II
CCIE Routing and Switching Exam Certification Guide 3rd Edition
When Tier one service providers agree to share routes and traffic they enter a peering
agreement. This agreements can be bilateral or multilateral.
Effective BGP peering must involve a certain amount of both trust and distrust.
BGP uses TCP port 179 for communications
Hello timer 60 seconds, hold 180 seconds (default)
BGP is a path vector routing protocol , it knows which AS are traversed to reach the
destination but still doesn’t have a SPF style topology tree.
IF a BGP router receives an update and it can see its own AS in the path it discards
the update.
Cisco routers have a separate table to hold BGP routes ( show ip BGP)
The bgp table contains all known routes and the preferred route is denominated with a
*
BGP is classless but by default summarises at the classfull boundary.
By default BGP only uses 1 path if there are equal cost paths ( this can up set to up to
6 for EBGP but can only be 1 for IBGP)
If a peer ( neighbour) router has a different AS number then that relationship is
EBGP.
If a peer router has the same AS number then it is IBGP.
BGP on connection establishment will do a full table exchange, from there only when
a route changes.
EBGP packets has a TTL set to 1 this means that only directly connected EBGP can
send BGP updates to each other. This breaks the usage of loopback interfaces as the
source. neighbor ebgp-multihop command can change this behavior.
Network statement, the network statement in BGP is different to an IGP, it just tells
BGP to advertise the NET as apposed to an IGP where the network statement
specifics interfaces that the routing protocol will run on.
BGP has 4 message types:
Open message: after tcp session is established it is used to specify BGP operational
parameters
Version number (default is 4)
The AS number of the router ( to determine E or I BGP)
Holdtimer, how offen a keepalive message must be received, 0 is no
holdtimer , minimum of 3 seconds default 180
BGP identifier : same as OSPF ( highest loopback address used)
Optional parameters : authentication etc
Keepalive message: by default set to 1/3 of the holdtimer ( 60 seconds)
Update message:
Network Layer Reachability Information (NLRI):
This is one or more (Length, Prefix) tuples that advertise IP address prefixes and their
lengths. If 206.193.160.0/19 were being advertised, for example, the Length portion
would specify the /19 and the Prefix portion would specify 206.193.160.
Path Attributes
The path attributes, are characteristics of the advertised NLRI. The attributes provide
the information that allows BGP to choose a shortest path, detect routing loops, and
determine routing policy.
Withdrawn Routes
These are (Length, Prefix) tuples describing destinations that have become
unreachable and are being withdrawn from service.
Notification message: The Notification message is sent whenever an error is
detected and always causes the BGP connection to close.
BGP state machine
IDLE state.
BGP isn’t active doesn’t do anything, a start event needs to be triggered ( router BGP
AS command or resetting BGP a process) it transition to the connected state.
Connections to its neighbours are attempted as well as receiving incoming connection
attempts.
Connected state: the router is wating for the tcp connection to be established. If it is
successfully established it sends an open message and transitions to the OPENsent
state. If the connect attempt fails the router will still listen for incoming connection
but will transition to the ACTIVE state.
ACTIVE state:
The router continues to try and establish a connection if it is successful it transistions
to the Opensent state. If it cant it will go back to the connected state. Any other imput
events at this time will cause the router to go back to the idle state.
Opensent state: in this state an open and been sent and the router is waiting to receive
an open message from its neighbour. When it receives the open message it is checked.
If there is an error a notification message is sent at the router transitions to the IDLE
state.
If there is no erros a keepalive packet is sent, the hold timer is negotiated ( the lowest
is accepted ) the peer either becomes internal or external and is transitioned to the
OPENConfirm state.
If a tcp disconnect message is received the router is transitioned to the active state.
Openconfirm state: is waiting for the return of a keep alive message. If one is
received then the router is transitioned to the established state. If it isn’t received the
router transitioned to the idle state.
Established state:
Peers can exchange updates, if a notification message is received the router is
transitioned to IDLE state.
To become a BGP neighbour
1.The router must receive a TCP connection request with a source address that the
router finds in a BGP neighbor command.
2. A router’s ASN (on the router bgp asn command) must match the neighboring
router’s reference to that ASN with its neighbor remote-as asn command. (This
requirement is not true of confederation configurations.)
3. The BGP RIDs of the two routers must not be the same.
4. If configured, MD5 authentication must pass.
Path attributes!!!
A path attribute is a charactistic of a route and they fall into 4 categories:
Well known mandatory
Well known discretionary
Optional transitive
Optional nontransitive
Well known must be recognised by all bgp routers, Optional is optional.
Mandatory means that they must be carried in a routing update.
Discretionary means that they are optional in a routing update.
Trasitive means they have to be carried even if the router cant interperate them
Nontransitive means they can be dropped the update if not understood. Nontrasitive
attributes can be added and removed at any stage during the route propagation
throughout AS’s.
Attribute Class
ORIGIN
Well-known mandatory
AS_PATH
Well-known mandatory
NEXT_HOP
Well-known mandatory
LOCAL_PREF
Well-known discretionary
ATOMIC_AGGREGATE Well-known discretionary
AGGREGATOR
Optional transitive
COMMUNITY
Optional transitive
MULTI_EXIT_DISC (MED) Optional nontransitive
ORIGINATOR_ID
Optional nontransitive
CLUSTER_LIST
Optional nontransitive
The ORIGIN attribute
this is where the route was learnt from,
IGP, the route was learnt from within an IGP (network statement) this is the most
preferred ORIGIN attribute
EGP- the route was learnt from EGP, is second in preference.
Incomplete – the least desired, BGP cant guarantee the source of the route,
redistributed routes are given the value of incomplete because there is no way to
determine the exact source of the route.
AS_PATH
There are four type of AS_PATH formatting, this as is only added to the path as it
leaves that AS to another as (EBGP Peer).
AS_SEQUENCE
A router will prepend(add to the front) the its AS number to a route update when it
advertises it to external neighbours. Each router along the way does this giving an
exact AS path that is taken by the route.
A router can make a path look more desirable by making another path look less
desirable by prepending its own AS number multiple times to artificially increase the
hop count. This is known as AS path prepending. A router will drop a update if it
see’s a loop in the AS path.
AS_SET
This is an unordered list of the AS numbers along a path to a destination. It is sent
along with the AS-sequence. When a route is summarized the AS-sequence is lost but
the AS_SET remains. When a router see’s an update that has its own AS number in
the AS_SET it discards the route as it could form a loop. AS_SET isn’t used for
shortest path calculations but only as a record of what AS’s this update has come
from.
When the as-set option has been configured, the router creates an AS_SET segment
for the aggregate route, but only if the summary route’s AS_SEQ is null.
See the confederations section for the other two.
AS NEXT-HOP
If the advertising router and receiving router are in different autonomous systems
(external peers), the NEXT_HOP is the IP address of the advertising router's
interface.
If the advertising router and the receiving router are in the same AS (internal peers),
and the NLRI of the update refers to a destination within the same AS, the
NEXT_HOP is the IP address of the neighbor that advertised the route.
If the advertising router and the receiving router are internal peers and the NLRI of
the update refers to a destination in a different AS, the NEXT_HOP is the IP address
of the external peer from which the route was learned.
The exact wording of the rule is: if the current BGP next hop is in the same IP subnet
as the receiving router the next hop address is not changed.
Local_preference
This is only used by IBGP neighbours, it is not passed to other AS’s. if there a
multipule paths to a destination(another AS) an IBGP peer will look at the local
preference to decided which route to use.
MULTI_EXIT_disc (MED)
This optional nontransitive attribute is carried in EBGP updates and allows an AS to
inform another AS of its preferred ingress points. If all else is equal, an AS receiving
multiple routes to the same destination compare the MEDs of the routes. Unlike
LOCAL_PREF, in which the largest value is preferred, the lowest MED value is
preferred. This is because MED is considered a metric, and with a metric the lowest
value—the lowest distance—is preferred.
MED isn’t advertises any further then the directly receiving AS. SO only routes
between two directly connected AS can be influenced.
MED is normally the metric from the IGP that the route was learnt from
Default MED is 0 ( which is best)
bgp bestpath med missing-as-worst command changes the above.
Enabling the bgp deterministic-med command ensures the comparison of the MED
variable when choosing routes advertised by different peers in the same autonomous
system. Enabling the bgp always-compare-med command ensures the comparison of
the MED for paths from neighbors in different autonomous systems
ATOMIC_AGGREGATE and AGGREGATOR
A BGP-speaking router can transmit overlapping routes to another BGP speaker. (
192.168.0.0/16 , 192.168.1.0 /24) routes always choose the most specific route. BGP
has several options it can take with overlapping routes:
Advertise both the more-specific and the less-specific route
Advertise only the more-specific route
Advertise only the nonoverlapping part of the route
Aggregate the two routes and advertise the aggregate
Advertise the less-specific route only
Advertise neither route
When routes are summarised in BGP the AS_PATH is lost the aggregator only
includes its own AS number in the AS PATH.
The ATOMIC_AGGREGATE must be set anytime when routing information is lost (
number 5 on the list above) and tells routers that there has been a loss of routing
information with this route and it cant do anything to the route to make it appear more
specific.
When the ATOMIC_AGGREGATE is set the router can also set the
AGGREGATOR attribute. This attribute has the AS number and the ip address ( for
cisco the router ID ) of the router that did the aggregation.
The COMMUNITY attribute
identifies a destination as a member of some community of destinations that share one
or more common properties. For example, an ISP might assign a particular
COMMUNITY attribute to all of its customers' routes. The ISP can then set its
LOCAL_PREF and MED attributes based on the COMMUNITY value rather than on
each individual route.
The COMMUNITY attribute is a set of four octets
first two octets are the autonomous system and the last two octets are an
administratively defined identifier giving a format of AA:NN. The default Cisco
format, on the other hand, is NN:AA. You can change this default to the RFC 1997
format with the command ip bgp-community new-format.
Suppose, for example, a route from AS 625 has a COMMUNITY identifier of 70.
The COMMUNITY attribute, in the AA:NN format, is 625:70 and is represented in
hex as a concatenation of the two numbers: 0x02710046, where 625 = 0x0271
and 70 = 0x0046. The RFCs use the hex representation, but COMMUNITY
attribute values are represented on Cisco routers in decimal. For example, 625:70
is 40960070 (the decimal equivalent of 0x2710046).
The community values from 0 (0x00000000) to 65535 (0x0000FFFF) and from
4294901760 (0xFFFF0000) to 4294967295 (0xFFFFFFFF) are reserved. Out of
this reserved range, several wellknown communities are defined:
l INTERNET—
The Internet community does not have a value; all routes belong
to this community by default. Received routes belonging to this community are
advertised freely.
l NO_EXPORT
(4294967041, or 0xFFFFFF01)— Routes received carrying this
value cannot be advertised to EBGP peers or, if a confederation is configured, the
routes cannot be advertised outside of the confederation.
l NO_ADVERTISE (4294967042, or 0xFFFFFF02)— Routes received carrying
this value cannot be advertised at all, to either EBGP or IBGP peers.
l LOCAL_AS (4294967043, or 0xFFFFFF03)— RFC 1997 calls this attribute
NO_EXPORT_SUBCONFED. Routes received carrying this value cannot be
advertised to EBGP peers, including peers in other autonomous systems within a
confederation.
The ORIGINATOR_ID
is a 32-bit value created by a route reflector. The value is the router ID of the
originator of the route in the local AS. If the originator sees its RID in the
ORIGINATOR_ID of a received route, it knows that a loop has occurred, and the
route is ignored.
CLUSTER_LIST
is a sequence of route reflection cluster IDs through which the route has passed. If a
route reflector sees its local cluster ID in the CLUSTER_LIST of a received route, it
knows that a loop has occurred, and the route is ignored.
Weight
Cisco only attribute, only on local router isn’t sent in any updates. It is a 16bit number
, higher the weight more perfured the route. BGP considers weight above all other
attributes. By default all learnt routes are given a value of 0 all locally generated
routes given a value of 32,768.
The BGP Decision Process
The BGP Routing Information Database (RIB) consists of three parts:
Adj-RIBs-In— Stores unprocessed routing information that has been learned from
updates received from peers. The routes contained in Adj-RIBs-In are considered
feasible routes.
Loc-RIB— Contains the routes that the BGP speaker has selected by applying its
local routing policies to the routes contained in Adj-RIBs-In.
Adj-RIBs-Out— Contains the routes that the BGP speaker advertises to its peers.
The BGP decision process selects routes by applying local routing policies to the
routes in the Adj-RIBs-In and by entering the selected or modified routes into the
Loc-RIB and Adj-RIBs-Out.
Phase 1 calculates the degree of preference for each feasible route. It is invoked
whenever a router receives a BGP Update from a peer in a neighboring AS containing
a new route, a changed route, or a withdrawn route. Each route is considered
separately, and a nonnegative integer is derived that indicates the degree of preference
for that route.
Phase 2 chooses the best route out of all the available routes to a particular
destination andinstalls the route in the Loc-RIB. It is invoked only after phase 1 has
been completed.
Phase 3 adds the appropriate routes to the Adj-RIBs-Out for advertisement to peers.
It is invoked after the Loc-RIB has changed, and only after phase 2 has been
completed. Route aggregation, if it is to be performed, happens during this phase.
if the address specified by the route's NEXT_HOP attribute is unreachable, the route
is not selected
1. Prefer the route with the highest administrative weight. This is a Cisco-specific
function, because BGP administrative weight is a Cisco parameter.
2. If the weights are equal, prefer the route with the highest LOCAL_PREF value.
3. If the LOCAL_PREF values are the same, prefer the route that was originated
locally on the router. That is, prefer a route that was learned from an IGP on the same
router.
4. If the LOCAL_PREF is the same, and no route was locally originated, prefer the
route with the shortest AS_PATH.
5. If the AS_PATH length is the same, prefer the path with the lowest origin code.
IGP is lower than EGP, which is lower than Incomplete.
6. If the origin codes are the same, prefer the route with the lowest
MULTI_EXIT_DISC value. This comparison is done only if the AS number is the
same for all the routes being considered.
7. If the MED is the same, prefer EBGP routes over confederation EBGP routes, and
prefer confederation EBGP routes over IBGP routes.
8. If the routes are still equal, prefer the route with the shortest path to the BGP
NEXT_HOP. This is the route with the lowest IGP metric to the next-hop router.
9. If the routes are still equal, they are from the same neighboring AS, and BGP
multipath is enabled with the maximum-paths command, install all the equal-cost
routes in the Loc-RIB.
10. If multipath is not enabled, prefer the route with the lowest BGP router ID.
Route Dampening
It is used to stop flapping routes to cause network instability caused by overloading of
updates. A dynamic number is used to determine if a route should be suppressed. The
more a route flaps the more likely it is to be surpressed.
The Cisco defaults for the various route-dampening variables are as follows:
Penalty— 1000 per flap (added every flap)
Suppress limit— 2000 ( stop advertising the route)
Reuse limit— 750(when a route is suppressed it must fall below this to be advertised
Half-life— 15 minutes ( the dynamic figure is ½ every half life timer)
Maximum suppress time— 60 minutes, or 4 times the half-life ( max time a route
can be suppressed)
IBGP
IBGP only exchanges directly connected routes. If IBGP was the only IGP running
this means there would need to be a full mesh of tcp sessions between every IBGP
router to exchange all routes with an AS. This pint is mute because BGP rule for
Synchronization states that the rule must first be learnt via an IGP before IBGP is
allowed to enter that route into the routing table.
If a bgp router forwards a packet Destined for an external and the internal (IGP
without IBGP) IGP router wouldn’t have enough routing information to route the
packet to the correct IBGP router and discard the packet. Synchronization prevents
packets from being black-holed within a transit AS by an IGP with insufficient
information.
IBGP Synchronization can be disabled if needed two. This need can arise when
routers running IBGP have enough routing information to route the packet the
destination EBGP peer but there is no IGP running on those routers.
For IBGP to work correctly one of two configuration options must be chosen:
The external routes must be redistributed into the IGP to ensure that the IGP can
synchronize with BGP. The drawback to this approach is that if you are taking a large
number of routes from BGP, such as a full Internet routing table, you are placing a
huge processing and memory burden on the IGP routers.
The IBGP routers must be fully meshed, and synchronization must be disabled. Every
router then has knowledge of the external routes via BGP, and disabling
synchronization allows the routes to be entered into the routing table without having
to first inform the IGP. The drawback to this approach is that in an AS where there are
more than a few IBGP routers, peering every router with every other router becomes
an administrative challenge. Nonetheless, this is the approach that is almost always
used when dealing with Internet routes.
If you turn off synchronization on a working BGP process, you must reset the BGP
connections with the clear ip bgp * command before the changes will take effect.
Managing Large-Scale BGP Peering
Peer Group:
Helps control routing policy between peers
Routers can be added to a peer group, when configuration for a routing policy needs
to be changed changing it on one router will change it on all routers within the peer
group. This simplifies administration work. Additional polices that need to be applied
on a per router bases ( not sent to other routers in the peer group) can also be
configured.
Communities
Helps control routing policy between peers
Communities a very similar to peer groups but they act on routes not routers. A router
sets the community attribute on the route update. Other routers within the AS then
know that this route is apart of a community and applies routing policy that is setup
for that community. A route can have more then one community value set.
Route Reflectors
Simply IBGP management
Route Reflectors can be used when an AS has a large amount of IBGP peers.
Route reflectors offer an alternative to fully meshed IBGP peers. A router is
configured as a route reflector (RR), and other IBGP routers, known as clients, peer
with the RR only, rather than with every other IBGP router As a result, the number of
peering sessions is reduced from n(n – 1)/2 to n – 1. A router reflector and its clients
are known collectively as a cluster.
Route reflectors work by relaxing the rule that IBGP peers cannot advertise routes
learned from other IBGP peers.The route reflector learns routes from each of its
clients. Unlike other IBGP routers, the RR can advertise these routes to its other
clients and to nonclient peers. In other words, the routes from one IBGP client are
reflected from the RR to the other clients. To avoid possible routing loops or other
routing errors, the route reflector cannot change the attributes of the routes it receives
from clients.
A client router in a route reflection cluster can peer with external neighbors, but the
only internal neighbor it can peer with is a route reflector in its cluster or other clients
in the cluster. However, the RR itself can peer with both internal and external
neighbors outside of the cluster and can reflect their routes to its clients.
If an RR receives multiple routes to the same destination, it uses the normal BGP
decision process to select the best path.
Rules used to determine which routers an RR will advertise to:
If the route was learned from a nonclient IBGP peer, it is reflected to clients only.
If the route was learned from a client, it is reflected to all nonclients and clients,
except for the originating client.
If the route was learned from an EBGP peer, it is reflected to all clients and
nonclients.
A RR Cluster can have more then 1 RR for redundancy purposes.
Because clients do not know they are clients, a route reflector can itself be a client of
another route reflector.
Each cluster within an AS must be identified with a unique 4-octet cluster ID. If the
cluster contains a single route reflector, the cluster ID is the router ID of the route
reflector. If the cluster contains multiple route reflectors, each RR must be manually
configured with a cluster ID.
Two attributes are used to control route reflection to stop routing loops.
The ORIGINATOR_ID is the router ID of the originator of a route within the local
AS. A route reflector does not advertise a route back to the originator of the route;
nonetheless, if the originator receives an update with its own RID, the update is
ignored.
CLUSTER_LIST
Is used the same way AS_PATH is used, each time a route hits a RR the
CLUSTER_ID is added, if a RR sees its own CLUSTER_ID in a update it ignores the
update.
Confederations
A confederation is an AS that has been subdivided into a group of subautonomous
systems, known as member autonomous systems. Each sub has a private AS
number and uses EBGP to talk to other subs Within the Confederation. The
confederation is assigned a Confederation ID which is the AS number that is sent to
EBGP outside the confederation.
Confederations add two more types of AS_PATH, both of these are only used locally
within the confederation and are stripped at the confederation boundary.
AS_CONFED_SEQUENCE
A order list of sub AS’s that are passed within the confederation.
AS_CONFED_SET
A list of all sub AS’s works the same way as AS_SET so sub AS info is kept in the
event of summarization
When an update is sent to a peer external to the confederation, the
AS_CONFED_SEQUENCE and AS_CONFED_SET information is stripped from the
AS_PATH attribute, and the confederation ID is prepended to the AS_PATH.
Because of this, external peers see the confederation as a single AS rather than as a
collection of autonomous systems.
When choosing a route, the BGP decision process remains the same, with one
addition: EBGP routes external to the confederation are preferred over EBGP routes
to member autonomous systems, which are preferred over IBGP routes. Another
difference between confederations and standard autonomous systems is the way in
which some attributes are handled. Attributes such as NEXT_HOP and MED can
be advertised unchanged to EBGP peers in another member AS within the
confederation, and the LOCAL_PREF attribute also can be sent.
Regular expressions
Character
Special Meaning
period
.
Matches any single character, including white space.
asterisk
* Matches 0 or more sequences of the pattern.
plus sign
+ Matches 1 or more sequences of the pattern.
question
mark
? Matches 0 or 1 occurrences of the pattern.
caret
^ Matches the beginning of the input string.
dollar sign
$ Matches the end of the input string.
underscore
Matches a comma (,), left brace ({), right brace (}), left parenthesis, right
_ parenthesis, the beginning of the input string, the end of the input string, or a
space.
brackets
[] Designates a range of single-character patterns.
hyphen
- Separates the end points of a range.
Matches any of the following a b c d A BC D
[a-dA-D]
Match just AS 4 ( no other AS in as sequence)
^4$
Match any route that has passed AS 4
_4_
Match any routes that are learnt from AS4 and all AS’s behind it
^4_[0-9]*$
Drop all AS’s
^$
Outbound route filtering
Uses prefix lists, configure on local router and gets sent to neighbour to control how
you want routes filted to the local router. Remember implicate deny at the end.
Batch updates
BGP will batch updates together per batch interval, this helps protect BGP from fast
flapping interface.
IBGP batch update every 5 seconds
EBGP batch update every 30 seconds
Singled homed customer reasons:
Need/want own internet routable address space.
for EBGP the neighbour address must be reachable by a route other then 0.0.0.0/0
show ip bgp summary:
inQ and outQ: are updates yet to be sent or processed
Tblver: every change to the BGP table on a router causes this value to be incremented
by 1
BGP scan time:
is used for 2 things, 1 to test reachabiltiy to BGP net hops the other is to bring routes
into a BGP VPN. By default it is 60 seconds for BGP reachability and 15 seconds for
VPN. Decreasing these numbers decreases convergence time.
iBGP multipath
For multiple paths to the same destination to be considered as multipaths, the
following criteria must be met:
• All attributes must be the same. The attributes include weight, local preference,
autonomous system path (entire attribute and not just length), origin code, Multi Exit
Discriminator (MED), and Interior Gateway Protocol (IGP) distance.
•
The next hop router for each multipath must be different.
Even if the criteria are met and multiple paths are considered multipaths, the BGP
speaking router will still designate one of the multipaths as the best path and advertise
this best path to its neighbors.
BGP Link Bandwidth
The Border Gateway Protocol (BGP) Link Bandwidth feature is used to advertise the
bandwidth of an autonomous system exit link as an extended community
It is used for unequal cost load balancing.
• BGP load balancing or multipath load balancing must be configured before this
feature is enabled.
• BGP extended community exchange must be enabled between iBGP neighbors to
which the link bandwidth attribute is to be advertised.
• Cisco Express Forwarding (CEF) or distributed CEF (dCEF) must be enabled on
all participating routers.
1. enable
2. configure {terminal | memory | network}
3. router bgp as-number
4. address-family ipv4 [mdt | multicast | tunnel | unicast [vrf vrf-name] | vrf vrfname] | ipv6 [multicast | unicast] | vpnv4 [unicast]
5. bgp dmzlink-bw
6. neighbor ip-address dmzlink-bw
7. neighbor ip-address send-community [both | extended | standard]
IP stuff
#ip tcp path-mtu-discovery
Is used to stop fragment packets for bgp updates
Router(config)#ip tcp path-mtu-discovery age-timer ?
<10-30> Aging time
infinite Disable pathmtu aging timer
age time is how long before a re-estimation of the MTU is taken.