CIS 185 CCNP ROUTE

Ch. 6 Border Gateway Protocol Solution

for ISP Connectivity Part 1
Rick Graziani
Cabrillo College
graziani@cabrillo.edu

Last Updated: Fall 2010

Materials
Book:
Implementing Cisco IP Routing
(ROUTE) Foundation Learning
Guide: Foundation learning for the
ROUTE 642-902 Exam
By Diane Teare
Book
ISBN-10: 1-58705-882-0
ISBN-13: 978-1-58705-882-0
eBook
ISBN-10: 0-13-255033-4
ISBN-13: 978-0-13-255033-8

2
Terms

What is an IGP (Interior Gateway Protocol)?

Routing protocol used to exchange routing information within an
autonomous system.
RIP, IGRP, EIGRP, OSPF, IS-IS
What is an EGP (Exterior Gateway Protocol)?
Routing protocol used to exchange routing information between
autonomous systems.
BGP (Border Gateway Protocol) is an Interdomain Routing Protocol
(IDRP), which is also known as an EGP.
BGP - is a path vector routing protocol.
What is an Autonomous System ?
(From RFC 1771) A set of routers under the single technical
administration, using an IGP and common metrics to route packets
within the AS, and using an EGP to route packets to other ASs. 3
 BGP version 4 (BGP-4) (latest version of BGP)
It is defined in Requests for Comments (RFC) 4271, A Border Gateway
Protocol (BGP-4).
As noted in this RFC, the classic definition of an AS is A set of routers
under a single technical administration, using an Interior Gateway Protocol
(IGP) and common metrics to determine how to route packets within the AS,
and using an inter-AS routing protocol to determine how to route packets to
other [autonomous systems].
Extensions to BGP-4 (known as BGP4+) includes IPv6.
4
BGP Use Between Autonomous Systems

Main goal is to provide an interdomain routing systems that guarantees the

loop-free exchange of routing information between ASs.
BGP is a successor to Exterior Gateway Protocol (EGP). (Note the dual use of
the EGP acronym.)
BGP-4 is a classless routing protocols so it supports:
VLSM
CIDR
There are more than 300,000 CIDR blocks
Without CIDR full Internet routing tables would contain more than
5
2,000,000 entries.
Comparison with Other Scalable Routing
Protocols

BGP does not look at speed for the best path.

BGP is a policy-based routing protocol that allows an AS to control traffic
flow using multiple BGP attributes.
Routers exchange network reachability information, called path vectors or
attributes
These include a list of the full path of BGP AS numbers that a router
should take to reach a destination network.

6
When to use BGP and when not to use BGP

Use BGP when the effects of BGP are well understood and one of the following
conditions exist:
The AS allows packets to transit through it to reach another AS (transit AS).
The AS has multiple connections to other ASs.
The flow of traffic entering or exiting the AS must be manipulated.
This is policy based routing and based on attributes.

7
When to use BGP and when not to use BGP

Do not use BGP if you have one or more of the following conditions:
A single connection to the Internet or another AS
No concern for routing policy or routing selection
A lack of memory or processing power on your routers to handle constant
BGP updates
A limited understanding of route filtering and BGP path selection process
Low bandwidth between ASs

8
Who needs BGP?

Not as many internetworks as you may think.

You should implement BGP only when a sound engineering reason
compels you to do so, such as when the IGPs do not provide the
tools necessary to implement the required routing policies or when
the size of the routing table cannot be controlled with
summarization.
The majority of the cases calling for BGP involve Internet
connectivity either between a subscriber and an ISP or (more
likely) between ISPs.
Yet even when interconnecting autonomous systems, BGP might
be unnecessary.
Jeff Dolye, Routing TCP/IP Vol. II

9
Overview of autonomous systems

AS - A group of routers that share similar routing policies and operate within
a single administrative domain.
An AS can be a:
Collection of routers running a single IGP (Single company)
Collection of routers running different protocols all belonging to one
organization (ISP)
In either case, the outside world views the entire Autonomous System as a
single entity.
10
Overview of autonomous systems

AS Numbers
Assigned by an Internet registry or a service provider.
Between 1 and 65,535.
0 - Reserved
1 through 64,495 Assignable for public use
64,512 through 65,535 - Private use
This is similar to RFC 1918 IP addresses.
65,535 - Reserved
Because of the finite number of available AS numbers, an organization must
present justification of its need before it will be assigned an AS number.
11
 Today, the Internet Assigned Numbers Authority (IANA) is enforcing a policy
whereby organizations that connect to a single provider and share the
provider's routing policies use an AS number from the private pool, 64,512
to 65,535.

12
 RFC 4893 BGP Support for Four-Octet AS Number Space describes 32 bit
AS numbers the anticipated depletion of current BGP 16-bit AS numbers
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps659
9/white_paper_C11_516823.html
http://www.potaroo.net/tools/asn16/
http://www.iana.org/assignments/as-numbers/as-numbers.xml

13
Using BGP

BGP dynamically exchanges routing information

BGP reacts to topology changes including those changes beyond a
customer-to-ISP link failure.

14
 Connection Redundancy
The ISP connection can also be made redundant.
A customer can be connected to a single ISP or to multiple ISPs.

