1

BGP
(Border Gateway Protocol)

A
hm
ed
N
abi
l
July 2007
 2 Overview
• BGPv4 is an Exterior Gateway Protocol (EGP) that can exchange routing updates
between different Autonomous Systems, so it operate mainly at the border of an AS.
• BGP is not designed to choose paths based on bandwidth, delay and other metrics,
but paths are chosen based on policy attributes.
• AS is a collection of networks under a single technical administration, AS is
identified by a unique number between 1 – 65535.The range 64512 - 65535 is
reserved for private use.

IGPs work within AS

A
hm
ed
N
abi
l
3
When BGP is not appropriate?
1-Single connection to Internet or other AS
‫ﻧﻘص‬

2-Lack of memory and processing power to handle updates

3-Low bandwidth between ASs
4-Limited understanding of route filtering & BGP path selection process

When BGP is most appropriate?

1-An AS allows packets to transit through it to reach other AS (e.g.
Service Provider)
2-An AS has multiple connections to other AS
3-Routing policy & route selection for traffic entering or leaving
the AS must be manipulated
A
hm
ed
N
abi
l
 4
BGP C/Cs
• BGP is a path vector protocol (advanced distance vector).
(IGPs announce networks and describe the cost to reach those
networks, BGP announces pathways and the networks that are
reachable at the end of the pathway. BGP describes the pathway by
using attributes which are similar to metrics)

A
hm
ed
N
abi
l
 5 BGP C/Cs
• Reliable updates: BGP run on top of TCP port 179.
• Full BGP tables is exchanged at start-up.
• Incremental batched updates every 30 sec at change.
• BGP has no method for dynamic neighbor discovery, all neighbors
must be discover manually using the neighbor command.
• Updates is sent on unicast address to the statically configured
neighbors.
• Periodic keepalive messages to verify TCP connectivity.
• Use rich metrics called path attributes.
• Designed to scale huge internetworks.
• Support VLSM & CIDR (classless)
• Loop free (use BGP split-horizon & AS path list to avoid loops inside
AS and between ASs)
• Its symbol in routing table is B.
A
• External BGP has admin. distance 20. hm
ed
• Internal BGP has admin. distance 200. N
• BGP allows administrators to define policies or rules abi
l
for how data will flow through the Autonomous Systems.
6 BGP Tables
1-Neighbor table:
List of BGP neighbors "BGP peers" (configured statically with the
neighbor command & can be reachable)

2-BGP forwarding database table:

- List of all networks learned from each neighbor,
- Contain multiple paths to destination networks with attributes for
each path
- Best paths in that table is advertised to neighbors in routing updates

3-IP routing table

List of best paths to destination networks
A
hm
ed
N
abi
l
7
BGP messages

