AJEX_10.b-R_LGD

Advanced Junos Enterprise Switching 10.b

Detailed Lab Guide

Worldwide Education Services 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408-745-2000 www.juniper.net Course Number: EDU-JUN-AJEX

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. Advanced Junos Enterprise Switching Detailed Lab Guide, Revision 10.b Copyright © 2011 Juniper Networks, Inc. All rights reserved. Printed in USA. Revision History: Revision 10.a—April 2011 Revision 10.b—June 2011 The information in this document is current as of the date listed above. The information in this document has been carefully verified and is believed to be accurate for software Release 10.4R3.4. Juniper Networks assumes no responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.

Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. YEAR 2000 NOTICE Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036. SOFTWARE LICENSE The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should consult the software license for further details.

Contents Lab 1:

Advanced Ethernet Switching (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 Part 1: Logging In Using the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Part 2: Configuring and Monitoring Filter-Based VLAN Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 Part 3: Configuring and Monitoring a PVLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8 Part 4: Configuring and Monitoring MVRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13 Part 5: Configuring and Monitoring Q-in-Q Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16

Lab 2:

Implementing MSTP and VSTP (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 Part 1: Modifying the Existing Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 Part 2: Configuring and Monitoring MSTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 Part 3: Configuring and Monitoring VSTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12

Lab 3:

Authentication and Access Control (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . 3-1 Part 1: Modifying the Existing Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 Part 2: Configuring 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5 Part 3: Configuring and Monitoring Other Access and Authentication Features . . . . . . . . . . . . . . . . . . . . . . 3-12

Lab 4:

Deploying IP Telephony Features (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 Part 1: Modifying the Existing Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 Part 2: Configuring and Monitoring PoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 Part 3: Configuring and Monitoring LLDP and LLDP-MED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7 Part 4: Configuring and Monitoring the Voice VLAN Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13

Lab 5:

Class of Service (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 Part 1: Exploring the Default CoS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2 Part 2: Configuring and Monitoring CoS Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8 Part 3: Implementing CoS Using the EZQoS Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20

Lab 6:

Monitoring and Troubleshooting Layer 2 Networks (Detailed) . . . . . . . . . . . 6-1 Part 1: Modifying the Existing Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2 Part 2: Determining Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 Part 3: Verifying Hardware Components and System Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4 Part 4: Verifying Ethernet Switching, MSTP, and Aggregate Ethernet Interfaces . . . . . . . . . . . . . . . . . . . . . 6-10 Part 5: Configuring Port Mirroring and sFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31

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

www.juniper.net

Contents • iii

iv • Contents

www.juniper.net

Course Overview This two-day course provides detailed coverage of virtual LAN (VLAN) operations, Multiple Spanning Tree Protocol (MSTP) and VLAN Spanning Tree Protocol (VSTP), authentication and access control for Layer 2 networks, IP telephony features, class of service (CoS) and monitoring and troubleshooting tools and features supported on the EX Series Ethernet Switches. Through demonstrations and hands-on labs, students will gain experience in configuring and monitoring the Junos operating system and in monitoring device and protocol operations.

Objectives After successfully completing this course, you should be able to: •

Implement filter-based VLAN assignments.

•

Restrict traffic flow within a VLAN.

•

Manage dynamic VLAN registration.

•

Tunnel Layer 2 traffic through Ethernet networks.

•

Review the purpose and operations of a spanning tree.

•

Implement multiple spanning tree instances in a network.

•

Implement one or more spanning tree instances for a VLAN.

•

List the benefits of implementing end-user authentication.

•

Explain the operations of various access control features.

•

Configure and monitor various access control features.

•

Describe processing considerations when multiple authentication and access control features are enabled.

•

Describe some common IP telephony deployment scenarios.

•

Describe features that facilitate IP telephony deployments.

•

Configure and monitor features used in IP telephony deployments.

•

Explain the purpose and basic operations of class of service.

•

Describe class of service features used in Layer 2 networks.

•

Configure and monitor class of service in a Layer 2 network.

•

Describe a basic troubleshooting method.

•

List common issues that disrupt network operations.

•

Identify tools used in network troubleshooting.

•

Use available tools to resolve network issues.

Intended Audience This course benefits individuals responsible for configuring and monitoring EX Series switches.

Course Level Advanced Junos Enterprise Switching is an advanced-level course.

Prerequisites Students should have an intermediate-level of 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), the Junos Routing Essentials (JRE), and the Junos Enterprise Switching (JEX) courses prior to attending this class.

www.juniper.net

Course Overview • v

Course Agenda Day 1 Chapter 1: Course Introduction Chapter 2: Advanced Ethernet Switching Lab 1: Advanced Ethernet Switching (Detailed) Chapter 3: Advanced Spanning Tree Lab 2: Implementing MSTP and VSTP (Detailed) Chapter 4: Authentication and Access Control Lab 3: Authentication and Access Control (Detailed)

Day 2 Chapter 5: Deploying IP Telephony Features Lab 4: Deploying IP Telephony Features (Detailed) Chapter 6: Class of Service Lab 5: Class of Service (Detailed) Chapter 7:

Monitoring and Troubleshooting Lab 6: Monitoring and Troubleshooting Layer 2 Networks (Detailed)

vi • Course Agenda

www.juniper.net

Document Conventions CLI and GUI Text Frequently throughout this course, we refer to text that appears in a command-line interface (CLI) or a graphical user interface (GUI). To make the language of these documents easier to read, we distinguish GUI and CLI text from chapter text according to the following table. Style

Description

Usage Example

Franklin Gothic

Normal text.

Most of what you read in the Lab Guide and Student Guide.

Courier New

Console text: •

Screen captures

commit complete

•

Noncommand-related syntax

Exiting configuration mode

GUI text elements: • Menu names • Text field entry

Select File > Open, and then click Configuration.conf in the Filename text box.

Input Text Versus Output Text You will also frequently see cases where you must enter input text yourself. Often these instances will be shown in the context of where you must enter them. We use bold style to distinguish text that is input versus text that is simply displayed. Style

Description

Usage Example

Normal CLI

No distinguishing variant.

Physical interface:fxp0, Enabled

Normal GUI

View configuration history by clicking Configuration > History. CLI Input

Text that you must enter.

lab@San_Jose> show route Select File > Save, and type config.ini in the Filename field.

GUI Input

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

Description

Usage Example

CLI Variable

Text where variable value is already assigned.

policy my-peers

Text where the variable’s value is the user’s discretion or text where the variable’s value as shown in the lab guide might differ from the value the user must input according to the lab topology.

Type set policy policy-name.

GUI Variable CLI Undefined

GUI Undefined

www.juniper.net

Click my-peers in the dialog.

ping 10.0.x.y Select File > Save, and type filename in the Filename field.

Document Conventions • vii

Additional Information Education Services Offerings You can obtain information on the latest Education Services offerings, course dates, and class locations from the World Wide Web by pointing your Web browser to: http://www.juniper.net/training/education/.

About This Publication The Advanced Junos Enterprise Switching Detailed Lab Guide was developed and tested using software Release 10.4R3.4. 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 Publications You can print technical manuals and release notes directly from the Internet in a variety of formats: •

Go to http://www.juniper.net/techpubs/.

•

Locate the specific software or hardware release and title you need, and choose the format in which you want to view or print the document.

Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.

Juniper Networks Support For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).

viii • Additional Information

www.juniper.net

Lab 1 Advanced Ethernet Switching (Detailed)

Overview In this lab, you familiarize yourself with the starting configuration and the lab environment. You will also use the command-line interface (CLI) to configure and monitor various Ethernet switching features covered in the corresponding lecture. The lab is available in two formats: a high-level format designed to make you think through each step and a detailed format that offers step-by-step instructions complete with sample output from most commands. By completing this lab you will perform the following tasks:

www.juniper.net

•

Familiarize yourself with the lab environment.

•

Configure and monitor filter-based VLAN assignments.

•

Configure and monitor a private VLAN (PVLAN).

•

Configure and monitor the Multiple VLAN Registration Protocol (MVRP).

•

Configure and monitor Q-in-Q tunneling.

Advanced Ethernet Switching (Detailed) • Lab 1–1 10.b.10.4R3.4

Advanced Junos Enterprise Switching

Part 1: Logging In Using the CLI In this lab part, you familiarize yourself with the access details used to connect to the lab equipment. Once you are familiar with the access details, you will use the CLI to log in to your team’s designated switch and become familiar with this lab’s environment. Note

The lab equipment used in this class is likely to be remote from your physical location. The instructor will provide access details to get you logged in to your assigned device. Step 1.1 Ensure that you know to which switch you have been assigned. Check with your instructor if you are not certain. Consult the Management Network Diagram to determine your switch’s management address. Question: What is the management address assigned to your switch?

Answer: Your answer will depend on your assigned device and the rack of equipment you areusing. Step 1.2 Access the CLI for your switch 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 Telnet and the SecureCRT program:

Lab 1–2 • Advanced Ethernet Switching (Detailed)

www.juniper.net


Step 1.3 Log in as user lab with the password supplied by your instructor. exD-1 (ttyu0) login: lab Password: --- JUNOS 10.4R3.4 built 2011-03-19 22:06:32 UTC {master:0} lab@exD-1>

Part 2: Configuring and Monitoring Filter-Based VLAN Assignments In this lab part, you configure and monitor filter-based VLAN assignments. You will first verify the state of the starting configuration. You will then configure and apply a firewall filter used for a filter-based VLAN assignment. You will then associate the interfaces. Step 2.1 Use the show interfaces terse command to ensure ge-0/0/7.0, ge-0/0/8.0, and ge-0/0/12.0 are all enabled for Layer 2 operations and are up, both physically and administratively. {master:0} lab@exD-1> show interfaces terse | Interface Admin Link ge-0/0/7 up up ge-0/0/7.0 up up ge-0/0/8 up up ge-0/0/8.0 up up ge-0/0/12 up up ge-0/0/12.0 up up

match "Interfaces|0/0/(7|8|12)" Proto Local Remote eth-switch eth-switch eth-switch

Question: Are the referenced interfaces enabled for Layer 2 operations and up, physically and administratively?

Answer: The answer should be yes. You should see up listed under the Admin and Link columns and eth-switch under the Proto column. If your output does not match the sample output, please work with your instructor to ensure the correct starting configuration has been loaded.

www.juniper.net

Advanced Ethernet Switching (Detailed) • Lab 1–3


Step 2.2 Use the show vlans command to ensure ge-0/0/7.0 and ge-0/0/8.0 are associated with the v11 and v12 VLANs respectively. Use the same command to ensure ge-0/0/12.0 is associated with both v11 and v12. {master:0} lab@exD-1> show vlans Name Tag default

Interfaces None

v11

11 ge-0/0/7.0*, ge-0/0/12.0*

v12

12 ge-0/0/8.0*, ge-0/0/12.0*

Question: Are the referenced interfaces associated with the correct VLANs?

Answer: The answer should be yes. You should see ge-0/0/7.0 and ge-0/0/12.0 associated with VLAN v11 and ge-0/0/8.0 and ge-0/0/12.0 associated with VLAN v12. If you see something different, please work with your instructor as needed. Question: What operational mode command can you issue to determine the port modes currently assigned with the referenced interfaces?

Answer: Multiple commands are available to view port mode assignments. The following output illustrates two such commands and shows that ge-0/0/7.0 and ge-0/0/8.0 are access ports (or untagged ports), whereas ge-0/0/12.0 is a trunk port (or a tagged port): {master:0} lab@exD-1> show vlans detail VLAN: default, 802.1Q Tag: Untagged, Admin State: Enabled VLAN: v11, 802.1Q Tag: 11, Admin State: Enabled Number of interfaces: 2 (Active = 2) Untagged interfaces: ge-0/0/7.0* Tagged interfaces: ge-0/0/12.0* VLAN: v12, 802.1Q Tag: 12, Admin State: Enabled Number of interfaces: 2 (Active = 2) Untagged interfaces: ge-0/0/8.0* Lab 1–4 • Advanced Ethernet Switching (Detailed)

www.juniper.net


Tagged interfaces: ge-0/0/12.0* {master:0} lab@exD-1> show ethernet-switching interfaces Interface State VLAN members Tag Tagging ge-0/0/7.0 up v11 11 untagged ge-0/0/8.0 up v12 12 untagged ge-0/0/12.0 up v11 11 tagged v12 12 tagged

Blocking unblocked unblocked unblocked unblocked

Step 2.3 Enter configuration mode and navigate to the [edit firewall family ethernet-switching] hierarchy. Create a firewall filter named fbva that matches any source IP address in the 172.23.15.0/24 subnet and associates the related traffic with VLAN v15. Ensure that all other traffic is permitted. {master:0} lab@exD-1> configure Entering configuration mode {master:0}[edit] lab@exD-1# edit firewall family ethernet-switching

{master:0}[edit firewall family ethernet-switching] lab@exD-1# set filter fbva term match-net from source-address 172.23.15.0/24 {master:0}[edit firewall family ethernet-switching] lab@exD-1# set filter fbva term match-net then vlan v15 {master:0}[edit firewall family ethernet-switching] lab@exD-1# set filter fbva term else-accept then accept {master:0}[edit firewall family ethernet-switching] lab@exD-1# show filter fbva { term match-net { from { source-address { 172.23.15.0/24; } } ## ## Warning: Named or Non-range vlan must be set ## then vlan v15; } term else-accept { then accept; } } {master:0}[edit firewall family ethernet-switching] lab@exD-1#

www.juniper.net



Step 2.4 Navigate to the [edit interfaces] hierarchy and associate the newly defined filter with ge-0/0/7.0 as an input filter. {master:0}[edit firewall family ethernet-switching] lab@exD-1# top edit interfaces {master:0}[edit interfaces] lab@exD-1# set ge-0/0/7.0 family ethernet-switching filter input fbva {master:0}[edit interfaces] lab@exD-1#

Step 2.5 Navigate to the [edit vlans] hierarchy and define VLAN v15 to use VLAN ID 15. Associate ge-0/0/12.0 and ge-0/0/7.0 with this VLAN. Note that to correctly associate ge-0/0/7.0 with the newly defined VLAN, you must use the mapping policy statement. Activate the changes using commit. {master:0}[edit interfaces] lab@exD-1# top edit vlans {master:0}[edit vlans] lab@exD-1# set v15 vlan-id 15 {master:0}[edit vlans] lab@exD-1# set v15 interface ge-0/0/12.0 {master:0}[edit vlans] lab@exD-1# set v15 interface ge-0/0/7.0 mapping policy {master:0}[edit vlans] lab@exD-1# show v15 vlan-id 15; interface { ge-0/0/12.0; ge-0/0/7.0 { mapping { policy; } } } {master:0}[edit vlans] lab@exD-1# commit configuration check succeedscommit complete {master:0}[edit vlans] lab@exD-1#

Step 2.6 Issue the run show vlans v15 detail command and verify the designated access port and trunk port are associated with VLAN v15.


www.juniper.net


{master:0}[edit vlans] lab@exD-1# run show vlans v15 detail VLAN: v15, 802.1Q Tag: 15, Admin State: Enabled Number of interfaces: 2 (Active = 2) Tagged interfaces: ge-0/0/12.0* Mapping policy interfaces: ge-0/0/7.0*

Question: Are the expected interfaces now associated with VLAN v15?

Answer: Yes, as shown in the sample output, the ge-0/0/7.0 and ge-0/0/12.0 interfaces should both now be associated with VLAN v15. The ge-0/0/12.0 interface is a trunk port serving VLAN v15 and the ge-0/0/7.0 interface is an access port for all traffic that matches the applied mapping policy (firewall filter). Question: Based on the current configuration, with which VLAN would traffic entering ge-0/0/7.0 with an IP source address of 172.23.16.100 be associated?

Answer: Based on the current configuration, all traffic, except traffic from the 172.23.15.0/24 subnet, should be associated with VLAN v11. Traffic sourced from the 172.23.15.0/24 subnet should be associated with VLAN v15. Step 2.7 Issue the top save /var/home/lab/ajex/lab1part2.conf command to save the entire configuration. Note that you will need to reload this configuration at a later time so ensure the entire configuration is saved. {master:0}[edit vlans] lab@exD-1# top save /var/home/lab/ajex/lab1part2.conf Wrote 120 lines of configuration to '/var/home/lab/ajex/lab1part2.conf'

STOP

www.juniper.net

Before proceeding ensure that the remote team is done with Part 2.



Part 3: Configuring and Monitoring a PVLAN In this lab part, you configure and monitor a PVLAN. You will first delete the current VLAN configuration. You will then configure and monitor a PVLAN named pvlan-50 with two community VLANs named finance and sales. Refer to the network diagram for configuration details associated with this lab. Step 3.1 Delete all configuration under the [edit vlans] hierarchy level. {master:0}[edit vlans] lab@exD-1# delete Delete everything under this level? [yes,no] (no) yes

Step 3.2 Delete all configuration under the [edit firewall] hierarchy and remove the application of the fbva firewall filter from the ge-0/0/7.0 interface. {master:0}[edit vlans] lab@exD-1# top delete firewall {master:0}[edit vlans] lab@exD-1# top delete interfaces ge-0/0/7.0 family ethernet-switching filter

Step 3.3 Configure a primary VLAN named pvlan-50 with a VLAN ID of 50. Associate the ge-0/0/12 interface with this newly defined VLAN. Configure ge-0/0/12 to function as a PVLAN trunk port. {master:0}[edit vlans] lab@exD-1# set pvlan-50 vlan-id 50 interface ge-0/0/12.0 pvlan-trunk {master:0}[edit vlans] lab@exD-1# set pvlan-50 no-local-switching

Step 3.4 Use the details shown on the network diagram for this lab and configure two community VLANs: one named finance and the other named sales. Ensure that ge-0/0/7.0 and ge-0/0/8.0 are associated with their respective community VLANs and that both community VLANs are linked to the primary VLAN (pvlan-50). {master:0}[edit vlans] lab@exD-1# set finance vlan-id 41 interface ge-0/0/7.0 {master:0}[edit vlans] lab@exD-1# set finance primary-vlan pvlan-50 {master:0}[edit vlans] lab@exD-1# set sales vlan-id 42 interface ge-0/0/8.0 {master:0}[edit vlans] lab@exD-1# set sales primary-vlan pvlan-50


www.juniper.net


Step 3.5 Attempt to activate the changes using the commit command. {master:0}[edit vlans] lab@exD-1# commit error: Trunk port ge-0/0/12.0 cannot be made member of community vlan error: configuration check-out failed

Question: Does the commit operation succeed? If not can you explain why not?

Answer: No, as shown in the sample output the ge-0/0/12.0 trunk port is currently associated with one or more community VLANs. After a closer look at the active configuration it should be obvious where the problem lies: {master:0}[edit vlans] lab@exD-1# top show interfaces ge-0/0/12.0 family ethernet-switching { port-mode trunk; vlan { members all; } }

Step 3.6 Remove the vlan members all statement from the ge-0/0/12.0 interface configuration and attempt the commit operation once again. {master:0}[edit vlans] lab@exD-1# top delete interfaces ge-0/0/12.0 family ethernet-switching vlan {master:0}[edit vlans] lab@exD-1# commit configuration check succeedscommit complete

Question: Does the commit operation succeed now?

Answer: Yes, as shown in the sample output, the commit operation should now succeed. Step 3.7 Issue the run show vlans pvlan-50 extensive command to determine the current PVLAN designations for the associated interfaces and community VLANs. www.juniper.net



{master:0}[edit vlans] lab@exD-1# run show vlans pvlan-50 extensive VLAN: pvlan-50, Created at: Fri May 13 23:02:03 2011 802.1Q Tag: 50, Internal index: 9, Admin State: Enabled, Origin: Static Private VLAN Mode: Primary Protocol: Port Mode, Mac aging time: 300 seconds Number of interfaces: Tagged 1 (Active = 1), Untagged 2 (Active = 2) ge-0/0/12.0*, tagged, trunk, pvlan-trunk ge-0/0/7.0*, untagged, access ge-0/0/8.0*, untagged, access Secondary VLANs: Isolated 0, Community 2, Inter-switch-isolated 0 Community VLANs : finance sales

Question: Are the expected access and trunk ports listed in the output?

Answer: Yes, as shown in the sample output, the two access ports and the trunk port should be listed in the output. Question: Based on the output, is the ge-0/0/12.0 properly enabled as a PVLAN trunk port?

Answer: Yes, as shown in the sample output, the ge-0/0/12.0 interface should be enabled as a PVLAN trunk port. Note

You will now log in to your assigned SRX device. The gateway is configured with multiple virtual routers (VRs), which are logical devices created on your assigned gateway. Most of the configuration required for the SRX device has already been defined. You will, however, be required to modify the existing configuration throughout the labs. Refer to the Management Network Diagram for the IP address of your assigned SRX device. If needed, work with your instructor to obtain the required information.


www.juniper.net


Step 3.8 Open a separate session to your assigned gateway. Note you can connect to your gateway using the console connection through the terminal server or through a Telnet or SSH session using the SRX device’s management IP address. Consult with your instructor if you have questions.

Step 3.9 Log in to your assigned SRX device using the lab user account and the password provided by your instructor. srxD-1 (ttyu0) login: lab Password: --- JUNOS 10.4R3.4 built 2011-03-19 22:29:40 UTC lab@srxD-1>

Step 3.10 From both of the VRs attached to your assigned EX Series switch, attempt to ping the other VR attached to your assigned EX Series switch, as well as the two VRs attached to the remote student EX Series switch. Refer to the network diagram for the instance names and the IP addresses assigned to the various VRs and do not forget to reference the correct routing instance. Variable y is used to distinguish the local VR attached to your assigned EX Series switch. Variable z is used to distinguish the destination IP address of the local and remote VRs. lab@srxD-1> ping routing-instance vry1 172.24.50.z rapid PING 172.24.50.2 (172.24.50.2): 56 data bytes ..... --- 172.24.50.2 ping statistics --5 packets transmitted, 0 packets received, 100% packet loss lab@srxD-1> ping routing-instance vry1 172.24.50.z rapid PING 172.24.50.3 (172.24.50.3): 56 data bytes www.juniper.net



!!!!! --- 172.24.50.3 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.955/1.062/1.227/0.093 ms lab@srxD-1> ping routing-instance vry1 172.24.50.z rapid PING 172.24.50.4 (172.24.50.4): 56 data bytes ..... --- 172.24.50.4 ping statistics --5 packets transmitted, 0 packets received, 100% packet loss lab@srxD-1> ping routing-instance vry2 172.24.50.z rapid PING 172.24.50.1 (172.24.50.1): 56 data bytes ..... --- 172.24.50.1 ping statistics --5 packets transmitted, 0 packets received, 100% packet loss lab@srxD-1> ping routing-instance vry2 172.24.50.z rapid PING 172.24.50.3 (172.24.50.3): 56 data bytes ..... --- 172.24.50.3 ping statistics --5 packets transmitted, 0 packets received, 100% packet loss lab@srxD-1> ping routing-instance vry2 172.24.50.z rapid PING 172.24.50.4 (172.24.50.4): 56 data bytes !!!!! --- 172.24.50.4 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.025/5.862/24.405/9.272 ms

Question: Do the ping tests between the VRs associated with the same community VLANs succeed?

Answer: Yes, as expected the ping tests between the VRs associated with the same community VLANs succeed. As shown in the sample output, the ping tests between VRs in different community VLANs should not succeed. If your test shows different results, check with the remote team to ensure they have committed the required configuration and, if needed, work with your instructor.

STOP



www.juniper.net


Part 4: Configuring and Monitoring MVRP In this lab part, you configure and monitor MVRP. You will first load the configuration file saved in a previous lab part and make some minor modifications. You will then configure and monitor MVRP. Refer to the network diagram for configuration details associated with this lab. Step 4.1 Return to your EX Series switch. Navigate to the root of the hierarchy level and use the load override and commit commands to restore the configuration saved at the end of Part 2. Note that the configuration file should be in the /var/home/lab/ajex/ directory and should be named lab1part2.conf. {master:0}[edit vlans] lab@exD-1# top {master:0}[edit] lab@exD-1# load override /var/home/lab/ajex/lab1part2.conf load complete {master:0}[edit] lab@exD-1# commit configuration check succeeds commit complete {master:0}[edit] lab@exD-1#

Step 4.2 Remove the vlan members all statement from the ge-0/0/12.0 interface configuration. {master:0}[edit] lab@exD-1# delete interfaces ge-0/0/12.0 family ethernet-switching vlan

Step 4.3 Delete the ge-0/0/12.0 interface from all currently defined VLANs. Issue the commit command to activate the changes. {master:0}[edit] lab@exD-1# delete vlans v11 interface ge-0/0/12.0 {master:0}[edit] lab@exD-1# delete vlans v12 interface ge-0/0/12.0 {master:0}[edit] lab@exD-1# delete vlans v15 interface ge-0/0/12.0 {master:0}[edit] lab@exD-1# commit configuration check succeedscommit complete

www.juniper.net



Step 4.4 Issue the run show vlans command to ensure the ge-0/0/12.0 interface is no longer associated with any of the defined VLANs. {master:0}[edit] lab@exD-1# run show vlans Name Tag Interfaces default None v11 11 ge-0/0/7.0* v12 12 ge-0/0/8.0* v15 15 ge-0/0/7.0*

Question: Is the ge-0/0/12.0 interface currently associated with any of the defined VLANs?

Answer: No, as shown in the sample output, the trunk port ge-0/0/12.0 is no longer associated with any of the defined VLANs.Note that this behavior is expected based on the current configuration. Step 4.5 Enable MVRP on the ge-0/0/12.0 interface. Activate the change using the commit command. {master:0}[edit] lab@exD-1# set protocols mvrp interface ge-0/0/12.0 {master:0}[edit] lab@exD-1# commit configuration check succeedscommit complete Note

Before proceeding, ensure that the remote team in your pod finishes the previous step. Step 4.6 Issue the run show vlans command once again to determine whether the ge-0/0/12.0 interface is now associated with the defined VLANs.


www.juniper.net


{master:0}[edit] lab@exD-1# run show vlans Name Tag Interfaces default None v11 11 ge-0/0/7.0*, ge-0/0/12.0* v12 12 ge-0/0/8.0*, ge-0/0/12.0* v15 15 ge-0/0/7.0*, ge-0/0/12.0*

Question: Is the ge-0/0/12.0 interface now associated with the defined VLANs?

Answer: Yes, as shown in the sample output, the trunk port ge-0/0/12.0 is now associated with all of the defined VLANs. Note that you can also view dynamic VLAN membership associations using the show mvrp dynamic-vlan-memberships command as shown in the following: {master:0}[edit] lab@exD-1# run show mvrp dynamic-vlan-memberships MVRP dynamic vlans for routing instance 'default-switch' (s) static vlan, (f) fixed registration

VLAN ID 11(s) 12(s) 15(s)

Interfaces ge-0/0/12.0 ge-0/0/12.0 ge-0/0/12.0

Step 4.7 Issue the run show mvrp statistics command to display MVRP statistics. {master:0}[edit] lab@exD-1# run show mvrp statistics MVRP statistics Interface name : ge-0/0/12.0 MRPDU received : 15 Invalid PDU received : 0 New received : 0 Join Empty received : 12 Join In received : 33 Empty received : 0 In received : 0 Leave received : 0 LeaveAll received : 4 MRPDU transmitted : 15 MRPDU transmit failures : 0 www.juniper.net



New transmitted Join Empty transmitted Join In transmitted Empty transmitted In transmitted Leave transmitted LeaveAll transmitted

: : : : : : :

0 33 12 0 0 0 11

Question: Does the output show non-zero counters for the MRPDU received and MRPDU transmitted lines?

Answer: Yes, along with several other lines in the output the MRPDU received and MRPDU transmitted lines should show non-zero counters.

STOP


Part 5: Configuring and Monitoring Q-in-Q Tunneling In this lab part, you configure and monitor Q-in-Q tunneling. You will first modify the existing configuration file. You will then configure and monitor Q-in-Q tunneling and Layer 2 Protocol Tunneling (L2PT). Refer to the network diagram for configuration details associated with this lab. Step 5.1 Enable ge-0/0/6 for Layer 2 operations as an access port. {master:0}[edit] lab@exD-1# edit interfaces {master:0}[edit interfaces] lab@exD-1# set ge-0/0/6.0 family ethernet-switching {master:0}[edit interfaces]

Step 5.2 Configure a new VLAN named cust-1 with a VLAN ID of 200. Associate the newly defined access port (ge-0/0/6.0) with this new VLAN. Issue the commit command to activate the changes. {master:0}[edit interfaces] lab@exD-1# top edit vlans {master:0}[edit vlans] lab@exD-1# set cust-1 vlan-id 200 interface ge-0/0/6.0 Lab 1–16 • Advanced Ethernet Switching (Detailed)

www.juniper.net


{master:0}[edit vlans] lab@exD-1# commit configuration check succeedscommit complete {master:0}[edit vlans] lab@exD-1#

Step 5.3 Return to the session opened for your SRX device. From the VR attached to your assigned EX Series switch that represents the customer bridge and attached network, attempt to ping the IP address of the remote VR performing the same function for the remote team. Refer to the network diagram for the instance names and the IP address information. Do not forget to reference the correct routing instance when performing this operation. lab@srxD-1> ping routing-instance ? Possible completions: Routing instance for ping attempt vr10 vr11 vr12 lab@srxD-1> ping routing-instance vry0 172.27.100.z rapid PING 172.27.100.2 (172.27.100.2): 56 data bytes ..... --- 172.27.100.2 ping statistics --5 packets transmitted, 0 packets received, 100% packet loss

Question: Does the ping operation succeed? Can you explain why?

Answer: No, the ping operation should not succeed at this time. Remember that the current configuration expects untagged frames on the ge-0/0/6.0 interface. We remedy this situation shortly by adding Q-in-Q functionality to the cust-1 VLAN. Step 5.4 Return to the session opened for your EX Series switch. Enable Q-in-Q tunneling for all defined VLANs. Ensure that all Layer 2 protocol traffic is permitted through the Q-in-Q tunnel for traffic associated with the cust-1 VLAN. Activate the changes and return to operational mode using the commit and-quit command. {master:0}[edit vlans] lab@exD-1# set v11 dot1q-tunneling {master:0}[edit vlans] www.juniper.net



lab@exD-1# set v12 dot1q-tunneling {master:0}[edit vlans] lab@exD-1# set v15 dot1q-tunneling {master:0}[edit vlans] lab@exD-1# set cust-1 dot1q-tunneling layer2-protocol-tunneling all {master:0}[edit vlans] lab@exD-1# commit and-quit configuration check succeedscommit complete Exiting configuration mode {master:0} lab@exD-1>

Step 5.5 Issue the show vlans cust-1 detail command. {master:0} lab@exD-1> show vlans cust-1 detail VLAN: cust-1, 802.1Q Tag: 200, Admin State: Enabled Dot1q Tunneling status: Enabled Layer2 Protocol Tunneling status: Enabled Number of interfaces: 2 (Active = 2) Untagged interfaces: ge-0/0/6.0* Tagged interfaces: ge-0/0/12.0*

Question: Based on the output, are Q-in-Q tunneling and L2PT now enabled?

Answer: Yes, as shown in the sample capture, Q-in-Q tunneling and L2PT are now enabled. Step 5.6 Return to the session opened for your SRX device. Use the ping utility once again and verify reachability between customer sites. Refer to the network diagram for the instance names and the IP address information. Do not forget to reference the correct routing instance when performing this operation. lab@srxD-1> ping routing-instance vry0 172.27.100.z rapid PING 172.27.100.2 (172.27.100.2): 56 data bytes !!!!! --- 172.27.100.2 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.038/5.765/24.069/9.153 ms


www.juniper.net


Question: Does the ping operation succeed now?

Answer: Yes, as shown in sample output, the ping operation should now succeed.

STOP

www.juniper.net

Tell your instructor that you have completed Lab 1.




www.juniper.net

Lab 2 Implementing MSTP and VSTP (Detailed)

Overview In this lab, you will use the command-line interface (CLI) to configure and monitor the Multiple Spanning Tree Protocol (MSTP) and VLAN STP (VSTP). The lab is available in two formats: a high-level format designed to make you think through each step and a detailed format that offers step-by-step instructions complete with sample output from most commands. By completing this lab you will perform the following tasks:

www.juniper.net

•

Modify the existing configuration.

•

Configure and monitor MSTP.

•

Configure and monitor VSTP.

Implementing MSTP and VSTP (Detailed) • Lab 2–1 10.b.10.4R3.4


Part 1: Modifying the Existing Configuration In this lab part, you will modify the existing configuration on your EX Series switch and perform some basic verification tasks to prepare for subsequent lab parts. Refer to network diagram for this lab for topological and configuration details. Step 1.1 Enter configuration mode and configure the ge-0/0/9 and ge-0/0/10 interfaces for Layer 2 operations and as trunk ports. {master:0} lab@exD-1> configure Entering configuration mode {master:0}[edit] lab@exD-1# edit interfaces {master:0}[edit interfaces] lab@exD-1# set ge-0/0/9.0 family ethernet-switching port-mode trunk {master:0}[edit interfaces] lab@exD-1# set ge-0/0/10.0 family ethernet-switching port-mode trunk {master:0}[edit interfaces] lab@exD-1#

Step 1.2 Associate these newly defined trunk ports with all currently defined VLANs. Note that the VLANs must be statically associated with these new trunk ports, because the attached SRX devices do not support the Multiple VLAN registration Protocol (MVRP). Also note that you cannot use the vlan members all statement because Q-in-Q tunneling is in place. {master:0}[edit interfaces] lab@exD-1# top edit vlans {master:0}[edit vlans] lab@exD-1# set ? Possible completions: VLAN name + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups cust-1 VLAN name > traceoptions VLAN trace options v11 VLAN name v12 VLAN name v15 VLAN name {master:0}[edit vlans] lab@exD-1# set cust-1 interface ge-0/0/9.0 {master:0}[edit vlans] lab@exD-1# set cust-1 interface ge-0/0/10.0 {master:0}[edit vlans] Lab 2–2 • Implementing MSTP and VSTP (Detailed)

www.juniper.net


lab@exD-1# set v11 interface ge-0/0/9.0 {master:0}[edit vlans] lab@exD-1# set v11 interface ge-0/0/10.0 {master:0}[edit vlans] lab@exD-1# set v12 interface ge-0/0/9.0 {master:0}[edit vlans] lab@exD-1# set v12 interface ge-0/0/10.0 {master:0}[edit vlans] lab@exD-1# set v15 interface ge-0/0/9.0 {master:0}[edit vlans] lab@exD-1# set v15 interface ge-0/0/10.0 {master:0}[edit vlans] lab@exD-1#

Step 1.3 Activate the configuration changes using the commit command and verify the spanning-tree topology details using the run show spanning-tree bridge command. {master:0}[edit vlans] lab@exD-1# commit configuration check succeedscommit complete {master:0}[edit vlans] lab@exD-1# run show spanning-tree bridge STP bridge parameters Context ID Enabled protocol Root ID Root cost Root port Hello time Maximum age Forward delay Message age Number of topology changes Time since last topology change Topology change initiator Topology change last recvd. from Local parameters Bridge ID Extended system ID Internal instance ID

www.juniper.net

: : : : : : : : : : : : :

0 RSTP 4096.00:26:88:e1:45:10 20000 ge-0/0/9.0 2 seconds 20 seconds 15 seconds 1 4 1808 seconds ge-0/0/9.0 00:26:88:e1:4f:8a

: 32768.50:c5:8d:ba:62:00 : 0 : 0

Implementing MSTP and VSTP (Detailed) • Lab 2–3


Question: Which device is elected as the root bridge? Which interface will your switch use to forward traffic through the Layer 2 network?

Answer: The srxX-1 device should be elected the root bridge device based on its current bridge priority of 4 K. The root port, used to forward traffic through the root bridge, varies depending on your assigned switch. If you are assigned exX-1, the root port should be ge-0/0/9.0. If you are assigned exX-2, the root port should be ge-0/0/10.0. Question: What limitation exists with the current spanning-tree implementation? What options exist that overcome this limitation?

Answer: The current spanning-tree topology offers no load balancing. The links between the EX Series switches and the srxX-2 device will not be used. This problem is a known limitation of STP and RSTP. You can use MSTP or VSTP instead of RSTP to overcome this limitation. We make use of MSTP and VSTP in subsequent lab parts.

Part 2: Configuring and Monitoring MSTP In this lab part, you configure and monitor MSTP. You create two multiple spanning-tree instances (MSTIs); one for all VLAN IDs between 1 and 199, and a second for all VLAN IDs between 200 and 399. Once configured, you use various operational mode commands to monitor MSTP. Step 2.1 Delete RSTP, under the [edit protocols] hierarchy. {master:0}[edit vlans] lab@exD-1# top edit protocols {master:0}[edit protocols] lab@exD-1# show rstp; mvrp { interface ge-0/0/12.0; } {master:0}[edit protocols] lab@exD-1# delete rstp {master:0}[edit protocols] lab@exD-1# Lab 2–4 • Implementing MSTP and VSTP (Detailed)

www.juniper.net


Step 2.2 Configure MSTP to include two MSTIs (MSTI 1 and MSTI 2). Associate MSTI 1 with VLAN IDs 1 through 199 and MSTI 2 with VLAN IDs 200 through 399. Name the MSTP configuration my-mstp-config. Activate the configuration using commit. {master:0}[edit protocols] lab@exD-1# set mstp configuration-name my-mstp-config {master:0}[edit protocols] lab@exD-1# set mstp msti 1 vlan [1-199] {master:0}[edit protocols] lab@exD-1# set mstp msti 2 vlan [200-399] {master:0}[edit protocols] lab@exD-1# commit configuration check succeedscommit complete

Step 2.3 Return to the session opened for your assigned SRX device. If needed, open a new session and log in using the credentials provided by your instructor. Enter configuration mode and navigate to [edit protocols] hierarchy. lab@srxD-1> configure Entering configuration mode [edit] lab@srxD-1# edit protocols [edit protocols] lab@srxD-1#

Step 2.4 Delete the existing RSTP configuration on your assigned SRX device. [edit protocols] lab@srxD-1# delete rstp

Step 2.5 Configure MSTP to include two MSTIs (MSTI 1 and MSTI 2). Associate MSTI 1 with VLAN IDs 1 through 199 and MSTI 2 with VLAN IDs 200 through 399. Name the MSTP configuration my-mstp-config. [edit protocols] lab@srxD-1# set mstp configuration-name my-mstp-config [edit protocols] lab@srxD-1# set mstp msti 1 vlan [1-199] [edit protocols] lab@srxD-1# set mstp msti 2 vlan [200-399]

www.juniper.net



Step 2.6 Configure a non-default bridge priority for each MSTI. If you are assigned srxX-1, specify a bridge priority of 4k for MSTI 1 and 8k for MSTI 2. If you are assigned srxX-2, specify a bridge priority of 8k for MSTI 1 and 4k for MSTI 2. Activate the changes using the commit command. The following captures illustrate the commands and expected configurations for both SRX devices in pod D: [edit protocols] lab@srxD-1# set mstp msti 1 bridge-priority 4k [edit protocols] lab@srxD-1# set mstp msti 2 bridge-priority 8k [edit protocols] lab@srxD-1# show mstp { configuration-name my-mstp-config; msti 1 { bridge-priority 4k; vlan 1-199; } msti 2 { bridge-priority 8k; vlan 200-399; } } [edit protocols] lab@srxD-1# commit commit complete [edit protocols] lab@srxD-2# set mstp msti 1 bridge-priority 8k [edit protocols] lab@srxD-2# set mstp msti 2 bridge-priority 4k [edit protocols] lab@srxD-2# show mstp { configuration-name my-mstp-config; msti 1 { bridge-priority 8k; vlan 1-199; } msti 2 { bridge-priority 4k; vlan 200-399; } } [edit protocols] lab@srxD-2# commit commit complete Lab 2–6 • Implementing MSTP and VSTP (Detailed)

www.juniper.net


Question: Based on the current configurations, what forwarding paths would you expect for traffic associated with the various VLANs currently in use?

Answer: The spanning-tree topology now offers some level of load balancing for the defined VLANs. Based on the current configurations, all traffic associated with VLAN ID 200 (SVLAN assigned to the attached customer) should pass through srxX-2. The traffic associated with all other VLAN IDs (11, 12, and 15) should pass through srxX-1. Note

Before proceeding, ensure that the remote team in your pod finishes the previous step. Step 2.7 Return to the session opened for your EX Series switch. Issue the run show spanning-tree bridge command and answer the questions that follow. {master:0}[edit protocols] lab@exD-1# run show spanning-tree bridge STP bridge parameters Context ID Enabled protocol STP bridge parameters for CIST Root ID Root cost Root port CIST regional root CIST internal root cost Hello time Maximum age Forward delay Hop count Message age Number of topology changes Time since last topology change Topology change initiator Topology change last recvd. from Local parameters Bridge ID Extended system ID Internal instance ID www.juniper.net

: 0 : MSTP

: : : : : : : : : : : : : :

32768.00:26:88:e1:45:10 0 ge-0/0/9.0 32768.00:26:88:e1:45:10 20000 2 seconds 20 seconds 15 seconds 19 0 12 18 seconds ge-0/0/9.0 50:c5:8d:ae:b7:8c

: 32768.50:c5:8d:ba:62:00 : 0 : 0 Implementing MSTP and VSTP (Detailed) • Lab 2–7


STP bridge parameters for MSTI 1 MSTI regional root Root cost Root port Hello time Maximum age Forward delay Hop count Number of topology changes Topology change initiator Topology change last recvd. from Local parameters Bridge ID Extended system ID Internal instance ID STP bridge parameters for MSTI 2 MSTI regional root Root cost Root port Hello time Maximum age Forward delay Hop count Number of topology changes Topology change initiator Topology change last recvd. from Local parameters Bridge ID Extended system ID Internal instance ID

: : : : : : : : : :

4097.00:26:88:e1:45:10 20000 ge-0/0/9.0 2 seconds 20 seconds 15 seconds 19 12 ge-0/0/9.0 00:26:88:e1:4f:8a

: 32769.50:c5:8d:ba:62:00 : 0 : 1

: : : : : : : : : :

4098.00:26:88:e1:4f:90 20000 ge-0/0/10.0 2 seconds 20 seconds 15 seconds 19 12 ge-0/0/10.0 00:26:88:e1:45:09

: 32770.50:c5:8d:ba:62:00 : 0 : 2

Question: Are the expected devices elected root bridges for MSTI 1 and MSTI 2?

Answer: The answer should be yes. The srxX-1 device should be elected root bridge for MSTI 1 and the srxX-2 device should be elected root bridge for MSTI 2. If you see different results, check your configuration and ensure the remote team has finished the previous step. Question: Which device has been elected as the root bridge for the Common and Internal Spanning Tree (CIST)?

Answer: The answer might vary. In the illustrated example, srxD-1 has been elected as the root bridge for the CIST (MSTI 0).

Lab 2–8 • Implementing MSTP and VSTP (Detailed)

www.juniper.net


Question: What configuration change can you make to ensure srxX-1 is always the root bridge as long as it is available?

Answer: To ensure one device is always the root bridge when it is available, you must ensure the bridge priority for that device is set to a lower value than all other switches participating in the MSTP region. Step 2.8 On your assigned EX Series switch, issue the run show spanning-tree mstp configuration command. {master:0}[edit protocols] lab@exD-1# run show spanning-tree mstp configuration MSTP information Context identifier : 0 Region name : my-mstp-config Revision : 0 Configuration digest : 0x91ee8012e6851d931adae71da4060690

MSTI Member VLANs 0 0,400-4094 1 1-199 2 200-399

Question: Does the output display the expected VLAN to MSTI mapping information?

Answer: Yes, the output should show the correct VLAN to MSTI mapping information. You should see the previously configured ranges for MSTI 1 and MSTI 2 (1-199 and 200-399 respectively) and the remainder of the supported VLAN ID range associated with the CIST (MSTI 0). Question: Which three components in the displayed output must match for switches participating in the same MST region?

Answer: The region name, revision level, and the VLAN to MSTI mappings must match on all bridges participating in the same MST region.

www.juniper.net



Question: How is the configuration digest determined?

Answer: The configuration digest is based on the VLAN to MSTI mapping information. Note that this mapping information must match on all switches intending to participate in the same MST region. Step 2.9 Issue the top save /var/home/lab/ajex/mstp.conf command to save the current configuration on your EX Series switch to the /var/tmp directory. {master:0}[edit protocols] lab@exD-1# top save /var/home/lab/ajex/mstp.conf Wrote 166 lines of configuration to '/var/home/lab/ajex/mstp.conf'

Step 2.10 Change the revision level to test the effects of mismatched settings that are required to match on switches participating in the same MST region. If you are assigned exX-1, set your revision number to 1. If you are assigned exX-2, set your revision number to 2. Issue commit to activate the configuration change. {master:0}[edit protocols] lab@exD-1# set mstp revision-level n {master:0}[edit protocols] lab@exD-1# commit configuration check succeedscommit complete

Step 2.11 Issue the run show spanning-tree mstp configuration command to verify the change. Next issue the run show spanning-tree bridge command to verify the current state of the MSTP topology and root bridge election details. {master:0}[edit protocols] lab@exD-1# run show spanning-tree mstp configuration MSTP information Context identifier : 0 Region name : my-mstp-config Revision : 1 Configuration digest : 0x91ee8012e6851d931adae71da4060690

MSTI Member VLANs 0 0,400-4094 1 1-199 2 200-399 {master:0}[edit protocols] lab@exD-1# run show spanning-tree bridge STP bridge parameters Lab 2–10 • Implementing MSTP and VSTP (Detailed)

www.juniper.net


Context ID Enabled protocol STP bridge parameters for CIST Root ID Root cost Root port CIST regional root CIST internal root cost Hello time Maximum age Forward delay Hop count Message age Number of topology changes Time since last topology change Topology change initiator Topology change last recvd. from Local parameters Bridge ID Extended system ID Internal instance ID STP bridge parameters for MSTI 1 MSTI regional root Hello time Maximum age Forward delay Number of topology changes Topology change initiator Topology change last recvd. from Local parameters Bridge ID Extended system ID Internal instance ID STP bridge parameters for MSTI 2 MSTI regional root Hello time Maximum age Forward delay Number of topology changes Topology change initiator Topology change last recvd. from Local parameters Bridge ID Extended system ID Internal instance ID

www.juniper.net

: 0 : MSTP

: : : : : : : : : : : : : :

32768.00:26:88:e1:45:10 20000 ge-0/0/9.0 32768.50:c5:8d:ba:62:00 0 2 seconds 20 seconds 15 seconds 20 1 17 20 seconds ge-0/0/9.0 00:26:88:e1:4f:8a

: 32768.50:c5:8d:ba:62:00 : 0 : 0

: : : : : : :

32769.50:c5:8d:ba:62:00 2 seconds 20 seconds 15 seconds 17 ge-0/0/9.0 00:26:88:e1:4f:8a

: 32769.50:c5:8d:ba:62:00 : 0 : 1

: : : : : : :

32770.50:c5:8d:ba:62:00 2 seconds 20 seconds 15 seconds 16 ge-0/0/9.0 00:26:88:e1:45:09

: 32770.50:c5:8d:ba:62:00 : 0 : 2



Question: What impact did changing the revision level have on the MSTP topology and root bridge election for MSTI 1 and MSTI 2?

Answer: Because the required settings on the EX Series switches no longer match the other devices within the MST region, each EX Series switch is effectively running in isolation in new MST regions that are based on new settings. This arrangement is verified by the newly elected root bridge in each MSTI. In the sample capture, we see that exX-1 is now the elected root bridge for MSTI 1 and MSTI 2. Note that exX-2 should show a similar output with itself elected root bridge for both MSTIs.

Part 3: Configuring and Monitoring VSTP In this lab part, you configure and monitor VSTP. Once configured, you use various operational mode commands to verify VSTP operations. Note that SRX devices do not currently support VSTP. Because of this fact, you will need to alter the current topology to exclude the SRX devices for this lab part. Step 3.1 Issue the set rstp and commit commands in an attempt to enable RSTP along with MSTP. {master:0}[edit protocols] lab@exD-1# set rstp {master:0}[edit protocols] lab@exD-1# commit [edit protocols] 'mstp' Another xSTP protocol is enabled error: Another xSTP protocol is enabled error: configuration check-out failed

Question: Did the commit operation succeed? If not, why not?

Answer: No, the commit operation should not succeed because RSTP and MSTP cannot be enabled at the same time. Note that RSTP can, however, be enabled at the same time as VSTP. Lab 2–12 • Implementing MSTP and VSTP (Detailed)

www.juniper.net


Step 3.2 Delete MSTP and attempt the commit operation once again. {master:0}[edit protocols] lab@exD-1# delete mstp {master:0}[edit protocols] lab@exD-1# commit configuration check succeedscommit complete

Step 3.3 Delete the ge-0/0/9 and ge-0/0/10 interface references from under the [edit interfaces] and [edit vlans] hierarchy levels. {master:0}[edit protocols] lab@exD-1# top delete interfaces ge-0/0/9 {master:0}[edit protocols] lab@exD-1# top delete interfaces ge-0/0/10 {master:0}[edit protocols] lab@exD-1# top delete vlans cust-1 interface ge-0/0/9 {master:0}[edit protocols] lab@exD-1# top delete vlans cust-1 interface ge-0/0/10 {master:0}[edit protocols] lab@exD-1# top delete vlans v11 interface ge-0/0/9 {master:0}[edit protocols] lab@exD-1# top delete vlans v11 interface ge-0/0/10 {master:0}[edit protocols] lab@exD-1# top delete vlans v12 interface ge-0/0/9 {master:0}[edit protocols] lab@exD-1# top delete vlans v12 interface ge-0/0/10 {master:0}[edit protocols] lab@exD-1# top delete vlans v15 interface ge-0/0/9 {master:0}[edit protocols] lab@exD-1# top delete vlans v15 interface ge-0/0/10

www.juniper.net



Step 3.4 Configure VSTP to support the currently defined VLANs independently. Refer to the following table for the bridge-priority values. Activate the changes using the commit command.

exX-1

exX-2

v11

4k

8k

v12

4k

8k

v15

8k

4k

cust-1

8k

4k

{master:0}[edit protocols] lab@exD-1# set vstp vlan v11 bridge-priority yk {master:0}[edit protocols] lab@exD-1# set vstp vlan v12 bridge-priority yk {master:0}[edit protocols] lab@exD-1# set vstp vlan v15 bridge-priority yk {master:0}[edit protocols] lab@exD-1# set vstp vlan cust-1 bridge-priority yk

{master:0}[edit protocols] lab@exD-1# show vstp vlan cust-1 { bridge-priority 8k; } vlan v11 { bridge-priority 4k; } vlan v12 { bridge-priority 4k; } vlan v15 { bridge-priority 8k; } {master:0}[edit protocols] lab@exD-1# commit configuration check succeedscommit complete Note

Before proceeding, ensure that the remote team in your pod finishes the previous step.


www.juniper.net


Step 3.5 Issue the run show spanning-tree bridge command to determine the current root bridge designations for each VLAN. {master:0}[edit protocols] lab@exD-1# run show spanning-tree bridge ... STP bridge parameters for VLAN 200 Root ID : 8392.50:c5:8d:ba:62:00 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Message age : 0 Number of topology changes : 0 Local parameters Bridge ID : 8392.50:c5:8d:ba:62:00 Extended system ID : 1 Internal instance ID : 0 STP bridge parameters Context ID Enabled protocol STP bridge parameters for VLAN 11 Root ID Hello time Maximum age Forward delay Message age Number of topology changes Local parameters Bridge ID Extended system ID Internal instance ID STP bridge parameters Context ID Enabled protocol STP bridge parameters for VLAN 12 Root ID Hello time Maximum age Forward delay Message age Number of topology changes Local parameters Bridge ID Extended system ID Internal instance ID STP bridge parameters Context ID Enabled protocol www.juniper.net

: 2 : RSTP

: : : : : :

4107.50:c5:8d:ba:62:00 2 seconds 20 seconds 15 seconds 0 0

: 4107.50:c5:8d:ba:62:00 : 2 : 0

: 3 : RSTP

: : : : : :


: 4108.50:c5:8d:ba:62:00 : 3 : 0

: 4 : RSTP Implementing MSTP and VSTP (Detailed) • Lab 2–15


STP bridge parameters for VLAN 15 Root ID Hello time Maximum age Forward delay Message age Number of topology changes Local parameters Bridge ID Extended system ID Internal instance ID

: : : : : :


: 8207.50:c5:8d:ba:62:00 : 4 : 0

Question: Based on the configuration, are the correct root bridges currently elected? Can you explain why?

Answer: No, your switch is currently elected as the root bridge for all VLANs. This election does not match the expectations based on the current configuration. This situation is because of a known limitation with VSTP and MVRP. MVRP does not currently support VSTP. Because of this lack of support, you will need to manually associate the ge-0/0/12.0 interface with the defined VLANs. You will perform that task next. Step 3.6 Manually associate the ge-0/0/12.0 interface with all currently defined VLANs. Activate the configuration changes using the commit command. {master:0}[edit protocols] lab@exD-1# top edit vlans {master:0}[edit vlans] lab@exD-1# set v11 interface ge-0/0/12.0 {master:0}[edit vlans] lab@exD-1# set v12 interface ge-0/0/12.0 {master:0}[edit vlans] lab@exD-1# set v15 interface ge-0/0/12.0 {master:0}[edit vlans] lab@exD-1# set cust-1 interface ge-0/0/12.0 {master:0}[edit vlans] lab@exD-1# commit configuration check succeedscommit complete {master:0}[edit vlans] lab@exD-1# Lab 2–16 • Implementing MSTP and VSTP (Detailed)

www.juniper.net

Advanced Junos Enterprise Switching Note

Before proceeding, ensure that the remote team in your pod finishes the previous step. Step 3.7 Issue the run show spanning-tree bridge command once again to determine the current root bridge designations for each VLAN. {master:0}[edit vlans] lab@exD-1# run show spanning-tree bridge ... STP bridge parameters for VLAN 200 Root ID : 4296.50:c5:8d:ae:b7:80 Root cost : 20000 Root port : ge-0/0/12.0 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Message age : 1 Number of topology changes : 1 Time since last topology change : 5 seconds Topology change initiator : ge-0/0/12.0 Topology change last recvd. from : 50:c5:8d:ae:b7:8c Local parameters Bridge ID : 8392.50:c5:8d:ba:62:00 Extended system ID : 1 Internal instance ID : 0 STP bridge parameters Context ID Enabled protocol STP bridge parameters for VLAN 11 Root ID Hello time Maximum age Forward delay Message age Number of topology changes Time since last topology change Topology change initiator Topology change last recvd. from Local parameters Bridge ID Extended system ID Internal instance ID

: 2 : RSTP

: : : : : : : : :

4107.50:c5:8d:ba:62:00 2 seconds 20 seconds 15 seconds 0 1 7 seconds ge-0/0/12.0 50:c5:8d:ae:b7:8c

: 4107.50:c5:8d:ba:62:00 : 2 : 0

STP bridge parameters Context ID Enabled protocol

: 3 : RSTP

STP bridge parameters for VLAN 12 Root ID Hello time

: 4108.50:c5:8d:ba:62:00 : 2 seconds

www.juniper.net



Maximum age Forward delay Message age Number of topology changes Time since last topology change Topology change initiator Topology change last recvd. from Local parameters Bridge ID Extended system ID Internal instance ID STP bridge parameters Context ID Enabled protocol

: : : : : : :

20 seconds 15 seconds 0 1 7 seconds ge-0/0/12.0 50:c5:8d:ae:b7:8c

: 4108.50:c5:8d:ba:62:00 : 3 : 0

: 4 : RSTP

STP bridge parameters for VLAN 15 Root ID Root cost Root port Hello time Maximum age Forward delay Message age Number of topology changes Time since last topology change Topology change initiator Topology change last recvd. from Local parameters Bridge ID Extended system ID Internal instance ID

: : : : : : : : : : :

4111.50:c5:8d:ae:b7:80 20000 ge-0/0/12.0 2 seconds 20 seconds 15 seconds 1 1 5 seconds ge-0/0/12.0 50:c5:8d:ae:b7:8c

: 8207.50:c5:8d:ba:62:00 : 4 : 0

Question: Are the correct root bridges now elected?

Answer: Yes, the expected root bridges should now be elected. Based on the current configuration, exX-1 should be root bridge for the v11 and v12 VLANs and exX-2 should be root bridge for the v15 and cust-1 VLANs. If your results do not match the expected results, check your configuration and work with the remote team and instructor as needed.


www.juniper.net


Step 3.8 Use the load override command to restore the mstp.conf configuration file saved in the /var/home/lab/ajex/ directory. Activate the changes and return to operational mode using the commit and-quit command. {master:0}[edit vlans] lab@exD-1# top {master:0}[edit] lab@exD-1# load override /var/home/lab/ajex/mstp.conf load complete {master:0}[edit] lab@exD-1# commit and-quit configuration check succeeds commit complete Exiting configuration mode {master:0} lab@exD-1>

STOP

www.juniper.net





www.juniper.net

Lab 3 Authentication and Access Control (Detailed)

Overview In this lab, you will use the command-line interface (CLI) to configure and monitor various authentication and access control features supported on EX Series switches. The lab is available in two formats: a high-level format designed to make you think through each step and a detailed format that offers step-by-step instructions complete with sample output from most commands. By completing this lab you will perform the following tasks:

www.juniper.net

•

Modify the existing configuration.

•

Configure and monitor 802.1X.

•

Configure and monitor other authentication and access features.

Authentication and Access Control (Detailed) • Lab 3–1 10.b.10.4R3.4


Part 1: Modifying the Existing Configuration In this lab part, you modify the existing configuration. In preparation for Part 2, you must modify the Q-in-Q and filter-based VLAN configuration because those features cannot be enabled with 802.1X on the same interface at the same time. Step 1.1 Enter configuration mode and navigate to the [edit vlans] hierarchy. {master:0} lab@exD-1> configure Entering configuration mode {master:0}[edit] lab@exD-1# edit vlans {master:0}[edit vlans] lab@exD-1#

Step 1.2 Delete the dot1q-tunneling statement from the v11 and v12 VLANs. {master:0}[edit vlans] lab@exD-1# delete v11 dot1q-tunneling {master:0}[edit vlans] lab@exD-1# delete v12 dot1q-tunneling

Step 1.3 Delete the v15 VLAN and all configuration related to the filter-based VLAN assignment defined in Lab 1. {master:0}[edit vlans] lab@exD-1# delete v15 {master:0}[edit vlans] lab@exD-1# top delete firewall {master:0}[edit vlans] lab@exD-1# top delete interfaces ge-0/0/7.0 family ethernet-switching filter

Step 1.4 Navigate to the [edit ethernet-switching] hierarchy and set the Ethernet-type for the switch to 0x8100. Activate the changes and return to operational mode using the commit and-quit command.

Lab 3–2 • Authentication and Access Control (Detailed)

www.juniper.net


Note

Changing the Ethernet-type to 0x8100 allows trunk ports to support VLANs configured for Q-in-Q tunneling as well as standard 802.1Q VLANs at the same time. In production environments, ensure the Ethernet-type is set consistently on all devices within a given forwarding path. {master:0}[edit vlans] lab@exD-1# top edit ethernet-switching-options {master:0}[edit ethernet-switching-options] lab@exD-1# set dot1q-tunneling ether-type 0x8100 {master:0}[edit ethernet-switching-options] lab@exD-1# commit and-quit configuration check succeedscommit complete Exiting configuration mode {master:0} lab@exD-1>

Step 1.5 Return to the session opened for your assigned SRX device. If needed, open a new session and log in using the credentials provided by your instructor. Use the ping utility and attempt to verify access to and reachability through the Layer 2 network. Use the virtual routers (VRs) associated with your assigned SRX device as the source devices for these tests. Use the corresponding VR connected to the remote team’s EX Series switch as the destination. Refer to the network diagram for the instance names and the IP addresses assigned to the various VRs. Do not forget to reference the correct routing instance. lab@srxD-1> ping routing-instance vry1 172.23.11.10z rapid PING 172.23.11.102 (172.23.11.102): 56 data bytes ..... --- 172.23.11.102 ping statistics --5 packets transmitted, 0 packets received, 100% packet loss lab@srxD-1> ping routing-instance vry2 172.23.12.10z rapid PING 172.23.12.102 (172.23.12.102): 56 data bytes ..... --- 172.23.12.102 ping statistics --5 packets transmitted, 0 packets received, 100% packet loss

www.juniper.net

Authentication and Access Control (Detailed) • Lab 3–3


Question: Did the ping operations succeed? Can you explain why?

Answer: No, the ping operations should not succeed. Because of the recent configuration changes, the forwarding path now consists of devices configured with different Ethernet-types. You will remedy this problem in subsequent steps. Step 1.6 On your assigned SRX device, enter configuration mode, navigate to the [edit vlans] hierarchy, and delete the v15 VLAN. lab@srxD-1> configure Entering configuration mode [edit] lab@srxD-1# edit vlans [edit vlans] lab@srxD-1# delete v15 [edit vlans] lab@srxD-1#

Step 1.7 Delete the dot1q-tunneling statement from the v11 and v12 VLANs. [edit vlans] lab@srxD-1# delete v11 dot1q-tunneling [edit vlans] lab@srxD-1# delete v12 dot1q-tunneling

Step 1.8 Navigate to the [edit ethernet-switching] hierarchy and set the Ethernet-type for the switch to 0x8100. Activate the changes and return to operational mode using the commit and-quit command. [edit vlans] lab@srxD-1# top edit ethernet-switching-options [edit ethernet-switching-options] lab@srxD-1# set dot1q-tunneling ether-type 0x8100 [edit ethernet-switching-options] lab@srxD-1# commit and-quit commit complete Exiting configuration mode lab@srxD-1>


www.juniper.net


Step 1.9 Use the ping utility and attempt to verify access to and reachability through the Layer 2 network. Use the VRs associated with your assigned SRX device as the source devices for these tests. Use the corresponding VR connected to the remote team’s EX Series switch as the destination. Refer to the network diagram for the instance names and the IP addresses assigned to the various VRs. Do not forget to reference the correct routing instance. lab@srxD-1> ping routing-instance vry1 172.23.11.10z rapid PING 172.23.11.102 (172.23.11.102): 56 data bytes !!!!! --- 172.23.11.102 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.990/6.243/24.806/9.328 ms lab@srxD-1> ping routing-instance vry2 172.23.12.10z rapid PING 172.23.12.102 (172.23.12.102): 56 data bytes !!!!! --- 172.23.12.102 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.963/7.145/26.195/9.765 ms lab@srxD-1>

Question: Do the ping operations succeed?

Answer: Yes, the ping operations should now succeed. If the ping operations do not succeed, check your configuration and work with the remote team and your instructor as needed.

Part 2: Configuring 802.1X In this lab part, you configure the 802.1X and the static MAC bypass option. Once configured, you use relevant operational mode commands to monitor operations. Refer to the network diagram for this lab for topological and configuration details. Step 2.1 Return to the session opened for your assigned EX Series switch. Display the Ethernet switching table to determine what MAC addresses have been learned for the v11 and v12 VLANs. {master:0} lab@exD-1> show ethernet-switching table vlan v11 Ethernet-switching table: 2 unicast entries VLAN MAC address Type v11 * Flood v11 00:26:88:02:6b:87 Learn v11 00:26:88:02:74:87 Learn

Age 57 59

Interfaces All-members ge-0/0/9.0 ge-0/0/7.0

{master:0} www.juniper.net



lab@exD-1> show ethernet-switching table vlan v12 Ethernet-switching table: 2 unicast entries VLAN MAC address Type Age v12 * Flood v12 00:26:88:02:6b:88 Learn 31 v12 00:26:88:02:74:88 Learn 1:02

Interfaces All-members ge-0/0/9.0 ge-0/0/8.0

Question: Do the MAC addresses learned for the v11 and v12 VLANs match the MAC addresses shown on the network diagram for this lab?

Answer: Yes, the MAC addresses listed for the referenced VLANs should match those shown on the network diagram for this lab. If you do not see any learned MAC addresses for the v11 and v12 VLANs, you might need to run through the ping tests in Part 1 once again. Step 2.2 Enter configuration mode and navigate to the [edit access] hierarchy level. Define a RADIUS server using the IP address of the server located in the management network and a secret of Juniper. Refer to the Management Network Diagram or consult with your instructor as needed. {master:0} lab@exD-1> configure Entering configuration mode {master:0}[edit] lab@exD-1# edit access {master:0}[edit access] lab@exD-1# set radius-server 10.210.n.n secret Juniper {master:0}[edit access] lab@exD-1#

Step 2.3 Create an authentication profile named my-profile. Define an authentication order of RADIUS only and use the IP address of the RADIUS defined in the previous step as the authentication server. {master:0}[edit access] lab@exD-1# set profile my-profile authentication-order radius {master:0}[edit access] lab@exD-1# set profile my-profile radius authentication-server 10.210.n.n


www.juniper.net


Step 2.4 Navigate to the [edit protocols dot1x] hierarchy and configure your switch as an 802.1X authenticator. Use the authentication profile defined in the previous step and enable 802.1X authentication for the ge-0/0/7.0 and ge-0/0/8.0 interfaces. Activate the configuration changes using the commit command. {master:0}[edit access] lab@exD-1# top edit protocols dot1x {master:0}[edit protocols dot1x] lab@exD-1# set authenticator authentication-profile-name my-profile {master:0}[edit protocols dot1x] lab@exD-1# set authenticator interface ge-0/0/7.0 {master:0}[edit protocols dot1x] lab@exD-1# set authenticator interface ge-0/0/8.0 {master:0}[edit protocols dot1x] lab@exD-1# commit configuration check succeeds commit complete {master:0}[edit protocols dot1x] lab@exD-1#

Step 2.5 Issue the run show dot1x interface detail command and answer the questions that follow. {master:0}[edit protocols dot1x] lab@exD-1# run show dot1x interface detail ge-0/0/7.0 Role: Authenticator Administrative state: Auto Supplicant mode: Single Number of retries: 3 Quiet period: 60 seconds Transmit period: 30 seconds Mac Radius: Disabled Mac Radius Restrict: Disabled Reauthentication: Enabled Configured Reauthentication interval: 3600 seconds Supplicant timeout: 30 seconds Server timeout: 30 seconds Maximum EAPOL requests: 2 Guest VLAN member: ge-0/0/8.0 Role: Authenticator Administrative state: Auto Supplicant mode: Single Number of retries: 3 Quiet period: 60 seconds Transmit period: 30 seconds Mac Radius: Disabled www.juniper.net



Mac Radius Restrict: Disabled Reauthentication: Enabled Configured Reauthentication interval: 3600 seconds Supplicant timeout: 30 seconds Server timeout: 30 seconds Maximum EAPOL requests: 2 Guest VLAN member:

Question: What is the current supplicant mode enabled for the listed interfaces?

Answer: The current supplicant mode enabled for the ge-0/0/7.0 and ge-0/0/8.0 interfaces is the Single supplicant mode, which is the default mode. Question: If an 802.1X client authenticated through the ge-0/0/7.0 or ge-0/0/8.0 interfaces, would that client be forced to reauthenticate after a period of time? If so, after what period of time?

Answer: Based on the current configuration, an authenticated client would need to reauthenticate after 3600 seconds (1 hour). Step 2.6 Set the supplicant mode for the ge-0/0/7.0 and ge-0/0/8.0 interfaces to the single-secure supplicant mode. Disable reauthentication on the ge-0/0/7.0 interface and double the reauthentication interval on the ge-0/0/8.0 interface to 7200 seconds (2 hours). {master:0}[edit protocols dot1x] lab@exD-1# set authenticator interface ge-0/0/7.0 supplicant single-secure {master:0}[edit protocols dot1x] lab@exD-1# set authenticator interface ge-0/0/8.0 supplicant single-secure {master:0}[edit protocols dot1x] lab@exD-1# set authenticator interface ge-0/0/7.0 no-reauthentication {master:0}[edit protocols dot1x] lab@exD-1# set authenticator interface ge-0/0/8.0 reauthentication 7200 {master:0}[edit protocols dot1x] lab@exD-1# show authenticator { authentication-profile-name my-profile; interface { ge-0/0/7.0 { supplicant single-secure; Lab 3–8 • Authentication and Access Control (Detailed)

www.juniper.net


no-reauthentication; } ge-0/0/8.0 { supplicant single-secure; reauthentication 7200; } } }