15
Single-homed autonomous systems

Single-homed system AS
One Link per ISP, One ISP
Only one exit point to outside networks.
Often referred to as stub networks or stubs.
Usually use a default route to handle all traffic destined for non-local
networks.
BGP is not normally needed in this situation

16
Single-homed autonomous systems

IGP Option
IGP: Both the provider and the customer use an IGP to share information
regarding the customer's networks.
Customer:
Sends public network address
Receives default route 17
Single-homed autonomous systems

BGP Option
In a single-homed autonomous system the customer's routing policies
are an extension of the policies of the provider.
Internet number registries are unlikely to assign public AS number.
AS number from the private pool of AS numbers, 64,512 to 65,535.
The provider will strip off these numbers when advertising the
customer's routes towards the core of the Internet. (later)

18
Dual Homed

Option 3

Dual-homed AS
Two or more links per ISP, One ISP
Same options as single-homed
Additional advantages:
Primary and backup link functionality
Load Balancing
19
Single Multi-homed

Multi-homed or Single Multi-homed

One link per ISP, two or more ISPs
Typically recommended to run BGP
Options: (more later on these)
ISP1 and ISP2: Full Internet routes
ISP1: Full Internet routes; ISP2: Partial updates (selected)
ISP1: Default route; ISP2: Partial updates (selected)
20
 http://bgp.potaroo.net/ 10/31/2010

Caution in receiving full Internet routes:

Over 300,000 summarized routes (over 2,000,000 un-summarized)
100,000 routes require about 70 MB of RAM for the BGP table

21
Dual Multi-homed

Dual Multi-homed
Two or more links per ISP, Two or more ISPs
Similar options as Single Multi-homed
Same benefits as single multi-homed but with enhanced resiliency.

22
Using BGP in an Enterprise Network

External BGP (EBGP) - When BGP is running between routers in different

autonomous systems.
Internal BGP (IBGP) - When BGP is running between routers in the same
AS.
Understanding how BGP works is important to avoid creating problems for
your AS as a result of running BGP.

23
 Transit
AS

Multihomed system
More than one exit point to outside networks.
May be a:
Transit
Non-transit AS
Transit traffic - Traffic that has a source and destination outside the AS.
Transit AS - allows transit traffic
Non-transit AS - does not allow transit traffic.
Advertises only its own routes to both the providers
Does not advertise routes it learned from one provider to another.
Therefore, ISP1 will not use AS 24 to reach destinations that belong to ISP2
24
and visa versa.
 AS 65500 is learning routes from both ISP-A and ISP-B via EBGP
Also running IBGP on all of its routers. (later)
Learns about routes and chooses the best way to each one based on the
configuration of the routers in the AS and the BGP routes passed from the
ISPs.
If one of the connections to the ISPs goes down, traffic will be sent
25
through the other ISP.
 Transit AS

AS 65500 wants to have a redundant Internet connection, but does not want
to act as a transit AS between ISP-A and ISP-B.
AS 65500 learns from ISP-A is the route to 172.18.0.0/16.
If that route is:
Propagated through AS 65500 using IBGP
And mistakenly announced to ISP-B
Then ISP-B might decide that the best way to get to 172.18.0.0/16 is
through AS 65500, instead of through the Internet.
AS 65500 would then be considered a transit AS (an ISP)
Not a very undesirable situation
26
Careful BGP configuration is required to avoid this situation.
 Default Route Default Route
+ ISP1 Routes

Default Route Default Route

+ ISP2 Routes

If an organization has determined that it will

perform multihoming with BGP, three
common ways to do this are as follows:
Each ISP passes only a default route to All Internet
Routes
the AS
The default route is passed to the
internal routers.
Each ISP passes only a default route and
provider-owned specific routes to the AS
These routes can be passed to internal All Internet
routers, or all internal routers in the Routes
transit path can run BGP and pass
these routes between them.
Each ISP passes all routes to the AS
All internal routers in the transit path run
BGP and pass these routes between 27
them.
Multihoming with Default
Routes from All Providers

AS 65500
Send Networks Send
0.0.0.0/0 0.0.0.0/0

First multihoming option is to receive

only a default route from each ISP. ?
Both edge routers learn a default route from their attached ISP
Propagate it into the routing domain via an IGP
Requires the least resources
AS 65500 propagates its owned routes to both ISPs
If a router within the AS learns about multiple default routes, the local IGP
installs the best default route into the routing table.
This does allow AS 65500 the capability of adding new customers (new
networks) without relying on upstream provider.
Otherwise ISP would have to create the network and add a static
28
route pointing to AS 65500
Multihoming with Default
Routes and Partial Table
from All Providers

AS 65500
Networks Sends ISPB
Sends ISPA
Prefixes and
Prefixes and
0.0.0.0/0
0.0.0.0/0
Both ISPs pass default routes
plus select specific routes to
the AS.

The internal routers of the customer can receive these routes via:
Redistribution into IGP
IBGP transit path (later)
The internal routers route packets:
ISP A networks via ISP A
ISP B networks via ISP B
Default routes via nearest edge router (possible suboptimal routing)

