Ajspr 11 A LGD

Advanced Junos Service Provider
Routing
11.a
Detailed Lab Guide
Worldwide Education Services
1194 North Mathilda Avenue

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
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-1
Part 1: Load Reset Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Part 2: Creating the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Part 3: Configuring the OSPF LInk Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Part 4: Configuring Overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
Part 5: Performing Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
Lab 2: Configuring and Monitoring OSPF Areas and

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

Part 1: Establishing the OSPF Adjacencies and Creating a Virtual Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Part 2: Configuring OSPF Multiarea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Part 3: Configuring External Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
Lab 4: IS-IS Configuration and Monitoring (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . 4-1

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

Part 1: Building the Extended IS-IS Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Part 2: Configuring IS-IS Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Part 3: Manipulating IS-IS Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
Part 4: Configuring IS-IS External Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17
Lab 6: Configuring a Multilevel IS-IS Network (Detailed) . . . . . . . . . . . . . . . . . . . . . 6-1

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

Part 1: Establishing the OSPF Adjacency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Part 2: Establishing an IBGP Peering Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Part 3: Configuring the P1 and P2 EBGP Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
Part 4: Configuring the EBGP Session with the P3 Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19
Part 5: Summarizing the Internal Routes to the Peer Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
Lab 8: BGP Attributes: Next Hop, Origin, MED, and AS Path (Detailed) . . . . . . . . . 8-1
Part 1: Repairing Unusable Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Part 2: Modifying the Origin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
Part 3: Configuring the MED Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14
Part 4: Modifying the AS Path Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20
www.juniper.net Contents • iii

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

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

Part 1: Modifying IBGP Redistribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2
Part 2: Configuring BGP Damping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-5
Part 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.
Style Description Usage Example
Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
Courier New Console text:

commit complete
• Screen captures
• Noncommand-related Exiting configuration mode
syntax
GUI text elements:
Select File > Open, and then click
• Menu names Configuration.conf in the
Filename text box.
• Text field entry
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.
Normal CLI No distinguishing variant. Physical interface:fxp0,

Enabled
Normal GUI
View configuration history by clicking
Configuration > History.
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
config.ini in the Filename field.
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.
CLI Variable Text where variable value is already policy my-peers

assigned.
GUI Variable Click my-peers in the dialog.
CLI Undefined Text where the variable’s value is Type set policy policy-name.
the user’s discretion or text where
ping 10.0.x.y
the variable’s value as shown in
GUI Undefined the lab guide might differ from the Select File > Save, and type
value the user must input filename in the Filename field.
according to the lab topology.
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 training@juniper.net.
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 1
OSPF 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–1

11.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.
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.
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:
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: lab
Password:
--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

lab@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-quit
commit complete
Exiting 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 lab
version 11.4R1.14;
system {

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+w4dWXEqaV3bnobzPC4eyxQKBUCOr80Q5YBlWXVBH
x9elwBWZwj0SF4hLKHznExnLerVsMuTMA846RbQmSz62vM6kGM13HFonWeQvWia0TDr78+rOEgWF
2KHBSIxL51lmIDW8Gql9hJfD/Dr/
NKP97w3L0wAAAIEAr3FkWU8XbYytQYEKxsIN9P1UQ1ERXB3G40YwqFO484SlyKyYCfaz+yNsaAJu
2C8UebDIR3GieyNcOAKf3inCG8jQwjLvZskuZwrvlsz/xtcxSoAh9axJcdUfSJYMW/
g+mD26JK1Cliw5rwp2nH9kUrJxeI7IReDp4egNkM4i15o= configurator@server1.he"; ##
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;
}
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 bytes
64 bytes from 172.22.121.2: icmp_seq=0 ttl=64 time=0.598 ms
--- 172.22.121.2 ping statistics ---

5 packets transmitted, 5 packets received, 0% packet loss
round-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 bytes

--- 10.0.1.2 ping statistics ---
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: lab
Password:
--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

lab@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

Reject
20.20.1.0/24 *[Static/5] 03:17:03
Reject
20.20.2.0/24 *[Static/5] 03:17:03
Reject
20.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.
[edit]
lab@mxA-1# edit protocols ospf
[edit protocols ospf]

lab@mxA-1# set area 0 interface lo0.0

lab@mxA-1# set area 0 interface ge-1/0/0.11ZV

lab@mxA-1# set area Y0 interface ge-1/0/4.0

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

lab@mxA-1# set area Y0 interface lo0.1

lab@mxA-1# commit
commit complete

lab@mxA-1#

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.
Step 2.3
Verify the OSPF adjacencies by issuing the run show ospf neighbor
command.
lab@mxA-1> run show ospf neighbor
Address Interface State ID Pri Dead
172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 36
10.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.
lab@mxA-1# run show route

10.0.1.0/24 *[Direct/0] 00:05:02

> via ge-1/0/4.0
10.0.1.1/32 *[Local/0] 00:05:02
Local via ge-1/0/4.0
10.0.2.0/24 *[OSPF/10] 00:02:18, metric 3
> to 172.22.121.2 via ge-1/0/0.1111
10.210.15.0/27 *[Direct/0] 00:36:15
> via fxp0.0
10.210.15.1/32 *[Local/0] 00:36:15
Local via fxp0.0
20.20.0.0/24 *[Static/5] 00:05:02

Reject
20.20.1.0/24 *[Static/5] 00:05:02
Reject
20.20.2.0/24 *[Static/5] 00:05:02
Reject
20.20.3.0/24 *[Static/5] 00:05:02
Reject
172.16.1.1/32 *[Direct/0] 00:36:15
> via lo0.0
172.16.1.2/32 *[OSPF/10] 00:00:32, metric 1
> to 10.0.1.2 via ge-1/0/4.0
172.16.2.1/32 *[OSPF/10] 00:02:18, metric 2
> to 172.22.121.2 via ge-1/0/0.1111
172.16.2.2/32 *[OSPF/10] 00:00:23, metric 3
> to 172.22.121.2 via ge-1/0/0.1111
172.22.121.0/24 *[Direct/0] 00:36:15
> via ge-1/0/0.1111
172.22.121.1/32 *[Local/0] 00:36:15
172.22.122.0/24 *[OSPF/10] 00:02:57, metric 2
> to 172.22.121.2 via ge-1/0/0.1111
172.31.100.1/32 *[OSPF/10] 00:02:57, metric 1
> to 172.22.121.2 via ge-1/0/0.1111
224.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)

10.0.1.0/24 *[Direct/0] 00:05:02

> via ge-1/1/4.0
10.0.1.2/32 *[Local/0] 00:05:02
10.0.2.0/24 *[OSPF/10] 00:00:33, metric 4
> to 10.0.1.1 via ge-1/1/4.0
172.16.1.1/32 *[OSPF/10] 00:00:33, metric 1
> to 10.0.1.1 via ge-1/1/4.0
172.16.1.2/32 *[Direct/0] 00:36:15
> via lo0.1
172.16.2.1/32 *[OSPF/10] 00:00:33, metric 3
> to 10.0.1.1 via ge-1/1/4.0
172.16.2.2/32 *[OSPF/10] 00:00:21, metric 4
> to 10.0.1.1 via ge-1/1/4.0
172.22.121.0/24 *[OSPF/10] 00:00:33, metric 2
> to 10.0.1.1 via ge-1/1/4.0
172.22.122.0/24 *[OSPF/10] 00:00:33, metric 3
> to 10.0.1.1 via ge-1/1/4.0
172.31.100.1/32 *[OSPF/10] 00:00:33, metric 2
> to 10.0.1.1 via ge-1/1/4.0
224.0.0.5/32 *[OSPF/10] 00:03:12, metric 1
MultiRecv

lab@mxA-1#

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.
lab@mxA-1# top edit protocols ospf

lab@mxA-1# set export static-to-ospf

lab@mxA-1# commit
commit complete

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.
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 48
Router 172.16.2.1 172.16.2.1 0x80000055 8 0x22 0x48c6 48
Router 172.31.100.1 172.31.100.1 0x80000048 230 0x22 0xe851 60
Network 172.22.121.2 172.31.100.1 0x80000001 269 0x22 0x409a 32
Network 172.22.122.2 172.31.100.1 0x80000001 230 0x22 0x4296 32
Summary *10.0.1.0 172.16.1.1 0x80000003 108 0x22 0x620e 28
Summary 10.0.2.0 172.16.2.1 0x80000003 103 0x22 0x501e 28
Summary *172.16.1.2 172.16.1.1 0x80000001 108 0x22 0x4f6e 28
Summary 172.16.2.2 172.16.2.1 0x80000001 103 0x22 0x3d7e 28

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

lab@mxA-1#
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.

lab@mxA-1# run show ospf interface detail
Interface State Area DR ID BDR ID Nbrs
ge-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: 0
lo0.0 DR 0.0.0.0 172.16.1.1 0.0.0.0 0
DR addr: 172.16.1.1, Priority: 128
Adj count: 0
Auth type: None
ge-1/0/4.0 BDR 0.0.0.10 172.16.1.2 172.16.1.1 1
Adj count: 1
Auth type: None

lab@mxA-1#
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.
lab@mxA-1# set reference-bandwidth 10g

lab@mxA-1# commit

commit complete

lab@mxA-1#
Step 3.3
Issue the run show ospf interface detail command to see if the link
costs changed.
lab@mxA-1# run show ospf interface detail
ge-1/0/0.1111 BDR 0.0.0.0 172.31.100.1 172.16.1.1 1
Adj count: 1
Auth type: None
lo0.0 DR 0.0.0.0 172.16.1.1 0.0.0.0 0
DR addr: 172.16.1.1, Priority: 128
Adj count: 0
Auth type: None
ge-1/0/4.0 BDR 0.0.0.10 172.16.1.2 172.16.1.1 1
Adj count: 1
Auth type: None
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.

lab@mxA-1# set area 0 interface lo0.0 metric 10000

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 3.5
Enter the run show route 172.16/16 command and examine the routing
table on your student device at this point.
lab@mxA-1# run show route 172.16/16

172.16.1.1/32 *[Direct/0] 00:40:25

> via lo0.0
172.16.1.2/32 *[OSPF/10] 00:01:10, metric 10
> to 10.0.1.2 via ge-1/0/4.0
172.16.2.1/32 *[OSPF/10] 00:00:02, metric 10011
> to 172.22.121.2 via ge-1/0/0.1111
172.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.0
172.16.1.2/32 *[Direct/0] 00:40:25
> via lo0.1
172.16.2.1/32 *[OSPF/10] 00:00:02, metric 10012
> to 10.0.1.1 via ge-1/1/4.0
172.16.2.2/32 *[OSPF/10] 00:01:01, metric 22
> to 10.0.1.1 via ge-1/1/4.0

lab@mxA-1#
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.

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.
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.
lab@mxA-1# set area Y0 interface ge-1/0/4.0 metric 5000

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

lab@mxA-1# commit
commit complete

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.

172.16.1.1/32 *[Direct/0] 00:43:16

> via lo0.0
172.16.1.2/32 *[OSPF/10] 00:01:14, metric 5000
> to 10.0.1.2 via ge-1/0/4.0
172.16.2.1/32 *[OSPF/10] 00:02:53, metric 10011
> to 172.22.121.2 via ge-1/0/0.1111
172.16.2.2/32 *[OSPF/10] 00:00:43, metric 5011
> to 172.22.121.2 via ge-1/0/0.1111

172.16.1.1/32 *[OSPF/10] 00:01:14, metric 12500

> to 10.0.1.1 via ge-1/1/4.0

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

lab@mxA-1#
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.
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.0
10.0.1.2/32 *[Local/0] 00:13:10
10.0.2.0/24 *[OSPF/10] 00:01:50, metric 7511
> to 10.0.1.1 via ge-1/1/4.0
20.20.0.0/24 *[OSPF/150] 00:06:59, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
20.20.1.0/24 *[OSPF/150] 00:06:59, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
20.20.2.0/24 *[OSPF/150] 00:06:59, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
20.20.3.0/24 *[OSPF/150] 00:06:59, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
20.20.4.0/24 *[OSPF/150] 00:06:54, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
20.20.5.0/24 *[OSPF/150] 00:06:54, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
20.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.0
172.16.1.1/32 *[OSPF/10] 00:02:21, metric 12500
> to 10.0.1.1 via ge-1/1/4.0
172.16.1.2/32 *[Direct/0] 00:44:23
> via lo0.1
172.16.2.1/32 *[OSPF/10] 00:02:21, metric 12511
> to 10.0.1.1 via ge-1/1/4.0
172.16.2.2/32 *[OSPF/10] 00:01:50, metric 7511
> to 10.0.1.1 via ge-1/1/4.0
172.22.121.0/24 *[OSPF/10] 00:02:21, metric 2510
> to 10.0.1.1 via ge-1/1/4.0
172.22.122.0/24 *[OSPF/10] 00:02:21, metric 2511
> to 10.0.1.1 via ge-1/1/4.0
172.31.100.1/32 *[OSPF/10] 00:02:21, metric 2510
> to 10.0.1.1 via ge-1/1/4.0
224.0.0.5/32 *[OSPF/10] 00:11:20, metric 1
MultiRecv

lab@mxA-1#
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.
lab@mxA-1# up

lab@mxA-1# set overload

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 4.3
Enter the run show route table R3-Y.inet.0 command to examine the
routing-instance route table again.
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.0
10.0.1.2/32 *[Local/0] 00:14:46
10.0.2.0/24 *[OSPF/10] 00:00:20, metric 70546

