INTER-DOMAIN ROUTING PROTOCOLS: EGP AND BGP. Abstract

Transcription

1 HELSINKI UNIVERSITY OF TECHNOLOGY Laboratory of Telecommunication Technology Licentiate course seminar, October 1996 Philippe Rua INTER-DOMAIN ROUTING PROTOCOLS: EGP AND BGP. Abstract This paper presents two Internet protocols used in inter-domain routing: the Exterior Gateway Protocol (EGP) and the Border Gateway Protocol (BGP). When it became necessary to split the Internet into several domains, a specific solution was also required in order to exchange global internet routing information between the domains. After introducing some concepts used in inter-domain routing, this paper gives an overview of the first inter-domain routing protocol to be used in the Internet, EGP, and explains its limitations. This paper then reviews BGP-3, a successor of EGP, and shows how the problems encountered with EGP were addressed. The new requirements imposed by the development of the Internet are also presented. Table of Contents 1. Introduction 1.1 The Initial Problem. 1.2 An Evolving Solution. 2. Some Concepts Used in Inter-Domain Routing 3. The Exterior Gateway Protocol (EGP) 3.1 EGP Overview. 3.2 Some Interesting Details. 3.3 The Limitations of EGP. 4. The Border Gateway Protocol (BGP-3) 4.1 Main Differences With EGP. 4.2 The BGP Messages. 4.3 The Path Attributes. 4.4 UPDATE Message Handling. 5. Conclusions Acronyms References 1

2 1. Introduction 1.1 The Initial Problem. In the early 1980s, the Internet was a single network domain to which hosts and networks were added in a relatively unstructured way. This growth required the addition of new routers (then called gateways) participating in the Gateway-to-Gateway Protocol, the routing protocol used at the time. Some problems became apparent: the overhead of the routing algorithm was becoming excessively large, not only because of the increased size of the routing table but also because of the additional traffic generated; the task of maintaining the routing system as whole was becoming almost impossible because it included many heterogeneous routers administered by different people. References: [1], [2], [3], [16] pp An Evolving Solution. As a consequence, the Internet Engineering Task Force (IETF) made the decision to split the Internet into separate domains, or autonomous systems in the EGP/BGP parlance, and to define a specific interface for the exchange of routing information between the domains: an inter-domain routing protocol. With this architecture, the choices made within one domain have less impact on the other domains. For example the different domains can freely use any interior" routing protocol (such as RIP or OSPF). Also, inside a domain, the internal routing protocol overhead generated by the handling of routes to networks in other domains can be reduced or even eliminated: some or all external route announcements can be filtered out at the domain border. The traffic to these destinations is then handled with the default route mechanism at the cost of a possible sub-optimal routing. The creation of a distinct protocol for inter-domain routing can be justified. Interior and exterior routing protocols have some very different constraints to address. An interior routing protocol is primarily concerned with routing efficiency whereas an exterior routing protocol has to provide mechanisms for controlling the sharing of resources, for fault isolation and for scaling. Over the years several inter-domain routing protocols have been proposed as Requests For Comments. (See Fig. 1.) This situation reflects the changing requirements linked to the development of the Internet year ¾ ¾ ¾ ¾ ¾ ¾ ¾ EGP(S) BGP-3(DS) BGP-4(DS) EGP(DS) BGP-2(PS) BGP-4(PS) BGP-1(E) Fig. 1: Main RFC publications for EGP and BGP. RFC status - E: Experimental, PS: Proposed Standard DS: Draft Standard, S: Standard The first of these protocols was EGP. Its successor, BGP, builds on the experience gained with EGP. BGP is currently used in the Internet, but it is not yet a "real" standard. It has been 2