1-Open message
It is used to open BGP session with a neighbor (Includes holdtime
and BGP router ID

2-Keepalive message
Periodic message that is sent to keep TCP session stay still

3-Update message
It contain information about destination networks and the attributes
to reach these networks

4-Notification message
Sent to identify that an error condition is detected for a certain router A
(i.e. memory or CPU error) hm
ed
N
abi
l
 8
BGP neighbor states ‫ﻣﺻطﻠﺢ‬

• A BGP peer, also known as a BGP neighbor, is a specific term that is

used for BGP speakers that have established a neighbor relationship.
• Any two routers that have formed a TCP connection to exchange BGP
routing information are called peers or neighbors.

A
hm
ed
N
BGP Starts its operation when neighbors are statically defined, using abi
the neighbor command l
 9
External BGP
• When BGP neighbors
belong to different
autonomous systems
they are called EBGP.
• EBGP neighbors, by
default, need to be
directly connected.

Internal BGP
•IGBP refers to the presence
of BGP neighbors within the
same AS.
A
• The neighbors do not have hm
ed
to be directly connected, N
because they can be reached abi
l
through an IGP.
10 Configuring BGP neighbors

This mean C is configuring A as eBGP

A
This mean A is configuring B as iBGP hm
and C as eBGP ed
N
This mean B is configuring A as iBGP abi
l
11 BGP Start up Operation
after neighbor command is written
(config)#router bgp <as#>
(config-router)#neighbor <neighbor ip> remote-as < neighbor as# >
Idle state:
router is searching IP routing table to see if a route exists to reach the neighbor
Connect state:
router found route and has completed TCP 3-way handshake
Open sent:
open message is sent
Active state:
waiting confirmation on parameters to establish session
Open confirm:
receive agreement on parameters to establish session
A
Established state: hm
ed
peering is formed and routing exchange begins N
abi
l
12
BGP Start up Operation

RouterA# debug ip bgp events

BGP events debugging is on
BGP : 172.16.1.2 passive open
BGP : 172.16.1.2 went from idle to connect
BGP : 172.16.1.2 open rcvd, version 4
BGP : 172.16.1.2 went from connect to open sent
BGP : 172.16.1.2 sending open, version 4
BGP : 172.16.1.2 went from open sent to open confirm
BGP : Scanning routing tables
BGP : 172.16.1.2 went from open confirm to established

Why a router could stuck in active state?

•Neighbor peering with the wrong address
•Neighbor does not have neighbor statement for this router
•Neighbor does not have a route to the source IP address of the
A
BGP open packet generated by this router hm
ed
N
abi
l
 13 Understanding BGP Requirements
1-BGP runs on borders of AS but no IGP

Update
About
11.0.0.0 11.0.0.0

B has E in its neighbor table (using neighbor command), but for B to send update
about 11.0.0.0 to E the update is encapsulated in a packet with destination IP of E, but
there is no IGP running in the AS 65102, so B cant find a path for E in its routing A
table, so B will drop any updates going to E hm
ed
• Conclude: N
abi
IGP must run inside the AS, so as the BGP neighbors could be reachable l
 14 2-BGP run on borders and IGP inside AS
4-Routing Table
No BGP

8-data with dst ip 11.0.0.1

3-Update 11.0.0.0

1-Update 6-Update 11.0.0.0

11.0.0.0 About 2-Routing Table 5-Routing Table 7-Routing Table
11.0.0.0 B 11.0.0.0 B 11.0.0.0 B 11.0.0.0

4-Routing Table
No BGP

Updates now can pass from A to B to E (C & D will consider it an IP packet

destined to E), update will go from E to F, but any returning data coming fromhmA
F will goto E and from E to C or D, but due to C & D doesnot have an entry ed
N
for 11.0.0.0 in their routing table , so packets destined to 11.0.0.0 will be abi
dropped, so black hole for data exists in AS65102 l
15
2-BGP run on borders and IGP inside AS
• Conclude:
BGP must run on all transit AS routers to avoid black holes, or
otherwise redistribution from BGP into IGP must take place
• Synchronization rule: (To avoid Black Holes)
Router cannot advertise routes to eBGP neighbor unless it exist in IP
routing table by an IGP (non-BGP)

To avoid synchronization problems (black holes):

1-redistribute BGP routes into IGP protocol (big headache for IGPs,
due to BGP table is very large and IGP is not designed for that
scalable networks)
2-run BGP on all transit AS routers and disable synchronization
(config-router)#no-synchronization

A
hm
ed
N
abi
l
16 BGP Synchronization
•Synchronization rule:
Do not use or advertise to an external neighbor a route learned by
IBGP until a matching route has been learned from an IGP.
• Ensures consistency of information throughout the AS
• Avoids black holes within the AS
• Safe to turn off if all routers in the AS are running full-mesh
IBGP, default.

Router(config-router)# no synchronization

• Disables BGP synchronization so a router can advertise routes

in BGP without learning them in IGP, but make sure that you
A
make all restrictions to avoid black holes hm
ed
N
abi
l
17
Example: BGP Synchronization

• If synchronization is on (the default), then:

– Routers A, C, and D would not use or advertise the route to 172.16.0.0
until they receive the matching route via an IGP.
– Router E would not hear about 172.16.0.0.
• If synchronization is off, then:
A
– Routers A, C, and D would use and advertise the route they receive via hm
ed
IBGP; router E would hear about 172.16.0.0. N
abi
– If router E sends traffic for 172.16.0.0, routers A, C, and D would route l
the packets correctly to router B.
18
3-BGP and IGP run on all routers of transit AS

• BGP Split horizon rule: "avoid routing loops inside the AS"
Route learned by iBGP neighbor can never be advertised back to another iBGP
neighbor
If Router A advertise a route to its eBGP neighbor B, so B must advertise that routes to
all it other neighbors, so B will advertise it to C & D, but due to split horizon rule, C
or D can never advertise that route again to their iBGP neighbor as E, so E will never
learn about that route.
A
hm
ed
• Conclude: N
abi
BGP must run in full mesh fashion (sessions between all BGP neighbors) to avoid l
split horizon rule
19 4-BGP must run in full mesh fashion

A
hm
• Full mesh BGP problem: ed
N
This will cause multiple TCP sessions, so a lot of CPU, memory abi
l
and bandwidth overhead will take place in the network
20
4-BGP must run in full mesh fashion
• Full mesh BGP problem:
The solution is to use:
1-Confederations:
divide the AS to sub ASs, where each Sub AS act with eBGP with other
sub Ass, so loops is avoided according to the eBGP rules (the advertised
route must contain a list of ASs that the route traverses, so if a router
finds its local AS in the AS path list it will detect that the update was
looped)
2-Route reflector:
to configure certain routers to override split horizon rule (route reflector
router)

Router Reflector configuration A

hm
• On Route Reflector only ed
N
(config)#router bgp <as#> abi
l
(config-router)#neighbor <neighbor ip> route-reflector-client
21
BGP considerations
1-Advertise routes in BGP updates (populate BGP table)
1.1-Redistribute IGP routes into BGP
1.2-Use Network command (Recommended)
(config)#router bgp <as# >
(config-router)#network <network address> [mask <subnet mask>]
Note: If no mask is specified, default masks is assumed
Note: There must be an exact match for that route in IP routing table
learned by IGP (non-BGP) so as for BGP to populate that route in
BGP table and advertise it to eBGP neighbors "synchronization
rule― or disable syncronization

A
hm
ed
N
abi
l
22
BGP considerations
1-Advertise routes in BGP updates (populate BGP table)

1. RouterB(config)# router bgp 65000

2. RouterB(config-router)# neighbor 10.1.1.2 remote-as 64520
3. RouterB(config-router)# neighbor 192.168.2.2 remote-as 65000
4. RouterB(config-router)# network 172.16.10.0 mask 255.255.255.0A
hm
5. RouterB(config-router)# network 192.168.1.0 ed
6. RouterB(config-router)# network 192.168.3.0 N
abi
7. RouterB(config-router)# no synchronization l
 23 2-Advertise summarized routes
(CIDR and Aggregate address)
• With BGP4, routes can be aggregated by any AS on any BGP router.
• BGP4 is classless, supports VLSM and longest match routing,
and carries a network mask for each network in the update.
‫اﻟﻣﺗﺑﺎﻋدة‬

• Auto summary is enabled by default at discontiguous network boundaries.

• To disable auto-summary
(config-router)#no auto-summary
• Manual summarization
Method 1: Recommended method of summarization for BGP
(config)#router bgp <as#>
(config-router)#aggregate-address <summary address> <mask>
[summary-only][as-set]
-Creates an aggregate (summary) entry in the BGP table
-Does not need an exact match in match in the routing table, due to BGP null route
automatically generated, Null static route not needed, but at least one of the specific
routes must exist. A
hm
-Uses the summary-only option to advertise only the summary and not the specific ed
routes N
-Adds the as-set option to include a list of all the autonomous system numbers that the abi
more specific routes have passed through l
24 2-Advertise summarized routes
(CIDR and Aggregate address)
• Auto summary is enabled by default at discontiguous network boundaries.

• Manual summarization
Method 1:

A
hm
ed
N
abi
l
25
Method 2:
(config)#router bgp <as#>
(config-router)#network <address> [mask <mask>]
This command was not designed to perform summarization by itself.
The aggregate-address command was designed for summarization.
• To use the network statement for summarization, the network number and mask used must
already exist exactly in the routing table.
• If the route was already summarized by EIGRP or OSPF, that summarization can be
‫أﻋﻠن‬
announced into BGP with the network and mask commands.
• If the route was not already summarized, a null static route must be created for BGP to
announce this summarization.
(config)#ip route <address> <mask> null0

A
hm
ed
N
abi
l
 26 Cautions about Network Statement
• If a network statement is used for summarization,
do not use the more specific entries and the
summarized route as shown here.
• If both are used, the
summarized route and the
more specific routes will
be announced.
• 192.168.24.0/22 does not
exist in the IP routing table
without the null route.
• BGP will not announce the network
unless the summarized route
is already present in the
routing table.

routerC# show ip bgp

BGP table version is 28, local router ID is 172.16.2.1

Status codes: s = suppressed, * = valid, > = best, and i = internal
Origin codes : i = IGP, e = EGP, and ? = incomplete A
Network 192.168.24.0/22 Next Hop 0.0.0.0 Metric LocPrf Weight Pathhm
*> 192.168.24.0 0.0.0.0 0.0.0.0 0 32768 i ed
s> s>
192.168.25.0 0.0.0.0 0.0.0.0 0 32768 i N
s> s>
192.168.26.0 0 32768 i abi
192.168.27.0 0 32768 i l
0 32768 i
27
3-Source of updates behaviour
• A router will never receive an update from a source unless that source
address is identified in its neighbor command (in its neighbor list)
• When a BGP packet is received for a new BGP session, the source
address of the packet is compared to the list of neighbor statements.
– If a match is found, a relationship is established.
– If no match is found, the packet is ignored.
• Make sure the source IP address matches the address that the other
router has in its neighbor statement.
• To identify the source of updates for a certain neighbor
(config)#router bgp <as#>
(config-router)#neighbor <neighbor ip> update-source <interface
name>
A
hm
ed
N
abi
l
28
3-Source of updates behaviour

A
hm
ed
N
abi
l
29 4-eBGP multihop
• Due to eBGP neighbors must be directly connected, so using
multiple links between the two neighbors, or using loopback as
source of update will cause a problem for the advertised updates
we can use the following command
(config-router)#neighbor <neighbor ip> ebgp-multihop [no. of
hops]