> to 10.0.1.1 via ge-1/1/4.0
20.20.0.0/24 *[OSPF/150] 00:08:35, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
20.20.1.0/24 *[OSPF/150] 00:08:35, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
20.20.2.0/24 *[OSPF/150] 00:08:35, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
20.20.3.0/24 *[OSPF/150] 00:08:35, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
20.20.4.0/24 *[OSPF/150] 00:08:30, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
20.20.5.0/24 *[OSPF/150] 00:08:30, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
20.20.6.0/24 *[OSPF/150] 00:08:30, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
20.20.7.0/24 *[OSPF/150] 00:08:30, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
172.16.1.1/32 *[OSPF/10] 00:00:20, metric 75535
> to 10.0.1.1 via ge-1/1/4.0
172.16.1.2/32 *[Direct/0] 00:45:59
> via lo0.1
172.16.2.1/32 *[OSPF/10] 00:00:20, metric 75546
> to 10.0.1.1 via ge-1/1/4.0
172.16.2.2/32 *[OSPF/10] 00:00:20, metric 70546
> to 10.0.1.1 via ge-1/1/4.0
172.22.121.0/24 *[OSPF/10] 00:00:20, metric 65545
> to 10.0.1.1 via ge-1/1/4.0
172.22.122.0/24 *[OSPF/10] 00:00:20, metric 65546
> to 10.0.1.1 via ge-1/1/4.0
172.31.100.1/32 *[OSPF/10] 00:00:20, metric 65545
> to 10.0.1.1 via ge-1/1/4.0
224.0.0.5/32 *[OSPF/10] 00:12:56, metric 1
MultiRecv

lab@mxA-1#
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.
lab@mxA-1# top edit protocols ospf area Y0
[edit protocols ospf area 0.0.0.10]

lab@mxA-1# run clear ospf statistics

lab@mxA-1# set interface ge-1/0/4.0 authentication md5 10 key juniper

lab@mxA-1# commit
commit complete

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.
lab@mxA-1# run show ospf neighbor
172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 37
10.0.1.2 ge-1/0/4.0 Full 172.16.1.2 128 11

172.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.
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 : 0

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

Total rexmit entries : 0
db summaries : 0
lsreq entries : 0
Receive errors:
2 area mismatches

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.
lab@mxA-1# top edit routing-instances R3-Y protocols ospf area Y0

lab@mxA-1# set interface ge-1/1/4.0 authentication md5 10 key juniper

commit complete
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
172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 34
10.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 2
Configuring 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–1
11.a.11.4R1.14
Note
number.
routing tables.
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
Lab 2–2 • Configuring and Monitoring OSPF Areas and Route Summarization (Detailed) www.juniper.net
mxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

lab@mxA-1>
Step 1.3
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# commit
commit complete
[edit]
lab@mxA-1#
Step 1.4
Verify you have two OSPF adjacencies using the run show ospf neighbor
command.
[edit]
172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 32
10.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.
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]

lab@mxA-1# set area Y0 stub


lab@mxA-1# set area Y0 stub

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.
lab@mxA-1# run show route 20.20/16 table R3-Y.inet.0

lab@mxA-1# run show route 20.20/16 table inet.0

20.20.0.0/24 *[Static/5] 00:05:53

Reject
20.20.1.0/24 *[Static/5] 00:05:53
Reject
20.20.2.0/24 *[Static/5] 00:05:53
Reject
20.20.3.0/24 *[Static/5] 00:05:53
Reject
20.20.4.0/24 *[OSPF/150] 00:05:44, metric 0, tag 0
> to 172.22.121.2 via ge-1/0/0.1111
20.20.5.0/24 *[OSPF/150] 00:05:44, metric 0, tag 0
> to 172.22.121.2 via ge-1/0/0.1111
20.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

lab@mxA-1#
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.

172.16.1.1/32 *[Direct/0] 00:23:37

> via lo0.0
172.16.1.2/32 *[OSPF/10] 00:05:01, metric 5000
> to 10.0.1.2 via ge-1/0/4.0
172.16.2.1/32 *[OSPF/10] 00:07:42, metric 10011
> to 172.22.121.2 via ge-1/0/0.1111
172.16.2.2/32 *[OSPF/10] 00:04:49, metric 5011
> to 172.22.121.2 via ge-1/0/0.1111

172.16.1.1/32 *[OSPF/10] 00:05:01, metric 75535

> to 10.0.1.1 via ge-1/1/4.0
172.16.1.2/32 *[Direct/0] 00:23:37
> via lo0.1
172.16.2.1/32 *[OSPF/10] 00:05:01, metric 75546
> to 10.0.1.1 via ge-1/1/4.0
172.16.2.2/32 *[OSPF/10] 00:04:49, metric 70546
> to 10.0.1.1 via ge-1/1/4.0

lab@mxA-1# run ping 172.16.R.2 count 5
PING 172.16.2.2 (172.16.2.2): 56 data bytes


lab@mxA-1#
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.

Router *172.16.1.1 172.16.1.1 0x80000066 387 0x22 0x1c1 48
Router 172.16.2.1 172.16.2.1 0x80000066 379 0x22 0x1aa3 48
Router 172.31.100.1 172.31.100.1 0x8000004e 761 0x22 0xdc57 60
Network 172.22.121.2 172.31.100.1 0x80000006 929 0x22 0x369f 32
Network 172.22.122.2 172.31.100.1 0x80000005 770 0x22 0x3a9a 32
Summary *10.0.1.0 172.16.1.1 0x80000005 347 0x22 0x557e 28
Summary 10.0.2.0 172.16.2.1 0x80000005 337 0x22 0x438e 28
Summary *172.16.1.2 172.16.1.1 0x80000001 347 0x22 0x46dc 28
Summary 172.16.2.2 172.16.2.1 0x80000001 337 0x22 0x34ec 28

Router *172.16.1.1 172.16.1.1 0x80000003 347 0x20 0x8779 36
Router 172.16.1.2 172.16.1.2 0x80000003 348 0x20 0x6763 48
Network 10.0.1.2 172.16.1.2 0x80000002 348 0x20 0x12dd 32
Summary *10.0.2.0 172.16.1.1 0x80000001 387 0x20 0xdeee 28
Summary *172.16.1.1 172.16.1.1 0x80000001 387 0x20 0x6e1c 28
Summary *172.16.2.1 172.16.1.1 0x80000001 387 0x20 0xd1ac 28
Summary *172.16.2.2 172.16.1.1 0x80000001 335 0x20 0xc751 28
Summary *172.22.121.0 172.16.1.1 0x80000001 387 0x20 0x66d3 28
Summary *172.22.122.0 172.16.1.1 0x80000001 387 0x20 0x65d2 28
Summary *172.31.100.1 172.16.1.1 0x80000001 387 0x20 0xd76d 28
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 36
Extern *20.20.2.0 172.16.1.1 0x80000001 517 0x22 0x5574 36
Extern *20.20.3.0 172.16.1.1 0x80000001 517 0x22 0x4a7e 36
Extern 20.20.4.0 172.16.2.1 0x80000002 68 0x22 0x368f 36
Extern 20.20.5.0 172.16.2.1 0x80000001 510 0x22 0x2d98 36
Extern 20.20.6.0 172.16.2.1 0x80000001 510 0x22 0x22a2 36
Extern 20.20.7.0 172.16.2.1 0x80000001 510 0x22 0x17ac 36

lab@mxA-1#
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.

lab@mxA-1# set area Y0 stub no-summaries

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.
172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 35
10.0.1.2 ge-1/0/4.0 Full 172.16.1.2 128 39


10.0.1.0/24 *[Direct/0] 00:19:21

> via ge-1/0/4.0
10.0.1.1/32 *[Local/0] 00:19:21
10.0.2.0/24 *[OSPF/10] 00:19:12, metric 5011
> to 172.22.121.2 via ge-1/0/0.1111
10.210.15.0/27 *[Direct/0] 00:35:07
> via fxp0.0
10.210.15.1/32 *[Local/0] 00:35:07
Local via fxp0.0
20.20.0.0/24 *[Static/5] 00:19:21
Reject
20.20.1.0/24 *[Static/5] 00:19:21
Reject
20.20.2.0/24 *[Static/5] 00:19:21
Reject
20.20.3.0/24 *[Static/5] 00:19:21
Reject
20.20.4.0/24 *[OSPF/150] 00:19:12, metric 0, tag 0
> to 172.22.121.2 via ge-1/0/0.1111
20.20.5.0/24 *[OSPF/150] 00:19:12, metric 0, tag 0
> to 172.22.121.2 via ge-1/0/0.1111
20.20.6.0/24 *[OSPF/150] 00:19:12, metric 0, tag 0
> to 172.22.121.2 via ge-1/0/0.1111
20.20.7.0/24 *[OSPF/150] 00:19:12, metric 0, tag 0
> to 172.22.121.2 via ge-1/0/0.1111
172.16.1.1/32 *[Direct/0] 00:35:07
> via lo0.0
172.16.1.2/32 *[OSPF/10] 00:00:48, metric 5000
> to 10.0.1.2 via ge-1/0/4.0
172.16.2.1/32 *[OSPF/10] 00:19:12, metric 10011
> to 172.22.121.2 via ge-1/0/0.1111
172.16.2.2/32 *[OSPF/10] 00:01:15, metric 5011
> to 172.22.121.2 via ge-1/0/0.1111
172.22.121.0/24 *[Direct/0] 00:35:07
> via ge-1/0/0.1111
172.22.121.1/32 *[Local/0] 00:35:07
172.22.122.0/24 *[OSPF/10] 00:19:21, metric 11
> to 172.22.121.2 via ge-1/0/0.1111
172.31.100.1/32 *[OSPF/10] 00:19:21, metric 10
> to 172.22.121.2 via ge-1/0/0.1111
224.0.0.5/32 *[OSPF/10] 00:35:07, metric 1
MultiRecv

10.0.1.0/24 *[Direct/0] 00:19:21

> via ge-1/1/4.0
10.0.1.2/32 *[Local/0] 00:19:21
172.16.1.2/32 *[Direct/0] 00:35:07
> via lo0.1
224.0.0.5/32 *[OSPF/10] 00:35:07, metric 1
MultiRecv

lab@mxA-1#
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
Step 2.3
Attempt to ping the loopback address of the remote team’s default router .
lab@mxA-1# run ping 172.16.R.1 count 5
PING 172.16.2.1 (172.16.2.1): 56 data bytes


lab@mxA-1#
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.
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 bytes
ping: sendto: No route to host


lab@mxA-1#
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.

Router *172.16.1.1 172.16.1.1 0x80000067 185 0x22 0xfec2 48
Router 172.16.2.1 172.16.2.1 0x80000067 171 0x22 0x18a4 48
Router 172.31.100.1 172.31.100.1 0x8000004e 1498 0x22 0xdc57 60
Network 172.22.121.2 172.31.100.1 0x80000007 289 0x22 0x34a0 32
Network 172.22.122.2 172.31.100.1 0x80000006 44 0x22 0x389b 32
Summary *10.0.1.0 172.16.1.1 0x80000007 141 0x22 0x5180 28
Summary 10.0.2.0 172.16.2.1 0x80000007 171 0x22 0x3f90 28
Summary *172.16.1.2 172.16.1.1 0x80000001 141 0x22 0x46dc 28
Summary 172.16.2.2 172.16.2.1 0x80000002 170 0x22 0x32ed 28

Router *172.16.1.1 172.16.1.1 0x80000005 141 0x20 0x837b 36
Router 172.16.1.2 172.16.1.2 0x80000005 142 0x20 0x6365 48
Network 10.0.1.2 172.16.1.2 0x80000001 142 0x20 0x14dc 32
Extern *20.20.0.0 172.16.1.1 0x80000002 805 0x22 0x6961 36
Extern *20.20.1.0 172.16.1.1 0x80000002 610 0x22 0x5e6b 36
Extern *20.20.2.0 172.16.1.1 0x80000002 417 0x22 0x5375 36
Extern *20.20.3.0 172.16.1.1 0x80000002 224 0x22 0x487f 36
Extern 20.20.4.0 172.16.2.1 0x80000002 805 0x22 0x368f 36
Extern 20.20.5.0 172.16.2.1 0x80000002 610 0x22 0x2b99 36
Extern 20.20.6.0 172.16.2.1 0x80000002 417 0x22 0x20a3 36
Extern 20.20.7.0 172.16.2.1 0x80000002 224 0x22 0x15ad 36

lab@mxA-1#
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.
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.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.
lab@mxA-1# set area Y0 stub default-metric 10

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.
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 bytes


lab@mxA-1#
Question: Was the ping successful?
Answer: Yes, the ping now should be successful.
STOP
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.
lab@mxA-1# set area Y0 nssa


lab@mxA-1# set area Y0 nssa

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 3.2
Issue run show ospf neighbor and run show route commands and
answer the following questions.
Note
It might take a minute for the R3-Y
adjacency to go back to Full.

172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 33
10.0.1.2 ge-1/0/4.0 Full 172.16.1.2 128 37


10.0.1.0/24 *[Direct/0] 00:31:56

> via ge-1/0/4.0
10.0.1.1/32 *[Local/0] 00:31:56
10.0.2.0/24 *[OSPF/10] 00:31:47, metric 5011
> to 172.22.121.2 via ge-1/0/0.1111
10.210.15.0/27 *[Direct/0] 00:47:42
> via fxp0.0
10.210.15.1/32 *[Local/0] 00:47:42
Local via fxp0.0
20.20.0.0/24 *[Static/5] 00:31:56
Reject
20.20.1.0/24 *[Static/5] 00:31:56
Reject
20.20.2.0/24 *[Static/5] 00:31:56
Reject
20.20.3.0/24 *[Static/5] 00:31:56
Reject
20.20.4.0/24 *[OSPF/150] 00:31:47, metric 0, tag 0
> to 172.22.121.2 via ge-1/0/0.1111
20.20.5.0/24 *[OSPF/150] 00:31:47, metric 0, tag 0
> to 172.22.121.2 via ge-1/0/0.1111
20.20.6.0/24 *[OSPF/150] 00:31:47, metric 0, tag 0
> to 172.22.121.2 via ge-1/0/0.1111
20.20.7.0/24 *[OSPF/150] 00:31:47, metric 0, tag 0
> to 172.22.121.2 via ge-1/0/0.1111
172.16.1.1/32 *[Direct/0] 00:47:42
> via lo0.0
172.16.1.2/32 *[OSPF/10] 00:04:33, metric 5000
> to 10.0.1.2 via ge-1/0/4.0
172.16.2.1/32 *[OSPF/10] 00:31:47, metric 10011
> to 172.22.121.2 via ge-1/0/0.1111
172.16.2.2/32 *[OSPF/10] 00:04:14, metric 5011
> to 172.22.121.2 via ge-1/0/0.1111
172.22.121.0/24 *[Direct/0] 00:47:42
> via ge-1/0/0.1111
172.22.121.1/32 *[Local/0] 00:47:42
172.22.122.0/24 *[OSPF/10] 00:31:56, metric 11
> to 172.22.121.2 via ge-1/0/0.1111
172.31.100.1/32 *[OSPF/10] 00:31:56, metric 10
> to 172.22.121.2 via ge-1/0/0.1111
224.0.0.5/32 *[OSPF/10] 00:47:42, metric 1
MultiRecv

