Jncie-Sp-12.a LG v1

JNCIE Service Provider Bootcamp
12.a
Lab Guide
Volume 1
Worldwide Education Services
1133 Innovation Way

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Course Number: EDU-JUN-JNCIE-SP

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.
JNCIE Service Provider Bootcamp Lab Guide, Revision 12.a
Copyright © 2015 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 10.a—September 2011
Revision 10.b—March 2012
Revision 12.a—February 2015
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 12.3. 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: Implementing Device Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Implementing Device Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Lab 2: IS-IS Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Implementing IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Lab 3: OSPF Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Implementing OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Lab 4: IS-IS Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Troubleshooting IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Lab 5: OSPF Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Troubleshooting OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
www.juniper.net Contents • iii

iv • Contents www.juniper.net
Course Overview
This five-day course is designed to serve as the ultimate preparation for the Juniper Networks Certified Internet Expert—
Service Provider (JNCIE-SP) exam. The course focuses on caveats and tips useful for potential test candidates and
emphasizes hands-on practice through a series of timed lab simulations. On the final day of the course, students are
given a six-hour lab simulation emulating the testing topics and environment from the real exam. All labs in this course
are facilitated by Junosphere Cloud (formerly known as Junosphere) virtual lab devices and are available after hours for
additional practice time. This course is based on Junos OS Release 12.3.
Objectives
After successfully completing this course, you should:
• Be better prepared for success in taking the actual JNCIE-SP exam.
• Be well-versed in exam topics, environment, and conditions.
Intended Audience
This course benefits individuals who have already honed their skills on service provider technologies and could use
some practice and tips in preparation for the JNCIE-SP exam.
Course Level
JNCIE Service Provider Bootcamp is an advanced-level course.
Prerequisites
Students should have passed the Juniper Networks Certified Internet Professional—Service Provider (JNCIP-SP) written
exam or achieved an equal level of expertise through Education Services courseware and hands-on experience.
www.juniper.net Course Overview • v

Course Agenda
Day 1
Chapter 1: Course Introduction
Chapter 2: Exam Strategies
Chapter 3: Device Infrastructure
Implementing Device Infrastructure Lab
Chapter 4: IGP Implementation
IS-IS Implementation Lab
OSPF Implementation Lab
Day 2
Chapter 5: IGP Troubleshooting
IS-IS Troubleshooting Lab
OSPF Troubleshooting Lab
Chapter 6: BGP Implementation
BGP Implementation Lab
Chapter 7: BGP Troubleshooting
BGP Troubleshooting Lab
Day 3
Chapter 8: Multicast Implementation
Multicast Implementation and Troubleshooting Lab
Chapter 9: Class of Service Implementation
Class of Service Implementation and Troubleshooting Lab
Day 4
Chapter 10: MPLS Implementation
MPLS Implementation and Troubleshooting Lab
Chapter 11: MPLS VPN Implementation
MPLS VPN Implementation and Troubleshooting Lab
Day 5
JNCIE-SP Full Lab Simulation
vi • Course Agenda www.juniper.net

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 plain 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.
www.juniper.net Document Conventions • vii

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 JNCIE Service Provider Bootcamp Lab Guide was developed and tested using the Junos software Release 12.3.
Previous and later versions of software might behave differently so you should always consult the documentation and
release notes for the version of code you are running before reporting errors.
This document is written and maintained by the Juniper Networks Education Services development team. Please send
questions and suggestions for improvement to training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
• Go to http://www.juniper.net/techpubs/.
• Locate the specific software or hardware release and title you need, and choose the format in which you
want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.
Juniper Networks Support
For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or at 1-888-314-JTAC
(within the United States) or 408-745-2121 (from outside the United States).
viii • Additional Information www.juniper.net

Lab
Implementing Device Infrastructure
Overview
In this lab, you will be given a list of tasks specific to device infrastructure to accomplish in a
timed setting. You will have 1 hour to complete the simulation.
By completing this lab, you will perform the following tasks:
• Configure the aggregated Ethernet interfaces ae0, ae1, and ae2. Refer to the lab
diagram for the routers and member interfaces associated with these aggregated
Ethernet interfaces.
• Configure all aggregated Ethernet interfaces to monitor the member links to ensure
that both ends of the bundle are connected to the correct group. Configure R4 to
initiate this process for all aggregated Ethernet interfaces.
• Ensure that the aggregated Ethernet bundle between R2 and R4 always supports a
bandwidth capacity of at least 2.5 Gbps. Traffic must not be forwarded across this
bundle if this requirement is not met at any time.
• Enable graceful restart for all routing protocols except BGP and OSPF on the internal
routers.
• High availability is required for the DC3 router connected to R3 and R5. Configure a
VRRP group in which R3 is the master for the 172.20.20.0/24 range. R5 must
acquire mastership if three of R3’s internal interfaces fail. If a failover condition
occurs for the VRRP group, and that failover condition is restored, R3 must not regain
mastership. Refer to the lab diagram for the specific interfaces and virtual IP
address.
• High availability is required for the data centers, DC1 and DC2, that are connected to
R2 and R4. Configure two VRRP groups in which R2 is the master for the
172.20.21.0/24 range in VRRP group 100. R4 is the master for the 172.20.22.0/24
range in VRRP group 200. Use 802.1q tag values that match the corresponding
VRRP group identifiers. If the link between R2 and R1 fails, R4 must acquire
mastership for VRRP group 100. If any member interface of the ae0 interface fails,
R2 must acquire mastership for VRRP group 200. Refer to the lab diagram for the
specific interfaces and virtual IP addresses.
• Configure all internal routers to communicate with the RADIUS server located at
172.27.155.1 using the secret key of Juniper.
www.juniper.net Implementing Device Infrastructure • Lab 1–1

• Configure two local users, jack and jill, on all internal routers and provide them
with full access to the routers.
• Create a user group named design on all internal routers. These users will
authenticate with the RADIUS server. This group will have full access to the routers but
will not be able to restart system processes, reboot, halt the routers, or power down
the routers.
• Create a user group named support on all internal routers. These users will
authenticate with the RADIUS server. Any users of this group can only view the
configuration and issue read-only commands.
• Allow jack and jill to authenticate locally on the routers only if the RADIUS server
is unreachable.
• Ensure that all internal routers disallow root access through the console port.
• Ensure that the control plane of router R5 is protected from malicious attacks.
Configure a firewall filter with the following criteria:
– Permit essential protocols already running on the router. For example, all IS-IS,
OSPF, and LDP adjacencies must be maintained.
– Ensure that BGP messages are only accepted from configured neighbors. Any
additional BGP neighbors that are added later must not require a configuration
change to this firewall filter.
– Allow any SSH connections from the 172.27.0.0/16 range. Log and silently
discard any SSH connections attempted from outside this range.
– Allow RADIUS authentication messages.
– All other traffic must be silently discarded.
• Log and silently discard all instances of IPv4 or IPv6 traffic that are coming from
transit peers and have the source address of 172.27.0.0/16 or 2008:4498::/32. This
information must be recoverable after a reboot.
• On router R4, configure the syslog file Monitor-Agg-Eth to only log information
associated with its local aggregated Ethernet interfaces. To conserve space on the
routers, only 20 files of this information can be stored locally. Each file can be no
more than 1 MB in size.
• Configure all internal routers to send any commands executed by users through the
CLI to the server located at 172.27.155.1.
• Ensure that the configuration of all internal routers is backed up every 15 minutes to
the internal server located at 172.27.155.1. Use SCP to encrypt these transmissions
and store the configurations in the /var/tmp/ directory on the server. Use the root
username with the password Clouds to authenticate with the internal server.
• The backbone-mtu.slax commit script is available to assist you in checking core
interface MTU values. The commit script is located on the internal server at
172.27.155.1 in the /etc/ directory. Because the commit script might change in the
future, configure all internal routers to refresh and retrieve the commit script through
SCP. Use the root username with the password Clouds to authenticate with the
internal server.
• Change any interface physical MTU value to the MTU value the script recommends.
Lab 1–2 • Implementing Device Infrastructure www.juniper.net

Implementing Device Infrastructure

In this lab part, you will become familiar with the configuring, monitoring, and testing of high
availability features found in the Junos operating system. You will first explore the usage of
aggregated Ethernet interfaces. Then, you will enable graceful restart on the routers. Next, you
will configure and monitor the usage of VRRP. You will then become familiar with the features in
the Junos OS that allow an administrator to secure and monitor Junos devices. You will configure
a user account to authenticate with a RADIUS server. You will then configure firewall filters to
protect the devices in your network. Then, you will configure the routers to periodically backup
the configurations to a server. Next, you will become familiar with the basic functions of Junos
automation. You will configure the routers to load a commit script from a remote server.
Note
We recommend that you spend some time
investigating the current operation of your
routers. During the real exam, you might be
given routers that are operating
inefficiently. Investigating operating issues
now might save you a lot of time
troubleshooting strange issues later.
Make sure you read through all tasks

required for this lab and understand the
different dependencies. Some of the tasks
can be completed at the same time. This is
a great opportunity to save time during the
exam. We have grouped common tasks
together in this lab guide to simplify
configuration steps, but feel free to order
your tasks in any way that makes sense to
you.
TASK 1
Access the CLI for your routers using either the console, Telnet, or SSH as directed by your
instructor. Refer to the management network diagram for the IP address associated with your
devices. Log in as user lab with the password lab123.
Configure the aggregated Ethernet interfaces ae0, ae1, and ae2.
Refer to the Lab 1 diagram for the routers and member interfaces
associated with these aggregated Ethernet interfaces.
Question: On which routers is it necessary to configure

aggregated Ethernet interfaces?
Answer: The lab diagram shows that it is necessary to configure

R1, R2, R4, and R5 with aggregated Ethernet interfaces.

Question: Which steps are necessary to create an operational
aggregated Ethernet interface?
Answer: First, set the Ethernet aggregated device count to

accommodate the number of aggregated Ethernet interfaces.
Second, create and associate the underlying member interfaces
with the aggregated Ethernet bundle. Third, create the
aggregated Ethernet interface.
TASK INTERPRETATION
The task appears to be a simple one, but problems might arise if the Ethernet aggregated device
count is not set properly. For example, even though R5 has only one aggregated Ethernet
interface, setting the Ethernet aggregated device count to 1 will result in a non-operational ae2
interface. The device count for R5 must be set to 3 or higher. This setting results in the creation
of interfaces ae0, ae1, and ae2, which is expected for this task.
After the Ethernet device count is set, associate the correct member interfaces with the correct
aggregated Ethernet bundle. Then, configure the aggregated Ethernet interface as you would any
other Gigabit interface on the router.
TASK COMPLETION
• R1:
R1 (ttyd0)
login: lab
Password:
--- JUNOS 12.3I20130406_1317_anjali (kernel) #1: 2013-04-06 13:40:14 UTC
lab@R1> configure
Entering configuration mode
[edit]
lab@R1# set chassis aggregated-devices ethernet device-count 2
[edit]
lab@R1# edit interfaces
[edit interfaces]
lab@R1# set ge-0/0/4 gigether-options 802.3ad ae1
[edit interfaces]
[edit interfaces]
lab@R1# edit ae1

[edit interfaces ae1]
lab@R1# set unit 0 family inet address 172.27.0.10/30

lab@R1# show
unit 0 {
family inet {
address 172.27.0.10/30;
}
}

lab@R1# commit
commit complete
• R2:
R2 (ttyd0)
login: lab
Password:
lab@R2> configure
[edit]
[edit]
[edit interfaces]
[edit interfaces]
[edit interfaces]
[edit interfaces]
lab@R2# edit ae0


lab@R2# show
unit 0 {
family inet {
address 172.27.0.5/30;
}

}

lab@R2# commit
commit complete
• R4:
R4 (ttyd0)
login: lab
Password:
lab@R4> configure
[edit]
[edit]
[edit interfaces]
[edit interfaces]
[edit interfaces]
[edit interfaces]
[edit interfaces]
[edit interfaces]
[edit interfaces]
[edit interfaces]
lab@R4# edit ae0


lab@R4# up

[edit interfaces]
lab@R4# edit ae1


lab@R4# up
[edit interfaces]
lab@R4# edit ae2


lab@R4# up
[edit interfaces]
lab@R4# show
...
ge-0/0/6 {
description "Connection to R1 AE1";
gigether-options {
802.3ad ae1;
}
}
ge-0/0/7 {
gigether-options {
802.3ad ae1;
}
}
ge-0/0/8 {
description "Connection to internal server";
unit 0 {
family inet {
address 172.27.155.5/24;
}
}
}
ge-0/0/9 {
gigether-options {
802.3ad ae0;
}
}
ge-0/0/10 {
gigether-options {
802.3ad ae0;
}
}
ge-0/0/11 {

gigether-options {
802.3ad ae0;
}
}
ge-0/0/12 {
gigether-options {
802.3ad ae2;
}
}
ge-0/0/13 {
gigether-options {
802.3ad ae2;
}
}
ae0 {
unit 0 {
family inet {
address 172.27.0.6/30;
}
}
}
ae1 {
unit 0 {
family inet {
address 172.27.0.9/30;
}
}
}
ae2 {
unit 0 {
family inet {
address 172.27.0.21/30;
}
}
}
...
[edit interfaces]
lab@R4# commit
commit complete
• R5:
R5 (ttyd0)
login: lab
Password:
lab@R5> configure

[edit]
[edit]
[edit interfaces]
[edit interfaces]
[edit interfaces]
lab@R5# edit ae2


lab@R5# show
unit 0 {
family inet {
address 172.27.0.22/30;
}
}

lab@R5# commit
commit complete
TASK VERIFICATION
All aggregated Ethernet bundles terminate on R4, which allows you to verify all the bundles from
one router. Issuing the show interfaces terse | match ae* command displays which
member interfaces are associated with aggregated Ethernet bundles. This command also
displays the status of each aggregated Ethernet interface.
However, we recommend issuing ping tests to ensure that the interfaces are functional. A few
ping replies from each router allows you to determine if the aggregated Ethernet bundles are
operational.
[edit interfaces]
lab@R4# run show interfaces terse | match ae*
Interface Admin Link Proto Local Remote
ge-0/0/6.0 up up aenet --> ae1.0
ge-0/0/10.0 up up aenet --> ae0.0
ge-0/0/11.0 up up aenet --> ae0.0
ge-0/0/12.0 up up aenet --> ae2.0
ge-0/0/13.0 up up aenet --> ae2.0
ae0 up up
ae0.0 up up inet 172.27.0.6/30
ae1 up up

ae1.0 up up inet 172.27.0.9/30
ae2 up up
ae2.0 up up inet 172.27.0.21/30
tap up up
vlan up down
[edit interfaces]
lab@R4# run ping 172.27.0.5 detail count 2
PING 172.27.0.5 (172.27.0.5): 56 data bytes
64 bytes from 172.27.0.5 via ae0.0: icmp_seq=0 ttl=64 time=3.920 ms
--- 172.27.0.5 ping statistics ---

2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.558/3.739/3.920/0.181 ms
[edit interfaces]
PING 172.27.0.10 (172.27.0.10): 56 data bytes

[edit interfaces]
PING 172.27.0.22 (172.27.0.22): 56 data bytes

TASK 2
Configure all aggregate Ethernet interfaces to monitor the member
links to ensure both ends of the bundle are connected to the correct
group. Configure R4 to initiate this process for all aggregated
Ethernet interfaces.
Question: Which feature allows for the monitoring of member

links in an aggregated Ethernet bundle?
Answer: LACP allows for the monitoring of member links in an

aggregated Ethernet bundle.

TASK INTERPRETATION
LACP must be configured on each router that has an aggregated Ethernet interface. However,
the key to this task is to configure R4 with the active command under LACP. This configuration
allows R4 to initiate the communication for all aggregated Ethernet interfaces. Routers R1, R2,
and R5 must set their LACP modes to passive for their respective bundles.
TASK COMPLETION
• R1:
lab@R1# set aggregated-ether-options lacp passive

lab@R1# commit
commit complete
• R2:

lab@R2# commit
commit complete
• R4:
[edit interfaces]
lab@R4# set ae0 aggregated-ether-options lacp active
[edit interfaces]
[edit interfaces]
[edit interfaces]
lab@R4# show
...
ae0 {
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family inet {
address 172.27.0.6/30;
}
}
}
ae1 {

lacp {
active;
}
}
unit 0 {
family inet {
address 172.27.0.9/30;
}
}
}
ae2 {
lacp {
active;
}
}
unit 0 {
family inet {
address 172.27.0.21/30;
}
}
...
[edit interfaces]
lab@R4# commit
commit complete
• R5:

lab@R5# commit
commit complete
TASK VERIFICATION
The following output displays which member interfaces for the aggregated Ethernet bundles are
in the active mode. R4’s output shows that its local interface, which is designated with the
keyword Actor, is in the Active state. The remote interface of the local interface, which is
designated with the keyword Partner, is in the Passive state.
[edit interfaces]
lab@R4# run show lacp interfaces
Aggregated interface: ae0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/10 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/10 Partner No No Yes Yes Yes Yes Fast Passive

LACP protocol: Receive State Transmit State Mux State
ge-0/0/10 Current Fast periodic Collecting distributing


TASK 3
Ensure that the aggregated Ethernet bundle between R2 and R4 always
supports a bandwidth capacity of at least 2.5 Gbps. Traffic must not
be forwarded across this bundle if this requirement is not met at
any time.
Question: Which command will show the current bandwidth

capacity for this aggregated Ethernet bundle?
Answer: The show interfaces ae0 command on R2 or R4

displays the current bandwidth capacity for the aggregated
Ethernet bundle.
TASK INTERPRETATION
With all three Gigabit links functional, the aggregated Ethernet link between R2 and R4 currently
has a bandwidth capacity of 3 Gbps. If any of the links fails, the bandwidth capacity will drop
below the required 2.5 Gbps. To accomplish this task you must enable the minimum-links
statement with a value of 3. This value will allow the routers to take the aggregated Ethernet
interface down if one of the three member links fails. Remember to enable this command on
both R2 and R4; failure to do so will cause one router to view the bundle as operational.

TASK COMPLETION
• R2:
lab@R2# set aggregated-ether-options minimum-links 3

lab@R2# commit
• R4:
[edit interfaces]
lab@R4# set ae0 aggregated-ether-options minimum-links 3
[edit interfaces]
lab@R4# commit
TASK VERIFICATION
Issuing the show interfaces ae0 command enables you to determine if the interface is
configured to go down if fewer than three operational member links are associated with it.
We can test this functionality by disabling any member interface of ae0. Once a member
interface is disabled, the aggregated Ethernet interface is declared down.
Note
Remember to delete the disable
statement from any interfaces that were
taken down to test failover scenarios.
Forgetting to do so might result in a point
deduction elsewhere in the exam.
[edit interfaces]
lab@R4# run show interfaces ae0 | match minimum
Flow control: Disabled, Minimum links needed: 3, Minimum bandwidth needed: 0
[edit interfaces]
lab@R4# run show interfaces terse | match ae0
ge-0/0/10.0 up up aenet --> ae0.0
ge-0/0/11.0 up up aenet --> ae0.0
ae0 up up
ae0.0 up up inet 172.27.0.6/30
[edit interfaces]
lab@R4# set ge-0/0/9 disable
[edit interfaces]
lab@R4# commit
commit complete
[edit interfaces]
lab@R4# run show interfaces terse | match ae0
ge-0/0/9.0 up down aenet --> ae0.0
ge-0/0/10.0 up up aenet --> ae0.0
ge-0/0/11.0 up up aenet --> ae0.0
ae0 up down
ae0.0 up down inet 172.27.0.6/30
[edit interfaces]
lab@R4# delete ge-0/0/9 disable
[edit interfaces]
lab@R4# commit
commit complete
TASK 4
Enable Graceful Restart for all routing protocols except BGP and
OSPF on the internal routers.
Question: How do you enable graceful restart for IS-IS?
Answer: Graceful restart is enabled globally under the [edit

routing-options] hierarchy level.
TASK INTERPRETATION
Turning on graceful restart is accomplished by enabling it globally under the [edit
routing-options] hierarchy. Then, you must disable it for any routing protocols in which you
do not want it to participate.
In this task, all internal routers must have graceful restart disabled for BGP. Only R5 is running
OSPF and requires that graceful restart be disabled for it.
TASK COMPLETION
• R1:
lab@R1# top edit routing-options
[edit routing-options]
lab@R1# set graceful-restart
lab@R1# top edit protocols bgp
[edit protocols bgp]

lab@R1# set graceful-restart disable

lab@R1# commit
commit complete

• R2:


lab@R2# commit
commit complete
• R3:
R3 (ttyd0)
login: lab
Password:
lab@R3> configure
[edit]
lab@R3# edit routing-options


lab@R3# commit
commit complete
• R4:
[edit interfaces]



lab@R4# commit
commit complete
• R5:



lab@R5# up 1 edit ospf
[edit protocols ospf]


lab@R5# commit
commit complete
TASK VERIFICATION
To check the status of graceful restart, you must examine each routing protocol for which it is
enabled or disabled. The following output displays the status of graceful restart for BGP, OSPF,
and IS-IS on R5. It is currently disabled for BGP and OSPF, but it is enabled for IS-IS.
lab@R5# run show bgp neighbor | match graceful
Options: <GracefulRestartHelperDisabled>
Options: <GracefulRestartHelperDisabled>

lab@R5# run show ospf overview
Instance: master
Router ID: 172.27.255.5
Route table index: 0
LSA refresh time: 50 minutes
Restart: Disabled

Area: 0.0.0.0
Stub type: Not Stub
Authentication Type: None
Area border routers: 0, AS boundary routers: 0
Neighbors
Up (in full state): 1
Topology: default (ID 0)
Prefix export count: 0
Full SPF runs: 7
SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3
Backup SPF: Not Needed

lab@R5# run show isis overview
Instance: master
Router ID: 172.27.255.5
Adjacency holddown: enabled
Maximum Areas: 3
LSP life time: 1200
Attached bit evaluation: enabled
SPF delay: 200 msec, SPF holddown: 5000 msec, SPF rapid runs: 3
IPv4 is enabled, IPv6 is enabled
Traffic engineering: enabled
Restart: Enabled
Restart duration: 210 sec
Helper mode: Enabled
Level 1
Internal route preference: 15
External route preference: 160
Wide metrics are enabled, Narrow metrics are enabled
Level 2
TASK 5
High availability is required for the DC3 router connected to R3 and
R5. Configure a VRRP group in which R3 is the master for the
172.20.20.0/24 range. R5 must acquire mastership if three of R3’s
internal interfaces fail. If a failover condition occurs for the
VRRP group, and that failover condition is restored, R3 must not
regain mastership. Refer to the lab diagram for the specific
interfaces and virtual IP address.
Question: Where in the configuration hierarchy is VRRP

configured?
Answer: VRRP is configured under the IPv4 address of an

interface.

TASK INTERPRETATION
This task might seem straightforward, but be careful with the condition that R3 cannot regain
mastership if it is lost. By default, VRRP is set to preempt mastership, which means that R3 will
regain mastership once the failover condition is restored. Add the no-preempt command to
R3’s configuration to accommodate this requirement. It is not necessary to set this command
on R5.
Also, be careful of the VRRP priority values you assign to R3 and R4 in relation to the interface
tracking values set on R3. The interface tracking values must cause a failover only if R3’s ge-0/
0/1, ge-0/0/2, and ge-0/0/3 interfaces fail. Set the total of all three interface tracking values to
bring R3’s VRRP priority just below R5’s VRRP priority.
TASK COMPLETION
• R3:
lab@R3# top edit interfaces ge-0/0/4
[edit interfaces ge-0/0/4]

lab@R3# edit unit 0 family inet address 172.20.20.3/24 vrrp-group 1
[edit interfaces ge-0/0/4 unit 0 family inet address 172.20.20.3/24 vrrp-group 1]

lab@R3# set priority 174

lab@R3# set no-preempt

lab@R3# set virtual-address 172.20.20.100

lab@R3# set track interface ge-0/0/1 priority-cost 25



lab@R3# show
virtual-address 172.20.20.100;
priority 174;
no-preempt;
track {
interface ge-0/0/1 {
priority-cost 25;
}
priority-cost 25;
}
priority-cost 25;
}

}

lab@R3# commit
commit complete
• R5:

lab@R5# edit unit 0 family inet address 172.20.20.5/24 vrrp-group 1



lab@R5# show
priority 100;

lab@R5# commit
commit complete
TASK VERIFICATION
The show vrrp detail command contains all the information necessary to determine the
status of the VRRP group. Specifically, it gives you the state of the VRRP member, the VRRP
priority, the preempt status, the virtual IP address, and the interfaces being tracked. From this
output you can see if all the conditions of this task are met.
You can test a failover condition by setting the necessary interfaces on R3 to the disabled state.
First, set the ge-0/0/1 and ge-0/0/2 interfaces to the disabled state and commit the
configuration. R3 retains mastership for the VRRP group. Set the ge-0/0/3 interface on R3 to the
disabled state and commit the configuration again. R3 loses mastership to R5. You can now test
if R5 will retain the mastership if R3’s recently disabled interfaces are restored. Delete the
disable statements that you recently configured on R3’s interfaces and issue the show vrrp
detail command again. R5 now retains mastership for the VRRP as per the conditions in the
task.
• R3:
lab@R3# run show vrrp detail
Physical interface: ge-0/0/4, Unit: 0, Address: 172.20.20.3/24
Index: 73, SNMP ifIndex: 519, VRRP-Traps: disabled
Interface state: up, Group: 1, State: master, VRRP Mode: Active
Priority: 174, Advertisement interval: 1, Authentication type: none
Delay threshold: 100, Computed send rate: 0

Preempt: no, Accept-data mode: no, VIP count: 1, VIP: 172.20.20.100
Advertisement Timer: 0.114s, Master router: 172.20.20.3
Virtual router uptime: 01:07:34, Master router uptime: 00:00:10
Virtual Mac: 00:00:5e:00:01:01
Tracking: enabled
Current priority: 174, Configured priority: 174
Priority hold time: disabled
Interface tracking: enabled, Interface count: 3
Interface Int state Int speed Incurred priority cost
ge-0/0/1.0 up 1g 0
ge-0/0/2.0 up 1g 0
ge-0/0/3.0 up 1g 0
Route tracking: disabled
• R5:
Interface state: up, Group: 1, State: backup, VRRP Mode: Active
Preempt: yes, Accept-data mode: no, VIP count: 1, VIP: 172.20.20.100
Dead timer: 2.835s, Master priority: 174, Master router: 172.20.20.3
Virtual router uptime: 00:32:35
Tracking: disabled
• R3:
lab@R3# up 5
[edit interfaces]
[edit interfaces]
[edit interfaces]
lab@R3# commit
commit complete
[edit interfaces]
Virtual Mac: 00:00:5e:00:01:01

Tracking: enabled
ge-0/0/1.0 down 0 25
ge-0/0/2.0 down 0 25
ge-0/0/3.0 up 1g 0
[edit interfaces]
[edit interfaces]
lab@R3# commit
commit complete
[edit interfaces]
Tracking: enabled
ge-0/0/1.0 down 0 25
ge-0/0/2.0 down 0 25
ge-0/0/3.0 down 0 25
[edit interfaces]
[edit interfaces]
[edit interfaces]
[edit interfaces]
lab@R3# commit
commit complete
[edit interfaces]

Tracking: enabled
ge-0/0/1.0 up 1g 0
ge-0/0/2.0 up 1g 0
ge-0/0/3.0 up 1g 0
TASK 6
High availability is required for the data centers, DC1 and DC2,
that are connected to R2 and R4. Configure two VRRP groups in which
R2 is the master for the 172.20.21.0/24 range in VRRP group 100. R4
is the master for the 172.20.22.0/24 range in VRRP group 200. Use
802.1q tag values that match the corresponding VRRP group
identifiers. If the link between R2 and R1 fails, R4 must acquire
mastership for VRRP group 100. If any member interface of the ae0
interface fails, R2 must acquire mastership for VRRP group 200.
Refer to the Lab 1 diagram for the specific interfaces and virtual
IP addresses.
Question: Which VLAN ID values should you use for the units
associated with VRRP groups 100 and 200?
Answer: The unit associated with VRRP group 100 should use
VLAN ID 100. The unit associated with VRRP group 200 should
use VLAN ID 200.
TASK INTERPRETATION
This task is similar to the previous task, in that you are configuring VRRP again. However, the
interfaces involved in VRRP are being shared between two VRRP groups on two different logical
interfaces, which requires VLAN tagging to be enabled. Be careful when configuring the different
VRRP groups, and configure the VLAN IDs to be the same as the VRRP group values. We also
recommend that the unit number match the VLAN ID values.

The interface monitoring on R2 is straightforward and easy to configure. However, the interface
monitoring criterion on R4 might pose a problem. It can be accomplished in two ways. First, you
can configure interface monitoring on all member interfaces of ae0. This configuration will
require you to set appropriate priority tracking values on each interface that will cause a failover
of the VRRP group. Second, you can configure interface monitoring on the aggregated Ethernet
bundle. Remember, in an earlier task, you set the aggregated Ethernet bundle to be declared
down if one member link fails. Now, if any member interface of the aggregated Ethernet bundle
is declared down, a failover of the VRRP group will occur. The second method discussed is the
better, and simpler, way to accomplish this task.
TASK COMPLETION
• R2:

lab@R2# set vlan-tagging

lab@R2# edit unit 100
[edit interfaces ge-0/0/3 unit 100]

lab@R2# set vlan-id 100

lab@R2# edit family inet address 172.20.21.2/24 vrrp-group 100
[edit interfaces ge-0/0/3 unit 100 family inet address 172.20.21.2/24 vrrp-group
100]
100]
100]
100]
lab@R2# up 4



200]
200]
200]
lab@R2# up 4

lab@R2# show
description "VRRP connection to DC1 & DC2";
vlan-tagging;
unit 100 {
vlan-id 100;
family inet {
address 172.20.21.2/24 {
vrrp-group 100 {
priority 200;
track {
priority-cost 101;
}
}
}
}
}
}
unit 200 {
vlan-id 200;
family inet {
address 172.20.22.2/24 {
vrrp-group 200 {
priority 100;
}
}
}
}

lab@R2# commit
commit complete
• R4:

lab@R4# set vlan-tagging



100]
100]
100]
lab@R4# up 4



200]
200]
200]
lab@R4# set track interface ae0 priority-cost 101
200]
lab@R4# up 4

lab@R4# show
description "VRRP connection to DC1 & DC2";
vlan-tagging;
unit 100 {
vlan-id 100;
family inet {
address 172.20.21.4/24 {
vrrp-group 100 {

priority 100;
}
}
}
}
unit 200 {
vlan-id 200;
family inet {
address 172.20.22.4/24 {
vrrp-group 200 {
priority 200;
track {
interface ae0 {
priority-cost 101;
}
}
}
}
}
}

lab@R4# commit
commit complete
TASK VERIFICATION
The show vrrp detail command produces all necessary information to verify this task.
Then, by disabling a member interface in the ae0 bundle, you can examine the failover process
of VRRP group 200. Then, by disabling the ge-0/0/1 interface on R2, you can see the failover
process of VRRP group 100.
Note
Remember to delete the disable
statement from any interfaces that were
taken down to test failover scenarios.
Forgetting to do so might result in a point
deduction elsewhere in the exam.
• R4:
Physical interface: ge-0/0/2, Unit: 100, Vlan-id: 100, Address: 172.20.21.4/24
Tracking: disabled

Virtual Mac: 00:00:5e:00:01:c8
Tracking: enabled
ae0.0 up 3g 0

lab@R4# up 1 set ge-0/0/9 disable

lab@R4# commit
commit complete

Tracking: disabled

Tracking: enabled
ae0.0 down 0 101

lab@R4# up 1 delete ge-0/0/9 disable


lab@R4# commit
commit complete
• R2:
Virtual Mac: 00:00:5e:00:01:64
Tracking: enabled
ge-0/0/1.0 up 1g 0

Tracking: disabled

lab@R2# up 1 set ge-0/0/1 disable

lab@R2# commit
commit complete


Tracking: enabled
ge-0/0/1.0 down 0 101

Tracking: disabled

lab@R2# up 1 delete ge-0/0/1 disable

lab@R2# commit
commit complete
TASK 7
Configure all internal routers to communicate with the RADIUS server
located at 172.27.155.1 using the secret key of “Juniper”.
Question: Where in the configuration hierarchy is the RADIUS

server configured?
Answer: The RADIUS server is configured in the [edit

system] hierarchy level.
TASK INTERPRETATION
To accomplish this task you must configure the router to communicate with the RADIUS server
with the secret key of Juniper. However, remember to configure this on all internal routers.
Forgetting to do so on a live exam will result in lost points for the task. There is no need to
commit the configuration after this task, but doing so does no harm.
TASK COMPLETION
• R1:
lab@R1# top edit system
[edit system]
lab@R1# set radius-server 172.27.155.1 secret Juniper

• R2:
[edit system]
• R3:
[edit interfaces]
[edit system]
• R4:
[edit system]
• R5:
[edit system]
TASK VERIFICATION
Communication with the RADIUS server cannot be verified yet.
TASK 8
Configure two local users, jack and jill, on all internal routers
and provide them with full access to the routers.
Question: Which predefined user class will give these users full
access to the routers?
Answer: The super-user class will give these users full

access to the routers.
TASK INTERPRETATION
This task requires you to configure two local users and assign them the super-user class.
The passwords that are given to them is completely up to you. However, remember these
passwords because you will use them to verify the users authorization levels.

TASK COMPLETION
• R1:
[edit system]
lab@R1# set login user jack class super-user authentication plain-text-password
New password:
Retype new password:
[edit system]
lab@R1# set login user jill class super-user authentication plain-text-password
New password:
[edit system]
lab@R1# commit
commit complete
• R2:
[edit system]
New password:
[edit system]
New password:
[edit system]
lab@R2# commit
commit complete
• R3:
[edit system]
New password:
[edit system]
New password:
[edit system]
lab@R3# commit
commit complete

• R4:
[edit system]
New password:
[edit system]
New password:
[edit system]
lab@R4# commit
commit complete
• R5:
[edit system]
New password:
[edit system]
New password:
[edit system]
lab@R5# commit
commit complete
TASK VERIFICATION
To verify the task, log out of the router and then log in as user jack or jill. Once you have
logged in to the router, issue the show cli authorization command to view the
permissions assigned to the user.
[edit system]
lab@R1# exit configuration-mode
Exiting configuration mode
lab@R1> exit
R1 (ttyd0)
login: jack
Password:

jack@R1> show cli authorization
Current user: 'jack ' class 'super-user'
Permissions:

admin -- Can view user accounts
admin-control-- Can modify user accounts
clear -- Can clear learned network info
configure -- Can enter configuration mode
control -- Can modify any config
edit -- Can edit full files
field -- Can use field debug commands
floppy -- Can read and write the floppy
interface -- Can view interface configuration
interface-control-- Can modify interface configuration
network -- Can access the network
reset -- Can reset/restart interfaces and daemons
routing -- Can view routing configuration
routing-control-- Can modify routing configuration
shell -- Can start a local shell
snmp -- Can view SNMP configuration
snmp-control-- Can modify SNMP configuration
system -- Can view system configuration
system-control-- Can modify system configuration
trace -- Can view trace file settings
trace-control-- Can modify trace file settings
view -- Can view current values and statistics
maintenance -- Can become the super-user
firewall -- Can view firewall configuration
firewall-control-- Can modify firewall configuration
secret -- Can view secret statements
secret-control-- Can modify secret statements
rollback -- Can rollback to previous configurations
security -- Can view security configuration
security-control-- Can modify security configuration
access -- Can view access configuration
access-control-- Can modify access configuration
view-configuration-- Can view all configuration (not including secrets)
flow-tap -- Can view flow-tap configuration
flow-tap-control-- Can modify flow-tap configuration
idp-profiler-operation-- Can Profiler data
pgcp-session-mirroring-- Can view pgcp session mirroring configuration
pgcp-session-mirroring-control-- Can modify pgcp session mirroring
configuration
all-control -- Can modify any configuration
Individual command authorization:
Allow regular expression: none
Deny regular expression: none
Allow configuration regular expression: none
Deny configuration regular expression: none
jack@R1> exit
R1 (ttyd0)
login: lab
Password:

