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