A
hm
ed
N
abi
l
 30 5-Next hop behavior
• BGP is an AS by AS routing protocol, not a router by router routing protocol, so in BGP next
hop does not mean the next hop router, it means the ip address to reach the next AS

-Router A advertises
network 172.16.0.0 to
router B in EBGP, with
a next hop of 10.10.10.3.
-Router B advertises
172.16.0.0 in IBGP to
router C, keeping 10.10.10.3
as the next-hop address.
-So C see the next hop to reach
172.16.0.0 is 10.10.10.3
(next AS entry point)
To override that behaviour
(config-router)#neighbor <neighbor ip> next-hop-self
Forces all updates for this neighbor to be advertised with this router as the next hop. The IP
address used for the next-hop-self will be the same as the source IP address of the BGP
A
packet.
hm
ed
So if B has written N
(config-router)# neighbor 172.20.10.2 next-hop-self abi
So C will see 172.16.0.0 with next hop 172.20.10.1 l
31
Next Hop on a Multiaccess Network
The following takes place in a multiaccess
network:
• Router B advertises
network 172.30.0.0 to
router A in EBGP with
a next hop of 10.10.10.2,
not 10.10.10.1. This avoids
an unnecessary hop.
• BGP is being efficient by
informing AS 64520 of the
best entry point into AS 65000
for network 172.30.0.0.