Step 2.7 Activate the configuration changes using the commit command. Next, issue the run show dot1x interface detail command and answer the questions that follow. {master:0}[edit protocols dot1x] lab@exD-1# commit configuration check succeedscommit complete {master:0}[edit protocols dot1x] lab@exD-1# run show dot1x interface detail ge-0/0/7.0 Role: Authenticator Administrative state: Auto Supplicant mode: Single-Secure Number of retries: 3 Quiet period: 60 seconds Transmit period: 30 seconds Mac Radius: Disabled Mac Radius Restrict: Disabled Reauthentication: Disabled Configured Reauthentication interval: 3600 seconds Supplicant timeout: 30 seconds Server timeout: 30 seconds Maximum EAPOL requests: 2 Guest VLAN member: Number of connected supplicants: 0 ge-0/0/8.0 Role: Authenticator Administrative state: Auto Supplicant mode: Single-Secure Number of retries: 3 Quiet period: 60 seconds Transmit period: 30 seconds Mac Radius: Disabled Mac Radius Restrict: Disabled Reauthentication: Enabled Configured Reauthentication interval: 7200 seconds Supplicant timeout: 30 seconds Server timeout: 30 seconds Maximum EAPOL requests: 2 Guest VLAN member: Number of connected supplicants: 0

www.juniper.net



