vill Contents at a Glance Part | Exterior Gateway Protocols Chapter 1 Exterior Gateway Protocol Chapter 2 Introduction to Border Gateway Protocol 4 Chapter'3 Configuring and Troubleshooting Border Gateway Protocol 4 Part ll Advanced IP Routing Issues Chapter 4 Network Address Translation Chapter 5 Introduction o IP Multicast Routing Chapter 6 Configuring and Troubleshooting IP Multicast Routing Chapter7 Large-Scale IP Multicast Routing Chapter 8 IP Version 6 Chapter 9 Router Management Part Ill Appendixes Appendix A The show ip bgp neighbors Display Appendix B A Regular-Expression Tutorial Appendix C Reserved Multicast Addresses Appendix D Answers to Review Questions ‘Appendix E Answers to Configuration Exercises Appendix F Answers to Troubleshooting Exercises IndexTable of Contents Introduction xxii Teons Used in This Book xxiii ‘Command Syntax Conventions xxiv Part | Exterior Gateway Protocols 3 Chapter 1 Exterior Gateway Protocol 5 ‘The Origins of EGP 5 Operation of EGP 7 EGP Topology Issues 7 EGP Funetions 9 EGP Message Formats 18 Shortcomings of EGP 26 Configuring EGP 26 Case Study: An EGP Stub Gateway 27 Case Study: An EGP Core Gateway 31 Case Study: Indirect Neighbors 35 Case Study: Default Routes 38 Troubleshooting EGP 39 Interpreting the Neighbor Table 39 Case Study: Converging at the Speed of Syrup 41 End Notes 43 Looking Ahead 43, Review Questions 44 Configuration Exercises 45 Troubleshooting Exercise 51 Chapter 2 Introduction to Border Gateway Protocol 4 55 Classless Interdomain Routing 55 ‘A Summarization Summary 56 Classless Routing $7‘Summarization: The Good, the Bad, and the Asymmetric 61 ‘The Internet: Still Hierarchical After All These Years 64 CIDR: Reducing Routing Table Explosion 69 CIDR: Reducing Class B Address Space Depletion 71 Difficulties with CIDR 72 Who Needs BGP? 76 ‘A Single-Homed Autonomous System 78 ‘Multihoming to a Single Autonomous System 80 Multihoming to Multiple Autonomous Systems 84 ANote on “Load Balancing” 88 BGP Hazards 88 BGP Basics 90 BGP Message Types 93 ‘The BGP Finite State Machine 95, Path Attributes 98, Administrative Weight 111 AS_SET 112 ‘The BGP Decision Process 114 Route Dampening 116 IBGP and IGP Synchronization 118 Managing Large-Scale BGP Peering 124 Peer Groups 124 Communities 124 Route Reflectors 125 Confederations 131 BGP Message Formats 132 ‘The Open Message 133 ‘The Update Message 134 ‘The Keepalive Message 137 ‘The Notification Message 137 End Notes 138 Looking Ahead 139 Recommended Reading 139 Review Questions 139 Chapter 3 Configuring and Troubleshooting Border Gateway Protocol 4 149 Basic BGP Configuration 149 Case Study: Peering BGP Routers 149xi Case Study: Injecting IGP Routes into BGP 155 Case Study: Injecting BGP Routes into an IGP 161 Case Study: IBGP without an IGP 167 Case Study: IBGP Over an IGP 174 Case Study: EBGP Multihop 182 Case Study: Aggregate Routes 185 Managing BGP Connections 204 Routing Policies 208 Resetting BGP Connections 209 Case Study: Filtering Routes by NLRI 211 Case Study: Filtering Routes by AS_PATH 219 Case Study: Filtering with Route Maps 224 Case Study: Administrative Weights 226 Case Study: Administrative Distances and Backdoor Routes 234 Case Study: Using the LOCAL_PREF Attribute 241 Case Study: Using the MULTI_EXIT_DISC Attribute 246 Case Study: Prepending the AS_PATH 252 Case Study: Route Tagging 256 ‘Case Study: Route Dampening 261 Large-Scale BGP 265 Case Study: BGP Peer Groups 265 Case Study: BGP Communities 270 Case Study: Private AS Numbers 284 Case Study: BGP Confederations 287 Case Study: Route Reflectors 300 Looking Ahead 307 Recommended Reading 307 ‘Command Summary 307 Configuration Exercises 312 ‘Troubleshooting Exercises 318 Part ll Advanced IP Routing Issues 331 Chapter 4 Network Address Translation 333 Operation of NAT 333 Basic NAT Concepts 333 NAT and IP Address Conservation 336 NAT and ISP Migration 338, NAT and Multihomed Autonomous Systems 340 Port Address Translation 342Chapter 5 NAT and TCP Load Distribution 343 NAT and Virtual Servers 344 NAT Issues 345 Header Checksums 346 Fragmentation 346 Encryption 346 Security 347 Protocol-Specitic Issues 347 Configuring NAT 356 Case Study: Static NAT 356 Case Study: Dynamic NAT 364 Case Study: A Network Merger 369 ‘Case Study: ISP Multihoming with NAT 374 Port Address Translation 379 ‘Case Study: TCP Load Balancing 381 Case Study: Service Distribution 383 Troubleshooting NAT 386 End Note 387 Looking Ahead 388 ‘Command Summary 388 Configuration Exercises 389 ‘Troubleshooting Exercises 392 Introduction to IP Multicast Routing 395, Requirements for IP Multicast 398 Multicast IP Addresses 399 Group Membership Concepts 404 Internet Group Management Protocol (IGMP) 411 Cisco Group Membership Protocol (CGMP) 419 Multicast Routing Issues 427 Multicast Forwarding 428 Multicast Routing 429 Sparse Versus Dense Topologies 431 Implicit Joins Versus Explicit Joins 432 Source-Based Trees Versus Shared Trees 435 ‘Multicast Scoping 437 Operation of the Distance Vector Multicast Routing Protocol (DVMRP) 441 ‘Neighbor Discovery and Maintenance 442xi ‘The DVMRP Routing Table 443 DVMRP Packet Forwarding 444 DVMRP Message Formats 445 Operation of Multicast OSPF (MOSPF) 453 MOSPF Basics 454 Inter-Area MOSPF 456 Inter-AS MOSPF 459 MOSPF Extension Formats 460 Operation of Core-Based Trees (CBT) 462 CBT Basics 463 Finding the Core 465 CBT Designated Routers 465, Member and Nonmember Sources 466 CBT Message Formats 468 Introduction to Protocol Independent Multicast (PIM) 473, Operation of Protocol Independent Multicast, Dense Mode (PIM-DM) 475 PIM-DM Basics 475 Prune Overrides 481 Unicast Route Changes 484 PIM-DM-Designated Routers 484 PIM Forwarder Election 484 Operation of Protocol Independent Multicast, Sparse Mode (PIM-SM) 487 PIM-SM Basics 488 Finding the Rendezvous Point 489 PIM-SM and Shared Trees 492 Source Registration 496 PIM-SM and Shortest Path Trees 502 PIMv2 Message Formats 507 End Notes 517 Looking Ahead $18, Recommended Reading 518 Command Summary $19 Review Questions 520 Chapter 6 Configuring and Troubleshooting IP Multicast Routing 531 Configuring IP Multicast Routing 531xiv Case Study: Configuring Protocol-Independent Multicast, Dense Mode (PIM-DM) 533, Configuring Protocol-Independent Multicast, Sparse Mode (PIM-SM) 542 Case Study Multicast Load Sharing 568 Troubleshooting IP Multicast Routing 576 Using mrinfo $77 Using mtrace and mstat $80 Looking Ahead 584 Configuration Exercises 585 Troubleshooting Exercises 587 Chapter 7 Large-Scale IP Multicast Routing 593 Chapter 8 Multicast Scoping 593 Case Study Multicasting Across Non-Multicast Domains 595 Connecting to DVMRP Networks 598 Inter-AS Malticasting 602 ‘Multiprotocol Extensions for BGP (MBGP) 606 Operation of Multicast Source Discovery Protocol (MSDP) 607 MSDP Message Formats 609 Case Study: Configuring MBGP 614 Case Study: Configuring MSDP 619 Case Study MSDP Mesh Groups 624 Case Study: Anycast RP 627 Case Study MSDP Default Peers 633 (Command Summary 636 End Notes 637 Looking Ahead 637 Review Questions 638 IP Version 6 643 Design Goals of IPv6 643 Improve Scalability 644 Ease of Configuration 645 Security 645Current State of IPv6 645 1Pv6 Specification (RFCs) 646 Vendor Support 647 Implementations 647 IPv6 Packet Format 649 ‘The IPv6 Address 649 Address Structure 654 IPv6 Header 667 1Pv6 Functionality 672 Enabling IPv6 Capability on a Cisco Router 673 ICMP v6 674 Neighbor Discovery 675 ‘Autoconfiguration 685, Routing 690 ‘The Anycast Process 708 Multicast 708 Quality of Service 714 ‘Transition from IPv4 to IPv6 715 Dual Stacks 715 DNS 716 1Pv6 Tunneled in IPv4 717 Network Address Translation - Protocol Translation 720 End Notes 720 Looking Ahead 721 Recommended Reading 721 Review Questions 721 Chapter Bibliography 724 Chapter 9 Router Management 727, Policies and Procedure Definition 727 Service Level Agreements 728 ‘Change Management 729 Escalation Procedures 730 Updating Policies 730 ‘Simple Network Management Protocol 731 Overview of SNMP 731 CiscoWorks 733 Router Configuration for SNMP 733 RMON 740Overview of RMON 740 Router Configuration for RMON 741 Logging 744 Syslog 748 Overview of Syslog 748 Router Configuration for Syslog 749 ‘Network Time Protocol 750 Overview of NTP 751 Router Configuration for NTP 751 Accounting 756 IP Accounting 756 NetFlow 757 Configuration Management 765 Fault Management 766 Performance Management 768 Security Management 769 Password Types and Encryption 770 Controlling Interactive Access 770 Minimizing Risks of Denial-of-Service Attacks 771 TACACS+ 773 RADIUS 780 Secure Shell 780 Designing Servers to Support Management Processes 782 ‘Network Robustness 782 HSRP 783 Lab 791 Recommended Reading 792 End Notes 792 Looking Ahead 793, Command Summary 793 Review Questions 798, Configuration Exercises 799 Bibliography 800xvii Part Il Appendixes 803 Appendix A The show ip bgp neighbors Display 805, Appendix B A Regular-Expression Tutorial 815 Literals and Metacharacters 815 Delineation Matching the Start and End of Lines 816 Bracketing Matching a Set of Characters 816 Negating Matching Everything Except a Set of Characters 817 Wildcard Matching Any Single Character 817 Alteration Matching One of a Set of Characters 817 Optional Characters Matching a Character That May or May Not Be There 818 Repetition Matching a Number of Repeating Characters 818 Boundaries Delineating Literals 818 Putting It All Together A Complex Example 819 Recommended Reading 819 Appendix C Reserved Multicast Addresses 821 Internet Multicast Addresses 821 References 830 People 830 Appendix D Answers to Review Questions 837 Answers to Chapter I Review Questions 837 Answers to Chapter 2 Review Questions 838 Answers to Chapter 5 Review Questions 845 Answers to Chapter 7 Review Questions 851 Answers to Chapter 8 Review Questions 852 Answers to Chapter 9 Review Questions 855xvii ‘Appendix E Answers to Configuration Exercises 857 Answers to Chapter 1 Configuration Exercises 857 Answers to Chapter 3 Configuration Exercises 864 Answers to Chapter 4 Configuration Exercises 883 ‘Answers to Chapter 6 Configuration Exergises 891 Answers to Chapter 9 Configuration Exercises 895 Appendix F Answers to Troubleshooting Exercises 899 Answer to Chapter | Troubleshooting Exercise 899 Answers to Chapter 3 Troubleshooting Exercises 900 Answers to Chapter 4 Troubleshooting Exercises 910 Answers to Chapter 6 Troubleshooting Exercises 912 Index 917Introduction Since the publication of Volume I of Routing TCP/IP, many volumes have been added to the Csco Press CCIE Professional Development series. And the CCIE program itself has expanded to include various areas of specializa- tion. Yet the IP routing protocols remain the essential foundation on which the CCIE candidate must build his or her peitive. Ihe Foundation is wea, the house will tunible. {stated inthe 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 acental theme inthis second volume, as we move beyond th interior gateway protocols to examine both interautonomous system routing nd 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 lab 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 withthe frst volume, I want to make CCTEs, not people who can pass the CCIE lab. In this vein, you will ind in this book more information than you will need to pass the lab, but certainly all of the materials important in your career as a recognized internetworking expert When I eamed my CCIE, the lab still consisted mostly of AGS+ routers. Certainly the lab andthe nature of the am have changed substantially since that ancient time. If anything, the lab is more dificult now. Another addition 'o 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 Folume Ihad helped them prepare for the test—paticularly for IS-1S, protocol that few outside of service provider environments are exposed to. Ihave therefore waitten this second vol tume 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 tis audience. ' have endeavored to follow the same structure tha I followed in Folume I, 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 10S Software tools fo troubleshooting the protocol. In the case of BGP and IP multicast, this structure is far too lengthy fora single chapter and therefore spans multiple chapters, {hope you lear as much from reading this book as Ihave from writing itxx Icons Used in This Book om i = a re siz, By Gone ‘Multilayer switch ISON switch ou tesa Conmanzato z i ee Gateway ‘Access server CiscoWorks Workstation a i» fi] 6 Custer Controller Front End Printer Laptop ‘em ProcessorLine: Ethernet TT oe Line: Serial Line: Switched Serial Frame Relay Virtual Circuit Command Syntax Conventions Token Ring ) AL Network Cloud ‘The conventions used to present command syntax in this book are the same conventions used in the IOS ‘Command Reference. The Command Reference describes these conventions as follows: + Vertical bars () separate alternative, mutually exclusive elements ‘+ Square brackets { ] indicate optional elements + Braces { ) maicate a required enoce. ‘+ Braces within brackets [{ }] indicate a required choice within an optional element,ail Boldface indicates commands and keywords that are entered literally as shown, In actual configuration ‘examples and output (not general command syntax) boldface indicates commands that are manually input by the user (such asa show command). halies indicates arguments for which you supply actual values.| Exterior Gateway Protocols Chapter 1 Exterior Gateway Protocol Chapter 2 Introduction to Border Gateway Protocol 4 Chapter 3. Configuring and Troubleshooting Border Gateway Protocol 4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.Berress |] Exterior Gateway Protocol ‘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)? Afterall, 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, iis still occasionally encountered. As of this ‘writing, for instance, you can still find EGP in a few U.S. military intenetworks. 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, ata 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 827!, 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 intemnetwork, all gateways have to exchange routing information and recalculate their tables. Even when the internetwork is in a steady state, the size ofthe 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.”6 Chapter 1: Exterior Gateway Protocol NOTE © As the number of gateways grows, so does the number of gateway administrators. AS 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 toa system of interconnected, autonomously controlled internetworks. Within cach 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 16-bit number assigned by the same addressing authori'y 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/rfc1930.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 gatewsys RFC 827 proposed that the exterior gateway’ 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, itis not a routing protocol. It has no algorithm for choosing an ‘optimal path between networks; rather, itis a common language that exterior gateways use to exchange reachability information with other exterior gateways. That reachability information is simple list of major network addresses (no subnets) and the gateways by which they can be reached.Operation of EGP 7 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 Figure 1-1 EGP messages are exchanged between EGP neighbors, or peers. Ifthe 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 toa 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 I-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. EGP Neighbors Do Not Have 0 Be Connected to the Same Network 492.168.17.1 ——> 192.168.1722 ——>. Y, ——s _— | a es EGP gateways are either core gateways or stub gateways. Both gateway types can accept information about networks in other autonomous systems, buta 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. 192.168.16.18 Chapter 1: Exterior Gateway Protocol Figure 1-2 ‘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 isa 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 loop- free interarea topology. Likewise, requiring all EGP reachability information betweea stub autonomous systems to traverse the core AS reduces the potential for routing loops in the EGP topology. To Prevent Routing Loops, Only Core Gateways Can Send Information Learned from One ASt0 Another AS ‘stub asOperation of EGP 9 EGP Functions EGP consists of the following three mechanisms: Neighbor Acquisition Protocol ‘© Neighbor Reachability Protocol © Network Reachability Protocol ‘These three mechanisms use ten message types to establish a neighbor relationship, maintain the neighbor relationship, exchange network reachability information with the neighbor, and notify the neighbor of procedural or formatting errors. Table I-I lists all of the EGP message types and the mechanism that uses each message type. Table 1-1 EGP Message Types Message Type Neighbor Acquisition Request —_ Neighbor Acquisition "Neighbor Acquisition Confiem, Neighbor Acquisition Neighbor Acquisition Refuse Neighbor Acquisition — Neighbor Cease Neighbor Acquistion Neighbor Cease Acknowledgment Neighbor Acquisition Hello -Heard-You — Pall Nework Reachability Update Network Reachability — Eor All fonctions ‘The following sections discuss the details of each of the three EGP mechanisms; the section “EGP Message Formats” in this chapter covers the specific details of the messages. Neighbor Acquisition Protocol Before EGP neighbors can exchange reachability information, they must estadlish that they are compatible. This function is performed by a simple two-way handshake in which one neighbor sends a Neighbor Acquisition Request message, and the other neighbor responds with a Neighbor Acquisition Confirm message. None of the RFCs specify how two EGP neighbors initially discover each other. In practice, an EGP gateway learns of its neighbor by manual configuration of the neighbor's IP address. The gateway then unicasts an Acquisition Request message to the configured neighbor. The message states a Hello interval, the minimum interval between Hello messages that the gateway is willing to accept from the neighbor, and a Fol interval,10 Chapter 1: Exterior Gateway Protocol NOTE the minimum interval that the gateway is willing (o be polled by the neighbor for rating updates. The neighbor's responding Acquisition Confirm message will contain its own, values for the same two intervals. If the neighbors agree on the values, they are ready to ‘exchange network reachability information. When a gateway first learns of a neighbor, it considers the neighbor to be in the Idle state. Before sending the first Acquisition Request, the gateway transitions the neighbor to the Acquire state; when the gateway receives an Acquisition Confirm, it transitions the neighbor to the Down state. ‘See REC 904 for a complete explanation of the EGP finite state machine. A gateway can refuse to accept a neighbor by responding with a Neighbor Acquisition Refuse message rather than an Acquisition Confirm message. The Refuse message can include a reason for the refusal, such as a lack of table space, or it can refuse for an unspecified reason, A gateway can also break an established neighbor relationship by sending a Neighbor Cease message. As with the Refuse message, the originating gateway has the option of including a reason for the Cease or leaving the reason unspecified. A neighbor receiving a Neighbor Cease message responds with a Neighbor Cease Acknowledgment. ‘The last case of a Neighbor Acquisition procedure is a case in which a gateway sends an Acquisition Request but the neighbor does not respond. RFC 888 suggests retransmitting the Acquisition message “at a reasonable rate, perhaps every 30 seconds or $0.” Cisco's EGP implementation does not just repeat unacknowledged messages over a constant period. Rather, it retransmits an unacknowledged Acquisition message 30 seconds after the original transmission, It then waits 60 seconds before the next transmission. Ifno response is received within 30 seconds of the third transmission, the gateway transitions the neighbor state from Acquite to Idle (see Example 1-1). The gateway remains in the Idle state for 300 seconds (5 minutes) and then transitions to Acquire and starts the process all over. Notice in Example 1-1 that cach EGP message has a sequence number. The sequence number allows EGP message pairs (such as Neighbor Acquisition Request/Confirm, Request/Refusal, and Cease/Cease-Ack pairs) to be identified, The next section, “Network Reachability Protocol,” details how the sequence numbers are used, ‘When two EGP gateways become neighbors, one isthe active neighbor and one is the pussive neighbor. Active gateways always initiate the neighbor relationship by sending Neighbor Acquisition Requests. Passive gateways do not send Acquisition Requests; they only respond ‘o them, The same is true for Hello/I-Heard-You message pairs, described in the following section: The active neighbor sends the Hello, and the passive neighbor responds with an I> Heard-You (I-H-U). A passive gateway can initiate a Neighbor Cease message, however, to which the active gateway must reply with a Cease Acknowledgement message.Operation of EGP 11 Example 1-1 debug ip egp transactions Command Ousput Displays EGP State Transitions Shemprdebug ip egp transactions asysten=1, sequence=d QUEST, Statuse@ (UNSPECIFIED), Hello-60, Poll=180 asysten=1, sequence: AUTRE, CodewREQUEST, Status~0 (UNSPECIFIED), Hello-60, Pol 16.1 to 192.168. » sequences fron 192.169.16,1 to 192.168.16.2, version=2, ssystea1, sequence-a ‘Type-ACQUIRE, Code-REGUEST, Status-@ (UNSPECIFIED), Hello=6 Foon 192.168.16.1 to 192.168.16.2, version QUEST, Statué-0 (UNSPECIFIED) , He110-60, Poll=164 ‘A core gateway, which can be a neighbor of routers in several other autonomous systems, might be the active gateway of one neighbor adjacency and the passive gateway of another neighbor adjacency. Cisco's EGP implementation uses the AS numbers as the determining factor: The neighbor whose AS number is lower will be the active neighbor. ighbor Reachability Protocol After a gateway has acquired a neighbor, it maintains the neighbor relationship by sending periodic Hello messages. The neighbor responds to each Hello with an I-H-U message. RFC 904 does not specify a standard period between Hellos; Cisco uses a default period of {60 seconds, which can be changed with the command timers egp. When three Hello/I-H-U message pairs have been exchanged, the neighbor state changes from Down to Up (see Example 1-2). The neighbors can then exchange network reachability information, as described in the next section, If an active neighbor sends three sequential messages without receiving a response, the neighbor state transitions to Down. The gateway sends three more Hellos at the normal Hello interval; if there is still no response, the state changes to Cease. The gateway sends three Neighbor Cease messages at 60-second intervals. Ifthe neighbor responds to any of the messages with a Cease Acknowledgment, or does not respond at all, the gateway transitions the neighbor state to Idle and waits $ minutes before transitioning back 10 ‘Acquire and attempting to reacquire the neighbor. Example 1-3 shows this sequence of events12 Chapter 1: Exterior Gateway Protocol Example 1-2 debug ip egp transactions Command Outpur Displays Two-Way Handshake Success and EGP State Transitions Example 1-3 The Neighbor at 192.168.16.2 Has Stopped Responding. The Interval Berween Each ofthe Unacknoviedged EGP Messages Is 60 Seconds “Type-ACQUIRE, Code-REQUEST, Status-1 (ACTIVE MODE), HeLlo60, Pol1=160 EOP: fron 192,168, 16.2 to 192.168.16.1, version=2, ayste 16.2, version=2, asysten ‘Type=REAGH, Code=HELLO, Status=2 (DOHN) EGP: fron 192.160.18.2 to 192.169.16.1, version-2, asystem 1EACH, Code=T-HEARD.YOU, Status=2 (OWN) 16.1 to 192.168.18.2, version=2, asysten=1, sequence=2 1EAGH, Code=HELLO, Status=2 (OOH) EP: tron 192.168.16.2 to 192.168.16.1, version-2, asyster TypesREACH, Code=T-HEARO.YOU, Statuse2 (OOK) GP: from 192.188.16.1 to 192.168.16.2, version TypesREAGH, Code=HELLO, Status=2 (DOH) EP: fron 192,188.16.2 to 192.168.16.1, version sequence: oP: ‘sequence: asysten=1,, sequence asysten shenp# EGP: from 192.168.16.1 to 192.168.16.2, vereion- ‘TypesREACH, Code-HELLO, Status=1 (UP) GP: fron 192.168.16.2 to 192.168.16.1, version=2, asysten-2, sequences2 ‘TypesREAGH, Code=I-HEARO.YOU, Status=1 (UP) EGP: fron 192.168.16.1 to 192.168.16.2, version=2, asystene1, sequence ‘Type REACH, Code-HELLO, Status=i (UP) EGP: fron 192.168.16.1 to 192.165.16.2, version-2, asysten-1, sequence-2 Type=POLL, Code-0, Status=1 (UP), Not=192.166. 16. EP: from 192.168.16.1 to 192.168.16.2, version=2, asysten-1, sequence Type=REAGH, Code-HELLO, Status=i (UP) a en a Dh OOS ESET SN RE EGP: from 192.168.16,1 to 192.168.16,2, varsion=2, asysten=1, sequence-3 TypeeREAGH, Code-HELLO, Status-2 (00WN) EGP: Fron 192.168.16.1 to 192.168.16.2, version-2, asystemet, sequenced Type-REACH, Code-HELLO, Status=2 (O0WN) GP: Fron 192.168.16.1 to 192.168.16.2, version=2, asystem=t, sequence: Type=REAGH, Code-HELLO, Status-2 (00MM) » asysten=t, sequencer2 EGP: from 192.168.16.1 to 102,168. 16.2, version: Type*ACOUIRE, Code*CEASE, Status-5 (HALTING) EGP: Fron 192.168.16.1 to 192.168, 16.2, version=2, asystem=t, sequenced Type*ACOUIRE, Code=CEASE, Status=1 (ACTIVE-ODE) EGP: Fron 192.168.16.1 to 192,168. 16.2, version-2, asystem=t, sequencers ‘TypeACOUIRE, Code=CEASE, Status=1_(ACTIVE-NODE)Operation of EGP 13 Example 1-4 shows another example of a dead neighbor, except this time a core gateway (192.168.16.2) in the passive mode is discovering the dead neighbor (192.168.16.1).. Example 1-4 Neighbor 192.168.16.1 Has Stopped Responding. The debug Messages Are Taken from 192.168.16.2 ‘a Gateway in Passive Mode {ron 192.168.16.1 to 192.168.16.2, version=2, asysten=1, sequence: EACH, Code=HELLO, Status=1 (UP) asyston=2, sequence HEARO-YOU, Statuse? (UP) fron 192.168.16.2 to 192.168.16.1, version=2, asysten=2, sequence: Type=POLL, Coder, Statuse1 (UP), ‘Net=192.166.16.0 0 192,168.16.1, version=2, asysten=2, sequence=2 , Statusst (UP), Net 16.0 192.168.16.1 going from UP to OOH ( ‘from 192.168.16.2 to 192.168.16.1, asyston-2, sequence TypeACQUIRE, Code=CEASE, Status=2 (PASSIVE-NODE) fron 192.168.16.2 to 192.168.18.1, s asysten=2, sequence: TypeACQUIRE, Code=CEASE, Status~2 (PASSIVE-WODE) ‘When the gateway does not receive a Hello within the 60-second Hello interval, it tries to “wake up” its neighbor. Because a gateway in passive mode cannot send Hellos,it sends a Poll message. The gateway then waits for one Poll interval. (Cisco's default Pol interval is 180 seconds, or 3 minutes.) Ifno response is received, it sends another Poll and waits another Poll interval. If there still s no response, the gateway changes the neighbor state to Down and then immediately to Cease. As in Example 1-3, three Cease messages are sent and the neighbor state is changed to Ide. Network Reachability Protocol ‘When the neighbor state is Up, the EGP neighbors can begin exchanging reachability information. Each gateway periodically sends a Poll message to its neighbor, containing ‘some sequence number. The neighbor responds with an Update message that contains the ‘same sequence number and a list of reachable networks. Example 1-5 shows how Cisco's IOS Software uses the sequence numbers.14 Chapter 1: Exterior Gateway Protocol Example 15 EGP Neighbors Poll Each Other Periodically for Network Reachability Updates ESP: from 192.168.16.1 to 192.168.16.2, version-2, ssystem=1, sequence=120 Type-REAGH, Code=HELLO, Status=1 (UP) ESP: fron 192.168.18.2 to 192.168.18.1, version-2, asystem=2, Type-REACH, Code=I-HEARD-YOU, Status=1 (UP) [E0P: from 192.168.18.1 to 192.168.16.2, versione2, asystem-1, sequences120 Type-REACH, Code-HELLO, Status=1 (UP) to 192,188.16.1, versions2, asystem2, sequencest20 Type=REACH, Code=I-HEARD-YOU, Status=1 (UP) (EGP: from 192.168.18.1 to 192.168.16.2, version=2, as Type=POLL, Codo=@, Status=1 (UP), Not=192.168.16.0 EGP: fron 192.168.16.2 to 192.168.16.1, version: Type=UPOATE, Cod Network 172.17.0 Network 192,168.17.0 via 192.168.16.2 in @ hops. Network 10.0.0.0 via 192.168. 16.2 in 3 hops Network 172,20.0,0 via 192.168.16.4 in 9 hops Network 192.168.18.0 via 192.168.16.9(8) in 3 hops: Network 172,16.0.0 via 192.168.16.3(@) sn 3 hops Network 172.18.0.0 via 192.168,16.3(e) in 3 hops 192.168.16.2 updated 7 routes from 192.168:18.2 to 192. 168.1 Type=POLL, Code=0, Status=t (Ui 2 from 192. 168.16.1 to 102. 168.1 m1, sequence=120 + vorsion=2, asyston-2,_ sequence-3 1 Net=192.168.16.0 , vorsion=2, asystene1,, sequences Type-UPOATE, Code0, Status~! (UP), IntGint, ExtQW=0, Net=182.168.16.0 Network 172,19.0,0 via 192,168.16. in ® hops from 192.168.16.1 to 182, 168.16.2, versions2, asysten=1, sequence=t21 ‘Type-REACH, Code-HELLO, Status=1 (UP) rom 192. 168.18.2 to 182.168.16.1, version=2) asysten=2, sequen: @ Ge 20 Every Hello/I-H-U pair exchanged between neighbors contains the same sequence number until a Poll is sent. The Poll/Update pair also uses the same sequence number. After the Update has been received, the active neighbor increments the sequence number. In Example 1-5, the sequence number is 120 through the Poll/Update, and it then is incremented to 121 Notice that both neighbors send a Poll; in this example, the Poll from the passive neighbor (192,168.16.2) has an entirely different sequence number (3). A neighbor ab with an Update containing the same sequence number as the Poll 's responds ‘The default polling interval used by Cisco's IOS Software is 180 seconds and can be changed with the command timers egp. Normally, a gateway sends an Update only when itis polled; however, this means a topology change might go unannounced for up to 3 minutes. EGP provides for this eventuality by allowing a gateway to send one unsolicited ‘Update—that is, an Update that is not in response to a Poll—each Poll interval. Cisco, however, does not support unsolicited Updates.Operation of EGP 15 NOTE ‘The timers egp command is also used to change the Hello interval. The format of the command is timers egp hello polliime. Both the Poll and the Update messages include the address of a source network. For example, the Poll and Update messages in Example 1-5 show a source network of 192,168.16.0. The source network is the network from which all reachability information is measured—that is, all networks requested or advertised can be reached via a router attached to the source network. Although this network is usually the network to which the ‘wo neighbors are both attached, itis more accurately the network about which the Poll is requesting information, and the network about which the Update is supplying information, EGP is a purely classful protocol, and the source network—as well as the network addresses listed in the Updates—are always major class network addresses, and never subnets. Following the source network address is a list of one or more routers and the networks that can be reached via those routers. The common characteristic ofthe routers on the list is that they are all attached to the source network. Ifa router on the list is not the EGP gateway ‘that originated the Update, the router is an indirect or third-party neighbor. Figure 1-3 illustrates the concept of indirect EGP neighbors. One router, Moe, is a core ‘gateway and is peered with three other gateways, ‘The debug messages in Example 1-5 are taken from Shemp, the router in ASI. Notice in the Update originated by Moe (192.168.16.2) that three networks are listed as reachable via ‘Moe, but also, four networks are listed as reachable via Larry (192.168.16.4) and Curly (192.168.16.3). These two routers are Shemp’s indirect neighbors, via Moe. Joe, in AS3, is not an indirect neighbor, because itis not attached to the source network. Its networks are merely advertised as being reachable via Moe. ‘The advertisement of indirect neighbors saves bandwidth on a common link, but more importantly, indirect neighbors increase efficiency by eliminating an unnecessary router for example, Shemp is not peered with any router other than Moe. In fact, Larry is not even speaking EGP, but is advertising its networks to Moe via RIP. Moe is performing a sort of “preemptive redirect” by informing Shemp ofbetter next-hop routers, than itself, In fact, itis possible for an EGP Update to contain indirect neighbors only—that is, the originator might not include itself as a next hop to any network. In this scenario, the originator is a route server. Ithas learned reachability information from an IGP or from static routes, and it advertises this information to EGP neighbors without itself performing any packet-forwarding functions.16 Chapter 1: Exterior Gateway Protocol Figure 1-3 Indirect EGP Neighbors 172.18.1.0%8 AS2 72.17.4008 172.20.1.0706 10.11.0724 Ware.10e AS1 AS3 From the perspective of an EGP gateway, a neighbor is either an interior gateway or an exterior gateway. A neighbor is an interior gateway if itis in the same AS, and itis an exterior gateway if itis in a different AS. In Figure 1-3, all the EGP gateways see all their neighbors as external gateways. If Larry were speaking EGP and peered with Moe, those {wo routers would see each other as interior gateways. An EGP Update message includes two fields for describing whether the routers in its list are interior or exterior gateways (see the following section, “EGP Message Formats”) Looking atthe first Update message in Example 1-5, you can see these fields just before the source network: IntGW=2 and ExtGW=I. The sum of these two fields tells how many routers ar listed in the Update. All the interior gateways specified are listed first; therefore, if InGW=2 and ExtGW-=1, the first two routers listed are interior gateways and the last router listed is an exterior gateway. If you compare the Update message from 192.168.16.2, in Example 1-5 with Figure 1-3, you will see that the three networks reachable via Curly are listed last in the Update and are marked as exterior—that is, they are reachable via a gateway exterior to Moe, Because stub gateways cannot advertise networks outside of their own AS, only Updates from core gateways can include exterior gateways, ‘The EGP Update message associates a distance with each network it lists, The distance field is $bits, so the distance can range from 0 t0 255. RFC 904 does not specify how the distanceOperation of EGP 17 Example 1-6 is to be interpreted, however, other than that 255 is used to indicate unreachable networks. "Nor does the RFC define an algorithm for using the distance to calculate shortest inter-AS paths, Cisco chooses to interpret the distance as hops, as shown in Example 1-5. The default rales are very basic: © A gateway advertises all networks within its own AS as having a distance of 0. © A gateway advertises all networks within an AS other than its own as having a distance of 3. © A gateway indicates that a network has become unreachable by giving ita distance of 255. For example, you can see in Example 1-5 and Figure 1-3 that although network 172.20.0.0 is one router hop away from Moe, Moe is advertising the network with adistance of 0—the same distance as network 172.17.0.0, which is directly attached. Network 10.0.0.0 is also ‘one router hop away, and network 172.18.0.0 is two hops away, but both are in different autonomous systems and are therefore advertised with a distance of 3. The point is that the distance used by EGP is virtually useless for determining the best path to a network. Example 1-6 shows the routing table of Shemp and the route entries resulting from the Update in Example 1-5. ‘Shemp's Routing Table Shonp#ahow 4p route Codes: C= connected, § - static, I - IOP, R- AIP, M- mobile, B - BGP 1 - EIGRP, EX'- EIGRP external, 0 - OSPF, IA’ OSPF inter area E1 - OSPF external type 1, E2 | OSPF external type 2, E - EGP 4 - 18-18, Li - 16-18 level-1, L2 - 18-18 level-2, *- candidate default Gatemay of last resort is not set 172.19,0.0 255.255.255.015 subnetted, 1 subnets © 172119.1.0 de directly connected, Loopback® Shompe ‘There are two points of interest inthe routing table. First, notice thatthe EGP entries have ‘an administrative distance of 140, This is higher than the administrative distance of any IGP (with the exception of External EIGRP), so a router will always choose an IGP route over ‘an EGP advertisement of the same network.18 Chapter 1: Exterior Gateway Protocol ‘Second, notice that the distanes to each of the EGP-advertised networks are one higher than the distances shown in the Update of Example 1-5. Cisco's EGP process increments, the distance by one, just as a RIP routing algorithm does. EGP Message Formats EGP uses five different formats to encode the ten message types shown in Table 1-1. All the "messages have a common header, as shown in Figure 1-4 Figure 1-4 EGP Message Header ———— s2bits ——_—_____+ 8 8 8 8 Version Type Code Status Checksum ‘Autonomous System # ‘Sequence Number ‘The fields in the EGP message header are defined as follows: © Version—Specities the current EGP version number. If this number ina received message does not agree with the receiver's version number, the message is rejected. ‘The version number of all current EGP implementations is 2. © ‘Type—Specifies which ofthe five message formats follows the header. Table 1-2 (which appears after this list) shows the ten EGP message types and the type number used by each. * Code—sSpecities the subtype, For example, iftype =5, the code specifies whether the message is a Hello or an I-Heard-You. © Status—Varies according to the message type (as with the Code field), For example, a Neighbor Acquisition message can use the status to indicate whether itis active or passive, whereas a Neighbor Reachability message can use the Status field to indicate aan Up o Down state. '* Checksum—The one’s complement of the one’s complement sum of the EGP ‘message. This is the same error-checking algorithm used by IP, TCP, and UDP. © Autonomous System Number—Specifies the AS of the message's originator. '* Sequence Number—Syschronizes message pairs (as described previously in this chapter). For example, ar Update should always contain the same sequence number as the Poll to which itis responding.Operation of EGP 19 Table 1-2 iP Message Types Message Neihibor Acquisition Request Neighbor Acquistion Confirm Neighbor Cease ‘Neighbor Cease Acknowledgment mf fof fl The Neighbor Acquisition Message (EGP Message Type 3) Table 1-3 Neighbor Acquisition messeges are EGP message type 3. Table 1-3 shows the codes used to indicate the EGP message. Table 1.4, taken from RFC 904, shows the possible values of the Status field and the reasons a particular status might be used, Codes Used with Message Type 3 Code ° 1 2 ‘Neighbor Acquisition Refuse Neighbor Cease 4 ‘Neighbor Cease Acknowledgment Figure 1-5 shows the format of the Neighbor Acquisition message. The Hello Interval and Poll Interval fields are present only in the Neighbor Acquisition Request (code 0) and Neighbor Acquisition Confirm (code 1) messages. All other Neighbor Acquisition messages are identical to the message header, with no other fields included.20 Chapter 1: Exterior Gateway Protocol Table 1-4 Status Numbers Used with Message Status Description 0 Unspecified Active mode Passive mode Insufficient resoure Type 3 Going down Perimeter problem Protocol violation ‘Administratively prohibited Use ‘When nothing ese fits Request/Confirm only Request/Confim only 1. Out of table space 2. Outof system resources “1, Unknown autonomous system 2. Use another gateway 1. Operator initiated stop 2. Abort timeout 1. Nonsense polling parameters 2. Unable to assume compatible mode Invalid command or response received in this tate Figure 1-5 The Neighbor Acquisition Message 32 bits ——_—_-__—+| 8 8 8 8 Version Type=3 Code Status Chocksum Autonomous System # ‘Sequence Number Helo lterval Pal inten ‘© Hello interval—The minimum interval, in seconds, between Hellos that the originator is willing to accept. The Cisco default Hello interval is 60 seconds and can be changed with the comm: wand timers egp. Poll interval—The minimum interval, in seconds, between Polls thatthe originator is willing to accept. The Cisco default Poll interval is 180 seconds and can be changed with the command timers egp.‘Operation of EGP 21 ‘The Neighbor Reachability Message (EGP Message Type 5) Figure 1-6 Table 1-5 Table 1-6 ‘The Neighbor Reachability message (see Figure 1-6) is the EGP header, with Type = 5. No additional fields are included, because all necessary information is carried in the Code (see ‘Table 1-5) and Status (see Table 1-6) fields. The Neighbor Reachability Message }___——— s2bits. —_______ 8 8 8 8 Version Types Code Status ‘Checksum ‘Autonomous System # Sequence Number Codes Used with Message Type $ Codi ‘Message 0 Hello _ 1 THeard-You Status Numbers Used with Message Types 5 and 2 Status Description Indeterminate 1 Upstate 2 Down state The Poll Message (EGP Message Type 2) ‘The only field that is added to the EGP header to create the Poll message (see Figure 1-7) is the IP Source Network, the network about which reachability information is being requested. The IP address encoded in this field is always a major Class A, B, or C network. ‘The Code field is always 0, and the Status numbers used are the same as those described in Table 1-6. (RFC 888 shows the Status field as unused in the Poll and Error messages.)22 Chapter 1: Exterior Gateway Protocol Figure 1-7 The Poll Message 32 bits. ——————_—| 8 8 8 8 Version Tred Code=0 ‘Status Checksum ‘Autonomous System # ‘Sequence Number Reserved IP Source Network The Update Message (EGP Message Type 1) Table 1-7 As with the Poll message, the Code field of the Update is always 0. Table 1-7 shows the possible values of the Status field, which isthe same as the values of Table 1-6 with the exception of the Unsolicited value. Status Numbers Used with Message Type I Status Description 0 Indeterminate 1 Up state Down state Rs Unsolicited ‘The most significant bit ofthe Status field is the Unsolicited bit; if the bit is set (giving the ficld a value of 128), the Update is unsolicited. The Unsolicited bit can be used in combination with any of the other Status values. ‘The Update message includes a four-level hierarchy of lists. Figure 1-8 shows the format of the Update message and how the hierarchy of lists is organized, At the highest level of the hierarchy isa list of all the routers that are directly attached to the source network. The nuniber of gateways on the list is specified by the sum of the # of | Interior Gateways and the #of Exterior Gateways fields. ALthe next level, interior gateways are distinguished from exterior gateways. All interior gateways, including the originator, ae listed fist. If there are any exterior gateways, they are listed after the interior gateways.Operation of EGP 23, Figure 1-8 The Update Message 2 bits. ————___— 8 8 8 8 Version Type=e ‘Gode=0 Status (Checksum “Autonomous System # Sequence Number nerorSuoways xterot Gata IP Source Network Gateway 1 IP Addross (without network #) 1Sectets ‘of Distances Distance 1 of Networks Network 11.1 aan Network 14,2 ae Distance n # of Networks | Network tint oo Network 102 + cctets Gateway N IP Adare (wihout network #) 1sontets ‘of Distances Distance 1 1 of Networks Network N.t ae Network N12 tectets Distance Wot Networks Network Nit scetets Network Nn2 1 ectats24 Chapter 1: Exterior Gateway Protocol ‘AL the third layer of the hierarchy, each listed gateway has alist of distances. As with the interior and exterior gateways, a field specifies the number of distances on the list. Finally, foreach listed distance there isa list of networks that can be reached at that distance and via that gateway. A field is included to specify the number of networks on the list. ‘The complete descriptions for the fields of the Update message format are as follows: © # of Interior Gateways—Specifes the number of interior gateways on the lis. ‘* # of Exterior Gateways—Specifies the number of exterior gateways following the list of interior gateways. The sum of this field and the # of Interior Gateways, shown as N in Figure 1-8, is the total number of gateways listed in the Update * IP Source Network—Specifies the network about which reachability information is being supplied. That is, all networks listed in the Update are reachable via a gateway attached to this network. The IP address encoded in ths field is always a major Class A,B, or C network, © Gateway IP Address—Specifies the address of a gateway attached to the source network. Only the host portion of the major Class A, B, or C address is listed; as a result, the length ofthe field is variable from 1 octet for a Class C address to 3 octets for a Class A address. The network portion of the address is already known from the IP Source Network field. ‘* # of Distances—Specifis the total number of distances being advertised under the listed gateway. * Distance—Specifies a particular distance advertised under the listed gateway. © # of Networks—Specifies the total number of networks advertised under the listed distance of the listed gateway. © Network—Specifies the IP address of the network being advertised. In Figure 1-8, each network is shown as belonging toa particular gateway, a particular distance, and a particular order in the network list Like the Gateway IP Address field, the Network field is variable. Unlike the Gateway IP Address field, the Newwork field lists the network portion rather than the host portion of a major Class A, B, ot C address. The Error Message (EGP Message Type 8) NOTE ‘A gateway can send an Error message (see Figure 1-9) at any time to notify a sender of a ‘bad EGP message or an invalid field value. The Code field of the error message is always 0, and the Status is one of the values described in Table 1-7. RFC 888 shows the Status field in the Error message (like inthe Poll message) as unused. RFC 904 specifies the uses shown in Table 1-7.Operation of EGP 25 Figure 1-9 The Error Message Table 1-8 32 bits. ——————| 8 8 8 8 Version “Type=8 Code=0 ‘Status Checksum ‘Autonomous System Sequence Number Reserved Error Message Header (first tee 32-bit words of errored EGP header) ‘The originator of the Error message can use an arbitrary value as tke sequence number. ‘Table 1-8, which is taken from RFC 904, describes the possible values of the Reason field. ‘The Error message header isthe first 12 octets of the EGP message that prompted the Error Use When nothingelsefits. 1.Badmessagelength 2. Invalid Type, Code, or Status field 1 Nonsense polling rates (RequesuConfirm), 2. Invalid Update message format. 3. Response IP Network Address field does rot match command (Update), ‘No information avaiable on the network message. Values of the Reason Field ofthe Error Message Reason Field Value Description 0 Unspecified 1 Bad EGP header format 2 ‘Bad EGP Data field format 3 Reachability info unavailable 4 Excessive polling rate “5 [No response specified inthe IP Network Address field Poll. 1. Two or more Hello messages received within the Hello interval, 2. Two or more Poll messages received within the Poll interval 43. Two or more Request messages received \within some (reasonably short) interval, ‘No Update received forthe Poll within some (reasonably long) interval26 Chapter 1: Exterior Gateway Protocol Shortcomings of EGP ‘The fundamental problem with EGP is its inability to detect routing loops. Because there is an upper boundary on the distance EGP uses (255), you might be tempted o say that counting 1o infinity is atleast a rudimentary loop-detection mechanism. Iti, but the high limit ‘combined with the typical Poll interval makes counting to infinity useless. Given a default Poll interval of 180 seconds, EGP peers could take almost 13 hours to count to infinity. Asa result, EGP must be run on an engineered loop-free topology. Although that was not problem in 1983, when EGP was intended merely to connect stub gateways to the ARPANET backbone, the creators of EGP already foresaw that such a limited topology ‘would soon become inadequate. The autonomous systems making up the Internet would need to evolve into a less structured mesh, in which many autonomous systems could serve as transit systems for many other autonomous systems With the advent of the NSFnet, the imitations of EGP became more pronounced, Not ony were there now multiple backbones, bu there were acceptable use policies conceming what traffic could traverse what backbone. Because EGP cannot support sophisticated poicy- based routing, interim solutions had to be engineered Another major problem with EGP is its inability to adequately interact with IGPs to determine a shortest route to a network in another AS. For example, EGP distances do not reliably translate into RIP hop counts. If the EGP distance causes the hop count to exceed 15, RIP declares the network unreachable. Other shortcomings of EGP include its susceptibility to failures when attempting to convey information on a large number of networks, and its vulnerability to intentionally or unintentionally inaccurate network information Last but certainly not least, EGP can be mind-numbingly slow to advertise a network change. The section “Troubleshooting EGP” includes an example in which a network in an EGP-connected AS becomes unreachable. As the example demonstrates, almost an hour passes before a gateway four hops away determines that the network has gone dow. ‘Several attempts were made (o create an EGPV3, but none were successful. In the end, EGP. ‘was abandoned in favor of an entirely new inter-AS protocol, BGP. As a result, Exterior Gateway Protocol is now not only the name of a protocol, but the name of a class of protocols, giving rise to the notion of an EGP named EGP. Nonetheless, the legacy of EGP. is still with us today in the form of autonomous systems and inter-AS routing. Configuring EGP You can configure EGP on a roater in four basic steps ‘Step 1 Specify the router's AS with the command autonomous-system, Step 2 Start the EGP process and specify the neighbor's AS with the command router egp.Configuring EGP 27 ‘Step 3 Specify the EGP neighbors with the neighbor command. Step 4 Specify what networks are to be advertised by EGP. ‘The first three steps are demonstrated in the first case study, along with several apgroaches to Step 4. Case Study: An EGP Stub Gateway Figure 1-10 shows an EGP stub gateway in AS 65502, connected to a core gatewey in AS (65501. The IGP of the stub AS is RIP, Figure 1-10 EGP Sub Gateway Advertises the Interior Networks of AS 65502 10 the Core Gateway AS 65501 (CORE) 192.168.16.1/28 192.168.16.224 172:16..0124 172.162.0724 172173.0724 192.168.17.0124 Example 1-7 shows the initial configuration of the stub gateway.28 Chapter 1: Exterior Gateway Protocol Example 1-7 Stub Gateway Configuration for Figure 1-10 autononous-syston 65502 router rip redistribute connects redistribute egp 65501 netric 5 network 172.16. router egp @5501 neighbor 192.168.16.1 Notice that the lacal AS (LAS) is specified by the autonomous-system statement, and the {far AS (FAS) is specified by the router egp statement. An EGP process cannot be configured until the LAS is configured. The EGP process is told where to find its peer by the neighbor statement. Buster's routing table (see Example 1-8) contains both EGP route entries learned from the core gateway and RIP entries learned from the interior neighbors. Example 1-8 Buster's Routing Table Shows Entries Learned from the EGP Neighbor and from the Interior RIP Neighbors Bustertshow sp route Codes: C - connected, § - static, I - 1GRP, R - AIP, U- mobile, B - BOP D - ETGRP, EX'- ETGRP external, 0 - OSPF, TA’. OSPF inter area Et - OSPF" external type 1, E2 " OSPF external type 2, & - EGP 4-18-18, Li- IG-TS level-1, L2 - 18-18 level-2, + - candidate detauit Gatenay of last resort is not set E 10.0.0.0 [140/4) vie 192.168.18.1, 2, Serials © 192.169.16.0 4s directly connected, seriaia R192, 468.17-0 [120/1) via 172.16.1.2, 00:00:05, Etherneto E192 vie 192.168.16.1, 00:02:19, Serials £192 via 1921168.16.1, 3, Serials £ 192,168.21 Via 192,168.16.1, 00:02:13, Serials E 192, 168.22.0 [140/4) via 192. 168.16.1, 00:02:19, Serials 172116.0.0 255.255.255.0 is subnetted, 2 subnets © 172.16.1.8 is directly connected, Etherneto R (@ (120/1) via 172.16.1.2, 05, Etherneto a 1120/11 via 172,16.1.2, 09:00:05, Ethernet a ‘The EGP-leamed routes are being redistributed into RIP with a metric of $ (see Example 1-9)Contiguring EGP 29 Example 1-9 Routing Table from a Router Interior to AS 65502 Shows the Redistributed EGP Routes Charlietshow 4p route Codes: © - connected, § - static, I - 10RP, R- AIP, M - mobile, @ - AGP 1. EIGRP, EX’ EIGRP external, 0 - OSPF, IA’ OSPF inter area Et - OSPF external type 1, £2 "OSPF external type 2, & - EOP 4 - ISIS, Li - 18-18 level-1, L2 - 18-18 level-2, *'- candidate default Gateway of Last resort 49 not set 10.0.0.0 [120/5] via 172.16.1.1, 00:00:13, Ethernete 192.168.16.0 [120/1] via 172.16.1.1, 13, Ethemneto 192,168.17-0 is directly connected, Ethernet3. 192,168.19.0 [120/5] vsa 172.16.1.1, 00:00:19, Ethernet 192,168,200 [120/5) via 172.16.1-1) 00:00:13, Etherneto 192.168.21.0 [120/5] via 172.18.1.1, 9, Ethernet 192.168.22.@ (120/5] via 172.18.1.1) 13) Ethernete 172,16,0.0 255.255.255.0 is subnetted, 2 subnets c 172:16.1.0 is directly connected, Ethernet® © —_172.16.2.0 ss airectly connected, Ethernet1 172.17,0.0 255,255.255.0 is subnetted, 1 subnets © 172.17.3.0 is directly connected, Ethernet? Charlier Notice that directly connected networks are also being redistributed into RIP. This, configuration is necessary to advertise network 192.168. 16.0 into the LAS; split horizon prevents Stan from advertising the network to Buster via EGP. An alternative configuration is to add a network 192,168.16.0 statement to the RIP configuration, along with a passive- interface statement to keep RIP broadcasts off of the inter-AS link. As Buster’s EGP configuration stands so far, network information is being received from the core, but no interior networks are being advertised to the core (see Example 1-10). Example 1-10 Stan's Routing Table Shows That None ofthe Interior Networks from AS 65502 Are Being Learned from Buster ‘Stan#show ip route Codes: ¢- connected, § - static, I - TGRP, A - AIP, M- mobile, 8 - BGP D - EIGRP, EX’. EIGRP external, 0 - OSPF, IA’. OSPF inter area Et - OSPF external type 1, £2 " OSPF external type 2, & - EOP 4 - IGG, Li» I6-18 Level-1, L2 » 15-18 level:2, *'- candsoate default, Gatenay of last resort 48 not set 19. 011 192. 168.16. E 14) via 192.168.10.2, c is directly connected, Seriale © 192.168.10.0 is airectly connected, Seriai1 E 192:168.19.0 (140/1} via 192.168.18.2, 00:01:57, Serialy e ss 01:56, Serialt 192.168. via 192,168.18, 57, Serialt 192.168. via 192,168.18. 57, Serialt 192.168. via 192.168.18: 57, Serialt30 Chapter 1: Exterior Gateway Protocol Example 1-11 One option for configuring EGP to advertise the interior networks is to add a redistribute rip statement. However, there are hazards associated with mutual redistribution, The danger is more pronounced when there are topological loops or multiple redistribution points, but even a simple design like the one in Figure 1-10 can be vulnerable to route feedback. For safety, route filters should always be used with mutual redistribution ‘configurations to ensure that no interior network addresses are accepted from the exterior gateway, and no exterior addresses are advertised to the exterior gateway. The problems associated with mutual redistribution are introduced in Routing TCPAP, Volume I and are discussed in further detail in Chapter 2, “Introduction to Border Gateway Protocol 4,” and Chapter 3, “Configuring and Troubleshooting Border Gateway Protacol 4,” of this book, A better approach to configuring EGP to advertise interior networks is 10 use the network statement. When used with EGP or BGP, the network statement has a different function from when used with an IGP configuration. For example, the network 172.16.0.0 statement under Buster's RIP configuration instructs the router (o enable RIP on any interface that has an IP address in the major network 172.16,0.0. When used in conjunction with an inter-AS protocol, the network statement ells the protocol what network addresses to advertise Example I-11 shows Buster's configuration to advertise all the networks in AS 65502. Buster Configuration 19 Advertise All Networks in AS 65502 autononous-systen 65502 ' router rip Fedistrabute connect redistribute egp 65501 metric 5 network 172.16, outer egp 65501 ‘network 172.16. network 172.17. network 192,168.47, neighbor 192.168.16.1 Example 1-12 shows Stan’s routing table after the network statements have been added to Buster's EGP configuration. ‘The advantage of using the network statement under EGP rather than redistribution is somewhat akin to the advantage of using static routes rather than a dynamic routing protocol: Both allow precise control over network reachability. In the case of EGP, the precision is limited by EGP’s classfulness. Although you can keep a major network “private” by not specifying it in a network statement, the same cannot be said of individual subnets, Refer back to Example 1-8, which shows that Buster's routing table contains subnets 172.16.1.0/24 and 172.16.2.0/24. Reexamining the EGP Update message format in Figure 1-8, you will recall that the Update carries only the major class portion of the IPConfiguring EGP 31 network: the first octet of a Class A network, the first (wo octets of a Class B network, and the first three octets of a Class C network. Therefore, the network statement under EGP can, specify only major networks, Example 1-12 Buster Is Now Advertising the Interior Networks of AS 65502 to Stan Stansshow 4p route Codes: © - connected, § - static, I. TORP, A - AIP, M - mobile, B - BGP 1D - EIGRP, EX’. EIGAP external, 0 - OSPF, IA’ OSPF inter area E1 - OSPF external type 1, E2 _ OSPF external type 2, € - EGP A= ISIS, L1 - 18-18 level-1, L2 - 15-18 level-2, * - candidate default Gateway of last resort is not set E 10.0.0.0 (149/4) via 192.168.18.2, + Serialt © 192.168.18.8 is directly connected, Seria E 192.168.17.@ [140/1) via 192.168. 16.2, |, Seriale © 192.168.10.0 is airectly connected, Serialt € —192,168.19.0 [140/1] via 192.168. 18.2, + Seriats £192, 192. 168.18.2, £192, 192.108.18.2, e192 192. 168.18.2, E 172.16.0.0 [140/1] via 192.168.16.2, 00:01:99, Seriale E 172.47.0.0 [140/1) via 102. 168.18.2, 99, Seriala stant Case Study: An EGP Core Gateway By definition, an EGP core gateway can peer with multiple neighbors within multiple far autonomous systems and can pass network information from one FAS to another FAS. Because of this, the configuration of a core gateway differs slightly. Figure 1-11 shows a core router, Stan, which is peered with a router in a FAS (Buster) and a router within its LAS (Ollie).82 Chapter 1: Exterior Gateway Protocol Figure 1-11. Core Router Stan Must Peer with Both Remote Neighbor Buster and Local Neighbor Ollie 72.168 195124 192.168.182124 192.168.18.1/28 AS 65501 te2.168.16.124 (CORE) 492,168.16 2724 Buster AS 65502 172.16.1.0724 172.16.2.024 q2173.024 192.168.17.0724 Example 1-13 demonstrates the EGP configuration of Stan in Figure 1-11 Example 113 Core Gateway Configuration for Network Topology in Figure I-11 sutononous-aystem 65501 | | router esp 0 | | neighbor any ‘The LAS is still specified with the autonomous-system command, bat the FAS is not specified by the router egp command, Instead, an AS number of 0 is used to specify any AS. Likewise, neighbors are specified with a neighbor any command, to respond to any neighbor that sends Acquisition messages. The neighbor any command implicitly configures neighbors, whereas the neighbor command explicitly configures neighbors. Core gateways can have explicitly configured neighbors, but the implicit neighbor anyConfiguring EGP 33 ‘makes life simpler when there are a large number of neighbors, as might be expected at a core gateway. Of course, atleast one neighbor must have an explicit neighbor configuration; two neighbors cannot discover each other if they both have a neighbor any command. Example 1-14 shows the configuration for the neighbor Ollie in Figure 1-11. Example 1-14 Neighbor Configuration for Olle in the Network Topology of Figure I-11 autononous-systen 65501 ep 0 network 192.168.19.0 neighbor 192.16 Although Ollie sill picks up its external neighbors with the neighbor any command, Stan’s address is explicitly configured. If it were not, Stan and Ollie would be unaware of each other's existence. With the configuration in Example 1-14, the core gateway will pass reachability information about networks external to its own AS to every other external AS. The core gateway will not, however, pass information about the networks in its own AS. You can see in Buster's routing table of Example 1-8, for instance, that there is no entry for network 192,168.18.0. Ifthe interior networks are to be advertised, Stan must have a network statement for each network to be advertised. The only network statement shown is for 192.168.16.0, which allows Ollie to receive information about that network. Look again at Buster's routing table, Notice that there is an entry for network 192.168.19.0. This entry is the result of the network 192.168.19.0 statement in Ollie’s configuration in Example 1-14. ‘What happens if a core should not peer with every EGP-speaking neighbor? In Figure 1-12, the three routers in AS 65506 are all running EGP, but Stan should peer with only Spanky and Buckwheat. Alfalfa should peer with Ollie, Of course, the core administrator could trust the administrator of AS 65506 to set up the correct peering with neighbor statements, but trust is seldom good enough in inter-AS routing.34 Chapter 1: Exterior Gateway Protocol Figure 1-12 Spanky and Buckwheat Must Peer Only with Stan, Whereas Alfalfa Must Peer Only with Ollie AS 65506 ee Spanky SS” 20.1.2 Stan [| iears © AS65501 er Buckwheat (CORE) In this example, all three gateways in AS 65506 have neighbor statements for both Stan ‘and Ollie. To regulate the peering, an access list is used with the neighbor any statement, as demonstrated in the configuration for Stan in Example 1-15. Example 115 Regulating Peering with Access Lists Using the neighbor any Command access-List 10 deny 172.20.1.2 List 19 permit any In Example 1-15, the neighbor any statement contains a reference to access list 10, which denies Alfalfa (172.20.1.2) and permits all other neighbors. A similar configuration at Ollie denies Spanky and Buckwheat and permits all other neighbors. Example 1-16 shows the results of this configuration.Configuring EGP 35 Example 1-16 The show ip egp Command Displays Information About EGP Neighbors Stanshow 4p egp Local autonomous system is 65501 EGP Neighbor FAS/LAS State _SndSeq RevSeq Hello Poll j/k Flags 192.169.18.2 65501/65501 UP 3 #60 180 4 Temp, Act s1921168.16.2 65502/65501 UP_ 3:20 3839601804 Temp, Act ‘stant OLie¥show 4p egp Local autonomous systen is 65501 EGP Neighbor _FAS/LAS State _SnaSeq RevSeq Hello Poll j/k Flags +192.168.18,1 65501/65501 UP 98180 Porm, Pass +172.20.1.2'65506/65501 UP 135561804 Temp, Act Using the show ip egp command with Stan and Ollie shows that Ollie is peered with Alfalfa and Stan is peered with Spanky and Buckwheat NOTE The details ofthe fields displayed by the show ip egp command are discussed in the section “Troubleshooting EGP.” For now, the addresses of the neighbors are of interest. Case Study: Indirect Neighbors In Figure I-13, thre stub gateways (Groucho, Harpo, and Chico) are connected tothe core gateway named Ollie. Groucho and Harpo, in separate autonomous systems, share a ommon Ethemet and can therefore be configured as indirect or third-party neighbors.36 Chapter 1: Exterior Gateway Protocol Figure 113 EGP indirect Neighbors AS 65503 Groucho Hrpo AS 65504 102,16020.106 ry 172.18.1.1808 192.168.19.2/28 192.168.21.1724 ‘AS 65501 (CORE) AS 65505, AS 65502 Groucho and Harpo cannot exchange 3 information directly, but they can route packets directly to each other if Ollie advertises them as indirect neighbors. Example 1-17 shows the configuration for Olli. Example 117 Advertising Indirect EGP Neighbors to One Another Enables the Routing of Packets Between Indirect EGP Neighbors | autononous-system 65501 network 192.168. network 192,168.11Configuring EGP 37 In the configuration in Example 1-17, Groucho and Harpo are explicitly configured as neighbors. Following the neighbor statements for the two routers are neighbor third- party statements. These entries specify the neighbor in question and then specify that gateways indirect neighbor on the shared Ethernet, Notice that Chico, which is not on the shared Ethernet, falls under the neighbor any statement. Example 1-18 shows the core sateway’s indirect neighbors recorded as Third Party. Example 1-18 Displaying Core Gateway Indirect Neighbors OLLsershow 4p egp Local autononous system is 65501 EOP Neighbor _FAS/LAS State SndSeq RovSeq Hello Poll j/k Flags +192.169.19.9 65504/65501 UP STE 3249 601804 Perm, Act 102. 165503/65501 UP OTE 8 9177 6 100 4 Perm, Act 192 (95501 /65501 UP STE 9 3192 60180 4 Perm, Pass 1921168.22.2 65505/65501 UP STE 5 3170 60 100 4 Temp, Act, EOP Neighbor Third Party 1192.168.19.9192.168.19.2 #192. 168.19. 168. oulier Ollie’s EGP neighbor table indicates that Groucho and Harpo (192.168.19.2 and 192,168.19.3, respectively) have been configured as indirect neighbors of each other. Harpo's routing table (see Example 1-19) shows the results of the indirect neighbor configuration. Rather than pointing (o the core gateway as the next hop to network 192.168.20.0 in AS 65503, the next hop points directly to Groucho (192.168.19.2). Routing Table Displays Next-Hop Routes to Indirect Neighbors Example 1-1 jofshow 1p route "connected, § - static, I - 16RP, R- AIP, M - mobile, 8 - BGP EIGRP, EX'- EIGRP external, 0 - OSPF, TA'- OSPF inter area OSPF’ external type 1, £2 OSPF external type 2, E - EGP 18-18, Li + 16-8 level-1, U2 - I8-18 level-2, * - candidate default ay of last resort is not set E 10.0.0.0 (140/4) via 192.168.19.1, 00: E192, 188.16.0 [140/4) via 192.168.19.1, 00: & —192,168.17-0 [140/4) via 192.168.19.1, 00:07 e c 192,168.18.0 [140/1] via 192.168.19.1, 00:0 492, 168.19.0 is directly connected, Etherneto | thereto [140/4) via 192.168.19.1, 172.18.0.0 255.255.255.0 is subnetted, 1 subnets © 472118.1.0 ds directly connected, Loopback® Harpo#38 Chapter 1: Exterior Gateway Protocol Harpo’s routing table in Example 1-19 shows that network 192.168.20.0 is directly reachable via next hop 192.168.19.2. Without the indirect neighbor configuration, Harpo ‘would have to use 192.168.19.1 as the next hop. Case Study: Default Routes EGP can be configured to advertise a default route in addition to more specific routes. Ian [AS has only a single exterior gateway default route is usally more efficent than fll list of exterior routes. Memory and processing eeles are conserved on the router and bandwidths saved onthe tink, To advertise a default route into AS 65502, a ilustated previously in Figure 1-1 configure Stan as demonstated in Example 1-20, Example 1-20 Advertsing a Deft Rote you router egp @ network 192.168.16.0 neighbor any default-intornation origina aistribute-List 20 out Serialo ' access-1ist 20 p LR ‘The default-information originate command is used to generate the default route. Unlike in other protocols, when the command is used with EGP, there are no optional statements. Notice, too, that a route filter has been added, which permits only the default route to be advertised out of Stan's $0 interface to AS 65502. Without this filter, the default and all more-specific networks would be advertised. Example 1-21 shows the results of the configuration. Example 1-21 192, 168.20.! Is Reachable as @ Result ofthe Default Rowe Buster#show ip route Codes: ¢ - connected, $ - static, I - IORP, A - AIP, M - mobile 0 EIGRP, EX’. EIGRP external, 0 - OSPF, TA’- OSPF inter area E1 - O8PF external type 1, £2 " OSPF external type 2, E » EG f+ 1618, U1» 18-18 level-1, L2 - 18-18 level-2, *- candsoate default Gateway of Last resort is 182.188.16.1° to" © 192.165.16.0 is directly connected, Serials 4192. 168.17-0 [120/11 vsa 172.16.1.2, 09:00:20, Etherneto 472. 16.0.0 255.255.255.0 is cubnatted, 2 subnets 172.16,1.0 18 directly connected, Etherneto 172.16.2.0 [120/1] via 172.16. 00:21, Ethernet 172.17.0.0 (120/1] via 172.16.1.2, 00:00:21, Ethernet® 0 0.0.0.8 [140/4) via 102.188:16:15 002002485: SOMERS SE‘Troubleshooting EGP 39 Example 1-21 192.168.20.1 Is Reachable as a Result ofthe Default Route (Continued) 192.168.20.1 Type uence to abort. Sending 5, 100-byte ICMP Echos to 192.162.20,1, timeout ie 2 seconds: nit Success rate is 100 percent (5/5), round-trip min/avg/max = 64/66/76 as buster The routing table of AS 65502's exterior gateway shows that the core gateway is advertising only a default route, by which all the exterior networks in Figure 1-13 are reached, Troubleshooting EGP ‘The earlier section “Shortcomings of EGP” discussed several reasons why EGP cannot be used in complex inter-AS topologies. An unexpected benefit is that by forcing a simple topology, EGP is easy to troubleshoot. As with any routing protocol, the first step in troubleshooting EGP is examining the routing tables. Ifa required route is missing or an unwanted route is present, the routing tables should lead you to the source of the problem. Because the EGP metrics have very little ‘meaning, using the routing tables for troubleshooting is greatly simplified in comparison ‘with other routing protocols. ‘When examining EGP configurations, remember that the gateway must have some sort of| neighbor statement—either explicit or neighbor any—for every neighbor. Understanding the use of the network statement, and how it differs from the network statement used with IGP, is also important. ‘The debug ip egp transactions command, used several times in the “Operation of EGI section, isa very useful troubleshooting fool. The output of this command reveals all the important information in all the EGP messages being exchanged between neighbors. Interpreting the Neighbor Table ‘An examination of the EGP neighbor table using show ip egp will tel you about the state and configuration ofa gateway's neighbors. Example 1-18 displayed the output ofthis ‘command; Example I-22 shows some additional output from the show ip egp command that examines Stan’s neighbor table.40 Chapter 1: Exterior Gateway Protocol Example 1-22 show ip egp Command Output Displays Information Useful for Troubleshooting EGP Peers ‘Stan#show 4p eg {Local autonomous systen is 65501 EGP Neighbor _FAS/LAS State __SndSeq RevSeq Hello Poll j/k Flags 192.168.18.2 6550/6551 UP 2:08 9227436 «180. Temp, Act, s1921160.16.2 65502/65501 UP 6a17 53253 9233601804 Temp, Act stant ‘You can see in Stan’s neighbor table that neighbor 192.168.18.2 is an interior neighbor, because the FAS and LAS are the same (65501). The state of the neighbor is shown, as is its uptime. Whereas 192.168.18.2 has been up for just over 2 hours, 192.168.16.2 has been up for 6 days and 17 hours. The present sequence number being used by the gateway for ceach neighbor is shown, as is the present sequence number being used by the neighbor. After the Hello and Poll intervals, the number of neighbor reachability messages that have ‘been received in the past four Hello intervals is recorded, This number is used to determine ‘whether a neighbor should be declared Up or Down, based on two values known as the j and k thresholds. The j threshold specifies the number of neighbor reachability messages that must be received during four Hello intervals before a Down neighbor is declared Up. ‘The & threshold specifies the minimum number of neighbor reachabil be received within four Hello intervals to prevent an Up neighbor from being declared Down. The thresholds, shown in Table 1-9, differ for active and passive neighbors. Table 1-9 EGP j andk Thresholds Threshold Active Passive Description i 3 1 [Neighbor Up threshold k 1 4 [Neighbor Down threshold ky messages that must ‘The next field (Flags) in Example 1-22 specifies whether the neighbor is permanent or temporary. Permanent neighbors are neighbors that have been explicitly configured with a neighbor statement, whereas temporary neighbors have bee! plicitly peered under the neighbor any statement. In Example 1-22, you can see that both of Stan’s neighbors are temporary; this fits with the configuration of Stan discussed earlier, in which there is a single neighbor any statement, Comparing Example 1-22 with Example 1-18, you might find it interesting that although Stan sees Ollie (192.168,18,2) as a temporary neighbor, Ollie sees Stan (192.168.18.1) as a permanent neighbor. An examination of Ollie’s configuration in Example 1-23 shows why.