Junos Routing Essentials - 1 File Download

1194 North Mathilda AvenueSunnyvale, CA 94089USA408-745-2000www.juniper.net

Worldwide Education ServicesWorldwide Education Services

Junos Routing Essentials12.a

Detailed Lab Guide

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.

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.

Junos Routing Essentials Detailed Lab Guide, Revision 12.a

Copyright © 2012, Juniper Networks, Inc.

All rights reserved. Printed in USA.

Revision History:

Revision 9.a—July 2009

Revision 9.b—October 2009

Revision 10.a—May 2010

Revision 10.b—December 2010

Revision 11.a—June 2011

Revision 12.a—June 2012

The information in this document is current as of the date listed above.

The information in this document has been carefully verified and is believed to be accurate for software Release 12.1R1.9. Juniper Networks assumes no responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.

www.juniper.net Contents • iii

Contents

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

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

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

Lab 4: Class of Service (Optional)(Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1Part 1: Preparing the System and Verifying Proper Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Part 2: Configuring Queues and Scheduler Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8Part 3: Configuring Multifield Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12Part 4: Verifying the Operation of the Multifield Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14Part 5: Configuring BA Rewrite Rules and Classifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24

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

iv • Contents www.juniper.net

www.juniper.net Course Overview • v

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.

ObjectivesAfter 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 AudienceThis course benefits individuals responsible for configuring and monitoring devices running the Junos OS.

Course LevelThe Junos Routing Essentials course is a one-day introductory course.

PrerequisitesStudents 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.

vi • Course Agenda www.juniper.net

Course Agenda

Day 1Chapter 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)

www.juniper.net Document Conventions • vii

Document Conventions

CLI and GUI TextFrequently 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.

Input Text Versus Output TextYou 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.

Defined and Undefined Syntax VariablesFinally, 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

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.


Normal CLI

Normal GUI

No distinguishing variant. Physical interface:fxp0, Enabled

View configuration history by clicking Configuration > History.

CLI Input

GUI Input

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

Select File > Save, and type config.ini in the Filename field.


CLI Variable

GUI Variable

Text where variable value is already assigned.

policy my-peers

Click my-peers in the dialog.

CLI Undefined

GUI Undefined

Text where the variable’s value is the user’s discretion and text where the variable’s 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.

viii • Additional Information www.juniper.net

Additional Information

Education Services OfferingsYou 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 PublicationThe 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 [email protected].

Technical PublicationsYou 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 SupportFor technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).

www.juniper.net Routing Fundamentals (Detailed) • Lab 1–112.a.12.1R1.9

Lab 1Routing 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:

• Configure and verify proper operation of network interfaces.

• Configure and monitor static routing.

• Configure and monitor OSPF.

Junos Routing Essentials

Lab 1–2 • Routing Fundamentals (Detailed) www.juniper.net

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.

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 team’s station. The following example uses a simple Telnet access to srxA-1 with the Secure CRT program as a basis:

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.


www.juniper.net Routing Fundamentals (Detailed) • Lab 1–3

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: labPassword:

--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTClab@srxA-1> configure Entering configuration mode

[edit]lab@srxA-1# load override jre/lab1-start.config load complete

[edit]lab@srxA-1# commit and-quitcommit completeExiting 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

inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

10.210.14.128/27 *[Direct/0] 23:39:24 > via ge-0/0/0.010.210.14.131/32 *[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:



lab@srxA-1> show route all


10.210.14.128/27 *[Direct/0] 00:07:26 > via ge-0/0/0.010.210.14.131/32 *[Local/0] 00:07:40 Local via ge-0/0/0.0

__juniper_private1__.inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

10.0.0.1/32 *[Direct/0] 00:08:16 > via lo0.1638510.0.0.6/32 *[Local/0] 00:07:39 Local via sp-0/0/0.1638310.0.0.16/32 *[Direct/0] 00:08:16 > via lo0.16385 [Direct/0] 00:07:33 > via sp-0/0/0.16383128.0.0.1/32 *[Direct/0] 00:08:16 > via lo0.16385128.0.0.4/32 *[Direct/0] 00:08:16 > via lo0.16385128.0.0.6/32 *[Local/0] 00:07:39 Local via sp-0/0/0.16383128.0.1.16/32 *[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)+ = Active Route, - = Last Active, * = Both

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.



Step 1.5

Enter configuration mode and navigate to the [edit interfaces] hierarchy level.

lab@srxA-1> configure Entering configuration mode

[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/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; } }



}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]lab@srxA-1# commit and-quit commit completeExiting 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 Remotege-0/0/0 up up ge-0/0/0.0 up up inet 10.210.14.131/27gr-0/0/0 up up



ip-0/0/0 up up lsq-0/0/0 up up lt-0/0/0 up up mt-0/0/0 up up pd-0/0/0 up up pe-0/0/0 up up ge-0/0/1 up up ge-0/0/1.0 up up inet 172.20.77.1/30 ge-0/0/2 up up ge-0/0/2.0 up up inet 172.20.66.1/30 ge-0/0/3 up up ge-0/0/3.0 up up inet 172.18.1.2/30 ge-0/0/4 up up ge-0/0/4.101 up up inet 172.20.101.1/24 ge-0/0/4.32767 up up ge-0/0/5 up downge-0/0/6 up downge-0/0/7 up downge-0/0/8 up downge-0/0/9 up downge-0/0/10 up downge-0/0/11 up downge-0/0/12 up downge-0/0/13 up downge-0/0/14 up downge-0/0/15 up downgre up up ipip up up lo0 up up lo0.0 up up inet 192.168.1.1 --> 0/0lo0.16384 up up inet 127.0.0.1 --> 0/0lo0.16385 up up inet 10.0.0.1 --> 0/0 10.0.0.16 --> 0/0 128.0.0.1 --> 0/0 128.0.1.16 --> 0/0 inet6 fe80::226:88ff:fe02:6700lo0.32768 up up lsi up up mtun up up pimd up up pime up up pp0 up up st0 up up tap up up vlan up up