29
Multihoming with Full
Routes from All Providers
All ISPs pass all routes to the
AS
IBGP is run on at least all the AS 65500
routers in the transit path in this Sends all Networks Sends all
Internet
AS. Internet
Routes
Routes
Requires a lot of resources
within the AS because it must
process all the external routes.
The internal routers of the customer can receive these routes via:
Redistribution into IGP (ex: OSPF): Not recommended!
IBGP transit path (later): Well say this is the case.
The ISP that a specific router within AS 64500 uses to reach the external
networks is determined by the IBGP protocol.
The routers in AS 64500 can be configured to influence the path to certain
networks.
For example, Router A and Router B can influence the outbound traffic from AS
64500. (Later - Attributes) 30
BGP Path Vector Characteristics

Path Advertised:
64520 64600 64700
Networks in AS 64700:
192.168.24.0
192.168.25.0
172.20.0.0

IGP routing protocols use metrics to determine best path.

Cost (Bandwidth), BW+DLY-REL-Load, Hop Count
BGP routers exchange network reachability information, called path vectors,
made up of path attributes
The path vector information includes a list of the full path of BGP AS
numbers (hop-by-hop) necessary to reach a destination network.
Other attributes include:
IP address of the next-hop AS (the next-hop attribute)
How the network was introduced into BGP (the origin code attribute)
And more later! 31
 AS Path information is used to construct a graph of loop-free ASs and to
identify routing policies (later)
AS 64512: AS Path to 192.168.24.0 = 64520 > 64600 > 64700
BGP AS Path is guaranteed to be loop free.
BGP router does not accept a routing update that already includes its
own AS number in the AS Path list.

32
 172.16.0.0/16
(4, 2, 1)
Loop Free Path 172.16.0.0/16
(6, 5, 3, 1) AS7

AS4

AS6

AS2

AS5 AS3 AS1

172.16.0.0/16

AS_PATH
List of AS numbers associated with a BGP route
One of several path attributes associated with each route.
Path attributes will be discussed in much more detail later.
We will discuss how BGP chooses best path later.
The shortest inter-AS path is very simply determined by the least number of AS
numbers.
In this example, AS7 will choose the shortest path (4, 2, 1).
We will see later what happens with equal cost paths.
33
 172.16.0.0/16
(7,4,2,1)

Loop Free Path AS8

172.16.0.0/16
(8,7,4,2,1)
AS9 172.16.0.0/16
(4, 2, 1)
X AS7
172.16.0.0/16
(9,8,7,4,2,1)
AS4

AS6

AS2

AS5 AS3 AS1

172.16.0.0/16

Routing Loop Avoidance

Route loops can be easily detected when a router receives an update
containing its local AS number in the AS_PATH.
When this occurs, the router will not accept the update, thereby avoiding a
potential routing loop.

34
 Possible paths for AS 64512 to reach networks in AS 64700, through AS
64520:
64520 64600 64700
64520 64600 64540 64550 64700
64520 64540 64600 64700
64520 64540 64550 64700
AS 64512 does NOT see all these possibilities.
AS 64520 advertises to AS 64512 only its best path:
64520 64600 64700 (assuming no other policies supersede AS Path)
AS 64512 could also get a best path from AS 64530
AS 64512 would then decide which path is best (via 64530 or via 64520)
35
based on its own AS policies.
 Multihomed nontransit autonomous systems
Here are the
Here are the
networks you can
networks you
reach through me.
can reach
I will try and make it
through me.
so that you prefer
me.

We have a choice
on which way to
send our traffic.

Incoming route advertisements influence your outgoing traffic, and

outgoing advertisements influence your incoming traffic.

36
 Multihomed nontransit autonomous systems

These are the These are the networks you

networks you can reach through me.
can reach I will include ISP1 networks
through me, but but include my AS number
I will not include multiple times so you may
ISP2 networks. prefer another route.

Incoming route advertisements influence your outgoing traffic, and

outgoing advertisements influence your incoming traffic.

37
BGP Hazards Inadvertent Transit Domain

We inadvertently advertise routes learned from ISP2 to ISP1.

ISP1 customers will see our network as the best path to ISP2 customers.
We have become a transit domain for packets from ISP1 to ISP2.
More later

38
BGP Hazards Doyle, Routing TCP/IP

BGP Peering
Creating a BGP peering relationship involves an interesting
combination of trust and mistrust.
You must trust the network administrator on that end to know what
they are doing.
At the same time, if you are smart, you will take every practical
measure to protect yourself in the event that a mistake is made on
the other end.
Paranoia is your friend. 39
BGP Hazards Doyle, Routing TCP/IP
Your ISP will show little patience with you if you make mistakes in your BGP
configuration.
Suppose, for example, that through some misconfiguration you advertise
207.46.0.0/16 to your ISP.
On the receiving side, the ISP does not filter out this incorrect route, allowing
it to be advertised to the rest of the Internet.
This particular CIDR block belongs to Microsoft, and you have just claimed to
have a route to that destination.
A significant portion of the Internet community could decide that the best
path to Microsoft is through your domain.
You will receive a flood of unwanted packets across your Internet connection
and, more importantly, you will have black-holed traffic that should have gone
to Microsoft.
They will be neither amused nor understanding.