10.0.1.0/24 *[Direct/0] 00:31:56

> via ge-1/1/4.0
10.0.1.2/32 *[Local/0] 00:31:56
10.0.2.0/24 *[OSPF/10] 00:04:33, metric 70546
> to 10.0.1.1 via ge-1/1/4.0
20.20.0.0/24 *[OSPF/150] 00:04:33, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
20.20.1.0/24 *[OSPF/150] 00:04:33, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
20.20.2.0/24 *[OSPF/150] 00:04:33, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
20.20.3.0/24 *[OSPF/150] 00:04:33, metric 0, tag 0
> to 10.0.1.1 via ge-1/1/4.0
172.16.1.1/32 *[OSPF/10] 00:04:33, metric 75535
> to 10.0.1.1 via ge-1/1/4.0
172.16.1.2/32 *[Direct/0] 00:47:42
> via lo0.1
172.16.2.1/32 *[OSPF/10] 00:04:33, metric 75546
> to 10.0.1.1 via ge-1/1/4.0
172.16.2.2/32 *[OSPF/10] 00:04:14, metric 70546
> to 10.0.1.1 via ge-1/1/4.0
172.22.121.0/24 *[OSPF/10] 00:04:33, metric 65545
> to 10.0.1.1 via ge-1/1/4.0
172.22.122.0/24 *[OSPF/10] 00:04:33, metric 65546
> to 10.0.1.1 via ge-1/1/4.0
172.31.100.1/32 *[OSPF/10] 00:04:33, metric 65545
> to 10.0.1.1 via ge-1/1/4.0
224.0.0.5/32 *[OSPF/10] 00:47:42, metric 1
MultiRecv

lab@mxA-1#
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
However, an NSSA does allow external routes to be
injected by an ASBR, which is why you can see the
customer routes.
STOP
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.

Router *172.16.1.1 172.16.1.1 0x80000069 624 0x22 0xfac4 48
Router 172.16.2.1 172.16.2.1 0x80000069 608 0x22 0x14a6 48
Router 172.31.100.1 172.31.100.1 0x8000004f 776 0x22 0xda58 60
Network 172.22.121.2 172.31.100.1 0x80000007 1262 0x22 0x34a0 32
Network 172.22.122.2 172.31.100.1 0x80000006 1017 0x22 0x389b 32
Summary *10.0.1.0 172.16.1.1 0x80000009 584 0x22 0x4d82 28
Summary 10.0.2.0 172.16.2.1 0x80000009 567 0x22 0x3b92 28
Summary *172.16.1.2 172.16.1.1 0x80000001 584 0x22 0x46dc 28
Summary 172.16.2.2 172.16.2.1 0x80000001 567 0x22 0x34ec 28
Router *172.16.1.1 172.16.1.1 0x80000004 584 0x20 0x8b72 36
Router 172.16.1.2 172.16.1.2 0x80000004 585 0x20 0x6564 48
Network 10.0.1.2 172.16.1.2 0x80000002 585 0x20 0x12dd 32
Summary *10.0.2.0 172.16.1.1 0x80000001 624 0x20 0xdeee 28
Summary *172.16.1.1 172.16.1.1 0x80000001 624 0x20 0x6e1c 28
Summary *172.16.2.1 172.16.1.1 0x80000001 624 0x20 0xd1ac 28
Summary *172.16.2.2 172.16.1.1 0x80000001 565 0x20 0xc751 28
Summary *172.22.121.0 172.16.1.1 0x80000001 624 0x20 0x66d3 28
Summary *172.22.122.0 172.16.1.1 0x80000001 624 0x20 0x65d2 28
Summary *172.31.100.1 172.16.1.1 0x80000001 624 0x20 0xd76d 28
NSSA *20.20.0.0 172.16.1.1 0x80000001 624 0x20 0x6d5e 36
NSSA *20.20.1.0 172.16.1.1 0x80000001 624 0x20 0x6268 36
NSSA *20.20.2.0 172.16.1.1 0x80000001 624 0x20 0x5772 36
NSSA *20.20.3.0 172.16.1.1 0x80000001 624 0x20 0x4c7c 36
Extern *20.20.0.0 172.16.1.1 0x80000003 704 0x22 0x6762 36
Extern *20.20.1.0 172.16.1.1 0x80000003 386 0x22 0x5c6c 36
Extern *20.20.2.0 172.16.1.1 0x80000003 233 0x22 0x5176 36
Extern *20.20.3.0 172.16.1.1 0x80000003 80 0x22 0x4680 36
Extern 20.20.4.0 172.16.2.1 0x80000003 707 0x22 0x3490 36
Extern 20.20.5.0 172.16.2.1 0x80000003 389 0x22 0x299a 36
Extern 20.20.6.0 172.16.2.1 0x80000003 236 0x22 0x1ea4 36
Extern 20.20.7.0 172.16.2.1 0x80000003 83 0x22 0x13ae 36

lab@mxA-1# run show ospf database | count
Count: 39 lines

lab@mxA-1#
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.

lab@mxA-1# set area Y0 nssa no-summaries

commit complete
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.
Note
Due to route churn, you might see the
count fluctuate some before settling down.
lab@mxA-1> show ospf database | count

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

Router *172.16.1.1 172.16.1.1 0x80000004 119 0x22 0xc55f 48
Router 172.16.2.1 172.16.2.1 0x80000004 110 0x22 0xde41 48
Router 172.31.100.1 172.31.100.1 0x8000007e 263 0x22 0x7c87 60
Network 172.22.121.2 172.31.100.1 0x80000001 276 0x22 0x409a 32
Network 172.22.122.2 172.31.100.1 0x80000001 263 0x22 0x4296 32
Summary *10.0.1.0 172.16.1.1 0x80000007 69 0x22 0x5180 28
Summary 10.0.2.0 172.16.2.1 0x80000007 59 0x22 0x3f90 28
Summary *172.16.1.2 172.16.1.1 0x80000001 69 0x22 0x46dc 28
Summary 172.16.2.2 172.16.2.1 0x80000001 59 0x22 0x34ec 28

Router *172.16.1.1 172.16.1.1 0x80000003 74 0x20 0x8d71 36
Router 172.16.1.2 172.16.1.2 0x80000003 75 0x20 0x6763 48
Network 10.0.1.2 172.16.1.2 0x80000002 75 0x20 0x12dd 32
NSSA *20.20.0.0 172.16.1.1 0x80000001 119 0x20 0x6d5e 36
NSSA *20.20.1.0 172.16.1.1 0x80000001 119 0x20 0x6268 36
NSSA *20.20.2.0 172.16.1.1 0x80000001 119 0x20 0x5772 36
NSSA *20.20.3.0 172.16.1.1 0x80000001 119 0x20 0x4c7c 36
Extern *20.20.0.0 172.16.1.1 0x80000001 275 0x22 0x6b60 36
Extern *20.20.1.0 172.16.1.1 0x80000001 275 0x22 0x606a 36
Extern *20.20.2.0 172.16.1.1 0x80000001 275 0x22 0x5574 36
Extern *20.20.3.0 172.16.1.1 0x80000001 275 0x22 0x4a7e 36
Extern 20.20.4.0 172.16.2.1 0x80000001 264 0x22 0x388e 36
Extern 20.20.5.0 172.16.2.1 0x80000001 264 0x22 0x2d98 36
Extern 20.20.6.0 172.16.2.1 0x80000001 264 0x22 0x22a2 36
Extern 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.
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 3
Advanced 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–1
11.a.11.4R1.14
Note
number.
routing tables.
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
Lab 3–2 • Advanced OSPF Options and Routing Policy (Detailed) www.juniper.net
mxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

lab@mxA-1>
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
[edit]
lab@mxA-1#
[edit]
load complete
[edit]
lab@mxA-1# commit
commit complete
[edit]
lab@mxA-1#
Step 1.4
Variable references are used throughout this lab to distinguish various parts of the
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
[edit]

lab@mxA-1# set area 0 interface lo0.0


lab@mxA-1# set area 10 nssa default-lsa default-metric 10

lab@mxA-1# set area 10 interface ge-1/0/4.0


lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 1.5
Issue a run show ospf interface command to verify interfaces are running
OSPF.
lab@mxA-1# run show ospf interface
ge-1/0/0.1111 BDR 0.0.0.0 172.16.100.1 172.16.1.1 1
lo0.0 DR 0.0.0.0 172.16.1.1 0.0.0.0 0
ge-1/0/4.0 BDR 0.0.0.10 172.16.1.2 172.16.1.1 1
ge-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.
172.22.121.2 ge-1/0/0.1111 Full 172.16.100.1 128 38
10.0.10.2 ge-1/0/4.0 Full 172.16.1.2 128 39
172.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.
lab@mxA-1# run show route table inet.0 protocol ospf | match /32
20.20.1.1/32 *[OSPF/10] 01:34:55, metric 2
40.40.1.1/32 *[OSPF/10] 01:34:55, metric 2
172.16.1.2/32 *[OSPF/10] 01:34:55, metric 1
172.16.2.1/32 *[OSPF/10] 00:03:09, metric 2
172.16.2.2/32 *[OSPF/10] 01:34:55, metric 3
172.31.100.1/32 *[OSPF/10] 00:03:13, metric 1
172.31.101.1/32 *[OSPF/10] 00:03:13, metric 1
172.31.102.1/32 *[OSPF/10] 00:03:18, metric 2
224.0.0.5/32 *[OSPF/10] 01:35:10, metric 1

lab@mxA-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.
lab@mxA-1# set area 0 virtual-link transit-area 20 neighbor-id 172.16.R.1

lab@mxA-1# set area 20 interface ge-1/0/0.11ZV metric 10

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.
ge-1/0/0.1111 BDR 0.0.0.0 172.31.100.1 172.16.1.1 1
lo0.0 DR 0.0.0.0 172.16.1.1 0.0.0.0 0
vl-172.16.2.1 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-1/0/4.0 BDR 0.0.0.10 172.16.1.2 172.16.1.1 1
ge-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.
172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 39
172.22.124.1 vl-172.16.2.1 Full 172.16.2.1 0 32
10.0.10.2 ge-1/0/4.0 Full 172.16.1.2 128 34
172.22.123.2 ge-1/0/0.1113 Full 172.31.101.1 128 31

lab@mxA-1#
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.
lab@mxA-1# run show route table inet.0 172.16.R.1/32

172.16.2.1/32 *[OSPF/10] 00:17:33, metric 2

> to 172.22.121.2 via ge-1/0/0.1111

lab@mxA-1#
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.
lab@mxA-1# set area 10 interface ge-1/0/0.11ZV secondary metric 10

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 2.2
Use the run show ospf interface command to verify the multiarea interface
is in OSPF Area 10.
ge-1/0/0.1111 BDR 0.0.0.0 172.31.100.1 172.16.1.1 1
lo0.0 DR 0.0.0.0 172.16.1.1 0.0.0.0 0
vl-172.16.2.1 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-1/0/0.1111 PtToPt 0.0.0.10 0.0.0.0 0.0.0.0 1
ge-1/0/4.0 DR 0.0.0.10 172.16.1.1 172.16.1.2 1
ge-1/0/0.1113 BDR 0.0.0.20 172.31.101.1 172.16.1.1 1

lab@mxA-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.
172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 39
Area 0.0.0.0
172.22.124.1 vl-172.16.2.1 Full 172.16.2.1 0 35
Area 0.0.0.0
172.22.121.2 ge-1/0/0.1111 Full 172.31.100.1 128 32
Area 0.0.0.10
10.0.10.2 ge-1/0/4.0 Full 172.16.1.2 128 36
Area 0.0.0.10
172.22.123.2 ge-1/0/0.1113 Full 172.31.101.1 128 38
Area 0.0.0.20

lab@mxA-1#
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.
lab@mxA-1# run show route table inet.0 172.16.R.2/32

172.16.2.2/32 *[OSPF/10] 02:15:09, metric 3
> to 10.0.10.2 via ge-1/0/4.0
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.
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

172.16.2.2/32 *[OSPF/10] 00:01:17, metric 12

> to 172.22.121.2 via ge-1/0/0.1111
[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# commit
commit 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.
Note
It might take a minute for the ge-1/0/4
interface to return to a Full state.
[edit]
lab@mxA-1# run show route table inet.0 172.16.2.2/32

172.16.2.2/32 *[OSPF/10] 00:01:46, metric 3

> to 10.0.10.2 via ge-1/0/4.0
[edit]
lab@mxA-1# run traceroute 172.16.2.2
1 10.0.10.2 (10.0.10.2) 0.379 ms 0.271 ms 0.254 ms
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

lab@mxA-1# set protocols rip group P3 neighbor ge-1/0/0.11ZV

lab@mxA-1# commit
commit complete

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.
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.1115
20.20.0.0/24 *[RIP/100] 00:05:30, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.1.0/24 *[RIP/100] 00:05:30, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.2.0/24 *[RIP/100] 00:05:30, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.3.0/24 *[RIP/100] 00:05:30, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.4.0/25 *[RIP/100] 00:05:30, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.4.128/25 *[RIP/100] 00:05:30, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.5.0/26 *[RIP/100] 00:05:30, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.5.64/26 *[RIP/100] 00:05:30, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.5.128/26 *[RIP/100] 00:05:30, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.5.192/26 *[RIP/100] 00:05:30, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115

lab@mxA-1#
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.
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

lab@mxA-1# set term 1 from route-filter 0/0 exact

lab@mxA-1# set term 1 then accept

lab@mxA-1# show
term 1 {
from {
protocol ospf;
route-filter 0.0.0.0/0 exact;
}
then accept;
}

lab@mxA-1#
Note
The next two steps will need to be
coordinated with your remote team
partners.
Step 3.4
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-1] hierarchy.

