Junos Routing Essentials: Detailed Lab Guide

Junos Routing Essentials
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-JRE
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 Routing Essentials Detailed Lab Guide, Revision 12.a
Copyright 2012, Juniper Networks, Inc.
All rights reserved. Printed in USA.
Revision History:
Revision 9.aJuly 2009
Revision 9.bOctober 2009
Revision 10.aMay 2010
Revision 10.bDecember 2010
Revision 11.aJune 2011
Revision 12.aJune 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:
Routing Fundamentals (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1

Part 1: Configuring and Monitoring Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Part 2: Configuring and Monitoring Static Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
Part 3: Configuring and Monitoring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
Lab 2:
Routing Policy (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1

Part 1: Preparing the System and Verifying Proper Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Part 2: Configuring and Monitoring Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Lab 3:
Firewall Filters (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Part 2: Configuring and Monitoring Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Lab 4:
Class of Service (Optional)(Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Part 2: Configuring Queues and Scheduler Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Part 3: Configuring Multifield Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Part 4: Verifying the Operation of the Multifield Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
Part 5: Configuring BA Rewrite Rules and Classifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Appendix A: Lab Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-1
www.juniper.net
Contents iii
iv Contents
www.juniper.net
Course Overview
This one-day course provides students with foundational routing knowledge and configuration
examples and includes an overview of general routing concepts, routing policy, and firewall filters.
Through demonstrations and hands-on labs, you will gain experience in configuring and monitoring
the Junos operating system and monitoring basic 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 operating system. This course is based on Junos OS Release 12.1R1.9.
Objectives
After successfully completing this course, you should be able to:
Explain basic routing operations and concepts.
View and describe routing and forwarding tables.
Configure and monitor static routing.
Configure and monitor OSPF.
Describe the framework for routing policy.
Explain the evaluation of routing policy.
Identify situations where you might use routing policy.
Write and apply a routing policy.
Describe the framework for firewall filters.
Explain the evaluation of firewall filters.
Identify instances where you might use firewall filters.
Write and apply a firewall filter.
Describe the operation and configuration for unicast reverse path forwarding (RPF).
Intended Audience
This course benefits individuals responsible for configuring and monitoring devices running the
Junos OS.
Course Level
The Junos Routing Essentials course is a one-day introductory course.
Prerequisites
Students should have basic networking knowledge and an understanding of the Open Systems
Interconnection (OSI) reference model and the TCP/IP protocol suite. Students should also attend
the Introduction to the Junos Operating System (IJOS) course prior to attending this class.
www.juniper.net
Course Overview v
Course Agenda
Day 1
Chapter 1:
Course Introduction
Chapter 2:
Routing Fundamentals
Lab 1: Routing Fundamentals
Chapter 3:
Routing Policy
Lab 2: Routing Policy
Chapter 4:
Firewall Filters
Lab 3: Firewall Filters
Appendix A: Class of Service

Lab 4: Class of Service (Optional)
vi Course Agenda
www.juniper.net
Document Conventions
CLI and GUI Text
Frequently throughout this course, we refer to text that appears in a command-line interface (CLI)
or a graphical user interface (GUI). To make the language of these documents easier to read, we
distinguish GUI and CLI text from chapter text according to the following table.
Style
Description
Usage Example
Franklin Gothic
Normal text.
Most of what you read in the Lab Guide

and Student Guide.
Courier New
Console text:
Screen captures
Noncommand-related
syntax
GUI text elements:

Menu names
Text field entry
commit complete
Exiting configuration mode
Select File > Open, and then click
Configuration.conf in the
Filename text box.
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.
Style
Description
Usage Example
Normal CLI
No distinguishing variant.
Physical interface:fxp0,
Enabled
Normal GUI
CLI Input
View configuration history by clicking

Configuration > History.
Text that you must enter.
lab@San_Jose> show route

Select File > Save, and type
config.ini in the Filename field.
GUI Input
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.
Style
Description
Usage Example
CLI Variable
Text where variable value is

already assigned.
policy my-peers
GUI Variable
Click my-peers in the dialog.

CLI Undefined
GUI Undefined
www.juniper.net
Text where the variables value

is the users discretion and text
where the variables value as
shown in the lab guide might
differ from the value the user
must input.
Type set policy policy-name.

ping 10.0.x.y
Select File > Save, and type
filename in the Filename field.
Document Conventions vii
Additional Information
Education Services Offerings
You can obtain information on the latest Education Services offerings, course dates, and class
locations from the World Wide Web by pointing your Web browser to:
http://www.juniper.net/training/education/.
About This Publication

The Junos Routing Essentials 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).
viii Additional Information
www.juniper.net
Lab 1
Routing Fundamentals (Detailed)
Overview
This lab demonstrates configuration and monitoring of Layer 3 routing on devices running
the Junos operating system. In this lab, you use the command-line interface (CLI) to
configure and monitor interfaces, static routing, and basic OSPF. Throughout these
configuration tasks, you will become familiar with and describe the contents of the routing
and forwarding tables.
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:
www.juniper.net
Configure and verify proper operation of network interfaces.
Configure and monitor static routing.
Configure and monitor OSPF.
Routing Fundamentals (Detailed) Lab 11

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
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
srxA-1 station, which uses an IP address of
10.210.14.131. 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 teams station. The following example uses a simple Telnet
access to srxA-1 with the Secure CRT program as a basis:
Lab 12 Routing Fundamentals (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/jre/lab1-start.config
command. After the configuration has been loaded, commit the changes and return
to operational mode using the commit and-quit command.
srxA-1 (ttyp0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC
lab@srxA-1> configure
Entering configuration mode
[edit]
lab@srxA-1# load override jre/lab1-start.config
load complete
[edit]
lab@srxA-1# commit and-quit
commit complete
lab@srxA-1>
Step 1.4
Issue the show route command to display the contents of the route table.
lab@srxA-1> show route
inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.210.14.128/27
10.210.14.131/32
*[Direct/0] 23:39:24
> via ge-0/0/0.0
*[Local/0] 23:39:31
Local via ge-0/0/0.0
Question: Which route table is displayed with the

show route command?
Answer: The output should show the inet.0 route

table, which is the primary IPv4 route table for the
master routing instance. You can display all route
tables and their respective entries using the show
route all command, as shown in the following
output:
www.juniper.net
lab@srxA-1> show route all

10.210.14.128/27
10.210.14.131/32
*[Direct/0] 00:07:26
> via ge-0/0/0.0
*[Local/0] 00:07:40
__juniper_private1__.inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0

hidden)
10.0.0.1/32
10.0.0.6/32
10.0.0.16/32
128.0.0.1/32
128.0.0.4/32
128.0.0.6/32
128.0.1.16/32
*[Direct/0] 00:08:16
> via lo0.16385
*[Local/0] 00:07:39
Local via sp-0/0/0.16383
*[Direct/0] 00:08:16
> via lo0.16385
[Direct/0] 00:07:33
> via sp-0/0/0.16383
*[Direct/0] 00:08:16
> via lo0.16385
*[Direct/0] 00:08:16
> via lo0.16385
*[Local/0] 00:07:39
Local via sp-0/0/0.16383
*[Direct/0] 00:08:16
> via lo0.16385
[Direct/0] 00:07:33
> 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] 00:08:16
> via lo0.16384
Question: Which route entries are present in the

inet.0 route table?
Answer: The inet.0 route table should currently

show a single Direct route and a single Local
route. Both routes are associated with the ge-0/0/0
interface. The Direct route matches the IP
address assigned to the ge-0/0/0 interface while
the Local route matches the management
network.
www.juniper.net
Step 1.5
Enter configuration mode and navigate to the [edit interfaces] hierarchy
level.
[edit]
lab@srxA-1# edit interfaces
[edit interfaces]
lab@srxA-1#
Step 1.6
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 interfaces]
lab@srxA-1# set lo0 unit 0 family inet address address/32
[edit interfaces]
lab@srxA-1# set ge-0/0/3 unit 0 family inet address address/30
[edit interfaces]
[edit interfaces]
[edit interfaces]
lab@srxA-1# set ge-0/0/4 vlan-tagging
[edit interfaces]
lab@srxA-1# set ge-0/0/4 unit vlan-id vlan-id vlan-id
[edit interfaces]
lab@srxA-1# set ge-0/0/4 unit vlan-id family inet address address/24
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@srxA-1# show
ge-0/0/0 {
description "MGMT Interface - DO NOT DELETE";
unit 0 {
family inet {
address 10.210.14.131/27;
}
}
www.juniper.net
}
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 101 {
vlan-id 101;
family inet {
address 172.20.101.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
}
[edit interfaces]
commit complete
lab@srxA-1>
Step 1.8
Issue the show interfaces terse command to verify the current state of the
recently configured interfaces.
lab@srxA-1> show interfaces terse
Interface
Admin Link Proto
ge-0/0/0
up
up
ge-0/0/0.0
up
up
inet
gr-0/0/0
up
up
Local
Remote
10.210.14.131/27
www.juniper.net
ip-0/0/0
lsq-0/0/0
lt-0/0/0
mt-0/0/0
pd-0/0/0
pe-0/0/0
ge-0/0/1
ge-0/0/1.0
ge-0/0/2
ge-0/0/2.0
ge-0/0/3
ge-0/0/3.0
ge-0/0/4
ge-0/0/4.101
ge-0/0/4.32767
ge-0/0/5
ge-0/0/6
ge-0/0/7
ge-0/0/8
ge-0/0/9
ge-0/0/10
ge-0/0/11
ge-0/0/12
ge-0/0/13
ge-0/0/14
ge-0/0/15
gre
ipip
lo0
lo0.0
lo0.16384
lo0.16385
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
down
down
down
down
down
down
down
down
down
down
down
up
up
up
up
up
up
lo0.32768
lsi
mtun
pimd
pime
pp0
st0
tap
vlan
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
inet
172.20.77.1/30
inet
172.20.66.1/30
inet
172.18.1.2/30
inet
172.20.101.1/24
inet
inet
inet
192.168.1.1
--> 0/0
127.0.0.1
--> 0/0
10.0.0.1
--> 0/0
10.0.0.16
--> 0/0
128.0.0.1
--> 0/0
128.0.1.16
--> 0/0
fe80::226:88ff:fe02:6700
inet6
www.juniper.net
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.9
Issue the show route command to view the current route entries.
10.210.14.128/27
10.210.14.131/32
172.18.1.0/30
172.18.1.2/32
172.20.66.0/30
172.20.66.1/32
172.20.77.0/30
172.20.77.1/32
172.20.101.0/24
172.20.101.1/32
192.168.1.1/32
*[Direct/0] 02:17:46
> via ge-0/0/0.0
*[Local/0] 02:17:50
*[Direct/0] 00:02:03
> via ge-0/0/3.0
*[Local/0] 00:02:03
*[Direct/0] 00:02:03
> via ge-0/0/2.0
*[Local/0] 00:02:03
*[Direct/0] 00:02:03
> via ge-0/0/1.0
*[Local/0] 00:02:03
*[Direct/0] 00:02:03
> via ge-0/0/4.101
*[Local/0] 00:02:03
*[Direct/0] 00:02:03
> via lo0.0
Question: Does the route table display an entry for

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

can refer back to the network diagram and compare
it with the displayed route entries.
www.juniper.net
Question: What is the route preference 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: No routes should be hidden at this time.

The summary line towards 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 srxA-1 to the Internet gateway, srxA-2,
and vr101, which are all directly connected:
lab@srxA-1> ping 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
PING 172.20.66.2 (172.20.66.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
PING 172.20.77.2 (172.20.77.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
PING 172.20.101.10 (172.20.101.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
www.juniper.net
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 Routing

In this lab part, you will configure and monitor static routing.
Step 2.1
Enter configuration mode and load the lab1-part2-start.config file from
the/var/home/lab/jre/ directory. Commit your configuration when complete.
[edit]
lab@srxA-1# load override jre/lab1-part2-start.config
load complete
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-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@srxA-1# run ping 172.31.15.1
PING 172.31.15.1 (172.31.15.1): 56 data bytes
ping: sendto: No route to host
^C
www.juniper.net
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?
Answer: The answer depends on your assigned

device. For all Team 1 devices, the next-hop
IP address would be 172.18.1.1. For all Team 2
devices, the next-hop IP address would be
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. Commit the configuration when complete.
[edit]
lab@srxA-1# edit routing-options
[edit routing-options]
lab@srxA-1# set static route 0/0 next-hop address
[edit]
lab@srxA-1# commit
commit complete
lab@srxA-1#
Step 2.4
Issue the run show route 172.31.15.1 command.
lab@srxA-1# run show route 172.31.15.1
0.0.0.0/0
www.juniper.net
*[Static/5] 00:00:23
> to 172.18.1.1 via ge-0/0/3.0
Question: Does the IP 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 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@srxA-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=5.446 ms
^C
www.juniper.net
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.
Note
Refer to the network diagram, as needed,

for the subsequent lab steps.
Step 2.6
Add a static route to the loopback address of the directly attached virtual router.
lab@srxA-1# set static route address/32 next-hop address
Step 2.7
Define the required static routes to allow end-to-end connectivity to the remote
teams subnet and loopback addresses. Use the IP address assigned to the remote
student device on the 172.20.66.0/30 subnet as the next hop for these static
routes.
lab@srxA-1# show
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
route 192.168.1.2/32 next-hop 172.20.101.10;
route 192.168.2.1/32 next-hop 172.20.66.2;
route 192.168.2.2/32 next-hop 172.20.66.2;
route 172.20.102.0/24 next-hop 172.20.66.2;
}
Step 2.8
Use the IP address assigned to the remote student device on the 172.20.77.0/30
subnet as a qualified next hop for the recently added static routes to the remote
subnet and loopback addresses. Use a route preference of 6 for these definitions.
View the configuration, and when satisfied commit your configuration and return to
operational mode.
lab@srxA-1# set static route address/32 qualified-next-hop address preference 6
www.juniper.net
lab@srxA-1# show
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
route 192.168.1.2/32 next-hop 172.20.101.10;
route 192.168.2.1/32 {
next-hop 172.20.66.2;
qualified-next-hop 172.20.77.2 {
preference 6;
}
}
route 192.168.2.2/32 {
next-hop 172.20.66.2;
preference 6;
}
}
route 172.20.102.0/24 {
next-hop 172.20.66.2;
preference 6;
}
}
}
commit complete
lab@srxA-1>
Step 2.9
Issue the show route protocol static command to view the current static
routes in your devices route table.
lab@srxA-1> show route protocol static
0.0.0.0/0
172.20.102.0/24
192.168.1.2/32
*[Static/5] 00:11:06
> to 172.18.1.1 via ge-0/0/3.0
*[Static/5] 00:00:44
> to 172.20.66.2 via ge-0/0/2.0
[Static/6] 00:00:44
> to 172.20.77.2 via ge-0/0/1.0
*[Static/5] 00:00:44
www.juniper.net
192.168.2.1/32
192.168.2.2/32
> to 172.20.101.10 via ge-0/0/4.101

*[Static/5] 00:00:44
> to 172.20.66.2 via ge-0/0/2.0
[Static/6] 00:00:44
> to 172.20.77.2 via ge-0/0/1.0
*[Static/5] 00:00:44
> to 172.20.66.2 via ge-0/0/2.0
[Static/6] 00:00:44
> to 172.20.77.2 via ge-0/0/1.0
Question: How many static routes display?
Answer: Each student device should show five static

routes. If not, check your configuration and contact
your instructor.
Question: Are both next hops displayed for the
remote subnet and loopback destinations? Which
next hop is active? Why?
Answer: You should see both next hops associated

with the remote subnet and loopback destinations.
The routes using the next hop associated with the
10.210.66.0/30 subnet should be active due to a
lower route preference of 5.
Step 2.10
Ping the loopback address of all internal devices to verify reachability.
Note
The virtual routers have a preconfigured

default static route using their directly
connected student devices as the next hop.
PING 192.168.1.2 (192.168.1.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
PING 192.168.2.1 (192.168.2.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
www.juniper.net

PING 192.168.2.2 (192.168.2.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
Question: Did the ping tests succeed?
Answer: The ping tests should succeed as long as

the remote team has the required configuration in
place. If the tests fail, check with the remote team
to ensure that they have completed the required
configuration.
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 OSPF. You will configure a single OSPF
area 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@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
www.juniper.net
Step 3.2
Navigate to the [edit protocols ospf] hierarchy level and define OSPF
Area 0 and include all internal interfaces that connect to the remote teams device
and the directly connected virtual router. Ensure that you also include the
lo0 interface. 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@srxA-1# edit protocols ospf
[edit protocols ospf]
lab@srxA-1# set area 0 interface ge-0/0/1.0
lab@srxA-1# set area 0 interface ge-0/0/2.0
lab@srxA-1# set area 0 interface ge-0/0/4.vlan-id
lab@srxA-1# set area 0 interface lo0.0
lab@srxA-1# show
area 0.0.0.0 {
interface ge-0/0/1.0;
interface lo0.0;
}
Question: With the OSPF configuration in place, how

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

configuration, only three of those interfaces are
capable of forming OSPF neighbor adjacencies.
www.juniper.net
Step 3.3
Activate the candidate configuration using the commit command. Issue the run
show ospf neighbor command to verify OSPF neighbor adjacency state
information.
Note
The OSPF adjacency state for each

neighbor is dependent on that neighbors
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.
lab@srxA-1# commit
commit complete
lab@srxA-1# run show ospf neighbor
Address
Interface
172.20.77.2
ge-0/0/1.0
172.20.66.2
ge-0/0/2.0
172.20.101.10
ge-0/0/4.101
State
Full
Full
Full
ID
192.168.2.1
192.168.2.1
192.168.1.2
Pri
128
128
128
Dead
37
37
39
Question: Which state do the OSPF neighbor

adjacencies show?
Answer: Although you might see some transitional

states, the state for all three OSPF neighbors 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.
Step 3.4
Issue the run show route protocol ospf to view the active OSPF routes in
your devices route table.
lab@srxA-1# run show route protocol ospf
172.20.102.0/24
192.168.1.2/32
192.168.2.1/32
[OSPF/10] 00:01:33, metric 2

to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
[OSPF/10] 00:02:14, metric 1
> to 172.20.101.10 via ge-0/0/4.101
[OSPF/10] 00:01:33, metric 1
to 172.20.77.2 via ge-0/0/1.0
www.juniper.net
192.168.2.2/32
224.0.0.5/32
> to 172.20.66.2 via ge-0/0/2.0

[OSPF/10] 00:01:33, metric 2
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 00:02:24, metric 1
MultiRecv
Question: Are all of the OSPF routes for the remote

subnet and loopback destinations active? Why?
Answer: No, all of the OSPF routes for the remote

subnet and loopback destinations should not be
active (Note the * is missing on most of the OSPF
routes). As you might remember, we still have the
previously defined static routes in place. The active
static routes use a route preference of 5, which
makes them more preferred than OSPF routes.
Internal OSPF routes use a route preference of 10,
by default.
Step 3.5
Delete all static routes used for internal connectivity. Ensure that you do not delete
the default static route used to route traffic to the Internet.
lab@srxA-1# top edit routing-options
lab@srxA-1# show
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
route 192.168.1.2/32 next-hop 172.20.101.10;
route 192.168.2.1/32 {
next-hop 172.20.66.2;
preference 6;
}
}
route 192.168.2.2/32 {
next-hop 172.20.66.2;
preference 6;
}
}
route 172.20.102.0/24 {
next-hop 172.20.66.2;
preference 6;
}
}
}
www.juniper.net
lab@srxA-1# delete static route address/32
lab@srxA-1# show
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
}
Step 3.6
Activate the configuration and return to operational mode. Issue the
show route protocol ospf command to verify that the OSPF routes are now
active.
commit complete
lab@srxA-1> show route protocol ospf
172.20.102.0/24
192.168.1.2/32
192.168.2.1/32
192.168.2.2/32
224.0.0.5/32
*[OSPF/10] 00:07:13, metric 2

