Textbook Notes (280,000)
CA (170,000)
U of A (2,000)
ECE (30)
ECE495 (20)
mint (20)
Chapter 3

ECE495 Chapter Notes - Chapter 3: Border Gateway Protocol, Routing Protocol, Routing Table


Department
Electrical and Computer Engineering
Course Code
ECE495
Professor
mint
Chapter
3

This preview shows pages 1-3. to view the full 30 pages of the document.
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by
Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
1
- Border Gateway Protocol -
Border Gateway Protocol (BGP)
BGP is a standardized exterior gateway protocol (EGP), as opposed to RIP,
OSPF, and EIGRP which are interior gateway protocols (IGP’s). BGP
Version 4 (BGPv4) is the current standard deployment.
BGP is considered a “Path Vector” routing protocol. BGP was not built to
route within an Autonomous System (AS), but rather to route between AS’s.
BGP maintains a separate routing table based on shortest AS Path and
various other attributes, as opposed to IGP metrics like distance or cost.
BGP is the routing protocol of choice on the Internet. Essentially, the
Internet is a collection of interconnected Autonomous Systems.
BGP Autonomous Systems are assigned an Autonomous System Number
(ASN), which is a 16-bit number ranging from 1 – 65535. A specific subset
of this range, 64512 – 65535, has been reserved for private (or internal) use.
BGP utilizes TCP for reliable transfer of its packets, on port 179.
When to Use BGP
Contrary to popular opinion, BGP is not a necessity when multiple
connections to the Internet are required. Fault tolerance or redundancy of
outbound traffic can easily be handled by an IGP, such as OSPF or EIGRP.
BGP is also completely unnecessary if there is only one connection to an
external AS (such as the Internet). There are over 100,000 routes on the
Internet, and interior routers should not be needlessly burdened.
BGP should be used under the following circumstances:
Multiple connections exist to external AS’s (such as the Internet) via
different providers.
Multiple connections exist to external AS’s through the same
provider, but connect via a separate CO or routing policy.
The existing routing equipment can handle the additional demands.
BGP’s true benefit is in controlling how traffic enters the local AS, rather
than how traffic exits it.

Only pages 1-3 are available for preview. Some parts have been intentionally blurred.

BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by
Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
2
BGP Peers (Neighbors)
For BGP to function, BGP routers (called speakers) must form neighbor
relationships (called peers).
There are two types of BGP neighbor relationships:
iBGP Peers – BGP neighbors within the same autonomous system.
eBGP Peers – BGP neighbors connecting separate autonomous
systems.
Note: Do not confuse an IGP, such as OSPF, with iBGP!
In the above figure, RouterB and RouterC in AS 200 would form an iBGP
peer relationship. RouterA in AS 100 and RouterB in AS 200 would form an
eBGP peering.
Once BGP peers form a neighbor relationship, they share their full routing
table. Afterwards, only changes to the routing table are forwarded to peers.
By default, BGP assumes that eBGP peers are a maximum of one hop away.
This restriction can be bypassed using the ebgp-multihop option with the
neighbor command (demonstrated later in this guide).
iBGP peers do not have a hop restriction, and are dependent on the
underlying IGP of the AS to connect peers together. By default, all iBGP
peers must be fully meshed within the Autonomous System.
A Cisco router running BGP can belong to only one AS. The IOS will only
allow one BGP process to run on a router.
The Administrative Distance for routes learned outside the Autonomous
System (eBGP routes) is 20, while the AD for iBGP and locally-originated
routes is 200.

Only pages 1-3 are available for preview. Some parts have been intentionally blurred.

BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by
Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
3
BGP Peers Messages
BGP forms its peer relationships through a series of messages. First, an
OPEN message is sent between peers to initiate the session. The OPEN
message contains several parameters:
BGP Version – must be the same between BGP peers
Local AS Number
BGP Router ID
KEEPALIVE messages are sent periodically (every 60 seconds by default)
to ensure that the remote peer is still available. If a router does not receive a
KEEPALIVE from a peer for a Hold-time period (by default, 180 seconds),
the router declares that peer dead.
UPDATE messages are used to exchange routes between peers.
Finally, NOTIFICATION messages are sent when there is a fatal error
condition. If a NOTIFICATION message is sent, the BGP peer session is
torn down and reset.
As a BGP peer session is forming, it will pass through several states. This
process is known as the BGP Finite-State Machine (FSM):
Idle – the initial BGP state
Connect - BGP waits for a TCP connection with the remote peer. If
successful, an OPEN message is sent. If unsuccessful, the session is
placed in an Active state.
Active – BGP attempts to initiate a TCP connection with the remote
peer. If successful, an OPEN message is sent. If unsuccessful, BGP
will wait for a ConnectRetry timer to expire, and place the session
back in a Connect State.
OpenSent – BGP has both established the TCP connection and sent
an OPEN Message, and is awaiting a reply OPEN Message. Once it
receives a reply OPEN Message, the BGP peer will send a
KEEPALIVE message.
OpenConfirm – BGP listens for a reply KEEPALIVE message.
Established – the BGP peer session is fully established. UPDATE
messages containing routing information will now be sent.
If a peer session is stuck in an Active state, potential problems can include:
no IP connectivity (no route to host), an incorrect neighbor statement, or an
access-list filtering TCP port 179.
You're Reading a Preview

Unlock to view full version