The Border Gateway Protocol and Classless InterDomain Routing

1
The Border Gateway Protocoland Classless
Inter-Domain Routing

• Allan Halme
• Seminar on Telecommunications Technology
• October 5, 1998

2
Classless 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)

3
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

4
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

5
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
• 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/feb1
  997/BGPTutorial/index.htm

6
BGP Between ASs

• eBGP between ASs
• iBGP within single AS

7
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 X
AS Y
AS A
A
B
OSPF network
E
RIP network
C
D
AS Z
AS T
8
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 ASs 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

9
Well-Known Attribute Types

• AS path
• Next hop
• Local preference
• Multi-exit discriminator (MED)
• Others
• Origin
• Communities
• ...

10
AS Path

• List of AS numbers to be traversed to reach
  destination prefix
• Loop detection (potential loop if own AS occurs
  in imported route)

11
Next Hop / eBGP

• IP address of next BGP router on the way to
  destination
• Usually local net in eBGP

12
Next Hop / iBGP

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

13
Local Preference

• Local to AS
• Used to influence BGP path selection
• Path with highest local preference wins

14
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

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

16
Scaling iBGP (1)

• BGP Confederations
• Method to subdivide a single AS into multiple,
  internal sub-ASs, yet still advertise a single
  AS to external peers
• Reduces iBGP mesh

17
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 RRs outside of
  cluster

18
BGP 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

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

20
Keepalive

• 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

21
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