Jir Lab Guide PDF

Junos Intermediate Routing
12.a
Detailed Lab Guide
Worldwide Education Services
1194 North Mathilda Avenue

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

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.
Junos Intermediate Routing Detailed Lab Guide, Revision 12.a
Copyright © 2012, Juniper Networks, Inc.
All rights reserved. Printed in USA.
Revision History:
Revision 10.a—May 2010
Revision 10.b—December 2010
Revision 11.a—June 2011
Revision 12.a—June 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 12.1R1.9. Juniper Networks assumes no
responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental
or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has
no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an
agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and
agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper
Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should
consult the software license for further details.
Contents
Lab 1: Protocol-Independent Routing (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Part 1: Configuring and Monitoring Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Part 2: Configuring and Monitoring Static and Aggregate Routes . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Part 3: Working with Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-16
Lab 2: Load Balancing and Filter-Based Forwarding (Detailed) . . . . . . . . . . . . . . . . . . . 2-1

Part 1: Configuring and Monitoring Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Part 2: Configuring and Monitoring Filter-Based Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Lab 3: Open Shortest Path First (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Part 1: Configuring and Monitoring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Part 2: Performing Basic OSPF Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15
Lab 4: Border Gateway Protocol (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Part 1: Configuring and Monitoring IBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Part 2: Configuring and Monitoring EBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Part 3: Implementing a next-hop self Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-21
Lab 5: IP Tunneling (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Part 1: Configuring and Monitoring a GRE Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Part 2: Configuring the GRE Interface to Participate in OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
Lab 6: High Availability (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Part 1: Configuring and Monitoring Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Part 2: Configuring and Monitoring BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-11
Part 3: Configuring and Monitoring VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-17
Lab 7: IPv6 (Optional) (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Part 1: Configuring and Monitoring Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Part 2: Configuring and Monitoring Static Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-10
Part 3: Configuring and Monitoring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-13
Part 4: Tunneling IPv6 over IPv4 Using GRE Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-16
Lab 8: IS-IS (Optional) (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Part 1: Configuring and Monitoring IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Part 2: Performing Basic IS-IS Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
Appendix A: Lab Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Contents • iii
iv • Contents
Course Overview
This two-day course provides students with intermediate routing knowledge and configuration
examples. The course includes an overview of protocol-independent routing features, load
balancing and filter-based forwarding, OSPF, BGP, IP tunneling, and high availability (HA) features.
Through demonstrations and hands-on labs, students will gain experience in configuring and
monitoring the Junos OS and monitoring device operations.This course uses Juniper Networks
SRX Series Services Gateways for the hands-on component, but the lab environment does not
preclude the course from being applicable to other Juniper hardware platforms running the Junos
OS. This course is based on Junos OS Release 12.1R1.9.
Objectives
After successfully completing this course, you should be able to:
• Describe typical uses of static, aggregate, and generated routes.
• Configure and monitor static, aggregate, and generated routes.
• Explain the purpose of Martian routes and add new entries to the default list.
• Describe typical uses of routing instances.
• Configure and share routes between routing instances.
• Describe load-balancing concepts and operations.
• Implement and monitor Layer 3 load balancing.
• Illustrate benefits of filter-based forwarding.
• Configure and monitor filter-based forwarding.
• Explain the operations of OSPF.
• Describe the role of the designated router.
• List and describe OSPF area types.
• Configure, monitor, and troubleshoot OSPF.
• Describe BGP and its basic operations.
• Name and describe common BGP attributes.
• List the steps in the BGP route selection algorithm.
• Describe BGP peering options and the default route advertisement rules.
• Configure and monitor BGP.
• Describe IP tunneling concepts and applications.
• Explain the basic operations of generic routing encapsulation (GRE) and IP over IP
(IP-IP) tunnels.
• Configure and monitor GRE and IP-IP tunnels.
• Describe various high availability features supported by the Junos OS.
• Configure and monitor some of the highlighted high availability features.
Intended Audience
This course benefits individuals responsible for configuring and monitoring devices running the
Junos OS.
Course Level
Junos Intermediate Routing is an intermediate-level course.
www.juniper.net Course Overview • v

Prerequisites
Students should have basic networking knowledge and an understanding of the Open Systems
Interconnection (OSI model) and the TCP/IP protocol suite. Students should also attend the
Introduction to the Junos Operating System (IJOS) and Junos Routing Essentials (JRE) courses prior
to attending this class.
vi • Course Overview www.juniper.net

Course Agenda
Day 1
Chapter 1: Course Introduction
Chapter 2: Protocol-Independent Routing
Lab 1: Protocol-Independent Routing
Chapter 3: Load Balancing and Filter-Based Forwarding
Lab 2: Load Balancing and Filter-Based Forwarding
Chapter 4: Open Shortest Path First
Lab 3: Open Shortest Path First
Day 2
Chapter 5: Border Gateway Protocol
Lab 4: Border Gateway Protocol
Chapter 6: IP Tunneling
Lab 5: IP Tunneling
Chapter 7: High Availability
Lab 6: High Availability
Appendix A: IPv6
Lab 7: IPv6 (Optional)
Appendix B: IS-IS
Lab 8: IS-IS (Optional)
Appendix C: RIP
www.juniper.net Course Agenda • vii

Document Conventions
CLI and GUI Text

Frequently throughout this course, we refer to text that appears in a command-line interface (CLI)
or a graphical user interface (GUI). To make the language of these documents easier to read, we
distinguish GUI and CLI text from chapter text according to the following table.
Style Description Usage Example
Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
Courier New Console text:

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

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

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

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

CLI Variable Text where variable value is policy my-peers
already assigned.
GUI Variable
Click my-peers in the dialog.
CLI Undefined Text where the variable’s value Type set policy policy-name.
is the user’s discretion and text
ping 10.0.x.y
where the variable’s value as
GUI Undefined shown in the lab guide might Select File > Save, and type
differ from the value the user filename in the Filename field.
must input.
viii • Document Conventions www.juniper.net

Additional Information
Education Services Offerings

You can obtain information on the latest Education Services offerings, course dates, and class
locations from the World Wide Web by pointing your Web browser to:
http://www.juniper.net/training/education/.
About This Publication
The Junos Intermediate Routing Detailed Lab Guide was developed and tested using software
Release 12.1R1.9. Previous and later versions of software might behave differently so you should
always consult the documentation and release notes for the version of code you are running before
reporting errors.
This document is written and maintained by the Juniper Networks Education Services development
team. Please send questions and suggestions for improvement to training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
• Go to http://www.juniper.net/techpubs/.
• Locate the specific software or hardware release and title you need, and choose the
format in which you want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or
account representative.
Juniper Networks Support
For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or
at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).
www.juniper.net Additional Information • ix

x • Additional Information www.juniper.net
Lab 1
Protocol-Independent Routing (Detailed)
Overview
This lab demonstrates configuration and monitoring of protocol-independent features on
devices running the Junos operating system. In this lab, you use the command-line
interface (CLI) to configure and monitor interfaces, static and aggregate routes, and
routing instances.
The lab is available in two formats: a high-level format designed to make you think through
each step and a detailed format that offers step-by-step instructions complete with
sample output from most commands.
By completing this lab, you will perform the following tasks:
• Configure and verify proper operation of network interfaces.
• Configure and monitor static and aggregate routes.
• Configure routing instances and share routes between them using routing
table groups.
www.juniper.net Protocol-Independent Routing (Detailed) • Lab 1–1

12.a.12.1R1.9
Part 1: Configuring and Monitoring Interfaces
In this lab part, you configure network interfaces on your assigned device. You then
verify that the interfaces are operational and that the system adds the
corresponding routing table entries for the configured interfaces.
Note
The instructor will tell you the nature of your
access and will provide you with the
necessary details to access your assigned
device.
Step 1.1
Ensure that you know to which student device you have been assigned. Check with
your instructor if you are not certain. Consult the management network diagram to
determine the management address of your student device.
Question: What is the management address

assigned to your station?
Answer: The answer varies; in the example used

throughout this lab, the user belongs to the
srxB-1 station, which uses an IP address of
10.210.14.133. Your answer will depend on the
rack of equipment your class is using.
Step 1.2
Access the CLI at your station 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 team’s station. The following example uses a simple Telnet
access to srxB-1 with the Secure CRT program as a basis:
Lab 1–2 • Protocol-Independent Routing (Detailed) www.juniper.net

Step 1.3
Log in to the student device with the username lab using a password of lab123.
Note that both the name and password are case-sensitive. Issue the configure
command to enter configuration mode and load the reset configuration file using
the load override /var/home/lab/jir/lab1-start.config
command. After the configuration has been loaded, commit the changes using the
commit command.
srxB-1 (ttyp0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

lab@srxB-1> configure
Entering configuration mode
[edit]
lab@srxB-1# load override jir/lab1-start.config
load complete
[edit]
lab@srxB-1# commit
commit complete
Step 1.4
Navigate to the [edit interfaces] hierarchy level.Refer to the network
diagram and configure the interfaces for your assigned device. Use the VLAN-ID as
the logical unit value for the tagged interface. Use logical unit 0 for all other
interfaces. Remember to configure the loopback interface!
[edit]
lab@srxB-1# edit interfaces
[edit interfaces]
lab@srxB-1# set lo0 unit 0 family inet address address/32
[edit interfaces]
lab@srxB-1# set ge-0/0/3 unit 0 family inet address address/30
[edit interfaces]
[edit interfaces]
[edit interfaces]
lab@srxB-1# set ge-0/0/4 vlan-tagging
[edit interfaces]
lab@srxB-1# set ge-0/0/4 unit vlan-id vlan-id vlan-id
[edit interfaces]
lab@srxB-1# set ge-0/0/4 unit vlan-id family inet address address/24

[edit interfaces]
lab@srxB-1#
Step 1.5
Display the interface configuration and ensure that it matches the details outlined
on the network diagram for this lab. When you are comfortable with the interface
configuration, issue the commit-and-quit command to activate the
configuration and return to operational mode.
[edit interfaces]
lab@srxB-1# show
ge-0/0/0 {
description "MGMT Interface - DO NOT DELETE";
unit 0 {
family inet {
address 10.210.35.133/26;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 172.20.77.1/30;
}
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 172.20.66.1/30;
}
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 172.18.1.2/30;
}
}
}
ge-0/0/4 {
vlan-tagging;
unit 113 {
vlan-id 113;
family inet {
address 172.20.113.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/32;
}

}
}
[edit interfaces]
lab@srxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxB-1>
Step 1.6
Issue the show interfaces terse command to verify the current state of the
recently configured interfaces.
lab@srxB-1> show interfaces terse
Interface Admin Link Proto Local Remote
ge-0/0/0 up up
ge-0/0/0.0 up up inet 10.210.35.133/26
gr-0/0/0 up up
ip-0/0/0 up up
lsq-0/0/0 up up
lt-0/0/0 up up
mt-0/0/0 up up
sp-0/0/0 up up
sp-0/0/0.0 up up inet
sp-0/0/0.16383 up up inet 10.0.0.1 --> 10.0.0.16
10.0.0.6 --> 0/0
128.0.0.1 --> 128.0.1.16
128.0.0.6 --> 0/0
ge-0/0/1 up up
ge-0/0/1.0 up up inet 172.20.77.1/30
ge-0/0/2 up up
ge-0/0/2.0 up up inet 172.20.66.1/30
ge-0/0/3 up up
ge-0/0/3.0 up up inet 172.18.1.2/30
ge-0/0/4 up up
ge-0/0/4.113 up up inet 172.20.113.1/24
ge-0/0/4.32767 up up
ge-0/0/5 up down
ge-0/0/6 up up
ge-0/0/7 up up
ge-0/0/8 up up
ge-0/0/9 up up
ge-0/0/10 up up
ge-0/0/11 up up
ge-0/0/12 up up
ge-0/0/13 up down
ge-0/0/14 up up
ge-0/0/15 up up
fxp2 up up
fxp2.0 up up tnp 0x1
gre up up
ipip up up
irb up up
lo0 up up

lo0.0 up up inet 192.168.1.1 --> 0/0
lo0.16384 up up inet 127.0.0.1 --> 0/0
lo0.16385 up up inet 10.0.0.1 --> 0/0
10.0.0.16 --> 0/0
128.0.0.1 --> 0/0
128.0.0.4 --> 0/0
128.0.1.16 --> 0/0
lo0.32768 up up
lsi up up
mtun up up
pimd up up
pime up up
pp0 up up
ppd0 up up
ppe0 up up
st0 up up
tap up up
vlan up up
Question: What are the Admin and Link states for

the recently configured interfaces?
Answer: The configured interfaces should all show

Admin and Link states of up, as shown in the
previous output. If the configured interfaces are in
the down state, contact your instructor.
Step 1.7
Issue the show route command to view the current route entries.
lab@srxB-1> show route
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
10.210.35.128/26 *[Direct/0] 00:29:18

> via ge-0/0/0.0
10.210.35.133/32 *[Local/0] 00:29:28
Local via ge-0/0/0.0
172.18.1.0/30 *[Direct/0] 00:01:52
> via ge-0/0/3.0
172.18.1.2/32 *[Local/0] 00:01:52
172.20.66.0/30 *[Direct/0] 00:01:52
> via ge-0/0/2.0
172.20.66.1/32 *[Local/0] 00:01:52
172.20.77.0/30 *[Direct/0] 00:01:52
> via ge-0/0/1.0
172.20.77.1/32 *[Local/0] 00:01:52

172.20.113.0/24 *[Direct/0] 00:01:52
> via ge-0/0/4.113
172.20.113.1/32 *[Local/0] 00:01:52
192.168.1.1/32 *[Direct/0] 00:01:52
> via lo0.0
Question: Does the routing table display an entry for

all local interface addresses and directly connected
networks?
Answer: The answer should be yes. If necessary, you

can refer back to the network diagram and compare
it with the displayed route entries.
Question: What are the route preferences for the

Local and Direct route entries?
Answer: The Local and Direct route entries

should both show a route preference of 0, as shown
in the sample output.
Question: Are any routes currently hidden?
Answer: You can possibly see hidden routes

depending on the environment and how the delivery
rack was prepared. In this example, no hidden
routes are present as indicated in the summary line
towards the top of the sample output.
Step 1.8
Use the ping utility to verify reachability to the neighboring devices connected to your
device. If necessary, check with the remote student team and your instructor to
ensure that their devices have the required configuration for the interfaces. The
following sample capture shows ping tests from srxB-1 to the Internet gateway,
srxD-2, and vr-device, which are all directly connected:
Note
Use Ctrl + c to stop a continuous ping
operation.

lab@srxB-1> ping internet-gateway-address rapid count 25
PING 172.18.1.1 (172.18.1.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
--- 172.18.1.1 ping statistics ---
25 packets transmitted, 25 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.560/5.276/26.080/4.364 ms
lab@srxB-1> ping remote-ge-0/0/2-address rapid count 25

PING 172.20.66.2 (172.20.66.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!

PING 172.20.77.2 (172.20.77.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
lab@srxB-1> ping local-vr-device rapid count 25

PING 172.20.113.10 (172.20.113.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
--- 172.20.113.10 ping statistics ---
Question: Are the ping tests successful?
Answer: Yes, the ping tests should be successful at

this time. If your tests are not successful, check
with the remote student team or your instructor.
STOP Before continuing, ensure that the remote team in your pod is ready to
proceed.
Part 2: Configuring and Monitoring Static and Aggregate Routes
In this lab part, you configure and monitor static and aggregate routes.
Step 2.1
Enter configuration mode and load the lab1-part2-start.config file from
the/var/home/lab/jir/ directory. Commit your configuration when complete.

[edit]
lab@srxB-1# load override jir/lab1-part2-start.config
load complete
[edit]
lab@srxB-1# commit
commit complete
[edit]
lab@srxB-1#
Step 2.2
Refer to the network diagram for this lab and answer the following question.
Question: Based on the network diagram, which IP

address does your device use as a next hop to
reach the Internet host?
Answer: The answer depends on your assigned

device. For all srxX-1 devices, the next-hop
IP address is 172.18.1.1. For all srxX-2 devices,
the next-hop IP address is 172.18.2.1.
Step 2.3
Enter configuration mode and define a default static route. Use the IP address
identified in the last step as the next hop for the default static route.
[edit]
lab@srxB-1# edit routing-options
[edit routing-options]
lab@srxB-1# set static route 0/0 next-hop address
lab@srxB-1#
Step 2.4
Activate the newly added static route and issue the run show route
172.31.15.1 command.
lab@srxB-1# commit
commit complete
lab@srxB-1# run show route 172.31.15.1


0.0.0.0/0 *[Static/5] 00:00:28

> to 172.18.1.1 via ge-0/0/3.0
Question: Does the IP address associated with the

Internet host show a valid route entry?
Answer: Yes, at this point the default static route

should be active. All destinations that do not have a
more specific route entry use the default route.
Question: What is the route preference of the

default static route?
Answer: The default static route uses the route

preference value of 5, which is the default route
preference for static routes.
Step 2.5
Issue the run ping 172.31.15.1 command to ping the Internet host.
Note
The Internet host should contain the
required routes to send traffic back to the
student devices.
lab@srxB-1# run ping 172.31.15.1
PING 172.31.15.1 (172.31.15.1): 56 data bytes
64 bytes from 172.31.15.1: icmp_seq=0 ttl=64 time=1.321 ms
^C

Question: Does the ping operation succeed?
Answer: Yes, the ping operation should succeed. If

the ping operation does not succeed, check your
configuration and, if necessary, contact your
instructor.
Step 2.6
Use the preference statement to ensure that the default static route maintains
the default route preference of 5, and that all future static routes use a route
preference of 20.
lab@srxB-1# set static route 0/0 preference 5
lab@srxB-1# set static defaults preference 20
Note
Refer to the network diagram, as
necessary, for the next lab step.
Step 2.7
Add a static route to the loopback address of the directly attached virtual router.
lab@srxB-1# set static route local-vr-loopback/32 next-hop local-vr-address
Step 2.8
Activate the configuration and issue the run show route protocol static
command to view all static routes.
lab@srxB-1# commit
commit complete
lab@srxB-1# run show route protocol static

0.0.0.0/0 *[Static/5] 00:54:20

> to 172.18.1.1 via ge-0/0/3.0
192.168.1.2/32 *[Static/20] 00:00:52
> to 172.20.113.10 via ge-0/0/4.113

Question: Are both static routes active? What is the
route preference of each static route?
Answer: Yes, both static routes should now be

active. The default static route should still show a
route preference of 5, and the static route for the
loopback address of the directly attached virtual
router should show a route preference of 20. If both
static routes are not active, or if you see different
route preference values for these two static routes,
check your configuration.
Step 2.9
Ping the loopback address of the directly attached virtual router.
Note
The virtual routers have a preconfigured
default static route using their directly
connected student devices as the next hop.
lab@srxB-1# run ping local-vr-loopback
PING 192.168.1.2 (192.168.1.2): 56 data bytes
^C
Question: Does the ping operation succeed?
Answer: Yes, the ping operation should succeed. If

the ping operation does not succeed, check your
configuration and, if necessary, contact your
instructor.
Step 2.10
Add an aggregate route for the 10.1.0.0/16 prefix by issuing the set aggregate
route 10.1.0.0/16 command.

lab@srxB-1# set aggregate route 10.1.0.0/16
Step 2.11
Activate the newly added aggregate route and issue the run show route
protocol aggregate command.
lab@srxB-1# commit
commit complete
lab@srxB-1# run show route protocol aggregate
Question: Is the newly added aggregate route

active? If not, why?
Answer: No, as shown in the output, the newly

added aggregate route is not present. You do,
however, see a new hidden route. The new
aggregate route is marked as hidden because no
contributing routes exist. You can display the hidden
route using the run show route hidden
detail command for verification purposes. The
following is a sample output for this command:
lab@srxB-1# run show route hidden detail

10.1.0.0/16 (1 entry, 0 announced)
Aggregate
Next hop type: Reject
Next-hop reference count: 1
State: <Hidden Int Ext>
Age: 1:27
Task: Aggregate
AS path: I
Flags: Depth: 0 Inactive
Step 2.12
Delete the 10.1.0.0/16 aggregate route and define a new aggregate route using the
172.20.64.0/18 prefix. Activate the configuration change and issue the run show
route protocol aggregate detail command.

lab@srxB-1# delete aggregate
lab@srxB-1# commit
commit complete
lab@srxB-1# run show route protocol aggregate detail

172.20.64.0/18 (1 entry, 1 announced)
*Aggregate Preference: 130
Next hop type: Reject
State: <Active Int Ext>
Age: 20
Task: Aggregate
Announcement bits (1): 0-KRT
AS path: I (LocalAgg)
Flags: Depth: 0 Active
AS path list:
AS path: I Refcount: 3
Contributing Routes (3):
172.20.66.0/30 proto Direct
172.20.77.0/30 proto Direct
172.20.117.0/24 proto Direct
Question: According to the route summary details

for the inet.0 routing table, does your device
currently have any hidden routes?
Answer: No, at this time you should not see any

hidden routes because the 10.1.0.0/16 aggregate
route was deleted. If you still see a hidden route,
check your configuration to ensure that it has only
the 172.20.64.0/18 aggregate route defined.
Question: Is the new aggregate route active? What

is the route preference of this aggregate route?
Answer: Yes, the new active aggregate route should

be active. This aggregate route should have an
assigned default route preference of 130.

Question: What are the contributing routes for the
172.20.64.0/18 aggregate route?
Answer: You should see a total of three contributing

routes—the two routes associated with connections
between the student devices (172.20.66.0/30 and
172.20.77.0/30) and the route associated with the
connection between your assigned device and the
directly connected virtual router (172.20.11v.0/24).
Question: Based on the next-hop type associated

with the 172.20.64.0/18 aggregate route, what
action will your device take if it receives a packet
destined for a prefix for which a more specific
routing table entry does not exist?
Answer: The next-hop type associated with the

172.20.64.0/18 aggregate route is reject. If your
device receives a packet that matches the defined
aggregate route and no other matching entry that is
more specific exists, then your device will respond
to the source device with a No route to host
message. This behavior is illustrated in the following
output:
lab@srxB-1# run show route 172.20.64.1

172.20.64.0/18 *[Aggregate/130] 00:02:22

Reject
lab@srxB-1# run ping 172.20.64.1
PING 172.20.64.1 (172.20.64.1): 56 data bytes
ping: sendto: No route to host
^C

proceed.
Part 3: Working with Routing Instances
In this lab part, you configure a routing instance and use routing table groups to
share routes between the master routing table and user-defined routing tables.
Step 3.1
Navigate to the top of the hierarchy and load the lab1-part3-start.config
file from the/var/home/lab/jir/ directory. Commit your configuration when
complete.
lab@srxB-1# top
[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
[edit]
lab@srxB-1#
Step 3.2
Navigate to the [edit routing-instances] hierarchy level. Define a routing
instance named instance-a that uses the virtual-router instance type and
includes the ge-0/0/1.0 and ge-0/0/2.0 interfaces.
[edit]
lab@srxB-1# edit routing-instances
[edit routing-instances]
lab@srxB-1# set instance-a instance-type virtual-router
lab@srxB-1# set instance-a interface ge-0/0/1.0
lab@srxB-1# set instance-a interface ge-0/0/2.0
lab@srxB-1#

Step 3.3
Define two static routes: the first static route is for the loopback addresses assigned
to the remote team’s device and the remote virtual router; the second static route is
for the remote subnet that connects the remote team’s device with the remote
virtual router. Both static routes should include two next-hop addresses of the
remote team’s ge-0/0/2 and ge-0/0/1 interfaces. Refer to the network diagram for
this lab as necessary.
lab@srxB-1# set instance-a routing-options static route remote-loopback/30
next-hop remote-ge-0/0/2-address
lab@srxB-1# set instance-a routing-options static route remote-loopback/30
lab@srxB-1# set instance-a routing-options static route remote-vr-address/24
lab@srxB-1# set instance-a routing-options static route remote-vr-address/24
lab@srxB-1# show
instance-a {
instance-type virtual-router;
interface ge-0/0/1.0;
routing-options {
static {
route 192.168.2.0/30 next-hop [ 172.20.66.2 172.20.77.2 ];
route 172.20.114.0/24 next-hop [ 172.20.66.2 172.20.77.2 ];
}
}
}
Step 3.4
Activate the changes and display the routing tables using the run show route
command.
lab@srxB-1# commit
commit complete
lab@srxB-1# run show route

0.0.0.0/0 *[Static/5] 00:28:32

> to 172.18.1.1 via ge-0/0/3.0
10.210.35.128/26 *[Direct/0] 01:12:29
> via ge-0/0/0.0
10.210.35.133/32 *[Local/0] 01:12:39
172.18.1.0/30 *[Direct/0] 00:45:03
> via ge-0/0/3.0
172.18.1.2/32 *[Local/0] 00:45:03
172.20.64.0/18 *[Aggregate/130] 00:16:25
Reject
172.20.113.0/24 *[Direct/0] 00:45:03
> via ge-0/0/4.113
172.20.113.1/32 *[Local/0] 00:45:03
192.168.1.1/32 *[Direct/0] 00:45:03
> via lo0.0
192.168.1.2/32 *[Static/20] 00:24:47
> to 172.20.113.10 via ge-0/0/4.113
instance-a.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

172.20.66.0/30 *[Direct/0] 00:00:22

> via ge-0/0/2.0
172.20.66.1/32 *[Local/0] 00:00:22
172.20.77.0/30 *[Direct/0] 00:00:22
> via ge-0/0/1.0
172.20.77.1/32 *[Local/0] 00:00:22
172.20.114.0/24 *[Static/5] 00:00:22
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
192.168.2.0/30 *[Static/5] 00:00:22
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
Question: Which routing tables does the output

display?
Answer: The output should display inet.0 and the

instance-a.inet.0 routing tables.

Question: Which routes are installed in the new
routing table?
Answer: The new routing table

(instance-a.inet.0) should show the Direct
and Local routes associated with the interfaces
assigned to the routing instance as well as the
recently defined static routes. If you do not see
similar routes in your device’s routing table, check
your configuration.
Step 3.5
Verify reachability to the remote student device using the run ping address
command, where address is the address assigned to the remote team’s ge-0/0/2
interface.
lab@srxB-1# run ping address
PING 172.20.66.2 (172.20.66.2): 56 data bytes
^C
Question: Did the ping operation succeed? If not,

why not?
Answer: The ping operation should not succeed

using the referenced command. Because the
destination prefix is installed only in the
instance-a.inet.0 routing table, you must
specify that routing instance as part of the
command. The required command syntax is shown
in the next step.
Step 3.6
Add the routing-instance instance-a option to the command referenced
in the previous step.
lab@srxB-1# run ping address routing-instance instance-a
PING 172.20.66.2 (172.20.66.2): 56 data bytes

^C
Question: Did the ping operation succeed?
Answer: As shown in the output, the ping operation

should now succeed with the proper routing
instance referenced.
Step 3.7
Attempt to ping the loopback address of the remote student device. Source the ping
operation from the instance-a routing instance.
lab@srxB-1# run ping remote-loopback-address routing-instance instance-a
PING 192.168.2.1 (192.168.2.1): 56 data bytes
36 bytes from 172.20.66.2: Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 229f 0 0000 40 01 a74b 172.20.66.1 192.168.2.1

4 5 00 0054 22a0 0 0000 40 01 a74a 172.20.66.1 192.168.2.1

4 5 00 0054 22a1 0 0000 40 01 a749 172.20.66.1 192.168.2.1
^C

Question: Did the ping operation succeed? What do
the results indicate?
Answer: As shown in the output, the ping operation

should not succeed. The results indicate that the
receiving device—in this case the remote student
device—does not have the required routing
information to forward the packets on to their
intended destination. Remember, at this point, you
have not shared routes between the default master
instance (inet.0) and the user-defined instance
(instance-a.inet.0). You remedy this lack of
shared routes in the following steps.
Step 3.8
Navigate to the [edit routing-options] hierarchy level. Issue the set
rib-groups inet.0-to-instance-a import-rib [inet.0
instance-a.inet.0] command to create a routing table group that imports
routes from inet.0 into instance-a.inet.0.
lab@srxB-1# top edit routing-options
lab@srxB-1# set rib-groups inet.0-to-instance-a import-rib [inet.0
instance-a.inet.0]
lab@srxB-1#
Step 3.9
Issue the set rib-groups instance-a-to-inet.0 import-rib
[instance-a.inet.0 inet.0] command to create a routing table group that
imports routes from instance-a.inet.0 into inet.0.
lab@srxB-1# set rib-groups instance-a-to-inet.0 import-rib [instance-a.inet.0
inet.0]
Step 3.10
Apply the inet.0-to-instance-a routing table group to import interface and
static routes from the inet.0 routing table to the instance-a.inet.0 routing
table. Activate the changes and display the instance-a.inet.0 routing table to
ensure that the routes were properly imported.
lab@srxB-1# set interface-routes rib-group inet inet.0-to-instance-a
lab@srxB-1# set static rib-group inet.0-to-instance-a

lab@srxB-1# commit
commit complete
lab@srxB-1# run show route table instance-a.inet.0
instance-a.inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)

0.0.0.0/0 *[Static/5] 00:02:17

> to 172.18.1.1 via ge-0/0/3.0
10.210.35.128/26 *[Direct/0] 00:02:17
> via ge-0/0/0.0
10.210.35.133/32 *[Local/0] 00:02:17
172.18.1.0/30 *[Direct/0] 00:02:17
> via ge-0/0/3.0
172.18.1.2/32 *[Local/0] 00:02:17
172.20.66.0/30 *[Direct/0] 00:13:12
> via ge-0/0/2.0
172.20.66.1/32 *[Local/0] 00:13:12
172.20.77.0/30 *[Direct/0] 00:13:12
> via ge-0/0/1.0
172.20.77.1/32 *[Local/0] 00:13:12
172.20.113.0/24 *[Direct/0] 00:02:17
> via ge-0/0/4.113
172.20.113.1/32 *[Local/0] 00:02:17
172.20.114.0/24 *[Static/5] 00:13:12
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
192.168.1.1/32 *[Direct/0] 00:02:17
> via lo0.0
192.168.1.2/32 *[Static/20] 00:02:17
> to 172.20.113.10 via ge-0/0/4.113
192.168.2.0/30 *[Static/5] 00:13:12
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
Question: Were the interface and static routes from

inet.0 imported into instance-a.inet.0?
Answer: As shown in the output, the interface and

static routes were imported into the
instance-a.inet.0 routing table.

Step 3.11
Navigate to the [edit routing-instance instance-a] hierarchy level.
Apply the instance-a-to-inet.0 routing table group to import interface and
static routes from the instance-a.inet.0 routing table to the inet.0 routing
table.
lab@srxB-1# top edit routing-instances instance-a
[edit routing-instances instance-a]

lab@srxB-1# set routing-options interface-routes rib-group instance-a-to-inet.0

lab@srxB-1# set routing-options static rib-group instance-a-to-inet.0

lab@srxB-1#
Step 3.12
Activate the configuration changes and return to operational mode. Next, display the
inet.0 routing table to ensure that the routes were properly imported from the
instance-a.inet.0 routing table.
commit complete
lab@srxB-1> show route table inet.0

0.0.0.0/0 *[Static/5] 00:04:49

> to 172.18.1.1 via ge-0/0/3.0
10.210.35.128/26 *[Direct/0] 01:27:51
> via ge-0/0/0.0
10.210.35.133/32 *[Local/0] 01:28:01
172.18.1.0/30 *[Direct/0] 01:00:25
> via ge-0/0/3.0
172.18.1.2/32 *[Local/0] 01:00:25
172.20.64.0/18 *[Aggregate/130] 00:31:47
Reject
172.20.66.0/30 *[Direct/0] 00:00:08
> via ge-0/0/2.0
172.20.66.1/32 *[Local/0] 00:00:08
172.20.77.0/30 *[Direct/0] 00:00:08
> via ge-0/0/1.0
172.20.77.1/32 *[Local/0] 00:00:08
172.20.113.0/24 *[Direct/0] 01:00:25
> via ge-0/0/4.113

172.20.113.1/32 *[Local/0] 01:00:25
172.20.114.0/24 *[Static/5] 00:00:08
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
192.168.1.1/32 *[Direct/0] 01:00:25
> via lo0.0
192.168.1.2/32 *[Static/20] 00:04:49
> to 172.20.113.10 via ge-0/0/4.113
192.168.2.0/30 *[Static/5] 00:00:08
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
lab@srxB-1>
Question: Were the interface and static routes from

the instance-a.inet.0 routing table imported
into the inet.0 routing table?
Answer: As shown in the capture, the interface and

static routes were imported into the inet.0
routing table.
Note
Ensure that the remote team finishes the
previous step before proceeding.
Step 3.13
Attempt to ping the loopback address of the remote student device from the master
inet.0 instance and user-defined instance-a instance.
lab@srxB-1> ping remote-loopback-address
PING 192.168.2.1 (192.168.2.1): 56 data bytes
^C
lab@srxB-1> ping remote-loopback-address routing-instance instance-a

PING 192.168.2.1 (192.168.2.1): 56 data bytes
^C

Question: Do the ping operations succeed?
Answer: As shown in the output, the ping operations

should succeed. These results indicate that the
both student devices now have the required routing
information to forward the packets between the
master instance and the user-defined instance.
Step 3.14
Log out of your assigned device using the exit command.
lab@srxB-1> exit
srxB-1 (ttyu0)
login:
STOP Tell your instructor that you have completed Lab 1.


Lab 2
Load Balancing and Filter-Based Forwarding (Detailed)
Overview
This lab demonstrates configuration and monitoring of load balancing and filter-based
forwarding (FBF) on devices running the Junos operating system. In this lab, you use the
command-line interface (CLI) to configure and monitor load balancing and FBF.
• Configure and monitor the effects of a load-balancing policy.
• Configure and monitor FBF.
www.juniper.net Load Balancing and Filter-Based Forwarding (Detailed) • Lab 2–1

12.a.12.1R1.9
Part 1: Configuring and Monitoring Load Balancing
In this lab part, you add static routes to your remote partner. You then verify the
default load-balancing behavior. Finally, you configure and monitor load balancing.
Step 1.1


Step 1.2
Step 1.3
commit command.
Lab 2–2 • Load Balancing and Filter-Based Forwarding (Detailed) www.juniper.net

srxB-1 (ttyp0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
Step 1.4
Define two static routes to the loopback addresses of the remote team’s device and
the remote virtual router and the remote subnet that connects the remote team’s
device and the remote virtual router. Both static routes should include two next-hop
addresses of the remote team’s ge-0/0/2 and ge-0/0/1 interfaces. Refer to the
network diagram for this lab as necessary. Once you are satisfied with the
configuration, activate the changes and return to operational mode.
[edit]
lab@srxB-1# set static route remote-loopback/30 next-hop
remote-ge-0/0/2-address
lab@srxB-1# set static route remote-loopback/30 next-hop
lab@srxB-1# set static route remote-vr-address/24 next-hop
lab@srxB-1# set static route remote-vr-address/24 next-hop
lab@srxB-1# show
static {
defaults {
preference 20;
}
route 0.0.0.0/0 {
next-hop 172.18.1.1;
preference 5;
}
route 192.168.1.2/32 next-hop 172.20.113.10;

route 192.168.2.0/30 next-hop [ 172.20.66.2 172.20.77.2 ];
route 172.20.114.0/24 next-hop [ 172.20.66.2 172.20.77.2 ];
}
aggregate {
route 172.20.64.0/18;
}
commit complete
lab@srxB-1>
Step 1.5
Display the routing table entries for the loopback addresses of the remote team’s
device, the remote virtual router, and the remote subnet that connects the remote
team’s device and the remote virtual router.
lab@srxB-1> show route remote-loopback/30

192.168.2.0/30 *[Static/20] 00:00:31

to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
lab@srxB-1> show route remote-vr-address/24

172.20.114.0/24 *[Static/20] 00:04:02

to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
Question: Which next-hop interface was selected for

these two static routes?
Answer: The answer can vary. In the sample output,

srxB-1 selected the ge-0/0/2.0 interface for both
routes. Because the selection process is somewhat
random, your results might vary, but you should see
a single next-hop interface selected for each route.
Step 1.6
Display the forwarding table entries for the same destination prefixes and answer
the question that follows.

lab@srxB-1> show route forwarding-table destination remote-loopback/30
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
192.168.2.0/30 user 0 172.20.66.2 ucst 562 4 ge-0/0/2.0
Routing table: __master.anon__.inet

Internet:
default perm 0 rjct 518 1
lab@srxB-1> show route forwarding-table destination remote-vr-address/24

Internet:
172.20.114.0/24 user 0 172.20.66.2 ucst 572 4 ge-0/0/2.0

Internet:
Question: Which next-hop interfaces does the

output list for the specified forwarding entries?
Answer: Only the next-hop interface selected by the

routing process (shown in the routing table) should
appear in the forwarding table for these prefixes.
Step 1.7
Enter configuration mode and navigate to the [edit policy-options]
hierarchy level.
[edit]
lab@srxB-1# edit policy-options
[edit policy-options]
lab@srxB-1#
Step 1.8
Define a load-balancing policy named balance-traffic that will load-balance
traffic over all equal-cost paths.
lab@srxB-1# set policy-statement balance-traffic then load-balance per-packet

Step 1.9
Navigate to the [edit routing-options forwarding-table] hierarchy
level and apply the balance-traffic policy as an export policy. Issue the
commit command to activate the configuration change.
lab@srxB-1# top edit routing-options forwarding-table
[edit routing-options forwarding-table]

lab@srxB-1# set export balance-traffic

lab@srxB-1# commit
commit complete

lab@srxB-1#
Step 1.10
Once again, display the forwarding table entries for the loopback addresses of the
remote team’s device and the remote virtual router and the remote subnet that
connects the remote team’s device and the remote virtual router . Compare this
output with the previous output (shown in Step 1.6) and answer the following
question.
lab@srxB-1# run show route forwarding-table destination remote-loopback/30
Internet:
192.168.2.0/30 user 0 ulst 262142 3
172.20.77.2 ucst 547 3 ge-0/0/1.0
172.20.66.2 ucst 562 3 ge-0/0/2.0

Internet:

lab@srxB-1# run show route forwarding-table destination remote-vr-address/24
Internet:
172.20.114.0/24 user 0 ulst 262142 3
172.20.77.2 ucst 556 3 ge-0/0/1.0
172.20.66.2 ucst 572 3 ge-0/0/2.0

Internet:

Question: Compared with the previous snapshot of
the forwarding table entries for these same
prefixes, what is different with this output?
Answer: The new output includes both equal-cost

next-hop interfaces for the specified destination
prefixes. In the sample output, the destination
prefixes now show a unicast list (ulst) along with
both unicast (ucst) next-hop interfaces
(ge-0/0/1.0 and ge-0/0/2.0). If you do not see
similar results on your device, check your
configuration.
Step 1.11
Navigate to the [edit forwarding-options] hierarchy level and configure
your device to evaluate Layer 3 and Layer 4 port data when performing the
load-balancing hash operation for IP version 4 (IPv4) traffic. Activate the
configuration changes and return to operational mode.
lab@srxB-1# top edit forwarding-options
[edit forwarding-options]
lab@srxB-1# set hash-key family inet layer-3
lab@srxB-1# set hash-key family inet layer-4
commit complete
lab@srxB-1>
Step 1.12
Perform a series of traceroute operations (at least three instances) from your
assigned device to the loopback address assigned to the remote virtual router.
lab@srxB-1> traceroute remote-vr-loopback
traceroute to 192.168.2.2 (192.168.2.2), 30 hops max, 40 byte packets
1 172.20.66.2 (172.20.66.2) 1.563 ms 4.989 ms 172.20.77.2 (172.20.77.2)
1.543 ms
2 192.168.2.2 (192.168.2.2) 3.768 ms 3.292 ms 2.894 ms

1 172.20.77.2 (172.20.77.2) 1.548 ms 1.275 ms 172.20.66.2 (172.20.66.2)
1.285 ms

2 192.168.2.2 (192.168.2.2) 11.223 ms 3.527 ms 4.809 ms

1 172.20.66.2 (172.20.66.2) 1.783 ms 1.615 ms 172.20.77.2 (172.20.77.2)
1.634 ms
2 192.168.2.2 (192.168.2.2) 3.196 ms 5.112 ms 2.906 ms
Note
The results illustrated in this lab step may
not be the same for all Junos platforms.
Some platforms will not allow this type of
verification and will require you to pass
traffic through the device i.e. not sourced
from the device (as in this step).
Question: Based on the traceroute results, does

your device load-balance the UDP traceroute
packets across both equal-cost paths?
Answer: Although the actual results might vary, the

UDP traceroute packets should travel over both
physical paths toward the remote virtual router. In
the sample output, the UDP traceroute packets
from the first and third instances were directed to
the 172.20.66.2 next-hop address, whereas in the
second instance, the packets were directed to the
172.20.77.2 next-hop address. Because your
device is now evaluating Layer 3 and Layer 4 port
data in addition to the source and destination IP
addresses and the protocol, you now see a more
granular load-balancing behavior. In the case of
UDP traceroute packets, the source port changes
between each instance of the traceroute operation.
STOP Do not proceed until the remote team finishes Part 1.
Part 2: Configuring and Monitoring Filter-Based Forwarding
In this lab part, you configure and monitor FBF.

Step 2.1

[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
[edit]
lab@srxB-1#
Step 2.2
Enter configuration mode and navigate to the [edit firewall family inet]
hierarchy level.
[edit]
lab@srxB-1# edit firewall family inet
[edit firewall family inet]

lab@srxB-1#
Step 2.3
Navigate to the [edit firewall family inet] hierarchy level. Issue the
edit filter my-fbf-filter command to define a firewall filter named
my-fbf-filter. Create a term named match-172-subnet that matches and
forwards traffic sourced from the local vr-device subnet to a forwarding instance
called instance-66. Create a second term named match-192-subnet that
matches and forwards traffic sourced from the local loopback subnet to a
forwarding instance named instance-77. You will define the referenced
forwarding instances in subsequent lab steps.
[edit]
lab@srxB-1# edit firewall family inet
[edit firewall family inet]

lab@srxB-1# edit filter my-fbf-filter
[edit firewall family inet filter my-fbf-filter]

lab@srxB-1# set term match-172-subnet from source-address local-vr-address/24

lab@srxB-1# set term match-172-subnet then routing-instance instance-66

lab@srxB-1# set term match-192-subnet from source-address local-loopback/30

lab@srxB-1# set term match-192-subnet then routing-instance instance-77

lab@srxB-1# show
term match-172-subnet {
from {
source-address {
172.20.113.0/24;
}
}
then {
routing-instance instance-66; ## 'instance-66' is not defined
}
}
term match-192-subnet {
from {
source-address {
192.168.1.0/30;
}
}
then {
routing-instance instance-77; ## 'instance-77' is not defined
}
}

lab@srxB-1#
Step 2.4
Navigate to the [edit interfaces ge-0/0/4] hierarchy level and apply the
new match filter as an input IPv4 filter to the defined logical interface.
lab@srxB-1# top edit interfaces ge-0/0/4
[edit interfaces ge-0/0/4]

lab@srxB-1# set unit local-vlan-id family inet filter input my-fbf-filter

lab@srxB-1#
Step 2.5
Navigate to the [edit routing-instances] hierarchy and create a new
instance named instance-66 using the forwarding instance type.
lab@srxB-1# top edit routing-instances
lab@srxB-1# set instance-66 instance-type forwarding
lab@srxB-1#

Step 2.6
Define two static routes for instance-66 for the remote loopback and vr-device
subnets. Use the ge-0/0/2 interface address assigned to the remote student device
as the next hop for both static routes.
lab@srxB-1# set instance-66 routing-options static route remote-loopback/30
next-hop remote-ge-0/0/2-interface
lab@srxB-1# set instance-66 routing-options static route remote-vr-address/24
next-hop remote-ge-0/0/2-interface
Step 2.7
Use the copy command to copy the contents defined in the instance-66 routing
instance to a new routing instance named instance-77.
lab@srxB-1# copy instance-66 to instance-77
lab@srxB-1# show
instance-66 {
instance-type forwarding;
routing-options {
static {
route 192.168.2.0/30 next-hop 172.20.66.2;
route 172.20.114.0/24 next-hop 172.20.66.2;
}
}
}
instance-77 {
routing-options {
static {
route 192.168.2.0/30 next-hop 172.20.66.2;
route 172.20.114.0/24 next-hop 172.20.66.2;
}
}
}
Step 2.8
Issue the edit instance-77 command to navigate to the [edit
routing-instances instance-77] hierarchy level. Next, issue the
replace pattern 66 with 77 command to modify the next-hop addresses
for the static routes.
lab@srxB-1# edit instance-77
[edit routing-instances instance-77]

lab@srxB-1# replace pattern 66 with 77

lab@srxB-1# show

routing-options {
static {
route 192.168.2.0/30 next-hop 172.20.77.2;
route 172.20.114.0/24 next-hop 172.20.77.2;
}
}

lab@srxB-1#
Step 2.9
Navigate to the [edit routing-options] hierarchy level and define an import
routing table group named fbf-rib-group that includes the inet.0,
instance-66.inet.0, and instance-77.inet.0 routing tables.
lab@srxB-1# set rib-groups fbf-rib-group import-rib [inet.0 instance-66.inet.0
instance-77.inet.0]
lab@srxB-1#
Step 2.10
Issue the set interface-routes rib-group inet fbf-rib-group
command to apply the newly defined routing table group to import interface routes
between the master and user-defined routing instances.
lab@srxB-1# set interface-routes rib-group inet fbf-rib-group
Step 2.11
Activate the configuration and issue the run show route command to ensure
that the routing tables for the user-defined routing instances have the required
routing information.
lab@srxB-1# commit
commit complete
lab@srxB-1# run show route
...TRIMMED...
instance-66.inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)

10.210.35.128/26 *[Direct/0] 00:00:03

> via ge-0/0/0.0
10.210.35.133/32 *[Local/0] 00:00:03

172.18.1.0/30 *[Direct/0] 00:00:03
> via ge-0/0/3.0
172.18.1.2/32 *[Local/0] 00:00:03
172.20.66.0/30 *[Direct/0] 00:00:03
> via ge-0/0/2.0
172.20.66.1/32 *[Local/0] 00:00:03
172.20.77.0/30 *[Direct/0] 00:00:03
> via ge-0/0/1.0
172.20.77.1/32 *[Local/0] 00:00:03
172.20.113.0/24 *[Direct/0] 00:00:03
> via ge-0/0/4.113
172.20.113.1/32 *[Local/0] 00:00:03
172.20.114.0/24 *[Static/5] 00:00:03
> to 172.20.66.2 via ge-0/0/2.0
192.168.1.1/32 *[Direct/0] 00:00:03
> via lo0.0
192.168.2.0/30 *[Static/5] 00:00:03
> to 172.20.66.2 via ge-0/0/2.0

10.210.35.128/26 *[Direct/0] 00:00:03

> via ge-0/0/0.0
10.210.35.133/32 *[Local/0] 00:00:03
172.18.1.0/30 *[Direct/0] 00:00:03
> via ge-0/0/3.0
172.18.1.2/32 *[Local/0] 00:00:03
172.20.66.0/30 *[Direct/0] 00:00:03
> via ge-0/0/2.0
172.20.66.1/32 *[Local/0] 00:00:03
172.20.77.0/30 *[Direct/0] 00:00:03
> via ge-0/0/1.0
172.20.77.1/32 *[Local/0] 00:00:03
172.20.113.0/24 *[Direct/0] 00:00:03
> via ge-0/0/4.113
172.20.113.1/32 *[Local/0] 00:00:03
172.20.114.0/24 *[Static/5] 00:00:03
> to 172.20.77.2 via ge-0/0/1.0
192.168.1.1/32 *[Direct/0] 00:00:03
> via lo0.0
192.168.2.0/30 *[Static/5] 00:00:03
> to 172.20.77.2 via ge-0/0/1.0

Question: Were the static and interface routes
added to the routing tables for the new instances?
Answer: Yes, at this point the new instances should

have the static routes defined under the respective
instances along with all interface routes. If you do
not see these routes, check your configuration and,
if necessary, ask your instructor for assistance.
Note
The next lab steps require you to log in to
the virtual router attached to your team’s
device. The virtual routers are logical
devices created on a J Series Services
Router. Refer to the management network
diagram for the IP address of the virtual
router device.
Step 2.12
Open a separate Telnet session to the virtual router device.

Step 2.13
Log in to the virtual router attached to your team’s device using the login information
shown in the following table:
Virtual Router Login Details
Student Device Username Password

srxA-1 a1 lab123
srxA-2 a2 lab123
srxB-1 b1 lab123
srxB-2 b2 lab123
srxC-1 c1 lab123
srxC-2 c2 lab123
srxD-1 d1 lab123
srxD-2 d2 lab123
vr-device (ttyp0)
login: username
Password:
--- JUNOS 11.4R1.6 built 2011-11-15 11:28:05 UTC
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
You must use 'configure private' to configure this router.
b1@vr-device>
Step 2.14
From your assigned virtual router, perform several traceroute operations (at least
three instances) to the loopback address assigned to the remote virtual router.
Note
Remember to reference the appropriate
instance name when sourcing Internet
Control Message Protocol (ICMP) traffic
from a virtual router. The instance names
match the virtual router names listed on
the network diagram for this lab.

b1@vr-device> traceroute remote-vr-loopback routing-instance vrvlan-id
1 172.20.113.1 (172.20.113.1) 17.678 ms 5.093 ms 5.432 ms
2 172.20.66.2 (172.20.66.2) 8.977 ms 9.004 ms 11.382 ms
3 192.168.2.2 (192.168.2.2) 4.925 ms 7.695 ms 7.622 ms

1 172.20.113.1 (172.20.113.1) 11.547 ms 8.720 ms 9.580 ms
2 172.20.66.2 (172.20.66.2) 4.864 ms 5.904 ms 4.876 ms
3 192.168.2.2 (192.168.2.2) 5.136 ms 8.656 ms 7.922 ms

1 172.20.113.1 (172.20.113.1) 9.426 ms 8.589 ms 10.749 ms
2 172.20.66.2 (172.20.66.2) 9.262 ms 10.098 ms 4.717 ms
3 192.168.2.2 (192.168.2.2) 5.207 ms 5.406 ms 6.231 ms
Question: Which path did the traceroute packets

take?
Answer: For this lab step, all traceroute packets

should have taken the path that uses the
172.20.66.0/30 subnet and the ge-0/0/2.0
interfaces. This path is the expected path based on
our match filter and the source address used in this
test. If you see different results, check your
configuration and, if necessary, ask your instructor
for assistance.
Step 2.15
Using your local virtual router’s loopback address as the source address, perform a
new series of traceroute operations (at least three instances) to the loopback
address assigned to the remote virtual router.
Note
instance name when sourcing traffic from a
virtual router. The instance names match
the virtual router names listed on the
network diagram for this lab.
b1@vr-device> traceroute remote-vr-loopback routing-instance vrvlan-id source

local-vr-loopback
traceroute to 192.168.2.2 (192.168.2.2) from 192.168.1.2, 30 hops max, 40 byte
packets
1 172.20.113.1 (172.20.113.1) 10.006 ms 8.425 ms 8.725 ms
2 172.20.77.2 (172.20.77.2) 12.497 ms 8.394 ms 11.563 ms
3 192.168.2.2 (192.168.2.2) 24.980 ms 14.949 ms 24.630 ms

local-vr-loopback
packets
1 172.20.113.1 (172.20.113.1) 12.498 ms 12.203 ms 12.625 ms
2 172.20.77.2 (172.20.77.2) 6.200 ms 3.743 ms 10.996 ms
3 192.168.2.2 (192.168.2.2) 6.134 ms 7.438 ms 6.046 ms

local-vr-loopback
packets
1 172.20.113.1 (172.20.113.1) 9.950 ms 8.620 ms 8.493 ms
2 172.20.77.2 (172.20.77.2) 9.308 ms 10.328 ms 9.575 ms
3 192.168.2.2 (192.168.2.2) 5.234 ms 5.380 ms 6.983 ms
Question: Which path did the traceroute packets

take?
Answer: For this lab step, all traceroute packets

should have taken the path that uses the
172.20.77.0/30 subnet and the ge-0/0/1.0
interfaces. This path is the expected path based on
our match filter and the source address used in this
test. If you see different results, check your
configuration and, if necessary, ask your instructor
for assistance.
Step 2.16
Use the ping utility to verify that your assigned virtual router can reach the Internet
host. Remember to reference the appropriate routing instance.
b1@vr-device> ping 172.31.15.1 routing-instance vrvlan-id
PING 172.31.15.1 (172.31.15.1): 56 data bytes
4 5 00 0054 7ab4 0 0000 40 01 23b6 172.20.113.10 172.31.15.1

4 5 00 0054 7abe 0 0000 40 01 23ac 172.20.113.10 172.31.15.1

4 5 00 0054 7ac1 0 0000 40 01 23a9 172.20.113.10 172.31.15.1
^C

Question: Was the ping test successful? If not, why
not?
Answer: No, the ping test should not succeed. The

ping test fails because the match filter created
earlier directs all traffic received from the virtual
routers to one of the two forwarding instances
based on source address regardless of the packet’s
destination. The routing instances include only the
static routes to the remote destinations and
interface routes. Several options are available to
remedy this situation. We highlight one of the
available options in a subsequent lab step.
Step 2.17
Return to the session opened to your assigned student device.
From the session opened to your assigned student device, navigate to the [edit
routing-instances] hierarchy level and define a default static route that
directs matching traffic to the inet.0 routing table for both routing instances.
Activate the configuration change and return to operational mode.
lab@srxB-1# top edit routing-instances
lab@srxB-1# set instance-66 routing-options static route 0/0 next-table inet.0
lab@srxB-1# set instance-77 routing-options static route 0/0 next-table inet.0
commit complete
lab@srxB-1>
Step 2.18
Issue the show route table instance-66 protocol static command
and ensure that the default static route was installed and directs traffic to the
inet.0 routing table.
lab@srxB-1> show route table instance-66 protocol static


0.0.0.0/0 *[Static/5] 00:00:36

to table inet.0
172.20.114.0/24 *[Static/5] 00:09:18
> to 172.20.66.2 via ge-0/0/2.0
192.168.2.0/30 *[Static/5] 00:09:18
> to 172.20.66.2 via ge-0/0/2.0
lab@srxB-1> show route table instance-77 protocol static

0.0.0.0/0 *[Static/5] 00:01:03

to table inet.0
172.20.114.0/24 *[Static/5] 00:09:45
> to 172.20.77.2 via ge-0/0/1.0
192.168.2.0/30 *[Static/5] 00:09:45
> to 172.20.77.2 via ge-0/0/1.0
Question: Do each of the user-defined instances

now have a default static route installed that directs
matching traffic to the inet.0 routing table?
Answer: Yes. As shown in the sample output, you

should see a default static route in each routing
table associated with the user-defined routing
instances. These default static routes should direct
traffic to the inet.0 table, which is evident with
the reference “to table inet.0”. If you do not
see similar entries for your device, check your
configuration and, if necessary, ask the instructor
for assistance.
Step 2.19
Return to the session opened to the virtual router.
From the session opened to the virtual router, perform the ping test to the Internet
host again. Remember to reference the appropriate routing instance.
b1@vr-device> ping 172.31.15.1 routing-instance vrvlan-id
PING 172.31.15.1 (172.31.15.1): 56 data bytes
^C

Question: Was the ping test successful?
Answer: Yes, the ping test should now succeed.
Step 2.20
From the session opened to your assigned student device, log out of your assigned
device using the exit command.
lab@srxB-1> exit
srxB-1 (ttyu0)
login:

Lab 3
Open Shortest Path First (Detailed)
Overview
This lab demonstrates configuration and monitoring of the Open Shortest Path First
(OSPF) protocol. In this lab, you use the command-line interface (CLI) to configure,
monitor, and troubleshoot OSPF.
• Configure and monitor a multi-area OSPF network.
• Perform basic OSPF troubleshooting.
www.juniper.net Open Shortest Path First (Detailed) • Lab 3–1

12.a.12.1R1.9
Part 1: Configuring and Monitoring OSPF
In this lab part, you configure and monitor a multi-area OSPF network. You will first
load a baseline configuration. Next you define a router ID for your assigned device.
You then configure your device to participate in a multi-area OSPF network and verify
operations using CLI operational mode commands.
Step 1.1


Step 1.2
Step 1.3
commit command.
Lab 3–2 • Open Shortest Path First (Detailed) www.juniper.net

srxB-1 (ttyp0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
Step 1.4
Navigate to the [edit routing-options] hierarchy level and define the router
ID on your router using the IP address assigned to your local lo0 interface as the
input value.
[edit]
lab@srxB-1# set router-id local-loopback-address
lab@srxB-1#
Step 1.5
Navigate to the [edit protocols ospf] hierarchy level and configure OSPF
Area 0. Refer to the network diagram as necessary and remember to include lo0.0.
lab@srxB-1# top edit protocols ospf
[edit protocols ospf]

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

lab@srxB-1# set area 0 interface ge-0/0/1.0


lab@srxB-1#
Note
Before proceeding, ensure that the remote
student team in your pod finishes the
previous step.

Step 1.6
Activate the configuration and issue the run show ospf neighbor command.
lab@srxB-1# commit
commit complete

lab@srxB-1# run show ospf neighbor
Address Interface State ID Pri Dead
172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 38
172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 35
Question: Which neighbor state is shown for the

listed interfaces?
Answer: The neighbor state for the ge-0/0/1.0 and

ge-0/0/2.0 interfaces should be Full, as shown in
the previous sample output. If you do not see the
Full state for both interfaces, check your
configuration and, if necessary, work with the
remote student team.
Question: Which value is listed under the ID

column?
Answer: The router ID assigned to the remote

student device should be listed under the ID
column. Note that this value should match the
remote student device’s lo0.0 IP address.
Question: Which value is listed under the Pri

column? What does this value help determine?
Answer: In all cases, the Pri value should show

128, which is the default priority value. Remember
that the priority value helps determine the
designated router on an Ethernet segment. The
device with the higher priority value is selected as
the designated router, assuming all competing
devices joined the segment at or around the same
time period.

Step 1.7
Issue the run show ospf interface command to display OSPF interface
details.
lab@srxB-1# run show ospf interface
Interface State Area DR ID BDR ID Nbrs
ge-0/0/1.0 DR 0.0.0.0 192.168.1.1 192.168.2.1 1
ge-0/0/2.0 DR 0.0.0.0 192.168.1.1 192.168.2.1 1
lo0.0 DR 0.0.0.0 192.168.1.1 0.0.0.0 0
Question: Which interfaces are listed in the output?

What are the states of those interfaces?
Answer: The ge-0/0/1.0, ge-0/0/2.0, and lo0.0

interfaces should all be listed. The states of the
ge-0/0/1.0 and ge-0/0/2.0 interfaces might show
DR or BDR, whereas the state of lo0.0 should show
DR in all cases. If the state of the interface is DR,
then the local router ID should be displayed under
the DR ID column and the router ID of the remote
student device should appear under the BDR ID
column. If the state of the interface is BDR, then the
opposite is true. The following is the output taken
from srxB-2 to show as a comparison:

lab@srxB-2# run show ospf interface
Interface State Area DR ID BDR ID Nbrs
ge-0/0/1.0 BDR 0.0.0.0 192.168.1.1 192.168.2.1 1
ge-0/0/2.0 BDR 0.0.0.0 192.168.1.1 192.168.2.1 1
lo0.0 DR 0.0.0.0 192.168.2.1 0.0.0.0 0
Step 1.8
Issue the run show ospf database command to display the OSPF database
details.
lab@srxB-1# run show ospf database
OSPF database, Area 0.0.0.0

Type ID Adv Rtr Seq Age Opt Cksum Len
Router *192.168.1.1 192.168.1.1 0x8000001e 99 0x22 0xd9b3 60
Router 192.168.2.1 192.168.2.1 0x8000001d 100 0x22 0x1376 60
Network *172.20.66.1 192.168.1.1 0x80000001 199 0x22 0xd124 32
Network *172.20.77.1 192.168.1.1 0x80000001 199 0x22 0x5892 32

Question: How many and what types of link-state
advertisements (LSAs) exist in OSPF database?
Answer: You should see a total of four LSA entries in

the OSPF database: two Router LSAs and two
Network LSAs. In the sample output, we see that
three of the four LSAs are advertised by the local
device, indicated by the asterisk (*). The other LSA
associates with the lo0.0 interface of the remote
team’s device and that device advertises it. Your
output might vary from the sample output.
Step 1.9
Display routes advertised to and received from OSPF using the run show ospf
route command.
lab@srxB-1# run show ospf route
Topology default Route Table:
Prefix Path Route NH Metric NextHop Nexthop

Type Type Type Interface Address/LSP
192.168.2.1 Intra Router IP 1 ge-0/0/1.0 172.20.77.2
ge-0/0/2.0 172.20.66.2
172.20.66.0/30 Intra Network IP 1 ge-0/0/2.0
192.168.1.1/32 Intra Network IP 0 lo0.0
192.168.2.1/32 Intra Network IP 1 ge-0/0/1.0 172.20.77.2
ge-0/0/2.0 172.20.66.2
Question: What is the current metric associated

with the displayed OSPF routes?
Answer: With the exception of the OSPF route for

the loopback address for the local device, all OSPF
routes should show a metric of 1. The metric for the
locally defined loopback address should be zero (0).

Question: Why does the output show two entries
with the same prefix?
Answer: The two entries with the same prefix

information represent the router ID and IP address
assigned to the remote team device. In the example
shown in the previous output, the 192.168.2.1
Router entry is associated with the router ID,
whereas the 192.168.2.1/32 Network entry is the
IP address assigned to the lo0.0 interface of the
remote team device.
Step 1.10
Associate a metric of 100 with the ge-0/0/2.0 interface and activate the change.
lab@srxB-1# set area 0 interface ge-0/0/2.0 metric 100

lab@srxB-1# commit
commit complete
Question: Based on your change, which interface do

you expect OSPF to choose toward the remote
student device?
Answer: OSPF prefers a lower link metric so it will

choose the ge-0/0/1.0 interface based on the
metric change.
Note
team in your pod finishes the previous step.
Step 1.11
Reissue the run show ospf route command to see your changes.


192.168.2.1 Intra Router IP 1 ge-0/0/1.0 172.20.77.2
Question: What is the current metric associated

with the 172.20.66.0/30 OSPF route?
Answer: The metric for the referenced prefix should

now show 100; previously, it was 1.
Question: What was the effect of the increased

metric for your partners loopback OSPF routes?
Answer: Because the ge-0/0/2.0 interface now has

a higher metric or cost, the remote partner’s
loopback OSPF route lists only the ge-0/0/1.0
interface as the next-hop interface; previously, both
ge-0/0/1.0 and ge-0/0/2.0 had the same metric,
which caused both to appear in the list.
Step 1.12
Issue the run show route protocol ospf command to view OSPF routes
installed in the routing table.
lab@srxB-1# run show route protocol ospf

192.168.2.1/32 *[OSPF/10] 00:06:31, metric 1

> to 172.20.77.2 via ge-0/0/1.0
224.0.0.5/32 *[OSPF/10] 00:55:19, metric 1
MultiRecv

Question: Which OSPF routes exist in the routing
table?
Answer: You should see two OSPF routes listed: one

route is for the loopback address of the remote
student device, and the second route is the OSPF
multicast route. You will see the OSPF multicast
route 224.0.0.5/32 when an OSPF neighbor is
established and OSPF routes are learned and
Question: Why are the 172.20.66.0/30 and

172.20.77.0/30 routes not listed in the generated
output?
Answer: The 172.20.66.0/30 and 172.20.77.0/30

routes are not listed in the output for the referenced
command because they are both installed in the
routing table as direct routes. Remember that direct
routes have a route preference of zero (0), whereas
internal OSPF routes have a default preference of
10.
Step 1.13
Configure your device to function as an area border router (ABR), joining Area 0 with
a second area (either Area 1 or Area 2, depending on your assigned device). Refer to
the network diagram for this lab for the area and interface details. Once it is
configured, activate the configuration changes and return to operational mode.
lab@srxB-1# set area area interface ge-0/0/4.vlan-id

lab@srxB-1# show
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/2.0 {
metric 100;
}
}
area 0.0.0.1 {
}

commit complete
lab@srxB-1>
Step 1.14
Issue the show ospf neighbor command to verify the current OSPF adjacency
details.
lab@srxB-1> show ospf neighbor
172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 33
172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 33
172.20.113.10 ge-0/0/4.113 Full 192.168.1.2 128 37
Question: How many OSPF neighbors exist and what

are the states of those adjacencies?
Answer: You should now see three OSPF neighbors

and they should each be in the Full adjacency
state. If you do not see three OSPF neighbors in the
Full adjacency state, check your configuration
and, if necessary, work with the instructor.
Step 1.15
Issue the show ospf database command to display the current OSPF database.
lab@srxB-1> show ospf database

Router *192.168.1.1 192.168.1.1 0x80000020 507 0x22 0x7ea8 60
Router 192.168.2.1 192.168.2.1 0x80000020 50 0x22 0xb56c 60
Network *172.20.66.1 192.168.1.1 0x80000002 812 0x22 0xcf25 32
Network *172.20.77.1 192.168.1.1 0x80000002 77 0x22 0x5693 32
Summary *172.20.113.0 192.168.1.1 0x80000003 506 0x22 0xb4e3 28
Summary 172.20.114.0 192.168.2.1 0x80000005 507 0x22 0x9ef5 28
Summary *192.168.1.2 192.168.1.1 0x80000001 507 0x22 0xa9ba 28
Summary 192.168.2.2 192.168.2.1 0x80000001 509 0x22 0x97ca 28
ASBRSum *192.168.1.2 192.168.1.1 0x80000002 506 0x22 0x99c8 28
ASBRSum 192.168.2.2 192.168.2.1 0x80000004 507 0x22 0x83da 28


Router *192.168.1.1 192.168.1.1 0x80000003 507 0x22 0x4b96 36
Router 192.168.1.2 192.168.1.2 0x800001c5 508 0x22 0x6035 48
Network 172.20.113.10 192.168.1.2 0x80000001 508 0x22 0x4d68 32
Summary *172.20.66.0 192.168.1.1 0x80000002 506 0x22 0xb9b2 28
Summary *172.20.77.0 192.168.1.1 0x80000002 506 0x22 0x5e66 28
Summary *172.20.114.0 192.168.1.1 0x80000001 507 0x22 0xb7e0 28
Summary *192.168.1.1 192.168.1.1 0x80000001 507 0x22 0xa9bc 28
Summary *192.168.2.1 192.168.1.1 0x80000001 507 0x22 0xa8bb 28
Summary *192.168.2.2 192.168.1.1 0x80000001 507 0x22 0xa8b9 28
ASBRSum *192.168.2.2 192.168.1.1 0x80000001 507 0x22 0x9ac6 28
OSPF AS SCOPE link state database
Extern 172.21.0.0 192.168.1.2 0x800001c0 832 0x22 0x9d26 36
Extern 172.21.1.0 192.168.1.2 0x800001c0 231 0x22 0x9230 36
Extern 172.21.2.0 192.168.1.2 0x800001bf 2032 0x22 0x8939 36
Extern 172.22.0.0 192.168.2.2 0x800001c0 832 0x22 0x8a37 36
Extern 172.22.1.0 192.168.2.2 0x800001c0 232 0x22 0x7f41 36
Extern 172.22.2.0 192.168.2.2 0x800001bf 2032 0x22 0x764a 36
Question: How many OSPF databases are present

in the output?
Answer: You should now see two OSPF databases:

one for each area in which your device is
participating. In the example output, srxB-1
shows a database for Area 0.0.0.0 and one for Area
0.0.0.1. The remote partner device, srxB-2,
should show a similar output for Area 0.0.0.0 and
Area 0.0.0.2.
Question: Which LSA types are represented in the

current OSPF databases?
Answer: You should now see router, network,

summary, ASBR summary, and external LSAs in the
databases.

Question: Based on the database entries, which
devices are injecting external prefixes in to OSPF?
Answer: At this time, both virtual routers

(192.168.1.2 and 192.168.2.2) should be
exporting external prefixes into OSPF. If you do not
see external prefixes, check your configuration and,
if necessary, work with the remote student team.
Question: Which command lists only external

entries in the OSPF database?
Answer: You can use the show ospf database

external command to filter the database
contents and show only external OSPF database
entries. The following is a sample of this command:
lab@srxB-1> show ospf database external

Extern 172.21.0.0 192.168.1.2 0x800001c0 1251 0x22 0x9d26 36
Extern 172.21.1.0 192.168.1.2 0x800001c0 650 0x22 0x9230 36
Extern 172.21.2.0 192.168.1.2 0x800001c0 102 0x22 0x873a 36
Extern 172.22.0.0 192.168.2.2 0x800001c0 1251 0x22 0x8a37 36
Extern 172.22.1.0 192.168.2.2 0x800001c0 651 0x22 0x7f41 36
Extern 172.22.2.0 192.168.2.2 0x800001c0 103 0x22 0x744b 36
Step 1.16
Enter configuration mode and navigate to the [edit policy-options]
hierarchy level.
[edit]
lab@srxB-1#
Step 1.17
Define a new routing policy named inject-default-route. Include a single
term named match-default-route that matches and accepts the default static
route into OSPF.

lab@srxB-1# edit policy-statement inject-default-route
[edit policy-options policy-statement inject-default-route]

lab@srxB-1# set term match-default-route from protocol static

lab@srxB-1# set term match-default-route from route-filter 0/0 exact

lab@srxB-1# set term match-default-route then accept

lab@srxB-1#
Step 1.18
Navigate to the [edit protocols ospf] hierarchy and apply the newly defined
policy as an export policy. Next, activate the configuration change using the commit
command.

lab@srxB-1# set export inject-default-route

lab@srxB-1# commit
commit complete

lab@srxB-1#
Step 1.19
Issue the run show ospf database advertising-router self
command to view all OSPF LSAs in the database that the local device originated.
Note that your output might vary from the sample output that follows:
lab@srxB-1# run show ospf database advertising-router self

Router *192.168.1.1 192.168.1.1 0x80000022 67 0x22 0x80a2 60
Network *172.20.66.1 192.168.1.1 0x80000003 1450 0x22 0xcd26 32
Network *172.20.77.1 192.168.1.1 0x80000002 1648 0x22 0x5693 32
Summary *172.20.113.0 192.168.1.1 0x80000006 15 0x22 0xaee6 28
Summary *192.168.1.2 192.168.1.1 0x80000002 659 0x22 0xa7bb 28
ASBRSum *192.168.1.2 192.168.1.1 0x80000005 15 0x22 0x93cb 28

Router *192.168.1.1 192.168.1.1 0x80000005 67 0x22 0x4d90 36
Summary *172.20.66.0 192.168.1.1 0x80000005 15 0x22 0xb3b5 28
Summary *172.20.77.0 192.168.1.1 0x80000005 15 0x22 0x5869 28

Summary *172.20.114.0 192.168.1.1 0x80000002 857 0x22 0xb5e1 28
Summary *192.168.1.1 192.168.1.1 0x80000002 66 0x22 0xa7bd 28
Summary *192.168.2.1 192.168.1.1 0x80000002 461 0x22 0xa6bc 28
Summary *192.168.2.2 192.168.1.1 0x80000002 264 0x22 0xa6ba 28
ASBRSum *192.168.2.1 192.168.1.1 0x80000002 15 0x22 0x98c9 28
ASBRSum *192.168.2.2 192.168.1.1 0x80000001 2078 0x22 0x9ac6 28
Extern *0.0.0.0 192.168.1.1 0x80000001 67 0x22 0xe75f 36
Question: Is a matching LSA entry present for the

recently injected default static route?
Answer: Yes, you should see an external LSA entry

for the default static route. If you do not see an
external LSA entry for the 0.0.0.0 prefix, check your
configuration and, if necessary, work with your
instructor.
Note
previous step.
Step 1.20
Issue the run show route 0/0 exact command to view the current routing
table entries for the default route.
lab@srxB-1# run show route 0/0 exact

0.0.0.0/0 *[Static/5] 08:20:12

> to 172.18.1.1 via ge-0/0/3.0
[OSPF/150] 00:02:31, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0

Question: Based on the current default route entry,
what would happen if your device’s direct
connection to the Internet failed?
Answer: At this time, you should see two default

route entries. The first, and currently selected,
default route is the default static route you defined
in a previous lab. The second default route is
learned through OSPF from the remote student
device. The default route learned through OSPF is
currently not selected as the active entry because
of a higher preference. If your device’s direct
connection to the Internet fails, your system then
selects the default route learned through OSPF, and
all traffic matching this route entry takes the
associated path.
Step 1.21
Issue the save /var/tmp/working-ospf.config command to save the
current OSPF configuration.
lab@srxB-1# save /var/tmp/working-ospf.config
Wrote 17 lines of configuration to '/var/tmp/working-ospf.conf'
Part 2: Performing Basic OSPF Troubleshooting
In this lab part, you perform basic OSPF troubleshooting. First, you modify your
device’s current configuration to make it incompatible with the attached virtual
router. You then enable OSPF traceoptions to log protocol activity. Finally, you display
the traceoptions log and the OSPF statistics to view the associated errors.
Step 2.1
Return to the top of the hierarchy and load the lab3-part2-start.config file
from the/var/home/lab/jir/ directory. Commit your configuration when
complete.

lab@srxB-1# top
[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
[edit]
lab@srxB-1#
Step 2.2
Issue the run show ospf statistics to display the current OSPF errors and
statistics.
[edit]
lab@srxB-1# run show ospf statistics
Packet type Total Last 5 seconds

Sent Received Sent Received
Hello 116 92 0 0
DbD 46 41 0 0
LSReq 7 2 0 0
LSUpdate 122 103 0 0
LSAck 73 93 0 0
DBDs retransmitted : 3, last 5 seconds : 0

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

Total rexmit entries : 0
db summaries : 0
lsreq entries : 0
Receive errors:
None

Question: Does your device show any registered
errors?
Answer: You should not see any errors at this time.

If you do see errors, clear the OSPF statistics using
the run clear ospf statistics command,
wait a couple of minutes, and then verify that the
error counters do not increment.
Step 2.3
Navigate to the [edit protocols ospf] hierarchy and rename the
nonbackbone area (Area 1 or Area 2 depending on your assigned device) to
area 3.
[edit]

lab@srxB-1# rename area area to area 3

lab@srxB-1# show
export inject-default-route;
area 0.0.0.0 {
interface lo0.0;
metric 100;
}
}
area 0.0.0.3 {
}
Step 2.4
Activate the configuration change and issue the run show ospf neighbor
command.
lab@srxB-1# commit
commit complete

172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 34
172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 33

Question: How many OSPF neighbors does your
assigned device currently have?
Answer: At this point, your device should have only

two neighbors. The neighbor adjacency with the
attached virtual router should no longer be in place
because of your recent configuration change.
Step 2.5
Define traceoptions for OSPF so that OSPF errors write to a file named
trace-ospf. Include the detail option with the error flag to capture
additional details for the OSPF errors. Activate the configuration change using the
commit command.
lab@srxB-1# set traceoptions file trace-ospf

lab@srxB-1# set traceoptions flag error detail

lab@srxB-1# commit
commit complete
Step 2.6
Issue the run show log trace-ospf command to view the contents written to
the trace-ospf trace file.
lab@srxB-1# run show log trace-ospf
Nov 10 00:32:57 trace_on: Tracing to "/var/log/trace-ospf" started
Nov 10 00:32:57.100041 OSPF packet ignored: area mismatch (0.0.0.1) from
172.20.113.10 on intf ge-0/0/4.113 area 0.0.0.3
Nov 10 00:32:57.100164 OSPF rcvd Hello 172.20.113.10 -> 224.0.0.5 (ge-0/0/4.113
IFL 72 area 0.0.0.3)
Nov 10 00:32:57.100230 Version 2, length 44, ID 192.168.1.2, area 0.0.0.1
Nov 10 00:32:57.100280 checksum 0x1955, authtype 0
Nov 10 00:32:57.100331 mask 255.255.255.0, hello_ivl 10, opts 0x2, prio 128
Nov 10 00:32:57.100425 dead_ivl 40, DR 172.20.113.10, BDR 0.0.0.0
Nov 10 00:33:04.143054 OSPF packet ignored: area mismatch (0.0.0.1) from
172.20.113.10 on intf ge-0/0/4.113 area 0.0.0.3
Nov 10 00:33:04.143195 OSPF rcvd Hello 172.20.113.10 -> 224.0.0.5 (ge-0/0/4.113
IFL 72 area 0.0.0.3)

Question: Does the generated error in the trace file
explain the current OSPF adjacency issue?
Answer: Based on the contents of the trace file, an

area mismatch obviously exists. In the previous
output, we see that the virtual router is configured
for Area 0.0.0.1, while the local device is configured
for Area 0.0.0.3.
Step 2.7
Issue the run show ospf statistics command to verify any current error
counters.

Hello 132 96 0 0
DbD 46 41 0 0
LSReq 7 2 0 0
LSAck 79 104 0 0


db summaries : 0
lsreq entries : 0
Receive errors:
17 area mismatches
Question: Are any error counters listed?
Answer: Yes. You should see a single error counter

named area mismatches with a nonzero value.

Step 2.8
Rename area 3 back to the correct area number (Area 1 or Area 2 depending on
your assigned device). Next, assign the correct nonbackbone area an area type of
stub and activate the configuration changes.
lab@srxB-1# rename area 3 to area area

lab@srxB-1# set area area stub

lab@srxB-1# commit
commit complete
Step 2.9
Issue the run clear log trace-ospf command to clear the contents of the
defined trace file. Wait a moment, then issue the run show log trace-ospf
command to view any new entries in the trace file.
lab@srxB-1# run clear log trace-ospf

lab@srxB-1# run show log trace-ospf
Nov 10 00:37:48 srxD-1 clear-log[5254]: logfile cleared
Nov 10 00:37:55.012880 OSPF packet ignored: area stubness mismatch from
172.20.113.10 on intf ge-0/0/4.113 area 0.0.0.1

explain the current OSPF adjacency issue?

area stubness or area-type mismatch should exist.
Step 2.10
Issue the run show ospf statistics command to verify the current error
counters.

Hello 140 106 0 0
DbD 46 41 0 0
LSReq 7 2 0 0
LSAck 81 107 0 0


db summaries : 0
lsreq entries : 0
Receive errors:
39 area mismatches
8 stub area mismatches
Question: Are any new error counters listed?
Answer: Yes. You should now see the stub area

mismatches counter in addition to the area
mismatches counter. Both error counters should
show nonzero values.
Step 2.11
Issue the delete command and confirm the operation to delete the current OSPF
configuration. Next, issue the load merge /var/tmp/
working-ospf.config command to load the configuration you saved earlier in
this lab. Activate the restored configuration and return to operational mode using
the commit and-quit command.
lab@srxB-1# delete
Delete everything under this level? [yes,no] (no) yes

lab@srxB-1# load merge /var/tmp/working-ospf.config
load complete

commit complete
lab@srxB-1>

Step 2.12
Verify that the OSPF neighbor adjacency has returned to the Full state between
your device and the directly attached virtual router.
172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 30
172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 39
172.20.113.10 ge-0/0/4.113 Full 192.168.1.2 128 31
Question: Did the OSPF adjacency with the directly

attached virtual router return to the Full state?
Answer: Yes, you should now see all three neighbors

in the Full adjacency state, as shown in the
previous output.
Step 2.13
lab@srxB-1> exit
srxB-1 (ttyu0)
login:

Lab 4
Border Gateway Protocol (Detailed)
Overview
This lab demonstrates configuration and monitoring of the Border Gateway Protocol
(BGP). In this lab, you use the command-line interface (CLI) to configure and monitor BGP.
• Configure and monitor BGP.
• Export aggregate routes to an EBGP peer.
• Configure and apply a next-hop self policy.
www.juniper.net Border Gateway Protocol (Detailed) • Lab 4–1

12.a.12.1R1.9
Part 1: Configuring and Monitoring IBGP
In this lab part, you configure and monitor internal BGP (IBGP). You first define the
autonomous system (AS) number for your device. Next, you establish IBGP peering
sessions using loopback addresses. You then monitor the established IBGP peering
sessions using CLI operational mode commands.
Step 1.1


Step 1.2
Step 1.3
commit command.
Lab 4–2 • Border Gateway Protocol (Detailed) www.juniper.net

srxB-1 (ttyp0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
Step 1.4
Navigate to the [edit routing-options] hierarchy level and define the AS
number designated for your network. Refer to the network diagram for this lab as
necessary.
[edit]
lab@srxB-1# set autonomous-system 64700
lab@srxB-1#
Step 1.5
Navigate to the [edit protocols bgp] hierarchy level. Configure a BGP group
named my-int-group that includes the three devices within your assigned
network as IBGP peers. Use the loopback address assigned to your device as the
local address and the remote loopback addresses of the devices within your AS
number as the peer addresses. When you are satisfied with the newly defined BGP
configuration, issue the commit command to activate the changes.
lab@srxB-1# top edit protocols bgp
[edit protocols bgp]

lab@srxB-1# set group my-int-group local-address local-loopback-address

lab@srxB-1# set group my-int-group neighbor local-vr-loopback-address

lab@srxB-1# set group my-int-group neighbor remote-loopback-address

lab@srxB-1# set group my-int-group neighbor remote-vr-loopback-address

lab@srxB-1# show
group my-int-group {
local-address 192.168.1.1;
neighbor 192.168.1.2;
neighbor 192.168.2.1;
neighbor 192.168.2.2;
}

lab@srxB-1# commit
[edit protocols]
'bgp'
Error in neighbor 192.168.1.2 of group my-int-group:
peer AS number must be configured for an external peer
error: configuration check-out failed

lab@srxB-1#
Question: Was the commit operation successful? If

not, why not?
Answer: The commit operation should have failed

and generated an error. You must either specify a
session type of internal or define a peer AS number
for the BGP group that matches the locally defined
AS number (64700). For external peering sessions,
you can specify the external session type and define
the remote peer AS number or because the system
assumes the external session type by default,
simply define the remote peer AS number.
Step 1.6
Configure the my-int-group for the internal BGP session type. Next, issue the
commit command to activate the configuration.
lab@srxB-1# set group my-int-group type internal

lab@srxB-1# commit
commit complete
Note
previous step.

Step 1.7
Issue the run show bgp summary command to view the current BGP summary
information for your device.
lab@srxB-1# run show bgp summary
Groups: 1 Peers: 3 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 6 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
192.168.1.2 64700 22 23 0 0 9:14 0/
3/3/0 0/0/0/0
192.168.2.1 64700 4 3 0 0 39 0/
0/0/0 0/0/0/0
192.168.2.2 64700 22 21 0 0 9:06 0/
3/3/0 0/0/0/0
Question: How many BGP neighbors does your

device currently list?
Answer: Your device should list the three IBGP

peers you defined previously in this lab part. If you
do not see three IBGP peers, check your
configuration. If necessary, consult with the remote
team and the instructor.
Question: Has your device received any routes from

its IBGP peers?
Answer: Yes, your device should have received three

BGP routes from each of the virtual routes within
your assigned pod.
Step 1.8
Issue the run show route receive-protocol bgp neighbor command,
where neighbor is the loopback address of each IBGP peer.
lab@srxB-1# run show route receive-protocol bgp local-vr-loopback-address

Prefix Nexthop MED Lclpref AS path
172.21.0.0/24 192.168.1.2 100 I
172.21.1.0/24 192.168.1.2 100 I
172.21.2.0/24 192.168.1.2 100 I

lab@srxB-1# run show route receive-protocol bgp remote-loopback-address

lab@srxB-1# run show route receive-protocol bgp remote-vr-loopback-address

172.22.0.0/24 192.168.2.2 100 I
172.22.1.0/24 192.168.2.2 100 I
172.22.2.0/24 192.168.2.2 100 I
Question: From which IBGP peers are you currently

receiving routes?
Answer: Only the virtual routers in your assigned

pod and AS are currently advertising routes. Note
that these routes are the same routes advertised
through OSPF.
Question: What is the AS path associated with the

received BGP routes?
Answer: The AS path for the received BGP routes is

I, which means the route originated in the local AS.
Once these routes are advertised to a different AS,
the local AS (64700 in this case) will be added to
the AS path list.
Question: What is the local preference of the

received BGP routes?
Answer: All received BGP routes should show a local

preference of 100, which is the default value.

Question: Which routing table group does the
referenced command consult? Which operational
mode command displays BGP routes in the routing
table (RIB-Local)?
Answer: The command referenced in this step

consults the RIB-In routing table. You can issue
the show route protocol bgp operational
mode command to display BGP routes. A sample of
this command is illustrated in the following capture:

lab@srxB-1# run show route protocol bgp

172.21.0.0/24 [BGP/170] 00:05:25, localpref 100, from 192.168.1.2

AS path: I
> to 172.20.113.10 via ge-0/0/4.113
AS path: I
> to 172.20.113.10 via ge-0/0/4.113
AS path: I
> to 172.20.113.10 via ge-0/0/4.113
AS path: I
> to 172.20.77.2 via ge-0/0/1.0
AS path: I
> to 172.20.77.2 via ge-0/0/1.0
AS path: I
> to 172.20.77.2 via ge-0/0/1.0
Step 1.9
Issue the run show route advertising-protocol bgp neighbor
command, where neighbor is the loopback address of each IBGP peer.
lab@srxB-1# run show route advertising-protocol bgp local-vr-loopback-address

lab@srxB-1# run show route advertising-protocol bgp remote-loopback-address

lab@srxB-1# run show route advertising-protocol bgp remote-vr-loopback-address

Question: Which routing table group does the
command referenced in this step consult?
Answer: The command referenced in this step

consults the RIB-Out routing table.
Question: Is your device currently advertising BGP

routes to any of its IBGP peers?
Answer: No. As illustrated in the sample output,

your device should not be advertising any BGP
routes at this time. Because BGP routes received
from IBGP peers are not readvertised to other IBGP
peers, it is logical that your device is not advertising
BGP routes at this time.
Part 2: Configuring and Monitoring EBGP
In this lab part, you configure and monitor EBGP. You first establish an EBGP peering
session with the external peer. You then advertise aggregate routes to your EBGP
peer to represent the prefixes reachable from your AS. Finally, you monitor the
established EBGP peering session using CLI operational mode commands.
Step 2.1
complete.
lab@srxB-1# top
[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
[edit]
lab@srxB-1#

Step 2.2
Navigate to the [edit protocols bgp] hierarchy level. Refer to the network
diagram for this lab and configure an EBGP peering session with the connected AS
(either ISP X or ISP Z). Name the associated EBGP group my-ext-group. Once
configured, activate the configuration changes using the commit command.
[edit]
lab@srxB-1# edit protocols bgp

lab@srxB-1# set group my-ext-group type external

lab@srxB-1# set group my-ext-group peer-as AS-number

lab@srxB-1# set group my-ext-group neighbor address

lab@srxB-1# show
group my-int-group {
type internal;
local-address 192.168.1.1;
neighbor 192.168.1.2;
neighbor 192.168.2.1;
neighbor 192.168.2.2;
}
group my-ext-group {
type external;
peer-as 65510;
neighbor 172.18.1.1;
}

lab@srxB-1# commit
commit complete

lab@srxB-1#
Note
Before proceeding, ensure the remote
student team in your pod has finished the
previous step.
Step 2.3
Issue the run show bgp summary command to view the current BGP summary
information.

lab@srxB-1# run show bgp summary
Groups: 2 Peers: 4 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 16 10 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
172.18.1.1 65510 8 5 0 0 1:12 10/
10/10/0 0/0/0/0
192.168.1.2 64700 70 75 0 0 31:20 0/
3/3/0 0/0/0/0
192.168.2.1 64700 54 55 0 0 22:45 0/
0/0/0 0/0/0/0
192.168.2.2 64700 70 74 0 0 31:12 0/
3/3/0 0/0/0/0
Question: How many BGP groups and peers does

your device currently list?
Answer: Your device should now list two BGP groups

and four BGP peers; the IBGP group consists of
three peers and the EBGP group has one peer. If
you do not see four BGP peers, check your
configuration and, if necessary, consult with the
instructor.
Question: Has your device received any routes from

its EBGP peer?
Answer: Yes, your device should receive 10 BGP

routes from its EBGP peer. Note that the remote
student device, currently serving as an IBGP peer, is
also advertising 10 BGP routes.
Step 2.4
Issue the run show bgp neighbor address command to view details for the
EBGP peering session. Replace address with the IP address value assigned to your
EBGP peer. Use the generated output to answer the following questions:
lab@srxB-1# run show bgp neighbor address
Peer: 172.18.1.1+179 AS 65510 Local: 172.18.1.2+62658 AS 64700
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Preference PeerAS Refresh>
Holdtime: 90 Preference: 170

Number of flaps: 0
Peer ID: 10.10.10.10 Local ID: 192.168.1.1 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
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 65510)
Peer does not support Addpath
Table inet.0 Bit: 10001
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 10
Received prefixes: 10
Accepted prefixes: 10
Suppressed due to damping: 0
Advertised prefixes: 0
Last traffic (seconds): Received 12 Sent 10 Checked 59
Input messages: Total 116 Updates 5 Refreshes 0 Octets 2373
Output messages: Total 114 Updates 0 Refreshes 0 Octets 2229
Output Queue[0]: 0
Question: What is the current state for this peer?

What was the previous state for this peering
session?
Answer: The current state is Established. The

previous state (or Last State) is OpenConfirm.
Question: Which values are set for the keepalive

interval and holddown timer?
Answer: The current keepalive interval is set to

30 seconds and the active holddown timer is set to
three times the keepalive interval (or 90 seconds).

Question: What is the last recorded event for this
EBGP session?
Answer: The last event your device should have

recorded likely indicates that a keepalive was
received from its peer (Last Event:
RecvKeepAlive).
Question: Which network layer reachability

information (NLRI) is supported for this peering
session?
Answer: The EBGP peering session supports the

inet-unicast NLRI, which is used for Internet
Protocol version 4 (IPv4) routes.
Step 2.5
Display the BGP routes received from the EBGP peer using the run show route
receive-protocol bgp address command, where address is the IP
address value assigned to your EBGP peer.
lab@srxB-1# run show route receive-protocol bgp address

* 0.0.0.0/0 172.18.1.1 65510 I
* 172.28.102.0/24 172.18.1.1 65510 65515
65519 65534 ?
* 172.28.103.0/24 172.18.1.1 65510 65515
65519 65534 ?
* 172.28.104.0/24 172.18.1.1 65510 65515
65519 65534 ?
* 172.30.1.0/24 172.18.1.1 65510 65515
65516 65517 I
* 172.30.2.0/24 172.18.1.1 65510 65515
65516 65517 I
* 172.30.3.0/24 172.18.1.1 65510 65515
65516 65517 I
* 172.31.10.0/24 172.18.1.1 65510 65515
65531 E
* 172.31.11.0/24 172.18.1.1 65510 65515
65531 E
* 172.31.12.0/24 172.18.1.1 65510 65515
65531 E

Question: How many prefixes originated from
AS number 65531?
Answer: You should see a total of 10 prefixes. Three

of the received prefixes should show an originating
AS number of 65531 (172.31.10.0/24,
172.31.11.0/24, and 172.31.12.0/24).
Question: What do the ?, E, and I indicators within

the AS path represent?
Answer: The ?, E, and I are origin identifiers. Recall

from the BGP discussion that the origin attribute
indicates how a route was learned (? = unknown,
E = EGP, and I = IGP). The origin identifiers were
modified using policy in this simulated environment.
By default, all routes injected into BGP by devices
running the Junos operating system use an origin of
I.
Step 2.6
Issue the run show route advertising-protocol bgp address
command, where address is the IP address value assigned to your EBGP peer.
lab@srxB-1# run show route advertising-protocol bgp address

lab@srxB-1#

Question: Is your device currently advertising the
BGP routes received from its IBGP peers to its EBGP
peer? If not, explain why.
Answer: No, as illustrated in the sample output,

your device should not currently be advertising BGP
routes to its EBGP peer. Although your device has
received BGP routes from its IBGP peers (the virtual
routers within your AS), those BGP routes are not
active because the same prefixes are also learned
through OSPF, which has a lower and more
preferred route preference (150 versus 170). The
following output illustrates the current status of
those prefixes.

lab@srxB-1# run show route 172.21/16

172.21.0.0/24 *[OSPF/150] 00:52:10, metric 0, tag 0

> to 172.20.113.10 via ge-0/0/4.113
[BGP/170] 00:34:52, localpref 100, from 192.168.1.2
AS path: I
> to 172.20.113.10 via ge-0/0/4.113
172.21.1.0/24 *[OSPF/150] 00:52:10, metric 0, tag 0
> to 172.20.113.10 via ge-0/0/4.113
AS path: I
> to 172.20.113.10 via ge-0/0/4.113
172.21.2.0/24 *[OSPF/150] 00:52:10, metric 0, tag 0
> to 172.20.113.10 via ge-0/0/4.113
AS path: I
> to 172.20.113.10 via ge-0/0/4.113

lab@srxB-1# run show route 172.22/16

172.22.0.0/24 *[OSPF/150] 18:42:57, metric 0, tag 0

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

> to 172.20.77.2 via ge-0/0/1.0
172.22.1.0/24 *[OSPF/150] 18:42:57, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
AS path: I
> to 172.20.77.2 via ge-0/0/1.0
172.22.2.0/24 *[OSPF/150] 18:42:57, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
AS path: I
> to 172.20.77.2 via ge-0/0/1.0
Step 2.7
Issue the set advertise-inactive command to override the default behavior
and advertise BGP routes that are not currently selected as active because of route
preference. Activate the configuration change by issuing the commit command.
lab@srxB-1# set advertise-inactive

lab@srxB-1# commit
commit complete
Step 2.8
Once again, issue the run show route advertising-protocol bgp
address command, where address is the IP address value assigned to your
EBGP peer, to determine whether your device is advertising BGP routes to its
external BGP peer.

172.21.0.0/24 Self I
172.21.1.0/24 Self I
172.21.2.0/24 Self I
172.22.0.0/24 Self I
172.22.1.0/24 Self I
172.22.2.0/24 Self I
Question: Is your device now advertising the BGP

routes received from its IBGP peers to its EBGP
peer?
Answer: Yes. As illustrated in the sample output,

your device should now be advertising the BGP
routes learned from the two virtual router IBGP
peers to its EBGP peer.

Step 2.9
Navigate to the [edit routing-options] hierarchy and define additional
aggregate routes that represent the remainder of the internal prefixes that are part
of your AS. (Hint: In addition to the current aggregate route, you will need to
summarize the 172.21.z.0/24, 172.22.z.0/24, 192.168.y.z/32 prefixes.)
lab@srxB-1# show aggregate
route 172.20.64.0/18;
route 172.21.0.0/22;
route 172.22.0.0/22;
route 192.168.1.0/30;
route 192.168.2.0/30;
lab@srxB-1#
Step 2.10
Navigate to the [edit policy-options] hierarchy and define a new policy
named adv-aggregates that includes two terms. Name the first term
match-aggregate-routes. It should match and accept the defined aggregate
routes. Ensure that you match the aggregate protocol. Name the second term
deny-other. It should reject all other routes.
lab@srxB-1# top edit policy-options
lab@srxB-1# edit policy-statement adv-aggregates
[edit policy-options policy-statement adv-aggregates]

lab@srxB-1# set term match-aggregate-routes from protocol aggregate

lab@srxB-1# set term match-aggregate-routes from route-filter 172.20.64.0/18
exact

exact

exact

exact

exact

lab@srxB-1# set term match-aggregate-routes then accept

lab@srxB-1# set term deny-other then reject

lab@srxB-1# show
term match-aggregate-routes {
from {
protocol aggregate;
route-filter 172.20.64.0/18 exact;
}
then accept;
}
term deny-other {
then reject;
}

lab@srxB-1#
Step 2.11
Navigate to the [edit protocols bgp] hierarchy level and apply the newly
defined policy as an export policy for the external BGP group named
my-ext-group. Activate the configuration changes using the commit command.

lab@srxB-1# set group my-ext-group export adv-aggregates

lab@srxB-1# show group my-ext-group
type external;
export adv-aggregates;

peer-as 65510;

lab@srxB-1# commit
commit complete

lab@srxB-1#
Step 2.12
Verify the effects of the newly defined and applied policy by issuing the run show
route advertising-protocol bgp address command, where address
is the IP address value assigned to your EBGP peer.

* 172.20.64.0/18 Self I
* 172.21.0.0/22 Self I
* 172.22.0.0/22 Self I
* 192.168.1.0/30 Self I
Question: Is your device advertising all of the

expected aggregate prefixes? If not, which prefix is
not being advertised?
Answer: No. At this time, only four of the five

expected prefixes are being advertised. Based on
our recent configuration efforts, we see that the
192.168.z.0/30 prefix for the loopback addresses
of the remote student device and virtual router is
not currently advertised. For the srxX-1 devices,
you should not see the 192.168.2.0/30 prefix and
for srxX-2 devices, you should not see the
192.168.1.0/30 prefix in the list of advertised
prefixes.
Step 2.13
Examine the routing table entry for the aggregate route representing the loopback
addresses for the remote side to determine why it is not being advertised into BGP.
lab@srxB-1# run show route remote-loopback/30


192.168.2.0/30 *[Static/20] 1d 03:57:26
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
[Aggregate/130] 00:29:25
Reject
192.168.2.1/32 *[OSPF/10] 20:26:30, metric 1
> to 172.20.77.2 via ge-0/0/1.0
192.168.2.2/32 *[OSPF/10] 19:21:34, metric 2
> to 172.20.77.2 via ge-0/0/1.0
Question: Based on the contents of the routing

table, can you explain why the aggregate route is
not currently advertised into BGP? How might you
remedy this situation?
Answer: As illustrated in the output, the aggregate

route is not currently active because of route
preference (the static route is more preferred). You
can do one of several things to advertise this prefix
into BGP. You can alter the route preference of the
aggregate route to be lower than the route
preference associated with the static route for the
same prefix, you can alter the policy to match on
protocol static for this route rather than the
aggregate protocol, or, because reachability for the
referenced prefix is now provided through OSPF, you
could simply deactivate or delete the current static
route. Note that other options might also exist to
remedy this situation. In the next step you decrease
the preference for the referenced prefix.
Step 2.14
Decrease the route preference for the aggregate route representing the loopback
addresses of the remote student and virtual router devices to 19. Activate the
change and issue the run show route remote-loopback/30 command to
verify that the aggregate route is now active.
lab@srxB-1# top edit routing-options aggregate
[edit routing-options aggregate]

lab@srxB-1# show
route 172.20.64.0/18;
route 172.21.0.0/22;
route 172.22.0.0/22;

route 192.168.1.0/30;
route 192.168.2.0/30;

lab@srxB-1# set route remote-loopback/30 preference 19

lab@srxB-1# show
route 172.20.64.0/18;
route 172.21.0.0/22;
route 172.22.0.0/22;
route 192.168.1.0/30;
route 192.168.2.0/30 {
preference 19;
}

lab@srxB-1# commit
commit complete

lab@srxB-1# run show route remote-loopback/30

192.168.2.0/30 *[Aggregate/19] 15:04:47

Reject
[Static/20] 4d 21:15:22
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
192.168.2.1/32 *[OSPF/10] 4d 21:07:54, metric 1
> to 172.20.77.2 via ge-0/0/1.0
192.168.2.2/32 *[OSPF/10] 4d 20:05:28, metric 2
> to 172.20.77.2 via ge-0/0/1.0

lab@srxB-1#
Question: Is the aggregated route now active?
Answer: Yes. The aggregate route should now be

active because of its lower route preference.
Step 2.15
Verify that the effects of the route preference change by issuing the run show
route advertising-protocol bgp address command, where address
is the IP address value assigned to your EBGP peer.


* 172.20.64.0/18 Self I
* 172.21.0.0/22 Self I
* 172.22.0.0/22 Self I
* 192.168.1.0/30 Self I
* 192.168.2.0/30 Self I
Question: Is your device now advertising all of the

expected aggregate prefixes?
Answer: Yes. At this time, all five aggregate prefixes

are being advertised. If you do not see all five
aggregate prefixes advertised in to BGP, check your
configuration and, if necessary, consult with the
instructor.
Question: Use the summary details of the

generated output to determine whether your device
currently has hidden routes. If so, how many?
Answer: Yes. As shown in the sample output, your

device should have one hidden route. We will
address this issue in the next lab part.
Part 3: Implementing a next-hop self Policy
In this lab part, you define and apply a next-hop self policy to alter the next-hop
value associated with routes received from your EBGP peer. You monitor the effects
of this policy.

Note
The following lab steps require you to log in
to the virtual router attached to your team’s
device. The virtual routers are logical
devices created on a J Series Services
Router. Refer to the management network
router.
Step 3.1
complete.
lab@srxB-1# top
[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
[edit]
lab@srxB-1#
Step 3.2
Open a separate Telnet session to the virtual router.
Step 3.3


srxA-1 a1 lab123
srxA-2 a2 lab123
srxB-1 b1 lab123
srxB-2 b2 lab123
srxC-1 c1 lab123
srxC-2 c2 lab123
srxD-1 d1 lab123
srxD-2 d2 lab123
vr-device (ttyp0)
login: username
Password:
--- JUNOS 11.4R1.6 built 2011-11-15 11:28:05 UTC
b1@vr-device>
Step 3.4
From your assigned virtual router, issue the show route table
vrvlan-id.inet.0 protocol bgp command, where vlan-id is the value
assigned to your virtual router.
b1@vr-device> show route table vrvlan-id.inet.0 protocol bgp
vr113.inet.0: 31 destinations, 48 routes (21 active, 0 holddown, 20 hidden)

172.22.0.0/24 [BGP/170] 1d 23:27:43, localpref 100, from 192.168.2.2

AS path: I
> to 172.20.113.1 via ge-0/0/1.113
AS path: I
> to 172.20.113.1 via ge-0/0/1.113
AS path: I
> to 172.20.113.1 via ge-0/0/1.113

Question: How many BGP routes display using the
referenced command?
Answer: The generated output should display three

BGP routes. The displayed routes will vary
depending on your assigned device, but in all cases
the output should reflect the routes advertised by
the remote virtual router within your assigned pod.
Note that the displayed routes are not currently
active because of route preference. Recall that
these same prefixes are learned through OSPF,
which has a lower and more preferred route
preference when compared to BGP.
Question: Does your virtual router currently have

hidden routes?
Answer: Yes, at this time your assigned virtual

router should show 20 hidden routes.
Step 3.5
View the hidden routes by issuing the show route table
vr11vlan-id.inet.0 hidden extensive command, where vlan-id is
the value assigned to your virtual router.
b1@vr-device> show route table vrvlan-id.inet.0 hidden extensive

0.0.0.0/0 (2 entries, 0 announced)
BGP Preference: 170/-101
Next hop type: Unusable
Local AS: 64700 Peer AS: 64700
Age: 1:52:22
Task: BGP_64700_64700.192.168.2.1+56163
AS path: 65520 I
Accepted
Localpref: 100
Router ID: 192.168.2.1
Indirect next hops: 1
Protocol next hop: 172.18.2.1
Indirect next hop: 0 -
Next hop type: Unusable

Age: 1:53:41
Task: BGP_64700_64700.192.168.1.1+56723
AS path: 65510 I
Accepted
Localpref: 100
Router ID: 192.168.1.1
Indirect next hop: 0 -
...TRIMMED...
Question: What are the protocol next-hop values

associated with these hidden routes?
Answer: As illustrated in the output, the protocol

next-hop values are 172.18.2.1 and
172.18.1.1.
Question: Why are these routes hidden?
Answer: The output indicates that the next hops

associated with these routes are unusable.
Remember that even though these routes are
received from IBGP peers, they were not originated
by those IBGP peers but rather by some other
external BGP peer. In this situation, the next-hop
value is not changed by default and requires some
administrative intervention. You can confirm that
the local virtual router does not have a route to the
protocol next hops identified earlier using the show
route table vrvlan-id.inet.0 prefix
command as shown in the following output:
b1@vr-device> show route table vrvlan-id.inet.0 172.18.1.1
b1@vr-device> show route table vrvlan-id.inet.0 172.18.2.1

Step 3.6
Return to the session opened for your assigned student device.

From the session opened for your assigned student device, navigate to the [edit
policy-options] hierarchy level. Define a policy named change-next-hop
with no terms and no defined match conditions, which alters the next-hop value to
the local device’s IP address used for peering sessions.
[edit]
lab@srxB-1# set policy-statement change-next-hop then next-hop self
lab@srxB-1#
Step 3.7
Navigate to the [edit protocols bgp] hierarchy and apply the
change-next-hop policy as an export policy to the my-int-group BGP group.
Activate the changes and return to operational mode using the commit and-quit
command.

lab@srxB-1# set group my-int-group export change-next-hop

commit complete
lab@srxB-1>
Note
previous step.
Step 3.8
Return to the Telnet session opened to the virtual router attached to your assigned
device.
From the Telnet session opened to the virtual router attached to your assigned
device, issue the show route table vrvlan-id.inet.0 protocol bgp
extensive command, where vlan-id is the value assigned to your virtual router.
b1@vr-device> show route table vrvlan-id.inet.0 protocol bgp extensive

0.0.0.0/0 (2 entries, 1 announced)
TSI:
KRT in-kernel 0.0.0.0/0 -> {indirect(262148)}
*BGP Preference: 170/-101
Next hop type: Indirect

Source: 192.168.1.1
Next hop type: Router, Next hop index: 1577
Next hop: 172.20.113.1 via ge-0/0/1.113, selected
Indirect next hop: 92fc0f0 262148
State: <Active Int Ext>
Age: 33 Metric2: 0
Task: BGP_64700_64700.192.168.1.1+56723
Announcement bits (2): 2-KRT 4-Resolve tree 1
AS path: 65510 I
Accepted
Localpref: 100
Router ID: 192.168.1.1
Indirect next hop: 92fc0f0 262148
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 172.20.113.1 via ge-0/0/1.113
192.168.1.1/32 Originating RIB: vr113.inet.0
Node path count: 1
Forwarding nexthops: 1
Nexthop: 172.20.113.1 via ge-0/0/1.113
Next hop type: Indirect
Source: 192.168.2.1
Next hop type: Router, Next hop index: 1577
Next hop: 172.20.113.1 via ge-0/0/1.113, selected
Indirect next hop: 92fc2d0 262146
State: <Int Ext>
Inactive reason: IGP metric
Age: 53 Metric2: 2
Task: BGP_64700_64700.192.168.2.1+56163
AS path: 65520 I
Accepted
Localpref: 100
Router ID: 192.168.2.1
Protocol next hop: 192.168.2.1 Metric: 2
Indirect next hop: 92fc2d0 262146
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 172.20.113.1 via ge-0/0/1.113
192.168.2.1/32 Originating RIB: vr113.inet.0
Metric: 2 Node path count: 1
Forwarding nexthops: 1
Nexthop: 172.20.113.1 via ge-0/0/1.113
...TRIMMED...

Question: What are the protocol next-hop values
associated with the displayed BGP routes?
Answer: As illustrated in the output, the protocol

next-hop values should now show 192.168.1.1
and 192.168.2.1.
Question: Are there any hidden routes present on

your assigned virtual router?
Answer: As illustrated in the output, no hidden

routes should exist at this time. If you still see
hidden routes, check your configuration and, if
necessary, work with the remote team to ensure
that they have properly implemented the
next-hop self policy. Note that the hidden
routes that were previously recorded on your
student device should no longer be hidden because
of the recently defined and applied next-hop
self policy. This point is illustrated in the following
output:
lab@srxB-1> show route hidden

Step 3.9
From the session opened to your assigned student device, log out of your assigned
device using the exit command.
lab@srxB-1> exit
srxB-1 (ttyu0)
login:

Lab 5
IP Tunneling (Detailed)
Overview
This lab demonstrates using the command-line interface (CLI) to configure and monitor a
generic routing encapsulation (GRE) tunnel.
• Configure and monitor a GRE tunnel.
• Use the defined GRE tunnel to merge two remote OSPF domains.
www.juniper.net IP Tunneling • Lab 5–1

12.a.12.1R1.9
Part 1: Configuring and Monitoring a GRE Tunnel
In this lab part, you configure and monitor a GRE tunnel. Using static routes, you
direct traffic to the remote subnets in your pod through the newly formed GRE
tunnel.
Step 1.1


Step 1.2
Step 1.3
commit command.
Lab 5–2 • IP Tunneling (Detailed) www.juniper.net

srxB-1 (ttyp0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
Step 1.4
Navigate to the [edit interfaces] hierarchy level. Next, disable the ge-0/0/1
and ge-0/0/2 interfaces. Finally, set the mtu of the ge-0/0/3 interface to 1524.
[edit]
[edit interfaces]
lab@srxB-1# set ge-0/0/1 disable
[edit interfaces]
lab@srxB-1# set ge-0/0/2 disable
[edit interfaces]
lab@srxB-1# set ge-0/0/3 mtu 1524
[edit interfaces]
lab@srxB-1#
Question: Why increase the MTU to 1524?
Answer: To encapsulate a GRE packet in an IP

packet, a GRE header and outer IP header are
added. These two headers add an additional 24
bytes of overhead to the packet. An MTU of 1524
allows for the default ethernet MTU of 1500 plus
the additional two headers.
Step 1.5
Define a new GRE interface and tunnel using the IP address assigned to the
loopback interface on your device as the source address and the IP address
assigned to the loopback interface on the remote student device as the destination
address. Use unit 0 for the logical point-to-point interface.

[edit interfaces]
lab@srxB-1# set gr-0/0/0 unit 0 family inet
[edit interfaces]
lab@srxB-1# set gr-0/0/0 unit 0 tunnel source local-loopback-address
[edit interfaces]
lab@srxB-1# set gr-0/0/0 unit 0 tunnel destination remote-loopback-address
[edit interfaces]
lab@srxB-1# show gr-0/0/0
unit 0 {
tunnel {
source 192.168.1.1;
destination 192.168.2.1;
}
family inet;
}
Step 1.6
Activate the changes and issue the run show interfaces terse gr-0/0/0
command to verify the state of the newly defined GRE interface.
[edit interfaces]
lab@srxB-1# commit
commit complete
[edit interfaces]
lab@srxB-1# run show interfaces terse gr-0/0/0
gr-0/0/0 up up
gr-0/0/0.0 up up inet
Question: What is the current state of the

gr-0/0/0.0 interface?
Answer: The gr-0/0/0.0 interface should show

sample output.
Step 1.7
Navigate to the [edit routing-options static] hierarchy and modify the
static routes for the subnets associated with the remote team to use only the newly
defined GRE interface. Ensure that you delete the current next-hop values assigned
to those static routes.
[edit interfaces]
lab@srxB-1# top edit routing-options static
[edit routing-options static]

lab@srxB-1# show

defaults {
preference 20;
}
inactive: route 0.0.0.0/0 {
next-hop 172.18.1.1;
preference 5;
}
route 192.168.1.2/32 next-hop 172.20.113.10;
route 192.168.2.0/30 next-hop [ 172.20.66.2 172.20.77.2 ];
route 172.20.114.0/24 next-hop [ 172.20.66.2 172.20.77.2 ];

lab@srxB-1# wildcard delete route remote-loopback/30 next-hop

lab@srxB-1# wildcard delete route remote-vr/24 next-hop

lab@srxB-1# set route remote-loopback/30 next-hop gr-0/0/0

lab@srxB-1# set route remote-vr/24 next-hop gr-0/0/0

lab@srxB-1# show
defaults {
preference 20;
}
next-hop 172.18.1.1;
preference 5;
}
route 192.168.1.2/32 next-hop 172.20.113.10;
route 192.168.2.0/30 next-hop gr-0/0/0.0;
route 172.20.114.0/24 next-hop gr-0/0/0.0;

lab@srxB-1#
Step 1.8
Activate the changes using commit and issue the run show interfaces
terse gr-0/0/0 command several times to monitor the state of the GRE
interface.
lab@srxB-1# commit
commit complete

gr-0/0/0 up up
gr-0/0/0.0 up down inet

gr-0/0/0 up up

gr-0/0/0 up up
Question: What is the state of the gr-0/0/0.0

interface?
Answer: The Admin state should consistently show

up but, as illustrated in the sample output, the
Link state might show up or down depending on
when the referenced command is issued.
Note
In the current state, the routing table
purges the static route for the remote
partners loopback prefix when the
gr-0/0/0.0 interface goes down. Once the
remote loopback prefix is removed from the
routing table, the remote tunnel endpoint
address is resolved through the default
BGP route received from the EBGP peer.
Once the remote tunnel endpoint address
is resolved through the default BGP route,
the gr-0/0/0.0 interface returns to the up
state and the GRE tunnel re-establishes.
When the GRE tunnel is re-established, the
static route for the remote partners
loopback prefix is added back to the
routing table, at which time the same
problem repeats. This cycle continues until
corrective action is taken. You will correct
this issue in a subsequent step.
Step 1.9
Define a new static route for the remote tunnel endpoint address (the loopback
address of the remote student device) using the local ge-0/0/3 address as the next
hop. Issue the commit command to activate the changes.

lab@srxB-1# set route remote-loopback-address next-hop local-ge-0/0/3-address

lab@srxB-1# show
defaults {
preference 20;
}
next-hop 172.18.1.1;
preference 5;
}
route 192.168.1.2/32 next-hop 172.20.113.10;
route 192.168.2.0/30 next-hop gr-0/0/0.0;
route 172.20.114.0/24 next-hop gr-0/0/0.0;
route 192.168.2.1/32 next-hop 172.18.1.1;

lab@srxB-1# commit
commit complete
Step 1.10
Issue the run show interfaces terse gr-0/0/0 command several times
to monitor the state of the GRE interface.
gr-0/0/0 up up

gr-0/0/0 up up

gr-0/0/0 up up

Answer: As shown in the sample output, the

gr-0/0/0.0 interface should now be stable and
show only Admin and Link states of up.

Step 1.11
Use the routing table to determine the next hop associated with the remote
virtual router subnet.
lab@srxB-1# run show route remote-vr/24

172.20.114.0/24 *[Static/20] 00:01:26

> via gr-0/0/0.0
Question: What is the next hop associated with the

route for the remote virtual router subnet?
Answer: As shown in the sample output, the

gr-0/0/0.0 interface should be listed as the next
hop for route associated with the remote virtual
router subnet.
Note
previous step.
Step 1.12
Use the ping utility to verify reachability to the remote virtual router. Use a
destination host address of the remote partner’s virtual router. Use a source host
address of your local ge-0/0/4 interface (172.20.11v.1). Refer to the network
diagram for this task as necessary.
lab@srxB-1# run ping remote-vr-address source local-ge-0/0/4-address
PING 172.20.114.10 (172.20.114.10): 56 data bytes
^C
--- 172.20.114.10 ping statistics ---

Question: Is the ping operation successful? What
does this ping test indicate?
Answer: As shown in the sample output, the ping

test should succeed. If the ping operation does not
succeed, check your configuration and, if
necessary, check with the remote student team to
ensure that they have completed the required
configuration tasks. A successful ping operation
indicates that the tunnel is passing traffic in both
directions. You can also issue the run show
interface gr-0/0/0.0 command to verify
interface input and output statistics:

lab@srxB-1# run show interfaces gr-0/0/0.0
Logical interface gr-0/0/0.0 (Index 75) (SNMP ifIndex 574)
Flags: Point-To-Point SNMP-Traps 0x0
IP-Header 192.168.2.1:192.168.1.1:47:df:64:0000000000000000
Encapsulation: GRE-NULL
Gre keepalives configured: Off, Gre keepalives adjacency state: up
Input packets : 6
Output packets: 6
Security: Zone: Null
Protocol inet, MTU: 1476
Flags: Sendbcast-pkt-to-re
Part 2: Configuring the GRE Interface to Participate in OSPF
In this lab part, you configure the GRE interface to participate in OSPF, thus allowing
the GRE tunnel to merge the two remote OSPF domains back to a single OSPF
domain. You will then re-enable the ge-0/0/1 and ge-0/0/2 interfaces and ensure
that the gr-0/0/0.0 interface serves as the backup link for OSPF area 0.
Step 2.1
complete.
lab@srxB-1# top
[edit]
load complete

[edit]
lab@srxB-1# commit
commit complete
[edit]
lab@srxB-1#
Step 2.2
Verify the current state of the OSPF neighbors using the run show ospf
neighbor command.
[edit]
172.20.113.10 ge-0/0/4.113 Full 192.168.1.2 128 37

assigned device currently show?
Answer: At this time, your device should have a

single OSPF neighbor: the directly attached virtual
router connected through the nonbackbone area as
defined on your assigned device.
Step 2.3
Navigate to the [edit protocols ospf] hierarchy level and add the
gr-0/0/0.0 interface under OSPF Area 0.0.0.0.
[edit]
lab@srxB-1# edit protocols ospf

lab@srxB-1# show
inactive: export inject-default-route;
area 0.0.0.0 {
interface lo0.0;
metric 100;
}
}
area 0.0.0.1 {
}

lab@srxB-1# set area 0 interface gr-0/0/0.0

lab@srxB-1# show

area 0.0.0.0 {
interface lo0.0;
metric 100;
}
interface gr-0/0/0.0;
}
area 0.0.0.1 {
}

lab@srxB-1#
Note
previous step.
Step 2.4
Activate the configuration change by issuing the commit command and then issue
the run show ospf neighbor command several times to verify that a new
OSPF neighbor was added and that the new neighbor session is stable.
lab@srxB-1# commit
commit complete

172.20.113.10 ge-0/0/4.113 Full 192.168.1.2 128 35

192.168.2.1 gr-0/0/0.0 Full 192.168.2.1 128 39
172.20.113.10 ge-0/0/4.113 Full 192.168.1.2 128 38

192.168.2.1 gr-0/0/0.0 Full 192.168.2.1 128 36
172.20.113.10 ge-0/0/4.113 Full 192.168.1.2 128 37

172.20.113.10 ge-0/0/4.113 Full 192.168.1.2 128 33

Question: Has a new neighbor been detected and, if
so, is the associated neighbor session stable?
Answer: A new neighbor is detected, but the

associated session is not currently stable. Your
output might vary from that shown in the sample
output. The following sample capture is taken from
srxB-2 for this same sample session:

172.20.114.10 ge-0/0/4.114 Full 192.168.2.2 128 39

192.168.1.1 gr-0/0/0.0 Init 192.168.1.1 128 39
172.20.114.10 ge-0/0/4.114 Full 192.168.2.2 128 37

192.168.1.1 gr-0/0/0.0 Init 192.168.1.1 128 37
172.20.114.10 ge-0/0/4.114 Full 192.168.2.2 128 34

172.20.114.10 ge-0/0/4.114 Full 192.168.2.2 128 32
Question: Based on the generated output, what is

the address of the newly detected OSPF neighbor?
Answer: The address of the newly detected OSPF

neighbor should be the loopback address of the
remote student device (also the GRE tunnel
endpoint address). If you are assigned srxX-1, the
neighbor address should be 192.168.2.1. If you are
assigned srxX-2, the neighbor address should be
192.168.1.1.

Question: Other than through the OSPF protocol,
how is your device learning the route for the
address of the remote student device’s loopback
interface?
Answer: Recall that earlier in this lab you defined a

static route for the address associated with the
loopback interface of the remote student device.
This static route uses the IP address associated
with the device connected to ge-0/0/3.0 as the
next hop. The following is a sample capture showing
this route:

lab@srxB-1# run show route remote-loopback-address

192.168.2.1/32 *[Static/20] 00:45:26

> to 172.18.1.1 via ge-0/0/3.0

Question: What is the route preference currently
assigned to the static route for the remote device’s
loopback interface address? How might the current
route preference for this route be contributing to the
unstable OSPF session?
Answer: By default, static routes assume a route

preference of 5, but in this case the defaults
hierarchy was modified in a previous lab to assign
static routes a route preference of 20 unless
otherwise specified. The output displays the current
route preference for this route. Because the
address of the remote tunnel endpoint is being
learned from a more preferred source (OSPF
internal routes have a default route preference of
10) that also happens to use the gr-0/0/0.0
interface as a next hop, the GRE tunnel drops
momentarily. Remember that the GRE tunnel
cannot rely on a route that uses the GRE interface
as a next hop. Eventually the invalid route is cleared
from the routing table, and the GRE tunnel
re-establishes. At this time, the OSPF session
rebuilds and the problem recurs. You can monitor
the GRE interface state to confirm this cycle. The
following is a sample capture, taken from srxB-1:

gr-0/0/0 up up

gr-0/0/0 up up

gr-0/0/0 up up


gr-0/0/0 up up
Step 2.5
Navigate to the [edit routing-options static] hierarchy and modify the
route preference of the static route for the remote device’s loopback interface
address to a value of 5. Activate the configuration change and return to operational
mode using the commit and-quit command.
lab@srxB-1# top edit routing-options static

lab@srxB-1# show
defaults {
preference 20;
}
next-hop 172.18.1.1;
preference 5;
}
route 192.168.1.2/32 next-hop 172.20.113.10;
route 192.168.2.0/30 next-hop gr-0/0/0.0;
route 172.20.114.0/24 next-hop gr-0/0/0.0;
route 192.168.2.1/32 next-hop 172.18.1.1;

lab@srxB-1# set route remote-loopback-address/32 preference 5

lab@srxB-1# show
defaults {
preference 20;
}
next-hop 172.18.1.1;
preference 5;
}
route 192.168.1.2/32 next-hop 172.20.113.10;
route 192.168.2.0/30 next-hop gr-0/0/0.0;
route 172.20.114.0/24 next-hop gr-0/0/0.0;
route 192.168.2.1/32 {
next-hop 172.18.1.1;
preference 5;
}

commit complete
lab@srxB-1>

Note

previous step.
Step 2.6
Issue the show route address command, where address represents the
value assigned to the loopback interface address of the remote student device.
lab@srxB-1> show route remote-loopback-address

192.168.2.1/32 *[Static/5] 00:11:47

> to 172.18.1.1 via ge-0/0/3.0
[OSPF/10] 00:11:28, metric 1
> via gr-0/0/0.0
Question: From which sources does your device

learn the referenced prefix? Which source is
selected as active and why?
Answer: Your device learns the referenced prefix

through a static route and the OSPF protocol. The
static route for this prefix should be active
(indicated by the asterisk [*]) because of a lower
route preference; the static route should now show
a preference of 5, whereas the OSPF route should
show a route preference of 10. If you see a different
result, check your configuration and, if necessary,
work with the remote team.
Step 2.7
Issue the show ospf neighbor command several times to verify that the new
OSPF neighbor has been added and that the new neighbor session is stable.
192.168.2.1 gr-0/0/0.0 Full 192.168.2.1 128 36
172.20.113.10 ge-0/0/4.113 Full 192.168.1.2 128 32

192.168.2.1 gr-0/0/0.0 Full 192.168.2.1 128 33
172.20.113.10 ge-0/0/4.113 Full 192.168.1.2 128 39

192.168.2.1 gr-0/0/0.0 Full 192.168.2.1 128 32
172.20.113.10 ge-0/0/4.113 Full 192.168.1.2 128 39

192.168.2.1 gr-0/0/0.0 Full 192.168.2.1 128 35
172.20.113.10 ge-0/0/4.113 Full 192.168.1.2 128 33

assigned device currently show? Are the detected
OSPF sessions stable?
Answer: At this time, your device should have two

OSPF neighbors: the directly attached virtual router
connected through the nonbackbone area and the
remote student device connected through the
backbone area. Both OSPF sessions should be
stable because of the recent configuration
changes.
Step 2.8
Enter configuration mode and re-enable the ge-0/0/1 and ge-0/0/2 interfaces.
Activate the changes using the commit command.
[edit]
lab@srxB-1# delete interfaces ge-0/0/1 disable
[edit]
[edit]
lab@srxB-1# commit
commit complete
[edit]
lab@srxB-1#
Step 2.9
Ensure that the remote team in your pod has finished the previous task, then issue
the run show ospf neighbors command.

[edit]
172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 34
172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 36
192.168.2.1 gr-0/0/0.0 Full 192.168.2.1 128 39
172.20.113.10 ge-0/0/4.113 Full 192.168.1.2 128 36

assigned device currently show?
Answer: Your device should have four OSPF

neighbors: one neighbor session with the directly
attached virtual router connected through the
nonbackbone area and three neighbor sessions
with the remote student device connected through
the backbone area.
Step 2.10
Add a metric value of 200 to the gr-0/0/0.0 interface under the [edit
protocols ospf area 0.0.0.0] hierarchy to ensure that the tunnel serves
as a backup path when the ge-0/0/1.0 and ge-0/0/2.0 interfaces are operational.
Activate the configuration change using the commit command.
[edit]
lab@srxB-1# set protocols ospf area 0 interface gr-0/0/0.0 metric 200
[edit]
lab@srxB-1# show protocols ospf area 0
interface lo0.0;
metric 100;
}
interface gr-0/0/0.0 {
metric 200;
}
[edit]
lab@srxB-1# commit
commit complete
Step 2.11
Issue the run show ospf route command to confirm that OSPF routes are not
currently using the gr-0/0/0.0 interface.

[edit]

192.168.1.2 Intra AS BR IP 1 ge-0/0/4.113 172.20.113.10
192.168.2.1 Intra Area BR IP 1 ge-0/0/1.0 172.20.77.2
192.168.2.2 Inter AS BR IP 2 ge-0/0/1.0 172.20.77.2
172.20.114.0/24 Inter Network IP 2 ge-0/0/1.0 172.20.77.2
172.21.0.0/24 Ext2 Network IP 0 ge-0/0/4.113 172.20.113.10
172.21.1.0/24 Ext2 Network IP 0 ge-0/0/4.113 172.20.113.10
172.21.2.0/24 Ext2 Network IP 0 ge-0/0/4.113 172.20.113.10
172.22.0.0/24 Ext2 Network IP 0 ge-0/0/1.0 172.20.77.2
172.22.1.0/24 Ext2 Network IP 0 ge-0/0/1.0 172.20.77.2
172.22.2.0/24 Ext2 Network IP 0 ge-0/0/1.0 172.20.77.2
192.168.2.2/32 Inter Network IP 2 ge-0/0/1.0 172.20.77.2
Question: Are any of the OSPF routes using

gr-0/0/0.0?
Answer: No OSPF routes should be using the

gr-0/0/0 interface at this time because of the
higher metric associated with that interface.
Step 2.12
Disable the ge-0/0/1 and ge-0/0/2 interfaces once again. Commit your changes
and issue the run show ospf route command to confirm that the remote OSPF
routes are now learned through the gr-0/0/0 interface.
[edit]
lab@srxB-1# set interfaces ge-0/0/1 disable
[edit]
lab@srxB-1# set interfaces ge-0/0/2 disable
[edit]
lab@srxB-1# commit
commit complete
[edit]

192.168.1.2 Intra AS BR IP 1 ge-0/0/4.113 172.20.113.10
192.168.2.1 Intra Area BR IP 200 gr-0/0/0.0
192.168.2.2 Inter AS BR IP 201 gr-0/0/0.0
172.20.114.0/24 Inter Network IP 201 gr-0/0/0.0
172.21.0.0/24 Ext2 Network IP 0 ge-0/0/4.113 172.20.113.10
172.21.1.0/24 Ext2 Network IP 0 ge-0/0/4.113 172.20.113.10
172.21.2.0/24 Ext2 Network IP 0 ge-0/0/4.113 172.20.113.10
172.22.0.0/24 Ext2 Network IP 0 gr-0/0/0.0
172.22.1.0/24 Ext2 Network IP 0 gr-0/0/0.0
172.22.2.0/24 Ext2 Network IP 0 gr-0/0/0.0
192.168.2.1/32 Intra Network IP 200 gr-0/0/0.0
192.168.2.2/32 Inter Network IP 201 gr-0/0/0.0
Question: Are the OSPF routes associated with the

remote side of your assigned pod using gr-0/0/0.0?
Answer: Yes. The OSPF routes associated with the

remote side of your pod should now be using the
gr-0/0/0 interface. Note that your output might vary
depending on the configuration in place on the
Step 2.13
Re-enable the ge-0/0/1 and ge-0/0/2 interfaces. Activate the configuration
changes and return to operational mode using the commit and-quit command.
[edit]
[edit]
[edit]
commit complete
Step 2.14
lab@srxB-1> exit
srxB-1 (ttyu0)
login:



Lab 6
High Availability (Detailed)
Overview
This lab demonstrates how to configure and monitor some high availability (HA) features
using the command-line interface (CLI).
• Configure and monitor graceful restart.
• Configure and monitor the Bidirectional Forwarding Detection (BFD) protocol.
• Configure and monitor the Virtual Router Redundancy Protocol (VRRP).
www.juniper.net High Availability (Detailed) • Lab 6–1

12.a.12.1R1.9
Part 1: Configuring and Monitoring Graceful Restart
In this lab part, you configure and monitor graceful restart. Before enabling graceful
restart, you perform some verification tasks using the directly attached virtual
router. You then enable graceful restart and perform the same verification tasks to
determine the impact that graceful restart can have in a network. You should refer to
the diagram for this lab part for topological details.
Step 1.1


Step 1.2
Step 1.3
commit command.
Lab 6–2 • High Availability (Detailed) www.juniper.net

srxB-1 (ttyp0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
Note
This lab part requires you to log in to the
virtual router attached to your team’s
device. Refer to the management network
router.
Step 1.4
Step 1.5


srxA-1 a1 lab123
srxA-2 a2 lab123
srxB-1 b1 lab123
srxB-2 b2 lab123
srxC-1 c1 lab123
srxC-2 c2 lab123
srxD-1 d1 lab123
srxD-2 d2 lab123
vr-device (ttyp0)
login: username
Password:
--- JUNOS 11.4R1.6 built 2011-11-15 11:28:05 UTC
b1@vr-device>
Step 1.6
Initiate a continuous ping from your assigned virtual router to the loopback address
of the remote virtual router. Refer to the network diagram for this lab part as
necessary.
Note
instance name when sourcing Internet
Control Message Protocol (ICMP) traffic
b1@vr-device> ping routing-instance vrvlan-id remote-vr-loopback

PING 192.168.2.2 (192.168.2.2): 56 data bytes
...

Step 1.7
From your assigned student device, restart the routing process while the ping
operation initiated on the directly attached virtual router continues.
lab@srxB-1> restart routing
Routing protocols process started, pid 3924
lab@srxB-1>
Step 1.8
Return to the session opened to the attached virtual router.
From the session opened to the attached virtual router, monitor the ping operation
for a moment. Next, type Ctrl + c to stop the continuous ping operation.
...TRIMMED...
4 5 00 0054 5641 0 0000 40 01 409f 172.20.117.10 192.168.2.2

4 5 00 0054 564d 0 0000 40 01 4093 172.20.117.10 192.168.2.2
...TRIMMED...

4 5 00 0054 573e 0 0000 40 01 3fa2 172.20.117.10 192.168.2.2

4 5 00 0054 5747 0 0000 40 01 3f99 172.20.117.10 192.168.2.2

^C
b1@vr-device>

Question: Did a disruption occur to the packet
forwarding operation through your assigned student
device?
Answer: As the sample output shows, you should

have seen a temporary disruption to packet
forwarding while the routing process was restarting.
Note that the summary of the ping operation should
also indicate that packet loss occurred. Your results
might vary from those shown in the sample capture.
Step 1.9
From your assigned student device, enter configuration mode and navigate to the
[edit routing-options] hierarchy level.
[edit]
lab@srxB-1#
Step 1.10
Enable graceful restart and activate the change using the commit command.
lab@srxB-1# set graceful-restart
lab@srxB-1# commit
commit complete
Note
previous step.
Step 1.11
From the session opened to the attached virtual router, initiate a continuous ping
from your assigned virtual router to the loopback address of the remote virtual
router.

Note
instance name when sourcing ICMP traffic
b1@vr-device> ping routing-instance vrvlan-id remote-vr-loopback

PING 192.168.2.2 (192.168.2.2): 56 data bytes
...
Step 1.12
From your assigned student device, issue the run restart routing command
to restart the routing process once again while the ping operation on the attached
virtual router continues.
lab@srxB-1# run restart routing
Step 1.13
From the session opened to the attached virtual router, monitor the ping operation
for a moment. Next, type Ctrl + c to stop the continuous ping operation.
...TRIMMED...
^C
Question: Did a disruption occur to the packet

forwarding operation through your assigned student
device with graceful restart enabled?
Answer: As the sample output shows, you should

not have seen any disruption to packet forwarding
while the routing process was restarting. Note that
the summary of the ping operation should indicate
0% packet loss.

Step 1.14
From your assigned student device, issue the run show bgp neighbor
address command, where address represents the value assigned to the EBGP
peer connected to your student device.
Peer: 172.18.1.1+179 AS 65510 Local: 172.18.1.2+64249 AS 64700
Type: External State: Established Flags: <ImportEval Sync>
Last Error: None
Export: [ adv-aggregates ]
Options: <Preference AdvertiseInactive GracefulRestart PeerAS Refresh>
Number of flaps: 0
BFD: disabled, down
Send state: in sync
Active prefixes: 10
Output Queue[0]: 0

Question: In the generated output, which evidence
indicates that graceful restart is enabled for this
EBGP peering session?
Answer: The output indicates that the student

router has graceful restart and helper mode
enabled for the referenced EBGP peering session.
The GracefulRestart option, shown in the list
of options, indicates that this device has the
restarting router mode capability enabled. The
network layer reachability information (NLRI) restart
details indicate that the router has the helper router
mode capability enabled.
Step 1.15
Navigate to the [edit protocols bgp] hierarchy level and disable graceful
restart for the EBGP neighbor defined under the my-ext-group BGP group.

lab@srxB-1# set group my-ext-group neighbor address graceful-restart disable

lab@srxB-1#
Step 1.16
Activate the configuration change and issue the run show bgp neighbor
address command once again, where address represents the value assigned to
the EBGP peer connected to your student device.
lab@srxB-1# commit
commit complete

Peer: 172.18.1.1+179 AS 65510 Local: 172.18.1.2+57195 AS 64700
Last Error: None
Options: <Preference AdvertiseInactive PeerAS Refresh>
Options: <GracefulRestartHelperDisabled>
Number of flaps: 0

BFD: disabled, down
Send state: in sync
Active prefixes: 10
Output Queue[0]: 0
Question: In the generated output, which evidence

indicates that graceful restart is now disabled for
this EBGP peering session?
Answer: The output indicates that the student

router has graceful restart disabled for the
referenced EBGP peering session. The lack of the
GracefulRestart option in the first Options
line indicates that the restarting router mode
capability is disabled. The second Options line
clearly indicates that graceful restart helper mode
is disabled.
Step 1.17
Re-enable graceful restart for the EBGP peering session. Issue the commit
command to activate the change.
lab@srxB-1# delete group my-ext-group neighbor address graceful-restart

lab@srxB-1# show group my-ext-group
type external;
export adv-aggregates;
peer-as 65510;

lab@srxB-1# commit
commit complete
Step 1.18
Navigate to the [edit protocols ospf] hierarchy and enable traceoptions to
track graceful restart operations for OSPF. Use a file name of trace-GR and
enable the graceful-restart flag with the detail option. Activate the
configuration changes using the commit command.

lab@srxB-1# set traceoptions file trace-GR

lab@srxB-1# set traceoptions flag graceful-restart detail

lab@srxB-1# commit
commit complete

lab@srxB-1#
Step 1.19
Issue the run restart routing command. After a moment, issue the run
show log trace-GR command to display the contents of the log file.
lab@srxB-1# run restart routing

lab@srxB-1# run show log trace-GR
Nov 11 20:17:04 trace_on: Tracing to "/var/log/trace-GR" started
Nov 11 20:17:12 trace_on: Tracing to "/var/log/trace-GR" started
Nov 11 20:17:13.382658 OSPF Restart: phase now 2
Nov 11 20:17:14.823921 OSPF Restart: sending grace lsas
Nov 11 20:17:14.827578 OSPF Restart: estimated restart duration timer triggered
Nov 11 20:17:14.827682 OSPF Restart: area 0.0.0.0 triggered restart maxwait
timer of 40 seconds
...TRIMMED...
Question: Did the restart events write to the log file?
Answer: Yes, the graceful restart events should be

written to the log file.

Part 2: Configuring and Monitoring BFD
In this lab part, you configure and monitor BFD. You should refer to the diagram for
this lab part for topological details.
Step 2.1
complete.
lab@srxB-1# top
[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
[edit]
lab@srxB-1#
Step 2.2
Issue the run show bfd session command to determine whether your student
device has any active BFD sessions.
[edit]
lab@srxB-1# run show bfd session
0 sessions, 0 clients
Cumulative transmit rate 0.0 pps, cumulative receive rate 0.0 pps
Question: Does your student device currently have

any active BFD sessions?
Answer: No. At this time no BFD sessions should be

active.
Step 2.3
Enable BFD on the interfaces participating in OSPF (except lo0.0). Use 300 ms as
the minimum transmit and receive interval value. Activate the configuration changes
using the commit command.

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

lab@srxB-1# set area 0 interface ge-0/0/1.0 bfd-liveness-detection
minimum-interval 300

lab@srxB-1# set area 0 interface ge-0/0/2.0 bfd-liveness-detection

lab@srxB-1# set area 0 interface gr-0/0/0.0 bfd-liveness-detection

lab@srxB-1# set area area interface ge-0/0/4.vlan-id bfd-liveness-detection

lab@srxB-1# show
traceoptions {
file trace-GR;
flag graceful-restart detail;
}
area 0.0.0.0 {
interface lo0.0;
bfd-liveness-detection {
minimum-interval 300;
}
}
metric 100;
}
}
interface gr-0/0/0.0 {
metric 200;
}
}
}
area 0.0.0.1 {
}
}
}

