JNCIE SP 10.b - LGD

JNCIE Service Provider Bootcamp
10.b
Detailed Lab Guide
Worldwide Education Services
1194 North Mathilda Avenue

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 Detailed Lab Guide, Revision 10.b
Copyright © 2012 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 10.a—September 2011
Revision 10.b—March 2012
The information in this document is current as of the date listed above.
The information in this document has been carefully verified and is believed to be accurate for software Release 10.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 (Detailed) . . . . . . . . . . . . . . . . . . . . . . . 1-1
Part 1: Implementing Device Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Lab 2: IS-IS Implementation (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Part 1: Implementing IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Lab 3: OSPF Implementation (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Part 1: Implementing OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Lab 4: IS-IS Troubleshooting (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Part 1: Troubleshooting IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Lab 5: OSPF Troubleshooting (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Part 1: Troubleshooting OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Lab 6: BGP Implementation (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Part 1: Implementing BGP with Route Reflectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Part 2: Implementing IBGP with Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-75
Lab 7: BGP Troubleshooting (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Part 1: Troubleshooting and Repairing BGP Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Lab 8: Multicast Implementation and Troubleshooting (Detailed) . . . . . . . . . . . . . 8-1

Part 1: Configuring PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Lab 9: Class of Service Implementation and Troubleshooting (Detailed) . . . . . . . . 9-1

Part 1: Configuring CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
Lab 10: MPLS Implementation and Troubleshooting (Detailed) . . . . . . . . . . . . . . . 10-1

Part 1: Configuring LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
Lab 11: MPLS VPNs Implementation and Troubleshooting (Detailed) . . . . . . . . . . 11-1

Part 1: Configuring Layer 3 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
Appendix A: Lab Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
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 virtual lab devices and are available after hours for additional practice
time. This course is based on Junos OS Release 10.3.
Objectives
After successfully completing this course:
• Students will be better prepared for success in taking the actual JNCIE-SP exam.
• Students will 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
Lab 1: Implementing Device Infrastructure
Chapter 4: IGP Implementation
Lab 2 and Lab 3: IGP Implementation
Day 2
Chapter 5: IGP Troubleshooting
Lab 4 and Lab 5: IGP Troubleshooting
Chapter 6: BGP Implementation
Lab 6: BGP Implementation
Chapter 7: BGP Troubleshooting
Lab 7: BGP Troubleshooting
Day 3
Chapter 8: Multicast Implementation
Lab 8: Multicast Implementation and Troubleshooting
Chapter 9: Class of Service Implementation
Lab 9: Class of Service Implementation and Troubleshooting
Day 4
Chapter 10: MPLS Implementation
Lab 10: MPLS Implementation and Troubleshooting
Chapter 11: MPLS VPN Implementation
Lab 11: MPLS VPNs Implementation and Troubleshooting
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 chapter text according to the following table.
Style Description Usage Example
Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
Courier New Console text:

commit complete
• Screen captures
• Noncommand-related Exiting configuration mode
syntax
GUI text elements:
Select File > Open, and then click
• Menu names Configuration.conf in the
Filename text box.
• Text field entry
Input Text Versus Output Text

You will also frequently see cases where you must enter input text yourself. Often these instances
will be shown in the context of where you must enter them. We use bold style to distinguish text
that is input versus text that is simply displayed.
Normal CLI No distinguishing variant. Physical interface:fxp0,

Enabled
Normal GUI
View configuration history by clicking
Configuration > History.
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
config.ini in the Filename field.
Defined and Undefined Syntax Variables

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

CLI Variable Text where variable value is already policy my-peers
assigned.
GUI Variable Click my-peers in the dialog.
CLI Undefined Text where the variable’s value is Type set policy policy-name.
the user’s discretion or text where
ping 10.0.x.y
the variable’s value as shown in
GUI Undefined the lab guide might differ from the Select File > Save, and type
value the user must input filename in the Filename field.
according to the lab topology.
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 Detailed Lab Guide was developed and tested using the
Junos software Release 10.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 1
Implementing Device Infrastructure (Detailed)
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.
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.
By completing this lab, you will perform the following tasks:
• 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.
• 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 1 diagram for the
specific interfaces and virtual IP addresses.
www.juniper.net Implementing Device Infrastructure (Detailed) • Lab 1–1

10.b.10.3
• 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.
• Configure all internal routers to communicate with the RADIUS server
located at 172.27.155.1 using the secret key of Juniper.
• 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 and maintenance commands
for troubleshooting.
• 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.
Lab 1–2 • Implementing Device Infrastructure (Detailed) www.juniper.net

• 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. Use the root username with the password
Clouds to log in to the internal server to examine these files.
• 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.

Part 1: 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.
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 1 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 10.3-20110523_pvt_predator_a.0 built 2011-05-23 04:17:01 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/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
inet6 fe80::5668:290f:fc7a:9f2b
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 1 diagram for the specific
interfaces and virtual IP addresses.
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

1]
lab@R3# set no-preempt

1]
lab@R3# set virtual-address 172.20.20.100

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

1]

1]

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

}

1]
lab@R3# commit
commit complete
• R5:

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

1]

1]

1]
lab@R5# show
priority 100;

1]
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:
1]
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:
1]
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:
1]
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
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:
1]
[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 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 support-class
[edit system login]

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: 2011-06-27 18:35:58 UTC by lab
version 10.3D0;
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.101 ge-0/0/9.0 Full 172.27.0.50 128 37

[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
Jun 29 02:34:21 R2 clear-log[61969]: logfile cleared
Jun 29 02:35:24 R2 fwdd[1082]: PFE_FW_SYSLOG_IP: FW: ge-0/0/2.0 D icmp
172.27.0.38 172.27.0.37 8 0 (1 packets)
172.27.0.38 172.27.0.37 8 0 (1 packets)
Jun 29 02:35:42 R2 fwdd[1082]: PFE_FW_SYSLOG_IP6_ICMP: FW: ge-0/0/2.0 D
icmpv6 SA 820:9844:9844:0:0:0:0:200 DA 2ff:0:0:0:0:100:ff:100 type 135
code 0 (1 packets)
Jun 29 02:35:44 R2 last message repeated 2 times
• R5:
lab@R5# run show log int-src-violations
Jun 29 02:36:02 R5 clear-log[67535]: logfile cleared
172.27.0.58 172.27.0.57 8 0 (1 packets)
172.27.0.58 172.27.0.57 8 0 (1 packets)
Jun 29 02:37:39 R5 fwdd[1155]: PFE_FW_SYSLOG_IP6_ICMP: FW: ge-0/0/5.0 D
icmpv6 SA 820:9844:0:0:0:0:0:200 DA 2ff:0:0:0:0:100:ff:100 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
Jun 29 18:37:52 R4 mgd[41976]: UI_CFG_AUDIT_SET: User 'lab' set: [interfaces
ae0] <unconfigured> -> "disable"
Jun 29 18:37:52 R4 mgd[41976]: UI_CMDLINE_READ_LINE: User 'lab', command 'top
set interfaces ae0 disable '
Jun 29 18:37:53 R4 dcd[93878]: ae0 : Warning: aggregated-ether-options
link-speed no kernel value! default to 0
Jun 29 18:37:53 R4 dcd[1063]: ae0 : aggregated-ether-options link-speed set to
kernel value of 1000000000
Jun 29 18:37:53 R4 /kernel: ae0: Unknown TLV type 201
Jun 29 18:37:53 R4 mib2d[1068]: SNMP_TRAP_LINK_DOWN: ifIndex 529, ifAdminStatus
down(2), ifOperStatus down(2), ifName ae0
Jun 29 18:37:53 R4 rpd[1069]: Received MC_AE_OPTIONS TLV for intf device ae0;
mc_ae_id 0, status 2
Jun 29 18:37:53 R4 cosd[1074]: link protection 0 for intf ae0
Jun 29 18:37:53 R4 rpd[1069]: EVENT <UpDown> ae0.0 index 72 <Broadcast
Multicast> address #0 52.54.0.0.c6.2
Jun 29 18:37:53 R4 rpd[1069]: EVENT UpDown ae0.0 index 72 <Broadcast Multicast
Localup>
Jun 29 18:37:53 R4 rpd[1069]: RPD_ESIS_ADJDOWN: ES-IS lost IS adjacency to
49.0172.0027.0255.0002 on ae0.0, reason: Interface Down
Jun 29 18:37:53 R4 rpd[1069]: EVENT UpDown ae0.0 index 72 <Broadcast Multicast
Localup>
Jun 29 18:37:53 R4 rpd[1069]: RPD_ISIS_ADJDOWN: IS-IS lost L2 adjacency to R2
on ae0.0, reason: Interface Down
Jun 29 18:37:53 R4 rpd[1069]: RPD_RSVP_NBRDOWN: RSVP neighbor 172.27.0.5 down
on interface ae0.0, triggered by IGP neighbor down event
Jun 29 18:37:53 R4 /kernel: ae_bundlestate_ifd_change: bundle ae0: bundle IFD
minimum links not met 2 < 3
Jun 29 18:37:53 R4 /kernel: ae_bundlestate_ifd_change: bundle ae0: bundle IFD
state changed to DOWN
...
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/etc/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
Jun 26 04:03:07 centos syslogd 1.4.1: restart.
Jun 27 08:34:01 centos auditd[1598]: Audit daemon rotating log files
Jun 29 13:02:43 centos kernel: Kernel logging (proc) stopped.
Jun 29 13:02:43 centos kernel: Kernel log daemon terminating.
Jun 29 13:02:44 centos exiting on signal 15
Jun 29 13:02:44 centos syslogd 1.4.1: restart (remote reception).
Jun 29 13:02:44 centos kernel: klogd 1.4.1, log source = /proc/kmsg started.
Jun 29 20:04:53 172.27.155.2 mgd[14823]: UI_CMDLINE_READ_LINE: User 'lab',
command 'top '
Jun 29 20:05:01 172.27.155.2 mgd[14823]: 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
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]


tmp/"

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


tmp/"

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


tmp/"

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


tmp/"

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

Lab 2
IS-IS Implementation (Detailed)
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.
guide.
• 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 “Lab 2: IS-IS Implementation” 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.
www.juniper.net IS-IS Implementation (Detailed) • Lab 2–1

10.b.10.3
• 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.
• 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 (Detailed) www.juniper.net

Part 1: 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
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 “Lab 2: IS-IS Implementation” 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.0003.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.0003.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.0003.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.0003.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.0003.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
as an external Level 2 IS-IS route which has a 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 {
}
then {
metric 301;
accept;
}
}

lab@R3# commit
commit complete
• R4:
lab@R4# top set 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
[edit policy-options]
lab@R1# run show isis database detail R2
IS-IS level 1 link-state database:
R2.00-00 Sequence: 0x9, Checksum: 0x6c7d, Lifetime: 838 secs

IS neighbor: R2.02 Metric: 10
IP prefix: 10.100.100.0/24 Metric: 0 External Up
IP prefix: 172.27.0.0/30 Metric: 10 Internal Up
V6 prefix: 2008:4498::/126 Metric: 10 Internal Up
V6 prefix: 2008:4498::4/126 Metric: 10 Internal Up
R2.02-00 Sequence: 0x7, Checksum: 0xc490, Lifetime: 838 secs

R4.00-00 Sequence: 0x13, Checksum: 0xfbbd, Lifetime: 1082 secs

IP prefix: 10.22.0.0/21 Metric: 63 Internal Down
IP prefix: 10.100.100.0/24 Metric: 63 External Up
IP prefix: 172.27.0.56/30 Metric: 20 Internal Down
V6 prefix: 2008:4498::38/126 Metric: 20 Internal Down
R4.02-00 Sequence: 0xc, Checksum: 0xd3b, Lifetime: 1082 secs

R4.03-00 Sequence: 0xc, Checksum: 0x4cf8, Lifetime: 1082 secs

• R5:

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

> to 172.27.0.21 via ae2.0

R4.00-00 Sequence: 0x14, Checksum: 0x6bbe, Lifetime: 892 secs


V6 prefix: 2008:4498::/126 Metric: 20 Internal Up
R4.04-00 Sequence: 0xc, Checksum: 0x3053, Lifetime: 892 secs


R3.00-00 Sequence: 0x1a, Checksum: 0x4a78, Lifetime: 925 secs

V6 prefix: 2008:4489::c/126 Metric: 10 Internal Up
R3.03-00 Sequence: 0xe, Checksum: 0x1e67, Lifetime: 925 secs

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# 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 are
maintained. You must temporarily remove the no-authentication-check
option on R3 and R4 to truly verify this task. Remember to replace the option once
you are done verifying the task.
• 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
• R3:

lab@R3# commit
commit complete
• R4:

lab@R4# commit
commit complete
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 3
OSPF Implementation (Detailed)
Overview
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.
guide.
• Configure all internal routers to route traffic using OSPF. Configure the OSPF
areas as shown on the “Lab 3: OSPF Implementation” 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.
www.juniper.net OSPF Implementation (Detailed) • Lab 3–1

10.b.10.3
• 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.
• 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 (Detailed) www.juniper.net

Part 1: 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 “Lab 3: OSPF
Implementation” 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 “Lab 2: IGP Implementation—OSPF” 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:
[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:
[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:
[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:
[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:
[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 4
IS-IS Troubleshooting (Detailed)
Overview
In this lab, you will be given a list of tasks specific to IS-IS troubleshooting to accomplish in
a timed setting. You will have 1 hour to complete the simulation.
guide.
– 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 (Detailed) • Lab 4–1

10.b.10.3
Part 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
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
Lab 4–2 • IS-IS Troubleshooting (Detailed) www.juniper.net

ae0 up down
vlan up down
• 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
description "Connection to R4 AE0";
disable;
gigether-options {
802.3ad ae0;
}
[edit interfaces]
[edit interfaces]
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
Jul 29 20:54:27.960190 ERROR: IIH from 0172.0027.2554 with no matching areas,
Jul 29 20:54:28.274132 ISIS L1 periodic xmit to 01:80:c2:00:00:14 interface
ge-0/0/3.0
Jul 29 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
ge-0/0/6.0
Jul 29 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
ae0.0
Jul 28 21:46:56.969347 ERROR: ISIS ignored a bad packet: IIH with duplicate
sysid on interface ae0.0
Jul 28 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
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
Jul 30 22:21:20.839779 Received L1 CSN, source 0172.0027.2553, interface
ge-0/0/6.0
Jul 30 22:21:20.839877 ERROR: CSN authentication failure
Jul 30 22:21:20.839896 ERROR: L1 CSN from 0172.0027.2553 on ge-0/0/6.0 failed
authentication
Jul 30 22:21:21.547672 Received L1 CSN, source 0172.0027.2554, interface ae1.0
Jul 30 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

Jul 30 22:21:46.482466 Received L1 CSN, source 0172.0027.2554, interface ae0.0
Jul 30 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:
byte 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

byte 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
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
Jul 31 18:13:06 trace_on: Tracing to "/var/log/R2-overload-issue.log" started
Jul 31 18:13:06.871515 ERROR: ISIS has exceeded the maximum external prefix
allowed - going to overload
Jul 31 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

byte 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: Can you determine 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 5
OSPF Troubleshooting (Detailed)
Overview
In this lab, you will be given a list of tasks specific to OSPF troubleshooting to accomplish
in a timed setting. You will have 1 hour to complete the simulation.
guide.
– 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 (Detailed) • Lab 5–1

10.b.10.3
Part 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 (Detailed) 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],
44
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 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
Aug 2 18: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)
Aug 2 18:03:26.458666 Version 2, length 44, ID 172.27.255.3, area 0.0.0.0
Aug 2 18:03:26.458685 checksum 0x0, authtype 1
Aug 2 18:03:26.458701 mask 255.255.255.0, hello_ivl 5, opts 0x2, prio 128
Aug 2 18:03:26.458718 dead_ivl 20, DR 0.0.0.0, BDR 0.0.0.0
Aug 2 18: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
Aug 7 00:49:24.800280 OSPF rcvd Hello fe80::5668:29ff:fe7a:93b2 -> ff02::5
(ge-0/0/6.0 IFL 73 area 0.0.0.0)
Aug 7 00:49: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
Aug 7 00:49:44.695623 OSPF rcvd Hello fe80::5668:29ff:fe7a:93b2 -> ff02::5
(ge-0/0/6.0 IFL 73 area 0.0.0.0)
Aug 7 00:49: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
Pattern not found

[edit protocols]
lab@R1# run show log ospf-adj.log | find ae1
Pattern not found
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 R4’s
configuration. The adjacency problem with R4 does
not appear in the output because the necessary
traceoptions flags are not set.
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
...
proto: 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
proto: 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
...

44
Options [NSSA]
44

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

lab@R5# run show ospf database lsa-id 0.0.0.0 detail

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 totally stubby 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 stub 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 stub no-summaries default-metric 10

lab@R1# show
stub default-metric 10 no-summaries;
interface-type p2p;
hello-interval 15;
dead-interval 30;

}


lab@R1# set stub no-summaries

lab@R1# show
stub no-summaries;
interface-type p2p;
hello-interval 2;
dead-interval 12;
}

lab@R1# commit
commit complete
• R4:

lab@R4# set stub no-summaries

lab@R4# show
stub no-summaries;
interface ae0.0 {
interface-type p2p;
hello-interval 5;
dead-interval 20;
}


lab@R4# set stub no-summaries default-metric 10

lab@R4# show
stub 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 stub
[edit protocols]
lab@R2# set ospf3 area 1 stub
[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:01:32, metric 110

> to 172.27.0.1 via ge-0/0/1.0
224.0.0.5/32 *[OSPF/10] 2d 14:12:33, 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
!!

Lab 6
BGP Implementation (Detailed)
Overview
In this lab, you will implement a BGP network including IBGP, EBGP, and routing policies
according to the provided task list. You will have 2.5 hours to complete the lab.
guide.
regarding the interpretation of each task, followed by step-by-step instructions.
• Configure the IBGP network. Your IBGP network must be designed using route
reflection and must contain one route reflection cluster. All IBGP sessions must
use the lo0.0 interface IP address. The failure of a link or router in the
network must not result in any connectivity issues or isolation of clients.
• All IBGP sessions in your autonomous system (AS) must be authenticated
using MD5 authentication.
• Configure a BGP session to the customer 2 (C2), peer (P), and transit (T)
neighbors. Configure the EBGP session to C2 to load-balance over the two links
that connect R5 and C2. Only one BGP session should be used. A static route is
permissible to complete this task.
• Configure the R2 router to use load balancing over the two peering sessions
with T1 and T2 routers.
• All peer (P), transit provider (T1, T2), and C2 IPv4 prefixes should be active and
reachable on all routers in your AS.
• Routers C1 and C3 belong to the same customer, which uses IPv6 routing.
Configure a BGP session to C1 and C3 routers. Both C1 and C3 routers should
be able to communicate with each other as well as with the transit routers T1
and T2 using IPv6. IPv6 packet forwarding in your AS is not permitted.
• The direct IPv6 routes on C1-R3 and C3-R4 links must be reachable from the
customer remote routers C3 and C1, respectively.
www.juniper.net BGP Implementation (Detailed) • Lab 6–1

10.b.10.3
• Ensure that no more than 12 prefixes are accepted from customer
routers C1 and C3. If this limit is exceeded the router should generate the
syslog message but the session should remain active.
• All BGP sessions state changes should be logged to syslog.
• Implement an inbound policy for the transit routers that prefer the
inbound IPv4 traffic to come from the T1 router.
• Implement an outbound policy for the transit routers that ensures
outbound IPv4 traffic exits your AS at the R2 router.
• Ensure that traffic going to the destinations advertised by the P router
prefers R3 as the exit point.
• Routes received from the P router should not be advertised to T1 or T2 or
vice versa.
• Using BGP standard communities, ensure that it is possible to
differentiate between the EBGP neighbors from which the external IPv4
prefixes were received.
• Advertise a summary route representing local AS IPv4 network range to
the P, T1, T2, and C2 devices.
• Advertise a summary route representing local AS IPv6 range to the transit
provider, no other IPv6 routes may be advertised to the T1 and T2 routers.
• Do not accept IPv4 routes that have a mask shorter than /8 or longer
than /24 from the peer or transit providers.
• If the same route is learned directly from the C2 customer, it should
always be preferred to the same prefix learned from either a peer or a
transit router.
• After performing all previous tasks, migrate the existing IBGP network to a
confederation. route reflection is not permitted. No router in your AS can
have more than two IBGP and CBGP neighbors. The failure of a link or
router in the network must not result in any connectivity issues or
isolation of routers.
Lab 6–2 • BGP Implementation (Detailed) www.juniper.net

Part 1: Implementing BGP with Route Reflectors
In this lab part, you will log in to your assigned routers and configure as well as verify
the BGP network. In addition to establishing the BGP network you will implement
BGP routing policies. The IBGP network will be designed using route reflection.
Note
carefully reading all the tasks before you
start configuring routers step by step. This
approach allows you to better develop your
strategy, which is especially important in
BGP routing policy.
Your AS number is 3895077211.

R1 EBGP peers data:
P - 172.27.0.30, AS 2087403078
T1 - 172.27.0.34, AS 1342930876
R2 EBGP peers data:
T1 - 172.27.0.66, AS AS 1342930876
T2 - 172.27.0.38, AS AS 1342930876
R3 EBGP peers data:
P - 172.27.0.62, AS 2087403078
C1 - 2008:4498::2, AS 65432
R4 EBGP peers data:
C3 - 2008:4498:0:1::2, AS 65432
R5 EBGP peers data:
C2 - 202.202.0.1, AS 65512
TASK 1
TASK COMPLETION
• R1:
R1 (ttyd0)
login: lab
Password:

lab@R1>

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

lab@R2>
• R3:
R3 (ttyd0)
login: lab
Password:

lab@R3>
• R4:
R4 (ttyd0)
login: lab
Password:

lab@R4>
• R5:
R5 (ttyd0)
login: lab
Password:

lab@R5>
• VR-device:
vr-device (ttyd0)
login: lab
Password:

lab@vr-device>
TASK 2
Configure the IBGP network. Your IBGP network must be
designed using Route Reflection and must contain one Route
Reflection cluster. All IBGP sessions must use the lo0.0
interface IP address. The failure of a link or router in
the network must not result in any connectivity issues or
isolation of clients.

TASK INTERPRETATION
The task looks straightforward at first glance. You have five routers in your AS that
will act as either a route reflector (RR) or as clients in a single cluster. Note though,
that the cluster must be redundant because of the requirement that the failure of a
link or router in the network must not result in any connectivity issues or isolation of
the clients. We recommend you configure at least two RRs. In the example provided
in the detailed guide we use R3 and R4 as RRs, but you can choose any two routers.
TASK COMPLETION
• R1:
lab@R1> configure
[edit]
lab@R1# set routing-options autonomous-system 3895077211
[edit]
lab@R1# show routing-options
router-id 172.27.255.1;
autonomous-system 3895077211
[edit]
lab@R1# edit protocols bgp group cluster-1
[edit protocols bgp group cluster-1]

lab@R1# set type internal local-address 172.27.255.1

lab@R1# set neighbor 172.27.255.3


lab@R1# show
type internal;
local-address 172.27.255.1;
neighbor 172.27.255.3;
neighbor 172.27.255.4;

commit complete
lab@R1>
• R2:
lab@R2> configure

[edit]
[edit]
router-id 172.27.255.2;
autonomous-system 3895077211;
[edit]




lab@R2# show
type internal;
neighbor 172.27.255.3;
neighbor 172.27.255.4;

commit complete
lab@R2>
• R3:
lab@R3> configure
[edit]
[edit]
router-id 172.27.255.3;
[edit]

lab@R3# set cluster 0.0.0.1






lab@R3# top edit protocols bgp group internal
[edit protocols bgp group internal]




lab@R3# top show protocols bgp
group cluster-1 {
type internal;
cluster 0.0.0.1;
neighbor 172.27.255.1;
neighbor 172.27.255.2;
neighbor 172.27.255.5;
}
group internal {
type internal;
neighbor 172.27.255.4;
}

commit complete
lab@R3>
• R4:
lab@R4> configure
[edit]
[edit]

router-id 172.27.255.4;
[edit]

lab@R4# set cluster 0.0.0.1








lab@R4# top show protocols bgp
group cluster-1 {
type internal;
cluster 0.0.0.1;
neighbor 172.27.255.1;
neighbor 172.27.255.2;
neighbor 172.27.255.5;
}
group internal {
type internal;
neighbor 172.27.255.3;
}

commit complete
lab@R4>

• R5:
lab@R5> configure
[edit]
[edit]
router-id 172.27.255.5;
[edit]




lab@R5# show
type internal;
neighbor 172.27.255.3;
neighbor 172.27.255.4;

commit complete
lab@R5>
TASK VERIFICATION
Verify that IBGP sessions are established successfully.
• R1:
lab@R1> show bgp summary
Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
172.27.255.3 3895077211 130 129 0 0 57:15 0/
0/0/0 0/0/0/0
172.27.255.4 3895077211 27 26 0 0 11:06 0/
0/0/0 0/0/0/0

• R2:
inet.0 0 0 0 0 0 0
172.27.255.3 3895077211 130 131 0 0 58:15 0/
0/0/0 0/0/0/0
172.27.255.4 3895077211 28 28 0 0 12:06 0/
0/0/0 0/0/0/0
• R3:
inet.0 0 0 0 0 0 0
172.27.255.1 3895077211 131 132 0 0 58:28 0/
0/0/0 0/0/0/0
172.27.255.2 3895077211 130 130 0 0 58:24 0/
0/0/0 0/0/0/0
172.27.255.4 3895077211 29 29 0 0 12:07 0/
0/0/0 0/0/0/0
172.27.255.5 3895077211 17 15 0 0 6:24 0/
0/0/0 0/0/0/0
• R4:
inet.0 0 0 0 0 0 0
172.27.255.1 3895077211 28 30 0 0 12:25 0/
0/0/0 0/0/0/0
172.27.255.2 3895077211 28 29 0 0 12:21 0/
0/0/0 0/0/0/0
172.27.255.3 3895077211 28 29 0 0 12:13 0/
0/0/0 0/0/0/0
172.27.255.5 3895077211 16 16 0 0 6:26 0/
0/0/0 0/0/0/0
• R5:
inet.0 0 0 0 0 0 0
172.27.255.3 3895077211 15 17 0 0 6:36 0/
0/0/0 0/0/0/0
172.27.255.4 3895077211 15 16 0 0 6:32 0/
0/0/0 0/0/0/0
TASK 3
All IBGP sessions in your autonomous system must be
authenticated using MD5 authentication.
TASK INTERPRETATION
The task is straight forward. You must configure md5 authentication for all the IBGP
sessions from each of your routers. The task does not specify what key must be
used, so you can use whatever key you wish. In this detailed guide we use “juniper”.
TASK COMPLETION
• R1:
lab@R1> configure
[edit]
lab@R1# set protocols bgp group cluster-1 authentication-key juniper
[edit]
commit complete
lab@R1>
• R2:
lab@R2> configure
[edit]
[edit]
commit complete
lab@R2>
• R3:
lab@R3> configure
[edit]
[edit]
lab@R3# set protocols bgp group internal authentication-key juniper

[edit]
commit complete
lab@R3>
• R4:
lab@R4> configure
[edit]
[edit]
lab@R4# set protocols bgp group internal authentication-key juniper
[edit]
commit complete
lab@R4>
• R5:
lab@R5> configure
[edit]
[edit]
commit complete
lab@R5>
TASK VERIFICATION
You can verify authentication is configured by reviewing the neighbors for each
router. The output will not display what the key being used is. To simplify the outputs
use the show bgp neighbor | match "Peer: 172.27.255|Authentication
key" command.
• R1:
lab@R1> show bgp neighbor | match "Peer: 172.27.255|Authentication key"
Peer: 172.27.255.3+56190 AS 3895077211 Local: 172.27.255.1+179 AS 3895077211
Authentication key is configured
Peer: 172.27.255.4+179 AS 3895077211 Local: 172.27.255.1+56737 AS 3895077211

• R2:
Peer: 172.27.255.3+179 AS 3895077211 Local: 172.27.255.2+56748 AS 3895077211
Peer: 172.27.255.4+179 AS 3895077211 Local: 172.27.255.2+51719 AS 3895077211
• R3:
Peer: 172.27.255.1+179 AS 3895077211 Local: 172.27.255.3+56190 AS 3895077211
Peer: 172.27.255.2+56748 AS 3895077211 Local: 172.27.255.3+179 AS 3895077211
Peer: 172.27.255.4+50303 AS 3895077211 Local: 172.27.255.3+179 AS 3895077211
Peer: 172.27.255.5+61030 AS 3895077211 Local: 172.27.255.3+179 AS 3895077211
• R4:
Peer: 172.27.255.1+56737 AS 3895077211 Local: 172.27.255.4+179 AS 3895077211
Peer: 172.27.255.2+51719 AS 3895077211 Local: 172.27.255.4+179 AS 3895077211
Peer: 172.27.255.3+179 AS 3895077211 Local: 172.27.255.4+50303 AS 3895077211
Peer: 172.27.255.5+57711 AS 3895077211 Local: 172.27.255.4+179 AS 3895077211
• R5:
Peer: 172.27.255.3+179 AS 3895077211 Local: 172.27.255.5+61030 AS 3895077211
Peer: 172.27.255.4+179 AS 3895077211 Local: 172.27.255.5+57711 AS 3895077211
TASK 4
Configure a BGP session to C2 Customer, Peer (P) and
Transit (T) neighbors. Configure the EBGP session to C2 to
load balance over the two links that connect R5 and C2.
There should only be one BGP session used. A static route
is permissible to complete this task.

TASK INTERPRETATION
The EBGP sessions to the peer and transit neighbors are regular single-hop EBGP
sessions. For the C2 neighbor, you should configure the multihop option in order
to load-balance over the two physical links. A static route is required to establish a
loopback-to-loopback session.
Note
It might take a few minutes for the BGP
session with C2 to establish. If the BGP
session does not establish immediately,
wait three to five minutes before you begin
troubleshooting the session.
TASK COMPLETION
• R1:
lab@R1> configure
[edit]
lab@R1# set protocols bgp group T1 type external
[edit]
lab@R1# set protocols bgp group T1 peer-as 1342930876
[edit]
lab@R1# set protocols bgp group T1 neighbor 172.27.0.34
[edit]
lab@R1# set protocols bgp group P type external
[edit]
lab@R1# set protocols bgp group P peer-as 2087403078
[edit]
lab@R1# set protocols bgp group P neighbor 172.27.0.30
[edit]
lab@R1# show protocols bgp
group cluster-1 {
type internal;
authentication-key "$9$v5P8xd24Zk.5bs.5QFAtM8X"; ## SECRET-DATA
neighbor 172.27.255.3;
neighbor 172.27.255.4;
}
group T1 {
type external;
peer-as 1342930876;
neighbor 172.27.0.34;
}
group P {
type external;
peer-as 2087403078;
neighbor 172.27.0.30;
}
[edit]
commit complete
lab@R1>
• R2:
lab@R2> configure
[edit]
lab@R2# set protocols bgp group T1-T2 type external
[edit]
lab@R2# set protocols bgp group T1-T2 peer-as 1342930876
[edit]
lab@R2# set protocols bgp group T1-T2 neighbor 172.27.0.66
[edit]
lab@R2# set protocols bgp group T1-T2 neighbor 172.27.0.38
[edit]
group cluster-1 {
type internal;
authentication-key "$9$AMDcuBElK8db2cyb24aiHtuO"; ## SECRET-DATA
neighbor 172.27.255.3;
neighbor 172.27.255.4;
}
group T1-T2 {
type external;
peer-as 1342930876;
neighbor 172.27.0.66;
neighbor 172.27.0.38;
}
[edit]
commit complete
lab@R2>
• R3:
lab@R3> configure

[edit]
lab@R3# set protocols bgp group P type external
[edit]
lab@R3# set protocols bgp group P peer-as 2087403078
[edit]
lab@R3# set protocols bgp group P neighbor 172.27.0.62
[edit]
group cluster-1 {
type internal;
authentication-key "$9$XeSNVYJGifT3goT369OBxNd"; ## SECRET-DATA
cluster 0.0.0.1;
neighbor 172.27.255.1;
neighbor 172.27.255.2;
neighbor 172.27.255.5;
}
group internal {
type internal;
authentication-key "$9$j9kmT69pRhrz3hrev7Nik."; ## SECRET-DATA
neighbor 172.27.255.4;
}
group P {
type external;
peer-as 2087403078;
neighbor 172.27.0.62;
}
[edit]
commit complete
lab@R3>
• R5:
lab@R5> configure
[edit]
lab@R5# set routing-options static route 202.202.0.1/32 next-hop 172.27.0.50
[edit]
lab@R5# set routing-options static route 202.202.0.1/32 next-hop 172.27.0.74
[edit]
static {
route 202.202.0.1/32 next-hop [ 172.27.0.50 172.27.0.74 ];
}

router-id 172.27.255.5;
[edit]
lab@R5# set protocols bgp group C2 type external
[edit]
lab@R5# set protocols bgp group C2 multihop
[edit]
lab@R5# set protocols bgp group C2 local-address 172.27.255.5
[edit]
lab@R5# set protocols bgp group C2 peer-as 65512
[edit]
lab@R5# set protocols bgp group C2 neighbor 202.202.0.1
[edit]
group cluster-1 {
type internal;
authentication-key "$9$xfz-b2ZUH5Qn4aQn/CB17-V"; ## SECRET-DATA
neighbor 172.27.255.3;
neighbor 172.27.255.4;
}
group C2 {
type external;
multihop;
peer-as 65512;
neighbor 202.202.0.1;
}
[edit]
commit complete
lab@R5>
TASK VERIFICATION
Verify that EBGP sessions are established successfully. You should also verify that
the routes received from the C2 neighbor at the R5 router shows two physical next
hops.
• R1:

inet.0 908 884 0 0 0 0
172.27.0.30 2087403078 102 582 0 0 45:12 24/
24/24/0 0/0/0/0
172.27.0.34 1342930876 581 104 0 0 45:13
860/860/860/0 0/0/0/0
172.27.255.3 3895077211 148 632 0 0 1:05:43 0/
24/24/0 0/0/0/0
172.27.255.4 3895077211 139 625 0 0 1:03:08 0/
0/0/0 0/0/0/0
• R2:
inet.0 1745 871 0 0 0 0
172.27.0.38 1342930876 576 95 0 0 42:45 11/
861/861/0 0/0/0/0
172.27.0.66 1342930876 504 96 0 0 42:49
860/860/860/0 0/0/0/0
172.27.255.3 3895077211 153 576 0 0 1:07:47 0/
24/24/0 0/0/0/0
172.27.255.4 3895077211 145 568 0 0 1:05:04 0/
0/0/0 0/0/0/0
• R3:
inet.0 1786 24 0 0 0 0
172.27.0.62 2087403078 89 90 0 0 39:57 24/
24/24/0 0/0/0/0
172.27.255.1 3895077211 639 155 0 0 1:09:00 0/
884/884/0 0/0/0/0
172.27.255.2 3895077211 578 157 0 0 1:09:09 0/
871/871/0 0/0/0/0
172.27.255.4 3895077211 148 150 0 0 1:06:10 0/
0/0/0 0/0/0/0
172.27.255.5 3895077211 146 146 0 0 1:04:46 0/
7/7/0 0/0/0/0
• R5:
inet.0 31 7 0 0 0 0

172.27.255.3 3895077211 146 148 0 0 1:05:27 0/
24/24/0 0/0/0/0
172.27.255.4 3895077211 144 146 0 0 1:05:23 0/
0/0/0 0/0/0/0
202.202.0.1 65512 79 80 0 0 35:06 7/
7/7/0 0/0/0/0
lab@R5> show route protocol bgp 202/8 terse

A Destination P Prf Metric 1 Metric 2 Next hop AS path

* 202.202.0.0/24 B 170 100 >172.27.0.50 65512 65512 I
172.27.0.74
* 202.202.2.0/24 B 170 100 >172.27.0.50 65512 65512 I
172.27.0.74
* 202.202.3.0/24 B 170 100 >172.27.0.50 65512 65512 I
172.27.0.74
* 202.202.4.0/24 B 170 100 >172.27.0.50 65512 65512 I
172.27.0.74
* 202.202.5.0/24 B 170 100 >172.27.0.50 65512 65512 I
172.27.0.74
* 202.202.6.0/24 B 170 100 >172.27.0.50 65512 65512 I
172.27.0.74
* 202.202.7.0/24 B 170 100 >172.27.0.50 65512 65512 I
172.27.0.74
TASK 5
Configure the R2 router to use load balancing over the two
peering sessions with T1 and T2 routers.
TASK INTERPRETATION
To make the R2 router load balance over the two EBGP sessions, you must configure
the multipath option.
TASK COMPLETION
• R2:
lab@R2> configure
[edit]
lab@R2# set protocols bgp group T1-T2 multipath
[edit]
commit complete
lab@R2>

TASK VERIFICATION
Verify that the routes received from both T1 and T2 neighbors at R2 router show two
physical next hops.
• R2:
lab@R2> show route protocol bgp 6/8 terse active-path


* 6.1.0.0/16 B 170 100 172.27.0.38 1342930876 8918
668 1455 I
>172.27.0.66
* 6.2.0.0/22 B 170 100 >172.27.0.38 1342930876 8918
668 1455 I
172.27.0.66
* 6.3.0.0/18 B 170 100 >172.27.0.38 1342930876 8918
668 1455 I
172.27.0.66
* 6.4.0.0/16 B 170 100 172.27.0.38 1342930876 8918
668 1455 I
>172.27.0.66
* 6.5.0.0/19 B 170 100 172.27.0.38 1342930876 8918
668 1455 I
>172.27.0.66
* 6.8.0.0/20 B 170 100 >172.27.0.38 1342930876 8918
668 1455 I
172.27.0.66
* 6.9.0.0/20 B 170 100 172.27.0.38 1342930876 8918
668 1455 I
>172.27.0.66
* 6.10.0.0/15 B 170 100 >172.27.0.38 1342930876 8918
668 1455 I
172.27.0.66
* 6.14.0.0/15 B 170 100 >172.27.0.38 1342930876 8918
668 1455 I
172.27.0.66
TASK 6
All Peer (P), Transit provider (T1, T2) and C2 IPv4
prefixes should be active and reachable on all routers in
your AS.
TASK INTERPRETATION
To ensure that all the external IPv4 routes are reachable across your A,S you must
ensure that all the routers in your AS can resolve BGP next hops.
TASK COMPLETION
• R1:
lab@R1> configure

[edit]
lab@R1# edit policy-options policy-statement nhs
[edit policy-options policy-statement nhs]

lab@R1# set term 1 from protocol bgp

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

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

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

lab@R1# top
[edit]
lab@R1# set protocols bgp group cluster-1 export nhs
[edit]
lab@R1# show protocols bgp group cluster-1
type internal;
export nhs;
neighbor 172.27.255.3;
neighbor 172.27.255.4;
[edit]
commit complete
lab@R1>
• R2:
lab@R2> configure
[edit]




lab@R2# show
term 1 {
from {
protocol bgp;
}
then {
next-hop self;
}
}

lab@R2# top
[edit]
[edit]
type internal;
export nhs;
neighbor 172.27.255.3;
neighbor 172.27.255.4;
[edit]
commit complete
lab@R2>
• R3:
lab@R3> configure
[edit]




lab@R3# show
term 1 {
from {
protocol bgp;
}
then {
next-hop self;
}
}

lab@R3# top
[edit]
[edit]
type internal;
export nhs;
cluster 0.0.0.1;
neighbor 172.27.255.1;
neighbor 172.27.255.2;
neighbor 172.27.255.5;
[edit]
lab@R3# set protocols bgp group internal export nhs
[edit]
lab@R3# show protocols bgp group internal
type internal;
export nhs;
neighbor 172.27.255.4;
[edit]
commit complete
lab@R3>

• R5:
lab@R5> configure
[edit]




lab@R5# show
term 1 {
from {
protocol bgp;
}
then {
next-hop self;
}
}

lab@R5# top
[edit]
[edit]
type internal;
authentication-key "$9$xfz-b2ZUH5Qn4aQn/CB17-V"; ## SECRET-DATA
export nhs;
neighbor 172.27.255.3;
neighbor 172.27.255.4;
[edit]
commit complete
lab@R5>

TASK VERIFICATION
Verify that all the routers in your AS can resolve BGP next hops.
• R1:
lab@R1> show route 202.202/24

202.202.0.0/24 *[BGP/170] 01:50:57, localpref 100

AS path: 2087403078 65512 I
> to 172.27.0.30 via ge-0/0/1.0
[BGP/170] 00:32:38, localpref 100, from 172.27.255.3
AS path: 2087403078 65512 I
> to 172.27.0.13 via ge-0/0/6.0
lab@R1> show route resolution unresolved

Tree Index 1
Tree Index 2
Tree Index 3
Tree Index 4
• R2:

202.202.0.0/24 *[BGP/170] 00:46:59, localpref 100, from 172.27.255.4

AS path: 2087403078 65512 I
> to 172.27.0.1 via ge-0/0/1.0
AS path: 2087403078 65512 I
> to 172.27.0.6 via ge-0/0/4.0
to 172.27.0.1 via ge-0/0/1.0


AS path: 2087403078 I
> to 172.27.0.1 via ge-0/0/1.0
AS path: 2087403078 I
> to 172.27.0.6 via ge-0/0/4.0
to 172.27.0.1 via ge-0/0/1.0

Tree Index 1
Tree Index 2
Tree Index 3
Tree Index 4
• R3:
lab@R3> show route 111.111.1/24


AS path: 1342930876 I
> to 172.27.0.14 via ge-0/0/1.0
AS path: 1342930876 I
> to 172.27.0.14 via ge-0/0/1.0
to 172.27.0.18 via ge-0/0/2.0

202.202.0.0/24 *[BGP/170] 01:47:15, localpref 100

AS path: 2087403078 65512 I
> to 172.27.0.62 via ge-0/0/5.0
AS path: 2087403078 65512 I
> to 172.27.0.14 via ge-0/0/1.0
AS path: 65512 65512 I
> to 172.27.0.25 via ge-0/0/3.0

Tree Index 1
Tree Index 2
Tree Index 3
Tree Index 4
• R4:


AS path: 1342930876 I
> to 172.27.0.10 via ae0.0
AS path: 1342930876 I
> to 172.27.0.5 via ge-0/0/1.0


AS path: 2087403078 65512 I
> to 172.27.0.10 via ae0.0
AS path: 2087403078 65512 I
> to 172.27.0.17 via ge-0/0/5.0
AS path: 65512 65512 I
> to 172.27.0.22 via ge-0/0/4.0


AS path: 2087403078 I
> to 172.27.0.10 via ae0.0
AS path: 2087403078 I
> to 172.27.0.17 via ge-0/0/5.0

Tree Index 1
Tree Index 2
Tree Index 3
Tree Index 4
• R5:


AS path: 1342930876 I
> to 172.27.0.21 via ge-0/0/2.0
AS path: 1342930876 I
> to 172.27.0.21 via ge-0/0/2.0


AS path: 2087403078 I
> to 172.27.0.26 via ge-0/0/1.0
AS path: 2087403078 I
> to 172.27.0.21 via ge-0/0/2.0

Tree Index 1
Tree Index 2
Tree Index 3
Tree Index 4
TASK 7
Routers C1 and C3 belong to the same customer, which uses
IPv6 routing. Provide the communication between C1 and C3
over your AS. Both C1 and C3 routers must be able to
communicate with the Transit routers T1 and T2 using IPv6.
IPv6 packet forwarding in your AS is not permitted.
TASK INTERPRETATION
In this task, the IPv6 forwarding in your network is not allowed but communication
must be provided between C1, C3, T1, and T2. 6PE is the application that can be
used to solve the problem. 6PE requires the network running MPLS, which is
preconfigured in your topology. Your task now is to configure 6PE on the four PE
routers servicing the IPv6 topology.
TASK COMPLETION
Configure core-facing interfaces on R1, R2, R3, and R4 to support family inet6.
Configure AS-external interfaces on R1 and R2 to support family inet6 with
IPv4-compatible IPv6 addresses. Configure AS-external interfaces on R3 and R4 to
support family inet6 with IPv6 native addresses.
Configure IBGP on R1, R2, R3, R4 to support 6PE signaling. Configure EBGP on R1
and R2 to support family IPv6. Configure EBGP on R3 and R4 as native IPv6 BGP.
Configure MPLS on R1, R2, R3, R4 to support IPv6 tunneling.
• R1:
lab@R1> configure
[edit]
[edit interfaces]
lab@R1# set ge-0/0/2 unit 0 family inet6 address ::172.27.0.33/126
[edit interfaces]
lab@R1# set ge-0/0/3 unit 0 family inet6
[edit interfaces]
[edit interfaces]
lab@R1# set ae0 unit 0 family inet6
[edit interfaces]
description "Connection to T1";

unit 0 {
family inet {
address 172.27.0.33/30;
}
family inet6 {
address ::172.27.0.33/126;
}
}
[edit interfaces]
unit 0 {
family inet {
address 172.27.0.1/30;
}
family inet6;
family mpls;
}

unit 0 {
family inet {
address 172.27.0.14/30;
}
family inet6;
family mpls;
}
[edit interfaces]
lab@R1# show ae0
lacp {
active;
}
}
unit 0 {
family inet {
address 172.27.0.10/30;
}
family inet6;
family mpls;
}
[edit interfaces]
lab@R1# top
[edit]
lab@R1# set protocols bgp group cluster-1 family inet unicast
[edit]
lab@R1# set protocols bgp group cluster-1 family inet6 labeled-unicast
explicit-null

[edit]
type internal;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
export nhs;
neighbor 172.27.255.3;
neighbor 172.27.255.4;
[edit]
lab@R1# set protocols bgp group T1 family inet unicast
[edit]
lab@R1# set protocols bgp group T1 family inet6 unicast
[edit]
lab@R1# show protocols bgp group T1
type external;
family inet {
unicast;
}
family inet6 {
unicast;
}
peer-as 1342930876;
neighbor 172.27.0.34;
[edit]
lab@R1# set protocols mpls ipv6-tunneling
[edit]
lab@R1# show protocols mpls
ipv6-tunneling;
interface ae0.0;
[edit]
commit complete
lab@R1>

• R2:
lab@R2> configure
[edit]
[edit interfaces]
[edit interfaces]
[edit interfaces]
[edit interfaces]
[edit interfaces]
unit 0 {
family inet {
address 172.27.0.2/30;
}
family inet6;
family mpls;
}
[edit interfaces]
unit 0 {
family inet {
address 172.27.0.37/30;
}
family inet6 {
address ::172.27.0.37/126;
}
}
[edit interfaces]
unit 0 {
family inet {
address 172.27.0.65/30;
}
family inet6 {
address ::172.27.0.65/126;
}
}

[edit interfaces]
unit 0 {
family inet {
address 172.27.0.5/30;
}
family inet6;
family mpls;
}
[edit interfaces]
lab@R2# top
[edit]
[edit]
explicit-null
[edit]
type internal;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
export nhs;
neighbor 172.27.255.3;
neighbor 172.27.255.4;
[edit]
lab@R2# set protocols bgp group T1-T2 family inet unicast
[edit]
lab@R2# set protocols bgp group T1-T2 family inet6 unicast
[edit]
lab@R2# show protocols bgp group T1-T2
type external;
family inet {
unicast;
}
family inet6 {
unicast;
}
peer-as 1342930876;
multipath;

neighbor 172.27.0.66;
neighbor 172.27.0.38;
[edit]
[edit]
ipv6-tunneling;
[edit]
commit complete
lab@R2>
• R3:
lab@R3> configure
[edit]
[edit interfaces]
[edit interfaces]
[edit interfaces]
[edit interfaces]
lab@R3# set ge-0/0/4 unit 0 family inet6 address 2008:4498::1/64
[edit interfaces]
unit 0 {
family inet {
address 172.27.0.13/30;
}
family inet6;
family mpls;
}
[edit interfaces]
unit 0 {

family inet {
address 172.27.0.17/30;
}
family inet6;
family mpls;
}
[edit interfaces]
unit 0 {
family inet {
address 172.27.0.26/30;
}
family inet6;
family mpls;
}
[edit interfaces]
description "Connection to C1";
unit 0 {
family inet6 {
address 2008:4498::1/64;
}
}
[edit interfaces]
lab@R3# top
[edit]
[edit]
explicit-null
[edit]
type internal;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
export nhs;
cluster 0.0.0.1;
neighbor 172.27.255.1;
neighbor 172.27.255.2;
neighbor 172.27.255.5;

[edit]
lab@R3# set protocols bgp group internal family inet unicast
[edit]
lab@R3# set protocols bgp group internal family inet6 labeled-unicast
explicit-null
[edit]
type internal;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
export nhs;
neighbor 172.27.255.4;
[edit]
[edit]
[edit]
lab@R3# set protocols bgp group C1 as-override
[edit]
lab@R3# set protocols bgp group C1 neighbor 2008:4498::2
[edit]
lab@R3# show protocols bgp group C1
type external;
peer-as 65432;
as-override;
neighbor 2008:4498::2;
[edit]
[edit]
ipv6-tunneling;

[edit]
commit complete
lab@R3>
• R4:
lab@R4> configure
[edit]
[edit interfaces]
[edit interfaces]
lab@R4# set ge-0/0/2 unit 0 family inet6 address 2008:4498:0:1::1/64
[edit interfaces]
[edit interfaces]
[edit interfaces]
lab@R4# set ae0 unit 0 family inet6
[edit interfaces]
unit 0 {
family inet {
address 172.27.0.6/30;
}
family inet6;
family mpls;
}
[edit interfaces]
description "Connection to C3";
unit 0 {
family inet6 {
address 2008:4498:0:1::1/64;
}
}
[edit interfaces]
unit 0 {

family inet {
address 172.27.0.21/30;
}
family inet6;
family mpls;
}
[edit interfaces]
unit 0 {
family inet {
address 172.27.0.18/30;
}
family inet6;
family mpls;
}
[edit interfaces]
lab@R4# show ae0
lacp {
passive;
}
}
unit 0 {
family inet {
address 172.27.0.9/30;
}
family inet6;
family mpls;
}
[edit interfaces]
lab@R4# top
[edit]
[edit]
explicit-null
[edit]
type internal;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}

}
authentication-key "$9$U3iqf36A1RSTzRSreXxDik"; ## SECRET-DATA
cluster 0.0.0.1;
neighbor 172.27.255.1;
neighbor 172.27.255.2;
neighbor 172.27.255.5;
[edit]
[edit]
lab@R4# set protocols bgp group internal family inet6 labeled-unicast
explicit-null
[edit]
type internal;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
authentication-key "$9$EFaSlM7-waZj8XZjHqQzhSr"; ## SECRET-DATA
neighbor 172.27.255.3;
[edit]
[edit]
[edit]
lab@R4# set protocols bgp group C3 as-override
[edit]
lab@R4# set protocols bgp group C3 neighbor 2008:4498:0:1::2
[edit]
type external;
peer-as 65432;
as-override;
neighbor 2008:4498:0:1::2;
[edit]
[edit]
ipv6-tunneling;