40
YouTube Hijacking: A RIPE NCC
RIS case study
YouTube Hijacking: A RIPE NCC RIS case study
This presentation is taken from RIPE NCC web site.
For more detailed information, please consult this web site:
http://www.ripe.net/news/study-youtube-hijacking.html

Movie: BBC Report

Movie: RIPE NCC

The following presentation is an accurate representation of what

took place, but using a simplified topology.

On Sunday, 24 February 2008, Pakistan Telecom (AS17557)

started an unauthorised announcement of the prefix
208.65.153.0/24.
One of Pakistan Telecom's upstream providers, PCCW Global
(AS3491) forwarded this announcement to the rest of the
Internet, which resulted in the hijacking of YouTube traffic on a
global scale.
42
 Before, during and after Sunday, 24 February 2008

Internet

BGP

DNS servers resolve www.youtube.com to:

208.65.153.251
208.65.153.253
43
208.65.153.238
Before, during and after Sunday, 24 February 2008

Internet

BGP

208.65.152.0/22

YouTube summarizes (CIDR) its /24 networks as a single /22:

208.65.152.0/24 11010000. 01000001.10011000.00000000
208.65.153.0/24 11010000. 01000001.10011001.00000000
208.65.154.0/24 11010000. 01000001.10011010.00000000
--------------------------------------
208.65.152.0/22 11010000. 01000001.10011000.00000000

44
Before, during and after Sunday, 24 February 2008

Internet

BGP

208.65.152.0/22

Before, during and after Sunday, 24 February 2008:

AS36561 (YouTube) announces 208.65.152.0/22.
Note that AS36561 also announces other prefixes, but they are not involved
in the event.

45
Before, during and after Sunday, 24 February 2008

Internet

2 hops 1 hop

BGP

4 hops 3 hops 208.65.152.0/22

3 hops 1 hop

2 hops

BGP
Unless other policies are used, routers will choose the shortest AS path.
This is a simplification of BGP, assuming shortest AS-Path is being used.

46
Before, during and after Sunday, 24 February 2008
www.youtube.com ip route 206.63.153.0 255.255.255.0 null0
206.65.153.0/24
Internet

2 hops 1 hop

BGP

4 hops 3 hops 208.65.152.0/22

3 hops 1 hop

2 hops
Pakistan Telecom
Wants to block traffic within its own AS from going to www.youtube.com.
Note: Details of how they did this is not known at them time this presentation
was created.
Most likely they created a route within their own AS that sent any traffic to
208.65.153.0/24 (DNS address for www.youtube.com) to a non-existent
network, in effect denying their own customers access to www.youtube.com.
47
Their mistake was that they propagated this route to PCCW Global.
 Sunday, 24 February 2008, 18:47 (UTC)
Internet

2 hops 1 hop
2 hops 3 hops
BGP

4 hops 3 hops 208.65.152.0/22

1 hop
208.65.153.0/24
3 hops 1 hop
2 hops 2 hops 4 hops
3 hops

Sunday, 24 February 2008, 18:47 (UTC):

AS17557 (Pakistan Telecom) starts announcing the more specific route of
208.65.153.0/24.
AS3491 (PCCW Global) propagates the announcement.
Routers around the world receive the announcement, and YouTube traffic is
48
redirected to Pakistan.
 Internet
Routed traffic to
youtube.com

BGP

? 208.65.152.0/22
208.65.153.0/24

Dest IP = 208.65.153.251
Why do the ISP routers forward traffic to Pakistan Telecom?
When a router receives packets for 208.65.153.251 which path will it
choose?
Routers will learn about both 208.65.153.0/24 and 208.65.152.0/22
networks and install the both routes in their routing tables.
When a router receives packets for 208.65.153.251 it will choose the
longest prefix match (more specific match): 208.65.153.0/24
49
24 bits is a longer (better) match than 22 bits
 Sunday, 24 February 2008, 20:07 (UTC):

Internet
Routed traffic to
youtube.com

BGP

208.65.152.0/22
208.65.153.0/24 208.65.153.0/24

Sunday, 24 February 2008, 20:07 (UTC):

AS36561 (YouTube) starts announcing the same, more specific prefix of
208.65.153.0/24.
With two identical prefixes in the routing system, BGP policy rules, such as
preferring the shortest AS path, determine which route is chosen.
This means that AS17557 (Pakistan Telecom) continues to attract some of
YouTube's traffic. 50
 Sunday, 24 February 2008, 20:07 (UTC):

Internet
Routed traffic to
youtube.com

BGP

208.65.152.0/22
208.65.153.0/24 208.65.153.0/24
208.65.153.0/25
208.65.153.128/25

Sunday, 24 February 2008, 20:18 (UTC):

AS36561 (YouTube) starts announcing an even more specific prefixes of
208.65.153.128/25 and 208.65.153.0/25.
Because of the longest prefix match rule, every router that receives these
announcements will send the traffic to YouTube.
51
 Sunday, 24 February 2008, 20:07 (UTC): For CCNP students

Internet
Routed traffic to
youtube.com

BGP

208.65.152.0/22
208.65.153.0/24 208.65.153.0/24
208.65.153.0/25
For CCNP students 208.65.153.128/25

Sunday, 24 February 2008, 20:51 (UTC):

