Chapter 1: Exterior Gateway Protocol
This chapter covers the following key topics:
- The Origins of EGP -- This section discusses the history of the development of the Exterior Gateway Protocol, presented in RFC 827 (1982).
- Operation of EGP -- This section explores the fundamental mechanics of EGP with a focus on EGP topology issues, EGP functions, and EGP message formats.
- Shortcomings of EGP --This section explores some of the reasons why EGP is no longer pursued as a viable external gateway protocol solution.
- Configuring EGP -- This section presents four separate case studies-EGP stub gateway, EGP core gateway, indirect neighbors, and default routes-to demonstrate different types of EGP configuration.
- Troubleshooting EGP -- This section examines how to interpret an EGP neighbor table and presents a case study on the slow convergence speed of an EGP network to show why EGP is no longer a popular option.
The first question knowledgeable readers will (and should) ask is "Why kill a few trees publishing a chapter about an obsolete protocol such as the Exterior Gateway Protocol (EGP)?" After all, EGP has been almost universally replaced by the Border Gateway Protocol (BGP). This question has two answers.
First, although EGP is rarely used these days, it is still occasionally encountered. As of this writing, for instance, you can still find EGP in a few U.S. military internetworks. As a CCIE, you should understand EGP for such rare encounters.
Second, this chapter serves as something of a history lesson. Examining the motives for developing an external gateway protocol and the shortcomings of the original external protocol provides a prologue for the following two chapters. BGP will make more sense to you if you are familiar with the roots from which it evolved.
The Origins of EGP
In the early 1980s, the routers (gateways) that made up the ARPANET (predecessor of the modern Internet) ran a distance vector routing protocol known as the Gateway-to-Gateway Protocol
(GGP). Every gateway knew a route to every reachable network, at a distance measured in gateway hops. As the ARPANET grew, its architects foresaw the same problem that administrators of many growing internetworks encounter today: Their routing protocol did not scale well.
Eric Rosen, in RFC 82711, chronicles the scalability problems:
- With all gateways knowing all routes, "the overhead of the routing algorithm becomes excessively large." Whenever a topology change occurs, the likelihood of which increases with the size of the internetwork, all gateways have to exchange routing information and recalculate their tables. Even when the internetwork is in a steady state, the size of the routing tables and routing updates becomes an increasing burden.
- As the number of GGP software implementations increases, and the hardware platforms on which they are implemented become more diverse, "it becomes impossible to regard the Internet as an integrated communications system." Specifically, maintenance and troubleshooting become "nearly impossible."
- As the number of gateways grows, so does the number of gateway administrators. As a result, resistance to software upgrades increases: "[A]ny proposed change must be made in too many different places by too many different people."
The solution proposed in RFC 827 was that the ARPANET be migrated from a single internetwork to a system of interconnected, autonomously controlled internetworks. Within each internetwork, known as an autonomous system (AS), the administrative authority for that AS is free to manage the internetwork as it chooses. In effect, the concept of autonomous systems broadens the scope of internetworking and adds a new layer of hierarchy. Where there was a single internetwork-a network of networks-there is now a network of autonomous systems, each of which is itself an internetwork. And just as a network is identified by an IP address, an AS is identified by an autonomous system number. An AS number is a 16bit number assigned by the same addressing authority that assigns IP addresses.
Also like IP addresses, some AS numbers are reserved for private use. These numbers range
from 64512 to 65535. See RFC 1930 (www.isi.edu/in-notes/rfcl930.txt) for more
Chief among the choices the administrative authority of each AS is free to make is the
routing protocol that its gateways run. Because the gateways are interior to the AS,
their routing protocols are known as interior gateway protocols (IGPs). Because GGP was
the routing protocol of the ARPANET, it became by default the first IGP. However, interest
in the more modern (and simpler) Routing Information Protocol (RIP) was building in
1982, and it was expected that this and other as-yet-unplanned protocols would be used in
many autonomous systems. These days, GGP has been completely replaced by RIP, RIP-2,
Interior Gateway Routing Protocol (IGRP), Enhanced IGRP (EIGRP), Open Shortest Path
First (OSPF), and Integrated Intermediate System-to-Intermediate System (IS-IS).
Each AS is connected to other autonomous systems via one or more exterior gateways.
RFC 827 proposed that the exterior gateways share routing information between each other
by means of a protocol known as the EGP. Contrary to popular belief, although EGP is a
distance vector protocol, it is not a routing protocol. It has no algorithm for choosing an
optimal path between networks; rather, it is a common language that exterior gateways use
to exchange reachability information with other exterior gateways. That reachability
information is a simple list of major network addresses (no subnets) and the gateways by
which they can be reached.
Operation of EGP
Version 1 of EGP was proposed in RFC 827. Version 2, slightly modified from version 1, was proposed in RFC 8882
, and the formal specification of EGPv2 is given in RFC 9043
EGP Topology Issues
EGP messages are exchanged between EGP neighbors, or peers
. If the neighbors are in the same AS, they are interior neighbors
. If they are in different autonomous systems, they are exterior neighbors
. EGP has no function that automatically discovers its neighbors: the addresses of the neighbors are manually configured, and the messages they exchange are unicast to the configured addresses.
RFC 888 suggests that the time-to-live (TTL) of EGP messages be set to a low number, because an EGP message should never travel farther than to a single neighbor. However, nothing in the EGP functionality requires EGP neighbors to share a common data link. For example, Figure 1-1 shows two EGP neighbors separated by a router that speaks only RIP. Because EGP messages are unicast to neighbors, they can cross router boundaries. Therefore, Cisco routers set the TTL of EGP packets to 255.
Figure 1-1 EGP Neighbors Do Not Have to Be Connected to the Sane Network...
...EGP gateways are either core gateways or stub gateways. Both gateway types can accept information about networks in other autonomous systems, but a stub gateway can send only information about networks in its own AS. Only core gateways can send information they have learned about networks in autonomous systems other than their own.
To understand why EGP defines core and stub gateways. it is necessary to understand the architectural limitations of EGP. As previously mentioned, EGP is not a routing protocol. Its updates list only reachable networks, without including enough information to determine shortest paths or to prevent routing loops. Therefore, the EGP topology must be built with no loops.
Figure 1-2 shows an EGP topology. There is a single core AS to which all other autonomous systems (stub autonomous systems) must attach. This two-level tree topology is very similar to the two-level topology requirements of OSPF, and its purpose is the same. Recall from Routing TCP/IP, Volume I that interarea OSPF routing is essentially distance vector, and therefore vulnerable to routing loops. Requiring all traffic between nonbackbone OSPF areas to traverse the backbone area reduces the potential for routing loops by forcing a loopfree interarea topology. Likewise, requiring all EGP reachability information between stub autonomous systems to traverse the core AS reduces the potential for routing loops in the EGP topology....