Apply the export-default policy as an export policy in protocol RIP group P3.
lab@mxA-1# top edit routing-instances R3-1

lab@mxA-1# set protocols rip group P3 export export-default

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 3.5
Note
This step is to be performed by Team 2 only
after waiting two minutes from the commit
time of the previous step.
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.

lab@mxA-2# set protocols rip group P3 export export-default

lab@mxA-2# commit
commit complete

lab@mxA-2#
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.
Note
The output from both routers is shown in
the following capture.

lab@mxA-1# run show route advertising-protocol rip 172.22.125.1 table
R3-1.inet.0

0.0.0.0/0 *[OSPF/150] 00:43:08, metric 11, tag 0

> to 10.0.10.1 via ge-1/1/4.0

lab@mxA-1#
...........................................................................

R3-2.inet.0

lab@mxA-2#
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.
Note

lab@mxA-1# run show route 0/0 exact table R3-1.inet.0

0.0.0.0/0 *[OSPF/150] 05:47:17, metric 11, tag 0

> to 10.0.10.1 via ge-1/1/4.0

lab@mxA-1#
...........................................................................

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

lab@mxA-2#
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.
lab@mxA-1# set protocols ospf external-preference 90

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 3.9
table R3-Y.inet.0 command to verify that both routers are advertising the
default route to the RIP router.
Note

R3-1.inet.0

0.0.0.0/0 *[OSPF/90] 00:01:34, metric 11, tag 0

> to 10.0.10.1 via ge-1/1/4.0

lab@mxA-1#
...........................................................................
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

lab@mxA-2#
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.
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
import-rip-route] hierarchy. Create a policy to accept only the 20.20/21
summary route from the RIP router.
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

lab@mxA-1# set term 1 from route-filter 20.20/21 exact



lab@mxA-1# set term 2 from route-filter 20.20/21 longer

lab@mxA-1# set term 2 then reject

lab@mxA-1# show
term 1 {
from {
protocol rip;
}
then accept;
}
term 2 {
from {
protocol rip;
route-filter 20.20.0.0/21 longer;
}
then reject;
}
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.

lab@mxA-1# set protocols rip group P3 import import-rip-route

lab@mxA-1# commit
commit complete

lab@mxA-1#
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

lab@mxA-1#
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
export-rip-route] hierarchy. Create a routing policy to redistribute the RIP
summary route into OSPF.
lab@mxA-1# top edit policy-options policy-statement export-rip-route
[edit policy-options policy-statement export-rip-route]



lab@mxA-1# show
term 1 {
from protocol rip;
then accept;
}
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.

lab@mxA-1# set protocols ospf prefix-export-limit 1

lab@mxA-1# set protocols ospf export export-rip-route

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 3.15
Note
This step is to be performed by Team 2 only
after waiting two minutes from the commit
time of the previous step.
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.

lab@mxA-2# set protocols ospf prefix-export-limit 1

lab@mxA-2# set protocols ospf export export-rip-route

lab@mxA-2# commit
commit complete

lab@mxA-1#
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

lab@mxA-1# run traceroute 20.20.1.1 routing-instance R3-1
1 20.20.1.1 (20.20.1.1) 0.508 ms 0.361 ms 0.315 ms

lab@mxA-1#
...........................................................................

lab@mxA-2# run traceroute 20.20.1.1 routing-instance R3-2
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

lab@mxA-2#
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.
lab@mxA-1# run show ospf database area 10 nssa detail

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

lab@mxA-1# run show ospf database external detail
Extern 20.20.0.0 172.31.100.1 0x80000001 2105 0x22 0x811d 36
mask 255.255.248.0

lab@mxA-1#
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
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.
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

lab@mxA-1# show
term 1 {
from {
route-filter 20.20.0.0/21 orlonger;
}
then reject;
}
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.

lab@mxA-1# set protocols ospf import ospf-import

commit complete
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.
Note
lab@mxA-1> traceroute 20.20.1.1 routing-instance R3-1

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

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 4
IS-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
number.
routing tables.
www.juniper.net IS-IS Configuration and Monitoring (Detailed) • Lab 4–1

11.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: lab
Password:
--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

lab@mxA-1>
Step 1.3
[edit]
load complete
[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;
}

unit 1113 {
vlan-id 1113;
family inet {
address 172.22.123.1/24;
}
##
##
family iso;
}
unit 1115 {
vlan-id 1115;
family inet {
address 172.22.125.1/24;
}
##
##
family iso;
}
}
ge-1/0/4 {
description "connection to R3-1";
unit 0 {
family inet {
address 10.0.10.1/24;
}
##
##
family iso;
}
}
ge-1/1/4 {
description "connection to mxA-1";
unit 0 {
family inet {
address 10.0.10.2/24;
}
##
##
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;
}
}
}
[edit interfaces]
lab@mxA-1#
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 Remote
lc-0/0/0 up up
lc-0/0/0.32769 up up vpls
xe-0/0/0 up down
xe-0/0/1 up down
xe-0/0/2 up down
xe-0/0/3 up down
ge-1/0/0 up up
ge-1/0/0.1111 up up inet 172.22.121.1/24
iso
multiservice
ge-1/0/0.1113 up up inet 172.22.123.1/24
iso
multiservice
ge-1/0/0.1115 up up inet 172.22.125.1/24
iso
multiservice
ge-1/0/0.32767 up up multiservice
ge-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 down
ge-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
multiservice
ge-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 down
fxp0 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/0
lo0.1 up up inet 172.16.1.2 --> 0/0
lo0.16384 up up inet 127.0.0.1 --> 0/0
lo0.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
[edit interfaces]
lab@mxA-1#
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
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

lab@mxA-1# set unit 1 family iso address 49.000Y.1720.1600.Y002.00

lab@mxA-1# commit
commit complete

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.
lab@mxA-1# run show interfaces lo0 terse
Interface Admin Link Proto Local Remote
lo0 up up
lo0.0 up up inet 172.16.1.1 --> 0/0
iso 49.0001.1720.1600.1001
lo0.1 up up inet 172.16.1.2 --> 0/0
iso 49.0001.1720.1600.1002
lo0.16384 up up inet 127.0.0.1 --> 0/0
lo0.16385 up up inet

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).
lab@mxA-1# top edit protocols isis
[edit protocols isis]

lab@mxA-1# set interface lo0.0

lab@mxA-1# set interface ge-1/0/0.11ZV

lab@mxA-1# set interface ge-1/0/4.0

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

lab@mxA-1# set interface ge-1/1/4.0

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 3.3
Use the run show isis interface command to verify IS-IS is active on the
interfaces.

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

lab@mxA-1#
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.
lab@mxA-1# run show isis adjacency
Interface System L State Hold (secs) SNPA
ge-1/0/0.1111 vr-device 2 Up 7 80:71:1f:c3:f7:60
ge-1/0/4.0 1720.1600.1002 1 Up 7 80:71:1f:c3:3:7c
ge-1/0/4.0 1720.1600.1002 2 Up 6 80:71:1f:c3:3:7c

lab@mxA-1#
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).
lab@mxA-1# top edit protocols isis

lab@mxA-1# set interface ge-1/0/0.11ZV level 1 disable

lab@mxA-1# set interface ge-1/0/4.0 level 1 disable

lab@mxA-1#
Step 3.6
hierarchy and disable IS-IS Level 1 on the interface between the two routing
instances (ge-1/1/4). Commit the configuration when completed.

lab@mxA-1# set interface ge-1/1/4.0 level 1 disable

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.
ge-1/0/0.1111 2 0x1 Disabled vr-device.02 10/10
ge-1/0/4.0 2 0x1 Disabled 1720.1600.1002.02 10/10

ge-1/0/4.0 1720.1600.1002 2 Up 8 80:71:1f:c3:3:7c


lab@mxA-1#
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).

172.16.1.1/32 *[Direct/0] 1d 10:29:21

> via lo0.0
172.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.0
172.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.1111
172.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

lab@mxA-1#

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

lab@mxA-1# set preference 20

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

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.

172.16.1.1/32 *[Direct/0] 1d 10:31:03

> via lo0.0
172.16.1.2/32 *[IS-IS/18] 00:02:21, metric 10

> 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.0
172.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.1111
172.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

lab@mxA-1#
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.
lab@mxA-1# top
[edit]
lab@mxA-1# delete protocols ospf
[edit]
lab@mxA-1# delete routing-instances R3-Y protocols ospf
[edit]
commit complete
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.0
172.16.1.2/32 *[IS-IS/18] 00:03:43, metric 10
> to 10.0.10.2 via ge-1/0/4.0
172.16.2.1/32 *[IS-IS/18] 00:11:04, metric 20
> to 172.22.121.2 via ge-1/0/0.1111
172.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 Attributes
mxA-1.00-00 0x5 0x87f7 1127 L1 L2 Attached
1 LSPs

mxA-1.00-00 0x8 0x34aa 1127 L1 L2
1720.1600.1002.00-00 0x7 0x4f52 1125 L1 L2
1720.1600.1002.02-00 0x4 0xefe3 1125 L1 L2
1720.1600.2001.00-00 0x7 0x2a6e 1136 L1 L2
mxA-2.00-00 0x5 0xe97d 1134 L1 L2
mxA-2.02-00 0x4 0x86fc 1135 L1 L2
vr-device.00-00 0x7d 0x63a4 1175 L1 L2
vr-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 extensive
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
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 prefix: 172.22.121.0/24, Internal, Metric: default 10, Up
IP extended prefix: 172.22.121.0/24 metric 10 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: 15
IPv4/IPv6 Routes
----------------
Prefix L Version Metric Type Interface NH Via
10.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
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 5
Advanced 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–1
11.a.11.4R1.14
Note
number.
routing tables.
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
Lab 5–2 • Advanced IS-IS Configuration and Routing Policy (Detailed) www.juniper.net
mxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