Question: Have the recent changes taken effect?

Answer: Yes, as shown in the sample output, the recent changes are now in effect. You can see that both the ge-0/0/7.0 and ge-0/0/8.0 interfaces are now enabled for the Single-Secure supplicant mode, the ge-0/0/7.0 interface now has reauthentication disabled, and the ge-0/0/8.0 interface still has reauthentication enabled, but the interval is now 7200 seconds (2 hours) rather than the previous interval of 3600 seconds (1 hour). Step 2.8 Return to the session opened for your assigned SRX device. Use the ping utility and attempt to verify access to and reachability through the Layer 2 network. Use the VRs associated with your assigned SRX device as the source devices for these tests. Use the corresponding VR connected to the remote team’s EX Series switch as the destination. Refer to the network diagram for the instance names and the IP addresses assigned to the various VRs. Do not forget to reference the correct routing instance. lab@srxD-1> ping routing-instance vry1 172.23.11.10z rapid PING 172.23.11.102 (172.23.11.102): 56 data bytes ..... --- 172.23.11.102 ping statistics --5 packets transmitted, 0 packets received, 100% packet loss lab@srxD-1> ping routing-instance vry2 172.23.12.10z rapid PING 172.23.12.102 (172.23.12.102): 56 data bytes ..... --- 172.23.12.102 ping statistics --5 packets transmitted, 0 packets received, 100% packet loss

Question: Can the VRs access the Layer 2 network through your assigned EX Series switch?

Answer: No, the VRs should not be able to access the Layer 2 network because of the lack of support for 802.1X. Step 2.9 Return to the session opened for your assigned EX Series switch. Configure the static MAC bypass option to always permit the MAC addresses shown on the network diagram. Associate the illustrated MAC addresses with their corresponding access ports. Refer to the network diagram for this lab as needed. Activate the changes using the commit command. Lab 3–10 • Authentication and Access Control (Detailed)

www.juniper.net


{master:0}[edit protocols dot1x] lab@exD-1# set authenticator static 00:26:88:02:nn:87 interface ge-0/0/7.0 {master:0}[edit protocols dot1x] lab@exD-1# set authenticator static 00:26:88:02:nn:88 interface ge-0/0/8.0 {master:0}[edit protocols dot1x] lab@exD-1# commit [edit protocols dot1x authenticator static 00:26:88:02:74:87/48 interface] 'interface ge-0/0/7.0' Static MAC cannot be configured on interface in single or single-secure mode [edit protocols dot1x authenticator static 00:26:88:02:74:88/48 interface] 'interface ge-0/0/8.0' Static MAC cannot be configured on interface in single or single-secure mode error: commit failed: (statements constraint check failed)

Question: Did the commit operation succeed? If not, why not?

Answer: No, the commit operation should not succeed because of an incompatible setting in the configuration file. As indicated in the commit error message, you must use the multiple supplicant mode on interfaces that are bound to a static MAC bypass statement. Step 2.10 Change the supplicant mode on the ge-0/0/7.0 and ge-0/0/8.0 interfaces to the multiple supplicant mode. Issue the commit command to activate the changes. {master:0}[edit protocols dot1x] lab@exD-1# set authenticator interface ge-0/0/7.0 supplicant multiple {master:0}[edit protocols dot1x] lab@exD-1# set authenticator interface ge-0/0/8.0 supplicant multiple {master:0}[edit protocols dot1x] lab@exD-1# commit configuration check succeedscommit complete Note

Before proceeding, ensure that the remote team in your pod finishes the previous step.

www.juniper.net



Step 2.11 Return to the session opened for your assigned SRX device. Use the ping utility and attempt to verify access to and reachability through the Layer 2 network. Use the VRs associated with your assigned SRX device as the source devices for these tests. Use the corresponding VR connected to the remote team’s EX Series switch as the destination. Refer to the network diagram for the instance names and the IP addresses assigned to the various VRs. Do not forget to reference the correct routing instance. lab@srxD-1> ping routing-instance vry1 172.23.11.10z rapid PING 172.23.11.102 (172.23.11.102): 56 data bytes !!!!! --- 172.23.11.102 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.200/32.826/159.058/63.116 ms lab@srxD-1> ping routing-instance vry2 172.23.12.10z rapid PING 172.23.12.102 (172.23.12.102): 56 data bytes !!!!! --- 172.23.12.102 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.176/31.789/153.650/60.930 ms

Question: Can the VRs access the Layer 2 network through your assigned EX Series switch?

Answer: Yes, now that the static MAC bypass configuration has been added, the VRs should be able to access the Layer 2 network. If your tests do not succeed, check your configuration and work with the remote team and instructor as needed.

