Routing TCP/IP, Volume II (CCIE Professional Development)

by Jeff Doyle, Jennifer Carroll

Overview

A detailed examination of exterior routing protocols and advanced IP routing issues

 

Routing TCP/IP, Volume II, enables you to:

• Master the operational components, configuration, and troubleshooting of BGP-4-the de facto interdomain routing protocol
• Understand the operation, configuration, and troubleshooting of NAT
• Learn how to deploy, configure, and troubleshoot IP multicast routing through an array of case studies and exercises
• Familiarize yourself with the design goals and current state of IPv6, the new generation of the IP protocol
• Implement router management through a diverse range of expert-tested methods
• Test and validate your knowledge with practical, comprehensive review questions, configuration exercises, and troubleshooting exercises
• Further your CCIE preparation while mastering advanced TCP/IP concepts

The complexities of exterior gateway protocols, including TCP connections, message states, path attributes, interior routing protocol interoperation, and setting up neighbor connections, require a comprehensive understanding of router operations in order to manage network growth. Routing TCP/IP, Volume II, provides you with the expertise necessary to understand and implement Border Gateway Protocol Version 4 (BGP-4), multicast routing, Network Address Translation (NAT), IPv6, and effective router management techniques. Jeff Doyle's practical approach, easy-to-read format, and comprehensive topic coverage make this book an instant classic and a must-have addition to any network professional's library.

Routing TCP/IP, Volume II, expands upon the central theme of Volume I: scalability and management of network growth. Volume II moves beyond the interior gateway protocols covered in Volume I to examine both inter-autonomous system routing and more exotic routing issues such as multicasting and IPv6. This second volume follows the same informational structure used effectively in Volume I: discussing the topic fundamentals, following up with a series of configuration examples designed to show the concept in a real-world environment, and relying on tested troubleshooting measures to resolve any problems that might arise. This book helps you accomplish more than earning the highly valued CCIE number after your name; it also helps you develop the knowledge and skills that are essential to perform your job at an expert level. Whether you are pursuing CCIE certification, need to review for your CCIE recertification exam, or are just looking for expert-level advice on advanced routing issues, Routing TCP/IP, Volume II, helps you understand foundation concepts and apply best practice techniques for effective network growth and management.

Product Details

ISBN-13:	9780133116045
Publisher:	Pearson Education
Publication date:	04/23/2001
Series:	CCIE Professional Development
Sold by:	Barnes & Noble
Format:	eBook
Pages:	976
File size:	45 MB
Note:	This product may take a few minutes to download.

About the Author

Jeff Doyle, CCIE No. 1919, is a professional services consultant with Juniper Networks, Inc., in Denver, Colorado. Specializing in IP routing protocols and MPLS traffic engineering, Jeff has helped design and implement large-scale Internet service provider networks throughout North America, Europe, and Asia.

Jennifer DeHaven Carroll, CCIE No. 1402, is a principal consultant with Lucent Technologies. She has planned, designed, and implemented many large networks over the past 13 years as well as developed and taught classes on theory and Cisco implementation of all IP routing protocols.

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 8271¹, 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.

NOTE

---

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 888², and the formal specification of EGPv2 is given in RFC 904³.

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

Table of Contents

I. EXTERIOR GATEWAY PROTOCOLS.

 1. Exterior Gateway Protocol.
 2. Introduction to BGP-4.
 3. BGP Configuration and Troubleshooting.

II. ADVANCED IP ROUTING ISSUES.

 4. Network Address Translation.
 5. Introduction to Multicast Routing.
 6. Configuration and Troubleshooting for Multicast Routing.
 7. Large-Scale Multicast Routing.
 8. IPv6.
 9. Router Management.
Appendix A: Field Details for the, 'show ip bgp neighbor' Output.
Appendix B: A Regular Expression Tutorial.
Appendix C: Answers to Review Questions.
Appendix D: Answers to Configuration Exercises.
Answers to Troubleshooting Exercises.

Introduction

Since the publication of Volume I of Routing TCP/IP, many volumes have been added to the Cisco Press CCIE Professional Development series. And the CCIE program itself has expanded to include various areas of specialization. Yet the IP routing protocols remain the essential foundation on which the CCIE candidate must build his or her expertise. If the foundation is weak, the house will tumble.

I stated in the introduction to Volume I that "...as internetworks grow in size and complexity, routing issues can become at once both large and subtle." Scalability and management of growth continues to be a central theme in this second volume, as we move beyond the interior gateway protocols to examine both interautonomous system routing and more exotic routing issues such as multicasting and IPv6.

My objective in this book is not only to help you walk away from the CCIE tab exam with one of those valued and valuable numbers after your name, but also to help you develop the knowledge and skills to live up to the CCIE title. As with the first volume, I want to make CCIEs, not people who can pass the ME lab. In this vein, you will find in this book more information than you will need to pass the lab, but certainly all of the material is important in your career as a recognized internetworking expert.

When I earned my CCIE, the lab still consisted mostly of AGS+ routers. Certainly the lab and the nature of the exam have changed substantially since that ancient time. If anything, the lab is more difficult now. Another addition to the CCIE program has been the recertification requirement. Even before I took the recertification exam for the first time, people were telling me how much Volume I had helped them prepare for the test-particularly for IS-IS, a protocol that few outside of service provider environments are exposed to. I have therefore written this second volume with not only CCIE candidates in mind, but also existing CCIEs who need to review for their recertification. The chapters on multicasting and IPv6 are directed to this audience.

I have endeavored to follow the same structure that I followed in Volume 1, in which a protocol is introduced in generic terms, followed by examples of configuring the protocol using Cisco IOS Software, and finally by examples of Cisco IOS Software tools for troubleshooting the protocol. In the case of BGP and IP multicast, this structure is far too lengthy for a single chapter and therefore spans multiple chapters.

I hope you learn as much from reading this book as I have from writing it.