lab@R1>
TASK 9
Create a user group named design on all internal routers. These
users will authenticate with the RADIUS server. This group will
have full access to the routers but will not be able to restart
system processes, reboot, halt the routers, or power down the
routers.
Question: Can users of the design group log in to the router if

the RADIUS server is not reachable from the router? Why?
Answer: No local users are configured for the design group. If

the router cannot communicate with the RADIUS server, users
from this group will not be able to log in to the router.
TASK INTERPRETATION
In this task, you create a user template that the router uses to assign permissions to users who
first authenticate with the RADIUS server. In this user template, you define a custom class that
gives full permissions but restricts the users from issuing any commands that contain the
statements restart, reboot, power-off, or halt.
TASK COMPLETION
• R1:
lab@R1> configure
[edit]
lab@R1# edit system login
[edit system login]

lab@R1# set class design-class permissions all
[edit system login]

lab@R1# set class design-class deny-commands "reboot|restart|power-off|halt"
[edit system login]

lab@R1# set user design class design-class
[edit system login]

lab@R1# commit
commit complete

• R2:
[edit system]
lab@R2# edit login
[edit system login]

[edit system login]

[edit system login]

[edit system login]

lab@R2# commit
commit complete
• R3:
[edit system]
lab@R3# edit login
[edit system login]

[edit system login]

[edit system login]

[edit system login]

lab@R3# commit
commit complete
• R4:
[edit system]
lab@R4# edit login
[edit system login]

[edit system login]

[edit system login]

[edit system login]

lab@R4# commit

commit complete
• R5:
lab@R5> configure
[edit system]
lab@R5# edit login
[edit system login]

[edit system login]

[edit system login]

[edit system login]

lab@R5# commit
commit complete
TASK VERIFICATION
Currently, the RADIUS server is not usable, which means the design user template cannot be
tested in this manner. However, you can move the user jack to the design class, commit the
configuration, log out, and log in as jack to test the user template.
Note
Remember to return jack to the
super-user class when you finish
testing the user template. Forgetting to do
so might result in a point deduction in the
exam.
[edit system login]

lab@R1# set user jack class design-class
[edit system login]

lab@R1# commit and-quit
commit complete
lab@R1> exit
R1 (ttyd0)
login: jack
Password:

jack@R1> show cli authorization | match Deny
Deny regular expression: reboot|restart|power-off|halt
jack@R1> request system ?

Possible completions:
certificate Manage X509 certificates
configuration Request operation on system configuration
firmware
license Manage feature licenses
logout Forcibly end user's CLI login session
partition Partition storage media
scripts Manage scripts (commit, op, event)
services Request service applications information
set-encryption-key Set EEPROM stored encryption key
snapshot Archive data and executable areas
software Perform system software extension or upgrade
storage Request operation on system storage
zeroize Erase all data, including configuration and log files
jack@R1> configure
[edit]
jack@R1# edit system login
[edit system login]

jack@R1# set user jack class super-user
[edit system login]

jack@R1# commit and-quit
commit complete
jack@R1> exit
R1 (ttyd0)
login: lab
Password:

lab@R1>
TASK 10
Create a user group named support on all internal routers. These
users will authenticate with the RADIUS server. Any users of this
group can only view the configuration and issue read-only commands.

Question: Can users of the support group log in to the router
if the RADIUS server is not reachable from the router? Why?
Answer: No local users are configured for the support group.

If the router cannot communicate the RADIUS server users from
this group will not be able to log in to the router.
TASK INTERPRETATION
This task is similar to the previous task in which you must create a user template. However, even
though it is possible to accomplish this task by issuing a list of deny-commands, as you did in
the previous task, it is not recommended. Doing so would be time consuming and it is possible
that a necessary command would not make it on the list.
A superior method to accomplish this task is to give the support user template the necessary
permissions.
TASK COMPLETION
• R1:
lab@R1> configure
[edit]
[edit system login]

lab@R1# set class support-class permissions [ view view-configuration ]
[edit system login]

lab@R1# set user support class support-class
[edit system login]

lab@R1# commit
commit complete
• R2:
[edit system login]
[edit system login]

[edit system login]

lab@R2# commit
commit complete

• R3:
[edit system login]
[edit system login]

[edit system login]

lab@R3# commit
commit complete
• R4:
[edit system login]
[edit system login]

[edit system login]

lab@R4# commit
commit complete
• R5:
[edit system login]
[edit system login]

[edit system login]

lab@R5# commit
commit complete
TASK VERIFICATION
Currently, the RADIUS server is not usable, which means the support user template cannot be
tested in this manner. However, you can move the user jack to the support class, commit the
configuration, log out, and log in as jack to test the user template.
Note
Remember to return jack to the
super-user class when you finish testing
the user template. Forgetting to do so might
result in a point deduction in the exam.
[edit system login]

lab@R1# set user jack class support-class

[edit system login]
lab@R1# commit and-quit
commit complete
lab@R1> exit
R1 (ttyd0)
login: jack
Password:

jack@R1> show cli authorization
Current user: 'jack ' class 'support-class'
Permissions:
view -- Can view current values and statistics
view-configuration-- Can view all configuration (not including secrets)
Individual command authorization:
Allow regular expression: none
Deny regular expression: none
Allow configuration regular expression: none
jack@R1> show configuration

## Last commit: 2015-01-22 08:55:29 PST by lab
version "12.3I20130406_1317_anjali [anjali]";
groups {
ae {
interfaces {
<ae*> {
unit 0 {
family iso;
family mpls;
}
}
}
}
}
apply-groups ae;
system {
host-name R1;
root-authentication {
encrypted-password /* SECRET-DATA */; ## SECRET-DATA
}
radius-server {
172.27.155.1 secret /* SECRET-DATA */; ## SECRET-DATA
...
jack@R1> show system statistics

Tcp:
578860 packets sent
253354 data packets (4704154 bytes)

5 data packets retransmitted (133 bytes)
0 resends initiated by MTU discovery
211266 ack only packets (211128 packets delayed)
0 URG only packets
0 window probe packets
0 window update packets
228369 control packets
685915 packets received
253434 acks(for 4704157 bytes)
24 duplicate acks
0 acks for unsent data
253792 packets received in-sequence(4705767 bytes)
1 completely duplicate packets(18 bytes)
0 old duplicate packets
0 packets with some duplicate data(0 bytes duped)
18 out-of-order packets(15952 bytes)
0 packets of data after window(0 bytes)
0 window probes
1 window update packets
0 packets received after close
...
jack@R1> configure
^
unknown command.
jack@R1> exit
R1 (ttyd0)
login: lab
Password:

lab@R1> configure
[edit]
[edit system login]

lab@R1# set user jack class super-user
[edit system login]

lab@R1# commit
commit complete
TASK 11
Allow jack and jill to authenticate locally on the routers only if
the RADIUS server is unreachable.

Question: Where in the configuration hierarchy do you enable
the router to authenticate users with the RADIUS server?
Answer: The router authenticates with the RADIUS server if it is

configured to do so under the [edit system] hierarchy.
TASK INTERPRETATION
By default, the router allows only local users to log in. To change this behavior, you must
configure the router to authenticate with the RADIUS server under the [edit system]
hierarchy.
Once under the [edit system] hierarchy level use the authentication-order
command to configure the router to authenticate users with the RADIUS server. Using only the
radius option will enable the router to authenticate all users with the RADIUS server. If the
router cannot communicate with the RADIUS server, it then allows local authentication to be
used. However, if the password and radius options are used, local users can log in to the
router even if the RADIUS server is reachable.
TASK COMPLETION
• R1:
[edit system login]
lab@R1# up
[edit system]
lab@R1# set authentication-order ?
[ Open a set of values
password Traditional password authentication
radius Remote Authentication Dial-In User Service
tacplus TACACS+ authentication services
[edit system]
lab@R1# set authentication-order radius
[edit system]
lab@R1# commit
commit complete
• R2:
[edit system login]
lab@R2# up
[edit system]
[edit system]
lab@R2# commit

commit complete
• R3:
[edit system login]
lab@R3# up
[edit system]
[edit system]
lab@R3# commit
commit complete
• R4:
[edit system login]
lab@R4# up
[edit system]
[edit system]
lab@R4# commit
commit complete
• R5:
[edit system login]
lab@R5# up
[edit system]
[edit system]
lab@R5# commit
commit complete
TASK VERIFICATION
You have the opportunity to verify this task because the RADIUS server is currently unreachable.
Simply log out of the router and attempt to log in as user jack. You will receive a delay while the
router attempts to contact the RADIUS server. The Local password prompt is displayed
because the RADIUS server is unreachable. Enter the password you gave to the user jack at the
Local password prompt to log in to the router again.
[edit system]
lab@R1> exit

R1 (ttyd0)
login: jack
Password:
Local password:

jack@R1> exit
R1 (ttyd0)
login: lab
Password:
Local password:

lab@R1>
TASK 12
Ensure that all internal routers disallow root access through the
console port.
Question: Which users can currently access the router through

the console port?
Answer: All users that can authenticate with the router has
access through the console port.
TASK INTERPRETATION
By default, the root user is allowed access to the router through the console port. To disable
this functionality, you must mark the console port as insecure.
TASK COMPLETION
Note
When issuing the set console ?
command, you might notice the description
for the insecure option displays that it
disallows superuser access. Issuing this
command only denies root access to the
console port and not other users who have
super-user permissions.
• R1:
lab@R1> configure

[edit]
lab@R1# edit system ports
[edit system ports]

lab@R1# set console ?
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
disable Disable console
insecure Disallow superuser access
log-out-on-disconnect Log out the console session when cable is unplugged
type Terminal type
[edit system ports]
lab@R1# set console insecure
[edit system ports]

lab@R1# commit
commit complete
• R2:
[edit system]
lab@R2# edit ports
[edit system ports]

[edit system ports]

lab@R2# commit
commit complete
• R3:
[edit system]
lab@R3# edit ports
[edit system ports]

[edit system ports]

lab@R3# commit
commit complete
• R4:
[edit system]
[edit system ports]

[edit system ports]

lab@R4# commit
commit complete
• R5:
[edit system]
[edit system ports]

[edit system ports]

lab@R5# commit
commit complete
TASK VERIFICATION
Attempt to log in to the router with user root and access is denied. You do not know the current
password for user root. You must change root password to verify this step. This confirms that
you have accomplished the task by denying root access through the console port.
Note
Receiving the Local password prompt
is expected because of the authentication
order we specified in a previous step.
[edit system ports]

lab@R1# up 1 set root-authentication plain-text-password
New password:
[edit system ports]

lab@R1# commit
commit complete
[edit system ports]

lab@R1> exit
R1 (ttyd0)
login: root
Password:
Local password:
Login incorrect
login: lab
Password:
Local password:

lab@R1>
TASK 13
Ensure that the control plane of router R5 is protected from
malicious attacks. Configure a firewall filter with the following
criteria:
– Permit essential protocols already running on the
router. For example, all IS-IS, OSPF, and LDP
adjacencies must be maintained.
– Ensure BGP messages are only accepted from configured
neighbors. Any additional BGP neighbors that are added
later must not require a configuration change to this
firewall filter.
– Allow any SSH connections from the 172.27.0.0/16 range.
Log and silently discard any SSH connections attempted
from outside this range.
– Allow RADIUS authentication messages.
– All other traffic must be silently discarded.
Question: To protect the router’s control plane, to which

interface is a firewall filter typically applied?
Answer: A firewall filter is typically applied to the loopback

interface to protect the control plane.
TASK INTERPRETATION
This task might seem complicated at first, but if you break it down to its individual parts it is less
overwhelming.
The first bullet stipulates that all essential protocols running on the routers must be permitted.
When examining R5 you can determine that it is running the following protocols: RSVP, LDP,
MPLS, BGP, IS-IS, OSPF, and VRRP. However, it is not necessary to provision a term that
accommodates IS-IS messages. These messages are not exchanged through IPv4 and will never
match any term in an IPv4 firewall filter.
The second bullet stipulates that BGP messages can be accepted only from configured peers.
Simply specifying each BGP neighbor that R5 has configured does not accomplish this task. Any
BGP neighbors that are added later necessitates configuration changes to this term. The correct
method is to use a prefix-list which contains an apply-path for the locally configured
BGP neighbors. This method scales well because no changes to the firewall filter are necessary if
BGP neighbors are added at a later date.

The third bullet stipulates that you must allow SSH traffic from internal subnets to reach R5.
Then, you must log and discard any SSH traffic that originates from outside your internal IPv4
subnets. The 172.27.0.0/16 range can be applied as a source-address in the term or as a
prefix-range configured under policy-options. It is advantageous to use a
prefix-range to decrease the overall size of a large firewall filter, which can help if your
router is experiencing memory issues. However, for this task it is not necessary. Also, configure
the term to permit TCP traffic from port 22, or port ssh. Then, configure another term to
discard and log all other SSH traffic.
The fourth bullet stipulates that you must allow RADIUS authentication messages. Configure a
term that accepts UDP traffic from port 1812. Alternatively, you can specify port radius
instead of port 1812.
The final bullet stipulates that all other traffic must be silently discarded. By default, all firewall
filters in the Junos OS have an implicit deny statement at the end of each filter. This means no
configuration is necessary to accomplish the task. However, it is recommended to configure a
term that discards all remaining traffic. It might be necessary to examine the traffic being
discarded. Adding the log statement to this term helps simplify the troubleshooting process.
Although there is no specific mention on which interface to apply the recently configured firewall
filter, the task does state that this filter is designed to protect the control plane. Technically, you
can apply this filter to every transit interface that is configured, but that solution does not scale
well. The loopback interface is the correct interface on which to apply this filter, which causes
any traffic that is traveling to the control plane to first be processed through the firewall filter.
TASK COMPLETION
• R5:
[edit system ports]
lab@R5# top edit firewall family inet filter protect-re
[edit firewall family inet filter protect-re]

lab@R5# set term RSVP-allow from protocol rsvp

lab@R5# set term RSVP-allow then accept

lab@R5# set term LDP-allow from protocol tcp

lab@R5# set term LDP-allow from protocol udp

lab@R5# set term LDP-allow from port ldp

lab@R5# set term LDP-allow then accept

lab@R5# top edit policy-options prefix-list configured-bgp-neighbors
[edit policy-options prefix-list configured-bgp-neighbors]

lab@R5# set apply-path "protocols bgp group <*> neighbor <*>"

[edit policy-options prefix-list configured-bgp-neighbors]
lab@R5# top edit firewall family inet filter protect-re

lab@R5# set term BGP-allow from source-prefix-list configured-bgp-neighbors

lab@R5# set term BGP-allow from protocol tcp

lab@R5# set term BGP-allow from port bgp

lab@R5# set term BGP-allow then accept

lab@R5# set term OSPF-allow from protocol ospf

lab@R5# set term OSPF-allow then accept

lab@R5# set term VRRP-allow from protocol vrrp

lab@R5# set term VRRP-allow then accept

lab@R5# set term SSH-allow from source-address 172.27.0.0/16

lab@R5# set term SSH-allow from protocol tcp

lab@R5# set term SSH-allow from port ssh

lab@R5# set term SSH-allow then log

lab@R5# set term SSH-allow then accept

lab@R5# set term SSH-block from protocol tcp

lab@R5# set term SSH-block from port ssh

lab@R5# set term SSH-block then log

lab@R5# set term SSH-block then discard

lab@R5# set term RADIUS-allow from protocol udp

lab@R5# set term RADIUS-allow from port radius

lab@R5# set term RADIUS-allow then accept

lab@R5# set term discard-all then discard

lab@R5# top set interfaces lo0.0 family inet filter input protect-re

lab@R5# up 2
[edit firewall]
lab@R5# show | no-more
family inet {
filter protect-re {
term RSVP-allow {
from {
protocol rsvp;
}
then accept;
}
term LDP-allow {
from {
protocol [ tcp udp ];
port ldp;
}
then accept;
}
term BGP-allow {
from {
source-prefix-list {
configured-bgp-neighbors;
}
protocol tcp;
port bgp;
}
then accept;
}
term OSPF-allow {
from {
protocol ospf;
}
then accept;
}
term VRRP-allow {
from {
protocol vrrp;
}
then accept;

}
term SSH-allow {
from {
source-address {
172.27.0.0/16;
}
protocol tcp;
port ssh;
}
then {
log;
accept;
}
}
term SSH-block {
from {
source-address {
0.0.0.0/0;
}
protocol tcp;
port ssh;
}
then {
log;
discard;
}
}
term RADIUS-allow {
from {
protocol udp;
port radius;
}
then accept;
}
term discard-all {
then {
discard;
}
}
}
}
[edit firewall]
lab@R5# top show policy-options prefix-list configured-bgp-neighbors
apply-path "protocols bgp group <*> neighbor <*>";
[edit firewall]
lab@R5# commit
commit complete
TASK VERIFICATION
There is no simple way to verify if a firewall filter is working. You must test each term individually
and some terms are not verifiable at this time.

You can easily verify the essential protocols running on the router by issuing operational
commands. Issue the show rsvp neighbor, show ldp neighbor, show ospf
neighbor, show isis adjacency, and show vrrp commands to verify these protocols
are maintaining their states.
You can test the two terms for SSH by originating SSH connections from different IP addresses.
For example, you can initiate an SSH connection from R1 and by default the source address of
the connection will be assigned from an internal interface. Then you can initiate another SSH
connection from R1 and add the source option with a non 172.27.0.0/16 IP address that is
assigned to the router. The first SSH connection succeeds and the second times out.
Unfortunately, you cannot test the term configured for RADIUS at this time. This service is not
currently operational in the test bed.
• R5:
[edit firewall]
lab@R5# run show rsvp neighbor
RSVP neighbor: 2 learned
Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd
172.27.0.26 0 1/0 3:00 9 22/22 14
172.27.0.21 0 1/0 1:00 9 9/9 7
[edit firewall]
lab@R5# run show ldp neighbor
Address Interface Label space ID Hold time
172.27.0.26 ge-0/0/1.0 172.27.255.3:0 13
172.27.0.21 ae2.0 172.27.255.4:0 10
[edit firewall]
lab@R5# run show ospf neighbor
Address Interface State ID Pri Dead
172.27.0.58 ge-0/0/5.0 Full 10.255.3.1 128 39
[edit firewall]
lab@R5# run show isis adjacency
Interface System L State Hold (secs) SNPA
ae2.0 R4 2 Up 20 52:54:0:0:c6:4
ge-0/0/1.0 R3 2 Up 6 56:68:29:7a:9e:2e
[edit firewall]
lab@R5# run show vrrp
Interface State Group VR state VR Mode Timer Type Address
ge-0/0/9.0 up 1 master Active A 0.758 lcl 172.20.20.5
vip 172.20.20.100
• R2:
[edit]
lab@R2# run ssh 172.27.255.5
The authenticity of host '172.27.255.5 (172.27.255.5)' can't be established.
RSA key fingerprint is 0c:d7:22:f8:ae:60:7b:60:12:40:df:e2:b4:2f:d1:c7.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.27.255.5' (RSA) to the list of known hosts.
lab@172.27.255.5's password:

lab@R5> exit
Connection to 172.27.255.5 closed.
[edit]
lab@R2# run ssh 172.27.255.5 source 172.20.21.2
ssh: connect to host 172.27.255.5 port 22: Operation timed out
TASK 14
Log and silently discard all instances of IPv4 or IPv6 traffic that
are coming from transit peers and have the source address of
172.27.0.0/16 or 2008:4498::/32. This information must be
recoverable after a reboot.
Question: Is unicast RPF checking a possible solution to this

task?
Answer: Yes. Although, a fail filter would need to be configured

that would look just like the firewall filter that you must create
for this task. This approach results in more work for the same
results.
TASK INTERPRETATION
This task is simple in regards to creating an IPv4 firewall filter and an IPv6 firewall filter that
blocks traffic from the specified source addresses. However, the criterion of making this
information recoverable after a reboot might cause some confusion. Two methods are available
for collecting information on traffic that matches a firewall filter term; logging and syslogging.
The key difference is the log command stores the information in a volatile memory location,
which will not survive a reboot. The syslog command stores the information in a non-volatile
memory location, such as the hard drive or compact flash. You must use the syslog command
to correctly complete this task.
You must also configure a syslog file in which to store the logs. The firewall facility must be
specified to collect the necessary information.
TASK COMPLETION
• R5:
lab@R5# up
[edit firewall family inet]

lab@R5# edit filter block-ipv4-int
[edit firewall family inet filter block-ipv4-int]

lab@R5# set term int-src from source-address 172.27.0.0/16

lab@R5# set term int-src then discard

lab@R5# set term int-src then syslog

lab@R5# set term allow-rest then accept

lab@R5# up 2
[edit firewall]
lab@R5# edit family inet6 filter block-ipv6-int
[edit firewall family inet6 filter block-ipv6-int]

lab@R5# set term int-src from source-address 2008:4498::/32




lab@R5# up 2
[edit firewall]
lab@R5# show
family inet {
...
filter block-ipv4-int {
term int-src {
from {
source-address {
172.27.0.0/16;
}
}
then {
syslog;
discard;
}
}
term allow-rest {
then accept;
}
}
}
family inet6 {
term int-src {
from {

source-address {
2008:4498::/32;
}
}
then {
syslog;
discard;
}
}
term allow-rest {
then accept;
}
}
}
...
[edit firewall]
lab@R5# top edit system syslog file int-src-violations
[edit system syslog file int-src-violations]

lab@R5# set firewall any
[edit system syslog file int-src-violations]


lab@R5# set unit 0 family inet filter input block-ipv4-int

lab@R5# set unit 0 family inet6 filter input block-ipv6-int

lab@R5# show
description "Connection to transit router";
unit 0 {
family inet {
filter {
input block-ipv4-int;
}
address 172.27.0.57/30;
}
family inet6 {
filter {
}
address 2008:4498::39/126;
}
}

lab@R5# commit
commit complete

• R2:
[edit system]
lab@R2# top edit firewall family inet filter block-ipv4-int

lab@R2# set term int-src from source-address 172.27.0.0/16




lab@R2# up 2
[edit firewall]
lab@R2# edit family inet6 filter block-ipv6-int

lab@R2# set term int-src from source-address 2008:4498::/32




lab@R2# up 2 show
family inet {
term int-src {
from {
source-address {
172.27.0.0/16;
}
}
then {
syslog;
discard;
}
}
term allow-rest {
then accept;
}
}
}

family inet6 {
term int-src {
from {
source-address {
2008:4498::/32;
}
}
then {
syslog;
discard;
}
}
term allow-rest {
then accept;
}
}
}

lab@R2# top edit system syslog
[edit system syslog]

lab@R2# set file int-src-violations firewall any


lab@R2# set unit 0 family inet filter input block-ipv4-int

lab@R2# set unit 0 family inet6 filter input block-ipv6-int

lab@R2# show
description "Connection to transit router";
unit 0 {
family inet {
filter {
}
address 172.27.0.37/30;
}
family inet6 {
filter {
}
address 2008:4498::25/126;
}
}

lab@R2# commit
commit complete
TASK VERIFICATION
You can verify this task by logging in to the VR-device and pinging the directly connected
interfaces of routers R2 and R5 from T1 and T2, respectively. Then, you can view the recently
created syslog for the recording of the violation.
• VR-device:
root@vr-device> ping 172.27.0.37 routing-instance transit1 count 2
PING 172.27.0.37 (172.27.0.37): 56 data bytes

root@vr-device> ping 2008:4498::25 routing-instance transit1 count 2

PING6(56=40+8+8 bytes) 2008:4498::26 --> 2008:4498::25
--- 2008:4498::25 ping6 statistics ---

root@vr-device> ping 172.27.0.57 routing-instance transit2 count 2

PING 172.27.0.57 (172.27.0.57): 56 data bytes

root@vr-device> ping 2008:4498::39 routing-instance transit2 count 2

PING6(56=40+8+8 bytes) 2008:4498::3a --> 2008:4498::39
--- 2008:4498::39 ping6 statistics ---

• R2:
lab@R2# run show log int-src-violations
Jan 22 10:17:15 R2 clear-log[46110]: logfile cleared
Jan 22 10:21:09 R2 fwdd[1203]: ÂÊPFE_FW_SYSLOG_IP: FW:
Âinterface-nameÂ^Lge-0/0/2.0 ÂactionÂÂD Âprotocol-nameÂ^Dicmp
Âsource-addressÂ^K38.0.27.172 Âdestination-addressÂ^K37.0.27.172
Âsource-port-or-typeÂÊ 8 Âdestination-port-or-codeÂÊ 0
(ÂcountÂÂ1 packets)
Jan 22 10:21:10 R2 fwdd[1203]: ÂÊPFE_FW_SYSLOG_IP: FW:
Âinterface-nameÂ^Lge-0/0/2.0 ÂactionÂÂD Âprotocol-nameÂ^Dicmp
Âsource-addressÂ^K38.0.27.172 Âdestination-addressÂ^K37.0.27.172
Âsource-port-or-typeÂÊ 8 Âdestination-port-or-codeÂÊ 0
(ÂcountÂÂ1 packets)
Jan 22 10:21:33 R2 fwdd[1203]: PFE_FW_SYSLOG_IP6_ICMP: FW: ge-0/0/2.0 D icmpv6
SA 820:9844:0:0:0:0:0:2600 DA 2ff:0:0:0:0:100:ff:2500 type 135 code 0 (1
packets)
Jan 22 10:21:35 R2 last message repeated 2 times

• R5:
lab@R5# run show log int-src-violations
Jan 22 10:19:11 R5 clear-log[45951]: logfile cleared
Jan 22 10:19:32 R5 fwdd[1217]: ÂÊPFE_FW_SYSLOG_IP: FW: Âinterface-nameÂ^Lge-0/
0/5.0 ÂactionÂÂD Âprotocol-nameÂ^Dicmp Âsource-addressÂ^K58.0.27.172
Âdestination-addressÂ^K57.0.27.172 Âsource-port-or-typeÂÊ 8
Âdestination-port-or-codeÂÊ 0 (ÂcountÂÂ1 packets)
Jan 22 10:19:33 R5 fwdd[1217]: ÂÊPFE_FW_SYSLOG_IP: FW: Âinterface-nameÂ^Lge-0/
0/5.0 ÂactionÂÂD Âprotocol-nameÂ^Dicmp Âsource-addressÂ^K58.0.27.172
Âdestination-addressÂ^K57.0.27.172 Âsource-port-or-typeÂÊ 8
Âdestination-port-or-codeÂÊ 0 (ÂcountÂÂ1 packets)
Jan 22 10:19:51 R5 fwdd[1217]: PFE_FW_SYSLOG_IP6_ICMP: FW: ge-0/0/5.0 D icmpv6
SA 820:9844:0:0:0:0:0:3a00 DA 2ff:0:0:0:0:100:ff:3900 type 135 code 0 (1
packets)
TASK 15
On router R4, configure the syslog file Monitor-Agg-Eth to only log
information associated with its local aggregated Ethernet
interfaces. To conserve space on the routers, there can be only 20
files of this information stored locally. Each file can be no more
than 1 MB in size.
TASK INTERPRETATION
To complete this task, you must configure the syslog file Monitor-agg-Eth on router R4 to
the facility level of any and the severity level of any. There must not be anymore then 20 files
stored locally and each of those files cannot be larger then 1 MB. Then, you must configure the
syslog to only collect information in regards to R4’s local aggregated Ethernet interfaces. To
accomplish this part of the task, you must use the match option. Through the use of regular
expressions you can configure the syslog file to collect only the necessary information.
TASK COMPLETION
[edit system ports]
lab@R4# up 1 edit syslog file Monitor-Agg-Eth
[edit system syslog file Monitor-Agg-Eth]

lab@R4# set any any

lab@R4# set match "ae0|ae1|ae2"

lab@R4# set archive size 1m

lab@R4# set archive files 20

lab@R4# show
any any;

match "ae0|ae1|ae2";
archive size 1m files 20;

lab@R4# commit
commit complete
TASK VERIFICATION
To verify this task, set the disable option on R4’s local aggregated Ethernet interfaces,
commit the configuration, delete the disable option, and commit the configuration again.
Then, examine the Monitor-Agg-Eth syslog file for evidence of recent activity on the
aggregated Ethernet interfaces.
lab@R4# top set interfaces ae0 disable



lab@R4# commit
commit complete

lab@R4# top delete interfaces ae0 disable



lab@R4# commit
commit complete

lab@R4# run show log Monitor-Agg-Eth
Jan 22 10:39:19 R4 mgd[38238]: UI_CFG_AUDIT_SET: User 'lab' set: [interfaces ae0]
<unconfigured> -> "disable"
Jan 22 10:39:19 R4 mgd[38238]: UI_CMDLINE_READ_LINE: User 'lab', command 'top set
interfaces ae0 disable '

Jan 22 10:39:19 R4 dcd[46546]: ae0 : Warning: aggregated-ether-options link-speed
no kernel value! default to 0
Jan 22 10:39:20 R4 dcd[1299]: ae0 : aggregated-ether-options link-speed set to
kernel value of 1000000000
...
TASK 16
Configure all internal routers to send any commands executed by
users through the CLI to the server located at 172.27.155.1.
Question: Which syslog facility records CLI commands executed

by users?
Answer: The interactive-commands facility allows the

syslog to record CLI commands executed by users.
TASK INTERPRETATION
To complete this task, you must configure the syslog utility to use the
interactive-commands facility when sending information to the syslog server located at
172.27.155.1. Instead of specifying a file name for the syslog, use the host statement instead,
which allows you to specify the server’s IP address.
TASK COMPLETION
• R1:
[edit system ports]
lab@R1# up 1 edit syslog host 172.27.155.1
[edit system syslog host 172.27.155.1]

lab@R1# set interactive-commands any

lab@R1# commit
commit complete

• R2:
lab@R2# top edit syslog host 172.27.155.1


lab@R2# commit
commit complete
• R3:
[edit system ports]
lab@R3# up 1 edit syslog host 172.27.155.1


lab@R3# commit
commit complete
• R4:
lab@R4# up

lab@R4# edit host 128.1.2.1


lab@R4# commit
commit complete
• R5:
lab@R5# top edit system syslog host 172.27.155.1


lab@R5# commit
commit complete

TASK VERIFICATION
Note
You must log in to the internal server using
the root username and the password
Clouds to verify this task.
To verify this task, issue a few commands on any of the routers and then log in to the internal
server. Once you log in to the internal server, issue the cat/var/log/messages command.
This command displays the syslog messages that arrived from you entering commands on the
router.
• R1:
lab@R1# top
[edit]
lab@R1# edit system syslog host 172.27.155.1

lab@R1#
• Internal server:
CentOS release 5.3 (Final)
Kernel 2.6.18-128.el5 on an i686
centos login: root

Password:
Last login: Mon Jun 20 16:01:15 on ttyS0
[root@centos ~]# cat /var/log/messages
...
Jan 22 10:41:53 172.27.155.6 R5 mgd[38211]: UI_COMMIT_PROGRESS: Commit operation in
progress: signaling 'Alarm control process', pid 1206, signal 30, status 0 with
notification errors enabled
Jan 22 10:43:39 172.27.155.2 R1 mgd[5446]: UI_CMDLINE_READ_LINE: User 'lab',
command 'top '
Jan 22 10:43:41 172.27.155.2 R1 mgd[5446]: UI_CMDLINE_READ_LINE: User 'lab',
command 'edit system syslog host 172.27.155.1 '
TASK 17
Ensure that the configuration of all internal routers is backed up
every 15 minutes to the internal server located at 172.27.155.1. Use
SCP to encrypt these transmissions and store the configurations in
the /var/tmp/ directory on the server. Use the root username with
the password Clouds to authenticate with the internal server. Use
the same credentials to log into the internal server to examine
these files.

Question: Which other protocols can be used to archive
configurations?
Answer: FTP and HTTP can be used to archive configurations.
TASK INTERPRETATION
To complete this task, configuration archiving must be configured. Configure the router to send
its configuration using SCP every 15 minutes. Be aware that the transmit interval is configured
in minutes. Configure the transmit-interval statement with a value of 15 to complete this
part.
The syntax for SCP to transfer the configuration is as follows “scp://
username:password@172.27.155.1:/var/tmp/”. Be sure to encase the command in
quotes. Failing to do so results in a syntax error.
TASK COMPLETION
• R1:
lab@R1# up 2
[edit system]
lab@R1# edit archival
[edit system archival]

lab@R1# set configuration transfer-interval 15

lab@R1# set configuration archive-sites "scp://root:Clouds@172.27.155.1:/var/tmp/"
RSA key fingerprint is a7:32:43:b4:b1:9c:78:6f:5d:0e:7d:e7:ce:cb:5b:a0.

lab@R1# commit
commit complete
• R2:
lab@R2# up 2
[edit system]



lab@R2# commit
commit complete
• R3:
lab@R3# up 2
[edit system]



lab@R3# commit
commit complete
• R4:
lab@R4# up 2
[edit system]



lab@R4# commit

commit complete
• R5:
lab@R5# up 2
[edit system]



lab@R5# commit
commit complete
TASK VERIFICATION.
Note
You must log in to the internal server using
the root username and the password
Clouds to verify this task.
To verify this task, you must access the internal server and examine the /var/tmp/ directory.
However, the minimum transfer interval is 15 minutes. You might need to come back to this task
after working through the lab further to examine the files.
[root@centos /]# ls /var/tmp/
R1_juniper.conf.gz_20110629_212753
vr-device_juniper.conf.gz_20110629_105758
TASK 18
The backbone-mtu.slax commit script is available to assist you in
checking core interface MTU values. The commit script is located on
the internal server at 172.27.155.1 in the /etc/ directory. Because
the commit script might change in the future, configure all
internal routers to refresh and retrieve the commit script through
SCP. Use the root username with the password Clouds to authenticate
with the internal server.

Question: Which other protocols can be used to retrieve commit
scripts?
Answer: FTP and HTTP can be used to retrieve commit scripts.
TASK INTERPRETATION
To complete this task, you must first configure the router to communicate with the internal server
using SCP. Remember to specify the username and the directory in which the file is located. Even
though you specify the commit script name after the file statement, you must also specify the
commit script name in the source.
Once you configure the router to retrieve the commit script, and before you issue the commit
command, be sure to issue the refresh command. This is a configuration mode command
that acts like a operational mode command. After you issue the refresh command, enter the
necessary password and the router retrieves the commit script.
TASK COMPLETION
• R1:
lab@R1# up 1 edit scripts commit
[edit system scripts commit]

lab@R1# set file backbone-mtu.slax source "scp://root@172.27.155.1/etc/
backbone-mtu.slax"

lab@R1# set refresh
refreshing 'backbone-mtu.slax' from 'scp://root@172.27.155.1/etc/
backbone-mtu.slax'
root@172.27.155.1's password:
backbone-mtu.slax 100% 1569 1.5KB/s 00:00

lab@R1# commit
warning: MTU on backbone interface ge-0/0/3.0 is not set to 4484 (1514) Please
change the interface's physical MTU to 4484
commit complete
• R2:

backbone-mtu.slax"

lab@R2# set refresh
backbone-mtu.slax'

lab@R2# commit
commit complete
• R3:

backbone-mtu.slax"

lab@R3# set refresh
backbone-mtu.slax'

lab@R3# commit
commit complete
• R4:

backbone-mtu.slax"

lab@R4# set refresh
backbone-mtu.slax'


