AJSPR 10.a-R LGD PDF

Advanced Junos Service Provider
Routing
10.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 10.a
Copyright © 2011 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 10.a — March 2011
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 10.3R1.9. 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: Verifying Router Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Part 2: Verifying Route Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Part 3: Creating the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Part 4: Configuring the OSPF LInk Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Part 5: Configuring Overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
Part 6: Performing Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization

(Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Part 1: Creating OSPF Stub Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Part 2: Creating a Stub No Summaries Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Part 3: Creating OSPF Not-So-Stubby-Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Part 4: Creating NSSA No Summaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
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-9
Part 3: Configuring External Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
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-8
Part 4: Migrating from OSPF to IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
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-12
Part 3: Manipulating IS-IS Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
Part 4: Configuring IS-IS External Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23
Lab 6: Configuring a Multilevel IS-IS Network (Detailed) . . . . . . . . . . . . . . . . . . . . . 6-1

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

Part 1: Establishing the OSPF Adjacency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Part 2: Establishing an IBGP Peering Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
Part 3: Configuring the P1 and P2 EBGP Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
Part 4: Configuring the EBGP Session with the P3 Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
Part 5: Summarizing the Internal Routes to the Peer Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-26
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-19
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-14
Lab 10: BGP Route Damping (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Part 1: Modifying IBGP Redistribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2
Part 2: Configuring BGP Damping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4
Part 3: Modifying the BGP Damping Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-13
Lab 11: Scaling BGP (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Part 1: Configuring Route Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2
Part 2: Configuring Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-21
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 10.3R1.9.
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.
• Control damping using routing policy.
• View damped routes using command-line interface (CLI) commands.
www.juniper.net Course Overview • v

• Describe the operation of BGP route reflection.
• Configure a route reflector.
• Describe the operation of a BGP confederation.
• Configure confederations.
• Describe peering relationships in a confederation.
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: BGP Route Damping
Lab 10: BGP Route Damping
Chapter 12: Route Reflection and Confederations
Lab 11: Scaling BGP
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 10.3R1.9. Previous and later versions of software might behave differently so
you should always consult the documentation and release notes for the version of code you are
running before reporting errors.
This document is written and maintained by the Juniper Networks Education Services development
team. Please send questions and suggestions for improvement to [email protected].
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
• Go to http://www.juniper.net/techpubs/.
• Locate the specific software or hardware release and title you need, and choose the
format in which you want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or
account representative.
Juniper Networks Support
For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or
at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).
www.juniper.net Additional Information • ix

x • Additional Information www.juniper.net
Lab 1
OSPF Multiarea Networks (Detailed)
Overview
In this lab, you will be using 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

10.a.10.3R1.9
Advanced Junos Service Provider Routing
Note
The lab topology requires you to display
information for the main routing instance
and another routing instance. When
referencing an ip-address, the third
octet will contain either an x or y, where x
= your pod number and y = either 1 or 2.
When referencing an OSPF area-id
(other than 0.0.0.0), y = 1 or 2.
VLAN-IDs are represented by x0 or xy. for
x0, x = your pod number. For xy, x = your
pod number and y = either 1 or 2.
When referencing the routing instance, the
commands include the routing instance
name, R3-z, where z 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-z option must
be used to specify the appropriate virtual
instance. When performing show
commands, the instance R3-z or
table R3-z option must be used to
display the appropriate adjacencies or
routing tables.
Part 1: Verifying Router 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.
Step 1.1
Log in to the router with the username lab using a password of lab123. Note that
both the name and password are case-sensitive.
Lab 1–2 • OSPF Multiarea Networks (Detailed) www.juniper.net

mxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 10.3R1.9 built 2010-08-13 12:48:28 UTC

lab@mxA-1>
Step 1.2
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 4 configured static routes for the 20.20.0.0/24, 20.20.1.0/24,
20.20.2.0/24, and 20.20.3.0/24 networks. Verify that there is a configured
routing-instance and a policy statement. Notify your instructor of any problems with
your device configuration.
lab@mxA-1> show configuration
## Last commit: 2011-01-02 20:43:18 UTC by lab
version 10.3R1.9;
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= [email protected]"; ##
SECRET-DATA
}
login {
user lab {
uid 2000;
class super-user;
authentication {
encrypted-password "$1$84J5Maes$cni5Hrazbd/IEHr/50oY30"; ##
SECRET-DATA
}
}
}
services {
ftp;
ssh;
telnet;
}
syslog {
user * {
any emergency;
}

file messages {
any notice;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
}
}
interfaces {
ge-1/0/0 {
vlan-tagging;
unit 1111 {
vlan-id 1111;
family inet {
address 172.22.121.1/24;
}
}
}
ge-1/0/4 {
vlan-tagging;
unit 10 {
vlan-id 10;
family inet {
address 10.0.10.1/24;
}
}
}
ge-1/1/4 {
vlan-tagging;
unit 10 {
vlan-id 10;
family inet {
address 10.0.10.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 192.168.20.1/32;
}
}
unit 1 {
family inet {
address 192.168.20.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.10;
interface lo0.1;
routing-options {
}
}
}
lab@mxA-1>
Step 1.3
Use the ping ip-address count 5 commands to verify that you can ping the
physical interfaces on each neighboring router.
lab@mxA-1> ping 172.22.12y.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

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”.
Try to telnet between the student device and the routing-instance router using the
telnet ip-address command. The username is lab and the password is
lab123
lab@mxA-1> telnet 10.0.x0.2
Trying 10.0.10.2...
Connected to 10.0.10.2.
Escape character is '^]'.
mxA-1 (ttyp0)
login: lab
Password:
--- JUNOS 10.3R1.9 built 2010-08-13 12:48:28 UTC

lab@mxA-1> exit
Connection closed by foreign host.
Question: Were you successful? If not, please notify

the instructor.
Answer: The Telnet should be successful.
Part 2: Verifying Route Information
In this lab part, you verify route information. To aid in completing the labs in a timely
manner, some routing information has been preconfigured on your router.
Step 2.1
Issue the show route protocol static command to ensure that the correct
routing information is present in each router.
lab@mxA-1> show route protocol static
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
20.20.0.0/24 *[Static/5] 00:03:13

Reject
20.20.1.0/24 *[Static/5] 00:03:13
Reject
20.20.2.0/24 *[Static/5] 00:03:13
Reject

20.20.3.0/24 *[Static/5] 00:03:13
Reject
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 3: Creating the Network
In this lab part, you create the network.

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

(ABR)?
Answer: The student device main 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 routing instances on the MX80s are

internal routers.

Step 3.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 (loopback interfaces included). Commit your configuration and exit to
operational mode.
lab@mxA-1> configure
Entering configuration mode
[edit]
lab@mxA-1# edit protocols ospf
[edit protocols ospf]

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

lab@mxA-1# set area y0 interface ge-1/0/4.xy

lab@mxA-1# set area 0 interface lo0.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.xy

lab@mxA-1# set area y0 interface lo0.1
lab@mxA-1# commit and-quit

commit complete
Exiting configuration mode
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 3.3
Verify the operation of OSPF by issuing the show ospf neighbor command.

lab@mxA-1> show ospf neighbor
Address Interface State ID Pri Dead
172.22.121.2 ge-1/0/0.1111 Full 192.168.100.1 128 37
10.0.10.2 ge-1/0/4.10 Full 192.168.20.2 128 33
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 3.4
Look at the routing table of the student device. Issue the show route command.
lab@mxA-1> show route

10.0.10.0/24 *[Direct/0] 3d 00:09:42

> via ge-1/0/4.10
10.0.10.1/32 *[Local/0] 3d 00:09:42
Local via ge-1/0/4.10
10.0.24.0/24 *[OSPF/10] 00:02:57, metric 3
> to 172.22.121.2 via ge-1/0/0.1111
10.210.15.0/27 *[Direct/0] 7w1d 22:41:02
> via fxp0.0
10.210.15.1/32 *[Local/0] 7w1d 22:41:02
Local via fxp0.0
20.20.0.0/24 *[Static/5] 2d 00:10:33
Reject
20.20.1.0/24 *[Static/5] 2d 00:10:33
Reject
20.20.2.0/24 *[Static/5] 2d 00:10:33
Reject
20.20.3.0/24 *[Static/5] 2d 00:10:33
Reject
172.22.121.0/24 *[Direct/0] 3d 00:09:42
> via ge-1/0/0.1111
172.22.121.1/32 *[Local/0] 3d 00:09:42
172.22.122.0/24 *[OSPF/10] 00:02:57, metric 2
> to 172.22.111.2 via ge-1/0/0.1111
192.168.20.1/32 *[Direct/0] 3d 00:09:42
> via lo0.0
192.168.20.2/32 *[OSPF/10] 00:02:21, metric 1
> to 10.0.10.2 via ge-1/0/4.10
192.168.21.1/32 *[OSPF/10] 00:02:57, metric 2
> to 172.22.111.2 via ge-1/0/0.1111
192.168.21.2/32 *[OSPF/10] 00:02:57, metric 3
> to 172.22.111.2 via ge-1/0/0.1111
192.168.100.1/32 *[OSPF/10] 00:02:57, metric 1
> to 172.22.111.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.10.0/24 *[Direct/0] 3d 00:09:42

> via ge-1/1/4.10
10.0.10.2/32 *[Local/0] 3d 00:09:42
10.0.24.0/24 *[OSPF/10] 00:02:21, metric 4
> to 10.0.10.1 via ge-1/1/4.10
172.22.121.0/24 *[OSPF/10] 00:02:21, metric 2
> to 10.0.10.1 via ge-1/1/4.10
172.22.122.0/24 *[OSPF/10] 00:02:21, metric 3
> to 10.0.10.1 via ge-1/1/4.10
192.168.20.1/32 *[OSPF/10] 00:02:21, metric 1
> to 10.0.10.1 via ge-1/1/4.10
192.168.20.2/32 *[Direct/0] 3d 00:09:42
> via lo0.1
192.168.21.1/32 *[OSPF/10] 00:02:21, metric 3
> to 10.0.10.1 via ge-1/1/4.10
192.168.21.2/32 *[OSPF/10] 00:02:21, metric 4
> to 10.0.10.1 via ge-1/1/4.10
192.168.100.1/32 *[OSPF/10] 00:02:21, metric 2
> to 10.0.10.1 via ge-1/1/4.10
224.0.0.5/32 *[OSPF/10] 00:03:12, metric 1
MultiRecv
Question: Do all routes show as active? Why or why

not?
Answer: Yes. Each route should be preceded by the

asterisk (*), indicating that the route is active.
Step 3.5
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. Commit your configuration and exit to operational mode.
[edit]

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

commit complete
Step 3.6
Use the show ospf database command to examine the link-state database on
the student device, which is the ABR and an ASBR. Notice that the output is
organized by areas, Area 0.0.0.0 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 GE 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) is
listed in Area 0.0.0.10.
lab@mxA-1> show ospf database
OSPF database, Area 0.0.0.0

Type ID Adv Rtr Seq Age Opt Cksum Len
Router *192.168.20.1 192.168.20.1 0x8000006d 302 0x22 0xf4b9 48
Router 192.168.21.1 192.168.21.1 0x8000006a 141 0x22 0x7144 48
Router 192.168.100.1 192.168.100.1 0x8000007e 825 0x22 0xef66 60
Network 172.22.121.2 192.168.100.1 0x80000029 2388 0x22 0xaf1c 32
Network 172.22.122.2 192.168.100.1 0x8000002a 1581 0x22 0xaf19 32
Summary *10.0.10.0 192.168.20.1 0x8000006a 2516 0x22 0x6e41 28
Summary 10.0.24.0 192.168.21.1 0x80000069 2058 0x22 0x5e50 28
Summary *192.168.20.2 192.168.20.1 0x80000026 23 0x22 0xb3de 28
Summary 192.168.21.2 192.168.21.1 0x80000025 2308 0x22 0xa3ed 28

Router *192.168.20.1 192.168.20.1 0x8000002c 302 0x22 0x9bba 36
Router 192.168.20.2 192.168.20.2 0x80000029 303 0x22 0xa2cc 48
Network 10.0.10.2 192.168.20.2 0x80000022 1375 0x22 0xb3ef 32
Summary *10.0.24.0 192.168.20.1 0x80000027 2266 0x22 0x588e 28
Summary *172.22.121.0 192.168.20.1 0x80000028 1016 0x22 0xafb5 28
Summary *172.22.122.0 192.168.20.1 0x80000028 266 0x22 0xaeb4 28
Summary *192.168.20.1 192.168.20.1 0x80000028 766 0x22 0xb93c 28
Summary *192.168.21.1 192.168.20.1 0x80000027 516 0x22 0x1fcb 28
Summary *192.168.21.2 192.168.20.1 0x80000025 2016 0x22 0x196e 28
Summary *192.168.100.1 192.168.20.1 0x80000026 1266 0x22 0x3f8b 28
ASBRSum *192.168.21.1 192.168.20.1 0x80000001 138 0x22 0x5cea 28
OSPF AS SCOPE link state database
Extern *20.20.0.0 192.168.20.1 0x80000001 302 0x22 0xb263 36
Extern *20.20.1.0 192.168.20.1 0x80000001 302 0x22 0xa76d 36
Extern *20.20.2.0 192.168.20.1 0x80000001 302 0x22 0x9c77 36
Extern *20.20.3.0 192.168.20.1 0x80000001 302 0x22 0x9181 36
Extern 20.20.4.0 192.168.21.1 0x80000001 141 0x22 0x7f91 36
Extern 20.20.5.0 192.168.21.1 0x80000001 141 0x22 0x749b 36
Extern 20.20.6.0 192.168.21.1 0x80000001 141 0x22 0x69a5 36
Extern 20.20.7.0 192.168.21.1 0x80000001 141 0x22 0x5eaf 36

Step 3.7
The ABR sends Type 1 LSAs into both the backbone and nonbackbone areas. Use
the show ospf database router extensive command to examine the
Type 1 LSAs.
lab@mxA-1> show ospf database router extensive

Router *192.168.20.1 192.168.20.1 0x8000006d 1227 0x22 0xf4b9 48
bits 0x3, link count 2
id 172.22.121.2, data 172.22.121.1, Type Transit (2)
Topology count: 0, Default metric: 10
id 192.168.20.1, data 255.255.255.255, Type Stub (3)
Topology default (ID 0)
Type: Transit, Node ID: 172.22.121.2
Metric: 10, Bidirectional
Gen timer 00:08:15
Aging timer 00:39:33
Installed 00:20:27 ago, expires in 00:39:33, sent 00:20:27 ago
Last changed 00:20:27 ago, Change count: 6, Ours
Router 192.168.21.1 192.168.21.1 0x8000006a 1066 0x22 0x7144 48
id 192.168.21.1, data 255.255.255.255, Type Stub (3)
Installed 00:17:44 ago, expires in 00:42:14
Last changed 00:17:44 ago, Change count: 3
Router 192.168.100.1 192.168.100.1 0x8000007e 1750 0x22 0xef66 60
id 192.168.100.1, data 255.255.255.255, Type Stub (3)
Last changed 1d 03:19:04 ago, Change count: 2

Router *192.168.20.1 192.168.20.1 0x8000002c 1227 0x22 0x9bba 36

Gen timer 00:11:11
Installed 00:20:27 ago, expires in 00:39:33, sent 00:20:27 ago
Last changed 00:20:27 ago, Change count: 5, Ours
Router 192.168.20.2 192.168.20.2 0x80000029 1228 0x22 0xa2cc 48
id 192.168.20.2, data 255.255.255.255, Type Stub (3)
Last changed 1d 02:06:21 ago, Change count: 6
Question: What is the difference between the two

Type 1 LSAs?
Answer: The LSA injected into the backbone

includes the 172.22.12x.0/24 network and the
router’s loopback. The LSA injected into the
nonbackbone area includes just the 10.0.x0.0/24
link between the main routing instance and another
routing instance.
STOP Tell your instructor that you have completed this section. Please do not
rush ahead because this 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 4: Configuring the OSPF LInk Costs
In this lab part, you configure the OSPF link costs.

Step 4.1
Issue the show ospf interface detail command.
lab@mxA-1> show ospf interface detail
Interface State Area DR ID BDR ID Nbrs
ge-1/0/0.1111 BDR 0.0.0.0 192.168.100.1 192.168.20.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 192.168.20.1 0.0.0.0 0
DR addr: 192.168.20.1, Priority: 128
Adj count: 0
Auth type: None
ge-1/0/4.10 BDR 0.0.0.10 192.168.20.2 192.168.20.1 1
Adj count: 1
Auth type: None
Question: Do each of the links in the network have

the same cost?
Answer: All of the GE links should have the same

cost.
Question: If so, what is that cost? Why might this

be?
Answer: The cost of the GE links is 1 because the

RFC requires the cost to be rounded up to the
nearest integer.
Step 4.2
At this point, we will better represent the link bandwidths in the network. Enter
configuration mode and navigate to the [edit protocols ospf] hierarchy.
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 and exit to operational mode.
[edit]

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

commit complete
Step 4.3
Issue the show ospf interface detail command to see if the link costs
changed.
lab@mxA-1> show ospf interface detail
ge-1/0/0.1111 BDR 0.0.0.0 192.168.100.1 192.168.20.1 1
Adj count: 1
Auth type: None
lo0.0 DR 0.0.0.0 192.168.10.1 0.0.0.0 0
DR addr: 192.168.20.1, Priority: 128
Adj count: 0
Auth type: None
ge-1/0/4.10 BDR 0.0.0.10 192.168.20.2 192.168.20.1 1
Adj count: 1
Auth type: None
Question: Did the cost of the links in the network

change? Did you remember to commit your
changes?
Answer: If you used a reference bandwith value of

10g or higher the GE link costs should have
changed.
Question: If so, what are some of the new costs?
Answer: If you used a reference bandwidth value of

10g the GE link costs should be 10.

Step 4.4
Enter configuration mode and navigate to the [edit protocols ospf
area 0] hierarchy. Change the metric on your loopback 0 interface to be 10000.
[edit]
lab@mxA-1# edit protocols ospf area 0
[edit protocols ospf area 0.0.0.0]

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

commit complete
Step 4.5
Enter the show route command to examine the routing table on your student
device at this point.
lab@mxA-1> show route 192.168/16

192.168.20.1/32 *[Direct/0] 3d 00:37:20

> via lo0.0
192.168.20.2/32 *[OSPF/10] 00:12:50, metric 10
> to 10.0.10.2 via ge-1/0/4.10
192.168.21.1/32 *[OSPF/10] 00:01:06, metric 10011
> to 172.22.121.2 via ge-1/0/0.1111
192.168.21.2/32 *[OSPF/10] 00:12:50, metric 12
> to 172.22.121.2 via ge-1/0/0.1111
192.168.100.1/32 *[OSPF/10] 00:12:50, metric 10
> to 172.22.121.2 via ge-1/0/0.1111

192.168.20.1/32 *[OSPF/10] 00:04:53, metric 10001

> to 10.0.10.1 via ge-1/1/4.10
192.168.20.2/32 *[Direct/0] 3d 00:37:20
> via lo0.1
192.168.21.1/32 *[OSPF/10] 00:01:06, metric 10012
> to 10.0.10.1 via ge-1/1/4.10
192.168.21.2/32 *[OSPF/10] 00:12:50, metric 13
> to 10.0.10.1 via ge-1/1/4.10
192.168.100.1/32 *[OSPF/10] 00:12:50, metric 11
> to 10.0.10.1 via ge-1/1/4.10

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 address.
Note
If no metric values have changed on your
router, then STOP here until some networks
have changed. If, however, some networks
in your routing table do have increased
metrics, then proceed to Step 4.6.
Step 4.6
Select the GE link that connects the student device with its routing instance. Enter
configuration mode and navigate to the [edit protocols ospf area
area-id] hierarchy. Alter the metrics on both sides of the link. The student device
router should use a metric of 5000, and the routing-instance router should use a
metric of 2500. Commit your configuration and exit to operational mode.
[edit]
lab@mxA-1# edit protocols ospf area y0

lab@mxA-1# set interface ge-1/0/4.xy metric 5000

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

[edit routing-instances R3-1 protocols ospf area 0.0.0.10]

lab@mxA-1# set interface ge-1/1/4.xy metric 2500

commit complete
Step 4.7
Examine the routing tables on each router. Specifically, use the show route
192.168/16 command to look at the cost to reach the loopback address of the
router on the other end of the link.


192.168.20.1/32 *[Direct/0] 3d 00:56:36

> via lo0.0
192.168.20.2/32 *[OSPF/10] 00:07:18, metric 5000
> to 10.0.10.2 via ge-1/0/4.10
192.168.21.1/32 *[OSPF/10] 00:20:22, metric 10011
> to 172.22.121.2 via ge-1/0/0.1111
192.168.21.2/32 *[OSPF/10] 00:03:40, metric 5011
> to 172.22.121.2 via ge-1/0/0.1111
192.168.100.1/32 *[OSPF/10] 00:32:06, metric 10
> to 172.22.121.2 via ge-1/0/0.1111

192.168.20.1/32 *[OSPF/10] 00:07:18, metric 12500

> to 10.0.10.1 via ge-1/1/4.10
192.168.20.2/32 *[Direct/0] 3d 00:56:36
> via lo0.1
192.168.21.1/32 *[OSPF/10] 00:07:18, metric 12511
> to 10.0.10.1 via ge-1/1/4.10
192.168.21.2/32 *[OSPF/10] 00:03:40, metric 7511
> to 10.0.10.1 via ge-1/1/4.10
192.168.100.1/32 *[OSPF/10] 00:07:18, metric 2510
> to 10.0.10.1 via ge-1/1/4.10
Question: Did the two routers agree to use a metric

of 2500 or 5000?
Answer: No. The routers did not agree on a single

metric.
Question: Did the two routers agree to use separate

metrics?
Answer: Yes.
Part 5: Configuring Overload
In this lab part, you configure the routing-instance router to be in overload mode.
Step 5.1
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> show route table R3-x.inet.0

10.0.10.0/24 *[Direct/0] 03:13:40

> via ge-1/1/4.10
10.0.10.2/32 *[Local/0] 03:13:40
10.0.14.0/24 *[OSPF/10] 00:07:33, metric 7511
> to 10.0.10.1 via ge-1/1/4.10
20.20.0.0/24 *[OSPF/150] 00:36:16, metric 0, tag 0
> to 10.0.10.1 via ge-1/1/4.10
20.20.1.0/24 *[OSPF/150] 00:36:16, metric 0, tag 0
> to 10.0.10.1 via ge-1/1/4.10
20.20.2.0/24 *[OSPF/150] 00:36:16, metric 0, tag 0
> to 10.0.10.1 via ge-1/1/4.10
20.20.3.0/24 *[OSPF/150] 00:36:16, metric 0, tag 0
> to 10.0.10.1 via ge-1/1/4.10
20.20.4.0/24 *[OSPF/150] 00:36:01, metric 0, tag 0
> to 10.0.10.1 via ge-1/1/4.10
20.20.5.0/24 *[OSPF/150] 00:36:01, metric 0, tag 0
> to 10.0.10.1 via ge-1/1/4.10
20.20.6.0/24 *[OSPF/150] 00:36:01, metric 0, tag 0
> to 10.0.10.1 via ge-1/1/4.10
20.20.7.0/24 *[OSPF/150] 00:36:01, metric 0, tag 0
> to 10.0.10.1 via ge-1/1/4.10
172.22.121.0/24 *[OSPF/10] 00:14:33, metric 2510
> to 10.0.10.1 via ge-1/1/4.10
172.22.122.0/24 *[OSPF/10] 00:14:33, metric 2511
> to 10.0.10.1 via ge-1/1/4.10
192.168.20.1/32 *[OSPF/10] 00:14:33, metric 12500
> to 10.0.10.1 via ge-1/1/4.10
192.168.20.2/32 *[Direct/0] 03:13:40
> via lo0.1
192.168.21.1/32 *[OSPF/10] 00:14:33, metric 12511
> to 10.0.10.1 via ge-1/1/4.10
192.168.21.2/32 *[OSPF/10] 00:07:33, metric 7511
> to 10.0.10.1 via ge-1/1/4.10
192.168.100.1/32 *[OSPF/10] 00:14:33, metric 2510
> to 10.0.10.1 via ge-1/1/4.10
224.0.0.5/32 *[OSPF/10] 03:13:41, metric 1
MultiRecv
Step 5.2
Enter configuration mode and navigate to the [edit routing-instance
instance-name protocols ospf] hierarchy and configure the
routing-instance router to be in overload mode. Commit your configuration and exit
to operational mode.
[edit]
lab@mxA-1# edit routing-instances R3-x protocols ospf


lab@mxA-1# set overload

commit complete
Step 5.3
Enter the show route table table-name command to examine the
routing-instance route table again.
lab@mxA-1> show route table R3-x.inet.0

10.0.10.0/24 *[Direct/0] 3d 01:21:32

> via ge-1/1/4.10
10.0.10.2/32 *[Local/0] 3d 01:21:32
10.0.24.0/24 *[OSPF/10] 00:02:18, metric 70546
> to 10.0.10.1 via ge-1/1/4.10
172.22.121.0/24 *[OSPF/10] 00:02:18, metric 65545
> to 10.0.10.1 via ge-1/1/4.10
172.22.122.0/24 *[OSPF/10] 00:02:18, metric 65546
> to 10.0.10.1 via ge-1/1/4.10
192.168.20.1/32 *[OSPF/10] 00:02:18, metric 75535
> to 10.0.10.1 via ge-1/1/4.10
192.168.20.2/32 *[Direct/0] 3d 01:21:32
> via lo0.1
192.168.21.1/32 *[OSPF/10] 00:02:18, metric 75546
> to 10.0.10.1 via ge-1/1/4.10
192.168.21.2/32 *[OSPF/10] 00:02:18, metric 70546
> to 10.0.10.1 via ge-1/1/4.10
192.168.100.1/32 *[OSPF/10] 00:02:18, metric 65545
> to 10.0.10.1 via ge-1/1/4.10
224.0.0.5/32 *[OSPF/10] 01:15:02, metric 1
MultiRecv
Question: Did the metrics change?
Answer: Yes. The metric should be greater than

65535 plus the link cost.
Part 6: Performing Authentication
In this lab part, you perform authentication for the OSPF area between the student
device and routing-instance router.

Step 6.1
Enter configuration mode and navigate to the [edit protocols ospf area
area-id] hierarchy. Configure your student device router and routing-instance
router to support an authentication key of juniper using the Message Digest 5
(MD5) algorithm. Commit your configuration and exit to operational mode.
[edit]

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

Step 6.2
Issue the show ospf statistics command. Notice the Receive errors
counter. The authentication mismatch is showing as area mismatches.
lab@mxA-1> show ospf statistics
Packet type Total Last 5 seconds

Sent Received Sent Received
Hello 0 0 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:
6 area mismatches
lab@mxA-1# top edit routing-instances R3-y


lab@mxA-1# set interface ge-1/1/4.xy authentication md5 10 key juniper


commit complete
Step 6.3
Issue the show ospf neighbor command to verify that the neighbor
adjacencies are still Full.
172.22.121.2 ge-1/0/0.1111 Full 192.168.100.1 128 34
10.0.10.2 ge-1/0/4.10 Full 192.168.20.2 128 34
Question: Are all OSPF neighbors still fully

adjacent?
Answer: Yes. Configuring a router as overloaded

does not change the adjacency.
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.
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 configure and monitor OSPF areas and route summarization to convert
some of the areas in the OSPF routing domain into OSPF stub areas, after which you will
convert them into stub no-summaries areas. You will then 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
10.a.10.3R1.9
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
hierarchy. Configure the area connected to the routing-instance to be a stub area.
Navigate to the [edit routing-instance R3-y protocols ospf]
hierarchy. Configure the area to be a stub area. Commit your configuration and exit
[edit]

lab@mxA-1# set area x0 stub


lab@mxA-1# set area x0 stub

commit complete
Step 1.2
Issue the show ospf neighbor command.
172.22.121.2 ge-1/0/0.1111 Full 192.168.100.1 128 30
10.0.10.2 ge-1/0/4.10 Full 192.168.20.2 128 38
Question: Are all the OSPF neighbors fully adjacent?
Answer: All the neighbors should be adjacent.
Step 1.3
Issue the show route table R3-y 20.20/16 command followed by the
show route 20.20/16 command.
Lab 2–2 • Configuring and Monitoring OSPF Areas and Route Summarization (Detailed) www.juniper.net
lab@mxA-1> show route table R3-y.inet.0 20.20/16

20.20.0.0/24 *[Static/5] 3w2d 08:49:19

Reject
20.20.1.0/24 *[Static/5] 3w2d 08:49:19
Reject
20.20.2.0/24 *[Static/5] 3w2d 08:49:19
Reject
20.20.3.0/24 *[Static/5] 3w2d 08:49:19
Reject
lab@mxA-1>
Question: Are the customer static routes from each

router visible in the network? Are they visible on the
ABRs?
Answer: The purpose of a stub area is to stop the

ABRs from injecting external routing information
and therefore reduce the size of the link-state
database. The customer routes should still be
visible on the ABRs.
Step 1.4
Issue the show route 192.168/16 command. Attempt to ping the loopback
address of the other routing-instance in your pod using the ping ip-address
count 5 command.

192.168.20.1/32 *[Direct/0] 3w2d 08:53:32

> via lo0.0
192.168.20.2/32 *[OSPF/10] 00:13:19, metric 1
> to 10.0.10.2 via ge-1/0/4.10
192.168.21.1/32 *[OSPF/10] 3w2d 08:51:14, metric 2
> to 172.22.121.2 via ge-1/0/0.1111
192.168.21.2/32 *[OSPF/10] 3w2d 08:51:14, metric 3
> to 172.22.121.2 via ge-1/0/0.1111
192.168.100.1/32 *[OSPF/10] 3w2d 08:51:20, metric 1
> to 172.22.121.2 via ge-1/0/0.1111

192.168.20.1/32 *[OSPF/10] 00:13:19, metric 1
> to 10.0.10.1 via ge-1/1/4.10
192.168.20.2/32 *[Direct/0] 3w2d 08:53:25
> via lo0.1
192.168.21.1/32 *[OSPF/10] 00:13:19, metric 3
> to 10.0.10.1 via ge-1/1/4.10
192.168.21.2/32 *[OSPF/10] 00:13:19, metric 4
> to 10.0.10.1 via ge-1/1/4.10
192.168.100.1/32 *[OSPF/10] 00:13:19, metric 2
> to 10.0.10.1 via ge-1/1/4.10
lab@mxA-1> ping 192.168.2x.2 count 5
PING 192.168.21.2 (192.168.21.2): 56 data bytes
--- 192.168.21.2 ping statistics ---

Question: Are the loopback addresses visible from

each router in the network? Is the ping successful?
Answer: The loopback addresses should be visible

and the ping successful.
Question: How many OSPF routes are in your in your

routing table?
Answer: The answer varies depending on whether

you are looking on an ABR or a router in the stub
area.
Step 1.5
Issue the show ospf database command.

Router *192.168.20.1 192.168.20.1 0x800002e4 1073 0x22 0x144 48
Router 192.168.21.1 192.168.21.1 0x800002e0 224 0x22 0x2222 48
Router 192.168.100.1 192.168.100.1 0x800002e1 319 0x22 0xd6ee 60
Network 172.22.121.2 192.168.100.1 0x800002dc 89 0x22 0x56ab 32
Network 172.22.122.2 192.168.100.1 0x800002db 2425 0x22 0x5aa6 32
Summary *10.0.10.0 192.168.20.1 0x800002e0 1356 0x22 0x3e89 28
Summary 10.0.14.0 192.168.21.1 0x800002dc 2430 0x22 0x13b3 28
Summary *192.168.20.2 192.168.20.1 0x80000001 1356 0x22 0x52eb 28
Summary 192.168.21.2 192.168.21.1 0x800002da 2680 0x22 0x86d9 28
Router *192.168.20.1 192.168.20.1 0x80000004 1356 0x20 0x8385 36
Router 192.168.20.2 192.168.20.2 0x80000003 1357 0x20 0x3d3b 48
Network 10.0.10.2 192.168.20.2 0x80000002 1357 0x20 0xa8fe 32
Summary *10.0.14.0 192.168.20.1 0x80000002 798 0x20 0x89c 28
Summary *172.22.121.0 192.168.20.1 0x80000001 1396 0x20 0xd76 28
Summary *172.22.122.0 192.168.20.1 0x80000002 525 0x20 0xa76 28
Summary *192.168.20.1 192.168.20.1 0x80000001 1396 0x20 0x70d1 28
Summary *192.168.21.1 192.168.20.1 0x80000002 255 0x20 0x77c6 28
Summary *192.168.21.2 192.168.20.1 0x80000001 1396 0x20 0x79c3 28
Summary *192.168.100.1 192.168.20.1 0x80000001 1396 0x20 0x7e9 28
Question: What types of LSAs are in your link-state

database?

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 a Stub No Summaries Area
In this lab part, you convert the stub area to a stub no-summaries area.
Step 2.1
hierarchy. Convert the stub area to a stub no-summaries area with the set area
area-id stub no-summaries command. Commit your configuration and exit
[edit]

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

commit complete
Question: On which routers must you issue the
command?
Answer: The command must be issued only on the

ABR.
Step 2.2
Issue the following commands to answer the next questions:
1. show ospf neighbor
2. show route
3. ping 192.168.2x.1 count 5 and ping 192.168.2x.2
routing-instance R3-y count 5 where x = 1 or 2.
4. show ospf database
172.22.121.2 ge-1/0/0.1111 Full 192.168.100.1 128 39
10.0.10.2 ge-1/0/4.10 Full 192.168.20.2 128 32

10.0.10.0/24 *[Direct/0] 3w2d 09:18:41

> via ge-1/0/4.10
10.0.10.1/32 *[Local/0] 3w2d 09:18:52
10.0.14.0/24 *[OSPF/10] 3w2d 09:17:45, metric 3
> to 172.22.121.2 via ge-1/0/0.1111
10.210.14.0/27 *[Direct/0] 3w2d 09:20:03
> via fxp0.0
10.210.14.1/32 *[Local/0] 3w2d 09:20:03
Local via fxp0.0
20.20.0.0/24 *[Static/5] 3w2d 09:20:03
Reject
20.20.1.0/24 *[Static/5] 3w2d 09:20:03
Reject
20.20.2.0/24 *[Static/5] 3w2d 09:20:03
Reject
20.20.3.0/24 *[Static/5] 3w2d 09:20:03
Reject
172.22.121.0/24 *[Direct/0] 3w2d 09:18:43
> via ge-1/0/0.1111
172.22.121.1/32 *[Local/0] 3w2d 09:18:52
172.22.122.0/24 *[OSPF/10] 3w2d 09:17:51, metric 2
> to 172.22.121.2 via ge-1/0/0.1111
192.168.20.1/32 *[Direct/0] 3w2d 09:20:03
> via lo0.0
192.168.20.2/32 *[OSPF/10] 00:06:27, metric 1
> to 10.0.10.2 via ge-1/0/4.10
192.168.21.1/32 *[OSPF/10] 3w2d 09:17:45, metric 2
> to 172.22.121.2 via ge-1/0/0.1111
192.168.21.2/32 *[OSPF/10] 3w2d 09:17:45, metric 3
> to 172.22.121.2 via ge-1/0/0.1111
192.168.100.1/32 *[OSPF/10] 3w2d 09:17:51, metric 1
> to 172.22.121.2 via ge-1/0/0.1111
224.0.0.5/32 *[OSPF/10] 3w2d 09:20:04, metric 1
MultiRecv

10.0.10.0/24 *[Direct/0] 3w2d 09:18:41

> via ge-1/1/4.10
10.0.10.2/32 *[Local/0] 3w2d 09:18:51
192.168.20.2/32 *[Direct/0] 3w2d 09:19:56
> via lo0.1
224.0.0.5/32 *[OSPF/10] 3w2d 09:20:04, metric 1
MultiRecv
lab@mxA-1> ping 192.168.2x.1 count 5

PING 192.168.21.2 (192.168.21.1): 56 data bytes
--- 192.168.21.2 ping statistics ---

lab@mxA-1> ping 192.168.2x.2 routing-instance R3-1 count 5

PING 192.168.21.2 (192.168.21.2): 56 data bytes
ping: sendto: No route to host
--- 192.168.21.2 ping statistics ---


Router *192.168.20.1 192.168.20.1 0x800002e6 408 0x22 0xfc46 48
Router 192.168.21.1 192.168.21.1 0x800002e0 1273 0x22 0x2222 48
Router 192.168.100.1 192.168.100.1 0x800002e1 1368 0x22 0xd6ee 60
Network 172.22.121.2 192.168.100.1 0x800002dc 1138 0x22 0x56ab 32
Network 172.22.122.2 192.168.100.1 0x800002dc 908 0x22 0x58a7 32
Summary *10.0.10.0 192.168.20.1 0x800002e4 407 0x22 0x368d 28
Summary 10.0.14.0 192.168.21.1 0x800002dd 809 0x22 0x11b4 28
Summary *192.168.20.2 192.168.20.1 0x80000002 402 0x22 0x50ec 28
Summary 192.168.21.2 192.168.21.1 0x800002db 1041 0x22 0x84da 28

Router *192.168.20.1 192.168.20.1 0x80000006 408 0x20 0x7592 36
Router 192.168.20.2 192.168.20.2 0x80000006 369 0x20 0x2d49 48
Network *10.0.10.1 192.168.20.1 0x80000002 408 0x20 0xbcec 32
Question: Are the customer routes from each router

visible in the network? Are they visible on the ABRs?
Answer: The purpose of a stub area is to stop the

ABRs from injecting external routing information
and therefore reduce the size of the link-state
database. The customer routes should still be
visible on the ABRs.

each router in the network? Can you ping the
loopback address of the other routing instance in
your pod from your routing instance? How about the
ABR?
Answer: The ABRs should be able to reach the other

routers but not the stub routers.
Question: How many OSPF routes are in your routing

table?

you are looking on an ABR or a router in the stub
area.
Question: What types of LSAs are in your LSDB?

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 therefore we must
configure it.
Step 2.3
Restore connectivity in the network by allowing the ABR to generate a default route
into the stub areas. Enter configuration mode and navigate to the [edit
protocols ospf] hierarchy. Issue the set area area-id stub
default-metric 10 command. Commit your configuration and exit to
operational mode.
[edit]

lab@mxA-1# set area x0 stub default-metric 10

commit complete
Step 2.4
Attempt to ping the loopback of the other routing-instance in your pod from your
routing-instance using the ping 192.168.2x.2 routing-instance R3-y
count 5 command where x = 1 or 2.
lab@mxA-1> ping 192.168.2x.2 routing-instance R3-y count 5
PING 192.168.21.2 (192.168.21.2): 56 data bytes
--- 192.168.21.2 ping statistics ---

Question: Can you ping the loopback addresses of

the other routers in other areas?
Answer: You should be able to ping them now.
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
Enter configuration mode and navigate first to the [edit protocols ospf]
and then to the [edit routing-instance R3-y protocols ospf]
hierarchies. Use the set area area-id nssa command. Commit your
configuration and exit to operational mode.
[edit]

lab@mxA-1# set area x0 nssa


lab@mxA-1# set area x0 nssa

commit complete
Step 3.2
Issue the following commands to answer the next set of questions:
1. show ospf neighbor
2. show route
3. show ospf database
172.22.121.2 ge-1/0/0.1111 Full 192.168.100.1 128 32
10.0.10.2 ge-1/0/4.10 Full 192.168.20.2 128 30

10.0.10.0/24 *[Direct/0] 3w2d 10:12:39

> via ge-1/0/4.10
10.0.10.1/32 *[Local/0] 3w2d 10:12:50
10.0.14.0/24 *[OSPF/10] 3w2d 10:11:43, metric 3
> to 172.22.121.2 via ge-1/0/0.1111
10.210.14.0/27 *[Direct/0] 3w2d 10:14:01
> via fxp0.0
10.210.14.1/32 *[Local/0] 3w2d 10:14:01
Local via fxp0.0
20.20.0.0/24 *[Static/5] 3w2d 10:14:01
Reject
20.20.1.0/24 *[Static/5] 3w2d 10:14:01
Reject
20.20.2.0/24 *[Static/5] 3w2d 10:14:01
Reject
20.20.3.0/24 *[Static/5] 3w2d 10:14:01
Reject
172.22.121.0/24 *[Direct/0] 3w2d 10:12:41
> via ge-1/0/0.1111
172.22.121.1/32 *[Local/0] 3w2d 10:12:50
172.22.122.0/24 *[OSPF/10] 3w2d 10:11:49, metric 2
> to 172.22.121.2 via ge-1/0/0.1111
192.168.20.1/32 *[Direct/0] 3w2d 10:14:01
> via lo0.0
192.168.20.2/32 *[OSPF/10] 00:07:26, metric 1
> to 10.0.10.2 via ge-1/0/4.10
192.168.21.1/32 *[OSPF/10] 3w2d 10:11:43, metric 2
> to 172.22.121.2 via ge-1/0/0.1111
192.168.21.2/32 *[OSPF/10] 3w2d 10:11:43, metric 3
> to 172.22.121.2 via ge-1/0/0.1111
192.168.100.1/32 *[OSPF/10] 3w2d 10:11:49, metric 1
> to 172.22.121.2 via ge-1/0/0.1111
224.0.0.5/32 *[OSPF/10] 3w2d 10:14:02, metric 1
MultiRecv

10.0.10.0/24 *[Direct/0] 3w2d 10:12:39
> via ge-1/1/4.10
10.0.10.2/32 *[Local/0] 3w2d 10:12:49
10.0.14.0/24 *[OSPF/10] 00:07:26, metric 4
> to 10.0.10.1 via ge-1/1/4.10
172.22.121.0/24 *[OSPF/10] 00:07:26, metric 2
> to 10.0.10.1 via ge-1/1/4.10
172.22.122.0/24 *[OSPF/10] 00:07:26, metric 3
> to 10.0.10.1 via ge-1/1/4.10
192.168.20.1/32 *[OSPF/10] 00:07:26, metric 1
> to 10.0.10.1 via ge-1/1/4.10
192.168.20.2/32 *[Direct/0] 3w2d 10:13:54
> via lo0.1
192.168.21.1/32 *[OSPF/10] 00:07:26, metric 3
> to 10.0.10.1 via ge-1/1/4.10
192.168.21.2/32 *[OSPF/10] 00:07:26, metric 4
> to 10.0.10.1 via ge-1/1/4.10
192.168.100.1/32 *[OSPF/10] 00:07:26, metric 2
> to 10.0.10.1 via ge-1/1/4.10
224.0.0.5/32 *[OSPF/10] 3w2d 10:14:02, metric 1
MultiRecv

Router *192.168.20.1 192.168.20.1 0x800002ea 496 0x22 0xfa42 48
Router 192.168.21.1 192.168.21.1 0x800002e1 1965 0x22 0x2023 48
Router 192.168.100.1 192.168.100.1 0x800002e2 2031 0x22 0xd4ef 60
Network 172.22.121.2 192.168.100.1 0x800002dd 1801 0x22 0x54ac 32
Network 172.22.122.2 192.168.100.1 0x800002dd 1571 0x22 0x56a8 32
Summary *10.0.10.0 192.168.20.1 0x800002e7 455 0x22 0x3090 28
Summary 10.0.14.0 192.168.21.1 0x800002de 1504 0x22 0xfb5 28
Summary *192.168.20.2 192.168.20.1 0x80000001 455 0x22 0x52eb 28
Summary 192.168.21.2 192.168.21.1 0x800002dc 1734 0x22 0x82db 28

Router *192.168.20.1 192.168.20.1 0x80000003 456 0x20 0x8b7c 36
Router 192.168.20.2 192.168.20.2 0x80000003 457 0x20 0x3d3b 48
Network 10.0.10.2 192.168.20.2 0x80000002 457 0x20 0xa8fe 32
Summary *10.0.14.0 192.168.20.1 0x80000001 495 0x20 0xa9b 28
Summary *172.22.121.0 192.168.20.1 0x80000001 495 0x20 0xd76 28
Summary *172.22.122.0 192.168.20.1 0x80000001 495 0x20 0xc75 28
Summary *192.168.20.1 192.168.20.1 0x80000001 495 0x20 0x70d1 28
Summary *192.168.21.1 192.168.20.1 0x80000001 495 0x20 0x79c5 28
Summary *192.168.21.2 192.168.20.1 0x80000001 495 0x20 0x79c3 28
Summary *192.168.100.1 192.168.20.1 0x80000001 495 0x20 0x7e9 28
Question: Are the customer routes from each router
visible in the network? Are they visible on the ABRs?
Why or why not?
Answer: The purpose of a stub/NSSA area is to stop

the ABRs from injecting external routing information
into the stub area. An NSSA does allow external
routes to be injected by an ASBR. The customer
routes should still be visible on the ABRs.

each router in the network?
Answer: The loopback addresses should be visible

in ABRs’ routing tables but not the NSSA routers.
Question: How many OSPF routes are in your routing

table?

you are looking on an ABR or a router in the NSSA.
Question: What types of LSAs are in your LSDB?

you are looking at the ABR or the router in the
NSSA. The NSSA router should not have any Type 3,
Type 4, or Type 5 LSAs.
Step 3.3
You will now restore connectivity in the network by allowing the ABR to generate a
default route into the NSSAs. Enter configuration mode and navigate to the [edit
protocols ospf] hierarchy. Issue the set area area-id nssa
default-lsa default-metric 10 command. Commit your configuration and
exit to operational mode.
[edit]
lab@mxA-1#

lab@router# set area x0 nssa default-lsa default-metric 10

commit complete
Step 3.4
Attempt to ping the loopback of the other routing-instance in your pod from your
routing-instance using the ping 192.168.2x.2 routing-instance R3-y
count 5 command where x = 1 or 2.
lab@mxA-1> ping 192.168.2x.2 routing-instance R3-y count 5
PING 192.168.21.2 (192.168.21.2): 56 data bytes
--- 192.168.21.2 ping statistics ---

Question: Can you now ping the loopback address

of the other routing-instance?
Answer: Yes, you should be able to ping the

loopback addresses.
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
hierarchy. Issue the set area area-id nssa no-summaries command.
Question: On which routers must you issue the

command?
Answer: The command must be issued only on the

ABR.
[edit]

lab@router# set area x0 nssa no-summaries

commit complete
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.
Lab 3
Advanced OSPF Options and Routing Policy (Detailed)
Overview
In this lab, you will be using 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 (LSA).
• 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
10.a.10.3R1.9
Note
The extended IS-IS topology requires you to
display information in the different virtual
routing instances. When referencing the
routing instance, the commands will
include the routing instance name, R3-z,
where z is the user number (1 or 2). Refer
to the lab diagram for the correct instance
and user number.
routing-instance R3-z switch must
be used to consult the appropriate virtual
table R3-z switch must be used to
routing tables.
Part 1: Establishing the OSPF Adjacencies and Creating a Virtual Tunnel
In this lab part, you load the Lab 3 basic 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. A reset file named
ajspr-lab3-reset-mx_.config has been created to help you load the OSPF
topology. The mx_ within the reset file name references the assigned student
device, mxA-1, mxA-2, etc.
Step 1.1
Use the load override command to load the Lab 3 reset file. The reset file is
named ajspr-lab3-reset-mx_.config and is located in the /var/tmp
directory. After loading the file, commit the configuration and return to operational
mode.
lab@mxB-1> configure
[edit]
lab@mxB-1# load override /var/tmp/ajspr-lab3-reset-mx_.config
load complete
[edit]
lab@mxB-1# commit and-quit
commit complete
lab@mxB-1>
Lab 3–2 • Advanced OSPF Options and Routing Policy (Detailed) www.juniper.net
Step 1.2
Use the show configuration command to view the active configuration.
lab@mxB-1> show configuration
## Last changed: 2010-12-09 01:40:03 UTC

version 10.3R1.9;
system {
host-name mxB-1;
ssh-dsa "ssh-dss
SECRET-DATA
}
login {
user lab {
uid 2000;
class super-user;
authentication {
SECRET-DATA
}
}
}
services {
ftp;
ssh;
telnet;
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
}
}
}
chassis {
fpc 1 {
pic 0 {
tunnel-services {
bandwidth 1g;
}
}
}
}
interfaces {
ge-1/0/0 {
vlan-tagging;
unit 1121 {
description “connection to P1”;
vlan-id 1121;
family inet {
address 172.22.121.1/24;
}
}
unit 1123 {
vlan-id 1123;
family inet {
address 172.22.123.1/24;
}
}
unit 1125 {
vlan-id 1125;
family inet {
address 172.22.125.1/24;
}
}
}
ge-1/0/4 {
vlan-tagging;
unit 20 {
description ”connection between mxB-1 and R3-1”;
vlan-id 20;
family inet {
address 10.0.20.1/24;
}
}
}
ge-1/1/4 {
vlan-tagging;
unit 20 {
description “connection between R3-1 and mxB-1”
vlan-id 20;
family inet {
address 10.0.20.2/24;
}
}
}
fxp0 {
unit 0 {
family inet {
address 10.210.15.3/27;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.20.1/32;
}
}
unit 1 {
family inet {
address 192.168.20.2/32;
}
}
}
}
routing-instances {
R3-1 {
interface lo0.1;
protocols {
ospf {
area 0.0.0.10 {
nssa;
interface lo0.1;
}
}
}
}
}
Step 1.3
hierarchy. Establish the OSPF adjacencies with P1, P2, and R3. Configure OSPF
Area 10 as a not-so-stubby area and advertise a default route with a metric of 10.
Commit the configuration and return to operational mode.
[edit]
lab@mxB-1# edit protocols ospf

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

