Transcript Classless Inter-Domain Routing

The Border Gateway Protocol
and Classless Inter-Domain Routing
Allan Halme
Seminar on Telecommunications Technology
October 5, 1998
Classless Inter-Domain Routing
•
•
Running out of class B addresses (half allocated by 1992)
•
Solution:
Routing tables getting too big
•
•
•
Allocate consecutive class C addresses
Addresses are contiguous and share the same most significant bits
Routing protocols and routing tables need only refer to this “supernet” prefix

•
•
only one entry needed in routing protocols
Addresses are allocated by geographical region

network numbers within a region share the same prefix

can be referred to by a single entry in other regions’ routing tables

“routing table aggregation”
Enough addresses to 2000 (1995 estimate)
BGP.ppt / 5.10.1998 / AH page: 2
Regional Allocation
•
Continental division of class C addresses
•
•
•
•
•
•
•
Multi-regional
Europe
North America
Central/South America
Pacific Rim
Others
Allocation of addresses is delegated hierarchically to regional authorities
•
ie,

RIPE (Réseaux IP Européens) -- Europe

INRIA -- France
BGP.ppt / 5.10.1998 / AH page: 3
Address Assignments
Organization
•
•
•
•
•
•
•
Assignment
requires fewer than 256 addresses
1 class C network
requires fewer than 512 addresses
2 contiguous class C networks
requires fewer than 1024 addresses
4 contiguous class C networks
requires fewer than 2048 addresses
8 contiguous class C networks
requires fewer than 4096 addresses
16 contiguous class C networks
requires fewer than 8192 addresses
32 contiguous class C networks
requires fewer than 16384 addresses
64 contiguous class C networks
BGP.ppt / 5.10.1998 / AH page: 4
The Border Gateway Protocol
•
The BGP is an inter-autonomous system routing protocol designed for TCP/IP
systems; defined primarily in RFC 1771
•
•
•
Learns multiple paths via internal and external BGP speakers
•
Procedures in BGP
Picks the best path and installs in the IP forwarding table
Policies applied by influencing the best path selection
•
•
•
Neighbor acquisition -- initial connection and initialization
Neighbor reachability -- keeping track of the peer (keepalive)
Network reachability -- maintain list of reachable prefixes and routes to them; maintain
database by accepting updates from other BGP routers and forwarding updates onward
• The following BGP slides are based on Introduction to the Border Gateway Protocol (BGP) by Paul Ferguson,
http://www.academ.com/nanog/feb1997/BGPTutorial/index.htm
BGP.ppt / 5.10.1998 / AH page: 5
BGP Between AS’s
•
•
eBGP between AS’s
iBGP within single AS
BGP.ppt / 5.10.1998 / AH page: 6
Autonomous Systems
•
Defined in RFC 1930 “Guidelines for Creation,Selection, and Registration of an
Autonomous System (AS)” as
A connected group of one or more IP
prefixes run by one or more network
operators which has a single and
clearly defined routing policy.
•
In practice, this is not totally strict
•
ie, the case where an AS is transitioning from RIP to OSPF
AS A
AS X
AS Y
A
B
OSPF network
E
RIP network
BGP.ppt / 5.10.1998 / AH page: 7
C
D
AS Z
AS T
Path Vectors and Path Attributes
•
Uses path vectors to indicate routes to destination prefixes
•
•
•
•
•
•
Destination network is specified by subnet (“supernet”) prefix (à la CIDR)
Route is sequence of AS’s to be traversed to reach AS that contains destination network
Path vectors avoids routing loops
Consumes memory (each destination prefix needs own AS route list), but within reason if
CIDR is used
Attributes describe a particular route
Path attribute contains:
•
•
•
•
Attribute type code (AS path, next hop, etc)
Transitive / non-transitive (local)
Mandatory (well-known) / optional
Partially / fully evaluated by all routers in the AS path
BGP.ppt / 5.10.1998 / AH page: 8
Well-Known Attribute Types
•
•
•
•
•
AS path
Next hop
Local preference
Multi-exit discriminator (MED)
Others
•
•
•
Origin
Communities
...
BGP.ppt / 5.10.1998 / AH page: 9
AS Path
•
•
List of AS numbers to be traversed to reach destination prefix
Loop detection (potential loop if own AS occurs in imported route)
BGP.ppt / 5.10.1998 / AH page: 10
Next Hop / eBGP
•
•
IP address of next BGP router on the way to destination
Usually local net in eBGP
BGP.ppt / 5.10.1998 / AH page: 11
Next Hop / iBGP
•
Next hop of external routes not changed when announced to iBGP neighbors
BGP.ppt / 5.10.1998 / AH page: 12
Local Preference
•
•
•
Local to AS
Used to influence BGP path selection
Path with highest local preference wins
BGP.ppt / 5.10.1998 / AH page: 13
Multi-exit Discriminator (MED)
•
•
•
•
•
Non-transitive
Used to convey the relative preference of entry points
Influences best path selection
Comparable if paths are from same AS
IGP metric can be conveyed as MED
BGP.ppt / 5.10.1998 / AH page: 14
Internal BGP (iBGP)
•
•
Same routing protocol as BGP, different application
•
All iBGP peers must be fully meshed, logically; an iBGP peer will not advertise a
route learned by one iBGP peer to another iBGP peer (readvertisement restriction to
prevent looping)
iBGP should be used when AS_PATH information must remain intact between
multiple eBGP peers
BGP.ppt / 5.10.1998 / AH page: 15
Scaling iBGP (1)
•
BGP Confederations
•
Method to subdivide a single AS into multiple, internal sub-AS’s, yet still advertise a single
AS to external peers
•
Reduces iBGP mesh
BGP.ppt / 5.10.1998 / AH page: 16
Scaling iBGP (2)
•
BGP Route Reflectors (RR)
•
•
•
•
Another method to reduce iBGP mesh
iBGP re-advertisement restrictions are relaxed
Single iBGP peer advertises (reflects) routes to subordinate iBGP peers
Clients must not peer with RR’s outside of cluster
BGP.ppt / 5.10.1998 / AH page: 17
BGP Initialization
•
•
•
Open connection to peer router, TCP port 179
Each sends OPEN message to other
Possible errors include
•
•
•

send NOTIFICATION indicating supported versions and close TCP

peer will probably retry specifying lower version number
Collision

each peer tries to connect to the other, results in 2 TCP connections

one gets through first; the latter duplication is detected by noticing that the peer
is already listed in routing table
Authentication and sanity checks
•
•
•
•
•
Version is unsupported
Eg, peer is found in list of acceptable potential neighbors
Peer identifier is a valid address, length field checks out
Rejection indicated by NOTIFICATION message and closure of TCP
Connection is accepted by sending KEEPALIVE message
Routing tables are initialized by UPDATE messages
BGP.ppt / 5.10.1998 / AH page: 18
Updating
•
Once initial connection is established, route information is exchanged with UPDATE
messages
•
•
Send only as needed
KEEPALIVE responsible for monitoring neighbor reachability
•
•
All known paths sent, using as many UPDATE messages as needed
•
Upon receipt of new path information:
After initial exchange, new UPDATE messages are sent only when path information
changes or new path information is received
•
•
•
•
•
If path is new, add to table
If destination is unreachable, remove from table
If path already exists, old path is replaced only if new path is shorter
If update came from neighbor responsible for routing to path, update
Forward new information to all other external neighbors
BGP.ppt / 5.10.1998 / AH page: 19
Keepalive
•
•
Neighbor reachability / availability monitoring
•
Not sufficient to merely send keepalives to neighbor
•
•
BGP router expects also to receive keepalives from peer
UPDATE messages are triggered only as necessary
Hold time (negotiated at initialization) is the maximum delay during which BGP router
should expect keepalive from peer
•
If nothing heard, peer is assumed to be down

NOTIFICATION is sent to peer

TCP connection is closed
BGP.ppt / 5.10.1998 / AH page: 20
Error Notification
•
On receipt of faulty message or other error (ie, non-receipt of keepalive within hold
time),
•
•
•
NOTIFICATION message is sent to peer, and
TCP connection is closed gracefully
Errors
•
•
•
•
•
Message Header Error (code 1)
Unsupported Version Number (code 2, subcode 1)
Bad Peer AS / Bad BGP Identifier (code 2, subcodes 2 & 3)
Unsupported Authentication Code / Authentication Failure (code 2, subcodes 4 & 5)
UPDATE Message Error

•
•
Unrecognized Well-known Attribute, Attribute Flags Error, etc ...
Hold Timer Expired (code 4)
Finite-State Machine Error (code 5)

reception of unexpected message, ie UPDATE before OPEN has been accepted
BGP.ppt / 5.10.1998 / AH page: 21