All prefix announcements, including the hijacked /24 which was originated
by AS17557 (Pakistan Telecom) via AS3491 (PCCW Global), are seen
prepended by another 17557.
This makes the route via AS17557 look like more hops.
The longer AS path means that more routers prefer the announcement
originated by YouTube. 52
 Sunday, 24 February 2008, 20:07 (UTC):

Internet
Routed traffic to
youtube.com

X BGP

208.65.152.0/22
208.65.153.0/24 208.65.153.0/24
208.65.153.0/25
208.65.153.128/25

Sunday, 24 February 2008, 21:01 (UTC):

AS3491 (PCCW Global) withdraws all prefixes originated by AS17557
(Pakistan Telecom), thus stopping the hijack of 208.65.153.0/24.
Note that AS17557 was not completely disconnected by AS3491.
Prefixes originated by other Pakistani ASs were still announced by AS17557
through AS3491. 53
Back to BGP
BGP
Characteristics

BGP updates are carried using TCP on port 179.

In contrast:
RIP updates use UDP port 520
EIGRP uses EIGRPs RTP
OSPF does not use a Layer 4 protocol but uses OSPF mechanisms
for reliability (OSPF ACKs)
Because BGP requires TCP:
IP connectivity must exist between BGP peers.
TCP connections must also be negotiated between them before updates
can be exchanged.
BGP inherits those reliable, connection-oriented properties from TCP.
Flow control properties as well (sliding windows)
BGP assumes that its communication is reliable and therefore, BGP does not
have to implement any retransmission or error-recovery mechanisms, like
55
EIGRP or OSPF does.
BGP Neighbor Relationships

Neighbors or peers - Two routers that establish a TCP-enabled BGP

connection between each other.
BGP speaker - Each router running BGP.
A BGP speaker has a limited number of BGP neighbors with which it peers
and forms a TCP-based relationship.
BGP peers can be either:
Internal to the AS
External to the AS 56
External BGP Neighbors
EBGP: BGP is running between routers in different autonomous systems.
Routers running EBGP are usually directly connected to each other
EBGP multi-hop allows EBGP neighbors not to be directly connected
(later)

57
There are several requirements for EBGP neighborship:
Different AS number:
EBGP neighbors must reside in different autonomous systems to be
able to form an EBGP relationship.
Define neighbors:
A TCP session must be established prior to starting BGP routing update
exchanges.
Reachability:
The IP addresses used in the neighbor command must be reachable
58
EBGP neighbors are usually directly connected.
EBGP
RTA(config)#router bgp 100
RTA(config-router)#

RTB(config)#router bgp 200

RTB(config-router)#

Configuring EBGP neighbors (more later)

To begin configuring a BGP process, issue the following familiar command:
Router(config)#router bgp AS-number

BGP configuration commands appear similar to familiar IGP but it is different!

Note: Cisco IOS permits only one BGP process to run at a time, thus, a router
cannot belong to more than one AS.
Because the two AS numbers are different, BGP will start an EBGP connection with 59
RTA.
EBGP
RTA(config)#router bgp 100
RTA(config-router)#neighbor 10.1.1.1 remote-as 200

RTB(config)#router bgp 200

RTB(config-router)#neighbor 10.1.1.2 remote-as 100

Configuring EBGP neighbors (more later)

Neighbor command - Used to establish a neighbor relationship with another BGP
router.
Router(config-router)#neighbor ip-address remote-as AS-number
Identifies a peer router with which the local router will establish a session.
The AS-number argument determines whether the neighbor router is an EBGP or an
IBGP neighbor
Different AS numbers mean EBGP peers
60
Same AS numbers mean IBG peers
Internal BGP Neighbors
IBGP: When BGP is running between routers within the same AS
IBGP is run within an AS to exchange BGP information so that:
All internal BGP routers have the same BGP routing information about
outside autonomous systems
This information can be passed to other autonomous systems.
Typically full-mesh on all routers in the transit path between ASs
61
There are several requirements for IBGP neighborship:
Same AS number:
IBGP neighbors must reside in the same AS to be able to form an IBGP
relationship.
Define neighbors:
A TCP session must be established between neighbors prior to start
exchanging BGP routing updates.
Reachability:
IBGP neighbors must be reachable; an IGP typically runs inside the AS.
62
Do not have to be directly connected.
RTB(config)#router bgp 200
RTB(config-router)#neighbor 172.16.1.2 remote-as 200

RTC(config)#router bgp 200

RTC(config-router)#neighbor 172.16.1.1 remote-as 200

The remote-as value (200) is the same routers will attempt to establish an
IBGP session.
Note: AS 200 is not a remote AS , for simplicity, the keyword remote-as is
used.
63
 Transit Path

Transit Path

Described more in the next section

You must set up IBGP sessions between all routers in the transit path in AS
65500 so that each router in the transit path within the AS learns about
paths to the external networks via IBGP.
Note: Can also redistribute into the IGP but this is not usually
recommended.

64
IBGP in a Transit AS
Transit Path

Transit Path

BGP was originally intended to run along the borders of an AS, with the
routers in the middle of the AS ignorant of the details of BGP
A transit AS is an AS that routes traffic from one external AS to another
external AS.
Transit autonomous systems are typically ISPs.
All routers in a transit path must have complete knowledge of external routes.
Run IBGP on all routers within the AS transit path
Redistribute BGP routes into an IGP at the edge routers (however, this
approach has problems) 65
IBGP in a Nontransit AS