lab@mxB-1# set area 0 interface ge-1/0/0.11xy
lab@mxB-1# set area 10 nssa default-lsa default-metric 10

lab@mxB-1# set area 10 interface ge-1/0/4.xy

lab@mxB-1# set area 20 interface ge-1/0/0.11xy
[edit]
commit complete
lab@mxB-1>
Step 1.4
Use the operational mode command show ospf interface to verify the
establishment of the OSPF adjacencies.
lab@mxB-1> show ospf interface
ge-1/0/0.1121 BDR 0.0.0.0 192.168.100.1 192.168.20.1 1
lo0.0 DR 0.0.0.0 192.168.20.1 0.0.0.0 0
ge-1/0/0.1123 BDR 0.0.0.20 192.168.101.1 192.168.20.1 1
ge-1/0/4.20 BDR 0.0.0.10 192.168.20.2 192.168.20.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.5
Use the operational mode command show ospf neighbor to verify the
establishment of the OSPF adjacencies.
lab@mxB-1> show ospf neighbor
172.22.121.2 ge-1/0/0.1121 Full 192.168.100.1 128 34
172.22.123.2 ge-1/0/0.1123 Full 192.168.101.1 128 37
10.0.20.2 ge-1/0/4.20 Full 192.168.20.2 128 35
lab@mxB-1>
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.6
Verify that the routing table has connectivity to all devices in the OSPF domain. Use
the show route table inet.0 protocol ospf | match /32 command
to display only the host addresses.
lab@mxB-1> show route table inet.0 protocol ospf | match /32
192.168.20.2/32 *[OSPF/10] 00:07:17, metric 1
192.168.21.1/32 *[OSPF/10] 00:01:37, metric 2
192.168.21.2/32 *[OSPF/10] 00:01:32, metric 3
192.168.100.1/32 *[OSPF/10] 01:09:39, metric 1
192.168.101.1/32 *[OSPF/10] 01:09:39, metric 1
192.168.102.1/32 *[OSPF/10] 00:07:17, metric 2
224.0.0.5/32 *[OSPF/10] 01:09:54, metric 1
lab@mxB-1>
Question: Is there an entry in the primary routing

table (inet.0) for all six loopback addresses within
the OSPF domain?
Answer: Yes. If your partner has successfully

configured OSPF, there should be six host
addresses in the inet.0 routing table, one for each
loopback address.
Step 1.7
0] hierarchy. Create a virtual tunnel in OSPF Area 0 through Area 20 using the OSPF
virtual-link command. The virtual-link neighbor-id is the loopback address of
your partner's student device. The virtual tunnel should be used only as a backup in
the event of an P1 failure. This can be accomplished by setting the Area 20 interface
to a high metric. Commit this configuration and return to operational mode.
[edit]
lab@mxB-1# edit protocols ospf area 0
[edit protocols ospf area 0]

lab@mxB-1# set virtual-link transit-area 20 neighbor-id 192.168.xy.1

lab@mxB-1# up

lab@mxB-1# set area 20 interface ge-1/0/0.11xy metric 10

commit complete
lab@mxB-1>
Step 1.8
Verify that the virtual tunnel has been established and that an adjacency has been
formed. Use the show ospf interface command to display the virtual tunnel
interface.
ge-1/0/0.1121 BDR 0.0.0.0 192.168.100.1 192.168.20.1 1
lo0.0 DR 0.0.0.0 192.168.20.1 0.0.0.0 0
vl-192.168.21.1 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-1/0/0.1123 BDR 0.0.0.20 192.168.101.1 192.168.20.1 1
ge-1/0/4.20 BDR 0.0.0.10 192.168.20.2 192.168.20.1 1
Question: What type of interface is created for the

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

virtual tunnel.
Step 1.9
Verify that the virtual tunnel has an adjacency. Use the show ospf neighbor
command to display the state of the virtual tunnel interface.
172.22.121.2 ge-1/0/0.1121 Full 192.168.100.1 128 38
172.22.124.1 vl-192.168.21.1 Full 192.168.21.1 0 32
172.22.123.2 ge-1/0/0.1123 Full 192.168.101.1 128 35
10.0.20.2 ge-1/0/4.20 Full 192.168.20.2 128 37
Question: What is the OSPF state on the virtual
tunnel interface?
Answer: The state should be Full.
Step 1.10
Use the show route table inet.0 192.168.xy.1/32 command to verify
that your partner's default loopback address routes through the P1 router and not
through the virtual link.
lab@mxB-1> show route table inet.0 192.168.xy.1/32

192.168.21.1/32 *[OSPF/10] 00:00:07, metric 2

> to 172.22.121.2 via ge-1/0/0.1121
lab@mxB-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.
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
10] hierarchy. Establish an OSPF Area 10 adjacency through the P1 router as a
secondary interface with a metric of 10. This setting provides a backup path for
Area 10 in the event of a P3 failure. Commit these changes and return to
operational mode.
[edit]
lab@mxB-1# edit protocols ospf area 10
lab@mxB-1# set interface ge-1/0/0.11xy secondary

lab@mxB-1# set interface ge-1/0/0.11xy metric 10

commit complete
lab@mxB-1>
Step 2.2
Verify the establishment of OSPF Area 10 on the interfaces using the show ospf
interface command.
ge-1/0/0.1121 BDR 0.0.0.0 192.168.100.1 192.168.20.1 1
lo0.0 DR 0.0.0.0 192.168.20.1 0.0.0.0 0
vl-192.168.21.1 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-1/0/0.1123 BDR 0.0.0.20 192.168.101.1 192.168.20.1 1
ge-1/0/0.1121 PtToPt 0.0.0.10 0.0.0.0 0.0.0.0 1
ge-1/0/4.20 BDR 0.0.0.10 192.168.20.2 192.168.20.1 1
Question: The interface connected to P1 has two

established states in OSPF. What is the established
state for the interface in Area 0.0.0.10? Why?
Answer: The established interface state for

Area 0.0.0.10 is point-to-point. As outlined in
RFC 5185, all secondary multiarea adjacencies will
be formed using a Pt-To-Pt interface.
Step 2.3
Verify the establishment of an OSPF Area 10 adjacency through P1 by displaying
both using the show ospf neighbor command.
172.22.121.2 ge-1/0/0.1121 Full 192.168.100.1 128 37
Area 0.0.0.0
172.22.124.1 vl-192.168.21.1 Full 192.168.21.1 0 37
Area 0.0.0.0
172.22.123.2 ge-1/0/0.1123 Full 192.168.101.1 128 39
Area 0.0.0.20
172.22.121.2 ge-1/0/0.1121 Full 192.168.100.1 128 37
Area 0.0.0.10
10.0.20.2 ge-1/0/4.20 Full 192.168.20.2 128 37
Area 0.0.0.10
Question: How many OSPF adjacencies are there for
Area 0.0.0.10?
Answer: Two adjacencies have been formed with

OSPF Area 0.0.0.10.
Step 2.4
Verify that the loopback address of your partner's R3 virtual instance is being routed
through the interface to your R3 virtual instance. Use the show route table
inet.0 192.168.xy.2/32 command to display the path of the route.

192.168.21.2/32 *[OSPF/10] 00:52:50, metric 3

> to 10.0.20.2 via ge-1/0/4.20
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 virtual router.
Step 2.5
The remaining steps of Part 2 should be performed only on the mx_-1 router. Enter
configuration mode and disable the default VLAN interface to the R3 routing
instance in OSPF Area 0.0.0.10. Commit the configuration and return to operational
mode.
Note
The following Part 2 steps should be

performed only on the mx_-1 router.
[edit]
lab@mxB-1# set interfaces ge-1/0/4.x0 disable
[edit]
commit complete
lab@mxB-1>
Step 2.6
Verify that the multiarea connectivity for OSPF Area 0.0.0.10 has converged through
the P1 router. Use the show route table inet.0 192.168.xy.2/32
command to display your partner's loopback address.

192.168.21.2/32 *[OSPF/10] 00:00:09, metric 12

> to 172.22.121.2 via ge-1/0/0.1121
Step 2.7
Use the traceroute 192.168.xy.2 command to verify that the traffic is
traversing P1.
lab@mxB-1> traceroute 192.168.21.2
traceroute to 192.168.21.2 (192.168.21.2), 30 hops max, 40 byte packets
1 172.22.121.2 (172.22.121.2) 0.409 ms 0.268 ms 0.247 ms
2 172.22.122.1 (172.22.122.1) 0.333 ms 0.291 ms 0.283 ms
3 192.168.21.2 (192.168.21.2) 0.428 ms 0.373 ms 0.367 ms
Question: Did OSPF converge to the multiarea

configuration?
Answer: Yes. OSPF converged to the backup

multiarea adjacency.
Step 2.8
Enter configuration mode and rollback the configuration to enable the default
OSPF connection for Area 10. Commit the configuration and return to operational
mode.
[edit]
lab@mxB-1# rollback 1
load complete
[edit]
commit complete
Step 2.9
Verify that OSPF converged back to the primary path by displaying your partner's
loopback address using the show route table inet.0 192.168.xy.2/32
and traceroute 192.168.xy.2 commands.

192.168.21.2/32 *[OSPF/10] 00:01:43, metric 3

> to 10.0.20.2 via ge-1/0/4.20
lab@mxB-1> traceroute 192.168.21.2

1 10.0.20.2 (10.0.20.2) 0.423 ms 0.295 ms 0.275 ms
2 172.22.125.2 (172.22.125.2) 0.280 ms 0.275 ms 0.263 ms
3 192.168.21.2 (192.168.21.2) 0.448 ms 0.372 ms 0.363 ms
Question: Did OSPF converge to the back to your

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

router.
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.
Note
In this lab, you configure and display
commands in the virtual routing instance.
commands will include the routing instance
name, R3-z, where z is the user number
(1 or 2). Refer to the lab diagram for the
correct user number.
Step 3.1
Enter configuration mode and navigate to the [edit routing-instances
R3-z] hierarchy. Remove the OSPF Area 10 interface that connects to the P3 router
and configure the interface in protocols RIP. Commit the configuration and return to
operational mode.
[edit]
lab@mxB-1# edit routing-instances R3-z

lab@mxB-1# delete protocols ospf area 10 interface ge-1/0/0.11xy

lab@mxB-1# set protocols rip group P3 neighbor ge-1/0/0.11xy