interface ae0.0;
[edit]
commit complete
lab@R4>
TASK VERIFICATION
Verify that BGP sessions with family inet6 support are established successfully.
Verify that IPv4-mapped IPv6 loopback addresses are reachable in inet6.3 table.
Verify that R1, R2, R3, and R4 exchange with IPv6 routes.
• R1:
inet.0 930 895 0 0 0 0
inet6.0 65 33 0 0 0 0
172.27.0.30 2087403078 455 1393 0 0 3:27:21 24/
24/24/0 0/0/0/0
172.27.0.34 1342930876 583 177 0 0 1:17:52
Establ
inet.0: 860/860/860/0
inet6.0: 1/1/1/0
172.27.255.3 3895077211 84 491 0 1 34:26
Establ
inet.0: 11/35/35/0
inet6.0: 16/32/32/0
172.27.255.4 3895077211 46 455 0 1 18:07
Establ
inet.0: 0/11/11/0
inet6.0: 16/32/32/0
lab@R1> show route table inet6.3

::ffff:172.27.255.2/128
*[LDP/20] 01:19:19, metric 10
> to 172.27.0.2 via ge-0/0/3.0
::ffff:172.27.255.3/128
*[LDP/20] 01:19:19, metric 10
> to 172.27.0.13 via ge-0/0/6.0

::ffff:172.27.255.4/128
*[LDP/20] 01:19:19, metric 5
> to 172.27.0.9 via ae0.0
::ffff:172.27.255.5/128
*[LDP/20] 01:19:19, metric 15
> to 172.27.0.9 via ae0.0, Push 299776
lab@R1> show route advertising-protocol bgp 172.27.0.34 table inet6.0

2008:4498:1::/64

Prefix Nexthop MED Lclpref AS path
* 2008:4498:1::/64 Self 65432 I

2008:4498:2::/64

* 2008:4498:2::/64 Self 65432 I

* ::/0 Self 100 1342930876 I

* ::/0 Self 100 1342930876 I
• R2:
inet.0 3489 1745 0 0 0 0
inet6.0 68 34 0 0 0 0
172.27.0.38 1342930876 615 137 0 0 59:31
Establ
inet.0: 861/861/861/0
inet6.0: 1/1/1/0
172.27.0.66 1342930876 543 137 0 0 59:34
Establ
inet.0: 860/860/860/0
inet6.0: 1/1/1/0
172.27.255.3 3895077211 517 512 0 1 44:55
Establ
inet.0: 0/884/884/0
inet6.0: 16/33/33/0

172.27.255.4 3895077211 481 476 0 1 28:36
Establ
inet.0: 24/884/884/0
inet6.0: 16/33/33/0

::ffff:172.27.255.1/128
*[LDP/20] 01:00:08, metric 10
> to 172.27.0.1 via ge-0/0/1.0
::ffff:172.27.255.3/128
*[LDP/20] 01:00:08, metric 20
to 172.27.0.6 via ge-0/0/4.0, Push 299792
> to 172.27.0.1 via ge-0/0/1.0, Push 299808
::ffff:172.27.255.4/128
*[LDP/20] 01:00:08, metric 10
> to 172.27.0.6 via ge-0/0/4.0
::ffff:172.27.255.5/128
*[LDP/20] 01:00:08, metric 20
> to 172.27.0.6 via ge-0/0/4.0, Push 299776

2008:4498:1::/64

* 2008:4498:1::/64 Self 65432 I

2008:4498:2::/64

* 2008:4498:2::/64 Self 65432 I

2008:4498:1::/64

* 2008:4498:1::/64 Self 65432 I

2008:4498:2::/64

* 2008:4498:2::/64 Self 65432 I

* ::/0 Self 100 1342930876 I

* ::/0 Self 100 1342930876 I
• R3:
inet.0 1786 895 0 0 0 0
inet6.0 34 33 0 0 0 0
172.27.0.62 2087403078 470 1423 0 0 3:35:12 24/
24/24/0 0/0/0/0
172.27.255.1 3895077211 527 119 0 0 50:49
Establ
inet.0: 860/884/884/0
inet6.0: 1/1/1/0
172.27.255.2 3895077211 525 529 0 0 50:45
Establ
inet.0: 11/871/871/0
inet6.0: 0/1/1/0
172.27.255.4 3895077211 550 548 0 1 34:18
Establ
inet.0: 0/0/0/0
inet6.0: 16/16/16/0
172.27.255.5 3895077211 113 527 0 0 50:41
Establ
inet.0: 0/7/7/0
2008:4498::2 65432 112 116 0 0 50:33
Establ
inet6.0: 16/16/16/0

::ffff:172.27.255.1/128
*[LDP/20] 00:51:15, metric 10
> to 172.27.0.14 via ge-0/0/1.0
::ffff:172.27.255.2/128
*[LDP/20] 00:51:15, metric 20
> to 172.27.0.14 via ge-0/0/1.0, Push 299824
to 172.27.0.18 via ge-0/0/2.0, Push 299824
::ffff:172.27.255.4/128
*[LDP/20] 00:51:15, metric 10
> to 172.27.0.18 via ge-0/0/2.0

::ffff:172.27.255.5/128
*[LDP/20] 00:51:15, metric 10
> to 172.27.0.25 via ge-0/0/3.0
lab@R3> show route advertising-protocol bgp 2008:4498::2 2008:4498:2::/64

* 2008:4498:2::/64 Self 3895077211 I
lab@R3> show route advertising-protocol bgp 2008:4498::2 ::/0 exact

* ::/0 Self 1342930876 I
• R4:
inet.0 1786 895 0 0 0 0
inet6.0 34 33 0 0 0 0
172.27.255.1 3895077211 499 89 0 0 37:58
Establ
inet.0: 884/884/884/0
inet6.0: 1/1/1/0
172.27.255.2 3895077211 497 501 0 0 37:54
Establ
inet.0: 11/871/871/0
inet6.0: 0/1/1/0
172.27.255.3 3895077211 555 556 0 0 37:46
Establ
inet.0: 0/24/24/0
inet6.0: 16/16/16/0
172.27.255.5 3895077211 85 499 0 0 37:50
Establ
inet.0: 0/7/7/0
2008:4498:0:1::2 65432 84 88 0 0 37:42
Establ
inet6.0: 16/16/16/0

::ffff:172.27.255.1/128
*[LDP/20] 00:38:23, metric 5
> to 172.27.0.10 via ae0.0
::ffff:172.27.255.2/128
*[LDP/20] 00:38:23, metric 10
> to 172.27.0.5 via ge-0/0/1.0

::ffff:172.27.255.3/128
*[LDP/20] 00:38:23, metric 10
> to 172.27.0.17 via ge-0/0/5.0
::ffff:172.27.255.5/128
*[LDP/20] 00:38:23, metric 10
> to 172.27.0.22 via ge-0/0/4.0
lab@R4> show route advertising-protocol bgp 2008:4498:0:1::2 2008:4498:1::/64

* 2008:4498:1::/64 Self 3895077211 I
lab@R4> show route advertising-protocol bgp 2008:4498:0:1::2 ::/0 exact

* ::/0 Self 1342930876 I
TASK 8
The direct IPv6 routes on C1-R3 and C3-R4 links must be
reachable from the Customer remote routers C3 and C1
respectively.
TASK INTERPRETATION
You must apply a redistribution policy at R3 and R4.
TASK COMPLETION
• R3:
lab@R3> configure
[edit]
lab@R3# edit policy-options policy-statement IPv6-direct
[edit policy-options policy-statement IPv6-direct]

lab@R3# set term 1 from protocol direct

lab@R3# set term 1 from route-filter 2008:4498::/64 exact

lab@R3# set term 1 then accept

lab@R3# show
term 1 {
from {
protocol direct;
route-filter 2008:4498::/64 exact;
}
then accept;
}


lab@R3# top
[edit]
lab@R3# set protocols bgp group internal export IPv6-direct
[edit]
type internal;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
export [ nhs IPv6-direct ];
neighbor 172.27.255.4;
[edit]
commit complete
lab@R3>
• R4:
lab@R4> configure
[edit]
lab@R4# edit policy-options policy-statement IPv6-direct


lab@R4# set term 1 from route-filter 2008:4498:0:1::/64 exact


lab@R4# show
term 1 {
from {
protocol direct;
route-filter 2008:4498:0:1::/64 exact;

}
then accept;
}

lab@R4# top
[edit]
lab@R4# set protocols bgp group internal export IPv6-direct
[edit]
type internal;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
authentication-key "$9$EFaSlM7-waZj8XZjHqQzhSr"; ## SECRET-DATA
export IPv6-direct;
neighbor 172.27.255.3;
[edit]
commit complete
lab@R4>
TASK VERIFICATION
Verify that the redistribution policy is applied at R3 and R4.
• R3:
lab@R3> show route advertising-protocol bgp 2008:4498::2 2008:4498:0:1::/64

* 2008:4498:0:1::/64 Self I
lab@R3> show route advertising-protocol bgp 172.27.255.4 2008:4498::/64

* 2008:4498::/64 Self 100 I
lab@R3> ping inet6 2008:4498:0:1::2 source 2008:4498::1 count 2

PING6(56=40+8+8 bytes) 2008:4498::1 --> 2008:4498:0:1::2
16 bytes from 2008:4498:0:1::2, icmp_seq=0 hlim=63 time=7.860 ms
16 bytes from 2008:4498:0:1::2, icmp_seq=1 hlim=63 time=7.825 ms

--- 2008:4498:0:1::2 ping6 statistics ---

round-trip min/avg/max/std-dev = 7.825/7.843/7.860/0.018 ms
• R4:
lab@R4> show route advertising-protocol bgp 2008:4498:0:1::2 2008:4498::/64

* 2008:4498::/64 Self I
lab@R4> show route advertising-protocol bgp 172.27.255.3 2008:4498:0:1::/64

* 2008:4498:0:1::/64 Self 100 I
lab@R4> ping inet6 2008:4498::2 source 2008:4498:0:1::1 count 2

PING6(56=40+8+8 bytes) 2008:4498:0:1::1 --> 2008:4498::2
16 bytes from 2008:4498::2, icmp_seq=0 hlim=63 time=13.861 ms
--- 2008:4498::2 ping6 statistics ---

TASK 9
Ensure that no more than 12 prefixes are accepted from
Customer routers C1 and C3. If this limit is exceeded the
router should generate the syslog message but the session
should remain active.
TASK INTERPRETATION
When prefix limit is configured in BGP, the default action is to generate the syslog
message, therefore you must configure only the limit, without specifying other
options.
TASK COMPLETION
• R3:
lab@R3> configure
[edit]
lab@R3# set protocols bgp group C1 family inet6 unicast prefix-limit maximum 12
[edit]
type external;
family inet6 {
unicast {
prefix-limit {

maximum 12;
}
}
}
peer-as 65432;
as-override;
neighbor 2008:4498::2;
[edit]
commit complete
lab@R3>
• R4:
lab@R4> configure
[edit]
lab@R4# set protocols bgp group C3 family inet6 unicast prefix-limit maximum 12
[edit]
type external;
family inet6 {
unicast {
prefix-limit {
maximum 12;
}
}
}
peer-as 65432;
as-override;
neighbor 2008:4498:0:1::2;
[edit]
commit complete
lab@R4>
TASK VERIFICATION
Verify that you have correctly configured the prefix limit.
• R3:
lab@R3> show log messages | match "Configured maximum"
Jun 29 07:48:51 R3 rpd[1078]: 2008:4498::2 (External AS 65432): Configured
maximum prefix-limit(12) exceeded for inet6-unicast nlri: 16

• R4:
lab@R4> show log messages | match "Configured maximum"
Jun 29 07:48:26 R4 rpd[1078]: 2008:4498:0:1::2 (External AS 65432): Configured
maximum prefix-limit(12) exceeded for inet6-unicast nlri: 16
TASK 10
All BGP sessions state changes should be logged to syslog.
TASK INTERPRETATION
The task is fairly straight forward. You must configure the log-updown option
under the BGP protocol for every router.
TASK COMPLETION
• R1:
lab@R1> configure
[edit]
lab@R1# set protocols bgp log-updown
[edit]
commit complete
lab@R1>
• R2:
lab@R2> configure
[edit]
[edit]
commit complete
lab@R2>
• R3:
lab@R3> configure
[edit]

[edit]
commit complete
lab@R3>
• R4:
lab@R4> configure
[edit]
[edit]
commit complete
lab@R4>
• R5:
lab@R5> configure
[edit]
[edit]
commit complete
lab@R5>
TASK VERIFICATION
Verify that all BGP sessions state changes are logged to syslog.
• R1:
lab@R1> clear bgp neighbor
Cleared 4 connections
lab@R1> show log messages | match RPD_BGP_NEIGHBOR_STATE_CHANGED

Aug 30 17:11:17 R1 rpd[1058]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer
172.27.255.3 (Internal AS 3895077211) changed state from Established to Idle
(event Stop)
172.27.255.4 (Internal AS 3895077211) changed state from Established to Idle
(event Stop)

172.27.0.34 (External AS 1342930876) changed state from Established to Idle
(event Stop)
172.27.0.30 (External AS 2087403078) changed state from Established to Idle
(event Stop)
Note
The next several steps are comprised of
policy tasks. To most efficiently implement
the BGP policy tasks, we will discuss each
policy task in a separate step, however, the
tasks will be completed together in a later
step.
TASK 11
Implement an inbound policy for the Transit routers that
prefers the inbound IPv4 traffic to come from the T1
router.
TASK INTERPRETATION
The prefixes advertised by R2 to T2 should look inferior to the ones advertised by R1
and R2 to T1. Routers to apply the policy: R2.
TASK 12
Implement an outbound policy for the Transit routers that
ensures the outbound IPv4 traffic exits your AS at the R2
router.
TASK INTERPRETATION
The prefixes received from T1 and T2 should be advertised to IBGP neighbors with
better preference by R2. Routers to apply the policy: R2.
TASK 13
Ensure that the traffic going to the destinations
advertised by the P router prefers R3 as the exit point.
TASK INTERPRETATION
The task is straightforward. Routers to apply the policy: R3.
TASK 14
Routes received from the P router should not be advertised
to T1 or T2 or vise-versa.
TASK INTERPRETATION
The task is straightforward. Routers to apply the policy: R1, R2, R3.

TASK 15
Using BGP standard communities ensure that it is possible
to differentiate between the EBGP neighbors where the
external IPv4 prefixes were received from.
TASK INTERPRETATION
The task is straightforward. Routers to apply the policy: R1, R2, R3, R5.
TASK 16
Advertise a summary route representing local AS IPv4 range
to the Peer (P), Transit provider (T1 and T2) and the C2
Customer.
TASK INTERPRETATION
The task is straightforward. Routers to apply the policy: R1, R2, R3, R5.
TASK 17
Advertise a summary route representing local AS IPv6 range
to the Transit provider, no other IPv6 routes may be
advertised to the T1 and T2 routers.
TASK INTERPRETATION
The task is straightforward. Routers to apply the policy: R1, R2.
TASK 18
Do not accept IPv4 routes that have a mask shorter than /8
or longer than /24 from the Peer and Transit providers.
TASK INTERPRETATION
The task is straightforward. Routers to apply the policy: R1, R2, R3.
TASK 19
If the same route is learned directly from the C2 Customer,
it should always be preferred to the same prefix learned
from either a Peer or a Transit router.
TASK INTERPRETATION
C2 prefixes may be advertised indirectly to your AS. You should not rely on AS path
length. R5 should advertise the C2 prefixes to IBGP neighbors with better
preference. Routers to apply the policy: R5.
.
Note
We recommend that you approach the BGP
routing policy design tasks, consisting of
many individual elements, as a single
integrated task. This approach allows you
to better design and implement your policy
structure.

Note
The example solution provided in this
section is one of several possible
approaches. You can accomplish the task
by designing your policies in different way.
TASK COMPLETION
• R1:
lab@R1> configure
[edit]
lab@R1# set rib inet6.0 aggregate route 2008:4498::/32
lab@R1# set aggregate route 172.27.0.0/16
lab@R1# show
rib inet6.0 {
aggregate {
route 2008:4498::/32;
}
}
aggregate {
route 172.27.0.0/16;
}
router-id 172.27.255.1;
lab@R1# top edit policy-options
lab@R1# set community C2-routes members 7211:65512
lab@R1# set community P-routes members 7211:1111
lab@R1# set community T1-routes members 7211:2222
lab@R1# edit policy-statement from-T1

[edit policy-options policy-statement from-T1]
lab@R1# set term 1 from route-filter 0.0.0.0/0 prefix-length-range /8-/24

lab@R1# set term 1 to rib inet.0

lab@R1# set term 1 then community add T1-routes


lab@R1# set term 2 to rib inet6.0


lab@R1# set term 3 then reject

lab@R1# show
term 1 {
from {
route-filter 0.0.0.0/0 prefix-length-range /8-/24;
}
to rib inet.0;
then {
community add T1-routes;
accept;
}
}
term 2 {
to rib inet6.0;
then accept;
}
term 3 {
then reject;
}

lab@R1# up
lab@R1# edit policy-statement to-T1
[edit policy-options policy-statement to-T1]

lab@R1# set term 1 from protocol aggregate

lab@R1# set term 1 from route-filter 172.27.0.0/16 exact




lab@R1# set term 2 from rib inet6.0




lab@R1# set term 3 from route-filter 2008:4498::/32 longer



lab@R1# set term 4 from community P-routes


lab@R1# show
term 1 {
from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
protocol aggregate;
rib inet6.0;
}
then accept;
}
term 3 {
from {
rib inet6.0;
route-filter 2008:4498::/32 longer;
}
then reject;
}

term 4 {
from {
protocol bgp;
community P-routes;
}
then reject;
}

lab@R1# up
lab@R1# edit policy-statement from-P
[edit policy-options policy-statement from-P]


lab@R1# set term 4 then community add P-routes



lab@R1# show
term 1 {
from {
}
then {
community add P-routes;
accept;
}
}
term 2 {
then reject;
}

lab@R1# up
lab@R1# edit policy-statement to-P
[edit policy-options policy-statement to-P]






lab@R1# set term 2 from community T1-routes



lab@R1# show
term 1 {
from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
protocol bgp;
community [ T1-routes T2-routes ];
}
then reject;
}

lab@R1# top
[edit]
lab@R1# set protocols bgp group T1 import from-T1
[edit]
lab@R1# set protocols bgp group T1 export to-T1
[edit]
lab@R1# set protocols bgp group P import from-P
[edit]
lab@R1# set protocols bgp group P export to-P
[edit]
commit complete
lab@R1>

• R2:
lab@R2> configure
[edit]
lab@R2# set rib inet6.0 aggregate route 2008:4498::/32
lab@R2# show
rib inet6.0 {
aggregate {
route 2008:4498::/32;
}
}
aggregate {
route 172.27.0.0/16;
}
router-id 172.27.255.2;



lab@R2# set term 1 then local-preference 200






lab@R2# show
term 1 {
from {
}
to rib inet.0;
then {
local-preference 200;
accept;
}
}
term 2 {
to rib inet6.0;
then accept;
}
term 3 {
then reject;
}

lab@R2# up















lab@R2# show
term 1 {
from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
protocol aggregate;
rib inet6.0;
}
then accept;
}
term 3 {
from {
rib inet6.0;
}
then reject;
}
term 4 {
from {
protocol bgp;
community P-routes;
}
then reject;

}

lab@R2# up









lab@R2# show
term 1 {
from {
}
to rib inet.0;
then {
accept;
}
}
term 2 {
to rib inet6.0;
then accept;
}
term 3 {
then reject;
}

lab@R2# up




lab@R2# set term 1 then as-path-prepend "3895077211 3895077211"













lab@R2# set term 5 then as-path-prepend "3895077211 3895077211"


lab@R2# show
term 1 {
from {
protocol aggregate;
}
then {
as-path-prepend "3895077211 3895077211";
accept;
}
}
term 2 {
from {
protocol aggregate;
rib inet6.0;
}
then accept;
}
term 3 {
from {
rib inet6.0;
}
then reject;
}
term 4 {
from {
protocol bgp;
community P-routes;
}
then reject;
}
term 5 {
from protocol bgp;
then {
as-path-prepend "3895077211 3895077211";
accept;
}
}

lab@R2# top
[edit]
lab@R2# set protocols bgp group T1-T2 neighbor 172.27.0.66 import from-T1
[edit]
lab@R2# set protocols bgp group T1-T2 neighbor 172.27.0.66 export to-T1
[edit]
lab@R2# set protocols bgp group T1-T2 neighbor 172.27.0.38 import from-T2

[edit]
lab@R2# set protocols bgp group T1-T2 neighbor 172.27.0.38 export to-T2
[edit]
commit complete
lab@R2>
• R3:
lab@R3> configure
[edit]
lab@R3# show
aggregate {
route 172.27.0.0/16;
}
router-id 172.27.255.3;
lab@R3# edit policy-statement from-P



lab@R3# set term 1 then community add P-routes



lab@R3# show
term 1 {
from {
}
then {
community add P-routes;
accept;
}
}
term 2 {
then reject;
}

lab@R3# up
lab@R3# edit policy-statement to-P








lab@R3# show
term 1 {

from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
protocol bgp;
community [ T1-routes T2-routes ];
}
then reject;
}

lab@R3# top
[edit]
[edit]
lab@R3# set protocols bgp group P export to-P
[edit]
commit complete
lab@R3>
• R5:
lab@R5> configure
[edit]
lab@R5# show
static {
route 202.202.0.1/32 next-hop [ 172.27.0.50 172.27.0.74 ];
}
aggregate {
route 172.27.0.0/16;
}
router-id 172.27.255.5;

[edit policy-options policy-statement from-C2]

lab@R5# up
lab@R5# edit policy-statement from-C2


lab@R5# set term 1 then community add C2-routes


lab@R5# show
term 1 {
then {
community add C2-routes;
accept;
}
}

lab@R5# up
lab@R5# edit policy-statement to-C2
[edit policy-options policy-statement to-C2]




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

lab@R5# top
[edit]
lab@R5# set protocols bgp group C2 import from-C2
[edit]
lab@R5# set protocols bgp group C2 export to-C2
[edit]
commit complete
lab@R5>
TASK VERIFICATION
Verify that all BGP policy tasks are correctly configured.
• R1:
lab@R1> show route advertising-protocol bgp 172.27.0.34 172.27.0.0/16

* 172.27.0.0/16 Self I

* 2008:4498::/32 Self {65432} I
lab@R1> show route advertising-protocol bgp 172.27.0.34 community-name P-routes
lab@R1> show route advertising-protocol bgp 172.27.0.34 community-name

C2-routes

* 202.202.0.0/24 Self 65512 65512 I
* 202.202.2.0/24 Self 65512 65512 I
* 202.202.3.0/24 Self 65512 65512 I
* 202.202.4.0/24 Self 65512 65512 I
* 202.202.5.0/24 Self 65512 65512 I
* 202.202.6.0/24 Self 65512 65512 I
* 202.202.7.0/24 Self 65512 65512 I
lab@R1> show route table inet.0 protocol bgp terse | match "(/2[5-9])|(/3[0-2])"
lab@R1> show route active-path 111.111.1/24 detail | match Communities

Communities: 7211:2222

* 172.27.0.0/16 Self I

T1-routes

T2-routes

C2-routes

* 202.202.0.0/24 Self 65512 65512 I
* 202.202.2.0/24 Self 65512 65512 I
* 202.202.3.0/24 Self 65512 65512 I
* 202.202.4.0/24 Self 65512 65512 I
* 202.202.5.0/24 Self 65512 65512 I
* 202.202.6.0/24 Self 65512 65512 I
* 202.202.7.0/24 Self 65512 65512 I
lab@R1> show route active-path 150.150/24 detail | match Communities



AS path: 1342930876 I
> to 172.27.0.2 via ge-0/0/3.0
AS path: 1342930876 I
> to 172.27.0.2 via ge-0/0/3.0
[BGP/170] 19:06:13, localpref 100
AS path: 1342930876 I
> to 172.27.0.34 via ge-0/0/2.0


AS path: 2087403078 I
> to 172.27.0.13 via ge-0/0/6.0
AS path: 2087403078 I
> to 172.27.0.13 via ge-0/0/6.0
[BGP/170] 19:06:12, localpref 100
AS path: 2087403078 I
> to 172.27.0.30 via ge-0/0/1.0


AS path: 65512 65512 I
> to 172.27.0.9 via ae0.0
AS path: 65512 65512 I
> to 172.27.0.9 via ae0.0
[BGP/170] 19:06:20, localpref 100
AS path: 2087403078 65512 I
> to 172.27.0.30 via ge-0/0/1.0
• R2:

* 172.27.0.0/16 Self I

* 2008:4498::/32 Self {65432} I


C2-routes

* 202.202.0.0/24 Self 65512 65512 I
* 202.202.2.0/24 Self 65512 65512 I
* 202.202.3.0/24 Self 65512 65512 I
* 202.202.4.0/24 Self 65512 65512 I
* 202.202.5.0/24 Self 65512 65512 I
* 202.202.6.0/24 Self 65512 65512 I
* 202.202.7.0/24 Self 65512 65512 I
lab@R2> show route active-path 111.111.1/24 detail | match

"Communities|Localpref"
Localpref: 200

* 172.27.0.0/16 Self 3895077211
3895077211 [3895077211] I

* 2008:4498::/32 Self {65432} I

C2-routes

* 202.202.0.0/24 Self 3895077211
3895077211 [3895077211] 65512 65512 I
* 202.202.2.0/24 Self 3895077211
3895077211 [3895077211] 65512 65512 I

* 202.202.3.0/24 Self 3895077211
3895077211 [3895077211] 65512 65512 I
* 202.202.4.0/24 Self 3895077211
3895077211 [3895077211] 65512 65512 I
* 202.202.5.0/24 Self 3895077211
3895077211 [3895077211] 65512 65512 I
* 202.202.6.0/24 Self 3895077211
3895077211 [3895077211] 65512 65512 I
* 202.202.7.0/24 Self 3895077211
3895077211 [3895077211] 65512 65512 I

111.111.1.0/24 *[BGP/170] 3d 00:23:15, localpref 200

AS path: 1342930876 I
> to 172.27.0.66 via ge-0/0/3.0


AS path: 2087403078 I
> to 172.27.0.1 via ge-0/0/1.0
to 172.27.0.6 via ge-0/0/4.0
AS path: 2087403078 I
> to 172.27.0.1 via ge-0/0/1.0
to 172.27.0.6 via ge-0/0/4.0