lab@R4# commit
commit complete
• R5:

backbone-mtu.slax"

lab@R5# set refresh
backbone-mtu.slax'

lab@R5# commit
commit complete
TASK VERIFICATION
You can verify this task by examining the warning message you receive when you issue a commit.
If you do not receive a warning message or if the commit fails, the task is not complete.
lab@R1# commit
commit complete
TASK 19
Change any interface physical MTU value to the MTU value the commit
script recommends.

Question: Which value does the commit script recommend you
change the MTU to?
Answer: The script recommends that you change the interface

MTU value to 4484.
TASK INTERPRETATION
The commit script you applied in the last task detects physical MTU values on core interfaces
that are incorrect. Do as the commit script advises and change the physical MTU values to what
it recommends.
TASK COMPLETION
• R1:
lab@R1# top edit interfaces
[edit interfaces]
lab@R1# set ge-0/0/3 mtu 4484
[edit interfaces]
[edit interfaces]
lab@R1# commit
commit complete
• R2:
[edit interfaces]
[edit interfaces]
lab@R2# commit
commit complete
• R3:
[edit interfaces]

[edit interfaces]
[edit interfaces]
[edit interfaces]
lab@R3# commit
commit complete
• R4:
[edit interfaces]
[edit interfaces]
lab@R4# commit
commit complete
• R5:
[edit interfaces]
[edit interfaces]
lab@R5# commit
commit complete
TASK VERIFICATION
If the commit script does not issue a warning about an incorrect interface MTU value then this
task is complete.
STOP Tell your instructor that you have completed this lab.



Lab
IS-IS Implementation
Overview
In this lab, you will be given a list of tasks specific to IS-IS implementation to accomplish in a
timed setting. You will have 1 hour and 15 minutes to complete the simulation.
• Routers R1, R2, R3, R4, and R5 must be configured to participate in your IS-IS
domain. Each router’s system ID must be based on its loopback address. Configure
each router to support only one IS-IS adjacency per router pairing. Loss of R3 or R4
must not isolate any internal router. Configure the IS-IS areas and levels as shown in
the “IS-IS Implementation” lab diagram.
• The loopback addresses of R1 and R2 must not appear in the routing table of R5.
However, loopback address to loopback address reachability from all internal routers
is required.
• The routes associated with the link between R2 and T1, and the routes associated
with the link between R5 and T2 must appear as internal IS-IS routes within your
network. However, the IPv6 routes from these links must not appear in R1’s routing
table but must appear in R2’s routing table. The [edit routing-options]
hierarchy level on R1 cannot be altered to accomplish this task.
• Configure R1 to receive RIP routes from C1. Then configure R1 to send a summary
route to C1 only when R2’s loopback address is present in R1’s routing table. This
summary route should represent your internal IPv4 address space. The routes
received from C1 must be present in area 49.0001 as IS-IS external routes. These
individual routes must not appear in the routing table of R5. However, you must
ensure that R5 can reach these destinations.
• Configure R3 and R5 to receive OSPF routes from DC3. Create the most specific
summary route possible that represents these routes and redistribute the summary
route into IS-IS. This summary route must appear on R4 with a metric that is greater
than 300. However, it must appear on R1 and R2 with a metric that is less than 74.
• The 10.100.100.0/24 prefix is being used to reach destinations behind DC1 through
static routing on R2 and R4. Redistribute this prefix into IS-IS. Ensure R2 is the
primary path and R4 is the backup path for this prefix for R1. Ensure R4 is the
primary path and R2 is the backup path for this prefix for R5.
www.juniper.net IS-IS Implementation • Lab 2–1

• Configure all interfaces participating in a Level 2 adjacency to monitor the
adjacencies using sub-second link failure detection. If the local router is the DR for a
Level 1 broadcast segment, the interface involved must have an IS-IS hold-time
value of 2 seconds.
• Configure the routers in both areas to authenticate hello PDUs using the unencrypted
password of Juniper. Configure the routers in Area 49.0001 to authenticate LSPs
using the encrypted password of JuniperRocks. No routing disruption can occur
between R3 and R4 during this process.
• All IS-IS LSPs should be valid for 1 hour.
Lab 2–2 • IS-IS Implementation www.juniper.net

Implementing IS-IS
In this lab part, you will become familiar with implementing IS-IS as the IGP in your network. You
will be given a list of tasks that will require you to configure and monitor IS-IS operations.
Note
We recommend that you spend some time
investigating the current operation of your
routers. During the real exam, you might be
given routers that are operating
inefficiently. Investigating operating issues
now might save you a lot of time
troubleshooting strange issues later.
TASK 1
Routers R1, R2, R3, R4, and R5 must be configured to participate in
your IS-IS domain. Each router’s system ID must be based on its
loopback address. Configure each router to support only one IS-IS
adjacency per router pairing. Loss of R3 or R4 must not isolate any
internal router. Configure the IS-IS areas and levels as shown in
the “IS-IS Implementation” lab diagram.
Question: Which AFI value must you use for the IS-IS areas?
Answer: You must use the private AFI value of 49 for the IS-IS
areas.
TASK INTERPRETATION
This task can be split into two smaller tasks, and then you can proceed with each task. First, you
must base the system ID for each router using its corresponding loopback address. The method
you use to do this can vary, but as long as the system ID in the ISO address resembles the IPv4
address on the loopback interface, the criterion for this part of the task is complete.
Second, you must configure each router to have only one IS-IS adjacency per router pairing.
Each interface can only participate in Level 1 or Level 2, but not both. This excludes the
loopback interface because no router pairing can occur from it participating in Level 1 and Level
2.
Confusion might be caused when attempting to decide which area ID you must assign to R3 and
R4. R1 and R2 must form Level 1 adjacencies with R3 and R4, which requires R3 and R4 to
have the same area ID as R1 and R2. To complete this part of the task, configure the area ID of
49.0001 on R1, R2, R3, and R4; then configure the area ID of 49.0002 on R5.
Also, remember to add the family iso statement to all internal interfaces. Forgetting to do so
results in a a malfunctioning IS-IS network which is difficult to troubleshoot later on.

Note
The last part of this task not only applies to
this task but all remaining tasks for the
IS-IS part of this lab. For example, when
applying a policy that leaks routes from one
level to the other, ensure that the loss of R3
or R4 does not stop the leaking of the
routes into that level.
TASK COMPLETION
• R1:
R1 (ttyd0)
login: lab
Password:

lab@R1> configure
[edit]
[edit interfaces]
lab@R1# set lo0.0 family iso address 49.0001.0172.0027.2551.00
[edit interfaces]
lab@R1# set ge-0/0/3.0 family iso
[edit interfaces]
[edit interfaces]
lab@R1# set ae1.0 family iso
[edit interfaces]
lab@R1# top edit protocols isis
[edit protocols isis]

lab@R1# set level 2 disable

lab@R1# set interface all

lab@R1# commit
commit complete
• R2:

R2 (ttyd0)
login: lab
Password:

lab@R2> configure
[edit]
[edit interfaces]
[edit interfaces]
[edit interfaces]
[edit interfaces]


[edit interfaces]
lab@R2# commit
• R3:
R3 (ttyd0)
login: lab
Password:

lab@R3> configure
[edit]
[edit interfaces]
[edit interfaces]
[edit interfaces]

[edit interfaces]
[edit interfaces]

lab@R3# set interface ge-0/0/1 level 2 disable



lab@R3# set interface lo0 level 1 disable

lab@R3# commit
commit complete
• R4:
R4 (ttyd0)
login: lab
Password:

lab@R4> configure
[edit]
[edit interfaces]
[edit interfaces]
[edit interfaces]
[edit interfaces]
[edit interfaces]
[edit interfaces]



lab@R4# set interface ae0 level 2 disable



lab@R4# set interface lo0 level 1 disable
edit protocols isis]

lab@R4# commit
• R5:
R5 (ttyd0)
login: lab
Password:

lab@R5> configure
[edit]
[edit interfaces]
[edit interfaces]
[edit interfaces]
[edit interfaces]



lab@R5# commit
commit complete

TASK VERIFICATION
You can verify the IS-IS address applied to the loopback interface by issuing the show
interface terse lo0.0 command on each router. Each router should have an IS-IS
address that contains the AFI and area values of 49.0001 or 49.0002, and a system ID that
represents the routers IPv4 loopback address.
You can verify the number of adjacencies per router pairing by issuing the show isis
adjacency command. Each router must only have one Level 1 or one Level 2 adjacency per
router pairing. You can obtain further info on the number of adjacencies per interface by issuing
the show isis interface detail command, but this is unnecessary to verify this task.
• R1:
lab@R1# run show interfaces terse lo0.0
lo0.0 up up inet 172.27.255.1 --> 0/0
iso 49.0001.0172.0027.2551

ae1.0 R4 1 Up 7 52:54:0:0:94:3
ge-0/0/3.0 R2 1 Up 20 56:68:29:7a:a7:56
ge-0/0/6.0 R3 1 Up 18 56:68:29:7a:87:a9
• R2:
lo0.0 up up inet 172.27.255.2 --> 0/0
iso 49.0001.0172.0027.2552

ae0.0 R4 1 Up 6 52:54:0:0:94:2
ge-0/0/1.0 R1 1 Up 8 56:68:29:7a:a8:bf
• R3:
lo0.0 up up inet 172.27.255.3 --> 0/0
iso 49.0001.0172.0027.2553

ge-0/0/1.0 R1 1 Up 8 56:68:29:7a:91:f1
ge-0/0/2.0 R4 2 Up 6 56:68:29:7a:a9:ef
ge-0/0/3.0 R5 2 Up 24 56:68:29:7a:8e:5

• R4:
lab@R4# run show interfaces lo0.0 terse
lo0.0 up up inet 172.27.255.4 --> 0/0
iso 49.0001.0172.0027.2254

ae0.0 R2 1 Up 20 52:54:0:0:32:2
ae1.0 R1 1 Up 19 52:54:0:0:43:3
ae2.0 R5 2 Up 19 52:54:0:0:1a:4
ge-0/0/5.0 R3 2 Up 20 56:68:29:7a:9c:bd
• R5:
lo0.0 up up inet 172.27.255.5 --> 0/0
iso 49.0002.0172.0027.2555

ae2.0 R4 2 Up 8 52:54:0:0:94:4
ge-0/0/1.0 R3 2 Up 7 56:68:29:7a:99:8f
TASK 2
The loopback addresses of R1 and R2 must not appear in the routing
table of R5. However, loopback address to loopback address
reachability from all internal routers is required.
Question: What is the most specific summary route that

represents the loopback addresses of R1 and R2?
Answer: The most specific summary route that represents R1’s

and R2’s loopback addresses is 172.27.255.0/30.
TASK INTERPRETATION
By default, Level 1 routes are advertised to any Level 2 router. You must restrict this default
behavior by employing some form of restrictive route leaking. This restrictive route leaking must
occur on the border routers R3 and R4. An export policy must be configured that stops the
advertisement of R1’s and R2’s loopback addresses into Level 2. Then, on R3 and R4, you must
create and inject an aggregate route into Level 2 that represents those loopback addresses.
Although the task does not specify the route leaking direction, it is recommended to create a
policy that uses the to level option. This option directs which level the policy leaks routes to.
This helps clarify the policy and reduces unnecessary LSP flooding that can occur.

TASK COMPLETION
• R3:
lab@R3# set aggregate route 172.27.255/30
lab@R3# top edit policy-options policy-statement leak-routes
[edit policy-options policy-statement leak-routes]

lab@R3# edit term block-R1-R2-lo0
[edit policy-options policy-statement leak-routes term block-R1-R2-lo0]

lab@R3# set from protocol isis

lab@R3# set from route-filter 172.27.255/30 orlonger

lab@R3# set from level 1

lab@R3# set to level 2

lab@R3# set then reject

lab@R3# up

lab@R3# edit term R1-R2-summary
[edit policy-options policy-statement leak-routes term R1-R2-summary]

lab@R3# set from protocol aggregate

lab@R3# set from route-filter 172.27.255/30 exact


lab@R3# set then accept

lab@R3# up

lab@R3# show
term block-R1-R2-lo0 {
from {

protocol isis;
level 1;
route-filter 172.27.255.0/30 orlonger;
}
to level 2;
then reject;
}
term R1-R2-summary {
from {
protocol aggregate;
route-filter 172.27.255.0/30 exact;
}
to level 2;
then accept;
}


lab@R3# set export leak-routes

lab@R3# commit
commit complete
• R4:
lab@R4# set aggregate route 172.27.255/30
lab@R4# top edit policy-options policy-statement leak-routes

lab@R4# edit term block-R1-R2-lo0


lab@R4# set from route-filter 172.27.255/30 orlonger





lab@R4# up

lab@R4# edit term R1-R2-summary





lab@R4# up

lab@R4# show
from {
protocol isis;
level 1;
}
to level 2;
then reject;
}
from {
protocol aggregate;
}
to level 2;
then accept;
}


lab@R4# set export leak-routes

lab@R4# commit
commit complete

TASK VERIFICATION
To verify this task, examine the routing tables on R3, R4, and R5. The recently configured
aggregate route and the routes for R1’s and R2’s loopback addresses should be present on R3
and R4. An external IS-IS route that represents R1’s and R2’s loopback addresses should be
present on R5. The individual routes for the loopback addresses of R1 and R2 should be absent
from R5. Then, ensure loopback address to loopback address reachability by issuing pings from
R5 to all other internal routers.
• R3:
lab@R3# run show route 172.27.255/30
inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
172.27.255.0/30 *[Aggregate/130] 17:20:35

Reject
172.27.255.1/32 *[IS-IS/15] 20:22:10, metric 10
> to 172.27.0.14 via ge-0/0/1.0
172.27.255.2/32 *[IS-IS/15] 20:22:10, metric 20
> to 172.27.0.14 via ge-0/0/1.0
172.27.255.3/32 *[Direct/0] 4d 18:11:31
> via lo0.0
• R4:

172.27.255.0/30 *[Aggregate/130] 17:29:39

Reject
172.27.255.1/32 *[IS-IS/15] 20:29:11, metric 10
> to 172.27.0.10 via ae1.0
172.27.255.2/32 *[IS-IS/15] 20:29:11, metric 10
> to 172.27.0.5 via ae0.0
172.27.255.3/32 *[IS-IS/18] 20:29:31, metric 10
> to 172.27.0.17 via ge-0/0/5.0
• R5:

172.27.255.0/30 *[IS-IS/165] 17:20:10, metric 20

to 172.27.0.26 via ge-0/0/1.0
> to 172.27.0.21 via ae2.0

172.27.255.3/32 *[IS-IS/18] 20:25:17, metric 10
> to 172.27.0.26 via ge-0/0/1.0

PING 172.27.255.1 (172.27.255.1): 56 data bytes
64 bytes from 172.27.255.1 via ge-0/0/1.0: icmp_seq=0 ttl=63 time=4.081 ms
64 bytes from 172.27.255.1 via ge-0/0/1.0: icmp_seq=1 ttl=63 time=5.126 ms
--- 172.27.255.1 ping statistics ---


PING 172.27.255.2 (172.27.255.2): 56 data bytes
--- 172.27.255.2 ping statistics ---


PING 172.27.255.3 (172.27.255.3): 56 data bytes
--- 172.27.255.3 ping statistics ---


PING 172.27.255.4 (172.27.255.4): 56 data bytes
--- 172.27.255.4 ping statistics ---

TASK 3
The routes associated with the link between R2 and T1, and the
routes associated with the link between R5 and T2 must appear as
internal IS-IS routes within your network. However, the IPv6 routes
from these links must not appear in R1’s routing table but must
appear in R2’s routing table. The [edit routing-options] hierarchy
level on R1 cannot be altered to accomplish this task.

Question: What type of interface routes exist on the link
between R5 and T2?
Answer: IPv4 and IPv6 interface routes exist on these links.
TASK INTERPRETATION
In the first part of this task, you must enable IS-IS on the ge-0/0/5 interface on R5 and the
ge-0/0/2 interface on R2. Then you must place these interfaces within the IS-IS protocol of the
respective routers. Place these interfaces into passive mode to inject these interface routes as
internal routes in your IS-IS domain. Route leaking on R3 and R4 is required to advertise these
routes to R1 and R2. Update your recently configured route leaking policy to accomplish this
part of the task.
The last task states that the IPv6 routes associated with these links cannot be present in R1’s
routing table. If the task allowed you to alter the [edit routing-options] hierarchy level,
you could simply add the IPv6 prefix in question to the martian route list, but this is not a
method you can use to accomplish this task. Also, you cannot use route leaking to accomplish
this task because R2 must have this route in its routing table. The only means necessary to
accomplish this task is to disable IPv6 routing on R2 by issuing the no-ipv6-routing
command under the [edit protocols isis] hierarchy level.
TASK COMPLETION
• R2:
lab@R2# set interface ge-0/0/2 passive

lab@R2# commit
commit complete
• R5:
lab@R5# set interface ge-0/0/5 passive

lab@R5# commit
commit complete
• R3:
lab@R3# top edit policy-options policy-statement leak-routes term r5-IPv4-int
[edit policy-options policy-statement leak-routes term r5-IPv4-int]




lab@R3# set from route-filter 172.27.0.56/30 exact



lab@R3# up 1 edit term r5-IPv6-int



lab@R3# set from route-filter 2008:4498::38/126 exact



lab@R3# up

lab@R3# show
from {
protocol isis;
level 1;
}
to level 2;
then reject;
}
from {
protocol aggregate;
}
to level 2;
then accept;
}
term r5-IPv4-int {
from {
protocol isis;
level 2;

}
to level 1;
then accept;
}
term r5-IPv6-int {
from {
protocol isis;
level 2;
route-filter 2008:4498::38/126 exact;
}
to level 1;
then accept;
}

lab@R3# commit
commit complete
• R4:
lab@R4# top edit policy-options policy-statement leak-routes term r5-IPv4-int






lab@R4# up 1 edit term r5-IPv6-int



lab@R4# set from route-filter 2008:4498::38/126 exact



lab@R4# up

lab@R4# show
from {
protocol isis;
level 1;
}
to level 2;
then reject;
}
from {
protocol aggregate;
}
to level 2;
then accept;
}
term r5-IPv4-int {
from {
protocol isis;
level 2;
}
to level 1;
then accept;
}
term r5-IPv6-int {
from {
protocol isis;
level 2;
}
to level 1;
then accept;
}

lab@R4# commit
commit complete
• R1:
lab@R1# set no-ipv6-routing

lab@R1# commit
commit complete
TASK VERIFICATION
You can verify this task by examining the routing tables on R1, R2, and R5. The necessary routes
must appear in those routing tables. Also, verify that the IPv6 routes from R2 and R5 do not
appear in R1’s routing table.
• R1:
lab@R1# run show route protocol isis

0.0.0.0/0 *[IS-IS/15] 01:19:38, metric 10

to 172.27.0.13 via ge-0/0/6.0
> to 172.27.0.9 via ae1.0
172.27.0.4/30 *[IS-IS/15] 01:19:38, metric 20
> to 172.27.0.9 via ae1.0
to 172.27.0.2 via ge-0/0/3.0
172.27.0.36/30 *[IS-IS/15] 01:19:38, metric 20
> to 172.27.0.2 via ge-0/0/3.0
172.27.0.56/30 *[IS-IS/18] 01:19:38, metric 30
to 172.27.0.13 via ge-0/0/6.0
> to 172.27.0.9 via ae1.0
172.27.255.2/32 *[IS-IS/15] 01:19:38, metric 10
> to 172.27.0.2 via ge-0/0/3.0
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
inet6.0: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)
• R2:

0.0.0.0/0 *[IS-IS/15] 23:58:22, metric 10

> to 172.27.0.6 via ae0.0
172.27.0.8/30 *[IS-IS/15] 23:58:12, metric 20
to 172.27.0.1 via ge-0/0/1.0
> to 172.27.0.6 via ae0.0
172.27.0.12/30 *[IS-IS/15] 23:59:09, metric 20
> to 172.27.0.1 via ge-0/0/1.0
172.27.0.56/30 *[IS-IS/18] 00:01:02, metric 30
> to 172.27.0.6 via ae0.0
172.27.255.1/32 *[IS-IS/15] 23:59:09, metric 10
> to 172.27.0.1 via ge-0/0/1.0


::/0 *[IS-IS/15] 23:58:22, metric 10

> to fe80::5254:ff:fe00:9402 via ae0.0
2008:4489::4/126 *[IS-IS/15] 23:58:12, metric 20
> to fe80::5254:ff:fe00:9402 via ae0.0
2008:4489::8/126 *[IS-IS/15] 23:58:12, metric 20
> to fe80::5254:ff:fe00:9402 via ae0.0
2008:4498::38/126 *[IS-IS/18] 00:01:02, metric 30
> to fe80::5254:ff:fe00:9402 via ae0.0
• R5:

172.27.0.0/30 *[IS-IS/18] 1d 01:19:23, metric 30

> to 172.27.0.26 via ge-0/0/1.0
to 172.27.0.21 via ae2.0
172.27.0.4/30 *[IS-IS/18] 1d 01:19:13, metric 20
> to 172.27.0.21 via ae2.0
172.27.0.8/30 *[IS-IS/18] 1d 01:19:13, metric 20
> to 172.27.0.21 via ae2.0
172.27.0.12/30 *[IS-IS/18] 1d 01:19:44, metric 20
> to 172.27.0.26 via ge-0/0/1.0
172.27.0.16/30 *[IS-IS/18] 1d 01:19:13, metric 20
> to 172.27.0.26 via ge-0/0/1.0
to 172.27.0.21 via ae2.0
172.27.0.36/30 *[IS-IS/18] 03:07:51, metric 30
> to 172.27.0.21 via ae2.0
172.27.255.0/30 *[IS-IS/165] 22:14:37, metric 20
to 172.27.0.26 via ge-0/0/1.0
> to 172.27.0.21 via ae2.0
172.27.255.3/32 *[IS-IS/18] 1d 01:19:44, metric 10
> to 172.27.0.26 via ge-0/0/1.0
172.27.255.4/32 *[IS-IS/18] 1d 01:19:13, metric 10
> to 172.27.0.21 via ae2.0

2008:4489::4/126 *[IS-IS/18] 1d 01:19:13, metric 20

> to fe80::5254:ff:fe00:9404 via ae2.0
2008:4489::8/126 *[IS-IS/18] 1d 01:19:13, metric 20
> to fe80::5254:ff:fe00:9404 via ae2.0

2008:4489::c/126 *[IS-IS/18] 1d 01:19:44, metric 20
> to fe80::5668:29ff:fe7a:998f via ge-0/0/1.0
2008:4489::10/126 *[IS-IS/18] 1d 01:19:13, metric 20
> to fe80::5668:29ff:fe7a:998f via ge-0/0/1.0
to fe80::5254:ff:fe00:9404 via ae2.0
2008:4498::/126 *[IS-IS/18] 01:21:26, metric 30
> to fe80::5254:ff:fe00:9404 via ae2.0
2008:4498::4/126 *[IS-IS/18] 1d 01:19:23, metric 30
> to fe80::5254:ff:fe00:9404 via ae2.0
2008:4498::24/126 *[IS-IS/18] 03:07:51, metric 30
> to fe80::5254:ff:fe00:9404 via ae2.0
TASK 4
Configure R1 to receive RIP routes from C1. Then configure R1 to
send a summary route to C1 only when R2’s loopback address is
present in R1’s routing table. This summary route should represent
your internal IPv4 address space. The routes received from C1 must
be present in area 49.0001 as IS-IS external routes. These
individual routes must not appear in the routing table of R5.
However, you must ensure that R5 can reach these destinations.
Question: Must the summary route be as specific as possible to

accomplish this task?
Answer: No. The task does not state that the summary route
must be the most specific summary route possible. You can use
the 172.27.0.0/16 summary route to accomplish this task.
TASK INTERPRETATION
To complete this task, you must first configure R1 to exchange RIP routes with C1. You must
configure a generate route on R1 that is attached to a policy that allows it to accept only R2’s
loopback address as a contributing route, and then export this generate route into RIP through a
policy. The RIP routes on R1 that are being received from C1 must now be exported into IS-IS.
By default, the Junos OS does not flood Level 1 external routes to Level 2 routers. R5 does not
receive these routes and no action is required to accomplish this part of the task. However, you
must create aggregate routes on R3 and R4, which represents these routes, and flood these
aggregate routes into Level 2, which then allows R5 to reach these destinations.
TASK COMPLETION
• R1:
lab@R1# set export isis-out

lab@R1# up 1 edit rip group rip-c1
[edit protocols rip group rip-c1]

lab@R1# set neighbor ge-0/0/1


lab@R1# set export rip-out

lab@R1# set generate route 172.27/16 policy isis-present
lab@R1# top edit policy-options policy-statement rip-out term gen-rip
[edit policy-options policy-statement rip-out term gen-rip]


lab@R1# set from route-filter 172.27/16 exact


lab@R1# up 2 edit policy-statement isis-present term isis
[edit policy-options policy-statement isis-present term isis]


lab@R1# set from route-filter 172.27.255.2 exact


lab@R1# up 1 edit term no-other-routes
[edit policy-options policy-statement isis-present term no-other-routes]

[edit policy-options policy-statement isis-present term no-other-routes]

lab@R1# up 2 edit policy-statement isis-out term rip-isis
[edit policy-options policy-statement isis-out term rip-isis]

lab@R1# set from protocol rip


lab@R1# top show protocols
isis {
export isis-out;
no-ipv6-routing;
level 2 disable;

interface all;
}
rip {
group rip-c1 {
export rip-out;
neighbor ge-0/0/1.0;
}
}

lab@R1# top show policy-options
policy-statement isis-out {
term rip-isis {
from protocol rip;
then accept;
}
}
policy-statement isis-present {
term isis {
from {
protocol isis;
}
then accept;
}
term no-other-routes {
then reject;
}
}
policy-statement rip-out {
term gen-rip {
from {
protocol aggregate;
}
then accept;
}
}

lab@R1# commit
commit complete
• R3:
lab@R3# top set routing-options aggregate route 172.16.16/21

lab@R3# edit term lvl-1-ext
[edit policy-options policy-statement leak-routes term lvl-1-ext]





lab@R3# show
from {
protocol aggregate;
}
to level 2;
then accept;

lab@R3# commit
commit complete
• R4:

lab@R4# edit term lvl-1-ext





lab@R4# show
from {
protocol aggregate;
}
to level 2;
then accept;

lab@R4# commit
commit complete
TASK VERIFICATION
To verify this task, examine the routing tables of R1 and R5. The RIP routes should be present on
R1 and the summary route should be present on R5. Next, examine the generate route on R1
using the show route 172.16.16/21 exact detail command. In this output, you can
see that the only contributing route is the loopback address of R2. To ensure R1 is advertising
the generate route to C1, issue the show route advertising-protocol rip
172.27.0.29 command. Then, to ensure reachability from R5 to the prefixes C1 is
advertising, issue the ping 172.16.16.1 detail count 2 command on R5.
• R1:

172.16.16.0/29 *[RIP/100] 02:46:19, metric 2, tag 0

> to 172.27.0.30 via ge-0/0/1.0
172.16.20.0/24 *[RIP/100] 02:46:19, metric 2, tag 0
> to 172.27.0.30 via ge-0/0/1.0
172.16.21.0/24 *[RIP/100] 02:46:19, metric 2, tag 0
> to 172.27.0.30 via ge-0/0/1.0

lab@R1# run show route 172.27/16 exact detail

172.27.0.0/16 (1 entry, 1 announced)
*Aggregate Preference: 130
Next hop type: Router, Next hop index: 595
Next-hop reference count: 6
Next hop: 172.27.0.2 via ge-0/0/3.0, selected
State: <Active Int Ext>
Age: 2:49:16
Task: Aggregate
Announcement bits (2): 0-KRT 3-RIPv2
AS path: I
Flags: Generate Depth: 0 Active
Contributing Routes (1):
172.27.255.2/32 proto IS-IS

lab@R1# run show route advertising-protocol rip 172.27.0.29

172.27.0.0/16 *[Aggregate/130] 02:49:32

> to 172.27.0.2 via ge-0/0/3.0

• R5:

172.16.16.0/21 *[IS-IS/165] 00:24:16, metric 20

to 172.27.0.26 via ge-0/0/1.0
> to 172.27.0.21 via ae2.0

PING 172.16.16.1 (172.16.16.1): 56 data bytes

TASK 5
Configure R3 and R5 to receive OSPF routes from DC3. Create the most
specific summary route possible that represents these routes and
redistribute the summary route into IS-IS. This summary route must
appear on R4 with a metric that is greater than 300. However, it
must appear on R1 and R2 with a metric that is less than 84.
TASK INTERPRETATION
To complete this task, you must first configure R3 and R5 to communicate through OSPF with
DC3. After establishing OSPF adjacencies, R3 and R5 receive OSPF routes in the 10.22.0.0/21
range. You must then create an aggregate route that represents these prefixes, and then
redistribute it into IS-IS. Be aware that when you redistribute the aggregate route into IS-IS, you
should not specify which protocol it originates from in the policy. Doing so might cause problems
when redistributing the route from R3 and R5. R3 might receive the redistributed aggregate
route from R5 with a route preference of 18. This preference is lower than the aggregate route
preference of 130 and causes R3 not to advertise its locally created aggregate route. When
creating the policy that redistributes the 10.22.0.0/21 prefix into IS-IS, remember to apply a
metric value to the route which is greater than 300.
By default, Level 2 external routes do not flood to Level 1 routers. You must adjust the route
leaking policy on R4 to allow the flooding of this route from R4 to the Level 1 routers; R1 and R2.
To ensure R4 receives the 10.22.0.0/21 prefix with a metric value that is greater than 300, you
must enable Level 2 wide metrics on R3, R4, and R5. This setting allows the prefix to appear on
these routers with a metric value that is greater than 300. By not enabling Level 1 wide metrics
on R1, R2, R3, and R4, the metric value is less than 84 on R1 and R2.

TASK COMPLETION
• R3:
lab@R3# top edit protocols ospf

lab@R3# set area 0 interface ge-0/0/4

lab@R3# top set routing-options aggregate route 10.22/21

lab@R3# top edit policy-options policy-statement ospf-isis term agg
[edit policy-options policy-statement ospf-isis term agg]



lab@R3# set then metric 301



lab@R3# set export ospf-isis

lab@R3# set level 2 wide-metrics-only

lab@R3# up 1 show
isis {
export [ leak-routes ospf-isis ];
level 2 wide-metrics-only;
interface ge-0/0/1.0 {
level 2 disable;
}
level 1 disable;
}
level 1 disable;
}
interface lo0.0 {
level 1 disable;
}
}
ospf {

area 0.0.0.0 {
interface ge-0/0/4.0;
}
}

lab@R3# top show policy-options policy-statement ospf-isis
term agg {
from {
}
to level 2;
then {
metric 301;
accept;
}
}

lab@R3# commit
commit complete
• R4:
lab@R4# top set protocols isis level 2 wide-metrics-only

lab@R4# up 1 edit term lvl-2-ext





lab@R4# show
from {
protocol isis;
}
to level 1;
then accept;

lab@R4# top show protocols
isis {

export leak-routes;
level 1 disable;
}
interface ae0.0 {
level 2 disable;
}
interface ae1.0 {
level 2 disable;
}
interface ae2.0 {
level 1 disable;
}
interface lo0.0 {
level 1 disable;
}
}

lab@R4# up 1 show
from {
protocol isis;
level 1;
}
to level 2;
then reject;
}
from {
protocol aggregate;
}
to level 2;
then accept;
}
term r5-IPv4-int {
from {
protocol isis;
level 2;
}
to level 1;
then accept;
}
term r5-IPv6-int {
from {
protocol isis;
level 2;
}
to level 1;
then accept;

}
term lvl-1-ext {
from {
protocol aggregate;
}
to level 2;
then accept;
}
term lvl-2-ext {
from {
protocol isis;
}
to level 1;
then accept;
}

lab@R4# commit
commit complete
• R5:



lab@R5# top edit policy-options policy-statement ospf-isis term agg





lab@R5# set export ospf-isis

lab@R5# set level 2 wide-metrics-only

lab@R5# top show policy-options
policy-statement ospf-isis {
term agg {
from {
}
then {
metric 301;
accept;
}
}
}

lab@R5# up 1 show
isis {
export ospf-isis;
level 1 disable;
passive;
}
interface all;
}
ospf {
area 0.0.0.0 {
}
}

lab@R5# commit
commit complete
TASK VERIFICATION
To verify this task, examine the routing tables on R1, R2, and R4. The 10.22.0.0/21 prefix
appears on R1 and R2 with a metric value that is less than 84. The same prefix appears on R4
with a metric value that is greater than 300.
• R1:
lab@R1# run show route 10.22/21

10.22.0.0/21 *[IS-IS/18] 01:18:15, metric 73

> to 172.27.0.9 via ae1.0

• R2:

10.22.0.0/21 *[IS-IS/18] 01:19:06, metric 73

> to 172.27.0.6 via ae0.0
• R4:

10.22.0.0/21 *[IS-IS/18] 15:35:30, metric 311

> to 172.27.0.22 via ae2.0
TASK 6
The 10.100.100.0/24 prefix is being used to reach destinations
behind DC1 through static routing on R2 and R4. Redistribute this
prefix into IS-IS. Ensure R2 is the primary path and R4 is the
backup path for this prefix for R1. Ensure R4 is the primary path
and R2 is the backup path for this prefix for R5.
Question: Which option in a routing policy can help you identify a

route later, after you redistribute it into IS-IS?
Answer: You can add the tag option to a route in a routing

policy. This can assist you in identifying the route later, after you
redistribute it into IS-IS.
TASK INTERPRETATION
To complete this task, you must redistribute the 10.100.100.0/24 static route found on R2 and
R4 into IS-IS. Redistributing the static route on R2 is fairly straightforward, however you must
leak this route into Level 2 to accomplish the redundancy criterion. It might be helpful to add a
tag value to the route when you redistribute it into IS-IS. This allows you to easily identify the
route in the route leaking policy found on R3.
To redistribute the static route on R4, you must add two terms to R4’s route leaking policy. The
first term must redistribute the route into Level 2. The second term must redistribute the route
into Level 1. However, when injecting the route into Level 1, you must add a metric value that
makes it less preferable than the static route R2 is injecting into Level 1.
Then, you must configure a route leaking policy on R3 to leak the 10.100.100.0/24 prefix, that is
present in Level 1, into Level 2. This satisfies the redundancy criterion for this task.

TASK COMPLETION
• R2:
lab@R2# set export static-isis

lab@R2# top edit policy-options policy-statement static-isis term DC1-prefix
[edit policy-options policy-statement static-isis term DC1-prefix]

lab@R2# set from protocol static


lab@R2# set then tag 102


lab@R2# show
from {
protocol static;
}
then {
tag 102;
accept;
}

lab@R2# commit
commit complete
• R4:
lab@R4# up 1 edit term static-DC-lvl-1
[edit policy-options policy-statement leak-routes term static-DC-lvl-1]







lab@R4# up 1 edit term static-DC-lvl-2






lab@R4# up 1

lab@R4# show
...
term static-DC-lvl-1 {
from {
protocol static;
}
to level 1;
then {
metric 63;
tag 104;
accept;
}
}
term static-DC-lvl-2 {
from {
protocol static;
}
to level 2;
then {
tag 104;
accept;
}
}
lab@R4# commit

commit complete
• R3:
lab@R3# top edit policy-options policy-statement leak-routes term
DC1-lvl-1-to-lvl-2
[edit policy-options policy-statement leak-routes term DC1-lvl-1-to-lvl-2]



lab@R3# set from tag 102





lab@R3# show
from {
protocol isis;
level 1;
tag 102;
}
to level 2;
then {
metric 100;
accept;
}

lab@R3# commit
commit complete

