Professional Documents
Culture Documents
12.a
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
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.
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)
Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
config.ini in the Filename field.
CLI Undefined Text where the variable’s value Type set policy policy-name.
is the user’s discretion and text
ping 10.0.x.y
where the variable’s value as
GUI Undefined shown in the lab guide might Select File > Save, and type
differ from the value the user filename in the Filename field.
must input.
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:
• Configure and verify proper operation of network interfaces.
• Configure and monitor static routing.
• Configure and monitor OSPF.
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
Step 1.2
Access the CLI at your station using either the console, Telnet, or SSH as directed by
your instructor. Refer to the management network diagram for the IP address
associated with your team’s station. The following example uses a simple Telnet
access to srxA-1 with the Secure CRT program as a basis:
login: lab
Password:
[edit]
lab@srxA-1# load override jre/lab1-start.config
load complete
[edit]
lab@srxA-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxA-1>
Step 1.4
Issue the show route command to display the contents of the route table.
lab@srxA-1> show route
[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]
lab@srxA-1# set ge-0/0/2 unit 0 family inet address address/30
[edit interfaces]
lab@srxA-1# set ge-0/0/1 unit 0 family inet address address/30
[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;
}
}
[edit interfaces]
lab@srxA-1# commit and-quit
commit complete
Exiting configuration mode
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 Local Remote
ge-0/0/0 up up
ge-0/0/0.0 up up inet 10.210.14.131/27
gr-0/0/0 up up
Step 1.9
Issue the show route command to view the current route entries.
lab@srxA-1> show route
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
STOP Before continuing, ensure that the remote team in your pod is ready to
proceed.
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.
lab@srxA-1> configure
[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
[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
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
^C
--- 172.31.15.1 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
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
[edit routing-options]
lab@srxA-1#
Step 2.4
Issue the run show route 172.31.15.1 command.
[edit routing-options]
lab@srxA-1# run show route 172.31.15.1
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.
[edit routing-options]
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
64 bytes from 172.31.15.1: icmp_seq=1 ttl=64 time=3.558 ms
64 bytes from 172.31.15.1: icmp_seq=2 ttl=64 time=4.889 ms
64 bytes from 172.31.15.1: icmp_seq=3 ttl=64 time=3.727 ms
64 bytes from 172.31.15.1: icmp_seq=4 ttl=64 time=16.563 ms
64 bytes from 172.31.15.1: icmp_seq=5 ttl=64 time=4.260 ms
^C
--- 172.31.15.1 ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.558/6.407/16.563/4.588 ms
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.
[edit routing-options]
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.
[edit routing-options]
lab@srxA-1# set static route address/32 next-hop address
[edit routing-options]
lab@srxA-1# set static route address/32 next-hop address
[edit routing-options]
lab@srxA-1# set static route address/24 next-hop address
[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;
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.
[edit routing-options]
lab@srxA-1# set static route address/32 qualified-next-hop address preference 6
www.juniper.net Routing Fundamentals (Detailed) • Lab 1–13
Junos Routing Essentials
[edit routing-options]
lab@srxA-1# set static route address/32 qualified-next-hop address preference 6
[edit routing-options]
lab@srxA-1# set static route address/24 qualified-next-hop address preference 6
[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;
qualified-next-hop 172.20.77.2 {
preference 6;
}
}
route 192.168.2.2/32 {
next-hop 172.20.66.2;
qualified-next-hop 172.20.77.2 {
preference 6;
}
}
route 172.20.102.0/24 {
next-hop 172.20.66.2;
qualified-next-hop 172.20.77.2 {
preference 6;
}
}
}
[edit routing-options]
lab@srxA-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxA-1>
Step 2.9
Issue the show route protocol static command to view the current static
routes in your device’s route table.
lab@srxA-1> show route protocol static
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.
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.
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
Enter configuration mode and load the lab1-part3-start.config file from
the/var/home/lab/jre/ directory. Commit your configuration when complete.
lab@srxA-1> configure
[edit]
lab@srxA-1# load override jre/lab1-part3-start.config
load complete
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
[edit]
lab@srxA-1# edit protocols ospf
Step 3.4
Issue the run show route protocol ospf to view the active OSPF routes in
your device’s route table.
[edit protocols ospf]
lab@srxA-1# run show route protocol ospf
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.
[edit protocols ospf]
lab@srxA-1# top edit routing-options
[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;
qualified-next-hop 172.20.77.2 {
preference 6;
}
}
route 192.168.2.2/32 {
next-hop 172.20.66.2;
qualified-next-hop 172.20.77.2 {
preference 6;
}
}
route 172.20.102.0/24 {
next-hop 172.20.66.2;
qualified-next-hop 172.20.77.2 {
preference 6;
}
}
}
[edit routing-options]
lab@srxA-1# delete static route address/32
[edit routing-options]
lab@srxA-1# delete static route address/32
[edit routing-options]
lab@srxA-1# delete static route address/24
[edit routing-options]
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.
[edit routing-options]
lab@srxA-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxA-1>
Step 3.7
Ping the loopback address of all internal devices to verify reachability through the
OSPF routes.
lab@srxA-1> ping address rapid count 25
PING 192.168.1.2 (192.168.1.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
--- 192.168.1.2 ping statistics ---
25 packets transmitted, 25 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.445/4.646/9.481/1.217 ms
lab@srxA-1>
Step 3.8
Log out of your assigned device using the exit command.
lab@srxA-1> exit
srxA-1 (ttyu0)
login:
STOP
Tell your instructor that you have completed Lab 1.
Overview
This lab demonstrates configuration and monitoring of routing policy on devices running
the Junos operating system. In this lab, you use the command-line interface (CLI) to
define, apply, and monitor basic routing policy.
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:
• Prepare your device and verify operation.
• Configure and monitor routing policy.
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
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
Step 1.2
Access the CLI at your station using either the console, Telnet, or SSH as directed by
your instructor. Refer to the management network diagram for the IP address
associated with your team’s station. The following example uses a simple Telnet
access to srxA-1 with the Secure CRT program as a basis:
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. 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:
[edit]
lab@srxA-1# load override jre/lab2-start.config
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
[edit routing-options]
lab@srxA-1# set static route address/24 next-hop address
[edit routing-options]
lab@srxA-1# set static route address/24 next-hop address
[edit routing-options]
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.
[edit routing-options]
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;
}
[edit routing-options]
lab@srxA-1# commit and-quit
commit complete
Exiting configuration mode
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
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 State ID Pri Dead
172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 39
172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 32
STOP Wait for your instructor before you proceed to the next part.
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
Enter configuration mode and load the lab2-part2-start.config file from
the/var/home/lab/jre/ directory. Commit your configuration when complete.
lab@srxA-1> configure
[edit]
lab@srxA-1# load override jre/lab2-part2-start.config
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.
[edit policy-options]
lab@srxA-1# edit policy-statement default-route
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 device’s routing table.
[edit protocols ospf]
lab@srxA-1# run show route 0/0 exact
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 device’s interfaces that connect to the Internet and to the directly attached
virtual router. Name the term match-interface-routes.
[edit protocols ospf]
lab@srxA-1# top edit policy-options
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.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.
[edit protocols ospf]
lab@srxA-1# top edit policy-options
[edit policy-options]
lab@srxA-1# edit policy-statement other-static-routes
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.11
Return to the [edit policy-options] hierarchy level and display the
configured policies.
[edit protocols ospf]
lab@srxA-1# top edit policy-options
[edit policy-options]
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.
[edit policy-options]
lab@srxA-1# edit policy-statement ospf-export
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.15
Issue the run show route protocol ospf command. Verify that your device
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 device’s routing table.
[edit protocols ospf]
lab@srxA-1# run show route protocol ospf
[edit policy-options]
lab@srxA-1# delete policy-statement default-route
[edit policy-options]
lab@srxA-1# delete policy-statement interface-routes
[edit policy-options]
lab@srxA-1# delete policy-statement other-static-routes
[edit policy-options]
lab@srxA-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxA-1>
Step 2.17
Log out of your assigned device using the exit command.
lab@srxA-1> exit
srxA-1 (ttyu0)
login:
Overview
This lab demonstrates configuration and monitoring of firewall filters on devices running
the Junos operating system. In this lab, you use the command-line interface (CLI) to
define, apply, and monitor firewall filters.
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:
• Prepare your device and verify operation.
• Configure and monitor firewall filters.
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
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
Step 1.2
Access the CLI at your station using either the console, Telnet, or SSH as directed by
your instructor. Refer to the management network diagram for the IP address
associated with your team’s station. The following example uses a simple Telnet
access to srxA-1 with the Secure CRT program as a basis:
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. Enter configuration mode
and load the reset configuration file using the load override /var/home/
lab/jre/lab3-start.config command. After the configuration has been
loaded, commit the changes.
login: lab
Password:
[edit]
lab@srxA-1# load override jre/lab3-start.config
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
Step 1.6
Open a separate Telnet session to the vr-device.
vr-device (ttyp0)
login: username
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
a1@vr-device>
Step 1.8
Use the ping utility to verify reachability to your device’s loopback address and the
Internet host. Refer to the network diagram associated with this lab as needed.
Note
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
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>
Step 1.12
Issue the exit command to close the SSH session and return to your assigned
virtual router.
lab@srxA-1> exit
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
Remember to reference the appropriate
instance name when initiating a Telnet
session from a virtual router. The instance
names match the virtual router names
listed on the network diagram.
srxA-1 (ttyp0)
login: lab
Password:
Step 1.14
Issue the exit command to close the Telnet session and return to your assigned
virtual router.
lab@srxA-1> exit
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.
[edit system services]
lab@srxA-1# run show ospf neighbor
Address Interface State ID Pri Dead
172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 37
172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 34
STOP Before proceeding, ensure that the remote student team is ready to
continue on to Part 2.
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.
[edit system services]
lab@srxA-1# top
[edit]
lab@srxA-1# load override jre/lab3-part2-start.config
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:
[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
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
Note
Remember to reference the appropriate
instance name when sourcing ICMP traffic
from a virtual router. The instance names
match the virtual router names listed on
the network diagram.
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.
Note
Use the Ctrl+c sequence to break
unresponsive attempts for FTP, SSH, and
Telnet sessions.
Step 2.11
To confirm that the firewall filter applied to your student device’s 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 ---
25 packets transmitted, 25 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.796/4.507/6.888/0.874 ms
srxA-1 (ttyp0)
login: lab
Password:
a1@vr-device>
Step 2.12
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 verify the
current state of the OSPF neighbors and route table entries.
[edit interfaces lo0]
lab@srxA-1# run show ospf neighbor
Step 2.13
Deactivate the firewall filter applied to the loopback interface and activate the
configuration change.
[edit interfaces lo0]
lab@srxA-1# deactivate unit 0 family inet filter
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.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.
[edit interfaces lo0]
lab@srxA-1# run show ospf neighbor
Address Interface State ID Pri Dead
172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 35
172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 38
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.
lab@srxA-1>
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 device’s loopback interface. Refer to the network diagram as needed.
Note
Remember to reference the appropriate
instance name when sourcing ICMP 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.
Step 2.20
To confirm that the firewall filter applied to your student device’s 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 Firewall Filters (Detailed) • Lab 3–25
Junos Routing Essentials
25 packets transmitted, 25 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.532/4.622/6.082/0.812 ms
srxA-1 (ttyp0)
login: lab
Password:
a1@vr-device>
Step 2.21
Return to the session opened for your assigned student device.
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 Bytes Packets
count-else-accept 18241 250
count-limit-ftp 64 1
count-limit-icmp 1260 15
count-limit-ssh 64 1
count-limit-telnet 128 2
Step 2.22
Log out of your assigned device using the exit command.
lab@srxA-1> exit
srxA-1 (ttyu0)
login:
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.
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:
• Prepare your device and verify operation.
• Configure queues and scheduler maps.
• Configure multifield classification.
• Verify the operation of the multifield classifier.
• Configure behavior aggregate (BA) rewrite rules and classifiers.
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
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
Step 1.2
Access the CLI at your station using either the console, Telnet, or SSH as directed by
your instructor. Refer to the management network diagram for the IP address
associated with your team’s station. The following example uses a simple Telnet
access to srxA-1 with the Secure CRT program as a basis:
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. Enter configuration mode
and load the reset configuration file using the load override /var/home/
lab/jre/lab4-start.config command. After the configuration has been
loaded, commit the changes.
login: lab
Password:
[edit]
lab@srxA-1# load override jre/lab4-start.config
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]
lab@srxA-1# edit interfaces
[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;
[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
!!!!!!!!!!!!!!!!!!!!!!!!!
--- 172.20.101.10 ping statistics ---
25 packets transmitted, 25 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.537/4.971/12.238/2.008 ms
[edit interfaces]
lab@srxA-1# run ping address rapid count 25
PING 172.20.201.10 (172.20.201.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
--- 172.20.201.10 ping statistics ---
25 packets transmitted, 25 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.299/9.487/124.851/23.574 ms
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
device’s 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
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 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.
[edit policy-options policy-statement ospf-export]
lab@srxA-1# run show ospf neighbor
Address Interface State ID Pri Dead
172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 35
Note
The next lab steps require you to log in to
the virtual router attached to your team’s
device. The virtual routers are logical
devices created on a J Series 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.
vr-device (ttyp0)
login: username
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual 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
a1@vr-device>
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.
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.
[edit policy-options policy-statement ospf-export]
lab@srxA-1# top
[edit]
lab@srxA-1# load override jre/lab4-part2-start.config
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
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 scheduler’s corresponding forwarding class.
[edit class-of-service forwarding-classes]
lab@srxA-1# up
[edit class-of-service]
lab@srxA-1# edit schedulers best-effort-sched
[edit class-of-service]
lab@srxA-1# edit scheduler-maps my-sched-map
[edit class-of-service]
lab@srxA-1# edit interfaces
In this lab part, you will configure your device to place traffic in a forwarding class
using a multifield classifier.
[edit]
lab@srxA-1# load override jre/lab4-part3-start.config
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
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
Navigate to the top of the hierarchy and load the lab4-part4-start.config
file from the/var/home/lab/jre/ dirtectory. Commit your configuration and
return to operational mode when complete.
[edit interfaces ge-0/0/4]
lab@srxA-1# top
[edit]
lab@srxA-1# load override jre/lab4-part4-start.config
load complete
[edit]
lab@srxA-1# commit and-quit
commit complete
Exiting configuration mode
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 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets : 0 0 pps
Low : 0 0 pps
Medium-low : 0 0 pps
Medium-high : 0 0 pps
High : 0 0 pps
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
Remember to reference the appropriate
instance name when sourcing ICMP traffic
from a virtual router. The instance names
match the virtual router names listed on
the network diagram.
Step 4.5
Return to the session opened to your assigned student device.
From your assigned student device, issue the show interfaces queue
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.
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 : 100 0 pps
Bytes : 9800 0 bps
Transmitted:
Packets : 100 0 pps
Bytes : 9800 0 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets : 0 0 pps
Low : 0 0 pps
Medium-low : 0 0 pps
Medium-high : 0 0 pps
High : 0 0 pps
RED-dropped bytes : 0 0 bps
Low : 0 0 bps
Medium-low : 0 0 bps
Medium-high : 0 0 bps
High : 0 0 bps
Queue: 1, Forwarding classes: admin
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets : 0 0 pps
Low : 0 0 pps
Medium-low : 0 0 pps
Medium-high : 0 0 pps
High : 0 0 pps
Note
Remember to reference the appropriate
instance name when sourcing ICMP traffic
from a virtual router. The instance names
match the virtual router names listed on
the network diagram.
Step 4.7
Return to the session opened to your assigned student device.
From your assigned student device, issue the show interfaces queue
ge-0/0/1 command and compare it to the baseline statistics you recorded earlier.
You should see that the statistics for queue 1 have incremented.
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 : 101 0 pps
Bytes : 9842 0 bps
Transmitted:
Packets : 101 0 pps
Bytes : 9842 0 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets : 0 0 pps
Low : 0 0 pps
Medium-low : 0 0 pps
Medium-high : 0 0 pps
High : 0 0 pps
RED-dropped bytes : 0 0 bps
Low : 0 0 bps
Medium-low : 0 0 bps
Medium-high : 0 0 bps
Step 4.9
Return to the session opened to your assigned student device.
From your assigned student device, issue the show interfaces queue
ge-0/0/1 command and compare it to the baseline statistics you recorded earlier.
You should see that the statistics for queue 2 have incremented.
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 : 101 0 pps
Bytes : 9842 0 bps
Transmitted:
Packets : 101 0 pps
Bytes : 9842 0 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets : 0 0 pps
Low : 0 0 pps
Medium-low : 0 0 pps
Medium-high : 0 0 pps
High : 0 0 pps
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 partner’s virtual router and monitoring that
traffic.
Step 5.1
Enter configuration mode and load the lab4-part5-start.config file from
the/var/home/lab/jre/ dirtectory. After the configuration has been loaded,
commit the changes.
lab@srxA-1> configure
Entering configuration mode
[edit]
lab@srxA-1# load override jre/lab4-part5-start.config
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
Physical interface: ge-0/0/4, Enabled, Physical link is Up
Interface index: 135, SNMP ifIndex: 128
Forwarding classes: 8 supported, 4 in use
Egress queues: 8 supported, 4 in use
Queue: 0, Forwarding classes: best-effort
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
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
[edit class-of-service]
lab@srxA-1# set interfaces ge-0/0/1 unit 0 rewrite-rules inet-precedence
default
[edit class-of-service]
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.
[edit class-of-service]
lab@srxA-1# set interfaces ge-0/0/1 unit 0 classifiers inet-precedence default
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 5.6
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
vr20V device to the remote vr20V 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
Remember to reference the appropriate
instance name when sourcing ICMP traffic
from a virtual router. The instance names
match the virtual router names listed on
the network diagram.
Step 5.7
Return to the session opened to your assigned student device.
Step 5.8
Return to the session opened to your assigned virtual router.
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
Remember to reference the appropriate
instance name when sourcing traffic from a
virtual router. The instance names match
the virtual router names listed on the
network diagram.
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.
lab@srxA-1> show interfaces queue ge-0/0/4
Physical interface: ge-0/0/4, Enabled, Physical link is Up
Interface index: 135, SNMP ifIndex: 128
Forwarding classes: 8 supported, 4 in use
Egress queues: 8 supported, 4 in use
Queue: 0, Forwarding classes: best-effort
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets : 0 0 pps
Low : 0 0 pps
Medium-low : 0 0 pps
Medium-high : 0 0 pps
High : 0 0 pps
RED-dropped bytes : 0 0 bps
Low : 0 0 bps
Medium-low : 0 0 bps
Medium-high : 0 0 bps
High : 0 0 bps
Queue: 1, Forwarding classes: admin
Queued:
Packets : 100 0 pps
Bytes : 10200 0 bps
Transmitted:
Packets : 100 0 pps
Bytes : 10200 0 bps
Tail-dropped packets : 0 0 pps
Step 5.10
Log out of your assigned device using the exit command.
lab@srxA-1> exit
srxA-1 (ttyu0)
login: