The Border Gateway ProtocolThe Border Gateway Protocoland Classless Inter-Domain Routingand Classless Inter-Domain Routing

Allan HalmeAllan Halme

Seminar on Telecommunications TechnologyOctober 5, 1998

BGP.ppt / 5.10.1998 / AH page: 2

Classless Inter-Domain RoutingClassless Inter-Domain Routing

• Running out of class B addresses (half allocated by 1992)

• Routing tables getting too big

• Solution:

• 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: 3

Regional AllocationRegional 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: 4

Address AssignmentsAddress 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: 5

The Border Gateway ProtocolThe 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

• Picks the best path and installs in the IP forwarding table

• Policies applied by influencing the best path selection

• Procedures in BGP

• 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: 6

BGP Between AS’sBGP Between AS’s

• eBGP between AS’s

• iBGP within single AS

BGP.ppt / 5.10.1998 / AH page: 7

• Defined in RFC 1930 “Guidelines for Creation,Selection, and Registration of an Autonomous System (AS)” as

Autonomous SystemsAutonomous Systems

OSPF network

RIP network

E

A

C D

B

AS X

AS Z AS T

AS Y

AS A

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

BGP.ppt / 5.10.1998 / AH page: 8

Path Vectors and Path AttributesPath 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: 9

Well-Known Attribute TypesWell-Known Attribute Types

• AS path

• Next hop

• Local preference

• Multi-exit discriminator (MED)

• Others

• Origin

• Communities

• ...

BGP.ppt / 5.10.1998 / AH page: 10

AS PathAS 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: 11

Next Hop / eBGPNext 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: 12

Next Hop / iBGPNext Hop / iBGP

• Next hop of external routes not changed when announced to iBGP neighbors

BGP.ppt / 5.10.1998 / AH page: 13

Local PreferenceLocal Preference

• Local to AS

• Used to influence BGP path selection

• Path with highest local preference wins

BGP.ppt / 5.10.1998 / AH page: 14

Multi-exit Discriminator (MED)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: 15

Internal BGP (iBGP)Internal BGP (iBGP)

• Same routing protocol as BGP, different application

• iBGP should be used when AS_PATH information must remain intact between multiple eBGP peers

• 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)

BGP.ppt / 5.10.1998 / AH page: 16

Scaling iBGP (1)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: 17

Scaling iBGP (2)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: 18

BGP InitializationBGP Initialization

• Open connection to peer router, TCP port 179

• Each sends OPEN message to other

• Possible errors include

• Version is unsupported 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

• 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: 19

UpdatingUpdating

• 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

• After initial exchange, new UPDATE messages are sent only when path information changes or new path information is received

• Upon receipt of new path information:

• 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: 20

KeepaliveKeepalive

• Neighbor reachability / availability monitoring

• UPDATE messages are triggered only as necessary

• Not sufficient to merely send keepalives to neighbor

• BGP router expects also to receive keepalives from peer

• 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: 21

Error NotificationError 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