TASK VERIFICATION
To verify this task, examine the routing tables on R1 and R5 for the primary routes. Then
examine the IS-IS link state databases on R1 and R5 for the backup routes. In the IS-IS link state
database, each router will have two LSPs for the route. R1 has LSPs from R2 and R4 that contain
the 10.100.100.0/24 prefix, however the LSP from R2 has a lower metric for the route. R5 has
LSPs from R3 and R4 that contain the 10.100.100.0/24 prefix, however the LSP from R4 has a
lower metric for the route.
• R1:

10.100.100.0/24 *[IS-IS/160] 00:05:47, metric 10, tag 102

> to 172.27.0.2 via ge-0/0/3.0

lab@R1# run show isis database detail R2 | match 10.100.100.0/24
IP prefix: 10.100.100.0/24 Metric: 0 External Up
[[edit policy-options policy-statement isis-out term rip-isis]

IP prefix: 10.100.100.0/24 Metric: 63 External Up
• R5:

10.100.100.0/24 *[IS-IS/18] 00:04:58, metric 10, tag 104

> to 172.27.0.21 via ae2.0

IP prefix: 10.100.100.0/24 Metric: 0 Internal Up

TASK 7
Configure all interfaces participating in a level 2 adjacency to
monitor the adjacencies using sub-second link failure detection. If
the local router is the DR for a level 1 broadcast segment, the
interface involved must have an IS-IS hold-time value of 2 seconds.

Question: Which command can help you collect DR related
information?
Answer: The show isis interfaces detail command

displays DR related information on a per interface basis.
TASK INTERPRETATION
To achieve sub-second failover capabilities with all Level 2 adjacencies, you must configure BFD
on the interfaces that require it. Configure BFD with a minimum-interval value of 333
milliseconds or less. This gives a Detect time value of less than one second.
To complete the next part of this task, you must adjust the hold-time value for all Level 1
adjacencies to 6 seconds. Alternatively, you can configure the hello-interval value to 2
seconds which results in a 6 second hold-time value. There is no need to configure non-DR
interfaces differently than DR interfaces. Configuring all Level 1 interfaces with a hold-time
value of 6 results in DR interfaces having a hold-time value of 2. If you configure DR
interfaces with a hold-time value of 2 the resulting hold-time value is actually 1 second.
TASK COMPLETION
• R1:

lab@R1# set interface all level 1 hold-time 6

lab@R1# show
export isis-out;
no-ipv6-routing;
level 2 disable;
interface all {
level 1 hold-time 6;
}

lab@R1# commit
commit complete
• R2:

lab@R2# set interface all level 1 hold-time 6

lab@R2# show
export static-isis;

level 2 disable;
passive;
}
interface all {
}

lab@R2# commit
commit complete
• R3:

lab@R3# set interface ge-0/0/1 level 1 hold-time 6

lab@R3# set interface ge-0/0/2 bfd-liveness-detection minimum-interval 150


lab@R3# show
level 2 disable;
level 1 {
hold-time 6;
}
}
bfd-liveness-detection {
minimum-interval 150;
}
level 1 disable;
}
}
level 1 disable;
}
interface lo0.0 {
level 1 disable;
}

lab@R3# commit
commit complete
• R4:


lab@R4# set interface ae0 level 1 hold-time 6

lab@R4# set interface ae1 level 1 hold-time 6

lab@R4# set interface ae2 bfd-liveness-detection minimum-interval 150

lab@R4# show
export leak-routes;
}
level 1 disable;
}
interface ae0.0 {
level 2 disable;
}
interface ae1.0 {
level 2 disable;
}
interface ae2.0 {
}
level 1 disable;
}
interface lo0.0 {
level 1 disable;
}

lab@R4# commit
commit complete

• R5:
lab@R5# set interface all bfd-liveness-detection minimum-interval 150

lab@R5# show
export ospf-isis;
level 1 disable;
passive;
}
interface all {
}
}

lab@R5# commit
commit complete
TASK VERIFICATION
To verify the hold-time values, issue the show isis interface detail command on
R1, R2, R3, and R4. To verify the BFD detection and failover timers, issue the show bfd
session command on R3, R4, and R5.
• R1:
lab@R1# run show isis interface detail
IS-IS interface database:
ae1.0
Index: 76, State: 0x6, Circuit id: 0x1, Circuit type: 1
LSP interval: 100 ms, CSNP interval: 10 s
Adjacency advertisement: Advertise
Level Adjacencies Priority Metric Hello (s) Hold (s) Designated Router
1 1 64 10 2.000 6 R4.04 (not us)
ge-0/0/3.0
1 1 64 10 0.666 2 R1.02 (us)
ge-0/0/6.0
1 1 64 10 0.666 2 R1.03 (us)
lo0.0
LSP interval: 100 ms, CSNP interval: disabled

1 0 64 0 Passive
2 0 64 0 Passive
lo0.32768
1 0 64 0 Passive
2 0 64 0 Passive
• R2:
ae0.0
1 1 64 10 2.000 6 R4.05 (not us)
ge-0/0/1.0
1 1 64 10 2.000 6 R1.02 (not us)
ge-0/0/2.0
1 0 64 10 Passive
2 0 64 10 Passive
lo0.0
1 0 64 0 Passive
2 0 64 0 Passive
lo0.32768
1 0 64 0 Passive
2 0 64 0 Passive
• R3:

ge-0/0/1.0
1 1 64 10 2.000 6 R1.03 (not us)
ge-0/0/2.0
2 1 64 10 9.000 27 R4.02 (not us)
ge-0/0/3.0
2 1 64 10 3.000 9 R3.02 (us)
lo0.0
2 0 64 0 Passive

lab@R3# run show bfd session
Detect Transmit
Address State Interface Time Interval Multiplier
172.27.0.18 Up ge-0/0/2.0 0.450 0.150 3
172.27.0.25 Up ge-0/0/3.0 0.450 0.150 3
2 sessions, 2 clients
Cumulative transmit rate 13.3 pps, cumulative receive rate 13.3 pps
• R4:
ae0.0
1 1 64 10 0.666 2 R4.05 (us)
ae1.0
1 1 64 10 0.666 2 R4.04 (us)
ae2.0

2 1 64 10 3.000 9 R4.03 (us)
ge-0/0/5.0
2 1 64 10 3.000 9 R4.02 (us)
lo0.0
2 0 64 0 Passive

Detect Transmit
172.27.0.17 Up ge-0/0/5.0 0.450 0.150 3
172.27.0.22 Up ae2.0 0.450 0.150 3
• R5:
Detect Transmit
172.27.0.21 Up ae2.0 0.450 0.150 3
172.27.0.26 Up ge-0/0/1.0 0.450 0.150 3
TASK 8
Configure the routers in both areas to authenticate hello PDUs
using the unencrypted password of Juniper. Configure the routers in
area 49.0001 to authenticate LSPs using the encrypted password of
JuniperRocks. No routing disruption can occur between R3 and R4
during this process.
Question: What type of authentication must you use to

authenticate LSPs?
Answer: You must use area authentication to authenticate

LSPs.

TASK INTERPRETATION
To accomplish this task, configure hello authentication using a plain text password on R1, R2,
R3, and R4. R1 and R2 require this authentication for all of their interfaces. R3 requires this
authentication for interface ge-0/0/1; and R4 requires this authentication for interfaces ae0
and ae1.
Configure area authentication for Level 1 on R1, R2, R3, and R5 to complete this part of the
task. Be sure to encrypt the password using MD5 authentication.
When hello or area authentication is configured, the routers must take down the IS-IS adjacency
and establish it again to accommodate the authentication. To change this behavior, issue the
no-authentication-check command at the global IS-IS protocol level. This action results
in an authentication check failing to occur on R3 and R4, and any other connected routers to R3
and R4, but satisfies the requirements for the task.
TASK COMPLETION
• R1:
lab@R1# set interface all level 1 hello-authentication-type simple

lab@R1# set interface all level 1 hello-authentication-key Juniper

lab@R1# set level 1 authentication-type md5

lab@R1# set level 1 authentication-key JuniperRocks

lab@R1# commit
commit complete
• R2:




lab@R2# commit
commit complete

• R3:
lab@R3# set interface ge-0/0/1 level 1 hello-authentication-type simple

lab@R3# set interface ge-0/0/1 level 1 hello-authentication-key Juniper







lab@R3# set no-authentication-check

lab@R3# commit
commit complete
• R4:
lab@R4# set interface ae0 level 1 hello-authentication-type simple

lab@R4# set interface ae0 level 1 hello-authentication-key Juniper









lab@R4# set no-authentication-check

lab@R4# commit
commit complete
• R5:


lab@R5# commit
Commit complete
TASK VERIFICATION
To verify this task, issue the show isis authentication command on all the internal
routers. Also, examine the IS-IS adjacencies to ensure that they were maintained. You will need
to remove the no-authentication-check option on R3 and R4 to truly verify this task.
Once you have verified the correct authentication keys have been configured you do not need to
reconfigure the no-authentication-check feature.
• R3:
lab@R3# delete no-authentication-check

lab@R3# commit
commit complete

lab@R3# run show isis authentication
Interface Level IIH Auth CSN Auth PSN Auth
ge-0/0/1.0 1 Simple MD5 MD5
ge-0/0/2.0 2 Simple None None

L1 LSP Authentication: MD5

L2 LSP Authentication: None

ge-0/0/1.0 R1 1 Up 1 56:68:29:7a:91:f1
ge-0/0/2.0 R4 2 Up 8 56:68:29:7a:a9:ef
ge-0/0/3.0 R5 2 Up 22 56:68:29:7a:8e:5
• R4:
lab@R4# delete no-authentication-check

lab@R4# commit
commit complete

ae0.0 1 Simple MD5 MD5
ae2.0 2 Simple None None


ae0.0 R2 1 Up 5 52:54:0:0:32:2
ae1.0 R1 1 Up 4 52:54:0:0:43:3
ae2.0 R5 2 Up 23 52:54:0:0:1a:4
ge-0/0/5.0 R3 2 Up 25 56:68:29:7a:9c:bd
• R1:


ae1.0 R4 1 Up 1 52:54:0:0:94:3
ge-0/0/3.0 R2 1 Up 4 56:68:29:7a:a7:56
ge-0/0/6.0 R3 1 Up 5 56:68:29:7a:87:a9
• R2:

ae0.0 R4 1 Up 1 52:54:0:0:94:2
ge-0/0/1.0 R1 1 Up 1 56:68:29:7a:a8:bf
• R5:
ae2.0 2 Simple None None

ae2.0 R4 2 Up 7 52:54:0:0:94:4
ge-0/0/1.0 R3 2 Up 7 56:68:29:7a:99:8f
TASK 9
All IS-IS LSPs should be valid for one hour.
Question: How long is an IS-IS LSP valid by default?
Answer: By default, the Junos OS allows IS-IS LSPs to be valid for

20 minutes, or 1,200 seconds.
TASK INTERPRETATION
To complete this task, you must adjust the LSP lifetime on each internal router to 3,600 seconds.
This allows the LSPs to remain valid in the IS-IS link state database for 1 hour.

TASK COMPLETION
• R1:
lab@R1# set lsp-lifetime 3600

lab@R1# commit
commit complete
• R2:

lab@R2# commit
commit complete
• R3:

lab@R3# commit
commit complete
• R4:

lab@R4# commit
commit complete
• R5:

lab@R5# commit
commit complete

TASK VERIFICATION
To verify this task, issue the show isis overview command on each internal router. This
command displays the current LSP lifetime value for the local router.
• R1
Instance: master
Router ID: 172.27.255.1
Maximum Areas: 3
LSP life time: 3600
IPv4 is enabled
Restart: Enabled
Level 1
Wide metrics are enabled
Level 2
• R2:
Instance: master
Router ID: 172.27.255.2
Maximum Areas: 3
LSP life time: 3600
Restart: Enabled
Level 1
Level 2

• R3:
Instance: master
Router ID: 172.27.255.3
Maximum Areas: 3
LSP life time: 3600
Restart: Enabled
Level 1
Level 2
• R4:
Instance: master
Router ID: 172.27.255.4
Maximum Areas: 3
LSP life time: 3600
Restart: Enabled
Level 1
Level 2
• R5:
Instance: master

Router ID: 172.27.255.5
Maximum Areas: 3
LSP life time: 3600
Restart: Enabled
Level 1
Level 2

Lab
OSPF Implementation
In this lab, you will be given a list of tasks specific to OSPF implementation to accomplish in a
timed setting. You will have 1 hour and 15 minutes to complete the simulation.
• Configure all internal routers to route traffic using OSPF. Configure the OSPF areas as
shown on the “OSPF Implementation” lab diagram.
• Ensure that no OSPF DR or BDR exists among your internal routers.
• Routers R1, R3, and R4 must authenticate all OSPF exchanges within Area 0 using
the unencrypted password of Juniper.
• Ensure that all OSPF links with the following bandwidth values are assigned the
following OSPF cost values.
– 1 Gbps = 50
– 2 Gbps = 25
– 3 Gbps = 16
• If R4 reboots, configure it to wait 240 seconds after the OSPF instance has started
before passing transit traffic.
• Configure the OSPF adjacencies over the ae0 link to be declared down if 2 hello
packets are missed.
• The interface routes for the links between R5 and T2, and R2 and T1 must appear on
Area 0 routers as internal OSPF routes. No OSPF adjacencies can form over these
links.
• Configure R1 to exchange RIP routes with C1. Create the most specific summary
route possible that represents these routes and redistribute the summary route into
OSPF. This summary route must be present on R2.
• Configure R3 and R5 to receive RIP routes from DC3. All other routers in your OSPF
domain must be able to reach these destinations. However, the primary path to these
destinations must lead through R3. Even R5 must use R3 as the primary path for
these destinations.
• No Type 5 or Type 3 LSAs are allowed in Area 2. R5 must use R3 to reach unknown
destinations. R5 must use R4 to reach unknown destinations only if the link between
R5 and R3 fails. Configure R3 to attach a metric of 10 and R4 to attach a metric of 5
to their respective default routes they inject into Area 2.
www.juniper.net OSPF Implementation • Lab 3–1

• Redistribute the interface route for the link between R5 and DC3 into OSPF as an
external OSPF route. This route must be present in Area 1 as an external LSA but
cannot be present in R2’s routing table. The [edit routing-options] hierarchy
level on R2 cannot be altered to accomplish this task.
• Redistribute the static routes found on R5 into OSPF. These specific routes must be
present in Area 2 but cannot be present in Area 1. However, R2 must be able to reach
these destinations.
Lab 3–2 • OSPF Implementation www.juniper.net

Implementing OSPF
In this lab part, you will become familiar with implementing OSPF as the IGP in your network. You
will be given a list of tasks that will require you to configure and monitor OSPF operations.
TASK 1
Configure all internal routers to route traffic using OSPF.
Configure the OSPF areas as shown on the “OSPF Implementation” lab
diagram.
Question: What OSPF areas must you configure?
Answer: You must configure the OSPF Area 0, Area 1, and Area
2.
TASK INTERPRETATION
To complete this task, you must configure the OSPF area boundaries as shown on the “OSPF
Implementation” lab diagram. However, if you read on to the seventh task for this part, you will
find that you must redistribute IPv6 routes into OSPF. This requires you to configure OSPFv2 and
OSPFv3 to accommodate both IPv4 and IPv6 routes within your network. Configuring both
protocols now will save you time and effort.
Although not explicitly shown, place the loopback interface within Area 0 if the router is
participating in Area 0. For non-Area 0 routers, place the loopback interface in the area in which
the routers reside. This part of the task is only necessary for OSPFv2 and is not applicable for
OSPFv3.
TASK COMPLETION
• R1:
Welcome to the cloud
password is Clouds
R1 (ttyd0)
login: lab
Password:

lab@R1> configure
[edit]
lab@R1# edit protocols ospf

lab@R1# set area 0 interface ae1


lab@R1# set area 0 interface lo0


lab@R1# up 1 edit ospf3
[edit protocols ospf3]




lab@R1# up 1 show
ospf {
area 0.0.0.0 {
interface ae1.0;
interface lo0.0;
}
area 0.0.0.1 {
}
}
ospf3 {
area 0.0.0.0 {
interface ae1.0;
}
area 0.0.0.1 {
}
}

lab@R1# commit
commit complete
• R2:
password is Clouds
R2 (ttyd0)
login: lab
Password:

lab@R2> configure
[edit]







lab@R2# up 1 show
ospf {
area 0.0.0.1 {
interface ae0.0
interface ge-0/0/1.0
interface lo0.0
}
}
ospf3 {
area 0.0.0.1 {
interface ae0.0
}
}

lab@R2# commit
commit complete
• R3:
password is Clouds
R3 (ttyd0)
login: lab
Password:


lab@R3> configure
[edit]









lab@R3# up 1 show
ospf {
area 0.0.0.0 {
interface lo0.0;
}
area 0.0.0.2 {
}
}
ospf3 {
area 0.0.0.0 {
}
area 0.0.0.2 {
}
}

lab@R3# commit
commit complete
• R4:
password is Clouds
R4 (ttyd0)
login: lab
Password:

lab@R4> configure
[edit]











lab@R4# up 1 show
ospf {
area 0.0.0.0 {

interface ae1.0;
interface lo0.0;
}
area 0.0.0.1 {
interface ae0.0;
}
area 0.0.0.2 {
interface ae2.0;
}
}
ospf3 {
area 0.0.0.0 {
interface ae1.0;
}
area 0.0.0.1 {
interface ae0.0;
}
area 0.0.0.2 {
interface ae2.0;
}
}

lab@R4# commit
commit complete
• R5:
password is Clouds
R5 (ttyd0)
login: lab
Password:

lab@R5> configure
[edit]







lab@R5# up 1 show
ospf {
area 0.0.0.2 {
interface lo0.0
interface ae2.0
}
}
ospf3 {
area 0.0.0.2 {
interface ae2.0
}
}

lab@R5# commit
commit complete
TASK VERIFICATION
Issue the show ospf neighbors and show ospf3 neighbors commands on all internal
routers to verify the operation of OSPFv2 and OSPFv3. The task is complete if all adjacencies
reach the Full state.
• R1:
172.27.0.9 ae1.0 Full 172.27.255.4 128 39
172.27.0.13 ge-0/0/6.0 Full 172.27.255.3 128 39
172.27.0.2 ge-0/0/3.0 Full 172.27.255.2 128 35

lab@R1# run show ospf3 neighbor
ID Interface State Pri Dead
172.27.255.4 ae1.0 Full 128 37
Neighbor-address fe80::5254:ff:fe00:9403
172.27.255.3 ge-0/0/6.0 Full 128 38
Neighbor-address fe80::5668:29ff:fe7a:87a9
172.27.255.2 ge-0/0/3.0 Full 128 39
Neighbor-address fe80::5668:29ff:fe7a:a756

• R2:
172.27.0.6 ae0.0 Full 172.27.255.4 128 39
172.27.0.1 ge-0/0/1.0 Full 172.27.255.1 128 35

172.27.255.4 ae0.0 Full 128 34
172.27.255.1 ge-0/0/1.0 Full 128 39
Neighbor-address fe80::5668:29ff:fe7a:a8bf
• R3:
172.27.0.14 ge-0/0/1.0 Full 172.27.255.1 128 33
172.27.0.18 ge-0/0/2.0 Full 172.27.255.4 128 34
172.27.0.25 ge-0/0/3.0 Full 172.27.255.5 128 32

172.27.255.1 ge-0/0/1.0 Full 128 32
Neighbor-address fe80::5668:29ff:fe7a:91f1
172.27.255.4 ge-0/0/2.0 Full 128 37
Neighbor-address fe80::5668:29ff:fe7a:a9ef
172.27.255.5 ge-0/0/3.0 Full 128 38
Neighbor-address fe80::5668:29ff:fe7a:8e05
• R4:
172.27.0.10 ae1.0 Full 172.27.255.1 128 36
172.27.0.17 ge-0/0/5.0 Full 172.27.255.3 128 32
172.27.0.5 ae0.0 Full 172.27.255.2 128 38
172.27.0.22 ae2.0 Full 172.27.255.5 128 37

172.27.255.1 ae1.0 Full 128 31
172.27.255.3 ge-0/0/5.0 Full 128 36
Neighbor-address fe80::5668:29ff:fe7a:9cbd
172.27.255.2 ae0.0 Full 128 36

172.27.255.5 ae2.0 Full 128 33
Neighbor-address fe80::5254:ff:fe00:1a04
• R5:
172.27.0.21 ae2.0 Full 172.27.255.4 128 35
172.27.0.26 ge-0/0/1.0 Full 172.27.255.3 128 37

172.27.255.4 ae2.0 Full 128 36
172.27.255.3 ge-0/0/1.0 Full 128 35
Neighbor-address fe80::5668:29ff:fe7a:998f
TASK 2
Ensure that no OSPF DR or BDR exists among your internal routers.
Question: Before completing this task, how many DRs and

BDRs are present in your network?
Answer: Currently, one DR and one BDR are present for each
OSPFv2 and OSPFv3 pairing. Before completing this task, you
have 14 DRs and 14 BDRs in your network.
TASK INTERPRETATION
You might believe you can accomplish this task by setting the OSPF interface priority value to 0,
which renders the router ineligible to be the DR or BDR for that broadcast domain. However,
doing so causes all OSPF adjacencies to become stuck in the two-way state so LSA exchanges
cannot occur.
To accomplish this task, you must configure all OSPF links with point-to-point interfaces.
Because the router does not consider the link to be a broadcast domain there is no need for a
DR or BDR. Technically, you must also set the loopback interface for all routers as an OSPF
point-to-point or passive interface. Although, failing to do so on a real exam will likely not result
in point loss.
TASK COMPLETION
• R1:
lab@R1# set area 0 interface ae1 interface-type p2p

lab@R1# set area 0 interface ge-0/0/6 interface-type p2p





lab@R1# set area 0 interface lo0 passive


lab@R1# commit
commit complete
• R2:






lab@R2# commit
commit complete
• R3:









lab@R3# commit
commit complete
• R4:











lab@R4# commit
commit complete
• R5:






lab@R5# commit
commit complete
TASK VERIFICATION
To verify this task, issue the show ospf interface and show ospf3 interface
commands. The State field must indicate either PtToPt or DRother for the task to be
complete.
• R1:
lab@R1# run show ospf interface
Interface State Area DR ID BDR ID Nbrs
ae1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/6.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
ge-0/0/3.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1

lab@R1# run show ospf3 interface
ae1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/6.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/3.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1

• R2:
ae0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
ge-0/0/1.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
lo0.0 DRother 0.0.0.1 0.0.0.0 0.0.0.0 0

ae0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
ge-0/0/1.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
• R3:
ge-0/0/1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/2.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
ge-0/0/3.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1

ge-0/0/1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/2.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/3.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
• R4:
ae1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/5.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
ae0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
ae2.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1

ae1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/5.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ae0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
ae2.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
• R5:

ae2.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
ge-0/0/1.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
lo0.0 DRother 0.0.0.2 0.0.0.0 0.0.0.0 0

ae2.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
ge-0/0/1.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
TASK 3
Routers R1, R3, and R4 must authenticate all OSPF exchanges within
area 0 using the unencrypted password of Juniper.
Question: Does this task require you to configure authentication

for OSPFv3?
Answer: This task does not require you to configure

authentication for OSPFv3. Currently the Junos OS only supports
authentication for OSPFv3 through the use of IPsec security
associations. This method requires the use of encryption which
violates the criteria of the task.
TASK INTERPRETATION
To complete this task configure the interfaces that are within Area 0 on R1, R3, and R4 to use
plain text authentication. Then use a key value of Juniper.
TASK COMPLETION
• R1:
lab@R1# set area 0 interface ae1 authentication simple-password Juniper

lab@R1# set area 0 interface ge-0/0/6 authentication simple-password Juniper

lab@R1# commit
commit complete
• R3:


lab@R3# commit
commit complete
• R4:

lab@R4# set area 0 interface ae1 authentication simple-password Juniper

lab@R4# commit
commit complete
TASK VERIFICATION
To verify this task, issue the show ospf neighbor command on R1, R3, and R4. If the OSPF
adjacencies in Area 0 remain in the Full state, then the task is complete.
• R1:
172.27.0.9 ae1.0 Full 172.27.255.4 128 37
172.27.0.13 ge-0/0/6.0 Full 172.27.255.3 128 33
172.27.0.2 ge-0/0/3.0 Full 172.27.255.2 128 34
• R3:
172.27.0.14 ge-0/0/1.0 Full 172.27.255.1 128 36
172.27.0.18 ge-0/0/2.0 Full 172.27.255.4 128 33
172.27.0.25 ge-0/0/3.0 Full 172.27.255.5 128 39
• R4:
172.27.0.10 ae1.0 Full 172.27.255.1 128 36
172.27.0.17 ge-0/0/5.0 Full 172.27.255.3 128 39
172.27.0.5 ae0.0 Full 172.27.255.2 128 39
172.27.0.22 ae2.0 Full 172.27.255.5 128 37
TASK 4
Ensure that all OSPF links with the following bandwidth values are
assigned the following OSPF cost values.

– 1 Gbps = 50
– 2 Gbps = 25
– 3 Gbps = 16
Question: Before the completion of this task, what is the cost

value for a 1 Gbps interface?
Answer: A 1 Gbps interface currently has the cost value of 1.
TASK INTERPRETATION
At first, this task might seem complex with the cost, or metric, values that you must apply to
different interfaces. One very time-consuming method to accomplish this task is to configure
each OSPF interface to the specific metric value that the task lists. This method is inferior and
unnecessary. The quick and superior method is to use the reference-bandwidth
command, which automatically calculates interface cost values. To complete this task, use the
reference-bandwidth command with a value of 50g on each router.
Note
Remember to configure OSPFv2 and
OSPFv3 with the correct
reference-bandwidth value.
Forgetting to do so results in two different
routing topologies.
TASK COMPLETION
• R1:
lab@R1# set reference-bandwidth 50g

lab@R1# up 1 set ospf3 reference-bandwidth 50g

lab@R1# commit
commit complete
• R2:


lab@R2# commit
commit complete

• R3:


lab@R3# commit
commit complete
• R4:


lab@R4# commit
commit complete
• R5:


lab@R5# commit
commit complete
TASK VERIFICATION
To verify this task, issue show ospf interface detail and show ospf3 interface
detail commands on each internal router. The output must display the cost values defined by
the task.
• R1:
lab@R1# run show ospf interface detail
ae1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Type: P2P, Address: 172.27.0.10, Mask: 255.255.255.252, MTU: 1500, Cost: 25
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: MD5, Active key ID: 1, Start time: 1970 Jan 1 00:00:00 UTC
Protection type: None
Topology default (ID 0) -> Cost: 25

ge-0/0/6.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Adj count: 1
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
Type: LAN, Address: 172.27.255.1, Mask: 255.255.255.255, MTU: 65535, Cost: 0
Adj count: 0, Passive
Auth type: None
Topology default (ID 0) -> Passive, Cost: 0
ge-0/0/3.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
Adj count: 1
Auth type: None

lab@R1# run show ospf3 interface detail
ae1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Address fe80::5254:ff:fe00:4303, Prefix-length 64
OSPF3-Intf-index 2, Type P2P, MTU 1500, Cost 25
Adj count: 1, Router LSA ID: 0
Hello 10, Dead 40, ReXmit 5, Not Stub
ge-0/0/6.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Address fe80::5668:29ff:fe7a:91f1, Prefix-length 64
ge-0/0/3.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
Address fe80::5668:29ff:fe7a:a8bf, Prefix-length 64
• R2:
ae0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
Adj count: 1
Auth type: None

ge-0/0/1.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
Adj count: 1
Auth type: None
lo0.0 DRother 0.0.0.1 0.0.0.0 0.0.0.0 0
Auth type: None

ae0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
ge-0/0/1.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
Address fe80::5668:29ff:fe7a:a756, Prefix-length 64
• R3:
ge-0/0/1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Adj count: 1
ge-0/0/2.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Adj count: 1
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0

Auth type: None
ge-0/0/3.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
Adj count: 1
Auth type: None

ge-0/0/1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Address fe80::5668:29ff:fe7a:87a9, Prefix-length 64
ge-0/0/2.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Address fe80::5668:29ff:fe7a:9cbd, Prefix-length 64
ge-0/0/3.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
Address fe80::5668:29ff:fe7a:998f, Prefix-length 64
• R4:
ae1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Adj count: 1
ge-0/0/5.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Adj count: 1
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0

Auth type: None
ae0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
Adj count: 1
Auth type: None
ae2.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
Adj count: 1
Auth type: None

ae1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/5.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Address fe80::5668:29ff:fe7a:a9ef, Prefix-length 64
ae0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
ae2.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
• R5:
ae2.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
Adj count: 1

Auth type: None
ge-0/0/1.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
Adj count: 1
Auth type: None
lo0.0 DRother 0.0.0.2 0.0.0.0 0.0.0.0 0
Auth type: None

ae2.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
Address fe80::5254:ff:fe00:1a04, Prefix-length 64
ge-0/0/1.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
Address fe80::5668:29ff:fe7a:8e05, Prefix-length 64
TASK 5
If R4 reboots, configure it to wait 240 seconds after the OSPF
instance has started before passing transit traffic.
Question: Is it necessary to consider OSPFv3 to complete this

task?
Answer: Yes. The Junos OS supports the use of the overload

command with OSPFv2 and OSPFv3.
TASK INTERPRETATION
To complete this task, you must configure R4 to enter the overloaded mode for 240 seconds with
OSPFv2 and OSPFv3 when the router reboots. Use the overload timeout 240 command at
the [edit protocols ospf] and [edit protocols ospf3] hierarchy levels to
accomplish this task.

TASK COMPLETION
• R4:
lab@R4# set overload timeout 240

lab@R4# up 1 set ospf3 overload timeout 240

lab@R4# commit
commit complete
TASK VERIFICATION
To verify this task, examine a prefix from a router that is reachable through R4; this cannot be an
address that resides on R4. Next, you can reboot the router, or bounce the OSPF protocol, and
examine the prefix again. Traffic now avoids R4 for 240 seconds. However, verifying this task by
rebooting R4, or bouncing OSPF, might take more time than it is worth. You can also verify this
task by removing the timeout option and examining prefixes that route through R4.
Note
If you verify this task by removing the
timeout option, be sure to replace it once
you finish your verification.
• R5:
lab@R5# run show route 172.27.255.2

172.27.255.2/32 *[OSPF/10] 00:08:22, metric 41

> to 172.27.0.21 via ae2.0
• R4:
lab@R4# delete overload timeout

lab@R4# up 1 delete ospf3 overload timeout