3 recycled once, back to the "proposed standard" status. The reason of the delay between BGP- 3 and BGP-4 is the introduction of the Classless Inter-Domain Routing (CIDR), a consequence of the exponential growth of the Internet. The differences between the various versions of BGP are detailed in [13]. Another recent protocol, the Inter-Domain Policy Routing protocol (IDPR), is not described in this paper. References: [1], [3], [13], [17]. 2. Some Concepts Used in Inter-Domain Routing These concepts are common to EGP and BGP, the examples refer to Fig 2. An autonomous system (AS) is a set of routers and networks under the same administration, where all the elements are "internally connected". In other words, between any two elements of the AS there is a path using only elements of the AS. In EGP and BGP, each AS is identified by a 16-bit number. Inside an AS, the routing tables are maintained by one Internal Gateway Protocol (IGP), for example RIP or OSPF. The information about external networks is only acquired through the inter-domain routing protocol and injected into the IGP. Two routers are exterior neighbours if they each have an interface to a common network and they belong to different autonomous systems, e.g.; B and C, or A and F. They can also be connected by a point-to-point link. A router is a border router if it has at least an exterior neighbour, e.g.: A, B,,G. The inter-domain protocol runs on the border routers. Two routers are interior neighbours if they are border routers in the same autonomous system. They may be connected indirectly through several networks, e.g.: A and B. References: [1], [2], [16]. Fig. 2: Inter-Domain Routing Concepts. 3

4 3. The Exterior Gateway Protocol (EGP) EGP is the first Inter-Domain Routing protocol which has been used in Internet. It is to be noted that EGP is now considered as an "historic" standard, and therefore should not be used anymore. This paper therefore only presents an overview of EGP and explains its limitations. A detailed description can be found in the official documents defining the protocol [1], [2] and [4]. 3.1 EGP Overview. At the time the Internet was to be split into several autonomous systems, the "natural" division was a strict 2-level hierarchy, where one of the autonomous systems was much bigger than the others and played a special role. This "core" AS was made of the ARPANET and SATNET backbones. The others autonomous systems were "stub" regional networks only linked to the core. (See Fig. 3.) Fig. 3: The Internet topology according to EGP. In line with this situation, one basic assumption in EGP is that the ASs in the Internet would remain organised as a tree structure. As there are no cycles in this topology, the protocol has no provision to carry the information that would be needed to avoid routing loops. Another property of this topology is that there is only one route -- at the inter-domain level -- between any two ASs, hence there is no defined mechanism for the selection between multiple routes to the same destination. EGP external neighbours exchange network reachability information: which networks can be reached through each external neighbour. Reachable destinations are advertised inside the AS, using the IGP. There is no specific EGP-defined communication between internal neighbours. A first-hop address and an arbitrary metric called "distance" is also carried (0-255). Each AS can manipulate this metric freely: EGP only specifies that 255 represents an unreachable destination. This "distance" is mostly used to specify a local preference for some route. For example, if two ASs are directly connected by a main link and a backup link, the destinations can be advertised with a higher "distance" through the backup link, hence this link would be used only if the main link fails. The actual operation of EGP is composed of three separate procedures, the times indicated inside parenthesis are just typical values and are not part of the protocol: Neighbour acquisition - two external neighbours agree to exchange EGP information. This is a simple "two-way handshake". The potential neighbours are usually explicitly 4

5 configured for each border router. A neighbour can refuse to become an EGP partner or cease its co-operation. Neighbour reachability - once two external neighbours have agreed to become EGP partners they must check that the link is still operational, this is a periodic handshake (30 seconds). Network reachability - if the two external neighbours can reach each other, they periodically exchange their list of reachable networks. Each neighbour polls its partner to get a new list (2 minutes). The whole list must be sent each time. EGP runs directly over IP, all messages are carried inside IP datagrams. EGP therefore implements its own mechanism for reliability. For example all messages are sequenced. References: [1], [2], [15], [16]. 3.2 Some Interesting Details. As mentioned earlier, EGP does not pass sufficient routing information to prevent routing loops if cycles exist in the AS topology. The distance metrics of different ASs are quite independent and hence cannot be used to count to infinity like with standard distance vector protocols. Even if the metrics were made consistent, EGP propagates changes slowly. If a cycle is introduced, for example as a consequence of an administrative mistake, and a routing loop appears, the count to infinity required to break the routing loop could take up to eight hours [16] p.173. It is therefore important to keep a structure without cycles or at least to constrain the interdomain routing information to flow along a tree-structure. A "backdoor link", for example a direct link between A and B in Fig. 3, is a good illustration of the cost to be paid when using this work around. Such a link introduces a cycle in the information flow unless it is kept strictly private: the autonomous systems A and B must only advertise their own networks to the core. In practice, this means a lot of manual configuration and complicates noticeably the task of the network administrators. The IGP used in the autonomous system has an influence on the operation of EGP. For example RIP does not differentiate between internal and external distances and also increments the external distances with each internal hop. In the case of a backup link or a backdoor link, the distance advertised internally must therefore be chosen very carefully so that all internal nodes select the proper route. One convention was used to simplify this task for backup links: the border routers in the core were configured to always advertise a "distance" of 128 for reachable destinations. On the other hand, OSPF carries the reachability information advertised by border routers as external links. OSPF does not modify the metric and considers the external links to always have a larger metric than any internal route. It is therefore much easier to administer competing external links if OSPF is used. References: [1], [2], [16]. 3.3 The Limitations of EGP. EGP proved the usefulness of the concept of inter-domain routing protocol. However, it was designed for the Internet of the early 80's and some of its limitations made its replacement necessary: The periodic exchange of complete reachability information in one IP datagram, combined with the growing number of networks, means that beyond the maximum size 5