• Router B in AS 65000 also advertises to AS

64520 that the best entry point for each A
hm
network in AS 64600 is the next hop of router ed
C because that is the best pathway to transit N
abi
AS 65000 to AS 64600 from AS 64520. l
32
Example: next-hop-self Configuration

A
hm
ed
N
abi
l
33
6-BGP peer groups

• If there are multiple neighbors the configuration will be a big

overhead and configuration mistakes could happen

• Peer groups is defining a template with configuration parameters and

assign these parameters to a group of neighbors

• Useful when many neighbors have the same

outbound policies

• Members can have a different inbound policy

• Its target is to Simplify configuration

A
hm
ed
N
abi
l
34 Configuration without peer groups for 15 neighbor
(config)#router bgp <as#>
(config-router)#neighbor <ip> remote-as <as>
*15 times
(config-router)#neighbor <ip> route-reflector-client
*15 times
(config-router)#neighbor <ip> source-update loopback0
*15 times
(config-router)#neighbor <ip> next-hop-self
*15 times
(config-router)#neighbor <ip> route-map <name> <in/out>
*15 times
(config-router)#neighbor <ip> prefix-list <name> <in/out>
*15 times A
hm
(config-router)#neighbor <ip> distribute-list <name> <in/out> ed
N
*15 times abi
• we may need about 105 command on a single router l
35
Configuration with peer groups for 15 neighbor
(config)#router bgp <as>
(config-router)#neighbor <peer group name> peer-group
(config-router)#neighbor <ip> peer-group <peer group name>
*15 times
(config-router)#neighbor <peer group name> route-reflector-client
(config-router)#neighbor <peer group name> source-update loopback0
(config-router)#neighbor <peer group name> next-hop-self
(config-router)#neighbor <peer group name> route-map <name>
<in/out>
(config-router)#neighbor <peer group name> prefix-list <name>
<in/out>
(config-router)#neighbor <peer group name> distribute-list <name> A
hm
<in/out> ed
N
• we may need about 21 command on a single router abi
l
36

Example:

router bgp 65100

neighbor 192.168.24.1 remote-as 65100
neighbor 192.168.24.1 update-source loopback 0
neighbor 192.168.24.1 next-hop-self
Router C neighbor 198.168.24.1 distribute-list 20 out
Without a Peer neighbor 192.168.25.1 remote-as 65100
Group neighbor 192.168.25.1 update-source loopback 0
neighbor 192.168.25.1 next-hop-self
neighbor 198.168.25.1 distribute-list 20 out
neighbor 192.168.26.1 remote-as 65100
neighbor 192.168.26.1 update-source loopback 0
neighbor 192.168.26.1 next-hop-self
neighbor 198.168.26.1 distribute-list 20 out