lab@srxB-1# commit
commit complete

lab@srxB-1#
Note
previous step.
Step 2.4
Issue the run show bfd session command to determine whether your student
device has any active BFD sessions.
Detect Transmit
Address State Interface Time Interval Multiplier
172.20.66.2 Up ge-0/0/2.0 0.900 0.300 3
172.20.77.2 Up ge-0/0/1.0 0.900 0.300 3
172.20.113.10 Up ge-0/0/4.113 1.200 0.400 3
192.168.2.1 Up gr-0/0/0.0 0.900 0.300 3
Question: Does your student device currently have

any active BFD sessions?
Answer: Yes. At this time, your student device

should have four active BFD sessions. If you do not
see four active sessions, check your configuration.
If necessary, work with the remote student team to
ensure that they finished the previous step.

Question: What are the current transmit intervals?
Do all of these values match the values you
defined? If not, explain why.
Answer: The current transmit intervals for all but the

BFD session formed over the tagged interface
should be 300 ms. The transmit interval for the
tagged interface (ge-0/0/4.vlan-id) shows
400 ms. Remember that, by default, BFD sessions
are adaptive, which means if the device with which
a BFD session is formed has a higher value, that
higher value is used. In this lab environment, the
directly attached virtual routers have a higher
minimum interval value defined (400 ms), which is
why this session shows the higher interval.
Question: Based on the BFD session details, how

