Advanced Junos Service Provider Routing

Advanced Junos Service Provider Routing11.a

Detailed Lab Guide

1194 North Mathilda AvenueSunnyvale, CA 94089USA408-745-2000www.juniper.net

Worldwide Education ServicesWorldwide Education Services

Course Number: EDU-JUN-AJSPR

This document is produced by Juniper Networks, Inc.

This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks Education Services.

Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered
trademarks, or registered service marks are the property of their respective owners.
Advanced Junos Service Provider Routing Detailed Lab Guide, Revision 11.a

Copyright © 2012 Juniper Networks, Inc. All rights reserved.

Printed in USA.

Revision History:

Revision 10.a — March 2011

Revision 10.b—September 2011

Revision 11.a—January 2012.

The information in this document is current as of the date listed above.

The information in this document has been carefully verified and is believed to be accurate for software Release 11.4R1.14. Juniper Networks assumes no responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.

Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

YEAR 2000 NOTICE

Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.

SOFTWARE LICENSE

The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should consult the software license for further details.

Contents

Lab 1: OSPF Multiarea Networks (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1Part 1: Load Reset Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2Part 2: Creating the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8Part 3: Configuring the OSPF LInk Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13Part 4: Configuring Overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18Part 5: Performing Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21

Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Part 1: Creating OSPF Stub Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2Part 2: Creating Stub No Summaries Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7Part 3: Creating OSPF Not-So-Stubby-Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12Part 4: Creating NSSA No Summaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15

Lab 3: Advanced OSPF Options and Routing Policy (Detailed) . . . . . . . . . . . . . . . . 3-1Part 1: Establishing the OSPF Adjacencies and Creating a Virtual Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Part 2: Configuring OSPF Multiarea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8Part 3: Configuring External Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12

Lab 4: IS-IS Configuration and Monitoring (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . 4-1Part 1: Configuring the Transit Interfaces to Support ISO Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Part 2: Configuring the IS-IS Network Entity Title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7Part 3: Configuring Interfaces as Part of the IS-IS Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9Part 4: Migrating from OSPF to IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12Part 5: Examining the IS-IS Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15

Lab 5: Advanced IS-IS Configuration and Routing Policy (Detailed) . . . . . . . . . . . . 5-1Part 1: Building the Extended IS-IS Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2Part 2: Configuring IS-IS Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6Part 3: Manipulating IS-IS Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9Part 4: Configuring IS-IS External Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17

Lab 6: Configuring a Multilevel IS-IS Network (Detailed) . . . . . . . . . . . . . . . . . . . . . 6-1Part 1: Establishing the Multilevel IS-IS Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2Part 2: Examining the IS-IS Multilevel Flooding Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6Part 3: Modifying the Default Flooding Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11

Lab 7: BGP (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1Part 1: Establishing the OSPF Adjacency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2Part 2: Establishing an IBGP Peering Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6Part 3: Configuring the P1 and P2 EBGP Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10Part 4: Configuring the EBGP Session with the P3 Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19Part 5: Summarizing the Internal Routes to the Peer Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22

Lab 8: BGP Attributes: Next Hop, Origin, MED, and AS Path (Detailed) . . . . . . . . . 8-1Part 1: Repairing Unusable Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2Part 2: Modifying the Origin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8Part 3: Configuring the MED Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14Part 4: Modifying the AS Path Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20

www.juniper.net Contents • iii

Lab 9: BGP Attributes: Local-Preference and Communities (Detailed) . . . . . . . . . . 9-1Part 1: Modifying the Local-Preference Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2Part 2: Configuring BGP Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10

Lab 10: Scaling BGP (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1Part 1: Configuring Route Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2Part 2: Configuring Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16

Lab 11: BGP Route Damping (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1Part 1: Modifying IBGP Redistribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2Part 2: Configuring BGP Damping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-5Part 3: Modifying the BGP Damping Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-14

Appendix A: Lab Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

iv • Contents www.juniper.net

Course Overview

This four-day course is designed to provide students with detailed coverage of OSPF, IS-IS, BGP, and routing policy. Through demonstrations and hands-on labs, students will gain experience in configuring and monitoring the Junos operating system and in monitoring device and protocol operations. This course is based on the Junos OS Release 11.4R1.14.

Objectives

After successfully completing this course, you should be able to:

• Describe the various OSPF link-state advertisement (LSA) types.

• Explain the flooding of LSAs in an OSPF network.

• Describe the shortest-path-first (SPF) algorithm.

• List key differences between OSPFv2 and OSPFv3.

• Describe OSPF area types and operations.

• Configure various OSPF area types.

• Summarize and restrict routes.

• Identify some scenarios in a service provider network that can be solved using routing policy or specific configuration options.

• Use routing policy and specific configuration options to implement solutions for various scenarios.

• Explain the concepts and operation of IS-IS.

• Describe various IS-IS link-state protocol data unit (PDU) types.

• List IS-IS adjacency rules and troubleshoot common adjacency issues.

• Configure and monitor IS-IS.

• Display and interpret the link-state database (LSDB).

• Perform advanced IS-IS configuration options.

• Implement IS-IS routing policy.

• Explain the default operation in multiarea IS-IS.

• Describe IS-IS address summarization methods.

• Configure and monitor a multiarea IS-IS network.

• Describe basic BGP operation.

• List common BGP attributes.

• Explain the route selection process for BGP.

• Describe how to alter the route selection process.

• Configure some advanced options for BGP peers.

• Describe various BGP attributes in detail and explain the operation of those attributes.

• Manipulate BGP attributes using routing policy.

• Explain the causes for route instability.

• Describe the effect of damping on BGP routing.

• Explain the default behavior of damping on links.

• Describe the operation of BGP route reflection.

• Configure a route reflector.

www.juniper.net Course Overview • v

• Describe the operation of a BGP confederation.

• Configure confederations.

• Describe peering relationships in a confederation.

• Control damping using routing policy.

• View damped routes using command-line interface (CLI) commands.

Intended Audience

This course benefits individuals responsible for implementing, monitoring, and troubleshooting Layer 3 components of a service provider’s network.

Course Level

Advanced Junos Service Provider Routing is an advanced-level course.

Prerequisites

Students should have intermediate-level networking knowledge and an understanding of the Open Systems Interconnection (OSI) model and the TCP/IP protocol suite. Students should also attend the Introduction to the Junos Operating System (IJOS), Junos Routing Essentials (JRE), and Junos Intermediate Routing (JIR) courses prior to attending this class.

vi • Course Overview www.juniper.net

Course Agenda

Day 1

Chapter 1: Course Introduction

Chapter 2: OSPF

Lab 1: OSPF Multiarea Networks

Chapter 3: OSPF Areas

Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization

Chapter 4: OSPF Case Studies and Solutions

Lab 3: Advanced OSPF Options and Policy

Day 2

Chapter 5: IS-IS

Lab 4: IS-IS Configuration and Monitoring

Chapter 6: Advanced IS-IS Operations and Configuration Options

Lab 5: Advanced IS-IS Configuration Options and Routing Policy

Chapter 7: Multilevel IS-IS Networks

Lab 6: Configuring a Multilevel IS-IS Network

Day 3

Chapter 8: BGP

Lab 7: BGP

Chapter 9: BGP Attributes and Policy—Part 1

Lab 8: BGP Attributes: Next-Hop, Origin, MED, and AS Path

Day 4

Chapter 10: BGP Attributes and Policy—Part 2

Lab 9: BGP Attributes: Local Preference and Communities

Chapter 11: Route Reflection and Confederations

Lab 10: Scaling BGP (Detailed)

Chapter 12: BGP Route Damping

Lab 11: BGP Route Damping (Detailed)

www.juniper.net Course Agenda • vii

Document Conventions

CLI and GUI Text

Frequently throughout this course, we refer to text that appears in a command-line interface (CLI) or a graphical user interface (GUI). To make the language of these documents easier to read, we distinguish GUI and CLI text from chapter text according to the following table.

Input Text Versus Output Text

You will also frequently see cases where you must enter input text yourself. Often these instances will be shown in the context of where you must enter them. We use bold style to distinguish text that is input versus text that is simply displayed.

Defined and Undefined Syntax Variables

Finally, this course distinguishes between regular text and syntax variables, and it also distinguishes between syntax variables where the value is already assigned (defined variables) and syntax variables where you must assign the value (undefined variables). Note that these styles can be combined with the input style as well.

Style Description Usage Example

Franklin Gothic Normal text. Most of what you read in the Lab Guide and Student Guide.

Courier New Console text:

• Screen captures

• Noncommand-related syntax

GUI text elements:

• Menu names

• Text field entry

commit complete

Exiting configuration mode

Select File > Open, and then click Configuration.conf in the Filename text box.


Normal CLI

Normal GUI

No distinguishing variant. Physical interface:fxp0, Enabled

View configuration history by clicking Configuration > History.

CLI Input

GUI Input

Text that you must enter. lab@San_Jose> show route

Select File > Save, and type config.ini in the Filename field.


CLI Variable

GUI Variable

Text where variable value is already assigned.

policy my-peers

Click my-peers in the dialog.

CLI Undefined

GUI Undefined

Text where the variable’s value is the user’s discretion or text where the variable’s value as shown in the lab guide might differ from the value the user must input according to the lab topology.

Type set policy policy-name.

ping 10.0.x.y

Select File > Save, and type filename in the Filename field.

viii • Document Conventions www.juniper.net

Additional Information

Education Services Offerings

You can obtain information on the latest Education Services offerings, course dates, and class locations from the World Wide Web by pointing your Web browser to: http://www.juniper.net/training/education/.

About This Publication

The Advanced Junos Service Provider Routing Detailed Lab Guide was developed and tested using software Release 11.4R1.14. Previous and later versions of software might behave differently so you should always consult the documentation and release notes for the version of code you are running before reporting errors.

This document is written and maintained by the Juniper Networks Education Services development team. Please send questions and suggestions for improvement to [email protected].

Technical Publications

You can print technical manuals and release notes directly from the Internet in a variety of formats:

• Go to http://www.juniper.net/techpubs/.

• Locate the specific software or hardware release and title you need, and choose the format in which you want to view or print the document.

Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.

Juniper Networks Support

For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).

www.juniper.net Additional Information • ix

x • Additional Information www.juniper.net

Lab 1OSPF Multiarea Networks (Detailed)

Overview

In this lab, you will use the lab diagram titled “Lab 1: OSPF Multiarea Networks” to establish a multiarea OSPF routing domain. You will explore the operation of the network focusing on show commands and the link-state database (LSDB). You will then explore configuration options, such as reference bandwidth, overload, and authentication.

The lab is available in two formats: a high-level format designed to make you think through each step and a detailed format that offers step-by-step instructions complete with sample output from most commands.

By completing this lab, you will perform the following tasks:

• Verify the router’s existing configuration.

• Verify the router’s interface status.

• Build a multiarea OSPF network.

• Change OSPF costs on links.

• Configure a router for overload.

• Perform authentication on OSPF packets.

www.juniper.net OSPF Multiarea Networks (Detailed) • Lab 1–111.a.11.4R1.14

Advanced Junos Service Provider Routing

Part 1: Load Reset Configuration

In this lab part, you verify the initial configuration of the routers. You then verify that the interfaces are operational. After verifying the interfaces, you attempt to telnet to your neighboring routers.

Step 1.1

Ensure that you know to which student device you have been assigned. Check with your instructor if you are not certain. Consult the management network diagram to determine the management address of your student device.

Step 1.2

Access the CLI on your student device using either the console, Telnet, or SSH as directed by your instructor. Refer to the management network diagram for the IP address associated with your student device. The following example demonstrates a simple Telnet session with the Secure CRT program as a basis:

Note

The instructor will tell you the nature of your access and will provide you with the necessary details to access your assigned device.

Note

The lab topology requires you to display information in the different virtual routing instances. When referencing the routing instance, the commands include the routing instance name, R3-Y, where Y is the user number (1 or 2). Refer to the lab diagram for the correct instance and user number.

When performing network commands such as ping or traceroute within the routing instance, the routing-instance R3-Y switch must be used to consult the appropriate virtual instance. When performing show commands, the instance R3-Y or table R3-Y switch must be used to display the appropriate adjacencies or routing tables.

Lab 1–2 • OSPF Multiarea Networks (Detailed) www.juniper.net


Step 1.3

Log in to the router with the username lab using a password of lab123. Note that both the name and password are case-sensitive.

mxA-1 (ttyu0)

login: labPassword:

--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTClab@mxA-1>

Step 1.4

Enter configuration mode and load the device’s reset configuration by issuing the load override ajspr/reset.config command. After the configuration has been loaded, commit the changes and exit to operational mode.

lab@mxA-1> configure Entering configuration mode

[edit]lab@mxA-1# load override ajspr/reset.config load complete

[edit]lab@mxA-1# commit and-quitcommit completeExiting configuration mode

lab@mxA-1>

Step 1.5

Issue the show configuration command. Use the lab diagram to verify that your router has the correct interface configuration with the appropriate VLANs. Verify that there are four 20.20/24 static routes, a routing-instance, and a policy statement. Notify your instructor of any problems with your device configuration.

lab@mxA-1> show configuration ## Last commit: 2011-12-28 18:31:22 UTC by labversion 11.4R1.14;system {

www.juniper.net OSPF Multiarea Networks (Detailed) • Lab 1–3


host-name mxA-1; root-authentication { encrypted-password "$1$KI99zGk6$MbYFuBbpLffu9tn2.sI7l1"; ## SECRET-DATA ssh-dsa "ssh-dss

AAAAB3NzaC1kc3MAAACBAMQrfP2bZyBXJ6PC7XXZ+MzErI8Jl6jah5L4/O8BsfP2hC7EvRfNoX7MqbrtCX/9gUH9gChVuBCB+ERULMdgRvM5uGhC/gs4UX+4dBbfBgKYYwgmisM8EoT25m7qI8ybpl2YZvHNznvO8h7kr4kpYuQEpKvgsTdH/Jle4Uqnjv7DAAAAFQDZaqA6QAgbW3O/zveaLCIDj6p0dwAAAIB1iL+krWrXiD8NPpY+w4dWXEqaV3bnobzPC4eyxQKBUCOr80Q5YBlWXVBHx9elwBWZwj0SF4hLKHznExnLerVsMuTMA846RbQmSz62vM6kGM13HFonWeQvWia0TDr78+rOEgWF2KHBSIxL51lmIDW8Gql9hJfD/Dr/NKP97w3L0wAAAIEAr3FkWU8XbYytQYEKxsIN9P1UQ1ERXB3G40YwqFO484SlyKyYCfaz+yNsaAJu2C8UebDIR3GieyNcOAKf3inCG8jQwjLvZskuZwrvlsz/xtcxSoAh9axJcdUfSJYMW/g+mD26JK1Cliw5rwp2nH9kUrJxeI7IReDp4egNkM4i15o= [email protected]"; ## SECRET-DATA

} login { user lab { uid 2000; class super-user; authentication { encrypted-password "$1$84J5Maes$cni5Hrazbd/IEHr/50oY30"; ##

SECRET-DATA } } } services { ftp; ssh; telnet; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}interfaces { ge-1/0/0 { vlan-tagging; unit 1111 { vlan-id 1111; family inet { address 172.22.121.1/24; } } } ge-1/0/4 {



unit 0 { family inet { address 10.0.1.1/24; } } } ge-1/1/4 { unit 0 { family inet { address 10.0.1.2/24; } } } fxp0 { description "MGMT INTERFACE - DO NOT DELETE"; unit 0 { family inet { address 10.210.15.1/27; } } } lo0 { unit 0 { family inet { address 172.16.1.1/32; } } unit 1 { family inet { address 172.16.1.2/32; } } }}routing-options { static { route 20.20.0.0/24 reject; route 20.20.1.0/24 reject; route 20.20.2.0/24 reject; route 20.20.3.0/24 reject; } autonomous-system 65512;}policy-options { policy-statement static-to-ospf { term 1 { from protocol static; then accept; } }}routing-instances { R3-1 { instance-type virtual-router; interface ge-1/1/4.0;



interface lo0.1; routing-options { autonomous-system 65512; } }}

lab@mxA-1>

Step 1.6

Variable references are used throughout this lab to distinguish various parts of CLI input.

1. Variable R will be 1 or 2 but will indicate a value from your remote team’s devices. Just remember “R for Remote.”

2. Variable V indicates the last number of the VLAN value on the links connecting to the P1, P2 and P3 routers. On the mxX-1 side, the value will be 1, 3 or 5. On the mxX-2 device, the value will be 2, 4 or 6. Just remember “V for VLAN.”

3. Variable X indicates the pod letter: A, B, C or D.

4. Variable Y will be a 1 or 2 depending on which student device you have been assigned within your pod. Just remember “Y for Yours.”

5. Variable Z will be either 1, 2, 3 or 4 depending upon which pod you have been assigned (A = 1, B = 2, C = 3 & D = 4).

Use the ping 172.22.12V.2 count 5 and ping 10.0.Y.2 count 5 commands to verify that you can ping the physical interfaces on each neighboring router.

lab@mxA-1> ping 172.22.12V.2 count 5 PING 172.22.121.2 (172.22.121.2): 56 data bytes64 bytes from 172.22.121.2: icmp_seq=0 ttl=64 time=0.598 ms64 bytes from 172.22.121.2: icmp_seq=1 ttl=64 time=0.527 ms64 bytes from 172.22.121.2: icmp_seq=2 ttl=64 time=0.528 ms64 bytes from 172.22.121.2: icmp_seq=3 ttl=64 time=0.512 ms64 bytes from 172.22.121.2: icmp_seq=4 ttl=64 time=0.519 ms

--- 172.22.121.2 ping statistics ---5 packets transmitted, 5 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.512/0.537/0.598/0.031 ms

lab@mxA-1> ping 10.0.Y.2 count 5 PING 10.0.1.2 (10.0.1.2): 56 data bytes64 bytes from 10.0.1.2: icmp_seq=0 ttl=64 time=0.538 ms64 bytes from 10.0.1.2: icmp_seq=1 ttl=64 time=0.389 ms64 bytes from 10.0.1.2: icmp_seq=2 ttl=64 time=0.475 ms64 bytes from 10.0.1.2: icmp_seq=3 ttl=64 time=0.398 ms64 bytes from 10.0.1.2: icmp_seq=4 ttl=64 time=0.467 ms




lab@mxA-1>

Question: Were the pings successful?

Answer: The pings should be successful. If not, verify that the interfaces have the correct IP addresses and are “up” and “up”.

Step 1.7

Try to telnet between the student device and the routing-instance router using the telnet 10.0.Y.2 command. The username is lab and the password is lab123. Once you have verified a successful telnet connection, log out using the exit command.

lab@mxA-1> telnet 10.0.Y.2 Trying 10.0.1.2...Connected to 10.0.1.2.Escape character is '^]'.

mxA-1 (ttyp0)

login: labPassword:

--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTClab@mxA-1> exit

Connection closed by foreign host.

Question: Were you successful?

Answer: The Telnet should be successful. If not, please notify your instructor.

Step 1.8

To aid in completing the labs in a timely manner, some routing information has been preconfigured on your router. Issue the show route protocol static table inet.0 command to ensure that the correct routing information is present.

lab@mxA-1> show route protocol static table inet.0

inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

20.20.0.0/24 *[Static/5] 03:17:03



Reject20.20.1.0/24 *[Static/5] 03:17:03 Reject20.20.2.0/24 *[Static/5] 03:17:03 Reject20.20.3.0/24 *[Static/5] 03:17:03 Reject

lab@mxA-1>

Question: How many static route entries are in your routing table?

Answer: There should be four static route entries. Please notify the instructor if your router does not currently have this configuration.

Part 2: Creating the Network

In this part of the lab, you configure and monitor a multiarea OSPF network. First, you configure the interfaces participating in OSPF for your assigned device. You then configure your device to participate in a multiarea OSPF network and verify operations using command-line interface (CLI) operational mode commands.

Step 2.1

Refer to the network diagram in your lab topology handout. Write down the interfaces that will run OSPF and to which area each is attached.

Interfaces and OSPF areas:

Question: Which routers are area border routers (ABRs)?

Answer: The student device default routing instances are the ABRs.

Question: Which routers are backbone routers?

Answer: The vr-device is a backbone router.



Question: Which routers are internal routers?

Answer: The R3-Y routing instances on the student devices are internal routers.

Step 2.2

Enter configuration mode and navigate to the [edit protocols ospf] hierarchy. Configure your routers’ interfaces and unit numbers to be in the correct OSPF area. Do not forget the loopback interfaces. Commit your configuration when completed.

lab@mxA-1> configureEntering configuration mode

[edit]lab@mxA-1# edit protocols ospf

[edit protocols ospf]lab@mxA-1# set area 0 interface lo0.0

[edit protocols ospf]lab@mxA-1# set area 0 interface ge-1/0/0.11ZV

[edit protocols ospf]lab@mxA-1# set area Y0 interface ge-1/0/4.0

[edit protocols ospf]lab@mxA-1# top edit routing-instances R3-Y protocols ospf

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# set area Y0 interface ge-1/1/4.0

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# set area Y0 interface lo0.1

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# commit commit complete

[edit routing-instances R3-1 protocols ospf]lab@mxA-1#



Step 2.3

Verify the OSPF adjacencies by issuing the run show ospf neighbor command.

[edit routing-instances R3-1 protocols ospf]lab@mxA-1> run show ospf neighbor Address Interface State ID Pri Dead172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 3610.0.1.2 ge-1/0/4.0 Full 172.16.1.2 128 36

Question: Does the neighbor adjacency state show Full for both OSPF neighbors?

Answer: Yes, the adjacency state should show Full for both OSPF neighbors.

Step 2.4

Issue the run show route command to look at the routing table of the student device.

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# run show route


10.0.1.0/24 *[Direct/0] 00:05:02 > via ge-1/0/4.010.0.1.1/32 *[Local/0] 00:05:02 Local via ge-1/0/4.010.0.2.0/24 *[OSPF/10] 00:02:18, metric 3 > to 172.22.121.2 via ge-1/0/0.111110.210.15.0/27 *[Direct/0] 00:36:15 > via fxp0.010.210.15.1/32 *[Local/0] 00:36:15 Local via fxp0.020.20.0.0/24 *[Static/5] 00:05:02

Note

Remember that the logical interface—and not the physical interface—will be running the protocol. All interfaces will appear in the configuration with a logical unit attached. If the logical unit is omitted when entering the command, such as interface ge-1/0/0, then a logical unit number of 0 will be automatically attached, and the configuration will contain interface ge-1/0/0.0. This attachment might be an issue on a multi-unit interface.



Reject20.20.1.0/24 *[Static/5] 00:05:02 Reject20.20.2.0/24 *[Static/5] 00:05:02 Reject20.20.3.0/24 *[Static/5] 00:05:02 Reject172.16.1.1/32 *[Direct/0] 00:36:15 > via lo0.0172.16.1.2/32 *[OSPF/10] 00:00:32, metric 1 > to 10.0.1.2 via ge-1/0/4.0172.16.2.1/32 *[OSPF/10] 00:02:18, metric 2 > to 172.22.121.2 via ge-1/0/0.1111172.16.2.2/32 *[OSPF/10] 00:00:23, metric 3 > to 172.22.121.2 via ge-1/0/0.1111172.22.121.0/24 *[Direct/0] 00:36:15 > via ge-1/0/0.1111172.22.121.1/32 *[Local/0] 00:36:15 Local via ge-1/0/0.1111172.22.122.0/24 *[OSPF/10] 00:02:57, metric 2 > to 172.22.121.2 via ge-1/0/0.1111172.31.100.1/32 *[OSPF/10] 00:02:57, metric 1 > to 172.22.121.2 via ge-1/0/0.1111224.0.0.5/32 *[OSPF/10] 00:03:12, metric 1 MultiRecv

R3-1.inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

10.0.1.0/24 *[Direct/0] 00:05:02 > via ge-1/1/4.010.0.1.2/32 *[Local/0] 00:05:02 Local via ge-1/1/4.010.0.2.0/24 *[OSPF/10] 00:00:33, metric 4 > to 10.0.1.1 via ge-1/1/4.0172.16.1.1/32 *[OSPF/10] 00:00:33, metric 1 > to 10.0.1.1 via ge-1/1/4.0172.16.1.2/32 *[Direct/0] 00:36:15 > via lo0.1172.16.2.1/32 *[OSPF/10] 00:00:33, metric 3 > to 10.0.1.1 via ge-1/1/4.0172.16.2.2/32 *[OSPF/10] 00:00:21, metric 4 > to 10.0.1.1 via ge-1/1/4.0172.22.121.0/24 *[OSPF/10] 00:00:33, metric 2 > to 10.0.1.1 via ge-1/1/4.0172.22.122.0/24 *[OSPF/10] 00:00:33, metric 3 > to 10.0.1.1 via ge-1/1/4.0172.31.100.1/32 *[OSPF/10] 00:00:33, metric 2 > to 10.0.1.1 via ge-1/1/4.0224.0.0.5/32 *[OSPF/10] 00:03:12, metric 1 MultiRecv




Question: Do all routes show as active? Why or why not?

Answer: Yes. Each route should be preceded by the asterisk (*), indicating that the route is active.

Step 2.5

Navigate to the [edit protocols ospf] hierarchy on the student device. A policy statement labeled static-to-ospf was defined in the configuration file. Apply the policy as an export policy to export the static routes into OSPF and commit your configuration.

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# top edit protocols ospf

[edit protocols ospf]lab@mxA-1# set export static-to-ospf

[edit protocols ospf]lab@mxA-1# commitcommit complete

[edit protocols ospf]lab@mxA-1#

Step 2.6

Use the run show ospf database command to examine the link-state database (LSDB) on the student device, which is the ABR and an ASBR. Notice that the output is organized by areas, Area 0.0.0.0 first and then the nonbackbone areas in numerical order, followed by the external routes (Type 5 exported static routes) labeled as the “OSPF AS SCOPE link state database”.

Notice the Router LSAs (Type 1) are the loopback interfaces. Network LSAs (Type 2) are the Gigabit Ethernet links. The Summary LSAs (Type 3) are Router LSAs or Network LSAs converted by the ABR and injected into the other area. The ASBRSum LSA (Type 4) are listed in the non-backbone area. You might see one or two ASBRSum entries depending on whether the other team has applied their policy.

[edit protocols ospf]lab@mxA-1# run show ospf database

OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router *172.16.1.1 172.16.1.1 0x80000056 12 0x22 0x2de5 48Router 172.16.2.1 172.16.2.1 0x80000055 8 0x22 0x48c6 48Router 172.31.100.1 172.31.100.1 0x80000048 230 0x22 0xe851 60Network 172.22.121.2 172.31.100.1 0x80000001 269 0x22 0x409a 32Network 172.22.122.2 172.31.100.1 0x80000001 230 0x22 0x4296 32Summary *10.0.1.0 172.16.1.1 0x80000003 108 0x22 0x620e 28Summary 10.0.2.0 172.16.2.1 0x80000003 103 0x22 0x501e 28Summary *172.16.1.2 172.16.1.1 0x80000001 108 0x22 0x4f6e 28Summary 172.16.2.2 172.16.2.1 0x80000001 103 0x22 0x3d7e 28



OSPF database, Area 0.0.0.10 Type ID Adv Rtr Seq Age Opt Cksum Len Router *172.16.1.1 172.16.1.1 0x80000003 12 0x22 0xa3f3 36Router 172.16.1.2 172.16.1.2 0x80000005 13 0x22 0x576e 48Network 10.0.1.2 172.16.1.2 0x80000001 116 0x22 0xf5f8 32Summary *10.0.2.0 172.16.1.1 0x80000001 119 0x22 0x6fff 28Summary *172.16.1.1 172.16.1.1 0x80000001 119 0x22 0x4f70 28Summary *172.16.2.1 172.16.1.1 0x80000001 119 0x22 0x5864 28Summary *172.16.2.2 172.16.1.1 0x80000001 99 0x22 0x5862 28Summary *172.22.121.0 172.16.1.1 0x80000001 119 0x22 0xed53 28Summary *172.22.122.0 172.16.1.1 0x80000001 119 0x22 0xec52 28Summary *172.31.100.1 172.16.1.1 0x80000001 119 0x22 0x5fec 28ASBRSum *172.16.2.1 172.16.1.1 0x80000001 4 0x22 0x4a71 28ASBRSum *172.31.100.1 172.16.1.1 0x80000001 119 0x22 0x51f9 28 OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern *20.20.0.0 172.16.1.1 0x80000001 12 0x22 0x6b60 36Extern *20.20.1.0 172.16.1.1 0x80000001 12 0x22 0x606a 36Extern *20.20.2.0 172.16.1.1 0x80000001 12 0x22 0x5574 36Extern *20.20.3.0 172.16.1.1 0x80000001 12 0x22 0x4a7e 36Extern 20.20.4.0 172.16.2.1 0x80000001 8 0x22 0x388e 36Extern 20.20.5.0 172.16.2.1 0x80000001 8 0x22 0x2d98 36Extern 20.20.6.0 172.16.2.1 0x80000001 8 0x22 0x22a2 36Extern 20.20.7.0 172.16.2.1 0x80000001 8 0x22 0x17ac 36


Question: How many and what types of link-state advertisements (LSAs) exist in OSPF database for Area 0?

Answer: You should see three Router, two Network and four Summary LSAs for Area 0.

STOP Tell your instructor that you have completed this section. Please do not

rush ahead because you will impact the lab results of other students.

Please use any available time to practice show commands, but do not make any configuration changes.

Part 3: Configuring the OSPF LInk Costs

In this lab part, you configure the OSPF link costs.

Step 3.1

Issue the run show ospf interface detail command and answer the following question.



[edit protocols ospf]lab@mxA-1# run show ospf interface detail Interface State Area DR ID BDR ID Nbrsge-1/0/0.1111 BDR 0.0.0.0 172.31.100.1 172.16.1.1 1 Type: LAN, Address: 172.22.121.1, Mask: 255.255.255.0, MTU: 1500, Cost: 1 DR addr: 172.22.121.2, BDR addr: 172.22.121.1, Priority: 128 Adj count: 1 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None Protection type: None Topology default (ID 0) -> Cost: 0lo0.0 DR 0.0.0.0 172.16.1.1 0.0.0.0 0 Type: LAN, Address: 172.16.1.1, Mask: 255.255.255.255, MTU: 65535, Cost: 0 DR addr: 172.16.1.1, Priority: 128 Adj count: 0 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None Protection type: None Topology default (ID 0) -> Cost: 0ge-1/0/4.0 BDR 0.0.0.10 172.16.1.2 172.16.1.1 1 Type: LAN, Address: 10.0.1.1, Mask: 255.255.255.0, MTU: 1500, Cost: 1 DR addr: 10.0.1.2, BDR addr: 10.0.1.1, Priority: 128 Adj count: 1 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None Protection type: None Topology default (ID 0) -> Cost: 0


Question: What is the current cost for the Gigabit Ethernet links and why?

Answer: All of the Gigabit Ethernet links should have the same cost of 1, because at the default reference-bandwidth setting of 100 Mbps, the calculation of a Gigabit Ethernet link is actually lower than one and must be rounded up to the nearest integer according to the RFC.

Step 3.2

At this point, we will better represent the link bandwidths in the network. Using the reference-bandwidth command, alter the metric calculation such that the bandwidth of a 10-Gigabit Ethernet link becomes the basis for the formula. Commit your configuration when completed.

[edit protocols ospf]lab@mxA-1# set reference-bandwidth 10g

[edit protocols ospf]lab@mxA-1# commit



commit complete


Step 3.3

Issue the run show ospf interface detail command to see if the link costs changed.

[edit protocols ospf]lab@mxA-1# run show ospf interface detail Interface State Area DR ID BDR ID Nbrsge-1/0/0.1111 BDR 0.0.0.0 172.31.100.1 172.16.1.1 1 Type: LAN, Address: 172.22.121.1, Mask: 255.255.255.0, MTU: 1500, Cost: 10 DR addr: 172.22.121.2, BDR addr: 172.22.121.1, Priority: 128 Adj count: 1 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None Protection type: None Topology default (ID 0) -> Cost: 0lo0.0 DR 0.0.0.0 172.16.1.1 0.0.0.0 0 Type: LAN, Address: 172.16.1.1, Mask: 255.255.255.255, MTU: 65535, Cost: 0 DR addr: 172.16.1.1, Priority: 128 Adj count: 0 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None Protection type: None Topology default (ID 0) -> Cost: 0ge-1/0/4.0 BDR 0.0.0.10 172.16.1.2 172.16.1.1 1 Type: LAN, Address: 10.0.1.1, Mask: 255.255.255.0, MTU: 1500, Cost: 10 DR addr: 10.0.1.2, BDR addr: 10.0.1.1, Priority: 128 Adj count: 1 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None Protection type: None Topology default (ID 0) -> Cost: 0

Question: Did the cost of the links in the network change? If so, what are some of the new costs?

Answer: If you used a reference bandwidth value of 10 Gbps or higher, the Gigabit Ethernet link costs should have changed. If you used a reference bandwidth value of 10 Gbps, the Gigabit Ethernet link costs should be 10.

Step 3.4

Change the metric on your Area 0 loopback interface to be 10000 and commit your configuration.



[edit protocols ospf]lab@mxA-1# set area 0 interface lo0.0 metric 10000

[edit protocols ospf]lab@mxA-1# commit commit complete


Step 3.5

Enter the run show route 172.16/16 command and examine the routing table on your student device at this point.

[edit protocols ospf]lab@mxA-1# run show route 172.16/16


172.16.1.1/32 *[Direct/0] 00:40:25 > via lo0.0172.16.1.2/32 *[OSPF/10] 00:01:10, metric 10 > to 10.0.1.2 via ge-1/0/4.0172.16.2.1/32 *[OSPF/10] 00:00:02, metric 10011 > to 172.22.121.2 via ge-1/0/0.1111172.16.2.2/32 *[OSPF/10] 00:01:01, metric 21 > to 172.22.121.2 via ge-1/0/0.1111


172.16.1.1/32 *[OSPF/10] 00:00:15, metric 10001 > to 10.0.1.1 via ge-1/1/4.0172.16.1.2/32 *[Direct/0] 00:40:25 > via lo0.1172.16.2.1/32 *[OSPF/10] 00:00:02, metric 10012 > to 10.0.1.1 via ge-1/1/4.0172.16.2.2/32 *[OSPF/10] 00:01:01, metric 22 > to 10.0.1.1 via ge-1/1/4.0


Question: Did any of the metric costs increase as a result of this configuration change? If so, which routes changed metric values?

Answer: Yes. The metric cost changed for routes to OSPF neighbor’s loopback addresses.



Step 3.6

Alter the metrics in OSPF Area Y0. The student device router should use a metric of 5000, and the routing-instance router should use a metric of 2500. Commit your configuration when completed.

[edit protocols ospf]lab@mxA-1# set area Y0 interface ge-1/0/4.0 metric 5000

[edit protocols ospf]lab@mxA-1# top edit routing-instances R3-Y protocols ospf area Y0

[edit routing-instances R3-1 protocols ospf area 0.0.0.10]lab@mxA-1# set interface ge-1/1/4.0 metric 2500

[edit routing-instances R3-1 protocols ospf area 0.0.0.10]lab@mxA-1# commitcommit complete

[edit routing-instances R3-1 protocols ospf area 0.0.0.10]lab@mxA-1#

Step 3.7

Examine the routing tables for each router. Specifically, use the run show route 172.16/16 command to look at the cost to reach the loopback address of the router on the other end of the link.

[edit routing-instances R3-1 protocols ospf area 0.0.0.10]lab@mxA-1# run show route 172.16/16




172.16.1.1/32 *[OSPF/10] 00:01:14, metric 12500 > to 10.0.1.1 via ge-1/1/4.0

Note

If no metric values have changed on your router, then STOP until some networks have changed. If, however, some networks in your routing table do have increased metrics, then proceed to the next step.



172.16.1.2/32 *[Direct/0] 00:43:16 > via lo0.1172.16.2.1/32 *[OSPF/10] 00:01:14, metric 12511 > to 10.0.1.1 via ge-1/1/4.0172.16.2.2/32 *[OSPF/10] 00:00:43, metric 7511 > to 10.0.1.1 via ge-1/1/4.0


Question: Did the two routers agree to use a metric of 2500 or 5000? If not, is this a problem?

Answer: No, the routers did not agree on a single metric but this is not a problem because metrics are allowed to be different on each side of a link.

Part 4: Configuring Overload

In this lab part, you configure the routing-instance router to be in overload mode.

Step 4.1

Enter the run show route table R3-Y.inet.0 to examine the routing table for the routing-instance on your student device and look at the metric for the transit links. You should also see the 20.20/16 static routes.

[edit routing-instances R3-1 protocols ospf area 0.0.0.10]lab@mxA-1# run show route table R3-Y.inet.0


10.0.1.0/24 *[Direct/0] 00:13:10 > via ge-1/1/4.010.0.1.2/32 *[Local/0] 00:13:10 Local via ge-1/1/4.010.0.2.0/24 *[OSPF/10] 00:01:50, metric 7511 > to 10.0.1.1 via ge-1/1/4.020.20.0.0/24 *[OSPF/150] 00:06:59, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.020.20.1.0/24 *[OSPF/150] 00:06:59, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.020.20.2.0/24 *[OSPF/150] 00:06:59, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.020.20.3.0/24 *[OSPF/150] 00:06:59, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.020.20.4.0/24 *[OSPF/150] 00:06:54, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.020.20.5.0/24 *[OSPF/150] 00:06:54, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.020.20.6.0/24 *[OSPF/150] 00:06:54, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.0



20.20.7.0/24 *[OSPF/150] 00:06:54, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.0172.16.1.1/32 *[OSPF/10] 00:02:21, metric 12500 > to 10.0.1.1 via ge-1/1/4.0172.16.1.2/32 *[Direct/0] 00:44:23 > via lo0.1172.16.2.1/32 *[OSPF/10] 00:02:21, metric 12511 > to 10.0.1.1 via ge-1/1/4.0172.16.2.2/32 *[OSPF/10] 00:01:50, metric 7511 > to 10.0.1.1 via ge-1/1/4.0172.22.121.0/24 *[OSPF/10] 00:02:21, metric 2510 > to 10.0.1.1 via ge-1/1/4.0172.22.122.0/24 *[OSPF/10] 00:02:21, metric 2511 > to 10.0.1.1 via ge-1/1/4.0172.31.100.1/32 *[OSPF/10] 00:02:21, metric 2510 > to 10.0.1.1 via ge-1/1/4.0224.0.0.5/32 *[OSPF/10] 00:11:20, metric 1 MultiRecv


Step 4.2

Navigate to the [edit routing-instance R3-Y protocols ospf] hierarchy. Configure the routing-instance router to be in overload mode and commit your configuration when completed.

[edit routing-instances R3-1 protocols ospf area 0.0.0.10]lab@mxA-1# up

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# set overload

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# commit commit complete


Step 4.3

Enter the run show route table R3-Y.inet.0 command to examine the routing-instance route table again.

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# run show route table R3-Y.inet.0


10.0.1.0/24 *[Direct/0] 00:14:46 > via ge-1/1/4.010.0.1.2/32 *[Local/0] 00:14:46 Local via ge-1/1/4.010.0.2.0/24 *[OSPF/10] 00:00:20, metric 70546



> to 10.0.1.1 via ge-1/1/4.020.20.0.0/24 *[OSPF/150] 00:08:35, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.020.20.1.0/24 *[OSPF/150] 00:08:35, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.020.20.2.0/24 *[OSPF/150] 00:08:35, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.020.20.3.0/24 *[OSPF/150] 00:08:35, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.020.20.4.0/24 *[OSPF/150] 00:08:30, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.020.20.5.0/24 *[OSPF/150] 00:08:30, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.020.20.6.0/24 *[OSPF/150] 00:08:30, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.020.20.7.0/24 *[OSPF/150] 00:08:30, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.0172.16.1.1/32 *[OSPF/10] 00:00:20, metric 75535 > to 10.0.1.1 via ge-1/1/4.0172.16.1.2/32 *[Direct/0] 00:45:59 > via lo0.1172.16.2.1/32 *[OSPF/10] 00:00:20, metric 75546 > to 10.0.1.1 via ge-1/1/4.0172.16.2.2/32 *[OSPF/10] 00:00:20, metric 70546 > to 10.0.1.1 via ge-1/1/4.0172.22.121.0/24 *[OSPF/10] 00:00:20, metric 65545 > to 10.0.1.1 via ge-1/1/4.0172.22.122.0/24 *[OSPF/10] 00:00:20, metric 65546 > to 10.0.1.1 via ge-1/1/4.0172.31.100.1/32 *[OSPF/10] 00:00:20, metric 65545 > to 10.0.1.1 via ge-1/1/4.0224.0.0.5/32 *[OSPF/10] 00:12:56, metric 1 MultiRecv


Question: Did the metrics change?

Answer: Yes. The metric should be greater than 65535.

Question: Are all OSPF neighbors still fully adjacent?

Question: Yes. Configuring a router as overloaded does not flap the adjacencies.



Part 5: Performing Authentication

In this lab part, you perform authentication for the OSPF area between the student device and routing-instance router.

Step 5.1

Navigate to the [edit protocols ospf area Y0] hierarchy. First, issue a run clear ospf statistics command. Then, configure your student device router to support an authentication key of juniper using the Message Digest 5 (MD5) algorithm. Use a key-id of 10 and commit your configuration when completed.

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# top edit protocols ospf area Y0

[edit protocols ospf area 0.0.0.10]lab@mxA-1# run clear ospf statistics

[edit protocols ospf area 0.0.0.10]lab@mxA-1# set interface ge-1/0/4.0 authentication md5 10 key juniper

[edit protocols ospf area 0.0.0.10]lab@mxA-1# commitcommit complete

[edit protocols ospf area 0.0.0.10]lab@mxA-1#

Step 5.2

Use the run show ospf neighbor command a few times to verify that the OSPF neighbor state is no longer full. Note that, because of the dead timer, it might take up to forty seconds for the neighbor to disappear from the output.

[edit protocols ospf area 0.0.0.10]lab@mxA-1# run show ospf neighbor Address Interface State ID Pri Dead172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 3710.0.1.2 ge-1/0/4.0 Full 172.16.1.2 128 11

[edit protocols ospf area 0.0.0.10]lab@mxA-1# run show ospf neighbor Address Interface State ID Pri Dead172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 36

Step 5.3

Issue the run show ospf statistics command. Notice the Receive errors counter. The authentication mismatch shows up as area mismatches.

[edit protocols ospf area 0.0.0.10]lab@mxA-1# run show ospf statistics

Packet type Total Last 5 seconds Sent Received Sent Received Hello 4 2 0 0 DbD 0 0 0 0 LSReq 0 0 0 0



LSUpdate 0 0 0 0 LSAck 0 0 0 0

DBDs retransmitted : 0, last 5 seconds : 0LSAs flooded : 0, last 5 seconds : 0LSAs flooded high-prio : 0, last 5 seconds : 0LSAs retransmitted : 0, last 5 seconds : 0LSAs transmitted to nbr: 0, last 5 seconds : 0LSAs requested : 0, last 5 seconds : 0LSAs acknowledged : 0, last 5 seconds : 0

Flood queue depth : 0Total rexmit entries : 0db summaries : 0lsreq entries : 0

Receive errors: 2 area mismatches

[edit protocols ospf area 0.0.0.10]lab@mxA-1#

Step 5.4

Navigate to the [edit routing-instances R3-Y protocols ospf area Y0] hierarchy. Configure your routing instance router to support an authentication key of juniper using the Message Digest 5 (MD5) algorithm. Use a key-id of 10, commit your configuration and exit to operational mode when completed.

[edit protocols ospf area 0.0.0.10]lab@mxA-1# top edit routing-instances R3-Y protocols ospf area Y0

[edit routing-instances R3-1 protocols ospf area 0.0.0.10]lab@mxA-1# set interface ge-1/1/4.0 authentication md5 10 key juniper

[edit routing-instances R3-1 protocols ospf area 0.0.0.10]lab@mxA-1# commit and-quitcommit completeExiting configuration mode

lab@mxA-1>

Step 5.5

Issue the show ospf neighbor command to verify that the neighbor adjacencies have returned to the Full state.

lab@mxA-1> show ospf neighbor Address Interface State ID Pri Dead172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 3410.0.1.2 ge-1/0/4.0 Full 172.16.1.2 128 34



Question: What happens if one router enters a higher key-id value while using the same password?

Answer: The highest key value is used by default. However, the key-id values must match in order to form a Full adjacency.

Step 5.6

Log out of your assigned device using the exit command.

lab@mxA-1> exit

STOP Tell your instructor that you have completed Lab 1.




Lab 2Configuring and Monitoring OSPF Areas and Route

Summarization (Detailed)

Overview

In this lab, you will use the lab diagram titled “Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization” to establish a multiarea OSPF routing domain. You will configure and monitor OSPF areas and route summarization to convert some of the areas in the OSPF routing domain into OSPF stub areas. You will then convert them into stub no-summaries areas. Finally, you will convert the areas into OSPF NSSA areas, as well as NSSA with no summaries areas.


• Create OSPF stub areas.

• Create OSPF stub no-summaries areas.

• Create an OSPF not-so-stubby area.

• Create an OSPF not-so-stubby no-summaries area.

www.juniper.net Configuring and Monitoring OSPF Areas and Route Summarization (Detailed) • Lab 2–111.a.11.4R1.14


Part 1: Creating OSPF Stub Areas

In this lab part, you convert the each of the non-backbone areas into stub areas. You then look at the link-state database (LSDB) of the routing-instance router to verify that external routing information is no longer present.

Step 1.1


Step 1.2


Note



Lab 2–2 • Configuring and Monitoring OSPF Areas and Route Summarization (Detailed) www.juniper.net


mxA-1 (ttyu0)

login: labPassword:


Step 1.3

Enter configuration mode and load the device’s reset configuration by issuing the load override ajspr/lab2-start.config command. After the configuration has been loaded, commit the changes.


[edit]lab@mxA-1# load override ajspr/lab2-start.config load complete

[edit]lab@mxA-1# commitcommit complete

[edit]lab@mxA-1#

Step 1.4

Verify you have two OSPF adjacencies using the run show ospf neighbor command.

[edit]lab@mxA-1# run show ospf neighbor Address Interface State ID Pri Dead172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 3210.0.1.2 ge-1/0/4.0 Full 172.16.1.2 128 36

Question: Are all the OSPF neighbors fully adjacent?

Answer: Yes, both neighbors should be in the Full state.

Step 1.5

Variable references are used throughout this lab to distinguish various parts of command-line interface (CLI) input.



www.juniper.net Configuring and Monitoring OSPF Areas and Route Summarization (Detailed) • Lab 2–3


3. Variable X indicates the pod letter: A, B, C, or D.


5. Variable Z will be either 1, 2, 3, or 4 depending upon which pod you have been assigned (A = 1, B = 2, C = 3, and D = 4).

Configure the non-backbone area as a stub area for the main instance and R3-Y routing instance. Commit your configuration when completed.


[edit protocols ospf]lab@mxA-1# set area Y0 stub


[edit routing-instances R3-1 protocols ospf]lab@mxA-1# set area Y0 stub

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# commitcommit complete


Step 1.6

Issue the run show route 20.20/16 table R3-Y.inet.0 command followed by the run show route 20.20/16 table inet.0 command.

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# run show route 20.20/16 table R3-Y.inet.0

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# run show route 20.20/16 table inet.0


20.20.0.0/24 *[Static/5] 00:05:53 Reject20.20.1.0/24 *[Static/5] 00:05:53 Reject20.20.2.0/24 *[Static/5] 00:05:53 Reject20.20.3.0/24 *[Static/5] 00:05:53 Reject20.20.4.0/24 *[OSPF/150] 00:05:44, metric 0, tag 0 > to 172.22.121.2 via ge-1/0/0.111120.20.5.0/24 *[OSPF/150] 00:05:44, metric 0, tag 0 > to 172.22.121.2 via ge-1/0/0.111120.20.6.0/24 *[OSPF/150] 00:05:44, metric 0, tag 0 > to 172.22.121.2 via ge-1/0/0.1111



20.20.7.0/24 *[OSPF/150] 00:05:44, metric 0, tag 0 > to 172.22.121.2 via ge-1/0/0.1111


Question: Are the 20.20/16 customer static routes from each router visible in the network? Are they visible on the ABRs?

Answer: The customer routes should still be visible on the ABRs but they should not be visible from the R3-Y routers. The purpose of a stub area is to stop the ABRs from injecting external routing information and therefore reduce the size of the LSDB.

Step 1.7

Issue the run show route 172.16/16 command. Attempt to ping the loopback address of the other team’s routing-instance router in your pod using the run ping 172.16.R.2 count 5 command. As a reminder, the value of R will come from the remote team’s R3-R router.

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# run show route 172.16/16




172.16.1.1/32 *[OSPF/10] 00:05:01, metric 75535 > to 10.0.1.1 via ge-1/1/4.0172.16.1.2/32 *[Direct/0] 00:23:37 > via lo0.1172.16.2.1/32 *[OSPF/10] 00:05:01, metric 75546 > to 10.0.1.1 via ge-1/1/4.0172.16.2.2/32 *[OSPF/10] 00:04:49, metric 70546 > to 10.0.1.1 via ge-1/1/4.0

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# run ping 172.16.R.2 count 5 PING 172.16.2.2 (172.16.2.2): 56 data bytes



64 bytes from 172.16.2.2: icmp_seq=0 ttl=62 time=0.532 ms64 bytes from 172.16.2.2: icmp_seq=1 ttl=62 time=0.561 ms64 bytes from 172.16.2.2: icmp_seq=2 ttl=62 time=0.470 ms64 bytes from 172.16.2.2: icmp_seq=3 ttl=62 time=0.535 ms64 bytes from 172.16.2.2: icmp_seq=4 ttl=62 time=0.459 ms



Question: Are the loopback addresses visible from each router in the network? Is the ping successful?

Answer: All loopback addresses should be visible and the ping should be successful.

Step 1.8

Issue the run show ospf database command and answer the following question.

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# run show ospf database

OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router *172.16.1.1 172.16.1.1 0x80000066 387 0x22 0x1c1 48Router 172.16.2.1 172.16.2.1 0x80000066 379 0x22 0x1aa3 48Router 172.31.100.1 172.31.100.1 0x8000004e 761 0x22 0xdc57 60Network 172.22.121.2 172.31.100.1 0x80000006 929 0x22 0x369f 32Network 172.22.122.2 172.31.100.1 0x80000005 770 0x22 0x3a9a 32Summary *10.0.1.0 172.16.1.1 0x80000005 347 0x22 0x557e 28Summary 10.0.2.0 172.16.2.1 0x80000005 337 0x22 0x438e 28Summary *172.16.1.2 172.16.1.1 0x80000001 347 0x22 0x46dc 28Summary 172.16.2.2 172.16.2.1 0x80000001 337 0x22 0x34ec 28

OSPF database, Area 0.0.0.10 Type ID Adv Rtr Seq Age Opt Cksum Len Router *172.16.1.1 172.16.1.1 0x80000003 347 0x20 0x8779 36Router 172.16.1.2 172.16.1.2 0x80000003 348 0x20 0x6763 48Network 10.0.1.2 172.16.1.2 0x80000002 348 0x20 0x12dd 32Summary *10.0.2.0 172.16.1.1 0x80000001 387 0x20 0xdeee 28Summary *172.16.1.1 172.16.1.1 0x80000001 387 0x20 0x6e1c 28Summary *172.16.2.1 172.16.1.1 0x80000001 387 0x20 0xd1ac 28Summary *172.16.2.2 172.16.1.1 0x80000001 335 0x20 0xc751 28Summary *172.22.121.0 172.16.1.1 0x80000001 387 0x20 0x66d3 28Summary *172.22.122.0 172.16.1.1 0x80000001 387 0x20 0x65d2 28Summary *172.31.100.1 172.16.1.1 0x80000001 387 0x20 0xd76d 28 OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern *20.20.0.0 172.16.1.1 0x80000002 68 0x22 0x6961 36



Extern *20.20.1.0 172.16.1.1 0x80000001 517 0x22 0x606a 36Extern *20.20.2.0 172.16.1.1 0x80000001 517 0x22 0x5574 36Extern *20.20.3.0 172.16.1.1 0x80000001 517 0x22 0x4a7e 36Extern 20.20.4.0 172.16.2.1 0x80000002 68 0x22 0x368f 36Extern 20.20.5.0 172.16.2.1 0x80000001 510 0x22 0x2d98 36Extern 20.20.6.0 172.16.2.1 0x80000001 510 0x22 0x22a2 36Extern 20.20.7.0 172.16.2.1 0x80000001 510 0x22 0x17ac 36


Question: What types of LSAs are in your LSDB?

Answer: The answer varies depending on whether you are looking at the ABR or the router in the stub area. The stub area router should not have any Type 5 LSAs.

STOP Tell your instructor that you have completed this section. Please do not rush ahead

because it will impact the lab results of other students.


Part 2: Creating Stub No Summaries Areas

In this lab part, you convert the stub area to a stub no-summaries area.

Step 2.1

Convert the stub area to a stub no-summaries area with the set area Y0 stub no-summaries command. Commit your configuration when completed.


[edit protocols ospf]lab@mxA-1# set area Y0 stub no-summaries





Question: On which routers must you issue the command?

Answer: The command must be issued only on the ABRs.

Step 2.2

Issue run show ospf neighbor and run show route commands and answer the following questions.

[edit protocols ospf]lab@mxA-1# run show ospf neighbor Address Interface State ID Pri Dead172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 3510.0.1.2 ge-1/0/4.0 Full 172.16.1.2 128 39

[edit protocols ospf]lab@mxA-1# run show route


10.0.1.0/24 *[Direct/0] 00:19:21 > via ge-1/0/4.010.0.1.1/32 *[Local/0] 00:19:21 Local via ge-1/0/4.010.0.2.0/24 *[OSPF/10] 00:19:12, metric 5011 > to 172.22.121.2 via ge-1/0/0.111110.210.15.0/27 *[Direct/0] 00:35:07 > via fxp0.010.210.15.1/32 *[Local/0] 00:35:07 Local via fxp0.020.20.0.0/24 *[Static/5] 00:19:21 Reject20.20.1.0/24 *[Static/5] 00:19:21 Reject20.20.2.0/24 *[Static/5] 00:19:21 Reject20.20.3.0/24 *[Static/5] 00:19:21 Reject20.20.4.0/24 *[OSPF/150] 00:19:12, metric 0, tag 0 > to 172.22.121.2 via ge-1/0/0.111120.20.5.0/24 *[OSPF/150] 00:19:12, metric 0, tag 0 > to 172.22.121.2 via ge-1/0/0.111120.20.6.0/24 *[OSPF/150] 00:19:12, metric 0, tag 0 > to 172.22.121.2 via ge-1/0/0.111120.20.7.0/24 *[OSPF/150] 00:19:12, metric 0, tag 0 > to 172.22.121.2 via ge-1/0/0.1111172.16.1.1/32 *[Direct/0] 00:35:07 > via lo0.0172.16.1.2/32 *[OSPF/10] 00:00:48, metric 5000 > to 10.0.1.2 via ge-1/0/4.0172.16.2.1/32 *[OSPF/10] 00:19:12, metric 10011



> to 172.22.121.2 via ge-1/0/0.1111172.16.2.2/32 *[OSPF/10] 00:01:15, metric 5011 > to 172.22.121.2 via ge-1/0/0.1111172.22.121.0/24 *[Direct/0] 00:35:07 > via ge-1/0/0.1111172.22.121.1/32 *[Local/0] 00:35:07 Local via ge-1/0/0.1111172.22.122.0/24 *[OSPF/10] 00:19:21, metric 11 > to 172.22.121.2 via ge-1/0/0.1111172.31.100.1/32 *[OSPF/10] 00:19:21, metric 10 > to 172.22.121.2 via ge-1/0/0.1111224.0.0.5/32 *[OSPF/10] 00:35:07, metric 1 MultiRecv R3-1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

10.0.1.0/24 *[Direct/0] 00:19:21 > via ge-1/1/4.010.0.1.2/32 *[Local/0] 00:19:21 Local via ge-1/1/4.0172.16.1.2/32 *[Direct/0] 00:35:07 > via lo0.1224.0.0.5/32 *[OSPF/10] 00:35:07, metric 1 MultiRecv



Answer: All the neighbors should be adjacent.

Question: Which routers are the 20.20/16 customer routes visible on and why?

Answer: The customer routes should only be visible on the ABRs. The purpose of a stub area is to stop the ABRs from injecting external routing information and therefore reduce the size of the LSDB.

Step 2.3

Attempt to ping the loopback address of the remote team’s default router .

[edit protocols ospf]lab@mxA-1# run ping 172.16.R.1 count 5 PING 172.16.2.1 (172.16.2.1): 56 data bytes64 bytes from 172.16.2.1: icmp_seq=0 ttl=63 time=0.583 ms64 bytes from 172.16.2.1: icmp_seq=1 ttl=63 time=0.476 ms64 bytes from 172.16.2.1: icmp_seq=2 ttl=63 time=0.459 ms64 bytes from 172.16.2.1: icmp_seq=3 ttl=63 time=0.475 ms



64 bytes from 172.16.2.1: icmp_seq=4 ttl=63 time=0.478 ms



Attempt to ping the loopback address of the remote team’s R3-R router from your own R3-Y router. Don’t forget to specify the routing-instance.

[edit protocols ospf]lab@mxA-1# run ping 172.16.R.2 count 5 routing-instance R3-Y PING 172.16.2.2 (172.16.2.2): 56 data bytesping: sendto: No route to hostping: sendto: No route to hostping: sendto: No route to hostping: sendto: No route to hostping: sendto: No route to host

--- 172.16.2.2 ping statistics ---5 packets transmitted, 0 packets received, 100% packet loss


Question: Were the pings successful?

Answer: The ping between default routers should be successful. The ping between the routing-instance routers should not be successful.

Step 2.4

Issue a run show ospf database command and answer the following question.

[edit protocols ospf]lab@mxA-1# run show ospf database

OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router *172.16.1.1 172.16.1.1 0x80000067 185 0x22 0xfec2 48Router 172.16.2.1 172.16.2.1 0x80000067 171 0x22 0x18a4 48Router 172.31.100.1 172.31.100.1 0x8000004e 1498 0x22 0xdc57 60Network 172.22.121.2 172.31.100.1 0x80000007 289 0x22 0x34a0 32Network 172.22.122.2 172.31.100.1 0x80000006 44 0x22 0x389b 32Summary *10.0.1.0 172.16.1.1 0x80000007 141 0x22 0x5180 28Summary 10.0.2.0 172.16.2.1 0x80000007 171 0x22 0x3f90 28Summary *172.16.1.2 172.16.1.1 0x80000001 141 0x22 0x46dc 28Summary 172.16.2.2 172.16.2.1 0x80000002 170 0x22 0x32ed 28

OSPF database, Area 0.0.0.10 Type ID Adv Rtr Seq Age Opt Cksum Len



Router *172.16.1.1 172.16.1.1 0x80000005 141 0x20 0x837b 36Router 172.16.1.2 172.16.1.2 0x80000005 142 0x20 0x6365 48Network 10.0.1.2 172.16.1.2 0x80000001 142 0x20 0x14dc 32 OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern *20.20.0.0 172.16.1.1 0x80000002 805 0x22 0x6961 36Extern *20.20.1.0 172.16.1.1 0x80000002 610 0x22 0x5e6b 36Extern *20.20.2.0 172.16.1.1 0x80000002 417 0x22 0x5375 36Extern *20.20.3.0 172.16.1.1 0x80000002 224 0x22 0x487f 36Extern 20.20.4.0 172.16.2.1 0x80000002 805 0x22 0x368f 36Extern 20.20.5.0 172.16.2.1 0x80000002 610 0x22 0x2b99 36Extern 20.20.6.0 172.16.2.1 0x80000002 417 0x22 0x20a3 36Extern 20.20.7.0 172.16.2.1 0x80000002 224 0x22 0x15ad 36


Question: What types of LSAs are in your LSDB?

Answer: The answer varies depending on whether you are looking at the ABR or the router in the stub area. The stub area router should not have any Type 3, Type 4, or Type 5 LSAs.

Step 2.5

Restore connectivity in the network by allowing the ABR to generate a default route into the stub areas. Issue the set area Y0 stub default-metric 10 command and commit your configuration.

[edit protocols ospf]lab@mxA-1# set area Y0 stub default-metric 10



Note

At this point, you might have some connectivity issues reaching routers in other OSPF areas in the network because you removed so much information from the routing table. To restore connectivity to the rest of the network, OSPF stub and stub no-summaries areas use a default route generated by the ABR. Within the Junos OS, this default route is not automatically generated and must be explicitly configured.



Step 2.6

Attempt to ping the loopback of the remote routing-instance from your own routing-instance using the run ping 172.16.R.2 routing-instance R3-Y count 5.

[edit protocols ospf]lab@mxA-1# run ping 172.16.R.2 routing-instance R3-Y count 5 PING 172.16.2.2 (172.16.2.2): 56 data bytes64 bytes from 172.16.2.2: icmp_seq=0 ttl=61 time=0.578 ms64 bytes from 172.16.2.2: icmp_seq=1 ttl=61 time=0.496 ms64 bytes from 172.16.2.2: icmp_seq=2 ttl=61 time=0.504 ms64 bytes from 172.16.2.2: icmp_seq=3 ttl=61 time=0.513 ms64 bytes from 172.16.2.2: icmp_seq=4 ttl=61 time=0.529 ms



Question: Was the ping successful?

Answer: Yes, the ping now should be successful.




Part 3: Creating OSPF Not-So-Stubby-Areas

In this lab part, you convert the OSPF stub areas to NSSA areas.

Step 3.1

Configure the non-backbone area as an NSSA area for the main instance and R3-Y routing instance. Commit the configuration when completed.

[edit protocols ospf]lab@mxA-1# set area Y0 nssa


[edit routing-instances R3-1 protocols ospf]lab@mxA-1# set area Y0 nssa

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# commit



commit complete


Step 3.2

Issue run show ospf neighbor and run show route commands and answer the following questions.

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# run show ospf neighbor Address Interface State ID Pri Dead172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 3310.0.1.2 ge-1/0/4.0 Full 172.16.1.2 128 37

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# run show route


10.0.1.0/24 *[Direct/0] 00:31:56 > via ge-1/0/4.010.0.1.1/32 *[Local/0] 00:31:56 Local via ge-1/0/4.010.0.2.0/24 *[OSPF/10] 00:31:47, metric 5011 > to 172.22.121.2 via ge-1/0/0.111110.210.15.0/27 *[Direct/0] 00:47:42 > via fxp0.010.210.15.1/32 *[Local/0] 00:47:42 Local via fxp0.020.20.0.0/24 *[Static/5] 00:31:56 Reject20.20.1.0/24 *[Static/5] 00:31:56 Reject20.20.2.0/24 *[Static/5] 00:31:56 Reject20.20.3.0/24 *[Static/5] 00:31:56 Reject20.20.4.0/24 *[OSPF/150] 00:31:47, metric 0, tag 0 > to 172.22.121.2 via ge-1/0/0.111120.20.5.0/24 *[OSPF/150] 00:31:47, metric 0, tag 0 > to 172.22.121.2 via ge-1/0/0.111120.20.6.0/24 *[OSPF/150] 00:31:47, metric 0, tag 0 > to 172.22.121.2 via ge-1/0/0.111120.20.7.0/24 *[OSPF/150] 00:31:47, metric 0, tag 0 > to 172.22.121.2 via ge-1/0/0.1111172.16.1.1/32 *[Direct/0] 00:47:42 > via lo0.0172.16.1.2/32 *[OSPF/10] 00:04:33, metric 5000

Note

It might take a minute for the R3-Y adjacency to go back to Full.



> to 10.0.1.2 via ge-1/0/4.0172.16.2.1/32 *[OSPF/10] 00:31:47, metric 10011 > to 172.22.121.2 via ge-1/0/0.1111172.16.2.2/32 *[OSPF/10] 00:04:14, metric 5011 > to 172.22.121.2 via ge-1/0/0.1111172.22.121.0/24 *[Direct/0] 00:47:42 > via ge-1/0/0.1111172.22.121.1/32 *[Local/0] 00:47:42 Local via ge-1/0/0.1111172.22.122.0/24 *[OSPF/10] 00:31:56, metric 11 > to 172.22.121.2 via ge-1/0/0.1111172.31.100.1/32 *[OSPF/10] 00:31:56, metric 10 > to 172.22.121.2 via ge-1/0/0.1111224.0.0.5/32 *[OSPF/10] 00:47:42, metric 1 MultiRecv R3-1.inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

10.0.1.0/24 *[Direct/0] 00:31:56 > via ge-1/1/4.010.0.1.2/32 *[Local/0] 00:31:56 Local via ge-1/1/4.010.0.2.0/24 *[OSPF/10] 00:04:33, metric 70546 > to 10.0.1.1 via ge-1/1/4.020.20.0.0/24 *[OSPF/150] 00:04:33, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.020.20.1.0/24 *[OSPF/150] 00:04:33, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.020.20.2.0/24 *[OSPF/150] 00:04:33, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.020.20.3.0/24 *[OSPF/150] 00:04:33, metric 0, tag 0 > to 10.0.1.1 via ge-1/1/4.0172.16.1.1/32 *[OSPF/10] 00:04:33, metric 75535 > to 10.0.1.1 via ge-1/1/4.0172.16.1.2/32 *[Direct/0] 00:47:42 > via lo0.1172.16.2.1/32 *[OSPF/10] 00:04:33, metric 75546 > to 10.0.1.1 via ge-1/1/4.0172.16.2.2/32 *[OSPF/10] 00:04:14, metric 70546 > to 10.0.1.1 via ge-1/1/4.0172.22.121.0/24 *[OSPF/10] 00:04:33, metric 65545 > to 10.0.1.1 via ge-1/1/4.0172.22.122.0/24 *[OSPF/10] 00:04:33, metric 65546 > to 10.0.1.1 via ge-1/1/4.0172.31.100.1/32 *[OSPF/10] 00:04:33, metric 65545 > to 10.0.1.1 via ge-1/1/4.0224.0.0.5/32 *[OSPF/10] 00:47:42, metric 1 MultiRecv





Answer: All the neighbors should be adjacent.

Question: Which routers are the customer routes visible on and why?

Answer: The customer routes should be visible on all routers. The purpose of an NSSA area is to stop the ABRs from injecting external routing information and therefore reduce the size of the LSDB. However, an NSSA does allow external routes to be injected by an ASBR, which is why you can see the customer routes.




Part 4: Creating NSSA No Summaries

In this lab part, you change each of the NSSAs to be a no-summaries area.

Step 4.1

First, issue a run show ospf database command to view the LSDB content. Second, issue a run show ospf database | count command. Make note of this value so you have a point of reference after configuring the area with the no-summaries command.

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# run show ospf database

OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router *172.16.1.1 172.16.1.1 0x80000069 624 0x22 0xfac4 48Router 172.16.2.1 172.16.2.1 0x80000069 608 0x22 0x14a6 48Router 172.31.100.1 172.31.100.1 0x8000004f 776 0x22 0xda58 60Network 172.22.121.2 172.31.100.1 0x80000007 1262 0x22 0x34a0 32Network 172.22.122.2 172.31.100.1 0x80000006 1017 0x22 0x389b 32Summary *10.0.1.0 172.16.1.1 0x80000009 584 0x22 0x4d82 28Summary 10.0.2.0 172.16.2.1 0x80000009 567 0x22 0x3b92 28Summary *172.16.1.2 172.16.1.1 0x80000001 584 0x22 0x46dc 28Summary 172.16.2.2 172.16.2.1 0x80000001 567 0x22 0x34ec 28



OSPF database, Area 0.0.0.10 Type ID Adv Rtr Seq Age Opt Cksum Len Router *172.16.1.1 172.16.1.1 0x80000004 584 0x20 0x8b72 36Router 172.16.1.2 172.16.1.2 0x80000004 585 0x20 0x6564 48Network 10.0.1.2 172.16.1.2 0x80000002 585 0x20 0x12dd 32Summary *10.0.2.0 172.16.1.1 0x80000001 624 0x20 0xdeee 28Summary *172.16.1.1 172.16.1.1 0x80000001 624 0x20 0x6e1c 28Summary *172.16.2.1 172.16.1.1 0x80000001 624 0x20 0xd1ac 28Summary *172.16.2.2 172.16.1.1 0x80000001 565 0x20 0xc751 28Summary *172.22.121.0 172.16.1.1 0x80000001 624 0x20 0x66d3 28Summary *172.22.122.0 172.16.1.1 0x80000001 624 0x20 0x65d2 28Summary *172.31.100.1 172.16.1.1 0x80000001 624 0x20 0xd76d 28NSSA *20.20.0.0 172.16.1.1 0x80000001 624 0x20 0x6d5e 36NSSA *20.20.1.0 172.16.1.1 0x80000001 624 0x20 0x6268 36NSSA *20.20.2.0 172.16.1.1 0x80000001 624 0x20 0x5772 36NSSA *20.20.3.0 172.16.1.1 0x80000001 624 0x20 0x4c7c 36 OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern *20.20.0.0 172.16.1.1 0x80000003 704 0x22 0x6762 36Extern *20.20.1.0 172.16.1.1 0x80000003 386 0x22 0x5c6c 36Extern *20.20.2.0 172.16.1.1 0x80000003 233 0x22 0x5176 36Extern *20.20.3.0 172.16.1.1 0x80000003 80 0x22 0x4680 36Extern 20.20.4.0 172.16.2.1 0x80000003 707 0x22 0x3490 36Extern 20.20.5.0 172.16.2.1 0x80000003 389 0x22 0x299a 36Extern 20.20.6.0 172.16.2.1 0x80000003 236 0x22 0x1ea4 36Extern 20.20.7.0 172.16.2.1 0x80000003 83 0x22 0x13ae 36

[edit routing-instances R3-1 protocols ospf]lab@mxA-1# run show ospf database | count Count: 39 lines


Step 4.2

On the ABR only, configure the NSSA area for no-summaries and commit your configuration. Exit to operation mode at this time.


[edit protocols ospf]lab@mxA-1# set area Y0 nssa no-summaries

[edit protocols ospf]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 4.3

Issue a show ospf database | count command and make note of the value. Next, issue a show ospf database command and answer the following questions.



lab@mxA-1> show ospf database | count Count: 32 lines

lab@mxA-1> show ospf database

OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router *172.16.1.1 172.16.1.1 0x80000004 119 0x22 0xc55f 48Router 172.16.2.1 172.16.2.1 0x80000004 110 0x22 0xde41 48Router 172.31.100.1 172.31.100.1 0x8000007e 263 0x22 0x7c87 60Network 172.22.121.2 172.31.100.1 0x80000001 276 0x22 0x409a 32Network 172.22.122.2 172.31.100.1 0x80000001 263 0x22 0x4296 32Summary *10.0.1.0 172.16.1.1 0x80000007 69 0x22 0x5180 28Summary 10.0.2.0 172.16.2.1 0x80000007 59 0x22 0x3f90 28Summary *172.16.1.2 172.16.1.1 0x80000001 69 0x22 0x46dc 28Summary 172.16.2.2 172.16.2.1 0x80000001 59 0x22 0x34ec 28

OSPF database, Area 0.0.0.10 Type ID Adv Rtr Seq Age Opt Cksum Len Router *172.16.1.1 172.16.1.1 0x80000003 74 0x20 0x8d71 36Router 172.16.1.2 172.16.1.2 0x80000003 75 0x20 0x6763 48Network 10.0.1.2 172.16.1.2 0x80000002 75 0x20 0x12dd 32NSSA *20.20.0.0 172.16.1.1 0x80000001 119 0x20 0x6d5e 36NSSA *20.20.1.0 172.16.1.1 0x80000001 119 0x20 0x6268 36NSSA *20.20.2.0 172.16.1.1 0x80000001 119 0x20 0x5772 36NSSA *20.20.3.0 172.16.1.1 0x80000001 119 0x20 0x4c7c 36 OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern *20.20.0.0 172.16.1.1 0x80000001 275 0x22 0x6b60 36Extern *20.20.1.0 172.16.1.1 0x80000001 275 0x22 0x606a 36Extern *20.20.2.0 172.16.1.1 0x80000001 275 0x22 0x5574 36Extern *20.20.3.0 172.16.1.1 0x80000001 275 0x22 0x4a7e 36Extern 20.20.4.0 172.16.2.1 0x80000001 264 0x22 0x388e 36Extern 20.20.5.0 172.16.2.1 0x80000001 264 0x22 0x2d98 36Extern 20.20.6.0 172.16.2.1 0x80000001 264 0x22 0x22a2 36Extern 20.20.7.0 172.16.2.1 0x80000001 264 0x22 0x17ac 36

lab@mxA-1>

Question: Did a difference exist in the size of the LSDB after configuring the NSSA area with no-summaries?

Answer: Yes, the LSDB was made smaller.

Note

Due to route churn, you might see the count fluctuate some before settling down.



Question: Which LSAs were dropped from the LSDB after making the change?

Answer: The Summary LSAs are no longer present in the routing-instance router’s LSDB.

Question: Is the effect of this command different when used in an NSSA as opposed to a stub area?

Answer: The behavior is similar to a stub area with no-summaries.

Step 4.4


lab@mxA-1> exit



Lab 3Advanced OSPF Options and Routing Policy (Detailed)

Overview

In this lab, you will use the lab diagram titled “Lab 3: Advanced OSPF Options and Routing Policy” to establish a multiarea OSPF routing domain. This lab will require the configuration of a virtual tunnel as backup to the backbone connection and a multiarea adjacency as outlined in RFC 5185. The final part of this lab will require routing policy to redistribute and advertise routes being received from a RIP network into OSPF external link-state advertisements (LSAs).


• Load the default configuration.

• Establish multiple OSPF adjacencies.

• Configure and verify a virtual tunnel.

• Configure and verify a OSPF multiarea adjacency.

• Establish a RIP neighbor peer session.

• Write a routing policy to advertise a default route into RIP.

• Configure prefix-limits in OSPF to prevent excessive external routes.

• Write a routing policy to advertise a RIP summary route into OSPF.

• Write an OSPF import policy to prevent suboptimal routing.

www.juniper.net Advanced OSPF Options and Routing Policy (Detailed) • Lab 3–111.a.11.4R1.14


Part 1: Establishing the OSPF Adjacencies and Creating a Virtual Tunnel

In this lab part, you load the reset configuration and establish the OSPF adjacencies. The virtual router device (vr-device) provides connectivity among all three OSPF areas—your student device and your partner’s.

Step 1.1


Step 1.2


Note



Lab 3–2 • Advanced OSPF Options and Routing Policy (Detailed) www.juniper.net


mxA-1 (ttyu0)

login: labPassword:


Step 1.3

Enter into configuration mode and load the device’s reset configuration by issuing the load override ajspr/lab3-start.config command. After the configuration has been loaded, commit the changes.


[edit]lab@mxA-1#



[edit]lab@mxA-1#

Step 1.4

Variable references are used throughout this lab to distinguish various parts of the command-line interface (CLI) input.






www.juniper.net Advanced OSPF Options and Routing Policy (Detailed) • Lab 3–3


Navigate to the [edit protocols ospf] hierarchy. Establish the OSPF adjacencies, from your default router, with P1, P2, and R3-Y. Configure OSPF Area 0 as the backbone area and do not forget the loopback address. Configure OSPF Area 10 as an NSSA and advertise a default route with a metric of 10. At this time, no need exists to configure adjacencies from within the R3-Y virtual router. They were pre-configured by the reset config you applied previously. OSPF Area 20 is configured as a normal OSPF area i.e. not a stub or NSSA area. Commit the configuration when completed.


[edit protocols ospf]lab@mxA-1# set area 0 interface lo0.0


[edit protocols ospf]lab@mxA-1# set area 10 nssa default-lsa default-metric 10

[edit protocols ospf]lab@mxA-1# set area 10 interface ge-1/0/4.0


[edit protocols ospf]lab@mxA-1# commitcommit complete


Step 1.5

Issue a run show ospf interface command to verify interfaces are running OSPF.

[edit protocols ospf]lab@mxA-1# run show ospf interface Interface State Area DR ID BDR ID Nbrsge-1/0/0.1111 BDR 0.0.0.0 172.16.100.1 172.16.1.1 1lo0.0 DR 0.0.0.0 172.16.1.1 0.0.0.0 0ge-1/0/4.0 BDR 0.0.0.10 172.16.1.2 172.16.1.1 1ge-1/0/0.1113 BDR 0.0.0.20 172.16.101.1 172.16.1.1 1

Question: How many interfaces are running OSPF?

Answer: There should be 3 transit interfaces and the loopback interface for a total of 4 interfaces running OSPF.



Step 1.6

Issue a run show ospf neighbor command to verify the establishment of OSPF adjacencies.

[edit protocols ospf]lab@mxA-1# run show ospf neighbor Address Interface State ID Pri Dead172.22.121.2 ge-1/0/0.1111 Full 172.16.100.1 128 3810.0.10.2 ge-1/0/4.0 Full 172.16.1.2 128 39172.22.123.2 ge-1/0/0.1113 Full 172.16.101.1 128 32

Question: Are all OSPF adjacencies established and in the Full state?

Answer: Yes. There should be three established OSPF adjacencies, one in each OSPF area including Area 0.0.0.10, which is configured as a not-so-stubby-area.

Step 1.7

Verify that the routing table has connectivity to all devices in the OSPF domain. Use the run show route table inet.0 protocol ospf | match /32 command to display only the host addresses.

[edit protocols ospf]lab@mxA-1# run show route table inet.0 protocol ospf | match /32 20.20.1.1/32 *[OSPF/10] 01:34:55, metric 240.40.1.1/32 *[OSPF/10] 01:34:55, metric 2172.16.1.2/32 *[OSPF/10] 01:34:55, metric 1172.16.2.1/32 *[OSPF/10] 00:03:09, metric 2172.16.2.2/32 *[OSPF/10] 01:34:55, metric 3172.31.100.1/32 *[OSPF/10] 00:03:13, metric 1172.31.101.1/32 *[OSPF/10] 00:03:13, metric 1172.31.102.1/32 *[OSPF/10] 00:03:18, metric 2224.0.0.5/32 *[OSPF/10] 01:35:10, metric 1




Question: With the exception of the 224.0.0.5/32 OSPF multicast address and your own loopback address, is there an entry in the primary routing table (inet.0) for the other eight loopback addresses within the OSPF domain?

Answer: Yes. If your partner has successfully configured OSPF, there should be eight host addresses in the inet.0 routing table, one for each loopback address.

Step 1.8

Using the OSPF virtual-link command, configure a virtual link in OSPF Area 0 that uses Area 20 as the transit-area. The virtual link’s neighbor-id is the loopback address of your partner's default router. The virtual link should be used only as a backup in the event of a P1 failure. This can be accomplished by setting the Area 20 interface to a high metric. Commit this configuration when completed.

[edit protocols ospf]lab@mxA-1# set area 0 virtual-link transit-area 20 neighbor-id 172.16.R.1

[edit protocols ospf]lab@mxA-1# set area 20 interface ge-1/0/0.11ZV metric 10



Step 1.9

Verify that the virtual link has been established and that an adjacency has been formed. Use the run show ospf interface command to display the virtual link interface.

[edit protocols ospf]lab@mxA-1# run show ospf interface Interface State Area DR ID BDR ID Nbrsge-1/0/0.1111 BDR 0.0.0.0 172.31.100.1 172.16.1.1 1lo0.0 DR 0.0.0.0 172.16.1.1 0.0.0.0 0vl-172.16.2.1 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1ge-1/0/4.0 BDR 0.0.0.10 172.16.1.2 172.16.1.1 1ge-1/0/0.1113 BDR 0.0.0.20 172.31.101.1 172.16.1.1 1



Question: What type of interface is created for the virtual link?

Answer: A point-to-point interface is created for the virtual tunnel.

Step 1.10

Verify that the virtual link has an adjacency. Use the run show ospf neighbor command to display the state of the virtual link interface.

[edit protocols ospf]lab@mxA-1# run show ospf neighbor Address Interface State ID Pri Dead172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 39172.22.124.1 vl-172.16.2.1 Full 172.16.2.1 0 3210.0.10.2 ge-1/0/4.0 Full 172.16.1.2 128 34172.22.123.2 ge-1/0/0.1113 Full 172.31.101.1 128 31


Question: What is the OSPF state on the virtual link interface?

Answer: The state should be Full.

Step 1.11

Use the run show route table inet.0 172.16.R.1/32 command to verify that your partner's default loopback address still routes through the P1 router and not through the virtual link.

[edit protocols ospf]lab@mxA-1# run show route table inet.0 172.16.R.1/32






Question: Is the loopback address of your partner’s student device using the P1 router or the virtual link?

Answer: The loopback address of your partner’s student device is using the P1 router and not the virtual link. This is because of the metric you set on the interface in Area 20.

Part 2: Configuring OSPF Multiarea

In this lab part, you use the OSPF multiarea adjacency command outlined in RFC 5185 to provide an alternate path for OSPF Area 0.0.0.10.

Step 2.1

Configure an OSPF Area 10 adjacency through the P1 router as a secondary interface with a metric of 10. Adding the Area 0 interface to Area10 with the secondary setting will provide a backup path for Area 10 in the event of a P3 failure. Commit these changes when completed.

[edit protocols ospf]lab@mxA-1# set area 10 interface ge-1/0/0.11ZV secondary metric 10



Step 2.2

Use the run show ospf interface command to verify the multiarea interface is in OSPF Area 10.

[edit protocols ospf]lab@mxA-1# run show ospf interface Interface State Area DR ID BDR ID Nbrsge-1/0/0.1111 BDR 0.0.0.0 172.31.100.1 172.16.1.1 1lo0.0 DR 0.0.0.0 172.16.1.1 0.0.0.0 0vl-172.16.2.1 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1ge-1/0/0.1111 PtToPt 0.0.0.10 0.0.0.0 0.0.0.0 1ge-1/0/4.0 DR 0.0.0.10 172.16.1.1 172.16.1.2 1ge-1/0/0.1113 BDR 0.0.0.20 172.31.101.1 172.16.1.1 1




Question: The interface connected to P1 has two established states in OSPF. What is the established state for the interface in Area 0.0.0.10? Why?

Answer: The established interface state for Area 0.0.0.10 is point-to-point. As outlined in RFC 5185, all secondary multiarea adjacencies will be formed using a point-to-point interface.

Step 2.3

Use the run show ospf neighbor command to verify the establishment of an OSPF Area 10 adjacency through P1.

[edit protocols ospf]lab@mxA-1# run show ospf neighbor Address Interface State ID Pri Dead172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 39 Area 0.0.0.0172.22.124.1 vl-172.16.2.1 Full 172.16.2.1 0 35 Area 0.0.0.0172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 32 Area 0.0.0.1010.0.10.2 ge-1/0/4.0 Full 172.16.1.2 128 36 Area 0.0.0.10172.22.123.2 ge-1/0/0.1113 Full 172.31.101.1 128 38 Area 0.0.0.20


Question: How many OSPF adjacencies are there for Area 0.0.0.10?

Answer: Two adjacencies have been formed within OSPF Area 0.0.0.10.

Step 2.4

Use the run show route table inet.0 172.16.R.2/32 command to verify that the loopback address of your partner's R3-R router is being routed through the interface to your R3-Y router.

[edit protocols ospf]lab@mxA-1# run show route table inet.0 172.16.R.2/32





Question: What is the primary path to your partner’s virtual router’s loopback address?

Answer: The primary path to your partner’s loopback address is through your R3-Y router.

Step 2.5 Lab Team 1 only

The remaining steps of Part 2 should be performed only on the mxX-1 router.

Disable the default VLAN interface to your R3-Y routing instance in OSPF Area 0.0.0.10. Commit the configuration when completed.

[edit protocols ospf]lab@mxA-1# top

[edit]lab@mxA-1# set interfaces ge-1/0/4 disable

[edit]lab@mxA-1# commit commit complete

[edit]lab@mxA-1#


Use the run show route table inet.0 172.16.2.2/32 command to verify that the multiarea connectivity for OSPF Area 0.0.0.10 has converged through the P1 router.

[edit]lab@mxA-1# run show route table inet.0 172.16.2.2/32



[edit]lab@mxA-1#


Use the run traceroute 172.16.2.2 command to verify that the traffic is traversing P1.

[edit]lab@mxA-1# run traceroute 172.16.2.2 traceroute to 172.16.2.2 (172.16.2.2), 30 hops max, 40 byte packets 1 172.22.121.2 (172.22.121.2) 0.478 ms 0.282 ms 0.252 ms



2 172.22.122.1 (172.22.122.1) 0.311 ms 0.269 ms 0.267 ms 3 172.16.2.2 (172.16.2.2) 0.394 ms 0.360 ms 0.386 ms

[edit]lab@mxA-1#

Question: Did OSPF converge to the multiarea configuration?

Answer: Yes. OSPF converged to the backup multiarea adjacency.


Use the rollback command to enable the default OSPF connection for Area 10. Commit the configuration when completed.

[edit]lab@mxA-1# rollback 1 load complete


[edit]lab@mxA-1#


Verify that OSPF converged back to the primary path by displaying your partner's loopback address using the run show route table inet.0 172.16.2.2/32 and run traceroute 172.16.2.2 commands.

[edit]lab@mxA-1# run show route table inet.0 172.16.2.2/32



[edit]lab@mxA-1# run traceroute 172.16.2.2 traceroute to 172.16.2.2 (172.16.2.2), 30 hops max, 40 byte packets 1 10.0.10.2 (10.0.10.2) 0.379 ms 0.271 ms 0.254 ms

Note

It might take a minute for the ge-1/0/4 interface to return to a Full state.



2 172.22.125.2 (172.22.125.2) 0.277 ms 0.262 ms 0.263 ms 3 172.16.2.2 (172.16.2.2) 0.432 ms 0.350 ms 0.342 ms

[edit]lab@mxA-1#

Question: Did OSPF converge to the back to your R3-Y router?

Answer: Yes. OSPF converged back to the R3-Y router.

STOP Do not proceed until the remote team finishes Part 2.

Part 3: Configuring External Reachability

In this lab part, you configure an external connection from the R3 routing instance to a RIP network. Once established, the RIP routes will be redistributed into OSPF.

Step 3.1

Navigate to the [edit routing-instances R3-Y] hierarchy. Remove the OSPF Area 10 interface that connects to the P3 router and configure that interface in protocols RIP. Use a RIP group name of P3 and commit the configuration when completed.

[edit]lab@mxA-1# top edit routing-instances R3-Y

[edit routing-instances R3-1]lab@mxA-1# delete protocols ospf area 10 interface ge-1/0/0.11ZV

[edit routing-instances R3-1]lab@mxA-1# set protocols rip group P3 neighbor ge-1/0/0.11ZV

[edit routing-instances R3-1]lab@mxA-1# commit commit complete

[edit routing-instances R3-1]lab@mxA-1#

Step 3.2

Use the run show route receive-protocol rip 172.22.12V.2 table R3-Y.inet.0 command to verify that RIP routes are being received from the P3 router.



[edit routing-instances R3-1]lab@mxA-1# run show route receive-protocol rip 172.22.12V.2 table R3-Y.inet.0


20.20.0.0/21 *[RIP/100] 00:05:30, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.0.0/24 *[RIP/100] 00:05:30, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.1.0/24 *[RIP/100] 00:05:30, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.2.0/24 *[RIP/100] 00:05:30, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.3.0/24 *[RIP/100] 00:05:30, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.4.0/25 *[RIP/100] 00:05:30, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.4.128/25 *[RIP/100] 00:05:30, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.5.0/26 *[RIP/100] 00:05:30, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.5.64/26 *[RIP/100] 00:05:30, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.5.128/26 *[RIP/100] 00:05:30, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.5.192/26 *[RIP/100] 00:05:30, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.1115


Step 3.3

Navigate to the [edit policy-options policy-statement export-default] hierarchy. Create a policy term to advertise only the OSPF default route to the RIP router. Do not commit the configuration at this time.

[edit routing-instances R3-1]lab@mxA-1# top edit policy-options policy-statement export-default

[edit policy-options policy-statement export-default]lab@mxA-1# set term 1 from protocol ospf

[edit policy-options policy-statement export-default]lab@mxA-1# set term 1 from route-filter 0/0 exact

[edit policy-options policy-statement export-default]lab@mxA-1# set term 1 then accept

[edit policy-options policy-statement export-default]lab@mxA-1# show term 1 { from { protocol ospf; route-filter 0.0.0.0/0 exact;



} then accept;}

[edit policy-options policy-statement export-default]lab@mxA-1#

Step 3.4

Team 1 only. Navigate to the [edit routing-instances R3-1] hierarchy. Apply the export-default policy as an export policy in protocol RIP group P3. Commit the configuration when completed.

[edit policy-options policy-statement export-default]lab@mxA-1# top edit routing-instances R3-1

[edit routing-instances R3-1]lab@mxA-1# set protocols rip group P3 export export-default



Step 3.5

Team 2 only. Navigate to the [edit routing-instances R3-2] hierarchy. Apply the export-default policy as an export policy in protocol RIP group P3. Commit the configuration when completed.

[edit policy-options policy-statement export-default]lab@mxA-2# top edit routing-instances R3-2

Note

The next two steps will need to be coordinated with your remote team partners.

Note

This step is to be performed by Team 1 only. Team 2 will perform the same step after waiting two minutes from the time of this commit.

Note

This step is to be performed by Team 2 only after waiting two minutes from the commit time of the previous step.



[edit routing-instances R3-1]lab@mxA-2# set protocols rip group P3 export export-default



Step 3.6

Use the run show route advertising-protocol rip 172.22.12V.1 table R3-Y.inet.0 command to verify that the route is being advertised to the P3 router.

[edit routing-instances R3-1]lab@mxA-1# run show route advertising-protocol rip 172.22.125.1 table

R3-1.inet.0




...........................................................................


R3-2.inet.0


Note

The output from both routers is shown in the following capture.



Question: Is the default route being advertised to R3?

Answer: The answer depends on which router advertised the default route first. One of the routers will not be advertising the route because its active route for the 0/0 default route is a RIP route, not an OSPF route. This is because the RIP preference of 100 is lower than the OSPF external preference of 150. Recall that the export-default policy you just applied uses a from protocol ospf in its term. Policy can only act on active routes. Therefore, in the previous output, the R3-2 router cannot advertise the route. We will demonstrate this issue and fix it in subsequent steps.

Step 3.7

Display the default route in the R3 routing table using the run show route 0/0 exact table R3-Y.inet.0 command.

[edit routing-instances R3-1]lab@mxA-1# run show route 0/0 exact table R3-1.inet.0




...........................................................................

[edit routing-instances R3-2]lab@mxA-2# run show route 0/0 exact table R3-2.inet.0


0.0.0.0/0 *[RIP/100] 00:59:58, metric 3, tag 0 > to 172.22.126.2 via ge-1/0/0.1116 [OSPF/150] 02:21:48, metric 11, tag 0 > to 10.0.20.1 via ge-1/1/4.0

Note





Question: What is the active protocol for the default route?

Answer: The answer depends on which router advertised the default route first. Based on the previous output for the mxA-2 router, the active protocol for the default route is RIP, because the preference of RIP (100) is lower than the external preference of OSPF (150).

Step 3.8

Set the OSPF external-preference to 90 for the R3-Y router. Doing so will make the OSPF external preference less than the RIP preference of 100. Commit the changes when completed.

[edit routing-instances R3-1]lab@mxA-1# set protocols ospf external-preference 90



Step 3.9

Use the run show route advertising-protocol rip 172.22.12V.1 table R3-Y.inet.0 command to verify that both routers are advertising the default route to the RIP router.


R3-1.inet.0



[edit routing-instances R3-1]

Note




lab@mxA-1#

...........................................................................[edit routing-instances R3-2]lab@mxA-2# run show route advertising-protocol rip 172.22.126.1 table

R3-2.inet.0


0.0.0.0/0 *[OSPF/90] 00:01:32, metric 11, tag 0 > to 10.0.20.1 via ge-1/1/4.0 [RIP/100] 01:04:02, metric 3, tag 0 > to 172.22.126.2 via ge-1/0/0.1116


Question: Is the route now being advertised to the RIP network?

Answer: Yes. The lower OSPF preference has made the default route active under OSPF, which matches the RIP export policy.

Step 3.10

Navigate to the [edit policy-options policy-statement import-rip-route] hierarchy. Create a policy to accept only the 20.20/21 summary route from the RIP router.

[edit routing-instances R3-1]lab@mxA-1# top edit policy-options policy-statement import-rip-route

[edit policy-options policy-statement import-rip-route]lab@mxA-1# set term 1 from protocol rip

[edit policy-options policy-statement import-rip-route]lab@mxA-1# set term 1 from route-filter 20.20/21 exact

[edit policy-options policy-statement import-rip-route]

Note

Do not be alarmed if you do not see the RIP route as shown in the previous mxX-2 output. It will eventually time out and be removed from the routing table. The key is to see that the active route for 0/0 is now an OSPF route and that both routers are now advertising it.



lab@mxA-1# set term 1 then accept

[edit policy-options policy-statement import-rip-route]lab@mxA-1# set term 2 from protocol rip

[edit policy-options policy-statement import-rip-route]lab@mxA-1# set term 2 from route-filter 20.20/21 longer

[edit policy-options policy-statement import-rip-route]lab@mxA-1# set term 2 then reject

[edit policy-options policy-statement import-rip-route]lab@mxA-1# showterm 1 { from { protocol rip; route-filter 20.20.0.0/21 exact; } then accept;}term 2 { from { protocol rip; route-filter 20.20.0.0/21 longer; } then reject;}[edit policy-options policy-statement import-rip-route]lab@mxA-1#

Step 3.11

Navigate to the [edit routing instances R3-Y] hierarchy and apply the policy as an import policy under protocols RIP group P3. Commit the configuration when completed.

[edit policy-options policy-statement import-rip-route]lab@mxA-1# top edit routing-instances R3-Y

[edit routing-instances R3-1]lab@mxA-1# set protocols rip group P3 import import-rip-route



Step 3.12

Display the routes being received from the RIP router using the run show route receive-protocol rip 172.22.12V.2 table R3-Y.inet.0 command. Verify that only the summary route is now being received from the P3 RIP router.





20.20.0.0/21 *[RIP/100] 01:36:30, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.1115


Question: Is the RIP import policy working?

Answer: Because only the summary route is being received from the RIP neighbor, yes, the import policy appears to be working.

Step 3.13

Navigate to the [edit policy-options policy-statement export-rip-route] hierarchy. Create a routing policy to redistribute the RIP summary route into OSPF.

[edit routing-instances R3-1]lab@mxA-1# top edit policy-options policy-statement export-rip-route

[edit policy-options policy-statement export-rip-route]lab@mxA-1# set term 1 from protocol rip

[edit policy-options policy-statement export-rip-route]lab@mxA-1# set term 1 then accept

[edit policy-options policy-statement export-rip-route]lab@mxA-1# showterm 1 { from protocol rip; then accept;}[edit policy-options policy-statement export-rip-route]lab@mxA-1#

Step 3.14

Note

This step is to be performed by Team 1 only. Team 2 will perform the same step after waiting two minutes from the time of this commit.



Team 1 only. Navigate to the [edit routing-instances R3-Y] hierarchy. Before applying the policy as an OSPF export policy, protect the network from unnecessary routes by configuring a prefix-export-limit of 1 within protocols OSPF. Commit the configuration when completed.

[edit policy-options policy-statement export-rip-route]lab@mxA-1# top edit routing-instances R3-1

[edit routing-instances R3-1]lab@mxA-1# set protocols ospf prefix-export-limit 1

[edit routing-instances R3-1]lab@mxA-1# set protocols ospf export export-rip-route



Step 3.15

Team 2 only. Navigate to the [edit routing-instances R3-Y] hierarchy. Before applying the policy as an OSPF export policy, protect the network from unnecessary routes by configuring a prefix-export-limit of 1 within protocols OSPF. Commit the configuration when completed.

[edit policy-options policy-statement export-rip-route]lab@mxA-2# top edit routing-instances R3-2

[edit routing-instances R3-2]lab@mxA-2# set protocols ospf prefix-export-limit 1

[edit routing-instances R3-2]lab@mxA-2# set protocols ospf export export-rip-route



Step 3.16

Verify connectivity to the RIP network by performing a trace to the RIP router using the redistributed RIP summary route. Enter the run traceroute 20.20.1.1 routing-instance R3-Y command to verify connectivity.

Note

This step is to be performed by Team 2 only after waiting two minutes from the commit time of the previous step.



[edit routing-instances R3-1]lab@mxA-1# run traceroute 20.20.1.1 routing-instance R3-1traceroute to 20.20.1.1 (20.20.1.1), 30 hops max, 40 byte packets 1 20.20.1.1 (20.20.1.1) 0.508 ms 0.361 ms 0.315 ms


...........................................................................

[edit routing-instances R3-2]lab@mxA-2# run traceroute 20.20.1.1 routing-instance R3-2 traceroute to 20.20.1.1 (20.20.1.1), 30 hops max, 40 byte packets 1 10.0.20.1 (10.0.20.1) 8.010 ms 0.267 ms 0.253 ms 2 172.22.122.2 (172.22.122.2) 10.089 ms 0.288 ms 0.261 ms 3 172.22.121.1 (172.22.121.1) 0.356 ms 0.303 ms 0.281 ms 4 10.0.10.2 (10.0.10.2) 0.301 ms 0.303 ms 0.291 ms 5 20.20.1.1 (20.20.1.1) 0.420 ms 0.412 ms 0.380 ms


Question: What would be causing the sub-optimal path to the RIP network for the mxX-2 router?

Answer: When multiple ABRs are present in an NSSA area, only the ABR with the highest router ID will translate the Type 7 to a Type 5. This causes the sub-optimal routing we see in this case. We demonstrate how to find this information in the subsequent steps.

Step 3.17

Examine the OSPF Type 7 to Type 5 conversion between the OSPF NSSA area and the OSPF backbone area. Use the run show ospf database area 10 nssa detail command to display the Type 7 LSAs and the run show ospf database external detail to display the Type 5 LSA.

[edit routing-instances R3-1]lab@mxA-1# run show ospf database area 10 nssa detail

OSPF database, Area 0.0.0.10 Type ID Adv Rtr Seq Age Opt Cksum Len NSSA *0.0.0.0 172.16.1.1 0x80000003 1220 0x20 0x4028 36

Note




mask 0.0.0.0 Topology default (ID 0) Type: 1, Metric: 10, Fwd addr: 0.0.0.0, Tag: 0.0.0.0NSSA 0.0.0.0 172.16.2.1 0x80000003 1446 0x20 0x392e 36 mask 0.0.0.0 Topology default (ID 0) Type: 1, Metric: 10, Fwd addr: 0.0.0.0, Tag: 0.0.0.0NSSA 20.20.0.0 172.16.1.2 0x80000001 2078 0x28 0x35d2 36 mask 255.255.248.0 Topology default (ID 0) Type: 2, Metric: 2, Fwd addr: 172.16.1.2, Tag: 0.0.0.0

[edit routing-instances R3-1]lab@mxA-1# run show ospf database external detail OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern 20.20.0.0 172.31.100.1 0x80000001 2105 0x22 0x811d 36 mask 255.255.248.0 Topology default (ID 0) Type: 2, Metric: 2, Fwd addr: 172.16.1.2, Tag: 0.0.0.0


Question: Which ABR created the Type 7 LSA for the 20.20.0.0 prefix? Which ABR created the Type 5 external LSA? Why?

Answer: The R3-1 router created the Type 7. However, the P1 router created the Type 5 LSA. The P1 router has the highest router ID between the three ABRs connected to OSPF NSSA Area 10. It might not appear that the P1 router is an ABR, but recall the Area 10 Multiarea Link we created through P1. This Multiarea Link is what allows P1 to be an ABR within Area 10. We will work around this issue in the next step.

Step 3.18

Navigate to the [edit policy-options policy-statement ospf-import] hierarchy. Create the OSPF import policy to block the 20.20/21 RIP summary route from being installed in the routing table from OSPF.

[edit routing-instances R3-1]lab@mxA-1# top edit policy-options policy-statement ospf-import

[edit policy-options policy-statement ospf-import]lab@mxA-1# set term 1 from route-filter 20.20.0.0/21 orlonger



[edit policy-options policy-statement ospf-import]lab@mxA-1# set term 1 then reject

[edit policy-options policy-statement ospf-import]lab@mxA-1# showterm 1 { from { route-filter 20.20.0.0/21 orlonger; } then reject;}[edit policy-options policy-statement ospf-import]lab@mxA-1#

Step 3.19

Navigate to the [edit routing instance R3-Y] hierarchy and apply the OSPF import policy. Commit the changes when completed and exit to operational mode.

[edit policy-options policy-statement ospf-import]lab@mxA-1# top edit routing-instances R3-Y

[edit routing-instances R3-1]lab@mxA-1# set protocols ospf import ospf-import

[edit routing-instances R3-1]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 3.20

Verify that the OSPF import policy is working and that optimal routing is being performed to the RIP network by using the traceroute 20.20.1.1 routing-instance R3-Y command.

lab@mxA-1> traceroute 20.20.1.1 routing-instance R3-1 traceroute to 20.20.1.1 (20.20.1.1), 30 hops max, 40 byte packets 1 20.20.1.1 (20.20.1.1) 0.506 ms 0.372 ms 0.359 ms

lab@mxA-1>

...........................................................................

lab@mxA-2> traceroute 20.20.1.1 routing-instance R3-2 traceroute to 20.20.1.1 (20.20.1.1), 30 hops max, 40 byte packets

Note




1 20.20.1.1 (20.20.1.1) 0.547 ms 0.387 ms 0.352 ms

lab@mxA-2>

Question: Is the OSPF import policy working?

Answer: Yes. The OSPF import policy is providing an optimal path to the RIP network for both R3-Y routers.

Step 3.21


lab@mxA-1> exit





Lab 4IS-IS Configuration and Monitoring (Detailed)

Overview

In this lab, you will use the lab diagram titled “Lab 4: IS-IS Configuration and Monitoring” to establish an IS-IS routing domain. The IS-IS network will be configured on top of the OSPF network currently running from Lab 3. After verifying the IS-IS configuration, routing will be converted from OSPF to IS-IS.


• Configure support of the ISO protocol data unit (PDU).

• Configure the IS-IS Network Entity Title (NET).

• Establish IS-IS adjacencies.

• Monitor IS-IS interfaces and adjacencies.

Note



www.juniper.net IS-IS Configuration and Monitoring (Detailed) • Lab 4–111.a.11.4R1.14


Part 1: Configuring the Transit Interfaces to Support ISO Packets

In this lab part, you load the reset configuration and configure family iso on all transit interfaces that could support IS-IS PDUs. The ingress I/O manager verifies Layer 3 packet headers based on the configuration provided for each logical interface including IPv4 and IPv6 protocols. Because the IS-IS PDU is not an IPv4 or IPv6 packet, the hardware must be configured to process this ISO PDU.

Step 1.1


Step 1.2


mxA-1 (ttyu0)

login: labPassword:


Step 1.3




[edit]lab@mxA-1# commit

Lab 4–2 • IS-IS Configuration and Monitoring (Detailed) www.juniper.net


commit complete

[edit]lab@mxA-1#

Step 1.4

Navigate to the [edit group ISO] hierarchy. Using wildcard commands, configure all transit interfaces (interface <*-*>) to support the IS-IS family iso on all logical units (unit <*>).

[edit]lab@mxA-1# edit groups ISO

[edit groups ISO]lab@mxA-1# set interfaces <*-*> unit <*> family iso

[edit groups ISO]lab@mxA-1#

Step 1.5

Navigate to the [edit interfaces] hierarchy and apply the ISO group to all interfaces. Commit the configuration when completed.

[edit groups ISO]lab@mxA-1# top edit interfaces

[edit interfaces]lab@mxA-1# set apply-groups ISO

[edit interfaces]lab@mxA-1# commit commit complete

[edit interfaces]lab@mxA-1#

Step 1.6

Use the show | display inheritance command to verify that family iso has been inherited by all transit logical interfaces.

[edit interfaces]lab@mxA-1# show | display inheritance ge-1/0/0 { vlan-tagging; unit 1111 { description "connection to P1"; vlan-id 1111; family inet { address 172.22.121.1/24; } ## ## 'iso' was inherited from group 'ISO' ## family iso; }

www.juniper.net IS-IS Configuration and Monitoring (Detailed) • Lab 4–3


unit 1113 { description "connection to P2"; vlan-id 1113; family inet { address 172.22.123.1/24; } ## ## 'iso' was inherited from group 'ISO' ## family iso; } unit 1115 { description "connection to P3"; vlan-id 1115; family inet { address 172.22.125.1/24; } ## ## 'iso' was inherited from group 'ISO' ## family iso; }}ge-1/0/4 { description "connection to R3-1"; unit 0 { family inet { address 10.0.10.1/24; } ## ## 'iso' was inherited from group 'ISO' ## family iso; }}ge-1/1/4 { description "connection to mxA-1"; unit 0 { family inet { address 10.0.10.2/24; } ## ## 'iso' was inherited from group 'ISO' ## family iso; }}fxp0 { description "MGMT INTERFACE - DO NOT DELETE"; unit 0 { family inet { address 10.210.15.1/27; } }}



lo0 { unit 0 { family inet { address 172.16.1.1/32; } } unit 1 { family inet { address 172.16.1.2/32; } }}


Question: Did the permanent interfaces fxp0 and lo0 inherit the family iso command?

Answer: No, the <*-*> wildcard parameter only matches on transit interfaces.

Step 1.7

Issue a run show interface terse command to verify the family iso configuration on the interfaces.

[edit interfaces]lab@mxA-1# run show interfaces terse Interface Admin Link Proto Local Remotelc-0/0/0 up up lc-0/0/0.32769 up up vpls xe-0/0/0 up downxe-0/0/1 up downxe-0/0/2 up downxe-0/0/3 up downge-1/0/0 up up ge-1/0/0.1111 up up inet 172.22.121.1/24 iso multiservicege-1/0/0.1113 up up inet 172.22.123.1/24 iso multiservicege-1/0/0.1115 up up inet 172.22.125.1/24 iso multiservicege-1/0/0.32767 up up multiservicege-1/0/1 up up ge-1/0/2 up up ge-1/0/3 up up ge-1/0/4 up up ge-1/0/4.0 up up inet 10.0.10.1/24 iso multiservice



ge-1/0/5 up up ge-1/0/6 up up ge-1/0/7 up up ge-1/0/8 up up ge-1/0/9 up up gr-1/0/10 up up ip-1/0/10 up up lt-1/0/10 up up mt-1/0/10 up up pd-1/0/10 up up pe-1/0/10 up up ut-1/0/10 up up vt-1/0/10 up up ge-1/1/0 up up ge-1/1/1 up downge-1/1/2 up up ge-1/1/3 up up ge-1/1/4 up up ge-1/1/4.0 up up inet 10.0.10.2/24 iso multiservicege-1/1/5 up up ge-1/1/6 up up ge-1/1/7 up up ge-1/1/8 up up ge-1/1/9 up up cbp0 up up demux0 up up dsc up up em0 up up em0.0 up up inet 10.0.0.1/8 10.0.0.4/8 128.0.0.1/2 128.0.0.4/2 inet6 fe80::200:ff:fe00:4/64 fec0::a:0:0:4/64 tnp 0x4 em1 up downfxp0 up up fxp0.0 up up inet 10.210.15.1/27 gre up up ipip up up irb up up lo0 up up lo0.0 up up inet 172.16.1.1 --> 0/0lo0.1 up up inet 172.16.1.2 --> 0/0lo0.16384 up up inet 127.0.0.1 --> 0/0lo0.16385 up up inet lsi up up me0 up up mtun up up pimd up up pime up up pip0 up up pp0 up up



tap up up


Question: Only the transit interfaces with configured logical units inherited the family iso parameter. Why?

Answer: The group interface command included the unit wildcard <*>, which only matches on interfaces with logical units configured.

Part 2: Configuring the IS-IS Network Entity Title






5. Variable Z will be either 1, 2, 3 or 4 depending upon which pod you have been assigned (A = 1, B = 2, C = 3, and D = 4).

In this lab part, you configure IS-IS to define the NET address on an active IS-IS interface. This address is typically configured on the loopback interface because it is always an active interface on the router. Use the following chart to determine the correct NET addresses for your student device.

Router Interface Network Entity Title

mxX-1 lo0.0 49.0001.1720.1600.1001.00

R3-1 lo0.1 49.0001.1720.1600.1002.00

mxX-2 lo0.0 49.0002.1720.1600.2001.00

R3-2 lo0.1 49.0002.1720.1600.2002.00



Step 2.1

Navigate to the [edit interfaces lo0] hierarchy and configure the two loopback interfaces in the default and virtual routing instances with the appropriate IS-IS NET address. Use unit 0 for your default instance and unit 1 for your R3-Y instance. Commit the configuration when completed.

[edit interfaces]lab@mxA-1# edit lo0

[edit interfaces lo0]lab@mxA-1# set unit 0 family iso address 49.000Y.1720.1600.Y001.00

[edit interfaces lo0]lab@mxA-1# set unit 1 family iso address 49.000Y.1720.1600.Y002.00

[edit interfaces lo0]lab@mxA-1# commitcommit complete

[edit interfaces lo0]lab@mxA-1#

Step 2.2

Use the run show interfaces lo0 terse command to verify that the loopback interfaces have the correct IS-IS NET address configured.

[edit interfaces lo0]lab@mxA-1# run show interfaces lo0 terse Interface Admin Link Proto Local Remotelo0 up up lo0.0 up up inet 172.16.1.1 --> 0/0 iso 49.0001.1720.1600.1001lo0.1 up up inet 172.16.1.2 --> 0/0 iso 49.0001.1720.1600.1002lo0.16384 up up inet 127.0.0.1 --> 0/0lo0.16385 up up inet

[edit interfaces lo0]lab@mxA-1#

Question: What is the IS-IS area configured on the loopback interfaces?

Answer: The answer will vary depending on your assigned device. Reading the NET address from right to left, the Net-Selector is 00, Sys-ID is 1720.1600.1001, and the area in the above capture is 49.0001



Part 3: Configuring Interfaces as Part of the IS-IS Protocol

In this lab part, you configure IS-IS on the participating interfaces under protocols isis. The IS-IS default operation for all configured interfaces is to form an adjacency in both Level 1 and Level 2 when possible.

Step 3.1

Navigate to the [edit protocols isis] hierarchy. In the default routing instance configure three interfaces: the loopback interface (lo0.0), the P1 interface (ge-1/0/0.11ZV) and the R3 routing instance interface (ge-1/0/4.0).

[edit interfaces lo0]lab@mxA-1# top edit protocols isis

[edit protocols isis]lab@mxA-1# set interface lo0.0

[edit protocols isis]lab@mxA-1# set interface ge-1/0/0.11ZV

[edit protocols isis]lab@mxA-1# set interface ge-1/0/4.0

[edit protocols isis]lab@mxA-1#

Step 3.2

Navigate to the [edit routing-instance R3-Y protocols isis] hierarchy and configure the loopback interface (lo0.1), and the interface to the default routing instance (ge-1/1/4.0). Commit the configuration when completed.

[edit protocols isis]lab@mxA-1# top edit routing-instances R3-Y protocols isis

[edit routing-instances R3-1 protocols isis]lab@mxA-1# set interface lo0.1

[edit routing-instances R3-1 protocols isis]lab@mxA-1# set interface ge-1/1/4.0

[edit routing-instances R3-1 protocols isis]lab@mxA-1# commitcommit complete

[edit routing-instances R3-1 protocols isis]lab@mxA-1#

Step 3.3

Use the run show isis interface command to verify IS-IS is active on the interfaces.



[edit routing-instances R3-1 protocols isis]lab@mxA-1# run show isis interface IS-IS interface database:Interface L CirID Level 1 DR Level 2 DR L1/L2 Metricge-1/0/0.1111 3 0x1 mxA-1.00 vr-device.02 10/10ge-1/0/4.0 3 0x1 1720.1600.1002.02 1720.1600.1002.02 10/10lo0.0 0 0x1 Passive Passive 0/0


Question: Which IS-IS levels are configured on the two interfaces, ge-1/0/0.11ZV and ge-1/0/4.0?

Answer: Both Level 1 and Level 2 are configured on these interfaces, which is shown by a 3 (1+2) in the “L” column.

Step 3.4

Use the run show isis adjacency command to verify IS-IS adjacencies in the default routing instance.

[edit routing-instances R3-1 protocols isis]lab@mxA-1# run show isis adjacency Interface System L State Hold (secs) SNPAge-1/0/0.1111 vr-device 2 Up 7 80:71:1f:c3:f7:60ge-1/0/4.0 1720.1600.1002 1 Up 7 80:71:1f:c3:3:7cge-1/0/4.0 1720.1600.1002 2 Up 6 80:71:1f:c3:3:7c


Question: How many adjacencies are formed on ge-1/0/0 and ge-1/0/4 interfaces? Why?

Answer: The ge-1/0/0.11ZV interface has only one adjacency, while the ge-1/0/4.0 interface has two adjacencies. Because they are not in the same IS-IS area, a Level 1 adjacency cannot be formed between the student device and the P1 device.



Step 3.5

Navigate to the [edit protocol isis] hierarchy. Disable IS-IS Level 1 on the interface between the default routing instance and the P1 router (ge-1/0/0.11ZV) and the interface between the two routing instances(ge-1/0/4.0).

[edit routing-instances R3-1 protocols isis]lab@mxA-1# top edit protocols isis

[edit protocols isis]lab@mxA-1# set interface ge-1/0/0.11ZV level 1 disable

[edit protocols isis]lab@mxA-1# set interface ge-1/0/4.0 level 1 disable


Step 3.6

Navigate to the [edit routing-instance R3-Y protocols isis] hierarchy and disable IS-IS Level 1 on the interface between the two routing instances (ge-1/1/4). Commit the configuration when completed.


[edit routing-instances R3-1 protocols isis]lab@mxA-1# set interface ge-1/1/4.0 level 1 disable



Step 3.7

Use the run show isis interface and run show isis adjacency commands in the default routing instance to verify that only one adjacency has been formed between the student device and the P1 router as well as between the routing instances.

[edit routing-instances R3-1 protocols isis]lab@mxA-1# run show isis interface IS-IS interface database:Interface L CirID Level 1 DR Level 2 DR L1/L2 Metricge-1/0/0.1111 2 0x1 Disabled vr-device.02 10/10ge-1/0/4.0 2 0x1 Disabled 1720.1600.1002.02 10/10lo0.0 0 0x1 Passive Passive 0/0

[edit routing-instances R3-1 protocols isis]lab@mxA-1# run show isis adjacency Interface System L State Hold (secs) SNPAge-1/0/0.1111 vr-device 2 Up 6 80:71:1f:c3:f7:60ge-1/0/4.0 1720.1600.1002 2 Up 8 80:71:1f:c3:3:7c




Question: Is Level 1 disabled on the interfaces between the student device and the P1 router and between the two routing instances?

Answer: Yes. The above capture shows Level 1 DR disabled on both ge-1/0/0.11ZV and ge-1/0/4.0. Also, a single Level 2 adjacency exists between the P1 router and routing instance.

Part 4: Migrating from OSPF to IS-IS

In this lab part, you change the IS-IS preference to make the OSPF routes less preferred than the IS-IS routes. You change this preference because the routing preference for OSPF internal routes is less than the IS-IS Level 2 internal routing preference; the OSPF routes will be preferred over the IS-IS routes. After the routing table has migrated to the IS-IS routes, you remove the OSPF configuration.

Step 4.1

Using the run show route 172.16/16 table inet.0 command, verify that the internal routes are using OSPF as the preferred routing protocol in the default routing instance (inet.0).

[edit routing-instances R3-1 protocols isis]lab@mxA-1# run show route 172.16/16 table inet.0


172.16.1.1/32 *[Direct/0] 1d 10:29:21 > via lo0.0172.16.1.2/32 *[OSPF/10] 00:16:38, metric 1 > to 10.0.10.2 via ge-1/0/4.0 [IS-IS/18] 00:00:39, metric 10 > to 10.0.10.2 via ge-1/0/4.0172.16.2.1/32 *[OSPF/10] 00:17:08, metric 2 > to 172.22.121.2 via ge-1/0/0.1111 [IS-IS/18] 00:08:00, metric 20 > to 172.22.121.2 via ge-1/0/0.1111172.16.2.2/32 *[OSPF/10] 00:16:38, metric 3 > to 10.0.10.2 via ge-1/0/4.0 [IS-IS/18] 00:08:00, metric 30 > to 172.22.121.2 via ge-1/0/0.1111




Question: What is the internal routing preference for OSPF? What is the internal routing preference for IS-IS?

Answer: The internal routing preference for OSPF is 10 and the internal routing preference for IS-IS is 18.

Step 4.2

Navigate to the [edit protocols ospf] hierarchy. In both your default instance and your R3-Y instance, change the OSPF internal preference to 20, which is higher than both the IS-IS Level 1 and Level 2 preference. Commit the changes when completed.

[edit routing-instances R3-1 protocols isis]lab@mxA-1# top edit protocols ospf

[edit protocols ospf]lab@mxA-1# set preference 20

[edit protocols ospf]lab@mxA-1# top set routing-instances R3-Y protocols ospf preference 20



Step 4.3

Use the run show route 172.16/16 table inet.0 command again to verify that the routes in the default routing instance now prefer IS-IS over OSPF.

[edit protocols ospf]lab@mxA-1# run show route 172.16/16 table inet.0


172.16.1.1/32 *[Direct/0] 1d 10:31:03 > via lo0.0172.16.1.2/32 *[IS-IS/18] 00:02:21, metric 10

Note

If you do not see the IS-IS route for the R3-Y loopback address immediately, issue the run clear isis database command to speed up the process.



> to 10.0.10.2 via ge-1/0/4.0 [OSPF/20] 00:00:29, metric 1 > to 10.0.10.2 via ge-1/0/4.0172.16.2.1/32 *[IS-IS/18] 00:09:42, metric 20 > to 172.22.121.2 via ge-1/0/0.1111 [OSPF/20] 00:00:29, metric 2 > to 172.22.121.2 via ge-1/0/0.1111172.16.2.2/32 *[IS-IS/18] 00:09:42, metric 30 > to 172.22.121.2 via ge-1/0/0.1111 [OSPF/20] 00:00:29, metric 3 > to 10.0.10.2 via ge-1/0/4.0


Question: Are the active routes in inet.0 now the IS-IS routes?

Answer: Yes, they are. The IS-IS Level 2 routing preference of 18 is now less than the explicitly configured OSPF preference of 20.

Step 4.4

Go to the top of the configuration hierarchy and delete protocols ospf from both routing instances. Commit the changes and exit to operational mode.

[edit protocols ospf]lab@mxA-1# top

[edit]lab@mxA-1# delete protocols ospf

[edit]lab@mxA-1# delete routing-instances R3-Y protocols ospf

[edit]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 4.5

Using the show route 172.16/16 table inet.0 command, verify that no OSPF routes are present in the default routing table.



lab@mxA-1> show route 172.16/16 table inet.0


172.16.1.1/32 *[Direct/0] 1d 10:32:25 > via lo0.0172.16.1.2/32 *[IS-IS/18] 00:03:43, metric 10 > to 10.0.10.2 via ge-1/0/4.0172.16.2.1/32 *[IS-IS/18] 00:11:04, metric 20 > to 172.22.121.2 via ge-1/0/0.1111172.16.2.2/32 *[IS-IS/18] 00:11:04, metric 30 > to 172.22.121.2 via ge-1/0/0.1111

lab@mxA-1>

Question: Are there any OSPF routes active in the inet.0 routing table?

Answer: No, all of the OSPF routes have disappeared from the default routing table.

Part 5: Examining the IS-IS Database

In this lab part, you examine both the IS-IS link state database (LSDB) and the shortest-path-first (SPF) tree database. The IS-IS LSDB data is input into the SPF algorithm and the algorithm creates two more databases, a candidate database and tree database. The candidate database is temporary and is deleted after the SPF calculation is complete. The SPF tree database is used to populate the local routing table.

Step 5.1

Use the show isis database command to display the IS-IS LSDB.

lab@mxA-1> show isis database IS-IS level 1 link-state database:LSP ID Sequence Checksum Lifetime AttributesmxA-1.00-00 0x5 0x87f7 1127 L1 L2 Attached 1 LSPs

IS-IS level 2 link-state database:LSP ID Sequence Checksum Lifetime AttributesmxA-1.00-00 0x8 0x34aa 1127 L1 L21720.1600.1002.00-00 0x7 0x4f52 1125 L1 L21720.1600.1002.02-00 0x4 0xefe3 1125 L1 L21720.1600.2001.00-00 0x7 0x2a6e 1136 L1 L2mxA-2.00-00 0x5 0xe97d 1134 L1 L2mxA-2.02-00 0x4 0x86fc 1135 L1 L2vr-device.00-00 0x7d 0x63a4 1175 L1 L2vr-device.02-00 0x2 0xe3a3 1036 L1 L2



vr-device.03-00 0x2 0x2145 1117 L1 L2 9 LSPs

lab@mxA-1>

Question: The mxA-1.00-00 LSP in the Level 1 database has the attach bit set. Why?

Answer: Any IS-IS router connected to both Level 1 and Level 2 will enable the attach bit in the Level 1 LSP. All routers in the Level 1 database will create a default route to the closest L1/L2 attached router.

Question: Why are there two mxA-1 and two mxA-2 LSPs?

Answer: In both cases, the mxA-1.00-00 and mxA-2.00-00 are the default LSPs advertising the local topology, while the mxA-1.02-00 and mxA-2.02-00 are the Designated Intermediate System (DIS) pseudo LSPs. Your output might show only one pseudo LSP for the main routing instance and one for the other routing-instance depending on which one was elected to be the DIS.

Step 5.2

Use the show isis database level 2 mxX-Y.00 extensive command to display the IS-IS header and the type/length/value (TLV) entries for the default routing instance LSP.

lab@mxA-1> show isis database level 2 mxX-Y.00 extensiveIS-IS level 2 link-state database:

mxA-1.00-00 Sequence: 0xc, Checksum: 0x21bb, Lifetime: 1007 secs IS neighbor: 1720.1600.1002.02 Metric: 10 Two-way fragment: 1720.1600.1002.02-00, Two-way first fragment:

1720.1600.1002.02-00 IS neighbor: vr-device.03 Metric: 10 Two-way fragment: vr-device.03-00, Two-way first fragment: vr-device.03-00 IP prefix: 10.0.10.0/24 Metric: 10 Internal Up IP prefix: 172.16.1.1/32 Metric: 0 Internal Up IP prefix: 172.22.121.0/24 Metric: 10 Internal Up

Header: LSP ID: mxA-1.00-00, Length: 202 bytes Allocated length: 1492 bytes, Router ID: 172.16.1.1



Remaining lifetime: 1007 secs, Level: 2, Interface: 0 Estimated free bytes: 1237, Actual free bytes: 1290 Aging timer expires in: 1007 secs Protocols: IP, IPv6

Packet: LSP ID: mxA-1.00-00, Length: 202 bytes, Lifetime : 1198 secs Checksum: 0x21bb, Sequence: 0xc, Attributes: 0x3 <L1 L2> NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 20, Packet version: 1, Max area: 0

TLVs: Area address: 49.0001 (3) Speaks: IP Speaks: IPV6 IP router id: 172.16.1.1 IP address: 172.16.1.1 Hostname: mxA-1 IS neighbor: vr-device.03, Internal, Metric: default 10 IS neighbor: 1720.1600.1002.02, Internal, Metric: default 10 IS extended neighbor: vr-device.03, Metric: default 10 IP address: 172.22.121.1 Local interface index: 328, Remote interface index: 0 IS extended neighbor: 1720.1600.1002.02, Metric: default 10 IP address: 10.0.10.1 Local interface index: 330, Remote interface index: 0 IP prefix: 172.22.121.0/24, Internal, Metric: default 10, Up IP prefix: 10.0.10.0/24, Internal, Metric: default 10, Up IP prefix: 172.16.1.1/32, Internal, Metric: default 0, Up IP extended prefix: 172.22.121.0/24 metric 10 up IP extended prefix: 10.0.10.0/24 metric 10 up IP extended prefix: 172.16.1.1/32 metric 0 up No queued transmissions

lab@mxA-1>

Question: Which protocols are supported in this LSP?

Answer: Both IP and IPV6 are supported in this LSP.

Question: Under the TLV section, your router’s loopback address is being advertised in which two TLVs?

Answer: The IP prefix, TLV 128, and the IP extended prefix, TLV 135.



Step 5.3

Use the show isis route command to display the SPF tree database.

lab@mxA-1> show isis route IS-IS routing table Current version: L1: 14 L2: 15IPv4/IPv6 Routes----------------Prefix L Version Metric Type Interface NH Via10.0.14.0/24 2 15 30 int ge-1/0/0.1111 IPV4 vr-device 172.16.1.2/32 2 15 10 int ge-1/0/4.0 IPV4 1720.1600.1002 172.16.2.1/32 2 15 20 int ge-1/0/0.1111 IPV4 vr-device 172.16.2.2/32 2 15 30 int ge-1/0/0.1111 IPV4 vr-device 172.22.122.0/24 2 15 20 int ge-1/0/0.1111 IPV4 vr-device 172.22.252.0/30 2 15 20 int ge-1/0/0.1111 IPV4 vr-device 172.31.100.1/32 2 15 10 int ge-1/0/0.1111 IPV4 vr-device 172.31.101.1/32 2 15 20 int ge-1/0/0.1111 IPV4 vr-device

lab@mxA-1>

Question: The IS-IS tree table shows the output of the SPF algorithm. Examine the entry for prefix that matches your R3-Y’s loopback address. Which database installed the route and from which LSP?

Answer: They results will vary but, in the previous output, the 172.16.1.2/32 entry was installed from LSP 1720.1600.1002 in the Level 2 database.

Step 5.4


lab@mxA-1> exit



Lab 5Advanced IS-IS Configuration and Routing Policy (Detailed)

Overview

In this lab, you will use the lab diagram titled “Lab 5: Advanced IS-IS Configuration and Routing Policy” to establish an extended IS-IS Level 2 routing domain. This extended network will allow implementation and monitoring of some of the IS-IS advanced configuration options. In addition, this lab will provide further insight into the IS-IS database with the redistribution of external routes.



• Manipulate routing using various metrics.

• Authenticate IS-IS hello packets.

• Explore the use of the overload bit.

• Redistribute routes between IS-IS and RIP.

www.juniper.net Advanced IS-IS Configuration and Routing Policy (Detailed) • Lab 5–111.a.11.4R1.14


Part 1: Building the Extended IS-IS Topology

The extended IS-IS topology, as outlined in the lab diagram, consists of four virtual routing instances in each of the student devices.

Step 1.1


Step 1.2


Note



Lab 5–2 • Advanced IS-IS Configuration and Routing Policy (Detailed) www.juniper.net


mxA-1 (ttyu0)

login: labPassword:


Step 1.3





[edit]lab@mxA-1#

Step 1.4

Use the run show isis interface and run show isis adjacency commands to verify that the new extended IS-IS topology has been loaded into the student device.

[edit]lab@mxA-1# run show isis interface IS-IS interface database:Interface L CirID Level 1 DR Level 2 DR L1/L2 Metricge-1/0/0.1111 2 0x1 Disabled vr-device.02 10/10ge-1/0/4.0 2 0x1 Disabled 1720.1600.1002.02 10/10ge-1/0/5.0 2 0x1 Disabled 1720.1600.1003.02 10/10lo0.0 0 0x1 Passive Passive 0/0

[edit]lab@mxA-1# run show isis adjacency Interface System L State Hold (secs) SNPAge-1/0/0.1111 vr-device 2 Up 8 80:71:1f:c3:f7:60ge-1/0/4.0 1720.1600.1002 2 Up 8 80:71:1f:c3:3:7cge-1/0/5.0 1720.1600.1003 2 Up 8 80:71:1f:c3:3:7d

[edit]lab@mxA-1#

www.juniper.net Advanced IS-IS Configuration and Routing Policy (Detailed) • Lab 5–3


Step 1.5







Use the run show isis interface instance R5-Y command to verify that the new extended IS-IS topology has been loaded into the student device.

[edit]lab@mxA-1# run show isis interface instance R5-Y IS-IS interface database:Interface L CirID Level 1 DR Level 2 DR L1/L2 Metricge-1/1/6.0 2 0x2 Disabled 1720.1600.1004.02 10/10ge-1/1/7.0 2 0x3 Disabled 1720.1600.1004.03 10/10lo0.3 0 0x1 Passive Passive 0/0

[edit]lab@mxA-1#

Step 1.6

Use the run show isis adjacency instance R5-Y command to verify that the new extended IS-IS topology has been loaded into the student device.

[edit]lab@mxA-1# run show isis adjacency instance R5-Y Interface System L State Hold (secs) SNPAge-1/1/6.0 1720.1600.1002 2 Up 21 80:71:1f:c3:3:66ge-1/1/7.0 1720.1600.1003 2 Up 20 80:71:1f:c3:3:67

[edit]lab@mxA-1#

Question: Are all the Level 2 IS-IS adjacencies established?

Answer: Yes. All of the Level 2 IS-IS adjacencies are established.



Question: Are any Level 1 IS-IS adjacencies established?

Answer: No. No Level 1 IS-IS adjacencies are established.

Step 1.7

Use the run show isis database command to examine the current IS-IS LSDB.

[edit]lab@mxA-1# run show isis database IS-IS level 1 link-state database:LSP ID Sequence Checksum Lifetime AttributesmxA-1.00-00 0x6 0x85f8 1163 L1 L2 Attached 1 LSPs

IS-IS level 2 link-state database:LSP ID Sequence Checksum Lifetime AttributesmxA-1.00-00 0x73 0xc70 438 L1 L21720.1600.1002.00-00 0x71 0x8353 1001 L1 L21720.1600.1002.02-00 0x4 0xefe3 1130 L1 L21720.1600.1003.00-00 0x5 0x96a1 437 L1 L21720.1600.1003.02-00 0x3 0x1ab7 437 L1 L21720.1600.1004.00-00 0x6 0x4be4 1128 L1 L21720.1600.1004.02-00 0x4 0x8645 954 L1 L21720.1600.1004.03-00 0x4 0xc503 1159 L1 L21720.1600.2001.00-00 0x6 0x3348 455 L1 L2mxA-2.00-00 0x6 0x835b 1001 L1 L2mxA-2.02-00 0x3 0x88fb 380 L1 L21720.1600.2003.00-00 0x5 0x953f 454 L1 L21720.1600.2003.02-00 0x3 0xb0d0 454 L1 L21720.1600.2004.00-00 0x5 0x9b32 378 L1 L21720.1600.2004.02-00 0x4 0x1d5e 996 L1 L21720.1600.2004.03-00 0x3 0x5e1b 386 L1 L2vr-device.00-00 0x36d 0x8e86 1172 L1 L2vr-device.02-00 0x4 0x2441 1130 L1 L2vr-device.03-00 0x4 0xd8ab 1172 L1 L2 19 LSPs

[edit]lab@mxA-1#



Question: All of the IS-IS adjacencies are IS-IS Level 2. Why is there an LSP in the IS-IS Level 1 database?

Answer: Each IS-IS router maintains a complete LSDB for each level configured. Because Level 1 has not been globally disabled, an LSP is created within the Level 1 database for the routing instance.

Question: Why is the attach bit set on the Level 1 LSP?

Answer: The primary routing instance has a Level 2 connection to two different IS-IS areas: IS-IS Area 49.0001 and ISIS Area 49.1234. Any router with a connection to two different IS-IS areas will turn on the attach bit in all Level 1 LSPs. This setting allows all Level 1 routers to create a default route to the closest L1/L2 attached router.

Part 2: Configuring IS-IS Authentication

IS-IS has three methods of authentication: none (default), simple authentication, and MD5 authentication. In addition, IS-IS authentication can be performed at the global or interface level hierarchy. The global level authenticates all IS-IS packets, hello, link-state, and sequence number PDUs generated by the router. The interface level authentication only authenticates the hello PDU generated by the router. In this lab part, you configure MD5 hello-authentication in the Level 2 interface hierarchy between the default routing instance and the two adjacent virtual routing instances.

Step 2.1

Navigate to the [edit protocols isis] hierarchy. Using md5 as the type and juniper as the key, configure Level 2 hello-authentication on the interface that is connected to the R3-Y routing instance.

[edit]lab@mxA-1# edit protocols isis

[edit protocols isis]lab@mxA-1# set interface ge-1/0/4.0 level 2 hello-authentication-type md5

[edit protocols isis]lab@mxA-1# set interface ge-1/0/4.0 level 2 hello-authentication-key juniper




Using md5 as the type and juniper as the key, configure Level 2 hello-authentication on the interface that is connected to the R4-Y routing instance.

[edit protocols isis]lab@mxA-1# set interface ge-1/0/5.0 level 2 hello-authentication-type md5

[edit protocols isis]lab@mxA-1# set interface ge-1/0/5.0 level 2 hello-authentication-key juniper


Step 2.2

Navigate to the [edit routing-instance R3-Y protocols isis] hierarchy. Using md5 as the type and juniper as the key, configure level 2 hello-authentication on the interface that is connected to the default routing instance.


[edit routing-instances R3-1 protocols isis]lab@mxA-1# set interface ge-1/1/4.0 level 2 hello-authentication-type md5

[edit routing-instances R3-1 protocols isis]lab@mxA-1# set interface ge-1/1/4.0 level 2 hello-authentication-key juniper


Step 2.3

Navigate to the [edit routing-instance R4-Y protocols isis] hierarchy. Using md5 as the type and juniper as the key, configure Level 2 hello-authentication on the interface that is connected to the default routing instance. Commit the changes and return to operational mode.

[edit routing-instances R3-1 protocols isis]lab@mxA-1# up 3 edit R4-Y protocols isis

[edit routing-instances R4-1 protocols isis]lab@mxA-1# set interface ge-1/1/5.0 level 2 hello-authentication-type md5

[edit routing-instances R4-1 protocols isis]lab@mxA-1# set interface ge-1/1/5.0 level 2 hello-authentication-key juniper

[edit routing-instances R4-1 protocols isis]lab@mxA-1# commit and-quitcommit completeExiting configuration mode

lab@mxA-1>



Step 2.4

Use the monitor traffic interface command to verify that the IS-IS hello packets are using the MD5 authentication. Use the Ctrl+c key sequence to stop the monitor output after a couple of seconds.

lab@mxA-1> monitor traffic interface ge-1/0/4.0 detail no-resolveAddress resolution is OFF.Listening on ge-1/0/4, capture size 1514 bytes

07:18:33.571466 In IS-IS, length 75 L2 Lan IIH, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) source-id: 1720.1600.1002, holding time: 9s, Flags: [Level 2 only] lan-id: 1720.1600.1002.02, Priority: 64, PDU length: 75 IS Neighbor(s) TLV #6, length: 6 SNPA: 8071.1fc3.0364 Protocols supported TLV #129, length: 2 NLPID(s): IPv4 (0xcc), IPv6 (0x8e) IPv4 Interface address(es) TLV #132, length: 4 IPv4 interface address: 10.0.10.2 Area address(es) TLV #1, length: 4 Area address (length: 3): 49.0001 Restart Signaling TLV #211, length: 3 Flags [none], Remaining holding time 0s Authentication TLV #10, length: 17 HMAC-MD5 password: ce5ad4e22cafe2aacadecf80290c8193^C1 packets received by filter0 packets dropped by kernel

lab@mxA-1>

Question: Which TLV carries the authentication key in the hello packet?

Answer: The authentication key is carried in TLV #10 in the IS-IS hello packet.

Step 2.5

Use the show isis adjacency command to verify that the IS-IS adjacencies are established using the hello-authentication configuration.

lab@mxA-1> show isis adjacency Interface System L State Hold (secs) SNPAge-1/0/0.1111 vr-device 2 Up 8 80:71:1f:c3:f7:60ge-1/0/4.0 1720.1600.1002 2 Up 7 80:71:1f:c3:3:7cge-1/0/5.0 1720.1600.1003 2 Up 6 80:71:1f:c3:3:7d

lab@mxA-1>



Question: What is the state of the IS-IS adjacencies with the MD5 authentication configured?

Answer: The three adjacencies are in the Up state with the authentication configured.

Part 3: Manipulating IS-IS Metrics

Several methods of manipulating routes exist within IS-IS. By changing the metrics on the IS-IS interfaces, default routing behavior can be affected. In this lab part, you explore some of these methods.

Step 3.1

Use the show isis interface command to examine the default metrics assigned to the IS-IS interfaces.

lab@mxA-1> show isis interfaceIS-IS interface database:Interface L CirID Level 1 DR Level 2 DR L1/L2 Metricge-1/0/0.1111 2 0x1 Disabled vr-device.02 10/10ge-1/0/4.0 2 0x1 Disabled 1720.1600.1002.02 10/10ge-1/0/5.0 2 0x1 Disabled 1720.1600.1003.02 10/10lo0.0 0 0x1 Passive Passive 0/0

lab@mxA-1>

Question: What is the default Level 1 and Level 2 metric for all Gigabit Ethernet interfaces?

Answer: The default Level 1 and Level 2 metric is 10 for all Gigabit Ethernet interfaces.

Step 3.2

Use the show route 172.16.Y.4/32 table inet.0 command to display the loopback interface of the R5-Y routing instance within your student device in the default routing table. Note that there are two equal cost paths and the Junos OS has chosen one of them.

lab@mxA-1> show route 172.16.Y.4/32 table inet.0




172.16.1.4/32 *[IS-IS/18] 00:11:52, metric 20 to 10.0.11.2 via ge-1/0/5.0 > to 10.0.10.2 via ge-1/0/4.0

lab@mxA-1>

Question: What is the cost to reach the 172.16.Y.4/32 network?

Answer: The route has an equal cost of 20 between the two intermediate nodes.

Step 3.3

Enter configuration mode and navigate to the [edit protocols isis] hierarchy. Use the reference-bandwidth command to change the default metric. Use 1 gigabit as the calculating bandwidth. Commit the change when completed.


[edit]lab@mxA-1# edit protocols isis

[edit protocols isis]lab@mxA-1# set reference-bandwidth 1g

[edit protocols isis]lab@mxA-1# commit commit complete


Step 3.4

Use the run show isis interface command to verify that the change in metric of the IS-IS Level 2 interfaces.

[edit protocols isis]lab@mxA-1# run show isis interface IS-IS interface database:Interface L CirID Level 1 DR Level 2 DR L1/L2 Metricge-1/0/0.1111 2 0x1 Disabled vr-device.02 1/1ge-1/0/4.0 2 0x1 Disabled 1720.1600.1002.02 1/1ge-1/0/5.0 2 0x1 Disabled 1720.1600.1003.02 1/1lo0.0 0 0x1 Passive Passive 0/0




Question: What has happened to the Level 1 and Level 2 metrics on the IS-IS interfaces?

Answer: The Level 1 and Level 2 metrics have changed from the default of 10 to a cost of 1. The reference-bandwidth command takes the calculating bandwidth (1 Gbps) and divides it by the static interface bandwidth (1 Gbps). The result is a cost of 1.

Step 3.5

Use the run show route 172.16.Y.4/32 table inet.0 command to display the loopback of your device’s R5 routing instance from the perspective of the default routing instance.

[edit protocols isis]lab@mxA-1# run show route 172.16.Y.4/32 table inet.0




Question: What is the cost to reach the 172.16.Y.4/32 network?

Answer: The cost to reach the remote network has changed from 20 to 11.

Step 3.6

On the ge-1/0/5.0 interface connecting the default routing instance to the R4-Y, change the Level 2 metric to 1000. Commit the change when completed.

[edit protocols isis]lab@mxA-1# set interface ge-1/0/5.0 level 2 metric 1000





Step 3.7

Use the run show isis interface command to examine the metrics now assigned to the IS-IS interfaces.

[edit protocols isis]lab@mxA-1# run show isis interface IS-IS interface database:Interface L CirID Level 1 DR Level 2 DR L1/L2 Metricge-1/0/0.1111 2 0x1 Disabled vr-device.02 1/1ge-1/0/4.0 2 0x1 Disabled 1720.1600.1002.02 1/1ge-1/0/5.0 2 0x1 Disabled 1720.1600.1003.02 1/1000lo0.0 0 0x1 Passive Passive 0/0


Step 3.8

Use the run show route 172.16.Y.4/32 table inet.0 to display the loopback of your device’s R5 routing instance from the perspective of the default routing instance.



172.16.1.4/32 *[IS-IS/18] 00:01:01, metric 11 > to 10.0.10.2 via ge-1/0/4.0


Question: What has happened to the route?

Answer: Because of the metric change, there is now only one possible path to the R5-Y node. The configured Level 2 metric is more specific than the reference-bandwidth command and therefore will take precedence in the configuration. The higher metric will also cause all routing to the remote network to go through the other remote node.

Step 3.9

Enable IS-IS overload on the R3-Y routing-instance, which is the active intermediate node to the R5-Y routing instance. Commit the change when completed.



[edit protocols isis]lab@mxA-2# top set routing-instances R3-Y protocols isis overload



Step 3.10

Use the run show isis database level 2 command to ensure that the overload bit has been enabled in the LSP.

[edit protocols isis]lab@mxA-1# run show isis database level 2 IS-IS level 2 link-state database:LSP ID Sequence Checksum Lifetime AttributesmxA-1.00-00 0x26 0xee4b 1173 L1 L21720.1600.1002.00-00 0x22 0x130f 1171 L1 L2 Overload1720.1600.1002.02-00 0x1c 0xbffb 1171 L1 L21720.1600.1003.00-00 0x15 0x5bcc 1171 L1 L21720.1600.1003.02-00 0xe 0x4c2 1171 L1 L21720.1600.1004.00-00 0x14 0xa57c 1169 L1 L21720.1600.1004.02-00 0xf 0x7050 1169 L1 L21720.1600.1004.03-00 0xe 0xb10d 1169 L1 L21720.1600.2001.00-00 0x1e 0x9e35 1182 L1 L21720.1600.2002.00-00 0x1c 0x4282 1180 L1 L2 Overload1720.1600.2002.02-00 0x1a 0x5a13 1180 L1 L21720.1600.2003.00-00 0xf 0x8a40 1181 L1 L21720.1600.2003.02-00 0xb 0xa0d8 1181 L1 L2mxA-2.00-00 0x10 0xd0f1 1179 L1 L2mxA-2.02-00 0xb 0xf65 1179 L1 L2mxA-2.03-00 0xb 0x4e23 1179 L1 L2vr-device.00-00 0x157 0xaa82 969 L1 L2vr-device.02-00 0x16 0xff53 1016 L1 L2vr-device.03-00 0x17 0xb2be 969 L1 L2 19 LSPs


Question: How can you tell if the overload bit is enabled?

Answer: The word “Overload” will be in the attributes column.

Step 3.11

Verify that the route has moved to the R4-Y routing instance using the run show route 172.16.Y.4/32 table inet.0 command.







Question: The IS-IS Level 2 interface has a metric of 1000 configured. Why is the metric to the remote network 73?

Answer: TLV 128 only has 6 bits it can use for the metric value of the prefix. Therefore, the highest metric value that can be advertised in the TLV is 63. The remote network cost is 63 plus 10, or 73.

Step 3.12

Use the run show isis database level 2 mxX-Y.00 extensive | find tlv command to display the TLVs that are being advertised in the default routing instance LSP.

[edit protocols isis]lab@mxA-1# run show isis database level 2 mxX-Y.00 extensive | find tlv TLVs: Area address: 49.0001 (3) Speaks: IP Speaks: IPV6 IP router id: 172.16.1.1 IP address: 172.16.1.1 Hostname: mxA-1 IS neighbor: vr-device.03, Internal, Metric: default 1 IS neighbor: 1720.1600.1002.02, Internal, Metric: default 1 IS neighbor: 1720.1600.1003.02, Internal, Metric: default 63 IS extended neighbor: vr-device.03, Metric: default 1 IP address: 172.22.121.1 Local interface index: 328, Remote interface index: 0 IS extended neighbor: 1720.1600.1002.02, Metric: default 1 IP address: 10.0.10.1 Local interface index: 330, Remote interface index: 0 IS extended neighbor: 1720.1600.1003.02, Metric: default 63 IP address: 10.0.11.1 Local interface index: 338, Remote interface index: 0 IP prefix: 172.22.121.0/24, Internal, Metric: default 1, Up IP prefix: 10.0.10.0/24, Internal, Metric: default 1, Up



IP prefix: 10.0.11.0/24, Internal, Metric: default 63, Up IP prefix: 172.16.1.1/32, Internal, Metric: default 0, Up IP extended prefix: 172.22.121.0/24 metric 1 up IP extended prefix: 10.0.10.0/24 metric 1 up IP extended prefix: 10.0.11.0/24 metric 63 up IP extended prefix: 172.16.1.1/32 metric 0 up No queued transmissions


Question: The IP extended prefix TLV (#135) has 4 octets for a metric value. Why is the metric value on the adjacent interface set to 63 when the metric value is configured at 1000?

Answer: When both the IP prefix (TLV #128) and the IP extended prefix (TLV #135) are advertised, the narrow metric will always be used in the SPF calculation. Therefore, both metrics are set to the maximum value of 63.

Step 3.13

Enable wide-metrics-only for Level 2 interfaces on the default routing instance. Commit the configuration when completed.

[edit protocols isis]lab@mxA-1# set level 2 wide-metrics-only



Step 3.14

Use the run show isis database level 2 mxX-Y.00 extensive | find tlv command to display the TLVs that are now being advertised in the default routing instance LSP.

[edit protocols isis]lab@mxA-1# run show isis database level 2 mxX-Y.00 extensive | find tlv TLVs: Area address: 49.0001 (3) Speaks: IP Speaks: IPV6 IP router id: 172.16.1.1 IP address: 172.16.1.1



Hostname: mxA-1 IS extended neighbor: vr-device.03, Metric: default 1 IP address: 172.22.121.1 Local interface index: 328, Remote interface index: 0 IS extended neighbor: 1720.1600.1002.02, Metric: default 1 IP address: 10.0.10.1 Local interface index: 330, Remote interface index: 0 IS extended neighbor: 1720.1600.1003.02, Metric: default 1000 IP address: 10.0.11.1 Local interface index: 338, Remote interface index: 0 IP extended prefix: 172.22.121.0/24 metric 1 up IP extended prefix: 10.0.10.0/24 metric 1 up IP extended prefix: 10.0.11.0/24 metric 1000 up IP extended prefix: 172.16.1.1/32 metric 0 up No queued transmissions


Question: What is the metric value in the IP extended prefix (TLV #135) on the adjacent interface?

Answer: It is now 1000. The narrow TLVs (TLV #2 and TLV #128) are no longer being advertised in the LSP. Therefore, the configured metric value can be advertised within the 4-byte metric field in the extended TLV #135.

Step 3.15

Use the run show route 172.16.Y.4/32 table inet.0 command to display the route to the R5 routing instance loopback address.







Question: What is the cost to the remote network now?

Answer: Using the wide-metric TLVs in the SPF calculation will result in a cost of 1010.

Part 4: Configuring IS-IS External Reachability

In this lab part, you configure external routes to be redistributed into IS-IS using routing policy. An external connection to a RIP network must be established. Once established, you create a RIP import policy to only accept routes from the RIP router that have a prefix-length of /24. These routes are redistributed into IS-IS and a default route is advertised into RIP.

Step 4.1

Navigate to the [edit routing-instances R5-Y] hierarchy. Add the ge-1/0/0.11ZV interface that connects the P3 device to your R5-Y routing instance.

[edit protocols isis]lab@mxA-1# top edit routing-instances R5-Y

[edit routing-instances R5-1]lab@mxA-1# set interface ge-1/0/0.11ZV


Step 4.2

Navigate to the [edit routing-instances R5-Y protocols rip group P3] hierarchy. Add the interface connected to the P3 router as a neighbor in the P3 group. Commit your changes when complete.

[edit routing-instances R5-1]lab@mxA-1# edit protocols rip group P3

[edit routing-instances R5-1 protocols rip group P3]lab@mxA-1# set neighbor ge-1/0/0.11ZV

[edit routing-instances R5-1 protocols rip group P3]lab@mxA-1# commit commit complete

[edit routing-instances R5-1 protocols rip group P3]lab@mxA-1#



Step 4.3

Verify that a RIP neighbor has been established with the P3 router using the run show rip neighbor instance R5-Y command. Also, use the run show route receive-protocol rip 172.22.12V.2 table R5-Y.inet.0 command to view all routes being received from the RIP router.

[edit routing-instances R5-1 protocols rip group P3]lab@mxA-1# run show rip neighbor instance R5-Y Source Destination Send Receive InNeighbor State Address Address Mode Mode Met -------- ----- ------- ----------- ---- ------- --- ge-1/0/0.1115 Up 172.22.125.1 224.0.0.9 mcast both 1

[edit routing-instances R5-1 protocols rip group P3]lab@mxA-1# run show route receive-protocol rip 172.22.12V.2 table R5-Y.inet.0


20.20.0.0/21 *[RIP/100] 00:02:38, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.0.0/24 *[RIP/100] 00:02:38, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.1.0/24 *[RIP/100] 00:02:38, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.2.0/24 *[RIP/100] 00:02:38, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.3.0/24 *[RIP/100] 00:02:38, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.4.0/25 *[RIP/100] 00:02:38, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.4.128/25 *[RIP/100] 00:02:38, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.5.0/26 *[RIP/100] 00:02:38, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.5.64/26 *[RIP/100] 00:02:38, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.5.128/26 *[RIP/100] 00:02:38, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.5.192/26 *[RIP/100] 00:02:38, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.1115


Note

Remember, when executing a show command for a routing-instance, the instance and table key words are required to view information within the routing-instance.



Question: Is the RIP neighbor established? What is the RIP version 2 destination multicast address?

Answer: The RIP neighbor is established with a source address of 172.22.125.Y. The RIP version 2 multicast destination address is 224.0.0.9.

Step 4.4

Navigate to the [edit policy-options policy-statement import-rip-routes] hierarchy. Create a policy to accept only RIP routes with a prefix-length of /24. No other RIP routes should be accepted.

[edit routing-instances R5-1 protocols rip group P3]lab@mxA-1# top edit policy-options policy-statement import-rip-routes

[edit policy-options policy-statement import-rip-routes]lab@mxA-1# set term 1 from protocol rip

[edit policy-options policy-statement import-rip-routes]lab@mxA-1# set term 1 from route-filter 0/0 prefix-length-range /24-/24

[edit policy-options policy-statement import-rip-routes]lab@mxA-1# set term 1 then accept

[edit policy-options policy-statement import-rip-routes]lab@mxA-1# set term 2 then reject

[edit policy-options policy-statement import-rip-routes]lab@mxA-1# show term 1 { from { protocol rip; route-filter 0.0.0.0/0 prefix-length-range /24-/24; } then accept;}term 2 { then reject;}

[edit policy-options policy-statement import-rip-routes]lab@mxA-1#

Step 4.5

Navigate to [edit routing-instances R5-Y], apply the import-rip-routes policy as an import policy to the RIP group P3 and commit the changes.

[edit policy-options policy-statement import-rip-routes]lab@mxA-1# top edit routing-instances R5-Y



[edit routing-instances R5-1]lab@mxA-1# set protocols rip group P3 import import-rip-routes

[edit routing-instances R5-1]lab@mxA-1# commitcommit complete


Step 4.6

Verify that the policy is working by using the run show route receive-protocol rip 172.22.12V.2 table R5-Y.inet.0 command to view all routes being received from the RIP router.



20.20.0.0/24 *[RIP/100] 00:05:55, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.1.0/24 *[RIP/100] 00:05:55, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.2.0/24 *[RIP/100] 00:05:55, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.3.0/24 *[RIP/100] 00:05:55, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.1115

R5-1.iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)


Question: Is the RIP import routing policy accepting only routes with a prefix-length of /24?

Answer: Yes. The import policy is accepting only the four routes with a prefix-length of /24?

Step 4.7

Navigate to the [edit policy-options policy-statement export-rip-default] hierarchy. Configure the policy to advertise a default route.

[edit routing-instances R5-1]lab@mxA-1# top edit policy-options policy-statement export-rip-default

[edit policy-options policy-statement export-rip-default]lab@mxA-1# set term 1 from route-filter 0/0 exact



[edit policy-options policy-statement export-rip-default]lab@mxA-1# set term 1 then accept

[edit policy-options policy-statement export-rip-default]lab@mxA-1#

Step 4.8

Navigate to the [edit routing-instances R5-Y protocols rip group P3] hierarchy, apply the export-rip-default policy as a RIP export policy under group P3 and commit the changes.

[edit]lab@mxA-1# top edit routing-instances R5-Y protocols rip group P3

[edit routing-instances R5-1 protocols rip group P3]lab@mxA-1# set export export-rip-default


[edit routing-instances R5-1 protocols rip group P3]lab@mxA-1>#

Step 4.9

Use the run show route advertising-protocol rip 172.22.12V.1 table R5-Y.inet.0 command to display the routes that are being advertised to the RIP network.

[edit routing-instances R5-1 protocols rip group P3]lab@mxA-1# run show route advertising-protocol rip 172.22.12V.1 table

R5-Y.inet.0


Question: Is the export routing policy advertising the default route?

Answer: According to the above capture, no routes are being advertised to the RIP network.

Step 4.10

Use the run show route 0/0 exact table R5-Y.inet.0 and run show isis database instance R5-Y commands to provide you with the reason why the default route is not being advertised to the RIP network.



[edit routing-instances R5-1 protocols rip group P3]lab@mxA-1# run show route 0/0 exact table R5-Y.inet.0

[edit routing-instances R5-1 protocols rip group P3]lab@mxA-1# run show isis database instance R5-Y IS-IS level 1 link-state database:LSP ID Sequence Checksum Lifetime Attributes1720.1600.1004.00-00 0xe 0xcf2e 645 L1 L2 Attached 1 LSPs

IS-IS level 2 link-state database:LSP ID Sequence Checksum Lifetime AttributesmxA-1.00-00 0x2e 0xf22c 641 L1 L21720.1600.1002.00-00 0x2a 0x317 643 L1 L2 Overload1720.1600.1002.02-00 0x24 0xaf04 643 L1 L21720.1600.1003.00-00 0x1d 0x4bd4 643 L1 L21720.1600.1003.02-00 0x16 0xf3ca 643 L1 L21720.1600.1004.00-00 0x1c 0x9584 645 L1 L21720.1600.1004.02-00 0x17 0x6058 645 L1 L21720.1600.1004.03-00 0x16 0xa115 645 L1 L21720.1600.2001.00-00 0x26 0x8b56 654 L1 L21720.1600.2002.00-00 0x24 0x328a 652 L1 L2 Overload1720.1600.2002.02-00 0x22 0x4a1b 652 L1 L21720.1600.2003.00-00 0x17 0x7a48 652 L1 L21720.1600.2003.02-00 0x13 0x90e0 652 L1 L2mxA-2.00-00 0x18 0xc0f9 650 L1 L2mxA-2.02-00 0x13 0xfe6d 650 L1 L2mxA-2.03-00 0x13 0x3e2b 651 L1 L2vr-device.00-00 0x15e 0x9c89 1034 L1 L2vr-device.02-00 0x1d 0xf15a 1034 L1 L2vr-device.03-00 0x1e 0xa4c5 917 L1 L2 19 LSPs


Question: Why is no default route active in the R5-Y routing table?

Answer: Because only IS-IS Level 2 adjacencies have been established and the attach bit is set only on the IS-IS Level 1 LSP of the L1/L2 attached router, the default route is not created in the routing table of the routing instances.

Step 4.11

Create an aggregate default route in the R5-Y routing instance and commit the change.



[edit routing-instances R5-1 protocols rip group P3]lab@mxA-1# up 3 set routing-options aggregate route 0/0



Step 4.12

Use the run show route advertising-protocol rip 172.22.12V.1 table R5-Y.inet.0 command to verify that the default route is now being advertised to the RIP network.

[edit routing-instances R5-1 protocols rip group P3]lab@mxA-1# run show route advertising-protocol rip 172.22.12V.1 table

R5-Y.inet.0


0.0.0.0/0 *[Aggregate/130] 00:00:55 Reject


Question: Is the default route being advertised to the RIP network?

Answer: Yes.The default aggregate route is being advertised to the RIP network.

Step 4.13

Navigate to the [edit policy-options policy-statement export-rip-to-isis] hierarchy. Configure the export-rip-to-isis policy to advertise the RIP routes as IS-IS external Type 1 routes.

[edit routing-instances R5-1 protocols rip group P3]lab@mxA-1# top edit policy-options policy-statement export-rip-to-isis

[edit policy-options policy-statement export-rip-to-isis]lab@mxA-1# set term 1 from protocol rip

[edit policy-options policy-statement export-rip-to-isis]lab@mxA-1# set term 1 then external type 1

[edit policy-options policy-statement export-rip-to-isis]



lab@mxA-1# set term 1 then accept

[edit policy-options policy-statement export-rip-to-isis]lab@mxA-1#

Step 4.14

Navigate to the [edit routing-instances R5-Y] hierarchy. Apply the export-rip-to-isis policy as an export policy to IS-IS and commit the changes and return to operational mode.

[edit policy-options policy-statement export-rip-to-isis]lab@mxA-1# top edit routing-instances R5-Y

[edit routing-instances R5-1]lab@mxA-1# set protocols isis export export-rip-to-isis

[edit routing-instances R5-1]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 4.15

Use the show route 20.20/22 table inet.0 command to verify that the RIP routes are active in the default inet.0 routing table as IS-IS external routes.



20.20.0.0/24 *[IS-IS/165] 00:01:43, metric 1012 > to 10.0.11.2 via ge-1/0/5.020.20.1.0/24 *[IS-IS/165] 00:01:43, metric 1012 > to 10.0.11.2 via ge-1/0/5.020.20.2.0/24 *[IS-IS/165] 00:01:43, metric 1012 > to 10.0.11.2 via ge-1/0/5.020.20.3.0/24 *[IS-IS/165] 00:01:43, metric 1012 > to 10.0.11.2 via ge-1/0/5.0

lab@mxA-1>

Question: Are the RIP routes installed in the default inet.0 routing instance as active IS-IS external routes?

Answer: Yes, the four RIP routes are active IS-IS external routes in the primary routing instance.



Step 4.16


lab@mxA-1> exit





Lab 6Configuring a Multilevel IS-IS Network (Detailed)

Overview

In this lab, you will use the lab diagram titled “Lab 6: Configuring a Multilevel IS-IS Network” to establish a multilevel IS-IS network. This diagram will provide you with the topology to explore the default operation of a multilevel IS-IS environment, including the flooding scope through the L1/L2 attached router. It will also provide you with the means to change these default operations using routing policies.



• Establish a multilevel IS-IS network.

• Explore the default flooding scope between L1 and L2.

• Explore the use of the attach bit.

• Use routing policy to summarize routes from L1 to L2.

• Redistribute external routes from L1 to L2.

• Use routing policies to leak routes from L2 to L1.

www.juniper.net Configuring a Multilevel IS-IS Network (Detailed) • Lab 6–111.a.11.4R1.14


Part 1: Establishing the Multilevel IS-IS Network

In this lab part, you establish the multilevel IS-IS network. The multilevel IS-IS topology, as outlined in the lab diagram, consists of four virtual routing instances in each of the student devices.

Step 1.1


Step 1.2


Note



Lab 6–2 • Configuring a Multilevel IS-IS Network (Detailed) www.juniper.net


mxA-1 (ttyu0)

login: labPassword:


Step 1.3





lab@mxA-1>

Step 1.4

Use the show isis interface and show isis adjacency commands to verify the state of the new extended IS-IS topology in the default routing instance.

lab@mxA-1> show isis interfaceIS-IS interface database:Interface L CirID Level 1 DR Level 2 DR L1/L2 Metricge-1/0/0.1111 2 0x1 Disabled vr-device.02 10/10ge-1/0/4.0 2 0x1 Disabled 1720.1600.1002.02 10/10ge-1/0/5.0 2 0x1 Disabled 1720.1600.1003.02 10/10lo0.0 0 0x1 Passive Passive 0/0

lab@mxA-1> show isis adjacency Interface System L State Hold (secs) SNPAge-1/0/0.1111 vr-device 2 Up 7 80:71:1f:c3:f7:60ge-1/0/4.0 1720.1600.1002 2 Up 6 80:71:1f:c3:3:7cge-1/0/5.0 1720.1600.1003 2 Up 7 80:71:1f:c3:3:7d

lab@mxA-1>

www.juniper.net Configuring a Multilevel IS-IS Network (Detailed) • Lab 6–3


Question: How many adjacencies does the default routing instance have, and at what level are these adjacencies formed?

Answer: The default routing instance has three IS-IS Level 2 adjacencies. No Level 1 adjacencies are in the default routing instance.

Step 1.5







Use the show isis interface instance R3-Y and show isis adjacency instance R3-Y commands to verify the state of the new extended IS-IS topology in the R3-Y routing instance.

lab@mxA-1> show isis interface instance R3-YIS-IS interface database:Interface L CirID Level 1 DR Level 2 DR L1/L2 Metricge-1/0/6.0 1 0x1 1720.1600.1004.03 Disabled 10/10ge-1/1/4.0 2 0x2 Disabled 1720.1600.1002.02 10/10lo0.1 0 0x1 Passive Passive 0/0

lab@mxA-1> show isis adjacency instance R3-YInterface System L State Hold (secs) SNPAge-1/0/6.0 1720.1600.1004 1 Up 7 80:71:1f:c3:3:7ege-1/1/4.0 mxA-1 2 Up 24 80:71:1f:c3:3:64

lab@mxA-1>



Question: How many adjacencies exist on the R3-Y routing instances? At what level are these adjacencies?

Answer: The R3-Y routing instance has two adjacencies. One adjacency is Level 2 on the interface to the default routing instance and the second is a Level 1 adjacency to the R5-Y routing instance.

Step 1.6


lab@mxA-1> show isis interface instance R4-YIS-IS interface database:Interface L CirID Level 1 DR Level 2 DR L1/L2 Metricge-1/0/7.0 1 0x1 1720.1600.1004.02 Disabled 10/10ge-1/1/5.0 2 0x2 Disabled 1720.1600.1003.02 10/10lo0.2 0 0x1 Passive Passive 0/0

lab@mxA-1> show isis adjacency instance R4-YInterface System L State Hold (secs) SNPAge-1/0/7.0 1720.1600.1004 1 Up 7 80:71:1f:c3:3:7fge-1/1/5.0 mxA-1 2 Up 26 80:71:1f:c3:3:65

lab@mxA-1>

Question: How many adjacencies exist on the R4-Y routing instances? At what level are these adjacencies?

Answer: The R4-Y routing instance has two adjacencies. One adjacency is Level 2 on the interface to the default routing instance and the second is a Level 1 adjacency to the R5-Y routing instance.

Step 1.7


lab@mxA-1> show isis interface instance R5-YIS-IS interface database:



Interface L CirID Level 1 DR Level 2 DR L1/L2 Metricge-1/1/6.0 1 0x3 1720.1600.1004.03 Disabled 10/10ge-1/1/7.0 1 0x2 1720.1600.1004.02 Disabled 10/10lo0.3 0 0x1 Passive Passive 0/0

lab@mxA-1> show isis adjacency instance R5-YInterface System L State Hold (secs) SNPAge-1/1/6.0 1720.1600.1002 1 Up 23 80:71:1f:c3:3:66ge-1/1/7.0 1720.1600.1003 1 Up 20 80:71:1f:c3:3:67

lab@mxA-1>

Question: How many adjacencies exist on the R5-Y routing instance? At what level are these adjacencies?

Answer: The R5-Y router has two adjacencies, both at IS-IS Level 1.

Part 2: Examining the IS-IS Multilevel Flooding Scope

In this lab part, you examine the default flooding scope of a multilevel IS-IS topology and then modify that default flooding scope. The IS-IS multilevel topology supports multiple IS-IS databases, a Level 1 database and a Level 2 database. Because the R3-Y and R4-Y routing instances have interfaces connected to both a Level 1 and Level 2, they have both databases. Information that is passed between these databases is known as the IS-IS flooding scope. IS-IS, by default, floods all Level 1 internal information into the Level 2 database but not Level 2 internal information into the Level 1 database. Also, by default, IS-IS does not flood any external information between either database.

Step 2.1

The default routing instance only has IS-IS Level 2 adjacencies. Use the show route 172.16/16 table inet.0 command to display all active loopback addresses in the Level 2 database.



172.16.1.1/32 *[Direct/0] 1d 12:18:34 > via lo0.0172.16.1.2/32 *[IS-IS/18] 00:28:52, metric 10 > to 10.0.10.2 via ge-1/0/4.0172.16.1.3/32 *[IS-IS/18] 00:28:52, metric 10 > to 10.0.11.2 via ge-1/0/5.0172.16.1.4/32 *[IS-IS/18] 00:00:55, metric 20 > to 10.0.11.2 via ge-1/0/5.0 to 10.0.10.2 via ge-1/0/4.0



172.16.2.1/32 *[IS-IS/18] 00:28:52, metric 20 > to 172.22.121.2 via ge-1/0/0.1111172.16.2.2/32 *[IS-IS/18] 00:28:41, metric 30 > to 172.22.121.2 via ge-1/0/0.1111172.16.2.3/32 *[IS-IS/18] 00:28:41, metric 30 > to 172.22.121.2 via ge-1/0/0.1111172.16.2.4/32 *[IS-IS/18] 00:28:40, metric 40 > to 172.22.121.2 via ge-1/0/0.1111

lab@mxA-1>

Question: Within the multilevel IS-IS topology, are any loopback addresses missing from the default routing instance routing table?

Answer: No. All loopback addresses are active in the default routing table as IS-IS Level 2 routes with a routing preference of 18. The R5-Y internal loopback address has been leaked into the Level 2 database through the R3-Y and R4-Y L1/L2 attached routers.

Step 2.2

The R5-Y routing instance only has IS-IS Level 1 adjacencies. Use the show route 172.16/16 table R5-Y.inet.0 command to display all active loopback address in the Level 1 database.

lab@mxA-1> show route 172.16/16 table R5-Y.inet.0


172.16.1.2/32 *[IS-IS/15] 00:29:29, metric 10 > to 10.0.12.1 via ge-1/1/6.0172.16.1.3/32 *[IS-IS/15] 00:29:29, metric 10 > to 10.0.13.1 via ge-1/1/7.0172.16.1.4/32 *[Direct/0] 01:35:08 > via lo0.3

lab@mxA-1>



Question: How many loopback addresses are active IS-IS routes in the R5-Y routing table? Are any of the routes from the Level 2 routing instances? Why?

Answer: The R5-Y routing table has only three loopback addresses in the routing table and none of the routes are from the IS-IS Level 2 database. By default, routes are not leaked from the Level 2 database into the Level 1 database.

Step 2.3

Because the internal Level 2 IS-IS routes are not leaked into the Level 1 database, access from the R5-Y router to the Level 2 routes requires a default route. Use the show route 0/0 exact table R5-Y.inet.0 command to display the active default route in the R5-Y routing table.

lab@mxA-1> show route 0/0 exact table R5-Y.inet.0


0.0.0.0/0 *[IS-IS/15] 00:02:03, metric 10 to 10.0.13.1 via ge-1/1/7.0 > to 10.0.12.1 via ge-1/1/6.0 [Aggregate/130] 00:49:10 Reject

lab@mxA-1>

Question: Is the default route an active IS-IS route in the R5-Y.inet.0 routing table? Is it an internal or external route?

Answer: The default route is an active internal Level 1 IS-IS route with a routing preference of 15.

Step 2.4

All L1/L2 attached routers enable the attach bit on their Level 1 LSP if the Level 2 adjacency is in a different IS-IS area. Display the Level 1 database using the show isis database level 1 instance R5-Y command.

lab@mxA-1> show isis database level 1 instance R5-YIS-IS level 1 link-state database:LSP ID Sequence Checksum Lifetime Attributes1720.1600.1002.00-00 0x18 0x9be2 1030 L1 L2 Attached



1720.1600.1003.00-00 0x12 0x7c05 1030 L1 L2 Attached1720.1600.1004.00-00 0x13 0x8a7a 1032 L1 L21720.1600.1004.02-00 0x4 0xccfc 1032 L1 L21720.1600.1004.03-00 0x4 0x7f4b 1032 L1 L2 5 LSPs

lab@mxA-1>

Question: Which routers have enabled the attach bit in their Level 1 LSP?

Answer: The R3-Y and R4-Y routers have enabled the attach bit in their Level 1 LSP. Every router in the Level 1 domain will create a default route to the closest L1/L2 attached router.

Question: What is the primary LSP ID for the R5-Y routing instance in the IS-IS Level 1 database?

Question: Your results might vary. Based on the previous output, the LSP-ID for the R5-Y routing instance is 1720.1600.1004.00.

Step 2.5

Use the show route protocol rip table R5-Y.inet.0 command to verify that RIP routes are being received from the P3 RIP network.

lab@mxA-1> show route protocol rip table R5-Y.inet.0


20.20.0.0/24 *[RIP/100] 01:02:13, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.1.0/24 *[RIP/100] 01:02:13, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.2.0/24 *[RIP/100] 01:02:13, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.111520.20.3.0/24 *[RIP/100] 01:02:13, metric 2, tag 0 > to 172.22.125.2 via ge-1/0/0.1115224.0.0.9/32 *[RIP/100] 00:03:48, metric 1 MultiRecv


lab@mxA-1>



Step 2.6

Use the primary LSP-ID defined previously to display the IS-IS database for the R5-Y link-state PDU to verify that the RIP routes have been redistributed into IS-IS as external Type 130 TLVs. Use the show isis database level 1 1720.1600.Y004.00 extensive instance R5-Y | find tlv command to display these TLVs.

lab@mxA-1> show isis database level 1 1720.1600.Y004.00 extensive instance R5-Y | find tlv

TLVs: Area address: 49.0001 (3) Speaks: IP Speaks: IPV6 Hostname: mxA-1 IP prefix: 10.0.12.0/24, Internal, Metric: default 10, Up IP prefix: 10.0.13.0/24, Internal, Metric: default 10, Up IP prefix: 172.16.1.4/32, Internal, Metric: default 0, Up IP extended prefix: 10.0.12.0/24 metric 10 up IP extended prefix: 10.0.13.0/24 metric 10 up IP extended prefix: 172.16.1.4/32 metric 0 up IP external prefix: 20.20.0.0/24, Internal, Metric: default 2, Up IP external prefix: 20.20.1.0/24, Internal, Metric: default 2, Up IP external prefix: 20.20.2.0/24, Internal, Metric: default 2, Up IP external prefix: 20.20.3.0/24, Internal, Metric: default 2, Up IP extended prefix: 20.20.0.0/24 metric 2 up IP extended prefix: 20.20.1.0/24 metric 2 up IP extended prefix: 20.20.2.0/24 metric 2 up IP extended prefix: 20.20.3.0/24 metric 2 up IS neighbor: 1720.1600.1004.02, Internal, Metric: default 10 IS neighbor: 1720.1600.1004.03, Internal, Metric: default 10 IS extended neighbor: 1720.1600.1004.02, Metric: default 10 IS extended neighbor: 1720.1600.1004.03, Metric: default 10 No queued transmissions

lab@mxA-1>

Question: Are the RIP routes installed in the R5-Y IS-IS LSP as external Type 130 TLVs?

Answer: The four RIP routes are installed in the R5-Y LSP as Type 130 TLVs (IP external prefix) and as Type 135 TLVs (IP extended prefix). Because both the external and extended TLVs exist, only the TLV 130 values are used in the SPF algorithm.

Step 2.7

Display the RIP routes in the default routing table using the show route 20.20/22 table inet.0 command.




lab@mxA-1>

Question: Are the RIP routes present in the default routing table? Why?

Answer: The RIP routes are not present in the default routing table because, by default, external routes are not leaked between the Level 1 database and the Level 2 database.

Part 3: Modifying the Default Flooding Scope

The default IS-IS flooding scope can be modified using routing policy. Because the R3-Y and R4-Y routing instances provide connectivity to both the Level 1 and Level 2 databases, export policy can be applied to the IS-IS protocol to direct routes into a specific database. In this lab, you write and apply IS-IS export policy in the R3-Y and R4-Y routing instances to change the default IS-IS flooding scope.

Step 3.1

IS-IS Level 1 internal routes are redistributed into the Level 2 database by default. Use the show route 10.0.1W.0/23 table inet.0 command to display the Level 1 interface routes connected to the R5-Y router in the default routing table. Variable W will be 2 for mxX-1 and 6 for mxX-2.

lab@mxA-1> show route 10.0.1W.0/23 table inet.0


10.0.12.0/24 *[IS-IS/18] 00:39:32, metric 20 > to 10.0.10.2 via ge-1/0/4.010.0.13.0/24 *[IS-IS/18] 00:39:32, metric 20 > to 10.0.11.2 via ge-1/0/5.0

lab@mxA-1>

Step 3.2

Enter configuration mode and navigate to the [edit routing-instances R3-Y routing-options] hierarchy. Configure a 10.0.1W.0/23 aggregate route in the R3-Y routing instance. Variable W will be 2 for mxX-1 and 6 for mxX-2.


[edit]lab@mxA-1# edit routing-instances R3-Y routing-options

[edit routing-instances R3-1 routing-options]



lab@mxA-1# set aggregate route 10.0.1W.0/23

[edit routing-instances R3-1 routing-options]lab@mxA-1#

Step 3.3

Navigate to the [edit routing-instances R4-Y routing-options] hierarchy. Configure a 10.0.1W.0/23 aggregate route in the R4-Y routing instance. Variable W will be 2 for mxX-1 and 6 for mxX-2.

[edit routing-instances R3-1 routing-options]lab@mxA-1# up 2 edit R4-Y routing-options

[edit routing-instances R4-1 routing-options]lab@mxA-1# set aggregate route 10.0.1W.0/23


Step 3.4

Navigate to the [edit policy-options policy-statement summarize-level-1] hierarchy. Create a routing policy to summarize the two Level 1 10.0.1W.0/24 routes into a single 10.0.1W.0/23 route, send them to Level 2 and, finally, suppress the more specific routes. Variable W will be 2 for mxX-1 and 6 for mxX-2.

[edit routing-instances R4-1 routing-options]lab@mxA-1# top edit policy-options policy-statement summarize-level-1

[edit policy-options policy-statement summarize-level-1]lab@mxA-1# set term 1 from protocol aggregate

[edit policy-options policy-statement summarize-level-1]lab@mxA-1# set term 1 from route-filter 10.0.1W.0/23 exact

[edit policy-options policy-statement summarize-level-1]lab@mxA-1# set term 1 to level 2

[edit policy-options policy-statement summarize-level-1]lab@mxA-1# set term 1 then accept

[edit policy-options policy-statement summarize-level-1]lab@mxA-1# set term 2 from route-filter 10.0.1W.0/23 longer

[edit policy-options policy-statement summarize-level-1]lab@mxA-1# set term 2 to level 2

[edit policy-options policy-statement summarize-level-1]lab@mxA-1# set term 2 then reject

[edit policy-options policy-statement summarize-level-1]lab@mxA-1# showterm 1 { from { protocol aggregate;



route-filter 10.0.12.0/23 exact; } to level 2; then accept;}term 2 { from { route-filter 10.0.12.0/23 longer; } to level 2; then reject;}

[edit policy-options policy-statement summarize-level-1]lab@mxA-1#

Step 3.5

Navigate to the [edit routing-instances R3-Y protocols isis] hierarchy and apply the policy named summarize-level-1 as an export policy.

[edit policy-options policy-statement summarize-level-1]lab@mxA-1# top edit routing-instances R3-Y protocols isis

[edit routing-instances R3-1 protocols isis]lab@mxA-1# set export summarize-level-1


Step 3.6

Navigate to the [edit routing-instances R4-Y protocols isis] hierarchy and apply the policy named summarize-level-1 as an export policy. Commit the changes when completed.


[edit routing-instances R4-1 protocols isis]lab@mxA-1# set export summarize-level-1



Step 3.7

Use the run show route 10.0.1W.0/23 table inet.0 command to verify that the Level 1 internal routes have been summarized into the 10.0.1W.0/23 route. Variable W will be 2 for mxX-1 and 6 for mxX-2.

[edit routing-instances R4-1 protocols isis]lab@mxA-1# run show route 10.0.1W.0/23 table inet.0






Question: Are the Level 1 routes being summarized in the Level 2 database?

Answer: Yes, the 10.0.1W.0/23 summary route is an active IS-IS external route in the default routing table as seen in the previous output and the more specific /24 internal Level 1 routes have been suppressed.

Step 3.8

Navigate to the [edit policy-options policy-statement rip-to-level-2] hierarchy. Configure the rip-to-level-2 policy to accept all routes more specific than 20.20.0.0/22 into the Level 2 database.

[edit routing-instances R4-1 protocols isis]lab@mxA-1# top edit policy-options policy-statement rip-to-level-2

[edit policy-options policy-statement rip-to-level-2]lab@mxA-1# set term 1 from route-filter 20.20.0.0/22 longer

[edit policy-options policy-statement rip-to-level-2]lab@mxA-1# set term 1 to level 2

[edit policy-options policy-statement rip-to-level-2]lab@mxA-1# set term 1 then accept

[edit policy-options policy-statement rip-to-level-2]lab@mxA-1# showterm 1 { from { route-filter 20.20.0.0/22 longer; } to level 2; then accept;}

[edit policy-options policy-statement rip-to-level-2]lab@mxA-1#



Step 3.9

Navigate to the [edit routing-instances R3-Y protocols isis] hierarchy and apply the rip-to-level-2 policy as an export policy.

[edit policy-options policy-statement rip-to-level-2]lab@mxA-1# top edit routing-instances R3-Y protocols isis

[edit routing-instances R3-1 protocols isis]lab@mxA-1# set export rip-to-level-2


Step 3.10

Navigate to the [edit routing-instances R4-Y protocols isis] hierarchy and apply the rip-to-level-2 policy as an export policy. Commit the configuration when completed.


[edit routing-instances R4-1 protocols isis]lab@mxA-1# set export rip-to-level-2

[edit routing-instances R4-1 protocols isis]lab@mxA-1# commit commit complete


Step 3.11

Use the run show route 20.20/22 table inet.0 command to verify that the RIP routes have been injected into the Level 2 database and SPF installed them in the default routing table.

[edit routing-instances R4-1 protocols isis]lab@mxA-1# run show route 20.20/22 table inet.0


20.20.0.0/24 *[IS-IS/165] 00:03:50, metric 22 to 10.0.11.2 via ge-1/0/5.0 > to 10.0.10.2 via ge-1/0/4.020.20.1.0/24 *[IS-IS/165] 00:03:50, metric 22 to 10.0.11.2 via ge-1/0/5.0 > to 10.0.10.2 via ge-1/0/4.020.20.2.0/24 *[IS-IS/165] 00:03:50, metric 22 > to 10.0.11.2 via ge-1/0/5.0 to 10.0.10.2 via ge-1/0/4.020.20.3.0/24 *[IS-IS/165] 00:03:50, metric 22 to 10.0.11.2 via ge-1/0/5.0 > to 10.0.10.2 via ge-1/0/4.0




Question: Are the RIP routes active routes in the default routing table? What protocol preference is assigned to the routes? Why?

Answer: Yes. The RIP routes are active IS-IS routes in the default routing table. The routes have a protocol preference of 165, the preference assigned to external Level 2 routes.

Step 3.12

Navigate to the [edit policy-options policy-statement level2-to-level1] hierarchy. Configure the level2-to-level1 policy to accept all IS-IS Level 2 routes into Level 1.

[edit routing-instances R4-1 protocols isis]lab@mxA-1# top edit policy-options policy-statement level2-to-level1

[edit policy-options policy-statement level2-to-level1]lab@mxA-1# set term 1 from protocol isis

[edit policy-options policy-statement level2-to-level1]lab@mxA-1# set term 1 from level 2

[edit policy-options policy-statement level2-to-level1]lab@mxA-1# set term 1 to level 1

[edit policy-options policy-statement level2-to-level1]lab@mxA-1# set term 1 then accept

[edit policy-options policy-statement level2-to-level1]lab@mxA-1# showterm 1 { from { protocol isis; level 2; } to level 1; then accept;}

[edit policy-options policy-statement level2-to-level1]lab@mxA-1#

Step 3.13

Navigate to the [edit routing-instances R3-Y protocols isis] hierarchy and apply the level2-to-level1 policy as an export policy.



[edit policy-options policy-statement level2-to-level1]lab@mxA-1# top edit routing-instances R3-Y protocols isis

[edit routing-instances R3-1 protocols isis]lab@mxA-1# set export level2-to-level1


Step 3.14

Navigate to the [edit routing-instances R4-Y protocols isis] hierarchy and apply the level2-to-level1 policy as an export policy. Commit the configuration and return to operational mode.


[edit routing-instances R4-1 protocols isis]lab@mxA-1# set export level2-to-level1

[edit routing-instances R4-1 protocols isis]lab@mxA-1# commit and-quitcommit completeExiting configuration mode

lab@mxA-1>

Step 3.15

Verify that the IS-IS Level 2 routes have been leaked into the IS-IS Level 1 database and installed in the R5-Y routing table. Use the show route 172.16/16 table R5-Y.inet.0 command to display the routes in the R5-Y routing table.

lab@mxA-1> show route 172.16/16 table R5-Y.inet.0


172.16.1.1/32 *[IS-IS/18] 00:00:57, metric 20 > to 10.0.13.1 via ge-1/1/7.0 to 10.0.12.1 via ge-1/1/6.0172.16.1.2/32 *[IS-IS/15] 01:49:57, metric 10 > to 10.0.12.1 via ge-1/1/6.0172.16.1.3/32 *[IS-IS/15] 01:49:57, metric 10 > to 10.0.13.1 via ge-1/1/7.0172.16.1.4/32 *[Direct/0] 02:55:36 > via lo0.3172.16.2.1/32 *[IS-IS/18] 00:00:57, metric 40 > to 10.0.13.1 via ge-1/1/7.0 to 10.0.12.1 via ge-1/1/6.0172.16.2.2/32 *[IS-IS/18] 00:00:57, metric 50 to 10.0.13.1 via ge-1/1/7.0 > to 10.0.12.1 via ge-1/1/6.0172.16.2.3/32 *[IS-IS/18] 00:00:57, metric 50 to 10.0.13.1 via ge-1/1/7.0 > to 10.0.12.1 via ge-1/1/6.0




lab@mxA-1>

Question: Have the Level 2 routes been leaked into the Level 1 database and installed in the R5-Y routing table? What is the protocol preference of the leaked routes in the routing table?

Answer: Yes. The Level 2 routes have been leaked into the Level 1 database and SPF has installed the routes in the R5-Y routing table. The protocol preference of the leaked routes is 18, the internal preference for Level 2 routes.

Step 3.16

Use the show isis database level 1 instance R3-Y command to locate the R3-Y LSP-ID in the Level 1 IS-IS database.

lab@mxA-1> show isis database level 1 instance R3-YIS-IS level 1 link-state database:LSP ID Sequence Checksum Lifetime Attributes1720.1600.1002.00-00 0x1f 0x2032 1038 L1 L2 Attached1720.1600.1003.00-00 0x19 0xec6a 1038 L1 L2 Attached1720.1600.1004.00-00 0x1a 0x619c 1040 L1 L21720.1600.1004.02-00 0xb 0xbe04 1040 L1 L21720.1600.1004.03-00 0xb 0x7152 1040 L1 L2 5 LSPs

lab@mxA-1>

Question: What is the LSP-ID of the primary LSP for the R3-Y router?

Answer: Your results might vary. Based on the previous output, the primary LSP-ID of the R3-Y router is 1720.1600.1002.00-00.



Step 3.17

Use the LSP-ID located in the previous step to display the TLVs inserted by the level2-to-level1 export policy. Enter the show isis database level 1 1720.1600.Y002.00-00 extensive instance R3-Y | find tlv command to display the TLVs in the R3-Y LSP.

lab@mxA-1> show isis database level 1 1720.1600.Y002.00-00 extensive instance R3-Y | find tlv

TLVs: Area address: 49.0001 (3) Speaks: IP Speaks: IPV6 Hostname: mxA-1 IS neighbor: 1720.1600.1004.02, Internal, Metric: default 10 IS extended neighbor: 1720.1600.1004.02, Metric: default 10 IP prefix: 172.16.1.2/32, Internal, Metric: default 0, Up IP prefix: 10.0.12.0/24, Internal, Metric: default 10, Up IP prefix: 10.0.11.0/24, Internal, Metric: default 20, Down IP prefix: 10.0.14.0/24, Internal, Metric: default 40, Down IP prefix: 10.0.15.0/24, Internal, Metric: default 40, Down IP prefix: 172.16.1.1/32, Internal, Metric: default 10, Down IP prefix: 172.16.2.1/32, Internal, Metric: default 30, Down IP prefix: 172.16.2.2/32, Internal, Metric: default 40, Down IP prefix: 172.16.2.3/32, Internal, Metric: default 40, Down IP prefix: 172.16.2.4/32, Internal, Metric: default 50, Down IP prefix: 172.22.121.0/24, Internal, Metric: default 20, Down IP prefix: 172.22.122.0/24, Internal, Metric: default 30, Down IP prefix: 172.22.252.0/30, Internal, Metric: default 30, Down IP prefix: 172.31.100.1/32, Internal, Metric: default 20, Down IP prefix: 172.31.101.1/32, Internal, Metric: default 30, Down IP extended prefix: 172.16.1.2/32 metric 0 up IP extended prefix: 10.0.12.0/24 metric 10 up IP extended prefix: 10.0.11.0/24 metric 20 down IP extended prefix: 10.0.14.0/24 metric 40 down IP extended prefix: 10.0.15.0/24 metric 40 down IP extended prefix: 172.16.1.1/32 metric 10 down IP extended prefix: 172.16.2.1/32 metric 30 down IP extended prefix: 172.16.2.2/32 metric 40 down IP extended prefix: 172.16.2.3/32 metric 40 down IP extended prefix: 172.16.2.4/32 metric 50 down IP extended prefix: 172.22.121.0/24 metric 20 down IP extended prefix: 172.22.122.0/24 metric 30 down IP extended prefix: 172.22.252.0/30 metric 30 down IP extended prefix: 172.31.100.1/32 metric 20 down IP extended prefix: 172.31.101.1/32 metric 30 down IP external prefix: 10.0.16.0/23, Internal, Metric: default 50, Down IP extended prefix: 10.0.16.0/23 metric 50 down No queued transmissions

lab@mxA-1>



Question: The Type 128 TLVs leaked into the Level 1 database have the “down” bit set. What is the function of this bit?

Answer: Because the default IS-IS flooding scope is to leak Level 1 internal Type 128 TLVs into the Level 2 database, the down bit is set in order to prevent routing loops. IS-IS Level 1 Type 128 TLVs with the down bit set are never leaked back into the Level 2 database as a loop detection mechanism.

Step 3.18


lab@mxA-1> exit



Lab 7BGP (Detailed)

Overview

In this lab, you will use the lab diagram titled “Lab 7-9: BGP and BGP Attributes” to establish a BGP network. The student device is divided into two routing instances running OSPF. After verifying the OSPF Area 0.0.0.0 adjacency, an IBGP session must be established between the default routing instance and the R3 routing instance. The P1 and P2 routers are in AS 65412, and the P3 router is in AS 65020. You must establish EBGP peering sessions to all three of the routers. The P3 EBGP peering session will peer to the loopback addresses.

This lab will require the configuration of both internal and EBGP peering sessions.


• Load the default configuration.

• Establish an IBGP peering session.

• Establish an EBGP peering session with multipath.

• Establish an EBGP peering session with multihop.

• Use policy to summarize IBGP routes.

www.juniper.net BGP (Detailed) • Lab 7–111.a.11.4R1.14


Part 1: Establishing the OSPF Adjacency

In this lab part, you load the Lab 7 reset configuration and establish an OSPF adjacency between the default routing instance and the R3 routing instance.

Step 1.1


Step 1.2


Note



Lab 7–2 • BGP (Detailed) www.juniper.net


mxA-1 (ttyu0)

login: labPassword:


Step 1.3



[edit]lab@mxA-1# load override ajspr/lab7-start.configload complete


lab@mxA-1>

Step 1.4

Use the show ospf interface command to verify that the interfaces are running OSPF.

lab@mxA-1> show ospf interfaceInterface State Area DR ID BDR ID Nbrsge-1/0/4.0 BDR 0.0.0.0 172.16.1.2 172.16.1.1 1lo0.0 DR 0.0.0.0 172.16.1.1 0.0.0.0 0

lab@mxA-1>

Question: How many many neighbors does interface ge-1/0/4.0 have?

Answer: It should have only one neighbor.

Step 1.5

Use the show ospf neighbor command to verify that the default routing instance has an adjacency with the R3 instance.

www.juniper.net BGP (Detailed) • Lab 7–3


lab@mxA-1> show ospf neighborAddress Interface State ID Pri Dead10.0.10.2 ge-1/0/4.0 Full 172.16.1.2 128 35

lab@mxA-1>

Question: Which neighbor state is shown for the ge-1/0/4.0 interface?

Answer: The neighbor state for the ge-1/0/4.0 interface should be Full, as shown in the sample output. If the state is not Full, check with your instructor.

Step 1.6







Use the ping utility to verify reachability to the directly connected interfaces of the P1, P2, and P3 routers. Remember to use the routing-instance command for the P3 device.

lab@mxA-1> ping 172.22.12V.2 rapid count 10PING 172.22.121.2 (172.22.121.2): 56 data bytes!!!!!!!!!!--- 172.22.121.2 ping statistics ---10 packets transmitted, 10 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.419/0.440/0.590/0.050 ms

lab@mxA-1> ping 172.22.12V.2 rapid count 10PING 172.22.123.2 (172.22.123.2): 56 data bytes!!!!!!!!!!--- 172.22.123.2 ping statistics ---10 packets transmitted, 10 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.415/0.451/0.595/0.053 ms

lab@mxA-1> ping 172.22.12V.2 rapid count 10 routing-instance R3-Y



PING 172.22.125.2 (172.22.125.2): 56 data bytes!!!!!!!!!!--- 172.22.125.2 ping statistics ---10 packets transmitted, 10 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.418/0.437/0.544/0.036 ms

lab@mxA-1>

Question: Are the ping tests successful?

Answer: Yes, the ping tests should be successful at this time. If your tests are not successful, check with your instructor.

Step 1.7

Use the show route table inet.0 command to display the default routing table.

lab@mxA-1> show route table inet.0


10.0.10.0/24 *[Direct/0] 1d 04:47:18 > via ge-1/0/4.010.0.10.1/32 *[Local/0] 1d 04:47:18 Local via ge-1/0/4.010.210.15.0/27 *[Direct/0] 1d 04:47:18 > via fxp0.010.210.15.1/32 *[Local/0] 1d 04:47:18 Local via fxp0.0172.16.1.0/26 *[Static/5] 00:16:03 Reject172.16.1.1/32 *[Direct/0] 1d 04:47:18 > via lo0.0172.16.1.2/32 *[OSPF/10] 1d 00:12:28, metric 1 > to 10.0.10.2 via ge-1/0/4.0172.16.1.64/26 *[Static/5] 00:16:03 Reject172.22.121.0/24 *[Direct/0] 1d 04:47:18 > via ge-1/0/0.1111172.22.121.1/32 *[Local/0] 1d 04:47:18 Local via ge-1/0/0.1111172.22.123.0/24 *[Direct/0] 1d 04:47:18 > via ge-1/0/0.1113172.22.123.1/32 *[Local/0] 1d 04:47:18 Local via ge-1/0/0.1113224.0.0.5/32 *[OSPF/10] 1d 02:34:18, metric 1 MultiRecv

lab@mxA-1>



Question: Are your two loopback addresses active in the default routing table?

Answer: Yes. The loopback addresses are active in the default routing table. The R3-Y loopback is an active OSPF route and the default loopback is a direct route.

Part 2: Establishing an IBGP Peering Session

In this lab part, you configure the Internal BGP (IBGP) session between the default routing instance and the R3-Y routing instance. The IBGP session should use loopback addresses for peering between the two instances. After configuring the IBGP group, verify that the session is established and redistribute the two static routes configured in the [edit routing-options] hierarchy.

Step 2.1

The autonomous system (AS) number must be configured in both routing instances. Enter configuration mode, navigate to the [edit routing-options] and configure the AS number 6500Y for the default routing instance.


[edit]lab@mxA-1# edit routing-options

[edit routing-options]lab@mxA-1# set autonomous-system 6500Y

[edit routing-options]lab@mxA-1#

Step 2.2

Navigate to the [edit routing-instances R3-Y routing-options] hierarchy and configure the same AS number for the R3-Y routing instance.

[edit routing-options]lab@mxA-1# top edit routing-instances R3-Y routing-options

[edit routing-instances R3-1 routing-options]lab@mxA-1# set autonomous-system 6500Y


Step 2.3

Navigate to the [edit protocols bgp] hierarchy and configure a BGP group named ibgp that establishes an IBGP peering session with the R3-Y loopback address. Refer to the network diagram for this lab as necessary.



[edit routing-instances R3-1 routing-options]lab@mxA-1# top edit protocols bgp

[edit protocols bgp]lab@mxA-1# set group ibgp type internal

[edit protocols bgp]lab@mxA-1# set group ibgp local-address 172.16.Y.1

[edit protocols bgp]lab@mxA-1# set group ibgp neighbor 172.16.Y.2

[edit protocols bgp]lab@mxA-1#

Step 2.4

Navigate to the [edit routing-instances R3-Y protocols bgp] hierarchy and configure a BGP group named ibgp that establishes an IBGP peering session with the default routing instance. Commit the configuration when completed.

[edit protocols bgp]lab@mxA-1# top edit routing-instances R3-Y protocols bgp

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# set group ibgp type internal

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# set group ibgp local-address 172.16.Y.2

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# set group ibgp neighbor 172.16.Y.1

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# commit commit complete

[edit routing-instances R3-1 protocols bgp]lab@mxA-1#

Step 2.5

Use the run show bgp summary command to verify that the IBGP session has been established.

lab@mxA-1# run show bgp summary Groups: 2 Peers: 2 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn

State|#Active/Received/Accepted/Damped...172.16.1.1 65001 3 3 0 0 9 Establ R3-1.inet.0: 0/0/0/0172.16.1.2 65001 2 3 0 0 9 0/

0/0/0 0/0/0/0




Question: Is the IBGP session established? Are any BGP routes being exchanged between the peers?

Answer: The IBGP session is established between the two routing instances. If the peering session is not established, check your configuration and if necessary consult with your instructor. The 0/0/0/0 identifies the Active/Received/Accepted/Damped routes; therefore, no active BGP routes are being exchanged at this time.

Step 2.6

Locate the two static routes in the each of the routing instances using the run show route protocol static command.

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# run show route protocol static


172.16.1.0/26 *[Static/5] 00:17:48 Reject172.16.1.64/26 *[Static/5] 00:17:48 Reject


172.16.1.128/26 *[Static/5] 00:17:48 Reject172.16.1.192/26 *[Static/5] 00:17:48 Reject

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)



Step 2.7

Navigate to the [edit policy-options policy-statement redistribute-statics] hierarchy and create a policy that accepts all static routes.

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# top edit policy-options policy-statement redistribute-statics



[edit policy-options policy-statement redistribute-statics]lab@mxA-1# set term 1 from protocol static

[edit policy-options policy-statement redistribute-statics]lab@mxA-1# set term 1 then accept

[edit policy-options policy-statement redistribute-statics]lab@mxA-1#

Step 2.8

Navigate to the [edit protocols bgp] hierarchy and apply the redistribute-statics policy as an export policy in the protocols bgp group ibgp hierarchy.

[edit policy-options policy-statement redistribute-statics]lab@mxA-1# top edit protocols bgp

[edit protocols bgp]lab@mxA-1# set group ibgp export redistribute-statics

Step 2.9

Navigate to the [edit routing-instances R3-Y protocols bgp] hierarchy and apply the redistribute-statics policy as an export policy in the protocols bgp group ibgp hierarchy. Commit the configuration when completed.


[edit routing-instances R3-1 protocols bgp]lab@mxA-1# set group ibgp export redistribute-statics



Step 2.10

Use the run show bgp summary command to verify that routes are being received from the IBGP peers and that the routes are active.

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# run show bgp summary Groups: 2 Peers: 2 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 2 2 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn

State|#Active/Received/Accepted/Damped...172.16.1.1 65001 9 9 0 0 2:19 Establ R3-1.inet.0: 2/2/2/0172.16.1.2 65001 8 9 0 0 2:19 2/

2/2/0 0/0/0/0




Question: How many routes are being advertised? How many routes are active?

Answer: Each peer should be advertising two routes and each route should be active. If the Active/Received/Accepted/Damped numbers are not 2/2/2/0 as shown in the example, check your policy and consult your instructor.

Part 3: Configuring the P1 and P2 EBGP Peers

In this lab part, you configure two EBGP peers to the P1 and P2 routers. These devices are both in AS 65412.

Step 3.1

Navigate to the [edit protocols bgp] hierarchy. Configure a BGP group named P1-P2 that establishes an EBGP peering session with the directly connected interfaces of the P1 and P2 routers. Refer to the network diagram for this lab as necessary. Commit the configuration when completed.

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# top edit protocols bgp

[edit protocols bgp]lab@mxA-1# set group P1-P2 type external

[edit protocols bgp]lab@mxA-1# set group P1-P2 neighbor 172.22.12V.2

[edit protocols bgp]lab@mxA-1# set group P1-P2 neighbor 172.22.12V.2

[edit protocols bgp]lab@mxA-1# set group P1-P2 peer-as 65412

[edit protocols bgp]lab@mxA-1# commit commit complete


Step 3.2

Use the run show bgp summary command to verify that the EBGP sessions to P1 and P2 routers are established.



[edit protocols bgp]lab@mxA-1# run show bgp summary Groups: 3 Peers: 4 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 10 6 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn


2/2/0 0/0/0/0172.22.121.2 65412 6 6 0 0 1:16 4/

4/4/0 0/0/0/0172.22.123.2 65412 5 5 0 0 1:02 0/

4/4/0 0/0/0/0


Question: Are the P1 and P2 peers established and how many routes are being received from the P1 and P2 routers?

Answer: The P1 and P2 BGP sessions should be established. However, your results might vary slightly depending if the remote team has their P1 and P2 peers established or not. If they do not have their peers established, you will receive four routes. If they do, you will receive six.

Step 3.3

The BGP neighbor command has a lot of valuable information. Use the run show bgp neighbor 172.22.12V.2 command to view the P1 EBGP peer.

[edit protocols bgp]lab@mxA-1# run show bgp neighbor 172.22.12V.2 Peer: 172.22.121.2+53546 AS 65412 Local: 172.22.121.1+179 AS 65001 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: <Preference PeerAS Refresh> Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 172.31.100.1 Local ID: 172.16.1.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down Local Interface: ge-1/0/0.1111 NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2)



Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 65412) Peer does not support Addpath Table inet.0 Bit: 10001 RIB State: BGP restart is complete Send state: in sync Active prefixes: 6 Received prefixes: 6 Accepted prefixes: 6 Suppressed due to damping: 0 Advertised prefixes: 2 Last traffic (seconds): Received 16 Sent 21 Checked 37 Input messages: Total 9 Updates 3 Refreshes 0 Octets 293 Output messages: Total 8 Updates 1 Refreshes 0 Octets 249 Output Queue[0]: 0


Question: On which TCP port is the peer established on? On which TCP port is the local peer established on?

Answer: In the above capture, the remote peer router is established on TCP port 53546 and the local router is established on TCP port 179. Your results might vary.

Question: Which peer established this session?

Answer: In the example the remote peer router established the session. The remote peer router initiated the TCP session by sending a TCP sync to 172.22.121.1 port 179 from 172.22.121.2 port 53546.

Step 3.4

Use the run show route receive-protocol bgp 172.22.12V.2 command to view the routes being received from the P1 and P2 routers. Refer to the network diagram for this step as necessary.



[edit protocols bgp]lab@mxA-1# run show route receive-protocol bgp 172.22.12V.2

inet.0: 21 destinations, 27 routes (21 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 30.30.0.0/24 172.22.121.2 65412 I* 30.30.1.0/24 172.22.121.2 65412 I* 30.30.2.0/24 172.22.121.2 65412 I* 30.30.3.0/24 172.22.121.2 65412 I* 172.16.2.128/26 172.22.121.2 65412 65002 I* 172.16.2.192/26 172.22.121.2 65412 65002 I

R3-1.inet.0: 17 destinations, 17 routes (11 active, 0 holddown, 6 hidden)




inet.0: 21 destinations, 27 routes (21 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 30.30.0.0/24 172.22.123.2 65412 I 30.30.1.0/24 172.22.123.2 65412 I 30.30.2.0/24 172.22.123.2 65412 I 30.30.3.0/24 172.22.123.2 65412 I 172.16.2.128/26 172.22.123.2 65412 65002 I 172.16.2.192/26 172.22.123.2 65412 65002 I





Question: Are the same routes being received from both the P1 and P2 routers?

Answer: Yes, the same routes are being received from the P1 and P2 routers.

Step 3.5

Display the 30.30.0.0/24 route using the run show route 30.30/24 detail command.



[edit protocols bgp]lab@mxA-1# run show route 30.30.0.0/24 detail

inet.0: 21 destinations, 27 routes (21 active, 0 holddown, 0 hidden)30.30.0.0/24 (2 entries, 1 announced) *BGP Preference: 170/-101 Next hop type: Router, Next hop index: 531 Address: 0x282f0f4 Next-hop reference count: 18 Source: 172.22.121.2 Next hop: 172.22.121.2 via ge-1/0/0.1111, selected State: <Active Ext> Local AS: 65001 Peer AS: 65412 Age: 5:30 Task: BGP_65412.172.22.121.2+53546 Announcement bits (3): 0-KRT 6-BGP RT Background 7-Resolve tree 5 AS path: 65412 I Accepted Localpref: 100 Router ID: 172.31.100.1 BGP Preference: 170/-101 Next hop type: Router Address: 0x282fcd4 Next-hop reference count: 6 Source: 172.22.123.2 Next hop: 172.22.123.2 via ge-1/0/0.1113, selected State: <NotBest Ext> Inactive reason: Not Best in its group - Active preferred Local AS: 65001 Peer AS: 65412 Age: 5:16 Task: BGP_65412.172.22.123.2+179 AS path: 65412 I Accepted Localpref: 100 Router ID: 172.31.101.1



Question: The 30.30.0.0/24 route is being received from both the P1 and P2 peers. Which route is currently the active route? Why?

Answer: The P1 route is the active route. The inactive reason in the P2 route is “Not Best in its group - Active preferred”, which indicates that the P2 route’s selection criteria cannot override the current active route.



Question: How many next-hops do you see for the active route?

Question: At this point you should see only one next-hop.

Step 3.6

Configure the BGP multipath option within the P1-P2 group to install the P1 and P2 routes with two equal cost paths. Commit the configuration when completed.

[edit protocols bgp]lab@mxA-1# set group P1-P2 multipath



Step 3.7

Display the 30.30.0.0/24 route again using the run show route 30.30.0.0/24 detail command.

[edit protocols bgp]lab@mxA-1# run show route 30.30.0.0/24 detail

inet.0: 21 destinations, 27 routes (21 active, 0 holddown, 0 hidden)30.30.0.0/24 (2 entries, 1 announced) *BGP Preference: 170/-101 Next hop type: Router Address: 0x28a11c0 Next-hop reference count: 12 Source: 172.22.121.2 Next hop: 172.22.121.2 via ge-1/0/0.1111 Next hop: 172.22.123.2 via ge-1/0/0.1113, selected State: <Active Ext> Local AS: 65001 Peer AS: 65412 Age: 6:17 Task: BGP_65412.172.22.121.2+53546 Announcement bits (3): 0-KRT 6-BGP RT Background 7-Resolve tree 5 AS path: 65412 I Accepted Multipath Localpref: 100 Router ID: 172.31.100.1 BGP Preference: 170/-101 Next hop type: Router, Next hop index: 673 Address: 0x282fcd4 Next-hop reference count: 9 Source: 172.22.123.2 Next hop: 172.22.123.2 via ge-1/0/0.1113, selected State: <NotBest Ext>



Inactive reason: Not Best in its group - Active preferred Local AS: 65001 Peer AS: 65412 Age: 6:03 Task: BGP_65412.172.22.123.2+179 AS path: 65412 I Accepted Localpref: 100 Router ID: 172.31.101.1



Question: The active BGP route for 30.30.0.0/24 is marked with an *. How many next hops does the active route have installed?

Answer: The 30.30/24 prefix now has two next hops.

Step 3.8

Use the run show route forwarding-table destination 30.30.0.0/24 command to view the packet forwarding table.

[edit protocols bgp]lab@mxA-1# run show route forwarding-table destination 30.30.0.0/24 Routing table: default.inetInternet:Destination Type RtRef Next hop Type Index NhRef Netif30.30.0.0/24 user 0 172.22.123.2 ucst 673 6 ge-1/0/0.1113

Routing table: __master.anon__.inetInternet:Destination Type RtRef Next hop Type Index NhRef Netifdefault perm 0 rjct 523 1

Routing table: default-switch.inetInternet:Destination Type RtRef Next hop Type Index NhRef Netifdefault perm 0 rjct 568 1

Routing table: R3-1.inetInternet:Destination Type RtRef Next hop Type Index NhRef Netifdefault perm 0 rjct 540 3




Question: Are the two next-hops to P1 and P2 installed in the packet forwarding table?

Answer: No. Only one next-hop is installed in the packet forwarding table. The default forwarding behavior for two or more equal cost next-hops is to randomly pick one to be installed in the forwarding table. In this example, the route is using the P2 interface for the 30.30.0.0/24 route. Your results might vary.

Step 3.9

Navigate to the [edit policy-options policy-statement pfe-load-balance] hierarchy. Create a policy named pfe-load-balance that only load balances the 30.30/22 routes being received from the P1 and P2 routers as displayed in Step 3.4.

[edit protocols bgp]lab@mxA-1# top edit policy-options policy-statement pfe-load-balance

[edit policy-options policy-statement pfe-load-balance]lab@mxA-1# set term 1 from protocol bgp

[edit policy-options policy-statement pfe-load-balance]lab@mxA-1# set term 1 from route-filter 30.30/22 longer

[edit policy-options policy-statement pfe-load-balance]lab@mxA-1# set term 1 then load-balance per-packet

[edit policy-options policy-statement pfe-load-balance]lab@mxA-1# show term 1 { from { protocol bgp; route-filter 30.30.0.0/22 longer; } then { load-balance per-packet; }}

[edit policy-options policy-statement pfe-load-balance]lab@mxA-1#

Step 3.10

After configuring the pfe-load-balance policy, apply it as an export policy under the [edit routing-options forwarding-table] hierarchy. Commit the changes when completed.



[edit policy-options policy-statement pfe-load-balance]lab@mxA-1# top edit routing-options forwarding-table

[edit routing-options forwarding-table]lab@mxA-1# set export pfe-load-balance

[edit routing-options forwarding-table]lab@mxA-1# commit commit complete

[edit routing-options forwarding-table]lab@mxA-1#

Step 3.11

Use the run show route forwarding-table destination 30.30/24 command to verify that the forwarding table now has two next-hop interfaces for the 30.30/24 route.

[edit routing-options forwarding-table]lab@mxA-1# run show route forwarding-table destination 30.30/24 Routing table: default.inetInternet:Destination Type RtRef Next hop Type Index NhRef Netif30.30.0.0/24 user 0 ulst 1048576 5 172.22.121.2 ucst 531 5 ge-1/0/0.1111 172.22.123.2 ucst 673 5 ge-1/0/0.1113

Routing table: __master.anon__.inetInternet:Destination Type RtRef Next hop Type Index NhRef Netifdefault perm 0 rjct 523 1

Routing table: default-switch.inetInternet:Destination Type RtRef Next hop Type Index NhRef Netifdefault perm 0 rjct 568 1

Routing table: R3-1.inetInternet:Destination Type RtRef Next hop Type Index NhRef Netifdefault perm 0 rjct 540 3

[edit routing-options forwarding-table]lab@mxA-1#

Question: Is the forwarding table using both next-hop interfaces to reach the 30.30/24 route?

Answer: Yes, the forwarding table now has two next-hop interfaces for the 30.30/24 route, one to P1 and the other to P2.



Part 4: Configuring the EBGP Session with the P3 Router

In this lab part, you configure the R3-Y routing instance to EBGP peer with the P3 router. The peering is between the loopback interfaces of R3-Y and P3. EBGP loopback peering is a three step process. Because the external interfaces are not participating in the IGP, the first step requires a static route to the P3 loopback address. The second step requires configuring the local loopback as the source address of the BGP messages sent to the P3 router. Finally, the BGP multihop command is configured to override the physical connection requirement normally imposed of EBGP sessions.

Step 4.1

Navigate to the [edit routing-instances R3-Y routing-options] hierarchy. Configure a static route to P3’s loopback address (172.31.102.1) with a next hop of 172.22.12V.2. Use the no-readvertise setting to ensure that the route can not be redistributed into other protocols and commit the configuration when completed.

[edit routing-options forwarding-table]lab@mxA-1# top edit routing-instances R3-Y routing-options

[edit routing-instances R3-1 routing-options]lab@mxA-1# set static route 172.31.102.1 next-hop 172.22.12V.2

[edit routing-instances R3-1 routing-options]lab@mxA-1# set static route 172.31.102.1 no-readvertise

[edit routing-instances R3-1 routing-options]lab@mxA-1# commit commit complete


Step 4.2

Use the run ping 172.31.102.1 source 172.16.Y.2 count 5 routing-instance R3-Y command to verify that connectivity between the loopback addresses has been established.

[edit routing-instances R3-1 routing-options]lab@mxA-1# run ping 172.31.102.1 source 172.16.Y.2 count 5 routing-instance R3-Y PING 172.31.102.1 (172.31.102.1): 56 data bytes64 bytes from 172.31.102.1: icmp_seq=0 ttl=64 time=0.440 ms64 bytes from 172.31.102.1: icmp_seq=1 ttl=64 time=0.453 ms64 bytes from 172.31.102.1: icmp_seq=2 ttl=64 time=0.379 ms64 bytes from 172.31.102.1: icmp_seq=3 ttl=64 time=0.454 ms64 bytes from 172.31.102.1: icmp_seq=4 ttl=64 time=0.440 ms


[edit routing-instances R3-1 routing-options static route 172.31.102.1/32]lab@mxA-1#



Question: Is the ping test successful?

Answer: The ping test should be successful. If it is not successful, verify your configuration and consult your instructor.

Step 4.3

Navigate to the [edit routing-instances R3-Y protocols bgp] hierarchy. Configure a BGP group named P3. Configure the P3 loopback address as the peer and the R3-Y loopback address as the local-address. The peer-as is 65020. Commit the configuration when completed.

[edit routing-instances R3-1 routing-options]lab@mxA-1# up 1 edit protocols bgp

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# set group P3 type external

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# set group P3 local-address 172.16.Y.2

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# set group P3 neighbor 172.31.102.1 peer-as 65020



Step 4.4

Check the state of the EBGP session using the run show bgp summary command.



2/2/0 0/0/0/0172.22.121.2 65412 38 38 0 0 15:38 6/

6/6/0 0/0/0/0172.22.123.2 65412 36 37 0 0 15:24 6/

6/6/0 0/0/0/0172.31.102.1 65020 0 0 0 0 5 Idle




Question: What is the state of the P3 peering session?

Answer: The P3 peering session is in Idle state. All EBGP peering sessions must be peered with the physical interface or a TCP session will not be established.

Step 4.5

To relax the EBGP requirement of physical interface peering and make it possible to EBGP peer between loopback addresses, apply the multihop statement to the P3 BGP group. Commit the change when completed.

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# set group P3 multihop



Step 4.6

Check the status again of the P3 session with the run show bgp summary command.



8/8/0 0/0/0/0172.22.121.2 65412 41 41 0 0 17:07 6/

6/6/0 0/0/0/0172.22.123.2 65412 40 40 0 0 16:53 6/

6/6/0 0/0/0/0172.31.102.1 65020 5 5 0 0 48 Establ R3-1.inet.0: 6/6/6/0




Question: What is the state of the P3 peering session after the multihop command is configured?

Answer: The P3 peering session should now be established. If the session is not established, check your configuration or consult your instructor.

Step 4.7

Now that the P3 peering session is established, use the run show route receive-protocol bgp 172.31.102.1 command to view the routes being received from the P3 router.

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# run show route receive-protocol bgp 172.31.102.1

inet.0: 27 destinations, 33 routes (21 active, 0 holddown, 6 hidden)

R3-1.inet.0: 24 destinations, 24 routes (18 active, 0 holddown, 6 hidden) Prefix Nexthop MED Lclpref AS path* 40.40.0.0/24 172.31.102.1 65020 I* 40.40.1.0/24 172.31.102.1 65020 I* 40.40.2.0/24 172.31.102.1 65020 I* 40.40.3.0/24 172.31.102.1 65020 I* 172.16.2.0/26 172.31.102.1 65020 65002 I* 172.16.2.64/26 172.31.102.1 65020 65002 I




Question: Are routes being received from the P3 peering session?

Answer: Yes. Six routes are being received from the P3 router.

Part 5: Summarizing the Internal Routes to the Peer Routers

In this lab part, you must create an aggregate route for the internal redistributed static routes. The mxX-1 aggregate route is 172.16.1.0/24 and the mxX-2 aggregate route is 172.16.2.0/24 for both the default and R3-Y routing instances. Because the IBGP routes are advertised to the EBGP peers by default, an export EBGP routing policy is required to advertise the aggregate route and suppress the specific routes.



Step 5.1

Enter configuration mode and navigate to the [edit routing-options] hierarchy. Configure the aggregate route 172.16.Y.0/24.

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# top edit routing-options

[edit routing-options]lab@mxA-1# set aggregate route 172.16.Y.0/24


Step 5.2

Configure the same aggregate route in the [edit routing-instances R3-Y routing-options] hierarchy.

[edit routing-options]lab@mxA-1# top edit routing-instances R3-Y routing-options

[edit routing-instances R3-1 routing-options]lab@mxA-1# set aggregate route 172.16.Y.0/24


Step 5.3

Navigate to the [edit policy-options policy-statement export-aggregate] hierarchy. Create a routing policy named export-aggregate that will advertise the aggregate route and suppress the more specific routes.

[edit routing-instances R3-1 routing-options]lab@mxA-1# top edit policy-options policy-statement export-aggregate

[edit policy-options policy-statement export-aggregate]lab@mxA-1# set term 1 from protocol aggregate

[edit policy-options policy-statement export-aggregate]lab@mxA-1# set term 1 from route-filter 172.16.Y/24 exact

[edit policy-options policy-statement export-aggregate]lab@mxA-1# set term 1 then accept

[edit policy-options policy-statement export-aggregate]lab@mxA-1# set term 2 from route-filter 172.16.Y/24 longer

[edit policy-options policy-statement export-aggregate]lab@mxA-1# set term 2 then reject

[edit policy-options policy-statement export-aggregate]lab@mxA-1# show term 1 { from { protocol aggregate;



route-filter 172.16.1.0/24 exact; } then accept;}term 2 { from { route-filter 172.16.1.0/24 longer; } then reject;}

[edit policy-options policy-statement export-aggregate]lab@mxA-1#

Step 5.4

Navigate to the [protocols bgp group P1-P2] hierarchy. Apply the export-aggregate policy as an export policy for the P1-P2 group.

[edit policy-options policy-statement export-aggregate]lab@mxA-1# top edit protocols bgp

[edit protocols bgp]lab@mxA-1# set group P1-P2 export export-aggregate


Step 5.5

Navigate to the [edit routing-instances R3-Y protocols bgp] hierarchy. Apply the export-aggregate policy as an export policy for the P3 group. Commit the configuration and return to operational mode.


[edit routing-instances R3-1 protocols bgp]lab@mxA-1# set group P3 export export-aggregate

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# commit and-quitcommit completeExiting configuration mode

lab@mxA-1>

Step 5.6

Using the show route advertising-protocol bgp 172.22.12V.2 command, substitute each of the P1 and P2 neighbor’s IP addresses to view the routes being advertised to each of the peer routers. Use the show route advertising-protocol bgp 172.31.102.1 command for the P3 router.

lab@mxA-1> show route advertising-protocol bgp 172.22.12V.2

inet.0: 25 destinations, 31 routes (21 active, 0 holddown, 5 hidden) Prefix Nexthop MED Lclpref AS path



* 172.16.1.0/24 Self I

lab@mxA-1> show route advertising-protocol bgp 172.22.12V.2

inet.0: 25 destinations, 31 routes (21 active, 0 holddown, 5 hidden) Prefix Nexthop MED Lclpref AS path* 172.16.1.0/24 Self I

lab@mxA-1> show route advertising-protocol bgp 172.31.102.1

R3-1.inet.0: 22 destinations, 23 routes (18 active, 0 holddown, 5 hidden) Prefix Nexthop MED Lclpref AS path* 172.16.1.0/24 Self I

lab@mxA-1>

Question: Is the aggregate route being advertised to each of the peers?

Answer: Yes, the aggregate route is being advertised.

Step 5.7


lab@mxA-1> exit





Lab 8BGP Attributes: Next Hop, Origin, MED, and AS Path (Detailed)

Overview

In this lab, you will use the lab diagram titled "Lab 7-9: BGP and BGP Attributes" to repair unusable routes and influence the BGP route selection process. This lab will utilize the internal Border Gateway Protocol (IBGP) and EBGP peering that was established in Lab 7 which contains "hidden" or unusable routes. Once these routes have been repaired with an IBGP export policy, the routes will be advertised to the P1 and P2 routers using the origin, multiple exit discriminator (MED), and AS-path attributes.

By completing this lab you will perform the following tasks:

• Repair the unusable routes.

• Influence routing using the Origin attribute.

• Influence routing using the MED attribute.

• Influence routing using the AS-path attribute.

• Use policy with AS Path regex expressions.

Note



www.juniper.net BGP Attributes: Next Hop, Origin, MED, and AS Path (Detailed) • Lab 8–111.a.11.4R1.14


Part 1: Repairing Unusable Routes

In this lab part, you will identify unusable routes using the show route hidden command. After analyzing the hidden routes, and discovering the reason they are unusable, you will write an IBGP export policy to change the next-hop attribute. After applying the IBGP export policy, you will verify that the routes are now active and usable.

Step 1.1

Access the command-line interface (CLI) on your student device using either the console, Telnet, or SSH as directed by your instructor. Refer to the management network diagram for the IP address associated with your student device. The following example demonstrates a simple Telnet session with the Secure CRT program as a basis:

Step 1.2


mxA-1 (ttyu0)

login: labPassword:


Step 1.3




[edit]

Lab 8–2 • BGP Attributes: Next Hop, Origin, MED, and AS Path (Detailed) www.juniper.net


lab@mxA-1# commit and-quitcommit completeExiting configuration mode

lab@mxA-1>

Step 1.4

Use the show route hidden table inet.0 command to identify the unusable routes in the default routing table.

lab@mxA-1> show route hidden table inet.0inet.0: 25 destinations, 31 routes (21 active, 0 holddown, 5 hidden)+ = Active Route, - = Last Active, * = Both

40.40.0.0/24 [BGP/170] 00:15:53, localpref 100, from 172.16.1.2 AS path: 65020 I Unusable40.40.1.0/24 [BGP/170] 00:15:53, localpref 100, from 172.16.1.2 AS path: 65020 I Unusable40.40.2.0/24 [BGP/170] 00:15:53, localpref 100, from 172.16.1.2 AS path: 65020 I Unusable40.40.3.0/24 [BGP/170] 00:15:53, localpref 100, from 172.16.1.2 AS path: 65020 I Unusable172.16.2.0/24 [BGP/170] 00:09:08, localpref 100, from 172.16.1.2 AS path: 65020 65002 I Unusable

lab@mxA-1>

Question: All of the hidden routes are BGP routes. Which BGP peer is advertising these routes?

Answer: In the above example, all of the hidden routes are being advertised from the IBGP peer 172.16.1.2.

Step 1.5

Use the show route 40.40.0.0/24 hidden extensive command to display more information about the hidden routes.

lab@mxA-1> show route 40.40.0.0/24 hidden extensive

inet.0: 25 destinations, 31 routes (21 active, 0 holddown, 5 hidden)40.40.0.0/24 (1 entry, 0 announced) BGP Preference: 170/-101 Next hop type: Unusable Address: 0x25e377c Next-hop reference count: 10

www.juniper.net BGP Attributes: Next Hop, Origin, MED, and AS Path (Detailed) • Lab 8–3


State: <Hidden Int Ext> Local AS: 65001 Peer AS: 65001 Age: 16:58 Task: BGP_65001.172.16.1.2+179 AS path: 65020 I Accepted Localpref: 100 Router ID: 172.16.1.2 Indirect next hops: 1 Protocol next hop: 172.31.102.1 Indirect next hop: 0 -


lab@mxA-1>

Question: What is the BGP next-hop attribute for this route?

Answer: In this example, the Protocol next hop is 172.31.102.1.

Question: Because IBGP does not modify any attributes by default, which EBGP peer advertised this route?

Answer: The P3 router advertised this route.

Step 1.6

In the BGP route selection process, the BGP next-hop attribute must be resolved in the default routing table. Use the show route 172.31.102.1 table inet.0 command to verify that the protocol next-hop can be resolved.

lab@mxA-1> show route 172.31.102.1 table inet.0

lab@mxA-1>

Question: Can the BGP next-hop address be resolved in the default routing table?

Answer: No, the BGP next-hop address cannot be resolved in the default routing table and therefore the route is marked as unusable.



Step 1.7

An IBGP export policy needs to be created to modify the attribute to something that can be resolved in the default routing table. Enter configuration mode and navigate to the [edit policy-options policy-statement next-hop-self] hierarchy. In the policy, change the next-hop attribute to the loopback address of the IBGP advertising peer. Ensure that you only change the next-hop attribute if the route is a BGP external route.


[edit]lab@mxA-1# edit policy-options policy-statement next-hop-self

[edit policy-options policy-statement next-hop-self]lab@mxA-1# set term 1 from protocol bgp

[edit policy-options policy-statement next-hop-self]lab@mxA-1# set term 1 from route-type external

[edit policy-options policy-statement next-hop-self]lab@mxA-1# set term 1 then next-hop self

[edit policy-options policy-statement next-hop-self]lab@mxA-1# showterm 1 { from { protocol bgp; route-type external; } then { next-hop self; }}

[edit policy-options policy-statement next-hop-self]lab@mxA-1#

Step 1.8









Navigate to the [edit routing-instances R3-Y protocols bgp] hierarchy and apply the next-hop-self export policy in the ibgp group. Because the hidden routes in the default routing table are being advertised from the R3-Y routing instance, the IBGP export policy must be applied in the R3-Y routing instance. Commit the changes when completed.

[edit policy-options policy-statement next-hop-self]lab@mxA-1# top edit routing-instances R3-Y protocols bgp

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# set group ibgp export next-hop-self


[edit routing-instances R3-1 protocols bgp]lab@mxA-1>#

Step 1.9

Use the run show route hidden command to verify that all routes are active and usable.

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# run show route hidden









Question: Have all the hidden routes disappeared?

Answer: No. Hidden routes are still in the R3-Y routing table that were advertised from the default routing instance.

Step 1.10

Navigate to the [edit protocols bgp] hierarchy. Apply the next-hop-self export policy to the ibgp group in the default routing instance. Commit the changes when completed.

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# top edit protocols bgp

[edit protocols bgp]lab@mxA-1# set group ibgp export next-hop-self



Step 1.11

Again use the run show route hidden command to verify that all of the hidden routes are gone from both routing tables.

[edit protocols bgp]lab@mxA-1# run show route hidden








Question: Are all of the hidden routes gone from all of the routing tables?

Answer: Yes. The next-hop-self policy needs to be applied as an IBGP export policy on all routers that have EBGP peers.

Part 2: Modifying the Origin Attribute

In this lab part, you will modify the origin attribute. The BGP origin attribute is a well known mandatory attribute used in the route selection processes. It has three possible values, IGP (I), EGP (E) or incomplete (?). In the route selection process IGP is preferred over EGP and EGP is preferred over incomplete. Using import policy to change the BGP origin, routes can be influenced to prefer a specific peering session. Because the attribute is a transitive attribute, it can also be used in an export policy to influence traffic in to the AS.

Step 2.1

Because the BGP origin attribute can influence traffic, removing the multipath command from the BGP group P1-P2 will be necessary. Doing so will allow the routes being received from P1 and P2 to choose a single path to AS 65412. Delete the multipath option. Commit the change when completed.

[edit protocols bgp]lab@mxA-1# delete group P1-P2 multipath


[edit protocols bgp]lab@mxA-1>

Step 2.2

Use the run show route receive-protocol bgp 172.22.12V.2 command to display the routes being received from the P1 and the P2 peers. Use the lab topology map to find the correct peering address of the P1 and P2 peers for your student device.


inet.0: 25 destinations, 31 routes (25 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 30.30.0.0/24 172.22.121.2 65412 I* 30.30.1.0/24 172.22.121.2 65412 I* 30.30.2.0/24 172.22.121.2 65412 I* 30.30.3.0/24 172.22.121.2 65412 I 172.16.2.0/24 172.22.121.2 65412 65002 I







inet.0: 25 destinations, 31 routes (25 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 30.30.0.0/24 172.22.123.2 65412 I 30.30.1.0/24 172.22.123.2 65412 I 30.30.2.0/24 172.22.123.2 65412 I 30.30.3.0/24 172.22.123.2 65412 I* 172.16.2.0/24 172.22.123.2 65412 65002 I





Question: How many routes are active from the P1 peer? How many routes are active from the P2 peer?

Answer: The asterisk (*) indicates active routes being received from a BGP peer. In this example, the P1 peer has four active routes and the P2 peer has one active route. Your results might vary.

Step 2.3

Use the run show route 172.16.R.0/24 table inet.0 detail command to display your partner’s summary route in the default routing instance.

[edit protocols bgp]lab@mxA-1# run show route 172.16.R.0/24 table inet.0 detail

inet.0: 25 destinations, 31 routes (25 active, 0 holddown, 0 hidden)172.16.2.0/24 (3 entries, 1 announced) *BGP Preference: 170/-101 Next hop type: Router, Next hop index: 531 Address: 0x282f0f4 Next-hop reference count: 15 Source: 172.22.121.2 Next hop: 172.22.121.2 via ge-1/0/0.1111, selected State: <Active Ext>



Local AS: 65001 Peer AS: 65412 Age: 19:41 Task: BGP_65412.172.22.121.2+53546 Announcement bits (3): 0-KRT 6-BGP RT Background 7-Resolve tree 5 AS path: 65412 65002 I Aggregator: 65002 172.16.2.1 Accepted Localpref: 100 Router ID: 172.31.100.1 BGP Preference: 170/-101 Next hop type: Router Address: 0x282ff80 Next-hop reference count: 5 Source: 172.22.123.2 Next hop: 172.22.123.2 via ge-1/0/0.1113, selected State: <NotBest Ext> Inactive reason: Not Best in its group - Active preferred Local AS: 65001 Peer AS: 65412 Age: 16 Task: BGP_65412.172.22.123.2+58753 AS path: 65412 65002 I Aggregator: 65002 172.16.2.1 Accepted Localpref: 100 Router ID: 172.31.101.1 BGP Preference: 170/-101 Next hop type: Indirect Address: 0x282f8f8 Next-hop reference count: 19 Source: 172.16.1.2 Next hop type: Router, Next hop index: 741 Next hop: 10.0.10.2 via ge-1/0/4.0, selected Protocol next hop: 172.16.1.2 Indirect next hop: 29152d0 1048575 State: <Int Ext> Inactive reason: Interior > Exterior > Exterior via Interior Local AS: 65001 Peer AS: 65001 Age: 7:17 Metric2: 1 Task: BGP_65001.172.16.1.2+179 AS path: 65020 65002 I Aggregator: 65002 172.16.2.2 Accepted Localpref: 100 Router ID: 172.16.1.2


Question: How many BGP peers are advertising the summary route in to the default routing table?

Answer: Three BGP peers are advertising the summary route in to the default routing instance, P1, P2, and R3-Y.



Question: Which peer is being preferred to activate the route?

Answer: EBGP routes are always preferred over IBGP routes so the preferred peer will be P1 or P2. In the previous output, BGP has chosen the P1 router for the active path. Your results might show P2 as the active path.

Step 2.4

Navigate to the [edit policy-options policy-statement P1-P2-import] hierarchy. Write the import policy to change the origin to egp on the summary route being received from P1 and P2.

[edit protocols bgp]lab@mxA-1# top edit policy-options policy-statement P1-P2-import

[edit policy-options policy-statement P1-P2-import]lab@mxA-1# set term 1 from protocol bgp

[edit policy-options policy-statement P1-P2-import]lab@mxA-1# set term 1 from route-filter 172.16.R.0/24 exact

[edit policy-options policy-statement P1-P2-import]lab@mxA-1# set term 1 then origin egp

[edit policy-options policy-statement P1-P2-import]lab@mxA-1# showterm 1 { from { protocol bgp; route-filter 172.16.2.0/24 exact; } then origin egp;}

[edit policy-options policy-statement P1-P2-import]lab@mxA-1#

Step 2.5

Navigate to the [edit protocols bgp] hierarchy and apply the P1-P2-import policy as an import policy to the P1-P2 group. Commit the changes when completed.

[edit policy-options policy-statement P1-P2-import]lab@mxA-1# top edit protocols bgp

[edit protocols bgp]lab@mxA-1# set group P1-P2 import P1-P2-import

[edit protocols bgp]



lab@mxA-1# commit commit complete


Step 2.6

Use the run show route 172.16.R.0/24 table inet.0 detail command to display your partner’s summary route in the default routing instance.

[edit protocols bgp]lab@mxA-1# run show route 172.16.R.0/24 table inet.0 detail

inet.0: 25 destinations, 31 routes (25 active, 0 holddown, 0 hidden)172.16.2.0/24 (3 entries, 1 announced) *BGP Preference: 170/-101 Next hop type: Indirect Address: 0x282f8f8 Next-hop reference count: 21 Source: 172.16.1.2 Next hop type: Router, Next hop index: 741 Next hop: 10.0.10.2 via ge-1/0/4.0, selected Protocol next hop: 172.16.1.2 Indirect next hop: 29152d0 1048575 State: <Active Int Ext> Local AS: 65001 Peer AS: 65001 Age: 12:31 Metric2: 1 Task: BGP_65001.172.16.1.2+179 Announcement bits (2): 0-KRT 7-Resolve tree 5 AS path: 65020 65002 I Aggregator: 65002 172.16.2.2 Accepted Localpref: 100 Router ID: 172.16.1.2 BGP Preference: 170/-101 Next hop type: Router, Next hop index: 531 Address: 0x282f0f4 Next-hop reference count: 13 Source: 172.22.121.2 Next hop: 172.22.121.2 via ge-1/0/0.1111, selected State: <Ext> Inactive reason: Origin Local AS: 65001 Peer AS: 65412 Age: 24:55 Task: BGP_65412.172.22.121.2+53546 AS path: 65412 65002 E Aggregator: 65002 172.16.2.1 Accepted Localpref: 100 Router ID: 172.31.100.1 BGP Preference: 170/-101 Next hop type: Router Address: 0x282ff80 Next-hop reference count: 5 Source: 172.22.123.2 Next hop: 172.22.123.2 via ge-1/0/0.1113, selected State: <NotBest Ext>



Inactive reason: Not Best in its group - Router ID Local AS: 65001 Peer AS: 65412 Age: 5:30 Task: BGP_65412.172.22.123.2+58753 AS path: 65412 65002 E Aggregator: 65002 172.16.2.1 Accepted Localpref: 100 Router ID: 172.31.101.1


Question: Which peer is now being preferred to activate the route? What do you notice about the Inactive reason for the P1/P2 routes?

Answer: The R3-Y router is now the preferred BGP peer for the summary route. The P1/P2 routes are set as inactive because of the origin attribute.

Step 2.7

Remove the import policy from the P1-P2 group. Commit the change and return to operational mode.

[edit protocols bgp]lab@mxA-1# delete group P1-P2 import

[edit protocols bgp]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 2.8

Use the operational mode command show route 172.16.R.0/24 table inet.0 to verify that the route again prefers one of the P1 or P2 peers in the default routing instance.

lab@mxA-1> show route 172.16.R.0 table inet.0


172.16.2.0/24 *[BGP/170] 00:26:12, localpref 100 AS path: 65412 65002 I > to 172.22.121.2 via ge-1/0/0.1111 [BGP/170] 00:06:47, localpref 100 AS path: 65412 65002 I > to 172.22.123.2 via ge-1/0/0.1113 [BGP/170] 00:13:48, localpref 100, from 172.16.1.2



AS path: 65020 65002 I > to 10.0.10.2 via ge-1/0/4.0

lab@mxA-1>

Question: Did the preferred path return to the P1 or P2 peer?

Answer: Yes, in the above capture, the origin is now the same on all three routes and, in this case, the Best in Group path is through P1.

Part 3: Configuring the MED Attribute

In this lab part, you will configure the MED attribute. The MED is an optional nontransitive attribute used to influence traffic coming into your AS. It is a route metric assigned to BGP and advertised to a remote peer to influence the remote peer's route selection process. In this part, you will use a MED to influence the AS 65412 to always use P2 to route traffic to your summary address.

Step 3.1

Refer to the Management Network Diagram and determine the management IP address of the vr-device.

Question: What is the management IP address of the vr-device?

Answer: The management IP address will vary depending on your environment. If you are unsure of this IP address, please check with your instructor.

Step 3.2

Using the management IP address identified in the previous step, open a separate Telnet session to the vr-device.



Step 3.3

Log in to the vr-device using the login details shown in the following table:

vr-device (ttyp2)

login: usernamePassword:lab123

--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

NOTE: This router is divided into many virtual routers used by different teams. Please only configure your own virtual router.

You must use 'configure private' to configure this router.

vr1@vr-device>

Login Details

Student Device Username Password

mxA-1 vr1 lab123

mxA-2 vr2 lab123

mxB-1 vr3 lab123

mxB-2 vr4 lab123

mxC-1 vr5 lab123

mxC-2 vr6 lab123

mxD-1 vr7 lab123

mxD-2 vr8 lab123



Step 3.4

On the vr-device, use the show route 172.16.Y.0/24 exact table ajspr-mxX-labs-p1.inet.0 and show route 172.16.Y.0/24 exact table ajspr-mxX-labs-p2.inet.0 commands to display the paths of your summary route into your AS 6500Y from the perspective of both the P1 and P2 routers. Because you are now viewing the routes from the perspective of the the vr-device, refer to the lab diagram to determine which interfaces you’re working with.

vr1@vr-device> show route 172.16.Y.0/24 exact table ajspr-mxX-labs-p1.inet.0

ajspr-mxA-labs-p1.inet.0: 19 destinations, 29 routes (19 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

172.16.1.0/24 *[BGP/170] 00:00:36, localpref 100 AS path: 65001 I > to 172.22.121.1 via ge-1/0/0.1111 [BGP/170] 04:49:52, localpref 100, from 172.31.101.1 AS path: 65001 I > to 172.22.252.2 via ge-1/0/4.1194




172.16.1.0/24 *[BGP/170] 04:50:25, localpref 100 AS path: 65001 I > to 172.22.123.1 via ge-1/0/0.1113 [BGP/170] 00:01:09, localpref 100, from 172.31.100.1 AS path: 65001 I > to 172.22.252.1 via ge-1/0/9.1194

vr1@vr-device>

Question: What is the preferred path of your summary route, into your AS, from each of the P1 and P2 routers?

Answer: From each of the P1 and P2 routers, the path for your summary route will be across its directly connected interface into AS 6500Y.

Step 3.5

From the Telnet session to your assigned student device, enter configuration mode and navigate to the [edit protocols bgp] hierarchy. Set the metric-out value to 10 on the P1 neighbor. Commit the configuration when completed.




[edit]lab@mxA-1# edit protocols bgp

[edit protocols bgp]lab@mxA-1# set group P1-P2 neighbor 172.22.12V.2 metric-out 10


[edit protocols bgp]lab@mxA-1>#

STOP Stop and wait for the remote student team to finish the previous step.

Step 3.6

On the vr-device, use the show route 172.16.Y.0/24 exact table ajspr-mxX-labs-p1.inet.0 and show route 172.16.Y.0/24 exact table ajspr-mxX-labs-p2.inet.0 commands to display the paths of your summary route into your AS 6500Y from the perspective of both the P1 and P2 routers. Again, because you are now viewing the routes from the perspective of the the vr-device, refer to the lab diagram to determine the interfaces with which you are working.




172.16.1.0/24 *[BGP/170] 05:53:08, localpref 100, from 172.31.101.1 AS path: 65001 I > to 172.22.252.2 via ge-1/0/4.1194 [BGP/170] 00:11:14, MED 10, localpref 100 AS path: 65001 I > to 172.22.121.1 via ge-1/0/0.1111




172.16.1.0/24 *[BGP/170] 05:53:14, localpref 100 AS path: 65001 I > to 172.22.123.1 via ge-1/0/0.1113

vr1@vr-device>



Question: After the MED change, what is the preferred path of your summary route, into your AS, from each of the P1 and P2 routers?

Answer: From the P1 router, the preferred path for the summary route is now through the P2 router. The preferred path for the P2 router is still across its directly connected link to AS 6500Y.

Question: What additional information is present in the routing information for the directly connected link between P1 and your default router?

Question: You should see a MED 10 value in the route information for the directly connected link between your default router and P1.

Step 3.7

From the Telnet session on your assigned device, navigate to the [edit policy-options] hierarchy. Copy the export-aggregate policy to a new policy named export-p2. Display the new policy with the show command.

[edit protocols bgp]lab@mxA-1# top edit policy-options

[edit policy-options]lab@mxA-1# copy policy-statement export-aggregate to policy-statement export-p2

[edit policy-options]lab@mxA-1# show policy-statement export-p2term 1 { from { protocol aggregate; route-filter 172.16.1.0/24 exact; } then accept;}term 2 { from { route-filter 172.16.1.0/24 longer; } then reject;}

[edit policy-options]lab@mxA-1#



Step 3.8

Navigate to the [edit policy-options policy-statement export-p2] hierarchy. Set the metric to 20 in term 1 before accepting the summary route.

[edit policy-options]lab@mxA-1# edit policy-statement export-p2

[edit policy-options policy-statement export-p2]lab@mxA-1# set term 1 then metric 20

[edit policy-options policy-statement export-p2]lab@mxA-1#

Step 3.9

Navigate to the [edit protocols bgp group P1-P2] hierarchy and apply the export-p2 policy as an export policy under the P2 neighbor statement. Commit the changes when completed.

lab@mxA-1# top edit protocols bgp group P1-P2

[edit protocols bgp group P1-P2]lab@mxA-1# set neighbor 172.22.12V.2 export export-p2

[edit protocols bgp group P1-P2]lab@mxA-1# commit commit complete

[edit protocols bgp group P1-P2]lab@mxA-1>#

Step 3.10

On the vr-device, use the show route 172.16.Y.0/24 exact table ajspr-mxX-labs-p1.inet.0 and show route 172.16.Y.0/24 exact table ajspr-mxX-labs-p2.inet.0 commands to display the paths of your summary route into your AS 6500Y from the perspective of both the P1 and P2 routers.




172.16.1.0/24 *[BGP/170] 00:31:50, MED 10, localpref 100 AS path: 65001 I > to 172.22.121.1 via ge-1/0/0.1111




172.16.1.0/24 *[BGP/170] 00:00:43, MED 10, localpref 100, from 172.31.100.1 AS path: 65001 I



> to 172.22.252.1 via ge-1/0/9.1194 [BGP/170] 00:00:43, MED 20, localpref 100 AS path: 65001 I > to 172.22.123.1 via ge-1/0/0.1113

vr1@vr-device>

Question: After this MED change, what is the preferred path of your summary route, into your AS, from each of the P1 and P2 routers?

Answer: From the P1 router, the preferred path for the summary route is now back across its directly connected interface into AS 6500Y. Because the lower MED value is always preferred, the preferred path for the P2 router is now through the P1 router.

Step 3.11

Log out of the vr-device.

vr1@vr-device> exit

Part 4: Modifying the AS Path Attribute

In this lab part, you will modify the AS Path attribute. The AS Path attribute is a mandatory well-known attribute that must be included in every BGP update. The attribute is modified as routes are advertised between EBGP peers. The AS number of the advertising peer is prepended to the beginning of the attribute before it is advertised to the peer. If a BGP update is received from a peer and the AS number of the receiving peer is in the attribute, the update is considered a loop and discarded. The AS Path attribute is also used in the route selection process, the shortest path length is preferred.

Step 4.1

Remove the metric from the P1 neighbor and the export policy from the P2 neighbor. Commit the changes when completed.

[edit protocols bgp group P1-P2]lab@mxA-1# delete neighbor 172.22.12V.2 metric-out

[edit protocols bgp group P1-P2]lab@mxA-1# delete neighbor 172.22.12V.2 export

[edit protocols bgp group P1-P2]lab@mxA-1# show type external;export export-aggregate;peer-as 65412;neighbor 172.22.121.2;



neighbor 172.22.123.2;

[edit protocols bgp group P1-P2]lab@mxA-1# commitcommit complete

[edit protocols bgp group P1-P2]lab@mxA-1#

Step 4.2

Open a new CLI session to your student device using either the console, Telnet, or SSH as directed by your instructor. Refer to the management network diagram for the IP address associated with your student device. The following example demonstrates a simple Telnet session with the Secure CRT program as a basis:

Step 4.3


mxA-1 (ttyu0)

login: labPassword:


Step 4.4

From the new CLI session, log in to your partner's student device using its default instance loopback address. The telnet session must be sourced from your loopback address. Log in with the username lab and a password of lab123.

lab@mxA-1> telnet 172.16.R.1 source 172.16.Y.1Trying 172.16.2.1...Connected to 172.16.2.1.Escape character is '^]'.

mxA-2 (ttyp1)

login: labPassword:




Step 4.5

From the Telnet session to your partner’s device, use the show route 172.16.Y.0/24 table inet.0 command to display the path of your summary route in the default routing instance.



172.16.1.0/24 *[BGP/170] 00:14:47, localpref 100 AS path: 65412 65001 I > to 172.22.124.2 via ge-1/0/0.1114 [BGP/170] 00:06:13, localpref 100 AS path: 65412 65001 I > to 172.22.122.2 via ge-1/0/0.1112 [BGP/170] 00:22:04, localpref 100, from 172.16.2.2 AS path: 65020 65001 I > to 10.0.14.2 via ge-1/0/4.0

lab@mxA-2>

Question: How many BGP paths exist for your summary route?

Answer: Three possible paths exist to the summary route through P1, P2, and P3.

Question: What is the AS Path for the three BGP paths?

Answer: The AS Path in two of the BGP updates is 65412 6500Y. The third is 65020 6500Y.

Step 4.6

From the Telnet session to your assigned student device, navigate to the [edit policy-options] hierarchy. Copy the export-aggregate policy to a new policy named export-p3 and display the new policy with the show policy-statement export-p3 command.

[edit protocols bgp group P1-P2]lab@mxA-1# top edit policy-options




[edit policy-options]lab@mxA-1# show policy-statement export-p3term 1 { from { protocol aggregate; route-filter 172.16.1.0/24 exact; } then accept;}term 2 { from { route-filter 172.16.1.0/24 longer; } then reject;}


Step 4.7

Navigate to the [edit policy-options policy-statement export-p3] hierarchy. Using the as-path-prepend option, insert your partner’s AS number in to the AS Path.


[edit policy-options policy-statement export-p3]lab@mxA-1# set term 1 then as-path-prepend 6500R


Step 4.8

Navigate to the [routing-instances R3-Y protocols bgp] hierarchy and apply the export-p3 policy as an export policy under the P3 neighbor hierarchy. Commit the changes when completed.

[edit policy-options policy-statement export-p3]lab@mxA-1# top edit routing-instances R3-Y protocols bgp

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# set group P3 neighbor 172.31.102.1 export export-p3





Step 4.9




172.16.1.0/24 *[BGP/170] 00:16:51, localpref 100 AS path: 65412 65001 I > to 172.22.124.2 via ge-1/0/0.1114 [BGP/170] 00:08:17, localpref 100 AS path: 65412 65001 I > to 172.22.122.2 via ge-1/0/0.1112

lab@mxA-2>

Question: What happened to the BGP update from the P3 router?

Answer: The BGP update received from the P3 peer has the local AS number in the AS Path attribute. The update is discarded as a loop.

Step 4.10

From the Telnet session to your assigned device, navigate to the [edit policy-options policy-statement export-aggregate] hierarchy. Display the policy with the show command. Using the as-path-prepend command insert your AS number three times in to the AS path before accepting the summary route. Commit the changes when completed.

[edit routing-instances R3-1 protocols bgp]lab@mxA-1# top edit policy-options policy-statement export-aggregate

[edit policy-options policy-statement export-aggregate]lab@mxA-1# showterm 1 { from { protocol aggregate; route-filter 172.16.1.0/24 exact; } then accept;}term 2 { from { route-filter 172.16.1.0/24 longer; } then reject;



}

[edit policy-options policy-statement export-aggregate]lab@mxA-1# set term 1 then as-path-prepend "6500Y 6500Y 6500Y"

[edit policy-options policy-statement export-aggregate]lab@mxA-1# commit commit complete


Step 4.11

From the Telnet session of your partner’s device, use the show route 172.16.Y.0/24 table inet.0 command to display the path of your summary route in the default routing instance.



172.16.1.0/24 *[BGP/170] 00:00:34, localpref 100 AS path: 65412 65001 65001 65001 65001 I > to 172.22.122.2 via ge-1/0/0.1112 [BGP/170] 00:00:34, localpref 100 AS path: 65412 65001 65001 65001 65001 I > to 172.22.124.2 via ge-1/0/0.1114

lab@mxA-2>

Question: What is the AS Path for the summary route now? Why are there four of your AS numbers?

Answer: The AS path for the summary route is 65412 6500Y 6500Y 6500Y 6500Y. The as-path-prepend command in the export policy inserted three 6500Y AS numbers and the EBGP peer inserted the fourth.

Step 4.12

From the Telnet session to your assigned device, navigate to the [edit policy-options policy-statement export-p3] hierarchy. Display the policy using the show command and delete the as-path-prepend option. Commit the change when completed.

[edit policy-options policy-statement export-aggregate]lab@mxA-1# up 1 edit policy-statement export-p3

[edit policy-options policy-statement export-p3]lab@mxA-1# show



term 1 { from { protocol aggregate; route-filter 172.16.1.0/24 exact; } then { as-path-prepend 65002; accept; }}term 2 { from { route-filter 172.16.1.0/24 longer; } then reject;}

[edit policy-options policy-statement export-p3]lab@mxA-1# delete term 1 then as-path-prepend

[edit policy-options policy-statement export-p3]lab@mxA-1# commit commit complete


Step 4.13




172.16.1.0/24 *[BGP/170] 00:03:34, localpref 100, from 172.16.2.2 AS path: 65020 65001 I > to 10.0.14.2 via ge-1/0/4.0

lab@mxA-2>

Question: Which of the three BGP routes is active and why?

Answer: The active route is using the IBGP update from the R3-Y router. This AS path through the R3 router has a length of two while the AS path through P1 and P2 has a length of five.



Step 4.14

Log out of the Telnet session to your partner’s device. You will not need it anymore during this lab. All future commands will be entered on your assigned student device.

lab@mxA-2> exit

Connection closed by foreign host.

lab@mxA-1> exit

Step 4.15

Navigate to the [edit policy-options policy-statement export-aggregate] hierarchy. Display the policy using the show command and delete the as-path-prepend statement. Commit the change when completed.

[edit policy-options policy-statement export-p3]lab@mxA-1# up 1 edit policy-statement export-aggregate

[edit policy-options policy-statement export-aggregate]lab@mxA-1# showterm 1 { from { protocol aggregate; route-filter 172.16.1.0/24 exact; } then { as-path-prepend "65001 65001 65001"; accept; }}term 2 { from { route-filter 172.16.1.0/24 longer; } then reject;}

[edit policy-options policy-statement export-aggregate]lab@mxA-1# delete term 1 then as-path-prepend

[edit policy-options policy-statement export-aggregate]lab@mxA-1# commit commit complete


Step 4.16

Use the run show route receive-protocol bgp 172.22.12V.2 command to display the routes being received from the P1 router.

[edit policy-options policy-statement export-aggregate]lab@mxA-1# run show route receive-protocol bgp 172.22.12V.2



inet.0: 25 destinations, 31 routes (25 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 30.30.0.0/24 172.22.121.2 65412 I 30.30.1.0/24 172.22.121.2 65412 I 30.30.2.0/24 172.22.121.2 65412 I 30.30.3.0/24 172.22.121.2 65412 I* 172.16.2.0/24 172.22.121.2 65412 65002 I





Question: How many routes are being received from the P1 peer?

Answer: Five routes are being received from the P1 peer.

Step 4.17

Use a regular expression in the run show route receive-protocol bgp 172.22.12V.2 aspath-regex “.* 6500R” command to only display routes that originate in your partner’s autonomous system. Use the P1 neighbor.

[edit policy-options policy-statement export-aggregate]lab@mxA-1# run show route receive-protocol bgp 172.22.12V.2 aspath-regex ".*

6500R"

inet.0: 25 destinations, 31 routes (25 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 172.16.2.0/24 172.22.121.2 65412 65002 I







Step 4.18

Using regular expressions, create a BGP import policy to only accept your partner’s summary route from the P1 peer. Navigate to the [edit policy-options] hierarchy. Create an as-path named partner-as to match on all routes that originate in your partner’s autonomous system.

[edit policy-options policy-statement export-aggregate]lab@mxA-1# up

[edit policy-options]lab@mxA-1# set as-path partner-as ".* 6500R"


Step 4.19

Navigate to the [edit policy-options policy-statement import-P1] hierarchy. Create a policy, using the as-path you just created, which accepts only routes that originate in your partner’s autonomous system.

[edit policy-options]lab@mxA-1# edit policy-statement import-P1

[edit policy-options policy-statement import-P1]lab@mxA-1# set term 1 from protocol bgp

[edit policy-options policy-statement import-P1]lab@mxA-1# set term 1 from as-path partner-as

[edit policy-options policy-statement import-P1]lab@mxA-1# set term 1 then accept

[edit policy-options policy-statement import-P1]lab@mxA-1# set term 2 then reject

[edit policy-options policy-statement import-P1]lab@mxA-1#

Step 4.20

Navigate to the [protocols bgp group P1-P2] hierarchy and apply the import-P1 policy to the P1 neighbor as an import policy. Commit the configuration when completed.

[edit policy-options policy-statement import-P1]lab@mxA-1# top edit protocols bgp group P1-P2

[edit protocols bgp group P1-P2]lab@mxA-1# set neighbor 172.22.12Y.2 import import-P1





Step 4.21

Use the run show route receive-protocol bgp 172.22.12V.2 command to display the routes being received from P1.

[edit protocols bgp group P1-P2]lab@mxA-1# run show route receive-protocol bgp 172.22.12V.2

inet.0: 25 destinations, 31 routes (25 active, 0 holddown, 4 hidden) Prefix Nexthop MED Lclpref AS path* 172.16.2.0/24 172.22.121.2 65412 65002 I





Question: Is the P1 import policy working?

Answer: Yes, the import policy applied to the P1 peer is only accepting your partner’s summary route.

Step 4.22

Use the command run show route advertising-protocol bgp 172.22.12V.2 to display the routes being advertised to the P1 peer.

[edit protocols bgp group P1-P2]lab@mxA-1# run show route advertising-protocol bgp 172.22.12V.2

inet.0: 25 destinations, 31 routes (25 active, 0 holddown, 4 hidden) Prefix Nexthop MED Lclpref AS path* 40.40.0.0/24 Self 65020 I* 40.40.1.0/24 Self 65020 I* 40.40.2.0/24 Self 65020 I* 40.40.3.0/24 Self 65020 I* 172.16.1.0/24 Self I




Question: How many routes are being advertised to the P1 peer?

Answer: The default routing instance is advertising five routes to the P1 peer.

Step 4.23

Navigate to the [edit routing-instances R3-Y] hierarchy. Configure a static route of 172.16.10.0/24 in the R3-Y routing instance with a next-hop of reject. Commit the configuration when completed.

[edit protocols bgp group P1-P2]lab@mxA-1# top edit routing-instances R3-Y

[edit routing-instances R3-1]lab@mxA-1# set routing-options static route 172.16.10.0/24 reject



Step 4.24

Use regular expressions in the run show route advertising-protocol bgp 172.22.12V.2 aspath-regex “()” command to only display routes that originate in your autonomous system. Use the P1 neighbor address.

[edit routing-instances R3-1]lab@mxA-1# run show route advertising-protocol bgp 172.22.12V.2 aspath-regex

"()"

inet.0: 26 destinations, 32 routes (26 active, 0 holddown, 4 hidden) Prefix Nexthop MED Lclpref AS path* 172.16.1.0/24 Self I* 172.16.10.0/24 Self I


Step 4.25

Using regular expressions, modify the BGP export policy for P1 to suppress all internal BGP routes from being advertised. Navigate to the [edit policy-options] hierarchy. Create an as-path named internal-as to match on all internal BGP routes.

[edit routing-instances R3-1]lab@mxA-1# top edit policy-options

[edit policy-options]



lab@mxA-1# set as-path internal-as "()"


Step 4.26

Navigate to the [edit policy-options policy-statement export-aggregate] hierarchy and display the policy using the show command. Using the as-path configured in the previous step, create a new term to suppress the internal BGP routes from being advertised to the P1 and P2 peers. Commit the configuration and return to operational mode.

[edit policy-options]lab@mxA-1# edit policy-statement export-aggregate

[edit policy-options policy-statement export-aggregate]lab@mxA-1# showterm 1 { from { protocol aggregate; route-filter 172.16.1.0/24 exact; } then accept;}term 2 { from { route-filter 172.16.1.0/24 longer; } then reject;}

[edit policy-options policy-statement export-aggregate]lab@mxA-1# set term 3 from protocol bgp

[edit policy-options policy-statement export-aggregate]lab@mxA-1# set term 3 from as-path internal-as

[edit policy-options policy-statement export-aggregate]lab@mxA-1# set term 3 then reject

[edit policy-options policy-statement export-aggregate]lab@mxA-1# commit and-quitcommit completeExiting configuration mode

lab@mxA-1>

Step 4.27

Use regular expressions in the show route advertising-protocol bgp 172.22.12V.2 aspath-regex “()” command to only display routes that originate in your autonomous system. Use the P1 neighbor.

lab@mxA-1> show route advertising-protocol bgp 172.22.12V.2 aspath-regex "()"




Prefix Nexthop MED Lclpref AS path* 172.16.1.0/24 Self I

lab@mxA-1>

Question: Are the internal BGP routes being suppressed to the P1 peer?

Answer: Yes. The 172.16.Y.0.0/24 route that is left is not a BGP internal route. It is an aggregate route being redistributed and advertised to the P1 EBGP peer.

Step 4.28


lab@mxA-1> exit





Lab 9BGP Attributes: Local-Preference and Communities (Detailed)

Overview

In this lab, you will use the lab diagram titled "Lab 7-9: BGP and BGP Attributes" to influence traffic leaving your autonomous system. The Local-Preference attribute will be used in this lab to define a preferred exit point out of your AS for routes being received from AS 65412. In addition, you will use communities to tag the routes being received from the P1, P2, and P3 routers.

By completing this lab you will perform the following tasks:

• Load the starting configuration

• Influence routing using the Local-Preference attribute.

• Use communities to tag routes.

• Influence routing by matching specific communities.

Note



www.juniper.net BGP Attributes: Local-Preference and Communities (Detailed) • Lab 9–111.a.11.4R1.14


Part 1: Modifying the Local-Preference Attribute

In this lab part, you will load the Lab 9 reset file and use the local-preference attribute to change the routing behavior within your local autonomous system.

Step 1.1


Step 1.2


mxA-1 (ttyu0)

login: labPassword:


Step 1.3

Enter configuration mode and load the device’s reset configuration by issuing the load override ajspr/lab9-start.config command. After the configuration has been loaded, commit the changes and exit to operational mode.




lab@mxA-1>

Lab 9–2 • BGP Attributes: Local-Preference and Communities (Detailed) www.juniper.net


Step 1.4







Use the show route 172.16.R.0/24 table inet.0 detail to display detailed information about your partner’s summary route in the default routing instance.

lab@mxA-1> show route 172.16.R.0/24 table inet.0 detail

inet.0: 26 destinations, 32 routes (26 active, 0 holddown, 4 hidden)172.16.2.0/24 (3 entries, 1 announced) *BGP Preference: 170/-101 Next hop type: Router, Next hop index: 613 Address: 0x282fba4 Next-hop reference count: 7 Source: 172.22.121.2 Next hop: 172.22.121.2 via ge-1/0/0.1111, selected State: <Active Ext> Local AS: 65001 Peer AS: 65412 Age: 48:27 Task: BGP_65412.172.22.121.2+179 Announcement bits (3): 0-KRT 7-BGP RT Background 8-Resolve tree 5 AS path: 65412 65002 I Aggregator: 65002 172.16.2.1 Accepted Localpref: 100 Router ID: 172.31.100.1 BGP Preference: 170/-101 Next hop type: Router, Next hop index: 614 Address: 0x282fc88 Next-hop reference count: 13 Source: 172.22.123.2 Next hop: 172.22.123.2 via ge-1/0/0.1113, selected State: <NotBest Ext> Inactive reason: Not Best in its group - Active preferred Local AS: 65001 Peer AS: 65412 Age: 48:27 Task: BGP_65412.172.22.123.2+54248 AS path: 65412 65002 I Aggregator: 65002 172.16.2.1 Accepted

www.juniper.net BGP Attributes: Local-Preference and Communities (Detailed) • Lab 9–3


Localpref: 100 Router ID: 172.31.101.1 BGP Preference: 170/-101 Next hop type: Indirect Address: 0x282ff80 Next-hop reference count: 22 Source: 172.16.1.2 Next hop type: Router, Next hop index: 615 Next hop: 10.0.10.2 via ge-1/0/4.0, selected Protocol next hop: 172.16.1.2 Indirect next hop: 28e2960 1048576 State: <Int Ext> Inactive reason: Interior > Exterior > Exterior via Interior Local AS: 65001 Peer AS: 65001 Age: 50:13 Metric2: 1 Task: BGP_65001.172.16.1.2+179 AS path: 65020 65002 I Aggregator: 65002 172.16.2.2 Accepted Localpref: 100 Router ID: 172.16.1.2

lab@mxA-1>

Question: Three BGP routes have been received in the default routing table from the R3-Y, P1 and P2 routers. Of these three BGP updates, which route is active?

Answer: In the above capture, the route received from the P1 router is the active route. Your results might differ.

Question: What is the local-preference for the three BGP routes?

Answer: The local-preference value for all three BGP routes is at the default 100.

Step 1.5

Enter configuration mode and navigate to the [edit policy-options policy-statement import-p1] hierarchy. Configure the import-p1 policy to set the local-preference on the summary route being received from the P1 router to 110. Ensure that the local-preference is only changed on the P1 neighbor. Use the show command to display the policy.




[edit]lab@mxA-1# edit policy-options policy-statement import-p1

[edit policy-options policy-statement import-p1]lab@mxA-1# set term 1 from protocol bgp

[edit policy-options policy-statement import-p1]lab@mxA-1# set term 1 from neighbor 172.22.12V.2

[edit policy-options policy-statement import-p1]lab@mxA-1# set term 1 from route-filter 172.16.R.0/24 exact

[edit policy-options policy-statement import-p1]lab@mxA-1# set term 1 then local-preference 110

[edit policy-options policy-statement import-p1]lab@mxA-1# showterm 1 { from { protocol bgp; neighbor 172.22.121.2; route-filter 172.16.2.0/24 exact; } then { local-preference 110; }}

[edit policy-options policy-statement import-p1]lab@mxA-1#

Step 1.6

Navigate to the [edit protocols bgp group P1-P2] hierarchy and apply the import-p1 policy as an import policy under the group. Commit the configuration when completed.

[edit policy-options policy-statement import-p1]lab@mxA-1# top edit protocols bgp group P1-P2

[edit protocols bgp group P1-P2]lab@mxA-1# set import import-p1



Step 1.7

Use the run show route 172.16.R.0/24 table inet.0 detail command to display detailed information about your partner’s summary route in the default routing instance.



[edit protocols bgp group P1-P2]lab@mxA-1# run show route 172.16.R.0/24 table inet.0 detail

inet.0: 26 destinations, 31 routes (26 active, 0 holddown, 0 hidden)172.16.2.0/24 (2 entries, 1 announced) *BGP Preference: 170/-111 Next hop type: Router, Next hop index: 613 Address: 0x282fba4 Next-hop reference count: 7 Source: 172.22.121.2 Next hop: 172.22.121.2 via ge-1/0/0.1111, selected State: <Active Ext> Local AS: 65001 Peer AS: 65412 Age: 1:08:04 Task: BGP_65412.172.22.121.2+179 Announcement bits (3): 0-KRT 7-BGP RT Background 8-Resolve tree 5 AS path: 65412 65002 I Aggregator: 65002 172.16.2.1 Accepted Localpref: 110 Router ID: 172.31.100.1 BGP Preference: 170/-101 Next hop type: Router, Next hop index: 614 Address: 0x282fc88 Next-hop reference count: 13 Source: 172.22.123.2 Next hop: 172.22.123.2 via ge-1/0/0.1113, selected State: <Ext> Inactive reason: Local Preference Local AS: 65001 Peer AS: 65412 Age: 1:08:04 Task: BGP_65412.172.22.123.2+54248 AS path: 65412 65002 I Aggregator: 65002 172.16.2.1 Accepted Localpref: 100 Router ID: 172.31.101.1


Question: Now, only two BGP routes are in the default routing table. What happened to the route from the R3-Y router?

Answer: Because the local-preference attribute is evaluated by the route selection algorithm before the AS Path attribute, the summary route from P1 is preferred over the route from the P3 router.



Question: What do you notice about the local-preference value on the P1 route?

Question: It has changed to 110 due to the import-p1 policy.

Step 1.8

Use the run show route 172.16.R.0/24 table R3-Y.inet.0 detail command to display detail information about your partner’s summary route in the R3-Y routing instance.

[edit protocols bgp group P1-P2]lab@mxA-1# run show route 172.16.R.0/24 table R3-Y.inet.0 detail

R3-1.inet.0: 23 destinations, 24 routes (23 active, 0 holddown, 0 hidden)172.16.2.0/24 (2 entries, 1 announced) *BGP Preference: 170/-111 Next hop type: Indirect Address: 0x282fee8 Next-hop reference count: 21 Source: 172.16.1.1 Next hop type: Router, Next hop index: 616 Next hop: 10.0.10.1 via ge-1/1/4.0, selected Protocol next hop: 172.16.1.1 Indirect next hop: 28e2870 1048575 State: <Active Int Ext> Local AS: 65001 Peer AS: 65001 Age: 4:33 Metric2: 1 Task: BGP_65001.172.16.1.1+51715 Announcement bits (3): 2-KRT 6-BGP RT Background 7-Resolve tree 4 AS path: 65412 65002 I Aggregator: 65002 172.16.2.1 Accepted Localpref: 110 Router ID: 172.16.1.1 BGP Preference: 170/-101 Next hop type: Indirect Address: 0x282fb58 Next-hop reference count: 13 Source: 172.31.102.1 Next hop type: Router, Next hop index: 612 Next hop: 172.22.125.2 via ge-1/0/0.1115, selected Protocol next hop: 172.31.102.1 Indirect next hop: 28e23c0 1048574 State: <Ext> Inactive reason: Local Preference Local AS: 65001 Peer AS: 65020 Age: 1:11:51 Metric2: 0 Task: BGP_65020.172.31.102.1+179 AS path: 65020 65002 I Aggregator: 65002 172.16.2.2 Accepted Localpref: 100



Router ID: 20.20.1.1


Question: Two BGP routes are in the R3-Y routing table for your partner’s summary route. Why is the route from the default routing instance active over the route from P3?

Answer: The local preference attribute is evaluated before the AS Path length in the BGP route selection process. Because the higher local preference is preferred, the BGP route from the default routing instance with a local preference of 110 is preferred over the P3 route with a local preference of 100.

Step 1.9

Navigate to the [edit policy-options policy-statement import-P3] hierarchy. Configure the import-p3 policy to set the local-preference on the summary route being received from the P3 router to 120. Ensure that the local-preference is only changed on the P3 neighbor. Also, recall that the P3 neighbor is a multihop peer to the P3 loopback address. Use the show command to display the policy.

[edit protocols bgp group P1-P2]lab@mxA-1# top edit policy-options policy-statement import-p3

[edit policy-options policy-statement import-p3]lab@mxA-1# set term 1 from protocol bgp

[edit policy-options policy-statement import-p3]lab@mxA-1# set term 1 from neighbor 172.31.102.1

[edit policy-options policy-statement import-p3]lab@mxA-1# set term 1 from route-filter 172.16.R.0/24 exact

[edit policy-options policy-statement import-p3]lab@mxA-1# set term 1 then local-preference 120

[edit policy-options policy-statement import-p3]lab@mxA-1# showterm 1 { from { protocol bgp; neighbor 172.31.102.1; route-filter 172.16.2.0/24 exact; } then { local-preference 120;



}}

[edit policy-options policy-statement import-p3]lab@mxA-1#

Step 1.10

Navigate to the [edit routing-instances R3-Y protocols bgp group P3] hierarchy and apply the import-p3 policy as an import policy under the group. Commit the configuration when completed.

[edit policy-options policy-statement import-p3]lab@mxA-1# top edit routing-instances R3-Y protocols bgp group P3

[edit routing-instances R3-1 protocols bgp group P3]lab@mxA-1# set import import-p3

[edit routing-instances R3-1 protocols bgp group P3]lab@mxA-1# commit commit complete

[edit routing-instances R3-1 protocols bgp group P3]lab@mxA-1#

Step 1.11

Use the run show route 172.16.R.0/24 table R3-Y.inet.0 detail command to display detail information about your partner’s summary route in the R3-Y routing instance.

[edit routing-instances R3-1 protocols bgp group P3]lab@mxA-1# run show route 172.16.R.0/24 table R3-Y.inet.0 detail

R3-1.inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden)172.16.2.0/24 (1 entry, 1 announced) *BGP Preference: 170/-121 Next hop type: Indirect Address: 0x2a7c224 Next-hop reference count: 15 Source: 172.31.102.1 Next hop type: Router, Next hop index: 581 Next hop: 172.22.125.2 via ge-1/0/0.1115, selected Protocol next hop: 172.31.102.1 Indirect next hop: 2b381c8 1048574 State: <Active Ext> Local AS: 65001 Peer AS: 65020 Age: 11:48 Metric2: 0 Task: BGP_65020.172.31.102.1+179 Announcement bits (3): 0-KRT 6-BGP RT Background 7-Resolve tree 4 AS path: 65020 65002 I Aggregator: 65002 172.16.2.2 Accepted Localpref: 120 Router ID: 20.20.1.1



Question: Did the local preference for your partner’s summary route change to 120?

Answer: Yes, as the above capture shows, the local preference on this route is now 120.

Part 2: Configuring BGP Communities

In this lab part, you will configure BGP communities. The community attribute is an optional transitive attribute. An individual BGP process does not have to understand the community attribute but it must advertise it to all established peers. The community attribute is a 4-octet value in the format FFFF:FFFF. The first two octets represent an autonomous system number and the second two octets represent a locally defined value.

Communities can be used to simply to provide an administrative tag value to associate specific routes with specific BGP peers. It can also be used to trigger specific actions with an import routing policy. A route's community value can cause specific routes to be accepted, rejected or modified.

Step 2.1

Navigate to the [edit policy-options] hierarchy. Define six communities as shown in the table below. The community name should be the same as the member value.

[edit routing-instances R3-1 protocols bgp group P3]lab@mxA-1# top edit policy-options

[edit policy-options]lab@mxA-1# set community 65001:100 members 65001:100


[edit policy-options]

Name Value

65001:100 65001:100

65001:110 65001:110

65001:120 65001:120

65002:100 65002:100

65002:110 65002:110

65002:120 65002:120



lab@mxA-1# set community 65001:120 members 65001:120





Step 2.2

Create two routing policies named export-p1 and export-p2 by using the copy command to copy the export-aggregate policy into each of the new policies.




Step 2.3

Navigate to the [edit policy-options policy-statement export-p1] hierarchy and use the show command to display the policy. In term 1, set the community with the 6500Y:100 community configured previously.


[edit policy-options policy-statement export-p1]lab@mxA-1# showterm 1 { from { protocol aggregate; route-filter 172.16.1.0/24 exact; } then accept;}term 2 { from { route-filter 172.16.1.0/24 longer; } then reject;}

[edit policy-options policy-statement export-p1]lab@mxA-1# set term 1 then community set 6500Y:100




Step 2.4


[edit policy-options policy-statement export-p1]lab@mxA-1# up 1 edit policy-statement export-p2

[edit policy-options policy-statement export-p2]lab@mxA-1# showterm 1 { from { protocol aggregate; route-filter 172.16.1.0/24 exact; } then accept;}term 2 { from { route-filter 172.16.1.0/24 longer; } then reject;}



Step 2.5



[edit policy-options policy-statement export-p3]lab@mxA-1# showterm 1 { from { protocol aggregate; route-filter 172.16.1.0/24 exact; } then accept;}term 2 { from { route-filter 172.16.1.0/24 longer; }



then reject;}



Step 2.6

Navigate to the [edit protocols bgp group P1-P2] hierarchy. Apply the export-p1 policy as an export policy under the P1 neighbor hierarchy and the export-p2 policy as an export policy under the P2 neighbor hierarchy. Recall that the export-p3 policy was applied in a previous step. Commit the configuration when completed.

[edit policy-options policy-statement export-p3]lab@mxA-1# top edit protocols bgp group P1-P2





STOP Stop and wait until your partner has completed the previous step.

Step 2.7

Use the run show route 172.16.R.0/24 table inet.0 detail command to display detailed information about your partner’s summary route in the default routing instance.

[edit protocols bgp group P1-P2]lab@mxA-1# run show route 172.16.R.0/24 table inet.0 detail

inet.0: 26 destinations, 32 routes (26 active, 0 holddown, 0 hidden)172.16.2.0/24 (3 entries, 1 announced) *BGP Preference: 170/-121 Next hop type: Indirect Address: 0x2a7e9a0 Next-hop reference count: 24 Source: 172.16.1.2 Next hop type: Router, Next hop index: 617 Next hop: 10.0.10.2 via ge-1/0/4.0, selected



Protocol next hop: 172.16.1.2 Indirect next hop: 2b3c390 1048576 State: <Active Int Ext> Local AS: 65001 Peer AS: 65001 Age: 30:12 Metric2: 1 Task: BGP_65001.172.16.1.2+179 Announcement bits (3): 0-KRT 7-BGP RT Background 8-Resolve tree 5 AS path: 65020 65002 I Aggregator: 65002 172.16.2.2 Communities: 65002:110 Accepted Localpref: 120 Router ID: 172.16.1.2 BGP Preference: 170/-111 Next hop type: Router, Next hop index: 601 Address: 0x2a7e5c4 Next-hop reference count: 13 Source: 172.22.121.2 Next hop: 172.22.121.2 via ge-1/0/0.1111, selected State: <Ext> Inactive reason: Local Preference Local AS: 65001 Peer AS: 65412 Age: 30:12 Task: BGP_65412.172.22.121.2+179 AS path: 65412 65002 I Aggregator: 65002 172.16.2.1 Communities: 65002:100 Accepted Localpref: 110 Router ID: 172.31.100.1 BGP Preference: 170/-101 Next hop type: Router Address: 0x2a7c354 Next-hop reference count: 5 Source: 172.22.123.2 Next hop: 172.22.123.2 via ge-1/0/0.1113, selected State: <Ext> Inactive reason: Local Preference Local AS: 65001 Peer AS: 65412 Age: 30:00 Task: BGP_65412.172.22.123.2+179 AS path: 65412 65002 I Aggregator: 65002 172.16.2.1 Communities: 65002:120 Accepted Localpref: 100 Router ID: 172.31.101.1




Question: Are the community values visible in your partner’s BGP routes?

Answer: In this example, the community values are visible. If you do not see any communities in the BGP routes, check with your partner or your instructor.

Step 2.8

Enter configuration mode and navigate to the [edit policy-options policy-statement import-communities] hierarchy. Create a three term policy. Each term should set the local-preference value based on the community received from the P1, P2, and P3 routers that was set by your partner. Using the community values received from your partner (use your partner’s AS number), set the local-preference to the same value as the administrative value (last two octets) of the community. Use the show command to display the policy.

[edit protocols bgp group P1-P2]lab@mxA-1# top edit policy-options policy-statement import-communities

[edit policy-options policy-statement import-communities]lab@mxA-1# set term 1 from community 6500R:100

[edit policy-options policy-statement import-communities]lab@mxA-1# set term 1 then local-preference 100

[edit policy-options policy-statement import-communities]lab@mxA-1# set term 1 then accept







[edit policy-options policy-statement import-communities]lab@mxA-1# show



term 1 { from community 65002:100; then { local-preference 100; accept; }}term 2 { from community 65002:110; then { local-preference 110; accept; }}term 3 { from community 65002:120; then { local-preference 120; accept; }}

[edit policy-options policy-statement import-communities]lab@mxA-1#

Step 2.9

Navigate to the [edit protocols bgp group P1-P2] hierarchy. Delete the existing group import policies and configure the import-communities policy as the only import policy for the BGP group.

[edit policy-options policy-statement import-communities]lab@mxA-1# top edit protocols bgp group P1-P2

[edit protocols bgp group P1-P2]lab@mxA-1# delete import

[edit protocols bgp group P1-P2]lab@mxA-1# set import import-communities


Step 2.10

Navigate to the [edit routing-instances R3-Y protocols bgp group P3] hierarchy. Delete the existing group import policies and configure the import-communities policy as the only import policy for the BGP group. Commit the configuration and return to operational mode.

[edit protocols bgp group P1-P2]lab@mxA-1# top edit routing-instances R3-Y protocols bgp group P3

[edit routing-instances R3-1 protocols bgp group P3]lab@mxA-1# delete import

[edit routing-instances R3-1 protocols bgp group P3]



lab@mxA-1# set import import-communities

[edit routing-instances R3-2 protocols bgp group P3]lab@mxA-1# commit and-quitcommit completeExiting configuration mode

lab@mxA-1>

Step 2.11

Use the show route 172.16.R.0/24 table inet.0 detail command to display detail information about your partner’s summary route in the default routing instance.

lab@mxA-1> show route 172.16.R.0/24 table inet.0 detail

inet.0: 26 destinations, 33 routes (26 active, 0 holddown, 0 hidden)172.16.2.0/24 (2 entries, 1 announced) *BGP Preference: 170/-121 Next hop type: Router, Next hop index: 614 Address: 0x282fc88 Next-hop reference count: 16 Source: 172.22.123.2 Next hop: 172.22.123.2 via ge-1/0/0.1113, selected State: <Active Ext> Local AS: 65001 Peer AS: 65412 Age: 4:44:04 Task: BGP_65412.172.22.123.2+54248 Announcement bits (3): 0-KRT 7-BGP RT Background 8-Resolve tree 5 AS path: 65412 65002 I Aggregator: 65002 172.16.2.1 Communities: 65002:120 Accepted Localpref: 120 Router ID: 172.31.101.1 BGP Preference: 170/-101 Next hop type: Router, Next hop index: 613 Address: 0x282fba4 Next-hop reference count: 6 Source: 172.22.121.2 Next hop: 172.22.121.2 via ge-1/0/0.1111, selected State: <Ext> Inactive reason: Local Preference Local AS: 65001 Peer AS: 65412 Age: 4:44:04 Task: BGP_65412.172.22.121.2+179 AS path: 65412 65002 I Aggregator: 65002 172.16.2.1 Communities: 65002:100 Accepted Localpref: 100 Router ID: 172.31.100.1

lab@mxA-1>



Question: Which of the routes received from the P1 and P2 routers is active? Why?

Answer: The route from the P2 router is the active route. The route from the P1 router has an inactive reason of Local Preference. The import policy has set the local preference based on the community value and the local preference on the P2 route is higher than the local preference of the P1 route.

Step 2.12

Use the show route 172.16.R.0/24 table R3-Y.inet.0 detail command to display detail information about your partner’s summary route in the default routing instance.

lab@mxA-1> show route 172.16.R.0/24 table R3-Y.inet.0 detail

R3-1.inet.0: 23 destinations, 24 routes (23 active, 0 holddown, 0 hidden)172.16.2.0/24 (2 entries, 1 announced) *BGP Preference: 170/-121 Next hop type: Indirect Address: 0x282fe04 Next-hop reference count: 21 Source: 172.16.1.1 Next hop type: Router, Next hop index: 558 Next hop: 10.0.10.1 via ge-1/1/4.0, selected Protocol next hop: 172.16.1.1 Indirect next hop: 28c43c0 1048576 State: <Active Int Ext> Local AS: 65001 Peer AS: 65001 Age: 3:14 Metric2: 1 Task: BGP_65001.172.16.1.1+179 Announcement bits (3): 2-KRT 6-BGP RT Background 7-Resolve tree 4 AS path: 65412 65002 I Aggregator: 65002 172.16.2.1 Communities: 65002:120 Accepted Localpref: 120 Router ID: 172.16.1.1 BGP Preference: 170/-111 Next hop type: Indirect Address: 0x282f484 Next-hop reference count: 13 Source: 172.31.102.1 Next hop type: Router, Next hop index: 546 Next hop: 172.22.125.2 via ge-1/0/0.1115, selected Protocol next hop: 172.31.102.1 Indirect next hop: 28c41e0 1048574 State: <Ext> Inactive reason: Local Preference Local AS: 65001 Peer AS: 65020 Age: 3:26 Metric2: 0



Task: BGP_65020.172.31.102.1+179 AS path: 65020 65002 I Aggregator: 65002 172.16.2.2 Communities: 65002:110 Accepted Localpref: 110 Router ID: 20.20.1.1

lab@mxA-1>

Question: Why is the route from the default router the active route in the R3-Y routing table?

Answer: The inactive reason on the route received from the P3 router is Local Preference. Because the local preference of the route received from the default router is higher than the local preference set by the import policy based on the community value from the P3 router, the route from the default router is active.

Step 2.13


lab@mxA-1> exit





Lab 10Scaling BGP (Detailed)

Overview

In this lab, you will use the lab diagrams titled “Lab 10: Scaling BGP Part 1” and “Lab 10: Scaling BGP Part 2” to configure route reflectors and confederations. Within a local autonomous system topology, the IBGP peers are fully meshed to prevent routing loops from forming. A fully meshed network inherently has scalability issues which includes the explicit configuration of all IBGP peer with the addition of a new router. Two methods can alleviate the full mesh scaling issue and still ensure a loop-free BGP topology. Route reflection and confederations provide a loop detection mechanism within IBGP to allow IBGP routes to be readvertised to other IBGP peers.


• Load the extended topology.

• Configure route reflection.

• Examine the reflected routes.

• Configure confederations.

www.juniper.net Scaling BGP (Detailed) • Lab 10–111.a.11.4R1.14


Part 1: Configuring Route Reflection

In this lab part, you configure BGP route reflectors. A route reflector utilizes two new BGP attributes. These attributes are never advertised outside the local autonomous system and are used internally for IBGP loop detection. The cluster-list is the first new BGP attribute and operates like the AS path attribute. It contains a list of 32-bit cluster IDs for each cluster a particular route has transited. If a route reflector detects its cluster ID in the cluster-list, it is considered a loop and the BGP update is dropped. The second attribute is the originator ID, which defines the router that first advertised the route to the route reflector. The route reflector uses the originator ID as a second check against routing loops.

Step 1.1

Access the command-line interface (CLI) on your student device using either the console, Telnet, or SSH as directed by your instructor. Refer to the management network diagram for the IP address associated with your student device. The following example demonstrates a simple Telnet session with the Secure CRT program as a basis:

Note



Lab 10–2 • Scaling BGP (Detailed) www.juniper.net


Step 1.2


mxA-1 (ttyu0)

login: labPassword:


Step 1.3

Enter configuration mode and load the device’s reset configuration by issuing the load override ajspr/lab10-start.config command. After the configuration has been loaded, commit the changes and return to operational mode.




lab@mxA-1>

Step 1.4

Use the show ospf neighbor command to verify OSPF reachability from the default router.

lab@mxA-1> show ospf neighborAddress Interface State ID Pri Dead10.0.10.2 ge-1/0/4.0 Full 172.16.1.2 128 3610.0.11.2 ge-1/0/5.0 Full 172.16.1.3 128 30

lab@mxA-1>

www.juniper.net Scaling BGP (Detailed) • Lab 10–3


Question: Are the OSPF neighbor adjacencies established between the default router and the R3-Y and R4-Y routers?

Answer: The OSPF neighbor relationship between the default router and the R3-Y and R4-Y routers should be established and in a Full state. If the OSPF neighbors are not established, check with your instructor.

Step 1.5

Use the show route protocol ospf to verify that the loopback addresses are active in all four of the routing tables.

lab@mxA-1> show route protocol ospf


10.0.12.0/24 *[OSPF/10] 00:03:12, metric 2 > to 10.0.10.2 via ge-1/0/4.010.0.13.0/24 *[OSPF/10] 00:03:11, metric 2 > to 10.0.11.2 via ge-1/0/5.0172.16.1.2/32 *[OSPF/10] 07:56:29, metric 1 > to 10.0.10.2 via ge-1/0/4.0172.16.1.3/32 *[OSPF/10] 00:03:11, metric 1 > to 10.0.11.2 via ge-1/0/5.0172.16.1.4/32 *[OSPF/10] 00:03:11, metric 2 > to 10.0.10.2 via ge-1/0/4.0 to 10.0.11.2 via ge-1/0/5.0224.0.0.5/32 *[OSPF/10] 07:58:42, metric 1 MultiRecv


10.0.11.0/24 *[OSPF/10] 00:03:11, metric 2 > to 10.0.10.1 via ge-1/1/4.010.0.13.0/24 *[OSPF/10] 00:03:12, metric 2 > to 10.0.12.2 via ge-1/0/6.0172.16.1.1/32 *[OSPF/10] 07:56:29, metric 1 > to 10.0.10.1 via ge-1/1/4.0172.16.1.3/32 *[OSPF/10] 00:03:11, metric 2 to 10.0.10.1 via ge-1/1/4.0 > to 10.0.12.2 via ge-1/0/6.0172.16.1.4/32 *[OSPF/10] 00:03:12, metric 1 > to 10.0.12.2 via ge-1/0/6.0224.0.0.5/32 *[OSPF/10] 07:58:42, metric 1 MultiRecv





10.0.10.0/24 *[OSPF/10] 00:03:13, metric 2 > to 10.0.11.1 via ge-1/1/5.010.0.12.0/24 *[OSPF/10] 00:03:08, metric 2 > to 10.0.13.2 via ge-1/0/7.0172.16.1.1/32 *[OSPF/10] 00:03:13, metric 1 > to 10.0.11.1 via ge-1/1/5.0172.16.1.2/32 *[OSPF/10] 00:03:08, metric 2 to 10.0.11.1 via ge-1/1/5.0 > to 10.0.13.2 via ge-1/0/7.0172.16.1.4/32 *[OSPF/10] 00:03:08, metric 1 > to 10.0.13.2 via ge-1/0/7.0224.0.0.5/32 *[OSPF/10] 00:04:00, metric 1 MultiRecv


10.0.10.0/24 *[OSPF/10] 00:03:14, metric 2 > to 10.0.12.1 via ge-1/1/6.010.0.11.0/24 *[OSPF/10] 00:03:09, metric 2 > to 10.0.13.1 via ge-1/1/7.0172.16.1.1/32 *[OSPF/10] 00:03:09, metric 2 to 10.0.13.1 via ge-1/1/7.0 > to 10.0.12.1 via ge-1/1/6.0172.16.1.2/32 *[OSPF/10] 00:03:14, metric 1 > to 10.0.12.1 via ge-1/1/6.0172.16.1.3/32 *[OSPF/10] 00:03:09, metric 1 > to 10.0.13.1 via ge-1/1/7.0224.0.0.5/32 *[OSPF/10] 00:04:00, metric 1 MultiRecv





lab@mxA-1>



Question: Are the loopback addresses active in all four routing tables?

Answer: All four routing tables have the loopback addresses of the other three routers. If any of the loopback addresses are missing, check with your instructor. Without active loopback addresses in the routing table, the IBGP peers cannot be established.

Step 1.6







Enter configuration mode and navigate to the [edit protocols bgp group rr-cluster] hierarchy. Configure the default router as a route reflector for the internal BGP network, and configure the R3-Y, R4-Y, and R5-Y loopback addresses as neighbors. Use your loopback address as the cluster ID and the local-address within the route reflector group.


[edit]lab@mxA-1# edit protocols bgp group rr-cluster

[edit protocols bgp group rr-cluster]lab@mxA-1# set type internal

[edit protocols bgp group rr-cluster]lab@mxA-1# set local-address 172.16.Y.1

[edit protocols bgp group rr-cluster]lab@mxA-1# set cluster 172.16.Y.1



[edit protocols bgp group rr-cluster]lab@mxA-1# set neighbor 172.16.Y.2



[edit protocols bgp group rr-cluster]lab@mxA-1#

Step 1.7

Navigate to the [edit routing-instances R3-Y protocols bgp group ibgp] hierarchy and configure the default router's loopback address as an IBGP neighbor. Use the R3-Y loopback address as the local-address for the internal BGP network.

[edit]lab@mxA-1# top edit routing-instances R3-Y protocols bgp group ibgp

[edit routing-instances R3-1 protocols bgp group ibgp]lab@mxA-1# set type internal

[edit routing-instances R3-1 protocols bgp group ibgp]lab@mxA-1# set local-address 172.16.Y.2

[edit routing-instances R3-1 protocols bgp group ibgp]lab@mxA-1# set neighbor 172.16.Y.1

[edit routing-instances R3-1 protocols bgp group ibgp]lab@mxA-1#

Step 1.8

Navigate to the [edit routing-instances R4-Y protocols bgp group ibgp] hierarchy and configure the default router’s loopback address as an IBGP neighbor. Use the R4-Y loopback address as the local-address for the internal BGP group.

[edit routing-instances R3-1 protocols bgp group ibgp]lab@mxA-1# top edit routing-instances R4-Y protocols bgp group ibgp







Step 1.9

Navigate to the [edit routing-instances R5-Y protocols bgp group ibgp] hierarchy and configure the default router’s loopback address as an IBGP neighbor. Use the R5-Y loopback address as the local-address for the internal BGP group. Commit the configuration when completed.

[edit routing-instances R4-1 protocols bgp group ibgp]lab@mxA-1# top edit routing-instances R5-Y protocols bgp group ibgp




[edit routing-instances R5-1 protocols bgp group ibgp]lab@mxA-1# commit commit complete

[edit routing-instances R5-1 protocols bgp group ibgp]lab@mxA-1>#

Step 1.10

Use the command run show bgp summary to ensure that all of the IBGP peer sessions are established.

[edit routing-instances R5-1 protocols bgp group ibgp]lab@mxA-1# run show bgp summary Groups: 6 Peers: 8 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 10 5 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn

State|#Active/Received/Accepted/Damped...172.16.1.1 65001 22 19 0 0 7:43 Establ R3-1.inet.0: 0/5/5/0172.16.1.1 65001 20 19 0 0 7:40 Establ R4-1.inet.0: 0/5/5/0172.16.1.1 65001 20 21 0 0 7:36 Establ R5-1.inet.0: 0/5/5/0172.16.1.2 65001 18 22 0 0 7:43 Establ inet.0: 0/0/0/0172.16.1.3 65001 18 20 0 0 7:39 Establ inet.0: 0/0/0/0172.16.1.4 65001 20 20 0 0 7:36 Establ inet.0: 0/5/5/0172.22.121.2 65412 1019 1055 0 1 2:48

Establ inet.0: 5/5/5/0172.31.102.1 65020 112 110 0 0 48:01

Establ R5-1.inet.0: 5/5/5/0




Question: Are all of the IBGP peers established on the route reflector?

Answer: All of the IBGP and EBGP peering sessions are established. If any of your sessions are not established, contact your instructor.

Step 1.11

Use the run show route hidden table inet.0 command to check for any unusable routes in the default routing table.

[edit routing-instances R5-1 protocols bgp group ibgp]lab@mxA-1# run show route hidden table inet.0




Question: Are any unusable routes in the default routing table?

Answer: Yes, five unusable routes are present.



Step 1.12

Use the run show route 40.40/24 hidden detail command to display detailed route information and a possible cause for the route to be marked unusable.

[edit routing-instances R5-1 protocols bgp group ibgp]lab@mxA-1# run show route 40.40/24 hidden detail

inet.0: 26 destinations, 32 routes (22 active, 0 holddown, 5 hidden)40.40.0.0/24 (1 entry, 0 announced) BGP Preference: 170/-101 Next hop type: Unusable Address: 0x25e377c Next-hop reference count: 20 State: <Hidden Int Ext> Local AS: 65001 Peer AS: 65001 Age: 11:43 Task: BGP_65001.172.16.1.4+179 AS path: 65020 I Accepted Localpref: 100 Router ID: 172.16.1.4



Question: Does the detail switch in the show route command display any evidence as to why the route is unusable?

Answer: No information in the detailed output helps determine the reason for the route’s unusable status.

Step 1.13

Use the run show route 40.40/24 hidden extensive to display the extensive information and a possible cause for the route to be marked unusable.

[edit routing-instances R5-1 protocols bgp group ibgp]lab@mxA-1# run show route 40.40/24 hidden extensive

inet.0: 26 destinations, 32 routes (22 active, 0 holddown, 5 hidden)40.40.0.0/24 (1 entry, 0 announced) BGP Preference: 170/-101 Next hop type: Unusable Address: 0x25e377c Next-hop reference count: 20 State: <Hidden Int Ext>



Local AS: 65001 Peer AS: 65001 Age: 12:31 Task: BGP_65001.172.16.1.4+179 AS path: 65020 I Accepted Localpref: 100 Router ID: 172.16.1.4 Indirect next hops: 1 Protocol next hop: 172.31.102.1 Indirect next hop: 0 -



Question: Does the extensive output help resolve the problem with the unusable routes?

Answer: The protocol next-hop attribute in the BGP update cannot be resolved in the default routing table. A next-hop self policy must be applied as an IBGP import policy in the R5-Y router.

Step 1.14

Navigate to the [edit policy-options policy-statement next-hop-self] hierarchy and create a policy that will modify the next-hop attribute to the local loopback address.

[edit routing-instances R5-1 protocols bgp group ibgp]lab@mxA-1# top edit policy-options policy-statement next-hop-self

[edit policy-options policy-statement next-hop-self]lab@mxA-1# set term 1 then next-hop self


Step 1.15

Navigate to the [edit routing-instances R5-Y protocols bgp group ibgp] hierarchy and apply the next-hop-self policy as an export policy in the group.

[edit policy-options policy-statement next-hop-self]lab@mxA-1# top edit routing-instances R5-Y protocols bgp group ibgp

[edit routing-instances R5-1 protocols bgp group ibgp]lab@mxA-1# set export next-hop-self




Step 1.16

Navigate to the [edit protocols bgp group rr-cluster] hierarchy and apply the next-hop-self policy as an export policy in the group. Commit the configuration when completed.

[edit routing-instances R5-1 protocols bgp group ibgp]lab@mxA-1# top edit protocols bgp group rr-cluster

[edit protocols bgp group rr-cluster]lab@mxA-1# set export next-hop-self

[edit protocols bgp group rr-cluster]lab@mxA-1# commit commit complete


Step 1.17

Use the run show route 40.40/22 table inet.0 command to display the P3 routes in the default routing table.

[edit protocols bgp group rr-cluster]lab@mxA-1# run show route 40.40/22 table inet.0


40.40.0.0/24 *[BGP/170] 00:02:06, localpref 100, from 172.16.1.4 AS path: 65020 I > to 10.0.10.2 via ge-1/0/4.0 to 10.0.11.2 via ge-1/0/5.040.40.1.0/24 *[BGP/170] 00:02:06, localpref 100, from 172.16.1.4 AS path: 65020 I > to 10.0.10.2 via ge-1/0/4.0 to 10.0.11.2 via ge-1/0/5.040.40.2.0/24 *[BGP/170] 00:02:06, localpref 100, from 172.16.1.4 AS path: 65020 I > to 10.0.10.2 via ge-1/0/4.0 to 10.0.11.2 via ge-1/0/5.040.40.3.0/24 *[BGP/170] 00:02:06, localpref 100, from 172.16.1.4 AS path: 65020 I > to 10.0.10.2 via ge-1/0/4.0 to 10.0.11.2 via ge-1/0/5.0




Question: Are the P3 routes active in the default routing table?

Answer: Yes, the P3 routes are now active in the default routing table.

Step 1.18

Use the run traceroute 40.40.1.1 source 172.16.Y.1 ttl 10 command to verify connectivity to the 40.40.1.1 address on the P3 router. Be sure to source the traceroute from your default router’s loopback address.

[edit protocols bgp group rr-cluster]lab@mxA-1# run traceroute 40.40.1.1 source 172.16.Y.1 ttl 10 traceroute to 40.40.1.1 (40.40.1.1) from 172.16.1.1, 10 hops max, 40 byte

packets 1 10.0.10.2 (10.0.10.2) 0.408 ms 0.316 ms 0.290 ms 2 10.0.10.1 (10.0.10.1) 0.289 ms 0.294 ms 0.281 ms 3 10.0.10.2 (10.0.10.2) 0.298 ms 0.305 ms 0.295 ms 4 10.0.10.1 (10.0.10.1) 0.304 ms 0.312 ms 0.303 ms 5 10.0.10.2 (10.0.10.2) 0.315 ms 0.320 ms 0.321 ms 6 10.0.10.1 (10.0.10.1) 0.325 ms 0.326 ms 0.320 ms 7 10.0.10.2 (10.0.10.2) 0.338 ms 0.336 ms 0.333 ms 8 10.0.10.1 (10.0.10.1) 0.334 ms 0.343 ms 0.336 ms 9 10.0.10.2 (10.0.10.2) 0.348 ms 0.352 ms 0.347 ms10 10.0.10.1 (10.0.10.1) 0.348 ms 59.994 ms 0.374 ms


Question: Does a problem exist in the path to the P3 router?

Answer: A routing loop has been formed between the R3-Y router and the R4-Y router. The loop is caused by the next-hop-self export policy in the route reflector. When configuring export policies in the route reflector, the match condition must be very specific to only change attributes from the EBGP peers.

Step 1.19

Enter configuration mode and navigate to the [edit policy-options policy-statement next-hop-self] hierarchy. Modify the policy to change only the next-hop attribute if the BGP routes are external routes. Use the match condition route-type to accomplish this task. Commit the change when completed.



[edit protocols bgp group rr-cluster]lab@mxA-1# top edit policy-options policy-statement next-hop-self

[edit policy-options policy-statement next-hop-self]lab@mxA-1# set term 1 from protocol bgp

[edit policy-options policy-statement next-hop-self]lab@mxA-1# set term 1 from route-type external

[edit policy-options policy-statement next-hop-self]lab@mxA-1# commit commit complete


Step 1.20

Use the run traceroute 40.40.1.1 source 172.16.Y.1 ttl 10 command to verify connectivity to the 40.40.1.1 address on the P3 router. Be sure to source the traceroute from your default router’s loopback address.

[edit policy-options policy-statement next-hop-self]lab@mxA-1# run traceroute 40.40.1.1 source 172.16.Y.1 ttl 10traceroute to 40.40.1.1 (40.40.1.1) from 172.16.1.1, 10 hops max, 40 byte

packets 1 10.0.10.2 (10.0.10.2) 0.415 ms 0.307 ms 0.295 ms 2 10.0.12.2 (10.0.12.2) 0.305 ms 0.308 ms 0.298 ms 3 40.40.1.1 (40.40.1.1) 0.460 ms 0.405 ms 0.399 ms


Question: Is the traceroute reaching the P3 router?

Answer: Yes. The next-hop-self policy change is only changing EBGP routes and not the routes being reflected by the route reflector. Your traceroute path might vary.

Step 1.21

Use the run show route 40.40/24 table R4-Y.inet.0 detail command to display the P3 route in the R4-Y routing table.

[edit policy-options policy-statement next-hop-self]lab@mxA-1# run show route 40.40/24 table R4-Y.inet.0 detail

R4-1.inet.0: 21 destinations, 26 routes (21 active, 0 holddown, 0 hidden)40.40.0.0/24 (1 entry, 1 announced) *BGP Preference: 170/-101 Next hop type: Indirect Address: 0x28c3e9c



Next-hop reference count: 12 Source: 172.16.1.1 Next hop type: Router, Next hop index: 692 Next hop: 10.0.13.2 via ge-1/0/7.0, selected Protocol next hop: 172.16.1.4 Indirect next hop: 28cb5a0 1048582 State: <Active Int Ext> Local AS: 65001 Peer AS: 65001 Age: 24:00 Metric2: 1 Task: BGP_65001.172.16.1.1+49990 Announcement bits (2): 2-KRT 6-Resolve tree 7 AS path: 65020 I (Originator) Cluster list: 172.16.1.1 AS path: Originator ID: 172.16.1.4 Accepted Localpref: 100 Router ID: 172.16.1.1


Question: The P3 route is being reflected to the R3-Y and R4-Y routers. What is the value of the cluster list and the originator ID?

Answer: The cluster list is 172.16.Y.1, which is the cluster ID configured in the BGP cluster group. The originator ID is 172.16.Y.4, which is the peer address of the R4-Y router.

Step 1.22

Use the run show route 30.30/24 table R4-Y.inet.0 detail command to display the P1 route in the R4-Y routing table.

[edit policy-options policy-statement next-hop-self]lab@mxA-1# run show route 30.30/24 table R4-Y.inet.0 detail

R4-1.inet.0: 21 destinations, 26 routes (21 active, 0 holddown, 0 hidden)30.30.0.0/24 (1 entry, 1 announced) *BGP Preference: 170/-101 Next hop type: Indirect Address: 0x28c3d6c Next-hop reference count: 15 Source: 172.16.1.1 Next hop type: Router, Next hop index: 696 Next hop: 10.0.11.1 via ge-1/1/5.0, selected Protocol next hop: 172.16.1.1 Indirect next hop: 28c41e0 1048576 State: <Active Int Ext> Local AS: 65001 Peer AS: 65001 Age: 39:46 Metric2: 1 Task: BGP_65001.172.16.1.1+49990



Announcement bits (2): 2-KRT 6-Resolve tree 7 AS path: 65412 I Accepted Localpref: 100 Router ID: 172.16.1.1


Question: Is this route being advertised or reflected to the R4 router?

Answer: Because this route does not have a cluster list or an originator ID, it is being advertised to the R4-Y router and not reflected.

Part 2: Configuring Confederations

In this lab part, you configure an internal network operating with a confederation. It will break the network up into smaller pieces called sub-AS or member-AS networks. Each sub-AS is assigned a unique AS number and operates as an independent internal network that must follow the IBGP rules, requiring a full mesh or route reflection topology. Connectivity between the sub-AS networks uses a modified form of EBGP named confederation BGP (CBGP). CBGP peers prepend the sub-AS number to the AS path attribute as routing updates are exchanged, which is used to prevent routing loops. Remember to switch to the “Lab 10: Scaling BGP Part 2” diagram.

Step 2.1

Navigate to the top of the configuration and load the device’s reset configuration by issuing the load override ajspr/lab10-part2-start.config command. After the configuration has been loaded, commit the changes and return to operational mode.

Note

The BGP confederation topology requires you to display information in the different logical routers known as logical-systems. Each logical router has its own routing daemon. Essentially, it allows multiple routers in the same physical chassis. When referencing a logical router, the commands need to include the logical-system R#-Y, where # is the router number and Y is the user number (1 or 2). Refer to the lab diagram for the correct router and user number.



[edit policy-options policy-statement next-hop-self]lab@mxA-1# top

[edit]lab@mxA-1# load override ajspr/lab10-part2-start.configload complete


lab@mxA-1>

Step 2.2

Use the show ospf neighbor command to verify OSPF reachability from the default router to the R3-Y and R4-Y routers.

lab@mxA-1> show ospf neighborAddress Interface State ID Pri Dead10.0.10.2 ge-1/0/4.0 Full 172.16.1.2 128 3310.0.11.2 ge-1/0/5.0 Full 172.16.1.3 128 30

lab@mxA-1>

Question: Are the OSPF neighbor adjacencies established?

Answer: The OSPF adjacencies between the default router and the R3-Y and R4-Y routers are in the Full state and therefore established.

Step 2.3

Use the show ospf neighbor logical-system R5-Y command to verify OSPF reachability between the R5-Y router and the R3-Y and R4-Y routers.

lab@mxA-1> show ospf neighbor logical-system R5-YAddress Interface State ID Pri Dead10.0.12.1 ge-1/1/6.0 Full 172.16.1.2 128 3910.0.13.1 ge-1/1/7.0 Full 172.16.1.3 128 38

lab@mxA-1>

Note

Four logical routers are configured. The default routing instance is considered its own logical router. The other three, R3-Y, R4-Y, and R5-Y are defined in the logical-system hierarchy.



Question: Are the OSPF neighbor adjacencies established?

Answer: Yes. The OSPF neighbor state is Full between the R5-Y router and the R3-Y and R4-Y routers.

Step 2.4

Enter configuration mode and navigate to the [edit routing-options] hierarchy. Set the autonomous system number to the sub-AS value, 6510Y. Configure the confederation global autonomous system number (6500Y) and the two member AS numbers (6510Y and 6520Y). Refer to the lab diagram for the correct sub-AS and global autonomous system numbers.


[edit]lab@mxA-1# edit routing-options

[edit routing-options]lab@mxA-1# set autonomous-system 6510Y

[edit routing-options]lab@mxA-1# set confederation 6500Y members 6510Y

[edit routing-options]lab@mxA-1# set confederation 6500Y members 6520Y


Step 2.5

Navigate to the [edit protocols bgp group ibgp] hierarchy and configure an internal peer session to the R3-Y router using the loopback addresses. Also apply the next-hop-self policy as an export group policy.

[edit routing-options]lab@mxA-1# top edit protocols bgp group ibgp

[edit protocols bgp group ibgp]lab@mxA-1# set type internal

[edit protocols bgp group ibgp]lab@mxA-1# set local-address 172.16.Y.1

[edit protocols bgp group ibgp]lab@mxA-1# set neighbor 172.16.Y.2

[edit protocols bgp group ibgp]lab@mxA-1# set export next-hop-self



[edit protocols bgp group ibgp]lab@mxA-1#

Step 2.6

Navigate to the [edit logical-systems R3-Y routing-options] hierarchy and set the autonomous system number to the sub-AS 6510Y. Configure the confederation global autonomous system number (6500Y) and the two member AS numbers (6510Y and 6520Y). Refer to the lab diagram for the correct sub-AS and global autonomous system numbers.

[edit protocols bgp group ibgp]lab@mxA-1# top edit logical-systems R3-Y routing-options

[edit logical-systems R3-1 routing-options]lab@mxA-1# set autonomous-system 6510Y

[edit logical-systems R3-1 routing-options]lab@mxA-1# set confederation 6500Y members 6510Y


[edit logical-systems R3-1 routing-options]lab@mxA-1#

Step 2.7

Navigate to the [edit logical-systems R3-Y protocols bgp group ibgp] hierarchy and configure an internal peer session to the default router using loopback addresses. Commit the configuration when completed.

[edit logical-systems R3-1 routing-options]lab@mxA-1# up 1 edit protocols bgp group ibgp

[edit logical-systems R3-1 protocols bgp group ibgp]lab@mxA-1# set type internal

[edit logical-systems R3-1 protocols bgp group ibgp]lab@mxA-1# set local-address 172.16.Y.2

[edit logical-systems R3-1 protocols bgp group ibgp]lab@mxA-1# set neighbor 172.16.Y.1

[edit logical-systems R3-1 protocols bgp group ibgp]lab@mxA-1# commit commit complete

[edit logical-systems R3-1 protocols bgp group ibgp]lab@mxA-1#

Step 2.8

Use the run show bgp summary command to display the BGP peer sessions.

[edit logical-systems R3-1 protocols bgp group ibgp]lab@mxA-1# run show bgp summary



Groups: 2 Peers: 2 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 5 5 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn

State|#Active/Received/Accepted/Damped...172.16.1.2 65101 7 10 0 0 2:17 0/

0/0/0 0/0/0/0172.22.121.2 65412 8 8 0 0 2:17 5/

5/5/0 0/0/0/0


Question: Is the IBGP peer session between the default router and the R3-Y router established?

Answer: Yes, the IBGP peer session between the default router and the R3-Y router is established. If the peer is not established, check the configuration or contact your instructor.

Step 2.9

Use the run show bgp summary logical-system R3-Y command to display the BGP peer sessions in the R3-Y router.

[edit logical-systems R3-1 protocols bgp group ibgp]lab@mxA-1# run show bgp summary logical-system R3-Y Groups: 1 Peers: 1 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 5 5 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn


5/5/0 0/0/0/0


Question: How many routes are being received from the default router in the R3-Y router?

Answer: The R3 router is receiving 5 active routes from the default router.



Question: What is the name of the routing table in the R3-Y router?

Answer: The name of the table is “inet.0.” Because each logical router has its own routing daemon, each logical router has its own inet.0 routing table.

Step 2.10

Navigate to the [edit logical-systems R4-Y routing-options] hierarchy. Set the AS number to the sub-AS 6520Y. Configure the confederation global AS number (6500Y) and the two member AS numbers (6510Y and 6520Y). Refer to the lab diagram for the correct sub-AS and global AS numbers.

[edit logical-systems R3-1 protocols bgp group ibgp]lab@mxA-1# top edit logical-systems R4-Y routing-options





Step 2.11

Navigate to the [edit logical-systems R4-Y protocols bgp group ibgp] hierarchy and configure an internal peer session to the R5-Y router using loopback addresses.








Step 2.12

Navigate to the [edit logical-systems R5-Y routing-options] hierarchy and set the AS number to the sub-AS 6520Y. Configure the confederation global AS number (6500Y) and the two member AS numbers (6510Y and 6520Y). Refer to the lab diagram for the correct sub-AS and global AS numbers.

[edit logical-systems R4-1 protocols bgp group ibgp]lab@mxA-1# top edit logical-systems R5-Y routing-options





Step 2.13

Navigate to the [edit logical-systems R5-Y protocols bgp group ibgp] hierarchy and configure an internal peer session to the R4-Y router using the loopback addresses. Also configure the next-hop-self policy as a group export policy. Commit the configuration when completed.





[edit logical-systems R5-1 protocols bgp group ibgp]lab@mxA-1# set export next-hop-self

[edit logical-systems R5-1 protocols bgp group ibgp]lab@mxA-1# commit commit complete


Step 2.14

Use the run show bgp summary logical-system R5-Y command to verify that the peer session between the R4-Y router and the R5-Y router is established.





0/0/0 0/0/0/0172.31.102.1 65020 10 11 0 0 3:34 4/

4/4/0 0/0/0/0


Question: Are the BGP peer sessions established to the R4-Y router and the P3 router?

Answer: Both the EBGP session to P3 and the IBGP session to R4-Y are established. If the peering sessions are not established, check your configuration and consult with your instructor.

Step 2.15

Use the run show bgp summary logical-system R4-Y command to verify that the R5-Y router is advertising routes to the R4-Y peer.



5/5/0 0/0/0/0


Question: Is the R4-Y router receiving routes from the R5-Y peer? How many of the routes are active?

Answer: The R4-Y router is receiving five active routes from the R5-Y peer.



Step 2.16

Navigate to the [edit protocols bgp group cbgp] hierarchy. Configure a confederation BGP session between the default router and the R5-Y router. Because the CBGP session will be using loopback addresses to peer, both the local-address and multihop commands are required to establish the session.

[edit logical-systems R5-1 protocols bgp group ibgp]lab@mxA-1# top edit protocols bgp group cbgp

[edit protocols bgp group cbgp]lab@mxA-1# set type external

[edit protocols bgp group cbgp]lab@mxA-1# set multihop

[edit protocols bgp group cbgp]lab@mxA-1# set local-address 172.16.Y.1

[edit protocols bgp group cbgp]lab@mxA-1# set neighbor 172.16.Y.4

[edit protocols bgp group cbgp]lab@mxA-1# set peer-as 6520Y

[edit protocols bgp group cbgp]lab@mxA-1#

Step 2.17

Navigate to the [edit logical-systems R5-Y protocols bgp group cbgp] hierarchy and configure the confederation BGP session to the default router.

[edit protocols bgp group cbgp]lab@mxA-1# top edit logical-systems R5-Y protocols bgp group cbgp

[edit logical-systems R5-1 protocols bgp group cbgp]lab@mxA-1# set type external

[edit logical-systems R5-1 protocols bgp group cbgp]lab@mxA-1# set multihop

[edit logical-systems R5-1 protocols bgp group cbgp]lab@mxA-1# set local-address 172.16.Y.4

[edit logical-systems R5-1 protocols bgp group cbgp]lab@mxA-1# set neighbor 172.16.Y.1

[edit logical-systems R5-1 protocols bgp group cbgp]lab@mxA-1# set peer-as 6510Y

[edit logical-systems R5-1 protocols bgp group cbgp]lab@mxA-2# commit commit complete



[edit logical-systems R5-1 protocols bgp group cbgp]lab@mxA-2#

Step 2.18

Use the run show bgp summary command to display the bgp peering sessions in the default router.

[edit logical-systems R5-1 protocols bgp group cbgp]lab@mxA-1# run show bgp summary Groups: 3 Peers: 3 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 10 5 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn


0/0/0 0/0/0/0172.16.1.4 65201 10 11 0 0 3:08 0/

5/5/0 0/0/0/0172.22.121.2 65412 101 103 0 0 45:36 5/

5/5/0 0/0/0/0


Question: Does the default router have an established CBGP peer session with the R5-Y router?

Answer: Yes, the CBGP peer session with R5-Y is established. If the peer session is not established, check the configuration and consult with your instructor.

Question: How many routes are being received from the R5-Y router? How many routes are active from R5-Y?

Answer: Five routes being are received from the R5-Y router, however none of the routes are active.

Step 2.19

Use the run show route receive-protocol bgp 172.16.Y.4 detail command to display the routes being received from the R5 router.



[edit logical-systems R5-1 protocols bgp group cbgp]lab@mxA-1# run show route receive-protocol bgp 172.16.Y.4 detail



Question: How many received routes from R5-Y are hidden?

Answer: All five received routes are hidden.

Step 2.20

Use the run show route hidden command to display the hidden routes in the default router's routing table.

[edit logical-systems R5-1 protocols bgp group cbgp]lab@mxA-1# run show route hidden


40.40.0.0/24 [BGP/170] 00:05:28, localpref 100, from 172.16.1.4 AS path: (65201) 65020 I Unusable40.40.1.0/24 [BGP/170] 00:05:28, localpref 100, from 172.16.1.4 AS path: (65201) 65020 I Unusable40.40.2.0/24 [BGP/170] 00:05:28, localpref 100, from 172.16.1.4 AS path: (65201) 65020 I Unusable40.40.3.0/24 [BGP/170] 00:05:28, localpref 100, from 172.16.1.4 AS path: (65201) 65020 I Unusable172.16.2.0/24 [BGP/170] 00:05:28, localpref 100, from 172.16.1.4 AS path: (65201) 65020 65002 I Unusable




Question: Why are the routes received from the R5-Y router marked as unusable?

Answer: The next-hop attribute in the routes being received from the R5-Y router cannot be resolved in the default routing table. CBGP peer sessions do not change any of the BGP attributes except the AS path.

Step 2.21

Configure the next-hop-self policy as the group export policy. Commit the configuration and return to operational mode.

[edit logical-systems R5-1 protocols bgp group cbgp]lab@mxA-1# set export next-hop-self

[edit logical-systems R5-1 protocols bgp group cbgp]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 2.22

Use the show route receive-protocol bgp 172.16.Y.4 command to display the routes being received from the R5-Y router.

lab@mxA-1> show route receive-protocol bgp 172.16.Y.4

inet.0: 26 destinations, 27 routes (26 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 40.40.0.0/24 172.16.1.4 100 (65201) 65020 I* 40.40.1.0/24 172.16.1.4 100 (65201) 65020 I* 40.40.2.0/24 172.16.1.4 100 (65201) 65020 I* 40.40.3.0/24 172.16.1.4 100 (65201) 65020 I 172.16.2.0/24 172.16.1.4 100 (65201) 65020

65002 I

lab@mxA-1>

Question: Are the routes being received from R5-Y active routes?

Answer: The five routes being received from R5-Y are active routes.



Step 2.23


lab@mxA-1> exit



Lab 11BGP Route Damping (Detailed)

Overview

In this lab, you will use the lab diagram titled “Lab 11: BGP Route Damping” to monitor the EBGP-received routes for any link flapping that might occur within the network. Route damping monitors the behavior of EBGP-received routes being withdrawn and readvertised. It uses a point system known as figure-of-merit to determine whether routes should be installed and advertised into the IBGP topology, or suppressed at the edge.


• Create a static route.

• Modify the export policies to advertise the static route.

• Configure damping in the default router.

• Flap the static route for your partner.

• Configure policy to alter the default damping parameters.

• Apply the policy as an EBGP import policy.

www.juniper.net BGP Route Damping (Detailed) • Lab 11–111.a.11.4R1.14


Part 1: Modifying IBGP Redistribution

In this lab part, you modify the IBGP routing policy, redistributing all static routes between the default router and the R3-Y router. The redistribute-statics export policy must be modified to advertise only the 172.16.Y.0/24 specific routes between the routing instances in your student device.

Step 1.1


Step 1.2


Note



Lab 11–2 • BGP Route Damping (Detailed) www.juniper.net


mxA-1 (ttyu0)

login: labPassword:


Step 1.3





lab@mxA-1#

Step 1.4







Enter configuration mode and navigate to the [edit policy-options policy-statement redistribute-statics] hierarchy. Modify the policy to ensure that only the specific 172.16.Y.0/24 routes are redistributed. Commit the change when completed.

[edit]lab@mxA-1# edit policy-options policy-statement redistribute-statics

[edit policy-options policy-statement redistribute-statics]lab@mxA-1# set term 1 from route-filter 172.16.Y.0/24 longer

www.juniper.net BGP Route Damping (Detailed) • Lab 11–3


[edit policy-options policy-statement redistribute-statics]lab@mxA-1# commit commit complete


Step 1.5

Use the run show route 172.16.Y.0/24 table inet.0 command to display the aggregate route and the redistributed static routes.

[edit policy-options policy-statement redistribute-statics]lab@mxA-1# run show route 172.16.Y.0/24 table inet.0


172.16.1.0/24 *[Aggregate/130] 00:19:49 Reject172.16.1.0/26 *[Static/5] 00:19:49 Reject172.16.1.1/32 *[Direct/0] 00:19:48 > via lo0.0172.16.1.2/32 *[OSPF/10] 00:18:57, metric 1 > to 10.0.10.2 via ge-1/0/4.0172.16.1.64/26 *[Static/5] 00:19:06 Reject172.16.1.128/26 *[BGP/170] 00:18:54, localpref 100, from 172.16.1.2 AS path: I > to 10.0.10.2 via ge-1/0/4.0172.16.1.192/26 *[BGP/170] 00:18:54, localpref 100, from 172.16.1.2 AS path: I > to 10.0.10.2 via ge-1/0/4.0


Question: Are the aggregate route and all six specific routes visible in the default routing table?

Answer: Yes. The aggregate route and all six of the specific routes are visible in the default routing table.



Question: Which protocols are advertising the specific routes?

Answer: Two of the routes are static routes, one is a directly connected route, one is an OSPF route, and two are BGP routes.

Part 2: Configuring BGP Damping

In this lab part, you create and advertise a static route to the P1 and P2 routers that will propagate the route through EBGP to your partner’s default router. After damping is enabled in the default router, you and your partner will flap the route by deleting the static route and adding it back.

Step 2.1

Navigate to the [edit routing-options] hierarchy. Configure a 172.22.Y.0/24 static route with a next hop of reject.

[edit policy-options policy-statement redistribute-statics]lab@mxA-1# top edit routing-options

[edit routing-options]lab@mxA-1# set static route 172.22.Y.0/24 reject


Step 2.2

Navigate to the [edit policy-options policy-statement export-p1] hierarchy and configure a third term in the policy to advertise the static route. Use the show command to display the policy.

[edit routing-options]lab@mxA-1# top edit policy-options policy-statement export-p1

[edit policy-options policy-statement export-p1]lab@mxA-1# set term 3 from protocol static

[edit policy-options policy-statement export-p1]lab@mxA-1# set term 3 from route-filter 172.22.Y.0/24 exact

[edit policy-options policy-statement export-p1]lab@mxA-1# set term 3 then accept

[edit policy-options policy-statement export-p1]lab@mxA-1# showterm 1 { from { protocol aggregate; route-filter 172.16.1.0/24 exact;



} then { community set 65001:100; accept; }}term 2 { from { route-filter 172.16.1.0/24 longer; } then reject;}term 3 { from { protocol static; route-filter 172.22.1.0/24 exact; } then accept;}


Step 2.3

Navigate to the [edit policy-options policy-statement export-p2] hierarchy and configure a third term in the policy to advertise the static route. Use the show command to display the policy. Commit the changes when completed.


[edit policy-options policy-statement export-p2]lab@mxA-1# set term 3 from protocol static

[edit policy-options policy-statement export-p2]lab@mxA-1# set term 3 from route-filter 172.22.Y.0/24 exact

[edit policy-options policy-statement export-p2]lab@mxA-1# set term 3 then accept

[edit policy-options policy-statement export-p2]lab@mxA-1# showterm 1 { from { protocol aggregate; route-filter 172.16.1.0/24 exact; } then { community set 65001:120; accept; }}term 2 { from { route-filter 172.16.1.0/24 longer;



} then reject;}term 3 { from { protocol static; route-filter 172.22.1.0/24 exact; } then accept;}

[edit policy-options policy-statement export-p2]lab@mxA-1# commit commit complete


Step 2.4

Use the run show route 172.22.R.0/24 table inet.0 to display your partner’s advertised route in the default routing table.

[edit policy-options policy-statement export-p2]lab@mxA-1# run show route 172.22.R.0/24 table inet.0


172.22.2.0/24 *[BGP/170] 00:00:35, localpref 100 AS path: 65412 65002 I > to 172.22.123.2 via ge-1/0/0.1113 [BGP/170] 00:00:35, localpref 100 AS path: 65412 65002 I > to 172.22.121.2 via ge-1/0/0.1111


Question: Is your partner’s route an active BGP route in your default routing table?

Answer: Your partner’s route should be an active BGP route in the default routing table. If the route is not active, consult with your partner or your instructor.

Step 2.5

Navigate to the [edit protocols bgp] hierarchy. Enable BGP damping as a global command. Commit the change.



[edit policy-options policy-statement export-p2]lab@mxA-1# top edit protocols bgp

[edit protocols bgp]lab@mxA-1# set damping

[edit protocols bgp]lab@mxA-1# commitcommit complete


Step 2.6

Navigate to the [edit routing-options] hierarchy. Coordinate with the remote team to cause the 172.22.Y.0/24 route to flap by deleting the static route. Commit the change when you are ready.

[edit protocols bgp]lab@mxA-1# top edit routing-options

[edit routing-options]lab@mxA-1# delete static route 172.22.Y.0/24

[edit routing-options]lab@mxA-1# commit commit complete


Step 2.7

Use the run show route damping history table inet.0 detail command to display routes that are withdrawn but have a history of figure-of-merit in the default routing table.

[edit routing-options]lab@mxA-1# run show route damping history table inet.0 detail

inet.0: 26 destinations, 32 routes (25 active, 0 holddown, 2 hidden)172.22.2.0/24 (2 entries, 0 announced) BGP /-101 Next hop type: Router, Next hop index: 760 Address: 0x28b4308 Next-hop reference count: 6 Source: 172.22.121.2 Next hop: 172.22.121.2 via ge-1/0/0.1111, selected State: <Hidden Ext> Local AS: 65001 Peer AS: 65412 Age: 9:22 Task: BGP_65412.172.22.121.2+179 AS path: 65412 65002 I Accepted Localpref: 100 Router ID: 172.31.100.1



Merit (last update/now): 1000/812 Default damping parameters used Last update: 00:04:30 First update: 00:04:30 Flaps: 1 History entry. Expires in: 00:30:20 BGP /-101 Next hop type: Router, Next hop index: 547 Address: 0x28b405c Next-hop reference count: 16 Source: 172.22.123.2 Next hop: 172.22.123.2 via ge-1/0/0.1113, selected State: <Hidden Ext> Local AS: 65001 Peer AS: 65412 Age: 9:22 Task: BGP_65412.172.22.123.2+179 AS path: 65412 65002 I Accepted Localpref: 100 Router ID: 172.31.101.1 Merit (last update/now): 1000/812 Default damping parameters used Last update: 00:04:30 First update: 00:04:30 Flaps: 1 History entry. Expires in: 00:30:20


Question: Do any withdrawn routes have a history of figure-of-merit?

Answer: If your partner has deleted the static route, a withdrawn route will have figure-of-merit. If no routes have been withdrawn, check with your partner or instructor.

Question: What is the current figure-of-merit for this withdrawn route?

Answer: In this example, the current figure-of-merit is 812. This value will change based on the half-life parameter and the amount of time that has elapsed.



STOP Wait for your partner to complete the previous step before continuing.

Step 2.8

Navigate to the top of the configuration and perform a rollback 1 to readvertise the static route. Commit the configuration when completed.

[edit routing-options]lab@mxA-1# top

[edit]lab@mxA-1# rollback 1 load complete


[edit]lab@mxA-1#

Step 2.9

Use the run show route damping decayed table inet.0 detail command to show active routes that are decaying but not suppressed.

[edit]lab@mxA-1# run show route damping decayed table inet.0 detail

inet.0: 27 destinations, 33 routes (27 active, 0 holddown, 0 hidden)172.22.2.0/24 (2 entries, 1 announced) *BGP Preference: 170/-101 Next hop type: Router, Next hop index: 760 Address: 0x28b4308 Next-hop reference count: 8 Source: 172.22.121.2 Next hop: 172.22.121.2 via ge-1/0/0.1111, selected State: <Active Ext> Local AS: 65001 Peer AS: 65412 Age: 1:29 Task: BGP_65412.172.22.121.2+179 Announcement bits (3): 0-KRT 4-BGP RT Background 8-Resolve tree 5 AS path: 65412 65002 I Accepted Localpref: 100 Router ID: 172.31.100.1 Merit (last update/now): 1616/1519 Default damping parameters used Last update: 00:01:29 First update: 00:09:35 Flaps: 2 BGP Preference: 170/-101 Next hop type: Router, Next hop index: 547 Address: 0x28b405c Next-hop reference count: 16



Source: 172.22.123.2 Next hop: 172.22.123.2 via ge-1/0/0.1113, selected State: <NotBest Ext> Inactive reason: Not Best in its group - Active preferred Local AS: 65001 Peer AS: 65412 Age: 1:29 Task: BGP_65412.172.22.123.2+179 AS path: 65412 65002 I Accepted Localpref: 100 Router ID: 172.31.101.1 Merit (last update/now): 1616/1519 Default damping parameters used Last update: 00:01:29 First update: 00:09:35 Flaps: 2

[edit]lab@mxA-1#

Question: Are there routes decaying but not suppressed?

Answer: If your partner has performed the rollback, the static route should be an active route in the default routing table with decaying figure-of-merit.

Question: How many flaps have occurred on the active route?

Answer: Only 2 flaps have occurred for this route: a withdrawn route and readvertised route.


Step 2.10

Flap the route 4 times using the rollback 1 and commit commands.

[edit]lab@mxA-1# rollback 1load complete










lab@mxA-1#

Step 2.11

Use the run show route damping suppressed table inet.0 detail command to display routes that have been suppressed due to damping in the default routing table.

[edit]lab@mxA-1# run show route damping suppressed table inet.0 detail

inet.0: 27 destinations, 33 routes (26 active, 0 holddown, 2 hidden)172.22.2.0/24 (2 entries, 0 announced) BGP /-101 Next hop type: Router, Next hop index: 760 Address: 0x28b4308 Next-hop reference count: 6 Source: 172.22.121.2 Next hop: 172.22.121.2 via ge-1/0/0.1111, selected State: <Hidden Ext> Local AS: 65001 Peer AS: 65412 Age: 34 Task: BGP_65412.172.22.121.2+179 AS path: 65412 65002 I Localpref: 100 Router ID: 172.31.100.1 Merit (last update/now): 5092/4975 Default damping parameters used Last update: 00:00:34 First update: 00:14:03 Flaps: 6 Suppressed. Reusable in: 00:41:00



Preference will be: 170 BGP /-101 Next hop type: Router, Next hop index: 547 Address: 0x28b405c Next-hop reference count: 16 Source: 172.22.123.2 Next hop: 172.22.123.2 via ge-1/0/0.1113, selected State: <Hidden Ext> Local AS: 65001 Peer AS: 65412 Age: 34 Task: BGP_65412.172.22.123.2+179 AS path: 65412 65002 I Localpref: 100 Router ID: 172.31.101.1 Merit (last update/now): 5092/4975 Default damping parameters used Last update: 00:00:34 First update: 00:14:03 Flaps: 6 Suppressed. Reusable in: 00:41:00 Preference will be: 170

[edit]lab@mxA-1#

Question: Have any routes in the default routing table been suppressed because of damping?

Answer: After your partner has completed the 4 flaps in the previous step, the static route should be suppressed in the default routing table. If the route is not suppressed, check with your partner or the instructor.

Question: If no other flaps occur, what is the estimated reuse time for this route?

Answer: In this example, the estimated reuse time is 00:41:00 minutes, which is calculated based on the amount of figure-of-merit and the half-life time.




Part 3: Modifying the BGP Damping Parameters

In this lab part, you use routing policy to modify the default damping parameters. You create an import policy to disable damping on routes received from the P1 router, and another policy to aggressively damp routes received from the P2 router.

Step 3.1

Navigate to the [edit policy-options] hierarchy. Create and configure two damping profiles named disable and aggressive. The disable profile should use the disable option. The aggressive profile should set the suppress parameter to 1500, half-life to 10 minutes, and the reuse parameter to 500.

[edit]lab@mxA-1# edit policy-options

[edit policy-options]lab@mxA-1# set damping disable disable

[edit policy-options]lab@mxA-1# set damping aggressive suppress 1500

[edit policy-options]lab@mxA-1# set damping aggressive half-life 10

[edit policy-options]lab@mxA-1# set damping aggressive reuse 500


Step 3.2

Navigate to the [edit policy-options policy-statement modify-damping] hierarchy. Configure the first term of the modify-damping import policy to use the disable profile on all BGP routes received from the P1 neighbor. Configure the second term to use the aggressive profile on all routes received from the P2 neighbor. Use the show command to display the policy.

[edit policy-options]lab@mxA-1# edit policy-statement modify-damping

[edit policy-options policy-statement modify-damping]lab@mxA-1# set term 1 from protocol bgp

[edit policy-options policy-statement modify-damping]lab@mxA-1# set term 1 from neighbor 172.22.12V.2

[edit policy-options policy-statement modify-damping]lab@mxA-1# set term 1 then damping disable

[edit policy-options policy-statement modify-damping]lab@mxA-1# set term 2 from protocol bgp

[edit policy-options policy-statement modify-damping]lab@mxA-1# set term 2 from neighbor 172.22.12V.2



[edit policy-options policy-statement modify-damping]lab@mxA-1# set term 2 then damping aggressive

[edit policy-options policy-statement modify-damping]lab@mxA-1# showterm 1 { from { protocol bgp; neighbor 172.22.121.2; } then damping disable;}term 3 { from { protocol bgp; neighbor 172.22.123.2; } then damping aggressive;}

[edit policy-options policy-statement modify-damping]lab@mxA-1#

Step 3.3

Navigate to the [edit protocols bgp group P1-P2] hierarchy and apply the modify-damping policy as a group import policy. Commit the changes when completed.

[edit policy-options policy-statement modify-damping]lab@mxA-1# top edit protocols bgp group P1-P2

[edit protocols bgp group P1-P2]lab@mxA-1# set import modify-damping



Step 3.4

Use the run clear bgp damping command to reset the figure-of-merit to zero on all routes. Use the run show route damping suppress table inet.0 command to verify that all routes are active and no routes are suppressed in the default routing table.

[edit protocols bgp group P1-P2]lab@mxA-1# run clear bgp damping

[edit protocols bgp group P1-P2]lab@mxA-1# run show route damping suppressed table inet.0





Question: Are suppressed routes in the default routing table?

Answer: No suppressed routes are in the default routing table.

Step 3.5

Navigate to the [edit routing-options] hierarchy. Use the delete static route 172.22.Y.0/24 command followed by a commit to flap the route. Use the rollback 1 command followed by a commit to readvertise the route.

[edit protocols bgp group P1-P2]lab@mxA-1# top edit routing-options

[edit routing-options]lab@mxA-1# delete static route 172.22.Y.0/24

[edit routing-options]lab@mxA-1# commitcommit complete

[edit routing-options]lab@mxA-1# top



[edit]lab@mxA-1#

Step 3.6

Use the run show route damping suppress table inet.0 detail command to display any routes suppressed due to damping in the default routing table.

[edit]lab@mxA-1# run show route damping suppressed table inet.0 detail

inet.0: 27 destinations, 33 routes (27 active, 0 holddown, 1 hidden)172.22.2.0/24 (2 entries, 1 announced) BGP /-101



Next hop type: Router, Next hop index: 547 Address: 0x28b405c Next-hop reference count: 16 Source: 172.22.123.2 Next hop: 172.22.123.2 via ge-1/0/0.1113, selected State: <Hidden Ext> Inactive reason: Unusable path Local AS: 65001 Peer AS: 65412 Age: 2:22 Task: BGP_65412.172.22.123.2+179 AS path: 65412 65002 I Localpref: 100 Router ID: 172.31.101.1 Merit (last update/now): 2000/1701 damping-parameters: aggressive Last update: 00:02:22 First update: 00:02:31 Flaps: 2 Suppressed. Reusable in: 00:17:40 Preference will be: 170

[edit]lab@mxA-1#

Question: Are any suppressed routes in the default routing table?

Answer: Yes. One suppressed route is in the default routing table.

Question: In the suppressed route, what is the damping parameter being used to suppress this route?

Answer: The damping parameter being used to suppress this route is aggressive. This parameter is configured in the modify-damping policy for the P2 router.

Step 3.7

Use the run show route 172.22.R.0/24 table inet.0 detail command to verify that the damping policy on the P1 router is disabling damping on received routes.

[edit]lab@mxA-1# run show route 172.22.R.0/24 table inet.0 detail




172.22.2.0/24 (2 entries, 1 announced) *BGP Preference: 170/-101 Next hop type: Router, Next hop index: 760 Address: 0x28b4308 Next-hop reference count: 8 Source: 172.22.121.2 Next hop: 172.22.121.2 via ge-1/0/0.1111, selected State: <Active Ext> Local AS: 65001 Peer AS: 65412 Age: 2:56 Task: BGP_65412.172.22.121.2+179 Announcement bits (3): 0-KRT 4-BGP RT Background 8-Resolve tree 5 AS path: 65412 65002 I Accepted Localpref: 100 Router ID: 172.31.100.1

[edit]lab@mxA-1#

Question: Which EBGP peer is advertising the active route in the default routing table?

Answer: In this example, the source of the active route is 172.22.121.2, which is the BGP peer address of the P1 router.

Step 3.8

Use the run show route damping decayed table inet.0 detail command to display any active routes with figure-of-merit in the default routing table.

[edit]lab@mxA-1# run show route damping decayed table inet.0 detail


[edit]lab@mxA-1#

Question: Is the EBGP import policy that disables damping on the P1 router working?

Answer: Because your partner’s route is active and no figure-of-merit is present, it appears that the import policy applied to the P1 router is disabling damping.



Step 3.9

Issue the load override ajspr/reset.config command to load the reset configuration file, commit the changes and then log out of your assigned device.

[edit]lab@mxA-1# load override ajspr/reset.config load complete

[edit]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1> exit






Appendix A: Lab Diagrams


A–2 • Lab Diagrams www.juniper.net


www.juniper.net Lab Diagrams • A–3











































Documents

Advanced Junos Service Provider Routing