Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

Routing TCP/IP Volume I (CCIE Professional Development)

Routing TCP/IP Volume I (CCIE Professional Development)

by Jeff Doyle

A detailed examination of interior routing protocols

  • Learn the IP interior routing protocols with this approachable, practical presentation
  • Explore configuration and troubleshooting of IP routing with Cisco routers through case studies
  • Test and validate your understanding with practical, comprehensive review questions, configuration


A detailed examination of interior routing protocols

  • Learn the IP interior routing protocols with this approachable, practical presentation
  • Explore configuration and troubleshooting of IP routing with Cisco routers through case studies
  • Test and validate your understanding with practical, comprehensive review questions, configuration exercises, and troubleshooting exercises
  • Further your CCIE preparation while mastering the essential TCP/IP protocols

CCIE Professional Development: Routing TCP/IP, Volume I, takes readers from a basic understanding of routers and routing protocols through a detailed examination of each of the IP interior routing protocols: RIP, RIP2, IGRP, EIGRP, OSPF, and IS-IS. In addition to specific protocols, important general topics such as redistribution, default routes and on-demand routing, route filtering, and route maps are covered. The book emphasizes techniques for designing networks that efficiently utilize and integrate the IP routing protocols. You will gain a deep understanding of IP routing protocols and learn best-practice techniques for implementing these protocols using Cisco(r) routers. As well, this book will help you master the skills necessary to become an effective Cisco Certified Internetwork Expert (CCIE).

Each protocol-specific chapter opens with thorough and lucid coverage of the protocol's capabilities and characteristics. Following sections contain configuration and troubleshooting case studies that cover Cisco-specific configuration of the protocol and all commands available for it on the most recent Cisco IOS(r) version. Finally, review questions and configuration and troubleshooting exercises on each protocol provide an opportunity to practice for the CCIE exam.

CCIE Program and Cisco Press(r)

The Cisco effort to facilitate the creation of competent network operations center (NOC) and information systems (IS) staff is exemplified in its Cisco Certified Internetwork Expert (CCIE) program. To support these efforts, Cisco Press is working closely with CCIE program management to create information products that help build the knowledge and expertise of NOC and IS professionals, as well as provide up-to-date, accurate information on technologies addressed in the CCIE program.

The CCIE Professional Development Series volumes are based on CCIE program guidelines from Cisco. This series is a set of technology-specific volumes designed to meet the needs of CCIE candidates.

Product Details

Cisco Press
Publication date:
CCIE Professional Development Series
Edition description:
Older Edition
Product dimensions:
7.54(w) x 9.44(h) x 2.57(d)

Read an Excerpt

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 information.

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....

Meet the Author

Jeff Doyle is a Senior Network Systems Consultant with International Network Services (INS) in Denver, Colorado. He is a Cisco Certified Internetwork Expert (CCIE #1919) and a Certified Cisco Systems Instructor. He has developed and taught a variety of networking and internetworking courses.

Customer Reviews

Average Review:

Post to your social network


Most Helpful Customer Reviews

See all customer reviews