X
X I learned about networks from
ISP2 but I cant tell ISP1 or ISP1
might forward packets to me to get
to those networks making me a
transit AS.

A Nontransit AS:
AS multihoming with two ISPs
But does not pass routes between the ISPs

66
 BGP Peers
IBGP

IBGP
EBGP

The designers of BGP could not guarantee that an AS would run BGP on all routers
So a method had to be developed to ensure that IBGP speakers could pass updates to one
another while ensuring that no routing loops would exist.
All IBGP routers (in the transit path) need to peer with each other (full mesh)
Note: Although this presentation refers to all IBGP routers in the transit path must be
fully-meshed, it is recommended that all IBGP routers in the AS are fully-meshed IBGP.
This will be discussed in Part 2.
BGP specifies that routes learned through IBGP are never propagated to other IBGP
peers.
By default, each BGP speaker is assumed to have a neighbor statement for all other IBGP
speakers in the ASthis is known as full mesh IBGP.
When a change is received from an external AS:
The BGP router is responsible for informing all other IBGP neighbors of the change.
67
IBGP neighbors that receive this update do not send it to other IBGP neighbors
BGP Partial-Mesh and Full-Mesh Examples

68
IBGP update behavior in a partially meshed neighbor environment

BGP Update

Router B receives a BGP update from Router A.

Router B has two IBGP neighbors, Routers C and D
Router B does not have an IBGP neighbor relationship with Router E.
Routers C and D learn about any networks that were added or withdrawn
behind Router B.
Routers C and D have IBGP neighbor sessions with Router E but do not
replicate the update and send it to Router E.
Sending the IBGP update to Router E is Router Bs responsibility
Router E does not learn of any networks through Router B and does not use
Router B to reach any networks in AS 65101 or other autonomous systems
69
behind AS 65101.
IBGP update behavior in a fully meshed neighbor environment

BGP Update

When Router B receives an update from Router A

Router B updates all three of its IBGP peers, Router C, Router D, and
Router E.
OSPF, the IGP, is used to route the TCP segment containing the BGP
update from Router B to Router E, because these two routers are not
directly connected.
The update is sent once to each neighbor and not duplicated by any other
IBGP neighbor
Reduces unnecessary traffic.
In fully meshed IBGP, each router assumes that every other internal router
70
has a neighbor statement that points to each IBGP neighbor.
Routing Issues if BGP Not on in All Routers in a Transit Path
BGP Update

In this example, Routers A, B, E, and F are the only ones running BGP.
Router B has an:
EBGP neighbor statement for Router A
IBGP neighbor statement for Router E
Router E has an:
EBGP neighbor statement for Router F
IBGP neighbor statement for Router B.
Routers C and D are not running BGP.
71
Routers B, C, D and E are running OSPF as their IGP.
 BGP Update

Network
10.0.0.0

Network 10.0.0.0 is owned by AS 65101 and is advertised by Router A to

Router B via an EBGP session.
Router B advertises it to Router E via an IBGP session.
Routers C and D never learn about this network because:
BGP is not redistributed into the local routing protocol (OSPF)
Routers C and D are not running BGP
Router E advertises this network to Router F in AS 65103

72
 BGP Update

Packet to
Network
Network 10.0.0.0
10.0.0.0

No route to 10.0.0.0
Drop packet

So far
Routers A, B, E and E all know about the 10.0.0.0 network
Routers C and D do not have a route for the 10.0.0.0 network
If Router F has a packet for 10.0.0.0
Router F would forward the packet to Router E
Router E would send the packets to its BGP peer, Router B
To get to Router B packets must go through Router C or D
Neither of these routers have an entry in their routing tables for
network 10.0.0.0.
When this packet to 10.0.0.0 is forwarded to either Routers C or D,
those packets would be discarded. 73
 BGP Update
Transit Path

Packet to
Network
Network Transit Path 10.0.0.0
10.0.0.0
Default Route

Even if Routers C and D have a default route going to the exit points of the
AS (Routers B and E)
Those packet for 10.0.0.0 might go back to Router E causing a routing
loop.
To solve this problem:
BGP must be implemented on all routers in the transit path
Routers C and/or D
This leads us to the question Can BGP help ensure that all routers AS
65102 know about these external networks in other ASs?

74
 I learned about 172.16.0.0 via IBGP from
Router B. I will not advertise 172.16.0.0 to
BGP Synchronization Router E via EBGP unless I see this network
in my routing table leaned via an IGP (OSPF).
Note: There is not a physical
link b/t A and B

?
OSPF IBGP

AS 65000 networks
Into OSPF

BGP synchronization rule states: A BGP router should not use or advertise
to an external BGP neighbor a route learned by IBGP, unless that route is
directly connected or learned from the IGP.
In the past this use to be the default.
If there were small enough number of BGP routes they could be
redistributed into the IGP (by Router A and Router B).
Routers C and D would then know about 172.16.0.0 and all AS 65000
networks via redistribution by Router B.
Then IBGP would not have to run on all routers in the transit path.
75
 I learned about 172.16.0.0 via IBGP from