commit complete
lab@mxB-1>
Step 3.2
Use the show route receive-protocol rip 172.22.1xy.2 table
R3-z command to verify that RIP routes are being received from the P3 router.
lab@mxB-1> show route receive-protocol rip 172.22.1xy.2 table R3-z

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

> to 172.22.125.2 via ge-1/0/0.1125
20.20.0.0/24 *[RIP/100] 00:09:49, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.1.0/24 *[RIP/100] 00:09:49, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.2.0/24 *[RIP/100] 00:09:49, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.3.0/24 *[RIP/100] 00:09:49, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.4.0/25 *[RIP/100] 00:09:49, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.4.128/25 *[RIP/100] 00:09:49, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.5.0/26 *[RIP/100] 00:09:49, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.5.64/26 *[RIP/100] 00:09:49, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.5.128/26 *[RIP/100] 00:09:49, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.5.192/26 *[RIP/100] 00:09:49, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
lab@mxB-1>
Step 3.3
Enter configuration mode and navigate to the [edit policy-options
policy-statement export-default] hierarchy. Create a routing policy to
advertise the default route to the RIP router and configure the policy to redistribute
the OSPF default route.
[edit]
lab@mxB-1# edit policy-options policy-statement export-default
[edit policy-options policy-statement export-default]

lab@mxB-1# set term 1 from protocol ospf

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

lab@mxB-1# set term 1 then accept

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

lab@mxB-1#
Step 3.4
Navigate to the [edit routing-instances R3-z] hierarchy. Apply the policy
as an export policy in protocol RIP group P3. Commit the configuration and return to
operational mode.
[edit]
lab@mxB-1# top edit routing-instances R3-z

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

commit complete
lab@mxB-1>
Step 3.5
Use the show route advertising-protocol rip 172.22.1xy.1
table R3-z command to verify that the route is being advertised to the P3 router.
lab@mxB-1> show route advertising-protocol rip 172.22.1xy.1 table R3-z
lab@mxB-1>
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 it is not an
active OSPF route. The OSPF external preference of
150 is higher then the RIP preference of 100.
Step 3.6
Display the default route in the R3 routing table using the show route 0/0
exact table R3-z command.
lab@mxB-1> show route 0/0 exact table R3-z

0.0.0.0/0 *[RIP/100] 00:02:21, metric 3, tag 0

> to 172.22.125.2 via ge-1/0/0.1125
[OSPF/150] 00:25:42, metric 11, tag 0
> to 10.0.20.1 via ge-1/1/4.20
lab@mxB-1>
Question: What is the active protocol for the default

route?
Answer: The active protocol for the default route is

RIP because the preference is lower than the
external preference of OSPF.
Step 3.7
Enter configuration mode and navigate to the [edit routing instances
R3-z] hierarchy. Set the OSPF external-preference to 90, which is less than
the RIP preference of 100. Commit the changes and return to operational mode.
[edit]

lab@mxB-1# set protocols ospf external-preference 90

commit complete
lab@mxB-1>
Step 3.8
table R3-z command to verify that both routers are advertising the default route
to the RIP router.

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

> to 10.0.20.1 via ge-1/1/4.20
[RIP/100] 00:18:07, metric 3, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
lab@mxB-1>
Question: Is the route now being advertised to the

RIP network?
Answer: Yes. The lower OPSF preference has made

the default route active under OSPF, which matches
the RIP export policy.
Step 3.9
policy-statement import-rip-route] hierarchy. Create a policy to accept
only the summary route 20.20.0.0/21 from the RIP router.
[edit]
lab@mxB-1# edit policy-options policy-statement import-rip-route
[edit policy-options policy-statement import-rip-route]
lab@mxB-1# set term 1 from protocol rip

lab@mxB-1# set term 1 from route-filter 20.20.0.0/21 exact



lab@mxB-1# set term 2 from route-filter 20.20.0.0/21 longer

lab@mxB-1# set term 2 then reject

lab@mxB-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@mxB-1#
Step 3.10
Navigate to the [edit routing instances R3-z] hierarchy and apply the
policy as an import policy under protocols RIP group P3. Commit the configuration
and return to operational mode.
lab@mxB-1# top edit routing-instances R3-Z

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

commit complete
lab@mxB-1>
Step 3.11
Display the routes being received from the RIP route using the show route
receive-protocol rip 172.22.1xy.2 table R3-z command. Verify
that only the summary route is now being received from the P3 RIP router.
lab@mxB-1> show route receive-protocol rip 172.22.1xy.2 table R3-z

20.20.0.0/21 *[RIP/100] 00:13:26, metric 2, tag 0

> to 172.22.125.2 via ge-1/0/0.1125
lab@mxB-1>
Question: Is the RIP import policy working?
Answer: Because only the summary route is being

received from the RIP neighbor, it appears that the
import policy is working.
Step 3.12
policy-statement export-rip-route] hierarchy. Create a routing policy to
redistribute the RIP summary route into OSPF.
[edit]
lab@mxB-1# edit policy-options policy-statement export-rip-route
[edit policy-options policy-statement export-rip-route]



lab@mxB-1# show
term 1 {
from protocol rip;
then accept;
}
lab@mxB-1#
Step 3.13
Navigate to the [edit routing-instances R3-z] hierarchy. Before applying
the policy as an OSPF export policy, protect the network from unnecessary routes by
configuring a prefix-export-limit of 1 within protocols OSPF. Commit the configuration

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

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

commit complete
lab@mxB-1>
Step 3.14
Verify connectivity to the RIP network by performing a trace to the RIP router using
the redistributed RIP summary route. Enter the traceroute 20.20.1.1
routing-instance R3-z command to verify connectivity.
lab@mxB-1> traceroute 20.20.1.1 routing-instance R3-z
1 10.0.20.1 (10.0.20.1) 0.448 ms 0.294 ms 0.280 ms
2 172.22.121.2 (172.22.121.2) 0.284 ms 0.271 ms 0.281 ms
3 172.22.122.1 (172.22.122.1) 0.340 ms 0.307 ms 0.298 ms
4 10.0.21.2 (10.0.21.2) 0.311 ms 0.350 ms 0.313 ms
5 20.20.1.1 (20.20.1.1) 0.479 ms 0.460 ms 0.451 ms
lab@mxB-1>
Question: What would be causing the sub-optimal

path to the RIP network?
Answer: The OSPF external preference has been

changed to something lower then the RIP
preference. The OSPF route learned through the
Type 7 NSSA LSA will be preferred over the RIP
route.
Step 3.15
policy-statement ospf-import] hierarchy. The sub-optimal routing
between OSPF and RIP is being caused by the routing preference that was modified
in a previous step. Create an OSPF import policy to block the RIP summary route
from being installed in the routing table from OSPF.
[edit]
lab@mxB-1# edit policy-options policy-statement ospf-import
[edit policy-options policy-statement ospf-import]

lab@mxB-1# set term 1 from route-filter 20.20.0.0/21 orlonger


lab@mxB-1# show
term 1 {
from {
route-filter 20.20.0.0/21 orlonger;
}
then reject;
}
lab@mxB-1#
Step 3.16
Navigate to the [edit routing instance R3-z] hierarchy and apply the
OSPF import policy. Commit the changes and return to operational mode.

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

commit complete
lab@mxB-1>
Step 3.17
Verify that the OSPF import policy is working and that optimal routing is being
preformed to the RIP network by running the traceroute 20.20.1.1
routing-instance R3-z command.
lab@mxB-1> traceroute 20.20.1.1 routing-instance R3-z
1 20.20.1.1 (20.20.1.1) 0.593 ms 0.444 ms 0.422 ms
lab@mxB-1>
Question: Is the OSPF import policy working?
Answer: Yes. The OSPF import policy is providing an

optimal path to the RIP network.
Step 3.18
Examine the OSPF Type 7 to Type 5 conversion between the OSPF NSSA area and
the OSPF backbone area. Use the show ospf database area 10 nssa
detail command to display the Type 7 LSAs and the show ospf database
external detail to display the Type 5 LSA.
lab@mxB-1> show ospf database area 10 nssa detail

NSSA *0.0.0.0 192.168.20.1 0x80000003 2271 0x20 0x4167 36
mask 0.0.0.0
Type: 1, Metric: 10, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
NSSA 0.0.0.0 192.168.21.1 0x80000003 2259 0x20 0x3a6d 36
mask 0.0.0.0
NSSA 20.20.0.0 192.168.21.2 0x80000001 1585 0x28 0x384e 36
mask 255.255.248.0
lab@mxB-1> show ospf database external detail

OSPF AS SCOPE link state database
Extern 20.20.0.0 192.168.100.1 0x80000002 1975 0x22 0x87b7 36
mask 255.255.248.0
lab@mxB-1>
Question: Which ABR created the Type 5 external
LSA? Why?
Answer: The P1 router created the Type 5 LSA. The

P1 router has the highest RID between the three
ABRs connected to OSPF NSSA Area 10.
Step 3.19
R3-z] hierarchy. Verify that the prefix-export-limit option is working by
deactivating the RIP import policy. Deactivate the RIP import policy and commit the
change. Return to operational mode.
[edit]

lab@mxB-1# deactivate protocols rip group P3 import

commit complete
lab@mxB-1>
Step 3.20
Display the OSPF Type 7 NSSA LSAs in the Area 10 database using the show ospf
database nssa area 10 command.
lab@mxB-1> show ospf database nssa area 10

NSSA *0.0.0.0 192.168.20.1 0x80000004 829 0x20 0x3f68 36
NSSA 0.0.0.0 192.168.21.1 0x80000004 815 0x20 0x386e 36
lab@mxB-1>
Question: Are the RIP routes being redistributed into
OSPF?
Answer: No. The OSPF external prefix-limit has been

excepted and therefore all external routes are being
rejected into the OSPF database.
Lab 4
IS-IS Configuration and Monitoring (Detailed)
Overview
In this lab, you will be using 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
routing instance, the commands include
the routing instance name, R3-z, where y
is the instance number and z is the user
number (1 or 2). Refer to the lab diagram
for the correct instance and user number.
be use to consult the appropriate virtual
commands, the instance R3-z or table
R3-z switch must be used to display the
appropriate adjacencies or routing tables.
www.juniper.net IS-IS Configuration and Monitoring (Detailed) • Lab 4–1

10.a.10.3R1.9
Part 1: Configuring the Transit Interfaces to Support ISO Packets
In this lab part, you 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
Ensure that you know what device you are assigned. Check with your instructor if
necessary. Change all the x values on the Lab 4 lab diagram to reflect the correct
value. This step helps avoid any confusion during the configuration steps throughout
the lab.
Step 1.2
Access the CLI at your station using either the console, Telnet, or Secure Shell (SSH)
as directed by your instructor.
Step 1.3
mxA-1 (ttyp0)
login: lab
Password:
---JUNOS 10.3R1.9 built 2010-08-13 12:48:29 UTC

lab@mxA-1>
Step 1.4
Enter configuration mode and 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@mxB-1# edit groups ISO
[edit groups ISO]

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

lab@mxB-1#
Step 1.5
Navigate to the [edit interfaces] hierarchy and apply the group to all
interfaces and commit the configuration.
[edit groups ISO]
lab@mxB-1# top
Lab 4–2 • IS-IS Configuration and Monitoring (Detailed) www.juniper.net

[edit]
lab@mxB-1# edit interfaces
[edit interfaces]
lab@mxB-1# set apply-groups ISO
[edit interfaces]
lab@mxB-1# commit
commit complete
[edit interfaces]
lab@mxB-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@mxB-1# show | display inheritance
ge-1/0/0 {
vlan-tagging;
unit 1121 {
vlan-id 1121;
family inet {
address 172.22.121.1/24;
}
##
## 'iso' was inherited from group 'ISO'
##
family iso;
}
unit 1123 {
vlan-id 1123;
family inet {
address 172.22.123.1/24;
}
##
##
family iso;
}
unit 1125 {
vlan-id 1125;
family inet {
address 172.22.125.1/24;
}
##
##
family iso;
}
}
ge-1/0/4 {
vlan-tagging;
unit 20 {

vlan-id 20;
family inet {
address 10.0.20.1/24;
}
##
##
family iso;
}
}
ge-1/1/4 {
vlan-tagging;
unit 20 {
vlan-id 20;
family inet {
address 10.0.20.2/24;
}
##
##
family iso;
}
}
fxp0 {
unit 0 {
family inet {
address 10.210.15.3/27;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.20.1/32;
}
}
unit 1 {
family inet {
address 192.168.20.2/32;
}
}
}
[edit interfaces]
lab@mxB-1#
Question: Did the permanent interfaces fxp0 and

lo0 inherit the family iso command?
Answer: No, the group ISO interface command used

the <*-*> wildcard parameter which only matches
on transit interfaces.

Step 1.7
The family iso configuration can also be verified by using an operational mode
command. Exit to operational mode and use the show interface terse
command.
[edit interfaces]
lab@mxB-1# exit configuration-mode
lab@mxB-1> 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.1121 up up inet 172.22.121.1/24
iso
multiservice
ge-1/0/0.1123 up up inet 172.22.123.1/24
iso
multiservice
ge-1/0/0.1125 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.20 up up inet 10.0.20.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 down
ge-1/1/1 up down
ge-1/1/2 up down
ge-1/1/3 up down

ge-1/1/4 up up
ge-1/1/4.20 up up inet 10.0.20.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.3/27
gre up up
ipip up up
irb up up
lo0 up up
lo0.0 up up inet 192.168.20.1 --> 0/0
lo0.1 up up inet 192.168.20.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
lab@mxB-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
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 locate the correct
NET address for your student device.
Router Interface Network Entity Title

mx_-1 lo0.0 49.0001.1921.680x.0001.00
R3-1 lo0.1 49.0001.1921.680x.0002.00
mx_-2 lo0.0 49.0002.1921.680x.0001.00
R3-2 lo0.1 49.0002.1921.680x.0002.00
Step 2.1
Enter configuration mode and 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. Commit the configuration
[edit]
lab@mxB-1# edit interfaces lo0
[edit interfaces lo0]

lab@mxB-1# set unit 0 family iso address 49.000y.1921.680x.0001.00

lab@mxB-1# set unit 1 family iso address 49.000y.1921.680x.0002.00

commit complete
lab@mxB-1>
Step 2.2
Use the show interfaces lo0 terse command to verify that the loopback
interfaces have the correct IS-IS NET address configured.

lab@mxB-1> show interfaces lo0 terse
Interface Admin Link Proto Local Remote
lo0 up up
lo0.0 up up inet 192.168.20.1 --> 0/0
iso 49.0001.1921.6802.0001
lo0.1 up up inet 192.168.20.2 --> 0/0
iso 49.0001.1921.6802.0002
lo0.16384 up up inet 127.0.0.1 --> 0/0
lo0.16385 up up inet
lab@mxB-1>
Question: What is the IS-IS area configured on the

loopback interfaces?
Answer: The IS-IS area is 49.0001. Reading the NET

address from right to left, the Net-Selector is 00,
Sys-ID is 1921.6902.0001, and the area 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.
Note
In this lab, you configure and display commands in
the virtual routing instance. When referencing the
routing instance, the commands include the routing
instance name, R3-z, where z is the user number
(1 or 2). Refer to the lab diagram for the correct user
number.
Step 3.1
Enter configuration mode and navigate to the [edit protocols isis]
hierarchy. In the default routing instance configure three interfaces: the loopback
interface (lo0.0), the vr-device interface (ge-1/0/0.11xy) and the R3 routing
instance interface (ge-1/0/4.xy).
[edit]
lab@mxB-1# edit protocols isis
[edit protocols isis]

lab@mxB-1# set interface lo0.0

lab@mxB-1# set interface ge-1/0/0.11xy


lab@mxB-1# set interface ge-1/0/4.xy

lab@mxB-1#
Step 3.2
Navigate to the [edit routing-instance R3-z protocols isis]
hierarchy and configure the loopback interface (lo0.1), and the interface to the
default routing instance (ge-1/1/4.xy). Commit the configuration and return to
operational mode.
lab@mxB-1# top edit routing-instances R3-z protocols isis
[edit routing-instances R3-1 protocols isis]

lab@mxB-1# set interface lo0.1

lab@mxB-1# set interface ge-1/1/4.xy

commit complete
lab@mxB-1>
Step 3.3
Use the show isis interface command to verify that the IS-IS operation is
active on the interfaces.
lab@mxB-1> show isis interface
IS-IS interface database:
Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric
ge-1/0/0.1121 3 0x2 mxB-1.00 mxB-1.02 10/10
ge-1/0/4.20 3 0x1 1921.6802.0002.02 1921.6802.0002.02 10/10
lo0.0 0 0x1 Passive Passive 0/0
lab@mxB-1>
Question: What IS-IS levels are configured on the

two interfaces, ge-1/0/0.11xy and
ge-1/0/4.xy?
Answer: Both Level 1 and Level 2 are configured on

these interfaces.

Step 3.4
Use the show isis adjacency command to verify that the IS-IS operation in the
default routing instance.
lab@mxB-1> show isis adjacency
Interface System L State Hold (secs) SNPA
ge-1/0/0.1121 vr-device 2 Up 23 50:c5:8d:87:8b:3a
ge-1/0/4.20 1921.6802.0002 1 Up 6 80:71:1f:c3:7:7c
ge-1/0/4.20 1921.6802.0002 2 Up 7 80:71:1f:c3:7:7c
lab@mxB-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.1121 interface has only one

adjacency, while the ge-1/0/4.20 interface has two
adjacencies. A Level 1 adjacency cannot be formed
between the student device and the vr-device
because they are not in the same IS-IS area.
Step 3.5
Enter configuration mode and navigate to the [edit protocol isis]
hierarchy. Disable level 1 on the interface between the default routing instance
and the vr-device (ge-1/0/0.11xy) and the interface between the two routing
instances (ge-1/0/4.xy).
[edit]

lab@mxB-1# set interface ge-1/0/0.11xy level 1 disable

lab@mxB-1# set interface ge-1/0/4.xy level 1 disable

lab@mxB-1#
Step 3.6
Navigate to the [edit routing-instance R3-Z protocols isis]
hierarchy and disable Level 1 on the interface between the two routing instances
(ge-1/1/4.XY). Commit the configuration and return to operational mode.


lab@mxB-1# set interface ge-1/1/4.xy level 1 disable

commit complete
lab@mxB-1>
Step 3.7
Using the show isis interface and show isis adjacency commands in
the default routing instance to verify that only one adjacency has been formed
between the student device and the vr-device and between the routing instances.
ge-1/0/0.1121 2 0x2 Disabled mxB-1.02 10/10
ge-1/0/4.20 2 0x1 Disabled 1921.6802.0002.02 10/10

ge-1/0/4.20 1921.6802.0002 2 Up 8 80:71:1f:c3:7:7c
lab@mxB-1>
Question: Is Level 1 disabled on the interfaces

between the student device and the vr-device and
between the two routing instances?
Answer: Yes. The IS-IS interface command shows

Level 1 DR disabled on both ge-1/0/0.1121 and
ge-1/0/4.20. Also there is a single Level 2
adjacency between the vr-device 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 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 show route 192.168.0.0/16 command verify that the internal
routes are using OSPF as the preferred routing protocol in the default routing
instance (inet.0).
lab@mxB-1> show route 192.168/16 table inet.0

192.168.20.1/32 *[Direct/0] 3w3d 18:28:03

> via lo0.0
192.168.20.2/32 *[OSPF/10] 3w2d 22:03:20, metric 1
> to 10.0.20.2 via ge-1/0/4.20
[IS-IS/15] 00:51:19, metric 10
> to 10.0.20.2 via ge-1/0/4.20
192.168.21.1/32 *[OSPF/10] 3w3d 00:12:24, metric 2
> to 172.22.121.2 via ge-1/0/0.1121
[IS-IS/18] 00:50:30, metric 20
> to 172.22.121.2 via ge-1/0/0.1121
192.168.21.2/32 *[OSPF/10] 3w2d 22:02:41, metric 12
> to 172.22.121.2 via ge-1/0/0.1121
[IS-IS/18] 00:50:30, metric 30
> to 172.22.121.2 via ge-1/0/0.1121
192.168.100.1/32 *[OSPF/10] 3w3d 01:44:26, metric 1
> to 172.22.121.2 via ge-1/0/0.1121
[IS-IS/18] 00:02:04, metric 10
> to 172.22.121.2 via ge-1/0/0.1121
192.168.101.1/32 *[OSPF/10] 3w3d 00:12:24, metric 10
> to 172.22.123.2 via ge-1/0/0.1123
lab@mxB-1>
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
depends on the level. IS-IS Level 1 preference is 15
and IS-IS Level 2 preference is 18.
Step 4.2
Enter configuration mode and and navigate to the [ edit protocol ospf ]
hierarchy. Change the OSPF internal preference to 20 which is higher than both
the IS-IS level 1 and level 2 preference. Commit the changes and return to
operational mode.

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

lab@mxB-1# set preference 20

commit complete
lab@mxB-1>
Step 4.3
Using the show route 192.168.0.0/16 command again to verify that the
routes in the default routing instance now prefer protocol IS-IS over OSPF.

192.168.20.1/32 *[Direct/0] 3w3d 18:35:12

> via lo0.0
192.168.20.2/32 *[IS-IS/15] 00:58:28, metric 10
> to 10.0.20.2 via ge-1/0/4.20
[OSPF/20] 00:00:21, metric 1
> to 10.0.20.2 via ge-1/0/4.20
192.168.21.1/32 *[IS-IS/18] 00:57:39, metric 20
> to 172.22.121.2 via ge-1/0/0.1121
[OSPF/20] 00:00:21, metric 2
> to 172.22.121.2 via ge-1/0/0.1121
192.168.21.2/32 *[IS-IS/18] 00:57:39, metric 30
> to 172.22.121.2 via ge-1/0/0.1121
[OSPF/20] 00:00:21, metric 12
> to 172.22.121.2 via ge-1/0/0.1121
192.168.100.1/32 *[IS-IS/18] 00:09:13, metric 10
> to 172.22.121.2 via ge-1/0/0.1121
[OSPF/20] 00:00:21, metric 1
> to 172.22.121.2 via ge-1/0/0.1121
192.168.101.1/32 *[OSPF/20] 00:00:21, metric 10
> to 172.22.123.2 via ge-1/0/0.1123
lab@mxB-1>
Question: Are the routes in inet.0 active IS-IS

routes?
Answer: Yes. The IS-IS Level 2 routing preference is

less than the OSPF preference.

Step 4.4
Enter configuration mode and delete protocols ospf from both routing
instances. Commit the changes and return to operational mode.
[edit]
lab@mxB-1# delete protocols ospf
[edit]
lab@mxB-1# delete routing-instances R3-z protocols ospf
[edit]
commit complete
lab@mxB-1>
Step 4.5
Using the show route 192.168.0.0/16 command, verify that only IS-IS routes
are present in the default routing table.

192.168.20.1/32 *[Direct/0] 3w3d 18:40:52

> via lo0.0
192.168.20.2/32 *[IS-IS/15] 01:04:08, metric 10
> to 10.0.20.2 via ge-1/0/4.20
192.168.21.1/32 *[IS-IS/18] 01:03:19, metric 20
> to 172.22.121.2 via ge-1/0/0.1121
192.168.21.2/32 *[IS-IS/18] 01:03:19, metric 30
> to 172.22.121.2 via ge-1/0/0.1121
192.168.100.1/32 *[IS-IS/18] 00:14:53, metric 10
> to 172.22.121.2 via ge-1/0/0.1121
lab@mxB-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 and the SPF tree
database. The IS-IS link state database (LSDB) is input to the shortest-path-first
(SPF) algorithm. This 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 link state database.
lab@mxB-1> show isis database
IS-IS level 1 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
mxB-1.00-00 0x3 0x90a9 1198 L1 L2 Attached
1 LSPs

mxB-1.00-00 0x7 0xcaac 1192 L1 L2
mxB-1.02-00 0x3 0x2d2a 1192 L1 L2
1921.6802.0002.00-00 0x5 0xfa3e 888 L1 L2
1921.6802.0002.02-00 0x1 0xb9b8 888 L1 L2
1921.6802.1001.00-00 0x6 0x4ef4 749 L1 L2
1921.6802.1001.02-00 0x3 0x7fa7 749 L1 L2
mxB-2.00-00 0x5 0x2dd6 747 L1 L2
mxB-2.02-00 0x1 0x50d1 747 L1 L2
vr-device.00-00 0x19f 0x1df7 604 L1 L2
9 LSPs
lab@mxB-1>
Question: The mxB-1.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 mxB-1 and two mxB-2
LSPs?
Answer: In both cases, the mxB-1.00 and mxB-2.00

are the default LSPs advertising the local topology,
while the mxB-1.02 and mxB-2.02 are the
Designated Intermediate System 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 mx_-1.00 extensive command
to display the IS-IS header and the type/length/value (TLV) entries for the default
routing instance LSP.
lab@mxB-1> show isis database level 2 mx_-1.00 extensive
mxB-1.00-00 Sequence: 0x7, Checksum: 0xcaac, Lifetime: 1075 secs

IS neighbor: mxB-1.02 Metric: 10
Two-way fragment: mxB-1.02-00, Two-way first fragment: mxB-1.02-00
IS neighbor: 1921.6802.0002.02 Metric: 10
Two-way fragment: 1921.6802.0002.02-00, Two-way first fragment:
1921.6802.0002.02-00
IP prefix: 10.0.20.0/24 Metric: 10 Internal Up
Header: LSP ID: mxB-1.00-00, Length: 202 bytes

Allocated length: 1492 bytes, Router ID: 192.168.20.1
Remaining lifetime: 1075 secs, Level: 2, Interface: -1610691544
Estimated free bytes: 1237, Actual free bytes: 1290
Aging timer expires in: 1075 secs
Protocols: IP, IPv6
Packet: LSP ID: mxB-1.00-00, Length: 202 bytes, Lifetime : 1198 secs
Checksum: 0xcaac, Sequence: 0x7, 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: 192.168.20.1
IP address: 192.168.20.1
Hostname: mxB-1

IS neighbor: mxB-1.02, Internal, Metric: default 10
IS neighbor: 1921.6802.0002.02, Internal, Metric: default 10
IS extended neighbor: mxB-1.02, Metric: default 10
IP address: 172.22.121.1
Local interface index: 88, Remote interface index: 0
IS extended neighbor: 1921.6802.0002.02, Metric: default 10
IP address: 10.0.20.1
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@mxB-1>
Question: What protocols are supported in this

LSP?
Answer: Both IP and IPV6 are supported in the

mxB-1.00 LSP in level 2.
Question: The IP prefix 192.168.20.1/32 is being

advertised in what two TLVs?
Answer: The IP prefix: 192.168.20.1/32 is TLV 128

and the IP extended prefix: 192.168.20.1/32 is TLV
135.
Step 5.3
Use the show isis route command to display the SPF tree database.
lab@mxB-1> show isis route
IS-IS routing table Current version: L1: 8 L2: 12
IPv4/IPv6 Routes
----------------
Prefix L Version Metric Type Interface NH Via
10.0.21.0/24 2 12 30 int ge-1/0/0.1121 IPV4 vr-device
192.168.20.2/32 2 12 10 int ge-1/0/4.20 IPV4 1921.6802.0002
lab@mxB-1>

Question: The IS-IS tree table shows the output of
the SPF algorithm. Examine the entry for prefix
192.168.20.2/32. Which database installed the
route and from which LSP?
Answer: The 192.168.20.2/32 entry was installed

from LSP 1921.6802.0002 in the Level 2 database.