6 supported by the network (MTU), the message is always fragmented. The loss of a fragment then forces a complete retransmission, which is inefficient. A more serious consequence is that, in case of congestion, the failure to perform the exchange in time causes the routes to be dropped. EGP does not provide any protection if a router misbehaves, the warning given in [1] is very explicit: "If any gateway sends a network reachability message with false information, claiming to be an appropriate first hop to a network which it in fact cannot even reach, traffic destined to that network may never be delivered." Because its basic design assumes a tree-like topology, EGP does not support the meshed architecture topology required in Internet today, where multiple commercial backbones are competing. It is to be noted that, despite these limitations, EGP is still in use today. For example, a stub AS with only one link to the rest of the Internet can very well use EGP for its inter-domain protocol, as long as the backbone provides an EGP peer. References: [1], [5], [6], [7], [16]. 4. The Border Gateway Protocol (BGP-3) BGP is the successor of EGP. This paper only reviews BGP-3. The additions brought by the latest design iteration, BGP-4, are best explained when presenting CIDR and therefore are not detailed here. (See [13], [14], [16].) The official documents defining BGP-3 are [10], and [11]. 4.1 Main Differences With EGP. The BGP characteristics briefly presented here collectively address most of the limitations of EGP. The Internet topology model used by BGP is a general graph whose nodes are ASs and whose edges are connections between pairs of ASs. In order to avoid routing loops in a meshed topology, the designers of BGP invented a new technology: the path vector. The principle is simple, with each advertised destination, BGP maintains a complete list of transit autonomous systems. When a border router receives a route advertisement it will refuse to use that route if its own AS is in the list. BGP runs on the top of TCP and therefore can assume a reliable message transfer. This greatly simplifies the protocol as there is no need for complex error recovery mechanisms. This choice also decreases indirectly the volume of data which is exchanged between routers: because messages are delivered reliably, BGP uses incremental updates of routing information. A consequence is that each BGP router memorises the information provided by its partners. BGP specifies a direct transfer of information between interior neighbours. The transfer is performed over internal BGP connections, independently of any constraints imposed by the interior routing protocol. It is to be noted that, although BGP defines new security and authentication mechanisms, it does not seem to offer any additional protection if a router misbehaves. 6