Part 3: Configuring and Monitoring Other Access and Authentication Features In this lab part, you configure the MAC RADIUS, guest VLAN, and server fail fallback features. Once configured, you use various operational mode commands to verify proper operations. Step 3.1 Return to the session opened for your assigned EX Series switch. Issue the run show dot1x static-mac-address command to view the MAC addresses currently permitted through static MAC bypass. Delete all static MAC bypass entries and activate the changes using the commit command. {master:0}[edit protocols dot1x] lab@exD-1# run show dot1x static-mac-address MAC address/prefix VLAN-Assignment 00:26:88:02:74:87/48 00:26:88:02:74:88/48 Lab 3–12 • Authentication and Access Control (Detailed)

Interface ge-0/0/7.0 ge-0/0/8.0 www.juniper.net


{master:0}[edit protocols dot1x] lab@exD-1# delete authenticator static {master:0}[edit protocols dot1x] lab@exD-1# commit configuration check succeedscommit complete {master:0}[edit protocols dot1x] lab@exD-1# run show dot1x static-mac-address

Question: Based on the current configuration, will traffic from the VRs, representing hosts without the 802.1X client, be permitted through the switch?

Answer: No, as we saw earlier in Part 1, the switch will not authenticate the VRs and consequently the traffic from the VRs will not be permitted through the switch. Step 3.2 Configure MAC RADIUS on the ge-0/0/7.0 and ge-0/0/8.0 interfaces. Use the restrict option for both interfaces to ensure that no Extensible Authentication Protocol over LAN (EAPoL) traffic is sent from your switch. Issue the commit command to activate the changes. {master:0}[edit protocols dot1x] lab@exD-1# set authenticator interface ge-0/0/7.0 mac-radius restrict {master:0}[edit protocols dot1x] lab@exD-1# set authenticator interface ge-0/0/8.0 mac-radius restrict {master:0}[edit protocols dot1x] lab@exD-1# commit configuration check succeedscommit complete

Step 3.3 Issue the run show dot1x interface ge-0/0/7.0 detail command to verify the settings associated with MAC RADIUS on the ge-0/0/7.0 interface. {master:0}[edit protocols dot1x] lab@exD-1# run show dot1x interface ge-0/0/7.0 detail ge-0/0/7.0 Role: Authenticator Administrative state: Auto Supplicant mode: Multiple Number of retries: 3 Quiet period: 60 seconds Transmit period: 30 seconds Mac Radius: Enabled Mac Radius Restrict: Enabled Reauthentication: Disabled Configured Reauthentication interval: 3600 seconds www.juniper.net



Supplicant timeout: 30 seconds Server timeout: 30 seconds Maximum EAPOL requests: 2 Guest VLAN member: Number of connected supplicants: 0

Question: Is MAC RADIUS currently enabled? Will EAPoL traffic be sent out the ge-0/0/7.0 interface?

Answer: Yes, according to the sample output, MAC RADIUS is currently enabled on the ge-0/0/7.0 interface. The output also clearly indicates that the MAC RADIUS restrict option is enabled, which means EAPoL traffic will not be sent out the ge-0/0/ 7.0 interface toward the attached supplicants. Step 3.4 Issue the run show dot1x interface to determine the current state of the ge-0/0/7.0 and ge-0/0/8.0 interfaces. {master:0}[edit protocols dot1x] lab@exD-1# run show dot1x interface 802.1X Information: Interface Role State ge-0/0/7.0 Authenticator Connecting ge-0/0/8.0 Authenticator Connecting

MAC address

User

Question: What is the state of these interfaces? What does this state indicate?

Answer: The state for both interfaces will likely show Connecting, but it might vary. The interface state depends on how recent traffic was received on the interface. The Connecting state represents an idle or waiting state. The Authenticating state indicates that the switch is authenticating a client. The Held state indicates that a supplicant is denied access, permitted access through a specified VLAN, or maintains the authenticated state granted to it before the RADIUS server timeout occurred. The Authenticated state indicates the supplicant is authenticated through a RADIUS server or has been permitted access through server fail fallback.


www.juniper.net


Step 3.5 Return to the session opened for your assigned SRX device. Use the ping utility to test access into the Layer 2 network. Use the VRs associated with your assigned SRX device as the source devices for these tests. Use the corresponding VR connected to the remote team’s EX Series switch as the destination. Refer to the network diagram for the instance names and the IP addresses assigned to the various VRs. Do not forget to reference the correct routing instance. lab@srxD-1> ping routing-instance vry1 172.23.11.10z rapid PING 172.23.11.102 (172.23.11.102): 56 data bytes ..... --- 172.23.11.102 ping statistics --5 packets transmitted, 0 packets received, 100% packet loss lab@srxD-1> ping routing-instance vry2 172.23.12.10z rapid PING 172.23.12.102 (172.23.12.102): 56 data bytes ..... --- 172.23.12.102 ping statistics --5 packets transmitted, 0 packets received, 100% packet loss

Question: Do the ping tests succeed? If not, what might be the cause of this failure?

Answer: No, the VRs should not currently be able to access the Layer 2 network and the ping tests should fail. A number of reasons might explain this lack of access to the network. For example, the MAC address of the end user device might not defined or might be incorrectly defined on the RADIUS server, or perhaps the RADIUS server is not available at the time the authentication request was made. In our case, the RADIUS server is not configured to authenticate the VRs based on their MAC addresses so it responds with access-reject message. Step 3.6 Return to the session opened for your assigned EX Series switch. Configure the server fail fallback option for the ge-0/0/7.0 and ge-0/0/8.0 interfaces. Use the permit action for this feature on both access ports. {master:0}[edit protocols dot1x] lab@exD-1# set authenticator interface ge-0/0/7.0 server-fail permit {master:0}[edit protocols dot1x] lab@exD-1# set authenticator interface ge-0/0/8.0 server-fail permit www.juniper.net



Step 3.7 Change the IP address of the RADIUS server to 1.1.1.1 to ensure that your switch does not receive an access-reject message when an authentication request is made to the RADIUS server. Use the replace pattern command to simplify this task. Use the commit and-quit command to activate the configuration changes and return to operational mode. {master:0}[edit protocols dot1x] lab@exD-1# top show access radius-server { 10.210.35.130 secret "$9$UciqPFnCBIc5QIcylLXUjH"; ## SECRET-DATA } profile my-profile { authentication-order radius; radius { authentication-server 10.210.35.130; } } {master:0}[edit protocols dot1x] lab@exD-1# top replace pattern 10.210.n.n with 1.1.1.1 {master:0}[edit protocols dot1x] lab@exD-1# top show access radius-server { 1.1.1.1 secret "$9$UciqPFnCBIc5QIcylLXUjH"; ## SECRET-DATA } profile my-profile { authentication-order radius; radius { authentication-server 1.1.1.1; } } {master:0}[edit protocols dot1x] lab@exD-1# commit and-quit configuration check succeedscommit complete Exiting configuration mode {master:0} lab@exD-1> Note

Before proceeding, ensure that the remote team in your pod finishes the previous step. Step 3.8 Return to the session opened for your assigned SRX device. Use the ping utility to send traffic from the VRs attached to your assigned EX Series switch. Use the corresponding VR connected to the remote team’s EX Series switch as the destination. Note that these ping tests should initially fail until the MAC RADIUS authentication attempts timeout and the server fail fallback feature authenticates the required ports. Work with the remote team as needed. Lab 3–16 • Authentication and Access Control (Detailed)

www.juniper.net


# NOTE: You may see several failed attempts before you see the following: lab@srxD-1> ping routing-instance vry1 172.23.11.10z rapid PING 172.23.11.102 (172.23.11.102): 56 data bytes !!!!! --- 172.23.11.102 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.200/32.826/159.058/63.116 ms lab@srxD-1> ping routing-instance vry2 172.23.12.10z rapid PING 172.23.12.102 (172.23.12.102): 56 data bytes !!!!! --- 172.23.12.102 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.176/31.789/153.650/60.930 ms

Question: Do the ping tests eventually succeed?

Answer: Yes, after the MAC RADIUS authentication attempts fail, you should see the ping tests succeed. Note that the access ports on the switches for both teams must be authenticated for the ping tests to succeed. If your ping tests do not succeed, check your configuration and, if needed, work with the remote team and your instructor. Note that for the traffic to pass successfully through the network, you should see the access ports on both sides in the Authenticated state as shown in the following output: {master:0} lab@exD-1> show dot1x interface 802.1X Information: Interface Role State ge-0/0/7.0 Authenticator Authenticated ge-0/0/8.0 Authenticator Authenticated

STOP

www.juniper.net

MAC address 00:26:88:02:74:87 00:26:88:02:74:88

User 002688027487 002688027488





www.juniper.net

Lab 4 Deploying IP Telephony Features (Detailed)

Overview In this lab, you implement various features that are commonly used in IP telephony deployments. Specifically you will use the command-line interface (CLI) to configure and monitor Power over Ethernet (PoE), the Link Layer Discovery Protocol (LLDP) and LLDP Media Endpoint Discovery (LLDP-MED), and the voice VLAN feature. The lab is available in two formats: a high-level format designed to make you think through each step and a detailed format that offers step-by-step instructions complete with sample output from most commands. By completing this lab you will perform the following tasks:

www.juniper.net

•

Modify the existing configurations.

•

Configure and monitor PoE.

•

Configure and monitor LLDP and LLDP-MED.

•

Configure and monitor a voice VLAN.

Deploying IP Telephony Features (Detailed) • Lab 4–1 10.b.10.4R3.4


Part 1: Modifying the Existing Configurations In this lab part, you modify the existing configurations on your assigned EX and SRX devices. You will enter configuration mode and load and activate a predefined configuration saved on your assigned devices. Step 1.1 Return to the session opened for your assigned SRX device. If needed, open a new session and log in using the credentials provided by your instructor. Enter configuration mode and override the existing configuration file with the lab4-start.conf configuration file stored in the /var/home/lab/ajex/ directory. Issue the commit and-quit command to activate the new configuration file and return to operational mode. lab@srxD-1> configure Entering configuration mode [edit] lab@srxD-1# load override /var/home/lab/ajex/lab4-start.conf load complete [edit] lab@srxD-1# commit and-quit commit complete Exiting configuration mode lab@srxD-1>

Step 1.2 Return to the session opened for your assigned EX Series switch. If needed, open a new session and log in using the credentials provided by your instructor. Enter configuration mode and override the existing configuration file with the lab4-start.conf configuration file stored in the /var/home/lab/ajex/ directory. Issue the commit command to activate the new configuration file. {master:0} lab@exD-1> configure Entering configuration mode {master:0}[edit] lab@exD-1# load override /var/home/lab/ajex/lab4-start.conf load complete {master:0}[edit] lab@exD-1# commit configuration check succeeds commit complete {master:0}[edit] lab@exD-1#

Lab 4–2 • Deploying IP Telephony Features (Detailed)

www.juniper.net


Part 2: Configuring and Monitoring PoE In this lab part, you will configure and monitor PoE on EX Series switches. The purpose of this lab part is to illustrate proper configuration and monitoring steps when working with PoE. Step 2.1 On your assigned EX Series switch, issue the run show chassis hardware command. {master:0}[edit] lab@exD-1# run show chassis hardware Hardware inventory: Item Version Part number Chassis Routing Engine 0 REV 06 750-033065 FPC 0 REV 06 750-033065 CPU BUILTIN PIC 0 BUILTIN Power Supply 0 REV 04 740-020957 Fan Tray

Serial number BM0210443341 BM0210443341 BM0210443341 BUILTIN BUILTIN AT0510394317

Description EX4200-24T EX4200-24T, 8 POE EX4200-24T, 8 POE FPC CPU 24x 10/100/1000 Base-T PS 320W AC Fan Tray

Question: How many PoE ports does your switch support?

Answer: Your answer might vary. In this example, the switch supports eight PoE ports. This information is displayed under the Description column for the FPC component. Question: What is the capacity of your switch’s power supply?

Answer: Again, your answer might vary. In this example, the capacity of the power supply unit (PSU) is 320 W, which is capable of supporting eight PoE ports. The other PSU options available for the EX 4200 are 600 W and 930 W. The 600 W and 930 W PSUs support 24 and 48 PoE ports, respectively. Step 2.2 Issue the run show poe interface command to determine the current state of all PoE interfaces.

www.juniper.net

Deploying IP Telephony Features (Detailed) • Lab 4–3


{master:0}[edit] lab@exD-1# run show poe interface Interface Admin status Oper status ge-0/0/0 Disabled Disabled applicable ge-0/0/1 Disabled Disabled applicable ge-0/0/2 Disabled Disabled applicable ge-0/0/3 Disabled Disabled applicable ge-0/0/4 Disabled Disabled applicable ge-0/0/5 Disabled Disabled applicable ge-0/0/6 Disabled Disabled applicable ge-0/0/7 Disabled Disabled applicable

Max power Priority Power consumption Class 0.0W Low 0.0W not 0.0W

Low

0.0W

not

0.0W

Low

0.0W

not

0.0W

Low

0.0W

not

0.0W

Low

0.0W

not

0.0W

Low

0.0W

not

0.0W

Low

0.0W

not

0.0W

Low

0.0W

not

Question: Based on the output, what interfaces support PoE on your assigned switch? What is the current administrative and operational state of these interfaces?

Answer: In this example, the first eight switch ports (ge-0/0/0 through ge-0/0/7) support PoE. The administrative and operational states for all PoE interfaces should be Disabled. Step 2.3 Navigate to the [edit poe] hierarchy. Enable PoE on all supported interfaces. Activate the configuration change using the commit command. {master:0}[edit] lab@exD-1# edit poe {master:0}[edit poe] lab@exD-1# set interface all {master:0}[edit poe] lab@exD-1# commit configuration check succeedscommit complete {master:0}[edit poe] lab@exD-1#

Step 2.4 Issue the run show poe controller command to determine how much power is available and how much power is being used.


www.juniper.net

Advanced Junos Enterprise Switching {master:0}[edit poe] lab@exD-1# run show poe controller Controller Maximum Power index power consumption 0 130 W 0W

Guard band 0W

Management Class

Question: How much power is currently available for the PoE controller to budget? How much power is currently consumed?

Answer: The pool of available power depends on the installed PSU. In this example, the switch has a maximum power pool of 130 W. Because we do not actually have any powered devices connected to and drawing power from the switch, the total power consumption value for your switch should show 0W. Step 2.5 Issue the run show poe interface command to determine the current state of all PoE interfaces. {master:0}[edit poe] lab@exD-1# run show poe interface Interface Admin status Oper status ge-0/0/0 Enabled OFF ge-0/0/1 Enabled OFF ge-0/0/2 Enabled OFF ge-0/0/3 Enabled OFF ge-0/0/4 Enabled OFF ge-0/0/5 Enabled OFF ge-0/0/6 Enabled OFF ge-0/0/7 Enabled OFF

Max power 15.4W 15.4W 15.4W 15.4W 15.4W 15.4W 15.4W 15.4W

Priority Low Low Low Low Low Low Low Low

Power consumption Class 0.0W not applicable 0.0W not applicable 0.0W not applicable 0.0W not applicable 0.0W not applicable 0.0W not applicable 0.0W not applicable 0.0W not applicable

Question: What is the current administrative and operational state of the PoE interfaces? What do these states indicate?

Answer: All PoE interfaces should show an administrative state of Enabled and an operational state of OFF. These states indicate that the switch is ready and able to provide power to powered devices (PDs) attached to these PoE ports and that currently no attached devices require power.

www.juniper.net



Question: What is the maximum power available to the PoE interfaces?

Answer: By default, all PoE interfaces are allocated the maximum power value. EX 4200 switches support IEEE 802.3af, which provides a maximum power value of 15.4 W. Question: What priority level is assigned to the PoE interfaces?

Answer: All PoE interfaces are assigned a priority level of Low. Note that this level is the default designation and that this assigned level can be changed through configuration to help ensure critical devices receive priority, should the power budget drop for some reason. You will manually adjust the priority level in a subsequent task in this lab. Step 2.6 Configure the ge-0/0/6 and ge-0/0/7 interfaces with a PoE priority level of high. Issue the commit command to activate the changes. {master:0}[edit poe] lab@exD-1# set interface ge-0/0/6 priority high {master:0}[edit poe] lab@exD-1# set interface ge-0/0/7 priority high {master:0}[edit poe] lab@exD-1# commit configuration check succeedscommit complete

Step 2.7 Issue the run show poe interface command again to ensure the priority level has been adjusted properly for the ge-0/0/6 and ge-0/0/7 PoE interfaces.


www.juniper.net

Advanced Junos Enterprise Switching {master:0}[edit poe] lab@exD-1# run show poe interface Interface Admin status Oper status ge-0/0/0 Enabled OFF ge-0/0/1 Enabled OFF ge-0/0/2 Enabled OFF ge-0/0/3 Enabled OFF ge-0/0/4 Enabled OFF ge-0/0/5 Enabled OFF ge-0/0/6 Enabled OFF ge-0/0/7 Enabled OFF

Max power 15.4W 15.4W 15.4W 15.4W 15.4W 15.4W 15.4W 15.4W

Priority Low Low Low Low Low Low High High

Power consumption Class 0.0W not applicable 0.0W not applicable 0.0W not applicable 0.0W not applicable 0.0W not applicable 0.0W not applicable 0.0W not applicable 0.0W not applicable

Question: What is the current PoE priority level for the ge-0/0/6 and ge-0/0/7 interfaces?

Answer: As shown in the sample output, the ge-0/ 0/6 and ge-0/0/7 interfaces should now show a PoE priority level of High.

Part 3: Configuring and Monitoring LLDP and LLDP-MED In this lab part, you will configure and monitor LLDP and LLDP-MED. Step 3.1 Navigate to the [edit protocols] hierarchy and configure LLDP and LLDP-MED for all interfaces. Activate the configuration changes using the commit command. {master:0}[edit poe] lab@exD-1# top edit protocols {master:0}[edit protocols] lab@exD-1# set lldp interface all {master:0}[edit protocols] lab@exD-1# set lldp-med interface all {master:0}[edit protocols] lab@exD-1# commit configuration check succeeds commit complete {master:0}[edit protocols] lab@exD-1# Note

LLDP and LLDP-MED have been preconfigured on the SRX devices.

www.juniper.net



Step 3.2 Issue the run show lldp local-information command to view information about your assigned EX Series switch that will be communicated to attached neighbors. {master:0}[edit protocols] lab@exD-1# run show lldp local-information LLDP Local Information details Chassis ID : 50:c5:8d:ba:62:00 System name : exD-1 System descr : Juniper Networks, Inc. ex4200-24t , version 10.4R3.4 Build date: 2011-03-19 22:17:08 UT System Capabilities Supported : Bridge Router Enabled : Bridge Router Management Information Port Name : me0.0 Port Address : 10.210.35.147 Address Type : IPv4 Port ID : 34 Port ID Subtype : local(7) Port Subtype : ifIndex(2) Interface name Parent Interface SNMP Index Interface description Status Tunneling me0.0 34 me0.0 Up Disabled ge-0/0/6.0 517 ge-0/0/6.0 Up Disabled ge-0/0/12.0 529 ge-0/0/12.0 Up Disabled ge-0/0/10.0 525 ge-0/0/10.0 Up Disabled ge-0/0/9.0 523 ge-0/0/9.0 Up Disabled ge-0/0/7.0 519 ge-0/0/7.0 Up Disabled

Question: Based on the output, what is the chassis ID assigned to your switch?

Answer: The answer will vary. In the illustrated example, the chassis ID of the switch is 50:c5:8d:ba:62:00.


www.juniper.net


Question: Based on the output, what are the system capabilities of your switch?

Answer: As illustrated in the sample output, the system capabilities of EX Series switches are Bridge and Router. Question: Based on the output, what are the descriptions for the ge-0/0/6.0 and ge-0/0/7.0 interfaces?

Answer: As illustrated in the sample output, the interface descriptions are simply the logical interface name. Note that this description is the default interface description when a user-defined description is not configured. Step 3.3 Configure descriptions of “v10 access port” and “v11 access port” for the ge-0/0/6.0 and ge-0/0/7.0 interfaces respectively. Issue the commit command to activate the change. {master:0}[edit protocols] lab@exD-1# top set interfaces ge-0/0/6.0 description "v10 access port" {master:0}[edit protocols] lab@exD-1# top set interfaces ge-0/0/7.0 description "v11 access port" {master:0}[edit protocols] lab@exD-1# commit configuration check succeedscommit complete

Step 3.4 Issue the run show lldp local-information command to verify the interface descriptions for LLDP have been updated. {master:0}[edit protocols] lab@exD-1# run show lldp local-information ... Interface name Parent Interface SNMP Index Interface description Status Tunneling ge-0/0/6.0 517 v10 access port Up Disabled ge-0/0/7.0 519 v11 access port Up Disabled ... www.juniper.net



Question: Have the interface descriptions been updated?

Answer: As illustrated in the output, the interface descriptions for the ge-0/0/6.0 and ge-0/0/7.0 interfaces should now be updated to the recently defined descriptions. Step 3.5 Disable LLDP and LLDP-MED on the me0.0 interface. Activate the change using the commit command. Note you typically would not disable LLDP or LLDP-MED on internal interfaces, including the me0.0 interface. You disable the me0.0 interface in this task for verification purposes only. {master:0}[edit protocols] lab@exD-1# set lldp interface me0.0 disable {master:0}[edit protocols] lab@exD-1# set lldp-med interface me0.0 disable {master:0}[edit protocols] lab@exD-1# commit configuration check succeedscommit complete

Step 3.6 Issue the run show lldp detail command to view detailed LLDP and LLDP-MED information. {master:0}[edit protocols] lab@exD-1# run show lldp detail LLDP Advertisement interval Transmit delay Hold timer Notification interval Config Trap Interval Connection Hold timer

: : : : : : :

LLDP MED MED fast start count

: Enabled : 3 Packets

Interface all me0.0

Enabled 30 seconds 2 seconds 4 seconds 0 Second(s) 0 seconds 300 seconds

Parent Interface -

LLDP Enabled Disabled


LLDP-MED Enabled Disabled

Neighbor count 5 0

www.juniper.net


Interface ge-0/0/6.0 ge-0/0/12.0 ge-0/0/12.0 ge-0/0/10.0 ge-0/0/10.0 ge-0/0/9.0 ge-0/0/9.0 ge-0/0/7.0

Parent Interface -

Vlan-id 10 11 10 11 10 11 10 11

Vlan-name v10 v11 v10 v11 v10 v11 v10 v11

LLDP basic TLVs supported: Chassis identifier, Port identifier, Port description, System name, System description, System capabilities, Management address. Supported LLDP 802 TLVs: MAC/PHY configuration/status, Power via MDI, Link aggregation, Maximum frame size, Port VLAN tag, Port VLAN name. Supported LLDP MED TLVs: LLDP MED capabilities, Network policy, Endpoint location, Extended power Via MDI.

Question: Based on the output, what is the current LLDP and LLDP-MED status of the me0.0 interface? What is the status of the other configured interfaces?

Answer: As illustrated in the output, me0.0 is Disabled and the remainder of the configured interfaces are Enabled. Question: Based on the output, what are the supported LLDP MED TLVs?

Answer: The supported LLDP MED TLVs include LLDP MED capabilities, Network policy, Endpoint location, and Extended power Via MDI. Question: Based on the output, how many neighbors has your switch detected?

Answer: The answer might vary. In the illustrated output, the switch as five LLDP neighbors. www.juniper.net



Before proceeding, ensure that the remote team in your pod finishes the previous step. Step 3.7 Issue the run show lldp neighbors command to view the attached LLDP neighbors. {master:0}[edit protocols] lab@exD-1# run show lldp neighbors Local Interface Parent Interface ge-0/0/6.0 ge-0/0/7.0 ge-0/0/9.0 ge-0/0/10.0 ge-0/0/12.0 -

Chassis Id Port info 00:26:88:e1:45:80 ge-0/0/6.0 00:26:88:e1:45:80 ge-0/0/7.0 00:26:88:e1:45:80 ge-0/0/9.0 00:26:88:e1:50:00 ge-0/0/10.0 50:c5:8d:ae:b7:80 ge-0/0/12.0

System Name srxD-1 srxD-1 srxD-1 srxD-2 exD-2

Question: Does your switch show a neighbor for all configured access and trunk ports?

Answer: Yes, as shown in the sample output, you should see a neighbor on all configured access and trunk ports. If not, check with the remote team in your pod and, if needed, the instructor. Step 3.8 Issue the run show lldp statistics command to view LLDP statistics. {master:0}[edit protocols] lab@exD-1# run show lldp statistics Interface Parent Interface Received Transmitted Untransmitted ge-0/0/6.0 199 0 0 ge-0/0/12.0 241 0 0 ge-0/0/10.0 195 0 0 ge-0/0/9.0 199 0 0 ge-0/0/7.0 199 0 0


Unknown TLVs

With Errors

Discarded TLVs

0

0

242

0

0

242

0

0

242

0

0

242

0

0

242

www.juniper.net


Question: Is your switch sending and receiving LLDP packets?