many BFD hellos must be missed before one of the
established sessions goes down?
Answer: Based on the output, the default multiplier

is in effect, which means if three consecutive BFD
hellos are missed for any of the established
sessions, that session goes down.
Step 2.5
Issue the run show bgp neighbor address command, where address
represents the value assigned to the EBGP peer connected to your student device.
Peer: 172.18.1.1+179 AS 65510 Local: 172.18.1.2+55908 AS 64700
Last Error: None
Number of flaps: 0
BFD: disabled, down

Send state: in sync
Active prefixes: 10
Output Queue[0]: 0
Question: Does the output clearly indicate whether

BFD is enabled for this EBGP peering session?
Answer: Yes, the output shows that BFD is disabled

(BFD: disabled, down).
Step 2.6
Navigate to the [edit protocols bgp] hierarchy and enable BFD for the EBGP
peering session. Use a minimum interval value of 300 ms for this BFD session and
activate the change using the commit command.
lab@srxB-1# up 1 edit bgp

lab@srxB-1# set group my-ext-group neighbor address bfd-liveness-detection

lab@srxB-1# commit
commit complete

lab@srxB-1#

Step 2.7
Issue the run show bgp neighbor address command once again, where
address represents the value assigned to the EBGP peer connected to your
student device.
Peer: 172.18.1.1+179 AS 65510 Local: 172.18.1.2+55908 AS 64700
Last Error: None
Options: <BfdEnabled>
Number of flaps: 0
BFD: enabled, up
...TRIMMED...
Question: Does the output clearly indicate whether