AS path: 65512 65512 I
> to 172.27.0.6 via ge-0/0/4.0
AS path: 65512 65512 I
> to 172.27.0.6 via ge-0/0/4.0
• R3:

* 172.27.0.0/16 Self I


T1-routes

T2-routes

C2-routes

* 202.202.0.0/24 Self 65512 65512 I
* 202.202.2.0/24 Self 65512 65512 I
* 202.202.3.0/24 Self 65512 65512 I
* 202.202.4.0/24 Self 65512 65512 I
* 202.202.5.0/24 Self 65512 65512 I
* 202.202.6.0/24 Self 65512 65512 I
* 202.202.7.0/24 Self 65512 65512 I
lab@R3> show route active-path 150.150/24 detail |match "Communities|Localpref"

Localpref: 200


AS path: 1342930876 I
> to 172.27.0.14 via ge-0/0/1.0
to 172.27.0.18 via ge-0/0/2.0

150.150.0.0/24 *[BGP/170] 3d 01:19:44, localpref 200

AS path: 2087403078 I
> to 172.27.0.62 via ge-0/0/5.0


AS path: 65512 65512 I
> to 172.27.0.25 via ge-0/0/3.0
[BGP/170] 3d 01:19:50, localpref 200
AS path: 2087403078 65512 I
> to 172.27.0.62 via ge-0/0/5.0
• R4:


AS path: 1342930876 I
> to 172.27.0.5 via ge-0/0/1.0


AS path: 2087403078 I
> to 172.27.0.17 via ge-0/0/5.0


AS path: 65512 65512 I
> to 172.27.0.22 via ge-0/0/4.0
• R5:

* 172.27.0.0/16 Self I
lab@R5> show route advertising-protocol bgp 202.202.0.1 111.111.1/24

* 111.111.1.0/24 Self 1342930876 I
lab@R5> show route advertising-protocol bgp 202.202.0.1 150.150/24

* 150.150.0.0/24 Self 2087403078 I

lab@R5> show route active-path 202.202/24 detail | match
"Communities|Localpref"
Localpref: 300


AS path: 1342930876 I
> to 172.27.0.21 via ge-0/0/2.0
AS path: 1342930876 I
> to 172.27.0.21 via ge-0/0/2.0


AS path: 2087403078 I
> to 172.27.0.26 via ge-0/0/1.0
AS path: 2087403078 I
> to 172.27.0.26 via ge-0/0/1.0


AS path: 65512 65512 I
> to 172.27.0.50 via ge-0/0/4.0
to 172.27.0.74 via ge-0/0/5.0
202.202.0.1/32 *[Static/5] 3d 01:22:04
> to 172.27.0.50 via ge-0/0/4.0
to 172.27.0.74 via ge-0/0/5.0
Part 2: Implementing IBGP with Confederations
In this lab part, you will redesign the IBGP topology using a confederation network.
TASK 20
Migrate the existing IBGP network to Confederation. Route
Reflection is not permitted. No router in your AS may have
more than two IBGP and CBGP neighbors altogether. The
failure of a link or router in the network must not result
in any connectivity issues or isolation of routers.

TASK INTERPRETATION
You must redesign the IBGP topology using a confederation network. The statement
that the failure of a link or router in the network must not result in any connectivity
issues or isolation of routers means that your network design must provide
redundant paths in your AS.
TASK COMPLETION
• R1:
lab@R1> configure
[edit]
lab@R1# delete routing-options autonomous-system
[edit]
lab@R1# set autonomous-system 65000
lab@R1# set confederation 3895077211
lab@R1# set confederation members 65000
lab@R1# show
rib inet6.0 {
aggregate {
route 2008:4498::/32;
}
}
aggregate {
route 172.27.0.0/16;
}
router-id 172.27.255.1;
confederation 3895077211 members [ 65000 65001 65002 ];
lab@R1# top
[edit]
lab@R1# delete protocols bgp group cluster-1

[edit]
lab@R1# edit protocols bgp group IBGP
[edit protocols bgp group IBGP]

lab@R1# set type internal

lab@R1# set local-address 172.27.255.1

lab@R1# set family inet unicast

lab@R1# set family inet6 labeled-unicast explicit-null

lab@R1# set authentication-key juniper

lab@R1# set export nhs


lab@R1# show
type internal;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
authentication-key "$9$pLjwOIcKMXbs4yls4aZkquO1"; ## SECRET-DATA
export nhs;
neighbor 172.27.255.3;

lab@R1# up

lab@R1# edit group CBGP
[edit protocols bgp group CBGP]

lab@R1# set type external

lab@R1# set multihop






lab@R1# set peer-as 65001


lab@R1# show
type external;
multihop;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
authentication-key "$9$R9CcrvxNboJDWLJDikTQEcy"; ## SECRET-DATA
export nhs;
peer-as 65001;
neighbor 172.27.255.2;

commit complete
lab@R1>
• R2:
lab@R2> configure
[edit]
[edit]

lab@R2# show
rib inet6.0 {
aggregate {
route 2008:4498::/32;
}
}
aggregate {
route 172.27.0.0/16;
}
router-id 172.27.255.2;
lab@R2# top
[edit]
[edit]









lab@R2# show
type internal;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
authentication-key "$9$TF6ABIcvWxp0WxNdg4QFn"; ## SECRET-DATA
export nhs;
neighbor 172.27.255.4;

lab@R2# up











lab@R2# show
type external;
multihop;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
authentication-key "$9$PTF/uORlK8CtK8X7sYfTz"; ## SECRET-DATA
export nhs;
peer-as 65000;
neighbor 172.27.255.1;

commit complete
lab@R2>
• R3:
lab@R3> configure
[edit]
[edit]
lab@R3# show

aggregate {
route 172.27.0.0/16;
}
router-id 172.27.255.3;
lab@R3# top
[edit]
[edit]
lab@R3# delete protocols bgp group internal
[edit]







lab@R3# set export IPv6-direct


lab@R3# show
type internal;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}

authentication-key "$9$iqPQ/CuEclFnclKMN-Hqm"; ## SECRET-DATA
neighbor 172.27.255.1;

lab@R3# up












lab@R3# show
type external;
multihop;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
authentication-key "$9$eeNMLNs2aikPdbkP5Q9CKM8"; ## SECRET-DATA

peer-as 65002;
neighbor 172.27.255.5;

commit complete
lab@R3>
• R4:
lab@R4> configure
[edit]
[edit]
ederation member[edit routing-options]

lab@R4# show
router-id 172.27.255.4;
lab@R4# top
[edit]
[edit]
lab@R4# delete protocols bgp group internal
[edit]








lab@R4# show
type internal;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
authentication-key "$9$u4C5BRSvWxwYoreYoJGq.0BI"; ## SECRET-DATA
export IPv6-direct;
neighbor 172.27.255.2;

lab@R4# up











lab@R4# show
type external;
multihop;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
authentication-key "$9$fQ390BEevLApvLxNY25QF"; ## SECRET-DATA
export IPv6-direct;
peer-as 65002;
neighbor 172.27.255.5;

commit complete
lab@R4>
• R5:
lab@R5> configure
[edit]
[edit]

lab@R5# show
static {
route 202.202.0.1/32 next-hop [ 172.27.0.50 172.27.0.74 ];
}
aggregate {
route 172.27.0.0/16;
}
router-id 172.27.255.5;
lab@R5# top
[edit]
lab@R5# set interfaces ge-0/0/1 unit 0 family inet6
[edit]
lab@R5# set interfaces ge-0/0/2 unit 0 family inet6
[edit]
[edit]
[edit]
lab@R5# edit protocols bgp group CBGP








lab@R5# set neighbor 172.27.255.3 peer-as 65000


lab@R5# show
type external;
multihop;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
authentication-key "$9$PTF/uORlK8CtK8X7sYfTz"; ## SECRET-DATA
export nhs;
neighbor 172.27.255.3 {
peer-as 65000;
}
neighbor 172.27.255.4 {
peer-as 65001;
}

commit complete
lab@R5>
TASK VERIFICATION
Verify that IBGP sessions are established successfully and the external routes are
active and reachable on all routers in your AS.
• R1:
inet.0 1773 889 0 0 0 0
inet6.0 36 35 0 0 0 0

172.27.0.30 2087403078 195 201 0 0 1:28:45 0/
24/23/0 0/0/0/0
172.27.0.34 1342930876 607 203 0 0 1:28:49
Establ
inet.0: 0/860/855/0
inet6.0: 1/1/1/0
172.27.255.2 65001 633 1001 0 0 1:11:03
Establ
inet.0: 866/866/866/0
inet6.0: 17/18/18/0
172.27.255.3 65000 120 581 0 0 50:48
Establ
inet.0: 23/23/23/0
inet6.0: 17/17/17/0


AS path: (65001) 1342930876 I
> to 172.27.0.2 via ge-0/0/3.0
[BGP/170] 01:28:57, localpref 100
AS path: 1342930876 I
> to 172.27.0.34 via ge-0/0/2.0


AS path: 2087403078 I
> to 172.27.0.13 via ge-0/0/6.0
[BGP/170] 01:29:01, localpref 100
AS path: 2087403078 I
> to 172.27.0.30 via ge-0/0/1.0


AS path: (65002) 65512 65512 I
> to 172.27.0.9 via ae0.0
[BGP/170] 01:29:09, localpref 100
AS path: 2087403078 65512 I
> to 172.27.0.30 via ge-0/0/1.0

Tree Index 1

Tree Index 2
Tree Index 3
Tree Index 4
Tree Index 5
• R2:
inet.0 1744 1734 0 0 0 0
inet6.0 38 36 0 0 0 0
172.27.0.38 1342930876 650 171 0 0 1:15:34
Establ
inet.0: 856/861/856/0
inet6.0: 1/1/1/0
172.27.0.66 1342930876 578 172 0 0 1:15:38
Establ
inet.0: 855/860/855/0
inet6.0: 1/1/1/0
172.27.255.1 65000 1012 643 0 0 1:15:33
Establ
inet.0: 23/23/23/0
inet6.0: 17/18/18/0
172.27.255.4 65001 80 551 0 0 33:14 Establ
inet.0: 0/0/0/0
inet6.0: 17/18/18/0

111.111.1.0/24 *[BGP/170] 01:15:45, localpref 200

AS path: 1342930876 I
> to 172.27.0.66 via ge-0/0/3.0


AS path: (65000) 2087403078 I
> to 172.27.0.6 via ge-0/0/4.0
to 172.27.0.1 via ge-0/0/1.0


AS path: (65000 65002) 65512 65512 I
> to 172.27.0.6 via ge-0/0/4.0

Tree Index 1
Tree Index 2
Tree Index 3
Tree Index 4
Tree Index 5
• R3:
inet.0 897 889 0 0 0 0
inet6.0 34 34 0 0 0 0
172.27.0.62 2087403078 158 161 0 0 1:11:18 16/
24/23/0 0/0/0/0
172.27.255.1 65000 626 163 0 0 1:11:10
Establ
inet.0: 866/866/866/0
inet6.0: 18/18/18/0
172.27.255.5 65002 542 575 0 0 29:20
Establ
inet.0: 7/7/7/0
inet6.0: 0/0/0/0
2008:4498::2 65432 158 162 0 0 1:11:14
Establ
inet6.0: 16/16/16/0


AS path: (65001) 1342930876 I
> to 172.27.0.14 via ge-0/0/1.0
to 172.27.0.18 via ge-0/0/2.0

150.150.0.0/24 *[BGP/170] 01:11:32, localpref 200

AS path: 2087403078 I
> to 172.27.0.62 via ge-0/0/5.0



AS path: (65002) 65512 65512 I
> to 172.27.0.25 via ge-0/0/3.0
[BGP/170] 01:11:39, localpref 200
AS path: 2087403078 65512 I
> to 172.27.0.62 via ge-0/0/5.0

Tree Index 1
Tree Index 2
Tree Index 3
Tree Index 4
Tree Index 5
lab@R3> show route ::/0 exact

::/0 *[BGP/170] 01:11:40, localpref 100, from 172.27.255.1

AS path: 1342930876 I
> to 172.27.0.14 via ge-0/0/1.0, Push 2
lab@R3> show route 2008:4498:0:1::/64

2008:4498:0:1::/64 *[BGP/170] 00:49:42, localpref 100, from 172.27.255.1

AS path: (65001) I
> to 172.27.0.18 via ge-0/0/2.0, Push 2
lab@R3> show route 2008:4498:2::/64

2008:4498:2::/64 *[BGP/170] 00:49:47, localpref 100, from 172.27.255.1

AS path: (65001) 65432 I
> to 172.27.0.18 via ge-0/0/2.0, Push 2
• R4:
inet.0 912 889 0 0 0 0
inet6.0 52 34 0 0 0 0

172.27.255.2 65001 593 121 0 0 52:18
Establ
inet.0: 889/889/889/0
inet6.0: 17/18/18/0
172.27.255.5 65002 489 568 0 0 32:25
Establ
inet.0: 0/23/23/0
inet6.0: 1/18/18/0
2008:4498:0:1::2 65432 117 123 0 0 52:22
Establ
inet6.0: 16/16/16/0


AS path: 1342930876 I
> to 172.27.0.5 via ge-0/0/1.0


AS path: (65000) 2087403078 I
> to 172.27.0.17 via ge-0/0/5.0
AS path: (65002 65000) 2087403078 I
> to 172.27.0.17 via ge-0/0/5.0


AS path: (65000 65002) 65512 65512 I
> to 172.27.0.22 via ge-0/0/4.0
AS path: (65002) 65512 65512 I
> to 172.27.0.22 via ge-0/0/4.0

Tree Index 1
Tree Index 2
Tree Index 3
Tree Index 4
Tree Index 5



AS path: (65002 65000) 1342930876 I
> to 172.27.0.10 via ae0.0, Push 2
AS path: 1342930876 I
> to 172.27.0.5 via ge-0/0/1.0, Push 2
lab@R4> show route 2008:4498:0:1::/64

2008:4498:0:1::/64 *[Direct/0] 1d 01:21:23

> via ge-0/0/2.0
2008:4498:0:1::1/128
*[Local/0] 1d 01:21:24
Local via ge-0/0/2.0
lab@R4> show route 2008:4498:2::/64

2008:4498:2::/64 *[BGP/170] 00:52:57, localpref 100

AS path: 65432 I
> to 2008:4498:0:1::2 via ge-0/0/2.0
• R5
inet.0 1771 889 0 0 0 0
inet6.0 69 35 0 0 0 0
172.27.255.3 65000 701 708 0 0 1:44:42
Establ
inet.0: 882/882/882/0
inet6.0: 35/35/35/0
172.27.255.4 65001 707 648 0 0 1:44:33
Establ
inet.0: 0/882/882/0
inet6.0: 0/34/34/0
202.202.0.1 65512 699 699 0 0 1:44:51 7/
7/7/0 0/0/0/0



AS path: (65000 65001) 1342930876 I
> to 172.27.0.21 via ge-0/0/2.0
AS path: (65001) 1342930876 I
> to 172.27.0.21 via ge-0/0/2.0


AS path: (65000) 2087403078 I
> to 172.27.0.26 via ge-0/0/1.0
AS path: (65001 65000) 2087403078 I
> to 172.27.0.26 via ge-0/0/1.0


AS path: 65512 65512 I
> to 172.27.0.50 via ge-0/0/4.0
to 172.27.0.74 via ge-0/0/5.0
202.202.0.1/32 *[Static/5] 23:23:50
> to 172.27.0.50 via ge-0/0/4.0
to 172.27.0.74 via ge-0/0/5.0

Tree Index 1
Tree Index 2
Tree Index 3
Tree Index 4
Tree Index 5


Lab 7
BGP Troubleshooting (Detailed)
Overview
In this lab, you will have to troubleshoot a BGP network including IBGP, EBGP, and routing
policies according to the provided task list. You will have 1.5 hours to complete the lab.
guide.
regarding the interpretation of each task, followed by step-by-step instructions.
The initial lab setup is shown below:
• OSPF is the core IGP protocol. The OSPF domain is divided into two areas. R1
and R2 routers are located in Area 0, R5 router is in Area 1. R3 and R4 routers
are ABRs with links in both Area 0 and Area 1.
• LDP is configured as the core MPLS protocol on all routers in your AS.
• Your IBGP network is configured using route reflection design with one route
reflection cluster and two route reflectors: R3 and R4. All IBGP sessions use
the lo0.0 interface IP address.
• All IBGP sessions in your autonomous system are authenticated using MD5
authentication using the key juniper.
• BGP next-hop-self policy is used to resolve the BGP next hop for IPv4 prefixes
on all routers in your AS except for R4.
• EBGP over IPv4 sessions are configured to C2 Customer, Peer (P), and Transit
(T) neighbors. EBGP session to C2 is configured to load balance over the two
links that connect R5 and C2 using only one BGP session.
• EBGP over IPv6 sessions are configured to C1 and C3 routers. The
communication among C1, C3, and the Transit routers T1 and T2 is provided
using 6PE technology.
• The R3 and R4 are configured with prefix limit with maximum 12 prefixes
allowed from customer routers C1 and C3. If this limit is exceeded, the routers
should generate the syslog message but the sessions should remain active.
www.juniper.net BGP Troubleshooting (Detailed) • Lab 7–1

10.b.10.3
• All routers in your AS are configured to log BGP sessions state changes to
syslog.
• Policies are implemented at R1, R2, R3, and R5 routers that should
advertise a summary route representing local AS IPv4 range to the
Peer (P), Transit provider (T1 and T2), and the C2 Customer.
• Policies are implemented at R1 and R2 routers that should advertise only
a summary route representing local AS IPv6 range to the Transit provider
and block all other IPv6 routes.
• Policies are implemented at R1, R2, and R3 routers that should not
accept IPv4 routes with a mask shorter than /8 or longer than
/24 from the Peer (P) and Transit provider.
• A policy is implemented at R5 that should prefer routes received from C2
Customer directly to the same prefix learned from either a Peer (P) or a
Transit provider.
• Using CLI operational mode commands, troubleshoot the IBGP and EBGP
sessions and discover the source of problems.
• Using CLI operational and configuration mode, ensure that all IBGP and
EBGP sessions are up, running, and support appropriate address
families. You are not allowed to change OSPF area design.
• All Peer (P), Transit provider (T1, T2), and C2 IPv4 prefixes, except of the
prefixes with mask shorter than /8 or longer than /24, must be active
and reachable on all routers in your AS.
• All Customer C1 and C3 IPv6 prefixes as well as IPv6 default routes
advertised by the Transit provider must be active and reachable on R1,
R2, R3, and R4 routers.
• Troubleshoot the implemented policies and ensure that they operate as
expected.
• Ensure that no suboptimal paths are taken for all routes.
Lab 7–2 • BGP Troubleshooting (Detailed) www.juniper.net

Part 1: Troubleshooting and Repairing BGP Sessions
In this lab part, you will troubleshoot and repair the BGP sessions using CLI
operational mode commands and then using CLI configuration mode to adjust the
BGP settings to ensure that all BGP sessions are operational and can convey routing
for the required address families.
Note
We recommend that you to carefully
examine the initial setup checklist before
you start troubleshooting.
Your Autonomous system number is 3895077211

R1 EBGP peers data:
P - 172.27.0.30, AS 2087403078
T1 - 172.27.0.34, AS 1342930876
R2 EBGP peers data:
T1 - 172.27.0.66, AS AS 1342930876
T2 - 172.27.0.38, AS AS 1342930876
R3 EBGP peers data:
P - 172.27.0.62, AS 2087403078
C1 - 2008:4498::2, AS 65432
R4 EBGP peers data:
C3 - 2008:4498:0:1::2, AS 65432
R5 EBGP peers data:
C2 - 202.202.0.1, AS 65512
TASK 1
associated with your devices. Log in as user ops with the password ops123.
TASK COMPLETION
• R1:
R1 (ttyd0)
login: ops
Password:

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

• R3:
R3 (ttyd0)
login: ops
Password:

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

• R5:
R5 (ttyd0)
login: ops
Password:

TASK 2
Using CLI operational mode commands troubleshoot the IBGP
and EBGP sessions and discover the source of problems.
TASK INTERPRETATION
In this step, several problems with BGP sessions are induced. You will be using the
ops user account, which is not allowed to enter the configuration mode. Using
operational mode commands, you must discover the problems.
TASK COMPLETION
• R1:
ops@R1> show bgp summary
inet.0 884 878 0 0 0 0
inet6.0 1 1 0 0 0 0
172.27.0.30 2087403078 39 40 0 0 16:12 23/
24/23/0 0/0/0/0
172.27.0.34 1342930876 450 41 0 0 16:08
Establ

inet.0: 855/860/855/0
inet6.0: 1/1/1/0
172.27.255.3 3895077211 0 0 0 0 50:48
Connect
172.27.255.4 3895077211 0 0 0 0 50:48
Active
The status reveals that two EBGP sessions are established and two IBGP sessions
are either in Active or Connect states. Now check the IBGP sessions.
ops@R1> show bgp neighbor 172.27.255.3
Peer: 172.27.255.3 AS 3895077211 Local: 172.27.255.1 AS 3895077211
Type: Internal State: Active Flags: <>
Last State: Idle Last Event: Start
Last Error: None
Export: [ NHS ]
Options: <Preference LocalAddress AuthKey LogUpDown AddressFamily Refresh>
Address families configured: inet-unicast inet6-labeled-unicast
Local Address: 172.27.255.1 Holdtime: 90 Preference: 170
NLRI inet6-labeled-unicast: ExplicitNull
Number of flaps: 0

Peer: 172.27.255.4 AS 3895077211 Local: 172.27.255.1 AS 3895077211
Type: Internal State: Active Flags: <>
Last Error: None
Export: [ NHS ]
Number of flaps: 0
The output shows that the sessions are configured to the peers 172.27.255.3 and
172.27.255.4 using 172.27.255.1 local address. The sessions use authentication.
We first check the IP connectivity between the peers.
ops@R1> ping 172.27.255.3 source 172.27.255.1 count 2
PING 172.27.255.3 (172.27.255.3): 56 data bytes
64 bytes from 172.27.255.3: icmp_seq=0 ttl=64 time=3.468 ms
--- 172.27.255.3 ping statistics ---


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

Both IBGP peers are reachable. Next, check the syslog messages file.
ops@R1> show log messages | match MD5
Jul 29 00:08:37 R1 /kernel: tcp_auth_ok: Packet from 172.27.255.4:53991 wrong
MD5 digest
MD5 digest
MD5 digest
MD5 digest
The output shows that TCP packets received from both 172.27.255.3 and
172.27.255.4 cannot be authenticated.
Synopsis: The probable source of the peering problem is authentication.
• R2:
inet.0 1721 1711 0 0 0 0
inet6.0 0 0 0 0 0 0
172.27.0.38 1342930876 580 100 0 0 43:42
856/861/856/0 0/0/0/0
172.27.0.66 1342930876 579 100 0 0 43:38
855/860/855/0 0/0/0/0
172.27.255.3 3895077211 0 0 0 0 1:07:58
Active
172.27.255.4 3895077211 0 0 0 0 1:07:58
Active
The status reveals that two EBGP sessions are established and two IBGP sessions
are either in Active or Connect states. Let us check the IBGP sessions.
Peer: 172.27.255.3 AS 3895077211 Local: 172.27.255.2 AS 3895077211
Type: Internal State: Active Flags: <ImportEval>
Last Error: None
Export: [ NHS ]
Number of flaps: 0

Peer: 172.27.255.4 AS 3895077211 Local: 172.27.255.2 AS 3895077211
Last Error: None
Export: [ NHS ]

Number of flaps: 0
172.27.255.4 using 172.27.255.2 local address. The sessions use authentication.
First, check the IP connectivity between the peers.
PING 172.27.255.3 (172.27.255.3): 56 data bytes
^C
--- 172.27.255.3 ping statistics ---

PING 172.27.255.4 (172.27.255.4): 56 data bytes
^C
--- 172.27.255.4 ping statistics ---
None of the IBGP peers is reachable. Let us check IGP routing.
ops@R2> show route 172.27.255.3

172.27.255.3/32 *[OSPF/10] 00:58:48, metric 2

> to 172.27.0.1 via ge-0/0/1.0
to 172.27.0.6 via ge-0/0/4.0

172.27.255.4/32 *[OSPF/10] 00:58:53, metric 1

> to 172.27.0.6 via ge-0/0/4.0
Both remote loopbacks are in the routing table. We try to ping them again without
specifying the source address.
ops@R2> ping 172.27.255.3 count 2
PING 172.27.255.3 (172.27.255.3): 56 data bytes
--- 172.27.255.3 ping statistics ---

ops@R2> ping 172.27.255.4 count 2

PING 172.27.255.4 (172.27.255.4): 56 data bytes

--- 172.27.255.4 ping statistics ---

Both remote loopbacks are now reachable.
ops@R2> show ospf interface
ge-0/0/1.0 BDR 0.0.0.0 172.27.255.1 172.27.255.2 1
ge-0/0/4.0 DR 0.0.0.0 172.27.255.2 172.27.255.4 1
The output shows that lo0.0 is not configured in OSPF.
Synopsis: The probable source of the peering problem is bidirectional IGP
reachability.
• R3:
inet.0 24 24 0 0 0 0
inet6.0 0 0 0 0 0 0
172.27.0.62 2087403078 171 174 0 0 1:16:28 24/
24/24/0 0/0/0/0
172.27.255.1 3895077211 0 0 0 0 1:34:13
Connect
172.27.255.2 3895077211 0 0 0 0 1:34:13
Active
172.27.255.5 3895077211 0 0 0 0 1:34:13
Connect
2008:4498::2 65432 0 62 0 0 1:34:13 Active
The output shows that all sessions except for one EBGP session to 172.27.0.62 are
either in Active or Connect state. Check the IBGP sessions first. R1 and R2
inspection revealed the source of problems.
MD5 digest
MD5 digest

172.27.0.0/16 *[Aggregate/130] 01:39:12

Reject
The output of the last two commands confirms the previously made assumptions.
ops@R3> show bgp group
Group Type: Internal AS: 3895077211 Local AS: 3895077211
Name: Clients Index: 0 Flags: <Export Eval>

Export: [ NHS IPv6-DIRECT ]
Options: <Cluster>
Holdtime: 0
Total peers: 3 Established: 0
172.27.255.1
172.27.255.2
172.27.255.5
Group Type: External Local AS: 3895077211

Name: P Index: 1 Flags: <Export Eval>
Export: [ to-P ]
Holdtime: 0
172.27.0.62+53096
inet.0: 24/24/24/0
Group Type: External AS: 65432 Local AS: 3895077211

Name: C1 Index: 2 Flags: <Export Eval>
Options: <As Override>
Options: <AdvertisePeerAs>
Holdtime: 0
2008:4498::2
Groups: 3 Peers: 5 External: 2 Internal: 3 Down peers: 4 Flaps: 0

inet.0 24 24 0 0 0 0
inet6.0 0 0 0 0 0 0
The show bgp summary command did not show a session to the 172.27.255.4
neighbor. The output confirms that the peering session to R4 (172.27.255.4) is not
configured. This error prevents the R3 and R4 from exchanging with EBGP-learned
routes in this topology.
Peer: 172.27.255.5+179 AS 3895077211 Local: 172.27.255.4 AS 3895077211
Type: Internal State: Connect (route reflector client)Flags:
<ImportEval>
Last State: Active Last Event: ConnectRetry
Last Error: None
Options: <Preference LocalAddress AuthKey LogUpDown Cluster AddressFamily
Refresh>
Number of flaps: 0
The output shows that the session is configured to the peer 172.27.255.5 using the
172.27.255.3 local address. The session uses authentication. First check the IP
connectivity between the peers.
PING 172.27.255.5 (172.27.255.5): 56 data bytes
^C

--- 172.27.255.5 ping statistics ---

172.27.255.5/32 *[OSPF/10] 01:42:53, metric 1

> to 172.27.0.25 via ge-0/0/3.0
ops@R3> ping 172.27.255.5 count 2

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

The output of the last three commands reveals a bidirectional IGP reachability
problem.
ge-0/0/1.0 BDR 0.0.0.0 172.27.255.1 172.27.255.3 1
ge-0/0/2.0 DR 0.0.0.0 172.27.255.3 172.27.255.4 1
lo0.0 DR 0.0.0.0 172.27.255.3 0.0.0.0 0
ge-0/0/3.0 DR 0.0.0.1 172.27.255.3 172.27.255.5 1
The R3 lo0.0 is configured in OSPF. The reachability problem is most probably
related to R5 configuration.
Check the EBGP session to C1 (2008:4498::2).
ops@R3> show bgp neighbor 2008:4498::2
Peer: 2008:4498::2 AS 65432 Local: 2008:4498::1 AS 3895077211
Type: External State: Active Flags: <ImportEval>
Last Error: Open Message Error
Options: <Preference LogUpDown AddressFamily PeerAS PrefixLimit Refresh As
Override>
Address families configured: inet6-unicast
Holdtime: 90 Preference: 170
Number of flaps: 0
Error: 'Open Message Error' Sent: 43 Recv: 0
The output shows that the session is configured to 2008:4498::2 from
2008:4498::1 local address. There is an “Open Message Error” status message in
the output. This error most probably indicates misconfigured BGP settings on one or
both peers. To troubleshoot it, we recommend configuring traceoptions, which
we perform in the next step because user ops does not have sufficient privileges.
ops@R3> ping 2008:4498::2 count 2
PING6(56=40+8+8 bytes) 2008:4498::1 --> 2008:4498::2
--- 2008:4498::2 ping6 statistics ---

The output shows that IPv6 connectivity works.
Synopsis: The source of peering problems:
– R1 is authentication key mismatch;
– R2 is bidirectional IGP reachability. R2 loopback address is not
known in OSPF;
– R4 is absence of IBGP session configured;
– R5 is bidirectional IGP reachability, most probably incorrect routing
configuration on R5;
– C1 is misconfigured BGP parameters.
• R4:
inet.0 0 0 0 0 0 0
inet6.0 0 0 0 0 0 0
172.27.255.1 3895077211 0 0 0 0 2:08:27
Active
172.27.255.2 3895077211 0 0 0 0 2:08:27
Active
172.27.255.5 3895077211 0 0 0 0 2:08:27
Active
2008:4498:0:1::2 65432 51 100 0 25 1:24 Idle
The output shows that all IBGP sessions stay in active state and the EBGP session is
in the idle state. First check the IBGP sessions. R1 and R2 inspection reveals the
source of problems.
MD5 digest
MD5 digest

The output of the last two commands confirms the previously made assumptions.
ops@R4> show bgp group
Group Type: Internal AS: 3895077211 Local AS: 3895077211
Name: Clients Index: 0 Flags: <Export Eval>
Options: <Cluster>
Holdtime: 0
172.27.255.1

172.27.255.2
172.27.255.5
Group Type: External AS: 65432 Local AS: 3895077211

Name: C3 Index: 1 Flags: <Export Eval>
Options: <As Override>
Holdtime: 0
2008:4498:0:1::2
Groups: 2 Peers: 4 External: 1 Internal: 3 Down peers: 4 Flaps: 36

inet.0 0 0 0 0 0 0
inet6.0 0 0 0 0 0 0
The show bgp summary command did not show a session to the 172.27.255.3
neighbor. The output confirms that the peering session to R3 (172.27.255.3) is not
configured, which prevents the R3 and R4 from exchanging with EBGP-learned
routes in this topology.
Peer: 172.27.255.5+179 AS 3895077211 Local: 172.27.255.4 AS 3895077211
Type: Internal State: Connect (route reflector client)Flags:
<ImportEval>
Last State: Active Last Event: ConnectRetry
Last Error: None
Options: <Preference LocalAddress AuthKey LogUpDown Cluster AddressFamily
Refresh>
Number of flaps: 0
The output shows that the session is configured to the peer 172.27.255.5 using the
172.27.255.4 local address. The session uses authentication. First check the IP
connectivity between the peers.
PING 172.27.255.5 (172.27.255.5): 56 data bytes
^C
--- 172.27.255.5 ping statistics ---

172.27.255.5/32 *[OSPF/10] 02:27:54, metric 1

> to 172.27.0.22 via ge-0/0/4.0
ops@R4> ping 172.27.255.5 count 2

PING 172.27.255.5 (172.27.255.5): 56 data bytes

--- 172.27.255.5 ping statistics ---

The output of the last three commands reveals a bidirectional IGP reachability
problem.
ae0.0 DR 0.0.0.0 172.27.255.4 172.27.255.1 1
ge-0/0/1.0 BDR 0.0.0.0 172.27.255.2 172.27.255.4 1
ge-0/0/5.0 BDR 0.0.0.0 172.27.255.3 172.27.255.4 1
lo0.0 DR 0.0.0.0 172.27.255.4 0.0.0.0 0
ge-0/0/4.0 DR 0.0.0.1 172.27.255.4 172.27.255.5 1
The R4 lo0.0 is configured in OSPF. The reachability problem is most probably
related to R5 configuration.
Check the EBGP session to C3 (2008:4498:0:1::2).
ops@R4> show bgp neighbor 2008:4498:0:1::2
Peer: 2008:4498:0:1::2 AS 65432 Local: 2008:4498:0:1::1 AS 3895077211
Type: External State: Idle Flags: <PrefixLimitIdle>
Last State: Established Last Event: RecvUpdate
Last Error: Cease
Options: <Preference LogUpDown AddressFamily PeerAS PrefixLimit Refresh As
Override>
Address families configured: inet6-unicast
Number of flaps: 31
Last flap event: RecvUpdate
Error: 'Cease' Sent: 31 Recv: 0
The output shows that the session is configured to 2008:4498:0:1::2 from
2008:4498:0:1::1 local address. A “Cease” status message is in the output. This
error probably indicates that the session was dropped because of some restrictions.
ops@R4> show log messages | match Cease
Jul 29 00:05:29 R4 rpd[1068]: bgp_rt_maxprefixes_check_common:6856:
NOTIFICATION sent to 2008:4498:0:1::2 (External AS 65432): code 6 (Cease)
subcode 1 (Maximum Number of Prefixes Reached) AFI: 2 SAFI: 1 prefix limit 12
ops@R4> show log messages | match NOTIFICATION

Jul 29 00:05:29 R4 rpd[1068]: bgp_rt_maxprefixes_check_common:6856:
NOTIFICATION sent to 2008:4498:0:1::2 (External AS 65432): code 6 (Cease)
subcode 1 (Maximum Number of Prefixes Reached) AFI: 2 SAFI: 1 prefix limit 12
Jul 29 00:06:01 R4 rpd[1068]: bgp_pp_recv:2961: NOTIFICATION sent to
2008:4498:0:1::2+64490 (proto): code 2 (Open Message Error) subcode 5
(authentication failure), Reason: no group for 2008:4498:0:1::2+64490
(proto) from AS 65432 found (peer idled due to prefix-limit violation),
dropping him

The output shows that the session was dropped because the maximum prefix limit
was exceeded. This drop is a configuration error because according to the initial
setup, EBGP sessions should not be dropped when the prefix limit is reached.
known in OSPF;
– C3 is misconfigured BGP prefix limit action.
• R5:
inet.0 0 0 0 0 0 0
172.27.255.3 3895077211 0 0 0 0 3:24:56
Active
172.27.255.4 3895077211 0 0 0 0 3:24:56
Active
202.202.0.1 65512 0 0 0 0 3:24:56 Idle
The status reveals that the IBGP sessions are in Active state and the EBGP sessions
are in Idle state. Check the IBGP sessions first.
Peer: 172.27.255.3 AS 3895077211 Local: 172.27.255.5 AS 3895077211
Last Error: None
Export: [ NHS ]
Options: <Preference LocalAddress AuthKey LogUpDown Refresh>
Number of flaps: 0

Peer: 172.27.255.4 AS 3895077211 Local: 172.27.255.5 AS 3895077211
Last Error: None
Export: [ NHS ]
Options: <Preference LocalAddress AuthKey LogUpDown Refresh>
Number of flaps: 0

172.27.255.4 using the 172.27.255.5 local address. First check the IP connectivity
between the peers.
PING 172.27.255.3 (172.27.255.3): 56 data bytes
ping: sendto: No route to host
^C
--- 172.27.255.3 ping statistics ---

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

172.27.0.0/16 *[Aggregate/130] 03:33:14

Reject

172.27.0.0/16 *[Aggregate/130] 03:33:18

Reject
The output of the last four commands shows that the remote loopbacks are not
reachable.
ops@R5> show route protocol ospf

0.0.0.0/0 *[OSPF/10] 03:35:00, metric 11

to 172.27.0.26 via ge-0/0/1.0
> to 172.27.0.21 via ge-0/0/2.0
224.0.0.5/32 *[OSPF/10] 03:35:20, metric 1
MultiRecv
mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

The output shows that R5 knows only the default route from OSPF because R5 is
located in OSPF totally stubby area. Next, check the EBGP session.

Peer: 202.202.0.1 AS 65512 Local: 172.27.255.5 AS 3895077211
Type: External State: Idle Flags: <PeerInterfaceError ImportEval>
Last State: NoState Last Event: NoEvent
Last Error: None
Export: [ to-C2 ]
Options: <Preference LocalAddress LogUpDown PeerAS Refresh>
Number of flaps: 0
The output shows that the session stays in Idle state, which means R5 cannot try to
establish the EBGP session. This error is most probably indicates misconfigured BGP
settings. To troubleshoot it, we recommend to configure traceoptions, which we
perform in the next step because user ops does not have sufficient privileges.
PING 202.202.0.1 (202.202.0.1): 56 data bytes

The output shows that the two peers can reach loopbacks of each other.
• R3 is incorrectly configured routing;
• R4 is incorrectly configured routing;
• C2 is misconfigured BGP parameters.
TASK 3
Log in to the routers as user lab with the password lab123.
TASK COMPLETION
• R1:
R1 (ttyd0)
login: lab
Password:
• R2:
R2 (ttyd0)
login: lab
Password:

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

TASK 4
Using CLI operational and configuration mode ensure that
all IBGP and EBGP sessions are up, running and support
appropriate address families. You are not allowed to change
the OSPF area design.
TASK INTERPRETATION
The task is straightforward.
TASK COMPLETION
• R1:
Synopsis: The probable source of the peering problem is authentication.
lab@R1> configure
[edit]
lab@R1# set protocols bgp group IBGP authentication-key juniper
[edit]
lab@R1# commit
commit complete
[edit]
lab@R1# run show bgp summary