Answer: At this point, your switch should be sending and receiving LLDP packets on the configured interfaces.

STOP

Do NOT continue to the next lab part until both teams within your assigned pod have reached this point.

Part 4: Configuring and Monitoring the Voice VLAN Feature In this part, you will configure and monitor the voice VLAN feature. Step 4.1 Return to the session opened for your assigned SRX device. If needed, open a new session and log in using the credentials provided by your instructor. Enter configuration mode and navigate to the[edit interfaces] hierarchy. Activate vlan-tagging and unit 25 for the ge-0/0/6 and ge-0/0/7 interfaces. Also deactivate unit 0 for the same interfaces. Issue the commit and-quit command to activate the new configuration file and return to operational mode. lab@srxD-1> configure Entering configuration mode [edit] lab@srxD-1# edit interfaces [edit interfaces] lab@srxD-1# activate ge-0/0/6 vlan-tagging [edit interfaces] lab@srxD-1# activate ge-0/0/6 unit 25 [edit interfaces] lab@srxD-1# deactivate ge-0/0/6 unit 0 [edit interfaces] lab@srxD-1# activate ge-0/0/7 vlan-tagging [edit interfaces] lab@srxD-1# activate ge-0/0/7 unit 25 [edit interfaces] lab@srxD-1# deactivate ge-0/0/7 unit 0 [edit interfaces] www.juniper.net



lab@srxD-1# commit and-quit commit complete Exiting configuration mode lab@srxD-1>

Step 4.2 Return to the session opened for your assigned EX Series switch. If needed, open a new session and log in using the credentials provided by your instructor. Navigate to the [edit vlans] hierarchy and configure a new VLAN named voice with a VLAN ID of 25. Associate the trunk ports configured on your switch with this new VLAN. Activate the changes using the commit command. Refer to the network diagram for this lab as needed. {master:0}[edit protocols] lab@exD-1# top edit vlans {master:0}[edit vlans] lab@exD-1# set voice vlan-id 25 interface ge-0/0/9.0 {master:0}[edit vlans] lab@exD-1# set voice vlan-id 25 interface ge-0/0/10.0 {master:0}[edit vlans] lab@exD-1# set voice vlan-id 25 interface ge-0/0/12.0 {master:0}[edit vlans] lab@exD-1# show voice vlan-id 25; interface { ge-0/0/9.0; ge-0/0/10.0; ge-0/0/12.0; } {master:0}[edit vlans] lab@exD-1# commit configuration check succeedscommit complete {master:0}[edit vlans] lab@exD-1# Note

Voice VLAN has been preconfigured on the SRX devices. Step 4.3 Navigate to the [edit ethernet-switching-options] hierarchy. Configure the voice VLAN feature to support all access ports. {master:0}[edit vlans] lab@exD-1# top edit ethernet-switching-options {master:0}[edit ethernet-switching-options] lab@exD-1# set voip interface access-ports vlan voice Lab 4–14 • Deploying IP Telephony Features (Detailed)

www.juniper.net


{master:0}[edit ethernet-switching-options] lab@exD-1# show voip { interface access-ports { vlan voice; } } storm-control { interface all; } {master:0}[edit ethernet-switching-options] lab@exD-1#

Step 4.4 Before activating the voice VLAN feature, use the run monitor traffic interface ge-0/0/6 detail print-ascii no-resolve command to monitor LLDP-MED packets for the ge-0/0/6 interface. Once an outgoing LLDP frame has been sent (within 30 seconds or less), issue the Ctrl + c key sequence to stop the monitoring process. {master:0}[edit ethernet-switching-options] lab@exD-1# run monitor traffic interface ge-0/0/6 detail print-ascii no-resolve Address resolution is OFF. Listening on ge-0/0/6.0, capture size 1514 bytes ... 21:41:03.360212 Out LLDP, length 263 ... Vlan Name Subtype (3) Vlan Id: 10 Vlan Name: v10 Organization specific TLV (127), length 7: OUI ANSI/TIA (0x0012bb) LLDP-MED Capabilities Subtype (1) Media capabilities [LLDP-MED capabilities, network policy, location identification, extended power via MDI-PSE] (0x000f) Device type [network connectivity] (0x04) Organization specific TLV (127), length 7: OUI ANSI/TIA (0x0012bb) Extended power-via-MDI Subtype (4) Power type [PSE device], Power source [PSE - primary power source] Power priority [high] (0x02), Power 0.0 Watts End TLV (0), length 0 0x0000 0180 c200 000e 50c5 8dba 6206 88cc 0207 ......P...b..... 0x0010 0450 c58d ba62 0004 0407 3531 3706 0200 .P...b....517... 0x0020 780a 0565 7844 2d31 0c59 4a75 6e69 7065 x..exD-1.YJunipe 0x0030 7220 4e65 7477 6f72 6b73 2c20 496e 632e r.Networks,.Inc. 0x0040 2065 7834 3230 302d 3234 7420 2c20 7665 .ex4200-24t.,.ve 0x0050 7273 696f 6e20 3130 2e34 5231 2e39 2042 rsion.10.4R3.4.B 0x0060 7569 6c64 2064 6174 653a 2032 3031 302d uild.date:.20100x0070 3132 2d30 3420 3130 3a30 393a 3436 2055 12-04.10:09:46.U 0x0080 5443 200e 0400 1400 1410 1805 010a d223 TC.............# 0x0090 9302 0000 0022 0c01 0306 0102 011f 0101 .....".......... 0x00a0 0101 2208 0f76 3130 2061 6363 6573 7320 .."..v10.access. 0x00b0 706f 7274 fe09 0012 0f01 03a8 3600 00fe port........6... 0x00c0 0700 120f 0207 0100 fe09 0012 0f03 0100 ................ 0x00d0 0000 00fe 0600 120f 0405 eafe 0600 80c2 ................ 0x00e0 0100 0afe 1000 9069 0142 4d30 3231 3034 .......i.BM02104 0x00f0 3433 3334 31fe 0a00 80c2 0300 0a03 7631 43341.........v1 www.juniper.net


Advanced Junos Enterprise Switching 0x0100 30fe 0700 12bb 0100 0f04 fe07 0012 bb04 0x0110 1200 0000 00 ^C 2 packets received by filter 0 packets dropped by kernel

0............... .....

Question: Did your sample capture include at least one outgoing LLDP packet?

Answer: As long as you allowed the monitoring to run a minimum of 30 seconds, your capture should include at least one outgoing (Out LLDP) LLDP packet. Note

Using the detail and the print-ascii monitoring options allows many of the LLDP TLV details to be displayed in plain text. Question: What is the name of the VLAN currently being sent through LLDP-MED?

Answer: The current VLAN being sent out the ge-0/ 0/6 interface through LLDP-MED is named v10. This VLAN can be seen in the outgoing LLDP-MED packet on the right side and toward the bottom of the output. Step 4.5 Activate the changes and return to operational mode by issuing the commit and-quit command. {master:0}[edit ethernet-switching-options] lab@exD-1# commit and-quit configuration check succeedscommit complete Exiting configuration mode {master:0}

Step 4.6 Use the monitor traffic interface ge-0/0/6 detail print-ascii no-resolve command to monitor LLDP-MED packets for the ge-0/0/6 interface. Once an outgoing LLDP frame has been sent (within 30 seconds or less), issue the Ctrl + c key sequence to stop the monitoring process.


www.juniper.net


{master:0} lab@exD-1> monitor traffic interface ge-0/0/6 detail print-ascii no-resolve Address resolution is OFF. Listening on ge-0/0/6, capture size 1514 bytes ... 22:14:51.449181 Out LLDP, length 287 ... Vlan Name Subtype (3) Vlan Id: 10 Vlan Name: v10 Organization specific TLV (127), length 12: OUI Ethernet bridged (0x0080c2) Vlan Name Subtype (3) Vlan Id: 25 Vlan Name: voice Organization specific TLV (127), length 7: OUI ANSI/TIA (0x0012bb) LLDP-MED Capabilities Subtype (1) Media capabilities [LLDP-MED capabilities, network policy, location identification, extended power via MDI-PSE] (0x000f) Device type [network connectivity] (0x04) Organization specific TLV (127), length 7: OUI ANSI/TIA (0x0012bb) Extended power-via-MDI Subtype (4) Power type [PSE device], Power source [PSE - primary power source] Power priority [high] (0x02), Power 0.0 Watts Organization specific TLV (127), length 8: OUI ANSI/TIA (0x0012bb) Network policy Subtype (2) Application type [voice] (0x01), Flags [Tagged] Vlan id 25, L2 priority 0, DSCP value 0 End TLV (0), length 0 0x0000 0180 c200 000e 50c5 8dba 6206 88cc 0207 ......P...b..... 0x0010 0450 c58d ba62 0004 0407 3531 3706 0200 .P...b....517... 0x0020 780a 0565 7844 2d31 0c59 4a75 6e69 7065 x..exD-1.YJunipe 0x0030 7220 4e65 7477 6f72 6b73 2c20 496e 632e r.Networks,.Inc. 0x0040 2065 7834 3230 302d 3234 7420 2c20 7665 .ex4200-24t.,.ve 0x0050 7273 696f 6e20 3130 2e34 5231 2e39 2042 rsion.10.4R3.4.B 0x0060 7569 6c64 2064 6174 653a 2032 3031 302d uild.date:.20100x0070 3132 2d30 3420 3130 3a30 393a 3436 2055 12-04.10:09:46.U 0x0080 5443 200e 0400 1400 1410 1805 010a d223 TC.............# 0x0090 9302 0000 0022 0c01 0306 0102 011f 0101 .....".......... 0x00a0 0101 2208 0f76 3130 2061 6363 6573 7320 .."..v10.access. 0x00b0 706f 7274 fe09 0012 0f01 03a8 3600 00fe port........6... 0x00c0 0700 120f 0207 0100 fe09 0012 0f03 0100 ................ 0x00d0 0000 00fe 0600 120f 0405 eafe 0600 80c2 ................ 0x00e0 0100 0afe 1000 9069 0142 4d30 3231 3034 .......i.BM02104 0x00f0 3433 3334 31fe 0a00 80c2 0300 0a03 7631 43341.........v1 0x0100 30fe 0c00 80c2 0300 1905 766f 6963 65fe 0.........voice. 0x0110 0700 12bb 0100 0f04 fe07 0012 bb04 1200 ................ 0x0120 00fe 0800 12bb 0201 4032 0000 00 ........@2... ^C 2 packets received by filter 0 packets dropped by kernel

www.juniper.net



Question: What VLAN values are currently being sent and received through LLDP MED?

Answer: Outgoing LLDP MED packets should now show the v10 and voice VLAN values. Step 4.7 Issue the show vlans command to verify the current VLAN assignments. {master:0} lab@exD-1> show vlans Name Tag default

Interfaces None

v10

10

v11

11

voice

25

ge-0/0/6.0*, ge-0/0/9.0*, ge-0/0/10.0*, ge-0/0/12.0* ge-0/0/7.0*, ge-0/0/9.0*, ge-0/0/10.0*, ge-0/0/12.0* ge-0/0/6.0*, ge-0/0/7.0*, ge-0/0/9.0*, ge-0/0/10.0*, ge-0/0/12.0*

Question: To which VLANs are the ge-0/0/6.0 and ge-0/0/7.0 access ports assigned?

Answer: The ge-0/0/6.0 and ge-0/0/7.0 access ports should still be assigned to the v10 and v11 VLANs respectively, based on the port-based assignments. In addition to the port-based assignments, the ge-0/0/6.0 and ge-0/0/7.0 interfaces should also be assigned to the voice VLAN because of the configuration under the [edit ethernet-switching-options voip] hierarchy level. Step 4.8 Return to the session opened for your assigned SRX device. Use the ping utility and verify traffic with a VLAN tag of 25 can pass through the ge-0/0/6.0 and ge-0/0/7.0 access ports. Note that the interfaces on the SRX devices are configured for 802.1Q operations with a VLAN ID of 25. Refer to the network diagram for the instance names and the IP addresses assigned to the various VRs. Do not forget to reference the correct routing instance.


www.juniper.net


lab@srxD-1> show interfaces ge-0/0/6.25 Logical interface ge-0/0/6.25 (Index 74) (SNMP ifIndex 542) Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.25 ] Encapsulation: ENET2 Input packets : 6 Output packets: 5 Security: Zone: Null Protocol inet, MTU: 1500 Flags: Sendbcast-pkt-to-re, Is-Primary Addresses, Flags: Is-Default Is-Preferred Is-Primary Destination: 172.23.25/24, Local: 172.23.25.10, Broadcast: 172.23.25.255 lab@srxD-1> show interfaces ge-0/0/7.25 Logical interface ge-0/0/7.25 (Index 78) (SNMP ifIndex 543) Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.25 ] Encapsulation: ENET2 Input packets : 6 Output packets: 5 Security: Zone: Null Protocol inet, MTU: 1500 Flags: Sendbcast-pkt-to-re, Is-Primary Addresses, Flags: Is-Default Is-Preferred Is-Primary Destination: 172.23.25/24, Local: 172.23.25.11, Broadcast: 172.23.25.255 lab@srxD-1> ping routing-instance vry0 interface ge-0/0/6.25 172.23.25.z1 rapid PING 172.23.25.11 (172.23.25.11): 56 data bytes !!!!! --- 172.23.25.11 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.953/2.306/6.892/2.302 ms lab@srxD-1> ping routing-instance vry0 interface ge-0/0/6.25 172.23.25.z0 rapid PING 172.23.25.20 (172.23.25.20): 56 data bytes !!!!! --- 172.23.25.20 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.014/8.085/23.691/8.268 ms lab@srxD-1> ping routing-instance vry0 interface ge-0/0/6.25 172.23.25.z1 rapid PING 172.23.25.21 (172.23.25.21): 56 data bytes !!!!! --- 172.23.25.21 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.069/9.655/31.662/11.342 ms lab@srxD-1>

www.juniper.net



Question: Did the ping tests succeed?

Answer: Yes, the ping tests should succeed. This test validates that the access ports (ge-0/0/6.0 and ge-0/0/7.0) are properly configured to support the voice VLAN feature. Note that untagged traffic received through these same access ports would be associated with the VLANs assigned directly to the access ports through the port-based VLAN assignment method.

STOP



www.juniper.net

Lab 5 Class of Service (Detailed)

Overview In this lab, you will use the command-line interface (CLI) to configure and monitor class of service (CoS) on EX Series switches. The lab is available in two formats: a high-level format designed to make you think through each step and a detailed format that offers step-by-step instructions complete with sample output from most commands. By completing this lab you will perform the following tasks:

www.juniper.net

•

Explore the default CoS configuration.

•

Configure and monitor CoS components.

•

Implement CoS using the EZQoS template.

Class of Service (Detailed) • Lab 5–1 10.b.10.4R3.4


Part 1: Exploring the Default CoS Configuration In this lab part, you will explore the default CoS configuration on your EX Series switch and perform some basic verification tasks to understand how the default CoS configuration works. Step 1.1 On your assigned EX Series switch, issue the show class-of-service interface ge-0/0/6 command to determine the default assignments for the ge-0/0/6 interface. {master:0} lab@exD-1> show class-of-service interface ge-0/0/6 Physical interface: ge-0/0/6, Index: 136 Queues supported: 8, Queues in use: 4 Scheduler map: , Index: 2 Congestion-notification: Disabled Logical interface: ge-0/0/6.0, Index: 2147404772 Object Name Type Classifier ieee8021p-untrust untrust

Index 16

Question: How many queues are supported on the ge-0/0/6 interface? How many are currently in use?

Answer: The ge-0/0/6 interface supports eight queues. Currently, only four queues are in use. Question: What classifier is assigned to the ge-0/0/6 interface?

Answer: As shown in the output, the assigned classifier for the ge-0/0/6 interface is ieee8021p-untrust. Step 1.2 Issue the show class-of-service classifier name ieee8021p-untrust command to determine the code point to forwarding class for the default ieee8021p-untrust classifier.

Lab 5–2 • Class of Service (Detailed)

www.juniper.net


{master:0} lab@exD-1> show class-of-service classifier name ieee8021p-untrust Classifier: ieee8021p-untrust, Code point type: ieee-802.1, Index: 16 Code point Forwarding class Loss priority 000 best-effort low 001 best-effort low 010 best-effort low 011 best-effort low 100 best-effort low 101 best-effort low 110 best-effort low 111 best-effort low

Question: Based on this default classifier, to which forwarding class will traffic entering the ge-0/0/6 interface with the 802.1P CoS bits 111 be assigned?

Answer: Based on this default classifier, all traffic, regardless of the 802.1P CoS bits, will be assigned to the best-effort forwarding class (queue 0). Step 1.3 Issue the show class-of-service interface ge-0/0/12 command to determine the default classifier assigned to the ge-0/0/12 interface. {master:0} lab@exD-1> show class-of-service interface ge-0/0/12 Physical interface: ge-0/0/12, Index: 142 Queues supported: 8, Queues in use: 4 Scheduler map: , Index: 2 Congestion-notification: Disabled Logical interface: ge-0/0/12.0, Index: 2147404772 Object Name Type Classifier ieee8021p-default ieee8021p

Index 11

Question: What classifier is assigned to the ge-0/0/12 interface?

Answer: As shown in the output, the assigned classifier for the ge-0/0/12 interface is ieee8021p-default.

www.juniper.net

Class of Service (Detailed) • Lab 5–3


Question: Why are default classifiers assigned to the ge-0/0/12 and ge-0/0/6 interfaces different?

Answer: Remember that the default classifier assigned to a given interface is based on the role of that interface. In our example, the ge-0/0/6 interface is an access port and the ge-0/0/12 interface is a trunk port. By default, the ieee8021p-untrust classifier is assigned to access ports and the ieee8021p-default classifier is assigned to trunk ports. Step 1.4 Issue the show class-of-service classifier name ieee8021p-default command to determine the code point to forwarding class for the default ieee8021p-default classifier. {master:0} lab@exD-1> show class-of-service classifier name ieee8021p-default Classifier: ieee8021p-default, Code point type: ieee-802.1, Index: 11 Code point Forwarding class Loss priority 000 best-effort low 001 best-effort low 010 best-effort low 011 best-effort low 100 best-effort low 101 best-effort low 110 network-control low 111 network-control low

Question: Based on this default classifier, to which forwarding class will traffic entering the ge-0/0/12 interface with the 802.1P CoS bits 111 be assigned?

Answer: Based on this default classifier, traffic with the 802.1P CoS bits will be assigned to the network-control forwarding class (queue 7). Step 1.5 Issue the show class-of-service classifier type ? command to determine which types of classifiers are supported on EX Series switches.


www.juniper.net


{master:0} lab@exD-1> show class-of-service classifier type ? Possible completions: dscp Differentiated Services code point (DSCP) dscp-ipv6 Differentiated Services code point (DSCP) for IPv6 ieee-802.1 IEEE-802.1 code point inet-precedence IPv4 precedence code point

Question: What classifier types are supported on your EX Series switch?

Answer: As shown in the output, the supported classifier types include dscp, dscp-ipv6, ieee-802.1, and inet-precedence. Question: Which type of classifier is typically used when classifying voice over IP (VoIP) traffic?

Answer: Typically, in environments that implement VoIP, DiffServ code point (DSCP) classifiers are used. Step 1.6 Issue the show class-of-service classifier type dscp command. {master:0} lab@exD-1> show class-of-service classifier type dscp Classifier: dscp-default, Code point type: dscp, Index: 7 Code point Forwarding class Loss priority 000000 best-effort low ... 111111 network-control low

Question: Which two forwarding classes are used by the dscp-default classifier?

Answer: By default, only the best-effort and network-control forwarding classes are used by the dscp-default classifier.

www.juniper.net



Question: To which forwarding class would traffic with the DSCP code point value 000000 be assigned? What about traffic with the DSCP code point value 111111?

Answer: Assuming the default DSCP classifier is used, all traffic entering an EX Series switch with the DSCP code point value 000000 is assigned to the best-effort forwarding class and all traffic with the DSCP code point value 111111 is assigned to the network-control forwarding class. Question: Based on the output, what loss priority value is assigned, by default, to traffic with the various code point values?

Answer: By default, all traffic, regardless of the DSCP code point value, will be assigned the low loss priority value. Step 1.7 Issue the show class-of-service forwarding-class command to determine the default forwarding classes and their assigned queues. {master:0} lab@exD-1> show class-of-service forwarding-class Forwarding class ID best-effort 0 expedited-forwarding 1 assured-forwarding 2 network-control 3

Queue 0 5 1 7

Policing priority normal normal normal normal

Question: What are the default forwarding classes and their corresponding queues?

Answer: The default forwarding classes are best-effort, expedited-forwarding, assured-forwarding, and network-control. These forwarding classes are assigned to queues 0, 5, 1, and 7 respectively. Note that the default forwarding classes used and their respective queues vary and are platform-specific. Lab 5–6 • Class of Service (Detailed)

www.juniper.net


Step 1.8 Issue the show interfaces ge-0/0/6 extensive | find "Egress queues" command to view queue and scheduler details for the ge-0/0/6 interface. {master:0} lab@exD-1> show interfaces ge-0/0/6 extensive | find "Egress Egress queues: 8 supported, 4 in use Queue counters: Queued packets Transmitted packets 0 best-effort 0 333691 1 assured-forw 0 0 5 expedited-fo 0 0 7 network-cont 0 16288 Queue number: Mapped forwarding classes 0 best-effort 1 assured-forwarding 5 expedited-forwarding 7 network-control ... CoS information: Direction : Output CoS transmit queue Bandwidth Limit % bps % 0 best-effort 95 950000000 95 7 network-control 5 50000000 5 ...

queues" Dropped packets 0 0 0 0

Buffer Priority usec NA low NA low

none none

Question: Which queues currently show non-zero counters? Can you explain why the other queues do not show non-zero counters?

Answer: Only queue 0 (best-effort) and queue 7 (network-control) should show non-zero counters at this time. Remember that the default classifiers map all code point values to either the best-effort forwarding class (queue 0) or the network-control forwarding class (queue 7).

www.juniper.net



Question: Which queues are currently being serviced by the default scheduler map? What percentage of the available bandwidth and buffer is allocated to each queue being serviced?

Answer: Only queue 0 (best-effort) and queue 7 (network-control) are serviced by the default scheduler map. Queue 0 is allocated 95% of the available bandwidth and buffer while queue 7 is allocated the remaining 5% of the available bandwidth and buffer.

Part 2: Configuring and Monitoring CoS Components In this lab part, you configure and monitor various CoS components. Refer to the network diagram for this lab for topological and configuration details. Step 2.1 On your assigned EX Series switch, enter configuration mode and navigate to the [edit class-of-service] hierarchy. {master:0} lab@exD-1> configure Entering configuration mode {master:0}[edit] lab@exD-1# edit class-of-service {master:0}[edit class-of-service] lab@exD-1#

Step 2.2 Create four custom forwarding classes named my-be, my-ef, my-af, and my-nc. Associate these forwarding classes with queues 0, 5, 1, and 7 respectively. {master:0}[edit class-of-service] lab@exD-1# set forwarding-classes class my-be queue-num 0 {master:0}[edit class-of-service] lab@exD-1# set forwarding-classes class my-ef queue-num 5 {master:0}[edit class-of-service] lab@exD-1# set forwarding-classes class my-af queue-num 1 {master:0}[edit class-of-service] lab@exD-1# set forwarding-classes class my-nc queue-num 7 {master:0}[edit class-of-service] lab@exD-1# show forwarding-classes { Lab 5–8 • Class of Service (Detailed)

www.juniper.net


class class class class

my-be my-ef my-af my-nc

queue-num queue-num queue-num queue-num

0; 5; 1; 7;

}

Step 2.3 Use the commit command to activate the changes. Next, issue the run show interfaces ge-0/0/6 extensive | find "Queue counters" command to view the current forwarding class information for the ge-0/0/6 interface. {master:0}[edit class-of-service] lab@exD-1# commit configuration check succeedscommit complete {master:0}[edit class-of-service] lab@exD-1# run show interfaces ge-0/0/6 extensive | find "Queue counters" Queue counters: Queued packets Transmitted packets Dropped packets 0 my-be 0 5562 0 1 my-af 0 0 0 5 my-ef 0 0 0 7 my-nc 0 1344 0 Queue number: Mapped forwarding classes 0 my-be 1 my-af 5 my-ef 7 my-nc ... CoS information: Direction : Output CoS transmit queue Bandwidth Buffer Priority Limit % bps % usec 0 my-be 95 950000000 95 NA low none 7 my-nc 5 50000000 5 NA low none ...

Question: Are the custom forwarding classes now in effect and associated with the ge-0/0/6 interface?

Answer: Yes, at this time, the custom forwarding classes should be in effect and associated with the ge-0/0/6 interface. Note that the custom forwarding classes are applied to the entire system, which means all interfaces will use these newly defined forwarding classes.

www.juniper.net



Question: Which queues are currently being serviced by the default scheduler map?