lab@R4# up 1 show
ospf {
overload;
...
ospf3 {
overload;
...

lab@R4# commit
commit complete
• R5:

172.27.255.2/32 *[OSPF/10] 00:29:23, metric 150

> to 172.27.0.26 via ge-0/0/1.0
• R4:

lab@R4# set overload timeout 240


lab@R4# commit
commit complete
• R5:

172.27.255.2/32 *[OSPF/10] 00:01:09, metric 41

> to 172.27.0.21 via ae2.0
TASK 6
Configure the OSPF adjacencies over the ae0 link to be declared down
if 2 hello packets are missed.

Question: By default, how often does the Junos OS send OSPF
hello packets?
Answer: The Junos OS sends an OSPF hello packet every 10

seconds by default.
TASK INTERPRETATION
By default, the Junos OS declares an OSPF adjacency down if it misses 4 hello packets in a 40
seconds window. To complete this task, you must configure R2 and R4 to declare the adjacency
between them as down if 2 hello packets are missed. To accomplish this criteria, change the
hello-interval to 20 seconds or the dead-interval to 20 seconds.
Note
Notice that the task refers to more than
one OSPF adjacency. Remember to
configure the OSPFv3 adjacency with the
correct hello-interval or
dead-interval setting.
TASK COMPLETION
• R2:
root@R2# set area 1 interface ae0 dead-interval 20

root@R2# up 1 set ospf3 area 1 interface ae0 dead-interval 20

root@R2# commit
commit complete
• R4:
root@R4# set area 1 interface ae0 dead-interval 20

root@R4# up 1 set ospf3 area 1 interface ae0 dead-interval 20

root@R4# commit
commit complete

TASK VERIFICATION
To verify this task, issue the show ospf interface ae0.0 detail | match hello
and show ospf3 interface ae0.0 detail | match hello commands on R2 and
R4. The output displays a hello-interval of 10 seconds and a dead-interval of 20
seconds, if you previously adjusted the dead-interval. If you previously adjusted the
hello-interval, then the hello-interval of 20 seconds and a dead-interval of 40
seconds is shown. Either way the adjacencies will be declared down if 2 hello packets are
missed.
• R2:
root@R2# run show ospf interface ae0.0 detail | match hello

root@R2# run show ospf3 interface ae0.0 detail | match hello
• R4:
root@R4# run show ospf interface ae0.0 detail | match hello

root@R4# run show ospf3 interface ae0.0 detail | match hello
TASK 7
The interface routes for the links between R5 and T2, and R2 and T1
must appear on area 0 routers as internal OSPF routes. No OSPF
adjacencies can form over these links.
Question: Can you use a policy to redistribute these interface

routes into OSPF?
Answer: No. Using a policy to redistribute the interface routes

results in the routes appearing as OSPF external routes. This
violates the criteria of the task.
TASK INTERPRETATION
To complete this task, you must apply the OSPF passive option to R5’s ge-0/0/5 interface and
R2’s ge-0/0/2 interface, which places these interfaces in their respective areas.
As with previous tasks, this task applies to OSPFv2 and OSPFv3. Remember to configure the
passive option for the necessary interfaces within each protocol.
TASK COMPLETION
• R2:

root@R2# set area 1 interface ge-0/0/2 passive

root@R2# up 1 set ospf3 area 1 interface ge-0/0/2 passive

root@R2# commit
commit complete
• R5:
root@R5# set area 2 interface ge-0/0/5 passive

root@R5# up 1 set ospf3 area 2 interface ge-0/0/5 passive

root@R5# commit
commit complete
TASK VERIFICATION
Issue the show ospf interface ge-0/0/2.0 detail and show ospf3 interface
ge-0/0/2.0 detail commands on R2. Then issue the show ospf interface ge-0/
0/5.0 detail and show ospf3 interface ge-0/0/5.0 detail commands on R5.
These commands display the current interface mode, which should be passive.
Examine the routing table of an ABR to determine if the interface routes are now internal OSPF
routes. If the two IPv4 and the two IPv6 routes in question appear in the ABR’s routing table as
internal OSPF routes, this task is complete.
• R2:
root@R2# run show ospf interface ge-0/0/2.0 detail
ge-0/0/2.0 DRother 0.0.0.1 0.0.0.0 0.0.0.0 0
Auth type: None

root@R2# run show ospf3 interface ge-0/0/2.0 detail
ge-0/0/2.0 DRother 0.0.0.1 0.0.0.0 0.0.0.0 0
Address fe80::5668:29ff:fe7a:8777, Prefix-length 64
OSPF3-Intf-index 3, Type LAN, MTU 1500, Cost 50
Adj count: 0, Router LSA ID: -, Passive
• R5:
root@R5# run show ospf interface ge-0/0/5.0 detail
ge-0/0/5.0 DRother 0.0.0.2 0.0.0.0 0.0.0.0 0
Auth type: None

root@R5# run show ospf3 interface ge-0/0/5.0 detail
ge-0/0/5.0 DRother 0.0.0.2 0.0.0.0 0.0.0.0 0
Address fe80::5668:29ff:fe7a:a645, Prefix-length 64
OSPF3-Intf-index 3, Type LAN, MTU 1500, Cost 50
Adj count: 0, Router LSA ID: -, Passive
• R1:
root@R1# run show route 172.27.0.56/30

172.27.0.56/30 *[OSPF/10] 00:10:16, metric 100

> to 172.27.0.9 via ae1.0

root@R1# run show route 172.27.0.36/30

172.27.0.36/30 *[OSPF/10] 00:11:40, metric 100

> to 172.27.0.2 via ge-0/0/3.0

root@R1# run show route 2008:4498::38/126

2008:4498::38/126 *[OSPF3/10] 00:11:10, metric 100

> to fe80::5254:ff:fe00:dc03 via ae1.0

root@R1# run show route 2008:4498::24/126

2008:4498::24/126 *[OSPF3/10] 00:11:57, metric 100

> to fe80::5668:29ff:fe7a:b232 via ge-0/0/3.0
TASK 8
Configure R1 to exchange RIP routes with C1. Create the most
specific summary route possible that represents these routes and
redistribute the summary route into OSPF. This summary route must
be present on R2.
Question: Does Area 2 currently allow the presence of Type 5

LSAs?
Answer: Yes. Area 2 currently allows Type 5 LSAs.
TASK INTERPRETATION
To complete this task, configure the RIP protocol on R1 to exchange RIP routes with C1. When
R1 receives the RIP routes, create an aggregate route that represents these routes, and
redistribute that aggregate route into OSPF.
The key requirement of this task is to have this summary route appear on R2. Currently, Area 1
is not an OSPF stub area and Type 5 LSAs are accepted; the summary route from R1 is present
on R2 without further intervention. This part of the task might seem simple, but keep in mind for
later tasks that because of this task, Area 1 must not restrict Type 5 LSAs.
TASK COMPLETION
• R1:
lab@R1# up 1 edit rip group rip
[edit protocols rip group rip]


lab@R1# commit
commit complete

lab@R1# run show route protocol rip

172.16.16.0/29 *[RIP/100] 00:00:04, metric 2, tag 0

> to 172.27.0.30 via ge-0/0/1.0
172.16.20.0/24 *[RIP/100] 00:00:04, metric 2, tag 0
> to 172.27.0.30 via ge-0/0/1.0

172.16.21.0/24 *[RIP/100] 00:00:04, metric 2, tag 0
> to 172.27.0.30 via ge-0/0/1.0
224.0.0.9/32 *[RIP/100] 00:00:04, metric 1
MultiRecv


lab@R1# top edit policy-options policy-statement rip-ospf term agg
[edit policy-options policy-statement rip-ospf term agg]





lab@R1# set export rip-ospf

lab@R1# commit
commit complete
TASK VERIFICATION
To verify this task examine R2’s routing table for the external OSPF route that represents the RIP
routes.
• R2:

172.16.16.0/21 *[OSPF/150] 00:02:34, metric 0, tag 0

> to 172.27.0.1 via ge-0/0/1.0
TASK 9
Configure R3 and R5 to receive RIP routes from DC3. All other
routers in your OSPF domain must be able to reach these
destinations. However, the primary path to these destinations must
lead through R3. Even R5 must use R3 as the primary path for these
destinations.

TASK INTERPRETATION
To attempt this task, you must recall that in the fourth task you changed the metrics that are
associated with the links based on their bandwidth. Because of this change, the preferred path
to DC3 will always be through R5. The task stipulates that all routers must reach these
destinations, but it does not stipulate how you must redistribute the routing information. To
meet these criteria, configure an aggregate route on R5 that represents the RIP routes it is
receiving and redistribute the aggregate route into OSPF. Then, on R3, redistribute the RIP
routes directly into OSPF. This causes all other routers to have specific routing information that
leads through R3 to reach DC3, and then they also have less specific routing information that
leads through R5.
Alternatively, you can redistribute the routes using a Type 1 metric on R3. By default, R5 uses a
Type 2 metric when redistributing routes, which is always less preferred than routes with a Type
1 metric.
To complete this task, you must configure R5 to use R3 to reach the destinations DC3 is
advertising. This part of the task requires you to adjust route protocol preference. You can adjust
OSPF external route preference or RIP route preference on R5, however, we recommend you
adjust the RIP route preference instead of the OSPF external route preference. Adjusting the
OSPF external route preference might have adverse effects elsewhere that are nearly impossible
to foresee at this point.
TASK COMPLETION
• R3:


lab@R3# commit
commit complete


10.22.1.0/24 *[RIP/100] 00:01:34, metric 2, tag 0

> to 172.27.0.101 via ge-0/0/4.0
10.22.2.0/24 *[RIP/100] 00:01:34, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/4.0
10.22.3.0/24 *[RIP/100] 00:01:34, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/4.0
10.22.4.0/24 *[RIP/100] 00:01:34, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/4.0
10.22.5.0/24 *[RIP/100] 00:01:34, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/4.0
10.22.6.0/24 *[RIP/100] 00:01:34, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/4.0

10.22.7.0/24 *[RIP/100] 00:01:34, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/4.0
224.0.0.9/32 *[RIP/100] 00:01:34, metric 1
MultiRecv

lab@R3# top edit policy-options policy-statement rip-ospf term rip
[edit policy-options policy-statement rip-ospf term rip]

lab@R3# set from protocol rip

lab@R3# set from route-filter 10.22/21 orlonger




lab@R3# up 1 show
ospf {
export rip-ospf;
reference-bandwidth 50g;
area 0.0.0.0 {
interface-type p2p;
authentication {
md5 1 key "$9$FPHM6CpIEyWLN0BLNdboaFn/AOIXxdsYoevaU"; ## SECRET-DATA
}
}
interface-type p2p;
authentication {
md5 1 key "$9$tui801ElK8db2cyb24aiHtuOISlws4ZGixNHm"; ## SECRET-DATA
}
}
interface lo0.0 {
passive;
}
}
area 0.0.0.2 {
interface-type p2p;
}
}
}
ospf3 {

area 0.0.0.0 {
interface-type p2p;
}
interface-type p2p;
}
}
area 0.0.0.2 {
interface-type p2p;
}
}
}
rip {
group rip {
}
}

lab@R3# commit
commit complete
• R5:


lab@R5# commit
commit complete


10.22.1.0/24 *[RIP/100] 00:00:10, metric 2, tag 0

> to 172.27.0.101 via ge-0/0/9.0
10.22.2.0/24 *[RIP/100] 00:00:10, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/9.0
10.22.3.0/24 *[RIP/100] 00:00:10, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/9.0
10.22.4.0/24 *[RIP/100] 00:00:10, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/9.0
10.22.5.0/24 *[RIP/100] 00:00:10, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/9.0

10.22.6.0/24 *[RIP/100] 00:00:10, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/9.0
10.22.7.0/24 *[RIP/100] 00:00:10, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/9.0
224.0.0.9/32 *[RIP/100] 00:00:10, metric 1
MultiRecv

lab@R5# set preference 155


lab@R5# top edit policy-options policy-statement rip-ospf term agg






lab@R5# up 1 show
ospf {
export rip-ospf;
area 0.0.0.2 {
interface-type p2p;
}
interface lo0.0 {
passive;
}
interface ae2.0 {
interface-type p2p;
}
passive;
}
}
}
ospf3 {

area 0.0.0.2 {
interface-type p2p;
}
interface ae2.0 {
interface-type p2p;
}
passive;
}
}
}
rip {
group rip {
preference 155;
}
}

lab@R5# commit
commit complete
TASK VERIFICATION
To verify this task, issue the show route 10.22/21 command on R1, R4, and R5. Each
router must have specific routing information that points towards R3 for the RIP routes
advertised by DC3. Then, the routers must have a less specific 10.22.0.0/21 route that points
towards R5. Then, R5 must prefer the external OSPF routes over its locally received RIP routes
for this prefix. Once you verify these criteria, you can consider the task complete.
• R1:

10.22.0.0/21 *[OSPF/150] 00:47:30, metric 0, tag 0

> to 172.27.0.9 via ae1.0
10.22.1.0/24 *[OSPF/150] 00:47:30, metric 2, tag 0
> to 172.27.0.13 via ge-0/0/6.0
10.22.2.0/24 *[OSPF/150] 00:47:30, metric 2, tag 0
> to 172.27.0.13 via ge-0/0/6.0
10.22.3.0/24 *[OSPF/150] 00:47:30, metric 2, tag 0
> to 172.27.0.13 via ge-0/0/6.0
10.22.4.0/24 *[OSPF/150] 00:47:30, metric 2, tag 0
> to 172.27.0.13 via ge-0/0/6.0
10.22.5.0/24 *[OSPF/150] 00:47:30, metric 2, tag 0
> to 172.27.0.13 via ge-0/0/6.0
10.22.6.0/24 *[OSPF/150] 00:47:30, metric 2, tag 0
> to 172.27.0.13 via ge-0/0/6.0
10.22.7.0/24 *[OSPF/150] 00:47:30, metric 2, tag 0
> to 172.27.0.13 via ge-0/0/6.0

• R4:

10.22.0.0/21 *[OSPF/150] 00:47:47, metric 0, tag 0

> to 172.27.0.22 via ae2.0
10.22.1.0/24 *[OSPF/150] 00:47:47, metric 2, tag 0
> to 172.27.0.17 via ge-0/0/5.0
10.22.2.0/24 *[OSPF/150] 00:47:47, metric 2, tag 0
> to 172.27.0.17 via ge-0/0/5.0
10.22.3.0/24 *[OSPF/150] 00:47:47, metric 2, tag 0
> to 172.27.0.17 via ge-0/0/5.0
10.22.4.0/24 *[OSPF/150] 00:47:47, metric 2, tag 0
> to 172.27.0.17 via ge-0/0/5.0
10.22.5.0/24 *[OSPF/150] 00:47:47, metric 2, tag 0
> to 172.27.0.17 via ge-0/0/5.0
10.22.6.0/24 *[OSPF/150] 00:47:47, metric 2, tag 0
> to 172.27.0.17 via ge-0/0/5.0
10.22.7.0/24 *[OSPF/150] 00:47:47, metric 2, tag 0
> to 172.27.0.17 via ge-0/0/5.0
• R5:

10.22.0.0/21 *[Aggregate/130] 00:47:58

Reject
10.22.1.0/24 *[OSPF/150] 00:47:58, metric 2, tag 0
> to 172.27.0.26 via ge-0/0/1.0
[RIP/155] 00:52:09, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/9.0
10.22.2.0/24 *[OSPF/150] 00:47:58, metric 2, tag 0
> to 172.27.0.26 via ge-0/0/1.0
[RIP/155] 00:52:09, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/9.0
10.22.3.0/24 *[OSPF/150] 00:47:58, metric 2, tag 0
> to 172.27.0.26 via ge-0/0/1.0
[RIP/155] 00:52:09, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/9.0
10.22.4.0/24 *[OSPF/150] 00:47:58, metric 2, tag 0
> to 172.27.0.26 via ge-0/0/1.0
[RIP/155] 00:52:09, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/9.0
10.22.5.0/24 *[OSPF/150] 00:47:58, metric 2, tag 0
> to 172.27.0.26 via ge-0/0/1.0
[RIP/155] 00:52:09, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/9.0

10.22.6.0/24 *[OSPF/150] 00:47:58, metric 2, tag 0
> to 172.27.0.26 via ge-0/0/1.0
[RIP/155] 00:52:09, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/9.0
10.22.7.0/24 *[OSPF/150] 00:47:58, metric 2, tag 0
> to 172.27.0.26 via ge-0/0/1.0
[RIP/155] 00:52:09, metric 2, tag 0
> to 172.27.0.101 via ge-0/0/9.0
TASK 10
No type 5 or type 3 LSAs are allowed in area 2. R5 must use R3 to
reach unknown destinations. R5 must use R4 to reach unknown
destinations only if the link between R5 and R3 fails. Configure R3
to attach a metric of 10 and R4 to attach a metric of 5 to their
respective default routes they inject into area 2.
Question: What OSPF command tells the router to restrict Type

3 LSAs from entering an area?
Answer: The no-summaries command tells the router to

restrict Type 3 LSAs from entering an OSPF area.
TASK INTERPRETATION
Restricting LSA flooding is a function of OSPF stub areas. A totally-stubby area restricts the
flooding of Type 5 and Type 3 LSAs into the area, however the ABR injects a default route as a
Type 3 LSA. To accomplish this task, you must configure Area 2 as a not-so-stubby totally-stubby
area. This results in both ABRs injecting default routes into the area as Type 7 LSAs.
You must configure the R3 to inject its default routes, one for IPv4 and one for IPv6, with a
metric value of 10. Then, configure R4 to inject its default routes, one for IPv4 and one for IPv6,
with a metric value of 5. This action creates a problem when attempting to ensure R5 uses R3 to
reach unknown destinations. To overcome this restriction, configure R3 to attach a metric type
value of 1 to its default routes, then configure R4 to attach a metric type value of 2 to its default
routes.
Note
As with previous tasks, remember about
OSPFv3. You must configure both protocols
for this task.
TASK COMPLETION
• R3:
lab@R3# set area 2 nssa default-lsa default-metric 10

lab@R3# set area 2 nssa default-lsa type-7

lab@R3# set area 2 nssa default-lsa metric-type 1


lab@R3# set area 2 nssa no-summaries






lab@R3# commit
commit complete
• R4:









lab@R4# commit

commit complete
• R5:
lab@R5# set area 2 nssa

lab@R5# up 1 set ospf3 area 2 nssa

lab@R5# commit
commit complete
TASK VERIFICATION
To verify this task, examine the OSPF database and routing table on R5. The OSPF database
must not contain any Type 3 or Type 5 LSAs. The routing table must direct traffic to R3 to reach
unknown destinations.
• R5:
lab@R5# run show ospf database
OSPF database, Area 0.0.0.2

Type ID Adv Rtr Seq Age Opt Cksum Len
Router 172.27.255.3 172.27.255.3 0x8000000b 48 0x20 0x266e 48
Router 172.27.255.4 172.27.255.4 0x8000000f 814 0x20 0xba0f 48
Router *172.27.255.5 172.27.255.5 0x8000000c 391 0x20 0x5a4a 96
NSSA 0.0.0.0 172.27.255.3 0x80000002 1350 0x20 0xe478 36
NSSA 0.0.0.0 172.27.255.4 0x80000004 814 0x20 0x2cb2 36
NSSA *10.22.0.0 172.27.255.5 0x80000002 2906 0x28 0xc72f 36
NSSA 10.22.1.0 172.27.255.3 0x80000004 2266 0x20 0x7d44 36
NSSA 10.22.2.0 172.27.255.3 0x80000004 2135 0x20 0x724e 36
NSSA 10.22.3.0 172.27.255.3 0x80000004 2003 0x20 0x6758 36
NSSA 10.22.4.0 172.27.255.3 0x80000004 1872 0x20 0x5c62 36
NSSA 10.22.5.0 172.27.255.3 0x80000004 1742 0x20 0x516c 36
NSSA 10.22.6.0 172.27.255.3 0x80000004 1611 0x20 0x4676 36
NSSA 10.22.7.0 172.27.255.3 0x80000004 1481 0x20 0x3b80 36

lab@R5# run show ospf3 database
OSPF3 database, Area 0.0.0.2

Type ID Adv Rtr Seq Age Cksum Len
Router 0.0.0.0 172.27.255.3 0x80000005 717 0xcd58 40
Router 0.0.0.0 172.27.255.4 0x80000009 816 0xf640 40
Router *0.0.0.0 172.27.255.5 0x80000006 1653 0x8e9c 56
NSSA 0.0.0.1 172.27.255.3 0x80000002 217 0xa2c1 28
NSSA 0.0.0.1 172.27.255.4 0x80000002 514 0x8ad9 28
IntraArPfx 0.0.0.1 172.27.255.3 0x80000005 467 0xd0d2 52
IntraArPfx 0.0.0.1 172.27.255.4 0x80000008 816 0x6458 52
IntraArPfx *0.0.0.1 172.27.255.5 0x80000004 1063 0x38ac 92

OSPF3 Link-Local database, interface ae2.0 Area 0.0.0.2

Link 0.0.0.4 172.27.255.4 0x80000003 1238 0xa459 64
Link *0.0.0.3 172.27.255.5 0x80000002 2277 0xf1c1 64
OSPF3 Link-Local database, interface ge-0/0/1.0 Area 0.0.0.2

Link 0.0.0.3 172.27.255.3 0x80000003 1472 0xffdf 64
Link *0.0.0.1 172.27.255.5 0x80000003 468 0x2124 64

lab@R5# run show route 0/0 exact

0.0.0.0/0 *[OSPF/150] 00:13:47, metric 60, tag 0

> to 172.27.0.26 via ge-0/0/1.0

lab@R5# run show route ::/0 exact

::/0 *[OSPF3/150] 00:47:14, metric 60, tag 0

> to fe80::5668:29ff:fe7a:9ac9 via ge-0/0/1.0
TASK 11
Redistribute the interface route for the link between R5 and DC3
into OSPF as an external OSPF route. This route must be present in
area 1 as an external LSA but cannot be present in R2’s routing
table. The [edit routing-options] hierarchy level on R2 cannot be
altered to accomplish this task.
Question: Can you introduce the interface route into your OSPF
domain through the use of the passive option?
Answer: No. Using the passive option causes the route to

appear as an internal OSPF route. The route must appear as an
external OSPF route to meet the criteria of this task.
TASK INTERPRETATION
To complete this task, you must first configure a policy on R5 that exports the 172.27.0.96/28
prefix into OSPF. Then the other routers in your OSPF domain distribute this route as a Type 5
LSA. This Type 5 LSA is now present on R2 and you must configure an import policy that blocks
this route from being installed into R2’s routing table.

TASK COMPLETION
• R5:
lab@R5# top edit policy-options policy-statement interface-routes term DC3
[edit policy-options policy-statement interface-routes term DC3]

lab@R5# set from protocol direct




lab@R5# set export interface-routes

lab@R5# commit
commit complete
• R2:
lab@R2# top edit policy-options policy-statement ospf-import term DC3
[edit policy-options policy-statement ospf-import term DC3]

lab@R2# set from protocol ospf




lab@R2# set import ospf-import

lab@R2# commit
commit complete

TASK VERIFICATION
To verify this task examine the link state database on R2 for the presence of the external LSA
that represents the 172.27.0.96/28 prefix. Then issue the show route 172.27.0.96/28
command on R2. The external LSA in question should be present in the database and the prefix
must not be present in the routing table.
• R2:
lab@R2# run show ospf database external
OSPF AS SCOPE link state database
Extern 10.22.0.0 172.27.255.4 0x80000019 17 0x22 0x16d2 36
Extern 10.22.1.0 172.27.255.3 0x8000001d 648 0x22 0x495f 36
Extern 10.22.2.0 172.27.255.3 0x8000001c 1691 0x22 0x4068 36
Extern 10.22.3.0 172.27.255.3 0x8000001c 1562 0x22 0x3572 36
Extern 10.22.4.0 172.27.255.3 0x8000001c 1430 0x22 0x2a7c 36
Extern 10.22.5.0 172.27.255.3 0x8000001c 1300 0x22 0x1f86 36
Extern 10.22.6.0 172.27.255.3 0x8000001c 909 0x22 0x1490 36
Extern 10.22.7.0 172.27.255.3 0x8000001c 778 0x22 0x99a 36
Extern 172.16.16.0 172.27.255.1 0x80000020 1128 0x22 0x788c 36
Extern 172.27.0.96 172.27.255.4 0x80000001 115 0x22 0xcc34 36

lab@R2# run show route 172.27.0.96/28

lab@R2#
TASK 12
Redistribute the static routes found on R5 into OSPF. These specific
routes must be present in area 2 but cannot be present in area 1.
However, R2 must be able to reach these destinations.
TASK INTERPRETATION
To complete this task, you must first redistribute the static routes found on R5 into OSPF. Then
on the ABRs, R3 and R4, summarize the routes into Area 0 from Area 2 using the area-range
command. Note that these routes are Type 7 LSAs and you must configure the area-range
command under the [edit protocols ospf area 0.0.0.2 nssa] hierarchy level.
TASK COMPLETION
• R5:
lab@R5# top edit policy-options policy-statement stat-ospf term statics
[edit policy-options policy-statement stat-ospf term statics]


lab@R5# set from route-filter 10.255/19 orlonger



lab@R5# set export stat-ospf

lab@R5# commit
commit complete
• R3:
lab@R3# up 1 edit ospf area 2
[edit protocols ospf area 0.0.0.2]

lab@R3# set nssa area-range 10.255/19

lab@R3# commit
commit complete
• R4:

lab@R4# set nssa area-range 10.255/19

lab@R4# commit
commit complete
TASK VERIFICATION
To verify this task, examine the routing table on R3 and R4. You must see the specific OSPF
external routes that represent the static routes that R5 redistributed into OSPF earlier. Then,
examine the routing table on R2—it must contain the summary route which represents the
specific OSPF external routes. This task is complete if R2 only has the summary route and lacks
the specific OSPF external routes.
• R3:

10.255.0.0/19 *[OSPF/150] 00:15:08, metric 1, tag 0

> to 172.27.0.18 via ge-0/0/2.0
10.255.3.0/24 *[OSPF/150] 00:19:32, metric 0, tag 0
> to 172.27.0.25 via ge-0/0/3.0
10.255.4.0/28 *[OSPF/150] 00:19:32, metric 0, tag 0
> to 172.27.0.25 via ge-0/0/3.0
10.255.5.0/28 *[OSPF/150] 00:19:32, metric 0, tag 0
> to 172.27.0.25 via ge-0/0/3.0
10.255.6.0/28 *[OSPF/150] 00:19:32, metric 0, tag 0
> to 172.27.0.25 via ge-0/0/3.0
10.255.7.0/28 *[OSPF/150] 00:19:32, metric 0, tag 0
> to 172.27.0.25 via ge-0/0/3.0
10.255.8.0/25 *[OSPF/150] 00:19:32, metric 0, tag 0
> to 172.27.0.25 via ge-0/0/3.0
10.255.9.0/29 *[OSPF/150] 00:19:32, metric 0, tag 0
> to 172.27.0.25 via ge-0/0/3.0
10.255.10.0/26 *[OSPF/150] 00:19:32, metric 0, tag 0
> to 172.27.0.25 via ge-0/0/3.0
10.255.11.0/27 *[OSPF/150] 00:19:32, metric 0, tag 0
> to 172.27.0.25 via ge-0/0/3.0
10.255.17.0/25 *[OSPF/150] 00:19:32, metric 0, tag 0
> to 172.27.0.25 via ge-0/0/3.0
• R4:

10.255.0.0/19 *[OSPF/150] 00:16:00, metric 16777215, tag 0

Discard
10.255.3.0/24 *[OSPF/150] 00:20:25, metric 0, tag 0
> to 172.27.0.22 via ae2.0
10.255.4.0/28 *[OSPF/150] 00:20:25, metric 0, tag 0
> to 172.27.0.22 via ae2.0
10.255.5.0/28 *[OSPF/150] 00:20:25, metric 0, tag 0
> to 172.27.0.22 via ae2.0
10.255.6.0/28 *[OSPF/150] 00:20:25, metric 0, tag 0
> to 172.27.0.22 via ae2.0
10.255.7.0/28 *[OSPF/150] 00:20:25, metric 0, tag 0
> to 172.27.0.22 via ae2.0
10.255.8.0/25 *[OSPF/150] 00:20:25, metric 0, tag 0
> to 172.27.0.22 via ae2.0
10.255.9.0/29 *[OSPF/150] 00:20:25, metric 0, tag 0
> to 172.27.0.22 via ae2.0
10.255.10.0/26 *[OSPF/150] 00:20:25, metric 0, tag 0
> to 172.27.0.22 via ae2.0
10.255.11.0/27 *[OSPF/150] 00:20:25, metric 0, tag 0
> to 172.27.0.22 via ae2.0
10.255.17.0/25 *[OSPF/150] 00:20:25, metric 0, tag 0
> to 172.27.0.22 via ae2.0

• R2:

10.255.0.0/19 *[OSPF/150] 00:00:13, metric 1, tag 0

> to 172.27.0.6 via ae0.0


Lab
IS-IS Troubleshooting
Overview
In this lab, you will be given a list of tasks specific to IS-IS troubleshooting to accomplish in a
The lab is available in two formats. In the high-level format, you are given only the list of tasks to
be accomplished. To better prepare you for the real JNCIE exam, we recommend that you make
your best effort at accomplishing the tasks with only the high-level lab guide.
The lab is also available in a detailed format. The detailed format contains a discussion
regarding the interpretation of each task, followed by step-by-step instructions. You might find
more than one method for accomplishing each task.
– Ensure that all IS-IS adjacencies have reached the Up state. Any adjacencies
that require authentication must authenticate properly.
– Ensure that all routers have IPv4 and IPv6 IS-IS routes present in their routing
tables.
– Ensure that the loss of any interface on a router cannot remove a router from
the IS-IS topology.
– To reduce the size of the IS-IS link-state database ensure that the interface
routes of all core facing interfaces are not present in the database. However,
you must ensure that all routers can ping each other’s loopback addresses.
– R4 is using the ae1 link to send traffic to the loopback address of R1. Ensure
that this traffic uses the ae0 link if the ae1 link fails.
– Ensure that R5 can communicate with the destinations advertised by the
customer router attached to R1. Also, ensure that R5 is receiving this routing
information from R3 and R4. You can verify this step by pinging the 172.16.16.1
address.
www.juniper.net IS-IS Troubleshooting • Lab 4–1

Troubleshooting IS-IS
In this lab part, you will examine and troubleshoot a malfunctioning network which has
incorporated IS-IS as its IGP. You are given a list of criteria that your network must meet to
consider this lab part complete.
TASK 1
Access the CLI for your routers using either the console, Telnet, or SSH as directed by your
instructor. Refer to the management network diagram for the IP address associated with your
devices. Log in as user lab with the password lab123.
Ensure that all IS-IS adjacencies have reached the Up state. Any
adjacencies that require authentication must authenticate properly.
TASK INTERPRETATION
When you examine your network you will find many problems that affect the IS-IS adjacency
formations. You must examine each router and fix any problems that are restricting the
adjacencies from reaching the Up state.
TASK COMPLETION
You must now examine the network for malfunctioning IS-IS adjacencies. A good place to start is
to issue the show isis adjacencies command on each router. You will notice that no
adjacencies have formed on any of the routers. This malady can be caused by many different
issues and so it is best to examine the interfaces on the routers using the show isis
interface and show interface terse | match down commands.
• R1:
R1 (ttyd0)
login: lab
Password:

lab@R1> configure
[edit]
[edit]
lab@R1# run show isis interface
Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric
ae1.0 1 0x1 R1.00 Disabled 15/15
ge-0/0/3.0 1 0x1 R1.00 Disabled 30/30
ge-0/0/6.0 0 0x1 Disabled Disabled 30/30
lo0.0 0 0x1 Passive Passive 0/0
[edit]
lab@R1# run show interfaces terse | match down
ae0 up down
vlan up down
Lab 4–2 • IS-IS Troubleshooting www.juniper.net

• R2:
R2 (ttyd0)
login: lab
Password:

lab@R2> configure
[edit]
[edit]
ae0.0 1 0x1 Down Disabled 10/10
ge-0/0/2.0 0 0x1 Passive Passive 10/10
[edit]
ge-0/0/7 down up
ge-0/0/7.0 up down aenet --> ae0.0
ae0 up down
ae0.0 up down inet 172.27.0.5/30
vlan up down
• R3:
R3 (ttyd0)
login: lab
Password:

lab@R3> configure
[edit]
[edit]
ge-0/0/3.0 2 0x1 Disabled Point to Point 1/1
lo0.0 0 0x1 Disabled Passive 0/0
[edit]
vlan up down

• R4:
R4 (ttyd0)
login: lab
Password:

lab@R4> configure
[edit]
[edit]
ae0.0 1 0x2 Down Disabled 10/10
[edit]
ae0 up down
ae0.0 up down inet 172.27.0.6/30
vlan up down
• R5:
R5 (ttyd0)
login: lab
Password:

lab@R5> configure
[edit]
[edit]
ae2.0 2 0x1 Disabled R5.00 99/99
ge-0/0/1.0 2 0x1 Disabled R5.00 199/199

[edit]
ae0 up down
ae1 up down
vlan up down
Question: What do these outputs reveal for each router?
Answer: The outputs on R1 show that interfaces ae1 and ge-0/

0/3 are configured for the correct level, however interface ge-0/
0/6 is disabled for Level 1 operations. It also shows that all
required interfaces are up and operational.

The outputs on R2 show that the ae0 interface is down, the
ge-0/0/2 interface is in the passive mode (as it should be), and
the ge-0/0/1 interface is not participating in IS-IS. It also shows
that the ae0 interface and its member interface ge-0/0/7 is in
the link down state.

The outputs on R3 show that the ge-0/0/1 and ge-0/0/2
interfaces are not participating in IS-IS. The ge-0/0/3 interface
is present and is configured in point-to-point mode. It also
shows that all required interfaces are up and operational.

The outputs on R4 show that the ae0 interface is down, the ae1
and ae2 interfaces are not participating in IS-IS. It also shows
that ae0 interface is in the link down state. However, none of
ae0’s member interfaces are listed as down.

The outputs on R5 show that all the required interfaces are
participating in the correct level and mode. All required
interfaces are up and operational. However, no IS-IS
adjacencies have formed with R3 or R4.
To rectify the current issues seen on R1, you must take the ge-0/0/6 interface out of the IS-IS
disabled state. Simply removing the interface under IS-IS accomplishes this task because the
interface all statement has previously been configured.

From the outputs on R2, you can see that the ae0 interface is down because the ge-0/0/7
interface is down; the minimum-links statement on ae0 specifies that all three member links
must be operational for the ae0 interface to be operational. Remove the disable statement on
ge-0/0/7 interface to make the ae0 interface operational. The missing ge-0/0/1 interface
requires further investigation. If you issue the show interface terse ge-0/0/1
command on R2 you can see that the family iso statement was excluded from the interface.
Add the family iso statement to the ge-0/0/1 interface to have it begin participating in IS-IS.
You can examine the issues on R3 further by issuing the show interface terse ge*
command. You can see that the protocol family ISO has be excluded from the ge-0/0/1 and
ge-0/0/2 interfaces. Add the family iso statement to those interfaces to have them begin
participating in IS-IS. Notice that the ge-0/0/3 interface is configured in point-to-point mode.
There is no restriction about the current interface modes but the other routers do not have their
interfaces running in this mode. You must either change all other connecting routers’ interfaces
to point-to-point mode, or you can remove the point-to-point statement on R3’s interfaces.
Examining the IS-IS configuration on R4 shows that the ae1 interface is not configured for Level
1 or Level 2. You must configure the interface under the IS-IS protocol, however simple hello
authentication is required. To determine the authentication key, you must monitor R4’s ae1
interface with the monitor traffic interface ae1.0 detail command. Once you
discover the authentication key, configure ae1 on R4 to participate in IS-IS with the correct
authentication. Also, R4’s ge-0/0/5 and ae2 interfaces are missing the protocol family ISO from
their respective units.
Then, examine the changes to the IS-IS adjacencies on all routers.
• R1:
[edit]
lab@R1# edit protocols isis

lab@R1# show | find ge-0/0/6
level 1 disable;
}
interface ae1.0 {
level 1 {
hello-authentication-key "$9$nr9B9t0vMLN-bZUqP5F6/eKMW7d"; ## SECRET-DATA
hello-authentication-type simple;
}
}
interface all {
level 1 {
hello-authentication-key "$9$gRaGjmfzCtOHqtO1RlegoJ"; ## SECRET-DATA
hold-time 6;
}
}

lab@R1# delete interface ge-0/0/6

lab@R1# commit

commit complete

ae1.0 1 0x1 R1.00 Disabled 15/15
ge-0/0/3.0 1 0x1 R1.00 Disabled 30/30
ge-0/0/6.0 1 0x1 R1.00 Disabled 30/30
• R2:
[edit]
[edit interfaces]
lab@R2# show ge-0/0/7
disable;
gigether-options {
802.3ad ae0;
}
[edit interfaces]
[edit interfaces]
lab@R2# show ge-0/0/1
description "Connection to R1";
unit 0 {
family inet {
address 172.27.0.2/30;
}
family inet6 {
address 2008:4498::2/126;
}
}
[edit interfaces]
[edit interfaces]
lab@R2# commit
commit complete
[edit interfaces]
lab@R2# run show interfaces terse ge-0/0/1

ge-0/0/1 up up
ge-0/0/1.0 up up inet 172.27.0.2/30
iso
inet6 2008:4498::2/126
fe80::5668:29ff:fe7a:ab5b/64
[edit interfaces]
ae0.0 1 0x1 R2.00 Disabled 3/3
ge-0/0/1.0 1 0x2 R2.00 Disabled 10/10
• R3:
[edit]
lab@R3# run show interfaces terse ge*
ge-0/0/0 up up
ge-0/0/0.0 up up inet 10.94.170.10/20
ge-0/0/1 up up
ge-0/0/1.0 up up inet 172.27.0.13/30
inet6 2008:4489::d/126
fe80::5668:29ff:fe7a:93b2/64
ge-0/0/2 up up
ge-0/0/2.0 up up inet 172.27.0.17/30
inet6 2008:4489::13/126
fe80::5668:29ff:fe7a:b48b/64
ge-0/0/3 up up
ge-0/0/3.0 up up inet 172.27.0.26/30
iso
inet6 2008:4489::1a/126
fe80::5668:29ff:fe7a:9ac9/64
ge-0/0/4 up up
ge-0/0/4.0 up up inet 172.27.0.103/28
ge-0/0/5 up up
ge-0/0/5.0 up up inet 138.1.2.4/24
[edit]
[edit interfaces]
[edit interfaces]
[edit interfaces]

lab@R3# show | find interface
point-to-point;
level 2 disable;
level 1 {
hello-authentication-key "$9$--bY4UjqQF/aZF/CtIR-Vw"; ## SECRET-DATA
hold-time 6;
}
}
point-to-point;
}
level 1 disable;
level 2 {
hello-authentication-key "$9$ITDhyeLxdgoGvWoGDif5IEc"; ## SECRET-DATA
}
}
point-to-point;
}
level 1 disable;
level 2 {
hello-authentication-key "$9$cptrKWNdsJGiLxGik.zFcyl"; ## SECRET-DATA
}
}
interface lo0.0 {
level 1 disable;
}

lab@R3# delete interface ge-0/0/1 point-to-point



lab@R3# commit
commit complete


ge-0/0/1.0 1 0x2 R3.02 Disabled 1/1
ge-0/0/2.0 2 0x1 Disabled R3.00 1/1
ge-0/0/3.0 2 0x1 Disabled R5.02 1/1
• R4:
[edit]
lab@R4# run monitor traffic interface ae1.0 detail no-resolve
Address resolution is OFF.
Listening on ae1.0, capture size 1514 bytes
23:42:08.078966 In IS-IS, length 49

L1 Lan IIH, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0)
source-id: 0172.0027.2551, holding time: 27s, Flags: [Level 1 only]
lan-id: 0172.0027.2551.00, Priority: 64, PDU length: 49
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: 9
simple text password: JNCIE-SP
^C
1 packets received by filter
0 packets dropped by kernel
[edit]



lab@R4# set interface ae1 level 1 hello-authentication-key JNCIE-SP

lab@R4# run show interfaces terse ge-0/0/5
ge-0/0/5 up up
ge-0/0/5.0 up up inet 172.27.0.18/30
inet6 2008:4489::12/126
fe80::5668:29ff:fe7a:8591/64

lab@R4# run show interfaces terse ae2
ae2 up up
ae2.0 up up inet 172.27.0.21/30
inet6 2008:4489::15/126
fe80::5254:ff:fe01:4/64

lab@R4# top set interfaces ge-0/0/5.0 family iso

lab@R4# top set interfaces ae2.0 family iso

lab@R4# commit
commit complete