7 The comparison of the two protocols in the field have shown that BGP is clearly superior to EGP in terms of CPU and bandwidth requirements [9]. On the other hand, [8] evaluates the extra memory requirements for BGP to less than 7 percent. References: [8], [9], [10], [11], [15], [16]. 4.2 The BGP Messages. The operation of BGP is divided along the same general lines as EGP. The procedures are presented under the corresponding message name. All the BGP messages use the same fixed-length header (19 bytes). This header carries the type (1-4, 1 byte) and the total length ( , 2 bytes) of the message. The length is used for message delineation because a TCP connection is a byte stream service. The header starts with a 16 byte marker field as a redundant protection against message misalignment. 1. OPEN (cf. Neighbour acquisition) - two external or internal neighbours agree to exchange BGP information. The potential BGP partners are usually explicitly configured for each border router. After the opening a TCP connection towards the port 179 on a potential partner, each side sends an OPEN message. The neighbour accepts the association with a KEEPALIVE message. A neighbour can refuse to become a BGP partner or cease its co-operation with a NOTIFICATION message. The fields of the OPEN message are: - the BGP version (1 byte): the version must be identical in both OPEN messages; - the AS number of the sender (2 bytes); - the hold time in seconds (2 bytes): the sender specifies how long its partner should wait between messages, before deciding that the connection is lost; - the BGP identifier (4 bytes) which is usually one of the IP interface address of the router. The same identifier is used by one router for all its BGP associations; - the authentication code (1 byte) and some variable length authentication data. The code specifies the format of the data and also the content of the marker field which will be used in the header of the next messages. The only code specified in [10] is 0: no data and a marker set to all 1s. 2. UPDATE (cf. Network reachability) - once the two neighbours are BGP partners, they exchange update messages which contain: - a list of path attributes for one AS path, the attributes are coded in the type, length, value format, the AS path itself is in one attribute, see the next section for more details; - a list of networks which can be reached through this path, each IP network number is on 4 bytes, padded with 3, 2 or 1 null bytes depending on the network class. After an initial phase where all the routing information is exchanged, BGP only transmits messages carrying the incremental changes in routing information. 3. NOTIFICATION - this message is used to convey error notifications or a normal cease notification. It includes an error code (1 byte), sub-code (1 byte) and variable length data. 4. KEEPALIVE (cf. Neighbour reachability) - once two external neighbours have agreed to become BGP partners they must check that the link is still operational. This message is sent if no UPDATE message has been sent during a given time. Usually this time is set to one third of the hold time specified in the OPEN message (resulting in a typical periodicity of 2 minutes). This message is made of a simple header. 7

8 Some sanity checks are performed on the header of all messages, the marker field itself must comply with the security algorithm specified in the OPEN message, if an error is detected, a NOTIFICATION is sent and the TCP connection is closed. It is interesting to note that, if the Internet is stable, the steady state traffic generated by BGP is only made of the periodic KEEPALIVE messages. This is a tiny 5 bit/sec bandwidth for each BGP connection (one way). References: [8], [10], [11], [16]. 4.3 The Path Attributes. Beside the list of reachable networks, the routing information is carried by BGP in the path attributes of the UPDATE message. Some binary flags are specified for each path attribute: well-known or optional: well-known attributes are understood by all BGP-3 routers, they are essential for the operation of the protocol. transitive or local: an optional attribute is passed on to the next AS only if it is transitive, note: a well-known attribute is marked as transitive in any case; complete or partial: an attribute is complete if it has been seen and handled by all the AS on the path. The well-known BGP-3 attributes are listed below: AS path: the list of transit AS; origin: the source of the information in the original AS, either IGP, EGP or incomplete (any other source); next hop: the IP address of the next router to the destination, it may be different from the sender of the message (local attribute); unreachable mark: this is used to inform that a previously advertised path is no longer available; BGP-3 also defines a local optional attribute: inter-as metric: when two ASs have several common connections this attribute is used locally to specify a preferred connection, this is the path with the lowest metric. References: [10], [16]. 4.4 UPDATE Message Handling. In this section we use the following definition of a route selection operation: a BGP router compares all the routes received from external and internal BGP peers. The algorithm used to choose the better route is freely defined inside the AS and can use the information provided in the path attributes. There are many possibilities such as counting the number of transit ASs or assigning weights to different ASs. All the BGP routers in one AS must use the same algorithm. The general principle behind the route selection mechanism is that, for each destination, each border router gets to know the best external route of each of its internal peers. The -- same 8

9 AS-level best path to a destination is therefore determined by a route selection operation at each border router of the AS. Whenever a new route is selected or a reachable destination inside the AS has changed, an UPDATE message is sent to each external peer, the local AS number is prepended to the AS path attribute. Note: the router which is the best exit point for a new route injects the route information into the IGP. The use of direct connections to propagate inter-domain routing information to internal BGP neighbours actually creates a synchronisation problem with the IGP: a route should not be advertised to external neighbours before it is properly established within the AS itself. The UPDATE handling mechanism is know described with more details. Please note that, for the sake of clarity, the explanations are given for an update concerning only one network. In practice, several networks may be listed in the message. When an UPDATE message is received, it is validated. The attributes are processed and checked. This include the detection of the AS s own AS number in the AS path attribute, if this is the case, the route is never selected as this would result in a routing loop. The actual handling of an UPDATE message is different whether it was received over an external or an internal BGP connection. Update received from an external neighbour. New route: for the network listed in the update message, the new route is compared with the routes received previously from other external neighbours. If the best external route has changed, it is advertised to the internal neighbours after a hold down time, a route selection operation is also performed at that time. Unreachable route: if this route was the currently selected route to the destination, the update is immediately propagated to all the internal neighbours. This is followed by a route selection operation. Update received from an internal neighbour. A route selection operation is performed. If a new route is selected, or a destination becomes unreachable, this is immediately advertised to the external neighbours. If the internal neighbours are linked by full-mesh BGP connections, as recommended in [10], then the update is not propagated to internal neighbours. References: [10], [12], [16]. 9