Answer: The default scheduler map services queue 0 and queue 7 on the EX 4200 Series switch. Queue 0 (my-be) is allocated 95% of the available bandwidth and buffer while queue 7 (my-nc) is allocated the remaining 5% of the available bandwidth and buffer. Note that you can also view the scheduler details using the run show class-of-service scheduler-map command as shown in the following output: {master:0}[edit class-of-service] lab@exD-1# run show class-of-service scheduler-map Scheduler map: , Index: 2 Scheduler: , Forwarding class: my-be, Index: 21 Transmit rate: 95 percent, Rate Limit: none, Buffer size: 95 percent, Buffer Limit: none, Priority: low Excess Priority: low Drop profiles: Loss priority Protocol Index Name High non-TCP 1 High TCP 1 Scheduler: , Forwarding class: my-nc, Index: 23 Transmit rate: 5 percent, Rate Limit: none, Buffer size: 5 percent, Buffer Limit: none, Priority: low Excess Priority: low Drop profiles: Loss priority Protocol Index Name High non-TCP 1 High TCP 1 ...

Step 2.4 Create a custom DSCP classifier named my-dscp-classifier. Associate code-point alias ef (101110) with the my-ef forwarding class, code-point alias af41 (100010) with the my-af forwarding class, and code-point aliases cs3 (011000) and af31 (011010) with the my-nc forwarding class. Ensure that this custom classifier inherits all default code point aliases not specified in these custom definitions. Ensure that these custom definitions use the low loss priority level. {master:0}[edit class-of-service] lab@exD-1# edit classifiers dscp my-dscp-classifier {master:0}[edit class-of-service classifiers dscp my-dscp-classifier] lab@exD-1# set forwarding-class my-ef loss-priority low code-points ef


www.juniper.net


{master:0}[edit class-of-service classifiers dscp my-dscp-classifier] lab@exD-1# set forwarding-class my-af loss-priority low code-points af41 {master:0}[edit class-of-service classifiers dscp my-dscp-classifier] lab@exD-1# set forwarding-class my-nc loss-priority low code-points [cs3 af31] {master:0}[edit class-of-service classifiers dscp my-dscp-classifier] lab@exD-1# set import default {master:0}[edit class-of-service classifiers dscp my-dscp-classifier] lab@exD-1#

Step 2.5 For the my-be forwarding class, change the default loss priority level of low to high for the code-point alias be (000000). {master:0}[edit class-of-service classifiers dscp my-dscp-classifier] lab@exD-1# set forwarding-class my-be loss-priority high code-points be {master:0}[edit class-of-service classifiers dscp my-dscp-classifier] lab@exD-1# show import default; forwarding-class my-ef { loss-priority low code-points ef; } forwarding-class my-af { loss-priority low code-points af41; } forwarding-class my-nc { loss-priority low code-points [ cs3 af31 ]; } forwarding-class my-be { loss-priority high code-points be; }

Step 2.6 Associate this newly defined DSCP classifier with all logical Gigabit Ethernet interfaces. Use the commit command to activate the recent changes. {master:0}[edit class-of-service classifiers dscp my-dscp-classifier] lab@exD-1# up 2 {master:0}[edit class-of-service] lab@exD-1# set interfaces ge-* unit * classifiers dscp my-dscp-classifier {master:0}[edit class-of-service] lab@exD-1# commit configuration check succeedscommit complete {master:0}[edit class-of-service] lab@exD-1#

www.juniper.net



The attached SRX devices have been pre-configured with a similar CoS configuration. Step 2.7 Issue the run show class-of-service interface ge-0/0/6 command to verify that the new custom DSCP classifier is now associated with the ge-0/0/6 interface. {master:0}[edit class-of-service] lab@exD-1# run show class-of-service interface ge-0/0/6 Physical interface: ge-0/0/6, Index: 136 Queues supported: 8, Queues in use: 4 Scheduler map: , Index: 2 Congestion-notification: Disabled Logical interface: ge-0/0/6.0, Index: 2147404772 Object Name Type Classifier my-dscp-classifier dscp

Index 63804

Question: Is the custom DSCP classifier now associated with the ge-0/0/6.0 interface?

Answer: Yes, at this time, the custom DSCP classifier should be associated with the ge-0/0/6 interface. Note that because the custom classifier is explicitly associated with the ge-0/0/6.0 access port, the implicit default classifier (ieee8021p-untrust) is no longer applied and has effectively been overridden. If a DSCP classifier is associated with trunk ports, the default classifier () is not removed. This point is illustrated in the following sample capture, which is taken from the ge-0/0/10.0 trunk port: {master:0}[edit class-of-service] lab@exD-1# run show class-of-service interface ge-0/0/10 Physical interface: ge-0/0/10, Index: 141 Queues supported: 8, Queues in use: 4 Scheduler map: , Index: 2 Congestion-notification: Disabled Logical interface: ge-0/0/10.0, Index: 2147404772 Object Name Type Classifier my-dscp-classifier dscp Classifier ieee8021p-default ieee8021p


Index 63804 11

www.juniper.net


Step 2.8 Issue the run show class-of-service classifier name my-dscp-classifier command to verify that the recent changes have taken effect. {master:0}[edit class-of-service] lab@exD-1# run show class-of-service classifier name my-dscp-classifier Classifier: my-dscp-classifier, Code point type: dscp, Index: 63804 Code point Forwarding class Loss priority 000000 my-be high ... 011000 my-nc low ... 011010 my-nc low ... 100010 my-af low ... 101110 my-ef low ...

Question: Are the correct code-point to forwarding class mappings and loss priority levels now active for the custom DSCP classifier?

Answer: Yes, at this time, the custom DSCP classifier should have the correct mappings between the defined code-point aliases and the correct loss priority levels set for each classification. If your output does not show the correct associations and loss priority levels, check your configuration and, if needed, work with your instructor. Step 2.9 Create a new scheduler for each queue defined earlier. Use the following table for configuration details for each scheduler.

Scheduler Configuration Details

www.juniper.net

Name

Transmit rate

Buffer size

Priority

my-be-sched

30%

50%

Low

my-af-sched

70%

20%

Low

my-ef-sched

N/A

20%

Strict High

my-nc-sched

N/A

10%

Strict High



{master:0}[edit class-of-service] lab@exD-1# edit schedulers {master:0}[edit class-of-service schedulers] lab@exD-1# set my-be-sched transmit-rate percent 30 {master:0}[edit class-of-service schedulers] lab@exD-1# set my-be-sched buffer-size percent 50 {master:0}[edit class-of-service schedulers] lab@exD-1# set my-be-sched priority low {master:0}[edit class-of-service schedulers] lab@exD-1# set my-af-sched transmit-rate percent 70 {master:0}[edit class-of-service schedulers] lab@exD-1# set my-af-sched buffer-size percent 20 {master:0}[edit class-of-service schedulers] lab@exD-1# set my-af-sched priority low {master:0}[edit class-of-service schedulers] lab@exD-1# set my-ef-sched buffer-size percent 20 {master:0}[edit class-of-service schedulers] lab@exD-1# set my-ef-sched priority strict-high {master:0}[edit class-of-service schedulers] lab@exD-1# set my-nc-sched buffer-size percent 10 {master:0}[edit class-of-service schedulers] lab@exD-1# set my-nc-sched priority strict-high {master:0}[edit class-of-service schedulers] lab@exD-1#

Step 2.10 Create a scheduler map named my-scheduler-map that maps the recently defined schedulers with their corresponding forwarding classes and queues. {master:0}[edit class-of-service schedulers] lab@exD-1# up {master:0}[edit class-of-service] lab@exD-1# edit scheduler-maps {master:0}[edit class-of-service scheduler-maps] lab@exD-1# set my-scheduler-map forwarding-class my-be scheduler my-be-sched {master:0}[edit class-of-service scheduler-maps] lab@exD-1# set my-scheduler-map forwarding-class my-af scheduler my-af-sched {master:0}[edit class-of-service scheduler-maps] lab@exD-1# set my-scheduler-map forwarding-class my-ef scheduler my-ef-sched


www.juniper.net


{master:0}[edit class-of-service scheduler-maps] lab@exD-1# set my-scheduler-map forwarding-class my-nc scheduler my-nc-sched {master:0}[edit class-of-service scheduler-maps] lab@exD-1# show my-scheduler-map { forwarding-class my-be scheduler my-be-sched; forwarding-class my-af scheduler my-af-sched; forwarding-class my-ef scheduler my-ef-sched; forwarding-class my-nc scheduler my-nc-sched; } {master:0}[edit class-of-service scheduler-maps] lab@exD-1#

Step 2.11 Associate the newly defined scheduler map with all physical Gigabit Ethernet interfaces. Issue the commit command to activate the configuration changes. {master:0}[edit class-of-service scheduler-maps] lab@exD-1# up {master:0}[edit class-of-service] lab@exD-1# set interfaces ge-* scheduler-map ? Possible completions: Output scheduler map my-scheduler-map {master:0}[edit class-of-service] lab@exD-1# set interfaces ge-* scheduler-map my-scheduler-map {master:0}[edit class-of-service] lab@exD-1# commit configuration check succeedscommit complete {master:0}[edit class-of-service] lab@exD-1# Note

The attached SRX devices have been pre-configured with a similar CoS configuration. Step 2.12 Issue the run show class-of-service interface ge-0/0/10 command to verify that the newly defined and applied scheduler map has been associated with the ge-0/0/10 interface. {master:0}[edit class-of-service] lab@exD-1# run show class-of-service interface ge-0/0/10 Physical interface: ge-0/0/10, Index: 140 Queues supported: 8, Queues in use: 4 Scheduler map: my-scheduler-map, Index: 17638 Congestion-notification: Disabled

www.juniper.net



Logical interface: ge-0/0/10.0, Index: 2147404772 Object Name Type Classifier my-dscp-classifier dscp Classifier ieee8021p-default ieee8021p

Index 63804 11

Question: Is the custom scheduler map associated with the ge-0/0/10 interface?

Answer: Yes, the custom scheduler map should be associated with ge-0/0/10 (and all other physical Gigabit Ethernet interfaces in your EX Series switch). If you do not see this association in the generated output, check your configuration and, if needed, work with your instructor. Step 2.13 Issue the run show interfaces ge-0/0/10 extensive | find "Queue counters" command to view current scheduler details and statistics for the ge-0/0/10 interface. {master:0}[edit class-of-service] lab@exD-1# run show interfaces ge-0/0/10 extensive | find "Queue counters" Queue counters: Queued packets Transmitted packets Dropped packets 0 my-be 0 0 0 1 my-af 0 0 0 5 my-ef 0 0 0 7 my-nc 0 2 0 ... CoS information: Direction : Output CoS transmit queue Bandwidth Buffer Priority Limit % bps % usec 0 my-be 30 300000000 50 NA low none 1 my-af 70 700000000 20 NA low none 5 my-ef r r 20 NA strict-high none 7 my-nc r r 10 NA strict-high none


www.juniper.net


Question: Which queues currently show non-zero counters for the ge-0/0/10 interface?

Answer: Your answer might vary. In the sample output, the only queue with a non-zero counter is queue 7, which is associated with the my-nc forwarding class. In a subsequent lab task you generate multiple flows of traffic with different CoS bits to verify proper classification. Note that you can also use the run show interfaces queue ge-0/0/10 command to view queue-based statistics for a given interface as shown in the following output: {master:0}[edit class-of-service] lab@exD-1# run show interfaces queue ge-0/0/10 Physical interface: ge-0/0/10, Enabled, Physical link is Up Interface index: 140, SNMP ifIndex: 524 Forwarding classes: 16 supported, 4 in use Egress queues: 8 supported, 4 in use Queue: 0, Forwarding classes: my-be Queued: Transmitted: Packets : 0 Bytes : 0 Tail-dropped packets : 0 Queue: 1, Forwarding classes: my-af Queued: Transmitted: Packets : 0 Bytes : 0 Tail-dropped packets : 0 Queue: 5, Forwarding classes: my-ef Queued: Transmitted: Packets : 0 Bytes : 0 Tail-dropped packets : 0 Queue: 7, Forwarding classes: my-nc Queued: Transmitted: Packets : 2 Bytes : 136 Tail-dropped packets : 0

Step 2.14 Associate the default DSCP rewrite rule with all logical Gigabit Ethernet interfaces. Activate the change using the commit command.

www.juniper.net



{master:0}[edit class-of-service] lab@exD-1# set interfaces ge-* unit * rewrite-rules dscp default {master:0}[edit class-of-service] lab@exD-1# commit configuration check succeedscommit complete Note

The attached SRX devices have been pre-configured with a similar CoS configuration. Step 2.15 Issue the run show class-of-service interface ge-0/0/10 command to ensure that the default DSCP rewrite rule has been applied to the ge-0/0/10.0 interface. {master:0}[edit class-of-service] lab@exD-1# run show class-of-service interface ge-0/0/10 Physical interface: ge-0/0/10, Index: 140 Queues supported: 8, Queues in use: 4 Scheduler map: my-scheduler-map, Index: 17638 Congestion-notification: Disabled Logical interface: ge-0/0/10.0, Index: 2147404772 Object Name Type Rewrite dscp-default dscp Classifier my-dscp-classifier dscp Classifier ieee8021p-default ieee8021p

Index 31 63804 11

Question: Is the default DSCP rewrite rule now associated with the ge-0/0/10.0 interface?

Answer: Yes, at this time the default DSCP rewrite rule should be associated with the ge-0/0/10.0 interface (and all other logical Gigabit Ethernet interfaces). If you do not see this association, check your configuration. Step 2.16 Return to the session opened for your assigned SRX device. If needed, open a new session and log in using the credentials provided by your instructor.


www.juniper.net


Use the ping utility to send traffic from your assigned vrx0 virtual router (VR) to your assigned vry1 VR, where y is either 1 or 2 depending on your assigned devices. As the destination IP address, use the IP address from the 172.23.25.0/24 subnet assigned to your vry1 VR. To test proper classification, use the tos option with values 0, 96, 104, 136, and 184 when performing your ping tests. Refer to the network diagram for the instance names and the IP addresses assigned to your VRs. Do not forget to reference the correct routing instance. lab@srxD-1> ping routing-instance vry0 172.23.25.z1 rapid count 25 tos 0 PING 172.23.25.11 (172.23.25.11): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.23.25.11 ping statistics --25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.962/1.971/7.031/2.095 ms lab@srxD-1> ping routing-instance vry0 172.23.25.z1 rapid count 25 tos 96 PING 172.23.25.11 (172.23.25.11): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.23.25.11 ping statistics --25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.959/3.033/6.949/2.082 ms lab@srxD-1> ping routing-instance vry0 172.23.25.z1 rapid count 25 tos 104 PING 172.23.25.11 (172.23.25.11): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.23.25.11 ping statistics --25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.966/2.300/8.316/2.454 ms lab@srxD-1> ping routing-instance vry0 172.23.25.z1 rapid count 25 tos 136 PING 172.23.25.11 (172.23.25.11): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.23.25.11 ping statistics --25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.923/1.621/7.017/1.663 ms lab@srxD-1> ping routing-instance vry0 172.23.25.z1 rapid count 25 tos 184 PING 172.23.25.11 (172.23.25.11): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.23.25.11 ping statistics --25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.959/1.769/6.878/1.839 ms

Step 2.17 Return to the session opened for your assigned EX Series switch. Issue the run show interfaces queue ge-0/0/7 command to verify that all queues for the ge-0/0/7 interface show a non-zero counter value for egress traffic. {master:0}[edit class-of-service] lab@exD-1# run show interfaces queue ge-0/0/7 Physical interface: ge-0/0/7, Enabled, Physical link is Up Interface index: 137, SNMP ifIndex: 518 Forwarding classes: 16 supported, 4 in use Egress queues: 8 supported, 4 in use Queue: 0, Forwarding classes: my-be www.juniper.net



Queued: Transmitted: Packets : Bytes : Tail-dropped packets : Queue: 1, Forwarding classes: my-af Queued: Transmitted: Packets : Bytes : Tail-dropped packets : Queue: 5, Forwarding classes: my-ef Queued: Transmitted: Packets : Bytes : Tail-dropped packets : Queue: 7, Forwarding classes: my-nc Queued: Transmitted: Packets : Bytes : Tail-dropped packets :

27 2778 0

25 2650 0

25 2650 0

70 11560 0

Question: Do all queues for the ge-0/0/7 interface show a non-zero counter value for egress traffic?

Answer: Yes, at this time all queues should show a non-zero counter value for egress traffic. Note

You can perform similar tests with traffic destined to the remote VRs.

STOP


Part 3: Implementing CoS Using the EZQoS Template In this lab part, you use the EZQoS template to simplify the implementation of CoS components. Step 3.1 On your EX Series switch, delete all configuration under the [edit class-of-service] hierarchy. Use the commit command to activate the configuration changes. Lab 5–20 • Class of Service (Detailed)

www.juniper.net


{master:0}[edit class-of-service] lab@exD-1# delete Delete everything under this level? [yes,no] (no) yes {master:0}[edit class-of-service] lab@exD-1# commit configuration check succeedscommit complete

Step 3.2 Navigate to the root hierarchy level and issue the load merge /etc/config/ ezqos-voip.conf command to load the EZQoS configuration template. {master:0}[edit class-of-service] lab@exD-1# top {master:0}[edit] lab@exD-1# load merge /etc/config/ezqos-voip.conf load complete {master:0}[edit] lab@exD-1# show groups ezqos-voip { class-of-service { classifiers { dscp ezqos-dscp-classifier { import default; forwarding-class ezqos-voice-fc { loss-priority low code-points 101110; } forwarding-class ezqos-control-fc { loss-priority low code-points [ 110000 011000 011010 111000 ]; } forwarding-class ezqos-video-fc { loss-priority low code-points 100010; } } } forwarding-classes { class ezqos-best-effort queue-num 0; class ezqos-video-fc queue-num 4; class ezqos-voice-fc queue-num 5; class ezqos-control-fc queue-num 7; } scheduler-maps { ezqos-voip-sched-maps { forwarding-class ezqos-voice-fc scheduler ezqos-voice-scheduler; forwarding-class ezqos-control-fc scheduler ezqos-control-scheduler; forwarding-class ezqos-video-fc scheduler ezqos-video-scheduler; forwarding-class ezqos-best-effort scheduler ezqos-data-scheduler; } } schedulers { www.juniper.net



ezqos-voice-scheduler { buffer-size percent 20; priority strict-high; } ezqos-control-scheduler { buffer-size percent 10; priority strict-high; } ezqos-video-scheduler { transmit-rate percent 70; buffer-size percent 20; priority low; } ezqos-data-scheduler { transmit-rate percent 30; buffer-size percent 50; priority low; } } } } {master:0}[edit] lab@exD-1#

Step 3.3 Issue the set apply-groups ezqos-voip command to apply the ezqos-voip configuration group loaded in the previous step. {master:0}[edit] lab@exD-1# set apply-groups ezqos-voip

Step 3.4 Associate the ezqos-dscp-classifier with all logical Gigabit Ethernet interfaces. {master:0}[edit] lab@exD-1# edit class-of-service interfaces {master:0}[edit class-of-service interfaces] lab@exD-1# set ge-* unit * classifiers dscp ezqos-dscp-classifier {master:0}[edit class-of-service interfaces] lab@exD-1#

Step 3.5 Associate the ezqos-voip-sched-maps with all physical Gigabit Ethernet interfaces. {master:0}[edit class-of-service interfaces] lab@exD-1# set ge-* scheduler-map ezqos-voip-sched-maps {master:0}[edit class-of-service interfaces] lab@exD-1# show ge-* { scheduler-map ezqos-voip-sched-maps; Lab 5–22 • Class of Service (Detailed)

www.juniper.net


unit * { classifiers { dscp ezqos-dscp-classifier; } } }

Step 3.6 Issue the commit command to activate the configuration changes. Next, issue the run show class-of-service interface ge-0/0/6 command to verify the current CoS components associated with the ge-0/0/6 interface. {master:0}[edit class-of-service interfaces] lab@exD-1# commit configuration check succeeds commit complete {master:0}[edit class-of-service interfaces] lab@exD-1# run show class-of-service interface ge-0/0/6 Physical interface: ge-0/0/6, Index: 136 Queues supported: 8, Queues in use: 5 Scheduler map: ezqos-voip-sched-maps, Index: 37585 Congestion-notification: Disabled Logical interface: ge-0/0/6.0, Index: 2147404772 Object Name Type Classifier ezqos-dscp-classifier dscp

Index 57624

Question: Are the CoS components defined within the template now associated with the ge-0/0/6 interface?

Answer: Yes, at this time the CoS components defined within the template should be associated with the ge-0/0/6 interface (and all other Gigabit Ethernet interfaces). If you do not see a similar result, check your configuration. Question: How many queues are currently in use? Can you explain why ?

Answer: As shown in the sample output, five queues should be in use currently. As shown in the following output, the template configuration added a new queue for video traffic (Queue 4):

www.juniper.net



{master:0}[edit class-of-service interfaces] lab@exD-1# run show interfaces queue ge-0/0/6 Physical interface: ge-0/0/6, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 516 Forwarding classes: 16 supported, 5 in use Egress queues: 8 supported, 5 in use Queue: 0, Forwarding classes: ezqos-best-effort Queued: Transmitted: Packets : 84 Bytes : 7492 Tail-dropped packets : 0 Queue: 1, Forwarding classes: assured-forwarding Queued: Transmitted: Packets : 0 Bytes : 0 Tail-dropped packets : 0 Queue: 4, Forwarding classes: ezqos-video-fc Queued: Transmitted: Packets : 0 Bytes : 0 Tail-dropped packets : 0 Queue: 5, Forwarding classes: ezqos-voice-fc Queued: Transmitted: Packets : 25 Bytes : 2650 Tail-dropped packets : 0 Queue: 7, Forwarding classes: ezqos-control-fc Queued: Transmitted: Packets : 285 Bytes : 78855 Tail-dropped packets : 0

Step 3.7 Associate the default DSCP rewrite rule with all logical Gigabit Ethernet interfaces. Activate this configuration change using the commit command. {master:0}[edit class-of-service interfaces] lab@exD-1# set ge-* unit * rewrite-rules dscp default {master:0}[edit class-of-service interfaces] lab@exD-1# commit configuration check succeedscommit complete

Step 3.8 Issue the run show class-of-service interface ge-0/0/6 command to verify that the default DSCP rewrite rule is now associated with the ge-0/0/6 interface.


www.juniper.net


{master:0}[edit class-of-service interfaces] lab@exD-1# run show class-of-service interface ge-0/0/6 Physical interface: ge-0/0/6, Index: 136 Queues supported: 8, Queues in use: 5 Scheduler map: ezqos-voip-sched-maps, Index: 37585 Congestion-notification: Disabled Logical interface: ge-0/0/6.0, Index: 2147404772 Object Name Type Rewrite dscp-default dscp Classifier ezqos-dscp-classifier dscp

Index 31 57624

Question: Is the default DSCP rewrite rule now associated with the ge-0/0/6.0 interface?

Answer: Yes, as shown in the sample output, the default DSCP rewrite rule (dscp-default) should now be associated with the ge-0/0/6.0 interface (and all logical Gigabit Ethernet interfaces). Step 3.9 Add the ezqos-voice-fc forwarding class as the designated forwarding class for the voice VLAN defined in a previous lab. Activate the configuration change and return to operational mode using the commit and-quit command. {master:0}[edit class-of-service interfaces] lab@exD-1# top edit ethernet-switching-options {master:0}[edit ethernet-switching-options] lab@exD-1# set voip interface access-ports forwarding-class ezqos-voice-fc {master:0}[edit ethernet-switching-options] lab@exD-1# show voip { interface access-ports { vlan voice; forwarding-class ezqos-voice-fc; } } storm-control { interface all; } {master:0}[edit ethernet-switching-options] lab@exD-1# commit and-quit configuration check succeedscommit complete Exiting configuration mode {master:0} lab@exD-1> www.juniper.net



If time permits, you can perform verification tests using the ping utility on your assigned SRX device as you did toward the end of Part 2 of this lab.

STOP



www.juniper.net

Lab 6 Monitoring and Troubleshooting Layer 2 Networks (Detailed)

Overview In this lab, you will first load a configuration file that will introduce problems that you will troubleshoot and fix. You will then examine hardware components and system processes. Next you will examine Ethernet switching functionality, the Multiple Spanning Tree Protocol (MSTP), and interface functionality. Finally you will configure port mirroring and the sFlow feature for monitoring purposes. As you identify problems throughout this lab, you will take corrective actions to fix them. The lab is available in two formats: a high-level format designed to make you think through each step and a detailed format that offers step-by-step instructions complete with sample output from most commands. By completing this lab you will perform the following tasks:

www.juniper.net

•

Examine hardware components.

•

Examine and troubleshoot system processes.

•

Examine and troubleshoot Ethernet switching functionality.

•

Examine and troubleshoot MSTP.

•