to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 00:07:54, metric 1
> to 172.20.101.10 via ge-0/0/4.101
*[OSPF/10] 00:07:13, metric 1
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 00:07:13, metric 2
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 00:08:04, metric 1
MultiRecv
lab@srxA-1>
www.juniper.net
Question: Are all of the OSPF routes for the remote

subnet and loopback destinations active now?
Answer: Yes, as illustrated in the sample output, all

OSPF routes should now be active. (Note the * is
now present for all of the OSPF routes.)
Step 3.7
Ping the loopback address of all internal devices to verify reachability through the
OSPF routes.
PING 192.168.1.2 (192.168.1.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
PING 192.168.2.1 (192.168.2.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
PING 192.168.2.2 (192.168.2.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
lab@srxA-1>
Question: Do the ping tests succeed?
Answer: Yes, as illustrated in the sample capture,

the ping tests succeed compliments of the current
OSPF routes in your devices route table.
Step 3.8
Log out of your assigned device using the exit command.
lab@srxA-1> exit
srxA-1 (ttyu0)
login:
www.juniper.net
STOP
Tell your instructor that you have completed Lab 1.
www.juniper.net
Lab 2
Routing Policy (Detailed)
Overview
This lab demonstrates configuration and monitoring of routing policy on devices running
define, apply, and monitor basic routing policy.
www.juniper.net
Prepare your device and verify operation.
Configure and monitor routing policy.
Routing Policy (Detailed) Lab 21

12.a.12.1R1.9
Part 1: Preparing the System and Verifying Proper Operation

As part of a team, you will make some modifications to the configuration and verify
proper operation. In this lab part, you must refer to the network diagram for Lab 2.
Step 1.1

Step 1.2
Step 1.3
Note that both the name and password are case-sensitive. Enter configuration mode
and load the reset configuration file using the load override /var/home/
lab/jre/lab2-start.config command. After the configuration has been
loaded, commit the changes.
srxA-1 (ttyp0)
login: lab
Password:
Lab 22 Routing Policy (Detailed)
www.juniper.net
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

[edit]
load complete
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Step 1.4
Navigate to the [edit protocols ospf] hierarchy level, delete the tagged
interface from the OSPF configuration and activate the configuration change. If
needed, refer to the network diagram for this lab to identify the tagged interface.
[edit]
lab@srxA-1# edit protocols ospf
lab@srxA-1# show
area 0.0.0.0 {
interface lo0.0;
}
lab@srxA-1# delete area 0 interface ge-0/0/4.vlan-id
lab@srxA-1# commit
commit complete
Step 1.5
Navigate to the [edit routing-options] hierarchy level. Define a static route
for each of the three subnets connected to the virtual router attached to your teams
device. Use the local virtual router as the next-hop. Refer to the network diagram for
the destination subnet and next-hop information.
lab@srxA-1# top edit routing-options
www.juniper.net
lab@srxA-1#
Step 1.6
Issue the show command to display the resulting configuration. Once satisfied with
your configuration, activate the changes and return to operational mode using the
commit and-quit command.
lab@srxA-1# show
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
route 172.21.0.0/24 next-hop 172.20.101.10;
route 172.21.1.0/24 next-hop 172.20.101.10;
route 172.21.2.0/24 next-hop 172.20.101.10;
}
commit complete
lab@srxA-1>
Step 1.7
Issue the show route protocol static command to display the current
static route entries.
lab@srxA-1> show route protocol static
0.0.0.0/0
172.21.0.0/24
172.21.1.0/24
172.21.2.0/24
*[Static/5] 01:30:15
> to 172.18.1.1 via ge-0/0/3.0
*[Static/5] 00:00:21
> to 172.20.101.10 via ge-0/0/4.101
*[Static/5] 00:00:21
> to 172.20.101.10 via ge-0/0/4.101
*[Static/5] 00:00:21
> to 172.20.101.10 via ge-0/0/4.101
Question: Are all static route entries active?
Answer: The answer should be yes. As displayed in

the sample capture, the default static route and the
three newly defined static routes should all be
active. If you do not see four active static routes,
check your configuration.
www.juniper.net
Step 1.8
Use the ping utility to verify reachability to the subnets connected to the local
virtual router.
PING 172.21.0.1 (172.21.0.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
PING 172.21.1.1 (172.21.1.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
PING 172.21.2.1 (172.21.2.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
Answer: Yes, as displayed in the sample capture,

the ping tests to all three remote destination
IP addresses should succeed.
Step 1.9
Issue the show ospf neighbor command to display the current OSPF neighbor
adjacencies on your device.
lab@srxA-1> show ospf neighbor
Address
Interface
172.20.77.2
ge-0/0/1.0
172.20.66.2
ge-0/0/2.0
www.juniper.net
State
Full
Full
ID
192.168.2.1
192.168.2.1
Pri
128
128
Dead
39
32
Question: How many OSPF adjacencies exist? What

is the current state of the OSPF neighbor
adjacencies?
Answer: Your system should show two OSPF

neighbor adjacencies with the remote student
device. The state should be Full for both OSPF
neighbor adjacencies, as shown in the sample
capture.
STOP
Wait for your instructor before you proceed to the next part.
Part 2: Configuring and Monitoring Routing Policy

In this lab part, you will configure and monitor routing policy. First, you will create a
routing policy designed to advertise routes in to OSPF. Next, you will apply the routing
policy as an export policy under the [edit protocols ospf] hierarchy level.
You will then use operational mode commands to verify that the policy is working
properly. Note that Junos routing policy is extremely flexible. Because of this
flexibility, you can generally accomplish the same objective in multiple ways. The
example configurations provided in the detailed lab guide illustrate one way of
accomplishing the stated tasks. Your configuration might vary.
Step 2.1
[edit]
load complete
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Step 2.2
Navigate to the [edit policy-options] hierarchy level.Create a new policy
named default-route that matches and accepts the existing default static
route. Name the term match-default-static-route.
www.juniper.net
[edit]
lab@srxA-1# edit policy-options
[edit policy-options]
lab@srxA-1# edit policy-statement default-route
[edit policy-options policy-statement default-route]
lab@srxA-1# set term match-default-static-route from protocol static
lab@srxA-1# set term match-default-static-route from route-filter 0/0 exact
lab@srxA-1# set term match-default-static-route then accept
lab@srxA-1#
Step 2.3
Navigate to the [edit protocols ospf] hierarchy level and apply the recently
defined policy as an OSPF export policy. Activate the configuration change.
lab@srxA-1# top edit protocols ospf
lab@srxA-1# set export default-route
lab@srxA-1# commit
commit complete
lab@srxA-1#
Note
The next lab step requires coordination

between student teams in the same
environment. Ensure that the remote team
finishes the previous step before
proceeding.
Step 2.4
Issue the run show route 0/0 exact command to verify that your device now
shows a default OSPF route in the routing table. Check with the remote team to
ensure that they also see a default OSPF route in their devices routing table.
lab@srxA-1# run show route 0/0 exact
www.juniper.net
0.0.0.0/0
*[Static/5] 00:35:18
> to 172.18.1.1 via ge-0/0/3.0
[OSPF/150] 00:22:53, metric 0, tag 0
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
Question: Does your device show a default OSPF

route in the route table?
Answer: Both student devices should now show a

default OSPF route. If you do not see a default OSPF
route, check with the remote team to ensure that
they have properly defined and applied the required
policy.
Question: Is the default OSPF route active? Why?
Answer: As shown in the sample capture, the

default OSPF route is not active due to its higher
preference. Because policy injected the route into
OSPF, this route is considered an external OSPF
route. As you might remember, OSPF external routes
use a default preference of 150 whereas internal
OSPF routes use a default preference of 10.
Question: Based on the current default route entry,
what would happen if your devices physical
connection to the Internet failed?
Answer: The current design provides redundancy for

this failure scenario. If the physical connection to
the Internet fails, your device marks the OSPF
default route as active and begins forwarding
Internet-bound traffic to the remote student device.
Step 2.5
Navigate to the [edit policy-options] hierarchy level. Define a new policy
named interface-routes that matches and accepts the networks associated
with your devices interfaces that connect to the Internet and to the directly attached
virtual router. Name the term match-interface-routes.
lab@srxA-1# top edit policy-options
www.juniper.net
lab@srxA-1# edit policy-statement interface-routes
[edit policy-options policy-statement interface-routes]
lab@srxA-1# set term match-interface-routes from route-filter address/30 exact
lab@srxA-1# set term match-interface-routes then accept
lab@srxA-1# show
term match-interface-routes {
from {
route-filter 172.18.1.0/30 exact;
}
then accept;
}
lab@srxA-1#
Step 2.6
Navigate to the [edit protocols ospf] hierarchy level and apply the
interface-routes policy as an OSPF export policy. Activate the configuration
change.
lab@srxA-1# set export interface-routes
lab@srxA-1# commit
commit complete
lab@srxA-1#
Note

proceeding.
www.juniper.net
Step 2.7
Issue the run show route protocol ospf command. Verify that your device
shows the OSPF external routes associated with the interfaces of the remote
student device. Check with the remote team to ensure that they also see the proper
OSPF routes in their devices routing table.
0.0.0.0/0
172.18.2.0/30
172.20.102.0/24
192.168.2.1/32
224.0.0.5/32
[OSPF/150] 00:08:09, metric 0, tag 0

to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:01:04, metric 0, tag 0
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:01:04, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 00:38:29, metric 1
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 00:39:20, metric 1
MultiRecv
Question: Does your device show the expected

OSPF routes in the route table?
Answer: Both student devices should now show the

expected OSPF routes. If you do not see the
expected OSPF routes, check with the remote team
to ensure that they have properly defined and
applied the required policy.
Step 2.8
Navigate to the [edit policy-options] hierarchy level. Define a third policy
named other-static-routes that matches and accepts the three recently
defined static routes that include destination subnets attached to the virtual router
connected to your device. Name the term match-other-static-routes.
lab@srxA-1# edit policy-statement other-static-routes
[edit policy-options policy-statement other-static-routes]
lab@srxA-1# set term match-other-static-routes from protocol static
www.juniper.net

lab@srxA-1# set term match-other-static-routes from route-filter address/24
exact
exact
exact
lab@srxA-1# set term match-other-static-routes then accept
lab@srxA-1# show
term match-other-static-routes {
from {
protocol static;
}
then accept;
}
lab@srxA-1#
Step 2.9
Navigate to the [edit protocols ospf] hierarchy level and apply the
other-static-routes policy as an OSPF export policy. Activate the
configuration change.
lab@srxA-1# set export other-static-routes
lab@srxA-1# commit
commit complete
lab@srxA-1#
Note

proceeding.
www.juniper.net
Step 2.10
shows the OSPF external routes associated with the static routes defined on the
remote student device. Check with the remote team to ensure that they also see the
proper OSPF routes in their devices routing table.
0.0.0.0/0
172.18.2.0/30
172.20.102.0/24
172.22.0.0/24
172.22.1.0/24
172.22.2.0/24
192.168.2.1/32
224.0.0.5/32
[OSPF/150] 01:13:36, metric 0, tag

to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 01:06:31, metric 0, tag
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 01:06:31, metric 0, tag
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:00:48, metric 0, tag
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:00:48, metric 0, tag
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:00:48, metric 0, tag
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 01:43:56, metric 1
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 01:44:47, metric 1
MultiRecv
0
0
0
0
0
0


to ensure that they have properly defined and
applied the required policy.
Step 2.11
Return to the [edit policy-options] hierarchy level and display the
configured policies.
www.juniper.net
lab@srxA-1# show
policy-statement default-route {
term match-default-static-route {
from {
protocol static;
}
then accept;
}
}
policy-statement interface-routes {
from {
}
then accept;
}
}
policy-statement other-static-routes {
term match-other-static-routes {
from {
protocol static;
}
then accept;
}
}
lab@srxA-1#
Step 2.12
Use the existing policies as a guide. Create a new policy named ospf-export with
three distinct terms; match-default-route, match-interface-routes,
and match-other-static-routes. Ensure that the new ospf-export policy
accomplishes the same basic objectives as the three existing policies.
lab@srxA-1# edit policy-statement ospf-export
[edit policy-options policy-statement ospf-export]
lab@srxA-1# set term match-default-static-route from protocol static
lab@srxA-1# set term match-default-static-route from route-filter 0/0 exact
lab@srxA-1# set term match-default-static-route then accept
www.juniper.net

lab@srxA-1# set term match-interface-routes then accept
lab@srxA-1# set term match-other-static-routes from protocol static
exact
exact
exact
lab@srxA-1# set term match-other-static-routes then accept
lab@srxA-1#
Step 2.13
Navigate to the [edit protocols ospf] hierarchy level and delete the applied
export policies.
lab@srxA-1# delete export
lab@srxA-1#
Step 2.14
Apply the ospf-export policy as an OSPF export policy and activate the changes
using the commit command.
lab@srxA-1# set export ospf-export
lab@srxA-1# commit
commit complete
www.juniper.net

Note

proceeding.
Step 2.15
shows the expected OSPF external routes exported by the remote student device.
Check with the remote team to ensure that they also see the proper OSPF routes in
their devices routing table.
0.0.0.0/0
172.18.2.0/30
172.20.102.0/24
172.22.0.0/24
172.22.1.0/24
172.22.2.0/24
192.168.2.1/32
224.0.0.5/32
[OSPF/150] 01:21:15, metric 0, tag

to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 01:14:10, metric 0, tag
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 01:14:10, metric 0, tag
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:08:27, metric 0, tag
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:08:27, metric 0, tag
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:08:27, metric 0, tag
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 01:51:35, metric 1
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 01:52:26, metric 1
MultiRecv
0
0
0
0
0
0


to ensure that they properly defined and applied the
required policy.
www.juniper.net
Step 2.16
Return to the [edit policy-options] hierarchy level and delete the unused
routing policies. Activate the changes and return to operational mode using the
commit and-quit command.
lab@srxA-1# delete policy-statement default-route
lab@srxA-1# delete policy-statement interface-routes
lab@srxA-1# delete policy-statement other-static-routes
commit complete
lab@srxA-1>
Step 2.17
lab@srxA-1> exit
srxA-1 (ttyu0)
login:
STOP
Tell your instructor that you completed Lab 2.
www.juniper.net
Lab 3
Firewall Filters (Detailed)
Overview
This lab demonstrates configuration and monitoring of firewall filters on devices running
define, apply, and monitor firewall filters.
www.juniper.net
Configure and monitor firewall filters.
Firewall Filters (Detailed) Lab 31

12.a.12.1R1.9

As part of a team, you will prepare your device by making some modifications to the
configuration and verifying proper operation. This lab part requires that you interact
with and perform some verification tasks on the vr-device, which is a J Series
Services Router. The vr-device is logically segmented into several virtual routers
that attach to the student devices. In this lab part, you must refer to the
management network diagram as well as the network diagram for Lab 3.
Step 1.1

Step 1.2
Step 1.3
Lab 32 Firewall Filters (Detailed)
www.juniper.net
srxA-1 (ttyp0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC
[edit]
load complete
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Step 1.4
Navigate to the [edit system services] hierarchy level. Issue the show
command to display the currently enabled services.
[edit]
lab@srxA-1# edit system services
[edit system services]
lab@srxA-1# show
ssh;
telnet;
web-management {
http {
}
https {
system-generated-certificate;
interface all;
}
}
lab@srxA-1#
Question: Which services are currently enabled?
Answer: As shown in the sample capture, the ssh,

telnet, and web-management services are
currently enabled.
www.juniper.net
Step 1.5
Enable the ftp service and activate the configuration change using the commit
command.
lab@srxA-1# set ftp
lab@srxA-1# commit
commit complete
Note
The next lab steps require you to log in to

the virtual router attached to your teams
device. The virtual routers are logical
devices created on a J Series router. Refer
to the management network diagram for
the IP address of the vr-device.
Step 1.6
Open a separate Telnet session to the vr-device.
www.juniper.net
Step 1.7
Log in to the virtual router attached to your teams 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.
a1@vr-device>
Step 1.8
Use the ping utility to verify reachability to your devices loopback address and the
Internet host. Refer to the network diagram associated with this lab as needed.
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. For
example srxA-1 would use the vr101
instance.
a1@vr-device> ping routing-instance local_instance address rapid count 25
PING 192.168.1.1 (192.168.1.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
--- 192.168.1.1 ping statistics --www.juniper.net
25 packets transmitted, 25 packets received, 0% packet loss

a1@vr-device> ping routing-instance local_instance 172.31.15.1 rapid count 25
PING 172.31.15.1 (172.31.15.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
Answer: Yes, as shown in the capture, the ping tests

should succeed from the virtual router.
Step 1.9
Attempt to establish an FTP session with your assigned device. Use the loopback
address assigned to your device as the destination address. Log in as lab when
testing this service.
Note

instance name when initiating an FTP
session from a virtual router. The instance
names match the virtual router names
listed on the network diagram.
a1@vr-device> ftp routing-instance local_instance address
Connected to 192.168.1.1.
220 srxA-1 FTP server (Version 6.00LS) ready.
Name (192.168.1.1:a1): lab
331 Password required for lab.
Password:
230 User lab logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
Question: Does the FTP session establish

successfully?
Answer: Yes, as shown in the capture, the FTP

session does establish successfully.
www.juniper.net
Step 1.10
Issue the bye command to close the established FTP session.
ftp> bye
221 Goodbye.
a1@vr-device>
Step 1.11
Attempt to establish an SSH session with your assigned device by issuing the ssh
routing-instance instance lab@address command. Reference the
instance name associated with your virtual router and the loopback address
assigned to your student device as the destination address.
a1@vr-device> ssh routing-instance local_instance lab@address
The authenticity of host '10.210.14.131 (10.210.14.131)' can't be established.
RSA key fingerprint is 7b:a1:9b:00:6e:7f:aa:5b:65:b3:b2:4c:5e:d6:8e:f2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.210.14.131' (RSA) to the list of known hosts.
lab@10.210.14.131's password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC
lab@srxA-1>
Question: Does the SSH session establish

successfully?
Answer: Yes, as shown in the capture, the SSH

Step 1.12
Issue the exit command to close the SSH session and return to your assigned
virtual router.
lab@srxA-1> exit
Connection to 192.168.1.1 closed.
a1@vr-device>
Step 1.13
Attempt to establish a Telnet session with your assigned device. Use the loopback
address assigned to your device as the destination address. Use the lab user
account when testing this service.
Note

instance name when initiating a Telnet
session from a virtual router. The instance
names match the virtual router names
listed on the network diagram.
www.juniper.net
a1@vr-device> telnet routing-instance local_instance address

Trying 192.168.1.1...
Escape character is '^]'.
srxA-1 (ttyp0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC
lab@srxA-1>
Question: Does the Telnet session establish

successfully?
Answer: Yes, as shown in the capture, the Telnet

Step 1.14
Issue the exit command to close the Telnet session and return to your assigned
virtual router.
lab@srxA-1> exit
Connection closed by foreign host.
a1@vr-device>
Note
You perform additional verification tasks

from your assigned virtual router later in
this lab. Keep the current Telnet session
open for the subsequent lab tasks.
Step 1.15
Return to the session opened for your assigned student device.
From the sessioned opened to your assigned student device, issue the
run show ospf neighbor and run show route commands to establish a
current baseline.
Address
Interface
172.20.77.2
ge-0/0/1.0
172.20.66.2
ge-0/0/2.0
State
Full
Full
ID
192.168.2.1
192.168.2.1
Pri
128
128
Dead
37
34

lab@srxA-1# run show route
www.juniper.net

0.0.0.0/0
10.210.14.128/27
10.210.14.131/32
172.18.1.0/30
172.18.1.2/32
172.18.2.0/30
172.20.66.0/30
172.20.66.1/32
172.20.77.0/30
172.20.77.1/32
172.20.101.0/24
172.20.101.1/32
172.20.102.0/24
172.21.0.0/24
172.21.1.0/24
172.21.2.0/24
172.22.0.0/24
172.22.1.0/24
172.22.2.0/24
192.168.1.1/32
192.168.2.1/32
224.0.0.5/32
www.juniper.net
*[Static/5] 14:31:10
> to 172.18.1.1 via ge-0/0/3.0
[OSPF/150] 12:52:11, metric 0, tag 0
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[Direct/0] 17:07:19
> via ge-0/0/0.0
*[Local/0] 17:07:23
*[Direct/0] 14:51:36
> via ge-0/0/3.0
*[Local/0] 14:51:36
*[OSPF/150] 12:45:06, metric 0, tag 0
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[Direct/0] 14:51:36
> via ge-0/0/2.0
*[Local/0] 14:51:36
*[Direct/0] 14:51:36
> via ge-0/0/1.0
*[Local/0] 14:51:36
*[Direct/0] 14:51:36
> via ge-0/0/4.101
*[Local/0] 14:51:36
*[OSPF/150] 12:45:06, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[Static/5] 13:01:16
> to 172.20.101.10 via ge-0/0/4.101
*[Static/5] 13:01:16
> to 172.20.101.10 via ge-0/0/4.101
*[Static/5] 13:01:16
> to 172.20.101.10 via ge-0/0/4.101
*[OSPF/150] 11:39:23, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 11:39:23, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 11:39:23, metric 0, tag 0
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[Direct/0] 14:51:36
> via lo0.0
*[OSPF/10] 13:22:31, metric 1
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 13:23:22, metric 1
MultiRecv
Question: Does your device still show its OSPF

neighbor adjacencies in the Full state?
Answer: Yes, at this time all student devices should

show their respective OSPF neighbor adjacencies in
the Full state.
Question: Does your device have the required route
table entries to route to all internal and external
destinations?
Answer: Yes, at this time all student devices should

have the required route table entries to facilitate
routing to both internal and external destination
prefixes.
STOP
Before proceeding, ensure that the remote student team is ready to

continue on to Part 2.
Part 2: Configuring and Monitoring Firewall Filters

In this lab part, you will configure and monitor firewall filters.
Step 2.1
Navigate to the top of the hierarchy and load the lab3-part2-start.config
file from the/var/home/lab/jre/ directory. Commit your configuration when
complete.
lab@srxA-1# top
[edit]
load complete
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Step 2.2
From your assigned student device, navigate to the [edit firewall] hierarchy
level. Issue the edit family ? command and answer the following question:
www.juniper.net
[edit]
lab@srxA-1# edit firewall
[edit firewall]
lab@srxA-1# edit family ?
Possible completions:
> any
Protocol-independent filter
> bridge
Protocol family BRIDGE for firewall filter
> ccc
Protocol family CCC for firewall filter
> inet
Protocol family IPv4 for firewall filter
> inet6
Protocol family IPv6 for firewall filter
> mpls
Protocol family MPLS for firewall filter
> vpls
Protocol family VPLS for firewall filter
[edit firewall]
lab@srxA-1# edit family
Question: Based on the available options, which

family designation is used for IPv4 firewall filters?
Answer: The family inet firewall filter option is

used for IPv4 firewall filters.
Step 2.3
Issue the edit family inet filter protect-host command in
preparation to create a new IPv4 firewall filter named protect-host.
[edit firewall]
lab@srxA-1# edit family inet filter protect-host
[edit firewall family inet filter protect-host]
lab@srxA-1#
Step 2.4
Create a term named limit-icmp that only permits inbound ICMP packets from
the 10.210.0.0/16 subnet.
lab@srxA-1# set term limit-icmp from protocol icmp
lab@srxA-1# set term limit-icmp from source-address 10.210.0.0/16
lab@srxA-1# set term limit-icmp then accept
Step 2.5
Create a term named limit-ftp that permits inbound FTP packets from the
10.210.0.0/16 subnet.
www.juniper.net

lab@srxA-1# set term limit-ftp from protocol tcp port ftp
lab@srxA-1# set term limit-ftp from source-address 10.210.0.0/16
lab@srxA-1# set term limit-ftp then accept
Step 2.6
Create a term named limit-ssh that permits inbound SSH packets from the
10.210.0.0/16 subnet.
lab@srxA-1# set term limit-ssh from protocol tcp port ssh
lab@srxA-1# set term limit-ssh from source-address 10.210.0.0/16
lab@srxA-1# set term limit-ssh then accept
Step 2.7
Create a term named limit-telnet that permits inbound Telnet packets from
the 10.210.0.0/16 subnet.
lab@srxA-1# set term limit-telnet from protocol tcp port telnet
lab@srxA-1# set term limit-telnet from source-address 10.210.0.0/16
lab@srxA-1# set term limit-telnet then accept
Step 2.8
Navigate to the [edit interfaces lo0] hierarchy level and apply the
protect-host firewall filter as an input filter. Issue the commit command to
activate the configuration change.
lab@srxA-1# top edit interfaces lo0
[edit interfaces lo0]
lab@srxA-1# set unit 0 family inet filter input protect-host
lab@srxA-1# commit
commit complete
lab@srxA-1#
www.juniper.net
Step 2.9
Return to the session opened for the virtual router attached to your teams device.
From your assigned virtual router, use the ping utility to verify reachability to your
devices loopback address and the Internet host. Refer to the network diagram for
the destination addresses when performing the ping operations.
Note

instance name when sourcing ICMP traffic
the network diagram.
PING 192.168.1.1 (192.168.1.1): 56 data bytes
.........................
a1@vr-device> ping routing-instance local_instance 172.31.15.1 rapid count 25
PING 172.31.15.1 (172.31.15.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
Question: Do both ping tests succeed? Is this result

the expected behavior?
Answer: Both ping tests do not succeed. As shown,

the ping test to the student devices loopback
address does not succeed while the ping test to the
Internet host does succeed. Based on the current
configuration, this result is expected. Remember
that our recently added loopback filter only permits
inbound ICMP traffic from the 10.210.0.0/16
subnet. The new filter does not, however, affect
transit traffic.
Step 2.10
Attempt to establish FTP, SSH, and Telnet sessions with your assigned device. Use
the loopback address assigned to your device as the destination address. Use the
lab user account when testing these services.
www.juniper.net

Note

instance name when sourcing traffic from a
virtual router. The instance names match
the virtual router names listed on the
network diagram.
Note
Use the Ctrl+c sequence to break

unresponsive attempts for FTP, SSH, and
Telnet sessions.
^C
^C
Trying 192.168.1.1...
^C
a1@vr-device>
Question: Do the FTP, SSH, and Telnet sessions

successfully establish? Given the current
configuration, is this behavior expected?
Answer: As shown in the capture, none of the

session attempts successfully establishes. Because
the session attempts do not use a source address
within the 10.210.0.0/16 subnet, the session
attempts should fail by design.
Step 2.11
To confirm that the firewall filter applied to your student devices loopback interface
permits inbound ICMP echo requests, FTP, SSH, and Telnet traffic destined for the
local host and sourced from the 10.210.0.0/16 subnet, attempt the same tests
performed in the previous two steps. Perform these tests from the virtual router
connection but do not specify a routing instance. Use the management IP address
assigned to your student device as the destination address. Refer to the
management network diagram as needed.
a1@vr-device> ping management_address rapid count 25
PING 10.210.14.131 (10.210.14.131): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
www.juniper.net
Question: Does the ping test succeed?
Answer: Yes, the ping test should now succeed

because the ICMP echo requests use a source
address within the 10.210.0.0/16 subnet.
a1@vr-device> ftp management_address
Name (10.210.14.131:a1): lab
Password:
ftp> bye
221 Goodbye.
a1@vr-device> ssh lab@management_address
The authenticity of host '10.210.14.131 (10.210.14.131)' can't be established.
RSA key fingerprint is 7b:a1:9b:00:6e:7f:aa:5b:65:b3:b2:4c:5e:d6:8e:f2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.210.14.131' (RSA) to the list of known hosts.
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC
lab@srxA-1> exit
a1@vr-device> telnet management_address
Trying 10.210.14.131...
srxA-1 (ttyp0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC
lab@srxA-1> exit
a1@vr-device>
www.juniper.net

successfully establish?
Answer: Yes, because the session attempts use a

source address within the 10.210.0.0/16 subnet,
the session attempts should now succeed.
Question: Do the results of the verification tasks
imply that the loopback filter is working as
designed?
Answer: Yes, based on the results of the verification

tasks, the applied loopback filter is working as
designed.
Step 2.12
From the sessioned opened to your assigned student device, issue the
run show ospf neighbor and run show route commands to verify the
current state of the OSPF neighbors and route table entries.
0.0.0.0/0
10.210.14.128/27
10.210.14.131/32
172.18.1.0/30
172.18.1.2/32
172.20.66.0/30
172.20.66.1/32
172.20.77.0/30
172.20.77.1/32
172.20.101.0/24
*[Static/5] 14:48:28
> to 172.18.1.1 via ge-0/0/3.0
*[Direct/0] 17:24:37
> via ge-0/0/0.0
*[Local/0] 17:24:41
*[Direct/0] 15:08:54
> via ge-0/0/3.0
*[Local/0] 15:08:54
*[Direct/0] 15:08:54
> via ge-0/0/2.0
*[Local/0] 15:08:54
*[Direct/0] 15:08:54
> via ge-0/0/1.0
*[Local/0] 15:08:54
*[Direct/0] 15:08:54
> via ge-0/0/4.101
www.juniper.net
172.20.101.1/32
172.21.0.0/24
172.21.1.0/24
172.21.2.0/24
192.168.1.1/32
224.0.0.5/32
*[Local/0] 15:08:54
*[Static/5] 13:18:34
> to 172.20.101.10 via ge-0/0/4.101
*[Static/5] 13:18:34
> to 172.20.101.10 via ge-0/0/4.101
*[Static/5] 13:18:34
> to 172.20.101.10 via ge-0/0/4.101
*[Direct/0] 15:08:54
> via lo0.0
*[OSPF/10] 13:40:40, metric 1
MultiRecv
Question: Does your device show OSPF neighbor

adjacencies or routes learned through OSPF? Can
you explain why?
Answer: As shown in the sample capture, your

student device should not detect any OSPF
neighbors at this time. If you expect the loopback
filter is the reason for the current state, you are
correct. Although the currently applied loopback
filter limits traffic for the specified protocols, it does
not currently account for other host-bound traffic,
such as OSPF. You resolve this issue in subsequent
lab steps.
Step 2.13
Deactivate the firewall filter applied to the loopback interface and activate the
configuration change.
lab@srxA-1# deactivate unit 0 family inet filter
lab@srxA-1# show
unit 0 {
family inet {
inactive: filter {
input protect-host;
}
address 192.168.1.1/32;
}
}
lab@srxA-1# commit
commit complete
www.juniper.net

Note

proceeding.
Step 2.14
Issue the run show ospf neighbor and run show route commands again
to verify the state of the OSPF neighbors and verify that the route table entries
restored properly.
Address
Interface
172.20.77.2
ge-0/0/1.0
172.20.66.2
ge-0/0/2.0
State
Full
Full
ID
192.168.2.1
192.168.2.1
Pri
128
128
Dead
35
38

0.0.0.0/0
10.210.14.128/27
10.210.14.131/32
172.18.1.0/30
172.18.1.2/32
172.18.2.0/30
172.20.66.0/30
172.20.66.1/32
172.20.77.0/30
172.20.77.1/32
172.20.101.0/24
172.20.101.1/32
172.20.102.0/24
*[Static/5] 14:55:12
> to 172.18.1.1 via ge-0/0/3.0
[OSPF/150] 00:00:34, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[Direct/0] 17:31:21
> via ge-0/0/0.0
*[Local/0] 17:31:25
*[Direct/0] 15:15:38
> via ge-0/0/3.0
*[Local/0] 15:15:38
*[OSPF/150] 00:00:34, metric 0, tag 0
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[Direct/0] 15:15:38
> via ge-0/0/2.0
*[Local/0] 15:15:38
*[Direct/0] 15:15:38
> via ge-0/0/1.0
*[Local/0] 15:15:38
*[Direct/0] 15:15:38
> via ge-0/0/4.101
*[Local/0] 15:15:38
*[OSPF/150] 00:00:34, metric 0, tag 0
www.juniper.net
172.21.0.0/24
172.21.1.0/24
172.21.2.0/24
172.22.0.0/24
172.22.1.0/24
172.22.2.0/24
192.168.1.1/32
192.168.2.1/32
224.0.0.5/32
> to 172.20.77.2 via ge-0/0/1.0

to 172.20.66.2 via ge-0/0/2.0
*[Static/5] 13:25:18
> to 172.20.101.10 via ge-0/0/4.101
*[Static/5] 13:25:18
> to 172.20.101.10 via ge-0/0/4.101
*[Static/5] 13:25:18
> to 172.20.101.10 via ge-0/0/4.101
*[OSPF/150] 00:00:34, metric 0, tag 0
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:00:34, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:00:34, metric 0, tag 0
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[Direct/0] 15:15:38
> via lo0.0
*[OSPF/10] 00:00:34, metric 1
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 13:47:24, metric 1
MultiRecv
Question: With the firewall filter inactive, does your

assigned device again see OSPF neighbor
adjacencies and routes learned from its neighbor?

student device should again see OSPF neighbor
adjacencies and OSPF routes learned from the
remote OSPF neighbor.
Step 2.15
Navigate to the [edit firewall family inet filter protect-host]
hierarchy level. Restructure the protect-host firewall filter to accomplish the
previously stated objectives and also permit all other traffic through a term named
else-accept that implicitly allows all other traffic. Include a counter for each
defined term. Name each of the counters count-X, where X is the name of the
associated term.
www.juniper.net

Note
In most firewall filter implementations, you

will likely use the discard action rather
than the reject action to avoid sending
notifications back to potential attackers. In
this lab, you might choose the reject
action to simplify your testing verification.
In the detailed lab guide, we highlight the
use of the discard action for each
defined term.
lab@srxA-1# top edit firewall family inet filter protect-host
lab@srxA-1# set term limit-icmp from source-address 0/0
lab@srxA-1# set term limit-icmp from source-address 10.210.0.0/16 except
lab@srxA-1# set term limit-icmp then count count-limit-icmp
lab@srxA-1# set term limit-icmp then discard
lab@srxA-1# set term limit-ftp from source-address 0/0
lab@srxA-1# set term limit-ftp from source-address 10.210.0.0/16 except
lab@srxA-1# set term limit-ftp then count count-limit-ftp
lab@srxA-1# set term limit-ftp then discard
lab@srxA-1# set term limit-ssh from source-address 0/0
lab@srxA-1# set term limit-ssh from source-address 10.210.0.0/16 except
lab@srxA-1# set term limit-ssh then count count-limit-ssh
lab@srxA-1# set term limit-ssh then discard
lab@srxA-1# set term limit-telnet from source-address 0/0
www.juniper.net

lab@srxA-1# set term limit-telnet from source-address 10.210.0.0/16 except
lab@srxA-1# set term limit-telnet then count count-limit-telnet
lab@srxA-1# set term limit-telnet then discard
lab@srxA-1# set term else-accept then count count-else-accept
lab@srxA-1# set term else-accept then accept
lab@srxA-1# show
term limit-icmp {
from {
source-address {
10.210.0.0/16 except;
0.0.0.0/0;
}
protocol icmp;
}
then {
count count-limit-icmp;
discard;
}
}
term limit-ftp {
from {
source-address {
10.210.0.0/16 except;
0.0.0.0/0;
}
protocol tcp;
port ftp;
}
then {
count count-limit-ftp;
discard;
}
}
term limit-ssh {
from {
source-address {
10.210.0.0/16 except;
0.0.0.0/0;
}
protocol tcp;
port ssh;
}
then {
count count-limit-ssh;
www.juniper.net
discard;
}
}
term limit-telnet {
from {
source-address {
10.210.0.0/16 except;
0.0.0.0/0;
}
protocol tcp;
port telnet;
}
then {
count count-limit-telnet;
discard;
}
}
term else-accept {
then {
count count-else-accept;
accept;
}
}
lab@srxA-1#
Step 2.16
Return to the [edit interfaces lo0] hierarchy level and reactivate the
protect-host filter. Issue the commit and-quit command to activate the
configuration changes and return to operational mode.
lab@srxA-1# top edit interfaces lo0
lab@srxA-1# activate unit 0 family inet filter
lab@srxA-1# show
unit 0 {
family inet {
filter {
input protect-host;
}
address 192.168.1.1/32;
}
}
commit complete
lab@srxA-1>
www.juniper.net
Step 2.17
Issue the show ospf neighbor and show route commands again to verify
that the state of the OSPF neighbors is Full and that OSPF routes are still present.
lab@srxA-1> show ospf neighbor
Address
Interface
172.20.77.2
ge-0/0/1.0
172.20.66.2
ge-0/0/2.0
State
Full
Full
ID
192.168.2.1
192.168.2.1
Pri
128
128
Dead
36
36

0.0.0.0/0
10.210.14.128/27
10.210.14.131/32
172.18.1.0/30
172.18.1.2/32
172.18.2.0/30
172.20.66.0/30
172.20.66.1/32
172.20.77.0/30
172.20.77.1/32
172.20.101.0/24
172.20.101.1/32
172.20.102.0/24
172.21.0.0/24
172.21.1.0/24
172.21.2.0/24
172.22.0.0/24
www.juniper.net
*[Static/5] 15:02:09
> to 172.18.1.1 via ge-0/0/3.0
[OSPF/150] 00:07:31, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[Direct/0] 17:38:18
> via ge-0/0/0.0
*[Local/0] 17:38:22
*[Direct/0] 15:22:35
> via ge-0/0/3.0
*[Local/0] 15:22:35
*[OSPF/150] 00:07:31, metric 0, tag 0
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[Direct/0] 15:22:35
> via ge-0/0/2.0
*[Local/0] 15:22:35
*[Direct/0] 15:22:35
> via ge-0/0/1.0
*[Local/0] 15:22:35
*[Direct/0] 15:22:35
> via ge-0/0/4.101
*[Local/0] 15:22:35
*[OSPF/150] 00:07:31, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[Static/5] 13:32:15
> to 172.20.101.10 via ge-0/0/4.101
*[Static/5] 13:32:15
> to 172.20.101.10 via ge-0/0/4.101
*[Static/5] 13:32:15
> to 172.20.101.10 via ge-0/0/4.101
*[OSPF/150] 00:07:31, metric 0, tag 0
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
172.22.1.0/24
172.22.2.0/24
192.168.1.1/32
192.168.2.1/32
224.0.0.5/32
*[OSPF/150] 00:07:31, metric 0, tag 0

> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:07:31, metric 0, tag 0
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[Direct/0] 15:22:35
> via lo0.0
*[OSPF/10] 00:07:31, metric 1
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 13:54:21, metric 1
MultiRecv
Question: With the firewall filter updated and

reapplied, does your assigned device still see OSPF
neighbor adjacencies and OSPF routes from its
neighbor?

student device should still show OSPF neighbor
adjacencies and OSPF routes learned from the
Step 2.18
Return to the session opened for the virtual router attached to your team device.
From your assigned virtual router, attempt to ping the IP address assigned to your
student devices loopback interface. Refer to the network diagram as needed.
Note

PING 192.168.1.1 (192.168.1.1): 56 data bytes
.........................
www.juniper.net
Step 2.19
From the virtual router, attempt to establish FTP, SSH, and Telnet sessions with your
assigned device. Use the loopback address assigned to your device as the
destination address. Use the lab user account when testing these services.
Note

network diagram.
Note
Use the Ctrl+c sequence to break

unresponsive attempts for FTP, SSH, and
Telnet sessions.
^C
^C
Trying 192.168.1.1...
^C
a1@vr-device>

successfully establish? Given the current
configuration, is this behavior expected?
Answer: As shown in the capture, none of the

session attempts successfully establish. Because
the session attempts do not use a source address
within the 10.210.0.0/16 subnet, the session
attempts should fail by design.
Step 2.20
To confirm that the firewall filter applied to your student devices loopback interface
permits inbound ICMP echo requests, FTP, SSH, and Telnet traffic destined for the
local host and sourced from the 10.210.0.0/16 subnet, attempt the same tests
performed in the previous two steps. Perform these tests from the virtual router
connection but do not specify a routing instance. Use the management IP address
assigned to your student device as the destination address. Refer to the
management network diagram as needed.
a1@vr-device> ping management_address rapid count 25
PING 10.210.14.131 (10.210.14.131): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
--- 10.210.14.131 ping statistics --www.juniper.net
25 packets transmitted, 25 packets received, 0% packet loss

Question: Does the ping test succeed?
Answer: Yes, the ping test should now succeed

because the ICMP echo requests use a source
address within the 10.210.0.0/16 subnet.
a1@vr-device> ftp management_address
Name (10.210.14.131:a1): lab
Password:
ftp> bye
221 Goodbye.
a1@vr-device> ssh lab@management_address
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC
lab@srxA-1> exit
a1@vr-device> telnet management_address
Trying 10.210.14.131...
srxA-1 (ttyp0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC
lab@srxA-1> exit
a1@vr-device>

successfully establish?
Answer: Yes, because the session attempts use a

source address within the 10.210.0.0/16 subnet,
the session attempts should now succeed.
www.juniper.net
Question: Do the results of the verification tasks

imply that the loopback filter is working as
designed?
Answer: Yes, based on the results of the verification

tasks, the applied loopback filter is working as
designed.
Step 2.21
From the sessioned opened to your assigned student device and issue the
show firewall command to determine if the counters are incrementing.
lab@srxA-1> show firewall
Filter: __default_bpdu_filter__
Filter: protect-host
Counters:
Name
count-else-accept
count-limit-ftp
count-limit-icmp
count-limit-ssh
count-limit-telnet
Bytes
18241
64
1260
64
128
Packets
250
1
15
1
2
Question: Are the counters for the protect-host

filter incrementing?
Answer: Yes, as illustrated in the sample capture, all

counters have a non-zero value due to the recent
tests.
Step 2.22
lab@srxA-1> exit
srxA-1 (ttyu0)
login:
STOP
www.juniper.net
Tell your instructor that you completed Lab 3.
www.juniper.net
Lab 4
Class of Service (Optional)(Detailed)
Overview
This lab explores basic class of service (CoS) configuration for devices running the
Junos operating system. In this lab, you use the command-line interface (CLI) to define,
apply, and monitor CoS components.
www.juniper.net
Configure queues and scheduler maps.
Configure multifield classification.
Verify the operation of the multifield classifier.
Configure behavior aggregate (BA) rewrite rules and classifiers.
Class of Service (Optional)(Detailed) Lab 41

12.a.12.1R1.9

As part of a team, you will prepare your device by making some modifications to the
configuration and verifying proper operation. This lab part requires that you interact
with and perform some verification tasks on the vr-device, which is a J Series
Services Router. The vr-device is logically segmented into several virtual routers
that attach to the student devices. In this lab part, you must refer to the
management network diagram as well as the network diagram for Lab 4.
Step 1.1

Step 1.2
Step 1.3
Lab 42 Class of Service (Optional)(Detailed)
www.juniper.net
srxA-1 (ttyp0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC
[edit]
load complete
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Step 1.4
Navigate to the [edit interfaces] hierarchy level and add the additional
logical interface to the ge-0/0/4 interface. For addressing and other interface
configuration details, refer to the network diagram for this lab.
[edit]
[edit interfaces]
lab@srxA-1# set ge-0/0/4 unit vlan-id family inet address address/24
[edit interfaces]
lab@srxA-1# set ge-0/0/4 unit vlan-id vlan-id vlan-id
[edit interfaces]
lab@srxA-1#
Step 1.5
Display the resulting configuration and verify that it is correct. Once you are satisfied
with the interface configuration, issue the commit command to activate the
changes.
[edit interfaces]
lab@srxA-1# show ge-0/0/4
vlan-tagging;
unit 101 {
vlan-id 101;
family inet {
address 172.20.101.1/24;
}
}
unit 201 {
vlan-id 201;
family inet {
address 172.20.201.1/24;
www.juniper.net
}
}
[edit interfaces]
lab@srxA-1# commit
commit complete
Step 1.6
Use the ping utility to verify reachability to both virtual routers attached to your
device.
[edit interfaces]
lab@srxA-1# run ping address rapid count 25
PING 172.20.101.10 (172.20.101.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
[edit interfaces]
lab@srxA-1# run ping address rapid count 25
PING 172.20.201.10 (172.20.201.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
Question: Do the ping tests to the attached virtual

routers succeed?
Answer: Yes, the ping tests to the attached virtual

routers should succeed. If your tests fail, verify your
configuration and, if needed, contact your
instructor.
Step 1.7
Navigate to the [edit policy-options policy-statement
ospf-export] hierarchy level. Add a new route filter to the
match-interface-routes term to account for the new subnet defined on your
devices tagged interface. This subnet connects your device to the new virtual router.
Refer to the network diagram for this lab as needed. Once satisfied with your
configuration, issue the commit command to activate the changes.
[edit interfaces]
lab@srxA-1# top edit policy-options policy-statement ospf-export
lab@srxA-1# show
www.juniper.net
from {
}
then accept;
}
lab@srxA-1# commit
commit complete
lab@srxA-1#
Note

proceeding.
Step 1.8
Issue the run show ospf neighbor and run show route protocol
ospf commands to verify the current state of the OSPF neighbors and route table
entries.
Address
Interface
State
ID
172.20.77.2
ge-0/0/1.0
Full
192.168.2.1
Pri
128
Dead
35

172.20.102.0/24
172.20.202.0/24
192.168.2.1/32
224.0.0.5/32
www.juniper.net
*[OSPF/150] 00:09:16, metric 0, tag 0

> to 172.20.77.2 via ge-0/0/1.0
*[OSPF/150] 00:00:53, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
*[OSPF/10] 00:09:16, metric 1
> to 172.20.77.2 via ge-0/0/1.0
*[OSPF/10] 1d 02:09:51, metric 1
MultiRecv
Question: Does your device show an OSPF neighbor

adjacency and routes learned from its neighbor?

student device should show an OSPF neighbor
adjacency as well as routes learned from the
Note
The next lab steps require you to log in to

the virtual router attached to your teams
device. The virtual routers are logical
devices created on a J Series router. Refer
to the management network diagram for
the IP address of the vr-device.
Although you have two virtual routers
attached to your student device, you only
need to establish a single session to the
vr-device.
Step 1.9
Open a separate Telnet session to the virtual router attached to your team device.
www.juniper.net
Step 1.10
Log in to the virtual router 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.
a1@vr-device>
Step 1.11
From both of your assigned virtual routers, use the ping utility to verify reachability
to each of the remote virtual routers connected to the remote student device. Refer
to the network diagram for the destination addresses when performing the ping
operations.
Note

instance name when sourcing Internet
Control Message Protocol (ICMP) traffic
from the virtual routers. For example srxA-1
uses the vr101 and vr201 instances. The
instance names match the names of the
virtual routers listed on the network
diagram.
a1@vr-device> ping routing-instance local_instance remote_vr_address rapid
count 25
PING 172.20.102.10 (172.20.102.10): 56 data bytes
www.juniper.net
!!!!!!!!!!!!!!!!!!!!!!!!!
count 25
PING 172.20.202.10 (172.20.202.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
count 25
PING 172.20.102.10 (172.20.102.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
count 25
PING 172.20.202.10 (172.20.202.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
a1@vr-device>
Answer: As shown in the capture, all ping tests from

both virtual routers should succeed. If your tests
fail, please check with the remote team and, if
needed, the instructor.
Note
You perform additional verification tasks

from your assigned virtual routers later in
this lab. Keep the current Telnet session
open for the subsequent lab tasks.
www.juniper.net
Part 2: Configuring Queues and Scheduler Maps

By default, Junos devices assign all traffic to the best-effort or
network-control forwarding classes. Before you can assign traffic to other
forwarding classes, you must configure a scheduler map for each interface with
schedulers for those forwarding classes. In this lab part, you will associate queues
with forwarding classes and configure schedulers and a scheduler map that you can
apply to all interfaces.
Use the following table to assist you in this part:
Forwarding Class Configuration
Queue
Forwarding Class
Bandwidth and
Buffer Allocation
(%)
Priority
best-effort
40
Low
admin
45
Medium-low
voip
10
High
network-control
Medium-high
Step 2.1
Return to the session opened to your assigned student device.
From your assigned student device, navigate to the top of the hierarchy and load the
lab4-part2-start.config file from the/var/home/lab/jre/ directory.
Commit your configuration when complete.
lab@srxA-1# top
[edit]
load complete
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Step 2.2
Navigate to the [edit class-of-service forwarding-classes]
hierarchy level. Configure the forwarding class to queue mappings shown in the
table.
[edit]
lab@srxA-1# edit class-of-service forwarding-classes
www.juniper.net
[edit class-of-service forwarding-classes]

lab@srxA-1# set queue 1 admin
lab@srxA-1# set queue 2 voip
lab@srxA-1#
Question: Must you define the best-effort and

network-control forwarding classes or assign
them to queues 0 and 3?
Answer: No. Configuring the best-effort or

network-control forwarding classes or
assigning them to their respective queues is not
necessary, because they are default CoS
designations and assignments.
Step 2.3
Configure a scheduler for each forwarding class using the parameters shown in the
preceding table. Name the individual schedulers
forwarding-class-name-sched, where forwarding-class-name is the
name of the schedulers corresponding forwarding class.
lab@srxA-1# up
[edit class-of-service]
lab@srxA-1# edit schedulers best-effort-sched
[edit class-of-service schedulers best-effort-sched]
lab@srxA-1# set buffer-size percent 40
lab@srxA-1# set transmit-rate percent 40
lab@srxA-1# set priority low
lab@srxA-1# up
[edit class-of-service schedulers]
lab@srxA-1# edit admin-sched
[edit class-of-service schedulers admin-sched]
www.juniper.net

lab@srxA-1# set priority medium-low
lab@srxA-1# up
lab@srxA-1# edit voip-sched
[edit class-of-service schedulers voip-sched]
lab@srxA-1# set priority high
lab@srxA-1# up
lab@srxA-1# edit network-control-sched
[edit class-of-service schedulers network-control-sched]
lab@srxA-1# set priority medium-high
lab@srxA-1#
Step 2.4
Configure a scheduler map named my-sched-map that associates each
forwarding class with its corresponding scheduler.
lab@srxA-1# up 2
lab@srxA-1# edit scheduler-maps my-sched-map
[edit class-of-service scheduler-maps my-sched-map]
lab@srxA-1# set forwarding-class best-effort scheduler best-effort-sched
lab@srxA-1# set forwarding-class admin scheduler admin-sched
lab@srxA-1# set forwarding-class voip scheduler voip-sched
www.juniper.net

lab@srxA-1# set forwarding-class network-control scheduler
network-control-sched
lab@srxA-1#
Step 2.5
Assign the scheduler map to all configured network interfaces and commit your
configuration when complete. Refer to the network diagram for this lab, if needed.
lab@srxA-1# up 2
[edit class-of-service interfaces]
lab@srxA-1# set ge-0/0/4 scheduler-map my-sched-map
lab@srxA-1# set ge-0/0/1 scheduler-map my-sched-map
lab@srxA-1# commit
commit complete
lab@srxA-1#
Question: Which negative results might you

experience if you fail to assign a scheduler map to
all interfaces?
Answer: The Junos device would use the default

scheduler for traffic traversing unspecified
interfaces. The default scheduler contains buffers
for traffic only in queues associated with the
best-effort and network-control
forwarding classes (typically queues 0 and 3).
Therefore, traffic in queues other than those
associated with the best-effort and
network-control queues might drop.
Part 3: Configuring Multifield Classification

In this lab part, you will configure your device to place traffic in a forwarding class
using a multifield classifier.
www.juniper.net
Step 3.1
file from the/var/home/lab/jre/ directory. Commit your configuration when
complete.
lab@srxA-1# top
[edit]
load complete
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Step 3.2
Navigate to the [edit firewall family inet filter
classify-traffic] hierarchy level to create a new firewall filter named
classify-traffic. Create a term named sip that places SIP traffic sourced
from the locally attached vr10V virtual router subnet (where V is the virtual router
specified in the lab diagrams) into the voip forwarding class. SIP traffic uses either
UDP or TCP and Port 5060.
[edit]
lab@srxA-1# edit firewall family inet filter classify-traffic
[edit firewall family inet filter classify-traffic]
lab@srxA-1# set term sip from source-address address/24
lab@srxA-1# set term sip from protocol [tcp udp] port 5060
lab@srxA-1# set term sip then forwarding-class voip
lab@srxA-1# set term sip then accept
lab@srxA-1#
Step 3.3
Create a term named rtp that places RTP traffic sourced from the locally attached
vr10V virtual router subnet (where V is the virtual router specified in the lab
diagrams) into the voip forwarding class. RTP traffic uses UDP and a port range of
1638432767.
lab@srxA-1# set term rtp from source-address address/24
www.juniper.net

lab@srxA-1# set term rtp from protocol udp port 16384-32767
lab@srxA-1# set term rtp then forwarding-class voip
lab@srxA-1# set term rtp then accept
Step 3.4
Create a term named admin that places traffic with a source address from the
subnet associated with the locally attached vr20V virtual router (where V is the
virtual router specified in the lab diagrams) into the admin forwarding class.
lab@srxA-1# set term admin from source-address address/24
lab@srxA-1# set term admin then forwarding-class admin
lab@srxA-1# set term admin then accept
Step 3.5
Create a term named accept-all that accepts all other traffic and places it in the
default forwarding class.
lab@srxA-1# set term accept-all then accept
Step 3.6
Apply the classify-traffic firewall filter to your devices tagged interfaces to
process inbound traffic from the directly attached virtual routers. Issue the
commit command to activate the configuration changes.
lab@srxA-1# top edit interfaces ge-0/0/4
[edit interfaces ge-0/0/4]
lab@srxA-1# set unit vlan-id family inet filter input classify-traffic
lab@srxA-1# set unit vlan-id family inet filter input classify-traffic
lab@srxA-1# commit
commit complete
lab@srxA-1#
www.juniper.net
Part 4: Verifying the Operation of the Multifield Classifier

In this lab part, you will generate traffic from the virtual routers attached to your
device and ensure that it is being placed in the correct forwarding classes.
Step 4.1
file from the/var/home/lab/jre/ dirtectory. Commit your configuration and
return to operational mode when complete.
lab@srxA-1# top
[edit]
load complete
[edit]
commit complete
lab@srxA-1>
Step 4.2
Clear the interface statistics using the clear interface statistics all
command.
lab@srxA-1> clear interfaces statistics all
Step 4.3
From your assigned student device, issue the show interfaces queue
ge-0/0/1 command to verify the queueing statistics for the ge-0/0/1 interface.
You should see per-queue traffic statistics. Use these statistics as a baseline for
subsequent tests.
lab@srxA-1> show interfaces queue ge-0/0/1
Physical interface: ge-0/0/1, Enabled, Physical link is Up
Interface index: 132, SNMP ifIndex: 119
Forwarding classes: 8 supported, 4 in use
Egress queues: 8 supported, 4 in use
Queue: 0, Forwarding classes: best-effort
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
Tail-dropped packets :
0
RED-dropped packets :
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
www.juniper.net
0 pps
0 bps
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queue: 1, Forwarding classes: admin
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queue: 2, Forwarding classes: voip
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queue: 3, Forwarding classes: network-control
Queued:
Packets
:
2
Bytes
:
188
Transmitted:
Packets
:
2
Bytes
:
188
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
0
0
0
0
0
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0 pps
0 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
0 pps
368 bps
368
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
www.juniper.net
RED-dropped bytes
Low
Medium-low
Medium-high
High
:
:
:
:
:
0
0
0
0
0
0
0
0
0
0
bps
bps
bps
bps
bps
Question: Do the interfaces list the expected

forwarding classes? Are those forwarding classes
properly mapped to their respective queues?
Answer: Yes, the expected forwarding classes

should be listed, and those forwarding classes
should properly map to their respective queues.
Question: Which queues currently show non-zero
counters for the Queued and Transmitted
Packets?
Answer: As shown, only queue 3 shows statistic

counters with non-zero values. Your counter values
might vary from those shown in the output.
Step 4.4
Return to the session opened to your assigned virtual router.
From the virtual router, use the ping utility to send ICMP traffic from the local
vr10V device to the remote vr10V device (where V is the virtual router specified in
the lab diagrams). Use the count option with a value of 100. You might also want to
include the rapid option to speed up the process. Refer to the network diagram for
the destination address.
Note

count 100
PING 172.20.102.10 (172.20.102.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!
www.juniper.net
Question: To which forwarding class should your

device assign this traffic?
Answer: Your device should assign the traffic to the

best-effort forwarding class.
Step 4.5
ge-0/0/1 command and compare it to the baseline statistics you recorded earlier.
You should see that the statistics for queue 0 have incremented.
Queued:
Packets
:
100
Bytes
:
9800
Transmitted:
Packets
:
100
Bytes
:
9800
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0 pps
0 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
www.juniper.net
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
96
Bytes
:
9008
Transmitted:
Packets
:
96
Bytes
:
9008
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
0
0
0
0
0
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0 pps
0 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
Step 4.6
www.juniper.net

Note

count 100
PING 172.20.202.10 (172.20.202.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!


admin forwarding class.
Step 4.7
Queued:
Packets
:
101
Bytes
:
9842
Transmitted:
Packets
:
101
Bytes
:
9842
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
www.juniper.net
High
:
0
Queued:
Packets
:
100
Bytes
:
9800
Transmitted:
Packets
:
100
Bytes
:
9800
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
136
Bytes
:
12772
Transmitted:
Packets
:
136
Bytes
:
12772
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
www.juniper.net
0 bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0 pps
0 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Step 4.8
From the virtual router, use the telnet utility to simulate SIP traffic from the local
vr10V virtual router to the remote vr10V virtual router (where V is the virtual
router specified in the lab diagrams). Use the port option with a port value of 5060
for this telnet session. Refer to the network diagram for the destination address.
Note

network diagram.
a1@vr-device> telnet routing-instance local_instance remote_vr_address port
5060
Trying 172.20.102.10...
telnet: connect to address 172.20.102.10: Connection refused
telnet: Unable to connect to remote host


voip forwarding class.
Step 4.9
Queued:
Packets
:
101
Bytes
:
9842
Transmitted:
Packets
:
101
Bytes
:
9842
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
0 pps
0 bps
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
www.juniper.net
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
100
Bytes
:
9800
Transmitted:
Packets
:
100
Bytes
:
9800
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1
Bytes
:
78
Transmitted:
Packets
:
1
Bytes
:
78
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
151
Bytes
:
14182
Transmitted:
Packets
:
151
Bytes
:
14182
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
www.juniper.net
0
0
0
0
0
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0 pps
0 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
0 pps
0 bps
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
RED-dropped bytes
Low
Medium-low
Medium-high
High
:
:
:
:
:
0
0
0
0
0
0
0
0
0
0
bps
bps
bps
bps
bps
Part 5: Configuring BA Rewrite Rules and Classifiers

In this lab part, you will first configure your student device to rewrite a BA marker
based on the forwarding class. You will then configure your student device to classify
incoming traffic based on BA markings. You will verify this configuration by sending
traffic from your virtual router to your partners virtual router and monitoring that
traffic.
Step 5.1
the/var/home/lab/jre/ dirtectory. After the configuration has been loaded,
commit the changes.
[edit]
load complete
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Step 5.2
Clear the interface statistics using the run clear interface statistics
all command.
[edit]
lab@srxA-1# run clear interfaces statistics all
Step 5.3
Issue the run show interfaces queue ge-0/0/4 command to view the
queueing statistics. Record the output as baseline statistics.
[edit]
lab@srxA-1# run show interfaces queue ge-0/0/4
Queued:
Packets
:
0
Bytes
:
0
0 pps
0 bps
www.juniper.net
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
www.juniper.net
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0
0
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
0 bps
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Packets
Bytes
Tail-dropped packets
RED-dropped packets
Low
Medium-low
Medium-high
High
RED-dropped bytes
Low
Medium-low
Medium-high
High
:
:
:
:
:
:
:
:
:
:
:
:
:
0
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
0 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
Question: Does the output list the expected

forwarding classes for this interface? Do those
forwarding classes properly map to their respective
queues?
Answer: Yes, the expected forwarding classes

should be listed and include best-effort,
admin, voip, and network-control. As
shown, the referenced forwarding classes should
properly map to queues 0, 1, 2, and 3, respectively.
Step 5.4
Navigate to the [edit class-of-service] hierarchy level. Configure the
ge-0/0/1 interface to use the default IP precedence rewrite rule for outbound
traffic.
[edit]
lab@srxA-1# edit class-of-service
lab@srxA-1# set interfaces ge-0/0/1 unit 0 rewrite-rules inet-precedence
default
lab@srxA-1#
Step 5.5
Configure the ge-0/0/1 interface to use the default IP precedence classifier for
inbound traffic. Activate the configuration changes and return to operational mode
using the commit and-quit command.
lab@srxA-1# set interfaces ge-0/0/1 unit 0 classifiers inet-precedence default
www.juniper.net
commit complete
lab@srxA-1>
Note

proceeding.
Step 5.6
Note

count 100
PING 172.20.202.10 (172.20.202.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!
Question: To which forwarding class should the

remote student device assign this traffic?
Answer: The remote student device should assign

the traffic to the admin forwarding class. The
traffic sent by the remote virtual router should
likewise be assigned to the admin forwarding class
on your device.
Step 5.7
www.juniper.net
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
100
Bytes
:
10200
Transmitted:
Packets
:
100
Bytes
:
10200
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0 pps
bps
pps
pps
pps
www.juniper.net
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
bps
bps
bps
bps
bps
0
0
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Question: Have the counters for queue 1

incremented?
Answer: Under Queued and Transmitted, the

Packets and Bytes counters for queue 1 should
now show a non-zero value. If you still see a value of
zero for these counters, please check with the
remote student team to ensure that they performed
the previous lab step.
Step 5.8
From the virtual router, use the telnet utility to simulate SIP traffic from the local
vr10V virtual router to the remote vr10V virtual router (where V is the virtual
router specified in the lab diagrams). Use the port option with a port value of 5060
for this telnet session. Refer to the network diagram for the destination address.
Note

network diagram.
www.juniper.net
a1@vr-device> telnet routing-instance local_instance remote_vr_address port

5060
Trying 172.20.102.10...
telnet: connect to address 172.20.102.10: Connection refused
telnet: Unable to connect to remote host
Question: To which forwarding class should the

remote student device assign this traffic?
Answer: The remote student device should assign

the traffic to the voip forwarding class. The traffic
sent by the remote virtual router should likewise be
assigned to the voip forwarding class on your
device.
Step 5.9
On your student device, issue the show interfaces queue ge-0/0/4
command and compare it to the baseline statistics you recorded earlier. You should
see that the statistics for queue 2 have incremented.
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
100
Bytes
:
10200
Transmitted:
Packets
:
100
Bytes
:
10200
0
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0 pps
0 bps
0 pps
www.juniper.net
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1
Bytes
:
64
Transmitted:
Packets
:
1
Bytes
:
64
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
www.juniper.net
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Question: Have the counters for queue 2

incremented?
Answer: The Packets and Bytes counters for

queue 2 under Queued and Transmitted should
now show a non-zero value. If you still see a value of
zero for these counters, please check with the
remote student team to ensure they have
performed the previous lab step.
Step 5.10
lab@srxA-1> exit
srxA-1 (ttyu0)
login:
STOP
Tell your instructor that you have completed Lab 4.
www.juniper.net

Appendix A: Lab Diagrams
A2 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A3
A4 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A5
A6 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A7
A8 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A9
A10 Lab Diagrams
www.juniper.net

Junos Routing Essentials: Detailed Lab Guide

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

Junos Routing Essentials: Detailed Lab Guide

Uploaded by

Copyright:

Available Formats

Junos Routing Essentials

Detailed Lab Guide

Worldwide Education Services

This document is produced by Juniper Networks, Inc.

Routing Fundamentals (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1

Routing Policy (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1

Firewall Filters (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Class of Service (Optional)(Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

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

Explain basic routing operations and concepts.

View and describe routing and forwarding tables.

Configure and monitor static routing.

Configure and monitor OSPF.

Describe the framework for routing policy.

Explain the evaluation of routing policy.

Identify situations where you might use routing policy.

Write and apply a routing policy.

Describe the framework for firewall filters.

Explain the evaluation of firewall filters.

Identify instances where you might use firewall filters.

Write and apply a firewall filter.

Appendix A: Class of Service

Most of what you read in the Lab Guide

GUI text elements:

Input Text Versus Output Text

View configuration history by clicking

lab@San_Jose> show route

Defined and Undefined Syntax Variables

Text where variable value is

Click my-peers in the dialog.

Text where the variables value

Type set policy policy-name.

Document Conventions vii

About This Publication

Juniper Networks Support

viii Additional Information

Configure and verify proper operation of network interfaces.

Configure and monitor static routing.

Configure and monitor OSPF.

Routing Fundamentals (Detailed) Lab 11