Lab 5
Advanced IS-IS Configuration and Routing Policy (Detailed)
Overview
In this lab, you will be using 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
10.a.10.3R1.9
Note
the routing instance name, R3-z, where z
is the user number (1 or 2). Refer to the lab
diagram for the correct instance and user
number.
routing tables.
Part 1: Building the Extended IS-IS Topology
In this lab part, you use the lab diagram titled “Lab 5: Advanced IS-IS Configuration
Options andRouting Policy”. The extended IS-IS topology, as outlined in the lab
diagram, consists of four virtual routing instances in each of the student devices. A
merge file named ajspr-lab5-merge-mx_ has been created to help you expand
the current topology into the extended topology. The mx_ within the merge file name
references the assigned student device, mxA, mxB, mxC, or mxD.
Step 1.1
Ensure that you know to which device you are assigned. Check with your instructor if
necessary. Change all the x values on the Lab 5 lab guide to reflect the correct
the lab.
Step 1.2
Access the command line interface (CLI) at your station using either the console,
Telnet, or Secure Shell (SSH) as directed by your instructor.
Step 1.3
both the username and password are case-sensitive.
mxB-1 (ttyp0)
login: lab
Password:
Lab 5–2 • Advanced IS-IS Configuration and Routing Policy (Detailed) www.juniper.net
---JUNOS 10.3R1.9 built 2010-08-13 12:48:29 UTC
lab@mxB-1>
Step 1.4
Enter configuration mode and delete the routing-instances hierarchy. Use the load
override command to load the ajspr-lab5-reset-mx_.config file located
in the /var/tmp directory. The mx_ within the reset file name references the
assigned student device, mxA-1, mxA-2, etc. Commit the changes and return to
operational mode.
[edit]
lab@mxB-1# load override ajspr-lab5-reset-mxB-1.config
load complete
[edit]
commit complete
lab@mxB-1>
Step 1.5
Use the show configuration command to display the current active
configuration.
version 10.3R1.9;
groups {
ISO {
interfaces {
<*-*> {
unit <*> {
family iso;
}
}
}
}
}
system {
host-name mxB-1;
ssh-dsa "ssh-dss
SECRET-DATA
}
login {
user lab {
uid 2000;
class super-user;
authentication {
SECRET-DATA
}
}
}
services {
ftp;
ssh;
telnet;
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
}
}
}
chassis {
fpc 1 {
pic 0 {
tunnel-services {
bandwidth 1g;
}
}
}
}
interfaces {
apply-groups ISO;
ge-1/0/0 {
vlan-tagging;
unit 1121 {
description "connection to P1";
vlan-id 1121;
family inet {
address 172.22.121.1/24;
}
}
unit 1123 {
vlan-id 1123;
family inet {
address 172.22.123.1/24;
}
}
unit 1125 {
vlan-id 1125;
family inet {
address 172.22.125.1/24;
}
}
}
ge-1/0/1 {
vlan-tagging;
}
ge-1/0/4 {
vlan-tagging;
unit 20 {
description "connection between default and R3-1";
vlan-id 20;
family inet {
address 10.0.20.1/24;
}
}
unit 21 {
description "connection between default and R4-1";
vlan-id 21;
family inet {
address 10.0.21.1/24;
}
}
}
ge-1/0/5 {
vlan-tagging;
unit 22 {
description "connection between R3-1 and R5-1";
vlan-id 22;
family inet {
address 10.0.22.1/24;
}
}
unit 23 {
vlan-id 23;
family inet {
address 10.0.23.1/24;
}
}
}
ge-1/1/4 {
vlan-tagging;
unit 20 {
description "connection between R3-1 and default";
vlan-id 20;
family inet {
address 10.0.20.2/24;
}
}
unit 21 {
description "connection between R4-1 and default";
vlan-id 21;
family inet {
address 10.0.21.2/24;
}
}
}
ge-1/1/5 {
vlan-tagging;
unit 22 {
vlan-id 22;
family inet {
address 10.0.22.2/24;
}
}
unit 23 {
vlan-id 23;
family inet {
address 10.0.23.2/24;
}
}
}
fxp0 {
unit 0 {
family inet {
address 10.210.15.3/27;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.20.1/32;
}
family iso {
address 49.0001.1921.6802.0001.00;
}
}
unit 1 {
family inet {
address 192.168.20.2/32;
}
family iso {
address 49.0001.1921.6802.0002.00;
}
}
unit 2 {
family inet {
address 192.168.20.3/32;
}
family iso {
address 49.0001.1921.6802.0003.00;
}
}
unit 3 {
family inet {
address 192.168.20.4/32;
}
family iso {
address 49.0001.1921.6802.0004.00;
}
}
}
}
protocols {
isis {
interface ge-1/0/0.1121 {
level 1 disable;
}
level 1 disable;
}
level 1 disable;
}
interface lo0.0;
}
}
policy-options {
policy-statement export-default {
term 1 {
from {
protocol ospf;
}
then accept;
}
}
policy-statement export-rip-route {
term 1 {
from protocol rip;
then accept;
}
}
policy-statement import-rip-route {
term 1 {
from {
protocol rip;
}
then accept;
}
term 2 {
from {
protocol rip;
}
then reject;
}
}
policy-statement ospf-import {
term 1 {
from {
route-filter 20.20.0.0/21 orlonger;
}
then reject;
}
}
}
routing-instances {
R3-1 {
interface lo0.1;
protocols {
isis {
level 1 disable;
}
level 1 disable;
}
interface lo0.1;
}
}
}
R4-1 {
interface lo0.2;
protocols {
isis {
level 1 disable;
}
level 1 disable;
}
interface lo0.2;
}
}
}
R5-1 {
interface lo0.3;
protocols {
isis {
level 1 disable;
}
level 1 disable;
}
interface lo0.3;
}
}
}
}
lab@mxB-1>
Step 1.6
Use the show isis interface command to verify that the new extended IS-IS
topology has been loaded into the student device.
ge-1/0/0.1121 2 0x2 Disabled mxB-1.02 10/10
ge-1/0/4.20 2 0x1 Disabled 1921.6802.0002.02 10/10
ge-1/0/4.21 2 0x1 Disabled 1921.6802.0003.02 10/20
lab@mxB-1>
Step 1.7
Use the show isis adjacency command to verify that the new extended IS-IS
topology has been loaded into the student device.
ge-1/0/4.20 1921.6802.0002 2 Up 8 80:71:1f:c3:7:7c
ge-1/0/4.21 1921.6802.0003 2 Up 7 80:71:1f:c3:7:7c
lab@mxB-1>
Step 1.8
Use the show isis interface instance R5-z command to verify that the
new extended IS-IS topology has been loaded into the student device.
lab@mxB-1> show isis interface instance R5-z
ge-1/1/5.22 2 0x3 Disabled 1921.6802.0004.03 10/10
ge-1/1/5.23 2 0x2 Disabled 1921.6802.0004.02 10/20
lab@mxB-1>
Step 1.9
Use the show isis adjacency instance R5-z command to verify that the
new extended IS-IS topology has been loaded into the student device.
lab@mxB-1> show isis adjacency instance R5-z
ge-1/1/5.22 1921.6802.0002 2 Up 25 80:71:1f:c3:7:65
ge-1/1/5.23 1921.6802.0003 2 Up 19 80:71:1f:c3:7:65
lab@mxB-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. There are no Level 1 IS-IS adjacencies

established.
Step 1.10
Use the show isis database command to examine the current IS-IS link-state
database.
lab@mxB-1> show isis database
mxB-1.00-00 0x20 0x56c6 854 L1 L2 Attached
1 LSPs

mxB-1.00-00 0x2c 0x2560 948 L1 L2
mxB-1.02-00 0x20 0xf247 854 L1 L2
1921.6802.0002.00-00 0x39 0x2fd 946 L1 L2
1921.6802.0002.02-00 0x2b 0x65e2 853 L1 L2
1921.6802.0003.00-00 0x4 0x7f5e 912 L1 L2
1921.6802.0003.02-00 0x2 0xdf8e 912 L1 L2
1921.6802.0004.00-00 0x4 0x20dc 913 L1 L2
1921.6802.0004.02-00 0x2 0x94d2 881 L1 L2
1921.6802.0004.03-00 0x2 0x4721 913 L1 L2
1921.6802.1001.00-00 0x22 0x4d99 634 L1 L2
1921.6802.1001.02-00 0x1b 0x4fbf 619 L1 L2
mxB-2.00-00 0x21 0x9043 628 L1 L2
1921.6802.1003.00-00 0x3 0x1663 657 L1 L2
1921.6802.1003.02-00 0x1 0x78a6 632 L1 L2
1921.6802.1004.00-00 0x3 0xfc9d 655 L1 L2
1921.6802.1004.02-00 0x1 0xe633 630 L1 L2
1921.6802.1004.03-00 0x1 0x26f0 655 L1 L2
vr-device.00-00 0x1b7 0xec10 951 L1 L2
18 LSPs
lab@mxB-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

link-state database 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
In this lab part, you configure 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
hierarchy. Using ajspr as the key, configure Level 2 hello-authentication on the
interface that is connected to the R3 routing instance.
[edit]

lab@mxB-1# set interface ge-1/0/4.xy level 2 hello-authentication-type md5

lab@mxB-1# set interface ge-1/0/4.xy level 2 hello-authentication-key ajspr

lab@mxB-1#
Step 2.2
Using ajspr as the key, configure level 2 hello-authentication on the interface that
is connected to the R4 routing instance.



lab@mxB-1#
Step 2.3
interface that is connected to the default routing instance routing instance.
[edit protocols isis interface ge-1/0/4.21]


lab@mxB-1#
Step 2.4
interface that is connected to the default routing instance routing instance. Commit
the changes and return to operational mode.
lab@mxB-1# up 3 edit R4-z protocols isis



lab@mxB-1# top
[edit]
commit complete
lab@mxB-1>
Step 2.5
Use the monitor traffic interface command to verify that the IS-IS hello
packets are using the MD5 authentication.
lab@mxB-1> monitor traffic interface ge-1/0/4.xy detail no-resolve
Address resolution is OFF.
Listening on ge-1/0/4.20, capture size 1514 bytes
16:37:34.979537 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: 1921.6802.0002, holding time: 9s, Flags: [Level 2 only]
lan-id: 1921.6802.0002.02, Priority: 64, PDU length: 75
IS Neighbor(s) TLV #6, length: 6
SNPA: 8071.1fc3.0764
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.20.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: 81186f98612f6044e9478b2afe5046f4
Step 2.6
Use the Ctrl + c key sequence to stop the monitor output.
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.7
Use the show isis adjacency command to verify that the IS-IS adjacencies are
established using the hello-authentication configuration.
ge-1/0/4.20 1921.6802.0002 2 Up 7 80:71:1f:c3:7:7c
ge-1/0/4.21 1921.6802.0003 2 Up 7 80:71:1f:c3:7:7c
lab@mxB-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
In this lab part, you change the metrics on the IS-IS routes. There are several ways of
manipulating routes within IS-IS. By changing the metrics on the IS-IS interfaces, the
SPF algorithm recalculates the shortest path changing the routing behavior. In this
lab part, you use different methods to change the IS-IS routing behavior.
Step 3.1
Use the show isis interface command to examine the default metrics
assigned to the IS-IS interfaces.
ge-1/0/0.1121 2 0x2 Disabled mxB-1.02 10/10
ge-1/0/4.20 2 0x1 Disabled 1921.6802.0002.02 10/10
ge-1/0/4.21 2 0x1 Disabled 1921.6802.0003.02 10/10
lab@mxB-1>
Question: What is the default Level 1 and Level 2

metric for the GE interfaces?
Answer: The default Level 1 and Level 2 metric is 10

for all interfaces.
Step 3.2
Use the show route 192.168.2z.4 table inet.0 command to display the
loopback interface of the R5-z routing instance within your student device in the
default routing table.
lab@mxB-1> show route 192.168.2z.4/32 table inet.0

192.168.20.4/32 *[IS-IS/18] 00:09:39, metric 20

> to 10.0.21.2 via ge-1/0/4.21
to 10.0.20.2 via ge-1/0/4.20
lab@mxB-1>
Question: What is the cost to reach the

192.168.20.4/32 network?
Answer: The route has an equal cost of 20 between

the two intermediate nodes.
Step 3.3
hierarchy. Use the reference-bandwidth command to change the default
metrics. Use 1 gigabit as the calculating bandwidth. Commit the change and return
[edit]

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

commit complete
lab@mxB-1>
Step 3.4
Use the show isis interface command to verify that the change in metric of
the IS-IS Level 2 interfaces.
ge-1/0/0.1121 2 0x2 Disabled mxB-1.02 1/1
ge-1/0/4.20 2 0x1 Disabled 1921.6802.0002.02 1/1
ge-1/0/4.21 2 0x1 Disabled 1921.6802.0003.02 1/1
lab@mxB-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 (1g) and divides it by the
static interface bandwidth (1g). The result is a cost
of 1.
Step 3.5
Use the show route 192.168.2z.4 table inet.0 command to display the
loopback of your device’s R5 routing instance from the perspective of the default
routing instance.

192.168.20.4/32 *[IS-IS/18] 00:00:27, metric 11

> to 10.0.21.2 via ge-1/0/4.21
to 10.0.20.2 via ge-1/0/4.20
lab@mxB-1>
Question: What is the cost to reach the

192.168.20.4/32 network?
Answer: The cost to reach the remote network has

changed from 20 to 11.
Step 3.6
hierarchy. On the ge-1/0/4.xy interface connecting the default routing instance
to the R4-z, change the Level 2 metric to 1000. Commit the change and return to
operational mode.
[edit]

lab@mxB-1# set interface ge-1/0/4.xy level 2 metric 1000

commit complete
lab@mxB-1>
Step 3.7
Use the show isis interface command to examine the default metrics
assigned to the IS-IS interfaces.
ge-1/0/0.1121 2 0x2 Disabled mxB-1.02 1/1
ge-1/0/4.20 2 0x1 Disabled 1921.6802.0002.02 1/1
ge-1/0/4.21 2 0x1 Disabled 1921.6802.0003.02 1/1000
lab@mxB-1>
Step 3.8
Use the show route 192.168.2z.4 table inet.0 to display the loopback
of your device’s R5 routing instance from the perspective of the default routing
instance.

192.168.20.4/32 *[IS-IS/18] 00:00:34, metric 11

> to 10.0.20.2 via ge-1/0/4.20
lab@mxB-1>
Question: What is the Level 2 cost to the remote

node? What has happened to the remote network
route?
Answer: The IS-IS Level 2 cost for the remote GE

interface has been changed to 1000. 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 through the other remote node.
Step 3.9
R3-z] hierarchy. Enable IS-IS overload on the R3 routing-instance, which is the
active intermediate node to the R5 routing instance. Commit the change and return
[edit]
[edit routing-instances R3-z]
lab@mxB-1# set protocols isis overload
[edit]
commit complete
lab@mxB-1>
Step 3.10
Use the show isis database level 2 command to ensure that the overload
bit has been enabled in the LSP.
lab@mxB-1> show isis database level 2
mxB-1.00-00 0x86 0x794d 1179 L1 L2
mxB-1.02-00 0x78 0x429f 1179 L1 L2
1921.6802.0002.00-00 0x93 0x8f12 1177 L1 L2 Overload
1921.6802.0002.02-00 0x82 0xb63a 1177 L1 L2
1921.6802.0003.00-00 0x5e 0x7f54 1074 L1 L2
1921.6802.0003.02-00 0x59 0x31e5 1177 L1 L2
1921.6802.0004.00-00 0x5c 0xac2 1175 L1 L2
1921.6802.0004.02-00 0x5a 0xe32b 1175 L1 L2
1921.6802.0004.03-00 0x5a 0x9679 1175 L1 L2
1921.6802.1001.00-00 0x72 0xace9 381 L1 L2
1921.6802.1001.02-00 0x6b 0xae10 355 L1 L2
1921.6802.1002.00-00 0x71 0xef93 365 L1 L2
mxB-2.00-00 0x53 0x75b3 1129 L1 L2
mxB-2.02-00 0x51 0xd7f6 379 L1 L2
1921.6802.1004.00-00 0x53 0x5ced 781 L1 L2
1921.6802.1004.02-00 0x51 0x4683 367 L1 L2
1921.6802.1004.03-00 0x51 0x8541 1128 L1 L2
vr-device.00-00 0x208 0x4962 786 L1 L2
18 LSPs
Question: How can you tell if the overload bit is

enabled?
Answer: The word “Overload” will be in the

attributes column.
Step 3.11
Verify that the route has moved to the R4-z routing instance using the show
route 192.168.2z.4/32 table inet.0 command.

192.168.20.4/32 *[IS-IS/18] 00:00:41, metric 73

> to 10.0.21.2 via ge-1/0/4.21
lab@mxB-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 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 show isis database level 2 mx_-z.00 extensive | find
tlv command to display the TLVs that are being advertised in the default routing
instance LSP.
lab@mxB-1> show isis database level 2 mx_-z.00 extensive | find tlv
TLVs:
Speaks: IP
Speaks: IPV6
IP router id: 192.168.20.1
IP address: 192.168.20.1
Hostname: mxB-1
IS neighbor: mxB-1.02, Internal, Metric: default 1
IP address: 172.22.121.1
lab@mxB-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
hierarchy. Enable wide-metrics only for Level 2 interfaces on the default routing
instance. Commit the configuration and return to operational mode.
[edit]

lab@mxB-1# set level 2 wide-metrics-only

commit complete
lab@mxB-1>
Step 3.14
Use the show isis database level 2 mx_-z.00 extensive | find
tlv command to display the TLVs that are now being advertised in the default
routing instance LSP.
lab@mxB-1> show isis database level 2 mx_-z.00 extensive | find tlv
TLVs:
Speaks: IP
Speaks: IPV6
IP router id: 192.168.20.1
IP address: 192.168.20.1
Hostname: mxB-1
IP address: 172.22.121.1
lab@mxB-1>
Question: What is the metric value in the IP

extended prefix (TLV #135) on the adjacent
interface?
Answer: The narrow TLVs (TLV #2 and TLV #128) are

no longer being advertised in the LSP. Therefore,
the configured metric value can be advertised
within the 4-byte metric field in the extended TLV
#135.
Step 3.15
Use the show route 192.168.2z.4/32 table inet.0 command to display
the route to the R5 routing instance loopback address.

192.168.20.4/32 *[IS-IS/18] 00:05:38, metric 1010

> to 10.0.21.2 via ge-1/0/4.21
lab@mxB-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
Enter configuration mode and delete the policy-options hierarchy. This
deletion removes any policies that might exist from other labs. Commit this
configuration.
[edit]
lab@mxB-1# delete policy-options
[edit]
lab@mxB-1# commit
commit complete
[edit]
lab@mxB-1#
Step 4.2
Navigate to the [edit routing-instances R5-z] hierarchy. Add the
ge-1/0/0.11xy interface that connects the P3 device to your R5-z routing
instance.
[edit]

lab@mxB-1# set interface ge-1/0/0.11xy

lab@mxB-1#
Step 4.3
Navigate to the [edit routing-instances R5-z protocols rip group
P3] hierarchy. Add the interface connected to the P3 router as a neighbor in that
group.
lab@mxB-1# edit protocols rip group P3
[edit routing-instances R5-1 protocols rip group P3]

lab@mxB-1# set neighbor ge-1/0/0.11xy

commit complete
lab@mxB-1>
Step 4.4
Verify that a RIP neighbor has been established with the P3 router using the show
rip neighbor instance R5-z command. Also, use the show route
receive-protocol rip 172.22.1xy.2 table R5-z.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@mxB-1> show rip neighbor instance R5-z

Source Destination Send Receive In
Neighbor State Address Address Mode Mode Met
-------- ----- ------- ----------- ---- ------- ---
ge-1/0/0.1125 Up 172.22.125.1 224.0.0.9 mcast both 1
lab@mxB-1> show route receive-protocol rip 172.22.1xy.2 table R5-z.inet.0
B5-1.inet.0: 35 destinations, 35 routes (35 active, 0 holddown, 0 hidden)

20.20.0.0/21 *[RIP/100] 00:06:54, metric 2, tag 0

> to 172.22.125.2 via ge-1/0/0.1125
20.20.0.0/24 *[RIP/100] 00:06:54, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.1.0/24 *[RIP/100] 00:06:54, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.2.0/24 *[RIP/100] 00:06:54, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.3.0/24 *[RIP/100] 00:06:54, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.4.0/25 *[RIP/100] 00:06:54, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.4.128/25 *[RIP/100] 00:06:54, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.5.0/26 *[RIP/100] 00:06:54, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.5.64/26 *[RIP/100] 00:06:54, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.5.128/26 *[RIP/100] 00:06:54, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.5.192/26 *[RIP/100] 00:06:54, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
lab@mxB-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.1. The RIP version 2
multicast destination address is 224.0.0.9
Step 4.5
policy-statement import-rip-routes] hierarchy. Create a policy to
accept only RIP routes with a prefix-length of /24, accepting no other RIP routes.
[edit]
lab@mxB-1# edit policy-options policy-statement import-rip-routes
[edit policy-options policy-statement import-rip-routes]


lab@mxB-1# set term 1 from route-filter 0/0 prefix-length-range /24-/24



lab@mxB-1#
Step 4.6
Navigate to [edit routing-instances R5-z] and apply the import policy to
the RIP group. Commit the changes and return to operational mode.

lab@mxB-1# set protocols rip group P3 import import-rip-routes

commit complete
lab@mxB-1>
Step 4.7
Verify that the policy is working by using the show route receive-protocol
rip 172.22.1xy.2 table R5-z.inet.0 command to view all routes being
received from the RIP router.
lab@mxB-1> show route receive-protocol rip 172.22.1xy.2 table R5-z.inet.0

20.20.0.0/24 *[RIP/100] 00:27:49, metric 2, tag 0

> to 172.22.125.2 via ge-1/0/0.1125
20.20.1.0/24 *[RIP/100] 00:27:49, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.2.0/24 *[RIP/100] 00:27:49, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.3.0/24 *[RIP/100] 00:27:49, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
lab@mxB-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.8
policy-statement export-rip-default] hierarchy. Configure the policy
to advertise a default route.
[edit]
lab@mxB-1# edit policy-options policy-statement export-rip-default
[edit policy-options policy-statement export-rip-default]

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


lab@mxB-1#
Step 4.9
Navigate to the R5 routing instance [edit routing-instances R5-z
protocols rip group P3] and apply the export-rip-default policy.
Commit the changes returning to operational mode.
[edit]
lab@mxB-1# top edit routing-instances R5-z protocols rip group P3

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

commit complete
lab@mxB-1>
Step 4.10
table R5-z.inet.0 command to display the routes that are being advertised to
the RIP network.
lab@mxB-1> show route advertising-protocol rip 172.22.1xy.1 table R5-z.inet.0
lab@mxB-1>
Question: Is the export routing policy advertising the

default route?
Answer: According to the show route

advertise-protocol command, no routes are
being advertised to the RIP network.
Step 4.11
The show route 0/0 exact table R5-z.inet.0 and show isis
database instance R5-z commands provide you with the reason why the
default route is not being advertised to the RIP network.
lab@mxB-1> show route 0/0 exact table R5-z.inet.0
lab@mxB-1> show isis database instance R5-z

1921.6802.0004.00-00 0x71 0x13bf 873 L1 L2 Attached
1 LSPs
mxB-1.00-00 0x9a 0xb676 870 L1 L2
mxB-1.02-00 0x8c 0x2023 870 L1 L2
1921.6802.0002.00-00 0xa5 0x6b24 872 L1 L2 Overload
1921.6802.0002.02-00 0x94 0x924c 872 L1 L2
1921.6802.0003.00-00 0x72 0x5768 872 L1 L2
1921.6802.0003.02-00 0x6c 0xbf8 872 L1 L2
1921.6802.0004.00-00 0x6f 0xe3d5 873 L1 L2
1921.6802.0004.02-00 0x6d 0xbd3e 873 L1 L2
1921.6802.0004.03-00 0x6d 0x708c 873 L1 L2
mxB-2.00-00 0x85 0xcbb7 918 L1 L2
mxB-2.02-00 0x7e 0x8823 1028 L1 L2
1921.6802.1002.00-00 0x82 0xcda4 454 L1 L2
1921.6802.1003.00-00 0x64 0x53c4 654 L1 L2
1921.6802.1003.02-00 0x62 0xb508 458 L1 L2
1921.6802.1004.00-00 0x64 0x3afe 456 L1 L2
1921.6802.1004.02-00 0x63 0x2295 1045 L1 L2
1921.6802.1004.03-00 0x62 0x6352 588 L1 L2
vr-device.00-00 0x21b 0xb8d 917 L1 L2
18 LSPs
lab@mxB-1>
Question: Why is no default route active in the R5-z

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.12
R5-z routing-options] hierarchy. Create an aggregate default route. Commit
the change and return to operational mode.
[edit]

lab@mxB-1# set routing-options aggregate route 0/0
commit complete
lab@mxB-1>
Step 4.13
table R5-z.inet.0 command to verify that the default route is now being
advertised to the RIP network.

0.0.0.0/0 *[Aggregate/130] 00:00:21

Reject
lab@mxB-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.14
policy-statement export-rip-to-isis] hierarchy. Configure the policy
to advertise the RIP routes as IS-IS external Type 1 routes.
[edit]
lab@mxB-1# edit policy-options policy-statement export-rip-to-isis
[edit policy-options policy-statement export-rip-to-isis]


lab@mxB-1# set term 1 then external type 1


lab@mxB-1#
Step 4.15
Navigate to the [edit routing-instances R5-z] hierarchy. Apply the
export-rip-to-isis policy as an export policy to IS-IS. Commit the changes

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

commit complete
lab@mxB-1>
Step 4.16
Use the show route 20.20.0.0/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.
lab@mxB-1> show route 20.20.0.0/22 table inet.0

20.20.0.0/24 *[IS-IS/165] 00:05:10, metric 1012

> to 10.0.21.2 via ge-1/0/4.21
20.20.1.0/24 *[IS-IS/165] 00:05:10, metric 1012
> to 10.0.21.2 via ge-1/0/4.21
20.20.2.0/24 *[IS-IS/165] 00:05:10, metric 1012
> to 10.0.21.2 via ge-1/0/4.21
20.20.3.0/24 *[IS-IS/165] 00:05:10, metric 1012
> to 10.0.21.2 via ge-1/0/4.21
lab@mxB-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

routes in the primary routing instance.
Lab 6
Configuring a Multilevel IS-IS Network (Detailed)
Overview
In this lab, you will be using 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

10.a.10.3R1.9
Note
the routing instance name, R3-z, where z
number.
routing instance, the routing-instance
R3-z switch must be used to consult the
appropriate virtual instance. When
performing show commands, the
instance R3-z or table R3-z switch
must be used to display the appropriate
adjacencies or 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. A load file named ajspr-lab6-reset-mx_ has
been created to help you configure the current topology into the multilevel topology.
The mx_ within the reset file name references the assigned student device, mxA-1,
mxA-2, etc. Ensure that you know to which device you are assigned. Check with your
instructor if necessary.
Step 1.1
Access the command line interface (CLI) at your station using either the console,
Telnet, or Secure Shell (SSH) as directed by your Instructor.
Step 1.2
mxA-1 (ttyp0)
login: lab
Password:
---JUNOS 10.3R1.9 built 2010-08-13 12:48:29 UTC

lab@mxA-1>
Lab 6–2 • Configuring a Multilevel IS-IS Network (Detailed) www.juniper.net

Step 1.3
Enter configuration mode and use the load override command to load the
lab 6 reset file. The reset file is named ajspr-lab6-reset-mx_.config and
is located in the /var/tmp directory. Commit the changes and return to operational
mode.
[edit]
load complete
[edit]
commit complete
lab@mxB-1>
Step 1.4
Issue the show configuration command to verify that your router has the
correct initial configuration loaded.
version 10.3R1.9;
groups {
ISO {
interfaces {
<*-*> {
unit <*> {
family iso;
}
}
}
}
}
system {
host-name mxB-1;
ssh-dsa "ssh-dss
SECRET-DATA
}

login {
user lab {
uid 2000;
class super-user;
authentication {
SECRET-DATA
}
}
}
services {
ftp;
ssh;
telnet;
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
}
}
}
chassis {
fpc 1 {
pic 0 {
tunnel-services {
bandwidth 1g;
}
}
}
}
interfaces {
apply-groups ISO;
ge-1/0/0 {
vlan-tagging;
unit 1121 {
vlan-id 1121;
family inet {
address 172.22.121.1/24;
}
}
unit 1123 {
vlan-id 1123;
family inet {
address 172.22.123.1/24;
}
}

unit 1125 {
vlan-id 1125;
family inet {
address 172.22.125.1/24;
}
}
}
ge-1/0/4 {
vlan-tagging;
unit 20 {
description "connection between mxB-1 and R3-1";
vlan-id 20;
family inet {
address 10.0.20.1/24;
}
}
unit 21 {
description "connection between mxB-1 and R4-1";
vlan-id 21;
family inet {
address 10.0.21.1/24;
}
}
}
ge-1/0/5 {
vlan-tagging;
unit 22 {
vlan-id 22;
family inet {
address 10.0.22.1/24;
}
}
unit 23 {
vlan-id 23;
family inet {
address 10.0.23.1/24;
}
}
}
ge-1/1/4 {
vlan-tagging;
unit 20 {
description "connection between R3-1 and mxB-1";
vlan-id 20;
family inet {
address 10.0.20.2/24;
}
}
unit 21 {
description "connection between R4-1 and mxB-1";
vlan-id 21;
family inet {

address 10.0.21.2/24;
}
}
}
ge-1/1/5 {
vlan-tagging;
unit 22 {
vlan-id 22;
family inet {
address 10.0.22.2/24;
}
}
unit 23 {
vlan-id 23;
family inet {
address 10.0.23.2/24;
}
}
}
fxp0 {
unit 0 {
family inet {
address 10.210.15.3/27;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.20.1/32;
}
family iso {
address 49.1234.1921.6802.0001.00;
}
}
unit 1 {
family inet {
address 192.168.20.2/32;
}
family iso {
address 49.0001.1921.6802.0002.00;
}
}
unit 2 {
family inet {
address 192.168.20.3/32;
}
family iso {
address 49.0001.1921.6802.0003.00;
}
}
unit 3 {

family inet {
address 192.168.20.4/32;
}
family iso {
address 49.0001.1921.6802.0004.00;
}
}
}
}
protocols {
isis {
level 1 disable;
}
level 1 disable;
level 2 {
hello-authentication-key "$9$AqnEpu1KvLNVYKMaU"; ## SECRET-DATA
hello-authentication-type md5;
}
}
level 1 disable;
level 2 {
hello-authentication-key "$9$dZbwgHkPQ39Hqu1"; ## SECRET-DATA
}
}
interface lo0.0;
}
}
policy-options {
policy-statement export-rip-default {
term 1 {
from {
}
then accept;
}
}
policy-statement export-rip-to-isis {
term 1 {
from protocol rip;
then {
external {
type 1;
}
accept;
}
}
}
policy-statement import-rip-routes {
term 1 {
from {
protocol rip;

route-filter 0.0.0.0/0 prefix-length-range /24-/24;
}
then accept;
}
term 2 {
then reject;
}
}
}
routing-instances {
R3-1 {
interface lo0.1;
protocols {
isis {
level 2 disable;
}
level 1 disable;
level 2 {
hello-authentication-key "$9$SojrlMbwgJUHbsPQ"; ##
SECRET-DATA
}
}
interface lo0.1;
}
}
}
R4-1 {
interface lo0.2;
protocols {
isis {
level 2 disable;
}
level 1 disable;
level 2 {
hello-authentication-key "$9$8IgXxdJZjqPQJG6A"; ##
SECRET-DATA
}
}
interface lo0.2;
}
}
}
R5-1 {

interface lo0.3;
routing-options {
aggregate {
route 0.0.0.0/0;
}
}
protocols {
rip {
group R3 {
export export-rip-default;
import import-rip-routes;
neighbor ge-1/0/0.1125;
}
}
isis {
export export-rip-to-isis;
level 1 prefix-export-limit 8;
level 2 disable;
}
level 2 disable;
}
interface lo0.3;
}
}
}
}
lab@mxB-1>
Step 1.5
Use the operational mode commands show isis interface and show isis
adjacency to verify that the new extended IS-IS topology in the default routing
instance.
ge-1/0/0.1121 2 0x2 Disabled mxB-1.02 10/10
ge-1/0/4.20 2 0x1 Disabled 1921.6802.0002.02 10/10
ge-1/0/4.21 2 0x1 Disabled 1921.6802.0003.02 10/10