Examine and troubleshoot Aggregated Ethernet interfaces.

•

Configure and monitor port mirroring.

•

Configure and monitor sFlow.

Monitoring and Troubleshooting Layer 2 Networks (Detailed) • Lab 6–1 10.b.10.4R3.4


Part 1: Modifying the Existing Configurations In this lab part, you load and activate a predefined configuration saved on your assigned devices. This predefined configuration will introduce a number of issues in your network. You will then troubleshoot the issues to restore network functionality. Step 1.1 Return to the session opened for your assigned SRX device. If needed, open a new session and log in using the credentials provided by your instructor. Enter configuration mode and override the existing configuration file with the lab6-start.conf configuration file stored in the /var/home/lab/ajex/ directory. Issue the commit and-quit command to activate the new configuration file and return to operational mode. lab@srxD-1> configure Entering configuration mode [edit] lab@srxD-1# load override /var/home/lab/ajex/lab6-start.conf load complete [edit] lab@srxD-1# commit and-quit commit complete Exiting configuration mode lab@srxD-1>

Step 1.2 Return to the session opened for your assigned EX Series switch. If needed, open a new session and log in using the credentials provided by your instructor. Enter configuration mode and override the existing configuration file with the lab6-start.conf configuration file stored in the /var/home/lab/ajex/ directory. Issue the commit command to activate the new configuration file. {master:0} lab@exD-1> configure Entering configuration mode {master:0}[edit] lab@exD-1# load override /var/home/lab/ajex/lab6-start.conf load complete {master:0}[edit] lab@exD-1# commit configuration check succeeds commit complete {master:0}[edit] lab@exD-1#

Lab 6–2 • Monitoring and Troubleshooting Layer 2 Networks (Detailed)

www.juniper.net


Part 2: Determining Success In this lab part, you will examine key processes and hardware components to determine why vr10 cannot communicate with vr20. Step 2.1 On your assigned SRX device, use the ping utility and verify communication between the vr10 and the vr20 devices. Note that the interfaces on the SRX devices are configured for 802.1Q operations with a VLAN ID of 10. Refer to the network diagram for the instance names and the IP addresses assigned to the various virtual routers (VRs). Do not forget to reference the correct routing instance. lab@srxD-1> ping routing-instance vry0 172.23.10.10z count 2 PING 172.23.10.102 (172.23.10.102): 56 data bytes --- 172.23.10.102 ping statistics --2 packets transmitted, 0 packets received, 100% packet loss

Step 2.2 On your assigned SRX device, use the ping utility and verify communication between the vr11 and the vr21 devices. Note that the interfaces on the SRX devices are configured for 802.1Q operations with a VLAN ID of 11. Refer to the network diagram for the instance names and the IP addresses assigned to the various VRs. Do not forget to reference the correct routing instance. lab@srxD-1> ping routing-instance vry1 172.23.11.10z count 2 PING 172.23.11.102 (172.23.11.102): 56 data bytes --- 172.23.11.102 ping statistics --2 packets transmitted, 0 packets received, 100% packet loss

Question: What do the ping tests reveal?

Answer: The ping tests reveal an issue with Layer 3 communication. Question: Can any value be gained from testing Layer 4 or higher?

Answer: No. We have established a failed Layer 3 test through the ping utility. The issue cannot exist above Layer 3.

www.juniper.net

Monitoring and Troubleshooting Layer 2 Networks (Detailed) • Lab 6–3


Question: What criteria will determine if the network has returned to a functioning state?

Answer: The network will have returned to a functioning state when the VR devices can communicate and that communication traverses the desired path.

Part 3: Verifying Hardware Components and System Processes In this lab part, you will verify your assigned EX Series switch’s hardware components and system processes in an effort to find what is causing the issue. Step 3.1 On your assigned EX Series switch, issue the run show chassis routing-engine command. {master:0}[edit] lab@exD-1# run show chassis routing-engine Routing Engine status: Slot 0: Current state Master Election priority Master (default) Temperature 51 degrees C / 123 degrees F CPU temperature 51 degrees C / 123 degrees F DRAM 1024 MB Memory utilization 29 percent CPU utilization: User 4 percent Background 0 percent Kernel 1 percent Interrupt 0 percent Idle 94 percent Model EX4200-24T, 8 POE Serial ID BM0208105168 Start time 2011-01-06 11:55:01 UTC Uptime 14690 days, 1 hour, 22 minutes, 46 seconds Last reboot reason Router rebooted after a normal shutdown. Load averages: 1 minute 5 minute 15 minute 0.04 0.03 0.03


www.juniper.net


Question: What CPU and memory utilization is present in the output?

Answer: Your answer might vary, but as shown in the previous output, the CPU and memory utilization is very low. Step 3.2 Issue the run show chassis alarms and run show system alarms commands. {master:0}[edit] lab@exD-1# run show chassis alarms No alarms currently active {master:0}[edit] lab@exD-1# run show system alarms 1 alarms currently active Alarm time Class Description 2011-01-06 11:56:22 UTC Minor Rescue configuration is not set

Question: Are any problems detected?

Answer: No. Although you might see a minor system alarm in reference to the rescue configuration, which is not cause for concern. Step 3.3 Issue the run show interfaces terse ge* command.

www.juniper.net



{master:0}[edit] lab@exD-1# run show interfaces terse ge* Interface Admin Link Proto Local ge-0/0/0 up down ge-0/0/1 up down ge-0/0/2 up down ge-0/0/3 up down ge-0/0/4 up down ge-0/0/5 up down ge-0/0/6 up up ge-0/0/6.0 up up eth-switch ge-0/0/7 up up ge-0/0/7.0 up up eth-switch ge-0/0/8 up up ge-0/0/8.0 up up aenet --> ae0.0 ge-0/0/9 up up ge-0/0/9.0 up up aenet --> ae0.0 ge-0/0/10 up up ge-0/0/10.0 up up eth-switch ge-0/0/11 up up ge-0/0/12 up up ge-0/0/12.0 up up eth-switch ge-0/0/13 up up ge-0/0/14 up up ge-0/0/15 up up ge-0/0/16 up down ge-0/0/17 up down ge-0/0/18 up down ge-0/0/19 up down ge-0/0/20 up down ge-0/0/21 up down ge-0/0/22 up down ge-0/0/23 up down

Remote

Question: What does this output reveal?

Answer: This output reveals the interfaces found in the lab diagram have Layer 1 connectivity. It also reveals the administrative status and the applied protocols to the interfaces. Question: Does the problem appear to be a Layer 1 issue?

Answer: No. The previous output indicates this problem is not a Layer 1 issue.


www.juniper.net


Step 3.4 Issue the run show system processes extensive command. {master:0}[edit] lab@exD-1# run show system processes extensive last pid: 27115; load averages: 0.06, 0.03, 0.00 up 25+12:57:27 106 processes: 3 running, 83 sleeping, 1 zombie, 19 waiting

00:51:58

Mem: 173M Active, 18M Inact, 89M Wired, 3812K Cache, 110M Buf, 700M Free Swap:

PID 11 798 795 13 796 823 803 20 807 797 804 827 802 809 12 40 49 814 36 2 ...

USERNAME root root root root root root root root root root root root root root root root root root root root

THR 1 1 1 1 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

PRI 171 8 4 -20 44 96 96 -52 96 4 96 96 96 4 -40 -16 12 96 20 -8

NICE 52 0 0 -139 -52 0 0 -171 0 -20 0 0 0 0 -159 0 0 0 0 0

SIZE RES STATE TIME WCPU COMMAND 0K 16K RUN 572.5H 96.04% idle 82044K 19052K nanslp 25.1H 1.12% pfem 14304K 4112K kqread 584:27 0.00% chassism 0K 16K RUN 179:51 0.00% swi7: clock 63720K 6396K select 22:43 0.00% sfid 10376K 4100K select 22:14 0.00% jdiameterd 20840K 10868K select 12:29 0.00% chassisd 0K 16K WAIT 12:18 0.00% irq43: i2c0 i2c1 18656K 13568K select 7:00 0.00% snmpd 10860K 6464K kqread 6:36 0.00% vccpd 5356K 1868K select 5:57 0.00% alarmd 3580K 968K select 5:34 0.00% license-check 20232K 4672K select 5:27 0.00% dcd 31672K 8904K kqread 5:21 0.00% rpd 0K 16K WAIT 4:45 0.00% swi2: net 0K 16K psleep 3:08 0.00% vmkmemdaemon 0K 16K 3:06 0.00% schedcpu 5952K 2360K select 3:04 0.00% ppmd 0K 16K syncer 2:26 0.00% syncer 0K 16K 2:07 0.00% g_event

Question: Is the daemon that controls the Ethernet switching functions running?

Answer: No. The eswd daemon is not running. Question: Does the absence of the eswd daemon affect traffic flows between the VR devices?

Answer: Yes. The EX Series switch cannot forward frames in this state.

www.juniper.net



Step 3.5 To determine why the eswd daemon is not running, examine the log messages file on your assigned EX Series switch. Use the | match eswd option to narrow your search. {master:0}[edit] lab@exD-1# run show log messages | match eswd ... Feb 1 01:07:27 exD-1 eswd[28093]: TASK_SIGNAL_TERMINATE: first termination signal received Feb 1 01:07:53 exD-1 mgd[19029]: UI_CMDLINE_READ_LINE: User 'lab', command 'run show log messages | match eswd '

Question: What does this output reveal?

Answer: The eswd daemon has terminated and is currently not running. Step 3.6 Restart the eswd daemon by issuing the run restart ethernet-switching command. {master:0}[edit] lab@exD-1# run restart ethernet-switching warning: ethernet-switching subsystem has been disabled by the user

Question: What is the result of attempting to restart the eswd daemon?

Answer: The Junos OS is unable to restart the eswd daemon because the Ethernet switching subsystem has been disabled. Step 3.7 Navigate to the [edit system processes] hierarchy level and remove the configuration that is disabling the eswd daemon. Activate the changes using the commit command. {master:0}[edit] lab@exD-1# edit system processes {master:0}[edit system processes] lab@exD-1# delete ethernet-switching disable {master:0}[edit system processes] lab@exD-1# commit Lab 6–8 • Monitoring and Troubleshooting Layer 2 Networks (Detailed)

www.juniper.net


configuration check succeeds commit complete

Step 3.8 Check the status of the eswd daemon by issuing the run show system processes extensive | match eswd command. {master:0}[edit system processes] lab@exD-1# run show system processes extensive | match eswd 28625 root 1 4 0 9552K 5172K kqread 0:00 0.00% eswd

Question: Is the eswd daemon running?

Answer: Yes. The eswd daemon is running.

STOP

Before proceeding, ensure that the remote student team in your pod finishes the previous steps.

Step 3.9 Return to your assigned SRX device, use the ping utility and verify communication between the vr10 and the vr20 devices. Refer to the network diagram for the instance names and the IP addresses assigned to the various VRs. Do not forget to reference the correct routing instance. lab@srxD-1> ping routing-instance vry0 172.23.10.10z count 2 PING 172.23.10.102 (172.23.10.102): 56 data bytes --- 172.23.10.102 ping statistics --2 packets transmitted, 0 packets received, 100% packet loss

Step 3.10 On your assigned SRX device, use the ping utility and verify communication between the vr11 and the vr21 devices. Refer to the network diagram for the instance names and the IP addresses assigned to the various VRs. Do not forget to reference the correct routing instance. lab@srxD-1> ping routing-instance vry1 172.23.11.10z count 2 PING 172.23.11.102 (172.23.11.102): 56 data bytes --- 172.23.11.102 ping statistics --2 packets transmitted, 0 packets received, 100% packet loss

www.juniper.net




Answer: The communications path is still not available. While the eswd daemon is required to pass Layer 2 traffic, many other possible reasons exist that a communications path might not be available. Our troubleshooting adventure continues.

Part 4: Verifying Ethernet Switching, MSTP, and Aggregate Ethernet Interfaces In this part, you will examine the Ethernet switching table and the aggregated Ethernet interfaces. You will then troubleshoot and fix any problems that are found. Step 4.1 Open a new session to the SRX device assigned to the remote team. Log in to that device using the credentials provided by your instructor. Find the media access control (MAC) address associated with the vry0 device, where y is either 1 or 2 depending on the SRX device. Refer to the network diagram for this lab as needed. srxD-2 (ttyu0) login: lab Password: --- JUNOS 10.4R3.4 built 2011-03-19 22:29:40 UTC lab@srxD-2> show interfaces ge-0/0/6 | match hardware Current address: 00:26:88:02:6b:86, Hardware address: 00:26:88:e1:4f:86 lab@srxD-2>

Question: What is the current MAC address assigned to the remote vry0 device?

Answer: The answer might vary. In this case, the current MAC address assigned to vr20 in the sample capture is 00:26:88:02:6b:86. Step 4.2 Return to the session opened for your assigned EX Series switch. On your assigned EX Series switch, display the Ethernet switching table and determine whether the MAC address associated with the remote team’s vry0 device is present. Note that your output might vary from the following sample capture.


www.juniper.net


{master:0}[edit system processes] lab@exD-1# run show ethernet-switching table Ethernet-switching table: 3 entries, 0 learned VLAN MAC address Type v10 * Flood v10 00:26:88:02:6b:86 Static v11 * Flood

Age -

Interfaces All-members ge-0/0/6.0 All-members

Question: Is the MAC address for the remote team’s vry0 device present?

Answer: Yes. The MAC address should be present. Question: Can you find any problems with the MAC address entry?

Answer: The MAC address entry is a static entry that directs traffic destined for the remote team’s VR device back toward your local VR device. Step 4.3 Remove any static MAC address entries configured on your assigned EX Series switch. Activate the changes using the commit command. {master:0}[edit system processes] lab@exD-1# top edit ethernet-switching-options {master:0}[edit ethernet-switching-options] lab@exD-1# show storm-control { interface all; } static { vlan v10 { mac 00:26:88:02:6b:86 next-hop ge-0/0/6.0; } } {master:0}[edit ethernet-switching-options] lab@exD-1# delete static {master:0}[edit ethernet-switching-options] lab@exD-1# commit configuration check succeedscommit complete {master:0}[edit ethernet-switching-options] lab@exD-1#

www.juniper.net



Step 4.4 Examine the Ethernet switching table. {master:0}[edit ethernet-switching-options] lab@exD-1# run show ethernet-switching table Ethernet-switching table: 3 entries, 1 learned VLAN MAC address Type v10 * Flood v10 00:26:88:02:74:86 Learn v11 * Flood

Age 4:36 -

Interfaces All-members ge-0/0/6.0 All-members

Question: Is the static MAC address entry present?

Answer: No. The static MAC address entry has been removed. Note that your output might vary from the sample capture provided.

STOP


Step 4.5 Return to the session opened for your assigned SRX device. Use the ping utility and verify communication between the vr10 and the vr20 devices. Refer to the network diagram for the instance names and the IP addresses assigned to the various VRs. Do not forget to reference the correct routing instance. lab@srxD-1> ping routing-instance vry0 172.23.10.10z count 2 PING 172.23.10.102 (172.23.10.102): 56 data bytes --- 172.23.10.102 ping statistics --2 packets transmitted, 0 packets received, 100% packet loss

Step 4.6 On your assigned SRX device, use the ping utility and verify communication between the vr11 and the vr21 devices. Refer to the network diagram for the instance names and the IP addresses assigned to the various VRs. Do not forget to reference the correct routing instance. lab@srxD-1> ping routing-instance vry1 172.23.11.10z count 2 PING 172.23.11.102 (172.23.11.102): 56 data bytes --- 172.23.11.102 ping statistics --2 packets transmitted, 0 packets received, 100% packet loss


www.juniper.net



Answer: The communications path is still not available. While the changes made so far were necessary, a problem still lingers. Our troubleshooting adventure continues. Step 4.7 Return to the session opened for your assigned EX Series switch. On your assigned EX Series switch, examine the Ethernet switching interface information. {master:0}[edit ethernet-switching-options] lab@exD-1# run show ethernet-switching interfaces Interface State VLAN members Tag Tagging ae0.0 up v10 10 tagged v11 11 tagged ge-0/0/6.0 up v10 10 untagged ge-0/0/7.0 up v11 11 untagged ge-0/0/10.0 up v10 10 tagged v11 11 tagged ge-0/0/12.0 up v10 10 tagged v11 11 tagged

Blocking unblocked unblocked unblocked unblocked unblocked unblocked unblocked unblocked

Question: Why do the ge-0/0/6 and ge-0/0/7 interfaces show a value of untagged in the Tagging field?

Answer: The ge-0/0/6 and ge-0/0/7 interfaces are configured as access ports. They will only send and receive untagged frames. Question: Can having these two interfaces configured as access ports cause problems with your setup? Why?

Answer: Recall that the VR devices are sending 802.1Q tagged frames to your assigned EX Series switch’s ge-0/0/6 and ge-0/0/7 interfaces. These interfaces will discard any received frames that have 802.1Q tagging. www.juniper.net



Question: What can you do to overcome this issue?

Answer: The ge-0/0/6 and ge-0/0/7 interfaces can be configured as trunk ports. This configuration will allow these interfaces to send and receive 802.1Q tagged frames. Step 4.8 Configure the ge-0/0/6 and ge-0/0/7 interfaces to receive and send 802.1Q frames. Activate the changes using the commit command. {master:0}[edit ethernet-switching-options] lab@exD-1# top edit interfaces {master:0}[edit interfaces] lab@exD-1# set ge-0/0/6 unit 0 family ethernet-switching port-mode trunk {master:0}[edit interfaces] lab@exD-1# set ge-0/0/7 unit 0 family ethernet-switching port-mode trunk {master:0}[edit interfaces] lab@exD-1# show ge-0/0/6 { unit 0 { family ethernet-switching { port-mode trunk; } } } ge-0/0/7 { unit 0 { family ethernet-switching { port-mode trunk; } } } ... {master:0}[edit interfaces] lab@exD-1# commit configuration check succeedscommit complete


www.juniper.net


Step 4.9 Examine the Ethernet switching interface information again. {master:0}[edit interfaces] lab@exD-1# run show ethernet-switching interfaces Interface State VLAN members Tag Tagging ae0.0 up v10 10 tagged v11 11 tagged ge-0/0/6.0 up v10 10 tagged ge-0/0/7.0 up v11 11 tagged ge-0/0/10.0 up v10 10 tagged v11 11 tagged ge-0/0/12.0 up v10 10 tagged v11 11 tagged

Blocking unblocked unblocked unblocked unblocked unblocked unblocked unblocked unblocked

Question: Will the ge-0/0/6 and ge-0/0/7 interfaces receive and send 802.1Q tagged frames?

Answer: Yes. The ge-0/0/6 and ge-0/0/7 interfaces should now send and receive 802.1Q frames.

STOP


Step 4.10 Return to your assigned SRX device, use the ping utility and verify communication between the vr10 and the vr20 devices. Refer to the network diagram for the instance names and the IP addresses assigned to the various VRs. Do not forget to reference the correct routing instance. lab@srxD-1> ping routing-instance vry0 172.23.10.10z count 2 PING 172.23.10.102 (172.23.10.102): 56 data bytes 64 bytes from 172.23.10.102: icmp_seq=0 ttl=64 time=4.432 ms 64 bytes from 172.23.10.102: icmp_seq=1 ttl=64 time=1.196 ms --- 172.23.10.102 ping statistics --2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.196/2.814/4.432/1.618 ms

Step 4.11 On your assigned SRX device, use the ping utility and verify communication between the vr11 and the vr21 devices. Refer to the network diagram for the instance names and the IP addresses assigned to the various VRs. Do not forget to reference the correct routing instance.

www.juniper.net



lab@srxD-1> ping routing-instance vry1 172.23.11.10z count 2 PING 172.23.11.102 (172.23.11.102): 56 data bytes 64 bytes from 172.23.11.102: icmp_seq=0 ttl=64 time=24.964 ms 64 bytes from 172.23.11.102: icmp_seq=1 ttl=64 time=1.116 ms --- 172.23.11.102 ping statistics --2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.116/13.040/24.964/11.924 ms


Answer: The ping tests reveal that communication has been restored between the VR devices. Question: Is the issue resolved yet? Why or why not?

Answer: No. Even though communication has been restored, you still need to verify the path the traffic is traversing. Step 4.12 On your assigned SRX device, use the ping utility to generate a constant stream of traffic between the vr10 and vr20 devices. Issue the command ping routing-instance vry0 172.23.10.10z rapid count 10000000. Note

The value of y is 1 if your assigned SRX device is SRX1. The value of y is 2 if your assigned SRX device is SRX2. The value of z is 2 if your assigned SRX device is SRX1. The value of z is 1 if your assigned SRX device is SRX2. lab@srxD-1> ping routing-instance vry0 172.23.10.10z rapid count 100000000 PING 172.23.10.102 (172.23.10.102): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ...


www.juniper.net


Step 4.13 Return to the session opened for your assigned EX Series switch. On your assigned EX Series switch, examine which interfaces are being used for this traffic by issuing the command run monitor interface traffic. Press the Ctrl + d or Ctrl + u key combinations to scroll down or up. Press the q key when you are finished examining the output. {master:0}[edit interfaces] lab@exD-1# run monitor interface traffic exD-1 Interface ge-0/0/0 ge-0/0/1 ge-0/0/2 ge-0/0/3 ge-0/0/4 ge-0/0/5 ge-0/0/6 ge-0/0/7 ge-0/0/8 ge-0/0/9 ge-0/0/10 ge-0/0/11 ge-0/0/12 ge-0/0/13 ge-0/0/14 ge-0/0/15 ge-0/0/16 ge-0/0/17 ge-0/0/18 ge-0/0/19 ge-0/0/20 ge-0/0/21 ge-0/0/22 ge-0/0/23 xe-0/1/0 vcp-0 vcp-1 ae0 ...

Seconds: 2 Link Down Down Down Down Down Down Up Up Up Up Up Up Up Up Up Up Down Down Down Down Down Down Down Down Down Down Down Up

Input packets 0 0 0 0 0 0 181362723 180554418 180627631 539812834 416385900 180551611 207380047 0 40 38 0 0 0 0 0 0 0 0 0 0 0 720440465

(pps) (0) (0) (0) (0) (0) (0) (498) (0) (1) (1) (0) (0) (498) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0)

(2)

Time: 18:54:51 Output packets 0 0 0 0 0 0 243122467 193017016 43909729 236119021 402815493 0 232040380 0 180529837 180433142 0 0 0 0 0 0 0 0 0 0 0 280028750

(pps) (0) (0) (0) (0) (0) (0) (499) (1) (0) (0) (1) (0) (499) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0)

(0)

Question: What interfaces are being used for the ping traffic?

Answer: The ping traffic is using the ge-0/0/6 and ge-0/0/12 interfaces.

www.juniper.net



Step 4.14 Traffic flows exceeding 1 Gbps is expected from the VR devices connected to your assigned EX Series switch. The traffic flows must traverse the aggregate Ethernet links in the switched topology to accommodate this requirement. The Gigabit Ethernet links are only to be used if an aggregate Ethernet link fails. Collect spanning-tree protocol information by issuing the command run show spanning-tree bridge. {master:0}[edit interfaces] lab@exD-1# run show spanning-tree bridge STP bridge parameters Context ID Enabled protocol

: 0 : MSTP

STP bridge parameters for CIST Root ID CIST regional root CIST internal root cost Hello time Maximum age Forward delay Number of topology changes Time since last topology change Topology change initiator Topology change last recvd. from Local parameters Bridge ID Extended system ID Internal instance ID STP bridge parameters for MSTI 1 MSTI regional root Hello time Maximum age Forward delay Number of topology changes Topology change initiator Topology change last recvd. from Local parameters Bridge ID Extended system ID Internal instance ID

: : : : : : : : : :

4096.00:19:e2:51:65:80 4096.00:19:e2:51:65:80 0 2 seconds 20 seconds 15 seconds 1 1318 seconds ge-0/0/12.0 00:19:e2:55:36:0c

: 4096.00:19:e2:51:65:80 : 0 : 0

: : : : : : :

32769.00:19:e2:51:65:80 2 seconds 20 seconds 15 seconds 1 ge-0/0/12.0 00:19:e2:55:36:0c

: 32769.00:19:e2:51:65:80 : 0 : 1

Question: What spanning-tree protocol is in use?

Answer: MSTP is in use.


www.juniper.net


Question: What is the regional root bridge ID for MSTI 1?

Answer: Although your answer will vary, the regional root bridge ID in the previous output is 32769.00:19:e2:51:65:80. Step 4.15 Return to your assigned SRX device, stop the ping test by pressing the Ctrl + c key combination, and collect spanning-tree protocol information by issuing the command show spanning-tree bridge. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!^C --- 172.23.10.102 ping statistics --61312 packets transmitted, 61312 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.873/1.896/9.665/1.709 ms lab@srxD-1> show spanning-tree bridge STP bridge parameters Context ID Enabled protocol

: 0 : MSTP