ae0.0 1 0x1 R4.00 Disabled 10/10
ae1.0 1 0x1 R4.00 Disabled 15/15
ae2.0 2 0x2 Disabled R4.02 15/15
ge-0/0/5.0 2 0x1 Disabled R3.02 30/30
• R1:
ge-0/0/6.0 0172.0027.2553 1 Up 1 56:68:29:7a:93:b2
• R2:
[edit interfaces]
• R3:
ge-0/0/1.0 0172.0027.2551! 1 Up 4 56:68:29:7a:8e:3a
ge-0/0/2.0 R4 2 Up 22 56:68:29:7a:85:91
ge-0/0/3.0 R5 2 Up 8 56:68:29:7a:b2:4d
• R4:
ae2.0 R5 2 Up 18 52:54:0:0:4b:4
ge-0/0/5.0 R3 2 Up 7 56:68:29:7a:b4:8b
• R5:
[edit]

ae2.0 R4 2 Up 8 52:54:0:1:0:4
ge-0/0/1.0 R3 2 Up 21 56:68:29:7a:9a:c9
Question: Did any adjacency states change? What differences

do you see on each router.
Answer: R1 has an adjacency with R3, but it is still missing

adjacencies with R2 and R4. R2 still has not formed any
adjacencies. R3 and R4 have formed adjacencies with each
other and with R5.
It still appears that most routers have some very serious issues with forming IS-IS adjacencies.
To troubleshoot these issues further, you must take a closer look at the protocol interaction by
enabling traceoptions. Configure traceoptions on R1 and R2. These traceoptions should contain
the flags error detail and hello detail. After you create the traceoptions, commit the
configuration and wait 1 minute before viewing the traceoptions file. This gives the router time to
populate the file with helpful information concerning the IS-IS adjacency issues.
• R1:
lab@R1# set traceoptions file isis-adj-issue.log

lab@R1# set traceoptions flag error detail

lab@R1# set traceoptions flag hello detail

lab@R1# commit
commit complete

lab@R1# run show log isis-adj-issue.log | match ge-0/0/3
Jan 24 20:54:27.960190 ERROR: IIH from 0172.0027.2554 with no matching areas,
Jan 24 20:54:28.274132 ISIS L1 periodic xmit to 01:80:c2:00:00:14 interface ge-0/0/
3.0
Jan 24 20:54:29.395489 Received L1 LAN IIH, source id 0172.0027.2554 on ge-0/0/3.0
....

lo0.0 up up inet 172.27.255.1 --> 0/0
iso 49.0002.0172.0027.2551
R1 appears to be configured with an incorrect area ID. Level 1 adjacencies must have a
matching area ID and level to form. Changing the area ID on R1 fixes the adjacency problem
with R2.
• R1:
lab@R1# top delete interfaces lo0.0 family iso

lab@R1# top set interfaces lo0.0 family iso address 49.0001.0172.0027.2551.00

lab@R1# commit
commit complete

ae1.0 R2 1 Up 8 52:54:0:1:0:3
ge-0/0/3.0 R2 1 Up 1 56:68:29:7a:ab:5b
ge-0/0/6.0 0172.0027.2553 1 Down 0 56:68:29:7a:93:b2
Note
Fixing the adjacency issue with R2 now
appears to have broken the adjacency with
R3, which is why you must check and
re-check the status of your network while
you configure or troubleshoot. A task might
be designed to break a previously
completed task, and you might not notice it
until later in the exam, at which point it is
very difficult to troubleshoot the new issue.
Examine the traceoptions on R1 again to view the problem with the adjacency with R3. You
might also notice in the previous output that R1 believes R2 is found through its ae1 and ge-0/
0/3 interface, which signifies another issue that must be addressed later.
• R1:
lab@R1# run show log isis-adj-issue.log | match ge-0/0/6
Jan 24 21:11:34.622705 ISIS L1 periodic xmit to 01:80:c2:00:00:14 interface ge-0/
0/6.0
Jan 24 21:11:34.623333 Received L1 LAN IIH, source id 0172.0027.2553 on ge-0/0/6.0

It appears that another area ID mismatch exists. We recently configured R1 with the correct area
ID so there must be an incorrect area ID on R3. Examining R3 reveals that it has the incorrect
area ID. Configure the correct area ID and examine the IS-IS adjacency again.
• R3:
lo0.0 up up inet 172.27.255.3 --> 0/0
iso 49.0002.0172.0027.2553



lab@R3# commit
commit complete
• R1:
ae1.0 R2 1 Up 7 52:54:0:1:0:3
ge-0/0/3.0 R2 1 Up 1 56:68:29:7a:ab:5b
ge-0/0/6.0 0172.0027.2553 1 Up 1 56:68:29:7a:93:b2
• R2:
Now, configure the traceoptions on R2 with the flags that were mentioned earlier.
[edit interfaces]

lab@R2# set traceoptions file isis-adj-issue.log

lab@R2# set traceoptions flag error detail

lab@R2# set traceoptions flag hello detail

lab@R2# commit
commit complete

lab@R2# run show log isis-adj-issue.log | match ae0
Jan 24 21:46:56.786800 ISIS L1 periodic xmit to 01:80:c2:00:00:14 interface ae0.0

Jan 24 21:46:56.969347 ERROR: ISIS ignored a bad packet: IIH with duplicate sysid
on interface ae0.0
Jan 24 21:46:58.494271 ERROR: ISIS ignored a bad packet: IIH with duplicate sysid
on interface ae0.0
By examining the traceoptions on R2, you can see that there appears to be a duplicate system
ID between R2 and R4. Examine R2 and R4 to determine which router has the incorrect system
ID.
• R2:
lo0.0 up up inet 172.27.255.2 --> 0/0
iso 49.0001.0172.0027.2554
• R4:
lo0.0 up up inet 172.27.255.4 --> 0/0
iso 49.0001.0172.0027.2554
Question: What router has the incorrect system ID and what

must you change it to?
Answer: From the output you can determine that the system ID
is determined from the loopback address. This means that R2’s
system ID must be changed to 49.0001.0172.0027.2552.
• R2:


lab@R2# commit
commit complete

ae0.0 0172.0027.2554 1 Up 1 52:54:0:1:0:2
ge-0/0/1.0 R1 ! 1 Up 5 56:68:29:7a:a0:ed

.
Note
Remember to deactivate the traceoptions
once you are done using them. While not
specific to accomplishing this task, it is
always considered good practice to never
leave traceoptions running when they are
not needed.
• R1:
lab@R1# deactivate traceoptions

lab@R1# commit
commit complete
• R2:

lab@R2# commit
commit complete
TASK VERIFICATION
To verify this task, issue the show isis adjacency command on all routers. Each router
must have the correct adjacencies in the Up state.
• R1:
ae1.0 0172.0027.2554 1 Up 8 52:54:0:1:0:3
ge-0/0/3.0 R2 1 Up 1 56:68:29:7a:ab:5b
ge-0/0/6.0 0172.0027.2553 1 Up 1 56:68:29:7a:93:b2
• R2:
ae0.0 0172.0027.2554 1 Up 1 52:54:0:1:0:2
ge-0/0/1.0 R1 ! 1 Up 4 56:68:29:7a:a0:ed
• R3:

ge-0/0/1.0 0172.0027.2551! 1 Up 5 56:68:29:7a:8e:3a
ge-0/0/2.0 R4 2 Up 25 56:68:29:7a:85:91
ge-0/0/3.0 R5 2 Up 7 56:68:29:7a:b2:4d
• R4:
ae0.0 0172.0027.2552 1 Up 4 52:54:0:0:c0:2
ae1.0 0172.0027.2551! 1 Up 21 52:54:0:0:4:3
ae2.0 R5 2 Up 24 52:54:0:0:4b:4
ge-0/0/5.0 R3 2 Up 7 56:68:29:7a:b4:8b
• R5:
[edit]
ae2.0 R4 2 Up 6 52:54:0:1:0:4
ge-0/0/1.0 R3 2 Up 25 56:68:29:7a:9a:c9
Question: Many adjacencies have a system name that did not

resolve to the router’s host name. Does this make the task
incomplete?
Answer: No. The task only requires that all necessary

adjacencies are in the Up state. However, this is an indication of
another issue. It is important to keep this in mind as you
attempt later tasks.
Question: Some routers have adjacencies that are notated by

an exclamation mark. What does this mean?
Answer: Having an exclamation mark notation in the adjacency

output tells you that the router is not receiving LSPs with
prefixes from said adjacency. Although this does not signal an
adjacency problem, it is important to make note of this.
TASK 2
Ensure that all routers have IPv4 and IPv6 IS-IS routes present in
their routing tables.

TASK INTERPRETATION
By default, IS-IS allows for the routing of IPv4 and IPv6 packets. Examine each router for IPv4
and IPv6 IS-IS routes. If a router is missing either, troubleshoot the issue to bring the proper
routes into the routing tables.
TASK COMPLETION
Start by examining the routing tables on all routers.
• R1:
lab@R1# run show route summary
Router ID: 172.27.255.1

Direct: 8 routes, 8 active
Local: 7 routes, 7 active
RIP: 4 routes, 4 active
Aggregate: 1 routes, 0 active


• R2:
Router ID: 172.27.255.2

Static: 2 routes, 2 active


• R3:
Router ID: 172.27.255.3

OSPF: 9 routes, 8 active
IS-IS: 8 routes, 8 active


• R4:
Router ID: 172.27.255.4



• R5:
[edit]
Router ID: 172.27.255.1



After viewing the routing tables on each router, you will notice that R1 has no IPv4 or IPv6 IS-IS
routes. R2, R3, R4, and R5 have IPv4 IS-IS routes, but no IPV6 IS-IS routes. Issuing the show
isis overview command on each router can help lead you in the right direction.

• R1:
Instance: master
Router ID: 172.27.255.1
Maximum Areas: 3
LSP life time: 3600
Reference bandwidth: 4230196224
Restart: Enabled
Level 1
Prefix export limit: 2
Level 2
• R2:
Instance: master
Router ID: 172.27.255.2
Maximum Areas: 3
LSP life time: 3600
IPv4 is enabled
Restart: Enabled
Level 1
Level 2

• R3:
Instance: master
Router ID: 172.27.255.3
Maximum Areas: 3
LSP life time: 3600
IPv4 is enabled
Restart: Enabled
Level 1
Level 2
• R4:
Instance: master
Router ID: 172.27.255.4
Maximum Areas: 3
LSP life time: 3600
IPv4 is enabled
Restart: Enabled
Level 1
Level 2

• R5:
[edit]
Instance: master
Router ID: 172.27.255.1
Maximum Areas: 3
LSP life time: 3600
Overload bit at startup is set
Overload high metrics: disabled
Allow route leaking: disabled
IPv4 is enabled
Restart: Enabled
Level 1
Level 2
Question: What can you determine from the outputs?
Answer: You must look at what the outputs are not saying. For
instance, all the routers except R1 show that IPv4 traffic is
enabled for IS-IS. From this information, you can deduce that
IPv6 routing for IS-IS has been disabled on every router, and R1
also has IPv4 routing for IS-IS disabled.
Question: The output from R5 displays that the overload bit is

set. Is it necessary to remove R5 from the overloaded mode?
Answer: It is impossible to tell right now if it is necessary to take

R5 out of the overloaded mode. Later tasks might require this
action, but for now just make special note of it.

Check the configuration of each router for statements that disable IPv4 or IPv6 routing for IS-IS.
Then, remove any statements that might be causing these problems.
• R1:
lab@R1# show
inactive: traceoptions {
file isis-adj-issue;
flag error detail;
flag hello detail;
}
export isis-out;
lsp-lifetime 3600;
no-ipv4-routing;
no-ipv6-routing;
...

lab@R1# delete no-ipv4-routing


lab@R1# commit
commit complete
• R2:
lab@R2# show
file isis-adj-issue;
flag error detail;
flag hello detail;
}
export static-isis;
lsp-lifetime 3600;
no-ipv6-routing;
level 2 disable;
...


lab@R2# commit
commit complete

• R3:
lab@R3# show
lsp-lifetime 3600;
no-authentication-check;
no-ipv6-routing;
...


lab@R3# commit
commit complete
• R4:
lab@R4# show
export leak-routes;
lsp-lifetime 3600;
no-ipv6-routing;
...


lab@R4# commit
commit complete
• R5:
[edit]

lab@R5# show
export ospf-isis;
lsp-lifetime 3600;
no-ipv6-routing;
overload;
level 1 disable;
...


lab@R5# commit
commit complete
Examining the routing table gives some very interesting results. R1 and R2 still do not have any
IPv4 or IPv6 IS-IS routes. Issuing the show isis adjacency command on the routers also
reveals confusing results. The adjacency between R1 and R2 has been lost, and all routers with
Level 1 adjacencies are not resolving their partners host names.
• R1:
Router ID: 172.27.255.1




ae1.0 0172.0027.2554 1 Up 8 52:54:0:1:0:3
ge-0/0/6.0 0172.0027.2553 1 Up 1 56:68:29:7a:93:b2
• R2:
Router ID: 172.27.255.2




ae0.0 0172.0027.2554 1 Up 1 52:54:0:1:0:2
• R3:
Router ID: 172.27.255.3




ge-0/0/1.0 0172.0027.2551 1 Up 4 56:68:29:7a:8e:3a
ge-0/0/2.0 R4 2 Up 20 56:68:29:7a:85:91
ge-0/0/3.0 R5 2 Up 7 56:68:29:7a:b2:4d
• R4:
Router ID: 172.27.255.4




ae0.0 0172.0027.2552 1 Up 5 52:54:0:0:c0:2
ae1.0 0172.0027.2551 1 Up 18 52:54:0:0:4:3
ae2.0 R5 2 Up 18 52:54:0:0:4b:4
ge-0/0/5.0 R3 2 Up 8 56:68:29:7a:b4:8b
• R5:
Router ID: 172.27.255.1



Monitoring the traffic on R1’s ge-0/0/3 interface reveals that the issue is a misconfigured IPv4
address on that interface. Configuring the correct IPv4 address on the ge-0/0/3 interface
resolves the adjacency issue.
Unlike the other Level 1 adjacencies, the system name resolves to the host name with the
adjacency between R1 and R2. An undiscovered problem still exists that is causing the other
Level 1 adjacencies to fail host name resolution.
• R1:
lab@R1# run monitor traffic interface ge-0/0/3 detail no-resolve
Listening on ge-0/0/3, capture size 1514 bytes
02:17:12.108973 Out IS-IS, length 76

L1 Lan IIH, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0)
source-id: 0172.0027.2551, holding time: 6s, Flags: [Level 1 only]
lan-id: 0172.0027.2551.00, Priority: 64, PDU length: 76
Protocols supported TLV #129, length: 2
NLPID(s): IPv4 (0xcc), IPv6 (0x8e)
IPv4 Interface address(es) TLV #132, length: 4
IPv4 interface address: 172.27.0.210
IPv6 Interface address(es) TLV #232, length: 16
IPv6 interface address: fe80::5668:29ff:fe7a:a0ed

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: 8
simple text password: Juniper
...
lab@R1# top edit interfaces ge-0/0/3.0

lab@R1# show
family inet {
address 172.27.0.210/30;
}
family iso;
family inet6 {
address 2008:4498::1/126;
}

lab@R1# replace pattern .210/30 with .1/30

lab@R1# show
family inet {
address 172.27.0.1/30;
}
family iso;
family inet6 {
address 2008:4498::1/126;
}

lab@R1# commit
commit complete

ae1.0 0172.0027.2554 1 Up 7 52:54:0:1:0:3
ge-0/0/3.0 R2 1 Up 1 56:68:29:7a:ab:5b
ge-0/0/6.0 0172.0027.2553 1 Up 1 56:68:29:7a:93:b2
TASK VERIFICATION
After resolving the adjacency issue between R1 and R2, all routers now have IPv4 and IPv6 IS-IS
routes. However, it is obvious that a great deal of routing information is still missing. For the
moment, this task can be considered complete, but keep in mind that later tasks could cause
specific routes to disappear which will cause you to revisit this task.
• R1:
Router ID: 172.27.255.1



• R2:
Router ID: 172.27.255.2



• R3:
Router ID: 172.27.255.3



• R4:
Router ID: 172.27.255.4



• R5:
[edit]
Router ID: 172.27.255.1



TASK 3
Ensure that the loss of any interface on a router can not remove a
router from the IS-IS topology.

TASK INTERPRETATION
What this task is asking might seem somewhat cryptic. Every internal router has at least two
interfaces, so it seems that the loss of any one interface on a router does not result in the
removal of the router from the IS-IS topology. However, if the ISO address is applied to a transit
interface, instead of the loopback interface, loss of that interface results in the router being
removed from the IS-IS topology.
TASK COMPLETION
Examine the interfaces on every router to determine if there are any ISO addresses applied to
transit interfaces.
• R1:
lo0.0 up up inet 172.27.255.1 --> 0/0
iso 49.0001.0172.0027.2551
• R2:
lo0.0 up up inet 172.27.255.2 --> 0/0
iso 49.0001.0172.0027.2552
• R3:
lo0.0 up up inet 172.27.255.3 --> 0/0
iso 49.0001.0172.0027.2553
• R4:
lo0.0 up up inet 172.27.255.4 --> 0/0
iso 49.0001.0172.0027.2554
• R5:
[edit]
lo0.0 up up inet 172.27.255.1 --> 0/0
172.27.255.5 --> 0/0
iso
[edit]
lab@R5# run show interfaces terse

...
inet6 2008:4498::39/126
fe80::5668:29ff:fe7a:87ca/64
ge-0/0/6 up up
ge-0/0/6.0 up up inet 138.1.2.6/24
ge-0/0/7 up up
ge-0/0/8 up up
ge-0/0/9 up up
ge-0/0/9.0 up up inet 172.27.0.105/28
ae0 up down
ae1 up down
ae2 up up
ae2.0 up up inet 172.27.0.22/30
iso 49.0002.0172.0027.2555
inet6 2008:4489::16/126
fe80::5254:ff:fe00:4b04/64
...
From the previous outputs, you can see that R5 has the ISO address applied to its ae2 interface.
If the ae2 link goes down for any reason, R5 will be removed from the IS-IS topology. To fix this
issue, you must remove the ISO address from the ae2 interface, and apply it to the loopback
interface.
• R5:
[edit interfaces]
lab@R5# delete ae2.0 family iso address 49.0002.0172.0027.2555.00
[edit interfaces]
[edit interfaces]
lab@R5# commit
commit complete
TASK VERIFICATION
Examine the loopback interface on R5 for the ISO address. If the ISO address is present on the
loopback interface this task is complete.
• R5:
[edit interfaces]
lo0.0 up up inet 172.27.255.1 --> 0/0
172.27.255.5 --> 0/0
iso 49.0002.0172.0027.2555

TASK 4
To reduce the size of the IS-IS link-state database ensure that the
interface routes of all core facing interfaces are not present in
the database. However, you must ensure that all routers can ping
each other’s loopback addresses.
Note
When you ping each router’s loopback
address, be sure to source the ping from
the local router’s loopback address.
TASK INTERPRETATION
For this task, you must create and apply a policy on each router that blocks direct routes from
being exported into IS-IS. However, allow each router to advertise its loopback address. Also,
ensure that you allow R1 and R5 to advertise the direct routes associated with their interfaces
that are running in the IS-IS passive mode. Then, ensure that each router can ping every other
router’s loopback address. If there are any problems, troubleshoot the issues until they are
resolved.
TASK COMPLETION
• R1:
lab@R1# top edit policy-options policy-statement local-routes term
allowed-interfaces
[edit policy-options policy-statement local-routes term allowed-interfaces]

lab@R1# set from interface lo0.0


lab@R1# up 1 edit term direct-routes
[edit policy-options policy-statement local-routes term direct-routes]




lab@R1# set export local-routes

lab@R1# commit
commit complete

• R2:
allowed-interfaces


lab@R2# set from interface ge-0/0/2.0







lab@R2# commit
commit complete
• R3:
allowed-interfaces









lab@R3# commit
commit complete
• R4:
allowed-interfaces








lab@R4# commit
commit complete
• R5:
[edit interfaces]
allowed-interfaces


lab@R5# set from interface ge-0/0/5.0








lab@R5# commit
commit complete
• R1:

172.27.0.36/30 *[IS-IS/15] 00:05:08, metric 40

> to 172.27.0.2 via ge-0/0/3.0
172.27.255.2/32 *[IS-IS/15] 18:51:13, metric 30
> to 172.27.0.2 via ge-0/0/3.0

2008:4498::24/126 *[IS-IS/15] 00:05:08, metric 40

> to fe80::5668:29ff:fe7a:ab5b via ge-0/0/3.0
• R2:

172.27.255.1/32 *[IS-IS/15] 18:52:04, metric 10

> to 172.27.0.1 via ge-0/0/1.0

• R3:

10.100.100.0/24 *[IS-IS/18] 00:47:42, metric 30, tag 104

> to 172.27.0.18 via ge-0/0/2.0
172.27.0.56/30 *[IS-IS/18] 00:12:42, metric 60
> to 172.27.0.25 via ge-0/0/3.0
172.27.255.1/32 *[IS-IS/18] 00:12:42, metric 30
> to 172.27.0.25 via ge-0/0/3.0
172.27.255.4/32 *[IS-IS/18] 00:47:42, metric 30
> to 172.27.0.18 via ge-0/0/2.0
172.27.255.5/32 *[IS-IS/18] 00:12:42, metric 30
> to 172.27.0.25 via ge-0/0/3.0

2008:4498::38/126 *[IS-IS/18] 00:12:42, metric 60

> to fe80::5668:29ff:fe7a:b24d via ge-0/0/3.0
• R4:

10.22.0.0/21 *[IS-IS/18] 00:35:29, metric 331

> to 172.27.0.17 via ge-0/0/5.0
172.27.0.56/30 *[IS-IS/18] 00:13:26, metric 45
> to 172.27.0.22 via ae2.0
172.27.255.0/30 *[IS-IS/18] 00:13:25, metric 40
> to 172.27.0.17 via ge-0/0/5.0
172.27.255.1/32 *[IS-IS/18] 00:13:26, metric 15
> to 172.27.0.22 via ae2.0
172.27.255.3/32 *[IS-IS/18] 00:35:29, metric 30
> to 172.27.0.17 via ge-0/0/5.0
172.27.255.5/32 *[IS-IS/18] 00:13:26, metric 15
> to 172.27.0.22 via ae2.0

2008:4498::38/126 *[IS-IS/18] 00:13:26, metric 45

> to fe80::5254:ff:fe00:4b04 via ae2.0
• R5:

10.22.0.0/21 [IS-IS/151] 17:38:45, metric 450

> to 172.27.0.21 via ae2.0
10.100.100.0/24 *[IS-IS/151] 17:38:45, metric 99, tag 104
> to 172.27.0.21 via ae2.0
172.27.255.0/30 [IS-IS/151] 17:38:45, metric 109
> to 172.27.0.21 via ae2.0
172.27.255.3/32 *[IS-IS/151] 17:38:45, metric 149
> to 172.27.0.21 via ae2.0
172.27.255.4/32 *[IS-IS/151] 17:38:45, metric 99
> to 172.27.0.21 via ae2.0
The core-facing interface routes are no longer present, but R1 and R2 still have no way to reach
R3’s, R4’s, or R5’s loopback addresses. Examining the IS-IS link-state database on R1 and R2
reveals that they are not receiving LSPs from R3, R4, and R5. The reverse is true if you examine
the databases on R3, R4, and R5. This means that R1 and R2 are not receiving LSPs from R3
and R4 with the attached bit set. This does not allow R1 and R2 to install a default route to reach
prefixes that are out of their area.
• R1:
lab@R1# run show isis database
IS-IS level 1 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
R1.00-00 0x5 0xab56 2312 L1 Overload
R2.00-00 0x3 0x4450 2285 L1 Overload
R2.02-00 0x1 0xd3d3 2202 L1
3 LSPs

0 LSPs
• R2:
R1.00-00 0x5 0xab56 2300 L1 Overload
R2.00-00 0x3 0x4450 2276 L1 Overload
R2.02-00 0x1 0xd3d3 2194 L1
3 LSPs

0 LSPs
• R3:
R3.00-00 0x3 0xb05d 1412 L1 L2 Attached
R3.02-00 0x1 0x8f7 1354 L1 L2
2 LSPs

R3.00-00 0x3 0xf190 1413 L1 L2
R3.03-00 0x1 0x385a 1413 L1 L2
R4.00-00 0x3 0xa836 1421 L1 L2
R4.04-00 0x1 0x4648 1421 L1 L2
R5.00-00 0x3 0xdfdd 1421 L1 L2 Overload
R5.02-00 0x1 0x2d63 1409 L1 L2
6 LSPs
• R4:
R4.00-00 0x4 0x2a4f 1382 L1 L2 Attached
R4.02-00 0x1 0x95b1 1316 L1 L2
R4.03-00 0x1 0xb7ad 1341 L1 L2
3 LSPs

R3.00-00 0x14 0xd855 3325 L1 L2
R3.02-00 0x7 0x335a 3325 L1 L2
R4.00-00 0xd 0xae3b 3350 L1 L2
R4.02-00 0x5 0x4c40 3350 L1 L2
R5.00-00 0xa 0x2be4 3399 L1 L2 Overload
R5.02-00 0x7 0x2169 3399 L1 L2
6 LSPs

Question: The previous outputs show that R1 and R2 are
overloaded. Does that create a problem for the current task?
Answer: No. Only traffic that has another possible path that
normally would pass through the overloaded router is effected.
However, this might cause problems with a task you have not yet
attempted. Make special note that the routers are overloaded
and move on.
Question: What can be causing the failure of Level 1 LSP

exchanges?
Answer: LSP authentication can cause LSP exchanges to fail. In

previous outputs you might have noticed that the System field
is not resolving the router’s host name with the show isis
adjacency command on some adjacencies. This is also an
indication of LSP authentication failure.
Enabling the correct traceoptions flags can help you determine if LSP authentication failure is
occurring. Activate the traceoptions on R1 and R2, remove the hello detail flag, and add
the csn detail flag. Then, change the file name to lsp-auth-issue.log to differentiate
it with the last traceoptions file you created.
• R1:
lab@R1# activate traceoptions

lab@R1# delete traceoptions flag hello

lab@R1# set traceoptions flag csn

lab@R1# set traceoptions file lsp-auth-issue.log

lab@R1# show traceoptions
file lsp-auth-issue.log;
flag error detail;
flag csn;

lab@R1# commit
commit complete

lab@R1# run show log lsp-auth-issue.log | match csn
Jan 24 22:21:20.839779 Received L1 CSN, source 0172.0027.2553, interface 
ge-0/0/6.0
Jan 24 22:21:20.839877 ERROR: CSN authentication failure
Jan 24 22:21:20.839896 ERROR: L1 CSN from 0172.0027.2553 on ge-0/0/6.0 failed
authentication
Jan 24 22:21:21.547672 Received L1 CSN, source 0172.0027.2554, interface ae1.0
Jan 24 22:21:21.547891 ERROR: L1 CSN from 0172.0027.2554 on ae1.0 failed
authentication


lab@R1# commit
commit complete
• R2:

lab@R2# delete traceoptions flag hello

lab@R2# set traceoptions flag csn

lab@R2# set traceoptions file lsp-auth-issue.log

lab@R2# commit
commit complete

lab@R2# run show log lsp-auth-issue.log | match csn
Jan 24 22:21:46.482466 Received L1 CSN, source 0172.0027.2554, interface ae0.0
Jan 24 22:21:46.482602 ERROR: L1 CSN from 0172.0027.2554 on ae0.0 failed
authentication


lab@R2# commit
commit complete

From the previous output, it is obvious that LSP authentication failure is occurring. Because
these exchanges are encrypted, it is impossible to decipher exactly what key is being used.
However, the first task only stipulates that the authentication must remain in place, you are not
required to use the current authentication keys. You can change the keys to something
completely different.
• R1:
lab@R1# set level 1 authentication-key juniper

lab@R1# commit
commit complete
• R2:

lab@R2# commit
commit complete
• R3:

lab@R3# commit
commit complete
• R4:


lab@R4# commit
commit complete
• R1:
ae1.0 R4 1 Up 6 52:54:0:1:0:3
ge-0/0/3.0 R2 1 Up 1 56:68:29:7a:ab:5b
ge-0/0/6.0 R3 1 Up 1 56:68:29:7a:93:b2


R1.00-00 0x1d 0xea2f 2027 L1 Overload
R2.00-00 0x11 0x10dd 3144 L1 Overload
R2.02-00 0xe 0x30f4 3144 L1
R3.00-00 0xa 0x8157 1548 L1 L2 Attached
R3.02-00 0x6 0x52e4 1540 L1 L2
R4.00-00 0xb 0xc4d5 2023 L1 L2 Attached
R4.02-00 0x4 0x8ce8 1773 L1 L2
R4.03-00 0x7 0xa5b2 2023 L1 L2
8 LSPs

0 LSPs


0.0.0.0/0 *[IS-IS/15] 00:28:15, metric 15

> to 172.27.0.9 via ae1.0
• R2:
ae0.0 R4 1 Up 1 52:54:0:1:0:2
ge-0/0/1.0 R1 1 Up 4 56:68:29:7a:a0:ed

R1.00-00 0x1d 0xea2f 1895 L1 Overload
R2.00-00 0x11 0x10dd 3016 L1 Overload
R2.02-00 0xe 0x30f4 3016 L1
R3.00-00 0xa 0x8157 1416 L1 L2 Attached
R3.02-00 0x6 0x52e4 1408 L1 L2
R4.00-00 0xb 0xc4d5 1893 L1 L2 Attached
R4.02-00 0x4 0x8ce8 1645 L1 L2
R4.03-00 0x7 0xa5b2 1893 L1 L2
8 LSPs

0 LSPs


0.0.0.0/0 *[IS-IS/15] 00:36:47, metric 3

> to 172.27.0.6 via ae0.0
The System field now resolves to the host name for all Level 1 adjacencies. R1 and R2 are now
receiving LSPs from R3 and R4 which contain an attached bit. This allows them to install a
default IS-IS route into their routing tables.
Now you can ping to verify loopback to loopback reachability. Remember to source the pings
from the local router’s loopback address.
• R1:
lab@R1# run ping 172.27.255.2 source 172.27.255.1 count 2 rapid
PING 172.27.255.2 (172.27.255.2): 56 data bytes
!!
--- 172.27.255.2 ping statistics ---

PING 172.27.255.3 (172.27.255.3): 56 data bytes
!!
--- 172.27.255.3 ping statistics ---

PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!
--- 172.27.255.4 ping statistics ---

PING 172.27.255.5 (172.27.255.5): 56 data bytes
..
--- 172.27.255.5 ping statistics ---
• R2:
PING 172.27.255.1 (172.27.255.1): 56 data bytes
!!

--- 172.27.255.1 ping statistics ---

PING 172.27.255.3 (172.27.255.3): 56 data bytes
!!
--- 172.27.255.3 ping statistics ---

PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!
--- 172.27.255.4 ping statistics ---

PING 172.27.255.5 (172.27.255.5): 56 data bytes
..
--- 172.27.255.5 ping statistics ---
• R3:
PING 172.27.255.1 (172.27.255.1): 56 data bytes
!!
--- 172.27.255.1 ping statistics ---

PING 172.27.255.2 (172.27.255.2): 56 data bytes
!!
--- 172.27.255.2 ping statistics ---

PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!
--- 172.27.255.4 ping statistics ---


PING 172.27.255.5 (172.27.255.5): 56 data bytes
!!
--- 172.27.255.5 ping statistics ---
• R4:
PING 172.27.255.1 (172.27.255.1): 56 data bytes
!!
--- 172.27.255.1 ping statistics ---

PING 172.27.255.2 (172.27.255.2): 56 data bytes
!!
--- 172.27.255.2 ping statistics ---

PING 172.27.255.3 (172.27.255.3): 56 data bytes
!!
--- 172.27.255.3 ping statistics ---

PING 172.27.255.5 (172.27.255.5): 56 data bytes
!!
--- 172.27.255.5 ping statistics ---
• R5:
PING 172.27.255.1 (172.27.255.1): 56 data bytes
!!
--- 172.27.255.1 ping statistics ---

PING 172.27.255.2 (172.27.255.2): 56 data bytes
36 bytes from 172.27.0.105: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst

4 5 00 0054 58fb 0 0000 01 01 0a6f 172.27.255.5 172.27.255.2

4 5 00 0054 590b 0 0000 01 01 0a5f 172.27.255.5 172.27.255.2
.
--- 172.27.255.2 ping statistics ---

PING 172.27.255.3 (172.27.255.3): 56 data bytes
!!
--- 172.27.255.3 ping statistics ---

PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!
--- 172.27.255.4 ping statistics ---
Question: What do the ping tests reveal?
Answer: R1 and R2 can reach every router except R5. R3 and

R4 can reach every router. R5 can reach every router except R2,
and there appears to be a routing loop when R5 attempts to
reach R2. Also, there appears to be one way communication
between R1 and R5.
Question: What can you do to troubleshoot the routing loop that

exists when trying to ping R2 from R5?
Answer: First, issue a traceroute from R2 and then issue a

traceroute from R5. Next, examine the routing tables on both
routers. These steps will give you the clues necessary to
continue forward.

• R2:
lab@R2# run traceroute 172.27.255.5 source 172.27.255.2
traceroute to 172.27.255.5 (172.27.255.5) from 172.27.255.2, 30 hops max, 40 byte
packets
1 172.27.0.6 (172.27.0.6) 9.892 ms 9.158 ms 9.819 ms
2 * * *
3 * * *
...
28 * * *
29 * * *
30 * * *


0.0.0.0/0 *[IS-IS/15] 01:24:07, metric 3

> to 172.27.0.6 via ae0.0
• R5:
packets
1 172.27.0.101 (172.27.0.101) 5.918 ms 5.079 ms 5.860 ms
2 172.27.0.105 (172.27.0.105) 5.673 ms 5.204 ms 5.875 ms
3 172.27.0.101 (172.27.0.101) 6.666 ms 6.516 ms 6.561 ms
4 172.27.0.105 (172.27.0.105) 6.662 ms 6.215 ms 6.464 ms
5 172.27.0.101 (172.27.0.101) 7.162 ms 7.212 ms 7.936 ms
6 172.27.0.105 (172.27.0.105) 7.590 ms 8.848 ms 7.245 ms
7 172.27.0.101 (172.27.0.101) 8.755 ms 8.134 ms 8.856 ms
8 172.27.0.105 (172.27.0.105) 8.698 ms 8.208 ms 8.908 ms
9 172.27.0.101 (172.27.0.101) 9.628 ms 9.214 ms 8.839 ms
...


172.27.255.0/30 *[OSPF/17] 01:36:53, metric 0, tag 0

> to 172.27.0.101 via ge-0/0/9.0
[IS-IS/151] 00:40:22, metric 40
> to 172.27.0.26 via ge-0/0/1.0

Question: What do the previous outputs reveal?
Answer: DC3 is advertising a route more preferred on R5 that is

drawing the traffic towards it. This causes R5 to send the traffic
destined for R1 to DC3 first. DC3 then sends the traffic right
back to R5.
Question: What must you do to eliminate the routing loop?
Answer: You can eliminate the routing loop by raising the OSPF
external preference to 152, lowering the IS-IS Level 2 internal
preference to 16, or applying an import policy on R5 that blocks
the route from being installed into the routing table.
Question: Can you determine why the ping test to R1’s loopback
address from R5 worked, while the ping to R2’s loopback
address from R5 did not work?
Answer: If you were paying close attention to the outputs in

previous tasks, you might have noticed that R5 has two
loopback IPv4 addresses; 172.27.255.5 and 172.27.255.1. In
reality, R5 was just pinging itself in the previous outputs.
• R5:

172.27.255.1/32 *[Direct/0] 4d 06:51:50