router bgp 65100

neighbor internal peer-group
Router C neighbor internal remote-as 65100
neighbor internal update-source loopback 0 A
Using a Peer hm
Group neighbor internal next-hop-self
neighbor internal distribute-list 20 out ed
neighbor 192.168.24.1 peer-group internal N
neighbor 192.168.25.1 peer-group internal abi
neighbor 192.168.26.1 peer-group internal l
37 7-Authenticating in BGP

• BGP authentication uses MD5.

• Configure a key (password); router generates a message digest, or hash, of the key and
the message.
• Message digest is sent; key is not sent.
• Router generates and checks the MD5 digest of every segment sent on the TCP
connection. Router authenticates the source of each routing update packet that it
receives

Router(config-router)# neighbor {ip-address | peer-group-name} password string

A
hm
ed
N
abi
l
38
8-Multihoming
• Multiple connections to ISP is required to increase reliability
(redundancy) and performance (load sharing)
– Reliability—If one ISP or connection fails, there is still
Internet access
– Performance—Better path selection to common Internet
destinations

• Types of connectivity:
1-Default routes from all providers
– Pass default route to internal routers

2-ISPs pass default routes + selected specific routes owned by ISP

– Redistribute into Interior Gateway Protocol
(IGP) for internal routers, or
– Run BGP on all routers in the AS
A
hm
3-ISPs pass all routes in their routing tables to customer AS ed
– Run BGP on all internal routers; turn off N
BGP synchronization abi
l
39 Default Routes from All Providers
– Low memory and CPU usage
– ISPs send BGP default route
• Default route passed into IGP
• Choice of exit point when multiple default routes exist will be lowest
IGP metric
– The AS of the customer sends all of its routes to providers (ISPs)
– Inbound path to the AS of the customer is decided by the ISPs

A
hm
ed
N
abi
l
40
Provider-Owned Routes and the Default Route from Each Provider
– Medium memory and CPU usage
– Best path to ISP-owned networks and to customer specific networks are
usually the shortest AS path
– Have ability to override path choice for some networks
– IGP metric to default route used for all other destinations

A
hm
ed
N
abi
l
41
Full Routes from All Providers
– Higher memory and CPU usage
– Reach all destinations by best path
• Usually shortest AS path
– Can manually tune all pathways

A
hm
ed
N
abi
l
 42
Filter BGP Advertisements to ISPs

Router A Router B

router bgp 64500 router bgp 64500

network 10.0.0.0
neighbor 192.168.1.1 remote-as 65000
neighbor 192.168.1.1 distribute-list 7 out
(text omitted)
access-list 7 permit 10.0.0.0 0.255.255.255
network 10.0.0.0
neighbor 172.16.1.1 remote-as 64900
neighbor 172.16.1.1 distribute-list 7 out
(text omitted)
access-list 7 permit 10.0.0.0 0.255.255.255

A
Prevent a non-ISP (stub) AS from becoming a transit network by hm
performing route advertisement filtering using access lists. ed
N
abi
l
43
BGP attributes

• BGP is not designed to choose paths based on bandwidth, delay

and other metrics, but paths are chosen based on policy attributes
• Attributes are classified as follows:
Well known attributes: ‫ﻣﺗواﻓﻘﺔ‬

must be recognized by all compliant BGP implementation, Are

propagated to other neighbors
-well known mandatory ‫إﻟزاﻣﻲ‬

must present in all update messages (ex.: as-path, next-hop, origin)

-well known discretionary ‫ﺗﻘدﯾري‬

may be present in update messages

(ex.: local preference, atomic aggregate)

A
hm
ed
N
abi
l
44
BGP attributes
Optional attributes:
recognised by some implementations (expected not to be
recognised by every router (depend on router position in AS))
Recognized optional attributes are propagated to other neighbors
based on their meaning
-Optional transitive
if not recognised are marked as partial and propagated to other
neighbors
(ex.: aggregator, community)
-Optional non transitive
discarded if not recognised
(ex.: MED (Multi Exit Discriminator))
A
hm
-Cisco Attribute: ed
N
local attribute on Cisco routers, it is not advertised in any updates abi
l
ex.: weight
45
1-AS path attribute
• The AS path attribute is Well known mandatory, transitive

• It is a list of AS numbers that a route has traversed to reach a router