lab@mxA-1>
Step 1.3
[edit]
load complete
[edit]
lab@mxA-1# commit
commit complete
[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]
ge-1/0/4.0 2 0x1 Disabled 1720.1600.1002.02 10/10
ge-1/0/5.0 2 0x1 Disabled 1720.1600.1003.02 10/10
[edit]
ge-1/0/4.0 1720.1600.1002 2 Up 8 80:71:1f:c3:3:7c
ge-1/0/5.0 1720.1600.1003 2 Up 8 80:71:1f:c3:3:7d
[edit]
lab@mxA-1#
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
ge-1/1/6.0 2 0x2 Disabled 1720.1600.1004.02 10/10
ge-1/1/7.0 2 0x3 Disabled 1720.1600.1004.03 10/10
[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
ge-1/1/6.0 1720.1600.1002 2 Up 21 80:71:1f:c3:3:66
ge-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
mxA-1.00-00 0x6 0x85f8 1163 L1 L2 Attached
1 LSPs

mxA-1.00-00 0x73 0xc70 438 L1 L2
1720.1600.1002.00-00 0x71 0x8353 1001 L1 L2
1720.1600.1002.02-00 0x4 0xefe3 1130 L1 L2
1720.1600.1003.00-00 0x5 0x96a1 437 L1 L2
1720.1600.1003.02-00 0x3 0x1ab7 437 L1 L2
1720.1600.1004.00-00 0x6 0x4be4 1128 L1 L2
1720.1600.1004.02-00 0x4 0x8645 954 L1 L2
1720.1600.1004.03-00 0x4 0xc503 1159 L1 L2
1720.1600.2001.00-00 0x6 0x3348 455 L1 L2
mxA-2.00-00 0x6 0x835b 1001 L1 L2
mxA-2.02-00 0x3 0x88fb 380 L1 L2
1720.1600.2003.00-00 0x5 0x953f 454 L1 L2
1720.1600.2003.02-00 0x3 0xb0d0 454 L1 L2
1720.1600.2004.00-00 0x5 0x9b32 378 L1 L2
1720.1600.2004.02-00 0x4 0x1d5e 996 L1 L2
1720.1600.2004.03-00 0x3 0x5e1b 386 L1 L2
vr-device.00-00 0x36d 0x8e86 1172 L1 L2
vr-device.02-00 0x4 0x2441 1130 L1 L2
vr-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

lab@mxA-1# set interface ge-1/0/4.0 level 2 hello-authentication-type md5

lab@mxA-1# set interface ge-1/0/4.0 level 2 hello-authentication-key juniper
lab@mxA-1#
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.


lab@mxA-1#
Step 2.2
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.



lab@mxA-1#
Step 2.3
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.
lab@mxA-1# up 3 edit R4-Y protocols isis



commit complete
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-resolve
Address 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
^C
1 packets received by filter
0 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
ge-1/0/4.0 1720.1600.1002 2 Up 7 80:71:1f:c3:3:7c
ge-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 interface
ge-1/0/4.0 2 0x1 Disabled 1720.1600.1002.02 10/10
ge-1/0/5.0 2 0x1 Disabled 1720.1600.1003.02 10/10
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

lab@mxA-1# set reference-bandwidth 1g

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 3.4
Use the run show isis interface command to verify that the change in
metric of the IS-IS Level 2 interfaces.
ge-1/0/4.0 2 0x1 Disabled 1720.1600.1002.02 1/1
ge-1/0/5.0 2 0x1 Disabled 1720.1600.1003.02 1/1

lab@mxA-1#
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
lab@mxA-1# run show route 172.16.Y.4/32 table inet.0

172.16.1.4/32 *[IS-IS/18] 00:01:39, metric 11

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 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.
lab@mxA-1# set interface ge-1/0/5.0 level 2 metric 1000

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 3.7
Use the run show isis interface command to examine the metrics now
assigned to the IS-IS interfaces.
ge-1/0/4.0 2 0x1 Disabled 1720.1600.1002.02 1/1
ge-1/0/5.0 2 0x1 Disabled 1720.1600.1003.02 1/1000

lab@mxA-1#
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

lab@mxA-1#
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.
lab@mxA-2# top set routing-instances R3-Y protocols isis overload

lab@mxA-2# commit
commit complete

lab@mxA-2#
Step 3.10
Use the run show isis database level 2 command to ensure that the
overload bit has been enabled in the LSP.
lab@mxA-1# run show isis database level 2
mxA-1.00-00 0x26 0xee4b 1173 L1 L2
1720.1600.1002.00-00 0x22 0x130f 1171 L1 L2 Overload
1720.1600.1002.02-00 0x1c 0xbffb 1171 L1 L2
1720.1600.1003.00-00 0x15 0x5bcc 1171 L1 L2
1720.1600.1003.02-00 0xe 0x4c2 1171 L1 L2
1720.1600.1004.00-00 0x14 0xa57c 1169 L1 L2
1720.1600.1004.02-00 0xf 0x7050 1169 L1 L2
1720.1600.1004.03-00 0xe 0xb10d 1169 L1 L2
1720.1600.2001.00-00 0x1e 0x9e35 1182 L1 L2
1720.1600.2002.00-00 0x1c 0x4282 1180 L1 L2 Overload
1720.1600.2002.02-00 0x1a 0x5a13 1180 L1 L2
1720.1600.2003.00-00 0xf 0x8a40 1181 L1 L2
1720.1600.2003.02-00 0xb 0xa0d8 1181 L1 L2
mxA-2.00-00 0x10 0xd0f1 1179 L1 L2
mxA-2.02-00 0xb 0xf65 1179 L1 L2
mxA-2.03-00 0xb 0x4e23 1179 L1 L2
vr-device.00-00 0x157 0xaa82 969 L1 L2
vr-device.02-00 0x16 0xff53 1016 L1 L2
vr-device.03-00 0x17 0xb2be 969 L1 L2
19 LSPs

lab@mxA-1#
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.

172.16.1.4/32 *[IS-IS/18] 00:00:04, metric 73

> to 10.0.11.2 via ge-1/0/5.0

lab@mxA-1#
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.
lab@mxA-1# run show isis database level 2 mxX-Y.00 extensive | find tlv
TLVs:
Speaks: IP
Speaks: IPV6
Hostname: mxA-1
IS neighbor: vr-device.03, Internal, Metric: default 1
IP address: 172.22.121.1

lab@mxA-1#
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.
lab@mxA-1# set level 2 wide-metrics-only

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.
lab@mxA-1# run show isis database level 2 mxX-Y.00 extensive | find tlv
TLVs:
Speaks: IP
Speaks: IPV6
Hostname: mxA-1
IP address: 172.22.121.1

lab@mxA-1#
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
display the route to the R5 routing instance loopback address.

172.16.1.4/32 *[IS-IS/18] 00:02:02, metric 1010

> to 10.0.11.2 via ge-1/0/5.0

lab@mxA-1#
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.

lab@mxA-1# set interface ge-1/0/0.11ZV

lab@mxA-1#
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.
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

lab@mxA-1# commit
commit complete

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

lab@mxA-1# run show rip neighbor instance R5-Y
Source Destination Send Receive In
Neighbor State Address Address Mode Mode Met
-------- ----- ------- ----------- ---- ------- ---
ge-1/0/0.1115 Up 172.22.125.1 224.0.0.9 mcast both 1


20.20.0.0/21 *[RIP/100] 00:02:38, metric 2, tag 0

> to 172.22.125.2 via ge-1/0/0.1115
20.20.0.0/24 *[RIP/100] 00:02:38, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.1.0/24 *[RIP/100] 00:02:38, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.2.0/24 *[RIP/100] 00:02:38, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.3.0/24 *[RIP/100] 00:02:38, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.4.0/25 *[RIP/100] 00:02:38, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.4.128/25 *[RIP/100] 00:02:38, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.5.0/26 *[RIP/100] 00:02:38, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.5.64/26 *[RIP/100] 00:02:38, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.5.128/26 *[RIP/100] 00:02:38, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.5.192/26 *[RIP/100] 00:02:38, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115

lab@mxA-1#
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
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.
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 route-filter 0/0 prefix-length-range /24-/24



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;
}

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.
lab@mxA-1# set protocols rip group P3 import import-rip-routes

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.1115
20.20.1.0/24 *[RIP/100] 00:05:55, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.2.0/24 *[RIP/100] 00:05:55, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.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)

lab@mxA-1#
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
export-rip-default] hierarchy. Configure the policy to advertise a default
route.
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


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

lab@mxA-1# set export export-rip-default

lab@mxA-1# commit
commit complete

lab@mxA-1>#
Step 4.9
table R5-Y.inet.0 command to display the routes that are being advertised to
the RIP network.
lab@mxA-1# run show route advertising-protocol rip 172.22.12V.1 table
R5-Y.inet.0

lab@mxA-1#
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.
lab@mxA-1# run show route 0/0 exact table R5-Y.inet.0

lab@mxA-1# run show isis database instance R5-Y
1720.1600.1004.00-00 0xe 0xcf2e 645 L1 L2 Attached
1 LSPs

mxA-1.00-00 0x2e 0xf22c 641 L1 L2
1720.1600.1002.00-00 0x2a 0x317 643 L1 L2 Overload
1720.1600.1002.02-00 0x24 0xaf04 643 L1 L2
1720.1600.1003.00-00 0x1d 0x4bd4 643 L1 L2
1720.1600.1003.02-00 0x16 0xf3ca 643 L1 L2
1720.1600.1004.00-00 0x1c 0x9584 645 L1 L2
1720.1600.1004.02-00 0x17 0x6058 645 L1 L2
1720.1600.1004.03-00 0x16 0xa115 645 L1 L2
1720.1600.2001.00-00 0x26 0x8b56 654 L1 L2
1720.1600.2002.00-00 0x24 0x328a 652 L1 L2 Overload
1720.1600.2002.02-00 0x22 0x4a1b 652 L1 L2
1720.1600.2003.00-00 0x17 0x7a48 652 L1 L2
1720.1600.2003.02-00 0x13 0x90e0 652 L1 L2
mxA-2.00-00 0x18 0xc0f9 650 L1 L2
mxA-2.02-00 0x13 0xfe6d 650 L1 L2
mxA-2.03-00 0x13 0x3e2b 651 L1 L2
vr-device.00-00 0x15e 0x9c89 1034 L1 L2
vr-device.02-00 0x1d 0xf15a 1034 L1 L2
vr-device.03-00 0x1e 0xa4c5 917 L1 L2
19 LSPs

lab@mxA-1#
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.
lab@mxA-1# up 3 set routing-options aggregate route 0/0

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 4.12
table R5-Y.inet.0 command to verify that the default route is now being
advertised to the RIP network.
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

lab@mxA-1#
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
export-rip-to-isis] hierarchy. Configure the export-rip-to-isis policy
to advertise the RIP routes as IS-IS external Type 1 routes.
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 then external type 1

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.

lab@mxA-1# set protocols isis export export-rip-to-isis

commit complete
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.0
20.20.1.0/24 *[IS-IS/165] 00:01:43, metric 1012
> to 10.0.11.2 via ge-1/0/5.0
20.20.2.0/24 *[IS-IS/165] 00:01:43, metric 1012
> to 10.0.11.2 via ge-1/0/5.0
20.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 6
Configuring 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–1

11.a.11.4R1.14
Note
number.
routing tables.
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
Lab 6–2 • Configuring a Multilevel IS-IS Network (Detailed) www.juniper.net

mxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

lab@mxA-1>
Step 1.3
[edit]
load complete
[edit]
commit complete
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 interface
ge-1/0/4.0 2 0x1 Disabled 1720.1600.1002.02 10/10
ge-1/0/5.0 2 0x1 Disabled 1720.1600.1003.02 10/10
lab@mxA-1> show isis adjacency

ge-1/0/4.0 1720.1600.1002 2 Up 6 80:71:1f:c3:3:7c
ge-1/0/5.0 1720.1600.1003 2 Up 7 80:71:1f:c3:3:7d
lab@mxA-1>

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-Y
ge-1/0/6.0 1 0x1 1720.1600.1004.03 Disabled 10/10
ge-1/1/4.0 2 0x2 Disabled 1720.1600.1002.02 10/10
lab@mxA-1> show isis adjacency instance R3-Y

ge-1/0/6.0 1720.1600.1004 1 Up 7 80:71:1f:c3:3:7e
ge-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
ge-1/0/7.0 1 0x1 1720.1600.1004.02 Disabled 10/10
ge-1/1/5.0 2 0x2 Disabled 1720.1600.1003.02 10/10

ge-1/0/7.0 1720.1600.1004 1 Up 7 80:71:1f:c3:3:7f
ge-1/1/5.0 mxA-1 2 Up 26 80:71:1f:c3:3:65
lab@mxA-1>

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

ge-1/1/6.0 1 0x3 1720.1600.1004.03 Disabled 10/10
ge-1/1/7.0 1 0x2 1720.1600.1004.02 Disabled 10/10

ge-1/1/6.0 1720.1600.1002 1 Up 23 80:71:1f:c3:3:66
ge-1/1/7.0 1720.1600.1003 1 Up 20 80:71:1f:c3:3:67
lab@mxA-1>

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.0
172.16.1.2/32 *[IS-IS/18] 00:28:52, metric 10
> to 10.0.10.2 via ge-1/0/4.0
172.16.1.3/32 *[IS-IS/18] 00:28:52, metric 10
> to 10.0.11.2 via ge-1/0/5.0
172.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.1111
172.16.2.2/32 *[IS-IS/18] 00:28:41, metric 30
> to 172.22.121.2 via ge-1/0/0.1111
172.16.2.3/32 *[IS-IS/18] 00:28:41, metric 30
> to 172.22.121.2 via ge-1/0/0.1111
172.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.0
172.16.1.3/32 *[IS-IS/15] 00:29:29, metric 10
> to 10.0.13.1 via ge-1/1/7.0
172.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-Y
1720.1600.1002.00-00 0x18 0x9be2 1030 L1 L2 Attached

1720.1600.1003.00-00 0x12 0x7c05 1030 L1 L2 Attached
1720.1600.1004.00-00 0x13 0x8a7a 1032 L1 L2
1720.1600.1004.02-00 0x4 0xccfc 1032 L1 L2
1720.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.1115
20.20.1.0/24 *[RIP/100] 01:02:13, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.2.0/24 *[RIP/100] 01:02:13, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
20.20.3.0/24 *[RIP/100] 01:02:13, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1115
224.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:
Speaks: IP
Speaks: IPV6
Hostname: mxA-1
IP external prefix: 20.20.0.0/24, Internal, Metric: default 2, Up
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.0
10.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

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.
lab@mxA-1# up 2 edit R4-Y routing-options

lab@mxA-1# set aggregate route 10.0.1W.0/23

lab@mxA-1#
Step 3.4
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.
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

lab@mxA-1# set term 1 from route-filter 10.0.1W.0/23 exact

lab@mxA-1# set term 1 to level 2


lab@mxA-1# set term 2 from route-filter 10.0.1W.0/23 longer



lab@mxA-1# show
term 1 {
from {
protocol aggregate;

}
to level 2;
then accept;
}
term 2 {
from {
}
to level 2;
then reject;
}

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.

lab@mxA-1# set export summarize-level-1

lab@mxA-1#
Step 3.6
hierarchy and apply the policy named summarize-level-1 as an export policy.
Commit the changes when completed.

lab@mxA-1# set export summarize-level-1

lab@mxA-1# commit
commit complete

lab@mxA-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.
lab@mxA-1# run show route 10.0.1W.0/23 table inet.0

10.0.12.0/23 *[IS-IS/165] 00:04:18, 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: 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
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.
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



lab@mxA-1# show
term 1 {
from {
}
to level 2;
then accept;
}

lab@mxA-1#

Step 3.9
hierarchy and apply the rip-to-level-2 policy as an export policy.

lab@mxA-1# set export rip-to-level-2

lab@mxA-1#
Step 3.10
hierarchy and apply the rip-to-level-2 policy as an export policy. Commit the

lab@mxA-1# set export rip-to-level-2

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.

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

lab@mxA-1#
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
level2-to-level1] hierarchy. Configure the level2-to-level1 policy to
accept all IS-IS Level 2 routes into Level 1.
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

lab@mxA-1# set term 1 from level 2



lab@mxA-1# show
term 1 {
from {
protocol isis;
level 2;
}
to level 1;
then accept;
}

lab@mxA-1#
Step 3.13
hierarchy and apply the level2-to-level1 policy as an export policy.

lab@mxA-1# set export level2-to-level1

lab@mxA-1#
Step 3.14
hierarchy and apply the level2-to-level1 policy as an export policy. Commit
the configuration and return to operational mode.

lab@mxA-1# set export level2-to-level1

commit complete
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.0
172.16.1.2/32 *[IS-IS/15] 01:49:57, metric 10
> to 10.0.12.1 via ge-1/1/6.0
172.16.1.3/32 *[IS-IS/15] 01:49:57, metric 10
> to 10.0.13.1 via ge-1/1/7.0
172.16.1.4/32 *[Direct/0] 02:55:36
> via lo0.3
172.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.0
172.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.0
172.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