BFD is enabled for this EBGP peering session?
Answer: Yes, the output shows BFD is now enabled

(BFD: enabled, up). The output also shows the
BfdEnabled option on the second Options line.
Note that you can also confirm the BFD session
using the show bfd session command as
illustrated earlier in this lab. The following capture
shows the current BFD sessions and their
respective states.
Question: What would be the effects of a firewall

filter inadvertently blocking BFD hello packets?
Answer: The BFD session would drop which, in turn,

would drop the any routing protocol sessions
configured with BFD.

Detect Transmit
Address State Interface Time Interval Multiplier
172.18.1.1 Up ge-0/0/3.0 0.900 0.300 3
172.20.66.2 Up ge-0/0/2.0 0.900 0.300 3
172.20.77.2 Up ge-0/0/1.0 0.900 0.300 3
172.20.113.10 Up ge-0/0/4.113 1.200 0.400 3
192.168.2.1 Up gr-0/0/0.0 0.900 0.300 3
Part 3: Configuring and Monitoring VRRP
In this lab part, you configure and monitor VRRP. You should refer to the diagram for
this lab part for topological details. Note that the lab diagram used for this lab part is
different than the lab diagram used for the previous parts of this lab.
Step 3.1
complete.
lab@srxB-1# top
[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
[edit]
lab@srxB-1#
Step 3.2
Navigate to the [edit interfaces ge-0/0/4] hierarchy and define two new
logical interfaces using the details provided on the network diagram for this lab part.

[edit]
lab@srxB-1# edit interfaces ge-0/0/4

lab@srxB-1# set unit vlan-id vlan-id vlan-id

lab@srxB-1# set unit vlan-id family inet address address/24

lab@srxB-1# set unit vlan-id vlan-id vlan-id

lab@srxB-1# set unit vlan-id family inet address address/24

lab@srxB-1# show
vlan-tagging;
unit 113 {
vlan-id 113;
family inet {
address 172.20.113.1/24;
}
}
unit 203 {
vlan-id 203;
family inet {
address 172.20.203.2/24;
}
}
unit 204 {
vlan-id 204;
family inet {
address 172.20.204.2/24;
}
}

lab@srxB-1#
Step 3.3
Activate the configuration change and ensure that you can ping the remote student
device and the virtual routers. Note that each of the defined subnets has an
assigned virtual router.
lab@srxB-1# commit
commit complete

lab@srxB-1# run ping address rapid
PING 172.20.203.3 (172.20.203.3): 56 data bytes
!!!!!
--- 172.20.203.3 ping statistics ---


PING 172.20.203.10 (172.20.203.10): 56 data bytes
.!!!!
--- 172.20.203.10 ping statistics ---

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

lab@srxB-1# run ping address rapid count 5
PING 172.20.204.10 (172.20.204.10): 56 data bytes
.!!!!
--- 172.20.204.10 ping statistics ---
Question: Can you ping the remote student device

and virtual routers?
Answer: You should be able to ping the remote

student device and virtual routers. If the ping tests
do not succeed, work with the remote student team.
If necessary, consult with your instructor for
assistance.
Step 3.4
Configure VRRP on the newly defined logical interfaces. Associate the new logical
interface with the lower VLAN-ID with the lower VRRP Group and the new logical
interface with the higher VLAN-ID with higher VRRP Group. Refer to the network
diagram associated with this lab part for all interface and VRRP configuration
variables for your assigned pod and device.
lab@srxB-1# edit unit vlan-id family inet address address/24
[edit interfaces ge-0/0/4 unit 203 family inet address 172.20.203.2/24]

lab@srxB-1# set vrrp-group VRRP-Group priority priority

lab@srxB-1# set vrrp-group VRRP-Group virtual-address VIP-address

lab@srxB-1# up 3


lab@srxB-1# set vrrp-group VRRP-Group priority priority

lab@srxB-1# set vrrp-group VRRP-Group virtual-address VIP-address

lab@srxB-1# up 3

lab@srxB-1# show
vlan-tagging;
unit 113 {
vlan-id 113;
family inet {
address 172.20.113.1/24;
}
}
unit 203 {
vlan-id 203;
family inet {
address 172.20.203.2/24 {
vrrp-group 12 {
virtual-address 172.20.203.1;
priority 200;
}
}
}
}
unit 204 {
vlan-id 204;
family inet {
address 172.20.204.2/24 {
vrrp-group 22 {
virtual-address 172.20.204.1;
priority 100;
}
}
}
}

lab@srxB-1#

Question: Based on the newly defined VRRP
configuration, which VRRP state should each
participating interface assume?

device, but in all cases the VRRP state is dependent
on the priority value given to each interface. The
interface assigned a priority value of 200 should
assume the master VRRP state, and the interface
assigned a priority value of 100 should assume the
backup VRRP state.
Note
previous step.
Step 3.5
Activate the configuration changes using the commit command then issue the run
show vrrp command to determine the current VRRP state for each VRRP group.
A sample output from both srxB-1 and srxB-2 follows:
lab@srxB-1# commit
commit complete

lab@srxB-1# run show vrrp
Interface State Group VR state VR Mode Timer Type Address
ge-0/0/4.203 up 12 master Active A 0.715 lcl 172.20.203.2
vip 172.20.203.1
ge-0/0/4.204 up 22 backup Active D 2.968 lcl 172.20.204.2
vip 172.20.204.1
mas 172.20.204.3
lab@srxB-2# commit
commit complete

lab@srxB-2# run show vrrp
Interface State Group VR state VR Mode Timer Type Address
ge-0/0/4.203 up 12 backup Active D 2.903 lcl 172.20.203.3
vip 172.20.203.1
mas 172.20.203.2
ge-0/0/4.204 up 22 master Active A 0.079 lcl 172.20.204.3
vip 172.20.204.1

Question: Which VRRP state has each participating
interface assumed within its respective VRRP
group?

device. In all pods, srxX-1 should be master for
group 1Z and the backup for group 2Z and srxX-2
should be the backup for group 1Z and the master
for group 2Z. This concept is illustrated in the
preceding outputs.
Step 3.6

Step 3.7

srxA-1 a1 lab123
srxA-2 a2 lab123
srxB-1 b1 lab123
srxB-2 b2 lab123
srxC-1 c1 lab123
srxC-2 c2 lab123
srxD-1 d1 lab123
srxD-2 d2 lab123
vr-device (ttyp0)
login: username
Password:
--- JUNOS 11.4R1.6 built 2011-11-15 11:28:05 UTC
b1@vr-device>
Step 3.8
From the virtual routers associated with your pod, ping the Internet host listed on the
network diagram. Note that each virtual router used in this lab part has a default
static route with the virtual IP (VIP) address associated with each respective subnet
as the gateway address.
Note
b1@vr-device> ping 172.31.15.1 routing-instance vrvlan-id count 3

PING 172.31.15.1 (172.31.15.1): 56 data bytes


b1@vr-device> ping 172.31.15.1 routing-instance vrvlan-id count 3

PING 172.31.15.1 (172.31.15.1): 56 data bytes

Question: Do the ping operations succeed?
Answer: Yes, the ping operations from each virtual

router associated with your pod to the Internet host
should succeed. If not, check your work and, if
necessary, consult with the instructor.
Step 3.9
From the virtual routers associated with your pod, ping the gateway address for each
virtual router’s respective subnet.
Note
b1@vr-device> ping VIP-address routing-instance vrvlan-id count 3

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


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


Question: Do the ping operations succeed? If not,
explain why not.
Answer: The ping operations from each virtual

router associated with your pod to their respective
gateway addresses (VRRP VIP address) should not
succeed. Remember from the classroom
discussion, unless the VIP address is owned by one
of the VRRP routers, no ICMP echo responses will
be present. You can override this default behavior
using the accept-data configuration option. We
enable this option in the next lab step.
Step 3.10
From your assigned student device, enable the accept-data configuration option
for both VRRP groups. Activate the configuration changes using the commit
command.

lab@srxB-1# set vrrp-group VRRP-Group accept-data

lab@srxB-1# up 3


lab@srxB-1# set vrrp-group VRRP-Group accept-data

lab@srxB-1# up 3

lab@srxB-1# commit
commit complete
Step 3.11
From the session opened to the attached virtual router, ping the gateway address for
each virtual router’s respective subnet once again.

Note


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


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

Question: Do the ping operations now succeed?
Answer: As shown in the previous output, the ping

operations from each virtual router to their
respective gateway address (VRRP VIP address)
should now succeed.
Step 3.12
From your assigned student device, enable the interface tracking option for the
VRRP group for which your device is currently functioning as master VRRP router.
Track the ge-0/0/3.0 interface and reduce the priority value by 101 if the tracked
interface goes down. Activate the configuration change and return to the root of the
configuration hierarchy.

Note
If you are assigned srxX-1, you should
enable interface tracking only for
vrrp-group 1z. If you are assigned
srxX-2, you should enable interface
tracking only for vrrp-group 2z.


lab@srxB-1# set vrrp-group VRRP-Group track interface ge-0/0/3.0 priority-cost
101

lab@srxB-1# commit
commit complete

lab@srxB-1# top
[edit]
lab@srxB-1#
Step 3.13
Disable the ge-0/0/3.0 interface and activate the change using the commit
command.
[edit]
lab@srxB-1# set interfaces ge-0/0/3 unit 0 disable
[edit]
lab@srxB-1# commit
commit complete
Step 3.14
Issue the run show vrrp track command to view the current interface
tracking details.
[edit]
lab@srxB-1# run show vrrp track
Track Int State Speed VRRP Int Group VR State Current prio
ge-0/0/3.0 down 0 ge-0/0/4.203 12 backup 99

Question: According to the output, what is the
current interface state of the tracked interface?
Also, what is the current VRRP state and priority
value for the associated VRRP group?
Answer: The current interface state for the tracked

interface (ge-0/0/3.0) is down. The current VRRP
state for the VRRP interface should be backup.
The current priority value should be 99, which is the
configured priority (200) minus the priority-cost
(101) for the down state of the tracked interface.
Step 3.15
Re-enable the ge-0/0/3.0 interface and activate the change by using the commit
command.
[edit]
lab@srxB-1# delete interfaces ge-0/0/3 unit 0 disable
[edit]
lab@srxB-1# commit
commit complete
Step 3.16
Verify the current status of the tracked interface and its associated VRRP group by
issuing the run show vrrp track command.
[edit]
lab@srxB-1# run show vrrp track
Track Int State Speed VRRP Int Group VR State Current prio
ge-0/0/3.0 up 1g ge-0/0/4.203 12 master 200
Question: What is the current status of the tracked

interface? Which VRRP state and priority value are
now assigned to the VRRP interface?
Answer: The current interface state for the tracked

interface (ge-0/0/3.0) is up. The current VRRP
state for the VRRP interface should now be master
and the priority value should now show the
configured priority value of 200.

Step 3.17
Reload the reset configuration by issuing the load override /var/home/
lab/jir/reset.config command. Activate the reset configuration and return
to operational mode using the commit and-quit command. Log out of all open
sessions.
[edit]
lab@srxB-1# load override jir/reset.config
load complete
[edit]
commit complete
lab@srxB-1> exit
srxB-1 (ttyu0)
login:

Lab 7
IPv6 (Optional) (Detailed)
Overview
This lab demonstrates configuration and monitoring of IP version 6 (IPv6) interfaces on
devices running the Junos operating system. In this lab, you use the command-line
interface (CLI) to configure and monitor interfaces, static routing, basic OSPF, and generic
routing encapsulation (GRE) tunnels.
• Configure and verify proper operation of IPv6 network interfaces.
• Configure and monitor static IPv6 routing.
• Configure and monitor OSPF with IPv6 interfaces.
• Configure a GRE interface to tunnel IPv6 traffic over an IP version 4 (IPv4)
network.
www.juniper.net IPv6 (Optional) (Detailed) • Lab 7–1

12.a.12.1R1.9
Part 1: Configuring and Monitoring Interfaces
In this lab part, you will configure network interfaces on your assigned device. You
will then verify that the interfaces are operational and that the system adds the
corresponding route table entries for the configured interfaces.
Note
Depending on the class, the lab equipment
used might be remote from your physical
location. The instructor will inform you as to
the nature of your access and will provide
you with the details needed to access your
assigned device.
Step 1.1


Step 1.2
Lab 7–2 • IPv6 (Optional) (Detailed) www.juniper.net

Step 1.3
commit command.
srxB-1 (ttyp0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
Step 1.4
Enable IPv6 on the router using the set security forwarding-options
family inet6 mode packet-based command. Activate the configuration
using the commit command.
[edit]
lab@srxB-1# set security forwarding-options family inet6 mode packet-based
[edit]
lab@srxB-1# commit
commit complete
[edit]
lab@srxB-1#
Step 1.5
Issue the run show route table inet6 to display the contents of the IPv6
route table.
[edit]
lab@srxB-1# run show route table inet6
[edit]
lab@srxB-1#

Question: Are any routes shown?
Answer: The output should be blank because you

have not configured any IPv6 interfaces yet. You
can display all route tables and their respective
entries using the run show route all
command, as shown in the following output:
[edit]
lab@srxB-1# run show route all

Restart Complete
10.210.35.128/26 *[Direct/0] 1w0d 06:47:51

> via ge-0/0/0.0
10.210.35.133/32 *[Local/0] 1w0d 06:47:59
__juniper_private1__.inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0

hidden)
10.0.0.1/32 *[Direct/0] 02:33:54

> via lo0.16385
10.0.0.6/32 *[Local/0] 02:33:54
Local via sp-0/0/0.16383
10.0.0.16/32 *[Direct/0] 02:33:54
> via lo0.16385
[Direct/0] 02:33:54
> via sp-0/0/0.16383
128.0.0.1/32 *[Direct/0] 02:33:54
> via lo0.16385
128.0.0.4/32 *[Direct/0] 02:33:54
> via lo0.16385
128.0.0.6/32 *[Local/0] 02:33:54
Local via sp-0/0/0.16383
128.0.1.16/32 *[Direct/0] 02:33:54
> via lo0.16385
[Direct/0] 02:33:54
> via sp-0/0/0.16383
__juniper_private2__.inet.0: 1 destinations, 1 routes (0 active, 0 holddown, 1

hidden)
127.0.0.1/32 [Direct/0] 1w0d 06:48:49

> via lo0.16384

Step 1.6
Refer to the network diagram and configure the interfaces for your assigned device.
Use logical unit 0 for all interfaces. Remember to configure the loopback
interface!
[edit]
[edit interfaces]
lab@srxB-1# set lo0 unit 0 family inet6 address address/128
[edit interfaces]
ab@srxA-1# set ge-0/0/3 unit 0 family inet6 address address/64
[edit interfaces]
lab@srxB-1# set ge-0/0/2 unit 0 family inet6 address address/64
Step 1.7
Display the interface configuration and ensure that it matches the details outlined
on the network diagram for this lab. When you are comfortable with the interface
configuration, issue the commit-and-quit command to activate the
configuration and return to operational mode.
[edit interfaces]
lab@srxB-1# show
ge-0/0/0 {
unit 0 {
family inet {
address 10.210.35.133/26;
}
}
}
ge-0/0/2 {
unit 0 {
family inet6 {
address 2001:172:20:66::1/64;
}
}
}
ge-0/0/3 {
unit 0 {
family inet6 {
address 2001:172:18:1::2/64;
}
}
}
lo0 {
unit 0 {
family inet6 {
address 2001:192:168:1::1/128;
}
}
}

[edit interfaces]
commit complete
lab@srxB-1>
Step 1.8
Issue the show interfaces terse command to verify the current state of the
recently configured interfaces.
lab@srxB-1> show interfaces terse
ge-0/0/0 up up
ge-0/0/0.0 up up inet 10.210.35.133/26
gr-0/0/0 up up
ip-0/0/0 up up
lsq-0/0/0 up up
lt-0/0/0 up up
mt-0/0/0 up up
sp-0/0/0 up up
sp-0/0/0.0 up up inet
sp-0/0/0.16383 up up inet 10.0.0.1 --> 10.0.0.16
10.0.0.6 --> 0/0
128.0.0.1 --> 128.0.1.16
128.0.0.6 --> 0/0
ge-0/0/1 up up
ge-0/0/2 up up
ge-0/0/2.0 up up inet6 2001:172:20:66::1/64
fe80::226:88ff:fee1:5482/64
ge-0/0/3 up up
ge-0/0/3.0 up up inet6 2001:172:18:1::2/64
fe80::226:88ff:fee1:5483/64
ge-0/0/4 up up
ge-0/0/5 up down
ge-0/0/6 up up
ge-0/0/7 up up
ge-0/0/8 up up
ge-0/0/9 up up
ge-0/0/10 up up
ge-0/0/11 up up
ge-0/0/12 up down
ge-0/0/13 up down
ge-0/0/14 up up
ge-0/0/15 up up
fxp2 up up
fxp2.0 up up tnp 0x1
gre up up
ipip up up
irb up up
lo0 up up
lo0.0 up up inet6 2001:192:168:1::1
fe80::226:880f:fce1:5480
lo0.16384 up up inet 127.0.0.1 --> 0/0
lo0.16385 up up inet 10.0.0.1 --> 0/0

10.0.0.16 --> 0/0
128.0.0.1 --> 0/0
128.0.1.16 --> 0/0
lo0.32768 up up
lsi up up
mtun up up
pimd up up
pime up up
pp0 up up
ppd0 up up
ppe0 up up
st0 up up
tap up up
vlan up up
Question: How many IPv6 addresses are associated

with each one of your interfaces?
Answer: All the configured interfaces now have two

IPv6 addresses. The first one is the global
IPv6 address that you manually configured. The
second one is the link local address autoconfigured
by the router using the interface's EUI-64 as
interface ID based on the MAC addresses of each
interface.
Question: How are the other addresses created on

the router?
Answer: Link-local addresses (known by their

leading fe80 in the address) are expressed in IEEE
EUI-64 format. Based on this format, you
concatenate the first 24 bits of the MAC address
with the binary value 1111111111111110
(0xFFFE) and follow it with the remaining 24 bits of
the MAC address, as shown in the following output.
lab@srxB-1> show interfaces ge-0/0/2 | match Hardware

Current address: 00:26:88:e1:54:82, Hardware address: 00:26:88:e1:54:82
lab@srxB-1> show interfaces ge-0/0/2 terse

ge-0/0/2 up up
ge-0/0/2.0 up up inet6 2001:172:20:66::1/64
fe80::226:88ff:fee1:5482/64

Step 1.9
Issue the show route table inet6 command to view the current IPv6 route
entries.
lab@srxB-1> show route table inet6
inet6.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)