STP bridge parameters for CIST Root ID Root cost Root port CIST regional root CIST internal root cost Hello time Maximum age Forward delay Hop count Message age Number of topology changes Time since last topology change Topology change initiator Topology change last recvd. from Local parameters Bridge ID Extended system ID Internal instance ID STP bridge parameters for MSTI 1 MSTI regional root Hello time Maximum age www.juniper.net

: : : : : : : : : : : : : :

4096.00:19:e2:51:65:80 20000 ae1.0 32768.00:26:88:02:6b:90 10000 2 seconds 20 seconds 15 seconds 19 1 1 785 seconds ae1.0 00:19:e2:55:36:0a

: 32768.00:26:88:02:74:90 : 0 : 0

: 16385.00:26:88:02:74:90 : 2 seconds : 20 seconds



Forward delay Number of topology changes Topology change initiator Local parameters Bridge ID Extended system ID Internal instance ID

: 15 seconds : 1 : ae1.0 : 16385.00:26:88:02:74:90 : 0 : 1

Question: What is the regional root bridge ID for MSTI 1?

Answer: Although your answer will vary, the regional root bridge ID in the previous output is 16385.00:26:88:02:74:90. Question: All devices in the network should be using the same regional root bridge for MSTI 1. What can cause two regional root bridges to appear?

Answer: While multiple answers might exist, a mismatched configuration digest is a common reason for this type of issue. Step 4.16 On your assigned SRX device, examine the configuration digest by issuing the command show spanning-tree mstp configuration. lab@srxD-1> show spanning-tree mstp configuration MSTP information Context identifier : 0 Region name : Region-1 Revision : 1 Configuration digest : 0x0fe915ec1bb56f8093abcd63be863ed3

MSTI Member VLANs 0 0-9,12-4094 1 10-11

Step 4.17 On your assigned EX Series switch, examine the configuration digest by issuing the command run show spanning-tree mstp configuration.


www.juniper.net


{master:0}[edit interfaces] lab@exD-1# run show spanning-tree mstp configuration MSTP information Context identifier : 0 Region name : Region-1 Revision : 1 Configuration digest : 0x5fbf3a8d0fdaaf3160c42456695ce709

MSTI Member VLANs 0 0-10,12-4094 1 11

Question: Does a configuration digest mismatch exist? Why?

Answer: Yes. The configuration digest is determined by the contents of the MSTI to VLAN ID table. In the previous outputs, VLAN 10 is located in MSTI 1 on your assigned SRX device. On your assigned EX Series switch, VLAN 10 is located in MSTI 0. Question: What can you do to fix this problem?

Answer: On your assigned EX Series switch, you can move VLAN 10 into MSTI 1. Step 4.18 Navigate to the [edit protocols mstp] hierarchy level and add VLAN 10 to MSTI 1. Activate the changes using the commit command. {master:0}[edit interfaces] lab@exD-1# top edit protocols mstp {master:0}[edit protocols mstp] lab@exD-1# set msti 1 vlan v10 {master:0}[edit protocols mstp] lab@exD-1# show configuration-name Region-1; revision-level 1; bridge-priority 4k; msti 1 { vlan [ v11 v10 ]; interface ge-0/0/12.0 { cost 50000; } www.juniper.net



interface ae0.0 { cost 500; } } {master:0}[edit protocols mstp] lab@exD-1# commit configuration check succeedscommit complete

STOP


Step 4.19 On your assigned EX Series switch, issue the command run show spanning-tree bridge. {master:0}[edit protocols mstp] lab@exD-1# run show spanning-tree bridge STP bridge parameters Context ID Enabled protocol STP bridge parameters for CIST Root ID CIST regional root CIST internal root cost Hello time Maximum age Forward delay Number of topology changes Time since last topology change Topology change initiator Topology change last recvd. from Local parameters Bridge ID Extended system ID Internal instance ID STP bridge parameters for MSTI 1 MSTI regional root Root cost Root port Hello time Maximum age Forward delay Hop count Number of topology changes Topology change initiator Topology change last recvd. from Local parameters Bridge ID

: 0 : MSTP

: : : : : : : : : :

4096.00:19:e2:51:65:80 4096.00:19:e2:51:65:80 0 2 seconds 20 seconds 15 seconds 2 176 seconds ge-0/0/10.0 00:26:88:02:6b:8a

: 4096.00:19:e2:51:65:80 : 0 : 0

: : : : : : : : : :

16385.00:26:88:02:74:90 20100 ge-0/0/10.0 2 seconds 20 seconds 15 seconds 18 1 ge-0/0/10.0 00:26:88:02:6b:8a

: 32769.00:19:e2:51:65:80


www.juniper.net


Extended system ID Internal instance ID

: 0 : 1

Step 4.20 Return to your assigned SRX device and issue the command show spanning-tree bridge. lab@srxD-1> show spanning-tree bridge STP bridge parameters Context ID Enabled protocol

: 0 : MSTP

STP bridge parameters for CIST Root ID Root cost Root port CIST regional root CIST internal root cost Hello time Maximum age Forward delay Hop count Message age Number of topology changes Time since last topology change Topology change initiator Topology change last recvd. from Local parameters Bridge ID Extended system ID Internal instance ID STP bridge parameters for MSTI 1 MSTI regional root Hello time Maximum age Forward delay Number of topology changes Topology change initiator Topology change last recvd. from Local parameters Bridge ID Extended system ID Internal instance ID

www.juniper.net

: : : : : : : : : : : : : :

4096.00:19:e2:51:65:80 0 ae1.0 4096.00:19:e2:51:65:80 30000 2 seconds 20 seconds 15 seconds 18 0 2 523 seconds ae1.0 00:19:e2:55:36:0a

: 32768.00:26:88:02:74:90 : 0 : 0

: : : : : : :

16385.00:26:88:02:74:90 2 seconds 20 seconds 15 seconds 3 ge-0/0/10.0 00:19:e2:55:36:0a

: 16385.00:26:88:02:74:90 : 0 : 1



Question: Do both of your assigned devices now show the same regional root bridge for MSTI 1?

Answer: Yes. The regional root bridge for MSTI 1 should now be the same on all devices. Note that it might take a minute or so for all devices to show the same regional root bridge. If you do not see the same regional root bridge in your environment, check the configurations and, if needed, work with your instructor. Step 4.21 On your assigned SRX device, use the ping utility to generate a constant stream of traffic between the vr10 and vr20 devices. Issue the command ping routing-instance vry0 172.23.10.10z rapid count 10000000. Note

The value of y is 1 if your assigned SRX device is SRX1. The value of y is 2 if your assigned SRX device is SRX2. The value of z is 2 if your assigned SRX device is SRX1. The value of z is 1 if your assigned SRX device is SRX2. lab@srxD-1> ping routing-instance vry0 172.23.10.10z rapid count 100000000 PING 172.23.10.102 (172.23.10.102): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ... Note

If the ping operation is not successful, work with the remote team in your pod and verify that all student devices show the same regional root bridge for MSTI 1. Do not proceed until the continuous ping operation shows success. If needed, work with your instructor. Step 4.22 Return to your assigned EX Series switch and examine the traffic flow using the run monitor interface traffic command. Press the Ctrl + d or Ctrl + u key combinations to scroll down or up. Press the q key when you are finished examining the output.


www.juniper.net


{master:0}[edit protocols mstp] lab@exD-1# run monitor interface traffic exD-1 Interface ge-0/0/0 ge-0/0/1 ge-0/0/2 ge-0/0/3 ge-0/0/4 ge-0/0/5 ge-0/0/6 ge-0/0/7 ge-0/0/8 ge-0/0/9 ge-0/0/10 ge-0/0/11 ge-0/0/12 ge-0/0/13 ge-0/0/14 ge-0/0/15 ge-0/0/16 ge-0/0/17 ge-0/0/18 ge-0/0/19 ge-0/0/20 ge-0/0/21 ge-0/0/22 ge-0/0/23 xe-0/1/0 vcp-0 vcp-1 ae0 ...

Seconds: 8 Link Down Down Down Down Down Down Up Up Up Up Up Up Up Up Up Up Down Down Down Down Down Down Down Down Down Down Down Up

Input packets 0 0 0 0 0 0 184487906 180554850 180642231 540688889 452243175 180551611 243181393 0 40 38 0 0 0 0 0 0 0 0 0 0 0 721331120

(pps) (0) (0) (0) (0) (0) (0) (500) (0) (1) (1) (501) (0) (1) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0)

(2)

Time: 22:25:36 Output packets 0 0 0 0 0 0 284776929 214511445 65408042 275489308 439989492 0 266501745 0 180529837 180433142 0 0 0 0 0 0 0 0 0 0 0 340897350

(pps) (0) (0) (0) (0) (0) (0) (501) (0) (0) (0) (501) (0) (1) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0)

(0)

Question: Which interfaces are being used for the traffic flow?

Answer: The traffic is flowing through the ge-0/0/6 and ge-0/0/10 interfaces.

www.juniper.net



Question: Do you currently have enough information to determine why the traffic is not using the ae0 interface?

Answer: No. You do not have enough information to determine why the traffic is bypassing the ae0 interface. Step 4.23 Exit the current output by pressing the q key. Examine the status of the ae0 interface by issuing the command run show interface terse | match ae0. {master:0}[edit protocols mstp] lab@exD-1# run show interfaces terse | match ae0 ge-0/0/8.0 up up aenet --> ae0.0 ge-0/0/9.0 up up aenet --> ae0.0 ae0 up up ae0.0 up up eth-switch

Question: Can you determine the problem from this output?

Answer: No. The ae0 interface and its child links appear to be functioning normally. Step 4.24 Examine the Ethernet switching table. {master:0}[edit protocols mstp] lab@exD-1# run show ethernet-switching table Ethernet-switching table: 6 entries, 4 learned VLAN MAC address Type v10 * Flood v10 00:26:88:02:6b:86 Learn v10 00:26:88:02:74:86 Learn v11 * Flood v11 00:26:88:02:6b:87 Learn v11 00:26:88:02:74:87 Learn


Age 0 0 0 0

Interfaces All-members ge-0/0/10.0 ge-0/0/6.0 All-members ge-0/0/10.0 ge-0/0/7.0

www.juniper.net


Question: What can you determine from this output?

Answer: The necessary MAC addresses have not been learned through the ae0 interface. Note that your output might vary from the sample capture provided. Step 4.25 Examine the interface statuses of MSTI 1 by issuing the command run show spanning-tree interface msti 1. {master:0}[edit protocols mstp] lab@exD-1# run show spanning-tree interface msti 1 Spanning tree interface parameters for instance 1 Interface ae0.0 ge-0/0/6.0 ge-0/0/7.0 ge-0/0/10.0 ge-0/0/12.0

Port ID 128:1 128:519 128:520 128:523 128:525

Designated port ID 128:1 128:519 128:520 128:523 128:525

Designated bridge ID 32769.0019e2516580 32769.0019e2516580 32769.0019e2516580 20481.002688026b90 32769.0019e2553600

Port Cost 500 20000 20000 20000 50000

State

Role

FWD FWD FWD FWD BLK

DESG DESG DESG ROOT ALT


Answer: The ae0 interface is participating in MSTP and appears to be able to forward traffic. Step 4.26 Examine the traffic entering and exiting the ae0 interface by issuing the command run monitor traffic interface ae0. Press the Ctrl + c key combination when you are finished. {master:0}[edit protocols mstp] lab@exD-1# run monitor traffic interface ae0 verbose output suppressed, use or for full protocol decode Address resolution is ON. Use to avoid any reverse lookup delay. Address resolution timeout is 4s. Listening on ae0, capture size 96 bytes 22:41:51.237741 Out STP 802.1s, Rapid STP[|stp 57] 22:41:53.134825 Out STP 802.1s, Rapid STP[|stp 57] 22:41:55.131739 Out STP 802.1s, Rapid STP[|stp 57] ^C www.juniper.net



3 packets received by filter 0 packets dropped by kernel


Answer: The ae0 interface is sending spanning-tree protocol packets, but it is not receiving anything. Step 4.27 Examine the traffic entering and exiting the ge-0/0/9 interface, which is a child interface of the ae0 interface. Issue the command run monitor traffic interface ge-0/0/9. Press the Ctrl + c key combination when you are finished. {master:0}[edit protocols mstp] lab@exD-1# run monitor traffic interface ge-0/0/9 verbose output suppressed, use or for full protocol decode Address resolution is ON. Use to avoid any reverse lookup delay. Address resolution timeout is 4s. Listening on ge-0/0/9, capture size 96 bytes 22:45:04.805910 In LACPv1, length 22:45:05.811845 In LACPv1, length 22:45:06.816822 In LACPv1, length 22:45:07.834618 In LACPv1, length 22:45:08.840442 In LACPv1, length ^C 6 packets received by filter 0 packets dropped by kernel

60 60 60 60 60


Answer: Link Aggregation Control Protocol (LACP) packets are being received on the ge-0/0/9 interface. Step 4.28 Examine all the interfaces that have LACP configured by issuing the command run show lacp interfaces. {master:0}[edit protocols mstp] lab@exD-1# run show lacp interfaces Aggregated interface: ae0


www.juniper.net



Answer: The ae0 interface is eligible for LACP. However, LACP is not running on the interface. Step 4.29 Configure LACP to actively attempt to configure its remote partner on the ae0 interface. Activate the change using the commit command. {master:0}[edit protocols mstp] lab@exD-1# top edit interfaces ae0 {master:0}[edit interfaces ae0] lab@exD-1# set aggregated-ether-options lacp active {master:0}[edit interfaces ae0] lab@exD-1# commit configuration check succeedscommit complete

Step 4.30 Issue the command run show lacp interfaces. {master:0}[edit interfaces ae0] lab@exD-1# run show lacp interfaces Aggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity ge-0/0/8 Actor No No Yes Yes Yes Yes Fast Active ge-0/0/8 Partner No No Yes Yes Yes Yes Fast Active ge-0/0/9 Actor No No Yes Yes Yes Yes Fast Active ge-0/0/9 Partner No No Yes Yes Yes Yes Fast Active LACP protocol: Receive State Transmit State Mux State ge-0/0/8 Current Fast periodic Collecting distributing ge-0/0/9 Current Fast periodic Collecting distributing


Answer: LACP is running on the interface and has detected its adjacent partner.

STOP

www.juniper.net




Step 4.31 On your assigned SRX device, use the ping utility to generate a constant stream of traffic between the vr10 and vr20 devices. Issue the command ping routing-instance vry0 172.23.10.10z rapid count 10000000. Note

The value of y is 1 if your assigned SRX device is SRX1. The value of y is 2 if your assigned SRX device is SRX2. The value of z is 2 if your assigned SRX device is SRX1. The value of z is 1 if your assigned SRX device is SRX2. lab@srxD-1> ping routing-instance vry0 172.23.10.10z rapid count 100000000 PING 172.23.10.102 (172.23.10.102): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ... Note

If the ping operation is not successful, you might need to wait for a moment for MSTP changes to occur on all participating devices. Do not proceed until the continuous ping operation shows success. If needed, work with your instructor. Step 4.32 Return to your assigned EX Series switch and examine the traffic flow using the run monitor interface traffic command. Press the Ctrl + d or Ctrl + u key combinations to scroll down or up. Press the q key when you are finished examining the output. {master:0}[edit interfaces ae0] lab@exD-1# run monitor interface traffic exD-1 Interface ge-0/0/0 ge-0/0/1 ge-0/0/2 ge-0/0/3 ge-0/0/4 ge-0/0/5 ge-0/0/6 ge-0/0/7 ge-0/0/8 ge-0/0/9 ge-0/0/10 ge-0/0/11 ge-0/0/12 ge-0/0/13 ge-0/0/14

Seconds: 2 Link Down Down Down Down Down Down Up Up Up Up Up Up Up Up Up

Input packets 0 0 0 0 0 0 185658052 180554952 180645859 540930270 453175891 180551611 243182421 0 40

(pps) (0) (0) (0) (0) (0) (0) (904) (0) (2) (905) (0) (0) (0) (0) (0)


Time: 23:14:57 Output packets 0 0 0 0 0 0 285947950 214513011 65410833 275729445 440922172 0 266503409 0 180529837

(pps) (0) (0) (0) (0) (0) (0) (905) (1) (2) (905) (0) (0) (1) (0) (0) www.juniper.net


ge-0/0/15 ge-0/0/16 ge-0/0/17 ge-0/0/18 ge-0/0/19 ge-0/0/20 ge-0/0/21 ge-0/0/22 ge-0/0/23 xe-0/1/0 vcp-0 vcp-1 ae0 ...

Up Down Down Down Down Down Down Down Down Down Down Down Up

38 0 0 0 0 0 0 0 0 0 0 0 721576129

(0) (0) (0) (0) (0) (0) (0) (0) (0) (0)

(907)

180433142 0 0 0 0 0 0 0 0 0 0 0 341140278

(0) (0) (0) (0) (0) (0) (0) (0) (0) (0)

(907)

Question: Which interfaces is the traffic using?

Answer: The outgoing flow of this traffic is entering the ge-0/0/6 interface and exiting the ae0 interface. You can also see traffic traversing the ge-0/0/9 interface, because it is a child interface of the ae0 interface that is in use. Question: Has the network been restored to a functioning condition?

Answer: Yes. Traffic can now flow between the VR devices and it is taking the desired path. MSTP is also functioning as expected.

Part 5: Configuring Port Mirroring and sFlow In this lab part, you will configure port mirroring and sFlow collection. You will then monitor the operation of both. Step 5.1 Configure the ge-0/0/13 interface to participate in family ethernet-switching. {master:0}[edit interfaces ae0] lab@exD-1# top edit interfaces {master:0}[edit interfaces] lab@exD-1# set ge-0/0/13 unit 0 family ethernet-switching

www.juniper.net



Step 5.2 Navigate to the [edit ethernet-switching-options] hierarchy level. Configure the analyzer monitor-vr to copy 1 out of every 5 frames that enters your assigned EX Series switch on the ge-0/0/6 interface. Then configure the monitor-vr analyzer to send these frames to the analyzer device located off the ge-0/0/13 interface. Activate the changes using the commit command. {master:0}[edit interfaces] lab@exD-1# top edit ethernet-switching-options {master:0}[edit ethernet-switching-options] lab@exD-1# edit analyzer monitor-vr {master:0}[edit ethernet-switching-options analyzer monitor-vr] lab@exD-1# set input ingress interface ge-0/0/6 {master:0}[edit ethernet-switching-options analyzer monitor-vr] lab@exD-1# set ratio 5 {master:0}[edit ethernet-switching-options analyzer monitor-vr] lab@exD-1# set output interface ge-0/0/13 {master:0}[edit ethernet-switching-options analyzer monitor-vr] lab@exD-1# show ratio 5; input { ingress { interface ge-0/0/6.0; } } output { interface { ge-0/0/13.0; } } {master:0}[edit ethernet-switching-options analyzer monitor-vr] lab@exD-1# commit configuration check succeedscommit complete

Step 5.3 Verify that the analyzer has been correctly created by issuing the command run show analyzer. {master:0}[edit ethernet-switching-options analyzer monitor-vr] lab@exD-1# run show analyzer Analyzer name : monitor-vr Output interface : ge-0/0/13.0 Mirror ratio : 5 Loss priority : Low Ingress monitored interfaces : ge-0/0/6.0


www.juniper.net


Question: Has the analyzer been configured correctly?

Answer: Yes. The analyzer has the correct output interface, the correct ingress monitored interface, and the correct mirror ratio. Step 5.4 On your assigned SRX device, use the ping utility to generate a constant stream of traffic between the vr10 and vr20 devices. Issue the command ping routing-instance vry0 172.23.10.10z rapid count 10000000. Note

The value of y is 1 if your assigned SRX device is SRX1. The value of y is 2 if your assigned SRX device is SRX2. The value of z is 2 if your assigned SRX device is SRX1. The value of z is 1 if your assigned SRX device is SRX2. lab@srxD-1> ping routing-instance vry0 172.23.10.10z rapid count 100000000 PING 172.23.10.102 (172.23.10.102): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ...

Step 5.5 Return to your assigned EX Series switch and examine the traffic flow using the run monitor interface traffic command. Press the Ctrl + d or Ctrl + u key combinations to scroll down or up. Press the q key when you are finished examining the output. {master:0}[edit protocols mstp] lab@exD-1# run monitor interface traffic exD-1 Interface ge-0/0/0 ge-0/0/1 ge-0/0/2 ge-0/0/3 ge-0/0/4 ge-0/0/5 ge-0/0/6 ge-0/0/7 ge-0/0/8 ge-0/0/9 ge-0/0/10 ge-0/0/11 www.juniper.net

Seconds: 10 Link Down Down Down Down Down Down Up Up Up Up Up Up

Input packets 0 0 0 0 0 0 187698119 180555103 180652636 542974744 453178269 180551611

(pps) (0) (0) (0) (0) (0) (0) (851) (0) (2) (852) (0) (0)

Time: 00:28:41 Output packets 0 0 0 0 0 0 287990195 214515340 65417613 277773926 440924531 0

(pps) (0) (0) (0) (0) (0) (0) (851) (1) (2) (852) (1) (0)



ge-0/0/12 ge-0/0/13 ge-0/0/14 ge-0/0/15 ge-0/0/16 ge-0/0/17 ge-0/0/18 ge-0/0/19 ge-0/0/20 ge-0/0/21 ge-0/0/22 ge-0/0/23 xe-0/1/0 vcp-0 vcp-1 ae0 ...

Up Up Up Up Down Down Down Down Down Down Down Down Down Down Down Up

243182569 38 40 0 0 0 0 0 0 0 0 0 0 0 0 723627380

(0) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0)

266505905 181582527 180529837 0 0 0 0 0 0 0 0 0 0 0 0 343191539

(854)

(1) (171) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0)

(854)

Question: Is traffic being mirrored out the ge-0/0/13 interface?

Answer: Yes. The output packet counter is incrementing for the ge-0/0/13 interface, which indicates that traffic is being mirrored out that interface.Note the input packet counter also might increase if both devices in the pod are running the ping. Step 5.6 Navigate to the [edit protocols sflow] hierarchy level. Configure the collector with the address of the local server located in your management network. Refer to the Management Network Diagram for this address. {master:0}[edit ethernet-switching-options analyzer monitor-vr] lab@exD-1# top edit protocols sflow {master:0}[edit protocols sflow] lab@exD-1# set collector n.n.n.n

Step 5.7 Enable sFlow on the child interfaces of the ae0 interface. Next, set the sFlow agent to collect interface statistics every second. Then sample every 100 frames that egress the interfaces. Note

The sFlow collection cannot be configured on an aggregate Ethernet interface. It must be configured on its child interfaces instead. Lab 6–34 • Monitoring and Troubleshooting Layer 2 Networks (Detailed)

www.juniper.net


{master:0}[edit protocols sflow] lab@exD-1# set interfaces ge-0/0/8 {master:0}[edit protocols sflow] lab@exD-1# set interfaces ge-0/0/9 {master:0}[edit protocols sflow] lab@exD-1# set polling-interval 1 {master:0}[edit protocols sflow] lab@exD-1# set sample-rate egress 100 {master:0}[edit protocols sflow] lab@exD-1# show polling-interval 1; sample-rate egress 100; collector 10.210.14.130; interfaces ge-0/0/8.0; interfaces ge-0/0/9.0; {master:0}[edit protocols sflow] lab@exD-1# commit configuration check succeedscommit complete

Step 5.8 Verify that sFlow has been configured correctly by issuing the command run show sflow. {master:0}[edit protocols lab@exD-1# run show sflow sFlow : Sample limit : Polling interval : Sample rate egress : Sample rate ingress : Agent ID : Source IP address :

sflow] Enabled 300 packets/second 1 second 1:100: Enabled 1:2048: Disabled 10.210.14.147 10.210.14.147

Question: Has the sFlow collection been configured correctly?

Answer: Yes. The interface statistics will be polled every second, 1 out of every 100 packets will be sampled, and sampling will occur on packets that egress the specified interfaces. Step 5.9 Verify the sFlow collector is working correctly by issuing the command run show sflow collector.

www.juniper.net



{master:0}[edit protocols sflow] lab@exD-1# run show sflow collector Collector Udp-port No. of samples address 10.210.14.130 6343 413

Question: Is traffic being sampled and sent to the sFlow collector?

Answer: Yes. The number of samples is incrementing. These sampled frames are then being sent to the sFlow collector. Step 5.10 Return to the sessions opened for your assigned SRX device and your assigned EX Series switch. On both of your assigned devices, enter configuration mode and load the reset configuration files by issuing the load override /var/home/lab/ajex/ reset.conf command. Activate the reset configuration files and return to operational mode using the commit and-quit command.

STOP



www.juniper.net

Advanced Junos Enterprise Switching Appendix A: Lab Diagrams


A–2 • Lab Diagrams

www.juniper.net


www.juniper.net

Lab Diagrams • A–3


A–4 • Lab Diagrams

www.juniper.net

AJEX_10.b-R_LGD

Recommend Documents