inet.0 908 879 0 0 0 0
inet6.0 1 1 0 0 0 0
172.27.0.30 2087403078 659 666 0 0 4:59:21 23/
24/23/0 0/0/0/0
172.27.0.34 1342930876 1070 669 0 0 4:59:17
Establ
inet.0: 855/860/855/0
inet6.0: 1/1/1/0
172.27.255.3 3895077211 34 511 0 0 13:05
Establ
inet.0: 1/24/24/0
inet6.0: 0/0/0/0
172.27.255.4 3895077211 32 441 0 0 12:50
Establ
inet.0: 0/0/0/0
inet6.0: 0/0/0/0
The output shows that all sessions are established now and the peers negotiated
appropriate address families.
• R2:
Synopsis: The probable source of the peering problem is bidirectional IGP
reachability.
lab@R2> configure
[edit]
lab@R2# set protocols ospf area 0 interface lo0.0
[edit]
lab@R2# commit
commit complete
[edit]
inet.0 3478 1735 0 0 0 0
inet6.0 2 1 0 0 0 0
172.27.0.38 1342930876 1155 682 0 0 5:05:58
856/861/856/0 0/0/0/0
172.27.0.66 1342930876 1154 682 0 0 5:05:54
855/860/855/0 0/0/0/0
172.27.255.3 3895077211 416 481 0 0 58
Establ
inet.0: 1/879/879/0
inet6.0: 1/1/1/0
172.27.255.4 3895077211 413 410 0 0 6
Establ

inet.0: 23/878/878/0
inet6.0: 0/1/1/0
The output shows that all sessions are established now, but EBGP sessions have
negotiated only the IPv4 address family.
[edit]
lab@R2# run show bgp neighbor 172.27.0.66
Peer: 172.27.0.66+52140 AS 1342930876 Local: 172.27.0.65+179 AS 3895077211
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ to-T1 ] Import: [ from-T1 ]
Options: <Preference LogUpDown PeerAS Multipath Refresh>
Number of flaps: 0
Peer ID: 111.111.0.1 Local ID: 172.27.255.2 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
Local Interface: ge-0/0/3.0
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast inet6-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast inet6-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 1342930876)
Peer does not support Addpath
Table inet.0 Bit: 10001
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 855
Received prefixes: 860
Accepted prefixes: 855
Suppressed due to damping: 0
Advertised prefixes: 25
Last traffic (seconds): Received 3 Sent 21 Checked 48
Input messages: Total 1164Updates 482Refreshes 0Octets 43654
Output messages: Total 692Updates 3Refreshes 0Octets 13406
Output Queue[0]: 0
[edit]
lab@R2# run show bgp neighbor 172.27.0.38
Peer: 172.27.0.38+51554 AS 1342930876 Local: 172.27.0.37+179 AS 3895077211
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ to-T2 ] Import: [ from-T2 ]
Options: <Preference LogUpDown PeerAS Multipath Refresh>
Number of flaps: 0

Peer ID: 111.111.0.2 Local ID: 172.27.255.2 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
Local Interface: ge-0/0/2.0
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast inet6-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast inet6-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 1342930876)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 856
Received prefixes: 861
Accepted prefixes: 856
Suppressed due to damping: 0
Advertised prefixes: 25
Last traffic (seconds): Received 23 Sent 21 Checked 11
Input messages: Total 1166Updates 483Refreshes 0Octets 43728
Output messages: Total 694Updates 3Refreshes 0Octets 13444
Output Queue[0]: 0
edit]
lab@R2# show protocols bgp group T1-T2
type external;
peer-as 1342930876;
multipath;
neighbor 172.27.0.66 {
import from-T1;
export to-T1;
}
neighbor 172.27.0.38 {
import from-T2;
export to-T2;
}
[edit]
lab@R2# set protocols bgp group T1-T2 family inet unicast
[edit]
lab@R2# set protocols bgp group T1-T2 family inet6 unicast
[edit]
lab@R2# commit
commit complete

[edit]
inet.0 3478 1735 0 0 0 0
inet6.0 4 2 0 0 0 0
172.27.0.38 1342930876 488 8 0 0 1:05
Establ
inet.0: 856/861/856/0
inet6.0: 1/1/1/0
172.27.0.66 1342930876 416 8 0 0 1:09
Establ
inet.0: 855/860/855/0
inet6.0: 1/1/1/0
172.27.255.3 3895077211 436 956 0 0 10:08
Establ
inet.0: 1/879/879/0
inet6.0: 0/1/1/0
172.27.255.4 3895077211 433 885 0 0 9:16
Establ
inet.0: 23/878/878/0
inet6.0: 0/1/1/0
The output now shows that all sessions are established and the peers negotiated
appropriate address families.
• R3:
known in OSPF;
lab@R3> configure
[edit]
lab@R3# set protocols bgp group Clients neighbor 172.27.255.4
[edit]
lab@R3# set protocols bgp group C1 traceoptions file bgp-trace.log
[edit]
lab@R3# set protocols bgp group C1 traceoptions flag open detail

[edit]
lab@R3# commit
commit complete
[edit]
lab@R3# run show log bgp-trace.log
Jul 29 05:28:34 trace_on: Tracing to "/var/log/bgp-trace.log" started
Jul 29 05:30:23.428658 advertising receiving-speaker only capability to
neighbor 2008:4498::2 (External AS 65432)
Jul 29 05:30:23.428743 bgp_send: sending 59 bytes to 2008:4498::2 (External AS
65432)
Jul 29 05:30:23.428772
Jul 29 05:30:23.428772 BGP SEND 2008:4498::1+64511 -> 2008:4498::2+179
Jul 29 05:30:23.428800 BGP SEND message type 1 (Open) length 59
Jul 29 05:30:23.428827 BGP SEND version 4 as 23456 holdtime 90 id 172.27.255.3
parmlen 30
Jul 29 05:30:23.428851 BGP SEND MP capability AFI=2, SAFI=1
Jul 29 05:30:23.428874 BGP SEND Refresh capability, code=128
Jul 29 05:30:23.428898 BGP SEND Refresh capability, code=2
Jul 29 05:30:23.428924 BGP SEND Restart capability, code=64, time=120, flags=
Jul 29 05:30:23.430615 BGP SEND 4 Byte AS-Path capability (65), as_num
3895077211
neighbor 2008:4498::2 (External AS 65432)
Jul 29 05:30:23.437365
Jul 29 05:30:23.437365 BGP RECV 2008:4498::2+179 -> 2008:4498::1+64511
Jul 29 05:30:23.437425 BGP RECV message type 1 (Open) length 59
Jul 29 05:30:23.437451 BGP RECV version 4 as 65422 holdtime 90 id 201.201.0.1
parmlen 30
Jul 29 05:30:23.437475 BGP RECV MP capability AFI=2, SAFI=1
Jul 29 05:30:23.437498 BGP RECV Refresh capability, code=128
Jul 29 05:30:23.437522 BGP RECV Refresh capability, code=2
Jul 29 05:30:23.437546 BGP RECV Restart capability, code=64, time=120, flags=
Jul 29 05:30:23.437570 BGP RECV 4 Byte AS-Path capability (65), as_num 65422
Jul 29 05:30:23.437636 bgp_process_open:2691: NOTIFICATION sent to 2008:4498::2
(External AS 65432): code 2 (Open Message Error) subcode 2 (bad peer AS
number), Reason: peer 2008:4498::2 (External AS 65432) claims 65422, 65432
configured
Jul 29 05:30:23.437662 bgp_send: sending 21 bytes to 2008:4498::2 (External AS
65432)
Jul 29 05:30:23.437689
Jul 29 05:30:23.437689 BGP SEND 2008:4498::1+64511 -> 2008:4498::2+179
Jul 29 05:30:23.437715 BGP SEND message type 3 (Notification) length 21
Jul 29 05:30:23.437739 BGP SEND Notification code 2 (Open Message Error) subcode
2 (bad peer AS number)
The output shows that the remote peer (C1) has incorrectly configured AS 65422.
You cannot change the EBGP peer configuration, hence you must change the R3
peer-as setting.
[edit]
[edit]
lab@R3# commit
commit complete

[edit]
inet.0 1768 890 0 0 0 0
inet6.0 18 17 0 0 0 0
172.27.0.62 2087403078 733 1231 0 0 5:32:31 24/
24/24/0 0/0/0/0
172.27.255.1 3895077211 583 111 0 0 45:59
Establ
inet.0: 855/878/878/0
inet6.0: 1/1/1/0
172.27.255.2 3895077211 994 475 0 0 27:31
Establ
inet.0: 11/866/866/0
inet6.0: 0/1/1/0
172.27.255.4 3895077211 0 0 0 0 9:14
Active
172.27.255.5 3895077211 0 0 0 0 5:50:16
Connect
2008:4498::2 65422 7 9 0 0 2:08 Establ
inet6.0: 16/16/16/0
The output shows that all sessions except for R4 (172.27.255.4) and R5
(172.27.255.5) are established successfully and the peers negotiated the required
address families.
• R4:
known in OSPF;
– C3 is misconfigured BGP prefix limit action.
lab@R4> configure
[edit]
lab@R4# set protocols bgp group Clients neighbor 172.27.255.3
[edit]
lab@R4# delete protocols bgp group C3 family inet6 unicast prefix-limit teardown
[edit]
lab@R4# commit
commit complete

[edit]
inet.0 1768 890 0 0 0 0
inet6.0 34 33 0 0 0 0
172.27.255.1 3895077211 554 150 0 0 1:03:34
Establ
inet.0: 878/878/878/0
inet6.0: 1/1/1/0
172.27.255.2 3895077211 965 514 0 0 44:28
Establ
inet.0: 11/866/866/0
inet6.0: 0/1/1/0
172.27.255.3 3895077211 420 420 0 0 2:31
Establ
inet.0: 1/24/24/0
inet6.0: 16/16/16/0
172.27.255.5 3895077211 0 0 0 0 5:57:10
Connect
2008:4498:0:1::2 65432 8 11 0 0 2:27
Establ
inet6.0: 16/16/16/0
The output shows that all sessions except for R5 (172.27.255.5) are established
successfully and the peers negotiated the required address families.
• R5:
– R3 is incorrectly configured routing;
– R4 is incorrectly configured routing;
lab@R5> configure
[edit]
lab@R5# set protocols bgp group C2 traceoptions file bgp-trace.log
[edit]
lab@R5# set protocols bgp group C2 traceoptions flag all detail
[edit]
lab@R5# delete routing-options aggregate route 172.27.0.0/16
[edit]
lab@R5# commit
commit complete
[edit]
lab@R5# run show log bgp-trace.log

Jul 29 05:59:32 trace_on: Tracing to "/var/log/bgp-trace.log" started
neighbor 202.202.0.1 (External AS 65512)
Jul 29 05:59:55.538714 bgp_4byte_aspath_add_cap():155 AS4-Peer 202.202.0.1
(External AS 65512)(SEND): 4 byte AS capability added, AS 3895077211
The output shows that R5 cannot send any BGP messages to the 202.202.0.1 peer.
type external;
traceoptions {
file bgp-trace.log;
flag all detail;
}
export to-C2;
peer-as 65512;
neighbor 202.202.0.1;
The sessions is EBGP session but multihop setting is missing from the
configuration.
[edit]
lab@R5# set protocols bgp group C2 multihop
[edit]
lab@R5# commit
commit complete
[edit]
inet.0 1787 890 0 0 0 0
172.27.255.3 3895077211 433 23 0 0 9:14
867/890/890/0 0/0/0/0
172.27.255.4 3895077211 434 24 0 0 9:21 16/
890/890/0 0/0/0/0
202.202.0.1 65512 519 515 0 0 1:36 7/
7/7/0 0/0/0/0
The output shows that all sessions are established successfully and the peers
negotiated the required address families.
TASK 5
All Peer (P), Transit provider (T1, T2) and C2 IPv4
prefixes, except of the prefixes with mask shorter than /8
or longer than /24, must be active and reachable on all
routers in your AS.

TASK INTERPRETATION
The task is straightforward. The sample routes we use for troubleshooting in this
step are the following:
• C2 - 202.202.0.0/24
• P - 150.150.0.0/24
• T1 - 35.0.0.0/8 and 111.111.1.0/24
• T2 - 35.0.0.0/8 and 111.111.1.0/24
TASK COMPLETION
• R1:
[edit]
lab@R1# exit

202.202.0.0/24 *[BGP/170] 00:11:37, localpref 100

AS path: 2087403078 65512 I
> to 172.27.0.30 via ge-0/0/1.0
AS path: 2087403078 65512 I
> to 172.27.0.13 via ge-0/0/6.0
AS path: 2087403078 65512 I
> to 172.27.0.9 via ae0.0

150.150.0.0/24 *[BGP/170] 00:12:16, localpref 100

AS path: 2087403078 I
> to 172.27.0.30 via ge-0/0/1.0
AS path: 2087403078 I
> to 172.27.0.13 via ge-0/0/6.0
AS path: 2087403078 I
> to 172.27.0.9 via ae0.0
lab@R1> show route 35/8


35.0.0.0/8 *[BGP/170] 00:20:51, localpref 100
AS path: 1342930876 8918 237 I
> to 172.27.0.34 via ge-0/0/2.0

111.111.1.0/24 *[BGP/170] 00:21:04, localpref 100

AS path: 1342930876 I
> to 172.27.0.34 via ge-0/0/2.0
AS path: 1342930876 I
> to 172.27.0.2 via ge-0/0/3.0
AS path: 1342930876 I
> to 172.27.0.9 via ae0.0
The output shows that all sample routes are active and reachable. At the same time,
C2 route 202.202.0.0/24 is preferred from the Peer (P) that is incorrect. The policy
that should ensure that customer routes are always preferred is probably not
configured or incorrectly configured on R5. The route 35/8 is also expected to be
received from R2 through route reflectors R3 and R4, which is not the case now.
This error can be related to incorrectly configured policy on either R2 or R3 and R4
routers.
lab@R1> show route 202.202/24 detail

202.202.0.0/24 (3 entries, 1 announced)
*BGP Preference: 170/-101
Source: 172.27.0.30
State: <Active Ext>
Local AS: 3895077211 Peer AS: 2087403078
Age: 25:38
Task: BGP_2087403078.172.27.0.30+64998
Announcement bits (3): 0-KRT 5-BGP RT Background 6-Resolve tree 2
AS path: 2087403078 65512 I
Accepted
Localpref: 100
Router ID: 150.150.0.1
BGP Preference: 170/-101
Next hop type: Indirect
Source: 172.27.255.3
Protocol next hop: 172.27.255.3
Indirect next hop: 8fed000 262143
State: <NotBest Int Ext>

Inactive reason: Not Best in its group - Interior > Exterior >
Exterior via Interior
Local AS: 3895077211 Peer AS: 3895077211
Age: 14:12 Metric2: 1
Task: BGP_3895077211.172.27.255.3+55730
AS path: 2087403078 65512 I
Accepted
Localpref: 100
Router ID: 172.27.255.3
Source: 172.27.255.4
Next hop: 172.27.0.9 via ae0.0, selected
Indirect next hop: 913bf00 262148
Inactive reason: Not Best in its group - Interior > Exterior >
Exterior via Interior
Local AS: 3895077211 Peer AS: 3895077211
Task: BGP_3895077211.172.27.255.4+54523
AS path: 2087403078 65512 I (Originator) Cluster list: 0.0.0.1
AS path: Originator ID: 172.27.255.3
Accepted
Localpref: 100
Router ID: 172.27.255.4
lab@R1> show route protocol bgp terse | match "(/2[5-9])|(/3[0-2])"

* 150.150.13.0/25 B 170 100 >172.27.0.13 2087403078 I
lab@R1> show route 150.150.13/25 detail

Source: 172.27.255.3
Indirect next hop: 90fd0f0 262142
Local AS: 3895077211 Peer AS: 3895077211
Age: 5:07:51 Metric2: 1
Task: BGP_3895077211.172.27.255.3+54444
AS path: 2087403078 I
Accepted
Localpref: 100
Router ID: 172.27.255.3

Source: 172.27.255.4
Indirect next hop: 90fd0f0 262142
Inactive reason: Not Best in its group - Cluster list length
Local AS: 3895077211 Peer AS: 3895077211
Age: 4:06:33 Metric2: 1
Task: BGP_3895077211.172.27.255.4+179
AS path: 2087403078 I (Originator) Cluster list: 0.0.0.1
Accepted
Localpref: 100
Router ID: 172.27.255.4
The output reveals that a route with mask longer than /24 is in the routing table.
This route is received from both R3 and R4 with BGP next hop of R3 (172.27.255.3).
Most probably an R3 EBGP policy is configured incorrectly.
lab@R1> show route hidden

12.16.126.192/26 [BGP ] 10:17:45, localpref 100

AS path: 1342930876 8918 10578 14325 ?
> to 172.27.0.34 via ge-0/0/2.0
65.114.168.192/26 [BGP ] 10:17:45, localpref 100
AS path: 1342930876 8918 10886 7082 I
> to 172.27.0.34 via ge-0/0/2.0
65.115.176.32/27 [BGP ] 10:17:45, localpref 100
AS path: 1342930876 8918 10764 20080 3681 4511 4511 4511 I
> to 172.27.0.34 via ge-0/0/2.0
65.127.62.0/27 [BGP ] 10:17:45, localpref 100
AS path: 1342930876 8918 14048 16989 I
> to 172.27.0.34 via ge-0/0/2.0
129.238.116.0/27 [BGP ] 10:17:45, localpref 100
AS path: 1342930876 8918 668 I
> to 172.27.0.34 via ge-0/0/2.0
150.150.13.0/25 [BGP ] 10:17:49, localpref 100
AS path: 2087403078 I
> to 172.27.0.30 via ge-0/0/1.0


Tree Index 1
Tree Index 2
Tree Index 3
No unresolved routes exist.
• R2:
[edit]
lab@R2# exit

AS path: 2087403078 65512 I
> to 172.27.0.6 via ge-0/0/4.0
AS path: 2087403078 65512 I
> to 172.27.0.1 via ge-0/0/1.0
to 172.27.0.6 via ge-0/0/4.0

AS path: 2087403078 I
> to 172.27.0.6 via ge-0/0/4.0
AS path: 2087403078 I
> to 172.27.0.1 via ge-0/0/1.0
to 172.27.0.6 via ge-0/0/4.0

AS path: 1342930876 8918 237 I
> to 172.27.0.6 via ge-0/0/4.0
AS path: 1342930876 8918 237 I
Indirect


111.111.1.0/24 *[BGP/170] 04:53:13, localpref 100

AS path: 1342930876 I
> to 172.27.0.66 via ge-0/0/3.0
The output shows that all sample routes are active and reachable but the 35/8
route is, for some reason, known indirectly from R3 and R4 instead of being learned
from T1 and T2 directly. Moreover, the next hop for the 35/8 route received from R3
is shown as indirect.
lab@R2> show route receive-protocol bgp 172.27.255.3 35/8
* 35.0.0.0/8 172.27.0.34 100 1342930876 8918
237 I
The output shows that the route 35/8 is received from R3 with the original BGP next
hop 172.27.0.34. The problem is related to next-hop-self policy on R1.
lab@R2> show route 172.27.0.34
172.27.0.0/16 *[Aggregate/130] 11:08:32

Reject
lab@R2> show route receive-protocol bgp 172.27.255.4 35/8
* 35.0.0.0/8 172.27.255.4 100 1342930876 8918
237 I
The output shows another problem with BGP next hop. The 35/8 route is received
from R4 with BGP next hop set to R4 loopback address. This output indicates that
R4 incorrectly changes next hop to self for certain prefixes.
* 150.150.13.0/25 B 170 100 172.27.0.1 2087403078 I
Source: 172.27.255.3
Next hop: 172.27.0.1 via ge-0/0/1.0
Indirect next hop: 90f20f0 262143
Local AS: 3895077211 Peer AS: 3895077211

Age: 5:25:34 Metric2: 2
Task: BGP_3895077211.172.27.255.3+53772
AS path: 2087403078 I
Accepted
Localpref: 100
Router ID: 172.27.255.3
Source: 172.27.255.4
Next hop: 172.27.0.1 via ge-0/0/1.0
Indirect next hop: 90f20f0 262143
Inactive reason: Not Best in its group - Cluster list length
Local AS: 3895077211 Peer AS: 3895077211
Age: 4:42:45 Metric2: 2
Task: BGP_3895077211.172.27.255.4+179
Accepted
Localpref: 100
Router ID: 172.27.255.4
The output reveals that a route with a mask longer than /24 is in the routing table.
This route is received from both R3 and R4 with BGP next hop of R3 (172.27.255.3).
Most probably an R3 EBGP policy is configured incorrectly.
6.1.0.0/16 [BGP ] 05:18:41, localpref 100

AS path: 1342930876 8918 668 1455 I
> to 172.27.0.38 via ge-0/0/2.0
[BGP ] 05:18:45, localpref 100
AS path: 1342930876 8918 668 1455 I
> to 172.27.0.66 via ge-0/0/3.0
6.2.0.0/22 [BGP ] 05:18:41, localpref 100
AS path: 1342930876 8918 668 1455 I
> to 172.27.0.38 via ge-0/0/2.0
AS path: 1342930876 8918 668 1455 I
> to 172.27.0.66 via ge-0/0/3.0
6.3.0.0/18 [BGP ] 05:18:41, localpref 100
AS path: 1342930876 8918 668 1455 I
> to 172.27.0.38 via ge-0/0/2.0
AS path: 1342930876 8918 668 1455 I
> to 172.27.0.66 via ge-0/0/3.0
...

Tree Index 1
Tree Index 2
Tree Index 3
Many hidden routes exist but no route is unresolved. The routes with masks longer
than /8 and shorter than /24 appear as hidden, which means that they are filtered
out by an incorrectly configured policy.
• R3:
[edit]
lab@R3# exit

202.202.0.0/24 *[BGP/170] 10:46:17, localpref 100

AS path: 2087403078 65512 I
> to 172.27.0.62 via ge-0/0/5.0
AS path: 2087403078 65512 I
Indirect
AS path: 65512 65512 I
> to 172.27.0.25 via ge-0/0/3.0

150.150.0.0/24 *[BGP/170] 10:46:20, localpref 100

AS path: 2087403078 I
> to 172.27.0.62 via ge-0/0/5.0
AS path: 2087403078 I
Indirect


AS path: 1342930876 8918 237 I
Indirect


AS path: 1342930876 I
> to 172.27.0.14 via ge-0/0/1.0
to 172.27.0.18 via ge-0/0/2.0
AS path: 1342930876 I
Indirect
The output shows that all the sample routes are active and reachable except for
35/8, which shows an indirect next hop. Note that all the routes that are received
from R1 (172.27.255.1) and show Indirect next hop. C2 route 202.202.0.0/24 is
preferred from the Peer (P) that is incorrect. The policy that should ensure that
customer routes are always preferred is not configured or incorrectly configured on
R5.
lab@R3> show route 35/8 detail

Source: 172.27.255.1
Next hop type: Reject
Indirect next hop: 91582d0 262142
Local AS: 3895077211 Peer AS: 3895077211
Age: 1:08:09 Metric2: 0
Task: BGP_3895077211.172.27.255.1+179
AS path: 1342930876 8918 237 I
Accepted
Localpref: 100
Router ID: 172.27.255.1
lab@R3> show route receive-protocol bgp 172.27.255.1

* 6.1.0.0/16 172.27.0.34 100 1342930876 8918
668 1455 I
* 6.2.0.0/22 172.27.0.34 100 1342930876 8918
668 1455 I
* 6.3.0.0/18 172.27.0.34 100 1342930876 8918
668 1455 I
* 6.4.0.0/16 172.27.0.34 100 1342930876 8918
668 1455 I
* 6.5.0.0/19 172.27.0.34 100 1342930876 8918
668 1455 I
...

172.27.0.0/16 *[Aggregate/130] 11:08:59

Reject
The output reveals the problem with the routes received from R1. The next-hop-self
policy is not configured on R1.
* 150.150.13.0/25 B 170 100 >172.27.0.62 2087403078 I

150.150.13.0/25 (1 entry, 1 announced)
Source: 172.27.0.62
State: <Active Ext>
Local AS: 3895077211 Peer AS: 2087403078
Age: 10:54:22
Task: BGP_2087403078.172.27.0.62+53096
AS path: 2087403078 I
Accepted
Localpref: 100
Router ID: 150.150.0.1
The output reveals that a route with a mask longer than /24 is in the routing table.
This output confirms that the policy that must filter these routes is either not
configured or configured incorrectly.

Tree Index 1
Tree Index 2
Tree Index 3
No hidden or unresolved routes exist.

• R4:
[edit]
lab@R4# exit

AS path: 2087403078 65512 I
> to 172.27.0.17 via ge-0/0/5.0
AS path: 65512 65512 I
> to 172.27.0.22 via ge-0/0/4.0

AS path: 2087403078 I
> to 172.27.0.17 via ge-0/0/5.0

AS path: 1342930876 I
> to 172.27.0.5 via ge-0/0/1.0
The output shows that all the sample routes are active and reachable, except for the
35/8 route. C2 route 202.202.0.0/24 is preferred from R3 router with the AS path
2087403078 65512 that is incorrect. The policy that should ensure that customer
routes are always preferred is not configured or incorrectly configured on R5.
lab@R4> show route 35/8 hidden
35.0.0.0/8 [BGP/170] 01:11:19, localpref 100, from 172.27.255.1

AS path: 1342930876 8918 237 I
Unusable


AS path: 1342930876 8918 668 1455 I
Unusable
AS path: 1342930876 8918 668 1455 I
Unusable
AS path: 1342930876 8918 668 1455 I
Unusable
...

Tree Index 1
Tree Index 2
131.123.0.0/16
Protocol Nexthop: 172.27.0.34
Indirect nexthop: 0 -
131.118.0.0/16
131.113.0.0/16
131.112.0.0/16
131.109.0.0/16
...
The outputs reveal the source of problem with hidden routes—next-hop-self policy is
not configured on R1.
• R5:
[edit]
lab@R5# exit


AS path: 65512 65512 I
> to 172.27.0.50 via ge-0/0/4.0
to 172.27.0.74 via ge-0/0/5.0
AS path: 2087403078 65512 I
> to 172.27.0.26 via ge-0/0/1.0

to 172.27.0.21 via ge-0/0/2.0
AS path: 2087403078 65512 I
> to 172.27.0.26 via ge-0/0/1.0
to 172.27.0.21 via ge-0/0/2.0
202.202.0.1/32 *[Static/5] 01:46:52
to 172.27.0.50 via ge-0/0/4.0
> to 172.27.0.74 via ge-0/0/5.0


AS path: 2087403078 I
> to 172.27.0.26 via ge-0/0/1.0
to 172.27.0.21 via ge-0/0/2.0
AS path: 2087403078 I
> to 172.27.0.26 via ge-0/0/1.0
to 172.27.0.21 via ge-0/0/2.0


AS path: 1342930876 8918 237 I
> to 172.27.0.26 via ge-0/0/1.0
to 172.27.0.21 via ge-0/0/2.0


AS path: 1342930876 I
> to 172.27.0.26 via ge-0/0/1.0
to 172.27.0.21 via ge-0/0/2.0
AS path: 1342930876 I
> to 172.27.0.26 via ge-0/0/1.0
to 172.27.0.21 via ge-0/0/2.0
The output shows that all sample routes are active and reachable. The route in
question though, is 35/8.
lab@R5> show route 35/8 detail


Source: 172.27.255.3
Next hop: 172.27.0.21 via ge-0/0/2.0
Indirect next hop: 910d000 262143
Local AS: 3895077211 Peer AS: 3895077211
Age: 1:04:08 Metric2: 11
Task: BGP_3895077211.172.27.255.3+55552
AS path: 1342930876 8918 237 I (Originator) Cluster list:
0.0.0.1
Accepted
Localpref: 100
Router ID: 172.27.255.3

0.0.0.0/0 *[OSPF/10] 11:24:33, metric 11

to 172.27.0.26 via ge-0/0/1.0
> to 172.27.0.21 via ge-0/0/2.0
The output shows that the route 35/8 is reachable from R5 because it has the 0/0
route in its routing table.

Tree Index 1
Tree Index 2
No hidden or unresolved routes exist.
TASK 6
All Customer C1 and C3 IPv6 prefixes as well as IPv6
default route advertised by the Transit provider must be
active and reachable on R1, R2, R3 and R4 routers.

TASK INTERPRETATION
The task is straightforward. The sample routes we use for troubleshooting in this
step are the following:
• C1 - 2008:4498:1::/64
• C3 - 2008:4498:2::/64
• T1 - ::/0
• T2 - ::/0
TASK COMPLETION
• R1:
lab@R1> show route 2008:4498:1::/64


AS path: 65422 I
> to 172.27.0.13 via ge-0/0/6.0, Push 2
AS path: 65422 I
> to 172.27.0.9 via ae0.0, Push 2
lab@R1> show route 2008:4498:2::/64


AS path: 65432 I
> to 172.27.0.9 via ae0.0, Push 2
AS path: 65432 I
> to 172.27.0.9 via ae0.0, Push 2


AS path: 1342930876 I
> to ::172.27.0.34 via ge-0/0/2.0
All sample routes are active and reachable.
• R2:
lab@R2> show route 2008:4498:1::/64


AS path: 65422 I
> to 172.27.0.6 via ge-0/0/4.0, Push 2
AS path: 65422 I
> to 172.27.0.1 via ge-0/0/1.0, Push 2, Push 299792(top)
to 172.27.0.6 via ge-0/0/4.0, Push 2, Push 299776(top)
lab@R2> show route 2008:4498:2::/64


AS path: 65432 I
> to 172.27.0.6 via ge-0/0/4.0, Push 2
AS path: 65432 I
> to 172.27.0.6 via ge-0/0/4.0, Push 2


AS path: 1342930876 I
to ::172.27.0.38 via ge-0/0/2.0
> to ::172.27.0.66 via ge-0/0/3.0
AS path: 1342930876 I
> to ::172.27.0.38 via ge-0/0/2.0
AS path: 1342930876 I
> to 172.27.0.1 via ge-0/0/1.0, Push 2
AS path: 1342930876 I
> to 172.27.0.6 via ge-0/0/4.0, Push 2
• R3:
lab@R3> show route 2008:4498:1::/64

2008:4498:1::/64 *[BGP/170] 06:08:22, localpref 100

AS path: 65422 I
> to 2008:4498::2 via ge-0/0/4.0
lab@R3> show route 2008:4498:2::/64



AS path: 65432 I
> to 172.27.0.18 via ge-0/0/2.0, Push 2


AS path: 1342930876 I
> to 172.27.0.14 via ge-0/0/1.0, Push 2
AS path: 1342930876 I
> to 172.27.0.18 via ge-0/0/2.0, Push 2, Push 299808(top)
to 172.27.0.14 via ge-0/0/1.0, Push 2, Push 299776(top)
• R4:
lab@R4> show route 2008:4498:1::/64


AS path: 65422 I
> to 172.27.0.17 via ge-0/0/5.0, Push 2
lab@R4> show route 2008:4498:2::/64

2008:4498:2::/64 *[BGP/170] 05:53:46, localpref 100

AS path: 65432 I
> to 2008:4498:0:1::2 via ge-0/0/2.0


AS path: 1342930876 I
> to 172.27.0.10 via ae0.0, Push 2
AS path: 1342930876 I
> to 172.27.0.5 via ge-0/0/1.0, Push 2

TASK 7
Troubleshoot the implemented policies and ensure that they
operate as expected.
TASK INTERPRETATION
In the initial lab setup, four sets of policies are implemented:
• Policies implemented at R1, R2, R3, and R5 routers that should advertise
a summary route representing local AS IPv4 range to the Peer (P), Transit
provider (T1 and T2), and the C2 Customer.
• Policies implemented at R1 and R2 routers that should advertise only a
summary route representing local AS IPv6 range to the Transit provider
and block all other IPv6 routes.
• Policies implemented at R1, R2, and R3 routers that should not accept
IPv4 routes with a mask shorter than /8 or longer than /24 from the Peer
(P) and Transit provider.
• A policy implemented at R5 that should prefer routes received from C2
Customer directly to the same prefix learned from either a Peer (P) or a
Transit provider.
Ensure that the policies operate correctly.
TASK COMPLETION
• R1:
First, fix the problems discovered at the previous steps in this part.
lab@R1> configure
[edit]
lab@R1# set policy-options policy-statement NHS term 1 from protocol bgp
[edit]
lab@R1# set policy-options policy-statement NHS term 1 from route-type external
[edit]
lab@R1# set policy-options policy-statement NHS term 1 then next-hop self
[edit]
lab@R1# set protocols bgp group IBGP export NHS
[edit]
lab@R1# commit
commit complete
[edit]
lab@R1# run show route advertising-protocol bgp 172.27.255.3 35/8

* 35.0.0.0/8 Self 100 1342930876 8918
237 I

[edit]

* 35.0.0.0/8 Self 100 1342930876 8918
237 I
The output shows that the problem with next-hop-self policy is fixed.
[edit]
lab@R1# run show route advertising-protocol bgp 172.27.0.30 172.27/16

* 172.27.0.0/16 Self I
[edit]

* 172.27.0.0/16 Self I
The output shows that the local IPv4 range 172.16.0.0/16 is advertised to EBGP
peers.
[edit]
lab@R1# run show route advertising-protocol bgp 172.27.0.34 table inet6.0

* 2008:4498::/32 Self {65422 65432} I
* 2008:4498:1::/64 Self 65422 I
* 2008:4498:1:1::/64 Self 65422 I
* 2008:4498:1:2::/64 Self 65422 I
* 2008:4498:1:3::/64 Self 65422 I
* 2008:4498:1:4::/64 Self 65422 I
* 2008:4498:1:5::/64 Self 65422 I
* 2008:4498:1:6::/64 Self 65422 I
* 2008:4498:1:7::/64 Self 65422 I
* 2008:4498:1:8::/64 Self 65422 I
* 2008:4498:1:9::/64 Self 65422 I
* 2008:4498:1:a::/64 Self 65422 I
* 2008:4498:1:b::/64 Self 65422 I
* 2008:4498:1:c::/64 Self 65422 I
* 2008:4498:1:d::/64 Self 65422 I
* 2008:4498:1:e::/64 Self 65422 I
* 2008:4498:1:f::/64 Self 65422 I
* 2008:4498:2::/64 Self 65432 I
* 2008:4498:2:1::/64 Self 65432 I
* 2008:4498:2:2::/64 Self 65432 I
* 2008:4498:2:3::/64 Self 65432 I
* 2008:4498:2:4::/64 Self 65432 I
* 2008:4498:2:5::/64 Self 65432 I
* 2008:4498:2:6::/64 Self 65432 I

* 2008:4498:2:7::/64 Self 65432 I
* 2008:4498:2:8::/64 Self 65432 I
* 2008:4498:2:9::/64 Self 65432 I
* 2008:4498:2:a::/64 Self 65432 I
* 2008:4498:2:b::/64 Self 65432 I
* 2008:4498:2:c::/64 Self 65432 I
* 2008:4498:2:d::/64 Self 65432 I
* 2008:4498:2:e::/64 Self 65432 I
* 2008:4498:2:f::/64 Self 65432 I
The output shows that export policy incorrectly advertises number of specific IPv6
routes in addition to the local IPv6 range 2008:4498::/32.
[edit]
lab@R1# show policy-options policy-statement to-T1
term 1 {
from {
protocol aggregate;
}
then accept;
}
term 2 {
from {
protocol aggregate;
rib inet6.0;
}
then accept;
}
[edit]
lab@R1# set policy-options policy-statement to-T1 term 3 from rib inet6.0
[edit]
lab@R1# set policy-options policy-statement to-T1 term 3 from route-filter
2008:4498::/32 longer
[edit]
lab@R1# set policy-options policy-statement to-T1 term 3 then reject
[edit]
lab@R1# commit
commit complete
[edit]

* 2008:4498::/32 Self {65422 65432} I
The output shows that the problem with IPv6 export policy is fixed. First fix the
problems discovered at the previous steps in this part.

• R2:
lab@R2> configure
[edit]
lab@R2# show policy-options policy-statement from-T1
term 1 {
from {
as-path AS1342930876;
}
to rib inet.0;
then accept;
}
term 2 {
to rib inet6.0;
then accept;
}
term 3 {
then reject;
}
[edit]
lab@R2# show policy-options policy-statement from-T2
term 1 {
from {
as-path AS1342930876;
}
to rib inet.0;
then accept;
}
term 2 {
to rib inet6.0;
then accept;
}
term 3 {
then reject;
}
[edit]
lab@R2# delete policy-options policy-statement from-T1 term 1 from as-path
[edit]
lab@R2# delete policy-options policy-statement from-T1 term 1 from as-path
[edit]
lab@R2# commit
commit complete
[edit]
lab@R2# run show route hidden terse


12.16.126.192/26 B 100 >172.27.0.38 1342930876 8918
10578 14325 ?
B 100 >172.27.0.66 1342930876 8918
10578 14325 ?
65.114.168.192/26 B 100 >172.27.0.38 1342930876 8918
10886 7082 I
B 100 >172.27.0.66 1342930876 8918
10886 7082 I
65.115.176.32/27 B 100 >172.27.0.38 1342930876 8918
10764 20080 3681 4511 4511 4511 I
B 100 >172.27.0.66 1342930876 8918
10764 20080 3681 4511 4511 4511 I
65.127.62.0/27 B 100 >172.27.0.38 1342930876 8918
14048 16989 I
B 100 >172.27.0.66 1342930876 8918
14048 16989 I
129.238.116.0/27 B 100 >172.27.0.38 1342930876 8918
668 I
B 100 >172.27.0.66 1342930876 8918
668 I
[edit]

* 35.0.0.0/8 Self 100 1342930876 8918
237 I
[edit]

* 35.0.0.0/8 Self 100 1342930876 8918
237 I
The output shows that the problem with EBGP import policy is fixed.
[edit]

* 172.27.0.0/16 Self I
[edit]

* 172.27.0.0/16 Self I
peers.
[edit]

* 2008:4498::/32 Self {65422 65432} I
[edit]

* 2008:4498::/32 Self {65422 65432} I
The output shows that the local IPv6 range 2008:4498::/32 is advertised to EBGP
peers. First fix the problems discovered at the previous steps in this part.
• R3:


AS path: 1342930876 8918 237 I
> to 172.27.0.14 via ge-0/0/1.0
AS path: 1342930876 8918 237 I
> to 172.27.0.18 via ge-0/0/2.0
to 172.27.0.14 via ge-0/0/1.0


AS path: 1342930876 I
> to 172.27.0.14 via ge-0/0/1.0
AS path: 1342930876 I

> to 172.27.0.18 via ge-0/0/2.0
to 172.27.0.14 via ge-0/0/1.0
The output shows that the problem with the routes 35/8 and 111.111.1/24 indirect
next hop is now fixed.
lab@R3> configure
[edit]
lab@R3# show protocols bgp group P
type external;
export to-P;
peer-as 2087403078;
neighbor 172.27.0.62;
[edit]
lab@R3# set policy-options policy-statement from-P term 1 from protocol bgp
[edit]
lab@R3# set policy-options policy-statement from-P term 1 from route-filter
0.0.0.0/0 prefix-length-range /8-/24
[edit]
lab@R3# set policy-options policy-statement from-P term 1 then accept
[edit]
lab@R3# set policy-options policy-statement from-P term 2 then reject
[edit]
lab@R3# show policy-options policy-statement from-P
term 1 {
from {
protocol bgp;
}
then accept;
}
term 2 {
then reject;
}
[edit]
[edit]
lab@R3# commit
commit complete
[edit]
lab@R3# run show route protocol bgp terse | match "(/2[5-9])|(/3[0-2])"
[edit]
lab@R3# run show route hidden

150.150.13.0/25 [BGP ] 13:22:29, localpref 100

AS path: 2087403078 I
> to 172.27.0.62 via ge-0/0/5.0

The output shows that the problem with EBGP import policy is fixed.
[edit]

* 172.27.0.0/16 Self I
peers. First fix the problems discovered at the previous steps in this part.
• R4:


AS path: 1342930876 8918 237 I
> to 172.27.0.10 via ae0.0
AS path: 1342930876 8918 237 I
> to 172.27.0.5 via ge-0/0/1.0


AS path: 1342930876 I
> to 172.27.0.10 via ae0.0
AS path: 1342930876 I
> to 172.27.0.5 via ge-0/0/1.0

The output shows that the problem with the routes 35/8 and 111.111.1/24
reachability through both R1 and R2 is now fixed. First fix the problems discovered
at the previous steps in this part.
• R5:
lab@R5> configure
[edit]

* 202.202.0.0/24 Self 100 65512 65512 I
[edit]

* 202.202.0.0/24 Self 100 65512 65512 I
The output shows that local preference is not set to a higher value to make other
routers in your AS prefer C2 customer routes received directly from the customer.
[edit]
type external;
traceoptions {
file bgp-trace.log;
flag all detail;
}
multihop;
export to-C2;
peer-as 65512;
neighbor 202.202.0.1;
[edit]
lab@R5# set policy-options policy-statement from-C2 term 1 then
local-preference 200
[edit]
lab@R5# show policy-options policy-statement from-C2
term 1 {
then {
}
}
[edit]
lab@R5# set protocols bgp group C2 import from-C2

[edit]
lab@R5# commit
commit complete
[edit]

* 202.202.0.0/24 Self 200 65512 65512 I
[edit]

* 202.202.0.0/24 Self 200 65512 65512 I
The output shows that the problem with policy setting BGP local preference is fixed.
[edit]
The output shows that the local IPv4 range 172.27.0.0/16 is not advertised. To solve
the problem, you must get the route 172.27.0.0/16 from either static or dynamic
routing protocol. The static route is not allowed. You cannot configure an aggregate
route because it will lead to dropping the IBGP sessions. You cannot use OSPF or
LDP because R5 is in the totally stubby area. The only remaining option is to deliver
the route using BGP. Note that the following configuration is applied on R3 and R4
routers.
• R3:
[edit]
lab@R3# set policy-options policy-statement LOCAL-RANGE term 1 from protocol
aggregate
[edit]
lab@R3# set policy-options policy-statement LOCAL-RANGE term 1 from
route-filter 172.27.0.0/16 exact
[edit]
lab@R3# set policy-options policy-statement LOCAL-RANGE term 1 then next-hop
172.27.0.26
[edit]
lab@R3# set policy-options policy-statement LOCAL-RANGE term 1 then accept
[edit]
lab@R3# show policy-options policy-statement LOCAL-RANGE
term 1 {
from {
protocol aggregate;
}

then {
next-hop 172.27.0.26;
accept;
}
}
[edit]
lab@R3# set protocols bgp group Clients neighbor 172.27.255.5 export NHS
[edit]
lab@R3# set protocols bgp group Clients neighbor 172.27.255.5 export LOCAL-RANGE
[edit]
lab@R3# show protocols bgp group Clients
type internal;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
authentication-key "$9$H.fz9A0hSe36SevW-dk.P"; ## SECRET-DATA
export [ NHS IPv6-DIRECT ];
cluster 0.0.0.1;
neighbor 172.27.255.1;
neighbor 172.27.255.2;
neighbor 172.27.255.5 {
export [ NHS LOCAL-RANGE ];
}
neighbor 172.27.255.4;
[edit]
lab@R3# commit
commit complete
[edit]

* 172.27.0.0/16 172.27.0.26 100 I
• R4:
lab@R4> configure
[edit]
lab@R4# set routing-options aggregate route 172.27.0.0/16

[edit]
lab@R4# set policy-options policy-statement LOCAL-RANGE term 1 from protocol
aggregate
[edit]
lab@R4# set policy-options policy-statement LOCAL-RANGE term 1 from
route-filter 172.27.0.0/16 exact
[edit]
lab@R4# set policy-options policy-statement LOCAL-RANGE term 1 then next-hop
172.27.0.21
[edit]
lab@R4# set policy-options policy-statement LOCAL-RANGE term 1 then accept
[edit]
lab@R4# show policy-options policy-statement LOCAL-RANGE
term 1 {
from {
protocol aggregate;
}
then {
next-hop 172.27.0.21;
accept;
}
}
[edit]
lab@R4# set protocols bgp group Clients neighbor 172.27.255.5 export NHS
[edit]
lab@R4# set protocols bgp group Clients neighbor 172.27.255.5 export LOCAL-RANGE
[edit]
lab@R4# show protocols bgp group Clients
type internal;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
authentication-key "$9$R01crvxNboJDWLJDikTQEcy"; ## SECRET-DATA
export [ NHS IPv6-DIRECT ];
cluster 0.0.0.1;
neighbor 172.27.255.1;
neighbor 172.27.255.2;
neighbor 172.27.255.5 {
export [ NHS LOCAL-RANGE ];
}
neighbor 172.27.255.3;

[edit]
lab@R4# commit
commit complete
[edit]

* 172.27.0.0/16 172.27.0.21 100 I
R3 and R4 now advertise the 172.27.0.0/16 route to R5 using BGP next hops that
R5 can resolve.
• R5:
[edit]

* 172.27.0.0/16 Self I
TASK 8
Ensure there are no suboptimal paths taken for all routes.
TASK INTERPRETATION
An incorrectly implemented BGP policy can influence the path traffic normally takes
using IGP shortest path. Ensure that traffic follows the IGP shortest path for all the
external BGP-learned destinations.
TASK COMPLETION
• R1:
[edit]
lab@R1# exit
lab@R1> traceroute 202.202.0.1

1 172.27.0.9 (172.27.0.9) 7.941 ms 7.115 ms 7.884 ms
2 172.27.0.22 (172.27.0.22) 7.920 ms 7.328 ms 6.646 ms
3 202.202.0.1 (202.202.0.1) 6.958 ms 9.708 ms 6.701 ms

1 150.150.0.1 (150.150.0.1) 7.418 ms 5.056 ms 7.913 ms

traceroute: sendto: No route to host
1 traceroute: wrote 111.111.0.1 40 chars, ret=-1
^C

1 172.27.0.34 (172.27.0.34) 9.263 ms !N 7.026 ms !N 8.075 ms !N
IPv4 traffic takes optimal paths.
lab@R1> traceroute 2008:4498:1::1
traceroute6 to 2008:4498:1::1 (2008:4498:1::1) from ::172.27.0.33, 64 hops max,
12 byte packets
1 2008:4498::1 (2008:4498::1) 5.323 ms 4.372 ms 5.273 ms
2 2008:4498:1::1 (2008:4498:1::1) 12.372 ms 9.777 ms 10.217 ms

12 byte packets
1 2008:4498:0:1::1 (2008:4498:0:1::1) 5.714 ms 7.332 ms 8.522 ms
2 2008:4498:2::1 (2008:4498:2::1) 6.407 ms 7.720 ms 7.018 ms
• R2:
[edit]
lab@R2# exit

1 172.27.0.6 (172.27.0.6) 7.308 ms 7.584 ms 7.717 ms
2 172.27.0.22 (172.27.0.22) 12.258 ms 11.609 ms 9.427 ms
3 202.202.0.1 (202.202.0.1) 11.055 ms 8.979 ms 10.982 ms

1 172.27.0.6 (172.27.0.6) 7.002 ms 7.082 ms 6.985 ms
2 172.27.0.10 (172.27.0.10) 9.243 ms 7.951 ms 7.211 ms
3 150.150.0.1 (150.150.0.1) 8.744 ms 8.247 ms 7.004 ms

1 172.27.0.66 (172.27.0.66) 6.890 ms !N 7.111 ms !N 6.913 ms !N
The output shows that traffic for 202.202.0.1 and 111.111.1.1 takes optimal paths,
but the traffic going to 150.150.0.1 takes a suboptimal path using R4. This reveals
a potential problem with incorrectly applied policy on R4 that influences traffic
paths.
lab@R2> show route 150.150.0.1 detail

Source: 172.27.255.4

Indirect next hop: 90f21e0 262145
Local AS: 3895077211 Peer AS: 3895077211
Age: 1:49:21 Metric2: 1
Task: BGP_3895077211.172.27.255.4+179
Accepted
Localpref: 100
Router ID: 172.27.255.4
Source: 172.27.255.3
Next hop: 172.27.0.6 via ge-0/0/4.0
Indirect next hop: 8f1c870 -
Inactive reason: Not Best in its group - IGP metric
Local AS: 3895077211 Peer AS: 3895077211
Task: BGP_3895077211.172.27.255.3+55004
AS path: 2087403078 I
Accepted
Localpref: 100
Router ID: 172.27.255.3
The output shows that BGP next hop for the 150.150.0.0/24 is R4 (172.27.255.4)
that confirms that R4 incorrectly applies the next-hop-self policy.
lab@R2> traceroute 2008:4498:1::1 source ::172.27.0.65
12 byte packets
1 * * *
2 2008:4498::1 (2008:4498::1) 6.193 ms 10.604 ms 11.010 ms
3 2008:4498:1::1 (2008:4498:1::1) 7.571 ms 7.836 ms 6.885 ms
lab@R2> traceroute 2008:4498:2::1 source ::172.27.0.65

12 byte packets
1 2008:4498:0:1::1 (2008:4498:0:1::1) 6.335 ms 6.600 ms 6.889 ms
2 2008:4498:2::1 (2008:4498:2::1) 7.904 ms 7.638 ms 8.006 ms
lab@R2> show route 2008:4498:1::1 detail

2008:4498:1::/64 (2 entries, 1 announced)
Source: 172.27.255.4

Label operation: Push 2
Protocol next hop: ::ffff:172.27.255.4
Push 2
Indirect next hop: 919ae00 262148
Local AS: 3895077211 Peer AS: 3895077211
Age: 1:46:57 Metric2: 1
Task: BGP_3895077211.172.27.255.4+179
Announcement bits (3): 0-KRT 1-Aggregate 3-Resolve tree 3
Accepted
Route Label: 2
Localpref: 100
Router ID: 172.27.255.4
Source: 172.27.255.3
Label operation: Push 2, Push 299840(top)
Next hop: 172.27.0.6 via ge-0/0/4.0
Label operation: Push 2, Push 299840(top)
Protocol next hop: ::ffff:172.27.255.3
Push 2
Indirect next hop: 919ac00 262144
Inactive reason: Not Best in its group - IGP metric
Local AS: 3895077211 Peer AS: 3895077211
Age: 1:46:05 Metric2: 2
Task: BGP_3895077211.172.27.255.3+55004
AS path: 65422 I
Accepted
Route Label: 2
Localpref: 100
Router ID: 172.27.255.3
The traceroute shows that IPv6 traffic takes the optimal path, but the detailed
output for the 2008:4498:1::/64 prefix shows that BGP next hop is changed by R4
to self.
• R3:
[edit]
lab@R3# exit

1 172.27.0.25 (172.27.0.25) 7.092 ms 7.606 ms 7.021 ms
2 202.202.0.1 (202.202.0.1) 5.960 ms 6.664 ms 5.875 ms

1 150.150.0.1 (150.150.0.1) 5.860 ms 7.413 ms 4.728 ms


1 172.27.0.14 (172.27.0.14) 6.231 ms 6.136 ms 5.960 ms
2 172.27.0.34 (172.27.0.34) 8.912 ms !N 9.316 ms !N 8.969 ms !N
traceroute6 to 2008:4498:1::1 (2008:4498:1::1) from 2008:4498::1, 64 hops max,
12 byte packets
1 2008:4498:1::1 (2008:4498:1::1) 7.815 ms 5.206 ms 7.972 ms

traceroute6 to 2008:4498:2::1 (2008:4498:2::1) from 2008:4498::1, 64 hops max,
12 byte packets
1 2008:4498:0:1::1 (2008:4498:0:1::1) 4.400 ms 4.540 ms 4.817 ms
2 2008:4498:2::1 (2008:4498:2::1) 6.350 ms 9.018 ms 6.724 ms
• R4:
Fix the problem with next-hop-self policy detected at the previous steps. R4 does not
need the next-hop-self policy in this topology because it does not have IPv4 EBGP
sessions.
[edit]
lab@R4# delete protocols bgp group Clients export NHS
[edit]
lab@R4# delete protocols bgp group Clients neighbor 172.27.255.5 export NHS
[edit]
lab@R4# delete policy-options policy-statement NHS
[edit]
lab@R4# commit
commit complete
Now check that traffic to 150.150/24 destinations takes the optimal path at R2.
• R2:
1 172.27.0.1 (172.27.0.1) 7.066 ms 6.874 ms 6.904 ms
2 150.150.0.1 (150.150.0.1) 7.875 ms 9.434 ms 9.811 ms
The output shows that the traffic takes the optimal path.
• R4:
[edit]
lab@R4# exit


1 172.27.0.22 (172.27.0.22) 17.243 ms 7.727 ms 6.908 ms
2 202.202.0.1 (202.202.0.1) 9.240 ms 10.974 ms 8.413 ms

1 172.27.0.10 (172.27.0.10) 7.552 ms 7.983 ms 8.082 ms
2 150.150.0.1 (150.150.0.1) 9.907 ms 6.169 ms 8.160 ms

1 172.27.0.10 (172.27.0.10) 8.302 ms 8.075 ms 7.912 ms
2 172.27.0.34 (172.27.0.34) 8.949 ms !N 12.552 ms !N 10.761 ms !N
traceroute6 to 2008:4498:1::1 (2008:4498:1::1) from 2008:4498:0:1::1, 64 hops
max, 12 byte packets
1 2008:4498::1 (2008:4498::1) 4.910 ms 6.239 ms 4.957 ms
2 2008:4498:1::1 (2008:4498:1::1) 5.972 ms 7.720 ms 6.687 ms

traceroute6 to 2008:4498:2::1 (2008:4498:2::1) from 2008:4498:0:1::1, 64 hops
max, 12 byte packets
1 2008:4498:2::1 (2008:4498:2::1) 5.869 ms 5.742 ms 5.877 ms
• R5:
[edit]
lab@R5# exit

1 202.202.0.1 (202.202.0.1) 6.918 ms 10.114 ms 5.430 ms

1 172.27.0.26 (172.27.0.26) 7.720 ms 8.417 ms 7.820 ms
2 150.150.0.1 (150.150.0.1) 8.933 ms 8.453 ms 7.762 ms

1 172.27.0.26 (172.27.0.26) 8.235 ms 8.188 ms 8.081 ms
2 172.27.0.14 (172.27.0.14) 9.986 ms 9.250 ms 8.999 ms
3 172.27.0.34 (172.27.0.34) 9.911 ms !N 10.905 ms !N 10.814 ms !N

Lab 8
Multicast Implementation and Troubleshooting (Detailed)
Overview
In this lab, you will be given a list of tasks specific to implementing and troubleshooting
multicast which you will need to accomplish within a specific time frame. You will have
1 hour to complete the simulation.
guide.
• Configure all routers to participate in protocol independent multicast (PIM).
• Ensure that R1 and R2 are rendezvous points (RPs) for all groups in the PIM
domain. All routers should use the closest RP. You must use the virtual IP
address of 172.27.255.11. The RP configuration must support only IPv4.
• Group 224.2.2.2 is critical for Rec2, and they have requested that the
multicast traffic always use the same path to keep traffic loss to a minimum
(except in the event of a failure). You cannot use policy, and you cannot alter
routes in inet.0 to accomplish this task. One static route can be used if needed
to accomplish this task.
• Ensure that joins to source are load-balanced for groups sourced from S1.
www.juniper.net Multicast Implementation and Troubleshooting (Detailed) • Lab 8–1

10.b.10.3
Part 1: Configuring PIM
In this lab part, you will log in to your assigned routers and ensure that you are
running the correct startup configuration file for this lab. Refer to the network
diagram for this lab for topological and configuration details. You will then configure
PIM. You must ensure the RP are configured within the guidelines defined by the
tasks in this lab.
Note
routers. During the exam, you might be
now might save you time troubleshooting
strange issues later.
INITIAL TASK
associated with your devices. Log in as user lab with the password lab123. Verify
OSPF is configured and neighborships are up, and that only the interfaces
connecting the routers have an OSPF neighborship.
TASK COMPLETION
• R1:
R1 (ttyd0)
login: lab
Password:

lab@R1> show configuration protocols ospf
area 0.0.0.0 {
interface all;
disable;
}
}
lab@R1> show ospf neighbor

172.27.0.9 ae0.0 Full 172.27.255.4 128 37
172.27.0.2 ge-0/0/3.0 Full 172.27.255.2 128 39
172.27.0.13 ge-0/0/6.0 Full 172.27.255.3 128 36
lab@R1>
• R2:
R2 (ttyd0)
login: lab
Lab 8–2 • Multicast Implementation and Troubleshooting (Detailed) www.juniper.net

Password:

area 0.0.0.0 {
interface all;
disable;
}
}

172.27.0.1 ge-0/0/1.0 Full 172.27.255.1 128 32
172.27.0.6 ge-0/0/4.0 Full 172.27.255.4 128 34
lab@R2>
• R3:
R3 (ttyd0)
login: lab
Password:

area 0.0.0.0 {
interface all;
disable;
}
}

172.27.0.14 ge-0/0/1.0 Full 172.27.255.1 128 32
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 36
lab@R3>
• R4:
R4 (ttyd0)
login: lab
Password:

area 0.0.0.0 {
interface all;
disable;
}
}

172.27.0.10 ae0.0 Full 172.27.255.1 128 31
172.27.0.5 ge-0/0/1.0 Full 172.27.255.2 128 38
172.27.0.22 ge-0/0/4.0 Full 172.27.255.5 128 38
172.27.0.17 ge-0/0/5.0 Full 172.27.255.3 128 34
lab@R4>
• R5:
R5 (ttyd0)
login: lab
Password:

area 0.0.0.0 {
interface all;
disable;
}
}

172.27.0.26 ge-0/0/1.0 Full 172.27.255.3 128 33
172.27.0.21 ge-0/0/2.0 Full 172.27.255.4 128 36
lab@R5>
TASK 1
Configure all routers to participate in PIM.
Note
We recommend that you include the
configuration steps for the second task
while you are configuring the first task. This
approach will save you some time and
effort as you move through the tasks of this
lab.
TASK 2
Ensure that R1 and R2 are RPs for all groups in the PIM
domain. All routers should use the closest RP. You must use
the virtual IP address of 172.27.255.11. The RP
configuration must only be able to support IPv4.

TASK INTERPRETATION
The task should be straight forward. Knowing that RPs are needed for the next task
tells you that PIM sparse mode (PIM-SM) must be configured. The requirements of
using R1 and R2 as RPs for all groups, and using the closest RP on all routers
reveals that bootstrap or auto-RP is not being used. This also further confirms
PIM-SM is needed and not sparse-dense mode. The requirements that a virtual IP
address must be used, and that the RP configuration must support only IPv4
confirms Multicast Source Discovery Protocol (MSDP) anycast RP must be
configured (instead of PIM anycast RP).
In this task, we configure the same virtual IP address (non-unique) that has been
provided as a secondary loopback address on both R1 and R2 (the required RPs). It
is good practice to configure the unique loopback address as primary to ensure it is
selected as the primary. Next, we set up MSPD between R1 and R2 using the unique
loopback addresses. Finally, set up protocol PIM on all routers. Configure R1 and R2
as a local RP using the non-unique loopback address, and configure all other routers
with a static RP to the non-unique loopback address. You can use interface all
under PIM without configuring a PIM mode, because PIM-SM is the default PIM
mode. Also, if you use interface all, disable the management interface for
best practice.
TASK COMPLETION
• R1:
lab@R1> configure
[edit]
lab@R1# set interfaces lo0 unit 0 family inet address 172.27.255.1/32 primary
[edit]
lab@R1# set interfaces lo0 unit 0 family inet address 172.27.255.11/32
[edit]
lab@R1# show interfaces lo0
unit 0 {
family inet {
address 172.27.255.1/32 {
primary;
}
address 172.27.255.11/32;
}
}
[edit]
lab@R1# set protocols msdp group anycast-rp local-address 172.27.255.1
[edit]
lab@R1# set protocols msdp group anycast-rp peer 172.27.255.2
[edit]
lab@R1# set protocols pim rp local address 172.27.255.11

[edit]
lab@R1# set protocols pim interface all
[edit]
lab@R1# set protocols pim interface ge-0/0/0 disable
[edit]
lab@R1# show protocols
msdp {
group anycast-rp {
peer 172.27.255.2;
}
}
...
pim {
rp {
local {
address 172.27.255.11;
}
}
interface all;
disable;
}
}
[edit]
lab@R1# commit
commit complete
[edit]
lab@R1#
• R2:
lab@R2> configure
[edit]
lab@R2# set interfaces lo0 unit 0 family inet address 172.27.255.2/32 primary
[edit]
lab@R2# set interfaces lo0 unit 0 family inet address 172.27.255.11/32
[edit]
lab@R2# show interfaces lo0
unit 0 {
family inet {
address 172.27.255.2/32 {
primary;
}
address 172.27.255.11/32;
}
}

[edit]
lab@R2# set protocols msdp group anycast-rp local-address 172.27.255.2
[edit]
lab@R2# set protocols msdp group anycast-rp peer 172.27.255.1
[edit]
lab@R2# set protocols pim rp local address 172.27.255.11
[edit]
[edit]
[edit]
lab@R2# show protocols
msdp {
group anycast-rp {
peer 172.27.255.1;
}
}
...
pim {
rp {
local {
address 172.27.255.11;
}
}
interface all;
disable;
}
}
[edit]
lab@R2# commit
commit complete
[edit]
lab@R2#
• R3:
lab@R3> configure
[edit]
lab@R3# set protocols pim rp static address 172.27.255.11
[edit]

[edit]
[edit]
lab@R3# show protocols pim
rp {
static {
address 172.27.255.11;
}
}
interface all;
disable;
}
[edit]
lab@R3# commit
commit complete
[edit]
lab@R3#
• R4:
lab@R4> configure
[edit]
[edit]
[edit]
[edit]
rp {
static {
address 172.27.255.11;
}
}
interface all;
disable;
}
[edit]
lab@R4# commit
commit complete

[edit]
lab@R4#
• R5:
lab@R5> configure
[edit]
[edit]
[edit]
[edit]
rp {
static {
address 172.27.255.11;
}
}
interface all;
disable;
}
[edit]
lab@R5# commit
commit complete
[edit]
lab@R5#
TASK VERIFICATION
Begin your verification by reviewing the status of the RPs on R1 and R2. Verify that
R1 and R2 are local RPs and that they are the RPs for all groups.
• R1:
[edit]
lab@R1# exit
lab@R1> show pim rps extensive

Instance: PIM.master
Address family INET
RP: 172.27.255.11
Learned via: static configuration
Time Active: 2d 12:44:52
Holdtime: 0
Device Index: 130
Subunit: 32769
Interface: ppd0.32769
Group Ranges:
224.0.0.0/4
Anycast PIM local address used: 172.27.255.1
Address family INET6
lab@R1>
• R2:
[edit]
lab@R2# exit

Address family INET
RP: 172.27.255.11
Holdtime: 0
Device Index: 130
Subunit: 32769
Interface: ppd0.32769
Group Ranges:
224.0.0.0/4
Anycast PIM local address used: 172.27.255.2
lab@R2>
Question: Which IP address is the RP for both R1

and R2?
Answer: Both R1 and R2 should have

172.27.255.11 for the RP address.
Question: What is the group range for both RPs?
Answer: Both R1 and R2 should show a group range

of 224.0.0.0/4.

Now that you have verified the RPs, verify the MSDP status and source-actives. The
intradomain MSDP usage for anycast RP covers the requirement for both R1 and R2
being the RP for all groups, the requirement of a virtual IP for the RP, and the
requirement for only IPv4 support. PIM anycast RP could also be used, except it
supports IPv4 and IPv6.
• R1:
lab@R1> show msdp
Peer address Local address State Last up/down Peer-Group SA Count
172.27.255.2 172.27.255.1 Established 2d 13:02:09 anycast-rp 1/1
lab@R1> show msdp source-active

Group address Source address Peer address Originator Flags
224.1.1.1 172.27.0.30 local 172.27.255.1 Accept
224.2.2.2 172.27.0.38 172.27.255.2 172.27.255.2 Accept
224.3.3.3 172.27.0.30 local 172.27.255.1 Accept
• R2:
lab@R2> show msdp
Peer address Local address State Last up/down Peer-Group SA Count
172.27.255.1 172.27.255.2 Established 2d 13:03:21 anycast-rp 2/2
lab@R2> show msdp source-active

Group address Source address Peer address Originator Flags
224.1.1.1 172.27.0.30 172.27.255.1 172.27.255.1 Accept
224.2.2.2 172.27.0.38 local 172.27.255.2 Accept
224.3.3.3 172.27.0.30 172.27.255.1 172.27.255.1 Accept
Question: What is the state of MSDP? How many

SAs does R1 and R2 have?
Answer: The MSDP state should be established. R1

should have 1 SA, and R2 should have 2 SAs.
Finally, you must verify that all other routers use the closest RP. View the status of
the RP on all other routers. Make sure that the active groups using the RP matches
the join to RP. Then check that the join to RP upstream neighbor matches the
shortest path to the RP..
Some of the below outputs might vary

depending on which path R5 chooses to
reach S1.
• R3:
[edit]
lab@R3# exit

Address family INET
RP: 172.27.255.11
Holdtime: 0
Device Index: 131
Subunit: 32769
Interface: ppe0.32769
Group Ranges:
224.0.0.0/4
Active groups using RP:
224.1.1.1
total 1 groups active
lab@R3> show pim join extensive 224.1.1.1

Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 224.1.1.1
Source: *
RP: 172.27.255.11
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/1.0
Upstream neighbor: 172.27.0.14
Upstream state: Join to RP
Downstream neighbors:
Interface: ge-0/0/4.0
172.27.0.58 State: Join Flags: SRW Timeout: 156
Group: 224.1.1.1
Source: 172.27.0.30
Flags: sparse,spt
Upstream state: None, Join to Source
Keepalive timeout: 328
172.27.0.25 State: Join Flags: S Timeout: 176


172.27.255.11/32 *[OSPF/10] 2d 13:33:22, metric 1
> to 172.27.0.14 via ge-0/0/1.0
lab@R3>
Question: Does the active group using the RP match

the best path to the RP?
Answer: Yes. As shown in the output from R3, the

group 224.1.1.1 join to RP uses upstream neighbor
172.27.0.14, which is the same path to the RP. This
output might vary depending on which path R5
chooses to send the join to RP.
• R4:
[edit]
lab@R4# exit

Address family INET
RP: 172.27.255.11
Holdtime: 0
Device Index: 131
Subunit: 32769
Group Ranges:
224.0.0.0/4
224.3.3.3
224.2.2.2
224.1.1.1

Group: 224.1.1.1
Source: *
RP: 172.27.255.11
Upstream interface: ae0.0

Group: 224.1.1.1
Source: 172.27.0.30
Flags: sparse
Upstream state: Prune to RP
Keepalive timeout:
Interface: ge-0/0/4.0 (pruned)
172.27.0.22 State: Prune Flags: SR Timeout: 161

Group: 224.2.2.2
Source: *
RP: 172.27.255.11
Group: 224.2.2.2
Source: 172.27.0.38
Flags: sparse,spt
Upstream state: Join to Source, Prune to RP

172.27.255.11/32 *[OSPF/10] 2d 13:40:18, metric 1

to 172.27.0.5 via ge-0/0/1.0
> to 172.27.0.10 via ae0.0
lab@R4>

• R5:
[edit]
lab@R5# exit

Address family INET
RP: 172.27.255.11
Holdtime: 0
Device Index: 131
Subunit: 32769
Group Ranges:
224.0.0.0/4
224.3.3.3
224.2.2.2
224.1.1.1

Group: 224.1.1.1
Source: *
RP: 172.27.255.11
Group: 224.1.1.1
Source: 172.27.0.30
Flags: sparse,spt

Group: 224.2.2.2
Source: *
RP: 172.27.255.11
Group: 224.2.2.2
Source: 172.27.0.38
Flags: sparse,spt

172.27.255.11/32 *[OSPF/10] 2d 14:04:12, metric 2

to 172.27.0.26 via ge-0/0/1.0
> to 172.27.0.21 via ge-0/0/2.0
lab@R5>
Question: Why does the *,G and S,G for group

224.1.1.1 have a different upstream neighbor?
Answer: With R5 being the designated router for the

receiver, the source tree cut-over took place, and
now the multicast traffic is using the shortest path
from the source (or preferred path). This output
might vary depending on which OSPF path is taken
to the RP—the *,G and S,G might match.

TASK 3
Group 224.2.2.2 is critical for Rec2, and they have
requested that the multicast traffic always uses the same
path to keep traffic loss to a minimum (except in the event
of a failure). You cannot use policy, and you cannot alter
routes in inet.0 to accomplish this task. One static route
can be used if needed to accomplish this task.
TASK INTERPRETATION
The task reveals that group 224.2.2.2 should always use the shared tree and should
not cutover to the source tree or shortest-path tree (SPT). The traffic is critical to
Rec2 and they do not want to lose any traffic during the source tree cutover process.
The easiest way to accomplish this task might be using a policy to not allow the SPT
cutover to take place for group 224.2.2.2 on the last hop router, but policy is not
allowed for this task. The next option is to make sure that the RPT and SPT always
use the same path, so that the SPT cutover does not takes place. R5 has equal cost
paths to the RPs, so there is a chance that currently RPT and SPT are the same
path. We want to rule out that the RPT and SPT use the same path by chance. You
cannot alter inet.0, so you must populate inet.2 with routes that you can alter. This is
done by creating rib-groups to copy interface and OSPF routes into inet.2, and then
applying inet.2 to PIM to be used for the RPF check. Make sure that this
configuration is done on R4 as well, because R4 has the same issue with equal cost
paths to the RP.
TASK COMPLETION
• R5:
lab@R5> configure
[edit]
lab@R5# set rib-groups to_inet.2 import-rib [inet.0 inet.2]
lab@R5# set rib-groups rpf_inet.2 import-rib inet.2
lab@R5# set interface-routes rib-group inet to_inet.2
lab@R5# show
interface-routes {
rib-group inet to_inet.2;
}
static {
route 0.0.0.0/0 next-hop 10.94.175.254;
}
rib-groups {
to_inet.2 {
import-rib [ inet.0 inet.2 ];
}
rpf_inet.2 {
import-rib inet.2;
}
}
lab@R5# top edit protocols
[edit protocols]
lab@R5# set ospf rib-group to_inet.2
[edit protocols]
lab@R5# set pim rib-group inet rpf_inet.2
[edit protocols]
lab@R5# show
ospf {
rib-group to_inet.2;
area 0.0.0.0 {
interface all;
disable;
}
}
}
pim {
rib-group inet rpf_inet.2;
rp {
static {
address 172.27.255.11;
}
}
interface all;
disable;
}
}
[edit protocols]
lab@R5# commit
commit complete
[edit protocols]
lab@R5#
• R4:
lab@R4> configure
[edit]

lab@R4# set rib-groups to_inet.2 import-rib [inet.0 inet.2]
lab@R4# set rib-groups rpf_inet.2 import-rib inet.2
lab@R4# set interface-routes rib-group inet to_inet.2
lab@R4# show
interface-routes {
}
static {
route 0.0.0.0/0 next-hop 10.94.175.254;
}
rib-groups {
to_inet.2 {
}
rpf_inet.2 {
import-rib inet.2;
}
}
[edit protocols]
lab@R4# set ospf rib-group to_inet.2
[edit protocols]
lab@R4# set pim rib-group inet rpf_inet.2
[edit protocols]
lab@R4# show
ospf {
rib-group to_inet.2;
area 0.0.0.0 {
interface all;
disable;
}
}
}
pim {
rp {
static {
address 172.27.255.11;
}
}

interface all;
disable;
}
}
[edit protocols]
lab@R4# commit
commit complete
[edit protocols]
lab@R4#
TASK VERIFICATION
We begin by verifying which table the RPF check is using to the RP and source, and
that the routing table shows the correct routes for the RP and source.
• R5:
[edit protocols]
lab@R5# run show multicast rpf 172.27.0.38
Multicast RPF table: inet.2 , 22 entries
172.27.0.36/30
Protocol: OSPF
Neighbor: 172.27.0.21
[edit protocols]
172.27.255.11/32
Protocol: OSPF
Neighbor: 172.27.0.26
[edit protocols]

172.27.0.36/30 *[OSPF/10] 00:23:21, metric 3

> to 172.27.0.21 via ge-0/0/2.0

172.27.0.36/30 *[OSPF/10] 00:23:21, metric 3

> to 172.27.0.21 via ge-0/0/2.0
[edit protocols]

172.27.255.11/32 *[OSPF/10] 07:19:57, metric 2

> to 172.27.0.26 via ge-0/0/1.0
to 172.27.0.21 via ge-0/0/2.0

172.27.255.11/32 *[OSPF/10] 07:19:57, metric 2

> to 172.27.0.26 via ge-0/0/1.0
to 172.27.0.21 via ge-0/0/2.0
Question: What table is being used for the RPF

check?
Answer: Table inet.2 should be the RPF table.
Question: Is there only one possible next hop for the

route to the RP in table inet.2?
Answer: No. The route has not been altered in inet.2

so that the next-hop of 172.27.0.21 is preferred.
The output may vary and show 172.27.0.21 is
preferred, but you want to ensure that 172.27.0.26
cannot be chosen.
TASK CORRECTION
To ensure that 172.27.0.21 is preferred to match the SPT path in the inet.2 table,
you must make the 172.27.0.21 more preferred. A static route can be used to
resolve this issue. Make sure to apply the same inet.2 configuration on R4.
• R5:
[edit protocols]
lab@R5# set rib inet.2 static route 172.27.255.11/32 next-hop 172.27.0.21
lab@R5# show
interface-routes {
}
rib inet.2 {
static {
route 172.27.255.11/32 next-hop 172.27.0.21;
}
}

static {
route 0.0.0.0/0 next-hop 10.94.175.254;
}
rib-groups {
to_inet.2 {
}
rpf_inet.2 {
import-rib inet.2;
}
}
lab@R5# commit
commit complete
lab@R5#
• R4:
[edit protocols]
lab@R4# set rib inet.2 static route 172.27.255.11/32 next-hop 172.27.0.5
lab@R4# show
interface-routes {
}
rib inet.2 {
static {
route 172.27.255.11/32 next-hop 172.27.0.5;
}
}
static {
route 0.0.0.0/0 next-hop 10.94.175.254;
}
rib-groups {
to_inet.2 {
}
rpf_inet.2 {
import-rib inet.2;
}
}
lab@R4# commit
commit complete

lab@R4#
Now that the route has a defined preferred next-hop, you can verify that the SPT and
RPT match.
• R5:
172.27.0.36/30
Protocol: OSPF
Neighbor: 172.27.0.21
172.27.255.11/32
Protocol: Static
Neighbor: 172.27.0.21

172.27.0.36/30 *[OSPF/10] 00:48:05, metric 3

> to 172.27.0.21 via ge-0/0/2.0

172.27.0.36/30 *[OSPF/10] 00:48:05, metric 3

> to 172.27.0.21 via ge-0/0/2.0

172.27.255.11/32 *[OSPF/10] 07:44:37, metric 2

> to 172.27.0.26 via ge-0/0/1.0
to 172.27.0.21 via ge-0/0/2.0

172.27.255.11/32 *[Static/5] 00:01:23

> to 172.27.0.21 via ge-0/0/2.0

[OSPF/10] 07:44:37, metric 2
> to 172.27.0.26 via ge-0/0/1.0
to 172.27.0.21 via ge-0/0/2.0
lab@R5# run show pim join extensive 224.2.2.2
Group: 224.2.2.2
Source: *
RP: 172.27.255.11
Group: 224.2.2.2
Source: 172.27.0.38
Flags: sparse,spt
• R4:
172.27.0.36/30
Protocol: OSPF
Neighbor: 172.27.0.5
172.27.255.11/32
Protocol: Static
Neighbor: 172.27.0.5

172.27.0.36/30 *[OSPF/10] 00:08:51, metric 2

> to 172.27.0.5 via ge-0/0/1.0

172.27.0.36/30 *[OSPF/10] 00:08:51, metric 2

> to 172.27.0.5 via ge-0/0/1.0

172.27.255.11/32 *[OSPF/10] 00:09:01, metric 1

to 172.27.0.5 via ge-0/0/1.0
> to 172.27.0.10 via ae0.0

172.27.255.11/32 *[Static/5] 00:09:02

> to 172.27.0.5 via ge-0/0/1.0
[OSPF/10] 00:09:01, metric 1
to 172.27.0.5 via ge-0/0/1.0
> to 172.27.0.10 via ae0.0
Group: 224.2.2.2
Source: *
RP: 172.27.255.11
Group: 224.2.2.2
Source: 172.27.0.38
Flags: sparse,spt

Question: Do the RPT and SPT match on both R4

and R5 for group 224.2.2.2?
Answer: Yes. Both R4 and R5 should show that the

RPT and SPT use the same path to group 224.2.2.2.
TASK 4
Ensure that joins to source are load-balanced for groups
sourced from S1.
TASK INTERPRETATION
If you view the lab diagram, R5 should have two equal paths to S1. Also, verify that
R5 has equal cost paths to S1. To load balance across the equal cost paths, simply
configure the PIM option join-load-balance on R5.
TASK COMPLETION
First verify the status of the routes and PIM joins on R5.

172.27.0.28/30 *[OSPF/10] 01:50:12, metric 3

to 172.27.0.26 via ge-0/0/1.0
> to 172.27.0.21 via ge-0/0/2.0

172.27.0.28/30 *[OSPF/10] 01:50:12, metric 3

to 172.27.0.26 via ge-0/0/1.0
> to 172.27.0.21 via ge-0/0/2.0
Group: 224.1.1.1
Source: *
RP: 172.27.255.11

Group: 224.1.1.1
Source: 172.27.0.30
Flags: sparse,spt
Group: 224.3.3.3
Source: *
RP: 172.27.255.11
Group: 224.3.3.3
Source: 172.27.0.30
Flags: sparse,spt
Question: Does R5 show equal cost paths to S1?
Answer: Yes. You should see two next-hops for the

route 172.27.0.30.

Question: Is R5 load balancing the PIM joins to
source towards S1?
Answer: No, both S,Gs for groups sourced from S1

use the same upstream neighbor.
Now that you have verified load balancing is not occurring, configure the option to
load balance under PIM.
• R5:
lab@R5# top edit protocols pim
[edit protocols pim]

lab@R5# set join-load-balance

lab@R5# show
rp {
static {
address 172.27.255.11;
}
}
interface all;
disable;
}
join-load-balance;

lab@R5# commit
commit complete

lab@R5#
TASK VERIFICATION
You can now verify that load balancing is occurring by looking at the two groups
sourced from S1. You might have to configure clear pim join or restart
routing (to speed up the process) on R5 for the load balancing to occur because
the load balancing option does not affect current joins.
• R5:


172.27.0.28/30 *[OSPF/10] 00:14:12, metric 3
to 172.27.0.26 via ge-0/0/1.0
> to 172.27.0.21 via ge-0/0/2.0

172.27.0.28/30 *[OSPF/10] 00:14:12, metric 3

to 172.27.0.26 via ge-0/0/1.0
> to 172.27.0.21 via ge-0/0/2.0

Group: 224.1.1.1
Source: *
RP: 172.27.255.11
Group: 224.1.1.1
Source: 172.27.0.30
Flags: sparse,spt

Group: 224.3.3.3
Source: *
RP: 172.27.255.11

Group: 224.3.3.3
Source: 172.27.0.30
Flags: sparse,spt
Question: Are the joins to source for both groups

from S1 load balancing?
Answer: Yes, in the R5 output, the group 224.1.1.1

upstream neighbor is 172.27.0.26, and the group
224.3.3.3 upstream neighbor is 172.27.0.21. Your
output might have the neighbors swapped between
the two groups depending how the load balancing
occurs.

Lab 9
Class of Service Implementation and Troubleshooting
(Detailed)
Overview
class of service that you will need to accomplish within a specific time frame. You will
have 2 hours to complete the simulation.
guide.
• Configure a scheduler named jncie-cos on all routers with the following
criteria:
– The expedited-forwarding queue should have the high priority with 10%
allocation of traffic;
– The assured-forwarding queue should have medium-high priority with 5%
allocation of traffic;
– The best-effort queue should have low priority with 80% allocation of
traffic;
– The network-connect queue should have low priority with 5% traffic
allocation; and
– Apply the scheduler on all interfaces.
• Configure a MF classifier named voice on R5:
– The classifier should match any traffic with DSCP EF markings and place
this traffic into the EF queue;
– The classifier should match any TCP traffic destined to port 2000 and
place this traffic on the AF queue; and
– Place this classifier on traffic coming from the C1 router.
www.juniper.net Class of Service Implementation and Troubleshooting (Detailed) • Lab 9–1
10.b.10.3
• Configure a MF classifier named internet on R1:
– Match all traffic and place into the best effort queue and mark as
high loss drop profile; and
– Place this classifier on all traffic coming from the C2 router.
• Configure a rewrite marker named jncie-rw on R5:
– Mark all traffic on the expedited-forwarding queue as DSCP EF; and
– Mark all traffic on the assured-forwarding queue as DSCP AF21.
• Configure a behavior aggregate classifier named jncie-ba on R3, and
R4:
– Place all traffic with inet-precedence 5 into the expedited-forwarding
queue; and
– Place all traffic with inet-precedence 3 into the assured-forwarding
queue.
• Configure a filter named jncie-police on R3 and R4:
– Send any traffic marked as DSCP 21 and exceeding 50 Mb to the
best effort queue and mark it as loss priority high;
– Send any traffic marked as DSCP 46 and exceeding 100 Mb to the
best effort queue and mark it as loss priority low; and
– Apply the policer to the interfaces facing R5.
• Configure a behavior aggregate classifier on R2:
– Place all traffic marked with 802.1p number 5 on the expedited
forwarding queue; and
– Apply this to the interface facing the VPLS CE2 device.
• Configure a rewrite marker named vpls-rw on R2:
– Mark all traffic in the expedited queue to EXP 5.
Lab 9–2 • Class of Service Implementation and Troubleshooting (Detailed) www.juniper.net

Part 1: Configuring CoS
In this lab part, you will log in to your assigned routers and ensure that you are
running the correct startup configuration file for this lab. Refer to the network
diagram for this lab for topological and configuration details. You will then configure
various CoS settings depending on the outlined requirements. You must ensure that
all the CoS requirements are met based on the task guidelines.
Note
TASK 1
Configure a scheduler-map named jncie-cos on all routers.
Map each queue to the following set of criteria:
• The expedited-forwarding queue should have the high
priority with a 10% transmit rate;
• The assured-forwarding queue should have
medium-high priority with a 5% transmit rate;
• The best-effort queue should have low priority with
a 80% transmit rate;
• The network-connect queue should have low priority
with a 5% transmit rate; and
• Apply the scheduler on all gigabit interfaces.
Note
When you have a repetitive task on the
exam, take advantage of Notepad access
for copy and paste operations.
TASK INTERPRETATION
The task is requesting a simple scheduler-map configuration to be applied on all
interfaces. It lays out all the necessary criteria and it includes instructions to use a
specific name for the scheduler-map, but it does not seem to matter what you use to
name the schedulers themselves. The rest of the instructions are straightforward.

TASK COMPLETION
• R1, R2, R3, R4, and R5:
[edit]
lab@R1# edit class-of-service
[edit class-of-service]
lab@R1# set schedulers ef transmit-rate percent 10
lab@R1# set schedulers ef priority high
lab@R1# set schedulers af priority medium-high
lab@R1# set schedulers af transmit-rate percent 5
lab@R1# set schedulers be transmit-rate percent 80
lab@R1# set schedulers be priority low
lab@R1# set schedulers nc transmit-rate percent 5
lab@R1# set schedulers nc priority low
lab@R1# set scheduler-maps jncie-cos forwarding-class expedited-forwarding
scheduler ef
lab@R1# set scheduler-maps jncie-cos forwarding-class assured-forwarding
scheduler af
lab@R1# set scheduler-maps jncie-cos forwarding-class best-effort scheduler be
lab@R1# set scheduler-maps jncie-cos forwarding-class network-control scheduler
nc
lab@R1# set interfaces ge-* scheduler-map jncie-cos
lab@R1# show
interfaces {
ge-* {
scheduler-map jncie-cos;
}
}
scheduler-maps {
jncie-cos {
forwarding-class expedited-forwarding scheduler ef;
forwarding-class assured-forwarding scheduler af;
forwarding-class best-effort scheduler be;
forwarding-class network-control scheduler nc;
}
}
schedulers {
ef {
transmit-rate percent 10;
priority high;
}
af {

priority medium-high;
}
be {
priority low;
}
nc {
priority low;
}
}
lab@R1# commit
TASK VERIFICATION
The best way to verify this task is to issue the show class-of-service
interface command and confirm that the correct scheduler has been applied to
the interface:
lab@R1> show class-of-service interface ge-0/0/1
Physical interface: ge-0/0/1, Index: 134
Queues supported: 8, Queues in use: 4
Scheduler map: jncie-cos, Index: 31932
Logical interface: ge-0/0/1.0, Index: 73

Object Name Type Index
Classifier ipprec-compatibility ip 13
TASK 2
Configure a multifield classifier named voice on R5:
• The classifier should match any traffic with DSCP EF
markings and place this traffic into the EF queue;
• The classifier should match any TCP traffic
destined to port 2000 and place this traffic on the
AF queue; and
• Place this classifier on traffic coming from the C1
router.
TASK INTERPRETATION
This task is requiring the use of a multifield classifier on R5. A firewall filter is used
for multifield classification. The task explicitly states to name the classifier voice, it
also states to place the classifier on traffic coming from the Customer 1 router.
Referring to the diagram the firewall filter is applied to the ge-0/0/4.0 interface.
Remember to accept all unmatched traffic in your firewall filter—a simple mistake
like this can cause you to fail the exam.
TASK COMPLETION
• R5:
lab@R5# top edit firewall family inet filter voice

[edit firewall family inet filter voice]
lab@R5# set term 1 from dscp ef
lab@R5# set term 1 then forwarding-class expedited-forwarding
lab@R5# set term 2 from protocol tcp
lab@R5# set term 2 from destination-port 2000
lab@R5# set term 2 then forwarding-class assured-forwarding
lab@R5# top set interfaces ge-0/0/4.0 family inet filter input voice

lab@R5# commit
TASK VERIFICATION
The best way to verify this task is to make sure your firewall is configured correctly
on the correct interface by examining the configuration. If the test provides you with
access to the Customer 1 router, a ping with the correct set of ToS bytes can be
generated, and verify that the internal router is placing the traffic into the correct
queue.
In this lab, you are given access to the external device. The Customer 1 router is in a
routing instance named C1 in the VR-device. The device can be accessed with SSH
from the R5 router or through the management IP with the user lab and password
lab123. On R5, find which routes are advertised to C1 and then generate a ping to
C1 from that destination with the correct markings. After doing this, return to R5 and
view an extensive output for the interface facing the internal routers.
• R5:
lab@R5# top
[edit]
lab@R5# exit
lab@R5> show route advertising-protocol bgp 172.27.0.50 | match /32
* 2.2.2.2/32 Self 2 I
* 172.27.255.1/32 Self 2 I
* 172.27.255.2/32 Self 2 I
* 172.27.255.3/32 Self 1 I
* 172.27.255.4/32 Self 1 I
lab@R5> ssh lab@172.27.0.50

RSA key fingerprint is 0c:d7:22:f8:ae:60:7b:60:12:40:df:e2:b4:2f:d1:c7.
lab@172.27.0.50's password:

lab@vrdevice> ping 172.27.255.4 routing-instance C1 tos 184 count 20 rapid

PING 172.27.255.4 (172.27.255.4): 56 data bytes
!!!!!!!!!!!!!!!!!!!!
--- 172.27.255.4 ping statistics ---
lab@vrdevice> exit

172.27.255.4/32 *[OSPF/10] 5d 23:09:18, metric 1

> to 172.27.0.21 via ge-0/0/2.0
...
lab@R5> show interfaces ge-0/0/2 extensive | find "Queue counters"

Queue counters: Queued packets Transmitted packets Dropped packets
0 best-effort 133162 133162 0
1 expedited-fo 22 22 0
2 assured-forw 0 0 0
3 network-cont 158284 158284 0
...
As observed, the correct queue is populated with traffic on the outbound interface
on R5.
Question: Why is the number 184 used in the ping

command?
Answer: The ping command requires a decimal for

the entire length to the ToS byte. This is 8 bits
instead of 6 bits represented by DSCP. To find this
number, you can convert 46, which is EF in DSCP, to
binary and add two zeros to the right-most bits. For
example, 101110 is 46 in binary; if you add two
zeroes to the end and convert it to decimal, it
equals 184.
Note
Make sure you verify with the proctor if the
external device is accessible and if its using
a routing instance.
Note
To be more efficient when doing the ping
command, take advantage of the rapid
and count statements.

TASK 3
Configure a MF classifier name internet on R1:
• Match all traffic and place into the best effort
queue and mark as high loss drop profile; and
• Place this classifier on all traffic coming from the
C2 router.
TASK INTERPRETATION
This task is very similar to the previous task with the additional requirement of
marking the packets with loss priority high.
Create a firewall filter named internet and place all the traffic in the best effort
queue with loss priority to high. Configure this filter as input on the interface
facing the Customer 2 router. Because the term matches all traffic and uses the
then forwarding-class terminating action, no subsequent accept term is
necessary.
TASK COMPLETION
• R1:
lab@R1# top edit firewall family inet filter internet
[edit firewall family inet filter internet]

lab@R1# set term 1 then forwarding-class best-effort

lab@R1# set term 1 then loss-priority high

lab@R1# top set interfaces ge-0/0/1.0 family inet filter input internet

lab@R1# commit
TASK VERIFICATION
As with the previous command, the easiest and most efficient way to verify this task
is to simply check the configuration and ensure everything is in place. This task is
more complicated to verify from an external device due to the fact that even without
the firewall configured, all traffic can go into the best-effort queue. If everything
appears correctly when viewing the configuration, it should satisfy this task.
Note
During the exam, we recommend you verify
the success of tasks when possible.
However, if time is a factor, priority should
be given to any unfinished tasks.

TASK 4
Configure a rewrite marker named jncie-rw on R5:
• Mark all traffic on the expedited-forwarding queue
as DSCP EF;
• Mark all traffic on the assured-forwarding queue as
DSCP AF21; and
• Place the rewrite on the interfaces facing R3 and
R4.
TASK INTERPRETATION
The task is asking for a simple rewrite marker on traffic in the expedited forwarding
and assured forwarding queues. Create a DSCP rewrite marker named jncie-rw
and match on the correct markings, and apply it to the correct forwarding class.
Apply this rewrite marker to the interfaces facing the internal network. Utilize the
copy and replace Junos commands to speed up the configuration. Because the
task does not specify on which loss-priority markings should be matched, all of them
are used at this time.
Note
During the exam, we recommend that you
over-configure rather than under-configure.
If a task does not explicitly mention a step,
and if the extra configuration does not
conflict with any other task in the exam, it is
a good idea to perform the additional
configuration steps.
TASK COMPLETION
• R5:
lab@R5> configure
lab@R5# edit class-of-service rewrite-rules dscp jncie-rw
[edit class-of-service rewrite-rules dscp jncie-rw]
lab@R5# set forwarding-class expedited-forwarding loss-priority high code-point
ef
lab@R5# set forwarding-class expedited-forwarding loss-priority low code-point
ef
lab@R5# set forwarding-class expedited-forwarding loss-priority medium-high
code-point ef
lab@R5# set forwarding-class expedited-forwarding loss-priority medium-low
code-point ef
lab@R5# copy forwarding-class expedited-forwarding to forwarding-class
assured-forwarding

lab@R5# edit forwarding-class assured-forwarding
[edit class-of-service rewrite-rules dscp jncie-rw forwarding-class
assured-forwarding]
lab@R5# replace pattern ef with af21
[edit class-of-service rewrite-rules dscp jncie-rw forwarding-class
assured-forwarding]
lab@R5# up
lab@R5# show
forwarding-class expedited-forwarding {
loss-priority high code-point ef;
loss-priority low code-point ef;
loss-priority medium-high code-point ef;
loss-priority medium-low code-point ef;
}
forwarding-class assured-forwarding {
loss-priority high code-point af21;
loss-priority low code-point af21;
loss-priority medium-high code-point af21;
loss-priority medium-low code-point af21;
}
lab@R5# up 2
lab@R5# set interfaces ge-0/0/1 unit 0 rewrite-rules dscp jncie-rw
lab@R5# set interfaces ge-0/0/2 unit 0 rewrite-rules dscp jncie-rw
lab@R5# commit
TASK VERIFICATION
Remember that the rewrite of bits is an egress operation in Junos OS. Ensure that
the correct rewrite marker is applied by looking at the output of the show
class-of-service interface and the show class-of-service
rewrite-rule type dscp operational commands.
• R5:
lab@R5# run show class-of-service interface ge-0/0/1
Physical interface: ge-0/0/1, Index: 134
Queues supported: 8, Queues in use: 4
Scheduler map: <default>, Index: 2
Logical interface: ge-0/0/1.0, Index: 73

Object Name Type Index
Rewrite jncie-rw dscp 56953
Rewrite exp-default exp (mpls-any) 33
Classifier exp-default exp 10
Classifier ipprec-compatibility ip 13

lab@R5# run show class-of-service rewrite-rule type dscp name jncie-rw
Rewrite rule: jncie-rw, Code point type: dscp, Index: 56953
Forwarding class Loss priority Code point
expedited-forwarding low 101110
expedited-forwarding high 101110
expedited-forwarding medium-low 101110
expedited-forwarding medium-high 101110
assured-forwarding low 010010
assured-forwarding high 010010
assured-forwarding medium-low 010010
assured-forwarding medium-high 010010
TASK 5
Configure a behavior aggregate classifier named jncie-ba on
all ge interfaces of R3 and R4:
• Place all traffic with inet-precedence 5 into the
expedited-forwarding queue; and
• Place all traffic with inet-precedence 3 into the
assured-forwarding queue.
TASK INTERPRETATION
As with a previous task, this task requires classification of traffic into different
forwarding-classes. However, this task is explicit in requiring the use of a behavior
aggregate classifier and use of inet-precedence. Because it is not explicit as to what
the loss priority should be, it is safe to use loss-priority low.
As with previous tasks, because no change occurs in the configuration from router
to router, take advantage of Notepad for copy and paste operations.
TASK COMPLETION
• R3 and R4:
lab@R4# edit classifiers inet-precedence jncie-ba
[edit class-of-service classifiers inet-precedence jncie-ba]

lab@R4# set forwarding-class expedited-forwarding loss-priority low code-points
101

lab@R4# set forwarding-class assured-forwarding loss-priority low code-points
011

lab@R4# up 2 set interfaces ge-* unit 0 classifiers inet-precedence jncie-ba

lab@R4# commit

TASK VERIFICATION
As with the previous classification task, there are a few approaches to confirm that
classification is working. The best way to ensure that classification is working
properly is by pinging from an upstream device to a downstream device. Referring to
the topology, a ping with the correct set of ToS bits is generated from R1 to the
loopback address of R5 to check the classification on R3. Likewise, a ping is
generated from R2 to R5 to check the classification of R4. We recommend that you
clear the statistics on R3 and R4 to get a fresh set of counters to confirm the
classification.
• R3 and R4:
lab@R3# run clear interfaces statistics all
• R1 and R2:
lab@R1# run ping 172.27.255.5 rapid count 20 tos 160
PING 172.27.255.5 (172.27.255.5): 56 data bytes
!!!!!!!!!!!!!!!!!!!!
--- 172.27.255.5 ping statistics ---
lab@R1# run ping 172.27.255.5 rapid count 20 tos 96
PING 172.27.255.5 (172.27.255.5): 56 data bytes
!!!!!!!!!!!!!!!!!!!!
--- 172.27.255.5 ping statistics ---
• R3 and R4:
lab@R3# run show interfaces ge-0/0/3 extensive | find "Queue counter"
0 best-effort 30 30 0
3 network-cont 34 34 0


TASK 6
Configure a firewall named jncie-police on R3 and R4:
• Send any traffic marked as DSCP AF21 and exceeding
50 Mb to the best effort queue and mark it as loss
priority high;
• Send any traffic marked as DSCP EF and exceeding 100
Mb to the best effort queue and mark it as loss
priority low; and
• Apply the policer to the interfaces facing R5.
TASK INTERPRETATION
In this task, the requirement is to create a policer with an action to reclassify traffic
if it exceeds a certain rate. The task also requires matching on DSCP code points.
Clearly, the only way to complete this task is with a firewall filter matching on the
DSCP code points with a then policer action and applying the policer as input to
the interface facing R5. This task does not explicitly state the burst size setting, so to
keep the task simple, set the burst size to 10 times the MTU size of the interface.
TASK COMPLETION
• R3 and R4:
lab@R3# top edit firewall
[edit firewall]
lab@R3# set policer ef if-exceeding bandwidth-limit 100m burst-size-limit 15000
[edit firewall]
lab@R3# set policer ef then forwarding-class best-effort
[edit firewall]
lab@R3# set policer ef then loss-priority low
[edit firewall]
lab@R3# copy policer ef to policer af21
[edit firewall]
lab@R3# edit policer af21
[edit firewall policer af21]

lab@R3# show
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 15k;
}
then {
loss-priority low;
forwarding-class best-effort;
}

lab@R3# set if-exceeding bandwidth-limit 50m


lab@R3# set then loss-priority high

lab@R3# show
if-exceeding {
bandwidth-limit 50m;
burst-size-limit 15k;
}
then {
loss-priority high;
forwarding-class best-effort;
}

lab@R3# up
[edit firewall]
lab@R3# set family inet filter jncie-police term 1 from dscp af21
[edit firewall]
lab@R3# set family inet filter jncie-police term 1 then policer af21
[edit firewall]
lab@R3# set family inet filter jncie-police term 2 from dscp ef
[edit firewall]
lab@R3# set family inet filter jncie-police term 2 then policer ef
[edit firewall]
lab@R3# set family inet filter jncie-police term 3 then accept
[edit firewall]
lab@R3# top set interfaces ge-0/0/4.0 family inet filter input jncie-police
[edit firewall]
lab@R3# commit
TASK VERIFICATION
During the exam, you cannot generate enough traffic to see if the filter is working
properly. Verification for this task can easily be done by double checking the
configuration. Confirm that the filter has the correct name and is applied to the right
interface and remember to apply an accept term to the filter.
TASK 7
Configure a behavior aggregate classifier on R2 named
vpls-ba:
• Place all traffic marked with 802.1p number 5 on the
expedited forwarding queue; and
• Apply this classifier to the interface facing the
VPLS CE1 device.

TASK INTERPRETATION
Refer to the topology diagram. This task is asking for another behavior aggregate,
this time based on 802.1p markings. A behavior aggregate named vpls-ba of type
802.1p must be created that matches the number 5. The behavior aggregate must
be placed on the interface facing the VPLS CE1 device. As with the previous
classifiers, if a loss priority marking is not provided, loss-priority low can be
used.
TASK COMPLETION
• R2:
lab@R2# edit classifiers ieee-802.1 vpls-ba
[edit class-of-service classifiers ieee-802.1 vpls-ba]
101
lab@R2# up 2 set interfaces ge-0/0/3 unit 0 classifiers ieee-802.1 vpls-ba
lab@R2# commit
TASK VERIFICATION
The use of VPLS in the topology might be intimidating for CoS operations, but the
configuration is very similar to that of the other possible ToS markings. If time allows
and you have access to the VPLS CEs, matching on 802.1p markings of zero and
placing into the expedited-forwarding queue can confirm that the configuration is
correct. After adding the configuration, log in to the VPLS CE and generate a ping to
the other CE device. The expedited-forwarding queue counter on the interface facing
the core should increment due to the ping.
The VR-device has both VPLS CE devices in different routing instances. The name of
the VPLS routing-instances is VPLS-CE1 and VPLS-CE2. Find the IP addresses for the
VPLS interfaces and generate a ping.
• R2:
000
lab@R2# commit
lab@R2# run clear interfaces statistics all
• VR-device:
lab@vrdevice> show route table VPLS-CE protocol local terse
VPLS-CE1.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)


* 192.168.1.1/32 L 0 Local

VPLS-CE2.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

* 192.168.1.3/32 L 0 Local
lab@vrdevice> ping 192.168.1.3 routing-instance VPLS-CE1 rapid count 100

PING 192.168.1.3 (192.168.1.3): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!
...
• R2:
...
R2 is queueing the packets into the expedited forwarding properly, the same should
be expected of traffic with a 802.1p marking of 5. As mentioned earlier, any extra
configuration if not explicitly disallowed should be okay to use, if there is any doubt
ask the proctor.
TASK 8
Configure a rewrite marker named vpls-rw on R2 and mark all
traffic in the expedited queue to EXP 5.
TASK INTERPRETATION
Similar to a previous task, this task is requiring the use of rewrite marker for traffic
in particular forwarding-class. The same steps as previously shown should be used
to configure the rewrite marker, one difference is that you must apply this to the
MPLS EXP markings.
TASK COMPLETION
lab@R2# up 2 edit rewrite-rules exp vpls-rw
[edit class-of-service rewrite-rules exp vpls-rw]
lab@R2# set forwarding-class expedited-forwarding loss-priority low code-point
101
lab@R2# up 2 set interfaces ge-0/0/4 unit 0 rewrite-rules exp vpls-rw

lab@R2# commit

TASK VERIFICATION
After checking the configuration, if time allows for more verification, a family MPLS
filter can be created on the downstream router with a counter to make sure the bits
are written correctly. From the perspective of R2, the next-hop router to the VPLS PE
is R4. On R4, a filter is created to count exp 5 packets. Generate a ping from the CE
device and make sure that the configuration on R2 places packets with priority bit
zero into the expedited forwarding queue, as done in the previous verification step.
• R4:
lab@R4# top edit firewall family mpls filter count
[edit firewall family mpls filter count]
lab@R4# set term 1 from exp 5
lab@R4# set term 1 then count fromR2
lab@R4# top set interfaces ge-0/0/1.0 family mpls filter input count
lab@R4# commit
• VR-device VPLS CE1:
lab@vrdevice> ping 192.168.1.3 routing-instance VPLS-CE1 rapid count 100
PING 192.168.1.3 (192.168.1.3): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!
...
• R4:
lab@R4# run show firewall
...
Filter: count
Counters:
Name Bytes Packets
fromR2 11054 101


Lab 10
MPLS Implementation and Troubleshooting (Detailed)
Overview
MPLS which you will need to accomplish within a specific time frame. You will have
1.5 hours to complete the simulation.
guide.
regarding the interpretation of each task, followed by step-by-step instructions. Some
tasks might include multiple methods for accomplishing each task.
• Configure the RSVP LSPs, defined in the LSP tables, through your network and
ensure all LSPs are up and functional.
• R2 is not allowed to run RSVP to signal its LSPs. You must route between R2
and R5 using a LSP. You must also ensure that the failure of any transit router
does not prevent the exchange of labels between R2 and R5. LDP is prohibited
on R3.
• Ensure that the r1-to-r5 LSP has two unique paths. The primary path
should traverse R4 while the secondary path should use a different path and
be signaled and ready for use.
• Configure the administrative groups defined in the Admin table on all RSVP
routers. Apply these administrative groups to the appropriate links as
illustrated on the Lab 6 diagram. Ensure that the r3-to-r4 LSP avoids the
R3-R4 link.
• Configure the r5-to-r1 LSP to reserve 450 Mbps of bandwidth across the
network.
• Create a bypass to improve convergence time for the r5-to-r1 LSP in the
event of a R4-R1 link failure. Ensure bandwidth reservation is honored and the
best available path is chosen.
www.juniper.net MPLS Implementation and Troubleshooting (Detailed) • Lab 10–1

10.b.10.3
• Ensure that all MPLS packets that transit the R1-R4 link are load
balanced across both member links of the aggregated Ethernet bundle.
The contents of the outer label as well as the IP packet should be used by
the load balancing algorithm.
• Ensure that the entire core MPLS network appears as two hops for any
transit traffic.
Lab 10–2 • MPLS Implementation and Troubleshooting (Detailed) www.juniper.net

Part 1: Configuring LSPs
In this lab part, you will log in to your assigned routers and configure the
label-switched paths (LSPs) required to transport traffic through your core network.
You must ensure all LSPs are created within the guidelines defined by the tasks in
this lab.

INITIAL TASK
TASK COMPLETION
• R1:
R1 (ttyd0)
login: lab
Password:

lab@R1>
• R2:
R2 (ttyd0)
login: lab
Password:

lab@R2>
• R3:
R3 (ttyd0)
login: lab
Password:

lab@R3>
• R4:
R4 (ttyd0)
login: lab
Password:


lab@R4>
• R5:
R5 (ttyd0)
login: lab
Password:

lab@R5>
• VR-device:
vr-device (ttyd0)
login: lab
Password:

lab@vr-device>
TASK 1
Configure the LSPs, defined in the following LSP tables,
through your network and ensure all LSPs are up and
functional.
Note
We recommend that you include the
configuration steps for the third task while
you are configuring the first task. This
approach will save you time and effort as
you move through the tasks of this lab.
The third task states:

Ensure that the r1-to-r5 LSP has two unique paths. The
primary path should traverse R4 while the secondary path
should use a different path and be signaled and ready for
use.
R1
LSP name Egress address

r1-to-r3 172.27.255.3
r1-to-r4 172.27.255.4
r1-to-r5 172.27.255.5

R3

r3-to-r1 172.27.255.1
r3-to-r4 172.27.255.4
r3-to-r5 172.27.255.5
R4

r4-to-r1 172.27.255.1
r4-to-r3 172.27.255.3
r4-to-r5 172.27.255.5
R5

r5-to-r1 172.27.255.1
r5-to-r3 172.27.255.3
r5-to-r4 172.27.255.4
TASK INTERPRETATION
The task appears to be a simple one and in some aspects it is. The difficult part of
this task is ensuring you properly configure each LSP and keep track of the LSPs you
have configured.
A good way to track your progress is to check off each LSP as you configure them.
This ensures you do not overlook creating one of the LSPs, because the failure to
configure any portion of the task, results in the loss of points for the entire task.
Another aspect of this task to keep in mind is that the LSPs must be defined exactly
as shown on the LSP tables.
In this task, you configure standard individual RSVP LSPs, but looking ahead to the
third task, you know that for the LSP from R1 to R5 there are additional constraints
that we need to configure. Therefore, it makes good sense while configuring the LSP
from R1 to R5 that you combine these actions into a single configuration task. The
third task requires that you configure two unique paths to be applied to the LSP you
configured to egress on R5. There is also a requirement for the second path to be
signaled and ready for use. This is accomplished by using the standby option
when creating the secondary path.
TASK COMPLETION
• R1:
[edit]
lab@R1# set protocols rsvp interface ae0

[edit]
lab@R1# set protocols rsvp interface ge-0/0/6
[edit]
lab@R1# edit protocols mpls
[edit protocols mpls]


lab@R1# set label-switched-path r1-to-r3 to 172.27.255.3


lab@R1# set path path-1 172.27.0.9 strict

lab@R1# set path path-2 172.27.0.13 strict


lab@R1# set label-switched-path r1-to-r5 primary path-1

lab@R1# set label-switched-path r1-to-r5 secondary path-2 standby

lab@R1# show
label-switched-path r1-to-r3 {
to 172.27.255.3;
}
to 172.27.255.4;
}
to 172.27.255.5;
primary path-1;
secondary path-2 {
standby;
}
}
path path-1 {
172.27.0.9 strict;
}
path path-2 {
172.27.0.13 strict;
}
interface all;


commit complete
lab@R1>
• R3:
[edit]
lab@R3# set protocols rsvp interface all
[edit]





lab@R3# show
to 172.27.255.1;
}
to 172.27.255.4;
}
to 172.27.255.5;
}
interface all;

commit complete
lab@R3>
• R4:
[edit]
lab@R4# set protocols rsvp interface ae0
[edit]
[edit]

[edit]





lab@R4# show
to 172.27.255.1;
}
to 172.27.255.3;
}
to 172.27.255.5;
}
interface all;

commit complete
lab@R4>
• R5:
[edit]
lab@R5# set protocols rsvp interface all
[edit]





lab@R5# show
to 172.27.255.1;
}
to 172.27.255.3;
}
to 172.27.255.4;
}
interface all;

commit complete
lab@R5>
TASK VERIFICATION
Begin your verification by reviewing the status of your LSPs from the perspective of
R1. If everything is functioning well, move through the rest of the routers on which
you configured LSPs.
• R1:
lab@R1> show mpls lsp
Ingress LSP: 3 sessions
To From State Rt P ActivePath LSPname
172.27.255.3 0.0.0.0 Dn 0 - r1-to-r3
172.27.255.4 0.0.0.0 Dn 0 - r1-to-r4
172.27.255.5 0.0.0.0 Dn 0 - r1-to-r5
Total 3 displayed, Up 0, Down 3
Egress LSP: 0 sessions

Transit LSP: 0 sessions

lab@R1> show mpls lsp extensive

172.27.255.3
From: 0.0.0.0, State: Dn, ActiveRoute: 0, LSPname: r1-to-r3
ActivePath: (none)
LSPtype: Static Configured
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
Primary State: Dn
Priorities: 7 0
SmartOptimizeTimer: 180
Will be enqueued for recomputation in 21 second(s).

1 Jun 23 22:39:07.928 CSPF failed: no route toward 172.27.255.3[169 times]
Created: Thu Jun 23 21:17:03 2011
172.27.255.4
ActivePath: (none)
LoadBalance: Random
Primary State: Dn
Priorities: 7 0
Created: Thu Jun 23 21:17:03 2011
172.27.255.5
ActivePath: (none)
LoadBalance: Random
Primary path-1 State: Dn
Priorities: 7 0
Standby path-2 State: Dn
Priorities: 7 0
Created: Thu Jun 23 21:17:03 2011


lab@R1> show mpls interface
lab@R1>
Question: What is the State of your LSPs?
Answer: At this point the LSPs should all show Dn.

Question: Using the previous outputs from R1, why
are the LSPs down?
Answer: The answer lies with the last command that

was executed. No interfaces are participating in
MPLS.
TASK CORRECTION
To correct the issue you have to enable family mpls on all interfaces that will be
participating in your MPLS network.
• R1:
lab@R1> configure
[edit]
[edit interfaces]
lab@R1# set ae0 unit 0 family mpls
[edit interfaces]
lab@R1# set ge-0/0/6 unit 0 family mpls
[edit interfaces]
commit complete
lab@R1>
• R3:
lab@R3> configure
[edit]
[edit interfaces]
[edit interfaces]
[edit interfaces]

[edit interfaces]
commit complete
lab@R3>
• R4:
lab@R4> configure
[edit]
[edit interfaces]
lab@R4# set ae0 unit 0 family mpls
[edit interfaces]
[edit interfaces]
[edit interfaces]
commit complete
lab@R4>
• R5:
lab@R5> configure
[edit]
[edit interfaces]
[edit interfaces]
[edit interfaces]
commit complete
lab@R5>

Now that you have added the protocol family to the correct interfaces, you must
review the state of your LSPs. Begin with one router and then progress through the
rest of the routers on which you configured LSPs.
• R1:
172.27.255.3 172.27.255.1 Up 10 * r1-to-r3
172.27.255.4 172.27.255.1 Up 0 * r1-to-r4
172.27.255.5 172.27.255.1 Up 10 * path-1 r1-to-r5

To From State Rt Style Labelin Labelout LSPname
172.27.255.1 172.27.255.4 Up 0 1 FF 3 - r4-to-r1
172.27.255.1 172.27.255.3 Up 0 1 FF 3 - r3-to-r1
172.27.255.1 172.27.255.5 Up 0 1 FF 3 - r5-to-r1

Answer: You should see that all you LSPs are Up

and functioning correctly.
• R3:
172.27.255.1 172.27.255.3 Up 10 * r3-to-r1
172.27.255.4 172.27.255.3 Up 0 * r3-to-r4
172.27.255.5 172.27.255.3 Up 10 * r3-to-r5

172.27.255.3 172.27.255.4 Up 0 1 FF 3 - r4-to-r3
172.27.255.3 172.27.255.5 Up 0 1 FF 3 - r5-to-r3
172.27.255.3 172.27.255.1 Up 0 1 FF 3 - r1-to-r3

172.27.255.5 172.27.255.1 Up 1 1 FF 299776 3 r1-to-r5

• R4:
172.27.255.1 172.27.255.4 Up 10 * r4-to-r1
172.27.255.3 172.27.255.4 Up 10 * r4-to-r3
172.27.255.5 172.27.255.4 Up 10 * r4-to-r5

172.27.255.4 172.27.255.5 Up 0 1 FF 3 - r5-to-r4
172.27.255.4 172.27.255.3 Up 0 1 FF 3 - r3-to-r4
172.27.255.4 172.27.255.1 Up 0 1 FF 3 - r1-to-r4

172.27.255.1 172.27.255.5 Up 1 1 FF 299792 3 r5-to-r1
172.27.255.5 172.27.255.1 Up 1 1 FF 299776 3 r1-to-r5
• R5:
172.27.255.1 172.27.255.5 Up 10 * r5-to-r1
172.27.255.3 172.27.255.5 Up 10 * r5-to-r3
172.27.255.4 172.27.255.5 Up 0 * r5-to-r4

172.27.255.5 172.27.255.4 Up 0 1 FF 3 - r4-to-r5
172.27.255.5 172.27.255.3 Up 0 1 FF 3 - r3-to-r5
172.27.255.5 172.27.255.1 Up 0 1 FF 3 - r1-to-r5
172.27.255.5 172.27.255.1 Up 0 1 FF 3 - r1-to-r5

Answer: You should see that all you LSPs are Up

and functioning correctly.

TASK 2
R2 is not allowed to run RSVP to signal its LSPs. You must
route between R2 and R5 using a LSP. You must also ensure
that the failure of any transit router does not prevent the
exchange of labels between R2 and R5. LDP is prohibited on
R3.
TASK INTERPRETATION
The task is telling you that you must configure LDP to signal LSPs, in addition to the
RSVP LSPs. As the task indicates, you are not allowed to run LDP on R3 and you
must ensure redundancy.
To meet the requirements of this task, you must configure LDP tunneling through
your RSVP LSP network. You configure LDP tunneling for the LSPs from both R1 and
R4 that terminate on R5. This ensures that labels are still exchanged from R2 to R5
if there is a failure of any transit device through the RSVP network.
TASK COMPLETION
• R1:
lab@R1> configure
[edit]
[edit interfaces]
[edit interfaces]
lab@R1# top
[edit]
lab@R1# set protocols ldp interface ge-0/0/3
[edit]
lab@R1# set protocols ldp interface lo0
[edit]
lab@R1# set protocols mpls label-switched-path r1-to-r5 ldp-tunneling
[edit]
commit complete
lab@R1>
• R2:
[edit]
[edit interfaces]
[edit interfaces]
[edit interfaces]
lab@R2# top
[edit]
lab@R2# set protocols ldp interface all
[edit]
commit complete
lab@R2>
• R4:
lab@R4> configure
[edit]
lab@R4# set interfaces ge-0/0/1 unit 0 family mpls
[edit]
[edit]
lab@R4# set protocols ldp interface ge-0/0/1
[edit]
[edit]
commit complete
lab@R4>
• R5:
lab@R5> configure
[edit]
[edit]
[edit]

[edit]
commit complete
lab@R5>
TASK VERIFICATION
Begin your verification by reviewing the status of your LSPs from the perspective of
R1. If everything is functioning well, move on through the rest of the routers on
which you configured LDP.
• R1:
lab@R1> show ldp interface
Interface Label space ID Nbr count Next hello
ge-0/0/3.0 172.27.255.1:0 1 4
lo0.0 172.27.255.1:0 1 0
lab@R1> show ldp neighbor

172.27.0.2 ge-0/0/3.0 172.27.255.2:0 12
172.27.255.5 lo0.0 172.27.255.5:0 33
lab@R1> show ldp session

Address State Connection Hold time
172.27.255.2 Operational Open 22
• R2:
lo0.0 172.27.255.2:0 0 0
ge-0/0/1.0 172.27.255.2:0 1 4
ge-0/0/4.0 172.27.255.2:0 1 2

172.27.0.1 ge-0/0/1.0 172.27.255.1:0 14
172.27.0.6 ge-0/0/4.0 172.27.255.4:0 13

• R4:
lo0.0 172.27.255.4:0 1 0
ge-0/0/1.0 172.27.255.4:0 1 2