• Shortest AS path is prefered

• AS path list is used to avoid loops between ASs

A
hm
• A list of Autonomous Systems that a route has traversed ed
N
– For example, on router B, the path to 192.168.1.0 is abi
l
the AS sequence (65500, 64520).
46 2-Next hop attribute
• The next-hop attribute is Well known mandatory, transitive

• It is the ip address of the next AS to reach a given network

• Next hop must be reachable so as the route is valid for use

• For self originated route next hop is 0.0.0.0

The IP address of the next AS to reach a given network: A

• Router A advertises network 172.16.0.0 to router B in EBGP, with a next hop of hm
ed
10.10.10.3 N
• Router B advertises172.16.0.0 in IBGP to router C, keeping 10.10.10.3 as the abi
l
next-hop address
47
3-Origin attribute

• Well known mandatory, transitive

• The origin attribute informs all Autonomous Systems in

the internetwork how the prefixes were introduced into
BGP, It defines the origin of the path information

• The origin could be:

-IGP(i): the route is interior to the originating AS, this
normally happens when network command is used to
advertise the route
-EGP(e): the route is learned via EGP (old protocol), this
happen when a route was redistributed from EGP
-incomplete(?): the origin is unknown, this happen when the
route is redistributed from IGP or static into BGP A
hm
ed
• Least origin is preferred (i<e<?) N
abi
l
48
4-Local preference attribute
• Well known discretionary, and is passed only within the AS.

• The local preference is Advertised between iBGP neighbors

• It provides an indication to routers in the inside of the AS about which path is preferred
to exit the AS (best way to leave the AS, it influence outbound traffic from AS)

• Higher local preference is preferred

• Default local preference=100

A
hm
ed
N
abi
Any router inside the AS 64520 will prefer to exit that AS using path through A l
49 5-Multi Exit Discriminator (MED) attribute
• The MED is an optional, non transitive
• It is called metric
• Advertised between eBGP neighbors
• MED is an indication to eBGP neighbors about the prefered path to enter an
AS (affect how others can enter your AS, it influence inbound traffic to an AS)
• MED is used to advertise to EBGP neighbors how to exit their AS to reach
networks Owned by this AS.
• Lowest MED is prefered
• Default MED=0
• MED is not compared between neighbors from different ASs, unless
(config-router)#bgp-always-compare-med

A will choose to exit A

AS 65000 through B hm
ed
To reach 172.20.0.0 N
abi
l
50 6-Weight attribute
• Cisco attribute

• Configured locally on the router and is not propagated to any BGP neighbor

• It identify a weight for routes from each neighbor

• Highest weight is preferred

• Default weight for self originated routes are 32768, for other routes default is 0
(weight 0-65535)

A
hm
ed
N
abi
A will choose path through B l
to reach network 172.20.0.0
51 7-Atomic aggregate attribute
• Well known discretionary
• It informs the routers that the originating router has performed aggregation
(summarization) for routes, list of ASs that contain these routes can be
advertised (aggregate-address command)

8-Aggregator attribute
• Optional transitive
• It specifies the BGP router ID & AS no. of the router that perform the route aggregation

A
9- Community attribute hm
ed
• Optional transitive
N
• It is the grouping of routes and tag them for filtration actions abi
l
• All routes by default are members in a community called the Internet
52 BGP route selection process
• The BGP forwarding table usually has multiple pathways from
which to choose for each network.

• BGP is not designed to perform load balancing:

• Paths are chosen because of policy.
• Paths are not chosen based upon bandwidth.

• The BGP selection process eliminates any multiple pathways

through attrition until a single best pathway is left.

• That best pathway is submitted to the routing table manager

process and evaluated against the methods of other routing
protocols for reaching that network (administrative distance).

• The routing protocol with the lowest administrative distance will A

be installed in the routing table. hm
ed
N
abi
l
53 BGP route selection process

• Consider only synchronized routes, routes with no AS loops and

valid next hop routes, then:
1-Prefer highest weight (local to router)
2-Prefer highest local preference (global within AS)
3-Prefer route originated by the local router (next hop 0.0.0.0)
4-Prefer shortest AS path
5-Prefer lowest origin code (i (IGP) < e (EGP) < ? (incomplete))
6-Prefer lowest MED (from other AS)
7-For routes from other AS, prefer eBGP path over iBGP path
7*-Prefer oldest route from eBGP path (more stable)
7**-Prefer path through the closest (lowest metric) IGP neighbors
9-Prefer the path from lowest neighbor BGP router ID
A
hm
• Finally only a single path is selected, and no load sharing is ed
available N
abi
l
54 Optimize attributes
Local preference is used in the following ways:
• Within an AS between IBGP speakers
• Used to determine the best pathway to leave the AS to reach an outside
network
• Set to 100 by default; higher values are preferred

(config-router)#bgp default local-prefrence <value>

or
(config)#route-map <name> {permit/deny} [<seq no.>]
(config-route-map)#match ip address <acl #>
(config-route-map)#set local-preference <local preference>
• Changes the default local preference value A
hm
ed
N
abi
l
55 Optimize attributes
•All routes advertised to an IBGP neighbor are set to the value specified using this
command
RouterC# show ip bgp

BGP table version is 7, local router ID is 3.3.3.3

Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* i172.16.0.0 172.20.50.1 100 0 65005 65004 i
*>i 192.168.28.1 100 0 65002 65003 i
*>i172.24.0.0 172.20.50.1 100 0 65005 i
* i 192.168.28.1 100 0 65002 65003 65004 i
* i172.30.0.0 172.20.50.1 100 0 65005 65004 i
*>i 192.168.28.1 400 0 65002 65003 65004i

A
hm
Best (>) pathways for networks 172.16.0.0/16 and 172.24.0.0/16 have not changed. ed
N
Best (>) pathway for network 172.30.0.0 has changed to a new next hop of 192.168.28.1 abi
due to the next hop of 192.168.28.1 having a higher local preference, 400. l
56
• MED is used when multiple pathways exist between two ASs
• A lower MED value is preferred.
• The default setting for Cisco is MED = 0.
• The metric is nontransitive.
• By default, MED is shared only between two Autonomous
Systems that have multiple EBGP connections with each other.
(config-router)#default-metric <value>
or
(config)#route-map <name> {permit/deny} [<seq no.>]
(config-route-map)#match ip address <acl #>
(config-route-map)#set metric <MED value>

• MED is considered the metric of BGP. A

hm
ed
N
abi
l
 57
All routes advertised to an EBGP neighbor are set to the value specified using this command.

RouterZ# show ip bgp

BGP table version is 7, local router ID is 122.30.1.1
Status codes: s suppressed, d damped, h history, * valid,
> best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i192.168.24.0 172.20.50.2 100 100 0 65001 i
* i 192.168.28.2 200 100 0 65001 i
* i192.168.25.0 172.20.50.2 200 100 0 65001 i
*>i 192.168.28.2 100 100 0 65001 i
* i192.168.26.0 172.20.50.2 200 100 0 65001 i
*>i 192.168.28.2 100 100 0 65001 i

•For all networks: Weight is equal (0); local preference is equal (100); routes are not originated
in this AS; AS path is equal (65001); origin code is equal (i). A
hm
• 192.168.24.0 has a lower metric (MED) through 172.20.50.2 (100) than 192.168.28.2 (200). ed
N
• 192.168.25.0 has a lower metric (MED) through 192.168.28.2 (100) than 172.20.50.2 (200).
abi
• 192.168.26.0 has a lower metric (MED) through 192.168.28.2 (100) than 172.20.50.2 (200). l
58 Route maps for BGP policy implementation
1-Create route map:
(config)#route-map <name> <permit/deny> [seq. no.]
(config-route-map)#match <conditions>
(config-route-map)#set <condition>
2-Activate route map:
(config-router)#neigbhor <ip/peer group> route-map <name> <in/out>
-Match conditions:
match ip address <acl#>
match community <community name>
-Set conditions:
set local-preference <no.>
set weight <no.>
set metric <no.>
set as-path <path list> A
hm
ed
N
abi
l
59
Verification and Troubleshooting
#sh ip bgp
#sh ip bgp summary
#sh ip route
#debug ip bgp [events/updates/keepalives]
#clear ip bgp <*/address>
(config-router)#[no] neighbor <ip/peer group> shutdown

A
hm
ed
N
abi
l
60
Verification and Troubleshooting
RouterA# show ip bgp summary

BGP table version is 23, main routing table version 23

10 network entries and 11 paths using 1242 bytes of memory
4 BGP path attribute entries using 380 bytes of memory
BGP activity 23/13 prefixes, 38/27 paths
0 prefixes revised.

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

10.1.1.100 4 65200 211 211 13 0 0 00:01:53 5
192.168.1.18 4 65101 214 226 23 0 0 00:00:13 1
192.168.1.34 4 65101 214 226 23 0 0 00:00:09 1
192.168.1.50 4 65101 214 225 23 0 0 00:00:06 3

If no state in the state column this indicates an established state

RouterA# show ip bgp