ge-1/0/4.20 1921.6802.0002 2 Up 8 80:71:1f:c3:7:7c
ge-1/0/4.21 1921.6802.0003 2 Up 7 80:71:1f:c3:7:7c
lab@mxB-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. There are no Level 1
adjacencies in the default routing instance.
Step 1.6
adjacency to verify that the new extended IS-IS topology in the R3-z routing
instance.
ge-1/0/5.22 1 0x1 1921.6802.0004.02 Disabled 10/10
ge-1/1/4.20 2 0x2 Disabled 1921.6802.0002.02 10/10

ge-1/0/5.22 1921.6802.0004 1 Up 8 80:71:1f:c3:7:7d
ge-1/1/4.20 mxB-1 2 Up 21 80:71:1f:c3:7:64
Question: How many adjacencies exist on the R3

routing instances? At what level are these
adjacencies?
Answer: The R3 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 routing
instance.

Step 1.7
instance.
ge-1/0/5.23 1 0x1 1921.6802.0004.03 Disabled 10/10
ge-1/1/4.21 2 0x2 Disabled 1921.6802.0003.02 10/10

ge-1/0/5.23 1921.6802.0004 1 Up 6 80:71:1f:c3:7:7d
ge-1/1/4.21 mxB-1 2 Up 25 80:71:1f:c3:7:64
lab@mxB-1>

routing instances? At what level are these
adjacencies?
Answer: The R4 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 routing
instance.
Step 1.8
instance.
ge-1/1/5.22 1 0x2 1921.6802.0004.02 Disabled 10/10
ge-1/1/5.23 1 0x3 1921.6802.0004.03 Disabled 10/10

ge-1/1/5.22 1921.6802.0002 1 Up 24 80:71:1f:c3:7:65
ge-1/1/5.23 1921.6802.0003 1 Up 25 80:71:1f:c3:7:65
lab@mxB-1>

routing instance? At what level are these
adjacencies?
Answer: The R5 router has two adjacencies, both at

IS-IS Level 1.
Step 1.9
Using the information from the previous steps, answer the following questions.
Question: Which routing instance has only Level 1

IS-IS adjacencies?
Answer: The R5 routing instance has only IS-IS

Level 1 adjacencies.
Question: Which routing instance has only Level 2

IS-IS adjacencies?
Answer: The default routing instance has only IS-IS

Level 2 adjacencies.
Question: Which routing instances have both

Level 1 and Level 2 IS-IS adjacencies?
Answer: The R3 and R4 routing instances have both

IS-IS Level 1 and Level 2 adjacencies. These R3 and
R4 routing instances are known as the IS-IS L1/L2
attached routers.

Part 2: Configuring 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 R3
and R4 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 192.168.0.0/16 table inet.0 operational mode command to
display all active loopback addresses in the Level 2 database.

192.168.20.1/32 *[Direct/0] 4w4d 16:35:13

> via lo0.0
192.168.20.2/32 *[IS-IS/18] 15:41:05, metric 10
> to 10.0.20.2 via ge-1/0/4.20
192.168.20.3/32 *[IS-IS/18] 15:41:08, metric 10
> to 10.0.21.2 via ge-1/0/4.21
192.168.20.4/32 *[IS-IS/18] 15:40:44, metric 20
to 10.0.21.2 via ge-1/0/4.21
> to 10.0.20.2 via ge-1/0/4.20
192.168.21.1/32 *[IS-IS/18] 15:41:20, metric 20
> to 172.22.121.2 via ge-1/0/0.1121
192.168.21.2/32 *[IS-IS/18] 15:41:20, metric 30
> to 172.22.121.2 via ge-1/0/0.1121
192.168.21.3/32 *[IS-IS/18] 15:41:20, metric 30
> to 172.22.121.2 via ge-1/0/0.1121
192.168.21.4/32 *[IS-IS/18] 15:41:20, metric 40
> to 172.22.121.2 via ge-1/0/0.1121
192.168.100.1/32 *[IS-IS/18] 15:41:20, metric 10
> to 172.22.121.2 via ge-1/0/0.1121
lab@mxB-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 internal
loopback address has been leaked into the Level 2
database through the R3 and R4 L1/L2 attached
routers.
Step 2.2
The R5 routing instance only has IS-IS Level 1 adjacencies. Use the show route
192.168.0.0/16 table R5-z operational mode command to display all active
loopback address in the Level 1 database.
lab@mxB-1> show route 192.168.0.0/16 table R5-z

192.168.20.2/32 *[IS-IS/15] 15:48:29, metric 10

> to 10.0.22.1 via ge-1/1/5.22
192.168.20.3/32 *[IS-IS/15] 15:48:07, metric 10
> to 10.0.23.1 via ge-1/1/5.23
192.168.20.4/32 *[Direct/0] 15:48:45
> via lo0.3
lab@mxB-1>
Question: How many loopback addresses are active

IS-IS routes in the R5 routing table? Are any of the
routes from the Level 2 routing instances? Why?
Answer: The R5 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 router to the Level 2 routes requires a default route. Use the
show route 0/0 exact table R5-z command to display the active default
route in the R5 routing table.
lab@mxB-1> show route 0/0 exact table R5-z

0.0.0.0/0 *[IS-IS/15] 18:47:41, metric 10

to 10.0.23.1 via ge-1/1/5.23
> to 10.0.22.1 via ge-1/1/5.22
[Aggregate/130] 18:48:19
Reject
lab@mxB-1>
Question: Is the default route an active IS-IS route in

the R5-1.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-z command.
lab@mxB-1> show isis database level 1 instance R5-z
1921.6802.0002.00-00 0x58 0x4293 1012 L1 L2 Attached
1921.6802.0003.00-00 0x58 0x9638 1097 L1 L2 Attached
1921.6802.0004.00-00 0x58 0xad05 1083 L1 L2
1921.6802.0004.02-00 0x56 0xa56f 866 L1 L2
1921.6802.0004.03-00 0x56 0xe42d 1083 L1 L2
5 LSPs
lab@mxB-1>

Question: Which routers have enabled the attach bit
in their Level 1 LSP?
Answer: The R3 and R4 routers have enable the

attach bit in their Level 1 LSP. Every router in a the
Level 1 domain will create a default route to the
closest L1/L2 attached router.
Step 2.5
Use the show route protocol rip table R5-z command to verify that RIP
routes are being received from the P3 RIP network.
lab@mxB-1> show route protocol rip table R5-z

20.20.0.0/24 *[RIP/100] 15:59:14, metric 2, tag 0

> to 172.22.125.2 via ge-1/0/0.1125
20.20.1.0/24 *[RIP/100] 15:59:14, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.2.0/24 *[RIP/100] 15:59:14, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
20.20.3.0/24 *[RIP/100] 15:59:14, metric 2, tag 0
> to 172.22.125.2 via ge-1/0/0.1125
224.0.0.9/32 *[RIP/100] 15:59:14, metric 1
MultiRecv
R5-1.iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@mxB-1>
Step 2.6
Display the IS-IS Level 1 database in the R5 routing instance using the show isis
database level 1 instance R5-z command.
1921.6802.0002.00-00 0x4a 0x5e85 409 L1 L2 Attached
1921.6802.0003.00-00 0x4a 0xb22a 770 L1 L2 Attached
1921.6802.0004.00-00 0x4a 0xc9f6 456 L1 L2
1921.6802.0004.02-00 0x49 0xbf62 1178 L1 L2
1921.6802.0004.03-00 0x48 0x11f 648 L1 L2
5 LSPs
lab@mxB-1>

Question: What is the primary LSP ID for the R5
routing instance in the IS-IS Level 1 database?
Answer: The LSP-ID for the R5 routing instance is

1921.6802.0004.00.
Step 2.7
Use the LSP-ID defined in the previous step to display the IS-IS database for the R5
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
1921.680x.y004.00 extensive instance R5-z | find tlv
command to display these TLVs.
lab@mxB-1> show isis database level 1 1921.680x.y004.00 extensive instance R5-z
| find tlv
TLVs:
Speaks: IP
Speaks: IPV6
Hostname: mxB-1
IP external prefix: 20.20.0.0/24, Internal, Metric: default 2, Up
lab@mxB-1>

Question: Are the RIP routes installed in the R5 IS-IS
LSP as external Type 130 TLVs?
Answer: The four RIP routes are installed in the R5

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.8
Display the RIP routes in the default routing table using the show route
20.20.0.0/22 table inet.0 command.
lab@mxB-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
In this lab part, you modify the default flooding scope. The default IS-IS flooding
scope can be modified using routing policy. Because the R3 and R4 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 and R4 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.xy.0/23 table inet.0 command to display the
Level 1 interface routes connected to the R5 router in the default routing table.

lab@mxB-1> show route 10.0.xy.0/23 table inet.0

10.0.22.0/24 *[IS-IS/18] 19:56:35, metric 20

> to 10.0.20.2 via ge-1/0/4.20
10.0.23.0/24 *[IS-IS/18] 19:56:38, metric 20
> to 10.0.21.2 via ge-1/0/4.21
lab@mxB-1>
Step 3.2
R3-z routing-options] hierarchy. Configure a 10.0.xy.0/23 aggregate route
in the R3 routing instance.
[edit]
lab@mxB-1# edit routing-instances R3-z routing-options
[edit routing-instances R3-1 routing-options]

lab@mxB-1# set aggregate route 10.0.xy.0/23

lab@mxB-1#
Step 3.3
R4-z routing-options] hierarchy. Configure a 10.0.xy.0/23 aggregate route
in the R4 routing instance.
lab@mxB-1# up 2 edit R4-z routing-options


lab@mxB-1#
Step 3.4
Navigate to the [edit policy-options policy-statement
summarize-level-1] hierarchy. Create a routing policy named
summarize-level-1 to summarize the Level 1 10.0.xy.0/23 routes and
suppress the more specific routes.
lab@mxB-1# top edit policy-options policy-statement summarize-level-1
[edit policy-options policy-statement summarize-level-1]

lab@mxB-1# set term 1 from protocol aggregate

lab@mxB-1# set term 1 from route-filter 10.0.xy.0/23 exact

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


lab@mxB-1# set term 2 from route-filter 10.0.xy.0/23 longer



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

lab@mxB-1#
Step 3.5
Navigate to the [edit routing-instances R3-z protocols isis]
hierarchy and apply the policy named summarize-level-1, as an export policy.

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

lab@mxB-1#

Step 3.6
hierarchy and apply the policy named summarize-level-1, as an export policy.
Commit the changes and return to operational mode.
lab@mxB-1# up 3 edit R4-Z protocols isis

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

commit complete
lab@mxB-1>
Step 3.7
Use the show route 10.0.xy.0/23 table inet.0 command to verify that
the Level 1 internal routes have been summarized into the 10.0.xy.0/23 route.

10.0.22.0/23 *[IS-IS/165] 00:03:16, metric 20

> to 10.0.21.2 via ge-1/0/4.21
to 10.0.20.2 via ge-1/0/4.20
lab@mxB-1>
Question: Are the Level 1 routes being summarized

in the Level 2 database?
Answer: Yes. The 10.0.22.0/23 summary route is

an active IS-IS external route in the default routing
table as seen in the output above and the more
specific 10.0.22.0/24 and the 10.0.23.0/24
internal Level 1 routes have been suppressed.
Step 3.8
policy-statement rip-to-level-2] hierarchy. Configure the policy to
accept all routes more specific then 20.20.0.0/22 into the Level 2 database.

[edit]
lab@mxB-1# edit policy-options policy-statement rip-to-level-2
[edit policy-options policy-statement rip-to-level-2]




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

lab@mxB-1#
Step 3.9
hierarchy and apply the policy named rip-to-level-2 as an export policy.

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

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

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

commit complete
lab@mxB-1>
Step 3.11
Use the show route 20.20.0.0/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:04:15, metric 22

> to 10.0.21.2 via ge-1/0/4.21
to 10.0.20.2 via ge-1/0/4.20
20.20.1.0/24 *[IS-IS/165] 00:04:15, metric 22
> to 10.0.21.2 via ge-1/0/4.21
to 10.0.20.2 via ge-1/0/4.20
20.20.2.0/24 *[IS-IS/165] 00:04:15, metric 22
> to 10.0.21.2 via ge-1/0/4.21
to 10.0.20.2 via ge-1/0/4.20
20.20.3.0/24 *[IS-IS/165] 00:04:15, metric 22
> to 10.0.21.2 via ge-1/0/4.21
to 10.0.20.2 via ge-1/0/4.20
lab@mxB-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
policy-statement level1-to-level2] hierarchy. Configure the policy to
accept all IS-IS Level 2 routes into Level 1.

[edit]
lab@mxB-1# edit policy-options policy-statement level2-to-level1
[edit policy-options policy-statement level2-to-level1]

lab@mxB-1# set term 1 from protocol isis

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



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

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

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

lab@mxB-1#
Step 3.14
hierarchy and apply the policy named level2-to-level1, as an export policy.

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

commit complete
lab@mxB-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 routing table. Use the show route 192.168.0.0/16
table R5-z command to display the routes in the R5 routing table.
lab@mxB-1> show route 192.168.0.0/16 table R5-z

192.168.20.1/32 *[IS-IS/18] 00:05:47, metric 20

to 10.0.23.1 via ge-1/1/5.23
> to 10.0.22.1 via ge-1/1/5.22
192.168.20.2/32 *[IS-IS/15] 22:23:47, metric 10
> to 10.0.22.1 via ge-1/1/5.22
192.168.20.3/32 *[IS-IS/15] 22:23:25, metric 10
> to 10.0.23.1 via ge-1/1/5.23
192.168.20.4/32 *[Direct/0] 22:24:03
> via lo0.3
192.168.21.1/32 *[IS-IS/18] 00:05:47, metric 40
> to 10.0.23.1 via ge-1/1/5.23
to 10.0.22.1 via ge-1/1/5.22
192.168.21.2/32 *[IS-IS/18] 00:05:47, metric 50
to 10.0.23.1 via ge-1/1/5.23
> to 10.0.22.1 via ge-1/1/5.22
192.168.21.3/32 *[IS-IS/18] 00:05:47, metric 50
> to 10.0.23.1 via ge-1/1/5.23
to 10.0.22.1 via ge-1/1/5.22
192.168.21.4/32 *[IS-IS/18] 00:05:47, metric 60
> to 10.0.23.1 via ge-1/1/5.23
to 10.0.22.1 via ge-1/1/5.22
192.168.100.1/32 *[IS-IS/18] 00:05:47, metric 30
to 10.0.23.1 via ge-1/1/5.23
> to 10.0.22.1 via ge-1/1/5.22
lab@mxB-1>

Question: Have the Level 2 routes been leaked into
the Level 1 database and installed in the R5 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 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 R5-z command to
locate the R3 LSP-ID in the Level 1 IS-IS database.
1921.6802.0002.00-00 0x6a 0xbc4a 400 L1 L2 Attached
1921.6802.0003.00-00 0x68 0x13f0 400 L1 L2 Attached
1921.6802.0004.00-00 0x69 0x9a07 402 L1 L2
1921.6802.0004.02-00 0x67 0x8380 402 L1 L2
1921.6802.0004.03-00 0x66 0xc43d 402 L1 L2
5 LSPs
lab@mxB-1>
Question: What is the LSP-ID of the primary LSP for

the R3 router?
Answer: The primary LSP-ID of the R3 router is

1921.6802.0002.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
1921.680x.y002.00-00 extensive instance R5-z | find tlv
command to display the TLVs in the R3 LSP.
lab@mxB-1> show isis database level 1 1921.680x.y002.00-00 extensive instance
R5-z | find tlv
TLVs:
Speaks: IP
Speaks: IPV6

Hostname: mxB-1
IP prefix: 10.0.21.0/24, Internal, Metric: default 20, Down
IP extended prefix: 10.0.21.0/24 metric 20 down
lab@mxB-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 the prevent
routing loops. IS-IS Level 1 Type 128 TLVs with the
down bit set are never leaked into the Level 2
database as a loop detection mechanism.


Lab 7
BGP (Detailed)
Overview
In this lab, you will be using 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

10.a.10.3R1.9
Note
The BGP 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-z, where z is
the user number (1 or 2). Refer to the lab
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. A reset
file named ajspr-lab7-reset-mx_ has been created to help you load the OSPF
topology. The mx_ within the reset file name references the assigned student
Step 1.1
Ensure you know to which device you are assigned. Check with your instructor if
necessary. Change all the x values on the Lab 7 diagram to reflect the correct value.
This step helps avoid any confusion during the configuration steps throughout the
lab.
Step 1.2
Access the command-line interface (CLI) at your station using either the console,
Step 1.3
mxA-1 (ttyp0)
login: lab
Password:
---JUNOS 10.3R1.9 built 2010-08-13 12:48:29 UTC

lab@mxA-1>
Lab 7–2 • BGP (Detailed) www.juniper.net

Step 1.4
Use the load override command to load the Lab 7 reset file. The reset file is
named ajspr-lab7-reset-mx_.config located in the /var/tmp directory.
After loading the file, commit the configuration and return to operational mode.
[edit]
load complete
[edit]
commit complete
lab@mxB-1>
Step 1.5
Use the operational mode command show configuration to view the active
configuration.
version 10.3R1.9;
/* AJSPR Lab-7 reset configuration file */
system {
host-name mxB-1;
ssh-dsa "ssh-dss
SECRET-DATA
}
login {
user lab {
uid 2000;
class super-user;
authentication {
SECRET-DATA
}
}
}
services {

ftp;
ssh;
telnet;
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
}
}
}
chassis {
fpc 1 {
pic 0 {
tunnel-services {
bandwidth 1g;
}
}
}
}
interfaces {
ge-1/0/0 {
vlan-tagging;
unit 1121 {
description "Connection to P1";
vlan-id 1121;
family inet {
address 172.22.121.1/24;
}
}
unit 1123 {
vlan-id 1123;
family inet {
address 172.22.123.1/24;
}
}
unit 1125 {
vlan-id 1125;
family inet {
address 172.22.125.1/24;
}
}
}
ge-1/0/4 {
vlan-tagging;
unit 20 {
description "connection to R3";

vlan-id 20;
family inet {
address 10.0.20.1/24;
}
}
}
ge-1/1/4 {
vlan-tagging;
unit 20 {
description "connection to mxB1";
vlan-id 20;
family inet {
address 10.0.20.2/24;
}
}
}
fxp0 {
unit 0 {
family inet {
address 10.210.15.3/27;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.20.1/32;
}
family iso {
address 49.0001.1921.6802.0001.00;
}
}
unit 1 {
family inet {
address 192.168.20.2/32;
}
family iso {
address 49.0001.1921.6802.0002.00;
}
}
}
}
routing-options {
static {
route 192.168.20.0/26 reject;
route 192.168.20.64/26 reject;
}
}
protocols {
isis {
level 1 disable;
interface lo0.0;
}

ospf {
area 0.0.0.0 {
interface lo0.0;
}
}
}
routing-instances {
R3-1 {
interface lo0.1;
routing-options {
static {
route 192.168.20.128/26 reject;
route 192.168.20.192/26 reject;
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lo0.1;
}
}
isis {
level 1 disable;
interface lo0.1;
}
}
}
}
lab@mxB-1>
Step 1.6
Use the show ospf interface command to verify that the interfaces are
running OSPF.
ge-1/0/4.20 BDR 0.0.0.0 192.168.20.2 192.168.20.1 1
lo0.0 DR 0.0.0.0 192.168.20.1 0.0.0.0 0
lab@mxB-1>
Question: With how many neighbors does interface

ge-1/0/4.xy have adjacencies?
Answer: There should only be 1.

Step 1.7
Use the show ospf neighbor command to verify that the default routing
instance has an adjacency with the R3 instance.
10.0.20.2 ge-1/0/4.20 Full 192.168.20.2 128 38
lab@mxB-1>
Question: Which neighbor state is shown for the

ge-1/0/4.xy interface?
Answer: The neighbor state for the ge-1/0/4.xy

interface should be Full, as shown in the sample
output. If the state is not Full, check with your
instructor.
Step 1.8
Use the ping utility to verify reachability to the three routers. Remember to use the
routing-instance command for the P3 device.
lab@mxB-1> ping 172.22.1xy.2 rapid count 10
PING 172.22.121.2 (172.22.121.2): 56 data bytes
!!!!!!!!!!
--- 172.22.121.2 ping statistics ---
lab@mxB-1> ping 172.22.1xy.2 rapid count 10

PING 172.22.123.2 (172.22.123.2): 56 data bytes
!!!!!!!!!!
--- 172.22.123.2 ping statistics ---
lab@mxB-1> ping 172.22.1xy.2 rapid count 10 routing-instance R3-z

PING 172.22.125.2 (172.22.125.2): 56 data bytes
!!!!!!!!!!
--- 172.22.125.2 ping statistics ---
lab@mxB-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.9
Use the show route table inet.0 command to display the default routing
table.
lab@mxB-1> show route table inet.0

10.0.20.0/24 *[Direct/0] 5w2d 22:31:09

> via ge-1/0/4.20
10.0.20.1/32 *[Local/0] 5w3d 17:34:15
10.210.15.0/27 *[Direct/0] 13w2d 13:03:24
> via fxp0.0
10.210.15.3/32 *[Local/0] 13w2d 13:03:24
Local via fxp0.0
172.22.121.0/24 *[Direct/0] 5w3d 17:34:15
> via ge-1/0/0.1121
172.22.121.1/32 *[Local/0] 5w3d 17:34:15
172.22.123.0/24 *[Direct/0] 5w3d 17:34:15
> via ge-1/0/0.1123
172.22.123.1/32 *[Local/0] 5w3d 17:34:15
192.168.20.0/26 *[Static/5] 04:01:17
Reject
192.168.20.1/32 *[Direct/0] 5w3d 17:19:55
> via lo0.0
192.168.20.2/32 *[OSPF/10] 1d 18:16:18, metric 1
> to 10.0.20.2 via ge-1/0/4.20
192.168.20.64/26 *[Static/5] 04:01:17
Reject
224.0.0.5/32 *[OSPF/10] 1d 18:17:09, metric 1
MultiRecv
lab@mxB-1>

Question: Are the two loopback addresses active in
the default routing table?
Answer: Yes. The loopback addresses are active in

the default routing table. The R3 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 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.
First, enter configuration mode and navigate to the [edit routing-options]
and configure the AS number for the default routing instance.
[edit]
lab@mxB-1# edit routing-options
[edit routing-options]
lab@mxB-1# set autonomous-system 6500x
lab@mxB-1#
Step 2.2
Navigate to the [edit routing-instance R3-z routing-options]
hierarchy and configure the same AS number for the R3-z routing instance.
lab@mxB-1# top edit routing-instances R3-z routing-options


lab@mxB-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 R3’s loopback address.
Refer to the network diagram for this lab as necessary.
lab@mxB-1# top edit protocols bgp
[edit protocols bgp]

lab@mxB-1# set group ibgp type internal

lab@mxB-1# set group ibgp local-address 192.168.xy.1

lab@mxB-1# set group ibgp neighbor 192.168.xy.2

lab@mxB-1#
Step 2.4
Navigate to the [edit routing-instance R3-z protocols bgp]
hierarchy and configure a BGP group named ibgp that establishes an IBGP peering
session with the default routing instance. Commit the configuration and return to
operational mode.
lab@mxB-1# top edit routing-instances R3-z protocols bgp
[edit routing-instances R3-1 protocols bgp]

lab@mxB-1# set group ibgp type internal

lab@mxB-1# set group ibgp local-address 192.168.xy.2

lab@mxB-1# set group ibgp neighbor 192.168.xy.1

commit complete
lab@mxB-1>
Step 2.5
Use the show bgp summary command to verify that the IBGP session has been
established.

lab@mxB-1> 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...
192.168.20.1 65001 9 9 0 0 2:53 Establ
R3-1.inet.0: 0/0/0/0
192.168.20.2 65001 8 9 0 0 2:53 0/0/0/
0 0/0/0/0
lab@mxB-1>
Question: Is the IBGP session established? Are

there 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
advertised at this time.
Step 2.6
Locate the two static routes in the each of the routing instances using the show
route protocol static command.
lab@mxB-1> show route protocol static

192.168.20.0/26 *[Static/5] 05:01:21

Reject
192.168.21.64/26 *[Static/5] 05:01:21
Reject

192.168.20.128/26 *[Static/5] 05:01:21

Reject
192.168.20.192/26 *[Static/5] 05:01:21
Reject

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@mxB-1>
Question: Identify the two static routes in each

routing instance.
Answer: The two static routes in each routing

instance summarizes into 192.168.x.0/25 for
inet.0 and 192.168.xy.128/25 in table R3-z.
Step 2.7
Enter configuration mode and create a policy named redistribute-statics.
redistribute-statics] hierarchy and configure the policy to accept all static
routes.
[edit]
lab@mxB-1# edit policy-options policy-statement redistribute-statics
[edit policy-options policy-statement redistribute-statics]

lab@mxB-1# set term 1 from protocol static


lab@mxB-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. Commit the configuration and return to operational mode.

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


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

commit complete
lab@mxB-1>
Step 2.9
Use the 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
192.168.20.1 65001 380 380 0 0 2:50:33 Establ
R3-1.inet.0: 2/2/2/0
192.168.20.2 65001 379 380 0 0 2:50:33 2/2/2/
0 0/0/0/0
lab@mxB-1>
Question: How many routes are being advertised?

How many routes are active?
Answer: Each peer should be advertising 2 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
Enter configuration mode and navigate to the [edit protocols bgp]
hierarchy. Configure a BGP group named P1-P2 that establishes an EBGP peering
session with the P1 and P2 routers. Refer to the network diagram for this lab as
necessary. Commit the configuration and return to the operational mode.
[edit]
lab@mxB-1# edit protocols bgp

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

lab@mxB-1# set group P1-P2 neighbor 172.22.1xy.2

lab@mxB-1# set group P1-P2 neighbor 172.22.1xy.2

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

commit complete
lab@mxB-1>
Step 3.2
Use the 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.22.121.2 65412 20 21 0 0 8:07 4/4/4/
0 0/0/0/0
172.22.123.2 65412 20 21 0 0 8:03 0/4/4/
0 0/0/0/0
192.168.20.1 65001 469 469 0 0 3:30:30 Establ
R3-1.inet.0: 2/6/6/0
192.168.20.2 65001 468 469 0 0 3:30:30 2/2/2/
0 0/0/0/0
lab@mxB-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. If the peers are not established, check
your configuration or consult your instructor. Each
EBGP peer should be receiving 4 routes.

Step 3.3
The BGP neighbor command has a lot of valuable information. Use the show
bgp neighbor 172.22.1xy.2 command to view the EBGP peer.
lab@mxB-1> show bgp neighbor 172.22.1xy.2
Peer: 172.22.121.2+179 AS 65412 Local: 172.22.121.1+60170 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: 192.168.100.1 Local ID: 192.168.20.1 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
Local Interface: ge-1/0/0.1121
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: 4
Received prefixes: 4
Accepted prefixes: 4
Suppressed due to damping: 0
Advertised prefixes: 2
Last traffic (seconds): Received 2 Sent 25 Checked 77
Input messages: Total 165 Updates 2 Refreshes 0 Octets 3179
Output messages: Total 169 Updates 1 Refreshes 0 Octets 3306
Output Queue[0]: 0
lab@mxB-1>
Question: On which TCP port is the peer established

on? On which TCP port is the local peer established
on?
Answer: As seen in the output above, the peer is

established to TCP port 179 and the local peer is
established to port 60170.

Question: Which peer established this session?
Answer: In the example the local peer established

the session. The local router initiated the TCP
session by sending a TCP sync to 172.22.121.2 port
179 from 172.22.121.1 port 60170.
Step 3.4
Use the show route received-protocol bgp 172.22.1xy.2 command
to view the routes being received from the P1 and P2 routers. Refer to the network
diagram for this lab as necessary.
lab@mxB-1> show route receive-protocol bgp 172.22.1xy.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

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
lab@mxB-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 show route 30.30.0.0/24 detail
command.
lab@mxB-1> 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: 583
Next-hop reference count: 12
Source: 172.22.121.2
Next hop: 172.22.121.2 via ge-1/0/0.1121, selected
State: <Active Ext>
Local AS: 65001 Peer AS: 65412
Age: 1:42:17
Task: BGP_65412.172.22.121.2+179
Announcement bits (3): 0-KRT 6-BGP RT Background 7-Resolve tree
AS path: 65412 I
Accepted
Localpref: 100
Router ID: 192.168.100.1
BGP Preference: 170/-101
Next hop type: Router
Source: 172.22.123.2
State: <NotBest Ext>
Inactive reason: Not Best in its group - Active preferred
Age: 1:42:13
Task: BGP_65412.172.22.123.2+179
AS path: 65412 I
Accepted
Localpref: 100
Router ID: 192.168.101.1
lab@mxB-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.
Step 3.6
Use the BGP multipath option to install the P1 and P2 routes with two equal cost
paths. Enter configuration mode and navigate to the [edit protocols bgp]
hierarchy and configure multipath in the P1-P2 group. Commit the configuration and
return to operational mode.
[edit]

lab@mxB-1# set group P1-P2 multipath

commit complete
lab@mxB-1>
Step 3.7
Display the 30.30.0.0/24 route again using the show route 30.30.0.0/24
detail command.
lab@mxB-1> show route 30.30.0.0/24 detail

Source: 172.22.121.2
Next hop: 172.22.123.2 via ge-1/0/0.1123
State: <Active Ext>
Age: 16:21:59
Task: BGP_65412.172.22.121.2+179