Router B. I will not advertise 172.16.0.0 to
BGP Synchronization Router E via EBGP unless I see this network
in my routing table leaned via an IGP (OSPF).

?
OSPF IBGP

AS 65000 networks
Into OSPF

It is important that Router C and Router D learn about the networks from AS
650000 (172.16.0.0).
Otherwise, when Router A forwards a packet to Router C destined for
172.16.0.0, Router C would drop the packet because that network is not in
its routing table.
This is why synchronization was the default on BGP routers.
However, in the modern Internet it not practical to redistribute so my
networks into the IGP this is no longer the best practice!

76
No BGP I learned about 172.16.0.0 via IBGP from
Router B. I can
will not
advertise
advertise
172.16.0.0
172.16.0.0
to to

Synchronization Router E via EBGP even

in myinrouting
NOT my routing
unlessif Ithis
table table
leaned
leaned
seenetwork
this network
via anvia
IGP
in
an(OSPF).
IGP
(OSPF).

?
OSPF IBGP

AS 65000 networks
Into OSPF

Best practice is to no longer redistribute BGP networks into the IGP.

Instead, all routers in the transit path should be fully meshed IBGP.
Synchronization is disabled by default in Cisco IOS 12.2(8)T and later.
This means that a BGP router can advertise to an external BGP neighbor a
route learned by IBGP regardless whether or not that network is in the
routing table via IGP.
All routers in the in the transit path must be running IBPG and be fully
meshed.
Each transit router in the AS must have a neighbor relationship with all
other transit routers. 77
No BGP I learned about 172.16.0.0 via IBGP from
Router B. I can advertise 172.16.0.0 to

Synchronization Router E via EBGP even if this network in

NOT in my routing table leaned via an IGP
(OSPF).

OSPF

The BGP synchronization rule does ensure consistency of information

throughout the AS and avoids black holes
For example, advertising a destination to an external neighbor when not all the
routers within the AS can reach the destination) within the autonomous
system.
So, when synchronization is disabled you must make sure that all routers in
the transit path are fully meshed via IBGP.
Otherwise, when Router A forwards a packet to Router C destined for 172.16.0.0,
Router C would drop the packet because that network is not in its routing table.
This allows the routers to carry fewer routes in IGP and allows BGP to converge
more quickly because it can advertise the routes as they are learned.
78
How does BGP choose the best path?
Is this the best path?
Does it meet the path
selection criteria? If so,
add to routing table.

BGP Update
BGP Routing
Table Table
Network Network

BGP selects only one path as the best path.

When the path is selected, BGP puts the selected path in its routing
table and propagates the path to its neighbors.
How does BGP choose the best path?

79
 WLam
Summary of the BGPWeight Path Selection Process
BGP uses the following Localcriteria, in the order presented, to select a path for a
Preference
destination:
NOTE: Not all of these as path
are commonly used and will be examined in more
detail later in this presentation
med and in the next presentation.

1. If the path specifies a next hop that is inaccessible, drop the update.
2. Prefer the path with the largest weight.
3. If the weights are the same, prefer the path with the largest local preference.
4. If the local preferences are the same, prefer the path that was originated by
BGP running on this router.
5. If no route was originated, prefer the route that has the shortest AS_path.
6. If all paths have the same AS_path length, prefer the path with the lowest
origin type (where IGP is lower than EGP, and EGP is lower than Incomplete).
7. If the origin codes are the same, prefer the path with the lowest MED
attribute.
8. If the paths have the same MED, prefer the external path over the internal
path.
9. If the paths are still the same, prefer the path through the closest IGP
neighbor.
10. Prefer the path with the lowest IP address, as specified by the BGP router ID
80
BGP Message Types

Before establishing a BGP peer connection the two neighbors must perform
the standard TCP three-way handshake and open a TCP connection to port
179.
After the TCP session is established, BGP peers exchanges several
messages to open and confirm connection parameters and to send BGP
routing information.
All BGP messages are unicast to the one neighbor over the TCP
connection.
There are four BGP message types:
Type 1: OPEN
Type 2: KEEPALIVE
Type 3: UPDATE
Type 4: NOTIFICATION

81
Type 1:
BGP Open Message

After the TCP session is established, both neighbors send Open messages.
This message is used to establish connections with peers.
Each neighbor uses this message to identify itself and to specify its BGP
operational parameters including:
BGP version number (defaults to version 4)
AS number: AS number of the originating router, determines if BGP
session is EBGP or IBGP.
BGP identifier: IP address that identifies the neighbor using the same
method as OSPF router ID.
Optional parameter: authentication, multiprotocol support and route
refresh.

82
Type 2: BGP Keepalive Message

This message type is sent periodically between peers to maintain

connections and verify paths held by the router sending the keepalive.
If a router accepts the parameters specified in its neighbors Open
message, it responds with a Keepalive.
Subsequent Keepalives are sent every 60 seconds
Holdtime: The maximum number of seconds that can elapse between
successive keepalives or update messages.
Cisco default holdtime is 180 seconds
Will use the smaller of the two neighbor holdtimes.
Router ID is includeds (determined same as OSPF or EIGRP Router ID)
83
Type 3: BGP Update Message