172.16.2.4/32 *[IS-IS/18] 00:00:57, metric 60
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-Y
1720.1600.1002.00-00 0x1f 0x2032 1038 L1 L2 Attached
1720.1600.1003.00-00 0x19 0xec6a 1038 L1 L2 Attached
1720.1600.1004.00-00 0x1a 0x619c 1040 L1 L2
1720.1600.1004.02-00 0xb 0xbe04 1040 L1 L2
1720.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:
Speaks: IP
Speaks: IPV6
Hostname: mxA-1
IP prefix: 10.0.11.0/24, Internal, Metric: default 20, Down
IP extended prefix: 10.0.11.0/24 metric 20 down
IP external prefix: 10.0.16.0/23, Internal, Metric: default 50, Down
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 7
BGP (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–1

11.a.11.4R1.14
Note
number.
routing tables.
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
Lab 7–2 • BGP (Detailed) www.juniper.net

mxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

lab@mxA-1>
Step 1.3
[edit]
load complete
[edit]
commit 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 interface
ge-1/0/4.0 BDR 0.0.0.0 172.16.1.2 172.16.1.1 1
lo0.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.

10.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 10
PING 172.22.121.2 (172.22.121.2): 56 data bytes
!!!!!!!!!!
--- 172.22.121.2 ping statistics ---
lab@mxA-1> ping 172.22.12V.2 rapid count 10

PING 172.22.123.2 (172.22.123.2): 56 data bytes
!!!!!!!!!!
--- 172.22.123.2 ping statistics ---
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 ---
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.0
10.0.10.1/32 *[Local/0] 1d 04:47:18
10.210.15.0/27 *[Direct/0] 1d 04:47:18
> via fxp0.0
10.210.15.1/32 *[Local/0] 1d 04:47:18
Local via fxp0.0
172.16.1.0/26 *[Static/5] 00:16:03
Reject
172.16.1.1/32 *[Direct/0] 1d 04:47:18
> via lo0.0
172.16.1.2/32 *[OSPF/10] 1d 00:12:28, metric 1
> to 10.0.10.2 via ge-1/0/4.0
172.16.1.64/26 *[Static/5] 00:16:03
Reject
172.22.121.0/24 *[Direct/0] 1d 04:47:18
> via ge-1/0/0.1111
172.22.121.1/32 *[Local/0] 1d 04:47:18
172.22.123.0/24 *[Direct/0] 1d 04:47:18
> via ge-1/0/0.1113
172.22.123.1/32 *[Local/0] 1d 04:47:18
224.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
lab@mxA-1#
Step 2.2
hierarchy and configure the same AS number for the R3-Y routing instance.
lab@mxA-1# top edit routing-instances R3-Y routing-options


lab@mxA-1#
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.
lab@mxA-1# top edit protocols bgp
[edit protocols bgp]

lab@mxA-1# set group ibgp type internal

lab@mxA-1# set group ibgp local-address 172.16.Y.1

lab@mxA-1# set group ibgp neighbor 172.16.Y.2

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

lab@mxA-1# set group ibgp local-address 172.16.Y.2

lab@mxA-1# set group ibgp neighbor 172.16.Y.1

lab@mxA-1# commit
commit complete

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: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 0 0 0 0 0 0
Peer 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/0
172.16.1.2 65001 2 3 0 0 9 0/
0/0/0 0/0/0/0

lab@mxA-1#
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.
lab@mxA-1# run show route protocol static

172.16.1.0/26 *[Static/5] 00:17:48

Reject
172.16.1.64/26 *[Static/5] 00:17:48
Reject

172.16.1.128/26 *[Static/5] 00:17:48

Reject
172.16.1.192/26 *[Static/5] 00:17:48
Reject
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

lab@mxA-1#
Step 2.7
redistribute-statics] hierarchy and create a policy that accepts all static
routes.
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


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.

lab@mxA-1# set group ibgp export redistribute-statics
Step 2.9
hierarchy and apply the redistribute-statics policy as an export policy in the
protocols bgp group ibgp hierarchy. Commit the configuration when completed.

lab@mxA-1# set group ibgp export redistribute-statics

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.
inet.0 2 2 0 0 0 0
172.16.1.1 65001 9 9 0 0 2:19 Establ
R3-1.inet.0: 2/2/2/0
172.16.1.2 65001 8 9 0 0 2:19 2/
2/2/0 0/0/0/0

lab@mxA-1#
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.

lab@mxA-1# set group P1-P2 type external

lab@mxA-1# set group P1-P2 neighbor 172.22.12V.2

lab@mxA-1# set group P1-P2 neighbor 172.22.12V.2

lab@mxA-1# set group P1-P2 peer-as 65412

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 3.2
Use the run show bgp summary command to verify that the EBGP sessions to
P1 and P2 routers are established.

inet.0 10 6 0 0 0 0
172.16.1.1 65001 17 17 0 0 6:05 Establ
R3-1.inet.0: 2/6/6/0
172.16.1.2 65001 16 17 0 0 6:05 2/
2/2/0 0/0/0/0
172.22.121.2 65412 6 6 0 0 1:16 4/
4/4/0 0/0/0/0
172.22.123.2 65412 5 5 0 0 1:02 0/
4/4/0 0/0/0/0

lab@mxA-1#
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.
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

lab@mxA-1#
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.

lab@mxA-1# run show route receive-protocol bgp 172.22.12V.2

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


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

lab@mxA-1#
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.

lab@mxA-1# run show route 30.30.0.0/24 detail

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
Source: 172.22.123.2
State: <NotBest Ext>
Inactive reason: Not Best in its group - Active preferred
Age: 5:16
Task: BGP_65412.172.22.123.2+179
AS path: 65412 I
Accepted
Localpref: 100
Router ID: 172.31.101.1

lab@mxA-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.
lab@mxA-1# set group P1-P2 multipath

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 3.7
Display the 30.30.0.0/24 route again using the run show route 30.30.0.0/
24 detail command.
lab@mxA-1# run show route 30.30.0.0/24 detail

Address: 0x28a11c0
Source: 172.22.121.2
Next hop: 172.22.121.2 via ge-1/0/0.1111
State: <Active Ext>
Age: 6:17
Task: BGP_65412.172.22.121.2+53546
AS path: 65412 I
Accepted Multipath
Localpref: 100
Router ID: 172.31.100.1
Address: 0x282fcd4
Source: 172.22.123.2
Age: 6:03
Task: BGP_65412.172.22.123.2+179
AS path: 65412 I
Accepted
Localpref: 100
Router ID: 172.31.101.1

lab@mxA-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.
lab@mxA-1# run show route forwarding-table destination 30.30.0.0/24
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
30.30.0.0/24 user 0 172.22.123.2 ucst 673 6 ge-1/0/0.1113
Routing table: __master.anon__.inet

Internet:
default perm 0 rjct 523 1
Routing table: default-switch.inet

Internet:
Routing table: R3-1.inet

Internet:

lab@mxA-1#

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

lab@mxA-1# set term 1 from route-filter 30.30/22 longer

lab@mxA-1# set term 1 then load-balance per-packet

lab@mxA-1# show
term 1 {
from {
protocol bgp;
}
then {
load-balance per-packet;
}
}

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

lab@mxA-1# top edit routing-options forwarding-table
[edit routing-options forwarding-table]

lab@mxA-1# set export pfe-load-balance

lab@mxA-1# commit
commit complete

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.
lab@mxA-1# run show route forwarding-table destination 30.30/24
Routing table: default.inet
Internet:
30.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__.inet

Internet:
Routing table: default-switch.inet

Internet:
Routing table: R3-1.inet

Internet:

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

lab@mxA-1# set static route 172.31.102.1 next-hop 172.22.12V.2

lab@mxA-1# set static route 172.31.102.1 no-readvertise

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.
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 bytes
--- 172.31.102.1 ping statistics ---

[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
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.
lab@mxA-1# up 1 edit protocols bgp

lab@mxA-1# set group P3 type external

lab@mxA-1# set group P3 local-address 172.16.Y.2

lab@mxA-1# set group P3 neighbor 172.31.102.1 peer-as 65020

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 4.4
Check the state of the EBGP session using the run show bgp summary
command.
inet.0 14 14 0 0 0 0
172.16.1.1 65001 50 49 0 0 20:27 Establ
R3-1.inet.0: 2/8/8/0
172.16.1.2 65001 48 50 0 0 20:27 2/
2/2/0 0/0/0/0
172.22.121.2 65412 38 38 0 0 15:38 6/
6/6/0 0/0/0/0
172.22.123.2 65412 36 37 0 0 15:24 6/
6/6/0 0/0/0/0
172.31.102.1 65020 0 0 0 0 5 Idle


lab@mxA-1#
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.
lab@mxA-1# set group P3 multihop

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 4.6
Check the status again of the P3 session with the run show bgp summary
command.
inet.0 20 14 0 0 0 0
172.16.1.1 65001 54 54 0 0 21:56 Establ
R3-1.inet.0: 2/8/8/0
172.16.1.2 65001 53 54 0 0 21:56 2/
8/8/0 0/0/0/0
172.22.121.2 65412 41 41 0 0 17:07 6/
6/6/0 0/0/0/0
172.22.123.2 65412 40 40 0 0 16:53 6/
6/6/0 0/0/0/0
172.31.102.1 65020 5 5 0 0 48 Establ
R3-1.inet.0: 6/6/6/0

lab@mxA-1#

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.
lab@mxA-1# run show route receive-protocol bgp 172.31.102.1

* 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

lab@mxA-1#
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.
lab@mxA-1# top edit routing-options
lab@mxA-1# set aggregate route 172.16.Y.0/24
lab@mxA-1#
Step 5.2
Configure the same aggregate route in the [edit routing-instances R3-Y
routing-options] hierarchy.

lab@mxA-1# set aggregate route 172.16.Y.0/24

lab@mxA-1#
Step 5.3
export-aggregate] hierarchy. Create a routing policy named
export-aggregate that will advertise the aggregate route and suppress the
more specific routes.
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

lab@mxA-1# set term 1 from route-filter 172.16.Y/24 exact


lab@mxA-1# set term 2 from route-filter 172.16.Y/24 longer


lab@mxA-1# show
term 1 {
from {
protocol aggregate;

}
then accept;
}
term 2 {
from {
}
then reject;
}

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.

lab@mxA-1# set group P1-P2 export export-aggregate

lab@mxA-1#
Step 5.5
hierarchy. Apply the export-aggregate policy as an export policy for the P3
group. Commit the configuration and return to operational mode.

lab@mxA-1# set group P3 export export-aggregate

commit complete
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


* 172.16.1.0/24 Self I
lab@mxA-1> show route advertising-protocol bgp 172.22.12V.2

* 172.16.1.0/24 Self I
lab@mxA-1> show route advertising-protocol bgp 172.31.102.1

* 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 8
BGP 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
number.
routing tables.
www.juniper.net BGP Attributes: Next Hop, Origin, MED, and AS Path (Detailed) • Lab 8–1
11.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: lab
Password:
--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

lab@mxA-1>
Step 1.3
[edit]
load complete
[edit]
Lab 8–2 • BGP Attributes: Next Hop, Origin, MED, and AS Path (Detailed) www.juniper.net
commit complete
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.0
40.40.0.0/24 [BGP/170] 00:15:53, localpref 100, from 172.16.1.2

AS path: 65020 I
Unusable
AS path: 65020 I
Unusable
AS path: 65020 I
Unusable
AS path: 65020 I
Unusable
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

40.40.0.0/24 (1 entry, 0 announced)
Next hop type: Unusable
Address: 0x25e377c
State: <Hidden Int Ext>
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 route-type external

lab@mxA-1# set term 1 then next-hop self

lab@mxA-1# show
term 1 {
from {
protocol bgp;
route-type external;
}
then {
next-hop self;
}
}

lab@mxA-1#
Step 1.8
input.
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.

lab@mxA-1# set group ibgp export next-hop-self

lab@mxA-1# commit
commit complete

lab@mxA-1>#
Step 1.9
Use the run show route hidden command to verify that all routes are active
and usable.
lab@mxA-1# run show route hidden


AS path: 65412 I
Unusable
AS path: 65412 I
Unusable
AS path: 65412 I
Unusable
AS path: 65412 I
Unusable
AS path: 65412 65002 I
Unusable

lab@mxA-1#
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.

lab@mxA-1# set group ibgp export next-hop-self

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.

lab@mxA-1#
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.
lab@mxA-1# delete group P1-P2 multipath

lab@mxA-1# commit
commit complete

lab@mxA-1>
Step 2.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.

* 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


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

lab@mxA-1#
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.
lab@mxA-1# run show route 172.16.R.0/24 table inet.0 detail

Address: 0x282f0f4
Source: 172.22.121.2
State: <Active Ext>
Age: 19:41
Task: BGP_65412.172.22.121.2+53546
AS path: 65412 65002 I Aggregator: 65002 172.16.2.1
Accepted
Localpref: 100
Router ID: 172.31.100.1
Address: 0x282ff80
Source: 172.22.123.2
Age: 16
Task: BGP_65412.172.22.123.2+58753
Accepted
Localpref: 100
Router ID: 172.31.101.1
Next hop type: Indirect
Address: 0x282f8f8
Source: 172.16.1.2
Indirect next hop: 29152d0 1048575
State: <Int Ext>
Inactive reason: Interior > Exterior > Exterior via Interior
Age: 7:17 Metric2: 1
Task: BGP_65001.172.16.1.2+179
Accepted
Localpref: 100
Router ID: 172.16.1.2

lab@mxA-1#
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
P1-P2-import] hierarchy. Write the import policy to change the origin to egp
on the summary route being received from P1 and P2.
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 route-filter 172.16.R.0/24 exact

lab@mxA-1# set term 1 then origin egp

lab@mxA-1# show
term 1 {
from {
protocol bgp;
}
then origin egp;
}

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

lab@mxA-1# set group P1-P2 import P1-P2-import
lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 2.6
command to display your partner’s summary route in the default routing instance.

Address: 0x282f8f8
Source: 172.16.1.2
Indirect next hop: 29152d0 1048575
State: <Active Int Ext>
Task: BGP_65001.172.16.1.2+179
Announcement bits (2): 0-KRT 7-Resolve tree 5
Accepted
Localpref: 100
Router ID: 172.16.1.2
Address: 0x282f0f4
Source: 172.22.121.2
State: <Ext>
Inactive reason: Origin
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
Address: 0x282ff80
Source: 172.22.123.2
Inactive reason: Not Best in its group - Router ID
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

lab@mxA-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.
lab@mxA-1# delete group P1-P2 import

commit complete
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
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:
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
vr-device (ttyp2)
login: username
Password: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>
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)
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
AS path: 65001 I
> to 172.22.252.2 via ge-1/0/4.1194

hidden)
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
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

lab@mxA-1# set group P1-P2 neighbor 172.22.12V.2 metric-out 10

lab@mxA-1# commit
commit complete

lab@mxA-1>#
STOP Stop and wait for the remote student team to finish the previous step.
Step 3.6
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.