2001:172:18:1::/64 *[Direct/0] 00:05:27

> via ge-0/0/3.0
2001:172:18:1::2/128
*[Local/0] 00:05:27
2001:172:20:66::/64*[Direct/0] 00:05:27
> via ge-0/0/2.0
2001:172:20:66::1/128
*[Local/0] 00:05:27
2001:192:168:1::1/128
*[Direct/0] 00:05:27
> via lo0.0
fe80::/64 *[Direct/0] 00:05:27
> via ge-0/0/2.0
[Direct/0] 00:05:27
> via ge-0/0/3.0
fe80::226:880f:fce1:5480/128
*[Direct/0] 00:05:27
> via lo0.0
fe80::226:88ff:fee1:5482/128
*[Local/0] 00:05:27
fe80::226:88ff:fee1:5483/128
*[Local/0] 00:05:27
Question: How many routes were installed for each

one of the configured interfaces?
Answer: Each physical interface on the router will

have four routes installed on the routing table: two
direct routes and two local routes for both the global
IPv6 prefix and for the link-local prefix. Direct routes
represent the network or prefix the interface is
connected to whereas the local address represents
the /128 host IPv6 address of the interface. The
loopback interface will only have two direct routes
for the /128 global and link-local address.

Question: Are any routes currently hidden?
Answer: No routes should be hidden at this time.