AS path: 65412 I
Accepted Multipath
Localpref: 100
Router ID: 192.168.100.1
Source: 172.22.123.2
Age: 16:21:55
Task: BGP_65412.172.22.123.2+179
AS path: 65412 I
Accepted
Localpref: 100
Router ID: 192.168.101.1
lab@mxB-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: There are two next hops for the

30.30.0.0/24.
Step 3.8
Use the show route forwarding-table destination 30.30.0.0/24
command to view the packet forwarding table.

lab@mxB-1> 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.121.2 ucst 583 6 ge-1/0/0.1121
Routing table: default-switch.inet

Internet:
default perm 0 rjct 519 1
Routing table: __master.anon__.inet

Internet:
Routing table: R3-1.inet

Internet:
lab@mxB-1>
Question: Are the two routes to P1 and P2 installed

in the packet forwarding table?
Answer: No. Only one route is installed in the packet

forwarding table. The default forwarding behavior
for two or more equal cost routes is to randomly
pick one to be installed in the forwarding table. In
this example, the route is using the P1 interface for
the 30.30.0.0/24 route.
Step 3.9
policy-statement pfe-load-balance] hierarchy. Create a policy named
pfe-load-balance, that only load balances the routes being received from the
P1 and P2 routers as displayed in Step 3.4.
[edit]
lab@mxB-1# edit policy-options policy-statement pfe-load-balance
[edit policy-options policy-statement pfe-load-balance]

lab@mxB-1# set term 1 from protocol bgp


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

lab@mxB-1# show
term 1 {
from {
protocol bgp;
}
then {
load-balance per-packet;
}
}
Step 3.10
After configuring the pfe-load-balance policy, apply it as an export policy under
the [edit routing-options forwarding-table] hierarchy. Commit the
changes and return to operational mode.
lab@mxB-1# top edit routing-options forwarding-table
[edit routing-options forwarding-table]

lab@mxB-1# set export pfe-load-balance
[edit routing-options forwarding-table]

commit complete
lab@mxB-1>
Step 3.11
Use the show route forwarding-table destination 30.30.0.0/24
command to verify that the forwarding table now has two next-hop interfaces for the
30.30.0.0/24 route.
lab@mxB-1> show route forwarding-table destination 30.30.0.0/24
Routing table: default.inet
Internet:
30.30.0.0/24 user 0 ulst 1048576 5
172.22.121.2 ucst 583 3 ge-1/0/0.1121
172.22.123.2 ucst 582 4 ge-1/0/0.1123
Routing table: default-switch.inet

Internet:

Routing table: __master.anon__.inet
Internet:
Routing table: R3-1.inet

Internet:
lab@mxB-1>
Question: Is the forwarding table using both

next-hop interfaces to reach the 30.30.0.0/24
route?
Answer: Yes, the forwarding table now has two

next-hop interfaces for the 30.30.0.0/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 routing instance to EBGP peer with the P3
router. The peering is between the loopback interfaces of R3 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
Enter configuration mode and navigate to the [edit routing-instance R3-z
routing-options] hierarchy. Configure a static route to the 192.168.102.1
loopback address with a next hop of 172.22.1xy.2. Ensure that the route can
not be redistributed into other protocols and commit the configuration and return to
operational mode.
[edit]
lab@mxB-1# edit routing-instances R3-z routing-options

lab@mxB-1# set static route 192.168.102.1 next-hop 172.22.1xy.2

lab@mxB-1# set static route 192.168.102.1 no-readvertise


commit complete
lab@mxB-1>
Step 4.2
Use the ping utility to verify that connectivity between the loopback addresses has
been established.
lab@mxB-1> ping 192.168.102.1 source 192.168.2z.2 count 5 routing-instance R3-z
PING 192.168.102.1 (192.168.102.1): 56 data bytes
--- 192.168.102.1 ping statistics ---

lab@mxB-1>
Question: Is the ping successful?
Answer: The ping should be successful. If they are

not successful verify that your configuration and
consult you instructor.
Step 4.3
Enter configuration mode and navigate to the [edit routing-instance R3-z
protocols bgp] hierarchy. Configure a BGP group named P3. Configure the P3
loopback address as the peer and the R3 loopback address as the local-address.
The peer-as is 65020. Commit the configuration and return to operational mode.
[edit]
lab@mxB-1# edit routing-instance R3-z protocols bgp

lab@mxB-1# set group P3 type external

lab@mxB-1# set group P3 local-address 192.168.xy.2

lab@mxB-1# set group P3 neighbor 192.168.102.1


lab@mxB-1# set group P3 neighbor 192.168.102.1 peer-as 65020

commit complete
lab@mxB-1>
Step 4.4
Check the state of the EBGP session using the show bgp summary command.
inet.0 11 10 0 0 0 0
172.22.121.2 65412 3062 3125 0 0 23:38:22 4/4/4/
0 0/0/0/0
172.22.123.2 65412 3061 3124 0 0 23:38:18 4/4/4/
0 0/0/0/0
192.168.20.1 65001 3573 3574 0 0 1d 3:00:45 Establ
R3-1.inet.0: 2/6/6/0
192.168.20.2 65001 3573 3573 0 0 1d 3:00:45 2/3/3/
0 0/0/0/0
192.168.102.1 65020 0 0 0 0 2:20 Idle
lab@mxB-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
R3-z protocols bgp] hierarchy. 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 and
[edit]
lab@mxB-1# edit routing-instances R3-z protocols bgp


lab@mxB-1# set group P3 multihop

commit complete
lab@mxB-1>
Step 4.6
Check the status of the P3 session with the show bgp summary command.
inet.0 15 10 0 0 0 0
172.22.121.2 65412 3135 3199 0 0 1d 0:12:25 4/4/4/
0 0/0/0/0
172.22.123.2 65412 3135 3199 0 0 1d 0:12:21 4/4/4/
0 0/0/0/0
192.168.20.1 65001 3647 3649 0 0 1d 3:34:48 Establ
R3-1.inet.0: 2/6/6/0
192.168.20.2 65001 3648 3647 0 0 1d 3:34:48 2/7/7/
0 0/0/0/0
192.168.102.1 65020 3 4 0 0 4 Establ
R3-1.inet.0: 4/4/4/0
lab@mxB-1>
Question: What is the state of the P3 peering

session after the multihop command is
configured?
Answer: The P3 peering session should be

established. f 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 show route
receive-protocol bgp 192.168.102.1 command to view the routes being
received from the P3 router.
lab@mxB-1> show route receive-protocol bgp 192.168.102.1

* 40.40.0.0/24 192.168.102.1 65020 I
* 40.40.1.0/24 192.168.102.1 65020 I
* 40.40.2.0/24 192.168.102.1 65020 I
* 40.40.3.0/24 192.168.102.1 65020 I
lab@mxB-1>
Question: Are routes being received from the P3

peering session?
Answer: Yes. Four 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 mx_-1 aggregate route is 192.168.20.0/24 and the mx_-2
aggregate route is 192.168.21.0/24 for both the default and R3 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 192.168.xy.0/24.
[edit]
lab@mxB-1#
Step 5.2
Configure the same aggregate route in the [edit routing-instances R3-z
routing-options] hierarchy.
lab@mxB-1# top edit routing-instances R3-z routing-options



lab@mxB-1#
Step 5.3
policy-statement export-aggregate] hierarchy. Create a routing policy
that will advertise the aggregate route and suppress the more specific routes.
lab@mxB-1# top edit policy-options policy-statement export-aggregate
[edit policy-options policy-statement export-aggregate]

lab@mxB-1# set term 1 from protocol aggregate





lab@mxB-1# show
term 1 {
from {
protocol aggregate;
route-filter 192.168.xy.0/24 exact;
}
then accept;
}
term 2 {
from {
route-filter 192.168.xy.0/24 longer;
}
then reject;
}

lab@mxB-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@mxB-1# set group P1-P2 export export-aggregate

lab@mxB-1#
Step 5.5
Navigate to the [edit routing-options R3-z protocols bgp]
hierarchy. Apply the export-aggregate policy as an export policy for the P3
group. Commit the configuration and return to operational mode.

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

commit complete
lab@mxB-1>
Step 5.6
Using the show route advertising-protocol bgp 192.168.10x.1
operational mode command, substitute each of the peer’s IP addresses to view the
routes being advertised to each of the peer routers.
lab@mxB-1> show route advertising-protocol bgp 172.22.121.2

* 192.168.20.0/24 Self I

* 192.168.20.0/24 Self I

* 192.168.20.0/24 Self I
lab@mxB-1>

Question: Is the summary route the only route being
advertised?
Answer: Yes. Only the summary route is being

advertised. If more or less routes are being
advertised check your policy or consult your
instructor.


Lab 8
BGP Attributes: Next Hop, Origin, MED and AS Path (Detailed)
Overview
In this lab, you will be using 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 External Border Gateway Protocol (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
The BGP topology will require you to display
information in the different virtual routing instances.
commands will include the routing instance name,
R3-z, where z 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-z switch must be used
to consult the appropriate virtual instance. When
performing show commands the instance
R3-z or table R3-z switch needs to be used to
display the appropriate adjacencies or routing
tables.
www.juniper.net BGP Attributes: Next Hop, Origin, MED and AS Path (Detailed) • Lab 8–1
10.a.10.3R1.9
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, an IBGP export policy is necessary to change the next-hop attribute. After
applying the IBGP export policy, verify that the routes are now active in the two
routing tables.
Step 1.1
Ensure you know what device you are assigned. Check with your instructor if
value. This will help avoid any confusion during the configuration steps throughout
the lab.
Step 1.2
Step 1.3
mxA-1 (ttyp0)
login: lab
Password:
---JUNOS 10.3R1.9 built 2010-08-13 12:48:29 UTC

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@mxB-1> show route hidden table inet.0

40.40.0.0/24 [BGP/170] 3d 12:19:07, localpref 100, from 192.168.20.2

AS path: 65020 I
Unusable
AS path: 65020 I
Unusable
AS path: 65020 I
Unusable
AS path: 65020 I
Unusable
Lab 8–2 • BGP Attributes: Next Hop, Origin, MED and AS Path (Detailed) www.juniper.net
AS path: 65020 65002 I
Unusable
lab@mxB-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
192.168.20.2.
Step 1.5
The hidden routes are all marked as Unusable. Use the show route
40.40.0.0/24 hidden detail command to determine the reason this route
is unusable.
lab@mxB-1> show route 40.40.0.0/24 hidden detail

40.40.0.0/24 (1 entry, 0 announced)
Next hop type: Unusable
State: <Hidden Int Ext>
Age: 3d 12:29:09
Task: BGP_65001.192.168.20.2+179
AS path: 65020 I
Accepted
Localpref: 100
Router ID: 192.168.20.2
lab@mxB-1>
Question: Does the detail route output give any clue

as to the reason this route is unusable?
Answer: The detail route output simply defines the

Next hop type as Unusable but doesn’t give any clue
as to why the route is unusable.
Step 1.6
Since the detail route output didn't help in determining the reason that these routes
are hidden, use the show route 40.40.0.0/24 hidden extensive
command to display more information about the hidden route.
lab@mxB-1> show route 40.40.0.0/24 hidden extensive

Age: 3d 12:39:17
Task: BGP_65001.192.168.20.2+179
AS path: 65020 I
Accepted
Localpref: 100
Router ID: 192.168.20.2
Indirect next hops: 1
Protocol next hop: 192.168.102.1
Indirect next hop: 0 -
lab@mxB-1>
Question: What is the BGP next-hop attribute for

this route?
Answer: In this example, the Protocol next hop is

192.168.102.1.
Question: Since IBGP does not modify any attributes

by default, which EBGP peer advertised this route?
Answer: The BGP next-hop is the loopback address

of the P3 router.
Step 1.7
In the BGP route selection process, the BGP next-hop attribute must be resolved in
the default routing table. Use the show route 192.168.102.1 table
inet.0 command to verify that the protocol next-hop can be resolved.
lab@mxB-1> show route 192.168.102.1 table inet.0
lab@mxB-1>
Question: Can the BGP next-hop address be

resolved in the default routing table?
Answer: It appears that the BGP next-hop address

can not be resolved in the default routing table and
therefore the route is marked as unusable.
Step 1.8
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. Create the policy called next-hop-self to 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@mxB-1# edit policy-options policy-statement next-hop-self
[edit policy-options policy-statement next-hop-self]


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

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

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

lab@mxB-1#
Step 1.9
Navigate to the [edit routing-instances R3-z protocols bgp]
hierarchy and apply the next-hop-self export policy in the ibgp group. Since
the hidden routes in the default routing table are being advertised from the R3
routing instance, the IBGP export policy must be applied in the R3 routing instance.

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

commit complete
lab@mxB-1>
Step 1.10
Use the show route hidden command to verify that all routes are active and
usable.
lab@mxB-1> 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@mxB-1>
Question: Have all the hidden routes disappeared?
Answer: No. There are still hidden routes in the R3

routing table that were advertised from the default
routing instance.
Step 1.11
hierarchy. Apply the next-hop-self export policy to the ibgp group in the
default routing instance. Commit the changes and return to operational mode.
[edit]

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

commit complete
lab@mxB-1>
Step 1.12
Again use the show route hidden command to verify that all of the hidden
routes are gone from both routing tables.
lab@mxB-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. Since 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
hierarchy. Since the BGP origin attribute can influence traffic, it will be necessary to
remove the multipath command from the BGP group P1-P2. This 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 and return to operational mode.
[edit]

lab@mxB-1# delete group P1-P2 multipath

commit complete
lab@mxB-1>
Step 2.2
Use the show route receive-protocol bgp 172.22.1xy.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 for 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
* 192.168.21.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
192.168.21.0/24 172.22.123.2 65412 65002 I
lab@mxB-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 5 active routes and the P2 peer has
no active route.
Step 2.3
In the default routing table, display your partner’s summary route. Use the show
route 192.168.xy.0/24 table inet.0 detail command to see the
detail routing information in the default routing instance.
lab@mxB-1> show route 192.168.xy.0/24 table inet.0 detail

Source: 172.22.121.2
State: <Active Ext>
Age: 1:41:04
Task: BGP_65412.172.22.121.2+179
AS path: 65412 65002 I Aggregator: 65002 192.168.21.1
Accepted
Localpref: 100
Router ID: 192.168.100.1
Source: 172.22.123.2
Age: 12:02
Task: BGP_65412.172.22.123.2+49691
Accepted
Localpref: 100
Router ID: 192.168.101.1
Next hop type: Indirect
Source: 192.168.20.2
Indirect next hop: 28124b0 1048575
State: <Int Ext>
Inactive reason: Interior > Exterior > Exterior via Interior
Age: 1:41:04 Metric2: 1
Task: BGP_65001.192.168.20.2+179
Accepted
Localpref: 100
Router ID: 192.168.20.2
lab@mxB-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.
Question: Which peer is being preferred to activate

the route?
Answer: The P1 peer is being preferred because

EBGP routes are always preferred over IBGP routes
and the P1 router-ID is lower than the P2 router-ID.
Step 2.4
policy-statement P1-P2-import] hierarchy. Using the BGP origin attribute,
change the preferred outbound path for the summary route to the R3 IBGP
advertisement. Create a EBGP import policy to change the origin to EGP on the
summary route being received from P1 and P2.
[edit]
lab@mxB-1# edit policy-options policy-statement P1-P2-import
[edit policy-options policy-statement P1-P2-import]



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

lab@mxB-1# show
term 1 {
from {
protocol bgp;
}
then origin egp;
}
lab@mxB-1#
Step 2.5
Navigate to the [edit protocols bgp] hierarchy and apply the
P1-P2-import policy as an import policy to the P1-P2 group. Commit the
changes and return to operational mode.

lab@mxB-1# set group P1-P2 import P1-P2-import

commit complete
lab@mxB-1>
Step 2.6
Use the show route 192.168.xy.0/24 table inet.0 detail command
to display the detailed routing information in the default routing instance.
lab@mxB-1> show route 192.168.21.0/24 table inet.0 detail

Source: 192.168.20.2
Indirect next hop: 28124b0 1048575
State: <Active Int Ext>
Age: 2:22:22 Metric2: 1
Task: BGP_65001.192.168.20.2+179
Accepted
Localpref: 100
Router ID: 192.168.20.2
Source: 172.22.121.2
State: <Ext>
Inactive reason: Origin
Age: 2:22:22
Task: BGP_65412.172.22.121.2+179
AS path: 65412 65002 E Aggregator: 65002 192.168.21.1
Accepted
Localpref: 100
Router ID: 192.168.100.1
Source: 172.22.123.2
Inactive reason: Not Best in its group - Router ID
Age: 53:20
Task: BGP_65412.172.22.123.2+49691
AS path: 65412 65002 E Aggregator: 65002 192.168.21.1
Accepted
Localpref: 100
Router ID: 192.168.101.1
lab@mxB-1>
Question: Which peer is now being preferred to

activate the route? Why?
Answer: The R3 router is now the preferred BGP

peer because of the origin.
Step 2.7
hierarchy. Remove the import policy from the P1-P2 group and commit the change.
Return to operational mode.
[edit]

lab@mxB-1# delete group P1-P2 import

commit complete
lab@mxB-1>
Step 2.8
Use the operational mode command show route 192.168.xy.0/24 table
inet.0 to verify that the route again prefers the P1 peer in the default routing
instance.

192.168.21.0/24 *[BGP/170] 02:50:40, localpref 100

AS path: 65412 65002 I
> to 172.22.121.2 via ge-1/0/0.1121
[BGP/170] 01:21:38, localpref 100
AS path: 65412 65002 I
> to 172.22.123.2 via ge-1/0/0.1123
[BGP/170] 02:50:40, localpref 100, from 192.168.20.2
AS path: 65020 65002 I
> to 10.0.20.2 via ge-1/0/4.20
lab@mxB-1>
Question: Did the preferred path return to the P1

peer?
Answer: Yes. The origin is now the same on all three

routes and the Best in Group path is through P1.
Part 3: Configuring the MED Attribute
In this lab part, you will configure the Multiple Exit Discriminator (MED) attribute.
The MED is an optional non-transitive 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
Use the telnet utility to log in to your partner's student device using the loopback
address. The telnet session must be sourced from your loopback address.
lab@mxB-1> telnet 192.168.xy.1 source 192.168.xy.1
Trying 192.168.21.1...
mxB-2 (ttyp0)
login: lab
Password:
--- JUNOS 10.3R1.9 built 2010-08-13 12:48:28 UTC

lab@mxB-2>
Step 3.2
inet.0 to display the path of your summary route in the default routing instance.

192.168.20.0/24 *[BGP/170] 3d 03:54:48, localpref 100

AS path: 65412 65001 I
> to 172.22.124.2 via ge-1/0/0.1124
[BGP/170] 3d 03:54:45, localpref 100
AS path: 65412 65001 I
> to 172.22.122.2 via ge-1/0/0.1122
AS path: 65020 65001 I
> to 10.0.24.2 via ge-1/0/4.24
lab@mxB-2>
Question: What is the preferred path of your

summary route through AS 65412?
Answer: In this example, the active path of the

summary route is through the P2 router.
Step 3.3
Exit from your partner’s 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 and return to operational mode.
lab@mxB-2> exit
[edit]

lab@mxB-1# set group P1-P2 neighbor 172.22.1xy.2 metric-out 10

commit complete
lab@mxB-1>
Step 3.4
Trying 192.168.21.1...
mxB-2 (ttyp0)
login: lab
Password:
--- JUNOS 10.3R1.9 built 2010-08-13 12:48:28 UTC

lab@mxB-2>
Step 3.5

192.168.20.0/24 *[BGP/170] 1w0d 06:55:19, localpref 100

AS path: 65412 65001 I
> to 172.22.124.2 via ge-1/0/0.1124
[BGP/170] 1w0d 06:55:16, localpref 100
AS path: 65412 65001 I
> to 172.22.122.2 via ge-1/0/0.1122
[BGP/170] 4d 07:23:27, localpref 100, from 192.168.21.2
AS path: 65020 65001 I
> to 10.0.24.2 via ge-1/0/4.24
lab@mxB-2>
Question: What is the preferred path of your

summary route through AS 65412?
Answer: In this example, the active path of the

summary route is through the P2 router.
Step 3.6
Use the traceroute utility, to verify the path from your partner’s default routing
instance to your loopback address. The traceroute session must be sourced from
your partner’s loopback address.
lab@mxB-2> traceroute 192.168.xy.1 source 192.168.xy.1
traceroute to 192.168.20.1 (192.168.20.1) from 192.168.21.1, 30 hops max, 40
byte packets
1 172.22.124.2 (172.22.124.2) 0.349 ms 0.271 ms 0.244 ms
2 192.168.20.1 (192.168.20.1) 0.368 ms 0.357 ms 0.350 ms
lab@mxB-2>
Question: Which router is the traceroute using to

reach your student device? Why?
Answer: The path is through the P2 router. Since

the MED has been set to 10 before sending the
summary route to the P1 router, the preferred path
is through the P2 router. The lack of a MED value in
the BGP update being sent to the P2 router, is
interpreted as a value of zero and therefore a lower
value than the P1 router.
Step 3.7
the [edit policy-options] hierarchy. Copy the export-aggregate policy
to a new policy called export-p2. Display the new policy with the show
command.
lab@mxB-2> quit
[edit]
lab@mxB-1# edit policy-options
[edit policy-options]
lab@mxB-1# copy policy-statement export-aggregate to policy-statement export-p2
lab@mxB-1# show policy-statement export-p2
term 1 {
from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
}
then reject;
}
lab@mxB-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@mxB-1# edit policy-statement export-p2
[edit policy-options policy-statement export-p2]

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

lab@mxB-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@mxB-1# top edit protocols bgp group P1-P2
[edit protocols bgp group P1-P2]

lab@mxB-1# set neighbor 172.22.12x.2 export export-p2

commit complete
lab@mxB-1>
Step 3.10
Trying 192.168.21.1...
mxB-2 (ttyp0)
login: lab
Password:
--- JUNOS 10.3R1.9 built 2010-08-13 12:48:28 UTC

lab@mxB-2>
Step 3.11
Use the traceroute utility, to verify the path from your partner’s default routing
instance to your loopback address. The traceroute session must be sourced from
your partner’s loopback address.
lab@mxB-2> traceroute 192.168.xy.1 source 192.168.xy.1
traceroute to 192.168.20.1 (192.168.20.1) from 192.168.21.1, 30 hops max, 40
byte packets
1 172.22.124.2 (172.22.124.2) 0.343 ms 0.257 ms 0.247 ms
2 172.22.252.1 (172.22.252.1) 0.260 ms 0.260 ms 0.269 ms
3 192.168.20.1 (192.168.20.1) 0.374 ms 0.368 ms 0.355 ms
lab@mxB-2>
Question: Which router is the traceroute using to

reach your student device? Why?
Answer: The path is through the P2 router and then

the P1 router. Since the MED has been set to 10 on
the summary route to the P1 router and 20 to the
P2 router, the preferred path is through the P1
router. The route with the lower MED is always
preferred.
Step 3.12
Exit from your partner’s student device.
lab@mxB-2> exit
lab@mxB-1>
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
Enter configuration mode and navigate to the [edit protocols bgp group
P1-P2] hierarchy. Remove the metric from the P1 neighbor and the export policy
from the P2 neighbor. Commit the changes and return to operational mode.
[edit]
lab@mxB-1# edit protocols bgp group P1-P2

lab@mxB-1# delete neighbor 172.22.12x.2 metric-out

lab@mxB-1# delete neighbor 172.22.12x.2 export

commit complete
lab@mxB-1>
Step 4.2
Trying 192.168.21.1...
mxB-2 (ttyp0)
login: lab
Password:
--- JUNOS 10.3R1.9 built 2010-08-13 12:48:28 UTC

lab@mxB-2>
Step 4.3

192.168.20.0/24 *[BGP/170] 00:07:41, localpref 100

AS path: 65412 65001 I
> to 172.22.124.2 via ge-1/0/0.1124
[BGP/170] 00:07:41, localpref 100
AS path: 65412 65001 I
> to 172.22.122.2 via ge-1/0/0.1122
AS path: 65020 65001 I
> to 10.0.24.2 via ge-1/0/4.24
lab@mxB-2>
Question: How many BGP paths exist for your

summary route?
Answer: There are three possible paths 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 65001” in this output. The third is “65020
65001”.
Step 4.4
the [edit policy-options] hierarchy. Copy the export-aggregate policy
to a new policy called export-p3 and display the new policy with the show
policy-statement export-p3 command.
lab@mxB-2> exit
[edit]
lab@mxB-1# show policy-statement export-p3
term 1 {
from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
}
then reject;
}
lab@mxB-1#
Step 4.5
hierarchy. Using the as-path-prepend option insert your partner’s AS number in
to the AS Path.

lab@mxB-1# set term 1 then as-path-prepend 6500x

lab@mxB-1#
Step 4.6
Navigate to the [routing-instances R3-z protocols bgp] hierarchy and
apply the export-p3 policy as an export policy under the P3 neighbor hierarchy.

lab@mxB-1# set group P3 neighbor 192.168.102.1 export export-p3

commit complete
lab@mxB-1>
Step 4.7
Trying 192.168.21.1...
mxB-2 (ttyp0)
login: lab
Password:
--- JUNOS 10.3R1.9 built 2010-08-13 12:48:28 UTC

lab@mxB-2>
Step 4.8

192.168.20.0/24 *[BGP/170] 00:42:22, localpref 100

AS path: 65412 65001 I
> to 172.22.124.2 via ge-1/0/0.1124
[BGP/170] 00:42:22, localpref 100
AS path: 65412 65001 I
> to 172.22.122.2 via ge-1/0/0.1122
lab@mxB-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.9
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 and return to operational
mode.
lab@mxB-2> exit
[edit]
lab@mxB-1# edit policy-options policy-statement export-aggregate

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

lab@mxB-1# set term 1 then as-path-prepend "65001 65001 65001"

commit complete
lab@mxB-1>
Step 4.10
Trying 192.168.21.1...
mxB-2 (ttyp0)
login: lab
Password:
--- JUNOS 10.3R1.9 built 2010-08-13 12:48:28 UTC

lab@mxB-2>
Step 4.11

192.168.20.0/24 *[BGP/170] 00:00:19, localpref 100

AS path: 65412 65001 65001 65001 65001 I
> to 172.22.124.2 via ge-1/0/0.1124
[BGP/170] 00:00:19, localpref 100
AS path: 65412 65001 65001 65001 65001 I
> to 172.22.122.2 via ge-1/0/0.1122
lab@mxB-2>
Question: What is the AS Path for the summary

route now? Why are there four of your AS numbers?
Answer: In this example, the AS path for the

summary route is “65412 65001 65001 65001
65001”. The as-path-prepend command in the
export policy inserted three “65001” AS numbers
and the EBGP peer inserted the fourth
Step 4.12
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 and return to operational mode.
lab@mxB-2> exit
[edit]
lab@mxB-1# edit policy-options policy-statement export-p3

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

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

commit complete
lab@mxB-1>
Step 4.13
Trying 192.168.21.1...
mxB-2 (ttyp0)
login: lab
Password:
--- JUNOS 10.3R1.9 built 2010-08-13 12:48:28 UTC

lab@mxB-2>
Step 4.14

192.168.20.0/24 *[BGP/170] 00:18:25, localpref 100, from 192.168.21.2

AS path: 65020 65001 I
> to 10.0.24.2 via ge-1/0/4.24
[BGP/170] 00:00:41, localpref 100
AS path: 65412 65001 65001 I
> to 172.22.122.2 via ge-1/0/0.1122
[BGP/170] 00:00:41, localpref 100
AS path: 65412 65001 65001 I
> to 172.22.124.2 via ge-1/0/0.1124
lab@mxB-2>
Question: Which of the three BGP updates is the
active route? Why?
Answer: The active route is using the IBGP update

from the R3 router. The AS path through the R3
router has a length of 2 while the AS Path through
P1 and P2 has a length of 3.
Step 4.15
Exit from your partner’s student device.
lab@mxB-2> exit
lab@mxB-1>
Step 4.16
policy-statement export-aggregate] hierarchy. Display the policy using
the show command and delete the as-path-prepend statement. Commit the
change and return to operational mode.
[edit]
lab@mxB-1# edit policy-options policy-statement export-aggregate

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

lab@mxB-1# delete term 1 then as-path-prepend
commit complete
lab@mxB-1>
Step 4.17
Use the operartional mode command show route receive-protocol bgp
172.22.1xy.2 to display the routes being received from P1.

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
192.168.21.0/24 172.22.121.2 65412 65002 I
lab@mxB-1>
Question: How many routes are being received from

the P1 peer?
Answer: The P1 peer is advertising five routes to the

default routing instance.
Step 4.18
Use a regular expression in the show route receive-protocol bgp
172.22.1xy.2 aspath-regex “.* 6500x” command to only display routes
that originate in your partner’s autonomous system.
lab@mxB-1> show route receive-protocol bgp 172.22.1xy.2 aspath-regex ".* 6500x"

192.168.21.0/24 172.22.121.2 65412 65002 I
lab@mxB-1>
Step 4.19
Using regular expressions create a BGP import policy to only accept your partners
summary route from the P1 peer. Enter configuration mode and navigate to the
[edit policy-options] hierarchy. Create an as-path called partner-as
to match on all routes that originate in your partners autonomous system.
[edit]
lab@mxB-1# set as-path partner-as ".* 6500x"
lab@mxB-1#
Step 4.20
Navigate to the [edit policy-options policy-statement import-P1]
hierarchy and create a policy to only accept your partner’s summary route.
lab@mxB-1# edit policy-statement import-P1
[edit policy-options policy-statement import-P1]


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



lab@mxB-1#
Step 4.21
Navigate to the [protocols bgp group P1-P2] hierarchy and apply the
import-P1 policy to the 172.22.1xy.2 neighbor as an import policy. Commit the
configuration and return to operational mode.
lab@mxB-1# set neighbor 172.22.1xy.2 import import-P1

commit complete
lab@mxB-1>
Step 4.22
Use the operartional mode command show route receive-protocol bgp
172.22.1xy.2 to display the routes being received from P1.