hidden)
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

hidden)
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.
lab@mxA-1# top edit policy-options
[edit policy-options]
lab@mxA-1# copy policy-statement export-aggregate to policy-statement export-p2
lab@mxA-1# show policy-statement export-p2
term 1 {
from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
}
then reject;
}
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.
lab@mxA-1# edit policy-statement export-p2
[edit policy-options policy-statement export-p2]

lab@mxA-1# set term 1 then metric 20

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

lab@mxA-1# commit
commit complete

lab@mxA-1>#
Step 3.10
routers.

hidden)
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

hidden)
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.
lab@mxA-1# delete neighbor 172.22.12V.2 metric-out

lab@mxA-1# delete neighbor 172.22.12V.2 export

lab@mxA-1# show
type external;
export export-aggregate;
peer-as 65412;
neighbor 172.22.121.2;
neighbor 172.22.123.2;

lab@mxA-1# commit
commit complete

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: lab
Password:
--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

lab@mxA-1>
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.1
Trying 172.16.2.1...
Connected to 172.16.2.1.
Escape character is '^]'.
mxA-2 (ttyp1)
login: lab
Password:
--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

lab@mxA-2>
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
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.
lab@mxA-1# show policy-statement export-p3
term 1 {
from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
}
then reject;
}
lab@mxA-1#
Step 4.7
hierarchy. Using the as-path-prepend option, insert your partner’s AS number
in to the AS Path.

lab@mxA-1# set term 1 then as-path-prepend 6500R

lab@mxA-1#
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.

lab@mxA-1# set group P3 neighbor 172.31.102.1 export export-p3

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.
lab@mxA-1# top edit policy-options policy-statement export-aggregate

lab@mxA-1# show
term 1 {
from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
}
then reject;
}

lab@mxA-1# set term 1 then as-path-prepend "6500Y 6500Y 6500Y"

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 4.11
From the Telnet session of your partner’s device, use the show route

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.
lab@mxA-1# up 1 edit policy-statement export-p3

lab@mxA-1# show
term 1 {
from {
protocol aggregate;
}
then {
as-path-prepend 65002;
accept;
}
}
term 2 {
from {
}
then reject;
}

lab@mxA-1# delete term 1 then as-path-prepend

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 4.13


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
export-aggregate] hierarchy. Display the policy using the show command and
delete the as-path-prepend statement. Commit the change when completed.
lab@mxA-1# up 1 edit policy-statement export-aggregate

lab@mxA-1# show
term 1 {
from {
protocol aggregate;
}
then {
as-path-prepend "65001 65001 65001";
accept;
}
}
term 2 {
from {
}
then reject;
}

lab@mxA-1# delete term 1 then as-path-prepend

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 4.16
command to display the routes being received from the P1 router.

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

lab@mxA-1#
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.
lab@mxA-1# run show route receive-protocol bgp 172.22.12V.2 aspath-regex ".*
6500R"

* 172.16.2.0/24 172.22.121.2 65412 65002 I

lab@mxA-1#
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.
lab@mxA-1# up
lab@mxA-1# set as-path partner-as ".* 6500R"
lab@mxA-1#
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.
lab@mxA-1# edit policy-statement import-P1
[edit policy-options policy-statement import-P1]


lab@mxA-1# set term 1 from as-path partner-as



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.

lab@mxA-1# set neighbor 172.22.12Y.2 import import-P1

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 4.21
command to display the routes being received from P1.

* 172.16.2.0/24 172.22.121.2 65412 65002 I

lab@mxA-1#
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.
lab@mxA-1# run show route advertising-protocol bgp 172.22.12V.2

* 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

lab@mxA-1#
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.

lab@mxA-1# set routing-options static route 172.16.10.0/24 reject

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.
lab@mxA-1# run show route advertising-protocol bgp 172.22.12V.2 aspath-regex
"()"

* 172.16.1.0/24 Self I
* 172.16.10.0/24 Self I

lab@mxA-1#
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.
lab@mxA-1# set as-path internal-as "()"
lab@mxA-1#
Step 4.26
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.
lab@mxA-1# edit policy-statement export-aggregate

lab@mxA-1# show
term 1 {
from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
}
then reject;
}


lab@mxA-1# set term 3 from as-path internal-as


commit complete
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 "()"
* 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 9
BGP 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
number.
routing tables.
www.juniper.net BGP Attributes: Local-Preference and Communities (Detailed) • Lab 9–1

11.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: lab
Password:
--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

lab@mxA-1>
Step 1.3
configuration has been loaded, commit the changes and exit to operational mode.
[edit]
load complete
[edit]
commit complete
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

Address: 0x282fba4
Source: 172.22.121.2
State: <Active Ext>
Age: 48:27
Task: BGP_65412.172.22.121.2+179
Accepted
Localpref: 100
Router ID: 172.31.100.1
Address: 0x282fc88
Source: 172.22.123.2
Age: 48:27
Task: BGP_65412.172.22.123.2+54248
Accepted

Localpref: 100
Router ID: 172.31.101.1
Address: 0x282ff80
Source: 172.16.1.2
Indirect next hop: 28e2960 1048576
State: <Int Ext>
Inactive reason: Interior > Exterior > Exterior via Interior
Task: BGP_65001.172.16.1.2+179
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 neighbor 172.22.12V.2


lab@mxA-1# set term 1 then local-preference 110

lab@mxA-1# show
term 1 {
from {
protocol bgp;
neighbor 172.22.121.2;
}
then {
local-preference 110;
}
}

lab@mxA-1#
Step 1.6
the import-p1 policy as an import policy under the group. Commit the

lab@mxA-1# set import import-p1

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 1.7
command to display detailed information about your partner’s summary route in the


Address: 0x282fba4
Source: 172.22.121.2
State: <Active Ext>
Age: 1:08:04
Task: BGP_65412.172.22.121.2+179
Accepted
Localpref: 110
Router ID: 172.31.100.1
Address: 0x282fc88
Source: 172.22.123.2
State: <Ext>
Inactive reason: Local Preference
Age: 1:08:04
Task: BGP_65412.172.22.123.2+54248
Accepted
Localpref: 100
Router ID: 172.31.101.1

lab@mxA-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.
lab@mxA-1# run show route 172.16.R.0/24 table R3-Y.inet.0 detail

Address: 0x282fee8
Source: 172.16.1.1
Indirect next hop: 28e2870 1048575
Task: BGP_65001.172.16.1.1+51715
Accepted
Localpref: 110
Router ID: 172.16.1.1
Address: 0x282fb58
Source: 172.31.102.1
Indirect next hop: 28e23c0 1048574
State: <Ext>
Age: 1:11:51 Metric2: 0
Task: BGP_65020.172.31.102.1+179
Accepted
Localpref: 100

Router ID: 20.20.1.1

lab@mxA-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.
lab@mxA-1# top edit policy-options policy-statement import-p3


lab@mxA-1# set term 1 from neighbor 172.31.102.1



lab@mxA-1# show
term 1 {
from {
protocol bgp;
neighbor 172.31.102.1;
}
then {

}
}

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

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 1.11
Use the run show route 172.16.R.0/24 table R3-Y.inet.0 detail
R3-Y routing instance.
lab@mxA-1# run show route 172.16.R.0/24 table R3-Y.inet.0 detail

172.16.2.0/24 (1 entry, 1 announced)
Address: 0x2a7c224
Source: 172.31.102.1
Indirect next hop: 2b381c8 1048574
State: <Active Ext>
Task: BGP_65020.172.31.102.1+179
Accepted
Localpref: 120

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.
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:100 members 65001:100

lab@mxA-1#
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.
lab@mxA-1#
Step 2.3
hierarchy and use the show command to display the policy. In term 1, set the
community with the 6500Y:100 community configured previously.

lab@mxA-1# show
term 1 {
from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
}
then reject;
}

lab@mxA-1# set term 1 then community set 6500Y:100


lab@mxA-1#
Step 2.4

lab@mxA-1# show
term 1 {
from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
}
then reject;
}


lab@mxA-1#
Step 2.5

lab@mxA-1# show
term 1 {
from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
}

then reject;
}


lab@mxA-1#
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.



lab@mxA-1# commit
commit complete

lab@mxA-1#
STOP Stop and wait until your partner has completed the previous step.
Step 2.7
command to display detailed information about your partner’s summary route in the

Address: 0x2a7e9a0
Source: 172.16.1.2

Indirect next hop: 2b3c390 1048576
Task: BGP_65001.172.16.1.2+179
Communities: 65002:110
Accepted
Localpref: 120
Router ID: 172.16.1.2
Address: 0x2a7e5c4
Source: 172.22.121.2
State: <Ext>
Age: 30:12
Task: BGP_65412.172.22.121.2+179
Accepted
Localpref: 110
Router ID: 172.31.100.1
Address: 0x2a7c354
Source: 172.22.123.2
State: <Ext>
Age: 30:00
Task: BGP_65412.172.22.123.2+179
Accepted
Localpref: 100
Router ID: 172.31.101.1

lab@mxA-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
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.
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









lab@mxA-1# show

term 1 {
from community 65002:100;
then {
accept;
}
}
term 2 {
then {
accept;
}
}
term 3 {
then {
accept;
}
}

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.

lab@mxA-1# delete import

lab@mxA-1# set import import-communities

lab@mxA-1#
Step 2.10
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.
lab@mxA-1# top edit routing-instances R3-Y protocols bgp group P3

lab@mxA-1# delete import

lab@mxA-1# set import import-communities

commit complete
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

Address: 0x282fc88
Source: 172.22.123.2
State: <Active Ext>
Age: 4:44:04
Task: BGP_65412.172.22.123.2+54248
Accepted
Localpref: 120
Router ID: 172.31.101.1
Address: 0x282fba4
Source: 172.22.121.2
State: <Ext>
Age: 4:44:04
Task: BGP_65412.172.22.121.2+179
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
lab@mxA-1> show route 172.16.R.0/24 table R3-Y.inet.0 detail

Address: 0x282fe04
Source: 172.16.1.1
Indirect next hop: 28c43c0 1048576
Task: BGP_65001.172.16.1.1+179
Accepted
Localpref: 120
Router ID: 172.16.1.1
Address: 0x282f484
Source: 172.31.102.1
Indirect next hop: 28c41e0 1048574
State: <Ext>

Task: BGP_65020.172.31.102.1+179
Accepted
Localpref: 110
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 10
Scaling 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–1

11.a.11.4R1.14
Note
number.
routing tables.
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:
Lab 10–2 • Scaling BGP (Detailed) www.juniper.net

Step 1.2
mxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

lab@mxA-1>
Step 1.3
configuration has been loaded, commit the changes and return to operational
mode.
[edit]
load complete
[edit]
commit complete
lab@mxA-1>
Step 1.4
Use the show ospf neighbor command to verify OSPF reachability from the
default router.
10.0.10.2 ge-1/0/4.0 Full 172.16.1.2 128 36
10.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 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.0
10.0.13.0/24 *[OSPF/10] 00:03:11, metric 2
> to 10.0.11.2 via ge-1/0/5.0
172.16.1.2/32 *[OSPF/10] 07:56:29, metric 1
> to 10.0.10.2 via ge-1/0/4.0
172.16.1.3/32 *[OSPF/10] 00:03:11, metric 1
> to 10.0.11.2 via ge-1/0/5.0
172.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.0
224.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.0
10.0.13.0/24 *[OSPF/10] 00:03:12, metric 2
> to 10.0.12.2 via ge-1/0/6.0
172.16.1.1/32 *[OSPF/10] 07:56:29, metric 1
> to 10.0.10.1 via ge-1/1/4.0
172.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.0
172.16.1.4/32 *[OSPF/10] 00:03:12, metric 1
> to 10.0.12.2 via ge-1/0/6.0
224.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.0
10.0.12.0/24 *[OSPF/10] 00:03:08, metric 2
> to 10.0.13.2 via ge-1/0/7.0
172.16.1.1/32 *[OSPF/10] 00:03:13, metric 1
> to 10.0.11.1 via ge-1/1/5.0
172.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.0
172.16.1.4/32 *[OSPF/10] 00:03:08, metric 1
> to 10.0.13.2 via ge-1/0/7.0
224.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.0
10.0.11.0/24 *[OSPF/10] 00:03:09, metric 2
> to 10.0.13.1 via ge-1/1/7.0
172.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.0
172.16.1.2/32 *[OSPF/10] 00:03:14, metric 1
> to 10.0.12.1 via ge-1/1/6.0
172.16.1.3/32 *[OSPF/10] 00:03:09, metric 1
> to 10.0.13.1 via ge-1/1/7.0
224.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
input.
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

lab@mxA-1# set local-address 172.16.Y.1

lab@mxA-1# set cluster 172.16.Y.1

lab@mxA-1# set neighbor 172.16.Y.2



lab@mxA-1#
Step 1.7
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#
Step 1.8
ibgp] hierarchy and configure the default router’s loopback address as an IBGP
BGP group.




lab@mxA-1#

Step 1.9
ibgp] hierarchy and configure the default router’s loopback address as an IBGP
BGP group. Commit the configuration when completed.




lab@mxA-1# commit
commit complete

lab@mxA-1>#
Step 1.10
Use the command run show bgp summary to ensure that all of the IBGP peer
sessions are established.
inet.0 10 5 0 0 0 0
172.16.1.1 65001 22 19 0 0 7:43 Establ
R3-1.inet.0: 0/5/5/0
172.16.1.1 65001 20 19 0 0 7:40 Establ
R4-1.inet.0: 0/5/5/0
172.16.1.1 65001 20 21 0 0 7:36 Establ
R5-1.inet.0: 0/5/5/0
172.16.1.2 65001 18 22 0 0 7:43 Establ
inet.0: 0/0/0/0
172.16.1.3 65001 18 20 0 0 7:39 Establ
inet.0: 0/0/0/0
172.16.1.4 65001 20 20 0 0 7:36 Establ
inet.0: 0/5/5/0
172.22.121.2 65412 1019 1055 0 1 2:48
Establ
inet.0: 5/5/5/0
172.31.102.1 65020 112 110 0 0 48:01
Establ
R5-1.inet.0: 5/5/5/0