10 5. Conclusions The main initial requirements for an inter-domain routing protocol were: provide a means for different domains to exchange information about the networks that are reachable via them; let the domains run different intra-domain routing protocols; avoid routing loops between domains. These requirements were met by EGP in the context of the 1980 Internet and its tree-structure topology, but the Internet was growing and additional requirements soon appeared: support the initial requirements in a meshed topology; scale to a large number of networks; support policy routing. The three first versions of BGP were designed to address these new requirements. The introduction of the path vector technology and the use of incremental updates were two key factors for their success. The Internet did not stop growing, this created some strains on the management of network IP addresses. The resulting new requirements for an inter-domain routing protocol is to support route aggregation and the IP addressing scheme introduced by the Classless Inter-Domain Routing (CIDR). BGP-3 is therefore already obsolete and is being replaced by BGP-4. One can also foresee the need for the support of different types of services (for example low delay variation) and multiple paths to one destination. AS BGP EGP IETF IGP IP MTU OSPF RIP TCP Acronyms Autonomous System Border Gateway Protocol Exterior Gateway Protocol Internet Engineering Task Force Internal Gateway Protocol Internet Protocol Media Transmission Unit Open Shortest Path First Routing Information Protocol Transfer Control Protocol 10

11 References Note about the Requests For Comments (RFC): these documents can be retrieved from or ftp://ds.internic.net/rfc. The abbreviation immediately following the RFC number is the RFC status as at 29 September S: Standards, DS: Draft Standards, PS: Proposed Standards, E: Experimental, I: Informational, H: Historic. See [17] for more details. NOTICE: The RFC publication date is in American format (mm/dd/yyyy). EGP [1] RFC0827, E. Rosen, "Exterior Gateway Protocol EGP", 10/01/1982. (Updated by RFC0904) [2] RFC0888, L. Seamonson, E. Rosen, ""STUB" Exterior Gateway Protocol", 01/01/1984. [3] RFC0890, J. Postel, "Exterior Gateway Protocol implementation schedule", 02/01/1984. [4] RFC0904 H, International Telegraph and Telephone Co, D. Mills, "Exterior Gateway Protocol formal specification", 04/01/1984. (Updates RFC0827) (STD 18) [5] RFC0911, P. Kirton, "EGP Gateway under Berkeley UNIX 4.2", 08/22/1984. [6] RFC1092, J. Rekhter, "EGP and policy based routing in the new NSFNET backbone", 02/01/1989. [7] RFC1093, H. Braun, "NSFNET routing architecture", 02/01/1989. BGP [8] RFC1265 I, Y. Rekhter, "BGP Protocol Analysis", 10/28/1991. [9] RFC1266 I, Y. Rekhter, "Experience with the BGP Protocol", 10/28/1991. [10] RFC1267 DS, K. Lougheed, Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)", 10/25/1991. (Obsoletes RFC1163) [11] RFC1268 DS, P. Gross, Y. Rekhter, "Application of the Border Gateway Protocol in the Internet", 10/25/1991. (Obsoletes RFC1164) (Obsoleted by RFC1655) [12] RFC1403 PS, K. Varadhan, "BGP OSPF Interaction", 01/14/1993. (Obsoletes RFC1364) [13] RFC1771 DS, Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", 03/21/1995. (Obsoletes RFC1654) [14] RFC1772 DS, Y. Rekhter, P. Gross, "Application of the Border Gateway Protocol in the Internet", 03/21/1995. (Obsoletes RFC1655) General [15] Martha Steenstrup, Routing in communications networks, Prentice Hall, [16] Christian Huitema, Routing in the Internet, Prentice Hall, [17] RFC1920 S, J. Postel, "INTERNET OFFICIAL PROTOCOL STANDARDS", 03/22/1996. (Obsoletes RFC1880) (STD 1) 11