192.168.21.0/24 172.22.121.2 65412 65002 I
lab@mxB-1>
Question: Is the P1 import policy only accepting

your partner’s summary router?
Answer: Yes. The import policy applied to the P1

peer is only accepting the partner’s summary route.
Step 4.23
Use the operational mode command show route advertise-protocol bgp
172.22.1xy.2 to display the routes being advertised to the P1 peer.
lab@mxB-1> show route advertising-protocol bgp 172.22.1xy.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
* 192.168.20.0/24 Self I
lab@mxB-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.24
R3-z] hierarchy. Configure a static route, 192.168.10.0/24 in the R3 routing
instance with a next-hop of reject. Commit the configuration and return to
operational mode.
[edit]
lab@mxB-1# edit routing-instances R3-1

lab@mxB-1# set routing-options static route 192.168.10.0/24 reject

commit complete
lab@mxB-1>
Step 4.25
Use regular expressions in the show route advertise-protocol bgp
172.22.1xy.2 aspath-regex “()” command to only display routes that
originate in your autonomous system.
lab@mxB-1> show route advertising-protocol bgp 172.22.1xy.2 aspath-regex "()"

* 192.168.10.0/24 Self I
* 192.168.20.0/24 Self I
lab@mxB-1>
Step 4.26
Using regular expressions modify the BGP export policy for P1 to suppress all
internal BGP routes from being advertised. Enter configuration mode and navigate
to the [edit policy-options] hierarchy. Create an as-path called
internal-as to match on all internal BGP routes.
[edit]
lab@mxB-1# set as-path internal-as "()"
lab@mxB-1#
Step 4.27
export-aggregate] hierarchy and display the policy using the show command.
Configure 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@mxB-1# top edit policy-options policy-statement export-aggregate

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


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


commit complete
lab@mxB-1>
Step 4.28
Use regular expressions in the show route advertise-protocol bgp
172.22.1xy.2 aspath-regex “()” command to only display routes that
originate in your autonomous system.
lab@mxB-1> show route advertising-protocol bgp 172.22.1xy.2 aspath-regex "()"

* 192.168.20.0/24 Self I
lab@mxB-1>
Question: Are the internal BGP routes being

suppressed to the P1 peer?
Answer: Yes. The 192.168.20.0/24 route is not a

BGP internal route. It is an aggregate route being
redistributed and advertised to the P1 EBGP peer.
Lab 9
BGP Attributes: Local-Preference and Communities (Detailed)
Overview
In this lab, you will be using 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.
In this lab you will:
• Load the starting configuration
• Influence routing using the Local-Preference attribute.
• Use communities to tag routes.
• Influence routing by matching specific communities.
Note
The BGP topology will require you to display
information in the different virtual routing instances.
commands will include the routing instance name,
R3-z, where z 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-z switch must be use to
consult the appropriate virtual instance. When
performing show commands the instance R3-z
or table R3-z switch needs to be used to display
the appropriate adjacencies or routing tables.
www.juniper.net BGP Attributes: Local-Preference and Communities (Detailed) • Lab 9–1

10.a.10.3R1.9
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. A
reset file named ajspr-lab9-reset-mx_ has been created to help you load the
OSPF topology. The mx_ within the reset file name references the assigned student
Step 1.1
Ensure you know what device you are assigned. Check with your instructor if
value. This will help avoid any confusion during the configuration steps throughout
the lab.
Step 1.2
Step 1.3
mxB-1 (ttyp0)
login: lab
Password:
---JUNOS 10.3R1.9 built 2010-08-13 12:48:29 UTC

lab@mxB-1>
Step 1.4
Use the load override command to load the lab 9 reset file. The reset file is
named ajspr-lab9-reset-mx_ .config and is located in /var/tmp directory.
After loading the file commit the configuration and return to operational mode
[edit]
load complete
[edit]
commit complete
lab@mxB-1>
Step 1.5
Use the operational mode command show configuration to view the active
configuration.
Lab 9–2 • BGP Attributes: Local-Preference and Communities (Detailed) www.juniper.net

version 10.3R1.9;
/* AJSPR Lab-9 reset configuration file */
system {
host-name mxA-1;
ssh-dsa "ssh-dss
SECRET-DATA
}
login {
user lab {
uid 2000;
class super-user;
authentication {
SECRET-DATA
}
}
}
services {
ftp;
ssh;
telnet;
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
}
}
}
chassis {
fpc 1 {
pic 0 {
tunnel-services {
bandwidth 1g;
}

}
}
}
interfaces {
ge-1/0/0 {
vlan-tagging;
unit 1111 {
vlan-id 1111;
family inet {
address 172.22.121.1/24;
}
}
unit 1113 {
vlan-id 1113;
family inet {
address 172.22.123.1/24;
}
}
unit 1115 {
vlan-id 1115;
family inet {
address 172.22.125.1/24;
}
}
}
ge-1/0/4 {
vlan-tagging;
unit 10 {
vlan-id 10;
family inet {
address 10.0.10.1/24;
}
}
}
ge-1/1/4 {
vlan-tagging;
unit 10 {
description "connection to default";
vlan-id 10;
family inet {
address 10.0.10.2/24;
}
}
}
fxp0 {
unit 0 {
family inet {
address 10.210.14.1/27;
}
}

}
lo0 {
unit 0 {
family inet {
address 192.168.20.1/32;
}
family iso {
address 49.0001.1921.6802.0001.00;
}
}
unit 1 {
family inet {
address 192.168.20.2/32;
}
family iso {
address 49.0001.1921.6802.0002.00;
}
}
}
}
routing-options {
static {
route 192.168.20.0/26 reject;
route 192.168.20.64/26 reject;
}
aggregate {
route 192.168.20.0/24;
}
forwarding-table {
export pfe-load-balance;
}
}
protocols {
bgp {
group ibgp {
type internal;
local-address 192.168.20.1;
export [ redistribute-statics next-hop-self ];
neighbor 192.168.20.2;
}
group P1-P2 {
type external;
import import-P1;
export export-aggregate;
peer-as 65412;
neighbor 172.22.121.2;
neighbor 172.22.123.2;
}
}
isis {
level 1 disable;
interface lo0.0;
}

ospf {
area 0.0.0.0 {
interface lo0.0;
}
}
}
policy-options {
policy-statement P1-P2-import {
term 1 {
from {
protocol bgp;
}
then origin egp;
}
}
policy-statement export-aggregate {
term 1 {
from {
protocol aggregate;
}
then accept;
}
}
policy-statement export-p3 {
term 1 {
from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
}
then reject;
}
}
policy-statement import-P1 {
term 1 {
from {
protocol bgp;
as-path partner-as;
}
then accept;
}
term 2 {
then reject;
}
}
policy-statement next-hop-self {
term 1 {

from {
protocol bgp;
route-type external;
}
then {
next-hop self;
}
}
}
policy-statement pfe-load-balance {
term 1 {
from {
protocol bgp;
}
then {
load-balance per-packet;
}
}
}
policy-statement redistribute-statics {
term 1 {
from protocol static;
then accept;
}
}
as-path partner-as ".* 65002";
}
routing-instances {
R3-1 {
interface lo0.1;
routing-options {
static {
route 192.168.20.128/26 reject;
route 192.168.20.192/26 reject;
route 192.168.102.1/32 {
next-hop 172.22.125.2;
no-readvertise;
}
route 192.168.10.0/24 reject;
}
aggregate {
route 192.168.20.0/24;
}
}
protocols {
bgp {
group ibgp {
type internal;
export [ redistribute-statics next-hop-self ];

neighbor 192.168.20.1;
}
group P3 {
type external;
multihop;
neighbor 192.168.102.1 {
export export-p3;
peer-as 65020;
}
}
}
ospf {
area 0.0.0.0 {
interface lo0.1;
}
}
isis {
level 1 disable;
interface lo0.1;
}
}
}
}
Step 1.6
Use the show route 192.168.xy.0/24 table inet.0 detail to display
detail information about your partners summary route in the default routing
instance.


Source: 172.22.121.2
State: <Active Ext>
Age: 1:28:24
Task: BGP_65412.172.22.121.2+179
Announcement bits (3): 0-KRT 6-BGP RT Background 7-Resolve tree 5
Accepted
Localpref: 100
Router ID: 192.168.100.1

Source: 172.22.123.2
Age: 1:28:24
Task: BGP_65412.172.22.123.2+179
Accepted
Localpref: 100
Router ID: 192.168.101.1
Source: 192.168.20.2
Indirect next hop: 27d75a0 1048575
State: <Int Ext>
Inactive reason: Interior > Exterior > Exterior via Interior
Age: 18:22:59 Metric2: 1
Task: BGP_65001.192.168.20.2+179
Accepted
Localpref: 100
Router ID: 192.168.20.2
lab@mxB-1>
Question: Three BGP routes have been received in

the default routing table from the R3-z, P1 and P2
routers. Of these three BGP updates, which route is
active? Why?
Answer: In the output the route received from the

P1 router is the active route. Your result may differ
Question: What is the local-preference in the three

BGP routes?
Answer: The local-preference value on all three BGP

routes is 100 which is the default value.

Step 1.7
policy-statement import-p1] hierarchy. Create a routing policy named
import-p1. Configure the 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@mxB-1# delete policy-statement import-P1
lab@mxB-1# edit policy-statement import-p1
[edit policy-options policy-statement import-p1]


lab@mxB-1# set term 1 from neighbor 172.22.1xy.2


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

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

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

lab@mxB-1# delete import

lab@mxB-1# set import import-p1

commit complete
lab@mxB-1>
Step 1.9
to display detail information about your partners summary route in the default
routing instance.

Source: 172.22.121.2
State: <Active Ext>
Age: 17:55:37
Task: BGP_65412.172.22.121.2+54951
AS path: 65412 65002 65002 I Aggregator: 65002 192.168.21.1
Accepted
Localpref: 110
Router ID: 192.168.100.1
Source: 172.22.123.2
State: <Ext>
Inactive reason: Local Preference
Age: 17:55:37
Task: BGP_65412.172.22.123.2+49691
Accepted
Localpref: 100
Router ID: 192.168.101.1
lab@mxB-1>

Question: Now, there are only two BGP routes in the
default routing table. What happened to the route
from the R3-z router?
Answer: Since 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.
Step 1.10
Use the show route 192.168.xy.0/24 table R3-z.inet.0 detail
command to display detail information about your partners summary route in the
R3-z routing instance.
lab@mxB-1> show route 192.168.xy.0/24 table R3-z.inet.0 detail

Source: 192.168.20.1
Indirect next hop: 2812960 1048576
Age: 19:13 Metric2: 1
Task: BGP_65001.192.168.20.1+179
Accepted
Localpref: 110
Router ID: 192.168.20.1
Source: 192.168.102.1
Indirect next hop: 28120f0 1048574
State: <Ext>
Age: 18:24:32 Metric2: 0
Task: BGP_65020.192.168.102.1+53647
Accepted

Localpref: 100
Router ID: 20.20.1.1
lab@mxB-1>
Question: There are two BGP routes in the R3

routing table for your partners 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. Since 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.11
policy-statement import-P3] hierarchy. Create a routing policy call
import-p3. Configure the 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. Use the show
command to display the policy.
[edit]
lab@mxB-1# edit policy-options policy-statement import-p3


lab@mxB-1# set term 1 from neighbor 172.22.125.2



lab@mxB-1# show
term 1 {
from {
protocol bgp;
neighbor 172.22.125.2;

}
then {
}
}

lab@mxB-1#
Step 1.12
Navigate to the [edit routing-instances R3-z protocols bgp group
P3] hierarchy and apply the import-p3 policy as an import policy under the
group. Commit the configuration and return to operational mode.
lab@mxB-1# top edit routing-instances R3-z protocols bgp group P3
[edit routing-instances R3-1 protocols bgp group P3]

lab@mxB-1# set import import-p3

commit complete
lab@mxB-1>
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 doesn't 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 octet
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
specifications with an import routing policy. A route's community value can cause
specific routes to be accepted, rejected or modified.
Step 2.1
Enter configuration mode and navigate to the [edit policy-options]
hierarchy. In this step, you will need to define the community values that will be used
in this lab. Define 6 communities, three with your local AS number in the first two
octets and three with your partners AS number in the first two octets. The second
two octets in each of the three communities will have a value of 100,110 and 120
(65001:100, 65001:110, 65001:120, 65002:100, 65002:110, 65002:120). The
community name should be the same as the member value.

[edit]
lab@mxB-1# set community 65001:100 members 65001:100
lab@mxB-1#
Step 2.2
Create two routing policies called export-p1 and export-p2. Use the copy
command to copy the export-aggregate policy into each of the new policies.
lab@mxB-1#
Step 2.3
hierarchy and use the show command to display the policy. Set the community with
your local AS and administrative value of 100 in the match action section of term 1.

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

}
term 2 {
from {
}
then reject;
}

lab@mxB-1# set term 1 then community set 6500x:100

lab@mxB-1#
Step 2.4
lab@mxB-1# up

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


lab@mxB-1#
Step 2.5

lab@mxB-1# up

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


lab@mxB-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. Commit the

lab@mxB-1# set neighbor 172.22.1xy.2 export export-p1

lab@mxB-1# set neighbor 172.22.1xy.2 export export-p2

commit complete
lab@mxB-1>
STOP Stop. Wait until your partner has completed Step 2.6.

Step 2.7
routing instance.
lab@mxB-1> show route 192.168.xy.0/24 detail table inet.0

Source: 172.22.121.2
State: <Ext>
Age: 2:59
Task: BGP_65412.172.22.121.2+54951
Communities: 65002:100
Accepted
Localpref: 110
Router ID: 192.168.100.1
Source: 172.22.123.2
State: <Ext>
Age: 2:59
Task: BGP_65412.172.22.123.2+49691
Accepted
Localpref: 100
Router ID: 192.168.101.1
lab@mxB-1>
Question: Are the community values configured in

your partners BGP routes?
Answer: In this example, the community values

have been configured. 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.
[edit]
lab@mxB-1# edit policy-options policy-statement import-communities
[edit policy-options policy-statement import-communities]

lab@mxB-1# set term 1 from community 6500x:100









lab@mxB-1# show
term 1 {
from community 65002:100;
then {
accept;
}
}
term 2 {

then {
accept;
}
}
term 3 {
then {
accept;
}
}

lab@mxB-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@mxB-1# set import import-communities

lab@mxB-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.
lab@mxB-1# top edit routing-instances R3-z protocols bgp group P3


lab@mxB-1# set import import-communities

commit complete
lab@mxB-1>

Step 2.11
routing instance.

Source: 172.22.123.2
State: <Active Ext>
Age: 1:14:39
Task: BGP_65412.172.22.123.2+49691
Accepted
Localpref: 120
Router ID: 192.168.101.1
Source: 172.22.121.2
State: <Ext>
Age: 1:14:39
Task: BGP_65412.172.22.121.2+54951
Accepted
Localpref: 100
Router ID: 192.168.100.1
lab@mxB-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 then the local preference of the P1 route.
Step 2.12
Use the show route 192.168.xy.0/24 table R3-z detail command to
display detail information about your partners summary route in the default routing
instance.
lab@mxB-1> show route 192.168.xy.0/24 detail table R3-z

Source: 192.168.20.1
Indirect next hop: 2812960 1048576
Age: 1:14:19 Metric2: 1
Task: BGP_65001.192.168.20.1+179
Accepted
Localpref: 120
Router ID: 192.168.20.1
Source: 192.168.102.1
Indirect next hop: 28120f0 1048574
State: <Ext>
Age: 1:22:23 Metric2: 0
Task: BGP_65020.192.168.102.1+53647
Accepted
Localpref: 110
Router ID: 20.20.1.1
lab@mxB-1>

Question: Why is the route from the default router
the active route in the R3-z routing table?
Answer: The inactive reason on the route received

from the P3 router is Local Preference. Since the
local preference of the route received from the
default router is higher then 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.


Lab 10
BGP Route Damping (Detailed)
Overview
In this lab, you will be using the lab diagram titled “Lab 10: 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 10–1

10.a.10.3R1.9
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 router. The redistribute-statics
export policy must be modified to advertise only the 192.168.xy.0/24 specific routes
between the routing instances in your student device.
Step 1.1
the lab.
Step 1.2
Step 1.3
mxB-1 (ttyp0)
login: lab
Password:
---JUNOS 10.3R1.9 built 2010-08-13 12:48:29 UTC

lab@mxB-1>
Lab 10–2 • BGP Route Damping (Detailed) www.juniper.net

Step 1.4
policy-statement redistribute-statics] hierarchy. Modify the policy
to ensure that only the specific 192.168.xy.0/24 routes are redistributed.
Commit the change and return to operational mode.
[edit]
lab@mxB-1# edit policy-options policy-statement redistribute-statics


commit complete
lab@mxB-1>
Step 1.5
Use the show route 192.168.xy.0/24 table inet.0 command to display
the aggregate route and the redistributed static routes.

192.168.20.0/24 *[Aggregate/130] 1w6d 13:23:27

Reject
192.168.20.0/26 *[Static/5] 1w6d 13:23:27
Reject
192.168.20.1/32 *[Direct/0] 7w4d 23:12:47
> via lo0.0
192.168.20.2/32 *[OSPF/10] 2w3d 00:09:10, metric 1
> to 10.0.20.2 via ge-1/0/4.20
192.168.20.64/26 *[Static/5] 1w6d 13:23:27
Reject
192.168.20.128/26 *[BGP/170] 4d 01:31:28, localpref 100, from 192.168.20.2
AS path: I
> to 10.0.20.2 via ge-1/0/4.20
192.168.20.192/26 *[BGP/170] 4d 01:31:28, localpref 100, from 192.168.20.2
AS path: I
> to 10.0.20.2 via ge-1/0/4.20
lab@mxB-1>

Question: Is the aggregate route and all five specific
routes visible in the default routing table?
Answer: Yes. The aggregate route and all five of the

specific routes are visible in the default routing
table.
Question: Which protocols are advertising the

specific routes?
Answer: Two of the specific routes are statics route,

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 reconfiguring it.
Step 2.1
hierarchy. Create a static route in your default router that has your student device
number (1 or 2) in the third octet. Configure a 172.22.x.0/24 static route with a next
hop of reject.
[edit]
lab@mxB-1# set static route 172.22.x.0/24 reject
lab@mxB-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@mxB-1# top edit policy-options policy-statement export-p1



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


lab@mxB-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@mxB-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 and return to
operational mode.
lab@mxB-1# up


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


lab@mxB-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;
}

commit complete
lab@mxB-1>
Step 2.4
Use the show route 172.22.x.0/24 table inet.0 to display your
partner’s advertised route in the default routing table.

lab@mxB-1> show route 172.22.x.0/24 table inet.0

172.22.2.0/24 *[BGP/170] 17:49:05, localpref 100

AS path: 65412 65002 I
> to 172.22.123.2 via ge-1/0/0.1123
[BGP/170] 17:49:05, localpref 100
AS path: 65412 65002 I
> to 172.22.121.2 via ge-1/0/0.1121
lab@mxB-1>
Question: Is you 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
hierarchy. Enable BGP damping as a global command. Commit the change.
[edit]

lab@mxB-1# set damping

lab@mxB-1# commit
commit complete

lab@mxB-1#
Step 2.6
Navigate to the [edit routing-options] hierarchy. Work with your partner to
cause the 172.22.x.0/24 route to flap by deleting the static route. Commit the
change and return to operational mode.
lab@mxB-1# top edit routing-options

lab@mxB-1# delete static route 172.22.x.0/24
commit complete
lab@mxB-1>
Step 2.7
Use the 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
lab@mxB-1> show route damping history table inet.0 detail

BGP /-101
Source: 172.22.123.2
State: <Hidden Ext>
Age: 18:16:27
Task: BGP_65412.172.22.123.2+49691
AS path: 65412 65002 I
Accepted
Localpref: 100
Router ID: 192.168.101.1
Merit (last update/now): 740/619
Default damping parameters used
Last update: 00:03:55 First update: 00:10:25
Flaps: 1
History entry. Expires in: 00:24:40
BGP /-101
Source: 172.22.121.2
State: <Hidden Ext>
Age: 18:16:27
Task: BGP_65412.172.22.121.2+54951
AS path: 65412 65002 I
Accepted
Localpref: 100
Router ID: 192.168.100.1

Flaps: 1
History entry. Expires in: 00:24:40
lab@mxB-1>
Question: Are there withdrawn routes with a history

of figure-of-merit?
Answer: If your partner has deleted the static route,

there will be a withdrawn route with figure-of-merit.
If there are no withdrawn routes, 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 619. 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
Enter configuration mode and perform a rollback 1 to readvertise the static
route. Commit the configuration and return to operational mode.
[edit]
load complete
[edit]
commit complete
lab@mxB-1>
Step 2.9
Use the show route damping decayed table inet.0 detail command
to show active routes that are decaying but not suppressed.
lab@mxB-1> show route damping decayed table inet.0 detail

Source: 172.22.123.2
State: <Active Ext>
Age: 26
Task: BGP_65412.172.22.123.2+49691
AS path: 65412 65002 I
Accepted
Localpref: 100
Router ID: 192.168.101.1
Flaps: 2
Source: 172.22.121.2
Age: 26
Task: BGP_65412.172.22.121.2+54951
AS path: 65412 65002 I
Accepted
Localpref: 100
Router ID: 192.168.100.1
Flaps: 2
lab@mxB-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: There should be only 2 flaps for this route,

a withdrawn route and readvertised route.
Step 2.10
Enter configuration mode and flap the route 4 times using the rollback 1 and
commit commands. On the last commit, return to operational mode.
[edit]
load complete
[edit]
lab@mxB-1# commit
commit complete
[edit]
load complete
[edit]
lab@mxB-1# commit
commit complete
[edit]
load complete
[edit]
lab@mxB-1# commit
commit complete
[edit]
load complete

[edit]
commit complete
lab@mxB-1>
Step 2.11
Use the show route damping suppressed table inet.0 detail
command to display routes that have been suppressed due to damping in the
lab@mxB-1> show route damping suppressed table inet.0 detail

BGP /-101
Source: 172.22.123.2
State: <Hidden Ext>
Age: 19
Task: BGP_65412.172.22.123.2+49691
AS path: 65412 65002 I
Localpref: 100
Router ID: 192.168.101.1
Flaps: 6
Suppressed. Reusable in: 00:35:40
Preference will be: 170
BGP /-101
Source: 172.22.121.2
State: <Hidden Ext>
Age: 19
Task: BGP_65412.172.22.121.2+54951
AS path: 65412 65002 I
Localpref: 100
Router ID: 192.168.100.1
Flaps: 6
lab@mxB-1>

Question: Are there routes in the default routing
table that have been suppressed because of
damping?
Answer: After your partner has completed the

4 flaps in Step 2.10, 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:35:40 minutes. This 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 damp aggressively routes received from the P2 router.
Step 3.1
Enter configuration mode and navigate to the [edit policy-options]
hierarchy. Create and configure two damping parameters named disable and
aggressive. The aggressive parameter should set the suppress parameter to
1500, half-life to 10 minutes, and the reuse to 500.
[edit]
lab@mxB-1# set damping disable disable
lab@mxB-1# set damping aggressive suppress 1500

lab@mxB-1# set damping aggressive half-life 10
lab@mxB-1# set damping aggressive reuse 500
lab@mxB-1#
Step 3.2
modify-damping] hierarchy. Create a two-term import policy named
modify-damping to modify the damping parameters. Configure the first term to
disable damping on all BGP routes received from the P1 neighbor and configure the
second term to set damping aggressive on all routes received from the P2 neighbor.
Use the show command to display the policy.
lab@mxB-1# edit policy-statement modify-damping
[edit policy-options policy-statement modify-damping]



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



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

lab@mxB-1# show
term 1 {
from {
protocol bgp;
neighbor 172.22.121.2;
}
then damping disable;
}
term 2 {
from {
protocol bgp;
neighbor 172.22.123.2;
}
then damping aggressive;
}

lab@mxB-1#
Step 3.3
the modify-damping policy as a group import policy. Commit the changes and

lab@mxB-1# set import modify-damping

commit complete
lab@mxB-1>
Step 3.4
Use the clear bgp damping command to reset the figure-of-merit to zero on all
routes. Use the show route damping suppress table inet.0 command
to verify that all routes are active and no routes are suppressed in the default
routing table.
lab@mxB-1> clear bgp damping
lab@mxB-1> show route damping suppressed table inet.0
lab@mxB-1>
Question: Are there suppressed routes in the

default routing table?
Answer: No. There are no suppressed routes in the

Step 3.5
hierarchy. Use the delete static route 172.22.x.0/24 command and
commit to flap the route. Use the rollback 1 command to readvertise the route.
Commit the change and return to operational mode.

[edit]
lab@mxB-1# delete static route 172.22.x.0/24
lab@mxB-1# commit
commit complete
lab@mxB-1# top
[edit]
load complete
[edit]
commit complete
lab@mxB-1>
Step 3.6
Use the show route damping suppress table inet.0 detail
command to display any routes suppressed due to damping in the default routing
table.
lab@mxB-1> show route damping suppressed table inet.0 detail

BGP /-101
Source: 172.22.123.2
State: <Hidden Ext>
Inactive reason: Unusable path
Age: 28
Task: BGP_65412.172.22.123.2+49691
AS path: 65412 65002 I
Localpref: 100
Router ID: 192.168.101.1
damping-parameters: aggressive
Flaps: 2
lab@mxB-1>

Question: Are there any suppressed routes in the
Answer: Yes. There is one suppressed route in the

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 is the
parameter configured in the modify-damping policy
for the P2 router.
Step 3.7
Use the show route 172.22.x.0/24 table inet.0 detail command to
verify that the damping policy on the P1 router is disabling damping on received
routes.
lab@mxB-1> show route 172.22.x.0/24 table inet.0 detail

Source: 172.22.121.2
State: <Active Ext>
Age: 18
Task: BGP_65412.172.22.121.2+54951
AS path: 65412 65002 I
Accepted
Localpref: 100
Router ID: 192.168.100.1
lab@mxB-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 show route damping decaying table inet.0 detail
command to display any active routes with figure-of-merit in the default routing
table.
lab@mxB-1> show route damping decayed table inet.0 detail
lab@mxB-1>
Question: Is the EBGP import policy that disables

damping on the P1 router working?
Answer: Because your partner’s route is active and

there is not figure-of-merit, it appears that the
import policy applied to the P1 router is disabling
damping.

Lab 11
Scaling BGP (Detailed)
Overview
In this lab, you will be using the lab diagram titled “Lab 11: Scaling BGP Part 1” and “Lab
11: 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 11–1

10.a.10.3R1.9
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
the lab.
Step 1.2
Step 1.3
Lab 11–2 • Scaling BGP (Detailed) www.juniper.net

mxB-1 (ttyp0)
login: lab
Password:
---JUNOS 10.3R1.9 built 2010-08-13 12:48:29 UTC

lab@mxB-1>
Step 1.4
Enter configuration mode and load the lab 11 reset file named
ajspr-lab11-reset-mx_.config located in the /var/tmp directory. The mx_
within the reset file name references the assigned student device, mxA-1, mxA-2,
etc. Use the load override option to replace the current candidate database
with the reset file. Commit the new candidate configuration and return to
operational mode.
[edit]
lab@mxB-1# load override ajspr-lab11-reset-mx_.config
load complete
[edit]
commit complete
lab@mxB-1>
Step 1.5
Use the show configuration command to display the new configuration for this
lab.
## Last changed: 2011-02-03 21:56:46 UTC
version 10.3R1.9;
groups {
iso {
interfaces {
<ge-*> {
unit <*> {
family iso;
}
}
}
}
}
/* AJSPR Lab 11 final configuration */
system {
host-name mxB-1;

ssh-dsa "ssh-dss
SECRET-DATA
}
login {
user lab {
uid 2000;
class super-user;
authentication {
SECRET-DATA
}
}
}
services {
ftp;
ssh;
telnet;
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
}
}
}
chassis {
fpc 1 {
pic 0 {
tunnel-services {
bandwidth 1g;
}
}
}
}
interfaces {
apply-groups iso;
ge-1/0/0 {
vlan-tagging;
unit 1121 {

vlan-id 1121;
family inet {
address 172.22.121.1/24;
}
}
unit 1125 {
vlan-id 1125;
family inet {
address 172.22.125.1/24;
}
}
}
ge-1/0/4 {
vlan-tagging;
unit 20 {
vlan-id 20;
family inet {
address 10.0.20.1/24;
}
}
unit 21 {
vlan-id 21;
family inet {
address 10.0.21.1/24;
}
}
}
ge-1/0/5 {
vlan-tagging;
unit 22 {
vlan-id 22;
family inet {
address 10.0.22.1/24;
}
}
unit 23 {
vlan-id 23;
family inet {
address 10.0.23.1/24;
}
}
}
ge-1/1/4 {
vlan-tagging;
unit 20 {
vlan-id 20;
family inet {
address 10.0.20.2/24;

}
}
unit 21 {
vlan-id 21;
family inet {
address 10.0.21.2/24;
}
}
}
ge-1/1/5 {
vlan-tagging;
unit 22 {
vlan-id 22;
family inet {
address 10.0.22.2/24;
}
}
unit 23 {
vlan-id 23;
family inet {
address 10.0.23.2/24;
}
}
}
fxp0 {
unit 0 {
family inet {
address 10.210.15.3/27;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.20.1/32;
}
family iso {
address 49.0001.1921.6802.0001.00;
}
}
unit 1 {
family inet {
address 192.168.20.2/32;
}
family iso {
address 49.0001.1921.6802.0002.00;
}
}
unit 2 {
family inet {
address 192.168.20.3/32;

}
family iso {
address 49.0001.1921.6802.0003.00;
}
}
unit 3 {
family inet {
address 192.168.20.4/32;
}
family iso {
address 49.0001.1921.6802.0004.00;
}
}
}
}
routing-options {
static {
route 192.168.20.0/26 reject;
}
aggregate {
route 192.168.20.0/24;
}
}
protocols {
bgp {
group P1-P2 {
type external;
peer-as 65412;
neighbor 172.22.121.2;
}
}
isis {
level 1 disable;
interface lo0.0;
}
ospf {
area 0.0.0.0 {
interface lo0.0;
}
}
}
policy-options {
term 1 {
from {
protocol aggregate;
}
then accept;

}
term 2 {
from {
}
then reject;
}
}
term 1 {
from {
protocol static;
}
then accept;
}
}
}
routing-instances {
R3-1 {
interface lo0.1;
routing-options {
static {
route 192.168.20.64/26 reject;
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lo0.1;
}
}
isis {
level 1 disable;
interface lo0.1;
}
}
}
R4-1 {
interface lo0.2;
routing-options {
static {
route 192.168.20.128/26 reject;
}

}
protocols {
ospf {
area 0.0.0.0 {
interface lo0.2;
}
}
isis {
level 1 disable;
interface lo0.2;
}
}
}
R5-1 {
interface lo0.3;
routing-options {
static {
route 192.168.102.1/32 {
next-hop 172.22.125.2;
no-readvertise;
}
route 192.168.20.192/26 reject;
}
aggregate {
route 192.168.20.0/24;
}
}
protocols {
bgp {
group P3 {
type external;
multihop;
neighbor 192.168.102.1 {
peer-as 65020;
}
}
}
ospf {
area 0.0.0.0 {
interface lo0.3;
}

}
isis {
level 1 disable;
interface lo0.3;
}
}
}
}
Step 1.6
Use the show ospf neighbor command to verify OSPF reachability from the
default router.
10.0.20.2 ge-1/0/4.20 Full 192.168.20.2 128 39
10.0.21.2 ge-1/0/4.21 Full 192.168.20.3 128 32
lab@mxB-1>
Question: Are the OSPF neighbor adjacencies

