1. The Border Gateway Protocol and 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 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 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,

6. BGP Between AS’s
eBGP between AS’s
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 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

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-AS’s, 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 RR’s 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