172.27.255.5 lo0.0 172.27.255.5:0 42
172.27.0.5 ge-0/0/1.0 172.27.255.2:0 13

• R5:
lo0.0 172.27.255.5:0 2 0

172.27.255.1 lo0.0 172.27.255.1:0 35
172.27.255.4 lo0.0 172.27.255.4:0 38

Question: What is the State of your LDP sessions?
Answer: At this point all you LDP sessions should

show Operational.
Question: Do you see the correct interfaces

participating in LDP on each router?
Answer: Yes, if you added the MPLS family to the

interface configuration as well as added the correct
interfaces to LDP.

TASK 3
Ensure that the r1-to-r5 LSP has two unique paths. The
primary path should traverse R4 while the secondary path
should use a different path and be signaled and ready for
use.
Note
We recommended that you include the
configuration steps for the third task while
you were configuring the first task. If you
decided not to include the third task then,
now is the time to complete this task.
TASK INTERPRETATION
If you followed the instructions in the first task, you have already completed this
task. If you did not include this task when you configured your RSVP LSPs then you
should complete this task now. You can refer to the detailed steps outlined in the
first task to complete this third task.
TASK 4
Configure the administrative groups, defined in the Admin
Groups table, on all RSVP routers. Apply these
administrative groups to the appropriate links as
illustrated on the Lab 6 diagram. Ensure that the r3-to-r4
LSP avoids the R3-R4 link.
Admin Groups
plat 1
gold 2
silver 3
bronze 4
TASK INTERPRETATION
This task requires you to configure the administrative groups defined in the table.
Apply these groups to the appropriate links and ensure that you apply the additional
constraints to the defined LSP r3-to-r4 by excluding the bronze admin group.
TASK COMPLETION
• R1:
lab@R1> configure
[edit]

lab@R1# set admin-groups plat 1

lab@R1# set admin-groups gold 2

lab@R1# set admin-groups silver 3

lab@R1# set admin-groups bronze 4

lab@R1# set interface ae0 admin-group plat

lab@R1# set interface ge-0/0/6 admin-group gold

lab@R1# show
admin-groups {
plat 1;
gold 2;
silver 3;
bronze 4;
}
to 172.27.255.3;
}
to 172.27.255.4;
}
to 172.27.255.5;
ldp-tunneling;
primary path-1;
secondary path-2 {
standby;
}
}
path path-1 {
172.27.0.9 strict;
}
path path-2 {
172.27.0.13 strict;
}
interface all;
interface ae0.0 {
admin-group plat;
}
admin-group gold;
}


commit complete
lab@R1>
• R3:
lab@R3> configure
[edit]






lab@R3# set interface ge-0/0/2 admin-group bronze

lab@R3# set interface ge-0/0/3 admin-group plat

lab@R3# set label-switched-path r3-to-r4 admin-group exclude bronze

lab@R3# show
admin-groups {
plat 1;
gold 2;
silver 3;
bronze 4;
}
to 172.27.255.1;
}
to 172.27.255.4;
admin-group exclude bronze;
}
to 172.27.255.5;
}

interface all;
admin-group gold;
}
admin-group bronze;
}
admin-group plat;
}

commit complete
lab@R3>
• R4:
lab@R4> configure
[edit]





lab@R4# set interface ae0 admin-group plat


lab@R4# set interface ge-0/0/5 admin-group bronze

lab@R4# show
admin-groups {
plat 1;
gold 2;
silver 3;
bronze 4;
}

to 172.27.255.1;
}
to 172.27.255.3;
}
to 172.27.255.5;
ldp-tunneling;
}
interface all;
interface ae0.0 {
admin-group plat;
}
admin-group gold;
}
admin-group bronze;
}

commit complete
lab@R4>
• R5:
lab@R5> configure
[edit]





lab@R5# set interface ge-0/0/1 admin-group plat


lab@R5# show
admin-groups {
plat 1;
gold 2;
silver 3;
bronze 4;
}
to 172.27.255.1;
ldp-tunneling;
}
to 172.27.255.3;
}
to 172.27.255.4;
ldp-tunneling;
}
interface all;
admin-group plat;
}
admin-group gold;
}

commit complete
lab@R5>
TASK VERIFICATION
Begin your verification by ensuring that all MPLS interfaces have the correct
administrative groups applied. While on R3, you should also verify that the
constraints that you applied to the r3-to-r4 LSP have taken effect. You can do
this by reviewing the extensive information for the particular LSP.
• R1:
Interface State Administrative groups
ge-0/0/3.0 Up <none>
ge-0/0/6.0 Up gold
ae0.0 Up plat
• R3:
ge-0/0/1.0 Up gold
ge-0/0/2.0 Up bronze
ge-0/0/3.0 Up plat

lab@R3> show mpls lsp name r3-to-r4 extensive

172.27.255.4
From: 172.27.255.3, State: Up, ActiveRoute: 0, LSPname: r3-to-r4
ActivePath: (primary)
LoadBalance: Random
*Primary State: Up
Priorities: 7 0
Exclude: bronze
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2)
172.27.0.25 S 172.27.0.21 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt
20=Node-ID):
172.27.0.25 172.27.0.21
11 Jun 28 20:05:29.311 Record Route: 172.27.0.25 172.27.0.21
10 Jun 28 20:05:29.311 Up
9 Jun 28 20:05:29.272 Originate Call
8 Jun 28 20:05:29.272 CSPF: computation result accepted 172.27.0.25
172.27.0.21
7 Jun 28 20:05:29.271 Clear Call
6 Jun 28 20:03:35.359 Selected as active path
5 Jun 28 20:03:35.357 Record Route: 172.27.0.18
4 Jun 28 20:03:35.357 Up
3 Jun 28 20:03:35.344 Originate Call
2 Jun 28 20:03:35.344 CSPF: computation result accepted 172.27.0.18
1 Jun 28 20:03:05.623 CSPF: could not determine self
Created: Tue Jun 28 20:03:05 2011


Question: What path does your r3-to-r4 LSP

follow?
Answer: The LSP should now use an alternative

path to R4. This LSP should avoid the more
preferred, direct link between R3 and R4.

• R4:
ge-0/0/1.0 Up <none>
ge-0/0/4.0 Up gold
ge-0/0/5.0 Up bronze
ae0.0 Up plat
• R5:
ge-0/0/1.0 Up plat
ge-0/0/2.0 Up gold
TASK 5
Configure the r5-to-r1 LSP to reserve 450 Mbps of bandwidth
across the network.
TASK INTERPRETATION
This task indicates that you must assign a bandwidth reservation to the LSP that you
created from r5-to-r1.
TASK COMPLETION
• R5:
lab@R5> configure
[edit]

lab@R5# set label-switched-path r5-to-r1 bandwidth 450m

commit complete
lab@R5>
TASK VERIFICATION
On R5, verify that the r5-to-r1 LSP is requesting the bandwidth and the LSP has
been signaled. You can also see the reservation by looking at the RSVP interfaces.
• R5:
lab@R5> show mpls lsp name r5-to-r1 extensive

172.27.255.1
Link protection desired
LoadBalance: Random
*Primary State: Up,
Priorities: 7 0
Bandwidth: 450Mbps
172.27.0.21 S 172.27.0.10 S
...
lab@R5> show rsvp interface

RSVP interface: 6 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
ge-0/0/0.0 Up 0 100% 1000Mbps 1000Mbps 0bps 0bps
ge-0/0/2.0 Up 2 100% 1000Mbps 550Mbps 450Mbps 450Mbps
lab@R5> show rsvp interface ge-0/0/2.0 extensive

ge-0/0/2.0 Index 71, State Ena/Up
NoAuthentication, NoAggregate, NoReliable, NoLinkProtection
HelloInterval 9(second)
Address 172.27.0.22
ActiveResv 2, PreemptionCnt 0, Update threshold 10%
Subscription 100%,
bc0 = ct0, StaticBW 1000Mbps
ct0: StaticBW 1000Mbps, AvailableBW 550Mbps
MaxAvailableBW 1000Mbps = (bc0*subscription)
ReservedBW [0] 450Mbps[1] 0bps[2] 0bps[3] 0bps[4] 0bps[5] 0bps[6] 0bps[7]
0bps
Protection: Off
Question: Do you see the correct bandwidth

reservation?
Answer: Yes, you should see that the LSP is

reserving 450 Mbps of bandwidth.
TASK 6
Create a bypass to improve convergence time for the
r5-to-r1 LSP in the event of a R4-R1 link failure. Ensure
bandwidth reservation is honored and the best available
path is chosen.

TASK INTERPRETATION
This task indicates that you need to configure some type of traffic protection. Based
on the constraints placed on the task we can eliminate Fast Reroute as an option
because we need to maintain the bandwidth reservation that we configured in the
previous task. If you read the task carefully you will notice that you are protecting the
LSP from a particular link failure, so the protection mechanism that you are using is
link-protection.
Begin by setting the RSVP interface on which you are going to enable link protection.
You must also configure the interface to reserve the 450 Mbps on the bypass LSP.
Next, you must enable link-protection on the ingress router for the r5-to-r1 LSP.
This will allow the bypass to be signaled.
TASK COMPLETION
• R4:
lab@R4> configure
[edit]
lab@R4# set protocols rsvp interface ae0.0 link-protection bandwidth 450m
[edit]
commit complete
lab@R4>
• R5:
lab@R5> configure
[edit]
lab@R5# set protocols mpls label-switched-path r5-to-r1 link-protection
[edit]
commit complete
lab@R5>
TASK VERIFICATION
Begin your verification by looking at the LSP from the perspective of the ingress
router (R5). After determining that link-protection is being requested for the LSP,
move to R4 and verify that the RSVP interface you configured is creating a bypass
LSP.

• R5:
lab@R5> show mpls lsp name r5-to-r1 detail
172.27.255.1
Link protection desired
LoadBalance: Random
*Primary State: Up
Priorities: 7 0
Bandwidth: 450Mbps
172.27.0.21 S 172.27.0.10 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt
20=Node-ID):
172.27.255.4(flag=0x21) 172.27.0.21(flag=1 Label=300080)
172.27.255.1(flag=0x20) 172.27.0.10(Label=3)


Question: Is link protection being requested by the

ingress router?
Answer: Yes, you should see in the above output

that link-protection is desired for this LSP.
• R4:
lab@R4> show rsvp interface ae0.0 extensive
ae0.0 Index 75, State Ena/Up
NoAuthentication, NoAggregate, NoReliable, LinkProtection
HelloInterval 9(second)
Address 172.27.0.9
ActiveResv 3, PreemptionCnt 0, Update threshold 10%
Subscription 100%,
bc0 = ct0, StaticBW 2Gbps
ct0: StaticBW 2Gbps, AvailableBW 1.55Gbps
MaxAvailableBW 2Gbps = (bc0*subscription)
ReservedBW [0] 450Mbps[1] 0bps[2] 0bps[3] 0bps[4] 0bps[5] 0bps[6] 0bps[7]
0bps
Protection: On, Bypass: 1, LSP: 1, Protected LSP: 1, Unprotected LSP: 0
3 Jun 29 00:56:37 New bypass Bypass->172.27.0.10
2 Jun 29 00:41:35 Delete bypass Bypass->172.27.0.10, configuration changed

1 Jun 29 00:38:32 New bypass Bypass->172.27.0.10
Bypass: Bypass->172.27.0.10, State: Up, Type: LP, LSP: 1, Backup: 0
3 Jun 29 00:56:39 Record Route: 172.27.0.17 172.27.0.14
2 Jun 29 00:56:39 Up
1 Jun 29 00:56:39 CSPF: computation result accepted
lab@R4> show mpls lsp bypass extensive

172.27.255.1
From: 172.27.255.4, LSPstate: Up, ActiveRoute: 0
LSPname: Bypass->172.27.0.10
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 299968
Resv style: 1 SE, Label in: -, Label out: 299968
Time left: -, Since: Wed Jun 29 00:56:39 2011
Tspec: rate 450Mbps size 450Mbps peak Infbps m 20 M 1500
Port number: sender 1 receiver 55417 protocol 0
Type: Bypass LSP
Number of data route tunnel through: 1
Number of RSVP session tunnel through: 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 172.27.0.17 (ge-0/0/5.0) 2 pkts
RESV rcvfrom: 172.27.0.17 (ge-0/0/5.0) 2 pkts
Explct route: 172.27.0.17 172.27.0.14
Record route: <self> 172.27.0.17 172.27.0.14


Question: Do you see a bypass LSP?
Answer: Yes, you should see a bypass LSP being

signaled.
Question: Which path is the bypass taking?
Answer: You can determine this by looking at the

record route values associated with the bypass LSP,
which indicate that the bypass is going through R3
then to R1.

lab@R4> show rsvp interface
RSVP interface: 3 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
ae0.0 Up 2 100% 2Gbps 1.55Gbps 450Mbps 450Mbps
ge-0/0/5.0 Up 2 100% 1000Mbps 550Mbps 450Mbps 450Mbps
Question: Do you see the correct bandwidth

reservations on both RSVP interfaces?
Answer: Yes, you should see 450 Mbps for two

interfaces now. The second interface indicates that
the bypass LSP is also reserving bandwidth as the
task required.
TASK 7
Ensure that all MPLS packets that transit the R1-R4 link
are load balanced across both member links of the
Aggregated Ethernet bundle. The contents of the outer label
as well as the IP packet should be used by the load
balancing algorithm.
TASK INTERPRETATION
This task indicates that you must alter the hash key being used by the forwarding
table when deciding what interface next-hop to use for MPLS traffic traversing the
aggregated Ethernet interface.
Based on the requirements, you must use the first label as well as the IP payload
when calculating the physical interface to send the MPLS traffic out. You must make
this configuration change on both R1 and R4 to meet the requirements of the task.
TASK COMPLETION
• R1:
lab@R1> configure
[edit]
lab@R1# set forwarding-options hash-key family mpls label-1 payload ip
[edit]
commit complete
lab@R1>

• R4:
lab@R4> configure
[edit]
lab@R4# set forwarding-options hash-key family mpls label-1 payload ip
[edit]
commit complete
lab@R4>
TASK VERIFICATION
Because no transit traffic is traversing your core network, you need no verification
steps for this particular task. If you configured the hash algorithm as illustrated in
the detailed steps, then everything should be working correctly.
TASK 8
Ensure that the entire core network appears as two hops for
any transit traffic.
TASK INTERPRETATION
This task indicates that you must alter the default TTL behavior. Even though all
devices in your MPLS network are running the Junos OS, you must use the
no-propagate-ttl option. You must use this option because LDP is not
supported by the no-decrement-ttl feature. You must configure the
no-propagate-ttl option for all MPLS LSP on all routers.
TASK COMPLETION
• R1:
lab@R1> configure
[edit]
lab@R1# set protocols mpls no-propagate-ttl
[edit]
commit complete
lab@R1>
• R2:
lab@R2> configure

[edit]
[edit]
commit complete
lab@R2>
• R3:
lab@R3> configure
[edit]
[edit]
commit complete
lab@R3>
• R4:
lab@R4> configure
[edit]
[edit]
commit complete
lab@R4>
• R5:
lab@R5> configure
[edit]
[edit]
commit complete
lab@R5>

Note
For verification, you can traceroute through
your MPLS core using the vr-device router.
Each virtual routing instance acting as a
external provider has a loopback address
assigned to it. You can use these
addresses to verify TTL behavior. Before
verifying, you must resignal all the LSPs for
this change to take effect.
TASK VERIFICATION
Verify that the changes you made have taken effect using traceroute.
Clear your MPLS LSPs on all routers using the clear mpls lsp command. This
will allow the TTL changes to be altered in the sessions.
Move to the VR-device.
Move to your open session on the VR-device and verify your changes by tracerouting
from one of the virtual routers through your core network to another virtual router.
For simplicity, use the traceroute 174.100.0.1 source 177.100.0.1
routing-instance customer2 command on the VR-device. This will
traceroute through the core using the r5-to-r1 LSP.
lab@vr-device> traceroute 174.100.0.1 source 177.100.0.1 routing-instance
customer2
traceroute to 174.100.0.1 (174.100.0.1) from 177.100.0.1, 30 hops max, 40 byte
packets
1 172.27.0.49 (172.27.0.49) 7.073 ms 7.696 ms 5.292 ms
2 172.27.0.10 (172.27.0.10) 8.747 ms 7.251 ms 7.771 ms
3 174.100.0.1 (174.100.0.1) 6.737 ms 9.255 ms 9.958 ms
Question: How many hops do you see when

traversing your core network?
Answer: You should see only two hops, the ingress

and the egress routers for your LSP.

Lab 11
MPLS VPNs Implementation and Troubleshooting (Detailed)
Overview
MPLS VPNs which you will need to accomplish within a specific time frame. You will have
3 hours to complete the simulation.
guide.
regarding the interpretation of each task, followed by step-by-step instructions. Some
tasks might include multiple methods for accomplishing each task.
• Create a Layer 3 VPN named vpn-1, connecting the following sites: CE-1,
CE-2, CE-3, and CE-4. The CE-3 and CE-4 sites peer using BGP. The CE-1 and
CE-2 are using OSPF Area 0. Ensure all the CE routers can ping the remote
directly connected PE-CE links.
• The CE-1 and CE-2 routers share a backdoor OSPF connection. Ensure that
CE-1 and CE-2 prefer to send traffic through the Layer 3 VPN. The internal
connection between CE-1 and CE-2 has an interface metric of 10.
• You are required to provide Internet access for vpn-1 on the R1 PE router. You
are allowed to use one static route to complete this task.
• On R1, ensure that vpn-1 traffic destined to CE-1 uses the r1-to-r5-one
LSP and traffic destined to CE-3 uses the r1-to-r5-two LSP.
• Configure a VPLS Layer 2 VPN named vpn-2 between CE-5 and CE-6 using
VLAN 200. Make sure the VPN uses the VPN RFC 4448 encapsulation and
uses BGP as the VPN signalling protocol. The maximum number of MAC
addresses learned by the VPLS domain should be limited to 500 on each
PE-CE link. Ensure that broadcast and multicast traffic will be policed to
50 Mbps for all sites before entering the MPLS domain.
www.juniper.net MPLS VPNs Implementation and Troubleshooting (Detailed) • Lab 11–1

10.b.10.3
• You must extend vpn-3 connecting CE-7 to CE-8 using an inter-provider
solution with ISP-A. You must not configure a routing instance on R3. The
address of the remote PE will be learned from ISP-A.The remote PE is
using the route target value of target:60001:101. Use the information in
the lab diagram for this lab to complete this task.
Lab 11–2 • MPLS VPNs Implementation and Troubleshooting (Detailed) www.juniper.net

Part 1: Configuring Layer 3 VPNs
In this lab part, you will log in to your assigned routers and configure a Layer 3 VPN.
Refer to network diagram for this lab for topological and configuration details. You
will be required to configure additional features and functionality to your VPN as
defined in the tasks for this lab.
Note
INITIAL TASK
TASK COMPLETION
• R1:
R1 (ttyd0)
login: lab
Password:

lab@R1>
• R2:
R2 (ttyd0)
login: lab
Password:

lab@R2>
• R3:
R3 (ttyd0)
login: lab
Password:

lab@R3>

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

lab@R4>
• R5:
R5 (ttyd0)
login: lab
Password:

lab@R5>
• VR-device:
vr-device (ttyd0)
login: lab
Password:

lab@vr-device>
TASK 1
Create a Layer 3 VPN called vpn-1, connecting the following
sites: CE-1, CE-2, CE-3, and CE-4. The CE-3 and CE-4 sites
peer using BGP. The CE-1 and CE-2 are using OSPF area 0.
Ensure all the CE routers can ping the remote directly
connected PE-CE links.
TASK INTERPRETATION
To complete this task, you must configure a VPN routing instance on routers R1, R5,
and R4 to connect the specified CE devices. Begin by configuring the routing
instance on R5 because two peerings exist. Include the appropriate interfaces for
the VPN instance. Define a Type 1 route distinguisher using the local loopback
address, to uniquely identify the source of the route advertisements. Define the VPN
route target as target:65100:100. This target is used to identify which MP-BGP
routes to accept. Configure an external BGP peering to CE-3 from your routing
instance, using the information outlined on the lab diagram. Note, that because
both sites are peering using the same AS, you must configure the BGP groups with
as-override. Using this option allows the PE to advertise the remote routes into
the site. Configure an OSPF peering to the CE-1 router from your routing instance.
You must create a routing policy to export your BGP routes into OSPF on R4 and R5,
so that the routes learned from your MP-BGP and EBGP peers can be shared with
the OSPF CE routers. On R5, you must include the direct route for the interface
connecting to CE-3 to ensure that this route is sent from both R4 and R5 into the
OSPF network.

Next, create a routing policy to export the OSPF routes on R5 to CE-3 through BGP.
Remember to include the directly connected network for the OSPF connection to
CE-1.
You must enable the support for the VPN NLRI on your internal BGP peering by
configuring the family inet-vpn unicast statement. Make sure you also
continue to receive standard BGP routes by configuring the family inet
unicast statement.
To accomplish the final piece of this task, you must make sure that you are
advertising the directly connected networks to your VPN peers. This is handled by
default when using the vrf-target option. If you use a vrf-export and
vrf-import policy you must make sure you include the direct routes.
Make the appropriate configurations one R1 and R4 to establish VPN connectivity to
their CE devices. Use the same method for creating your route distinguisher and
ensure that the route target matches for each instance in the vpn-1 VPN.
TASK COMPLETION
• R5:
lab@R5> configure
[edit]
[edit]
lab@R5# set protocols bgp group internal family inet-vpn unicast
[edit]
lab@R5# edit routing-instances vpn-1
[edit routing-instances vpn-1]

lab@R5# set instance-type vrf

lab@R5# set interface ge-0/0/3


lab@R5# set route-distinguisher 172.27.255.5:1

lab@R5# set vrf-target target:65100:100

lab@R5# show
instance-type vrf;
route-distinguisher 172.27.255.5:1;
vrf-target target:65100:100;

lab@R5# set protocols bgp group to-ce3 type external

lab@R5# set protocols bgp group to-ce3 neighbor 172.27.0.50 peer-as 65100

lab@R5# set protocols bgp group to-ce3 as-override

lab@R5# set protocols ospf area 0 interface ge-0/0/3

lab@R5# top
[edit]
lab@R5# edit policy-options policy-statement bgp-to-ospf
[edit policy-options policy-statement bgp-to-ospf]






lab@R5# up
lab@R5# edit policy-statement ospf-to-bgp
[edit policy-options policy-statement ospf-to-bgp]

lab@R5# set term 1 from protocol ospf





lab@R5# top
[edit]

lab@R5# set protocols ospf export bgp-to-ospf

lab@R5# set protocols bgp group to-ce3 export ospf-to-bgp

commit complete
lab@R5>
• R4:
lab@R4> configure
[edit]
[edit]
[edit]





lab@R4# set protocols ospf area 0 interface ge-0/0/3

lab@R4# top
[edit]
lab@R4# edit policy-options policy-statement bgp-to-ospf



lab@R4# top
[edit]

lab@R4# set protocols ospf export bgp-to-ospf

commit complete
lab@R4>
• R1:
lab@R1> configure
[edit]
[edit]
[edit]





lab@R1# set protocols bgp group to-ce4 type external

lab@R1# set protocols bgp group to-ce4 neighbor 172.27.0.34 peer-as 65100

lab@R1# set protocols bgp group to-ce4 as-override

commit complete
lab@R1>
TASK VERIFICATION
Begin your verification by reviewing the status of your PE to CE neighborships. To
simplify the outputs, you should include the instance option with the show
command and specify the VPN name. Review the vpn-1.inet.0 routing table to
verify that you have the remote networks for the directly connected interface. You
can include the terse option to quickly see what networks are there without all the
extra detailed information.
You should also log into the VR-device and verify the routing tables for each of the CE
devices. Finally, verify that you can ping from the local CE interface to the remote CE
interfaces for all of your CE routers.
You do not need to verify every detail from each device because if it is working on
one or two routers, it should be working on all.
You might want to review the contents of the bgp.l3vpn.0 routing table to see
which routes are being learned from which PE router by using the route distinguisher
that is prepended to the prefix.
Note
During the verification phase of the first
task, you must determine which routes are
being sent from which CE device. You can
determine this by systematically reviewing
the VRF tables and isolating the routes. To
save you some time during this step, the CE
devices in your Layer 3 VPN are listed below
with the routes they should be sending:
CE-1 = 65.100.0.0/24 to 65.100.4.0/24
CE-2 = 65.100.5.0/24 to 65.100.9.0/24
CE-3 = 65.100.10.0/24 to 65.100.14.0/24
CE-4 = 65.100.15.0/24 to 65.100.19.0/24
• R5:
lab@R5> show bgp summary instance vpn-1

vpn-1.inet.0 27 11 0 0 0 0
vpn-1.mdt.0 0 0 0 0 0 0
172.27.0.50 65100 535 8263 0 0 4:02:46
Establ
vpn-1.inet.0: 5/5/5/0
lab@R5> show ospf neighbor instance vpn-1

172.27.0.46 ge-0/0/3.0 Full 65.100.255.1 128 37
lab@R5> show route table vpn-1.inet.0 terse
vpn-1.inet.0: 30 destinations, 46 routes (30 active, 0 holddown, 0 hidden)


* 65.100.0.0/24 O 150 0 >172.27.0.46
B 170 100 0 >172.27.0.21 I
* 65.100.0.0/30 O 10 11 >172.27.0.46
B 170 100 35 >172.27.0.21 I
* 65.100.1.0/24 O 150 0 >172.27.0.46
B 170 100 0 >172.27.0.21 I
* 65.100.2.0/24 O 150 0 >172.27.0.46
B 170 100 0 >172.27.0.21 I
* 65.100.3.0/24 O 150 0 >172.27.0.46
B 170 100 0 >172.27.0.21 I
* 65.100.4.0/24 O 150 0 >172.27.0.46
B 170 100 0 >172.27.0.21 I
* 65.100.5.0/24 O 150 0 >172.27.0.46
B 170 100 0 >172.27.0.21 I
* 65.100.6.0/24 O 150 0 >172.27.0.46
B 170 100 0 >172.27.0.21 I
* 65.100.7.0/24 O 150 0 >172.27.0.46
B 170 100 0 >172.27.0.21 I
* 65.100.8.0/24 O 150 0 >172.27.0.46
B 170 100 0 >172.27.0.21 I
* 65.100.9.0/24 O 150 0 >172.27.0.46
B 170 100 0 >172.27.0.21 I
* 65.100.10.0/24 B 170 100 >172.27.0.50 65100 I
* 65.100.11.0/24 B 170 100 >172.27.0.50 65100 I
* 65.100.12.0/24 B 170 100 >172.27.0.50 65100 I
* 65.100.13.0/24 B 170 100 >172.27.0.50 65100 I
* 65.100.14.0/24 B 170 100 >172.27.0.50 65100 I
* 65.100.15.0/24 B 170 100 >172.27.0.26 65100 I
* 65.100.16.0/24 B 170 100 >172.27.0.26 65100 I
* 65.100.17.0/24 B 170 100 >172.27.0.26 65100 I
* 65.100.18.0/24 B 170 100 >172.27.0.26 65100 I
* 65.100.19.0/24 B 170 100 >172.27.0.26 65100 I
* 65.100.255.1/32 O 10 1 >172.27.0.46
B 170 100 35 >172.27.0.21 I
* 65.100.255.2/32 O 10 11 >172.27.0.46
B 170 100 25 >172.27.0.21 I

* 172.27.0.32/30 B 170 100 >172.27.0.26 I
* 172.27.0.40/30 O 10 12 >172.27.0.46
B 170 100 >172.27.0.21 I
* 172.27.0.44/30 D 0 >ge-0/0/3.0
B 170 100 36 >172.27.0.21 I
* 172.27.0.45/32 L 0 Local
* 172.27.0.48/30 D 0 >ge-0/0/4.0
B 170 100 0 >172.27.0.21 I
* 172.27.0.49/32 L 0 Local
* 224.0.0.5/32 O 10 1 MultiRecv
• R1:
lab@R1> show bgp summary instance vpn-1
vpn-1.inet.0 42 26 0 0 0 0
vpn-1.mdt.0 0 0 0 0 0 0
172.27.0.34 65100 7859 279724 0 0 2d 11:33:04
Establ
vpn-1.inet.0: 5/5/5/0


* 65.100.0.0/24 B 170 100 0 >172.27.0.13 I
B 170 100 0 >172.27.0.9 I
172.27.0.13
* 65.100.0.0/30 B 170 100 11 >172.27.0.9 I
172.27.0.13
B 170 100 35 >172.27.0.13 I
* 65.100.1.0/24 B 170 100 0 >172.27.0.13 I
B 170 100 0 >172.27.0.9 I
172.27.0.13
* 65.100.2.0/24 B 170 100 0 >172.27.0.13 I
B 170 100 0 >172.27.0.9 I
172.27.0.13
* 65.100.3.0/24 B 170 100 0 >172.27.0.13 I
B 170 100 0 >172.27.0.9 I
172.27.0.13
* 65.100.4.0/24 B 170 100 0 >172.27.0.13 I
B 170 100 0 >172.27.0.9 I
172.27.0.13
* 65.100.5.0/24 B 170 100 0 >172.27.0.13 I
B 170 100 0 >172.27.0.9 I
172.27.0.13
* 65.100.6.0/24 B 170 100 0 >172.27.0.13 I
B 170 100 0 >172.27.0.9 I
172.27.0.13

* 65.100.7.0/24 B 170 100 0 >172.27.0.13 I
B 170 100 0 >172.27.0.9 I
172.27.0.13
* 65.100.8.0/24 B 170 100 0 >172.27.0.13 I
B 170 100 0 172.27.0.9 I
>172.27.0.13
* 65.100.9.0/24 B 170 100 0 >172.27.0.13 I
B 170 100 0 172.27.0.9 I
>172.27.0.13
* 65.100.10.0/24 B 170 100 0 >172.27.0.13 I
* 65.100.11.0/24 B 170 100 0 >172.27.0.13 I
* 65.100.12.0/24 B 170 100 0 >172.27.0.13 I
* 65.100.13.0/24 B 170 100 0 >172.27.0.13 I
* 65.100.14.0/24 B 170 100 0 >172.27.0.13 I
* 65.100.15.0/24 B 170 100 >172.27.0.34 65100 I
* 65.100.16.0/24 B 170 100 >172.27.0.34 65100 I
* 65.100.17.0/24 B 170 100 >172.27.0.34 65100 I
* 65.100.18.0/24 B 170 100 >172.27.0.34 65100 I
* 65.100.19.0/24 B 170 100 >172.27.0.34 65100 I
* 65.100.255.1/32 B 170 100 1 172.27.0.9 I
>172.27.0.13
B 170 100 35 >172.27.0.13 I
* 65.100.255.2/32 B 170 100 11 172.27.0.9 I
>172.27.0.13
B 170 100 25 >172.27.0.13 I
* 172.27.0.32/30 D 0 >ge-0/0/2.0
* 172.27.0.33/32 L 0 Local
* 172.27.0.40/30 B 170 100 >172.27.0.13 I
B 170 100 12 172.27.0.9 I
>172.27.0.13
* 172.27.0.44/30 B 170 100 172.27.0.9 I
>172.27.0.13
B 170 100 36 >172.27.0.13 I
* 172.27.0.48/30 B 170 100 0 >172.27.0.13 I
• R4:
lab@R4> show ospf neighbor instance vpn-1
172.27.0.42 ge-0/0/3.0 Full 65.100.255.2 128 34


* 65.100.0.0/24 O 150 0 >172.27.0.42
B 170 100 0 >172.27.0.22 I
* 65.100.0.0/30 O 10 35 >172.27.0.42
B 170 100 11 >172.27.0.22 I
* 65.100.1.0/24 O 150 0 >172.27.0.42
B 170 100 0 >172.27.0.22 I
* 65.100.2.0/24 O 150 0 >172.27.0.42
B 170 100 0 >172.27.0.22 I

* 65.100.3.0/24 O 150 0 >172.27.0.42
B 170 100 0 >172.27.0.22 I
* 65.100.4.0/24 O 150 0 >172.27.0.42
B 170 100 0 >172.27.0.22 I
* 65.100.5.0/24 O 150 0 >172.27.0.42
B 170 100 0 >172.27.0.22 I
* 65.100.6.0/24 O 150 0 >172.27.0.42
B 170 100 0 >172.27.0.22 I
* 65.100.7.0/24 O 150 0 >172.27.0.42
B 170 100 0 >172.27.0.22 I
* 65.100.8.0/24 O 150 0 >172.27.0.42
B 170 100 0 >172.27.0.22 I
* 65.100.9.0/24 O 150 0 >172.27.0.42
B 170 100 0 >172.27.0.22 I
* 65.100.10.0/24 B 170 100 >172.27.0.22 65100 I
* 65.100.11.0/24 B 170 100 >172.27.0.22 65100 I
* 65.100.12.0/24 B 170 100 >172.27.0.22 65100 I
* 65.100.13.0/24 B 170 100 >172.27.0.22 65100 I
* 65.100.14.0/24 B 170 100 >172.27.0.22 65100 I
* 65.100.15.0/24 B 170 100 >172.27.0.17 65100 I
* 65.100.16.0/24 B 170 100 >172.27.0.17 65100 I
* 65.100.17.0/24 B 170 100 >172.27.0.17 65100 I
* 65.100.18.0/24 B 170 100 >172.27.0.17 65100 I
* 65.100.19.0/24 B 170 100 >172.27.0.17 65100 I
* 65.100.255.1/32 O 10 35 >172.27.0.42
B 170 100 1 >172.27.0.22 I
* 65.100.255.2/32 O 10 25 >172.27.0.42
B 170 100 11 >172.27.0.22 I
* 172.27.0.32/30 B 170 100 >172.27.0.17 I
* 172.27.0.40/30 D 0 >ge-0/0/3.0
B 170 100 12 >172.27.0.22 I
* 172.27.0.41/32 L 0 Local
* 172.27.0.44/30 O 10 36 >172.27.0.42
B 170 100 >172.27.0.22 I
* 172.27.0.48/30 O 150 0 >172.27.0.42
B 170 100 >172.27.0.22 I
* 224.0.0.5/32 O 10 1 MultiRecv
Now return to the session you have open to your VR-device.
Begin by looking at the routing table and verify that you have the interface routes for
other remote CE interfaces. After verifying that the routes are present, ping the
remote interface. Remember that all of the CE devices are in a virtual routing
instances and you must include the proper routing instance when using the ping
utility.
• VR-device:
lab@vr-device> show route table CE-1.inet.0 terse
CE-1.inet.0: 30 destinations, 30 routes (30 active, 0 holddown, 0 hidden)


* 65.100.0.0/24 S 5 Reject
* 65.100.0.0/30 D 0 >ge-0/0/11.0
* 65.100.0.1/32 L 0 Local
* 65.100.1.0/24 S 5 Reject
* 65.100.2.0/24 S 5 Reject
* 65.100.3.0/24 S 5 Reject
* 65.100.4.0/24 S 5 Reject
* 65.100.5.0/24 O 150 0 >65.100.0.2
* 65.100.6.0/24 O 150 0 >65.100.0.2
* 65.100.7.0/24 O 150 0 >65.100.0.2
* 65.100.8.0/24 O 150 0 >65.100.0.2
* 65.100.9.0/24 O 150 0 >65.100.0.2
* 65.100.10.0/24 O 150 0 >172.27.0.45
* 65.100.11.0/24 O 150 0 >172.27.0.45
* 65.100.12.0/24 O 150 0 >172.27.0.45
* 65.100.13.0/24 O 150 0 >172.27.0.45
* 65.100.14.0/24 O 150 0 >172.27.0.45
* 65.100.15.0/24 O 150 0 >172.27.0.45
* 65.100.16.0/24 O 150 0 >172.27.0.45
* 65.100.17.0/24 O 150 0 >172.27.0.45
* 65.100.18.0/24 O 150 0 >172.27.0.45
* 65.100.19.0/24 O 150 0 >172.27.0.45
* 65.100.255.1/32 D 0 >lo0.1
* 65.100.255.2/32 O 10 10 >65.100.0.2
* 172.27.0.32/30 O 150 0 >172.27.0.45
* 172.27.0.40/30 O 10 11 >65.100.0.2
* 172.27.0.44/30 D 0 >ge-0/0/8.0
* 172.27.0.46/32 L 0 Local
* 172.27.0.48/30 O 150 0 >172.27.0.45
* 224.0.0.5/32 O 10 1 MultiRecv
lab@vr-device> show route table CE-4.inet.0 terse


* 65.100.0.0/24 B 170 100 >172.27.0.33 3895077211 I
* 65.100.0.0/30 B 170 100 >172.27.0.33 3895077211 I
* 65.100.1.0/24 B 170 100 >172.27.0.33 3895077211 I
* 65.100.2.0/24 B 170 100 >172.27.0.33 3895077211 I
* 65.100.3.0/24 B 170 100 >172.27.0.33 3895077211 I
* 65.100.4.0/24 B 170 100 >172.27.0.33 3895077211 I
* 65.100.5.0/24 B 170 100 >172.27.0.33 3895077211 I
* 65.100.6.0/24 B 170 100 >172.27.0.33 3895077211 I
* 65.100.7.0/24 B 170 100 >172.27.0.33 3895077211 I
* 65.100.8.0/24 B 170 100 >172.27.0.33 3895077211 I
* 65.100.9.0/24 B 170 100 >172.27.0.33 3895077211 I
* 65.100.10.0/24 B 170 100 >172.27.0.33 3895077211
3895077211 I
* 65.100.11.0/24 B 170 100 >172.27.0.33 3895077211
3895077211 I
* 65.100.12.0/24 B 170 100 >172.27.0.33 3895077211
3895077211 I

* 65.100.13.0/24 B 170 100 >172.27.0.33 3895077211
3895077211 I
* 65.100.14.0/24 B 170 100 >172.27.0.33 3895077211
3895077211 I
* 65.100.15.0/24 S 5 Reject
* 65.100.16.0/24 S 5 Reject
* 65.100.17.0/24 S 5 Reject
* 65.100.18.0/24 S 5 Reject
* 65.100.19.0/24 S 5 Reject
* 65.100.255.1/32 B 170 100 >172.27.0.33 3895077211 I
* 65.100.255.2/32 B 170 100 >172.27.0.33 3895077211 I
* 65.100.255.4/32 D 0 >lo0.4
* 172.27.0.32/30 D 0 >ge-0/0/2.0
* 172.27.0.34/32 L 0 Local
* 172.27.0.40/30 B 170 100 >172.27.0.33 3895077211 I
* 172.27.0.44/30 B 170 100 >172.27.0.33 3895077211 I
* 172.27.0.48/30 B 170 100 >172.27.0.33 3895077211 I
lab@vr-device> ping 172.27.0.46 routing-instance CE-4 count 5

PING 172.27.0.46 (172.27.0.46): 56 data bytes