established between the default router and the R3
and R4 routers?
Answer: The OSPF neighbor relationship between

the default router and the R3 and R4 routers should
be established and in a Full state. If the OSPF
neighbors are not established, check with your
instructor.
Step 1.7
Use the show route protocol ospf to verify that the loopback addresses are
active in all four of the routing tables.
lab@mxB-1> show route protocol ospf

10.0.22.0/24 *[OSPF/10] 06:06:46, metric 2

> to 10.0.20.2 via ge-1/0/4.20
10.0.23.0/24 *[OSPF/10] 06:05:59, metric 2
> to 10.0.21.2 via ge-1/0/4.21
192.168.20.2/32 *[OSPF/10] 2w5d 23:38:25, metric 1
> to 10.0.20.2 via ge-1/0/4.20
192.168.20.3/32 *[OSPF/10] 06:05:59, metric 1
> to 10.0.21.2 via ge-1/0/4.21
192.168.20.4/32 *[OSPF/10] 05:40:57, metric 2
> to 10.0.21.2 via ge-1/0/4.21

to 10.0.20.2 via ge-1/0/4.20
224.0.0.5/32 *[OSPF/10] 2w5d 23:39:16, metric 1
MultiRecv

10.0.21.0/24 *[OSPF/10] 06:05:59, metric 2

> to 10.0.20.1 via ge-1/1/4.20
10.0.23.0/24 *[OSPF/10] 05:40:57, metric 2
> to 10.0.22.2 via ge-1/0/5.22
192.168.20.1/32 *[OSPF/10] 2w5d 23:38:25, metric 1
> to 10.0.20.1 via ge-1/1/4.20
192.168.20.3/32 *[OSPF/10] 05:40:57, metric 2
to 10.0.20.1 via ge-1/1/4.20
> to 10.0.22.2 via ge-1/0/5.22
192.168.20.4/32 *[OSPF/10] 05:40:57, metric 1
> to 10.0.22.2 via ge-1/0/5.22
224.0.0.5/32 *[OSPF/10] 2w5d 23:39:16, metric 1
MultiRecv

10.0.20.0/24 *[OSPF/10] 06:06:01, metric 2

> to 10.0.21.1 via ge-1/1/4.21
10.0.22.0/24 *[OSPF/10] 05:41:02, metric 2
> to 10.0.23.2 via ge-1/0/5.23
192.168.20.1/32 *[OSPF/10] 06:06:01, metric 1
> to 10.0.21.1 via ge-1/1/4.21
192.168.20.2/32 *[OSPF/10] 05:40:57, metric 2
to 10.0.21.1 via ge-1/1/4.21
> to 10.0.23.2 via ge-1/0/5.23
192.168.20.4/32 *[OSPF/10] 05:41:02, metric 1
> to 10.0.23.2 via ge-1/0/5.23
224.0.0.5/32 *[OSPF/10] 06:06:47, metric 1
MultiRecv

10.0.20.0/24 *[OSPF/10] 05:40:59, metric 2

> to 10.0.22.1 via ge-1/1/5.22
10.0.21.0/24 *[OSPF/10] 05:41:02, metric 2
> to 10.0.23.1 via ge-1/1/5.23
192.168.20.1/32 *[OSPF/10] 05:40:59, metric 2
> to 10.0.22.1 via ge-1/1/5.22
to 10.0.23.1 via ge-1/1/5.23
192.168.20.2/32 *[OSPF/10] 05:40:59, metric 1
> to 10.0.22.1 via ge-1/1/5.22
192.168.20.3/32 *[OSPF/10] 05:41:02, metric 1
> to 10.0.23.1 via ge-1/1/5.23
224.0.0.5/32 *[OSPF/10] 06:06:47, metric 1
MultiRecv

lab@mxB-1>
Question: Are the loopback addresses active in all

four routing table?
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.8
rr-cluster] hierarchy. Configure the default router as a route reflector for the
internal BGP network, and configure the R3-z, R4-z, and R5-z loopback addresses
as neighbors. Use your loopback address as the cluster ID and the local-address
within the route reflector group.
[edit]
lab@mxB-1# edit protocols bgp group rr-cluster
[edit protocols bgp group rr-cluster]

lab@mxB-1# set type internal

lab@mxB-1# set local-address 192.168.xy.1

lab@mxB-1# set cluster 192.168.xy.1

lab@mxB-1# set neighbor 192.168.xy.2




lab@mxB-1#
Step 1.9
ibgp] hierarchy and configure the default router's loopback address as an IBGP
neighbor. Use the R3 loopback address as the local-address for the internal
BGP network.
[edit]
lab@mxB-1# top edit routing-instances R3-z protocols bgp group ibgp
[edit routing-instances R3-1 protocols bgp group ibgp]




lab@mxB-1#
Step 1.10
ibgp] hierarchy and configure the default router’s loopback address as an IBGP
neighbor. Use the R4 loopback address as the local-address for the internal BGP
group.




lab@mxB-1#
Step 1.11
ibgp] hierarchy and configure the default router’s loopback address as an IBGP
neighbor. Use the R5 loopback address as the local-address for the internal
BGP group. Commit the configuration and return to operational mode.




commit complete
lab@mxB-1>
Step 1.12
Use the operational mode command show bgp summary to ensure that all of the
IBGP peer sessions are established.
inet.0 9 5 0 0 0 0
172.22.121.2 65412 21982 22608 0 1 1w0d3h Establ
inet.0: 5/5/5/0
192.168.20.1 65412 264 263 0 0 1:59:26 Establ
R3-1.inet.0: 0/5/5/0
192.168.20.1 65412 263 262 0 0 1:59:22 Establ
R4-1.inet.0: 0/5/5/0
192.168.20.1 65412 262 263 0 0 1:59:18 Establ
R5-1.inet.0: 0/5/5/0
192.168.20.2 65412 263 265 0 0 1:59:26 Establ
inet.0: 0/0/0/0
192.168.20.3 65412 262 264 0 0 1:59:22 Establ
inet.0: 0/0/0/0
192.168.20.4 65412 263 263 0 0 1:59:18 Establ
inet.0: 0/4/4/0
192.168.102.1 65020 228 233 0 0 1:45:19 Establ
R5-1.inet.0: 4/4/4/0
lab@mxB-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.13
Use the show route hidden table inet.0 command to check for any
unusable routes in the default routing table.
lab@mxB-1> show route hidden table inet.0

40.40.0.0/24 [BGP/170] 02:06:00, localpref 100, from 192.168.20.4

AS path: 65020 I
Unusable
AS path: 65020 I
Unusable
AS path: 65020 I
Unusable
AS path: 65020 I
Unusable
lab@mxB-1>
Question: Are there any unusable routes in the

Answer: There are four unusable routes in the

hidden RIB table.
Step 1.14
Use the show route 40.40.0.0/24 hidden detail command to display
the detail information and a possible cause for the route to be marked unusable.
lab@mxB-1> show route 40.40.0.0/24 hidden detail

Age: 2:09:33
Task: BGP_65412.192.168.20.4+50480
AS path: 65020 I
Accepted
Localpref: 100
Router ID: 192.168.20.4

lab@mxB-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 switch helps

determine the reason for the routes unusable
status.
Step 1.15
Use the show route 40.40.0.0/24 hidden extensive to display the
extensive information and a possible cause for the route to be marked unusable.
lab@mxB-1> show route 40.40.0.0 hidden extensive

Age: 2:14:43
Task: BGP_65412.192.168.20.4+50480
AS path: 65020 I
Accepted
Localpref: 100
Router ID: 192.168.20.4
Indirect next hops: 1
Indirect next hop: 0 -
lab@mxB-1>
Question: Does the extensive switch 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 router.

Step 1.16
policy-statement next-hop-self] hierarchy and create a policy that will
modify the next-hop attribute to the local loopback address.
[edit]

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

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

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

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


commit complete
lab@mxB-1>
Step 1.19
Use the show route 40.40.0.0/22 table inet.0 command to display the
P3 routes in the default routing table.



AS path: 65020 I
> to 10.0.21.2 via ge-1/0/4.21
to 10.0.20.2 via ge-1/0/4.20
AS path: 65020 I
> to 10.0.21.2 via ge-1/0/4.21
to 10.0.20.2 via ge-1/0/4.20
AS path: 65020 I
> to 10.0.21.2 via ge-1/0/4.21
to 10.0.20.2 via ge-1/0/4.20
AS path: 65020 I
> to 10.0.21.2 via ge-1/0/4.21
to 10.0.20.2 via ge-1/0/4.20
lab@mxB-1>
Question: Are the P3 routes active in the default

routing table?
Answer: Yes. The P3 routes are active in the default

routing table.
Step 1.20
Use the traceroute utility to verify connectivity to the 40.40.1.1 address on the
P3 router.
lab@mxB-1> traceroute 40.40.1.1 ttl 10
1 10.0.21.2 (10.0.21.2) 0.492 ms 0.293 ms 0.279 ms
2 10.0.21.1 (10.0.21.1) 0.283 ms 0.286 ms 0.288 ms
3 10.0.21.2 (10.0.21.2) 0.285 ms 0.288 ms 0.281 ms
4 10.0.21.1 (10.0.21.1) 0.298 ms 0.298 ms 0.291 ms
5 10.0.21.2 (10.0.21.2) 0.295 ms 0.307 ms 0.300 ms
6 10.0.21.1 (10.0.21.1) 0.307 ms 0.312 ms 0.307 ms
7 10.0.21.2 (10.0.21.2) 0.315 ms 23.316 ms 0.333 ms
8 10.0.21.1 (10.0.21.1) 0.328 ms 0.328 ms 0.318 ms
9 10.0.21.2 (10.0.21.2) 0.328 ms 0.340 ms 0.329 ms
10 10.0.21.1 (10.0.21.1) 0.343 ms 0.348 ms 0.339 ms
lab@mxB-1>

Question: Is there a problem in the path to the P3
router?
Answer: A routing loop has been formed between

the R3-z router and the R4-z 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.21
policy-statement next-hop-self] hierarchy. Modify the policy to only
change the next-hop attribute if the BGP routes are external routes. Use the match
condition route-type to accomplish this task. Commit the change and return to
operational mode.
[edit]


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

commit complete
lab@mxB-1>
Step 1.22
Use the traceroute utility to verify connectivity to the 40.40.1.1 address on the
P3 router.
lab@mxB-1> traceroute 40.40.1.1 ttl 10
1 10.0.21.2 (10.0.21.2) 0.440 ms 0.299 ms 0.284 ms
2 10.0.23.2 (10.0.23.2) 0.289 ms 0.293 ms 0.287 ms
3 40.40.1.1 (40.40.1.1) 0.486 ms 0.466 ms 0.458 ms
lab@mxB-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.
Step 1.23
Use the show route 40.40.0.0/24 table R4-z detail operational
mode command to display the P3 route in the R4 routing table.
lab@mxB-1> show route 40.40.0.0/24 table R4-z detail

Source: 192.168.20.1
Indirect next hop: 285a5a0 1048582
Age: 12:24 Metric2: 1
Task: BGP_65412.192.168.20.1+179
Announcement bits (2): 2-KRT 6-Resolve tree 6
AS path: 65020 I (Originator) Cluster list: 192.168.20.1
AS path: Originator ID: 192.168.20.4
Accepted
Localpref: 100
Router ID: 192.168.20.1
lab@mxB-1>
Question: The P3 route is being reflected to the R3

and R4 routers. What is the value of the cluster list
and the originator ID?
Answer: The cluster list is 192.168.20.1, which is

the cluster ID configured in the BGP cluster group.
The originator ID is 192.168.20.4, which is the peer
address of the R4 router.

Step 1.24
Use the show route 30.30.0.0/24 table R4-z detail operational
mode command to display the P3 route in the R4 routing table.
lab@mxB-1> show route 30.30.0.0/24 table R4-z detail

Source: 192.168.20.1
Indirect next hop: 285a1e0 1048576
Age: 3:00:00 Metric2: 1
Task: BGP_65412.192.168.20.1+179
Announcement bits (2): 2-KRT 6-Resolve tree 6
AS path: 65412 I
Accepted
Localpref: 100
Router ID: 192.168.20.1
lab@mxB-1>
Question: Is this route being advertised or reflected

to the R4 router?
Answer: Because the route does not have a cluster

list or originator ID, the route is being advertised to
the R4 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.

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
Ry-z, where y is the router number and z
diagram for the correct router and user
number.
Step 2.1
Enter configuration mode and load the lab 11 reset file named
ajspr-lab11-confederation-mx_.config located in the /var/tmp
directory. The mx_ within the reset file name references the assigned student
device, mxA-1, mxA-2, etc. Use the load override option to replace the current
candidate database with the reset file. Commit the new candidate configuration and
[edit]
lab@mxB-1# load override ajspr-lab11-confederation-mx_.config
load complete
[edit]
commit complete
lab@mxB-1>
Step 2.2
Use the operational mode command show configuration to display the active
configuration. The BGP confederation lab requires the creation of logical systems for
the R3, R4, and R5 routers.
version 10.3R1.9;
groups {
iso {
logical-systems {
<*> {
interfaces {
<ge-*> {
unit <*> {
family iso;

}
}
}
}
}
interfaces {
<ge-*> {
unit <*> {
family iso;
}
}
}
}
}
/* AJSPR Lab 11 final configuration */
system {
host-name mxB-1;
ssh-dsa "ssh-dss
SECRET-DATA
}
login {
user lab {
uid 2000;
class super-user;
authentication {
SECRET-DATA
}
}
}
services {
ftp;
ssh;
telnet;
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}

}
}
}
logical-systems {
R3-1 {
interfaces {
apply-groups iso;
ge-1/0/5 {
unit 22 {
vlan-id 22;
family inet {
address 10.0.22.1/24;
}
}
}
ge-1/1/4 {
unit 20 {
vlan-id 20;
family inet {
address 10.0.20.2/24;
}
}
}
lo0 {
unit 1 {
family inet {
address 192.168.20.2/32;
}
family iso {
address 49.0001.1921.6802.0002.00;
}
}
}
}
protocols {
isis {
level 1 disable;
interface lo0.1;
}
ospf {
area 0.0.0.0 {
interface lo0.1;
}
}
}
policy-options {

term 1 {
from {
protocol static;
}
then accept;
}
}
}
routing-options {
static {
route 192.168.20.64/26 reject;
}
}
}
R4-1 {
interfaces {
apply-groups iso;
ge-1/0/5 {
unit 23 {
vlan-id 23;
family inet {
address 10.0.23.1/24;
}
}
}
ge-1/1/4 {
unit 21 {
vlan-id 21;
family inet {
address 10.0.21.2/24;
}
}
}
lo0 {
unit 2 {
family inet {
address 192.168.20.3/32;
}
family iso {
address 49.0001.1921.6802.0003.00;
}
}
}
}
protocols {
isis {
level 1 disable;
interface lo0.2;
}

ospf {
area 0.0.0.0 {
interface lo0.2;
}
}
}
policy-options {
term 1 {
from {
protocol static;
}
then accept;
}
}
}
routing-options {
static {
route 192.168.20.128/26 reject;
}
}
}
R5-1 {
interfaces {
apply-groups iso;
ge-1/0/0 {
unit 1125 {
vlan-id 1125;
family inet {
address 172.22.125.1/24;
}
}
}
ge-1/1/5 {
unit 22 {
vlan-id 22;
family inet {
address 10.0.22.2/24;
}
}
unit 23 {
vlan-id 23;
family inet {
address 10.0.23.2/24;
}
}
}
lo0 {

unit 3 {
family inet {
address 192.168.20.4/32;
}
family iso {
address 49.0001.1921.6802.0004.00;
}
}
}
}
protocols {
bgp {
group P3 {
type external;
multihop;
peer-as 65020;
neighbor 192.168.102.1;
}
}
isis {
level 1 disable;
interface lo0.3;
}
ospf {
area 0.0.0.0 {
interface lo0.3;
}
}
}
policy-options {
term 1 {
from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
}
then reject;
}
}
term 1 {
then {
next-hop self;

}
}
}
term 1 {
from {
protocol static;
}
then accept;
}
}
}
routing-options {
static {
route 192.168.20.192/26 reject;
route 192.168.102.1/32 next-hop 172.22.125.2;
}
aggregate {
route 192.168.20.0/24;
}
}
}
}
chassis {
fpc 1 {
pic 0 {
tunnel-services {
bandwidth 1g;
}
}
}
}
interfaces {
apply-groups iso;
ge-1/0/0 {
vlan-tagging;
unit 1121 {
vlan-id 1121;
family inet {
address 172.22.121.1/24;
}
}
ge-1/0/4 {
vlan-tagging;
unit 20 {
vlan-id 20;
family inet {
address 10.0.20.1/24;
}
}
unit 21 {

vlan-id 21;
family inet {
address 10.0.21.1/24;
}
}
}
ge-1/0/5 {
vlan-tagging;
}
ge-1/1/4 {
vlan-tagging;
}
ge-1/1/5 {
vlan-tagging;
}
fxp0 {
unit 0 {
family inet {
address 10.210.15.3/27;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.20.1/32;
}
family iso {
address 49.0001.1921.6802.0001.00;
}
}
}
}
routing-options {
static {
route 192.168.20.0/26 reject;
}
aggregate {
route 192.168.20.0/24;
}
}
protocols {
bgp {
group P1-P2 {
type external;
peer-as 65412;
neighbor 172.22.121.2;
}
}
isis {
level 1 disable;

interface lo0.0;
}
ospf {
area 0.0.0.0 {
interface lo0.0;
}
}
}
policy-options {
term 1 {
from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
}
then reject;
}
}
term 1 {
from {
protocol static;
}
then accept;
}
}
term 1 }
then next-hop self;
}
}
}
lab@mxB-1>

Question: How many logical routers are configured
in the active configuration?
Answer: There are four logical routers configured.

The default routing instance is a logical router by
default. The other three, R3-z, R4-z, and R5-z
are defined in the logical-system hierarchy.
Step 2.3
Use the show ospf neighbor command to verify OSPF reachability from the
default router to the R3 and R4 routers.
10.0.20.2 ge-1/0/4.20 Full 192.168.20.2 128 33
10.0.21.2 ge-1/0/4.21 Full 192.168.20.3 128 38
lab@mxB-1>

established?
Answer: The OSPF adjacencies between the default

router and the R3 and R4 routers are in the Full
state and therefore established.
Step 2.4
Use the show ospf neighbor logical-system R5-z command to verify
OSPF reachability between the R5 router and the R3 and R4 routers.
lab@mxB-1> show ospf neighbor logical-system R5-z
10.0.22.1 ge-1/1/5.22 Full 192.168.20.2 128 38
10.0.23.1 ge-1/1/5.23 Full 192.168.20.3 128 38
lab@mxB-1>

established?
Answer: Yes. The OSPF neighbor state is Full

between the R5 router and the R3 and R4 routers.

Step 2.5
hierarchy. Set the autonomous system number to the sub-AS value, 6510x.
Configure the confederation global autonomous system number (6500x) and the
two member AS numbers (6510x and 6520x). Refer to the lab diagram for the
correct sub-AS and global autonomous system numbers.
[edit]
lab@mxB-1# set confederation 6500x members 6510x
lab@mxB-1#
Step 2.6
Navigate to the [edit protocols bgp group ibgp] hierarchy and configure
an internal peer session to the R3 router using the loopback addresses. Also apply
the next-hop-self policy as an export group policy.
lab@mxB-1# top edit protocols bgp group ibgp
[edit protocols bgp group ibgp]





lab@mxB-1#
Step 2.7
Navigate to the [edit logical-systems R3-z routing-options]
hierarchy and set the autonomous system number to the sub-AS 6510x. Configure
the confederation global autonomous system number (6500x) and the two member
AS numbers (6510x and 6520x). Refer to the lab diagram for the correct sub-AS
and global autonomous system numbers.

lab@mxB-1# top edit logical-systems R3-z routing-options
[edit logical-systems R3-1 routing-options]




lab@mxB-1#
Step 2.8
Navigate to the [edit logical-systems R3-z protocols bgp group
ibgp] hierarchy and configure an internal peer session to the default router using
loopback addresses. Commit the candidate configuration and return to operational
mode.
lab@mxB-1# up
[edit logical-systems R3-1]

lab@mxB-1# edit protocols bgp group ibgp
[edit logical-systems R3-1 protocols bgp group ibgp]




commit complete
lab@mxB-1>
Step 2.9
Use the show bgp summary command to display the BGP peer sessions.

inet.0 5 5 0 0 0 0
172.22.121.2 65412 33 32 0 0 12:51 5/
5/5/0 0/0/0/0
192.168.20.2 65101 6 8 0 0 1:24 0/
0/0/0 0/0/0/0
lab@mxB-1>
Question: Is the IBGP peer session between the

default router and the R3 router established?
Answer: Yes. The IBGP peer session between the

default router and the R3 router is established. If
the peer is not established, check the configuration
or contact your instructor.
Step 2.10
Use the show bgp summary logical-systems R3-z command to display
the BGP peer sessions in the R3 router.
lab@mxB-1> show bgp summary logical-system R3-z
inet.0 5 5 0 0 0 0
192.168.20.1 65101 14 13 0 0 4:44 5/
5/5/0 0/0/0/0
lab@mxB-1>

the default router in the R3 router?
Answer: The R3 router is receiving 5 routes from the

default router and 5 routes are active.

Question: What is the name of the routing table in
the R3 router?
Answer: The inet.0 routing table is being used in the

R3 router. Because a logical router has its own
routing daemon, each logical router has its own
inet.0 routing table.
Step 2.11
Enter configuration mode and navigate to the [edit logical-systems R4-z
routing-options] hierarchy. Set the AS number to the sub-AS 6520x.
Configure the confederation global AS number (6500x) and the two member AS
numbers (6510x and 6520x). Refer to the lab diagram for the correct sub-AS and
global AS numbers.
[edit]
lab@mxB-1# edit logical-systems R4-z routing-options




lab@mxB-1#
Step 2.12
ibgp] hierarchy and configure an internal peer session to the R5 router using
loopback addresses.
lab@mxB-1# up





lab@mxB-1#
Step 2.13
Navigate to the [edit logical-systems R5-z routing-options]
hierarchy and set the AS number to the sub-AS 6520x. Configure the confederation
global AS number (6500x) and the two member AS numbers (6510x and 6520x).
Refer to the lab diagram for the correct sub-AS and global AS numbers.
lab@mxB-1# top edit logical-systems R5-z routing-options




lab@mxB-1#
Step 2.14
ibgp] hierarchy and configure an internal peer session to the R4 router using the
loopback addresses. Also configure the next-hop-self policy as a group export policy.
Commit the candidate configuration and return to operational mode.
lab@mxB-1# up






commit complete
lab@mxB-1>
Step 2.15
Use the show bgp summary logical-systems R5-z command to verify
that the peer session between the R4 router and the R5 router is established.
inet.0 5 5 0 0 0 0
192.168.20.3 65201 74 80 0 0 32:28 0/
0/0/0 0/0/0/0
192.168.102.1 65020 77 74 0 0 32:28 5/
5/5/0 0/0/0/0
lab@mxB-1>
Question: Are the BGP peer sessions established to

the R4 router and the P3 router?
Answer: Both the EBGP session to P3 and the IBGP

session to R4 are established. If the peering
sessions are not established, check your
configuration and consult with your instructor.
Step 2.16
Use the show bgp summary logical-systems R4-z command to verify that
the R5 router is advertising routes to the R4 peer.
inet.0 5 5 0 0 0 0
192.168.20.4 65201 97 92 0 0 40:49 5/
5/5/0 0/0/0/0
lab@mxB-1>

Question: Is the R4 router receiving routes from the
R5 peer? How many of the routes are active?
Answer: The R4 router is receiving five routes from

the R5 peer and all five routes are active.
Step 2.17
cbgp] hierarchy. Configure a confederation BGP session between the default router
and the R5 router. Because the CBGP session will be using loopback addresses to
peer, both the local-address and multihop commands are required to
establish the session.
[edit]
lab@mxB-1# edit protocols bgp group cbgp
[edit protocols bgp group cbgp]

lab@mxB-1# set type external

lab@mxB-1# set multihop



lab@mxB-1# set peer-as 6520x

lab@mxB-1#
Step 2.18
cbgp] hierarchy and configure the confederation BGP session to the default router.
lab@mxB-1# top edit logical-systems R5-z protocols bgp group cbgp
[edit logical-systems R5-1 protocols bgp group cbgp]

lab@mxB-1# set type external

lab@mxB-1# set multihop



lab@mxB-1# set peer-as 6510x

commit complete
lab@mxB-1>
Step 2.19
Use the show bgp summary command to display the bgp peering sessions in the
default router.
inet.0 10 5 0 0 0 0
172.22.121.2 65412 245 252 0 0 1:52:08 5/
5/5/0 0/0/0/0
192.168.20.2 65101 226 228 0 0 1:40:41 0/
0/0/0 0/0/0/0
192.168.20.4 65201 26 26 0 0 9:57 0/
5/5/0 0/0/0/0
lab@mxB-1>
Question: Does the default router have an

established CBGP peer session with R5?
Answer: Yes, the CBGP peer session with R5 is

established. If the peer session is not established,
check the configuration and consult with your
instructor.

the R5 router? How many routes are active from
R5?
Answer: There are five routes being received from

the R5 router, however none of the routes are
active.
Step 2.20
Use the show route receive-protocol bgp 192.168.xy.4 detail
command to display the routes being received from the R5 router.
lab@mxB-1> show route receive-protocol bgp 192.168.xy.4 detail
lab@mxB-1>
Question: How many routes received from R5 are

hidden?
Answer: There are five hidden routes.
Step 2.21
Use the 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@mxB-1>
Question: Why are the routes received from the R5

router marked as unusable?
Answer: The next-hop attribute in the routes

being received from the R5 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.22
Enter configuration mode and navigate to the [edit logical-systems R5-z
protocols bgp group cbgp] hierarchy. Configure the next-hop-self
policy as the group export policy. Commit the configuration and return to operational
mode.
[edit]
lab@mxB-1# edit logical-systems R5-z protocols bgp group cbgp


commit complete
lab@mxB-1>
Step 2.23
Use the show route receive-protocol bgp 192.168.xy.4 command to
display the routes being received from the R5 router.

lab@mxB-1> show route receive-protocol bgp 192.168.xy.4

* 40.40.0.0/24 192.168.20.4 100 (65201) 65020 I
* 40.40.1.0/24 192.168.20.4 100 (65201) 65020 I
* 40.40.2.0/24 192.168.20.4 100 (65201) 65020 I
* 40.40.3.0/24 192.168.20.4 100 (65201) 65020 I
192.168.21.0/24 192.168.20.4 100 (65201) 65020
65002 I
lab@mxB-1>
Question: Are the routes being received from R5

active routes?
Answer: The five routes being received from R5 are

active routes.

Advanced Junos Service Provider
Routing
Appendix A: Lab Diagrams

A–2 • Lab Diagrams www.juniper.net

www.juniper.net Lab Diagrams • A–3






AJSPR 10.a-R LGD PDF

Uploaded by

Copyright:

Available Formats

AJSPR 10.a-R LGD PDF

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 10.a-R LGD PDF

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 1: OSPF Multiarea Networks (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization

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: BGP Route Damping (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Lab 11: Scaling BGP (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

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: Verifying Router Configuration

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

--- JUNOS 10.3R1.9 built 2010-08-13 12:48:28 UTC

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

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

--- 172.22.121.2 ping statistics ---

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

Answer: The pings should be successful. If not,

--- JUNOS 10.3R1.9 built 2010-08-13 12:48:28 UTC

Connection closed by foreign host.

Question: Were you successful? If not, please notify

Answer: The Telnet should be successful.

Part 2: Verifying Route Information

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

20.20.0.0/24 *[Static/5] 00:03:13

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

Question: How many static route entries are in your

Answer: There should be four static route entries.

Part 3: Creating the Network

In this lab part, you create the network.

Question: Which routers are area border routers

Answer: The student device main routing instances

Question: Which routers are backbone routers?

Answer: The vr-device is a backbone router.

Question: Which routers are internal routers?

Answer: The routing instances on the MX80s are

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

[edit protocols ospf]