Implementing Cisco IP Routing

ROUTE

Implementing Cisco IP Routing Volume 1 Version 1.0

Student Guide Text Part Number: 97-2814-01

DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED “AS IS.” CISCO MAKES AND YOU RECEIVE NO WARRANTIES IN CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY OR IN ANY OTHER PROVISION OF THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO SPECIFICALLY DISCLAIMS ALL IMPLIED WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. This learning product may contain early release content, and while Cisco believes it to be accurate, it falls subject to the disclaimer above.

Student Guide

© 2009 Cisco Systems, Inc. All Rights Reserved.

Students, this letter describes important course evaluation access information!

Welcome to Cisco Systems Learning. Through the Cisco Learning Partner Program, Cisco Systems is committed to bringing you the highest-quality training in the industry. Cisco learning products are designed to advance your professional goals and give you the expertise you need to build and maintain strategic networks. Cisco relies on customer feedback to guide business decisions; therefore, your valuable input will help shape future Cisco course curricula, products, and training offerings. We would appreciate a few minutes of your time to complete a brief Cisco online course evaluation of your instructor and the course materials in this student kit. On the final day of class, your instructor will provide you with a URL directing you to a short post-course evaluation. If there is no Internet access in the classroom, please complete the evaluation within the next 48 hours or as soon as you can access the web. On behalf of Cisco, thank you for choosing Cisco Learning Partners for your Internet technology training. Sincerely, Cisco Systems Learning

Table of Contents Volume 1 Course Introduction Overview Learner Skills and Knowledge Course Goal and Objectives Course Flow Additional References Cisco Glossary of Terms Your Training Curriculum General Administration

Planning Routing Services to Requirements Overview Module Objectives

Assessing Complex Enterprise Network Requirements Overview Objectives Defining Cisco Network Models Traffic Conditions in a Converged Network Cisco SONA Framework Routing and Routing Protocols Summary

Creating an Implementation Plan and Documenting the Implementation Overview Objectives Creating an Implementation Plan Implementation Plan Tasks Implementation Plan Documentation Implementation Plan Example Summary

Lab 1-1 Debrief Overview Objectives Lab Overview and Verification Sample Solutions and Alternatives Summary Module Summary Module Self-Check Module Self-Check Answer Key

1 1 1 3 4 6 6 7 10

1-1 1-1 1-1

1-3 1-3 1-3 1-4 1-10 1-13 1-19 1-22

1-23 1-23 1-23 1-24 1-28 1-32 1-34 1-40

1-41 1-41 1-41 1-42 1-46 1-49 1-51 1-53 1-56

Implementing an EIGRP-Based Solution

2-1

Overview Module Objectives

2-1 2-1

Planning Routing Implementations with EIGRP

2-3

Overview Objectives EIGRP Capabilities and Attributes EIGRP Operation and Metric Example: EIGRP Tables Example: Advertised Distance (AD) Example: Feasible Distance (FD) Example: Successor and Feasible Successor Example: EIGRP Metrics Calculation Planning and Documenting for EIGRP Implementing Basic EIGRP Example: Basic EIGRP Configuration Summary

2-3 2-3 2-4 2-8 2-13 2-16 2-17 2-18 2-22 2-24 2-27 2-33 2-35

Implementing and Verifying Basic EIGRP for the Enterprise LAN Architecture Overview Objectives Verify EIGRP Routes for IPv4 Using the Passive-Interface Command with EIGRP Advertising an IP Default Network in EIGRP Determining Summary Boundaries Utilizing Manual Route Summarization Summary

Lab 2-1 Debrief Overview Objectives Lab Overview and Verification Sample Solutions and Alternatives Summary

Configuring and Verifying EIGRP for the Enterprise WAN Architecture Overview Objectives EIGRP Over Frame Relay and on a Physical Interface EIGRP over Multipoint Subinterfaces EIGRP over Point-to-Point Subinterfaces Load Balancing Across Equal-Metric Paths Load Balancing Across Unequal-Metric Paths EIGRP Bandwidth use Across WAN Links EIGRP over EoMPLS and Metro Ethernet Summary

Lab 2-2 Debrief Overview Objectives Lab Overview and Verification Sample Solutions and Alternatives Summary

ii

Implementing Cisco IP Routing (ROUTE) v1.0

2-37 2-37 2-37 2-38 2-49 2-52 2-55 2-59 2-62

2-63 2-63 2-63 2-64 2-68 2-71

2-73 2-73 2-73 2-74 2-79 2-85 2-88 2-90 2-94 2-100 2-108

2-109 2-109 2-109 2-110 2-116 2-119

© 2009 Cisco Systems, Inc.

Implementing and Verifying EIGRP Authentication

2-121

Overview Objectives Router Authentication for EIGRP MD5 Authentication for EIGRP Implementing MD5 Authentication for EIGRP Verifying MD5 Authentication for EIGRP Summary

2-121 2-121 2-122 2-126 2-128 2-137 2-141

Lab 2-3 Debrief

2-143

Overview Objectives Lab Overview and Verification Sample Solutions and Alternatives Summary

2-143 2-143 2-144 2-148 2-151

Advanced EIGRP Features in an Enterprise Network Overview Objectives Scalability in Large Networks EIGRP Queries SIA Connections in EIGRP EIGRP Stub Routers Summary

2-153 2-153 2-154 2-157 2-158 2-161 2-171

Lab 2-4 Debrief

2-173

Overview Objectives Lab Overview and Verification Instructions Summary Module Summary Module Self-Check Module Self-Check Answer Key

2009 Cisco Systems, Inc.

2-153

2-173 2-173 2-174 2-176 2-178 2-179 2-181 2-191

Implementing Cisco IP Routing (ROUTE) v1.0

iii

iv

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

ROUTE

Course Introduction Overview Implementing Cisco IP Routing (ROUTE) v1.0 is an instructor-led training program presented by Cisco training partners to their end customers. This five-day course is designed to help students prepare for Cisco CCNP® certification. The ROUTE course is a component of the CCNP curriculum. The ROUTE course is designed to provide professionals of medium to large network sites with information on the use of advanced routing in implementing scalability for Cisco routers that are connected to LANs and WANs. The goal is to train professionals to dramatically increase the number of routers and sites using these techniques instead of redesigning the network when additional sites or wiring configurations are added. The ROUTE training reinforces the instruction by providing students with hands-on labs to ensure they thoroughly understand how to implement advanced routing within their networks.

Student Skills and Knowledge This subtopic lists the skills and knowledge that students must possess to benefit fully from the course. The subtopic also includes recommended Cisco learning offerings that students should first complete to benefit fully from this course.

Learner Skills and Knowledge Students considered for this training will have attended the following classes or obtained equivalent level training: – ICND1 Interconnecting Cisco Network Devices part 1 v1.0 – ICND2 Interconnecting Cisco Network Devices part 2 v1.0 Knowledge of the Cisco Lifecycle deployment

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

2

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v1. 0—0-3

© 2009 Cisco Systems, Inc.

Course Goal and Objectives This topic describes the course goal and objectives.

Course Goal “To train network professionals on the techniques to plan, implement, and monitor a scalable IP routing network.”

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—0-4

Upon completing this course, you will be able to meet these objectives: Plan Routing Services to meet requirements Implement an EIGRP-based solution Implement a Scalable Multiarea Network OSPF-based solution Implement an IPv4-based redistribution solution Implement Path Control Implement and verify a Layer 3 solution using BGP to connect an enterprise network to an Internet service provider

© 2008 Cisco Systems, Inc.

Course Introduction

3

Course Flow This topic presents the suggested flow of the course materials.

Course Flow Day 1 Course Introduction

A M

Module 1: Planning Routing Services to Requirements

Day 2

Day 3

Day 4

Day 5

Module 2: Implementing an EIGRPbased Solution

Module 3: Implementing a Scalable Multiarea Network OSPF-based Solution

Module 4: Implement an IPv4-based redistribution solution

Module 6: Connecting an Enterprise Network to ISP Networks

Module 5: Implement Path Control

Module 6: Connecting an Enterprise Network to ISP Networks

Lunch Module 2: P Implementing M an EIGRPbased Solution

Module 2: Implementing an EIGRPbased Solution

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

Module 3: Implementing a Scalable Multiarea Network OSPF-based Solution

ROUTE v1. 0—0-5

The schedule reflects the recommended structure for this course. This structure allows enough time for the instructor to present the course information and for you to work through the lab activities. The exact timing of the subject materials and labs depends on the pace of your specific class.

4

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

ROUTE E-learning Modules Path Control Implementation IPv6 Implementation Routing Facilities for Branch Offices and Mobile Workers

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—0-6

Implementing Cisco IP Routing (ROUTE) v1.0 training has three e-learning modules, which also include information required to pass the Cisco 642-902 ROUTE certification exam. The following modules provided: “Implementing Path Control” “Implementing IPv6” “Routing Facilities for Branch Offices and Mobile Workers” The ELT content is supplied on a CD that is given out to each student, along with the other course materials.

© 2008 Cisco Systems, Inc.

Course Introduction

5

Additional References This topic presents the Cisco icons and symbols that are used in this course, as well as information on where to find additional technical references.

Cisco Icons and Symbols Router

Web Server

PC

Network Cloud

Camera PC/Video

Serial Link Laptop Circuit-Switched Link File Server Workgroup Switch

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

End Users

Ethernet

IP Phone

ROUTE v1. 0—0-7

Cisco Glossary of Terms For additional information on Cisco terminology, refer to the Cisco Internetworking Terms and Acronyms glossary of terms at http://www.cisco.com/en/US/docs/internetworking/terms_acronyms/CISCO12.html.

6

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Your Training Curriculum This topic presents the training curriculum for this course.

Cisco Career Certifications Cisco Certifications

www.cisco.com/go/certifications © 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—0-8

You are encouraged to join the Cisco Certification Community, a discussion forum open to anyone holding a valid Cisco Career Certification (such as Cisco CCIE®, CCNA®, CCDA®, CCNP®, CCDP®, CCIP®, CCVP™, or CCSP™). It provides a gathering place for Cisco certified professionals to share questions, suggestions, and information about Cisco Career Certification programs and other certification-related topics. For more information, visit www.cisco.com/go/certifications.

© 2008 Cisco Systems, Inc.

Course Introduction

7

Cisco Career Certifications Expand Your Professional Options and Advance Your Career

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

8

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v1. 0—0-9

© 2009 Cisco Systems, Inc.

Cisco Career Certifications (cont.) Customize Your Learning to Match Your Job Responsibilities If, in addition to Core Networking, you also…

Additional Recommended Cisco Curriculum:

Related Cisco Career Certification:

Assist senior staff i n designing routed and switched network infrastructure

Designing for Cisco Internetwork Solutions (DESGN)

CCDA

Implement and troubleshoot MPLS solutions in your enterpri se network

Implementing Cisco MPLS (MPLS) OR Advanced Implementing and Troubleshooting MPLS VPNs (AMPLS)

CCIP

Implement and troubleshoot IBGP solutions in your enterpri se network

Configuring BGP on Cisco Routers (BGP) OR Building Core Networks with OSPF, ISIS, BGP and MPLS (BCN)

CCIP

Implement and troubleshoot QoS solutions for a converged network

Implementing Cisco Quality of Service (QoS)

CCIP

Implement and troubleshoot wireless network devi ces

Implementing Cisco Unified Wireless Networking Essentials (IUWNE)

CCNA-Wireless

Implement and troubleshoot network securi ty devices

Implementing Cisco IOS Network Security (IINS)

CCNA-Security

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2008 Cisco Systems, Inc.

RO UTE v 1.0—0-10

Course Introduction

9

General Administration This topic presents the general administration for this course.

General Administration Class-Related Issues

Facilities-Related Issues

Sign-in sheet

Course materials

Length and times

Site emergency procedures

Break and lunch room locations

Rest rooms Telephones and faxes

Attire

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—0-11

The instructor will discuss the following administrative issues so that you know exactly what to expect from the class: Sign-in process Start and anticipated end times of each class day Class break and lunch facilities Appropriate attire during class Materials you can expect to receive during class What to do in the event of an emergency Location of the rest rooms How to send and receive telephone and fax messages

10

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Learner Introductions Your name Your company Job responsibilities Skills and knowledge Brief history Objective

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—0-12

Prepare to share this information: Your name Your company Your job responsibilities The prerequisite skills that you have A profile of your experience What you would like to learn from this course

© 2008 Cisco Systems, Inc.

Course Introduction

11

12

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Module 1

Planning Routing Services to Requirements Overview The convergence of voice, video, and data has not only changed the conceptual network models but has also affected the way that networks support services and applications. Correct information must be identified and collected to use in the implementation plan. This module describes Cisco conceptual models and architectures for converged networks, as well as how to build an implementation plan.

Module Objectives Upon completing this module, you will be able to describe the converged network requirements of various network and networked applications within Cisco network architectures, including the creation of the implementation plan. This ability includes being able to meet these objectives: Identify the distinctive business and technical requirements of complex enterprise networks (compared to the simpler networks of CCNA) Assess a provided network design and to select the proper tools and resources and planning the work Assess a provided network design to create an implementation plan Review ICND2 skills and knowledge Discuss lab results to assess skills needed for implementing complex networks

1-2

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 1

Assessing Complex Enterprise Network Requirements Overview This lesson starts by introducing Cisco Enterprise Architectures and describing how they align with the traditional three-layer hierarchical network model. The lesson examines the Cisco Enterprise Composite Network Model and discusses the traffic patterns in converged networks. It also introduces the Cisco vision of the future of the Intelligent Information Network (IIN) and the Cisco Service-Oriented Network Architecture (Cisco SONA). The lesson concludes with a discussion of where routing protocols fit into these models.

Objectives Upon completing this lesson, you will be able to describe the converged network requirements of various networks and network applications within Cisco network architectures. This will result in the ability to identify the information that you must collect when filling out an implementation plan. This ability includes being able to meet these objectives: Define Cisco network models. Understand traffic conditions in a converged network. Understand the Cisco SONA framework. Understand routing and routing protocols.

Defining Cisco Network Models This topic describes Cisco network models, starting with the Cisco Enterprise Architectures and how they map to a traditional three-layer hierarchical network model.

Cisco Enterprise Architectures

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-2

Cisco provides an enterprise-wide systems architecture that helps companies protect, optimize, and grow the infrastructure that supports their business processes. The architecture provides for the integration of the entire network—campuses, data centers, WANs, branches, and teleworkers—offering staff secure access to tools, processes, and services. The Cisco Enterprise Campus Architecture combines intelligent switching and routing of core infrastructure with tightly integrated productivity-enhancing technologies, including IP communications, mobility, and advanced security. The architecture provides the enterprise with high availability through a resilient multilayer design, redundant hardware and software features, and automatic procedures for reconfiguring network paths when failures occur. Multicast provides optimized bandwidth consumption and quality of service (QoS) prevents oversubscription, ensuring that real-time traffic, such as voice and video, and critical data are not dropped or delayed. Integrated security protects against and mitigates the impact of worms, viruses, and other attacks on the network, even at the port level. The Cisco enterprise-wide architecture extends support for standards, such as 802.1x and Extensible Authentication Protocol (EAP). It also provides the flexibility to add IP Security (IPsec) and Multiprotocol Label Switching (MPLS), virtual private networks (VPNs), identity and access management, and VLANs to compartmentalize access. These features help improve performance and security and decrease costs.

1-4

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

The Cisco Enterprise Data Center Architecture is a cohesive, adaptive network architecture. It supports the requirements for consolidation, business continuance, and security, while enabling emerging service-oriented architectures, virtualization, and on-demand computing. IT staff can easily provide departmental staff, suppliers, or customers with secure access to applications and resources. This simplifies and streamlines management, significantly reducing overhead. Redundant data centers provide backup using synchronous and asynchronous data and application replication. The network and devices offer server and application load balancing to maximize performance. This solution allows the enterprise to scale without major changes to the infrastructure. The Cisco Enterprise Branch Architecture allows enterprises to extend head-office applications and services, such as security, IP communications, and advanced application performance to thousands of remote locations and users or to a small group of branches. Cisco integrates security, switching, network analysis, caching, and converged voice and video services into a series of integrated services routers in the branch, so that the enterprises can deploy new services when they are ready, without buying new equipment. This solution provides secure access to voice, mission-critical data, and video applications anywhere and anytime. Advanced network routing, VPNs, redundant WAN links, application content caching, and local IP telephony call processing provide a robust architecture with high levels of resilience for all the branch offices. An optimized network leverages the WAN and LAN to reduce traffic and save bandwidth and operational expenses. The enterprise can easily support branch offices with the ability to centrally configure, monitor, and manage devices located at remote sites, including tools such as AutoQoS, which proactively resolve congestion and bandwidth issues before they affect network performance. The Cisco Enterprise Teleworker Architecture allows enterprises to securely deliver voice and data services to small remote offices and home offices using a standard broadband access service. This ability provides a business resiliency solution for the enterprise and a flexible work environment for employees. Centralized management minimizes IT support costs, while robust integrated security mitigates the unique security challenges of this environment. Integrated security and identity-based networking services enable the enterprise to extend campus security policies to the teleworker. Staff can securely log in to the network over an “always-on” VPN and gain access to authorized applications and services from a single costeffective platform. Productivity can further be enhanced by adding an IP phone, providing costeffective access to a centralized IP communications system with voice and unified messaging services. The Cisco Enterprise WAN Architecture offers the convergence of voice, video, and data services over a single IP communications network, which enables the enterprise to costeffectively span large geographic areas. QoS, granular service levels, and comprehensive encryption options help ensure the secure delivery of high-quality corporate voice, video, and data resources to all corporate sites, enabling staff to work productively and efficiently wherever they are located. Security is provided with multiservice VPNs (IPsec and MPLS) in Layer 2 or Layer 3 WANs, hub-and-spoke topologies, or full-mesh topologies.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-5

Cisco Hierarchical Network Model

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-3

Traditionally, the three-layer hierarchical model has been used in network designs. This model provides a modular framework that allows flexibility in network design and facilitates implementation and troubleshooting. The hierarchical model divides networks or their modular blocks into access, distribution, and core layers with these features: Access layer: This layer is used to grant user access to network devices. In a network campus, the access layer generally incorporates switched LAN devices with ports that provide connectivity to workstations and servers. In a WAN environment, the access layer for remote sites or teleworkers may provide access to the corporate network across WAN technology. Distribution layer: This layer aggregates the wiring closets and uses switches to segment workgroups and isolate network problems in a campus environment. Similarly, the distribution layer aggregates WAN connections at the edge of the campus and provides policy-based connectivity. Core layer (also referred to as the backbone): This layer is a high-speed backbone and is designed to switch packets as fast as possible. Because the core is critical for connectivity, it must provide a high level of availability and adapt to changes very quickly. Note

1-6

The hierarchical model can be applied to any network type: LAN, WAN, wireless LAN (WLAN), metropolitan-area networks (MAN), VPN, or any modular block of the Cisco networking model.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Example: Hierarchical Campus Model

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-4

Example: Hierarchical Network Model WAN

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-5

For example, the hierarchical model can be applied specifically to the enterprise campus. The hierarchical model can also be applied to the enterprise WAN. Obviously, another model is required to break down and analyze an existing modern enterprise network or plan a new one.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-7

Enterprise Composite Network Model Functional Areas

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-6

Since intelligent network service security has become of critical importance to all network planning and implementation, Cisco has developed a set of best practices for security called the Cisco SAFE Blueprint. SAFE helps network designers and administrators properly deploy security solutions to support network solutions and the existing network infrastructure. SAFE includes the Enterprise Composite Network Model, which can be used by network professionals to describe and analyze any modern enterprise network. Three functional areas are defined by the model: Enterprise Campus: This functional area contains the modules required to build a hierarchical, highly robust campus network. Access, distribution, and core principles are applied to these modules. Enterprise Edge: This functional area aggregates connectivity from the various elements at the edge of the enterprise network. It provides a description of connectivity to remote locations, the Internet, and remote users. Service Provider Edge: This area provides a description of connectivity to service providers such as Internet service providers (ISPs), WAN providers, and the public switched telephone network (PSTN).

1-8

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Enterprise Composite Network Model

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-7

Various modules form an integrated converged network that supports business processes. As shown in the figure, the campus comprises six modules: Building, with access switches and end devices (PCs and IP phones) Building distribution, with distribution multilayer switches Core, sometimes called the backbone Edge distribution, which concentrates all branches and teleworkers accessing the campus via WAN or Internet Server farm, which represents the data center Management, which represents the network management functionality Additional modules in the other functional areas represent e-commerce functionality, corporate Internet connections, remote access and VPN connections, and traditional WAN (Frame Relay, ATM, and leased lines with PPP) connections.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-9

Traffic Conditions in a Converged Network This topic describes the traffic types and requirements in converged networks.

Network Traffic Mix Converged network traffic mix: Voice and video traffic Voice applications traffic Mission-critical applications traffic Transactional traffic Routing update traffic Network management traffic

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-8

Converged networks with integrated voice, video, and data contain various traffic patterns: Voice and video traffic, for example, IP telephony, and video broadcast and conferencing Voice applications traffic, generated by voice-related applications (such as contact centers) Mission-critical traffic, generated, for example, by stock exchange applications Transactional traffic, generated by e-commerce applications Routing update traffic, from routing protocols like Routing Information Protocol (RIP), Open Shortest Path First Protocol (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), Intermediate System-to-Intermediate System (IS-IS) Protocol, and Border Gateway Protocol (BGP) Network management traffic

1-10

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Network Requirements Key requirements: Performance – Bandwidth – Delay – Jitter Security – Access – Transmission

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-9

The diversity of the traffic mix poses stringent requirements on the network in terms of performance and security. The requirements significantly differ, depending on the traffic type. For example, voice and video require constant bandwidth and low delay and jitter, while transactional traffic requires high reliability and security with relatively low bandwidth. Video traffic is frequently carried as IP multicast traffic. Also, voice applications such as IP telephony require high reliability and availability, because the user expectations for a “dial tone” in the IP network are exactly the same as in traditional phone network. To meet the traffic requirements in the network, for example, voice and video traffic must be treated differently from other traffic, such as web-based traffic. QoS mechanisms are mandatory in converged networks. Security is a key issue not only for fixed networks but also wireless mobility, for which access to the network is possible from virtually anywhere. Several security strategies, such as device hardening with strict access control and authentication, intrusion protection, intrusion detection, traffic protection with encryption, and so on can minimize or even eliminate network security threats.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-11

Example: Enterprise network

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—1-10

The figure above shows a hierarchical enterprise network with some remote offices. In such environments, many different traffic types exist. IP telephony is used as well as video applications, which add a lot of delay to time-sensitive (VoIP) and bandwidth-consuming (video) traffic streams. Server farms contain storage for mission-critical data and e-commerce applications generating transactional traffic. Traffic toward the server farm requires fast transport and bandwidth guarantees. You must have remote and Internet-connectivity Layer 3 devices sending updates in order to efficiently route traffic. Network design and configuration must be able to provide guaranteed services for all this traffic and satisfy the requirements for performance and security.

1-12

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Cisco SONA Framework This topic describes Cisco SONA, which guides an evolution of enterprise networks toward an IIN. The IIN and its features are also described in this section.

Cisco SONA Framework Cisco Service-Oriented Network Architecture (SONA) is an architectural framework. Cisco SONA brings several advantages to enterprises: – Outlines how enterprises can evolve toward the Intelligent Information Network (IIN) – Illustrates how to build integrated systems across a fully converged intelligent network – Improves flexibility and increases efficiency – Optimizes applications, processes, and resources

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—1-11

Cisco is helping organizations address new IT challenges, such as the deployment of serviceoriented architectures, web services, and virtualization. Cisco SONA is an architectural framework that guides the evolution of enterprise networks to an IIN. The Cisco SONA framework provides several advantages to enterprises: Outlines the path toward the IIN Illustrates how to build integrated systems across a fully converged IIN Improves flexibility and increases efficiency, which results in optimized applications, processes, and resources Cisco SONA uses the extensive product line services, proven architectures, and the experience of Cisco and its partners to help enterprises achieve their business goals.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-13

Cisco SONA Framework Layers

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—1-12

The Cisco SONA framework shows how integrated systems can both allow for a dynamic, flexible architecture and provide for operational efficiency through standardization and virtualization. It centers on the concept that the network is the common element that connects and enables all components of the IT infrastructure. Cisco SONA outlines these three layers of the IIN: Networked infrastructure layer: This layer is where all of the IT resources are interconnected across a converged network foundation. The IT resources include servers, storage, and clients. The network infrastructure layer represents how these resources exist in different places in the network, including the campus, branch, data center, WAN and MAN, and teleworker. The objective for customers in this layer is to have “anywhere and anytime” connectivity. Interactive services layer: This layer enables efficient allocation of resources to applications and business processes delivered through the networked infrastructure. This layer comprises these services:

1-14

—

Voice and collaboration services

—

Mobility services

—

Security and identity services

—

Storage services

—

Computer services

—

Application networking services

—

Network infrastructure virtualization

—

Services management

—

Adaptive management services

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Application layer: This layer includes business applications and collaboration applications. The objective for customers in this layer is to meet business requirements and achieve efficiencies by leveraging the interactive services layer.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-15

Intelligent Information Network IIN integrates networked resources and information assets. IIN extends intelligence across multiple products and infrastructure layers. IIN actively participates in the delivery of services and applications. Three phases in building an IIN are: – Integrated transport – Integrated services – Integrated applications

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—1-13

The Cisco vision of the future of the Intelligent Information Network (IIN) encompasses these features: Integration of networked resources and information assets that have been largely unlinked: Modern converged networks with integrated voice, video, and data require that IT departments more closely link the IT infrastructure with the network. Intelligence across multiple products and infrastructure layers: The intelligence built into each component of the network is extended network-wide and applies end to end. Active participation of the network in the delivery of services and applications: With added intelligence, the IIN makes it possible for the network to actively manage, monitor, and optimize service and application delivery across the entire IT environment. With the listed features, the IIN offers much more than basic connectivity, bandwidth for users, and access to applications. The IIN offers end-to-end functionality and centralized, unified control that promotes true business transparency and agility. The IIN technology vision offers an evolutionary approach that consists of three phases in which functionality can be added to the infrastructure as required: Integrated transport: Everything, including data, voice, and video, is consolidated onto an IP network for secure network convergence. By integrating data, voice, and video transport into a single, standards-based, modular network, organizations can simplify network management and generate enterprise-wide efficiencies. Network convergence also lays the foundation for a new class of IP-enabled applications delivered through Cisco Unified Communications solutions.

1-16

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Integrated services: Once the network infrastructure has been converged, IT resources can be pooled and shared or “virtualized” to flexibly address the changing needs of the organization. Integrated services help to unify common elements, such as storage and data center server capacity. By extending virtualization capabilities to encompass server, storage, and network elements, an organization can transparently use all of its resources more efficiently. Business continuity is also enhanced because shared resources across the IIN provide services in the event of a local systems failure. Integrated applications: With Cisco Application-Oriented Networking (AON) technology, Cisco has entered the third phase of building the IIN. This phase focuses on making the network “application-aware” so that it can optimize application performance and more efficiently deliver networked applications to users. In addition to capabilities such as content caching, load balancing, and application-level security, Cisco AON Software makes it possible for the network to simplify the application infrastructure by integrating intelligent application message handling, optimization, and security into the existing network.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-17

Example: Enterprise Network Networked infrastructure layer Interactive services layer Application layer

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—1-14

The figure above shows a hierarchical enterprise network with some remote offices. Segmentation can be done to three basic layers of SONA: Networked infrastructure layer Interactive services layer Application layer The networked infrastructure layer represents the physical infrastructure—the combination of network, servers, clients, and storage hardware that is deployed throughout an enterprise network. The interactive services layer represents the network-based functionality by making resources available to applications and business processes. Application delivery, real-time communication, management, mobility, security, transport, and virtualization are parts of the interactive services layer. The application layer represents the enterprise software that addresses the needs of organizational processes and data flow, often in a large, distributed environment.

1-18

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Routing and Routing Protocols This topic describes routing and routing protocols.

Routing Protocols

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—1-15

To review, the focus of this course is on selecting, planning, implementing, tuning, and troubleshooting IP advanced routing protocols. This is a technical course at the level of Cisco CCNP®. All of the models and tools described previously are important in the initial part of the process of selecting and planning. The best practice is to use one IP routing protocol throughout the enterprise if possible. In many cases, this practice is not possible, which will be discussed in detail in another module. For example, Border Gateway Protocol (BGP) will be a factor in the Corporate Internet and ECommerce modules if multihomed to ISPs is implemented. You will usually use static routes for remote access and VPN users. Therefore, you are likely to have to deal with multiple routing protocols. The Enterprise Composite Network Model can assist in determining where each routing protocol is implemented, where the boundaries are, and how traffic flows are managed. It is obvious that advanced IP routing protocols must be implemented in all core networks to support high availability requirements. Less advanced routing protocols (such as RIP) and static routes may exist at the access and distribution levels within modules.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-19

Routing Protocol Comparison Parameters

EIGRP

OSPF

BGP

Large

Large

Very Large

Very High

High

Low

Use of VLSM (Yes-No)

Yes

Yes

Yes

Mixed-Vendor Devices (Yes-No)

No

Yes

Yes

Good

Good

Fair

Size of Network (Small-Medium-Large-Very Large) Speed of Convergence (Very High-High-Medium-Low)

Network Support Staff Knowledge (Good-Fair-Poor)

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—1-16

This table provides a simple comparison of three IP routing protocols. The remainder of this course consists of technical details for each of these.

1-20

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Example: Enterprise Network

EIGRP is used as IGP BGP is used as EGP Static routes for remote access and VPN

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—1-17

Based on a best practice, one IP routing protocol has been selected throughout the whole enterprise network in the figure above. Enterprise networks usually employ an Interior Gateway Protocol (IGP) such as RIP, EIGRP, or OSPF for the exchange of routing information within their networks. EIGRP has been used in the example above, as it has very fast convergence and supports a large network size. The network in the figure above has Internet connectivity in which multihoming with multiple routers has been implemented. For such interautonomous system connectivity, an Exterior Gateway Protocol (EGP) is used. BGP is an example of an EGP protocol, is selected above. It supports very large networks and has excellent traffic policy options. Besides advanced IP routing protocols supporting high availability requirements, static routes exist at the access and distribution levels for remote and VPN access.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-21

Summary This topic summarizes the key points that were discussed in this lesson.

Summary Cisco Enterprise Architectures with hierarchical network models facilitate the deployment of converged networks. Converged networks with their traffic mix have higher demands on the network and its resources. The SONA framework guides the evolution of the enterprise network toward the IIN. The network models can be important tools for selecting and implementing an advanced IP routing protocol.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

1-22

Implementing Cisco IP Routing (ROUTE) v1.0

RO UTE v 1.0—1-18

© 2009 Cisco Systems, Inc.

Lesson 2

Creating an Implementation Plan and Documenting the Implementation Overview An implementation plan and its documentation are a result of good processes and procedures during network design, implementation, and performance testing. This lesson assesses a provided network design, identifies network requirements, creates an implementation plan, and provides guidelines for creating the documentation. To create an implementation plan, you must have detailed network information, tools, resources, and a work plan. By selecting the proper tools and resources, as well as a plan of work, you can make implementation of the network is faster, more cost-effective, and capable of meeting high industry standards.

Objectives Upon completion of this lesson, you will be able to describe the requirements of the enterprise network, implementation plan, and documentation of the implementation process, as well as describe their results. These abilities include being able to meet these objectives: Create an implementation plan Define the implementation plan tasks Develop the implementation plan documentation Create an implementation plan example

Creating an Implementation Plan This topic describes the steps required to create a typical implementation plan, the types of information it contains and types of tasks within it.

Implementing Routing in the Network Ad-hoc approach Identify the need for the implementation Implement routing in the network

Structured approach Create an implementation plan Implement the solution Document the implementation

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-2

How is the implementation of routing protocols performed? For any other process, the following options exist: Ad-hoc approach Structured approach In an ad-hoc approach, the network engineer identifies the need for routing protocol implementation and implements the solution without planning any of the tasks. If the size of the network is increasing, new equipment and remote offices are added to its administration. Many activities such as connectivity, routing, and security, are required. The network engineer can simply examine and configure the required functionalities as they arrive. Scalability issues, suboptimal routing, and security issues are more likely to occur with this approach. A good implementation plan is required to avoid such difficulties. In a structured approach, the network engineer identifies the need for a routing protocol implementation and starts with planning first. Based on the existing topology, the engineer reviews all new changes, taking into account many aspects of the implementation. The engineer defines a new topology, including an IP addressing plan, scalability issues, link utilization, remote network connectivity, and other network parameters. The engineer does not review the technical aspect of the implementation only. The implementation plan must meet technical and business requirements as well. The engineer writes all details into the implementation plan documentation prior to the implementation. After the successful implementation he creates good documentation. This documentation includes the implementation plan itself, along with tools, resources, and implementation results.

1-24

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Structured Approach Well-known models and methodologies that can aid in structuring the network implementation tasks include the following: Cisco Lifecycle Services (PPDIOO) IT Infrastructure Library (ITIL) Fault, Configuration, Accounting, Performance, and Security (FCAPS) Telecommunications Management Network (TMN)

Choose a model with elements that fit your organization as well as its business and technical needs.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-3

The implementation plan is part of the well-known models and methodologies of every IT company, which can help structure the network implementation task. These methodologies are generic models that categorize the lifecycle approach of each process and help provide highquality IT services. For many models and methodologies related to network implementation, network implementation with an implementation plan is just one of the building blocks. The following models are a few good examples: The Cisco Lifecycle Services approach defines the minimum set of activities needed, by technology and by network complexity, to help customers successfully deploy and operate Cisco technologies and optimize their performance throughout the lifecycle of the network. This approach is referred to as the PPDIOO model based on the six phases in the network lifecycle: Prepare, Plan, Design, Implement, Operate, and Optimize. The implementation plan is part of the Design phase and the implementation itself is part of the Implement phase. IT Infrastructure Library (ITIL) is a framework of best practices for IT service management that provides high quality IT services. IT services are aligned with business requirements and processes in IT. The implementation plan and implementation are part of ITIL best practices. The Fault, Configuration, Accounting, Performance, and Security (FCAPS) model was created by the International Organization for Standardization (ISO). It defines five categories as the minimum necessary for successful network management: configuration management, fault management, accounting management, performance management and security management. Both the implementation plan and implementation are in the configuration management category.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-25

The Telecommunications Management Network (TMN) model is a protocol model similar to the FCAPS model and defines a framework for the management of telecommunication networks. The Telecommunications Standardization Sector (ITU-T) took the main aspects of the FCAPS model, refined them, and created a framework for which the implementation plan and implementation itself are one of the building blocks. Note

1-26

Each organization is different and has different requirements. Choose the model and elements that fit your organization and its business and technical needs.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Models and Tools Select the implementation model Adapt the model to your organization’s needs Select the tools supporting the model Create the implementation plan

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-4

After you decide on a structured approach, you must choose a model and methodology.. You may combine different models to adapt the solution to fit requirements. The Cisco Lifecycle Services approach is a step-by-step approach for successfully deploying technology solutions; it will be used as an example throughout the course. Once you have selected an implementation model, you must adapt it to the needs of your organization. If you choose service components and define processes and procedures properly when creating your implementation plan, you can produce a successful implementation. You must select cost-effective tools to successfully deploy and optimize Cisco technologies. Once you collect the requirements, models, and tools. you must create the implementation plan. Then you can successfully implement the solution.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-27

Implementation Plan Tasks This topic describes the types of tasks that are detailed in a typical implementation plan.

Create the Implementation Plan Identify the required information for the plan: – Network-specific information, activities, and tasks – Dependencies of the existing installation – Recommended resources Create the implementation plan Implement the solution Verify the implementation Create the documentation

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-5

During the design process you must clearly define the model and network and business requirements before you can create an implementation plan. Prior to developing the implementation plan, you must identify the following required information: Network-specific information, activities, and tasks associated with implementation plan development Dependencies of your implementation plan development on other service components Recommended resources to accomplish the activities and tasks associated with implementation plan development The next logical step is to develop the implementation plan, followed by implementation, verification, and creation of good documentation.

1-28

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Identify the Required Network Information Existing topology, equipment, and software version IP addressing plan Scalability configuration (summarization, stub areas, and so on) List of advertized networks Link utilization Metric requirements for primary and backup links

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-6

One of your most important tasks is to identify network-specific information, because the implementation must support the topology and its requirements. You will likely need to change the existing network installation in order to have a successful implementation. The following network-specific information is required: Existing topology, equipment, software version IP addressing plan Scalability requirements (summarization, stub areas, and so on) List of advertised networks Link utilization Metric requirements for primary and backup links Based on the information above, the network engineer can decide about the tasks required. The existing network may not require topology, IP addressing, or any other changes. In a best case scenario, when the network is built following the Cisco recommended design, the new implementation is just an addition to the existing network.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-29

Identify Other Requirements Site specific implementation requirements Dependencies on existing installation Configuration and verification commands Implementation schedule and resources Tools

Online Resources © 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-7

In addition to network information, there are many other requirements for the successful creation of an implementation plan and for implementation: Site-specific implementation requirements Dependencies on the existing installation Configuration and verification commands Implementation schedule and resources Tools

1-30

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Create the Implementation Plan Plan the work tasks Select the site-specific tools and configurations Configure and coordinate work with specialists Create verification tests

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-8

After you gather network requirements, existing documentation, implementation schedule options, identified implementation risks, management plan, and roles and responsibilities implementation, you can create the plan. You must define and document the following tasks to create a site-specific implementation plan: Identify applications and devices to be implemented Identify installation tasks and checklists Create site-specific configurations Define site-specific installation tasks and checklists Define device configuration and software requirements Create installation verification tests

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-31

Implementation Plan Documentation This topic describes the types of implementation information that should be documented and how to document them.

Implementation Plan Documentation Good documentation is a result of good processes and procedures. Documentation must be: – Correct – Up-to-date – Accessible Documentation must support: – Future upgrades and changes – Troubleshooting – Reporting

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-9

Creating and documenting an excellent implementation plan according to a well-known model and methodology is the first step for good documentation. Documentation must be correct and up-to-date as you will use it during the implementation process and during verification at the end. At the end of the implementation, you will add all verification steps and results to produce documentation that is useful for future processes. The documentation will provide the last known good status of the network and, together with all the details inside, will make it easy to create an implementation plan for future changes and upgrades in the network. At the same time, the documentation must be accessible. This is one of the requirements for a successful troubleshooting session. The documentation contains all of the information about the equipment, configuration, and known issues, as well as baseline, verification tasks, and their results. Having good documentation available to a troubleshooting engineer at any time is essential to ensuring efficient troubleshooting. If the IT department needs to create a report, the documentation can support the information in the report, because it contains all the tasks performed, the schedule, and the resources involved.

1-32

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

What to Document? Network information Tools Resources Implementation plan tasks Verification tasks Performance measurement and results Screenshots and photos

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—1-10

The documentation consists of: Network information Tools Resources Implementation plan tasks Verification tasks Performance measurement and results Screenshots and photos Each part of the documentation presents its own phase of the network lifecycle implementation and verification process. The documentation creation process cannot be finished in one step; it is not finished until the end of the project. The process starts with the implementation plan, which describes all the tasks needed and ends with the verification steps. The typical process when creating documentation includes creating a template and adding information to it during every step of the implementation process. Finally, several verification steps are required to verify that the information is correct. If a standard company template does not exist, then convert the documentation to the company standards and standard models and methodologies. At the end of the project, safely store the document, as it can be used at any time to review the network and determine when changes are required.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-33

Implementation Plan Example This topic describes how to assess a network design and create an implementation plan.

Example: Implementation Plan Identify the existing situation and requirements Follow these steps to create an implementation plan: – Plan – Select the tools and resources – Coordinate the work with specialists – Verify – Interpret the performance results – Document the baseline, performance, and recommendation

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—1-11

In order to create an implementation plan, you must define the existing situation and requirements correctly. Review the given network, select tools and resources, and create the implementation tasks required. The following steps are required during the creation of an implementation plan: Plan Select the tools and resources Coordinate work with specialists Verify Interpret performance results Document baseline, performance, and recommendations

1-34

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Enterprise Network Topology Required

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—1-12

The figure presents an enterprise network in which a hierarchical design is applied. The company would like to implement a scalable solution with a routing protocol that provides fast convergence. For optimal routing and packet forwarding, hierarchical addressing with summarization is required. Users require high-speed access to the server farm with redundant connectivity for protection. The company has many remote offices and a redundant connection to the Internet is required to provide the remote offices with nonstop access to its server farm. For remote offices, a secure connection must be implemented to prevent unauthorized persons from accessing data. Network professionals must review the existing topology and other network information needed to implement a new solution. Network professionals must take all requirements into account and create a complete implementation plan. They must document an implementation plan, along with the results of the verification tests.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-35

Identify Network Information and Requirements Existing topology, equipment, and software version IP addressing plan, configuration, and link utilization Requirements for: – Connectivity and configuration – Protection and optimization – Security and remote access

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—1-13

The first step before creating an implementation plan is to gather existing information about the network and all the requirements. The existing topology provides redundant connectivity among all of the network devices. Internet connectivity is dual-homed, which provides redundant access to the remote sites as well as World Wide Web resources. The equipment can provide all of the functionalities required, but the software version of the operation system must be upgraded. The networking equipment has existing IP addressing that need to be changed in order to ensure optimal routing and forwarding of packets as well as summarization. Requirements for server farm access and remote office connectivity do not include changes in the Quality of Service (QoS) configuration. The server farm hosts the company’s critical applications. Aside from Voice over IP (VoIP), these applications require preferred treatment. Open Shortest Path First (OSPF) is configured in the network. This configuration must be changed, as a faster convergence time is required. The EIGRP routing protocol is a better selection. Security configuration is required to provide secure access to internal resources and to provide remote office connectivity. Existing security is sufficient and no changes are needed. After identification of network information, document all details and requirements, including: A list of equipment, topology (physical and logical), and design documents The current and required software versions The current configuration and documentation, such as for IP addressing, summarization, routing information, QoS, and security Site requirement specifications, including IP addressing, required software, topology changes, routing protocol requirements, QoS, and security.

1-36

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Creation of the Implementation Plan Create an implementation plan and document it – Project contact list – Location information – Tasks and detailed descriptions – Verification steps – Representation of the results

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—1-14

You must identify the current status of the network and current network requirements before creating the first part of documentation. You must then obtain the following information: Project contact list and statements of work Location information and means of accessing to the premises Tools and resources Assumptions Tasks and detailed descriptions Network Staging Plan The following examples show the typical content of an implementation plan and a description of each section. The project contact list introduces all of the people involved and their commitments.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-37

Project Contact List Cisco Project Team

Project Team

Project Manager:

Project Manager:

Telephone:

Telephone:

Email:

Email:

Project Engineer:

Project Engineer:

Telephone:

Telephone:

Email:

Email:

Design Engineer:

Design Engineer:

Telephone:

Telephone:

Email:

Email:

Account Manager:

Account Manager:

Telephone:

Telephone:

Email:

Email:

Systems Engineer:

Systems Engineer:

Telephone:

Telephone:

Email:

Email:

Location information and access details of the premises define where the equipment is located and how to reach it. Equipment Floor Plan Location

Details

Floor Room Suite Position Rack No.

A tools description provides a list of tools that the implementation engineer will require to carry out the work detailed in this document.

1-38

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Tools Required Item No.

Item

1.

PC with a VT100 emulator, 10BaseT interface, FTP Server and TFTP Client applications

2.

Console port cable DB9-RJ45/DB25

3.

10BaseT Ethernet cable

The implementation task list must provide a breakdown of the implementation process, followed by a detailed description of each activity. The output of each activity should be indicated on the implementation record. Implementation Tasks Step No.

Task

1.

Connect to the router

2.

Verify the current installation and create a backup file

3.

Change the Cisco IOS version on all devices

4.

Update the IP address configuration on distribution routers

5.

Configure EIGRP

6.

Verify the configuration and record the results

After the implementation plan is completed successfully, documentation must be created with all of the details, verification steps, and results.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-39

Summary This topic summarizes the key points that were discussed in this lesson.

Summary Using well known models and methodologies can aid in structuring the network implementation tasks and creating an implementation plan. An implementation plan consists of the project and network overview, required tools, and information, as well as the implementation tasks. The tasks in the implementation plan provide a detailed explanation of all actions that must be taken in order to configure the network according to requirements. Good documentation is a result of good processes and procedures, and includes performance testing and documentation of results.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

1-40

Implementing Cisco IP Routing (ROUTE) v1.0

RO UTE v 1.0—1-15

© 2009 Cisco Systems, Inc.

Lesson 3

Lab 1-1 Debrief Overview In Lab 1-1, students create the implementation plan for routing protocol selection and implementation. The first part of the lab is focused on gathering requirements and required data. After a student successfully surveys the existing topology and gathers all of the data, the student must create an implementation plan, and then perform implementation and verification. The student must then document the project. After students complete the lab, the instructor will lead a discussion about lab topology, tasks, verification, and checkpoints. The instructor will also provide a sample solution and different alternatives. Students will present their implementation plans and solutions.

Objectives Upon completing this lesson, you will be able to explain the gathering of network requirements and required data. You will be able to create an implementation plan, verify it, and document the whole process. This ability includes being able to meet these objectives: Complete the Lab Overview and Verification Describe a Sample Solution and Alternatives

Lab Overview and Verification This topic describes lab topology and key checkpoints used to create a solution and to start with the verification.

Lab Topology

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-2

The figure above presents the physical lab topology used for all labs in the Planning Routing Services course. The topology uses four pod routers, two switches, and backbone equipment. A physical lab is not needed for this lab, as the implementation plan is the theoretical part of each implementation. Implementation and verification make up the practical part, but will be practiced throughout the whole course. Based on the topology, students will create requirements, gather all of the data, and create implementation plans. Finally, they will describe and document the verification process.

1-42

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab Review: What Did You Accomplish? Task 1: Identify the requirements the network must meet – What were the steps you took to identify the tasks and requirements? Task 2: Identify the required information – Which tools did you need and where did you gather the application and data requirements? – Where did you get the existing equipment and topology information? – Who defined the routing protocols, scalability, and other configuration details? Task 3: Create an Implementation Plan – How was documentation created and when?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-3

In the first task, you must identify the requirements the network has to meet to establish a foundation for the implementation plan. There are two common approaches to this. You can either define the requirements based on company needs, or gather the requirements from the network administrator. In the first approach, you must select the correct tools to be able to analyze the network and define the requirements in order to start gathering data and creating a good implementation plan. If you choose the second method, you can speed up the process and get the real requirements from the person who knows all the details of the network. In the second task, the requirements are defined, but the real data is missing. Again, you can do some research and collect all the necessary data using the different tools. As an option, two network administrators can provide all of the data. Then you can select the routing protocols, scalability options, and define other configuration details. With all of the details, you can create a good implementation plan, then implement, verify, and document the process.

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-43

Verification Did you have enough information to create an implementation plan? Did you successfully finish the configuration of the network? What was the last step you did in the lab?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-4

A common approach to verifying the implementation process for a routing protocol is to follow the following steps: Evaluate if enough information was gathered in order to create a good implementation plan. Verify that the routing protocol configuration is successful. Create the documentation, which includes all the requirements, required data, implementation and verification steps, as well as implmentation results.

1-44

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Checkpoints Determine which tasks are needed to identify the requirements Document the requirements Gather the application and data requirements Gather the existing equipment, software version, and topology Define the IP addressing plan Select the routing protocols and define the scalability configuration Create the implementation plan and implement the solution Verify and document the implementation

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-5

During the configuration and verification phase, a network operator can deal with several checkpoints. After completing all configuration tasks, the network operator can complete implementation of a routing protocol or perform additional verification and troubleshooting, as needed. Optionally, the network operator can check the creation of the implementation plan in different stages using checkpoints verifying each stage. With different checkpoints, the network operator can verify for proper configuration. The following checkpoints are used for verification: Determine which tasks are needed to identify the requirements Document the requirements Gather the application and data requirements Gather the existing equipment, software version, and topology Define the IP addressing plan Select routing protocols and define scalability configuration Create an implementation plan and implement the solution Verify and document the implementation

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-45

Sample Solutions and Alternatives This topic describes sample solution and other alternatives.

A Sample Solution EIGRP AS 100, IP addressing with mask /24 and /30 for point-topoint links, the default route to Internet, summarization on routers R1 and R2, and no redistribution

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-6

A sample solution includes the implementation details and the details for each task of the implementation plan. Different solutions are possible and the figure points out a few details of a successful configuration. A proper implementation of the routing protocol might include the following attributes: Implementation of EIGRP AS 100 IP addressing with mask /24 and /30 for point-to-point links An Internet gateway that uses the default route announced by routers BBR1 and BBR2 Implementation of summarization on routers R1 and R2; because only one routing protocol is used, there is no need for redistribution between different routing protocols. Note

1-46

As the purpose of lab 1-1 is for you to create an implementation plan, there is no single solution to the lab. The solution presented here is just a sample that satisfies the lab requirements.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternative Solutions OSPF, IP addressing with mask /24 and /30 on peer-to-peer links, BGP and partial redistribution on BBR1 and BBR1, summarization on routers R1 and R2

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-7

You can achieve the same or similar results by using different configuration steps and a different routing protocol. Instead of EIGRP, you can use the OSPF routing protocol. If you use multihoming and have your own BGP autonomous system number and public IP address space, you can run BGP on routers BBR1 and BBR2 instead of using the default route to the Internet. If you use more than one routing process, you may need to use redistribution or the default route. Note

© 2009 Cisco Systems, Inc.

As the purpose of lab 1-1 is for you to create an implementation plan, there is no single solution to the lab. The alternative solution presented here is just a sample that satisfies the lab requirements.

Planning Routing Services to Requirements

1-47

Q and A Why is IP addressing important? Why is routing protocol selection important? Why is the implementation plan important? Why is verification important? What is the last and final step after the successful implementation of the routing protocol in the network?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-8

IP addressing is important because a good addressing plan makes redistribution and summarization possible. It also helps when a scalable solution is required. Routing protocol selection is important, because different organizations require different convergence speeds, levels of scalability, and levels of interoperability. EIGRP has a faster convergence speed than OSPF but OSPF might be more scalable in some cases. An implementation plan is needed in order to correctly implement the proper configuration. Sometimes the steps must be implemented in a specific order. Sometimes the number of steps is so high that without an implementation plan, it is likely that some details might be omitted accidentally. Verification follows implementation. It is important because it proves our concept and the configuration steps used. The final step before handover is the creation of documentation. Good documentation is required in order to implement and verify the network. It also helps later when upgrading and troubleshooting takes place.

1-48

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary Gather all the requirements and required data. Create a good implementation plan. Implement the network using the steps in the implementation plan. Verify and document the implementation.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1. 0—1-9

Planning Routing Services to Requirements

1-49

1-50

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Module Summary This topic summarizes the key points that were discussed in this module.

Module Summary Cisco provides an enterprise-wide systems architecture that helps companies protect, optimize, and grow the infrastructure that supports their business processes. The architecture provides for integration of the entire network—campuses, data centers, WANs, branches, and teleworkers—offering staff secure access to tools, processes, and services. The implementation plan and documentation are a result of good processes and procedures during network design, implementation and performance testing at the end.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—1-1

This module describes the Cisco conceptual models and architectures for converged networks. It examines the three tiers of the hierarchical network model in detail, the traffic conditions in a converged network, and the use of routing protocols. Additionally, it describes the creation of an implementation plan, for which the requirements and the required data provide a baseline to define all of the tasks required to produce a successful implementation. Verification after the implementation proves the concept, and documentation is created to finish the implementation process. .

© 2009 Cisco Systems, Inc.

Planning Routing Services to Requirements

1-51

1-52

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Module Self-Check Use the questions here to review what you learned in this module. The correct answers and solutions are found in the Module Self-Check Answer Key. Q1)

Which three layers are parts of the Cisco hierarchical network model? (Choose three.) (Source: Assessing Complex Enterprise Network Requirements) A) B) C) D) E)

Q2)

What is SAFE? (Source: Assessing Complex Enterprise Network Requirements) A) B) C) D)

Q3)

performance security connectivity convergence speed

Which advantage is not a SONA advantage for enterprises? (Source: Assessing Complex Enterprise Network Requirements) A) B) C) D)

Q5)

security protocol blueprint for network designers and administrators of best practices for the proper deployment of security solutions routing protocol authentication Cisco hierarchical network model white paper

What are two key network requirements? (Choose two.) (Source: Assessing Complex Enterprise Network Requirements) A) B) C) D)

Q4)

Core Distribution Redistribution Access Workgroup

outlines how enterprises can evolve toward the IIN illustrates how to build integrated systems across a fully converged IIN improves flexibility and increases efficiency, which results in optimized applications, processes, and resources uses the limited product line services

What are three SONA framework layers? (Source: Assessing Complex Enterprise Network Requirements) ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________

Q6)

Which routing protocol supports a very high convergence speed and the use of VLSM? (Source: Assessing Complex Enterprise Network Requirements) A) B) C) D)

© 2009 Cisco Systems, Inc.

EIGRP BGP OSPF RIP

Planning Routing Services to Requirements

1-53

Q7)

What are three main steps for a structured approach to implement routing in a network? (Choose three.) (Source: Creating an Implementation Plan and Documenting the Implementation) A) B) C) D)

Q8)

What is the name of the Cisco model and methodology that describes a structured approach to network implementation? (Source: Creating an Implementation Plan and Documenting the Implementation) A) B) C) D)

Q9)

B) C) D)

true false

What is not part of the implementation plan documentation for configuring a routing protocol in an enterprise network? (Source: Creating an Implementation Plan and Documenting the Implementation) A) B) C) D) E)

1-54

existing topology, equipment, software version IP addressing plan and scalability requirements tools needed to evaluate application requirements list of advertized networks and metrics

When changing the software version of the existing network infrastructure, Layer 3 devices are part of the implementation plan for routing protocols. (Source: Creating an Implementation Plan and Documenting the Implementation) A) B)

Q12)

network-specific information, activities and tasks associated with the implementation plan development dependencies your implementation plan development has on other service components recommended resources to accomplish the activities and task associated with implementation plan development implementation plan and verification tasks

What information must you know in order to create an implementation plan for EIGRP routing protocol? (Choose three.) (Source: Creating an Implementation Plan and Documenting the Implementation) A) B) C) D)

Q11)

Cisco Lifecycle Services Cisco ITIL Cisco FCAPS Cisco TMN

Which three items must be identified prior to the creation of an implementation plan? (Choose three.) (Source: Creating an Implementation Plan and Documenting the Implementation) A)

Q10)

select the tools used for implementation create an implementation plan implement the solution document the implementation

tools future upgrade tasks implementation plan tasks verification tasks performance measurement and results

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q13)

Interpretation of performance results must be done prior to the verification steps within the implementation plan for routing protocols. (Source: Creating an Implementation Plan and Documenting the Implementation) A) B)

© 2009 Cisco Systems, Inc.

true false

Planning Routing Services to Requirements

1-55

Module Self-Check Answer Key

1-56

Q1)

A, B, D

Q2)

B

Q3)

A, B

Q4)

D

Q5)

Networked infrastructure layer, interactive services layer, application layer

Q6)

A

Q7)

B, C, D

Q8)

A

Q9)

A, B, C

Q10)

A, B, D

Q11)

A

Q12)

B

Q13)

B

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Module 2

Implementing an EIGRPBased Solution Overview In routing environments, Enhanced Interior Gateway Routing Protocol (EIGRP) offers benefits and features over historical distance-vector routing protocols such as Routing Information Protocol version 1 (RIPv1). These benefits include rapid convergence, lower bandwidth utilization, and multiple routed protocol support besides IP. This module describes how EIGRP works and how to implement and verify EIGRP operations. It also explores advanced topics like route summarization, load balancing, EIGRP bandwidth usage, and authentication. The module concludes with a discussion of EIGRP issues and problems as well as how to correct them.

Module Objectives Upon completing this module, you will be able to implement and verify EIGRP operations. This ability includes being able to meet these objectives: Identify the technologies, components, and metrics of EIGRP needed to implement routing in diverse, large-scale internetworks based on requirements. Configure EIGRP according to a given implementation plan and set of requirements. Discuss the lab results for configuring and verifying EIGRP operations. Configure and verify EIGRP over circuit emulation, MPLS VPNs, and Frame Relay for operational performance. Discuss the lab results for configuring and verifying EIGRP circuit emulation, MPLS VPNs, and Frame Relay operations. Configure and verify EIGRP authentication for operational performance. Discuss the lab results for configuring and verifying EIGRP authentication. Implement and verify the advanced EIGRP features in an Enterprise Network. Discuss the lab results for implementing and verifying EIGRP operations.

2-2

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 1

Planning Routing Implementations with EIGRP Overview To select the appropriate routing protocols for an internetwork, you must understand the key features and terminology that are necessary to evaluate a given protocol against other choices. Routing protocols are distinguished from one another by the way that each selects the best pathway and the way that each calculates the routing protocol metric. Knowing the correct commands to use when you configure Enhanced Interior Gateway Routing Protocol (EIGRP) helps to ensure that the migration to this routing protocol is smooth and quick. This lesson reviews the benefits of EIGRP and discusses the key capabilities that distinguish EIGRP from other routing protocols, including the four underlying technologies within EIGRP. The three tables that EIGRP uses in the path selection process are described, and EIGRP metric calculation is explored in detail. An implementation plan is described as the first step in configuring EIGRP, followed by basic EIGRP configuration.

Objectives Upon completing this lesson, you will be able to describe the components and metrics of EIGRP, how EIGRP selects routes between routers in diverse, large-scale internetworks, the implementation plan creation process, and basic EIGRP configuration. This ability includes being able to meet these objectives: List EIGRP capabilities and attributes. Define EIGRP operation and metrics. Plan and Document EIGRP. Implement Basic EIGRP.

EIGRP Capabilities and Attributes Key capabilities that distinguish EIGRP from other routing protocols include fast convergence, support for variable-length subnet masking (VLSM), partial updates, and support for multiple network layer protocols. This topic describes these capabilities.

EIGRP Capabilities and Attributes Advanced distance vector Multicast and unicast instead of broadcast address Support for multiple network-layer protocols 100% loop-free classless routing Fast convergence Partial updates Flexible network design

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-2

EIGRP is a Cisco proprietary protocol that combines the advantages of link-state and distance vector routing protocols. EIGRP has its roots as a distance vector routing protocol and is predictable in its behavior. EIGRP is easy to configure and is adaptable to a wide variety of network topologies. The addition of several link-state features, such as dynamic neighbor discovery, makes EIGRP an advanced distance vector protocol. EIGRP is an enhanced IGRP because of its rapid convergence and the guarantee of a loop-free topology at all times. A hybrid protocol, EIGRP uses the Diffusing Update Algorithm (DUAL) and includes the following key features: Fast convergence: A router running EIGRP stores all of its neighbors’ routing tables so that it can quickly adapt to alternate routes. If no appropriate route exists, EIGRP queries its neighbors to discover an alternate route. These queries propagate until an alternate route is found. Partial updates: EIGRP does not send periodic updates. Instead, it sends partial triggered updates; these are sent only when the path or the metric changes for a route and contain information about only the changed routes. Propagation of partial updates is automatically bounded so that only those routers that need the information are updated. Because of these two capabilities, EIGRP consumes significantly less bandwidth. This behavior is different from link-state protocols, in which an update is transmitted to all link-state routers within an area. Multiple network-layer protocol support: EIGRP supports multiple network-layer protocols (for example IP) by using protocol-dependent modules. These modules are responsible for protocol requirements specific to the network layer. The rapid convergence and sophisticated metric structure of EIGRP offers superior performance and stability. 2-4

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Note

This course covers only the TCP/IP implementation of EIGRP.

Multicast and unicast: EIGRP uses multicast and unicast, rather than broadcast. The multicast address used for EIGRP is 224.0.0.10.

EIGRP Capabilities and Attributes (Cont.) Support for VLSM and discontiguous subnets Load balancing across equal- and unequal-cost pathways Easy configuration for WANs and LANs Manual summarization at any point Sophisticated metric

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-3

EIGRP features also include: VLSM support: EIGRP is a classless routing protocol, which means that it advertises a subnet mask for each destination network. This feature enables EIGRP to support discontinuous subnetworks and VLSM. With EIGRP, routes are automatically summarized at the major network number boundary, but EIGRP can be configured to summarize on any bit boundary on any router interface. Seamless connectivity across all data-link layer protocols and topologies: EIGRP does not require special configuration to work across any Layer 2 protocols. Other routing protocols, such as Open Shortest Path First (OSPF), use different configurations for different Layer 2 protocols, such as Ethernet and Frame Relay. EIGRP operates effectively in both LAN and WAN environments. WAN support for dedicated point-to-point links and nonbroadcast multiaccess (NBMA) topologies is standard for EIGRP. EIGRP accommodates differences in media types and speeds when neighbor adjacencies form across WAN links and can be configured to limit the amount of bandwidth that the protocol uses on WAN links. Sophisticated metric: EIGRP represents metric values in a 32-bit format to provide enough granularity. EIGRP supports unequal metric load balancing, which allows administrators to distribute traffic flow more efficiently in their networks.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-5

EIGRP Key Technologies EIGRP – Runs directly above the IP layer Neighbor discovery and recovery – Uses Hello packets between neighbors Reliable Transport Protocol – Guaranteed, ordered EIGRP packet delivery to all neighbors – Used for flooding 88—EIGRP 6—TCP 17—UDP

Frame Payload Frame Header

IP Header

Protocol Number

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

Packet Payload

C R C

ROUTE v1. 0—2-4

EIGRP runs directly above the IP layer (protocol number 88) and employs four key technologies that combine to differentiate it from other routing technologies: neighbor discovery and recovery, reliable transport protocol, Diffusing Update Algorithm (DUAL) finite-state machines, and protocol-dependent modules. Neighbor discovery and recovery mechanism: This mechanism enables routers to learn dynamically about other routers on their directly-attached networks. Routers must also discover when their neighbors become unreachable or inoperative. This process is achieved with low overhead by periodically sending small hello packets. As long as a router receives hello packets from a neighboring router, it assumes that the neighbor is functioning and the two can exchange routing information. Reliable Transport Protocol: This protocol is responsible for guaranteed, ordered delivery of EIGRP packets to all neighbors. It supports intermixed transmission of multicast or unicast packets. For efficiency, only certain EIGRP packets are transmitted reliably. For example, on a multiaccess network that has multicast capabilities, such as Ethernet, it is not necessary to send hello packets reliably to all neighbors individually, so EIGRP sends a single multicast hello packet containing an indicator that informs the receivers that the packet need not be acknowledged. Other types of packets, such as updates, contain an indicator in the packet that acknowledgment is required. Reliable transport protocol contains a provision for sending multicast packets quickly, even when unacknowledged packets are pending. This provision helps ensure that convergence time remains low in the presence of varying link speeds. DUAL enables EIGRP routers to find out whether a path to the destination network is loopfree. DUAL allows a router running EIGRP to find alternate paths based on updates received from other routers..

2-6

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Protocol-dependent modules are responsible for network layer protocol-specific requirements. The IP-EIGRP module is responsible for sending and receiving EIGRP packets, which are encapsulated in IP as well as for parsing EIGRP packets and informing DUAL of the new information that has been received. IP-EIGRP asks DUAL to make routing decisions, to put results in the IP routing table and to redistribute routes learned by other IP routing protocols.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-7

EIGRP Operation and Metric EIGRP uses the neighbor table to list adjacent routers. The topology table lists all the learned routes to each destination, while the routing table contains the best route to each destination. This best route is called the successor route. A feasible successor route is a backup route to a destination, which is kept in the topology table. This topic describes how EIGRP uses these tables and routes in its operation.

EIGRP Packets Hello: Establish neighbor relationships Update: Send routing updates Query: Ask neighbors about routing information Reply: Respond to query about routing information ACK: Acknowledge a reliable packet 䱳·¬¬»Ľâ Ű×ŮÎĐć ۲Ż«»«»·˛ą ËĐÜßĚŰ ±˛ ۬¸»®˛»¬đ ··ĽľĎ «˛ń®»´§ đńď ­»®˛± ęčíóęčí Ű×ŮÎĐć Í»˛Ľ·˛ą ËĐÜßĚŰ ±˛ ۬¸»®˛»¬đ ßÍ ďô Ú´żą­ đ¨đô Í»Ż ęîěńđ ·ĽľĎ đńđ ··ĽľĎ «˛ń®»´§ đńđ ­»®˛± ęčíóęčí䱫¬°«¬ ±ł·¬¬»Ľâ 䱳·¬¬»Ľâ Ű×ŮÎĐć ۲Ż«»«»·˛ą ĎËŰÎÇ ±˛ ۬¸»®˛»¬đ ··ĽľĎ «˛ń®»´§ đńď ­»®˛± ęççóęçç Ű×ŮÎĐć Í»˛Ľ·˛ą ĎËŰÎÇ ±˛ ۬¸»®˛»¬đ ßÍ ďô Ú´żą­ đ¨đô Í»Ż ęëđńđ ·ĽľĎ đńđ ··ĽľĎ «˛ń®»´§ đńđ ­»®˛± ęççóęçç 䱳·¬¬»Ľâ 䱳·¬¬»Ľâ ÜËßÔć Ľ«ż´Á®˝Ş®»°´§ř÷ć ďđňďňěňđńîě Ş·ż ďđňďňîňď ł»¬®·˝ ěîçěçęéîçëńěîçěçęéîçë 䱳·¬¬»Ľâ © 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-5

EIGRP uses the following five generic packet types: Hello: Routers use hello packets for neighbor discovery. The packets are sent as multicasts and do not require acknowledgments. Update: Update packets contain route change information. They are sent reliably to the affected routers only. These updates can be unicast to a specific router or multicast to multiple attached routers. Query: When a router performs a route computation and does not have a feasible successor, it sends a reliable query packet to its neighbors to determine if they have a feasible successor for the destination. Queries are normally multicast but can be retransmitted as unicast packets in certain cases. Reply: A router sends a reply packet in response to a query packet. Replies are unicast reliably to the originator of the query. ACK: The acknowledgment (ACK) packet acknowledges update, query, and reply packets. ACK packets are unicast hello packets and contain a nonzero acknowledgment number.

2-8

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Initial Route Discovery

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-6

The process to establish and discover neighbor routes occurs simultaneously with EIGRP. A high-level description of the process follows, using the topology in the figure as an example: 1. A new router (router R1) comes up on the link and sends a hello packet through all of its EIGRP-configured interfaces. 2. Routers receiving the hello packet (router R2) on one interface reply with update packets that contain all the routes they have in their routing tables, except those learned through that interface (split horizon). Router R2 sends an update packet to router R1, but a neighbor relationship is not established until router R2 sends a hello packet to router R1. The update packet from router R2 has the initialization bit set, indicating that this is the initialization process. The update packet includes information about the routes that the neighbor (router R2) is aware of, including the metric that the neighbor is advertising for each destination. 3. After both routers have exchanged hellos and the neighbor adjacency is established, router R1 replies to router R2 with an ACK packet, indicating that it received the update information. 4. Router R1 assimilates all update packets in its topology table. The topology table includes all destinations advertised by neighboring (adjacent) routers. It lists each destination, all the neighbors that can reach the destination, and their associated metric. 5. Router R1 then sends an update packet to router R2. 6. Upon receiving the update packet, router R2 sends an ACK packet to router R1. After routers R1 and R2 successfully receive the update packets from each other, they are ready to update their routing tables with the successor routes from the topology table.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-9

EIGRP Neighbor Table The list of directly connected routers running EIGRP with which this router has an adjacency

IP EIGRP Neighbor Table Next-Hop Router

Interface

Îďý ­¸±© · ° »· ą®° ˛ »·ą¸ ľ±® ×Đó Ű×ŮÎ Đ ˛»·ą ¸ľ±® ­ ş±® °®±˝ »­­ ď Ř ßĽĽ® »­­ × ˛¬»® şż˝» Ř ±´Ľ Ë °¬·ł » Í ÎĚĚ ř ­»˝÷ ř ł­÷ î ďđňď ňďďë ňë Í »đńđ ńđňě ďď đ đćďé ćďę ď îíç ď ďđňď ňďďî ňî Í »đńđ ńđňď ďî đ đćďé ćîë ëíč đ ďéîň íđňď íňí Ú żđńđ ďí đ đćďé ćíď ěďę

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ÎĚ Ń

Ď Ý˛¬ ëđđ đ đ íîî č đ îěç ę đ

Í»Ż Ň«ł í ďě ďí

ROUTE v1. 0—2-7

When a router discovers and forms an adjacency with a new neighbor, it records the neighbor’s address and the interface through which it can be reached as an entry in the neighbor table. One neighbor table exists for each protocol-dependent module. The EIGRP neighbor table is comparable to the adjacencies database that link-state routing protocols use and serves the same purpose: to ensure bidirectional communication between each of the directly connected neighbors. When a neighbor sends a hello packet, it advertises a hold time, which is the amount of time that a router treats a neighbor as reachable and operational. If a hello packet is not received within the hold time, the hold time expires and DUAL is aware of the topology change. The neighbor-table entry also includes information required by the reliable transport protocol. Sequence numbers are employed to match acknowledgments with data packets, and the last sequence number received from the neighbor is recorded, so that out-of-order packets can be detected. A transmission list is used to queue packets for possible retransmission on a perneighbor basis. Round-trip timers are kept in the neighbor-table entry to estimate an optimal retransmission interval.

2-10

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP Topology Table The list of all routes learned from each EIGRP neighbor The source for the topology table: IP EIGRP Neighbor Table IP EIGRP Topology Table Destination 1

FD and AD via Each Neighbor

Îďý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňďíňď÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę Ş·ż ďđňďňďďëňë řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđńđňě Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę Ş·ż ďđňďňďďëňë řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđńđňě Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę Ş·ż ďđňďňďďëňë řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđńđňě Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňě 䱫¬°«¬ ±ł·¬¬»Ľâ

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-8

When the router dynamically discovers a new neighbor, it sends an update about the routes it knows to its new neighbor and receives the same from the new neighbor. These updates populate the topology table. The topology table contains all destinations advertised by neighboring routers. It is important to note that if a neighbor is advertising a destination, it must be using that route to forward packets; this rule must be strictly followed by all distance vector protocols. The topology table also maintains the metric that each neighbor advertises for each destination, the advertised distance (AD), and the metric that this router would use to reach the destination via that neighbor, the feasible distance (FD). The FD is the cost for this router to reach the neighbor for this destination, plus the neighbor’s metric to reach the destination. The topology table is updated when a directly connected route or interface changes or when a neighboring router reports a change to a route. A topology-table entry for a destination can be in one of two states: active or passive. A destination is in the passive state when the router is not performing a recomputation; it is in the active state when the router is performing a recomputation. If feasible successors are always available, a destination never has to go into the active state, thereby avoiding a recomputation. The desired state is the passive state. A recomputation occurs when a destination has no feasible successors. The router initiates the recomputation by sending a query packet to each of its neighboring routers. If the neighboring router has a route for the destination, it sends a reply packet; if it does not have a route, it sends a query packet to its neighbors. In this case, the route is also in the active state in the neighboring router. While a destination is in the active state, a router cannot change the destination’s routing table information. After a router has received a reply from each neighboring router, the topology-table entry for the destination returns to the passive state, and the router can select a successor.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-11

EIGRP IP Routing Table The list of all best routes from the EIGRP topology table and other routing processes The source for the EIGRP routes in an IP routing table: IP EIGRP Topology Table The IP Routing Table Destination 1

Best Route

Îďý­¸±© ·° ®±«¬» »·ą®° 䱫¬°«¬ ±ł·¬¬»Ľâ ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňîěňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďîňîô ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďđňďňďíěňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňďíňíô Ü ďçîňďęčňďňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďďëňëô Ü ďçîňďęčňîňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďďëňëô Ü ďçîňďęčňíňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďďëňëô 䱫¬°«¬ ±ł·¬¬»Ľâ

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

đěćďíćîéô Í»®·ż´đńđńđňď đěćďíćîéô đěćďíćďçô đěćďíćďçô đěćďíćďçô

Úż­¬Ű¬¸»®˛»¬đńđ Í»®·ż´đńđńđňě Í»®·ż´đńđńđňě Í»®·ż´đńđńđňě

ROUTE v1. 0—2-9

A router compares all FDs to reach a specific network, then selects the route with the lowest FD and places it in the IP routing table; this is called the successor route. The FD for the chosen route becomes the EIGRP routing metric to reach that network in the routing table.

2-12

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Example: EIGRP Tables

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-10

Example: EIGRP Tables The network shown illustrates the EIGRP tables; router R3’s tables are displayed. Routers R1 and R2 have established a neighbor relationship with router R3 and have sent their routing tables to router R3. Both routers R1 and R2 have paths to network 10.1.1.0/24, among many others that are not shown. The routing table on router R1 has an EIGRP metric of 1000 for 10.1.1.0/24, so router R1 advertises 10.1.1.0/24 to router R3 with a metric of 1000. Router R3 installs the route to 10.1.1.0/24 via router R1 in its EIGRP topology table with an advertised distance of 1000. Router R2 has network 10.1.1.0/24 with a metric of 1500 in its IP routing table, so router R2 advertises 10.1.1.0/24 to router R3 with an advertised distance of 1500. Router R3 places the route to 10.1.1.0/24 network via router R2 in the EIGRP topology table with an advertised distance of 1500. Therefore, router R3 has two entries to reach 10.1.1.0/24 in its topology table. The EIGRP metric for router R3 to reach both routers R1 and R2 is 1000. This cost (1000) is added to the respective advertised distance from each router, resulting in the feasible distances from router R3 to reach network 10.1.1.0/24 shown in the figure. Router R3 chooses the least-cost feasible distance, which is 2000, via router R1, and installs it in the IP routing table as the best route to reach 10.1.1.0/24. The EIGRP metric in the routing table is equal to the feasible distance from the EIGRP topology table. Router R1 is the successor for the route to 10.1.1.0/24.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-13

DUAL Terminology Upstream and downstream router Selects lowest-cost loop-free paths to each destination – Advertised Distance (AD) = next-hop router-destination – Feasible Distance (FD) = local router cost + AD – Lowest-cost = lowest FD – (Current) successor = next-hop router with the lowest-FD-cost loop-free path – Feasible successor = backup router with loop-free path (its AD < current successor FD)

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-11

DUAL uses the distance information, known as a metric or cost, to select efficient, loop-free paths. The lowest-cost route is calculated by adding the cost between the next-hop router and the destination—referred to as the advertised distance (AD)—to the cost between the local router and the next-hop router. The sum of these costs is referred to as the feasible distance (FD). A successor, also called a current successor, is a neighboring router that has a least-cost path to a destination (the lowest FD) that is guaranteed not to be part of a routing loop; successors are used for forwarding packets. Multiple successors can exist if they have the same FD. By default, up to four successors can be added to the routing table (the router can be configured to accept up to six per destination). As well as keeping least-cost paths, DUAL keeps backup paths to each destination. The nexthop router for a backup path is called the feasible successor. To qualify as a feasible successor, a next-hop router must have an AD less than the FD of the current successor route.

2-14

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

DUAL Operation The topology table is changed when: – The cost or state of a directly connected link changes – An EIGRP packet (update, query, reply) is received – A neighbor is lost DUAL computes an alternate path if the primary (successor) is lost – Local computation: a feasible successor is present in the topology—the route is passive – DUAL recomputation: no feasible successor is present in the topology—the route is active

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-12

If the route via the successor becomes invalid (because of a topology change) or if a neighbor changes the metric, DUAL checks for a feasible successor to the destination route. If one is found, DUAL uses it, thereby avoiding the need to recompute the route. If no suitable feasible successor exists, a recomputation must occur to determine the new successor. Although a recomputation is not processor-intensive, it does affect convergence time, so it is best to avoid any unnecessary recomputations.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-15

Example: Advertised Distance (AD) Advertised distance is the distance (metric) to a destination as advertised by an upstream neighbor

Topology Table

Destination

Advertised Distance (AD)

Neighbor

10.0.0.0/8

20+10=30

R8

10.0.0.0/8

1+10+10=21

R2

10.0.0.0/8

100+20+10+10=140

R4

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-13

Example: Advertised Distance (AD) The figure above shows an example of how the AD is calculated. Router R1 has several options available to reach network 10.0.0.0/8. Routers R2, R4, and R8 each send an update to router R1. Each update contains an AD, which is the cost that router is advertising to reach network 10.0.0.0/8.

2-16

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Example: Feasible Distance (FD) Lowest cost = lowest FD

Topology Table

Destination

Feasible Distance (FD)

Neighbor

10.0.0.0/8

100+20+10=130

R8

10.0.0.0/8

100+1+10+10=121

R2

10.0.0.0/8

100+100+20+10+10=240

R4

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-14

Example: Feasible Distance (FD) The figure above shows an example of how the FD is calculated. Router R1 has several options available to reach network 10.0.0.0/8. Each update from the three neighbors has a different AD. By adding the cost of the local link to routers R2, R4, and R8 to the AD of each path, router R1 calculates the FD for each path to network 10.0.0.0/8.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-17

Example: Successor and Feasible Successor Advertised distance is the distance (metric) to a destination as advertised by an upstream neighbor

Router A’s Routing Table Destination

AD

FD

Neighbor

Status

10.0.0.0/8

30

130

R8

FS

10.0.0.0/8

21

121

R2

S

10.0.0.0/8

140

240

R4

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

7

121

R2

RO UTE v 1.0—2-15

Example: Successor and Feasible Successor The figure above shows the successor and feasible successor on router R1 to network 10.0.0.0/8. Three paths exist for network 10.0.0.0/8. The FD and AD values are calculated for all three paths—the three candidates for the routing table. The candidate with the lowest FD value becomes the successor. If the AD for one of the remaining two candidates is lower than the FD on the successor route, then this candidate becomes a feasible successor. The route via router R2 becomes the successor. The route via router R8 becomes the feasible successor. Only the successor route goes into the routing table.

2-18

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Example: Successor and Feasible Successor Solve Loop Issue R1 receives information about 10.0.0./8 from R8 and R4 FD on R1 is smaller than AD from R4 and the update from R4 is not FS

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-16

The scenario on this slide shows how the DUAL algorithm solves the EIGRP routing loop issue. Router R8 with an AD of 30 sends the routing update about network 10.0.0.0/8. Router R1 receives an update, calculates the FD value (130), and sends an update to both neighbors. Routers R1, R2, and R4 are in a loop, and the picture above shows the update sent to router R2, which comes back to router R1. The update travelled via routers R2 and R4, and the AD of the update received on router R1 is 330. The value is higher than the FD value (130) calculated from the original update received from router R8. Because the FD of the update coming from R8 is smaller than the AD in the update coming from router R4, the route from the second update does not become feasible successor. This way DUAL solves the routing loop issue.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-19

EIGRP Metric The use of metric components is represented by K values Metric components are: – Bandwidth (K1) – Delay (K3) – Reliability (K4 and K5) – Loading (K2) MTU is included in the update but not used for metric calculation

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-17

EIGRP uses the composite metric to determine the best path. The metric can be based on five criteria, but EIGRP uses only two of these criteria by default: Bandwidth: The smallest bandwidth between source and destination Delay: The cumulative interface delay along the path The following criteria can be used, but are not recommended, because using them typically results in frequent recalculation of the topology table: Reliability: This value represents the worst reliability between source and destination, based on keepalives. Loading: This value represents the worst load on a link between the source and destination, computed based on the packet rate and the configured bandwidth of the interface. Maximum Transmission Unit (MTU): This represents the smallest MTU in the path. MTU is included in the EIGRP routing update but is not actually used in the metric calculation.

2-20

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP Metric Calculation By default, EIGRP metric: – Metric = bandwidth (slowest link) + delay (sum of delays) Delay = sum of the delays in the path, in tens of microseconds, multiplied by 256. Bandwidth = [107 / (minimum bandwidth link along the path, in kilobits per second)] * 256 Formula with default K values (K1 = 1, K2 = 0, K3 = 1, K4 = 0, K5 = 0): – Metric = [K1 * BW + ((K2 * BW) / (256 – load)) + K3 * delay] If K5 not equal to 0: – Metric = Metric * [K5 / (reliability + K4)] Note: Multiplication by 256 is because of older protocol. © 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-18

EIGRP calculates the metric by adding together weighted values of different variables of the link to the network in question. The default constant weight values are K1 = K3 = 1, and K2 = K4 = K5 = 0. In EIGRP metric calculations, when K5 is 0 (the default), variables (bandwidth, bandwidth divided by load, and delay) are weighted with the constants K1, K2, and K3. The following is the formula used: metric = (K1 * bandwidth )+ [(K2 * bandwidth) / (256 – load)] + (K3 * delay) If these K values are equal to their defaults, the formula becomes the following: metric = (1 * bandwidth ) + [(0 * bandwidth) / (256 – load)] + (1 * delay) metric = bandwidth + delay If K5 is not equal to 0, the following additional operation is performed: metric = metric * [K5 / (reliability + K4)] K values are carried in EIGRP hello packets. Mismatched K values can cause a neighbor to be reset (Only K1 and K3 are used, by default, in metric compilation.) These K values should be modified only after careful planning; changing these values can prevent your network from converging and is generally not recommended. The format of the delay and bandwidth values used for EIGRP metric calculations is different from those displayed by the show interface command. The EIGRP delay value is the sum of the delays in the path, in tens of microseconds, multiplied by 256. The show interface command displays delay in microseconds. The EIGRP bandwidth is calculated using the minimum bandwidth link along the path, in kilobits per second. The value 107 is divided by this value, and then the result is multiplied by 256, because of the older protocol.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-21

Example: EIGRP Metrics Calculation Path 1: R1 > R2 > R3 > R4 – Least bandwidth = 64 [kb/s] – Total delay = 2,000 + 2,000 + 2,000 [tens of microseconds] – Metric = (1 * 107 / 64) * 256 + 1 * (2,000 + 2,000 + 2,000) * 256 = 40,000,000 + 1,536,000 = 41,536,000

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-19

Example: EIGRP Metrics Calculation Router R1 has two paths to reach networks behind router R4. The bandwidths (in kb/s) and the delays (in tens of microseconds) of the various links are also shown in the figure. The least bandwidth along the top path (R1 > R2 > R3 > R4) is 64 kb/s. The EIGRP bandwidth calculation for this path is as follows: Bandwidth = (107 / least bandwidth in kb/s) * 256 Bandwidth = (10,000,000 / 64) * 256 = 156,250 * 256 = 40,000,000 The delay through the top path is as follows: Delay = [(delay R1

R2) + (delay R2

R3) + (delay R3

R4)] * 256

Delay = [2000 + 2000 + 2000] * 256 Delay = 1,536,000 Therefore, the EIGRP metric calculation for the top path is as follows: Metric = bandwidth + delay Metric = 40,000,000 + 1,536,000 Metric = 41,536,000

2-22

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Example: EIGRP Metrics Calculation (Cont.) Path 2: R1 > R5 > R6 > R7 > R4 – Least bandwidth = 256 [kb/s] – Total delay = 2,000 + 2,000 + 2,000 + 2,000 [tens of microseconds] – Metric = (1 * 107 / 256) * 256 + 1 * (2,000 + 2,000 + 2,000 + 2,000) * 256 = 10,000,000 + 2,048,000 = 12,048,000

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-20

The least bandwidth along the lower path (R1 R5 R6 EIGRP bandwidth calculation for this path is as follows:

R7

R4) is 256 kb/s. The

Bandwidth = (107 / least bandwidth in kb/s) * 256 Bandwidth = (10,000,000 / 256) * 256 = 10,000,000 The delay through the lower path is as follows: Delay = [(delay R1 256

R5) + (delay R5

R6) + (delay R6

R7) + (delay R7

R4)] *

Delay = [2000 + 2000 + 2000 + 2000] * 256 Delay = 2,048,000 Therefore, the EIGRP metric calculation for the lower path is as follows: Metric = bandwidth + delay Metric = 10,000,000 + 2,048,000 Metric = 12,048,000 Router R1 therefore chooses the lower path, with a metric of 12,048,000 over the top path, with a metric of 41,536,000. Router R1 installs the lower path, with a next-hop router of R5 and a metric of 12,048,000, in the IP routing table. The bottleneck along the top path, the 64-kb/s link, can explain why the router takes the lower path. This slow link means that the rate of transfer to Router R4 can be at a maximum of 64 kb/s. Along the lower path, the lowest speed is 256 kb/s, meaning the throughput rate can be as high as that speed. Therefore, the lower path represents a better choice, for example, for moving large files quickly.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-23

Planning and Documenting for EIGRP This topic describes how to plan, implement, and document the EIGRP deployment.

Planning for EIGRP Assess the requirements and options: – IP addressing plan – Network topology Primary versus backup links WAN bandwidth utilization Define hierarchical network design Evaluate EIGRP scaling options – Summarization: where necessary – EIGRP stub

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-21

The EIGRP routing protocol implementation depends on specific needs and topologies. When preparing to deploy EIGRP routing in a network, the existing state and requirements first need to be gathered and different deployment options considered: The IP addressing plan determines how EIGRP can be deployed and how well the EIGRP deployment might scale. Thus, a detailed IP addressing plan along with IP subnetting information must be collected. A solid IP addressing plan should enable the usage of EIGRP summarization, making it easier to scale the network and optimize EIGRP behavior. A network topology consists of links connecting the network equipment (routers, switches, and so on). A detailed network topology plan should be presented, in order to assess EIGRP scalability requirements and determine which EIGRP features might be required (for example EIGRP stub routing). EIGRP can be used to employ traffic engineering, which helps with efficient bandwidth utilization and enables the administrator to have control over the traffic patterns. By changing the interface metrics, EIGRP traffic engineering can be deployed to improve bandwidth utilization.

2-24

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP Implementation Plan Verify and configure IP addressing Enable EIGRP using the correct AS number Define networks to include per router Define a special metric to influence path selection Router R1 Networks 10.1.1.0

Router

Link

Metric

R1

Fa0

Bandwidth = 10 Mb/s

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-22

Once you have assessed the requirements, you can create the implementation plan. The information necessary to implement EIGRP routing is: The IP addresses (or, more precisely, the networks) that need to be included and advertised by EIGRP The correct autonomous system (AS) number used to enable the EIGRP process, which must be the same on the routers in the EIGRP domain. A list of routers where EIGRP must be enabled, along with the connected networks that need to be advertised (per individual router) A listing in the table of any specific metric that needs to be applied to certain interfaces in order to deploy EIGRP traffic engineering, along with the interface where the metric needs to be applied When an implementation plan is created, a list of tasks for each router in the network must be defined: Enable the EIGRP routing protocol. Configure the proper network statements based on the information collected. You can also apply the metric to proper interfaces, if you wish. After implementation, you should confirm that EIGRP is deployed properly on each router: Verify the setup of the EIGRP neighbor relationship or relationships. Verify that the EIGRP topology table is populated with the necessary information. Verify that the IP routing table is populated with the necessary information. Verify that there is connectivity in the network. Verify that EIGRP behaves as expected when the topology changes (test link failure and router failure events). © 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-25

Documenting EIGRP Documenting EIGRP – Topology—use topology map – AS numbering and IP addressing – Networks included in EIGRP per routers – Non-default metric applied

Router R1 networks Router R2 10.1.1.0 networks 10.1.2.0 Router R3 10.2.1.0 networks ... 10.2.2.0 10.3.1.0 ... 10.3.2.0

Router

Link

Metric

R1

Fa0

Bandwidth = 10 Mb/s

R2

Serial1

Delay = 100

R2

Serial2

Delay = 200

R2

Tunnel

Bandwidth = 2 Mb/s

...

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-23

After a successful EIGRP deployment, you should document the solution in order to keep the information about the deployment available for future reference. The implementation plan itself is only half of the information. In order to complete the documentation, you must include the verification process and its results, as well.

2-26

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Implementing Basic EIGRP This topic describes how to plan and implement the basic EIGRP configuration.

Example: Planning for Basic EIGRP Define the network requirements Gather the required parameters Define EIGRP routing Configure basic EIGRP Verify EIGRP configuration

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-24

For the example in the figure above, prepare an implementation plan to configure basic EIGRP and proceed with the configuration. When you plan for the basic EIGRP configuration, you must ensure that your plan includes the: Define the network requirements Gather the required parameters Define the EIGRP routing Configure the basic EIGRP Verify the EIGRP configuration

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-27

Requirements for Basic EIGRP Configuration EIGRP routing protocol AS number Interfaces for EIGRP neighbor relationship Networks participating in EIGRP Interface bandwidth

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-25

The network in the figure consists of three routers. Routers R1 and R2 are in the same EIGRP autonomous system (AS). Router R3 represents an external network that is not part of the EIGRP AS 110. Requirements for the basic EIGRP configuration are: EIGRP routing protocol AS number: Routers in the same EIGRP domain must have the same AS number, as each EIGRP process must be started with the same AS number. The AS number 110 is used in our example. Interfaces for EIGRP neighbor relationship: Interfaces included in the EIGRP routing protocol will exchange routing updates and other packets between their neighbors. You must define the interfaces to show which networks are part of the EIGRP process. Both routers (R1 and R2) have one serial and one Fast Ethernet interface included in the EIGRP process. IP addressing is defined as listed in the figure. Networks participating in EIGRP: EIGRP routers must advertise their local networks to all neighbors. All the interfaces and their networks must be defined. Both routers (R1 and R2) are advertising directly to connected networks that are part of the EIGRP domain. Interface Bandwidth: Interface bandwidth is changing the metric of the link. In order to influence path selection, interface bandwidth must be defined properly. The real bandwidth on the serial link between routers R1 and R2 is 512 kb/s and the proper configuration must be applied in order to reflect the real bandwidth. This will result in proper selection of preferred routes in the EIGRP process. Note

2-28

Default bandwidth for a serial interface is 1544 kb/s.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Steps to Configure Basic EIGRP Define EIGRP as a routing protocol Define the attached networks participating in EIGRP Define the interface bandwidth

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-26

Once you have defined all of the required information, an implementation plan showing the following tasks is required to configure a basic EIGRP configuration: Define EIGRP as a routing protocol Define the attached networks participating in EIGRP Define the interface bandwidth

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-29

Define EIGRP as a Routing Protocol Define EIGRP as the routing protocol All routers in the internetwork that must exchange EIGRP routing updates must have the same autonomous system number

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-27

During the first step of a basic EIGRP configuration, you must define EIGRP as a routing protocol. You must specify an AS number that identifies the routes to the other EIGRP routers. Be aware that all routers in the same EIGRP domain must have the same AS number. Use the router eigrp 110 command to configure the EIGRP routing protocol and add any subsequent subcommands belonging to this routing process. This command also identifies the local AS to which this router belongs. AS 110 is used as an example. The command enters router configuration mode. Note

You can configure more than one EIGRP autonomous system on the same router, but you should configure only one EIGRP autonomous system in any single autonomous system.

For more details about the router eigrp command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

2-30

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Define Networks Participating in EIGRP Define the attached networks participating in EIGRP The wildcard-mask is an inverse mask used to determine how to interpret the address. The mask has wildcard bits, where 0 is a match and 1 is “do not care.”

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-28

In order to start sending and receiving EIGRP routing updates, networks of directly connected interfaces must be defined. Only the network statements for interfaces where the router will send and receive updates need to be configured. Use the network 172.16.1.0 0.0.0.255 command in router configuration mode to specify the network for an EIGRP routing process. When the network command is configured for an EIGRP routing process, the router matches one or more local interfaces. The network command matches only local interfaces that are configured with addresses that are within the same subnet as the address that has been configured with the network command. The router then establishes neighbors through the matched interfaces. There is no limit to the number of network statements (network commands) that you can configure on a router. Note

The wildcard mask in the network command is optional. It is an inverse mask used to determine how to interpret the network number. The mask has wildcard bits, where 0 indicates a match and 1 indicates the bits which are not relevant. For example, 0.0.255.255 indicates a match in the first two octets.

For more details about the network (EIGRP) command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-31

Define Interface Bandwidth Define the bandwidth on the serial0/0/1 interface for the purpose of sending routing update traffic

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-29

EIGRP uses the minimum path bandwidth to determine a routing metric. The TCP protocol adjusts the initial retransmission parameters based on the apparent bandwidth of the outgoing interface. Use the bandwidth 512 command in interface configuration mode to specify or change the informational value used for an EIGRP routing process. If you do not change the bandwidth for the interfaces, EIGRP assumes that the default bandwidth on the serial link is the T1. If the link is actually slower, the router might not be able to converge or routing updates might be lost. The bandwidth command sets an informational parameter only; you cannot adjust the actual bandwidth of an interface with this command. For some media, such as Ethernet, the bandwidth is fixed; for other media, such as serial lines, you can change the actual bandwidth by adjusting hardware. For both classes of media, you can use the bandwidth configuration command to communicate the current bandwidth to the higher-level protocols. Note

At higher bandwidths, the value you configure with the bandwidth command is not what is displayed by the show interface command. The value shown is used in EIGRP updates and computing the load.

For generic serial interfaces such as PPP or High-Level Data Link Control (HDLC), set the bandwidth to the line speed. For Frame Relay on point-to-point interfaces, set the bandwidth to the committed information rate (CIR). For Frame Relay multipoint connections, set the bandwidth to the sum of all CIRs, or, if the permanent virtual circuits (PVCs) have different CIRs, then set the bandwidth to the lowest CIR multiplied by the number of PVCs on the multipoint connection. For more details about the bandwidth command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html 2-32

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Example: Basic EIGRP Configuration

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-30

Example: Basic EIGRP Configuration On router R1, EIGRP is enabled in autonomous system 110. The network 172.16.1.0 0.0.0.255 command starts EIGRP on the Fast Ethernet 0/0 interface and allows router R1 to advertise this network. With the wildcard mask used, this command specifies that only interfaces on the 172.16.1.0/24 subnet will participate in EIGRP. However, the full class B network 172.16.0.0 will be advertised, because EIGRP automatically summarizes routes on the major network boundary by default. The network 192.168.1.0 command starts EIGRP on the Serial 0/0/1 interface, and allows router R1 to advertise this network. If you do not use the optional wildcard mask, the EIGRP process assumes that all directly connected networks that are part of the overall major network will participate in the EIGRP routing process, and EIGRP will attempt to establish EIGRP neighbor relationships from each interface that is part of that Class A, B, or C major network. Use the optional wildcard mask to identify a specific IP address, subnet, or network. The router interprets the network number using the wildcard mask to determine which connected networks will participate in the EIGRP routing process. If specifying an interface address, use the mask 0.0.0.0 to match all four octets of the address. An address and wildcard mask combination of 0.0.0.0 255.255.255.255 matches all interfaces on the router. In the example above, router R1 is connected to router R3, which is external to AS 110. Network 172.16.5.0 is used on the link between router R1 and R3, but the statement for network 172.16.1.0 on router R1 is using a wildcard mask and router R1 does not try to form an adjacency with the router R3. Without the wildcard mask, router R1 would send EIGRP packets to the external network (toward router R3), which would waste bandwidth and CPU cycles and provide unnecessary information to the external network. The wildcard mask in the example above tells EIGRP to establish a relationship with EIGRP routers from interfaces that are part of subnet 172.16.1.0/24 only.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-33

Note

2-34

The configuration of router R2 is identical to that of R1 described here. The only difference in terms of the EIGRP configuration is that the advertised network of the Fast Ethernet interface is different. The Fast Ethernet interface of router R2 is using a different subnet on the link.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary EIGRP is an enhanced distance-vector protocol using these four key technologies: – Neighbor discovery and recovery – Reliable transport protocol – DUAL – Protocol-independent modules EIGRP uses various data structures (neighbor and topology tables) for proper operation, which are populated based on DUAL operation and metrics deployed. When planning EIGRP deployment, define the network requirements, gather the required parameters, and define the EIGRP routing. Basic EIGRP configuration requires the definition of EIGRP as a routing protocol, attached networks participating in EIGRP, and interface bandwidth for path manipulation. © 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

RO UTE v 1.0—2-31

Implementing an EIGRP-Based Solution

2-35

2-36

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 2

Implementing and Verifying Basic EIGRP for the Enterprise LAN Architecture Overview To assist in verification, this lesson introduces various Cisco IOS software show commands and defines the key fields in each. For a scalable Enhanced Interior Gateway Routing Protocol (EIGRP) network, configuring manual route summarization at key points on the internetwork is vital when implementing an optimized network configuration. Knowing the correct commands to use when you configure EIGRP helps to ensure that migration to this routing protocol is smooth and quick. Understanding which show command to use when verifying the EIGRP configuration saves valuable time. This lesson also provides advanced configuration options for EIGRP, including route summarization, passive interfaces, and default network origination.

Objectives Upon completing this lesson, you will be able to describe how to verify and implement EIGRP routing. This ability includes being able to meet these objectives: Verify EIGRP routes for IPv4. Verify EIGRP operation for IPv4. Use the passive-interface command with EIGRP. Advertise an IP default network in EIGRP. Determine summary boundaries. Utilize manual route summarization.

Verify EIGRP Routes for IPv4 This topic describes how EIGRP configuration and operation can be verified using the appropriate commands.

EIGRP Deployment

Îďý ·˛¬ »®şż ˝» Úż­¬Ű¬¸ »®˛» ¬đńđ · ° żĽĽ ®»­­ ďéîň ďęňď ňď îë ëňîë ëňîëë ňđ ˙ ·˛¬ »®şż ˝» Í»®·ż´đ ńđńď ľż ˛Ľ©·Ľ ¬¸ ëď î ·° żĽĽ®»­­ ďçîňďęčňďňďđď îëëňîëëňîëëňîîě ˙ ®±« ¬»® » ·ą®° ďď𠲻 ¬©±®µ ďéîň ďęňď ňđ đň đňđň îëë ˛» ¬©±®µ ďçîň ďęčň ďňđ

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

Îîý ·˛¬ »®şż˝ » Úż­ ¬Ű¬¸» ®˛»¬ đńđ ·° żĽĽ® »­­ ďéîňď éňîň î îëë ňîëë ňîëë ňđ ˙ ·˛¬ »®şż˝ » Í»® ·ż´đń đńď ľż˛ Ľ©·Ľ ¬¸ ëďî ·° żĽĽ®»­­ ďçîňďęčňďňďđî îëëňîëëňîëëňîîě ˙ ®±« ¬»® »· ą®° ďď𠲻¬ ©±®µ ďéîňďéňîň đ đňđ ňđňî ëë ˛»¬ ©±®µ ďçîňďęčňď ňđ

ROUTE v1. 0—2-2

Router R1 has EIGRP enabled in autonomous system 110. The network 172.16.1.0 0.0.0.255 command starts EIGRP on the Fast Ethernet 0/0 interface and allows router R1 to advertise this network. With the wildcard mask used, this command specifies that only interfaces on the 172.16.1.0/24 subnet will participate in EIGRP. Note, however, the full class B network 1 72.16.0.0 will be advertised, because EIGRP automatically summarizes routes on the major network boundary by default. The network 192.168.1.0 command starts EIGRP on the Serial 0/0/1 interface and allows router R1 to advertise this network. Router R2 has EIGRP enabled in autonomous system 110. The network 172.17.2.0 0.0.0.255 command starts EIGRP on the Fast Ethernet 0/0 interface and allows router R2 to advertise this network. With the wildcard mask used, this command specifies that only interfaces on the 172.17.2.0/24 subnet will participate in EIGRP. Note, however, the full class B network 172.17.0.0 will be advertised, because EIGRP automatically summarizes routes on the major network boundary by default. The network 192.168.1.0 command starts EIGRP on the serial 0/0/1 interface and allows router R2 to advertise this network.

2-38

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Verifying EIGRP Neighbors

Îď ý­¸±© ·° » ·ą®° ˛»·ą ¸ľ±®­ ×Đ óŰ×ŮÎ Đ ˛»· ą¸ľ± ®­ ş± ® °®± ˝»­­ ďďđ Ř ßĽĽ ®»­­ ײ ¬»®şż ˝» ر´Ľ Ë°¬ ·ł» ÍÎĚĚ ř­»˝ ÷ řł­ ÷ đ ďçî ňďęčň ďňďđ î Í» đńđńď ďđ đđć đéćî î ďđ

Î ĚŃ

Ď Í» Ż Ý ˛¬ Ň« ł î îčđ đ ë

Îî ý­¸± © ·° » ·ą®° ˛»·ą ¸ľ±® ­ ×Đ óŰ×Ů ÎĐ ˛»· ą¸ľ± ®­ ş± ® °® ±˝»­ ­ ďďđ Ř ßĽĽ ®»­­ ײ ¬»®ş ż˝» ر´ Ľ Ë° ¬·ł» ÍÎ ĚĚ ř­» ˝÷ řł ­÷ đ ďçî ňďęč ňďňď đď Í» đńđń ď ďđ đđ ćďéć đî ďđ

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ÎĚŃ

Ď Í »Ż Ý ˛¬ Ň «ł ďíčđ đ ë

ROUTE v1. 0—2-3

Both routers R1 and R2 are configured with the EIGRP routing protocol in autonomous system (AS) 110 and are advertising their networks to the neighbors. Before updates are sent, EIGRP is building the EIGRP neighbor table. The EIGRP neighbor table displays the neighbors discovered by EIGRP, including the IP address and interface on which each neighbor is reachable. The EIGRP neighbor table can be displayed using the show ip eigrp neighbors command. Use this command to determine when neighbors become active or inactive. You can also use it for debugging certain types of transport problems. The outputs of the command in the figure list currently used neighbor relationships—router R1 has formed an adjacency with router R2 and vice versa. For more details about the show ip eigrp neighbors command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-39

Verifying EIGRP Neighbors (Cont.) Îďý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ďďđ Ř ßĽĽ®»­­ ײ¬»®şż˝» ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ đ ďçîňďęčňďňďđî Í»đńđńď ďđ đđćđéćîî ďđ

1

2

3

4

5

1.

Neighbor index

2.

Neighbor IP address

3.

Interfac e on which the neighbor is reachable

4.

Remaining hold time

5.

Neighbor uptime

6.

Smooth round-trip time

7.

Retransmission timeout

8.

Number of pac kets to send to neighbor

9.

Last sequence received

6

ÎĚŃ

Ď Í»Ż ݲ¬ Ň«ł îîčđ đ ë

7

8

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

9

ROUTE v1. 0—2-4

This output of the show ip eigrp neighbors command includes the following key elements: 1. H (handle): This column lists the order in which a peering session was established with the specified neighbor. The order is specified with sequential numbering starting with 0. 2. Address: This column contains the IP address of the EIGRP peer. 3. Interface: This column contains the interface on which the router is receiving hello packets from the peer. 4. Hold Time: This column contains the length of time (in seconds) that the Cisco IOS software will wait to hear from the peer before declaring it down. If the peer is using the default hold time, this number will be less than 15. If the peer is configured with a nondefault hold time, the non-default hold time will be displayed. Originally, the expected packet was a hello packet, but with current Cisco IOS software releases, any EIGRP packet received after the first hello from that neighbor resets the timer. 5. Uptime: This is the elapsed time (in hours: minutes: seconds) since the local router first heard from this neighbor. 6. Smooth Round Trip Timer (SRTT): The smooth round-trip time is the number of milliseconds required for an EIGRP packet to be sent to this neighbor and for the local router to receive an acknowledgment of that packet. This timer is used to determine the retransmit interval, also known as the retransmit timeout (RTO). 7. Retransmission timeout (RTO): This is the amount of time (in milliseconds) the software waits before resending a packet from the retransmission queue to a neighbor. 8. Queue count: This is the number of EIGRP packets (update, query, and reply) that the software is waiting to send. If this value is consistently higher than 0, a congestion problem might exist. A 0 indicates that no EIGRP packets are in the queue. 9. Seq Num: This is the sequence number of the last update, query, or reply packet that was received from this neighbor. 2-40

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Verifying EIGRP Neighbors (Cont.) Total retransmission count

Current retry count

Îďý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ Ľ»¬ż·´ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ďďđ Ř ßĽĽ®»­­ ײ¬»®şż˝» ر´Ľ Ë°¬·ł» ÍÎĚĚ ÎĚŃ Ď Í»Ż ř­»˝÷ řł­÷ ݲ¬ Ň«ł đ ďçîňďęčňďňďđî Í»đńđńď ďě đđćďéćëë đ ěëđđ í îéě Ôż­¬ ­¬ż®¬«° ­»®·ż´ ëęç Ę»®­·±˛ ďîňěńďňđô 묮ż˛­ć îô 묮·»­ć îô Éż·¬·˛ą ş±® ײ·¬ ß˝µ ËĐÜßĚŰ ­»Ż íđé ­»® îçóëęç Í»˛¬ čçîě ײ·¬ Í»Ż«»˛˝»Ľ ËĐÜßĚŰ ­»Ż íďđ ­»® ëéđóëéí Í»Ż«»˛˝»Ľ ËĐÜßĚŰ ­»Ż íďî ­»® ëéěóëéč Í»Ż«»˛˝»Ľ Neighbor version of Cisco IOS

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

Current pending packets

ROUTE v1. 0—2-5

Detailed neighbor information can be examined with the show ip eigrp neighbor detail command. The command also reveals how many times a retransmission has occurred, the current retry count (router R1 in the figure has the value 2 for the retry count), the packets that are currently waiting to be sent (you can see that router R1 has three updates waiting to be sent), and the Cisco IOS version on the neighboring router For more details about the show ip eigrp neighbors detail command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-41

Verifying EIGRP Routes Network EIGRP route type

AD / Metric

Next hop

Route age

Îďý­¸±© ·° ®±«¬» »·ą®° Ü ďéîňďéňđňđńďę ĹçđńěđëďěëęđĂ Ş·ż ďçîňďęčňďňďđîô đđćđéćđďô Í»®·ż´đńđńď ďéîňďęňđňđńďę ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ô î łż­µ­ Ü ďéîňďęňđňđńďę ·­ ż ­«łłż®§ô đđćđëćďíô Ň«´´đ ďçîňďęčňďňđńîě ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ô î łż­µ­ Ü ďçîňďęčňďňđńîě ·­ ż ­«łłż®§ô đđćđëćďíô Ň«´´đ

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-6

If you run the show ip route command, the output will contain all of the routes in the routing table. To verify only EIGRP routes for any neighbors the router recognizes, use the show ip route eigrp command. EIGRP supports several route types: EIGRP routes from the local AS (D), EIGRP routes from the external AS (EX), and summary routes. EIGRP routes in the router’s R1 routing table above are identified with a D in the left column; any external EIGRP routes (from outside of this autonomous system) would be identified with an EX. After the network number, there is a field that looks similar to [90/40514560]. The numbers may be different from the one in the example. The first number, 90 in the example above, is the administrative distance. It is used to select the best path when a router learns two or more routes from different routing sources. For example, consider that this router also uses Routing Information Protocol (RIP), and RIP has a route to network 172.17.0.0 that is three hops away. The router, without administrative distance, cannot compare the three hops for RIP to an EIGRP metric of 40514560. The router does not know the bandwidth associated with the hops and EIGRP does not use a hop count as a metric. To avoid problems like this, Cisco established an administrative distance value for each routing protocol; the lower the value, the more preferred the route is. By default, EIGRP internal routes have an administrative distance of 90 and RIP has an administrative distance of 120. Because EIGRP has a metric based upon bandwidth and delays, it is preferred over the RIP hop count. As a result, in this example, the EIGRP route is installed in the routing table. The second number in the brackets is the EIGRP metric. Recall that the default EIGRP metric is the least-cost bandwidth plus the accumulated delays. The EIGRP metric for a certain network is the same as its feasible distance (FD) in the EIGRP topology table. The next field, “via 192.168.1.102” in the example above, identifies the address of the next-hop router to which this router passes the packets for the destination network 172.17.0.0/16. The next-hop address in the routing table is the same as the successor in the EIGRP topology table.

2-42

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Each route also has a time associated with it: the length of time, perhaps days or months, since EIGRP last advertised this network to this router. EIGRP does not refresh routes periodically; it resends the routing information only when neighbor adjacencies change. The next field in the output is the interface (serial 0/0/1 in this case) from which packets for 172.17.0.0 are sent. Notice that the routing table includes routes to null0 for the advertised routes. The Cisco IOS software automatically inserts these routes in the table. They are called summary routes. Null0 is a directly connected, software-only interface. The use of the null0 interface prevents the router from trying to forward traffic to other routers in search of a more precise, longer match. For example, if the router in the figure receives a packet to an unknown subnet that is part of the summarized range (such as 172.16.3.5) the packet matches the summary route based on the longest match. The packet is forwarded to the null0 interface (in other words, it is dropped, or sent to the bit bucket) which prevents the router from forwarding the packet to a default route and possibly creating a routing loop. For more details about the show ip route command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-43

Verifying EIGRP Operation Î ďý­¸ ±© ·° °®±¬±˝±´ ­ Î ±«¬· ˛ą Đ®± ¬±˝±´ ·­ ţ»·ą ®° ďď đţ Ń«¬ą ±·˛ą «°Ľż ¬» ş· ´¬»® ´·­¬ ş±® ż´´ ·˛¬»® şż˝» ­ ·­ ˛±¬ ­ »¬ ײ˝± ł·˛ą «°Ľż ¬» ş· ´¬»® ´·­¬ ş±® ż´´ ·˛¬»® şż˝» ­ ·­ ˛±¬ ­ »¬ Ü»şż «´¬ ˛ »¬©± ®µ­ ş ´żąą »Ľ ·˛ ±«¬ ą±·˛ą «°Ľż ¬»­ Ü»şż «´¬ ˛ »¬©± ®µ­ ż ˝˝»° ¬»Ľ ş ®±ł ·˛˝±ł ·˛ą « °Ľż¬ »­ Ű×ŮÎ Đ ł»¬ ®·˝ © »·ą¸ ¬ Őď ăďô Ő îăđô Őíăď ô Őěă đô Őë ăđ Ű×ŮÎ Đ łż¨ ·ł«ł ¸±°˝ ±«˛¬ ďđđ Ű×ŮÎ Đ łż¨ ·ł«ł ł»¬® ·˝ Ş ż®·ż ˛˝» ď λĽ· ­¬®· ľ«¬· ˛ąć »· ą®° ďďđ Ű×ŮÎ Đ ŇÍÚ óż©ż ®» ®± «¬» ¸±´Ľ ¬·ł» ® ·­ îěđ­ ä ±«¬° «¬ ±ł· ¬¬»Ľâ

K values

Load-balancing setting Ó ż¨·ł «ł °ż¬ ¸ć ě ᫬ ·˛ą ş ±® Ň »¬©± ®µ­ć ďé îňďę ňďňđ ńîě Networks being announced ďç îňďę čňďň đ ᫬ ·˛ą × ˛ş±® łż¬· ±˛ ͱ «®˝» ­ć Ůż ¬»©ż § Ü·­¬ ż˛˝» Ôż­¬ Ë°Ľż ¬» ř¬ ¸·­ ® ±«¬» ®÷ çđ đđćđ çćíč Ůż ¬»©ż § Ü·­¬ ż˛˝» Ôż­¬ Ë°Ľż ¬» ďç îňďę čňďň ďđî çđ đđćđ çćěđ EIGRP local AD Ü·­¬ ż˛˝» ć ·˛¬ »®˛ż ´ ç𠻨¬» ®˛ż´ ďéđ © 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-7

To display the parameters and current state of the active routing protocol process, use the show ip protocols command. The sample output in the example above shows that EIGRP process 110 is running. The command output displays any filtering of routing that is occurring on EIGRP outbound or inbound updates. It also identifies if EIGRP is generating a default network or receiving a default network in EIGRP updates. The command output provides information about additional default settings for EIGRP, such as default K values, hop count, and variance. Note

Because the routers must have identical K values for EIGRP to establish an adjacency, you should run the show ip protocols command to determine the current K value setting before attempting an adjacency.

This sample output also indicates that automatic summarization is enabled (this is the default setting) and that the router is allowed to load-balance over a maximum of four paths. (The Cisco IOS software allows configuration of up to six paths for equal-cost load balancing, using the maximum-path configuration command.) The networks that the router is routing are also displayed. As shown in the figure, the format of the output varies, depending on the use of the wildcard mask in the network command. If a wildcard mask is used, the network address is displayed with a prefix length. If a wildcard mask is not used, the Class A, B, or C major network is displayed. The routing information sources section of this command output identifies all other routers that have an EIGRP neighbor relationship with this router.

2-44

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

The show ip protocols command output also provides the two administrative distances. First, an administrative distance of 90 applies to networks from other routers inside the autonomous system; these are considered internal networks. Second, an administrative distance of 170 applies to networks introduced to EIGRP for this autonomous system through redistribution; these are called external networks. The source of the external routes is not inside the autonomous system. For more details about the show ip protocols command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-45

Verifying EIGRP Operation (Cont.) Îďý­¸ ±© ·° »·ą®° ·˛¬ »®şż ˝»­ ×ĐóŰ× ŮÎĐ · ˛¬»®ş ż˝»­ ş±® °®±˝ »­­ ď ďđ Čł·¬ Ď«»« » ײ¬»® şż˝» Đ»» ®­ ˲ńÎ »´·ż ľ´» Úżđńđ đ đ ńđ Í»đńđ ńď ď đ ńđ

Ó »ż˛ Í ÎĚĚ đ ďđ

Đż˝ ·˛ą Ě ·ł» ˲ńλ´·ż ľ´» đńďđ ďđńíč đ

Ó«´ ¬·˝ż ­¬ Ú´± © Ě·ł »® đ ěîě

Đ»˛ Ľ·˛ą α« ¬»­ đ đ

Peer count Route status

Next hop

Îďý­ ¸±© ·° »·ą ®° ¬± °±´± ą§ ×ĐóŰ ×ŮÎĐ Ě ±°±´ ±ą§ Ě żľ´» ş±® ßÍřď ďđ÷ń× Üřďç îňďę čňďňďđď÷ ݱĽ» ­ć Đ ó Đż­ ­·Ş» ô ß ó ß˝¬ ·Ş»ô Ë ó Ë °Ľż¬» ô Ď ó Ď«» ®§ô Î ó Î »°´§ ô ® ó ®»° ´§ ͬ ż¬«­ ô ­ ó ­·ż ͬż¬ «­ Feasible Đ ďçî ňďęč ňďňç ęńîé ô ď ­« ˝˝»­ ­±®­ô ÚÜ · ­ ěđë ďîđđ đ distance Ş· ż ݱ ˛˛»˝ ¬»Ľô Í»®· ż´đńđ ńď Đ ďçî ňďęč ňďňđ ńîěô ď ­«˝ ˝»­­ ±®­ô ÚÜ ·­ ěđëď îđđđ Advertised Ş· ż Í« łłż® § řěđ ëďîđ đđńđ÷ ô Ň«´ ´đ distance Đ ďéî ňďęň đňđń ďęô ď ­«˝˝ »­­± ®­ô Ú Ü ·­ îčďęđ Ş· ż Í« łłż® § řîč ďęđń đ÷ô Ň «´´đ Đ ďéî ňďęň ďňđń îěô ď ­«˝˝ »­­± ®­ô Ú Ü ·­ îčďęđ Outgoing Ş· ż ݱ ˛˛»˝ ¬»Ľô Úż­¬ ۬¸»® ˛»¬đ ńđ interface Đ ďéî ňďéň đňđń ďęô ď ­«˝˝ »­­± ®­ô Ú Ü ·­ ěđëďě ëęđ Ş· ż ďç îňďę čňďň ďđî řě đëďě ëęđńî čďęđ ÷ô Í»® ·ż´đ ńđńď

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-8

The show ip eigrp interfaces command displays information about interfaces configured for EIGRP. Use this command to determine which interfaces EIGRP is active on, and to learn information about EIGRP for interfaces. As shown in this sample output, the following key elements are included in the output: Interface: Interface over which EIGRP is configured Peers: Number of directly connected EIGRP neighbors Xmit Queue Un/Reliable: Number of packets remaining in the Unreliable and Reliable transmit queues Mean SRTT: Mean smooth round-trip time (SRTT) interval (in seconds). Pacing Time Un/Reliable: Pacing time used to determine when EIGRP packets should be sent out of the interface (unreliable and reliable packets) Multicast Flow Timer: Maximum number of seconds in which the router will send multicast EIGRP packets Pending Routes: Number of routes in the packets sitting in the transmit queue waiting to be sent To verify EIGRP operations further, you can use the show ip eigrp topology command. Use this command to determine the Diffusing Update Algorithm (DUAL) states and to debug any possible DUAL problems. If this command is used without any keywords or arguments, only routes that are feasible successors are displayed. The sample output above shows that Router R1 has an ID of 192.168.1.101 and resides in the autonomous system 110 (the EIGRP ID is the highest IP address on an active interface for this router). The command output lists the networks known by this router through the EIGRP routing process. The codes in the command output showing the state of this topology table entry are defined as follows:

2-46

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Passive (P): This network is available and installation can occur in the routing table. Passive is the correct state for a stable network. Passive state is an indication that no EIGRP computations are being performed for this destination. Active (A): This network is currently unavailable and installation cannot occur in the routing table. A network in an active state has outstanding queries. Active state is an indication that EIGRP computations are being performed for this destination. Update (U): This code applies if a network is being updated (an update packet is being sent to this destination). This code also applies if the router is waiting for an acknowledgment for an update packet. Query (Q): This code applies if there is an outstanding query packet for this network and the network is not in the active state. The code indicates that a query packet was sent to this destination. This code also applies if the router is waiting for an acknowledgment for a query packet. Reply (R): This code applies if the router is generating a reply for this network or is waiting for an acknowledgment for a reply packet. This code indicates that a reply packet was sent to this destination. Stuck-in-active (SIA) status: This code signifies an EIGRP convergence problem for the network with which the route is associated. The number of successors available for a route is indicated in the command output, as well. In this example, all networks have one successor. If there were equal-cost paths to the same network, a maximum of six paths would be shown. The number of successors corresponds to the number of best routes with equal cost. For each network, the FD is displayed, followed by the next-hop address and then a field similar to “(40514560/28160)” in the figure. The first number in this field is the FD for that network through this next-hop router. The second number is the advertised distance (AD) from the next-hop router to the destination network. For more details about the show ip eigrp interfaces and show ip eigrp topology commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-47

Verifying EIGRP Operation (Cont.) Îďý­¸±© ·° »·ą®° ¬®żşş·˝ ×ĐóŰ×ŮÎĐ Ě®żşş·˝ ͬż¬·­¬·˝­ ş±® ßÍ ďďđ Ř»´´±­ ­»˛¬ń®»˝»·Ş»Ľć ěîçńďçî EIGRP packet counters Ë°Ľż¬»­ ­»˛¬ń®»˝»·Ş»Ľć ěńě Ď«»®·»­ ­»˛¬ń®»˝»·Ş»Ľć ďńđ λ°´·»­ ­»˛¬ń®»˝»·Ş»Ľć đńď ß˝µ­ ­»˛¬ń®»˝»·Ş»Ľć ěńí ײ°«¬ Ż«»«» ¸·ą¸ ©ż¬»® łż®µ ďô đ Ľ®±°­ Í×ßóĎ«»®·»­ ­»˛¬ń®»˝»·Ş»Ľć đńđ Í×ßóλ°´·»­ ­»˛¬ń®»˝»·Ş»Ľć đńđ Ř»´´± Đ®±˝»­­ ×Üć ďďí ĐÜÓ Đ®±˝»­­ ×Üć éí

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-9

To examine the number of various EIGRP packets sent and received, use the show ip eigrp traffic command, as illustrated in the figure. You can see that router R1 has sent 429 and received 192 hello messages, sent 4 and received 4 update messages, sent 1 query message and received 0 query messages, sent 0 reply messages and received 1 reply message, and sent 4 ACK messages and received 3 ACK messages. For more details about the show ip eigrp traffic command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

2-48

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Using the Passive-Interface Command with EIGRP This topic describes how to control routing updates using the passive-interface command.

Using Passive Interfaces EIGRP announces the directly connected network of an interface EIGRP does not try to form neighbor relationships over the interface where only the host is connected – Reduces traffic overhead

No peer here Îďý

No peer here Îîý

®±«¬ »® »·ą®° ď ďđ °ż­­ ·Ş»ó ·˛¬»®şż˝» Úż­¬Ű ¬¸»® ˛»¬đ ń𠲻¬© ±®µ ď éîňď ęňďňđ đňđň đňîë ë ˛»¬© ±®µ ď çîňď ęčňďň đ

®±«¬» ® »·ą®° ďď đ °ż­­ ·Ş»ó· ˛¬»® şż˝» Ú ż­¬Ű ¬¸»® ˛»¬đ ń𠲻¬© ±®µ ď éîňďé ňîňđ đňđň đňîë ë ˛»¬© ±®µ ď çîňďę čňďň đ

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-10

Routers R1 and R2 have no neighbors available over the FastEtehrent0/0 interfaces, thus there is no need to try to establish adjacency over the interfaces. Moreover, the packets sent are overhead to the link bandwidth and also consume CPU resources of the router. In order to stop sending hello packets over the interface without neighbors, use the passive-interface command on the specified interface. In the above example, the passive-interface command is used in both routers for the Fast Ethernet interface 0/0. EIGRP will not bring up adjacencies on a passive interface, regardless of whether the neighbor command is configured. Note

Configuring the passive-interface command suppresses all incoming and outgoing routing updates and hello messages.

The passive-interface command has the following properties: Prevents a neighbor relationship from being established over the passive interface Stops routing updates from being received or sent over the passive interface Allows a subnet on the passive interface to be announced in an EIGRP process For more details about the passive-interface command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-49

Using Passive Interfaces (Cont.) No need to talk to host by EIGRP Disables EIGRP on all interfaces by default Enables EIGRP only on selected interfaces

Îďř˝±˛ş·ą÷ý ®±«¬ »® »·ą®° ď ďđ °ż­­ ·Ş»ó ·˛¬»®şż˝» Ľ»şż« ´¬ ˛± ° ż­­· Ş»ó·˛¬»®ş ż˝» Í» ®·ż´ đńđń ď ˛»¬© ±®µ ď éîňď ęňďňđ đňđň đňîë ë ˛»¬© ±®µ ď çîňď ęčňďň đ © 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-11

Within ISPs and large enterprise networks, distribution routers may have more than 100 interfaces, so manual configuration of the passive-interface command on interfaces where adjacency is not desired may create a problem. In some networks, this means entering 100 or more passive interface statements. With the default passive interface feature, this issue is solved by allowing all interfaces to be set as passive by default using a single passive-interface default command. Where adjacencies are desired, the individual interfaces are configured using the no passive-interface command. In the example above, routers R1 and R2 are configured with the passive-interface default command and all interfaces are refusing the establishment of EIGRP adjacency by default. The Serial 0/0/1 interface on each router is then configured to allow EIGRP adjacency as neighbors are expected. The passive-interface command is disabled for these interfaces.. For more details about the passive-interface default command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

2-50

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Verify Operation with Passive Interfaces

Îď ý­¸ ·° °®± ¬±˝±´­ α «¬·˛ ą Đ®±¬ ±˝±´ ·­ ţ »·ą®° ďďđţ ä± «¬°« ¬ ±ł·¬ ¬»Ľâ ß «¬±ł ż¬·˝ ˛»¬© ±®µ ­ «łłż® ·¦ż¬ ·±˛ ·­ ·˛ »şş» ˝¬ ß «¬±ł ż¬·˝ żĽĽ® »­­ ­ «łłż® ·¦ż¬ ·±˛ć ďéî ňďęň đňđńď ę ş±® Í»®· ż´đń đńď Í« łłż® ·¦·˛ ą ©·¬ ¸ ł»¬ ®·˝ î čďęđ Ó ż¨·ł «ł °ż ¬¸ć ě Î ±«¬· ˛ą ş± ® Ň» ¬©±®µ ­ć ďéî ňďęň ďňđńî ě ďçî ňďęč ňďňđ Đ ż­­· Ş» ײ ¬»®ş ż˝»ř­ ÷ć Úż­ ¬Ű¬¸ »®˛»¬ đńđ ä± «¬°« ¬ ±ł·¬ ¬»Ľâ

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-12

The main questions to ask when verifying operation with passive interfaces are: Do we see all the neighbors? Which interfaces in the routing process are passive? To see all of the EIGRP neighbors available, use the show ip eigrp neighbors command. To see the passive interfaces in the routing protocol, use show ip protocols command. The command output above for router R1 shows that interface FastEthernet 0/0 is defined as a passive interface. For more details about the show ip protocols command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-51

Advertising an IP Default Network in EIGRP This topic describes the ip default-network command that is used to configure the last resort gateway or default route.

Using the ip default network Command with EIGRP Default routes decrease the size of the routing table Multiple candidates: – 0.0.0.0 is statically set or advertised by the routing protocol – Any EIGRP major network route is flagged as a candidate default with the ip default-network command

EIGRP solution: Flags network as a default route candidate Multiple default candidates supported – Announced with the Exterior flag

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-13

The major purpose of using default routes is to decrease the size of the routing table. This especially applies to stub networks or networks at the access layer (generally, it applies to all networks that are on lower hierarchical layers). The router, before installation of a default route, first collects default route candidates. The candidate can be a statically configured default route with the following command: ip route 0.0.0.0 0.0.0.0 next-hop | interface. In this command, interface is an outgoing interface through which all packets with unknown destinations will be forwarded, and nexthop is an IP address to which packets with unknown destinations will be forwarded. Any major network residing in the local routing table can become a candidate to use the ip default-network command. The command is also used to attach an Exterior flag to any major EIGRP or IGRP route, thus making it a candidate for a default route. Note

In EIGRP, no default routes can be directly injected (as in the OSPF environment with the default-information originate command).

The router examines all the default candidates and selects the best one based on the administrative distance and route metric. When selected, the router sets the gateway of last resort to the next hop of the selected candidate. This does not apply when the best candidate happens to be one of the directly connected routes.

2-52

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Note

Any route residing in a routing table can be marked as a default candidate even if the route is not an EIGRP route.

Using the ip default network Command with EIGRP (Cont.) Flagging an external network as a default route candidate

Îîý ®±« ¬»® »· ą®° ďď𠲻¬ ©±®µ ďđňđ ňđňđ ·° Ľ »şż« ´¬ó˛»¬©±® µ ďéîň íďňđ ňđ ·° ® ±«¬» ďéîň íďňđň đ îëë ňîëë ňđňđ ďéîň íďňď ňď

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-14

The EIGRP default route can be created with the ip default-network command. A router configured with this command considers the network listed in the command as the last-resort gateway that it will announce to other routers. The network specified by this command must be reachable by the router that uses this command before it announces it as a candidate default route to other EIGRP routers. The network specified by this command must also be passed to other EIGRP routers so that those routers can use this network as their default network and set the gateway of last resort to this default network. This means that the network must either be an EIGRP-derived network in the routing table or be generated using a static route, which has been redistributed into EIGRP. Note

Multiple default networks can be configured; downstream routers use the EIGRP metric to determine the best default route.

Router R2 is has access to the external network 172.31.0.0/16 via its serial interface. The static route is configured in order to provide reachability, as routers R2 and R3 are not exchanging routing updates. Router R2 is configured with the 172.31.0.0 network as a candidate default network using the ip default-network 172.31.0.0 command. This network is passed to router R1. For more details about the ip default-network command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-53

Verifying Default Network Information

Îîý­¸±© ·° ®±«¬»

Flagged candidate Flagged candidate

đňđňđňđ Ş·ż Í»®·ż´đńđńđ 䱫¬°«¬ ±ł·¬¬»Ľâ Íö đňđňđňđńđ ĹďńđĂ Ş·ż ďéîňíďňďňď Ý ďéîňíďňďňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđ Ý ďđňęěňđňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ

Îďý­¸±© ·° ®±«¬» 䱫¬°«¬ ±ł·¬¬»Ľâ Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ďđňęěňđňî ¬± ˛»¬©±®µ đňđňđňđ ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­ 䱫¬°«¬ ±ł·¬¬»Ľâ Ý ďđňęěňđňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ Üö ďéîňíďňđňđńďę ĹçđńďđëďěëęđĂ Ş·ż ďđňęěňđňîô đđćđéćđďô Úż­¬Ű¬¸»®˛»¬đńđ © 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-15

Routers R1 and R2 are configured for EIGRP and router R2 has a configuration using the ip default-network command. In order to verify the processing of the default routes and default candidates, you must look at the IP routing tables on both of the routers. The 172.31.0.0 network is passed from router R2 to router R1. The ip default-network command does not benefit router R2 directly. On router R1, the EIGRP-learned 172.31.0.0 network is flagged as a candidate default network (as indicated by the * in the routing table). Router R1 also sets the gateway of last resort to 10.64.0.2 (toward router R2) to reach the default network of 172.31.0.0. Note

2-54

When you configure the ip default-network command, a static route (the ip route command) is generated in the router’s configuration; however, the Cisco IOS software does not display a message to indicate that this has been done. The entry appears as a static route in the routing table of the router in which the command is configured, as can be seen in router R1’s configuration and routing table in the figure. This can be confusing if you want to remove the default network. The configuration must be removed with the no ip route command.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Determining Summary Boundaries This topic explains why administrators may need to use manual route summarization over default automatic route summarization.

Route Summarization Improves network scalability – Smaller routing tables – Fewer updates Should follow IP addressing

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-16

To reduce routing overhead and improve stability and scalability of routing, you can use route aggregation (summarization). However, to implement route aggregation, you must divide the network into contiguous IP address areas. This requires you to have a solid understanding of IP address assignment on route aggregation and hierarchical routing. The purpose of route summarization is to squeeze several subnets into one aggregate entry that covers all of them. Summarization results in smaller routing tables and smaller updates. Consequently, it also results in less routing traffic and lower CPU utilization (minor changes in the network go unnoticed).

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-55

EIGRP Automatic Route Summarization Performed on major network boundaries – Subnetworks are summarized to a single classful (major) network. – Automatic summarization occurs by default. Could result in routing issues—disable auto summarization

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-17

Some EIGRP features (such as automatic route summarization routes at major network boundaries) are characteristics of distance vector operation. Traditional distance vector protocols, which are classful routing protocols, cannot assume the mask for networks that are not directly connected, because routing updates do not exchange masks. EIGRP automatically summarizes routes at the classful boundary. In some cases, you may not want automatic summarization to occur. For example, if you have discontiguous networks, you need to disable automatic summarization to minimize router confusion. Note

2-56

Automatic summarization is enabled by default for EIGRP.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP Manual Route Summarization Configurable on a per-interface basis in any router within a network. Summarization results in a route pointing to null0. – Loop prevention mechanism When the last specific route of the summary goes away, the summary is deleted. The minimum metric of the specific routes = metric of the summary route.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-18

A drawback to using distance vector protocols is that you cannot create summary routes at arbitrary boundaries within a major network. The ability to summarize routes is desirable, because it allows you to keep smaller routing tables. EIGRP allows administrators to disable automatic summarization and create one or more summary routes within the network on any bit boundary, as long as a more specific route exists in the routing table. When the last specific route of the summary goes away, the summary is deleted from the routing table. The minimum metric of the specific routes is used as the metric of the summary route. Recall that Cisco IOS software automatically inserts summary routes to interface null0 in the routing table for automatically summarized routes, to prevent routing loops. For the same reason, Cisco IOS software also creates a summary route to interface null0 when manual summarization is configured. For example, if the summarizing router receives a packet to an unknown subnet that is part of the summarized range, the packet matches the summary route based on the longest match. The packet is forwarded to the null0 interface (in other words, it is dropped), which prevents the router from forwarding the packet to a default route and possibly creating a routing loop. For manual summarization to be effective, blocks of contiguous addresses (subnets) must come together at a common router so that the router can advertise a single summary route. The number of subnets that can be represented by a summary route is directly related to the difference in the number of bits between the subnet mask and the summary mask. The formula 2n, where n equals the difference in the number of bits between the summary and subnet mask, indicates how many subnets can be represented by a single summary route. For example, if the summary mask contains three fewer bits than the subnet mask, eight (23 = 8) subnets can be aggregated into one advertisement. For example, if network 10.0.0.0 is divided into /24 subnets and is summarized to the summarization block 10.1.8.0/21, the difference between the /24 networks and the /21 summarizations is 3 bits; therefore, 23 = 8 subnets can be aggregated. The summarized subnets range from 10.1.8.0/24 through 10.1.15.0/24. © 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-57

When configuring summary routes, the administrator needs to specify the IP address of the summary route and the summary mask. The Cisco IOS software for EIGRP handles many of the details that surround proper implementation, including details about metrics, loop prevention, and removal of the summary routes from the routing table if none of the more specific routes are valid.

2-58

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Utilizing Manual Route Summarization This topic explains why administrators may need to use manual route summarization over default automatic route summarization.

Configuring Route Summarization Creating a summary route for 172.16.0.0/16

Îďř˝±˛ş·ą÷ý ®±«¬ »® »·ą ®° ď ď𠲻¬© ±®µ ď đňđň đň𠲻¬© ±®µ ď éîňď ęňđň 𠲱 ż «¬±ó ­«łł ż®§

Îîř˝±˛ş·ą÷ý ®± «¬»® »·ą®° ďďđ ˛ »¬©±® µ ďđň đňđň đ ˛ »¬©±® µ ďéî ňďęň đňđ ˛ ± ż«¬ ±ó­« łłż® § © 2009 Cis co S y st em s, Inc. A ll right s reserved.

Îíř˝±˛ş·ą÷ý · ˛¬»® şż˝» Í »®·ż ´đńđ ńđ ·° żĽ Ľ®»­ ­ ďçî ňďęč ňěňî îëëň îëëňî ëëňđ ·° ­« łłż® §óżĽ Ľ®»­ ­ »·ą®° ďďđ ďéî ňďęňđ ňđ îë ëňîë ëňđň đ ˙ ® ±«¬» ® »·ą® ° ďď𠲻¬©± ®µ ďđ ňđňđ ň𠲻¬©± ®µ ďç îňďę čňěň 𠲱 ż« ¬±ó­ «łłż ®§ RO UTE v 1.0—2-19

EIGRP automatically summarizes routes at the classful boundary. In some cases, you may not want automatic summarization to occur. For example, if you have discontiguous networks, you need to disable automatic summarization to minimize router confusion. To disable automatic summarization, use the no auto-summary EIGRP router configuration command. Note

EIGRP router does not perform automatic summarization of networks in which it does not participate.

A discontiguous network 172.16.0.0 is used in the network on specific router R1 and R2 interfaces. On routers R1 and R2, automatic summarization has been disabled, so the 172.16.1.0 and 172.16.2.0 subnets are advertised into network 10.0.0.0. The routing tables of routers in the 10.0.0.0 network, including router R3, include these discontiguous subnets. An EIGRP router automatically summarizes routes only for networks to which it is attached. If a network is not automatically summarized at the major network boundary, as is the case in this example on routers R1 and R2 because autosummarization is turned off, all the subnet routes are carried into the router R3 routing table. Router R3 will not automatically summarize the 172.16.1.0 and 172.16.2.0 subnets, because it does not own the 172.16.0.0 network. Therefore, router R3 will send routes to the 172.16.1.0 and 172.16.2.0 subnets to the WAN. If you configure a summary route on the router R3 interface serial 0/0/0, as shown in the figure, only one route will be sent on the WAN. This route will represent all subnets that belong to network 172.16.0.0.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-59

To configure manual route summarization on router R3, you must select the interface to propagate the summary route. Interface Serial0/0/0 is used in the example above. When configuring the summary route, you should use the ip summary-address eigrp command. You must specify the EIGRP routing protocol, AS number, and the summary address and the mask of the routes. Note

For manual route summarization, the summary route is advertised only if a component (a more specific entry) of the summary route is present in the routing table.

For more details about the auto-summary and ip summary-address eigrp commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

2-60

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Verifying Route Summarization

Îí ý­¸±© ·° ® ±«¬» ä± «¬°«¬ ±ł·¬ ¬»Ľâ Ůż ¬»©ż§ ±ş ´ ż­¬ ® »­±® ¬ ·­ ˛±¬ ­ »¬ ďéî ňďęň đňđń ďę ·­ Şż®· żľ´§ ­«ľ˛ »¬¬» Ľô í ­ «ľ˛» ¬­ô î łż­ µ­ Ü ďéîň ďęňđ ňđńďę ·­ ż ­«łł ż®§ô đđćđ đćđě ô Ň«´´đ Ü ďéîň ďęňď ňđńîě Ĺçđń ďëęď ęđĂ Ş· ż ďđ ňďňď ňîô đđćđđ ćđěô Úż­¬Ű ¬¸»® ˛»¬đ ńđ Ü ďéîň ďęňî ňđńîě Ĺçđń îđęě đđđđ Ă Ş·ż ďđňî ňîňî ô đđć đđćđě ô Í»® ·ż´đ ńđńď Ý ďçî ňďęč ňěňđ ńîě · ­ Ľ·® »˝¬´ § ˝±˛ ˛»˝¬ »Ľô Í »®·ż ´đńđń đ ďđň đňđň đńč ·­ Şż ®·żľ´ § ­«ľ ˛»¬¬ »Ľô í ­«ľ ˛»¬­ ô î ł ż­µ­ Ý ďđňî ňîňđ ńîě · ­ Ľ·® »˝¬´ § ˝±˛ ˛»˝¬ »Ľô Í »®·ż ´đńđń ď ä± «¬°«¬ ±ł·¬ ¬»Ľâ © 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-20

In order to verify that summarization is configured correctly, you must look at the IP routing table. Router R3 was configured for summarization and the routing table on router R3 is presented in the figure above. Router R3 has both 172.16.1.0 and 172.16.2.0, the discontiguous subnets, in its routing table. Because of the summarization, only network 172.16.0.0 is advertised out of the serial0/0/0 interface, though. The summary route pointing to the Null0 interface prevents routing loops. This approach is based on the assumption that the router doing summarization has more information on the subnets covered by the summary route besides the summary route itself.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-61

Summary This topic summarizes the key points that were discussed in this lesson.

Summary EIGRP operation can be verified by examining the EIGRP neighbor relationship information and IP routing table for the presence of EIGRP routes. The neighbor command can be used to form the EIGRP neighbor relationship with only specific neighbors using unicast packets. EIGRP is, by default, enabled on all interfaces included with the network command. To prevent unnecessary traffic, interfaces without neighbors should be made passive.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-21

Summary (Cont.) Create and advertise a default route in an EIGRP autonomous system with the ip default-network network-number command. EIGRP performs automatic network-boundary summarization, but administrators can disable automatic summarization and perform manual route summarization on an interface-by-interface basis. Summarizing routes results in smaller routing tables. For manual route summarization, the summary route is advertised only if a more specific entry of the summary route is present in the routing table.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

2-62

Implementing Cisco IP Routing (ROUTE) v1.0

RO UTE v 1.0—2-22

© 2009 Cisco Systems, Inc.

Lesson 3

Lab 2-1 Debrief Overview In Lab 2-1, students configure and verify EIGRP operations. First a student configures basic EIGRP and advertises all the specific subnets used in the network. Next, the student defines EIGRP path selection so that the primary path is preferred and the second path remains as a backup. Because EIGRP uses a lot of bandwidth and CPU resources, the student must optimize EIGRP operation. The student must also configure EIGRP operation in scalable way, in which summarization is configured in order to improve convergence time and add stability.

Objectives Upon completing this lesson, you will be able to explain how to configure and verify EIGRP operations. This ability includes being able to meet these objectives: Complete the lab overview and verification Describe a sample solution and alternatives

Lab Overview and Verification This topic describes lab topology, as well as the key checkpoints used to create a solution and start with the verification.

Lab Topology

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-2

The figure above presents the physical lab topology used for Lab 2-1: configure and verify EIGRP operations. The topology uses four pod routers, one backbone router, and one pod switch. Based on the topology, students will identify the required parameters and configure a basic EIGRP routing protocol in order to establish Layer 3 reachability in the network, as well as influence EIGRP path selection, optimize EIGRP operation, and provide a scalable solution.

2-64

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab Review: What Did You Accomplish? Task 1: Configure Basic EIGRP – What steps did you take to configure the EIGRP routing protocol and advertise all of the specific IP subnets used in the network? Task 2: Influence EIGRP Path Selection – What must be changed so that the primary path is preferred and the secondary path remains as a backup? Task 3: Optimize EIGRP Operation – How do you prevent the formation of an adjacency, as well as preserve interface bandwidth and CPU resources? Task 4: Scale EIGRP Operation – How is summarization configured in order to improve convergence time and add to stability?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-3

In the first task, you configured basic EIGRP routing. All routers are configured for EIGRP routing protocol according to the implementation plan. In the second task, you influenced the EIGRP path selection. You implemented redundancy in the network and the routers are able to select the primary path, while the backup path remains in the routing table. You must also change the metric in order to influence path selection in EIGRP routing protocol. In the third task, you optimized the EIGRP operation. Routing update suppression prevented the formation of EIGRP adjacencies. At the same time, CPU resources were preserved without the use of filtering. The passive-interface command is the solution to optimize the EIGRP operation in this step. In the fourth task, you configured scaling options of the EIGRP operation. Summarization was configured to summarize many subnets into one summary route, which was sent to the adjacent routers. Only one summary route is sent instead of many more-specific subnets.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-65

Verification Did you have enough information to create the implementation plan? Do the EIGRP-enabled routers form the adjacencies? Do you see all of the EIGRP-advertised networks in the IP routing table as EIGRP routes? Do you see two routes in the IP routing table after manipulating the path where the correct one is preferred? You cannot see the adjacency where the EIGRP routing protocol packets are suppressed, but the path to the destination still exists via another route; why is this? Do you see a summary route to Null0 interface as well as many more-specific subnets?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-4

A common approach to verifying the implementation process for configuring EIGRP operations is as follows: In order to create the implementation plan, sufficient information must be gathered. After a successful EIGRP configuration, all neighboring routers running EIGRP form an adjacency. Adjacent routers start exchanging routing protocol information and EIGRP routes populate the IP routing table. When a redundant path exists, one of them becomes primary path. Path manipulation results in the desired path being the primary and redundant paths being the backups. You cannot see the adjacency where EIGRP routing protocol packets are suppressed, but the path to the destination still exists via another route. The router performing the summarization includes a summary route to the Null0 interface, as well as routes to more-specific subnets. The remaining EIGRP neighbors only have a summary route.

2-66

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Checkpoints Configure the EIGRP routing protocol Advertise only specific subnets used in the network Manipulate the path by changing the metric Ensure the backup path still exists in the IP routing table Suppress the EIGRP routing protocol packet to preserve interface bandwidth and CPU resources without filtering Enable manual summarization to hide more specific subnets and improve stability

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-5

During the configuration and verification phase, a network operator can deal with several checkpoints. After completing all the configuration tasks, the network operator may have successfully configured EIGRP operations, or may need to do additional verification and troubleshooting. With different checkpoints, the network operator can verify for proper configuration. The following checkpoints are used for verification: Configure the EIGRP routing protocol. Advertise only specific subnets used in the network. Manipulate the path by changing the metric. Ensure that the backup path still exists in the IP routing table. Suppress the EIGRP routing protocol packet to preserve interface bandwidth and CPU resources without filtering. Enable manual summarization to hide more specific subnets and improve stability.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-67

Sample Solutions and Alternatives This topic describes a sample solution and other alternatives.

Sample Solution EIGRP is configured on the routers. Specific subnets used in the network are advertised. The metric for the link between routers R1 and R3 is changed. The LAN interfaces on routers R1 and R3 are configured as passive. Summarization is configured on router R1.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-6

A sample solution includes implementation details and details for each task of the implementation plan. Different solutions are possible and the figure above shows a few details of a successful configuration. The proper implementation of route redistribution between multiple IP routing protocols includes the following checkpoints: EIGRP routing protocol is configured on the pod routers. Specific subnets used in the network are advertised. The metric for the link between routers R1 and R3 is changed in order to manipulate the primary and backup path. The LAN interface on routers R1 and R3 is configured as passive to suppress EIGRP routing packets and preserve link bandwidth and CPU resources. Summarization is configured on router R1 for a scalable EIGRP implementation that results in the summary route being advertised only to other neighbors.

2-68

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternative Solutions EIGRP can be configured per interface or globally Different metrics, administrative distance, and filtering can be applied Static routes can be used and EIGRP can be disabled between routers R1 and BBR1. The use of another routing protocol can be an alternative solution, which is not realistic.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-7

Different metrics, administrative distance, and filtering can be applied to change the behavior of the EIGRP routing protocol. They can also be applied to manipulate the path when there is a redundancy in the network or to preserve CPU resources. You can use static routes, as well, but if all of the routers are configured with static routes, the solution will not be scalable. One of the options is to disable EIGRP between routers R1 and BBR1 and configure the default route or several static routes pointing toward router BBR1. The use of another routing protocol can be an alternative solution, which is not realistic as changing the routing protocol is not the case during fine tuning of the existing protocol.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-69

Q and A Why is routing protocol selection important? Why is changing the metric important? Does filtering preserve CPU router resources? Why does the passive-interface command result in no adjacency between the routers? Why does summarizing the router IP routing table contain a summary route to Null0 as well as more specific subnets? Why do the IP routing tables for some routers contain only a summary route?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-8

A routing protocol exchanges routing updates and populates the IP routing table, which is used for destination-based forwarding. Different routing protocols process routing updates in different ways. The metric defines the importance and the quality of the routes in the routing protocol. By manipulating the administrative distance and metric value, you can implement path manipulation, as well. Filtering does not preserve CPU resources. The passive-interface command suppresses routing protocol packets, preventing routers from forming adjacencies. The summary route is advertised and the neighboring routers send packets to the router that is summarizing the subnets in the routing table. If one of the more-specific subnets is lost, the router still sends the summary route to its neighbors, but the destination is not reachable and packets must be dropped (sent to the Null0 interface). A router summarizing the subnets contains the summary route as well as more-specific subnets. Because the idea of summarization is to decrease the sizes of the routing tables for neighboring routers, only a summary route is sent. This is enough to preserve the connectivity in the network.

2-70

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary Configure EIGRP and advertise all of the specific IP subnets in the network. Influencing EIGRP Path Selection can be applied by using a changing metric and backup path still exists in the IP routing table. By suppressing EIGRP routing packets, an EIGRP adjacency is not formed and the routing updates are not exchanged which results in more interface bandwidth and less CPU cycles used. Summarization decreases the size of the IP routing table, as only the summary route is present. The summarizing router has a summary route to the Null0 interface, as well as routes to morespecific subnets.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1. 0—2-9

Implementing an EIGRP-Based Solution

2-71

2-72

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 4

Configuring and Verifying EIGRP for the Enterprise WAN Architecture Overview EIGRP can operate over various underlying network technologies—Ethernet over Multiprotocol Label Switching (EoMPLS), MPLS virtual private network (MPLS VPN), and physical Frame Relay, as well as multipoint and point-to-point Frame Relay subinterfaces. Load balancing across multiple links is a valuable option for efficient bandwidth utilization. If you limit the amount of bandwidth that Enhanced Interior Gateway Routing Protocol (EIGRP) uses across these WAN links, you can provide user traffic with better access to the WAN links. This lesson provides insight into EIGRP deployment over various WAN technologies, as well as advanced configuration options for EIGRP load balancing and limitation of EIGRP bandwidth utilization on WAN links.

Objectives Upon completing this lesson, you will be able to describe, recognize, and deploy EIGRP over various WAN technologies and be able to scale the deployment with load balancing and proper bandwidth utilization. This ability includes being able to meet these objectives: Configure and verify EIGRP over Frame Relay and on a physical interface. Configure and verify EIGRP over multipoint subinterfaces. Configure and verify EIGRP over point-to-point subinterfaces. Implement load balancing across equal-metric paths. Implement load balancing across unequal-metric aths. Determine EIGRP bandwidth use across WAN links. Implement EIGRP over Layer 2 and Layer 3 MPLS VPN.

EIGRP Over Frame Relay and on a Physical Interface This topic describes how EIGRP can be deployed using Frame Relay physical interfaces.

Frame Relay Overview Frame Relay network – NBMA = nonbroadcast multiaccess network – Pseudo-broadcasting Requires mapping from Layer 3 to Layer 2 (IP-to-DLCI) – Static mapping – Dynamic mapping Neighbor loss detected only after the hold time expires or the interface goes down Different topologies – Full mesh – Partial mesh – Hub and spoke © 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-2

Frame Relay is a switched WAN technology for which virtual circuits are created through the network. In order to provide IP layer connectivity mapping between IP addresses and data-link connection identifiers (DLCIs) must be deployed—either dynamically or statically. Usually, switched WAN networks do not support broadcasting capability equivalent to LAN broadcasting. To emulate the LAN broadcasting capability that is required by IP routing protocols (for example, to send hello or update packets to all neighbors reachable over an IP subnet), Cisco IOS Software implements pseudo-broadcasting. This is when the Layer 2 code in Cisco IOS Software creates several copies of the same broadcast or multicast packet—one for each neighbor reachable through the WAN media. In environments where a single router has a large number of neighbors reachable through a single WAN interface, pseudo-broadcasting must be tightly controlled, as it can use a large amount of CPU time and WAN bandwidth. Pseudo-broadcasting is controlled with the broadcast option specified on static maps in a Frame Relay configuration. Pseudo-broadcasting cannot be controlled for neighbors reachable through dynamic maps created via Inverse Address Resolution Protocol (Inverse ARP) on a Frame Relay, as dynamic maps always allow pseudo-broadcasting. To control pseudo-broadcasting in Frame Relay, you must define the manual static maps and disable Inverse ARP. Neighbor loss is detected only after the hold time expires or the interface goes down. It is important to know that an interface is up as long as at least one DLCI is alive. The different topologies for Frame Relay are full mesh, partial mesh, and hub and spoke. 2-74

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP with Dynamic Mapping A single IP subnet is used Inverse ARP is enabled by default Split horizon is disabled on the physical interface by default

Îďý ·˛¬»®şż˝» Í»®·ż´đń𠻲˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ·° żĽĽ®»­­ ďçîňďęčňďňďđď îëëňîëëňîëëňđ ˙ ®±«¬»® »·ą®° ďď𠲻¬©±®µ ďéîňďęňďňđ đňđňđňîëë ˛»¬©±®µ ďçîňďęčňďňđ © 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-3

To deploy EIGRP over a physical interface using dynamic mapping, thus relying on Inverse ARP, no changes are needed to the basic configuration. The EIGRP process is enabled using the required autonomous system (AS) number (110 in the example on the figure). Proper interfaces and networks can also be included in the topology by specifying the network command under the EIGRP routing process. The split-horizon behavior is disabled by default on the physical interface. Therefore, routers R2 and R3 can provide connectivity between their connected networks. Inverse ARP does not provide dynamic mapping for the communication between routers R2 and R3; this must be configured manually.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-75

EIGRP with Dynamic Mapping (Cont.)

Îďý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ďďđ Ř ßĽĽ®»­­ ײ¬»®şż˝» ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ đ ďçîňďęčňďňďđî Í»đńđ ďđ đđćđéćîî ďđ ď ďçîňďęčňďňďđí Í»đńđ ďđ đđćđçćíě ďđ

ÎĚŃ

Ď Í»Ż ݲ¬ Ň«ł îîčđ đ ë îíîđ đ ç

Îíý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ďďđ Ř ßĽĽ®»­­ ײ¬»®şż˝» ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ đ ďçîňďęčňďňďđď Í»đńđ ďđ đđćďďćěë ďđ ď ďçîňďęčňďňďđî Í»đńđ ďđ đđćđîćďď ďđ © 2009 Cis co S y st em s, Inc. A ll right s reserved.

ÎĚŃ

Ď Í»Ż ݲ¬ Ň«ł ďçďđ đ ę îîďđ đ í ROUTE v1. 0—2-4

The sample outputs of the show ip eigrp neighbors command on this slide show the neighbors of routers R1 and R3. Router R1 forms an adjacency with router R2 and another with router R3 over the serial0/0 physical interface. Likewise, routers R2 and R3 form adjacencies with router R1. Apart from that, they can also form an EIGRP adjacency to each other if the IP-to-DLCI mapping for that connectivity is also provided. On the sample output for router R3, it is apparent that router R3 has adjacencies to routers R1 and R2.

2-76

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP with Static Mapping A single IP subnet is used Split horizon is disabled on the physical interface by default Inverse ARP is not used

Îďř˝±˛ş·ą÷ý ·˛¬»®şż˝» Í»®·ż´đń𠻲˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ·° żĽĽ®»­­ ďçîňďęčňďňďđď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ łż° ·° ďçîňďęčňďňďđď ďđď ş®żł»ó®»´ż§ łż° ·° ďçîňďęčňďňďđî ďđî ľ®±żĽ˝ż­¬ ş®żł»ó®»´ż§ łż° ·° ďçîňďęčňďňďđí ďđí ľ®±żĽ˝ż­¬ ˙ ®±«¬»® »·ą®° ďď𠲻¬©±®µ ďéîňďęňďňđ đňđňđňîëë ˛»¬©±®µ ďçîňďęčňďňđ © 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-5

To deploy EIGRP over a physical interface on router R1 using static mapping, thus disabling the Inverse ARP, no changes are needed to the basic configuration of EIGRP. The EIGRP process is enabled using the required AS number (110 in the example in the figure above). Proper interfaces and networks are included in the topology by specifying the network command under the EIGRP routing process. In addition, manual IP-to-DLCI mapping statements on the serial 0/0 interface are necessary on all three routers: R1, R2, and R3. The split-horizon behavior is disabled by default on the physical interface, thus routers R2 and R3 can provide connectivity between their connected networks, as well.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-77

EIGRP with Static Mapping (Cont.)

Îďý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ďďđ Ř ßĽĽ®»­­ ײ¬»®şż˝» ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ đ ďçîňďęčňďňďđî Í»đńđ ďđ đđćđęćîđ ďđ ď ďçîňďęčňďňďđí Í»đńđ ďđ đđćđčćíď ďđ

ÎĚŃ

Ď Í»Ż ݲ¬ Ň«ł îîčđ đ ë îíîđ đ ç

Îíý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ďďđ Ř ßĽĽ®»­­ ײ¬»®şż˝» ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ đ ďçîňďęčňďňďđď Í»đńđ ďđ đđćďđćěě ďđ ď ďçîňďęčňďňďđî Í»đńđ ďđ đđćđíćđî ďđ

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ÎĚŃ ďçďđ îîďđ

Ď Í»Ż ݲ¬ Ň«ł đ ę đ í

ROUTE v1. 0—2-6

The figure above shows the adjacency formed between router R1 and routers R2 and R3 over the serial0/0 physical interface. The adjacency formed using static mapping is the same as the one formed using dynamic mapping. The same applies to routers R2 and R3, which form the adjacency with router R1. Routers R2 and R3 can also form an EIGRP adjacency to each other if the IP-to-DLCI mapping for that connectivity is provided. The sample output from the show ip eigrp neighbors command in the figure above shows the neighbors on router R1 and R3. It is apparent that router R1 has two neighbors (routers R2 and R3), and router R3 also has two neighbors (routers R1 and R2).

2-78

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP over Multipoint Subinterfaces This topic describes how EIGRP can be deployed using Frame Relay multipoint subinterfaces.

Frame Relay Multipoint Subinterfaces Several multipoint subinterfaces can be created: – Logical interfaces emulating the multiaccess network – Like NBMA physical interfaces for routing purposes IP address space may be saved, since a single subnet is used. Subinterfaces are applicable to partial-mesh and full-mesh topologies. Neighbor loss is detected only after the hold time expires or the subinterface goes down.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-7

Several subinterfaces can be created over Frame Relay interfaces. They are logical interfaces emulating a multi-access network and provide the routing equivalent to nonbroadcast multiaccess (NBMA) physical interfaces. As with NBMA physical interfaces, a single subnet is used—preserving the IP address space. EIGRP neighbor loss detection is particularly slow on multipoint subinterfaces configured over low-speed WAN links. This is because the default values of the EIGRP timers on these interfaces are 60 seconds for the hello timer and 180 seconds for the hold timer. In the worst case, neighbor loss detection can take up to 3 minutes. Frame Relay multipoint is applicable to partial-mesh and full-mesh topologies. Partial-mesh Frame Relay networks must deal with the possibility of a split horizon, which prevents routing updates from being retransmitted on the same interface on which they were received.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-79

EIGRP over Multipoint Subinterfaces

Îďý ·˛¬»®şż˝» Í»®·ż´đń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± ş®żł»ó®»´ż§ ·˛Ş»®­»óż®° »·ą®° ďďđ ˙ ·˛¬»®şż˝» Í»®·ż´đńđňď ł«´¬·°±·˛¬ ·° żĽĽ®»­­ ďçîňďęčňďňďđď îëëňîëëňîëëň𠲱 ·° ­°´·¬ó¸±®·¦±˛ »·ą®° ďďđ ş®żł»ó®»´ż§ łż° ·° ďçîňďęčňďňďđď ďđď ş®żł»ó®»´ż§ łż° ·° ďçîňďęčňďňďđî ďđî ľ®±żĽ˝ż­¬ ş®żł»ó®»´ż§ łż° ·° ďçîňďęčňďňďđí ďđí ľ®±żĽ˝ż­¬ ˙ ®±«¬»® »·ą®° ďď𠲻¬©±®µ ďéîňďęňďňđ đňđňđňîëë ˛»¬©±®µ ďçîňďęčňďňđ © 2009 Cis co S y st em s, Inc. A ll right s reserved.

A single IP subnet is used. Mapping is applied to the subinterface. Split horizon must be disabled in partial-mesh topologies.

ROUTE v1. 0—2-8

To use the multipoint behavior of a subinterface, you must add the multipoint keyword at the end of the interface command when creating the subinterface. With Frame Relay, the mapping on the multipoint subinterfaces is created by using the proper local DLCI value: By specifying the proper local DLCI value and relying on the Inverse ARP With manual IP-to-DLCI mapping EIGRP is configured with no changes to the basic deployment. To enable the EIGRP process, use the required AS number (110 in the example on the figure) and include the proper interfaces and networks in the topology via the network command under the EIGRP routing process. Additionally, you can configure manual IP-to-DLCI mapping statements (via the frame-relay map command with the broadcast keyword on the serial 0/0 multipoint subinterfaces on routers R1, R2, and R3), in order to define the mapping between a destination protocol address and the DLCI used to connect to the destination address. If routers R2 and R3 need to provide connectivity between their connected networks, you must disable the EIGRP split horizon on the multipoint subinterface of router R1. The router R1 configuration includes the frame-relay map command to its own IP address on the multipoint serial subinterface in order to ping the local address for router R1 from router R1 itself.

2-80

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP over Multipoint Subinterfaces (Cont.)

Îďý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ďďđ Ř ßĽĽ®»­­ ײ¬»®şż˝» ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ đ ďçîňďęčňďňďđî Í»đńđňď ďđ đđćđęćěď ďđ ď ďçîňďęčňďňďđí Í»đńđňď ďđ đđćđčćëî ďđ

ÎĚŃ

Ď Í»Ż ݲ¬ Ň«ł îîčđ đ ë îíîđ đ ç

Îíý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ďďđ Ř ßĽĽ®»­­ ײ¬»®şż˝» ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ đ ďçîňďęčňďňďđď Í»đńđňď ďđ đđćďđćíé ďđ ď ďçîňďęčňďňďđî Í»đńđňď ďđ đđćđíćďî ďđ

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ÎĚŃ ďçďđ îîďđ

Ď Í»Ż ݲ¬ Ň«ł đ ę đ í

ROUTE v1. 0—2-9

If you want to verify the operation of the EIGRP routing protocol over the Frame Relay multipoint subinterface, you can use the show ip eigrp neighbors command. The figure above shows two sample outputs for routers R1 and R3. Router R1 forms the adjacency with routers R2 and R3 over the serial0/0.1 multipoint subinterface. This is done in the same way routers R2 and R3 form the adjacency with router R1 and between each other if IP-to-DLCI mapping for that connectivity is provided.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-81

EIGRP Unicast Neighbor Setting a neighbor with the command to enable a unicast neighbor relationship

Îďý ·˛¬» ®şż˝» Úż­¬ ۬¸»® ˛»¬đ ńđ ·° ż ĽĽ®» ­­ ďéîňďę ňďňď îëëň îëëň îëëň đ ˙ ·˛¬» ®şż˝» Í»®· ż´đńđ ňď ł« ´¬·° ±·˛¬ ·° ż ĽĽ®» ­­ ďçîňďęč ňďňď đď îëë ňîëë ňîëë ňđ ş®żł »ó®» ´ż§ łż° ·° ďçîň ďęčň ďňďđ î ďđî ľ®±ż Ľ˝ż­ ¬ ş®żł »ó®» ´ż§ łż° ·° ďçîň ďęčň ďňďđ í ďđí ľ®±ż Ľ˝ż­ ¬ ˙ ®±«¬ »® »·ą®° ď ď𠲻¬© ±®µ ď éîňď ęňďňđ đňđň đňîë ë ˛»¬© ±®µ ď çîňď ęčňďň 𠲻·ą ¸ľ±® ďçîňďęčňď ňďđî © 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-10

The neighbor command is used in EIGRP in order to define a neighboring router with which to exchange routing information. Instead of using multicast packets, EIGRP exchanges routing information with the neighbors in the form of unicast packets whenever the neighbor command is configured for an interface. EIGRP stops processing all multicast packets that come inbound on that interface. At the same time, EIGRP stops sending multicast packets on that interface. Multiple neighbor statements can be used to establish peering sessions with specific EIGRP neighbors. The interface through which EIGRP will exchange routing updates must be specified in the neighbor statement. The interfaces through which two EIGRP neighbors exchange routing updates must be configured with IP addresses from the same network. Note

EIGRP neighbor adjacencies cannot be established or maintained over an interface that is configured as passive.

Router R1 is configured with the neighbor command for router R2. For more details about the neighbor command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

2-82

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP Unicast Neighbor (cont.)

Îîý ·˛¬» ®şż˝» Úż­¬ ۬¸»® ˛»¬đ ńđ ·° ż ĽĽ®» ­­ ďéîňďé ňîňî îëëň îëëň îëëň đ ˙ ·˛¬» ®şż˝» Í»®· ż´đńđ ňď ł« ´¬·° ±·˛¬ ·° ż ĽĽ®» ­­ ďçîňďęč ňďňď đî îëë ňîëë ňîëë ňđ ş®żł »ó®» ´ż§ łż° ·° ďçîň ďęčň ďňďđ ď ďđî ľ®±ż Ľ˝ż­ ¬ ˙ ®±«¬ »® »·ą®° ď ď𠲻¬© ±®µ ď éîňď éňîňđ đňđň đňîë ë ˛»¬© ±®µ ď çîňď ęčňďň 𠲻·ą ¸ľ±® ďçîňďęčňď ňďđď © 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-11

Router R1 is configured with the neighbor command and will not accept multicast packets anymore. In order to establish an adjacency, router R2 must be configured as well. In the example above, router R2 is configured with the neighbor command for router R1, which enables the use of unicast packets accepted by router R1. Router R3 is not configured with the neighbor command.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-83

Verifying EIGRP Unicast Neighbors

Îď ý­¸±© ·° » ·ą®° ˛»·ą ¸ľ±®­ ×Đ óŰ×ŮÎ Đ ˛»· ą¸ľ± ®­ ş± ® °®± ˝»­­ ďďđ Ř ßĽĽ ®»­­ ײ ¬»®şż ˝» ر´Ľ Ë°¬ ·ł» ÍÎĚĚ ř­»˝ ÷ řł­ ÷ đ ďçî ňďęčň ďňďđ î Í» đńđńď ďđ đđć đéćî î ďđ

Î ĚŃ

Ď Í» Ż Ý ˛¬ Ň« ł î îčđ đ ë

Îî ý­¸± © ·° » ·ą®° ˛»·ą ¸ľ±® ­ ×Đ óŰ×Ů ÎĐ ˛»· ą¸ľ± ®­ ş± ® °® ±˝»­ ­ ďďđ Ř ßĽĽ ®»­­ ײ ¬»®ş ż˝» ر´ Ľ Ë° ¬·ł» ÍÎ ĚĚ ř­» ˝÷ řł ­÷ đ ďçî ňďęč ňďňď đď Í» đńđń ď ďđ đđ ćďéć đî ďđ © 2009 Cis co S y st em s, Inc. A ll right s reserved.

ÎĚŃ

Ď Í »Ż Ý ˛¬ Ň «ł ďíčđ đ ë RO UTE v 1.0—2-12

To verify the configuration, use the show ip eigrp neighbors command. As you can see in the output above, routers R1 and R2 have formed the neighbor relationship. The sample output does not show that the neighbor command was used on both routers. It only indicates that a neighbor relationship was established, which is a proof that the configuration was successfully completed. Router R3 is not using the neighbor command and no neighbor relationship was established, because routers R1 and R2 are not accepting multicast packets. For more details about the show ip eigrp neighbors command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

2-84

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP over Point-to-Point Subinterfaces This topic describes how EIGRP can be deployed using Frame Relay point-to-point subinterfaces.

Frame Relay Point-to-Point Subinterfaces Several point-to-point subinterfaces can be created: – Logical interfaces emulating a leased-line network – Like physical point-to-point interfaces for routing purposes Each point-to-point subinterface requires its own subnet. Applicable to hub-and-spoke topologies. Neighbor loss is detected after the hold time expires, the subinterface goes down, or the DLCI is lost.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-13

Several point-to-point subinterfaces can be created over Frame Relay interfaces. They are logical interfaces emulating a leased line network and provide a routing equivalent to point-topoint physical interfaces. As with physical point-to-point interfaces, each interface requires its own subnet. Frame Relay point-to point is applicable to hub-and-spoke topologies. EIGRP neighbor loss detection is quite fast on point-to-point subinterfaces for several reasons: The default values of the EIGRP hello timer and the EIGRP hold timer are identical to the values used on point-to-point links (5 seconds for the hello timer and 15 seconds for the hold timer). In the worst case, the neighbor loss is detected within 15 seconds. On Frame Relay networks, the subinterface is declared down if the DLCI attached to the interface is lost and neighbor loss detection is immediate. For multipoint subinterfaces, all of the permanent virtual circuits (PVCs) attached to it must be lost for the interface to be declared down. Note

© 2009 Cisco Systems, Inc.

Neighbor loss detection due to DLCI loss only works if the Frame Relay network supports end-to-end Integrated Local Management Interface (ILMI) signaling. On some Frame Relay networks, one end of the connections might fail (for example, due to a router failure), but the DLCI will still be declared operational at the other end of the connection.

Implementing an EIGRP-Based Solution

2-85

EIGRP over Point-to-Point Subinterfaces

Îďý ·˛¬»®şż˝» Í»®·ż´đń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˙ ·˛¬»®şż˝» Í»®·ż´đńđňî °±·˛¬ó¬±ó°±·˛¬ ·° żĽĽ®»­­ ďçîňďęčňîňďđď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďđî ˙ ·˛¬»®şż˝» Í»®·ż´đńđňí °±·˛¬ó¬±ó°±·˛¬ ·° żĽĽ®»­­ ďçîňďęčňíňďđď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďđí ˙ ®±«¬»® »·ą®° ďď𠲻¬©±®µ ďéîňďęňďňđ đňđňđňîëë ˛»¬©±®µ ďçîňďęčňîň𠲻¬©±®µ ďçîňďęčňíňđ © 2009 Cis co S y st em s, Inc. A ll right s reserved.

Îíý ·˛¬»®şż˝» Í»®·ż´đń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˙ ·˛¬»®şż˝» Í»®·ż´đńđňď °±·˛¬ó¬±ó°±·˛¬ ·° żĽĽ®»­­ ďçîňďęčňíňďđí îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďđí ˙ ®±«¬»® »·ą®° ďď𠲻¬©±®µ ďéîňďęňíňđ đňđňđňîëë ˛»¬©±®µ ďçîňďęčňíňđ

RO UTE v 1.0—2-14

To enable subinterfaces for point-to-point, you need to create them using the point-to-point keyword at the end of the interface command. With Frame Relay, the mapping of the point-topoint subinterfaces is created by specifying the proper local DLCI value. EIGRP is configured with no changes to the basic deployment. To enable the EIGRP process, use the required AS number (110 in the example on the figure) and include the proper interfaces and networks in the topology via the network command under the EIGRP routing process. Additionally, you can configure manual IP-to-DLCI mapping statements (via the frame-relay map command with the broadcast keyword on the serial 0/0 multipoint subinterfaces on routers R1, R2, and R3).

2-86

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP over Point-to-Point Subinterfaces (Cont.)

Îďý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ďďđ Ř ßĽĽ®»­­ ײ¬»®şż˝» ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ đ ďçîňďęčňîňďđî Í»đńđňî ďđ đđćđčćđě ďđ ď ďçîňďęčňíňďđí Í»đńđňí ďđ đđćďđćďî ďđ

ÎĚŃ îîčđ îíîđ

Ď Í»Ż ݲ¬ Ň«ł đ ë đ ç

Îíý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ďďđ Ř ßĽĽ®»­­ ײ¬»®şż˝» ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ đ ďçîňďęčňíňďđď Í»đńđňď ďđ đđćďíćîë ďđ

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ÎĚŃ ďçďđ

Ď Í»Ż ݲ¬ Ň«ł đ ę

RO UTE v 1.0—2-15

The show ip eigrp neighbors command can be used to verify the operation of the EIGRP routing protocol over the Frame Relay point-to point subinterface. The figure above shows two sample outputs for router R1 and R3. Router R1 forms an adjacency with router R2 over the serial0/0.2 point-to-point interface and with router R3 over the serial0/0.3 point-to-point subinterface. Likewise, routers R2 and R3 form the adjacency with router R1. On the figure above it is apparent that router R3 has one neighbor over the serial0/0.1 point-to-point subinterface.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-87

Load Balancing Across Equal-Metric Paths This topic explains how EIGRP performs load balancing across equal-metric paths and describes how to change the default configuration.

EIGRP Load Balancing Routes with a metric equal to the minimum metric are installed in the routing table - equal-metric load balancing Up to 16 entries can be in the routing table for the same destination (default is 4) – Maximum number is configurable – To disable load balancing, set the value to one Îďř˝±˛ş·ą÷ý ®±«¬»® »·ą®° ďďđ łż¨·ł«łŠ°ż¬¸­ î

To control the maximum number of parallel routes that an IP routing protocol can support

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-16

Equal-metric load balancing is a router’s capability to distribute traffic over all of its network ports that have the same metric to the destination address. Load balancing increases the use of network segments and increases the effective network bandwidth. For IP, the Cisco IOS Software applies load balancing between a maximum of four equalmetric paths by default. You can configure the maximum number of parallel routes that an IP routing protocol can support using the maximum-paths router configuration command. Up to 16 equally good routes can be kept in the routing table. Note

Setting the maximum-paths value to 1 disables load balancing.

When a packet is process-switched, load balancing over equal-metric paths occurs on a perpacket basis. When packets are fast-switched, load balancing over equal-metric paths occurs on a per-destination basis. (Thus, if you are testing load balancing, do not ping to or from routers with fast-switching interfaces, because the packets generated locally by this router are processswitched rather than fast-switched, and the ping might produce confusing results.) For more details about the maximum-paths command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

2-88

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP Load Balancing (Cont.)

Îďý ®±«¬»® »·ą®° ďď𠲻¬©±®µ ďéîňďęňďňđ đňđňđňîëë ˛»¬©±®µ ďçîňďęčňďň𠲻¬©±®µ ďçîňďęčňîň𠲻¬©±®µ ďçîňďęčňíň𠲻¬©±®µ ďçîňďęčňěňđ łż¨·ł«łŠ°ż¬¸­ í Îďý­¸±© ·° ®±«¬» »·ą®° 䱫¬°«¬ ±ł·¬¬»Ľâ ďéîňďęňđňđńďę ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ô Ü ďéîňďęňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďçîňďęčňďňîô ĹçđńîčđçčëęĂ Ş·ż ďçîňďęčňîňîô ĹçđńîčđçčëęĂ Ş·ż ďçîňďęčňíňîô 䱫¬°«¬ ±ł·¬¬»Ľâ © 2009 Cis co S y st em s, Inc. A ll right s reserved.

î łż­µ­ đđćđéćđďô Í»®·ż´ďńď đđćđéćđďô Í»®·ż´ďńî đđćđéćđďô Í»®·ż´ďńí

RO UTE v 1.0—2-17

The configuration example above shows the use of the maximum-paths command, which is applied under the EIGRP routing process. Router R1 is configured to support up to three equalmetric paths. If the maximum-paths command is not used, EIGRP can, by default, use four equal-metric paths. The sample output above shows router R1’s routing table, where the three paths have the same metric (cost). All three paths through routers R2, R3, and R4 are used to reach the destination network 172.16.2.0 behind router R6. The path through router R5 is not used, because the metric is too big. Even if the metric is the same as the others, the path will not be used, as 3 is the maximum number set by the maximum-paths command.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-89

Load Balancing Across Unequal-Metric Paths This topic explains how EIGRP performs load balancing across unequal-metric paths and describes how to configure load balancing.

EIGRP Unequal-Cost Load Balancing The router can balance traffic across multiple routes that have different metrics to a destination – Successor is always used – Feasible successors are used if the cost is less than (minimum cost * variance) – Variance is only a multiplier, not a max-path parameter – The maximum number of paths is limited by the maximum– paths command Variance opens the gate for unequal-cost load balancing Îďř˝±˛ş·ą÷ý ®±«¬»® »·ą®° ďďđ Şż®·ż˛˝» î

To control load balancing in an internetwork based on EIGRP © 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-18

EIGRP can also balance traffic across multiple routes that have different metrics, which is called unequal-metric load balancing. The degree to which EIGRP performs load balancing is controlled by the variance (EIGRP) command. Setting a variance value (1-128) enables EIGRP to install multiple loop-free routes with unequal cost in a local routing table. EIGRP will always install a successor into the local routing table. Additional feasible successors are candidates for the local routing table. Additional entries through EIGRP must meet two criteria to be installed in the local routing table: The route must be loop-free. This condition is satisfied when the advertised distance (AD) is less than the total distance, or when the route is a feasible successor. The metric of the route must be lower than the metric of the best route (the successor), multiplied by the variance configured on the router. The default value for the variance (EIGRP) command is 1, which indicates equal-cost load balancing—only routes with the same metric as the successor are installed in the local routing table. The variance command is not limiting the maximum number of paths. It is the multiplier that defines the range of metric values that are accepted for load balancing by the EIGRP process. If the variance is set to 2, any EIGRP-learned route with a metric less than 2 times the successor metric will be installed in the local routing table. If the variance command allows EIGRP to use 9 paths and the maximum-path command sets the maximum paths value to 3, only the first 3 paths of the 9 paths will show up in the IP routing table—the maximum-path command will limit the maximum number.

2-90

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Note

EIGRP does not load-share between multiple routes; it only installs the routes in the local routing table. Then the local routing table enables switching hardware or software to loadshare between the multiple paths.

For more details about the EIGRP variance command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-91

EIGRP Unequal-Cost Load Balancing (Cont.)

Îďý ®±«¬»® »·ą®° ďďđ Şż®·ż˛˝» î

R1 EIGRP Topology for 172.16.2.0 Ne two rk

Neig hbor

FD

AD

172 .16.2.0

R2

30

10

R3

20

10

R4

45

25

- AD(R4)>FD(R3)

R5

50

10

- Variance: 50(FD)>2*20(FD,Successor)

Îďý­¸±© ·° ®±«¬» »·ą®° 䱫¬°«¬ ±ł·¬¬»Ľâ ďéîňďęňđňđńďę ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ô î łż­µ­ Ü ďéîňďęňîňđńîě ĹçđńďđęęëěéîĂ Ş·ż ďçîňďęčňîňîô đđćđéćđďô Í»®·ż´ďńî ĹçđńďďďëďčéîĂ Ş·ż ďçîňďęčňďňîô đđćđéćđďô Í»®·ż´ďńď 䱫¬°«¬ ±ł·¬¬»Ľâ © 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-19

Router R1 in the example above is configured with a variance of 2, and the range of metric values, which are the feasible distances (FDs) to network 172.16.2.0/24, is from 20 to 50 (generic values, in order to make computation easier). This range of values determines the feasibility of a potential route. A route is feasible if the next router in the path is closer to the destination than the current router and if the metric of the alternate path is within the variance. Load balancing can use only feasible paths, which are included inside the local routing table. The two feasibility conditions are: The local best metric (the current FD) must be greater than the best metric (AD) learned from the next router. In other words, the next router in the path must be closer to the destination than the current router, which prevents routing loops. The variance multiplied by the local best metric (the current FD) must be greater than the metric through the next router (the alternative FD). This condition is true if the metric of the alternate path is within the variance. If both of these conditions are met, the route is called feasible and can be added to the routing table. The example below shows four paths from router R1 to network 172.16.2.0/24 with the following metrics: Path 1: 30 (via R2) Path 2: 20 (via R3) Path 3: 45 (via R4) Path 4: 50 (via R5)

2-92

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

All the paths have different metrics. By default, router R1 only places path 2, via R3, in the routing table, because it is the least-cost path—a successor route with the lowest FD. For it to load balance over paths 1 and 2, a variance command must be applied to router R1 to change the value in such way that path 1 (with a greater metric than the successor route) can be used as well. The variance value must be set such that the result of multiplying the variance and successor FD will be greater than the second FD candidate. In our example, the variance value is set to 2, which produces a result of 40 (20 * 2 = 40) and path 1 through router R2, becomes the second route in the local routing table (the FD of 30 is less than 40). Router R4 is not considered for load balancing with this variance, because the FD through router R4 is more than twice the FD for the successor (router R3). Router R4 will never be a feasible successor no matter what the variance is. This is because router R4’s advertised distance of 25 is greater than router R3’s FD of 20; therefore, to avoid a potential routing loop, router R4 is not considered a feasible successor. Router R5 is not considered for load balancing with this variance, because the FD through router R5 is more than twice the FD for the successor (router R3). In this example, however, router R5 will be a feasible successor no matter what the variance is. This is because router R5’s advertised distance of 10 is lower than router R3’s FD of 20. Load balancing is proportional to the bandwidth. Routes via R2 and R3 in the picture above are used for load balancing. The FD of the route via R2 equals 30. The FD of the route via R3 equals 20. The total FD is 50 and the ratio of traffic between the two paths (via R2 : via R3) is 3/5 : 2/5.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-93

EIGRP Bandwidth use Across WAN Links This topic explains how EIGRP can utilize bandwidth across WAN links in an environment where the default bandwidth usage, of up to 50%, may not be optimal.

EIGRP Bandwidth Utilization over WAN Up to 50% of bandwidth is utilized by default and can be changed Point-to-point interfaces – Treat bandwidth as T1 by default – Configure bandwidth manually Multipoint interfaces – Bandwidth on the physical interface divided by the number of neighbors on that interface Îďř˝±˛ş·ąó·ş÷ý ľż˛Ľ©·Ľ¬¸ îëę ·° ľż˛Ľ©·Ľ¬¸ó°»®˝»˛¬ »·ą®° ďďđ čđ

To configure the percentage of bandwidth that may be used by EIGRP on an interface

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-20

EIGRP operates efficiently in WAN environments. It is scalable on both point-to-point links and on multipoint NBMA links. Because of the inherent differences in the operational characteristics of WAN links, the default configuration parameters may not be the best option for all WAN links. A solid understanding of EIGRP operation, coupled with knowledge of available link speeds, can yield an efficient, reliable, and scalable router configuration. By default, EIGRP may use up to 50 percent of the bandwidth of an interface or subinterface. When calculating how much bandwidth to use, EIGRP uses either the bandwidth of the link set by the bandwidth command, or the link’s default bandwidth if none is configured. This percentage can be changed on a per-interface basis by using the ip bandwidth-percent eigrp interface configuration command. Cisco IOS Software assumes that the point-to-point Frame Relay subinterfaces (such as all serial interfaces) operate at full T1 link speed. In many implementations however, only fractional T1 speeds are available. Therefore, when configuring these subinterfaces, set the bandwidth to match the contracted committed information rate (CIR). When configuring multipoint interfaces, especially for Frame Relay (but also for ATM and ISDN PRI), it is important to understand that all neighbors share the bandwidth equally. That is, EIGRP uses the bandwidth command on the physical interface divided by the number of Frame Relay neighbors connected on that physical interface to calculate the bandwidth assigned to each neighbor. The EIGRP configuration should reflect the correct percentage of the actual available bandwidth on the line. 2-94

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

In the figure above, a sample configuration is used, in which an EIGRP process with an AS number 110 can get 80% of the bandwidth configured on that interface. This percentage can be greater than 100, which may be useful if the bandwidth is configured artificially low for routing-policy reasons. For more details about the ip bandwidth-percent eigrp command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-95

Bandwidth Utilization Issues Each PVC can have a different CIR, creating an EIGRP packetpacing problem. Multipoint interfaces: – Convert to point-to-point configuration OR – Manually configure bandwidth by multiplying the lowest CIR by the number of PVCs.

PVC

Bandwidth (kb/s)

1

64

2

128

3

256

4

256

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-21

Each installation has a unique topology and requires a unique configuration. Since CIR values differ, a subinterface will often requires a hybrid configuration that blends the characteristics of point-to-point circuits with multipoint circuits. When configuring multipoint interfaces, configure the bandwidth to represent the minimum CIR multiplied by the number of circuits. This approach may not fully use the higher-speed circuits, but it ensures that the circuits with the lowest CIR values are not overdriven. If the topology has a small number of very low-speed circuits, these interfaces are defined typically as point-to-point, so that their bandwidth can be set to match the provisioned CIR. In the figure above, 64k b/s is the smallest amount of bandwidth among all PVCs in the multipoint configuration and this should be taken into account for bandwidth calculation.

2-96

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP Hub-and-Spoke WAN Utilization Configure each VC as point-to-point—do not change number of VCs to preserve the configuration Set bandwidth to 1/10 of link capacity Increase EIGRP utilization to 50% of actual VC capacity Îďý ·˛¬»®şż˝» ­»®·ż´đ ľż˛Ľ©·Ľ¬¸ îëę ·˛¬»®şż˝» ­»®·ż´đňď °±·˛¬ó¬±ó°±·˛¬ ·° ľż˛Ľ©·Ľ¬¸ó°»®˝»˛¬ »·ą®° ďďđ ďîč 䱫¬°«¬ ±ł·¬¬»Ľâ ·˛¬»®şż˝» ­»®·ż´đňďđ °±·˛¬ó¬±ó°±·˛¬ ·° ľż˛Ľ©·Ľ¬¸ó°»®˝»˛¬ »·ą®° ďďđ ďîč

Îëý ·˛¬»®şż˝» ­»®·ż´đ ľż˛Ľ©·Ľ¬¸ îë ·° ľż˛Ľ©·Ľ¬¸ó°»®˝»˛¬ »·ą®° ďďđ ďîč

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-22

The example above shows a hub-and-spoke topology with ten virtual circuits to the ten remotes sites. Only four of the ten remote sites are shown in the figure above. The configurations for routers R1 and R5, using EIGRP AS 110, are also shown in the figure. The circuits are provisioned as 64-kb/s links, but there is insufficient bandwidth at the interface to support this allocation. For example, if the hub tries to communicate to all remote sites at the same time, the bandwidth that is required exceeds the available link speed of 256 kb/s for the hub (10 times the CIR of 64 kb/s equals 640 kb/s). The configuration for router R1 shows that the bandwidth 256 command has been applied to the main interface (serial0) and has set the bandwidth to 256 kb/s. Because 10 virtual circuits (VCs) are configured, each of them automatically gets 10% of the main interface bandwidth. Therefore, the bandwidth command is not needed on each subinterface. The ip bandwidth-percent eigrp 110 128 command sets the maximum percentage of an interface’s bandwidth that EIGRP can use to 128% for EIGRP AS 110. In a point-to-point topology, all virtual circuits are treated equally; the subinterfaces are assigned a bandwidth equal to one-tenth of the available link speed (25 kb/s). Based on the ip bandwidth-percent eigrp 110 128 command applied on each interface and subinterface, the EIGRP allocation percentage is raised to 128 percent of the specified bandwidth in an attempt to ensure that the EIGRP packets are delivered through the Frame Relay network. This adjustment causes the EIGRP packets to receive 32 kb/s of the provisioned 64 kb/s on each circuit (128% of the 25kb/s equals 32 kb/s). This extra configuration restores the 50-50 ratio that was changed when the bandwidth was set to an artificially low value. In order to ensure that this calculation is correct, the number of VCs must not be changed.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-97

EIGRP Multipoint WAN Utilization Solution 1: create on multipoint interfaces (Lowest CIR * number of VCs) = (56 kb/s * 4) = 224 kb/s

Îďř˝±˛ş·ą÷ý ·˛¬»®şż˝» ­»®·ż´đ ľż˛Ľ©·Ľ¬¸ îîě

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-23

In a multipoint topology, where virtual circuits may not have equal bandwidth, the rule is to use the lowest CIR and multiply it by the number of VCs to get the bandwidth that should be set on the interface. With this configuration, the smallest and the slowest link will not suffer with higher speed links. In the figure above, the example shows four VCs with different CIRs configured. The CIR toward routers R2, R3, and R4 is configured to 256 kb/s and the CIR toward router R5 is configured to 56 kb/s. Thus, on router R1, the bandwidth is set to 224 kb/s, which is 4 times the lowest CIR in the system (56 kb/s).

2-98

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP Hybrid Multipoint WAN Utilization (Cont.) Solution 2: create separate multipoint interfaces – Configure the lowest CIR VC as point-to-point and set bandwidth = CIR. – Configure higher CIR VCs as multipoint, combine CIRs, and configure the sum of bandwidth to the subinterface. Îďý ·˛¬»®şż˝» ­»®·ż´đňď ł«´¬·°±·˛¬ ľż˛Ľ©·Ľ¬¸ éęč ˙ ·˛¬»®şż˝» ­»®·ż´đňî °±·˛¬ó¬±ó°±·˛¬ ľż˛Ľ©·Ľ¬¸ ëę

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-24

In a hybrid multipoint and point-to-point topology, you should create separate point-to-point VCs for the lowest CIR VCs. All other VCs, which have a higher and possibly equal CIR, should be configured as one multipoint VC. For this multipoint VC, the CIR must be a combination of all individual CIRs. The figure above shows an example in which one VC is a low-speed circuit with 56kb/s of bandwidth and the other three VCs have bandwidth of 256 kb/s. The preferred configuration on router R1 shows the low-speed circuit configured as point-to-point with the bandwidth set to the CIR value. The remaining circuits are designated as a multipoint subinterface, and their CIRs are added together to set the bandwidth for the subinterface. In multipoint interfaces, the bandwidth is shared equally among all circuits. In this case, the bandwidth is set to 768 kb/s, which is the sum of the three CIRs (3 * 256 kb/s = 768 kb/s). Each link will be allocated one-third of this bandwidth, resulting in 256 kb/s each.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-99

EIGRP over EoMPLS and Metro Ethernet This topic provides an overview of EoMPLS technology and explains how EIGRP can be deployed in an EoMPLS environment.

AToM Overview Service providers offer Layer 2 transport services to connect customer equipment (CE) – Ethernet, Ethernet VLAN – ATM – PPP, HLDC, and so on Any Transport Over MPLS – Enables the sending of Layer 2 frames across the MPLS backbone – Unifies Layer 2 and Layer 3 over a common MPLS infrastructure – Virtual circuits represent Layer 2 links – Labels identify virtual circuits

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-25

Many ISPs currently offer Layer 2 transport services to their customers. These services are offered over a circuit-based infrastructure to build Layer 2 virtual private networks (VPNs). Initially, VPNs were built using leased lines. Later, service providers offered Layer 2 VPNs based on point-to-point data link layer connectivity, using ATM or Frame Relay virtual circuits. Customers built their own Layer 3 networks to accommodate IP traffic. As a result, separate networks exist for Layer 2 and Layer 3 traffic. However, maintaining separate networks for Layer 2 VPNs and Internet traffic is difficult and costly. Therefore, ISPs want a single IP-based network to provide both Layer 2 and Layer 3 services. MPLS VPN was introduced to meet the requirement for a unified network for Layer 3 VPN services. However, some customers still wanted Layer 2 connections. This can be Ethernet VLAN extensions across a metropolitan area or ATM services. Any Transport over MPLS (AToM) was introduced to facilitate Layer 2 connectivity across an MPLS backbone. AToM benefits ISPs that offer Layer 2 connectivity to customers with traditional offerings such as ATM, Frame Relay, and serial/Point-to-Point Protocol (PPP) services. Additionally, it benefits service providers specializing in Ethernet connectivity in metropolitan areas. Services for Layer 2 VPNs also appeal to service providers' enterprise customers, who may already run many of these networks and want just point-to-point connectivity. Note

2-100

For more information about MPLS, please attend the Implementing MPLS VPN Cisco course.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Layer 2 and Layer 3 MPLS VPN Solutions Layer 2 MPLS VPN backbone solution

Layer 3 MPLS VPN backbone solution

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-26

The figure above presents the basic difference between a Layer 2 MPLS VPN and a Layer 3 MPLS VPN backbone solution. Customer routers (R1 and R2 on this slide) are connected across the MPLS VPN backbone, and it is important to define the difference. The Layer 2 MPLS VPN backbone solution is providing the Layer 2 service across the backbone, where routers R1 and R2 are connected together directly using the same IP subnet. This slide presents the connectivity through the backbone as a switch. The Layer 3 MPLS VPN backbone solution is providing the Layer 3 service across the backbone, where routers R1 and R2 are connected to ISP edge routers. A separate IP subnet is used on each side. This slide presents the connectivity through the backbone as a router.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-101

Layer 3 MPLS VPN Overview Service provider is connecting multiple customers over a common MPLS backbone using MPLS VPNs Customer Edge (CE) devices connect into the service provider MPLS VPN network

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-27

The MPLS VPN architecture provides the ISPs with a peer-to-peer VPN architecture that combines the best feature of an overlay VPN (support for overlapping customer address spaces) with the best features of peer-to-peer VPNs: PE routers participate in customer routing, guaranteeing optimum routing between customer sites. PE routers carry a separate set of routes for each customer, resulting in perfect isolation between the customers. The MPLS VPN terminology divides the overall network into the customer-controlled part (Cnetwork) and the provider-controlled part (P-network). Contiguous portions of the C-network are called sites and are linked with the P-network via Customer Edge routers (CE-routers). The CE-routers are connected to the provider edge routers (PE-routers), which serve as the edge devices of the provider network. The core devices in the provider network (P-routers) provide the transit transport across the provider backbone and do not carry customer routes. The architecture of a PE-router in an MPLS VPN is very similar to the architecture of a point of presence (POP) in the dedicated PE-router peer-to-peer model; the only difference is that the whole architecture is condensed into one physical device. Each customer is assigned an independent routing table (virtual routing table) that corresponds to the dedicated PE-router in the traditional peer-to-peer model. Routing across the provider backbone is performed by another routing process that uses global IP routing table, corresponding to the intra-POP Prouter in a traditional peer-to-peer model. The MPLS VPN backbone provides a Layer 3 backbone in which the CE routers see PE routers as additional customer routers in the path. The PE routers maintain separate routing tables for each customer.

2-102

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Customer MPLS Perspective CE routers run EIGRP and exchange routing updates with the PE router – The PE router appears as another router in the customer’s network – The service provider’s P-routers are hidden from the customer – CE-routers are unaware of MPLS VPN EIGRP parameters must be agreed upon with service provider

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-28

The MPLS VPN technology has the following routing requirements: The customer routers should not be aware of MPLS VPN. They should run standard IP routing software. The provider core routers (P-routers) must not carry VPN routes, in order to ensure the MPLS VPN solution is scalable. The provider edge routers (PE-routers) must support MPLS VPN services and traditional Internet services. The MPLS VPN backbone looks like a standard corporate backbone to the CE-routers. The CErouters run standard IP routing software and exchange routing updates with the PE-routers that appear to them as normal routers in customer’s network. The standard design rules that are used for enterprise MPLS VPN backbones can be applied to the design of the customer’s network. The P-routers are hidden from the customer’s view and CE-routers are unaware of the MPLS VPN. The internal topology of the MPLS backbone is therefore transparent to the customer.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-103

Ethernet Port-to-Port Connectivity Customer routers R1 and R2 exchange Ethernet frames Frame propagation occurs across the MPLS transport network – Ethernet frames: from R1 to PE1 and from PE2 to router R2 – MPLS packet: Between PE1 and PE2 EoMPLS service does participate in Spanning Tree Protocol nor learns MAC addresses

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-29

An MPLS backbone provides a Layer 2 Ethernet port-to-port connection between the two customer routers R1 and R2. Routers R1 and R2 are exchanging Ethernet frames. The Provider Edge 1 (PE1) router takes whatever Ethernet frame it receives from router R1 on the link to PE1, encapsulates it into an MPLS packet, and forwards it across the backbone to the PE2 router. PE2 de-encapsulates the MPLS packet and reproduces the Ethernet frame on its link towards router R2. The AToM feature does not include any MAC layer address learning and filtering. That means that routers PE1 and PE2 do not filter any frames based on those addresses. Nor does the AToM feature use STP (Spanning Tree Protocol). Bridge protocol data units (BPDUs) are propagated transparently and not processed. The LAN loop detection must be performed by other functions or avoided by design.

2-104

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ethernet VLAN Connectivity Customer routers R1 and R2 exchange Ethernet frames via VLAN subinterfaces Frame propagation occurs across the MPLS transport network – Ethernet frames: from R1 to PE1 and from PE2 to router R2 – MPLS packet: Between PE1 and PE2 EoMPLS service does participate in Spanning Tree Protocol nor learns MAC addresses

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-30

The two customer routers R1 and R2 are connected to the MPLS edge routers PE1 and PE2 via VLAN subinterfaces. The interface encapsulation between routers R1 and R2 and the PE routers supports VLANs. Different subinterfaces in the PE routers are used to connect to different VLANs. The PE1 subinterface to the VLAN where router R1 is connected is used for AToM forwarding. When an Ethernet frame arrives on the specific VLAN subinterface, it is encapsulated into MPLS and forwarded across the backbone to router PE2. Router PE2 de-encapsulates the packet and reproduces the Ethernet frame on the outgoing subinterface toward router R2. Although the learning of MAC addresses and STP are not features of AToM, combining AToM with a LAN switch allows the service provider to utilize those missing features.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-105

EIGRP over EoMPLS

Îďý · ˛¬ »® şż˝ » Úż ­¬Ű ¬¸ »® ˛» ¬đ ńđ ·° żĽ Ľ® »­ ­ ďçî ňď ęč ňď ňď đď îë ëň îë ëň îëë ňî îě ˙ ® ±« ¬» ® » ·ą ®° ďď 𠲻¬ ©± ®µ ď éî ňďę ňď ňđ đ ňđ ňđň îë ë ˛»¬ ©± ®µ ď çî ňďę čň ďň đ

Îîý

Îď ý­ ¸±© · ° »·ą ®° ˛ »· ą¸ ľ±® ­ ×Đ óŰ ×ŮÎ Đ ˛» ·ą¸ ľ± ®­ ş ±® °® ±˝ »­ ­ ďď đ Ř ß ĽĽ ®» ­­ × ˛¬ »®ş ż˝ » ر ´Ľ Ë °¬ ·ł » Í ÎĚ Ě ř­ »˝÷ ř ł­ ÷ đ ď çî ňď ęč ňďň ďđ î Ú »đ ńđ ďđ đ đć đé ćî î ďđ

ÎĚ Ń

Ď Í »Ż Ý ˛¬ Ň «ł îî čđ đ ë

·˛ ¬» ®ş ż˝ » Ú ż­ ¬Ű ¬¸ »®˛ »¬ đń đ · ° żĽ Ľ®» ­­ ď çî ňď ęčň ďň ďđ î îë ëňî ëë ňî ëë ňî îě ˙ ®± «¬ »® »· ą® ° ďď đ ˛ »¬ ©± ®µ ďé îň ďé ňî ňđ đň đň đň îë ë ˛ »¬ ©± ®µ ďç îň ďę čň ďňđ

Î îý ­¸ ±© ·° » ·ą ®° ˛» ·ą ¸ľ ±® ­ × Đó Ű× ŮÎ Đ ˛ »· ą¸ ľ± ®­ ş± ® °® ±˝ »­­ ď ďđ Ř ß ĽĽ® »­ ­ ײ ¬» ®ş ż˝ » Ř ±´ Ľ Ë °¬· ł» Í ÎĚ Ě ř ­» ˝÷ ř ł­ ÷ đ ď çîň ďę čň ďň ďđ ď Ú» đń đ ďđ đ đćď éć đî ďđ

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

Î ĚŃ

Ď Í» Ż Ý ˛¬ Ň« ł ď íč đ đ ë

RO UTE v 1.0—2-31

In the example in the slide, it is assumed that the MPLS network is configured properly and only the EIGRP configuration is observed. When deploying EIGRP over EoMPLS, there are no changes to the EIGRP configuration from the customer perspective. EIGRP needs to be enabled with the correct autonomous system (AS) number (the same on both routers R1 and R2). In addition, the network commands must include all of the interfaces required in the EIGRP process. This applies to the link toward routers PE1 and PE2 as well as routers R1 and R2, which will form the neighbor relationship to each other over the MPLS backbone. From the EIGRP perspective, the MPLS backbone and routers PE1 and PE2 are not visible. A neighbor relationship is established directly between routers R1 and R2 as it is visible from the show ip eigrp neighbors command output.

2-106

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP over Layer 3 MPLS VPN

Îďý · ˛¬ »® şż˝ » Úż ­¬Ű ¬¸ »® ˛» ¬đ ńđ ·° żĽ Ľ® »­ ­ ďçî ňď ęč ňď ňî îë ëň îë ëň îë ëňî ëî ˙ ® ±« ¬» ® » ·ą ®° ďď 𠲻¬ ©± ®µ ď éî ňďę ňď ňđ đ ňđ ňđň îë ë ˛»¬ ©± ®µ ď çî ňďę čň ďň đ

Îîý

Î ďý ­¸± © ·° »· ą® ° ˛» ·ą ¸ľ± ®­ × Đó Ű×Ů ÎĐ ˛ »·ą ¸ľ ±® ­ ş± ® ° ®± ˝» ­­ ď ďđ Ř ßĽ Ľ® »­ ­ ײ ¬»® şż ˝» Ř ±´Ľ Ë° ¬· ł» ÍÎ ĚĚ ř ­»˝ ÷ řł ­÷ đ ďç îň ďę čňď ňď Ú» đńđ ďđ đđ ćđ éć îî ďđ

Î ĚŃ

Ď Í» Ż ݲ ¬ Ň« ł î îčđ đ ë

·˛ ¬» ®ş ż˝ » Ú ż­ ¬Ű ¬¸ »®˛ »¬ đń đ · ° żĽ Ľ®» ­­ ď çî ňď ęčň îň î îë ëň îëë ňî ëë ňî ëî ˙ ®± «¬ »® »· ą® ° ďď đ ˛ »¬ ©± ®µ ďé îň ďé ňî ňđ đň đň đň îë ë ˛ »¬ ©± ®µ ďç îň ďę čň îňđ

Î îý ­¸ ±© ·° » ·ą ®° ˛» ·ą ¸ľ ±® ­ × Đó Ű× ŮÎ Đ ˛ »· ą¸ ľ± ®­ ş± ® °® ±˝ »­­ ď ďđ Ř ß ĽĽ® »­ ­ ײ ¬» ®ş ż˝ » Ř ±´ Ľ Ë °¬· ł» Í ÎĚ Ě ř ­» ˝÷ ř ł­ ÷ đ ď çîň ďę čň îň î Ú» đń đ ďđ đ đćď éć đî ďđ © 2009 Cis co S y st em s, Inc. A ll right s reserved.

Î ĚŃ

Ď Í» Ż Ý ˛¬ Ň« ł ď íč đ đ ë RO UTE v 1.0—2-32

Routers R1 and R2 are deployed with EIGRP as if there were a corporate core network between them. EIGRP is enabled on the proper interfaces using the network command. The only difference is that the customer has to agree with the service provider regarding the EIGRP parameters (such as the AS number, authentication password, and so on), as these parameters are often governed by the service provider. The PE routers receive IPv4 routing updates from the CE routers and install these updates in the appropriate virtual routing and forwarding (VRF) table. This part of the configuration and operation is the responsibility of a service provider.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-107

Summary This topic summarizes the key points that were discussed in this lesson.

Summary When EIGRP is deployed over a Frame Relay physical interface, neighbor loss is detected after the hold time expires or all DLCIs are down. EIGRP routing behavior over Frame Relay multipoint interfaces is equivalent to NBMA physical interfaces. When EIGRP is deployed over a Frame Relay point-to-point interface, neighbor loss is detected after the hold time expires or the interface DLCI goes down EIGRP performs equal-cost load balancing by default for up to four paths (up to six paths can be supported).

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-33

Summary (Cont.) To support unequal-cost load balancing, a multiplier parameter (variance) should be configured. EIGRP uses up to 50% of the bandwidth of an interface by default. This may not be the best option for all WAN links, due to the inherent differences in the operational characteristics of WANs. CE-routers connected to a service provider’s EoMPLS (Layer 2 MPLS VPN) treat the connection as a separate subnet. Therefore, EIGRP operates normally without changes in the basic configuration. A customer connected to a Layer 3 MPLS VPN must agree with its service provider on EIGRP parameters (AS number, authentication, and so on) in order to deploy routing.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

2-108

Implementing Cisco IP Routing (ROUTE) v1.0

RO UTE v 1.0—2-34

© 2009 Cisco Systems, Inc.

Lesson 5

Lab 2-2 Debrief Overview In Lab 2-2, students configure and verify EIGRP circuit emulation and Frame Relay operations. First, they configure EIGRP on point-to-point interfaces, then multipoint interfaces. After that, they adjust EIGRP over multipoint WAN interface and configure EIGRP unequal-cost path load balancing.

Objectives Upon completing this lesson, you will be able to configure and verify EIGRP circuit emulation and Frame Relay operations. This ability includes being able to meet these objectives: Complete the lab overview and verification Describe a sample solution and alternatives

Lab Overview and Verification This topic describes the lab topology and key checkpoints used to create a solution and to start with the verification.

Lab Topology

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-2

The figure above presents the physical lab topology used for Lab 2-2: configuring and verifying EIGRP circuit emulation and Frame Relay operations. The topology uses four pod routers and two backbone routers. All routers participate in the EIGRP routing protocol. Based on the topology, students will identify the required parameters and EIGRP configuration over point-to-point and multipoint WAN interfaces.

2-110

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab Review: What Did You Accomplish? Task 1: Configure EIGRP over point-to-point WAN interfaces – What steps did you take to configure the EIGRP routing protocol on point-to-point WAN interfaces? – How do you automatically configure EIGRP to advertise any additional network that is added to the router? – Can a secondary IP address be added to the router? Task 2: Configure EIGRP over a multipoint WAN interface – What steps did you take to configure the EIGRP routing protocol on multipoint WAN interfaces?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1. 0—2-3

Implementing an EIGRP-Based Solution

2-111

Lab Review: What Did You Accomplish? (Cont.) Task 3: Adjusting EIGRP operation over a multipoint WAN interface – What is an EIGRP split horizon? – How can an EIGRP split horizon behavior be changed on a WAN multipoint interface? Task 4—Deploying EIGRP unequal-cost path load balancing – What do you use to manipulate the path in an EIGRP routing protocol? – How can you perform path manipulation without using path control tools?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-4

In the first task, you configured EIGRP over point-to-point WAN interfaces. The EIGRP configuration automatically advertises any additional network that is added to the router. You also added a secondary IP address to the router. In the second task, you configured EIGRP over a multipoint WAN interface. Again, the EIGRP configuration automatically advertises any additional network that is added to the router. In the third task, you configured additional EIGRP functionalities in order to adjust the EIGRP operation over a multipoint WAN interface. Split horizon was disabled. In the fourth task, you deployed EIGRP unequal-cost path load balancing. In order to manipulate the path, you changed the metric in EIGRP.

2-112

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Verification Did you have enough information to create the implementation plan? Do EIGRP-enabled routers form adjacencies on point-to-point and multipoint links after EIGRP is configured? Do you see all of the EIGRP-advertised networks in the IP routing table as EIGRP routes (after point-to-point and after multipoint configuration respectively)? What are the changes when split horizon is disabled on the interface? What is changed to manipulate the path of the packets and what must be implemented to perform unequal-cost load balancing?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-5

A common approach to verifying the implementation process for a routing protocol is to answer the following questions: Did you have sufficient information to create the implementation plan? Do EIGRP-enabled routers form adjacencies on point-to-point and multipoint links after EIGRP is configured? Do you see all of the EIGRP-advertised networks in the IP routing table as EIGRP routes (after point-to-point and multipoint configuration)? What are the changes when split horizon behavior is disabled on the interface? What is changed to manipulate the path of the packets and what must be implemented to perform unequal-cost load balancing?

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-113

Checkpoints Configure EIGRP routing protocol on point-to-point interfaces. Automatically advertise any additional network that is added to the router. Ensure EIGRP networks are present in the IP routing table. Configure EIGRP routing protocol on multipoint interfaces. Ensure new EIGRP networks are present in the IP routing table. Simulate a connectivity failure between routers R3 and R4 and examine the EIGRP operation afterwards.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

2-114

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v1. 0—2-6

© 2009 Cisco Systems, Inc.

Checkpoints (Cont.) Change the EIGRP split horizon behavior on the WAN multipoint interface Adjust the metric to manipulate load balancing. Simulate a connectivity failure between routers R1 and R3 and examine the EIGRP operation afterwards. Change the EIGRP metric to manipulate unequal-cost path load balancing. Verify connectivity.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-7

During the configuration and verification phase, the network operator deals with several checkpoints. After completing all configuration tasks, the network operator has either finished the lab successfully or must perform additional verification and troubleshooting. With different checkpoints, the network operator can verify for proper configuration. The following checkpoints are used for verification: Configure the EIGRP routing protocol on point-to-point interfaces. Automatically advertise any additional network that is added to the router. Ensure that EIGRP networks are present in the IP routing table. Configure the EIGRP routing protocol on multipoint interfaces. Ensure new EIGRP networks are present in the IP routing table. Simulate a connectivity failure between routers R3 and R4 and examine the EIGRP operation afterwards. Change the EIGRP split horizon behavior on the WAN multipoint interface. Adjust the metric to manipulate load balancing. Simulate a connectivity failure between routers R1 and R3 and examine the EIGRP operation afterwards. Change the EIGRP metric to manipulate unequal-cost path load balancing. Verify connectivity.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-115

Sample Solutions and Alternatives This topic describes sample solution and other alternatives.

A Sample Solution EIGRP is configured on point-to-point and multipoint interfaces. All of the specific IP subnets used in the network are advertised, as well as all new networks added later. Split horizon is disabled, and the metric is changed in order to provide load balancing and unequal-cost path load-balancing.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-8

The sample solution includes implementation details and details for each task of the implementation plan. Different solutions are possible and the figure shows a few details of a successful configuration. Proper implementation includes the following details: EIGRP is configured on point-to-point and multipoint interfaces. All of the specific IP subnets used in the network (including all networks added later) are advertised. Split horizon behavior is disabled and the metric is changed in order provide load balancing and unequal-cost path load balancing.

2-116

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternative Solutions A different metric and administrative distance can be applied as well as filtering or static routes can be used in a few segments of the EIGRP network. EIGRP-specific functionalities do not have many alternative solutions; while another routing protocol can be used, this is not a realistic solution.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-9

A different metric and administrative distance can be applied, as well as filtering or static routes can be used in few segments of the EIGRP network to provide a similar solution. However, EIGRP-specific functionalities do not have many alternative solutions. To implement a similar solution, another routing protocol can be used, which is not a realistic solution as changing the routing protocol is not the case during fine tuning of the existing protocol.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-117

Q and A Why is the selection of a routing protocol important? What is the difference between point-to-point and multipoint interfaces when configuring an EIGRP? Why is changing the metric important? How does split horizon work?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-10

The routing protocol, with its metric and administrative distance, exchanges routing updates. It also populates the IP routing table, which is used for destination-based forwarding. Different routing protocols process routing updates in different ways. When configuring EIGRP on point-to-point interfaces, just two routers are connected to the link. They exchange routing updates. If the interface is a multipoint interface, routing updates received from one neighbor must be sent to another neighbor through the same interface. The metric provides the importance or the quality of the routes within a routing protocol. By manipulating the administrative distance and metric value, you can implement path manipulation, as well. Because of the split horizon behavior, the routing updates are not sent back to the interface from which they were received. This breaks the exchange of EIGRP routing updates.

2-118

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary Configure EIGRP on point-to-point interfaces and advertise all of the specific IP subnets in the network; you should also provide automatic advertising of any additional network that is added to the router. Configure EIGRP on the multipoint interfaces and advertise all of the specific IP subnets in the network; you should also provide automatic advertising of any additional network that is added to the router. Manipulate the EIGRP configuration on the multipoint interface by disabling split horizon. Change the metric in order to deploy unequal-cost path load balancing.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

RO UTE v 1.0—2-11

Implementing an EIGRP-Based Solution

2-119

2-120

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 6

Implementing and Verifying EIGRP Authentication Overview You can prevent your router from receiving false route updates by configuring neighbor router authentication. Enhanced Interior Gateway Routing Protocol (EIGRP) neighbor authentication (also called neighbor router authentication or route authentication) can be configured in such a way that routers can participate in routing based on predefined passwords. This lesson describes EIGRP Message Digest 5 (MD5) authentication and how to configure and verify it.

Objectives Upon completing this lesson, you will be able to implement and verify authentication in an EIGRP network. This ability includes being able to meet these objectives: Determine router authentication for EIGRP. Determine MD5 authentication for EIGRP. Implement MD5 authentication for EIGRP. Verify MD5 authentication for EIGRP.

Router Authentication for EIGRP This topic describes the router authentication used by routing protocols.

Router Authentication Implement security to the routing protocol by supporting authentication A router authenticates the source of each routing update packet that it receives. Prevent false routing updates from updating the routing table: – Prevent deliberate false routing updates sourced by unapproved sources – Ignore malicious updates, thus preventing them from disrupting the routing or taking down the adjacency

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-2

Neighbor router authentication (also called route authentication) can be configured in such way that routers only participate in routing based on predefined passwords. Without neighbor authentication, unauthorized or deliberately malicious routing updates can compromise the security of your network traffic. A security compromise may occur if any unfriendly party interferes with your network. For example, an unauthorized router might launch a fictitious routing update to convince your router to send traffic to an incorrect destination. When neighbor authentication has been configured on routers, those routers authenticate the source of each routing update packet they receive. They do so by exchanging an authentication key that is known to both the sending and the receiving router. By default, no authentication is used for routing protocol packets.

2-122

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Router Authentication (Cont.) Many routing protocols support authentication Simple password authentication is supported by: – OSPF – RIPv2 MD5 authentication is supported by: – EIGRP – OSPF – RIPv2 – BGP

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-3

There are two types of authentication: simple password authentication (also called plaintext authentication) and Message Digest 5 (MD5) authentication. Simple password authentication is supported by Open Shortest Path First (OSPF) and Routing Information Protocol version 2 (RIPv2). MD5 authentication is supported by OSPF, RIPv2, Border Gateway Protocol (BGP), and EIGRP. Note

© 2009 Cisco Systems, Inc.

Authentication for EIGRP, OSPF, and BGP is covered in this course.

Implementing an EIGRP-Based Solution

2-123

Simple Password vs. MD5 Authentication Simple password authentication: – The router sends a packet and a key. – The neighbor checks if the key matches its key. – The process is not secure. MD5 authentication: – This authentication is secure, as described in RFC1321. – This authentication does not include confidentiality (content not encrypted). – The router generates a message digest. – The message digest is sent with the packet. – The key is not sent.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-4

The behavior of simple password authentication is the same as that of MD5 authentication, except that MD5 sends a message digest instead of the authenticating key itself. MD5 creates the message digest using the key and a message, but the key itself is not sent, which prevents it from being read while it is being transmitted. Simple password authentication sends the authenticating key itself over the wire. Note

Note that simple password authentication is not recommended for use as part of your security strategy, because it is vulnerable to passive attacks. Anybody with a link analyzer could easily view the password on the wire. The primary use of simple password authentication is to avoid accidental changes to the routing infrastructure. Using MD5 authentication, however, is a recommended security practice.

With simple password authentication, a password (key) is configured on a router, and each participating neighbor router must be configured with the same key. When a packet is sent over the wire, the password, in plaintext, is sent along with it. MD5 authentication is a cryptographic authentication. A key (password) and key ID are configured on each router. The router uses an algorithm to generate a message digest (also called a hash) from the key and key ID, and appends the message digest to the packet. Unlike simple authentication, the key is not exchanged over the wire; the message digest is sent instead of the key, which ensures that no one can eavesdrop on the line and learn keys during transmission. Although MD5 authentication provides authenticity, it does not provide confidentiality. The content of the routing update is not encrypted.

2-124

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Note

© 2009 Cisco Systems, Inc.

As with all keys, passwords, and other security secrets, it is imperative that you closely guard authenticating keys used in neighbor authentication. In order to obtain the security benefits of this feature, you must keep all authenticating keys confidential. Also, when performing router management tasks via Simple Network Management Protocol (SNMP), do not ignore the risk associated with sending keys using non-encrypted SNMP.

Implementing an EIGRP-Based Solution

2-125

MD5 Authentication for EIGRP This topic describes MD5 authentication as it is used in EIGRP.

MD5 Authentication for EIGRP EIGRP supports MD5 authentication. The router generates a MD5 message digest. – Multiple keys can be configured in all EIGRP routers. The receiving router computes the MD5 hash from the received EIGRP information. Time should be synchronized between all routers, and NTP can be used.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-5

EIGRP supports MD5 authentication to prevent the introduction of unauthorized or false routing messages from unapproved sources. EIGRP neighbor authentication (also called neighbor router authentication or route authentication) can be configured in such way that routers can participate in routing based on predefined passwords. By default, no authentication is used for EIGRP packets. EIGRP must be configured to use MD5 authentication. When neighbor authentication has been configured on a router, the router authenticates the source of each routing update packet that it receives. In order to start using EIGRP MD5 authentication, you must configure an authenticating key (sometimes referred to as a password) and a key identifier on both the sending router and the receiving router. Each EIGRP router takes the key and key ID and generates a message digest that is appended to each routing update and sent to the neighbor. The receiving router computes the MD5 hash from the received EIGRP information. If the hash matches the value received, the packet is accepted. If it does not, the packet is silently dropped. Each key has its own key ID, which is stored locally. The combination of the key ID and the interface associated with the message uniquely identifies the authentication algorithm and the MD5 authentication key in use. You can increase the security of EIGRP MD5 authentication by making frequent key changes. The definition of multiple keys is supported, which can be changed based on time that is defined in the configuration. Transitioning between the keys is implemented in a way that provides non-disruptive exchange of EIGRP routing updates. The key changes must be well-planned and supported by the time synchronization between the routers. The key rollover works only if the times on the adjacent routers are synchronized. You can use several mechanisms for time synchronization. Network Time Protocol (NTP) is the most commonly used time synchronization mechanism to ensure that the correct time is used by all the participating EIGRP routers using the key rollover mechanism. 2-126

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Key Chain EIGRP allows keys to be managed using key chains – A key chain is a set of keys associated with an interface. – Includes key IDs, keys, and key lifetimes – The first valid activated key is used in the outgoing direction. – Incoming packets are checked against all valid keys.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-6

EIGRP allows keys to be managed using key chains. Each key definition within the key chain can specify a time duration for when that key will be activated (its lifetime). Then, during a given key's lifetime, routing update packets are sent with this activated key. Only one authentication packet is sent, regardless of how many valid keys exist. The software examines the key numbers in order from lowest to highest. It then uses the first valid key it encounters. Keys cannot be used at times when they are not activated. Therefore, for a given key chain, you should ensure that key activation times overlap. This will help you avoid any period of time for which no key is activated. If a period occurs during when no key is activated, neighbor authentication cannot occur, and therefore routing updates will fail. Note that the router needs to know the correct time to be able to rotate through keys in a way that is synchronized with the other participating routers, so that all routers are using the same key at the same moment. Refer to the Network Time Protocol (NTP) and calendar commands in the “Performing Basic System Management” chapter of the Cisco IOS Configuration Fundamentals Configuration Guide for information about configuring the time on your router.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-127

Implementing MD5 Authentication for EIGRP This topic describes how to configure MD5 authentication for EIGRP.

Planning for EIGRP Authentication Examine the existing EIGRP configuration Define the authentication type Define how many keys will be used Define if an optional lifetime parameter will be used

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-7

Before configuring authentication for EIGRP, a network administrator must examine the existing EIGRP configuration and define the network requirements. The existing EIGRP configuration defines which autonomous system (AS) number is used for EIGRP and which routers and interfaces participate in the EIGRP configuration. The network requirements for EIGRP authentication define which parameters must be gathered and include the definition of the authentication type, number of keys used in the EIGRP network, and optional lifetime parameters used. The next step is to gather of all of the parameters needed to provide enough details for the network operator to start setting up EIGRP authentication.

2-128

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Requirements for EIGRP Authentication EIGRP AS number Authentication mode One or more keys Key lifetimes (optional)

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-8

Requirements to configure EIGRP authentication include the following elements: The EIGRP AS number The authentication mode selected The definition of one or more keys The lifetime of each defined key The EIGRP AS number must be defined, as authentication is locked to the EIGRP process. The authentication mode used is MD5. The definition of the keys is a process by which the network administrator and network designer must develop a security plan. They are not trying to encrypt the packet, but authenticate the source of the EIGRP routing updates. Using more keys and changing them can reduce the potential risk. When more keys are used, it makes sense to change the keys based on predefined time intervals. A key’s lifetime can be defined. It is optional and requires an NTP server in order to synchronize the clocks of all routers running EIGRP.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-129

Steps to Configure EIGRP MD5 Authentication Configure the authentication mode for EIGRP Configure the key chain Configure the lifetime of each key in the key chain Enable authentication to use the key or keys in the key chain

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-9

EIGRP MD5 authentication configuration steps: Step 1

Configure the authentication mode for EIGRP.

Step 2

Configure the key chain.

Step 3

Optional: Configure the lifetime parameters for the keys.

Step 4

Enable authentication to use the key or keys in the key chain.

To complete these steps, you must have information about the existing EIGRP process, definitions of all the keys, and any lifetime parameters to be used in the configuration.

2-130

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Configure Authentication Mode Îďř˝±˛ş·ą÷ý

·˛¬»®şż˝» Í»®·ż´đńđńď ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ďďđ łĽë łĽë Îîř˝±˛ş·ą÷ý

·˛¬»®şż˝» Í»®·ż´đńđńď ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ďď𠳼ë ďď𠳼ë

Specify the type of authentication used in EIGRP packets for router R1 and R2

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-10

You must configure authentication between any two neighbors exchanging EIGRP routing updates. You must also use the correct AS number and enable the authentication configuration on all interfaces between the neighbors across the EIGRP domain. The example in this slide shows two routers, R1 and R2, that are running the EIGRP process with AS number 110. They are connected via the serial 0/0/1 interfaces and configuration must be applied to both interfaces involved. To configure MD5 authentication for EIGRP, complete the following steps: Step 1

Enter the configuration mode for the interface on which you want to enable authentication.

Step 2

Specify the type of the authentication using the ip authentication mode eigrp 110 md5 interface command.

The only authentication type available is MD5, and AS number 110 is used in the example on this slide, where both routers R1 and R2 are configured for MD5 authentication. When authentication is configured, an MD5 keyed digest is added to each EIGRP packet in the specified AS. For more details about the ip authentication mode eigrp command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-131

Configure the Key Chain Îďř˝±˛ş·ą÷ý

µ»§ ˝¸ż·˛ ®±«¬»®Îｸż·˛ µ»§ ď µ»§ó­¬®·˛ą ş·®­¬µ»§ µ»§ î µ»§ó­¬®·˛ą ­»˝±˛Ľµ»§

Îîř˝±˛ş·ą÷ý

µ»§ ˝¸ż·˛ ®±«¬»®Îż·˛ µ»§ ď µ»§ó­¬®·˛ą ş·®­¬µ»§ µ»§ î µ»§ó­¬®·˛ą ­»˝±˛Ľµ»§

Create the key-chain to enter key chain key configuration mode. Create an authentication key on a key chain. Define the authentication string for a key (password).

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-11

When authentication is enabled on the interface, a group of authentication keys must be defined. The key chain global configuration command is used to define all of the keys used for EIGRP MD5 authentication. Once you are in the key chain configuration mode, use the key command to identify the key in the key chain. Each key is defined by the number, which defines the key ID. When the key command is used, the configuration enters the key chain key configuration mode, where the key-string authentication-key configuration command must be used to specify the authentication string (or password). The key ID and authentication string must be the same on all neighboring routers. In the example on this slide, each interface is configured to enter its own key chain. The key chain configured on router R1 is “routerR1chain” and key-chain on router R2 is “routerR2chain”. Inside each of the key chains, two keys are defined, key 1 and key 2. Note

The key ID number of an authentication key on a key chain can range from 0 to 2147483647, and there is no need for the numbers to be consecutive.

Key 1 includes the authentication string “firstkey” and key 2 includes the authentication string “secondkey”. Note

The authentication string used to authenticate sent and received EIGRP packets can contain from 1 to 80 uppercase and lowercase alphanumeric characters; the one exception is that the except that the first character cannot be a number.

For more details about the key chain, key, and key-string (authentication) commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

2-132

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Configure the Lifetime of The Key or Keys Îďř˝±˛ş·ą÷ý µ»§ ˝ ¸ż·˛ ®±«¬ »®Îď˝ ¸ż·˛ µ»§ ď µ»§ 󭬮 ·˛ą ş·®­¬µ »§ ż˝˝ »°¬ó ´·ş»¬·ł» đ ěćđđć đđ Öż ˛ ď îđđç ·˛ş· ˛·¬» ­»˛ Ľó´· ş»¬·ł» đěć đđćđđ Öż˛ ď îđ đç đěćđđć đđ Öż ˛ íď îđđç µ»§ î µ»§ 󭬮 ·˛ą ­»˝±˛Ľ µ»§ ż˝˝ »°¬ó ´·ş»¬·ł» đ ěćđđć đđ Öż ˛ îë îđđç ·˛ş ·˛·¬ » ­»˛ Ľó´· ş»¬·ł» đěć đđćđđ Öż˛ îë î đđç ·˛ş·˛ ·¬»

If you wish, you can define when the key will be accepted or sent.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-12

Once you define more keys and ensure each key includes an authentication string, you can then configure a key lifetime, if you wish. Two commands can be used to define the lifetime of the key. The accept-lifetime command in the key chain key configuration mode is used to set the time-period during which the authentication key on a key chain is received as valid. The sendlifetime command in the key chain key configuration mode is used to set the time-period during which an authentication key on a key chain is valid to be sent. In the example on this slide, router R1 is configured with the key chain routerR1chain and two keys are inside the key chain. Each key has an authentication string and lifetime specified. The network administrator wants to change the keys on all the routers in the network on a regular basis to improve the security, initially every month. One week is enough time to change the keys on all the routers, so the validity of key 2 is configured 1 week before the expiration of key 1 to ensure that all the routers in the network will accept the configuration. The authentication string for key 1 is set to firstkey and the accept-lifetime and send-lifetime commands have been used to specify the validity of key 1. This key is acceptable for use on packets received by router R1 from January 1, 2009 onwards, as specified in the acceptlifetime 04:00:00 Jan 1 2009 infinite command. However, the send-lifetime 04:00:00 Jan 1 2009 04:00:00 Jan 31 2009 command specifies that this key was valid for use when sending packets from January 1, 2009 until January 31, 2009. It will no longer be valid for use in sending packets after 4:00 a.m. on January 31, 2009. The authentication string for key 2 is set to secondkey. The accept-lifetime and send-lifetime commands have been used to specify the validity of key 2, as well as for key 1. Key 2 is acceptable for use on packets received by router R1 from January 25, 2009 onwards, as specified in the accept-lifetime 04:00:00 Jan 25 2009 infinite command. This key can also be used when sending packets from January 25, 2009 onwards, as specified in the send-lifetime 04:00:00 Jan 25 2009 infinite command. When more than one key is configured, key 1 is used first until its lifetime expires. Then the next key is used. The bar chart in this slide presents the result of the configuration. From © 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-133

Starting January 1, 2009, key 1 was used for sent packets as well as for received packets. Starting January 25, 2009, key 2 was valid for sent and received packets, but it was not actually used, since key 1 was still valid. Starting January 31, 2009, key 1 was no longer valid. Immediately key 2 started to be used for all sent and received packets. From January 25, 2009 to January 31, 2009, router R1 will accept and attempt to verify the MD5 digest of any EIGRP packets with a key ID equal to 1 or a key ID equal to 2. All other MD5 packets will be dropped. The syntax of the start time in the accept-lifetime and send-lifetime commands can be either of the following: hh:mm:ss month date year hh:mm:ss date month year When using the infinite parameter to configure the lifetime, the key is valid for use on received packets from the start-time value and never expires. The default start time and the earliest acceptable date is January 1, 1993. If an end time is specified, the key is valid for use on the received packets from the start-time value until the end-time value. The syntax is the same as the start-time value. The end-time value must be after the start-time value. The default end time is infinite. The same or a similar configuration can be applied to router R2 as well. The optional lifetime parameters can be the same or different. It is important that at least one key is valid to send and at least one key is valid as a receive key. Of course both keys must be the same, otherwise it is very likely that the authentication will fail. For more details about the accept-lifetime and send-lifetime commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

2-134

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Enable Authentication of EIGRP Packets Îďř˝±˛ş·ą÷ý

·˛¬»®şż˝» Í»®·ż´đńđńď ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ďďđ ®±«¬»®Îｸż·˛ Îîř˝±˛ş·ą÷ý

·˛¬»®şż˝» Í»®·ż´đńđńď ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ďďđ ®±«¬»®Îż·˛

Enable authentication of EIGRP packets using the key or keys in the key chains routerR1chain and routerR2chain on routers R1 and R2, respectively.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-13

When an authentication type is selected and a key chain is configured, then authentication of EIGRP packets must be enabled on all interfaces participating in the EIGRP domain as well. Authentication is enabled using the ip authentication key-chain eigrp interface command. In the example on this slide, each interface is configured to use keys in its local key chain. Router R1 is configured to use the routerR1chain key chain and router R2 is configured to use the routerR2chain key chain. The key chain contains the list of all the available keys and must be configured separately to specify all of the keys required. The name of the key chain is of local significance and can be different on the two neighboring routers. Note

The name of the authentication key chain is a user-defined string.

For more details about the ip authentication key-chain eigrp command, please check the Cisco IOS IP Routing Protocols Command Reference on the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-135

Router R1 Configuration for MD5 Authentication Îďý 䱫¬°«¬ ±ł·¬¬»Ľâ µ»§ ˝¸ż·˛ ®±«¬»®Îｸż·˛ µ»§ ď µ»§ó­¬®·˛ą ş·®­¬µ»§ ż˝˝»°¬ó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» ­»˛Ľó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç đěćđđćđđ Öż˛ íď îđđç µ»§ î µ»§ó­¬®·˛ą ­»˝±˛Ľµ»§ ż˝˝»°¬ó´·ş»¬·ł» đěćđđćđđ Öż˛ îë îđđç ·˛ş·˛·¬» ­»˛Ľó´·ş»¬·ł» đěćđđćđđ Öż˛ îë îđđç ·˛ş·˛·¬» 䱫¬°«¬ ±ł·¬¬»Ľâ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňďęňďňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Í»®·ż´đńđńď ľż˛Ľ©·Ľ¬¸ îëę ·° żĽĽ®»­­ ďçîňďęčňďňďđď îëëňîëëňîëëňîîě ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ďďđ łĽë ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ďďđ ®±«¬»®Îｸż·˛ ˙ ®±«¬»® »·ą®° ďď𠲻¬©±®µ ďéîňďęňďňđ đňđňđňîëë ˛»¬©±®µ ďçîňďęčňďňđ ż«¬±ó­«łłż®§

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-14

The configuration of router R1 on this slide shows that MD5 authentication is configured on the serial 0/0/1 interface with the ip authentication mode eigrp 110 md5 command. The ip authentication key-chain eigrp 110 routerR1chain command specifies that the key chain routerR1chain is to be used. The key chain routerR1chain command indicates to enter configuration mode for the routerR1chain key chain. Two keys are defined. Key 1 is set to firstkey with the key-string firstkey command. This key is acceptable for use on packets received by router R1 from January 1, 2009 onward, as specified in the accept-lifetime 04:00:00 Jan 1 2009 infinite command. In contrast, the send-lifetime 04:00:00 Jan 1 2009 04:00:00 Jan 31 2009 command specifies that this key is valid for use when sending packets from January 2, 2009 to January 31, 2009. Key 2 is set to secondkey with the key-string secondkey command. This key is acceptable for use on packets received by router R1 from January 25, 2009 onward, as specified in the acceptlifetime 04:00:00 Jan 25 2009 infinite command. This key can also be used when sending packets from January 25, 2009 onward, as specified in the send-lifetime 04:00:00 Jan 25 2009 infinite command. Router R1 will therefore accept and attempt to verify the MD5 digest of any EIGRP packets with a key ID equal to 1. Router R1 will also accept a packet with a key ID equal to 2. All other MD5 packets will be dropped. Router R1 will send all EIGRP packets using key 2, because key 1 is no longer valid for use when sending packets. MD5 EIGRP authentication configuration on router R2 is very similar. The lifetimes of the keys are typically the same, and the key chain names can be different (it is of local significance in the router). The IP addresses on the interfaces are different and set according to the IP addressing scheme of router R2. In the ip authentication key-chain eigrp command, the configuration must refer to its local key chain name and networks advertised under the EIGRP 110 routing process must reflect the real networks used.

2-136

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Verifying MD5 Authentication for EIGRP This topic describes how to verify MD5 authentication for EIGRP.

Verifying MD5 Authentication for EIGRP Îď ý­¸± © ·° » ·ą®° ˛»·ą ¸ľ±®­ ×Đ óŰ×Ů ÎĐ ˛»·ą¸ľ± ®­ ş± ® °®± ˝»­­ ďďđ Ř ßĽĽ ®»­­ ײ¬ »®şż ˝» đ

ďçî ňďęč ňďňďđ î

Í»đ ńđńď

Ř ±´Ľ Ë°¬· ł» ÍÎĚĚ ř ­»˝÷ řł­÷ ďî đđćđ íćďđ ďé

ÎĚŃ

Ď Í»Ż ݲ¬ Ň«ł îîčđ đ ďě

Verify that the EIGRP neighbor relationship is up Îď ý­¸± © ·° ® ±«¬» ä± «¬°« ¬ ±ł·¬¬»Ľâ Ůż ¬»©ż § ±ş ´ż­¬ ® »­±® ¬ ·­ ˛±¬ ­ »¬ Ü ďéî ňďéňđňđń ďę Ĺç đńěđë ďěëę đĂ Ş· ż ďçî ňďęč ňďňď đîô đ đćđîć îîô Í »®·ż ´đńđ ńď ďéî ňďęň đňđń ďę ·­ Şż®· żľ´§ ­«ľ˛ »¬¬» Ľô î ­ «ľ˛» ¬­ô î łż­ µ­ Ü ďéîňďęňđ ňđńďę ·­ ż ­«łł ż®§ô đđćí ďćíď ô Ň«´ ´đ Ý ďéîňďęňď ňđńîě ·­ Ľ ·®»˝¬ ´§ ˝± ˛˛»˝ ¬»Ľô Úż­¬ ۬¸» ®˛»¬đ ńđ ďçî ňďęč ňďňđ ńîě · ­ Şż® ·żľ´ § ­«ľ ˛»¬¬ »Ľô î ­«ľ˛ »¬­ô î łż ­µ­ Ý ďçîňďęčň ďňçęń îé ·­ Ľ·®» ˝¬´§ ˝±˛˛ »˝¬» Ľô Í» ®·ż´ đńđńď Ü ďçîňďęčň ďňđńî ě ·­ ż ­«ł łż®§ ô đđć íďćí ďô Ň« ´´đ

Verify that the IP routing table is populated © 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-15

If authentication is not successful, then routers will not process EIGRP packets and will not form neighbor relationships. Also, routers will not build the EIGRP tables and populate the IP routing table with EIGRP routes. The output on the figure on this slide shows two commands that can be used to verify the EIGRP neighbors and IP routing table. The show ip eigrp neighbors verification command shows the EIGRP neighbors table on router R1, which indicates that the two routers have successfully formed an EIGRP adjacency. The show ip route verification command on router R1 shows that the 172.17.0.0 network has been learned via EIGRP over the serial connection, which proves that the authentication must have been successful. For more details about the show ip eigrp neighbors and show ip route commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-137

Verifying MD5 Authentication for EIGRP (Cont.) Îď ý­¸± © µ»§ ˝¸ż· ˛ Ő» §ó˝¸ ż·˛ ®±«¬»® Îｸż ·˛ć µ»§ ď óó ¬»¨ ¬ Ťş· ®­¬µ» §ţ ż˝˝» °¬ ´· ş»¬· ł» řđ ěćđđ ćđđ Öż ˛ ď îđđç ÷ ó ř ż´©ż §­ Şż ´·Ľ÷ ĹŞż´· Ľ ˛± ©Ă ­»˛Ľ ´·ş »¬·ł» řđěć đđćđ đ Öż˛ ď îđ đç÷ ó řđě ćđđć đđ Öż ˛ íď îđđç÷ µ»§ î óó ¬»¨ ¬ Ť­» ˝±˛Ľµ »§ţ ż˝˝» °¬ ´· ş»¬· ł» řđ ěćđđ ćđđ Öż ˛ îë îđđ ç÷ ó řż´© ż§­ Ş ż´·Ľ÷ ĹŞż´ ·Ľ ˛ ±©Ă ­»˛Ľ ´·ş »¬·ł» řđěć đđćđ đ Öż˛ îë î đđç÷ ó řż ´©ż§ ­ Şż´ ·Ľ÷ Ĺ Şż´· Ľ ˛±© Ă

Verify the key chains and keys This output of the show key chain command is from January 27, 2009.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-16

You can use the show key chain verification command to see the key chain, key string, and the lifetime of the keys configured under the key chain. The keys must be the same on both neighbors and the lifetime must be set properly. The output of the show key chain command on router R1 is shown on this slide. Key chain routerR1chain and both key 1 (with authentication string firstkey) and key 2 (with authentication string secondkey) are shown in the sample output. Under each key, the lifetime of the key is shown as well. You can verify the configuration by checking that the output is the same from the neighboring router (router R2 in our topology). For more details about the show key chain command, please check the Cisco IOS IP routing protocols command reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

2-138

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Verifying MD5 Authentication for EIGRP (Cont.) ÎďýĽ »ľ«ą »·ą®° °ż˝µ »¬ Ű×ŮÎ Đ Đż˝ µ»¬­ Ľ»ľ« ąą·˛ ą ·­ ± ˛ řËĐÜß ĚŰô Î ŰĎËŰ ÍĚô Ď ËŰÎÇ ô ÎŰĐ ÔÇô Ř ŰÔÔŃ ô ×ĐČ ÍßĐô ĐÎŃŢ Űô ßÝ Őô ÍĚ ËŢô Í×ßĎ ËŰÎÇô Í×ßÎ ŰĐÔÇ ÷ öÖż˛ îď ď ęćíčć ëďňé ěëć Ű ×ŮÎĐ ć ®»˝ »·Ş»Ľ °ż˝ µ»¬ © ·¬¸ Ó Üë ż« ¬¸»˛ ¬·˝ż ¬·±˛ ô µ»§ ·Ľ ă ď öÖż˛ îď ď ęćíčć ëďňé ěëć Ű ×ŮÎĐ ć λ˝ »·Ş»Ľ ŘŰÔ ÔŃ ±˛ Í»®· ż´đń đńď ˛ ľ® ďç îňďę čňďň ďđî öÖż˛ îď ď ęćíčć ëďňé ěëć ßÍ ď ďđô Ú´żą­ đ¨đ ô Í»Ż đńđ ·ĽľĎ đńđ ··Ľľ Ď «˛ń ®»´§ đńđ °» »®Ď «˛ń®» ´§ đń đ

ÎîýĽ »ľ«ą »·ą®° °ż˝µ »¬ Ű×ŮÎ Đ Đż˝ µ»¬­ Ľ»ľ« ąą·˛ ą ·­ ± ˛ řËĐÜß ĚŰô Î ŰĎËŰ ÍĚô Ď ËŰÎÇ ô ÎŰĐ ÔÇô Ř ŰÔÔŃ ô ×ĐČ ÍßĐô ĐÎŃŢ Űô ßÝ Őô ÍĚ ËŢô Í×ßĎ ËŰÎÇô Í×ßÎ ŰĐÔÇ ÷ Îîý öÖż˛ îď ď ęćíčć íčňí îďć Ű ×ŮÎĐ ć ®»˝ »·Ş»Ľ °ż˝ µ»¬ © ·¬¸ Ó Üë ż« ¬¸»˛ ¬·˝ż ¬·±˛ ô µ»§ ·Ľ ă ď öÖż˛ îď ď ęćíčć íčňí îďć Ű ×ŮÎĐ ć λ˝ »·Ş»Ľ ŘŰÔ ÔŃ ±˛ Í»®· ż´đń đńď ˛ ľ® ďç îňďę čňďň ďđď öÖż˛ îď ď ęćíčć íčňí îďć ßÍ ď ďđô Ú´żą­ đ¨đ ô Í»Ż đńđ ·ĽľĎ đńđ ··Ľľ Ď «˛ń ®»´§ đńđ °» »®Ď «˛ń®» ´§ đń đ

Use debug to verify the operation

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-17

Use the debug eigrp packet command to display general debugging information. If a communication session is closing when it should not be, an end-to-end connection problem could be the cause. The debug eigrp packet command is useful for analyzing the messages traveling between the local and remote hosts, including authentication messages. The sample output on this slide shows successful MD5 authentication. The output of the debug eigrp packet command on router R1 shows that router R1 is receiving EIGRP packets with MD5 authentication, with a key ID equal to 1, from router R2. Similarly, the output of the debug eigrp packet command on router R2 shows that router R2 is receiving EIGRP packets with MD5 authentication, with a key ID equal to 2, from router R1. For more details about the debug eigrp packet command, please check the Cisco IOS debug command reference via the following link: http://www.cisco.com/en/US/docs/ios/debug/command/reference/db_book.html

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-139

Misconfigured Key ÎďýĽ »ľ«ą »·ą®° °ż˝µ »¬­ Ű×ŮÎ Đ Đż˝ µ»¬­ Ľ»ľ« ąą·˛ ą ·­ ± ˛ řËĐÜß ĚŰô Î ŰĎËŰ ÍĚô Ď ËŰÎÇ ô ÎŰĐ ÔÇô Ř ŰÔÔŃ ô ×ĐČ ÍßĐô ĐÎŃŢ Űô ßÝ Őô ÍĚ ËŢô Í×ßĎ ËŰÎÇô Í×ßÎ ŰĐÔÇ ÷ Îďý öÖż˛ íď î íćîđć îďňç ęéć Ű ×ŮÎĐ ć Í»˛ Ľ·˛ą ŘŰÔÔ Ń ±˛ Í»®·ż ´ďńđ öÖż˛ íď î íćîđć îďňç ęéć ßÍ ď ďđô Ú´żą­ đ¨đ ô Í»Ż đńđ ·ĽľĎ đńđ ··Ľľ Ď «˛ń ®»´§ đńđ öÖż˛ íď î íćîđć îîňí ďëć Ű ×ŮÎĐ ć °µ¬ µ»§ ·Ľ ă îô ż «¬¸»˛ ¬·˝ż ¬·±˛ ł·­ł ż¬˝¸ öÖż˛ íď î íćîđć îîňí ďëć Ű ×ŮÎĐ ć Í»® ·ż´ďńđć · ą˛±®» Ľ °ż˝ µ»¬ ş ®±ł ďçîň ďęčň ďňďđî ô ±°˝ ±Ľ » ă ë ř·˛ Şż´·Ľ ż«¬¸ »˛¬· ˝ż¬· ±˛÷

The MD5 authentication key is different for routers R1 and R2. Îď ý­¸± © ·° » ·ą®° ˛»·ą ¸ľ±® ­ ×Đ óŰ×Ů ÎĐ ˛»· ą¸ľ± ®­ ş± ® °®±˝»­ ­ ďďđ

The EIGRP neighbor relationship is down.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-18

The sample output on this slide shows the MD5 authentication problems. The output of the debug eigrp packet command on router R1 shows that router R1 is receiving EIGRP packets with MD5 authentication, with a key ID equal to 2, from router R2, but there is an authentication mismatch. The EIGRP packets from router R2 are ignored and the neighbor relationship is declared to be down. The output of the show ip eigrp neighbors command confirms that router R1 does not have any EIGRP neighbors. The two routers keep trying to reestablish their neighbor relationship using key 2. Because of the different key strings used by each router in this scenario, router R1 will authenticate hello messages sent by router R2 using the key string secondkey. However, when router R1 sends a hello message back to router R2 using a different key string, an authentication mismatch occurs.

2-140

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary There are two types of router authentication: simple password and MD5 authentication. When EIGRP authentication is configured, the router generates and checks every EIGRP packet and authenticates the source of each routing update packet that it receives. EIGRP supports MD5 authentication. To configure MD5 authentication, use the ip authentication mode eigrp and ip authentication key-chain interface commands. The key chain must also be configured to define the keys. Use show ip eigrp neighbors, show ip route, and debug eigrp packets to verify MD5 authentication.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

RO UTE v 1.0—2-19

Implementing an EIGRP-Based Solution

2-141

2-142

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 7

Lab 2-3 Debrief Overview In Lab 2-3, students configure and verify EIGRP authentication. They also implement EIGRP authentication over LAN and WAN interfaces.

Objectives Upon completing this lesson, you will be able to configure and verify EIGRP authentication. This ability includes being able to meet these objectives: Complete the lab overview and verification Describe a sample solution and alternatives

Lab Overview and Verification This topic describes the lab topology and key checkpoints used to create a solution and to start with the verification.

Lab Topology

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-2

The figure above presents the physical lab topology used for the Lab 2-3: Configure and Verify EIGRP Authentication. The topology uses four pod routers. All routers participate in the EIGRP routing protocol. Based on the topology, students will identify the required parameters for configuring EIGRP authentication on LAN and WAN interfaces.

2-144

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab Review: What Did You Accomplish? Task 1: Configure EIGRP authentication over LAN interfaces – What steps did you take to configure EIGRP authentication on a LAN segment? – How can you configure keys so they do not expire? – How can you define the key chain used for router authentication? Task 2: Configure EIGRP authentication over WAN interfaces – What steps did you take to configure EIGRP authentication on a WAN segment? – How can you configure keys so they do not expire? – How can you define the key chain used for router authentication?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-3

In the first task, you configured EIGRP authentication over LAN interfaces. You configured a key chain with a key that never expires. You enabled secure authentication and used the defined key chain to provide security when exchanging EIGRP packets. In the second task, you configured EIGRP authentication over WAN interfaces. You configured a second key chain with a key that never expires. And again, you enabled secure authentication using the defined key chain.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-145

Verification • Did you have enough information to create an implementation plan? • Did you enable EIGRP authentication on the LAN interfaces? • Did you use a secure authentication method for authentication over LAN interfaces? • Did you establish adjacencies between the routers over the LAN interface and enter EIGRP routes into the IP routing table? • Did you enable EIGRP authentication on the WAN interfaces? • Didi you use a secure authentication method for authentication over WAN interfaces? • Did you establish adjacencies between the routers over WAN interface and enter EIGRP routes into the IP routing table?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-4

A common approach to verifying the implementation process for a routing protocol is to answer the following questions: Did you have enough information to create an implementation plan? Did you enable EIGRP authentication on the LAN interfaces? Did you use a secure authentication method for authentication over LAN interfaces? Did you establish adjacencies between the routers over the LAN interface and enter EIGRP routes into the IP routing table? Did you enable EIGRP authentication on the WAN interfaces? Did you use a secure authentication method for authentication over WAN interfaces? Did you establish adjacencies between the routers over WAN interface and enter EIGRP routes into the IP routing table?

2-146

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Checkpoints • Configure the key chain to use for authentication on LAN interfaces. • Configure a key to use in the key chain for authentication over the LAN interfaces. • Enable secure authentication on LAN segments. • Use the defined key chain for router authentication. • Configure another key chain to use for authentication on WAN interfaces. • Configure a key to use in the key chain for authentication over the WAN interfaces. • Enable secure authentication on WAN segments. • Use the defined key chain for router authentication.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-5

During the configuration and verification phase, the network operator can deal with several checkpoints. After completing all configuration tasks, the network operator has either finished the lab successfully or must perform additional verification and troubleshooting. With different checkpoints, the network operator can verify for proper configuration. The following checkpoints are used for verification: Configure the key chain to use for authentication on LAN interfaces. Configure a key to use in the key chain for authentication over the LAN interfaces. Enable secure authentication on LAN segments. Use the defined key chain for router authentication. Configure another key chain to use for authentication on WAN interfaces. Configure a key to use in the key chain for authentication over the WAN interfaces. Enable secure authentication on WAN segments. Use the defined key chain for router authentication.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-147

Sample Solutions and Alternatives This topic describes a sample solution and other alternatives.

Sample Solution • Use static routes to establish reachability instead of a routing protocol, which is typically not recommended, as static routes do not scale. • Another routing protocol can be used to implement a similar solution and use the supported authentication type. Changing the routing protocol is not a realistic solution as changing the routing protocol is not the case during fine tuning of the existing protocol.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-6

The sample solution includes implementation details and details for each task of the implementation plan. Different solutions are possible and this slide shows a few details of a successful configuration. Proper implementation includes the following items: Configure a key chain with the key used for LAN authentication and use it for router authentication on LAN segments. Configure another key chain with the key used for WAN authentication and use it for router authentication on WAN segments.

2-148

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternative Solutions Use static routes to establish reachability instead of routing protocol, which is typically not possible, as static routes do not scale. Another routing protocol can be used to implement a similar solution. Changing the routing protocol is not a realistic solution.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-7

Use static routes to establish reachability instead of a routing protocol, which is typically not recommended, as static routes do not scale. Another routing protocol can be used to implement a similar solution and use the supported authentication type. Changing the routing protocol is not a realistic solution as changing the routing protocol is not the case during fine tuning of the existing protocol.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-149

Q and A Why should you use authentication with routing protocols? What kind of authentication does EIGRP support? When do the keys in a key chain expire? Can you change the key expiration time? What is the difference between authentication on LAN and WAN segments?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-8

Authentication provides additional security in networks by verifying the source and destination of each routing update. Only routers with the correct authentication configured can exchange routing protocol packets. EIGRP supports MD5 authentication. The expiration time can be configured for each key and the key can be configured not to expire. There is no difference between LAN and WAN authentication. In both cases, you must enable MD5 authentication, configure a key chain, and use the keys in the key chain properly.

2-150

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary Configure EIGRP authentication on LAN segments, where the key without expiration is used in the key chain. Configure EIGRP authentication on WAN segments, where the key without expiration is used in the key chain.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1. 0—2-9

Implementing an EIGRP-Based Solution

2-151

2-152

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 8

Advanced EIGRP Features in an Enterprise Network Overview Network administrators benefit from understanding how to configure Enhanced Interior Gateway Routing Protocol (EIGRP) to prevent common routing problems that hinder network scalability. For example, you can implement EIGRP stub routers to limit the EIGRP query range, making EIGRP more scalable with fewer complications. EIGRP is a scalable routing protocol, which ensures that as a network grows larger, it operates efficiently and adjusts rapidly to changes. This lesson describes advanced EIGRP features and practical EIGRP-specific design and configuration techniques to implement an effective, scalable network.

Objectives Upon completing this lesson, you will be able to implement advanced EIGRP features in an Enterprise Network by applying the planned implementation processes using correct Cisco IOS commands and applications. You will also be able to verify that the configuration was correctly implemented. This ability includes being able to meet these objectives: Define scalability in large networks. Understand EIGRP queries. Define SIA connections in EIGRP. Understand EIGRP stub routers.

Scalability in Large Networks This topic explains factors affecting scalability in large internetworks.

Scalability in Large Networks Operating one large, flat EIGRP network is not a scalable solution for to the following reasons: – Large routing tables – High memory requirements – Large amount of routing traffic

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-2

Large, flat EIGRP networks are normally not scalable for two main reasons: High memory demands can lead to problems. The problems result from having a large topology table, having a large number of routes in a routing table, and, in some environments (such as a concentration of routers at a central site), from having a large number of neighbors in an adjacency table. High bandwidth demands can also create problems, resulting from the exchange of routing updates. The sending of queries and replies in one large EIGRP domain (which may include links with low bandwidth and links with a significant number of transmission errors) often results in a large amount of routing traffic, which consequently results in even more traffic and congestion.

2-154

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Factors that Influence EIGRP Scalability Amount of routing information exchanged between peers Number of routers Depth of topology—the number of hops that information must travel to reach all routers Number of alternate paths through the network

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-3

The following are some of the factors that affect network scalability: Amount of information exchanged between neighbors: If more routing information than is necessary is exchanged between EIGRP neighbors, the routers have to work harder both at neighbor startup and when reacting to changes in the network. Route summarization is needed to improve the convergence time. Number of routers: When a topology change occurs in the network, EIGRP resource consumption is directly related to the number of routers that are involved in the change. Depth of the topology: The topology depth can affect the convergence time. Depth refers to the number of hops that information must travel to reach all routers. A multinational network without route summarization is an example of a network with large depth and, therefore, higher convergence times. A three-tiered network design (as described in Module 1) is highly recommended for all IP routing environments. There should never be more than seven hops between any two routing devices on an internetwork. The propagation delay and query process across multiple hops when changes occur may slow network convergence. Number of alternate paths through the network: A network should provide alternate paths to avoid single points of failure. However, too much complexity (too many alternate paths) can also lead to EIGRP convergence problems, because the EIGRP routing process needs to explore all possible paths for lost routes (using queries). This complexity creates the ideal condition for a router to become stuck-in-active (SIA) as it awaits a response to queries that are being propagated through many alternate paths.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-155

EIGRP Design Challenges The number of neighboring routers on the common subnet The number of changes in the network The amount of EIGRP load on the WAN Every time a route disappears from the EIGRP process, DUAL computation is needed—resulting in high link utilization and CPU load

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-4

When you implement EIGRP as the routing protocol, you need to address some design challenges. The three major factors are: The size of the topology and routing tables, including the number of neighboring routers on the common subnet The number of changes in the network The amount of EIGRP load on the WAN These three factors mainly dictate the EIGRP design and introduce the need for query boundaries (using summarization, redistribution, and so on). Without any boundaries, queries are propagated throughout the EIGRP domain and, often, all of the routers get involved in a Diffusing Update Algorithm (DUAL) computation. This EIGRP feature not only places additional bandwidth demands on links in the network, but also results in high CPU utilization. Frequent DUAL computations have an effect on all tables, which are maintained by the routers—from EIGRP structures to various caches built during the forwarding process.

2-156

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP Queries This topic explains how EIGRP uses queries to converge rapidly when a route is lost.

EIGRP Query Process Queries are sent when a route is lost and no feasible successor is available—route is in an active state Queries are sent to all neighboring routers on all interfaces except the interface of the successor If neighbors have the lost route information, they answer the query (and stop the query from spreading), otherwise queries are sent to their neighbors

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-5

As an advanced distance vector protocol, EIGRP relies on neighboring routers to provide routing information. Recall that when a router loses a route and does not have a feasible successor in its topology table, it looks for an alternative path to the destination. This is known as going active on a route; a route is considered passive when a router is not performing recompilation on that route. When the route is lost, the router sends query packets to all neighbors on interfaces other than the one used to reach the previous successor (split horizon behavior). These packets query if each of the neighbors has a route to the given destination. If a router has an alternate route, it answers the query and does not propagate it further. If a neighbor does not have an alternate route, it queries each of its own neighbors for an alternate path. The queries then propagate through the network, creating an expanding tree of queries. When a router answers a query, it stops the spread of the query through that branch of the network. The figure in the slide presents a network example for which a single lost route might result in an enormous number of queries sent throughout the EIGRP domain. When the route to network 10.1.1.0 on router R1 is lost, router R1 sends a query to all neighboring routers and to all interfaces except the interface of the successor (split horizon). The query is propagated to router R2. Since it has no information about the lost route, router R2 cascades the query to its neighbors, which cascade it to their neighbors, and so on. Each query requires a reply from the neighbor and the amount of traffic increases. The network topology, in the figure in the slide, shows that there is no redundant path to network 10.1.1.0 available. The EIGRP query propagation process is far from efficient. Many queries are sent and each query is followed by a reply. Several solutions exist to optimize the query propagation process and to limit the amount of unnecessary EIGRP load on the links. The solutions that can be used are summarization, redistribution, and the EIGRP stub routing feature. © 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-157

SIA Connections in EIGRP Stuck-in-active (SIA) routes can be some of the most challenging problems to resolve in an EIGRP network. This topic explains why SIA connections occur.

EIGRP Query Process Stuck-in-Active The router must get replies to all its queries for a lost route to start calculating successor information If any reply to the query is lost or missing within 3 minutes: – The route is SIA – The router resets the neighbor relationship with the neighbor that fails to reply

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-6

EIGRP uses a reliable multicast approach to search for an alternate to a lost route; therefore, it is imperative that EIGRP receive a reply for each query it generates in the network. Once a route goes active and the query sequence is initiated, it can only come out of the active state and transition to the passive state when it receives a reply for every generated query. If the router does not receive a reply to all the outstanding queries within three minutes (the default time), the route goes into the SIA state. When the route goes into the SIA state, the querying router resets the neighbor relationship to the neighbor that failed to reply. This setting causes the router to go active on all routes known through the lost neighbor, and to re-advertise all the routes that it knows about to the lost neighbor. The most common reasons for SIA routes are as follows: The router being queried is too busy to answer the query because of high CPU usage or memory problems and cannot allocate the memory to process the query or build the reply packet. The link between the two routers is not good; therefore, some packets are lost between the routers. While the receiving router receives enough packets to maintain the neighbor relationship, the router does not receive all of the queries or replies. A failure causes traffic on a link to flow in one direction only—this is called a unidirectional link.

2-158

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Active Process Enhancement Before: Router R1 resets the neighbor relationship to router R2 when the normal active timer expires.

After: An SIA query is used from router R1. Router R3’s neighbor relationship is reset—problem on the link.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-7

A route becomes active when it goes down or its metric become worse and there are no feasible successors. It sends a query to all its neighbors asking for a new path to the lost route. The process requires replies from all of the neighbors. If replies are lost, then two new messages are required. SIA query and SIA reply are two new additions to the type, length, value (TLV) triplets in the EIGRP packet header. These packets are generated automatically since Cisco IOS Release 12.1(5) with the Active Process Enhancement feature. This feature enables an EIGRP router to monitor the search progression for a successor route and ensures that the neighbor is still reachable. The result is improved network reliability by reducing the unintended termination of neighbor adjacency. Before a SIA query and SIA reply were available, the following would occur: 1. Router R1 sends a query for network 10.1.1.0/24 to router R2. 2. Router R2 has no entry for this network, so it queries router R3. If problems exist between router R2 and router R3, the reply packet from router R3 to router R2 may be delayed or lost. 3. Router R1 has no visibility of the downstream progress and assumes that no response indicates problems with router R2. After router R1’s three-minute active timer expires, the neighbor relationship with router R2 is reset, along with all known routes from router R2. With the Active Process Enhancement feature, the events take a different course. 1. Router R1 queries downstream router R2 (with an SIA query) at the midway point of the active timer (one and a half minutes by default) about the status of the route. 2. Router R2 responds (with an SIA reply) that it is searching for a replacement route. 3. Upon receiving this SIA reply response packet, router R1 validates the status of router R2 and does not terminate the neighbor relationship. © 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-159

4. Meanwhile, router R2 will send up to three SIA queries to router R3. If they go unanswered, router R2 will terminate the neighbor relationship with router R3. Router R2 will then update router R1 with an SIA reply indicating that the network 10.1.1.0/24 is unreachable. 5. Routers R1 and R2 will remove the active route from their topology tables. The neighbor relationship between routers R1 and R2 remains intact.

2-160

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP Stub Routers The stability of large-scale EIGRP networks is often dependent on the range of queries through the network. This topic explains how to mark the spokes of a large network as stubs to reduce the number of EIGRP queries and thus improve network scaling.

Updates and Queries Without an EIGRP Stub

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-8

When a router running EIGRP loses its connection to a network, it first searches for alternate loop-free paths. If it finds none, it then sends queries to each of its neighbors, looking for an alternate path. If the neighbor does not have another path to this destination, it replies with infinity. After receiving all replies, router R1 then removes all references to this route from its local tables. In large hub-and-spoke networks, the hub routers have to build queries and process replies from each of the spokes; this limits scaling. Without the stub feature, a hub router will send a query to the spoke routers if a route is lost somewhere in the network. If there is a communication problem over the WAN link between the hub router and the spoke router, replies may not be received for all queries (this is known as SIA), and the network may become unstable. By default (when a router is not stub-enabled), queries for network 10.1.1.0/24 are sent to the remote routers, thus unnecessarily utilizing the bandwidth and possibly invoking routes that are stuck-in-active. Each of the remote sites also sends a query towards router R2, with router R2 receiving five queries that it must process and answer. If these spokes are remote sites, they typically have two connections for redundancy. Router R1 should never use the spokes as a path to anything reachable through router R2, so there is no reason to learn about, or query for, routes through these spokes. Hub-and-spoke network topologies commonly use stub routing. If a true stub network is required, the hub router can be configured to send a default route to the spoke routers. This approach is the simplest and conserves the most bandwidth and memory on the spoke routers.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-161

Updates and Queries Using EIGRP Stub Router R1 should never use spoke routers to reach any network available through router R2. There is no reason to learn about or query for routes through spoke routers. Spoke routers should not be used for transit traffic—they can be configured as stubs.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-9

The EIGRP stub routing feature allows a network administrator to prevent the sending of queries to the spoke router under any condition. Remote sites allow the hub (regional office) sites to immediately answer queries without propagating the queries to the remote sites. This saves CPU cycles and bandwidth. It also lessens the convergence time, even when the remote sites are dual-homed to two or more hub (regional) sites. The figure in the slide shows that spoke routers are configured as stubs to signal to routers R1 and R2 that the paths through the spoke routers should not be used for transit traffic. Router R1 is not sending queries for network 10.1.1.0/24 to stubs, reducing the total number of queries and total bandwidth used. Marking the remote routers as stubs also reduces the complexity of the topology. It is highly recommended that you use both EIGRP route summarization and EIGRP stub features to provide the best scalability.

2-162

Note

The EIGRP stub routing feature does not automatically enable route summarization on the hub router. In most cases, the network administrator should configure route summarization on the hub routers.

Note

Although EIGRP is a classless routing protocol, it behaves in a classful way by default. For example, one default behavior of EIGRP is to have automatic summarization turned on. When you configure the hub router to send a default route to the remote router, ensure that the ip classless command is on the remote router. By default, the ip classless command is enabled in all Cisco IOS images that support the EIGRP stub routing feature.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP Stub The EIGRP stub routing feature does the following: – Improves network stability – Reduces resource utilization – Simplifies remote router (spoke) configuration The feature is commonly used in hub-and-spoke topologies – Each stub router reports its status to neighbors. – Queries are not sent to the stub routers.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-10

The EIGRP stub feature was first introduced in Cisco IOS Release 12.0(7)T. Only the remote routers are configured as stubs. A stub router sends a special peer information packet to all neighboring routers to report its status as a stub router. Any neighbor that receives a packet informing it of the stub status does not query the stub router for any routes. Therefore, a router that has a stub peer does not query that peer; instead, hub routers connected to the stub router answer the query on behalf of the stub router. The stub routing feature does not prevent routes from being advertised to the remote router. The EIGRP stub routing feature also simplifies the configuration and maintenance of hub-andspoke networks, improves network stability, and reduces resource utilization. When stub routing is enabled in dual-homed remote configurations, you do not have to configure filtering on remote routers to prevent them from appearing as transit paths to the hub routers. Caution

© 2009 Cisco Systems, Inc.

EIGRP stub routing should be used on stub routers only. A stub router is defined as a router that is connected to the network core or hub layer and through which core transit traffic should not flow. A stub router should only have hub routers for EIGRP neighbors; ignoring this restriction may cause undesirable behavior.

Implementing an EIGRP-Based Solution

2-163

EIGRP Stub Configuration Planning Examine the topology and existing EIGRP configuration Define requirements – Stub routers – Redistribution – Summarization Create an implementation plan Configure and verify the configuration

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-11

When you configure EIGRP stub behavior on stub routers, you should examine the existing topology and configuration and follow the design. The design is based on the topology and requirements. Stub routers, together with the redistribution and summarization, limit the query range in the topology. The next step is to create the implementation plan, then configure the EIGRP stub functionality on all required routers in the EIGRP domain. When you configure EIGRP stub routers, you optimize query and reply processing and you can verify that the configuration and design are both correct.

2-164

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

EIGRP Stub Options Stub options (default is with connected and summary) – receive-only: prevents the stub from sending any type of route – connected: permits the stub to send connected routes (may still need to redistribute) – static: permits the stub to send static routes (must still redistribute) – summary: permits the stub to send summary routes – redistribute: permits the stub to send redistributed routes

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-12

A router configured as a stub shares information about connected and summary routes with all neighboring routers by default. The receive-only option restricts the router from sharing any of its routes with any other router within an EIGRP autonomous system (AS). This option does not permit any other option to be specified, because it prevents any type of route from being sent. The other options (connected, static, and summary) cannot be used with the receive-only option. Use this option if there is a single interface on the router. The connected option permits the EIGRP stub routing feature to send connected routes. If a network command does not include the connected routes, it might be necessary to redistribute the connected routes with the redistribute connected command under the EIGRP process. This option is enabled by default and is the most widely practical stub option. The static option permits the EIGRP stub routing feature to send static routes. You still need to redistribute static routes with the redistribute static command. The summary option permits the EIGRP stub routing feature to send summary routes. You can either create summary routes manually, or create them automatically by enabling autosummary at a major network border router. The summary option is enabled by default. The redistribute option permits the EIGRP stub routing feature to send redistributed routes. You still need to redistribute routes with the redistribute command.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-165

Configuring eigrp stub connected Îîř˝±˛ş·ąó®±«¬»®÷ý

»·ą®° ­¬«ľ ˝±˛˛»˝¬»Ľ

Router R2 will advertise to router R1 – 10.1.2.0/24 Router R2 will not advertise to router R1 – 10.1.2.0/23 – 10.1.3.0/24 – 10.1.4.0/24

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

Îîý 䱫¬°«¬ ±ł·¬¬»Ľâ ·˛¬»®şż˝» ­»®·ż´đ ·° ­«łłż®§óżĽĽ®»­­ »·ą®° ďđňďňîňđ îëëňîëëňîëěňđ ˙ ·° ®±«¬» ďđňďňěňđ îëëňîëëňîëëňđ ďđňďňďňďđ ˙ ®±«¬»® »·ą®° ďďđ ®»Ľ·­¬®·ľ«¬» ­¬ż¬·˝ ł»¬®·˝ ďđđđ ď îëë ď ďëđ𠲻¬©±®µ ďđňîňîňî đňđňđňí ˛»¬©±®µ ďđňďňîňđ đňđňđňîëë »·ą®° ­¬«ľ ˝±˛˛»˝¬»Ľ RO UTE v 1.0—2-13

You can use the eigrp stub router configuration mode command to configure EIGRP stub functionality on the routers. You can modify the eigrp stub command with several options to optimize the exchange of routes based on the topology and requirements. Note

The eigrp stub command options can be used in any combination except for the receiveonly keyword, which prevents that router in advertising networks.

The figure in the slide shows the eigrp stub connected command on Router R2. Because the connected keyword is used, router R2 advertises the connected networks to its neighbors. Router R2, in the example in the slide, advertises the 10.1.2.0/24 route only. Network 10.1.2.0/24 is connected and, at the same time, is covered by the network statement under EIGRP AS 110 routing process. Although 10.1.3.0/24 is also a connected network, it is not advertised to router R1 because it is not advertised in a network command, and connected routes are not redistributed. The same applies to the static route for network 10.1.4.0/24. This route is not included in the EIGRP routing updates, because the EIGRP stub functionality for static routes is not specified under the EIGRP routing process. The eigrp stub connected command is only used as an example. For more details about eigrp stub command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

2-166

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Configuring eigrp stub summary Îîř˝±˛ş·ąó®±«¬»®÷ý

»·ą®° ­¬«ľ ­«łłż®§

Router R2 will advertise to router R1 – 10.1.2.0/23 Router R2 will not advertise to router R1 – 10.1.2.0/24 – 10.1.3.0/24 – 10.1.4.0/24

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

Îîý 䱫¬°«¬ ±ł·¬¬»Ľâ ·˛¬»®şż˝» ­»®·ż´đ ·° ­«łłż®§óżĽĽ®»­­ »·ą®° ďđňďňîňđ îëëňîëëňîëěňđ ˙ ·° ®±«¬» ďđňďňěňđ îëëňîëëňîëëňđ ďđňďňďňďđ ˙ ®±«¬»® »·ą®° ďďđ ®»Ľ·­¬®·ľ«¬» ­¬ż¬·˝ ł»¬®·˝ ďđđđ ď îëë ď ďëđ𠲻¬©±®µ ďđňîňîňî đňđňđňí ˛»¬©±®µ ďđňďňîňđ đňđňđňîëë »·ą®° ­¬«ľ ­«łłż®§ RO UTE v 1.0—2-14

The figure in the slide shows that the eigrp stub summary command is used on router R2. Because the summary keyword is used, router R2 will advertise summary routes only to its neighbors. Router R2 will only advertise 10.1.2.0/23, the summary route that is configured on the router R2. No other routes are advertised, because the eigrp stub summary command is the only eigrp stub command used under the EIGRP AS 110 routing process in the example in the slide. Note

© 2009 Cisco Systems, Inc.

Summary routes can be created manually with the summary-address command or automatically at a major network border router with the auto-summary command enabled, which is enabled by default.

Implementing an EIGRP-Based Solution

2-167

Configuring eigrp stub static Îîř˝±˛ş·ąó®±«¬»®÷ý

»·ą®° ­¬«ľ ­¬ż¬·˝

Router R2 will advertise to router R1 – 10.1.4.0/24 Router R2 will not advertise to router R1 – 10.1.2.0/24 – 10.1.2.0/23 – 10.1.3.0/24

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

Îîý 䱫¬°«¬ ±ł·¬¬»Ľâ ·˛¬»®şż˝» ­»®·ż´đ ·° ­«łłż®§óżĽĽ®»­­ »·ą®° ďđňďňîňđ îëëňîëëňîëěňđ ˙ ·° ®±«¬» ďđňďňěňđ îëëňîëëňîëëňđ ďđňďňďňďđ ˙ ®±«¬»® »·ą®° ďďđ ®»Ľ·­¬®·ľ«¬» ­¬ż¬·˝ ł»¬®·˝ ďđđđ ď îëë ď ďëđ𠲻¬©±®µ ďđňîňîňî đňđňđňí ˛»¬©±®µ ďđňďňîňđ đňđňđňîëë »·ą®° ­¬«ľ ­¬ż¬·˝ RO UTE v 1.0—2-15

The figure in the slide shows that the eigrp stub static command is used on router R2. Because of the static keyword, router R2 will advertise static routes only to its neighbors. Router R2 will only advertise 10.1.4.0/24, the static route that is configured on the router R2. It will not advertise any other routes, because the eigrp stub static command is the only eigrp stub command used under the EIGRP AS 110 routing process in the example in the slide. Note

2-168

Without the configuration of the eigrp stub static option, EIGRP will not send any static routes. This includes internal static routes that normally would be automatically redistributed. It will still be necessary to redistribute static routes with the redistribute static command.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Configuring eigrp stub receive-only Îîř˝±˛ş·ąó®±«¬»®÷ý

»·ą®° ­¬«ľ ®»˝»·Ş»ó±˛´§

Router R2 will not advertise anything to router R1 Router R1 needs to have a static route to the networks behind router R2 to reach them Îîý 䱫¬°«¬ ±ł·¬¬»Ľâ ·˛¬»®şż˝» ­»®·ż´đ ·° ­«łłż®§óżĽĽ®»­­ »·ą®° ďđňďňîňđ îëëňîëëňîëěňđ ˙ ·° ®±«¬» ďđňďňěňđ îëëňîëëňîëëňđ ďđňďňďňďđ ˙ ®±«¬»® »·ą®° ďďđ ®»Ľ·­¬®·ľ«¬» ­¬ż¬·˝ ł»¬®·˝ ďđđđ ď îëë ď ďëđ𠲻¬©±®µ ďđňîňîňî đňđňđňí ˛»¬©±®µ ďđňďňîňđ đňđňđňîëë »·ą®° ­¬«ľ ®»˝»·Ş»ó±˛´§ © 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-16

The figure in the slide shows that the eigrp stub receive-only command is used on router R2. Because the receive-only keyword is used, router R2 will not advertise anything to its neighbors. Router R2, in the example in the slide, requires that static routes be configured in order to reach the networks behind router R2. Note

© 2009 Cisco Systems, Inc.

The receive-only keyword restricts the router from sharing any of its routes with any other router in the same EIGRP autonomous system and cannot be combined with any other option within the eigrp stub command.

Implementing an EIGRP-Based Solution

2-169

Configuring eigrp stub redistributed Îîř˝±˛ş·ąó®±«¬»®÷ý

»·ą®° ­¬«ľ ®»Ľ·­¬®·ľ«¬»Ľ

Router R2 will advertise routes from RIP to router R1

Îîý 䱫¬°«¬ ±ł·¬¬»Ľâ ®±«¬»® ®·° ˛»¬©±®µ ďđňđňđňđ ˙ ®±«¬»® »·ą®° ďďđ ®»Ľ·­¬®·ľ«¬» ®·° ł»¬®·˝ ­¬ż¬·˝ ďđđđ ď îëë ď ďëđ𠲻¬©±®µ îđňđňđňđ »·ą®° ­¬«ľ ®»Ľ·­¬®·ľ«¬»Ľ

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—2-17

From the figure in the slide, it is apparent that router R2 is running the EIGRP AS 110 and RIP routing processes. At the same time, it is configured with the eigrp stub redistributed command within the EIGRP AS 110 routing process. Because the redistributed keyword is used, router R2 will advertise all RIP routes that are redistributed from the RIP routing protocol into the EIGRP AS 110 process. The sample configuration shows that the redistribute command is used under the EIGRP AS 110 process. This is required in order to include redistributed networks within the EIGRP advertisements.

2-170

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary Factors that affect network scalability include the amount of information exchanged between peers, the number of routers, the depth of the topology, and the number of alternate paths through the network. When a route is lost and no feasible successor is available, queries are sent to all neighboring routers on all interfaces. Once a route goes active and the query sequence is initiated, it can only come out of the active state and transition to the passive state when it receives a reply for every generated query. If the router does not receive a reply to all of the outstanding queries within 3 minutes (the default time), the route goes into the SIA state. The stub routing feature improves network stability, reduces resource utilization, and simplifies stub router configuration.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

RO UTE v 1.0—2-18

Implementing an EIGRP-Based Solution

2-171

2-172

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 9

Lab 2-4 Debrief Overview In Lab 2-4, students implement and troubleshoot EIGRP operations. They also solve EIGRP adjacency and limited connectivity issues.

Objectives Upon completing this lesson, you will be able to implement and troubleshoot EIGRP operations to solve EIGRP adjacency and limited connectivity issues. This ability includes being able to meet these objectives: Complete the lab overview and verification Presents instructions to troubleshoot EIGRP implementation

Lab Overview and Verification This topic describes the lab topology and key checkpoints used to create a solution and start with the verification.

Lab Topology

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-2

The figure in the slide presents the physical lab topology used for the Lab 2-4: Implement and Troubleshoot EIGRP Operations. The topology uses four pod routers and two backbone routers. All routers are participating in the EIGRP routing protocol. The configuration is broken in order to prepare the lab for students, who will go through troubleshooting steps. Based on the topology, students will identify required parameters to implement and troubleshoot EIGRP operations.

2-174

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab Overview Trouble Ticket A—EIGRP Adjacency Issues – There is no connectivity to the additional IP subnet being deployed on a LAN segment between routers R2 and R4. – There are issue with the EIGRP adjacency to router BBR1. – A configuration was applied that should have improved the metric calculation on R4, but instead resulted in no connectivity from that router. – Summarization was configured, but is not working as expected. Trouble Ticket B—Limited Connectivity – A new spoke location, router R3, was deployed with no connectivity to the LAN subnets attached to routers R2 and R4.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-3

The lab consists of two trouble tickets: Trouble Ticket A—EIGRP Adjacency Issues: There is no connectivity to an additional IP subnet being deployed on a LAN segment between routers R2 and R4. The next problem is an issue with EIGRP adjacency to router BBR1. A configuration that should have improved the metric calculation on router R4 instead caused there to be no connectivity from that router. Finally, summarization is configured, but is not working as expected. Trouble Ticket B—Limited Connectivity: A newly deployed spoke location, router R3, has no connectivity to the LAN subnets attached to routers R2 and R4.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-175

Instructions This subtopic presents instructions to troubleshoot EIGRP implementation.

Instructions Create the troubleshooting plan. Verify that you can see no more errors for the entries generated on routers R2 and R4. Verify that EIGRP adjacency on the LAN segment between routers R2 and R4 has been formed. Verify that the secondary IP address from the LAN segment is also present on router R1, and that you can ping the IP addresses from that subnet Verify that EIGRP adjacency has been formed between routers R1 and BBR1. Verify that routers in your pod have received subnets 192.168.x.0/24, announced by router BBR1.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-4

Instructions (Cont.) Verify that routers have specific information about every subnet in your network and that you have connectivity to those subnets. Verify that router R3 receives IP routing information for the IP subnets located on the LAN segment between routers R2 and R4. Verify that you can ping the IP addresses from the IP subnets located on the LAN segment between routers R2 and R4.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

2-176

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v1. 0—2-5

© 2009 Cisco Systems, Inc.

A common approach to verifying the implementation process for a routing protocol is to follow these instructions: Create the troubleshooting plan. Verify that you can see no more errors for the entries generated on routers R2 and R4. Verify that EIGRP adjacency on the LAN segment between routers R2 and R4 has been formed. Verify that the secondary IP address from the LAN segment is present on router R1 and that you can ping the IP addresses from that subnet. Verify that EIGRP adjacency has been formed between routers R1 and BBR1. Verify that the routers in your pod have received the subnets 192.168.x.0/24 announced by router BBR1. Verify that routers have specific information about every subnet in your network and that you have connectivity to those networks. Verify that router R3 receives IP routing information for the IP subnets located on the LAN segment between routers R2 and R4. Verify that you can ping the IP addresses from the IP subnets located on the LAN segment between routers R2 and R4.

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-177

Summary This topic summarizes the key points that were discussed in this lesson.

Summary Connectivity issues, wrong authentication, and metric configuration result in EIGRP adjacency issues. Incorrectly configuring a newly deployed site can lead to limited connectivity.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

2-178

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v1. 0—2-6

© 2009 Cisco Systems, Inc.

Module Summary This topic summarizes the key points that were discussed in this module.

Module Summary EIGRP starts by building a table of adjacent neighbors. Route exchanges with these neighbors result in an EIGRP topology table. The DUAL process calculates the best EIGRP routes, which are moved into the IP routing table. Steps to configure basic EIGRP are: define EIGRP as a routing protocol, define attached networks participating in EIGRP, and, if desired, define interface bandwidth. The configuration of a passive interface, IP default-network, and summarization are all advanced steps to improve network scalability and decrease the number of EIGRP updates exchanged between EIGRP neighbors.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-1

Module Summary (Cont.) Any Transport over MPLS (AToM) supports EIGRP, allowing service provider PE-routers to be aware of EIGRP and P-routers to be hidden from the customer network. EIGRP supports MD5 authentication, which checks and authenticates the source of each routing update packet received. Features such as stub routing and active process enhancement help improve network stability and performance.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—2-2

Configuring Enhanced Interior Gateway Routing Protocol (EIGRP) for your routing environment enables you to achieve benefits such as rapid convergence, lower bandwidth utilization, and multiple routed protocol support. Using EIGRP ensures that as a network grows larger, it will still operate efficiently and adjust to changes rapidly. © 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-179

2-180

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Module Self-Check Use the questions here to review what you learned in this module. The correct answers and solutions are found in the Module Self-Check Answer Key. Q1)

Which three features are benefits of EIGRP? (Choose three.) (Source: Planning Routing Implementations with EIGRP) A) B) C) D)

Q2)

What is listed in the EIGRP topology table? (Source: Planning Routing Implementations with EIGRP) A) B) C) D)

Q3)

directly connected routers that have formed EIGRP adjacencies best routes to a destination network all routes learned from each EIGRP neighbor all EIGRP neighbors in the EIGRP domain

Which two statements are true of the EIGRP metric calculation? (Choose two.) (Source: Planning Routing Implementations with EIGRP) A) B) C) D)

Q6)

directly connected routers that have formed EIGRP adjacencies best routes to a destination network all routes learned from each EIGRP neighbor all EIGRP neighbors in the EIGRP domain

What is listed in the IP routing table? (Source: Planning Routing Implementations with EIGRP) A) B) C) D)

Q5)

directly connected routers that have formed an EIGRP adjacency best routes to a destination network all routes learned from each EIGRP neighbor all EIGRP neighbors in the EIGRP domain

What is listed in the EIGRP neighbor table? (Source: Planning Routing Implementations with EIGRP) A) B) C) D)

Q4)

fast convergence support for VLSM and discontiguous subnets same metric algorithm as OSPF manual route summarization at any point in the network

The following are the default K values: K1 = 1, K2 = 1, K3 = 0, K4=0, K5 = 0. To convert an IGRP metric to an EIGRP metric, multiply the IGRP metric by 256. To convert an EIGRP metric to an IGRP metric, multiply the EIGRP metric by 256. The following are the default K values: K1 = 1, K2 = 0, K3 = 1, K4 = 0, K5=0.

Which three characteristics are key features of EIGRP? (Choose three.) (Source: Planning Routing Implementations with EIGRP) A) B) C) D)

© 2009 Cisco Systems, Inc.

fast convergence partial updates support for multiple Layer 3 protocols backward compatibility with RIP

Implementing an EIGRP-Based Solution

2-181

Q7)

Which of these are key EIGRP technologies? (Choose three.) (Source: Planning Routing Implementations with EIGRP) A) B) C) D) E)

Q8)

Which two characteristics are features of EIGRP? (Choose two.) (Source: Planning Routing Implementations with EIGRP) A) B) C) D)

Q9)

EIGRP topology table EIGRP neighbor table IP routing table IP EIGRP adjacency table

Which five criteria may be considered by EIGRP when calculating the metric? (Choose five.) (Source: Planning Routing Implementations with EIGRP) A) B) C) D) E) F) G)

2-182

EIGRP topology table EIGRP neighbor table IP routing table IP EIGRP adjacency table

Which type of database contains a list of all possible EIGRP routes to reach a destination? (Source: Planning Routing Implementations with EIGRP) A) B) C) D)

Q12)

EIGRP topology table EIGRP neighbor table IP routing table IP EIGRP adjacency table

Which type of database contains a list of the best EIGRP routes to reach a destination? (Source: Planning Routing Implementations with EIGRP) A) B) C) D)

Q11)

support for load balancing across unequal-cost paths manual summarization at any point on the internetwork provisioning of highly structured area design requirements automatic redistribution of static routes

Which type of database is a list of all EIGRP adjacencies? (Source: Planning Routing Implementations with EIGRP) A) B) C) D)

Q10)

RTP protocol-dependent modules protocol-independent modules DUAL RMTP

MTU bandwidth cost delay load hop count reliability

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q13)

Which packet type establishes neighbor relationships? (Source: Planning Routing Implementations with EIGRP) A) B) C) D) E)

Q14)

Which packet type is responsible for sending routing advertisements? (Source: Planning Routing Implementations with EIGRP) A) B) C) D) E)

Q15)

IP addressing EIGRP AS number the difference in the metric between EIGRP and IGRP feasible distance of feasible successor feasible distance of successor

Which packet type is used to ask neighbors about routing information? (Source: Planning Routing Implementations with EIGRP) A) B) C) D) E)

Q18)

assess the requirements assess the existing configuration and topology create the documentation verify the EIGRP neighbors create an implementation plan

Which parameters are included in an EIGRP implementation plan? (Choose two.) (Source: Planning Routing Implementations with EIGRP) A) B) C) D) E)

Q17)

ACK hello query reply update

What should a network engineer do before configuring EIGRP in the network? (Choose three.) (Source: Planning Routing Implementations with EIGRP) A) B) C) D) E)

Q16)

ACK hello query reply update

ACK hello query reply update

DUAL selects as the successor for a specific destination network the next-hop router with which of these? (Source: Planning Routing Implementations with EIGRP) A) B) C) D)

© 2009 Cisco Systems, Inc.

highest FD lowest FD highest AD lowest AD

Implementing an EIGRP-Based Solution

2-183

Q19)

What is the formula for selecting a feasible successor? (Source: Planning Routing Implementations with EIGRP) A) B) C) D)

Q20)

What does EIGRP do when a successor fails and there are no feasible successors, but there are alternate paths available? (Source: Planning Routing Implementations with EIGRP) A) B) C) D)

Q21)

It immediately uses the alternate pathway with the lowest FD and sends queries and updates to ensure that this pathway is loop-free. It automatically uses the alternate pathway with the lowest FD. It sends queries to see if the alternate paths are still viable. When a loop-free path is found, the path is installed in the routing table. It removes the network from the routing table and waits for the periodic update from EIGRP neighbors to see if an alternate route exists.

Which two conditions signify the active state for EIGRP? (Choose two.) (Source: Planning Routing Implementations with EIGRP) A) B) C) D)

2-184

The AD of the current successor route is less than the FD of the feasible successor route. The FD of the current successor route is less than the AD of the feasible successor route. The FD of the feasible successor route is less than the AD of the current successor route. The AD of the feasible successor route is less than the FD of the current successor route.

The route can be used and is stable. The route cannot be used. EIGRP queries are outstanding and the router is waiting for EIGRP replies. This is the best route with the lowest FD.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q22)

Test your understanding of EIGRP by matching terms with statements. Write the number of the statement in front of the term that the statement describes. (Source: Planning Routing Implementations with EIGRP) Term _____ 1.

successor

_____ 2.

feasible successor

_____ 3.

hello

_____ 4.

topology table

_____ 5.

IP

_____ 6.

update

_____ 7.

routing table

_____ 8.

DUAL

Statement 1. 2. 3. 4. 5. 6. 7. 8. Q23)

What is the purpose of the network command for EIGRP? (Source: Planning Routing Implementations with EIGRP) A) B) C) D)

Q24)

to determine which router interfaces participate in EIGRP and which networks the router advertises to specify the AS number to which the router belongs to define the EIGRP neighbors to tell EIGRP which networks to advertise, those directly connected and those learned through EIGRP

Which command creates a default route for EIGRP? (Source: Implementing and Verifying Basic EIGRP for the Enterprise LAN Architecture) A) B) C) D)

Q25)

a network protocol that EIGRP supports a database that contains successor and feasible successor information a database that includes administrative distance a neighbor router that has the best path to a destination a neighbor router that has the best alternate loop-free path to a destination an algorithm used by EIGRP to ensure fast convergence a multicast packet used to discover neighbors a packet sent by EIGRP routers when a new neighbor is discovered or a change occurs

ip default-network network-number ip route 0.0.0.0 0.0.0.0 outbound-interface ip route 0.0.0.0 255.0.0.0 outbound-interface ip route 0.0.0.0 255.255.255.255 outbound-interface

Which command displays an indication if a network is SIA? (Source: Implementing and Verifying Basic EIGRP for the Enterprise LAN Architecture) A) B) C)

© 2009 Cisco Systems, Inc.

show ip route show ip protocol show ip eigrp topology

Implementing an EIGRP-Based Solution

2-185

Q26)

What is the correct network command to allow updates to propagate only out of interfaces that are part of subnet 10.1.0.0/16? (Source: Implementing and Verifying Basic EIGRP for the Enterprise LAN Architecture) A) B) C) D)

Q27)

Which three of these are true of configuring the ip default-network command for EIGRP? (Choose three.) (Source: Implementing and Verifying Basic EIGRP for the Enterprise LAN Architecture) A) B) C) D)

Q28)

no boundary-summarization at the interface level no auto-summary under the routing process no auto-summary at the interface level no boundary-summarization under the routing process

Which command is used to configure manual summarization of all the subnets in network 10.1.32.0/21 for EIGRP in AS 101? (Source: Implementing and Verifying Basic EIGRP for the Enterprise LAN Architecture) A) B) C) D)

2-186

show ip eigrp interfaces show ip eigrp neighbors show ip route show ip eigrp topology

Which command is used to disable automatic EIGRP network-boundary summarization, and where is it applied? (Source: Implementing and Verifying Basic EIGRP for the Enterprise LAN Architecture) A) B) C) D)

Q31)

There are outstanding queries for this network. The network is unreachable. The network is up and operational, and this state signifies normal conditions. A feasible successor has been selected.

Which command indicates the number of EIGRP peer routers on an interface? (Source: Implementing and Verifying Basic EIGRP for the Enterprise LAN Architecture) A) B) C) D)

Q30)

The network must be reachable by the router using this command. The command will set the gateway of last resort to 0.0.0.0 on the router issuing this command. The network must be advertised to other neighbors as an EIGRP route. The network will be flagged by other EIGRP routers as a candidate default route.

What does the passive state in the EIGRP topology table signify? (Source: Implementing and Verifying Basic EIGRP for the Enterprise LAN Architecture) A) B) C) D)

Q29)

network 10.1.0.0 mask 255.255.0.0 network 10.1.0.0 mask 0.0.255.255 network 10.1.0.0 255.255.0.0 network 10.1.0.0 0.0.255.255

ip summary-address eigrp 101 10.1.32.0 255.255.248.0 ip eigrp 101 summary-address 10.1.32.0 255.255.240.0 ip summary-address eigrp 101 10.1.32.0 255.255.240.0 ip eigrp 101 summary-address 10.1.32.0 255.255.248.0

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q32)

By default, how many equal-cost paths to the same destination network can EIGRP place in the routing table? (Source: Configuring and Verifying EIGRP for the Enterprise WAN Architecture) A) B) C) D)

Q33)

Between headquarters and remote site A, there are two dedicated serial PPP connections, one at 64 kb/s, and the other at 128 kb/s. What is the appropriate variance to allow for unequal-cost load balancing across these links? (Source: Configuring and Verifying EIGRP for the Enterprise WAN Architecture) A) B) C) D)

Q34)

C router CE router PE router P router

What are three requirements for MPLS VPN technology? (Choose three.) (Source: Configuring and Verifying EIGRP for the Enterprise WAN Architecture) A) B) C) D)

Q38)

AToM stands for Any Transport over MPLS AToM unifies Layer 2 and Layer 3 over a common MPLS infrastructure. AToM must be enabled for EIGRP in an MPLS environment. Authentication is required in an AToM design.

Which router does not participate in customer routing? (Source: Configuring and Verifying EIGRP for the Enterprise WAN Architecture) A) B) C) D)

Q37)

25 percent 50 percent 75 percent 100 percent

Which two statements best describes AToM? (Choose two.) (Source: Configuring and Verifying EIGRP for the Enterprise WAN Architecture) A) B) C) D)

Q36)

1 2 3 4

What is the default bandwidth percentage that EIGRP uses on WAN links? (Source: Configuring and Verifying EIGRP for the Enterprise WAN Architecture) A) B) C) D)

Q35)

one two four six

CE routers should not be aware of MPLS VPN. The service provider’s P routers must be hidden from the customer. C routers must be directly connected to PE routers. Each PE router must appear as another router in the customer’s network.

You do not need to change the basic configuration when you deploy EIGRP over a physical interface using dynamic mapping, thus relying on Inverse ARP. ((Source: Configuring and Verifying EIGRP for the Enterprise WAN Architecture) A) B)

© 2009 Cisco Systems, Inc.

true false

Implementing an EIGRP-Based Solution

2-187

Q39)

Which two topologies use EIGRP over Frame Relay multipoint subinterfaces? (Choose two.) (Source: Configuring and Verifying EIGRP for the Enterprise WAN Architecture) A) B) C) D)

Q40)

What are two main reasons for the relatively fast EIGRP neighbor loss detection on point-to-point subinterfaces? (Choose two.) (Source: Configuring and Verifying EIGRP for the Enterprise WAN Architecture) A) B) C) D)

Q41)

true false

Which three of these are used to generate the message digest when EIGRP MD5 authentication is configured? (Choose three.) (Source: Implementing and Verifying EIGRP Authentication) A) B) C) D) E)

2-188

MD5 MD5 and simple password simple password none

When EIGRP authentication is configured between two routers, each router has its own unique password. (Source: Implementing and Verifying EIGRP Authentication) A) B)

Q44)

point-to-point partial-mesh full-mesh hub-and-spoke

Which authentication does EIGRP support? (Source: Implementing and Verifying EIGRP Authentication) A) B) C) D)

Q43)

There is a small default EIGRP hello and hold timer, which is identical to the value used on point-to-point links. On Frame Relay networks, the subinterface is declared down if the DLCI attached to the interface is lost. Neighbors send immediate EIGRP update packets to inform each other of neighbor loss. The EIGRP process is checking for neighbors every 5 seconds

Which topologies use EIGRP over Frame Relay multipoint subinterfaces? (Choose two.) (Source: Configuring and Verifying EIGRP for the Enterprise WAN Architecture) A) B) C) D)

Q42)

point-to-point partial-mesh full-mesh hub-and-spoke

packet sequence number key ID key router ID

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q45)

What does the accept-lifetime 04:00:00 Jan 1 2006 infinite command do? (Source: Implementing and Verifying EIGRP Authentication) A) B) C) D)

Q46)

Which command specifies that EIGRP MD5 authentication in AS 100 be used? (Source: Implementing and Verifying EIGRP Authentication) A) B) C) D) E)

Q47)

debug ip eigrp adj debug ip eigrp packets debug eigrp packets debug ip eigrp adjacency events debug eigrp adj

When a router gets a query from a neighboring router that is not a successor for the network listed in the query, and that network is in a passive state on this router, what does the router do? (Source: Advanced EIGRP Features in an Enterprise Network) A) B)

C) D) Q49)

ip authentication mode eigrp 100 md5 ip eigrp 100 authentication mode md5 ip authentication-key eigrp 100 ip message-digest-key eigrp 100 ip eigrp 100 authentication message-digest

Which command is used to troubleshoot EIGRP authentication? (Source: Implementing and Verifying EIGRP Authentication) A) B) C) D) E)

Q48)

specifies that a key is acceptable for use on received packets from the first of January 2006 onward specifies that a key is acceptable for use on sent packets from the first of January 2006 onward specifies that a key is acceptable for use on received packets until the first of January 2006 specifies that a key is acceptable for use on sent packets until the first of January 2006

The router replies that the destination is unreachable. The router attempts to find a new successor. If successful, it replies with new information. If unsuccessful, it marks the destination as unreachable and queries all neighboring routers except the previous successor. The router replies with the current successor information. The router marks the destination as unreachable and queries all neighboring routers except the previous successor.

Which three of these factors affect network scalability? (Choose three.) (Source: Advanced EIGRP Features in an Enterprise Network) A) B) C) D)

© 2009 Cisco Systems, Inc.

number of alternate paths through the network amount of information exchanged between neighbors the amount of different AS numbers used in the network depth of the topology

Implementing an EIGRP-Based Solution

2-189

Q50)

Which three statements about implementing EIGRP stub routers are true? (Choose three.) (Source: Advanced EIGRP Features in an Enterprise Network) A) B) C) D)

Q51)

How long does a querying router wait to reset a neighbor that fails to reply to a query? (Source: Advanced EIGRP Features in an Enterprise Network) A) B) C) D)

Q52)

15 seconds 40 seconds 1 minute 3 minutes

Which command configures an EIGRP stub router to not send any routing updates? (Source: Advanced EIGRP Features in an Enterprise Network) A) B) C) D)

2-190

Stub routing is commonly used on networks with hub-and-spoke topologies. The EIGRP stub feature should be configured only on remote spoke routers. EIGRP stub routers can and should be used as transit points to other parts of the network and other autonomous systems. Queries are not propagated to EIGRP stub routers; EIGRP updates are sent to stub routers, or a default route is passed.

eigrp stub eigrp stub receive-only eigrp stub no-send eigrp stub none

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Module Self-Check Answer Key Q1)

A, B, D

Q2)

C

Q3)

A

Q4)

B

Q5)

B, D

Q6)

A, B, C

Q7)

A, B, D

Q8)

A, B

Q9)

B

Q10)

C

Q11)

A

Q12)

A, B, D, E, G

Q13)

B

Q14)

E

Q15)

A, B, E

Q16)

A, B

Q17)

C

Q18)

B

Q19)

D

Q20)

C

Q21)

B, C

Q22)

A=4, B=5, C=7, D=2, E=1, F=8, G=3, H=6

Q23)

A

Q24)

A

Q25)

C

Q26)

D

Q27)

A, C, D

Q28)

C

Q29)

A

Q30)

B

Q31)

A

Q32)

C

Q33)

B

Q34)

B

Q35)

A,B

© 2009 Cisco Systems, Inc.

Implementing an EIGRP-Based Solution

2-191

2-192

Q36)

D

Q37)

A, B, D

Q38)

A

Q39)

B, C

Q40)

A, B

Q41)

B, C

Q42)

A

Q43)

B

Q44)

A, C, D

Q45)

A

Q46)

A

Q47)

C

Q48)

C

Q49)

A, B, D

Q50)

A, B, D

Q51)

D

Q52)

B

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

ROUTE

Implementing Cisco IP Routing Volume 2 Version 1.0

Student Guide Text Part Number: 97-2815-02

DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED “AS IS.” CISCO MAKES AND YOU RECEIVE NO WARRANTIES IN CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY OR IN ANY OTHER PROVISION OF THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO SPECIFICALLY DISCLAIMS ALL IMPLIED WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. This learning product may contain early release content, and while Cisco believes it to be accurate, it falls subject to the disclaimer above.

Student Guide

© 2009 Cisco Systems, Inc. All Rights Reserved.

Table of Contents Volume 2 Implementing a Scalable Multiarea Network OSPF-Based Solution Overview Module Objectives

Planning Routing Implementations with OSPF as the Scalable Routing Protocol Overview Objectives Link-State Routing Protocols OSPF Area Structure OSPF Adjacency Database Calculating the OSPF Metric Link-State Data Structures Maintaining Link-State Sequence Numbers Example: LSA Sequence Numbers and Maximum Age Planning for Implementing OSPF Summary

How OSPF Packet Processes Work Overview Objectives OSPF Packet Types Establishing OSPF Neighbor Adjacencies Exchanging and Synchronizing LSDB’s Maintaining Network Routes Verifying Packet Flow Example: debug ip ospf packet Summary

3-1 3-1 3-1

3-3 3-3 3-3 3-4 3-6 3-9 3-10 3-12 3-15 3-17 3-18 3-23

3-25 3-25 3-25 3-26 3-29 3-31 3-36 3-38 3-38 3-40

Improving Routing Performance in a Complex Enterprise Network

3-41

Overview Objectives Introducing OSPF Network Types Adjacency Behavior in Point-to-Point Links Adjacency Behavior in a Broadcast Network Adjacency Behavior in a Metro Ethernet and EoMPLS Network Adjacency Behavior in MPLS networks Selecting a DR and BDR OSPF over Different Frame Relay Implementations OSPF over Frame Relay NBMA Example: NBMA Configuration Example Using Sub-Interfaces in OSPF over Frame Relay Example: Point-to-Point Subinterface Example: Multipoint Subinterface Implementing OSPF over a Point-to-Point Frame Relay Network Example: Point-to-Point Configuration Implementing OSPF over a Point-to-Multipoint Frame Relay Network Example: Point-to-Multipoint Configuration Example: OSPF over NBMA Topology Summary Summary

3-41 3-41 3-43 3-44 3-45 3-47 3-49 3-51 3-54 3-59 3-62 3-64 3-66 3-68 3-69 3-70 3-72 3-74 3-77 3-78

Configuring and Verifying OSPF Routing Overview Objectives Initializing Single-Area and Multiarea OSPF Activating OSPF within a Router in Single-Area and Multiarea Defining the Router ID Verify OSPF Operations Identifying LSA Types within the LSDB Type 1 Type 2 Types 3 and 4 Type 5 Type 6 Type 7 Type 8 Types 9, 10, and 11 LSA Type 1 Link Types Example: LSA Type 4—ASBR Summary LSA Example: Types of Link State Advertisements (LSAs) Limiting Adjacencies in OSPF with the Passive-Interface Command Design Limitations of OSPF OSPF Virtual Links and Solutions to Non-Contiguous Area Problems Changing the Cost Metric Summary

Lab 3-1 Debrief Overview Objectives Lab Overview and Verification Sample Solution and Alternatives Summary

Lab 3-2 Debrief Overview Objectives Lab Overview and Verification Sample Solution and Alternatives Summary

Configuring and Verifying OSPF Route Summarization Overview Objectives OSPF Route Summarization Implementing OSPF Route Summarization Benefits of a Default Route in OSPF Using a Default Route in OSPF Summary

Lab 3-3 Debrief Overview Objectives Lab Overview and Verification Sample Solution and Alternatives Summary

Configuring and Verifying OSPF Special Area Types Overview Objectives OSPF Area Types Defining and Implementing a Stub Area Defining and Implementing a Totally Stubby Area Example: Totally Stubby Configuration ii

Implementing Cisco IP Routing (ROUTE) v1.0

3-79 3-79 3-79 3-80 3-82 3-85 3-90 3-97 3-97 3-97 3-97 3-98 3-98 3-98 3-98 3-98 3-99 3-102 3-105 3-126 3-128 3-130 3-136 3-138

3-141 3-141 3-141 3-142 3-148 3-151

3-153 3-153 3-153 3-154 3-158 3-161

3-163 3-163 3-163 3-164 3-166 3-173 3-174 3-176

3-177 3-177 3-177 3-178 3-182 3-185

3-187 3-187 3-187 3-188 3-192 3-195 3-197 © 2009 Cisco Systems, Inc.

Interpreting Routing Tables for OSPF Area Types Defining and Implementing a Not-So-Stubby-Area and Totally NSSA in OSPF Verifying All OSPF Area Types Summary

Lab 3-4 Debrief

3-211

Overview Objectives Lab Overview and Verification Sample Solution and Alternatives Summary

3-211 3-211 3-212 3-217 3-220

Configuring and Verifying OSPF Authentication

3-221

Overview Objectives Types of OSPF Authentication Implementing Simple Password Authentication for OSPF Configuring MD5 Authentication for OSPF Troubleshooting Authentication for OSPF Summary

Lab 3-5 Debrief

3-221 3-221 3-222 3-223 3-228 3-232 3-239

3-241

Overview Objectives Lab Overview and Verification Sample Solution and Alternatives Summary Module Summary Module Self-Check Module Self-Check Answer Key

3-241 3-241 3-242 3-246 3-249 3-251 3-253 3-269

Implement an IPv4-Based Redistribution Solution

4-1

Overview Module Objectives

4-1 4-1

Assessing Network Routing Performance and Security Issues Overview Objectives Common Network Performance Issues How Distribute Lists Work Using Distribution Lists to Control Routing Updates How Prefix Lists Work Using a Prefix List to Control Routing Updates How Route Maps Work Using Route-Maps to Control Routing Updates Using Route-Maps to Filter Routes Suppressing Routing Updates using a Passive Interface Summary

4-3 4-3 4-3 4-5 4-11 4-13 4-17 4-21 4-25 4-33 4-36 4-37 4-40

Operating a Network Using Multiple IP Routing Protocols Overview Objectives Describe a Complex Routing Network Defining Route Redistribution Default Metrics for Redistributed Routes Determining Where to Redistribute Caveats of Redistribution Summary

2009 Cisco Systems, Inc.

3-198 3-202 3-208 3-209

4-41 4-41 4-41 4-42 4-45 4-49 4-53 4-57 4-62

Implementing Cisco IP Routing (ROUTE) v1.0

iii

Configuring and Verifying Route Redistribution Overview Objectives Examples of Redistribution The Administrative Distance Attribute Route Redistribution using Administrative Distance Impact of using Administrative Distance for Route Manipulation Redistribution Using Route Maps Route Redistribution using Route Maps Summary

Lab 4-1 Debrief Overview Objectives Lab Overview and Verification Sample Solution and Alternatives Summary Module Summary Module Self-Check Module Self-Check Answer Key

iv

Implementing Cisco IP Routing (ROUTE) v1.0

4-63 4-63 4-63 4-64 4-76 4-78 4-82 4-87 4-89 4-91

4-93 4-93 4-93 4-94 4-98 4-101 4-103 4-105 4-108

© 2009 Cisco Systems, Inc.

Module 3

Implementing a Scalable Multiarea Network OSPFBased Solution Overview This module examines Open Shortest Path First (OSPF), which is one of the most commonly used interior gateway protocols in IP networking. OSPF is an open-standard protocol based primarily on RFC 2328, with some enhancements for IP version 6 (IPv6) based on RFC 2740. OSPF is a complex protocol made up of several protocol handshakes, database advertisements, and packet types. Configuration and verification of OSPF in a Cisco Systems router is a primary learning objective of this module. The lessons move from simple to more advanced configuration topics. Each of the important OSPF commands is explained and described in an example. All of the important OSPF show commands are defined.

Module Objectives Upon completing this module, you will be able to build a scalable multiarea network with OSPF. This ability includes being able to meet these objectives: Identify, analyze, and match OSPF multiarea routing functions and benefits for routing efficiency in a complex enterprise network Demonstrate how OSPF improves packet processes in a multiarea enterprise network Configure OSPF to improve routing performance in a complex enterprise network Discuss lab results for configuring and verifying OSPF to improve routing performance Given a network design, configure OSPF multiarea routing to improve network operations and reach performance expectations Discuss lab results for implementing and verifying OSPF multiarea routing Configure OSPF route summarization for interarea and external routes

Discuss lab results for configuring and verifying OSPF route summarization for interarea and external routes Configure and verify the OSPF area parameters, including stub areas, not-so-stubby areas (NSSAs), and totally stubby areas Discuss lab results for configuring and verifying OSPF special area types Implement authentication in an OSPF network Discuss lab results for configuring and verifying OSPF authentication

3-2

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 1

Planning Routing Implementations with OSPF as the Scalable Routing Protocol Overview Open Shortest Path First (OSPF) is one of the most commonly used IP routing protocols in networking. It is an open standard that is used by both enterprise and service provider networks. This lesson introduces each of the major characteristics of the OSPF routing protocol, including a description of link-state routing protocols, the OSPF hierarchical structure, link-state adjacencies, and Shortest Path First (SPF) calculations. Since the creation of the implementation plan the first step in configuring the OSPF routing protocol, it is also described.

Objectives Upon completing this lesson, you will be able to explain link state protocols, components, the metrics of OSPF, the way in which OSPF operates, and the implementation plan creation process. This ability includes being able to meet these objectives: Determine link-state routing protocols Determine OSPF area structure Determine OSPF adjacency database Calculate the OSPF metric Determine link-State data structures Maintain link-state sequence numbers Plan for OSPF implementation

Link-State Routing Protocols This topic describes the features of link-state routing protocols.

Link-State Protocols

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-2

The need to overcome the limitations of distance vector routing protocols led to the development of link-state routing protocols. By using link-state advertisements (LSAs), each router builds its own view of the network, and also maintains a list of neighbors, a list of all routers in the area, and a list of the best paths to each destination. OSPF is classified as a linkstate routing protocol, because of the manner in which it distributes routing information and calculates routes. Link-state routing protocols generate routing updates only when a change occurs in the network topology. When a link changes state, the device that detected the change creates a link-state advertisement (LSA) concerning that link. The LSA is propagated to all neighboring devices using a special multicast address. Each routing device creates a copy of the LSA, updates its link-state database (LSDB), and forwards the LSA to all neighboring devices (within an area, as described later in this lesson). This flooding of the LSA ensures that all routing devices update their databases before updating routing tables to reflect the new topology. The LSDB is used to calculate the best paths through the network. Link-state routers find the best paths to a destination by applying Dijkstra’s algorithm, also known as SPF, against the LSDB to build the SPF tree. The best paths are then selected from the SPF tree and placed in the routing table. Note

3-4

The 224.0.0.5 multicast address is used by OSPF routers and the 224.0.0.6 multicast address is used by OSPF designated routers (RFC 1583, JXM1).

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Link-State Protocol Data Structures Link-state routers recognize more information about the network than their distance vector counterparts. – Neighbor table: also known as the adjacency database – Topology table: referred as the LSDB – Routing table: also known as the forwarding database Each router has a full picture of the topology Link-state routers tend to make more accurate decisions

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-3

Link-state routing protocols collect routing information from all other routers in the network or from within a defined area of the network. When link-state routing protocols have collected this information from all routers, each router independently calculates its best path to all destinations in the network using Dijkstra’s algorithm. Incorrect information from any particular router is less likely to cause confusion, because each router maintains its own view of the network. For consistent routing decisions to be taken by all the routers in the network, each router must keep a record of the following information: Its immediate neighbor routers: If the router loses contact with a neighboring router, within a few seconds, it will invalidate all paths through that router and recalculate its paths through the network. Adjacency information about neighbors is stored in the neighbor table, also known as an adjacency database, in OSPF. All the other routers in the network, or in its area of the network, and their attached networks: The router recognizes other routers and networks through LSAs, which are flooded through the network. LSAs are stored in a topology table, also called an LSDB. The LSDB is identical for all OSPF routers in an area. The memory resources that are needed to maintain these tables represent one drawback to link-state protocols. The best path to each destination: Each router independently calculates the best paths to each destination in the network using Dijkstra’s algorithm. The best paths are then offered to the routing table or forwarding database. Packets arriving at the router are forwarded based on the information held in the routing table. Each router is able to independently select a loop-free and efficient pathway. This benefit overcomes the “routing by rumors” limitation of distance vector routing.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-5

OSPF Area Structure This topic describes the two-tier hierarchy structure of OSPF, including the characteristics of transit areas and regular areas, as well as the terminology used.

OSPF Areas Link-state routing requires a hierarchical network structure This two-level hierarchy consists of the following: – Transit area (backbone or area 0) – Normal areas (non-backbone areas)

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-4

In small networks, the web of router links is not complex, and paths to individual destinations are easily deduced. However, in large networks, the web is highly complex and the number of potential paths to each destination is large. Therefore, the Dijkstra calculations comparing all these possible routes can be very complex and can take a significant amount of time to complete. Link-state routing protocols usually reduce the size of the Dijkstra calculations by partitioning the network into areas. The number of routers in an area and the number of LSAs that flood within the area are small, which means that the link-state or topology database for an area is small. Consequently, the Dijkstra calculation is easier and takes less time. Routers inside an area maintain detailed information about the links and only general or summary information about routers and links in other areas. Link-state routing protocols use a two-layer area hierarchy: Backbone or transit area: The primary function of this OSPF area is to quickly and efficiently move IP packets. Backbone areas interconnect with other OSPF area types. The OSPF hierarchical area structure requires that all areas connect directly to the backbone area. You will notice that in the figure in the slide, links between area 1 routers and area 2 routers are not allowed. Generally, end users are not found within a backbone area. It is also known as OSPF area 0.

3-6

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Normal or non-backbone area: The primary function of this OSPF area is to connect users and resources. Normal areas are usually set up according to functional or geographical groupings. By default, a normal area does not allow traffic from another area to use its links to reach other areas. All traffic from other areas must cross a transit area such as area 0. Normal areas can be of different types. The optimal number of routers per area varies based on factors such as network stability, but in the “Designing Large-Scale Internetworks” document, Cisco recommends that there generally be no more than 50 routers per area.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-7

Area Terminology and Router Types ABR: Area Border Router ASBR: Autonomous System Boundary Router R5, R6: Internal routers R1: Backbone router

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-5

All OSPF areas and routers running OSPF routing protocol compose the OSPF autonomous system. Routers that make up non-backbone (normal) areas are known as internal routers and they have all interfaces in one area only. Routers that make up area 0 are known as backbone routers (internal routers in backbone). OSPF hierarchical networking defines area 0 as the core. All other areas connect directly to backbone area 0. An Area Border Router (ABR) connects area 0 to the non-backbone areas. An OSPF ABR plays a very important role in network design and has interfaces in more than one area. An ABR has the following characteristics: It separates LSA flooding zones. It becomes the primary point for area address summarization. It functions regularly as the source for default routes. It maintains the LSDB for each area with which it is connected. The ideal design is to have each ABR connected to two areas only, the backbone and another area, with three areas being the upper limit. An Autonomous System Boundary Router (ASBR) connects any OSPF area to a different routing administration (such as Border Gateway Protocol [BGP] or Enhanced Interior Gateway Routing Protocol [EIGRP]). The ASBR is the point where external routes can be redistributed into OSPF.

3-8

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

OSPF Adjacency Database This topic describes how routers running a link-state routing protocol establish neighbor adjacencies with their neighboring routers.

OSPF Adjacencies Routing updates and topology information are passed only between adjacent routers.

Forming OSPF adjacencies on point-to-point WAN links

Forming OSPF adjacencies on LAN links is different than forming them on point-to-point links. © 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-6

A router running a link-state routing protocol must first establish neighbor adjacencies with its neighboring routers. A router achieves this neighbor adjacency by exchanging hello packets with the neighboring routers. Once routers become adjacent, they begin exchanging the link-state information to synchronize the LSDB. Link-state information must be synchronized between routers and the process is described later in this module. Only by reliably flooding link-state information can you ensure that every router in the area or domain has the latest, most accurate view of the network. Only then can the router make reliable routing decisions that are consistent with the decisions of other routers in the network. The two OSPF routers on a point-to-point serial link, which are usually encapsulated in HighLevel Data Link Control (HDLC) or PPP, form a full adjacency with each other. OSPF routers on the LAN form adjacencies in a different way and the process is described later in this module.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-9

Calculating the OSPF Metric This topic describes the SPF algorithm and the calculations used by OSPF to find the best path to each destination network. The routing table is then populated with the best paths.

OSPF Calculation Routers find the best paths to destinations by applying Dijkstra’s SPF algorithm to the LSDB. The best path is calculated based on the lowest total cost and sent to the routing table.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-7

All routers form an adjacency, which is the prerequisite for the LSDB creation process. Once they have all formed adjacencies, they start exchanging LSAs. Router R1 has four neighboring routers: R2, R3, R4, and R5. From these routers, it receives the LSAs from all other routers in the network. From these LSAs, it can also deduce the links between all routers and draw the web of routers depicted in the figure in the slide. In this way an LSDB is created. Edsger Dijkstra designed a mathematical algorithm for calculating the best paths through complex networks. Link-state routing protocols use Dijkstra’s algorithm to calculate the best paths through a network. They assign a cost to each link in the network and place the specific node at the root of a tree, then sum the costs toward each given destination. In this way they calculate the branches of the tree to determine the best path to each destination. The best path is calculated with respect to the lowest total cost of links to a specific destination and is put in the forwarding database (routing table). For OSPF, the default behavior is that the interface cost is calculated based on its configured bandwidth. You can also manually define an OSPF cost for each interface, which overrides the default cost value. The figure illustrates an example of a Dijkstra calculation. Each Ethernet link in the figure is assigned an OSPF cost of 10. By summing the costs to each destination, the router can deduce the best path to each destination. The right side of the figure shows the result of Dijkstra calculation, in which the SPF tree is defining the best paths. From these best paths, shown with solid lines, routes to destination networks attached to each router are offered to the routing table; for each route, the next-hop address is the appropriate neighboring router (R2, R3, R4, or R5).

3-10

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

OSPF Metric Also called “cost” Defined per interface, but may be altered Inversely proportional to the bandwidth of that interface COST = 100,000,000 / bandwidth [b/s]

Link Type

Default Cost

64-kb/s s erial link

1562

T1 (1.544-Mb/s serial link)

64

E1 (2.048-Mb/s serial link)

48

Ethernet

10

Fast Ethernet

1

ATM

1

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-8

The cost (also called the metric) of an interface in OSPF is an indication of the overhead required to send packets across a certain interface. The cost of an interface is inversely proportional to the bandwidth of that interface. A higher bandwidth indicates a lower cost. There is more overhead (higher cost) and time delays involved in crossing a 56 kb/s serial line than crossing a 10 Mb/s Ethernet line. The formula used to calculate the cost is: Cost = 100,000,000 / bandwidth in b/s For example, it will cost 108/107 = 10 to cross a 10-Mb Ethernet line and will cost 108/1544000 = 64 to cross a T1 line. By default, the cost of an interface is calculated based on the bandwidth and can be changed by using the OSPF configuration command. If you change the link bandwidth, it will also indirectly change the cost. Only one cost can be assigned per interface and it is advertised as the link cost in the router link advertisements. Links have different default costs, as follows: 56-kb/s serial link: default cost is 1785 64-kb/s serial link: default cost is 1562 T1 (1.544-Mb/s serial link): default cost is 64 E1 (2.048-Mb/s serial link): default cost is 48 Ethernet: default cost is 10 Fast Ethernet: default cost is 1 FDDI: default cost is 1 ATM: default cost is 1

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-11

Link-State Data Structures This topic describes how routers use link-state updates (LSUs) to verify that links are still active.

Building the LSDB The Hello protocol is used to define neighbors Adjacency is established Adjacent routers exchange LSAs Each router builds an LSDB using LSAs

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-9

Routers that share a common segment become neighbors on that segment. Neighbors are elected via the Hello protocol. Hello packets are sent periodically out of each interface and routers become neighbors as soon as they see themselves listed in the neighbor's Hello packet. This way, a two-way communication is guaranteed. Two routers will not become neighbors unless they agree on the following: Area ID: Two routers having a common segment; their interfaces have to belong to the same area on that segment. Authentication: OSPF allows for the configuration of a password for a specific area. Routers that want to become neighbors have to exchange the same password on a particular segment. Hello and dead intervals: OSPF exchanges hello packets on each segment. This is a form of keepalive used by routers in order to acknowledge their existence on a segment and in order to elect a designated router (DR) on multiaccess segments. OSPF requires these intervals to be exactly the same between two neighbors. Stub area flag: Two routers have to agree on the stub area flag in the hello packets in order to become neighbors. Stub areas will be discussed in a later section. Keep in mind for now that defining stub areas will affect the neighbor election process. Adjacency is the next step after the process of becoming neighbors. Adjacent routers are routers that go beyond the simple hello exchange and proceed into the database exchange process. Link-state update packets are exchanged and acknowledgement is required. Selection and processing of link-state updates is based on the sequence numbers. At the end, the adjacent routers will have the exact same link-state database. 3-12

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

The following is a brief summary of the states an interface passes through before becoming adjacent to another router: Down Attempt INIT Two-way Exstart Exchange Loading Full

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-13

Link-State Data Structures: LSA Operation

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-10

Each LSA entry has its own aging timer, which the link-state age field carries. The default timer value for OSPF is 30 minutes (expressed in seconds in the link-state age field). After an LSA entry ages, the router that originated the entry sends the LSA (with a higher sequence number, in a Link State Update, or LSU) to verify that the link is still active. The LSU can contain one or more LSAs. This LSA validation method saves on bandwidth compared to distance vector routers, each of which sends its entire routing table at short intervals. When each router receives the LSU, it does the following: If the LSA does not already exist, the router adds the entry to its LSDB, sends a link-state acknowledgment back, floods the information to other routers, runs SPF, and updates its routing table. If the entry already exists and the received LSA has the same sequence number, the router ignores the LSA entry. If the entry already exists but the LSA includes newer information (it has a higher sequence number), the router adds the entry to its LSDB, sends a link-state acknowledgment back, floods the information to other routers, runs SPF, and updates its routing table. If the entry already exists but the LSA includes older information, it sends an LSU to the sender with its newer information.

3-14

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Maintaining Link-State Sequence Numbers This topic describes the process of maintaining a database of only the most recent link-state sequence numbers.

Defining the “More Recent” LSA An LSA is more recent if it has: A higher sequence number A higher checksum number An age equal to the maximum age (poisoning) A significantly smaller link-state age (the LSA is significantly younger)

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-11

A combination of the maximum age (maxage) and refresh timers, as well as link-state sequence numbers, helps OSPF maintain a database of only the most recent link-state records. An LSA is more recent if it has: A higher sequence number A higher checksum number An age equal to the maximum age (poisoning) A significantly smaller link-state age (the LSA is significantly younger)

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-15

LSA Sequence Numbering Each LSA in the LSDB maintains a sequence number 4-byte number begins with 0x80000001; ends with 0x7FFFFFFF

OSPF floods each LSA every 30 minutes Each time, the sequence number is incremented by one. The LSA with the higher (newer) sequence number is more recent

Ultimately, a sequence number will wrap around to 0x80000001 The existing LSA was prematurely aged to the maximum age (one hour) and flushed.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-12

The link-state sequence number field in an LSA header is 32 bits long (4 bytes). Beginning with the leftmost bit set, the first legal sequence number is 0x80000001 and the last one is 0x7FFFFFFF. The number is incremented in each new LSA until it reaches 0xFFFFFFFF. The next number is then 0x00000000, followed by 0x00000001, etc. 0x8000000 is reserved and never used. This field is used to detect old or redundant LSAs; the larger the number, the more recent the LSA. To ensure an accurate database, OSPF floods (refreshes) each LSA every 30 minutes. Each time a record is flooded, the sequence number is incremented by one. An LSA record will reset its maximum age when it receives a new LSA update. An LSA will never remain longer in the database than the maximum age of one hour without a refresh. It is possible for an LSA to remain in the database for long periods of time, getting refreshed every 30 minutes. At some point, the sequence number will need to wrap back to the starting sequence number. When this occurs, the existing LSA will be prematurely aged out (the maximum age timer is immediately set to one hour) and flushed. The LSA will then begin its sequencing at 0x80000001 again. When a router encounters two instances of an LSA, it must determine which is more recent. The LSA with the higher link-state sequence number is the more recent LSA.

3-16

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

LSA Sequence Numbers and Maximum Age Every OSPF router announces a router LSA for those interfaces that it owns in that area. Router with link ID 192.168.1.67 has been updated eight times; the last update was 48 seconds ago.

Îďý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďçîňďęčňďňęé÷ řĐ®±˝»­­ ×Ü Î±«¬ »® Ô· ˛µ Í ¬ż¬»­ řß®»ż ď÷ Ô·˛µ × Ü ßÜĘ Î±«¬» ® ßą» Í»Żý ݸ»˝µ­«ł ďçîňďę čňďňęé ďçîňďęčňďňęé ěč đ¨čđđđđđđč đ¨Ţďďî ďçîňďę čňîňďíđ ďçîňďęčňîňďíđ îďî đ¨čđđđđđđę đ¨íÚěě 䱫¬°« ¬ ±ł·¬¬»Ľ â

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ďđ÷ Ô·˛ µ ˝±« ˛¬ î î

ROUTE v1. 0— 3-13

Example: LSA Sequence Numbers and Maximum Age The show ip ospf database command displays lists of information related to the Open Shortest Path First (OSPF) database for a specific router. The output of the command shown in the figure in the slide provides an example of how the link-state age and LSA sequence numbers are kept in the database. Every OSPF router has interfaces in one or more areas and announces a router LSA for those interfaces that it owns in those areas. The link ID is the ID of the router that created the router LSA. The advertising router (shown as “ADV Router” in the output) is the router ID of the OSPF router that announced the router LSA. Generally, the link ID and advertising router for a router LSA are the same. The first router LSA entry in the OSPF database indicates that the router LSA with link ID 192.168.1.67 has been updated eight times (because the sequence number is 0x80000008), and that the last update occurred 48 seconds ago. For more details about the show ip ospf database command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-17

Planning for Implementing OSPF This topic describes how to plan, implement, and document the OSPF deployment.

Planning for OSPF Assess the requirements and options: – IP addressing plan – Network topology Primary vs. backup links WAN bandwidth utilization

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

Define hierarchical network design and areas Evaluate OSPF scaling options – Summarization - where necessary – Define stub areas

ROUTE v1. 0— 3-14

The OSPF routing protocol implementation depends on specific needs and topologies. When preparing to deploy OSPF routing in a network, you must first gather the existing state and requirements, and also consider different deployment considerations as follows: The IP addressing plan governs how OSPF can be deployed and how well the OSPF deployment might scale. Thus, a detailed IP addressing plan, along with IP subnetting information, must be defined. A solid IP addressing plan should enable usage of OSPF summarization in order to scale the network and to optimize OSPF behavior more easily. A network topology consists of links connecting the network equipment (routers, switches, and so on). A detailed network topology plan should be presented in order to assess OSPF scalability requirements and determine which OSPF features might be required (for example OSPF summarization and redistribution). OSPF can control the size of the LSDB by using different areas, which decrease the LSDB size and limit the propagation of link-state updates in case of a topology change within one area.

3-18

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

OSPF Implementation Plan Verify and configure IP addressing Enable OSPF for the correct interfaces Enable OSPF for the correct areas Define special metric to influence path selection Verify the configuration Area

Router

Interface

0

R1

S0/0, S0/1

0

R2

S0/0, S0/1

1

R2

S0/2

0

R3

S0/0, S0/1

2

R3

S0/2

0

R4

S0/0, S0/1

3

R4

S0/2

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-15

Once you have assessed the requirements, you can create the implementation plan. In order to implement OSPF routing you must do the following: Learn IP addressing, or more precisely, the networks that need to be included and advertised by OSPF. Enable the OSPF process for the correct interfaces or the correct network statements under the OSPF routing process configuration mode. The OSPF process must be enabled for the correct areas on the interfaces. Any specific metric that needs to be applied to certain interfaces in order to influence the default best path selection by OSPF routing protocol must be known. The table should include the required metric along with the interface where the metric needs to be applied. When the implementation plan is created, the list of task for each router in the network must be defined as follows: Enable the OSPF routing protocol on an interface, or use the correct network statements under the OSPF routing process configuration mode. Assign the correct area ID to the interface through the OSPF configuration under the interface or under the OSPF routing process configuration mode. You can also apply the metric to proper interfaces.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-19

After implementation, you should perform verification to confirm that OSPF has been deployed properly on each router: Verify the setup of OSPF adjacency. Verify that the OSPF LSDB is populated with the proper information. Verify that the IP routing table is populated with the proper information. Verify that there is connectivity in the network. Verify that OSPF behaves as expected when a topology change occurs (test link failure and router failure events).

3-20

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Documenting OSPF Documenting OSPF: Topology Areas and IP addressing Networks and interfaces included in OSPF per router Default and non-default metrics applied Configuration and verification results

Router R1 networks Router R2 10.1.1.0 networks 10.1.2.0 Router R3 10.2.1.0 ... networks

Router

Link

R3

Eth0

Cost 10

R3

Serial0/0

30

R3

Serial0/1

64

10.2.2.0 10.2.0.0 / 16 ... …

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-16

After a successful OSPF deployment, you should document the solution, and then put the information about the deployment in a safe place. The implementation plan itself is half of the information. In order to complete the documentation, you must also include the verification process and results.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-21

Example: Planning for Basic OSPF Define the network requirements Gather the required parameters Define the OSPF areas and routing Configure basic OSPF Verify the OSPF configuration Complete the documentation

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-17

The example in the figure in the slide illustrates the steps necessary to prepare an implementation plan to configure basic OSPF. When you are planning for the basic OSPF configuration, you should ensure that the implementation plan includes the following steps: Define the network requirements. Gather the required parameters. Define OSPF routing. Configure basic OSPF. Verify the OSPF configuration.

3-22

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary Link-state routing protocols respond quickly to changes, send triggered updates when changes occur, and send periodic updates every 30 minutes. A two-tier hierarchical network structure is used by OSPF, in which the network is divided into areas. This area structure is used to separate the LSDB into more manageable pieces. Adjacencies are built by OSPF routers using the Hello protocol. LSUs are sent over these logical adjacencies, in order to exchange database information between adjacent OSPF routers. Dijkstra’s SPF algorithm is used to calculate best paths for all destinations. SPF is run against the LSDB, and the result is a table of best paths, known as the routing table.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-18

Summary (Cont.) After an LSA entry ages, the router that originated the entry sends an LSU about the network to verify that the link is still active. The LSU can contain one or more LSAs. Each LSA in the LSDB has a sequence number, which is incremented by one each time the LSA is flooded. When a router encounters two instances of an LSA, it must determine which is more recent. The LSA with the higher LSA sequence number is the more recent. When planning an OSPF deployment, define the network requirements, gather the required parameters, and define the OSPF routing.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1. 0— 3-19

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-23

3-24

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 2

How OSPF Packet Processes Work Overview The Open Shortest Path First Protocol (OSPF) protocol has several functions and five packet types to support them: hello, database description (DBD), link-state request (LSR), link-state update (LSU), and link-state acknowledgement (LSAck). The five OSPF packet types enable all OSPF information flow between routers. This lesson defines each packet type and explains where and how these packets interact to build OSPF neighbor adjacencies and maintain the OSPF topology database.

Objectives Upon completing this lesson, you will be able to explain how information flows between routers to maintain OSPF links and which packets are used. This ability includes being able to meet these objectives: Determine OSPF packet types Establish OSPF neighbor adjacencies Exchange and synchronize LSDBs Maintain network routes Verify packet flow

OSPF Packet Types This topic describes the five OSPF packet types.

OSPF Functions High-level functions of OSPF include the following: Discover neighbors and form adjacencies Flood link-state database (LSDB) information Compute the shortest path Install routes in the route-forwarding table

Additional functions of OSPF include the following: Detect changes in the link state Propagate changes to maintain link-state database synchronization

Several OSPF packet types are involved

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-2

In order for OSPF to operate properly, several processes must occur: Neighbor discovery to form adjacencies Flooding of the link state information in order to build a link-state database (LSDB) Computation of SPF to find out the shortest path to all known destinations Populating of the route forwarding table with the best routes to known destinations Once OSPF initially populates the router forwarding table, the state of the links around the OSPF autonomous system may change. OSPF is able to detect these changes and respond by flooding this information throughout the OSPF autonomous system, or at least in the area where the change was detected. The flooding of new information is needed in order to maintain the link-state databases (LSDBs) in all neighboring routers. For all functions above, several OSPF packet types are involved and will be described in this Lesson.

3-26

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

OSPF Packet Header Format ÎďýĽ»ľ«ą ·° ±­°ş ° ż˝µ»¬ ŃÍĐÚ °ż˝µ »¬ Ľ »ľ«ąą ·˛ą ·­ ±˛ Îďý öÚ»ľ ďę ď ďćđí ćëďňî đęć ŃÍĐÚć ®˝Şň Şćî ¬ćď ´ ćěč ®·Ľćďđňđňđňďî ż·Ľćđňđ ňđňď ˝¸µćÜččî ż «¬ćđ ż«µć ş®±ł Í»®·ż´đńđńđňî

This debug output shows fields in the OSPF header.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-3

All five OSPF packets are encapsulated directly into an IP payload, as shown in the figure. The OSPF packet does not use TCP or User Datagram Protocol (UDP). OSPF requires a reliable packet transport scheme, and because it does not use TCP, it has defined its own acknowledgment routine using an acknowledgment packet (OSPF packet type 5). In the IP header, a protocol identifier of 89 defines all OSPF packets. Each of the OSPF packets begins with the same header format. This header has the following fields: Version number: Version 2 for OSPF with IPv4 and version 3 for OSPF with IPv6 Type: Differentiates the five OSPF packet types Packet length: Is the length of the OSPF packet in bytes Router ID: Defines which router is the source of the packet Area ID: Defines the area where the packet originated Checksum: Is used for packet-header error detection to ensure that the OSPF packet was not corrupted during transmission Authentication type: Is an option in OSPF that describes either no authentication, cleartext passwords, or encrypted Message Digest 5 (MD5) formats for router authentication Authentication: Is used in the authentication scheme Data: Each of the five packet types includes different data —

Hello packets: Contains a list of known neighbors

—

DBD packet: Contains a summary of the link-state database (LSDB), which includes all known router IDs and their last sequence numbers, among a number of other fields

—

LSR packet: Contains the type of LSU needed and the router ID that has the needed LSU

—

LSU packet: Contains the full link-state advertisement (LSA) entries. Multiple LSA entries can fit in one OSPF update packet

—

LSAck packet: Is empty

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-27

OSPF Packet Types OSPF uses five types of routing protocol packets.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-4

OSPF uses five types of routing protocol packets, which share a common protocol header. The protocol ID number inside the IP header is 89, and all five packet types are used in the normal operation of OSPF. OSPF Packets The table contains descriptions of each type.

3-28

Type

Packet Name

Description

1

Hello

Discovers neighbors and builds adjacencies between them

2

DBD

Checks for database synchronization between routers

3

LSR

Requests specific link-state records from another router

4

LSU

Sends specifically requested link-state records

5

LSAck

Acknowledges the other packet types

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Establishing OSPF Neighbor Adjacencies This topic describes how OSPF neighbor adjacencies are established.

Neighbor Relationship: The Hello Packet * Entries must match on neighboring routers

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-5

Each interface participating in OSPF uses IP multicast address 224.0.0.5 to send hello packets periodically. A hello packet contains the following information: Router ID: The router ID is a 32-bit number that uniquely identifies the router. The highest IP address on an active interface is chosen by default, unless a loopback interface or the router ID is configured; for example, IP address 172.16.12.1 would be chosen over 172.16.1.1. This identification is important in establishing neighbor relationships and coordinating LSU exchanges. Also, the router ID breaks ties during the designated router (DR) and backup designated router (BDR) selection processes if the OSPF priority values are equal. Hello and dead intervals: The hello interval specifies the frequency, in seconds, with which a router sends hello packets (10 seconds is the default on multiaccess networks). The dead interval is the time in seconds that a router waits to hear from a neighbor before declaring the neighboring router out of service (four times the hello interval, by default). These timers must be the same on neighboring routers; otherwise an adjacency will not be established. Neighbors: The neighbors field lists the adjacent routers with established bidirectional communication. This bidirectional communication is indicated when the router recognizes itself listed in the neighbors field of the hello packet from the neighbor. Area ID: To communicate, two routers must share a common segment, and their interfaces must belong to the same OSPF area on that segment (they must also share the same subnet and mask). These routers will all have the same link-state information. Router priority: The router priority is an 8-bit number that indicates the priority of a router. Priority is used when selecting a DR and BDR. DR and BDR IP addresses: These are the IP addresses of the DR and BDR for the specific network, if they are known. © 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-29

Authentication password: If router authentication is enabled, two routers must exchange the same password. Authentication is not required, but if it is enabled, all peer routers must have the same password. Stub area flag: A stub area is a special area. Two routers must agree on the stub area flag in the hello packets. Designating a stub area is a technique that reduces number of routing updates by replacing many of them with a default route. Note

3-30

The following fields must match when hello packets are exchanged between the neighboring routers: hello and dead intervals, area ID, authentication password, and stub area flag.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Exchanging and Synchronizing LSDB’s Once a bidirectional adjacency is formed, OSPF must exchange and synchronize the LSDBs between routers. This topic describes the process of exchanging and synchronizing the LSDBs between routers.

OSPF Routing Update Packets Use of Multicast and unicast IP address Four types of update packets LSDB synchronization process – Discover neighbor – Establish bidirectional communication – Elect a designated router, if desired – Form an adjacency – Discover the network routes – Update and synchronize link-state databases

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-6

All routing updates are sent in IP packets (protocol type 89), for which OSPF does not do any fragmentation and reassembly on the IP. Four types of update packets are used when exchanging and synchronizing LSDBs: Type 2 database description packet: Used to describe the network routes of each neighbor. Type 3 link-state request packet: After database description packets are exchanged, the routers request missing information by using request packets. Type 4 link-state update packet: All missing information is sent to the neighbors by sending update packets, which contain different LSAs. Type 5 link-state acknowledgment packet: Every packet is acknowledged, to ensure reliable transport and reliable exchange of information. Type 4 and type 5 packets are sent to multicast IP addresses, except when retransmitting, when sent across a virtual link, and when sent on non-broadcast networks. All other packets are sent to unicast IP addresses. The LSDB synchronization process starts with neighbor discovery. After a neighbor has been discovered, bidirectional communication commences. A designated router may also be elected (for example if the OSPF protocol is active on the LAN). Then routers make a decision whether or not an adjacency is formed. If an adjacency is to be formed, neighbors have to synchronize link-state databases. First, network routes are discovered, and then missing information is exchanged. Finally, LSDB is synchronized, as described in the following pages. © 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-31

Establishing Bidirectional Communication

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-7

When routers running OSPF are initialized, an exchange process using the Hello protocol is the first procedure. The exchange process that happens when routers appear on the network is illustrated in the figure in the slide: 1. Router R1 is enabled on the LAN and is in a down state, because it has not exchanged information with any other router. It begins by sending a hello packet through each of its interfaces participating in OSPF, even though it does not know the identity of the DR or of any other routers. The hello packet is sent out using the multicast address 224.0.0.5. 2. All directly connected routers running OSPF receive the hello packet from router R1 and add router R1 to their lists of neighbors. After adding router R1 to the list other router are in the initial state (INIT state). 3. Each of the routers that received the hello packet sends a unicast reply hello packet to router R1 with its corresponding information. The neighbor field in the hello packet includes all neighboring routers and router R1. 4. When router R1 receives these hello packets, it adds all the routers that had its router ID in their hello packets to its own neighbor relationship database. After this process router R1 is in the two-way state. At this point, all routers that have each other in their lists of neighbors have established bidirectional communication. If the link type is a broadcast network, generally a LAN link like Ethernet, then a DR and BDR must first be selected. The DR forms bidirectional adjacencies with all other routers on the LAN link. This process must occur before the routers can begin exchanging link-state information. Periodically (every 10 seconds on broadcast networks, by default) the routers within a network exchange hello packets to ensure that communication is still working. The hello updates include the DR, BDR, and the list of routers for which hello packets have been received by the router. Remember that “received” means that the receiving router recognizes its own name as one of the entries in the received hello packet. Note

3-32

The concept of DR and BDR will be described later in this module.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Discovering the Network Routes

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-8

After the DR and BDR have been selected (applied to LAN link types), the routers are considered to be in the exstart state. The routers are then ready to discover the link-state information about the internetwork and create their LSDBs. The exchange protocol is used to discover the network routes, and it gets all the routers from exchange state to a full state of communication. The first step in this process is for the DR and BDR to establish adjacencies with each of the other routers. When adjacent routers are in a FULL state, they do not repeat the exchange protocol unless the full state changes. As shown in the figure, the exchange protocol operates as follows: Step 1

Note

In the exstart state, the DR and BDR establish adjacencies with each router in the network. During this process, a master-slave relationship is created between each router and its adjacent DR and BDR. The router with the higher router ID acts as the master during the exchange process—Router R2 becomes DR. Only the DR exchanges and synchronizes link-state information with the routers to which it has established adjacencies. Having the DR represent the network in this capacity reduces the amount of routing update traffic. The concepts of DR and BDR will be explained later in this module.

The master and slave routers exchange one or more DBD packets. The routers are in the exchange state. A DBD includes information about the LSA entry header that appears in the LSDB of the router. The entries can be about a link or about a network. Each LSA entry header includes information about the link-state type, the address of the advertising router, the cost of the link, and the sequence number. The router uses the sequence number to determine the “newness” of the received link-state information.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-33

Adding the Link-State Entries

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

Step 2

ROUTE v1.0—3-9

When the router receives the DBD, it performs these actions, as shown in the figure: 1. It acknowledges the receipt of the DBD using the LSAck packet. 2. It compares the information it received with the information it has. If the DBD has a more up-to-date link-state entry, then the router sends an LSR to the other router. When routers start sending LSRs they are in the loading state. 3. The other router responds with the complete information about the requested entry in an LSU packet. Again, when the router receives an LSU, it sends an LSAck.

Step 3

The router adds the new link-state entries to its LSDB.

When all LSRs have been satisfied for a given router, the adjacent routers are considered synchronized. They are in a full state. The routers must be in a full state before they can route traffic. At this point, all the routers in the area should have identical LSDBs.

3-34

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

OSPF Neighbor States OSPF routers progress through seven states: Down: no active neighbor detected INIT: hello packet received Two-way: own router ID in received hello Exstart: master and slave roles determined Exchange: database description packets sent Loading: exchange of LSRs and LSUs Full: neighbors fully adjacent

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-10

The following is a brief summary of the states an interface passes through before becoming adjacent to another router: Down: No information has been received from anybody on the segment. Attempt: In nonbroadcast multiaccess clouds such as Frame Relay and X.25, this state indicates that no recent information has been received from the neighbor. An effort should be made to contact the neighbor by sending hello packets at the reduced rate poll interval. INIT: The interface has detected a hello packet coming from a neighbor but bidirectional communication has not yet been established. Two-way: There is bidirectional communication with a neighbor. The router has seen itself in the hello packets coming from a neighbor. At the end of this stage, the DR and BDR election would have been done. When routers are in the two-way state they must decide whether to proceed in building an adjacency or not. The decision is based on whether one of the routers is a DR or BDR or the link is a point-to-point or a virtual link. Exstart: Routers are trying to establish the initial sequence number that is going to be used in the information exchange packets. The sequence number ensures that routers always get the most recent information. One router will become the primary and the other will become secondary. The primary router will poll the secondary for information. Exchange: Routers will describe their entire link-state database by sending database description packets. In this state, packets may be flooded to other interfaces on the router. Loading: In this state, routers are finalizing the information exchange. Routers have built a link-state request list and a link-state retransmission list. Any information that looks incomplete or outdated will be put on the request list. Any update that is sent will be put on the retransmission list until it gets acknowledged. Full: In this state, adjacency is complete. The neighboring routers are fully adjacent. Adjacent routers will have similar link-state databases.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-35

Maintaining Network Routes This topic describes how OSPF maintains synchronization of the LSDBs (topology tables) of all routers in the network.

Flooding Changes in Topology Router R1 that detects a topology change adjusts its LSA and floods the LSA: – Router R1 notifies all OSPF neighbors using 224.0.0.5, or, on LAN links, all OSPF DRs and BDRs using 224.0.0.6. – The DR notifies others on 224.0.0.5. The LSDBs of all routers must be synchronized.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-11

In a link-state routing environment, it is very important for the LSDBs (topology tables) of all routers to stay synchronized. When there is a change in a link state, the routers use a flooding process to notify the other routers in the network of the change. LSUs provide the mechanism for flooding LSAs. A router that detects a topology change adjusts its LSA, increments its LSA sequence number and floods the LSA. Only the LSA originator can adjust or regenerate the LSA. A router that receives an LSA update packet compares the received LSA to its own copy. If the received LSA is more recent, it is installed in the database and flooded. If the database copy is newer, it is send back to the sending neighbor. This is an exception to the rule, because a router is not supposed to re-originate the LSAs of other routers. Periodic LSA refreshment is another mechanism to maintain the LSDB. Each LSA has an age field. LSAs are aged when flooded and in the topology database. LSAs that reach the maximum age are purged from the topology database (garbage collection). Each router has to resend its LSA (the LSA that was originated from that router) before it ages out in the topology databases. LSAs with an age equal to the maximum age are used to immediately remove LSAs from the database (route poisoning). In general, the flooding process steps in a multiaccess network are as follows: Step 1

3-36

A router notices a change in a link state and multicasts an LSU packet (which includes the updated LSA entry) to all OSPF neighbors (on point-to-point links) at 224.0.0.5 or to all OSPF DRs and BDRs (on LAN links like the one in the figure in the slide) at 224.0.0.6. An LSU packet may contain several distinct LSAs.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Step 2

The DR acknowledges receipt of the change and floods the LSU to others on the network using the OSPF multicast address 224.0.0.5. After receiving the LSU, each router responds to the DR with an LSAck. To make the flooding procedure reliable, each LSA must be acknowledged separately.

Step 3

If a router is connected to other networks, it floods the LSU to those other networks by forwarding the LSU to the DR of the multiaccess network (or to the adjacent router if it is in a point-to-point network). The DR, in turn, multicasts the LSU to the other routers in the network.

Step 4

The router updates its LSDB using the LSU that includes the changed LSA. It then recomputes the shortest path first (SPF) algorithm against the updated database after a short delay (the SPF delay) and updates the routing table as necessary.

Note

Although it is not shown in this figure, all LSUs are acknowledged.

When is the SPF algorithm run? A change in the topology database is a necessary, but not sufficient condition for SPF recalculation. The SPF algorithm is triggered if: The LSA Options field has changed The age of the LSA instance is set to MaxAge The length field in the LSA header has changed The contents of the LSA (excluding the LSA header) have changed An SPF calculation is performed separately for each area in the topology database. OSPF simplifies the synchronization issue by requiring only adjacent routers to remain synchronized. Summaries of individual link-state entries, not the complete link-state entries, are sent every 30 minutes to ensure proper LSDB synchronization. Each link-state entry has a timer to determine when the LSA refresh update must be sent. Each link-state entry also has a maximum age of 60 minutes. If a link-state entry has not been refreshed within 60 minutes, it is removed from the LSDB. Note

© 2009 Cisco Systems, Inc.

On a Cisco router, if a route already exists, the routing table is used at the same time the SPF algorithm is calculating new best route to the destination. However, if the SPF is calculating a new route, the new route is used only after the SPF calculation is complete.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-37

Verifying Packet Flow This topic describes how to verify that OSPF packets are flowing properly between two routers.

The debug ip ospf packet Command Debugging a single packet ÎďýĽ»ľ«ą · ° ±­°ş °ż˝µ»¬ ŃÍĐÚ ° ż˝µ»¬ Ľ»ľ«ąą·˛ą ·­ ±˛ Îďý öÚ»ľ ď ę ďďćđíćëďňîđęć ŃÍĐÚć ®˝ Şň Şćî ¬ćď ´ćěč ®·Ľćďđňđňđňďî ż·Ľć đňđňđ ňď ˝¸µćÜčč î ż«¬ćđ ż «µć ş®±ł Í»®·ż´đńđńđňî

This debug output shows the fields in the OSPF header.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-12

The debug ip ospf packet command is used to verify that OSPF packets are flowing properly between two routers as well as for troubleshooting.

Example: debug ip ospf packet The output of this debug command is shown in the figure. Notice that the output shows the fields in the OSPF header, but they are not described in any detail. After each field there is a parameter for it. The values are described in the table below. From the table below and from the sample output we can say the following: ŃÍĐÚć ®˝Şň Şćî ¬ćď ´ćěč ®·Ľćďđňđňđňďî ż·Ľćđňđňđňď ˝¸µćÜččî ż«¬ćđ ż«µć ş®±ł Í»®·ż´đńđńđňî

3-38

OSPF:

- OSPF packet

rcv.

- was received

v:2

- OSPF version 2

t:1

- Hello packet

l:48

- 48 bytes is the OSPF packet length

rid:10.0.0.12

- The OSPF router ID is 10.0.0.12

aid:0.0.0.1

- The OSPF area ID is 0.0.0.1

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

chk:D882

- The OSPF checksum is D882

aut:0

- Authentication is not being used

auk:

- There is no key, as authentication is not being used

from Serial0/0/0.2

- The packet was received via interface Serial0/0/0.2

OSPF Packet Header Fields The table lists the OSPF packet header fields represented in this output. Field

Description

v

Provides the version of OSPF

t

Specifies the OSPF packet type: 1: hello 2: DBD 3: LSR 4: LSU 5: LSAck

l

Specifies the OSPF packet length in bytes

rid

Provides the OSPF router ID

aid

Shows the OSPF area ID

chk

Displays the OSPF checksum Provides the OSPF authentication type: 0: No authentication

aut 1: Simple password 2: MD5 auk

Specifies the OSPF authentication key, if used

keyid

Displays the MD5 key ID; only used for MD5 authentication

seq

Provides the sequence number; only used for MD5 authentication

For more details about the debug ip ospf packet command, please check the Cisco IOS Debug Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/debug/command/reference/db_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-39

Summary This topic summarizes the key points that were discussed in this lesson.

Summary There are five OSPF packet types: hello, DBD, LSU, LSR, and LSAck. The Hello protocol forms logical neighbor adjacency relationships. A DR may be required to coordinate adjacency formations. The exchange protocol passes through several states (down, INIT, two-way, exstart, exchange, and loading) before finally reaching the goal of the full state. When the protocol is in the full state, its databases are synchronized with adjacent routers. LSAs are sent when a change occurs, but are also sent every 30 minutes to ensure database integrity. The maximum time that an LSA will stay in the database, without an update, is 1 hour. Use the debug ip ospf packet command to verify that OSPF packets are flowing properly between two routers.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

3-40

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v1. 0— 3-13

© 2009 Cisco Systems, Inc.

Lesson 3

Improving Routing Performance in a Complex Enterprise Network Overview Open Shortest Path First Protocol (OSPF) areas may be made up of different types of network links. You must know which ones are being used in order to properly configure OSPF to work with all of them and their different adjacency behaviors as well as over certain network types. It is important to note that OSPF pays special attention to different network types, such as point-to-point and broadcast networks, and that the OSPF default settings do not always work properly with some network topologies. This lesson describes each OSPF network type, how the adjacencies are formed for these OSPF network types, and how link-state advertisements (LSAs) are flooded on each.

Objectives Upon completing this lesson, you will be able to describe the features of various OSPF network architectures. This ability includes being able to meet these objectives: Introduce OSPF network types Determine adjacency behavior in point-to-point links Determine adjacency behavior in a broadcast network Determine adjacency behavior in a Metro Ethernet and EoMPLS network Determine adjacency behavior in MPLS networks Select a DR and BDR Implement OSPF over different Frame Relay implementations Implement OSPF over Frame Relay NBMA Use subinterfaces in OSPF over Frame Relay

Implement OSPF over a point-to-point Frame Relay network Implement OSPF over a point-to-multipoint Frame Relay network

3-42

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Introducing OSPF Network Types This topic describes the three types of networks defined by OSPF.

OSPF Network Types Point-to-point: A network that joins a single pair of routers. Broadcast: A multiaccess broadcast network, such as Ethernet. Nonbroadcast multiaccess (NBMA): A network that interconnects more than two routers but that has no broadcast capability. – Examples: Frame Relay, ATM, and X.25 – Five modes of OSPF operation are available for NBMA networks

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-2

OSPF defines distinct types of networks, based on their physical link types. OSPF operation on each type is different, including how adjacencies are established and what configuration is required. There are three types of networks that are defined by OSPF: Point-to-point: A network that joins a single pair of routers. Broadcast: A multiaccess broadcast network, such as Ethernet. Nonbroadcast multiaccess (NBMA): A network that interconnects more than two routers but that has no broadcast capability. Frame Relay, ATM, and X.25 are examples of NBMA networks. There are five modes of OSPF operation available for NBMA networks, as described later in this lesson.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-43

Adjacency Behavior in Point-to-Point Links This topic describes the adjacency behavior for point-to-point serial links.

Point-to-Point Links Usually a serial interface running either PPP or HDLC May also be a point-to-point subinterface running Frame Relay or ATM Does not require DR or BDR election Is automatically detected by OSPF Sends OSPF packets using multicast 224.0.0.5

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-3

A point-to-point network joins a single pair of routers. A T1 serial line configured with a linklayer protocol such as PPP or High-Level Data Link Control (HDLC) is an example of a pointto-point network. On point-to-point networks, the router dynamically detects its neighboring routers by multicasting its hello packets to all OSPF routers, using the address 224.0.0.5. On point-topoint networks, neighboring routers become adjacent whenever they can communicate directly. No designated router (DR) or backup designated router (BDR) election is performed. This is because there can be only two routers on a point-to-point link, so there is no need for a DR or BDR. Usually, the IP source address of an OSPF packet is set to the address of the outgoing interface on the router. It is possible to use IP unnumbered interfaces with OSPF. On unnumbered interfaces, the IP source address is set to the IP address of another interface on the router. The default OSPF hello and dead intervals on point-to-point links are 10 seconds and 40 seconds, respectively.

3-44

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Adjacency Behavior in a Broadcast Network This topic describes the adjacency behavior for a broadcast network link.

Multiaccess Broadcast Network This generally applies to LAN technologies like Ethernet. DR and BDR selection are required. All neighbor routers form full adjacencies with the DR and BDR only. Packets to the DR and the BDR use 224.0.0.6. Packets from DR to all other routers use 224.0.0.5.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-4

An OSPF router on a multiaccess broadcast network such as Ethernet forms an adjacency with its DR and BDR. Adjacent routers have synchronized link-state databases (LSDBs). A common media segment is the basis for adjacency, such as an Ethernet segment connecting two routers. When routers first come up on the Ethernet, they perform the hello process and then elect the DR and BDR. The routers then attempt to form adjacencies with the DR and BDR. The routers on a segment must elect a DR and a BDR to represent the multiaccess broadcast network. The BDR does not perform any DR functions when the DR is operating. Instead, the BDR receives all the information, but the DR performs the LSA forwarding and LSDB synchronization tasks. The BDR performs the DR tasks only if the DR fails. If the DR fails, the BDR automatically becomes the DR and a new BDR election occurs. The DR and BDR improve network functioning in the following ways: Reducing routing update traffic: The DR and BDR act as central point of contact for link-state information exchange on a multiaccess broadcast network; therefore, each router must establish a full adjacency with the DR and the BDR only. Each router, rather than exchanging link-state information with every other router on the segment, sends the linkstate information to the DR and BDR only. The DR represents the multiaccess broadcast network in the sense that it sends link-state information from each router to all other routers in the network. This flooding process significantly reduces the router-related traffic on a segment.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-45

Managing link-state synchronization: The DR and BDR ensure that the other routers on the network have the same link-state information about the internetwork. In this way, the DR and BDR reduce the number of routing errors. Note

3-46

After a DR and BDR have been selected, any router added to the network establishes adjacencies with the DR and BDR only.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Adjacency Behavior in a Metro Ethernet and EoMPLS Network This topic describes the adjacency behavior in a Metro Ethernet and Ethernet over Multiprotocol Label Switching (EoMPLS) network link.

OSPF Adjacency Over Metro Ethernet and EoMPLS EoMPLS and Metro Ethernet service does not participate in STP, nor does it learn MAC addresses Customer routers R1 and R2 exchange Ethernet frames via an interface or VLAN subinterfaces OSPF behaves the same as on Ethernet – OSPF network type = Multiaccess Broadcast Network – DR and BDR are elected – Routers form full adjacencies with the DR and BDR only

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-5

The service provider’s MPLS backbone is used to enable Layer 2 Ethernet connectivity between the two customer routers R1 and R2, whether an EoMPLS or Metro Ethernet service is used. Routers R1 and R2 thus exchange Ethernet frames. Provider edge router (PE-router) PE1 takes the Ethernet frames received from router R1 on the link to PE1, encapsulates them into MPLS packets, and forwards them across the backbone to router PE2. Router PE2 de-encapsulates the MPLS packets and reproduces the Ethernet frames on the link towards router R2. EoMPLS and Metro Ethernet typically do not participate in Spanning Tree Protocol (STP) and bridge protocol data unit (BPDU) exchanges, so EoMPLS and Metro Ethernet are transparent to the customer routers. The Ethernet frames are transparently exchanged across the MPLS backbone. Keep in mind that customer routers can be connected either in a port-to-port fashion, in which PE-routers take whatever Ethernet frame is received and forward the frames across the Layer 2 MPLS VPN backbone, or in a VLAN subinterface fashion, in which frames for a particular VLAN, identified with subinterface in configuration, are encapsulated and sent across the Layer 2 MPLS VPN backbone. When deploying OSPF over EoMPLS, there are no changes to the existing OSPF configuration from the customer perspective. OSPF needs to be enabled and network commands must include the interfaces required by the relevant OSPF area in order to start the OSPF properly. © 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-47

Routers R1 and R2 form a neighbor relationship with each other over the Layer 2 MPLS VPN backbone. From an OSPF perspective, the Layer 2 MPLS VPN backbone, router PE1, and router PE2 are all invisible. A neighbor relationship is established between routers R1 and R2 directly, and behaves in the same way as on a regular Ethernet broadcast network.

3-48

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Adjacency Behavior in MPLS networks This topic describes the adjacency behavior in an MPLS network link.

OSPF Adjacency Over MPLS VPN Customer routers run OSPF and exchange routing updates with the PE routers – PE routers appear as another router in the customer’s network – Service provider’s P routers are hidden from the customer – Customer routers are unaware of MPLS VPN – Customer and service provider must agree on OSPF parameters Customer Routers to PE connection can be of any type – OSPF behaves per the connection type (point-to-point, broadcast, NBMA)

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-6

With the Layer 3 MPLS VPN architecture, the ISP provides a peer-to-peer VPN architecture. In this architecture, Provider Edge-routers (PE-routers) participate in customer routing, guaranteeing optimum routing between customer sites. Therefore, the PE-routers carry a separate set of routes for each customer, resulting in perfect isolation between the customers. The following apply to the Layer 3 MPLS VPN technology, even when running OSPF as a provider edge-customer edge (PE-CE) routing protocol: The customer routers should not be aware of MPLS VPN; they should run standard IP routing software. The provider routers (P-routers) must not carry VPN routes for the MPLS VPN solution to be scalable. The provider edge routers (PE-routers) must support MPLS VPN services and traditional Internet services. To OSPF, the Layer 3 MPLS VPN backbone looks like a standard corporate backbone and it run standard IP routing software. Routing updates are exchanged between the Customer-routers (C-routers) and the PE routers that appear as normal routers in the customer’s network. OSPF is enabled on proper interfaces using the network command. The standard design rules that are used for enterprise Layer 3 MPLS VPN backbones can be applied to the design of the customer’s network. The P routers are hidden from the customer’s view and Customer Edgerouters (CE routers) are unaware of MPLS VPN. The internal topology of the Layer 3 MPLS backbone is therefore totally transparent to the customer. The PE routers receive IPv4 routing updates from the CE routers and install them in the appropriate VRF table. This part of the configuration and operation is the responsibility of a service provider.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-49

The CE-PE can have any OSPF network type—point-to-point, broadcast, or even nonbroadcast multiaccess. The only difference between a CE-PE design and a regular OSPF design is that the customer has to agree with the service provider about the OSPF parameters (AS number, authentication password, and so on), where usually these parameters are governed by the service provider.

3-50

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Selecting a DR and BDR This topic describes how OSPF routers apply conditions to the OSPF priority values of other routers during the hello packet exchange process to elect a DR and BDR.

Electing the DR and BDR Hello packets are exchanged via IP multicast DR: The router with the highest OSPF priority BDR: The router with the second-highest priority value The OSPF router ID is used as the tiebreaker The DR election is nonpreemptive

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-7

To elect a DR and BDR, the routers view the OSPF priority value of other routers during the hello packet exchange process and then use the following conditions to determine which router to select: The router with the highest priority value is the DR. The router with the second-highest priority value is the BDR. The default for the interface OSPF priority is 1. In the case of a tie, the router ID is used. The router with the highest router ID becomes the DR. The router with the second-highest router ID becomes the BDR. A router with a priority set to zero cannot become the DR or BDR. A router that is not the DR or BDR is called a DROTHER. If a router with a higher priority value is added to the network, it does not preempt the DR and BDR. The only time a DR or BDR changes is when one of them is out of service. If the DR is out of service, the BDR becomes the DR and a new BDR is selected. If the BDR is out of service, a new BDR is elected. To determine whether the DR is out of service, the BDR uses the wait timer. This timer is a reliability feature. If the BDR does not confirm that the DR is forwarding LSAs before the timer expires, then the BDR assumes that the DR is out of service. Note

© 2009 Cisco Systems, Inc.

The highest IP address on an active interface is normally used as the router ID; however, you can override this selection by configuring an IP address on a loopback interface or using the router-id router configuration command.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-51

In a multiaccess broadcast environment, each network segment has its own DR and BDR. A router connected to multiple multiaccess broadcast networks can be a DR on one segment and a regular router on another segment. Note

3-52

The DR operation is at the link level; a DR is selected for every multiaccess broadcast link in the OSPF network.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Setting the Priority for DR Election ÜÎř˝±˛ş·ąó·ş÷ý ·° ±­°ş °®·±®·¬§ í

This interface configuration command assigns the OSPF priority to an interface. Different interfaces on a router may be assigned different values. The default priority is 1. The range is from 0 to 255. “0” means the router cannot be the DR or BDR. A router that is not the DR or BDR is DROTHER.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-8

Use the ip ospf priority command to designate which router interfaces on a multiaccess link are the DR and the BDR. The default priority is 1, and the range is from 0 to 255. The interface with the highest priority becomes the DR, and the interface with the second-highest priority becomes the BDR. Interfaces that are set to a priority of 0 cannot be involved in the DR or BDR election process. Note

The priority of an interface takes effect only when the existing DR goes down. A DR does not relinquish its status just because a new interface reports a higher priority in its hello packet.

For more details about the ip ospf priority command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-53

OSPF over Different Frame Relay Implementations This topic describes the adjacency behavior for a Frame Relay NBMA network.

NBMA Topology A single interface interconnects multiple sites NBMA topologies support multiple routers, but without broadcasting capabilities Five modes of OSPF operation are available

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-9

When a single interface interconnects multiple sites over an NBMA network, the nonbroadcast nature of the network can lead to reachability issues. NBMA networks can support more than two routers but have no broadcast capability. For example, if the NBMA topology is not fully meshed, then a broadcast or multicast sent by one router will not reach all the other routers. Frame Relay, ATM, and X.25 are examples of NBMA networks. To implement broadcasting or multicasting in an NBMA network, the router replicates the packets to be broadcast or multicast and sends them individually on each permanent virtual circuit (PVC) to all destinations. This process is CPU- and bandwidth-intensive. The default OSPF hello and dead intervals on NBMA interfaces are 30 seconds and 120 seconds, respectively.

3-54

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

DR Election in NBMA Topology OSPF considers NBMA to be like other broadcast media. The DR and BDR need to have fully meshed connectivity with all other routers, but NBMA networks are not always fully meshed. – The DR and BDR each need a list of neighbors. OSPF neighbors are not automatically discovered by the router.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-10

OSPF treats NBMA environments like any other broadcast media environments, such as Ethernet; however, NBMA clouds are usually built in hub-and-spoke topologies, using PVCs or switched virtual circuits (SVCs). A hub-and-spoke topology means that the NBMA network is only a partial mesh. In these cases, the physical topology does not provide multiaccess capability, on which OSPF relies. The election of the DR becomes an issue in NBMA topologies, because the DR and BDR need to have full physical connectivity with all routers in the NBMA network. The DR and BDR also need to have a list of all the other routers, so that they can establish adjacencies. OSPF cannot automatically build adjacencies with neighboring routers over NBMA interfaces.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-55

Frame Relay Topologies

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-11

There are several OSPF configuration choices for a Frame Relay network, depending on the Frame Relay network topology. With Frame Relay, remote sites interconnect in a variety of ways. By default, interfaces that support Frame Relay are multipoint connection types. The following examples are types of Frame Relay topologies: Star topology: A star topology, also known as a hub-and-spoke configuration, is the most common Frame Relay network topology. In this topology, remote sites connect to a central site that generally provides a service or application. The star topology is the least expensive topology, because it requires the smallest number of PVCs. The central router provides a multipoint connection, because it typically uses a single interface to interconnect multiple PVCs. Full-mesh topology: In a full-mesh topology, all routers have virtual circuits to all other destinations. This method, although costly, provides direct connections from each site to all other sites and allows for redundancy. As the number of nodes in the full-mesh topology increases, the topology becomes increasingly expensive. To figure out how many virtual circuits are needed to implement a fully meshed topology, use the formula (n * (n – 1)) / 2, where n is the number of nodes in the network. Partial-mesh topology: In a partial-mesh topology, not all sites have direct access to a central site. This method reduces the cost of implementing a full-mesh topology.

3-56

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

OSPF over NBMA Topology Modes of Operation There are five modes of OSPF operation. RFC 2328-compliant modes are as follows: – Nonbroadcast (NBMA) – Point-to-multipoint Additional modes from Cisco are as follows: – Point-to-multipoint nonbroadcast – Broadcast – Point-to-point

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-12

As described in RFC 2328, OSPF runs in one of the following two official modes in NBMA topologies: Nonbroadcast: The nonbroadcast (NBMA) mode simulates the operation of OSPF in broadcast networks. Neighbors must be manually configured, and DR and BDR election is required. This configuration is typically used with fully meshed networks. Point-to-multipoint: The point-to-multipoint mode treats the nonbroadcast network as a collection of point-to-point links. In this environment, the routers automatically identify their neighboring routers but do not elect a DR and BDR. This configuration is typically used with partially meshed networks. The choice between NBMA and point-to-multipoint modes determines the way the Hello protocol and flooding work over the nonbroadcast network. The main advantage of the pointto-multipoint mode is that it requires less manual configuration, and the main advantage of the nonbroadcast mode is that there is less overhead traffic. Cisco has defined the following additional modes: Point-to-multipoint nonbroadcast Broadcast Point-to-point

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-57

The description of all the modes is as follows: OSPF network type over NBMA topology

ľ®±żĽ˝ż­¬

Description

Cisco extension. Makes the WAN interface appear to be a LAN Has one IP subnet Uses multicast OSPF hello packets to automatically discover the neighbors Elects the DR and BDR. Requires a full-mesh or a partial-mesh topology

˛±˛óľ®±żĽ˝ż­¬

RFC-compliant mode. Has one IP subnet Requires neighbors to be manually configured Elects the DR and BDR Requires that the DR and BDR have full connectivity with all other routers Is typically used in a full-mesh or a partial-mesh topology

°±·˛¬ó¬±ół«´¬·°±·˛¬

RFC-compliant mode. Has one IP subnet Uses multicast OSPF hello packets to automatically discover the neighbors Does not require DR and BDR—router sends additional LSAs with more information about neighboring routers Is typically used in partial-mesh or star topology

°±·˛¬ó¬±ół«´¬·°±·˛¬ ˛±˛óľ®±żĽ˝ż­¬

Cisco extension.

°±·˛¬ó¬±ó°±·˛¬

Cisco extension.

Is used in place of RFC-compliant point-to-multipoint mode if multicast and broadcast are not enabled on the virtual circuits, because the router cannot dynamically discover its neighboring routers using hello multicast packets Requires neighbors to be manually configured Does not require DR and BDR election

Has a different IP subnet on each subinterface Does not have DR or BDR election Is used when only two routers need to form an adjacency on a pair of interfaces Can be used with either LAN or WAN Interfaces

Broadcast mode is a workaround for statically listing all existing neighboring routers. The interface is set to broadcast and behaves as though the router connects to a LAN. DR and BDR election is still performed; therefore, take special care to ensure either a full-mesh topology or a static election of the DR based on the interface priority. The other modes are examined in the following topics.

3-58

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

OSPF over Frame Relay NBMA This topic describes how to configure an NBMA topology in an OSPF over Frame Relay network.

Nonbroadcast Mode (NBMA Mode) Treated as a broadcast network by OSPF (like a LAN) All serial ports are part of the same IP subnet Frame Relay, X.25, and ATM networks default to nonbroadcast mode Duplicates LSA updates

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-13

In nonbroadcast mode, OSPF emulates operation over a broadcast network. A DR and BDR are elected for the NBMA network, and the DR originates an LSA for the network. In this environment, the routers are usually fully meshed to facilitate the establishment of adjacencies among the routers. If the routers are not fully meshed, then you should select the DR and BDR manually to ensure that the selected DR and BDR have full connectivity to all other neighboring routers. Neighboring routers are statically defined to start the DR and BDR election process. When using nonbroadcast mode, all routers are on one IP subnet. For flooding over a nonbroadcast interface, the link-state update (LSU) packet must be replicated for each PVC. The updates are sent to each of the neighboring routers defined in the neighbor table on the interface. When there are few neighbors in the network, nonbroadcast mode is the most efficient way to run OSPF over NBMA networks, because it has less overhead than point-to-multipoint mode. Frame Relay networks default to OSPF nonbroadcast mode.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-59

Steps to Configure NBMA Mode Enable the OSPF routing process Define the interfaces that OSPF will run on

NBMA-specific configuration: Statically define a neighbor relationship Define the OSPF network type

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-14

At the beginning, one or more OSPF routing processes must be enabled on the router, followed by configuration that defines which interfaces are involved in OSPF routing. Details will be described in the following lessons. Once all the required information is defined and basic OSPF configuration is applied, an implementation plan showing the following tasks is required to configure the NBMA-specific configuration: Manual configuration of the neighbors Definition of the OSPF network type

3-60

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Nonbroadcast Mode Operation Neighbors must be statically configured The OSPF network type must be defined Îďř˝±˛ş·ąó®±«¬»®÷ý ˛»·ą¸ľ±® ďçîňďęčňďňî °®·±®·¬§ đ

Use this command to statically define neighbor relationships in an NBMA network. Îďř˝±˛ş·ąó·ş÷ý ·° ±­°ş ˛»¬©±®µ ˛±˛óľ®±żĽ˝ż­¬

This command defines the OSPF non-broadcast network type.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-15

To configure Open Shortest Path First (OSPF) routers interconnecting to nonbroadcast networks, use the neighbor (OSPF) command in router configuration mode. Adjacent relationships must be statically defined in NBMA networks using the nonbroadcast mode. One neighbor entry must be included in the Cisco IOS Software configuration for each known nonbroadcast network neighbor and the neighbor address must be on the primary address of the interface. Note

You cannot use the neighbor (OSPF) command to specify an OSPF neighbor on nonbroadcast networks within an OSPF Virtual Private Network (VPN) routing instance.

The neighbor 192.168.1.2 priority 0 command in the figure in this slide shows the configuration where the priority 0 optional keyword is used. A number indicates the router priority value of the nonbroadcast neighbor associated with the IP address specified. The default value is 0. If this value is used, then the specified neighbor cannot become DR or BDR. Additionally, an OSPF network type must be defined. To configure the OSPF network type to a type other than the default for a given medium, use the ip ospf network command in the interface configuration mode. The ip ospf network non-broadcast command in the figure shows that network type selected is NBMA. For more details about the neighbor (OSPF) and ip ospf network commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-61

NBMA Configuration Example

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-16

Example: NBMA Configuration Example This figure illustrates an example of statically defined adjacencies and the configuration of a nonbroadcast OSPF network type. All three routers are using the default nonbroadcast mode on their Frame Relay interfaces; therefore, each must manually configure its neighboring routers. The priority should be set to 0 for routers R2 and R3, because a full-mesh topology does not exist. This configuration ensures that router R1 becomes the DR because only router R1 has full connectivity to the other two routers. No BDR will be elected in this case. Note

The default priority on the neighbor command is 0. Setting the OSPF priority to 0 at the interface level on routers R2 and R3 did result in a priority of 0 and the routers not being elected as DR or BDR.

In an NBMA network, neighbor statements are required only on the DR and BDR. In a huband-spoke topology, neighbor statements must be used on the hub, which must be configured to become the DR. Neighbor statements are not mandatory on the spoke routers. In a full-mesh NBMA topology, you may need neighbor statements on all routers unless you have statically configured the DR and BDR using the priority command.

3-62

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

The show ip ospf neighbor Command

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-17

To display OSPF neighbor information on a per-interface basis, you must use the show ip ospf neighbor command. This table describes the output of the show ip ospf neighbor command: Field

Description

Ň»·ą¸ľ±® ×Ü

Neighbor router ID

Đ®·±®·¬§

Router priority of the neighbor

ͬż¬»

Neighbor state

Ü»żĽ Ě·ł»

Expected time before Cisco IOS software will declare the neighbor dead

߼Ľ®»­­

IP address of the interface

ײ¬»®şż˝»

Local interface to reach the neighbor

Example: show ip ospf neighbor Command Router R1 in the figure has a serial Frame Relay NBMA interface and a Fast Ethernet interface. The serial 0/0/0 interface on this router has two neighbors; both show a state of FULL/DROTHER. DROTHER means that the neighboring router is not a DR or BDR (because router R1 is the DR and there is no BDR in this network). The neighbor learned on FastEthernet 0/0 shows a state of FULL/BDR, which means that it has successfully exchanged LSDB information with the router issuing the show command, and that it is the BDR. For more details about show ip ospf neighbor command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-63

Using Sub-Interfaces in OSPF over Frame Relay This topic describes how to configure a physical interface into multiple subinterfaces.

Using Subinterfaces Several logical subinterfaces can be created over all multiaccess WAN networks: – point-to-point – multipoint Each subinterface requires an IP subnet. Logical interfaces behave in exactly the same way as physical interfaces for routing purposes Statistics and traffic shaping behavior differs between interfaces and subinterfaces

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-18

A physical interface can be split into multiple logical interfaces, called subinterfaces. Each subinterface is defined as a point-to-point or a point-to-multipoint interface. Subinterfaces were originally created to better handle issues caused by split horizon over an NBMA for distancevector-based routing protocols. Each subinterface requires an IP subnet. Logical interfaces behave in exactly the same way as physical interfaces for routing purposes. Statistics and traffic shaping behavior differs between interfaces and subinterfaces. During the configuration of subinterfaces, you must choose the point-to-point or multipoint keywords. The choice of modes affects the operation of OSPF. The default OSPF mode on a point-to-point Frame Relay subinterface is the point-to-point mode; the default OSPF mode on a Frame Relay point-to-multipoint subinterface is the nonbroadcast mode. The default OSPF mode on a main Frame Relay interface is also the nonbroadcast mode. The following topics will describe point-to-point and multipoint subinterfaces and their use in the OSPF NBMA mode.

3-64

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Point-to-Point Subinterfaces Each PVC gets its own subinterface. PVCs are treated like point-to-point links. Each subinterface requires a subnet. OSPF point-to-point mode is the default. – DR and BDR are not used. – You do not need to configure neighbors. Îďř˝±˛ş·ą÷ý ·˛¬»®şż˝» ­»®·ż´ đńđńđňď °±·˛¬ó¬±ó°±·˛¬

This shows how to configure a point-to-point subinterface.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-19

When point-to-point subinterfaces are configured, each permanent virtual circuit (PVC) gets its own subinterface, and PVCs are treated like point-to-point links. A point-to-point subinterface has the properties of any physical point-to-point interface and requires its own subnet. There is no DR or BDR election process. Neighbor discovery is automatic, so neighbors do not need to be configured. To configure the point-to-point interface, you must select the point-to-point keyword during subinterface configuration, as shown on the figure in this slide.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-65

Point-to-Point Subinterface Example

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-20

Example: Point-to-Point Subinterface Point-to-point mode is used when only two nodes exist; this mode is typically used only with point-to-point subinterfaces. Each point-to-point connection is one IP subnet. An adjacency forms over the point-to-point network with no DR or BDR election. In the figure, the router R1 serial 0/0/0 interface is configured with point-to-point subinterfaces. Although all three routers have only one physical serial port, router R1 appears to have two logical ports. Each logical port (subinterface) has its own IP address and operates as a point-topoint OSPF network type. This type of configuration avoids the need for a DR or BDR and removes the requirement to define the neighbors statically.

3-66

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Multipoint Subinterfaces Multiple PVCs are on a single subinterface. Each subinterface requires a subnet. OSPF nonbroadcast mode is the default. – The DR is used. – Neighbors need to be statically configured. Îďř˝±˛ş·ą÷ý ·˛¬»®şż˝» ­»®·ż´ đńđńđňď ł«´¬·°±·˛¬

This shows how to configure a multipoint subinterface.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-21

When multipoint subinterfaces are configured, there are multiple permanent virtual circuits (PVCs) on a single subinterface. Each subinterface requires a subnet. Multipoint Frame Relay subinterfaces default to OSPF nonbroadcast mode, which requires neighbors to be statically configured and performs a DR and BDR election. To configure the multipoint interface, you must select the multipoint keyword during subinterface configuration, as shown in the figure in this slide.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-67

Multipoint Subinterface Example

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-22

Example: Multipoint Subinterface In this figure, router R1 has one single interface, serial 0/0/0, which has been logically separated into two subinterfaces: one point-to-point (S0/0/0.1) and one point-to-multipoint (S0/0/0.2). The multipoint subinterface supports two other routers in a single subnet. Each subinterface requires a subnet. On a multipoint interface, neighbors are statically defined. OSPF defaults to point-to-point mode on the point-to-point subinterface. OSPF defaults to nonbroadcast mode on the point-to-multipoint interface.

3-68

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Implementing OSPF over a Point-to-Point Frame Relay Network This topic describes how to configure a point-to-point topology in an OSPF over Frame Relay network.

Point-to-Point Mode Leased-line emulation Automatic configuration of adjacency DR is not used Only a single subnet is used

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-23

Networks in point-to-point mode are designed to emulate leased-line networks. This is a Cisco proprietary mode. Because they are treated as point-to-point links, the DR and BDR are not used, and the adjacency forms over the point-to-point network with no DR or BDR election. Only a single subnet is used per point-to-point link.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-69

Point-to-Point Configuration Example

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-24

Example: Point-to-Point Configuration This figure shows partial configuration of routers R1 and R2 in point-to-point mode. This configuration does not require subinterfaces and uses only a single subnet. In point-to-point mode, a DR or BDR is not used; therefore, DR and BDR election and priorities are not a concern. For more details about the ip ospf network command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

3-70

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Point-to-Point Verification Example

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-25

The show ip ospf interface command displays key OSPF details for each interface. The OSPF network type, area number, cost, and state of the interface are all displayed. The hello interval for a point-to-multipoint interface is 30 seconds, with a dead interval of 120 seconds. The point-to-point and broadcast modes default to a 10-second hello timer. The hello and dead timers on the neighboring interfaces must match in order for the neighbors to form successful adjacencies. The listed adjacent neighboring routers are all dynamically learned. Manual configuration of neighboring routers is not necessary. For more details about the show ip ospf interface commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-71

Implementing OSPF over a Point-to-Multipoint Frame Relay Network This topic describes how to configure a point-to-multipoint topology and point-to-multipoint nonbroadcast topologies in an OSPF over Frame Relay network.

Point-to-Multipoint Mode Fixes partial-mesh and star topologies Automatic configuration of adjacency DR is not used Only a single subnet is used

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-26

Networks in point-to-multipoint mode are designed to work with partial-mesh or star topologies. With RFC 2328-compliant point-to-multipoint mode, OSPF treats all router-torouter connections over the nonbroadcast network as if they were point-to-point links. In pointto-multipoint mode, DRs are not used, and a type 2 LSA (as described in the next lesson) is not flooded to adjacent routers. Instead, OSPF point-to-multipoint works by exchanging additional LSUs that are designed to automatically discover neighboring routers and add them to the neighbor table. In large networks, using point-to-multipoint mode reduces the number of PVCs required for complete connectivity, because you are not required to have a full-mesh topology. In addition, not having a full-mesh topology reduces the number of neighbor entries in the neighbor table. Point-to-multipoint mode has the following properties: Does not require a fully meshed network: This environment allows routing to occur between two routers that are not directly connected but are connected through a router that has virtual circuits to each of the two routers. All three routers connected to the Frame Relay network in the figure can be configured for point-to-multipoint mode. Does not require a static neighbor configuration: In nonbroadcast mode, neighboring routers are statically defined to start the DR election process and allow the exchange of routing updates. Because the point-to-multipoint mode treats the network as a collection of point-to-point links, multicast hello packets discover neighboring routers dynamically. Statically configuring neighboring routers is not necessary.

3-72

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Uses one IP subnet: As in nonbroadcast mode, when you are using point-to-multipoint mode, all routers are on one IP subnet. Duplicates LSA packets: Also as in nonbroadcast mode, when flooding out a nonbroadcast interface in point-to-multipoint mode, the router must replicate the LSU. The LSU packet is sent to each of the neighboring routers of the interface, as defined in the neighbor table.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-73

Point-to-Multipoint Configuration Example

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-27

Example: Point-to-Multipoint Configuration This figure shows partial configurations of routers R1 and R2 in point-to-multipoint mode. This configuration does not require subinterfaces and uses only a single subnet. In point-to-multipoint mode, a DR or BDR is not used; therefore, DR and BDR election and priorities are not a concern.

3-74

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Point-to-Multipoint Verification Example

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-28

The show ip ospf interface command displays key OSPF details for each interface. The OSPF network type, area number, cost, and state of the interface are all displayed. The hello interval for a point-to-multipoint interface is 30 seconds, with a dead interval of 120 seconds. The point-to-multipoint and the nonbroadcast modes default to a 30-second hello timer, while the point-to-point and broadcast modes default to a 10-second hello timer. The hello and dead timers on the neighboring interfaces must match in order for the neighbors to form successful adjacencies. The listed adjacent neighboring routers are all dynamically learned. Manual configuration of neighboring routers is not necessary. For more details about the show ip ospf interface command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-75

Point-to-Multipoint Nonbroadcast Cisco extension to the RFC-compliant point-to-multipoint mode Must manually define neighbors—as with NBMA mode DR, BDR not used—as with point-to-multipoint mode Used in special cases where neighbors cannot be automatically discovered – Example: Virtual circuits without multicast and broadcast enabled Îďř˝±˛ş·ąó·ş÷ý ·° ±­°ş ˛»¬©±®µ °±· ˛¬ó¬±ół«´¬·°±·˛¬ ˛±˛óľ®±żĽ˝ż­¬

Defines the OSPF network type

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-29

Cisco defines additional modes for the OSPF neighbor relationship, including point-tomultipoint nonbroadcast. This mode is a Cisco extension of the RFC-compliant point-tomultipoint mode. You must statically define neighbors, and you can modify the cost of the link to the neighboring router to reflect the different bandwidths of each link. The RFC point-tomultipoint mode was developed to support underlying point-to-multipoint virtual circuits that support multicast and broadcast; therefore, this mode allows dynamic neighboring router discovery. For this reason, no DR or BDR is used. This mode is used in special cases where neighbors cannot be automatically discovered. If, for example, multicast and broadcast are not enabled on the virtual circuits, the RFC-compliant point-to-multipoint mode cannot be used, because the router cannot dynamically discover its neighboring routers using the hello multicast packets; this Cisco mode should be used instead. To define point-to-multipoint nonbroadcast mode, you must use the ip ospf network point-tomultipoint non-broadcast command in an interface configuration mode, as shown on the figure in this slide.

3-76

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

OSPF over NBMA Topology Summary OSPF Mode

NBMA Preferred Topology

Subnet Address

Hello Timer

Adjacency

RFC or Cisco

Broadcast

Full- or partialmesh

Same

10 s ec

Automatic, DR/BDR elected

Cisco

Nonbroadcast (NBMA)

Full- or partialmesh

Same

30 s ec

Manual configuration, DR/BDR elected

RFC

Point-tomultipoint

Partial-mesh or star

Same

30 s ec

Automatic, no DR/BDR

RFC

Point-tomultipoint nonbroadcast

Partial-mesh or star

Same

30 s ec

Manual configuration, no DR or BDR

Cisco

Point-to-point

Partial-mesh or star, using subinterface

Different for each subinterface

10 s ec

Automatic, no DR or BDR

Cisco

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-30

Example: OSPF over NBMA Topology Summary The figure provides a concise comparison of the various modes of operation for OSPF over NBMA topologies.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-77

Summary This topic summarizes the key points that were discussed in this lesson.

Summary OSPF defines three types of networks: point-to-point, broadcast, and NBMA. On point-to-point links, the adjacency is dynamic, uses multicast addresses, and has no DR or BDR. On broadcast links, the adjacency is dynamic and includes election of a DR and BDR. All updates are sent to the DR, which forwards the updates to all routers. OSPF over Metro Ethernet and EoMPLS requires no changes to the OSPF configuration from the customer perspective. OSPF over MPLS VPN requires the customer routers to run OSPF and exchange routing updates with the PE routers. The router with the highest OSPF priority is selected as the DR. The router with the second-highest priority value is selected as the BDR. © 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-31

Summary (Cont.) The OSPF mode of operation on Frame Relay depends on the underlying Frame Relay network. OSPF mode options include nonbroadcast, broadcast, point-to-multipoint, point-to-multipoint nonbroadcast, and point-to-point. By default on NBMA links, adjacency requires the manual definition of neighbors for the DR and BDR, because OSPF will consider the network similar to broadcast media. A physical interface can be split into multiple logical interfaces called subinterfaces. Each subinterface requires an IP subnet. With point-to-point mode, leased line is emulated, the adjacency is automatically configured, and no DR is required. In point-to-multipoint mode, no DR or BDR is needed and neighbors are automatically discovered. In point-to-multipoint nonbroadcast mode, no DR or BDR is needed, but neighbors must be statically configured. © 2009 Cis co S yst em s, Inc. A ll rights reserved.

3-78

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v1. 0— 3-32

© 2009 Cisco Systems, Inc.

Lesson 4

Configuring and Verifying OSPF Routing Overview This lesson discusses the primary configuration commands for a single-area and multiarea Open Shortest Path First protocol (OSPF) design and how to configure the router OSPF and network commands. The network command for OSPF requires a special inverse mask that is defined in this lesson. For verification, several OSPF show commands are described in this lesson, introducing the OSPF verification process together with a description of the link state database (LSDB) and details about link state advertisements (LSAs). OSPF has some design limitations and solutions such as virtual links, passive interface command, and changing the cost metric are described.

Objectives Upon completing this lesson, you will be able to explain how to configure OSPF single-area and multiarea routing, and also explain how to configure several advanced features. This ability includes being able to meet these objectives: Initialize single-area and multiarea OSPF Activate OSPF within a router in single-area and multiarea Define the router ID Verify OSPF operations Identify LSA types within the LSDB Limit adjacencies in OSPF with the passive-interface command Define the design limitations of OSPF Define OSPF virtual links and solve the non-contiguous area problem Change the cost metric

Initializing Single-Area and Multiarea OSPF This topic describes the procedure to configure single-area and multiarea OSPF and the differences between the two.

Initializing Single-Area and Multiarea OSPF

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-2

Single area design in OSPF put all routers into a single OSPF area. This results in many updates being processed on every router and in larger routing tables. The OSPF configuration follows a single area design, in which all of the routers are treated as being internal routers to the area and all of the interfaces are members of that single area. The best design should use a single area as the backbone area. Multiarea design is a better solution than single-area design. In a multiarea design, the network is segmented to limit the propagation of LSAs and to make routing tables smaller. There are two types of routers, from the configuration point of view: Routers with single-area configuration: internal routers, backbone routers, autonomous system border routers residing in one area Routers with a multiarea configuration: area border routers and autonomous system border routers residing in more than one area

3-80

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Planning for OSPF Assess the requirements and options: – Contiguous IP addressing plan – Network topology with multiple areas Define different area types, ABRs, and ASBRs Define summarization and redistribution points Create an implementation plan Configure the OSPF

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-3

The type of OSPF routing protocol implementation you should choose depends on your specific needs and topology. When you prepare to deploy OSPF routing in a network, you must first gather the existing state and requirements, and then consider different deployment options: The IP addressing plan governs how OSPF can be deployed and how well the OSPF deployment might scale. Thus, a detailed IP addressing plan, along with the IP subnetting information, must be created. A solid IP addressing plan should enable usage of OSPF area design and summarization, to more easily scale the network, as well as optimize OSPF behavior and propagation of Link State Advertisements (LSAs). The network topology consists of links that connect the network equipment (routers, switches, and so on) and belong to different OSPF areas in a multiarea OSPF design. A detailed network topology plan should be presented in order to assess the OSPF scalability requirements and to determine the different OSPF areas, area border routers (ABRs), and autonomous system border routers (ASBRs), as well as summarization and redistribution points. An implementation plan must be created prior to the configuration of OSPF routing in the network.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-81

Activating OSPF within a Router in Single-Area and Multiarea This topic describes the two-step process to configure basic single-area and multiarea OSPF.

Steps to Configure Basic OSPF Configure OSPF routing processes on every OSPF router – Define one or more processes globally on the router – Define the interfaces that OSPF will run on

Or Enable OSPF explicitly on an interface

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-4

Once you have gathered all of the required information, you must create an implementation plan showing the following tasks to perform basic OSPF configuration: Define one or more OSPF processes globally on the router. Define the interfaces that OSPF will run on. The basic OSPF configuration can be applied directly on the router interface as well. In this case, there is just one step, which enables OSPF on an interface and assigns the interface to the desired OSPF area: Enable OSPF explicitly on an interface

3-82

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Configuring OSPF for Multiple Areas

Îďý

Îîý

䱫¬°«¬ ±ł·¬¬»Ľâ ·˛¬»®şż˝» Úż­¬ ۬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďđňęěňđňď îëëňîëëňîëëňđ

䱫¬°«¬ ±ł·¬¬»Ľâ ·˛¬»®şż˝» Úż­¬ ۬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďđňęěňđňî îëëňîëëňîëëňđ

䱫¬°«¬ ±ł·¬¬»Ľâ ®±«¬»® ±­°ş ď ˛»¬©±®µ ďđňđňđňđ

·˛¬»®şż˝» Í»®·ż´ đńđńď ·° żĽĽ®»­­ ďđňîňďňî îëëňîëëňîëëňđ ·° ±­°ş ëđ ż®»ż ď

đňîëëňîëëňîëë ż®»ż đ

䱫¬°«¬ ±ł·¬¬»Ľâ ®±«¬»® ±­°ş ë𠲻¬©±®µ ďđňęěňđňî

đňđňđňđ ż®»ż đ

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-5

To configure the OSPF process, complete the following steps: Enable the OSPF process on the router Identify which interfaces on the router are part of the OSPF process To configure an OSPF routing process, use the router ospf command in global configuration mode, as shown in the figure in the slide. The process-id parameter inside the router ospf command is an internally used identification parameter for the OSPF routing process. It is locally assigned and can be any positive integer. A unique value is assigned for each OSPF routing process in the router. To define the interfaces on which OSPF runs and define the area IDs for those interfaces, use the network area command in router configuration mode, as shown in the figure in the slide. The wildcard-mask parameter in the network area command determines how to interpret the IP address. The mask has wildcard bits, in which 0 is a match and 1 indicates that the value is not significant. For example, 0.0.255.255 indicates a match in the first two octets. Starting with Cisco IOS Release 12.3(11)T (and some specific versions of earlier releases), OSPF can be enabled directly on the interface using the ip ospf area command, which simplifies the configuration of unnumbered interfaces. Because the command is configured explicitly for the interface, it takes precedence over the network area command. The command is shown in the figure in the slide as well. The figure shows the OSPF configuration for Fast Ethernet broadcast networks and serial pointto-point links. Router R1 is in area 0, router R3 is in area 1, and router R2 is the area border router (ABR) between the two areas. Router R1 is configured for OSPF with a process-id value of 1, and a network statement assigns all interfaces defined in the 10.0.0.0 network to OSPF process 1. Router R2 is running OSPF process 50 and has a network statement for area 0. The configuration for area 1 in the example in the slide uses the ip ospf 50 area 1 interface command for serial point-to-point; alternatively, a separate network router configuration command could have been used. © 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-83

Note

The network statement and wildcard mask are not used for route summarization purposes. The network statement is used strictly to turn OSPF on for an interface or for multiple interfaces.

For more details about the router ospf, network area, and ip ospf area commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

3-84

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Defining the Router ID For an OSPF routing process to start successfully, it must be able to determine an OSPF router ID. This topic describes how to select the OSPF router ID using the router-id command.

OSPF Router ID The router is known to OSPF by the router ID number. This router ID is used in LSDBs to differentiate one router from the next. OSPF requires at least one active interface with an IP address. By default, the router ID is: – The highest IP address on an active interface at the moment of OSPF process startup. – If a loopback interface exists, the router ID is the highest IP address on any active loopback interface. A loopback interface overrides the OSPF router ID. The OSPF router-id command can be used to override the default OSPF router ID selection process. Using a loopback interface or a router-id command is recommended for stability. © 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-6

The OSPF database uses the OSPF router ID to describe each router in the network uniquely. Remember that every router keeps a complete topology database of all routers and links in an area (or network); therefore, each router should have a unique router ID. The OSPF routing process chooses a router ID for itself when it starts up. The router ID is a unique IP address that can be assigned in the following ways: By default, the highest IP address of any active physical interface when OSPF starts is chosen as the router ID. The interface does not have to be part of the OSPF process, but it has to be up. There must be at least one IP interface that is up on the router for OSPF to use as a router ID. If no interface is up and available with an IP address when the OSPF process starts, the following error message occurs: Îďř˝±˛ş·ą÷ý®±«¬»® ±­°ş ď î©ďĽć űŃÍĐÚóěóŇŃÎĚÎ×Üć ŃÍĐÚ °®±˝»­­ ď ˝ż˛˛±¬ ­¬ż®¬ň

If there is a loopback interface, its address will always be preferred as the router ID over of a physical interface address, because a loopback interface never goes down. If there is more than one loopback interface, then the highest IP address on any active loopback interface becomes the router ID. Using the router-id command is the preferred procedure to set the router ID and is always used in preference to the other two procedures. Once the OSPF router ID is set, it does not change, even if the interface that the router is using for the router ID goes down. The OSPF router ID changes only if the router reloads or if the OSPF routing process restarts. © 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-85

Configuration of Loopback Interfaces Îďř˝±˛ş·ą÷ý ·˛¬»®şż˝» ´±±°ľż˝µ đ ·° żĽĽ®»­­ ďéîňďęňďéňë îëëňîëëňîëëňîëë

OSPF is running and the new loopback takes effect in either of these two situations: When the router is reloaded When the OSPF process is removed and reconfigured

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-7

To modify the OSPF router ID to a loopback address, first define a loopback interface as follows: Îďř˝±˛ş·ą÷ý·˛¬»®şż˝» ´±±°ľż˝µ đ

Configuring an IP address on a loopback interface overrides the highest IP address being used as the router ID. OSPF is more reliable if a loopback interface is configured, because the interface is always active and cannot fail, as opposed to a real interface. For this reason, you should use a loopback address on all key routers. If the loopback address is advertised with the network command, then this address can be pinged for testing purposes. A private IP address can be used to save registered public IP addresses. Note

A loopback address requires a different subnet for each router, unless the host address itself is advertised. By default, OSPF advertises loopback addresses as /32 host routes.

If the OSPF process is already running, the router must be reloaded or the OSPF process must be removed and reconfigured before the new loopback address will take effect.

3-86

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Setting OSPF Router ID Îďř˝±˛ş·ąó®±«¬»®÷ý ®±«¬»®ó·Ľ

ďđňďđňďđňď

This OSPF routing process configuration command changes the OSPF router ID. The 32-bit number in the IP address format is used. This must be configured before the OSPF process, otherwise the OSPF process needs to be restarted or the router must be reloaded. Îďý ˝´»ż® ·° ±­°ş °®±˝»­­

This is the command for a manual OSPF process restart.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-8

Use the OSPF router-id command in router configuration mode to ensure that OSPF uses a specific router ID. The ip-address parameter can be any unique, arbitrary 32-bit value in an IP address dotted-decimal format. After the router-id command is configured, use the clear ip ospf process command. This command restarts the OSPF routing process so that it will reselect the new IP address as its router ID. Caution

The clear ip ospf process command will temporarily disrupt an operational network.

Note

Router IDs must be unique throughout the autonomous system (AS), no matter how they are configured.

For more details about the router-id and clear ip ospf commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-87

OSPF Router ID Verification Îîý­¸±© ·° ±­°ş ᫬·˛ą Đ®±˝»­­ ţ±­°ş ëđţ ©·¬¸ ×Ü ďđňęěňđňî 䱫¬°«¬ ±ł·¬¬»Ľâ Ň«łľ»® ±ş ż®»ż­ ·˛ ¬¸·­ ®±«¬»® ·­ îň î ˛±®łż´ đ ­¬«ľ đ ˛­­ż Ň«łľ»® ±ş ż®»ż­ ¬®ż˛­·¬ ˝ż°żľ´» ·­ đ ۨ¬»®˛ż´ ş´±±Ľ ´·­¬ ´»˛ą¬¸ đ ×ŰĚÚ ŇÍÚ ¸»´°»® ­«°°±®¬ »˛żľ´»Ľ Ý·­˝± ŇÍÚ ¸»´°» ® ­«°°±®¬ »˛żľ´»Ľ ß®»ż ŢßÝŐŢŃŇŰřđ÷ Ň«łľ»® ±ş ·˛¬»®şż˝»­ · ˛ ¬¸·­ ż® »ż ·­ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż ¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨» ˝«¬»Ľ đđć đďćďéňčçę żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ě ¬·ł»­ 䱫¬°«¬ ±ł·¬¬»Ľâ ß®»ż ď Ň«łľ»® ±ş ·˛¬»®şż˝»­ · ˛ ¬¸·­ ż® »ż ·­ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż ¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨» ˝«¬»Ľ đđć đđćěęňęęč żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ í ¬·ł»­ 䱫¬°«¬ ±ł·¬¬»Ľâ

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-9

You can use the show ip ospf command to verify the OSPF router ID. This command also displays OSPF timer settings and other statistics, including the number of times the shortest path first (SPF) algorithm has been executed. This command also has optional parameters so that you can further specify the information to be displayed. The figure shows partial output from this command on router R2 in the last example; router R2 is an ABR. The full output is as follows: Îîý­¸±© ·° ±­°ş ᫬·˛ą Đ®±˝»­­ ţ±­°ş ëđţ ©·¬¸ ×Ü ďđňęěňđňî ͬż®¬ ¬·ł»ć đđćđěćěçňđęěô Ě·ł» »´ż°­»Ľć đđćđíćďęňçëî Í«°°±®¬­ ±˛´§ ­·˛ą´» ĚŃÍřĚŃÍđ÷ ®±«¬»­ Í«°°±®¬­ ±°żŻ«» ÔÍß Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ Í«°°±®¬­ ż®»ż ¬®ż˛­·¬ ˝ż°żľ·´·¬§ ׬ ·­ ż˛ ż®»ż ľ±®Ľ»® ®±«¬»® ᫬»® ·­ ˛±¬ ±®·ą·˛ż¬·˛ą ®±«¬»®óÔÍß­ ©·¬¸ łż¨·ł«ł ł»¬®·˝ ײ·¬·ż´ ÍĐÚ ­˝¸»Ľ«´» Ľ»´ż§ ëđđđ ł­»˝­ Ó·˛·ł«ł ¸±´Ľ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ Óż¨·ł«ł ©ż·¬ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ ײ˝®»ł»˛¬ż´óÍĐÚ Ľ·­żľ´»Ľ Ó·˛·ł«ł ÔÍß ·˛¬»®Şż´ ë ­»˝­ Ó·˛·ł«ł ÔÍß ż®®·Şż´ ďđđđ ł­»˝­ ÔÍß ą®±«° °ż˝·˛ą ¬·ł»® îěđ ­»˝­ ײ¬»®şż˝» ş´±±Ľ °ż˝·˛ą ¬·ł»® íí ł­»˝­ 묮ż˛­ł·­­·±˛ °ż˝·˛ą ¬·ł»® ęę ł­»˝­ 3-88

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ň«łľ»® ±ş »¨¬»®˛ż´ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ±°żŻ«» ßÍ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ż®»ż­ ·˛ ¬¸·­ ®±«¬»® ·­ îň î ˛±®łż´ đ ­¬«ľ đ ˛­­ż Ň«łľ»® ±ş ż®»ż­ ¬®ż˛­·¬ ˝ż°żľ´» ·­ đ ۨ¬»®˛ż´ ş´±±Ľ ´·­¬ ´»˛ą¬¸ đ ×ŰĚÚ ŇÍÚ ¸»´°»® ­«°°±®¬ »˛żľ´»Ľ Ý·­˝± ŇÍÚ ¸»´°»® ­«°°±®¬ »˛żľ´»Ľ ß®»ż ŢßÝŐŢŃŇŰřđ÷ Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđďćďéňčçę żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ě ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß ěň ݸ»˝µ­«ł Í«ł đ¨đíďÝçë Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż ď Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđđćěęňęęč żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ í ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß íň ݸ»˝µ­«ł Í«ł đ¨đďďçčÝ Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ

For more details about the show ip ospf command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-89

Verify OSPF Operations This topic describes how to configure a default route injection into OSPF.

Steps to Verify Basic OSPF Verify OSPF routing protocol Verify OSPF interface information Verify OSPF neighbors Verify OSPF routes learned by the router in the IP routing table Verify configured IP routing protocol processes Verify OSPF link state database (LSDB)

Îîý

Îďý 䱫¬°«¬ ±ł·¬¬»Ľâ ·˛¬»®şż˝» Úż­¬ ۬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďđňęěňđňď îëëňîëëňîëëňđ

䱫¬°«¬ ±ł·¬¬»Ľâ ·˛¬»®şż˝» Úż­¬ ۬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďđňęěňđňî îëëňîëëňîëëňđ

䱫¬°«¬ ±ł·¬¬»Ľâ ®±«¬»® ±­°ş ď ˛»¬©±®µ ďđňđňđňđ

·˛¬»®şż˝» Í»®·ż´ đńđńď ·° żĽĽ®»­­ ďđňîňďňî îëëňîëëňîëëňđ ·° ±­°ş ëđ ż®»ż ď

đňîëëňîëëňîëë ż®»ż đ

䱫¬°«¬ ±ł·¬¬»Ľâ ®±«¬»® ±­°ş ë𠲻¬©±®µ ďđňęěňđňî

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

đňđňđňđ ż®»ż đ

ROUTE v1. 0— 3-10

Once the basic OSPF is configured, you can use several verification commands to verify its operation. One of the first verification steps is to verify the presence of the OSPF routing process. If the OSPF process has been configured successfully, there must be an OSPF router inside the IP routing table. Additionally you can verify the OSPF interfaces, routing process neighbors, and database.

3-90

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Example: The show ip ospf Command This command displays the OSPF router ID, timers, and statistics. Îďý­¸±© ·° ± ­°ş ᫬·˛ą Đ®±˝»­­ ţ±­°ş ďţ ©·¬¸ ×Ü ďđňęěňđ ňď ͬż®¬ ¬·ł»ć đđćđďćďę ňđčěô Ě·ł» »´ż° ­»Ľć đđćďěćëčňíęč 䱫¬°«¬ ±ł·¬¬»Ľâ Ó·˛·ł«ł ¸±´ Ľ ¬·ł» ľ» ¬©»»˛ ¬©± ˝±˛­»˝«¬· Ş» ÍĐÚ­ ďđđđđ ł ­»˝­ Óż¨·ł«ł ©ż· ¬ ¬·ł» ľ» ¬©»»˛ ¬©± ˝±˛­»˝«¬· Ş» ÍĐÚ­ ďđđđđ ł ­»˝­ ײ˝®»ł»˛¬ż´ óÍĐÚ Ľ·­ż ľ´»Ľ Ó·˛·ł«ł ÔÍß ·˛¬»®Şż´ ë ­»˝­ Ó·˛·ł«ł ÔÍß ż®®·Şż´ ďđđđ ł­»˝­ ÔÍß ą®±«° ° ż˝·˛ą ¬·ł »® îěđ ­»˝­ ײ¬»®şż˝» ş ´±±Ľ °ż˝· ˛ą ¬·ł»® íí ł­» ˝­ 묮ż˛­ł·­­ ·±˛ °ż˝·˛ ą ¬·ł»® ęę ł­»˝ ­ 䱫¬°«¬ ±ł· ¬¬»Ľâ Ň«łľ»® ±ş ż ®»ż­ ·˛ ¬ ¸·­ ®±«¬»® ·­ ď ň ď ˛±®łż´ đ ­¬«ľ đ ˛­­ż Ň«łľ»® ±ş ż ®»ż­ ¬®ż˛ ­·¬ ˝ż°żľ´» ·­ đ 䱫¬°«¬ ±ł· ¬¬»Ľâ ß®»ż ŢßÝŐ ŢŃŇŰřđ÷ Ň«łľ »® ±ş ·˛¬ »®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ß®»ż ¸ż­ ˛± ż «¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±® ·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđéćîęňëîđ żą± ÍĐÚ ż´ą±® ·¬¸ł »¨»˝«¬»Ľ í ¬·ł »­ 䱫¬°«¬ ±ł·¬¬»Ľâ © 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-11

You can use the show ip ospf command to display general information about Open Shortest Path First (OSPF) routing processes. As shown in the last topic, the show ip ospf command displays the OSPF router ID, OSPF timers, the number of times the SPF algorithm has been executed, and link-state advertisement (LSA) information. For more details about the show ip ospf command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-91

Example: The show ip ospf interface Command This command displays the OSPF router ID, area ID, and adjacency information. Îîý­¸±© ·° ±­°ş ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬ đńđ Úż­¬Ű¬¸»®˛» ¬đńđ ·­ «° ô ´·˛» °®±¬±˝± ´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđ ňęěňđňîńîěô ß® »ż đ Đ®±˝»­­ × Ü ëđô ᫬ »® ×Ü ďđňęěňđňîô Ň»¬©±®µ ̧° » ŢÎŃ ßÜÝßÍĚô ݱ ­¬ć ď Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ŢÜ Îô Đ®·±®·¬ § ď Ü»­·ą˛ż¬» Ľ ᫬»® ř ×Ü÷ ďđňęěňđňďô ײ¬»®şż˝» żĽĽ®»­­ ďđňęěňđňď Ţż˝µ«° Ü» ­·ą˛ż¬»Ľ ® ±«¬»® ř×Ü÷ ďđň ęěňđňîô ײ ¬»®şż˝» ż ĽĽ®»­­ ďđň ęěňđňî Ě·ł»® ·˛¬ »®Şż´­ ˝±˛ ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛ ­ł·¬ ë ±±ľ ó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´ ´± Ľ«» ·˛ đđćđđćđë Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔ Í÷ Ý·­˝± ŇÍÚ ¸»´°»® ­« °°±®¬ »˛żľ´»Ľ ×ŰĚÚ ŇÍÚ ¸»´°»® ­«° °±®¬ »˛żľ´»Ľ ײĽ»¨ ďńî ô ş´±±Ľ Ż« »«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đř đ÷ńđ¨đřđ÷ Ôż­¬ ş´±± Ľ ­˝ż˛ ´»˛ ą¬¸ ·­ ďô łż¨· ł«ł ·­ ď Ôż­¬ ş´±± Ľ ­˝ż˛ ¬·ł » ·­ đ ł­»˝ô ł ż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ď ô ߼¶ż˝»˛¬ ˛»· ą¸ľ±® ˝±«˛ ¬ ·­ ď ߼¶ ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňęěňđňď řÜ»­·ą˛ż¬»Ľ ᫬»®÷ Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ © 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-12

The show ip ospf interface command displays OSPF-related interface information. You can use this command to verify that interfaces are configured in the intended areas. In addition, this command displays the timer intervals (including the hello interval) and shows the neighbor adjacencies. The command output in the figure in the slide is from router R2 from the last configuration example. The output details the OSPF status of the FastEthernet 0/0 interface. You can use the output to verify that OSPF is running on this interface, and what OSPF area the interface is in. This command also displays other information, such as the OSPF process ID, the OSPF router ID, the OSPF network type, the designated router (DR) and backup designated router (BDR), timers, and neighbor adjacency. For more details about the show ip ospf interface command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

3-92

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Example: The show ip ospf neighbor Command This command displays information about the OSPF neighbors, including the DR and BDR information. Îîý­¸±© ·° ± ­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ± ® ×Ü ďđňęěňđ ňď ďđňîňďň ď

Đ®· ď đ

ͬż¬» ÚËÔÔńÜ Î ÚËÔÔń ó

Ü»żĽ Ě·ł» đđćđ đćíî đđćđ đćíé

߼Ľ®»­­ ďđňęěňđ ňď ďđňîňďň ď

ײ¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ Í»®·ż´đńđńď

Îîý­¸±© ·° ± ­°ş ˛»·ą¸ľ±® Ľ»¬ż·´ Ň»·ą¸ľ±® ďđňęěňđňďô ·˛¬» ®şż˝» żĽĽ®»­­ ďđňęěňđňď ײ ¬¸» ż®»ż đ Ş·ż ·˛¬» ®şż˝» Úż­¬Ű¬¸»®˛»¬ďńđ Ň»·ą¸ľ±® °®·±®·¬§ ·­ ď ô ͬż¬» ·­ ÚËÔÔô ę ­¬ż¬» ˝¸ż˛ą»­ ÜÎ ·­ ďđňęěňđňď ŢÜÎ ·­ ďđňęěňđňî 䱫¬°«¬ ±ł·¬¬»Ľâ Ň»·ą¸ľ ±® ďđ ňîňďňďô ·˛¬»®şż˝» ż ĽĽ®»­­ ďđ ňîňďňď ײ ¬¸» ż®»ż ď Ş·ż ·˛¬» ®şż˝» Í»®·ż´îńđ Ň»·ą¸ľ±® °®·±®·¬§ ·­ đ ô ͬż¬» ·­ ÚËÔÔô ę ­¬ż¬» ˝¸ż˛ą»­ ÜÎ ·­ đňđňđňđ ŢÜÎ ·­ đ ňđňđňđ 䱫¬°«¬ ±ł·¬¬»Ľâ

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-13

One of the most important OSPF verification and troubleshooting commands is the show ip ospf neighbor command. OSPF does not send or receive updates without having full adjacencies between neighbors. The show ip ospf neighbor command displays a list of neighbors, including their OSPF router IDs, their OSPF priorities, their neighbor adjacency states (for example, INIT, exstart, or full), and their dead timers. In the first output in the slide, router R2 (from the last configuration example) has two neighbors. The first entry in the table represents the adjacency formed on the Fast Ethernet interface. A FULL state means that the link-state database (LSDB) has been exchanged successfully. The DR entry means that a router is the designated router. The second line in the table represents the neighbor of router R2 on the serial interface. DR and BDR are not used on point-to-point interfaces (indicated by a dash [–]). The second output in the figure shows partial output of the show ip ospf neighbor detail command output, providing details of the neighbors of router R2. The full output is as follows: Îîý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ľ»¬ż·´ Ň»·ą¸ľ±® ďđňęěňđňďô ·˛¬»®şż˝» żĽĽ®»­­ ďđňęěňđňď ײ ¬¸» ż®»ż đ Ş·ż ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬ďńđ Ň»·ą¸ľ±® °®·±®·¬§ ·­ ďô ͬż¬» ·­ ÚËÔÔô ę ­¬ż¬» ˝¸ż˛ą»­ ÜÎ ·­ ďđňęěňđňď ŢÜÎ ·­ ďđňęěňđňî Ń°¬·±˛­ ·­ đ¨ëî ÔÔÍ Ń°¬·±˛­ ·­ đ¨ď řÔÎ÷ Ü»żĽ ¬·ł»® Ľ«» ·˛ đđćđđćíđ Ň»·ą¸ľ±® ·­ «° ş±® đđćďčćđç ײĽ»¨ ďńďô ®»¬®ż˛­ł·­­·±˛ Ż«»«» ´»˛ą¬¸ đô ˛«łľ»® ±ş ®»¬®ż˛­ł·­­·±˛ đ © 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-93

Ú·®­¬ đ¨đřđ÷ńđ¨đřđ÷ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ®»¬®ż˛­ł·­­·±˛ ­˝ż˛ ´»˛ą¬¸ ·­ đô łż¨·ł«ł ·­ đ Ôż­¬ ®»¬®ż˛­ł·­­·±˛ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ďđňîňďňďô ·˛¬»®şż˝» żĽĽ®»­­ ďđňîňďňď ײ ¬¸» ż®»ż ď Ş·ż ·˛¬»®şż˝» Í»®·ż´îńđ Ň»·ą¸ľ±® °®·±®·¬§ ·­ đô ͬż¬» ·­ ÚËÔÔô ę ­¬ż¬» ˝¸ż˛ą»­ ÜÎ ·­ đňđňđňđ ŢÜÎ ·­ đňđňđňđ Ń°¬·±˛­ ·­ đ¨ëî ÔÔÍ Ń°¬·±˛­ ·­ đ¨ď řÔÎ÷ Ü»żĽ ¬·ł»® Ľ«» ·˛ đđćđđćíë Ň»·ą¸ľ±® ·­ «° ş±® đđćďęćďě ײĽ»¨ ďńîô ®»¬®ż˛­ł·­­·±˛ Ż«»«» ´»˛ą¬¸ đô ˛«łľ»® ±ş ®»¬®ż˛­ł·­­·±˛ đ Ú·®­¬ đ¨đřđ÷ńđ¨đřđ÷ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ®»¬®ż˛­ł·­­·±˛ ­˝ż˛ ´»˛ą¬¸ ·­ đô łż¨·ł«ł ·­ đ Ôż­¬ ®»¬®ż˛­ł·­­·±˛ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝

For more details about the show ip ospf neighbor and show ip ospf neighbor detail commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

3-94

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Example: The show ip route ospf Command This command displays all OSPF routes learned by the router. Îďý­¸±© ·° ®±«¬» ±­°ş ďđňđ ňđňđńîě · ­ ­«ľ ˛»¬¬»Ľô î ­«ľ˛» ¬­ Ń ×ß ďđňîň ďňđ Ĺ ďďđńęëĂ Ş·ż ďđň ęěňđ ňîô đđćđěćîçô Úż­¬Ű¬¸»®˛ »¬đńđ

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-14

Use the show ip route ospf command to verify the OSPF routes in the IP routing table known to the router. This command is one of the best ways to determine connectivity between the local router and the rest of the internetwork. This command also has optional parameters so that you can further specify the information to be displayed, including the OSPF process ID. The “O” code represents OSPF routes, and “IA” means “interarea.” In the figure, the 10.2.1.0 subnet is recognized on FastEthernet 0/0 via neighbor 10.64.0.2. The entry “[110/65]” in the routing table represents the administrative distance assigned to OSPF (110), and the total cost of the route to subnet 10.2.1.0 (cost of 65). For more details about the show ip route ospf command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-95

Example: The show ip protocols Command This command verifies the configured IP routing protocol processes, parameters, and statistics. Îďý­¸±© ·° °®±¬±˝±´­ ᫬·˛ą Đ®± ¬±˝±´ ·­ ţ ±­°ş ďţ Ń«¬ą±·˛ą «°Ľż¬» ş·´ ¬»® ´·­¬ ş±® ż ´´ ·˛¬»®şż ˝»­ ·­ ˛± ¬ ­»¬ ײ˝±ł·˛ą «°Ľż¬» ş·´ ¬»® ´·­¬ ş±® ż ´´ ·˛¬»®şż ˝»­ ·­ ˛± ¬ ­»¬ ᫬»® ×Ü ďđňęěňđňď Ň«łľ»® ±ş ż®»ż­ ·˛ ¬¸·­ ®±«¬»® ·­ ďň ď ˛±®ł ż´ đ ­¬«ľ đ ˛­­ż Óż¨·ł«ł ° ż¬¸ć ě ᫬·˛ą ş ±® Ň»¬©±®µ ­ć ďđň đňđňđ đňîëëňîëëňîëë ż®»ż đ λş»®» ˛˝» ľż˛Ľ©·Ľ¬¸ «˛·¬ ·­ ďđđ łľ°­ 䱫¬°«¬ ±ł· ¬¬»Ľâ

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-15

You can use the show ip protocols command to verify the OSPF routing protocol parameters about timers, filters, metrics, networks, and other information for the entire router. The command output in the slide shows that the OSPF routing protocol with process number 1 is configured. The router-id of the router is 10.64.0.1, and it belongs to area 0. For more details about the show ip protocols command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

3-96

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Identifying LSA Types within the LSDB LSAs are the building blocks of the OSPF LSDB. Individually, they act as database records; in combination, they describe the entire topology of an OSPF network or area. This topic describes the LSAs defined by OSPF.

LSA Types LSA Type

Description

1

Router LSAs

2

Network LSAs

3 or 4

Summary LSAs

5

Autonomous system external LSAs

6

Multicast OSPF LSAs

7

LSAs defined for not-so-stubby areas

8

External attribute LSAs for Border Gateway Protocol (BGP)

9, 10, 11

Opaque LSAs

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-16

The following are descriptions of each type of LSA. LSA types 1 through 5 and 7 are explained in more detail in the following pages.

Type 1 Every router generates router link advertisements for each area to which it belongs. Router link advertisements describe the state of the router’s links to the area, and are flooded only within that particular area. For all types of LSAs, there are 20-byte LSA headers. One of the fields of the LSA header is the link-state ID. The link-state ID of the type 1 LSA is the originating router ID.

Type 2 DRs generate network link advertisements for multiaccess networks that describe the set of routers attached to a particular multiaccess network. Network link advertisements are flooded in the area that contains the network. The link-state ID of the type 2 LSA is the IP interface address of the DR.

Types 3 and 4 ABRs generate summary link advertisements. Summary link advertisements describe the following interarea routes: Type 3 describes routes to networks and aggregates routes. © 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-97

Type 4 describes routes to ASBRs. The link-state ID is the destination network number for type 3 LSAs and the router ID of the described ASBR for type 4 LSAs. These LSAs are flooded throughout the backbone area to the other ABRs. The link entries are not flooded into totally stubby areas or not-so-stubby areas (NSSAs).

Type 5 ASBRs generate AS external link advertisements. External link advertisements describe routes to destinations external to the AS and are flooded everywhere with the exception of stub areas, totally stubby areas, and NSSAs. The link-state ID of the type 5 LSA is the external network number.

Type 6 Type 6 LSAs are specialized LSAs that are used in multicast OSPF applications.

Type 7 Type 7 LSAs are used in NSSAs for external routes.

Type 8 Type 8 LSAs are specialized LSAs that are used in internetworking OSPF and Border Gateway Protocol (BGP).

Types 9, 10, and 11 The opaque LSAs, types 9, 10, and 11, are designated for future upgrades to OSPF for application-specific purposes. For example, Cisco Systems uses opaque LSAs for Multiprotocol Label Switching (MPLS) with OSPF. Standard LSDB flooding mechanisms are used for distribution of opaque LSAs. Each of the three types has a different flooding scope.

3-98

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

LSA Type 1: Router LSA One router LSA for every router in an area (intra-area) – Includes a list of directly attached links – Links identified by the IP prefix and link type LSA identified by the router ID of the originating router Floods within its area only; does not cross an ABR

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-17

A router advertises a type 1 LSA that floods to all other routers in the area in which it originated. A type 1 LSA describes the collective states of the directly connected links (interfaces) of the router. Each type 1 LSA is identified by the router ID. Each router link is defined as one of four link types: type 1, 2, 3, or 4. The LSA includes a link ID field that identifies, by the network number and mask, the object to which this link connects.

LSA Type 1 Link Types Depending on the type, the link ID has different meanings, as described in the table. Link Type

Description

Link ID

1

Point-to-point connection to another router

Neighboring router ID

2

Connection to a transit network

IP address of DR

3

Connection to a stub network

IP network or subnet number

4

Virtual link

Neighboring router ID

A stub network is a dead-end link that has only one router attached. In addition, the type 1 LSA describes whether the router is an ABR or ASBR.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-99

LSA Type 2: Network LSA One network LSA for each transit broadcast or NBMA network in an area (intra-area) – Includes a list of attached routers on the transit link – Includes a subnet mask of the link Advertised by the DR of the broadcast network Floods within its area only; does not cross an ABR

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-18

A type 2 LSA is generated for every transit broadcast or nonbroadcast multiaccess (NBMA) network within an area. A transit network has at least two directly attached OSPF routers. A multiaccess network like Ethernet is an example of a transit network. The DR of the network is responsible for advertising the network LSA. A type 2 network LSA lists each of the attached routers that make up the transit network, including the DR itself and the subnet mask used on the link. The type 2 LSA then floods to all routers within the transit network area. Type 2 LSAs never cross an area boundary. The link-state ID for a network LSA is the IP interface address of the DR that advertises it.

3-100

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

LSA Type 3: Summary LSA Used to flood network information to areas outside the originating area (interarea) – Describes the network number and mask of the link Advertised by the ABR of the originating area, regenerated by all subsequent ABRs to flood throughout the AS Advertised for every subnet and not summarized, by default

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-19

The ABR sends type 3 summary LSAs. Type 3 LSAs advertise any networks owned by an area to the rest of the areas in the OSPF AS, as shown in the figure. The link-state ID is set to the network number; the mask is also advertised. By default, OSPF does not automatically summarize groups of contiguous subnets, nor does it summarize a network to its classful boundary. The network operator, through configuration commands, must specify how the summarization will occur. By default, a type 3 LSA is advertised into the backbone area for every subnet defined in the originating area, which can cause significant flooding problems. Consequently, you should always consider using manual route summarization at the ABR. Summary LSAs are flooded throughout a single area only, but are regenerated by ABRs to flood into other areas. Note

© 2009 Cisco Systems, Inc.

By default, summary LSAs do not contain summarized routes.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-101

LSA Type 4: ASBR Summary LSA Used to advertise a metric to the ASBR, which is used for path selection Generated by the ABR of the originating area Regenerated by all subsequent ABRs to flood throughout the AS Contain the router ID of the ASBR

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-20

A type 4 summary LSA is generated by an ABR only when an ASBR exists within an area. A type 4 LSA identifies the ASBR and provides a route to it. The link-state ID is set to the ASBR router ID. All traffic destined to an external AS requires routing table knowledge of the ASBR that originated the external routes.

Example: LSA Type 4—ASBR Summary LSA In the figure, the ASBR sends a type 1 router LSA with a bit (known as the external bit [e bit]) that is set to identify itself as an ASBR. When the ABR (identified with the border bit [b bit] in the router LSA) receives this type 1 LSA, it builds a type 4 LSA and floods it to the backbone, area 0. Subsequent ABRs regenerate a type 4 LSA to flood into their areas.

3-102

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

LSA Type 5: External LSA Used to advertise networks from other ASs Advertised and owned by the originating ASBR Flooded throughout the entire AS The advertising router ID (ASBR) is unchanged throughout the AS A type 4 LSA is needed to find the ASBR By default, routes are not summarized

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-21

Type 5 external LSAs describe routes to networks outside the OSPF AS. Type 5 LSAs are originated by the ASBR and are flooded to the entire AS. The link-state ID is the external network number. Because of the flooding scope and depending on the number of external networks, the default lack of route summarization can also be a major issue with external LSAs. Therefore, you should always attempt to summarize blocks of external network numbers at the ASBR to reduce flooding problems.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-103

LSA Type 7: NSSA External LSA Used to advertise networks from other ASs injected into the NSSA. Have the same format as a type 5 external LSA Advertised and owned by the originating ASBR Translated to LSA type 5 on first NSSA subsequent ABR By default, routes are not summarized

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-22

Type 7 external LSAs describe routes to networks outside the OSPF AS. Redistribution from an external autonomous system into an NSSA area creates this special LSA type 7, which can only exist in an NSSA area. An NSSA autonomous system boundary router (ASBR) generates this LSA and an NSSA area border router (ABR) translates it into a type 5 LSA, which gets propagated into the OSPF domain to all areas that can support Type 5 LSAs. Routers operating NSSA areas set the N-bit to signify that they can support type 7 NSSAs. These option bits must be checked during neighbor establishment. They must match for an adjacency to form. The link-state ID is the external network number. Because of the flooding scope and depending on the number of external networks, the default lack of route summarization can also be a major issue with external LSAs. Therefore, you should always attempt to summarize blocks of external network numbers at the ASBR to reduce flooding problems. The advertising router is set to the router ID of the router that injected the external route into OSPF—a router inside this NSSA area. This address is also set as the “Forward Address” for this prefix; the address used to determine the path to take towards this external destination.

3-104

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Example of Different LSAs Note: Only one example of each LSA type exchange is demonstrated in this graphic.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-23

Example: Types of Link State Advertisements (LSAs) Link-state advertisements are packets that OSPF uses to advertise changes in the condition of a specific link to other OSPF routers. There are various types of link-state packets used by OSPF, each of which is generated for a different purpose and flooded in the network. The following are the different types of LSA packets that can be generated by the source router and entered into the destination router's LSA database. Type 1: Router link LSAs: Router LSAs are generated by each router for each area it is in. The link-state ID is the originating router's ID. Type 2: Intra-area network link LSAs: Network LSAs are generated by designated routers (DRs). The link-state ID is the IP interface address of the DR. Type 3: Network summary LSAs for ABRs: Summary LSAs are generated by ABRs. The link-state ID is the destination network number. Type 4: ASBR summary LSAs for ASBRs: Summary LSAs are generated by ABRs. The link-state ID is the router ID of the described ASBR. Type 5: Autonomous System External LSAs: Type 5 LSAs are generated by the ASBRs. The link-state ID is the external network number. Type 7: Not-So-Stubby Area External LSAs: Type 7 LSAs are generated by ASBRs.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-105

Note

3-106

OSPF has more LSAs. Types 9, 10, and 11 (Opaque LSAs) may be used for distributing application-specific information through an OSPF domain. Type 9 LSAs are not flooded beyond the local network or subnetwork. Type 10 LSAs are not flooded beyond the borders of their associated area. Type 11 LSAs are flooded throughout the AS. The flooding scope of type 11 LSAs is equivalent to that of AS-external (type 5) LSAs. Cisco MPLS Traffic Engineering (Cisco MPLS TE) functionality has been implemented with type 10 opaque LSAs. For more information about opaque LSAs, please see RFC 2370. Type 8 LSAs are specialized LSAs that are used in internetworking OSPF and Border Gateway Protocol (BGP).

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

OSPF LSDB: Intra-Area Routing

Îďý

Îîý

·˛¬»®şż˝» Úż­¬ ۬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďđňęěňđňď îëëňîëëňîëëňđ

·˛¬»®şż˝» Úż­¬ ۬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďđňęěňđňî îëëňîëëňîëëňđ

䱫¬°«¬ ±ł·¬¬»Ľâ ®±«¬»® ±­°ş ď ˛»¬©±®µ ďđňđňđňđ

·˛¬»®şż˝» Í»®·ż´ đńđńď ·° żĽĽ®»­­ ďđňîňďňî îëëňîëëňîëëňđ ·° ±­°ş ëđ ż®»ż ď

đňîëëňîëëňîëë ż®»ż đ

®±«¬»® ±­°ş ë𠲻¬©±®µ ďđňęěňđňî

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

đňđňđňđ ż®»ż đ

ROUTE v1. 0— 3-24

The figure in the slide shows the topology that will be used to describe the OSPF link state database (LSDB) for intra-area routing. All routers are configured for OSPF routing and the show ip ospf database command is used to get information about an OSPF LSDB. The router link states presented on the next figure are type 1 and type 2 LSAs, since we are focused on OSPF intra-area database entries.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-107

OSPF LSDB: Intra-Area Routing (Cont.) Îîý­¸±© ·° ±­°ş Ľż¬ żľż­» ŃÍĐÚ Î±«¬ »® © ·¬¸ × Ü řďđňęěňđ ňî÷ řĐ®±˝ »­­ ×Ü ëđ÷

Ô·˛µ × Ü ďđňęěň đňď ďđňęěň đňî

LSA Type 1 from area 0

᫬»® Ô·˛µ ͬ ż¬»­ řß® »ż đ÷ ßÜĘ Î±«¬»® ßą» Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ ďđňęěňđňď íđë đ¨čđđđđđđî đ¨đđÝçíŢ ď ďđňęěňđňî îíé đ¨čđđđđđđě đ¨đđÝęíč ď

LSA Type 2 from area 0 Ô·˛µ × Ü ďđňęěň đňď

Ň»¬ Ô·˛µ ͬż¬» ­ řß®»ż đ÷ ßÜĘ Î±«¬»® ßą» ďđňęěňđňď íđë

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđčÜéŰ

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-25

The figure in the slide illustrates the use of the show ip ospf database command to get information about an OSPF LSDB. The router link states are type 1 LSAs and the net link states are type 2 LSAs. The database columns are as follows: Link ID: This identifies each LSA. ADV router: This shows the address of the advertising router, the source router of the LSA. Age: This shows the maximum age counter in seconds; the maximum configurable age counter is 1 hour, or 3,600 seconds. Seq#: This is the sequence number of the LSA; the number begins at 0x80000001 and increases with each update of the LSA. Checksum: This is the checksum of the individual LSA, which can be used to ensure reliable receipt of that LSA. Link count: This is the total number of directly attached links, which is used only on router LSAs. The link count includes all point-to-point, transit, and stub links. Each point-to-point serial link counts as two; all other links count as one, including Ethernet links. The output in the figure is partial output from an ABR—router R2. The full command output from this router is as follows: Îîý­¸ ·° ±­°ş Ľż¬żľż­»

ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňęěňđňî÷ řĐ®±˝»­­ ×Ü ëđ÷

᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷

3-108

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ô·˛µ ×Ü ßÜĘ Î±«¬»® ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬

ßą»

Í»Żý

ďđňęěňđňď đ¨đđÝéíÝ ď

ďđňęěňđňď

çď

đ¨čđđđđđđí

ďđňęěňđňî đ¨đđÝěíç ď

ďđňęěňđňî

ěę

đ¨čđđđđđđë

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷

Ô·˛µ ×Ü Ý¸»˝µ­«ł

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ďđňęěňđňď đ¨đđčŢéÚ

ďđňęěňđňď

çď

đ¨čđđđđđđî

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷

Ô·˛µ ×Ü Ý¸»˝µ­«ł

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ďđňîňďňđ đ¨đđÚŢßę

ďđňęěňđňî

ěę

đ¨čđđđđđđî

᫬»® Ô·˛µ ͬż¬»­ řß®»ż ď÷

Ô·˛µ ×Ü ßÜĘ Î±«¬»® ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬

ßą»

Í»Żý

ďđňîňďňď đ¨đđďéđç î

ďđňîňďňď

ďçęç

đ¨čđđđđđđî

ďđňęěňđňî đ¨đđëęčé î

ďđňęěňđňî

ěę

đ¨čđđđđđđě

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż ď÷

Ô·˛µ ×Ü Ý¸»˝µ­«ł

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ďđňęěňđňđ đ¨đđßíđď

ďđňęěňđňî

ěé

đ¨čđđđđđđî

Îîý

For more details about the show ip ospf database command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-109

OSPF LSDB: Interarea Routing

Îďý

Îîý

·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďňďňďňď îëëňđňđňđ ·˛¬»®şż˝» ۬¸»®˛»¬îńđńđ ·° żĽĽ®»­­ ěňđňđňď îëëňđňđňđ ·˛¬»®şż˝» Í»®·ż´îńďńđ ·° «˛˛«łľ»®»Ľ ۬¸»®˛»¬îńđńđ ®±«¬»® ±­°ş ď ˛»¬©±®µ ěňđňđňđ đňîëëňîëëňîëë ż®»ż đ

·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ îňîňîňî îëëňđňđňđ ·˛¬»®şż˝» ۬¸»®˛»¬đńđńě ·° żĽĽ®»­­ ęňđňđňî îëëňđňđňđ ·˛¬»®şż˝» Í»®·ż´đńďńđ ·° «˛˛«łľ»®»Ľ ۬¸»®˛»¬đńđńě ·˛¬»®şż˝» ßĚÓďńđňîđ °±·˛¬ó¬±ó°±·˛¬ ·° żĽĽ®»­­ îđđňđňđňî îëëňîëëňîëëňđ ®±«¬»® ±­°ş î ˛»¬©±®µ ęňđňđňđ đňîëëňîëëňîëë ż®»ż 𠲻¬©±®µ îđđňđňđňđ đňîëëňîëëňîëë ż®»ż ď

Îíý ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ íňíňíňí îëëňđňđňđ ·˛¬»®şż˝» ßĚÓîńđňîđ °±·˛¬ó¬±ó°±·˛¬ ·° żĽĽ®»­­ îđđňđňđňí îëëňîëëňîëëňđ ®±«¬»® ±­°ş î ˛»¬©±®µ îđđňđňđňđ đňîëëňîëëňîëë ż®»ż ď © 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-26

The figure in the slide presents the topology that will be used to describe the OSPF link state database (LSDB) for inter-area routing. All routers are configured for OSPF routing and the show ip ospf database command is used to get information about an OSPF LSDB. The router link states presented on the next figure are type 1 and type 3 LSAs.

3-110

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

OSPF LSDB: Interarea Routing (Cont.) Îîý­¸±© ·° ±­°ş Ľż¬ żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řîňîňîňî÷ řĐ® ±˝»­­ ×Ü î÷

Ô·˛µ × Ü ďňďňďň ď îňîňîň î

Ô·˛µ × Ü îđđňđň đňđ

Ô·˛µ × Ü îňîňîň î íňíňíň í

Ô·˛µ × Ü ěňđňđň đ ęňđňđň đ

᫬»® ßÜĘ Î ±«¬»® ďňďňď ňď îňîňî ňî

Ô·˛µ ͬ ż¬»­ řß® »ż đ÷ ßą» Í»Żý ݸ»˝µ­«ł ęçé đ¨čđđđđđěđ đ¨ëßîď ęçę đ¨čđđđđđěë đ¨ŰŰčî

Í«łłż®§ Ň»¬ Ô· ˛µ ͬż¬» ­ řß®»ż đ÷ ßÜĘ Î±«¬»® ßą» Í»Żý ݸ»˝µ­«ł îňî ňîňî íëî đ¨čđđđđđđď đ¨îëěę ᫬»® Ô·˛µ ßÜĘ Î ±«¬»® ßą» îňîňî ňî íëď íňíňí ňí íëě Í«łłż®§ ßÜĘ Î±«¬»® îňîň îňî îňîň îňî

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ͬ ż¬»­ řß® »ż ď÷ Í» Żý ݸ»˝µ­«ł đ¨ čđđđđđđŢ đ¨ÝßçÜ đ¨ čđđđđđđę đ¨éďÚé

LSA Type 1 from area 0 Ô·˛µ ˝±«˛¬ î î LSA Type 3

for area 0

LSA Type 1 from area 1 Ô·˛µ ˝±«˛¬ î LSA Type 3 î

for area 1

Ň»¬ Ô· ˛µ ͬż¬» ­ řß®»ż ď÷ ßą» Í»Żý ݸ»˝µ­«ł ęčç đ¨čđđđđđđď đ¨ÚÚŰę éđđ đ¨čđđđđđđď đ¨ęíÝď

ROUTE v1. 0— 3-27

The figure in the slide illustrates the use of the show ip ospf database command to get information about an OSPF LSDB. The router link states are type 1 LSAs and the summary net link states are type 3 LSAs. Since router R2 is the ABR, it has the database for both areas that it is connected to. That makes it the best place to see the OSPF database. The output in the figure is the full command output from this router. To advertise routes from one area into another, the ABR creates summary links, which you can see using the show ip ospf database summary command.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-111

OSPF LSDB: External Routes

Îďý ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďňďňďňď îëëňđňđňđ ·˛¬»®şż˝» Í»®·ż´îńďńđ ·° żĽĽ®»­­ ëňđňđňď îëëňđňđňđ ·˛¬»®şż˝» ۬¸»®˛»¬îńđńđ ·° żĽĽ®»­­ ěňđňđňď îëëňđňđňđ ®±«¬»® ±­°ş ě ®»Ľ·­¬®·ľ«¬» ­¬ż¬·˝ ł»¬®·˝ ë ł»¬®·˝ó¬§°» ď ˛»¬©±®µ ëňđňđňđ đňîëëňîëëňîëë ż®»ż ď ˛»¬©±®µ ěňđňđňđ đňîëëňîëëňîëë ż®»ż ď ·° ®±«¬» çňđňđňđ îëëňđňđňđ ěňđňđňî

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

Îîý ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ îňîňîňî îëëňđňđňđ ·˛¬»®şż˝» Í»®·ż´đńďńđ ·° żĽĽ®»­­ ëňđňđňî îëëňđňđňđ ·˛¬»®şż˝» ßĚÓďńđňîđ ·° żĽĽ®»­­ ęňđňđňî îëëňđňđňđ ®±«¬»® ±­°ş î ˛»¬©±®µ ëňđňđňđ đňîëëňîëëňîëë ż®»ż ď ˛»¬©±®µ ęňđňđňđ đňîëëňîëëňîëë ż®»ż đ Îíý ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ íňíňíňí îëëňđňđňđ ·˛¬»®şż˝» ßĚÓîńđňîđ °±·˛¬ó¬±ó°±·˛¬ ·° żĽĽ®»­­ ęňđňđňí îëëňđňđňđ ®±«¬»® ±­°ş î ˛»¬©±®µ ęňđňđňđ đňîëëňîëëňîëë ż®»ż đ ROUTE v1. 0— 3-28

The figure in the slide shows the topology that will be used to describe the OSPF link state database (LSDB) for external routes. All routers are configured for OSPF routing and the show ip ospf database command is used to get information about an OSPF LSDB. The router link states presented on the next figure are type 1, type 3, type 4, and type 5 LSAs.

3-112

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

OSPF LSDB: External Routes (Cont.) Îîý­¸±© ·° ±­°ş Ľż¬ żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řîňîňîňî÷ řĐ® ±˝»­­ ×Ü î÷

LSA Type 1 from area 0

Ô·˛µ × Ü îňîňîň î íňíňíň í

᫬»® Ô·˛µ ͬ ż¬»­ řß® »ż đ÷ ßÜĘ Î±«¬»® ßą» Í»Żý îňîň îňî çí đ¨čđđđđđîđ íňíň íňí ďîîë đ¨čđđđđđđÜ

ݸ»˝µ­«ł đ¨ÝÜđŢ đ¨çđëé

Ô·˛µ × Ü ěňđňđň đ ëňđňđň đ

Í«łłż®§ Ň»¬ Ô· ˛µ ͬż¬» ­ řß®»ż ßÜĘ Î±«¬»® ßą» Í»Żý îňî ňîňî éí đ¨čđđđđđđď îňî ňîňî ďęëď đ¨čđđđđđđę

đ÷ ݸ»˝µ­«ł đ¨ÚÚŰę đ¨čěęę

Í«łłż®§ ßÍŢ Ô· ˛µ ͬż¬» ­ řß®»ż đ÷ Ô·˛µ × Ü ßÜĘ Î ±«¬»® ßą» Í»Żý ݸ»˝µ­«ł ďňďňďň ď îňîň îňî éě đ¨čđđđđđđď đ¨çíëÝ ä±«¬°« ¬ ±ł·¬¬»Ľ â

Ô·˛µ × Ü çňđňđň đ

̧°»óë ßÍ Ű¨¬» ®˛ż´ Ô·˛ µ ͬż¬»­ ßÜĘ Î ±«¬»® ßą» Í »Żý ݸ»˝µ­«ł ďňďňď ňď ďíë đ ¨čđđđđđđď đ¨íßŰč

Ô·˛µ ˝±«˛¬ î î LSA Type 3

for area 0

LSA Type 4 of ASBR from ABR

LSA Type 5 from ASBR Ěżą đ

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-29

The figure in the slide illustrates the use of the show ip ospf database command to get information about an OSPF LSDB in terms of external routes. The router link states are type 1 LSAs and the summary net link states are type 3 LSAs. Additionally, the autonomous system boundary router (ASBR) creates (type 5) external LSAs to advertise external routes into OSPF. External LSAs are flooded unaltered into all areas. However, the ASBR is not in area 0. Routers in area 0 do not know how to reach the ASBR. To advertise the reachability of an ASBR into other areas, the ABR creates (type 4) ASBR-summary LSAs. The output in the figure is partial output from an ABR: router R2. The full command output from this router is as follows: Îîý­¸±© ·° ±­°ş Ľż¬żľż­»

ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řîňîňîňî÷ řĐ®±˝»­­ ×Ü î÷

᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷

Ô·˛µ ×Ü ˝±«˛¬

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł

Ô·˛µ

îňîňîňî

îňîňîňî

çí

đ¨čđđđđđîđ

đ¨ÝÜđŢ

î

íňíňíňí

íňíňíňí

ďîîë

đ¨čđđđđđđÜ

đ¨çđëé

î

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷

© 2009 Cisco Systems, Inc.

Ô·˛µ ×Ü

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł

ěňđňđňđ

îňîňîňî

éí

đ¨čđđđđđđď

đ¨ÚÚŰę

ëňđňđňđ

îňîňîňî

ďęëď

đ¨čđđđđđđę

đ¨čěęę

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-113

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż đ÷

Ô·˛µ ×Ü

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł

ďňďňďňď

îňîňîňî

éě

đ¨čđđđđđđď

đ¨çíëÝ

᫬»® Ô·˛µ ͬż¬»­ řß®»ż ď÷

Ô·˛µ ×Ü ˝±«˛¬

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł

Ô·˛µ

ďňďňďňď

ďňďňďňď

čç

đ¨čđđđđđďď

đ¨ÚÚëç

í

îňîňîňî

îňîňîňî

čč

đ¨čđđđđđíí

đ¨îďíđ

î

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż ď÷

Ô·˛µ ×Ü

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł

ęňđňđňđ

îňîňîňî

çě

đ¨čđđđđđďÚ

đ¨ÝÝěí

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­

3-114

Ô·˛µ ×Ü

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł

çňđňđňđ

ďňďňďňď

ďíë

đ¨čđđđđđđď

đ¨íßŰč

Implementing Cisco IP Routing (ROUTE) v1.0

Ěżą đ

© 2009 Cisco Systems, Inc.

OSPF LSDB: NSSA

Îîý

Îďý ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďňďňďňď îëëňđňđňđ ·˛¬»®şż˝» Í»®·ż´îńďńđ ·° żĽĽ®»­­ ëňđňđňď îëëňđňđňđ ·˛¬»®şż˝» ۬¸»®˛»¬îńđńđ ·° żĽĽ®»­­ ěňđňđňď îëëňđňđňđ ®±«¬»® ±­°ş ě ®»Ľ·­¬®·ľ«¬» ­¬ż¬·˝ ł»¬®·˝ ë ł»¬®·˝ó¬§°» ď ˛»¬©±®µ ëňđňđňđ đňîëëňîëëňîëë ż®»ż ď ˛»¬©±®µ ěňđňđňđ đňîëëňîëëňîëë ż®»ż ď ż®»ż ď ˛­­ż ·° ®±«¬» çňđňđňđ îëëňđňđňđ ěňđňđňî © 2009 Cis co S yst em s, Inc. A ll rights reserved.

·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ îňîňîňî îëëňđňđňđ ·˛¬»®şż˝» Í»®·ż´đńďńđ ·° żĽĽ®»­­ ëňđňđňî îëëňđňđňđ ·˛¬»®şż˝» ßĚÓďńđňîđ ·° żĽĽ®»­­ ęňđňđňî îëëňđňđňđ ®±«¬»® ±­°ş î ˛»¬©±®µ ëňđňđňđ đňîëëňîëëňîëë ż®»ż ď ˛»¬©±®µ ęňđňđňđ đňîëëňîëëňîëë ż®»ż đ ż®»ż ď ˛­­ż Îíý ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ íňíňíňí îëëňđňđňđ ·˛¬»®şż˝» ßĚÓîńđňîđ °±·˛¬ó¬±ó°±·˛¬ ·° żĽĽ®»­­ ęňđňđňí îëëňđňđňđ ®±«¬»® ±­°ş î ˛»¬©±®µ ęňđňđňđ đňîëëňîëëňîëë ż®»ż đ ROUTE v1. 0— 3-30

The figure in the slide presents the topology that will be used to describe the OSPF link state database (LSDB) for NSSA routing. All routers are configured for OSPF routing and the show ip ospf database command is used to get information about an OSPF LSDB. The router link states presented on the next figure are type 1, type 3, type 5, and type 7 LSAs.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-115

OSPF LSDB: NSSA (Cont.) Îîý­¸±© ·° ±­°ş Ľż¬ żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řîňîňîňî÷ řĐ® ±˝»­­ ×Ü î÷

LSA Type 1 from area 0

Ô·˛µ × Ü îňîňîň î íňíňíň í

᫬»® Ô·˛µ ͬ ż¬»­ řß® »ż đ÷ ßÜĘ Î ±«¬»® ßą» Í»Żý îňîň îňî ďîíë đ¨čđđđđđďÜ íňíň íňí ďďđđ đ¨čđđđđđđŢ

Ô·˛µ × Ü ěňđňđň đ ëňđňđň đ

Í«łłż®§ Ň»¬ Ô· ˛µ ͬż¬» ­ řß®»ż đ÷ ßÜĘ Î ±«¬»® ßą» Í»Żý ݸ»˝µ­«ł îňîň îňî ďçéç đ¨čđđđđđđî đ¨ÚÜŰé îňîň îňî ďěčí đ¨čđđđđđđě đ¨ččęě

ݸ»˝µ­«ł đ¨ÜçÚÚ đ¨çěëë

Ô·˛µ ˝±«˛¬ î LSA î Type 3

for area 0

LSA Type 7 from ASBR

̧°»óé ßÍ Ű¨¬» ®˛ż´ Ô·˛ µ ͬż¬»­ řß®»ż ď÷ Ô·˛µ × Ü çňđňđň đ

ßÜĘ Î ±«¬»® ďňďň ďňď

ßą» ííě

Í»Żý đ¨čđđđđđđë

ݸ»˝µ­«ł đ¨Üéíč

Ěżą đ

LSA Type 5 from ABR

̧°»óë ßÍ Ű¨¬» ®˛ż´ Ô·˛ µ ͬż¬»­ Ô·˛µ × Ü çňđňđň đ

ßÜĘ Î ±«¬»® îňîň îňî

ßą» ďéîë

Í»Żý đ¨čđđđđđđě

ݸ»˝µ­«ł đ¨ëđÝę

Ěżą đ

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-31

The figure in the slide illustrates the use of the show ip ospf database command to get information about an OSPF LSDB for NSSA routing. The router link states are type 1 LSAs and the summary net link states are type 3 LSAs and both are used to advertise routes from one area into another. To advertise external routes into an NSSA, the autonomous system boundary router (ASBR) also creates NSSA external LSAs (type 7). The ABR converts type 7 LSAs into type 5 LSAs, and propagates the type 5 LSAs into normal areas. The ASBR summary LSAs are not needed in this case, because the ABR originates the external LSA and the ABR is reachable within area 0. You can compare this example with a scenario in which the NSSA is a normal area by looking at the previous database example. The output in the figure is partial output from an ABR: router R2. The full command output from this router is as follows: Îîý­¸±© ·° ±­°ş Ľż¬żľż­»

ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řîňîňîňî÷ řĐ®±˝»­­ ×Ü î÷

᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷

Ô·˛µ ×Ü ßÜĘ Î±«¬»® Ô·˛µ ˝±«˛¬

ßą»

Í»Żý

ݸ»˝µ­«ł

îňîňîňî î

îňîňîňî

ďîíë

đ¨čđđđđđďÜ

đ¨ÜçÚÚ

íňíňíňí î

íňíňíňí

ďďđđ

đ¨čđđđđđđŢ

đ¨çěëë

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷

3-116

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ô·˛µ ×Ü

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł

ěňđňđňđ

îňîňîňî

ďçéç

đ¨čđđđđđđî

đ¨ÚÜŰé

ëňđňđňđ

îňîňîňî

ďěčí

đ¨čđđđđđđě

đ¨ččęě

᫬»® Ô·˛µ ͬż¬»­ řß®»ż ď÷

Ô·˛µ ×Ü ˝±«˛¬

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł

Ô·˛µ

ďňďňďňď

ďňďňďňď

íďç

đ¨čđđđđđđÝ

đ¨ßÚßč

í

îňîňîňî

îňîňîňî

îîđ

đ¨čđđđđđîÚ

đ¨Üěéč

î

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż ď÷

Ô·˛µ ×Ü

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł

ęňđňđňđ

îňîňîňî

ďěčí

đ¨čđđđđđďÝ

đ¨éčçě

̧°»óé ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ řß®»ż ď÷

Ô·˛µ ×Ü

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł

çňđňđňđ

ďňďňďňď

ííě

đ¨čđđđđđđë

đ¨Üéíč

Ěżą đ

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­

© 2009 Cisco Systems, Inc.

Ô·˛µ ×Ü

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł

çňđňđňđ

îňîňîňî

ďéîë

đ¨čđđđđđđě

đ¨ëđÝę

Implementing a Scalable Multiarea Network OSPF-Based Solution

Ěżą đ

3-117

OSPF LSDB: Virtual Link

Îďý

Îíý

·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďňďňďňď îëëňđňđňđ

·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ íňíňíňí îëëňđňđňđ

·˛¬»®şż˝» ۬¸»®˛»¬îńđńđ ·° żĽĽ®»­­ ěňđňđňď îëëňđňđňđ

·˛¬»®şż˝» ۬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďîňđňđňí îëëňđňđňđ

·˛¬»®şż˝» Í»®·ż´îńďńđ ·° żĽĽ®»­­ ëňđňđňď îëëňđňđňđ

·˛¬»®şż˝» ßĚÓîńđňîđ °±·˛¬ó¬±ó°±·˛¬ ·° żĽĽ®»­­ ęňđňđňí îëëňđňđňđ

®±«¬»® ±­°ş î ˛»¬©±®µ ěňđňđňđ đňîëëňîëëňîëë ż®»ż 𠲻¬©±®µ ëňđňđňđ đňîëëňîëëňîëë ż®»ż ď ż®»ż ď Ş·®¬«ż´ó´·˛µ íňíňíňí

®±«¬»® ±­°ş î ˛»¬©±®µ ďîňđňđňđ đňîëëňîëëňîëë ż®»ż î ˛»¬©±®µ ęňđňđňđ đňîëëňîëëňîëë ż®»ż ď ż®»ż ď Ş·®¬«ż´ó´·˛µ ďňďňďňď

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-32

The figure in the slide presents the topology that will be used to describe the OSPF link state database (LSDB) when virtual links are configured. All routers are configured for OSPF routing and the show ip ospf database command is used to get information about an OSPF LSDB. The router link states presented in the next figure are type 1 and type 3 LSAs.

3-118

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

OSPF LSDB: Virtual Link (Cont.) Îďý­¸±© ·° ±­°ş Ľż¬ żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďňďňďňď÷ řĐ® ±˝»­­ ×Ü î÷ ᫬»® Ô·˛µ ͬ ż¬»­ řß® »ż đ÷ Ô·˛µ × Ü ˝±«˛¬ ďňďňďň ď íňíňíň í

ßÜĘ Î ±«¬»®

ßą»

ďňďňď ňď íňíňí ňí

çďç ë

řÜŇß÷

Í»Żý

ݸ»˝µ­«ł

đ¨čđđđđđđí đ¨čđđđđđđî

đ¨ÜëÜÚ đ¨íççđ

Ô·˛µ î ď

Í«łłż®§ Ň»¬ Ô· ˛µ ͬż¬» ­ řß®»ż đ÷ Ô·˛µ × Ü ëňđňđň đ ëňđňđň đ ęňđňđň đ ęňđňđň đ ďîňđňđ ňđ

ßÜĘ Î ±«¬»® ďňďňď ňď íňíňí ňí ďňďňď ňď íňíňí ňí íňíňí ňí

ßą» ďçěë ç ďçěę ç ç

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđď

řÜŇß÷ řÜŇß÷ řÜŇß÷

ݸ»˝µ­«ł đ¨ßßěč đ¨éßéđ đ¨ßéěç đ¨ŰßíÚ đ¨Úęîě

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-33

The figure in the slide illustrates the use of the show ip ospf database command to get information about an OSPF LSDB when virtual links are configured. The router link states are type 1 LSAs and the summary net link states are type 3 LSAs and both are used to advertise routes from one area into another. Notice that LSAs learned through the virtual link have the DoNotAge (DNA) option. The virtual link is treated like a demand circuit. The output in the figure is partial output from router R1. The full command output from this router is as follows: Îďý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďňďňďňď÷ řĐ®±˝»­­ ×Ü î÷

᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷

Ô·˛µ ×Ü

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł

Ô·˛µ ˝±«˛¬

ďňďňďňď

ďňďňďňď

çďç

đ¨čđđđđđđí đ¨ÜëÜÚ

î

íňíňíňí

íňíňíňí

ë

řÜŇß÷ đ¨čđđđđđđî đ¨íççđ

ď

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷

© 2009 Cisco Systems, Inc.

Ô·˛µ ×Ü

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł

ëňđňđňđ

ďňďňďňď

ďçěë

đ¨čđđđđđđî đ¨ßßěč

ëňđňđňđ

íňíňíňí

ç

ęňđňđňđ

ďňďňďňď

ďçěę

řÜŇß÷ đ¨čđđđđđđď đ¨éßéđ đ¨čđđđđđđî đ¨ßéěç

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-119

ęňđňđňđ

íňíňíňí

ç

řÜŇß÷ đ¨čđđđđđđď đ¨ŰßíÚ

ďîňđňđňđ

íňíňíňí

ç

řÜŇß÷ đ¨čđđđđđđď đ¨Úęîě

᫬»® Ô·˛µ ͬż¬»­ řß®»ż ď÷

Ô·˛µ ×Ü

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł

Ô·˛µ ˝±«˛¬

ďňďňďňď

ďňďňďňď

ďçěę

đ¨čđđđđđđë đ¨ÜÜßę

î

îňîňîňî

îňîňîňî

ďđ

đ¨čđđđđđđç đ¨ęěÜÜ

ě

íňíňíňí

íňíňíňí

çíđ

đ¨čđđđđđđę đ¨ßďěÝ

î

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż ď÷

Ô·˛µ ×Ü

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł

ěňđňđňđ

ďňďňďňď

ďçěé

đ¨čđđđđđđî đ¨çççđ

ěňđňđňđ

íňíňíňí

çďď

đ¨čđđđđđđď đ¨ŰŢÚë

ďîňđňđňđ

ďňďňďňď

çďí

đ¨čđđđđđđď đ¨ŢÚîî

ďîňđňđňđ

íňíňíňí

çíď

đ¨čđđđđđđď đ¨Úęîě

Router R3 considers itself an ABR, because it has a link to Area 0 (the virtual link). As a result, it generates a summary LSA for 12.0.0.0 into area 1 and area 0, which you can see when you issue the show ip ospf database summary command on router R3. Îíý­¸±© ·° ±­°ş Ľż¬żľż­» ­«łłż®§ ďîňđňđňđ

ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü říňíňíňí÷ řĐ®±˝»­­ ×Ü î÷

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷

ÔÍ żą»ć ďééç Ń°¬·±˛­ć řұ ĚŃÍ󽿰żľ·´·¬§ô ÜÝ÷ ÔÍ Ě§°»ć Í«łłż®§ Ô·˛µ­řŇ»¬©±®µ÷ Ô·˛µ ͬż¬» ×Üć ďîňđňđňđ ř­«łłż®§ Ň»¬©±®µ Ň«łľ»®÷ ßĽŞ»®¬·­·˛ą ᫬»®ć íňíňíňí ÔÍ Í»Ż Ň«łľ»®ć čđđđđđđď ݸ»˝µ­«łć đ¨Úęîě Ô»˛ą¬¸ć îč Ň»¬©±®µ Óż­µć ńč ĚŃÍć đ

Ó»¬®·˝ć ďđ

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż ď÷

3-120

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

ÔÍ żą»ć ďéęę Ń°¬·±˛­ć řұ ĚŃÍ󽿰żľ·´·¬§ô ÜÝ÷ ÔÍ Ě§°»ć Í«łłż®§ Ô·˛µ­řŇ»¬©±®µ÷ Ô·˛µ ͬż¬» ×Üć ďîňđňđňđ ř­«łłż®§ Ň»¬©±®µ Ň«łľ»®÷ ßĽŞ»®¬·­·˛ą ᫬»®ć ďňďňďňď ÔÍ Í»Ż Ň«łľ»®ć čđđđđđđď ݸ»˝µ­«łć đ¨ŢÚîî Ô»˛ą¬¸ć îč Ň»¬©±®µ Óż­µć ńč ĚŃÍć đ

Ó»¬®·˝ć éë

ÔÍ żą»ć ďéčď Ń°¬·±˛­ć řұ ĚŃÍ󽿰żľ·´·¬§ô ÜÝ÷ ÔÍ Ě§°»ć Í«łłż®§ Ô·˛µ­řŇ»¬©±®µ÷ Ô·˛µ ͬż¬» ×Üć ďîňđňđňđ ř­«łłż®§ Ň»¬©±®µ Ň«łľ»®÷ ßĽŞ»®¬·­·˛ą ᫬»®ć íňíňíňí ÔÍ Í»Ż Ň«łľ»®ć čđđđđđđď ݸ»˝µ­«łć đ¨Úęîě Ô»˛ą¬¸ć îč Ň»¬©±®µ Óż­µć ńč ĚŃÍć đ

© 2009 Cisco Systems, Inc.

Ó»¬®·˝ć ďđ

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-121

The show ip route Command Îďý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ ďéîňíďňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ ďéîňíďňîňđ ĹďďđńďëęíĂ Ş·ż ďđňďňďňďô đđćďîćíëô Úż­¬Ű¬¸»®˛»¬đńđ ďéîňíďňďňđ ĹďďđńéčîĂ Ş·ż ďđňďňďňďô đđćďîćíëô Úż­¬Ű¬¸»®˛»¬đńđ ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ ďđňîđđňîđđňďíńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ ďđňďňíňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđ ďđňďňîňđńîě ĹďďđńéčîĂ Ş·ż ďđňďňíňěô đđćďîćíëô Í»®·ż´đńđńđ ďđňďňďňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďđňďňđňđńîě ĹďďđńéčîĂ Ş·ż ďđňďňďňďô đđćďîćíéô Úż­¬Ű¬¸»®˛»¬đńđ Űî ďđňîëěňđňđńîě ĹďďđńëđĂ Ş·ż ďđňďňďňďô đđćďîćíéô Úż­¬Ű¬¸»®˛»¬đńđ

Ń ×ß Ń ×ß Ý Ý Ń Ý Ń Ń

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-34

The show ip route command example in this figure depicts both external type routes (O E2) and interarea (O IA) routes. The last entry (O E2) is an external route (from the ASBR, via the ABR). The two numbers in brackets, [110/50], are the administrative distance and the total cost of the route to a specific destination network. In this case, the administrative distance is set to the default of 110 for all OSPF routes, and the total cost of the route has been calculated as 50.

3-122

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Interpreting the Routing Table: Types of Routes Router Designator

O

OSPF intra-area (router LSA) and network LSA

O IA

OSPF interarea (summary LSA)

Description Networks from within the area of the router Advertised by means of router LSA and the network LSAs Networks from outside the area of the router, but within the OSPF autonomous system Advertised by means of summary LSAs

O E1

Type 1 external routes

Networks outside of the autonomous system of the router

O E2

Type 2 external routes

Advertised by means of external LSAs

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-35

The figure defines each of the routing table descriptors for OSPF. The router and network LSAs describe the details within an area. The routing table reflects this link-state information with a designation of “O,” meaning that the route is OSPF intra-area. When an ABR receives summary LSAs, it adds them to its LSDB and regenerates them into the local area. When an ABR receives external LSAs, it adds them to its LSDB and floods them into the area. The internal routers then assimilate the information into their databases. Summary LSAs appear in the routing table as IA (interarea routes). External LSAs appear in the routing table marked as external type 1 (E1) or external type 2 (E2) routes. The SPF algorithm is then run against the LSDB to build the SPF tree. The SPF tree is used to determine the best paths. The order in which the best paths are calculated is as follows: 1. All routers calculate the best paths to destinations within their areas (intra-area) and add these entries to the routing table. These are the type 1 and type 2 LSAs, which are noted in the routing table with a routing designator of “O” (OSPF intra-area). 2. All routers calculate the best paths to the other areas within the internetwork. These best paths are the interarea route entries, or type 3 and type 4 LSAs, and are noted with a routing designator of O IA (interarea). 3. All routers (except those that are in a form of stub area) calculate the best paths to the external AS (type 5) destinations; these are noted with either an O E1 or an O E2 route designator, depending on the configuration. At this point, a router can communicate with any network within or outside the OSPF AS.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-123

Calculating Costs for E1 and E2 Routes

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-36

The cost of an external route varies depending on the external type configured on the ASBR. The following external packet types can be configured: E1: Type O E1 external routes calculate the cost by adding the external cost to the internal cost of each link that the packet crosses. Use this type when there are multiple ASBRs advertising an external route to the same AS to avoid suboptimal routing. E2 (default): The external cost of O E2 packet routes is always the external cost only. Use this type if only one ASBR is advertising an external route to the AS. The figure in the slide shows the network diagram with two ASBRs (routers R5 and R6). Both ASBR routers are sending external routes into the OSPF autonomous system. External routes can be sent as E1 or as E2. The router R1 receives the same external routes from routers R2 and R3. In the example in the slide, the path from R1 to R6 is shorter than the path from R1 to R5. If external routes are received as E2 routes (default setting), then the cost is the same regardless of the topology in the OSPF domain, which means there will be suboptimal routing. If external routes are received as E1 routes, then the cost is different, because the internal OSPF cost is added to the external cost. The routing is optimal and the shortest path is selected to the destination.

3-124

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

OSPF LSDB Overload Protection Excessive LSAs generated by other routers can drain local router resources. This feature can limit the processing of non-self-generated LSAs for a defined OSPF process. Only a warning message can be sent or neighbors can be ignored.

Îďř˝±˛ş·ąó®±«¬»®÷ý łż¨ó´­ż ďîđđđ

Limit the number of non-self-generated LSAs.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-37

If other routers are misconfigured, causing, for example, a large number of prefixes to be redistributed, large numbers of LSAs can be generated. These excessive LSAs can drain local CPU and memory resources. OSPF LSDB overload protection can be configured to protect against this issue with Cisco IOS Release 12.3(7)T and later releases (and some specific versions of earlier releases) by using the max-lsa command. When this feature is enabled, the router keeps count of the number of received (non-selfgenerated) LSAs that it keeps in its LSDB. An error message is logged when this number reaches a configured threshold number, and a notification is sent when it exceeds the threshold number. If the LSA count still exceeds the threshold after one minute, the OSPF process takes down all adjacencies and clears the OSPF database; this is called the “ignore” state. In the ignore state, no OSPF packets are sent or received by interfaces that belong to that OSPF process. The OSPF process remains in the ignore state for the time that is defined by the ignore-time parameter. The ignore-count parameter defines the maximum number of times that the OSPF process can consecutively enter the ignore state before remaining permanently down and requiring manual intervention. If the OSPF process remains normal for the time that is defined by the reset-time parameter, the ignore state counter is reset to 0. For more details about the max-lsa command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-125

Limiting Adjacencies in OSPF with the PassiveInterface Command This topic describes how routing advertisements can be controlled using the passive-interface command.

OSPF Passive Interface The sending and receiving of routing updates is disabled. The specified interface address appears as a stub network in the OSPF domain.

Îďý

Îîý

®±«¬»® ±­°ş ďđ𠲻¬©±®µ ďçîňďęčňđňđ đňđňîëëňîëë ż®»ż ď ˛»¬©±®µ ďđňîňđňđ đňđňîëëňîëë ż®»ż ď °ż­­·Ş»ó·˛¬»®şż˝» Ľ»şż«´¬ ˛± °ż­­·Ş»ó·˛¬»®şż˝» Í»®·ż´đńđńď

®±«¬»® ±­°ş ďđ𠲻¬©±®µ ďçîňďęčňđňđ đňđňîëëňîëë ż®»ż ď ˛»¬©±®µ ďđňîňđňđ đňđňîëëňîëë ż®»ż ď ˛»¬©±®µ ďđňíňđňđ đňđňîëëňîëë ż®»ż ď °ż­­·Ş»ó·˛¬»®şż˝» ۬¸»®˛»¬đ

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-38

To prevent other routers on a local network from learning about routes dynamically, you can keep routing update messages from being sent through a router interface. This feature applies to all IP-based routing protocols except BGP. OSPF behaves somewhat differently. In OSPF, the interface address you specify as passive appears as a stub network in the OSPF domain. OSPF routing information is neither sent nor received through the specified router interface. To disable the sending and receiving of OSPF routing updates on an interface, use the passiveinterface command in router configuration mode. Within ISPs and large enterprise networks, many of the distribution routers have more than 200 interfaces. Thus, a large number of LSAs can be flooded over the domain. The OSPF routing protocol can be configured on all interfaces, and the passive-interface command can be set on the interfaces where adjacency is not desired. In some networks, this means the coding of 100 or more passive interface statements. With the Default Passive Interface feature, this problem is solved by allowing all interfaces to be set as passive by default using a single passive-interface default command, then configuring individual interfaces where adjacencies are desired using the no passive-interface command. In the example in the slide, routers are configured for OSPF routing protocol. The configuration of routers R1 and R2 is observed, where the passive interface feature is configured.

3-126

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Router R1 has a set of interfaces that act as a stub network. LSAs are not received through these interfaces anyway and there is no need for LSAs to be sent from there either. The only interface that should participate in OSPF process is interface Serial0/0/1. The passive-interface default command is used on router R1, as it is easier to make all of the interfaces passive and just enable one or more, where OSPF LSAs can be sent and received. In our example in the slide, the no passive-interface Serial0/0/1 command is used to enable the propagation of LSAs on interface Serial0/0/1. Router R2 is slightly different. Only one interface is acting as a stub interface, where the propagation of LSAs should be stopped. The passive-interface Ethernet0 command is stopping the propagation of LSAs through interface Ethernet0 and other interfaces are normally processing OSPF LSAs. For more details about the passive-interface command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-127

Design Limitations of OSPF This topic describes the effects of using a non-contiguous backbone area, area 0, or area that does not connect to area 0.

Design Limitations of OSPF If more than one area is configured, one of these areas has be to be area 0, the backbone area. All areas must be connected to area 0. Area 0 must be contiguous.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-39

OSPF has special restrictions when multiple areas are involved throughout the OSPF autonomous system. If more than one area is configured, one of these areas has to be area 0. This is called the backbone area. When designing networks, it is good practice to start from core layer, which becomes area 0, and then expand into other areas later on. The backbone has to be at the center of all other areas and other areas have to be physically connected to the backbone. The main reason is that the OSPF expects all areas to inject routing information into the backbone, which distributes that information into other areas. In the figure in the slide, it is evident that all areas are directly connected to the backbone. In the rare situations in which a new area is introduced that cannot have a direct physical access to the backbone, a solution is required. Virtual links, discussed in the next section, must be configured in such case.

3-128

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Virtual Links as a Solution An extension to the backbone Carried by a nonbackbone area Cannot be created across a stub or NSSA area, or over unnumbered links Are used to: – Allow areas to connect to areas other than 0 – Repair a discontiguous area 0 (for example, if two companies merge and have separate backbone areas)

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-40

OSPF has a solution to extend the reach of the backbone across other areas. This solution is called the virtual link. It provides an extension to the OSPF backbone and allows a router to connect logically to the backbone even though there is no direct physical link. Between the two routers involved in the creation of the virtual-link, there is a non-backbone area. The routers at each end become part of the backbone and both act as ABRs. The virtual link relies on intra-area routing, and its stability is dependent on the stability of the underlying area. Virtual links cannot run through more than one area or over stub areas. They can only run through normal non-backbone areas. If a virtual link needs to be attached to the backbone across two non-backbone areas, then two virtual links are required: one virtual link to serve each area. Virtual links are used for two purposes: Linking an area that does not have a physical connection to the backbone Patching the backbone in case a discontinuity with area 0 occurs A good example of when virtual links might be required is when two companies merge that do not have a direct link between their backbone areas. A similar problem occurs when you add a non-backbone area to an OSPF network and the new area does not have a direct physical connection to the existing OSPF backbone area, area 0.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-129

OSPF Virtual Links and Solutions to NonContiguous Area Problems This topic describes OSPF virtual links, which are used to address the non-contiguous area issues, and how to configure these virtual links.

No Direct Physical Connection to Area 0 Area 20 added with no physical access to area 0 A virtual link provides a logical path to the backbone area The OSPF database treats the link between routers ABR1 and ABR2 as a direct link

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-41

All areas in an OSPF autonomous system must be physically connected to the backbone area (area 0). When this is not possible, you can use a virtual link to connect to the backbone through a non-backbone area. The area through which you configure the virtual link is known as a transit area and must have full routing information. In the example in the slide, area 20 is added to the existing OSPF topology. Because it has no direct physical link to the backbone area, area 0, a virtual link across non-backbone area 10 is created. In this case, the virtual link provides a logical path between area 20 and the backbone area. The OSPF database treats the virtual link between ABR1 and ABR2 as a direct link. For greater stability, the loopback interface is used as a router ID and virtual links are created using these loopback addresses.

3-130

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Discontiguous Area 0 Two companies merge without a direct link between them. Virtual links are used to connect the discontiguous areas 0. A logical link is built between routers ABR1 and ABR2. Virtual links are recommended for backup or temporary connections, too.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-42

The two-tiered area hierarchy of OSPF requires that all areas be directly connect to the backbone area, area 0, and that area 0 be contiguous. A virtual link is a link that allows discontiguous areas 0 to be connected, or that allows a disconnected area to be connected to area 0, via a transit area. The OSPF virtual link feature should be used only in very specific cases, for temporary connections or backup after a failure. Virtual links should not be used as a primary backbone design feature. Virtual links are part of the OSPF open standard and have been a part of Cisco IOS Software since Cisco IOS Release 10.0. In the figure in the slide, area 0 is discontiguous, because the two companies have merged and there is no direct link between their backbone areas. A logical link (virtual link) is built between the two ABRs, routers ABR1 and ABR2. This virtual link is similar to a standard OSPF adjacency. However, in a virtual link, the routers do not have to be directly attached to neighboring routers. The hello protocol works over virtual links as it does over standard links, in 10-second intervals. However, LSA updates work differently on virtual links. An LSA usually refreshes every 30 minutes; LSAs learned through a virtual link have the DoNotAge (DNA) option set, so that the LSA does not age out. This DNA technique is required to prevent excessive flooding over the virtual link.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-131

OSPF Virtual Link Configuration Configure a virtual link. The router ID of the remote router is used in the command.

ßŢÎďý

ßŢÎîý

®±«¬»® ±­°ş ďđ𠲻¬©±®µ ďéîňďęňđňđ đňđňîëëňîëë ż®»ż ď ˛»¬©±®µ ďđňđňđňđ đňîëëňîëëňîëë ż®»ż đ ż®»ż ď Ş·®¬«ż´ó´·˛µ ďđňîňîňî

®±«¬»® ±­°ş ďđ𠲻¬©±®µ ďéîňďęňđňđ đňđňîëëňîëë ż®»ż ď ˛»¬©±®µ ďđňđňđňđ đňîëëňîëëňîëë ż®»ż đ ż®»ż ď Ş·®¬«ż´ó´·˛µ ďđňďňďňď

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-43

You can use the area virtual-link command in router configuration mode, along with any necessary optional parameters, to define an OSPF virtual link. The configuration must be done on both sides of the virtual link and the area virtual-link command on each side must include the router ID of the far-end router. To find the router ID of the far-end router, use the show ip ospf command, show ip ospf interface command, or show ip protocol command on that remote router. In the figure in the slide, two companies have merged, and because there is no direct physical link, area 0 is discontiguous. A virtual link is used as a strategy to temporarily connect the Company 1 and Company 2 backbone areas, areas 0. Area 1 is used as the transit area. Router ABR1 builds a virtual link to router ABR2, and router ABR2 builds a virtual link to router ABR1. Each router points to the router ID of the other router. For more details about the area virtual-link command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

3-132

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Virtual Link Verification ßŢÎďý

­¸±© ·° ±­°ş Ş·®¬«ż´ó´·˛µ­ Verify the configuration of the virtual link.

ßŢÎďý ­¸±© ·° ±­°ş Ş·®¬« ż´ó´·˛µ­ Ę·®¬« ż´ Ô·˛µ ŃÍĐÚÁĘÔ𠬱 ®±«¬»® ďđňîňîňî ·­ «° Ϋ˛ ż­ Ľ»łż˛Ľ ˝· ®˝«·¬ ܱұ¬ßą » ÔÍß ż´´ ±©»Ľň Ě®ż˛­·¬ ż®»ż ďô Ş·ż · ˛¬»®şż˝» Í »®·ż´đńđń ďô ݱ­¬ ±ş «­·˛ą éčď Ě®ż˛­ł· ¬ Ü»´ż§ · ­ ď ­ »˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁ ĐŃ×ŇĚô Ě·ł»® · ˛¬»®Şż´­ ˝±˛ş· ą«®»Ľô Ř»´ ´± ďđô Ü» żĽ ěđô Éż·¬ ěđô 묮ż˛­ł ·¬ ë Ř»´´± Ľ«» ·˛ đđćđđćđé ߼¶ż˝»˛˝§ ͬż¬» ÚËÔÔ řŘ»´´± ­«°°® »­­»Ľ÷ ײĽ»¨ ďńî ô ®»¬®ż˛­ł·­­·±˛ Ż«»«» ´ »˛ą¬¸ đô ˛«łľ»® ±ş ®»¬®ż ˛­ł·­­·±˛ ď Ú·®­¬ đ¨đ řđ÷ńđ¨đřđ÷ Ň»¨¬ đ¨đřđ÷ńđ ¨đřđ÷ Ôż­¬ ®»¬® ż˛­ł·­­·±˛ ­˝ż˛ ´»˛ą¬¸ · ­ ďô łż¨·ł«ł ·­ ď Ôż­¬ ®»¬® ż˛­ł·­­·±˛ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­» ˝ © 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-44

You can use the show ip ospf virtual-links command to verify that the configured virtual link works properly. In the example in the slide, it is evident that the virtual link toward the neighboring router with the router ID 10.2.2.2 is up and area 1 is used as a transit area. The output shows also that interface Serial0/0/1 is used to form the virtual link as well as several OSPF timers. Other commands that are useful when troubleshooting virtual links are show ip ospf neighbor, show ip ospf database, and debug ip ospf adj. Routers across a virtual link become adjacent and exchange LSAs via the virtual link in a way that is similar to how they exchange LSAs over a physical link. Example output from the show ip ospf neighbor command follows: ßŢÎďý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü

Đ®·

ͬż¬»

Ü»żĽ Ě·ł»

ďđňîňîňî

đ

ÚËÔÔń

ó

ďđňîňîňî

đ

ÚËÔÔń

ó

ó đđćđđćíî

߼Ľ®»­­

ײ¬»®şż˝»

ďéîňďęňďňî

ŃÍĐÚÁĘÔđ

ďéîňďęňďňî

Í»®·ż´đńđńď

For more details about the show ip ospf virtual-links and show ip ospf neighbor commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-133

Virtual Link Verification in OSPF LSDB ßŢÎďý

­¸±© ·° ±­°ş Ľż¬żľż­» Verify the virtual link in the OSPF database.

ßŢÎďý ­¸±© ·° ±­°ş Ľż¬żľ ż­» ŃÍĐÚ Î±«¬»® © ·¬¸ × Ü řďđňďňďň ď÷ řĐ®±˝» ­­ ×Ü ďđđ÷ ᫬»® Ô·˛µ ͬż¬»­ řß ®»ż đ÷ Ô·˛µ ×Ü ˝±«˛¬ ďđňďň ďňď ďđňîň îňî

ßÜĘ Î±«¬»®

ßą»

ďđňďňďňď ďđňîňîňî

éďč ě

řÜŇß÷

Í»Żý

ݸ »˝µ­«ł

đ¨čđđđđđđî đ¨čđđđđđđď

đ¨ ďčçß đ¨ îçčđ

Ô·˛µ î ď

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬ »­ řß®»ż đ÷ 䱫¬° «¬ ±ł·¬¬»Ľâ

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-45

The show ip ospf database command shows the virtual link as one of the router links. The LSAs learned through the virtual link have the DoNotAge (DNA) option. An example output from the show ip ospf database router 10.2.2.2 command shows the information from router ABR2. The output of this show command for the virtual link LSA is as follows : ßŢÎďý­¸±© ·° ±­°ş Ľż¬żľż­» ®±«¬»® ďđňîňîňî

ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňďňďňď÷ řĐ®±˝»­­ ×Ü ďđđđ÷

᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷

᫬·˛ą Ţ·¬ Í»¬ ±˛ ¬¸·­ ÔÍß ÔÍ żą»ć ď řܱұ¬ßą»÷ Ń°¬·±˛­ć řұ ĚŃÍ󽿰żľ·´·¬§ô ÜÝ÷ ÔÍ Ě§°»ć ᫬»® Ô·˛µ­ Ô·˛µ ͬż¬» ×Üć ďđňîňîňî ßĽŞ»®¬·­·˛ą ᫬»®ć ďđňîňîňî ÔÍ Í»Ż Ň«łľ»®ć čđđđđđđí ݸ»˝µ­«łć đ¨číčđ Ô»˛ą¬¸ć ěč ß®»ż ޱ®Ľ»® ᫬»® Ň«łľ»® ±ş Ô·˛µ­ć î

Ô·˛µ ˝±˛˛»˝¬»Ľ ¬±ć ż Ę·®¬«ż´ Ô·˛µ řÔ·˛µ ×Ü÷ Ň»·ą¸ľ±®·˛ą ᫬»® ×Üć ďđňďňďňď 3-134

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

řÔ·˛µ Üż¬ż÷ ᫬»® ײ¬»®şż˝» żĽĽ®»­­ć ďéîňďęňďňî Ň«łľ»® ±ş ĚŃÍ ł»¬®·˝­ć đ ĚŃÍ đ Ó»¬®·˝­ć éčď

Ô·˛µ ˝±˛˛»˝¬»Ľ ¬±ć ż Ě®ż˛­·¬ Ň»¬©±®µ řÔ·˛µ ×Ü÷ Ü»­·ą˛ż¬»Ľ ᫬»® żĽĽ®»­­ć ďđňďňîňî řÔ·˛µ Üż¬ż÷ ᫬»® ײ¬»®şż˝» żĽĽ®»­­ć ďđňďňîňî Ň«łľ»® ±ş ĚŃÍ ł»¬®·˝­ć đ ĚŃÍ đ Ó»¬®·˝­ć ď

᫬»® Ô·˛µ ͬż¬»­ řß®»ż ď÷

᫬·˛ą Ţ·¬ Í»¬ ±˛ ¬¸·­ ÔÍß ÔÍ żą»ć ďęčč Ń°¬·±˛­ć řұ ĚŃÍ󽿰żľ·´·¬§ô ÜÝ÷ ÔÍ Ě§°»ć ᫬»® Ô·˛µ­ Ô·˛µ ͬż¬» ×Üć ďđňîňîňî ßĽŞ»®¬·­·˛ą ᫬»®ć ďđňîňîňî ÔÍ Í»Ż Ň«łľ»®ć čđđđđđđč ݸ»˝µ­«łć đ¨ÝÝčď Ô»˛ą¬¸ć ěč ß®»ż ޱ®Ľ»® ᫬»® Ę·®¬«ż´ Ô·˛µ ۲Ľ°±·˛¬ Ň«łľ»® ±ş Ô·˛µ­ć î

Ô·˛µ ˝±˛˛»˝¬»Ľ ¬±ć ż˛±¬¸»® ᫬»® ř°±·˛¬ó¬±ó°±·˛¬÷ řÔ·˛µ ×Ü÷ Ň»·ą¸ľ±®·˛ą ᫬»® ×Üć ďđňďňďňď řÔ·˛µ Üż¬ż÷ ᫬»® ײ¬»®şż˝» żĽĽ®»­­ć ďéîňďęňďňî Ň«łľ»® ±ş ĚŃÍ ł»¬®·˝­ć đ ĚŃÍ đ Ó»¬®·˝­ć éčď

Ô·˛µ ˝±˛˛»˝¬»Ľ ¬±ć ż ͬ«ľ Ň»¬©±®µ řÔ·˛µ ×Ü÷ Ň»¬©±®µń­«ľ˛»¬ ˛«łľ»®ć ďéîňďęňďňđ řÔ·˛µ Üż¬ż÷ Ň»¬©±®µ Óż­µć îëëňîëëňîëëňđ Ň«łľ»® ±ş ĚŃÍ ł»¬®·˝­ć đ ĚŃÍ đ Ó»¬®·˝­ć éčď

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-135

Changing the Cost Metric This topic explains how to change the cost metric from the default values.

OSPF Cost The cost, or metric, is an indication of the overhead to send packets over an interface. OSPF cost is used as the route selection criteria. Dijkstra’s algorithm determines the best path by adding all link costs along a path. OSPF cost is computed automatically. – Cost = 10 8 / Bandwidth (in b/s) – Bandwidth is specified on the interface with the bandwidth command. OSPF cost is recomputed after every bandwidth change.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-46

The OSPF cost is an indication of the overhead to send packets over an interface. OSPF cost is computed automatically for each interface assigned into an OSPF process using the following formula: cost = 108 / bandwidth (The bandwidth is specified on the interface with the bandwidth interface command.) The cost value is a 16-bit positive number between 1 and 65,535, where a lower value is a more desirable metric. For example, a 64-kb/s link gets a metric of 1562, while a T1 link gets a metric of 64. Cost is applied on all router link paths and route decisions are made on the total cost of a path. The metric is only relevant on an outbound path (route decisions are not made for inbound traffic). The OSPF cost is recomputed after every bandwidth change and Dijkstra’s algorithm determines the best path by adding all link costs along a path. On high bandwidth links (155 Mb/s and more), automatic cost assignment no longer works (it would result in all costs being equal to 1). On these links, OSPF costs must be set manually on each interface.

3-136

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Changing The Default OSPF Cost Îďř˝±˛ş·ąó·ş÷ý

·° ±­°ş ˝±­¬ ďđ Changes the OSPF cost on the specified interface to 10. Îîř˝±˛ş·ąó®±«¬»®÷ý

ż«¬±ó˝±­¬ ®»ş»®»˛˝»óľż˛Ľ©·Ľ¬¸ ďđđđđ Changes the reference bandwidth used to compute the default OSPF costs from 100 to 10000.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-47

In general, the OSPF cost in Cisco routers is calculated using the following formula: (100 Mb/s) / (bandwidth in Mb/s). However, the cost is calculated based on a maximum bandwidth of 100 Mb/s, which is a cost of 1. If you have faster interfaces, you may want to recalibrate the cost of 1 to a higher bandwidth. When you are using the bandwidth of the interface to determine OSPF cost, always remember to use the bandwidth interface command to define the bandwidth of the interface (in kb/s) accurately. The bandwidth command is the reference for calculating the cost. To override the automatically calculated default cost, manually define the cost using the ip ospf cost interface command on a per-interface basis. The cost value is an integer from 1 to 65,535. The lower the number, the better and more preferred the link. In the figure in the slide, the ip ospf cost 10 command manually defines the cost of the GE interface. In the example in the slide, interfaces that are faster than 100 Mb/s are being used (Gigabit Ethernet and Fast Ethernet). The automatic cost assignment is returning the value 1. For all faster links, a new reference value must be configured. Use the auto-cost command in router configuration mode on all routers in the network to ensure accurate route calculations. The reference-bandwidth value in the auto-cost command is a reference bandwidth in megabits per second. It ranges from 1 to 4,294,967, with a default value of 100. In the example in the slide, the reference-bandwidth value in router R2 is set to 10000. In this way, the cost of the Fast Ethernet link is changed to 100, while the Gigabit Ethernet link cost is changed to 10. Thus, the link costs are differentiated. For more details about the ip ospf cost and auto-cost commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-137

Summary This topic summarizes the key points that were discussed in this lesson.

Summary There are four router types: internal routers, backbone routers, ABRs, and ASBRs. The configuration of OSPF is a two-step process: – Define one or more OSPF processes in the router. – Define the interfaces that OSPF will run on. OSPF selects a router ID at startup time: – Define the router ID with the router-id command. – If you do not define the router ID, and there is a loopback interface, the highest IP address of the loopback interface is used. – If you do not define the router ID, and there is no loopback interface, the highest IP address of all active interfaces is used.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-48

Summary Use the show ip protocols, show ip route ospf, show ip ospf interface, show ip ospf, show ip ospf neighbor, and show ip ospf database commands to verify OSPF operation. There are 11 OSPF LSA types. The following are the most commonly used: Type 1 router, Type 2 network, Type 3 and 4 summary, Type 5 external, Type 7 external To prevent other routers on a local network from learning about routes dynamically, you can keep routing update messages from being sent through a router interface by using the passiveinterface command.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

3-138

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v1. 0— 3-49

© 2009 Cisco Systems, Inc.

Summary All OSPF areas must be connected to a backbone area, area 0, which must be contiguous. A virtual link allows discontiguous areas 0 to be connected, or a disconnected area to be connected to area 0 via a transit area. Virtual links should only be used for temporary connections or backup after a failure, not as a primary backbone design feature. The OSPF cost defaults to (100 Mb/s) / (bandwidth in megabits per second). The cost can be changed on a per-interface basis, and so can the reference bandwidth (100 Mb/s).

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1. 0— 3-50

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-139

3-140

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 5

Lab 3-1 Debrief Overview In Lab 3-1, students configure and verify OSPF to improve routing performance. First, a student uses OSPF to exchange routing information in order to achieve IP connectivity over the LAN interfaces. The student then establishes reachability and configures OSPF on the WAN segment. The OSPF interface network type should reflect the Frame Relay WAN segment representation. The student will configure OSPF over Frame Relay using the point-to-point and multipoint OSPF network types.

Objectives Upon completing this lesson, you will be able to implement and verify OSPF to improve routing performance. This ability includes being able to meet these objectives: Complete the lab overview and verification Describe a sample solution and alternatives

Lab Overview and Verification This topic describes the lab topology and key checkpoints used to create a solution and to start with the verification.

Lab Topology

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-2

The figure above presents the physical lab topology used for Lab 3-1: Configure and verify OSPF to improve routing performance. The topology uses 4 pod routers. Based on the topology, students will identify the required parameters and configure an OSPF routing protocol in order to establish Layer 3 reachability in the network.

3-142

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab Review: What Did You Accomplish? Task 1: Configure OSPF over LAN interfaces – What steps did you take to configure the OSPF routing protocol and advertise all of the specific IP subnets used in the network? – How can you change the configuration to prevent any network added to the router from being advertised? – How does this change the default OSPF DR and BDR selection on the LAN segment? Task 2: Configure OSPF over Frame Relay using the point-topoint OSPF network type – What must you change on router R3 to be able to add a WAN segment to the OSPF in the same area as the LAN segment? – What must you change on router R4 to be able to add a WAN segment to the OSPF in the same area as the LAN segment and where only the WAN segment subnet is advertised?

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1.0—3-3

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-143

Lab Review: What Did You Accomplish? (Cont.) Task 3: Configure OSPF over Frame Relay using the point-tomultipoint OSPF network type – How does the configuration reflect the Frame Relay multipoint network type when you include the WAN segment on router R1 into OSPF and enable OSPF adjacency over the serial interface towards routers R2 and R4? – How do you change the configuration to also advertise, from the major network, any networks that are added later? This is the OSPF configuration on routers R2 and R4, where the WAN segment towards router R1 is included in the OSPF.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-4

In the first task, you configured OSPF over LAN interfaces. You configured OSPF routing protocol and advertised all of the specific IP subnets used in the network. You then prevented any network added to the router from being advertised. In order to change the default OSPF DR and BDR selection on the LAN segment, you manipulated the OSPF router priority. In the second task, you configured OSPF over Frame Relay using the point-to-point OSPF network type. You added the WAN segment to the OSPF in the same area as the LAN segment. You then configured the OSPF routing protocol to advertise the WAN segment subnet only. In the third task, you configured OSPF over Frame Relay using the point-to-multipoint OSPF network type. You configured OSPF on the WAN segments on routers R2 and R4 toward router R1, reflecting the Frame Relay multipoint network type. You configured OSPF to advertise any networks from the major network that are added later.

3-144

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Verification Did you have enough information to create an implementation plan? Are the proper adjacencies established on the LAN segment? For how long are the adjacencies up? Do you see the proper OSPF routes in the IP routing table when comparing it to the OSPF database? Which router is the DR on the LAN segment between routers R1 and R3? Are the proper adjacencies established on the WAN segment between routers R3 and R4? For how long are the adjacencies up?

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1.0—3-5

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-145

Verification (Cont.) After enabling OSPF on the WAN segment, do you see the proper OSPF routes in the IP routing table when comparing it to the OSPF database? Are proper adjacencies established on the WAN segment between routers R1, R2, and R4 in your pod? For how long are the adjacencies up? After enabling OSPF on the WAN segment on routers R2 and R4, do you see the proper the OSPF routes in the IP routing table when comparing it to the OSPF database?

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-6

A common approach to verifying the implementation process for a routing protocol is to answer the following questions: Did you have enough information to create implementation plan? Are the proper adjacencies established on the LAN segment? For how long are the adjacencies up? Do you see the proper OSPF routes in the IP routing table when comparing the IP routing table to OSPF database? Which router is the DR on the LAN segment between routers R1 and R3? Are the proper adjacencies established on the WAN segment between routers R3 and R4? For how long are the adjacencies up? After enabling OSPF on the WAN segment, do you see the proper OSPF routes in the IP routing table when comparing the IP routing table to the OSPF database? Are the proper adjacencies established on the WAN segment between routers R1, R2, and R4 in your pod? For how long are the adjacencies up? After enabling OSPF on the WAN segment on routers R2 and R4, do you see the proper OSPF routes in the IP routing table when comparing the IP routing table to the OSPF database?

3-146

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Checkpoints Configure the OSPF routing protocol on LAN segment. Advertise only the specific subnets used in the network. Check for the DR on the LAN segment. Configure the OSPF routing protocol on the WAN segment between routers R3 and R4. Advertise only the specific subnets used in the network. Check for the correct OSPF network type on the WAN segments. Configure the OSPF routing protocol on the WAN segments between routers R1, R2, and R4. Check for the proper entries in the IP routing table.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-7

With different checkpoints, the network operator can verify for proper configuration. The following checkpoints are used for verification: Configure the OSPF routing protocol on the LAN segment. Advertise only the specific subnets used in the network. Check for the DR on the LAN segment. Configure the OSPF routing protocol on the WAN segment between routers R3 and R4. Advertise only the specific subnets used in the network. Check for the correct OSPF network type on the WAN segments. Configure the OSPF routing protocol on the WAN segments between routers R1, R2, and R4. Check for the proper entries in the IP routing table.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-147

Sample Solution and Alternatives This topic describes a sample solution and other alternatives.

Sample Solution Configure OSPF on the LAN segment and advertise only the specific subnets used in the network. Configure OSPF on the WAN segment between routers R3 and R4, and advertise only the specific subnets used in the network. Configure the OSPF routing protocol on the WAN segments between routers R1, R2, and R4.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-8

This sample solution includes implementation details and details for each task of the implementation plan. Different solutions are possible and the figure points out some of the details of a successful configuration. The proper implementation of OSPF configuration and verification to improve routing performance includes the following items: Configure OSPF on the LAN segment and advertise only the specific subnets used in the network. Configure OSPF on the WAN segment between router R3 and R4, and advertise only the specific subnets used in the network. Configure the OSPF routing protocol on the WAN segments between routers R1, R2, and R4.

3-148

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternative Solutions You can use several routing protocols to provide reachability in the network. Changing the routing protocol is not a realistic solution, though you can modify the existing solution. You can also fulfill the same requirements by reconfiguring to different Frame Relay types.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-9

You can use several routing protocols to provide reachability in the network. Changing the routing protocol is not a realistic solution as changing the routing protocol is not the case during fine tuning of the existing protocol. You can also fulfill the same requirements by reconfiguring to different Frame Relay types.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-149

Q and A Why is routing protocol selection important? How is a DR and BDR selection performed? How is OSPF enabled on a LAN segment? Is an OSPF network type important when enabling an OSPF on the WAN segment?

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-10

A routing protocol, with its metric and administrative distance, exchanges routing updates and populates its IP routing table, which is used for destination-based forwarding. Different routing protocols process routing updates in different ways. LAN links elect one router as the designated router (DR) and another as the backup designated router (BDR), to ensure that all of the routers on the same LAN have identical databases. The OSPF priority value is used to elect a DR and BDR. The router with the highest priority value is the DR. In case of a tie, the router with the highest router ID becomes the DR. The highest IP address on an active interface is normally used as the router ID, which can be manipulated by configuring an IP address on a loopback interface or using the router-id router configuration command. Once elected the DR passes its database to any new routers that come up. OSPF on a LAN segment is configured using the network command in OSPF router configuration mode with the network for that LAN segment. The router priority value can be added to the particular interface in order to manipulate DR and BDR election. It is important to specify the OSPF network type on the WAN segment. This is because the OSPF network type defines how the OSPF adjacencies will be established, as well as how OSPF routing packets will be propagated.

3-150

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary Configure OSPF on the LAN segment to advertise only specific subnets and to observe DR selection. Configure OSPF on the WAN segment to advertise only specific subnets. Configure OSPF on the WAN segment to advertise any additional networks from the major network, if added later.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1. 0— 3-11

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-151

3-152

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 6

Lab 3-2 Debrief Overview In Lab 3-2, students implement and verify OSPF multiarea routing. First, they define the backbone area, where the selected routers are configured for the OSPF backbone area. They then configure the remaining routers for nonbackbone normal areas, as there is no need to filter any subnets. They tune the OSPF configuration by manipulating the cost and router ID. They can perform additional optimization by suppressing routing updates.

Objectives Upon completing this lesson, you will be able to implement and verify OSPF multiarea routing. This ability includes being able to meet these objectives: Complete the lab overview and verification Describe a sample solution and alternatives

Lab Overview and Verification This topic describes lab topology and key checkpoints used to create a solution and to start with verification.

Lab Topology

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-2

The figure above presents the physical lab topology used for the Lab 3-2: Implement and Verify OSPF Multiarea Routing. The topology uses four pod routers and one backbone router. Based on this topology, students will divide the will be divided into more OSPF areas (backbone and nonbackbone) and apply the correct configuration to each router.

3-154

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab Review: What Did You Accomplish? Task 1: Configuring OSPF backbone area – What steps did you take to configure the OSPF routing protocol on a router belonging to the backbone area? Task 2: Configuring OSPF nonbackbone areas – What steps did you take to configure the OSPF routing protocol on routers belonging to different nonbackbone areas? Task 3: Tuning an OSPF operation – How can the default cost calculation be changed? – How can the router ID be changed? – How can you preserve CPU cycles on router R3 by eliminating the unnecessary OSPF traffic on a LAN segment?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-3

In the first task, you configured the OSPF backbone area, which means configuring routers in backbone area. Selections of the routers are members of the backbone area and the correct area type must be configured on each interface, which is part of the backbone area. In the second task, you configured the OSPF nonbackbone areas and configured the routers in the nonbackbone areas. Some routers represent a nonbackbone area where they have all or just a few interfaces in a nonbackbone area. In the third task, you must tune OSPF operation. You must change the default cost calculation to manipulate the path for the packets. You must change the router ID to manipulate the DR and BDR selection. Finally, you must configure some interfaces as passive to preserve the CPU cycles on the router by eliminating unnecessary OSPF traffic.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-based Solution

3-155

Verification Did you have enough information to create an implementation plan? Is adjacency in area 0 between routers R1 and BBR2 established? Is the IP routing table populated with correct OSPF routes? Is adjacency established between the routers of nonbackbone areas? Is the IP routing table populated with the correct OSPF routes? How is a change in cost calculation done? What is the router ID of router R1? Is the IP routing table populated with the correct OSPF routes? Did router R3 stop trying to set up an OSPF adjacency via the LAN segment? © 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-4

To verify the implementation of OSPF, answer the following questions: Did you have enough information to create an implementation plan? Is an adjacency in area 0 between routers R1 and BBR2 established? Is the IP routing table populated with the correct OSPF routes? Is an adjacency established between routers in the nonbackbone areas? Is the IP routing table populated with the correct OSPF routes? How is a cost calculation change done? What is the router ID of router R1? Is the IP routing table populated with the correct OSPF routes? Did router R3 stop trying to set up an OSPF adjacency via the LAN segment?

3-156

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Checkpoints Configure OSPF in area 0. Check for adjacencies in area 0 between routers R1 and BBR2. Check the IP routing table for the proper OSPF routes. Configure OSPF in nonbackbone areas Check if an adjacency is established between the routers of nonbackbone areas. Check the IP routing table for proper OSPF routes. Change the cost calculation. Manipulate the OSPF router ID of router R1. Check the IP routing table for the proper OSPF routes. Check that router R3 stopped trying to set up an OSPF adjacency via the LAN segment.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-5

With different checkpoints, the network operator can verify for proper configuration. The following checkpoints are used for verification: Configure OSPF in area 0. Check for adjacencies in area 0 between routers R1 and BBR2. Check the IP routing table for the proper OSPF routes. Configure the OSPF in nonbackbone areas. Check if an adjacency is established between the routers of nonbackbone areas. Check the IP routing table for the proper OSPF routes. Change the cost calculation. Manipulate the OSPF router ID of router R1. Check the IP routing table for proper OSPF routes. Check if router R3 has stopped trying to set up an OSPF adjacency via the LAN segment.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-based Solution

3-157

Sample Solution and Alternatives This topic describes sample solution and other alternatives.

Sample Solution Configure OSPF for backbone and nonbackbone areas. Select the correct OSPF network type for each WAN segment. Change the default cost calculation to manipulate the path selection and change the router ID to manipulate DR and BDR selection. Configure the passive interface to suppress routing traffic and preserve CPU cycles on router R3.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-6

The sample solution includes the implementation details and details for each task of the implementation plan. Different solutions are possible and the figure points out a few details of successful configuration. The proper implementation and verification of OSPF multiarea routing includes the following details: Configure OSPF for the backbone and nonbackbone areas. Select the correct OSPF network type for each WAN segment. Change the default cost calculation to manipulate the path selection and change the router ID to manipulate the DR and BDR selection. Configure the passive interface to suppress routing traffic and preserve CPU cycles on router R3.

3-158

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternative Solutions You can design different backbone and nonbackbone areas, for which nonbackbone areas can be non-standard in order to reduce the number of routing updates. You can configure a different IP adress on the loopback interface to manipulate the router ID. Because changing the routing protocol is not a realistic solution, you can configure static and default routes.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-7

In order to create a similar configuration, you can design different backbone and nonbackbone areas, for which the nonbackbone areas can be non-standard in order to reduce the number of routing updates. You can configure a different IP address on the loopback interface to manipulate the router ID. Because it is not realistic to change the routing protocol, you can configure static and default routes, in order to provide reachability while still preserving OSPF as a routing protocol in the network.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-based Solution

3-159

Q and A What is the purpose of backbone and nonbackbone areas? How can a default cost calculation be changed? Why is the router ID important? How does a passive interface work in an OSPF routing protocol?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-8

OSPF segments the network in different areas to optimize the routing in the whole network. All nonbackbone areas must be connected to backbone area. Routing information is exchanged between the areas in a controlled way; summarization takes place on the area border routers limiting the number of updates that the small changes locally in the area are not triggering the topology change recalculation in other areas. You can change the default cost calculation by changing the cost per neighbor in OSPF routing process configuration mode. The OSPF routing protocol adds the router ID to all OSPF updates and is visible in the OSPF topology database. The router ID inside the update packet defines the source of the update packets and must be unique in the network. When a passive interface is enabled, the sending and receiving of routing updates is disabled. The specified interface address appears as a stub network in the OSPF domain.

3-160

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary Configure OSPF for a backbone area. Configure OSPF for a nonbackbone area. Tune OSPF operation by changing how default cost calculation is performed; you can change the cost calculation by changing the router ID and configuring a passive interface. Doing this preserves CPU cycles by eliminating unnecessary OSPF traffic on the LAN segment.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1. 0—3-9

Implementing a Scalable Multiarea Network OSPF-based Solution

3-161

3-162

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 7

Configuring and Verifying OSPF Route Summarization Overview Scalability, improved CPU and memory utilization, and the ability to mix small routers with large routers are all benefits of using proper route summarization techniques. A key feature of Open Shortest Path First (OSPF) protocol is the ability to summarize routes at area and autonomous system (AS) boundaries. Route summarization is important, because it reduces the amount of OSPF link-state advertisement (LSA) flooding and the sizes of link-state databases (LSDBs) and routing tables, which also reduces memory and CPU utilization on the routers. The OSPF network can scale to very large sizes, in part because of route summarization. Default routes reduce routing table size, and also reduce memory and CPU utilization. OSPF injects a default route unconditionally or based on the presence of the default route inside the routing table. This lesson defines the different types of route summarization and describes the configuration commands for each type. It also describes the benefits of default routes and how to configure them.

Objectives Upon completing this lesson, you will be able to describe the procedure for configuring OSPF route summarization for interarea and external routes. This ability includes being able to meet these objectives: Describe OSPF route summarization Implement OSPF route summarization Identify the benefits of a default route in OSPF Use a default route in OSPF

OSPF Route Summarization This topic describes the functions of interarea route summarization and external route summarization.

Summarization Networks are normally translated into type 3 LSAs in other areas. Route summarization is the consolidation of advertised addresses. – On ABR, summarize type 3 LSAs – On ASBR, summarize type 5 LSAs A good addressing plan is required. A drawback is the possibility of suboptimal routing.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-2

Route summarization is a key to scalability in OSPF. Route summarization helps solve two major problems: large routing tables and frequent LSA flooding throughout the AS. Every time a route disappears in one area, routers in other areas also get involved in shortest-path calculation. In order to reduce the size of the area database, you can configure summarization on an area boundary or autonomous system boundary. Normally, type 1 and type 2 LSAs are generated inside each area and translated into type 3 LSAs in other areas. With route summarization, the ABR or ASBR routers consolidate multiple routes into a single advertisement. ABR routers summarize type 3 LSAs and ASBR routers summarize type 5 LSAs. Instead of advertising many specific prefixes, advertise only one summary prefix. If the OSPF design includes many Area Border Routers (ABRs) or Autonomous System Boundary Routers, suboptimal routing is possible. This is one of the drawbacks of summarization. Of course, route summarization requires a good addressing plan—an assignment of subnets and addresses that is based on the OSPF area structure and lends itself to aggregation at the OSPF area borders. Note

3-164

Recall that summary LSAs (type 3) and external LSAs (type 5) do not, by default, contain summarized routes.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Benefits of Route Summarization Minimizes the number of routing table entries Localizes the impact of a topology change Reduces LSA flooding and saves CPU resources

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-3

Route summarization directly affects the amount of bandwidth, CPU power, and memory resources that the OSPF routing process consumes. Without route summarization, every specific-link LSA is propagated into the OSPF backbone and beyond, causing unnecessary network traffic and router overhead. With route summarization, only the summarized routes are propagated into the backbone (area 0). Summarization prevents every router from having to rerun the SPF algorithm, increases the stability of the network, and reduces unnecessary LSA flooding. Also, if a network link fails, the topology change is not propagated into the backbone (and other areas by way of the backbone). Specific-link LSA flooding outside the area does not occur.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-165

Implementing OSPF Route Summarization This topic describes how to configure route summarization in OSPF.

Interarea Route Summarization A summary route will be generated if at least one subnet within the area falls in the summary address range. A summarized route metric will be equal to the lowest cost of all subnets within the summary address range. Only for the summary routes of connected areas: – The ABR creates a route to Null 0 to avoid loops.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-4

The summarization of internal routes can be done only by ABRs (router R2 in the figure above). Without summarization, all of the prefixes from an area are passed into the backbone as type 3 interarea routes. When summarization is enabled, the ABR intercepts this process and instead injects a single type 3 LSA, which describes the summary route into the backbone. Multiple routes inside the area are summarized. A summary route is generated if at least one subnet within the area falls in the summary address range and the summarized route metric is equal to the lowest cost of all the subnets within the summary address range. Interarea summarization can only be done for the intra-area routes of connected areas, and the ABR creates a route to Null0 in order to avoid loops in the absence of more specific routes.

3-166

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Using Route Summarization Interarea summary link carries a mask One or more entries can represent several subnets

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-5

OSPF is a classless routing protocol, which means that it carries subnet mask information along with route information. Therefore, OSPF supports multiple subnet masks for the same major network, which is known as variable-length subnet masking (VLSM). OSPF also supports discontiguous subnets, because the subnet masks are part of the LSDB. Some older distance vector protocols do not support VLSM or discontiguous subnets. For example, if a major network crosses the boundaries of an OSPF and an older distance vector routing protocol domain, then VLSM information redistributed into the older routing distance vector protocol is lost, and the static routes may have to be configured manually there. Network numbers in areas should be assigned contiguously to ensure that these addresses can be summarized into a minimal number of summary addresses. For example, in the figure above, the list of 12 networks in the routing table of the ABR can be summarized into two summary address advertisements. The block of addresses from 172.16.8.0 through 172.16.15.0/24 can be summarized using 172.16.8.0/21, and the block from 172.16.16.0 through 172.16.19.0/24 can be summarized using 172.16.16.0/22.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-167

Configure Interarea Route Summarization Configures type 3 summarization on ABRs

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-6

OSPF does not perform automatic summarization on major network boundaries. To consolidate and summarize routes at an area boundary, use the area range command in router configuration mode. The ABR will summarize routes for a specific area before injecting them into a different area via the backbone as type 3 summary LSAs. Before summarization is possible, OSPF must be configured with the contiguous IP addressing implementation. Without proper addressing implementation, effective summarization cannot be done. Cisco IOS Software creates a summary route to interface Null0 when manual summarization is configured, to prevent routing loops. For example, if the summarizing router receives a packet to an unknown subnet that is part of the summarized range, the packet matches the summary route based on the longest match. The packet is forwarded to the Null0 interface (in other words, it is dropped), which prevents the router from forwarding the packet to a default route and possibly creating a routing loop. For more details about the area range command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

3-168

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Route Summarization Configuration Example at the ABR

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-7

The figure shows that route summarization can occur in both directions: from a nonbackbone area to area 0 and from area 0 to a nonbackbone area. In the example, the router ABR configuration specifies the following summarization: area 0 range 172.16.96.0 255.255.224.0: Identifies area 0 as the area containing the range of networks to be summarized into area 1. Router “ABR” summarizes the range of subnets from 172.16.96.0 to 172.16.127.0 into one range: 172.16.96.0 255.255.224.0. area 1 range 172.16.64.0 255.255.224.0: Identifies area 1 as the area containing the range of networks to be summarized into area 0. Router “ABR” summarizes the range of subnets from 172.16.64.0 to 172.16.95.0 into one range: 172.16.64.0 255.255.224.0. Note

© 2009 Cisco Systems, Inc.

Depending on your network topology, you may not want to summarize area 0 networks into other areas. For example, if you have more than one ABR between a nonbackbone area and the backbone area, sending a summary (type 3) LSA with the explicit network information into an area ensures that the shortest path to destinations outside the area is selected. If you summarize the addresses, suboptimal path selection may occur.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-169

External Route Summarization Summarization can be used for external routes: – on an AS boundary for type 5 LSAs (redistributed routes) – on an NSSA ABR for type 5 translated from type 7 A summary route to Null 0 will be created for each summary range

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-8

Summarization can also be used for external routes. Each route that is redistributed into OSPF from other protocols is advertised individually with an external link state advertisement (LSA). To reduce the size of the OSPF link state database, you can configure a summary for external routes. Summarization of external routes can be done on the ASBR for type 5 LSAs (redistributed routes) before injecting them into the OSPF domain. Summarization of external routes can be done by the ABR in not-so-stubby areas (NSSAs) as well, where the ABR router creates type 5 summary routes from type 7 external routes. Without summarization, all of the redistributed external prefixes from external autonomous system are passed into the OSPF area. A summary route to Null0 is created automatically for each summary range.

3-170

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Configure External Route Summarization Configures type 5 summarization of redistributed routes on ASBRs

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-9

To create aggregate addresses for OSPF at an autonomous system boundary, use the summaryaddress command in router configuration mode. ASBR will summarize external routes before injecting them into the OSPF domain as type 5 external LSAs. You must implement contiguous IP addressing before you can achieve optimal summarization. Sometimes only type 3 or type 5 summarization is required, but in large OSPF networks, both configurations can be applied. For more details about the summary-address command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-171

Route Summarization Configuration Example at ASBR

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-10

The figure depicts route summarization on the ASBR. On the right-hand side, an external AS running EIGRP has its routes redistributed into OSPF. Because of the contiguous subnet block in the external EIGRP network, it is possible to summarize the 32 different subnets into one summarized route. Instead of 32 external type 5 LSAs flooding into the OSPF network, there is only one. Note

3-172

EIGRP routes must also be redistributed into OSPF in this example; redistribution is covered in the “Implement an IPv4-Based Redistribution Solution” module.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Benefits of a Default Route in OSPF Occasionally, you will be required to configure OSPF to advertise a default route into the route’s AS. This topic describes the benefits of a default route in OSPF.

Default Routes in OSPF A default route is injected into OSPF as an external type 5 LSA. Default route distribution is not on by default. Benefits of default routes include: – A smaller routing table – Fewer resources used in the router

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-11

To be able to perform routing from an OSPF autonomous system toward external networks or toward the Internet, you must either know all of the destination networks or create a default route. In order to learn all of the destinations, you can either create a number of static routes, or configure redistribution. But the most scalable and optimized way is through the use of a default route. The benefits of a default route include the following: Smaller routing table Fewer resources and less CPU power needed; no need to recalculate the SPF algorithm if one or more networks fail The figure shows how OSPF injects a default route into a standard area (the different types of areas are described in the next lesson). Any OSPF router can originate the default routes injected into a standard area, but the OSPF routers by default do not generate a default route into the OSPF domain. In order for OSPF to generate a default route, you must run a configuration command. A default route shows up in the OSPF database as a type 5 external LSA. Here is an example of how it looks in the database: ̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł

Ěżą

đňđňđňđ ďçčňďňďňď

ęđď

đ¨čđđđđđđď

đ¨ÜđÜč

đ

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-173

Using a Default Route in OSPF This topic describes how to configure a default route injection into OSPF.

Configure OSPF Default Route The first command allows the ASBR to originate a type 5 default route if it has the gateway of last resort. The second command allows the ASBR to originate a type 5 default route even if there is no gateway of last resort (optional). Use the route map to define a dependency on any condition inside the route map (optional).

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-12

To generate a default external route into an OSPF routing domain, use the default-information originate router configuration command, as shown in the figure above. There are two ways to advertise a default route into a standard area: Advertise 0.0.0.0/0 into the OSPF domain when the advertising router already has a default route. Use the default-information originate command to allow the ASBR to originate a type 5 default route inside the OSPD autonomous system. You can also use different keywords in the configuration command, order to configure dependency on IP routing table entries: Advertise 0.0.0.0/0, regardless of whether the advertising router already has a default route. The second method can be accomplished by adding the keyword always to the defaultinformation originate command, as shown in the figure in the slide. Whenever you use the redistribute or the default-information router configuration command to redistribute routes into an OSPF routing domain, the Cisco IOS software automatically becomes an Autonomous System Boundary Router (ASBR). However, an ASBR by default does not generate a default route into the OSPF routing domain. The software must still have a default route for itself before it generates one, except when you have specified the always keyword. You can also use a route map to define dependency on any condition inside the route map. For more details about the default-information originate command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

3-174

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Default Route Configuration Example

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-13

In the figure above, an OSPF network is multihomed to dual Internet service providers (ISPs). Because the number of prefixes in the ISPs routing table is high, it makes no sense to redistribute them into an OSPF autonomous system. The default route is sent into the OSPF AS in order to provide connectivity to the external destinations. In the customer design, ISP A is preferred, and ISP B is used as a backup. In order to define the priority, the optional metric parameter has been used to establish a preference for the default route to ISP A. In the example above, router A’s default route has a metric of 10 attached to it. It is preferred over the default route advertised by router R2, which has a metric of 100. Because the default-information originate command is used without the optional parameter always, the default route must exist inside the IP routing table in order to advertise the default route into an OSPF domain. Both routers in the figure above have a default route statically defined. For more details about the default-information originate command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-175

Summary This topic summarizes the key points that were discussed in this lesson.

Summary Route summarization improves CPU utilization, reduces LSA flooding, and reduces routing table sizes. The area range command is used to summarize at the ABR. The summary-address command is used to summarize at the ASBR. Default routes can be used in OSPF to prevent the need for a specific route to each destination network. The benefits include a much smaller routing table and an LSDB with complete reachability. OSPF uses the default-information originate command to inject a default route.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

3-176

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v1. 0— 3-14

© 2009 Cisco Systems, Inc.

Lesson 8

Lab 3-3 Debrief Overview In Lab 3-3, students configure and verify OSPF route summarization for interarea and external routes. After each student performs an initial examination of the OSPF routing information and an IP routing table, it is evident that optimization is required. Each must optimize an OSPF link-state database and, consequently, an IP routing table, in order to make them smaller with summarization. Once students summarize internal routes, they can do additional work for external routes, as well.

Objectives Upon completing this lesson, you will be able to configure and verify OSPF route summarization for interarea and external routes. This ability includes being able to meet these objectives: Complete the lab overview and verification Describe a sample solution and alternatives

Lab Overview and Verification This topic describes the lab topology and key checkpoints used to create a solution and to start with the verification.

Lab Topology

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-2

The figure in this slide presents the physical the lab topology used for the Lab 3-3: Configure and verify OSPF route summarization for interarea and external routes. The topology uses four pod routers and one backbone router. Based on this topology and the OSPF routing protocol configuration, several internal and external OSPF routes exist in the IP routing tables in all of the routers in different areas. The configuration will be optimized by using summarization.

3-178

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab Review: What Did You Accomplish? Task 1: Examining OSPF Routing Information – How can you verify the operation of an OSPF routing protocol? – What can you see by observing the OSPF neighbors, OSPF database, OSPF interfaces, and IP routing table? Task 2: Summarizing OSPF Internal Routes – How are internal routes defined? – How is summarization performed for internal routes? Task 3: Summarizing OSPF External Routes – Where do you apply the summarization of external routes? – How many sources of external routes exist in the lab?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-3

In the first task, you will examine the operation of an OSPF routing protocol by checking the information from the OSPF neighbors, OSPF database, and OSPF interfaces. You will also examine the IP routing table. Your pod is preconfigured with the OSPF configuration and the proper configuration steps are needed in order to optimize the size of the OSPF database and IP routing table. In the second task, summarization of the OSPF internal routes is required. An OSPF can differentiate between internal and external (redistributed) routes. When applying internal route summarization, the summarization command is applied from the direction (area) where the routes are received. In the third task, OSPF summarization of OSPF external routes is required. Summarization of external routes should be done as close to the source as possible. Preferably, the router redistributing the routes should summarize them as well. There is only one source of external routers. Keep in mind that the summarization command is different than the one for the internal routes, because external routes have no concept of areas.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-179

Verification Did you have enough information to create an implementation plan? Were you able to define the OSPF topology and the content of an IP routing table? Does the summary route exist on the routers in areas 3 and 24? Does the OSPF link-state database contain relevant information? Is the routing information for the external networks 192.168.x.0/24 presented as summary information in the OSPF link-state database and, therefore, in the IP routing tables on relevant routers? Do all the routers have IP connectivity to the pod external networks?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-4

To verify the configuration of OSPF, answer the following questions: Did you have enough information to create an implementation plan? Were you able to define the OSPF topology and the content of an IP routing table? Does the summary route exist on the routers in areas 3 and 24? Does the OSPF link-state database contain relevant information? Is the routing information for the external networks 192.168.x.0/24 presented as summary information in the OSPF link-state database and, therefore, in the IP routing tables on relevant routers? Do all the routers have IP connectivity to the pod external networks?

3-180

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Checkpoints Examine the IP routing information exchanged by routers configured with the OSPF routing protocol. Define the internal and external routes. Configure the summarization of internal routes. Check if the adjacencies are up. Check if the IP routing tables and OSPF databases reflect the summarization. Configure the summarization of external routes. Check if the adjacencies are up. Check if the IP routing tables and OSPF databases reflect the summarization.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-5

With different checkpoints, the network operator can verify for proper configuration. The following checkpoints are used for verification: Examine the IP routing information exchanged by routers configured with OSPF routing protocol. Define internal and external routes. Configure the summarization of internal routes. Check if the adjacencies are up. Check if the IP routing tables and OSPF databases reflect the summarization. Configure the summarization of external routes. Check if the adjacencies are up. Check if the IP routing tables and OSPF databases reflect the summarization.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-181

Sample Solution and Alternatives This topic describes a sample solution and other alternatives.

A Sample Solution The OSPF topology and OSPF operation are verified, along with the IP routing table, which shows the OSPF routes. Internal summarization is configured for areas 3 and 24 on ABRs. External summarization is configured on an ASBR router, which redistributes external routes into the OSPF routing protocol.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-6

The sample solution in the slide includes implementation details and details for each task of the implementation plan. Different solutions are possible; the figure points out a few details of a successful configuration. The proper implementation of route redistribution between multiple IP routing protocols include the following details: The OSPF topology and OSPF operation are verified, along with the IP routing table, which shows OSPF routes. Internal summarization summarizes the internal OSPF routes sent into area 3 and area 24. ABR routers are configured for summarization. External summarization is configured on an ASBR router, which redistributes the external routes into the OSPF routing protocol.

3-182

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternative Solutions Change the area types in order to optimize the amount of OSPF information entering into a specific area. Because changing the routing protocol is not a realistic solution, static and default routes can be configured together with route filtering.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-7

The OSPF routing protocol supports different area types, which prevent the insertion of all OSPF routing updates. By selecting different OSPF area types, the network operator can filter network announcements on the ABR or ASBR routers and ensure that only a summary or default route is entered. In order to provide reachability in the network, several routing protocols can be used. Changing the routing protocol is not a realistic solution, because system administrators will not redesign and reconfigure the whole network for another routing protocol. Sometimes reconfiguration is not even possible, because not all devices may support the desired routing protocol. On the other hand, static and default routes can be configured together with route filtering. Filtering prevents routing updates from being exchanged, and static and default routes provide reachability. Static routes are not a scalable solution.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-183

Q and A How can you verify OSPF routes in an IP routing table? How can you verify the OSPF topology and operation? Where do you perform summarization into areas 3 and 24? Where do you perform summarization of external routes? Is there a difference between summarization of internal and external routes? How can you verify summarization results?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-8

You can verify the IP routing table by observing the contents of the IP routing table for the OSPF routes. You can verify the operation of the OSPF routing protocol by checking the information of OSPF neighbors, the OSPF database, OSPF interfaces, and the IP routing table. You should configure summarization of internal routes on ABR routers. You should configure summarization of external routes as close as possible to the source of redistribution, preferably on the ASBR routers. You use different configuration commands to configure external and internal summarization. You can verify summarization results by observing the IP routing table and OSPF database.

3-184

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary IP routing information exchanged by routers configured with OSPF routing protocol was examined. You can optimize the OSPF link-state database and consequently the IP routing table by using summarization to making the database smaller. OSPF routing operation can be further optimized by summarizing OSPF external routes.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1. 0—3-9

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-185

3-186

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 9

Configuring and Verifying OSPF Special Area Types Overview The Open Shortest Path First (OSPF) protocol defines several special-case area types, including stub areas, totally stubby areas, and not-so-stubby areas (NSSAs). The purpose of all three types of stub areas is to inject default routes into an area so that external and summary link-state advertisements (LSAs) are not flooded in. Stub areas are designed to reduce the amount of flooding, the link-state database (LSDB) size, and the routing table size in routers within the area. Network designers should always consider using stub area techniques when building networks. Stub area techniques improve performance in OSPF networks and allow the network to scale to significantly larger sizes. This lesson discusses OSPF area types and how to configure them.

Objectives Upon completing this lesson, you will be able to implement and verify different OSPF area types, including the stub area, totally stubby area, NSSA, and totally NSSA. This ability includes being able to meet these objectives: Determine OSPF area types Define and implement a stub area Define and implement a totally stubby area Interpret routing tables for OSPF area types Define and implement a not-so-stubby area and totally NSSA in OSPF Verify all OSPF area types

OSPF Area Types This topic describes the OSPF area types.

OSPF Area Types and Structure OSPF is based on a two-level hierarchical area structure Each area has its own topology database Area Types – Backbone area: Connects all other areas – Normal area: Contains all of the internal and external routing information – Stub area: Contains internal and area routing information, but not external routing information – Totally stubby area: Contains area routing information only; Cisco proprietary – Not-so-stubby area: Contains area and external routing information

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-2

OSPF is based on a two-level hierarchical area structure. The hierarchy defines backbone and nonbackbone areas. Each area has its own topology, which is invisible from outside the area. A router belonging to several areas (called an Area Border Router, or ABR) has several topology databases. All areas have to be connected to a backbone area or linked to it with a virtual link. The backbone area has to be contiguous. A nonbackbone area can be discontiguous. Area types are: Backbone area: Connects all other areas Normal area: Contains all internal and external routing information Stub area: Contains internal and area routing information, but not external routing information Totally stubby area: Contains area routing information only; Cisco proprietary Not-so-stubby area (NSSA): Contains area and external routing information

3-188

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Types of Areas

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-3

The characteristics assigned to an area control the type of route information that it receives. The possible area types are as follows: Normal area: This default area accepts link updates, route summaries, and external routes. Backbone area (transit area): The backbone area is the central entity to which all other areas connect. The backbone area is labeled area 0. All other areas connect to this area to exchange and route information. The OSPF backbone includes all the properties of a standard OSPF area. Stub area: This area does not accept information about routes external to the autonomous system (AS), such as routes from non-OSPF sources. If routers need to route to networks outside the AS, they use a default route, noted as 0.0.0.0. Stub areas cannot contain autonomous system boundary routers (ASBRs) (except that ABRs may also be ASBRs). Totally stubby area: This area does not accept external AS routes or summary routes from other areas internal to the AS. If the router needs to send a packet to a network external to the area, it sends the packet using a default route. Totally stubby areas cannot contain ASBRs (except that ABRs may also be ASBRs). NSSA: NSSA is an addendum to the OSPF RFC. This area defines a special LSA type 7. An NSSA offers benefits that are similar to those of a stub area or totally stubby area. However, NSSAs allow ASBRs, which is prohibited in a stub area.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-189

OSPF Router and LSA Types ABR is generating Summary LSAs ASBR is generating External LSAs Summary and External LSAs can be blocked and default route is sent instead

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-4

The OSPF defines three main router types: Internal router: This type of router resides inside any area and is a member of one area only. Area Border Router (ABR): This type of router that is a member of more than one area. As a border router, it has the ability to control routing traffic from one area to another. Different types of LSAs are exchanged between areas. ABRs can transmit these LSAs, or block them and send default routes instead. Autonomous System Boundary Router (ASBR): This type of router is used to insert external routing information from another non-OSPF autonomous system. ASBR routers generate External LSAs, which can be blocked by ABR routers. OSPF routers are able to generate and send the following six types of LSAs: Router Link (LSA type 1), Network Link (LSA type 2), Network Summary (LSA type 3), ASBR Summary (LSA type 4), External (LSA type 5), and NSSA External (LSA type 7).

3-190

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Stub and Totally Stub Area Rules An area can be stub or totally stub if: There is one ABR or more All routers that are members of the stub area are configured as stub routers There is no ASBR in the area The area is not an area 0 No virtual links go through the area

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-5

Stub and totally stubby areas do not carry any external routes, known as type 5 LSAs. An area can be qualified as a stub or totally stubby area if it has the following characteristics: There is either a single exit point from that area, or, if there are multiple exits, one or more ABRs inject a default into the stub area and suboptimal routing paths are acceptable. Routing to other areas or autonomous systems could take a suboptimal path to reach the destination by exiting the area at a point that is farther from the destination than other exit points. All OSPF routers inside the stub area, including ABRs and internal routers, must be configured as stub routers before they can become neighbors and exchange routing information. There is no ASBR inside the area. The area is not the backbone area, area 0. The area is not needed as a transit area for virtual links. Recall that a virtual link is a link that allows an area to connect to the backbone via a transit area. Virtual links are generally used for temporary connections or backup after a failure; they should not be considered as part of the primary OSPF design.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-191

Defining and Implementing a Stub Area This topic defines OSPF stub areas and describes how to configure them.

OSPF Stub Areas External LSAs are stopped. The default route is advertised into the stub area by the ABR.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-6

Configuring a stub area reduces the size of the LSDB inside the area, resulting in reduced memory requirements for routers in that area. External network LSAs (type 5), such as those redistributed from other routing protocols into OSPF, are not permitted to flood into a stub area. Routing from these areas to the outside is based on a default route (0.0.0.0). If a packet is addressed to a network that is not in the routing table of an internal router, the router automatically forwards the packet to the ABR, which sends a 0.0.0.0 LSA. Forwarding the packet to the ABR allows routers within the stub to reduce the size of their routing tables, because a single default route replaces many external routes. A stub area is typically created when a hub-and-spoke topology is used, with each spoke being a stub area, such as a branch office. In this case, the branch office does not need to know about every network at the headquarters site, because it can use a default route to reach the networks.

3-192

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Stub Area Configuration Îîř˝±˛ş·ąó®±«¬»®÷ý

ż®»ż î ­¬«ľ This command turns on stub area networking. Configure all routers in the stub area as stub routers. ßŢÎř˝±˛ş·ąó®±«¬»®÷ý

ż®»ż î ­¬«ľ ż®»ż î Ľ»şż«´¬ó˝±­¬ ďđ This command defines the cost of a default route sent into the stub area (default is 1); defining the cost is optional.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-7

Once you have gathered all the required information for an implementation plan, you must complete the following tasks to configure OSPF stub areas: Configure all routers in the stub area as stub routers Configure the cost for the default route on an ABR router (optional) To configure an area as a stub, all routers inside the area must be configured as stub routers. The area stub router configuration mode command is used to define an area as a stub area. By default, the ABR will advertise a default route with a cost of 1. You can change the cost of the default route by using the area default-cost command. You only use this command on Area Border Routers (ABRs) attached to stub areas or NSSAs. The default-cost option provides the metric for the summary default route generated by the ABR into the stub area. For more details about the area stub and area default-cost commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-193

OSPF Stub Area Configuration Example

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-8

Area 2 in the figure in this slide is defined as the stub area. No routes from the external AS are forwarded into the stub area. The last line in each configuration (area 2 stub) defines the stub area. Router ABR automatically advertises 0.0.0.0 (the default route) with a default cost metric of 1 into the stub area. Each router in the stub area must be configured with the area stub command. The hello packet exchanged between OSPF routers contains a stub area flag that must match on neighboring routers. The area 2 stub command must be enabled on all routers in the stub, so that they all have the stub flag set; they can then become neighbors and exchange routing information. The routes that appear in the routing table of router R2 are as follows: Intra-area routes, which are designated with an O in the routing table The default route and interarea routes, which are both designated with an IA in the routing table The default route is also denoted with an asterisk (O *IA) Configuration of the router ABR includes the area 2 default-cost 10 command, which changes the default value of the cost for default routes from 1 to 10.

3-194

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Defining and Implementing a Totally Stubby Area This topic defines OSPF totally stubby areas and describes how to configure them.

OSPF Totally Stubby Areas External and Summary LSAs are stopped The default route is sent instead Cisco proprietary feature

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-9

The totally stubby area technique is a Cisco proprietary enhancement that further reduces the number of routes in the routing table. A totally stubby area is a stub area that blocks external type 5 LSAs as well as summary type 3 and type 4 LSAs (interarea routes) from entering the area. Because it blocks these routes, a totally stubby area recognizes only intra-area routes and the default route of 0.0.0.0. ABRs inject the default summary link 0.0.0.0 into the totally stubby area. Each router picks the closest ABR as a gateway to everything outside the area. Totally stubby areas minimize routing information further than stub areas and increase the stability and scalability of OSPF internetworks. Using totally stubby areas is typically a better solution than using stub areas, as long as the ABR is a Cisco router.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-195

Totally Stubby Area Configuration Îîř˝±˛ş·ąó®±«¬»®÷ý

ż®»ż î ­¬«ľ This command turns on stub area networking Configure all routers in the stub area as stub routers ßŢÎř˝±˛ş·ąó®±«¬»®÷ý

ż®»ż î ­¬«ľ ˛±ó­«łłż®§ ż®»ż î Ľ»şż«´¬ó˝±­¬ ďđ First command defines the totally stubby area on the ABR router Second command defines the cost of a default route sent into the totally stubby area (default is 1); defining the cost is optional

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-10

Once you have gathered all the required information for an implementation plan, you must complete the following tasks to configure OSPF totally stubby areas: Configure all routers in stub areas as stub routers Configure the ABR router as a totally stubby router Configure the cost of the default route on the ABR router, if desired To configure an area as totally stubby, you must configure all routers inside the area as stub routers. The area stub router configuration mode command defines an area as a stub area. Additionally, the ABR router must be configured for totally stubby functionality. Run the area stub command with the no-summary keyword on the ABR router to configure it as totally stubby. By default, the ABR will advertise a default route with a cost of 1. You can change the cost of the default route by using the area default-cost command. For more details about the area stub and area default-cost commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

3-196

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Totally Stubby Configuration Example Router R2 is the preferred ABR

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-11

Example: Totally Stubby Configuration The figure in this slide shows an example of a totally stubby area configuration. All routes advertised into area 1 (from area 0 and the external AS) default to 0.0.0.0. The default route cost is set to 5 on router R2 and to 10 on router R4. Both default routes are advertised into area 1. However, the default route from router R2 is advertised with a lower cost. This makes routes through R2 preferable even if the internal cost from router R3 to router R4 is the same as the internal cost from router R3 to router R2. Notice that router R3 requires the area 1 stub command, yet the no-summary extension is not required. Only ABRs use the no-summary extension to keep summary LSAs from being propagated into the stub area. Note

© 2009 Cisco Systems, Inc.

Remember that all routers in a stub or totally stubby area must be configured as stub routers. An OSPF adjacency will not form between stub and nonstub routers.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-197

Interpreting Routing Tables for OSPF Area Types This topic interprets information shown on routing tables for stub areas and totally stubby areas.

Routing Table in a Normal Area

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-12

The figure shows how the routing table might look for an OSPF router in a standard area without a stub or totally stubby configuration. Intra-area, interarea, and external routes are all maintained in a standard area.

3-198

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Routing Table in a Stub Area Use the area 1 stub command to configure a stub area.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-13

The figure in this slide shows how the same routing table looks if the area is configured as a stub area. Intra-area and interarea routes are all maintained. In a stub area, ABR routers block external LSAs, and external routes are not visible in the routing table but accessible via the intra-area default route. ABR inserts an intra-area default route instead of forwarding external LSAs into the stub area.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-199

Routing Table in a Stub Area with Summarization Use the area 1 stub and area 1 range commands.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-14

The figure in this slide shows how the same routing table looks if stub area functionality is used and summarization is performed on each ABR. External LSAs are blocked by the ABR routers, which also perform summarization. The intra-area and summarized interarea routes are all maintained in the routing tables of stub area routers. External routes are not visible in the routing tables for each stub area, but are accessible via the intra-area default routes for that stub area.

3-200

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Routing Table in a Totally Stubby Area Use the area 1 stub command on all internal routers. Use the area 1 stub no-summary command on the ABRs.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-15

The figure in this slide shows how the same routing table looks if the area is configured as a totally stubby area. Notice that routers in the totally stubby area have the smallest routing tables of all the configurations you have seen so far. Intra-area routes are maintained. Interarea and external routes are not visible in the routing tables for each stub area, but are accessible via the intra-area default routes for that stub area. ABR routers block interarea and external LSAs and insert the default routes instead.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-201

Defining and Implementing a Not-So-Stubby-Area and Totally NSSA in OSPF This topic defines OSPF not-so-stubby areas (NSSAs) and describes how to configure them.

OSPF Not-So-Stubby Areas (NSSAs) NSSA breaks stub area rules ASBR is allowed inside LSA type 7 sent by ASBR

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ABR converts LSA type 7 to LSA type 5 ABR sends the default route into NSSA instead of external (LSA type 5) routes

ROUTE v1. 0— 3-16

The OSPF NSSA feature is described by RFC 3101 and was first introduced in Cisco IOS Software Release 11.2. It is a nonproprietary extension of the existing stub area feature that allows the injection of external routes in a limited fashion into the stub area. Redistribution into an NSSA creates a special type of LSA known as a type 7 LSA, which can exist only in an NSSA. An NSSA ASBR (router ASBR1 in the figure in this slide) generates this LSA, and an NSSA ABR translates it into a type 5 LSA, which gets propagated into the OSPF domain. Type 7 LSAs have a propagate (P) bit in the LSA header to prevent propagation loops between the NSSA and the backbone area. The NSSA retains the other stub area features; the ABR sends a default route into the NSSA instead of external routes from other ASBRs (for example from ASBR2 in the figure in this slide). The type 7 LSA is described in the routing table as an O N2 or O N1 (N means NSSA). N1 means that the metric is calculated like external type 1; N2 means that the metric is calculated like external type 2. The default is O N2. Note

3-202

The external type 1 (E1) metric adds external and internal costs together to reflect the whole cost to the destination. The external type 2 (E2) metric takes only the external cost, which is reflected in the OSPF cost.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

OSPF Totally NSSA Areas ABR is blocking Type 3, 4, 5 LSAs ABR is sending the default route into the NSSA instead This is a Cisco proprietary feature

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-17

The OSPF totally NSSA feature is an extension to the NSSA feature like the totally stubby feature is an extension to the stub area feature. It is a Cisco proprietary feature that blocks type 3, 4, and 5 LSAs. A single default route replaces both inbound-external (type 5) LSAs and summary (type 3 and 4) LSAs in the totally NSSA area. The ABRs for the totally NSSA area must be configured to prevent the flooding of summary routes for other areas into the NSSA area. Only ABR routers control the propagation of type 3 LSAs from the backbone. If ABR router is configured on any other routers in the area, it will have no effect at all.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-203

Totally NSSA Area Configuration Îîř˝±˛ş·ąó®±«¬»®÷ý

ż®»ż î ˛­­ż This command turns on NSSA area networking Set on all routers in the NSSA area ßŢÎř˝±˛ş·ąó®±«¬»®÷ý

ż®»ż î ˛­­ż ˛±ó­«łłż®§ ż®»ż î Ľ»şż«´¬ó˝±­¬ ďđ The first command defines the totally NSSA area on ABRs The second command defines the cost of a default route sent into the NSSA area (default is 1)

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-18

Once all the required information is defined, you must complete the following tasks to configure OSPF totally NSSAs: Configure all routers in the NSSA area as NSSA routers Configure the ABR as totally not-so-stubby (for configuration of the totally NSSA feature only) Configure the cost for the default route on the ABR router (optional). Note

Default cost of the default route is 1

To configure an area as an NSSA, you must configure all routers inside the area for NSSA functionality. The area nssa router configuration mode command is used to define each router in the NSSA area as not-so-stubby. Each ABR router must be configured for NSSA, too. Note

Remember that all routers in the NSSA must be configured with the area nssa command in order to form adjacencies.

Totally NSSA functionality requires one more step; you must configure each ABR router for totally NSSA functionality. The area nssa command with the no-summary keyword at the end is used to define the ABR router as a totally not-so-stubby. By default, the ABR will advertise a default route with a cost of 1. You can change the cost of the default route by using the area default-cost command. For more details about the area nssa and area default-cost commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

3-204

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

NSSA Configuration Example

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-19

In the figure in this slide, router ASBR is the Autonomous System Boundary Router (ASBR) that is redistributing Routing Information Protocol (RIP) routes into area 1, the NSSA. Router ABR is the NSSA Area Border Router (ABR). This router converts LSA type 7 into type 5 for advertisement into the backbone area 0. Router ABR is also configured to summarize the type 5 LSAs that originate from the RIP network: The 172.16.0.0 subnets will be summarized to 172.16.0.0/16 and advertised into area 0. To cause router “ABR” (the NSSA ABR) to generate an O *N2 default route (O *N2 0.0.0.0/0) into the NSSA, use the area nssa command with the default-information-originate option on router R2. For more details about the area nssa command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-205

Totally NSSA Configuration Example

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-20

In the figure, the ABR router is using the area 1 nssa no-summary command. This command works the same as the totally stubby technique. A single default route replaces both inboundexternal (type 5) LSAs and summary (type 3 and 4) LSAs into the area. The NSSA ABR, which is router “ABR,” automatically generates the O *N2 default route into the NSSA area with the no-summary option configured at the ABR, so the defaultinformation-originate option is not required. All other routers in the NSSA area only require the area 1 nssa command. The totally not-so-stubby configuration is a Cisco proprietary feature like the totally stubby configuration.

3-206

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Example of Different Areas

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-21

The figure in this slide shows different area types as follows: Normal area accepts link updates, summaries, and external routes. Stub area does not accept external LSAs. Totally Stubby area does not accept summary or external LSAs. NSSA area does not accept external LSAs, but allows ASBR. Totally NSSA area does not accept summary or external LSAs, but allows ASBR.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-207

Verifying All OSPF Area Types This topic describes how to verify all types of OSPF stub areas.

show Commands for Stub and NSSA Îďý

­¸±© ·° ±­°ş Displays which areas are normal, stub, or NSSA Îďý

­¸±© ·° ±­°ş Ľż¬żľż­» Displays the details of the LSAs Îďý

­¸±© ·° ±­°ş Ľż¬żľż­» ˛­­żó»¨¬»®˛ż´ Displays the details of each LSA type 7 update in the database Îďý

­¸±© ·° ®±«¬» Displays all routes © 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-22

The show commands in the figure are used to display information about all of the types of stub areas that may be configured.

3-208

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary There are several OSPF area types: normal, backbone, stub, totally stubby, NSSA, and totally NSSA. Use the area area-id stub command to define an area as stubby. Use the area area-id stub command with the no-summary keyword on the ABR only to define an area as totally stubby. For stub areas, external routes are not visible in the routing table, but are accessible via the intra-area default route. For totally stubby areas, interarea and external routes are not visible in the routing table, but are accessible via the intra-area default route. Use the area area-id nssa command to define an area as NSSA. Use the show ip ospf, show ip ospf database, and show ip route commands to verify all types of stub areas. Use the show ip ospf database nssa-external command to display details of type 7 LSAs. © 2009 Cis co S yst em s, Inc. A ll rights reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1. 0— 3-23

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-209

3-210

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 10

Lab 3-4 Debrief Overview In Lab 3-4, students configure and verify OSPF special area types. After performing an initial examination of OSPF, the routing information, and the IP routing table, they discover that the routers in each OSPF area are announcing their own subnets and external routes are included in OSPF. In order to minimize the OSPF routing information in area 24, students convert the area into an OSPF stub area. The results do not meet expectations, so students perform additional optimization by converting the area into a totally-stub area. At the same time, students must reduce OSPF information in area 3, as well, by converting area 3 into a totally not-so-stubby area (NSSA).

Objectives Upon completing this lesson, you will be able to configure and verify the OSPF special area types. This ability includes being able to meet these objectives: Complete the lab overview and verification Describe a sample solution and alternatives

Lab Overview and Verification This topic describes lab topology and key checkpoints used to create a solution and to start with the verification.

Lab Topology

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-2

The figure in the slide presents the physical lab topology used for Lab 3-4: Configure and verify OSPF special area types. The topology uses four pod routers and one backbone router. Based on this topology and the OSPF routing protocol configuration, several internal and external OSPF routes exist in the IP routing table in all routers in the different areas. Optimization is required to make the IP routing tables smaller. One of the solutions is to change the area types, which will limit the amount of information exchanged between the areas and replace many updates with a summary route.

3-212

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab Review: What Did You Accomplish? Task 1: Examining OSPF Routing Information – How can you verify the operation of an OSPF routing protocol? – What you can see by observing OSPF neighbors, the OSPF database, OSPF interfaces, and the IP routing table? Task 2: Optimizing OSPF Routing for Area 24 – What steps are required to restrict OSPF from announcing information about OSPF external routers, while preserving the insertion of internal routes from other areas? Task 3: Minimizing OSPF Information in Area 24 – What steps are also required to restrict OSPF from announcing information about OSPF internal routers from other OSPF areas?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1. 0—3-3

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-213

Lab Review: What Did You Accomplish? (Cont.) Task 4: Reducing OSPF Information in Area 3 – What steps are required to minimize the sizes of the OSPF link-state database and IP routing table on a router inside the area in such a way that only information about the area announced routes (internal or external) is allowed and redistribution of external routes is preserved.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-4

In the first task, you examine OSPF routing information. Your pod is preconfigured with the OSPF configuration. The steps you must follow in order to optimize the OSPF routing protocol are in the following tasks. In the second task, you configure the optimization for OSPF Routing in area 24. Optimization prevents OSPF from announcing information about the OSPF external routers while preserving the insertion of the internal routes from other areas. You do this by configuring a stub area. In the third task, you minimize the OSPF information in area 24. You must optimize the IP routing table by preventing OSPF from announcing information about the OSPF internal routers from other OSPF areas. You do this by configuring a totally-stubby area. In the fourth task, you must reduce the size of the OSPF link-state database and IP routing table on the router inside area 3. You must allow only information about the routes announced by the area (internal and external). At the same time, you must preserve the redistribution of external routes. You do this by configuring a totally not-so-stubby area (totally NSSA).

3-214

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Verification Did you have enough information to create an implementation plan? Were you able to define the OSPF topology and content of the IP routing table? After task 2, were external routes from other areas are suppressed and internal routes, while internal routes remained in the IP routing table and were injectable? After task 3, were external and internal routes from other areas suppressed? After task 4, were external and internal routes from other areas prevented from being injected, while redistribution of external routes was allowed?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-5

To verify the implementation process for configuring OSPF operations, answer the following questions: Did you have enough information to create an implementation plan? Were you able to define the OSPF topology and content of the IP routing table? After task 2, were external routes from other areas are suppressed and internal routes, while internal routes remained in the IP routing table and were injectable? After task 3, were external and internal routes from other areas suppressed? After task 4, were external and internal routes from other areas prevented from being injected, while redistribution of external routes was allowed?

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-215

Checkpoints Examine the IP routing information exchanged by routers configured with the OSPF routing protocol. Change the area type to suppress external routes from other areas to be injected. Check the IP routing table and OSPF database for verification. Change the area type to suppress external and internal routes from other areas to be injected. Check the IP routing table and OSPF database for verification. Change the area type to suppress external and internal routes but allow the injection of external routes into the area. Check the IP routing table and OSPF database for verification.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-6

With different checkpoints, the network operator can verify for proper configuration. The following checkpoints are used for verification: Examine the IP routing information exchanged by routers configured with the OSPF routing protocol. Change the area type to suppress external routes from other areas to be injected. Check the IP routing table and OSPF database for verification. Change the area type to suppress external and internal routes from other areas to be injected. Check the IP routing table and OSPF database for verification. Change the area type to suppress external and internal routes but allow injection of external routes into the area. Check the IP routing table and OSPF database for verification.

3-216

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Sample Solution and Alternatives This topic describes a sample solution and other alternatives.

A Sample Solution The IP routing table is verified for OSPF routes. The existing configuration of the area type for area 24 has been changed from normal to stub and then to totally-stubby in order to manipulate the insertion of routes into the area. The existing configuration for area 3 has been changed to a totally not-so-stubby (NSSA) area in order to manipulate the insertion of routes into the area.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-7

A sample solution includes implementation details and details for each task of the implementation plan. Different solutions are possible; the figure in the slide points out a few details of a successful configuration. Proper implementation of route redistribution between multiple IP routing protocols includes the following details: The IP routing table is verified for OSPF routes. The configuration of the area type for area 24 has been changed from normal to stub and then to totally-stubby in order to manipulate the insertion of routes into the area. The configuration for area 3 has been changed to a totally not-so-stubby area (totally NSSA) in order to manipulate the insertion of routes into the area.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-217

Alternative Solutions Summarization and filtering can be used in order to manipulate the insertion of routes into a specific area. Because changing the routing protocol is not a realistic solution, you can implement static and default routes with filtering instead.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-8

In order to decrease the size of the routing table and to prevent the insertion of routes, you can use summarization together with the filtering of routes. In order to provide reachability in the network, you can use several routing protocols. Changing the routing protocol is not a realistic solution, as the network system administrators will not redesign and reconfigure the whole network for another routing protocol. Sometimes reconfiguration is not even possible, because not all devices may support the desired routing protocol. Instead, static and default routes can be configured together with route filtering. Filtering prevents routing updates from being exchanged, and the static and default routes provide reachability. Static routes are not a scalable solution.

3-218

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q and A How you can verify OSPF routes and the OSPF topology? What can you change in OSPF to manipulate which routes are inserted into an area? Which OSPF area type suppresses external routes from other areas to be inserted? Which OSPF area type suppresses external and internal routes from other areas to be inserted? Which area type suppresses external routes from other areas to be inserted, but allows redistribution of external routes? Which area type suppresses external and internal routes from other areas to be inserted, but allows redistribution of external routes?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-9

You can verify the IP routing table by observing the contents of the IP routing table for OSPF routes. You can verify the operation of the OSPF routing protocol by checking the information of OSPF neighbors, the OSPF database, OSPF interfaces, and the IP routing table. You can use summarization and OSPF area types to manipulate which routes are inserted into the area. The stub OSPF area type suppresses external routes from other areas to be inserted. The totally-stub OSPF area type suppresses external and internal routes from other areas to be inserted. The not-so-stubby (NSSA) OSPF area type suppresses external routes from other areas to be inserted, but allows redistribution of external routes. The totally NSSA OSPF area type suppresses external and internal routes from other areas to be inserted, but allows redistribution of external routes.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-219

Summary This topic summarizes the key points that were discussed in this lesson.

Summary The IP routing table provides information that can be used to verify the proper configuration of different OSPF area types. To optimize OSPF you must configure area 24 as an OSPF stub area. To minimize OSPF information in area 24, you must configure an OSPF totally-stub area. To reduce OSPF information in area 3, you must configure an OSPF totally not-so-stubby (NSSA) area.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

3-220

Implementing Cisco IP Routing (ROUTE) v1.0

RO UTE v 1.0—3-10

© 2009 Cisco Systems, Inc.

Lesson 11

Configuring and Verifying OSPF Authentication Overview You can prevent your router from receiving fraudulent route updates by configuring neighbor router authentication. You can configure Open Shortest Path First Protocol (OSPF) neighbor authentication (also called neighbor router authentication or route authentication) in such a way that routers can participate in routing based on predefined passwords. This lesson describes the two types of OSPF authentications, how to configure, and verify them.

Objectives Upon completing this lesson, you will be able to implement authentication in an OSPF network. This ability includes being able to meet these objectives: Define types of OSPF authentication Implement simple password authentication for OSPF Configure MD5 authentication for OSPF Troubleshoot authentication for OSPF

Types of OSPF Authentication This topic describes two types of authentication used in OSPF.

OSPF Authentication Types OSPF supports two types of authentication: – Simple password (or plaintext) authentication – MD5 authentication The router generates and checks every OSPF packet. The source of each routing update packet received is authenticated. Each participating neighbor must have the same key (password) configured.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-2

OSPF neighbor authentication (also called neighbor router authentication or route authentication) can be configured in such a way that routers participate in routing based on predefined passwords. Recall that once you have configured neighbor authentication on a router, the router authenticates the source of each routing update packet that it receives. It does this by exchanging an authenticating key (sometimes referred to as a password) that is known to both the sending and the receiving router. By default, OSPF is not using authentication, which means that routing exchanges over a network are not authenticated. OSPF supports two authentication methods: Simple password or plaintext authentication Message Digest 5 (MD5) authentication OSPF MD5 authentication includes a non-decreasing sequence number in each OSPF packet to protect against replay attacks.

3-222

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Implementing Simple Password Authentication for OSPF This topic describes how to configure simple password authentication.

Configure Simple Password Authentication for OSPF Îďř˝±˛ş·ąó·ş÷ý·° ±­°ş ż«¬¸»˛¬·˝ż¬·±˛óµ»§ ł§µ»§

This command defines a password to be used with a neighboring router. The neighboring router must have the same password configured. Îďř˝±˛ş·ąó·ş÷ý·° ±­°ş ż«¬¸»˛¬·˝ż¬·±˛ ŃÎ Îďř˝±˛ş·ąó®±«¬»®÷ýż®»ż đ ż«¬¸»˛¬·˝ż¬·±˛

Specifies the authentication type for an interface or the authentication type for an area.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-3

To implement OSPF authentication, you must create an implementation plan. The implementation plan includes two main steps for the configuration of authentication: Key (password) configuration Authentication-type configuration The first step to configure OSPF simple password authentication is to configure the key (password). Assign a password to be used with the neighboring routers that use OSPF simple password authentication by issuing the ip ospf authentication-key interface configuration command, as shown in the figure. Note

In Cisco IOS Software Release 12.4, the router will give a warning message if you try to configure a password longer than eight characters; only the first eight characters will be used. Some earlier Cisco IOS releases did not provide this warning.

The password created by this command is used as a “key” that is inserted directly into the OSPF header when Cisco IOS software originates routing protocol packets. A separate password can be assigned to each network on a per-interface basis. All neighboring routers on the same network must have the same password to be able to exchange OSPF information.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-223

Note

If the service password-encryption command is not used when configuring OSPF authentication, the key will be stored as plaintext in the router configuration. If you configure the service password-encryption command, the key will be stored and displayed in an encrypted form; when it is displayed, there will be an encryption-type of 7 specified before the encrypted key.

The second step to configure OSPF simple password authentication is to configure the authentication type. Specify the authentication type using the ip ospf authentication interface configuration command, as shown in the figure. The ip ospf authentication command was introduced in Cisco IOS Software Release 12.0. For backward compatibility, the authentication type for an area is still supported. If the authentication type is not specified for an interface, the authentication type for the area will be used (the area default is null authentication). To enable authentication for an OSPF area, use the area authentication router configuration command. For more details about the ip ospf authentication-key, ip ospf authentication, and area authentication commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

3-224

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Simple Password Authentication Configuration Example

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-4

The figure in the slide shows the network used to illustrate the configuration, verification, and troubleshooting of simple password authentication. The configuration of the router R1 is shown in this figure. Simple password authentication is configured on interface serial 0/0/1. The ip ospf authentication command is used without the additional keywords. The interface is configured with an authentication key of “plainkey”. The configuration of router R2 is shown in this figure as well. You should notice that the connecting interfaces on both routers R1 and R2 are configured with the same authentication key. The only difference is that router R2 authentication is configured for the whole area 0 and authentication on router R1 is configured on the serial0/0/1 interface only.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-225

Simple Password Authentication Configuration for Virtual Links

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-5

The figure in the slide shows the network used to illustrate the configuration of simple password authentication for virtual links. The configuration of routers R1 and R3 is similar. Plaintext authentication is configured for the whole area 0 and the virtual link to area 0 is created via transit area 1 with plaintext authentication enabled. The authentication key cisco is configured on both routers.

3-226

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Verifying Simple Password Authentication

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-6

The figure shows the output of the show ip ospf interface and ping commands. The show ip ospf interface command shows that router R1 has one adjacent neighbor and simple password authentication is enabled. The results of the ping command to the router R2 loopback interface address are also displayed, to illustrate that the link is working. This and proves that devices are accessible. For more details about the show ip ospf interface command, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html For more details about the ping command, please check the Cisco IOS Configuration Fundamentals Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/fundamentals/command/reference/cf_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-227

Configuring MD5 Authentication for OSPF This topic describes how to configure MD5 authentication.

Configure OSPF MD5 Authentication Îďř˝±˛ş·ąó·ş÷ý·° ±­°ş ł»­­żą»óĽ·ą»­¬óµ»§ ď łĽë ł§­»˝®»¬µ»§

Defines a key ID and key to be used with a neighboring router. Neighboring router must have the same combination of key ID and key configured. Îďř˝±˛ş·ąó·ş÷ý·° ±­°ş ż«¬¸»˛¬·˝ż¬·±˛ ł»­­żą»óĽ·ą»­¬ ŃÎ Îďř˝±˛ş·ąó®±«¬»®÷ýż®»ż đ ż«¬¸»˛¬·˝ż¬·±˛ ł»­­żą»óĽ·ą»­¬

Specifies the authentication type for an interface or the authentication type for an area.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-7

The first step when configuring OSPF MD5 authentication is to configure the key ID and the key (password). You can assign a key ID and key to be used with neighboring routers that use OSPF MD5 authentication using the ip ospf message-digest-key command, as shown in the figure in the slide. Note

In Cisco IOS Software Release 12.4, the router will give a warning message if you try to configure a password longer than 16 characters; only the first 16 characters will be used. Some earlier Cisco IOS releases did not provide this warning.

The key and the key ID specified in this command are used to generate a message digest (also called a hash) of each OSPF packet; the message digest is appended to the packet. A separate password can be assigned to each network on a per-interface basis. Usually, one key per interface is used to generate authentication information when sending packets and to authenticate incoming packets. All neighboring routers on the same network must have the same password to be able to exchange OSPF information; in other words, the same key ID on the neighbor router must have the same key value. The key ID allows for uninterrupted transitions between keys, which is helpful for administrators who wish to change the OSPF password without disrupting communication. If an interface is configured with a new key, the router will send multiple copies of the same packet, each authenticated by different keys. The router will stop sending duplicate packets when it detects that all of its neighbors have adopted the new key.

3-228

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

For illustrating the process of changing keys, suppose the current configuration is as follows: ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬ đńđ ·° ±­°ş ł»­­żą»óĽ·ą»­¬óµ»§ ďđ𠳼ë ŃÔÜ

Then you change the configuration to the following: ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬ đńđ ·° ±­°ş ł»­­żą»óĽ·ą»­¬óµ»§ ďđď łĽë ŇŰÉ

The system assumes that its neighbors do not have the new key yet, so it begins a rollover process. It sends multiple copies of the same packet, each authenticated by different keys. In this example, the system sends out two copies of the same packet, the first one authenticated by key 100 and the second one authenticated by key 101. Rollover allows neighboring routers to continue communication while the network administrator is updating them with the new key. Rollover stops when the local system finds that all its neighbors know the new key. The system detects that a neighbor has the new key when it receives packets from the neighbor authenticated by the new key. After all neighbors have been updated with the new key, the old key should be removed. In this example, you would enter the following: ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬ đń𠲱 ·° ±­°ş ł»­­żą»óĽ·ą»­¬óµ»§ ďđđ

Then only key 101 will be used for authentication on FastEthernet interface 0/0. Note

You should not keep more than one key per interface. Every time you add a new key, you should remove the old key to prevent the local system from continuing to communicate with a hostile system that knows the old key.If you do not use the service password-encryption command when configuring OSPF authentication, the key will be stored as plaintext in the router configuration. If you use the service password-encryption command, the key will be stored and displayed in an encrypted form; when it is displayed, there will be an encryptiontype of 7 specified before the encrypted key.

The second step when configuring OSPF MD5 authentication is to configure the authentication type. Specify the authentication type using the ip ospf authentication command as shown in the figure in the slide. For MD5 authentication, use the ip ospf authentication command with the message-digest parameter. Before using this command, configure the message digest key for the interface with the ip ospf message-digest-key command. Recall that the ip ospf authentication command was introduced in Cisco IOS Software Release 12.0. As with simple password authentication, the MD5 authentication type for an area is still supported using the area authentication router configuration command, for backward compatibility. For more details about the ip ospf message-digest-key, ip ospf authentication, and area authentication commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-229

OSPF MD5 Authentication Configuration Example

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-8

The figure in the slide shows the network used to illustrate the configuration, verification, and troubleshooting of simple password authentication. The configuration of router R1 is shown in this figure in the slide. MD5 authentication is configured on interface serial 0/0/1. The ip ospf authentication command is used with the message-digest keyword. The interface is configured with authentication key number 1 set to mysecret. The configuration of router R2 is shown in this figure, as well. You should notice that the connecting interfaces on both routers R1 and R2 are configured with the same authentication key ID and the key. The authentication configuration on router R2 is enabled for the whole area 0, not only on the serial 0/0/1 interface as with router R1.

3-230

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Verifying MD5 Authentication

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—3-9

The figure shows the output of the show ip ospf interface and ping commands. The show ip ospf interface command shows that router R1 has one adjacent neighbor and message digest authentication is enabled. The results of a ping command to the router R2 loopback interface address are also displayed, to illustrate that the link is working. This proves the accessibility of devices.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-231

Troubleshooting Authentication for OSPF This topic describes how to verify and troubleshoot authentication and focuses on simple password authentication.

Authentication Verification Problems include the following: Authentication problems: – Authentication is not configured on both sides. – A different authentication type is configured on either side. Different passwords are configured on either side. Îďý

Ľ»ľ«ą ·° ±­°ş żĽ¶

This command displays the OSPF adjacency-related events.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-10

Authentication for OSPF routing packets prevents your router from receiving fraudulent route updates. Once authentication is configured, all the neighbors must use the same password and authentication type. If the authentication type is not the same for both neighbors, or one neighbor is not configured at all, then OSPF will not be able to exchange routing updates successfully. The same applies for the password, which must be the same for both neighboring routers. After OSPF configuration, the authentication verification, authentication type, and password must be observed. Once the authentication configuration is correct, an OSPF neighborship is established, routing updates are exchanged, and OSPF routes are entered in the IP routing table. If the destinations are not accessible, or there are no neighbors or OSPF routes or both in the IP routing table, then you can use debugging to obtain additional information about OSPF authentication problems. To display information on OSPF related adjacency events, such as packets being dropped due to authentication problems, use the debug ip ospf adj command from privileged EXEC mode. For more details about the debug ip ospf adj command, please check the Cisco IOS Debug Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/debug/command/reference/db_book.html

3-232

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Successful Simple Password Authentication Verification Authentication is configured correctly

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-11

The following output of the debug ip ospf adj command (part of which is shown in the figure) illustrates successful simple password authentication on router R1 after the serial 0/0/1 interface, on which authentication has been configured, comes up: ÎďýĽ»ľ«ą ·° ±­°ş żĽ¶ ŃÍĐÚ żĽ¶ż˝»˛˝§ »Ş»˛¬­ Ľ»ľ«ąą·˛ą ·­ ±˛ öÚ»ľ ďé ďčćěďćëďňîěîć ŃÍĐÚć ײ¬»®şż˝» Í»®·ż´đńđńď ą±·˛ą Ë° öÚ»ľ ďé ďčćěďćëďňéěîć ŃÍĐÚć Ţ«·´Ľ ®±«¬»® ÔÍß ş±® ż®»ż đô ®±«¬»® ×Ü ďđňďňďňďô ­»Ż đ¨čđđđđđďí öÚ»ľ ďé ďčćěďćëîňîěîć űÔ×ŇŰĐÎŃĚŃóëóËĐÜŃÉŇć Ô·˛» °®±¬±˝±´ ±˛ ײ¬»®şż˝» Í»®·ż´đńđńďô ˝¸ż˛ą»Ľ ­¬ż¬» ¬± «° öÚ»ľ ďé ďčćěîćđďňîëđć ŃÍĐÚć î Éż§ ݱłł«˛·˝ż¬·±˛ ¬± ďđňîňîňî ±˛ Í»®·ż´đńđńďô ­¬ż¬» îÉßÇ öÚ»ľ ďé ďčćěîćđďňîëđć ŃÍĐÚć Í»˛Ľ ÜŢÜ ¬± ďđňîňîňî ±˛ Í»®·ż´đńđńď ­»Ż đ¨çŢę ±°¬ đ¨ëî ş´żą đ¨é ´»˛ íî öÚ»ľ ďé ďčćěîćđďňîęîć ŃÍĐÚć Î˝Ş ÜŢÜ ş®±ł ďđňîňîňî ±˛ Í»®·ż´đńđńď ­»Ż đ¨îíŰÜ ±°¬đ¨ëî ş´żą đ¨é ´»˛ íî ł¬« ďëđđ ­¬ż¬» ŰČÍĚßÎĚ öÚ»ľ ďé ďčćěîćđďňîęîć ŃÍĐÚć ŇŢÎ Ň»ą±¬·ż¬·±˛ ܱ˛»ň É» ż®» ¬¸» ÍÔßĘŰ öÚ»ľ ďé ďčćěîćđďňîęîć ŃÍĐÚć Í»˛Ľ ÜŢÜ ¬± ďđňîňîňî ±˛ Í»®·ż´đńđńď ­»Ż đ¨îíŰÜ ±°¬ đ¨ëî ş´żą đ¨î ´»˛ éî öÚ»ľ ďé ďčćěîćđďňîçěć ŃÍĐÚć Î˝Ş ÜŢÜ ş®±ł ďđňîňîňî ±˛ Í»®·ż´đńđńď ­»Ż đ¨îíŰŰ ±°¬đ¨ëî ş´żą đ¨í ´»˛ éî ł¬« ďëđđ ­¬ż¬» ŰČÝŘßŇŮŰ öÚ»ľ ďé ďčćěîćđďňîçěć ŃÍĐÚć Í»˛Ľ ÜŢÜ ¬± ďđňîňîňî ±˛ Í»®·ż´đńđńď ­»Ż đ¨îíŰŰ ±°¬ đ¨ëî ş´żą đ¨đ ´»˛ íî öÚ»ľ ďé ďčćěîćđďňîçěć ŃÍĐÚć Üż¬żľż­» ®»Ż«»­¬ ¬± ďđňîňîňî

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-233

öÚ»ľ ďé ďčćěîćđďňîçěć ŃÍĐÚć ­»˛¬ ÔÍ ÎŰĎ °ż˝µ»¬ ¬± ďçîňďęčňďňďđîô ´»˛ą¬¸ ďî öÚ»ľ ďé ďčćěîćđďňíďěć ŃÍĐÚć Î˝Ş ÜŢÜ ş®±ł ďđňîňîňî ±˛ Í»®·ż´đńđńď ­»Ż đ¨îíŰÚ ±°¬đ¨ëî ş´żą đ¨ď ´»˛ íî ł¬« ďëđđ ­¬ż¬» ŰČÝŘßŇŮŰ öÚ»ľ ďé ďčćěîćđďňíďěć ŃÍĐÚć ۨ˝¸ż˛ą» ܱ˛» ©·¬¸ ďđňîňîňî ±˛ Í»®·ż´đńđńď öÚ»ľ ďé ďčćěîćđďňíďěć ŃÍĐÚć Í»˛Ľ ÜŢÜ ¬± ďđňîňîňî ±˛ Í»®·ż´đńđńď ­»Ż đ¨îíŰÚ ±°¬ đ¨ëî ş´żą đ¨đ ´»˛ íî öÚ»ľ ďé ďčćěîćđďňíîęć ŃÍĐÚć ͧ˛˝¸®±˛·¦»Ľ ©·¬¸ ďđňîňîňî ±˛ Í»®·ż´đńđńďô ­¬ż¬» ÚËÔÔ öÚ»ľ ďé ďčćěîćđďňííđć űŃÍĐÚóëóßÜÖÝŘŮć Đ®±˝»­­ ďđô Ňľ® ďđňîňîňî ±˛ Í»®·ż´đńđńď ş®±ł ÔŃßÜ×ŇŮ ¬± ÚËÔÔô Ô±żĽ·˛ą ܱ˛» öÚ»ľ ďé ďčćěîćđďňčíđć ŃÍĐÚć Ţ«·´Ľ ®±«¬»® ÔÍß ş±® ż®»ż đô ®±«¬»® ×Ü ďđňďňďňďô ­»Ż đ¨čđđđđđďě

The output of the show ip ospf neighbor command shown in the figure illustrates that router R1 has successfully formed an adjacency with router R2.

3-234

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Troubleshooting Simple Password Authentication Problems Simple authentication is not configured on router R2

Different keys on routers R1 and R2

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-12

If simple password authentication is configured on router R1’s serial 0/0/1 interface but no authentication is configured on router R2’s serial 0/0/1 interface, the routers will not be able to form an adjacency over that link. The output of the debug ip ospf adj command shown in the upper portion of the figure illustrates that the routers report a mismatch in authentication type; no OSPF packets will be sent between the neighbors. Note

The different types of authentication have these type codes: null—type 0, simple password—type 1, MD5—type 2.

If simple password authentication is configured on router R1’s serial 0/0/1 interface and on the router R2’s serial 0/0/1 interface, but with different passwords, the routers will not be able to form an adjacency over that link. The output of the debug ip ospf adj command shown in the lower portion of the figure illustrates that the routers report an authentication key mismatch; no OSPF packets will be sent between the neighbors.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-235

Successful MD5 Authentication Verification Authentication is configured correctly

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-13

The following output of the debug ip ospf adj command (part of which is shown in the figure in the slide) illustrates a successful MD5 authentication on router R1 after the serial 0/0/1 interface, on which authentication has been configured, comes up: ÎďýĽ»ľ«ą ·° ±­°ş żĽ¶ ŃÍĐÚ żĽ¶ż˝»˛˝§ »Ş»˛¬­ Ľ»ľ«ąą·˛ą ·­ ±˛ öÚ»ľ ďé ďéćďíćëęňëíđć űÔ×ŇŐóíóËĐÜŃÉŇć ײ¬»®şż˝» Í»®·ż´đńđńďô ˝¸ż˛ą»Ľ ­¬ż¬» ¬± «° öÚ»ľ ďé ďéćďíćëęňëíđć ŃÍĐÚć ײ¬»®şż˝» Í»®·ż´đńđńď ą±·˛ą Ë° öÚ»ľ ďé ďéćďíćëęňëíđć ŃÍĐÚć Í»˛Ľ ©·¬¸ §±«˛ą»­¬ Ő»§ ď öÚ»ľ ďé ďéćďíćëéňđíđć ŃÍĐÚć Ţ«·´Ľ ®±«¬»® ÔÍß ş±® ż®»ż đô ®±«¬»® ×Ü ďđňďňďňďô ­»Ż đ¨čđđđđđđç öÚ»ľ ďé ďéćďíćëéňëíđć űÔ×ŇŰĐÎŃĚŃóëóËĐÜŃÉŇć Ô·˛» °®±¬±˝±´ ±˛ ײ¬»®şż˝» Í»®·ż´đńđńďô ˝¸ż˛ą»Ľ ­¬ż¬» ¬± «° öÚ»ľ ďé ďéćďěćđęňëíđć ŃÍĐÚć Í»˛Ľ ©·¬¸ §±«˛ą»­¬ Ő»§ ď öÚ»ľ ďé ďéćďěćđęňëěęć ŃÍĐÚć î Éż§ ݱłł«˛·˝ż¬·±˛ ¬± ďđňîňîňî ±˛ Í»®·ż´đńđńďô ­¬ż¬» îÉßÇ öÚ»ľ ďé ďéćďěćđęňëěęć ŃÍĐÚć Í»˛Ľ ÜŢÜ ¬± ďđňîňîňî ±˛ Í»®·ż´đńđńď ­»Ż đ¨Ţíé ±°¬ đ¨ëî ş´żą đ¨é ´»˛ íî öÚ»ľ ďé ďéćďěćđęňëěęć ŃÍĐÚć Í»˛Ľ ©·¬¸ §±«˛ą»­¬ Ő»§ ď öÚ»ľ ďé ďéćďěćđęňëęîć ŃÍĐÚć Î˝Ş ÜŢÜ ş®±ł ďđňîňîňî ±˛ Í»®·ż´đńđńď ­»Ż đ¨íîÚ ±°¬ đ ¨ëî ş´żą đ¨é ´»˛ íî

ł¬« ďëđđ ­¬ż¬» ŰČÍĚßÎĚ

öÚ»ľ ďé ďéćďěćđęňëęîć ŃÍĐÚć ŇŢÎ Ň»ą±¬·ż¬·±˛ ܱ˛»ň É» ż®» ¬¸» ÍÔßĘŰ öÚ»ľ ďé ďéćďěćđęňëęîć ŃÍĐÚć Í»˛Ľ ÜŢÜ ¬± ďđňîňîňî ±˛ Í»®·ż´đńđńď ­»Ż đ¨íîÚ ±°¬ đ¨ëî ş´żą đ¨î ´»˛ éî

3-236

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

öÚ»ľ ďé ďéćďěćđęňëęîć ŃÍĐÚć Í»˛Ľ ©·¬¸ §±«˛ą»­¬ Ő»§ ď öÚ»ľ ďé ďéćďěćđęňęđîć ŃÍĐÚć Î˝Ş ÜŢÜ ş®±ł ďđňîňîňî ±˛ Í»®·ż´đńđńď ­»Ż đ¨ííđ ±°¬ đ¨ëî ş´żą đ¨í ´»˛ éî ł¬« ďëđđ ­¬ż¬» ŰČÝŘßŇŮŰ öÚ»ľ ďé ďéćďěćđęňęđîć ŃÍĐÚć Í»˛Ľ ÜŢÜ ¬± ďđňîňîňî ±˛ Í»®·ż´đńđńď ­»Ż đ¨ííđ ±°¬ đ¨ëî ş´żą đ¨đ ´»˛ íî öÚ»ľ ďé ďéćďěćđęňęđîć ŃÍĐÚć Í»˛Ľ ©·¬¸ §±«˛ą»­¬ Ő»§ ď öÚ»ľ ďé ďéćďěćđęňęđîć ŃÍĐÚć Üż¬żľż­» ®»Ż«»­¬ ¬± ďđňîňîňî öÚ»ľ ďé ďéćďěćđęňęđîć ŃÍĐÚć Í»˛Ľ ©·¬¸ §±«˛ą»­¬ Ő»§ ď öÚ»ľ ďé ďéćďěćđęňęđîć ŃÍĐÚć ­»˛¬ ÔÍ ÎŰĎ °ż˝µ»¬ ¬± ďçîňďęčňďňďđîô ´»˛ą¬¸ ďî öÚ»ľ ďé ďéćďěćđęňęďěć ŃÍĐÚć Í»˛Ľ ©·¬¸ §±«˛ą»­¬ Ő»§ ď öÚ»ľ ďé ďéćďěćđęňęíěć ŃÍĐÚć Î˝Ş ÜŢÜ ş®±ł ďđňîňîňî ±˛ Í»®·ż´đńđńď ­»Ż đ¨ííď ±°¬ đ¨ëî ş´żą đ¨ď ´»˛ íî ł¬« ďëđđ ­¬ż¬» ŰČÝŘßŇŮŰ öÚ»ľ ďé ďéćďěćđęňęíěć ŃÍĐÚć ۨ˝¸ż˛ą» ܱ˛» ©·¬¸ ďđňîňîňî ±˛ Í»®·ż´đńđńď öÚ»ľ ďé ďéćďěćđęňęíěć ŃÍĐÚć Í»˛Ľ ÜŢÜ ¬± ďđňîňîňî ±˛ Í»®·ż´đńđńď ­»Ż đ¨ííď ±°¬ đ¨ëî ş´żą đ¨đ ´»˛ íî öÚ»ľ ďé ďéćďěćđęňęíěć ŃÍĐÚć Í»˛Ľ ©·¬¸ §±«˛ą»­¬ Ő»§ ď öÚ»ľ ďé ďéćďěćđęňęëđć ŃÍĐÚć ͧ˛˝¸®±˛·¦»Ľ ©·¬¸ ďđňîňîňî ±˛ Í»®·ż´đńđńďô ­¬ż¬» ÚËÔÔ öÚ»ľ ďé ďéćďěćđęňęëđć űŃÍĐÚóëóßÜÖÝŘŮć Đ®±˝»­­ ďđô Ňľ® ďđňîňîňî ±˛ Í»®·ż´đńđńď ş®±ł ÔŃßÜ×ŇŮ ¬± ÚËÔÔô Ô±żĽ·˛ą ܱ˛» öÚ»ľ ďé ďéćďěćđéňďëđć ŃÍĐÚć Í»˛Ľ ©·¬¸ §±«˛ą»­¬ Ő»§ ď öÚ»ľ ďé ďéćďěćđéňďëđć ŃÍĐÚć Ţ«·´Ľ ®±«¬»® ÔÍß ş±® ż®»ż đô ®±«¬»® ×Ü ďđňďňďňďô ­»Ż đ¨čđđđđđđß öÚ»ľ ďé ďéćďěćđçňďëđć ŃÍĐÚć Í»˛Ľ ©·¬¸ §±«˛ą»­¬ Ő»§ ď

The output of the show ip ospf neighbor command shown in the figure illustrates that router R1 has successfully formed an adjacency with router R2.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-237

Troubleshooting MD5 Authentication Problems MD5 authentication configured on both routers Router R1 has key 1 and router R2 has key 2, both with the same passwords:

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-14

If MD5 authentication is configured on router R1’s serial 0/0/1 interface and on the router R2’s serial 0/0/1 interface, but router R1 has key 1 and router R2 has key 2, the routers will not be able to form an adjacency over that link, even though both have the same passwords configured. The output of the debug ip ospf adj command shown in the figure illustrates that the routers report an authentication key mismatch. No OSPF packets will be sent between the neighbors.

3-238

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary When authentication is configured, the router generates and checks every OSPF packet and authenticates the source of each routing update packet that it receives. OSPF supports two types of authentication: – Simple password (or plaintext) authentication: The router sends an OSPF packet and key. – MD5 authentication: The router generates a message digest, or hash, of the key, key ID, and message. The message digest is sent with the packet; the key is not sent. To configure simple password authentication, use the ip ospf authentication-key password command and the ip ospf authentication command.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 3-15

Summary (Cont.) To configure MD5 authentication, use the ip ospf messagedigest-key key-id md5 key command and the ip ospf authentication message-digest command. Use the show ip ospf neighbor, show ip route, ping, and debug ip ospf adj commands to verify and troubleshoot both types of authentication. With MD5 authentication, the debug ip ospf adj command output indicates the key ID sent.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1. 0— 3-16

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-239

3-240

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 12

Lab 3-5 Debrief Overview In Lab 3-5, students configure and verify OSPF authentication.

Objectives Upon completing this lesson, you will be able to configure and verify OSPF authentication. This ability includes being able to meet these objectives: Complete the lab overview and verification Describe a sample solution and alternatives

Lab Overview and Verification This topic describes lab topology and key checkpoints used to create a solution and to start with the verification.

Lab Topology

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-2

The figure in the slide presents the physical lab topology used for Lab 3-5: Configure and Verify OSPF Authentication. The topology uses four pod routers and one backbone router. Based on the topology, students will identify the required parameters and configure OSPF authentication in order to establish a neighbor relationship and secure exchange of routing packets. The backbone routers are preconfigured with authentication and the configuration of the pod routers must match. For the rest of the pod routers, the proper configuration must be applied.

3-242

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab Review: What Did You Accomplish? Task 1: Examining OSPF Routing Information – How can you verify the operation of an OSPF routing protocol? – What can you see by observing the OSPF neighbors, OSPF database, OSPF interfaces, and IP routing table? Task 2: Enabling OSPF Link Authentication – How is OSPF link authentication between two routers implemented? Task 3: Enabling OSPF Area Authentication – How is OSPF area authentication implemented on a router?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-3

In the first task, you will examine the OSPF routing information. Your pod is preconfigured with the OSPF configuration and the proper configuration steps are needed in order to configure authentication in the following tasks. In the second task, you must enable OSPF link authentication on the LAN segment between routers R2 and R4. You must use the authentication that provides the highest level of security. In the third task, you must enable OSPF area authentication in the whole area. Again, you must use the authentication that provides the highest level of security.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-243

Verification Did you have enough information to create an implementation plan? Were you able to define the OSPF topology and the contents of the IP routing table? Verify that after link authentication configuration, the adjacencies, IP routing table, and OSPF database are included into OSPF. Examine the OSPF link authentication process. Verify that after link authentication configuration, the adjacencies, IP routing table, and OSPF database are included into OSPF. Examine the OSPF area authentication process. Verify that when a router with an improper or missing OSPF authentication is connected to the area, an OSPF adjacency is not set up.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-4

To verify the implementation process for configuring OSPF authentication, answer the following questions: Did you have enough information to create an implementation plan? Were you able to define the OSPF topology and the content of the IP routing table? After link authentication configuration, were all the adjacencies, the IP routing table, and the OSPF database included in OSPF? What do you see when you examine the OSPF link authentication process? After area authentication configuration, were all the adjacencies, the IP routing table, and the OSPF database included in OSPF? What do you see when you examine the OSPF link authentication process? When a router with an improper or missing OSPF authentication is connected to the area, is it prevented from establishing an OSPF adjacency?

3-244

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Checkpoints Examine the IP routing information exchanged by routers configured with the OSPF routing protocol. Configure OSPF link authentication on the LAN segment. Check the IP routing table and OSPF database to verify that the adjacency on that link is up and link is included in the OSPF process. Configure OSPF area authentication. Check the IP routing table and OSPF database to verify that the adjacencies in the area are up and the links are included in the OSPF process. Check for the OSPF information in the router where area authentication is not configured.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-5

With different checkpoints, the network operator can verify for proper configuration. The following checkpoints are used for verification: Examine the IP routing information exchanged by routers configured with the OSPF routing protocol. Configure OSPF link authentication on a LAN segment. Check the IP routing table and OSPF database to verify that an adjacencies on the links are up and the links included in the OSPF process. Configure OSPF area authentication. Check the IP routing table and OSPF database to verify that the adjacencies in the area are up and the links are included in the OSPF process. Check for OSPF information in the router where the area authentication is not configured.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-245

Sample Solution and Alternatives This topic describes a sample solution and other alternatives.

A Sample Solution The OSPF topology and OSPF operation are verified, along with the IP routing table, which shows the OSPF routes. OSPF link authentication is configured on the LAN segment. OSPF area authentication is configured in the whole area. MD5 authentication is used as the highest security provided in the OSPF.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-6

A sample solution includes implementation details and details for each task of the implementation plan. Different solutions are possible; the figure points out a few details of a successful configuration. Proper implementation of route redistribution between multiple IP routing protocols includes the following details: The OSPF topology and OSPF operation are verified, as well as the IP routing table, which shows OSPF routes. OSPF link authentication is configured on the LAN segment between routers R2 and R4. OSPF area authentication is configured in the whole area. MD5 authentication is used as the highest security provided in the OSPF.

3-246

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternative Solutions Different authentication types can be used (clear text instead of MD5). Different areas and redistribution can be used to control the updates, but they do not provide authentication.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-7

In order to provide reachability and authentication, you can select between MD5 and simple authentication. In both cases, authentication provides a level of security in the network, but MD5 authentication is more secure. In order to control the routing updates, you can use several areas and redistribution. The use of different areas, by itself, does not provide authentication, but you can use a different authentication key in each area. Redistribution does not provide authentication either, but it provides a way for you to control routing updates, if this is a concern.

.

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-247

Q and A How can you verify the OSPF routes in an IP routing table? How many authentication types are supported by OSPF? How do you configure OSPF link authentication? How do you configure OSPF area authentication? Is OSPF area authentication applied to all OSPF-enabled interfaces on the router where it is configured?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-8

You can verify OSPF routes in the IP routing table; all the routes with the letter “O” in front of them represent the OSPF routes. OSPF supports two types of authentication: simple and MD5 authentication. You can configure link authentication on the interface, along with the authentication key used on both neighboring routers. You can configure area authentication in OSPF router configuration mode and apply it to the whole area. You need an authentication key on each interface facing the OSPF neighbor. Area authentication is enabled for the whole area. The interfaces used must also be configured with the authentication key.

3-248

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary IP routing information exchanged by routers that are configured with the OSPF routing protocol is examined. Simple OSPF authentication is configured between routers on a LAN segment. You do not only deploy OSPF area authentication on each link, but also in the whole area, for which all OSPF interfaces are involved.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1. 0—3-9

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-249

3-250

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Module Summary This topic summarizes the key points that were discussed in this module.

Module Summary Open Shortest Path First (OSPF) protocol is one of the most commonly used link-state IP routing protocols in networking. It is an open standard and offers quick convergence and the ability to scale large networks. OSPF uses five types of routing protocol packets and six common link-state advertisements (LSAs). The routing protocol packets are hello, database description, link-state request, linkstate update, and link-state acknowledgement. LSAs are router link (LSA type 1), network link (LSA type 2), network summary (LSA type 3), ASBR summary (LSA type 4), external (LSA type 5), and NSSA external (LSA type 7). OSPF has the following three network types: point-to-point, broadcast, and nonbroadcast multiaccess (NBMA), for which NBMA supports five modes of OSPF operation: NBMA, point-tomultipoint, point-to-multipoint nonbroadcast, broadcast, and point-to-point. © 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-1

Module Summary (Cont.) The configuration of OSPF is a two-step process: – Enter the OSPF configuration with the router ospf command. – Use the network command to describe which interfaces will run OSPF in which area. Route summarization reduces OSPF LSA flooding and the routing table size, which reduces memory and CPU utilization on routers. The OSPF area types supported are backbone area, normal area, stub area, totally stubby area, and not-so-stubby area (NSSA). Stub area techniques improve OSPF performance by reducing the amount of LSA flooding. OSPF supports two types of authentication: – Simple password (or plaintext) authentication – MD5 authentication

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—3-2

Open Shortest Path First Protocol (OSPF) is one of the most commonly used interior gateway protocols in IP networking. OSPF is a complex, open-standard protocol made up of several protocol handshakes, database advertisements, and packet types. © 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-251

3-252

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Module Self-Check Use the questions here to review what you learned in this module. The correct answers and solutions are found in the Module Self-Check Answer Key. Q1)

All of these tables are maintained by a link-state routing protocol except which one? (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B) C) D)

Q2)

The memory needed to maintain tables is one disadvantage of link-state protocols. (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B)

Q3)

Area Boundary Router Area Border Router Autonomous System Boundary Router backbone router

What is the recommended guideline for the maximum number of routers per OSPF area? (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B) C) D)

Q6)

routing topology neighbor 1. stores LSAs 2. stores adjacencies 3. stores best paths

Which term refers to the router that connects area 0 to a nonbackbone area? (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B) C) D)

Q5)

true false

Match each table to its function. (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B) C) _____ _____ _____

Q4)

routing topology update neighbor

50 10 200 500

Which OSPF packet helps form neighbor adjacencies? (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B) C) D)

© 2009 Cisco Systems, Inc.

exchange packet hello packet neighbor discovery packet adjacency packet

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-253

Q7)

Which criterion does SPF use to determine the best path? (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B) C) D)

Q8)

Which table is populated as a result of SPF calculations? (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B) C) D)

Q9)

neighbor table topology table routing table update table

An OSPF router receives an LSA and checks the sequence number of the LSA. This number matches the sequence number of an LSA that the receiving router already has. What does the receiving router do with the received LSA? (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B) C) D)

3-254

true false

When an OSPF router receives an LSA, it is installed in the _____. (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B) C) D)

Q13)

a separate database for each area with which it is connected a single database for all areas two databases: one for the backbone and one for all other areas a separate routing table for each area

In a multiarea network, any area can be the backbone area, although it is most often area 0. (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B)

Q12)

one two four eight

An area border router maintains _____. (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B) C) D)

Q11)

topology routing adjacency neighbor

Cisco recommends no more than _____ area or areas per ABR in addition to area 0. (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B) C) D)

Q10)

lowest delay highest bandwidth lowest total cost of the route total bandwidth of the route

ignores the LSA adds the LSA to the database sends the newer LSU to the source router floods the LSA to the other routers

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q14)

An OSPF router receives an LSA. The router checks the sequence number of the LSA and finds that this number is higher than the sequence number it already has. Which two tasks does the router perform with the LSA? (Choose two.) (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B) C) D)

Q15)

An OSPF router receives an LSA. The router checks the sequence number of the LSA and finds that this number is lower than the sequence number it already has. What does the router do with the LSA? (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B) C) D)

Q16)

implementation plan verification plan the Cisco IOS Router Configuration Guide for the OSPF routing protocol documentation of the OSPF implementation

During planning for basic OSPF implementation, the network engineer must go through the following steps: define the network requirements, gather the required parameters, define the OSPF areas and routing, configure basic OSPF, verify the OSPF configuration, and complete the documentation. (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B)

Q19)

30 seconds 1 minute 30 minutes 1 hour

A network engineer must configure the OSPF routing protocol in the network. The engineer needs all of these to implement the OSPF routing protocol except which one? (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B) C) D)

Q18)

ignores the LSA adds the LSA to the database sends the newer LSU to the source router floods the LSA to the other routers

Each LSA has its own age timer. By default, how long does an LSA wait before requiring an update? (Source: Planning Routing Implementations with OSPF as a Scalable Routing Protocol) A) B) C) D)

Q17)

ignores the LSA adds the LSA to the database sends the newer LSU to the source router floods the LSA to the other routers

true false

What is the IP protocol number for OSPF packets? (Source: How OSPF Packet Processes Work) A) B) C) D)

© 2009 Cisco Systems, Inc.

89 86 20 76

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-255

Q20)

All of these are OSPF packet types except which one? (Source: How OSPF Packet Processes Work) A) B) C) D) E) F)

Q21)

Which multicast address does the OSPF Hello protocol use? (Source: How OSPF Packet Processes Work) A) B) C) D)

Q22)

10 seconds 30 seconds 30 minutes 1 hour

All of these fields are in an OSPF packet header except which one? (Source: How OSPF Packet Processes Work) A) B) C) D)

3-256

exstart loading exchange two-way

At what interval does OSPF refresh LSAs? (Source: How OSPF Packet Processes Work) A) B) C) D)

Q26)

_____ two-way _____ loading _____ down _____ full _____ exchange _____ init _____ exstart

DBD packets are involved during which two states? (Choose two.) (Source: How OSPF Packet Processes Work) A) B) C) D)

Q25)

true false

Place the exchange protocol states in the correct order. (Source: How OSPF Packet Processes Work) A) B) C) D) E) F) G)

Q24)

224.0.0.5 224.0.0.6 224.0.0.7 224.0.0.8

The Hello protocol sends periodic updates to ensure that a neighbor relationship is maintained between adjacent routers. (Source: How OSPF Packet Processes Work) A) B)

Q23)

LSU LSR DBD LSAck hello query

packet length router ID authentication type MaxAge time

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q27)

OSPF does not require a hello protocol on point-to-point links, because adjacent routers are directly connected. (Source: Improving Routing Performance in a Complex Enterprise Network) A) B)

Q28)

Three routers are connected to an Ethernet LAN. One is a small router that should not take on the role of DR or BDR. How do you ensure that it never will? (Source: Improving Routing Performance in a Complex Enterprise Network) A) B) C) D)

Q29)

true false

Which mode of OSPF operation is RFC-compliant? (Source: Improving Routing Performance in a Complex Enterprise Network) A) B) C) D)

Q33)

10 seconds 30 seconds 120 seconds 60 seconds

An OSPF router automatically builds adjacencies with neighboring routers on an NBMA link. (Source: Improving Routing Performance in a Complex Enterprise Network) A) B)

Q32)

true false

What is the default hello interval for NBMA interfaces? (Source: Improving Routing Performance in a Complex Enterprise Network) A) B) C) D)

Q31)

Set the interface priority to 100. Set the interface priority to 0. Leave the interface priority set to 1 and set the priority of the other two routers to 10. Use the no designated-router command on the Ethernet interface.

When the DR fails, the BDR automatically builds new adjacencies, exchanges databases with other routers, and takes over as DR. (Source: Improving Routing Performance in a Complex Enterprise Network) A) B)

Q30)

true false

point-to-multipoint nonbroadcast point-to-multipoint broadcast point-to-point

Match the OSPF over Frame Relay mode of operation with its description. (Source: Improving Routing Performance in a Complex Enterprise Network) A) B) C)

broadcast point-to-multipoint nonbroadcast

_____ 1.

does not discover neighbors automatically

_____ 2.

discovers neighbors automatically and requires a DR and BDR election

_____ 3.

is used in partial-mesh topologies, discovers neighbors automatically, and does not require a DR and BDR election

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-257

Q34)

Which two OSPF over Frame Relay modes elect a DR? (Choose two.) (Source: Improving Routing Performance in a Complex Enterprise Network) A) B) C) D)

Q35)

A point-to-point subinterface provides which two benefits for OSPF over Frame Relay? (Choose two.) (Source: Improving Routing Performance in a Complex Enterprise Network) A) B) C) D)

Q36)

true false

The BDR, like the DR, maintains a full set of adjacencies on a broadcast link. (Source: Improving Routing Performance in a Complex Enterprise Network) A) B)

3-258

point-to-point broadcast point-to-multipoint point-to-multipoint nonbroadcast nonbroadcast multiaccess

When an OSPF adjacency is built over a Layer 3 MPLS VPN backbone, customer routers are unaware of the MPLS VPN topology. (Source: Improving Routing Performance in a Complex Enterprise Network) A) B)

Q40)

224.0.0.6 224.0.0.5 255.255.255.255 the IP address of the output interface

What are the three types of networks defined by OSPF? (Choose three.) (Source: Improving Routing Performance in a Complex Enterprise Network) A) B) C) D) E)

Q39)

The DR and BDR are elected. The OSPF parameters must be agreed upon with service provider. Provider edge routers appear as additional routers in the customer’s network. The OSPF network type is multiaccess broadcast.

Which destination IP address does OSPF use when advertising to all SPF routers? (Source: Improving Routing Performance in a Complex Enterprise Network) A) B) C) D)

Q38)

works with multiple vendors does not require manual configuration of neighbors does not require a DR and BDR saves on subnets

Which statement below is true for an OSPF adjacency built over a Layer 2 MPLS VPN backbone? (Choose two.) (Source: Improving Routing Performance in a Complex Enterprise Network) A) B) C) D)

Q37)

broadcast nonbroadcast point-to-multipoint point-to-point

true false

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q41)

Which two OSPF over Frame Relay modes require a DR? (Choose two.) (Source: Improving Routing Performance in a Complex Enterprise Network) A) B) C) D)

Q42)

Which two statements regarding OSPF nonbroadcast mode are correct? (Choose two.) (Source: Improving Routing Performance in a Complex Enterprise Network) A) B) C) D)

Q43)

show ip ospf interface show ip ospf show ip route show ip ospf neighbor

All of these techniques are used for router ID selection except which one? (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q48)

network ip-address mask area area-id network ip-address wildcard-mask area area-id router ospf process-id ip router ospf

Which OSPF show command describes a list of OSPF adjacencies? (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q47)

broadcast point-to-point point-to-multipoint point-to-multipoint nonbroadcast

Which two commands are required for a basic OSPF configuration? (Choose two.) (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q46)

true false

Which OSPF mode requires neighbor commands? (Source: Improving Routing Performance in a Complex Enterprise Network) A) B) C) D)

Q45)

This mode requires manual neighbor commands. This mode does not use a DR and BDR. This mode uses a DR and BDR. This mode requires multiple subnets.

When you are using an OSPF neighbor command, you must configure it under an interface. (Source: Improving Routing Performance in a Complex Enterprise Network) A) B)

Q44)

point-to-point broadcast point-to-multipoint nonbroadcast

highest IP address on an interface IP address on a loopback interface lowest IP address when multiple loopback interfaces are used the router-id command

When you use the router-id command, the router ID immediately changes to the IP address that has been entered. (Source: Configuring and Verifying OSPF Routing) A) B)

© 2009 Cisco Systems, Inc.

true false

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-259

Q49)

Which network statement is used to configure OSPF on an interface with an IP address of 172.16.1.1 in area 0? (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q50)

Only one OSPF process can run on a Cisco router at one time. (Source: Configuring and Verifying OSPF Routing) A) B)

Q51)

cannot be a router ID, because it cannot be pinged can be the router ID, even though it cannot be pinged can be the router ID and can be pinged if a private address is selected cannot be the router ID; you should always advertise loopback addresses

Which statement describes the process ID used in the router ospf command? (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

3-260

show ip ospf interface show ip ospf neighbor show ip ospf show ip route

When you configure a loopback interface, you choose an IP address that is not going to be advertised by OSPF. This loopback address _____. (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q55)

a neighbor in the FULL state a neighbor not in FULL state any neighbor, regardless of whether or not it is in the FULL state no neighbor, regardless of whether or not it is in the FULL state

Which two show commands can be used to verify the OSPF router ID of a router? (Choose two.) (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q54)

172.16.45.1 10.3.3.3 10.2.2.2 10.1.1.1

The show ip ospf neighbor command shows the FULL state on one of the two neighbors in its table. Which neighbor or neighbors will successfully exchange LSDB information? (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q53)

true false

A router has a FastEthernet interface with an IP address of 172.16.45.1, a loopback 0 interface with an IP address of 10.3.3.3, a loopback 1 interface with an IP address of 10.2.2.2, and a router-id command with an IP address of 10.1.1.1. Which router ID will be selected? (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q52)

network 172.16.0.0 0.0.0.255 area 0 network 172.16.1.1 0.0.0.0 area 0 network 172.16.1.1 255.255.255.255 area 0 network 172.16.0.0 0.0.255.255 area 0

All OSPF routers in a network must have the same OSPF process ID. The OSPF process ID is an internal number; process IDs on different routers do not need to match. The OSPF process ID is similar to an AS number. There can be only one OSPF process ID in a router configuration.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q56)

Which three benefits are derived from a multiarea design in OSPF? (Choose three.) (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q57)

List the four link types that a type 1 LSA defines. (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q58)

reduced amount LSA flooding reduced number SPF calculations reduced size of the neighbor table reduced size of the routing table

________________ ________________ ________________ ________________

Match each LSA name with the number that corresponds to its LSA type. (Source: Configuring and Verifying OSPF Routing) A) B) C) D) E) F) G)

external network summary multicast router opaque NSSA

_____ 5 _____ 2 _____ 3 and 4 _____ 6 _____ 1 _____ 9–11 _____ 7 Q59)

If the OSPF routing table shows an O E1 route, what does this mean? (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q60)

It is an interarea route that uses the external cost plus the interarea cost. It is an interarea route that uses the external cost only. It is an external route that uses the external cost only. It is an external route that uses the external cost plus the internal cost.

Which two LSAs describe intra-area routing information? (Choose two.) (Source: Configuring and Verifying OSPF Routing) A) B) C) D) E)

© 2009 Cisco Systems, Inc.

summary external 1 external 2 router network

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-261

Q61)

Where will a type 3 LSA be sent? (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q62)

An O E1 route sums up the external metric and the interarea metric, while the O E2 route uses the external metric only. The O E1 route is the default for OSPF; the router must be configured to support O E2. (Source: Configuring and Verifying OSPF Routing) A) B)

Q63)

LSA 3 is a summary LSA, and LSA 4 is E1. LSA 3 is E1, and LSA 4 is a summary. LSA 3 is a summary for networks, and LSA 4 is a summary for ASBRs. LSA 3 is a summary for ASBRs, and LSA 4 is a summary for networks.

By default, OSPF assigns a cost of 1 to a bandwidth of _____. (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

3-262

It is intra-area. It is interarea. It is external. It is a stub.

What is the difference between an LSA 3 and an LSA 4? (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q67)

The O E1 cost is 110, and the O E2 cost is 55. The administrative distance is 110, and the metric is 55. The administrative distance is 55, and the metric is 110. The total cost of the route is 165.

What does it mean if a route in the routing table has an indicator of O? (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q66)

ip ospf cost on the interface auto-cost reference-bandwidth under the OSPF routing process bandwidth under the interface bandwidth under the OSPF routing process

Looking at the routing table, you notice “[110/55].” What does this mean? (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q65)

true false

A network uses Gigabit Ethernet and you want OSPF to correctly calculate the metric using bandwidth. Which command should you use to ensure that this happens? (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q64)

only within the area it originates from within the area it originates from plus the backbone area within the area it originates from, plus between all other areas within the backbone area, plus between all other areas

T1 1 Gb/s 100 Mb/s 10 Gb/s

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q68)

The OSPF LSDB shows an LSA with an age of 1799. What does this mean? (Source: Configuring and Verifying OSPF Routing) A) B) C) D)

Q69)

What are the two reasons why route summarization is important? (Choose two.) (Source: Configuring and Verifying OSPF Route Summarization) A) B) C) D)

Q70)

summary-address area x range network area x summary

A default route is identified in the OSPF database as an _____. (Source: Configuring and Verifying OSPF Route Summarization) A) B) C) D) E)

Q74)

summary-address area x range network area x summary

Which command would you use to summarize routes into OSPF from the ASBR? (Source: Configuring and Verifying OSPF Route Summarization) A) B) C) D)

Q73)

contiguous IP addressing discontinuous IP addressing FLSM VLSM

Which command would you use to summarize routes into area 0 from the ABR? (Source: Configuring and Verifying OSPF Route Summarization) A) B) C) D)

Q72)

reduces LSA type 1 flooding reduces LSA type 3 flooding reduces the size of the routing table reduces the size of the neighbor table

Which two features play a key role in route summarization? (Choose two.) (Source: Configuring and Verifying OSPF Route Summarization) A) B) C) D)

Q71)

The LSA is going to age out in 1 second. It has been 1799 minutes since the last update. The LSA will be refreshed in 1 second. The LSA was just refreshed, and another refresh is coming in 29 minutes and 59 seconds.

LSA type 1 LSA type 2 LSA type 3 LSA type 4 LSA type 5

The primary purpose of a default route is to reduce the sizes of the routing table and the LSDB. A default route avoids detailed updating of routes by inserting a single 0.0.0.0 route into the routing table, making this 0.0.0.0 route act as a gateway of last resort. (Source: Configuring and Verifying OSPF Route Summarization) A) B)

© 2009 Cisco Systems, Inc.

true false

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-263

Q75)

When should you use the always keyword with the default-information originate command? (Source: Configuring and Verifying OSPF Route Summarization) A) B) C) D)

Q76)

A summary LSA (type 3 LSA) is designed to automatically summarize a network into blocks. (Source: Configuring and Verifying OSPF Route Summarization) A) B)

Q77)

true false

Route summarization reduces the flooding of which two of the following LSA types? (Choose two.) (Source: Configuring and Verifying OSPF Route Summarization) A) B) C) D) E)

router network summary external NSSA

Q78)

You are at the ABR of area 1 and want to classfully summarize network 172.16.32.0 through 172.16.63.0 into area 0. Write the configuration command that you would use. (Source: Configuring and Verifying OSPF Route Summarization)

Q79)

You are at the ASBR between an OSPF area 0 and an EIGRP network. EIGRP routes are being redistributed into OSPF. Write the correct summarization command to summarize the EIGRP block 172.16.32.0 through 172.16.63.0. (Source: Configuring and Verifying OSPF Route Summarization)

Q80)

It is important that you always summarize the routes from area 0 into other areas. Suboptimal path selection can occur if you do not. (Source: Configuring and Verifying OSPF Route Summarization) A) B)

Q81)

true false

The area range command has an optional not-advertise parameter, which is used to prevent advertising of _____. (Source: Configuring and Verifying OSPF Route Summarization) A) B) C) D)

3-264

it is on by default; configuration not required when you want to send summarized routes when your default route is always in the routing table when you want the default route advertised, even if it is not in the routing table

all summary LSAs into area 0 summary LSAs that match the area range command all external LSAs external LSAs that match the area range command

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q82)

Generally, a default route is described in the routing table as an _____. (Source: Configuring and Verifying OSPF Route Summarization) A) B) C) D)

Q83)

Which command is best to use if you want to establish a default route from a router that has no default route in its routing table? (Source: Configuring and Verifying OSPF Route Summarization) A) B) C) D)

Q84)

ASBR backbone router ABR internal router

What is the correct configuration for stub area 10? (Source: Configuring and Verifying OSPF Special Area Types) A) B) C) D)

Q88)

an ABR an ASBR summary routes summary LSAs

Which type of router advertises the default into a stub area? (Source: Configuring and Verifying OSPF Special Area Types) A) B) C) D)

Q87)

true false

All of these are permitted in a stub area except which one? (Source: Configuring and Verifying OSPF Special Area Types) A) B) C) D)

Q86)

ip route 0.0.0.0 0.0.0.0 next hop address default-information originate default-information originate always static route

The area x range and network commands are similar because both use inverse masks for configuration purposes. (Source: Configuring and Verifying OSPF Route Summarization) A) B)

Q85)

O route O IA route O *E1 route O *E2 route

area 10 stub-area router ospf 10 stub area 10 stub area 10 stub no-summary

What is the meaning of the no-summary parameter of the area x stub command? (Source: Configuring and Verifying OSPF Special Area Types) A) B) C) D)

© 2009 Cisco Systems, Inc.

There is no route summarization in the stub area. No summary LSAs are sent into the stub area. No type 5 LSAs are sent into in the stub area. There are no external LSAs in the stub area.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-265

Q89)

The default route has a cost of 1 from the stub area ABR if no area default-cost command is used. (Source: Configuring and Verifying OSPF Special Area Types) A) B)

Q90)

A disadvantage of NSSA is that it does not have a totally stubby feature, like a normal stub area. (Source: Configuring and Verifying OSPF Special Area Types) A) B)

Q91)

true false

Where should you configure the area area-id stub command when you are configuring a stub area? (Source: Configuring and Verifying OSPF Special Area Types) A) B) C) D)

3-266

no-summary option on the ABR area area-id totally-stubby command on the internal routers area area-id nssa command on the internal routers default-cost command on the ABR

A stub area blocks summary LSAs (type 3 and 4 LSAs). (Source: Configuring and Verifying OSPF Special Area Types) A) B)

Q96)

O E1 route O E2 route O N2 route O I/A route

What is the difference between a stub area and a totally stubby area configuration? (Source: Configuring and Verifying OSPF Special Area Types) A) B) C) D)

Q95)

CPU utilization on routers in the stub memory requirements on routers in the stub ability to reach outside networks LSDB size on routers in the stub

An LSA type 7 appears in the routing table as an _____. (Source: Configuring and Verifying OSPF Special Area Types) A) B) C) D)

Q94)

virtual links not allowed ASBRs not allowed ABRs not allowed one way in and out of the stub area

Stub area design will not improve _____. (Source: Configuring and Verifying OSPF Special Area Types) A) B) C) D)

Q93)

true false

Which characteristic is not a prerequisite for stub areas? (Source: Configuring and Verifying OSPF Special Area Types) A) B) C) D)

Q92)

true false

on all routers in the area on the ABR on the ASBR on routers that require stub capability within the area

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q97)

In NSSA, the NSSA ABR translates type 7 LSAs into type 5 LSAs. (Source: Configuring and Verifying OSPF Special Area Types) A) B)

Q98)

The ABR injects a default route into which three types of areas? (Choose three.) (Source: Configuring and Verifying OSPF Special Area Types) A) B) C) D)

Q99)

true false

stub totally stubby NSSA totally stubby area 0

Which two types of authentication are used in OSPF? (Choose two.) (Source: Configuring and Verifying OSPF Authentication) A) B) C) D)

MD5 encrypted password simple password MD6

Q100) When OSPF authentication is configured between two routers, each router has its own unique password. (Source: Configuring and Verifying OSPF Authentication) A) B)

true false

Q101) Which three of the following are used to generate the message digest when OSPF MD5 authentication is configured? (Choose three.) (Source: Configuring and Verifying OSPF Authentication) A) B) C) D) E)

packet sequence number key ID key router ID

Q102) Which command is used to specify that OSPF simple password authentication is to be used? (Source: Configuring and Verifying OSPF Authentication) A) B) C) D) E)

ip ospf authentication simple ip ospf authentication ip ospf authentication-key ip ospf message-digest-key ip ospf authentication message-digest

Q103) Which command is used to specify that OSPF MD5 authentication is to be used? (Source: Configuring and Verifying OSPF Authentication) A) B) C) D) E)

© 2009 Cisco Systems, Inc.

ip ospf authentication simple ip ospf authentication ip ospf authentication-key ip ospf message-digest-key ip ospf authentication message-digest

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-267

Q104) When a new MD5 key is configured on a router for OSPF authentication, the router will use both the old and new keys until the new key is configured on neighboring routers. (Source: Configuring and Verifying OSPF Authentication) A) B)

true false

Q105) Which command is used to troubleshoot OSPF authentication? (Source: Configuring and Verifying OSPF Authentication) A) B) C) D)

3-268

debug ip ospf adj debug ip ospf adjacency events debug ip ospf database debug ip ospf packets

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Module Self-Check Answer Key Q1)

C

Q2)

A

Q3)

1 = B, 2 = C, 3 = A

Q4)

B

Q5)

A

Q6)

B

Q7)

C

Q8)

B

Q9)

B

Q10)

A

Q11)

B

Q12)

B

Q13)

A

Q14)

B, D

Q15)

C

Q16)

C

Q17)

C

Q18)

A

Q19)

A

Q20)

F

Q21)

A

Q22)

A

Q23)

A = 3, B = 6, C = 1, D = 7, E = 5, F = 2, G = 4

Q24)

A, C

Q25)

C

Q26)

D

Q27)

B

Q28)

B

Q29)

B

Q30)

B

Q31)

B

Q32)

B

Q33)

1 = C, 2 = A, 3 = B

Q34)

A, B

Q35)

B, C

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-269

3-270

Q36)

A, D

Q37)

B

Q38)

A, B, E

Q39)

A

Q40)

A

Q41)

B, D

Q42)

A, C

Q43)

B

Q44)

D

Q45)

B, C

Q46)

D

Q47)

C

Q48)

B

Q49)

B

Q50)

B

Q51)

D

Q52)

A

Q53)

A, C

Q54)

B

Q55)

B

Q56)

A, B, D

Q57)

A = point-to-point B = transit C = stub D = virtual link

Q58)

A = 5, B = 2, C = 3 and 4, D = 6, E = 1, F = 9 and 11, G = 7

Q59)

D

Q60)

D, E

Q61)

D

Q62)

B

Q63)

B

Q64)

B

Q65)

A

Q66)

C

Q67)

C

Q68)

C

Q69)

B, C

Q70)

A, D

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q71)

B

Q72)

A

Q73)

E

Q74)

A

Q75)

D

Q76)

B

Q77)

C, D

Q78)

area 1 range 172.16.0.0 255.255.0.0

Q79)

summary-address 172.16.32.0 255.255.224.0

Q80)

B

Q81)

B

Q82)

D

Q83)

C

Q84)

B

Q85)

B

Q86)

C

Q87)

C

Q88)

B

Q89)

A

Q90)

B

Q91)

C

Q92)

C

Q93)

C

Q94)

A

Q95)

B

Q96)

A

Q97)

A

Q98)

A, B, C

Q99)

A, C

Q100)

B

Q101)

A, C, D

Q102)

B

Q103)

E

Q104)

A

Q105)

A

© 2009 Cisco Systems, Inc.

Implementing a Scalable Multiarea Network OSPF-Based Solution

3-271

3-272

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Module 4

Implement an IPv4-Based Redistribution Solution Overview This module explains why it is necessary to manipulate routing information. Without manipulation, route redistribution between IP routing domains may result in suboptimal routing. There are also times when routing information would waste bandwidth on a router interface, because the routing information is not needed. The implementation of redistribution in a multiprotocol network using Cisco IOS features according to a given network design and requirements is a primary learning objective of this module. The lessons describe prefix lists, distribution lists, and route maps first, and then describe the controlling of routing traffic with configuration and verification steps.

Module Objectives Upon completing this module, you will be able to implement a redistribution solution in a multiprotocol network that uses Cisco IOS features to control the path selection and a loop free topology according to a given network design and requirements. This ability includes being able to meet these objectives: Identify common network performance issues Define how prefix lists work Determine how to use a prefix-list to control routing updates Determine how distribution lists work Use distribution lists to control routing updates Determine how route maps work Determine how to use route maps to control routing updates Use route-maps to filter routes

4-2

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 1

Assessing Network Routing Performance and Security Issues Overview Routing updates compete with user data for bandwidth and router resources, yet routing updates are critical because they carry the information that routers need to make sound routing decisions. To ensure that the network operates efficiently, you must control and tune routing updates. Information about networks must be sent where it is needed and filtered from where it is not needed. There is no one type of route filter that is appropriate for every situation. Therefore, the more techniques that you have at your disposal, the better your chance of having a smooth, well-run network. This lesson discusses common network performance issues and how to control the updates that are sent and received by dynamic routing protocols. Prefix lists, distribute lists, and route maps are described as the main mechanisms to filter and control routing update traffic.

Objectives Upon completing this lesson, you will be able to describe prefix lists, distribute lists, and route maps. You will also be able to explain how to use them to filter and control routing update traffic. This ability includes being able to meet these objectives: Determine common network performance issues Identify how distribute lists work Use distribute lists to control routing updates Identify how prefix lists work Use a prefix list to control routing updates Identify how route maps work

Use route maps to control routing updates Use route maps to filter routes Suppress routing updates using passive interface command

4-4

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Common Network Performance Issues This topic describes common network performance and security issues caused by update inefficiencies.

Common Factors Affecting Network Performance Routing factors that influence CPU utilization include: – The size of the routing information update – The frequency of the updates – The weaknesses in the design – The presence of any route maps or filters Incorrectly configured route filters Running different protocols in different areas within the same autonomous system – The number of routing protocol processes receiving the updates

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—4-2

Routing updates can decrease network performance. If a Layer 3-enabled switch or router receives a large number of updates, they must be processed. The CPU utilization spike during this processing depends on the following factors: The size of the routing update The frequency of the updates The number of routing protocol processes receiving the updates The presence of any route filters The weaknesses in the design Some factors are also dependent on the routing protocol. The size of routing updates and their frequency is directly proportional to the amount of traffic that must be sent over the links and processed by the CPUs. The same applies to the number of routing processes per router, where more routing processes generate more updates and require more CPU resources. Several solutions exist, and a good design and filtering may significantly improve network performance. However, the wrong design and incorrectly configured route filters will not improve network performance at all.

© 2009 Cisco Systems, Inc.

Implement an IPv4-Based Redistribution Solution

4-5

Routing Updates Qualities of routing updates that influence CPU utilization include: – The size of the routing information update – The frequency of the updates – A bad design

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—4-3

In some network deployments, high CPU utilization is normal. In general, larger Layer 2 or Layer 3 networks demand more CPU resources to process network-related traffic. Examples of operations with potentially high CPU utilization are as follows: IP routing table updates Cisco IOS commands More devices and links inside an autonomous system produce more routing update traffic. Redistribution from an external autonomous system adds to the size, as well. When a router receives a large number of routing updates, the routing information must be processed.

4-6

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Filtering Routing Updates Routing update filters may improve network performance Ensure router filters are configured correctly

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—4-4

Route filtering works by regulating the routes that are entered into or advertised out of the routing table. Filtering has different effects on link state routing protocols compared to distance vector protocols. Distance vector protocols advertise routes based on what is in the protocol’s route table. Link state protocols on the opposite side determine their routes based on the information in their link state databases. Distance vector protocols filter routes the router advertises to its neighbors; link state protocols, in contrast, do not take into account the advertised route entries of each router’s neighbors. Filters can be configured to prevent updates through router interfaces, to control the advertising of routes in routing updates, or to control the processing of routing updates. If filters are not configured correctly or if filters are applied to the wrong interfaces, network performance issues will result.

© 2009 Cisco Systems, Inc.

Implement an IPv4-Based Redistribution Solution

4-7

Running Multiple Routing Protocols You can run different protocols in different areas within the same autonomous system. – If many routing protocol processes receive updates at the same time, performance will be affected.

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—4-5

You can configure multiple routing protocols in a single router to connect networks that use different routing protocols. For example, you can run Enhanced Interior Gateway Routing Protocol (EIGRP) on one subnetted network, Open Shortest Path First (OSPF) on another subnetted network, and exchange routing information between them in a controlled fashion. Additionally, the same router can be connected to the ISP and exchange Border Gateway Protocol (BGP) routes, as well. Router R1 in the figure in the slide runs EIGRP, OSPF, and BGP. The available routing protocols were not designed to interoperate with one another, so each protocol collects different types of information and reacts to topology changes in its own way. This behavior produces a large amount of routing update traffic that must be processed by each protocol separately in a different way. For example, Routing Information Protocol (RIP) uses a hop-count metric and OSPF uses link metric information. Maintaining all routing, topology, and database tables inside the routers requires not only a great deal of CPU capacity, but also large amounts of memory resources.

4-8

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Controlling Routing Updates Design change – Limit the number of routing protocols used Passive interfaces Redistribution with route filtering – Access lists – Prefix lists – Distribute lists – Route maps

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—4-6

To increase the network performance, routing updates must be exchanged in a controlled way and the network designer must take into account the recommended design rules. The passive interface technique prevents all routing updates from being advertised out of an interface. However, in many cases you do not want to prevent all routing information from being advertised. You might want to block the advertisement of only certain specific routes. For example, you might do so to prevent routing loops when you are implementing two-way route redistribution with dual redistribution points. When routing information is being exchanged between different networks that use different routing protocols, you can use many configuration options to filter the routing information. A good design must limit the number of routing protocols running on one router, because filtering must be applied to the redistribution between different protocols. You can use various methods of filtering routes, with various effects, to increase network performance. You can use the following tools to control routing updates and redistribution: Access lists Prefix lists Distribute lists Route maps

© 2009 Cisco Systems, Inc.

Implement an IPv4-Based Redistribution Solution

4-9

Using Route Filters A neighbor relationship is established Adjacent routes exchange routing updates – The process takes effect after multiple stages have been completed

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—4-7

The figure in the slide shows how filtering is used to control incoming routing update traffic. Only inbound filtering is shown.

4-10

Step 1

A routing update arrives at a router’s interface and the router stores the packet in the interface buffer and triggers the CPU to make a decision.

Step 2

The router’s CPU checks if there is an incoming filter applied to this interface. If no filter is applied, then the routing update packet is processed normally. If a filter is applied, then the next step is taken.

Step 3

The router’s CPU checks if there is an entry for this address in the routing update packet. If there is no entry, the route is dropped. If entry exists, the next step is taken.

Step 4

The router’s CPU processes the routing update packet according to the filter configuration.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

How Distribute Lists Work This topic describes how distribute lists can be used to control routing updates.

Controlling Routing Update Traffic Using Distribute Lists

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—4-8

The ways to control or prevent dynamic routing updates are as follows: Passive interface: As previously stated, this feature prevents all routing updates from being sent through an interface. For EIGRP and Open Shortest Path First Protocol (OSPF), this method includes Hello protocol packets. Default routes: This feature instructs the router that if it does not have a route for a given destination, it should send the packet to the default route. Therefore, no dynamic routing updates about the remote destinations are necessary. Static routes: This feature allows routes to remote destinations to be manually configured in the router. Therefore, no dynamic routing updates about the remote destinations are necessary. Another way to control routing updates is a technique called a “distribute list.” A distribute list allows the application of an access list to the routing updates. You may be familiar with access lists associated with an interface and how they are used to control IP traffic. However, routers can have many interfaces, and route information can also be obtained through route redistribution, which does not involve an interface at all. Additionally, access lists do not affect traffic that is originated by the router, so applying one to an interface would have no effect on the outgoing routing advertisements. When you link an access list to a distribute list, routing updates can be controlled no matter what their source is. Configure access lists in global configuration mode, and then configure the associated distribute list under the routing protocol. The access list should permit the networks that will be advertised or redistributed, and deny the networks that will remain hidden.

© 2009 Cisco Systems, Inc.

Implement an IPv4-Based Redistribution Solution

4-11

The router then applies the access list to the routing updates for that protocol. Options in the distribute-list command allow updates to be filtered based on three factors: Incoming interface Outgoing interface Redistribution from another routing protocol Using a distribute list gives the administrator great flexibility in determining just which routes the router distributes.

4-12

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Using Distribution Lists to Control Routing Updates This topic describes how to implement and verify the distribute list route-filtering technique.

Steps to Configure Distribute List Filters Define the traffic filtering requirements to permit or deny routes using one of these two methods: – Configure an access list (ACL) – Configure a route map Configure a distribute list to use the ACL or a route map: – Apply it to the inbound or outbound updates

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1.0—4-9

When you are planning how to configure distribute list filters, you must complete the following steps and create an implementation plan for the filters: Define traffic filtering requirements to permit or deny routes using one of these two methods: —

Configure an access list

—

Configure a route map

Configure a distribute list to use the access list or route map: —

© 2009 Cisco Systems, Inc.

Apply it to the inbound or outbound updates

Implement an IPv4-Based Redistribution Solution

4-13

Configuring a Distribute List Filter A distribute list filter can be applied to transmitted, received, or redistributed routing updates. Îďř˝±˛ş·ą÷ý

®±«¬»® ®·° ®»Ľ·­¬®·ľ«¬» ±­°ş ď ł»¬®·˝ ë Ľ·­¬®·ľ«¬»ó´·­¬ ď𠱫¬ ŃÍĐÚ ď

Filtering of updates being advertised from OSPF into RIP routing protocol according to access list 10 Îďř˝±˛ş·ą÷ý

®±«¬»® Ű×ŮÎĐ ďđđ Ľ·­¬®·ľ«¬»ó´·­¬ é ·˛ Í»®·ż´đ

Filtering of networks received in updates from interface Serial0 according to access list 7 © 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 4-10

You can filter routing update traffic for any protocol by defining an access list and applying it to the specific routing protocol. You use the distribute-list command and link it to an access list to complete the filtering of routing update traffic. (The inbound distribute-list command allows the use of a route map instead of an access list.) A distribute list enables you to filter routing updates coming into a specific interface from or going out to neighboring routers using the same routing protocol. A distribute list also allows you to filter routes redistributed from other routing protocols or sources. Use the distribute-list out command to assign the access list to filter outgoing routing updates or to assign it to routes being redistributed into the protocol. The distribute-list out command cannot be used with link-state routing protocols for blocking outbound link-state advertisements (LSAs) on an interface. The distribute-list out command in the figure in the slide filters the updates being redistributed from OSPF into RIP routing protocol. Access list 10 is used to define the networks permitted or denied. Use the distribute-list in command to cause the access list to filter incoming routing updates coming in through an interface. This command prevents most routing protocols from placing the filtered routes in their databases. When this command is used with OSPF, the routes are placed in the database but not in the routing table. The distribute-list in command in the figure in the slide filters the networks received in updates from interface Serial0 according to access list 7. For more details about the distribute-list out and distribute-list in commands, please check the Cisco IOS IP Routing Protocols Command Reference via the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

4-14

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Filtering Routing Updates with a Distribute List Hides network 10.0.0.0 using interface filtering

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 4-11

The figure in the slide shows the configuration of router R2, which is hiding network 10.0.0.0 behind the serial 0 interface. The distribute-list 7 out s0 command applies access list 7 to routing updates sent out from interface serial 0 to other routers running this routing protocol. This access list permits routing information about network 172.16.0.0 only. The “implicit deny any” statement at the end of the access list prevents routing updates about any other networks from being advertised. As a result, network 10.0.0.0 is hidden from the rest of the network.

© 2009 Cisco Systems, Inc.

Implement an IPv4-Based Redistribution Solution

4-15

Controlling Redistribution with Distribute Lists

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 4-12

With redistribution, using a distribute list helps prevent all routes from being redistributed from RIP routing protocol into OSPF and vice versa. As shown in the figure in the slide, only networks 10.1.0.0 to 10.3.0.0 are redistributed from RIP into OSPF. Other networks are not permitted with access list 2 and are denied. Access list 2 allows the subset of RIP routes and denies all others. The distribute list configured under OSPF refers to this access list number 2. The same redistribution processing applies to networks 10.8.0.0 to 10.11.0.0, originated by OSPF. They can be redistributed from OSPF to RIP. Redistribution into RIP from OSPF is filtered with access list 3. The distribute list configured under RIP refers to this access list number 3 and permits only a subset of networks. A distribute list hides network information, which may be considered a drawback in some circumstances. In a network with redundant paths, the goal of using a distribute list may be to prevent routing loops. The distribute list permits routing updates that enable only the desired paths to be advertised. Therefore, other routers in the network do not know about the other ways to reach the filtered networks.

4-16

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

How Prefix Lists Work This topic describes the how prefix lists can be used to control routing updates.

IP Prefix Filters Traditionally, IP prefix filters were implemented with IP access lists configured with the distribute-list command. Prefix lists: – Better performance than access lists – User-friendly command-line interface – Match routes in part of an address space with a subnet mask longer or shorter than a set number

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 4-13

Traditionally, IP prefix filters were implemented with IP access lists configured with the distribute-list command. IP access lists used as route filters have several drawbacks: The subnet mask cannot be easily matched. Access lists are evaluated sequentially for every IP prefix in the routing update. Extended access lists can be cumbersome to configure. Using the ip prefix-list command has several benefits compared to using the access-list command. The intended use of prefix lists is limited to route filtering, where access lists were originally intended to be used for packet filtering and were then extended to route filtering. A router transforms a prefix list into a tree structure, with each branch of the tree serving as a test. The Cisco IOS software determines a verdict of either “permit” or “deny” much faster this way than when sequentially interpreting access lists. The command-line interface (CLI) that you use to configure the ip prefix-list command provides you with the ability to assign a line number to each line of the prefix list. The router will use this number to sort the entries in the prefix list. If you initially sequence the lines with some gaps in between the sequence numbers, you can insert additional lines later. You can also remove individual lines without removing the entire list. Routers match network numbers in a routing update against the prefix list using as many bits as indicated. For example, you can specify a prefix list to be 10.0.0.0/16, which will match 10.0.0.0 routes but not 10.1.0.0 routes.

© 2009 Cisco Systems, Inc.

Implement an IPv4-Based Redistribution Solution

4-17

The prefix list can specify the size of the subnet mask, and can also indicate that the subnet mask must be in a specified range. Prefix lists are similar to access lists in a number of ways. A prefix list can consist of any number of lines, each of which indicates a test and a result. The router can interpret the lines in the specified order, although Cisco IOS optimizes this for processing in a tree structure. When a router evaluates a route against the prefix list, the first line that matches will result in either a “permit” or “deny.” If none of the lines in the list match, the result is “implicitly deny.” Testing is done using prefixes. The router compares the indicated number of bits in the prefix with the same number of bits in the network number in the update. If they match, testing continues with an examination of the number of bits set in the subnet mask. The prefix list line can indicate a range in which the number must be in order to pass the test. If you do not indicate a range in the prefix line, the subnet mask must match the prefix size.

4-18

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Controlling Redistribution with Prefix Lists

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 4-14

With redistribution, a prefix list can be used instead of a distribute list. As shown in the figure in the slide, networks 10.1.0.0 to 10.3.0.0 are redistributed only from RIP into OSPF. The other networks are not permitted with the prefix list PFX1 and are denied. PFX1 allows the subset of RIP routes and denies all others. The route map into OSPF matches the networks permitted by PFX1. The same applies to networks 10.8.0.0 to 10.11.0.0, originated by OSPF. They can be redistributed from OSPF to RIP. The redistribution into RIP from OSPF is filtered with the prefix list PFX2. The route map into RIP matches networks permitted by PFX2. In a network with redundant paths, the goal of using prefix lists and route maps may be to prevent routing loops. The prefix lists permit routing updates that enable only the desired paths to be advertised. Therefore, other routers in the network do not know about the other ways to reach the filtered networks.

© 2009 Cisco Systems, Inc.

Implement an IPv4-Based Redistribution Solution

4-19

Prefix List Matching Rules Filter by exact prefix length – mask filtering “/” Filter within a range – using ge – using le – using ge and le The matching process also considers the subnet mask

© 2009 Cis co S yst em s, Inc. A ll rights reserved.

ROUTE v1. 0— 4-15

Prefix lists are configured to filter traffic based on a match of an exact prefix length or a match within a range when the ge and le keywords are used. The ge and le keywords are used to specify a range of prefix lengths. They provide a more flexible configuration than can be obtained using only the network/length arguments. A prefix list is processed using an exact match when neither the ge nor le keyword is specified. If only the ge value is specified, the range is the value entered for the ge-length argument to a full 32-bit length. If only the le value is specified, the range is from the value entered for the network/length argument to the lelength argument. If both the ge and le values are specified, the range is between the values used for the ge-length and le-length arguments. The following formula shows this behavior: length < ge-length < le-length ” when BGP has selected the path as the best path to a network. The third column is either blank or shows “i.” If it is blank, BGP learned that route from an external peer. An “i” indicates that an IBGP neighbor advertised this path to the router. © 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-77

The fourth column lists the networks that the router learned. The Next Hop column lists all the next-hop addresses for each route. This column may contain the entry 0.0.0.0, which signifies that this router is the originator of the route. The three columns to the left of the Path column list three BGP path attributes that are associated with the path: metric (multi-exit discriminator [MED]), local preference, and weight. The column with the Path header may contain a sequence of autonomous systems in the path. From left to right, the first AS listed is the adjacent AS, from which this network was learned. The last number (the rightmost AS number) is the originating AS of this network. The AS numbers between these two numbers represent the exact path that a packet takes back to the originating AS. If the path column is blank, the route is from the current AS. The last column signifies how this route was entered into BGP on the original router. If the last column has an “i” in it, the originating router probably used a network statement to introduce this network into BGP. If the character is an “e,” the originating router learned this network from exterior gateway protocol (EGP), which is the historical predecessor to BGP. A question mark (?) signifies that BGP cannot absolutely verify the availability of this network because it is redistributed from an IGP into BGP.

6-78

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Example: show ip bgp rib-failure Command Displays networks that are not installed in the RIB and the reason that they were not installed.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v 1.0—6-26

Use the show ip bgp rib-failure command to display BGP routes that were not installed in the Routing Information Base (RIB) table and the reason that the routes were not installed. The example in the figure above shows that the displayed routes were not installed because a route or routes with a better administrative distance already exist in the RIB. For more details about show ip bgp rib-failure command, please check the Cisco IOS IP Routing Protocols Command Reference on the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-79

Clearing the BGP Session When policies change, the change takes effect immediately. The next time that a prefix or path is advertised or received, the new policy is used. This can take a long time for all networks. You must trigger an update for immediate action. Ways to trigger an update: – Hard reset – Soft reset – Route refresh

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v 1.0—6-27

BGP can potentially handle huge volumes of routing information. When a policy configuration change occurs, the router cannot go through the huge table of BGP information and recalculate which entry is no longer valid in the local table; nor can the router determine which route or routes, already advertised, should be withdrawn from a neighbor. There is an obvious risk that the first configuration change will be immediately followed by a second, which would cause the whole process to start all over again. To avoid such a problem, Cisco IOS Software applies changes only to those updates that are received or transmitted after the BGP policy configuration change has been performed. The new policy, enforced by the new filters, is applied only on routes that are received or sent after the change. A network administrator who would like the policy change to be applied on all routes must trigger an update to force the router to let all routes pass through the new filter. If the filter is applied on outgoing information, the router has to resend the BGP table through the new filter. If the filter is applied on incoming information, the router needs its neighbor to resend its BGP table so that it passes through the new filters. There are three ways to trigger an update: with a hard reset, soft reset, or route refresh.

6-80

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Hard Reset of BGP Sessions A BGP session makes the transition from established to idle; everything must be relearned. Îîý

˝´»ż® ·° ľą° ö

Resets all BGP connections with this router. The entire BGP forwarding table is discarded. Îîý

˝´»ż® ·° ľą° ďđňďňďňî

Resets only a single neighbor. Less severe than a clear ip bgp * command.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v 1.0—6-28

Resetting a session is a method of informing the neighbor or neighbors of a policy change. If BGP sessions are reset, all information received on those sessions is invalidated and removed from the BGP table. Also, the remote neighbor will detect a BGP session down state and will invalidate the routes that were received. After 30 to 60 seconds, the BGP sessions are reestablished automatically and the BGP table is exchanged again, but through the new filters. However, resetting the BGP session disrupts packet forwarding. Both commands that are shown in the figure above cause a hard reset of the BGP neighbors that are involved. A hard reset means that the router issuing either of these commands will close the appropriate TCP connections, reestablish those TCP sessions as appropriate, and resend all information to each of the neighbors affected by the particular command that is used. The clear ip bgp * command causes the BGP forwarding table on the router that issued this command to be completely deleted, and all networks must be relearned from every neighbor. If a router has multiple neighbors, this action is a very dramatic event. This command forces all neighbors to resend their entire tables simultaneously. For example, consider a situation in which router R1 has eight neighbors and each neighbor has a full Internet table of about 32 MB in size. If router R1 issues the clear ip bgp * command, all eight routers resend their 32-MB tables at the same time. To hold all these updates, router R1 would need 256 MB of RAM. Router R1 would also need to be able to process all of this information. Processing 256 MB of updates would take a considerable number of CPU cycles for router R1, further delaying the routing of user data. If the second command, clear ip bgp 10.1.1.2, is used instead, one neighbor is reset at a time. The impact is less severe on the router that is issuing this command; however, it takes longer to change policy for all of the neighbors, because each must be done individually rather than all at once as with the clear ip bgp * command. The clear ip bgp command still performs a hard reset and must reestablish the TCP session with the specified address, but this command affects only a single neighbor at a time.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-81

For more details about clear ip bgp command, please check the Cisco IOS IP Routing Protocols Command Reference on the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

6-82

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Soft Reset Outbound Îîý

˝´»ż® ·° ľą° ďđňďňďňî ­±ş¬ ±«¬

Routes learned from this neighbor are not lost. This router resends all BGP information to the neighbor without resetting the connection. This option is highly recommended when you are changing the outbound policy. The soft out option does not help if you are changing an inbound policy.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v 1.0—6-29

The soft out option of the clear ip bgp command causes BGP to do a soft reset for outbound updates. The router issuing the clear ip bgp 10.1.1.2 soft out command does not reset the BGP session; instead, the router creates a new update and sends the whole table to the specified neighbor. This update includes withdrawal commands for the networks that the other neighbor will not see anymore based on the new outbound policy. Note

© 2009 Cisco Systems, Inc.

The soft keyword of this command is optional; clear ip bgp out does a soft reset for outbound updates.

Connecting an Enterprise Network to an ISP Network

6-83

Inbound Soft Reset Îîř˝±˛ş·ąó®±«¬»®÷ý

˛»·ą¸ľ±® ďđňďňďňî ­±ş¬ó®»˝±˛ş·ą«®ż¬·±˛ ·˛ľ±«˛Ľ

This router stores all updates from this neighbor in case the inbound policy is changed. The command is memory intensive. Îîý

˝´»ż® ·° ľą° ďđňďňďňî ­±ş¬ ·˛

Uses the stored information to generate new inbound updates.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v 1.0—6-30

There are two ways to perform an inbound soft reconfiguration: using stored routing update information, as shown in the figure above, and dynamically, as shown in the next figure. Enter the neighbor command that is shown in the figure above to inform BGP to save all updates that were learned from the neighbor specified. The BGP router retains an unfiltered table of what that neighbor has sent. When the inbound policy is changed, use the clear ip bgp command shown in the figure above. The stored unfiltered table is used to generate new inbound updates; the new results are placed in the BGP forwarding database. Thus, if changes are made, the other side does not have to be forced to resend everything.

6-84

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Route Refresh: Dynamic Inbound Soft Reset Îîý

˝´»ż® ·° ľą° Ąö¤ďđňďňďňîŁ Ĺ­±ş¬ ·˛ ¤ ·˛Ă

Routes advertised to this neighbor are not withdrawn Does not store update information locally The connection remains established Introduced in Cisco IOS Software Release 12.0(2)S and 12.0(6)T

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v 1.0—6-31

Cisco IOS Software Releases 12.0(2)S and 12.0(6)T introduced a BGP soft reset enhancement feature, also known as “route refresh,” which provides automatic support for dynamic soft reset of inbound BGP routing table updates, and is not dependent upon stored routing table update information. The clear ip bgp soft in command implements this feature. This method requires no preconfiguration and requires significantly less memory than the previous soft method for inbound routing table updates. The soft in option generates new inbound updates without resetting the BGP session, but it can be memory intensive. BGP does not allow a router to force another BGP speaker to resend its entire table. If the inbound BGP policy is changed and a hard reset is not to be completed, configure the router to perform a soft reconfiguration. Note

To determine whether a BGP router supports this route refresh capability, use the show ip bgp neighbors command. The following message is displayed in the output when the router supports the route refresh capability: λ˝»·Ş»Ľ ®±«¬» ®»ş®»­¸ ˝ż°żľ·´·¬§ ş®±ł °»»® If all BGP routers support the route refresh capability, use the clear ip bgp {* | address | peer-group-name} in command. It is not necessary to use the soft keyword because soft reset is automatically assumed when the route refresh capability is supported.

Note

© 2009 Cisco Systems, Inc.

The clear ip bgp soft command performs a soft reconfiguration of both inbound and outbound updates.

Connecting an Enterprise Network to an ISP Network

6-85

Monitoring Soft Reconfiguration

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v 1.0—6-32

When a BGP session is reset and soft reconfiguration is used, several commands exist to monitor the BGP routes that are received, sent, or filtered. The following commands can be used: show ip bgp neighbor address received show ip bgp neighbor address routes show ip bgp show ip bgp neighbor address advertised

6-86

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

debug ip bgp updates Command

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v 1.0—6-33

The figure above shows a partial output from the debug ip bgp updates command on router R1 after the clear ip bgp command is issued to clear the BGP sessions with its IBGP neighbor 10.1.0.2. After the neighbor adjacency is reestablished, router R1 creates and sends updates to 10.1.0.2. The first update highlighted in the figure, “10.1.1.0/24, next 10.1.0.1,” is an update about network 10.1.1.0/24, with a next hop of 10.1.0.1, which is the address of router R1. The second update highlighted in the figure, “10.97.97.0/24, next 172.31.11.4,” is an update about network 10.97.97.0/24, with a next hop of 172.31.11.4, which is the address of one of the EBGP neighbors of router R1. The EBGP next-hop address is being carried into IBGP. Router R1 later receives updates from 10.1.0.2. The update highlighted in the figure contains a path to two networks, 10.1.2.0/24 and 10.1.0.0/24. The attributes shown in this update are described in the next lesson. Note

Debugging uses up router resources and should be turned on only when necessary.

For more details about debug ip bgp updates command, please check the Cisco IOS Debug Command Reference on the following link: http://www.cisco.com/en/US/docs/ios/debug/command/reference/db_book.html

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-87

Summary This topic summarizes the key points that were discussed in this lesson.

Summary For a BGP configuration, the following must be defined: BGP requirements, BGP parameters, and connectivity. BGP is configured with the following basic BGP commands: router bgp autonomous-system, neighbor ip-address remoteas autonomous-system, network network-number [mask network-mask] The neighbor shutdown command administratively shuts down a BGP neighbor. When creating a BGP packet, the neighbor statement defines the destination IP address and the outbound interface defines the source IP address.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v 1.0—6-34

Summary (cont.) When establishing a BGP session, the BGP goes through the following states: idle, connect, open sent, open confirm, and established. You can configure MD5 authentication between two BGP peers, which means that each segment sent on the TCP connection between the peers is verified. One EBGP neighbor exists in a single-homed environment. The show and debug commands are used to troubleshoot the BGP session.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

6-88

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v 1.0—6-35

© 2009 Cisco Systems, Inc.

Lesson 5

Lab 6-1 Debrief Overview In Lab 6-1, students configure Border Gateway Protocol (BGP) operations. Given a routed network, students simulate multihomed Internet service provider (ISP) connections and configure External BGP (EBGP) on the enterprise router to connect to the two ISPs. After completing the lab, the instructor will lead the discussion about lab topology, tasks, verification, and checkpoints, as well as sample solutions and different alternatives. Students will present their implementation plan and solution.

Objectives Upon completing this lesson, you will be able to explain the lab topology, configure BGP operations, create checkpoints for configuration and verification, and find alternative solutions. This ability includes being able to meet these objectives: Compare your solution, findings, and action log against a set of checkpoints provided by the instructor and identify common and alternative solutions. Consolidate the lessons learned during the review discussions into a set of best practice methods and commands to aid you in future troubleshooting procedures.

Lab Overview and Verification This topic describes the lab topology and key checkpoints used to create a solution and begin verification.

Lab Topology

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-2

The figure above presents a logical lab topology used for configuration of a BGP operations lab. The topology uses four pod routers, which are members of an Internal BGP (IBGP) relationship, and two backbone routers, which are members of an EBGP relationship. The lab is preconfigured with addressing, including loopbacks and an IGP routing protocol. Based on the topology, students can create a basic BGP operations configuration, including entering BGP processes, creating neighbors, advertising networks, as well as utilizing additional BGP options including synchronization, peer groups, and authentication.

6-90

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab Review: What did you accomplish? Task 1 – Cleaning Up What steps did you take to remove unnecessary configuration? How did you create the initial configuration?

Task 2 – Configuring BGP What is needed to configure basic BGP? What steps did you take to configure neighbors, advertise networks, and verify the configuration?

Task 3 – Configuring BGP authentication Which authentication type did you select? How can you verify MD5 authentication?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-3

The lab consists of three tasks. Students need an implementation plan to fulfill the lab requirements. In the first task, students need to perform lab cleanup, in which the previous configuration is erased and the lab is prepared with an initial configuration supporting Lab 6-1, “Configure BGP Operations.” In the second task, students configure basic BGP steps from entering the BGP process to neighbor definition and network advertisements. In the third task, students configure additional BGP configuration options including Message Digest 5 (MD5) authentication, and learn additional commands used for better reachability of next hop between IBGP and EBGP neighbors.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-91

Verification Is your solution working? What method did you follow to verify the status of all BGP connections? Which commands did you use to verify the following information? – Display information about BGP and TCP connections to neighbors – Display the parameters and current state of the active routing protocol process – Display entries in the BGP routing table

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-4

After each configuration task, verification takes place where students check their configurations. Several show commands are used during the verification process showing many parameters of the BGP process and neighbor relationship. Verification includes use of the following commands: show ip bgp summary: Displays the status of all BGP connections. show ip bgp neighbors: Displays information about BGP and TCP connections to neighbors. show ip protocols: Displays the parameters and current state of the active routing protocol process. show ip bgp: Displays entries in the BGP routing table.

6-92

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Check Points BGP process and AS number Neighbor relationship status Advertise networks BGP routing information base BGP routes BGP protocol Default route Authentication

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-5

During the configuration and verification phase, a network operator can deal with several checkpoints. After completing all configuration tasks, BGP configuration can be successfully completed or additional verification and troubleshooting is needed. Optionally, a network operator can check the BGP configuration in different stages of the implementation using the checkpoints at each stage. With different checkpoints, a network operator can check for proper configuration with the following steps: Check BGP process and autonomous system (AS) number Check neighbor relationship status Check which networks are advertised Check BGP routing information base Check BGP routes Check BGP protocol Check for default route Check authentication

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-93

Sample Solutions and Alternatives This topic describes a sample solution and other alternatives.

Sample Solution Configure BGP process Define neighbors Advertise networks Define default route Configure authentication

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-6

A sample solution includes configuration steps for each of the tasks. Different solutions are possible and the figure above points out the important tasks needed for a successful configuration. To be able to successfully complete the lab configuration, use the following guidelines: Enter the BGP process using the correct AS number. Define neighbors using a directly connected interface (EBGP) or loopback interface (IBGP). Advertise the local networks into BGP using a network statement with the mask keyword. Define the default route inside IGP that is used inside the AS. Configure authentication on both neighbors.

6-94

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternative Solutions BGP process – Different AS numbers and connectivity options EBGP/IBGP neighbors – update-source command Advertise networks – next-hop-self, synchronization

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-7

Same or similar results can be achieved by using different configuration steps. When entering a BGP process, different AS numbers can be used between the neighbors. An EBGP or IBGP neighbor relationship is defined based on which AS number is used among the neighboring routers. EBGP and IBGP relationships have different connectivity rules. An EBGP neighbor relationship is established between the directly connected neighbors and an IBGP neighbor relationship does not have this requirement. Loopbacks are used for IBGP neighbor relationships. Networks are advertised with the next-hop attribute, which is processed in a different way based on an EBGP or IBGP neighbor relationship. The next-hop attribute can be changed, as well as the network advertisement between the EBGP and IBGP neighbors.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-95

Q and A 1. Why is the AS number important? 2. Why is the neighbor IP address important? 3. Why is authentication necessary?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-8

The AS number is important when creating neighbors because AS numbers define the EBGP or IBGP relationship. An IP address used during neighbor configuration is important because EBGP neighbors require directly connected neighbors rather than IBGP neighbors where there is no need to be directly connected. The synchronization rule says that a router will not advertise routes in BGP until it learns the routes in an IGP. It is safe to have the synchronization rule off only if all routers in the transit path in the AS are running full-mesh IBGP. Authentication in BGP is used to verify that only trusted neighbors establish the neighbor relationship. If some other routers configured for BGP are added to the system, they cannot attract traffic and establish the neighbor relationship.

6-96

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary Create a good implementation plan and define the BGP requirements before configuring BGP operations. Several solutions exist and alternative solutions give similar or very different results.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1. 0—6-9

Connecting an Enterprise Network to an ISP Network

6-97

6-98

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 6

Using the BGP Attributes and Path Selection Process Overview Border Gateway Protocol (BGP) is used to perform policy-based routing. In order to manipulate the best paths chosen by BGP, a network administrator must understand the different attributes that BGP uses and how BGP selects the best path based on these attributes. This lesson explains the BGP path selection process and the BGP attributes and their characteristics, and discusses configuration steps using different attributes for selecting a BGP path. Route filtering using route maps and prefix lists is described as well.

Objectives Upon completing this lesson, you will be able to configure and verify BGP operations in a multihomed environment using the BGP attributes and route maps to control all BGP routes to and from the router. This ability includes being able to meet these objectives: Understand the BGP path selection process. Identify the characteristics of BGP attributes for path selection and path manipulation. Configure filtering of BGP routing updates.

BGP Path Selection This topic describes the criteria for selecting a BGP path.

BGP Path Selection The BGP table can have several paths for each network to choose from BGP is not designed to perform load balancing: – Paths are chosen because of policy. – Paths are not chosen based upon bandwidth. The BGP selection process eliminates any multiple paths until a single best path remains.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-2

Routers often have several neighbors and receive routing updates from each neighbor. All routing updates enter the BGP forwarding table, and as a result, multiple paths may exist to reach a given network. The whole BGP forwarding table can be displayed using the show ip bgp command. Next, paths for the network are evaluated to determine which path is best. Paths that are not the best are eliminated from the selection criteria but kept in the BGP forwarding table in case the best path becomes inaccessible. If one of the best paths is not accessible, then a new best path must be selected. BGP is not designed to perform load balancing; paths are chosen based on policy, not based on bandwidth. The BGP selection process eliminates any multiple paths until a single best path remains.

6-100

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Routing Table Manager The best path is submitted to the routing table manager process. The best path is evaluated against the routes of other routing protocols for reaching that network. The route with the lowest administrative distance from the source will be installed in the routing table.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-3

The best path is submitted to the routing table manager process and is evaluated against any other routing protocols that can also reach that network. The router usually runs BGP and one of the interior gateway protocols (IGP) (such as Routing Information Protocol [RIP], Enhanced Interior Gateway Routing Protocol [EIGRP], Open Shortest Path First [OSPF], and so on), which are sending candidates for the routing table to the routing table manager. The route from the source with the lowest administrative distance is installed in the routing table. The whole routing table can be displayed using the show ip route command.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-101

Route Selection Decision Process Consider only (synchronized) routes with no AS loops and a valid next hop. The next steps in the evaluation process are: 1.

Prefer highest weight (local to router).

2.

Prefer highest local preference (global within AS).

3.

Prefer route originated by the local router (next hop = 0.0.0.0).

4.

Prefer shortest AS path.

5.

Prefer lowest origin code (IGP < EGP < incomplete).

6.

Prefer lowest MED (exchanged between autonomous systems).

7.

Prefer the EBGP path over the IBGP path.

8.

Prefer the path through the closest IGP neighbor.

9.

Prefer the oldest route for EBGP paths.

10.

Prefer the path with the lowest neighbor BGP router ID.

11.

Prefer the path with the lowest neighbor IP address.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-4

After BGP receives updates about different destinations from different autonomous systems, it chooses the single best path to reach a specific destination. The decision process is based on the BGP attributes. When faced with multiple routes to the same destination, BGP chooses the best route for routing traffic toward the destination. BGP considers only synchronized routes with no autonomous system loops and a valid next hop. The following process summarizes how BGP chooses the best route on a Cisco router: 1. Prefer the route with the highest weight. (Recall that the weight is proprietary to Cisco and is local to the router only.) 2. If multiple routes have the same weight, prefer the route with the highest local preference. (Recall that the local preference is used within an autonomous system.) 3. If multiple routes have the same local preference, prefer the route that the local router originated. A locally originated route has a next hop of 0.0.0.0 in the BGP table. 4. If none of the routes were locally originated, prefer the route with the shortest autonomous system path. 5. If the autonomous system path length is the same, prefer the lowest origin code (IGP < EGP < incomplete).

6-102

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

6. If all origin codes are the same, prefer the path with the lowest multiexit discriminator (MED). (Recall that the MED is exchanged between autonomous systems.) The MED comparison is made only if the neighboring autonomous system is the same for all routes considered, unless the bgp always-compare-med command is enabled. Note

The most recent Internet Engineering Task Force (IETF) decision regarding BGP MED assigns a value of infinity to the missing MED, making the route lacking the MED variable the least preferred. The default behavior of BGP routers running Cisco IOS Software is to treat routes without the MED attribute as having a MED of 0, making the route lacking the MED variable the most preferred. To configure the router to conform to the IETF standard, use the bgp bestpath missing-as-worst command.

7. If the routes have the same MED, prefer external paths (EBGP) to internal paths (Internal BGP, or IBGP). 8. If synchronization is disabled and only internal paths remain, prefer the path through the closest IGP neighbor. This step means that the router will prefer the shortest internal path within the autonomous system to reach the destination (the shortest path to the BGP next hop). 9. For EBGP paths, select the oldest route to minimize the effect of routes going up and down (flapping). 10. Prefer the route with the lowest neighbor BGP router ID value. 11. If the BGP router IDs are the same, prefer the router with the lowest neighbor IP address. Only the best path is entered in the routing table and propagated to the BGP neighbors of the router. Note

The route selection process summarized here does not cover all cases but is sufficient for a basic understanding of how BGP selects routes.

For example, suppose there are seven paths to reach network 10.0.0.0. None of the paths have autonomous system loops and all paths have valid next-hop addresses, so all seven paths proceed to Step 1, which examines the weight of the paths. All seven paths have a weight of 0, so all paths proceed to Step 2, which examines the local preference of the paths. Four of the paths have a local preference of 200, and the other three have local preferences of 100, 100, and 150. The four with a local preference of 200 will continue the evaluation process in the next step. The other three will still be in the BGP forwarding table, but are currently disqualified as the best path. BGP will continue the evaluation process until only a single best path remains. The single best path that remains will be submitted to the IP routing table as the best BGP path.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-103

Path Selection with Multihomed Connection An autonomous system rarely implements BGP with only one EBGP connection. This situation generally means that multiple paths exist for each network in the BGP forwarding database. If only one path exists and it is loop-free and synchronized with the IGP for IBGP, and the next hop is reachable, the path is submitted to the IP routing table. There is no path selection taking place because there is only one path and manipulating it will derive no benefit. Only the best path is put in the routing table and propagated to the router’s BGP neighbors. Without route manipulation, the most common reason for path selection is Step 4, prefer the shortest autonomous system path. Step 1 looks at weight, which by default is set to 0 for routes that were not originated by this router. Step 2 compares local preference which, by default, is set to 100 for all networks. Both of these steps have an effect only if the network administrator configures the weight or local preference to a nondefault value. Step 3 looks at networks that are owned by this autonomous system. If one of the routes is injected into the BGP table by the local router, the local router prefers it to any routes received from other BGP routers. Step 4 selects the path that has the fewest autonomous systems to cross. This is the most common reason a path is selected in BGP. If a network administrator does not like the path with the fewest autonomous systems, the administrator needs to manipulate the weight or local preference to change which outbound path BGP chooses. Step 5 looks at how a network was introduced into BGP. This introduction is usually either with network statements (i for an origin code) or through redistribution (? for an origin code). Step 6 looks at MED to judge where the neighbor autonomous system wants this autonomous system to send packets for a given network. Cisco sets the MED to 0 by default; therefore, MED does not participate in path selection unless the network administrator of the neighbor autonomous system manipulates the paths using MED. If multiple paths have the same number of autonomous systems to traverse, the second most common decision point is Step 7, which states that an externally learned path from an EBGP neighbor is preferred over a path learned from an IBGP neighbor. A router in an autonomous system prefers to use the bandwidth of the Internet service provider (ISP) to reach a network rather than using internal bandwidth to reach an IBGP neighbor on the other side of its own autonomous system. If the autonomous system path is equal and the router in an autonomous system has no EBGP neighbors for that network (only IBGP neighbors), it makes sense to take the quickest path to the nearest exit point. Step 8 looks for the closest IBGP neighbor; the IGP metric determines what “closest” means (for example, RIP uses hop count, and OSPF uses the least cost, based on bandwidth).

6-104

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

If the autonomous system path is equal and the costs via all IBGP neighbors are equal, or if all neighbors for this network are EBGP, the oldest path, Step 9, is the next common reason for selecting one path over another. EBGP neighbors rarely establish sessions at exactly the same time. One session is likely older than another, so the paths through that older neighbor are considered more stable because those paths have been up for a longer period of time. If all of the above criteria are equal, the next most common decision is to choose the neighbor with the lowest BGP router ID, which is Step 10. If the BGP router IDs are all the same (for example, if the paths are to the same BGP router), Step 11 states that the route with the lowest neighbor IP address is used.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-105

Characteristics of BGP Attributes for Path Selection and Path Manipulation BGP attributes inform the BGP routers receiving updates about how to treat the paths to the final network. This topic describes the characteristics of the BGP attributes that affect path selection.

Weight Attribute Weight is an attribute that is proprietary to Cisco. Weight is not sent to any BGP neighbors. It is local to the router only. Paths with the highest weight value are preferred.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-5

The weight attribute is an attribute that Cisco defines for the path selection process. The weight is configured locally on a router and is not propagated to any other routers. This attribute applies when one router is used with multiple exit points out of an autonomous system, as opposed to the local preference attribute, which is used when two or more routers provide multiple exit points. The weight can have a value from 0 to 65535. Paths that the router originates have a weight of 32768 by default, and other paths have a weight of 0 by default. Routes with a higher weight are preferred when multiple routes exist to the same destination. In the figure above, routers R2 and R4 learn about network 172.20.0.0 from autonomous system (AS) 65020 and propagate the update to router R1. Router R1 has two ways to reach 172.20.0.0, and it must decide which route to take—the path through router R2 or the path through router R4. In the example, router R1 sets the weight of updates coming from router R2 to 200 and the weight of those coming from router R4 to 150. Because the weight for the route pointing to router R2 is higher than the weight for route pointing to router R4, router R1 uses router R2 as a next hop to reach 172.20.0.0.

6-106

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Set Weight with Route Map First BGP path selection criteria Prefer the highest weight (local to router) BGP weight can be specified per neighbor by a complex criteria with route maps

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-6

One way of changing the path selection is to use weights. Weight is an attribute that is locally significant to a router. Weight is a property or parameter. Therefore, it is not seen on any neighboring routers. When designing BGP networks using weights, network administrators should set the weights on every router. If there is more than one path for the same network, a router will choose the one with the highest weight. The default value for weight is 0. When a route map is applied, it is configured on the router. The route map can be arbitrarily complex and select routes based on various selection criteria, such as a network number or AS path. The selected routes can have some altered attributes. The route map can set the weight values of permitted routes. Selection can be done in several route-map statements, giving the opportunity to assign a certain weight value to some routes and another weight value to others. A route map can also completely filter out routes. AS path filters, prefix lists, or other BGP attributes are used to match routes, where any combination can be used. Routes that are not matched are discarded.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-107

Using Route Maps for Path Selection Îîř˝±˛ş·ą÷ý

®±«¬»ółż° ÓÇó᫬»óÓż° °»®ł·¬ ďđ

Enter route map configuration mode. Îîř˝±˛ş·ąó®±«¬»ółż°÷ý

łż¬˝¸ ´±˝ż´ó°®»ş»®»˛˝» ďëđ ­»¬ ©»·ą¸¬ îđđ

Match on the BGP attribute. Set the new value for the BGP attribute. Îîř˝±˛ş·ąó®±«¬»®÷ý

˛»·ą¸ľ±® ďđňđňđňď ®±«¬»ółż° ÓÇó᫬»óÓż° ·˛¤±«¬

Apply the route map to the incoming or outgoing updates.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-7

Three steps are needed when using route maps for path selection. In the first step, a route map must be created. Use the route-map command in global configuration mode to create a route map and to enter route map configuration mode. In the second step a rule for changing the BGP attributes is created. Use the match command in route-map configuration mode to define which incoming or outgoing updates will be affected. Use the set command in route-map configuration mode to change selected BGP attributes. The last step is required to apply a configured route map to incoming or outgoing routes. Use the neighbor route-map command in router configuration mode to apply the route map to BGP updates. For more details about the route-map, match, set, and neighbor route-map commands, please check the Cisco IOS IP Routing Protocols Command Reference on the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

6-108

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Set Weight with Route Map Example

䱫¬°«¬ ±ł·¬¬»Ľâ ˙ ®±«¬»® ľą° ęëđě𠲻·ą¸ľ±® ďđňđňđňď ®±«¬»ółż° ÎÓóÍŰĚóÉ»·ą¸¬ ·˛ ˙ ®±«¬»ółż° ÎÓóÍŰĚóÉ»·ą¸¬ °»®ł·¬ ďđ łż¬˝¸ ż­ó°ż¬¸ ďđ ­»¬ ©»·ą¸¬ ďëđ ˙ ®±«¬»ółż° ÎÓóÍŰĚóÉ»·ą¸¬ °»®ł·¬ çç ­»¬ ©»·ą¸¬ ďđđ ˙ ·° ż­ó°ż¬¸ ż˝˝»­­ó´·­¬ ďđ °»®ł·¬ Áęëđîđü © 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-8

In the example above, the routing policy dictates the selection of AS 65030 as the primary way out of AS 65040 for the traffic destined to any network originated by AS 65020. This limitation is achieved by placing a high weight of 150 on all incoming announcements from AS65030 (that is, from neighbor 10.0.0.1), which carry the information about the network originated in AS 65020.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-109

Local Preference Attribute Used to select the outbound EBGP path Sent to IBGP neighbors only (and only within the AS) Stripped in the outgoing EBGP updates except in the EBGP updates with confederation peers The local preference attribute is well known and discretionary Default value = 100 Paths with the highest local preference value are preferred

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-9

Local preference is a well-known discretionary attribute that provides information to routers in the autonomous system about the path that is preferred for exiting the autonomous system. A path with a higher local preference is preferred. The local preference is an attribute that is configured on a router and exchanged among routers within the same autonomous system only. The default value for local preference on a Cisco router is 100. To change the default local preference value of 100, use the bgp default local-preference command. In the figure above, AS 65050 receives updates about network 172.16.0.0 from two neighbors. Each of the networks is advertising a different path to the destination. The local preference on router R1 for network 172.16.0.0 is set to 200, and the local preference on router R2 for network 172.16.0.0 is set to 150. Because the local preference information is exchanged within AS 65050, all routers are aware of the exit point for network 172.16.0.0 out of AS 65050. In the figure, router R1 is configured with higher local preference than router R2 and all the traffic destined for network 172.16.0.0 will be sent to router R1 as an exit point from AS 65050. For more details about the route bgp default local-preference command, please check the Cisco IOS IP Routing Protocols Command Reference on the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

6-110

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Set Local Preference with Route Map Second BGP path selection criteria Prefer highest local preference (global within AS) Local preference can be set when – processing incoming route updates – doing redistribution – sending outgoing route updates BGP local preference can be specified per neighbor by complex criteria with route maps

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—6-10

Using BGP in autonomous systems with a single neighbor relationship usually does not require any advanced features. In multihomed situations however, it is important to ensure that the customer routers choose the correct link. Local preference is the second-strongest criterion in the route selection process. If there are two or more paths available for the same network, a router will first compare weight, and if the weights are equal for all paths, the router will then compare the local preference attributes. The path with the highest local preference value will be preferred. The default value for local preference is 100. Local preference is similar to weight because it is an attribute. It can be set once and can then be viewed on neighboring routers without having to reset it. This attribute has a default value of 100, which the router will apply to locally originated routes and updates that come in from external neighbors. Updates that come from internal neighbors already have the local preference attribute. The local preference attribute is automatically stripped from outgoing updates to External Border Gateway Protocol (EBGP) sessions. This practice means that this attribute can be used only within a single AS to influence the route selection process. BGP local preference can be specified per neighbor by complex criteria using route maps. AS path filters, prefix lists, and other BGP attributes are used to match routes, where any combination can be used. Routes that are not matched are discarded.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-111

Set Local Preference with Route Map (Cont.)

R1#

ä ±«¬° «¬ ±ł· ¬¬»Ľâ ˙ ® ±«¬» ® ľą° ęěëî𠲻·ą¸ ľ±® ď đňđň đňď ® ±«¬» ółż° ÎÓóÍ ŰĚóÔĐ ·˛ ˙ ® ±«¬» ółż° Î ÓóÍŰĚóÔĐ °»®ł ·¬ ďđ ­»¬ ´ ±˝ż´ó °®»ş »®»˛ ˝» ďë đ © 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—6-11

In the example above, the routing policy dictates the selection of AS 65030 as the primary way out of the AS 65040. This limitation is achieved by placing a local preference that is higher than the default local preference of 150 on all incoming announcements from AS 65040; that is, from neighbor 10.0.0.1. Updates entering AS 65040 from AS 65030 will be processed by all BGP routers inside AS 65040 and these updates will be preferred to other updates having the default local preference.

6-112

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Set AS Path with Route Map Fourth BGP path selection criteria Prefer shorter AS paths (only length is compared) Influences the outbound path selection in a multihomed AS Manual manipulation of AS path length—AS path prepending AS path prepending can be specified per neighbor by complex criteria with route maps (AS path filters, prefix lists, or other BGP attributes that match the routes in any combination)

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—6-12

When connections to multiple providers are required, it is important that BGP selects the optimum route for traffic to use. The optimum, or best, route may not be what the network designer intended based on design criteria, administrative policies, or corporate mandate. It is fairly easy for an AS to select the appropriate path for outgoing traffic. It is much more complicated to influence other autonomous systems to select the appropriate path for traffic that is returning to a specific AS. It is unlikely that the operator of an AS can request changes in router configurations in another AS. This limitation makes it virtually impossible to influence another AS to select the desired path based on the weight and local preference attributes, because both options would require configuration changes in the neighboring AS. If no BGP path selection tools are configured on the route to influence the traffic flow, BGP will use the shortest AS path—the fourth option in the path selection process. If the AS path is not manually manipulated by some administrative means, the path going over the fewest number of autonomous systems is selected by the router regardless of available bandwidth. However, if the AS that is attempting to influence the incoming traffic flow is sending out EBGP updates with a manipulated AS path attribute over that undesired path, the receiver of this update is less likely to select it as the best because the AS path now appears to be longer. AS path prepending potentially allows the customer to influence the route selection of its service providers. The AS path is extended with multiple copies of the AS number of the sender. There is no exact mechanism to calculate the required prepended AS path length. The benefit of manipulating AS paths to influence route selection is that the configuration that is needed is done in the AS that is requesting a desired return path.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-113

Set AS Path with Route Map (Cont.)

ßýR1# ä ±«¬° «¬ ±ł· ¬¬»Ľâ ˙ ® ±«¬» ® ľą° ęëđě𠲻·ą¸ ľ±® ď éîňď ęňďň ď ®±« ¬»ół ż° ÎÓ óÍŰĚó ßÍĐż ¬¸ ±«¬ ˙ ® ±«¬» ółż° Î ÓóÍŰĚóßÍ Đż¬¸ °»®ł ·¬ ďđ ­»¬ ż ­ó°ż¬ ¸ °® »°»˛ Ľ ęëđ ěđ ęë đěđ ęëđěđ

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—6-13

AS paths can be manipulated by prepending AS numbers to existing AS paths. Normally, AS path prepending is performed on outgoing EBGP updates over the undesired return path. Because the AS paths sent over the undesired link become longer than the AS path sent over the preferred path, the undesired link is now less likely to be used as the return path. The length of the AS path is extended because additional copies of the AS number of the sender are prepended to the AS path attribute. To avoid clashes with BGP loop prevention mechanisms, no other AS number, except that of the sending AS, should be prepended to the AS path attribute. If another AS number is prepended in the AS path, the routers in the AS that has been prepended will reject the update because of BGP loop prevention mechanisms. Prepending can be configured on a router for all routing updates that are sent to a neighbor or only on a subset of these updates. In the example, all updates sent to neighbor 172.16.1.1 are prepended three times with AS 65040, the AS number of the sender, thus making that path less preferable for the returning traffic. Keep in mind that if any AS on the path also does AS path prepending, the policy may not work.

6-114

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

MED Attribute The paths with the lowest MED (also called the metric) value are the most desirable. MED is used to advertise an exit path to be used by EBGP neighbors to reach networks owned by this AS. The MED attribute is optional and nontransitive.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—6-14

The MED attribute, also called the metric, is an optional nontransitive attribute. The MED is an indication to EBGP neighbors about the preferred path into an AS. The MED attribute is a dynamic way to influence another AS about which path that it should choose to reach a certain route when multiple entry points into an AS exist. A lower metric is preferred. Unlike local preference, the MED is exchanged between autonomous systems. The MED is sent to EBGP peers. Those routers propagate the MED within their AS, and the routers within the AS use the MED but do not pass it on to the next AS. When the same update is passed on to another AS, the metric is set back to the default of 0. To change this value, use the defaultmetric number command under the BGP process. All routes that are advertised to an EBGP neighbor are set to the value specified using this command. MED influences inbound traffic to an AS, and local preference influences outbound traffic from an AS. By default, a router compares the MED attribute only for paths from neighbors in the same AS. Note

The MED attribute means that BGP is the only protocol that can affect how routes are sent into an AS.

In the figure above, the router R2 MED attribute is set to 150, and the router R3 MED attribute is set to 200. When router R1 receives updates from routers R2 and R3, it picks router R2 as the best next hop because its MED of 150 is less than the router R3 MED of 200. For more details about the default-metric number command, please check the Cisco IOS IP Routing Protocols Command Reference on the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-115

Set MED with Route Map

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—6-15

This figure is used in the following configurations to demonstrate how to manipulate inbound traffic using route maps to change the BGP MED attribute. The intention of these route maps is to designate router R1 as the preferred path to reach networks 192.168.25.0/24 and 192.168.26.0/24 and to designate router R2 as the preferred path to reach network 192.168.24.0/24. The other networks should still be reachable through each router in case of a link or router failure.

6-116

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Route Map for Router R1 Îďý ® ±«¬» ® ľą° ęëđď đ ˛ »·ą¸ ľ±® îň îňîňî ®»ł ±¬»óż ­ ęëđ ďđ ˛ »·ą¸ ľ±® íň íňíňí ®»ł ±¬»óż ­ ęëđ ďđ ˛ »·ą¸ ľ±® îň îňîňî «°Ľ ż¬»ó­ ±«®˝ » ´±± °ľż˝ µđ ˛ »·ą¸ ľ±® íň íňíňí «°Ľ ż¬»ó­ ±«®˝ » ´±± °ľż˝ µđ ˛ »·ą¸ ľ±® ďç îňďęčňîčň ď ®»ł ±¬»ó ż­ ęë đîđ ˛ »·ą¸ ľ±® ďç îňďęčňîčň ď ®±« ¬»ół ż° ł» ĽÁęë đîđ ± «¬ ˙ ż ˝˝»­ ­ó´·­ ¬ ęę ° »®ł· ¬ ďçî ňďęč ňîëň đňđ đň đňđň îëë ż ˝˝»­ ­ó´·­ ¬ ęę ° »®ł· ¬ ďçî ňďęč ňîęň đňđ đň đňđň îëë ˙ ® ±«¬» ółż° ł »ĽÁęëđîđ °»®ł· ¬ ďđ ł ż¬˝¸ · ° żĽ Ľ®»­­ ęę ­ »¬ ł» ¬®·˝ ďđđ ˙ ® ±«¬» ółż° ł »ĽÁęëđîđ °»®ł· ¬ ďđđ ­ »¬ ł» ¬®·˝ îđđ

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—6-16

The MED is set outbound when a router is advertising to an EBGP neighbor. In the configuration example for router R1, a route map named “med_65020” is linked to neighbor 192.168.28.1 as an outbound route map. When router R1 sends an update to neighbor 192.168.28.1 (router R4), it processes the outbound update through route map med_65020 and uses a set statement to change any values that are specified, as long as the preceding match statement is met in that section of the route map. The first line of the route map is a permit statement with a sequence number of 10 for the route map med_65020; this defines the first route-map statement. The match condition for this statement checks all networks that are permitted by access list 66. The first line of access list 66 permits any networks that start with the first three octets of 192.168.25.0, and the second line of access list 66 permits networks that start with the first three octets of 192.168.26.0. All networks that are permitted by either of these lines are set to a MED of 100. All other networks are denied by this access list (there is an implicit “deny all” at the end of all access lists), so those networks are not set to a MED of 100; their MED is not changed. These other networks must proceed to the next route map statement in the med_65020 route map. The second statement of the route map is a permit statement with a sequence number of 100 for the route map med_65020. The route map does not have any match statements, just a set metric 200 command. This is a “permit all” statement for route maps. Because the network administrator does not specify a match condition for this portion of the route map, all networks being processed through this section of the route map (sequence number 100) are permitted, and are set to a MED of 200. If the network administrator did not set the MED to 200, by default it would have been a MED of 0. Because 0 is less than 100, the routes with a MED of 0 would have been the preferred paths to the networks in AS 65010.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-117

Route Map for Router R2 Îîý ® ±«¬» ® ľą° ęëđď đ ˛ »·ą¸ ľ±® ďň ďňďň ď ®»ł ±¬»óż ­ ęëđ ďđ ˛ »·ą¸ ľ±® íň íňíň í ®»ł ±¬»óż ­ ęëđ ďđ ˛ »·ą¸ ľ±® ďň ďňďň ď «°Ľ ż¬»ó­ ±«®˝ » ´±± °ľż˝ µđ ˛ »·ą¸ ľ±® íň íňíň í «°Ľ ż¬»ó­ ±«®˝ » ´±± °ľż˝ µđ ˛ »·ą¸ ľ±® ďé îňîđ ňëđňď ®»ł± ¬»óż ­ ęëđ îđ ˛ »·ą¸ ľ±® ďé îňîđ ňëđňď ®±«¬ »ółż ° ł»Ľ Áęëđî𠱫 ¬ ˙ ż ˝˝»­ ­ó´·­ ¬ ęę ° »®ł· ¬ ďçî ňďęč ňîěň đňđ đň đňđň îëë ˙ ® ±«¬» ółż° ł »ĽÁę ëđîđ °»®ł· ¬ ďđ ł ż¬˝¸ · ° żĽ Ľ®»­ ­ ęę ­ »¬ ł» ¬®·˝ ďđđ ˙ ® ±«¬» ółż° ł »ĽÁę ëđîđ °»®ł· ¬ ďđđ ­ »¬ ł» ¬®·˝ îđđ

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—6-17

Similarly, in the configuration example for router R2, a route map named “med_65020” is linked to neighbor 172.20.50.1 (router R5) as an outbound route map. Before router R2 sends an update to neighbor 172.20.50.1, it will process the outbound update through route map med_65020 and use a set statement to change any values that are specified, as long as the preceding match statement is met in that section of the route map. The first line of the route map is a permit statement with a sequence number of 10 for the route map med_65020, which defines the first route-map statement. The match condition for that line checks all networks that are permitted by access list 66. Access list 66 on router R2 permits any networks that start with the first three octets of 192.168.24.0. Any networks that are permitted by this line are set to a MED of 100. All other networks are denied by this access list, and are not set to a MED of 100. These other networks must proceed to the next route map statement in the med_65020 route map. The second statement of the route map is a permit statement with a sequence number of 100 for the route map med_65020, but it does not have any match statements, just a set metric 200 command. This is a permit all statement for route maps. Because the network administrator does not specify a match condition for this portion of the route map, all networks being processed through this second statement of the route-map are permitted, but are set to a MED of 200. If the network administrator did not set the MED to 200, by default it would have been set to a MED of 0. Because 0 is less than 100, the routes with a MED of 0 would have been the preferred paths to the networks in AS 65010. On router R6, there are multiple paths to reach each network from AS 65010. These paths all have valid next-hop addresses, have synchronization disabled, and are loop-free. All networks have a weight of 0 and a local preference of 100, so Steps 1 and 2 do not determine the best path. 6-118

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

None of the routes were originated by this router or any router in AS 65020; all networks came from AS 65010, so Step 3 does not apply. All networks have an AS path of one AS (65010) and were introduced into BGP with network statements (“i” is the origin code), so Steps 4 and 5 are equal. Step 6 states that BGP chooses the lowest MED if all preceding steps are equal or do not apply. For network 192.168.24.0, the next hop of 172.20.50.2 has a lower MED than the next hop of 192.168.28.2. Therefore, for network 192.168.24.0, the path through 172.20.50.2 is the preferred path. For networks 192.168.25.0 and 192.168.26.0, the next hop of 192.168.28.2 has a lower MED of 100 compared to the MED of 200 through the next hop of 172.20.50.2; therefore, 192.168.28.2 is the preferred path for those networks.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-119

Filtering of BGP Routing Updates BGP is receiving a high number of routing updates. In order to optimize the BGP configuration, route filtering must be applied. This topic describes the steps needed to configure filtering of routing updates.

Steps to Configure BGP Route Filtering Using IP Prefix Lists Define traffic filtering requirements: – Filtering updates – Controlling redistribution Configure matching statements using: – mask filtering, ge, le Apply a prefix list to filter inbound or outbound updates

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—6-18

When planning filter configuration using prefix lists, the following steps are required and an implementation plan must be created for these steps: Define the traffic filtering requirements: —

Filtering updates

—

Controlling redistribution

Configure the matching statements: —

Use mask filtering, ge, le

Apply a prefix list to filter inbound or outbound updates

6-120

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Configuring Filtering of BGP Routing Updates Îîř˝±˛ş·ą÷ý ·° °®»ş·¨ó´·­¬ ßŇÇó謱îěóŇŰĚ °»®ł·¬ đňđňđňđńđ ą» č ´» îě

Configure a matching statement to match all networks with the mask from /8 to /24. Îîř˝±˛ş·ąó®±«¬»®÷ý ˛»·ą¸ľ±® ďéîňďęňďňî °®»ş·¨ó´·­¬ ßŇÇó謱îěóŇŰĚ ·˛

Applies an inbound prefix list filter to prevent distribution of subnets /8 to /24. The prefix list is applied to incoming advertisements from the 172.16.1.2 neighbor.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—6-19

Prefix-list entries where the ge and le option are specified match any prefix within the address range that are specified using the ge and le parameters. In the example above, the prefix list named “ANY-8to25-NET” is configured to match routes from any network that has a mask length from 8 to 24 bits. The 0.0.0.0/0 network/length combination does not match a specific network, but is used to define any network. The combination of ge 8 le 24 parameters specifies that any network with a mask length between 8 and 24 is a match. A prefix list must be applied to inbound or outbound updates. In the figure above, the prefix list ANY-8to25-NET is applied to the inbound traffic to prevent distribution of BGP neighbor information. The prefix list is applied to incoming advertisements from the BGP neighbor 172.16.1.2, which prevents distribution of routes from any network that has a mask length from 8 to 24 bits. For more details about the neighbor prefix-list command, please check the Cisco IOS IP Routing Protocols Command Reference on the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-121

Verify Filtering of BGP Routing Updates Îîý­¸±© ·° °®»ş·¨ó´·­¬ Ľ»¬ż·´ ßŇÇó謱îěóŇŰĚ ·° °®»ş·¨ó´·­¬ ßŇÇó謱îěóŇŰĚć Ü»­˝®·°¬·±˛ć ¬»­¬ó´·­¬ ˝±«˛¬ć ďô ®ż˛ą» »˛¬®·»­ć ďô ­»Ż«»˛˝»­ć ďđ ó ďđô ®»ş˝±«˛¬ć í ­»Ż ďđ °»®ł·¬ đňđňđňđńđ ą» č ´» îě ř¸·¬ ˝±«˛¬ć đô ®»ş˝±«˛¬ć ď÷

Configure a matching statement to match all networks with the mask from /8 to /24.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—6-20

To display information about a prefix list or prefix list entries, use the show ip prefix-list command. The show ip prefix-list command output shows the count of packets being matched. The clear ip prefix-list command is used to clear the prefix list hit counters. The hit count is a value indicating the number of matches to a specific prefix list entry. For more details about the show ip prefix-list and clear ip prefix-list commands, please check the Cisco IOS IP Routing Protocols Command Reference on the following link: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html

6-122

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Steps to Configure Route Filtering with a Route Map Define the route map – Define match statements – Define set statements Define route filtering using a route map

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—6-21

When planning filter configuration using route maps, the following steps are required and an implementation plan must be created for these steps: Define the route map —

Define the match statements

—

Define the set statements

Define the route filtering using route-maps

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-123

Using Route Maps for Filtering Routing Updates Îďř˝±˛ş·ąó®±«¬»®÷ý

˛»·ą¸ľ±® ďéîňďęňďňî ®±«¬»ółż° ᫬»Ú·´¬»® ·˛ Applies a route map RouteFilter to incoming BGP updates from neighbor 172.16.1.2 Filtering can be applied to outgoing updates. Prefixes that are not permitted by the route map are discarded. Route maps can also change the BGP attributes of incoming or outgoing updates.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—6-22

To apply a route map to filter incoming or outgoing BGP routes, use the neighbor route-map command in router configuration mode. The routes that are permitted can have their attributes set or changed by the set clauses in the route-map command. Setting attributes on routes is useful when attempting to influence route selection. Route map permit statements can be written to change the attributes of the permitted routes or to leave the attributes unchanged. When BGP performs route selection, the attribute values indicate that one route is preferred more than the other. Similar route filtering could be performed for the OSPF or EIGRP routing process. In this case, the distribute-list in or distribute-list out commands are used together with the route-map command, which defines which updates are dropped and which updates are accepted.

6-124

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Using Route Maps as BGP Filters Requirement: The customer will accept only a default route and use the primary link for outbound traffic.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—6-23

In this example, the customer will accept only a default route from the ISPs, and will use the link to AS 387 as the primary link for outbound traffic. The customer router in AS 213 is configured for BGP with two neighbors using the neighbors remote-as command. Both neighbors are configured with the neighbor route-map command to filter the incoming routing update traffic according to the route map named “filter.” Routemap filter allows a default route into the customer network, and with careful setting of the BGP weight attribute, the primary link becomes preferred. A higher value for weight is preferred and the default route coming from the ISP in AS 387 gets a weight value of 150 and the secondary default route gets a weight value of 100.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-125

Filtering Routing Updates

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—6-24

As an option, filter lists, prefix lists, and route maps can be applied on either incoming or outgoing information, or in any combination in BGP. The incoming prefix list, the incoming filter list, and the incoming route map must all permit the routes that are received from a neighbor before they will be accepted into the BGP table. Outgoing routes must pass the outgoing filter list, the outgoing prefix list, and the outgoing route map before they will be transmitted to the neighbor. When a router is configured to redistribute routing information from IGP into BGP, the routes must successfully pass any prefix list or route map applied to the redistribution process before the route is injected into the BGP table.

6-126

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary After BGP receives updates about multiple destinations from different autonomous systems, it follows a multiple-step process for selecting the best route to reach a destination; the best route is a candidate for the routing table. BGP metrics are called path attributes and describe the paths to reach each network. BGP is receiving a high number of routing updates. In order to optimize the BGP configuration, route filtering with prefix-lists must be applied Route maps are used to set selected attributes for selected routes to control the outbound EBGP path selection.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

RO UTE v 1.0—6-25

Summary (cont.) The local preference attribute is a well-known discretionary attribute that provides an indication to routers in the AS about which path is preferred to exit the AS. The weight attribute is an attribute that Cisco defines for the path selection process; routes with a higher weight are preferred when multiple routes exist to the same destination.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

RO UTE v 1.0—6-26

Connecting an Enterprise Network to an ISP Network

6-127

6-128

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 7

Lab 6-2 Debrief Overview In Lab 6-2, students manipulate the BGP path selection with route maps using local preference and MED. Students use different BGP path selection methods and compare these methods in a routed network. After completing the lab, the instructor will lead a discussion about the lab topology, tasks, verification, and checkpoints and discuss a sample solution and different alternatives. Students will present their implementation plans and solutions.

Objectives Upon completing this lesson, you will be able to explain the lab topology, configure the BGP path manipulation using a local preference and the MED BGP attributes, create check points for configuration, verification, and find alternative solutions. This ability includes being able to meet these objectives: Identify the implementation and verification tasks to establish BGP adjacency in the network and manipulate the BGP path using local preference and MED BGP attributes. Present the sample solution and identify possible alternative solutions .

Lab Overview and Verification This topic describes the lab topology and key checkpoints used to create a solution and to start the verification.

Lab Topology

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-2

This figure presents the lab topology used for the configuration of BGP path manipulation lab. The topology uses four pod routers, which are members of a full Internal BGP (IBGP) relationship and two backbone routers, which are members of an External BGP (EBGP) relationship. The lab is preconfigured with addressing including loopbacks and an IGP routing protocol. Based on the topology, students can create a BGP path manipulation configuration including a full IBGP process, advertising next hop, synchronization, and path manipulation configuration.

6-130

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab Review: What did you accomplish? Task 1: Configure fully meshed IBGP – What steps did you take to configure fully meshed IBGP? – How did you deal with loopback interfaces? Task 2: Use the MED and local preference (LP) with route maps for BGP path manipulation – What is the difference between a MED and an LP implementation? – In what order did you execute your plan and why? – How did you apply a new policy to the BGP neighbor?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-3

In the first task, students are asked to clean up previous router configurations and establish a full-mesh IBGP. When configuring the full-mesh IBGP, next hop and loopback reachability must be achieved. Because of the full-mesh IBGP, there is no need for synchronization. In the second task, MED and local preference are used to manipulate the path. Each time the policy is changed there is a need to perform a soft reconfiguration to see the results of the new configuration.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-131

Verification Is your solution working? What method did you follow to verify that BGP path manipulation is working correctly? Which commands did you use to verify the proper operation of different BGP policies?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-4

A common approach to verify the proper BGP path manipulation would be to take the following steps: Verify that all IBGP peering sessions are operational. The following commands can be used for this verification: —

show ip bgp summary: Displays the status of all BGP connections

—

show ip bgp neighbors: Displays information about the BGP and TCP connections to neighbors

Verify what the MED and local preference values are and which routes are inside the BGP table. The following command can be used for this verification: —

show ip bgp: Displays entries in the BGP routing table

Verify which BGP routes were entered in the routing table. The following command can be used for this verification: —

6-132

show ip route: Displays entries in the IP routing table

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Check Points Full-mesh BGP Check IP routing table Loopbacks and next hop Path used to reach the remote networks Why a different path is used Soft reconfiguration

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-5

During the configuration and verification phase, the network operator uses several checkpoints. After completing all of the configuration tasks, the BGP configuration can be successfully completed or additional verification and troubleshooting will be needed. Optionally, the network operator can check the BGP configuration in different stages of the implementation using checkpoints to verify each stage. With different checkpoints, the network operator can check for proper configuration using the following steps: Step 1

Check the full-mesh BGP.

Step 2

Check the IP routing table.

Step 3

Check the loopbacks and next hop.

Step 4

Check the path used to reach the remote networks.

Step 5

Check why a different path is used.

Step 6

Check the soft reconfiguration.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-133

Sample Solutions and Alternatives This topic describes sample solution and other alternatives.

Sample Solution Configure full-mesh IBGP. Use loopbacks for BGP sessions. Advertise loopbacks and next hop. Disable synchronization. Manipulate the path using MED and LP. Perform a soft reconfiguration.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-6

This sample solution includes the configuration steps necessary for each of the tasks. Different solutions are possible. However, this figure points out the important tasks required for successful configuration. To be able to complete the lab configuration successfully, complete the following steps:

6-134

Step 1

Configure a full-mesh IBGP.

Step 2

Use loopbacks for the BGP sessions.

Step 3

Advertise the loopbacks and next hop.

Step 4

Disable synchronization.

Step 5

Manipulate the path using MED and local preference.

Step 6

Perform a soft reconfiguration.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternative Solutions IBGP process—full mesh or partial mesh Use loopbacks or other interfaces for BGP session Install routes into the IP routing table or advertise next hop BGP synchronization ON or OFF Using other BGP attributes (beside MED or LP) for path manipulation How to trigger an update of BGP table after policy change © 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-7

The same or similar results can be achieved by using different configuration steps. When configuring an IBGP neighbor relationship, it can be either a full-mesh IBGP or partial mesh. There is no mechanism in IBGP to detect whether there is an update loop. For that reason, the IBGP neighbor never sends updates to another IBGP neighbor. If there is a need for all of the IBGP neighbors to be aware of all the BGP updates, then there is a need for a fullmesh IBGP. The IBGP next-hop address is reachable by running an IGP routing protocol inside an autonomous system (AS). Loopbacks are always on if the router is operational, and it is very convenient to establish IBGP sessions between the loopback interfaces. Loopbacks must be advertised inside an IP routing table as well as other next-hop IP addresses. When a BGP is advertising networks to other peers, the route must be present in the IP routing table or synchronization must be turned off. If running a full-mesh IBGP, there is no need for synchronization to be turned on. MED and local preferences can be used to manipulate the path selection. MED is used to influence the inbound EBGP path selection. Local preference can be used to influence the outbound EBGP path selection. There are other BGP attributes that can be used to influence the path selection: AS Path, weight, and others. When the BGP policy changes, there is a need to refresh the BGP and IP routing table. Resetting the BGP session is not an elegant solution. A soft reset is available to trigger an update of the BGP table.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-135

Q and A What is the advantage of full-mesh IBGP? Why is the next hop IP address important? When is synchronization needed? What are different reconfiguration options? What is the difference between MED and LP?

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-8

Because IBGP peers are not sending BGP updates to other IBGP neighbors, within an AS there is a need to run a full-mesh IBGP in order to have a complete BGP table. Next hop is used when forwarding the packets toward their destination. Every BGP update has information about the remote networks together with the next-hop address used for forwarding the packets. The next-hop address must be reachable in order to forward the packets. The synchronization rule says that a router will not advertise routes in BGP until it learns them from an IGP. It is safe to have it off only if all routers in the transit path within the AS are running a full-mesh IBGP. To update the BGP table, the operator can clear the BGP session or trigger the neighbor to resend the complete BGP table again. This last option is called a soft reconfiguration and requires more resources. At the same time, it is not as aggressive as a BGP session staying up all of the time. MED is used to manipulate the inbound path to the AS and local preference is used to manipulate the outbound path from the AS.

6-136

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Summary This topic summarizes the key points that were discussed in this lesson.

Summary Create a good implementation plan and define the BGP requirements before configuring a BGP path manipulation. Several solutions exist and alternative solutions give similar or very different results.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1. 0—6-9

Connecting an Enterprise Network to an ISP Network

6-137

6-138

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lesson 8

E-Learning Training on IPv6 and Routing for Branch Offices and Remote Workers Overview The Implementing Cisco IP Routing (ROUTE) v1.0 instructor-led training (ILT) course is a comprehensive learning experience. Among the learning tools available are e-learning modules that complement the classroom instructor-led content and help complete your experience with self-paced materials and demonstrations. Upon accessing the e-learning content, you will be able to reinforce the knowledge acquired in class, and witness real-life scenarios demonstrated in real routers and switches. The content structure is flexible, and you can navigate it at your own pace, at the time of your choosing, and at the depth you desire according to your level of experience. This lesson presents the topics of IPv6 and remote access connectivity. A total of two elearning modules are reviewed: “Implementing IPv6” and “Implementing Routing Facilities for Branch Offices and Mobile Workers.” The content includes demonstrations that cover critical topics in both areas.

Objectives Upon completing this lesson, you will be able to discuss the e-learning modules that pertain to additional topics in IPv6 and remote access connectivity. This ability includes being able to meet these objectives: Describe the content of the “Implementing IPv6” e-learning module. Describe the content of the “Implementing Routing Facilities for Branch Offices and Mobile Workers” e-learning module. Understand the structure and the process of accessing and using e-learning content.

Preview of E-Learning Modules “Implementing IPv6” and “Routing Facilities for Branch Offices and Mobile Workers” This topic describes two e-learning products that pertain to additional topics in IPv6 and remote access connectivity.

CCNP E-Learning Complement and enhance your classroom experience. Reinforce concepts and their application. Learn at your own pace. Review advanced topics. Experience real-life scenarios through directed demonstrations.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-2

One of the key ideas behind the design of the Cisco CCNP® curriculum is the understanding that there is no one "best" method of learning for every student. Some students prefer individual labs, while others prefer one-on-one tutoring, hands-on sessions, self-paced computer-assisted instruction, direct discovery learning or cooperative learning, and other methods. E-learning solutions offer new approaches that complement and enhance classroom-based learning. Designed with flexibility and learning effectiveness in mind, the “Implementing IPv6” and “Implementing Routing Facilities for Branch Offices and Mobile Workers” e-learning modules are based on knowledge you acquired during your Implementing Cisco IP Routing (ROUTE) v1.0 instructor-led training course. Both modules include new concepts and describe these concepts starting with the fundamentals and going into more depth through directed demonstrations.

6-140

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Implementing IPv6 Lesson

Description

IPv6 Addressing and Unicast

Learn the fundamentals of IPv6 technologies, focusing on static and stateless address planning and configuration, and unicast connectivity in pointto-point and multipoint links.

IPv6 with RIPng, OSPFv3, EIGRP and Redistribution

Demonstrate router configuration in scenarios of IPv6 routing, including the integration and redistribution of multiple routing protocols such as RIPng, OSPFv3, EIGRP, and BGP.

IPv6 Transition Techniques

Understand the transition path to IPv6, using techniques such as manual IPv6 tunnels, 6to4 tunnels, and ISATAP tunnels.

NAT and PAT with IPv6

Implement static and dynamic NAT-PT.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-3

The “Implementing IPv6” e-learning module covers topics that enhance Module 6, Connection of an Enterprise Network to an ISP Network, of the Implementing Cisco IP Routing (ROUTE) v1.0 course. It starts with an introductory lesson that discusses the benefits of the protocol and structural and operational fundamentals, such as addressing. Directed demonstrations will guide subsequent lessons on IPv6 routing and routing protocols, IPv4-to-IPv6 transition techniques including IPv6, 6to4 and Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) tunnels and Network Address Translation (NAT) as well as Port Address Translation (PAT) in IPv6 scenarios. IPv6 is supported by RIP named RIP next generation (RIPng), OSPF version3 (OSPFv3) and EIGRP routing protocols.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-141

Implementing Routing Facilities for Branch Offices and Mobile Workers Lesson Analyzing Branch Office Designs and Planning for Branch Office Installations Directed Demo on How to Implement Special Facilities for Branch Offices Lab Debrief

Description Watch a discussion on design fundamentals and trends for the branch office. Overview the design scenarios that will be demonstrated in the next lesson. Demonstrate router configurations in scenarios of branch office connectivity, including verification of existing services, routing around IPSec tunnels using GRE, and other routing facilities. Gather conclusions, sample configurations, and alternative methods related to the demonstrations in the previous lesson.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-4

The “Implementing Routing Facilities for Branch Offices and Mobile Workers” e-learning module also covers topics that enhance Module 6, Connection of an Enterprise Network to an ISP Network, of the Implementing Cisco IP Routing (ROUTE) v1.0 course. It is structured in two major topics: branch office scenarios and mobile worker scenarios. Branch office designs are analyzed through an introductory lesson that discusses trends and factors to consider in the implementation plan of new installations and upgrades. The directed demonstrations focus on scenarios involving backup connectivity, alternative routing across IPv6 tunnels using Generic Routing Encapsulation (GRE), load sharing, and other situation.

6-142

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Implementing Routing Facilities for Branch Offices and Mobile Workers (cont.) Lesson Analyzing Mobile Workers Designs and Planning for Mobile Workers Installations Directed Demo: Implement Special Facilities for Mobile Workers. Lab Debrief

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

Description Review design fundamentals and trends for the mobile worker. Overview the design scenarios that will be demonstrated in the next lesson.

Demonstrate router configurations in scenarios of mobile worker connectivity, including verification of existing services, IP address, and routing facilities provision for mobile workers. Gather conclusions, sample configurations, and alternative methods related to the demonstrations in the previous lesson.

ROUTE v1. 0—6-5

The mobile worker topic is approached in a similar way. An introductory lesson will describe trends and design considerations. This lesson is followed by a directed demonstration of remote access connectivity for mobile users, including addressing and routing considerations around the use of IP Security (IPsec) tunnels as a connectivity option.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-143

Where to find E-Learning Modules Cisco Certifications

www.cisco.com/go/certifications © 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-6

The “E-Learning Training on IPv6 and Routing for Branch Offices and Remote Workers” elearning modules are available on a CD as part of your classroom materials. Please contact your instructor with questions about finding and accessing the CD. The objectives of the “E-Learning Training on IPv6 and Routing for Branch Offices and Remote Workers” e-learning modules are part of your CCNP certification exam, and as such, candidates for the CCNP certification should review these objectives.

6-144

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

E-Learning Module Structure

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-7

Utilizing a combination of lecture sessions, animated content, lab demonstrations, and assessments, each e-learning module presents a hierarchical structure of lessons and topics. You can navigate through that structure by using an intuitive GUI that includes playback controls, slide selection, and lesson and topic selection. Using these tools, you will be able to navigate the content at your own pace. The three-panel screen presented in the directed demonstrations allows you to focus on the device console demonstrations, while having the command syntax and the topology diagram available for verification and additional information.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-145

Summary This topic summarizes the key points that were discussed in this lesson.

Summary The content of the “Implementing IPv6” e-learning module was described. The content of the “Implementing Routing Facilities for Branch Offices and Mobile Workers” e-learning module was described. The structure and process of accessing and using e-Learning content was reviewed.

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

6-146

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v1. 0—6-8

© 2009 Cisco Systems, Inc.

Module Summary This topic summarizes the key points that were discussed in this module.

Module Summary BGP is a path-vector routing protocol that allows routing policy decisions at the AS level to be enforced. BGP is a policy-based routing protocol and controls traffic flow using multiple BGP path attributes. BGP forms EBGP relationships with external neighbors and IBGP with internal neighbors. All routers in the transit path within an AS must run fully meshed IBGP. When BGP is properly configured, it will establish a neighbor relationship and announce the networks with a next-hop and source IP address to other BGP routers. BGP performs a multistep process when selecting the best path to reach a destination. BGP can manipulate path selection to affect the inbound and outbound traffic policies of an AS using route maps and BGP attributes. © 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1. 0—6-1

The Internet has proven to be a valuable tool to many companies, resulting in multiple redundant connections to many different Internet service providers (ISPs). The function of Border Gateway Protocol (BGP) is to provide alternatives to using default routes to control path selections.

References For additional information, refer to these resources: RFCs 1772, 1773, 1774, 1930, 1966, 1997, 1998, 2042, 2385, 2439, 2545, 2547, 2796, 2858, 2918, 3065, 3107, 3392, 4223, and 4271. RFC 1518, An Architecture for IP Address Allocation with CIDR. RFC 1519, Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy. RFC 2050, Internet Registry IP Allocation Guidelines.

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-147

6-148

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Module Self-Check Use the questions here to review what you learned in this module. The correct answers and solutions are found in the Module Self-Check Answer Key. Q1)

Which type of connectivity is typically expected to and from an enterprise network? (Source: Planning the Enterprise-to-ISP Connection) A) B) C) D)

Q2)

What is not a requirement of enterprise network-to-ISP connectivity? (Source: Planning the Enterprise-to-ISP Connection) A) B) C) D)

Q3)

one-way two-way unidirectional connectivity from the clients to the Internet

public IP address space link type and bandwidth availability AS routing policy connection redundancy

List five routing update exchange options for enterprise network-to-ISP connectivity. (Source: Planning the Enterprise-to-ISP Connection) ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________

Q4)

Which one of these statements is not the reason for using BGP as a routing update exchange mechanism? (Source: Planning the Enterprise-to-ISP Connection) A) B) C) D)

Q5)

A customer deploys BGP to announce its public networks. A BGP is typically used for inter-AS routing. Customer routers are connected to SPs PE routers. Customer network implementation requires a complete Internet routing table.

What are four enterprise network-to-ISP connection options? (Source: Planning the Enterprise-to-ISP Connection) ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________

Q6)

Which is a characteristic of dual-multihomed ISP connectivity? (Source: Planning the Enterprise-to-ISP Connection) A) B) C) D)

© 2009 Cisco Systems, Inc.

a connection to two or more different ISPs with two links per ISP a connection to multiple ISPs with one link per ISP the default route points to each ISP from an enterprise network each ISP announces a default route with a different metric to the enterprise network

Connecting an Enterprise Network to an ISP Network

6-149

Q7)

What are three common ways to perform multihoming? (Choose three.) (Source: Planning the Enterprise-to-ISP Connection) A) B) C) D)

Q8)

Which statement is true about the autonomous system (AS)? (Source: Considering the Advantages of Using BGP) A) B) C) D)

Q9)

C) D)

The AS has only a single connection to another AS. Path and packet flow manipulation is required in this AS. You have a limited understanding of BGP routing and route filtering. The AS is an ISP.

Which routing method best describes BGP? (Source: Considering the Advantages of Using BGP) A) B) C) D)

6-150

true false

Which two conditions are valid reasons to run BGP in an AS? (Choose two.) (Source: Considering the Advantages of Using BGP) A) B) C) D)

Q13)

It has redundancy with the multiple connections. Connectivity issues in that single ISP can cause your autonomous system to lose connectivity to the Internet. It is not tied into the routing policy of a single connection. It has more paths to the same networks for better policy manipulation.

An enterprise network is configured as a multihoming network and only receives a default route from each ISP. (Source: Considering the Advantages of Using BGP) A) B)

Q12)

To increase the reliability of the connection to the Internet. To increase the performance of the connection. To increase the bandwidth of the connection. To simplify the IGP protocol configuration.

What is a drawback of having all of your connections to a single ISP? (Source: Considering the Advantages of Using BGP) A) B)

Q11)

The AS is a collection of networks under single administrative domain. The AS is a collection of networks that belong to one enterprise network. The AS requires IGP protocol to exchange routing information between autonomous systems. EBGP neighbors must be configured within the same AS.

What are the two typical reasons for multihoming? (Choose two.) (Source: Considering the Advantages of Using BGP) A) B) C) D)

Q10)

Each ISP passes only a default route to the AS. Each ISP passes a default route and provider-owned specific routes to the AS. Each ISP passes selected provider-owned routes but no default routes to the AS. Each ISP passes all routes to the AS.

distance vector link-state path-vector hybrid of link-state and distance vector

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q14)

Which protocol does BGP use? (Source: Considering the Advantages of Using BGP) A) B) C) D)

Q15)

IP protocol number 88 IP protocol number 89 UDP port 520 TCP port 179

Which four message types are defined by BGP? (Source: Considering the Advantages of Using BGP) ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________

Q16)

Which two terms refer to routers that are configured to exchange BGP information with one another? (Choose two.) (Source: Comparing the Functions and Uses of EBGP and IBGP) A) B) C) D)

Q17)

By default, what are two conditions for routers to be EBGP neighbors? (Choose two.) (Source: Comparing the Functions and Uses of EBGP and IBGP) A) B) C) D)

Q18)

routers must be in the same AS routers must be in different autonomous systems routers are running an IGP between them to establish an adjacency routers are directly connected

What are three ways to form an adjacency between IBGP neighbors by default? (Choose three.) (Source: Comparing the Functions and Uses of EBGP and IBGP) A) B) C) D)

Q19)

BGP peer BGP speaker BGP router BGP neighbor

The neighbors can be directly connected. The neighbors can be reachable from one another by static routes. The neighbors can be reachable from one another by a dynamic internal routing protocol. The neighbors can be in different autonomous systems.

Which statement about IBGP is true? (Source: Comparing the Functions and Uses of EBGP and IBGP) A) B) C) D)

© 2009 Cisco Systems, Inc.

Routes learned via IBGP are never sent to EBGP peers. All the routers between IBGP neighbors must not be running IGP instead of BGP. Routes learned via IBGP are never propagated to other IBGP peers. Routes are never learned via IBGP.

Connecting an Enterprise Network to an ISP Network

6-151

Q20)

Test your understanding of BGP terminology by matching statements with terms. Write the letter of the statement in front of the term that the statement describes. A statement can describe more than one term. Each term can match multiple statements, but choose only the statement that best describes the term. (Source: Explaining EBGP and IBGP) Statement: A) B) C) D)

These routers never advertise BGP routing information to IBGP neighbors. This is a set of BGP routers that are explicitly configured to exchange BGP information. This is a set of BGP routers that have a neighbor relationship with BGP routers in the same and different autonomous systems. This is a set of BGP routers that, by default, must be directly connected and must be in different autonomous systems.

Term:

Q21)

_____ 1.

IBGP neighbors

_____ 2.

BGP neighbors

_____ 3.

EBGP neighbors

_____ 4.

BGP routers

What does BGP use during the best path selection process? (Source: Explaining EBGP and IBGP) A) B) C) D)

Q22)

speed AS routing policy bandwidth plus delay number of routers to reach a destination network

Which parameters are required for a basic BGP configuration? (Source: Configuring and Verifying Basic BGP Operations) ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________

Q23)

Which command indicates to a BGP router whether an IP address belongs to an IBGP or an EBGP neighbor? (Source: Configuring and Verifying Basic BGP Operations) A) B) C) D)

Q24)

Which command sets the source IP address of a BGP update to be the IP address of a specific interface? (Source: Configuring and Verifying Basic BGP Operations) A) B) C) D)

6-152

neighbor 10.1.1.1 shutdown neighbor 10.1.1.1 update-source Loopback0 neighbor 10.1.1.1 remote-as 65010 neighbor 10.1.1.1 next-hop-self

neighbor 10.2.2.2 shutdown neighbor 10.2.2.2 update-source Loopback0 neighbor 10.2.2.2 remote-as 65020 neighbor 10.2.2.2 next-hop-self

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q25)

What is the result of using this command: router bgp 65010? (Source: Configuring and Verifying Basic BGP Operations) A) B) C) D)

Q26)

The network command that is used in the router BGP process identifies the interfaces from which to advertise BGP updates. (Source: Configuring and Verifying Basic BGP Operations) A) B)

Q27)

neighbor 10.4.4.4 ebgp-multihop neighbor 10.4.4.4 update-source Loopback0 neighbor 10.4.4.4 remote-as 65020 neighbor 10.4.4.4 next-hop-self

What are two benefits of using BGP peer groups? (Choose two.) (Source: Configuring and Verifying Basic BGP Operations) A) B) C) D)

Q30)

BGP neighbor 10.3.3.3 is administratively disabled. It prevents BGP neighbor 10.3.3.3 from receiving BGP updates. The BGP process on the neighbor 10.3.3.3 is disabled. The command also requires the AS number in order to shut down the neighbor.

Which command must be used if an EBGP neighbor is not directly connected? (Source: Configuring and Verifying Basic BGP Operations) A) B) C) D)

Q29)

true false

What is the result of using this command: neighbor 10.3.3.3 shutdown? (Source: Configuring and Verifying Basic BGP Operations) A) B) C) D)

Q28)

The BGP process starts in the router. The BGP process starts on the interface. The neighboring router AS is defined. The router enters into BGP configuration mode with AS number 65010 used locally.

Peer groups simplify the BGP configuration. Peer groups make BGP updates more efficient. Peer groups are able to find a more optimal way out of the AS. Peer groups change BGP attributes for more BGP neighbors at a time.

What states does BGP go through during the establishment of a BGP session? (Source: Configuring and Verifying Basic BGP Operations) ________________________________________________________________ ________________________________________________________________ ________________________________________________________________

Q31)

Which state indicates that the router does not have a path to the neighbor IP address? (Source: Configuring and Verifying Basic BGP Operations) A) B) C) D)

© 2009 Cisco Systems, Inc.

active idle established open confirm

Connecting an Enterprise Network to an ISP Network

6-153

Q32)

If you configure or change the password or key used for MD5 authentication between two BGP peers, the local router will not tear down the existing session after you configure the password. (Source: Configuring and Verifying Basic BGP Operations) A) B)

Q33)

Which clear ip bgp command is the least intrusive for resetting a BGP session after changing outbound policy for neighbor 10.5.5.5? (Source: Configuring and Verifying Basic BGP Operations) A) B) C) D)

Q34)

well-known mandatory well-known discretionary optional transitive optional nontransitive

Which description applies to the origin attribute? (Source: Selecting an Outbound EBGP Path) A) B) C) D)

6-154

well-known mandatory well-known discretionary optional transitive optional nontransitive

Which description applies to the next-hop attribute? (Source: Selecting an Outbound EBGP Path) A) B) C) D)

Q37)

_____ prefer the path with the lowest neighbor BGP router ID _____ prefer the lowest MED _____ prefer the shortest AS path _____ prefer the oldest route for EBGP paths _____ prefer the lowest origin code (IGP < EGP < incomplete) _____ prefer the highest weight _____ prefer the path through the closest IGP neighbor _____ prefer the highest local preference _____ prefer the route that was originated by the local router _____ prefer an EBGP path over IBGP path _____ prefer the lowest neighbor IP address

Which description applies to the AS path attribute? (Source: Selecting an Outbound EBGP Path) A) B) C) D)

Q36)

clear ip bgp * clear ip bgp 10.5.5.5 soft out clear ip bgp 10.5.5.5 clear ip bgp 10.5.5.5 soft in

Place the BGP selection criteria in order from the first step to the last step evaluated to select the BGP path that is submitted to the IP routing table. (Source: Selecting an Outbound EBGP Path) A) B) C) D) E) F) G) H) I) J) K)

Q35)

true false

well-known mandatory well-known discretionary optional transitive optional nontransitive

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Q38)

Which description applies to the local preference attribute? (Source: Selecting an Outbound EBGP Path) A) B) C) D)

Q39)

Which description applies to the MED attribute? (Source: Selecting an Outbound EBGP Path) A) B) C) D)

Q40)

The lower value for weight is preferred. The higher value for weight is preferred. Weight is used only between IBGP neighbors. Weight is used only locally inside the router.

Which two statements are true regarding the MED? (Choose two.) (Source: Manipulating Inbound EBGP Paths Selection) A) B) C) D)

Q44)

The higher value for local preference is preferred. Local preference is used only between EBGP neighbors. The lower value for local preference is preferred. Local preference is used only between IBGP neighbors.

Which two statements are true regarding weight? (Choose two.) (Source: Selecting an Outbound EBGP Path) A) B) C) D)

Q43)

well-known mandatory well-known discretionary optional transitive proprietary to Cisco and not advertised to other BGP routers

Which two statements are true regarding local preference? (Choose two.) (Source: Selecting an Outbound EBGP Path) A) B) C) D)

Q42)

well-known mandatory well-known discretionary optional transitive optional nontransitive

Which description applies to the weight attribute? (Source: Selecting an Outbound EBGP Path) A) B) C) D)

Q41)

well-known mandatory well-known discretionary optional transitive optional nontransitive

The higher value for the MED is preferred. The lower value for the MED is preferred. The MED is exchanged between autonomous systems. The MED is local to an AS.

Which two statements are true regarding the AS Path? (Choose two.) (Manipulating Inbound EBGP Paths Selection) A) B) C) D)

© 2009 Cisco Systems, Inc.

The shorter AS path is preferred. The longer AS path is preferred. The AS path is prepended and exchanged between autonomous systems. The AS path is local to an AS.

Connecting an Enterprise Network to an ISP Network

6-155

Q45)

Which command changes the MED for all routes? (Source: Manipulating Inbound EBGP Paths Selection) A) B) C) D)

Q46)

The MED is used to decide how to enter an AS from neighboring autonomous systems, when multiple paths exist between two autonomous systems. (Source: Manipulating Inbound EBGP Paths Selection) A) B)

Q47)

true false

The length of the AS path is extended because additional copies of the AS number of the sender are prepended to the original AS path attribute. To avoid clashes with BGP loop prevention mechanisms, no other AS number, except that of the neighboring AS, should be prepended to the AS path attribute. (Source: Manipulating Inbound EBGP Paths selection) A) B)

6-156

true false

The MED is set inbound when a router is receiving router updates from an EBGP neighbor. (Source: Manipulating Inbound EBGP Paths Selection) A) B)

Q48)

bgp med number default-metric number bgp default-metric number set med number

true false

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Module Self-Check Answer Key Q1)

B

Q2)

C

Q3)

Static routes, Common IGP, MPLS VPNs, Circuit Emulation, BGP

Q4)

C

Q5)

Single-homed, Dual-homed, Multihomed, Dual-multihomed

Q6)

A

Q7)

A, B, D

Q8)

A

Q9)

A, B

Q10)

B

Q11)

A

Q12)

B, D

Q13)

C

Q14)

D

Q15)

Open, Keepalive, Update, Notification

Q16)

A, D

Q17)

B, D

Q18)

A, B, C

Q19)

C

Q20)

1-A 2-C 3-D 4-B

Q21)

B

Q22)

neighbors (peers) involved, AS numbers used, IP Addresses used and Networks, which need to be advertised

Q23)

C

Q24)

B

Q25)

D

Q26)

B

Q27)

A

Q28)

A

Q29)

A, B

Q30)

Idle, Connect, Open sent, Open confirm, Established

Q31)

B

Q32)

A

© 2009 Cisco Systems, Inc.

Connecting an Enterprise Network to an ISP Network

6-157

6-158

Q33)

B

Q34)

1-F 2-H 3-I 4-C 5-E 6-B 7-J 8-G 9-D 10-A 11-K

Q35)

A

Q36)

A

Q37)

A

Q38)

B

Q39)

D

Q40)

D

Q41)

A, D

Q42)

B, D

Q43)

B, C

Q44)

A, C

Q45)

B

Q46)

A

Q47)

B

Q48)

B

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

ROUTE

Implementing Cisco IP Routing Version 1.0

Lab Guide Text Part Number: 97-2817-01

DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED “AS IS.” CISCO MAKES AND YOU RECEIVE NO WARRANTIES IN CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY OR IN ANY OTHER PROVISION OF THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO SPECIFICALLY DISCLAIMS ALL IMPLIED WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. This learning product may contain early release content, and while Cisco believes it to be accurate, it falls subject to the disclaimer above.

Lab Guide

© 2009 Cisco Systems, Inc. All Rights Reserved.

Table of Contents Lab Guide

1

Overview 1 Outline 1 Lab 1-1: Assess Skills for Implementing Complex Networks 3 Activity Objective 3 Information Packet 3 Implementation Policy 4 Device Information 5 Required Resources 5 Job Aids 6 Task 1: Identify the Network Requirements 7 Task 2: Identify and Gather the Required Information 8 Task 3: Create an Implementation and Verification Plan 10 Alternate Resources and Solutions 12 Hints 13 Lab 1-1 Hint Sheet: Assess Skills for Implementing Complex Networks 13 Lab 2-1: Configure and Verify EIGRP Operations 19 Activity Objective 19 Information Packet 19 Implementation Policy 20 Device Information 21 Command List 22 Required Resources 22 Job Aids 23 Task 1: Establish an Implementation Requirements List 25 Task 2: Create an Implementation and Verification Plan 26 Task 3: Implement and Verify 28 Alternate Resources and Solutions 30 Hints 33 Lab 2-1 Hint Sheet: Configure and Verify EIGRP Operations 33 Lab 2-2: Configure and Verify EIGRP Circuit Emulation and Frame Relay Operations 47 Activity Objective 47 Information Packet 47 Implementation Policy 48 Device Information 49 Command List 50 Required Resources 50 Job Aids 51 Task 1: Establish an Implementation Requirements List 53 Task 2: Create an Implementation and Verification Plan 54 Task 3: Implement and Verify 56 Alternate Resources and Solutions 58 Hints 61 Lab 2-2 Hint Sheet: Configure and Verify EIGRP Circuit Emulation and Frame Relay Operations 61 Lab 2-3: Configure and Verify EIGRP Authentication 80 Activity Objective 80 Information Packet 80 Implementation Policy 81 Device Information 81 Command List 82 Required Resources 82 Job Aids 82 Task 1: Establish an Implementation Requirements List 83 Task 2: Create an Implementation and Verification Plan 84 Task 3: Implement and Verify 86 Alternate Resources and Solutions 88

Hints 91 Lab 2-3 Hint Sheet: Configure and Verify EIGRP Authentication 91 Lab 2-4: Implement and Troubleshoot EIGRP Operations 100 Activity Objective 100 Information Packet 100 Troubleshooting Policy 100 Device Information 101 Command List 102 Required Resources 102 Job Aids 103 Task 1: Create an Troubleshooting and Verification Plan 104 Task 2: Troubleshooting Log 106 Hints 108 Lab 2-4 Hint Sheet: Implement and Troubleshoot EIGRP Operations 108 Lab 3-1: Configure and Verify OSPF to Improve Routing Performance 112 Activity Objective 112 Information Packet 112 Implementation Policy 113 Device Information 114 Command List 114 Required Resources 115 Job Aids 115 Task 1: Establish an Implementation Requirements List 116 Task 2: Create an Implementation and Verification Plan 117 Task 3: Implement and Verify 119 Alternate Resources and Solutions 121 Hints 124 Lab 3-1 Hint Sheet: Configure and Verify OSPF to Improve Routing Performance 124 Lab 3-2: Implement and Verify OSPF Multiarea Routing 137 Activity Objective 137 Information Packet 137 Implementation Policy 138 Device Information 139 Command List 139 Required Resources 140 Job Aids 140 Task 1: Establish an Implementation Requirements List 141 Task 2: Create an Implementation and Verification Plan 143 Task 3: Implement and Verify 145 Alternate Resources and Solutions 147 Hints 149 Lab 3-2 Hint Sheet: Implement and Verify OSPF Multiarea Routing 149 Lab 3-3: Configure and Verify OSPF Route Summarization for Interarea and External Routes 164 Activity Objective 164 Information Packet 164 Implementation Policy 165 Device Information 166 Command List 166 Required Resources 166 Job Aids 167 Task 1: Establish an Implementation Requirements List 168 Task 2: Create an Implementation and Verification Plan 170 Task 3: Implement and Verify 172 Alternate Resources and Solutions 174 Hints 176 Lab 3-3 Hint Sheet: Configure and Verify OSPF Route Summarization for Interarea and External Routes 176

ii

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab 3-4: Configure and Verify OSPF Special Area Types 190 Activity Objective 190 Information Packet 190 Implementation Policy 191 Device Information 192 Command List 193 Required Resources 193 Job Aids 193 Task 1: Establish an Implementation Requirements List 194 Task 2: Create an Implementation and Verification Plan 196 Task 3: Implement and Verify 198 Alternate Resources and Solutions 200 Hints 202 Lab 3-4 Hint Sheet: Configure and Verify OSPF Special Area Types 202 Lab 3-5: Configure and Verify OSPF Authentication 220 Activity Objective 220 Information Packet 220 Implementation Policy 221 Device Information 221 Command List 222 Required Resources 222 Job Aids 222 Task 1: Establish an Implementation Requirements List 223 Task 2: Create an Implementation and Verification Plan 225 Task 3: Implement and Verify 227 Alternate Resources and Solutions 229 Hints 231 Lab 3-5 Hint Sheet: Configure and Verify OSPF Authentication 231 Lab 4-1: Configure Route Redistribution Between Multiple IP Routing Protocols 246 Activity Objective 246 Information Packet 246 Implementation Policy 247 Device Information 248 Command List 249 Required Resources 250 Job Aids 250 ------- The page intentionally left blank. --------Task 1: Establish an Implementation Requirements List 251 Task 1: Establish an Implementation Requirements List 252 Task 2: Create an Implementation and Verification Plan 254 Task 3: Implement and Verify 256 Alternate Resources and Solutions 257 Hints 258 Lab 4-1 Hint Sheet: Configure Route Redistribution Between Multiple IP Routing Protocols 258 Lab 5-1: Configure and Verify Path Control Between Multiple IP Routing Protocols 271 Activity Objective 271 Information Packet 271 Implementation Policy 272 Device Information 272 Command List 273 Required Resources 273 Job Aids 273 Task 1: Establish an Implementation Requirements List 275 Task 2: Create an Implementation and Verification Plan 277 Task 3: Implement and Verify 279 Alternate Resources and Solutions 281 Hints 283 Lab 5-1 Hint Sheet: Configure and Verify Path Control Between Multiple IP Routing Protocols283

2009 Cisco Systems, Inc.

Implementing Cisco IP Routing (ROUTE) v1.0

iii

Lab 6-1: Configure BGP Operations 291 Activity Objective 291 Information Packet 291 Implementation Policy 292 Device Information 292 Command List 293 Required Resources 293 Job Aids 294 Task 1: Establish an Implementation Requirements List 295 Task 2: Create an Implementation and Verification Plan 297 Task 3: Implement and Verify 299 Alternate Resources and Solutions 301 Hints 303 Lab 6-1 Hint Sheet: Configure BGP Operations 303 Lab 6-2: Manipulate EBGP Path Selections 317 Activity Objective 317 Information Packet 317 Implementation Policy 317 Device Information 318 Command List 319 Required Resources 319 Job Aids 319 Task 1: Establish an Implementation Requirements List 321 Task 2: Create an Implementation and Verification Plan 322 Task 3: Implement and Verify 323 Alternate Resources and Solutions 325 Hints 327 Lab 6-2 Hint Sheet: Manipulate EBGP Path Selections 327 Answer Key 339 Lab 1-1 Answer Key: Assess Skills for Implementing Complex Networks 339 Lab 2-1 Answer Key: Configure and Verify EIGRP Operations 339 Lab 2-2 Answer Key: Configure and Verify EIGRP Circuit Emulation and Frame Relay Operations 344 Lab 2-3 Answer Key: Configure and Verify EIGRP Authentication 349 Lab 2-4 Answer Key: Implement and Troubleshoot EIGRP Operations 355 Lab 3-1 Answer Key: Configure and Verify OSPF to Improve Routing Performance 360 Lab 3-2 Answer Key: Implement and Verify OSPF Multiarea Routing 366 Lab 3-3 Answer Key: Configure and Verify OSPF Route Summarization for Interarea and External Routes 371 Lab 3-4 Answer Key: Configure and Verify OSPF Special Area Types 377 Lab 3-5 Answer Key: Configure and Verify OSPF Authentication 383 Lab 4-1 Answer Key: Configure Route Redistribution Between Multiple IP Routing Protocols 388 Lab 5-1 Answer Key: Configure and Verify Path Control Between Multiple IP Routing Protocols 394 Lab 6-1 Answer Key: Configure BGP Operations 400 Lab 6-2 Answer Key: Manipulate EBGP Path Selections 405

iv

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

ROUTE

Lab Guide Overview This guide presents the instructions and other information concerning the lab activities for the Implementing Cisco IP Routing (ROUTE) v1.0 course. You can find the solutions in the lab activity Answer Key.

Outline This guide includes these activities: Lab 1-1: Assess Skills for Implementing Complex Networks —

Lab

—

Hints

Lab 2-1: Configure and Verify EIGRP Operations —

Lab

—

Hints

Lab 2-2: Configure and Verify EIGRP Circuit Emulation and Frame Relay Operations —

Lab

—

Hints

Lab 2-3: Configure and Verify EIGRP Authentication —

Lab

—

Hints

Lab 2-4: Implement and Troubleshoot EIGRP Operations —

Lab

—

Hints

Lab 3-1: Configure and Verify OSPF to Improve Routing Performance —

Lab

—

Hints

Lab 3-2: Implement and Verify OSPF Multiarea Routing —

Lab

—

Hints

Lab 3-3: Configure and Verify OSPF Route Summarization for Interarea and External Routes —

Lab

—

Hints

Lab 3-4: Configure and Verify OSPF Special Area Types —

Lab

—

Hints

Lab 3-5: Configure and Verify OSPF Authentication —

Lab

—

Hints

Lab 4-1: Configure Route Redistribution Between Multiple IP Routing Protocols —

Lab

—

Hints

Lab 5-1: Configure and Verify Path Control Between Multiple IP Routing Protocols —

Lab

—

Hints

Lab 6-1: Configure BGP Operations —

Lab

—

Hints

Lab 6-2: Manipulate EBGP Path Selections —

Lab

—

Hints

Answer Key

2

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab 1-1: Assess Skills for Implementing Complex Networks Complete this lab activity to confirm and refresh your Layer 2 and Layer 3 skills from Interconnecting Cisco Networking Devices Part 2 (ICND2).

Activity Objective In this activity, you will put together a network implementation plan for an complex enterprise network. This lab activity is designed to reinforce the skills necessary to build a network implementation plan for complex networks. You will need to identify network requirements, acquire required information, and create a network implementation plan for one part of the complex enterprise network. One campus network will be implemented. After completing this activity, you will be able to meet these objectives: Identify the requirements the network has to provide Identify the required information Identify the tasks necessary for the implementation and create an implementation plan Verify the activity

Information Packet The figures illustrate what you will accomplish in this activity.

Visual Objective

Visual Objective for Lab 1-1: Assess Skills for Implementing Complex Networks

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1.0—LG-4

Lab Guide

3

Visual Objective for Lab 1-1: Campus Network To Be Implemented

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1.0—LG-5

Implementation Policy You were hired by No-route, Inc. to implement their Layer 3 enterprise network. They provided you with a cabling plan and asked you to help them implement routing in their network. As you were collecting information about their network infrastructure, they provided the following diagrams and list of equipment. The first figure in the Visual Objective diagrams represents an enterprise network. The second figure represents network at No-route, Inc., which is simplified in order to create the implementation plan as part of Lab 1-1. Their infrastructure includes these submodules: Access Distribution Backbone The equipment is not installed yet. At the beginning typical requirements for a network must be identified. A quick call to the local administrator results in identification of the following requirements: Functionality: The enterprise network must support the applications and data flows required within the required time frames. Performance: Performance includes three primary metrics: responsiveness, throughput (volume), and utilization. Scalability: Networks must provide scalability for future growth including new users and the amount of data and applications that the network must support.

4

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Availability: Nearly 100 percent availability is required for most enterprise data networks. (Critical applications may be required to meet a standard of availability approaching 99.999 percent [“five nines”]). Manageability: A network must be manageable across the entire infrastructure. Cost-effectiveness: Cost-effectiveness is a key concern for most enterprises, given limited budgets. Based on the important parameters above, determine what network information must be identified. The detailed requirements for the implementation plan to employ routing in a customer network must be collected. Collect all of the required parameters in order to correctly implement the network. All of the details needed for the configuration must be provided by the customer. When all details are defined and documented, you can plan the implementation and create the implementation plan, which describes the steps required to implement routing in the customer network. Planning means deciding on a starting point and determining the progression of steps necessary to configure the network and make it operational. Spend some time discussing the best course of action with your pod partner to allow for the most efficient way of configuring the network.

Device Information The table provides the information specific to each switch in the network: Device name

Role

R1

POD router

R2

POD router

R3

POD router

R4

POD router

SW1

POD switch

BBR1

Backbone router

BBR2

Backbone router

IP address

Gateway

VLAN

Required Resources These are the resources and equipment that are required to complete this activity: A PC that is connected to an on-site laboratory or a PC with an Internet connection if remote laboratory equipment must be accessed A terminal server that is connected to the console port of each laboratory device, if using a remote laboratory Core and access switches in your pod

© 2009 Cisco Systems, Inc.

Lab Guide

5

Job Aids These are the job aids for this lab activity:

6

Value

Location

Blank network device requirements list

Task 1

Blank implementation requirements list

Task 2

Blank implementation and verification plan form

Task 3

Debrief alternate solutions form

End of this lab

Implementation requirement hints

“Hints” section at the end of this lab

Implementation hints

“Hints” section at the end of this lab

Verification hints

“Hints” section at the end of this lab

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Task 1: Identify the Network Requirements The first step in your configuration deployment is to identify the requirements of each device according to the customer network requirements.. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Device

© 2009 Cisco Systems, Inc.

Implementation Requirement

Lab Guide

7

Task 2: Identify and Gather the Required Information The second step in your configuration deployment is to gather and document all the detailed information that will be used to create an implementation and verification plan. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Complete

8

Device

Implementation Order

Implementing Cisco IP Routing (ROUTE) v1.0

Values and Items to Implement

© 2009 Cisco Systems, Inc.

Complete

© 2009 Cisco Systems, Inc.

Device

Implementation Order

Values and Items to Implement

Lab Guide

9

Task 3: Create an Implementation and Verification Plan The beginning of any successful implementation is the creation of the implementation and verification plan. Create a list of steps needed to implement and verify the routing in the customer network. For the purpose of Lab 1-1, there is no need to use configuration commands. The implementation plan should define the general steps required to implement and verify routing in the customer network. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Complete

10

Device

Feature

Implementing Cisco IP Routing (ROUTE) v1.0

Verification Method and Expected Results

© 2009 Cisco Systems, Inc.

Complete

© 2009 Cisco Systems, Inc.

Device

Feature

Verification Method and Expected Results

Lab Guide

11

Alternate Resources and Solutions Other groups may have implemented a solution that is different from yours. These will be discussed during the debriefing period that will follow this lab. Use the following space to document other possible solutions for your reference. __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ 12

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Hints You are encouraged to complete the labs using your knowledge. However, this section contains a series of hints to aid your completion of the lab.

Lab 1-1 Hint Sheet: Assess Skills for Implementing Complex Networks Identify the Requirements the Network Must Provide To facilitate the configuration of your network, the first task asks you to identify the requirements of the network—the things that the network must provide according to the customer specifications. This list details the elements you need in order to develop an implementation plan. The following is an example of such a list: No.

Implementation Requirement

1.

Application and data requirements

2.

Existing equipment and software version

3.

Existing topology (logical and physical)

4.

IP addressing plan

5.

Select routing protocols

6.

Scalability configuration (summarization, stub areas, and so on)

Implementation Requirements The second task asks you to create an implementation requirements list. This list details the elements you need in order to develop an implementation plan. The following is an example of such a list with details: Application and data requirements

© 2009 Cisco Systems, Inc.

Lab Guide

13

Name of Application

Building or Location

Type of Application

Number of Users

Number of Servers

Bandwidth/ Delay Tolerance/ Loss Characteristics

Marketing DSS

Building 1

Database

137

3

High bandwidth High delay tolerance

(OLAP)

Low loss Corporate email

Building 2

Email

65

2

Low bandwidth Low delay tolerance Low loss

File server

Building 3

File sharing (FTP)

48

1

Low bandwidth Medium delay tolerance Low loss

Existing equipment and software version Device

Role

Software Version

CLT1

Client station

Mac OS

CLT2

Client station

Windows OS

SW1

Access switch

Advanced IP service 12.2-46

R1

Distribution router

Advanced IP service 12.4(10)

R2

Distribution router

Advanced IP service 12.4(10)

R3

Distribution router

Advanced IP service 12.4(10)

R4

Distribution router

Advanced IP service 12.4(10)

BBR1

Core router

Advanced IP service 12.4(10)

BBR2

Core router

Advanced IP service 12.4(10)

Existing topology (logical and physical)

14

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Visual Objective for Lab 1-1: Physical Topology

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v1.0—LG-6

IP addressing plan Link

Network

R1 to R2

10.1.112.0/24

R1 LAN, R3 LAN

172.30.13.0/24

R3 to R4

10.1.134.0/24

R2 AN, R4 LAN

172.30.24.0/24

R1 to BBR1

10.1.115.0/24

R2 to BBR2

10.1.116.0/24

Select routing protocols EIGRP is selected as the interior gateway protocol because the following network characteristics are required for the customer: supports large network size, has very high speed of convergence, and supports VLSM. BGP is selected as the exterior gateway protocol because complex enterprise networks support redundant connectivity to ISPs and the customer has its own public IP addresses and public BGP autonomus system number. Scalability configuration (summarization, stub areas, and so on ) The network design uses IP addressing, which supports summarization on every distribution router. Some branch offices are configured as stub networks. The default route is sent inside the stub network and only summary IP addresses are propagated outside of the stub network.

© 2009 Cisco Systems, Inc.

Lab Guide

15

Implementation Plan In Task 3 you need to create an implementation and verification plan and document the plan. There are several possible ways to accomplish this task. One possible way is to group items that are common to all devices in a template, and then apply this template to all of the devices. You can then configure each device with items that are unique to each device, such as IP addresses or gateway. The implementation steps are specified in the following list: Document network information. Prepare the required resources. —

Connect the PC to the equipment.

—

Select specific tools and equipment.

—

Select and reserve resources (project contact list).

Configure the IP addressing on all devices in the network. Enable all of the interfaces. Configure the IP routing protocol where needed. Configure summarization and stub areas. Verify proper operation of IP routing protocol; check the connectivity in the network. Measure the performance and document the results. Create a backup of the configuration. Document the implementation plan, baseline, performance, and recommendations. Verification Plan Complete

16

Device

Feature

Verification Method and Expected Results

Hint

ALL

All Interfaces must be enabled.

ALL

Configuration of the routing protocol must be done and the verification must prove that the routing protocol is running.

ALL

Required networks must be advertised.

R1, R2

Summary route to Null0 must appear on every customer edge router.

ALL

Preferred path must be selected by the routing protocol.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Complete

© 2009 Cisco Systems, Inc.

Device

Feature

Verification Method and Expected Results

Hint

Lab Guide

17

-------- This page intentionally left blank. --------

18

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab 2-1: Configure and Verify EIGRP Operations Complete this lab activity to practice what you learned in the related module.

Activity Objective In this activity, you will use correct commands, tools, and steps to configure and verify a basic EIGRP implementation. After completing this activity, you will be able to meet these objectives: Configure and verify basic EIGRP operation over WAN and LAN interfaces Select the required tools and commands to configure basic EIGRP operations Configure EIGRP on the LAN interfaces using a secondary IP address on one router Influence the path selection for EIGRP by changing the metric Optimize EIGRP operation to prevent unnecessary hellos from being sent Optimize EIGRP operation by minimizing the routing table size using summarization Make a list of the configuration and implementation steps Write a verification and test plan to verify the proper implementation and operation according to the expected performance criteria Verify the configuration and operation by using the proper show and debug commands

Information Packet The figure illustrates what you will accomplish in this activity.

Visual Objective

Visual Objective for Lab 2-1: Configure and Verify Basic EIGRP Operations

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1.0—LG-7

Lab Guide

19

Implementation Policy The following lists the detailed configuration requirements for all devices in the company network: Set the proper initial configuration on all devices in your lab. The instructor will provide the necessary information on how to set the initial configuration on all devices. First, a basic EIGRP configuration is required on each of the routers in your network— routers R1, R2, R3, and R4. The EIGRP will be used to exchange routing information in order to achieve IP connectivity between the subnets deployed on your routers and backbone BBR1 router as well. The EIGRP configuration should be so specific that if an additional network is added to the router, such a network is not automatically advertised. The IP routing tables on all your routers should be populated with all of the specific IP subnets in your network. Automatic summarization must be disabled. Basic EIGRP configuration must be verified in order to see if it meets requirements. Verify that the proper EIGRP adjacencies have been set up between the routers in your pod and between routers R1 and BBR1. Router R1 should have established three adjacencies and routers R2, R3, and R4 should have established two adjacencies. Examine each router and make sure that EIGRP has been set up to advertise the IP subnets present on WAN and LAN interfaces with the correct mask, without examining the IP routing table and EIGRP topology database. Verify the EIGRP topology database and compare it against the EIGRP information that was put into the IP routing table on router R1. You should be able to see that all of the networks acquired via EIGRP were put into the routing table and that the metric related to an individual route corresponds to the value present in the topology table. Examine the EIGRP topology table and IP routing table on router R4 also. Keep in mind that R4 has two paths in the topology and IP routing table for the networks that are external to your pod. If you look at the metric either in the topology table or in the IP routing table for the network 192.168.1.0/24, you can see that the metric is the same for both sources. Therefore there are equal cost paths for the same destination being installed in the routing table. Examine the EIGRP in action: enable EIGRP event debugging on router R4 and disable the interface between routers R1 and R2. When the debug output is observed, you should see EIGRP packets being exchanged, and that for network 10.1.112.0/24 (the one used between R1 and R2), router R4 responds with an infinite metric to an EIGRP query. EIGRP can install multiple equal cost paths into the routing table, which is what happens on router R4. Tis router has two possible paths to the destination networks that are external to your pod. For the metric calculation, EIGRP uses multiple parameters such as delay and bandwidth. In this task, you will influence EIGRP path selection by changing the metric of the routes to eliminate equal cost paths from the router R4 routing table, but still preserve the EIGRP fast convergence in a case of topology change. Verify the path selection process by examining the router R4 EIGRP topology table and verify that two paths still exist for the 192.168.x.0/24 subnets, with the path via router R3 being the secondary option. Verify on the router R4 routing table that only the best path to destination networks 192.168.x.0/24 exists, the path through router R2. Verify that the secondary path through router R3 is put into the routing table of router R4 in case of a primary path failure without an FD change. When a network statement is used under EIGRP, EIGRP not only starts to advertise that subnet but also tries to form an adjacency through that interface. EIGRP does so by sending hello packets. Sometimes this is not desired; thus, the adjacency formation should be prevented by suppressing the hello packets. Disable the unnecessary EIGRP adjacencies to preserve the interface bandwidth and the CPU resources of the router. The configuration will be added to routers R1 and R3.

20

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Verify that you have disabled EIGRP between routers R1 and R3 on the LAN segment and that hello packets are suppressed and not being sent over the LAN interface on routers R1 and R3. An EIGRP adjacency between routers R1 and R3 over the LAN interface must not be present. At the same time, the IP routing table on router R4 still has information on how to access the network 172.30.13.0/24 used on the LAN interface between routers R1 and R3. As a last step, you must enable the EIGRP route summarization for the networks external to your pod, that is, the 192.168.x.0/24 networks. This configuration will add to the stability and speed of the convergence for the network by controlling the scope of queries, minimizing update traffic, and minimizing routing table size. Verify that manual route summarization for subnets 192.168.x.0/24 is applied on router R1, the more specific 192.168.x.0/24 subnets, and the 192.168.0.0/16 summary route pointing to the Null0 interface in the router R1 routing table. Routing tables on routers R2, R3, and R4 must have a summary route 192.168.0.0/16 and no specific 192.168.x.0/24 subnets. You do not have to apply summarization on the LAN interface because an EIGRP adjacency is disabled there. Keep in mind that you also do not have to enable summarization on Serial0/0/0.2 toward router BBR1 because the subnets are received from router BBR1.

Device Information The table provides information specific to each switch in the network: Device Name

Role

R1

POD router

R2

POD router

R3

POD router

R4

POD router

BBR1

Backbone router

© 2009 Cisco Systems, Inc.

IP Address

Gateway

VLAN

Lab Guide

21

Command List The table describes the commands that are used in this activity. Command

Description

(no) auto-summary

Enables (disables) automatic summarization of classless subnets

(no) shutdown

Administratively disables (enables) the interface

debug ip eigrp

Enables EIGRP event debugging

delay tens-of-microsec

Specifies the delay on interfaces (used for routing processes)

interface type slot/port

Enters the interface configuration mode

ip summary-address eigrp asnumber network mask

Configures manual EIGRP summarization on an interface

network x.x.x.x

Enables EIGRP on interfaces belonging to a specified network

passive-interface interface

Disables EIGRP hellos to be sent on an interface

router eigrp as-number

Starts an EIGRP routing process with the given AS number

show ip eigrp neighbors

Lists the EIGRP neighbors and relevant information on EIGRP neighbor adjacencies

show ip eigrp topology [prefix] [mask]

Displays the EIGRP topology table (whole, or only per prefix/mask)

show ip protocols

Shows the information about the configured IP protocols

show ip route [eigrp]

Displays the whole IP routing table or EIGRP routes only

undebug all

Disables debugging on the router

Required Resources These are the resources and equipment that are required to complete this activity: A PC that is connected to an on-site laboratory or a PC with an Internet connection if remote laboratory equipment must be accessed A terminal server that is connected to the console port of each laboratory device, if using a remote laboratory Core and access switches in your pod

22

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Job Aids These are the job aids for this lab activity: Value

Location

Blank implementation requirements list

Task 1

Blank implementation and verification plan form

Task 2

Blank verification notes form

Task 3

Alternate resources and solutions form

End of this lab

Implementation requirements hints

“Hints” section at the end of this lab

Implementation and verification form hints

“Hints” section at the end of this lab

Implementation and verification hints

“Hints” section at the end of this lab

Solution configuration answer key (step-by-step procedure)

End of the “Hints” section at the end of this lab

© 2009 Cisco Systems, Inc.

Lab Guide

23

-------- This page intentionally left blank. --------

24

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Task 1: Establish an Implementation Requirements List The first step in your configuration deployment is to establish a list of what you need in order to configure each device; for example, device names, trunk encapsulation types, and so on. Use the following table, the visual objective at the beginning of this lab, the implementation policy, and the device information to create your implementation requirements list. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Device

© 2009 Cisco Systems, Inc.

Implementation Requirement

Lab Guide

25

Task 2: Create an Implementation and Verification Plan The second step in your configuration deployment is to establish a task list of the items that must be configured on each device, and in what order. You can use the following table, the visual objective at the beginning of this lab, the implementation policy, and the device information to create your implementation and verification plan. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Complete

26

Device

Order

Implementing Cisco IP Routing (ROUTE) v1.0

Values and Items to Implement

Verification Method and Expected Results

© 2009 Cisco Systems, Inc.

Complete

© 2009 Cisco Systems, Inc.

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Lab Guide

27

Task 3: Implement and Verify Now that you have collected all the requirements and planned your implementation, you are ready to connect to the remote lab and implement your solution. Do not forget to save. Once you implement your solution, you need to verify that your configuration is working and fulfills all of the requirements specified by the customer. Keep in mind that once you leave the customer location, a network specialist will verify your configuration. Your ability to implement the solution according to the specifications provided by the customer will determine whether you get the job or not. Use the following area to record your notes and document the verifications you conducted to ensure that your solution is complete. If you are unsure of the verification steps, use the information provided in the “Hints” section at the end of this lab. Student Notes: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ 28

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

© 2009 Cisco Systems, Inc.

Lab Guide

29

Alternate Resources and Solutions Other groups may have implemented a solution that is different from yours. These will be discussed during the debriefing period that will follow this lab. Use the following space to document other possible solutions for your reference. __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ 30

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

© 2009 Cisco Systems, Inc.

Lab Guide

31

------- This page intentionally left blank. --------

32

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Hints You are encouraged to complete the labs using your knowledge. However, this section contains a series of hints to aid your completion of the lab.

Lab 2-1 Hint Sheet: Configure and Verify EIGRP Operations Implementation Requirements To facilitate the configuration of your network, the first task asks you to create an implementation requirements list. This list details the elements you need in order to develop an implementation plan. The following is an example of such a list: Device

Implementation Requirement

ALL

Define EIGRP AS number used in the lab.

Check AS number used in the BBR1 router

ALL

Define which networks are used in the lab in order to advertise all specific networks.

Visual Objective diagrams

R4

Examine and write down the metric for 192.168.x.0/24 subnets for both possible paths by looking into the EIGRP topology table.

Lab

R1, R3

Examine and write down the current delay value of the FastEthernet0/0 interfaces.

Lab

R4

Check for the specific 192.168.x.0/24 subnets in order to apply manual summarization.

Lab

© 2009 Cisco Systems, Inc.

Hint

Lab Guide

33

Implementation and Verification Plan In Task 2, you will create an implementation and verification plan. Although there are several ways to set up this plan, the following tasks must be completed: Complete

34

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1–R4

1

Load initial configuration

All pod routers must be preloaded with the initial configuration for the lab.

Step 1

R1

2

Enable EIGRP routing protocol on router R1 on the WAN interfaces Serial 0/0.1, Serial0/0.2, and on the LAN interface FastEthernet0/0. Router BBR1 is preconfigured with EIGRP AS 1. Apply the configuration in a way that EIGRP does not automatically advertise any additional network that is added to the router.

Verify that the proper EIGRP adjacencies have been set up between the routers in your pod and between routers R1 and BBR1.

Step 2

R1–R4

3

Enable EIGRP routing protocol on routers R2, R3, and R4, on the WAN interface Serial 0/0.1, and on the LAN interface FastEthernet0/0. Apply the configuration in a way that EIGRP does not automatically advertise any additional networks that are added to the router.

Verify that router R1 has established three adjacencies, and routers R2, R3, and R4 have two adjacencies. Also examine how long the adjacencies have been set up and whether there is any problem with neighbor communication, such as routing packets remaining in the queue.

Step 3

R1, R4

4

Verify on routers R1 and R4 that the EIGRP has been set up to advertise the IP subnets present on the WAN and LAN interfaces with the correct mask without examining the IP routing table and EIGRP topology database.

Step 4

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Complete

Device

Order

R1

Verification Method and Expected Results

Step

5

Verify the EIGRP topology database and compare it to the EIGRP information that was put into the IP routing table on router R1. You should be able to see that all networks acquired via EIGRP were put into the routing table and that the metric related to an individual route corresponds to the value present in the topology table.

Step 4

R4

6

Examine the EIGRP topology table and IP routing table on router R4. Keep in mind that R4 has two paths in the topology and the IP routing table for the networks that are external to your pod. If you look at the metric either in the topology table or in the IP routing table for the network 192.168.1.0/24, you can see that the metric is the same for both sources, thus we have equal cost paths for the same destination being installed in the routing table.

Step 4

R1, R2, R4

7

Examine the EIGRP in action; that is, enable EIGRP event debugging on router R4 and disable the interface between routers R1 and R2. Observing the debug output, you should see EIGRP packets being exchanged and that for network 10.1.112.0/24 (the one used between R1 and R2), R4 responds with an infinite metric to an EIGRP query.

Step 5

© 2009 Cisco Systems, Inc.

Values and Items to Implement

Lab Guide

35

Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1, R3, R4

8

Change the delay parameter on the LAN segment between routers R1 and R3 so that the preferred path to the 192.168.x.0/24 subnets for router R4 is through router R2.

Examine the EIGRP topology table for router R4 and verify that two paths still exist for the 192.168.x.0/24 subnets, with the path via R3 being the secondary option.

Step 6

Enable the interfaces that were disabled in order to simulate the failure.

Examine the routing table for router R4 to verify that only the best path to destination networks 192.168.x.0/24 exist, the one through router R2.

R4

9

The configuration should not prevent router R4 from using the second path in case of a primary path failure; that is, the secondary path should become a successor.

Verify that the secondary path through router R3 is put into the routing table of router R4 in case of a primary path failure without the FD being changed.

Step 7

R1, R3, R4

10

Prevent routers R1 and R3 from forming an EIGRP adjacency over the LAN network to preserve the interface bandwidth and CPU resources on the routers. The configuration you apply should prevent the routers from sending EIGRP hello packets over the FastEthernet0/0 interface. You should not apply other types of filtering.

Verify that EIGRP between routers R1 and R3 on the LAN segment is disabled, hello packets are suppressed from being sent over the LAN interface on routers R1 and R3, and the EIGRP adjacency between R1 and R3 over the LAN interface is not present.

Step 8

Enable the interfaces that were disabled in order to simulate the failure.

36

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Complete

Device

Order

R4

11

Values and Items to Implement

Verification Method and Expected Results

Step

Verify that the IP routing table on router R4 still has the information on how to access the network 172.30.13.0/24, which is used on the LAN interface between routers R1 and R3, and that R4 still knows how to reach the network 172.30.12.0/24 on the LAN segment between routers R1 and R3.

Step 8

Verify that you can see the individual 192.168.x.0/24 networks in the IP routing table on router R4. R1–R4

12

Enable manual summarization of the 192.168.x.0/24 networks on router R1 to advertise only 192.168.0.0/16 to the rest of the routers in your pod.

Verify that the routing table on router R1 holds the specific 192.168.x.0/24 subnets and 192.168.0.0/16 summary route pointing to the Null0 interface.

Step 9

Verify that the routing tables on routers R2, R3, and R4 have summary route 192.168.0.0/16 and no specific 192.168.x.0/24 subnets.

Step-by-Step Procedure for Implementation and Verification 1. Load the initial configuration on all devices in your lab. 1.1. The instructor will provide the guidelines for changing the initial configuration. 2. Configure EIGRP on router R1 in your pod. 2.1. Use the following example to configure router R1 in this lab: Îďý ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňďňďďîňđ đňđňđňîëë ˛»¬©±®µ ďđňďňďďëňđ đňđňđňîëë ˛»¬©±®µ ďéîňíđňďíňđ đňđňđňîëë ˛± ż«¬±ó­«łłż®§

2.2. Verify the EIGRP configuration on router R1. Îďý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» đ

ďđňďňďďëňë

© 2009 Cisco Systems, Inc.

Í»đńđńđňě

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďď đđćďéćďę ďîíç

ÎĚŃ

Ď Í»Ż ݲ¬ Ň«ł ëđđđ đ í

Lab Guide

37

3. Configure EIGRP on routers R2 through R4 in your pod. 3.1. Use the following example to configure the routers in this lab: Îîý ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňďňďďîňđ đňđňđňîëë ˛»¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ˛± ż«¬±ó­«łłż®§ Îíý ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňďňďíěňđ đňđňđňîëë ˛»¬©±®µ ďéîňíđňďíňđ đňđňđňîëë ˛± ż«¬±ó­«łłż®§ Îěý ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňďňďíěňđ đňđňđňîëë ˛»¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ˛± ż«¬±ó­«łłż®§

3.2. Verify the EIGRP adjacencies on your pod router. Îďý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» î ď đ

ďđňďňďďëňë ďđňďňďďîňî ďéîňíđňďíňí

Í»đńđńđňě Í»đńđńđňď Úżđńđ

Îîý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» ď đ

ďđňďňďďîňď ďéîňíđňîěňě

Í»đńđńđňď Úżđńđ

Îíý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» ď đ

ďéîňíđňďíňď ďđňďňďíěňě

Úżđńđ Í»đńđńđňí

Îěý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» ď đ

ďđňďňďíěňí ďéîňíđňîěňî

Í»đńđńđňí Úżđńđ

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďď đđćďéćďę ďîíç ďî đđćďéćîë ëíč ďí đđćďéćíď ěďę

ÎĚŃ

Í»Ż Ň«ł í ďě ďí

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďđ đđćďçćëę íç ďě đđćîďćďď ď

ÎĚŃ

Ď Ý˛¬ îíě đ îđđ đ

Í»Ż Ň«ł îđ ďî

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďě đđćîđćëď í ďđ đđćîďćďé ęéđ

ÎĚŃ

Í»Ż Ň«ł ďç ďí

ÎĚŃ

Í»Ż Ň«ł ďě ďí

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďě đđćîîćîë ěď ďď đđćîíćđč ď

Ď Ý˛¬ ëđđđ đ íîîč đ îěçę đ

Ď Ý˛¬ îđđ đ ěđîđ đ

Ď Ý˛¬ îěę đ îđđ đ

4. Verify that the EIGRP topology and IP routing table appear on the routers in your pod. Îďý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňîěňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďîňîô ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďđňďňďíěňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňďíňíô Ü ďçîňďęčňďňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďďëňëô Ü ďçîňďęčňîňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďďëňëô Ü ďçîňďęčňíňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďďëňëô

đěćďíćîéô Í»®·ż´đńđńđňď đěćďíćîéô đěćďíćďçô đěćďíćďçô đěćďíćďçô

Úż­¬Ű¬¸»®˛»¬đńđ Í»®·ż´đńđńđňě Í»®·ż´đńđńđňě Í»®·ż´đńđńđňě

Îîý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňďíňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďîňďô đđćíďćîîô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ 38

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ü Ü Ü Ü Ü

ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďîňďô đđćíďćîîô Í»®·ż´đńđńđňď ďđňďňďíěňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňîěňěô đđćíďćîîô Úż­¬Ű¬¸»®˛»¬đńđ ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďîňďô đđćíďćîîô Í»®·ż´đńđńđňď ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďîňďô đđćíďćîîô Í»®·ż´đńđńđňď ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďîňďô đđćíďćîîô Í»®·ż´đńđńđňď

Îíý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňîěňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďíěňěô đđćíîćîđô Í»®·ż´đńđńđňí ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďđňďňďďëňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňďíňďô đđćíîćîéô Úż­¬Ű¬¸»®˛»¬đńđ Ü ďđňďňďďîňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňďíňďô đđćíîćđëô Úż­¬Ű¬¸»®˛»¬đńđ Ü ďçîňďęčňďňđńîě ĹçđńîíđđěďęĂ Ş·ż ďéîňíđňďíňďô đđćíîćîéô Úż­¬Ű¬¸»®˛»¬đńđ Ü ďçîňďęčňîňđńîě ĹçđńîíđđěďęĂ Ş·ż ďéîňíđňďíňďô đđćíîćîéô Úż­¬Ű¬¸»®˛»¬đńđ Ü ďçîňďęčňíňđńîě ĹçđńîíđđěďęĂ Ş·ż ďéîňíđňďíňďô đđćíîćîéô Úż­¬Ű¬¸»®˛»¬đńđ Îěý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňďíňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďíěňíô đđćíîćěđô Í»®·ż´đńđńđňí ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďđňďňďďëňđ ĹçđńîęčěěďęĂ Ş·ż ďéîňíđňîěňîô đđćíîćěđô Úż­¬Ű¬¸»®˛»¬đńđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďíěňíô đđćíîćěđô Í»®·ż´đńđńđňí Ü ďđňďňďďîňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňîěňîô đđćíîćěđô Úż­¬Ű¬¸»®˛»¬đńđ Ü ďçîňďęčňďňđńîě ĹçđńîčďîěďęĂ Ş·ż ďéîňíđňîěňîô đđćíîćěđô Úż­¬Ű¬¸»®˛»¬đńđ ĹçđńîčďîěďęĂ Ş·ż ďđňďňďíěňíô đđćíîćěđô Í»®·ż´đńđńđňí Ü ďçîňďęčňîňđńîě ĹçđńîčďîěďęĂ Ş·ż ďéîňíđňîěňîô đđćíîćěđô Úż­¬Ű¬¸»®˛»¬đńđ ĹçđńîčďîěďęĂ Ş·ż ďđňďňďíěňíô đđćíîćěđô Í»®·ż´đńđńđňí Ü ďçîňďęčňíňđńîě ĹçđńîčďîěďęĂ Ş·ż ďéîňíđňîěňîô đđćíîćěđô Úż­¬Ű¬¸»®˛»¬đńđ ĹçđńîčďîěďęĂ Ş·ż ďđňďňďíěňíô đđćíîćěđô Í»®·ż´đńđńđňí Îďý­¸±© ·° °®±¬±˝±´­ ᫬·˛ą Đ®±¬±˝±´ ·­ ţ»·ą®° ďţ Ń«¬ą±·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬ ײ˝±ł·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬ Ü»şż«´¬ ˛»¬©±®µ­ ş´żąą»Ľ ·˛ ±«¬ą±·˛ą «°Ľż¬»­ Ü»şż«´¬ ˛»¬©±®µ­ ż˝˝»°¬»Ľ ş®±ł ·˛˝±ł·˛ą «°Ľż¬»­ Ű×ŮÎĐ ł»¬®·˝ ©»·ą¸¬ Őďăďô Őîăđô Őíăďô Őěăđô Őëăđ Ű×ŮÎĐ łż¨·ł«ł ¸±°˝±«˛¬ ďđđ Ű×ŮÎĐ łż¨·ł«ł ł»¬®·˝ Şż®·ż˛˝» ď λĽ·­¬®·ľ«¬·˛ąć »·ą®° ď Ű×ŮÎĐ ŇÍÚóż©ż®» ®±«¬» ¸±´Ľ ¬·ł»® ·­ îěđ­ ß«¬±łż¬·˝ ˛»¬©±®µ ­«łłż®·¦ż¬·±˛ ·­ ˛±¬ ·˛ »şş»˝¬ Óż¨·ł«ł °ż¬¸ć ě ᫬·˛ą ş±® Ň»¬©±®µ­ć ďđňďňďďîňđńîě ďđňďňďďëňđńîě ďéîňíđňďíňđńîě ᫬·˛ą ײş±®łż¬·±˛ ͱ«®˝»­ć Ůż¬»©ż§ Ü·­¬ż˛˝» Ôż­¬ Ë°Ľż¬» ďđňďňďďîňî çđ đđćííćďç ďđňďňďďëňë çđ đđćíëćîď ďéîňíđňďíňí çđ đđćííćďç Ü·­¬ż˛˝»ć ·˛¬»®˛ż´ ç𠻨¬»®˛ż´ ďéđ Îîý­¸±© ·° °®±¬±˝±´­ ᫬·˛ą Đ®±¬±˝±´ ·­ ţ»·ą®° ďţ Ń«¬ą±·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬ ײ˝±ł·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬ Ü»şż«´¬ ˛»¬©±®µ­ ş´żąą»Ľ ·˛ ±«¬ą±·˛ą «°Ľż¬»­ Ü»şż«´¬ ˛»¬©±®µ­ ż˝˝»°¬»Ľ ş®±ł ·˛˝±ł·˛ą «°Ľż¬»­ Ű×ŮÎĐ ł»¬®·˝ ©»·ą¸¬ Őďăďô Őîăđô Őíăďô Őěăđô Őëăđ Ű×ŮÎĐ łż¨·ł«ł ¸±°˝±«˛¬ ďđđ Ű×ŮÎĐ łż¨·ł«ł ł»¬®·˝ Şż®·ż˛˝» ď λĽ·­¬®·ľ«¬·˛ąć »·ą®° ď Ű×ŮÎĐ ŇÍÚóż©ż®» ®±«¬» ¸±´Ľ ¬·ł»® ·­ îěđ­ ß«¬±łż¬·˝ ˛»¬©±®µ ­«łłż®·¦ż¬·±˛ ·­ ˛±¬ ·˛ »şş»˝¬ Óż¨·ł«ł °ż¬¸ć ě ᫬·˛ą ş±® Ň»¬©±®µ­ć © 2009 Cisco Systems, Inc.

Lab Guide

39

ďđňďňďďîňđńîě ďđňđňđňđ ďéîňíđňîěňđńîě ďéîňíđňđňđ ᫬·˛ą ײş±®łż¬·±˛ ͱ«®˝»­ć Ůż¬»©ż§ Ü·­¬ż˛˝» Ôż­¬ Ë°Ľż¬» ďđňďňďďîňď çđ đđćíěćđë ďéîňíđňîěňě çđ đđćíěćđë Ü·­¬ż˛˝»ć ·˛¬»®˛ż´ ç𠻨¬»®˛ż´ ďéđ Îíý­¸±© ·° °®±¬±˝±´­ ᫬·˛ą Đ®±¬±˝±´ ·­ ţ»·ą®° ďţ Ń«¬ą±·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬ ײ˝±ł·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬ Ü»şż«´¬ ˛»¬©±®µ­ ş´żąą»Ľ ·˛ ±«¬ą±·˛ą «°Ľż¬»­ Ü»şż«´¬ ˛»¬©±®µ­ ż˝˝»°¬»Ľ ş®±ł ·˛˝±ł·˛ą «°Ľż¬»­ Ű×ŮÎĐ ł»¬®·˝ ©»·ą¸¬ Őďăďô Őîăđô Őíăďô Őěăđô Őëăđ Ű×ŮÎĐ łż¨·ł«ł ¸±°˝±«˛¬ ďđđ Ű×ŮÎĐ łż¨·ł«ł ł»¬®·˝ Şż®·ż˛˝» ď λĽ·­¬®·ľ«¬·˛ąć »·ą®° ď Ű×ŮÎĐ ŇÍÚóż©ż®» ®±«¬» ¸±´Ľ ¬·ł»® ·­ îěđ­ ß«¬±łż¬·˝ ˛»¬©±®µ ­«łłż®·¦ż¬·±˛ ·­ ˛±¬ ·˛ »şş»˝¬ Óż¨·ł«ł °ż¬¸ć ě ᫬·˛ą ş±® Ň»¬©±®µ­ć ďđňďňďíěňđńîě ďéîňíđňďíňđńîě ᫬·˛ą ײş±®łż¬·±˛ ͱ«®˝»­ć Ůż¬»©ż§ Ü·­¬ż˛˝» Ôż­¬ Ë°Ľż¬» ďđňďňďíěňě çđ đđćíěćíë ďéîňíđňďíňď çđ đđćíěćíë Ü·­¬ż˛˝»ć ·˛¬»®˛ż´ ç𠻨¬»®˛ż´ ďéđ Îěý­¸±© ·° °®±¬±˝±´­ ᫬·˛ą Đ®±¬±˝±´ ·­ ţ»·ą®° ďţ Ń«¬ą±·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬ ײ˝±ł·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬ Ü»şż«´¬ ˛»¬©±®µ­ ş´żąą»Ľ ·˛ ±«¬ą±·˛ą «°Ľż¬»­ Ü»şż«´¬ ˛»¬©±®µ­ ż˝˝»°¬»Ľ ş®±ł ·˛˝±ł·˛ą «°Ľż¬»­ Ű×ŮÎĐ ł»¬®·˝ ©»·ą¸¬ Őďăďô Őîăđô Őíăďô Őěăđô Őëăđ Ű×ŮÎĐ łż¨·ł«ł ¸±°˝±«˛¬ ďđđ Ű×ŮÎĐ łż¨·ł«ł ł»¬®·˝ Şż®·ż˛˝» ď λĽ·­¬®·ľ«¬·˛ąć »·ą®° ď Ű×ŮÎĐ ŇÍÚóż©ż®» ®±«¬» ¸±´Ľ ¬·ł»® ·­ îěđ­ ß«¬±łż¬·˝ ˛»¬©±®µ ­«łłż®·¦ż¬·±˛ ·­ ˛±¬ ·˛ »şş»˝¬ Óż¨·ł«ł °ż¬¸ć ě ᫬·˛ą ş±® Ň»¬©±®µ­ć ďđňďňďíěňđńîě ďéîňíđňîěňđńîě ᫬·˛ą ײş±®łż¬·±˛ ͱ«®˝»­ć Ůż¬»©ż§ Ü·­¬ż˛˝» Ôż­¬ Ë°Ľż¬» ďđňďňďíěňí çđ đđćíëćďđ ďéîňíđňîěňî çđ đđćíëćďđ Ü·­¬ż˛˝»ć ·˛¬»®˛ż´ ç𠻨¬»®˛ż´ ďéđ Îďý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňďíňď÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę Ş·ż ďđňďňďďëňë řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđńđňě Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę Ş·ż ďđňďňďďëňë řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđńđňě Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę Ş·ż ďđňďňďďëňë řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđńđňě Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňě 40

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Đ ďđňďňďďîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňď Đ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďéîňíđňďíňí řîďéîěďęńîďęçčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďďîňî řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ Îîý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňîěňî÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďîňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďîňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďîňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďîňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňď Đ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďéîňíđňîěňě řîďéîěďęńîďęçčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďďîňď řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňď Îíý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňďíňí÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îíđđěďę Ş·ż ďéîňíđňďíňď řîíđđěďęńîîçéčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îíđđěďę Ş·ż ďéîňíđňďíňď řîíđđěďęńîîçéčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îíđđěďę Ş·ż ďéîňíđňďíňď řîíđđěďęńîîçéčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďéîňíđňďíňď řîďéîěďęńîďęçčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďđňďňďďîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďéîňíđňďíňď řîďéîěďęńîďęçčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňí Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďíěňě řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňí Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ Îěý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňîěňě÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďçîňďęčňďňđńîěô î ­«˝˝»­­±®­ô ÚÜ ·­ îčďîěďę Ş·ż ďđňďňďíěňí řîčďîěďęńîíđđěďę÷ô Í»®·ż´đńđńđňí Ş·ż ďéîňíđňîěňî řîčďîěďęńîčđçčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďçîňďęčňîňđńîěô î ­«˝˝»­­±®­ô ÚÜ ·­ îčďîěďę Ş·ż ďđňďňďíěňí řîčďîěďęńîíđđěďę÷ô Í»®·ż´đńđńđňí Ş·ż ďéîňíđňîěňî řîčďîěďęńîčđçčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďçîňďęčňíňđńîěô î ­«˝˝»­­±®­ô ÚÜ ·­ îčďîěďę © 2009 Cisco Systems, Inc.

Lab Guide

41

Đ Đ Đ Đ

Ş·ż ďđňďňďíěňí řîčďîěďęńîíđđěďę÷ô Í»®·ż´đńđńđňí Ş·ż ďéîňíđňîěňî řîčďîěďęńîčđçčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ ďđňďňďďëňđńîěô î ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďđňďňďíěňí řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňí Ş·ż ďéîňíđňîěňî řîęčěěďęńîęčďčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ ďđňďňďďîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďéîňíđňîěňî řîďéîěďęńîďęçčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňí ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ

ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďíěňí řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňí

5. Examine the EIGRP in action on router R4 in your pod. Simulate a WAN failure: Îďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´ đńđńđňď Îďř˝±˛ş·ąó­«ľ·ş÷ý­¸«¬Ľ±©˛ Note

In order to simulate a WAN failure, you can shut down the interface between routers R1 and R2 on router R1. There are also other ways to simulate a WAN failure.

5.2. Examine the results after the WAN failure: ÎěýĽ»ľ«ą ·° »·ą®° ×ĐóŰ×ŮÎР᫬» ŰŞ»˛¬­ Ľ»ľ«ąą·˛ą ·­ ±˛ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć Đ®±˝»­­·˛ą ·˛˝±ł·˛ą ĎËŰÎÇ °ż˝µ»¬ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďđňďňďďîňđńîě Ó ěîçěçęéîçë ó đ ěîçěçęéîçë ÍÓ ěîçěçęéîçë ó đ ěîçěçęéîçë ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ďđňďňďďîňđńîě ó Ľ± żĽŞ»®¬·­» ±«¬ Í»®·ż´đńđńđňí ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďđňďňďďîňđńîě ł»¬®·˝ îďéîěďę ó ďęëéčëę ëďěëęđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć Đ®±˝»­­·˛ą ·˛˝±ł·˛ą ËĐÜßĚŰ °ż˝µ»¬ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďđňďňďďîňđńîě Ó ěîçěçęéîçë ó ďęëéčëę ěîçěçęéîçë ÍÓ ěîçěçęéîçë ó ďęëéčëę ěîçěçęéîçë ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć Đ®±˝»­­·˛ą ·˛˝±ł·˛ą ĎËŰÎÇ °ż˝µ»¬ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďçîňďęčňďňđńîě Ó ěîçěçęéîçë ó ďęëéčëę ěîçěçęéîçë ÍÓ ěîçěçęéîçë ó ďęëéčëę ěîçěçęéîçë ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ®±«¬» ·˛­¬ż´´»Ľ ş±® ďçîňďęčňďňđ ř÷ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ďçîňďęčňďňđńîě ®±«¬·˛ą ¬żľ´» ˛±¬ «°Ľż¬»Ľ ¬¸®« ďéîňíđňîěňî ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďçîňďęčňîňđńîě Ó ěîçěçęéîçë ó ďęëéčëę ěîçěçęéîçë ÍÓ ěîçěçęéîçë ó ďęëéčëę ěîçěçęéîçë ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ®±«¬» ·˛­¬ż´´»Ľ ş±® ďçîňďęčňîňđ ř÷ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ďçîňďęčňîňđńîě ®±«¬·˛ą ¬żľ´» ˛±¬ «°Ľż¬»Ľ ¬¸®« ďéîňíđňîěňî ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďçîňďęčňíňđńîě Ó ěîçěçęéîçë ó ďęëéčëę ěîçěçęéîçë ÍÓ ěîçěçęéîçë ó ďęëéčëę ěîçěçęéîçë ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ®±«¬» ·˛­¬ż´´»Ľ ş±® ďçîňďęčňíňđ ř÷ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ďçîňďęčňíňđńîě ®±«¬·˛ą ¬żľ´» ˛±¬ «°Ľż¬»Ľ ¬¸®« ďéîňíđňîěňî ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďđňďňďďëňđńîě Ó ěîçěçęéîçë ó ďęëéčëę ěîçěçęéîçë ÍÓ ěîçěçęéîçë ó ďęëéčëę ěîçěçęéîçë ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ®±«¬» ·˛­¬ż´´»Ľ ş±® ďđňďňďďëňđ ř÷ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ďđňďňďďëňđńîě ®±«¬·˛ą ¬żľ´» ˛±¬ «°Ľż¬»Ľ ¬¸®« ďéîňíđňîěňî

42

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďéîňíđňďíňđńîě Ó ěîçěçęéîçë ó ďęëéčëę ěîçěçęéîçë ÍÓ ěîçěçęéîçë ó ďęëéčëę ěîçěçęéîçë ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ďçîňďęčňďňđńîě ó Ľ± żĽŞ»®¬·­» ±«¬ Úż­¬Ű¬¸»®˛»¬đńđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďçîňďęčňďňđńîě ł»¬®·˝ îčďîěďę ó ďęëéčëę ďďëěëęđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ďçîňďęčňîňđńîě ó Ľ± żĽŞ»®¬·­» ±«¬ Úż­¬Ű¬¸»®˛»¬đńđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďçîňďęčňîňđńîě ł»¬®·˝ îčďîěďę ó ďęëéčëę ďďëěëęđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ďçîňďęčňíňđńîě ó Ľ± żĽŞ»®¬·­» ±«¬ Úż­¬Ű¬¸»®˛»¬đńđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďçîňďęčňíňđńîě ł»¬®·˝ îčďîěďę ó ďęëéčëę ďďëěëęđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ďđňďňďďëňđńîě ó Ľ± żĽŞ»®¬·­» ±«¬ Úż­¬Ű¬¸»®˛»¬đńđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďđňďňďďëňđńîě ł»¬®·˝ îęčěěďę ó ďęëéčëę ďđîęëęđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ďéîňíđňďíňđńîě ó Ľ± żĽŞ»®¬·­» ±«¬ Úż­¬Ű¬¸»®˛»¬đńđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďéîňíđňďíňđńîě ł»¬®·˝ îďéîěďę ó ďęëéčëę ëďěëęđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďçîňďęčňďňđńîě ł»¬®·˝ îčďîěďę ó ďęëéčëę ďďëěëęđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďçîňďęčňîňđńîě ł»¬®·˝ îčďîěďę ó ďęëéčëę ďďëěëęđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďçîňďęčňíňđńîě ł»¬®·˝ îčďîěďę ó ďęëéčëę ďďëěëęđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďđňďňďďëňđńîě ł»¬®·˝ îęčěěďę ó ďęëéčëę ďđîęëęđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ďçîňďęčňďňđńîě ó Ľ± żĽŞ»®¬·­» ±«¬ Úż­¬Ű¬¸»®˛»¬đńđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďçîňďęčňďňđńîě ł»¬®·˝ îčďîěďę ó ďęëéčëę ďďëěëęđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ďçîňďęčňîňđńîě ó Ľ± żĽŞ»®¬·­» ±«¬ Úż­¬Ű¬¸»®˛»¬đńđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďçîňďęčňîňđńîě ł»¬®·˝ îčďîěďę ó ďęëéčëę ďďëěëęđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ďçîňďęčňíňđńîě ó Ľ± żĽŞ»®¬·­» ±«¬ Úż­¬Ű¬¸»®˛»¬đńđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďçîňďęčňíňđńîě ł»¬®·˝ îčďîěďę ó ďęëéčëę ďďëěëęđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ďđňďňďďëňđńîě ó Ľ± żĽŞ»®¬·­» ±«¬ Úż­¬Ű¬¸»®˛»¬đńđ ě©đĽć ×ĐóŰ×ŮÎĐřÜ»şż«´¬ó×Đó᫬·˛ąóĚżľ´»ćď÷ć ײ¬ ďđňďňďďëňđńîě ł»¬®·˝ îęčěěďę ó ďęëéčëę ďđîęëęđ

6. Configure EIGRP path selection. 6.1. Use the following example to configure the routers in this lab: Îďý ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňďíňď îëëňîëëňîëëňđ Ľ»´ż§ ďđđ Îíý ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňďíňí îëëňîëëňîëëňđ Ľ»´ż§ ďđđ Îďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´ đńđńđňď Îďř˝±˛ş·ąó­«ľ·ş÷ý˛± ­¸«¬Ľ±©˛ Note

© 2009 Cisco Systems, Inc.

Interfaces, which were disabled in order to simulate WAN failure, are now enabled.

Lab Guide

43

6.2. Verify the configuration on router R4. Îěý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňîěňě÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďçîňďęčňďňđńîěô î ­«˝˝»­­±®­ô ÚÜ ·­ îčďîěďę Ş·ż ďđňďňďíěňí řîčďîěďęńîíđđěďę÷ô Í»®·ż´đńđńđňí Ş·ż ďéîňíđňîěňî řîčďîěďęńîčđçčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďçîňďęčňîňđńîěô î ­«˝˝»­­±®­ô ÚÜ ·­ îčďîěďę Ş·ż ďđňďňďíěňí řîčďîěďęńîíđđěďę÷ô Í»®·ż´đńđńđňí Ş·ż ďéîňíđňîěňî řîčďîěďęńîčđçčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďçîňďęčňíňđńîěô î ­«˝˝»­­±®­ô ÚÜ ·­ îčďîěďę Ş·ż ďđňďňďíěňí řîčďîěďęńîíđđěďę÷ô Í»®·ż´đńđńđňí Ş·ż ďéîňíđňîěňî řîčďîěďęńîčđçčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďđňďňďďëňđńîěô î ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďđňďňďíěňí řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňí Ş·ż ďéîňíđňîěňî řîęčěěďęńîęčďčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďđňďňďďîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďéîňíđňîěňî řîďéîěďęńîďęçčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňí Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďíěňí řîďçëěëęńëďîđđ÷ô Í»®·ż´đńđńđňí Îěý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ý Ü Ü Ü Ý Ü Ü Ü

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ ďéîňíđňîěňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďéîňíđňďíňđ ĹçđńîďçëěëęĂ Ş·ż ďđňďňďíěňíô đđćđîćďčô Í»®·ż´đńđńđňí ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ ďđňďňďďëňđ ĹçđńîęčěěďęĂ Ş·ż ďéîňíđňîěňîô đđćđîćđčô Úż­¬Ű¬¸»®˛»¬đńđ ďđňďňďďîňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňîěňîô đđćđîćđčô Úż­¬Ű¬¸»®˛»¬đńđ ďđňďňďíěňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňí ďçîňďęčňďňđńîě ĹçđńîčďîěďęĂ Ş·ż ďéîňíđňîěňîô đđćđîćđčô Úż­¬Ű¬¸»®˛»¬đńđ ďçîňďęčňîňđńîě ĹçđńîčďîěďęĂ Ş·ż ďéîňíđňîěňîô đđćđîćđčô Úż­¬Ű¬¸»®˛»¬đńđ ďçîňďęčňíňđńîě ĹçđńîčďîěďęĂ Ş·ż ďéîňíđňîěňîô đđćđîćđčô Úż­¬Ű¬¸»®˛»¬đńđ

7. Examine EIGRP in action on router R4 in your pod. 7.1 Simulate a WAN failure: Îďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´ đńđńđňď Îďř˝±˛ş·ąó­«ľ·ş÷ý­¸«¬Ľ±©˛ Note

44

In order to simulate WAN failure, you can shut down the interface between routers R1 and R2 on router R1. There are also other ways to simulate a WAN failure.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

7.2 Examination after a WAN failure: Îěý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňîěňě÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďîěďę Ş·ż ďđňďňďíěňí řîčíëěëęńîíîíěëę÷ô Í»®·ż´đńđńđňí Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďîěďę Ş·ż ďđňďňďíěňí řîčíëěëęńîíîíěëę÷ô Í»®·ż´đńđńđňí Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďîěďę Ş·ż ďđňďňďíěňí řîčíëěëęńîíîíěëę÷ô Í»®·ż´đńđńđňí Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďđňďňďíěňí řîéđéěëęńîďçëěëę÷ô Í»®·ż´đńđńđňí Đ ďđňďňďďîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďéîňíđňîěňî řîďéîěďęńîďęçčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňí Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďíěňí řîďçëěëęńëďîđđ÷ô Í»®·ż´đńđńđňí Îěý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňďíňđ ĹçđńîďçëěëęĂ Ş·ż ďđňďňďíěňíô đđćđëćďčô Í»®·ż´đńđńđňí ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďđňďňďďëňđ ĹçđńîéđéěëęĂ Ş·ż ďđňďňďíěňíô đđćđđćěčô Í»®·ż´đńđńđňí Ü ďđňďňďďîňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňîěňîô đđćđëćđčô Úż­¬Ű¬¸»®˛»¬đńđ Ü ďçîňďęčňďňđńîě ĹçđńîčíëěëęĂ Ş·ż ďđňďňďíěňíô đđćđđćěčô Í»®·ż´đńđńđňí Ü ďçîňďęčňîňđńîě ĹçđńîčíëěëęĂ Ş·ż ďđňďňďíěňíô đđćđđćěčô Í»®·ż´đńđńđňí Ü ďçîňďęčňíňđńîě ĹçđńîčíëěëęĂ Ş·ż ďđňďňďíěňíô đđćđđćěčô Í»®·ż´đńđńđňí

8. Configure EIGRP optimization on the LAN interface. 8.1. Use the following example to configure the routers in this lab: Îďý ®±«¬»® »·ą®° ď °ż­­·Ş»ó·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ Îíý ®±«¬»® »·ą®° ď °ż­­·Ş»ó·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ Îďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´ đńđńđňď Îďř˝±˛ş·ąó­«ľ·ş÷ý˛± ­¸«¬Ľ±©˛ Note

Interfaces, which were disabled in order to simulate WAN failure, are now enabled.

8.2. Verify the EIGRP adjacencies and configuration the routers in your pod. Îďý­¸ ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» ď î

ďđňďňďďîňî ďđňďňďďëňë

Í»đńđńđňď Í»đńđńđňě

Îíý­¸ ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» đ

ďđňďňďíěňě

© 2009 Cisco Systems, Inc.

Í»đńđńđňí

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďď đđćđđćëđ ęč ďě đëćěéćđč ěě

ÎĚŃ

Ď Ý˛¬ ěđč đ îęě đ

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďí đđćđéćíí čěí

ÎĚŃ

Í»Ż Ň«ł ęî îě

Ď Í»Ż ݲ¬ Ň«ł ëđđđ đ ęę

Lab Guide

45

Îěý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňďíňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďíěňíô đđćďçćíěô Í»®·ż´đńđńđňí ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďđňďňďďëňđ ĹçđńîęčěěďęĂ Ş·ż ďéîňíđňîěňîô đđćđęćîěô Úż­¬Ű¬¸»®˛»¬đńđ Ü ďđňďňďďîňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňîěňîô đđćďçćěđô Úż­¬Ű¬¸»®˛»¬đńđ Ü ďçîňďęčňďňđńîě ĹçđńîčďîěďęĂ Ş·ż ďéîňíđňîěňîô đđćđęćîěô Úż­¬Ű¬¸»®˛»¬đńđ Ü ďçîňďęčňîňđńîě ĹçđńîčďîěďęĂ Ş·ż ďéîňíđňîěňîô đđćđęćîěô Úż­¬Ű¬¸»®˛»¬đńđ Ü ďçîňďęčňíňđńîě ĹçđńîčďîěďęĂ Ş·ż ďéîňíđňîěňîô đđćđęćîěô Úż­¬Ű¬¸»®˛»¬đńđ

9. Configure an EIGRP summarization. 9.1. Use the following example to configure router R1 in this lab: Îďý ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îî ·° ­«łłż®§óżĽĽ®»­­ »·ą®° ď ďçîňďęčňđňđ îëëňîëëňđňđ ë

9.2. Verify the IP routing table on the routers in your pod. Îďý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňîěňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďîňîô đđćíďćěěô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďđňďňďíěňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďîňîô đđćďčćííô Í»®·ż´đńđńđňď Ü ďçîňďęčňďňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďďëňëô đđćíďćěěô Í»®·ż´đńđńđňě Ü ďçîňďęčňîňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďďëňëô đđćíďćěěô Í»®·ż´đńđńđňě Ü ďçîňďęčňíňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďďëňëô đđćíďćěěô Í»®·ż´đńđńđňě Ü ďçîňďęčňđňđńďę ·­ ż ­«łłż®§ô đđćđîćîęô Ň«´´đ Îěý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňďíňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďíěňíô đđćíëćëěô Í»®·ż´đńđńđňí ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďđňďňďďëňđ ĹçđńîęčěěďęĂ Ş·ż ďéîňíđňîěňîô đđćîîćěíô Úż­¬Ű¬¸»®˛»¬đńđ Ü ďđňďňďďîňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňîěňîô đđćíëćëçô Úż­¬Ű¬¸»®˛»¬đńđ Ü ďçîňďęčňđňđńďę ĹçđńîčďîěďęĂ Ş·ż ďéîňíđňîěňîô đđćđęćíęô Úż­¬Ű¬¸»®˛»¬đńđ Îěý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňîěňě÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďçîňďęčňđňđńďęô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďîěďę Ş·ż ďéîňíđňîěňî řîčďîěďęńîčđçčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďéîňíđňîěňî řîęčěěďęńîęčďčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďđňďňďďîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďéîňíđňîěňî řîďéîěďęńîďęçčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňí Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďíěňí řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňí

46

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab 2-2: Configure and Verify EIGRP Circuit Emulation and Frame Relay Operations Complete this lab activity to confirm and refresh your Layer 2 and Layer 3 skills from Interconnecting Cisco Networking Devices Part 2 (ICND2).

Activity Objective In this activity, you will use the correct commands, tools, and steps to configure and verify EIGRP operation over circuit emulation and Frame Relay. After completing this activity, you will be able to meet these objectives: Configure and verify EIGRP operation over the WAN interfaces (circuit emulation and Frame Relay) Organize the tasks into an implementation plan to implement EIGRP functions Use Cisco IOS commands and applications, applied in the correct order, to the selected devices and portions of the network Verify the correct implementation and operation according to the expected performance criteria Verify the configuration and operation by using the proper show commands Document the implementation, operation, and maintenance

Information Packet The figure illustrates what you will accomplish in this activity.

Visual Objective

Visual Objective for Lab 2-2: Configure and Verify EIGRP Circuit Emulation and Frame Relay Operations

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

ROUTE v1.0—LG-8

Lab Guide

47

Implementation Policy The following list details the configuration requirements for all devices in the company network: Set proper initial configuration on all devices in your lab. Your instructor will provide the necessary information on how to set the initial configuration on all devices. Configure the EIGRP operation over WAN point-to-point interfaces toward routers BBR1 and BBR2. By deploying EIGRP toward the pod, external routers will receive IP routing information about distant networks. Additionally, you must enable EIGRP over the pointto-point WAN interface between routers R3 and R4 to announce the router’s directly connected LAN segments. The EIGRP configuration should be applied in such way that additional subnet(s) from the used IP addressing pool are automatically advertised if they are added. The EIGRP configuration should allow all the networks to be reachable from any router in the network. After a successful configuration, verify that the EIGRP adjacencies have been set up between routers R1 and BBR1, R1 and BBR2, and R3 and R4. Verify the EIGRP topology database and compare it against the EIGRP information that was put into the IP routing table on router R1. You should be able to see that all the networks acquired via EIGRP were put into the routing table and that the metric related to an individual route corresponds to the value present in the topology table. Router R1 is receiving external networks from router BBR1; that is, 192.168.x.0/24 subnets and external network 172.30.10.0/24 from router BBR2. The next configuration step will be to configure EIGRP operation over the WAN multipoint interface on router R1 toward router R2 through R4. By deploying EIGRP toward the internal routers in the pod, you will allow IP routing information exchange between all of the routers in the pod. Verify that the EIGRP adjacencies have been set up between the routers R1 and R2, R1 and R3, and R1 and R4. Verify the EIGRP topology database and compare it against the EIGRP information that was put into the IP routing table on routers R1, R3, and R4. You should be able to see that all the networks acquired via EIGRP were put into the routing table and that the metric related to an individual route corresponds to the value present in the topology table. Simulate a WAN connectivity failure between routers R3 and R4 and examine the consequences. Verify that router R3 no longer has routing information about network 172.30.24.0/24, and that routers R2 and R4 no longer have routing information about network 172.30.13.0/24. Additional configuration is required in order to adjust the EIGRP operation over the WAN multipoint interface on router R1 so that routers R3 and R4 will still have the information necessary to access each other’s LAN segments through the path via router R1, even in case of a WAN connectivity failure between routers R3 and R4. Verify that the EIGRP adjacencies between routers R1 and R2, R1 and R3, and R1 and R4 are up and running. Verify the EIGRP topology database and compare it against the EIGRP information that was put into the IP routing table on routers R1, R2, R3, and R4. You should be able to see that all the networks acquired via EIGRP were put into the routing table and that the metric related to an individual route corresponds to the value present in the topology table. Simulate a WAN connectivity failure between routers R3 and R4 and examine the consequences. Verify that router R3 still can access other networks, and that routers R2 and R4 have routing information about network 172.30.13.0/24 via the R1 WAN connection.

48

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

The last requirement is to adjust the EIGRP operation in a way that the path via R1 will be treated as a feasible successor. This adjustment will require that the delay parameter between the WAN connection and routers R3 and R4 be changed. You will also change the default EIGRP path selection to allow router R3 to install two routes to the destination network 172.30.24.0/24 while the routers are not of equal cost. Verify that the path via router R1 to network 172.30.24.0/24 is a feasible successor on router R3, whereas the path via router R4 is the primary path and is also used in the IP routing table on router R3. Verify if the configuration results changed the EIGRP path selection behavior on router R3 to treat the secondary path as a valid option for the IP routing table along with the path via router R4. Finally, verify that you have connectivity to the destination network 172.30.24.0/24 from the router R3 LAN segment.

Device Information The table provides the information specific to each switch in the network: Device Name

Role

R1

POD router

R2

POD router

R3

POD router

R4

POD router

BBR1

Backbone router

BBR2

Backbone router

© 2009 Cisco Systems, Inc.

Lab Guide

49

Command List The table describes the commands that are used in this activity. Command

Description

(no) auto-summary

Enables (disables) automatic summarization of classless subnets

(no) shutdown

Administratively disables (enables) the interface

delay tens-of-microsec

Specifies the delay on interfaces (used for routing processes)

interface type slot/port

Enters the interface configuration mode

network x.x.x.x

Enables EIGRP on interfaces belonging to a specified network

router eigrp as-number

Starts an EIGRP routing process with the given AS number

show ip eigrp neighbors

Lists the EIGRP neighbors and relevant information on EIGRP neighbor adjacencies

show ip eigrp topology [prefix] [mask]

Displays the EIGRP topology table (whole, or only per prefix/mask)

show ip route [eigrp]

Displays the whole IP routing table or EIGRP routes only

ip address ip mask secondary

Sets the secondary ip address on the interface

[no] ip split-horizon eigrp AS

Disables/enables EIGRP split-horizon on an interface

variance number

Sets the EIGRP metric variance multipler

show interfaces serial

Displays the statistics for all interfaces configured on the router

Required Resources These are the resources and equipment that are required to complete this activity: A PC that is connected to an on-site laboratory or a PC with an Internet connection if remote laboratory equipment must be accessed A terminal server that is connected to the console port of each laboratory device, if using a remote laboratory Core and access switches in your pod

50

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Job Aids These are the job aids for this lab activity: Value

Location

Blank implementation requirements list

Task 1

Blank implementation and verification plan form

Task 2

Blank verification notes form

Task 3

Alternate resources and solutions form

End of this lab

Implementation requirements hints

“Hints” section at the end of this lab

Implementation and verification plan hints

“Hints” section at the end of this lab

Solution configuration answer key (step-by step procedure)

Configuration section at the end of this lab

© 2009 Cisco Systems, Inc.

Lab Guide

51

-------- This page intentionally left blank. --------

52

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Task 1: Establish an Implementation Requirements List The first step in your configuration deployment is to establish a list of what is needed in order for you to configure each device; for example, device names, trunk encapsulation types, and so on. Use the following table, the visual objective at the beginning of this lab, the implementation policy, and the device information to create your implementation requirement list. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Device

© 2009 Cisco Systems, Inc.

Implementation Requirement

Lab Guide

53

Task 2: Create an Implementation and Verification Plan The second step in your configuration deployment is to establish a task list of the items that must be configured on each device, and in what order. Use the following table and the visual objective at the beginning of this lab to create your implementation and verification plan. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Complete

54

Device

Implementing Cisco IP Routing (ROUTE) v1.0

Order

Values and Items to Implement

Verification Method and Expected Results

© 2009 Cisco Systems, Inc.

Complete

© 2009 Cisco Systems, Inc.

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Lab Guide

55

Task 3: Implement and Verify Now that you have collected all the requirements and planned your implementation, you are ready to connect to the remote lab and implement your solution. Do not forget to save. Once your solution is implemented, you need to verify that your configuration is working and fulfills all of the requirements specified by the customer. Keep in mind that once you leave the company, a network specialist will verify your configuration. Your ability to implement the solution according to the customer specifications will determine whether you get the job or not. Use the following area to record your notes and document the verifications you conducted to ensure that your solution is complete. If you are unsure about the verification steps, use the information provided in the “Hints” section at the end of this lab. Student Notes: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ 56

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

© 2009 Cisco Systems, Inc.

Lab Guide

57

Alternate Resources and Solutions Other groups may have implemented a solution that is different from yours. These will be discussed during the debriefing period that follows this lab. Use the following space to document other possible solutions for your reference. __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ 58

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

© 2009 Cisco Systems, Inc.

Lab Guide

59

-------- This page intentionally left blank. --------

60

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Hints You are encouraged to complete the labs using your knowledge. However, this section contains a series of hints to aid your completion of the lab.

Lab 2-2 Hint Sheet: Configure and Verify EIGRP Circuit Emulation and Frame Relay Operations Implementation Requirements To facilitate the configuration of your network, the first task asks you to create an implementation requirements list. This list details the elements you need in order to develop an implementation plan. The following is an example of such a list: Device

Implementation Requirement

Hint

ALL

Define an EIGRP AS number used in the lab.

Check the AS number used in the BBR1 and BBR2 router

ALL

Define which networks are used in the lab in order to advertise all major networks used in the pod.

Visual Objective diagrams

ALL

Identify the multipoint interfaces in order to disable split horizon under the EIGRP routing process for the correct routers.

Visual Objective diagrams, Lab

R3, R4

Examine and write down the current delay value of the Serial pointto-point subinterfaces.

Visual Objective diagrams, Lab

Implementation and Verification Plan In Task 2, you will create an implementation and verification plan. Although there are several ways to set up this plan, the following tasks must be completed:: Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1–R4

1

Load initial configuration

All pod routers must be preloaded with the initial configuration for the lab.

Step 1

© 2009 Cisco Systems, Inc.

Lab Guide

61

Complete

62

Device

Order

Values and Items to Implement

R1

2

Enable the EIGRP routing protocol on router R1 on WAN interfaces Serial 0/0/0.4 and Serial0/0.4. Routers BBR1 and BBR2 are preconfigured with the EIGRP AS 1. Apply the configuration so that EIGRP automatically advertises any additional network that is added to the router.

Step 2

R3, R4

3

Enable the EIGRP routing protocol on routers R3 and R4 on the WAN interface Serial 0/0.1 and advertise LAN segments. Apply the configuration in a way that EIGRP automatically advertises any additional network that is added to the router. Apply the configuration so that you will be capable of adding an EIGRP adjacency to R1 without a major reconfiguration.

Step 3

R3

4

Add a secondary IP address 10.255.255.1/24 to the router R3 LAN interface.

Step 3

R1, R3, R4

5

Verify that the EIGRP adjacencies have been set up between routers R1 and BBR1, R1 and BBR2, and R3 and R4.

Step 3

R1, R3, R4

6

Verify the EIGRP topology database and compare it against the EIGRP information that was put into the IP routing table on router R1. You should be able to see that all of the networks acquired via EIGRP were put into a routing table and that the metric related to an individual route corresponds to the value present in the topology table. Router R1 receives external networks from router BBR1; that is, 192.168.x.0/24 subnets and external network 172.30.10.0/24 from router BBR2.

Step 3

Implementing Cisco IP Routing (ROUTE) v1.0

Verification Method and Expected Results

Step

© 2009 Cisco Systems, Inc.

Complete

Device

Order

Values and Items to Implement

R1

7

Enable the EIGRP routing protocol on the router R1 WAN interface, Serial 0/0/0.1. Use the proper EIGRP AS number to achieve seamless connectivity. Apply the configuration so that EIGRP automatically advertises any additional network that is added to the router.

R2, R3, R4

8

Enable the EIGRP routing protocol on the router R2, R3, and R4 WAN interface, Serial 0/0/0.1. Use the proper EIGRP AS number to achieve connectivity. Apply the configuration so that EIGRP automatically advertises any additional network that is added to the router.

R1–R4

9

R3, R4

10

© 2009 Cisco Systems, Inc.

Simulate a WAN connectivity failure between routers R3 and R4.

Verification Method and Expected Results

Step

Step 4

Verify that the EIGRP adjacencies have been set up between routers R1 and R2, R1 and R3, and R1 and R4.

Step 4

Verify the EIGRP topology database and compare it against the EIGRP information that was put into the IP routing table on routers R1 through R4. You should be able to see that all of the networks acquired via EIGRP were put into the routing table and that the metric related to an individual route corresponds to the value present in the topology table

Step 4

Create a WAN connectivity failure between routers R3 and R4, and examine the consequences. Verify that router R3 no longer has routing information about network 172.30.24.0/24, and that routers R2 and R4 no longer have routing information about network 172.30.13.0/24.

Step 5

Lab Guide

63

Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1

11

Change the EIGRP split-horizon behavior on the WAN multipoint interface on router R1 so that the LAN segment information for routers R2, R3, and R4 is also exchanged via that interface.

Verify that the EIGRP adjacencies between the routers R1 and R2, R1 and R3, and R1 and R4 are up and running.

Step 6

Enable the interfaces that were disabled in order to simulate the failure. R1–R4

12

Adjust the delay parameter on the WAN interfaces for connectivity between routers R3 and R4 so that R3 load balances between R1 and R4 in order to reach network 172.30.24.0/24.

Verify the EIGRP topology database and compare it against the EIGRP information that was put into the IP routing table on routers R1 through R4. You should be able to see that all the networks acquired via EIGRP were put into the routing table and that the metric related to an individual route corresponds to the value present in the topology table.

Step 7

R1, R3

13

Simulate a WAN connectivity failure between routers R1 and R3.

Create a WAN connectivity failure between routers R3 and R4 and examine the consequences. Verify that router R3 still can access other networks, and that routers R2 and R4 have routing information about network 172.30.13.0/24 via the router R1 WAN connection.

Step 8

14

Change the delay parameter on the Serial 0/0/0.3 interface on routers R3 and R4 so that the path via R1 to network 172.30.24.0/24 becomes a feasible successor, while the path via router R3 to R4 is the primary one that is installed in the routing table on router R3.

At first, the path via router R1 to the network 172.30.24.0/24 is a feasible successor on router R3, whereas the path via router R4 is the primary path and is also used in the IP routing table on router R3.

Step 9

Enable the interfaces that were disabled in order to simulate the failure.

64

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

15

Change the EIGRP path selection behavior on router R3 so that R3 selects both the primary path via router R4 and the secondary path via router R1 to the destination network 172.30.24.0/24. Both paths should be present in the routing table.

EIGRP path selection behavior is changed on router R3 to treat the secondary path as a valid option for the IP routing table along with the path via router R4.

Step 10

Verify that you have connectivity to destination network 172.30.24.0/24 from the router R3 LAN segment.

Step 10

16

Step-by-Step Procedure for Implementation and Verification 1. Load the initial configuration on all devices in your lab. 1.1. The instructor will provide guidelines for changing the initial configuration. 2. Configure EIGRP on router R1. 2.1. Use the following example to configure router R1 in this lab: Îďý ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲱 ż«¬±ó­«łłż®§

3. Configure EIGRP on routers R3 and R4 and verify the configuration. 3.1. Use the following example to configure the routers in this lab: Îíý ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§ Îěý ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§

3.2. Use the following example to configure router R3 in this lab. Îíý ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďđňîëëňîëëňď îëëňîëëňîëëňđ ­»˝±˛Ľż®§

3.3. Verify the EIGRP configuration. Îďý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» í î

ďđňďňďďđňě ďđňďňďďđňí

© 2009 Cisco Systems, Inc.

Í»đńđńđňď Í»đńđńđňď

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďí đđćđďćíç éç ďí đđćđďćěé ęç

ÎĚŃ

Ď Ý˛¬ ěéě đ ěďě đ Lab Guide

Í»Ż Ň«ł ďî ďď 65

ď đ

ďđňďňďďęňę ďđňďňďďëňë

Í»đńđńđňë Í»đńđńđňě

Îíý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» ď đ

ďđňďňďíěňě ďđňďňďďđňď

Í»đńđńđňí Í»đńđńđňď

Îěý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» ď đ

ďđňďňďďđňď ďđňďňďíěňí

Í»đńđńđňď Úż­¬Ű¬¸»®˛»¬đńđ

ďě đđćđîćďî ďđ đđćđîćďî

ëěë ęéč

íîéđ ěđęč

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďí đđćđîćďđ čí ďęď đđćđîćďç čďé

ÎĚŃ

Í»Ż Ň«ł ďď îí

ÎĚŃ

Í»Ż Ň«ł îí ďđ

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďíé đđćđîćíě ęęč ďí đđćđîćíě ęéë

đ đ

Ď Ý˛¬ ěçč đ ěçđî đ

Ď Ý˛¬ ěđđč đ ěđëđ đ

ěđ ďíď

Îďý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďđňďňďďęňď÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďđňîëëňîëëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďďđňí řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňď Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę Ş·ż ďđňďňďďëňë řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđńđňě Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę Ş·ż ďđňďňďďëňë řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđńđňě Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę Ş·ż ďđňďňďďëňë řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđńđňě Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňě Đ ďđňďňďďęňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňë Đ ďđňďňďíěňđńîěô î ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňí řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Ş·ż ďđňďňďďđňě řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Ş·ż ďđňďňďďđňě řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďďęňę řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňë Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďďđňí řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňď Îíý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňďíňí÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďđňîëëňîëëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďđňďňďďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňď Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę 66

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďęňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňí Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďíěňě řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňí ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ Îěý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňîěňě÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďđňîëëňîëëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďíěňí řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňí Đ ďđňďňďďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňď Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďęňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňí Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďíěňí řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňí Îďý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďéîňíđňîěňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďđňěô đđćđěćîéô Í»®·ż´đńđńđňď Ü ďéîňíđňďđňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďęňęô đđćđëćđďô Í»®·ż´đńđńđňë Ü ďéîňíđňďíňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďđňíô đđćđěćîéô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ Ü ďđňîëëňîëëňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďđňíô đđćđěćđëô Í»®·ż´đńđńđňď Ü ďđňďňďíěňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňěô đđćđěćîéô Í»®·ż´đńđńđňď ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňíô đđćđěćîéô Í»®·ż´đńđńđňď Ü ďçîňďęčňďňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďďëňëô đđćđëćđďô Í»®·ż´đńđńđňě Ü ďçîňďęčňîňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďďëňëô đđćđëćđďô Í»®·ż´đńđńđňě Ü ďçîňďęčňíňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďďëňëô đđćđëćđďô Í»®·ż´đńđńđňě Îíý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďéîňíđňîěňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďíěňěô đđćđëćđíô Í»®·ż´đńđńđňí Ü ďéîňíđňďđňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćđëćđíô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ Ü ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđëćđíô Í»®·ż´đńđńđňď © 2009 Cisco Systems, Inc.

Lab Guide

67

Ü Ü Ü Ü

ďđňďňďďęňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđëćđíô Í»®·ż´đńđńđňď ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđëćđíô Í»®·ż´đńđńđňď ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđëćđíô Í»®·ż´đńđńđňď ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđëćđíô Í»®·ż´đńđńđňď

Îěý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďéîňíđňďđňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćđëćîîô Í»®·ż´đńđńđňď Ü ďéîňíđňďíňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďíěňíô đđćđëćîîô Í»®·ż´đńđńđňí ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ Ü ďđňîëëňîëëňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďíěňíô đđćđëćđđô Í»®·ż´đńđńđňí Ü ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđëćîîô Í»®·ż´đńđńđňď Ü ďđňďňďďęňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđëćîîô Í»®·ż´đńđńđňď Ü ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđëćîîô Í»®·ż´đńđńđňď Ü ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđëćîîô Í»®·ż´đńđńđňď Ü ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđëćîîô Í»®·ż´đńđńđňď

4. Configure EIGRP on routers R3 and R4 and verify the configuration. 4.1. Use the following example to configure the routers in this lab: Îîý ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§ Note

Routers R1, R3, and R4 do not require any additional configuration because EIGRP is already enabled on those routers.

4.2. Verify the EIGRP configuration: Îďý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» í ě î ď đ

ďđňďňďďđňî ďđňďňďďęňę ďđňďňďďđňí ďđňďňďďđňě ďđňďňďďëňë

Í»đńđńđňď Í»đńđńđňë Í»đńđńđňď Í»đńđńđňď Í»đńđńđňě

Îîý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» ď đ

ďéîňíđňîěňě ďđňďňďďđňď

Úżđńđ Í»đńđńđňď

Îíý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» đ ď

ďđňďňďíěňě ďđňďňďďđňď

Í»đńđńđňí Í»đńđńđňď

Îěý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» đ î ď

68

ďđňďňďíěňí ďđňďňďďđňď ďéîňíđňîěňî

Implementing Cisco IP Routing (ROUTE) v1.0

Í»đńđńđňí Í»đńđńđňď Úżđńđ

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďî đđćîďćëë îěč ďí đđćîîćëé çí ďě đđćîíćđđ íéç ďď đđćîíćđđ čđ ďî đđćîíćđđ ëç

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďď đđćđđćíď é ďëď đđćđđćíë ďđđď

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďî đđćđíćďé ďđíě ďíé đđćîčćîď ěč

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďě đđćđëćďđ ďďę ďíë đđćíđćďí ďčë ďî đđćíęćďě ď

ÎĚŃ

Ď Ý˛¬ đ đ đ đ đ

Í»Ż Ň«ł íí ç îé íč íë

ÎĚŃ

Ď Ý˛¬ îđđ đ ëđđđ đ

Í»Ż Ň«ł ďé îë

ÎĚŃ

Í»Ż Ň«ł ěę čđ

ÎĚŃ

Í»Ż Ň«ł íî čď íę

ďěčč ëëč îîéě ěčđ íëě

Ď Ý˛¬ ëđđđ đ îčč đ

Ď Ý˛¬ ęçę đ ďďďđ đ îđđ đ

© 2009 Cisco Systems, Inc.

Îďý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďđňďňďďęňď÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďđňîëëňîëëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďďđňí řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňď Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę Ş·ż ďđňďňďďëňë řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđńđňě Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę Ş·ż ďđňďňďďëňë řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđńđňě Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę Ş·ż ďđňďňďďëňë řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđńđňě Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňě Đ ďđňďňďďęňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňë Đ ďđňďňďíěňđńîěô î ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňí řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Ş·ż ďđňďňďďđňě řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Ş·ż ďđňďňďďđňî řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňîěňđńîěô î ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Ş·ż ďđňďňďďđňî řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňď Ş·ż ďđňďňďďđňě řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďďęňę řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňë Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďďđňí řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňď Îîý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňîěňî÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďđňîëëňîëëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéěçéę Ş·ż ďéîňíđňîěňě řîďéěçéęńîďéîěďę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďđňďňďďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňď Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďęňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďéîňíđňîěňě řîďéîěďęńîďęçčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéěçéę Ş·ż ďéîňíđňîěňě řîďéěçéęńîďéîěďę÷ô Úż­¬Ű¬¸»®˛»¬đńđ © 2009 Cisco Systems, Inc.

Lab Guide

69

Îíý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňďíňí÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďđňîëëňîëëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďđňďňďďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňď Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďęňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňí Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďíěňě řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňí ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ Îěý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňîěňě÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďđňîëëňîëëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďíěňí řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňí Đ ďđňďňďďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňď Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďęňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňí Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďíěňí řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňí Îďý­¸±© ·° ®±«¬» »·ą®° 70

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ü Ü Ü Ü Ü Ü Ü Ü Ü

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ ďéîňíđňďđňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćđíćíđô Í»®·ż´đńđńđňď ďéîňíđňďíňđ ĹçđńîďéěçéęĂ Ş·ż ďéîňíđňîěňěô đđćđíćíđô Úż­¬Ű¬¸»®˛»¬đńđ ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ ďđňîëëňîëëňđ ĹçđńîďéěçéęĂ Ş·ż ďéîňíđňîěňěô đđćđíćíđô Úż­¬Ű¬¸»®˛»¬đńđ ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđíćíđô Í»®·ż´đńđńđňď ďđňďňďďęňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđíćíđô Í»®·ż´đńđńđňď ďđňďňďíěňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňîěňěô đđćđíćíđô Úż­¬Ű¬¸»®˛»¬đńđ ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđíćíđô Í»®·ż´đńđńđňď ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđíćíđô Í»®·ż´đńđńđňď ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđíćíđô Í»®·ż´đńđńđňď

Îîý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďéîňíđňďđňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćîěćëčô Í»®·ż´đńđńđňď Ü ďéîňíđňďíňđ ĹçđńîďéěçéęĂ Ş·ż ďéîňíđňîěňěô đđćđđćëčô Úż­¬Ű¬¸»®˛»¬đńđ ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ Ü ďđňîëëňîëëňđ ĹçđńîďéěçéęĂ Ş·ż ďéîňíđňîěňěô đđćđđćëčô Úż­¬Ű¬¸»®˛»¬đńđ Ü ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćîěćëčô Í»®·ż´đńđńđňď Ü ďđňďňďďęňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćîěćëčô Í»®·ż´đńđńđňď Ü ďđňďňďíěňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňîěňěô đđćďçćđíô Úż­¬Ű¬¸»®˛»¬đńđ Ü ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćîěćëčô Í»®·ż´đńđńđňď Ü ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćîěćëčô Í»®·ż´đńđńđňď Ü ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćîěćëčô Í»®·ż´đńđńđňď Îíý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďéîňíđňîěňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďíěňěô đđćđíćîđô Í»®·ż´đńđńđňí Ü ďéîňíđňďđňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćđíćîđô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ Ü ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđíćîđô Í»®·ż´đńđńđňď Ü ďđňďňďďęňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđíćîđô Í»®·ż´đńđńđňď Ü ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđíćîđô Í»®·ż´đńđńđňď Ü ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđíćîđô Í»®·ż´đńđńđňď Ü ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđíćîđô Í»®·ż´đńđńđňď Îěý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďéîňíđňďđňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćđëćďîô Í»®·ż´đńđńđňď Ü ďéîňíđňďíňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďíěňíô đđćđëćďîô Í»®·ż´đńđńđňí ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ Ü ďđňîëëňîëëňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďíěňíô đđćđëćďîô Í»®·ż´đńđńđňí Ü ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđëćďîô Í»®·ż´đńđńđňď Ü ďđňďňďďęňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđëćďîô Í»®·ż´đńđńđňď Ü ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđëćďîô Í»®·ż´đńđńđňď Ü ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđëćďîô Í»®·ż´đńđńđňď Ü ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđëćďîô Í»®·ż´đńđńđňď

5. Simulate a WAN failure and verify routers R2, R3, and R4 after the WAN failure. 5.1. To simulate a WAN failure, run these commands: Îíř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»đńđńđňí Îíř˝±˛ş·ąó­«ľ·ş÷ý­¸«¬Ľ±©˛ Note

In order to simulate WAN failure, you can shut down the interface on router R3. There are also other ways to simulate a WAN failure.

5.2. Verification after a WAN failure: Îíý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» ď

ďđňďňďďđňď

© 2009 Cisco Systems, Inc.

Í»đńđńđňď

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďęď đđćíîćđč ěč

ÎĚŃ

Ď Í»Ż ݲ¬ Ň«ł îčč đ čí Lab Guide

71

Îîý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňďđňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćíîćëëô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ Ü ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćíîćëëô Í»®·ż´đńđńđňď Ü ďđňďňďďęňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćíîćëëô Í»®·ż´đńđńđňď Ü ďđňďňďíěňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňîěňěô đđćîéćđđô Úż­¬Ű¬¸»®˛»¬đńđ Ü ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćíîćëëô Í»®·ż´đńđńđňď Ü ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćíîćëëô Í»®·ż´đńđńđňď Ü ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćíîćëëô Í»®·ż´đńđńđňď Îíý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňďđňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćđéćđčô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ Ü ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđéćđčô Í»®·ż´đńđńđňď Ü ďđňďňďďęňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđéćđčô Í»®·ż´đńđńđňď Ü ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđéćđčô Í»®·ż´đńđńđňď Ü ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđéćđčô Í»®·ż´đńđńđňď Ü ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđéćđčô Í»®·ż´đńđńđňď Îěý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňďđňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćđčćďčô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ Ü ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđčćďčô Í»®·ż´đńđńđňď Ü ďđňďňďďęňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđčćďčô Í»®·ż´đńđńđňď Ü ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđčćďčô Í»®·ż´đńđńđňď Ü ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđčćďčô Í»®·ż´đńđńđňď Ü ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđčćďčô Í»®·ż´đńđńđňď

6. Configure EIGRP on router R1 and verify the configuration. 6.1. Use the following example to configure router R1 in this lab: Îďý ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ ˛± ·° ­°´·¬ó¸±®·¦±˛ »·ą®° ď Îíř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´ đńđńđňí Îíř˝±˛ş·ąó­«ľ·ş÷ý˛± ­¸«¬Ľ±©˛ Note

Interfaces, which were disabled in order to simulate WAN failure, are now enabled.

6.2. Verify the EIGRP configuration: Îďý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» í ě î ď đ

ďđňďňďďđňî ďđňďňďďęňę ďđňďňďďđňí ďđňďňďďđňě ďđňďňďďëňë

Í»đńđńđňď Í»đńđńđňë Í»đńđńđňď Í»đńđńđňď Í»đńđńđňě

Îîý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» ď

72

ďđňďňďďđňď

Implementing Cisco IP Routing (ROUTE) v1.0

Í»đńđńđňď

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďî đđćěďćěç ďčě ďď đđćěîćëď çí ďě đđćěîćëí îéę ďí đđćěîćëí çđ ďí đđćěîćëě ëç

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďéď đďćďíćďç íç

ÎĚŃ ďďđě ëëč ďęëę ëěđ íëě

Ď Ý˛¬ đ đ đ đ đ

Í»Ż Ň«ł ěí ç íę ëí íë

ÎĚŃ

Ď Í»Ż ݲ¬ Ň«ł îíě đ ďëé

© 2009 Cisco Systems, Inc.

đ

ďéîňíđňîěňě

Úżđńđ

Îíý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» ď đ

ďđňďňďďđňď ďđňďňďíěňě

Í»đńđńđňď Í»đńđńđňí

Îěý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» đ î ď

ďđňďňďíěňí ďđňďňďďđňď ďéîňíđňîěňî

Í»đńđńđňí Í»đńđńđňď Úżđńđ

ďí đďćîđćîđ

ď

íđđ

đ

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďéç đđćďíćěë ďíč ďě đđćďíćěę ëď

ÎĚŃ

Ď Ý˛¬ čîč đ íđę đ

Í»Ż Ň«ł ďëé ďîč

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďî đđćďëćëč íéę ďęí đďćďéćîî ěđ ďě đďćîíćîí ď

ÎĚŃ

Í»Ż Ň«ł čé ďëé éç

Ď Ý˛¬ îîëę đ îěđ đ îđđ đ

ďîę

7. Configure EIGRP on routers R3 and R4 and verify the configuration. 7.1. Use the following example to configure routers R3 and R4 in this lab: Îíý ·˛¬»®şż˝» Í»®·ż´đńđńđňí °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îě ·° żĽĽ®»­­ ďđňďňďíěňí îëëňîëëňîëëňđ Ľ»´ż§ ěđđđ Îěý ·˛¬»®şż˝» Í»®·ż´đńđńđňí °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îí ·° żĽĽ®»­­ ďđňďňďíěňě îëëňîëëňîëëňđ Ľ»´ż§ ěđđđ

7.2. Verify the EIGRP configuration: Îďý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďéîňíđňîěňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďđňěô đđćďđćëéô Í»®·ż´đńđńđňď ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďđňîô đđćďđćëéô Í»®·ż´đńđńđňď Ü ďéîňíđňďđňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďęňęô đďćďíćíęô Í»®·ż´đńđńđňë Ü ďéîňíđňďíňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďđňíô đđćďđćëíô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ Ü ďđňîëëňîëëňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďđňíô đđćďđćëíô Í»®·ż´đńđńđňď Ü ďđňďňďíěňđ ĹçđńíďçíčëęĂ Ş·ż ďđňďňďďđňěô đđćđéćíđô Í»®·ż´đńđńđňď ĹçđńíďçíčëęĂ Ş·ż ďđňďňďďđňíô đđćđéćíđô Í»®·ż´đńđńđňď Ü ďçîňďęčňďňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďďëňëô đďćďíćíçô Í»®·ż´đńđńđňě Ü ďçîňďęčňîňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďďëňëô đďćďíćíçô Í»®·ż´đńđńđňě Ü ďçîňďęčňíňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďďëňëô đďćďíćíçô Í»®·ż´đńđńđňě Îîý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďéîňíđňďđňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đďćďíćîíô Í»®·ż´đńđńđňď Ü ďéîňíđňďíňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćđčćđéô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ Ü ďđňîëëňîëëňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćđčćđéô Í»®·ż´đńđńđňď Ü ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đďćďíćîíô Í»®·ż´đńđńđňď Ü ďđňďňďďęňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đďćďíćîíô Í»®·ż´đńđńđňď Ü ďđňďňďíěňđ ĹçđńîęčěěďęĂ Ş·ż ďéîňíđňîěňěô đđćđčćďéô Úż­¬Ű¬¸»®˛»¬đńđ Ü ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đďćďíćîíô Í»®·ż´đńđńđňď Ü ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đďćďíćîíô Í»®·ż´đńđńđňď Ü ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đďćďíćîíô Í»®·ż´đńđńđňď Îíý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďéîňíđňîěňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďíěňěô đđćđčćëéô Í»®·ż´đńđńđňí ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćđčćëéô Í»®·ż´đńđńđňď © 2009 Cisco Systems, Inc.

Lab Guide

73

Ü Ü Ü Ü Ü Ü

ďéîňíđňďđňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćđčćëéô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđčćëéô Í»®·ż´đńđńđňď ďđňďňďďęňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđčćëéô Í»®·ż´đńđńđňď ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđčćëéô Í»®·ż´đńđńđňď ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđčćëéô Í»®·ż´đńđńđňď ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđčćëéô Í»®·ż´đńđńđňď

Îěý­¸ ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďéîňíđňďđňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćďďćđëô Í»®·ż´đńđńđňď Ü ďéîňíđňďíňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďíěňíô đđćďďćđëô Í»®·ż´đńđńđňí ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćďďćđëô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ Ü ďđňîëëňîëëňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďíěňíô đđćďďćđëô Í»®·ż´đńđńđňí ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćďďćđëô Í»®·ż´đńđńđňď Ü ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćďďćđëô Í»®·ż´đńđńđňď Ü ďđňďňďďęňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćďďćđëô Í»®·ż´đńđńđňď Ü ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćďďćđëô Í»®·ż´đńđńđňď Ü ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćďďćđëô Í»®·ż´đńđńđňď Ü ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćďďćđëô Í»®·ż´đńđńđňď Îďý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďđňďňďďęňď÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďđňîëëňîëëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďďđňí řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňď Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę Ş·ż ďđňďňďďëňë řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđńđňě Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę Ş·ż ďđňďňďďëňë řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđńđňě Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę Ş·ż ďđňďňďďëňë řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđńđňě Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňě Đ ďđňďňďďęňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňë Đ ďđňďňďíěňđńîěô î ­«˝˝»­­±®­ô ÚÜ ·­ íďçíčëę Ş·ż ďđňďňďďđňí říďçíčëęńîęčďčëę÷ô Í»®·ż´đńđńđňď Ş·ż ďđňďňďďđňě říďçíčëęńîęčďčëę÷ô Í»®·ż´đńđńđňď Ş·ż ďđňďňďďđňî říďçęěďęńîęčěěďę÷ô Í»®·ż´đńđńđňďô ­»®˛± îď ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďéîňíđňîěňđńîěô î ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďďđňî řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňď Ş·ż ďđňďňďďđňě řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďďęňę řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňë Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďďđňí řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňď Îîý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňîěňî÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďđňîëëňîëëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéěçéę Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňď 74

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďęňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďéîňíđňîěňě řîęčěěďęńîęčďčëę÷ô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéěçéę Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď Îíý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňďíňí÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďđňîëëňîëëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďđňďňďďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňď Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďęňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňí Đ ďéîňíđňîěňđńîěô î ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďíěňě řîęčěěďęńîčďęđ÷ô Í»®·ż´đńđńđňí ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ Îěý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňîěňě÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďđňîëëňîëëňđńîěô î ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďíěňí řîęčěěďęńîčďęđ÷ô Í»®·ż´đńđńđňí Đ ďđňďňďďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňď Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď © 2009 Cisco Systems, Inc.

Lab Guide

75

Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďęňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňí Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňďíňđńîěô î ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďíěňí řîęčěěďęńîčďęđ÷ô Í»®·ż´đńđńđňí

8. Simulate a WAN failure and verify routers R2, R3, and R4 after the WAN failure. 8.1. To simulate a WAN failure, run these commands: Îíř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»đńđńđňí Îíř˝±˛ş·ąó­«ľ·ş÷ý­¸«¬Ľ±©˛ Note

In order to simulate a WAN failure, you can shut down the interface on router R3. There are also other ways to simulate a WAN failure.

8.2. Verification after a WAN failure: Îíý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» ď

ďđňďňďďđňď

Í»đńđńđňď

Îěý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» î ď

ďđňďňďďđňď ďéîňíđňîěňî

Í»đńđńđňď Úżđńđ

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďěę đđćďčćëç ďďé

ÎĚŃ

Ď Í»Ż ݲ¬ Ň«ł éđî đ ďëč

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďěę đďćîďćďç ěđ ďď đďćîéćîđ ď

ÎĚŃ

Ď Ý˛¬ îěđ đ îđđ đ

Í»Ż Ň«ł ďëé éç

Îíý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďéîňíđňîěňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćđďćđěô Í»®·ż´đńđńđňď Ü ďéîňíđňďđňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćďěćďďô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ Ü ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćďěćďďô Í»®·ż´đńđńđňď Ü ďđňďňďďęňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćďěćďďô Í»®·ż´đńđńđňď Ü ďđňďňďíěňđ ĹçđńíéđëčëęĂ Ş·ż ďđňďňďďđňďô đđćđďćđěô Í»®·ż´đńđńđňď Ü ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćďěćďďô Í»®·ż´đńđńđňď Ü ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćďěćďďô Í»®·ż´đńđńđňď Ü ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćďěćďďô Í»®·ż´đńđńđňď Îěý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďéîňíđňďđňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćďëćđďô Í»®·ż´đńđńđňď Ü ďéîňíđňďíňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćđďćěéô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ Ü ďđňîëëňîëëňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćđďćěéô Í»®·ż´đńđńđňď Ü ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćďëćđďô Í»®·ż´đńđńđňď Ü ďđňďňďďęňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćďëćđďô Í»®·ż´đńđńđňď 76

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ü Ü Ü

ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćďëćđďô Í»®·ż´đńđńđňď ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćďëćđďô Í»®·ż´đńđńđňď ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćďëćđďô Í»®·ż´đńđńđňď

Îíý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňďíňí÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďđňîëëňîëëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ Đ ďđňďňďďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňď Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďęňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ íéđëčëę Ş·ż ďđňďňďďđňď říéđëčëęńíďçíčëę÷ô Í»®·ż´đńđńđňďô ­»®˛± îí Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ Îěý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďéîňíđňîěňě÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďđňîëëňîëëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňď Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňîňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďçîňďęčňíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčđçčëę Ş·ż ďđňďňďďđňď řîčđçčëęńîîçéčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďëňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďďęňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ďđňďňďďđňď řîęčďčëęńîďęçčëę÷ô Í»®·ż´đńđńđňď Đ ďđňďňďíěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčďčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňí Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę © 2009 Cisco Systems, Inc.

Lab Guide

77

Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď

9. Configure EIGRP on routers R3 and R4 and verify the configuration. 9.1. Use the following example to configure routers R3 and R4 in this lab: Îíý ·˛¬»®şż˝» Í»®·ż´đńđńđňí °±·˛¬ó¬±ó°±·˛¬ Ľ»´ż§ íđđđ Îěý ·˛¬»®şż˝» Í»®·ż´đńđńđňí °±·˛¬ó¬±ó°±·˛¬ Ľ»´ż§ íđđđ Îíř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´ đńđńđňí Îíř˝±˛ş·ąó­«ľ·ş÷ý˛± ­¸«¬Ľ±©˛ Note

Interfaces, which were disabled in order to simulate WAN failure, are now enabled.

9.2. Verify the EIGRP configuration: Îíý­¸±© ·° »·ą®° ¬±°±´±ą§ ¤ ľ»ą·˛ ďéîňíđňîěňđ Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îěîčěďę Ş·ż ďđňďňďíěňě řîěîčěďęńîčďęđ÷ô Í»®·ż´đńđńđňí Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îęčěěďę Ş·ż ďđňďňďďđňď řîęčěěďęńîďéîěďę÷ô Í»®·ż´đńđńđňď Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđ Ş·ż ݱ˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ Îíý­¸±© ·° »·ą®° ¬±°±´±ą§ ďéîňíđňîěňđ îëëňîëëňîëëňđ ×ĐóŰ×ŮÎĐ řßÍ ď÷ć ̱°±´±ą§ »˛¬®§ ş±® ďéîňíđňîěňđńîě ͬż¬» ·­ Đż­­·Ş»ô Ď«»®§ ±®·ą·˛ ş´żą ·­ ďô ď Í«˝˝»­­±®ř­÷ô ÚÜ ·­ îěîčěďę ᫬·˛ą Ü»­˝®·°¬±® Ţ´±˝µ­ć ďđňďňďíěňě řÍ»®·ż´đńđńđňí÷ô ş®±ł ďđňďňďíěňěô Í»˛Ľ ş´żą ·­ đ¨đ ݱł°±­·¬» ł»¬®·˝ ·­ řîěîčěďęńîčďęđ÷ô ᫬» ·­ ײ¬»®˛ż´ Ę»˝¬±® ł»¬®·˝ć Ó·˛·ł«ł ľż˛Ľ©·Ľ¬¸ ·­ ďëěě Őľ·¬ ̱¬ż´ Ľ»´ż§ ·­ íđďđđ ł·˝®±­»˝±˛Ľ­ λ´·żľ·´·¬§ ·­ îëëńîëë Ô±żĽ ·­ ďńîëë Ó·˛·ł«ł ÓĚË ·­ ďëđđ ر° ˝±«˛¬ ·­ ď ďđňďňďďđňď řÍ»®·ż´đńđńđňď÷ô ş®±ł ďđňďňďďđňďô Í»˛Ľ ş´żą ·­ đ¨đ ݱł°±­·¬» ł»¬®·˝ ·­ řîęčěěďęńîďéîěďę÷ô ᫬» ·­ ײ¬»®˛ż´ Ę»˝¬±® ł»¬®·˝ć Ó·˛·ł«ł ľż˛Ľ©·Ľ¬¸ ·­ ďëěě Őľ·¬ ̱¬ż´ Ľ»´ż§ ·­ ěđďđđ ł·˝®±­»˝±˛Ľ­ λ´·żľ·´·¬§ ·­ îëëńîëë Ô±żĽ ·­ ďńîëë Ó·˛·ł«ł ÓĚË ·­ ďëđđ ر° ˝±«˛¬ ·­ î Îíý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďéîňíđňîěňđ ĹçđńîěîčěďęĂ Ş·ż ďđňďňďíěňěô đđćîđćěďô Í»®·ż´đńđńđňí Ü ďéîňíđňďđňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćîđćěďô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ Ü ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćîđćěďô Í»®·ż´đńđńđňď Ü ďđňďňďďęňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćîđćěďô Í»®·ż´đńđńđňď Ü ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćîđćěďô Í»®·ż´đńđńđňď Ü ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćîđćěďô Í»®·ż´đńđńđňď Ü ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćîđćěďô Í»®·ż´đńđńđňď

78

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

10. Configure EIGRP on router R3 and verify the configuration. 10.1.

Use the following example to configure router R3 in this lab: Îíý ®±«¬»® »·ą®° ď Şż®·ż˛˝» î

10.2.

Verify the EIGRP configuration: Îíý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ü ďéîňíđňîěňđ ĹçđńîěîčěďęĂ Ş·ż ďđňďňďíěňěô đđćđďćëěô Í»®·ż´đńđńđňí ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćđďćëěô Í»®·ż´đńđńđňď Ü ďéîňíđňďđňđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďďđňďô đđćđďćëěô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ Ü ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđďćëěô Í»®·ż´đńđńđňď Ü ďđňďňďďęňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďđňďô đđćđďćëěô Í»®·ż´đńđńđňď Ü ďçîňďęčňďňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđďćëěô Í»®·ż´đńđńđňď Ü ďçîňďęčňîňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđďćëěô Í»®·ż´đńđńđňď Ü ďçîňďęčňíňđńîě ĹçđńîčđçčëęĂ Ş·ż ďđňďňďďđňďô đđćđďćëěô Í»®·ż´đńđńđňď Îíý°·˛ą ďéîňíđňîěňî ­±«®˝» ďéîňíđňďíňí ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňíđňîěňîô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć Đż˝µ»¬ ­»˛¬ ©·¬¸ ż ­±«®˝» żĽĽ®»­­ ±ş ďéîňíđňďíňí ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ëęńëęńęđ ł­

© 2009 Cisco Systems, Inc.

Lab Guide

79

Lab 2-3: Configure and Verify EIGRP Authentication Complete this lab activity to practice what you learned in the related module.

Activity Objective In this activity, you will use the correct commands, tools, and steps to configure and verify EIGRP authentication. After completing this activity, you will be able to meet these objectives: Select the required tools and commands to configure basic EIGRP authentication Organize the tasks into an implementation plan to implement EIGRP authentication Implement the identified EIGRP solution to configure basic EIGRP authentication in the provided network according to the implementation plan, using Cisco IOS commands and applications in the correct order to the selected devices and portions of the network Write a verification and test plan to verify the correct implementation and operation according to expected performance criteria Verify the implementation according to the verification plan, using the appropriate show and debug commands and applications to verify the correct operation, and document implementation, operation, and maintenance

Information Packet The figure illustrates what you will accomplish in this activity.

Visual Objective

Visual Objective for Lab 2-3: Configure and Verify EIGRP Authentication

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

80

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v1.0—LG-9

© 2009 Cisco Systems, Inc.

Implementation Policy The following list details the configuration requirements for all devices in the company network: First, you will configure EIGRP authentication over the LAN interfaces between the routers in your pod. The authentication should use a safe password exchange. Passwords that will be used to authenticate the routers should never expire. Once the authentication configuration on the LAN interfaces is done, you must verify if the proper key chain is defined on each pod’s routers, and that the correct keys are used, which never expire. A successful configuration results in a neighbor relationship being formed over the LAN interfaces, and you can see all of the networks advertised by the EIGRP routing process in the IP routing table of every router in the pod. After a successful LAN authentication, you will configure EIGRP authentication over the WAN interfaces between the routers in your pod. The authentication should use a safe password exchange. Passwords that are used to authenticate the routers should never expire. Once the authentication configuration on the WAN interfaces is done, you must verify if the proper key chain is defined on each pod router and that correct keys are used, which never expire. A successful configuration results in a neighbor relationship being formed over the WAN interfaces, and you can see all of the networks advertised by the EIGRP routing process in the IP routing table of every router in the pod.

Device Information The table provides the information specific to each switch in the network: Device Name

Role

R1

POD router

R2

POD router

R3

POD router

R4

POD router

© 2009 Cisco Systems, Inc.

Lab Guide

81

Command List The table describes the commands that are used in this activity. Command

Description

interface type slot/port

Enters the interface configuration mode

show ip eigrp neighbors

Lists EIGRP neighbors and relevant information on EIGRP neighbor adjacencies

show ip route [eigrp]

Displays the whole IP routing table or EIGRP routes only

key-chain name

Configures the key chain

key id

Define a key

key-string string

Defines a shared secret for a key

accept-lifetime from till

Defines an acceptable lifetime for a key

send-lifetime from till

Defines the lifetime that is advertised for a key

ip authentication mode eigrp AS md5

Enables EIGRP MD5 authentication

ip authentication key-chain eigrp AS key-chain

Sets the key chain used for the EIGRP authentication

show key-chain

Shows the configured key chains and parameters

show ip eigrp interfaces detail interface

Shows EIGRP configuration details for an interface

Required Resources These are the resources and equipment that are required to complete this activity: A PC that is connected to an on-site laboratory or a PC with an Internet connection if remote laboratory equipment must be accessed A terminal server that is connected to the console port of each laboratory device, if using a remote laboratory Core and access switches in your pod

Job Aids These are the job aids for this lab activity:

82

Value

Location

Blank implementation requirements list

Task 1

Blank implementation and verification plan form

Task 2

Blank verification notes form

Task 3

Alternate resources and solutions form

End of this lab

Implementation requirements hints

“Hints” section at the end of this lab

Implementation and verification plan hints

“Hints” section at the end of this lab

Solution configuration answer key (step-by-step procedure)

Configuration section at the end of this lab

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Task 1: Establish an Implementation Requirements List The first step in your configuration deployment is to establish a list of what is needed in order for you to configure each device; for example, device names, trunk encapsulation types, and so on. Use the following table, the visual objective at the beginning of this lab, the implementation policy, and the device information to create your implementation requirements list. If you are unsure, use the information provided in the “Hints” section at the end of this lab. Device

© 2009 Cisco Systems, Inc.

Implementation Requirement

Lab Guide

83

Task 2: Create an Implementation and Verification Plan The second step in your configuration deployment is to establish a task list of the items that must be configured on each device, and in what order. Use the following table and the visual objective at the beginning of this lab to create your implementation and verification plan. If you are unsure, use the information provided in the “Hints” section at the end of this lab. Complete

84

Device

Order

Implementing Cisco IP Routing (ROUTE) v1.0

Values and Items to Implement

Verification Method and Expected Results

© 2009 Cisco Systems, Inc.

Complete

© 2009 Cisco Systems, Inc.

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Lab Guide

85

Task 3: Implement and Verify Now that you have collected all of the requirements and planned your implementation, you are ready to connect to the remote lab and implement your solution. Do not forget to save. Once your solution is implemented, you need to verify that your configuration is working and fulfills all of the requirements specified by the customer. Keep in mind that once you leave the company, a network specialist will verify your configuration. Your ability to implement the solution according to the customer specifications will determine whether you get the job or not. Use the following area to record your notes and document the verifications you conducted to ensure that your solution is complete. If you are unsure of the verification steps, use the information provided in the “Hints” section at the end of this lab.

Student Notes: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ 86

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

© 2009 Cisco Systems, Inc.

Lab Guide

87

Alternate Resources and Solutions Other groups may have implemented a solution that is different from yours. These will be discussed during the debriefing period that will follow this lab. Use the following space to document other possible solutions for your reference. __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ 88

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

© 2009 Cisco Systems, Inc.

Lab Guide

89

------- This page intentionally left blank. --------

90

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Hints You are encouraged to complete the labs using your knowledge. However, this section contains a series of hints to aid your completion of the lab.

Lab 2-3 Hint Sheet: Configure and Verify EIGRP Authentication Implementation Requirements To facilitate the configuration of your network, the first task asks you to create an implementation requirements list. This list details the elements you need in order to develop an implementation plan. The following is an example of such a list: Device

Implementation Requirement

Hint

ALL

Define the keys used for authentication and their validity

Implementation Policy

Implementation and Verification Plan In Task 2, you need to create an implementation plan. There are, of course, several possible ways to accomplish this task. The following steps need to be completed: Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1–R4

1

Load initial configuration

All pod routers must be preloaded with the initial configuration for the lab.

Step 1

R1–R4

2

Configure a key chain on the routers that will be used for authentication on the LAN segments. Keys in the key chain used for authentication must never expire.

Verify that the proper key chain is defined on each of the pod routers by inspecting the key chain configuration.

Step 2

R1–R4

3

Enable secure authentication on the LAN segments between routers and use the defined key chain for authentication.

Verify that secure authentication is configured on each of the pod routers by inspecting the configuration on each router.

Step 3

© 2009 Cisco Systems, Inc.

Lab Guide

91

Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1–R4

4

Verify that the EIGRP adjacencies have been set up between the pod routers after you have applied the EIGRP authentication.

Verify that the routers form the neighbor relationship through LAN interfaces.

Step 4

R1–R4

5

Verify that the anticipated EIGRP routes are present in the routing tables of all routers.

Verify the routing tables on every router for the EIGRP routes for involved networks.

Step 5

R1–R4

6

Verify that the anticipated EIGRP routers have authentication enabled on the LAN interfaces.

Verify the EIGRP details on every LAN interface involved in the authentication process.

Step 6

R1–R4

7

Configure another key chain on the routers that will be used for authentication on the WAN segments. Keys in the key chain used for authentication must never expire.

Verify that the proper key chain is defined on each of the pod routers by inspecting the key chain configuration.

Step 7

R1–R4

8

Enable secure authentication on the WAN segments between routers and use the defined key chain for authentication.

Verify that secure authentication is configured on each of the pod routers by inspecting the configuration on each router.

Step 8

R1–R4

9

Verify that the EIGRP adjacencies have been set up between the pod routers after you have applied the EIGRP authentication.

Verify that routers form the neighbor relationship through LAN interfaces.

Step 9

R1–R4

10

Verify that the anticipated EIGRP routes are present in the routing tables of all routers.

Verify the routing table on every router for the EIGRP routes for involved networks.

Step 10

R1–R4

11

Verify that anticipated EIGRP routers have authentication enabled on LAN interfaces.

Verify EIGRP details on every LAN interface involved in the authentication process.

Step 11

Step-by-Step Procedure for Implementation and Verification 1. Load the initial configuration on all devices in your lab. 1.1. The instructor will provide guidelines for changing the initial configuration. 2. Configure a key chain and keys used for authentication. 2.1. Use the following example to configure the routers in this lab: Îďý µ»§ ˝¸ż·˛ ÔßŢîíóÔßŇ µ»§ ď 92

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

µ»§ó­¬®·˛ą Ý·­˝±ÔßŇ ż˝˝»°¬ó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» ­»˛Ľó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» Note

The same commands are also used on routers R2, R3, and R4

2.2. Verify that the proper key chain is defined on each of the pod routers. Îďý­¸±© µ»§ ˝¸ż·˛ Ő»§ó˝¸ż·˛ ÔßŢîíóÔßŇć µ»§ ď óó ¬»¨¬ ŤÝ·­˝±ÔßŇţ ż˝˝»°¬ ´·ş»¬·ł» řđěćđđćđđ Öż˛ ď îđđç÷ ó řż´©ż§­ Şż´·Ľ÷ ĹŞż´·Ľ ˛±©Ă ­»˛Ľ ´·ş»¬·ł» řđěćđđćđđ Öż˛ ď îđđç÷ ó řż´©ż§­ Şż´·Ľ÷ ĹŞż´·Ľ ˛±©Ă

Note

The same command must also be used on routers R2, R3, and R4, and the command output will be the same as well.

3. Enable secure authentication on the LAN segments. 3.1. Use the following example to configure the routers in this lab: Îďý ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ď łĽë ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ď ÔßŢîíóÔßŇ Note

The same commands are used also on routers R2, R3, and R4.

3.2. Verify that secure authentication is configured and the correct key chain is used. Îďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ 䱫¬°«¬ ±ł·¬¬»Ľâ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ď łĽë ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ď ÔßŢîíóÔßŇ ä±«¬°«¬ ±ł·¬¬»Ľâ Note

The same command must also be used on routers R2, R3, and R4, and the command output will be the same as well.

4. Verify that the EIGRP adjacencies have been set up and that each router forms a neighbor relationship over the LAN interface. Îďý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» î

ďéîňíđňďíňí

© 2009 Cisco Systems, Inc.

Úżđńđ

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďď đđćđěćíě čďî

ÎĚŃ

Ď Í»Ż ݲ¬ Ň«ł ěčéî đ ďě Lab Guide

93

đ

ďđňďňďďîňî

Í»đńđńđňď

Îîý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» đ ď

ďđňďňďďîňď ďéîňíđňîěňě

Í»đńđńđňď Úżđńđ

Îíý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» đ ď

ďđňďňďíěňě ďéîňíđňďíňď

Í»đńđńđňí Úżđńđ

Îěý ­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» ď đ

ďđňďňďíěňí ďéîňíđňîěňî

Í»đńđńđňí Úżđńđ

ďď đđćđěćěé

ëěđ

íîěđ

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďě đđćđîćďě ęę ďđ đđćđëćďé ď

ÎĚŃ

Ď Ý˛¬ íçę đ îđđ đ

Í»Ż Ň«ł îç îé

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďď đđćđîćëđ ďđíé ďď đđćđęćíí ď

ÎĚŃ

Í»Ż Ň«ł îč íď

ÎĚŃ

Í»Ż Ň«ł îç îç

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďî đđćđíćíđ ęé ďđ đđćđęćěí ď

đ

Ď Ý˛¬ ëđđđ đ îđđ đ

Ď Ý˛¬ ěđî đ îđđ đ

ďé

5. Verify that the LAN and WAN segments are advertised on all routers. Îďý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü

ďéîňíđňîěňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďîňîô đđćđďćíďô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­

Ü

ďđňďňďíěňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňďíňíô đđćđďćěďô Úż­¬Ű¬¸»®˛»¬đńđ

Îîý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňďíňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďîňďô đđćđîćđëô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďđňďňďíěňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňîěňěô đđćđîćďëô Úż­¬Ű¬¸»®˛»¬đńđ Îíý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňîěňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďíěňěô đđćđîćëđô Í»®·ż´đńđńđňí ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďđňďňďďîňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňďíňďô đđćđîćëđô Úż­¬Ű¬¸»®˛»¬đńđ Îěý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňďíňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďíěňíô đđćđíćíďô Í»®·ż´đńđńđňí ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďđňďňďďîňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňîěňîô đđćđíćíďô Úż­¬Ű¬¸»®˛»¬đńđ

6. Verify that detailed EIGRP interface information shows you that secure LAN authentication is enabled on the LAN interfaces on all routers in your lab. Îďý­¸±© ·° »·ą®° ·˛¬»®şż˝»­ Ľ»¬ż·´ şż­¬Ű¬¸»®˛»¬ đńđ

94

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

×ĐóŰ×ŮÎĐ ·˛¬»®şż˝»­ ş±® °®±˝»­­ ď Čł·¬ Ď«»«» Ó»ż˛ Đż˝·˛ą Ě·ł» ײ¬»®şż˝» Đ»»®­ ˲ńλ´·żľ´» ÍÎĚĚ Ë˛ńλ´·żľ´» Úżđńđ ď đńđ ď đńď Ř»´´± ·˛¬»®Şż´ ·­ ë ­»˝ Ň»¨¬ ¨ł·¬ ­»®·ż´ 䲱˛»â ˲ń®»´·żľ´» ł˝ż­¬­ć đńďî ˲ń®»´·żľ´» «˝ż­¬­ć ďíńďđ Ó˝ż­¬ »¨˝»°¬·±˛­ć î ÝÎ °ż˝µ»¬­ć î ßÝŐ­ ­«°°®»­­»Ľć ď 묮ż˛­ł·­­·±˛­ ­»˛¬ć ď Ń«¬ó±şó­»Ż«»˛˝» ®˝ŞĽć đ ß«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» ·­ łĽëô µ»§ó˝¸ż·˛ ·­ ţÔßŢîíóÔßŇţ Ë­» ł«´¬·˝ż­¬

Ó«´¬·˝ż­¬ Ú´±© Ě·ł»® ëđ

Đ»˛Ľ·˛ą ᫬»­ đ

Îîý­¸±© ·° »·ą®° ·˛¬»®şż˝»­ Ľ»¬ż·´ şż­¬Ű¬¸»®˛»¬ đńđ ×ĐóŰ×ŮÎĐ ·˛¬»®şż˝»­ ş±® °®±˝»­­ ď Čł·¬ Ď«»«» Ó»ż˛ Đż˝·˛ą Ě·ł» ײ¬»®şż˝» Đ»»®­ ˲ńλ´·żľ´» ÍÎĚĚ Ë˛ńλ´·żľ´» Úżđńđ ď đńđ ď đńď Ř»´´± ·˛¬»®Şż´ ·­ ë ­»˝ Ň»¨¬ ¨ł·¬ ­»®·ż´ 䲱˛»â ˲ń®»´·żľ´» ł˝ż­¬­ć đńďî ˲ń®»´·żľ´» «˝ż­¬­ć ďíńďđ Ó˝ż­¬ »¨˝»°¬·±˛­ć î ÝÎ °ż˝µ»¬­ć î ßÝŐ­ ­«°°®»­­»Ľć ď 묮ż˛­ł·­­·±˛­ ­»˛¬ć ď Ń«¬ó±şó­»Ż«»˛˝» ®˝ŞĽć đ ß«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» ·­ łĽëô µ»§ó˝¸ż·˛ ·­ ţÔßŢîíóÔßŇţ Ë­» ł«´¬·˝ż­¬

Ó«´¬·˝ż­¬ Ú´±© Ě·ł»® ëđ

Đ»˛Ľ·˛ą ᫬»­ đ

Ó«´¬·˝ż­¬ Ú´±© Ě·ł»® ëđ

Đ»˛Ľ·˛ą ᫬»­ đ

Ó«´¬·˝ż­¬ Ú´±© Ě·ł»® ëđ

Đ»˛Ľ·˛ą ᫬»­ đ

Îíý­¸±© ·° »·ą®° ·˛¬»®şż˝»­ Ľ»¬ż·´ şż­¬Ű¬¸»®˛»¬ đńđ ×ĐóŰ×ŮÎĐ ·˛¬»®şż˝»­ ş±® °®±˝»­­ ď Čł·¬ Ď«»«» Ó»ż˛ Đż˝·˛ą Ě·ł» ײ¬»®şż˝» Đ»»®­ ˲ńλ´·żľ´» ÍÎĚĚ Ë˛ńλ´·żľ´» Úżđńđ ď đńđ ď đńď Ř»´´± ·˛¬»®Şż´ ·­ ë ­»˝ Ň»¨¬ ¨ł·¬ ­»®·ż´ 䲱˛»â ˲ń®»´·żľ´» ł˝ż­¬­ć đńďî ˲ń®»´·żľ´» «˝ż­¬­ć ďíńďđ Ó˝ż­¬ »¨˝»°¬·±˛­ć î ÝÎ °ż˝µ»¬­ć î ßÝŐ­ ­«°°®»­­»Ľć ď 묮ż˛­ł·­­·±˛­ ­»˛¬ć ď Ń«¬ó±şó­»Ż«»˛˝» ®˝ŞĽć đ ß«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» ·­ łĽëô µ»§ó˝¸ż·˛ ·­ ţÔßŢîíóÔßŇţ Ë­» ł«´¬·˝ż­¬ Îěý­¸±© ·° »·ą®° ·˛¬»®şż˝»­ Ľ»¬ż·´ şż­¬Ű¬¸»®˛»¬ đńđ ×ĐóŰ×ŮÎĐ ·˛¬»®şż˝»­ ş±® °®±˝»­­ ď Čł·¬ Ď«»«» Ó»ż˛ Đż˝·˛ą Ě·ł» ײ¬»®şż˝» Đ»»®­ ˲ńλ´·żľ´» ÍÎĚĚ Ë˛ńλ´·żľ´» Úżđńđ ď đńđ ď đńď Ř»´´± ·˛¬»®Şż´ ·­ ë ­»˝ Ň»¨¬ ¨ł·¬ ­»®·ż´ 䲱˛»â ˲ń®»´·żľ´» ł˝ż­¬­ć đńďî ˲ń®»´·żľ´» «˝ż­¬­ć ďíńďđ Ó˝ż­¬ »¨˝»°¬·±˛­ć î ÝÎ °ż˝µ»¬­ć î ßÝŐ­ ­«°°®»­­»Ľć ď 묮ż˛­ł·­­·±˛­ ­»˛¬ć ď Ń«¬ó±şó­»Ż«»˛˝» ®˝ŞĽć đ ß«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» ·­ łĽëô µ»§ó˝¸ż·˛ ·­ ţÔßŢîíóÔßŇţ Ë­» ł«´¬·˝ż­¬

© 2009 Cisco Systems, Inc.

Lab Guide

95

7. Configure a key chain and keys used for authentication. 7.1. Use the following example to configure the routers in this lab: Îďý µ»§ ˝¸ż·˛ ÔßŢîíóÉßŇ µ»§ ď µ»§ó­¬®·˛ą Ý·­˝±ÉßŇ ż˝˝»°¬ó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» ­»˛Ľó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» Note

The same commands are also used on routers R2, R3, and R4.

7.2. Verify that the proper key chain is defined on each of the pod routers. Îďý­¸±© µ»§ ˝¸ż·˛ Ő»§ó˝¸ż·˛ ÔßŢîíóÔßŇć µ»§ ď óó ¬»¨¬ ţÝ·­˝±ÔßŇţ ż˝˝»°¬ ´·ş»¬·ł» řđěćđđćđđ ËĚÝ Öż˛ ­»˛Ľ ´·ş»¬·ł» řđěćđđćđđ ËĚÝ Öż˛ ď Ő»§ó˝¸ż·˛ ÔßŢîíóÉßŇć µ»§ ď óó ¬»¨¬ ţÝ·­˝±ÉßŇţ ż˝˝»°¬ ´·ş»¬·ł» řđěćđđćđđ ËĚÝ Öż˛ ­»˛Ľ ´·ş»¬·ł» řđěćđđćđđ ËĚÝ Öż˛ ď

Note

ď îđđç÷ ó ř·˛ş·˛·¬»÷ ĹŞż´·Ľ ˛±©Ă îđđç÷ ó ř·˛ş·˛·¬»÷ ĹŞż´·Ľ ˛±©Ă

ď îđđç÷ ó ř·˛ş·˛·¬»÷ ĹŞż´·Ľ ˛±©Ă îđđç÷ ó ř·˛ş·˛·¬»÷ ĹŞż´·Ľ ˛±©Ă

The same command must also be used on routers R2, R3, and R4, and the command output will be the same as well.

8. Enable secure authentication on WAN segments. 8.1. Use the following example to configure the routers in this lab: Îďý ·˛¬»®şż˝» ­»®·ż´đńđńđňď ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ď łĽë ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ď ÔßŢîíóÉßŇ

Note

The same commands used on router R1 are also used on router R2.

Îíý ·˛¬»®şż˝» ­»®·ż´đńđńđňí ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ď łĽë ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ď ÔßŢîíóÉßŇ

Note

The same commands used on router R3 are also used on router R4.

8.2. Verify that secure authentication is configured and that the correct key chain is used. Îďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ 䱫¬°«¬ ±ł·¬¬»Ľâ ·˛¬»®şż˝» ­»®·ż´đńđńđňď 96

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ď łĽë ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ď ÔßŢîíóÉßŇ ä±«¬°«¬ ±ł·¬¬»Ľâ Note

The same command used on router R1 must also be used on router R2, and the command output will be the same as well.

Îíý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ 䱫¬°«¬ ±ł·¬¬»Ľâ ·˛¬»®şż˝» ­»®·ż´đńđńđňí ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ď łĽë ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ď ÔßŢîíóÉßŇ ä±«¬°«¬ ±ł·¬¬»Ľâ Note

The same command used on router R3 must also be used on router R4, and the command output will be the same as well.

9. Verify that the EIGRP adjacencies have been set up and that each router forms a neighbor relationship over the LAN interface. Îďý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» đ ď

ďđňďňďďîňî ďéîňíđňďíňí

Í»đńđńđňď Úżđńđ

Îîý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» đ ď

ďđňďňďďîňď ďéîňíđňîěňě

Í»đńđńđňď Úżđńđ

Îíý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» đ ď

ďđňďňďíěňě ďéîňíđňďíňď

Í»đńđńđňí Úżđńđ

Îěý ­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» ď đ

ďđňďňďíěňí ďéîňíđňîěňî

Í»đńđńđňí Úżđńđ

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďî đđćđďćěđ ďđđě ďđ đđćđëćďí ď

ÎĚŃ

Í»Ż Ň«ł îč íđ

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďě đđćđîćďě ęę ďđ đđćđëćďé ď

ÎĚŃ

Ď Ý˛¬ íçę đ îđđ đ

Í»Ż Ň«ł îç îé

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďď đđćđîćëđ ďđíé ďď đđćđęćíí ď

ÎĚŃ

Í»Ż Ň«ł îč íď

ÎĚŃ

Í»Ż Ň«ł îç îç

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďî đđćđíćíđ ęé ďđ đđćđęćěí ď

Ď Ý˛¬ ëđđđ đ îđđ đ

Ď Ý˛¬ ëđđđ đ îđđ đ

Ď Ý˛¬ ěđî đ îđđ đ

10. Verify that LAN and WAN segments are advertised on all routers. Îďý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňîěňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďîňîô đđćđďćíďô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďđňďňďíěňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňďíňíô đđćđďćěďô Úż­¬Ű¬¸»®˛»¬đńđ Îîý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňďíňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďîňďô đđćđîćđëô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďđňďňďíěňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňîěňěô đđćđîćďëô Úż­¬Ű¬¸»®˛»¬đńđ Îíý­¸±© ·° ®±«¬» »·ą®° © 2009 Cisco Systems, Inc.

Lab Guide

97

Ü Ü

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ ďéîňíđňîěňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďíěňěô đđćđîćëđô Í»®·ż´đńđńđňí ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ ďđňďňďďîňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňďíňďô đđćđîćëđô Úż­¬Ű¬¸»®˛»¬đńđ

Îěý­¸±© ·° ®±«¬» »·ą®° ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďéîňíđňďíňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďíěňíô đđćđíćíďô Í»®·ż´đńđńđňí ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ü ďđňďňďďîňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňîěňîô đđćđíćíďô Úż­¬Ű¬¸»®˛»¬đńđ

11. Verify that detailed EIGRP interface information shows that secure LAN authentication is enabled on the LAN interfaces on all routers in your lab. Îďý­¸±© ·° »·ą®° ·˛¬»®şż˝»­ Ľ»¬ż·´ ×ĐóŰ×ŮÎĐ ·˛¬»®şż˝»­ ş±® °®±˝»­­ ď Čł·¬ Ď«»«» Ó»ż˛ Đż˝·˛ą Ě·ł» ײ¬»®şż˝» Đ»»®­ ˲ńλ´·żľ´» ÍÎĚĚ Ë˛ńλ´·żľ´» Í»đńđńđňď ď đńđ ęé đńďë Ř»´´± ·˛¬»®Şż´ ·­ ë ­»˝ Ň»¨¬ ¨ł·¬ ­»®·ż´ 䲱˛»â ˲ń®»´·żľ´» ł˝ż­¬­ć đńđ ˲ń®»´·żľ´» «˝ż­¬­ć çńîî Ó˝ż­¬ »¨˝»°¬·±˛­ć đ ÝÎ °ż˝µ»¬­ć đ ßÝŐ­ ­«°°®»­­»Ľć č 묮ż˛­ł·­­·±˛­ ­»˛¬ć í Ń«¬ó±şó­»Ż«»˛˝» ®˝ŞĽć đ ß«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» ·­ łĽëô µ»§ó˝¸ż·˛ ·­ ţÔßŢîíóÉßŇţ Ë­» «˛·˝ż­¬ Úżđńđ ď đńđ î đńď Ř»´´± ·˛¬»®Şż´ ·­ ë ­»˝ Ň»¨¬ ¨ł·¬ ­»®·ż´ 䲱˛»â ˲ń®»´·żľ´» ł˝ż­¬­ć đńďđ ˲ń®»´·żľ´» «˝ż­¬­ć ďîńďđ Ó˝ż­¬ »¨˝»°¬·±˛­ć î ÝÎ °ż˝µ»¬­ć î ßÝŐ­ ­«°°®»­­»Ľć ď 묮ż˛­ł·­­·±˛­ ­»˛¬ć ď Ń«¬ó±şó­»Ż«»˛˝» ®˝ŞĽć đ ß«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» ·­ łĽëô µ»§ó˝¸ż·˛ ·­ ţÔßŢîíóÔßŇţ Ë­» ł«´¬·˝ż­¬

Ó«´¬·˝ż­¬ Ú´±© Ě·ł»® íďç

ëđ

Đ»˛Ľ·˛ą ᫬»­ đ

đ

Îîý­¸±© ·° »·ą®° ·˛¬»®şż˝»­ Ľ»¬ż·´ ×ĐóŰ×ŮÎĐ ·˛¬»®şż˝»­ ş±® °®±˝»­­ ď Čł·¬ Ď«»«» Ó»ż˛ Đż˝·˛ą Ě·ł» ײ¬»®şż˝» Đ»»®­ ˲ńλ´·żľ´» ÍÎĚĚ Ë˛ńλ´·żľ´» Í»đńđńđňď ď đńđ ęé đńďë Ř»´´± ·˛¬»®Şż´ ·­ ë ­»˝ Ň»¨¬ ¨ł·¬ ­»®·ż´ 䲱˛»â ˲ń®»´·żľ´» ł˝ż­¬­ć đńđ ˲ń®»´·żľ´» «˝ż­¬­ć çńîî Ó˝ż­¬ »¨˝»°¬·±˛­ć đ ÝÎ °ż˝µ»¬­ć đ ßÝŐ­ ­«°°®»­­»Ľć č 묮ż˛­ł·­­·±˛­ ­»˛¬ć í Ń«¬ó±şó­»Ż«»˛˝» ®˝ŞĽć đ ß«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» ·­ łĽëô µ»§ó˝¸ż·˛ ·­ ţÔßŢîíóÉßŇţ Ë­» «˛·˝ż­¬ Úżđńđ ď đńđ î đńď Ř»´´± ·˛¬»®Şż´ ·­ ë ­»˝ Ň»¨¬ ¨ł·¬ ­»®·ż´ 䲱˛»â ˲ń®»´·żľ´» ł˝ż­¬­ć đńďđ ˲ń®»´·żľ´» «˝ż­¬­ć ďîńďđ Ó˝ż­¬ »¨˝»°¬·±˛­ć î ÝÎ °ż˝µ»¬­ć î ßÝŐ­ ­«°°®»­­»Ľć ď 묮ż˛­ł·­­·±˛­ ­»˛¬ć ď Ń«¬ó±şó­»Ż«»˛˝» ®˝ŞĽć đ ß«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» ·­ łĽëô µ»§ó˝¸ż·˛ ·­ ţÔßŢîíóÔßŇţ Ë­» ł«´¬·˝ż­¬

Ó«´¬·˝ż­¬ Ú´±© Ě·ł»® íďç

ëđ

Đ»˛Ľ·˛ą ᫬»­ đ

đ

Îíý­¸±© ·° »·ą®° ·˛¬»®şż˝»­ Ľ»¬ż·´ ×ĐóŰ×ŮÎĐ ·˛¬»®şż˝»­ ş±® °®±˝»­­ ď Čł·¬ Ď«»«» Ó»ż˛ Đż˝·˛ą Ě·ł» ײ¬»®şż˝» Đ»»®­ ˲ńλ´·żľ´» ÍÎĚĚ Ë˛ńλ´·żľ´» Í»đńđńđňí ď đńđ ęé đńďë Ř»´´± ·˛¬»®Şż´ ·­ ë ­»˝ Ň»¨¬ ¨ł·¬ ­»®·ż´ 䲱˛»â ˲ń®»´·żľ´» ł˝ż­¬­ć đńđ ˲ń®»´·żľ´» «˝ż­¬­ć çńîî 98

Implementing Cisco IP Routing (ROUTE) v1.0

Ó«´¬·˝ż­¬ Ú´±© Ě·ł»® íďç

Đ»˛Ľ·˛ą ᫬»­ đ

© 2009 Cisco Systems, Inc.

Ó˝ż­¬ »¨˝»°¬·±˛­ć đ ÝÎ °ż˝µ»¬­ć đ ßÝŐ­ ­«°°®»­­»Ľć č 묮ż˛­ł·­­·±˛­ ­»˛¬ć í Ń«¬ó±şó­»Ż«»˛˝» ®˝ŞĽć đ ß«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» ·­ łĽëô µ»§ó˝¸ż·˛ ·­ ţÔßŢîíóÉßŇţ Ë­» «˛·˝ż­¬ Úżđńđ ď đńđ î đńď Ř»´´± ·˛¬»®Şż´ ·­ ë ­»˝ Ň»¨¬ ¨ł·¬ ­»®·ż´ 䲱˛»â ˲ń®»´·żľ´» ł˝ż­¬­ć đńďđ ˲ń®»´·żľ´» «˝ż­¬­ć ďîńďđ Ó˝ż­¬ »¨˝»°¬·±˛­ć î ÝÎ °ż˝µ»¬­ć î ßÝŐ­ ­«°°®»­­»Ľć ď 묮ż˛­ł·­­·±˛­ ­»˛¬ć ď Ń«¬ó±şó­»Ż«»˛˝» ®˝ŞĽć đ ß«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» ·­ łĽëô µ»§ó˝¸ż·˛ ·­ ţÔßŢîíóÔßŇţ Ë­» ł«´¬·˝ż­¬

ëđ

đ

Îěý­¸±© ·° »·ą®° ·˛¬»®şż˝»­ Ľ»¬ż·´ ×ĐóŰ×ŮÎĐ ·˛¬»®şż˝»­ ş±® °®±˝»­­ ď Čł·¬ Ď«»«» Ó»ż˛ Đż˝·˛ą Ě·ł» ײ¬»®şż˝» Đ»»®­ ˲ńλ´·żľ´» ÍÎĚĚ Ë˛ńλ´·żľ´» Í»đńđńđňí ď đńđ ęé đńďë Ř»´´± ·˛¬»®Şż´ ·­ ë ­»˝ Ň»¨¬ ¨ł·¬ ­»®·ż´ 䲱˛»â ˲ń®»´·żľ´» ł˝ż­¬­ć đńđ ˲ń®»´·żľ´» «˝ż­¬­ć çńîî Ó˝ż­¬ »¨˝»°¬·±˛­ć đ ÝÎ °ż˝µ»¬­ć đ ßÝŐ­ ­«°°®»­­»Ľć č 묮ż˛­ł·­­·±˛­ ­»˛¬ć í Ń«¬ó±şó­»Ż«»˛˝» ®˝ŞĽć đ ß«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» ·­ łĽëô µ»§ó˝¸ż·˛ ·­ ţÔßŢîíóÉßŇţ Ë­» «˛·˝ż­¬ Úżđńđ ď đńđ î đńď Ř»´´± ·˛¬»®Şż´ ·­ ë ­»˝ Ň»¨¬ ¨ł·¬ ­»®·ż´ 䲱˛»â ˲ń®»´·żľ´» ł˝ż­¬­ć đńďđ ˲ń®»´·żľ´» «˝ż­¬­ć ďîńďđ Ó˝ż­¬ »¨˝»°¬·±˛­ć î ÝÎ °ż˝µ»¬­ć î ßÝŐ­ ­«°°®»­­»Ľć ď 묮ż˛­ł·­­·±˛­ ­»˛¬ć ď Ń«¬ó±şó­»Ż«»˛˝» ®˝ŞĽć đ ß«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» ·­ łĽëô µ»§ó˝¸ż·˛ ·­ ţÔßŢîíóÔßŇţ Ë­» ł«´¬·˝ż­¬

© 2009 Cisco Systems, Inc.

Ó«´¬·˝ż­¬ Ú´±© Ě·ł»® íďç

Đ»˛Ľ·˛ą ᫬»­ đ

ëđ

đ

Lab Guide

99

Lab 2-4: Implement and Troubleshoot EIGRP Operations Complete this lab activity to practice what you learned in the related module.

Activity Objective In this activity, you must analyze, locate, and fix EIGRP-related problems in your network that are caused by a misconfiguration or poor design. After this activity, you will be able to meet these objectives: Develop a work plan to troubleshoot configuration and security issues related to the EIGRP Isolate the causes of the problems Correct all of the identified EIGRP issues Document and report the troubleshooting findings and recommendations

Information Packet The figure illustrates what you will accomplish in this activity.

Visual Objective

Visual Objective for Lab 2-4: Verify EIGRP Operations

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v 1. 0—LG-10

Troubleshooting Policy The following lists details troubleshooting requirements and issues for all devices in the company network:

100

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Trouble Ticket A: EIGRP Adjacency Issues You were absent for a short period of time, and during your absence a junior engineer substituted foryou. There was a demand for additional IP subnet deployment on a LAN segment between routers R2 and R4. The junior engineer deployed additional IP subnets, but the connectivity beyond that segment to the new IP subnet is not available. You have been asked to examine and correct the issue, so that the new IP subnet will be accessible from any part of the network. There is also an issue with the EIGRP adjacency to router BBR1. During your absence, the junior engineer was asked to improve routing security related to router BBR1. An adjacency with router BBR1 cannot be formed and you are asked to correct that problem. Tthe engineer was also asked to optimize EIGRP operation. He applied a configuration that improved the metric calculation on R4, which broke the connectivity from that router. In addition to that, he tried to optimize the routing tables on the routers and implemented summarization to accomplish this goal, which is not working as expected. You are asked to address this issue too. Trouble Ticket B: Limited Connectivity Your assistant reports that there is no connectivity to the LAN subnets attached to routers R2 and R4 from a newly deployed spoke location where router R3 was deployed. Router R3 has limited connectivity—all other IP subnets in the network are accessible via router R1. You must locate and correct the issue with EIGRP routing. Instructions Together with your team members, create a troubleshooting and verification plan to divide the work. Assign each team member appropriate roles and coordinate device access among the team members. Together, work on Trouble Tickets A and B to resolve the issues. Document your progress in the “Troubleshooting Log” provided below as part of Task 2 in order to help facilitate efficient communication within the team and to have an overview of your troubleshooting process for reference during the lab debriefing discussions.

Device Information The table provides the information specific to each switch in the network: Device Name

Role

R1

POD router

R2

POD router

R3

POD router

R4

POD router

BBR1

Backbone router

BBR2

Backbone router

© 2009 Cisco Systems, Inc.

Lab Guide

101

Command List The table describes the commands that are used in this activity. Command

Description

interface type slot/port

Enters the interface configuration mode

show ip eigrp neighbors

Lists the EIGRP neighbors and relevant information on EIGRP neighbor adjacencies

show ip route [eigrp]

Displays the entire IP routing table or EIGRP routes only

key-chain name

Configures a key chain

key id

Defines a key

key-string string

Defines a shared secret for a key

accept-lifetime from till

Defines a key's acceptable lifetime

send-lifetime from till

Defines a key's lifetime that is advertised

show key-chain

Shows the configured key chains and parameters

show ip eigrp interfaces detail interface

Shows the EIGRP configuration details for an interface

debug eigrp packets

Enables EIGRP packet debugging

debug ip eigrp neighbor AS ip address

Enables EIGRP debugging per neighbor

[no] metric weights 0 k1 k2 k3 k4 k5

Sets EIGRP K values

ip address ip mask [secondary]

Sets the IP address on an interface

Required Resources These are the resources and equipment that are required to complete this activity: A PC that is connected to an on-site laboratory or a PC with an Internet connection if remote laboratory equipment must be accessed A terminal server that is connected to the console port of each laboratory device, if using a remote laboratory Core and access switches in your pod

102

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Job Aids These are the job aids for this lab activity: Value

Location

Blank troubleshoouting and verification plan

Task 1

Blank troubleshooting log

Task 2

Troubleshooting and verification plan hints

“Hints” section at the end of this lab

Trouble Ticket Hints List

“Hints” section at the end of this lab

Configuration sample after trouble tickets

Configuration section at the end of this lab

© 2009 Cisco Systems, Inc.

Lab Guide

103

Task 1: Create an Troubleshooting and Verification Plan The first step is to establish a troubleshooting and verification plan. This is a task list of the items that must be checked and corrected in order to establish working conditions in the EIGRP network. Use the following table and the visual objective at the beginning of this lab to create your troubleshooting and verification plan. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Complete

104

Device

Order

Implementing Cisco IP Routing (ROUTE) v1.0

Values and Items to Implement

Verification Method and Expected Results

© 2009 Cisco Systems, Inc.

Complete

© 2009 Cisco Systems, Inc.

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Lab Guide

105

Task 2: Troubleshooting Log Use this log to document your actions and results during the troubleshooting process. Trouble Ticket

106

Actions and Results

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Trouble Ticket

© 2009 Cisco Systems, Inc.

Actions and Results

Lab Guide

107

Hints You are encouraged to complete the labs using your knowledge. However, this section contains a series of hints to aid your completion of the lab.

Lab 2-4 Hint Sheet: Implement and Troubleshoot EIGRP Operations Troubleshooting and Verification Plan In Task 1, you will create a troubleshooting and verification plan. Although there are several ways to set up this plan, the following tasks must be completed:: Complete

108

Device

Order

Values and Items to Implement

Verification Method and Expected Results

R1–R4

1

Load initial configuration.

All pod routers must be preloaded with the initial configuration for the LAB.

R1–R4

2

On all the routers, examine the EIGRP adjacency tables and write down the information.

Use the show ip eigrp neighbor command in order to see if neighbors are adjacent.

R1, R2, R4

3

Observe the messages that appear on the routers because they might indicate that there is some kind of IP address mismatch and that the metric calculation is not in sync on all the routers.

Verify the IP address configuration on all routers and establish a working configuration by using the show running-configuration command.

R2, R4

4

Verify how a secondary IP subnet is applied on the LAN segment.

Verify the secondary IP address configuration on the LAN segments by issuing the show running-configuration command.

R1

5

Verify IP connectivity toward router BBR1. Enable EIGRP packet debugging and debugging for neighbor BBR1 to explore the problem toward that neighbor.

Debug the EIGRP packets in order to identify the source of the connectivity issues. Use the following commands: debug eigrp packets and debug eigrp neighbors.

R1–R4

6

Examine the IP routing tables on the routers in your pod and verify whether specific IP subnet information is present.

Identify the presence of EIGRP routes inside the IP routing table using the show ip route eigrp command. Verify if all IP subnets from the pod are present.

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

R1, R3

7

Verify the neighbor relationship between routers R1 and R3.

Use the show ip eigrp neighbors command to verify if the neighbor relationship is established between the routers.

R1, R3

8

Examine the IP routing table and the EIGRP topology table on routers R1 and R3.

Use the show ip route eigrp and show ip eigrp topology commands to verify that the IP routing table reflecting the correct EIGRP topology and costs.

R3

9

Enable EIGRP debugging for the neighbor and observe what information is advertised to router R3.

Use the debug eigrp neighbors command in order to see what information is advertised to router R3.

Trouble Ticket Hint List On all routers, examine the EIGRP adjacency tables and write down the information. Observe the messages that appear on routers R1, R2, and R4—they indicate that there is some kind of IP address mismatch and that the metric calculation is not in sync with all routers. Verify how a secondary IP subnet is applied on the LAN segment on routers R2 and R4. Verify IP connectivity toward router BBR1. Enable EIGRP packet debugging and debugging for neighbor BBR1 to explore the problem toward that neighbor. Examine the IP routing tables on routers in your pod and determine whether specific IP subnet information is present. Verify the neighbor relationship between routers R1 and R3. Examine the IP routing table and the EIGRP topology table on routers R1 and R3. Enable EIGRP debugging for the neighbor and observe what information is advertised to router R3. Configuration Sample After Trouble Tickets Ѳ Îďć ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ ˛± ·° ­°´·¬ó¸±®·¦±˛ »·ą®° ď ˙ ˛± µ»§ ˝¸ż·˛ ÔßŢîě ˙ µ»§ ˝¸ż·˛ ÔßŢîě µ»§ ď µ»§ó­¬®·˛ą Ý·­˝± ż˝˝»°¬ó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđí ·˛ş·˛·¬» ­»˛Ľó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđí ·˛ş·˛·¬»

© 2009 Cisco Systems, Inc.

Lab Guide

109

Ѳ Îîć ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňî îëëňîëëňîëëňđ ·° żĽĽ®»­­ ďéîňíđňěîňî îëëňîëëňîëëňđ ­»˝±˛Ľż®§ Ѳ Îěć ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňě îëëňîëëňîëëňđ ·° żĽĽ®»­­ ďéîňíđňěîňě îëëňîëëňîëëňđ ­»˝±˛Ľż®§ ˙ ®±«¬»® »·ą®° ď ˛± ł»¬®·˝ ©»·ą¸¬­ đ ď ď ď ď ď

110

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

------- The page intentionally left blank. --------

© 2009 Cisco Systems, Inc.

Lab Guide

111

Lab 3-1: Configure and Verify OSPF to Improve Routing Performance Complete this lab activity to practice what you learned in the related module.

Activity Objective In this activity, you will use the correct commands, tools, and steps to configure and verify OSPF implementation. After completing this activity, you will be able to meet these objectives: Configure and verify OSPF operation over LAN interfaces Configure and verify OSPF operation over Frame Relay using a point-to-multipoint OSPF network type Configure and verify OSPF operation over Frame Relay using a point-to-point network type Select the required tools and commands to configure OSPF operations Make a list of configuration and implementation steps Write a verification and test plan to verify the proper implementation and operation according to the expected performance criteria Verify the configuration and operation by using the proper show and debug commands

Information Packet The figure illustrates what you will accomplish in this activity.

Visual Objective

Visual Objective for Lab 3-3: Configure and Verify OSPF Route Summarization for Interarea and External Routes

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

112

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v 1. 0—LG-13

© 2009 Cisco Systems, Inc.

Implementation Policy The following list details the configuration requirements for all devices in the company network: In this task you, will configure OSPF on each of the routers in your network—routers R1, R2, R3, and R4. OSPF will be used to exchange routing information in order to achieve IP connectivity over the LAN interfaces. All of the routers should be members of the OSPF backbone area. The OSPF configuration should be so specific that if an additional network is added to the router, that network is not automatically advertised. The IP routing tables on all your routers should be populated with all of the specific IP subnets in your network. Verify that the proper OSPF adjacencies have been set up on the LAN segments between the routers in your pod (between routers R1 and R3 and between R2 and R4). Also examine how long the adjacencies have been set up and whether there is any problem in neighbor communications;, such as routing packets remaining in the queue. Verify whether the OSPF has been set up to advertise the IP subnets present on the loopback and LAN interfaces with the correct mask without examining the IP routing table and OSPF topology database. Verify the OSPF link-state database and compare it against the OSPF information that was put into the IP routing table on router R1. You should be able to see that the router R3 loopback network, acquired via OSPF, was put into the routing table, and that the metric related to the route corresponds to the value present in the link-state database.Verify that router R1 is the DR on the LAN segment between R1 and R3. As a next step, you will configure OSPF on the WAN segment between routers R3 and R4 to exchange IP routing information about the loopback and LAN. The OSPF configuration must reflect the point-to-point representation of the Frame Relay interface. Routers will be members of the same OSPF area as LAN segments. The OSPF configuration should be so specific that if an additional network is added to the router, that network is not automatically advertised. The IP routing tables on all your routers should be populated with all of the specific IP subnets in your network. Verify that the proper OSPF adjacencies have been set up on the WAN segment between routers R3 and R4 in your pod. Also examine how long the adjacencies have been set up and whether there is any problem with neighbor communications, such as routing packets remaining in the queue. Verify on the routers in your pod that OSPF has been set up to advertise the IP subnets present on the loopback, LAN interfaces, and the WAN segment from router R3 to R4 with the correct mask without examining the IP routing table and OSPF topology database.Verify the OSPF link-state database and compare it against the OSPF information that was put into the IP routing table on router R1. You should be able to see that the router R3 loopback network, acquired via OSPF, was put into the routing table, and that the metric related to the route corresponds to the value present in the link-state database. In the last step you will configure OSPF on a WAN segment between routers R1, R2, and R4 to exchange IP routing information. OSPF configuration must reflect the point-tomultipoint representation of the Frame Relay interface. Routers will be members of the same OSPF area as LAN segments. The OSPF configuration should be so specific that if an additional network is added to the router, that network is not automatically advertised. The IP routing tables on all of your routers should be populated with all of the specific IP subnets in your network.

© 2009 Cisco Systems, Inc.

Lab Guide

113

Verify that the proper OSPF adjacencies have been set up on the WAN segment between the routers R1, R2, and R4 in your pod. Examine also how long the adjacencies have been set up and whether there is any problem with neighbor communications, such as routing packets remaining in the queue. Verify for the routers in your pod that the OSPF is advertising all of the IP subnets on your routers and that the information is present in the OSPF link-state database as well as in the IP routing table.

Device Information The table provides the information specific to each switch in the network: Device Name

Role

R1

POD router

R2

POD router

R3

POD router

R4

POD router

Command List The table describes the commands that are used in this activity.

114

Command

Description

router ospf 1

Turns on OSPF; the process number is not communicated to other routers

interface s0/0/0.1 multipoint | point-to-point

Creates a subinterface (either point-to-multipoint or point-topoint)

ip ospf network point-tomultipoint

Forces OSPF to treat this interface as point-to-multipoint; the default is NBMA

network 172.31.x.0 0.0.0.255 area 0

Specifies the interfaces on which OSPF will run, in Area 0

show ip ospf interface

Displays information about interfaces configured for OSPF

show ip ospf neighbor

Displays a list of OSPF neighbors

show ip ospf database

Displays information about the OSPF database

show ip route [ospf]

Displays the entire IP routing table or OSPF routes only

ip ospf priority

Sets the router priority

log-adjacency-changes

Configures the router to send a syslog message when an OSPF neighbor goes up or down

ip ospf hello-interval

Specifies the interval between hello packets that are sent on the interface by the Cisco IOS software

clear ip ospf 1 process

Clears the Open Shortest Path First (OSPF) routing process

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Required Resources These are the resources and equipment that are required to complete this activity: A PC that is connected to an on-site laboratory or a PC with an Internet connection if remote laboratory equipment must be accessed A terminal server that is connected to the console port of each laboratory device, if using a remote laboratory Core and access switches in your pod

Job Aids These are the job aids for this lab activity: Value

Location

Blank implementation requirements list

Task 1

Blank implementation and verification plan form

Task 2

Blank verification notes form

Task 3

Alternate resources and solutions form

End of this lab

Implementation requirements hints

“Hints” section at the end of this lab

Implementation and verification plan hints

“Hints” section at the end of this lab

Solution configuration answer key (step-bystep procedure)

Configuration section at the end of this lab

© 2009 Cisco Systems, Inc.

Lab Guide

115

Task 1: Establish an Implementation Requirements List The first step in your configuration deployment is to establish a list of what is needed in order for you to configure each device; for example, the device names, trunk encapsulation types, and so on. Use the following table, the visual objective at the beginning of this lab, the implementation policy, and the device information to create your implementation requirement list. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Device

116

Implementation Requirement

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Task 2: Create an Implementation and Verification Plan The second step in your configuration deployment is to establish a task list of the items that must be configured on each device, and in what order. Use the following table and the visual objective at the beginning of this lab to create your implementation and verification plan. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Complete

© 2009 Cisco Systems, Inc.

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Lab Guide

117

Complete

118

Device

Order

Implementing Cisco IP Routing (ROUTE) v1.0

Values and Items to Implement

Verification Method and Expected Results

© 2009 Cisco Systems, Inc.

Task 3: Implement and Verify Now that you gave collected all of the requirements and planned your implementation, you are ready to connect to the remote lab and implement your solution. Do not forget to save. Once your solution is implemented, you need to verify that your configuration is working and that it fulfills all of the requirements specified by the customer. Keep in mind that once you leave the company, a network specialist will verify your configuration. Your ability to implement the solution according to the customer specifications will determine whether you get the job or not. Use the following area to record your notes and document the verifications you conducted to ensure that your solution is complete. If you are unsure about the verification steps, use the information provided in the “Hints” section at the end of this lab.

Student Notes: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ © 2009 Cisco Systems, Inc.

Lab Guide

119

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

120

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternate Resources and Solutions Other groups may have implemented a solution that is different from yours. These will be discussed during the debriefing period that will follow this lab. Use the following space to document other possible solutions for your reference. __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ © 2009 Cisco Systems, Inc.

Lab Guide

121

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

122

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

-------- The page intentionally left blank. --------

© 2009 Cisco Systems, Inc.

Lab Guide

123

Hints You are encouraged to complete the labs using your knowledge. However, this section contains a series of hints to aid your completion of the lab.

Lab 3-1 Hint Sheet: Configure and Verify OSPF to Improve Routing Performance Implementation Requirements To facilitate the configuration of your network, Task 1 asks you to create an implementation requirements list. This list details the elements you need in order to develop an implementation plan. The following is an example of such a list: Device

Implementation Requirement

Hint

ALL

Define which specific subnets OSPF must announce

Visual Objective

ALL

Decide which OSPF area will be used

Implementation Policy

Implementation and Verification Plan In Task 2, you will create an implementation and verification plan. Although there are several ways to set up this plan, the following tasks must be completed: Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1–R4

1

Load initial configuration.

All pod routers must be preloaded with the initial configuration for the lab.

Step 1

R1, R3

2

Enable OSPF routing protocol on the LAN interface. Apply the configuration so that OSPF does not automatically advertise any additional network that is added to the router. Announce only LAN and loopback networks. Both routers should be members of the backbone area.

Verify that the proper OSPF adjacencies have been set up on LAN segments between the routers.

Step 2

Verify on each router that the OSPF has been set up to advertise the IP subnets present on the loopback and LAN interfaces with the correct mask, without examining the IP routing table and OSPF topology database. Verify the OSPF link-state database and compare it to the OSPF information that was put into the IP routing table. You should be able to see that the loopback network acquired via OSPF was put into the routing table, and that the metric related to the route corresponds to the value present in the link-state database.

124

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R2, R4

3

Enable the OSPF routing protocol on the LAN interface. Apply the configuration so that OSPF does not automatically advertise any additional network that is added to the router. Announce only the LAN and loopback networks. Both routers should be members of the backbone area.

Verify that the proper OSPF adjacencies have been set up on the LAN segments between the routers.

Step 3

Verify on each router that OSPF has been set up to advertise the IP subnets present on the loopback and LAN interfaces with the correct mask, without examining the IP routing table and OSPF topology database. Verify the OSPF link-state database and compare it to the OSPF information that was put into the IP routing table. You should be able to see that the loopback network acquired via OSPF was put into the routing table, and that the metric related to the route corresponds to the value present in the link-state database.

R1, R3

4

Change the default OSPF DR/BDR selection on the LAN segment between routers R1 and R3, and force OSPF to choose R1 to become a DR.

R3

5

Change the OSPF configuration on router R3 and include the WAN segment that connects router R3 to router R4. The OSPF configuration that you add should be so specific that no additional networks are advertised. Place the segment in the OSPF area you have used for the LAN segment and loopbacks. The OSPF network representation for the WAN segment should reflect the Frame Relay network type.

© 2009 Cisco Systems, Inc.

Verify that router R1 is the DR on the LAN segment between R1 and R3.

Step 4

Step 5

Lab Guide

125

Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R4

6

Change the OSPF configuration on router R3 and include the WAN segment that connects router R3 to router R4. The OSPF configuration that you add should be so specific that no additional networks are advertised. Place the segment in the OSPF area you have used for the LAN segment and loopbacks. The OSPF network representation for the WAN segment should reflect the Frame Relay network type.

Verify that the proper OSPF adjacencies have been set up on the WAN segment between routers R3 and R4 in your pod.

Step 5

R1

126

7

Include the WAN segment on router R1 in OSPF and enable the OSPF adjacency over the serial interface toward routers R2 and R4. The OSPF configuration that you add should be so specific that no additional networks are advertised. Place the segment in the same OSPF area you have used so far. The OSPF network representation for the WAN segment should reflect the Frame Relay multipoint network type.

Implementing Cisco IP Routing (ROUTE) v1.0

Also examine how long the adjacencies have been set up and whether there is any problem with neighbor communications, such as routing packets remaining in the queue. On all of the pod routers, verify the OSPF link-state database and compare it against the OSPF information that was put into the IP routing table. You should be able to see that the loopback network acquired via OSPF was put into the routing table, and that the metric related to the route corresponds to the value present in the link-state database. Step 6

© 2009 Cisco Systems, Inc.

Complete

Device

Order

R2, R4

Values and Items to Implement

Verification Method and Expected Results

Step

Add the OSPF configuration on routers R2 and R4. Include WAN segment toward router R1 in the OSPF. The OSPF configuration should also advertise any additional networks from a major network if added later. The OSPF interface network type should reflect the Frame Relay WAN segment representation.

Verify that the proper OSPF adjacencies have been set up on the WAN segment between routers R1, R2, and R4 in your pod. Examine how long the adjacencies have been set up and whether there is any problem with neighbor communications, such as routing packets remaining in the queue.

Step 6

Verify for the routers in your pod that OSPF is advertising all the IP subnets on your routers and that the information is present in the OSPF link-state database as well as in the IP routing table.

Step-by-Step Procedure for Implementation and Verification 1. Load an initial configuration on all devices in your lab. 1.1. The instructor will provide guidelines for changing the initial configuration. 2. Configure OSPF over the LAN interfaces on routers R1 and R3. 2.1. Use the following example to configure the routers in this lab: Îďý ®±«¬»® ±­°ş ď ˛»¬©±®µ ďđňďňďňď đňđňđňđ ż®»ż 𠲻¬©±®µ ďéîňíđňďíňđ đňđňđňîëë ż®»ż đ Îíý ®±«¬»® ±­°ş ď ˛»¬©±®µ ďđňíňíňí đňđňđňđ ż®»ż 𠲻¬©±®µ ďéîňíđňďíňđ đňđňđňîëë ż®»ż đ

2.2. Verify that the proper adjacencies are set up between neighbors on the LAN segment. Îďý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďçîňďęčňíňď

Đ®· ď

ͬż¬» ÚËÔÔńÜÎ

Ü»żĽ Ě·ł» đđćđđćíî

߼Ľ®»­­ ďéîňíđňďíňí

ײ¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ

Ü»żĽ Ě·ł» đđćđđćíę

߼Ľ®»­­ ďéîňíđňďíňď

ײ¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ

Îíý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňďňďňď

Đ®· ď

ͬż¬» ÚËÔÔńŢÜÎ

2.3. Verify that the proper interfaces are involved in the OSPF process, and that networks are advertised. Îďý­¸±© ·° ±­°ş ·˛¬»®şż˝» Ô±±°ľż˝µđ ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďňďńíîô ß®»ż đ Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďéîňíđňďíňďô Ň»¬©±®µ ̧°» ÔŃŃĐŢßÝŐô ݱ­¬ć ď Ô±±°ľż˝µ ·˛¬»®şż˝» ·­ ¬®»ż¬»Ľ ż­ ż ­¬«ľ ر­¬ Úż­¬Ű¬¸»®˛»¬đńđ ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďéîňíđňďíňďńîěô ß®»ż đ Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďéîňíđňďíňďô Ň»¬©±®µ ̧°» ŢÎŃßÜÝßÍĚô ݱ­¬ć ď Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ÜÎô Đ®·±®·¬§ ď Ü»­·ą˛ż¬»Ľ ᫬»® ř×Ü÷ ďéîňíđňďíňďô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňďíňď © 2009 Cisco Systems, Inc.

Lab Guide

127

Ţż˝µ«° Ü»­·ą˛ż¬»Ľ ®±«¬»® ř×Ü÷ ďçîňďęčňíňďô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňďíňí Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđç Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńďô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ î Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďçîňďęčňíňď řŢż˝µ«° Ü»­·ą˛ż¬»Ľ ᫬»®÷ Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Îíý­¸±© ·° ±­°ş ·˛¬»®şż˝» Ô±±°ľż˝µđ ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňíňíňíńíîô ß®»ż đ Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďçîňďęčňíňďô Ň»¬©±®µ ̧°» ÔŃŃĐŢßÝŐô ݱ­¬ć ď Ô±±°ľż˝µ ·˛¬»®şż˝» ·­ ¬®»ż¬»Ľ ż­ ż ­¬«ľ ر­¬ Úż­¬Ű¬¸»®˛»¬đńđ ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďéîňíđňďíňíńîěô ß®»ż đ Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďçîňďęčňíňďô Ň»¬©±®µ ̧°» ŢÎŃßÜÝßÍĚô ݱ­¬ć ď Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ŢÜÎô Đ®·±®·¬§ ď Ü»­·ą˛ż¬»Ľ ᫬»® ř×Ü÷ ďéîňíđňďíňďô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňďíňď Ţż˝µ«° Ü»­·ą˛ż¬»Ľ ®±«¬»® ř×Ü÷ ďçîňďęčňíňďô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňďíňí Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđë Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńďô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ď Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďéîňíđňďíňď řÜ»­·ą˛ż¬»Ľ ᫬»®÷ Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷

2.4. Examine the OSPF link-state database and verify that the loopback network acquired via OSPF was put into the routing table. Îďý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňďňďňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďđňďňďňď ďçîňďęčňíňď

ßą» ďîę ďîé

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđî đ¨đđŰÚëę î đ¨čđđđđđđî đ¨đđęçďě î

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďéîňíđňďíňí

ßÜĘ Î±«¬»® ďçîňďęčňíňď

ßą» ďîé

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđŰďçë

Îďý­¸±© ·° ®±«¬» ±­°ş ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ô î łż­µ­ Ń ďđňíňíňíńíî ĹďďđńîĂ Ş·ż ďéîňíđňďíňíô đđćđîćđéô Úż­¬Ű¬¸»®˛»¬đńđ Îíý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďçîňďęčňíňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďňď ďçîňďęčňíňď

128

ßÜĘ Î±«¬»® ďđňďňďňď ďçîňďęčňíňď

Implementing Cisco IP Routing (ROUTE) v1.0

ßą» ďéč ďéé

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđî đ¨đđŰÚëę î đ¨čđđđđđđî đ¨đđęçďě î

© 2009 Cisco Systems, Inc.

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďéîňíđňďíňí

ßÜĘ Î±«¬»® ďçîňďęčňíňď

ßą» ďéé

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđŰďçë

Îíý­¸±© ·° ®±«¬» ±­°ş ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďňďńíî ĹďďđńîĂ Ş·ż ďéîňíđňďíňďô đđćđęćíéô Úż­¬Ű¬¸»®˛»¬đńđ

3. Configure OSPF over the LAN interfaces on routers R2 and R4. 3.1. Use the following example to configure the routers in this lab: Îîý ®±«¬»® ±­°ş ď ˛»¬©±®µ ďđňîňîňî đňđňđňđ ż®»ż 𠲻¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż đ Îěý ®±«¬»® ±­°ş ď ˛»¬©±®µ ďđňěňěňě đňđňđňđ ż®»ż 𠲻¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż đ

3.2. Verify that the proper adjacencies are set up between neighbors on the LAN segment. Îîý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňěňěňě

Đ®· ͬż¬» ď ÚËÔÔńÜÎ

Ü»żĽ Ě·ł» đđćđđćíđ

߼Ľ®»­­ ďéîňíđňîěňě

ײ¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ

Ü»żĽ Ě·ł» đđćđđćíë

߼Ľ®»­­ ďéîňíđňîěňî

ײ¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ

Îěý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňîňîňî

Đ®· ͬż¬» ď ÚËÔÔńŢÜÎ

3.3. Verify that proper interfaces are involved in the OSPF process and that networks are advertised. Îîý­¸±© ·° ±­°ş ·˛¬»®şż˝» Ô±±°ľż˝µđ ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňîňîňîńíîô ß®»ż đ Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďéîňíđňîěňîô Ň»¬©±®µ ̧°» ÔŃŃĐŢßÝŐô ݱ­¬ć ď Ô±±°ľż˝µ ·˛¬»®şż˝» ·­ ¬®»ż¬»Ľ ż­ ż ­¬«ľ ر­¬ Úż­¬Ű¬¸»®˛»¬đńđ ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďéîňíđňîěňîńîěô ß®»ż đ Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďéîňíđňîěňîô Ň»¬©±®µ ̧°» ŢÎŃßÜÝßÍĚô ݱ­¬ć ď Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ÜÎô Đ®·±®·¬§ ď Ü»­·ą˛ż¬»Ľ ᫬»® ř×Ü÷ ďéîňíđňîěňîô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňîěňî Ţż˝µ«° Ü»­·ą˛ż¬»Ľ ®±«¬»® ř×Ü÷ ďđňěňěňěô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňîěňě Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđđ Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńďô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ đô łż¨·ł«ł ·­ î Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňěňěňě řŢż˝µ«° Ü»­·ą˛ż¬»Ľ ᫬»®÷ Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Îěý ­¸±© ·° ±­°ş ·˛¬»®şż˝» Ô±±°ľż˝µđ ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňěňěňěńíîô ß®»ż đ Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňěňěňěô Ň»¬©±®µ ̧°» ÔŃŃĐŢßÝŐô ݱ­¬ć ď Ô±±°ľż˝µ ·˛¬»®şż˝» ·­ ¬®»ż¬»Ľ ż­ ż ­¬«ľ ر­¬ Úż­¬Ű¬¸»®˛»¬đńđ ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďéîňíđňîěňěńîěô ß®»ż đ Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňěňěňěô Ň»¬©±®µ ̧°» ŢÎŃßÜÝßÍĚô ݱ­¬ć ď © 2009 Cisco Systems, Inc.

Lab Guide

129

Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ŢÜÎô Đ®·±®·¬§ ď Ü»­·ą˛ż¬»Ľ ᫬»® ř×Ü÷ ďéîňíđňîěňîô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňîěňî Ţż˝µ«° Ü»­·ą˛ż¬»Ľ ®±«¬»® ř×Ü÷ ďđňěňěňěô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňîěňě Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđé Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńďô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ď Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďéîňíđňîěňî řÜ»­·ą˛ż¬»Ľ ᫬»®÷ Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷

3.4. Examine the OSPF link-state database and verify that the loopback network acquired via OSPF was put into the routing table. Îîý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňîňîňî÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďđňîňîňî ďđňěňěňě

ßą» ďęç ďéđ

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđî đ¨đđđďîě î đ¨čđđđđđđî đ¨đđÚŰďî î

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ďéđ

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Îîý­¸±© ·° ®±«¬» ±­°ş ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ô î łż­µ­ Ń ďđňěňěňěńíî ĹďďđńîĂ Ş·ż ďéîňíđňîěňěô đđćđěćěđô Úż­¬Ű¬¸»®˛»¬đńđ Îěý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňěňěňě÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďđňîňîňî ďđňěňěňě

ßą» îďě îďí

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđî đ¨đđđďîě î đ¨čđđđđđđî đ¨đđÚŰďî î

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» îďí

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Îěý­¸±© ·° ®±«¬» ±­°ş ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ô î łż­µ­ Ń ďđňîňîňîńíî ĹďďđńîĂ Ş·ż ďéîňíđňîěňîô đđćđéćíěô Úż­¬Ű¬¸»®˛»¬đńđ

4. Change the default OSPF DR/BDR selection on the LAN segment between routers R1 and R3. 4.1. Use the following example to configure the routers in this lab: Îďý ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° ±­°ş °®·±®·¬§ ďđ Îďý˝´»ż® ·° ±­°ş ď °®±˝»­­

4.2. Verify that router R1 is the DR on the LAN segment between R1 and R3. 130

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Îďý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďçîňďęčňíňď

Đ®· ď

ͬż¬» ÚËÔÔńÜÎ

Ü»żĽ Ě·ł» đđćđđćíî

߼Ľ®»­­ ďéîňíđňďíňí

ײ¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ

5. Configure OSPF over Frame Relay using a point-to-point OSPF network type. 5.1. Use the following example to configure router R3 in this lab: Îíý ®±«¬»® ±­°ş ď ˛»¬©±®µ ďđňďňďíěňđ đňđňđňîëë ż®»ż đ

5.2. Use the following example to configure router R4 in this lab: Îěý ®±«¬»® ±­°ş ď ˛»¬©±®µ ďđňďňďíěňđ đňđňđňîëë ż®»ż đ

5.3. Verify the configuration on routers R1, R2, R3, and R4. Îďý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňďňďňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďňď ďđňîňîňî ďđňěňěňě ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďđňďňďňď ďđňîňîňî ďđňěňěňě ďçîňďęčňíňď

ßą» éč íéî ďď ďë

Í»Żý đ¨čđđđđđđí đ¨čđđđđđđî đ¨čđđđđđđě đ¨čđđđđđđě

ݸ»˝µ­«ł đ¨đđŰÜëé đ¨đđđďîě đ¨đđééęě đ¨đđéđíđ

Ô·˛µ ˝±«˛¬ î î ě ě

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďéîňíđňďíňí ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďđňěňěňě

ßą» ęęî íéď

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđŰďçë đ¨čđđđđđđď đ¨đđđďďę

Îďý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ń ďéîňíđňîěňđ ĹďďđńęęĂ Ş·ż ďéîňíđňďíňíô đđćđďćîęô Úż­¬Ű¬¸»®˛»¬đńđ ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňîňîňîńíî ĹďďđńęéĂ Ş·ż ďéîňíđňďíňíô đđćđďćîęô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňíňíňíńíî ĹďďđńîĂ Ş·ż ďéîňíđňďíňíô đđćđďćîęô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňěňěňěńíî ĹďďđńęęĂ Ş·ż ďéîňíđňďíňíô đđćđďćîęô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňďňďíěňđńîě ĹďďđńęëĂ Ş·ż ďéîňíđňďíňíô đđćđďćîęô Úż­¬Ű¬¸»®˛»¬đńđ Îîý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňěňěňě

Đ®· ď

ͬż¬» ÚËÔÔńÜÎ

Ü»żĽ Ě·ł» đđćđđćíë

߼Ľ®»­­ ďéîňíđňîěňě

ײ¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ

Îîý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňîňîňî÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďňď ďđňîňîňî ďđňěňěňě ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďđňďňďňď ďđňîňîňî ďđňěňěňě ďçîňďęčňíňď

ßą» ďěç ěíé éç čí

Í»Żý đ¨čđđđđđđí đ¨čđđđđđđî đ¨čđđđđđđě đ¨čđđđđđđě

ݸ»˝µ­«ł đ¨đđŰÜëé đ¨đđđďîě đ¨đđééęě đ¨đđéđíđ

Ô·˛µ ˝±«˛¬ î î ě ě

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ © 2009 Cisco Systems, Inc.

Lab Guide

131

Ô·˛µ ×Ü ďéîňíđňďíňí ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďđňěňěňě

ßą» éíď ěíč

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđŰďçë đ¨čđđđđđđď đ¨đđđďďę

Îîý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ń ďéîňíđňďíňđ ĹďďđńęęĂ Ş·ż ďéîňíđňîěňěô đđćđďćëęô Úż­¬Ű¬¸»®˛»¬đńđ ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňíňíňíńíî ĹďďđńęęĂ Ş·ż ďéîňíđňîěňěô đđćđďćëęô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňďňďňďńíî ĹďďđńęéĂ Ş·ż ďéîňíđňîěňěô đđćđďćëęô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňěňěňěńíî ĹďďđńîĂ Ş·ż ďéîňíđňîěňěô đđćđďćëęô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňďňďíěňđńîě ĹďďđńęëĂ Ş·ż ďéîňíđňîěňěô đđćđďćëęô Úż­¬Ű¬¸»®˛»¬đńđ Îíý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňěňěňě ďđňďňďňď

Đ®· đ ďđ

ͬż¬» ÚËÔÔń ó ÚËÔÔńŢÜÎ

Ü»żĽ Ě·ł» đđćđđćíí đđćđđćíď

߼Ľ®»­­ ďđňďňďíěňě ďéîňíđňďíňď

ײ¬»®şż˝» Í»®·ż´đńđńđňî Úż­¬Ű¬¸»®˛»¬đńđ

Îíý­¸±© ·° ±­°ş ·˛¬»®şż˝» ­»đńđńđňî Í»®·ż´đńđńđňî ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďíěňíńîěô ß®»ż đ Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďçîňďęčňíňďô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđď Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ íńíô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ď Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňěňěňě Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Îíý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďçîňďęčňíňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďňď ďđňîňîňî ďđňěňěňě ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďđňďňďňď ďđňîňîňî ďđňěňěňě ďçîňďęčňíňď

ßą» îíč ëîç ďęç ďéí

Í»Żý đ¨čđđđđđđí đ¨čđđđđđđî đ¨čđđđđđđě đ¨čđđđđđđě

ݸ»˝µ­«ł đ¨đđŰÜëé đ¨đđđďîě đ¨đđééęě đ¨đđéđíđ

Ô·˛µ ˝±«˛¬ î î ě ě

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďéîňíđňďíňí ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďđňěňěňě

ßą» čîđ ëîč

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđŰďçë đ¨čđđđđđđď đ¨đđđďďę

Îíý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ń ďéîňíđňîěňđ ĹďďđńęëĂ Ş·ż ďđňďňďíěňěô đđćđîćěéô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňîňîňîńíî ĹďďđńęęĂ Ş·ż ďđňďňďíěňěô đđćđîćěéô Í»®·ż´đńđńđňî Ń ďđňďňďňďńíî ĹďďđńîĂ Ş·ż ďéîňíđňďíňďô đđćđîćěéô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňěňěňěńíî ĹďďđńęëĂ Ş·ż ďđňďňďíěňěô đđćđîćěéô Í»®·ż´đńđńđňî Îěý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďçîňďęčňíňď ďđňîňîňî 132

Đ®· đ ď

ͬż¬» ÚËÔÔń ó ÚËÔÔńŢÜÎ

Implementing Cisco IP Routing (ROUTE) v1.0

Ü»żĽ Ě·ł» đđćđđćíë đđćđđćíí

߼Ľ®»­­ ďđňďňďíěňí ďéîňíđňîěňî

ײ¬»®şż˝» Í»®·ż´đńđńđňî Úż­¬Ű¬¸»®˛»¬đńđ © 2009 Cisco Systems, Inc.

Îěý­¸±© ·° ±­°ş ·˛¬»®şż˝» ­»®·ż´đńđńđňî Í»®·ż´đńđńđňî ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďíěňěńîěô ß®»ż đ Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňěňěňěô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđé Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ íńíô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ď Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďçîňďęčňíňď Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Îěý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňěňěňě÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďňď ďđňîňîňî ďđňěňěňě ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďđňďňďňď ďđňîňîňî ďđňěňěňě ďçîňďęčňíňď

ßą» ěđđ ęçđ ííđ ííë

Í»Żý đ¨čđđđđđđí đ¨čđđđđđđî đ¨čđđđđđđě đ¨čđđđđđđě

ݸ»˝µ­«ł đ¨đđŰÜëé đ¨đđđďîě đ¨đđééęě đ¨đđéđíđ

Ô·˛µ ˝±«˛¬ î î ě ě

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďéîňíđňďíňí ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďđňěňěňě

ßą» çčî ęčç

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđŰďçë đ¨čđđđđđđď đ¨đđđďďę

Îěý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ń ďéîňíđňďíňđ ĹďďđńęëĂ Ş·ż ďđňďňďíěňíô đđćđíćîęô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňîňîňîńíî ĹďďđńîĂ Ş·ż ďéîňíđňîěňîô đđćđíćîęô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňíňíňíńíî ĹďďđńęëĂ Ş·ż ďđňďňďíěňíô đđćđíćîęô Í»®·ż´đńđńđňî Ń ďđňďňďňďńíî ĹďďđńęęĂ Ş·ż ďđňďňďíěňíô đđćđíćîęô Í»®·ż´đńđńđňî

6. Configure OSPF over Frame Relay using a point-to-multipoint OSPF network type. 6.1. Use the following example to configure router R1 in this lab: Îďý ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ˙ ®±«¬»® ±­°ş ď ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż đ

6.2. Use the following example to configure routers R2 and R4 in this lab: Îîý ®±«¬»® ±­°ş ď ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż đ Îěý ®±«¬»® ±­°ş ď ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż đ

6.3. Verify the configuration on routers R1, R2, and R4. © 2009 Cisco Systems, Inc.

Lab Guide

133

Îďý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňîňîňî ďđňěňěňě ďçîňďęčňíňď

Đ®· đ đ ď

ͬż¬» ÚËÔÔń ó ÚËÔÔń ó ÚËÔÔńÜÎ

Ü»żĽ Ě·ł» đđćđđćíę đđćđđćíđ đđćđđćíę

߼Ľ®»­­ ďđňďňďďđňî ďđňďňďďđňě ďéîňíđňďíňí

ײ¬»®şż˝» Í»®·ż´đńđńđňď Í»®·ż´đńđńđňď Úż­¬Ű¬¸»®˛»¬đńđ

Îďý­¸±© ·° ±­°ş ·˛¬ ­»đńđńđňď Í»®·ż´đńđńđňď ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďđňďńîěô ß®»ż đ Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňďňďňďô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁÓËÔĚ×ĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁÓËÔĚ×ĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđî Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ íńíô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ď Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ îô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ î ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňîňîňî ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňěňěňě Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Îďý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňďňďňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďňď ďđňîňîňî ďđňěňěňě ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďđňďňďňď ďđňîňîňî ďđňěňěňě ďçîňďęčňíňď

ßą» ďđí ďđě ďďđ ëďé

Í»Żý đ¨čđđđđđđę đ¨čđđđđđđí đ¨čđđđđđđë đ¨čđđđđđđě

ݸ»˝µ­«ł đ¨đđÜčîé đ¨đđÝŰŢě đ¨đđđěíě đ¨đđéđíđ

Ô·˛µ ˝±«˛¬ ë ě ę ě

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďéîňíđňďíňí ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďđňěňěňě

ßą» ďďęë čéí

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđŰďçë đ¨čđđđđđđď đ¨đđđďďę

Îďý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ń ďéîňíđňîěňđ ĹďďđńęëĂ Ş·ż ďđňďňďďđňěô đđćđďćíđô Í»®·ż´đńđńđňď ĹďďđńęëĂ Ş·ż ďđňďňďďđňîô đđćđďćíđô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňîňîňîńíî ĹďďđńęëĂ Ş·ż ďđňďňďďđňîô đđćđďćíđô Í»®·ż´đńđńđňď Ń ďđňíňíňíńíî ĹďďđńîĂ Ş·ż ďéîňíđňďíňíô đđćđďćíđô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňěňěňěńíî ĹďďđńęëĂ Ş·ż ďđňďňďďđňěô đđćđďćíđô Í»®·ż´đńđńđňď Ń ďđňďňďíěňđńîě ĹďďđńęëĂ Ş·ż ďéîňíđňďíňíô đđćđďćíđô Úż­¬Ű¬¸»®˛»¬đńđ Îîý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňďňďňď ďđňěňěňě

Đ®· đ ď

ͬż¬» ÚËÔÔń ó ÚËÔÔńÜÎ

Ü»żĽ Ě·ł» đđćđđćíě đđćđđćíç

߼Ľ®»­­ ďđňďňďďđňď ďéîňíđňîěňě

ײ¬»®şż˝» Í»®·ż´đńđńđňď Úż­¬Ű¬¸»®˛»¬đńđ

Îîý­¸±© ·° ±­°ş ·˛¬»®şż˝» ­»®·ż´ đńđńđňď Í»®·ż´đńđńđňď ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďđňîńîěô ß®»ż đ Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňîňîňîô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđë Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ 134

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

ײĽ»¨ íńíô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ď Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňďňďňď Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Îîý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňîňîňî÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďňď ďđňîňîňî ďđňěňěňě ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďđňďňďňď ďđňîňîňî ďđňěňěňě ďçîňďęčňíňď

ßą» îđç îđč îďę ęîí

Í»Żý đ¨čđđđđđđę đ¨čđđđđđđí đ¨čđđđđđđë đ¨čđđđđđđě

ݸ»˝µ­«ł đ¨đđÜčîé đ¨đđÝŰŢě đ¨đđđěíě đ¨đđéđíđ

Ô·˛µ ˝±«˛¬ ë ě ę ě

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďéîňíđňďíňí ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďđňěňěňě

ßą» ďîéđ çéé

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđŰďçë đ¨čđđđđđđď đ¨đđđďďę

Îîý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ń ďéîňíđňďíňđ ĹďďđńęëĂ Ş·ż ďđňďňďďđňďô đđćđíćđíô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­ Ń ďđňíňíňíńíî ĹďďđńęęĂ Ş·ż ďéîňíđňîěňěô đđćđíćđíô Úż­¬Ű¬¸»®˛»¬đńđ ĹďďđńęęĂ Ş·ż ďđňďňďďđňďô đđćđíćđíô Í»®·ż´đńđńđňď Ń ďđňďňďňďńíî ĹďďđńęëĂ Ş·ż ďđňďňďďđňďô đđćđíćđíô Í»®·ż´đńđńđňď Ń ďđňěňěňěńíî ĹďďđńîĂ Ş·ż ďéîňíđňîěňěô đđćđíćđíô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđíćđíô Í»®·ż´đńđńđňď Ń ďđňďňďíěňđńîě ĹďďđńęëĂ Ş·ż ďéîňíđňîěňěô đđćđíćđíô Úż­¬Ű¬¸»®˛»¬đńđ Îěý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňďňďňď ďçîňďęčňíňď ďđňîňîňî

Đ®· đ đ ď

ͬż¬» ÚËÔÔń ó ÚËÔÔń ó ÚËÔÔńŢÜÎ

Ü»żĽ Ě·ł» đđćđđćíě đđćđđćíđ đđćđđćíď

߼Ľ®»­­ ďđňďňďďđňď ďđňďňďíěňí ďéîňíđňîěňî

ײ¬»®şż˝» Í»®·ż´đńđńđňď Í»®·ż´đńđńđňî Úż­¬Ű¬¸»®˛»¬đńđ

Îěý­¸±© ·° ±­°ş ·˛¬»®şż˝» ­»®·ż´ đńđńđňď Í»®·ż´đńđńđňď ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďđňěńîěô ß®»ż đ Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňěňěňěô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđí Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ěńěô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ď Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňďňďňď Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Îěý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňěňěňě÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü © 2009 Cisco Systems, Inc.

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ Lab Guide

135

ďđňďňďňď ďđňîňîňî ďđňěňěňě ďçîňďęčňíňď

ďđňďňďňď ďđňîňîňî ďđňěňěňě ďçîňďęčňíňď

íđđ íđđ íđë éďí

đ¨čđđđđđđę đ¨čđđđđđđí đ¨čđđđđđđë đ¨čđđđđđđě

đ¨đđÜčîé đ¨đđÝŰŢě đ¨đđđěíě đ¨đđéđíđ

ë ě ę ě

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďéîňíđňďíňí ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďđňěňěňě

ßą» ďíęđ ďđęé

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđŰďçë đ¨čđđđđđđď đ¨đđđďďę

Îěý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ń ďéîňíđňďíňđ ĹďďđńęëĂ Ş·ż ďđňďňďíěňíô đđćđěćďîô Í»®·ż´đńđńđňî ĹďďđńęëĂ Ş·ż ďđňďňďďđňďô đđćđěćďîô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­ Ń ďđňîňîňîńíî ĹďďđńîĂ Ş·ż ďéîňíđňîěňîô đđćđěćďîô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňíňíňíńíî ĹďďđńęëĂ Ş·ż ďđňďňďíěňíô đđćđěćďîô Í»®·ż´đńđńđňî Ń ďđňďňďňďńíî ĹďďđńęëĂ Ş·ż ďđňďňďďđňďô đđćđěćďîô Í»®·ż´đńđńđňď Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđěćďîô Í»®·ż´đńđńđňď

136

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab 3-2: Implement and Verify OSPF Multiarea Routing Complete this lab activity to practice what you learned in the related module.

Activity Objective In this activity, you will use the correct commands, tools, and steps to configure and verify OSPF multiarea routing. After completing this activity, you will be able to meet these objectives: Configure and verify the OSPF operation over LAN and WAN interfaces Configure and verify the OSPF operation using multiple areas Select the required tools and commands to configure OSPF operations Influence the path selection for OSPF by changing the cost Optimize the OSPF operation to prevent the transmission of unnecessary hellos Make a list of configuration and implementation steps Write a verification and test plan to verify the proper implementation and operation according to the expected performance criteria Verify the configuration and operation by using the proper show and debug commands

Information Packet The figure illustrates what you will accomplish in this activity.

Visual Objective

Visual Objective for Lab 3-2: Implement and Verify OSPF Multiarea Routing

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

ROUTE v 1. 0—LG-12

Lab Guide

137

Implementation Policy The following list details the configuration requirements for all devices in the company network: First you will configure OSPF on the WAN segment between routers R1 and BBR2. BBR2 is preconfigured with OSPF routing in Area 0. Router R1 will be configured in OSPF Area 0 with a WAN interface toward router BBR2 and should receive IP routing information about network 172.30.10.0/24 from router BBR2. Verify that the OSPF adjacency has been set up on the WAN segment between routers R1 and BBR2. Examine the OSPF link-state database on router R1 and compare it to the IP routing table to verify the correctness of the received information. Examine the IP routing table on router R1 and verify that it is populated with the expected OSPF routes. Verify that you have connectivity to the BBR2 LAN segment 172.30.10.0/24. In this task you will complete the OSPF routing configuration in your pod. You will configure OSPF routing on routers R2, R3, and R4. Router R3 will be a member of OSPF Area 3 with all of its interfaces. Routers R2 and R4 will be members of Area 24. All of the router R2 and R4 interfaces will be part of that area. Routers in your pod should exchange and receive IP routing information about all of the subnets available. Verify that the OSPF adjacency has been set up between routers R1 and R3 in OSPF Area 3. Examine the OSPF link-state database on router R3 and compare it against its routing table to verify that the correct information was put into the IP routing table. Verify that router R3 has all the necessary IP subnets in its routing table and that it can access all the IP subnets in the network. Verify that the OSPF adjacency has been set up between routers R1 and R2 and between routers R1 and R4 in OSPF Area 24. Examine the OSPF link-state database on routers R2 and R4 and compare them against their routing tables to verify that the correct information was put into the IP routing table. Verify that routers R2 and R4 have all the necessary IP subnets in their routing tables and that they can access all the IP subnets in the network, including the subnets that have been announced by BBR2. Verify that you have connectivity to the BBR2 LAN segment 172.30.10.0/24 from all routers in your pod. In this task you will precisely adjust the OSPF operation on your routers. You will change the default path cost calculation in Area 24 and persuade router R1 to prefer the path via router R2 to the 172.30.24.0/24 LAN segment. Next you will have to make the OSPF routing in Area 0 more stable by forcing router R1 to administratively define the router ID. Finally, you will optimize the OSPF operation in Area 3 on router R3 to preserve CPU resources on that router by eliminating unnecessary OSPF traffic on the LAN segment. Verify that all the necessary OSPF adjacencies in the network are up and running. Router R1 should have an OSPF adjacency set up with BBR2 in Area 0, with router R3 in Area 3, and with routers R2 and R4 in Area 24. Verify that router R1 is using a stable router ID for the OSPF process you have configured. Examine the IP routing table on router R1 and confirm that it prefers the path via router R2 toward the 172.30.24.0/24 segment. Verify that R1 selects R2 as the next hop for IP packets destined to segment 172.30.24.0/24. Examine the OSPF adjacencies on router R3 and verify that the adjacency with router R1 is the only adjacency that is up and running. Verify that router R3 is not trying to set up an OSPF adjacency via the LAN segment.

138

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Device Information The table provides the information specific to each switch in the network: Device Name

Role

R1

POD router

R2

POD router

R3

POD router

R4

POD router

BBR2

Backbone router

Command List The table describes the commands that are used in this activity. Command

Description

router ospf 1

Turns on OSPF; the process number is not communicated to other routers

neighbor 10.1.110.2 cost 10

Assigns a cost to the neighbor

interface s0/0/0.1 multipoint | pointto-point

Creates a subinterface (either point-to-multipoint or point-topoint)

ip ospf network point-to-multipoint

Forces OSPF to treat this interface as point-to-multipoint; the default is NBMA

network 172.31.x.0 0.0.0.255 area 0

Specifies the interfaces on which OSPF will run, in Area 0

show ip ospf interface

Displays information about interfaces configured for OSPF

show ip ospf neighbor

Displays a list of OSPF neighbors

show ip ospf database

Displays information about the OSPF database

show ip route [ospf]

Displays a whole IP routing table or OSPF routes only

ip ospf priority

Sets the router priority

log-adjacency-changes

Configures the router to send a syslog message when an OSPF neighbor goes up or down

ip ospf hello-interval

Specifies the interval between hello packets that are sent on the interface by the Cisco IOS software

clear ip ospf 1 process

Clears the Open Shortest Path First (OSPF) routing process

router-id

Sets a fixed router ID

passive-interface

Disables the sending of routing updates on an interface

Ping

Diagnoses basic network connectivity

Trace

Discovers the routes that packets will actually take when traveling to their destination

© 2009 Cisco Systems, Inc.

Lab Guide

139

Required Resources These are the resources and equipment that are required to complete this activity: A PC that is connected to an on-site laboratory or a PC with an Internet connection if remote laboratory equipment must be accessed A terminal server that is connected to the console port of each laboratory device, if using a remote laboratory Core and access switches in your pod

Job Aids These are the job aids for this lab activity:

140

Value

Location

Blank implementation requirements list

Task 1

Blank implementation and verification plan form

Task 2

Blank verification notes form

Task 3

Alternate resources and solutions form

End of this lab

Implementation requirements hints

“Hints” section at the end of this lab

Implementation and verification plan hints

“Hints” section at the end of this lab

Solution configuration answer key (step-bystep procedure)

Configuration section at the end of this lab

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Task 1: Establish an Implementation Requirements List The first step in your configuration deployment is to establish a list of what is needed in order for you to configure each device; for example, device names, trunk encapsulation types, and so on. Use the following table, the visual objective at the beginning of this lab, the implementation policy, and the device information to create your implementation requirement list. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Device

© 2009 Cisco Systems, Inc.

Implementation Requirement

Lab Guide

141

-------- The page intentionally left blank. --------

142

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Task 2: Create an Implementation and Verification Plan The second step in your configuration deployment is to establish a task list of the items that must be configured on each device, and in what order. Use the following table and the visual objective at the beginning of this lab to create your implementation and verification plan. If you are unsure, you use the information provided in the “Hints” section at the end of this lab. Complete

© 2009 Cisco Systems, Inc.

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Lab Guide

143

Complete

144

Device

Order

Implementing Cisco IP Routing (ROUTE) v1.0

Values and Items to Implement

Verification Method and Expected Results

© 2009 Cisco Systems, Inc.

Task 3: Implement and Verify Now that you have collected all the requirements and planned your implementation, you are ready to connect to the remote lab and implement your solution. Do not forget to save. Once your solution is implemented, you need to verify that your configuration is working and fulfills all the requirements specified by the customer. Keep in mind that once you leave the company, a network specialist will verify your configuration. Your ability to implement the solution according to the customer specifications will determine whether you get the job or not. Use the following area to record your notes and document the verifications you conducted to ensure that your solution is complete. If you are unsure about the verification steps, use the information provided in the “Hints” section at the end of this lab. Student Notes: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ © 2009 Cisco Systems, Inc.

Lab Guide

145

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

146

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternate Resources and Solutions Other groups may have implemented a solution that is different from yours. These will be discussed during the debriefing period that will follow this lab. Use the following space to document other possible solutions for your reference. __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ © 2009 Cisco Systems, Inc.

Lab Guide

147

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

148

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Hints You are encouraged to complete the labs using your knowledge. However, this section contains a series of hints to aid your completion of the lab.

Lab 3-2 Hint Sheet: Implement and Verify OSPF Multiarea Routing Implementation Requirements To facilitate the configuration of your network, Task 1 asks you to create an implementation requirements list. This list details the elements you need in order to develop an implementation plan. The following is an example of such a list: Device

Implementation Requirement

Hint

ALL

Define the interfaces and networks used in the network in order to correctly implement OSPF.

Visual Objective and lab

ALL

Observe the costs on the links.

Lab

Implementation and Verification Plan In Task 2, you will create an implementation and verification plan. Although there are several ways to set up this plan, the following tasks must be completed: Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1–R4

1

Load the initial configuration.

All pod routers must be preloaded with the initial configuration for the lab.

Step 1

© 2009 Cisco Systems, Inc.

Lab Guide

149

Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1

2

Configure OSPF routing protocol on router R1. Enable the logging of OSPF neighbor changes on router R1. Include the router R1 WAN interface toward router BBR2 in the OSPF routing process. Remember that router BBR2 is already configured with the OSPF routing protocol toward router R1 in OSPF Area 0

Verify that the OSPF adjacency has been set up on the WAN segment between routers R1 and BBR2. Examine the OSPF link-state database on router R1 and compare it against the IP routing table to verify the correctness of the received information. Examine the IP routing table on router R1 and verify that it is populated with the expected OSPF routes. Verify that you have connectivity to the BBR2 LAN segment 172.30.10.0/24.

Step 2

R3

3

Enable the OSPF routing protocol on router R3 and enable the logging of OSPF adjacency changes. Set up an OSPF adjacency with router R1. Configure router R3 to be part of Area 3 with all its interfaces.

R1

4

On router R1, add the OSPF configuration to enable adjacency with router R3. Router R1 should announce its networks and networks received via the backbone OSPF area to router R3.

Verify that the OSPF adjacency has been set up between routers R1 and R3 in OSPF Area 3.

Step 3

R1, R2, R4

5

Configure the OSPF routing protocol on routers R2 and R4, and enable the logging of adjacency changes. Routers should set up an OSPF adjacency with router R1 and between each other. The LAN and WAN interfaces of routers R2 and R4 should be part of OSPF Area 24.

Verify that the OSPF adjacency has been set up between routers R1 and R2 and between routers R1 and R4 in OSPF Area 24.

Step 4

Add a configuration on router R1 to allow the creation of OSPF adjacencies with routers R2 and R4. Router R1 should announce its network and networks received via the backbone area to routers R2 and R4.

150

Implementing Cisco IP Routing (ROUTE) v1.0

Step 3

Examine the OSPF link-state database on routers R2 and R4 and compare it to the router R2 and R4 routing tables to verify that the correct information was put into the IP routing table, including the subnets that were announced by BBR2.

© 2009 Cisco Systems, Inc.

Complete

Device

Order

R1, R3, R4

7

Values and Items to Implement

Verification Method and Expected Results

Step

Examine the OSPF link-state database on router R3 and compare it against its routing table to verify that the correct information was put into the IP routing table, including the subnets that were announced by BBR2.

Step 5

Verify that you have connectivity to the router BBR2 LAN segment 172.30.10.0/24 from routers R1 and R4. R1

8

Examine the routing information for the LAN segment 172.30.24.0/24 on router R1 to verify which path is used to reach the destinations on that segment. Adjust the cost parameter used for OSPF path calculation on routers in Area 24 so that router R1 prefers the path via router R2 to the 172.30.24.0/24 destination subnet.

Examine the IP routing table on router R1 and confirm that it prefers the path via router R2 toward the 172.30.24.0/24 segment.

Step 6

R1

9

Examine the OSPF configuration on router R1 to inspect what OSPF router ID is used for the OSPF process. Then change the OSPF router ID on router R1 and force the router to use the administratively defined value for the router ID.

Verify that router R1 is using a stable router ID for the OSPF process you have configured.

Step 7

Examine the OSPF adjacencies on router R3. Verify that there are no neighbors seen on the LAN segment, but despite that, router R3 is constantly trying to set up OSPF adjacency. Change the OSPF configuration on router R3 so that it stops trying to set up OSPF adjacency via the LAN interface, which will preserve CPU cycles. The configuration should prevent the sending of OSPF hello packets out of that interface.

Verify that router R3 stopped trying to set up an OSPF adjacency via the LAN segment.

R3

10

Router R1 should have OSPF adjacency set up with BBR2 in Area 0, with router R3 in Area 3, and with routers R2 and R4 in Area 24. Step 8

11 12

© 2009 Cisco Systems, Inc.

Lab Guide

151

Step-by-Step Procedure for Implementation and Verification 1. Load the initial configuration on all devices in your lab. 1.1. The instructor will provide guidelines for changing the initial configuration. 2. Configure the OSPF backbone area. 2.1. Use the following example to configure the routers in this lab: Îďý ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďďęňđ đňđňđňîëë ż®»ż đ

2.2. Verify OSPF configuration and reachability using different commands on router R1. Îďý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďéîňíđňďđňę

Đ®· đ

ͬż¬» ÚËÔÔń

Ü»żĽ Ě·ł» đđćđđćíî

ó

߼Ľ®»­­ ďđňďňďďęňę

ײ¬»®şż˝» Í»®·ż´đńđńđňďďę

Îďý­¸±© ·° ±­°ş ·˛¬»®şż˝» Í»®·ż´đńđńđňďďę ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďęňďńîěô ß®»ż đ Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňďňďňďô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđî Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńďô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ď Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďéîňíđňďđňę Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Îďý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňďňďňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďňď ďéîňíđňďđňę

ßÜĘ Î±«¬»® ďđňďňďňď ďéîňíđňďđňę

ßą» éë éî

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđî đ¨đđěěęß î đ¨čđđđđđđí đ¨đđîÚÝě í

Îďý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ Ń ďéîňíđňďđňđ ĹďďđńęëĂ Ş·ż ďđňďňďďęňęô đđćđďćđëô Í»®·ż´đńđńđňďďę Îďý°·˛ą ďéîňíđňďđňę ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňíđňďđňęô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ëęńëéńęđ ł­

3. Configure the OSPF nonbackbone areas. 3.1. Use the following example to configure router R3 in this lab: Îíý ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďďíňđ đňđňđňîëë ż®»ż í 152

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˛»¬©±®µ ďéîňíđňďíňđ đňđňđňîëë ż®»ż í

3.2. Use the following example to configure router R1 in this lab: Îďý ®±«¬»® ±­°ş ď ˛»¬©±®µ ďđňďňďďíňđ đňđňđňîëë ż®»ż í

3.3. Verify the adjacency between routers R1 and R3: Îíý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňďňďňď

Đ®· đ

ͬż¬» ÚËÔÔń

ó

Ü»żĽ Ě·ł» đđćđđćíę

߼Ľ®»­­ ďđňďňďďíňď

ײ¬»®şż˝» Í»®·ż´đńđńđňî

4. Configure OSPF nonbackbone areas. 4.1. Use the following example to configure routers R2 and R4 in this lab: Îîý ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż îě ˛»¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż îě Îěý ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż îě ˛»¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż îě

4.2. Use the following example to configure router R1 in this lab: Îďý ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ˙ ®±«¬»® ±­°ş ď ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż îě

4.3. Verify the OSPF configuration on routers R1, R2, and R4. Îďý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďéîňíđňďđňę ďçîňďęčňíňď ďđňěňěňě ďđňîňîňî

Đ®· đ đ đ đ

ͬż¬» ÚËÔÔń ÚËÔÔń ÚËÔÔń ÚËÔÔń

ó ó ó ó

Ü»żĽ Ě·ł» đđćđđćíđ đđćđđćíě đđćđđćíé đđćđđćíç

߼Ľ®»­­ ďđňďňďďęňę ďđňďňďďíňí ďđňďňďďđňě ďđňďňďďđňî

ײ¬»®şż˝» Í»®·ż´đńđńđňďďę Í»®·ż´đńđńđňî Í»®·ż´đńđńđňď Í»®·ż´đńđńđňď

ͬż¬» ÚËÔÔńÜÎ ÚËÔÔń ó

Ü»żĽ Ě·ł» đđćđđćíí đđćđđćíě

߼Ľ®»­­ ďéîňíđňîěňě ďđňďňďďđňď

ײ¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ Í»®·ż´đńđńđňď

Ü»żĽ Ě·ł» đđćđđćíč đđćđđćíč

߼Ľ®»­­ ďéîňíđňîěňî ďđňďňďďđňď

ײ¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ Í»®·ż´đńđńđňď

Îîý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňěňěňě ďđňďňďňď

Đ®· ď đ

Îěý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňîňîňî ďđňďňďňď

Đ®· ď đ

ͬż¬» ÚËÔÔńŢÜÎ ÚËÔÔń ó

Îďý­¸±© ·° ±­°ş ·˛¬»®şż˝» Í»®·ż´đńđńđňďďę ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďęňďńîěô ß®»ż đ Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňďňďňďô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ © 2009 Cisco Systems, Inc.

Lab Guide

153

Ř»´´± Ľ«» ·˛ đđćđđćđď Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńíô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ď Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďéîňíđňďđňę Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Í»®·ż´đńđńđňî ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďíňďńîěô ß®»ż í Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňďňďňďô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđđ Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńîô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ď Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďçîňďęčňíňď Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Í»®·ż´đńđńđňď ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďđňďńîěô ß®»ż îě Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňďňďňďô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁÓËÔĚ×ĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁÓËÔĚ×ĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđď Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńďô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ď Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ îô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ î ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňěňěňě ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňîňîňî Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Îîý­¸±© ·° ±­°ş ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďéîňíđňîěňîńîěô ß®»ż îě Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňîňîňîô Ň»¬©±®µ ̧°» ŢÎŃßÜÝßÍĚô ݱ­¬ć ď Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ŢÜÎô Đ®·±®·¬§ ď Ü»­·ą˛ż¬»Ľ ᫬»® ř×Ü÷ ďđňěňěňěô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňîěňě Ţż˝µ«° Ü»­·ą˛ż¬»Ľ ®±«¬»® ř×Ü÷ ďđňîňîňîô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňîěňî Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđç Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ îńîô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ď Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňěňěňě řÜ»­·ą˛ż¬»Ľ ᫬»®÷ Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Í»®·ż´đńđńđňď ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďđňîńîěô ß®»ż îě Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňîňîňîô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđí Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńďô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ 154

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ď Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňďňďňď Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Îěý­¸±© ·° ±­°ş ·˛¬»®şż˝»­ Úż­¬Ű¬¸»®˛»¬đńđ ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďéîňíđňîěňěńîěô ß®»ż îě Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňěňěňěô Ň»¬©±®µ ̧°» ŢÎŃßÜÝßÍĚô ݱ­¬ć ď Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ÜÎô Đ®·±®·¬§ ď Ü»­·ą˛ż¬»Ľ ᫬»® ř×Ü÷ ďđňěňěňěô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňîěňě Ţż˝µ«° Ü»­·ą˛ż¬»Ľ ®±«¬»® ř×Ü÷ ďđňîňîňîô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňîěňî Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđě Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ îńîô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ îô łż¨·ł«ł ·­ î Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňîňîňî řŢż˝µ«° Ü»­·ą˛ż¬»Ľ ᫬»®÷ Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Í»®·ż´đńđńđňď ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďđňěńîěô ß®»ż îě Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňěňěňěô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđč Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńďô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ îô łż¨·ł«ł ·­ î Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňďňďňď Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Îďý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňďňďňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďňď ďéîňíđňďđňę

ßÜĘ Î±«¬»® ďđňďňďňď ďéîňíđňďđňę

ßą» ďéč ďčě

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđî đ¨đđěéęę î đ¨čđđđđđđę đ¨đđŰíđÜ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďďđňđ ďđňďňďďđňď ďđňďňďďíňđ ďéîňíđňďíňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďđňďňďňď ďđňďňďňď ďđňďňďňď ďđňďňďňď ďđňďňďňď

ßą» çě ďďí ďčě ďěç čě

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđÜďęě đ¨đđÝîÚî đ¨đđîŰěë đ¨đđŰčîŰ đ¨đđęÚçÝ

᫬»® Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďđňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďđňďňďňď ďçîňďęčňíňď

ßą» ďęě ďëé

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđí đ¨đđěŰÜď î đ¨čđđđđđđî đ¨đđěçčÜ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż í÷

© 2009 Cisco Systems, Inc.

Lab Guide

155

Ô·˛µ ×Ü ďđňďňďďđňđ ďđňďňďďđňď ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďđňďňďňď ďđňďňďňď ďđňďňďňď ďđňďňďňď ďđňďňďňď

ßą» çě ďďí ďéç ďęç čě

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđÜďęě đ¨đđÝîÚî đ¨đđđÜęí đ¨đđđßďđ đ¨đđęÚçÝ

᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďđňďňďňď ďđňîňîňî ďđňěňěňě

ßą» čď íę íę

Í»Żý đ¨čđđđđđđë đ¨čđđđđđđí đ¨čđđđđđđí

ݸ»˝µ­«ł đ¨đđíéßß đ¨đđÜÚÝě đ¨đđÝíÜđ

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» íę

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďđňďňďňď ďđňďňďňď ďđňďňďňď ďđňďňďňď

ßą» ďčě ďčď ďéď ďëď

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđîŰěë đ¨đđđÜęí đ¨đđđßďđ đ¨đđŰčîŰ

Îîý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňîňîňî÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďđňďňďňď ďđňîňîňî ďđňěňěňě

ßą» îđî ďëë ďëę

Í»Żý đ¨čđđđđđđë đ¨čđđđđđđí đ¨čđđđđđđí

ݸ»˝µ­«ł đ¨đđíéßß đ¨đđÜÚÝě đ¨đđÝíÜđ

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ďëę

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďđňďňďňď ďđňďňďňď ďđňďňďňď ďđňďňďňď

ßą» íđë íđđ îçđ îéđ

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđîŰěë đ¨đđđÜęí đ¨đđđßďđ đ¨đđŰčîŰ

Îěý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňěňěňě÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďđňďňďňď ďđňîňîňî ďđňěňěňě

ßą» ííę îçđ îčç

Í»Żý đ¨čđđđđđđë đ¨čđđđđđđí đ¨čđđđđđđí

ݸ»˝µ­«ł đ¨đđíéßß đ¨đđÜÚÝě đ¨đđÝíÜđ

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» îčç

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ 156

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďđňďňďňď ďđňďňďňď ďđňďňďňď ďđňďňďňď

ßą» ěíč ěíí ěîí ěđí

Îďý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô Ń ďéîňíđňîěňđ ĹďďđńęëĂ Ş·ż ĹďďđńęëĂ Ş·ż Ń ďéîňíđňďđňđ ĹďďđńęëĂ Ş·ż Ń ďéîňíđňďíňđ ĹďďđńęëĂ Ş·ż

í ­«ľ˛»¬­ ďđňďňďďđňěô ďđňďňďďđňîô ďđňďňďďęňęô ďđňďňďďíňíô

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

đđćđđćíéô đđćđđćíéô đđćđîćëęô đđćđîćíęô

ݸ»˝µ­«ł đ¨đđîŰěë đ¨đđđÜęí đ¨đđđßďđ đ¨đđŰčîŰ

Í»®·ż´đńđńđňď Í»®·ż´đńđńđňď Í»®·ż´đńđńđňďďę Í»®·ż´đńđńđňî

Îîý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđîćěîô Í»®·ż´đńđńđňď Ń ×ß ďéîňíđňďíňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđîćěîô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđîćěîô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďíňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđîćěîô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđîćěîô Í»®·ż´đńđńđňď Îěý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđěćěčô Í»®·ż´đńđńđňď Ń ×ß ďéîňíđňďíňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđěćěčô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđěćěčô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďíňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđěćěčô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđěćěčô Í»®·ż´đńđńđňď

5. Verify the OSPF configuration on router R3 and connectivity to the BBR2 LAN segment 172.30.10.0/24 from routers R1 and R4. Îíý­¸±© ·° ±­°ş ·˛¬»®şż˝»­ Úż­¬Ű¬¸»®˛»¬đńđ ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďéîňíđňďíňíńîěô ß®»ż í Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďçîňďęčňíňďô Ň»¬©±®µ ̧°» ŢÎŃßÜÝßÍĚô ݱ­¬ć ď Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ÜÎô Đ®·±®·¬§ ď Ü»­·ą˛ż¬»Ľ ᫬»® ř×Ü÷ ďçîňďęčňíňďô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňďíňí ұ ľż˝µ«° Ľ»­·ą˛ż¬»Ľ ®±«¬»® ±˛ ¬¸·­ ˛»¬©±®µ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđî Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ îńîô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ đô łż¨·ł«ł ·­ đ Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ đô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ đ Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Í»®·ż´đńđńđňî ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďíňíńîěô ß®»ż í Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďçîňďęčňíňďô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđí Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńďô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ď Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňďňďňď Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷

© 2009 Cisco Systems, Inc.

Lab Guide

157

Îíý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďçîňďęčňíňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďđňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďđňďňďňď ďçîňďęčňíňď

ßą» íęď íëî

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđí đ¨đđěŰÜď î đ¨čđđđđđđî đ¨đđěçčÜ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďđňďňďďđňđ ďđňďňďďđňď ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďđňďňďňď ďđňďňďňď ďđňďňďňď ďđňďňďňď ďđňďňďňď

ßą» îçď íďđ íéë íęë îčď

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđÜďęě đ¨đđÝîÚî đ¨đđđÜęí đ¨đđđßďđ đ¨đđęÚçÝ

Îíý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňîěňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďíňďô đđćđěćěěô Í»®·ż´đńđńđňî Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďíňďô đđćđëćěçô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ô î łż­µ­ Ń ×ß ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďíňďô đđćđëćďîô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďđňđńîě ĹďďđńďçîĂ Ş·ż ďđňďňďďíňďô đđćđěćëěô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďíňďô đđćđëćěçô Í»®·ż´đńđńđňî Îďý°·˛ą ďéîňíđňďđňę ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňíđňďđňęô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ëęńëęńęđ ł­ Îěý°·˛ą ďéîňíđňďđňę ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňíđňďđňęô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďíńďďę ł­

6. Tuning OSPF operation. 6.1. Use the following example to configure router R1 in this lab: Îďý ®±«¬»® ±­°ş ď ˛»·ą¸ľ±® ďđňďňďďđňî ˝±­¬ ďđ

6.2. Verify that router R1 prefers the path via router R2 toward the 172.30.24.0/24 segment: Îďý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô Ń ďéîňíđňîěňđ ĹďďđńďďĂ Ş·ż Ń ďéîňíđňďđňđ ĹďďđńęëĂ Ş·ż Ń ďéîňíđňďíňđ ĹďďđńęëĂ Ş·ż

í ­«ľ˛»¬­ ďđňďňďďđňîô đđćđđćëđô Í»®·ż´đńđńđňď ďđňďňďďęňęô đđćđđćëđô Í»®·ż´đńđńđňďďę ďđňďňďďíňíô đđćđđćëđô Í»®·ż´đńđńđňî

Îďý°·˛ą ďéîňíđňîěňî ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňíđňîěňîô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ëęńëęńęđ ł­ Îďý°·˛ą ďéîňíđňîěňě ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňíđňîěňěô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć 158

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ëęńëęńęđ ł­ Îďý¬®ż˝»®±«¬» ďéîňíđňîěňě ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďéîňíđňîěňě ď ďđňďňďďđňî îč ł­»˝ îč ł­»˝ îč ł­»˝ î ďéîňíđňîěňě îč ł­»˝ îč ł­»˝ ö

7. Manipulate the router ID. 7.1. Use the following example to configure router R1 in this lab: Îďý ®±«¬»® ±­°ş ď ®±«¬»®ó·Ľ ďňďňďňď Îďý˝´»ż® ·° ±­°ş ď °®±˝»­­

7.2. Verify that router R1 prefers the path via router R2 toward the 172.30.24.0/24 segment: Îďý­¸±© ·° ±­°ş ᫬·˛ą Đ®±˝»­­ ţ±­°ş ďţ ©·¬¸ ×Ü ďđňďňďňď ͬż®¬ ¬·ł»ć ë©îĽô Ě·ł» »´ż°­»Ľć đđćďîćđéňîďę Í«°°±®¬­ ±˛´§ ­·˛ą´» ĚŃÍřĚŃÍđ÷ ®±«¬»­ Í«°°±®¬­ ±°żŻ«» ÔÍß Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ Í«°°±®¬­ ż®»ż ¬®ż˛­·¬ ˝ż°żľ·´·¬§ ׬ ·­ ż˛ ż®»ż ľ±®Ľ»® ®±«¬»® ᫬»® ·­ ˛±¬ ±®·ą·˛ż¬·˛ą ®±«¬»®óÔÍß­ ©·¬¸ łż¨·ł«ł ł»¬®·˝ ײ·¬·ż´ ÍĐÚ ­˝¸»Ľ«´» Ľ»´ż§ ëđđđ ł­»˝­ Ó·˛·ł«ł ¸±´Ľ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ Óż¨·ł«ł ©ż·¬ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ ײ˝®»ł»˛¬ż´óÍĐÚ Ľ·­żľ´»Ľ Ó·˛·ł«ł ÔÍß ·˛¬»®Şż´ ë ­»˝­ Ó·˛·ł«ł ÔÍß ż®®·Şż´ ďđđđ ł­»˝­ ÔÍß ą®±«° °ż˝·˛ą ¬·ł»® îěđ ­»˝­ ײ¬»®şż˝» ş´±±Ľ °ż˝·˛ą ¬·ł»® íí ł­»˝­ 묮ż˛­ł·­­·±˛ °ż˝·˛ą ¬·ł»® ęę ł­»˝­ Ň«łľ»® ±ş »¨¬»®˛ż´ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ±°żŻ«» ßÍ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ż®»ż­ ·˛ ¬¸·­ ®±«¬»® ·­ íň í ˛±®łż´ đ ­¬«ľ đ ˛­­ż Ň«łľ»® ±ş ż®»ż­ ¬®ż˛­·¬ ˝ż°żľ´» ·­ đ ۨ¬»®˛ż´ ş´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż ŢßÝŐŢŃŇŰřđ÷ Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđîćëęňéîě żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ í ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß éň ݸ»˝µ­«ł Í«ł đ¨đěŰîçî Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż í Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđîćëęňéîě żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ í ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß éň ݸ»˝µ­«ł Í«ł đ¨đîŢéÚÜ Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ © 2009 Cisco Systems, Inc.

Lab Guide

159

Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż îě Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđîćëęňéîě żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ í ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß čň ݸ»˝µ­«ł Í«ł đ¨đëěŢéç Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ Îďý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü Đ®· ͬż¬» ďéîňíđňďđňę đ ÚËÔÔń ďçîňďęčňíňď đ ÚËÔÔń ďđňěňěňě đ ÚËÔÔń ďđňîňîňî đ ÚËÔÔń

ó ó ó ó

Ü»żĽ Ě·ł» đđćđđćíě đđćđđćíč đđćđđćíď đđćđđćíí

߼Ľ®»­­ ďđňďňďďęňę ďđňďňďďíňí ďđňďňďďđňě ďđňďňďďđňî

ײ¬»®şż˝» Í»®·ż´đńđńđňďďę Í»®·ż´đńđńđňî Í»®·ż´đńđńđňď Í»®·ż´đńđńđňď

Îďý­¸±© ·° ±­°ş ·˛¬»®şż˝»­ Í»®·ż´đńđńđňďďę ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďęňďńîěô ß®»ż đ Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňďňďňďô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđď Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńíô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ îô łż¨·ł«ł ·­ ë Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďéîňíđňďđňę Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Í»®·ż´đńđńđňî ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďíňďńîěô ß®»ż í Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňďňďňďô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđď Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńîô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ îô łż¨·ł«ł ·­ ë Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďçîňďęčňíňď Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Í»®·ż´đńđńđňď ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďđňďńîěô ß®»ż îě Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňďňďňďô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁÓËÔĚ×ĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁÓËÔĚ×ĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđď Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńďô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ě Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ îô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ î ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňěňěňě 160

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňîňîňîô ˝±­¬ ·­ ďđ Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Îďý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňďňďňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďňď ďéîňíđňďđňę

ßÜĘ Î±«¬»® ďđňďňďňď ďéîňíđňďđňę

ßą» ëę ëé

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđí đ¨đđěëęé î đ¨čđđđđđđč đ¨đđÜÚđÚ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďďđňđ ďđňďňďďđňď ďđňďňďďíňđ ďéîňíđňďíňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďđňďňďňď ďđňďňďňď ďđňďňďňď ďđňďňďňď ďđňďňďňď

ßą» ěé ëî ëî ěé ěé

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđŢíŢč đ¨đđÝđÚí đ¨đđîÝěę đ¨đđŰčîŰ đ¨đđëďÚđ

᫬»® Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďđňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďđňďňďňď ďçîňďęčňíňď

ßą» ëę ëé

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđě đ¨đđěÝÜî î đ¨čđđđđđđě đ¨đđěëčÚ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďđňďňďďđňđ ďđňďňďďđňď ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďđňďňďňď ďđňďňďňď ďđňďňďňď ďđňďňďňď ďđňďňďňď

ßą» ěé ëî ëî ěé ěé

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđŢíŢč đ¨đđÝđÚí đ¨đđđŢęě đ¨đđđßďđ đ¨đđëďÚđ

᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďđňďňďňď ďđňîňîňî ďđňěňěňě

ßą» ëę ěěé ěěč

Í»Żý đ¨čđđđđđđé đ¨čđđđđđđí đ¨čđđđđđđí

ݸ»˝µ­«ł đ¨đđÜčíÜ đ¨đđÜÚÝě đ¨đđÝíÜđ

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ěěč

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďđňďňďňď ďđňďňďňď ďđňďňďňď ďđňďňďňď

ßą» ëî ëî ěç ěç

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđîÝěę đ¨đđđŢęě đ¨đđđßďđ đ¨đđŰčîŰ

8. Manipulation using OSPF adjacencies. 8.1. Use the following example to configure router R3 in this lab: Îíý ®±«¬»® ±­°ş ď °ż­­·Ş»ó·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ

8.2. Verify that router R3 did not establish adjacency, and that router R3 stopped trying to establish adjacency, on the LAN segment:

© 2009 Cisco Systems, Inc.

Lab Guide

161

Îíý­¸±© ·° ±­°ş ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ Úż­¬Ű¬¸»®˛»¬đńđ ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďéîňíđňďíňíńîěô ß®»ż í Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďçîňďęčňíňďô Ň»¬©±®µ ̧°» ŢÎŃßÜÝßÍĚô ݱ­¬ć ď Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ÜÎô Đ®·±®·¬§ ď Ü»­·ą˛ż¬»Ľ ᫬»® ř×Ü÷ ďçîňďęčňíňďô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňďíňí ұ ľż˝µ«° Ľ»­·ą˛ż¬»Ľ ®±«¬»® ±˛ ¬¸·­ ˛»¬©±®µ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ ұ Ř»´´±­ řĐż­­·Ş» ·˛¬»®şż˝»÷ Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ îńîô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ đô łż¨·ł«ł ·­ đ Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ đô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ đ Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷

162

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

-------- The page intentionally left blank. --------

© 2009 Cisco Systems, Inc.

Lab Guide

163

Lab 3-3: Configure and Verify OSPF Route Summarization for Interarea and External Routes Complete this lab activity to practice what you learned in the related module.

Activity Objective In this activity, you will use correct commands, tools, and steps to configure and verify OSPF multiarea routing and optimize OSPF routing by implementing summarization. After completing this activity, you will be able to meet these objectives: Configure and verify the OSPF operation over LAN and WAN interfaces Configure and verify the OSPF operation using multiple areas Select the required tools and commands to configure OSPF operations Optimize the OSPF operation by implementing route summarization for the internal OSPF routes Optimize the OSPF operation by implementing route summarization for the external OSPF routes Make a list of the configuration and implementation steps Write a verification and test plan to verify the proper implementation and operation according to the expected performance criteria. Verify the configuration and operation by using the proper show and debug commands

Information Packet The figure illustrates what you will accomplish in this activity.

Visual Objective

Visual Objective for Lab 3-3: Configure and Verify OSPF Route Summarization for Interarea and External Routes

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

164

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v 1. 0—LG-13

© 2009 Cisco Systems, Inc.

Implementation Policy The following list details the configuration requirements for all devices in the company network: In this task you will examine IP routing information exchanged by routers configured with the OSPF routing protocol. Routers R1, R2, R3, and R4 are configured with the OSPF routing protocol and are announcing their directly attached networks. Router R4 is also announcing some external OSPF networks into the OSPF routing domain. Learn about the current OSPF configuration, which includes information about the networks that are included in the OSPF routing domain, interfaces where OSPF is enabled, OSPF adjacencies, link-state databases, and OSPF area design. Verify that all the routers have IP connectivity to the advertised networks. Examine the IP routing table, write down the IP networks that are advertised, and determine the IP addressing scheme. Use the information about the OSPF routing configuration and design that you collected in the previous task to optimize OSPF operation. You will optimize the OSPF link-state database, and consequently the IP routing table, by making them smaller using summarization of the 172.30.x.0/24 subnets from router BBR2. Verify that all relevant OSPF adjacencies are still up and running for routers R1, R2, R3, and R4. Router R1 should have running OSPF adjacencies to routers R2, R3, R4, and BBR2. Router R3 should have running OSPF adjacency with router R1 only, whereas routers R2 and R4 should have OSPF adjacency running between themselves and toward router R1. Examine the OSPF link-state databases on routers R1, R2, R3, and R4 and verify that the relevant information is in the databases. Verify that the best path information has been put into the router IP routing tables. Examine the OSPF link-state database and IP routing table on relevant routers to see that the OSPF internal route summarization for the pod IP subnets 172.30.x.0/24 has been applied. Further optimize OSPF routing operation by summarizing the OSPF external routes. Router R3 is redistributing certain 192.168.x.0/24 subnets into the OSPF routing domain. Because it is the only source of that IP routing information, there is no need for other routers to learn and keep information about individual 192.68.x.0/24 subnets. You also know that in the future, additional 192.168.x.0/24 subnets will be added. Verify that all relevant OSPF adjacencies are still up and running for routers R1, R2, R3, and R4. Router R1 should have running OSPF adjacencies to routers R2, R3, R4, and BBR2. Router R3 should have running OSPF adjacency with router R1 only, whereas routers R2 and R4 should have OSPF adjacency running between them and toward router R1. Examine the OSPF link-state databases on routers R1, R2, R3, and R4 and verify that the relevant information is in the databases. Verify that the best path information has been put into the router IP routing tables. Verify that the routing information for the external networks 192.168.x.0/24 is presented as summary information in the OSPF link-state database and in the IP routing tables on relevant routers; in other words, verify that the OSPF required information is really minimized. Verify that all the routers have IP connectivity to the pod external networks 192.268.x.0/24, which were redistributed on router R4.

© 2009 Cisco Systems, Inc.

Lab Guide

165

Device Information The table provides the information specific to each switch in the network: Device Name

Role

R1

POD router

R2

POD router

R3

POD router

R4

POD router

BBR2

Backbone router

Command List The table describes the commands that are used in this activity. Command

Description

router ospf 1

Turns on OSPF; the process number is not communicated to other routers

show ip ospf interface

Displays information about interfaces configured for OSPF

show ip ospf neighbor

Displays a list of OSPF neighbors

show ip ospf database

Displays information about the OSPF database

show ip route [ospf]

Displays the entire IP routing table or OSPF routes only

area range

Consolidates and summarizes routes at an area boundary

summary-address (OSPF)

Creates an aggregate address for OSPF

Ping

Diagnoses basic network connectivity

Required Resources These are the resources and equipment that are required to complete this activity: A PC that is connected to an on-site laboratory or a PC with an Internet connection if remote laboratory equipment must be accessed A terminal server that is connected to the console port of each laboratory device, if using a remote laboratory Core and access switches in your pod

166

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Job Aids These are the job aids for this lab activity: Value

Location

Blank implementation requirements list

Task 1

Blank implementation and verification plan form

Task 2

Blank verification notes form

Task 3

Alternate resources and solutions form

End of this lab

Implementation requirements hints

“Hints” section at the end of this lab

Implementation and verification plan hints

“Hints” section at the end of this lab

Solution configuration answer key (step-bystep procedure)

Configuration section at the end of this lab

© 2009 Cisco Systems, Inc.

Lab Guide

167

Task 1: Establish an Implementation Requirements List The first step in your configuration deployment is to establish a list of what is needed in order for you to configure each device; for example, device names, trunk encapsulation types, and so on. Use the following table, the visual objective at the beginning of this lab, the implementation policy, and the device information to create your implementation requirements list. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Device

168

Implementation Requirement

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

-------- The page intentionally left blank. --------

© 2009 Cisco Systems, Inc.

Lab Guide

169

Task 2: Create an Implementation and Verification Plan The second step in your configuration deployment is to establish a task list of the items that must be configured on each device, and in what order. Use the following table and the visual objective at the beginning of this lab to create your implementation and verification plan. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Complete

170

Device

Order

Implementing Cisco IP Routing (ROUTE) v1.0

Values and Items to Implement

Verification Method and Expected Results

© 2009 Cisco Systems, Inc.

Complete

© 2009 Cisco Systems, Inc.

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Lab Guide

171

Task 3: Implement and Verify Now that you have collected all the requirements and planned your implementation, you are ready to connect to the remote lab and implement your solution. Do not forget to save. Once your solution is implemented, you need to verify that your configuration is working and fulfills all the requirements specified by the customer. Keep in mind that once you leave the company, a network specialist will verify your configuration. Your ability to implement the solution according to the customer specifications will determine whether you get the job or not. Use the following area to record your notes and document the verifications you conducted to ensure that your solution is complete. If you are unsure about the verification steps, use the information provided in the “Hints” section at the end of this lab. Student Notes: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ 172

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

© 2009 Cisco Systems, Inc.

Lab Guide

173

Alternate Resources and Solutions Other groups may have implemented a solution that is different from yours. These will be discussed during the debriefing period that will follow this lab. Use the following space to document other possible solutions for your reference. __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ 174

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

© 2009 Cisco Systems, Inc.

Lab Guide

175

Hints You are encouraged to complete the labs using your knowledge. However, this section contains a series of hints to aid your completion of the lab.

Lab 3-3 Hint Sheet: Configure and Verify OSPF Route Summarization for Interarea and External Routes Implementation Requirements To facilitate the configuration of your network, Task 1 asks you to create an implementation requirements list. This list details the elements you need in order to develop an implementation plan. The following is an example of such a list: Device

Implementation Requirement

Hint

ALL

Identify the networks that are advertised by all routers.

Lab

ALL

Identify the existing OSPF configuration.

Lab

ALL

Identify the subnets that can be summarized and define a summary address.

Lab

Implementation and Verification Plan In Task 2, you will create an implementation and verification plan. Although there are several ways to set up this plan, the following tasks must be completed: Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1–R4

1

Load the initial configuration.

All pod routers must be preloaded with the initial configuration for the lab.

Step 1

R1–R4

2

Examine the OSPF routing configuration on all routers. First explore the OSPF adjacencies to gain insight into how OSPF is deployed in the network. Also observe the OSPF area configuration in order to learn the OSPF architecture and topology.

Step 2.1

Verify the router R1, R2, R3, and R4 IP routing tables to see whether the correct information was put into the routing tables.

2.2

R1–R4

176

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1

Apply OSPF internal route summarization for the IP subnet 172.30.10.0/24 received from router BBR1. Summarize the networks in summary route 172.30.0.0/16, which is announced into nonbackbone OSPF areas.

Examine the OSPF link-state databases on all routers and verify that the relevant information is in the databases. Verify that the OSPF internal route summarization is applied for the pod IP 172.30.x.0/24 subnets.

Step 3

R3

Apply the appropriate OSPF configuration to summarize the external 192.168.x.0/24 subnets, which are redistributed and injected into the OSPF domain. Because you know that additional 192.168.x.0/24 subnets will be added in the future, apply the summarization so that all 192.168.x.0/24 subsets are summarized with one command only and that the OSPF routing optimization is maximized.

Examine the OSPF link-state database and IP routing table on all routers to verify that the relevant information is present. The routing information for the external 192.168.x.0/24 networks is presented as summary information in the OSPF link-state database and therefore in the IP routing tables on relevant routers.

Step 4

Verify that all the external 192.268.x.0/24 networks, which are redistributed on router R3, are reachable from router R4.

Step-by-Step Procedure for Implementation and Verification 1. Load the initial configuration on all devices in your lab. 1.1. The instructor will provide guidelines for changing the initial configuration. 2. Examine the OSPF routing information. 2.1. Examine the OSPF adjacencies and OSPF link-state database to gain insight into how OSPF is deployed in the network. Îďý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďéîňíđňďđňę ďçîňďęčňíňď ďđňěňěňě ďđňîňîňî

Đ®· đ đ đ đ

ͬż¬» ÚËÔÔń ÚËÔÔń ÚËÔÔń ÚËÔÔń

ó ó ó ó

Ü»żĽ Ě·ł» đđćđđćíč đđćđđćíî đđćđđćíë đđćđđćíé

߼Ľ®»­­ ďđňďňďďęňę ďđňďňďďíňí ďđňďňďďđňě ďđňďňďďđňî

ײ¬»®şż˝» Í»®·ż´đńđńđňďďę Í»®·ż´đńđńđňî Í»®·ż´đńđńđňď Í»®·ż´đńđńđňď

Îďý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďňďňďňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďňďňďňď © 2009 Cisco Systems, Inc.

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ďěđč

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđë đ¨đđđčŢě î Lab Guide

177

ďéîňíđňďđňę

ďéîňíđňďđňę

ďěíđ

đ¨čđđđđçßÜ đ¨đđÝÜéŢ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďíňđ ďéîňíđňďíňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďěđí čí ęě ďíčí ďíéí čí

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđďěßß đ¨đđęŰěë đ¨đđęěěÝ đ¨đđéÚÚÝ đ¨đđíßŰë đ¨đđßîßč

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ďíéí

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđíčé

᫬»® Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď ďçîňďęčňíňď

ßą» ďíčí ďěđč

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđę đ¨đđđÚîđ î đ¨čđđđđđđě đ¨đđçÚíÝ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďěîě ďđí čë ďěîç ďěîç ďđí

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđďěßß đ¨đđęŰěë đ¨đđęěěÝ đ¨đđëŰďŢ đ¨đđëŢÝé đ¨đđßîßč

᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» čč ďđę čę

Í»Żý đ¨čđđđđđđę đ¨čđđđđđđë đ¨čđđđđđđë

ݸ»˝µ­«ł đ¨đđßďčé đ¨đđŰçÚÚ đ¨đđďîÝë

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ěéí

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďěđë ďěíď ďěíď ďíçë

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđéÚÚÝ đ¨đđëŰďŢ đ¨đđëŢÝé đ¨đđíßŰë

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ďíçë

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđíčé

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď

ßą» ďëđď ďëđď ďëđî

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđđěÝě đ¨đđÚčÝŰ đ¨đđŰÜÜč

Ěżą đ đ đ

Îîý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü 178

Đ®·

ͬż¬»

Implementing Cisco IP Routing (ROUTE) v1.0

Ü»żĽ Ě·ł»

߼Ľ®»­­

ײ¬»®şż˝» © 2009 Cisco Systems, Inc.

ďđňěňěňě ďňďňďňď

ď đ

ÚËÔÔńÜÎ ÚËÔÔń ó

đđćđđćíč đđćđđćíđ

ďéîňíđňîěňě ďđňďňďďđňď

Úż­¬Ű¬¸»®˛»¬đńđ Í»®·ż´đńđńđňď

Îîý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňîňîňî÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» čëç číę éëđ

Í»Żý đ¨čđđđđđđí đ¨čđđđđđđë đ¨čđđđđđđë

ݸ»˝µ­«ł đ¨đđßéčě đ¨đđíđéŢ đ¨đđďěčé

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ďëîé

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđî đ¨đđÚŰďé

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» čëç čëč čëč čëč

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđéÜÚÜ đ¨đđëÝďÝ đ¨đđëçÝč đ¨đđíčŰę

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ęđë

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđî đ¨đđđďčč

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď

ßą» ëčë ëčë ëčě

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđđîÝë đ¨đđÚęÝÚ đ¨đđŰŢÜç

Ěżą đ đ đ

Îíý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďňďňďňď

Đ®· đ

ͬż¬» ÚËÔÔń

ó

Ü»żĽ Ě·ł» đđćđđćíç

߼Ľ®»­­ ďđňďňďďíňď

ײ¬»®şż˝» Í»®·ż´đńđńđňî

Îíý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďçîňďęčňíňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď ďçîňďęčňíňď

ßą» ďëďę ďëďç

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđę đ¨đđđÚîđ î đ¨čđđđđđđě đ¨đđçÚíÝ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďëíę îďę ďçč ďëěď ďëěď îďę

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđďěßß đ¨đđęŰěë đ¨đđęěěÝ đ¨đđëŰďŢ đ¨đđëŢÝé đ¨đđßîßč

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ © 2009 Cisco Systems, Inc.

ßÜĘ Î±«¬»® ďçîňďęčňíňď

ßą» ďęďď

Í»Żý ݸ»˝µ­«ł Ěżą đ¨čđđđđđđď đ¨đđđěÝě đ Lab Guide

179

ďçîňďęčňîňđ ďçîňďęčňíňđ

ďçîňďęčňíňď ďçîňďęčňíňď

ďęďď ďęîç

đ¨čđđđđđđď đ¨đđÚčÝŰ đ đ¨čđđđđđđď đ¨đđŰÜÜč đ

Îěý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňîňîňî ďňďňďňď

Đ®· ď đ

ͬż¬» ÚËÔÔńŢÜÎ ÚËÔÔń ó

Ü»żĽ Ě·ł» đđćđđćíč đđćđđćíç

߼Ľ®»­­ ďéîňíđňîěňî ďđňďňďďđňď

ײ¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ Í»®·ż´đńđńđňď

Îěý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňěňěňě÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» çđđ čéç éçđ

Í»Żý đ¨čđđđđđđí đ¨čđđđđđđë đ¨čđđđđđđë

ݸ»˝µ­«ł đ¨đđßéčě đ¨đđíđéŢ đ¨đđďěčé

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ďëęé

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđî đ¨đđÚŰďé

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» çđđ çđđ çđđ çđđ

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđéÜÚÜ đ¨đđëÝďÝ đ¨đđëçÝč đ¨đđíčŰę

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ęěę

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđî đ¨đđđďčč

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď

ßą» ęîę ęîę ęîę

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđđîÝë đ¨đđÚęÝÚ đ¨đđŰŢÜç

Ěżą đ đ đ

2.2. Verify that the correct information was added to the router R1, R2, R3, and R4 IP routing tables. Îďý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ďéîňíđňîěňđ ĹďďđńďďĂ Ş·ż ďđňďňďďđňîô đđćđěćëçô Í»®·ż´đńđńđňď Ń ďéîňíđňďđňđ ĹďďđńęëĂ Ş·ż ďđňďňďďęňęô đđćîéćîéô Í»®·ż´đńđńđňďďę Ń ďéîňíđňďíňđ ĹďďđńęëĂ Ş·ż ďđňďňďďíňíô đđćîęćëéô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňěńíî ĹďďđńďďĂ Ş·ż ďđňďňďďđňîô đđćđěćëçô Í»®·ż´đńđńđňď Ń ďđňďňďďđňîńíî ĹďďđńďđĂ Ş·ż ďđňďňďďđňîô đđćđěćëçô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđěćëçô Í»®·ż´đńđńđňî Ń Űî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđěćëçô Í»®·ż´đńđńđňî Ń Űî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđěćëçô Í»®·ż´đńđńđňî Îîý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđëćěëô Í»®·ż´đńđńđňď Ń ×ß ďéîňíđňďíňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđëćěëô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňěńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňěô đđćđëćěëô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđëćěëô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďíňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđëćěëô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđëćěëô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđëćěëô Í»®·ż´đńđńđňď 180

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ń Űî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđëćěëô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđëćěëô Í»®·ż´đńđńđňď Îíý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňîěňđ ĹďďđńéëĂ Ş·ż ďđňďňďďíňďô đđćđęćíçô Í»®·ż´đńđńđňî Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďíňďô đđćîčćďěô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ×ß ďđňďňďďđňěńíî ĹďďđńéëĂ Ş·ż ďđňďňďďíňďô đđćđęćîďô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďíňďô đđćîčćďěô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďđňîńíî ĹďďđńéěĂ Ş·ż ďđňďňďďíňďô đđćđęćíçô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďíňďô đđćîčćďěô Í»®·ż´đńđńđňî Îěý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđęćíđô Í»®·ż´đńđńđňď Ń ×ß ďéîňíđňďíňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđęćíđô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđęćíđô Í»®·ż´đńđńđňď Ń ďđňďňďďđňîńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňîô đđćđęćíđô Úż­¬Ű¬¸»®˛»¬đńđ Ń ×ß ďđňďňďďíňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđęćíđô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđęćíđô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđęćíđô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđęćíđô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđęćíđô Í»®·ż´đńđńđňď

3. Summarizing the OSPF internal routes. 3.1. Use the following example to configure router R1 in this lab: Îďý ®±«¬»® ±­°ş ď ż®»ż 𠮿˛ą» ďéîňíđňđňđ îëëňîëëňđňđ

3.2. Verify the OSPF link-state databases and IP routing tables. Îďý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďňďňďňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďňďňďňď ďéîňíđňďđňę

ßÜĘ Î±«¬»® ďňďňďňď ďéîňíđňďđňę

ßą» ďéčë ďčđé

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđë đ¨đđđčŢě î đ¨čđđđđçßÜ đ¨đđÝÜéŢ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďíňđ ďéîňíđňďíňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďéčď ěęď ěěî ďéęđ ďéëđ ěęď

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđďěßß đ¨đđęŰěë đ¨đđęěěÝ đ¨đđéÚÚÝ đ¨đđíßŰë đ¨đđßîßč

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ďéëđ

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđíčé

᫬»® Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď ďçîňďęčňíňď

ßą» ďéęđ ďéčč

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđę đ¨đđđÚîđ î đ¨čđđđđđđě đ¨đđçÚíÝ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż í÷

© 2009 Cisco Systems, Inc.

Lab Guide

181

Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďęňđ ďéîňíđňđňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďčđě ěčí ěęë ďčđç íí ěčí

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđďěßß đ¨đđęŰěë đ¨đđęěěÝ đ¨đđëŰďŢ đ¨đđÝçęí đ¨đđßîßč

᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» ěęč ěčę ěęę

Í»Żý đ¨čđđđđđđę đ¨čđđđđđđë đ¨čđđđđđđë

ݸ»˝µ­«ł đ¨đđßďčé đ¨đđŰçÚÚ đ¨đđďîÝë

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» čëí

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďéçç ďčîě ěč ďéčç

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđéÚÚÝ đ¨đđëŰďŢ đ¨đđÝçęí đ¨đđíßŰë

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ďéčç

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđíčé

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď

ßą» ďčçě ďčçě ďčçę

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđđěÝě đ¨đđÚčÝŰ đ¨đđŰÜÜč

Ěżą đ đ đ

Îďý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńďę ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ô î łż­µ­ Ń ďéîňíđňîěňđńîě ĹďďđńďďĂ Ş·ż ďđňďňďďđňîô đđćđďćěîô Í»®·ż´đńđńđňď Ń ďéîňíđňđňđńďę ·­ ż ­«łłż®§ô đđćđďćěîô Ň«´´đ Ń ďéîňíđňďđňđńîě ĹďďđńęëĂ Ş·ż ďđňďňďďęňęô đđćđďćěîô Í»®·ż´đńđńđňďďę Ń ďéîňíđňďíňđńîě ĹďďđńęëĂ Ş·ż ďđňďňďďíňíô đđćđďćěîô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňěńíî ĹďďđńďďĂ Ş·ż ďđňďňďďđňîô đđćđďćěîô Í»®·ż´đńđńđňď Ń ďđňďňďďđňîńíî ĹďďđńďđĂ Ş·ż ďđňďňďďđňîô đđćđďćěîô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđďćěîô Í»®·ż´đńđńđňî Ń Űî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđďćěîô Í»®·ż´đńđńđňî Ń Űî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđďćěîô Í»®·ż´đńđńđňî Îîý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňîňîňî÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» ďíçî ďíęç ďîčî

Í»Żý đ¨čđđđđđđí đ¨čđđđđđđë đ¨čđđđđđđë

ݸ»˝µ­«ł đ¨đđßéčě đ¨đđíđéŢ đ¨đđďěčé

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě 182

ßÜĘ Î±«¬»® ďđňěňěňě

Implementing Cisco IP Routing (ROUTE) v1.0

ßą» îđ

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđí đ¨đđÚÝďč © 2009 Cisco Systems, Inc.

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďíçî ďíçď çç ďéë

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđéÜÚÜ đ¨đđëÝďÝ đ¨đđÝçęí đ¨đđíßŰë

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ďďíč

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđî đ¨đđđďčč

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď

ßą» ďďďč ďďďč ďďďé

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđđîÝë đ¨đđÚęÝÚ đ¨đđŰŢÜç

Ěżą đ đ đ

Îîý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńďę ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ô î łż­µ­ Ń ×ß ďéîňíđňđňđńďę ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđîćîçô Í»®·ż´đńđńđňď Ń ×ß ďéîňíđňďíňđńîě ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđçćíîô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňěńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňěô đđćđçćíîô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđçćíîô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďíňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđçćíîô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđçćíîô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđîćîěô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđîćîěô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđîćîěô Í»®·ż´đńđńđňď Îíý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďçîňďęčňíňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď ďçîňďęčňíňď

ßą» ďçíí ę

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđę đ¨đđđÚîđ î đ¨čđđđđđđë đ¨đđçÜíÜ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďęňđ ďéîňíđňđňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďçëî ęíí ęďě ďçëé ďčî ęíí

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđďěßß đ¨đđęŰěë đ¨đđęěěÝ đ¨đđëŰďŢ đ¨đđÝçęí đ¨đđßîßč

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď

ßą» ę ę ďí

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđđîÝë đ¨đđÚęÝÚ đ¨đđŰŢÜç

Ěżą đ đ đ

Îíý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńďę ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ô î łż­µ­ Ń ×ß ďéîňíđňîěňđńîě ĹďďđńéëĂ Ş·ż ďđňďňďďíňďô đđćďďćđëô Í»®·ż´đńđńđňî Ń ×ß ďéîňíđňđňđńďę ĹďďđńďîçĂ Ş·ż ďđňďňďďíňďô đđćđíćíěô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ×ß ďđňďňďďđňěńíî ĹďďđńéëĂ Ş·ż ďđňďňďďíňďô đđćďđćěęô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďíňďô đđćíîćíçô Í»®·ż´đńđńđňî © 2009 Cisco Systems, Inc.

Lab Guide

183

Ń ×ß Ń ×ß

ďđňďňďďđňîńíî ĹďďđńéěĂ Ş·ż ďđňďňďďíňďô đđćďďćđëô Í»®·ż´đńđńđňî ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďíňďô đđćíîćíçô Í»®·ż´đńđńđňî

Îěý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňěňěňě÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» ďěěë ďěîě ďííë

Í»Żý đ¨čđđđđđđí đ¨čđđđđđđë đ¨čđđđđđđë

ݸ»˝µ­«ł đ¨đđßéčě đ¨đđíđéŢ đ¨đđďěčé

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» éí

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđí đ¨đđÚÝďč

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďěěë ďěěë ďëî îîč

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđéÜÚÜ đ¨đđëÝďÝ đ¨đđÝçęí đ¨đđíßŰë

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ďďçď

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđî đ¨đđđďčč

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď

ßą» ďďéď ďďéď ďďéď

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđđîÝë đ¨đđÚęÝÚ đ¨đđŰŢÜç

Ěżą đ đ đ

Îěý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńďę ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ô î łż­µ­ Ń ×ß ďéîňíđňđňđńďę ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđěćîîô Í»®·ż´đńđńđňď Ń ×ß ďéîňíđňďíňđńîě ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćďďćîëô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćďďćîëô Í»®·ż´đńđńđňď Ń ďđňďňďďđňîńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňîô đđćďďćîëô Úż­¬Ű¬¸»®˛»¬đńđ Ń ×ß ďđňďňďďíňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćďďćîëô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćďďćîëô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđěćďéô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđěćďéô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđěćďéô Í»®·ż´đńđńđňď

4. Summarizing OSPF external routes. 4.1. Use the following example to configure router R3 in this lab: Îíý ®±«¬»® ±­°ş ď ­«łłż®§óżĽĽ®»­­ ďçîňďęčňđňđ îëëňîëëňđňđ

4.2. Verify the OSPF link-state databases and IP routing tables. Îďý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďňďňďňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü 184

ßÜĘ Î±«¬»®

Implementing Cisco IP Routing (ROUTE) v1.0

ßą»

Í»Żý

ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ © 2009 Cisco Systems, Inc.

ďňďňďňď ďéîňíđňďđňę

ďňďňďňď ďéîňíđňďđňę

ďîç îçč

đ¨čđđđđđđę đ¨đđđęŢë î đ¨čđđđđçßŰ đ¨đđÝŢéÝ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďíňđ ďéîňíđňďíňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďîç éçî ééí ďîç ďîç éçî

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđďîßŢ đ¨đđęŰěë đ¨đđęěěÝ đ¨đđéÜÚÜ đ¨đđíčŰę đ¨đđßîßč

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ďîç

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđî đ¨đđđďčč

᫬»® Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď ďçîňďęčňíňď

ßą» ďîç ďéë

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđé đ¨đđđÜîď î đ¨čđđđđđđë đ¨đđçÜíÜ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďęňđ ďéîňíđňđňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďíé čđđ éčî ďíé íëđ čđđ

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđďîßŢ đ¨đđęŰěë đ¨đđęěěÝ đ¨đđëÝďÝ đ¨đđÝçęí đ¨đđßîßč

᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» éčë čđí éčí

Í»Żý đ¨čđđđđđđę đ¨čđđđđđđë đ¨čđđđđđđë

ݸ»˝µ­«ł đ¨đđßďčé đ¨đđŰçÚÚ đ¨đđďîÝë

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ďďéđ

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďěđ ďěđ íëî ďěđ

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđéÜÚÜ đ¨đđëÝďÝ đ¨đđÝçęí đ¨đđíčŰę

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ďěđ

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđî đ¨đđđďčč

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňđňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď

ßą» îí

Í»Żý ݸ»˝µ­«ł Ěżą đ¨čđđđđđđď đ¨đđđÚŢß đ

Îďý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńďę ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ô î łż­µ­ Ń ďéîňíđňîěňđńîě ĹďďđńďďĂ Ş·ż ďđňďňďďđňîô đđćđęćíęô Í»®·ż´đńđńđňď Ń ďéîňíđňđňđńďę ·­ ż ­«łłż®§ô đđćđęćíęô Ň«´´đ © 2009 Cisco Systems, Inc.

Lab Guide

185

Ń Ń

ďéîňíđňďđňđńîě ĹďďđńęëĂ Ş·ż ďđňďňďďęňęô đđćđęćíęô Í»®·ż´đńđńđňďďę ďéîňíđňďíňđńîě ĹďďđńęëĂ Ş·ż ďđňďňďďíňíô đđćđęćíęô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňěńíî ĹďďđńďďĂ Ş·ż ďđňďňďďđňîô đđćđęćíęô Í»®·ż´đńđńđňď Ń ďđňďňďďđňîńíî ĹďďđńďđĂ Ş·ż ďđňďňďďđňîô đđćđęćíęô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňđňđńďę ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđďćđęô Í»®·ż´đńđńđňî Îîý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňîňîňî÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» čëî čęé čěč

Í»Żý đ¨čđđđđđđę đ¨čđđđđđđë đ¨čđđđđđđë

ݸ»˝µ­«ł đ¨đđßďčé đ¨đđŰçÚÚ đ¨đđďîÝë

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ďîíë

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» îđě îđě ěďę îđí

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđéÜÚÜ đ¨đđëÝďÝ đ¨đđÝçęí đ¨đđíčŰę

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» îđí

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđî đ¨đđđďčč

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňđňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď

ßą» čç

Í»Żý ݸ»˝µ­«ł Ěżą đ¨čđđđđđđď đ¨đđđÚŢß đ

Îîý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńďę ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ô î łż­µ­ Ń ×ß ďéîňíđňđňđńďę ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđéćďčô Í»®·ż´đńđńđňď Ń ×ß ďéîňíđňďíňđńîě ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćďěćîďô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňěńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňěô đđćďěćîďô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćďěćîďô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďíňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćďěćîďô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćďěćîďô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňđňđńďę ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđďćěčô Í»®·ż´đńđńđňď Îíý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďçîňďęčňíňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď ďçîňďęčňíňď

ßą» îěé îčí

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđé đ¨đđđÜîď î đ¨čđđđđđđë đ¨đđçÜíÜ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě 186

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď

Implementing Cisco IP Routing (ROUTE) v1.0

ßą» îěé çďđ čçî

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđďîßŢ đ¨đđęŰěë đ¨đđęěěÝ © 2009 Cisco Systems, Inc.

ďđňďňďďęňđ ďéîňíđňđňđ ďéîňíđňîěňđ

ďňďňďňď ďňďňďňď ďňďňďňď

îěé ěęđ çďđ

đ¨čđđđđđđî đ¨đđëÝďÝ đ¨čđđđđđđď đ¨đđÝçęí đ¨čđđđđđđď đ¨đđßîßč

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňđňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď

ßą» ďîç

Í»Żý ݸ»˝µ­«ł Ěżą đ¨čđđđđđđď đ¨đđđÚŢß đ

Îíý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńďę ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ô î łż­µ­ Ń ×ß ďéîňíđňîěňđńîě ĹďďđńéëĂ Ş·ż ďđňďňďďíňďô đđćďëćíěô Í»®·ż´đńđńđňî Ń ×ß ďéîňíđňđňđńďę ĹďďđńďîçĂ Ş·ż ďđňďňďďíňďô đđćđčćđíô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ×ß ďđňďňďďđňěńíî ĹďďđńéëĂ Ş·ż ďđňďňďďíňďô đđćďëćďëô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďíňďô đđćíéćđčô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďđňîńíî ĹďďđńéěĂ Ş·ż ďđňďňďďíňďô đđćďëćíěô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďíňďô đđćíéćđčô Í»®·ż´đńđńđňî Ń ďçîňďęčňđňđńďę ·­ ż ­«łłż®§ô đđćđîćííô Ň«´´đ Îěý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňěňěňě÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» çíč çëë çíě

Í»Żý đ¨čđđđđđđę đ¨čđđđđđđë đ¨čđđđđđđë

ݸ»˝µ­«ł đ¨đđßďčé đ¨đđŰçÚÚ đ¨đđďîÝë

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ďíîď

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» îçđ îçđ ëđí îçđ

Í»Żý đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđéÜÚÜ đ¨đđëÝďÝ đ¨đđÝçęí đ¨đđíčŰę

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» îçđ

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđî đ¨đđđďčč

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňđňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď

ßą» ďéë

Í»Żý ݸ»˝µ­«ł Ěżą đ¨čđđđđđđď đ¨đđđÚŢß đ

Îěý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńďę ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ô î łż­µ­ Ń ×ß ďéîňíđňđňđńďę ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđčćěëô Í»®·ż´đńđńđňď Ń ×ß ďéîňíđňďíňđńîě ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćďëćěéô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćďëćěéô Í»®·ż´đńđńđňď Ń ďđňďňďďđňîńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňîô đđćďëćěéô Úż­¬Ű¬¸»®˛»¬đńđ Ń ×ß ďđňďňďďíňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćďëćěéô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćďëćěéô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňđňđńďę ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđíćďěô Í»®·ż´đńđńđňď Îěý°·˛ą ďçîňďęčňďňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň © 2009 Cisco Systems, Inc.

Lab Guide

187

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňďňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďîńďďę ł­ Îěý°·˛ą ďçîňďęčňîňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňîňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďěńďîđ ł­ Îěý°·˛ą ďçîňďęčňíňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňíňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďîńďďî ł­

188

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

-------- The page intentionally left blank. --------

© 2009 Cisco Systems, Inc.

Lab Guide

189

Lab 3-4: Configure and Verify OSPF Special Area Types Complete this lab activity to practice what you learned in the related module.

Activity Objective In this activity, you will use the correct commands, tools, and steps to configure and verify OSPF multiarea routing and optimize OSPF routing by implementing different OSPF special area types. After completing this activity, you will be able to meet these objectives: Configure and verify the OSPF operation over LAN and WAN interfaces in multiple OSPF areas Optimize the OSPF operation by implementing OSPF database optimization using special OSPF area types. Select the required tools and commands to configure OSPF operations Make a list of configuration and implementation steps Write a verification and test plan to verify the proper implementation and operation according to the expected performance criteria. Verify the configuration and operation by using the proper show and debug commands

Information Packet The figure illustrates what you will accomplish in this activity.

Visual Objective

Visual Objective for Lab 3-4: Configure and Verify OSPF Special Area Types

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

190

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v 1. 0—LG-14

© 2009 Cisco Systems, Inc.

Implementation Policy The following list details the configuration requirements for all devices in the company network: In this task you will examine IP routing information exchanged by routers configured with the OSPF routing protocol. Routers R1, R2, R3, and R4 are configured with the OSPF routing protocol and announce their directly attached networks. Router R4 also announces some external OSPF networks into the OSPF routing domain. Learn about the current OSPF configuration, which includes the information about the networks that are included in the OSPF routing domain, interfaces where OSPF is enabled, OSPF adjacencies, link-state databases, and OSPF area design. Verify that all the routers have IP connectivity to the advertised networks. Examine the IP routing table, write down the IP networks that are advertised, and determine the IP addressing scheme. In this task, you must optimize OSPF routing inside Area 24. Routers R2 and R4 have insufficient CPU and memory resources to cope with the amount of routing information that is advertised in the OSPF domain. You must reduce the size of the OSPF link-state database on routes R2 and R4 to preserve their resources. Verify that OSPF adjacencies in the OSPF domain are operational. Router R1 should have OSPF adjacency with routers R2, R3, R4, and BBR2. Routers R2 and R4 should also have adjacency set between them. Examine the OSPF database on routers R1 and R3 and verify that they still have all the specific information about OSPF internal and external routes of your OSPF domain. Also verify that the IP routing tables are populated with the best paths to all destination networks. Examine the OSPF database on routers R2 and R4 and verify that the size of the database is smaller because they do not hold the specific information about the IP subnets that are external to the OSPF domain; in other words, those that are redistributed somewhere in the OSPF domain. Verify that routers R2 and R4 have the information necessary to reach the external networks. Verify that routers R2 and R4 have IP connectivity to the destinations from the IP subnets that are external to the OSPF domain. In this task you must minimize OSPF link-state database information inside Area 24. Although you optimized OSPF Area 24 operation in the previous task to preserve R2 and R4 resources, you have seen that they still cannot hold all the information that is advertised in the OSPF domain. Therefore, you must further reduce the amount of OSPF information on those routers while preserving the IP connectivity to the destinations located on all networks that are not attached to routers R2 and R4. Verify that OSPF adjacencies in the OSPF domain are operational. Router R1 should have OSPF adjacency with routers R2, R3, R4, and BBR2. Routers R2 and R4 should have additional adjacency set between them. Examine the OSPF database on routers R1 and R3 and verify that they still have all the specific information about OSPF internal and external routes of your OSPF domain. Also verify that the IP routing tables are populated with the best paths to all destination networks. Examine the OSPF databases on routers R2 and R4 and verify that the size of the databases is smaller because they do not hold the specific information about the IP subnets that are external to OSPF Area 24; in other words, those IP networks that are redistributed somewhere in the OSPF domain and those IP networks that are internal to OSPF but are part of other OSPF areas. Verify that routers R2 and R4 have the information necessary to reach all the networks. Verify that routers R2 and R4 have IP connectivity to the destinations from all the IP subnets that are announced in the OSPF domain.

© 2009 Cisco Systems, Inc.

Lab Guide

191

In this task you will have to minimize the OSPF and IP routing information inside Area 3. You have noticed that router R3 does not have sufficient memory capacity to store all the OSPF an IP routing information. In other words, the OSPF link-state database, and consequently the IP routing table, cannot store all the dynamically acquired IP routing information. Verify that OSPF adjacencies in the OSPF domain are operational. Router R1 should have an OSPF adjacency with routers R2, R3, R4, and BBR2. Routers R2 and R4 should have an additional adjacency set between them. Examine the OSPF database on router R1 and verify that it still has all the specific information about the OSPF internal and external routes of your OSPF domain. Also verify that the IP routing table is populated with the best paths to all destination networks. Verify that router R1 can access all the networks that are announced in the OSPF domain. Examine the OSPF databases on routers R2 and R4 and verify that they still have all the specific information about the OSPF internal routes from Area 24, while the information about the other networks is not present, and external routes of your OSPF domain. Also verify that the IP routing table is populated with the proper IP routing information. Verify that routers R2 and R4 can access all the networks that are advertised in the OSPF domain. Examine the OSPF database on router R3 and verify that the database size has been reduced. Verify that the router has the information about all the OSPF Area 3 internal router as well as the external routes that are redistributed in the area. At the same time, the router should not have any information about the routes that are external to OSPF Area 3. Verify that you still have IP connectivity to all networks announced that are announced by OSPF from router R3.

Device Information The table provides the information specific to each switch in the network:

192

Device name

Role

R1

POD router

R2

POD router

R3

POD router

R4

POD router

BBR2

Backbone router

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Command List The table describes the commands that are used in this activity. Command

Description

router ospf 1

Turns on OSPF; the process number is not communicated to other routers

show ip ospf database

Displays information about OSPF database

show ip route [ospf]

Displays whole IP routing table or OSPF routes only

show ip ospf

Displays general information about OSPF routing processes

area stub

Defines an area as a stub area

area nssa

Configures an area as a not-so-stubby area (NSSA)

Ping

Diagnoses basic network connectivity

Required Resources These are the resources and equipment that are required to complete this activity: A PC that is connected to an on-site laboratory or a PC with an Internet connection if remote laboratory equipment must be accessed A terminal server that is connected to the console port of each laboratory device, if using a remote laboratory Core and access switches in your pod

Job Aids These are the job aids for this lab activity: Value

Location

Blank implementation requirements list

Task 1

Blank implementation and verification plan form

Task 2

Blank verification notes form

Task 3

Alternate resources and solutions form

End of this lab

Implementation requirements hints

“Hints” section at the end of this lab

Implementation and verification plan hints

“Hints” section at the end of this lab

Solution configuration answer key (step-bystep procedure)

Configuration section at the end of this lab

© 2009 Cisco Systems, Inc.

Lab Guide

193

Task 1: Establish an Implementation Requirements List The first step in your configuration deployment is to establish a list of what is needed in order for you to configure each device; for example, the device names and trunk encapsulation types. Use the following table, the visual objective at the beginning of this lab, the implementation policy, and the device information to create your implementation requirements list. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Device

194

Implementation Requirement

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

-------- The page intentionally left blank. --------

© 2009 Cisco Systems, Inc.

Lab Guide

195

Task 2: Create an Implementation and Verification Plan The second step in your configuration deployment is to establish a task list of the items that must be configured on each device, and in what order. Use the following table and the visual objective at the beginning of this lab to create your implementation and verification plan. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Complete

196

Device

Order

Values and Items to Implement

Implementing Cisco IP Routing (ROUTE) v1.0

Verification Method and Expected Results

© 2009 Cisco Systems, Inc.

Complete

Device

© 2009 Cisco Systems, Inc.

Order

Values and Items to Implement

Verification Method and Expected Results

Lab Guide

197

Task 3: Implement and Verify Now that you have collected all the requirements and planned your implementation, you are ready to connect to the remote lab and implement your solution. Do not forget to save. Once your solution is implemented, you need to verify that your configuration is working and fulfills all the requirements specified by the customer. Keep in mind that once you leave the company, a network specialist will verify your configuration. Your ability to implement the solution according to the customer specifications will determine whether you get the job or not. Use the following area to record your notes and document the verifications you conducted to ensure that your solution is complete. If you are unsure about the verification steps, use the information provided in the “Hints” section at the end of this lab. Student Notes: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ 198

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

© 2009 Cisco Systems, Inc.

Lab Guide

199

Alternate Resources and Solutions Other groups may have implemented a solution that is different from yours. These will be discussed during the debriefing period that will follow this lab. Use the following space to document other possible solutions for your reference. __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ 200

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

© 2009 Cisco Systems, Inc.

Lab Guide

201

Hints You are encouraged to complete the labs using your knowledge. However, this section contains a series of hints to aid your completion of the lab.

Lab 3-4 Hint Sheet: Configure and Verify OSPF Special Area Types Implementation Requirements To facilitate the configuration of your network, Task 1 asks you to create an implementation requirements list. This list details the elements you need in order to develop an implementation plan. The following is an example of such a list: Device

Implementation Requirement

Hint

ALL

Identify the networks that are advertised by all routers. Find internal as well as external networks.

Lab

ALL

Identify the existing OSPF configuration.

Lab

Implementation and Verification Plan In Task 2, you will create an implementation and verification plan. Although there are several ways to set up this plan, the following tasks must be completed: Complete

202

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1–R4

1

Load the initial configuration.

All pod routers must be preloaded with the initial configuration for the lab.

Step 1

R1–R4

2

Examine the OSPF routing configuration on all routers. First explore the OSPF link-state database to gain insight into how OSPF is deployed in the network. Also observe the OSPF area configuration to learn the OSPF architecture and topology.

Step 2.1

R1–R4

3

Verify the IP routing tables for routers R1, R2, R3, and R4 to see whether the correct information was put into the routing tables and that external networks are in the IP routing table.

Step 2.2

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1, R2, R4

4

Prevent OSPF from announcing information about the OSPF external routers into Area 24. Connectivity to external routes 192.168.x.0/24 should be preserved and routers R2 and R4 should still be able to access those networks. Remember that routers R2 and R4 should have specific information about those networks that are internal to the OSPF domain regardless of where they are injected into the OSPF domain.

Examine the OSPF database on routers R2 and R4 and verify that the size of the database is smaller than before because they do not hold specific information about the IP subnets that are external to the OSPF domain; that is, those that are redistributed somewhere in the OSPF domain.

Step 3

Prevent OSPF from announcing information about the OSPF internal routers from other OSPF areas into Area 24. Connectivity to all external routes 192.168.x.0/24 and internal routes from other areas should be preserved; that is,routers R2 and R4 should still be able to access those networks. Remember that routers R2 and R4 should have specific information about those networks that are internal to the OSPF Area 24.

Examine the OSPF database on routers R2 and R4 and verify that the size of the database is smaller than before because they do not hold the specific information about the IP subnets that are interarea and external to the OSPF domain.

R1, R2, R4

© 2009 Cisco Systems, Inc.

5

Verify that routers R2 and R4 have the necessary information on how to reach the external networks. Verify that routers R2 and R4 have IP connectivity to the destinations from the IP subnets that are external to the OSPF domain. Step 4

Verify that routers R2 and R4 have the necessary information on how to reach the interarea and external networks. Verify that routers R2 and R4 have IP connectivity to the destinations from the IP subnets that are external to the OSPF domain.

Lab Guide

203

Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1, R3

6

Minimize the OSPF link-state database and IP routing table on router R3 inside Area 3. The router R3 OSPF database, and consequently the IP routing table, should have information only about the OSPF Area 3 announced routes, whether internal or external.

Examine the OSPF database on router R1 and verify that it still has all the specific information about the internal and external OSPF routes of your OSPF domain. Also verify that the IP routing table is populated with the best paths to all destination networks.

Step 5

Preserve the redistribution of external routes 192.1658.x.0/24 on router R3; that is, the router should still announce those networks into the OSPF domain.

Examine the OSPF database and IP routing table on router R3 and verify that the database size and the size of the IP routing table have been reduced. The router should not have any information about the routes that are external to OSPF Area 3.

Remember that router R3 should also preserve connectivity to all subsets announced by OSPF.

Verify that you still have IP connectivity from router R3 to the LAN segment between routers R2 and R4.

Step-by-Step Procedure for Implementation and Verification 1. Load the initial configuration on all devices in your lab. 1.1. The instructor will provide guidelines for changing the initial configuration. 2. Examine the OSPF routing information. 2.1. Examine the OSPF link-state database to gain insight into how OSPF is deployed in the network. Îďý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďňďňďňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďňďňďňď ďéîňíđňďđňę

ßÜĘ Î±«¬»® ďňďňďňď ďéîňíđňďđňę

ßą» îđî îđí

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđë đ¨đđđŰßÝ î đ¨čđđđđçŢë đ¨đđŢÜčí í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďíňđ ďéîňíđňďíňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďęč ďďč ďďč ďçě ďčç ďďč

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđě đ¨čđđđđđđď đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđďěßß đ¨đđęÝěę đ¨đđęîěÜ đ¨đđéçÚÚ đ¨đđíßŰë đ¨đđßđßç

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ďčç

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđíčé

᫬»® Ô·˛µ ͬż¬»­ řß®»ż í÷

204

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ô·˛µ ×Ü ďňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď ďçîňďęčňíňď

ßą» ďçí ďçě

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđë đ¨đđďéďé î đ¨čđđđđđđě đ¨đđçÚíÝ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďęç ďďç ďďç îđë îđđ ďďç

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđďěßß đ¨đđęÝěę đ¨đđęîěÜ đ¨đđëŰďŢ đ¨đđëŢÝé đ¨đđßđßç

᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» ďîě ďîë ďíí

Í»Żý đ¨čđđđđđđé đ¨čđđđđđđé đ¨čđđđđđđë

ݸ»˝µ­«ł đ¨đđßëčđ đ¨đđŰëđî đ¨đđďîÝë

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ďíé

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» îđđ îđë îđđ ďçđ

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđéÚÚÝ đ¨đđëŰďŢ đ¨đđëŢÝé đ¨đđíßŰë

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ďçđ

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđíčé

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ ďçîňďęčňěňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď ďňďňďňď

ßą» îčę îčę îčę îîę

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđđěÝě đ¨đđÚčÝŰ đ¨đđŰÜÜč đ¨đđŰŢěí

Ěżą đ đ đ đ

Îîý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňîňîňî÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» íđ îç íç

Í»Żý đ¨čđđđđđđé đ¨čđđđđđđé đ¨čđđđđđđë

ݸ»˝µ­«ł đ¨đđßëčđ đ¨đđŰëđî đ¨đđďîÝë

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ěí

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ © 2009 Cisco Systems, Inc.

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ďđé

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđéÚÚÝ Lab Guide

205

ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňďíňđ

ďňďňďňď ďňďňďňď ďňďňďňď

ďďî ďđé çé

đ¨čđđđđđđď đ¨đđëŰďŢ đ¨čđđđđđđď đ¨đđëŢÝé đ¨čđđđđđđď đ¨đđíßŰë

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» çé

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđíčé

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ ďçîňďęčňěňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď ďňďňďňď

ßą» îđď îđď îđď ďěď

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđđěÝě đ¨đđÚčÝŰ đ¨đđŰÜÜč đ¨đđŰŢěí

Ěżą đ đ đ đ

Îíý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďçîňďęčňíňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď ďçîňďęčňíňď

ßą» îěç îěč

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđë đ¨đđďéďé î đ¨čđđđđđđě đ¨đđçÚíÝ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» îîë ďéë ďéë îęđ îëë ďéë

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđďěßß đ¨đđęÝěę đ¨đđęîěÜ đ¨đđëŰďŢ đ¨đđëŢÝé đ¨đđßđßç

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ ďçîňďęčňěňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď ďňďňďňď

ßą» íěđ íěđ íěî îčî

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđđěÝě đ¨đđÚčÝŰ đ¨đđŰÜÜč đ¨đđŰŢěí

Ěżą đ đ đ đ

Îěý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňěňěňě÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» îđč îđč îďë

Í»Żý đ¨čđđđđđđé đ¨čđđđđđđé đ¨čđđđđđđë

ݸ»˝µ­«ł đ¨đđßëčđ đ¨đđŰëđî đ¨đđďîÝë

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» îîđ

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňďíňđ 206

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

Implementing Cisco IP Routing (ROUTE) v1.0

ßą» îčí îčč îčí îéí

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđéÚÚÝ đ¨đđëŰďŢ đ¨đđëŢÝé đ¨đđíßŰë © 2009 Cisco Systems, Inc.

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» îéí

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđíčé

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ ďçîňďęčňěňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď ďňďňďňď

ßą» íéď íéď íéď íďď

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđđěÝě đ¨đđÚčÝŰ đ¨đđŰÜÜč đ¨đđŰŢěí

Ěżą đ đ đ đ

2.2. Verify the IP routing table. Îďý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ďéîňíđňîěňđ ĹďďđńďďĂ Ş·ż ďđňďňďďđňîô đđćđěćďđô Í»®·ż´đńđńđňď Ń ďéîňíđňďđňđ ĹďďđńęëĂ Ş·ż ďđňďňďďęňęô đđćđëćíđô Í»®·ż´đńđńđňďďę Ń ďéîňíđňďíňđ ĹďďđńęëĂ Ş·ż ďđňďňďďíňíô đđćđëćîđô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňěńíî ĹďďđńďďĂ Ş·ż ďđňďňďďđňîô đđćđěćďđô Í»®·ż´đńđńđňď Ń ďđňďňďďđňîńíî ĹďďđńďđĂ Ş·ż ďđňďňďďđňîô đđćđěćďđô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđěćďđô Í»®·ż´đńđńđňî Ń Űî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđěćďđô Í»®·ż´đńđńđňî Ń Űî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđěćďđô Í»®·ż´đńđńđňî Îîý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđěćíëô Í»®·ż´đńđńđňď Ń ×ß ďéîňíđňďíňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđěćíëô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňěňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđěćíëô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňěńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňěô đđćđěćíëô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđěćíëô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďíňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđěćíëô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđěćíëô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđěćíëô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđěćíëô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđěćíëô Í»®·ż´đńđńđňď Îíý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňîěňđ ĹďďđńéëĂ Ş·ż ďđňďňďďíňďô đđćđěćëěô Í»®·ż´đńđńđňî Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďíňďô đđćđęćđîô Í»®·ż´đńđńđňî Ń Űî ďçîňďęčňěňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňďô đđćđěćëçô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ×ß ďđňďňďďđňěńíî ĹďďđńéëĂ Ş·ż ďđňďňďďíňďô đđćđěćëěô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďíňďô đđćđëćěěô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďđňîńíî ĹďďđńéěĂ Ş·ż ďđňďňďďíňďô đđćđěćëěô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďíňďô đđćđęćđîô Í»®·ż´đńđńđňî Îěý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđëćďěô Í»®·ż´đńđńđňď Ń ×ß ďéîňíđňďíňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđëćďěô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňěňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđëćďěô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđëćďěô Í»®·ż´đńđńđňď Ń ďđňďňďďđňîńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňîô đđćđëćďěô Úż­¬Ű¬¸»®˛»¬đńđ Ń ×ß ďđňďňďďíňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđëćďěô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđëćďěô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđëćďěô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđëćďěô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđëćďěô Í»®·ż´đńđńđňď

© 2009 Cisco Systems, Inc.

Lab Guide

207

3. Optimize OSPF routing for Area 24 using stub area type. 3.1. Use the following example to configure routers R1, R2, and R4 in this lab: Îďý ®±«¬»® ±­°ş ď ż®»ż îě ­¬«ľ Îîý ®±«¬»® ±­°ş ď ż®»ż îě ­¬«ľ Îěý ®±«¬»® ±­°ş ď ż®»ż îě ­¬«ľ

3.2. Verify the OSPF database, IP routing table, and check for connectivity to external networks. Îďý­¸±© ·° ±­°ş ᫬·˛ą Đ®±˝»­­ ţ±­°ş ďţ ©·¬¸ ×Ü ďňďňďňď ͬż®¬ ¬·ł»ć ë©îĽô Ě·ł» »´ż°­»Ľć đďćíěćďéňěęč Í«°°±®¬­ ±˛´§ ­·˛ą´» ĚŃÍřĚŃÍđ÷ ®±«¬»­ Í«°°±®¬­ ±°żŻ«» ÔÍß Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ Í«°°±®¬­ ż®»ż ¬®ż˛­·¬ ˝ż°żľ·´·¬§ ׬ ·­ ż˛ ż®»ż ľ±®Ľ»® ż˛Ľ ż«¬±˛±ł±«­ ­§­¬»ł ľ±«˛Ľż®§ ®±«¬»® λĽ·­¬®·ľ«¬·˛ą ۨ¬»®˛ż´ ᫬»­ ş®±łô ­¬ż¬·˝ô ·˛˝´«Ľ»­ ­«ľ˛»¬­ ·˛ ®»Ľ·­¬®·ľ«¬·±˛ ᫬»® ·­ ˛±¬ ±®·ą·˛ż¬·˛ą ®±«¬»®óÔÍß­ ©·¬¸ łż¨·ł«ł ł»¬®·˝ ײ·¬·ż´ ÍĐÚ ­˝¸»Ľ«´» Ľ»´ż§ ëđđđ ł­»˝­ Ó·˛·ł«ł ¸±´Ľ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ Óż¨·ł«ł ©ż·¬ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ ײ˝®»ł»˛¬ż´óÍĐÚ Ľ·­żľ´»Ľ Ó·˛·ł«ł ÔÍß ·˛¬»®Şż´ ë ­»˝­ Ó·˛·ł«ł ÔÍß ż®®·Şż´ ďđđđ ł­»˝­ ÔÍß ą®±«° °ż˝·˛ą ¬·ł»® îěđ ­»˝­ ײ¬»®şż˝» ş´±±Ľ °ż˝·˛ą ¬·ł»® íí ł­»˝­ 묮ż˛­ł·­­·±˛ °ż˝·˛ą ¬·ł»® ęę ł­»˝­ Ň«łľ»® ±ş »¨¬»®˛ż´ ÔÍß ěň ݸ»˝µ­«ł Í«ł đ¨đîÜęßÜ Ň«łľ»® ±ş ±°żŻ«» ßÍ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ż®»ż­ ·˛ ¬¸·­ ®±«¬»® ·­ íň î ˛±®łż´ ď ­¬«ľ đ ˛­­ż Ň«łľ»® ±ş ż®»ż­ ¬®ż˛­·¬ ˝ż°żľ´» ·­ đ ۨ¬»®˛ż´ ş´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż ŢßÝŐŢŃŇŰřđ÷ Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđîćîéňíîđ żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ďđ ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» ďéîňíđňđňđńďę ß˝¬·Ş»řęë÷ ßĽŞ»®¬·­» Ň«łľ»® ±ş ÔÍß čň ݸ»˝µ­«ł Í«ł đ¨đěęéÝď Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż í Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđîćîéňíîđ żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ďď ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß éň ݸ»˝µ­«ł Í«ł đ¨đíďëŢç Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ 208

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż îě Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ׬ ·­ ż ­¬«ľ ż®»ż ą»˛»®ż¬»­ ­¬«ľ Ľ»şż«´¬ ®±«¬» ©·¬¸ ˝±­¬ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđďćëěňęçę żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ďě ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß çň ݸ»˝µ­«ł Í«ł đ¨đéęŢîÜ Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ Îîý­¸±© ·° ±­°ş ᫬·˛ą Đ®±˝»­­ ţ±­°ş ďţ ©·¬¸ ×Ü ďđňîňîňî ͬż®¬ ¬·ł»ć ë©îĽô Ě·ł» »´ż°­»Ľć đďćííćîčňéčě Í«°°±®¬­ ±˛´§ ­·˛ą´» ĚŃÍřĚŃÍđ÷ ®±«¬»­ Í«°°±®¬­ ±°żŻ«» ÔÍß Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ Í«°°±®¬­ ż®»ż ¬®ż˛­·¬ ˝ż°żľ·´·¬§ ᫬»® ·­ ˛±¬ ±®·ą·˛ż¬·˛ą ®±«¬»®óÔÍß­ ©·¬¸ łż¨·ł«ł ł»¬®·˝ ײ·¬·ż´ ÍĐÚ ­˝¸»Ľ«´» Ľ»´ż§ ëđđđ ł­»˝­ Ó·˛·ł«ł ¸±´Ľ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ Óż¨·ł«ł ©ż·¬ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ ײ˝®»ł»˛¬ż´óÍĐÚ Ľ·­żľ´»Ľ Ó·˛·ł«ł ÔÍß ·˛¬»®Şż´ ë ­»˝­ Ó·˛·ł«ł ÔÍß ż®®·Şż´ ďđđđ ł­»˝­ ÔÍß ą®±«° °ż˝·˛ą ¬·ł»® îěđ ­»˝­ ײ¬»®şż˝» ş´±±Ľ °ż˝·˛ą ¬·ł»® íí ł­»˝­ 묮ż˛­ł·­­·±˛ °ż˝·˛ą ¬·ł»® ęę ł­»˝­ Ň«łľ»® ±ş »¨¬»®˛ż´ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ±°żŻ«» ßÍ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ż®»ż­ ·˛ ¬¸·­ ®±«¬»® ·­ ďň 𠲱®łż´ ď ­¬«ľ đ ˛­­ż Ň«łľ»® ±ş ż®»ż­ ¬®ż˛­·¬ ˝ż°żľ´» ·­ đ ۨ¬»®˛ż´ ş´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż îě Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ î ׬ ·­ ż ­¬«ľ ż®»ż ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđîćďëňčęě żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ďí ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß çň ݸ»˝µ­«ł Í«ł đ¨đěîďÜç Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ Îěý­¸±© ·° ±­°ş ᫬·˛ą Đ®±˝»­­ ţ±­°ş ďţ ©·¬¸ ×Ü ďđňěňěňě ͬż®¬ ¬·ł»ć ë©îĽô Ě·ł» »´ż°­»Ľć đďćííćëďňëçî Í«°°±®¬­ ±˛´§ ­·˛ą´» ĚŃÍřĚŃÍđ÷ ®±«¬»­ Í«°°±®¬­ ±°żŻ«» ÔÍß Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ Í«°°±®¬­ ż®»ż ¬®ż˛­·¬ ˝ż°żľ·´·¬§ ᫬»® ·­ ˛±¬ ±®·ą·˛ż¬·˛ą ®±«¬»®óÔÍß­ ©·¬¸ łż¨·ł«ł ł»¬®·˝ ײ·¬·ż´ ÍĐÚ ­˝¸»Ľ«´» Ľ»´ż§ ëđđđ ł­»˝­ Ó·˛·ł«ł ¸±´Ľ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ Óż¨·ł«ł ©ż·¬ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ ײ˝®»ł»˛¬ż´óÍĐÚ Ľ·­żľ´»Ľ Ó·˛·ł«ł ÔÍß ·˛¬»®Şż´ ë ­»˝­ © 2009 Cisco Systems, Inc.

Lab Guide

209

Ó·˛·ł«ł ÔÍß ż®®·Şż´ ďđđđ ł­»˝­ ÔÍß ą®±«° °ż˝·˛ą ¬·ł»® îěđ ­»˝­ ײ¬»®şż˝» ş´±±Ľ °ż˝·˛ą ¬·ł»® íí ł­»˝­ 묮ż˛­ł·­­·±˛ °ż˝·˛ą ¬·ł»® ęę ł­»˝­ Ň«łľ»® ±ş »¨¬»®˛ż´ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ±°żŻ«» ßÍ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ż®»ż­ ·˛ ¬¸·­ ®±«¬»® ·­ ďň 𠲱®łż´ ď ­¬«ľ đ ˛­­ż Ň«łľ»® ±ş ż®»ż­ ¬®ż˛­·¬ ˝ż°żľ´» ·­ đ ۨ¬»®˛ż´ ş´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż îě Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ î ׬ ·­ ż ­¬«ľ ż®»ż ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđîćëęňëëę żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ďě ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß çň ݸ»˝µ­«ł Í«ł đ¨đěîďÜç Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ Îďý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďňďňďňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďňďňďňď ďéîňíđňďđňę

ßÜĘ Î±«¬»® ďňďňďňď ďéîňíđňďđňę

ßą» ëéç ëčď

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđë đ¨đđđŰßÝ î đ¨čđđđđçŢë đ¨đđŢÜčí í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďíňđ ďéîňíđňďíňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ëěę ďđę çę ëéď ëęę ďđę

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđî đ¨čđđđđđđě đ¨čđđđđđđď đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđďěßß đ¨đđęŰěë đ¨đđęîěÜ đ¨đđéçÚÚ đ¨đđíßŰë đ¨đđßđßç

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ëęę

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđíčé

᫬»® Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď ďçîňďęčňíňď

ßą» ëéđ ëéí

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđë đ¨đđďéďé î đ¨čđđđđđđě đ¨đđçÚíÝ í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ëěč ďđč çč ëčí ëéč ďđč

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđî đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđďěßß đ¨đđęŰěë đ¨đđęîěÜ đ¨đđëŰďŢ đ¨đđëŢÝé đ¨đđßđßç

᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷

210

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» ďďí ďđę ďđé

Í»Żý đ¨čđđđđđđß đ¨čđđđđđđŢ đ¨čđđđđđđč

ݸ»˝µ­«ł đ¨đđŢéęÚ đ¨đđÚŢŰç đ¨đđîßßÝ

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ďđé

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđí đ¨đđďŢÚŢ

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü đňđňđňđ ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďěç ďěç ďěç ďěç ďěç

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđçíßę đ¨đđçŢŰď đ¨đđéßÚÚ đ¨đđééßÝ đ¨đđëęÝß

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ ďçîňďęčňěňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď ďňďňďňď

ßą» ęęę ęęę ęęę ęđë

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđđěÝě đ¨đđÚčÝŰ đ¨đđŰÜÜč đ¨đđŰŢěí

Ěżą đ đ đ đ

Îîý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňîňîňî÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» ďęđ ďëî ďëě

Í»Żý đ¨čđđđđđđß đ¨čđđđđđđŢ đ¨čđđđđđđč

ݸ»˝µ­«ł đ¨đđŢéęÚ đ¨đđÚŢŰç đ¨đđîßßÝ

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ďëě

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđí đ¨đđďŢÚŢ

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü đňđňđňđ ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďçě ďçě ďçě ďçě ďçě

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđçíßę đ¨đđçŢŰď đ¨đđéßÚÚ đ¨đđééßÝ đ¨đđëęÝß

Îěý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňěňěňě÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» ďéç ďéî ďéî

Í»Żý đ¨čđđđđđđß đ¨čđđđđđđŢ đ¨čđđđđđđč

ݸ»˝µ­«ł đ¨đđŢéęÚ đ¨đđÚŢŰç đ¨đđîßßÝ

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

© 2009 Cisco Systems, Inc.

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ďéî

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđí đ¨đđďŢÚŢ

Lab Guide

211

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü đňđňđňđ ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» îďě îďě îďě îďě îďě

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđî đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđçíßę đ¨đđçŢŰď đ¨đđéßÚÚ đ¨đđééßÝ đ¨đđëęÝß

Îďý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ďéîňíđňîěňđ ĹďďđńďďĂ Ş·ż ďđňďňďďđňîô đđćđíćďđô Í»®·ż´đńđńđňď Ń ďéîňíđňďđňđ ĹďďđńęëĂ Ş·ż ďđňďňďďęňęô đđćđěćđđô Í»®·ż´đńđńđňďďę Ń ďéîňíđňďíňđ ĹďďđńęëĂ Ş·ż ďđňďňďďíňíô đđćđěćđđô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňěńíî ĹďďđńďďĂ Ş·ż ďđňďňďďđňîô đđćđíćďđô Í»®·ż´đńđńđňď Ń ďđňďňďďđňîńíî ĹďďđńďđĂ Ş·ż ďđňďňďďđňîô đđćđíćďđô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđíćďđô Í»®·ż´đńđńđňî Ń Űî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđíćďđô Í»®·ż´đńđńđňî Ń Űî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđíćďđô Í»®·ż´đńđńđňî Îîý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđíćíëô Í»®·ż´đńđńđňď Ń ×ß ďéîňíđňďíňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđíćíëô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňěńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňěô đđćđíćíëô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđíćíëô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďíňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđíćíëô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđíćíëô Í»®·ż´đńđńđňď Ńö×ß đňđňđňđńđ ĹďďđńęëĂ Ş·ż ďđňďňďďđňďô đđćđíćíëô Í»®·ż´đńđńđňď Îěý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđíćëđô Í»®·ż´đńđńđňď Ń ×ß ďéîňíđňďíňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđíćëđô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđíćëđô Í»®·ż´đńđńđňď Ń ďđňďňďďđňîńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňîô đđćđíćëđô Úż­¬Ű¬¸»®˛»¬đńđ Ń ×ß ďđňďňďďíňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđíćëđô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđíćëđô Í»®·ż´đńđńđňď Ńö×ß đňđňđňđńđ ĹďďđńęëĂ Ş·ż ďđňďňďďđňďô đđćđíćëđô Í»®·ż´đńđńđňď Îîý°·˛ą ďçîňďęčňďňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňďňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďîńďďę ł­ Îěý°·˛ą ďçîňďęčňďňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňďňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďîńďďę ł­

4. Optimize OSPF routing for Area 24 using stub area type. 4.1. Use the following example to configure router R1 in this lab: Îďý ®±«¬»® ±­°ş ď ż®»ż îě ­¬«ľ ˛±ó­«łłż®§

4.2. Verify the OSPF database, IP routing table, and check for connectivity to external networks. Îďý­¸±© ·° ±­°ş ᫬·˛ą Đ®±˝»­­ ţ±­°ş ďţ ©·¬¸ ×Ü ďňďňďňď 212

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

ͬż®¬ ¬·ł»ć ë©îĽô Ě·ł» »´ż°­»Ľć đďćíčćîđňçěđ Í«°°±®¬­ ±˛´§ ­·˛ą´» ĚŃÍřĚŃÍđ÷ ®±«¬»­ Í«°°±®¬­ ±°żŻ«» ÔÍß Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ Í«°°±®¬­ ż®»ż ¬®ż˛­·¬ ˝ż°żľ·´·¬§ ׬ ·­ ż˛ ż®»ż ľ±®Ľ»® ż˛Ľ ż«¬±˛±ł±«­ ­§­¬»ł ľ±«˛Ľż®§ ®±«¬»® λĽ·­¬®·ľ«¬·˛ą ۨ¬»®˛ż´ ᫬»­ ş®±łô ­¬ż¬·˝ô ·˛˝´«Ľ»­ ­«ľ˛»¬­ ·˛ ®»Ľ·­¬®·ľ«¬·±˛ ᫬»® ·­ ˛±¬ ±®·ą·˛ż¬·˛ą ®±«¬»®óÔÍß­ ©·¬¸ łż¨·ł«ł ł»¬®·˝ ײ·¬·ż´ ÍĐÚ ­˝¸»Ľ«´» Ľ»´ż§ ëđđđ ł­»˝­ Ó·˛·ł«ł ¸±´Ľ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ Óż¨·ł«ł ©ż·¬ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ ײ˝®»ł»˛¬ż´óÍĐÚ Ľ·­żľ´»Ľ Ó·˛·ł«ł ÔÍß ·˛¬»®Şż´ ë ­»˝­ Ó·˛·ł«ł ÔÍß ż®®·Şż´ ďđđđ ł­»˝­ ÔÍß ą®±«° °ż˝·˛ą ¬·ł»® îěđ ­»˝­ ײ¬»®şż˝» ş´±±Ľ °ż˝·˛ą ¬·ł»® íí ł­»˝­ 묮ż˛­ł·­­·±˛ °ż˝·˛ą ¬·ł»® ęę ł­»˝­ Ň«łľ»® ±ş »¨¬»®˛ż´ ÔÍß ěň ݸ»˝µ­«ł Í«ł đ¨đěÝđďč Ň«łľ»® ±ş ±°żŻ«» ßÍ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ż®»ż­ ·˛ ¬¸·­ ®±«¬»® ·­ íň î ˛±®łż´ ď ­¬«ľ đ ˛­­ż Ň«łľ»® ±ş ż®»ż­ ¬®ż˛­·¬ ˝ż°żľ´» ·­ đ ۨ¬»®˛ż´ ş´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż ŢßÝŐŢŃŇŰřđ÷ Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđđćđçňčďę żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ě ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» ďéîňíđňđňđńďę ß˝¬·Ş»řęë÷ ßĽŞ»®¬·­» Ň«łľ»® ±ş ÔÍß čň ݸ»˝µ­«ł Í«ł đ¨đíçíčç Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż í Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđđćđçňčďę żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ě ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß éň ݸ»˝µ­«ł Í«ł đ¨đíßęÚÝ Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż îě Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ׬ ·­ ż ­¬«ľ ż®»żô ˛± ­«łłż®§ ÔÍß ·˛ ¬¸·­ ż®»ż ą»˛»®ż¬»­ ­¬«ľ Ľ»şż«´¬ ®±«¬» ©·¬¸ ˝±­¬ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđđćďîňďçî żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ě ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß ëň ݸ»˝µ­«ł Í«ł đ¨đëßěđč Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ Îîý­¸±© ·° ±­°ş ᫬·˛ą Đ®±˝»­­ ţ±­°ş ďţ ©·¬¸ ×Ü ďđňîňîňî ͬż®¬ ¬·ł»ć ë©îĽô Ě·ł» »´ż°­»Ľć đďćíéćîďňîíę © 2009 Cisco Systems, Inc.

Lab Guide

213

Í«°°±®¬­ ±˛´§ ­·˛ą´» ĚŃÍřĚŃÍđ÷ ®±«¬»­ Í«°°±®¬­ ±°żŻ«» ÔÍß Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ Í«°°±®¬­ ż®»ż ¬®ż˛­·¬ ˝ż°żľ·´·¬§ ᫬»® ·­ ˛±¬ ±®·ą·˛ż¬·˛ą ®±«¬»®óÔÍß­ ©·¬¸ łż¨·ł«ł ł»¬®·˝ ײ·¬·ż´ ÍĐÚ ­˝¸»Ľ«´» Ľ»´ż§ ëđđđ ł­»˝­ Ó·˛·ł«ł ¸±´Ľ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ Óż¨·ł«ł ©ż·¬ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ ײ˝®»ł»˛¬ż´óÍĐÚ Ľ·­żľ´»Ľ Ó·˛·ł«ł ÔÍß ·˛¬»®Şż´ ë ­»˝­ Ó·˛·ł«ł ÔÍß ż®®·Şż´ ďđđđ ł­»˝­ ÔÍß ą®±«° °ż˝·˛ą ¬·ł»® îěđ ­»˝­ ײ¬»®şż˝» ş´±±Ľ °ż˝·˛ą ¬·ł»® íí ł­»˝­ 묮ż˛­ł·­­·±˛ °ż˝·˛ą ¬·ł»® ęę ł­»˝­ Ň«łľ»® ±ş »¨¬»®˛ż´ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ±°żŻ«» ßÍ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ż®»ż­ ·˛ ¬¸·­ ®±«¬»® ·­ ďň 𠲱®łż´ ď ­¬«ľ đ ˛­­ż Ň«łľ»® ±ş ż®»ż­ ¬®ż˛­·¬ ˝ż°żľ´» ·­ đ ۨ¬»®˛ż´ ş´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż îě Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ î ׬ ·­ ż ­¬«ľ ż®»ż ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđđćěčňçđđ żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ďë ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß ëň ݸ»˝µ­«ł Í«ł đ¨đďÜďŰë Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ Îěý­¸±© ·° ±­°ş ᫬·˛ą Đ®±˝»­­ ţ±­°ş ďţ ©·¬¸ ×Ü ďđňěňěňě ͬż®¬ ¬·ł»ć ë©îĽô Ě·ł» »´ż°­»Ľć đďćíéćíéňîęč Í«°°±®¬­ ±˛´§ ­·˛ą´» ĚŃÍřĚŃÍđ÷ ®±«¬»­ Í«°°±®¬­ ±°żŻ«» ÔÍß Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ Í«°°±®¬­ ż®»ż ¬®ż˛­·¬ ˝ż°żľ·´·¬§ ᫬»® ·­ ˛±¬ ±®·ą·˛ż¬·˛ą ®±«¬»®óÔÍß­ ©·¬¸ łż¨·ł«ł ł»¬®·˝ ײ·¬·ż´ ÍĐÚ ­˝¸»Ľ«´» Ľ»´ż§ ëđđđ ł­»˝­ Ó·˛·ł«ł ¸±´Ľ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ Óż¨·ł«ł ©ż·¬ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ ײ˝®»ł»˛¬ż´óÍĐÚ Ľ·­żľ´»Ľ Ó·˛·ł«ł ÔÍß ·˛¬»®Şż´ ë ­»˝­ Ó·˛·ł«ł ÔÍß ż®®·Şż´ ďđđđ ł­»˝­ ÔÍß ą®±«° °ż˝·˛ą ¬·ł»® îěđ ­»˝­ ײ¬»®şż˝» ş´±±Ľ °ż˝·˛ą ¬·ł»® íí ł­»˝­ 묮ż˛­ł·­­·±˛ °ż˝·˛ą ¬·ł»® ęę ł­»˝­ Ň«łľ»® ±ş »¨¬»®˛ż´ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ±°żŻ«» ßÍ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ż®»ż­ ·˛ ¬¸·­ ®±«¬»® ·­ ďň 𠲱®łż´ ď ­¬«ľ đ ˛­­ż Ň«łľ»® ±ş ż®»ż­ ¬®ż˛­·¬ ˝ż°żľ´» ·­ đ ۨ¬»®˛ż´ ş´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż îě Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ î ׬ ·­ ż ­¬«ľ ż®»ż ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđďćîęňîěđ żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ďę ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß ëň ݸ»˝µ­«ł Í«ł đ¨đďÜďŰë Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ 214

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ Îîý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňîňîňî÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» ëç íéé íčď

Í»Żý đ¨čđđđđđđç đ¨čđđđđđđç đ¨čđđđđđđç

ݸ»˝µ­«ł đ¨đđŢçęŰ đ¨đđěęęí đ¨đđîßęÚ

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» íéę

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđë đ¨đđďéÚÜ

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü đňđňđňđ

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ęđ

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđí đ¨đđčÚßč

Îěý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňěňěňě÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» çě ěďí ěďę

Í»Żý đ¨čđđđđđđç đ¨čđđđđđđç đ¨čđđđđđđç

ݸ»˝µ­«ł đ¨đđŢçęŰ đ¨đđěęęí đ¨đđîßęÚ

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ěďď

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđë đ¨đđďéÚÜ

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü đňđňđňđ

ßÜĘ Î±«¬»® ďňďňďňď

ßą» çë

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđí đ¨đđčÚßč

Îîý­¸±© ·° ®±«¬» ±­°ş ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňěńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňěô đđćđęćěěô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđęćěěô Í»®·ż´đńđńđňď Ńö×ß đňđňđňđńđ ĹďďđńęëĂ Ş·ż ďđňďňďďđňďô đđćđďćëëô Í»®·ż´đńđńđňď Îěý­¸±© ·° ®±«¬» ±­°ş ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđęćďîô Í»®·ż´đńđńđňď Ń ďđňďňďďđňîńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňîô đđćđęćďîô Úż­¬Ű¬¸»®˛»¬đńđ Ńö×ß đňđňđňđńđ ĹďďđńęëĂ Ş·ż ďđňďňďďđňďô đđćđďćîéô Í»®·ż´đńđńđňď Îîý°·˛ą ďçîňďęčňďňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňďňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďîńďďę ł­ Îěý°·˛ą ďçîňďęčňďňď

© 2009 Cisco Systems, Inc.

Lab Guide

215

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňďňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďîńďďę ł­

5. Reduce the OSPF information in Area 3. 5.1. Use the following example to configure router R1 in this lab: Îďý ®±«¬»® ±­°ş ď ż®»ż í ˛­­ż ˛±ó­«łłż®§ Îíý ®±«¬»® ±­°ş ď ż®»ż í ˛­­ż

5.2. Verify the OSPF database, IP routing table, and check for connectivity to the external networks. Îďý­¸±© ·° ±­°ş ᫬·˛ą Đ®±˝»­­ ţ±­°ş ďţ ©·¬¸ ×Ü ďňďňďňď ͬż®¬ ¬·ł»ć ë©îĽô Ě·ł» »´ż°­»Ľć đďćěçćěďňçčđ Í«°°±®¬­ ±˛´§ ­·˛ą´» ĚŃÍřĚŃÍđ÷ ®±«¬»­ Í«°°±®¬­ ±°żŻ«» ÔÍß Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ Í«°°±®¬­ ż®»ż ¬®ż˛­·¬ ˝ż°żľ·´·¬§ ׬ ·­ ż˛ ż®»ż ľ±®Ľ»® ż˛Ľ ż«¬±˛±ł±«­ ­§­¬»ł ľ±«˛Ľż®§ ®±«¬»® λĽ·­¬®·ľ«¬·˛ą ۨ¬»®˛ż´ ᫬»­ ş®±łô ­¬ż¬·˝ô ·˛˝´«Ľ»­ ­«ľ˛»¬­ ·˛ ®»Ľ·­¬®·ľ«¬·±˛ ᫬»® ·­ ˛±¬ ±®·ą·˛ż¬·˛ą ®±«¬»®óÔÍß­ ©·¬¸ łż¨·ł«ł ł»¬®·˝ ײ·¬·ż´ ÍĐÚ ­˝¸»Ľ«´» Ľ»´ż§ ëđđđ ł­»˝­ Ó·˛·ł«ł ¸±´Ľ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ Óż¨·ł«ł ©ż·¬ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ ײ˝®»ł»˛¬ż´óÍĐÚ Ľ·­żľ´»Ľ Ó·˛·ł«ł ÔÍß ·˛¬»®Şż´ ë ­»˝­ Ó·˛·ł«ł ÔÍß ż®®·Şż´ ďđđđ ł­»˝­ ÔÍß ą®±«° °ż˝·˛ą ¬·ł»® îěđ ­»˝­ ײ¬»®şż˝» ş´±±Ľ °ż˝·˛ą ¬·ł»® íí ł­»˝­ 묮ż˛­ł·­­·±˛ °ż˝·˛ą ¬·ł»® ęę ł­»˝­ Ň«łľ»® ±ş »¨¬»®˛ż´ ÔÍß ěň ݸ»˝µ­«ł Í«ł đ¨đěÜěßÚ Ň«łľ»® ±ş ±°żŻ«» ßÍ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ż®»ż­ ·˛ ¬¸·­ ®±«¬»® ·­ íň ď ˛±®łż´ ď ­¬«ľ ď ˛­­ż Ň«łľ»® ±ş ż®»ż­ ¬®ż˛­·¬ ˝ż°żľ´» ·­ đ ۨ¬»®˛ż´ ş´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż ŢßÝŐŢŃŇŰřđ÷ Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđđćěíňéíę żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ é ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» ďéîňíđňđňđńďę ß˝¬·Ş»řęë÷ ßĽŞ»®¬·­» Ň«łľ»® ±ş ÔÍß éň ݸ»˝µ­«ł Í«ł đ¨đíçđđî Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż í Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ׬ ·­ ż ŇÍÍß ż®»ż Đ»®ş±®ł ¬§°»óéń¬§°»óë ÔÍß ¬®ż˛­´ż¬·±˛ ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđđćěíňéěđ żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ç ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß éň ݸ»˝µ­«ł Í«ł đ¨đíîęëë Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ 216

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż îě Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ׬ ·­ ż ­¬«ľ ż®»żô ˛± ­«łłż®§ ÔÍß ·˛ ¬¸·­ ż®»ż ą»˛»®ż¬»­ ­¬«ľ Ľ»şż«´¬ ®±«¬» ©·¬¸ ˝±­¬ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđđćěęňđěđ żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ é ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß ëň ݸ»˝µ­«ł Í«ł đ¨đëßěđč Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ Îíý­¸±© ·° ±­°ş ᫬·˛ą Đ®±˝»­­ ţ±­°ş ďţ ©·¬¸ ×Ü ďçîňďęčňíňď ͬż®¬ ¬·ł»ć ë©îĽô Ě·ł» »´ż°­»Ľć đďćěçćěçňčîě Í«°°±®¬­ ±˛´§ ­·˛ą´» ĚŃÍřĚŃÍđ÷ ®±«¬»­ Í«°°±®¬­ ±°żŻ«» ÔÍß Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ Í«°°±®¬­ ż®»ż ¬®ż˛­·¬ ˝ż°żľ·´·¬§ ׬ ·­ ż˛ ż«¬±˛±ł±«­ ­§­¬»ł ľ±«˛Ľż®§ ®±«¬»® λĽ·­¬®·ľ«¬·˛ą ۨ¬»®˛ż´ ᫬»­ ş®±łô ˝±˛˛»˝¬»Ľô ·˛˝´«Ľ»­ ­«ľ˛»¬­ ·˛ ®»Ľ·­¬®·ľ«¬·±˛ ᫬»® ·­ ˛±¬ ±®·ą·˛ż¬·˛ą ®±«¬»®óÔÍß­ ©·¬¸ łż¨·ł«ł ł»¬®·˝ ײ·¬·ż´ ÍĐÚ ­˝¸»Ľ«´» Ľ»´ż§ ëđđđ ł­»˝­ Ó·˛·ł«ł ¸±´Ľ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ Óż¨·ł«ł ©ż·¬ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ ײ˝®»ł»˛¬ż´óÍĐÚ Ľ·­żľ´»Ľ Ó·˛·ł«ł ÔÍß ·˛¬»®Şż´ ë ­»˝­ Ó·˛·ł«ł ÔÍß ż®®·Şż´ ďđđđ ł­»˝­ ÔÍß ą®±«° °ż˝·˛ą ¬·ł»® îěđ ­»˝­ ײ¬»®şż˝» ş´±±Ľ °ż˝·˛ą ¬·ł»® íí ł­»˝­ 묮ż˛­ł·­­·±˛ °ż˝·˛ą ¬·ł»® ęę ł­»˝­ Ň«łľ»® ±ş »¨¬»®˛ż´ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ±°żŻ«» ßÍ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ż®»ż­ ·˛ ¬¸·­ ®±«¬»® ·­ ďň 𠲱®łż´ đ ­¬«ľ ď ˛­­ż Ň«łľ»® ±ş ż®»ż­ ¬®ż˛­·¬ ˝ż°żľ´» ·­ đ ۨ¬»®˛ż´ ş´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż í Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ î ׬ ·­ ż ŇÍÍß ż®»ż ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđčćďîňîęđ żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ďě ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß éň ݸ»˝µ­«ł Í«ł đ¨đďÚÚÚç Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ Îďý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďňďňďňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďňďňďňď © 2009 Cisco Systems, Inc.

ßÜĘ Î±«¬»® ďňďňďňď

ßą» çéé

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđë đ¨đđđŰßÝ î Lab Guide

217

ďéîňíđňďđňę

ďéîňíđňďđňę

çéç

đ¨čđđđđçŢë đ¨đđŢÜčí í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďíňđ ďéîňíđňďíňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» çěí ëđí ěçí çęç ďč ëđí

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđî đ¨čđđđđđđě đ¨čđđđđđđď đ¨čđđđđđđî

ݸ»˝µ­«ł đ¨đđďěßß đ¨đđęŰěë đ¨đđęîěÜ đ¨đđéçÚÚ đ¨đđíßŰë đ¨đđßđßç

᫬»® Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď ďçîňďęčňíňď

ßą» îé îç

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđé đ¨đđŢčęÜ î đ¨čđđđđđđę đ¨đđěďçî í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü đňđňđňđ

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ěç

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđďŢďé

̧°»óé ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ ďçîňďęčňěňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď ďňďňďňď

ßą» ěđ ěđ ěđ ěč

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđďčÝŢ đ¨đđđÜÜë đ¨đđđîÜÚ đ¨đđÝÚëÜ

Ěżą đ đ đ đ

᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» ëďě ëđč ëđç

Í»Żý đ¨čđđđđđđß đ¨čđđđđđđŢ đ¨čđđđđđđč

ݸ»˝µ­«ł đ¨đđŢéęÚ đ¨đđÚŢŰç đ¨đđîßßÝ

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ëđç

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđí đ¨đđďŢÚŢ

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü đňđňđňđ

ßÜĘ Î±«¬»® ďňďňďňď

ßą» îîď

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđî đ¨đđçďßé

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ ďçîňďęčňěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» îđ îđ îđ ďđđç

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđŢëßď đ¨đđßßßŢ đ¨đđçÚŢë đ¨đđŰŢěí

Ěżą đ đ đ đ

Îíý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďçîňďęčňíňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď ďçîňďęčňíňď

ßą» ëđę ëđë

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđč đ¨đđŢęęŰ î đ¨čđđđđđđÝ đ¨đđíëçč í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż í÷

218

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ô·˛µ ×Ü đňđňđňđ

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ęę

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđďŢďé

̧°»óé ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ ďçîňďęčňěňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď ďňďňďňď

ßą» ëđç ëđç ëđç ëíî

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđďčÝŢ đ¨đđđÜÜë đ¨đđđîÜÚ đ¨đđÝÚëÜ

Ěżą đ đ đ đ

Îďý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ďéîňíđňîěňđ ĹďďđńďďĂ Ş·ż ďđňďňďďđňîô đđćđďćëëô Í»®·ż´đńđńđňď Ń ďéîňíđňďđňđ ĹďďđńęëĂ Ş·ż ďđňďňďďęňęô đđćđďćëëô Í»®·ż´đńđńđňďďę Ń ďéîňíđňďíňđ ĹďďđńęëĂ Ş·ż ďđňďňďďíňíô đđćđďćíđô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňěńíî ĹďďđńďďĂ Ş·ż ďđňďňďďđňîô đđćđďćëëô Í»®·ż´đńđńđňď Ń ďđňďňďďđňîńíî ĹďďđńďđĂ Ş·ż ďđňďňďďđňîô đđćđďćëëô Í»®·ż´đńđńđňď Ń Ňî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđďćíđô Í»®·ż´đńđńđňî Ń Ňî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđďćíđô Í»®·ż´đńđńđňî Ń Ňî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđďćíđô Í»®·ż´đńđńđňî Îíý­¸±© ·° ®±«¬» ±­°ş Ń Ňî ďçîňďęčňěňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňďô đđćđďćđëô Í»®·ż´đńđńđňî Ńö×ß đňđňđňđńđ ĹďďđńęëĂ Ş·ż ďđňďňďďíňďô đđćđďćďđô Í»®·ż´đńđńđňî Îíý°·˛ą ďéîňíđňîěňî ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňíđňîěňîô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďîńďďę ł­

© 2009 Cisco Systems, Inc.

Lab Guide

219

Lab 3-5: Configure and Verify OSPF Authentication Complete this lab activity to practice what you learned in the related module.

Activity Objective Complete this lab activity to practice what you learned in the related module. In this activity, you will use correct commands, tools, and steps to configure and verify basic OSPF authentication implementation. After completing this activity, you will be able to meet these objectives: Select the required tools and commands to configure basic OSPF authentication Organize the tasks into an implementation plan to implement OSPF authentication Implement the identified OSPF solution to configure basic OSPF authentication in the provided network according to the implementation plan, using Cisco IOS commands and applications in the correct order to the selected devices and portions of the network Write a verification and test plan to verify correct implementation and operation according to the expected performance criteria Verify the implementation according to the verification plan, using the appropriate show and debug commands and applications to verify correct operation document implementation, operations, and maintenance

Information Packet The figure illustrates what you will accomplish in this activity.

Visual Objective

Visual Objective for Lab 3-5: Configure and Verify OSPF Authentication

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

220

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v 1. 0—LG-15

© 2009 Cisco Systems, Inc.

Implementation Policy The following list details the configuration requirements for all devices in the company network: Set proper initial configuration on all devices in your lab. The instructor will provide the necessary information on how to set the initial configuration on all devices. When an existing topology needs to be fine tuned, the administrator first needs to review the existing routing configuration and policy. This requires that you review the router configuration and examine the routing behavior. Examine IP routing information exchanged by routers configured with OSPF routing protocol. Routers R1, R2, R3, and R4 are configured with the OSPF routing protocol and announce their directly attached networks. Router R4 also announces some external OSPF networks into the OSPF routing domain. Once the existing topology and operation is discovered, the administrator can address and adjust the operation so that it is more precise. The security of the routing information must be properly addressed. The administrator should deploy a configuration that prevents traffic hijacking and black-hole routing caused by counterfeit routing information that is injected into the routing domain by a malicious attacker. This is achieved by deploying routing authentication, and OSPF can be affected. OSPF authentication offers very granular authentication, which is deployed on a per-interface basis. Address the OSPF routing security in OSPF Areas 3 and 24. You have decided to apply simple OSPF authentication between routers R3 and R1 to examine how authentication is working. At the same time you are concerned with the LAN segment between routers R2 and R4 and have decided to implement link authentication on that segment also. The most secure OSPF authentication should be deployed. OSPF authentication configuration and deployment can be eased by deploying area-based authentication. The area-based authentication mechanism utilizes the OSPF deployment specific – the routing topology deployed in areas. In this task you will address the OSPF routing security in OSPF Area 24. You have decided to scale the authentication in that area by deploying authentication on the LAN segment between routers R2 and R4 and on other Area 24 interfaces and segments. Verify the IP routing table, OSPF routing domain, interfaces where OSPF is enabled, OSPF adjacencies, link-state databases, and OSPF area design after each task in order to verify proper configuration.

Device Information The table provides the information specific to each switch in the network: Device Name

Role

R1

POD router

R2

POD router

R3

POD router

R4

POD router

BBR2

Backbone router

© 2009 Cisco Systems, Inc.

Lab Guide

221

Command List The table describes the commands that are used in this activity. Command

Description

ip ospf authentication

Specifies the authentication type for an interface

ip ospf authentication-key

Assigns a password to be used by neighboring routers that use Open Shortest Path First (OSPF) simple password authentication

ip ospf message-digest-key md5

Enables Open Shortest Path First (OSPF) Message Digest 5 (MD5) authentication

area authentication

Enables authentication for an OSPF area

show ip ospf

Displays general information about Open Shortest Path First (OSPF) routing processes

show ip ospf database

Displays lists of information related to the Open Shortest Path First (OSPF) database for a specific router

show ip route [ospf]

Displays whole IP routing table or OSPF routes only

show ip ospf neighbor

Displays Open Shortest Path First (OSPF) neighbor information on a per-interface basis

show ip ospf interface

Displays Open Shortest Path First (OSPF)-related interface information

Required Resources These are the resources and equipment that are required to complete this activity: A PC that is connected to an on-site laboratory or a PC with an Internet connection if remote laboratory equipment must be accessed A terminal server that is connected to the console port of each laboratory device, if using a remote laboratory Core and access switches in your pod

Job Aids These are the job aids for this lab activity:

222

Value

Location

Blank implementation requirements list

Task 1

Blank implementation and verification plan form

Task 2

Blank verification notes form

Task 3

Alternate resources and solutions form

End of this lab

Implementation requirements hints

“Hints” section at the end of this lab

Implementation and verification plan hints

“Hints” section at the end of this lab

Solution configuration answer key (step-bystep procedure)

Configuration section at the end of this lab

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Task 1: Establish an Implementation Requirements List The first step in your configuration deployment is to establish a list of what is needed in order for you to configure each device; for example, device names, trunk encapsulation types, and so on. Use the following table, the visual objective at the beginning of this lab, the implementation policy, and the device information to create your implementation requirements list. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Device

© 2009 Cisco Systems, Inc.

Implementation Requirement

Lab Guide

223

-------- The page intentionally left blank. --------

224

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Task 2: Create an Implementation and Verification Plan The second step in your configuration deployment is to establish a task list of the items that must be configured on each device, and in what order. Use the following table and the visual objective at the beginning of this lab to create your implementation and verification plan. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Complete

© 2009 Cisco Systems, Inc.

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Lab Guide

225

Complete

226

Device

Order

Implementing Cisco IP Routing (ROUTE) v1.0

Values and Items to Implement

Verification Method and Expected Results

© 2009 Cisco Systems, Inc.

Task 3: Implement and Verify Now that you have collected all the requirements and planned your implementation, you are ready to connect to the remote lab and implement your solution. Do not forget to save. Once your solution is implemented, you need to verify that your configuration is working and fulfills all the requirements specified by the customer. Keep in mind that once you leave the company, a network specialist will verify your configuration. Your ability to implement the solution according to the customer specifications will determine whether you get the job or not. Use the following area to record your notes and document the verifications you conducted to ensure that your solution is complete. If you are unsure about the verification steps, use the information provided in the “Hints” section at the end of this lab. Student Notes: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ © 2009 Cisco Systems, Inc.

Lab Guide

227

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

228

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternate Resources and Solutions Other groups may have implemented a solution different from yours. These will be discussed during the debriefing period that will follow this lab. Use the following space to document other possible solutions for your reference. __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ © 2009 Cisco Systems, Inc.

Lab Guide

229

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

230

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Hints You are encouraged to complete the labs using your knowledge. However, this section contains a series of hints to aid your completion of the lab.

Lab 3-5 Hint Sheet: Configure and Verify OSPF Authentication Implementation Requirements To facilitate the configuration of your network, Task 1 asks you to create an implementation requirements list. This list details the elements you need in order to develop an implementation plan. The following is an example of such a list: Device

Implementation Requirement

Hint

ALL

Interfaces involved in OSPF authentication

Visual Objective

ALL

Authentication type used on the interface

Implementation Policy

ALL

Authentication key used for authentication

Implementation Policy

Implementation and Verification Plan In Task 2, you will create an implementation and verification plan. Although there are several ways to set up this plan, the following tasks must be completed: Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1–R4

1

Load the initial configuration.

All pod routers must be preloaded with the initial configuration for the lab.

Step 1

Examine the OSPF routing configuration on all routers. First explore the OSPF linkstate database to gain insight into how OSPF is deployed in the network. Also observe the OSPF area configuration to determine the OSPF architecture and topology.

Step 2

R1–R4

Verify the IP routing tables for routers R1, R2, R3, and R4 to see whether the correct information was put into the routing tables and that external networks are inside the IP routing table.

© 2009 Cisco Systems, Inc.

Lab Guide

231

Complete

Device

Order

Values and Items to Implement

R1, R3

Deploy OSPF link authentication between routers R1 and R3 on the WAN segment. Remember that router R3 should not use encrypted keys for the OSPF authentication.

R2, R4

Deploy OSPF link authentication between routers R2 and R4 on the LAN segment. Deploy the most secure OSPF authentication.

R2, R4

Change the OSPF authentication on routers R2 and R4 so that they enforce the OSPF authentication on all OSPF-enabled interfaces. Remember that the configuration must be implemented with a minimum number of commands, and that if an additional interface is added to Area 24, the OSPF authentication should automatically be enforced on that interface also without having to apply additional commands.

R1

Deploy OSPF authentication on router R1 for Area 24 also. The authentication should use the most secure method available.

Verification Method and Expected Results

Step

Step 3

Examine OSPF adjacencies and verify that all the adjacencies that were up before implementing OSPF link authentication are still up and running. Router R1 should have OSPF adjacencies to routers R2, R3, R4, and BBR2. Routers R2 and R4 should have an additional adjacency between them.

Step 3

Step 4

Examine OSPF adjacencies and interfaces in order to verify that all the adjacencies that were up before implementing OSPF link authentication are still up and running. Router R1 should have OSPF adjacencies to routers R2, R3, R4, and BBR2. Routers R2 and R4 should have an additional adjacency between them.

Step 4

Step-by-Step Procedure for Implementation and Verification 1. Load the initial configuration on all devices in your lab. 1.1. The instructor will provide guidelines for changing the initial configuration.

232

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

2. Examine the OSPF routing information by verifying the OSPF link-state database to gain insight into how OSPF is deployed in the network, and to check the OSPF process and IP routing table. Îďý­¸±© ·° ±­°ş ᫬·˛ą Đ®±˝»­­ ţ±­°ş ďţ ©·¬¸ ×Ü ďňďňďňď ͬż®¬ ¬·ł»ć ë©îĽô Ě·ł» »´ż°­»Ľć đďćëěćđďňěîě Í«°°±®¬­ ±˛´§ ­·˛ą´» ĚŃÍřĚŃÍđ÷ ®±«¬»­ Í«°°±®¬­ ±°żŻ«» ÔÍß Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ Í«°°±®¬­ ż®»ż ¬®ż˛­·¬ ˝ż°żľ·´·¬§ ׬ ·­ ż˛ ż®»ż ľ±®Ľ»® ż˛Ľ ż«¬±˛±ł±«­ ­§­¬»ł ľ±«˛Ľż®§ ®±«¬»® λĽ·­¬®·ľ«¬·˛ą ۨ¬»®˛ż´ ᫬»­ ş®±łô ­¬ż¬·˝ô ·˛˝´«Ľ»­ ­«ľ˛»¬­ ·˛ ®»Ľ·­¬®·ľ«¬·±˛ ᫬»® ·­ ˛±¬ ±®·ą·˛ż¬·˛ą ®±«¬»®óÔÍß­ ©·¬¸ łż¨·ł«ł ł»¬®·˝ ײ·¬·ż´ ÍĐÚ ­˝¸»Ľ«´» Ľ»´ż§ ëđđđ ł­»˝­ Ó·˛·ł«ł ¸±´Ľ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ Óż¨·ł«ł ©ż·¬ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ ײ˝®»ł»˛¬ż´óÍĐÚ Ľ·­żľ´»Ľ Ó·˛·ł«ł ÔÍß ·˛¬»®Şż´ ë ­»˝­ Ó·˛·ł«ł ÔÍß ż®®·Şż´ ďđđđ ł­»˝­ ÔÍß ą®±«° °ż˝·˛ą ¬·ł»® îěđ ­»˝­ ײ¬»®şż˝» ş´±±Ľ °ż˝·˛ą ¬·ł»® íí ł­»˝­ 묮ż˛­ł·­­·±˛ °ż˝·˛ą ¬·ł»® ęę ł­»˝­ Ň«łľ»® ±ş »¨¬»®˛ż´ ÔÍß ěň ݸ»˝µ­«ł Í«ł đ¨đěÝđďč Ň«łľ»® ±ş ±°żŻ«» ßÍ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ż®»ż­ ·˛ ¬¸·­ ®±«¬»® ·­ íň í ˛±®łż´ đ ­¬«ľ đ ˛­­ż Ň«łľ»® ±ş ż®»ż­ ¬®ż˛­·¬ ˝ż°żľ´» ·­ đ ۨ¬»®˛ż´ ş´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż ŢßÝŐŢŃŇŰřđ÷ Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđďćëéňîçî żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ç ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» ďéîňíđňđňđńďę ß˝¬·Ş»řęë÷ ßĽŞ»®¬·­» Ň«łľ»® ±ş ÔÍß čň ݸ»˝µ­«ł Í«ł đ¨đíçíčç Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż í Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđďćđčňîîě żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ďí ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß éň ݸ»˝µ­«ł Í«ł đ¨đíçŢđî Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż îě Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ ď ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđđćëčňîîě żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ďî ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß çň ݸ»˝µ­«ł Í«ł đ¨đéęčŢŰ Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ

© 2009 Cisco Systems, Inc.

Lab Guide

233

Îîý­¸±© ·° ±­°ş ᫬·˛ą Đ®±˝»­­ ţ±­°ş ďţ ©·¬¸ ×Ü ďđňîňîňî ͬż®¬ ¬·ł»ć ë©îĽô Ě·ł» »´ż°­»Ľć đďćëíćďęňçđě Í«°°±®¬­ ±˛´§ ­·˛ą´» ĚŃÍřĚŃÍđ÷ ®±«¬»­ Í«°°±®¬­ ±°żŻ«» ÔÍß Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ Í«°°±®¬­ ż®»ż ¬®ż˛­·¬ ˝ż°żľ·´·¬§ ᫬»® ·­ ˛±¬ ±®·ą·˛ż¬·˛ą ®±«¬»®óÔÍß­ ©·¬¸ łż¨·ł«ł ł»¬®·˝ ײ·¬·ż´ ÍĐÚ ­˝¸»Ľ«´» Ľ»´ż§ ëđđđ ł­»˝­ Ó·˛·ł«ł ¸±´Ľ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ Óż¨·ł«ł ©ż·¬ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ ײ˝®»ł»˛¬ż´óÍĐÚ Ľ·­żľ´»Ľ Ó·˛·ł«ł ÔÍß ·˛¬»®Şż´ ë ­»˝­ Ó·˛·ł«ł ÔÍß ż®®·Şż´ ďđđđ ł­»˝­ ÔÍß ą®±«° °ż˝·˛ą ¬·ł»® îěđ ­»˝­ ײ¬»®şż˝» ş´±±Ľ °ż˝·˛ą ¬·ł»® íí ł­»˝­ 묮ż˛­ł·­­·±˛ °ż˝·˛ą ¬·ł»® ęę ł­»˝­ Ň«łľ»® ±ş »¨¬»®˛ż´ ÔÍß ěň ݸ»˝µ­«ł Í«ł đ¨đîÜěßŰ Ň«łľ»® ±ş ±°żŻ«» ßÍ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ż®»ż­ ·˛ ¬¸·­ ®±«¬»® ·­ ďň ď ˛±®łż´ đ ­¬«ľ đ ˛­­ż Ň«łľ»® ±ş ż®»ż­ ¬®ż˛­·¬ ˝ż°żľ´» ·­ đ ۨ¬»®˛ż´ ş´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż îě Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ î ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđďćîěňđďę żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ îđ ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß çň ݸ»˝µ­«ł Í«ł đ¨đíçęçŢ Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ Îíý­¸±© ·° ±­°ş ᫬·˛ą Đ®±˝»­­ ţ±­°ş ďţ ©·¬¸ ×Ü ďçîňďęčňíňď ͬż®¬ ¬·ł»ć ë©îĽô Ě·ł» »´ż°­»Ľć đďćëěćííňčďî Í«°°±®¬­ ±˛´§ ­·˛ą´» ĚŃÍřĚŃÍđ÷ ®±«¬»­ Í«°°±®¬­ ±°żŻ«» ÔÍß Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ Í«°°±®¬­ ż®»ż ¬®ż˛­·¬ ˝ż°żľ·´·¬§ ׬ ·­ ż˛ ż«¬±˛±ł±«­ ­§­¬»ł ľ±«˛Ľż®§ ®±«¬»® λĽ·­¬®·ľ«¬·˛ą ۨ¬»®˛ż´ ᫬»­ ş®±łô ˝±˛˛»˝¬»Ľô ·˛˝´«Ľ»­ ­«ľ˛»¬­ ·˛ ®»Ľ·­¬®·ľ«¬·±˛ ᫬»® ·­ ˛±¬ ±®·ą·˛ż¬·˛ą ®±«¬»®óÔÍß­ ©·¬¸ łż¨·ł«ł ł»¬®·˝ ײ·¬·ż´ ÍĐÚ ­˝¸»Ľ«´» Ľ»´ż§ ëđđđ ł­»˝­ Ó·˛·ł«ł ¸±´Ľ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ Óż¨·ł«ł ©ż·¬ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ ײ˝®»ł»˛¬ż´óÍĐÚ Ľ·­żľ´»Ľ Ó·˛·ł«ł ÔÍß ·˛¬»®Şż´ ë ­»˝­ Ó·˛·ł«ł ÔÍß ż®®·Şż´ ďđđđ ł­»˝­ ÔÍß ą®±«° °ż˝·˛ą ¬·ł»® îěđ ­»˝­ ײ¬»®şż˝» ş´±±Ľ °ż˝·˛ą ¬·ł»® íí ł­»˝­ 묮ż˛­ł·­­·±˛ °ż˝·˛ą ¬·ł»® ęę ł­»˝­ Ň«łľ»® ±ş »¨¬»®˛ż´ ÔÍß ěň ݸ»˝µ­«ł Í«ł đ¨đîÜěßŰ Ň«łľ»® ±ş ±°żŻ«» ßÍ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ż®»ż­ ·˛ ¬¸·­ ®±«¬»® ·­ ďň ď ˛±®łż´ đ ­¬«ľ đ ˛­­ż Ň«łľ»® ±ş ż®»ż­ ¬®ż˛­·¬ ˝ż°żľ´» ·­ đ ۨ¬»®˛ż´ ş´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż í Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ î ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđďćěčňëëę żą± 234

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ ďé ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß éň ݸ»˝µ­«ł Í«ł đ¨đîéěßę Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ Îěý­¸±© ·° ±­°ş ᫬·˛ą Đ®±˝»­­ ţ±­°ş ďţ ©·¬¸ ×Ü ďđňěňěňě ͬż®¬ ¬·ł»ć ë©îĽô Ě·ł» »´ż°­»Ľć đďćëíćîëňëéę Í«°°±®¬­ ±˛´§ ­·˛ą´» ĚŃÍřĚŃÍđ÷ ®±«¬»­ Í«°°±®¬­ ±°żŻ«» ÔÍß Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ Í«°°±®¬­ ż®»ż ¬®ż˛­·¬ ˝ż°żľ·´·¬§ ᫬»® ·­ ˛±¬ ±®·ą·˛ż¬·˛ą ®±«¬»®óÔÍß­ ©·¬¸ łż¨·ł«ł ł»¬®·˝ ײ·¬·ż´ ÍĐÚ ­˝¸»Ľ«´» Ľ»´ż§ ëđđđ ł­»˝­ Ó·˛·ł«ł ¸±´Ľ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ Óż¨·ł«ł ©ż·¬ ¬·ł» ľ»¬©»»˛ ¬©± ˝±˛­»˝«¬·Ş» ÍĐÚ­ ďđđđđ ł­»˝­ ײ˝®»ł»˛¬ż´óÍĐÚ Ľ·­żľ´»Ľ Ó·˛·ł«ł ÔÍß ·˛¬»®Şż´ ë ­»˝­ Ó·˛·ł«ł ÔÍß ż®®·Şż´ ďđđđ ł­»˝­ ÔÍß ą®±«° °ż˝·˛ą ¬·ł»® îěđ ­»˝­ ײ¬»®şż˝» ş´±±Ľ °ż˝·˛ą ¬·ł»® íí ł­»˝­ 묮ż˛­ł·­­·±˛ °ż˝·˛ą ¬·ł»® ęę ł­»˝­ Ň«łľ»® ±ş »¨¬»®˛ż´ ÔÍß ěň ݸ»˝µ­«ł Í«ł đ¨đîÜěßŰ Ň«łľ»® ±ş ±°żŻ«» ßÍ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» »¨¬»®˛ż´ ż˛Ľ ±°żŻ«» ßÍ ÔÍß đ Ň«łľ»® ±ş ż®»ż­ ·˛ ¬¸·­ ®±«¬»® ·­ ďň ď ˛±®łż´ đ ­¬«ľ đ ˛­­ż Ň«łľ»® ±ş ż®»ż­ ¬®ż˛­·¬ ˝ż°żľ´» ·­ đ ۨ¬»®˛ż´ ş´±±Ľ ´·­¬ ´»˛ą¬¸ đ ß®»ż îě Ň«łľ»® ±ş ·˛¬»®şż˝»­ ·˛ ¬¸·­ ż®»ż ·­ î ß®»ż ¸ż­ ˛± ż«¬¸»˛¬·˝ż¬·±˛ ÍĐÚ ż´ą±®·¬¸ł ´ż­¬ »¨»˝«¬»Ľ đđćđďćëđňčěě żą± ÍĐÚ ż´ą±®·¬¸ł »¨»˝«¬»Ľ îđ ¬·ł»­ ß®»ż ®ż˛ą»­ ż®» Ň«łľ»® ±ş ÔÍß çň ݸ»˝µ­«ł Í«ł đ¨đíçęçŢ Ň«łľ»® ±ş ±°żŻ«» ´·˛µ ÔÍß đň ݸ»˝µ­«ł Í«ł đ¨đđđđđđ Ň«łľ»® ±ş ÜÝľ·¬´»­­ ÔÍß đ Ň«łľ»® ±ş ·˛Ľ·˝ż¬·±˛ ÔÍß đ Ň«łľ»® ±ş ܱұ¬ßą» ÔÍß đ Ú´±±Ľ ´·­¬ ´»˛ą¬¸ đ Îďý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďňďňďňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďňďňďňď ďéîňíđňďđňę

ßÜĘ Î±«¬»® ďňďňďňď ďéîňíđňďđňę

ßą» ďęî ďëç

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđÜ đ¨đđÚÜŢě î đ¨čđđđđçÝę đ¨đđçŢçě í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďíňđ ďéîňíđňďíňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďéď ďîí çí ďěď ďďí ďîí

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđďěßß đ¨đđęŰěë đ¨đđęěěÝ đ¨đđéÚÚÝ đ¨đđíßŰë đ¨đđßîßč

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż đ÷

© 2009 Cisco Systems, Inc.

Lab Guide

235

Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ďďí

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđíčé

᫬»® Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď ďçîňďęčňíňď

ßą» ďîé ďíé

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđÚ đ¨đđđíîď î đ¨čđđđđđďđ đ¨đđčéěč í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďčě ďíę ďđę ďčě ďęě ďíę

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđďěßß đ¨đđęŰěë đ¨đđęěěÝ đ¨đđëŰďŢ đ¨đđëŢÝé đ¨đđßîßč

᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» îč ďďé îç

Í»Żý đ¨čđđđđđđŰ đ¨čđđđđđďď đ¨čđđđđđđÚ

ݸ»˝µ­«ł đ¨đđçéčé đ¨đđÜďđÝ đ¨đđÚÜÝÚ

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ďďč

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďëę ďčę ďęę ďîé

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđéÚÚÝ đ¨đđëŰďŢ đ¨đđëŢÝé đ¨đđíßŰë

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ďîé

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđíčé

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ ďçîňďęčňěňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď ďňďňďňď

ßą» ďîęě ďîęě ďîęę ďçď

Í»Żý đ¨čđđđđđđŢ đ¨čđđđđđđŢ đ¨čđđđđđđŢ đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđŰÚÝŰ đ¨đđŰěÜč đ¨đđÜçŰî đ¨đđŰŢěí

Ěżą đ đ đ đ

Îîý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňîňîňî÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» éď ďëč éď

Í»Żý đ¨čđđđđđđŰ đ¨čđđđđđďď đ¨čđđđđđđÚ

ݸ»˝µ­«ł đ¨đđçéčé đ¨đđÜďđÝ đ¨đđÚÜÝÚ

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

236

ßÜĘ Î±«¬»® ďđňěňěňě

Implementing Cisco IP Routing (ROUTE) v1.0

ßą» ďëç

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

© 2009 Cisco Systems, Inc.

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňďíňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» ďçę îîę îđę ďęč

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđéÚÚÝ đ¨đđëŰďŢ đ¨đđëŢÝé đ¨đđíßŰë

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» ďęč

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđíčé

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ ďçîňďęčňěňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď ďňďňďňď

ßą» ďíđę ďíđę ďíđę îíî

Í»Żý đ¨čđđđđđđŢ đ¨čđđđđđđŢ đ¨čđđđđđđŢ đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđŰÚÝŰ đ¨đđŰěÜč đ¨đđÜçŰî đ¨đđŰŢěí

Ěżą đ đ đ đ

Îíý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďçîňďęčňíňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďňďňďňď ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď ďçîňďęčňíňď

ßą» îďď îđę

Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬ đ¨čđđđđđđÚ đ¨đđđíîď î đ¨čđđđđđďđ đ¨đđčéěč í

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż í÷ Ô·˛µ ×Ü ďđňďňďďđňď ďđňďňďďđňî ďđňďňďďđňě ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňîěňđ

ßÜĘ Î±«¬»® ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

ßą» îëë îđé ďéé îëë îíë îđé

Í»Żý đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđďěßß đ¨đđęŰěë đ¨đđęěěÝ đ¨đđëŰďŢ đ¨đđëŢÝé đ¨đđßîßč

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ ďçîňďęčňěňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď ďňďňďňď

ßą» ďííî ďííî ďííí îęđ

Í»Żý đ¨čđđđđđđŢ đ¨čđđđđđđŢ đ¨čđđđđđđŢ đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđŰÚÝŰ đ¨đđŰěÜč đ¨đđÜçŰî đ¨đđŰŢěí

Ěżą đ đ đ đ

Îěý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňěňěňě÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďňďňďňď ďđňîňîňî ďđňěňěňě

ßą» ďîç îďé ďîč

Í»Żý đ¨čđđđđđđŰ đ¨čđđđđđďď đ¨čđđđđđđÚ

ݸ»˝µ­«ł đ¨đđçéčé đ¨đđÜďđÝ đ¨đđÚÜÝÚ

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» îďę

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü © 2009 Cisco Systems, Inc.

ßÜĘ Î±«¬»®

ßą»

Í»Żý

ݸ»˝µ­«ł Lab Guide

237

ďđňďňďďíňđ ďđňďňďďęňđ ďéîňíđňďđňđ ďéîňíđňďíňđ

ďňďňďňď ďňďňďňď ďňďňďňď ďňďňďňď

îëë îčë îęë îîé

đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď đ¨čđđđđđđď

đ¨đđéÚÚÝ đ¨đđëŰďŢ đ¨đđëŢÝé đ¨đđíßŰë

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż îě÷ Ô·˛µ ×Ü ďçîňďęčňíňď

ßÜĘ Î±«¬»® ďňďňďňď

ßą» îîé

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđíčé

̧°»óë ßÍ Ű¨¬»®˛ż´ Ô·˛µ ͬż¬»­ Ô·˛µ ×Ü ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ ďçîňďęčňěňđ

ßÜĘ Î±«¬»® ďçîňďęčňíňď ďçîňďęčňíňď ďçîňďęčňíňď ďňďňďňď

ßą» ďíęę ďíęę ďíęę îçî

Í»Żý đ¨čđđđđđđŢ đ¨čđđđđđđŢ đ¨čđđđđđđŢ đ¨čđđđđđđď

ݸ»˝µ­«ł đ¨đđŰÚÝŰ đ¨đđŰěÜč đ¨đđÜçŰî đ¨đđŰŢěí

Ěżą đ đ đ đ

Îďý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ďéîňíđňîěňđ ĹďďđńďďĂ Ş·ż ďđňďňďďđňîô đđćđíćěđô Í»®·ż´đńđńđňď Ń ďéîňíđňďđňđ ĹďďđńęëĂ Ş·ż ďđňďňďďęňęô đđćđęćđďô Í»®·ż´đńđńđňďďę Ń ďéîňíđňďíňđ ĹďďđńęëĂ Ş·ż ďđňďňďďíňíô đđćđëćîîô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňěńíî ĹďďđńďďĂ Ş·ż ďđňďňďďđňîô đđćđíćěđô Í»®·ż´đńđńđňď Ń ďđňďňďďđňîńíî ĹďďđńďđĂ Ş·ż ďđňďňďďđňîô đđćđíćěđô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđíćěđô Í»®·ż´đńđńđňî Ń Űî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđíćěđô Í»®·ż´đńđńđňî Ń Űî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđíćěđô Í»®·ż´đńđńđňî Îîý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđěćëéô Í»®·ż´đńđńđňď Ń ×ß ďéîňíđňďíňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđěćëéô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňěňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđěćëéô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňěńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňěô đđćđěćëéô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđěćëéô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďíňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđěćëéô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđěćëéô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđěćëéô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđěćëéô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđěćëéô Í»®·ż´đńđńđňď Îíý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňîěňđ ĹďďđńéëĂ Ş·ż ďđňďňďďíňďô đđćđéćđîô Í»®·ż´đńđńđňî Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďíňďô đđćđéćđîô Í»®·ż´đńđńđňî Ń Űî ďçîňďęčňěňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňďô đđćđęćíéô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ×ß ďđňďňďďđňěńíî ĹďďđńéëĂ Ş·ż ďđňďňďďíňďô đđćđęćěîô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďíňďô đđćđéćđîô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďđňîńíî ĹďďđńéěĂ Ş·ż ďđňďňďďíňďô đđćđéćđîô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďíňďô đđćđéćđîô Í»®·ż´đńđńđňî Îěý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđëćíëô Í»®·ż´đńđńđňď Ń ×ß ďéîňíđňďíňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđëćíëô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňěňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđëćíëô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđëćíëô Í»®·ż´đńđńđňď Ń ďđňďňďďđňîńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňîô đđćđëćíëô Úż­¬Ű¬¸»®˛»¬đńđ Ń ×ß ďđňďňďďíňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđëćíëô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđëćíëô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđëćíëô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđëćíëô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđëćíëô Í»®·ż´đńđńđňď 238

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

3. Enable OSPF link authentication. 3.1. Use the following example to configure the routers in this lab: Îďý ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ ·° ±­°ş ż«¬¸»˛¬·˝ż¬·±˛ ·° ±­°ş ż«¬¸»˛¬·˝ż¬·±˛óµ»§ Ý×ÍÝŃ Îîý ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° ±­°ş ż«¬¸»˛¬·˝ż¬·±˛ ł»­­żą»óĽ·ą»­¬ ·° ±­°ş ł»­­żą»óĽ·ą»­¬óµ»§ ď łĽë Ý×ÍÝŃ Îíý ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ ·° ±­°ş ż«¬¸»˛¬·˝ż¬·±˛ ·° ±­°ş ż«¬¸»˛¬·˝ż¬·±˛óµ»§ Ý×ÍÝŃ Îěý ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° ±­°ş ż«¬¸»˛¬·˝ż¬·±˛ ł»­­żą»óĽ·ą»­¬ ·° ±­°ş ł»­­żą»óĽ·ą»­¬óµ»§ ď łĽë Ý×ÍÝŃ

3.2. Verify that the authentication is successfully configured. Îďý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďéîňíđňďđňę ďçîňďęčňíňď ďđňěňěňě ďđňîňîňî

Đ®· đ đ đ đ

ͬż¬» ÚËÔÔń ÚËÔÔń ÚËÔÔń ÚËÔÔń

ó ó ó ó

Ü»żĽ Ě·ł» đđćđđćíî đđćđđćíę đđćđđćíç đđćđđćíď

߼Ľ®»­­ ďđňďňďďęňę ďđňďňďďíňí ďđňďňďďđňě ďđňďňďďđňî

ײ¬»®şż˝» Í»®·ż´đńđńđňďďę Í»®·ż´đńđńđňî Í»®·ż´đńđńđňď Í»®·ż´đńđńđňď

ͬż¬» ÚËÔÔńÜÎ ÚËÔÔń ó

Ü»żĽ Ě·ł» đđćđđćíđ đđćđđćíé

߼Ľ®»­­ ďéîňíđňîěňě ďđňďňďďđňď

ײ¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ Í»®·ż´đńđńđňď

ó

Ü»żĽ Ě·ł» đđćđđćíî

߼Ľ®»­­ ďđňďňďďíňď

ײ¬»®şż˝» Í»®·ż´đńđńđňî

ͬż¬» ÚËÔÔńŢÜÎ ÚËÔÔń ó

Ü»żĽ Ě·ł» đđćđđćíę đđćđđćíî

߼Ľ®»­­ ďéîňíđňîěňî ďđňďňďďđňď

ײ¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ Í»®·ż´đńđńđňď

Îîý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňěňěňě ďňďňďňď

Đ®· ď đ

Îíý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďňďňďňď

Đ®· đ

ͬż¬» ÚËÔÔń

Îěý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňîňîňî ďňďňďňď

Đ®· ď đ

Îďý­¸±© ·° ±­°ş ·˛¬»®şż˝» ­»®·ż´ đńđńđňî Í»®·ż´đńđńđňî ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďíňďńîěô ß®»ż í Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďňďňďňďô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđç Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńîô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ë Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďçîňďęčňíňď Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Í·ł°´» °ż­­©±®Ľ ż«¬¸»˛¬·˝ż¬·±˛ »˛żľ´»Ľ © 2009 Cisco Systems, Inc.

Lab Guide

239

Îîý­¸±© ·° ±­°ş ·˛¬»®şż˝» şżđńđ Úż­¬Ű¬¸»®˛»¬đńđ ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďéîňíđňîěňîńîěô ß®»ż îě Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňîňîňîô Ň»¬©±®µ ̧°» ŢÎŃßÜÝßÍĚô ݱ­¬ć ď Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ŢÜÎô Đ®·±®·¬§ ď Ü»­·ą˛ż¬»Ľ ᫬»® ř×Ü÷ ďđňěňěňěô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňîěňě Ţż˝µ«° Ü»­·ą˛ż¬»Ľ ®±«¬»® ř×Ü÷ ďđňîňîňîô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňîěňî Ú´«­¸ ¬·ł»® ş±® ±´Ľ ÜÎ ÔÍß Ľ«» ·˛ đđćđîćěę Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđé Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ îńîô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ î Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ ě ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňěňěňě řÜ»­·ą˛ż¬»Ľ ᫬»®÷ Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Ó»­­żą» Ľ·ą»­¬ ż«¬¸»˛¬·˝ż¬·±˛ »˛żľ´»Ľ DZ«˛ą»­¬ µ»§ ·Ľ ·­ ď Îíý­¸±© ·° ±­°ş ·˛¬»®şż˝» ­»®·ż´ đńđńđňî Í»®·ż´đńđńđňî ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďíňíńîěô ß®»ż í Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďçîňďęčňíňďô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđç Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńďô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ í Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďňďňďňď Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Í·ł°´» °ż­­©±®Ľ ż«¬¸»˛¬·˝ż¬·±˛ »˛żľ´»Ľ Îěý­¸±© ·° ±­°ş ·˛¬»®şż˝» şż­¬»¬¸»®˛»¬ đńđ Úż­¬Ű¬¸»®˛»¬đńđ ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďéîňíđňîěňěńîěô ß®»ż îě Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňěňěňěô Ň»¬©±®µ ̧°» ŢÎŃßÜÝßÍĚô ݱ­¬ć ď Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ÜÎô Đ®·±®·¬§ ď Ü»­·ą˛ż¬»Ľ ᫬»® ř×Ü÷ ďđňěňěňěô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňîěňě Ţż˝µ«° Ü»­·ą˛ż¬»Ľ ®±«¬»® ř×Ü÷ ďđňîňîňîô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňîěňî Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđđ Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ îńîô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ í Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ ě ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňîňîňî řŢż˝µ«° Ü»­·ą˛ż¬»Ľ ᫬»®÷ Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Ó»­­żą» Ľ·ą»­¬ ż«¬¸»˛¬·˝ż¬·±˛ »˛żľ´»Ľ DZ«˛ą»­¬ µ»§ ·Ľ ·­ ď

4. Enable OSPF area authentication. 4.1. Use the following example to configure routers R2 and R4 in this lab: Îîý ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ 240

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˛± ·° ±­°ş ż«¬¸»˛¬·˝ż¬·±˛ ł»­­żą»óĽ·ą»­¬ ·° ±­°ş ł»­­żą»óĽ·ą»­¬óµ»§ ď łĽë Ý×ÍÝŃ ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ ·° ±­°ş ł»­­żą»óĽ·ą»­¬óµ»§ ď łĽë Ý×ÍÝŃ ˙ ®±«¬»® ±­°ş ď ż®»ż îě ż«¬¸»˛¬·˝ż¬·±˛ ł»­­żą»óĽ·ą»­¬ Îěý ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đń𠲱 ·° ±­°ş ż«¬¸»˛¬·˝ż¬·±˛ ł»­­żą»óĽ·ą»­¬ ·° ±­°ş ł»­­żą»óĽ·ą»­¬óµ»§ ď łĽë Ý×ÍÝŃ ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ ·° ±­°ş ł»­­żą»óĽ·ą»­¬óµ»§ ď łĽë Ý×ÍÝŃ ˙ ®±«¬»® ±­°ş ď ż®»ż îě ż«¬¸»˛¬·˝ż¬·±˛ ł»­­żą»óĽ·ą»­¬

4.2. Use the following example to configure router R1 in this lab: Îďý ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ ·° ±­°ş ł»­­żą»óĽ·ą»­¬óµ»§ ď łĽë Ý×ÍÝŃ ˙ ®±«¬»® ±­°ş ď ż®»ż îě ż«¬¸»˛¬·˝ż¬·±˛ ł»­­żą»óĽ·ą»­¬

4.3. Verify that the authentication is successfully configured. Îďý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďéîňíđňďđňę ďçîňďęčňíňď ďđňěňěňě ďđňîňîňî

Đ®· đ đ đ đ

ͬż¬» ÚËÔÔń ÚËÔÔń ÚËÔÔń ÚËÔÔń

ó ó ó ó

Ü»żĽ Ě·ł» ߼Ľ®»­­ đđćđđćíë ďđňďňďďęňę đđćđđćíç ďđňďňďďíňí đđćđđćíî ďđňďňďďđňě đđćđđćíě ďđňďňďďđňî

ײ¬»®şż˝» Í»®·ż´đńđńđňďďę Í»®·ż´đńđńđňî Í»®·ż´đńđńđňď Í»®·ż´đńđńđňď

Îîý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňěňěňě ďňďňďňď

Đ®· ď đ

ͬż¬» ÚËÔÔńÜÎ ÚËÔÔń ó

Ü»żĽ Ě·ł» đđćđđćíę đđćđđćíí

߼Ľ®»­­ ďéîňíđňîěňě ďđňďňďďđňď

ײ¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ Í»®·ż´đńđńđňď

ó

Ü»żĽ Ě·ł» đđćđđćíď

߼Ľ®»­­ ďđňďňďďíňď

ײ¬»®şż˝» Í»®·ż´đńđńđňî

ͬż¬» ÚËÔÔńŢÜÎ ÚËÔÔń ó

Ü»żĽ Ě·ł» đđćđđćíě đđćđđćíđ

߼Ľ®»­­ ďéîňíđňîěňî ďđňďňďďđňď

ײ¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ Í»®·ż´đńđńđňď

Îíý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďňďňďňď

Đ®· đ

ͬż¬» ÚËÔÔń

Îěý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňîňîňî ďňďňďňď

Đ®· ď đ

Îďý­¸±© ·° ±­°ş ·˛¬»®şż˝» ­»®·ż´ đńđńđňď Í»®·ż´đńđńđňď ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďđňďńîěô ß®»ż îě Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďňďňďňďô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁÓËÔĚ×ĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁÓËÔĚ×ĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđé Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńďô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ë Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ ě ł­»˝ © 2009 Cisco Systems, Inc.

Lab Guide

241

Ň»·ą¸ľ±® ݱ«˛¬ ·­ îô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ î ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňěňěňě ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňîňîňîô ˝±­¬ ·­ ďđ Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Ó»­­żą» Ľ·ą»­¬ ż«¬¸»˛¬·˝ż¬·±˛ »˛żľ´»Ľ DZ«˛ą»­¬ µ»§ ·Ľ ·­ ď Îîý­¸±© ·° ±­°ş ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďéîňíđňîěňîńîěô ß®»ż îě Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňîňîňîô Ň»¬©±®µ ̧°» ŢÎŃßÜÝßÍĚô ݱ­¬ć ď Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ŢÜÎô Đ®·±®·¬§ ď Ü»­·ą˛ż¬»Ľ ᫬»® ř×Ü÷ ďđňěňěňěô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňîěňě Ţż˝µ«° Ü»­·ą˛ż¬»Ľ ®±«¬»® ř×Ü÷ ďđňîňîňîô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňîěňî Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđě Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ îńîô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ î Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ ě ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňěňěňě řÜ»­·ą˛ż¬»Ľ ᫬»®÷ Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Ó»­­żą» Ľ·ą»­¬ ż«¬¸»˛¬·˝ż¬·±˛ »˛żľ´»Ľ DZ«˛ą»­¬ µ»§ ·Ľ ·­ ď Í»®·ż´đńđńđňď ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďđňîńîěô ß®»ż îě Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňîňîňîô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđč Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńďô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ ď Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ ě ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďňďňďňď Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Ó»­­żą» Ľ·ą»­¬ ż«¬¸»˛¬·˝ż¬·±˛ »˛żľ´»Ľ DZ«˛ą»­¬ µ»§ ·Ľ ·­ ď Îíý­¸±© ·° ±­°ş ·˛¬»®şż˝» ­»®·ż´đńđńđňî Í»®·ż´đńđńđňî ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďíňíńîěô ß®»ż í Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďçîňďęčňíňďô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđî Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńďô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ îô łż¨·ł«ł ·­ î Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďňďňďňď Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Í·ł°´» °ż­­©±®Ľ ż«¬¸»˛¬·˝ż¬·±˛ »˛żľ´»Ľ Îěý­¸±© ·° ±­°ş ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďéîňíđňîěňěńîěô ß®»ż îě Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňěňěňěô Ň»¬©±®µ ̧°» ŢÎŃßÜÝßÍĚô ݱ­¬ć ď Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ÜÎô Đ®·±®·¬§ ď 242

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ü»­·ą˛ż¬»Ľ ᫬»® ř×Ü÷ ďđňěňěňěô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňîěňě Ţż˝µ«° Ü»­·ą˛ż¬»Ľ ®±«¬»® ř×Ü÷ ďđňîňîňîô ײ¬»®şż˝» żĽĽ®»­­ ďéîňíđňîěňî Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđé Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ îńîô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ í Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ ě ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďđňîňîňî řŢż˝µ«° Ü»­·ą˛ż¬»Ľ ᫬»®÷ Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Ó»­­żą» Ľ·ą»­¬ ż«¬¸»˛¬·˝ż¬·±˛ »˛żľ´»Ľ DZ«˛ą»­¬ µ»§ ·Ľ ·­ ď Í»®·ż´đńđńđňď ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «° ײ¬»®˛»¬ ߼Ľ®»­­ ďđňďňďďđňěńîěô ß®»ż îě Đ®±˝»­­ ×Ü ďô ᫬»® ×Ü ďđňěňěňěô Ň»¬©±®µ ̧°» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚô ݱ­¬ć ęě Ě®ż˛­ł·¬ Ü»´ż§ ·­ ď ­»˝ô ͬż¬» ĐŃ×ŇĚÁĚŃÁĐŃ×ŇĚ Ě·ł»® ·˛¬»®Şż´­ ˝±˛ş·ą«®»Ľô Ř»´´± ďđô Ü»żĽ ěđô Éż·¬ ěđô 묮ż˛­ł·¬ ë ±±ľó®»­§˛˝ ¬·ł»±«¬ ěđ Ř»´´± Ľ«» ·˛ đđćđđćđď Í«°°±®¬­ Ô·˛µó´±˝ż´ Í·ą˛ż´·˛ą řÔÔÍ÷ ײĽ»¨ ďńďô ş´±±Ľ Ż«»«» ´»˛ą¬¸ đ Ň»¨¬ đ¨đřđ÷ńđ¨đřđ÷ Ôż­¬ ş´±±Ľ ­˝ż˛ ´»˛ą¬¸ ·­ ďô łż¨·ł«ł ·­ î Ôż­¬ ş´±±Ľ ­˝ż˛ ¬·ł» ·­ đ ł­»˝ô łż¨·ł«ł ·­ đ ł­»˝ Ň»·ą¸ľ±® ݱ«˛¬ ·­ ďô ߼¶ż˝»˛¬ ˛»·ą¸ľ±® ˝±«˛¬ ·­ ď ߼¶ż˝»˛¬ ©·¬¸ ˛»·ą¸ľ±® ďňďňďňď Í«°°®»­­ ¸»´´± ş±® 𠲻·ą¸ľ±®ř­÷ Ó»­­żą» Ľ·ą»­¬ ż«¬¸»˛¬·˝ż¬·±˛ »˛żľ´»Ľ DZ«˛ą»­¬ µ»§ ·Ľ ·­ ď Îďý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ďéîňíđňîěňđ ĹďďđńďďĂ Ş·ż ďđňďňďďđňîô đđćđëćěęô Í»®·ż´đńđńđňď Ń ďéîňíđňďđňđ ĹďďđńęëĂ Ş·ż ďđňďňďďęňęô đđćďçćíîô Í»®·ż´đńđńđňďďę Ń ďéîňíđňďíňđ ĹďďđńęëĂ Ş·ż ďđňďňďďíňíô đđćďčćëíô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňěńíî ĹďďđńďďĂ Ş·ż ďđňďňďďđňîô đđćđëćěęô Í»®·ż´đńđńđňď Ń ďđňďňďďđňîńíî ĹďďđńďđĂ Ş·ż ďđňďňďďđňîô đđćđëćěęô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđëćěęô Í»®·ż´đńđńđňî Ń Űî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđëćěęô Í»®·ż´đńđńđňî Ń Űî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňíô đđćđëćěęô Í»®·ż´đńđńđňî Îîý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđëćëëô Í»®·ż´đńđńđňď Ń ×ß ďéîňíđňďíňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđëćëëô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňěňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđëćëëô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňěńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňěô đđćđëćëëô Úż­¬Ű¬¸»®˛»¬đńđ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđëćëëô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďíňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđëćëëô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđëćëëô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđëćëëô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđëćëëô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđëćëëô Í»®·ż´đńđńđňď ďéîňíđňđňđńďę ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ô î łż­µ­ Îíý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňîěňđ ĹďďđńéëĂ Ş·ż ďđňďňďďíňďô đđćđéćđěô Í»®·ż´đńđńđňî Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďíňďô đđćîđćďîô Í»®·ż´đńđńđňî Ń Űî ďçîňďęčňěňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďíňďô đđćďçćěéô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ×ß ďđňďňďďđňěńíî ĹďďđńéëĂ Ş·ż ďđňďňďďíňďô đđćđéćđěô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďíňďô đđćîđćďîô Í»®·ż´đńđńđňî Ń ×ß ďđňďňďďđňîńíî ĹďďđńéěĂ Ş·ż ďđňďňďďíňďô đđćđéćđěô Í»®·ż´đńđńđňî © 2009 Cisco Systems, Inc.

Lab Guide

243

Ń ×ß

ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďíňďô đđćîđćďîô Í»®·ż´đńđńđňî

Îěý­¸±© ·° ®±«¬» ±­°ş Îěý­¸±© ·° ®±«¬» ±­°ş ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ Ń ×ß ďéîňíđňďđňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđéćîěô Í»®·ż´đńđńđňď Ń ×ß ďéîňíđňďíňđ ĹďďđńďîçĂ Ş·ż ďđňďňďďđňďô đđćđéćîěô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňěňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđéćîěô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­ Ń ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđéćîěô Í»®·ż´đńđńđňď Ń ďđňďňďďđňîńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňîô đđćđéćîěô Úż­¬Ű¬¸»®˛»¬đńđ Ń ×ß ďđňďňďďíňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđéćîěô Í»®·ż´đńđńđňď Ń ×ß ďđňďňďďęňđńîě ĹďďđńďîčĂ Ş·ż ďđňďňďďđňďô đđćđéćîěô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđéćîěô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđéćîěô Í»®·ż´đńđńđňď Ń Űî ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđéćîěô Í»®·ż´đńđńđňď

244

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

------- The page intentionally left blank. --------

© 2009 Cisco Systems, Inc.

Lab Guide

245

Lab 4-1: Configure Route Redistribution Between Multiple IP Routing Protocols Complete this lab activity to practice what you learned in the related module.

Activity Objective In this activity, you will use correct commands, tools, and steps to configure and verify route redistribution between multiple IP routing protocols. After completing this activity, you will be able to meet these objectives: Configure and verify different routing protocols in the network Select the required tools and commands to configure redistribution between different routing protocols Make a list of configuration and implementation steps Write a verification and test plan to verify the proper implementation and operation according to the expected performance criteria. Verify the configuration and operation by using the proper show and debug commands

Information Packet The figure illustrates what you will accomplish in this activity.

Visual Objective

Visual Objective for Lab 4-1: Configure Route Redistribution Between Multiple IP Routing Protocols

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

246

Implementing Cisco IP Routing (ROUTE) v1.0

ROUTE v 1. 0—LG-16

© 2009 Cisco Systems, Inc.

Implementation Policy The following list details the configuration requirements for all devices in the company network: Set proper initial configuration on all devices in your lab. The instructor will provide the necessary information on how to set initial the configuration on all devices. Multiple routing protocols must be deployed in your network. RIPv2, EIGRP, and OSPF must be configured in order to start the redistribution. Routers R3 and R1 will use the RIPv2 routing protocol to exchange routing information. Routers R1, R2, and R4 will use the OSPF routing protocol to exchange routing information, and router R1 will use EIGRP to exchange routing information with router BBR2. Configuration must be verified in order to proceed to the next step. Verify that the RIPv2 protocol is running between routers R1 and R3. Make sure that router R1 can access the RIPv2-announced routes from router R1. Verify that the EIGRP routing protocol is up and running between routers R1 and BBR2. Make sure that router R1 receives routes announced by BBR2 and that these routes are accessible. Examine and verify that the OSPF routing protocol is up and running between routers R1, R2, and R4. Make sure that routers have established the adjacencies and that R1has received the IP subnet from the LAN segment between routers R2 and R4. Verify that R1 has connectivity to the networks. After successful configuration of the routing protocols, redistribution must take place. Redistribute connected loopback interfaces in RIP to announce them to router R1. Configure the RIP-to-EIGRP redistribution with filtering to allow access to only one of the loopback interfaces. Because the RIP-to-EIGRP redistribution will be in one direction only (one way), you must configure a static default route on router R3 to provide connectivity to selected RIPv2 routing domain routes. Examine the RIPv2 database on routers R1 and R3 and verify that the R3 loopback networks are present in the RIP table as a result of redistribution. Add an additional loopback network to router R3 and verify that the network is not redistributed into RIPv2, and that router R1 does not receive that information. Verify that you have connectivity from router R3 to the BBR2 LAN segment. The next task to be preformed is the configuration of the redistribution between the OSPF and EIGRP domains. You will deploy two-way redistribution to achieve full IP connectivity between the routing domains. Additionally you will configure two-way redistribution between the OSPF and RIP routing domains. Examine the RIP routing information on router R3 and verify that the routes from the OSPF routing domain are present in the RIP database and IP routing table. The EIGRP topology table on router R1 must contain routes that originated in OSPF. Verify that the OSPF database and IP routing table on routers R2 and R4 hold the information about the RIP and EIGRP redistributed routes. Verify that you have connectivity from the R2 LAN segment to the BBR2 LAN segment, and that there is connectivity from the R3 LAN segment to the R2 LAN segment.

© 2009 Cisco Systems, Inc.

Lab Guide

247

Device Information The table provides the information specific to each switch in the network:

248

Device name

Role

R1

POD router

R2

POD router

R3

POD router

R4

POD router

BBR2

Backbone router

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Command List The table describes the commands that are used in this activity. Command

Description

router rip

Configures the RIP routing process

version

Specifies a RIP version used globally by the router

network (RIP)

Specifies a list of networks for the RIP routing process

[no] auto-summary (RIP)

Restores the default behavior of automatic summarization of subnet routes into network-level routes

show ip rip database

Displays summary address entries in the RIP routing database entries; if relevant, displays whether routes are being summarized based upon a summary address

show ip route

Displays whole IP routing table

Router ospf

Configures an OSPF routing process

ip ospf network point-tomultipoint

Configures the OSPF network type to a type other than the default for a given medium

ip ospf hello-interval

Specifies the interval between hello packets that the Cisco IOS software sends on the interface

log-adjacency-changes

Configures the router to send a syslog message when an OSPF neighbor goes up or down

network area

Defines the interfaces on which OSPF runs and defines the area ID for those interfaces

Show ip ospf database

Display lists of information related to the OSPF database for a specific router

Show ip ospf neighbor

Displays OSPF neighbor information on a per-interface basis

Router eigrp

Configures the EIGRP process

network (EIGRP)

Specifies the network for an EIGRP routing process

Show ip eigrp neighbors

Displays neighbors discovered by EIGRP

Show ip eigrp topology

Displays entries in the EIGRP topology table

redistribute (IP)

Redistributes routes from one routing domain into another routing domain

distribute-list in (IP)

Filters networks received in updates

distribute-list out (IP)

Suppresses networks from being advertised in updates

ip prefix-list

Creates a prefix list or adds a prefix list entry

route-map

Defines the conditions for redistributing routes from one routing protocol into another, or enables policy routing

default-metric (eigrp)

Sets metrics for the EIGRP

ip route

Establishes static routes

ping

Diagnoses basic network connectivity

router ospf 1

Configures an OSPF routing process

© 2009 Cisco Systems, Inc.

Lab Guide

249

Required Resources These are the resources and equipment that are required to complete this activity: A PC that is connected to an on-site laboratory or a PC with an Internet connection if remote laboratory equipment must be accessed A terminal server that is connected to the console port of each laboratory device, if using a remote laboratory Core and access switches in your pod

Job Aids These are the job aids for this lab activity:

250

Value

Location

Blank implementation requirements list

Task 1

Blank implementation and verification plan form

Task 2

Blank verification notes form

Task 3

Alternate resources and solutions form

End of this lab

Implementation requirements hints

“Hints” section at the end of this lab

Implementation and verification plan hints

“Hints” section at the end of this lab

Solution configuration answer key (step-bystep procedure)

Configuration section at the end of this lab

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

------- The page intentionally left blank. --------

© 2009 Cisco Systems, Inc.

Lab Guide

251

Task 1: Establish an Implementation Requirements List The first step in your configuration deployment is to establish a list of what is needed in order for you to configure each device; for example, device names, trunk encapsulation types, and so on. Use the following table, the visual objective at the beginning of this lab, the implementation policy, and the device information to create your implementation requirements list. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Device

252

Implementation Requirement

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

-------- The page intentionally left blank. --------

© 2009 Cisco Systems, Inc.

Lab Guide

253

Task 2: Create an Implementation and Verification Plan The second step in your configuration deployment is to establish a task list of the items that must be configured on each device, and in what order. Use the following table and the visual objective at the beginning of this lab to create your implementation and verification plan. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Complete

254

Device

Order

Implementing Cisco IP Routing (ROUTE) v1.0

Values and Items to Implement

Verification Method and Expected Results

© 2009 Cisco Systems, Inc.

Complete

© 2009 Cisco Systems, Inc.

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Lab Guide

255

Task 3: Implement and Verify Now that you have collected all the requirements and planned your implementation, you are ready to connect to the remote lab and implement your solution. Do not forget to save. Once your solution is implemented, you need to verify that your configuration is working and fulfills all the requirements specified by the customer. Keep in mind that once you leave the company, a network specialist will verify your configuration. Your ability to implement the solution according to the customer specifications will determine whether you get the job or not. Use the following area to record your notes and document the verifications you conducted to ensure that your solution is complete. If you are unsure about the verification steps, use the information provided in the “Hints” section at the end of this lab. Student Notes: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

256

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternate Resources and Solutions Other groups may have implemented a solution that is different from yours. These will be discussed during the debriefing period that will follow this lab. Use the following space to document other possible solutions for your reference. __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

© 2009 Cisco Systems, Inc.

Lab Guide

257

Hints You are encouraged to complete the labs using your knowledge. However, this section contains a series of hints to aid your completion of the lab.

Lab 4-1 Hint Sheet: Configure Route Redistribution Between Multiple IP Routing Protocols Implementation Requirements To facilitate the configuration of your network, Task 1 asks you to create an implementation requirements list. This list details the elements you need in order to develop an implementation plan. The following is an example of such a list: Device

Implementation Requirement

Hint

ALL

Interfaces involved in routing protocol configuration

Visual Objective

ALL

Where redistribution takes place

Implementation Policy

ALL

What needs to be redistributed

Implementation Policy

Implementation and Verification Plan In Task 2, you will create an implementation and verification plan. Although there are several ways to set up this plan, the following tasks must be completed: Complete

258

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1–R4

1

Load the initial configuration.

All pod routers must be preloaded with the initial configuration for the lab.

Step 1

2

Configure the RIPv2 routing protocol on routers R1 and R3 and advertise the R3 LAN segment. Routers should exchange RIPv2 only over the WAN segment that interconnects them.

Examine and verify that the RIPv2 protocol is running between routers R1 and R3. Make sure that router R1 can access the RIPv2-announced routes from router R1.

Step 2

Configure routers R1, R2, and R4 to exchange routing information using OSPF. On router R1, the process should include only the WAN segment that connects router R1 to routers R2 and R4. Routers R2 and R4 should also include the LAN segment in the OSPF process. Only a single area should be deployed.

Examine and verify that the EIGRP routing protocol is up and running between routers R1 and BBR2. Make sure that router R1 receives routes announced by BBR2 and that these routes are accessible.

Step 3

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Complete

Device

© 2009 Cisco Systems, Inc.

Order

Values and Items to Implement

Verification Method and Expected Results

Step

Configure the EIGRP routing protocol on router R1 and include only the interface that connects router R1 to router BBR2. BBR2 is preconfigured with EIGRP AS 1.

Examine and verify that the OSPF routing protocolsis up and running between routers R1, R2, and R4. Make sure that the routers have established adjacencies and that R1 has received the IP subnet from the LAN segment between routers R2 and R4. Verify that R1 has connectivity to the networks.

Step 4

Redistribute the IP subnets configured on the loopback interfaces on router R3 into the RIPv2 routing domain. Only IP subnets that are currently configured on the existing loopback interfaces should be redistributed, even if new subnets are added in the future. Do not use an access list or route maps to accomplish filtering.

Examine the RIPv2 database on routers R1 and R3 and verify that R3 loopback networks are present in the RIP table as a result of redistribution.

Step 5

Redistribute RIPv2 routes to the EIGRP routing domain on router R1. Make sure that after the redistribution, only the 192.168.1.0/24 loopback networks is redistributed into the EIGRP routing domain and not any other R3-deployed loopback network. You cannot use distribute lists to provide filtering upon redistribution.

Add an additional loopback network to router R3 and verify that the network is not redistributed into RIPv2 and that router R1 does not receive that information.

Step 6

Configure a static route on router R3 to establish connectivity in the opposite direction.

Verify that you have connectivity from router R3 to the router BBR2 LAN segment.

Step 7

Redistribute routing information from OSPF to the EIGRP routing domain and vice versa on router R1.

Examine the EIGRP topology table on router R1 and confirm that OSPF-originated routes are present.

Step 8

Examine the IP routing tables on routers R1 and R3 and confirm that the requested routes are present.

Lab Guide

259

Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

Redistribute from the OSPF to the RIP routing domain and vice versa. Make sure that only RIP-originated routes are redistributed into the OSPF domain and that only OSPF-originated routes are redistributed into the RIP routing domain.

Examine the RIP routing information on router R3 and verify that routes from the OSPF routing domain are present in the RIP database and IP routing table.

Step 9

Verify that the OSPF database and IP routing table on routers R2 and R4 contain the information about the RIP and EIGRP redistributed routes. Verify that you have connectivity from the R2 LAN segment to the BBR2 LAN segment. Verify that you have connectivity from the R3 LAN segment to the R2 LAN segment.

Step-by-Step Procedure for Implementation and Verification 1. Load the initial configuration on all devices in your lab. 1.1. The instructor will provide guidelines for changing the initial configuration. 2. Enable the RIP routing protocol. 2.1. Use the following example to configure the routers in this lab: Îďý ®±«¬»® ®·° Ş»®­·±˛ î ˛»¬©±®µ ďđňđňđň𠲱 ż«¬±ó­«łłż®§ Îíý ®±«¬»® ®·° Ş»®­·±˛ î ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§

2.2. Verify that RIP is successfully configured. Îďý­¸±© ·° ®·° Ľż¬żľż­» ďđňđňđňđńč ż«¬±ó­«łłż®§ ďđňďňďňďńíî Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ ďđňďňďďđňđńîě Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňď ďđňďňďďíňđńîě Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňî ďđňďňďďęňđńîě Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňďďę ďđňíňíňíńíî ĹďĂ Ş·ż ďđňďňďďíňíô đđćđđćđęô Í»®·ż´đńđńđňî ďéîňíđňđňđńďę ż«¬±ó­«łłż®§ ďéîňíđňďíňđńîě ĹďĂ Ş·ż ďđňďňďďíňíô đđćđđćđęô Í»®·ż´đńđńđňî 260

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Îíý­¸±© ·° ®·° Ľż¬żľż­» ďđňđňđňđńč ż«¬±ó­«łłż®§ ďđňďňďňďńíî ĹďĂ Ş·ż ďđňďňďďíňďô đđćđđćîđô Í»®·ż´đńđńđňî ďđňďňďďđňđńîě ĹďĂ Ş·ż ďđňďňďďíňďô đđćđđćîđô Í»®·ż´đńđńđňî ďđňďňďďíňđńîě Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňî ďđňďňďďęňđńîě ĹďĂ Ş·ż ďđňďňďďíňďô đđćđđćîđô Í»®·ż´đńđńđňî ďđňíňíňíńíî Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ ďéîňíđňđňđńďę ż«¬±ó­«łłż®§ ďéîňíđňďíňđńîě Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ Îďý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Î Î Ý Ý Ý Ý

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­ ďéîňíđňďíňđ ĹďîđńďĂ Ş·ż ďđňďňďďíňíô đđćđđćđíô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ô î łż­µ­ ďđňíňíňíńíî ĹďîđńďĂ Ş·ż ďđňďňďďíňíô đđćđđćđíô Í»®·ż´đńđńđňî ďđňďňďňďńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ ďđňďňďďđňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňď ďđňďňďďíňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňî ďđňďňďďęňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňďďę

Îíý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ý Ý Î Î Ý Î Ý Ý Ý

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­ ďéîňíđňďíňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ô î łż­µ­ ďđňíňíňíńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ ďđňďňďňďńíî ĹďîđńďĂ Ş·ż ďđňďňďďíňďô đđćđđćîîô Í»®·ż´đńđńđňî ďđňďňďďđňđńîě ĹďîđńďĂ Ş·ż ďđňďňďďíňďô đđćđđćîîô Í»®·ż´đńđńđňî ďđňďňďďíňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňî ďđňďňďďęňđńîě ĹďîđńďĂ Ş·ż ďđňďňďďíňďô đđćđđćîîô Í»®·ż´đńđńđňî ďçîňďęčňďňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíď ďçîňďęčňîňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíî ďçîňďęčňíňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíí

3. Enable the OSPF routing protocol. 3.1. Use the following example to configure the routers in this lab: Îďý ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ © 2009 Cisco Systems, Inc.

Lab Guide

261

˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż đ Îîý ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż 𠲻¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż đ Îěý ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż 𠲻¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż đ

3.2. Verify that OSPF is successfully configured. Îďý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňďňďňď÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďđňďňďňď ďđňîňîňî ďđňěňěňě

ßą» čçđ çęí čçî

Í»Żý đ¨čđđđđđđě đ¨čđđđđđđí đ¨čđđđđđđě

ݸ»˝µ­«ł đ¨đđíęßÜ đ¨đđÜÚÝě đ¨đđŰŰßě

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» çęě

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Îďý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňěňěňě ďđňîňîňî

Đ®· đ đ

ͬż¬» ÚËÔÔń ÚËÔÔń

ó ó

Ü»żĽ Ě·ł» đđćđđćíď đđćđđćíď

߼Ľ®»­­ ďđňďňďďđňě ďđňďňďďđňî

ײ¬»®şż˝» Í»®·ż´đńđńđňď Í»®·ż´đńđńđňď

Îďý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ń Î Î Ý Ń Ý Ń Ý 262

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ ďéîňíđňîěňđ ĹďďđńęëĂ Ş·ż ďđňďňďďđňěô đđćđíćëďô Í»®·ż´đńđńđňď ĹďďđńęëĂ Ş·ż ďđňďňďďđňîô đđćđíćëďô Í»®·ż´đńđńđňď ďéîňíđňďíňđ ĹďîđńďĂ Ş·ż ďđňďňďďíňíô đđćđđćďěô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­ ďđňíňíňíńíî ĹďîđńďĂ Ş·ż ďđňďňďďíňíô đđćđđćďěô Í»®·ż´đńđńđňî ďđňďňďňďńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ ďđňďňďďđňěńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňěô đđćđíćëďô Í»®·ż´đńđńđňď ďđňďňďďđňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňď ďđňďňďďđňîńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňîô đđćđíćëďô Í»®·ż´đńđńđňď ďđňďňďďíňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňî

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ý

ďđňďňďďęňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňďďę

Îîý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňîňîňî÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďđňďňďňď ďđňîňîňî ďđňěňěňě

ßą» çďç çčč çďč

Í»Żý đ¨čđđđđđđě đ¨čđđđđđđí đ¨čđđđđđđě

ݸ»˝µ­«ł đ¨đđíęßÜ đ¨đđÜÚÝě đ¨đđŰŰßě

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» çčç

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Îîý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňěňěňě ďđňďňďňď

Đ®· ď đ

ͬż¬» ÚËÔÔńÜÎ ÚËÔÔń ó

Ü»żĽ Ě·ł» đđćđđćíé đđćđđćíç

߼Ľ®»­­ ďéîňíđňîěňě ďđňďňďďđňď

ײ¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ Í»®·ż´đńđńđňď

Îîý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ý Ý Ń Ń Ý

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­ ďéîňíđňîěňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ô î łż­µ­ ďđňîňîňîńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ ďđňďňďďđňěńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňěô đđćđëćëçô Úż­¬Ű¬¸»®˛»¬đńđ ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđëćëçô Í»®·ż´đńđńđňď ďđňďňďďđňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňď

Îěý­¸±© ·° ±­°ş Ľż¬żľż­» ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňěňěňě÷ řĐ®±˝»­­ ×Ü ď÷ ᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďđňďňďňď ďđňîňîňî ďđňěňěňě

ßÜĘ Î±«¬»® ďđňďňďňď ďđňîňîňî ďđňěňěňě

ßą» çęď ďđíí çęđ

Í»Żý đ¨čđđđđđđě đ¨čđđđđđđí đ¨čđđđđđđě

ݸ»˝µ­«ł đ¨đđíęßÜ đ¨đđÜÚÝě đ¨đđŰŰßě

Ô·˛µ ˝±«˛¬ í í í

Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷ Ô·˛µ ×Ü ďéîňíđňîěňě

ßÜĘ Î±«¬»® ďđňěňěňě

ßą» ďđíî

Í»Żý ݸ»˝µ­«ł đ¨čđđđđđđď đ¨đđđďďę

Îěý­¸±© ·° ±­°ş ˛»·ą¸ľ±® Ň»·ą¸ľ±® ×Ü ďđňîňîňî ďđňďňďňď

Đ®· ď đ

ͬż¬» ÚËÔÔńŢÜÎ ÚËÔÔń ó

Ü»żĽ Ě·ł» đđćđđćíď đđćđđćíě

߼Ľ®»­­ ďéîňíđňîěňî ďđňďňďďđňď

ײ¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ Í»®·ż´đńđńđňď

Îěý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż © 2009 Cisco Systems, Inc.

Lab Guide

263

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ý Ý Ń Ý Ń

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­ ďéîňíđňîěňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ô î łż­µ­ ďđňěňěňěńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđčćđęô Í»®·ż´đńđńđňď ďđňďňďďđňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňď ďđňďňďďđňîńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňîô đđćđčćđęô Úż­¬Ű¬¸»®˛»¬đńđ

4. Enable the EIGRP routing protocol. 4.1. Use the following example to configure the routers in this lab: Îďý ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňďňďďęňđ đňđňđňîëë

4.2. Verify that EIGRP is successfully configured. Îďý­¸±© ·° »·ą®° ˛»·ą¸ľ±®­ ×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ď Ř ßĽĽ®»­­ ײ¬»®şż˝» đ

ďđňďňďďęňę

Í»đńđńđňďďę

ر´Ľ Ë°¬·ł» ÍÎĚĚ ř­»˝÷ řł­÷ ďí đđćďíćëđ ďîîđ

ÎĚŃ

Ď Í»Ż ݲ¬ Ň«ł ëđđđ đ ęđ

Îďý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďđňďňďňď÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďđňďňďďęňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňďďę Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďďęňę řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňďďę Îďý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ń Ü Î Î Ý Ý Ý Ý

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ ďéîňíđňîěňđ ĹďďđńęëĂ Ş·ż ďđňďňďďđňěô đđćďîćđđô Í»®·ż´đńđńđňď ĹďďđńęëĂ Ş·ż ďđňďňďďđňîô đđćďîćđđô Í»®·ż´đńđńđňď ďéîňíđňďđňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďęňęô đđćďîćđđô Í»®·ż´đńđńđňďďę ďéîňíđňďíňđ ĹďîđńďĂ Ş·ż ďđňďňďďíňíô đđćđđćîíô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ô î łż­µ­ ďđňíňíňíńíî ĹďîđńďĂ Ş·ż ďđňďňďďíňíô đđćđđćîíô Í»®·ż´đńđńđňî ďđňďňďňďńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ ďđňďňďďđňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňď ďđňďňďďíňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňî ďđňďňďďęňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňďďę

5. Enable redistribution into the RIP routing protocol. 264

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

5.1. Use the following example to configure the routers in this lab: Îíý ®±«¬»® ®·° ®»Ľ·­¬®·ľ«¬» ˝±˛˛»˝¬»Ľ Ľ·­¬®·ľ«¬»ó´·­¬ °®»ş·¨ ĐÔóÎ×Đ ±«¬ ˝±˛˛»˝¬»Ľ ˙ ·° °®»ş·¨ó´·­¬ ĐÔóÎ×Đ ­»Ż ë °»®ł·¬ ďçîňďęčňďňđńîě ·° °®»ş·¨ó´·­¬ ĐÔóÎ×Đ ­»Ż ďđ °»®ł·¬ ďçîňďęčňîňđńîě ·° °®»ş·¨ó´·­¬ ĐÔóÎ×Đ ­»Ż ďë °»®ł·¬ ďçîňďęčňíňđńîě

5.2. Verify that redistribution is successfully configured. Îďý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ń Ü Î Î Ý Ń Ý Ń Ý Ý Î Î Î

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ ďéîňíđňîěňđ ĹďďđńęëĂ Ş·ż ďđňďňďďđňěô đđćďîćëéô Í»®·ż´đńđńđňď ĹďďđńęëĂ Ş·ż ďđňďňďďđňîô đđćďîćëéô Í»®·ż´đńđńđňď ďéîňíđňďđňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďęňęô đđćđîćîëô Í»®·ż´đńđńđňďďę ďéîňíđňďíňđ ĹďîđńďĂ Ş·ż ďđňďňďďíňíô đđćđđćđčô Í»®·ż´đńđńđňî ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­ ďđňíňíňíńíî ĹďîđńďĂ Ş·ż ďđňďňďďíňíô đđćđđćđčô Í»®·ż´đńđńđňî ďđňďňďňďńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ ďđňďňďďđňěńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňěô đđćďîćëéô Í»®·ż´đńđńđňď ďđňďňďďđňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňď ďđňďňďďđňîńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňîô đđćďîćëéô Í»®·ż´đńđńđňď ďđňďňďďíňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňî ďđňďňďďęňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňďďę ďçîňďęčňďňđńîě ĹďîđńďĂ Ş·ż ďđňďňďďíňíô đđćđđćďđô Í»®·ż´đńđńđňî ďçîňďęčňîňđńîě ĹďîđńďĂ Ş·ż ďđňďňďďíňíô đđćđđćďđô Í»®·ż´đńđńđňî ďçîňďęčňíňđńîě ĹďîđńďĂ Ş·ż ďđňďňďďíňíô đđćđđćďđô Í»®·ż´đńđńđňî

6. Enable redistribution into the EIGRP routing protocol. 6.1. Use the following example to configure the routers in this lab: Îďý ®±«¬»® »·ą®° ď ®»Ľ·­¬®·ľ«¬» ®·° ®±«¬»ółż° ÎÓóÎ×Đ Ľ»şż«´¬ół»¬®·˝ ďëđđ ďđđ îëë ď ďëđđ ˙ ·° ż˝˝»­­ó´·­¬ ­¬ż˛Ľż®Ľ ßÝÔóÎ×Đ °»®ł·¬ ďçîňďęčňîňđ đňđňđňîëë °»®ł·¬ ďçîňďęčňíňđ đňđňđňîëë ˙ ®±«¬»ółż° ÎÓóÎ×Đ Ľ»˛§ ďđ łż¬˝¸ ·° żĽĽ®»­­ ßÝÔóÎ×Đ ˙ ®±«¬»ółż° ÎÓóÎ×Đ °»®ł·¬ çç

6.2. Verify that redistribution is successfully configured. Îďý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďđňďňďňď÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďđňíňíňíńíîô ď ­«˝˝»­­±®­ô ÚÜ ·­ ďéíîđçę © 2009 Cisco Systems, Inc.

Lab Guide

265

Ş·ż λĽ·­¬®·ľ«¬»Ľ řďéíîđçęńđ÷ Đ ďđňďňďňďńíîô ď ­«˝˝»­­±®­ô ÚÜ ·­ ďéíîđçę Ş·ż λĽ·­¬®·ľ«¬»Ľ řďéíîđçęńđ÷ Đ ďđňďňďďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ ďéíîđçę Ş·ż λĽ·­¬®·ľ«¬»Ľ řďéíîđçęńđ÷ Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ ďéíîđçę Ş·ż λĽ·­¬®·ľ«¬»Ľ řďéíîđçęńđ÷ Đ ďđňďňďďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ ďéíîđçę Ş·ż λĽ·­¬®·ľ«¬»Ľ řďéíîđçęńđ÷ Đ ďđňďňďďęňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňďďę Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďďęňę řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňďďę Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ ďéíîđçę Ş·ż λĽ·­¬®·ľ«¬»Ľ řďéíîđçęńđ÷

7. Enable additional connectivity. 7.1. Use the following example to configure router R3 in this lab: Îíý ·° ®±«¬» đňđňđňđ đňđňđňđ ďđňďňďďíňď

7.2. Verify that redistribution is successfully configured. Îíý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ďđňďňďďíňď ¬± ˛»¬©±®µ đňđňđňđ Ý Ý Î Î Ý Î Ý Ý Ý Íö

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­ ďéîňíđňďíňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ô î łż­µ­ ďđňíňíňíńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ ďđňďňďňďńíî ĹďîđńďĂ Ş·ż ďđňďňďďíňďô đđćđđćďęô Í»®·ż´đńđńđňî ďđňďňďďđňđńîě ĹďîđńďĂ Ş·ż ďđňďňďďíňďô đđćđđćďęô Í»®·ż´đńđńđňî ďđňďňďďíňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňî ďđňďňďďęňđńîě ĹďîđńďĂ Ş·ż ďđňďňďďíňďô đđćđđćďęô Í»®·ż´đńđńđňî ďçîňďęčňďňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíď ďçîňďęčňîňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíî ďçîňďęčňíňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíí đňđňđňđńđ ĹďńđĂ Ş·ż ďđňďňďďíňď

Îíý°·˛ą ďéîňíđňďđňę ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňíđňďđňęô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďçńďěđ ł­ Îíý°·˛ą ďéîňíđňďđňę ­±«®˝» ďçîňďęčňďňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňíđňďđňęô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć Đż˝µ»¬ ­»˛¬ ©·¬¸ ż ­±«®˝» żĽĽ®»­­ ±ş ďçîňďęčňďňď ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďëńďîě ł­ Îíý°·˛ą ďéîňíđňďđňę ­±«®˝» ďçîňďęčňîňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňíđňďđňęô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć 266

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Đż˝µ»¬ ­»˛¬ ©·¬¸ ż ­±«®˝» żĽĽ®»­­ ±ş ďçîňďęčňîňď ňňňňň Í«˝˝»­­ ®ż¬» ·­ đ °»®˝»˛¬ řđńë÷

8. Configure redistribution between OSPF and EIGRP. 8.1. Use the following example to configure router R1 in this lab: Îďý ®±«¬»® »·ą®° ď ®»Ľ·­¬®·ľ«¬» ±­°ş ď ˙ ®±«¬»® ±­°ş ď ®»Ľ·­¬®·ľ«¬» »·ą®° ď ­«ľ˛»¬­

8.2. Verify that redistribution is successfully configured. Îďý­¸±© ·° »·ą®° ¬±°±´±ą§ ×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřď÷ń×Üřďđňďňďňď÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďđňíňíňíńíîô ď ­«˝˝»­­±®­ô ÚÜ ·­ ďéíîđçę Ş·ż λĽ·­¬®·ľ«¬»Ľ řďéíîđçęńđ÷ Đ ďđňďňďňďńíîô ď ­«˝˝»­­±®­ô ÚÜ ·­ ďéíîđçę Ş·ż λĽ·­¬®·ľ«¬»Ľ řďéíîđçęńđ÷ Đ ďđňďňďďđňěńíîô ď ­«˝˝»­­±®­ô ÚÜ ·­ ďéíîđçę Ş·ż λĽ·­¬®·ľ«¬»Ľ řďéíîđçęńđ÷ Đ ďđňďňďďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ ďéíîđçę Ş·ż λĽ·­¬®·ľ«¬»Ľ řďéíîđçęńđ÷ Đ ďđňďňďďđňîńíîô ď ­«˝˝»­­±®­ô ÚÜ ·­ ďéíîđçę Ş·ż λĽ·­¬®·ľ«¬»Ľ řďéíîđçęńđ÷ Đ ďçîňďęčňďňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ ďéíîđçę Ş·ż λĽ·­¬®·ľ«¬»Ľ řďéíîđçęńđ÷ Đ ďđňďňďďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ ďéíîđçę Ş·ż λĽ·­¬®·ľ«¬»Ľ řďéíîđçęńđ÷ Đ ďđňďňďďęňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđńđňďďę Đ ďéîňíđňîěňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ ďéíîđçę Ş·ż λĽ·­¬®·ľ«¬»Ľ řďéíîđçęńđ÷ ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô ® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­ Đ ďéîňíđňďđňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďéîěďę Ş·ż ďđňďňďďęňę řîďéîěďęńîčďęđ÷ô Í»®·ż´đńđńđňďďę Đ ďéîňíđňďíňđńîěô ď ­«˝˝»­­±®­ô ÚÜ ·­ ďéíîđçę Ş·ż λĽ·­¬®·ľ«¬»Ľ řďéíîđçęńđ÷ Îěý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ý Ń Űî Ý Ń Ý Ń

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ ďéîňíđňîěňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďéîňíđňďđňđ ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđíćíçô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ô î łż­µ­ ďđňěňěňěńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđíćíçô Í»®·ż´đńđńđňď ďđňďňďďđňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňď ďđňďňďďđňîńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňîô đđćđíćíçô Úż­¬Ű¬¸»®˛»¬đńđ

© 2009 Cisco Systems, Inc.

Lab Guide

267

Ń Űî

ďđňďňďďęňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđíćíçô Í»®·ż´đńđńđňď

9. Configure redistribution between OSPF and RIP. 9.1. Use the following example to configure router R1 in this lab: Îďý ®±«¬»® ±­°ş ď ®»Ľ·­¬®·ľ«¬» ®·° ­«ľ˛»¬­ ˙ ®±«¬»® ®·° ®»Ľ·­¬®·ľ«¬» ±­°ş ď

9.2. Verify that redistribution is successfully configured. Îîý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ý Ń Űî Ń Űî Ý Ń Ń Ń Ń Ý Ń Ń Ń Ń Ń

Űî Űî

Űî Űî Űî Űî Űî

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ ďéîňíđňîěňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďéîňíđňďđňđ ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđęćďďô Í»®·ż´đńđńđňď ďéîňíđňďíňđ ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđđćđéô Í»®·ż´đńđńđňď ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô č ­«ľ˛»¬­ô î łż­µ­ ďđňîňîňîńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ ďđňíňíňíńíî ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđđćđéô Í»®·ż´đńđńđňď ďđňďňďňďńíî ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđđćđéô Í»®·ż´đńđńđňď ďđňďňďďđňěńíî ĹďďđńďĂ Ş·ż ďéîňíđňîěňěô đđćđęćďďô Úż­¬Ű¬¸»®˛»¬đńđ ďđňďňďďđňďńíî ĹďďđńęěĂ Ş·ż ďđňďňďďđňďô đđćđęćďďô Í»®·ż´đńđńđňď ďđňďňďďđňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňď ďđňďňďďíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđđćđéô Í»®·ż´đńđńđňď ďđňďňďďęňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđęćďďô Í»®·ż´đńđńđňď ďçîňďęčňďňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđđćďđô Í»®·ż´đńđńđňď ďçîňďęčňîňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđđćďđô Í»®·ż´đńđńđňď ďçîňďęčňíňđńîě ĹďďđńîđĂ Ş·ż ďđňďňďďđňďô đđćđđćďđô Í»®·ż´đńđńđňď

Îíý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ďđňďňďďíňď ¬± ˛»¬©±®µ đňđňđňđ Ý Ý Î Î Ý Î Ý Ý Ý Íö

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­ ďéîňíđňďíňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ô î łż­µ­ ďđňíňíňíńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ ďđňďňďňďńíî ĹďîđńďĂ Ş·ż ďđňďňďďíňďô đđćđđćđđô Í»®·ż´đńđńđňî ďđňďňďďđňđńîě ĹďîđńďĂ Ş·ż ďđňďňďďíňďô đđćđđćđđô Í»®·ż´đńđńđňî ďđňďňďďíňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňî ďđňďňďďęňđńîě ĹďîđńďĂ Ş·ż ďđňďňďďíňďô đđćđđćđđô Í»®·ż´đńđńđňî ďçîňďęčňďňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíď ďçîňďęčňîňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíî ďçîňďęčňíňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíí đňđňđňđńđ ĹďńđĂ Ş·ż ďđňďňďďíňď

Îîý°·˛ą ďéîňíđňďđňę 268

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňíđňďđňęô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďîńďďî ł­ Îîý°·˛ą ďçîňďęčňďňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňďňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďîńďďî ł­ Îîý°·˛ą ďçîňďęčňîňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňîňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďîńďďę ł­ Îíý°·˛ą ďéîňíđňďđňę ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňíđňďđňęô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďëńďîđ ł­ Îíý°·˛ą ďéîňíđňîěňî ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňíđňîěňîô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďîńďďę ł­ Îíý°·˛ą ďéîňíđňîěňî ­±«®˝» ďçîňďęčňďňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňíđňîěňîô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć Đż˝µ»¬ ­»˛¬ ©·¬¸ ż ­±«®˝» żĽĽ®»­­ ±ş ďçîňďęčňďňď ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďîńďďę ł­ Îíý°·˛ą ďéîňíđňďđňę ­±«®˝» ďçîňďęčňîňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňíđňďđňęô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć Đż˝µ»¬ ­»˛¬ ©·¬¸ ż ­±«®˝» żĽĽ®»­­ ±ş ďçîňďęčňîňď ňňňňň Í«˝˝»­­ ®ż¬» ·­ đ °»®˝»˛¬ řđńë÷ Îíý°·˛ą ďéîňíđňîěňî ­±«®˝» ďçîňďęčňîňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňíđňîěňîô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć Đż˝µ»¬ ­»˛¬ ©·¬¸ ż ­±«®˝» żĽĽ®»­­ ±ş ďçîňďęčňîňď ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďîńďďîńďďę ł­

© 2009 Cisco Systems, Inc.

Lab Guide

269

------- The page intentionally left blank. --------

270

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab 5-1: Configure and Verify Path Control Between Multiple IP Routing Protocols Complete this lab activity to practice what you learned in the related module.

Activity Objective In this activity, you will use correct commands, tools, and steps to configure and verify path control between multiple routing protocols. After completing this activity, you will be able to meet these objectives: Configure and verify policy-based routing Select the required tools and commands to configure PBR operations Make a list of configuration and implementation steps Write a verification and test plan to verify the proper implementation and operation according to the expected performance criteria. Verify the configuration and operation by using the proper show and debug commands

Information Packet The figure illustrates what you will accomplish in this activity.

Visual Objective

Visual Objective for Lab 5-1: Configure and Verify Path Control Between Multiple IP Routing Protocols

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

ROUTE v 1. 0—LG-17

Lab Guide

271

Implementation Policy The following list details the configuration requirements for all devices in the company network: Begin by deploying the EIGRP routing protocol in your network to achieve full IP connectivity. Routers R1, R2, R3, and R4 will form EIGRP adjacencies and exchange IP routing information to achieve a converged IP routing topology. Examine and verify that the EIGRP routing protocol is up and running between routers R1, R2, R3, and R4. Verify that the router R1, R2, R3, and R4 routing tables are populated with the required networks. Examine the path of IP packets sourced from SW1 destined to networks 192.168.1.0/24 and 192.168.2.0/24. Examine the path of IP packets sourced locally from router R2 destined to network 192.168.3.0/24. The destination-based forwarding and reachability provided by EIGRP is not sufficient for all traffic. You will deploy source-based IP routing using policy-based routing. You will change default IP routing decisions based on the EIGRP-acquired routing information for selected IP source to IP destination flows and apply a different next hop router. Change the policy on router R3 so that IP traffic that is sourced from switch SW1 IP address 172.30.13.11 and sent to networks 192.168.1.0/24 and 192.168.2.0/24 will select R1 as a next hop. Change the policy on router R1 so that locally originated traffic sent to network 192.168.3.0/24 will select router R3 as the next hop rather than router R2. Examine and verify that traffic originated from switch SW1 that is sent to networks 192.168.1.0/24 and 192.168.2.0/24 takes the path R3-R1-R2-R4 using policy-based routing. Examine and verify that policy-based routing is in effect on router R3. Verify that traffic originated from switch SW1 that is sent to other networks is not policy routed and takes the path governed by the EIGRP-selected best path. Verify that locally originated traffic on router R1 that is sent to 192.168.3.0/24 travels on the path R3-R4 instead of the path R2R4. Verify that policy-based routing is in effect on router R1 for locally originated traffic sent to network 192.168.3.0/24 only, and that for the other type of traffic, the normal EIGRP-governed path is selected.

Device Information The table provides the information specific to each switch in the network:

272

Device name

Role

R1

POD router

R2

POD router

R3

POD router

R4

POD router

BBR2

Backbone router

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Command List The table describes the commands that are used in this activity. Command

Description

show ip route

Displays whole IP routing table

Router eigrp

Configures the EIGRP process

network (EIGRP)

Specifies the network for an EIGRP routing process

[no] auto-summary (EIGRP)

Allows automatic summarization of subnet routes into networklevel routes

debug ip policy

Displays IP policy routing packet activity

route-map

Defines the conditions for redistributing routes from one routing protocol into another, or enables policy routing

ip policy route-map

Identifies a route map to use for policy routing on an interface

trace (privileged)

Discovers the routes that packets will actually take when traveling to their destination

ping

Diagnoses basic network connectivity

Required Resources These are the resources and equipment that are required to complete this activity: A PC that is connected to an on-site laboratory or a PC with an Internet connection if remote laboratory equipment must be accessed A terminal server that is connected to the console port of each laboratory device, if using a remote laboratory Core and access switches in your pod

Job Aids These are the job aids for this lab activity: Value

Location

Blank implementation requirements list

Task 1

Blank implementation and verification plan form

Task 2

Blank verification notes form

Task 3

Alternate resources and solutions form

End of this lab

Implementation requirements hints

“Hints” section at the end of this lab

Implementation and verification plan hints

“Hints” section at the end of this lab

Solution configuration answer key (step-bystep procedure)

Configuration section at the end of this lab

© 2009 Cisco Systems, Inc.

Lab Guide

273

-------- The page intentionally left blank. --------

274

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Task 1: Establish an Implementation Requirements List The first step in your configuration deployment is to establish a list of what is needed in order for you to configure each device; for example, device names, trunk encapsulation types, and so on. Use the following table, the visual objective at the beginning of this lab, the implementation policy, and the device information to create your implementation requirements list. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Device

© 2009 Cisco Systems, Inc.

Implementation Requirement

Lab Guide

275

-------- The page intentionally left blank. --------

276

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Task 2: Create an Implementation and Verification Plan The second step in your configuration deployment is to establish a task list of the items that must be configured on each device, and in what order. Use the following table and the visual objective at the beginning of this lab to create your implementation and verification plan. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Complete

© 2009 Cisco Systems, Inc.

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Lab Guide

277

Complete

278

Device

Order

Implementing Cisco IP Routing (ROUTE) v1.0

Values and Items to Implement

Verification Method and Expected Results

© 2009 Cisco Systems, Inc.

Task 3: Implement and Verify Now that you have collected all the requirements and planned your implementation, you are ready to connect to the remote lab and implement your solution. Do not forget to save. Once your solution is implemented, you need to verify that your configuration is working and fulfills all the requirements specified by the customer. Keep in mind that once you leave the company, a network specialist will verify your configuration. Your ability to implement the solution according to the customer specifications will determine whether you get the job or not. Use the following area to record your notes and document the verifications you conducted to ensure that your solution is complete. If you are unsure about the verification steps, use the information provided in the “Hints” section at the end of this lab. Student Notes: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ © 2009 Cisco Systems, Inc.

Lab Guide

279

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

280

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternate Resources and Solutions Other groups may have implemented a solution different from yours. These will be discussed during the debriefing period that will follow this lab. Use the following space to document other possible solutions for your reference. __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ © 2009 Cisco Systems, Inc.

Lab Guide

281

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

282

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Hints You are encouraged to complete the labs using your knowledge. However, this section contains a series of hints to aid your completion of the lab.

Lab 5-1 Hint Sheet: Configure and Verify Path Control Between Multiple IP Routing Protocols Implementation Requirements To facilitate the configuration of your network, Task 1 asks you to create an implementation requirements list. This list details the elements you need in order to develop an implementation plan. The following is an example of such a list: Device

Implementation Requirement

Hint

ALL

Define the EIGRP autonomous system number and the interfaces that must be part of the EIGRP

Implementation Policy

ALL

Define networks advertised

Implementation Policy

ALL

Define the preferred path for the packets

Implementation Policy

Implementation and Verification Plan In Task 2, you will create an implementation and verification plan. Although there are several ways to set up this plan, the following tasks must be completed: Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1–R4

1

Load the initial configuration.

All pod routers must be preloaded with the initial configuration for the lab.

Step 1

R1–R4

2

Configure the EIGRP routing protocol on routers R1, R2, R3, and R4, and on all WAN, LAN, and loopback interfaces.

Examine and verify that the EIGRP routing protocol is up and running between routers R1, R2, R3, and R4 by verifying that the routers have their IP routing tables populated with the required networks.

Step 2

Examine the path of IP packets sourced from SW1 that are sent to networks 192.168.1.0/24 and 192.168.2.0/24. Verify reachability.

Step 3

Examine the path of IP packets sourced locally from router R2 that are sent to network 192.168.3.0/24.

© 2009 Cisco Systems, Inc.

Lab Guide

283

Complete

Device

Order

R3

R1

Values and Items to Implement

Verification Method and Expected Results

Step

Change the routing policy on router R3 for the IP traffic sourced from switch SW1 IP address 172.30.13.11 that is sent to networks 192.168.1.0/24 and 192.168.2.0/24 so that router R1 is selected as a next hop.

Examine and verify that traffic originated from switch SW1 that is sent to networks 192.168.1.0/24 and 192.168.2.0/24 takes the path R3-R1R2-R4 and uses policy-based routing.

Step 4

Change the routing policy on router R1 to force the locally originated traffic that is sent to network 192.168.3.0/24 to select router R3 as a next hop instead of router R2.

Examine and verify that locally originated traffic on router R1 that is sent to network 192.168.3.0/24 travels via router path R3-R4 instead of path R2-R4. Verify that policy-based routing is in effect on router R1 for locally originated traffic destined to network 192.168.3.0/24 only, and that for the other type of traffic, the normal EIGRPgoverned path is selected.

Examine and verify that policy-based routing is in effect on router R3. Step 5

Step-by-Step Procedure for Implementation and Verification 1. Load the initial configuration on all devices in your lab. 1.1. The instructor will provide guidelines for changing the initial configuration. 2. Implement EIGRP routing. 2.1. Use the following example to configure the EIGRP routing protocol in the lab. Îďý ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§ Îîý ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§ Îíý ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§ Îěý ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲻¬©±®µ ďçîňďęčňđňđ đňđňîëëňîëë ˛± ż«¬±ó­«łłż®§

284

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

2.2. Verify that the EIGRP routing protocol is up and running between routers. Îďý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ü Ý Ý Ý Ü Ü Ü Ü

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ ďéîňíđňîěňđ ĹçđńîđěěěďęĂ Ş·ż ďđňďňďďîňîô đđćđďćëîô ďéîňíđňďíňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ ďđňďňďďëňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňě ďđňďňďďîňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňď ďđňďňďíěňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňďíňíô đđćđďćëîô ďçîňďęčňďňđńîě ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďîňîô đđćđďćëîô ďçîňďęčňîňđńîě ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďîňîô đđćđďćëîô ďçîňďęčňíňđńîě ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďîňîô đđćđďćëîô

Í»®·ż´đńđńđňď

Úż­¬Ű¬¸»®˛»¬đńđ Í»®·ż´đńđńđňď Í»®·ż´đńđńđňď Í»®·ż´đńđńđňď

Îîý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ý Ü Ü Ý Ü Ü Ü Ü

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ ďéîňíđňîěňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďéîňíđňďíňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďďîňďô đđćđďćííô Í»®·ż´đńđńđňď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ ďđňďňďďëňđ ĹçđńîęčďčëęĂ Ş·ż ďđňďňďďîňďô đďćěęćđéô Í»®·ż´đńđńđňď ďđňďňďďîňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňď ďđňďňďíěňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňîěňěô đđćđîćđéô Úż­¬Ű¬¸»®˛»¬đńđ ďçîňďęčňďňđńîě ĹçđńďëęďęđĂ Ş·ż ďéîňíđňîěňěô đďćěęćěéô Úż­¬Ű¬¸»®˛»¬đńđ ďçîňďęčňîňđńîě ĹçđńďëęďęđĂ Ş·ż ďéîňíđňîěňěô đďćěęćěéô Úż­¬Ű¬¸»®˛»¬đńđ ďçîňďęčňíňđńîě ĹçđńďëęďęđĂ Ş·ż ďéîňíđňîěňěô đďćěęćěéô Úż­¬Ű¬¸»®˛»¬đńđ

Îíý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ü Ý Ü Ü Ý Ü Ü Ü

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ ďéîňíđňîěňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďíěňěô đđćđďćëîô ďéîňíđňďíňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ ďđňďňďďëňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňďíňďô đďćěęćďéô ďđňďňďďîňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňďíňďô đđćđďćëîô ďđňďňďíěňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňí ďçîňďęčňďňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďíěňěô đđćđďćëîô ďçîňďęčňîňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďíěňěô đđćđďćëîô ďçîňďęčňíňđńîě ĹçđńîîçéčëęĂ Ş·ż ďđňďňďíěňěô đđćđďćëîô

© 2009 Cisco Systems, Inc.

Í»®·ż´đńđńđňí Úż­¬Ű¬¸»®˛»¬đńđ Úż­¬Ű¬¸»®˛»¬đńđ Í»®·ż´đńđńđňí Í»®·ż´đńđńđňí Í»®·ż´đńđńđňí Lab Guide

285

Îěý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ý Ü Ü Ü Ý Ý Ý Ý

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ ďéîňíđňîěňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďéîňíđňďíňđ ĹçđńîďéîěďęĂ Ş·ż ďđňďňďíěňíô đđćđîćďďô Í»®·ż´đńđńđňí ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­ ďđňďňďďëňđ ĹçđńîęčěěďęĂ Ş·ż ďéîňíđňîěňîô đđćđîćďďô Úż­¬Ű¬¸»®˛»¬đńđ ĹçđńîęčěěďęĂ Ş·ż ďđňďňďíěňíô đđćđîćďďô Í»®·ż´đńđńđňí ďđňďňďďîňđ ĹçđńîďéîěďęĂ Ş·ż ďéîňíđňîěňîô đđćđîćďďô Úż­¬Ű¬¸»®˛»¬đńđ ďđňďňďíěňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňí ďçîňďęčňďňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíď ďçîňďęčňîňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíî ďçîňďęčňíňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíí

3. Examine the path of the IP packets. ­©ďý°·˛ą ďçîňďęčňďňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňďňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ëčńëčńëç ł­ ­©ďý°·˛ą ďçîňďęčňîňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňîňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ëčńëčńëç ł­ ­©ďý¬®ż˝»®±«¬» ďçîňďęčňďňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďçîňďęčňďňď ď ďéîňíđňďíňí đ ł­»˝ đ ł­»˝ đ ł­»˝ î ďđňďňďíěňě îë ł­»˝ îë ł­»˝ ö ­©ďý¬®ż˝»®±«¬» ďçîňďęčňîňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďçîňďęčňîňď ď ďéîňíđňďíňí đ ł­»˝ đ ł­»˝ đ ł­»˝ î ďđňďňďíěňě îë ł­»˝ îë ł­»˝ ö Îďý°·˛ą ďçîňďęčňíňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňíňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ëęńëéńęđ ł­ Îďý¬®ż˝» ďçîňďęčňíňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďçîňďęčňíňď ď ďđňďňďďîňî îč ł­»˝ îč ł­»˝ îč ł­»˝ î ďéîňíđňîěňě îč ł­»˝ îč ł­»˝ ö 286

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

4. Implement PBR on router R3. 4.1. Use the following example to configure PBR on router R3 in the lab. Îíý ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° °±´·˝§ ®±«¬»ółż° ÎÓóĐŢÎ ˙ ·° ż˝˝»­­ó´·­¬ »¨¬»˛Ľ»Ľ ßÝÔóĐŢÎ °»®ł·¬ ·° ¸±­¬ ďéîňíđňďíňďď ďçîňďęčňďňđ đňđňđňîëë °»®ł·¬ ·° ¸±­¬ ďéîňíđňďíňďď ďçîňďęčňîňđ đňđňđňîëë ˙ ®±«¬»ółż° ÎÓóĐŢÎ °»®ł·¬ ďđ łż¬˝¸ ·° żĽĽ®»­­ ßÝÔóĐŢÎ ­»¬ ·° ˛»¨¬ó¸±° ďéîňíđňďíňď

4.2. Verify the traffic flow from switch SW1 and PBR on R3. ­©ďý¬®ż˝» ďçîňďęčňďňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďçîňďęčňďňď ď î í ě

ďéîňíđňďíňí đ ł­»˝ đ ł­»˝ đ ł­»˝ ďéîňíđňďíňď đ ł­»˝ đ ł­»˝ đ ł­»˝ ďđňďňďďîňî îë ł­»˝ îë ł­»˝ îë ł­»˝ ďéîňíđňîěňě íě ł­»˝ îë ł­»˝ ö

ÎíýĽ»ľ«ą ·° °±´·˝§ б´·˝§ ®±«¬·˛ą Ľ»ľ«ąą·˛ą ·­ ±˛ Note

Enable debugging in order to see the policy macth following the ping commands on pod switch SW1.

­©ďý°·˛ą ďçîňďęčňďňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňďňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ëďńëčńęé ł­ Îíý öÓż§ îě ďěćďěćěçňđîëć ×Đć ­ăďéîňíđňďíňďď řÚż­¬Ű¬¸»®˛»¬đńđ÷ô Ľăďçîňďęčňďňďô ďđđô Ú×Ţ °±´·˝§ łż¬˝¸ öÓż§ îě ďěćďěćěçňđîëć ×Đć ­ăďéîňíđňďíňďď řÚż­¬Ű¬¸»®˛»¬đńđ÷ô Ľăďçîňďęčňďňďô ďđđô °±´·˝§ łż¬˝¸ öÓż§ îě ďěćďěćěçňđîëć ×Đć ®±«¬» łż° ÎÓóĐŢÎô ·¬»ł ďđô °»®ł·¬ öÓż§ îě ďěćďěćěçňđîëć ×Đć ­ăďéîňíđňďíňďď řÚż­¬Ű¬¸»®˛»¬đńđ÷ô Ľăďçîňďęčňďňď řÚż­¬Ű¬¸»®˛»¬đńđ÷ô ´»˛ ďđđô °±´·˝§ ®±«¬»Ľ öÓż§ îě ďěćďěćěçňđîëć ×Đć Úż­¬Ű¬¸»®˛»¬đń𠬱 Úż­¬Ű¬¸»®˛»¬đńđ ďéîňíđňďíňď öÓż§ îě ďěćďěćěçňđčëć ×Đć ­ăďéîňíđňďíňďď řÚż­¬Ű¬¸»®˛»¬đńđ÷ô Ľăďçîňďęčňďňďô ďđđô Ú×Ţ °±´·˝§ łż¬˝¸ öÓż§ îě ďěćďěćěçňđčëć ×Đć ­ăďéîňíđňďíňďď řÚż­¬Ű¬¸»®˛»¬đńđ÷ô Ľăďçîňďęčňďňďô ąăďéîňíđňďíňďô ´»˛ ďđđô Ú×Ţ °±´·˝§ ®±«¬»Ľ öÓż§ îě ďěćďěćěçňďěëć ×Đć ­ăďéîňíđňďíňďď řÚż­¬Ű¬¸»®˛»¬đńđ÷ô Ľăďçîňďęčňďňďô ďđđô Ú×Ţ °±´·˝§ łż¬˝¸ öÓż§ îě ďěćďěćěçňďěëć ×Đć ­ăďéîňíđňďíňďď řÚż­¬Ű¬¸»®˛»¬đńđ÷ô Ľăďçîňďęčňďňďô ąăďéîňíđňďíňďô ´»˛ ďđđô Ú×Ţ °±´·˝§ ®±«¬»Ľ

´»˛ ´»˛

´»˛

´»˛

­©ďý°·˛ą ďçîňďęčňíňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňíňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ëđńëéńëç ł­ Îíý öÓż§ îě ďěćďëćďęňęěëć ×Đć ­ăďéîňíđňďíňďď řÚż­¬Ű¬¸»®˛»¬đńđ÷ô Ľăďçîňďęčňíňďô ´»˛ ďđđô Ú×Ţ °±´·˝§ ®»¶»˝¬»Ľř˛± łż¬˝¸÷ ó ˛±®łż´ ş±®©ż®Ľ·˛ą © 2009 Cisco Systems, Inc.

Lab Guide

287

öÓż§ îě ďěćďëćďęňęěëć ×Đć ­ăďéîňíđňďíňďď řÚż­¬Ű¬¸»®˛»¬đńđ÷ô Ľăďçîňďęčňíňď řÚż­¬Ű¬¸»®˛»¬đńđ÷ô ´»˛ ďđđô °±´·˝§ ®»¶»˝¬»Ľ óó ˛±®łż´ ş±®©ż®Ľ·˛ą öÓż§ îě ďěćďëćďęňéđëć ×Đć ­ăďéîňíđňďíňďď řÚż­¬Ű¬¸»®˛»¬đńđ÷ô Ľăďçîňďęčňíňďô ´»˛ ďđđô Ú×Ţ °±´·˝§ ®»¶»˝¬»Ľř˛± łż¬˝¸÷ ó ˛±®łż´ ş±®©ż®Ľ·˛ą öÓż§ îě ďěćďëćďęňéęëć ×Đć ­ăďéîňíđňďíňďď řÚż­¬Ű¬¸»®˛»¬đńđ÷ô Ľăďçîňďęčňíňďô ´»˛ ďđđô Ú×Ţ °±´·˝§ ®»¶»˝¬»Ľř˛± łż¬˝¸÷ ó ˛±®łż´ ş±®©ż®Ľ·˛ą

5. Implement PBR on router R1. 5.1. Use the following example to configure PBR on router R1 in the lab. Îďý ·° ´±˝ż´ °±´·˝§ ®±«¬»ółż° ÎÓóÔŃÝßÔóĐŢÎ ˙ ·° ż˝˝»­­ó´·­¬ »¨¬»˛Ľ»Ľ ßÝÔóÔŃÝßÔóĐŢÎ °»®ł·¬ ·° ż˛§ ďçîňďęčňíňđ đňđňđňîëë ˙ ®±«¬»ółż° ÎÓóÔŃÝßÔóĐŢÎ °»®ł·¬ ďđ łż¬˝¸ ·° żĽĽ®»­­ ßÝÔóÔŃÝßÔóĐŢÎ ­»¬ ·° ˛»¨¬ó¸±° ďéîňíđňďíňí

5.2. Verify the traffic flow and PBR on R1. Îďý°·˛ą ďçîňďęčňíňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňíňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ëęńëéńęđ ł­ Îďý¬®ż˝»®±«¬» ďçîňďęčňíňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďçîňďęčňíňď ď î í ě

ďéîňíđňďíňí đ ł­»˝ đ ł­»˝ đ ł­»˝ ďéîňíđňďíňď íę ł­»˝ íî ł­»˝ íî ł­»˝ ďđňďňďďîňî îč ł­»˝ îč ł­»˝ îč ł­»˝ ďéîňíđňîěňě îč ł­»˝ îč ł­»˝ ö

ÎďýĽ»ľ«ą ·° °±´·˝§ б´·˝§ ®±«¬·˛ą Ľ»ľ«ąą·˛ą ·­ ±˛ Note

Enable debugging in order to see the policy match following the ping commands on pod router R1.

Îďý°·˛ą ďçîňďęčňíňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňíňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ëęńëčńęđ ł­ Îďý öÓż§ îě ďěćîčćđčňíěďć ×Đć ­ăďđňďňďďîňď ř´±˝ż´÷ô Ľăďçîňďęčňíňďô ´»˛ ďđđô °±´·˝§ łż¬˝¸ öÓż§ îě ďěćîčćđčňíěďć ×Đć ®±«¬» łż° ÎÓóÔŃÝßÔóĐŢÎô ·¬»ł ďđô °»®ł·¬ öÓż§ îě ďěćîčćđčňíěďć ×Đć ­ăďđňďňďďîňď ř´±˝ż´÷ô Ľăďçîňďęčňíňď řÚż­¬Ű¬¸»®˛»¬đńđ÷ô ´»˛ ďđđô °±´·˝§ ®±«¬»Ľ öÓż§ îě ďěćîčćđčňíěďć ×Đć ´±˝ż´ ¬± Úż­¬Ű¬¸»®˛»¬đńđ ďéîňíđňďíňí öÓż§ îě ďěćîčćđčňěđďć ×Đć ­ăďđňďňďďîňď ř´±˝ż´÷ô Ľăďçîňďęčňíňďô ´»˛ ďđđô °±´·˝§ łż¬˝¸ öÓż§ îě ďěćîčćđčňěđďć ×Đć ®±«¬» łż° ÎÓóÔŃÝßÔóĐŢÎô ·¬»ł ďđô °»®ł·¬ öÓż§ îě ďěćîčćđčňěđďć ×Đć ­ăďđňďňďďîňď ř´±˝ż´÷ô Ľăďçîňďęčňíňď řÚż­¬Ű¬¸»®˛»¬đńđ÷ô ´»˛ ďđđô °±´·˝§ ®±«¬»Ľ öÓż§ îě ďěćîčćđčňěđďć ×Đć ´±˝ż´ ¬± Úż­¬Ű¬¸»®˛»¬đńđ ďéîňíđňďíňí

288

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

öÓż§ îě ďěćîčćđčňěëéć ×Đć ­ăďđňďňďďîňď ř´±˝ż´÷ô Ľăďçîňďęčňíňďô ´»˛ ďđđô °±´·˝§ łż¬˝¸ öÓż§ îě ďěćîčćđčňěëéć ×Đć ®±«¬» łż° ÎÓóÔŃÝßÔóĐŢÎô ·¬»ł ďđô °»®ł·¬ öÓż§ îě ďěćîčćđčňěëéć ×Đć ­ăďđňďňďďîňď ř´±˝ż´÷ô Ľăďçîňďęčňíňď řÚż­¬Ű¬¸»®˛»¬đńđ÷ô ´»˛ ďđđô °±´·˝§ ®±«¬»Ľ öÓż§ îě ďěćîčćđčňěëéć ×Đć ´±˝ż´ ¬± Úż­¬Ű¬¸»®˛»¬đńđ ďéîňíđňďíňí öÓż§ îě ďěćîčćđčňëďéć ×Đć ­ăďđňďňďďîňď ř´±˝ż´÷ô Ľăďçîňďęčňíňďô ´»˛ ďđđô °±´·˝§ łż¬˝¸ Îďý°·˛ą ďçîňďęčňďňď ̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďçîňďęčňďňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć ˙˙˙˙˙ Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ëęńëęńęđ ł­ Îďý öÓż§ îě ďěćîčćďčňçééć ×Đć ­ăďđňďňďďîňď ®»¶»˝¬»Ľ óó ˛±®łż´ ş±®©ż®Ľ·˛ą öÓż§ îě ďěćîčćďçňđííć ×Đć ­ăďđňďňďďîňď ®»¶»˝¬»Ľ óó ˛±®łż´ ş±®©ż®Ľ·˛ą öÓż§ îě ďěćîčćďçňđçíć ×Đć ­ăďđňďňďďîňď ®»¶»˝¬»Ľ óó ˛±®łż´ ş±®©ż®Ľ·˛ą öÓż§ îě ďěćîčćďçňďěçć ×Đć ­ăďđňďňďďîňď ®»¶»˝¬»Ľ óó ˛±®łż´ ş±®©ż®Ľ·˛ą öÓż§ îě ďěćîčćďçňîđëć ×Đć ­ăďđňďňďďîňď ®»¶»˝¬»Ľ óó ˛±®łż´ ş±®©ż®Ľ·˛ą

© 2009 Cisco Systems, Inc.

ř´±˝ż´÷ô Ľăďçîňďęčňďňďô ´»˛ ďđđô °±´·˝§ ř´±˝ż´÷ô Ľăďçîňďęčňďňďô ´»˛ ďđđô °±´·˝§ ř´±˝ż´÷ô Ľăďçîňďęčňďňďô ´»˛ ďđđô °±´·˝§ ř´±˝ż´÷ô Ľăďçîňďęčňďňďô ´»˛ ďđđô °±´·˝§ ř´±˝ż´÷ô Ľăďçîňďęčňďňďô ´»˛ ďđđô °±´·˝§

Lab Guide

289

-------- The page intentionally left blank. --------

290

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab 6-1: Configure BGP Operations Complete this lab activity to practice what you learned in the related module.

Activity Objective In this activity, you will use correct commands, tools, and steps to configure and verify BGP operations. After completing this activity, you will be able to meet these objectives: Configure and verify multihomed ISP connections Configure EBGP on the enterprise router to connect to the two ISPs Select the required tools and commands to configure EBGP operations Make a list of configuration and implementation steps Write a verification and test plan to verify the proper implementation and operation according to the expected performance criteria Verify the configuration and operation by using the proper show and debug commands

Information Packet The figure illustrates what you will accomplish in this activity.

Visual Objective

Visual Objective for Lab 6-1: Configure BGP Operations

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

© 2009 Cisco Systems, Inc.

ROUTE v 1. 0—LG-18

Lab Guide

291

Implementation Policy The following list details the configuration requirements for all devices in the company network: Your first task will be to deploy the EBGP routing protocol in your pod. The network topology should consist of the following BGP autonomous systems: —

AS 130 with router R3 and switch SW1 as members

—

AS 100 with router R1 as a member

—

AS 200 with router R2 as a member

—

AS 400 with router R4 as a member

AS 130 will have EBGP sessions to AS 100 and AS 200 in order to receive IP information about the networks in AS 200. Examine and verify that EBGP sessions have been set up and that the neighbors are ready to exchange IP routing information. Examine and verify that the EBGP session between router R3, R1, and R4 uses strong authentication. Configure the routers to announce selected networks via the BGP routing protocol to exchange IP routing information. The following should be done in order to announce the required routing information: —

Announce the 172.30.13.0/24 network from router R3

—

Announce the 10.3.3.3/32 network from router R3

—

Announce the 192.168.1.0/24, 192.168.2.0/24, and 192.168.3.0/24 networks from router R2

Device Information The table provides the information specific to each switch in the network:

292

Device name

Role

R1

POD router

R2

POD router

R3

POD router

R4

POD router

BBR2

Backbone router

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Command List The table describes the commands that are used in this activity. Command

Description

router bgp

Configures the BGP routing process

[no] synchronization

Enables the synchronization between BGP and the Interior Gateway Protocol (IGP) system

bgp log-neighbor-changes

Enables logging of BGP neighbor resets

[no]auto-summary (BGP)

Configures automatic summarization of subnet routes into network-level routes

neighbor remote-as

Adds an entry to the BGP or multiprotocol BGP neighbor table

neighbor password

Enables Message Digest 5 (MD5) authentication on a TCP connection between two BGP peers

Show ip bgp summary

Displays the status of all BGP connections

show ip bgp neighbors

Displays information about BGP and TCP connections to neighbors

show ip bgp

Displays entries in the Border Gateway Protocol (BGP) routing table

network (BGP and multiprotocol BGP)

Specifies the networks to be advertised by the BGP and multiprotocol BGP routing processes

redistribute (IP)

Redistributes routes from one routing domain into another routing domain

route-map

Defines the conditions for redistributing routes from one routing protocol into another, or enables policy routing

aggregate-address

Creates an aggregate entry in a BGP database

Required Resources These are the resources and equipment that are required to complete this activity: A PC that is connected to an on-site laboratory or a PC with an Internet connection if remote laboratory equipment must be accessed A terminal server that is connected to the console port of each laboratory device, if using a remote laboratory Core and access switches in your pod

© 2009 Cisco Systems, Inc.

Lab Guide

293

Job Aids These are the job aids for this lab activity:

294

Value

Location

Blank implementation requirements list

Task 1

Blank implementation and verification plan form

Task 2

Blank verification notes form

Task 3

Alternate resources and solutions form

End of this lab

Implementation requirements hints

“Hints” section at the end of this lab

Implementation and verification plan hints

“Hints” section at the end of this lab

Solution configuration answer key (step-bystep procedure)

Configuration section at the end of this lab

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Task 1: Establish an Implementation Requirements List The first step in your configuration deployment is to establish a list of what is needed in order for you to configure each device; for example, device names, trunk encapsulation types, and so on. Use the following table, the visual objective at the beginning of this lab, the implementation policy, and the device information to create your implementation requirement list. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Device

© 2009 Cisco Systems, Inc.

Implementation Requirement

Lab Guide

295

-------- The page intentionally left blank. --------

296

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Task 2: Create an Implementation and Verification Plan The second step in your configuration deployment is to establish a task list of the items that must be configured on each device, and in what order. Use the following table and the visual objective at the beginning of this lab to create your implementation and verification plan. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Complete

© 2009 Cisco Systems, Inc.

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Lab Guide

297

Complete

298

Device

Order

Implementing Cisco IP Routing (ROUTE) v1.0

Values and Items to Implement

Verification Method and Expected Results

© 2009 Cisco Systems, Inc.

Task 3: Implement and Verify Now that you have collected all the requirements and planned your implementation, you are ready to connect to the remote lab and implement your solution. Do not forget to save. Once your solution is implemented, you need to verify that your configuration is working and fulfills all the requirements specified by the customer. Keep in mind that once you leave the company, a network specialist will verify your configuration. Your ability to implement the solution according to the customer specifications will determine whether you get the job or not. Use the following area to record your notes and document the verifications you conducted to ensure that your solution is complete. If you are unsure about the verification steps, use the information provided in the “Hints” section at the end of this lab. Student Notes: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ © 2009 Cisco Systems, Inc.

Lab Guide

299

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

300

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternate Resources and Solutions Other groups may have implemented a solution different from yours. These will be discussed during the debriefing period that will follow this lab. Use the following space to document other possible solutions for your reference. __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ © 2009 Cisco Systems, Inc.

Lab Guide

301

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

302

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Hints You are encouraged to complete the labs using your knowledge. However, this section contains a series of hints to aid your completion of the lab.

Lab 6-1 Hint Sheet: Configure BGP Operations Implementation Requirements To facilitate the configuration of your network, Task 1 asks you to create an implementation requirements list. This list details the elements you need in order to develop an implementation plan. The following is an example of such a list: Device

Implementation Requirement

Hint

ALL

Define BGP autonomous system numbers and assign them to routers

Implementation Policy

ALL

Define the networks that will be advertised

Implementation Policy Visual Objective

Implementation and Verification Plan In Task 2, you will create an implementation and verification plan. Although there are several ways to set up this plan, the following tasks must be completed: Complete

Device

Order

Values and items to Implement

Verification Method and Expected Results

Step

R1–R4

1

Load the initial configuration.

All pod routers must be preloaded with the initial configuration for the lab.

Step 1

© 2009 Cisco Systems, Inc.

Lab Guide

303

Complete

Device

R1–R4

Order

Values and items to Implement

Verification Method and Expected Results

Step

Enable BGP routing protocol on routers R1, R2, R3, and R4 and configure the following EBGP sessions:

Examine and verify that EBGP sessions have been set up and that the neighbors are ready to exchange IP routing information.

Step 2

AS 130 to AS 100 between routers R3 and R1 AS 130 to AS 400 between routers R3 and R4

Examine and verify that the EBGP session between router R3, R1, and R4 uses strong authentication.

AS 200 to AS 100 between routers R2 and R1 AS 200 to AS 400 between routers R2 and R4 The BGP sessions between AS 130, AS 100, and AS 400 should be authenticated using the strongest possible authentication. R3

Enable router R3 to announce the connected network 172.30.13.0/24 to the neighboring autonomous systems via the EBGP sessions you set up in the previous task. The network should not be redistributed into BGP.

Step 3

Configure router R3 to announce the loopback network 10.3.3.3/32 to the neighboring autonomous systems 100 and 200 via the EBGP network. The network should be redistributed into BGP. R2

304

Configure router R2 to announce the 192.168.x.0/24 subnets to the neighboring autonomous systems via BGP. Instead of announcing individual 192.168.x.0/24 subnets, announce the 192.168.0.0/16 major network. The summary route should be advertised if at least one of the 192.168.x.0/24 subnets are present in the IP routing table of router R2.

Implementing Cisco IP Routing (ROUTE) v1.0

Verify that routers R1, R2, and R4 have information about the 172.30.13.0/24 and 10.3.3.3/32 networks in their BGP and IP routing tables.

Step 3

Verify that routers R1, R3, and R4 have information about the 192.168.0.0/16 summary route in their BGP and IP routing tables.

© 2009 Cisco Systems, Inc.

Step-by-Step Procedure for Implementation and Verification 1. Load the initial configuration on all devices in your lab. 1.1. The instructor will provide guidelines for changing the initial configuration. 2. Configure EBGP. 2.1. Use the following example to configure the routers in this lab: Îďý ®±«¬»® ľą° ďđ𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»·ą¸ľ±® ďđňďňďďîňî ®»ł±¬»óż­ îđ𠲻·ą¸ľ±® ďđňďňďďíňí ®»ł±¬»óż­ ďí𠲻·ą¸ľ±® ďđňďňďďíňí °ż­­©±®Ľ ˝·­˝± ˛± ż«¬±ó­«łłż®§ Îîý ®±«¬»® ľą° îđ𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»·ą¸ľ±® ďđňďňďďîňď ®»ł±¬»óż­ ďđ𠲻·ą¸ľ±® ďđňďňďîěňě ®»ł±¬»óż­ ěđ𠲱 ż«¬±ó­«łłż®§ Îíý ®±«¬»® ľą° ďí𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»·ą¸ľ±® ďđňďňďďíňď ®»ł±¬»óż­ ďđ𠲻·ą¸ľ±® ďđňďňďďíňď °ż­­©±®Ľ ˝·­˝± ˛»·ą¸ľ±® ďđňďňďíěňě ®»ł±¬»óż­ ěđ𠲻·ą¸ľ±® ďđňďňďíěňě °ż­­©±®Ľ ˝·­˝± ˛± ż«¬±ó­«łłż®§ Îěý ®±«¬»® ľą° ěđ𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»·ą¸ľ±® ďđňďňďîěňî ®»ł±¬»óż­ îđ𠲻·ą¸ľ±® ďđňďňďíěňí ®»ł±¬»óż­ ďí𠲻·ą¸ľ±® ďđňďňďíěňí °ż­­©±®Ľ ˝·­˝± ˛± ż«¬±ó­«łłż®§

2.2. Verify that EBGP sessions have been set up. Îďý­¸±© ·° ľą° ­«łłż®§ ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďđňďňďďíňďô ´±˝ż´ ßÍ ˛«łľ»® ďđđ ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ ď Ň»·ą¸ľ±® ͬż¬»ńĐş¨Î˝Ľ ďđňďňďďîňî ďđňďňďďíňí

Ę ě ě

ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ îđđ ďíđ

ě ďí

ě ďí

Ěľ´Ę»® ď ď

×˛Ď Ń«¬Ď Ë°ńܱ©˛ đ đ

đ đđćđđćíë đ đđćđëćîç

đ đ

Îîý­¸±© ·° ľą° ­«łłż®§ ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďçîňďęčňíňďô ´±˝ż´ ßÍ ˛«łľ»® îđđ ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ ď Ň»·ą¸ľ±® ͬż¬»ńĐş¨Î˝Ľ ďđňďňďďîňď ďđňďňďîěňě

Ę ě ě

ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ ďđđ ěđđ

ë ďđ

ë ďđ

Ěľ´Ę»® ď ď

×˛Ď Ń«¬Ď Ë°ńܱ©˛ đ đ

đ đđćđďćďě đ đđćđéćďç

đ đ

Îíý­¸±© ·° ľą° ­«łłż®§ © 2009 Cisco Systems, Inc.

Lab Guide

305

ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďđňíňíňíô ´±˝ż´ ßÍ ˛«łľ»® ďíđ ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ ď Ň»·ą¸ľ±® ͬż¬»ńĐş¨Î˝Ľ ďđňďňďďíňď ďđňďňďíěňě

Ę ě ě

ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ ďđđ ěđđ

ďě ďě

Ěľ´Ę»®

ďě ďě

ď ď

×˛Ď Ń«¬Ď Ë°ńܱ©˛ đ đ

đ đđćđęćíę đ đđćđęćíę

đ đ

Îěý­¸±© ·° ľą° ­«łłż®§ ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďđňďňďíěňěô ´±˝ż´ ßÍ ˛«łľ»® ěđđ ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ ď Ň»·ą¸ľ±® ͬż¬»ńĐş¨Î˝Ľ ďđňďňďîěňî ďđňďňďíěňí

Ę ě ě

ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ îđđ ďíđ

ďď ďë

Ěľ´Ę»®

ďď ďë

ď ď

×˛Ď Ń«¬Ď Ë°ńܱ©˛ đ đ

đ đđćđčćîî đ đđćđéćďď

đ đ

Îďý­¸±© ·° ľą° ˛»·ą¸ľ±®­ ŢŮĐ ˛»·ą¸ľ±® ·­ ďđňďňďďîňîô ®»ł±¬» ßÍ îđđô »¨¬»®˛ż´ ´·˛µ ŢŮĐ Ş»®­·±˛ ěô ®»ł±¬» ®±«¬»® ×Ü ďçîňďęčňíňď ŢŮĐ ­¬ż¬» ă Ű­¬żľ´·­¸»Ľô «° ş±® đđćđíćđí Ôż­¬ ®»żĽ đđćđđćđíô ´ż­¬ ©®·¬» đđćđđćđíô ¸±´Ľ ¬·ł» ·­ ďčđô µ»»°ż´·Ş» ·˛¬»®Şż´ ·­ ęđ ­»˝±˛Ľ­ Ň»·ą¸ľ±® ˝ż°żľ·´·¬·»­ć ᫬» ®»ş®»­¸ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľř±´Ľ ú ˛»©÷ ߼Ľ®»­­ şżł·´§ ×ĐŞě ˲·˝ż­¬ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľ Ó»­­żą» ­¬ż¬·­¬·˝­ć ×˛Ď Ľ»°¬¸ ·­ đ Ń«¬Ď Ľ»°¬¸ ·­ đ Í»˛¬ Î˝ŞĽ Ń°»˛­ć ď ď ұ¬·ş·˝ż¬·±˛­ć đ đ Ë°Ľż¬»­ć đ đ Ő»»°ż´·Ş»­ć ę ę ᫬» λş®»­¸ć đ đ ̱¬ż´ć é é Ü»şż«´¬ ł·˛·ł«ł ¬·ł» ľ»¬©»»˛ żĽŞ»®¬·­»ł»˛¬ ®«˛­ ·­ íđ ­»˝±˛Ľ­ Ú±® żĽĽ®»­­ şżł·´§ć ×ĐŞě ˲·˝ż­¬ ŢŮĐ ¬żľ´» Ş»®­·±˛ ďô ˛»·ą¸ľ±® Ş»®­·±˛ ďńđ Ń«¬°«¬ Ż«»«» ­·¦» ć đ ײĽ»¨ ďô Ńşş­»¬ đô Óż­µ đ¨î ď «°Ľż¬»óą®±«° ł»łľ»® Í»˛¬ Î˝ŞĽ Đ®»ş·¨ ż˝¬·Ş·¬§ć óóóó óóóó Đ®»ş·¨»­ Ý«®®»˛¬ć đ đ Đ®»ş·¨»­ ̱¬ż´ć đ đ ׳°´·˝·¬ É·¬¸Ľ®ż©ć đ đ ۨ°´·˝·¬ É·¬¸Ľ®ż©ć đ đ Ë­»Ľ ż­ ľ»­¬°ż¬¸ć ˛ńż đ Ë­»Ľ ż­ ł«´¬·°ż¬¸ć ˛ńż đ Ń«¬ľ±«˛Ľ ײľ±«˛Ľ Ô±˝ż´ б´·˝§ Ü»˛·»Ľ Đ®»ş·¨»­ć óóóóóóóó óóóóóóó ̱¬ż´ć đ đ Ň«łľ»® ±ş ŇÔÎ×­ ·˛ ¬¸» «°Ľż¬» ­»˛¬ć łż¨ đô ł·˛ đ ݱ˛˛»˝¬·±˛­ »­¬żľ´·­¸»Ľ ďĺ Ľ®±°°»Ľ đ Ôż­¬ ®»­»¬ ˛»Ş»® ݱ˛˛»˝¬·±˛ ­¬ż¬» ·­ ŰÍĚßŢô ×ńŃ ­¬ż¬«­ć ďô «˛®»żĽ ·˛°«¬ ľ§¬»­ć đ ݱ˛˛»˝¬·±˛ ·­ ŰÝŇ Ü·­żľ´»Ľô Ó·˛·˛«ł ·˛˝±ł·˛ą ĚĚÔ đô Ń«¬ą±·˛ą ĚĚÔ ď Ô±˝ż´ ¸±­¬ć ďđňďňďďîňďô Ô±˝ż´ °±®¬ć ďďęęí Ú±®»·ą˛ ¸±­¬ć ďđňďňďďîňîô Ú±®»·ą˛ °±®¬ć ďéç ۲Ż«»«»Ľ °ż˝µ»¬­ ş±® ®»¬®ż˛­ł·¬ć đô ·˛°«¬ć đ ŰŞ»˛¬ Ě·ł»®­ ř˝«®®»˛¬ ¬·ł» ·­ đ¨ÝÚííŢÚëÝ÷ć Ě·ł»® ͬż®¬­ Éżµ»«°­ 306

Implementing Cisco IP Routing (ROUTE) v1.0

ł·­ó±®Ľ»®»Ľć đ ř𠾧¬»­÷ Ň»¨¬ © 2009 Cisco Systems, Inc.

묮ż˛­ Ě·ł»Éż·¬ ß˝µŘ±´Ľ Í»˛ĽÉ˛Ľ Ő»»°ß´·Ş» Ů·Ş»Ë° Đł¬«ßą»® Ü»żĽÉż·¬ ·­­ć îçčçěěîçíď ·®­ć ďčđđęíëđďč

é đ ë đ đ đ đ đ

đ đ ď đ đ đ đ đ

­˛Ľ«˛żć îçčçěěíđçď ®˝Ş˛¨¬ć ďčđđęíëďéč

đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ ­˛Ľ˛¨¬ć îçčçěěíđçď ®˝Ş©˛Ľć ďęîîë

­˛Ľ©˛Ľć Ľ»´®˝Ş©˛Ľć

ďęîîë ďëç

ÍÎĚĚć ďčî ł­ô ÎĚĚŃć ďđéí ł­ô ÎĚĘć čçď ł­ô ŐÎĚĚć đ ł­ ł·˛ÎĚĚć îč ł­ô łż¨ÎĚĚć íđđ ł­ô ßÝŐ ¸±´Ľć îđđ ł­ Ú´żą­ć ż˝¬·Ş» ±°»˛ô ˛żą´» ×Đ Đ®»˝»Ľ»˛˝» Şż´«» ć ę Üż¬żą®żł­ řłż¨ Ľż¬ż ­»ął»˛¬ ·­ ďěę𠾧¬»­÷ć Î˝ŞĽć ďđ ř±«¬ ±ş ±®Ľ»®ć đ÷ô ©·¬¸ Ľż¬żć ëô ¬±¬ż´ Ľż¬ż ľ§¬»­ć ďëç Í»˛¬ć ç ř®»¬®ż˛­ł·¬ć đô şż­¬®»¬®ż˛­ł·¬ć đô °ż®¬·ż´ż˝µć đô Í»˝±˛Ľ ݱ˛ą»­¬·±˛ć đ÷ô ©·¬¸ Ľż¬żć ęô ¬±¬ż´ Ľż¬ż ľ§¬»­ć ďëç ŢŮĐ ˛»·ą¸ľ±® ·­ ďđňďňďďíňíô ®»ł±¬» ßÍ ďíđô »¨¬»®˛ż´ ´·˛µ ŢŮĐ Ş»®­·±˛ ěô ®»ł±¬» ®±«¬»® ×Ü ďđňíňíňí ŢŮĐ ­¬ż¬» ă Ű­¬żľ´·­¸»Ľô «° ş±® đđćđčćđđ Ôż­¬ ®»żĽ đđćđđćëçô ´ż­¬ ©®·¬» đđćđđćëçô ¸±´Ľ ¬·ł» ·­ ďčđô µ»»°ż´·Ş» ·˛¬»®Şż´ ·­ ęđ ­»˝±˛Ľ­ Ň»·ą¸ľ±® ˝ż°żľ·´·¬·»­ć ᫬» ®»ş®»­¸ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľř±´Ľ ú ˛»©÷ ߼Ľ®»­­ şżł·´§ ×ĐŞě ˲·˝ż­¬ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľ Ó»­­żą» ­¬ż¬·­¬·˝­ć ×˛Ď Ľ»°¬¸ ·­ đ Ń«¬Ď Ľ»°¬¸ ·­ đ Í»˛¬ Î˝ŞĽ Ń°»˛­ć î î ұ¬·ş·˝ż¬·±˛­ć đ đ Ë°Ľż¬»­ć đ đ Ő»»°ż´·Ş»­ć ďí ďí ᫬» λş®»­¸ć đ đ ̱¬ż´ć ďë ďë Ü»şż«´¬ ł·˛·ł«ł ¬·ł» ľ»¬©»»˛ żĽŞ»®¬·­»ł»˛¬ ®«˛­ ·­ íđ ­»˝±˛Ľ­ Ú±® żĽĽ®»­­ şżł·´§ć ×ĐŞě ˲·˝ż­¬ ŢŮĐ ¬żľ´» Ş»®­·±˛ ďô ˛»·ą¸ľ±® Ş»®­·±˛ ďńđ Ń«¬°«¬ Ż«»«» ­·¦» ć đ ײĽ»¨ ďô Ńşş­»¬ đô Óż­µ đ¨î ď «°Ľż¬»óą®±«° ł»łľ»® Í»˛¬ Î˝ŞĽ Đ®»ş·¨ ż˝¬·Ş·¬§ć óóóó óóóó Đ®»ş·¨»­ Ý«®®»˛¬ć đ đ Đ®»ş·¨»­ ̱¬ż´ć đ đ ׳°´·˝·¬ É·¬¸Ľ®ż©ć đ đ ۨ°´·˝·¬ É·¬¸Ľ®ż©ć đ đ Ë­»Ľ ż­ ľ»­¬°ż¬¸ć ˛ńż đ Ë­»Ľ ż­ ł«´¬·°ż¬¸ć ˛ńż đ Ń«¬ľ±«˛Ľ ײľ±«˛Ľ Ô±˝ż´ б´·˝§ Ü»˛·»Ľ Đ®»ş·¨»­ć óóóóóóóó óóóóóóó ̱¬ż´ć đ đ Ň«łľ»® ±ş ŇÔÎ×­ ·˛ ¬¸» «°Ľż¬» ­»˛¬ć łż¨ đô ł·˛ đ ݱ˛˛»˝¬·±˛­ »­¬żľ´·­¸»Ľ îĺ Ľ®±°°»Ľ ď Ôż­¬ ®»­»¬ đđćđčćđîô Ľ«» ¬± Đ»»® ˝´±­»Ľ ¬¸» ­»­­·±˛ ݱ˛˛»˝¬·±˛ ­¬ż¬» ·­ ŰÍĚßŢô ×ńŃ ­¬ż¬«­ć ďô «˛®»żĽ ·˛°«¬ ľ§¬»­ć đ ݱ˛˛»˝¬·±˛ ·­ ŰÝŇ Ü·­żľ´»Ľô Ó·˛·˛«ł ·˛˝±ł·˛ą ĚĚÔ đô Ń«¬ą±·˛ą ĚĚÔ ď Ô±˝ż´ ¸±­¬ć ďđňďňďďíňďô Ô±˝ż´ °±®¬ć ďéç Ú±®»·ą˛ ¸±­¬ć ďđňďňďďíňíô Ú±®»·ą˛ °±®¬ć ěďéíę

© 2009 Cisco Systems, Inc.

Lab Guide

307

۲Ż«»«»Ľ °ż˝µ»¬­ ş±® ®»¬®ż˛­ł·¬ć đô ·˛°«¬ć đ ŰŞ»˛¬ Ě·ł»®­ ř˝«®®»˛¬ ¬·ł» ·­ đ¨ÝÚííÜďŰč÷ć Ě·ł»® ͬż®¬­ Éżµ»«°­ 묮ż˛­ ďď đ Ě·ł»Éż·¬ đ đ ß˝µŘ±´Ľ ďď ç Í»˛ĽÉ˛Ľ đ đ Ő»»°ß´·Ş» đ đ Ů·Ş»Ë° đ đ Đł¬«ßą»® đ đ Ü»żĽÉż·¬ đ đ ·­­ć íęçęęęďďďč ·®­ć îďďčđěďěďé

­˛Ľ«˛żć íęçęęęďíéí ®˝Ş˛¨¬ć îďďčđěďęéî

ł·­ó±®Ľ»®»Ľć đ ř𠾧¬»­÷ Ň»¨¬ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ

­˛Ľ˛¨¬ć íęçęęęďíéí ®˝Ş©˛Ľć ďęďíđ

­˛Ľ©˛Ľć Ľ»´®˝Ş©˛Ľć

ďęďíđ îëě

ÍÎĚĚć îíď ł­ô ÎĚĚŃć éęç ł­ô ÎĚĘć ëíč ł­ô ŐÎĚĚć đ ł­ ł·˛ÎĚĚć ěđ ł­ô łż¨ÎĚĚć íđđ ł­ô ßÝŐ ¸±´Ľć îđđ ł­ Ú´żą­ć °ż­­·Ş» ±°»˛ô ˛żą´»ô ą»˛ ¬˝ľ­ô łĽë ×Đ Đ®»˝»Ľ»˛˝» Şż´«» ć ę Üż¬żą®żł­ řłż¨ Ľż¬ż ­»ął»˛¬ ·­ ďěě𠾧¬»­÷ć Î˝ŞĽć îî ř±«¬ ±ş ±®Ľ»®ć đ÷ô ©·¬¸ Ľż¬żć ďďô ¬±¬ż´ Ľż¬ż ľ§¬»­ć îëě Í»˛¬ć îđ ř®»¬®ż˛­ł·¬ć đô şż­¬®»¬®ż˛­ł·¬ć đô °ż®¬·ż´ż˝µć đô Í»˝±˛Ľ ݱ˛ą»­¬·±˛ć đ÷ô ©·¬¸ Ľż¬żć ďđô ¬±¬ż´ Ľż¬ż ľ§¬»­ć îëě Îîý­¸±© ·° ľą° ˛»·¸ľ±®­ ŢŮĐ ˛»·ą¸ľ±® ·­ ďđňďňďďîňďô ®»ł±¬» ßÍ ďđđô »¨¬»®˛ż´ ´·˛µ ŢŮĐ Ş»®­·±˛ ěô ®»ł±¬» ®±«¬»® ×Ü ďđňďňďďíňď ŢŮĐ ­¬ż¬» ă Ű­¬żľ´·­¸»Ľô «° ş±® đđćđíćďđ Ôż­¬ ®»żĽ đđćđđćďđô ´ż­¬ ©®·¬» đđćđđćďđô ¸±´Ľ ¬·ł» ·­ ďčđô µ»»°ż´·Ş» ·˛¬»®Şż´ ·­ ęđ ­»˝±˛Ľ­ Ň»·ą¸ľ±® ˝ż°żľ·´·¬·»­ć ᫬» ®»ş®»­¸ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľř±´Ľ ú ˛»©÷ ߼Ľ®»­­ şżł·´§ ×ĐŞě ˲·˝ż­¬ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľ Ó»­­żą» ­¬ż¬·­¬·˝­ć ×˛Ď Ľ»°¬¸ ·­ đ Ń«¬Ď Ľ»°¬¸ ·­ đ Í»˛¬ Î˝ŞĽ Ń°»˛­ć ď ď ұ¬·ş·˝ż¬·±˛­ć đ đ Ë°Ľż¬»­ć đ đ Ő»»°ż´·Ş»­ć ę ę ᫬» λş®»­¸ć đ đ ̱¬ż´ć é é Ü»şż«´¬ ł·˛·ł«ł ¬·ł» ľ»¬©»»˛ żĽŞ»®¬·­»ł»˛¬ ®«˛­ ·­ íđ ­»˝±˛Ľ­ Ú±® żĽĽ®»­­ şżł·´§ć ×ĐŞě ˲·˝ż­¬ ŢŮĐ ¬żľ´» Ş»®­·±˛ ďô ˛»·ą¸ľ±® Ş»®­·±˛ ďńđ Ń«¬°«¬ Ż«»«» ­·¦» ć đ ײĽ»¨ ďô Ńşş­»¬ đô Óż­µ đ¨î ď «°Ľż¬»óą®±«° ł»łľ»® Í»˛¬ Î˝ŞĽ Đ®»ş·¨ ż˝¬·Ş·¬§ć óóóó óóóó Đ®»ş·¨»­ Ý«®®»˛¬ć đ đ Đ®»ş·¨»­ ̱¬ż´ć đ đ ׳°´·˝·¬ É·¬¸Ľ®ż©ć đ đ ۨ°´·˝·¬ É·¬¸Ľ®ż©ć đ đ Ë­»Ľ ż­ ľ»­¬°ż¬¸ć ˛ńż đ Ë­»Ľ ż­ ł«´¬·°ż¬¸ć ˛ńż đ Ń«¬ľ±«˛Ľ ײľ±«˛Ľ Ô±˝ż´ б´·˝§ Ü»˛·»Ľ Đ®»ş·¨»­ć óóóóóóóó óóóóóóó ̱¬ż´ć đ đ Ň«łľ»® ±ş ŇÔÎ×­ ·˛ ¬¸» «°Ľż¬» ­»˛¬ć łż¨ đô ł·˛ đ ݱ˛˛»˝¬·±˛­ »­¬żľ´·­¸»Ľ ďĺ Ľ®±°°»Ľ đ Ôż­¬ ®»­»¬ ˛»Ş»® 308

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

ݱ˛˛»˝¬·±˛ ­¬ż¬» ·­ ŰÍĚßŢô ×ńŃ ­¬ż¬«­ć ďô «˛®»żĽ ·˛°«¬ ľ§¬»­ć đ ݱ˛˛»˝¬·±˛ ·­ ŰÝŇ Ü·­żľ´»Ľô Ó·˛·˛«ł ·˛˝±ł·˛ą ĚĚÔ đô Ń«¬ą±·˛ą ĚĚÔ ď Ô±˝ż´ ¸±­¬ć ďđňďňďďîňîô Ô±˝ż´ °±®¬ć ďéç Ú±®»·ą˛ ¸±­¬ć ďđňďňďďîňďô Ú±®»·ą˛ °±®¬ć ďďęęí ۲Ż«»«»Ľ °ż˝µ»¬­ ş±® ®»¬®ż˛­ł·¬ć đô ·˛°«¬ć đ ŰŞ»˛¬ Ě·ł»®­ ř˝«®®»˛¬ ¬·ł» ·­ đ¨ÝÚííéŰŰě÷ć Ě·ł»® ͬż®¬­ Éżµ»«°­ 묮ż˛­ ę đ Ě·ł»Éż·¬ đ đ ß˝µŘ±´Ľ ę ě Í»˛ĽÉ˛Ľ đ đ Ő»»°ß´·Ş» đ đ Ů·Ş»Ë° đ đ Đł¬«ßą»® đ đ Ü»żĽÉż·¬ đ đ ·­­ć ďčđđęíëđďč ·®­ć îçčçěěîçíď

­˛Ľ«˛żć ďčđđęíëďéč ®˝Ş˛¨¬ć îçčçěěíđçď

ł·­ó±®Ľ»®»Ľć đ ř𠾧¬»­÷ Ň»¨¬ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ

­˛Ľ˛¨¬ć ďčđđęíëďéč ®˝Ş©˛Ľć ďęîîë

­˛Ľ©˛Ľć Ľ»´®˝Ş©˛Ľć

ďęîîë ďëç

ÍÎĚĚć ďęë ł­ô ÎĚĚŃć ďďéî ł­ô ÎĚĘć ďđđé ł­ô ŐÎĚĚć đ ł­ ł·˛ÎĚĚć îč ł­ô łż¨ÎĚĚć íđđ ł­ô ßÝŐ ¸±´Ľć îđđ ł­ Ú´żą­ć °ż­­·Ş» ±°»˛ô ˛żą´»ô ą»˛ ¬˝ľ­ ×Đ Đ®»˝»Ľ»˛˝» Şż´«» ć ę Üż¬żą®żł­ řłż¨ Ľż¬ż ­»ął»˛¬ ·­ ďěę𠾧¬»­÷ć Î˝ŞĽć ç ř±«¬ ±ş ±®Ľ»®ć đ÷ô ©·¬¸ Ľż¬żć ęô ¬±¬ż´ Ľż¬ż ľ§¬»­ć ďëç Í»˛¬ć ďđ ř®»¬®ż˛­ł·¬ć đô şż­¬®»¬®ż˛­ł·¬ć đô °ż®¬·ż´ż˝µć đô Í»˝±˛Ľ ݱ˛ą»­¬·±˛ć đ÷ô ©·¬¸ Ľż¬żć ëô ¬±¬ż´ Ľż¬ż ľ§¬»­ć ďëç ŢŮĐ ˛»·ą¸ľ±® ·­ ďđňďňďîěňěô ®»ł±¬» ßÍ ěđđô »¨¬»®˛ż´ ´·˛µ ŢŮĐ Ş»®­·±˛ ěô ®»ł±¬» ®±«¬»® ×Ü ďđňďňďíěňě ŢŮĐ ­¬ż¬» ă Ű­¬żľ´·­¸»Ľô «° ş±® đđćđçćďč Ôż­¬ ®»żĽ đđćđđćďčô ´ż­¬ ©®·¬» đđćđđćďčô ¸±´Ľ ¬·ł» ·­ ďčđô µ»»°ż´·Ş» ·˛¬»®Şż´ ·­ ęđ ­»˝±˛Ľ­ Ň»·ą¸ľ±® ˝ż°żľ·´·¬·»­ć ᫬» ®»ş®»­¸ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľř±´Ľ ú ˛»©÷ ߼Ľ®»­­ şżł·´§ ×ĐŞě ˲·˝ż­¬ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľ Ó»­­żą» ­¬ż¬·­¬·˝­ć ×˛Ď Ľ»°¬¸ ·­ đ Ń«¬Ď Ľ»°¬¸ ·­ đ Í»˛¬ Î˝ŞĽ Ń°»˛­ć ď ď ұ¬·ş·˝ż¬·±˛­ć đ đ Ë°Ľż¬»­ć đ đ Ő»»°ż´·Ş»­ć ďď ďď ᫬» λş®»­¸ć đ đ ̱¬ż´ć ďî ďî Ü»şż«´¬ ł·˛·ł«ł ¬·ł» ľ»¬©»»˛ żĽŞ»®¬·­»ł»˛¬ ®«˛­ ·­ íđ ­»˝±˛Ľ­ Ú±® żĽĽ®»­­ şżł·´§ć ×ĐŞě ˲·˝ż­¬ ŢŮĐ ¬żľ´» Ş»®­·±˛ ďô ˛»·ą¸ľ±® Ş»®­·±˛ ďńđ Ń«¬°«¬ Ż«»«» ­·¦» ć đ ײĽ»¨ ďô Ńşş­»¬ đô Óż­µ đ¨î ď «°Ľż¬»óą®±«° ł»łľ»® Í»˛¬ Î˝ŞĽ Đ®»ş·¨ ż˝¬·Ş·¬§ć óóóó óóóó Đ®»ş·¨»­ Ý«®®»˛¬ć đ đ Đ®»ş·¨»­ ̱¬ż´ć đ đ ׳°´·˝·¬ É·¬¸Ľ®ż©ć đ đ ۨ°´·˝·¬ É·¬¸Ľ®ż©ć đ đ Ë­»Ľ ż­ ľ»­¬°ż¬¸ć ˛ńż đ Ë­»Ľ ż­ ł«´¬·°ż¬¸ć ˛ńż đ Ô±˝ż´ б´·˝§ Ü»˛·»Ľ Đ®»ş·¨»­ć ̱¬ż´ć © 2009 Cisco Systems, Inc.

Ń«¬ľ±«˛Ľ óóóóóóóó đ

ײľ±«˛Ľ óóóóóóó đ Lab Guide

309

Ň«łľ»® ±ş ŇÔÎ×­ ·˛ ¬¸» «°Ľż¬» ­»˛¬ć łż¨ đô ł·˛ đ ݱ˛˛»˝¬·±˛­ »­¬żľ´·­¸»Ľ ďĺ Ľ®±°°»Ľ đ Ôż­¬ ®»­»¬ ˛»Ş»® ݱ˛˛»˝¬·±˛ ­¬ż¬» ·­ ŰÍĚßŢô ×ńŃ ­¬ż¬«­ć ďô «˛®»żĽ ·˛°«¬ ľ§¬»­ć đ ݱ˛˛»˝¬·±˛ ·­ ŰÝŇ Ü·­żľ´»Ľô Ó·˛·˛«ł ·˛˝±ł·˛ą ĚĚÔ đô Ń«¬ą±·˛ą ĚĚÔ ď Ô±˝ż´ ¸±­¬ć ďđňďňďîěňîô Ô±˝ż´ °±®¬ć ďęčéę Ú±®»·ą˛ ¸±­¬ć ďđňďňďîěňěô Ú±®»·ą˛ °±®¬ć ďéç ۲Ż«»«»Ľ °ż˝µ»¬­ ş±® ®»¬®ż˛­ł·¬ć đô ·˛°«¬ć đ ŰŞ»˛¬ Ě·ł»®­ ř˝«®®»˛¬ ¬·ł» ·­ đ¨ÝÚííçďîč÷ć Ě·ł»® ͬż®¬­ Éżµ»«°­ 묮ż˛­ ďí đ Ě·ł»Éż·¬ đ đ ß˝µŘ±´Ľ ďď đ Í»˛ĽÉ˛Ľ đ đ Ő»»°ß´·Ş» đ đ Ů·Ş»Ë° đ đ Đł¬«ßą»® đ đ Ü»żĽÉż·¬ đ đ ·­­ć ďçîíďëéęđí ·®­ć íčçęěěîííč ÍÎĚĚć îěé ł­ô ł·˛ÎĚĚć đ ł­ô Ú´żą­ć ż˝¬·Ş» ×Đ Đ®»˝»Ľ»˛˝»

­˛Ľ«˛żć ďçîíďëéčëč ®˝Ş˛¨¬ć íčçęěěîëçí

ł·­ó±®Ľ»®»Ľć đ ř𠾧¬»­÷ Ň»¨¬ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ

­˛Ľ˛¨¬ć ďçîíďëéčëč ®˝Ş©˛Ľć ďęďíđ

­˛Ľ©˛Ľć Ľ»´®˝Ş©˛Ľć

ďęďíđ îëě

ÎĚĚŃć ęęí ł­ô ÎĚĘć ěďę ł­ô ŐÎĚĚć đ ł­ łż¨ÎĚĚć íđđ ł­ô ßÝŐ ¸±´Ľć îđđ ł­ ±°»˛ô ˛żą´» Şż´«» ć ę

Üż¬żą®żł­ řłż¨ Ľż¬ż ­»ął»˛¬ ·­ ďěę𠾧¬»­÷ć Î˝ŞĽć îí ř±«¬ ±ş ±®Ľ»®ć đ÷ô ©·¬¸ Ľż¬żć ďďô ¬±¬ż´ Ľż¬ż ľ§¬»­ć îëě Í»˛¬ć ďě ř®»¬®ż˛­ł·¬ć đô şż­¬®»¬®ż˛­ł·¬ć đô °ż®¬·ż´ż˝µć đô Í»˝±˛Ľ ݱ˛ą»­¬·±˛ć đ÷ô ©·¬¸ Ľż¬żć ďîô ¬±¬ż´ Ľż¬ż ľ§¬»­ć îëě Îíý­¸±© ·° ľą° ˛»·ą¸ľ±®­ ŢŮĐ ˛»·ą¸ľ±® ·­ ďđňďňďďíňďô ®»ł±¬» ßÍ ďđđô »¨¬»®˛ż´ ´·˛µ ŢŮĐ Ş»®­·±˛ ěô ®»ł±¬» ®±«¬»® ×Ü ďđňďňďďíňď ŢŮĐ ­¬ż¬» ă Ű­¬żľ´·­¸»Ľô «° ş±® đđćđčćďđ Ôż­¬ ®»żĽ đđćđđćđçô ´ż­¬ ©®·¬» đđćđđćđçô ¸±´Ľ ¬·ł» ·­ ďčđô µ»»°ż´·Ş» ·˛¬»®Şż´ ·­ ęđ ­»˝±˛Ľ­ Ň»·ą¸ľ±® ˝ż°żľ·´·¬·»­ć ᫬» ®»ş®»­¸ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľř±´Ľ ú ˛»©÷ ߼Ľ®»­­ şżł·´§ ×ĐŞě ˲·˝ż­¬ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľ Ó»­­żą» ­¬ż¬·­¬·˝­ć ×˛Ď Ľ»°¬¸ ·­ đ Ń«¬Ď Ľ»°¬¸ ·­ đ Í»˛¬ Î˝ŞĽ Ń°»˛­ć î î ұ¬·ş·˝ż¬·±˛­ć đ đ Ë°Ľż¬»­ć đ đ Ő»»°ż´·Ş»­ć ďě ďě ᫬» λş®»­¸ć đ đ ̱¬ż´ć ďę ďę Ü»şż«´¬ ł·˛·ł«ł ¬·ł» ľ»¬©»»˛ żĽŞ»®¬·­»ł»˛¬ ®«˛­ ·­ íđ ­»˝±˛Ľ­ Ú±® żĽĽ®»­­ şżł·´§ć ×ĐŞě ˲·˝ż­¬ ŢŮĐ ¬żľ´» Ş»®­·±˛ ďô ˛»·ą¸ľ±® Ş»®­·±˛ ďńđ Ń«¬°«¬ Ż«»«» ­·¦» ć đ ײĽ»¨ ďô Ńşş­»¬ đô Óż­µ đ¨î ď «°Ľż¬»óą®±«° ł»łľ»® Í»˛¬ Î˝ŞĽ Đ®»ş·¨ ż˝¬·Ş·¬§ć óóóó óóóó Đ®»ş·¨»­ Ý«®®»˛¬ć đ đ Đ®»ş·¨»­ ̱¬ż´ć đ đ ׳°´·˝·¬ É·¬¸Ľ®ż©ć đ đ ۨ°´·˝·¬ É·¬¸Ľ®ż©ć đ đ Ë­»Ľ ż­ ľ»­¬°ż¬¸ć ˛ńż đ 310

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ë­»Ľ ż­ ł«´¬·°ż¬¸ć

˛ńż

đ

Ń«¬ľ±«˛Ľ ײľ±«˛Ľ Ô±˝ż´ б´·˝§ Ü»˛·»Ľ Đ®»ş·¨»­ć óóóóóóóó óóóóóóó ̱¬ż´ć đ đ Ň«łľ»® ±ş ŇÔÎ×­ ·˛ ¬¸» «°Ľż¬» ­»˛¬ć łż¨ đô ł·˛ đ ݱ˛˛»˝¬·±˛­ »­¬żľ´·­¸»Ľ îĺ Ľ®±°°»Ľ ď Ôż­¬ ®»­»¬ đđćđčćďđô Ľ«» ¬± Ë­»® ®»­»¬ ݱ˛˛»˝¬·±˛ ­¬ż¬» ·­ ŰÍĚßŢô ×ńŃ ­¬ż¬«­ć ďô «˛®»żĽ ·˛°«¬ ľ§¬»­ć đ ݱ˛˛»˝¬·±˛ ·­ ŰÝŇ Ü·­żľ´»Ľô Ó·˛·˛«ł ·˛˝±ł·˛ą ĚĚÔ đô Ń«¬ą±·˛ą ĚĚÔ ď Ô±˝ż´ ¸±­¬ć ďđňďňďďíňíô Ô±˝ż´ °±®¬ć ěďéíę Ú±®»·ą˛ ¸±­¬ć ďđňďňďďíňďô Ú±®»·ą˛ °±®¬ć ďéç ۲Ż«»«»Ľ °ż˝µ»¬­ ş±® ®»¬®ż˛­ł·¬ć đô ·˛°«¬ć đ ŰŞ»˛¬ Ě·ł»®­ ř˝«®®»˛¬ ¬·ł» ·­ đ¨ÝÚíîçÚďč÷ć Ě·ł»® ͬż®¬­ Éżµ»«°­ 묮ż˛­ ďî đ Ě·ł»Éż·¬ đ đ ß˝µŘ±´Ľ ďđ ç Í»˛ĽÉ˛Ľ đ đ Ő»»°ß´·Ş» đ đ Ů·Ş»Ë° đ đ Đł¬«ßą»® đ đ Ü»żĽÉż·¬ đ đ ·­­ć îďďčđěďěďé ·®­ć íęçęęęďďďč

­˛Ľ«˛żć îďďčđěďęéî ®˝Ş˛¨¬ć íęçęęęďíéí

ł·­ó±®Ľ»®»Ľć đ ř𠾧¬»­÷ Ň»¨¬ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ

­˛Ľ˛¨¬ć îďďčđěďęéî ®˝Ş©˛Ľć ďęďíđ

­˛Ľ©˛Ľć Ľ»´®˝Ş©˛Ľć

ďęďíđ îëě

ÍÎĚĚć îíç ł­ô ÎĚĚŃć éďî ł­ô ÎĚĘć ěéí ł­ô ŐÎĚĚć đ ł­ ł·˛ÎĚĚć ěđ ł­ô łż¨ÎĚĚć íđđ ł­ô ßÝŐ ¸±´Ľć îđđ ł­ Ú´żą­ć ż˝¬·Ş» ±°»˛ô ˛żą´»ô łĽë ×Đ Đ®»˝»Ľ»˛˝» Şż´«» ć ę Üż¬żą®żł­ řłż¨ Ľż¬ż ­»ął»˛¬ ·­ ďěě𠾧¬»­÷ć Î˝ŞĽć îđ ř±«¬ ±ş ±®Ľ»®ć đ÷ô ©·¬¸ Ľż¬żć ďđô ¬±¬ż´ Ľż¬ż ľ§¬»­ć îëě Í»˛¬ć îî ř®»¬®ż˛­ł·¬ć đô şż­¬®»¬®ż˛­ł·¬ć đô °ż®¬·ż´ż˝µć đô Í»˝±˛Ľ ݱ˛ą»­¬·±˛ć đ÷ô ©·¬¸ Ľż¬żć ďďô ¬±¬ż´ Ľż¬ż ľ§¬»­ć îëě ŢŮĐ ˛»·ą¸ľ±® ·­ ďđňďňďíěňěô ®»ł±¬» ßÍ ěđđô »¨¬»®˛ż´ ´·˛µ ŢŮĐ Ş»®­·±˛ ěô ®»ł±¬» ®±«¬»® ×Ü ďđňďňďíěňě ŢŮĐ ­¬ż¬» ă Ű­¬żľ´·­¸»Ľô «° ş±® đđćđčćďď Ôż­¬ ®»żĽ đđćđđćďďô ´ż­¬ ©®·¬» đđćđđćďďô ¸±´Ľ ¬·ł» ·­ ďčđô µ»»°ż´·Ş» ·˛¬»®Şż´ ·­ ęđ ­»˝±˛Ľ­ Ň»·ą¸ľ±® ˝ż°żľ·´·¬·»­ć ᫬» ®»ş®»­¸ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľř±´Ľ ú ˛»©÷ ߼Ľ®»­­ şżł·´§ ×ĐŞě ˲·˝ż­¬ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľ Ó»­­żą» ­¬ż¬·­¬·˝­ć ×˛Ď Ľ»°¬¸ ·­ đ Ń«¬Ď Ľ»°¬¸ ·­ đ Í»˛¬ Î˝ŞĽ Ń°»˛­ć î î ұ¬·ş·˝ż¬·±˛­ć đ đ Ë°Ľż¬»­ć đ đ Ő»»°ż´·Ş»­ć ďě ďě ᫬» λş®»­¸ć đ đ ̱¬ż´ć ďę ďę Ü»şż«´¬ ł·˛·ł«ł ¬·ł» ľ»¬©»»˛ żĽŞ»®¬·­»ł»˛¬ ®«˛­ ·­ íđ ­»˝±˛Ľ­ Ú±® żĽĽ®»­­ şżł·´§ć ×ĐŞě ˲·˝ż­¬ ŢŮĐ ¬żľ´» Ş»®­·±˛ ďô ˛»·ą¸ľ±® Ş»®­·±˛ ďńđ Ń«¬°«¬ Ż«»«» ­·¦» ć đ ײĽ»¨ ďô Ńşş­»¬ đô Óż­µ đ¨î ď «°Ľż¬»óą®±«° ł»łľ»® Í»˛¬ Î˝ŞĽ Đ®»ş·¨ ż˝¬·Ş·¬§ć óóóó óóóó Đ®»ş·¨»­ Ý«®®»˛¬ć đ đ © 2009 Cisco Systems, Inc.

Lab Guide

311

Đ®»ş·¨»­ ̱¬ż´ć ׳°´·˝·¬ É·¬¸Ľ®ż©ć ۨ°´·˝·¬ É·¬¸Ľ®ż©ć Ë­»Ľ ż­ ľ»­¬°ż¬¸ć Ë­»Ľ ż­ ł«´¬·°ż¬¸ć

đ đ đ ˛ńż ˛ńż

đ đ đ đ đ

Ń«¬ľ±«˛Ľ ײľ±«˛Ľ Ô±˝ż´ б´·˝§ Ü»˛·»Ľ Đ®»ş·¨»­ć óóóóóóóó óóóóóóó ̱¬ż´ć đ đ Ň«łľ»® ±ş ŇÔÎ×­ ·˛ ¬¸» «°Ľż¬» ­»˛¬ć łż¨ đô ł·˛ đ ݱ˛˛»˝¬·±˛­ »­¬żľ´·­¸»Ľ îĺ Ľ®±°°»Ľ ď Ôż­¬ ®»­»¬ đđćđčćďëô Ľ«» ¬± Ë­»® ®»­»¬ ݱ˛˛»˝¬·±˛ ­¬ż¬» ·­ ŰÍĚßŢô ×ńŃ ­¬ż¬«­ć ďô «˛®»żĽ ·˛°«¬ ľ§¬»­ć đ ݱ˛˛»˝¬·±˛ ·­ ŰÝŇ Ü·­żľ´»Ľô Ó·˛·˛«ł ·˛˝±ł·˛ą ĚĚÔ đô Ń«¬ą±·˛ą ĚĚÔ ď Ô±˝ż´ ¸±­¬ć ďđňďňďíěňíô Ô±˝ż´ °±®¬ć ęđçéę Ú±®»·ą˛ ¸±­¬ć ďđňďňďíěňěô Ú±®»·ą˛ °±®¬ć ďéç ۲Ż«»«»Ľ °ż˝µ»¬­ ş±® ®»¬®ż˛­ł·¬ć đô ·˛°«¬ć đ ŰŞ»˛¬ Ě·ł»®­ ř˝«®®»˛¬ ¬·ł» ·­ đ¨ÝÚíîŢďëč÷ć Ě·ł»® ͬż®¬­ Éżµ»«°­ 묮ż˛­ ďî đ Ě·ł»Éż·¬ đ đ ß˝µŘ±´Ľ ďđ đ Í»˛ĽÉ˛Ľ đ đ Ő»»°ß´·Ş» đ đ Ů·Ş»Ë° đ đ Đł¬«ßą»® đ đ Ü»żĽÉż·¬ đ đ ·­­ć ěđđíëđçďîď ·®­ć ěčçéęîçčî

­˛Ľ«˛żć ěđđíëđçíéę ®˝Ş˛¨¬ć ěčçéęíîíé

ł·­ó±®Ľ»®»Ľć đ ř𠾧¬»­÷ Ň»¨¬ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ

­˛Ľ˛¨¬ć ěđđíëđçíéę ®˝Ş©˛Ľć ďęďíđ

­˛Ľ©˛Ľć Ľ»´®˝Ş©˛Ľć

ďęďíđ îëě

ÍÎĚĚć îíç ł­ô ÎĚĚŃć éďî ł­ô ÎĚĘć ěéí ł­ô ŐÎĚĚć đ ł­ ł·˛ÎĚĚć ěđ ł­ô łż¨ÎĚĚć íđđ ł­ô ßÝŐ ¸±´Ľć îđđ ł­ Ú´żą­ć ż˝¬·Ş» ±°»˛ô ˛żą´»ô łĽë ×Đ Đ®»˝»Ľ»˛˝» Şż´«» ć ę Üż¬żą®żł­ řłż¨ Ľż¬ż ­»ął»˛¬ ·­ ďěě𠾧¬»­÷ć Î˝ŞĽć îđ ř±«¬ ±ş ±®Ľ»®ć đ÷ô ©·¬¸ Ľż¬żć ďđô ¬±¬ż´ Ľż¬ż ľ§¬»­ć îëě Í»˛¬ć ďí ř®»¬®ż˛­ł·¬ć đô şż­¬®»¬®ż˛­ł·¬ć đô °ż®¬·ż´ż˝µć đô Í»˝±˛Ľ ݱ˛ą»­¬·±˛ć đ÷ô ©·¬¸ Ľż¬żć ďďô ¬±¬ż´ Ľż¬ż ľ§¬»­ć îëě Îěý­¸±© ·° ľą° ˛»·ą¸ľ±®­ ŢŮĐ ˛»·ą¸ľ±® ·­ ďđňďňďîěňîô ®»ł±¬» ßÍ îđđô »¨¬»®˛ż´ ´·˛µ ŢŮĐ Ş»®­·±˛ ěô ®»ł±¬» ®±«¬»® ×Ü ďçîňďęčňíňď ŢŮĐ ­¬ż¬» ă Ű­¬żľ´·­¸»Ľô «° ş±® đđćđçćîë Ôż­¬ ®»żĽ đđćđđćîëô ´ż­¬ ©®·¬» đđćđđćîëô ¸±´Ľ ¬·ł» ·­ ďčđô µ»»°ż´·Ş» ·˛¬»®Şż´ ·­ ęđ ­»˝±˛Ľ­ Ň»·ą¸ľ±® ˝ż°żľ·´·¬·»­ć ᫬» ®»ş®»­¸ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľř±´Ľ ú ˛»©÷ ߼Ľ®»­­ şżł·´§ ×ĐŞě ˲·˝ż­¬ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľ Ó»­­żą» ­¬ż¬·­¬·˝­ć ×˛Ď Ľ»°¬¸ ·­ đ Ń«¬Ď Ľ»°¬¸ ·­ đ Í»˛¬ Î˝ŞĽ Ń°»˛­ć ď ď ұ¬·ş·˝ż¬·±˛­ć đ đ Ë°Ľż¬»­ć đ đ Ő»»°ż´·Ş»­ć ďď ďď ᫬» λş®»­¸ć đ đ ̱¬ż´ć ďî ďî Ü»şż«´¬ ł·˛·ł«ł ¬·ł» ľ»¬©»»˛ żĽŞ»®¬·­»ł»˛¬ ®«˛­ ·­ íđ ­»˝±˛Ľ­ Ú±® żĽĽ®»­­ şżł·´§ć ×ĐŞě ˲·˝ż­¬ ŢŮĐ ¬żľ´» Ş»®­·±˛ ďô ˛»·ą¸ľ±® Ş»®­·±˛ ďńđ Ń«¬°«¬ Ż«»«» ­·¦» ć đ 312

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

ײĽ»¨ ďô Ńşş­»¬ đô Óż­µ đ¨î ď «°Ľż¬»óą®±«° ł»łľ»® Đ®»ş·¨ ż˝¬·Ş·¬§ć Đ®»ş·¨»­ Ý«®®»˛¬ć Đ®»ş·¨»­ ̱¬ż´ć ׳°´·˝·¬ É·¬¸Ľ®ż©ć ۨ°´·˝·¬ É·¬¸Ľ®ż©ć Ë­»Ľ ż­ ľ»­¬°ż¬¸ć Ë­»Ľ ż­ ł«´¬·°ż¬¸ć

Í»˛¬ óóóó đ đ đ đ ˛ńż ˛ńż

Î˝ŞĽ óóóó đ đ đ đ đ đ

Ń«¬ľ±«˛Ľ ײľ±«˛Ľ Ô±˝ż´ б´·˝§ Ü»˛·»Ľ Đ®»ş·¨»­ć óóóóóóóó óóóóóóó ̱¬ż´ć đ đ Ň«łľ»® ±ş ŇÔÎ×­ ·˛ ¬¸» «°Ľż¬» ­»˛¬ć łż¨ đô ł·˛ đ ݱ˛˛»˝¬·±˛­ »­¬żľ´·­¸»Ľ ďĺ Ľ®±°°»Ľ đ Ôż­¬ ®»­»¬ ˛»Ş»® ݱ˛˛»˝¬·±˛ ­¬ż¬» ·­ ŰÍĚßŢô ×ńŃ ­¬ż¬«­ć ďô «˛®»żĽ ·˛°«¬ ľ§¬»­ć đ ݱ˛˛»˝¬·±˛ ·­ ŰÝŇ Ü·­żľ´»Ľô Ó·˛·˛«ł ·˛˝±ł·˛ą ĚĚÔ đô Ń«¬ą±·˛ą ĚĚÔ ď Ô±˝ż´ ¸±­¬ć ďđňďňďîěňěô Ô±˝ż´ °±®¬ć ďéç Ú±®»·ą˛ ¸±­¬ć ďđňďňďîěňîô Ú±®»·ą˛ °±®¬ć ďęčéę ۲Ż«»«»Ľ °ż˝µ»¬­ ş±® ®»¬®ż˛­ł·¬ć đô ·˛°«¬ć đ ŰŞ»˛¬ Ě·ł»®­ ř˝«®®»˛¬ ¬·ł» ·­ đ¨ÝÚíîŢçŢě÷ć Ě·ł»® ͬż®¬­ Éżµ»«°­ 묮ż˛­ ďî đ Ě·ł»Éż·¬ đ đ ß˝µŘ±´Ľ ďî ďď Í»˛ĽÉ˛Ľ đ đ Ő»»°ß´·Ş» đ đ Ů·Ş»Ë° đ đ Đł¬«ßą»® đ đ Ü»żĽÉż·¬ đ đ ·­­ć íčçęěěîííč ·®­ć ďçîíďëéęđí

­˛Ľ«˛żć íčçęěěîëçí ®˝Ş˛¨¬ć ďçîíďëéčëč

ł·­ó±®Ľ»®»Ľć đ ř𠾧¬»­÷ Ň»¨¬ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ

­˛Ľ˛¨¬ć íčçęěěîëçí ®˝Ş©˛Ľć ďęďíđ

­˛Ľ©˛Ľć Ľ»´®˝Ş©˛Ľć

ďęďíđ îëě

ÍÎĚĚć îíç ł­ô ÎĚĚŃć éďî ł­ô ÎĚĘć ěéí ł­ô ŐÎĚĚć đ ł­ ł·˛ÎĚĚć đ ł­ô łż¨ÎĚĚć íđđ ł­ô ßÝŐ ¸±´Ľć îđđ ł­ Ú´żą­ć °ż­­·Ş» ±°»˛ô ˛żą´»ô ą»˛ ¬˝ľ­ ×Đ Đ®»˝»Ľ»˛˝» Şż´«» ć ę Üż¬żą®żł­ řłż¨ Ľż¬ż ­»ął»˛¬ ·­ ďěę𠾧¬»­÷ć Î˝ŞĽć ďě ř±«¬ ±ş ±®Ľ»®ć đ÷ô ©·¬¸ Ľż¬żć ďîô ¬±¬ż´ Ľż¬ż ľ§¬»­ć îëě Í»˛¬ć îí ř®»¬®ż˛­ł·¬ć đô şż­¬®»¬®ż˛­ł·¬ć đô °ż®¬·ż´ż˝µć đô Í»˝±˛Ľ ݱ˛ą»­¬·±˛ć đ÷ô ©·¬¸ Ľż¬żć ďďô ¬±¬ż´ Ľż¬ż ľ§¬»­ć îëě ŢŮĐ ˛»·ą¸ľ±® ·­ ďđňďňďíěňíô ®»ł±¬» ßÍ ďíđô »¨¬»®˛ż´ ´·˛µ ŢŮĐ Ş»®­·±˛ ěô ®»ł±¬» ®±«¬»® ×Ü ďđňíňíňí ŢŮĐ ­¬ż¬» ă Ű­¬żľ´·­¸»Ľô «° ş±® đđćđčćďę Ôż­¬ ®»żĽ đđćđđćďëô ´ż­¬ ©®·¬» đđćđđćďëô ¸±´Ľ ¬·ł» ·­ ďčđô µ»»°ż´·Ş» ·˛¬»®Şż´ ·­ ęđ ­»˝±˛Ľ­ Ň»·ą¸ľ±® ˝ż°żľ·´·¬·»­ć ᫬» ®»ş®»­¸ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľř±´Ľ ú ˛»©÷ ߼Ľ®»­­ şżł·´§ ×ĐŞě ˲·˝ż­¬ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľ Ó»­­żą» ­¬ż¬·­¬·˝­ć ×˛Ď Ľ»°¬¸ ·­ đ Ń«¬Ď Ľ»°¬¸ ·­ đ Í»˛¬ Î˝ŞĽ Ń°»˛­ć î î ұ¬·ş·˝ż¬·±˛­ć đ đ Ë°Ľż¬»­ć đ đ Ő»»°ż´·Ş»­ć ďě ďě ᫬» λş®»­¸ć đ đ ̱¬ż´ć ďę ďę Ü»şż«´¬ ł·˛·ł«ł ¬·ł» ľ»¬©»»˛ żĽŞ»®¬·­»ł»˛¬ ®«˛­ ·­ íđ ­»˝±˛Ľ­ © 2009 Cisco Systems, Inc.

Lab Guide

313

Ú±® żĽĽ®»­­ şżł·´§ć ×ĐŞě ˲·˝ż­¬ ŢŮĐ ¬żľ´» Ş»®­·±˛ ďô ˛»·ą¸ľ±® Ş»®­·±˛ ďńđ Ń«¬°«¬ Ż«»«» ­·¦» ć đ ײĽ»¨ ďô Ńşş­»¬ đô Óż­µ đ¨î ď «°Ľż¬»óą®±«° ł»łľ»® Í»˛¬ Î˝ŞĽ Đ®»ş·¨ ż˝¬·Ş·¬§ć óóóó óóóó Đ®»ş·¨»­ Ý«®®»˛¬ć đ đ Đ®»ş·¨»­ ̱¬ż´ć đ đ ׳°´·˝·¬ É·¬¸Ľ®ż©ć đ đ ۨ°´·˝·¬ É·¬¸Ľ®ż©ć đ đ Ë­»Ľ ż­ ľ»­¬°ż¬¸ć ˛ńż đ Ë­»Ľ ż­ ł«´¬·°ż¬¸ć ˛ńż đ Ń«¬ľ±«˛Ľ ײľ±«˛Ľ Ô±˝ż´ б´·˝§ Ü»˛·»Ľ Đ®»ş·¨»­ć óóóóóóóó óóóóóóó ̱¬ż´ć đ đ Ň«łľ»® ±ş ŇÔÎ×­ ·˛ ¬¸» «°Ľż¬» ­»˛¬ć łż¨ đô ł·˛ đ ݱ˛˛»˝¬·±˛­ »­¬żľ´·­¸»Ľ îĺ Ľ®±°°»Ľ ď Ôż­¬ ®»­»¬ đđćđčćďčô Ľ«» ¬± Đ»»® ˝´±­»Ľ ¬¸» ­»­­·±˛ ݱ˛˛»˝¬·±˛ ­¬ż¬» ·­ ŰÍĚßŢô ×ńŃ ­¬ż¬«­ć ďô «˛®»żĽ ·˛°«¬ ľ§¬»­ć đ ݱ˛˛»˝¬·±˛ ·­ ŰÝŇ Ü·­żľ´»Ľô Ó·˛·˛«ł ·˛˝±ł·˛ą ĚĚÔ đô Ń«¬ą±·˛ą ĚĚÔ ď Ô±˝ż´ ¸±­¬ć ďđňďňďíěňěô Ô±˝ż´ °±®¬ć ďéç Ú±®»·ą˛ ¸±­¬ć ďđňďňďíěňíô Ú±®»·ą˛ °±®¬ć ęđçéę ۲Ż«»«»Ľ °ż˝µ»¬­ ş±® ®»¬®ż˛­ł·¬ć đô ·˛°«¬ć đ ŰŞ»˛¬ Ě·ł»®­ ř˝«®®»˛¬ ¬·ł» ·­ đ¨ÝÚíîÝŢÚč÷ć Ě·ł»® ͬż®¬­ Éżµ»«°­ 묮ż˛­ ďď đ Ě·ł»Éż·¬ đ đ ß˝µŘ±´Ľ ďď ç Í»˛ĽÉ˛Ľ đ đ Ő»»°ß´·Ş» đ đ Ů·Ş»Ë° đ đ Đł¬«ßą»® đ đ Ü»żĽÉż·¬ đ đ

ł·­ó±®Ľ»®»Ľć đ ř𠾧¬»­÷

·­­ć ěčçéęîçčî ·®­ć ěđđíëđçďîď

­˛Ľ«˛żć ěčçéęíîíé ®˝Ş˛¨¬ć ěđđíëđçíéę

­˛Ľ˛¨¬ć ®˝Ş©˛Ľć

Ň»¨¬ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ đ¨đ ěčçéęíîíé ďęďíđ

­˛Ľ©˛Ľć Ľ»´®˝Ş©˛Ľć

ďęďíđ îëě

ÍÎĚĚć îíď ł­ô ÎĚĚŃć éęç ł­ô ÎĚĘć ëíč ł­ô ŐÎĚĚć đ ł­ ł·˛ÎĚĚć ěđ ł­ô łż¨ÎĚĚć íđđ ł­ô ßÝŐ ¸±´Ľć îđđ ł­ Ú´żą­ć °ż­­·Ş» ±°»˛ô ˛żą´»ô ą»˛ ¬˝ľ­ô łĽë ×Đ Đ®»˝»Ľ»˛˝» Şż´«» ć ę Üż¬żą®żł­ řłż¨ Ľż¬ż ­»ął»˛¬ ·­ ďěě𠾧¬»­÷ć Î˝ŞĽć ďí ř±«¬ ±ş ±®Ľ»®ć đ÷ô ©·¬¸ Ľż¬żć ďďô ¬±¬ż´ Ľż¬ż ľ§¬»­ć îëě Í»˛¬ć îđ ř®»¬®ż˛­ł·¬ć đô şż­¬®»¬®ż˛­ł·¬ć đô °ż®¬·ż´ż˝µć đô Í»˝±˛Ľ ݱ˛ą»­¬·±˛ć đ÷ô ©·¬¸ Ľż¬żć ďđô ¬±¬ż´ Ľż¬ż ľ§¬»­ć îëě

3. Announce networks into BGP. 3.1. Use the following example to configure router R3 in this lab: Îíý ®±«¬»® ľą° ďí𠲻¬©±®µ ďéîňíđňďíňđ łż­µ îëëňîëëňîëëňđ ®»Ľ·­¬®·ľ«¬» ˝±˛˛»˝¬»Ľ ®±«¬»ółż° ÎÓóŢŮĐ ˙ ·° ż˝˝»­­ó´·­¬ ­¬ż˛Ľż®Ľ ßÝÔóŢŮĐ °»®ł·¬ ďđňíňíňí ˙ ˙ ®±«¬»ółż° ÎÓóŢŮĐ °»®ł·¬ ďđ łż¬˝¸ ·° żĽĽ®»­­ ßÝÔóŢŮĐ 314

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

3.2. Use the following example to configure router R2 in this lab. Îîý ®±«¬»® ľą° îđ𠲻¬©±®µ ďçîňďęčňďň𠲻¬©±®µ ďçîňďęčňîň𠲻¬©±®µ ďçîňďęčňíňđ żąą®»ąż¬»óżĽĽ®»­­ ďçîňďęčňđňđ îëëňîëëňđňđ ­«łłż®§ó±˛´§

3.3. Verify the BGP table in order to see announced routes. Îďý­¸±© ·° ľą° ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ěô ´±˝ż´ ®±«¬»® ×Ü ·­ ďđňďňďďíňď ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô ® Î×Ţóşż·´«®»ô Í Í¬ż´» Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬» Ň»¬©±®µ ö ďđňíňíňíńíî öâ ö ďéîňíđňďíňđńîě öâ ö ďçîňďęčňđňđńďę öâ

Ň»¨¬ ر° ďđňďňďďîňî ďđňďňďďíňí ďđňďňďďîňî ďđňďňďďíňí ďđňďňďďíňí ďđňďňďďîňî

Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ đ đ đ đ đ đ đ đ đ

Đż¬¸ îđđ ěđđ ďíđ á ďíđ á îđđ ěđđ ďíđ · ďíđ · ďíđ ěđđ îđđ · îđđ ·

Îîý­¸±© ·° ľą° ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďđô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčňíňď ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô ® Î×Ţóşż·´«®»ô Í Í¬ż´» Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬» ö öâ ö öâ öâ ­â ­â ­â

Ň»¬©±®µ ďđňíňíňíńíî ďéîňíđňďíňđńîě ďçîňďęčňđňđńďę ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ

Ň»¨¬ ر° ďđňďňďďîňď ďđňďňďîěňě ďđňďňďďîňď ďđňďňďîěňě đňđňđňđ đňđňđňđ đňđňđňđ đňđňđňđ

Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ đ đ đ đ íîéęč đ íîéęč đ íîéęč đ íîéęč

Đż¬¸ ďđđ ďíđ ěđđ ďíđ ďđđ ďíđ ěđđ ďíđ · · · ·

á á · ·

Îíý­¸±© ·° ľą° ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ěô ´±˝ż´ ®±«¬»® ×Ü ·­ ďđňíňíňí ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô ® Î×Ţóşż·´«®»ô Í Í¬ż´» Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬» Ň»¬©±®µ öâ ďđňíňíňíńíî öâ ďéîňíđňďíňđńîě ö ďçîňďęčňđňđńďę öâ

Ň»¨¬ ر° đňđňđňđ đňđňđňđ ďđňďňďďíňď ďđňďňďíěňě

Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸ đ íîéęč á đ íîéęč · đ ďđđ îđđ · đ ěđđ îđđ ·

Îěý­¸±© ·° ľą° ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ îîô ´±˝ż´ ®±«¬»® ×Ü ·­ ďđňďňďíěňě ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô ® Î×Ţóşż·´«®»ô Í Í¬ż´» Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬» Ň»¬©±®µ ö ďđňíňíňíńíî öâ ö ďéîňíđňďíňđńîě öâ öâ ďçîňďęčňđňđńďę © 2009 Cisco Systems, Inc.

Ň»¨¬ ر° ďđňďňďîěňî ďđňďňďíěňí ďđňďňďîěňî ďđňďňďíěňí ďđňďňďîěňî

Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ đ đ đ đ đ đ đ đ

Đż¬¸ îđđ ďđđ ďíđ á ďíđ á îđđ ďđđ ďíđ · ďíđ · îđđ · Lab Guide

315

-------- The page intentionally left blank. --------

316

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Lab 6-2: Manipulate EBGP Path Selections Complete this lab activity to practice what you learned in the related module.

Activity Objective In this activity, you will use correct commands, tools, and steps to manipulate EBGP path selections. After completing this activity, you will be able to meet these objectives: Configure and verify policy-based routing Select the required tools and commands to configure PBR operations Make a list of configuration and implementation steps Write a verification and test plan to verify the proper implementation and operation according to the expected performance criteria. Verify the configuration and operation by using the proper show and debug commands

Information Packet The figure illustrates what you will accomplish in this activity.

Visual Objective

Visual Objective for Lab 6-2: Manipulate EBGP Path Selections

© 2009 Cis co S y st em s, Inc. A ll right s reserved.

ROUTE v 1. 0—LG-19

Implementation Policy The following list details the configuration requirements for all devices in the company network: In this task you will deploy the EBGP routing protocol in your pod. The network topology should consist of the following BGP autonomous systems: © 2009 Cisco Systems, Inc.

Lab Guide

317

—

AS 130 with router R3 and switch SW1 as members

—

AS 100 with router R1 as a member

—

AS 200 with router R2 as a member

—

AS 400 with router R4 as a member

AS 130 will have EBGP sessions to AS 100 in order to receive IP information about the networks in AS 200. AS 200 should have EBGP sessions to AS 100 and AS 400 to exchange IP routing information. Change the default BGP path selection for the traffic from AS 103 that are sent to networks originated from AS 200. Change the primary path for the traffic that is returning to AS 130. Examine the EBGP adjacencies and verify that adjacencies are set up between the routers R1, R2, R3, and R4. Verify that the router IP routing tables are populated with the required networks. Examine the path of IP packets sourced from AS 130 that are sent to networks in AS 200. Examine the path of IP packets returning to AS 130 from AS 200. Deploy additional EBGP sessions in your pod. Establish the following additional EBGP adjacencies: —

AS 130 to AS 100 between switch SW1 and router R1

—

AS 130 to AS 400 between routers R3 and R4

—

AS 130 between router R3 and switch SW1

Delete the following EBGP sessions: —

AS 130 to AS 100 between routers R3 and R1

Influence AS 130 path selection to select the primary path out of the AS via router R4 in AS 400. Influence the path of the traffic coming into AS 130 from AS 200. The path via router R1 should be preferred. Examine the EBGP adjacencies and verify they are set up between the routers. Verify that the routers have their IP routing tables populated with the required networks. Examine the primary path out of AS 130. Examine and verify the path of IP packets coming into AS 130.

Device Information The table provides the information specific to each switch in the network:

318

Device name

Role

R1

POD router

R2

POD router

R3

POD router

R4

POD router

BBR2

Backbone router

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Command List The table describes the commands that are used in this activity. Command

Description

router bgp

Configures the BGP routing process

[no] synchronization

Enables the synchronization between BGP and your Interior Gateway Protocol (IGP) system

bgp log-neighbor-changes

Enables logging of BGP neighbor resets

[no]auto-summary (BGP)

Configures automatic summarization of subnet routes into network-level routes

neighbor remote-as

Adds an entry to the BGP or multiprotocol BGP neighbor table

show ip bgp summary

Displays the status of all BGP connections

show ip bgp

Displays entries in the Border Gateway Protocol (BGP) routing table

network (BGP and multiprotocol BGP)

Specifies the networks to be advertised by the BGP and multiprotocol BGP routing processes

show ip route

Displays whole IP routing table

neighbor route-map

Applys a route map to incoming or outgoing routes

route-map

Defines the conditions for redistributing routes from one routing protocol into another, or enables policy routing

Required Resources These are the resources and equipment that are required to complete this activity: A PC that is connected to an on-site laboratory or a PC with an Internet connection if remote laboratory equipment must be accessed A terminal server that is connected to the console port of each laboratory device, if using a remote laboratory Core and access switches in your pod

Job Aids These are the job aids for this lab activity: Value

Location

Blank implementation requirements list

Task 1

Blank implementation and verification plan form

Task 2

Blank verification notes form

Task 3

Alternate resources and solutions form

End of this lab

Implementation requirements hints

“Hints” section at the end of this lab

Implementation and verification plan hints

“Hints” section at the end of this lab

Solution configuration answer key (step-bystep procedure)

Configuration section at the end of this lab

© 2009 Cisco Systems, Inc.

Lab Guide

319

-------- The page intentionally left blank. --------

320

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Task 1: Establish an Implementation Requirements List The first step in your configuration deployment is to establish a list of what is needed in order for you to configure each device; for example, device names, trunk encapsulation types, and so on. Use the following table, the visual objective at the beginning of this lab, the implementation policy, and the device information to create your implementation requirements list. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Device

© 2009 Cisco Systems, Inc.

Implementation Requirement

Lab Guide

321

Task 2: Create an Implementation and Verification Plan The second step in your configuration deployment is to establish a task list of the items that must be configured on each device, and in what order. Use the following table and the visual objective at the beginning of this lab to create your implementation and verification plan. If you are unsure, you can use the information provided in the “Hints” section at the end of this lab. Complete

322

Device

Order

Implementing Cisco IP Routing (ROUTE) v1.0

Values and Items to Implement

Verification Method and Expected Results

© 2009 Cisco Systems, Inc.

Task 3: Implement and Verify Now that you have collected all the requirements and planned your implementation, you are ready to connect to the remote lab and implement your solution. Do not forget to save. Once your solution is implemented, you need to verify that your configuration is working and fulfills all the requirements specified by the customer. Keep in mind that once you leave the company, a network specialist will verify your configuration. Your ability to implement the solution according to the customer specifications will determine whether you get the job or not. Use the following area to record your notes and document the verifications you conducted to ensure that your solution is complete. If you are unsure about the verification steps, use the information provided in the “Hints” section at the end of this lab. Student Notes: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ © 2009 Cisco Systems, Inc.

Lab Guide

323

__________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

324

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Alternate Resources and Solutions Other groups may have implemented a solution different from yours. These will be discussed during the debriefing period that will follow this lab. Use the following space to document other possible solutions for your reference. __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________

© 2009 Cisco Systems, Inc.

Lab Guide

325

-------- The page intentionally left blank. --------

326

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Hints You are encouraged to complete the labs using your knowledge. However, this section contains a series of hints to aid your completion of the lab.

Lab 6-2 Hint Sheet: Manipulate EBGP Path Selections Implementation Requirements To facilitate the configuration of your network, Task 1 asks you to create an implementation requirements list. This list details the elements you need in order to develop an implementation plan. The following is an example of such a list: Device

Implementation Requirement

Hint

ALL

Define BGP autonomous system numbers and assign them to routers

Implementation Policy

ALL

Define the networks that will be advertised

Implementation Policy Visual Objective

ALL

Define path manipulation rules

Implementation Policy

Implementation and Verification Plan In Task 2, you will create an implementation and verification plan. Although there are several ways to set up this plan, the following tasks must be completed: Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

R1–R4

1

Load the initial configuration.

All pod routers must be preloaded with the initial configuration for the lab.

Step 1

Establish the following EBGP adjacencies:

Examine the EBGP adjacencies and verify they are set up correctly between the routers.

Step 2

R1–R4

AS 130 to AS 100 – two EBGP sessions between routers R3 and R1 AS 100 to AS 200 between routers R1 and R2 AS 400 to AS 200 between routers R4 and R2

© 2009 Cisco Systems, Inc.

Lab Guide

327

Complete

Device

Order

Values and Items to Implement

Verification Method and Expected Results

Step

The following networks should be announced:

Verify the BGP table to verify that all networks are announced.

Step 3

Verify the IP routing table and BGP table in order to see the advertised networks and the preferred path for the packets.

Step 4

Examine the EBGP adjacencies and verify that they are set up correctly between the routers.

Step 5

Verify the IP routing table and BGP table in order to see the advertised networks and the preferred path for the packets.

Step 6

Announce the 172.30.13.0/24 network from router R3. Announce the 192.168.1.0/24, 192.168.2.0/24, and 192.168.3.0/24 networks from router R2. Change the default BGP path selection for the traffic from AS 103 that is sent to networks originated from AS 200. The path via 10.1.131.1 should be preferred over the second option, via 10.1.113.1. For the traffic that is returning to AS 130, the path via 10.1.131.1 should be the primary path. Establish the following additional EBGP adjacencies: AS 130 to AS 100 between switch SW1 and router R1 AS 130 to AS 400 between routers R3 and R4 AS 130 between router R3 and switch SW1 Delete the following EBGP sessions: AS 130 to AS 100 between routers R3 and R1 Influence AS 130 path selection to select the primary path out of the AS via router R4 in AS 400. Influence the path of the traffic coming into AS 130 from AS 200. The path via router R1 should be preferred.

Step-by-Step Procedure for Implementation and Verification 1. Load the initial configuration to all devices in your lab. 1.1. The instructor will provide guidelines for changing the initial configuration.

328

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

2. Establish EBGP adjacencies. 2.1. Use the following example to configure the routers in this lab: Îďý ®±«¬»® ľą° ďđ𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»·ą¸ľ±® ďđňďňďďîňî ®»ł±¬»óż­ îđ𠲻·ą¸ľ±® ďđňďňďďíňí ®»ł±¬»óż­ ďí𠲻·ą¸ľ±® ďđňďňďíďňí ®»ł±¬»óż­ ďí𠲱 ż«¬±ó­«łłż®§ Îîý ®±«¬»® ľą° îđ𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»·ą¸ľ±® ďđňďňďďîňď ®»ł±¬»óż­ ďđ𠲻·ą¸ľ±® ďđňďňďîěňě ®»ł±¬»óż­ ěđ𠲱 ż«¬±ó­«łłż®§ Îíý ®±«¬»® ľą° ďí𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»·ą¸ľ±® ďđňďňďďíňď ®»ł±¬»óż­ ďđ𠲻·ą¸ľ±® ďđňďňďíďňď ®»ł±¬»óż­ ďđ𠲱 ż«¬±ó­«łłż®§ Îěý ®±«¬»® ľą° ěđ𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»·ą¸ľ±® ďđňďňďîěňî ®»ł±¬»óż­ îđ𠲱 ż«¬±ó­«łłż®§

2.2. Verify that the adjacencies are established. Îďý­¸±© ·° ľą° ­«łłż®§ ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďđňďňďíďňďô ´±˝ż´ ßÍ ˛«łľ»® ďđđ ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ëô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ ë ě ˛»¬©±®µ »˛¬®·»­ «­·˛ą ěęč ľ§¬»­ ±ş ł»ł±®§ ë °ż¬¸ »˛¬®·»­ «­·˛ą îę𠾧¬»­ ±ş ł»ł±®§ ěńî ŢŮĐ °ż¬¸ńľ»­¬°ż¬¸ ż¬¬®·ľ«¬» »˛¬®·»­ «­·˛ą ěçę ľ§¬»­ ±ş ł»ł±®§ î ŢŮĐ ßÍóĐßĚŘ »˛¬®·»­ «­·˛ą ěč ľ§¬»­ ±ş ł»ł±®§ đ ŢŮĐ ®±«¬»ółż° ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ đ ŢŮĐ ş·´¬»®ó´·­¬ ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ ŢŮĐ «­·˛ą ďîéî ¬±¬ż´ ľ§¬»­ ±ş ł»ł±®§ ŢŮĐ ż˝¬·Ş·¬§ ďęńďî °®»ş·¨»­ô îçńîě °ż¬¸­ô ­˝ż˛ ·˛¬»®Şż´ ë ­»˝­ Ň»·ą¸ľ±® ͬż¬»ńĐş¨Î˝Ľ ďđňďňďďîňî ďđňďňďďíňí ďđňďňďíďňí

Ę ě ě ě

ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ îđđ ďíđ ďíđ

ęç ďđî çë

éí ďđî ďđî

Ěľ´Ę»® ë ë ë

×˛Ď Ń«¬Ď Ë°ńܱ©˛ đ đ đ

đ đđćđěćîč đ đđćđěćîí đ đđćđěćîč

í ď ď

Îîý­¸±© ·° ľą° ­«łłż®§ ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďçîňďęčňíňďô ´±˝ż´ ßÍ ˛«łľ»® îđđ ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďçô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ ďç ě ˛»¬©±®µ »˛¬®·»­ «­·˛ą ěęč ľ§¬»­ ±ş ł»ł±®§ ě °ż¬¸ »˛¬®·»­ «­·˛ą îđč ľ§¬»­ ±ş ł»ł±®§ íńî ŢŮĐ °ż¬¸ńľ»­¬°ż¬¸ ż¬¬®·ľ«¬» »˛¬®·»­ «­·˛ą íéî ľ§¬»­ ±ş ł»ł±®§ ď ŢŮĐ ßÍóĐßĚŘ »˛¬®·»­ «­·˛ą îě ľ§¬»­ ±ş ł»ł±®§ đ ŢŮĐ ®±«¬»ółż° ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ đ ŢŮĐ ş·´¬»®ó´·­¬ ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ ŢŮĐ «­·˛ą ďđéî ¬±¬ż´ ľ§¬»­ ±ş ł»ł±®§ ŢŮĐ ż˝¬·Ş·¬§ čńě °®»ş·¨»­ô ďďńé °ż¬¸­ô ­˝ż˛ ·˛¬»®Şż´ ęđ ­»˝­

© 2009 Cisco Systems, Inc.

Lab Guide

329

Ň»·ą¸ľ±® ͬż¬»ńĐş¨Î˝Ľ ďđňďňďďîňď ďđňďňďîěňě

Ę ě ě

ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ ďđđ ěđđ

éě ěđ

éđ ëę

Ěľ´Ę»® ďç ďç

×˛Ď Ń«¬Ď Ë°ńܱ©˛ đ đ

đ đđćđëćđî đ đđćíęćíě

ď đ

Îíý­¸±© ·° ľą° ­«łłż®§ ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďđňíňíňíô ´±˝ż´ ßÍ ˛«łľ»® ďíđ ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ îíô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ îí ě ˛»¬©±®µ »˛¬®·»­ «­·˛ą ěęč ľ§¬»­ ±ş ł»ł±®§ é °ż¬¸ »˛¬®·»­ «­·˛ą íęě ľ§¬»­ ±ş ł»ł±®§ íńî ŢŮĐ °ż¬¸ńľ»­¬°ż¬¸ ż¬¬®·ľ«¬» »˛¬®·»­ «­·˛ą íéî ľ§¬»­ ±ş ł»ł±®§ ď ŢŮĐ ßÍóĐßĚŘ »˛¬®·»­ «­·˛ą îě ľ§¬»­ ±ş ł»ł±®§ đ ŢŮĐ ®±«¬»ółż° ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ đ ŢŮĐ ş·´¬»®ó´·­¬ ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ ŢŮĐ «­·˛ą ďîîč ¬±¬ż´ ľ§¬»­ ±ş ł»ł±®§ ŢŮĐ ż˝¬·Ş·¬§ íîńîč °®»ş·¨»­ô éěńęé °ż¬¸­ô ­˝ż˛ ·˛¬»®Şż´ ë ­»˝­ Ň»·ą¸ľ±® ͬż¬»ńĐş¨Î˝Ľ ďđňďňďďíňď ďđňďňďíďňď

Ę ě ě

ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ ďđđ ďđđ

ďđí ďđí

ďđí çé

Ěľ´Ę»® îí îí

×˛Ď Ń«¬Ď Ë°ńܱ©˛ đ đ

đ đđćđëćďë đ đđćđëćîđ

í í

Îěý­¸±© ·° ľą° ­«łłż®§ ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďđňďňďíěňěô ´±˝ż´ ßÍ ˛«łľ»® ěđđ ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďçô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ ďç ě ˛»¬©±®µ »˛¬®·»­ «­·˛ą ěęč ľ§¬»­ ±ş ł»ł±®§ ě °ż¬¸ »˛¬®·»­ «­·˛ą îđč ľ§¬»­ ±ş ł»ł±®§ íńî ŢŮĐ °ż¬¸ńľ»­¬°ż¬¸ ż¬¬®·ľ«¬» »˛¬®·»­ «­·˛ą íéî ľ§¬»­ ±ş ł»ł±®§ î ŢŮĐ ßÍóĐßĚŘ »˛¬®·»­ «­·˛ą ěč ľ§¬»­ ±ş ł»ł±®§ đ ŢŮĐ ®±«¬»ółż° ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ đ ŢŮĐ ş·´¬»®ó´·­¬ ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ ŢŮĐ «­·˛ą ďđçę ¬±¬ż´ ľ§¬»­ ±ş ł»ł±®§ ŢŮĐ ż˝¬·Ş·¬§ ďďńé °®»ş·¨»­ô ďďńé °ż¬¸­ô ­˝ż˛ ·˛¬»®Şż´ ęđ ­»˝­ Ň»·ą¸ľ±® ͬż¬»ńĐş¨Î˝Ľ ďđňďňďîěňî

Ę ě

ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ îđđ

ëé

ěď

Ěľ´Ę»® ďç

×˛Ď Ń«¬Ď Ë°ńܱ©˛ đ

đ đđćíéćđç

ě

3. Announce the networks in BGP. 3.1. Use the following example to configure the routers in this lab: Îîý ®±«¬»® ľą° îđ𠲻¬©±®µ ďçîňďęčňďň𠲻¬©±®µ ďçîňďęčňîň𠲻¬©±®µ ďçîňďęčňíňđ Îíý ®±«¬»® ľą° ďí𠲻¬©±®µ ďéîňíđňďíňđ łż­µ îëëňîëëňîëëňđ

3.2. Verify the BPG table for the announced networks: Îďý­¸±© ·° ľą° ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ëô ´±˝ż´ ®±«¬»® ×Ü ·­ ďđňďňďíďňď ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô ® Î×Ţóşż·´«®»ô Í Í¬ż´» Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬» ö öâ öâ öâ öâ

Ň»¬©±®µ ďéîňíđňďíňđńîě ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ

Ň»¨¬ ر° ďđňďňďďíňí ďđňďňďíďňí ďđňďňďďîňî ďđňďňďďîňî ďđňďňďďîňî

Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸ ďđđđ đ ďíđ · đ đ ďíđ · đ đ îđđ · đ đ îđđ · đ đ îđđ ·

Îîý­¸±© ·° ľą° 330

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďçô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčňíňď ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô ® Î×Ţóşż·´«®»ô Í Í¬ż´» Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬» öâ öâ öâ öâ

Ň»¬©±®µ ďéîňíđňďíňđńîě ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ

Ň»¨¬ ر° ďđňďňďďîňď đňđňđňđ đňđňđňđ đňđňđňđ

Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ đ đ íîéęč đ íîéęč đ íîéęč

Đż¬¸ ďđđ ďíđ · · · ·

Îíý­¸±© ·° ľą° ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ îíô ´±˝ż´ ®±«¬»® ×Ü ·­ ďđňíňíňí ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô ® Î×Ţóşż·´«®»ô Í Í¬ż´» Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬» öâ ö öâ ö öâ ö öâ

Ň»¬©±®µ ďéîňíđňďíňđńîě ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ

Ň»¨¬ ر° đňđňđňđ ďđňďňďďíňď ďđňďňďíďňď ďđňďňďďíňď ďđňďňďíďňď ďđňďňďďíňď ďđňďňďíďňď

Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸ đ íîéęč · đ ďđđ îđđ ďđđđ ďđđ îđđ đ ďđđ îđđ ďđđđ ďđđ îđđ đ ďđđ îđđ ďđđđ ďđđ îđđ

· · · · · ·

Îěý­¸±© ·° ľą° ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďçô ´±˝ż´ ®±«¬»® ×Ü ·­ ďđňďňďíěňě ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô ® Î×Ţóşż·´«®»ô Í Í¬ż´» Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬» öâ öâ öâ öâ

Ň»¬©±®µ ďéîňíđňďíňđńîě ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ

Ň»¨¬ ر° ďđňďňďîěňî ďđňďňďîěňî ďđňďňďîěňî ďđňďňďîěňî

Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ đ đ đ đ đ đ đ

Đż¬¸ îđđ ďđđ ďíđ · îđđ · îđđ · îđđ ·

4. Change the default BGP path selection. 4.1. Use the following example to configure the routers in this lab: Îíý ®±«¬»® ľą° ďí𠲻·ą¸ľ±® ďđňďňďďíňď ®±«¬»ółż° ÎÓóÓŰÜ ±«¬ ˛»·ą¸ľ±® ďđňďňďíďňď ®±«¬»ółż° ÎÓóÉŰ×ŮŘĚ ·˛ ˙ ®±«¬»ółż° ÎÓóÉŰ×ŮŘĚ °»®ł·¬ ďđ ­»¬ ©»·ą¸¬ ďđđđ ˙ ®±«¬»ółż° ÎÓóÓŰÜ °»®ł·¬ ďđ ­»¬ ł»¬®·˝ ďđđđ

4.2. Verify the routing table for the preferred path of the packets. Îďý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ © 2009 Cisco Systems, Inc.

Lab Guide

331

Ţ Ý Ý Ý Ý Ţ Ţ Ţ

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­ ďéîňíđňďíňđ ĹîđńđĂ Ş·ż ďđňďňďíďňíô đđćđěćîë ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ ďđňďňďďďňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďđňďňďďíňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňî ďđňďňďďîňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňď ďđňďňďíďňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńď ďçîňďęčňďňđńîě ĹîđńđĂ Ş·ż ďđňďňďďîňîô đđćđěćîë ďçîňďęčňîňđńîě ĹîđńđĂ Ş·ż ďđňďňďďîňîô đđćđěćîë ďçîňďęčňíňđńîě ĹîđńđĂ Ş·ż ďđňďňďďîňîô đđćđěćîë

Îîý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ţ Ý Ý Ý Ý Ý

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­ ďéîňíđňďíňđ ĹîđńđĂ Ş·ż ďđňďňďďîňďô đđćđěćëç ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ ďđňďňďîěňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďđňďňďďîňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňď ďçîňďęčňďňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíđ ďçîňďęčňîňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíď ďçîňďęčňíňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíî

Îíý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ý Ý Ý Ý Ý Ţ Ţ Ţ

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­ ďéîňíđňďíňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ô î łż­µ­ ďđňíňíňíńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ ďđňďňďďíňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňî ďđňďňďíďňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńď ďđňďňďíěňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňí ďçîňďęčňďňđńîě ĹîđńđĂ Ş·ż ďđňďňďíďňďô đđćđëćďě ďçîňďęčňîňđńîě ĹîđńđĂ Ş·ż ďđňďňďíďňďô đđćđëćďě ďçîňďęčňíňđńîě ĹîđńđĂ Ş·ż ďđňďňďíďňďô đđćđëćďě

Îěý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ţ

332

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­ ďéîňíđňďíňđ ĹîđńđĂ Ş·ż ďđňďňďîěňîô đđćđëćđď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ý Ý Ţ Ţ Ţ

ďđňďňďîěňđ ·­ Ľ·®»˝¬´§ ďđňďňďíěňđ ·­ Ľ·®»˝¬´§ ďçîňďęčňďňđńîě ĹîđńđĂ Ş·ż ďçîňďęčňîňđńîě ĹîđńđĂ Ş·ż ďçîňďęčňíňđńîě ĹîđńđĂ Ş·ż

˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňí ďđňďňďîěňîô đđćíéćďě ďđňďňďîěňîô đđćíéćďě ďđňďňďîěňîô đđćíéćďě

5. Establish additional adjacencies and remove a few of them. 5.1. Use the following example to configure the routers in this lab: Îďý ®±«¬»® ľą° ďđ𠲱 ˛»·ą¸ľ±® ďđňďňďďíňí ®»ł±¬»óż­ ďí𠲱 ˛»·ą¸ľ±® ďđňďňďíďňí ®»ł±¬»óż­ ďí𠲻·ą¸ľ±® ďđňďňďďďňďď ®»ł±¬»óż­ ďíđ Îíý ®±«¬»® ľą° ďí𠲻·ą¸ľ±® ďđňďňďíěňě ®»ł±¬»óż­ ěđ𠲻·ą¸ľ±® ďéîňíđňďíňďď ®»ł±¬»óż­ ďí𠲱 ˛»·ą¸ľ±® ďđňďňďďíňď ®»ł±¬»óż­ ďđ𠲱 ˛»·ą¸ľ±® ďđňďňďíďňď ®»ł±¬»óż­ ďđđ Îěý ®±«¬»® ľą° ěđ𠲻·ą¸ľ±® ďđňďňďíěňí ®»ł±¬»óż­ ďíđ ÍÉďý ®±«¬»® ľą° ďí𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ˛»·ą¸ľ±® ďđňďňďďďňď ®»ł±¬»óż­ ďđ𠲻·ą¸ľ±® ďéîňíđňďíňí ®»ł±¬»óż­ ďí𠲻¬©±®µ ďéîňíđňďíňđ łż­µ îëëňîëëňîëëň𠲱 ż«¬±ó­«łłż®§

5.2. Verify the preferred path of the packets. Îďý­¸±© ·° ľą° ­«łłż®§ ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďđňďňďíďňďô ´±˝ż´ ßÍ ˛«łľ»® ďđđ ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ëô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ ë ě ˛»¬©±®µ »˛¬®·»­ «­·˛ą ěęč ľ§¬»­ ±ş ł»ł±®§ é °ż¬¸ »˛¬®·»­ «­·˛ą íęě ľ§¬»­ ±ş ł»ł±®§ ěńî ŢŮĐ °ż¬¸ńľ»­¬°ż¬¸ ż¬¬®·ľ«¬» »˛¬®·»­ «­·˛ą ěçę ľ§¬»­ ±ş ł»ł±®§ í ŢŮĐ ßÍóĐßĚŘ »˛¬®·»­ «­·˛ą éî ľ§¬»­ ±ş ł»ł±®§ đ ŢŮĐ ®±«¬»ółż° ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ đ ŢŮĐ ş·´¬»®ó´·­¬ ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ ŢŮĐ «­·˛ą ďěđ𠬱¬ż´ ľ§¬»­ ±ş ł»ł±®§ ŢŮĐ ż˝¬·Ş·¬§ îçńîë °®»ş·¨»­ô ęîńëë °ż¬¸­ô ­˝ż˛ ·˛¬»®Şż´ ë ­»˝­ Ň»·ą¸ľ±® ďđňďňďďďňďď ďđňďňďďîňî

Ę ě ě

ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ ďíđ éđ çď îđđ ďěđ ďëî

Ěľ´Ę»® ë ë

×˛Ď Ń«¬Ď Ë°ńܱ©˛ ͬż¬»ńĐş¨Î˝Ľ đ đ đđćđîćëç ě đ đ đđćđîćëč í

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Îîý­¸±© ·° ľą° ­«łłż®§ ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďçîňďęčňíňďô ´±˝ż´ ßÍ ˛«łľ»® îđđ ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ éô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ é ě ˛»¬©±®µ »˛¬®·»­ «­·˛ą ěęč ľ§¬»­ ±ş ł»ł±®§ ë °ż¬¸ »˛¬®·»­ «­·˛ą îę𠾧¬»­ ±ş ł»ł±®§ ěńî ŢŮĐ °ż¬¸ńľ»­¬°ż¬¸ ż¬¬®·ľ«¬» »˛¬®·»­ «­·˛ą ěçę ľ§¬»­ ±ş ł»ł±®§ î ŢŮĐ ßÍóĐßĚŘ »˛¬®·»­ «­·˛ą ěč ľ§¬»­ ±ş ł»ł±®§ đ ŢŮĐ ®±«¬»ółż° ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ đ ŢŮĐ ş·´¬»®ó´·­¬ ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ ŢŮĐ «­·˛ą ďîéî ¬±¬ż´ ľ§¬»­ ±ş ł»ł±®§ ŢŮĐ ż˝¬·Ş·¬§ ëńď °®»ş·¨»­ô ęńď °ż¬¸­ô ­˝ż˛ ·˛¬»®Şż´ ęđ ­»˝­ © 2009 Cisco Systems, Inc.

Lab Guide

333

Ň»·ą¸ľ±® ďđňďňďďîňď ďđňďňďîěňě

Ę ě ě

ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ ďđđ ěč ěę ěđđ íę ěď

Ěľ´Ę»® é é

×˛Ď Ń«¬Ď Ë°ńܱ©˛ ͬż¬»ńĐş¨Î˝Ľ đ đ đđćîîćîî ď đ đ đđćíîćëč ď

Îíý­¸±© ·° ľą° ­«łłż®§ ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďđňíňíňíô ´±˝ż´ ßÍ ˛«łľ»® ďíđ ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ éô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ é ě ˛»¬©±®µ »˛¬®·»­ «­·˛ą ěęč ľ§¬»­ ±ş ł»ł±®§ ë °ż¬¸ »˛¬®·»­ «­·˛ą îę𠾧¬»­ ±ş ł»ł±®§ ëńî ŢŮĐ °ż¬¸ńľ»­¬°ż¬¸ ż¬¬®·ľ«¬» »˛¬®·»­ «­·˛ą ęî𠾧¬»­ ±ş ł»ł±®§ ď ŢŮĐ ßÍóĐßĚŘ »˛¬®·»­ «­·˛ą îě ľ§¬»­ ±ş ł»ł±®§ đ ŢŮĐ ®±«¬»ółż° ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ đ ŢŮĐ ş·´¬»®ó´·­¬ ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ ŢŮĐ «­·˛ą ďíéî ¬±¬ż´ ľ§¬»­ ±ş ł»ł±®§ ŢŮĐ ż˝¬·Ş·¬§ ęîńëč °®»ş·¨»­ô ďěëńďěđ °ż¬¸­ô ­˝ż˛ ·˛¬»®Şż´ ë ­»˝­ Ň»·ą¸ľ±® ďđňďňďíěňě ďéîňíđňďíňďď

Ę ě ě

ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ ěđđ čë čî ďíđ čç ďđč

Ěľ´Ę»® é é

×˛Ď Ń«¬Ď Ë°ńܱ©˛ ͬż¬»ńĐş¨Î˝Ľ đ đ đđćđęćěč í đ đ đđćđęćěç ď

Îěý­¸±© ·° ľą° ­«łłż®§ ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďđňďňďíěňěô ´±˝ż´ ßÍ ˛«łľ»® ěđđ ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ěđô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ ěđ ě ˛»¬©±®µ »˛¬®·»­ «­·˛ą ěęč ľ§¬»­ ±ş ł»ł±®§ ë °ż¬¸ »˛¬®·»­ «­·˛ą îę𠾧¬»­ ±ş ł»ł±®§ ěńî ŢŮĐ °ż¬¸ńľ»­¬°ż¬¸ ż¬¬®·ľ«¬» »˛¬®·»­ «­·˛ą ěçę ľ§¬»­ ±ş ł»ł±®§ í ŢŮĐ ßÍóĐßĚŘ »˛¬®·»­ «­·˛ą éî ľ§¬»­ ±ş ł»ł±®§ đ ŢŮĐ ®±«¬»ółż° ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ đ ŢŮĐ ş·´¬»®ó´·­¬ ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ ŢŮĐ «­·˛ą ďîçę ¬±¬ż´ ľ§¬»­ ±ş ł»ł±®§ ŢŮĐ ż˝¬·Ş·¬§ ďîńč °®»ş·¨»­ô ěďńíę °ż¬¸­ô ­˝ż˛ ·˛¬»®Şż´ ęđ ­»˝­ Ň»·ą¸ľ±® ͬż¬»ńĐş¨Î˝Ľ ďđňďňďîěňî ďđňďňďíěňí

Ę ě ě

ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ îđđ ďíđ

ďďč čí

ďďď čę

Ěľ´Ę»® ěđ ěđ

×˛Ď Ń«¬Ď Ë°ńܱ©˛ đ đ

đ đďćîéćďę đ đđćđéćîë

ě ď

­©ďý­¸±© ·° ľą° ­«łłż®§ ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďéîňíđňďíňďďô ´±˝ż´ ßÍ ˛«łľ»® ďíđ ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďçô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ ďç ě ˛»¬©±®µ »˛¬®·»­ «­·˛ą ěęč ľ§¬»­ ±ş ł»ł±®§ č °ż¬¸ »˛¬®·»­ «­·˛ą ěďę ľ§¬»­ ±ş ł»ł±®§ éńî ŢŮĐ °ż¬¸ńľ»­¬°ż¬¸ ż¬¬®·ľ«¬» »˛¬®·»­ «­·˛ą çč𠾧¬»­ ±ş ł»ł±®§ î ŢŮĐ ßÍóĐßĚŘ »˛¬®·»­ «­·˛ą ěč ľ§¬»­ ±ş ł»ł±®§ đ ŢŮĐ ®±«¬»ółż° ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ đ ŢŮĐ ş·´¬»®ó´·­¬ ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§ ŢŮĐ «­·˛ą ďçďî ¬±¬ż´ ľ§¬»­ ±ş ł»ł±®§ ŢŮĐ ż˝¬·Ş·¬§ îđńďę °®»ş·¨»­ô éíńęë °ż¬¸­ô ­˝ż˛ ·˛¬»®Şż´ ë ­»˝­ Ň»·ą¸ľ±® ͬż¬»ńĐş¨Î˝Ľ ďđňďňďďďňď ďéîňíđňďíňí

Ę ě ě

ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ ďđđ ďíđ

çę ďďđ

éë çď

Ěľ´Ę»® ďç ďç

×˛Ď Ń«¬Ď Ë°ńܱ©˛ đ đ

đ đđćđéćěď đ đđćđčćëč

í ě

6. Manipulate BGP path selection with local preference and AS path prepending. 6.1. Use the following example to configure the routers in this lab: Îíý ®±«¬»® ľą° ďí𠲻·ą¸ľ±® ďđňďňďíěňě ®±«¬»ółż° ÎÓóÔĐ ·˛ ˛»·ą¸ľ±® ďđňďňďíěňě ®±«¬»ółż° ÎÓóßĐĐ ±«¬ ˙ ®±«¬»ółż° ÎÓóÔĐ °»®ł·¬ ďđ ­»¬ ´±˝ż´ó°®»ş»®»˛˝» îđđ ˙ ®±«¬»ółż° ÎÓóßĐĐ °»®ł·¬ ďđ ­»¬ ż­ó°ż¬¸ °®»°»˛Ľ ďíđ ďíđ 334

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

6.2. Verify the preferred path of the packets. Îďý­¸±© ·° ľą° ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ëô ´±˝ż´ ®±«¬»® ×Ü ·­ ďđňďňďíďňď ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô ® Î×Ţóşż·´«®»ô Í Í¬ż´» Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬» öâ öâ öâ öâ

Ň»¬©±®µ ďéîňíđňďíňđńîě ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ

Ň»¨¬ ر° ďđňďňďďďňďď ďđňďňďďîňî ďđňďňďďîňî ďđňďňďďîňî

Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸ đ đ ďíđ · đ đ îđđ · đ đ îđđ · đ đ îđđ ·

Îîý­¸±© ·° ľą° ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ íđô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčňíňď ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô ® Î×Ţóşż·´«®»ô Í Í¬ż´» Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬» öâ öâ öâ öâ

Ň»¬©±®µ ďéîňíđňďíňđńîě ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ

Ň»¨¬ ر° ďđňďňďďîňď đňđňđňđ đňđňđňđ đňđňđňđ

Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ đ đ íîéęč đ íîéęč đ íîéęč

Đż¬¸ ďđđ ďíđ · · · ·

Îíý­¸±© ·° ľą° ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ éô ´±˝ż´ ®±«¬»® ×Ü ·­ ďđňíňíňí ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô ® Î×Ţóşż·´«®»ô Í Í¬ż´» Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬» Ň»¬©±®µ öâ ďéîňíđňďíňđńîě ö · öâ ďçîňďęčňďňđ ö · öâ ďçîňďęčňîňđ ö · öâ ďçîňďęčňíňđ ö ·

Ň»¨¬ ر° đňđňđňđ ďéîňíđňďíňďď ďđňďňďíěňě ďđňďňďďďňď ďđňďňďíěňě ďđňďňďďďňď ďđňďňďíěňě ďđňďňďďďňď

Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸ đ íîéęč · đ ďđđ đ · îđđ đ ěđđ îđđ đ ďđđ đ ďđđ îđđ îđđ đ ěđđ îđđ đ ďđđ đ ďđđ îđđ îđđ đ ěđđ îđđ đ ďđđ đ ďđđ îđđ

· · · · · ·

Îěý­¸±© ·° ľą° ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ěđô ´±˝ż´ ®±«¬»® ×Ü ·­ ďđňďňďíěňě ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô ® Î×Ţóşż·´«®»ô Í Í¬ż´» Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬» ö öâ öâ öâ öâ

Ň»¬©±®µ ďéîňíđňďíňđńîě ďçîňďęčňďňđ ďçîňďęčňîňđ ďçîňďęčňíňđ

Ň»¨¬ ر° ďđňďňďíěňí ďđňďňďîěňî ďđňďňďîěňî ďđňďňďîěňî ďđňďňďîěňî

Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸ đ đ ďíđ ďíđ ďíđ · đ îđđ ďđđ ďíđ · đ đ îđđ · đ đ îđđ · đ đ îđđ ·

Îďý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

© 2009 Cisco Systems, Inc.

Lab Guide

335

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ţ Ý Ý Ý Ý Ţ Ţ Ţ

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­ ďéîňíđňďíňđ ĹîđńđĂ Ş·ż ďđňďňďďďňďďô đđćđîćëď ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ ďđňďňďďďňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďđňďňďďíňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňî ďđňďňďďîňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňď ďđňďňďíďňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńď ďçîňďęčňďňđńîě ĹîđńđĂ Ş·ż ďđňďňďďîňîô đđćđîćëď ďçîňďęčňîňđńîě ĹîđńđĂ Ş·ż ďđňďňďďîňîô đđćđîćëď ďçîňďęčňíňđńîě ĹîđńđĂ Ş·ż ďđňďňďďîňîô đđćđîćëď

­©ďý­¸±© ·° ľą° ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďçô ´±˝ż´ ®±«¬»® ×Ü ·­ ďéîňíđňďíňďď ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô ® Î×Ţóşż·´«®»ô Í Í¬ż´» Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬» Ň»¬©±®µ ö ·ďéîňíđňďíňđńîě öâ ö ·ďçîňďęčňďňđ öâ ö ·ďçîňďęčňîňđ öâ ö ·ďçîňďęčňíňđ öâ

Ň»¨¬ ر° ďéîňíđňďíňí đňđňđňđ ďđňďňďíěňě ďđňďňďďďňď ďđňďňďíěňě ďđňďňďďďňď ďđňďňďíěňě ďđňďňďďďňď

Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸ đ ďđđ đ · đ íîéęč · đ îđđ đ ěđđ îđđ đ ďđđ îđđ đ îđđ đ ěđđ îđđ đ ďđđ îđđ đ îđđ đ ěđđ îđđ đ ďđđ îđđ

· · · · · ·

Îîý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ţ Ý Ý Ý Ý Ý

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­ ďéîňíđňďíňđ ĹîđńđĂ Ş·ż ďđňďňďďîňďô đđćđíćíě ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ ďđňďňďîěňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďđňďňďďîňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňď ďçîňďęčňďňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíđ ďçîňďęčňîňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíď ďçîňďęčňíňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µíî

Îíý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ý Ý Í Ý Ý 336

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­ ďéîňíđňďíňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ô î łż­µ­ ďđňíňíňíńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ ďđňďňďďďňđńîě ĹďńđĂ Ş·ż ďéîňíđňďíňďď ďđňďňďďíňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňî ďđňďňďíďňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńď

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ý Ţ Ţ Ţ

ďđňďňďíěňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňí ďçîňďęčňďňđńîě ĹîđńđĂ Ş·ż ďđňďňďíěňěô đđćđęćîí ďçîňďęčňîňđńîě ĹîđńđĂ Ş·ż ďđňďňďíěňěô đđćđęćîí ďçîňďęčňíňđńîě ĹîđńđĂ Ş·ż ďđňďňďíěňěô đđćđęćîí

Îěý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ţ Ý Ý Ţ Ţ Ţ

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­ ďéîňíđňďíňđ ĹîđńđĂ Ş·ż ďđňďňďîěňîô đđćđěćíî ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­ ďđňďňďîěňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Úż­¬Ű¬¸»®˛»¬đńđ ďđňďňďíěňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđńđňí ďçîňďęčňďňđńîě ĹîđńđĂ Ş·ż ďđňďňďîěňîô đđćđěćíî ďçîňďęčňîňđńîě ĹîđńđĂ Ş·ż ďđňďňďîěňîô đđćđěćíî ďçîňďęčňíňđńîě ĹîđńđĂ Ş·ż ďđňďňďîěňîô đđćđěćíî

­©ďý­¸±© ·° ®±«¬» ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î · ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî ·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬» ± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬» Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬ Ý Ý Ţ Ţ Ţ

ďéîňíđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­ ďéîňíđňďíňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ę´ż˛ďďí ďđňđňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­ ďđňďňďďďňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ę´ż˛ďďď ďçîňďęčňďňđńîě ĹîđńđĂ Ş·ż ďđňďňďďďňďô đđćđëćďě ďçîňďęčňîňđńîě ĹîđńđĂ Ş·ż ďđňďňďďďňďô đđćđëćďě ďçîňďęčňíňđńîě ĹîđńđĂ Ş·ż ďđňďňďďďňďô đđćđëćďě

© 2009 Cisco Systems, Inc.

Lab Guide

337

-------- The page intentionally left blank. --------

338

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Answer Key The correct answers and expected solutions for the activities that are described in this guide appear here.

Lab 1-1 Answer Key: Assess Skills for Implementing Complex Networks When you complete this activity, your lab configuration will be similar to the results in the “Hints” section of Lab 1-1.

Lab 2-1 Answer Key: Configure and Verify EIGRP Operations When you complete this activity, your lab configuration will be similar to the results here, with differences that are specific to your device or workgroup: Îďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďîěé ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îď ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňďíňď îëëňîëëňîëëňđ Ľ»´ż§ ďđđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđ © 2009 Cisco Systems, Inc.

Lab Guide

339

˛± ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îî ·° żĽĽ®»­­ ďđňďňďďîňď îëëňîëëňîëëňđ ·° ­«łłż®§óżĽĽ®»­­ »·ą®° ď ďçîňďęčňđňđ îëëňîëëňđňđ ë ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďî ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňě °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± ŢŢÎď ·° żĽĽ®»­­ ďđňďňďďëňď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďë ˙ ®±«¬»® »·ą®° ď °ż­­·Ş»ó·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đń𠲻¬©±®µ ďđňďňďďîňđ đňđňđňîëë ˛»¬©±®µ ďđňďňďďëňđ đňđňđňîëë ˛»¬©±®µ ďéîňíđňďíňđ đňđňđňîëë ˛± ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îîý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďđďę ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îî ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í 340

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňî îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďîňî îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďîď ˙ ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňďňďďîňđ đňđňđňîëë ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ˛»¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îíý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďđîě ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ © 2009 Cisco Systems, Inc.

Lab Guide

341

­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îí ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňďíňí îëëňîëëňîëëňđ Ľ»´ż§ ďđđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňí °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îě ·° żĽĽ®»­­ ďđňďňďíěňí îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíě ˙ ®±«¬»® »·ą®° ď °ż­­·Ş»ó·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đń𠲻¬©±®µ ďđňďňďíěňđ đňđňđňîëë ˛»¬©±®µ ďéîňíđňďíňđ đňđňđňîëë ˛± ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ 342

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îěý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć çéč ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îě ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňě îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňí °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îí ·° żĽĽ®»­­ ďđňďňďíěňě îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďěí ˙ ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňďňďíěňđ đňđňđňîëë ˛»¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ˛± ż«¬±ó­«łłż®§ © 2009 Cisco Systems, Inc.

Lab Guide

343

˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ

Lab 2-2 Answer Key: Configure and Verify EIGRP Circuit Emulation and Frame Relay Operations When you complete this activity, your lab configuration will be similar to the results here, with differences that are specific to your device or workgroup: Îďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďíđë ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îď ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đń𠲱 ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± 344

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îîô Îíô Îě ·° żĽĽ®»­­ ďđňďňďďđňď îëëňîëëňîëëň𠲱 ·° ­°´·¬ó¸±®·¦±˛ »·ą®° ď ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňî ďďî ľ®±żĽ˝ż­¬ ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňí ďďí ľ®±żĽ˝ż­¬ ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňě ďďě ľ®±żĽ˝ż­¬ ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňě °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± ŢŢÎď ·° żĽĽ®»­­ ďđňďňďďëňď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďë ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňë °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± ŢŢÎî ·° żĽĽ®»­­ ďđňďňďďęňď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďę ˙ ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îîý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć çîé ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îî © 2009 Cisco Systems, Inc.

Lab Guide

345

˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňî îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňî îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďîď ˙ ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđđ 346

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

»˛Ľ Îíý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďďíé ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îí ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďđňîëëňîëëňď îëëňîëëňîëëňđ ­»˝±˛Ľż®§ ·° żĽĽ®»­­ ďéîňíđňďíňí îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňí îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíď ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňí °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îě ·° żĽĽ®»­­ ďđňďňďíěňí îëëňîëëňîëëňđ Ľ»´ż§ íđđđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíě ˙ ®±«¬»® »·ą®° ď Şż®·ż˛˝» î ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§ © 2009 Cisco Systems, Inc.

Lab Guide

347

˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îěý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďđéę ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îě ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňě îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđ 348

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˛± ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňě îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďěď ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňí °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îí ·° żĽĽ®»­­ ďđňďňďíěňě îëëňîëëňîëëňđ Ľ»´ż§ íđđđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďěí ˙ ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ

Lab 2-3 Answer Key: Configure and Verify EIGRP Authentication When you complete this activity, your lab configuration will be similar to the results here, with differences that are specific to your device or workgroup: Îďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďíčí ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îď ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş © 2009 Cisco Systems, Inc.

Lab Guide

349

˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ µ»§ ˝¸ż·˛ ÔßŢîíóÔßŇ µ»§ ď µ»§ó­¬®·˛ą Ý·­˝±ÔßŇ ż˝˝»°¬ó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» ­»˛Ľó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» µ»§ ˝¸ż·˛ ÔßŢîíóÉßŇ µ»§ ď µ»§ó­¬®·˛ą Ý·­˝±ÉßŇ ż˝˝»°¬ó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» ­»˛Ľó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňďíňď îëëňîëëňîëëňđ ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ď łĽë ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ď ÔßŢîíóÔßŇ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îî ·° żĽĽ®»­­ ďđňďňďďîňď îëëňîëëňîëëňđ ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ď łĽë ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ď ÔßŢîíóÉßŇ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďî ˙ ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ 350

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îîý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďíčí ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îî ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ µ»§ ˝¸ż·˛ ÔßŢîíóÔßŇ µ»§ ď µ»§ó­¬®·˛ą Ý·­˝±ÔßŇ ż˝˝»°¬ó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» ­»˛Ľó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» µ»§ ˝¸ż·˛ ÔßŢîíóÉßŇ µ»§ ď µ»§ó­¬®·˛ą Ý·­˝±ÉßŇ ż˝˝»°¬ó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» ­»˛Ľó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňî îëëňîëëňîëëňđ ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ď łĽë ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ď ÔßŢîíóÔßŇ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđ © 2009 Cisco Systems, Inc.

Lab Guide

351

˛± ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďîňî îëëňîëëňîëëňđ ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ď łĽë ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ď ÔßŢîíóÉßŇ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďîď ˙ ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îíý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďíčí ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îí ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ µ»§ ˝¸ż·˛ ÔßŢîíóÔßŇ µ»§ ď µ»§ó­¬®·˛ą Ý·­˝±ÔßŇ ż˝˝»°¬ó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» 352

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

­»˛Ľó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» µ»§ ˝¸ż·˛ ÔßŢîíóÉßŇ µ»§ ď µ»§ó­¬®·˛ą Ý·­˝±ÉßŇ ż˝˝»°¬ó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» ­»˛Ľó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňďíňí îëëňîëëňîëëňđ ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ď łĽë ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ď ÔßŢîíóÔßŇ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňí °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îě ·° żĽĽ®»­­ ďđňďňďíěňí îëëňîëëňîëëňđ ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ď łĽë ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ď ÔßŢîíóÉßŇ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíě ˙ ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îěý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň © 2009 Cisco Systems, Inc.

Lab Guide

353

Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďíčí ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îě ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ µ»§ ˝¸ż·˛ ÔßŢîíóÔßŇ µ»§ ď µ»§ó­¬®·˛ą Ý·­˝±ÔßŇ ż˝˝»°¬ó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» ­»˛Ľó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» µ»§ ˝¸ż·˛ ÔßŢîíóÉßŇ µ»§ ď µ»§ó­¬®·˛ą Ý·­˝±ÉßŇ ż˝˝»°¬ó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» ­»˛Ľó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđç ·˛ş·˛·¬» ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňě îëëňîëëňîëëňđ ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ď łĽë ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ď ÔßŢîíóÔßŇ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňí °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îí ·° żĽĽ®»­­ ďđňďňďíěňě îëëňîëëňîëëňđ ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ď łĽë ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ď ÔßŢîíóÉßŇ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďěí ˙ ®±«¬»® »·ą®° ď 354

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ

Lab 2-4 Answer Key: Implement and Troubleshoot EIGRP Operations When you complete this activity, your lab configuration will be similar to the results here, with differences that are specific to your device or workgroup: Îďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďëěď ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îď ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ µ»§ ˝¸ż·˛ ÔßŢîě µ»§ ď µ»§ó­¬®·˛ą Ý·­˝± ż˝˝»°¬ó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđí ·˛ş·˛·¬» ­»˛Ľó´·ş»¬·ł» đěćđđćđđ Öż˛ ď îđđí ·˛ş·˛·¬» ˙ ˙ ˙ © 2009 Cisco Systems, Inc.

Lab Guide

355

˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đń𠲱 ·° żĽĽ®»­­ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îîô Îíô Îě ·° żĽĽ®»­­ ďđňďňďďđňď îëëňîëëňîëëň𠲱 ·° ­°´·¬ó¸±®·¦±˛ »·ą®° ď ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňî ďďî ľ®±żĽ˝ż­¬ ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňí ďďí ľ®±żĽ˝ż­¬ ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňě ďďě ľ®±żĽ˝ż­¬ ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňě °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± ŢŢÎď ·° żĽĽ®»­­ ďđňďňďďëňď îëëňîëëňîëëňđ ·° ż«¬¸»˛¬·˝ż¬·±˛ ł±Ľ» »·ą®° ď łĽë ·° ż«¬¸»˛¬·˝ż¬·±˛ µ»§ó˝¸ż·˛ »·ą®° ď ÔßŢîě ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďë ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňë °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± ŢŢÎî ·° żĽĽ®»­­ ďđňďňďďęňď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďę ˙ ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ

356

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Îîý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďđđ𠾧¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îî ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňěîňî îëëňîëëňîëëňđ ­»˝±˛Ľż®§ ·° żĽĽ®»­­ ďéîňíđňîěňî îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňî îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďîď ˙ ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđňđ ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ © 2009 Cisco Systems, Inc.

Lab Guide

357

˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îíý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďîđé ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îí ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňďíňí îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňí îëëňîëëňîëëňđ 358

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíď ˙ ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđňđ ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îěý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďđđ𠾧¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îě ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňěîňě îëëňîëëňîëëňđ ­»˝±˛Ľż®§ ·° żĽĽ®»­­ ďéîňíđňîěňě îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ © 2009 Cisco Systems, Inc.

Lab Guide

359

·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňě îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďěď ˙ ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđňđ ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľňíđňďíňí ˛±¬ ±˛ ˝±łł±˛ ­ »˛Ľ

Lab 3-1 Answer Key: Configure and Verify OSPF to Improve Routing Performance When you complete this activity, your lab configuration will be similar to the results here, with differences that are specific to your device or workgroup: Îďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďîđď ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îď ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ 360

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňďňďňď îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňďíňď îëëňîëëňîëëňđ ·° ±­°ş °®·±®·¬§ ďđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îîô Îě ·° żĽĽ®»­­ ďđňďňďďđňď îëëňîëëňîëëňđ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňî ďďî ľ®±żĽ˝ż­¬ ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňě ďďě ľ®±żĽ˝ż­¬ ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďňď đňđňđňđ ż®»ż 𠲻¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż 𠲻¬©±®µ ďéîňíđňďíňđ đňđňđňîëë ż®»ż đ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě © 2009 Cisco Systems, Inc.

Lab Guide

361

´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îîý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďđęď ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îî ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňîňîňî îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňî îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňî îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďîď ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż 𠲻¬©±®µ ďđňîňîňî đňđňđňđ ż®»ż 𠲻¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż đ ˙ 362

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îíý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďíčď ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îí ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňíňíňí îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíď ·° żĽĽ®»­­ ďçîňďęčňďňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíî ·° żĽĽ®»­­ ďçîňďęčňîňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíí ·° żĽĽ®»­­ ďçîňďęčňíňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ © 2009 Cisco Systems, Inc.

Lab Guide

363

·° żĽĽ®»­­ ďéîňíđňďíňí îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňí îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíď ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îě ·° żĽĽ®»­­ ďđňďňďíěňí îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíě ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďíěňđ đňđňđňîëë ż®»ż 𠲻¬©±®µ ďđňíňíňí đňđňđňđ ż®»ż 𠲻¬©±®µ ďéîňíđňďíňđ đňđňđňîëë ż®»ż đ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îěý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďîíë ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îě ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ 364

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňěňěňě îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňě îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňě îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďěď ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îí ·° żĽĽ®»­­ ďđňďňďíěňě îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďěí ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż 𠲻¬©±®µ ďđňďňďíěňđ đňđňđňîëë ż®»ż 𠲻¬©±®µ ďđňěňěňě đňđňđňđ ż®»ż 𠲻¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż đ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ © 2009 Cisco Systems, Inc.

Lab Guide

365

´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ

Lab 3-2 Answer Key: Implement and Verify OSPF Multiarea Routing When you complete this activity, your lab configuration will be similar to the results here, with differences that are specific to your device or workgroup: Îďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďěčé ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îď ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňďňďňď îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đń𠲱 ·° żĽĽ®»­­ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ 366

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îîô Îě ·° żĽĽ®»­­ ďđňďňďďđňď îëëňîëëňîëëňđ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňî ďďî ľ®±żĽ˝ż­¬ ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňě ďďě ľ®±żĽ˝ż­¬ ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îí ·° żĽĽ®»­­ ďđňďňďďíňď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďí ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňďďę °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± ŢŢÎî ·° żĽĽ®»­­ ďđňďňďďęňď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďę ˙ ®±«¬»® ±­°ş ď ®±«¬»®ó·Ľ ďňďňďňď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż îě ˛»¬©±®µ ďđňďňďďíňđ đňđňđňîëë ż®»ż í ˛»¬©±®µ ďđňďňďďęňđ đňđňđňîëë ż®»ż 𠲻·ą¸ľ±® ďđňďňďďđňî ˝±­¬ ďđ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îîý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďđí𠾧¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îî ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ © 2009 Cisco Systems, Inc.

Lab Guide

367

˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňîňîňî îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňî îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňî îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďîď ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż îě ˛»¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż îě ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îíý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďîěę ľ§¬»­ 368

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îí ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňíňíňí îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíď ·° żĽĽ®»­­ ďçîňďęčňďňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíî ·° żĽĽ®»­­ ďçîňďęčňîňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíí ·° żĽĽ®»­­ ďçîňďęčňíňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňďíňí îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďíňí îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíď ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ °ż­­·Ş»ó·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đń𠲻¬©±®µ ďđňďňďďíňđ đňđňđňîëë ż®»ż í ˛»¬©±®µ ďéîňíđňďíňđ đňđňđňîëë ż®»ż í ˙ © 2009 Cisco Systems, Inc.

Lab Guide

369

·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îěý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďđí𠾧¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îě ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňěňěňě îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňě îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± 370

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňě îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďěď ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż îě ˛»¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż îě ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ

Lab 3-3 Answer Key: Configure and Verify OSPF Route Summarization for Interarea and External Routes When you complete this activity, your lab configuration will be similar to the results here, with differences that are specific to your device or workgroup: Îďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďëîě ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îď ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ © 2009 Cisco Systems, Inc.

Lab Guide

371

˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňďňďňď îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đń𠲱 ·° żĽĽ®»­­ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îîô Îě ·° żĽĽ®»­­ ďđňďňďďđňď îëëňîëëňîëëňđ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňî ďďî ľ®±żĽ˝ż­¬ ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňě ďďě ľ®±żĽ˝ż­¬ ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îí ·° żĽĽ®»­­ ďđňďňďďíňď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďí ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňďďę °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± ŢŢÎî ·° żĽĽ®»­­ ďđňďňďďęňď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďę ˙ ®±«¬»® ±­°ş ď ®±«¬»®ó·Ľ ďňďňďňď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ż®»ż 𠮿˛ą» ďéîňíđňđňđ îëëňîëëňđň𠲻¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż îě ˛»¬©±®µ ďđňďňďďíňđ đňđňđňîëë ż®»ż í ˛»¬©±®µ ďđňďňďďęňđ đňđňđňîëë ż®»ż 𠲻·ą¸ľ±® ďđňďňďďđňî ˝±­¬ ďđ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ 372

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îîý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďđčé ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îî ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňîňîňî îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňî îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňî îëëňîëëňîëëňđ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ © 2009 Cisco Systems, Inc.

Lab Guide

373

·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďîď ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż îě ˛»¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż îě ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îíý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďëďç ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îí ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňíňíňí îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíď ·° żĽĽ®»­­ ďçîňďęčňďňď îëëňîëëňîëëňđ 374

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˙ ·˛¬»®şż˝» Ô±±°ľż˝µíî ·° żĽĽ®»­­ ďçîňďęčňîňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíí ·° żĽĽ®»­­ ďçîňďęčňíňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňďíňí îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďíňí îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíď ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ­«łłż®§óżĽĽ®»­­ ďçîňďęčňđňđ îëëňîëëňđňđ ®»Ľ·­¬®·ľ«¬» ˝±˛˛»˝¬»Ľ ­«ľ˛»¬­ ®±«¬»ółż° ÎÓóÔŃŃĐ °ż­­·Ş»ó·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đń𠲻¬©±®µ ďđňďňďďíňđ đňđňđňîëë ż®»ż í ˛»¬©±®µ ďéîňíđňďíňđ đňđňđňîëë ż®»ż í ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ·° ż˝˝»­­ó´·­¬ ­¬ż˛Ľż®Ľ ßÝÔóÔŃŃĐ °»®ł·¬ ďçîňďęčňďňđ đňđňđňîëë °»®ł·¬ ďçîňďęčňîňđ đňđňđňîëë °»®ł·¬ ďçîňďęčňíňđ đňđňđňîëë ˙ ˙ ®±«¬»ółż° ÎÓóÔŃŃĐ °»®ł·¬ ďđ łż¬˝¸ ·° żĽĽ®»­­ ßÝÔóÔŃŃĐ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îěý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň © 2009 Cisco Systems, Inc.

Lab Guide

375

Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďđčé ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îě ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňěňěňě îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňě îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňě îëëňîëëňîëëňđ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďěď ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż îě ˛»¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż îě ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ 376

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ

Lab 3-4 Answer Key: Configure and Verify OSPF Special Area Types When you complete this activity, your lab configuration will be similar to the results here, with differences that are specific to your device or workgroup: Îďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďęíç ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îď ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňďňďňď îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đń𠲱 ·° żĽĽ®»­­ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ © 2009 Cisco Systems, Inc.

Lab Guide

377

Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îîô Îě ·° żĽĽ®»­­ ďđňďňďďđňď îëëňîëëňîëëňđ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňî ďďî ľ®±żĽ˝ż­¬ ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňě ďďě ľ®±żĽ˝ż­¬ ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îí ·° żĽĽ®»­­ ďđňďňďďíňď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďí ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňďďę °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± ŢŢÎî ·° żĽĽ®»­­ ďđňďňďďęňď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďę ˙ ®±«¬»® ±­°ş ď ®±«¬»®ó·Ľ ďňďňďňď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ż®»ż í ˛­­ż ˛±ó­«łłż®§ ż®»ż îě ­¬«ľ ˛±ó­«łłż®§ ®»Ľ·­¬®·ľ«¬» ­¬ż¬·˝ ­«ľ˛»¬­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż îě ˛»¬©±®µ ďđňďňďďíňđ đňđňđňîëë ż®»ż í ˛»¬©±®µ ďđňďňďďęňđ đňđňđňîëë ż®»ż 𠲻·ą¸ľ±® ďđňďňďďđňî ˝±­¬ ďđ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ·° ®±«¬» ďçîňďęčňěňđ îëëňîëëňîëëňđ ďđňďňďďęňę ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îîý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďďîç ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ 378

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îî ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňîňîňî îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňî îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňî îëëňîëëňîëëňđ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďîď ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ż®»ż îě ­¬«ľ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż îě ˛»¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż îě ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ © 2009 Cisco Systems, Inc.

Lab Guide

379

˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îíý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďëďç ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îí ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňíňíňí îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíď ·° żĽĽ®»­­ ďçîňďęčňďňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíî ·° żĽĽ®»­­ ďçîňďęčňîňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíí ·° żĽĽ®»­­ ďçîňďęčňíňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňďíňí îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± 380

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďíňí îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíď ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ż®»ż í ˛­­ż ®»Ľ·­¬®·ľ«¬» ˝±˛˛»˝¬»Ľ ­«ľ˛»¬­ ®±«¬»ółż° ÎÓóÔŃŃĐ °ż­­·Ş»ó·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đń𠲻¬©±®µ ďđňďňďďíňđ đňđňđňîëë ż®»ż í ˛»¬©±®µ ďéîňíđňďíňđ đňđňđňîëë ż®»ż í ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ·° ż˝˝»­­ó´·­¬ ­¬ż˛Ľż®Ľ ßÝÔóÔŃŃĐ °»®ł·¬ ďçîňďęčňďňđ đňđňđňîëë °»®ł·¬ ďçîňďęčňîňđ đňđňđňîëë °»®ł·¬ ďçîňďęčňíňđ đňđňđňîëë ˙ ˙ ®±«¬»ółż° ÎÓóÔŃŃĐ °»®ł·¬ ďđ łż¬˝¸ ·° żĽĽ®»­­ ßÝÔóÔŃŃĐ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îěý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďďîç ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îě ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş © 2009 Cisco Systems, Inc.

Lab Guide

381

˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňěňěňě îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňě îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňě îëëňîëëňîëëňđ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďěď ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ż®»ż îě ­¬«ľ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż îě ˛»¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż îě ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđđ 382

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

»˛Ľ

Lab 3-5 Answer Key: Configure and Verify OSPF Authentication When you complete this activity, your lab configuration will be similar to the results here, with differences that are specific to your device or workgroup: Îďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďéîé ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îď ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňďňďňď îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đń𠲱 ·° żĽĽ®»­­ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îîô Îě ·° żĽĽ®»­­ ďđňďňďďđňď îëëňîëëňîëëňđ ·° ±­°ş ł»­­żą»óĽ·ą»­¬óµ»§ ď łĽë Ý×ÍÝŃ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňî ďďî ľ®±żĽ˝ż­¬ ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňě ďďě ľ®±żĽ˝ż­¬ © 2009 Cisco Systems, Inc.

Lab Guide

383

˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îí ·° żĽĽ®»­­ ďđňďňďďíňď îëëňîëëňîëëňđ ·° ±­°ş ż«¬¸»˛¬·˝ż¬·±˛ ·° ±­°ş ż«¬¸»˛¬·˝ż¬·±˛óµ»§ Ý×ÍÝŃ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďí ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňďďę °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± ŢŢÎî ·° żĽĽ®»­­ ďđňďňďďęňď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďę ˙ ®±«¬»® ±­°ş ď ®±«¬»®ó·Ľ ďňďňďňď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ż®»ż îě ż«¬¸»˛¬·˝ż¬·±˛ ł»­­żą»óĽ·ą»­¬ ®»Ľ·­¬®·ľ«¬» ­¬ż¬·˝ ­«ľ˛»¬­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż îě ˛»¬©±®µ ďđňďňďďíňđ đňđňđňîëë ż®»ż í ˛»¬©±®µ ďđňďňďďęňđ đňđňđňîëë ż®»ż 𠲻·ą¸ľ±® ďđňďňďďđňî ˝±­¬ ďđ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ·° ®±«¬» ďçîňďęčňěňđ îëëňîëëňîëëňđ ďđňďňďďęňę ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îîý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďîíě ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îî ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ 384

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňîňîňî îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňî îëëňîëëňîëëňđ ·° ±­°ş ł»­­żą»óĽ·ą»­¬óµ»§ ď łĽë Ý×ÍÝŃ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňî îëëňîëëňîëëňđ ·° ±­°ş ł»­­żą»óĽ·ą»­¬óµ»§ ď łĽë Ý×ÍÝŃ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďîď ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ż®»ż îě ż«¬¸»˛¬·˝ż¬·±˛ ł»­­żą»óĽ·ą»­¬ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż îě ˛»¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż îě ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ

© 2009 Cisco Systems, Inc.

Lab Guide

385

Îíý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďëęě ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îí ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňíňíňí îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíď ·° żĽĽ®»­­ ďçîňďęčňďňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíî ·° żĽĽ®»­­ ďçîňďęčňîňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíí ·° żĽĽ®»­­ ďçîňďęčňíňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňďíňí îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďíňí îëëňîëëňîëëňđ ·° ±­°ş ż«¬¸»˛¬·˝ż¬·±˛ ·° ±­°ş ż«¬¸»˛¬·˝ż¬·±˛óµ»§ Ý×ÍÝŃ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíď 386

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ®»Ľ·­¬®·ľ«¬» ˝±˛˛»˝¬»Ľ ­«ľ˛»¬­ ®±«¬»ółż° ÎÓóÔŃŃĐ °ż­­·Ş»ó·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đń𠲻¬©±®µ ďđňďňďďíňđ đňđňđňîëë ż®»ż í ˛»¬©±®µ ďéîňíđňďíňđ đňđňđňîëë ż®»ż í ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ·° ż˝˝»­­ó´·­¬ ­¬ż˛Ľż®Ľ ßÝÔóÔŃŃĐ °»®ł·¬ ďçîňďęčňďňđ đňđňđňîëë °»®ł·¬ ďçîňďęčňîňđ đňđňđňîëë °»®ł·¬ ďçîňďęčňíňđ đňđňđňîëë ˙ ˙ ®±«¬»ółż° ÎÓóÔŃŃĐ °»®ł·¬ ďđ łż¬˝¸ ·° żĽĽ®»­­ ßÝÔóÔŃŃĐ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îěý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďîíě ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îě ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ © 2009 Cisco Systems, Inc.

Lab Guide

387

˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňěňěňě îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňě îëëňîëëňîëëňđ ·° ±­°ş ł»­­żą»óĽ·ą»­¬óµ»§ ď łĽë Ý×ÍÝŃ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňě îëëňîëëňîëëňđ ·° ±­°ş ł»­­żą»óĽ·ą»­¬óµ»§ ď łĽë Ý×ÍÝŃ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďěď ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ż®»ż îě ż«¬¸»˛¬·˝ż¬·±˛ ł»­­żą»óĽ·ą»­¬ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż îě ˛»¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż îě ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ

Lab 4-1 Answer Key: Configure Route Redistribution Between Multiple IP Routing Protocols When you complete this activity, your lab configuration will be similar to the results here, with differences that are specific to your device or workgroup: Îďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ 388

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďčëé ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îď ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňďňďňď îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đń𠲱 ·° żĽĽ®»­­ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îîô Îě ·° żĽĽ®»­­ ďđňďňďďđňď îëëňîëëňîëëňđ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňî ďďî ľ®±żĽ˝ż­¬ ş®żł»ó®»´ż§ łż° ·° ďđňďňďďđňě ďďě ľ®±żĽ˝ż­¬ ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îí ·° żĽĽ®»­­ ďđňďňďďíňď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďí ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňďďę °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± ŢŢÎî ·° żĽĽ®»­­ ďđňďňďďęňď îëëňîëëňîëëňđ © 2009 Cisco Systems, Inc.

Lab Guide

389

ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďę ˙ ®±«¬»® »·ą®° ď ®»Ľ·­¬®·ľ«¬» ®·° ®±«¬»ółż° ÎÓóÎ×Đ ®»Ľ·­¬®·ľ«¬» ±­°ş ď ˛»¬©±®µ ďđňďňďďęňđ đňđňđňîëë Ľ»şż«´¬ół»¬®·˝ ďëđđ ďđđ îëë ď ďëđđ ż«¬±ó­«łłż®§ ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ®»Ľ·­¬®·ľ«¬» ®·° ­«ľ˛»¬­ ®»Ľ·­¬®·ľ«¬» »·ą®° ď ­«ľ˛»¬­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż đ ˙ ®±«¬»® ®·° Ş»®­·±˛ î ®»Ľ·­¬®·ľ«¬» ±­°ş ď ˛»¬©±®µ ďđňđňđň𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ·° ż˝˝»­­ó´·­¬ ­¬ż˛Ľż®Ľ ßÝÔóÎ×Đ °»®ł·¬ ďçîňďęčňîňđ đňđňđňîëë °»®ł·¬ ďçîňďęčňíňđ đňđňđňîëë ˙ ˙ ®±«¬»ółż° ÎÓóÎ×Đ Ľ»˛§ ďđ łż¬˝¸ ·° żĽĽ®»­­ ßÝÔóÎ×Đ ˙ ®±«¬»ółż° ÎÓóÎ×Đ °»®ł·¬ çç ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îîý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďďďí ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îî ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ 390

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňîňîňî îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňî îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňî îëëňîëëňîëëňđ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďîď ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż 𠲻¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż đ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ © 2009 Cisco Systems, Inc.

Lab Guide

391

­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îíý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďěęí ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îí ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňíňíňí îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíď ·° żĽĽ®»­­ ďçîňďęčňďňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíî ·° żĽĽ®»­­ ďçîňďęčňîňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíí ·° żĽĽ®»­­ ďçîňďęčňíňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňďíňí îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďíňí îëëňîëëňîëëňđ 392

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíď ˙ ®±«¬»® ®·° Ş»®­·±˛ î ®»Ľ·­¬®·ľ«¬» ˝±˛˛»˝¬»Ľ ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđňđ Ľ·­¬®·ľ«¬»ó´·­¬ °®»ş·¨ ĐÔóÎ×Đ ±«¬ ˝±˛˛»˝¬»Ľ ˛± ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ·° ®±«¬» đňđňđňđ đňđňđňđ ďđňďňďďíňď ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ·° °®»ş·¨ó´·­¬ ĐÔóÎ×Đ ­»Ż ë °»®ł·¬ ďçîňďęčňďňđńîě ·° °®»ş·¨ó´·­¬ ĐÔóÎ×Đ ­»Ż ďđ °»®ł·¬ ďçîňďęčňîňđńîě ·° °®»ş·¨ó´·­¬ ĐÔóÎ×Đ ­»Ż ďë °»®ł·¬ ďçîňďęčňíňđńîě ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îěý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďďďí ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îě ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ © 2009 Cisco Systems, Inc.

Lab Guide

393

˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňěňěňě îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňě îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňě îëëňîëëňîëëňđ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďěď ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż 𠲻¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż đ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ

Lab 5-1 Answer Key: Configure and Verify Path Control Between Multiple IP Routing Protocols When you complete this activity, your lab configuration will be similar to the results here, with differences that are specific to your device or workgroup: Îďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďďďí ľ§¬»­ ˙ 394

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îě ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňěňěňě îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňě îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď ł«´¬·°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďđňě îëëňîëëňîëëňđ ·° ±­°ş ˛»¬©±®µ °±·˛¬ó¬±ół«´¬·°±·˛¬ ·° ±­°ş ¸»´´±ó·˛¬»®Şż´ ďđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďěď ˙ ®±«¬»® ±­°ş ď ´±ąóżĽ¶ż˝»˛˝§ó˝¸ż˛ą»­ ˛»¬©±®µ ďđňďňďďđňđ đňđňđňîëë ż®»ż 𠲻¬©±®µ ďéîňíđňîěňđ đňđňđňîëë ż®»ż đ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ © 2009 Cisco Systems, Inc.

Lab Guide

395

˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îîý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć çëë ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îî ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňî îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďîňî îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďîď 396

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˙ ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îíý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďďéç ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îí ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňďíňí îëëňîëëňîëëňđ ·° °±´·˝§ ®±«¬»ółż° ÎÓóĐŢÎ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď © 2009 Cisco Systems, Inc.

Lab Guide

397

˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ ·° żĽĽ®»­­ ďđňďňďíěňí îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíě ˙ ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ·° ż˝˝»­­ó´·­¬ »¨¬»˛Ľ»Ľ ßÝÔóĐŢÎ °»®ł·¬ ·° ¸±­¬ ďéîňíđňďíňďď ďçîňďęčňďňđ đňđňđňîëë °»®ł·¬ ·° ¸±­¬ ďéîňíđňďíňďď ďçîňďęčňîňđ đňđňđňîëë ˙ ˙ ®±«¬»ółż° ÎÓóĐŢÎ °»®ł·¬ ďđ łż¬˝¸ ·° żĽĽ®»­­ ßÝÔóĐŢÎ ­»¬ ·° ˛»¨¬ó¸±° ďéîňíđňďíňď ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îěý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďďéď ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îě ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş 398

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíď ·° żĽĽ®»­­ ďçîňďęčňďňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíî ·° żĽĽ®»­­ ďçîňďęčňîňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíí ·° żĽĽ®»­­ ďçîňďęčňíňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňîěňě îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňí °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îí ·° żĽĽ®»­­ ďđňďňďíěňě îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďěí ˙ ®±«¬»® »·ą®° ď ˛»¬©±®µ ďđňđňđň𠲻¬©±®µ ďéîňíđňđň𠲻¬©±®µ ďçîňďęčňđňđ đňđňîëëňîëë ˛± ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ © 2009 Cisco Systems, Inc.

Lab Guide

399

´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ

Lab 6-1 Answer Key: Configure BGP Operations When you complete this activity, your lab configuration will be similar to the results here, with differences that are specific to your device or workgroup: Îďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďďęë ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îď ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đń𠲱 ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îî ·° żĽĽ®»­­ ďđňďňďďîňď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďî ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ 400

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ľ»­˝®·°¬·±˛ ´·˛µ ¬± Îí ·° żĽĽ®»­­ ďđňďňďďíňď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďí ˙ ®±«¬»® ľą° ďđ𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»·ą¸ľ±® ďđňďňďďîňî ®»ł±¬»óż­ îđ𠲻·ą¸ľ±® ďđňďňďďíňí ®»ł±¬»óż­ ďí𠲻·ą¸ľ±® ďđňďňďďíňí °ż­­©±®Ľ ˝·­˝± ˛± ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îîý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďííě ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îî ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíđ © 2009 Cisco Systems, Inc.

Lab Guide

401

·° żĽĽ®»­­ ďçîňďęčňďňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíď ·° żĽĽ®»­­ ďçîňďęčňîňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíî ·° żĽĽ®»­­ ďçîňďęčňíňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďđňďňďîěňî îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďîňî îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďîď ˙ ®±«¬»® ľą° îđ𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»¬©±®µ ďçîňďęčňďň𠲻¬©±®µ ďçîňďęčňîň𠲻¬©±®µ ďçîňďęčňíňđ żąą®»ąż¬»óżĽĽ®»­­ ďçîňďęčňđňđ îëëňîëëňđňđ ­«łłż®§ó±˛´§ ˛»·ą¸ľ±® ďđňďňďďîňď ®»ł±¬»óż­ ďđ𠲻·ą¸ľ±® ďđňďňďîěňě ®»ł±¬»óż­ ěđ𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îíý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďěę𠾧¬»­ ˙ 402

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îí ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňíňíňí îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňďíňí îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ ´·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďíňí îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíď ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňí °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ ´·˛µ ¬± Îě ·° żĽĽ®»­­ ďđňďňďíěňí îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíě ˙ ®±«¬»® ľą° ďí𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»¬©±®µ ďéîňíđňďíňđ łż­µ îëëňîëëňîëëňđ ®»Ľ·­¬®·ľ«¬» ˝±˛˛»˝¬»Ľ ®±«¬»ółż° ÎÓóŢŮĐ ˛»·ą¸ľ±® ďđňďňďďíňď ®»ł±¬»óż­ ďđ𠲻·ą¸ľ±® ďđňďňďďíňď °ż­­©±®Ľ ˝·­˝± ˛»·ą¸ľ±® ďđňďňďíěňě ®»ł±¬»óż­ ěđ𠲻·ą¸ľ±® ďđňďňďíěňě °ż­­©±®Ľ ˝·­˝± ˛± ż«¬±ó­«łłż®§ ˙ © 2009 Cisco Systems, Inc.

Lab Guide

403

·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ·° ż˝˝»­­ó´·­¬ ­¬ż˛Ľż®Ľ ßÝÔóŢŮĐ °»®ł·¬ ďđňíňíňí ˙ ˙ ®±«¬»ółż° ÎÓóŢŮĐ °»®ł·¬ ďđ łż¬˝¸ ·° żĽĽ®»­­ ßÝÔóŢŮĐ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îěý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďđě𠾧¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îě ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďđňďňďîěňě îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ 404

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňí °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îí ·° żĽĽ®»­­ ďđňďňďíěňě îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďěí ˙ ®±«¬»® ľą° ěđ𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»·ą¸ľ±® ďđňďňďîěňî ®»ł±¬»óż­ îđ𠲻·ą¸ľ±® ďđňďňďíěňí ®»ł±¬»óż­ ďí𠲻·ą¸ľ±® ďđňďňďíěňí °ż­­©±®Ľ ˝·­˝± ˛± ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ

Lab 6-2 Answer Key: Manipulate EBGP Path Selections When you complete this activity, your lab configuration will be similar to the results here, with differences that are specific to your device or workgroup: Îďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďďčî ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îď ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş © 2009 Cisco Systems, Inc.

Lab Guide

405

˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďđňďňďďďňď îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ·° żĽĽ®»­­ ďđňďňďíďňď îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îî ·° żĽĽ®»­­ ďđňďňďďîňď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďî ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ ´·˛µ ¬± Îí ·° żĽĽ®»­­ ďđňďňďďíňď îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďí ˙ ®±«¬»® ľą° ďđ𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»·ą¸ľ±® ďđňďňďďďňďď ®»ł±¬»óż­ ďí𠲻·ą¸ľ±® ďđňďňďďîňî ®»ł±¬»óż­ îđ𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđđ 406

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

»˛Ľ Îîý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďîéč ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îî ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíđ ·° żĽĽ®»­­ ďçîňďęčňďňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíď ·° żĽĽ®»­­ ďçîňďęčňîňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µíî ·° żĽĽ®»­­ ďçîňďęčňíňď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďđňďňďîěňî îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňď °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďîňî îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďîď ˙ ®±«¬»® ľą° îđ𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ © 2009 Cisco Systems, Inc.

Lab Guide

407

ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»¬©±®µ ďçîňďęčňďň𠲻¬©±®µ ďçîňďęčňîň𠲻¬©±®µ ďçîňďęčňíň𠲻·ą¸ľ±® ďđňďňďďîňď ®»ł±¬»óż­ ďđ𠲻·ą¸ľ±® ďđňďňďîěňě ®»ł±¬»óż­ ěđ𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ Îíý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďëéî ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îí ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Ô±±°ľż˝µđ ·° żĽĽ®»­­ ďđňíňíňí îëëňîëëňîëëňîëë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďéîňíđňďíňí îëëňîëëňîëëňđ 408

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ·° żĽĽ®»­­ ďđňďňďíďňí îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňî °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ ´·˛µ ¬± Îď ·° żĽĽ®»­­ ďđňďňďďíňí îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíď ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňí °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ ´·˛µ ¬± Îě ·° żĽĽ®»­­ ďđňďňďíěňí îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďíě ˙ ®±«¬»® ľą° ďí𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»¬©±®µ ďéîňíđňďíňđ łż­µ îëëňîëëňîëëň𠲻·ą¸ľ±® ďđňďňďíěňě ®»ł±¬»óż­ ěđ𠲻·ą¸ľ±® ďđňďňďíěňě ®±«¬»ółż° ÎÓóÔĐ ·˛ ˛»·ą¸ľ±® ďđňďňďíěňě ®±«¬»ółż° ÎÓóßĐĐ ±«¬ ˛»·ą¸ľ±® ďéîňíđňďíňďď ®»ł±¬»óż­ ďí𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ®±«¬»ółż° ÎÓóÔĐ °»®ł·¬ ďđ ­»¬ ´±˝ż´ó°®»ş»®»˛˝» îđđ ˙ ®±«¬»ółż° ÎÓóÉŰ×ŮŘĚ °»®ł·¬ ďđ ­»¬ ©»·ą¸¬ ďđđđ ˙ ®±«¬»ółż° ÎÓóßĐĐ °»®ł·¬ ďđ ­»¬ ż­ó°ż¬¸ °®»°»˛Ľ ďíđ ďíđ ˙ ®±«¬»ółż° ÎÓóÓŰÜ °»®ł·¬ ďđ ­»¬ ł»¬®·˝ ďđđđ ˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ

© 2009 Cisco Systems, Inc.

Lab Guide

409

Îěý­¸±© ®«˛˛·˛ąó˝±˛ş·ą«®ż¬·±˛ Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďđíî ľ§¬»­ ˙ Ş»®­·±˛ ďîňě ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą Ľż¬»¬·ł» ł­»˝ ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą Ľż¬»¬·ł» ł­»˝ ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» Îě ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ·° ˝»ş ˙ ˙ ˙ ˙ ·° ż«¬¸ó°®±¨§ łż¨ó˛±Ľż¬żó˝±˛˛­ í ·° żĽł·­­·±˛ łż¨ó˛±Ľż¬żó˝±˛˛­ í ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńđ ·° żĽĽ®»­­ ďđňďňďîěňě îëëňîëëňîëëňđ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ˛± ·° żĽĽ®»­­ ­¸«¬Ľ±©˛ Ľ«°´»¨ ż«¬± ­°»»Ľ ż«¬± ˙ ·˛¬»®şż˝» Í»®·ż´đńđń𠲱 ·° żĽĽ®»­­ »˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ ˛± şż·®óŻ«»«» ş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝± ˙ ·˛¬»®şż˝» Í»®·ż´đńđńđňí °±·˛¬ó¬±ó°±·˛¬ Ľ»­˝®·°¬·±˛ Ô·˛µ ¬± Îí ·° żĽĽ®»­­ ďđňďňďíěňě îëëňîëëňîëëňđ ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďěí ˙ ®±«¬»® ľą° ěđ𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»·ą¸ľ±® ďđňďňďîěňî ®»ł±¬»óż­ îđ𠲻·ą¸ľ±® ďđňďňďíěňí ®»ł±¬»óż­ ďí𠲱 ż«¬±ó­«łłż®§ ˙ ·° ş±®©ż®Ľó°®±¬±˝±´ ˛Ľ ˙ ˙ ·° ¸¬¬° ­»®Ş»® ˛± ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ 410

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

˙ ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ż«¨ đ ´·˛» ެ§ đ ě ´±ą·˛ ˙ ­˝¸»Ľ«´»® ż´´±˝ż¬» îđđđđ ďđđ𠻲Ľ ­©ďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć íčíę ľ§¬»­ ˙ Ş»®­·±˛ ďîňî ˛± ­»®Ş·˝» °żĽ ­»®Ş·˝» ¬·ł»­¬żł°­ Ľ»ľ«ą «°¬·ł» ­»®Ş·˝» ¬·ł»­¬żł°­ ´±ą «°¬·ł» ˛± ­»®Ş·˝» °ż­­©±®Ľó»˛˝®§°¬·±˛ ˙ ¸±­¬˛żł» ­©ď ˙ ľ±±¬ó­¬ż®¬ółż®µ»® ľ±±¬ó»˛Ľółż®µ»® ˙ ˙ ˛± żżż ˛»©ół±Ľ»´ ­§­¬»ł ł¬« ®±«¬·˛ą ďëđđ ·° ­«ľ˛»¬ó¦»®± ·° ®±«¬·˛ą ˙ ˙ ˙ ˙ ˝®§°¬± °µ· ¬®«­¬°±·˛¬ ĚĐó­»´şó­·ą˛»Ľóîđěďďęęëçî »˛®±´´ł»˛¬ ­»´ş­·ą˛»Ľ ­«ľ¶»˝¬ó˛żł» ˝˛ă×ŃÍóÍ»´şóÍ·ą˛»ĽóÝ»®¬·ş·˝ż¬»óîđěďďęęëçî ®»Ş±˝ż¬·±˛ó˝¸»˝µ ˛±˛» ®­żµ»§°ż·® ĚĐó­»´şó­·ą˛»Ľóîđěďďęęëçî ˙ ˙ ˝®§°¬± °µ· ˝»®¬·ş·˝ż¬» ˝¸ż·˛ ĚĐó­»´şó­·ą˛»Ľóîđěďďęęëçî ˝»®¬·ş·˝ż¬» ­»´şó­·ą˛»Ľ đď íđčîđîíÝ íđčîđďßë ßđđíđîđď đîđîđďđď íđđÜđęđç îßčęěččę íďíďîÚíđ îÜđęđíëë đěđíďíîę ěçěÚëíîÜ ëíęëęÝęę îÜëíęçęé ęçęęęçęí ęďéěęëîÜ íîíđíěíď íďíęíęíë íçíîíđďŰ ďéđÜíçíí íëíďëßďé đÜíîíđíđ íďíđíďíđ íđíđíđíđ íđëßíđíď íďîÚíđîÜ ěÚëíîÜëí ęëęÝęęîÜ ëíęçęéęŰ ęëęěîÜěí ęëéîéěęç ęęęçęíęď íęíęíëíç íîíđčďçÚ íđđÜđęđç îßčęěččę ÚéđÜđďđď đďđëđđđí čďđđßëçŢ ÜçŢíěŢŢđ ęééčÚÚďđ ďŰčěččéÜ čŰđîŰččď ÜÜŰëđěčß đíěçďěéÝ íďěééŢÚî íčçîŰďíç ŰďîŰďîęŢ đÝęęÚçëÝ ëëÝŢîííé ëëÝčîŢÜŢ ßďęîÝßÚď ÜęŰéŢęéë Ýëçßëîíé ęÚďŰçíëę ÝÚßčÝęčŰ éđîđÜěíî îđíçëîéí ííÜŢÝíđď ÝîÜîéÜđě çëÚŢčéçí çîîßđçßÝ čÝÜçđîđí đďđđđďßí ęěíđęîíđ đÚđęđíëë ďÜďíđďđď ÚÚđěđëíđ ëëďÜďďđě đčíđđęčî đěéíééíď îŰíđďÚđę đíëëďÜîí đěďčíđďę ÜééíÝíçí ŰđÚÜÜŰéÚ ďęÝíččŢŢ ßéŰîíđďÜ đęđíëëďÜ đŰđěďęđě éíÝíçíŰđ ÚÜÜŰéÚďę ÝíččŢŢßé ŰîíđđÜđę đçîßčęěč čęÚéđÜđď ęčŰÚÜđęđ ÝÜđÝÝěęî ěŰŰîëęčé Üěëëďíčî ëÝŰďďíéŢ ÝßßďÝííî íďčëîčęď éđěÜŢëčé ŢďçéęÚčë ďŢěëŢÝíę ěčÝßíęěÚ đčďďëßÜď ěçčçčÚŰŰ ÝďđîÜŢîî ęŰíđěđŰé ěŰîëÝŰÝę čÚÝŰđîíđ ëéđíęěßç ŢďŰééßçß ěďîęÚëďé čęÝďěěçß đčđěďÚëÜ čëÝéđěëí ęčęÚÜďďß © 2009 Cisco Systems, Inc.

ÚéđÜđďđď ęŰęëęěîÜ íđíííđíď đęđíëëđě éěęëîÜíî čďčÜđđíđ ŢŢßÜççÝÝ ÜŢÝéěíďë éŰďÝěîęč ďđçíéíÝç đíđďđďÚÚ čđďěßďîđ ďěßďîđŢÝ đďđěđëđđ đíÚđŢëďî ÜŢđîčíčÚ čßÜÝŢďęđ ÝëßÚđçÜě

đěđëđđíđ ěíęëéîéě íđíđíđíđ đíďíîęěç íđíěíďíď čďčçđîčď éîčÜŰÝčÚ îÜđđÚßéŢ ÜßďÝßďÜč ÚŢęęŰçđç íđđÚđęđí ŢÝÜŰÚęÝŢ ÜŰÚęÝŢÜé đíčďčďđđ îďçÜîîŰî íîíŰÜŰđč éčďŰčíŢß ęíÜčđďęß Lab Guide

411

Ż«·¬ ˙ ˙ ˙ ˙ ˙ ˙ ­°ż˛˛·˛ąó¬®»» ł±Ľ» °Ş­¬ ­°ż˛˛·˛ąó¬®»» »¨¬»˛Ľ ­§­¬»łó·Ľ ­°ż˛˛·˛ąó¬®»» Ş´ż˛ ď °®·±®·¬§ ëíîěč ˙ Ş´ż˛ ·˛¬»®˛ż´ ż´´±˝ż¬·±˛ °±´·˝§ ż­˝»˛Ľ·˛ą ˙ ˙ ˙ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńď ­©·¬˝¸°±®¬ ż˝˝»­­ Ş´ż˛ ďďď ­©·¬˝¸°±®¬ ł±Ľ» ż˝˝»­­ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńî ­©·¬˝¸°±®¬ ż˝˝»­­ Ş´ż˛ ďîě ­©·¬˝¸°±®¬ ł±Ľ» ż˝˝»­­ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńí ­©·¬˝¸°±®¬ ż˝˝»­­ Ş´ż˛ ďďí ­©·¬˝¸°±®¬ ł±Ľ» ż˝˝»­­ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńě ­©·¬˝¸°±®¬ ż˝˝»­­ Ş´ż˛ ďîě ­©·¬˝¸°±®¬ ł±Ľ» ż˝˝»­­ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńë ­©·¬˝¸°±®¬ ż˝˝»­­ Ş´ż˛ ďđđ ­©·¬˝¸°±®¬ ł±Ľ» ż˝˝»­­ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńę ­©·¬˝¸°±®¬ ¬®«˛µ »˛˝ż°­«´ż¬·±˛ Ľ±¬ďŻ ­©·¬˝¸°±®¬ ł±Ľ» ¬®«˛µ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńé ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńč ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńç ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńďđ ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńďď ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńďî ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńďí ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńďě ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńďë ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńďę ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńďé ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńďč ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńďç ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńîđ ˙ 412

Implementing Cisco IP Routing (ROUTE) v1.0

© 2009 Cisco Systems, Inc.

·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńîď ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńîî ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńîí ˙ ·˛¬»®şż˝» Úż­¬Ű¬¸»®˛»¬đńîě ˙ ·˛¬»®şż˝» Ů·ążľ·¬Ű¬¸»®˛»¬đńď ­©·¬˝¸°±®¬ ¬®«˛µ »˛˝ż°­«´ż¬·±˛ Ľ±¬ďŻ ­©·¬˝¸°±®¬ ł±Ľ» ¬®«˛µ ˙ ·˛¬»®şż˝» Ů·ążľ·¬Ű¬¸»®˛»¬đńî ­©·¬˝¸°±®¬ ¬®«˛µ »˛˝ż°­«´ż¬·±˛ Ľ±¬ďŻ ­©·¬˝¸°±®¬ ł±Ľ» ¬®«˛µ ˙ ·˛¬»®şż˝» Ę´ż˛ď ˛± ·° żĽĽ®»­­ ˙ ·˛¬»®şż˝» Ę´ż˛ďďď ·° żĽĽ®»­­ ďđňďňďďďňďď îëëňîëëňîëëňđ ˙ ·˛¬»®şż˝» Ę´ż˛ďďí ·° żĽĽ®»­­ ďéîňíđňďíňďď îëëňîëëňîëëňđ ˙ ®±«¬»® ľą° ďí𠲱 ­§˛˝¸®±˛·¦ż¬·±˛ ľą° ´±ąó˛»·ą¸ľ±®ó˝¸ż˛ą»­ ˛»¬©±®µ ďéîňíđňďíňđ łż­µ îëëňîëëňîëëň𠲻·ą¸ľ±® ďđňďňďďďňď ®»ł±¬»óż­ ďđ𠲻·ą¸ľ±® ďđňďňďďďňď ¬®ż˛­°±®¬ °ż¬¸ół¬«óĽ·­˝±Ş»®§ ˛»·ą¸ľ±® ďéîňíđňďíňí ®»ł±¬»óż­ ďí𠲻·ą¸ľ±® ďéîňíđňďíňí ¬®ż˛­°±®¬ °ż¬¸ół¬«óĽ·­˝±Ş»®§ ˛± ż«¬±ó­«łłż®§ ˙ ·° Ľ»şż«´¬óąż¬»©ż§ ďđňîňďęđňď ·° ˝´ż­­´»­­ ·° ¸¬¬° ­»®Ş»® ·° ¸¬¬° ­»˝«®»ó­»®Ş»® ˙ ˙ ˙ ˝±˛¬®±´ó°´ż˛» ˙ ˙ ´·˛» ˝±˛ đ ´·˛» ެ§ đ ě ´±ą·˛ ´·˛» ެ§ ë ďë ´±ą·˛ ˙ »˛Ľ

© 2009 Cisco Systems, Inc.

Lab Guide

413