The UPDATE messages contain all the information BGP uses to construct a
loop-free picture of the internetwork.
Update messages advertises feasible routes, withdrawn routes, or both.
The three basic components of an UPDATE message are:
Network-Layer Reachability Information (NLRI)
Path Attributes
Withdrawn Routes

84
Type 3: BGP Update Message
Attributes Attributes Attributes

Path Networks Path Networks Path Networks

Update message includes Paths and associated Attributes and Networks

Path Attributes
This is described later, providing 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 destination that have become
unreachable and are being withdrawn from service.
Network-Layer Reachability Information (NLRI)
This is one or more networks (IP address prefix and prefix lengths) that can
be reached by this path.

85
Type 4: BGP Notification Message

A NOTIFICATION message is sent whenever an error is detected and

always causes the BGP connection to close.
The NOTIFICATION message is composed of the Error Code (8 bits), Error
Subcode (8 bits), and a Data fields (variable length).

86
BGP FSM

The BGP neighbor negotiation process proceeds through

various states, or stages, which can be described in terms of
a finite-state machine (FSM).

87
BGP FSM

BGP FSM includes six states:

1. Idle
2. Connect
3. Active
4. OpenSent
5. Open Confirm
6. Established
Note: Curved arrows should show
pointing back to the same state.

88
 This process can be viewed with:
debugipbgpipv4unicast
debugipbgpevents (older IOSs)

After you enter the neighbor command

BGP starts in the idle state, and the BGP process checks that it has a route to the IP
address listed.
BGP should be in the idle state for only a few seconds.
If BGP does not find a route to the neighboring IP address, it stays in the idle
state.
If it finds a route, it goes to the connect state when the TCP handshaking
synchronize acknowledge (SYN ACK) packet returns (when the TCP three-way
handshake is complete).
After the TCP connection is set up, the BGP process creates a BGP open
message and sends it to the neighbor.
After BGP dispatches this open message, the BGP peering session changes to the
open sent state.
If there is no response for 5 seconds, the state changes to the active state.
If a response does come back in a timely manner, BGP goes to the open confirm
state and starts scanning (evaluating) the routing table for the paths to send to the
neighbor.
When these paths have been found, BGP then goes to the established state and
89
begins routing between the neighbors.
 Idle State

BGP always begins in the Idle state, in which it refuses all incoming connections.
It is normally initiated by an administrator or a network event.
If BGP does not find a route to the neighboring IP address, it stays in the idle
state.
When Start event occurs, the BGP process:
Initializes all BGP resources
Starts the ConnectRetry timer
Initializes a TCP connection the the neighbor
Listens for a TCP initialization from the neighbor
Changes its state to Connect
90
Connect State

In this state, the BGP process is waiting for the TCP connection to be
completed.
If it finds a route, it goes to the connect state when the TCP handshaking
synchronize acknowledge (SYN ACK) packet returns (when the TCP three-
way handshake is complete).
If the connection is successful, the BGP process:
Clears the ConnectRetry timer
Completes initialization
Sends an Open message to the neighbor
Transitions to the OpenSent state 91
Connect State

If the connection is unsuccessful, the BGP process:

Continues to listen for a connection to be initiated by the
neighbor
Resets the ConnectRetry timer
Transitions to the Active state

92
Active State

In this state, the BGP process is trying to initiate a TCP connection with the
neighbor.
If the TCP connection is successful:
Clears the ConnectRetry timer
Completes initialization
Sends an Open message to the neighbor
Transitions to the OpenSent state

93
 Problem

Active State

If the ConnectRetry timer expires while BGP is in the Active State, the BGP
process:
Transitions back to the Connect state
Resets the ConnectRetry timer
In general, a neighbor state that is switching between "Connect" and
"Active" is an indication that something is wrong and that there are
problems with the TCP connection.
It could be because of many TCP retransmissions, or the incapability of a
neighbor to reach the IP address of its peer.

94
OpenSent State
errors

No errors

In this state an Open message has been sent and BGP is waiting to hear an Open
message from its neighbor.
After the TCP connection is set up, the BGP process creates a BGP open
message and sends it to the neighbor.
After BGP dispatches this open message, the BGP peering session changes to the
open sent state.
When an Open message is received, all its fields are checked.
If errors exist, a Notification message is sent and the state transitions to Idle.
If no errors exist, a Keepalive message is sent and the Keepalive timer is
set, the peer is determined to be internal or external, and state is changed to
OpenConfirm. 95
OpenConfirm
State
error

No errors

In this state, the BGP process waits for a Keepalive or Notification

message.
If a Keepalive message is received, the state transitions to
Established.
If a Notification message is received, or a TCP disconnect is
received, the state transitions to Idle.

96
Established
State

In this state, the BGP connection is fully established and the peers can
exchange Update, Keepalive and Notification messages.
If an Update or Keepalive message is received, the Hold timer is
restarted.
If a Notification message is received, the state transitions to Idle.

97
 CIS 185 CCNP ROUTE
Ch. 6 Border Gateway Protocol Solution
for ISP Connectivity Part 1
Rick Graziani
Cabrillo College
graziani@cabrillo.edu

Last Updated: Fall 2010