> via lo0.0

lab@R5# top delete interfaces lo0.0 family inet address 172.27.255.1

lab@R5# up 1 set ospf external-preference 155


lab@R5# commit
commit complete


172.27.255.0/30 *[IS-IS/151] 00:43:07, metric 40

> to 172.27.0.26 via ge-0/0/1.0
[OSPF/155] 00:00:03, metric 0, tag 0
> to 172.27.0.101 via ge-0/0/9.0


172.27.255.0/30 *[IS-IS/151] 00:43:10, metric 40

> to 172.27.0.26 via ge-0/0/1.0
[OSPF/155] 00:00:06, metric 0, tag 0
> to 172.27.0.101 via ge-0/0/9.0
TASK VERIFICATION
To verify this task, ping the loopback address of each router. Remember to source the ping from
the local routers loopback address. Also, examine the routing table to ensure no core interface
routes are present.
• R1:
PING 172.27.255.2 (172.27.255.2): 56 data bytes
!!
--- 172.27.255.2 ping statistics ---

PING 172.27.255.3 (172.27.255.3): 56 data bytes
!!
--- 172.27.255.3 ping statistics ---

PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!
--- 172.27.255.4 ping statistics ---

PING 172.27.255.5 (172.27.255.5): 56 data bytes
!!
--- 172.27.255.5 ping statistics ---


0.0.0.0/0 *[IS-IS/15] 02:11:09, metric 15

> to 172.27.0.9 via ae1.0
10.22.0.0/21 *[IS-IS/160] 00:10:08, metric 93
> to 172.27.0.13 via ge-0/0/6.0
10.100.100.0/24 *[IS-IS/160] 01:52:28, metric 78, tag 104
> to 172.27.0.9 via ae1.0
172.27.0.36/30 *[IS-IS/15] 02:19:25, metric 40
> to 172.27.0.2 via ge-0/0/3.0
172.27.0.56/30 *[IS-IS/18] 02:11:09, metric 78
> to 172.27.0.9 via ae1.0
172.27.255.2/32 *[IS-IS/15] 02:19:25, metric 30
> to 172.27.0.2 via ge-0/0/3.0
172.27.255.3/32 *[IS-IS/15] 02:19:25, metric 30
> to 172.27.0.13 via ge-0/0/6.0
172.27.255.4/32 *[IS-IS/15] 02:11:09, metric 15
> to 172.27.0.9 via ae1.0

::/0 *[IS-IS/15] 02:11:09, metric 15

> to fe80::5254:ff:fe01:3 via ae1.0
2008:4498::24/126 *[IS-IS/15] 02:19:25, metric 40
> to fe80::5668:29ff:fe7a:ab5b via ge-0/0/3.0
2008:4498::38/126 *[IS-IS/18] 02:11:09, metric 78
> to fe80::5254:ff:fe01:3 via ae1.0
• R2:
PING 172.27.255.1 (172.27.255.1): 56 data bytes
!!
--- 172.27.255.1 ping statistics ---


PING 172.27.255.3 (172.27.255.3): 56 data bytes
!!
--- 172.27.255.3 ping statistics ---

PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!
--- 172.27.255.4 ping statistics ---

PING 172.27.255.5 (172.27.255.5): 56 data bytes
!!
--- 172.27.255.5 ping statistics ---


0.0.0.0/0 *[IS-IS/15] 02:22:02, metric 3

> to 172.27.0.6 via ae0.0
10.100.100.0/24 [IS-IS/160] 01:55:01, metric 66, tag 104
> to 172.27.0.6 via ae0.0
172.27.0.56/30 *[IS-IS/18] 02:22:02, metric 66
> to 172.27.0.6 via ae0.0
172.27.255.1/32 *[IS-IS/15] 02:22:02, metric 10
> to 172.27.0.1 via ge-0/0/1.0
172.27.255.4/32 *[IS-IS/15] 02:22:02, metric 3
> to 172.27.0.6 via ae0.0

::/0 *[IS-IS/15] 02:22:02, metric 3

> to fe80::5254:ff:fe01:2 via ae0.0
2008:4498::38/126 *[IS-IS/18] 02:22:02, metric 66
> to fe80::5254:ff:fe01:2 via ae0.0
• R3:

PING 172.27.255.1 (172.27.255.1): 56 data bytes
!!
--- 172.27.255.1 ping statistics ---

PING 172.27.255.2 (172.27.255.2): 56 data bytes
!!
--- 172.27.255.2 ping statistics ---

PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!
--- 172.27.255.4 ping statistics ---

PING 172.27.255.5 (172.27.255.5): 56 data bytes
!!
--- 172.27.255.5 ping statistics ---


10.100.100.0/24 *[IS-IS/18] 00:42:57, metric 1, tag 104

> to 172.27.0.18 via ge-0/0/2.0
172.27.0.36/30 *[IS-IS/18] 00:42:57, metric 27
> to 172.27.0.18 via ge-0/0/2.0
172.27.0.56/30 *[IS-IS/18] 02:23:37, metric 200
> to 172.27.0.25 via ge-0/0/3.0
172.27.255.1/32 *[IS-IS/15] 02:23:45, metric 1
> to 172.27.0.14 via ge-0/0/1.0
172.27.255.4/32 *[IS-IS/18] 00:42:57, metric 1
> to 172.27.0.18 via ge-0/0/2.0
172.27.255.5/32 *[IS-IS/18] 02:23:45, metric 1
> to 172.27.0.25 via ge-0/0/3.0


2008:4498::24/126 *[IS-IS/18] 00:42:57, metric 27

> to fe80::5668:29ff:fe7a:8591 via ge-0/0/2.0
2008:4498::38/126 *[IS-IS/18] 02:23:37, metric 200
> to fe80::5668:29ff:fe7a:b24d via ge-0/0/3.0
• R4:
PING 172.27.255.1 (172.27.255.1): 56 data bytes
!!
--- 172.27.255.1 ping statistics ---

PING 172.27.255.2 (172.27.255.2): 56 data bytes
!!
--- 172.27.255.2 ping statistics ---

PING 172.27.255.3 (172.27.255.3): 56 data bytes
!!
--- 172.27.255.3 ping statistics ---

PING 172.27.255.5 (172.27.255.5): 56 data bytes
!!
--- 172.27.255.5 ping statistics ---


10.22.0.0/21 *[IS-IS/18] 00:08:08, metric 331

> to 172.27.0.17 via ge-0/0/5.0
172.27.0.36/30 *[IS-IS/15] 01:37:50, metric 40
> to 172.27.0.5 via ae0.0
172.27.0.56/30 *[IS-IS/18] 01:50:10, metric 45
> to 172.27.0.22 via ae2.0
172.27.255.0/30 *[IS-IS/18] 00:06:33, metric 30
> to 172.27.0.17 via ge-0/0/5.0

172.27.255.1/32 *[IS-IS/15] 00:01:56, metric 15
> to 172.27.0.10 via ae1.0
172.27.255.2/32 *[IS-IS/15] 01:37:50, metric 10
> to 172.27.0.5 via ae0.0
172.27.255.3/32 *[IS-IS/18] 01:49:37, metric 30
> to 172.27.0.17 via ge-0/0/5.0
172.27.255.5/32 *[IS-IS/18] 01:50:10, metric 15
> to 172.27.0.22 via ae2.0

2008:4498::24/126 *[IS-IS/15] 02:25:22, metric 26

> to fe80::5254:ff:fe00:c002 via ae0.0
2008:4498::38/126 *[IS-IS/18] 02:24:56, metric 224
> to fe80::5254:ff:fe00:4b04 via ae2.0
• R5:
PING 172.27.255.1 (172.27.255.1): 56 data bytes
!!
--- 172.27.255.1 ping statistics ---

PING 172.27.255.2 (172.27.255.2): 56 data bytes
!!
--- 172.27.255.2 ping statistics ---

PING 172.27.255.3 (172.27.255.3): 56 data bytes
!!
--- 172.27.255.3 ping statistics ---

PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!
--- 172.27.255.4 ping statistics ---



10.22.0.0/21 [IS-IS/151] 00:17:23, metric 450

> to 172.27.0.21 via ae2.0
10.100.100.0/24 *[IS-IS/151] 00:40:29, metric 99, tag 104
> to 172.27.0.21 via ae2.0
172.27.0.36/30 *[IS-IS/151] 00:40:29, metric 125
> to 172.27.0.21 via ae2.0
172.27.255.0/30 *[IS-IS/151] 00:40:29, metric 159
> to 172.27.0.21 via ae2.0
172.27.255.3/32 *[IS-IS/151] 00:40:29, metric 149
> to 172.27.0.21 via ae2.0
172.27.255.4/32 *[IS-IS/151] 00:40:29, metric 99
> to 172.27.0.21 via ae2.0

2008:4498::24/126 *[IS-IS/151] 00:40:29, metric 125

> to fe80::5254:ff:fe01:4 via ae2.0
TASK 5
R4 is using the ae1 link to send traffic to the loopback address of
R1. Ensure that this traffic uses the ae0 link if the ae1 link
fails.
TASK INTERPRETATION
At the moment, R4 is using the ae1 link to reach R1’s loopback address. To complete this task,
you must ensure that if the ae1 link fails, R4 will use the ae0 link to reach R1.
TASK COMPLETION
To complete this task, you must first configure the failure scenario in which the ae1 link is not
operational. Once the ae1 link is down, examine the routing table on R4 to see if the path to R1
leads through the ae0 link.
• R1:

lab@R1# commit
commit complete
• R4:

172.27.255.0/30 *[IS-IS/18] 20:13:02, metric 60

> to 172.27.0.17 via ge-0/0/5.0
[Aggregate/130] 5d 17:58:38
Reject

packets
1 172.27.0.17 (172.27.0.17) 5.910 ms 7.476 ms 5.238 ms
2 172.27.255.1 (172.27.255.1) 5.665 ms 6.255 ms 5.677 ms
With the ae1 link being non-operational, the traffic uses the ge-0/0/5 interface on R4 to reach
R1. To begin troubleshooting this issue, ensure that the interface metric for ae0 is lower than
the interface metric for ge-0/0/5. Also, it might be helpful to examine the IS-IS link-state
database for further clues.
• R4:
lab@R4# run show isis interface detail ae0.0
ae0.0
1 1 64 16 0.666 2 R4.02 (us)

lab@R4# run show isis interface detail ge-0/0/5.0
ge-0/0/5.0
2 1 64 50 9.000 27 R3.03 (not us)

R1.00-00 0x38 0x8d2a 2629 L1 Overload
R2.00-00 0x28 0x6669 1268 L1 Overload
R2.02-00 0x25 0xf023 1268 L1
R3.00-00 0x26 0x7cb0 1264 L1 L2 Attached
R3.02-00 0x20 0xbee8 1264 L1 L2
R4.00-00 0x24 0x2127 2629 L1 L2 Attached
R4.02-00 0x1c 0xdd96 2264 L1 L2
R4.03-00 0x1f 0 0 L1 L2
8 LSPs


R3.00-00 0x25 0x8479 1266 L1 L2
R3.03-00 0x1f 0xfb78 1266 L1 L2
R4.00-00 0x1f 0x6917 1262 L1 L2
R4.04-00 0x1b 0x1262 1767 L1 L2
R5.00-00 0x28 0xe9ad 1302 L1 L2 Overload
R5.02-00 0x24 0xe686 1302 L1 L2
6 LSPs

lab@R4# run show isis database R1 detail
R1.00-00 Sequence: 0x38, Checksum: 0x8d2a, Lifetime: 2609 secs

IS neighbor: R2.02 Metric: 50
IS neighbor: R3.02 Metric: 50
Question: Can you determine why the traffic is using the higher
cost interface?
Answer: From the previous outputs, you can see that R4 is

receiving an LSP from R1, and that LSP contains the loopback
address of R1. However, that route is not being installed in R4’s
routing table. When viewing the entire IS-IS link-state database,
you can see that R1 and R2 are overloaded, which means R4
cannot send traffic destined for R1 through R2.
To resolve this problem, you must have R2 advertise its LSP without the overload bit set.
Examine R2’s configuration to attempt to determine why this is occurring.
• R2:
lab@R2# show
file lsp-auth-issue.log;
flag error detail;
flag csn detail;
}
export [ static-isis local-routes ];
lsp-lifetime 3600;
level 2 disable;

level 1 {
authentication-key "$9$Mm1L7VgoGqmTwYmTz3tpWLx"; ## SECRET-DATA
authentication-type md5;
prefix-export-limit 1;
}
passive;
}
interface all {
level 1 {
hello-authentication-key "$9$IjshyeLxdgoGvWoGDif5IEc"; ## SECRET-DATA
hold-time 6;
}
}

Instance: master
Router ID: 172.27.255.2
Maximum Areas: 3
LSP life time: 3600
Restart: Enabled
Level 1
Prefix export limit: 1
Level 2
R2 is not using the overload statement and the show isis overview command does not
show that the overload bit is set. It is time to take a closer look at the internal IS-IS operations on
R2. Enable IS-IS traceoptions on R2 with only the error detail flag set. Then, wait a minute
for the traceoptions file to fill up with information.
• R2:

lab@R2# set traceoptions file R2-overload-issue.log

lab@R2# delete traceoptions flag csn

lab@R2# show traceoptions
file R2-overload-issue.log;
flag error detail;

lab@R2# commit
commit complete

lab@R2# run show log R2-overload-issue.log | match overload
Jan 24 18:13:06 trace_on: Tracing to "/var/log/R2-overload-issue.log" started
Jan 24 18:13:06.871515 ERROR: ISIS has exceeded the maximum external prefix
allowed - going to overload
Jan 24 18:13:06.872333 ERROR: IS-IS database overload


lab@R2# commit
commit complete
R2 is clearly overloaded because it is exceeding the maximum number of external routes allowed
to export into IS-IS. In the IS-IS protocol configuration, R2 has the prefix-export-limit
statement set to a value of 1, and it is exporting two static routes into IS-IS. Configure the
prefix-export-limit statement to have a value of 2. This removes R2 from the overloaded
mode.
• R2:
lab@R2# show | match prefix

lab@R2# set level 1 prefix-export-limit 2

lab@R2# commit
commit complete

R1.00-00 0x3d 0xadd 3371 L1 Overload
R2.00-00 0x31 0x6146 3590 L1
R2.02-00 0x2e 0xd503 3590 L1

R3.00-00 0x2b 0x7e6c 2600 L1 L2 Attached
R3.02-00 0x25 0x685c 2741 L1 L2
R4.00-00 0x29 0x41ab 3001 L1 L2 Attached
R4.02-00 0x21 0x1dc0 2595 L1 L2
7 LSPs

0 LSPs
TASK VERIFICATION
To verify this task, examine R4’s routing table to find R1’s loopback address. If the route points
towards R2 over the ae0 link, then the task is complete. Also, remember to restore the ae1 link
when you finish verifying this task.
• R4:

172.27.255.1/32 *[IS-IS/15] 00:01:37, metric 66

> to 172.27.0.5 via ae0.0

packets
1 172.27.0.5 (172.27.0.5) 5.641 ms 6.004 ms 5.715 ms
2 172.27.255.1 (172.27.255.1) 4.671 ms 5.259 ms 4.750 ms
• R1:

lab@R1# commit
commit complete
TASK 6
Ensure that R5 can communicate with the destinations advertised by
the customer router attached to R1. Also, ensure that R5 is
receiving this routing information from R3 and R4. You can verify
this step by pinging the 172.16.16.1 address.
TASK INTERPRETATION
This task requires you to enable communication between R5 and the destinations that are being
advertised by the customer router.

TASK COMPLETION
When examining R5’s routing table, you will find that it does not contain any routing information
for the 172.16.16.0/21 prefix range. After further examination of the routing tables of the other
routers, you will find that only R1 has routing information for these prefixes.
• R1:

172.16.16.0/29 *[RIP/100] 5d 09:15:35, metric 2, tag 0

> to 172.27.0.30 via ge-0/0/1.0
172.16.20.0/24 *[RIP/100] 5d 09:15:35, metric 2, tag 0
> to 172.27.0.30 via ge-0/0/1.0
172.16.21.0/24 *[RIP/100] 00:23:15, metric 2, tag 0
> to 172.27.0.30 via ge-0/0/1.0
• R2:
• R3:
• R4:
• R5:
If you remember from early outputs R1 is currently overloaded. This might have something to do
with the prefix-export-limit statement that it has configured.
• R1:
R1.00-00 0x47 0x892a 3596 L1 Overload
R2.00-00 0x33 0xd0df 2679 L1
R2.02-00 0x30 0xa07f 2889 L1
R3.00-00 0x2d 0xfb92 1716 L1 L2 Attached
R3.02-00 0x27 0xf1bf 2128 L1 L2
R4.00-00 0x2b 0xf436 727 L1 L2 Attached
R4.02-00 0x23 0x9f9f 1960 L1 L2
R4.03-00 0x2 0xec4a 877 L1 L2
8 LSPs

0 LSPs

lab@R1# show | match prefix
Question: How many RIP routes is R1 attempting to export in

IS-IS? Is the current prefix-export-limit statement
restricting exportation of these routes?
Answer: R1 is attempting to export three RIP routes into IS-IS.

The prefix-export-limit statement has a value of 2.
This is causing the router to go into the overloaded state and
not advertise these routes.
Change the Level 1 prefix-export-limit on R1 to a value that is greater than 2. This

removes R1 from the overloaded mode and allows it to advertise the RIP routes into IS-IS. Then,
examine the routing tables of the other routers in the network to see the results of this action.
• R1:
lab@R1# set level 1 prefix-export-limit 3

lab@R1# commit
commit complete
• R2:

172.16.16.0/29 *[IS-IS/160] 00:01:59, metric 43

> to 172.27.0.6 via ae0.0
172.16.20.0/24 *[IS-IS/160] 00:01:59, metric 43
> to 172.27.0.6 via ae0.0

172.16.21.0/24 *[IS-IS/160] 00:01:59, metric 43
> to 172.27.0.6 via ae0.0
• R3:

172.16.16.0/21 *[Aggregate/130] 5d 23:41:43

Reject
172.16.16.0/29 *[IS-IS/160] 00:02:01, metric 52
> to 172.27.0.14 via ge-0/0/1.0
172.16.20.0/24 *[IS-IS/160] 00:02:01, metric 52
> to 172.27.0.14 via ge-0/0/1.0
172.16.21.0/24 *[IS-IS/160] 00:02:01, metric 52
> to 172.27.0.14 via ge-0/0/1.0
• R4:

172.16.16.0/21 *[Aggregate/130] 5d 23:53:25

Reject
172.16.16.0/29 *[IS-IS/160] 00:02:03, metric 27
> to 172.27.0.10 via ae1.0
172.16.20.0/24 *[IS-IS/160] 00:02:03, metric 27
> to 172.27.0.10 via ae1.0
172.16.21.0/24 *[IS-IS/160] 00:02:03, metric 27
> to 172.27.0.10 via ae1.0
• R5:
The routing information is now present on all routers participating in Level 1, but it still is not
present on R5.
Question: Can you think of a possible reason why the routing

information is not present on R5?
Answer: There might be a problem with the route leaking

policies on R3 and R4.

• R3:
lab@R3# top edit policy-options policy-statement leak-routes term lvl-1-ext

lab@R3# show
from {
protocol aggregate;
level 1;
}
to level 2;
then accept;
• R4:
lab@R4# top edit policy-options policy-statement leak-routes term lvl-1-ext

lab@R4# show
from {
protocol aggregate;
level 1;
}
to level 2;
then accept;
Question: What is wrong with the route leaking policies?
Answer: Both policies are matching on level 1. The summary

route that is being leaked to Level 2 is an aggregate route. You
must remove the level 1 match condition from both policies.
Remove the level 1 match condition from the route leaking policies on R3 and R4. Then,
examine the routing table on R5 for the routing information.
• R3:
lab@R3# delete from level 1

lab@R3# commit
commit complete

• R4:
lab@R4# delete from level 1

lab@R4# commit
commit complete
• R5:

172.16.16.0/21 *[IS-IS/151] 00:01:44, metric 60

> to 172.27.0.26 via ge-0/0/1.0
The routing information is now present on R5. However, examining the IS-IS link-state database
reveals that R5 is only receiving the prefix from R3. R5 must receive the prefix from R3 and R4 to
satisfy the criteria of this task.
Note
If you committed the recent configuration
changes on R4 before R3 then the next hop
for the route would point out the ae2
interface. This is expected behavior and
does not cause a problem. Also, the IS-IS
link-state database outputs shown next
would be reversed.
Examining the routing tables on R3 and R4 reveals the problem.

• R5:
lab@R5# run show isis database R3 detail | match 172.16.16.0/21

• R3:

172.16.16.0/21 *[Aggregate/130] 6d 00:17:18

Reject

172.16.16.0/29 *[IS-IS/160] 00:33:17, metric 52
> to 172.27.0.14 via ge-0/0/1.0
172.16.20.0/24 *[IS-IS/160] 00:33:17, metric 52
> to 172.27.0.14 via ge-0/0/1.0
172.16.21.0/24 *[IS-IS/160] 00:33:17, metric 52
> to 172.27.0.14 via ge-0/0/1.0
• R4:

172.16.16.0/21 *[IS-IS/18] 00:15:03, metric 60

> to 172.27.0.17 via ge-0/0/5.0
[Aggregate/130] 6d 00:29:12
Reject
172.16.16.0/29 *[IS-IS/160] 00:33:32, metric 27
> to 172.27.0.10 via ae1.0
172.16.20.0/24 *[IS-IS/160] 00:33:32, metric 27
> to 172.27.0.10 via ae1.0
172.16.21.0/24 *[IS-IS/160] 00:33:32, metric 27
> to 172.27.0.10 via ae1.0
Question: After examining the routing tables on R3 and R4, can

you determine the problem?
Answer: R3 is advertising the aggregate route into Level 2.

Then, R4 receives the external IS-IS route from R3. This makes
the aggregate route on R4 ineligible to be processed by the
route leaking policy on R4. Then, R5 receives only one LSP with
the prefix. This process is reversed if you committed the
configuration on R4 before R3.
Question: What can you do to fix the problem?
Answer: You can fix this problem by setting the preference value
of the aggregate routes on R3 and R4 to a number below 18.

• R3:
lab@R3# top set routing-options aggregate route 172.16.16.0/21 preference 14

lab@R3# commit
commit complete
• R4:
lab@R4# top set routing-options aggregate route 172.16.16.0/21 preference 14

lab@R4# commit
commit complete
TASK VERIFICATION
To verify this task, examine the IS-IS link-state database to ensure R5 is receiving a copy of the
summary route from R3 and R4. Then, ping the 172.16.16.1 address to ensure communication.
Remember to source the ping from the loopback address of R5.
• R5:


!!



Lab
OSPF Troubleshooting
Overview
In this lab, you will be given a list of tasks specific to OSPF troubleshooting to accomplish in a
– Ensure that all OSPF adjacencies have reached the Full state. Any
adjacencies that require authentication must authenticate properly to reach the
Full state.
– Ensure that each router can reach the loopback address of all other routers in
the network.
– R4 has been unstable in the past and must remain overloaded. However, there
will be consistently over 1.5 Gbps of traffic coming from DC3 that will be using
R5. For this reason, ensure that R4 must be the primary exit of Area 2 for
unknown destinations.
– Most traffic exiting Area 1 is using R1 because of the stability problems of R4.
However, the 1 Gbps link between R1 and R2 cannot handle the load. Ensure
that R1 is used as the primary exit point for all IPv4 traffic in 
Area 1. However, IPv4 traffic cannot use R4 as the secondary exit point for the
area. Ensure that R4 is used as the primary exit point for all IPv6 traffic in Area
1. However, IPv6 traffic cannot use R1 as the secondary exit point for the area.
– Ensure that R2 can reach the destinations located on the T2 router; which are
in the 10.255.0.0/19 prefix range. You can ping the 10.255.3.1 addresses to
verify this step.
www.juniper.net OSPF Troubleshooting • Lab 5–1

Troubleshooting OSPF
In this lab part, you will examine and troubleshoot a malfunctioning network which has
incorporated OSPF as its IGP. You are given a list of criteria that your network must meet to
consider this lab part complete.
TASK 1
Ensure that all OSPF adjacencies have reached the Full state. Any
adjacencies that require authentication must authenticate properly
to reach the Full state.
Question: Must you consider both OSPFv2 and OSPFv3 for this
task?
Answer: Yes. The network has both OSPFv2 and OSPFv3

adjacencies that are not working properly. You must
troubleshoot all OSPF adjacency issues.
TASK INTERPRETATION
Examine each router’s OSPFv2 and OSPFv3 adjacencies. Troubleshoot any adjacency issues you
find until the adjacencies reach the Full state.
TASK COMPLETION
• R1:
R1 (ttyd0)
login: lab
Password:

lab@R1> configure
[edit]
172.27.0.9 ae1.0 Exchange 172.27.255.5 128 38
[edit]
172.27.255.5 ae1.0 Full 128 18
• R2:
R2 (ttyd0)
login: lab
Password:
Lab 5–2 • OSPF Troubleshooting www.juniper.net


lab@R2> configure
[edit]
[edit]
• R3:
R3 (ttyd0)
login: lab
Password:

lab@R3> configure
[edit]
172.27.0.18 ge-0/0/2.0 Full 172.27.255.5 128 27
172.27.0.25 ge-0/0/3.0 Full 172.27.255.5 128 27
[edit]
172.27.255.5 ge-0/0/2.0 Full 128 8
Neighbor-address fe80::5668:29ff:fe7a:8591
172.27.255.5 ge-0/0/3.0 Full 128 27
Neighbor-address fe80::5668:29ff:fe7a:b24d
• R4:
R4 (ttyd0)
login: lab
Password:

lab@R4> configure
[edit]
172.27.0.10 ae1.0 ExStart 172.27.255.1 128 34
172.27.0.17 ge-0/0/5.0 Full 172.27.255.3 128 29
[edit]

172.27.255.1 ae1.0 Full 128 19
172.27.255.3 ge-0/0/5.0 Full 128 8
Neighbor-address fe80::5668:29ff:fe7a:b48b
• R5:
R5 (ttyd0)
login: lab
Password:

lab@R5> configure
[edit]
172.27.0.26 ge-0/0/1.0 Full 172.27.255.3 128 27
[edit]
172.27.255.3 ge-0/0/1.0 Full 128 26
Neighbor-address fe80::5668:29ff:fe7a:9ac9
Question: What do the outputs reveal?
Answer: R1 shows that it has one OSPFv2 and one OSPFv3

adjacency, however the OSPFv2 adjacency is stuck in the
Exchange state.
R2 shows that no OSPF neighbors have been discovered.
R3 shows that it has two OSPFv2 and two OSPFv3 adjacencies
in the Full state. However, the OSPFv2 neighbors have the
same router ID.
R4 shows that it has two OSPFv2 and two OSPFv3 adjacencies.
However, one OSPFv2 adjacency is in the Exstart state.
R5 shows that it has one OSPFv2 and one OSPFv3 adjacency
with R3 that have reached the Full state.
Examine the OSPF interfaces by issuing the show ospf interface and show ospf3
interface commands.

• R1:
[edit]
ae1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/6.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 0
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
ge-0/0/3.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 0
[edit]
ae1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/6.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 0
ge-0/0/3.0 PtToPt 1.0.0.1 0.0.0.0 0.0.0.0 0
• R2:
[edit]
ae0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 0
ge-0/0/1.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 0
ge-0/0/2.0 DRother 0.0.0.1 0.0.0.0 0.0.0.0 0
lo0.0 DRother 0.0.0.1 0.0.0.0 0.0.0.0 0
[edit]
ae0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 0
ge-0/0/1.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 0
ge-0/0/2.0 DRother 0.0.0.1 0.0.0.0 0.0.0.0 0
• R3:
[edit]
ge-0/0/1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 0
ge-0/0/2.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
ge-0/0/3.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
[edit]
ge-0/0/1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 0
ge-0/0/2.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/3.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
• R4:
[edit]

ae1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/5.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
ae0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 0
ae2.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 0
[edit]
ae1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/5.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ae0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 0
ae2.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 0
• R5:
[edit]
ae2.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 0
ge-0/0/1.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
ge-0/0/5.0 DRother 0.0.0.2 0.0.0.0 0.0.0.0 0
lo0.0 DRother 0.0.0.2 0.0.0.0 0.0.0.0 0
[edit]
ae2.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 0
ge-0/0/1.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 1
ge-0/0/5.0 DRother 0.0.0.2 0.0.0.0 0.0.0.0 0
Answer: Every router has the correct interfaces in the correct

areas, except R1. The output on R1 displays that its ge-0/0/3
interface is in Area 1.0.0.1, or Area 16,777,217 for OSPFv3.
On R1, change Area 1.0.0.1 to Area 1 in OSPFv3. Then, examine its OSPFv3 adjacency states.
• R1:
[edit]
lab@R1# edit protocols ospf3

lab@R1# rename area 1.0.0.1 to area 1

lab@R1# commit

commit complete

172.27.255.5 ae1.0 Full 128 18
Question: Has the OSPFv3 adjacencies on R1 changed?
Answer: Unfortunately, changing the area number to the correct

value did not bring up the OSPFv3 adjacency between R1 and
R2. However, an area ID mismatch will cause an OSPF
adjacency to fail. Other adjacency issues must exist.
Monitor the traffic between R1 and R2 by issuing the monitor traffic interface
ge-0/0/3 detail no-resolve command.
• R1:
lab@R1# run monitor traffic interface ge-0/0/3 detail no-resolve
Listening on ge-0/0/3, capture size 1514 bytes
15:50:17.139129 In IP (tos 0xc0, ttl 1, id 41381, offset 0, flags [none], proto:

OSPF (89), length: 64) 172.27.0.2 > 224.0.0.5: OSPFv2, Hello, length 44
Router-ID 172.27.255.2, Area 0.0.0.1, Authentication Type: none (0)
Options [NSSA]
Hello Timer 15s, Dead Timer 30s, Mask 255.255.255.252, Priority 128
15:50:17.670581 In IP6 (class 0xc0, hlim 1, next-header: OSPF (89), length: 36)
fe80::5668:29ff:fe7a:ab5b > ff02::5: OSPFv3, Hello, length 36
Router-ID 172.27.255.2, Area 0.0.0.1
Options [V6, NSSA, Router]
Hello Timer 2s, Dead Timer 12s, Interface-ID 0.0.0.1, Priority 128
Neighbor List:
15:50:17.755673 Out IP6 (class 0xc0, hlim 1, next-header: OSPF (89), length: 36)
fe80::5668:29ff:fe7a:a0ed > ff02::5: OSPFv3, Hello, length 36
Router-ID 172.27.255.1, Area 0.0.0.1
Options [V6, External, Router]
Hello Timer 2s, Dead Timer 12s, Interface-ID 0.0.0.6, Priority 128
Neighbor List:
15:50:19.468151 Out IP (tos 0xc0, ttl 1, id 27951, offset 0, flags [none], proto:
Options [External]

Question: Is there anything in the output that can cause
adjacency issues?
Answer: Close inspection reveals that the Options field is

receiving an NSSA area type from R2. R1 is not configured as an
NSSA.
Question: Should R1 be configured as an NSSA area, or should

you remove the NSSA statement from R2?
Answer: It is currently impossible to tell at the moment if Area 1

should be an NSSA.
For now, remove the nssa statement from R2 for Area 1 under OSPFv2 and OSPFv3. Then
examine the OSPF adjacencies on R2.
• R2:
[edit]
lab@R2# edit protocols
[edit protocols]
lab@R2# delete ospf area 1 nssa
[edit protocols]
lab@R2# delete ospf3 area 1 nssa
[edit protocols]
lab@R2# commit
commit complete
[edit protocols]
172.27.0.6 ae0.0 Full 172.27.255.5 128 16
172.27.0.1 ge-0/0/1.0 Full 172.27.255.1 128 25
[edit protocols]
172.27.255.5 ae0.0 Full 128 31
172.27.255.1 ge-0/0/1.0 Full 128 10
Neighbor-address fe80::5668:29ff:fe7a:a0ed

Now that all the OSPF adjacencies have reached the Full state on R2, return to R1 and
troubleshoot the adjacency issue with R3 and R4.
Question: Which troubleshooting technique can you use to

determine the problem with the R1 to R4 OSPF adjacencies?
Answer: You can monitor the interface, or enable OSPF

traceoptions.
Although, monitoring the interface will allow you to discover the problem, traceoptions is also a
viable troubleshooting tool as well. Configure traceoptions on R1 for OSPFv2 and OSPFv3.
Configure the flag error detail and the flag hello detail statements under the
traceoptions.
• R1:
lab@R1# up 1
[edit protocols]
lab@R1# set ospf traceoptions file ospf-adj.log
[edit protocols]
lab@R1# set ospf traceoptions flag hello detail
[edit protocols]
lab@R1# set ospf traceoptions flag error detail
[edit protocols]
lab@R1# set ospf3 traceoptions file ospf-adj.log
[edit protocols]
lab@R1# set ospf3 traceoptions flag hello detail
[edit protocols]
lab@R1# set ospf3 traceoptions flag error detail
[edit protocols]
lab@R1# commit
commit complete
[edit protocols]
lab@R1# run show log ospf-adj.log | find 172.27.0.13
Jan 25 12:03:26.458628 OSPF rcvd Hello 172.27.0.13 -> 224.0.0.5 (ge-0/0/6.0 IFL 73
area 0.0.0.0)
Jan 25 12:03:26.458666 Version 2, length 44, ID 172.27.255.3, area 0.0.0.0
Jan 25 12:03:26.458685 checksum 0x0, authtype 1
Jan 25 12:03:26.458701 mask 255.255.255.0, hello_ivl 5, opts 0x2, prio 128
Jan 25 12:03:26.458718 dead_ivl 20, DR 0.0.0.0, BDR 0.0.0.0
Jan 25 12:03:26.458737 OSPF packet ignored: netmask 255.255.255.0 mismatch from
172.27.0.13 on intf ge-0/0/6.0 area 0.0.0.0

...
[edit protocols]
lab@R1# run show log ospf-adj.log | match fe80 | match ge-0/0/6
Jan 25 12:08:24.800280 OSPF rcvd Hello fe80::5668:29ff:fe7a:93b2 -> ff02::5 (ge-0/
0/6.0 IFL 73 area 0.0.0.0)
Jan 25 12:08:24.800382 OSPF packet ignored: hello interval mismatch 20 from
fe80::5668:29ff:fe7a:93b2 on intf ge-0/0/6.0 area 0.0.0.0
Jan 25 12:08:44.695623 OSPF rcvd Hello fe80::5668:29ff:fe7a:93b2 -> ff02::5 (ge-0/
0/6.0 IFL 73 area 0.0.0.0)
Jan 25 12:08:44.695733 OSPF packet ignored: hello interval mismatch 20 from
fe80::5668:29ff:fe7a:93b2 on intf ge-0/0/6.0 area 0.0.0.0
...
[edit protocols]
lab@R1# run show log ospf-adj.log | find 172.27.0.9
Jan 25 12:13:11.955362 OSPF restart signaling: Received DBD with LLS data from nbr
ip=172.27.0.9 id=172.27.255.5.
Jan 25 12:13:11.955398 OSPF restart signaling: Add LLS data for DbD packet on
interface ae1.0.
Jan 25 12:13:12.232777 OSPF hello from 172.27.255.5 (IFL 70, area 0.0.0.0) absorbed
...
Question: Why was the match condition of fe80 used to acquire

information?
Answer: R3 is using the link-local IPv6 address associated with

the ge-0/0/1 interface to source the OSPFv3 packets.
Question: What troubleshooting information did you gain from

the previous outputs?
Answer: The OSPFv2 adjacency is failing to form because R3’s

ge-0/0/1 interface is configured with a /24 netmask, it should
have a /30 netmask. The OSPFv3 adjacency is failing to form
because of a hello interval mismatch. However, a dead interval
of 60 seconds is also being received from R3. The current dead
interval value configured on R1 for that adjacency is 30
seconds. The hello and dead interval on R1 must be adjusted to
match R3’s configuration. The adjacency problem with R4 does
not show in the output.
Monitor the ae1 interface on R1 to discover the adjacency problem between R1 and R4.

• R1:
[edit protocols]
lab@R1# run monitor traffic interface ae1 detail no-resolve
Listening on ae1, capture size 1514 bytes
...
OSPF (89), length: 52) 172.27.0.9 > 224.0.0.5: OSPFv2, Database Description,
length 32
Router-ID 172.27.255.5, Backbone Area, Authentication Type: simple (1)
Simple text password: Juniper
Options [External, Opaque], DD Flags [Init, More, Master], MTU: 1496,
Sequence: 0xac1eecd6
OSPF (89), length: 112) 172.27.0.10 > 224.0.0.5: OSPFv2, Database Description,
length 92
Router-ID 172.27.255.1, Backbone Area, Authentication Type: simple (1)
Simple text password: Juniper
Options [External, Opaque], DD Flags [none], MTU: 1500, Sequence:
0xac1eecd6
Advertising Router 172.27.255.1, seq 0x80000043, age 1575s, length 28
Router LSA (1), LSA-ID: 172.27.255.1
Options: [External, Demand Circuit]
Summary LSA (3), LSA-ID: 172.27.0.0
Advertising Router 172.27.255.1, seq 0x8000001b, age 718s, length 16
External LSA (5), LSA-ID: 172.16.16.0
Question: What can you determine from the output?
Answer: It might be somewhat difficult to find the problem, but

