The Border Gateway Protocol and Classless Inter-Domain 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/feb1997/BGPTutorial/index.htm

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