lab@mxA-1#
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.
lab@mxA-1# run show route hidden table inet.0


AS path: 65020 I
Unusable
AS path: 65020 I
Unusable
AS path: 65020 I
Unusable
AS path: 65020 I
Unusable
AS path: 65020 65002 I
Unusable

lab@mxA-1#
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.
lab@mxA-1# run show route 40.40/24 hidden detail

Address: 0x25e377c
Age: 11:43
Task: BGP_65001.172.16.1.4+179
AS path: 65020 I
Accepted
Localpref: 100
Router ID: 172.16.1.4

lab@mxA-1#
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.
lab@mxA-1# run show route 40.40/24 hidden extensive

Address: 0x25e377c

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
Indirect next hop: 0 -

lab@mxA-1#
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
next-hop-self] hierarchy and create a policy that will modify the next-hop
attribute to the local loopback address.
lab@mxA-1# top edit policy-options policy-statement next-hop-self

lab@mxA-1# set term 1 then next-hop self

lab@mxA-1#
Step 1.15
ibgp] hierarchy and apply the next-hop-self policy as an export policy in the
group.

lab@mxA-1# set export next-hop-self

lab@mxA-1#

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
lab@mxA-1# top edit protocols bgp group rr-cluster


lab@mxA-1# commit
commit complete

lab@mxA-1#
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.


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

lab@mxA-1#

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.
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 ms
10 10.0.10.1 (10.0.10.1) 0.348 ms 59.994 ms 0.374 ms

lab@mxA-1#
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
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.

lab@mxA-1# top edit policy-options policy-statement next-hop-self


lab@mxA-1# set term 1 from route-type external

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.
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.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

lab@mxA-1#
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.
lab@mxA-1# run show route 40.40/24 table R4-Y.inet.0 detail

Address: 0x28c3e9c

Source: 172.16.1.1
Indirect next hop: 28cb5a0 1048582
Task: BGP_65001.172.16.1.1+49990
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

lab@mxA-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.
lab@mxA-1# run show route 30.30/24 table R4-Y.inet.0 detail

Address: 0x28c3d6c
Source: 172.16.1.1
Indirect next hop: 28c41e0 1048576
Task: BGP_65001.172.16.1.1+49990

AS path: 65412 I
Accepted
Localpref: 100
Router ID: 172.16.1.1

lab@mxA-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.
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.
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.

lab@mxA-1# top
[edit]
lab@mxA-1# load override ajspr/lab10-part2-start.config
load complete
[edit]
commit complete
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.
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.
10.0.10.2 ge-1/0/4.0 Full 172.16.1.2 128 33
10.0.11.2 ge-1/0/5.0 Full 172.16.1.3 128 30
lab@mxA-1>

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-Y
10.0.12.1 ge-1/1/6.0 Full 172.16.1.2 128 39
10.0.13.1 ge-1/1/7.0 Full 172.16.1.3 128 38
lab@mxA-1>

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
lab@mxA-1# set confederation 6500Y members 6510Y
lab@mxA-1#
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.
lab@mxA-1# top edit protocols bgp group ibgp
[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.
lab@mxA-1# top edit logical-systems R3-Y routing-options
[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.
lab@mxA-1# up 1 edit protocols bgp group ibgp
[edit logical-systems R3-1 protocols bgp group ibgp]




lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 2.8
Use the run show bgp summary command to display the BGP peer sessions.

inet.0 5 5 0 0 0 0
172.16.1.2 65101 7 10 0 0 2:17 0/
0/0/0 0/0/0/0
172.22.121.2 65412 8 8 0 0 2:17 5/
5/5/0 0/0/0/0

lab@mxA-1#
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.
lab@mxA-1# run show bgp summary logical-system R3-Y
inet.0 5 5 0 0 0 0
172.16.1.1 65101 11 10 0 0 3:27 5/
5/5/0 0/0/0/0

lab@mxA-1#

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




lab@mxA-1#
Step 2.11
ibgp] hierarchy and configure an internal peer session to the R5-Y router using
loopback addresses.




lab@mxA-1#

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




lab@mxA-1#
Step 2.13
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.





lab@mxA-1# commit
commit complete

lab@mxA-1#
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.

inet.0 4 4 0 0 0 0
172.16.1.3 65201 11 11 0 0 3:34 0/
0/0/0 0/0/0/0
172.31.102.1 65020 10 11 0 0 3:34 4/
4/4/0 0/0/0/0

lab@mxA-1#
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.
inet.0 5 5 0 0 0 0
172.16.1.4 65201 35 34 0 0 14:25 5/
5/5/0 0/0/0/0

lab@mxA-1#
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.
lab@mxA-1# top edit protocols bgp group cbgp
[edit protocols bgp group cbgp]

lab@mxA-1# set type external

lab@mxA-1# set multihop



lab@mxA-1# set peer-as 6520Y

lab@mxA-1#
Step 2.17
cbgp] hierarchy and configure the confederation BGP session to the default router.
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

lab@mxA-1# set multihop



lab@mxA-1# set peer-as 6510Y

lab@mxA-2# commit
commit complete

lab@mxA-2#
Step 2.18
Use the run show bgp summary command to display the bgp peering sessions
in the default router.
inet.0 10 5 0 0 0 0
172.16.1.2 65101 104 105 0 0 45:36 0/
0/0/0 0/0/0/0
172.16.1.4 65201 10 11 0 0 3:08 0/
5/5/0 0/0/0/0
172.22.121.2 65412 101 103 0 0 45:36 5/
5/5/0 0/0/0/0

lab@mxA-1#
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.

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.

lab@mxA-1# run show route receive-protocol bgp 172.16.Y.4 detail

lab@mxA-1#
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.


AS path: (65201) 65020 I
Unusable
AS path: (65201) 65020 I
Unusable
AS path: (65201) 65020 I
Unusable
AS path: (65201) 65020 I
Unusable
AS path: (65201) 65020 65002 I
Unusable

lab@mxA-1#

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.

commit complete
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

* 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 11
BGP 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–1

11.a.11.4R1.14
Note
number.
routing tables.
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
Lab 11–2 • BGP Route Damping (Detailed) www.juniper.net

mxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

lab@mxA-1>
Step 1.3
[edit]
load complete
[edit]
lab@mxA-1# commit
commit complete
lab@mxA-1#
Step 1.4
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

lab@mxA-1# set term 1 from route-filter 172.16.Y.0/24 longer

lab@mxA-1# commit
commit complete

lab@mxA-1#
Step 1.5
display the aggregate route and the redistributed static routes.

172.16.1.0/24 *[Aggregate/130] 00:19:49

Reject
172.16.1.0/26 *[Static/5] 00:19:49
Reject
172.16.1.1/32 *[Direct/0] 00:19:48
> via lo0.0
172.16.1.2/32 *[OSPF/10] 00:18:57, metric 1
> to 10.0.10.2 via ge-1/0/4.0
172.16.1.64/26 *[Static/5] 00:19:06
Reject
AS path: I
> to 10.0.10.2 via ge-1/0/4.0
AS path: I
> to 10.0.10.2 via ge-1/0/4.0

lab@mxA-1#
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.
lab@mxA-1# set static route 172.22.Y.0/24 reject
lab@mxA-1#
Step 2.2
hierarchy and configure a third term in the policy to advertise the static route. Use
the show command to display the policy.
lab@mxA-1# top edit policy-options policy-statement export-p1


lab@mxA-1# set term 3 from route-filter 172.22.Y.0/24 exact


lab@mxA-1# show
term 1 {
from {
protocol aggregate;

}
then {
community set 65001:100;
accept;
}
}
term 2 {
from {
}
then reject;
}
term 3 {
from {
protocol static;
}
then accept;
}

lab@mxA-1#
Step 2.3
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.


lab@mxA-1# set term 3 from route-filter 172.22.Y.0/24 exact


lab@mxA-1# show
term 1 {
from {
protocol aggregate;
}
then {
community set 65001:120;
accept;
}
}
term 2 {
from {

}
then reject;
}
term 3 {
from {
protocol static;
}
then accept;
}

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.
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

lab@mxA-1#
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.


lab@mxA-1# set damping

lab@mxA-1# commit
commit complete

lab@mxA-1#
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.
lab@mxA-1# delete static route 172.22.Y.0/24
lab@mxA-1# commit
commit complete
lab@mxA-1#
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.
lab@mxA-1# run show route damping history table inet.0 detail

BGP /-101
Address: 0x28b4308
Source: 172.22.121.2
State: <Hidden Ext>
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
Address: 0x28b405c
Source: 172.22.123.2
State: <Hidden Ext>
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
Flaps: 1
History entry. Expires in: 00:30:20
lab@mxA-1#
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.
lab@mxA-1# top
[edit]
load complete
[edit]
lab@mxA-1# commit
commit 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

Address: 0x28b4308
Source: 172.22.121.2
State: <Active Ext>
Age: 1:29
Task: BGP_65412.172.22.121.2+179
AS path: 65412 65002 I
Accepted
Localpref: 100
Router ID: 172.31.100.1
Flaps: 2
Address: 0x28b405c

Source: 172.22.123.2
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
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]
load complete
[edit]
lab@mxA-1# commit
commit complete
[edit]
load complete
[edit]
lab@mxA-1# commit
commit complete
[edit]
load complete
[edit]
lab@mxA-1# commit
commit complete
[edit]
load complete
[edit]
lab@mxA-1# commit
commit 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
[edit]
lab@mxA-1# run show route damping suppressed table inet.0 detail

BGP /-101
Address: 0x28b4308
Source: 172.22.121.2
State: <Hidden Ext>
Age: 34
Task: BGP_65412.172.22.121.2+179
AS path: 65412 65002 I
Localpref: 100
Router ID: 172.31.100.1
Flaps: 6
Suppressed. Reusable in: 00:41:00

Preference will be: 170
BGP /-101
Address: 0x28b405c
Source: 172.22.123.2
State: <Hidden Ext>
Age: 34
Task: BGP_65412.172.22.123.2+179
AS path: 65412 65002 I
Localpref: 100
Router ID: 172.31.101.1
Flaps: 6
[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
lab@mxA-1# set damping disable disable
lab@mxA-1# set damping aggressive suppress 1500
lab@mxA-1# set damping aggressive half-life 10
lab@mxA-1# set damping aggressive reuse 500
lab@mxA-1#
Step 3.2
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.
lab@mxA-1# edit policy-statement modify-damping
[edit policy-options policy-statement modify-damping]



lab@mxA-1# set term 1 then damping disable




lab@mxA-1# set term 2 then damping aggressive

lab@mxA-1# show
term 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;
}

lab@mxA-1#
Step 3.3
the modify-damping policy as a group import policy. Commit the changes when
completed.

lab@mxA-1# set import modify-damping

lab@mxA-1# commit
commit complete

lab@mxA-1#
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
lab@mxA-1# run clear bgp damping

lab@mxA-1# run show route damping suppressed table inet.0


lab@mxA-1#
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.
lab@mxA-1# delete static route 172.22.Y.0/24
lab@mxA-1# commit
commit complete
lab@mxA-1# top
[edit]
load complete
[edit]
lab@mxA-1# commit
commit complete
[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

BGP /-101

Address: 0x28b405c
Source: 172.22.123.2
State: <Hidden Ext>
Inactive reason: Unusable path
Age: 2:22
Task: BGP_65412.172.22.123.2+179
AS path: 65412 65002 I
Localpref: 100
Router ID: 172.31.101.1
damping-parameters: aggressive
Flaps: 2
[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
command to verify that the damping policy on the P1 router is disabling damping on
received routes.
[edit]

Address: 0x28b4308
Source: 172.22.121.2
State: <Active Ext>
Age: 2:56
Task: BGP_65412.172.22.121.2+179
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]
commit complete
lab@mxA-1> exit


Advanced Junos Service Provider
Routing
Appendix A: Lab Diagrams

A–2 • Lab Diagrams www.juniper.net

www.juniper.net Lab Diagrams • A–3






















Ajspr 11 A LGD

Uploaded by

Copyright:

Available Formats

Ajspr 11 A LGD

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ajspr 11 A LGD

Uploaded by

Copyright:

Available Formats

Advanced Junos Service Provider

Detailed Lab Guide

Worldwide Education Services

1194 North Mathilda Avenue

Course Number: EDU-JUN-AJSPR

Lab 2: Configuring and Monitoring OSPF Areas and

Lab 3: Advanced OSPF Options and Routing Policy (Detailed) . . . . . . . . . . . . . . . . 3-1

Lab 4: IS-IS Configuration and Monitoring (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . 4-1

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

Lab 6: Configuring a Multilevel IS-IS Network (Detailed) . . . . . . . . . . . . . . . . . . . . . 6-1

Lab 7: BGP (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

www.juniper.net Contents • iii

Lab 10: Scaling BGP (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Lab 11: BGP Route Damping (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

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

www.juniper.net Course Overview • v

vi • Course Overview www.juniper.net

www.juniper.net Course Agenda • vii

CLI and GUI Text

Style Description Usage Example

Courier New Console text:

Input Text Versus Output Text

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxp0,

Defined and Undefined Syntax Variables

Style Description Usage Example

CLI Variable Text where variable value is already policy my-peers

viii • Document Conventions www.juniper.net

Education Services Offerings

www.juniper.net Additional Information • ix

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

Part 1: Load Reset Configuration

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

--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

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

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

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

--- 172.22.121.2 ping statistics ---

lab@mxA-1> ping 10.0.Y.2 count 5

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

Question: Were the pings successful?

Answer: The pings should be successful. If not,

--- JUNOS 11.4R1.14 built 2011-12-16 16:42:37 UTC

Connection closed by foreign host.

Question: Were you successful?

Answer: The Telnet should be successful. If not,

inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)

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

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

Question: How many static route entries are in your

Answer: There should be four static route entries.

Part 2: Creating the Network

Question: Which routers are area border routers

Answer: The student device default routing

Question: Which routers are backbone routers?

Answer: The vr-device is a backbone router.

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

Answer: The R3-Y routing instances on the student

[edit protocols ospf]