if you look closely you will notice that the MTU value in the
incoming packet is different than the MTU value in the outgoing
packet.
Change the IPv4 netmask on R3’s ge-0/0/1 interface from /24 to /30. Next, change the
OSPFv3 hello-interval and dead-interval on R1’s ge-0/0/6 interface to 20 and 60,
respectively. Then change the family inet mtu value to 1496 on R1’s ae1 interface.
Alternatively, you can change the family inet mtu value on R4 to 1500. Examine the status
of the OSPF adjacencies once you have committed the configuration. Also, remember to
deactivate the traceoptions.
• R3:
[edit]
lab@R3# edit interfaces ge-0/0/1


lab@R3# show
mtu 4489;
unit 0 {
family inet {
mtu 3300;
address 172.27.0.13/24;
}
family inet6 {
mtu 4400;
address 2008:4489::d/126;
}
}

lab@R3# replace pattern 13/24 with 13/30

lab@R3# show
mtu 4489;
unit 0 {
family inet {
mtu 3300;
address 172.27.0.13/30;
}
family inet6 {
mtu 4400;
address 2008:4489::d/126;
}
}

lab@R3# commit
commit complete
• R1:
[edit protocols]
lab@R1# deactivate ospf traceoptions
[edit protocols]
lab@R1# deactivate ospf3 traceoptions
[edit protocols]
lab@R1# set ospf3 area 0 interface ge-0/0/6.0 hello-interval 20 dead-interval 60
[edit protocols]
lab@R1# top edit interfaces ae1.0
[edit interfaces ae1 unit 0]

lab@R1# show

family inet {
mtu 1500;
address 172.27.0.10/30;
}
family inet6 {
mtu 1500;
address 2008:4498::a/126;
}

lab@R1# set family inet mtu 1496

lab@R1# commit
commit complete

172.27.0.9 ae1.0 Full 172.27.255.5 128 37
172.27.0.13 ge-0/0/6.0 Full 172.27.255.3 128 15
172.27.0.2 ge-0/0/3.0 Full 172.27.255.2 128 27

172.27.255.5 ae1.0 Full 128 18
172.27.255.3 ge-0/0/6.0 Full 128 45
Neighbor-address fe80::5668:29ff:fe7a:93b2
172.27.255.2 ge-0/0/3.0 Full 128 11
Neighbor-address fe80::5668:29ff:fe7a:ab5b
Question: Do you notice anything strange with the OSPF

adjacency between R1 and R4? What does this mean?
Answer: The ID field displays the loopback address of R5. R1

does not have a direct connection to R5, which means R4 is
using an incorrect router ID.
Question: Could the incorrect router ID be the source of R4 and

R5 adjacency problems?
Answer: Yes. If R4 has the same router ID as R5 the OSPF

adjacencies cannot form.

Examine R4 and R5 for the source of the incorrect router ID. Correct any problems that you find.
• R5:
[edit]
lo0.0 up up inet 172.27.255.5 --> 0/0
inet6 ::172.27.255.5/32
fe80::5668:290f:fc7a:b8a3
• R4:
[edit]
lo0.0 up up inet 172.27.255.5 --> 0/0
inet6 ::172.27.255.4/32
fe80::5668:290f:fc7a:8eed
[edit]
lab@R4# delete interfaces lo0.0 family inet address 172.27.255.5/32
[edit]
lab@R4# set interfaces lo0.0 family inet address 172.27.255.4
[edit]
lab@R4# commit
commit complete
[edit]
172.27.0.10 ae1.0 Full 172.27.255.1 128 31
172.27.0.17 ge-0/0/5.0 Full 172.27.255.3 128 26
172.27.0.5 ae0.0 Full 172.27.255.2 128 18
[edit]
172.27.255.1 ae1.0 Full 128 16
172.27.255.3 ge-0/0/5.0 Full 128 9
172.27.255.2 ae0.0 Full 128 39
Neighbor-address fe80::5254:ff:fe00:c002
172.27.255.5 ae2.0 Exchange 128 37
Neighbor-address fe80::5254:ff:fe00:4b04
Changing the loopback address of R4 to the correct address did not solve the problem between
R4 and R5, but it is a step in the right direction. Monitor the ae2 interface on R4 to troubleshoot
this problem further.
• R4:

[edit]
lab@R4# run monitor traffic interface ae2.0 detail no-resolve
Listening on ae2.0, capture size 1514 bytes
17:09:18.074283 In IP6 (class 0xc0, hlim 1, next-header: OSPF (89), length: 28)
fe80::5254:ff:fe00:4b04 > ff02::5: OSPFv3, Database Description, length 28
Router-ID 172.27.255.5, Area 0.0.0.2
Options [V6, Router], DD Flags [Init, More, Master], MTU 1486, DD-Sequence
0xac1c26fb
17:09:18.075175 Out IP6 (class 0xc0, hlim 1, next-header: OSPF (89), length: 88)
fe80::5254:ff:fe01:4 > ff02::5: OSPFv3, Database Description, length 88
Router-ID 172.27.255.4, Area 0.0.0.2
Options [V6, Router], DD Flags [none], MTU 1500, DD-Sequence 0xac1c26fb
NSSA LSA (7), Area Local Scope, LSA-ID 0.0.0.1
Intra-Area Prefix LSA (9), Area Local Scope, LSA-ID 0.0.0.1
Link LSA (8), Link Local Scope, LSA-ID 0.0.0.4
...
Options [NSSA]
Options [NSSA]
Question: Can you determine the problem with the OSPFv2

adjacency?
Answer: The dead interval timers are mismatched. R4 has a

dead interval timer of 20 seconds, whereas R5 has a dead
interval timer of 40 seconds.
Question: Can you determine the problem with the OSPFv3

adjacency?
Answer: The MTU values are mismatched. R4 has its family

INET MTU value set to 1486 and R5 has its family INET MTU
value set to 1500.

Fix the OSPF adjacency problems by configuring matching dead interval values and matching
MTU values where applicable.
• R4:
[edit]
lab@R4# edit protocols ospf area 2

lab@R4# set interface ae2 dead-interval 40

lab@R4# commit
commit complete
• R5:
[edit]
lab@R5# edit interfaces ae2

lab@R5# show
mtu 1500;
lacp {
passive;
}
}
unit 0 {
family inet {
address 172.27.0.22/30;
}
family inet6 {
address 2008:4489::16/126;
}
}

lab@R5# set mtu 1514

lab@R5# commit
commit complete
• R4:
172.27.0.10 ae1.0 Full 172.27.255.1 128 35
172.27.0.17 ge-0/0/5.0 Full 172.27.255.3 128 26

172.27.0.5 ae0.0 Full 172.27.255.2 128 19
172.27.0.22 ae2.0 Full 172.27.255.5 128 37

172.27.255.1 ae1.0 Full 128 16
172.27.255.3 ge-0/0/5.0 Full 128 9
172.27.255.2 ae0.0 Full 128 33
172.27.255.5 ae2.0 Full 128 37
TASK VERIFICATION
To verify this task, examine the OSPFv2 and OSPFv3 adjacencies on each router. If all the
adjacencies reach the Full state, then the task is complete.
• R1:
172.27.0.9 ae1.0 Full 172.27.255.4 128 32
172.27.0.13 ge-0/0/6.0 Full 172.27.255.3 128 19
172.27.0.2 ge-0/0/3.0 Full 172.27.255.2 128 29

172.27.255.4 ae1.0 Full 128 16
172.27.255.3 ge-0/0/6.0 Full 128 50
Neighbor-address fe80::5668:29ff:fe7a:93b2
172.27.255.2 ge-0/0/3.0 Full 128 10
Neighbor-address fe80::5668:29ff:fe7a:ab5b
• R2:
[edit protocols]
172.27.0.6 ae0.0 Full 172.27.255.4 128 16
172.27.0.1 ge-0/0/1.0 Full 172.27.255.1 128 27
[edit protocols]
172.27.255.4 ae0.0 Full 128 39
172.27.255.1 ge-0/0/1.0 Full 128 10
Neighbor-address fe80::5668:29ff:fe7a:a0ed

• R3:
172.27.0.14 ge-0/0/1.0 Full 172.27.255.1 128 17
172.27.0.18 ge-0/0/2.0 Full 172.27.255.4 128 26
172.27.0.25 ge-0/0/3.0 Full 172.27.255.5 128 25

172.27.255.1 ge-0/0/1.0 Full 128 47
Neighbor-address fe80::5668:29ff:fe7a:8e3a
172.27.255.4 ge-0/0/2.0 Full 128 8
Neighbor-address fe80::5668:29ff:fe7a:8591
172.27.255.5 ge-0/0/3.0 Full 128 28
Neighbor-address fe80::5668:29ff:fe7a:b24d
• R4:
172.27.0.10 ae1.0 Full 172.27.255.1 128 35
172.27.0.17 ge-0/0/5.0 Full 172.27.255.3 128 29
172.27.0.5 ae0.0 Full 172.27.255.2 128 16
172.27.0.22 ae2.0 Full 172.27.255.5 128 36

172.27.255.1 ae1.0 Full 128 19
172.27.255.3 ge-0/0/5.0 Full 128 8
172.27.255.2 ae0.0 Full 128 35
172.27.255.5 ae2.0 Full 128 36
• R5:
172.27.0.21 ae2.0 Full 172.27.255.4 128 38
172.27.0.26 ge-0/0/1.0 Full 172.27.255.3 128 25

172.27.255.4 ae2.0 Full 128 39

172.27.255.3 ge-0/0/1.0 Full 128 26
Neighbor-address fe80::5668:29ff:fe7a:9ac9
TASK 2
Ensure that each router can reach the loopback address of all other
routers in the network.
TASK INTERPRETATION
In this task, you must ensure that all routers can communicate with each other’s loopback
addresses. If any problems arise, troubleshoot them until they are resolved.
TASK COMPLETION
• R1:
lab@R1# run ping 172.27.255.2 rapid count 2
PING 172.27.255.2 (172.27.255.2): 56 data bytes
!!
--- 172.27.255.2 ping statistics ---

PING 172.27.255.3 (172.27.255.3): 56 data bytes
!!
--- 172.27.255.3 ping statistics ---

PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!
--- 172.27.255.4 ping statistics ---

PING 172.27.255.5 (172.27.255.5): 56 data bytes
!!
--- 172.27.255.5 ping statistics ---
• R2:
[edit protocols]
PING 172.27.255.1 (172.27.255.1): 56 data bytes
4 5 00 0054 a5b5 0 0000 01 01 bcb6 172.27.0.5 172.27.255.1
.36 bytes from 172.27.0.26: Time to live exceeded
4 5 00 0054 a5b7 0 0000 01 01 bcb4 172.27.0.5 172.27.255.1
.
--- 172.27.255.1 ping statistics ---
[edit protocols]
PING 172.27.255.3 (172.27.255.3): 56 data bytes
!!
--- 172.27.255.3 ping statistics ---
[edit protocols]
PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!
--- 172.27.255.4 ping statistics ---
[edit protocols]
PING 172.27.255.5 (172.27.255.5): 56 data bytes
!!
--- 172.27.255.5 ping statistics ---
• R3:
PING 172.27.255.1 (172.27.255.1): 56 data bytes
4 5 00 0054 380c 0 0000 01 01 29fe 172.27.0.103 172.27.255.1
4 5 00 0054 380d 0 0000 01 01 29fd 172.27.0.103 172.27.255.1
.
--- 172.27.255.1 ping statistics ---

PING 172.27.255.2 (172.27.255.2): 56 data bytes
!!
--- 172.27.255.2 ping statistics ---


PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!
--- 172.27.255.4 ping statistics ---

PING 172.27.255.5 (172.27.255.5): 56 data bytes
!!
--- 172.27.255.5 ping statistics ---
• R4:
PING 172.27.255.1 (172.27.255.1): 56 data bytes
4 5 00 0054 a2b2 0 0000 01 01 bfac 172.27.0.18 172.27.255.1
4 5 00 0054 a2b3 0 0000 01 01 bfab 172.27.0.18 172.27.255.1
.
--- 172.27.255.1 ping statistics ---

PING 172.27.255.2 (172.27.255.2): 56 data bytes
!!
--- 172.27.255.2 ping statistics ---

PING 172.27.255.3 (172.27.255.3): 56 data bytes
!!
--- 172.27.255.3 ping statistics ---

PING 172.27.255.5 (172.27.255.5): 56 data bytes
!!
--- 172.27.255.5 ping statistics ---

• R5:
PING 172.27.255.1 (172.27.255.1): 56 data bytes
4 5 00 0054 49ee 0 0000 01 01 186a 172.27.0.25 172.27.255.1
4 5 00 0054 49f2 0 0000 01 01 1866 172.27.0.25 172.27.255.1
.
--- 172.27.255.1 ping statistics ---

PING 172.27.255.2 (172.27.255.2): 56 data bytes
!!
--- 172.27.255.2 ping statistics ---

PING 172.27.255.3 (172.27.255.3): 56 data bytes
!!
--- 172.27.255.3 ping statistics ---

PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!
--- 172.27.255.4 ping statistics ---
Question: Do the ping tests reveal any problems?
Answer: There seems to be a routing loop between the loopback

address of R1 and every other router in the network.

Question: What can you do to troubleshoot the routing loop?
Answer: Issue traceroutes from various routers to pinpoint the

area in which the loop is occurring. Then, examine the
necessary routing tables to determine how to fix whatever is
causing the loop.
Issuing a traceroute from any router helps pinpoint the area in which the routing loop is
occurring.
• R2:
[edit protocols]
lab@R2# run traceroute 172.27.255.1
traceroute to 172.27.255.1 (172.27.255.1), 30 hops max, 40 byte packets
1 172.27.0.1 (172.27.0.1) 8.902 ms 8.087 ms 8.137 ms
2 172.27.0.13 (172.27.0.13) 9.504 ms 10.524 ms 13.744 ms
3 172.27.0.105 (172.27.0.105) 10.694 ms 11.224 ms 11.853 ms
4 172.27.0.26 (172.27.0.26) 8.692 ms 14.503 ms 8.565 ms
5 172.27.0.105 (172.27.0.105) 12.784 ms 14.159 ms 13.812 ms
...
29 172.27.0.105 (172.27.0.105) 40.676 ms 36.593 ms 37.463 ms
30 172.27.0.26 (172.27.0.26) 36.736 ms 21.349 ms 23.143 ms
Question: Where is the routing loop occurring?
Answer: The traffic is going to R1, R3, R5, and back to R3. The
routing loop is occurring between R3 and R5.
Examine the routing tables of R2, R3, and R5 to gather more information on the routing loop.
• R2:
[edit protocols]

172.27.255.0/30 *[OSPF/150] 00:06:29, metric 2, tag 0

> to 172.27.0.1 via ge-0/0/1.0
• R3:

172.27.255.0/30 *[RIP/100] 2d 05:43:15, metric 2, tag 0

> to 172.27.0.105 via ge-0/0/4.0
• R5:

172.27.255.0/30 *[OSPF/150] 00:27:52, metric 2, tag 0

> to 172.27.0.26 via ge-0/0/1.0
Question: What do the previous outputs reveal?
Answer: R3 is receiving the 172.27.255.0/30 route from DC3

through RIP. It is then redistributing the route into OSPF. The
other routers in the network are using this routing information in
an attempt to reach the 172.27.255.1 address.
Question: Can you determine why R2 and R3 do not have a host

route for the loopback address of R1?
Answer: R2 and R3 are not receiving a /32 prefix for the

loopback address of R1. This means that it is not a route
preference issue, or an unwittingly implemented routing policy.
There might be a problem on R1 that is restricting the router
from advertising the proper route.
Examine R1 to ensure that it is properly advertising its loopback address into the network. Fix
any problems that you might find.
• R1:
lab@R1# run show ospf interface lo0.0 detail
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0

Auth type: None
Question: Can you determine the problem from the previous

output?
Answer: If you examine the previous output closely you might

notice that the Address field lists the 172.27.25.1 address.
This means the loopback interface on R1 is configured with the
incorrect address.
• R1:
lab@R1# up 2 edit lo0.0
[edit interfaces lo0 unit 0]

lab@R1# show
family inet {
address 172.27.25.1/32;
}
family inet6 {
address ::172.27.255.1/32;
}

lab@R1# replace pattern 25.1 with 255.1

lab@R1# show
family inet {
address 172.27.255.1/32;
}
family inet6 {
address ::172.27.255.1/32;
}

lab@R1# commit
commit complete
TASK VERIFICATION
This task is complete when each router can reach the loopback address of every other router in
the internal network.

• R1:
PING 172.27.255.2 (172.27.255.2): 56 data bytes
!!
--- 172.27.255.2 ping statistics ---

PING 172.27.255.3 (172.27.255.3): 56 data bytes
!!
--- 172.27.255.3 ping statistics ---

PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!
--- 172.27.255.4 ping statistics ---

PING 172.27.255.5 (172.27.255.5): 56 data bytes
!!
--- 172.27.255.5 ping statistics ---
• R2:
[edit protocols]
PING 172.27.255.1 (172.27.255.1): 56 data bytes
!!
--- 172.27.255.1 ping statistics ---
[edit protocols]
PING 172.27.255.3 (172.27.255.3): 56 data bytes
!!
--- 172.27.255.3 ping statistics ---

[edit protocols]
PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!
--- 172.27.255.4 ping statistics ---
[edit protocols]
PING 172.27.255.5 (172.27.255.5): 56 data bytes
!!
--- 172.27.255.5 ping statistics ---
• R3:
PING 172.27.255.1 (172.27.255.1): 56 data bytes
!!
--- 172.27.255.1 ping statistics ---

PING 172.27.255.2 (172.27.255.2): 56 data bytes
!!
--- 172.27.255.2 ping statistics ---

PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!
--- 172.27.255.4 ping statistics ---

PING 172.27.255.5 (172.27.255.5): 56 data bytes
!!
--- 172.27.255.5 ping statistics ---
• R4:

PING 172.27.255.1 (172.27.255.1): 56 data bytes
!!
--- 172.27.255.1 ping statistics ---

PING 172.27.255.2 (172.27.255.2): 56 data bytes
!!
--- 172.27.255.2 ping statistics ---

PING 172.27.255.3 (172.27.255.3): 56 data bytes
!!
--- 172.27.255.3 ping statistics ---

PING 172.27.255.5 (172.27.255.5): 56 data bytes
!!
--- 172.27.255.5 ping statistics ---
• R5:
PING 172.27.255.1 (172.27.255.1): 56 data bytes
!!
--- 172.27.255.1 ping statistics ---

PING 172.27.255.2 (172.27.255.2): 56 data bytes
!!
--- 172.27.255.2 ping statistics ---

PING 172.27.255.3 (172.27.255.3): 56 data bytes
!!
--- 172.27.255.3 ping statistics ---


PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!
--- 172.27.255.4 ping statistics ---
TASK 3
R4 has been unstable in the past and must remain overloaded.
However, there will be consistently over 1.5 Gbps of traffic coming
from DC3 that will be using R5. For this reason, ensure that R4 must
be the primary exit of area 2 for unknown destinations.
Question: What is the result of a router being in the overloaded

mode?
Answer: When a router is overloaded it advertises any prefix

that is reachable through it with the maximum metric. This
causes other routers to forward traffic around the overloaded
router if there is another path to the destination that does not
lead through the overloaded router.
TASK INTERPRETATION
To complete this task you must configure Area 2 to use R4 as the primary exit for any unknown
destinations. This task is complicated by the criterion that R4 must remain in the overloaded
state. You must configure Area 2 to use R4 for any traffic for which R5 does not have specific
routing information. Note that this task applies to OSPFv2 and OSPFv3.
TASK COMPLETION
Begin this task by examining the default routes on R5 in the routing table. Then, examine the
default LSAs in the OSPF link-state database.
• R5:
lab@R5# run show route 0/0 exact detail

0.0.0.0/0 (1 entry, 1 announced)
*OSPF Preference: 150
Next hop: 172.27.0.26 via ge-0/0/1.0, selected
Age: 58:31 Metric: 5100 Tag: 0
Task: OSPF
Announcement bits (1): 0-KRT
AS path: I

lab@R5# run show route ::/0 exact detail

::/0 (1 entry, 1 announced)
*OSPF3 Preference: 150
Next hop: fe80::5668:29ff:fe7a:9ac9 via ge-0/0/1.0, selected
Age: 7:03:12 Metric: 5040 Tag: 0
Task: OSPF3
Announcement bits (1): 0-KRT
AS path: I

lab@R5# run show ospf database lsa-id 0.0.0.0 detail
OSPF database, Area 0.0.0.2

NSSA 0.0.0.0 172.27.255.3 0x80000008 1764 0x20 0x7550 36
mask 0.0.0.0
Topology default (ID 0)
Type: 1, Metric: 5000, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
NSSA 0.0.0.0 172.27.255.4 0x80000009 553 0x20 0xf9e3 36
mask 0.0.0.0
Topology default (ID 0)
Type: 2, Metric: 1, Fwd addr: 0.0.0.0, Tag: 0.0.0.0

lab@R5# run show ospf3 database lsa-id 0.0.0.0 detail
OSPF3 database, Area 0.0.0.2

Router 0.0.0.0 172.27.255.3 0x8000000c 168 0x9194 40
bits 0x3, Options 0x39
Type PointToPoint (1), Metric 40
Loc-If-Id 3, Nbr-If-Id 4, Nbr-Rtr-Id 172.27.255.5
Type: PointToPoint, Node ID: 172.27.255.5, Metric: 40, Bidirectional
Router 0.0.0.0 172.27.255.4 0x80000005 1857 0x1a39 40
bits 0x3, Options 0x39
Type PointToPoint (1), Metric 65535
Loc-If-Id 3, Nbr-If-Id 5, Nbr-Rtr-Id 172.27.255.5
Type: PointToPoint, Node ID: 172.27.255.5, Metric: 65535, Bidirectional

Answer: The outputs show that R5 is receiving default LSAs

from R3 and R4. The default LSAs R5 is receiving from R3
shows a higher metric value than the default LSAs R5 is
receiving from R4. R3’s default LSA for OSPFv2 has a metric
type value of 1; whereas R4’s default LSA for OSPFv2 has a
metric type value of 2. Although the metric type for the OSPFv3
default LSAs is not shown, it is safe to suspect that the metric
type of the default LSAs is also the problem for OSPFv3.
Question: Why is R5 preferring the default routes from R3 over

the default routes from R4?
Answer: R5 is not preferring the default routes from R3 because

R4 is overloaded. It is only preferring the default routes from R3
because they have a metric type value of 1.
On R4 in Area 2, change the metric type value for the default LSA to 1 for OSPFv2 and OSPFv3.
Alternatively, you can simply remove the default-type statement and R4 will advertise the
default LSA with a Type 1 metric.
• R4:
lab@R4# show
nssa {
default-lsa {
default-metric 1;
metric-type 2;
type-7;
}
no-summaries;
}
area-range 10.255.0.0/19 restrict;
interface ae2.0 {
interface-type p2p;
hello-interval 5;
dead-interval 40;
}

lab@R4# set nssa default-lsa metric-type 1


lab@R4# up 2 edit ospf3 area 2
[edit protocols ospf3 area 0.0.0.2]

lab@R4# show
nssa {
default-lsa {
default-metric 1;
metric-type 2;
type-7;
}
no-summaries;
}
interface ae2.0 {
interface-type p2p;
hello-interval 5;
dead-interval 40;
}

lab@R4# set nssa default-lsa metric-type 1

lab@R4# commit
commit complete
TASK VERIFICATION
To verify this task, examine the routing table on R5. If the default route points towards R4, then
this task is complete.
• R5:

0.0.0.0/0 *[OSPF/150] 01:04:16, metric 51, tag 0

> to 172.27.0.21 via ae2.0

lab@R5# run show route ::/0 exact

::/0 *[OSPF3/150] 00:01:25, metric 21, tag 0

> to fe80::5254:ff:fe01:4 via ae2.0

TASK 4
Most traffic exiting area 1 is using R1 because of the stability
problems of R4. However, the 1 Gbps link between R1 and R2 cannot
handle the load. Ensure that R1 is used as the primary exit point
for all IPv4 traffic in area 1. However, IPv4 traffic cannot use R4
as the secondary exit point for the area. Ensure that R4 is used as
the primary exit point for all IPv6 traffic in area 1. However, IPv6
traffic cannot use R1 as the secondary exit point for the area.
Question: Why is most of the traffic using R1 to leave Area 1?
Answer: R4 is currently in the overloaded mode. R1 is seen as

the preferred path.
TASK INTERPRETATION
Completing this task requires you to turn Area 1 into a totally stubby area. Configuring only a
stub area might satisfy the criteria of this task, however a totally stubby area will force more
traffic to use the designated ABR.
TASK COMPLETION
To complete this task, configure R1 and R4 as ABRs for Area 1. Then configure Area 1 to be a
NSSA area. Next, configure R1 as the primary exit point for IPv4 traffic by using the
no-summaries and default-metric commands under Area 1 in OSPFv2. When
configuring Area 1 under OSPFv3 on R1, set the no-summaries command but omit the
default-metric command. Then, configure R4 as the primary exit point for IPv6 traffic by
using the no-summaries and default-metric commands under Area 1 in OSPFv3. When
configuring Area 1 under OSPFv2 on R4 set the no-summaries command but omit the
default-metric command.
Remember to configure R2 as a NSSA router within Area 1. Forgetting to do so causes R2 to lose
all of its OSPF adjacencies.
• R1:
lab@R1# top edit protocols ospf area 1

lab@R1# set nssa no-summaries default-lsa default-metric 10

lab@R1# show
nssa {
default-lsa default-metric 10;
no-summaries;
}
interface-type p2p;
hello-interval 15;
dead-interval 30;
}


lab@R1# set nssa no-summaries

lab@R1# show
nssa no-summaries;
interface-type p2p;
hello-interval 2;
dead-interval 12;
}

lab@R1# commit
commit complete
• R4:

lab@R4# set nssa no-summaries

lab@R4# show
nssa no-summaries;
interface ae0.0 {
interface-type p2p;
hello-interval 5;
dead-interval 20;
}


lab@R4# set nssa no-summaries default-lsa default-metric 10

lab@R4# show
nssa {
default-lsa default-metric 10;
no-summaries;
}
interface ae0.0 {
interface-type p2p;
hello-interval 10;
dead-interval 40;
}

lab@R4# commit
commit complete
• R2:
[edit protocols]
lab@R2# set ospf area 1 nssa
[edit protocols]
lab@R2# set ospf3 area 1 nssa
[edit protocols]
lab@R2# commit
commit complete
TASK VERIFICATION
To verify this task, examine the inet.0 and inet6.0 routing tables on R2. If R1 is the primary exit
point for IPv4 traffic, and R4 is the primary exit point for all IPv6 traffic, the task is complete.
• R2:
[edit protocols]
lab@R2# run show route protocol ospf table inet.0


0.0.0.0/0 *[OSPF/10] 00:00:04, metric 110

> to 172.27.0.1 via ge-0/0/1.0
172.16.16.0/21 *[OSPF/150] 00:00:04, metric 0, tag 0
> to 172.27.0.1 via ge-0/0/1.0
224.0.0.5/32 *[OSPF/10] 01:31:41, metric 1
MultiRecv
[edit protocols]
lab@R2# run show route protocol ospf table inet6.0

::/0 *[OSPF3/10] 00:01:44, metric 110

> to fe80::5254:ff:fe01:2 via ae0.0
2008:4489::4/126 *[OSPF3/10] 00:01:44, metric 113
> to fe80::5254:ff:fe01:2 via ae0.0
ff02::5/128 *[OSPF3/10] 2d 14:12:40, metric 1
MultiRecv

TASK 5
Ensure that R2 can reach the destinations located on the T2 router,
which are in the 10.255.0.0/19 prefix range. You can ping the
10.255.3.1 addresses to verify this step.
TASK INTERPRETATION
This task requires you to ensure communication between R2 and the destinations located on T2;
which are in the 10.255.0.0/19 prefix range.
TASK COMPLETION
Examine the routing table on R2 to determine if it has the routing information to reach the
destinations located on T2. Then, attempt to communicate with the 10.255.3.1 address from
R2.
• R2:
[edit protocols]

0.0.0.0/0 *[OSPF/10] 15:42:40, metric 110

> to 172.27.0.1 via ge-0/0/1.0
[edit protocols]
lab@R2# run ping 10.255.3.1 count 2
PING 10.255.3.1 (10.255.3.1): 56 data bytes
36 bytes from 172.27.0.1: Destination Net Unreachable
4 5 00 0054 9eb8 0 0000 40 01 21d4 172.27.0.2 10.255.3.1
36 bytes from 172.27.0.1: Destination Net Unreachable

4 5 00 0054 9eba 0 0000 40 01 21d2 172.27.0.2 10.255.3.1

Question: What can you determine from the outputs?
Answer: R2 is using its default route to send traffic towards the

10.255.3.1 address. However, R1 is telling R2 that it does not
have any routing information for this prefix.
Examine the routing table on R1, R3, and R4 to gain further insight on the problem.

• R1:
• R3:

10.255.3.0/24 *[OSPF/150] 20:53:02, metric 0, tag 0

> to 172.27.0.25 via ge-0/0/3.0
• R4:

10.255.3.0/24 *[OSPF/150] 20:52:55, metric 0, tag 0

> to 172.27.0.22 via ae2.0
Question: Can you determine why R1 does not have this prefix
in its routing table?
Answer: From the previous outputs it is not possible to

determine why R1 does not have the prefix.
Take a close look at the OSPFv2 Area 2 configuration on R3 and R4.

• R3:
lab@R3# top edit protocols ospf area 2

lab@R3# show
nssa {
default-lsa {
default-metric 5000;
metric-type 1;
type-7;
}
no-summaries;
}

interface-type p2p;
hello-interval 5;
dead-interval 30;
}
• R4:


lab@R4# show
nssa {
default-lsa {
default-metric 1;
metric-type 1;
type-7;
}
no-summaries;
}
interface ae2.0 {
interface-type p2p;
hello-interval 5;
dead-interval 40;
}
Question: Can you determine what the problem is from the

previous outputs?
Answer: There is an area range command that is restricting any

prefix in the 10.255.0.0/19 range from being flooded out of
Area 2.
Remove the restrict statement at the end of the area-range statement on R3 and R4.
Doing this allows the 10.255.0.0/19 prefix to be flooded into Area 0.
• R3:
lab@R3# delete nssa area-range 10.255.0.0/19 restrict

lab@R3# show
nssa {
default-lsa {
default-metric 5000;
metric-type 1;
type-7;

}
no-summaries;
area-range 10.255.0.0/19;
}
interface-type p2p;
hello-interval 5;
dead-interval 30;
}
lab@R3# commit
commit complete
• R4:
lab@R4# delete nssa area-range 10.255.0.0/19 restrict

lab@R4# show
nssa {
default-lsa {
default-metric 1;
metric-type 1;
type-7;
}
no-summaries;
area-range 10.255.0.0/19;
}
interface ae2.0 {
interface-type p2p;
hello-interval 5;
dead-interval 40;
}

lab@R4# commit
commit complete
TASK VERIFICATION
To verify this task, ping the 10.255.3.1 address from R2. If R2 can communicate with the
10.255.3.1 address then the task is complete.
• R2:
[edit protocols]
PING 10.255.3.1 (10.255.3.1): 56 data bytes
!!


Jncie-Sp-12.a LG v1

Uploaded by

Copyright:

Available Formats

Jncie-Sp-12.a LG v1

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

Jncie-Sp-12.a LG v1

Uploaded by

Copyright:

Available Formats

JNCIE Service Provider Bootcamp

Worldwide Education Services

1133 Innovation Way

Course Number: EDU-JUN-JNCIE-SP

Lab 2: IS-IS Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Lab 3: OSPF Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Lab 4: IS-IS Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Lab 5: OSPF Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

www.juniper.net Contents • iii

www.juniper.net Course Overview • v

vi • Course Agenda www.juniper.net

CLI and GUI Text

Style Description Usage Example

Courier New Console text:

Input Text Versus Output Text

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxp0,

Defined and Undefined Syntax Variables

Style Description Usage Example

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

www.juniper.net Document Conventions • vii

Education Services Offerings

viii • Additional Information www.juniper.net

www.juniper.net Implementing Device Infrastructure • Lab 1–1

Lab 1–2 • Implementing Device Infrastructure www.juniper.net

Implementing Device Infrastructure

Make sure you read through all tasks

Question: On which routers is it necessary to configure

Answer: The lab diagram shows that it is necessary to configure

www.juniper.net Implementing Device Infrastructure • Lab 1–3

Answer: First, set the Ethernet aggregated device count to

--- JUNOS 12.3I20130406_1317_anjali (kernel) #1: 2013-04-06 13:40:14 UTC

Lab 1–4 • Implementing Device Infrastructure www.juniper.net

[edit interfaces ae1]

[edit interfaces ae1]

--- JUNOS 12.3I20130406_1317_anjali (kernel) #1: 2013-04-06 13:40:14 UTC

[edit interfaces ae0]

[edit interfaces ae0]

www.juniper.net Implementing Device Infrastructure • Lab 1–5

[edit interfaces ae0]

--- JUNOS 12.3I20130406_1317_anjali (kernel) #1: 2013-04-06 13:40:14 UTC

[edit interfaces ae0]

[edit interfaces ae0]

Lab 1–6 • Implementing Device Infrastructure www.juniper.net

[edit interfaces ae1]

[edit interfaces ae1]

[edit interfaces ae2]

[edit interfaces ae2]

www.juniper.net Implementing Device Infrastructure • Lab 1–7

--- JUNOS 12.3I20130406_1317_anjali (kernel) #1: 2013-04-06 13:40:14 UTC

Lab 1–8 • Implementing Device Infrastructure www.juniper.net

[edit interfaces ae2]

[edit interfaces ae2]

[edit interfaces ae2]

www.juniper.net Implementing Device Infrastructure • Lab 1–9

--- 172.27.0.5 ping statistics ---

--- 172.27.0.10 ping statistics ---

--- 172.27.0.22 ping statistics ---

Question: Which feature allows for the monitoring of member