BGP

(Border Gateway Protocol)

226
Ahmed Nabil
 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.
• Currently new AS numbering (32 bit) was introduced and AS
23456 is used for interoperability between old numbering (16
bit) and new numbering (32 bit)

IGPs work within AS

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 227
 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

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 (i.e. memory or CPU error) 228
 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)

• Reliable updates: BGP run on top of TCP port 179.

• BGP has no method for dynamic neighbor discovery, all
neighbors must be discovered manually using the neighbor
command.
• Updates is sent on unicast address to the statically configured
neighbors.
• Full BGP tables is exchanged at start-up.
• Periodic keepalive messages to verify TCP connectivity at
convergence.
• Incremental batched updates every 30 sec at change.
• Its symbol in routing table is B.
• External BGP has admin. distance 20.
• Internal BGP has admin. distance 200.
• 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)
• BGP allows administrators to define policies or rules
for how data will flow through the Autonomous Systems. 229
 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.

BGP Starts its operation when neighbors are

statically defined, using the neighbor command
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.
• The neighbors do not
have to be directly
connected, because they
can be reached through
an IGP.
230
 Configuring BGP neighbors

This mean C is configuring A as eBGP

This mean A is configuring B as iBGP

and C as eBGP

This mean B is configuring A as iBGP

231
Ahmed Nabil
 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
Established state:
peering is formed and routing exchange begins
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
BGP open packet generated by this router 232
 Understanding BGP Requirements
1-BGP runs on borders of AS but no IGP

Update
11.0.0.0 About
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
table, so Bwill drop any updates going to E
• Conclude:
IGP must run inside the AS, so as the BGP neighbors
could be reachable

233
Ahmed Nabil
 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

About 2-Routing Table 5-Routing Table 7-Routing Table
11.0.0.0 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 from F will goto E and from E to C or D,
but due to C & D doesnot have an entry for 11.0.0.0 in their
routing table , so packets destined to 11.0.0.0 will be dropped,
so black hole for data exists in AS65102

• 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
234
 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.

• Conclude:
BGP must run in full mesh fashion (sessions between all
BGP neighbors) to avoid split horizon rule

235
Ahmed Nabil
 4-BGP must run in full mesh fashion

• Full mesh BGP problem:

This will cause multiple TCP sessions, so a lot of CPU,
memory and bandwidth overhead will take place in the
network
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
• On Route Reflector only
(config)#router bgp <as#>
(config-router)#neighbor <neighbor ip> route-reflector-client
236
BGP Considerations:
Neighborship considerations:
1- Neighbor command in BGP
2- Neighbor reachability (route to neighbor should exist
in routing table, using connected,static or IGP)
3- Fixed source of BGP messages and updates are
required (update-source)
4- Adjusting TTL if neighbor is eBGP (eBGP-multihop)

BGP Update Considerations:

1- Advertise using BGP network command.
2- Use (full mesh, Route Reflectors or Confederation) to
avoid BGP split horizon and data black holes.
3- Disable synchronization.
4- BGP Next hop behavior (next-hop-self on BGP
borders)

237
Ahmed Nabil
 1-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>
This command allows the BGP process to use the IP address of a
specified interface as the source IP address of all BGP updates to that
neighbor.
• A loopback interface is usually used, as it will be available as long as
the router is operational.
• The IP address used in this command will be the destination IP
address of all BGP updates and should be the loopback interface of
the other router.
• The update-source command is normally used only with IBGP
neighbors.
• The address of an EBGP neighbor must be directly connected by
default. The loopback of an EBGP neighbor is not directly connected.

238
 2-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 BGP open
message and the advertised updates, as all eBGP messages
by default are sent with TTL=1 (non routable messages)
we can use the following command
(config-router)#neighbor <neighbor ip> ebgp-multihop [no.
of hops]
but to reach that hop there will never be an IGP or connected
that could do that, so a static route is required to reach that
hop , default hop =255 if we used ebgp-multihop, in fact no.
of hops is a TTL, and default hop (TTL)=1 if that command is
not used.

The only acceptable dynamic routing protocol between ASs

is BGP, so for BGP session to be established we need to
reach the neighbor using Static route. 239
 3-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

240
Ahmed Nabil
 BGP considerations for updates
4-Advertise routes in BGP updates (populate BGP table)
4.1-Redistribute IGP routes into BGP
4.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.

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.0

5. RouterB(config-router)# network 192.168.1.0

6. RouterB(config-router)# network 192.168.3.0

7. RouterB(config-router)# no synchronization 241

 5-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.
-Uses the summary-only option to advertise only the summary and
not the specific routes
-Adds the as-set option to include a list of all the autonomous system
numbers that the more specific routes have passed through.

242
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

243
Ahmed Nabil
 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

Network Next Hop Metric LocPrf Weight Path

*> 192.168.24.0/22 0.0.0.0 0 32768 i
s> 192.168.24.0 0.0.0.0 0 32768 i
s> 192.168.25.0 0.0.0.0 0 32768 i
s> 192.168.26.0 0.0.0.0 0 32768 i
s> 192.168.27.0 0.0.0.0 0 32768 i

244
 6- BGP Synchronization