The summary line toward the top of the sample
output makes this lack of hidden routes evident.
Step 1.10
Use the ping utility to verify reachability to the neighboring devices connected to your
device. If needed, check with the remote student team and your instructor to ensure
that their devices have the required configuration for the interfaces. The following
sample capture shows ping tests from srxB-1 to the Internet gateway and
srxB-2, which are all directly connected:
Note
The first ping of the 25 might be lost and
show up as a “.” (period).
lab@srxB-1> ping Internet-gateway-address rapid count 25

PING6(56=40+8+8 bytes) 2001:172:18:1::2 --> 2001:172:18:1::1
!!!!!!!!!!!!!!!!!!!!!!!!!
--- 2001:172:18:1::1 ping6 statistics ---
round-trip min/avg/max/std-dev = 2.648/6.763/15.872/4.380 ms

PING6(56=40+8+8 bytes) 2001:172:20:66::1 --> 2001:172:20:66::2
!!!!!!!!!!!!!!!!!!!!!!!!!
--- 2001:172:20:66::2 ping6 statistics ---


Step 1.11
Issue the show ipv6 neighbors command.
lab@srxB-1> show ipv6 neighbors
IPv6 Address Linklayer Address State Exp Rtr Secure
Interface
2001:172:18:1::1 00:24:dc:0a:ac:15 stale 1006 yes no ge-0/
0/3.0
2001:172:20:66::2 00:26:88:e1:4f:02 stale 1054 yes no ge-0/
0/2.0
proceed.
Part 2: Configuring and Monitoring Static Routing
In this lab part, you will configure and monitor a default static IPv6 route.
Step 2.1
[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
[edit]
lab@srxB-1#
Step 2.2
Attempt to ping the Internet host referenced on the network diagram for this lab.
Note
Use Ctrl+c to stop a continuous ping

operation.
[edit]
lab@srxB-1# run ping 2001:172:31:15::1
PING6(56=40+8+8 bytes) 2001:192:168:1::1 --> 2001:172:31:15::1
ping: sendmsg: No route to host
ping6: wrote 2001:172:31:15::1 16 chars, ret=-1

^C
--- 2001:172:31:15::1 ping6 statistics ---
Question: What does the result from the ping

operation indicate?
Answer: The results from the ping operation

indicate that no route to the specified host currently
exists.
Question: Based on the network diagram, which

IP address would your device use as a next hop to
reach the Internet host?

device. For all srxX-1 devices, the next-hop
IP address would be 2001:172:18:1::1. For all
srxX-2 devices, the next-hop IP address would be
2001:172:18:2::1.
Step 2.3
Define a default static route. Use the IP address identified in the last step as the
next hop for the default static route.
[edit]
lab@srxB-1# edit routing-options rib inet6.0
[edit routing-options rib inet6.0]

lab@srxB-1# set static route ::/0 next-hop address
Step 2.4
Activate the newly added static route and return to operational mode. Issue the
show route 2001:172:31:15::1 command.
[edit routing-options rib inet6.0]
commit complete
lab@srxB-1> show route 2001:172:31:15::1

::/0 *[Static/5] 00:00:32

> to 2001:172:18:1::1 via ge-0/0/3.0

Question: Does the IPv6 address associated with
the Internet host now show a valid route entry?
Answer: Yes, at this point the default static route

should be active and all destinations that do not
have a more specific route entry, would use the
default route.
Question: What is the route preference of the

default static route?
Answer: The default static route uses the route

preference value of 5, which is the default route
preference for static routes.
Step 2.5
Issue the ping 2001:172:31:15::1 command to ping the Internet host.
Note
The Internet host should contain the
required routes to send traffic back to the
student devices.
lab@srxB-1> ping 2001:172:31:15::1

PING6(56=40+8+8 bytes) 2001:172:18:1::2 --> 2001:172:31:15::1
16 bytes from 2001:172:31:15::1, icmp_seq=0 hlim=64 time=14.330 ms
^C
--- 2001:172:31:15::1 ping6 statistics ---
Question: Does the ping operation succeed this

time?
Answer: Yes, the ping operation should now

succeed. If the ping operation does not succeed,
contact your instructor.

STOP Notify your instructor that you have finished Part 2. Before proceeding,
ensure that the remote team within your pod is ready to continue on to
Part 3.
Part 3: Configuring and Monitoring OSPF
In this lab part, you will configure and monitor an IPv6 interface in OSPF. You will
configure a single OSPF Area 0 based on the network diagram for this lab. Finally,
you will perform some verification tasks to ensure that OSPF works properly.
Step 3.1
[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
[edit]
lab@srxB-1#
Note
RIP and OSPF both require new versions to
support IPv6. These new versions are
known as RIPng and OSPFv3. No changes
are necessary for IS-IS because it supports
IPv6 natively.
Step 3.2
Define OSPF Area 0 and include the internal interface that connects to the remote
team’s device. Ensure that you also include the lo0 interface. Also, recall that only
OSPF version 3 supports IPv6. Issue the show command to view the resulting
configuration.
Note
Remember to specify the appropriate
logical interface! If the logical unit is not
specified, the Junos OS assumes a logical
unit of zero (0).
[edit]
lab@srxB-1# edit protocols ospf3

[edit protocols ospf3]


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

lab@srxB-1# show
area 0.0.0.0 {
interface lo0.0;
}
Question: With the OSPF configuration in place, how

many OSPF neighbor adjacencies should form?
Answer: Although two interfaces are present in the

configuration, only one of those interfaces is
capable of forming an OSPF neighbor adjacency.
Step 3.3
Activate the candidate configuration using the commit and-quit command to
return to operational mode. Issue the show ospf3 neighbor command to verify
OSPF neighbor adjacency state information.
Note
The OSPF adjacency state for each
neighbor is dependent on that neighbor’s
configuration. Ensure that the neighboring
team has added the required OSPF
configuration and committed the changes.
The virtual routers contain preconfigured
settings added by your instructor.

commit complete
lab@srxB-1> show ospf3 neighbor

ID Interface State Pri Dead
10.210.35.134 ge-0/0/2.0 Full 128 35
Neighbor-address fe80::226:88ff:fee1:4f02

Question: Which state do the OSPF neighbor
adjacencies show?
Answer: Although you might see some transitional

states, the state should eventually show Full. If
you do not see this state after several minutes,
check with the remote team and with your
instructor, if needed.
Question: Why does the neighbor ID show as an

IPv4 address?
Question: For ease of configuration and

management, the router-ID of OSPFv3 was kept as
a 32-bit number. The router-ID selection for OSPFv3
follows the same rules of OSPF for IPv4. According
to these rules, if you do not configure a router
identifier, the IP address of the first interface to
come online is used. In this case, the ge-0/0/0
management interface address was used.
Step 3.4
Issue the show route protocol ospf3 to view the active OSPF routes in your
device’s route table.
lab@srxB-1> show route protocol ospf3

2001:192:168:2::1/128
*[OSPF3/10] 00:01:33, metric 1
> to fe80::226:88ff:fee1:4f02 via ge-0/0/2.0
ff02::5/128 *[OSPF3/10] 00:02:22, metric 1
MultiRecv
Question: What is the ff02::5/128 address?
Answer: Much like the 224.0.05 All OSPF Routers

address for OSPF, it is the IPv6 address used to
send Hello packets to all OSPFv3 routers on a
network segment.

Part 4: Tunneling IPv6 over IPv4 Using GRE Encapsulation
In this lab part, you configure a GRE tunnel to carry IPv6 traffic over IPv4. You should
refer to the diagram for this lab part for topological details. Note that the lab diagram
used for this lab part is slightly different from the lab diagram used for the previous
parts of this lab.
Step 4.1
[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
[edit]
lab@srxB-1#
Step 4.2
First, delete the protocols and routing-options stanzas. Second, delete
interfaces ge-0/0/2, ge-0/0/3 and the loopback interface.
[edit]
lab@srxB-1# delete protocols
[edit]
lab@srxB-1# delete routing-options
[edit]
[edit interfaces]
lab@srxB-1# delete lo0
lab@srxB-1# wildcard delete "ge-0/0/[2-3]"

matched: ge-0/0/2
matched: ge-0/0/3
Delete 2 objects? [yes,no] (no) yes
[edit interfaces]
lab@srxB-1#

Step 4.3
Configure IPv4 addressing as per the lab diagram on your device’s loopback and
ge-0/0/3 interfaces. Finally, using the ge-0/0/3 address as a next-hop, configure a
static route to the remote student device’s loopback.
[edit interfaces]
lab@srxB-1# set lo0 unit 0 family inet address address/32
[edit interfaces]
[edit interfaces]
lab@srxB-1# set static route remote-loopback-address/32 next-hop address
lab@srxB-1#l
Step 4.4
Display your changes and ensure they match the details outlined on the network
diagram for this lab. When you are comfortable with the interface configuration,
issue the commit-and-quit command to activate the configuration and return to
operational mode.
lab@srxB-1# top
[edit]
lab@srxB-1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.210.35.133/26;
}
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 172.18.1.2;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
}

[edit]
lab@srxB-1# show routing-options
static {
route 192.168.2.1/32 next-hop 172.18.1.1;
}
commit complete
lab@srxB-1>
Step 4.5
At this point, you now have a basic IPv4 network. Test the reachability of the remote
student device’s loopback using the ping command. Be sure to source the ping from
your device’s loopback.
lab@srxB-1> ping remote-loopback-address source local-loopback-address rapid
PING 192.168.2.1 (192.168.2.1): 56 data bytes
!!!!!

Step 4.6
Define a new GRE interface and tunnel using the IP address assigned to the
loopback interface on your device as the source address and the IP address
assigned to the loopback interface on the remote student device as the destination
address. Use unit 0 for the logical point-to-point interface.
[edit]
[edit interfaces]
lab@srxB-1# set gr-0/0/0 unit 0 family inet
[edit interfaces]
lab@srxB-1# set gr-0/0/0 unit 0 tunnel source local-loopback-address
[edit interfaces]
lab@srxB-1# set gr-0/0/0 unit 0 tunnel destination remote-loopback-address

[edit interfaces]
lab@srxB-1# show gr-0/0/0
unit 0 {
tunnel {
source 192.168.1.1;
destination 192.168.2.1;
}
family inet;
}
Step 4.7
Activate the changes and issue the run show interfaces terse gr-0/0/0
command to verify the state of the newly defined GRE interface.
[edit interfaces]
lab@srxB-1# commit
commit complete
[edit interfaces]
gr-0/0/0 up up

Answer: The gr-0/0/0.0 interface should show

sample output.
Step 4.8
Configure an IPv6 address on your tunnel interface. Refer to the lab diagram for the
IPv6 address to use. When you are satisfied, activate your changes with the commit
command.
[edit interfaces]
lab@srxB-1# set gr-0/0/0 unit 0 family inet6 address address/64
[edit interfaces]
lab@srxB-1# commit
commit complete
Step 4.9
Verify you can reach the remote student device’s IPv6 tunnel address using the ping
command.
[edit interfaces]
lab@srxB-1# run ping remote-IPv6-address count 3
PING6(56=40+8+8 bytes) 2001:c0ff:ee:100::1 --> 2001:c0ff:ee:100::2
16 bytes from 2001:c0ff:ee:100::2, icmp_seq=0 hlim=64 time=2.830 ms

--- 2001:c0ff:ee:100::2 ping6 statistics ---

Question: How is the IPv6 traffic forwarded across

the tunnel?
Answer: When you ping the remote student device’s

IPv6 tunnel address, the router finds a direct route
in inet6 for the destination through the gr-0/0/0
interface. The router figures out that the traffic
needs to be tunneled or encapsulated using a
GRE header inside an IPv4 packet with destination
address equal to the tunnel destination address.
The tunnel destination is resolved in inet0. If a route
is found the packet is forwarded out of the proper
interface, as shown in the following outputs.
Step 4.10
Issue a run show route 2001:c0ff:ee:100::z command to show that the
IPv6 destination is, indeed, the tunnel interface.
[edit interfaces]
lab@srxB-1# run show route remote-IPv6-address

2001:c0ff:ee:100::/64
*[Direct/0] 00:31:30
> via gr-0/0/0.0
Step 4.11
Issue a run show interfaces gr-0/0/0.0 command. Note the IP-Header
line.
[edit interfaces]
lab@srxB-1# run show interfaces gr-0/0/0.0
Logical interface gr-0/0/0.0 (Index 65) (SNMP ifIndex 546)
Flags: Point-To-Point SNMP-Traps 0x0
IP-Header 192.168.2.1:192.168.1.1:47:df:64:0000000000000000
...TRIMMED...

Question: What does the IP Header line tell you?
Answer: The IP Header line tells you that, to

reach the remote student device’s IPv6 tunnel
address, the router is adding a GRE header and is
encapsulating everything into an IPv4 packet with a
source address of 192.168.1.1 and a destination
address of 192.168.2.1.
Question: What does the number 47 in the

IP Header line signify?
Answer: The number 47 denotes the IP protocol

type used by GRE.
Step 4.12
Issue a run show route address command to see how our encapsulated IPv6
packets are leaving the router, where address is the remote team’s loopback
address.
[edit interfaces]
lab@srxB-1# run show route remote-loopback-address

192.168.2.1/32 *[Static/5] 00:48:48

> to 172.18.1.1 via ge-0/0/3.0
Question: What have these outputs proven?
Answer: These outputs prove that our IPv6 packets

are being GRE encapsulated and are using the IPV4
tunnel to reach their destination.
Step 4.13
Exit configuration mode and log out of your assigned device using the exit
command.
[edit interfaces]
lab@srxB-1# exit configuration-mode

lab@srxB-1> exit
srxB-1 (ttyu0)
login:
STOP
Tell your instructor that you have completed Lab 7.

Lab 8
IS-IS (Optional) (Detailed)
Overview
This lab demonstrates configuration and monitoring of the IS-IS protocol. In this lab, you
use the command-line interface (CLI) to configure, monitor, and troubleshoot IS-IS.
• Configure and monitor a multi-level IS-IS network.
• Perform basic IS-IS troubleshooting.
www.juniper.net IS-IS (Optional) (Detailed) • Lab 8–1

12.a.12.1R1.9
Part 1: Configuring and Monitoring IS-IS
In this lab part, you configure and monitor a multi-level IS-IS network. You will first
define a router ID for your assigned device. You then configure your device to
participate in a multi-level IS-IS network and verify operations using CLI operational
mode commands.
Step 1.1


Step 1.2
Step 1.3
commit command.
Lab 8–2 • IS-IS (Optional) (Detailed) www.juniper.net

srxB-1 (ttyp0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
Step 1.4
Navigate to the [edit routing-options] hierarchy level and define the router
ID on your router using the IP address assigned to the lo0 interface as the input
value.
[edit]
lab@srxB-1# set router-id local-loopback-address
lab@srxB-1#
Step 1.5
Navigate to the [edit interfaces] hierarchy level and add family ISO and the
Network Entity Title (NET) address to the lo0 interface. Pad each octet of the router
ID with leading zeros to form the system ID portion of the NET address. For instance,
if the router’s lo0 address is 192.168.1.1, the system ID portion of the net address
will be 1921.6800.1001. The N-selector (SEL) field is 00.
lab@srxB-1# top edit interfaces
[edit interfaces]
lab@srxB-1# set lo0 unit 0 family iso address IS-IS-area.1921.6800.z001.00
[edit interfaces]
lab@srxB-1# show lo0
unit 0 {
family inet {
address 192.168.1.1/32;
}
family iso {
address 49.0001.1921.6800.1001.00;
}
}

[edit interfaces]
lab@srxB-1#
Step 1.6
Add family iso to the transit interfaces.
[edit interfaces]
lab@srxB-1# set ge-0/0/1 unit 0 family iso
[edit interfaces]
lab@srxB-1# set ge-0/0/2 unit 0 family iso
[edit interfaces]
lab@srxB-1# set ge-0/0/4 unit vlan-id family iso
Step 1.7
Navigate to the [edit protocols isis] hierarchy level and configure IS-IS
levels. Make interfaces lo0, ge-0/0/1 and ge-0/0/2 level 2 only. Refer to the
network diagram as necessary and remember to include lo0.0.
[edit interfaces]
lab@srxB-1# top edit protocols isis
[edit protocols isis]

lab@srxB-1# set interface lo0 level 1 disable

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

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

lab@srxB-1#
Note
previous step.
Step 1.8
Activate the configuration and issue the run show isis adjacency command.
lab@srxB-1# commit
commit complete

lab@srxB-1# run show isis adjacency
Interface System L State Hold (secs) SNPA
ge-0/0/1.0 srxB-2 2 Up 24 0:26:88:e1:4d:1
ge-0/0/2.0 srxB-2 2 Up 24 0:26:88:e1:4d:2

Question: Which neighbor state is shown for the
listed interfaces?
Answer: The neighbor state for the ge-0/0/1.0 and

ge-0/0/2.0 interfaces should be Up, as shown in
the previous sample output. If you do not see the
Up state for both interfaces, check your
configuration and, if necessary, work with the
Question: Which value is listed under the L (Level)

column?
Answer: The L (Level) state for ge-0/0/1.0 and

ge-0/0/2.0 should be 2 which indicates Level 2
adjacencies on these links.
Step 1.9
Issue the run show isis interface command to display IS-IS interface
details.
lab@srxB-1# run show isis interface
IS-IS interface database:
Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric
ge-0/0/1.0 2 0x3 Disabled srxB-1.03 10/10
ge-0/0/2.0 2 0x2 Disabled srxB-1.02 10/10
lo0.0 0 0x1 Disabled Passive 0/0
Question: Which interfaces are listed in the output?
Answer: The ge-0/0/1.0, ge-0/0/2.0, and lo0.0

interfaces should all be listed. The lo0 interface will
always be listed as Passive since no adjacency
can form on this interface.
Step 1.10
Issue the run show isis database command to display the IS-IS database
details.
lab@srxB-1# run show isis database
IS-IS level 1 link-state database:

LSP ID Sequence Checksum Lifetime Attributes
srxB-1.00-00 0x2 0xe1b3 1092 L1 L2 Attached
1 LSPs

srxB-1.00-00 0x3 0x21d7 1115 L1 L2
srxB-1.02-00 0x1 0xa36b 1092 L1 L2
srxB-1.03-00 0x1 0x9c71 1115 L1 L2
srxB-2.00-00 0x3 0xb62a 1113 L1 L2
4 LSPs
Question: How many link-state protocol data units

(LSPs) exist in the IS-IS database?
Answer: You should see a total of five LSPs in the

ISIS database: four in the level 2 link-state
database and one in the level 1 database. Each
link-state PDU shows its ID, remaining lifetime and
attributes. Your output might vary from the sample
output.
Step 1.11
Display routes advertised to and received from IS-IS using the run show isis
route command.
lab@srxB-1# run show isis route
IS-IS routing table Current version: L1: 3 L2: 5
IPv4/IPv6 Routes
----------------
Prefix L Version Metric Type Interface NH Via
192.168.2.1/32 2 5 10 int ge-0/0/1.0 IPV4 srxB-2
ge-0/0/2.0 IPV4 srxB-2
Note
team in your pod finishes the previous step.
Step 1.12
Issue the run show route protocol isis command to view IS-IS routes
lab@srxB-1# run show route protocol isis


192.168.2.1/32 *[IS-IS/18] 00:07:28, metric 10
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Question: Which IS-IS routes exist in the routing

table?
Answer: You should see only one IS-IS route to your

remote team’s loopback address.
Question: Why are the 172.20.66.0/30 and

172.20.77.0/30 routes not listed in the generated
output?
Answer: The 172.20.66.0/30 and 172.20.77.0/30

routes are not listed in the output for the referenced
command because they are both installed in the
routing table as direct routes. Remember that direct
routes have a route preference of zero (0), whereas
internal IS-IS routes have a default preference
of 18.
Step 1.13
Configure your device with a Level 1 adjacency to the virtual router. Refer to the
network diagram for this lab for the area and interface details. Once it is configured,
activate the configuration changes and return to operational mode.
lab@srxB-1# set interface ge-0/0/4.vlan-id level 2 disable

commit complete
lab@srxB-1>
Step 1.14
Issue the show isis adjacency command to verify the current IS-IS adjacency
details.
lab@srxB-1> show isis adjacency

ge-0/0/1.0 srxB-2 2 Up 24 0:26:88:e1:4d:1
ge-0/0/2.0 srxB-2 2 Up 21 0:26:88:e1:4d:2
ge-0/0/4.113 vr-device 1 Up 21 0:24:dc:a:ac:1
Question: How many IS-IS adjacencies exist and

what are the states of those adjacencies?
Answer: You should now see three IS-IS adjacencies

and they should each be in the Up adjacency state.
If you do not see three IS-IS adjacencies in the Up
state, check your configuration and, if necessary,
work with the instructor.
Step 1.15
Issue the show isis database command to display the current IS-IS database.
lab@srxB-1> show isis database
srxB-1.00-00 0x5 0xa6f 682 L1 L2 Attached
srxB-1.04-00 0x1 0x9793 682 L1 L2
vr-device.00-00 0xf3a 0x56eb 680 L1 L2
3 LSPs

srxB-1.00-00 0x4 0x933e 675 L1 L2
srxB-1.02-00 0x3 0x9f6d 675 L1 L2
srxB-1.03-00 0x2 0x9a72 675 L1 L2
srxB-2.00-00 0x5 0xb402 683 L1 L2
4 LSPs
Question: How many link-state protocol data units

(LSPs) exist in the IS-IS database now?
Answer: You should see a total of seven LSPs in the

ISIS database: three LSPs in the level 1 link-state
database and four in the level 2 link-state
database. Each link-state PDU shows its ID,
remaining lifetime and attributes. Your output might
vary from the sample output.

Question: Which command lists only Level 2 entries
in the IS-IS database?
Answer: You can use the show isis database

level 2 command to filter the database contents
and show only IS-IS Level 2 information. The
following is a sample of this command:
lab@srxB-1> show isis database level 2

srxB-1.00-00 0x4 0x933e 624 L1 L2
srxB-1.02-00 0x3 0x9f6d 624 L1 L2
srxB-1.03-00 0x2 0x9a72 624 L1 L2
srxB-2.00-00 0x5 0xb402 633 L1 L2
4 LSPs
Step 1.16
Enter configuration mode and navigate to [edit protocols isis]. Issue the
save /var/tmp/working-isis.config command to save the current IS-IS
configuration.
[edit]
lab@srxB-1# edit protocols isis

lab@srxB-1# save /var/tmp/working-isis.config
Wrote 18 lines of configuration to '/var/tmp/working-isis.config'
Part 2: Performing Basic IS-IS Troubleshooting
In this lab part, you perform basic IS-IS troubleshooting. First, you modify your
device’s current configuration to make it incompatible with the attached virtual
router by loading the Part 2 starting configuration. You then enable IS-IS
traceoptions to log protocol activity. Finally, you display the traceoptions log to view
the associated errors.
Step 2.1
from the/var/home/lab/jir/ directory. This file will modify your IS-IS
configuration and cause inconsistencies. Commit your configuration when complete.

lab@srxB-1# top
[edit]
load complete
[edit]
lab@srxB-1# commit
commit complete
[edit]
lab@srxB-1#
Step 2.2
Issue the run show isis adjacency command.
[edit]
lab@srxB-1# run show isis adjacency
ge-0/0/1.0 srxB-2 2 Up 24 0:26:88:e1:4d:1
ge-0/0/2.0 srxB-2 2 Up 24 0:26:88:e1:4d:2
Question: How many IS-IS adjacencies does your

assigned device currently have?
Answer: At this point, your device should have only

two adjacencies. The neighbor adjacency with the
attached virtual router should no longer be in place
because of your recent configuration change.
Step 2.3
Navigate to [edit protocols isis] and define traceoptions for IS-IS so that
IS-IS errors write to a file named trace-isis. Include the detail option with the
error flag to capture additional details for the ISIS errors. Activate the
configuration change using the commit command.
[edit]
lab@srxB-1# edit protocols isis

lab@srxB-1# set traceoptions file trace-isis

lab@srxB-1# set traceoptions flag error detail

lab@srxB-1# commit
commit complete

lab@srxB-1#
Step 2.4
Issue the run show log trace-isis command to view the contents written to
the trace-isis trace file.
lab@srxB-1## run show log trace-isis
Jun 11 22:09:19.516136 local area 49.0003
Jun 11 22:09:19.516193 remote area 49.0001 (3 bytes)
Jun 11 22:09:26.928758 ERROR: IIH from vr-device with no matching areas,
interface ge-0/0/4.113
Jun 11 22:09:26.929171 local area 49.0003
Jun 11 22:09:26.929239 remote area 49.0001 (3 bytes)
Jun 11 22:09:35.214743 ERROR: IIH from vr-device with no matching areas,
interface ge-0/0/4.113

explain the current IS-IS adjacency issue?

area mismatch obviously exists. In the previous
output, we see that the virtual router is configured
for area 49.0001 while the local device is
configured for area 49.0003.
Step 2.5
Navigate to [edit interfaces lo0 unit 0] and delete the incorrect
NET address and set the correct address. Configure IS-IS Level 1 for simple
authentication with juniper as the password.
lab@srxB-1# top edit interfaces lo0 unit 0
[edit interfaces lo0 unit 0]

lab@srxB-1# show
family inet {
address 192.168.1.1/32;
}
family iso {
address 49.0003.1921.6800.1001.00;
}

root@srxD-1# delete family iso address 49.0003.1921.6800.1001.00

root@srxD-1# set family iso address IS-IS-area.1921.6800.z001.00

root@srxD-1# top edit protocols isis

root@srxD-1# set level 1 authentication-type simple

root@srxD-1# set level 1 authentication-key juniper

root@srxD-1# commit
commit complete
Step 2.6
Issue the run clear log trace-isis command to clear the contents of the
defined trace file. Wait a minute, then issue the run show log trace-isis
command to view any new entries in the trace file.
lab@srxB-1# run clear log trace-isis

lab@srxB-1# run show log trace-isis
Jun 11 22:18:57 srxB-1 clear-log[15441]: logfile cleared
Jun 11 22:19:03.316888 ERROR: IIH from vr-device on ge-0/0/4.113 without
authentication
Jun 11 22:19:03.317629 ERROR: previous error from L1, source vr-device on ge-0/
0/4.113
authentication
0/4.113
authentication
0/4.113

explain the current IS-IS adjacency issue?

level authentication mismatch should exist.
Step 2.7
Issue the delete command and confirm the operation to delete the current IS-IS
configuration. Issue the load merge /var/tmp/working-isis.config
command to load the configuration you saved previously in this lab. Activate the
restored configuration and return to operational mode using the commit
and-quit command.

lab@srxB-1# delete
Delete everything under this level? [yes,no] (no) yes

lab@srxB-1# load merge /var/tmp/working-isis.config
load complete

commit complete
lab@srxB-1>
Step 2.8
Verify that the IS-IS adjacencies have returned to the Up state between your device
and the directly attached virtual router.
lab@srxB-1> show isis adjacency
ge-0/0/1.0 srxB-2 2 Up 24 0:26:88:e1:4d:1
ge-0/0/2.0 srxB-2 2 Up 26 0:26:88:e1:4d:2
ge-0/0/4.113 vr-device 1 Up 23 0:24:dc:a:ac:1
Question: Did the IS-IS adjacency with the directly

attached virtual router return to the Up state?
Answer: Yes, you should now see all three

adjacencies in the Up state, as shown in the
previous output.
Step 2.9
lab@srxB-1> exit
srxB-1 (ttyu0)
login:


Appendix A: Lab Diagrams

A–2 • Lab Diagrams www.juniper.net

www.juniper.net Lab Diagrams • A–3
























Jir Lab Guide PDF

Uploaded by

Copyright:

Available Formats

Jir Lab Guide PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Jir Lab Guide PDF

Uploaded by

Copyright:

Available Formats

What are some of the topics covered in the course?

What are some of the topics covered in the course?

What prerequisites are recommended before taking this course?

What prerequisites are recommended before taking this course?

Junos Intermediate Routing

Detailed Lab Guide

Worldwide Education Services

1194 North Mathilda Avenue

Course Number: EDU-JUN-JIR

Lab 2: Load Balancing and Filter-Based Forwarding (Detailed) . . . . . . . . . . . . . . . . . . . 2-1

Lab 3: Open Shortest Path First (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Lab 4: Border Gateway Protocol (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Lab 5: IP Tunneling (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Lab 6: High Availability (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Lab 7: IPv6 (Optional) (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Lab 8: IS-IS (Optional) (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

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

www.juniper.net Course Overview • v

vi • Course Overview www.juniper.net

www.juniper.net Course Agenda • vii

CLI and GUI Text

Style Description Usage Example

Courier New Console text:

Input Text Versus Output Text

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxp0,

Defined and Undefined Syntax Variables

Style Description Usage Example

viii • Document Conventions www.juniper.net

Education Services Offerings

www.juniper.net Additional Information • ix

www.juniper.net Protocol-Independent Routing (Detailed) • Lab 1–1

Part 1: Configuring and Monitoring Interfaces

Question: What is the management address

Answer: The answer varies; in the example used

Lab 1–2 • Protocol-Independent Routing (Detailed) www.juniper.net

--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

www.juniper.net Protocol-Independent Routing (Detailed) • Lab 1–3

Lab 1–4 • Protocol-Independent Routing (Detailed) www.juniper.net

www.juniper.net Protocol-Independent Routing (Detailed) • Lab 1–5

Question: What are the Admin and Link states for

Answer: The configured interfaces should all show

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

10.210.35.128/26 *[Direct/0] 00:29:18

Lab 1–6 • Protocol-Independent Routing (Detailed) www.juniper.net

Question: Does the routing table display an entry for

Answer: The answer should be yes. If necessary, you

Question: What are the route preferences for the

Answer: The Local and Direct route entries

Question: Are any routes currently hidden?

Answer: You can possibly see hidden routes

www.juniper.net Protocol-Independent Routing (Detailed) • Lab 1–7

lab@srxB-1> ping remote-ge-0/0/2-address rapid count 25

lab@srxB-1> ping remote-ge-0/0/1-address rapid count 25

lab@srxB-1> ping local-vr-device rapid count 25

Question: Are the ping tests successful?

Answer: Yes, the ping tests should be successful at

Part 2: Configuring and Monitoring Static and Aggregate Routes

Lab 1–8 • Protocol-Independent Routing (Detailed) www.juniper.net