PING 172.27.0.50 (172.27.0.50): 56 data bytes


PING 172.27.0.42 (172.27.0.42): 56 data bytes


Question: Do your pings complete?
Answer: Yes, your pings should complete. If they do

not, please verify your routing tables have the
correct routes.
TASK 2
The CE-1 and CE-2 routers share a backdoor OSPF connection.
Ensure that CE-1 and CE-2 prefer to send traffic through
the Layer 3 VPN. The internal connection between CE-1 and
CE-2 has an interface metric of 10.
TASK INTERPRETATION
To complete this task, you must ensure that the VPN connection appears as an
internal route, which allows you to alter the link metric to make the VPN more
preferred than the existing connection between CE-1 and CE-2 to allow the VPN to
appear as a internal link, you must configure a sham link between R4 and R5. As a
requirement for sham links, you must include a loopback address. Configure a
secondary loopback unit using 65.100.255.14 on R4 and 65.100.255.15 on R5.
Add this interface to the VPN. The loopback interface address is used as the local
and remote address for the sham link. Finally, you must add a metric to the sham
link that is lower than the existing connection between CE-1 and CE-2, which has a
metric of 10.
TASK COMPLETION
• R4:
lab@R4> configure
[edit]
[edit]

lab@R4# set interface lo0.1

[edit routing-instances vpn-1 protocols ospf]

lab@R4# set sham-link local 65.100.255.14

lab@R4# set area 0 interface lo0.1

lab@R4# set area 0 sham-link-remote 65.100.255.15 metric 1

commit complete
lab@R4>
• R5:
lab@R5> configure
[edit]
[edit]

lab@R5# set interface lo0.1


lab@R5# set sham-link local 65.100.255.15

lab@R5# set area 0 interface lo0.1

lab@R5# set area 0 sham-link-remote 65.100.255.14 metric 1

commit complete
lab@R5>
TASK VERIFICATION
Begin your verification by reviewing the OSPF database for CE-1. Remember this
device is in a routing instance, so you have to include the instance CE-1 with
your show commands. After verifying you have the router LSAs for R4 and R5, review
your CE-1 OSPF route for the loopback address of CE-2 (65.100.255.2). This route
should point to R5 as the next hop and avoid the original link between CE-1 and
CE-2. You can include the extensive option to see the IP address for the next hop.
• CE-1:
lab@vr-device> show ospf database instance CE-1

Router *65.100.255.1 65.100.255.1 0x80000093 764 0x22 0xa7a0 60

Router 65.100.255.2 65.100.255.2 0x80000091 1262 0x22 0xb43 60
Router 65.100.255.14 65.100.255.14 0x80000006 410 0x22 0xaaf1 48
Router 65.100.255.15 65.100.255.15 0x80000004 725 0x22 0xe8ac 48
Router 172.27.0.41 172.27.0.41 0x800000c3 1962 0x22 0xc1ce 36
Router 172.27.0.45 172.27.0.45 0x800000b9 1383 0x22 0x445e 36
Network 65.100.0.2 65.100.255.2 0x8000008b 1831 0x22 0x759f 32
Network 172.27.0.41 65.100.255.14 0x80000002 1263 0x22 0x3a02 32
Network 172.27.0.45 65.100.255.15 0x80000002 765 0x22 0x82f 32
OSPF AS SCOPE link state database
Extern *65.100.0.0 65.100.255.1 0x8000008d 2158 0x22 0x6e6b 36
Extern *65.100.1.0 65.100.255.1 0x8000008d 1033 0x22 0x6375 36
Extern *65.100.2.0 65.100.255.1 0x8000008d 658 0x22 0x587f 36
Extern *65.100.3.0 65.100.255.1 0x8000008d 283 0x22 0x4d89 36
Extern *65.100.4.0 65.100.255.1 0x8000008c 2533 0x22 0x4492 36
Extern 65.100.5.0 65.100.255.2 0x8000008b 831 0x22 0x35a0 36
...
lab@vr-device> show route 65.100.255.2 table CE-1.inet.0 extensive

65.100.255.2/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 65.100.255.2/32 -> {172.27.0.45}
*OSPF Preference: 10
State: <Active Int>
Local AS: 65100
Age: 13:41 Metric: 3
Area: 0.0.0.0
Task: CE-1-OSPF
AS path: I
TASK 3
You are required to provide internet access for vpn-1 on
the R1 PE router. You are allowed to use one static route
to complete this task.
Note
Internet access for this lab means that you
can reach routers and addresses outside
the VPN environment. You do not have a full
Internet routing table and you do not have
external EBGP peers advertising external
routes into our IBGP core. You will verify this
task by reviewing the routing tables and
using the ping utility to pass traffic from
devices in the routing instance to your core
devices in your network.

TASK INTERPRETATION
To complete this task, you must create a static route in the main instance that
encompasses the VPN networks (65.100.0.0/16) with the next-table operation
pointing to vpn-1.inet.0. Advertise this static route into your IBGP network using
an export policy. This policy allows the Internet traffic to reach to your VPN. Because
you do not have any EBGP peers for R1 in this lab, you can simply export this route
by adding a new term to your next hop self policy. Alternatively, you could create a
new export policy and apply to your internal IBGP group. Next, you will create a
rib-group designed to copy the routes from the inet.0 into the
vpn-1.inet.0 routing table. Finally, you must apply this RIB group to your IBGP,
OSPF, and interface routes in the main instance.
TASK COMPLETION
• R1:
lab@R1> configure
[edit]
lab@R1# set static route 65.100.0/16 next-table vpn-1.inet.0
[edit policy-options policy-statement export-vpn]

lab@R1# top edit policy-options policy-statement nhs

lab@R1# set term 2 from protocol static route-filter 65.100/16 exact


lab@R1# set rib-groups rib-1 import-rib [inet.0 vpn-1.inet.0]
lab@R1# set interface-routes rib-group rib-1
[edit protocols]
lab@R1# set ospf rib-group rib-1
[edit protocols]
lab@R1# set bgp group internal family inet unicast rib-group rib-1

[edit protocols]
commit complete
lab@R1>
TASK VERIFICATION
Begin your verification by reviewing the vpn-1.inet.0 routing table on R1 to
verify that you now have all the Internet routes. Next, verify that you have the Internet
routes in the vpn-1.inet.0 routing table on R5. While on R5, verify that you have
the 65.100.0.0/16 route in the inet.0 routing table. Once you have verified the
routes are present, ping from the main instance to the loopback address on R5 that
is assigned to the routing instance. This action can be accomplished using the ping
65.100.255.15 count 5 command. This command will illustrate that you can
pass traffic from the main instance through R1 into the VPN to R5. You can do
additional verification if you want.
• R1:


* 65.100.0.0/24 B 170 100 0 >172.27.0.9 I
172.27.0.13
* 65.100.0.0/30 B 170 100 11 >172.27.0.9 I
B 170 100 11 >172.27.0.9 I
172.27.0.13
* 65.100.1.0/24 B 170 100 0 >172.27.0.9 I
172.27.0.13
* 65.100.2.0/24 B 170 100 0 >172.27.0.9 I
172.27.0.13
* 65.100.3.0/24 B 170 100 0 >172.27.0.9 I
172.27.0.13
* 65.100.4.0/24 B 170 100 0 >172.27.0.9 I
172.27.0.13
* 65.100.5.0/24 B 170 100 0 >172.27.0.9 I
* 65.100.6.0/24 B 170 100 0 >172.27.0.9 I
* 65.100.7.0/24 B 170 100 0 >172.27.0.9 I
* 65.100.8.0/24 B 170 100 0 >172.27.0.9 I
* 65.100.9.0/24 B 170 100 0 >172.27.0.9 I
* 65.100.10.0/24 B 170 100 172.27.0.9 65100 I
>172.27.0.13
* 65.100.11.0/24 B 170 100 172.27.0.9 65100 I
>172.27.0.13
* 65.100.12.0/24 B 170 100 172.27.0.9 65100 I
>172.27.0.13
* 65.100.13.0/24 B 170 100 172.27.0.9 65100 I
>172.27.0.13
* 65.100.14.0/24 B 170 100 172.27.0.9 65100 I
>172.27.0.13

* 65.100.15.0/24 B 170 100 >172.27.0.34 65100 I
* 65.100.15.255/32 B 170 100 >172.27.0.34 65100 I
* 65.100.16.0/24 B 170 100 >172.27.0.34 65100 I
* 65.100.17.0/24 B 170 100 >172.27.0.34 65100 I
* 65.100.18.0/24 B 170 100 >172.27.0.34 65100 I
* 65.100.19.0/24 B 170 100 >172.27.0.34 65100 I
* 65.100.255.1/32 B 170 100 1 172.27.0.9 I
>172.27.0.13
* 65.100.255.2/32 B 170 100 1 >172.27.0.9 I
* 65.100.255.3/32 B 170 100 172.27.0.9 65100 I
>172.27.0.13
* 65.100.255.4/32 B 170 100 >172.27.0.34 65100 I
* 65.100.255.14/32 B 170 100 >172.27.0.9 I
* 65.100.255.15/32 B 170 100 >172.27.0.9 I
172.27.0.13
* 172.27.0.0/30 D 0 >ge-0/0/3.0
* 172.27.0.1/32 L 0 Local
* 172.27.0.4/30 O 10 2 >172.27.0.2
* 172.27.0.8/30 D 0 >ae0.0
* 172.27.0.10/32 L 0 Local
* 172.27.0.12/30 D 0 >ge-0/0/6.0
* 172.27.0.14/32 L 0 Local
* 172.27.0.16/30 O 10 2 >172.27.0.13
* 172.27.0.20/30 O 10 3 172.27.0.2
>172.27.0.13
* 172.27.0.24/30 O 10 2 >172.27.0.13
* 172.27.0.28/30 D 0 >ge-0/0/1.0
* 172.27.0.29/32 L 0 Local
* 172.27.0.32/30 D 0 >ge-0/0/2.0
B 170 100 >172.27.0.34 65100 I
* 172.27.0.33/32 L 0 Local
* 172.27.0.40/30 B 170 100 >172.27.0.9 I
* 172.27.0.44/30 B 170 100 172.27.0.9 I
>172.27.0.13
* 172.27.0.48/30 B 170 100 >172.27.0.9 I
172.27.0.13
* 172.27.255.1/32 D 0 >lo0.0
* 172.27.255.2/32 O 10 1 >172.27.0.2
* 172.27.255.3/32 O 10 1 >172.27.0.13
* 172.27.255.4/32 O 10 2 >172.27.0.2
172.27.0.13
* 172.27.255.5/32 O 10 2 >172.27.0.13
• R5:


* 65.100.0.0/24 O 150 0 >172.27.0.46
* 65.100.0.0/30 O 10 11 >172.27.0.46
B 170 100 11 >172.27.0.26 I
* 65.100.1.0/24 O 150 0 >172.27.0.46

* 65.100.2.0/24 O 150 0 >172.27.0.46
* 65.100.3.0/24 O 150 0 >172.27.0.46
* 65.100.4.0/24 O 150 0 >172.27.0.46
* 65.100.5.0/24 B 170 100 0 >172.27.0.26 I
* 65.100.6.0/24 B 170 100 0 >172.27.0.26 I
* 65.100.7.0/24 B 170 100 0 >172.27.0.26 I
* 65.100.8.0/24 B 170 100 0 >172.27.0.26 I
* 65.100.9.0/24 B 170 100 0 >172.27.0.26 I
* 65.100.10.0/24 B 170 100 >172.27.0.50 65100 I
* 65.100.11.0/24 B 170 100 >172.27.0.50 65100 I
* 65.100.12.0/24 B 170 100 >172.27.0.50 65100 I
* 65.100.13.0/24 B 170 100 >172.27.0.50 65100 I
* 65.100.14.0/24 B 170 100 >172.27.0.50 65100 I
* 65.100.15.0/24 B 170 100 >172.27.0.26 65100 I
* 65.100.15.255/32 B 170 100 >172.27.0.26 65100 I
* 65.100.16.0/24 B 170 100 >172.27.0.26 65100 I
* 65.100.17.0/24 B 170 100 >172.27.0.26 65100 I
* 65.100.18.0/24 B 170 100 >172.27.0.26 65100 I
* 65.100.19.0/24 B 170 100 >172.27.0.26 65100 I
* 65.100.255.1/32 O 10 1 >172.27.0.46
* 65.100.255.2/32 B 170 100 1 >172.27.0.26 I
* 65.100.255.3/32 B 170 100 >172.27.0.50 65100 I
* 65.100.255.4/32 B 170 100 >172.27.0.26 65100 I
* 65.100.255.14/32 B 170 100 >172.27.0.26 I
* 65.100.255.15/32 D 0 >lo0.1
* 172.27.0.0/30 B 170 100 >172.27.0.26 I
* 172.27.0.4/30 B 170 100 2 >172.27.0.26 I
* 172.27.0.12/30 B 170 100 >172.27.0.26 I
* 172.27.0.16/30 B 170 100 2 >172.27.0.26 I
* 172.27.0.20/30 B 170 100 3 >172.27.0.26 I
* 172.27.0.24/30 B 170 100 2 >172.27.0.26 I
* 172.27.0.32/30 B 170 100 >172.27.0.26 I
* 172.27.0.40/30 B 170 100 >172.27.0.26 I
* 172.27.0.44/30 D 0 >ge-0/0/3.0
* 172.27.0.45/32 L 0 Local
* 172.27.0.48/30 D 0 >ge-0/0/4.0
B 170 100 >172.27.0.50 65100 I
* 172.27.0.49/32 L 0 Local
* 172.27.255.1/32 B 170 100 >172.27.0.26 I
* 172.27.255.2/32 B 170 100 1 >172.27.0.26 I
* 172.27.255.3/32 B 170 100 1 >172.27.0.26 I
* 172.27.255.4/32 B 170 100 2 >172.27.0.26 I
* 172.27.255.5/32 B 170 100 2 >172.27.0.26 I
* 224.0.0.5/32 O 10 1 MultiRecv
lab@R5> show route table inet.0 terse


* 65.100.0.0/16 B 170 100 >172.27.0.26 I
* 172.27.0.0/30 O 10 3 >172.27.0.26
172.27.0.21

* 172.27.0.4/30 O 10 2 >172.27.0.21
* 172.27.0.8/30 O 10 16 >172.27.0.21
* 172.27.0.12/30 O 10 2 >172.27.0.26
* 172.27.0.16/30 O 10 2 172.27.0.26
>172.27.0.21
* 172.27.0.20/30 D 0 >ge-0/0/2.0
* 172.27.0.22/32 L 0 Local
* 172.27.0.24/30 D 0 >ge-0/0/1.0
* 172.27.0.25/32 L 0 Local
* 172.27.255.1/32 O 10 2 >172.27.0.26
* 172.27.255.2/32 O 10 2 >172.27.0.21
* 172.27.255.3/32 O 10 1 >172.27.0.26
* 172.27.255.4/32 O 10 1 >172.27.0.21
* 172.27.255.5/32 D 0 >lo0.0
* 224.0.0.5/32 O 10 1 MultiRecv
lab@R5> ping 65.100.255.15 count 5

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

Question: Are your pings successful?
Answer: Yes, you should be able to ping from the

main instance into the VPN.
TASK 4
On R1, ensure that vpn-1 traffic destined to CE-1 uses the
r1-to-r5-one LSP and traffic destined to CE-3 uses the
r1-to-r5-two LSP.
TASK INTERPRETATION
To complete this task, you must create two additional unique communities on R5.
You must add these communities to the routes learned from the each of the CE
neighbors before advertising them through MP-BGP to the other PE routers.
Remember to also create and add the target community to these routes before
you accept and advertise them to your MP-BGP peers. Remember to include the
direct routes when adding the communities to the BGP routes. To add additional
communities to your MP-BGP routes, you must manually create a vrf-export
and vrf-import policies on R5, and remove the vrf-target statement.
You must then create a policy on R1 to alter the next-hop LSP in the forwarding table
based on which community tag is present in the BGP route.You must define the
communities and values on R1 also.

TASK COMPLETION
• R5:
lab@R5> configure
[edit]
lab@R5# edit policy-options
lab@R5# set community vpn-1 members target:65100:100
lab@R5# set community ce-1 members 65100:1
lab@R5# edit policy-statement vpn-export
[edit policy-options policy-statement vpn-export]



lab@R5# set term 1 from route-filter 65.100.0/16 orlonger


lab@R5# set term 1 then community add ce-1

lab@R5# set term 1 then community add vpn-1


lab@R5# set term 2 from protocol bgp neighbor 172.27.0.50


lab@R5# set term 2 from route-filter 65.100.0/16 orlonger


lab@R5# set term 2 then community add ce-3

lab@R5# set term 2 then community add vpn-1


lab@R5# top edit policy-options policy-statement vpn-import
[edit policy-options policy-statement vpn-import]


lab@R5# set term 1 from community vpn-1


lab@R5# top edit routing-instances vpn-1

lab@R5# delete vrf-target

lab@R5# set vrf-export vpn-export

lab@R5# set vrf-import vpn-import

commit complete
lab@R5>
• R1:
lab@R1> configure
[edit]
lab@R1# edit policy-options

lab@R1# edit policy-statement set-lsp
[edit policy-options policy-statement set-lsp]


lab@R1# set term 1 from community ce-1

lab@R1# set term 1 then install-nexthop lsp r1-to-r5-one



lab@R1# set term 2 from community ce-3

lab@R1# set term 2 then install-nexthop lsp r1-to-r5-two


lab@R1# top
[edit]
lab@R1# set routing-options forwarding-table export set-lsp
[edit]
commit complete
lab@R1>
TASK VERIFICATION
You can easily verify this task on R1 by reviewing the selected next hops for the CE
prefixes advertised by the R5 router in the VRF routing table. Routes from CE-1
should show only a next-hop of LSP r1-to-r5-one and routes learned from
CE-3 should show only the next-hop of r1-to-r5-two.
• R1:
lab@R1> show route table vpn-1.inet.0


65.100.0.0/24 *[BGP/170] 00:40:28, MED 0, localpref 100, from 172.27.255.5
AS path: I
> to 172.27.0.9 via ae0.0, label-switched-path r1-to-r5-one
AS path: I
> to 172.27.0.9 via ae0.0, label-switched-path r1-to-r4
[BGP/170] 00:06:53, MED 11, localpref 100, from 172.27.255.5
AS path: I
AS path: I
AS path: I
AS path: I
AS path: I
AS path: I
AS path: I
AS path: I
AS path: I
AS path: I
AS path: 65100 I
to 172.27.0.13 via ge-0/0/6.0, label-switched-path
r1-to-r5-two
AS path: 65100 I
r1-to-r5-two
AS path: 65100 I
r1-to-r5-two
AS path: 65100 I
r1-to-r5-two

AS path: 65100 I
r1-to-r5-two
65.100.15.0/24 *[BGP/170] 04:08:15, localpref 100
AS path: 65100 I
> to 172.27.0.34 via ge-0/0/2.0
65.100.15.255/32 *[BGP/170] 04:08:15, localpref 100
AS path: 65100 I
> to 172.27.0.34 via ge-0/0/2.0
65.100.16.0/24 *[BGP/170] 04:08:15, localpref 100
AS path: 65100 I
> to 172.27.0.34 via ge-0/0/2.0
65.100.17.0/24 *[BGP/170] 04:08:15, localpref 100
AS path: 65100 I
> to 172.27.0.34 via ge-0/0/2.0
65.100.18.0/24 *[BGP/170] 04:08:15, localpref 100
AS path: 65100 I
> to 172.27.0.34 via ge-0/0/2.0
65.100.19.0/24 *[BGP/170] 04:08:15, localpref 100
AS path: 65100 I
> to 172.27.0.34 via ge-0/0/2.0
AS path: I
AS path: I
AS path: 65100 I
r1-to-r5-two
65.100.255.4/32 *[BGP/170] 04:08:15, localpref 100
AS path: 65100 I
> to 172.27.0.34 via ge-0/0/2.0
AS path: I
AS path: I
172.27.0.0/30 *[Direct/0] 02:05:23
> via ge-0/0/3.0
172.27.0.1/32 *[Local/0] 02:05:23
172.27.0.4/30 *[OSPF/10] 02:05:22, metric 2
> to 172.27.0.2 via ge-0/0/3.0
172.27.0.8/30 *[Direct/0] 02:05:23
> via ae0.0
172.27.0.10/32 *[Local/0] 02:05:23
Local via ae0.0
172.27.0.12/30 *[Direct/0] 02:05:23
> via ge-0/0/6.0
172.27.0.14/32 *[Local/0] 02:05:23

172.27.0.16/30 *[OSPF/10] 02:05:22, metric 2
> to 172.27.0.13 via ge-0/0/6.0
172.27.0.20/30 *[OSPF/10] 02:05:22, metric 3
to 172.27.0.2 via ge-0/0/3.0
> to 172.27.0.13 via ge-0/0/6.0
172.27.0.24/30 *[OSPF/10] 02:05:22, metric 2
> to 172.27.0.13 via ge-0/0/6.0
172.27.0.28/30 *[Direct/0] 02:05:23
> via ge-0/0/1.0
172.27.0.29/32 *[Local/0] 02:05:23
172.27.0.32/30 *[Direct/0] 04:08:35
> via ge-0/0/2.0
[BGP/170] 04:08:15, localpref 100
AS path: 65100 I
> to 172.27.0.34 via ge-0/0/2.0
172.27.0.33/32 *[Local/0] 04:08:35
AS path: I
AS path: I
AS path: I
r1-to-r5-two
172.27.255.1/32 *[Direct/0] 02:05:23
> via lo0.0
172.27.255.2/32 *[OSPF/10] 02:05:22, metric 1
> to 172.27.0.2 via ge-0/0/3.0
172.27.255.3/32 *[OSPF/10] 02:05:22, metric 1
> to 172.27.0.13 via ge-0/0/6.0
172.27.255.4/32 *[OSPF/10] 02:05:22, metric 2
> to 172.27.0.2 via ge-0/0/3.0
to 172.27.0.13 via ge-0/0/6.0
172.27.255.5/32 *[OSPF/10] 02:05:22, metric 2
> to 172.27.0.13 via ge-0/0/6.0
TASK 5
Configure a VPLS Layer 2 VPN called vpn-2 between CE-5 and
CE-6 using VLAN 200. Make sure the VPN uses the VPN RFC
4448 encapsulation and uses BGP as the VPN signalling
protocol. The maximum number of MAC addresses learned by
the VPLS domain should be limited to 500 on each PE-CE
link. Ensure that broadcast and multicast traffic will be
policed to 50 Mbps for all sites before entering the MPLS
domain.

TASK INTERPRETATION
To complete this task, you must configure the CE-facing interface with the correct
properties. Because the VLAN requirement is outside the normal VPLS VLAN range,
you must configure the encapsulation to be extended-vlan-vpls. Ensure that
you configure your IBGP peering to accept and send the VPLS NLRIs.
Next, you must configure the routing instance for vpn-2 and include the proper
interface. Define a Type 1 route distinguisher using the local loopback address to
uniquely identify source of the advertisements. Define a Type 1 VPN route target
using your local AS number. You must add the “L” at the end of the AS number to
indicate that you are using a 4-byte AS. After defining the standard properties,
configure the VPLS protocol information.
For the VPLS protocol, you must define a site name, site ranges, and local site
identifier. Because you do not have a tunnel services PIC, you must configure the
no-tunnel-services option.
The next requirement is that no more than 500 MAC addresses can be learned on
any CE-PE interface. You must specify the interface-mac-limit option for
VPLS.
Finally, the last requirement is that you police all VPLS broadcast and multicast
traffic entering your MPLS network. You must configure a firewall policer and filter.
Then this filter must be applied in your VPLS instance.
TASK COMPLETION
• R2:
lab@R2> configure
[edit]
lab@R2# set interfaces ge-0/0/3 vlan-tagging
[edit]
lab@R2# set interfaces ge-0/0/3 encapsulation extended-vlan-vpls
[edit]
lab@R2# set interfaces ge-0/0/3 unit 200 vlan-id 200 family vpls
[edit]
lab@R2# edit protocols bgp group internal


lab@R2# set family l2vpn signaling


lab@R2# set instance-type vpls

lab@R2# set interface ge-0/0/3.200


lab@R2# set vrf-target target:3895077211L:200

lab@R2# set protocols vpls site-range 10

lab@R2# set protocols vpls no-tunnel-services

lab@R2# edit protocols vpls
[edit routing-instances vpn-2 protocols vpls]

lab@R2# set site ce-5 site-identifier 5

lab@R2# set interface-mac-limit 500

[edit firewall]
lab@R2# set policer policer-1 if-exceeding bandwidth-limit 50m
[edit firewall]
lab@R2# set policer policer-1 if-exceeding burst-size-limit 1m
[edit firewall]
lab@R2# set policer policer-1 then discard
[edit firewall]
lab@R2# edit family vpls filter police-vpls
[edit firewall family vpls filter police-vpls]

lab@R2# set term 1 then policer policer-1

lab@R2# top edit routing-instances vpn-2 forwarding-options
[edit routing-instances vpn-2 forwarding-options]

lab@R2# set family vpls flood input police-vpls

commit complete
lab@R2>

• R5:
lab@R5> configure
[edit]
lab@R5# set interfaces ge-0/0/5 vlan-tagging
[edit]
lab@R5# set interfaces ge-0/0/5 encapsulation extended-vlan-vpls
[edit]
lab@R5# set interfaces ge-0/0/5 unit 200 vlan-id 200 family vpls
[edit]

lab@R5# set family l2vpn signaling


lab@R5# set instance-type vpls

lab@R5# set interface ge-0/0/5.200


lab@R5# set vrf-target target:3895077211L:200

lab@R5# edit protocols vpls

lab@R5# set site-range 10

lab@R5# set no-tunnel-services

lab@R5# set site ce-6 site-identifier 6

lab@R5# set interface-mac-limit 500


[edit firewall]
lab@R5# set policer policer-1 if-exceeding bandwidth-limit 50m
[edit firewall]
lab@R5# set policer policer-1 if-exceeding burst-size-limit 1m
[edit firewall]
lab@R5# set policer policer-1 then discard
[edit firewall]
lab@R5# edit family vpls filter police-vpls

lab@R5# set term 1 then policer policer-1

lab@R5# top edit routing-instances vpn-2 forwarding-options

lab@R5# set family vpls flood input police-vpls

commit complete
lab@R5>
TASK VERIFICATION
Begin your verification on R2 by reviewing the VPLS connections. After verifying that
your VPLS session is up and functioning, move to the VR-device and use the ping
utility to ping through your newly created VPLS connection.
• R2:
lab@R2> show vpls connections
Layer-2 VPN connections:
Legend for connection status (St)

EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS
EM -- encapsulation mismatch WE -- interface and instance encaps not same
VC-Dn -- Virtual circuit down NP -- interface hardware not present
CM -- control-word mismatch -> -- only outbound connection is up
CN -- circuit not provisioned <- -- only inbound connection is up
OR -- out of range Up -- operational
OL -- no outgoing label Dn -- down
LD -- local site signaled down CF -- call admission control failure
RD -- remote site signaled down SC -- local and remote site ID collision
LN -- local site not designated LM -- local site ID not minimum designated
RN -- remote site not designated RM -- remote site ID not minimum designated
XX -- unknown connection status IL -- no incoming label
MM -- MTU mismatch MI -- Mesh-Group ID not available
BK -- Backup connection ST -- Standby connection
PF -- Profile parse failure PB -- Profile busy
RS -- remote site standby SN -- Static Neighbor

Legend for interface status

Up -- operational
Dn -- down
Instance: vpn-2
Local site: ce-5 (5)
connection-site Type St Time last up # Up trans
6 rmt Up Jul 27 02:30:21 2011 1
Remote PE: 172.27.255.5, Negotiated control-word: No
Incoming label: 262150, Outgoing label: 262157
Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS
Description: Intf - vpls vpn-2 local site 5 remote site 6
• VR-device:
PING 51.100.0.2 (51.100.0.2): 56 data bytes

TASK 6
You must extend vpn-3 connecting CE-7 to CE-8 using a
inter-provider solution with ISP-A. You must not configure
a routing instance on R3. The address of the remote PE will
be learned from ISP-A. The Remote PE is using the route
target value of target:60001:101. Use the information in
the lab diagram for this lab to complete this task.
TASK INTERPRETATION
To complete this task, you must configure an inter-provider VPN using Option C
because you cannot use R3 as a PE device. The R3 can be only an ASBR and you
must configure an external BGP peering to ISP-A’s ASBR. Your R1 router will be the
PE, using multihop EBGP peering to establish the MP-BGP neighborship with ISP-A.
Because you must learn the remote PEs address through BGP, start by configuring
R3’s EBGP peering to ISP-A. You must create a policy to advertise the loopback
address for R1 to ISP-A. You must include both the inet.0 route and the inet.3
route in your policy. You must enable family inet labeled-unicast rib
inet.3 on all BGP peerings between R1 and ISP-A, to maintain the label and
advertise the inet.3 route as well as unlabeled routes. Remember that you also need
regular inet unicast routes. To exchange inet.3 routes with ISP-A, you must enable
family mpls on your interface that connects R3 to ISP-A.

Begin your configuration of R1 by creating your routing instance and configuring the
parameters for the VPN. After configuring the VPN, create your multi-hop EBGP
peering to the ISP-A router. The easiest way to determine what the neighbor address
will be is to review your inet.0 routing table for an entry in the ISP-A’s network.
Once you have this address, configure the required properties for your multihop
EBGP session. Because this session will be carrying the VPN routes, make sure that
you enable the proper NLRIs.
TASK COMPLETION
• R3:
lab@R3> configure
[edit]
lab@R3# set interfaces ge-0/0/4 unit 0 family mpls
[edit]


lab@R3# set family inet labeled-unicast rib inet.3

lab@R3# top edit protocols bgp group external
[edit protocols bgp group external]





lab@R3# top edit policy-options policy-statement export-loopback
[edit policy-options policy-statement export-loopback]


lab@R3# set term 1 from route-filter 172.27.255.1 exact


lab@R3# set term 2 from rib inet.3






lab@R3# set group external export export-loopback

commit complete
lab@R3>
• R1:
lab@R1> configure
[edit]





lab@R1# edit protocols bgp
[edit routing-instances vpn-3 protocols bgp]

lab@R1# set group external type external

lab@R1# set group external neighbor 172.27.0.30

lab@R1# set group external peer-as 50001



lab@R1# up

lab@R1# edit group isp-a
[edit protocols bgp group isp-a]





lab@R1# set family inet-vpn unicast



commit complete
lab@R1>
TASK VERIFICATION
Begin your verification on R3 by checking that the EBGP session is established to
ISP-A. Next, make sure that you have the remote PE’s loopback address in your
inet.3 routing table on R3.
After verifying R3, move to R1 and verify that your multi-hop EBGP peering is
established to the remote PE. You can also use the same output to verify that your
PE to CE BGP peering is established and working. Next, verify that you have the
loopback address in your inet.3 routing table. The next table you want to verify is the
VRF routing table. Finally, move to the VR-device and verify reachability by pinging
85.100.255.1 from the CE-7 routing instance.

• R3:
inet.0 2 2 0 0 0 0
inet.3 1 1 0 0 0 0
172.27.0.58 60001 1720 1731 0 0 13:07:22
Establ
inet.0: 1/1/1/0
inet.3: 1/1/1/0
172.27.255.1 3895077211 1644 1658 0 0 12:33:41
Establ
inet.0: 1/1/1/0
inet.3: 0/0/0/0
172.27.255.2 3895077211 1654 1655 0 0 12:33:37
Establ
inet.0: 0/0/0/0
172.27.255.4 3895077211 1656 1654 0 0 12:33:33
Establ
inet.0: 0/0/0/0
172.27.255.5 3895077211 1651 1654 0 0 12:33:29
Establ
inet.0: 0/0/0/0
lab@R3> show route table inet.3

95.100.255.2/32 *[BGP/170] 13:07:35, MED 1, localpref 100

AS path: 60001 I
> to 172.27.0.58 via ge-0/0/4.0, Push 299840
172.27.255.1/32 *[RSVP/7/1] 21:37:55, metric 1
> to 172.27.0.14 via ge-0/0/1.0, label-switched-path r3-to-r1
172.27.255.4/32 *[RSVP/7/1] 21:37:21, metric 1
172.27.255.5/32 *[RSVP/7/1] 21:37:49, metric 1
• R1:
inet.0 1 1 0 0 0 0
bgp.l3vpn.0 42 42 0 0 0 0
inet.3 1 1 0 0 0 0
95.100.255.2 60001 1681 1691 0 0 12:50:22
Establ
inet.0: 0/0/0/0
bgp.l3vpn.0: 6/6/6/0

vpn-3.inet.0: 6/6/6/0
172.27.0.30 50001 1704 1706 0 0 13:01:17
Establ
vpn-3.inet.0: 5/5/5/0
172.27.0.34 65100 2848 3431 0 0 21:40:49
Establ
vpn-1.inet.0: 6/7/7/0
172.27.255.2 3895077211 1689 1676 0 0 12:48:14
Establ
inet.0: 0/0/0/0
172.27.255.3 3895077211 1665 1650 0 1 12:36:28
Establ
inet.0: 1/1/1/0
inet.3: 1/1/1/0
172.27.255.4 3895077211 1698 1687 0 0 12:50:31
Establ
inet.0: 0/0/0/0
bgp.l3vpn.0: 9/9/9/0
vpn-1.inet.0: 9/9/9/0
172.27.255.5 3895077211 1695 1686 0 0 12:50:27
Establ
inet.0: 0/0/0/0
bgp.l3vpn.0: 16/16/16/0
vpn-1.inet.0: 15/16/16/0
lab@R1> show route table inet.3


AS path: 60001 I
172.27.255.2/32 *[LDP/9] 19:38:06, metric 1
> to 172.27.0.2 via ge-0/0/3.0
172.27.255.3/32 *[RSVP/7/1] 21:40:44, metric 1
172.27.255.4/32 *[RSVP/7/1] 21:40:20, metric 2
[LDP/9] 19:38:06, metric 1
> to 172.27.0.2 via ge-0/0/3.0, Push 299776
172.27.255.5/32 *[RSVP/7/1] 21:40:22, metric 2
to 172.27.0.9 via ae0.0, label-switched-path r1-to-r5-one
> to 172.27.0.13 via ge-0/0/6.0, label-switched-path
r1-to-r5-two
lab@R1> show route table vpn-3.inet.0

85.100.0.0/24 *[BGP/170] 13:03:05, localpref 100

AS path: 50001 I
> to 172.27.0.30 via ge-0/0/1.0

85.100.1.0/24 *[BGP/170] 13:03:05, localpref 100
AS path: 50001 I
> to 172.27.0.30 via ge-0/0/1.0
85.100.2.0/24 *[BGP/170] 13:03:05, localpref 100
AS path: 50001 I
> to 172.27.0.30 via ge-0/0/1.0
85.100.3.0/24 *[BGP/170] 13:03:05, localpref 100
AS path: 50001 I
> to 172.27.0.30 via ge-0/0/1.0
85.100.4.0/24 *[BGP/170] 13:03:05, localpref 100
AS path: 50001 I
> to 172.27.0.30 via ge-0/0/1.0
AS path: 60001 I
AS path: 60001 I
AS path: 60001 I
AS path: 60001 I
AS path: 60001 I
AS path: 60001 I
172.27.0.28/30 *[Direct/0] 13:03:09
> via ge-0/0/1.0
172.27.0.29/32 *[Local/0] 13:03:09
• VR-device:
PING 85.100.255.1 (85.100.255.1): 56 data bytes
--- 85.100.255.1 ping statistics ---

Question: Do your pings complete?
Answer: Yes, you should have reachability to the

remote CE-8 network.



Appendix A: Lab Diagrams

A–2 • Lab Diagrams www.juniper.net

www.juniper.net Lab Diagrams • A–3






JNCIE SP 10.b - LGD

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

JNCIE SP 10.b - LGD

Hochgeladen von

Copyright:

Verfügbare Formate

JNCIE Service Provider Bootcamp

Detailed Lab Guide

Worldwide Education Services

1194 North Mathilda Avenue

Course Number: EDU-JUN-JNCIE-SP

Lab 2: IS-IS Implementation (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Lab 3: OSPF Implementation (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Lab 4: IS-IS Troubleshooting (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Lab 5: OSPF Troubleshooting (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Lab 6: BGP Implementation (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

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

Lab 8: Multicast Implementation and Troubleshooting (Detailed) . . . . . . . . . . . . . 8-1

Lab 9: Class of Service Implementation and Troubleshooting (Detailed) . . . . . . . . 9-1

Lab 10: MPLS Implementation and Troubleshooting (Detailed) . . . . . . . . . . . . . . . 10-1

Lab 11: MPLS VPNs Implementation and Troubleshooting (Detailed) . . . . . . . . . . 11-1

Appendix A: Lab Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-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

www.juniper.net Document Conventions • vii

Education Services Offerings

viii • Additional Information www.juniper.net

www.juniper.net Implementing Device Infrastructure (Detailed) • Lab 1–1

Lab 1–2 • Implementing Device Infrastructure (Detailed) www.juniper.net

www.juniper.net Implementing Device Infrastructure (Detailed) • Lab 1–3

Part 1: Implementing Device Infrastructure

Question: On which routers is it necessary to

Answer: The Lab 1 diagram shows that it is

Lab 1–4 • Implementing Device Infrastructure (Detailed) www.juniper.net

Answer: First, set the Ethernet aggregated device

--- JUNOS 10.3-20110523_pvt_predator_a.0 built 2011-05-23 04:17:01 UTC

www.juniper.net Implementing Device Infrastructure (Detailed) • Lab 1–5

[edit interfaces ae1]

[edit interfaces ae1]

[edit interfaces ae1]

--- JUNOS 10.3-20110523_pvt_predator_a.0 built 2011-05-23 04:17:01 UTC

[edit interfaces ae0]

[edit interfaces ae0]

Lab 1–6 • Implementing Device Infrastructure (Detailed) www.juniper.net

[edit interfaces ae0]

--- JUNOS 10.3-20110523_pvt_predator_a.0 built 2011-05-23 04:17:01 UTC

[edit interfaces ae0]

[edit interfaces ae0]

www.juniper.net Implementing Device Infrastructure (Detailed) • Lab 1–7

[edit interfaces ae1]

[edit interfaces ae1]

[edit interfaces ae2]

[edit interfaces ae2]

Lab 1–8 • Implementing Device Infrastructure (Detailed) www.juniper.net

--- JUNOS 10.3-20110523_pvt_predator_a.0 built 2011-05-23 04:17:01 UTC

www.juniper.net Implementing Device Infrastructure (Detailed) • Lab 1–9

[edit interfaces ae2]

[edit interfaces ae2]

[edit interfaces ae2]

Lab 1–10 • Implementing Device Infrastructure (Detailed) www.juniper.net