Question: What are the Admin and Link states for the recently configured interfaces?

Answer: The configured interfaces should all show Admin and Link states of up, as shown in the previous output. If the configured interfaces are in the down state, contact your instructor.

Step 1.9

Issue the show route command to view the current route entries.



10.210.14.128/27 *[Direct/0] 02:17:46 > via ge-0/0/0.010.210.14.131/32 *[Local/0] 02:17:50 Local via ge-0/0/0.0172.18.1.0/30 *[Direct/0] 00:02:03 > via ge-0/0/3.0172.18.1.2/32 *[Local/0] 00:02:03 Local via ge-0/0/3.0172.20.66.0/30 *[Direct/0] 00:02:03 > via ge-0/0/2.0172.20.66.1/32 *[Local/0] 00:02:03 Local via ge-0/0/2.0172.20.77.0/30 *[Direct/0] 00:02:03 > via ge-0/0/1.0172.20.77.1/32 *[Local/0] 00:02:03 Local via ge-0/0/1.0172.20.101.0/24 *[Direct/0] 00:02:03 > via ge-0/0/4.101172.20.101.1/32 *[Local/0] 00:02:03 Local via ge-0/0/4.101192.168.1.1/32 *[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.



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 lossround-trip min/avg/max/stddev = 3.560/5.276/26.080/4.364 ms






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.

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 bytesping: sendto: No route to hostping: sendto: No route to hostping: sendto: No route to hostping: sendto: No route to host^C--- 172.31.15.1 ping statistics ---4 packets transmitted, 0 packets received, 100% packet loss

Use Ctrl+c to stop a continuous ping operation.



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 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


0.0.0.0/0 *[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.

[edit routing-options]lab@srxA-1# run ping 172.31.15.1 PING 172.31.15.1 (172.31.15.1): 56 data bytes64 bytes from 172.31.15.1: icmp_seq=0 ttl=64 time=5.446 ms64 bytes from 172.31.15.1: icmp_seq=1 ttl=64 time=3.558 ms64 bytes from 172.31.15.1: icmp_seq=2 ttl=64 time=4.889 ms64 bytes from 172.31.15.1: icmp_seq=3 ttl=64 time=3.727 ms64 bytes from 172.31.15.1: icmp_seq=4 ttl=64 time=16.563 ms64 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 lossround-trip min/avg/max/stddev = 3.558/6.407/16.563/4.588 ms

Note

The Internet host should contain the required routes to send traffic back to the student devices.



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.

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# 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

Note

Refer to the network diagram, as needed, for the subsequent lab steps.





[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 completeExiting 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


0.0.0.0/0 *[Static/5] 00:11:06 > to 172.18.1.1 via ge-0/0/3.0172.20.102.0/24 *[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.0192.168.1.2/32 *[Static/5] 00:00:44



> to 172.20.101.10 via ge-0/0/4.101192.168.2.1/32 *[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.0192.168.2.2/32 *[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.




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]lab@srxA-1#



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 team’s device and the directly connected virtual router. Ensure that you also include the lo0 interface. Issue the show command to view the resulting configuration.

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

[edit protocols ospf]lab@srxA-1# set area 0 interface ge-0/0/1.0

[edit protocols ospf]lab@srxA-1# set area 0 interface ge-0/0/2.0

[edit protocols ospf]lab@srxA-1# set area 0 interface ge-0/0/4.vlan-id

[edit protocols ospf]lab@srxA-1# set area 0 interface lo0.0

[edit protocols ospf]lab@srxA-1# show area 0.0.0.0 { interface ge-0/0/1.0; interface ge-0/0/2.0; interface ge-0/0/4.101; 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.

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).



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.

[edit protocols ospf]lab@srxA-1# commit commit complete

[edit protocols ospf]lab@srxA-1# run show ospf neighbor Address Interface State ID Pri Dead172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 37172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 37172.20.101.10 ge-0/0/4.101 Full 192.168.1.2 128 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 device’s route table.

[edit protocols ospf]lab@srxA-1# run show route protocol ospf


172.20.102.0/24 [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.0192.168.1.2/32 [OSPF/10] 00:02:14, metric 1 > to 172.20.101.10 via ge-0/0/4.101192.168.2.1/32 [OSPF/10] 00:01:33, metric 1 to 172.20.77.2 via ge-0/0/1.0

Note

The OSPF adjacency state for each neighbor is dependent on that neighbor’s configuration. Ensure that the neighboring team has added the required OSPF configuration and committed the changes. The virtual routers contain preconfigured settings added by your instructor.



> to 172.20.66.2 via ge-0/0/2.0192.168.2.2/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.0224.0.0.5/32 *[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.

[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# 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.


lab@srxA-1> show route protocol ospf


172.20.102.0/24 *[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.0192.168.1.2/32 *[OSPF/10] 00:07:54, metric 1 > to 172.20.101.10 via ge-0/0/4.101192.168.2.1/32 *[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.0192.168.2.2/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.0224.0.0.5/32 *[OSPF/10] 00:08:04, metric 1 MultiRecv

lab@srxA-1>



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.




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 device’s route table.

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.

www.juniper.net Routing Policy (Detailed) • Lab 2–112.a.12.1R1.9

Lab 2Routing Policy (Detailed)

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.



• Prepare your device and verify operation.

• Configure and monitor routing policy.


Lab 2–2 • Routing Policy (Detailed) www.juniper.net

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

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: labPassword:


www.juniper.net Routing Policy (Detailed) • Lab 2–3



[edit]lab@srxA-1# commitcommit 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 protocols ospf]lab@srxA-1# show area 0.0.0.0 { interface ge-0/0/1.0; interface ge-0/0/2.0; interface ge-0/0/4.101; interface lo0.0;}

[edit protocols ospf]lab@srxA-1# delete area 0 interface ge-0/0/4.vlan-id


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 team’s device. Use the local virtual router as the next-hop. Refer to the network diagram for the destination subnet and next-hop information.

[edit protocols ospf]lab@srxA-1# top edit routing-options






[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;}


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 *[Static/5] 01:30:15 > to 172.18.1.1 via ge-0/0/3.0172.21.0.0/24 *[Static/5] 00:00:21 > to 172.20.101.10 via ge-0/0/4.101172.21.1.0/24 *[Static/5] 00:00:21 > to 172.20.101.10 via ge-0/0/4.101172.21.2.0/24 *[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.



Step 1.8

Use the ping utility to verify reachability to the subnets connected to the local virtual router.





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 State ID Pri Dead172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 39172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 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]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]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

[edit policy-options policy-statement default-route]lab@srxA-1# set term match-default-static-route from route-filter 0/0 exact

[edit policy-options policy-statement default-route]lab@srxA-1# set term match-default-static-route then accept

[edit policy-options policy-statement default-route]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.

[edit policy-options policy-statement default-route]lab@srxA-1# top edit protocols ospf

[edit protocols ospf]lab@srxA-1# set export default-route


[edit protocols ospf]

lab@srxA-1#

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


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.



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 device’s 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 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



[edit policy-options]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

[edit policy-options policy-statement interface-routes]lab@srxA-1# set term match-interface-routes from route-filter address/24 exact

[edit policy-options policy-statement interface-routes]lab@srxA-1# set term match-interface-routes then accept

[edit policy-options policy-statement interface-routes]lab@srxA-1# show term match-interface-routes { from { route-filter 172.18.1.0/30 exact; route-filter 172.20.101.0/24 exact; } then accept;}

[edit policy-options policy-statement interface-routes]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.

[edit policy-options policy-statement interface-routes]lab@srxA-1# top edit protocols ospf

[edit protocols ospf]lab@srxA-1# set export interface-routes


[edit protocols ospf]lab@srxA-1#

Note




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 device’s routing table.



0.0.0.0/0 [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.0172.18.2.0/30 *[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.0172.20.102.0/24 *[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.0192.168.2.1/32 *[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.0224.0.0.5/32 *[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.


[edit policy-options]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



[edit policy-options policy-statement other-static-routes]lab@srxA-1# set term match-other-static-routes from route-filter address/24 exact



[edit policy-options policy-statement other-static-routes]lab@srxA-1# set term match-other-static-routes then accept

[edit policy-options policy-statement other-static-routes]lab@srxA-1# show term match-other-static-routes { from { protocol static; route-filter 172.21.0.0/24 exact; route-filter 172.21.1.0/24 exact; route-filter 172.21.2.0/24 exact; } then accept;}

[edit policy-options policy-statement other-static-routes]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.

[edit policy-options policy-statement other-static-routes]lab@srxA-1# top edit protocols ospf

[edit protocols ospf]lab@srxA-1# set export other-static-routes



Note




Step 2.10

Issue the run show route protocol ospf command. Verify that your device 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 device’s routing table.



0.0.0.0/0 [OSPF/150] 01:13:36, 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.0172.18.2.0/30 *[OSPF/150] 01:06: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.0172.20.102.0/24 *[OSPF/150] 01:06: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.0172.22.0.0/24 *[OSPF/150] 00:00:48, 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.0172.22.1.0/24 *[OSPF/150] 00:00:48, 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.0172.22.2.0/24 *[OSPF/150] 00:00:48, 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.0192.168.2.1/32 *[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.0224.0.0.5/32 *[OSPF/10] 01:44:47, metric 1 MultiRecv


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.11

Return to the [edit policy-options] hierarchy level and display the configured policies.




[edit policy-options]lab@srxA-1# show policy-statement default-route { term match-default-static-route { from { protocol static; route-filter 0.0.0.0/0 exact; } then accept; }}policy-statement interface-routes { term match-interface-routes { from { route-filter 172.18.1.0/30 exact; route-filter 172.20.101.0/24 exact; } then accept; }}policy-statement other-static-routes { term match-other-static-routes { from { protocol static; route-filter 172.21.0.0/24 exact; route-filter 172.21.1.0/24 exact; route-filter 172.21.2.0/24 exact; } then accept; }}

[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

[edit policy-options policy-statement ospf-export]lab@srxA-1# set term match-default-static-route from protocol static

[edit policy-options policy-statement ospf-export]lab@srxA-1# set term match-default-static-route from route-filter 0/0 exact

[edit policy-options policy-statement ospf-export]lab@srxA-1# set term match-default-static-route then accept

[edit policy-options policy-statement ospf-export]lab@srxA-1# set term match-interface-routes from route-filter address/30 exact




[edit policy-options policy-statement ospf-export]lab@srxA-1# set term match-interface-routes then accept

[edit policy-options policy-statement ospf-export]lab@srxA-1# set term match-other-static-routes from protocol static

[edit policy-options policy-statement ospf-export]lab@srxA-1# set term match-other-static-routes from route-filter address/24 exact



[edit policy-options policy-statement ospf-export]lab@srxA-1# set term match-other-static-routes then accept

[edit policy-options policy-statement ospf-export]lab@srxA-1#

Step 2.13

Navigate to the [edit protocols ospf] hierarchy level and delete the applied export policies.

[edit policy-options policy-statement ospf-export]lab@srxA-1# top edit protocols ospf

[edit protocols ospf]lab@srxA-1# delete export


Step 2.14

Apply the ospf-export policy as an OSPF export policy and activate the changes using the commit command.

[edit protocols ospf]lab@srxA-1# set export ospf-export




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.



0.0.0.0/0 [OSPF/150] 01:21:15, 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.0172.18.2.0/30 *[OSPF/150] 01:14:10, 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.0172.20.102.0/24 *[OSPF/150] 01:14:10, 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.0172.22.0.0/24 *[OSPF/150] 00:08:27, 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.0172.22.1.0/24 *[OSPF/150] 00:08:27, 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.0172.22.2.0/24 *[OSPF/150] 00:08:27, 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.0192.168.2.1/32 *[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.0224.0.0.5/32 *[OSPF/10] 01:52:26, metric 1 MultiRecv


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 properly defined and applied the required policy.

Note




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.


[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 completeExiting configuration mode

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 Firewall Filters (Detailed) • Lab 3–112.a.12.1R1.9

Lab 3Firewall Filters (Detailed)

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.




• Configure and monitor firewall filters.


Lab 3–2 • Firewall Filters (Detailed) www.juniper.net


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



www.juniper.net Firewall Filters (Detailed) • Lab 3–3

srxA-1 (ttyp0)

login: labPassword:




[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 { interface ge-0/0/0.0; } https { system-generated-certificate; interface all; }}[edit system services]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.



Step 1.5

Enable the ftp service and activate the configuration change using the commit command.

[edit system services]lab@srxA-1# set ftp

[edit system services]lab@srxA-1# commit commit complete

Step 1.6

Open a separate Telnet session to the vr-device.

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.



Step 1.7

Log in to the virtual router attached to your team’s device using the login information shown in the following table:

vr-device (ttyp0)

login: usernamePassword:

--- 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 device’s loopback address and the Internet host. Refer to the network diagram associated with this lab as needed.

Note

a1@vr-device> ping routing-instance local_instance address rapid count 25PING 192.168.1.1 (192.168.1.1): 56 data bytes!!!!!!!!!!!!!!!!!!!!!!!!!--- 192.168.1.1 ping statistics ---

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

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.



25 packets transmitted, 25 packets received, 0% packet lossround-trip min/avg/max/stddev = 2.532/7.853/123.251/23.561 ms

a1@vr-device> ping routing-instance local_instance 172.31.15.1 rapid count 25PING 172.31.15.1 (172.31.15.1): 56 data bytes!!!!!!!!!!!!!!!!!!!!!!!!!--- 172.31.15.1 ping statistics ---25 packets transmitted, 25 packets received, 0% packet lossround-trip min/avg/max/stddev = 3.965/5.700/7.183/0.915 ms


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

a1@vr-device> ftp routing-instance local_instance addressConnected to 192.168.1.1.220 srxA-1 FTP server (Version 6.00LS) ready.Name (192.168.1.1:a1): lab331 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.

Remember to reference the appropriate instance name when initiating an FTP session from a virtual router. The instance names match the virtual router names listed on the network diagram.



Step 1.10

Issue the bye command to close the established FTP session.

ftp> bye221 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@addressThe 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)? yesWarning: Permanently added '10.210.14.131' (RSA) to the list of known [email protected]'s password: --- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTClab@srxA-1>

Question: Does the SSH session establish successfully?

Answer: Yes, as shown in the capture, the SSH session does establish successfully.

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

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.



a1@vr-device> telnet routing-instance local_instance address Trying 192.168.1.1...Connected to 192.168.1.1.Escape character is '^]'.

srxA-1 (ttyp0)

login: labPassword:

--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTClab@srxA-1>

Question: Does the Telnet session establish successfully?

Answer: Yes, as shown in the capture, the Telnet session does establish successfully.

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>

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 Dead172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 37172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 34

[edit system services]lab@srxA-1# run show route

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

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.



+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[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.010.210.14.128/27 *[Direct/0] 17:07:19 > via ge-0/0/0.010.210.14.131/32 *[Local/0] 17:07:23 Local via ge-0/0/0.0172.18.1.0/30 *[Direct/0] 14:51:36 > via ge-0/0/3.0172.18.1.2/32 *[Local/0] 14:51:36 Local via ge-0/0/3.0172.18.2.0/30 *[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.0172.20.66.0/30 *[Direct/0] 14:51:36 > via ge-0/0/2.0172.20.66.1/32 *[Local/0] 14:51:36 Local via ge-0/0/2.0172.20.77.0/30 *[Direct/0] 14:51:36 > via ge-0/0/1.0172.20.77.1/32 *[Local/0] 14:51:36 Local via ge-0/0/1.0172.20.101.0/24 *[Direct/0] 14:51:36 > via ge-0/0/4.101172.20.101.1/32 *[Local/0] 14:51:36 Local via ge-0/0/4.101172.20.102.0/24 *[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.0172.21.0.0/24 *[Static/5] 13:01:16 > to 172.20.101.10 via ge-0/0/4.101172.21.1.0/24 *[Static/5] 13:01:16 > to 172.20.101.10 via ge-0/0/4.101172.21.2.0/24 *[Static/5] 13:01:16 > to 172.20.101.10 via ge-0/0/4.101172.22.0.0/24 *[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.0172.22.1.0/24 *[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.0172.22.2.0/24 *[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.0192.168.1.1/32 *[Direct/0] 14:51:36 > via lo0.0192.168.2.1/32 *[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.0224.0.0.5/32 *[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.

[edit system services]lab@srxA-1# top



[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]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.

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-icmp from protocol icmp

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-icmp from source-address 10.210.0.0/16

[edit firewall family inet filter protect-host]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.



[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-ftp from protocol tcp port ftp

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-ftp from source-address 10.210.0.0/16

[edit firewall family inet filter protect-host]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.

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-ssh from protocol tcp port ssh

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-ssh from source-address 10.210.0.0/16

[edit firewall family inet filter protect-host]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.

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-telnet from protocol tcp port telnet

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-telnet from source-address 10.210.0.0/16

[edit firewall family inet filter protect-host]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.

[edit firewall family inet filter protect-host]lab@srxA-1# top edit interfaces lo0

[edit interfaces lo0]lab@srxA-1# set unit 0 family inet filter input protect-host

[edit interfaces lo0]lab@srxA-1# commit commit complete

[edit interfaces lo0]lab@srxA-1#



Step 2.9

Return to the session opened for the virtual router attached to your team’s device. From your assigned virtual router, use the ping utility to verify reachability to your device’s loopback address and the Internet host. Refer to the network diagram for the destination addresses when performing the ping operations.

a1@vr-device> ping routing-instance local_instance address rapid count 25PING 192.168.1.1 (192.168.1.1): 56 data bytes.........................--- 192.168.1.1 ping statistics ---25 packets transmitted, 0 packets received, 100% 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!!!!!!!!!!!!!!!!!!!!!!!!!--- 172.31.15.1 ping statistics ---25 packets transmitted, 25 packets received, 0% packet lossround-trip min/avg/max/stddev = 3.027/5.805/23.680/3.724 ms

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 device’s 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.

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

a1@vr-device> ftp routing-instance local_instance address^Ca1@vr-device> ssh routing-instance local_instance lab@address^Ca1@vr-device> telnet routing-instance local_instance addressTrying 192.168.1.1...^Ca1@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 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 lossround-trip min/avg/max/stddev = 3.796/4.507/6.888/0.874 ms

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.

Note

Use the Ctrl+c sequence to break unresponsive attempts for FTP, SSH, and Telnet sessions.



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 Connected to 10.210.14.131.220 srxA-1 FTP server (Version 6.00LS) ready.Name (10.210.14.131:a1): lab331 Password required for lab.Password:230 User lab logged in.Remote system type is UNIX.Using binary mode to transfer files.ftp> bye221 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)? yesWarning: Permanently added '10.210.14.131' (RSA) to the list of known [email protected]'s password: --- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTClab@srxA-1> exit


a1@vr-device> telnet management_addressTrying 10.210.14.131...Connected to 10.210.14.131.Escape character is '^]'.

srxA-1 (ttyp0)

login: labPassword:

--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTClab@srxA-1> exit


a1@vr-device>



Question: Do the FTP, SSH, and Telnet sessions 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.

[edit interfaces lo0]lab@srxA-1# run show ospf neighbor

[edit interfaces lo0]lab@srxA-1# run show route


0.0.0.0/0 *[Static/5] 14:48:28 > to 172.18.1.1 via ge-0/0/3.010.210.14.128/27 *[Direct/0] 17:24:37 > via ge-0/0/0.010.210.14.131/32 *[Local/0] 17:24:41 Local via ge-0/0/0.0172.18.1.0/30 *[Direct/0] 15:08:54 > via ge-0/0/3.0172.18.1.2/32 *[Local/0] 15:08:54 Local via ge-0/0/3.0172.20.66.0/30 *[Direct/0] 15:08:54 > via ge-0/0/2.0172.20.66.1/32 *[Local/0] 15:08:54 Local via ge-0/0/2.0172.20.77.0/30 *[Direct/0] 15:08:54 > via ge-0/0/1.0172.20.77.1/32 *[Local/0] 15:08:54 Local via ge-0/0/1.0172.20.101.0/24 *[Direct/0] 15:08:54 > via ge-0/0/4.101



172.20.101.1/32 *[Local/0] 15:08:54 Local via ge-0/0/4.101172.21.0.0/24 *[Static/5] 13:18:34 > to 172.20.101.10 via ge-0/0/4.101172.21.1.0/24 *[Static/5] 13:18:34 > to 172.20.101.10 via ge-0/0/4.101172.21.2.0/24 *[Static/5] 13:18:34 > to 172.20.101.10 via ge-0/0/4.101192.168.1.1/32 *[Direct/0] 15:08:54 > via lo0.0224.0.0.5/32 *[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.

[edit interfaces lo0]lab@srxA-1# deactivate unit 0 family inet filter

[edit interfaces lo0]lab@srxA-1# show unit 0 { family inet { inactive: filter { input protect-host; } address 192.168.1.1/32; }}

[edit interfaces lo0]lab@srxA-1# commit commit complete



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 Dead172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 35172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 38

[edit interfaces lo0]lab@srxA-1# run show route


0.0.0.0/0 *[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.010.210.14.128/27 *[Direct/0] 17:31:21 > via ge-0/0/0.010.210.14.131/32 *[Local/0] 17:31:25 Local via ge-0/0/0.0172.18.1.0/30 *[Direct/0] 15:15:38 > via ge-0/0/3.0172.18.1.2/32 *[Local/0] 15:15:38 Local via ge-0/0/3.0172.18.2.0/30 *[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.0172.20.66.0/30 *[Direct/0] 15:15:38 > via ge-0/0/2.0172.20.66.1/32 *[Local/0] 15:15:38 Local via ge-0/0/2.0172.20.77.0/30 *[Direct/0] 15:15:38 > via ge-0/0/1.0172.20.77.1/32 *[Local/0] 15:15:38 Local via ge-0/0/1.0172.20.101.0/24 *[Direct/0] 15:15:38 > via ge-0/0/4.101172.20.101.1/32 *[Local/0] 15:15:38 Local via ge-0/0/4.101172.20.102.0/24 *[OSPF/150] 00:00:34, metric 0, tag 0

Note




> to 172.20.77.2 via ge-0/0/1.0 to 172.20.66.2 via ge-0/0/2.0172.21.0.0/24 *[Static/5] 13:25:18 > to 172.20.101.10 via ge-0/0/4.101172.21.1.0/24 *[Static/5] 13:25:18 > to 172.20.101.10 via ge-0/0/4.101172.21.2.0/24 *[Static/5] 13:25:18 > to 172.20.101.10 via ge-0/0/4.101172.22.0.0/24 *[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.0172.22.1.0/24 *[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.0172.22.2.0/24 *[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.0192.168.1.1/32 *[Direct/0] 15:15:38 > via lo0.0192.168.2.1/32 *[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.0224.0.0.5/32 *[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?

Answer: As shown in the sample capture, your 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.



Note

[edit interfaces lo0]lab@srxA-1# top edit firewall family inet filter protect-host

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-icmp from source-address 0/0

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-icmp from source-address 10.210.0.0/16 except

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-icmp then count count-limit-icmp

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-icmp then discard

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-ftp from source-address 0/0

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-ftp from source-address 10.210.0.0/16 except

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-ftp then count count-limit-ftp

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-ftp then discard

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-ssh from source-address 0/0

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-ssh from source-address 10.210.0.0/16 except

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-ssh then count count-limit-ssh

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-ssh then discard

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-telnet from source-address 0/0

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.



[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-telnet from source-address 10.210.0.0/16 except

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-telnet then count count-limit-telnet

[edit firewall family inet filter protect-host]lab@srxA-1# set term limit-telnet then discard

[edit firewall family inet filter protect-host]lab@srxA-1# set term else-accept then count count-else-accept

[edit firewall family inet filter protect-host]lab@srxA-1# set term else-accept then accept

[edit firewall family inet filter protect-host]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;



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

[edit firewall family inet filter protect-host]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.

[edit firewall family inet filter protect-host]lab@srxA-1# top edit interfaces lo0

[edit interfaces lo0]lab@srxA-1# activate unit 0 family inet filter

[edit interfaces lo0]lab@srxA-1# show unit 0 { family inet { filter { input protect-host; } address 192.168.1.1/32; }}

[edit interfaces lo0]lab@srxA-1# commit and-quitcommit completeExiting configuration mode

lab@srxA-1>



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 State ID Pri Dead172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 36172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 36



0.0.0.0/0 *[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.010.210.14.128/27 *[Direct/0] 17:38:18 > via ge-0/0/0.010.210.14.131/32 *[Local/0] 17:38:22 Local via ge-0/0/0.0172.18.1.0/30 *[Direct/0] 15:22:35 > via ge-0/0/3.0172.18.1.2/32 *[Local/0] 15:22:35 Local via ge-0/0/3.0172.18.2.0/30 *[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.0172.20.66.0/30 *[Direct/0] 15:22:35 > via ge-0/0/2.0172.20.66.1/32 *[Local/0] 15:22:35 Local via ge-0/0/2.0172.20.77.0/30 *[Direct/0] 15:22:35 > via ge-0/0/1.0172.20.77.1/32 *[Local/0] 15:22:35 Local via ge-0/0/1.0172.20.101.0/24 *[Direct/0] 15:22:35 > via ge-0/0/4.101172.20.101.1/32 *[Local/0] 15:22:35 Local via ge-0/0/4.101172.20.102.0/24 *[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.0172.21.0.0/24 *[Static/5] 13:32:15 > to 172.20.101.10 via ge-0/0/4.101172.21.1.0/24 *[Static/5] 13:32:15 > to 172.20.101.10 via ge-0/0/4.101172.21.2.0/24 *[Static/5] 13:32:15 > to 172.20.101.10 via ge-0/0/4.101172.22.0.0/24 *[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 *[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.0172.22.2.0/24 *[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.0192.168.1.1/32 *[Direct/0] 15:22:35 > via lo0.0192.168.2.1/32 *[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.0224.0.0.5/32 *[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?

Answer: As shown in the sample capture, your student device should still show OSPF neighbor adjacencies and OSPF routes learned from the remote OSPF neighbor.

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.

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 ---25 packets transmitted, 0 packets received, 100% packet loss

Note




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.

a1@vr-device> ftp routing-instance local_instance address ^Ca1@vr-device> ssh routing-instance local_instance lab@address ^Ca1@vr-device> telnet routing-instance local_instance address Trying 192.168.1.1...^Ca1@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 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 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 ---

Note


Note

Use the Ctrl+c sequence to break unresponsive attempts for FTP, SSH, and Telnet sessions.



25 packets transmitted, 25 packets received, 0% packet lossround-trip min/avg/max/stddev = 3.532/4.622/6.082/0.812 ms

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 Connected to 10.210.14.131.220 srxA-1 FTP server (Version 6.00LS) ready.Name (10.210.14.131:a1): lab331 Password required for lab.Password:230 User lab logged in.Remote system type is UNIX.Using binary mode to transfer files.ftp> bye221 Goodbye.

a1@vr-device> ssh lab@management_address [email protected]'s password: --- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTClab@srxA-1> exit


a1@vr-device> telnet management_address Trying 10.210.14.131...Connected to 10.210.14.131.Escape character is '^]'.

srxA-1 (ttyp0)

login: labPassword:

--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTClab@srxA-1> exit


a1@vr-device>

Question: Do the FTP, SSH, and Telnet sessions 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.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 Bytes Packetscount-else-accept 18241 250count-limit-ftp 64 1count-limit-icmp 1260 15count-limit-ssh 64 1count-limit-telnet 128 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 Tell your instructor that you completed Lab 3.



www.juniper.net Class of Service (Optional)(Detailed) • Lab 4–112.a.12.1R1.9

Lab 4Class 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.




• Configure queues and scheduler maps.

• Configure multifield classification.

• Verify the operation of the multifield classifier.

• Configure behavior aggregate (BA) rewrite rules and classifiers.


Lab 4–2 • Class of Service (Optional)(Detailed) www.juniper.net


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



www.juniper.net Class of Service (Optional)(Detailed) • Lab 4–3

srxA-1 (ttyp0)

login: labPassword:




[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 lossround-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 lossround-trip min/avg/max/stddev = 3.299/9.487/124.851/23.574 ms

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 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


[edit policy-options policy-statement ospf-export]lab@srxA-1# show term match-interface-routes {



from { route-filter 172.20.101.0/24 exact; route-filter 172.20.201.0/24 exact; } then accept;}

[edit policy-options policy-statement ospf-export]lab@srxA-1# commit commit complete

[edit policy-options policy-statement ospf-export]lab@srxA-1#

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 Dead172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 35

[edit policy-options policy-statement ospf-export]lab@srxA-1# run show route protocol ospf


172.20.102.0/24 *[OSPF/150] 00:09:16, metric 0, tag 0 > to 172.20.77.2 via ge-0/0/1.0172.20.202.0/24 *[OSPF/150] 00:00:53, metric 0, tag 0 > to 172.20.77.2 via ge-0/0/1.0192.168.2.1/32 *[OSPF/10] 00:09:16, metric 1 > to 172.20.77.2 via ge-0/0/1.0224.0.0.5/32 *[OSPF/10] 1d 02:09:51, metric 1 MultiRecv

Note




Question: Does your device show an OSPF neighbor adjacency and routes learned from its neighbor?

Answer: As shown in the sample capture, your student device should show an OSPF neighbor adjacency as well as routes learned from the remote OSPF neighbor.

Step 1.9

Open a separate Telnet session to the virtual router attached to your team device.

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.10

Log in to the virtual router using the login information shown in the following table:

vr-device (ttyp0)

login: usernamePassword:

--- 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

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

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

Remember to reference the appropriate 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.



!!!!!!!!!!!!!!!!!!!!!!!!!--- 172.20.102.10 ping statistics ---25 packets transmitted, 25 packets received, 0% packet lossround-trip min/avg/max/stddev = 3.222/17.445/322.150/62.205 ms

a1@vr-device> ping routing-instance local_instance remote_vr_address rapid count 25 PING 172.20.202.10 (172.20.202.10): 56 data bytes!!!!!!!!!!!!!!!!!!!!!!!!!--- 172.20.202.10 ping statistics ---25 packets transmitted, 25 packets received, 0% packet lossround-trip min/avg/max/stddev = 3.374/9.590/124.417/23.453 ms



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.



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:

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#

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

Forwarding Class Configuration

Queue Forwarding Class Bandwidth and Buffer Allocation (%)

Priority

0 best-effort 40 Low

1 admin 45 Medium-low

2 voip 10 High

3 network-control 5 Medium-high



[edit class-of-service forwarding-classes]lab@srxA-1# set queue 1 admin

[edit class-of-service forwarding-classes]lab@srxA-1# set queue 2 voip

[edit class-of-service forwarding-classes]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 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 schedulers best-effort-sched]lab@srxA-1# set buffer-size percent 40

[edit class-of-service schedulers best-effort-sched]lab@srxA-1# set transmit-rate percent 40

[edit class-of-service schedulers best-effort-sched]lab@srxA-1# set priority low

[edit class-of-service schedulers best-effort-sched]lab@srxA-1# up

[edit class-of-service schedulers]lab@srxA-1# edit admin-sched

[edit class-of-service schedulers admin-sched]lab@srxA-1# set buffer-size percent 45

[edit class-of-service schedulers admin-sched]lab@srxA-1# set transmit-rate percent 45



[edit class-of-service schedulers admin-sched]lab@srxA-1# set priority medium-low

[edit class-of-service schedulers admin-sched]lab@srxA-1# up

[edit class-of-service schedulers]lab@srxA-1# edit voip-sched

[edit class-of-service schedulers voip-sched]lab@srxA-1# set buffer-size percent 10

[edit class-of-service schedulers voip-sched]lab@srxA-1# set transmit-rate percent 10

[edit class-of-service schedulers voip-sched]lab@srxA-1# set priority high

[edit class-of-service schedulers voip-sched]lab@srxA-1# up

[edit class-of-service schedulers]lab@srxA-1# edit network-control-sched

[edit class-of-service schedulers network-control-sched]lab@srxA-1# set buffer-size percent 5

[edit class-of-service schedulers network-control-sched]lab@srxA-1# set transmit-rate percent 5

[edit class-of-service schedulers network-control-sched]lab@srxA-1# set priority medium-high

[edit class-of-service schedulers network-control-sched]lab@srxA-1#

Step 2.4

Configure a scheduler map named my-sched-map that associates each forwarding class with its corresponding scheduler.

[edit class-of-service schedulers network-control-sched]lab@srxA-1# up 2

[edit class-of-service]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

[edit class-of-service scheduler-maps my-sched-map]lab@srxA-1# set forwarding-class admin scheduler admin-sched

[edit class-of-service scheduler-maps my-sched-map]lab@srxA-1# set forwarding-class voip scheduler voip-sched



[edit class-of-service scheduler-maps my-sched-map]lab@srxA-1# set forwarding-class network-control scheduler network-control-sched

[edit class-of-service scheduler-maps my-sched-map]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.

[edit class-of-service scheduler-maps my-sched-map]lab@srxA-1# up 2

[edit class-of-service]lab@srxA-1# edit interfaces

[edit class-of-service interfaces]lab@srxA-1# set ge-0/0/4 scheduler-map my-sched-map

[edit class-of-service interfaces]lab@srxA-1# set ge-0/0/1 scheduler-map my-sched-map

[edit class-of-service interfaces]lab@srxA-1# commit commit complete

[edit class-of-service interfaces]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.



Step 3.1

Navigate to the top of the hierarchy and load the lab4-part3-start.config file from the/var/home/lab/jre/ directory. Commit your configuration when complete.

[edit class-of-service interfaces]lab@srxA-1# top



[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

[edit firewall family inet filter classify-traffic]lab@srxA-1# set term sip from protocol [tcp udp] port 5060

[edit firewall family inet filter classify-traffic]lab@srxA-1# set term sip then forwarding-class voip

[edit firewall family inet filter classify-traffic]lab@srxA-1# set term sip then accept

[edit firewall family inet filter classify-traffic]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 16384–32767.

[edit firewall family inet filter classify-traffic]lab@srxA-1# set term rtp from source-address address/24



[edit firewall family inet filter classify-traffic]lab@srxA-1# set term rtp from protocol udp port 16384-32767

[edit firewall family inet filter classify-traffic]lab@srxA-1# set term rtp then forwarding-class voip

[edit firewall family inet filter classify-traffic]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.

[edit firewall family inet filter classify-traffic]lab@srxA-1# set term admin from source-address address/24

[edit firewall family inet filter classify-traffic]lab@srxA-1# set term admin then forwarding-class admin

[edit firewall family inet filter classify-traffic]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.

[edit firewall family inet filter classify-traffic]lab@srxA-1# set term accept-all then accept

Step 3.6

Apply the classify-traffic firewall filter to your device’s tagged interfaces to process inbound traffic from the directly attached virtual routers. Issue the commit command to activate the configuration changes.

[edit firewall family inet filter classify-traffic]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

[edit interfaces ge-0/0/4]lab@srxA-1# set unit vlan-id family inet filter input classify-traffic

[edit interfaces ge-0/0/4]lab@srxA-1# commitcommit complete

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



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

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# commit and-quitcommit completeExiting 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: 119Forwarding classes: 8 supported, 4 in useEgress queues: 8 supported, 4 in useQueue: 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 bpsQueue: 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 RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bpsQueue: 2, Forwarding classes: voip 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 bpsQueue: 3, Forwarding classes: network-control Queued: Packets : 2 0 pps Bytes : 188 368 bps Transmitted: Packets : 2 0 pps Bytes : 188 368 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

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.

a1@vr-device> ping routing-instance local_instance remote_vr_address rapid count 100 PING 172.20.102.10 (172.20.102.10): 56 data bytes!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Note




--- 172.20.102.10 ping statistics ---100 packets transmitted, 100 packets received, 0% packet lossround-trip min/avg/max/stddev = 3.299/8.634/322.981/32.003 ms

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


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: 119Forwarding classes: 8 supported, 4 in useEgress queues: 8 supported, 4 in useQueue: 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 bpsQueue: 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



RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bpsQueue: 2, Forwarding classes: voip 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 bpsQueue: 3, Forwarding classes: network-control Queued: Packets : 96 0 pps Bytes : 9008 0 bps Transmitted: Packets : 96 0 pps Bytes : 9008 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

Step 4.6





a1@vr-device> ping routing-instance local_instance remote_vr_address rapid count 100 PING 172.20.202.10 (172.20.202.10): 56 data bytes!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!--- 172.20.202.10 ping statistics ---100 packets transmitted, 100 packets received, 0% packet lossround-trip min/avg/max/stddev = 3.361/6.809/122.999/12.724 ms


Answer: Your device should assign the traffic to the admin forwarding class.

Step 4.7



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: 119Forwarding classes: 8 supported, 4 in useEgress queues: 8 supported, 4 in useQueue: 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

Note




High : 0 0 bpsQueue: 1, Forwarding classes: admin 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 bpsQueue: 2, Forwarding classes: voip 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 bpsQueue: 3, Forwarding classes: network-control Queued: Packets : 136 0 pps Bytes : 12772 0 bps Transmitted: Packets : 136 0 pps Bytes : 12772 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



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.

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 refusedtelnet: Unable to connect to remote host


Answer: Your device should assign the traffic to the voip forwarding class.

Step 4.9



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: 119Forwarding classes: 8 supported, 4 in useEgress queues: 8 supported, 4 in useQueue: 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

Note




RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bpsQueue: 1, Forwarding classes: admin 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 bpsQueue: 2, Forwarding classes: voip Queued: Packets : 1 0 pps Bytes : 78 0 bps Transmitted: Packets : 1 0 pps Bytes : 78 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 bpsQueue: 3, Forwarding classes: network-control Queued: Packets : 151 0 pps Bytes : 14182 0 bps Transmitted: Packets : 151 0 pps Bytes : 14182 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

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 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#

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/4Physical interface: ge-0/0/4, Enabled, Physical link is Up Interface index: 135, SNMP ifIndex: 128Forwarding classes: 8 supported, 4 in useEgress queues: 8 supported, 4 in useQueue: 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 bpsQueue: 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 RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bpsQueue: 2, Forwarding classes: voip 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 bpsQueue: 3, Forwarding classes: network-control 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

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

[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



[edit class-of-service]lab@srxA-1# commit and-quit commit completeExiting configuration mode

lab@srxA-1>

Step 5.6



a1@vr-device> ping routing-instance local_instance remote_vr_address rapid count 100 PING 172.20.202.10 (172.20.202.10): 56 data bytes!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!--- 172.20.202.10 ping statistics ---100 packets transmitted, 100 packets received, 0% packet lossround-trip min/avg/max/stddev = 3.361/6.809/122.999/12.724 ms

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


Note


Note





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: 128Forwarding classes: 8 supported, 4 in useEgress queues: 8 supported, 4 in useQueue: 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 bpsQueue: 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 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 bpsQueue: 2, Forwarding classes: voip 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 bpsQueue: 3, Forwarding classes: network-control 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

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




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 refusedtelnet: 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.

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: 128Forwarding classes: 8 supported, 4 in useEgress queues: 8 supported, 4 in useQueue: 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 bpsQueue: 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



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 bpsQueue: 2, Forwarding classes: voip Queued: Packets : 1 0 pps Bytes : 64 0 bps Transmitted: Packets : 1 0 pps Bytes : 64 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 bpsQueue: 3, Forwarding classes: network-control 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



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.


Appendix A: Lab Diagrams


A–2 • Lab Diagrams www.juniper.net


www.juniper.net Lab Diagrams • A–3















Documents

Junos Routing Essentials - 1 File Download