•Synchronization rule:
Do not use or advertise to any BGP neighbor (iBGP or eBGP)
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 make all restrictions to avoid black holes

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:
– Routers A, C, and D would use and advertise the
route they receive via IBGP; router E would hear
about 172.16.0.0.
– If router E sends traffic for 172.16.0.0, routers A, C,
and D would route the packets correctly to router B.
245
 7-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
packet.

So if B has written
(config-router)# neighbor 172.20.10.2 next-hop-self
So C will see 172.16.0.0 with next hop 172.20.10.1
246
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 network in AS 64600 is the
next hop of router C because that is the best pathway to
transit AS 65000 to AS 64600 from AS 64520.
Example: next-hop-self Configuration

247
 8-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
• It also help to process one update to all peer group at once
(less processing)

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
(config-router)#neighbor <ip> distribute-list <name>
<in/out>
*15 times
• we may need about 105 command on a single router 248
 Configuration with peer groups for 15 neighbor
(config)#router bgp <as>
(config-router)#neighbor <peer group name> remote-as 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> ebgp-multihop
(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> <in/out>
• we may need about 21 command on a single router
Example:

Router C Without a Peer Group

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
neighbor 198.168.24.1 distribute-list 20 out
neighbor 192.168.25.1 remote-as 65100
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 C Using a Peer Group

router bgp 65100
neighbor internal peer-group
neighbor internal remote-as 65100
neighbor internal update-source loopback 0
neighbor internal next-hop-self
neighbor internal distribute-list 20 out
neighbor 192.168.24.1 peer-group internal
neighbor 192.168.25.1 peer-group internal
neighbor 192.168.26.1 peer-group internal 249
BGP Considerations:
Neighborship considerations:
1- Neighbor command in BGP
2- Neighbor reachability (route to neighbor should exist
in routing table , using connected, static or IGP)
3- Fixed source of BGP messages and updates are
required (update-source)
4- Adjusting TTL if neighbor is eBGP (eBGP-multihop)

BGP Update Considerations:

1- Advertise using BGP network command.
2- Use (full mesh, Route Reflectors or Confederation) to
avoid BGP split horizon & data Black holes.
3- Disable synchronization.
4- BGP Next hop behavior (next-hop-self on BGP
borders)

250
Ahmed Nabil
 BGP Attributes
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 list of Autonomous Systems that a route has

traversed
– For example, on router B, the path to 192.168.1.0
is
the AS sequence (65500, 64520).

251
Ahmed Nabil
 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:

• Router A advertises network 172.16.0.0 to router B in
EBGP, with a next hop of 10.10.10.3
• Router B advertises172.16.0.0 in IBGP to router C,
keeping 10.10.10.3 as the next-hop address

252
Ahmed Nabil
 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

• Least origin is preferred (i<e<?)

253
Ahmed Nabil
 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

Any router inside the AS 64520 will prefer to exit that

AS using path through A

254
Ahmed Nabil
 5-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 will choose path through B

to reach network 172.20.0.0

255
Ahmed Nabil
 6-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

AS 65000 through B
To reach 172.20.0.0

256
 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

9- Community attribute
• Optional transitive
• It is the grouping of routes and tag them for
filtration actions and applying policies to group
of routes belonging to certain community.
• All routes by default are members in a
community called the Internet
257
 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 be installed in the routing table.

• 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
• Finally only a single path is selected, and no load sharing
is available
258
 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)
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))
-Cisco Attribute:
local attribute on Cisco routers, it is not advertised in any
updates
ex.: weight
259
 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
• 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 65004 i

Best (>) pathways for networks 172.16.0.0/16 and 172.24.0.0/16 have not changed.
Best (>) pathway for network 172.30.0.0 has changed to a new next hop of 192.168.28.1
due to the next hop of 192.168.28.1 having a higher local preference, 400.
260
 • 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.
• 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).
• 192.168.24.0 has a lower metric (MED) through 172.20.50.2 (100) than 192.168.28.2 (200).
• 192.168.25.0 has a lower metric (MED) through 192.168.28.2 (100) than 172.20.50.2 (200).
• 192.168.26.0 has a lower metric (MED) through 192.168.28.2 (100) than 172.20.50.2 (200).
261
 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-prepend <path list>
Set community community id

262
Ahmed Nabil
 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

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
*>i172.26.1.48/28 192.168.1.50 0 100 0 i
*> 192.168.1.0 0.0.0.0 0 32768 i
*> 192.168.2.0 10.1.1.100 0 65200 65102 i
*> 192.168.2.64/28 10.1.1.100 0 65200 65102 i
* i192.168.101.0 192.168.1.34 0 100 0 i
*>i 192.168.1.18 0 100 0 i

The table displays networks from lowest network to highest.

263
 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
Router# clear ip bgp {*|neighbor-address}
[soft {in | out}]
• Resets all BGP connections with this router using * or Resets
only a single neighbor
• If not using soft option (hard reset):
- Entire BGP forwarding table is discarded
- BGP session transitions from established to idle; everything
must be relearned
Using Soft Reset option:
• 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. 264
 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

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
3w5d: BGP: nettable_walker 192.168.1.0/24 calling revise_route
3w5d: BGP: revise route installing 192.168.1.0/24 -> 10.1.1.1

265