BGP table version is 23, local router ID is 192.168.1.49

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 10.0.0.0 10.1.1.100 0 0 65200 i
*> 172.16.10.0/24 10.1.1.100 0 0 65200 i
*> 172.16.11.0/24 10.1.1.100 0 0 65200 i
*>i172.26.1.16/28 192.168.1.50 0 100 0 i
*>i172.26.1.32/28 192.168.1.50 0 100 0 i A
*>i172.26.1.48/28 192.168.1.50 0 100 0 i
hm
*> 192.168.1.0 0.0.0.0 0 32768 i
*> 192.168.2.0 10.1.1.100 0 65200 65102 i ed
*> 192.168.2.64/28 10.1.1.100 0 65200 65102 i N
* i192.168.101.0 192.168.1.34 0 100 0 i abi
*>i 192.168.1.18 0 100 0 i l
The table displays networks from lowest network to highest.
61 Clearing the BGP Session

• When policies such as access lists, timers, or attributes are changed,

the BGP session must be reset.
• The change takes effect immediately, and the next time a prefix or
pathway is advertised or received, the new policy will be used. It can
take a long time for the policy to be applied to all networks.
• The session should be reset to ensure the policy is immediately
applied to all affected prefixes and pathways.
• You must trigger an update to ensure that the policy is
immediately applied to all affected prefixes and paths.
• Ways to trigger an update:
– Hard reset
– Soft reset
– Route refresh A
hm
ed
N
abi
l
62 Clearing the BGP Session

router# clear ip bgp *

• Resets all BGP connections with this router
• Entire BGP forwarding table is discarded
• BGP session transitions from established to idle; everything
must be relearned
router# clear ip bgp [ip-address]
• Resets only a single neighbor
• BGP session transitions from established to idle; everything
from this neighbor must be relearned
• Better than the clear ip bgp *

A
hm
ed
N
abi
l
63
Soft Reset Outbound

Router# clear ip bgp {*|neighbor-address} [soft out]

• Routes learned from this neighbor are not lost.

• This router resends all BGP information to the neighbor without resetting the
connection.
• The connection remains established.
• This option is highly recommended when you are changing outbound policy.
• The soft out option does not help if you are changing inbound policy.

Inbound Soft Reset

Router(config-router)#
neighbor [ip-address] soft-reconfiguration inbound

• This router stores all updates from this neighbor in case the inbound policy is changed.A
hm
• The command is memory-intensive. ed
Router# clear ip bgp {*|neighbor-address} soft in N
abi
• Uses the stored information to generate new inbound updates l
64

RouterA# show ip bgp neighbors

BGP neighbor is 10.1.1.1, remote AS 65000, external link

Index 1, Offset 0, Mask 0x2
BGP version 4, remote router ID 172.16.10.1
BGP state = Established, table version = 5, up for 00:10:47
Last read 00:00:48, hold time is 180, keepalive interval is 60 seconds
Minimum time between advertisement runs is 30 seconds
Received 16 messages, 0 notifications, 0 in queue
Sent 15 messages, 1 notifications, 0 in queue
Prefix advertised 1, suppressed 0, withdrawn 0
Connections established 1; dropped 0
Last reset 00:16:35, due to Peer closed the session
2 accepted prefixes consume 64 bytes

A
hm
ed
N
abi
l
65

routerA# debug ip bgp updates

BGP updates debugging is on

RTRA# clear ip bgp *

3w5d: BGP: 10.1.1.1 computing updates, neighbor version 0, table

version 1, starting at 0.0.0.0
3w5d: BGP: 10.1.1.1 update run completed, ran for 0ms, neighbor
version 0, start version 1, throttled to 1, check point net 0.0.0.0
3w5d: BGP: 10.1.1.1 rcv UPDATE w/ attr: nexthop 10.1.1.1, origin i,
aggregated by 65000 172.16.10.1, path 65000
3w5d: BGP: 10.1.1.1 rcv UPDATE about 172.16.0.0/16
3w5d: BGP: nettable_walker 172.16.0.0/16 calling revise_route
3w5d: BGP: revise route installing 172.16.0.0/16 -> 10.1.1.1
3w5d: BGP: 10.1.1.1 rcv UPDATE w/ attr: nexthop 10.1.1.1, origin i,
metric 0, path 65000
3w5d: BGP: 10.1.1.1 rcv UPDATE about 192.168.1.0/24 A
3w5d: BGP: nettable_walker 192.168.1.0/24 calling revise_route hm
ed
3w5d: BGP: revise route installing 192.168.1.0/24 -> 10.1.1.1
N
abi
l