Advanced Junos Enterprise Switching: Student Guide

Advanced Junos Enterprise Switching
10.b
Student 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 Student Guide, Revision 10.b Copyright 2011 Juniper Networks, Inc. All rights reserved. Printed in USA. Revision History: Revision 10.aApril 2011 Revision 10.bJune 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
Chapter 1: Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1 Chapter 2: Advanced Ethernet Switching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1
Virtual Local Area NetworksAssigning User Traffic to VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 Virtual Local Area NetworksRestricting Traffic within a VLAN . . . . . . . . . . . . . . . . . . . . . . . .2-15 Automating VLAN Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-28 Tunneling Layer 2 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-40 Lab 1: Advanced Ethernet Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-63
Chapter 3: Advanced Spanning Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Spanning Tree Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3 Multiple Spanning Tree Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10 VLAN Spanning Tree Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-23 Lab 2: Implementing MSTP and VSTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-34
Chapter 4: Authentication and Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Authentication Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 Access Control Features: 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9 Access Control Features: MAC RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-28 Access Control Features: Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-34 Overview of Authentication Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-45 Lab 3: Authentication and Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-51
Chapter 5: Deploying IP Telephony Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 IP Telephony Features: Power over Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6 IP Telephony Features: Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15 IP Telephony Features: Voice VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-28 Case Study: Deploying IP Telephony Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-33 Lab 4: Deploying IP Telephony Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-43
Chapter 6: Class of Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1

Class of Service Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 Implementing Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-16 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-28 Lab 5: Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-37
Chapter 7: Monitoring and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

Introduction to Monitoring and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3 Monitoring and Troubleshooting Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-18 Troubleshooting Case Studies: Reachability Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-27 Troubleshooting Case Studies: Network Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-33 Lab 6: Monitoring and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-41
www.juniper.net
Contents iii
Appendix A: Acronym List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1 Appendix B: Answer Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1
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 Chapter 3: Advanced Spanning Tree Lab 2: Implementing MSTP and VSTP Chapter 4: Authentication and Access Control Lab 3: Authentication and Access Control
Day 2
Chapter 5: Deploying IP Telephony Features Lab 4: Deploying IP Telephony Features Chapter 6: Class of Service Lab 5: Class of Service Chapter 7: Monitoring and Troubleshooting Lab 6: Monitoring and Troubleshooting Layer 2 Networks
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 Franklin Gothic Courier New Description Normal text. Console text: Screen captures Noncommand-related syntax commit complete Exiting configuration mode Usage Example Most of what you read in the Lab Guide and Student Guide.
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 Normal CLI Normal GUI Description No distinguishing variant. Usage Example Physical interface:fxp0, Enabled View configuration history by clicking Configuration > History. CLI Input GUI Input Text that you must enter. lab@San_Jose> show route Select File > Save, and type config.ini in the Filename field.
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 CLI Variable GUI Variable CLI Undefined Description Text where variable value is already assigned. Text where the variables value is the users discretion or text where the variables value as shown in the lab guide might differ from the value the user must input according to the lab topology. Usage Example policy my-peers Click my-peers in the dialog. Type set policy policy-name. ping 10.0.x.y Select File > Save, and type filename in the Filename field.
GUI Undefined
www.juniper.net
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 Student 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 training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats: Go to http://www.juniper.net/techpubs/. Locate the specific software or hardware release and title you need, and choose the format in which you want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.
Juniper Networks Support

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

Chapter 1: Course Introduction
This Chapter Discusses:

Objectives and course content information; Additional Juniper Networks, Inc. courses; and The Juniper Networks Certification Program.
Chapter 12 Course Introduction
www.juniper.net
Introductions
The slide asks several questions for you to answer during class introductions.
www.juniper.net
Course Introduction Chapter 13
Course Contents
The slide lists the topics we discuss in this course.
www.juniper.net
Prerequisites
The slide lists the prerequisites for this course.
www.juniper.net
General Course Administration

The slide documents general aspects of classroom administration.
www.juniper.net
Training and Study Materials

The slide describes Education Services materials that are available for reference both in the classroom and online.
www.juniper.net
Additional Resources
The slide provides links to additional resources available to assist you in the installation, configuration, and operation of Juniper Networks products.
www.juniper.net
Satisfaction Feedback
Juniper Networks uses an electronic survey system to collect and analyze your comments and feedback. Depending on the class you are taking, please complete the survey at the end of the class, or be sure to look for an e-mail about two weeks from class completion that directs you to complete an online survey form. (Be sure to provide us with your current e-mail address.) Submitting your feedback entitles you to a certificate of class completion. We thank you in advance for taking the time to help us improve our educational offerings.
www.juniper.net
Juniper Networks Education Services Curriculum

Juniper Networks Education Services can help ensure that you have the knowledge and skills to deploy and maintain cost-effective, high-performance networks for both enterprise and service provider environments. We have expert training staff with deep technical and industry knowledge, providing you with instructor-led hands-on courses in the classroom and online, as well as convenient, self-paced eLearning courses.
Course List
You can access the latest Education Services offerings covering a wide range of platforms at http://www.juniper.net/training/technical_education/.
www.juniper.net
Juniper Networks Certification Program

A Juniper Networks certification is the benchmark of skills and competence on Juniper Networks technologies.
www.juniper.net
Juniper Networks Certification Program Overview

The Juniper Networks Certification Program (JNCP) consists of platform-specific, multitiered tracks that enable participants to demonstrate competence with Juniper Networks technology through a combination of written proficiency exams and hands-on configuration and troubleshooting exams. Successful candidates demonstrate thorough understanding of Internet and security technologies and Juniper Networks platform configuration and troubleshooting skills. The JNCP offers the following features: Multiple tracks; Multiple certification levels; Written proficiency exams; and Hands-on configuration and troubleshooting exams.
Each JNCP track has one to four certification levelsAssociate-level, Specialist-level, Professional-level, and Expert-level. Associate-level and Specialist-level exams are computer-based exams composed of multiple choice questions administered at Prometric testing centers worldwide. Professional-level and Expert-level exams are composed of hands-on lab exercises administered at select Juniper Networks testing centers. Professional-level and Expert-level exams require that you first obtain the next lower certification in the track. Please visit the JNCP Web site at http://www.juniper.net/certification for detailed exam information, exam pricing, and exam registration. Chapter 112 Course Introduction www.juniper.net
Preparing and Studying

The slide lists some options for those interested in preparing for Juniper Networks certification.
www.juniper.net
Find Us Online
The slide lists some online resources to learn and share information about Juniper Networks.
www.juniper.net
Any Questions?
If you have any questions or concerns about the class you are attending, we suggest that you voice them now so that your instructor can best address your needs during class. This chapter contains no review questions.
www.juniper.net
www.juniper.net

Chapter 2: Advanced Ethernet Switching

Implementation of filter-based virtual LAN (VLAN) assignments; Restricting traffic flows within a VLAN; Management of dynamic VLAN registration; and Tunneling Layer 2 traffic through Ethernet networks.
Chapter 22 Advanced Ethernet Switching
www.juniper.net
Virtual Local Area NetworksAssigning User Traffic to VLANs

The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
www.juniper.net
Advanced Ethernet Switching Chapter 23
Default Designations
The factory-default configuration associates all installed interfaces with the default VLAN. In this sample output shown on the slide we can see that the default VLAN does not use an 802.1Q tag. Because all installed interfaces are pre-configured for Layer 2 operations and are associated with the default VLAN, you can simply insert an EX Series switch in basic single-broadcast domain environments without much or any configuration. If a switch supports multiple broadcast domains, you might want to define additional VLANs to separate the traffic associated with each subnet at Layer 2. Continued on the next page.
www.juniper.net
Default Designation (contd.)

You can assign an 802.1Q tag with the default VLAN as shown in the following output: [edit] root# set vlans default vlan-id 100 [edit] root# commit and-quit configuration check succeedscommit complete Exiting configuration mode root> show vlans Name Tag default 100
Interfaces ge-0/0/0.0, ge-0/0/1.0, ge-0/0/2.0, ge-0/0/3.0, ge-0/0/4.0, ge-0/0/5.0, ge-0/0/6.0*, ge-0/0/7.0*, ge-0/0/8.0*, ge-0/0/9.0*, ge-0/0/10.0*, ge-0/0/11.0*, ge-0/0/12.0*, ge-0/0/13.0*, ge-0/0/14.0*, ge-0/0/15.0*, ge-0/0/16.0, ge-0/0/17.0, ge-0/0/18.0, ge-0/0/19.0, ge-0/0/20.0, ge-0/0/21.0, ge-0/0/22.0, ge-0/0/23.0, xe-0/1/0.0
www.juniper.net
Changing Default Designations

You can easily change the default VLAN designations by adding new VLANs and associating interfaces with those user-defined VLANs. You can also create trunk ports which are used to service one or more VLANs. We review the key attributes of access and trunk ports on a subsequent slide.
www.juniper.net
Access and Trunk Ports

This slide is designed as a review of the key attributes of access and trunk ports. The tables associated with the two port modes provide the key characteristics of each and highlight the differences between the two types.
www.juniper.net
Port-Based VLAN Assignments

In the Junos Enterprise Switching course we introduced you to the port-based VLAN assignment method. Using the port-based VLAN assignment method, you associate ports with user-defined VLANs. Typically, access ports are associated with a single VLAN whereas trunk ports are often associated with multiple VLANs. The slide provides a basic configuration example that associates access and trunk ports with their respective VLANs. Note that in this example vlan-10 and vlan-20 are associated with the 172.23.10.0/24 and 172.23.20.0/24 subnets respectively.
www.juniper.net
Test Your Knowledge

This slide is designed to test the learners understanding based on the scenario and configuration provided. Based on the configuration, all traffic received through the ge-0/0/6.0 interface, regardless of its associated subnet, will be tagged with VLAN-ID 10 and flooded out interfaces associated with the vlan-10 VLAN. The end result is that all traffic sourced from Host-B will be associated with vlan-10 and forwarded or flooded on to nodes that are also associated with vlan-10. It is important to note that although VLANs are typically associated with a single subnet, this is not a strict requirement. In other words, you can have multiple subnets associated with a single VLAN.
www.juniper.net
Filter-Based VLAN Assignment

Using the port-based VLAN assignment method, all traffic received through an access port is associated with the VLAN assigned to that access port. This approach is all-encompassing and provides no evaluation of source subnet information. The filter-based VLAN assignment method provides flexibility by evaluating information, such as the source IP address, and making VLAN assignments based on evaluation results. The filter-based VLAN assignment method uses firewall filters to aid in the evaluation and assignment process. This feature might be used in scenarios that include multiple devices attached to a single switch port through an attached hub or passive switch, as shown on the slide.
www.juniper.net
Implementing Filter-Based VLAN Assignments

This slide provides a basic overview of how filter-based VLAN assignments are implemented. We cover each of the highlighted steps in more detail on subsequent slides. Note that filter-based VLAN assignments are not supported on access ports that are configured for 802.1X. If both features are configured at the same time, the configuration will not commit as shown in the following output: [edit protocols dot1x] user@switch# commit error: Dot1x: Authenticator can't be configured on mapping "policy" enabled interface <ge-0/0/6.0> error: configuration check-out failed
www.juniper.net
Defining and Applying the Firewall Filter

The first two steps when implementing filter-based VLAN assignments are to define and apply a Layer 2 firewall filter. Note that Layer 2 filters are associated with the ethernet-switching protocol family. In the example shown on the slide, we define a Layer 2 firewall filter that matches on the source IP subnet 172.23.20.0/24 and associates matching traffic with the VLAN named vlan-20 using the then vlan statement. Because the default action for all traffic not explicitly accepted is discard, we include a second term that accepts all other traffic. The else-accept term not only allows the switch to accept all other traffic but by doing so also allows the switch to associate all other traffic with VLAN vlan-10, which is the port-based VLAN assignment for the ge-0/0/6.0 access port. Note that the slide also shows the application of the vlan-assign firewall filter. In this case the vlan-assign firewall filter is applied as an input filter to the ge-0/0/6.0 access port.
www.juniper.net
Associating Access Port with Secondary VLAN

The third step when implementing filter-based VLAN assignments is to associate the access port, ge-0/0/6.0 in our example, with the secondary VLAN (vlan-20). Because the matching criteria defined in the firewall filter (illustrated on the previous slide) must be met, this secondary VLAN association for the ge-0/0/6.0 access port is conditional in nature. To form a conditional association between an access port and a secondary VLAN, you use the mapping policy statement, as shown in the example on the slide.
www.juniper.net
Monitoring the Results

Here we can see that the ge-0/0/6.0 access port is now associated with vlan-10 and vlan-20. Note the unique Mapping policy interfaces association ge-0/0/6.0 has with vlan-20. This unique association is indicative of a filter-based VLAN assignment, which, as previously stated, is conditional in nature. Based on the current configuration and associations, if traffic enters ge-0/0/6.0 and matches the defined conditions in the firewall filter, then that traffic should be associated with vlan-20. All other traffic should be associated with vlan-10. Once traffic passes through ge-0/0/6.0, the switch will add the related media access control (MAC) addresses to the corresponding VLAN in the bridge table. If no MAC entry exists in the bridge table, the switch uses the flood entry assigned to each VLAN to facilitate the required communications. The following output shows the bridge table assignments for ge-0/0/6.0: user@AS-2> show ethernet-switching table interface ge-0/0/6 Ethernet-switching table: 0 unicast entries VLAN MAC address Type Age Interfaces vlan-10 * Flood - All-members vlan-20 * Flood - All-members
www.juniper.net
Virtual Local Area NetworksRestricting Traffic within a VLAN

The slide highlights the topic we discuss next.
www.juniper.net
Typical VLAN Deployments

Although not strictly required, a common VLAN deployment involves a one-to-one mapping between a VLAN and a corresponding broadcast domain. This deployment design results in end-to-end communications between all devices participating in the same VLAN.
www.juniper.net
Restricting Traffic
In some situations you might want to sub-divide groups within the same broadcast domain and restrict communications between the different groups. For example, you might have a single subnet on which multiple workgroups participate, such as the Sales and Finance workgroups, and want to restrict direct communications between those workgroups. A primary reason for restricting communications between workgroups in the same broadcast domain is to increase network security.
www.juniper.net
Private VLAN
The Private VLAN (PVLAN) feature allows you to split a broadcast domain into multiple isolated broadcast subdomains, essentially putting a VLAN inside a VLAN. A PVLAN consists of a primary VLAN with other VLANs, called secondary VLANs, nested inside. PVLANs are useful for restricting the flow of broadcast and unknown unicast traffic and for limiting the communication between known hosts. A PVLAN can be configured on a single switch or can be configured to span multiple switches. A PVLAN can span different models of EX Series switches. Note that the PVLAN feature is not supported on all EX Series switches. Refer to the technical publications for a list of switches that support this feature. The voice VLAN and PVLAN features cannot both be enabled at the same time on the same interface. We discuss the voice VLAN feature in detail in a subsequent chapter.
www.juniper.net
Primary VLAN
The primary VLAN is the main VLAN within a configured PVLAN, and other VLANs are nested inside that VLAN as secondary VLANs. The primary VLAN must be associated with an 802.1Q tag regardless of whether the PVLAN is configured on a single switch or is configured to span multiple switches. The primary VLAN is used to forward frames downstream to all secondary VLANs (isolated and community VLANs).
Secondary VLANs
Secondary VLANs are nested inside the primary VLAN. Secondary VLANs require 802.1Q tags only when a PVLAN spans multiple switches. The types of secondary VLANs supported on EX Series switches along with a brief description of each follows: Community VLAN: A secondary VLAN that transports frames among interfaces within the same community and forwards frames upstream to the primary VLAN. Isolated VLAN: A secondary VLAN that receives packets only from the primary VLAN and forwards frames upstream to the primary VLAN. Isolated VLANs can be used when a PVLAN is configured on one switch or spans multiple switches in a PVLAN domain. Inter-switch isolated VLAN: A secondary (internal) VLAN that is used to forward isolated VLAN traffic from one switch to another through pvlan-trunk ports. We discuss pvlan-trunk ports on a later slide. Inter-switch isolated VLANs are used when a PVLAN spans multiple switches. Advanced Ethernet Switching Chapter 219
www.juniper.net
PVLAN Port Designations: Part 1

This slide illustrates and describes some of the PVLAN port designations. We illustrate and describe the remainder of the port designations on the next slide.
www.juniper.net
PVLAN Port Designations: Part 2

This slide illustrates and describes the remainder of the PVLAN port designations.
www.juniper.net
Test Your Knowledge

This slide is designed to test your understanding of PVLAN port accessibility. Remember that only promiscuous ports (or traffic that has entered the PVLAN domain from a promiscuous port) can access isolated ports. Because of this rule, only R1 can access the file server in the isolated VLAN.
www.juniper.net
Case Study: Topology and Objectives

The slide displays the topology and objectives for our case study.
www.juniper.net
Configuring PVLANs: Part 1

This slide shows a portion of the required PVLAN configuration for our case study. Here we illustrate the configuration associated with the primary VLAN, named pvlan-100. Note that the configuration associated with the isolation VLAN is defined within the primary VLAN. All access ports (ge-0/0/8.0 on AS-1 in our example) defined within the primary VLAN are considered isolation ports and are associated with the isolation VLAN-ID. In our example the VLAN-ID associated with the primary VLAN is 100 while the VLAN-ID associated with the isolation VLAN is 30. The isolation VLAN-ID is configured under the primary VLAN using the isolation-id <VLAN-ID> command option. Remember that a VLAN-ID is not always necessary when implementing a PVLAN. Because this PVLAN spans multiple switches (AS-1 and AS-2) the inclusion of the isolation-id statement is required.
www.juniper.net
Configuring PVLANs: Part 2

This slide shows the remainder of the required PVLAN configuration for our case study. Here we illustrate the configuration associated with the community VLANs, named sales and finance. Note that there are no trunk ports referenced within the community VLAN configuration. All pvlan-trunk or promiscuous trunk ports are associated with community VLANs through the linking of the primary and community VLANs. Primary and community VLANs are linked through the primary-vlan <vlan-name> statement as shown on the slide. Note that ge-0/0/6.0 and ge-0/0/7.0 are both configured as access ports. Note that isolation and community VLANs do not require a VLAN-ID unless the PVLAN spans multiple switches. Because the PVLAN spans multiple switches, the inclusion of the VLAN-IDs 10 and 20, for the sales and finance community VLANs respectively, is required.
www.juniper.net
Monitoring PVLANs: Part 1

This slide and the next illustrate the basics of monitoring the PVLAN feature. This slide illustrates the show vlans command which is helpful in determining port-to-VLAN associations. Note that all configured pvlan and promiscuous trunk ports should be associated with all secondary VLANs. The slide shows the expected output on AS-1. The expected output for AS-2 follows: user@AS-2> show vlans Name Tag Interfaces __pvlan_pvlan-100_isiv__ 30 ge-0/0/10.0*, ge-0/0/12.0* default None finance 20 ge-0/0/7.0*, ge-0/0/10.0*, ge-0/0/12.0* pvlan-100 100 ge-0/0/6.0*, ge-0/0/7.0*, ge-0/0/10.0*, ge-0/0/12.0* sales 10 ge-0/0/6.0*, ge-0/0/10.0*, ge-0/0/12.0*
www.juniper.net
Monitoring PVLANs: Part 2

This slide illustrates the show vlans extensive command which provides additional details related to the PVLAN feature. In the sample output on the slide, we see details related to PVLANs which indicate that the configured PVLAN spans multiple switches.
www.juniper.net
Automating VLAN Administration

www.juniper.net
Test Your Knowledge: Part 1

This slide and the next are designed to test your understanding of basic bridging operations in an environment with multiple VLANs. As the slide indicates, all switches are configured to support all VLANs on their respective trunk ports (the ports interconnecting the switches). Because of this configuration, all broadcast and unknown unicast traffic sourced and destined within a given VLAN should be flooded throughout the entire Layer 2 network passing through all access and distribution switches.
www.juniper.net

The scenario illustrated in this slide builds on the details covered on the previous slide. In this example, the end-user device named Host-I, which is connected to the AS-3 switch, is no longer active (meaning that AS-3 no longer has any active access ports for VLAN 10). Even though AS-3 no longer has active end-user devices participating in VLAN 10, it will still receive all broadcast and unknown unicast traffic associated with VLAN 10 because of the current configurations on the connected switches. In order to stop this unwanted traffic from being flooded on to AS-3, you must modify the configurations on the connected distribution switches (DS-1 and DS-2) so that their trunk ports, which connect to AS-3, no longer service VLAN 10.
www.juniper.net
Introducing MVRP
To simplify VLAN management you can enable Multiple VLAN Registration Protocol (MVRP) on your EX Series Ethernet Switches. MVRP dynamically manages VLAN registration in a LAN. MVRP helps reduce administration and network overhead by dynamically pruning VLAN information when a switch no longer has active access ports for a configured VLAN. In addition to the pruning functionality, MVRP can also be used to dynamically create VLANs in switching networks. MVRP is an application protocol of the Multiple Registration Protocol (MRP) and is defined in the IEEE 802.1ak standard. MRP and MVRP were designed by Institute of Electrical and Electronics Engineers (IEEE) to perform the same functions as Generic Attribute Registration Protocol (GARP) and GARP VLAN Registration Protocol (GVRP). MRP and MVRP overcome some GARP and GVRP limitations, in particular limitations involving bandwidth usage and convergence time in large networks with large numbers of VLANs. MVRP was created by IEEE as a replacement application for GVRP. EX Series switches support MVRP and GVRP; however, MVRP and GVRP cannot be enabled at the same time to share VLAN information. We do not cover GVRP in this course.
www.juniper.net
Exchanging VLAN Membership Information

MVRP uses protocol data units (PDUs) to send VLAN registration information which includes the current VLAN membership details of the sending switch. The VLAN membership information is used to communicate which switches are members of which VLANs and which switch interfaces are in which VLAN. MVRP shares all information in the PDU with all switches participating in MVRP in the switching network. MVRP stays synchronized using these PDUs. The MVRP PDUs are sent to other switches on the network only when an MVRP state change occurs. Switches participating in MVRP receive these PDUs during state changes and update their MVRP states accordingly. MVRP timers dictate when PDUs can be sent and when switches receiving MVRP PDUs can update their MVRP information. MVRP registration and updates are controlled by timers that are part of the MRP protocol. These timers are set on a per-interface basis and define when MVRP PDUs can be sent and when MVRP information can be updated on a switch. The following timers are used to control MVRP operations: Join: Controls the interval for the next MVRP PDU transmit opportunity. Leave: Controls the period of time that an interface on the switch waits in the Leave state before changing to the unregistered state. LeaveAll: Controls the frequency with which the interface generates LeaveAll messages.
Continued on the next page.
www.juniper.net
Exchanging VLAN Membership Information (Contd.)

VLAN information is distributed as part of the MVRP message exchange process and can be used to dynamically create VLANs, which are VLANs created on one switch and propagated to other switches as part of the MVRP message exchange process. Dynamic VLAN creation using MVRP is enabled by default but can be disabled. MVRP uses MRP messages to register and declare MVRP states for a switch and to inform the switching network of state changes. These messages are included in the PDUs and communicate state information to the other switches in the network. The following messages are communicated for MVRP: Empty: VLAN information is not being declared and is not registered. In: VLAN information is not being declared but is registered. JoinEmpty: VLAN information is being declared but not registered. JoinIn: VLAN information is being declared and is registered. Leave: VLAN information that was previously registered is being withdrawn. LeaveAll: All registrations will be de-registered. Participants that want to participate in MVRP will need to re-register. New: VLAN information is new and possibly not previously registered.
To ensure VLAN membership information is current, MVRP uses the MRP messages to remove switches and interfaces that are no longer available from the VLAN information. Pruning VLAN information limits the network VLAN configuration to active participants only, reducing network overhead. Pruning VLAN information also targets the scope of broadcast, unicast with unknown destination, and multicast (BUM) traffic to interested devices only. MVRP is disabled by default on all EX Series switches. You can configure MVRP on EX Series switch interfaces to participate in MVRP for the switching network. MVRP can only be enabled on trunk interfaces, and dynamic VLAN configuration through MVRP is enabled by default when MVRP is enabled. We cover MVRP configuration on a subsequent slide. Note that MVRP does not support all spanning tree protocols. Currently, MVRP does not support the VLAN Spanning Tree Protocol (VSTP).
www.juniper.net
A Starting Point
When implementing MVRP, you should ensure that all required VLANs are configured on the access switches and that the access ports are associated with their respective VLANs. We illustrate a basic starting point configuration for the AS-1 switch on the slide. Note that the sample configuration is trimmed for brevity and that the AS-2 switch requires a similar configuration. Also worth noting is that none of the trunk ports, on any of the participating switches, should be associated with the configured VLANs. The trunk ports must still be configured under the [edit interfaces] hierarchy level as trunk ports but they will not be manually associated with VLANs. MVRP will make the needed associations once it is enabled.
www.juniper.net
Enabling MVRP
This slide illustrates the required configuration used to enable MVRP. Note that MVRP is only enabled on the trunk ports of all participating switches. Once MVRP is enabled, dynamic VLAN configuration information will be shared and created on participating switches. You can disable dynamic VLAN configuration using the no-dynamic-vlan statement as shown below: [edit protocols] user@AS-1# show mvrp { no-dynamic-vlan; interface ge-0/0/14.0; } Continued on the next page.
www.juniper.net
Enabling MVRP (Contd.)

Remember that MVRP registration and updates are controlled by timers, which are part of MRP. These timers are set on a per-interface basis and define when MVRP PDUs can be sent and when MVRP information can be updated. If needed, you can adjust the timers as shown below: [edit protocols] user@AS-1# set mvrp interface ge-0/0/14.0 ? Possible completions: <[Enter]> Execute this command + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups disable Disable MVRP on this interface join-timer Join timer interval (200..4294967295 milliseconds) leave-timer Leave timer interval (600..4294967295 milliseconds) leaveall-timer LeaveAll timer interval (10000..4294967295 milliseconds) registration Registration mode | Pipe through a command The default MVRP timer values are 200 ms for the join timer, 1000 ms for the leave timer, and 10000 ms for the leaveall timer. Unless there is a compelling reason to make a change, we recommend you use the default timer settings. Modifying timers to inappropriate values might cause an imbalance in MVRP operations.
www.juniper.net
Monitoring MVRP: Part 1

This and the next two slides highlight some key monitoring commands used when verifying MVRP operations. This slide illustrates the use of the show mvrp command, which is used to monitor MVRP status along with message and timer information on a per interfaces basis.
www.juniper.net

This slide illustrates the show mvrp dynamic-vlan-memberships and the show vlans commands, which are used to view dynamic VLAN membership information.
www.juniper.net

This slide illustrates the show mvrp statistics command, which is used to view MVRP statistics on a per interface basis.
www.juniper.net
Tunneling Layer 2 Traffic

www.juniper.net
Todays Connectivity Requirements

IEEE 802.1Q VLAN tagging makes it possible for a customers bridged network to scale. Instead of needing to add more bridging equipment to a growing network, VLAN tagging allows for the logical separation of a bridged network into many broadcast domains (or VLANs). With a 12-bit length VLAN ID, 4094 VLANs are available for use on a single physical Ethernet network. Because of its simple nature, service provider customers generally understand Ethernet. For a long time, service providers have searched for ways to deliver Ethernet virtual connections (EVCs) to the customer premises. To a customer, an EVC between two sites should appear as a simple Ethernet link or VLAN through the service providers network. IEEE 802.1Q VLAN tagging does not provide the scalability service providers' require to deliver that type of service. Continued on next page.
www.juniper.net
Todays Connectivity Requirements (Contd.)

From the service providers point of view, the following is a list of some of the scaling issues that might arise: Because only one VLAN tag field exists in an 802.1Q frame, customers and the service provider need to coordinate the use of VLAN ID space. Considering that a service provider might have thousands of customers, this coordination would be an overly extreme effort. To pass Ethernet frames between customer sites, the service provider bridges must learn customer MAC addresses. Maintaining a bridge table for internal MAC addresses as well as the MAC addresses of each customer can be a daunting task for some bridges and might be too much to handle. To provide redundant links between customers and the service provider, running a form of the Spanning Tree Protocol (STP), which is generally not a viable solution, might be necessary. The STPs of today cannot scale to support all service provider and customer bridges of the world in a single spanning-tree domain.
www.juniper.net
Addressing the Challenges

Q-in-Q tunneling is defined under IEEE 802.1ad. It was developed to allow a service provider to provide a more scalable EVC service to its customers. IEEE 802.1ad has standardized the methodology of stacking VLAN tags. The slide shows the frame format that the standard introduced. The standard gives a new name to the 802.1Q VLAN tag: the Customer VLAN (C-VLAN) tag (C-TAG) . It also introduces a new tag named the Service VLAN (S-VLAN) tag (S-TAG). By adding the S-TAG to the frame, much less coordination is necessary between the customer and the service provider. At the customer site, the customer can continue to use 802.1Q tagging using C-VLAN IDs that are relevant only to their network (not the service providers network). As 802.1Q-tagged frames arrive at the edge of the service providers bridged network, the provider edge bridge adds an S-TAG to the frame. The S-TAG, using a single S-VLAN ID, can carry any or all of the 4094 C-VLANs that are possibly in use by the customer. A typical provider bridged network using Q-in-Q tunneling provides for C-VLAN tagging and forwarding at the edge of the network using the ports that face the customer. For all ports that face the core of the provider bridged network, the provider bridges forward based only on the S-VLAN tag. In the simplest case, a service provider can allocate a single S-VLAN ID to represent each of its individual customers, which allows the service provider to potentially support up to 4094 customers. IEEE 802.1ad also allows for the translating of S-VLAN IDs at the edge of a service providers bridged network, which helps in the coordination of VLAN ID usage between service providers. Continued on next page.
www.juniper.net
Addressing the Challenges (Contd.)

Although IEEE 802.1ad helps to solve the issue of the limited VLAN ID space that we discussed in relation to IEEE 802.1Q tagging, it does not solve the MAC learning problem. That is, for frames to be forwarded between bridges in the service providers network, the bridges each must learn and store MAC addresses learned from the customer networks. A service provider can help alleviate this problem by limiting the number of learned MAC addresses or charging the customer more for the EVC service if they exceed the MAC address limit.
www.juniper.net
IEEE 802.1ad TAG Formats

The slide shows the S-TAG and C-TAG formats defined under IEEE 802.1ad. Note that the C-TAG remains identical to the IEEE 802.1Q VLAN tag. The S-TAG is similar but a few fields have been redefined. For example, because the Canonical Format Indicator (CFI) field in the C-TAG is rarely used (for use in token ring networks), it has been redefined in the S-TAG to represent a frames eligibility to be dropped. The Drop Eligibility Indicator (DEI) is used for class of service. Also, IEEE 802.1ad has reserved a Tag Protocol Identifier (TPID) of 0x88A8 for the S-TAG.
www.juniper.net
Key Terminology for Provider Bridged Networks

The following terms are used in a provider bridged network: Provider Bridged Network: A network of provider bridges that provide transparent EVC service to the service providers customers. Provider Bridge: A bridge in the service providers network that performs IEEE 802.1ad VLAN tagging and forwarding. These bridges learn and store the MAC addresses of the service providers customers. Provider Edge Bridge: Accepts and forwards IEEE 802.1Q frames to and from customers. These bridges also encapsulate the received customer frames using the IEEE 802.1ad format to forward customer frames across the provider bridged network. S-VLAN Bridge: A nonedge provider bridge that forwards frames based only on the S-VLAN tag. Customer Edge Port: A port on a provider edge bridge that connects to customer equipment and receives and transmits C-VLAN tagged frames. These are access ports. Provider Network Port: A port on a provider edge bridge that receives and transmits S-VLAN tagged frames. These are trunk ports.
www.juniper.net
Frame Processing Example: Part 1

In the example, the service provider delivers an Ethernet circuit to each of the customer premises. To provide connectivity between Customer Bridge 1 and Customer Bridge 2, the customer must enable an IEEE 802.1Q VLAN using VLAN ID 100 on the service provider-facing ports. The service provider has allocated an S-VLAN tag of 200 to transparently forward the customers frames across its network. We evaluate the required configuration, from the service providers perspective, on a subsequent slide. Over the next several slides we look at the frame processing steps for traffic traversing a Q-in-Q tunnel.
www.juniper.net

When C-VLAN-tagged frames arrive at Bridge A, Bridge A performs a MAC-table lookup based on the customers assigned VLAN (VLAN-ID 200). If Bridge A has previously learned the destination MAC address of the frame, it forwards the frame to the appropriate outbound interface (ge-0/0/10.0 in this case) and adds the outer S-VLAN tag of 200 on to the frame before sending the frame to the next bridge. The act of adding an outer tag to the frame is known as a push operation. Note that if Bridge A did not previously learn the destination MAC address of the frames, it floods the frame out of every other interface associated with the VLAN assigned to the customer except for the interface on which the frame was originally received.
www.juniper.net

When S-VLAN-tagged frames arrive at Bridge C (an S-VLAN bridge), Bridge C performs a MAC-table lookup based on the VLAN associated with the customer (VLAN-ID 200). If Bridge C has previously learned the destination MAC address of the frame, it forwards the frame to the appropriate outbound interface (ge-0/0/16.0 in this case) and the interface sends the frame unchanged to the next bridge.
www.juniper.net

When S-VLAN-tagged frames arrive at Bridge D, Bridge D pops the S-VLAN tag and performs a MAC-table lookup based on the C-VLAN tag. If Bridge D has previously learned the destination MAC address of the frame, it forwards the frame to the appropriate outbound interface (ge-0/0/0.0 in this case) and the interface sends the C-tagged frame to the attached customer bridge.
www.juniper.net

The slide shows the frame format of the Ethernet frame as it arrives at Customer Bridge 2. Note that the frame looks exactly as it did when Customer Bridge 1 transmitted it. At this point, Customer Bridge 2 will perform its own MAC-table lookup and forward the frame on to their intended destination, if known. If the destination MAC address is unknown, Customer Bridge 2 will flood frame out all other interfaces associated with VLAN-ID 100.
www.juniper.net
Configuring Q-in-Q Tunneling

This slide illustrates a basic Q-in-Q tunneling configuration for EX Series Switches. Depending on your requirements, you can map C-VLANs to an S-VLAN in three different ways. You can use the all-in-one bundling approach which takes all traffic from all access interfaces and maps that traffic to the defined S-VLAN regardless of the C-VLAN tag. This configuration method is shown on the slide. The second method you can use is the many-to-one bundling approach which maps only the defined C-VLAN tags to the configured S-VLAN. You use the customer-vlans option to specify which C-VLANs are mapped to the S-VLAN as shown in the configuration example below: [edit vlans] user@Bridge-A# show v200 { vlan-id 200; interface { ge-0/0/0.0; ge-0/0/10.0; } dot1q-tunneling { customer-vlans [ 100 160 ]; } } Continued on the next page. Chapter 252 Advanced Ethernet Switching www.juniper.net
Configuring Q-in-Q Tunneling (Contd.)

The third mapping option allows you to assign an S-VLAN to a specific C-VLAN on an interface. This method uses the mapping option, which is referenced with the incoming interface. This mapping approach uses two options for the treatment of traffic: push and swap. When traffic, mapped to a specific interface, is pushed, the traffic retains its tag as it moves between the C-VLAN and S-VLAN and an additional VLAN tag is added to the frame. When traffic mapped to a specific interface is swapped, the incoming tag is replaced with a new VLAN tag. Using the swap option is also referred to as VLAN ID translation. A basic configuration example, is provided below: [edit vlans] user@Bridge-A# show v200 { vlan-id 200; interface { ge-0/0/10.0; ge-0/0/13.0 { mapping { 100 { push; } } } } dot1q-tunneling; } In the illustrated configuration example, traffic with a C-VLAN tag of 100 entering ge-0/0/13.0, which is a customer-facing access interface, will receive an outer tag (S-VLAN tag) of 200. If traffic with any other VLAN-ID enters the ge-0/0/13.0 interface, no such mapping will take effect. If you configure multiple mapping methods, the switch gives priority to the interface-specific mapping method, then to the many-to-one bundling method, and last to the all-in-one bundling method. Note that while you can configure multiple mapping methods, you cannot have overlapping rules for the same C-VLAN under a given approach. Note that Q-in-Q tunneling does not support most access port security features. There is no per-VLAN (customer) policing or per-VLAN (outgoing) shaping and limiting with Q-in-Q tunneling unless you configure these security features using firewall filters. For more information, refer to the technical publications for your specific product. If Q-in-Q tunneling is configured, you will need to enable Q-in-Q tunneling on all VLANs serviced by the trunk ports or alternatively change the Ethernet-type setting as shown in the following sample output: [edit] user@switch# commit error: Trunk interface <ge-0/0/10.0> can not be member of both dot1q-tunneling enabled vlan <cust-1>, and a non dot1q-tunneled vlan <v11> when dot1q-tunneling ethernet-type is not <0x8100> error: configuration check-out failed [edit] user@switch# set ethernet-switching-options dot1q-tunneling ether-type 0x8100 [edit] user@switch# commit configuration check succeedscommit complete
www.juniper.net
Monitoring Q-in-Q Tunneling

As shown on the slide, you can use the show vlans and show ethernet-switching interfaces commands to verify Q-in-Q tunneling.
www.juniper.net
Tunneling Layer 2 Protocols

While Q-in-Q tunneling does tunnel Layer 2 traffic across a provider bridged network, it does not, by itself, effectively tunnel Layer 2 protocol traffic. Layer 2 protocol tunneling (L2PT) allows you to send Layer 2 PDUs across a service provider network and between customer edge switches connected through a service provider network. L2PT is useful when you want to run Layer 2 protocols on a network that includes switches located at remote sites that are connected across a service provider network. L2PT encapsulates Layer 2 PDUs, tunneling them across a service provider network, and decapsulates them for delivery to their destination switches. L2PT encapsulates Layer 2 PDUs by enabling the ingress provider edge bridge to rewrite the PDUs destination MAC addresses before forwarding them onto the service provider network. The provider bridges treat the encapsulated PDUs as multicast Ethernet packets. Upon receipt of the PDUs, the egress provider edge bridge decapsulates them by replacing the destination MAC addresses with the address of the Layer 2 protocol that is being tunneled before forwarding the PDUs to their destination customer edge switch. Continued on the next page.
www.juniper.net
Tunneling Layer 2 Protocols (Contd.)

EX Series implementation of L2PT supports the following Layer 2 protocols: 802.1X authentication 802.3ah Operation, Administration, and Maintenance (OAM) link fault management (LFM) Cisco Discovery Protocol (CDP) Ethernet local management interface (E-LMI) GVRP Link Aggregation Control Protocol (LACP) Link Layer Discovery Protocol (LLDP) Multiple MAC Registration Protocol (MMRP) MVRP Spanning Tree Protocol (STP), Rapid Spanning Tree Protocol (RSTP), and Multiple Spanning Tree Protocol (MSTP) Unidirectional Link Detection (UDLD) VLAN Spanning Tree Protocol (VSTP) VLAN Trunking Protocol (VTP).
www.juniper.net
Configuring L2PT: Part 1

L2PT is configured under the [edit vlans vlan-name dot1q-tunneling] hierarchy. This means Q-in-Q tunneling must also be enabled when implementing L2PT. When you enable L2PT on a VLAN, any specified Layer 2 protocols are disabled on the access ports, which are considered customer-facing. Access interfaces in an L2PT-enabled VLAN should not receive L2PT-tunneled PDUs. If L2PT PDUs are received on an access interface, the switch reacts as if there is a loop between the service provider network and the customer network and shuts down (disables) the access interface. As previously mentioned and illustrated on the slide, L2PT supports several Layer 2 protocols. Note that some of these protocols, when enabled, have special considerations and caveats. Some of these considerations and caveats are listed below: If you enable L2PT for untagged OAM LFM packets, do not configure LFM on the corresponding access interface. If you enable L2PT for untagged LACP packets, do not configure LACP on the corresponding access interface. CDP, UDLD, and VTP cannot be configured on EX Series switches. L2PT does, however, tunnel CDP, UDLD, and VTP PDUs. You cannot configure L2PT and VLAN translation (using the mapping statement) on the same VLAN. You can, however, configure L2PT on one VLAN and VLAN translation on a different VLAN that does not have L2PT enabled. Advanced Ethernet Switching Chapter 257
www.juniper.net
Configuring L2PT: Part 2

If the tunneled Layer 2 PDUs arrive at a high rate, your network might be experiencing a problem. In this situation, you would likely want the interface receiving the high rate of tunneled Layer 2 PDUs to shut down so the problem can be isolated. If you do not want to completely shut down the interface, you can configure the switch to drop tunneled Layer 2 PDUs that exceed a certain threshold. The drop-threshold configuration statement allows you to specify the maximum number of Layer 2 PDUs of the specified protocol that can be received per second on the interfaces in a specified VLAN before the switch begins dropping the Layer 2 PDUs. The drop threshold must be less than or equal to the shutdown threshold, if configured. If the drop threshold is greater than the shutdown threshold, the commit operation will fail. The shutdown-threshold configuration statement allows you to define the maximum number of Layer 2 PDUs of the specified protocol that can be received per second on the interfaces in a specified VLAN before the specified interface is disabled. The shutdown threshold must be greater than or equal to the drop threshold. You can define a drop threshold without specifying a shutdown threshold, and you can specify a shutdown threshold without specifying a drop threshold. If you do not specify these thresholds, then no thresholds are enforced and, as a result, the switch tunnels all Layer 2 PDUs regardless of the frequency at which they are received. Once an interface is disabled, you can reenable it using the clear ethernet-switching layer2-protocol-tunneling error command.
www.juniper.net
Monitoring L2PT: Part 1

This slide and the next provide key commands used to monitor L2PT. As shown on the slide, you can use the show vlans extensive command to verify the state of L2PT. For proper L2PT operations, the Dot1q tunneling and L2PT status should both show enabled.
www.juniper.net
Monitoring L2PT: Part 2

This slide shows the various show ethernet-switching layer2-protocol-tunneling commands, which can be helpful when monitoring L2PT operations.
www.juniper.net
This Chapter Discussed:

Implementation of filter-based VLAN assignments; Restricting traffic flows within a VLAN; Management of dynamic VLAN registration; and Tunneling Layer 2 traffic through Ethernet networks.
www.juniper.net
Review Questions
1. 2. 3. 4.
www.juniper.net
Lab 1: Advanced Ethernet Switching

The slide provides the objective for this lab.
www.juniper.net
www.juniper.net

Chapter 3: Advanced Spanning Tree

The purpose and operations of a spanning tree; How to implement multiple spanning tree instances in a network; and How to implement one or more spanning tree instances for a virtual LAN (VLAN).
Chapter 32 Advanced Spanning Tree
www.juniper.net
Spanning Tree Review

www.juniper.net
Advanced Spanning Tree Chapter 33
What If...?
Switches flood broadcast frames and frames for unknown media access control (MAC) addresses out all ports except the port on which those frames were received. In Layer 2 networks with redundant paths, such as the one illustrated on the slide, switches will continuously flood these types of frames throughout the network. When a frame is continuously flooded throughout a Layer 2 network, a Layer 2 loop exists. Layer 2 loops can be extremely harmful to a networks operation and should be avoided. To avoid Layer 2 loops, you must implement a Layer 2 loop-prevention mechanism such as theSpanning Tree Protocol (STP) or Rapid Spanning Tree Protocol (RSTP). We discuss some alternatives to STP and RSTP in subsequent sections in this chapter.
www.juniper.net
Factory Default Configuration and RSTP

RSTP is enabled by default on EX Series switches. RSTP helps ensure a loop-free Layer 2 topology in environments where redundant paths exist. To establish a loop-free path, RSTP elects one of the participating switches as the root bridge. Based on the election results, each switch determines the role and state of its switch ports. As illustrated on the slide, the root bridge election and determination of every switch ports role and state provide a loop-free path throughout the network. We covered the election process and port roles and states in detail in the Junos Enterprise Switching course. We provide a basic review of these details on subsequent slides.
www.juniper.net

This slide is designed to test your understanding of the various configuration options and how they relate to the root bridge election process. As shown in the following output, you can use the show spanning-tree bridge command to verify root bridge information: user@DS-1> show spanning-tree bridge STP bridge parameters Context ID : Enabled protocol : 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 :
0 RSTP 4096.00:26:88:02:74:90 2 seconds 20 seconds 15 seconds 0 1 2114 seconds ge-0/0/1.0 00:26:88:02:6b:81 4096.00:26:88:02:74:90 0 0
www.juniper.net

This slide is designed to test your understanding of the various configuration options and how they relate to port role and state determination. As shown in the following output, you can use the show spanning-tree interface command to verify spanning tree interface information: user@DS-2> show spanning-tree interface Spanning tree interface parameters for instance 0 Interface Port ID Designated Designated port ID bridge ID ge-0/0/1.0 16:514 128:514 4096.002688027490 ge-0/0/8.0 16:521 16:521 8192.002688026b90 ge-0/0/10.0 128:523 16:523 32768.0019e2516580 user@AS-1> show spanning-tree interface Spanning tree interface parameters for instance 0 Interface Port ID Designated Designated port ID bridge ID ge-0/0/8.0 16:521 128:521 4096.002688027490 ge-0/0/10.0 16:523 16:523 32768.0019e2516580 ge-0/0/12.0 16:525 16:525 32768.0019e2516580
Port Cost 20000 20000 1
State BLK FWD FWD
Role ALT DESG ROOT
Port Cost 2000 2000 2000
State FWD FWD FWD
Role ROOT DESG DESG
www.juniper.net

This slide is designed to test your understanding of the various configuration options and how they relate to port role and state determination. As shown in the following output, you can use the show spanning-tree interface command to verify spanning tree interface information: user@AS-2> show spanning-tree interface Spanning tree interface parameters for instance 0 Interface Port ID Designated Designated port ID bridge ID ge-0/0/8.0 32:521 16:521 32768.002688026b90 ge-0/0/12.0 16:525 16:525 32768.0019e2516580
Port Cost 20000 20000
State BLK FWD
Role ALT ROOT
www.juniper.net
A Limitation of STP and RSTP

While RSTP provides several advantages over STP neither of these protocols allow for load balancing, which in some environments is a requirement. In environments where RSTP or STP is used, all VLANs within a LAN share the same spanning tree, which limits the number of forwarding paths for data traffic. To address this limitation, we recommend you enable the Multiple Spanning Tree Protocol (MSTP) to provide load balancing for the configured VLANs. In environments that require interoperability with Cisco's Per-VLAN Spanning Tree Plus (PVST+) or rapid-PVST+ (RPVST+), you should consider using the Juniper Networks VLAN Spanning Tree Protocol (VSTP). We discuss MSTP and VSTP in subsequent sections in this chapter.
www.juniper.net
Multiple Spanning Tree Protocol

www.juniper.net
MSTP
MSTP extends STP and RSTP functionality by mapping multiple independent spanning-tree instances onto one physical topology. Each spanning-tree instance (STI) includes one or more VLANs. Each multiple spanning tree instance (MSTI) creates a separate topology tree and you can administratively map it to one or more VLANs. Allowing users to administratively map VLANs to MSTIs facilitates better load sharing across redundant links within a Layer 2 switching environment. Unlike in STP and RSTP configurations, a port can belong to multiple VLANs and be dynamically blocked in one spanning-tree instance but forwarding in another. This behavior significantly improves network resource utilization by load-balancing across the network and maintaining switch CPU loads at moderate levels. MSTP also leverages the fast re-convergence time of RSTP when a network, switch, or port failure occurs within a spanning-tree instance. MSTP was originally defined in the IEEE 802.1s draft and later incorporated into the IEEE 802.1Q-2003 specification.
www.juniper.net
MST Region
MSTP allows switches to be logically grouped into manageable clusters, known as multiple spanning tree (MST) regions. An MST region is a group of switches that share the same region name, revision level, and VLAN-to-instance mapping parameters. Each MST region supports up to 64 MSTIs. MSTP greatly reduces the number of bridge protocol data units (BPDUs) on a LAN by including the spanning tree information for all MSTIs in a single BPDU. MSTP encodes region information after the standard RSTP BPDU along with individual MSTI messages. The MSTI configuration messages convey spanning tree information for each instance. MSTP elects a regional root bridge for each MSTI. The regional root bridge is elected based on the configured bridge priority and calculates the spanning tree within its designated instance.
www.juniper.net
Common Spanning Tree: Part 1

The common spanning tree (CST), which interconnects all MST regions as well as STP devices not bound to a particular region, facilitates end-to-end paths within an MSTP environment. The CST facilitates backward compatibility with RSTP and STP.
www.juniper.net
Common Spanning Tree: Part 2

Because MSTP encodes region information after the standard RSTP BPDU, a switch running RSTP interprets MSTP BPDUs as RSTP BPDUs. This behavior facilitates full compatibility between devices running MSTP and devices running STP or RSTP. MSTP uses the same Ethernet frame as STP and RSTP. However, the BPDU information in the data field is different. The first 13 fields in the MST BPDU contain similar information to what you would find in an RSTP BPDU. In fact, an RSTP-speaking switch evaluates these fields in the same manner as it would any other RSTP BPDU. To the outside world (other MSTI regions or standalone RSTP devices), these fields are a representation of the virtual bridge that is an individual MSTP region. This information is used to build the CST.
www.juniper.net
Common and Internal Spanning Tree

All MSTP environments contain a CST, which is used to interconnect individual MST regions and independent STP devices. All bridges in the CST elect a single root bridge. The root bridge is responsible for the path calculation for the CST. As illustrated on the slide, bridges outside of the MST region treat each MST region as a virtual bridge, regardless of the actual number of devices participating in each MST region. The common and internal spanning tree (CIST) is a single topology that connects all switches (RSTP and MSTP devices) through an active topology. The CIST includes a single spanning tree as calculated by RSTP together with the logical continuation of connectivity through MST regions. MSTP calculates the CIST and the CIST ensures connectivity between LANs and devices within a bridged network. Each MSTP region builds a spanning tree for the region, referred to as an internal spanning tree, based upon the remaining BPDU fields. For a switch to participate in a regions internal spanning tree and use the information in this portion of the BPDU, it must be configured with the same configuration ID. Therefore, all switches in the same region must be configured with the same configuration ID. This approach to configuration ensures that when MSTP switches outside of the local MSTP region receive MSTP BPDUs, those switches will evaluate only the CST-related information (illustrated on the previous slide). Once the internal spanning tree is built, by default, all traffic on all VLANs will follow it. Continued on the next page.
www.juniper.net
Common and Internal Spanning Tree (contd.)

Without the use of MSTI configuration methods, traffic for all VLANs within a region flows along the path of the internal spanning tree. To override this behavior and allow some VLANs to take one path through the region and let others take other paths (64 paths are possible for each region), you must configure MSTIs as part of the router MSTI configuration. The information carried in the MSTI configuration messages allows each switch to elect root bridges, root ports, designated ports, designated bridges, and so forth for each MSTI. Each MSTI will have one or more VLANs associated with them. One VLAN cannot be in more than one MSTI. Notice that the MSTI messages do not carry VLAN ID information. The VLAN-to-MSTI mappings are configured locally on each switch and each switch configuration should use the same mappings. We evaluate MSTP configuration on EX Series switches on a subsequent slides.
www.juniper.net
MSTP Configuration
This slide illustrates the configuration structure for MSTP along with some of the key configuration parameters and considerations. Note that some of the MSTP configuration values must match on all devices participating in the same MSTP region. The MSTP configuration values that must match include: Configuration name: A user-defined value used to represent the region. Note that this value can be left blank but must match on all devices in a common region. Revision level: A user-defined value that represents the MSTP configuration version number. By default this value is 0. MSTI-to-VLAN mapping: A mapping between a specific MSTI and the VLANs that MSTI will service. This value must match on all devices in a common MSTP region. All VLANs not specifically mapped to a user-defined MSTI are automatically associated with MSTI 0 (the common spanning tree instance).
www.juniper.net
Topology and Objectives

This slide introduces the topology and objectives used throughout this case study.
www.juniper.net
Configuring MSTP
This slide provides the configuration required on DS-1 and DS-2 to accomplish the objectives outlined on the previous slide. Note that the configuration on AS-1, AS-2, and AS-3 is very similar to that shown on the slide with the exception of the configured bridge priority values (AS-1, AS-2, and AS-3 all use the default bridge priority of 32K).
www.juniper.net
Monitoring MSTP: Part 1

This slide illustrates the operational-mode commands used to monitor MSTP along with a sample output from the show spanning-tree mstp configuration command.
www.juniper.net

The slide highlights the use of the show spanning-tree interface command, which you use to verify the MSTP interface status and role assignment along with various other details.
www.juniper.net

The slide highlights the show spanning-tree bridge command, which you use to display STP bridge parameters for the CIST and individual MSTIs.
www.juniper.net
VLAN Spanning Tree Protocol

www.juniper.net
VSTP
VSTP allows for spanning trees to be calculated for each VLAN. VSTP is a nonstandard protocol, yet it is compatible with Ciscos PVST+ and RPVST+ protocols.
www.juniper.net
VSTP Considerations: Part 1

When using VSTP on EX Series switches, you can selectively configure up to 253 VLANs which map to distinct spanning tree topologies. You can enable RSTP for all VLANs not participating in VSTP. VSTP and RSTP are the only spanning-tree protocols that can be configured concurrently on an EX Series switch. Any other combination will result in a commit error as shown below: [edit protocols] user@switch# commit [edit protocols] 'mstp' Another xSTP protocol is enabled error: Another xSTP protocol is enabled error: configuration check-out failed Note that if your network includes 802.1D 1998 bridges, you can explicitly configure STP on those devices. When you explicitly configure STP, the EX Series switch uses the IEEE 802.1D 2004 specification, force version 0, which is an RSTP configuration that is compatible with basic STP.
www.juniper.net
VSTP Considerations: Part 2

Switches configured to run VSTP automatically assign each VLAN to one spanning-tree instance that runs RSTP. While this approach is useful to optimize network usage in small networks with a limited number of VLANs, a VSTP configuration in networks with several hundred VLANs can overload switch CPUs. For this and other reasons, we recommend you use MSTP when possible. MSTP ensures that your network does not slow down from the increased network traffic caused by hundreds of VLANs, each with its own spanning-tree instance. Unlike VSTP, MSTP sends a single BPDU regardless of the number of instances used.
www.juniper.net
VSTP Configuration
This slide illustrates the configuration structure for VSTP along with some of the key configuration parameters and considerations. VSTP is most similar to RSTP and uses the same terminology and many of the same configuration parameters. Note that VSTP also provides for the ability to force the version to STP. In its default form, VSTP is roughly equivalent to Ciscos Rapid PVST+. If the version is forced to STP, as shown on the slide, VSTP is then more similar to Ciscos PVST+. As shown on the slide, you can configure parameters for individual or all VLANs using the vlan option. You can also use the vlan-group option to simplify your configuration tasks when groups of VLANs use the same parameters. When using the vlan all option, the first 253 VLANs will participate in VSTP. All VLANs beyond the first 253 will not be supported by VSTP, but may be supported by RSTP if it is enabled. Note that VSTP will not work correctly if VLAN information is propagated over trunk ports using MVRP. Because MVRP does not currently support VSTP on EX Series switches, you must statically define VLAN membership on trunk ports when VSTP is enabled.
www.juniper.net
Topology and Objectives

This slide introduces the topology and objectives used throughout this case study.
www.juniper.net
Configuring VSTP
This slide provides the configuration required on DS-1 and DS-2 to accomplish the objectives outlined on the previous slide. Note that the configuration on AS-1, AS-2, and AS-3 does not need to include two distinct groups, as is shown for DS-1 and DS-2, since AS-1, AS-2, and AS-3 are all using the default bridge priority of 32K.
www.juniper.net
Monitoring VSTP: Part 1

The slide highlights the use of the show spanning-tree interface command, which you use to verify the VSTP interface status and role assignment along with various other details. Note that the spanning tree interface information is organized by VLAN.
www.juniper.net
Monitoring VSTP: Part 2

The slide highlights the show spanning-tree bridge command, which you use to display STP bridge parameters for each VLAN.
www.juniper.net

The purpose and operations of a spanning tree; How to implement multiple spanning tree instances in a network; and How to implement one or more spanning tree instances for a VLAN.
www.juniper.net
Review Questions
1. 2. 3.
www.juniper.net
Lab 2: Implementing MSTP and VSTP

The slide provides the objectives for this lab.
www.juniper.net

Chapter 4: Authentication and Access Control

Benefits of using end-user authentication; Operations of various access control features; Configuration and monitoring of access control features; and Processing considerations when multiple authentication and access control features are enabled.
Chapter 42 Authentication and Access Control
www.juniper.net
Authentication Overview
www.juniper.net
Authentication and Access Control Chapter 43
Understanding the Defaults

By default, all installed interfaces in an EX Series switch are configured for Layer 2 operations. These Layer 2 interfaces do not enforce any end-user authentication. In some environments, this default implementation can be problematic and prone to security risks. Once an end user receives a physical connection, that user can, if proactive measures are not taken, connect a rogue switch or wireless device to the network allowing access for unauthorized devices to the network and its resources. We discuss several authentication and access control features throughout this chapter that combat the potential security risks that are inherent with the default configuration settings. Note that not all features are currently supported on all EX Series devices. For details about your specific device, refer to the features overview found in the technical publications.
www.juniper.net
Potential Risks
This slide is designed to get you thinking about potential issues that can arise from the illustrated scenarios. Among other things, you could see Layer 2 topology changes that affect network performance or cause complete outages, unauthorized access to your network and its resources, or a network outage caused by resource overload through a denial of service (DoS) attack. In reality many potential issues can arise if you do not protect your network and its resources. The authentication and access control features covered in this chapter can help mitigate some of these potential issues.
www.juniper.net
Controlling Network Access

This slide introduces a number of features that can help control network access. We cover the features listed on the slide in detail in subsequent sections. Note that each of the highlighted features authenticates users using RADIUS. One of the biggest advantages of a RADIUS implementation is that it offers a single, centralized database of end-user accounts. Each network device can then query the RADIUS server when a given user attempts access. If the account is available and the parameters (user name, password, and so forth) are correct, the RADIUS server lets the network device know that the user should be granted access. Using RADIUS to authenticate users greatly simplifies account management because you maintain and manage only a single database of users, rather than dozens or hundreds. We provide more details about RADIUS authentication on subsequent slides in this section.
www.juniper.net
RADIUS Overview
RADIUS provides authentication, authorization, and accounting (AAA) services in network environments. When users attempt to access a network device, a RADIUS server verifies that the user is legitimate (authentication). The RADIUS server can then assign certain levels of access to network resources (authorization). Finally, the RADIUS server keeps track of how long that user stayed connected and how much data the user sent or received (accounting). A RADIUS client is a network device, such as an EX Series switch, that makes access requests on behalf of end users. Although RADIUS is similar in many respects to other client/server database models, RADIUS can only provide information regarding users as a part of the authentication process. In other words, you can not use a RADIUS database to look up information on a user or collection of users as you might with a Structured Query Language (SQL) or Lightweight Directory Access Protocol (LDAP) database. RADIUS servers will offer up the information they contain only within the context of the RADIUS process.
www.juniper.net
RADIUS Traffic Flow

The simple traffic flow on the slide illustrates the general steps that occur when an end user attempts to gain access to a network device (an EX Series switch in our example), as follows: 1. 2. The end user makes an initial connection to the network device; The network device creates and sends the RADIUS server an access-request packet, which includes the users account name and password (or an encrypted variant of the password); The RADIUS server consults its account database to determine if the user credentials are legitimate; Assuming the information in the access-request packet is valid, the RADIUS server returns an access-accept packet to the network device, informing it that the user should be given access; and The network device accepts the users connection.
3. 4.
5.
If the users credentials are not legitimate, the RADIUS server sends the network device an access-reject packet, instructing it to deny access to the user. Note that in this example we show how RADIUS authenticates user access to a network device. RADIUS can also be used to authenticate user access to an entire network. We illustrate how RADIUS is used to authenticate network access in the next section.
www.juniper.net
Access Control Features: 802.1X

www.juniper.net
802.1X
802.1X is an Institute of Electrical and Electronics Engineers (IEEE) standard used for port-level access control and authentication. 802.1X does not replace other security technologies; rather, it works together with port security features, such as Dynamic Host Configuration Protocol (DHCP) snooping, Dynamic ARP Inspection (DAI), and media access control (MAC) limiting, to guard against DoS attacks and spoofing. The 802.1X standard is based on the Extensible Authentication Protocol (EAP), a universal authentication framework. EAP is not an authentication mechanism by itself. Instead, EAP provides some common functions and a negotiation method to determine the authentication mechanism (EAP method) used between hosts and the authentication server. As individual hosts are authenticated, they can be associated with a specific profile and virtual LAN (VLAN). A LAN configured for 802.1X authentication contains three basic components: Supplicant: The device being authenticated. This device is typically a users PC or an IP phone. Authenticator: The device that prevents a supplicants access until it is authenticated. This device is a switch. Authentication server: The authenticating device. EX Series switches support RADIUS authentication servers for 802.1X.
To authenticate through 802.1X, supplicants require 802.1X client software. Some operating systems, such as Windows XP, include an 802.1X client by default. Chapter 410 Authentication and Access Control www.juniper.net
Controlling Access
802.1X works in conjunction with the Extensible Authentication Protocol (EAP) standard to provide port-based network access control. Defined by the Internet Engineering Task Force (IETF), EAP is an authentication framework that ensures the secure passing and validation of network credentials. EAP also allows for the creation of a variety of extensible access protocols, such as tunneled EAP for more flexible, expandable network access and authorization. 802.1X authenticators, such as EX Series switches, control network access by blocking all traffic to and from unauthorized supplicants. Authenticators open access only when supplicants are authenticated. Supplicants request network access through their attached authenticator by sending and responding to EAP over LAN (EAPOL) messages. If an authenticated supplicant no longer requires access to the network, it notifies the authenticator, at which time the authenticator once again blocks network access through the associated network port.
Relaying Information
When an authenticator receives authentication requests from a supplicant, those requests are received as EAPOL messages. The authenticator extracts and relays the identity information, found within the EAPOL message, to the authentication server as a RADIUS access request. The authenticator does not evaluate the supplicants credentials but simply relays that information to the authenticating server in an understandable format.
www.juniper.net
Authentication Process
This slide shows the individual steps for the 802.1X authentication process.
www.juniper.net
Authenticating Supplicants
Although the authentication server performs the actual authentication process, it is up to the authenticator to facilitate network access for individual supplicants through the switch ports. Supplicants are authenticated in either single mode, single-secure mode, or multiple mode: single: Authenticates only the first supplicant. All other supplicants who connect later to the port are allowed full access without any further authentication. The subsequent supplicants utilize the first supplicants authentication. This setting is the default supplicant mode on EX Series switches. It is also the recommended mode when a users PC and IP telephone use the same switch port and one of the supplicants does not support 802.1X. single-secure: Allows only one supplicant to connect to the port. No other supplicant is allowed to connect until the first supplicant logs out. multiple: Allows multiple supplicants to connect to the port. Each supplicant is authenticated individually.
www.juniper.net
Single Supplicant Mode

This slide illustrates the single supplicant mode, which is the default supplicant mode for EX Series switches.
www.juniper.net
Single-Secure Supplicant Mode

This slide highlights the single-secure supplicant mode.
www.juniper.net
Multiple Supplicant Mode

This slide highlights the multiple supplicant mode. The multiple supplicant mode overcomes the security concerns of the single supplicant mode while providing more flexibility than the single-secure mode. The multiple supplicant mode allows multiple supplicants to connect to the port. Each supplicant is authenticated individually.
www.juniper.net
Periodic Reauthentication
By default, EX Series switches functioning as 802.1X authenticators force all authenticated supplicants to periodically reauthenticate. The default reauthentication interval is 3600 seconds (1 hour). You can disable reauthentication or modify the reauthentication interval for individual ports at the [edit protocols dot1x authenticator interface interface-name] configuration hierarchy level. The reauthentication interval range is from 1 to 65535 seconds. We provide a configuration example on a subsequent slide.
www.juniper.net
802.1X and Mixed Environments

The slide addresses two common scenarios in which either the supplicant (client) or the authenticator (switch) is not enabled for 802.1X, whereas the other component is enabled for 802.1X. In the first scenario, the supplicant does not support 802.1X, but the authenticator does support 802.1X. In this case, the authenticator sends an EAP frame requesting the supplicants identity. Because the supplicant has no 802.1X support, it does not respond. The authenticator keeps the port in an unauthorized state, blocking normal traffic from being switched. In the second scenario, the authenticator does not support 802.1X, but the supplicant does support 802.1X. In this case, the supplicant sends an EAP start frame to initiate authentication. Because the authenticator is not configured for 802.1X, or does not support 802.1X, it does not respond. The supplicant continues sending EAP start frames until it reaches the predefined limit of attempts. The number of start attempts might vary depending on the supplicant client software. Once the predefined limit is reached, the supplicant assumes that the link is authenticated and begins forwarding traffic. In scenarios where the supplicant does not support 802.1X, you can permit some level of access using the guest VLAN feature or the static MAC bypass feature. We discuss both of these features on subsequent slides in this section.
www.juniper.net
Dynamic VLAN Assignment

802.1X provides the ability to dynamically associate supplicants with a designated VLAN during the authentication process. You can configure the RADIUS server to return VLAN attributes as part of the access-accept message. For proper operation, the same VLAN assigned to the supplicants port by the RADIUS server must also be configured on the switch. In addition to dynamically assigning VLANs, you can also dynamically apply firewall filters. EX Series switches support the configuration of RADIUS server attributes specific to Juniper Networks. These attributes are known as vendor-specific attributes (VSAs) and are described in RFC 2138. Through VSAs, you can configure port-filtering attributes on the RADIUS server. VSAs are clear text fields sent from the RADIUS server to the switch as a result of the 802.1X authentication success or failure. The 802.1X authentication prevents unauthorized user access by blocking a supplicant at the port until the supplicant is authenticated by the RADIUS server. The VSA attributes are interpreted by the switch during authentication, and the switch takes appropriate actions. Implementing port-filtering attributes with 802.1X authentication on the RADIUS server provides a central location for controlling LAN access for supplicants. These port-filtering attributes specific to Juniper Networks are encapsulated in a RADIUS server VSA with the vendor ID set to the Juniper Networks ID number, 2636. Continued on the next page.
www.juniper.net
Dynamic VLAN Assignment (contd.)

In addition to configuring port-filtering attributes through VSAs, you can apply a port firewall filter that has already been configured on the switch directly to the RADIUS server. Like port-filtering attributes, the filter is applied during the 802.1X authentication process, and its actions are applied at the switch port. Adding a port firewall filter to a RADIUS server eliminates the need to add the filter to multiple ports and switches. VSAs are only supported for 802.1X single-supplicant and multiple-supplicant configurations.
www.juniper.net
Guest VLAN
Guest VLANs, in conjunction with 802.1X, MAC RADIUS, and captive portal authentication, provide secure access to the LAN for corporate guests and for end devices that fail the authentication process. When a corporate visitor attempts to authenticate on the LAN and authentication fails, the visitor is moved to a guest VLAN. A guest VLAN typically provides access only to the Internet. A guest VLAN can also provide limited access to the LAN in cases when authentication fails for end devices that are not visitors. When authentication fails, the switch receives an access-reject message for the end device and determines whether a guest VLAN is configured on that port. If so, it moves that end device alone to the guest VLAN. If the access-reject message contains optional VLAN information, then the end device is moved to the VLAN specified by the RADIUS server and not to the locally configured guest VLAN. Authentication can fail for many reasons. One example is when the end device does not have supplicant software on it (for example, the end device is a device type that cannot be enabled for 802.1X, such as a printer). Another example is when the end device provides invalid credentialsa username or password that were not authenticated by the RADIUS server. For end devices that are not 802.1X-enabled, a guest VLAN can allow limited access to a server from which the non-802.1X-enabled end device can download the supplicant software and attempt authentication again.
www.juniper.net
Server Fail Fallback

The server fail fallback option allows you to specify how end devices connected to the switch are supported if the RADIUS authentication server becomes unavailable. EX Series switches use authentication to implement access control in an enterprise network. If 802.1X, MAC RADIUS, or captive portal authentication are configured on the interface, end devices are evaluated at the initial connection by a RADIUS server. If the end device is configured on the RADIUS server, the device is granted access to the LAN and the EX Series switch permits access through the interface. A RADIUS server timeout occurs when RADIUS authentication servers are not available to authenticate LAN access requests. The server fail fallback option allows you to specify one of the four actions listed on the slide to be taken toward end devices awaiting authentication when a server timeout occurs. Server fail fallback is triggered most often during reauthentication attempts made when the RADIUS server is no longer accessible. However, server fail fallback can also be triggered by an end devices first attempt at authentication through the RADIUS server. Server fail fallback allows you to specify that an end device be moved to a specified VLAN if the switch receives an access-reject message. The configured VLAN name overrides any attributes sent by the server. Note that the server fail fallback options are applicable to 802.1X, MAC RADIUS, and captive portal. We cover the MAC RADIUS and captive portal features in subsequent sections in this chapter.
www.juniper.net
Static MAC Bypass

You can allow end devices to access the LAN without authentication through a RADIUS server by including their MAC addresses in the static MAC bypass list. You might choose to include a device in the bypass list to allow non-802.1X-enabled devices access to the LAN or to eliminate the delay that occurs while the switch determines that a connected device is a non-802.1X-enabled host. When you configure static MAC bypass on the switch, the MAC address of the end device is first checked in a local database (a user-configured list of MAC addresses). If a match is found, the end device is successfully authenticated and the interface is opened up for it. No further authentication is done for that end device. If a match is not found and 802.1X authentication is enabled on the switch, the switch attempts to authenticate the end device through the RADIUS server or grants access through the guest VLAN, if configured. The MAC addresses can be bound to a specific network port or associated with any network port to facilitate user mobility. We provide a configuration example on a subsequent slide. If you bind a static MAC address to a specific port, you must use the multiple supplicant mode: [edit protocols dot1x] user@switch# commit [edit protocols dot1x authenticator static 00:26:88:02:6b:87/48 interface] 'interface ge-0/0/7.0' Static MAC cannot be configured on interface in single or single-secure mode error: commit failed: (statements constraint check failed)
www.juniper.net
Configuring 802.1X: Part 1

In the sample configuration, we see the definition of a RADIUS server and an authentication profile. As illustrated on the slide, the RADIUS server and authentication profile configuration is defined under the [edit access] configuration hierarchy.
www.juniper.net

This slide shows the next portion of the 802.1X configuration example. The configuration takes place under the [edit protocols dot1x] configuration hierarchy level. Note that when authenticating end-user devices through the static MAC bypass method you can specify an individual MAC address or a prefix-range of MAC addresses as shown in the following example: [edit protocols dot1x] user@switch# show authenticator { static { 50:c5:8d:ba:62:05/48; 00:26:88:00:00:00/24; } } ... In the preceding example the MAC address 50:c5:8d:ba:62:05/48 will be accepted along with any MAC address in the 00:26:88:00:00:00/24 prefix range. Using a prefix range can come in handy when you need to permit access to several devices that do not support 802.1X using the static MAC bypass method.
www.juniper.net

This slide shows the server fail fallback configuration syntax. Note that the server fail fallback options are applicable to 802.1X, MAC RADIUS, and captive portal. We cover the MAC RADIUS and captive portal features in subsequent sections in this chapter.
www.juniper.net
Monitoring 802.1X
This slide displays some common operational mode commands used to monitor 802.1X.
www.juniper.net
Access Control Features: MAC RADIUS

www.juniper.net
MAC RADIUS
Like 802.1X, MAC RADIUS authentication uses a centralized RADIUS server and database to authenticate end-user devices. You can configure MAC RADIUS authentication on interfaces that are connected to end-user devices that are not 802.1X-enabled but that you want to allow access to the LAN. Because MAC RADIUS uses a centralized authentication server and database, it is more scalable than manually defining an exclusion list (in the form of the static MAC bypass list) on individual switches.
www.juniper.net
MAC RADIUS and 802.1X

You can enable multiple authentication methods on the same switch port. For example, if both 802.1X-enabled end devices and end devices that are not 802.1X-enabled connect to an interface, you can configure both 802.1X and MAC RADIUS authentication methods on the interface. In this case, the switch first attempts to authenticate using 802.1X, and if that method fails, it attempts to authenticate the end device using MAC RADIUS authentication. When 802.1X and MAC RADIUS authentication are enabled on the same port on an EX Series switch, the switch uses Extensible Authentication Protocol-Message Digest 5 (EAP-MD5) as its EAP method when attempting to authenticate 802.1X-enabled devices. If you know that only non-802.1X-enabled end devices will connect to a given interface, you can eliminate the delay that occurs while the switch determines that the end device is non-802.1X-enabled by configuring the mac-radius restrict option. Note that the delay when determining whether a device is 802.1X enabled can take up to 90 seconds. We highlight the use of the restrict option on a subsequent slide.
www.juniper.net
Configuring MAC RADIUS: Part 1

In the sample configuration, we see the definition of a RADIUS server and an authentication profile. As illustrated on the slide, the RADIUS server and authentication profile are defined under the [edit access] configuration hierarchy. Note that this configuration is the same configuration required for 802.1X.
www.juniper.net
Configuring MAC RADIUS: Part 2

This slide shows the next portion of the MAC RADIUS configuration example. Similar to 802.1X, the MAC RADIUS configuration also takes place under the [edit protocols dot1x] configuration hierarchy. The illustrated example highlights the use of the restrict option. When using the MAC RADIUS restrict option, all 802.1X packets received on the associated port are dropped. In other words, a device attempting to authenticate through that port using 802.1X will never be authenticated regardless of the defined supplicant mode. In other words, when the restrict option is used no mix and match of 802.1X and MAC authentication occurs on the port, even if it is configured for multi-supplicant mode. Note that the dynamic VLAN and other RADIUS attributes continue to work the same even with the restrict option enabled.
www.juniper.net
Monitoring MAC RADIUS

This slide highlights the show dot1x interface detail command which is used to verify status information of interfaces participating in 802.1X and MAC RADIUS. The output shows that MAC RADIUS is enabled and that the restrict option is set for ge-0/0/15.0.
www.juniper.net
Access Control Features: Captive Portal

www.juniper.net
Captive Portal
Captive Portal is a network access control mechanism that authenticates users and permits access to the network based on username and password. You enable captive portal on an individual interface. When an end-user device opens a Web browser and points to a remote website, the connected switch, with the captive portal feature enabled, intercepts the request and presents the user with the captive portal login HTML page. The captive portal login HTML page requests the user's username and password. If the user is authenticated, the user's original Web-page request and subsequent access to the network is permitted. If the user is not authenticated, the switch denies the users original Web-page request along with all other network access. This authentication process includes a number of implied requirements. For example, an end-user device connected to a port enabled for captive portal authentication requires an IP address, gateway services, and most likely Domain Name System (DNS) services to initiate and request HTTP services from a remote Web server. The switch port achieves this task by allowing DHCP and DNS traffic to flow through the port even when the end user is not authenticated.
www.juniper.net
Authentication Exclusion List

In some situations, and specifically for some devices, you might need to define an authentication exclusion list. Captive portal provides such a mechanism and it is called the authentication whitelist. The authentication whitelist option is especially helpful when working with devices that do not have HTTP capabilities, such as printers and IP phones. The captive portal authentication whitelist is similar in function to the static MAC bypass option in 802.1X. We provide a configuration example on a subsequent slide.
www.juniper.net
Configuring Captive Portal: Part 1

A number of small steps are involved in ensuring captive portal is set up properly. The first step is to ensure that the Web service on the EX Series switch is enabled. You can use HTTP or HTTPS with the captive portal feature. Because of its increased security, HTTPS is recommended. Note that if HTTPS is used you will need to generate and load a security certificate and its corresponding key on the EX Series switch. Continued on the next page.
www.juniper.net
Configuring Captive Portal: Part 1 (contd.)

Currently you must generate the security certificate and key on a separate device such as a server running OpenSSL. An example of the command used on the server to generate a security certificate and key follows. (Note that the name of the associated .pem file is user-defined): user@server$openssl req -x509 -nodes -newkey rsa:1024 -keyout name-of-cert.pem -out name-of-cert.pem ... After entering this command you will be asked a number of generic questions about your locality and company. Once you answer those questions (or press Enter to skip answering those questions), the process of generating the security certificate and key is complete. You can view the contents as shown in the following output: user@server$cat name-of-cert.pem -----BEGIN RSA PRIVATE KEY----MIICXAIBAAKBgQCu5hAiBag2iezCVGE5dWoj4w1iJo1VdQNZvzMdCrmKHNrO8wnC ... vETZ/wtb8wL6kFskmoEC1mP3Vnz0tnhKo+sUmwDnXT1XgBYd3dgAdHfq8Y2Spmg= -----END RSA PRIVATE KEY---------BEGIN CERTIFICATE----MIICsDCCAhmgAwIBAgIJAJHTcY0ugTjqMA0GCSqGSIb3DQEBBAUAMEUxCzAJBgNV ... w5WoUn9IbiCpdzOeq53oCgIz01joCQpr6hFkTz1Kpz/mS4QX+Tgx4Qq7GNMUFL4= -----END CERTIFICATE----Once the certificate and key are generated, you will need to copy the associated .pem file from the server to your EX Series switch and associate that file with the configuration using the following command: [edit] user@switch# set security certificates local name-of-cert load-key-file name-of-cert.pem You can see that a number of required dependencies exist when using HTTPS. You must have a generated certificate and key loaded in the switchs file system to successfully define a local key for the system to load; and you must define and successfully load the key file to reference that key when enabling HTTPS. Unless all of the required dependencies are met, the configuration file will not commit and HTTPS will not work on the local switch.
www.juniper.net

In the sample configuration, we see the definition of a RADIUS server and an authentication profile. As illustrated on the slide, the RADIUS server and authentication profile are defined under the [edit access] configuration hierarchy. Note that this configuration is the same configuration required for 802.1X and MAC RADIUS.
www.juniper.net

This slide illustrates a sample configuration that enables the captive portal authentication feature using HTTPS for ge-0/0/0.0. Some considerations when enabling captive portal include the following: Captive portal can be configured only on L2 interfaces. Captive portal does not support dynamic VLAN assignments through the RADIUS server. Captive portal is a supported fallback option for 802.1X. By default captive portal uses the single supplicant mode. You can change this default setting and instead use the single-secure or multiple supplicant mode. Note that when an authentication whitelist is defined, you must use multiple supplicant mode for the associated interface. Captive portal limits the number of user authentication attempts. The default number of authentication attempts is three but this number can be changed using the retries configuration option. After the specified number of retries, captive portal places the authentication request in a holding state for a period of time (60 seconds by default). Upon expiry of re-authentication timer, captive portal tears down the connection. When this tear-down occurs, the end-user device must reauthenticate. Sessions, by default, are 3600 seconds (1 hour). You can change the default re-authentication timer using the session-expiry configuration option for specific interfaces or for all interfaces.
www.juniper.net

You have the flexibility to modify the captive portal login page and add detailed instructions or terms and conditions related to the use of the network. This slide provides the syntax and command options used to customize the captive portal login page for your environment. We illustrate a login page with the default parameters on a subsequent slide.
www.juniper.net

Depending on your environment, you might need to create an authentication whitelist. This slide illustrates a sample configuration that includes an authentication whitelist. By default, captive portal operates in single supplicant mode. When an authentication whitelist is defined, you must use the multiple supplicant mode for the associated interface as illustrated on the slide for ge-0/0/1.0.
www.juniper.net
Monitoring Captive Portal: Part 1

As with many network implementations, the true test of successful configuration is determining whether things work from the end-users perspective. If the end-user attempts to open a Web page associated with a remote Web server and that user is presented with the Terms and Conditions of Use and the User Authentication pages, as shown on the slide, and, after entering the required user name and password, is directed to the original Web page, then you know the captive portal feature is working as desired. If the user does not see the expected captive portal authentication pages or is never redirected to the original Web page, then you will need to verify connectivity and configurations on all participating devices including the end-user host, the switch, the RADIUS server, and possibly even the remote Web server.
www.juniper.net
Monitoring Captive Portal: Part 2

In addition to the verification steps highlighted on the preceding slide, you can also use various operational commands to monitor captive portal operations. The slide highlights several show and clear commands that can be useful when working with the captive portal feature.
www.juniper.net
Overview of Authentication Processing

www.juniper.net
Authentication Processing
You can enable multiple authentication methods on EX Series switches including those illustrated on the slide. When multiple authentication methods are enabled the switch uses a decision tree to determine which method to use when authenticating a user. The next slide provides an illustration of how this decision is made.
www.juniper.net
Authentication Process Flow

This slide illustrates the authentication process. The authentication process resembles the following: 1. 2. Authentication is initiated by an end device sending an EAP request or a data packet. If the MAC address of the end device is in the static MAC bypass list or the authentication whitelist, the switch accepts the end device without querying the authentication server and allows the end device to access the LAN. If the MAC address is not in the static MAC bypass list or the authentication whitelist, the switch checks whether an authenticator statement is configured on the interface. If an authenticator is not configured, the switch checks for captive portal configuration. If captive portal configuration exists for the interface, skip to Step 6. If an authenticator is configured: a. The switch checks whether the mac-radius restrict statement is configured on the interface. If mac-radius restrict is configured, the switch does not attempt 802.1X authentication and skips to Step 5. If it is configured, the switch moves to Step b.
3.
Continued on the next page.
www.juniper.net
Authentication Process Flow (contd.)

b. The switch sends either an EAP request (if the end device initiated contact with a data packet) or an EAP response (if the end device initiated contact with an EAPOL-start message). If the switch receives no response, it tries sending an EAP request two more times (a total of three attempts by default). If the end device does not respond to the EAP messages sent by the switch, the switch checks for MAC RADIUS configuration. If MAC RADIUS configuration exists, the switch skips to Step 4. If the end device responds to the EAP messages, the switch proceeds to step 5. When an EAP request is received from the end device, the switch sends an authentication request message to the authentication server. If the authentication server does not respond, the switch checks whether a server fail VLAN is configured. If a server fail VLAN exists, the switch performs the configured server fail fallback operation. If no server fail VLAN is available, the switch skips to Step 6. The authentication server sends an access-accept or access-reject message. If the authentication server sends an access-reject message, the switch skips to Step 8.
c. d.
e.
f.
4.
If the end device does not respond to the EAP messages, the switch checks whether MAC RADIUS authentication is configured on the interface. If it is not configured, the switch skips to Step 6. If MAC RADIUS authentication is configured on the interface: a. The switch sends a MAC RADIUS authentication request to the authentication server. The switch sends only one such request. If the authentication server does not respond, the switch checks whether a server fail VLAN is configured on the switch. If a server fail VLAN is available, the switch performs the configured server fail fallback operation. If no server fail VLAN is available, the switch skips to Step 8. The authentication server sends an access-accept or access-reject message. If the authentication server sends an access-reject message, the switch proceeds to Step 6.
5.
b.
6.
If MAC RADIUS authentication is not configured on the interface or if the authentication server responds with an access-reject message for MAC RADIUS authentication, the switch checks whether captive portal is configured on the interface. If captive portal is not configured on the interface, the switch skips to Step 8. If captive portal authentication is configured on the interface: a. b. c. The switch sends a request to the user on the end device for captive portal authentication information. The switch sends the captive portal authentication information to the authentication server. The authentication server sends an access-accept or access-reject message. If the server sends an access-reject message, the switch proceeds to Step 8.
7.
8.
The switch checks whether a guest VLAN is configured. If a guest VLAN is configured, the switch allows the end device limited access to the LAN.
www.juniper.net

Benefits of using end-user authentication; Operations of various access control features; Configuration and monitoring of access control features; and Processing considerations when multiple authentication and access control features are enabled.
www.juniper.net
Review Questions:
1. 2. 3.
www.juniper.net
Lab 3: Authentication and Access Control

www.juniper.net
www.juniper.net

Chapter 5: Deploying IP Telephony Features

Some common IP telephony deployment scenarios; Features that facilitate IP telephony deployments; and Configuration and monitoring features used in IP telephony deployments.
Chapter 52 Deploying IP Telephony Features
www.juniper.net
Deployment Scenarios
www.juniper.net
Deploying IP Telephony Features Chapter 53
Common Deployment Scenarios

This slide illustrates two common IP telephony deployment scenarios. In the first deployment scenario, a single switch port is used to connect the end-users IP phone and computer. In the second deployment scenario, two switch ports are used: one switch port for the users IP phone and the second switch port for the same users computer. Each deployment scenario has its own set of advantages and disadvantages, but scenario one is the clear winner for reasons explained on the next page.
www.juniper.net
Most Common Deployment Scenario

The most common enterprise IP telephony deployment consists of IP phones and end-host devices connected in series and attached to a single switch port. This design reduces switch port requirements by allowing multiple end-user devices to share a single connection rather than occupy their own individual switch ports. This approach reduces the total number of required switch ports and switches as well as capital and operational expenses. When IP phones and end-host devices share a common switch port, the sound quality on IP phone calls might suffer when large bursts of data traffic consume the available bandwidth. When there is not enough bandwidth for voice traffic, the resulting congestion leads to packet loss or delay. While packet loss and delay might be acceptable for data traffic it is not typically acceptable for voice traffic because of its quality requirements. To overcome this problem, EX Series switches support a number of features that allow you to treat voice traffic with a higher level of service. These features include Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP-MED), voice virtual LAN (VLAN), and class of service (CoS). We cover LLDP-MED and the voice VLAN in subsequent sections in this chapter and CoS in the next chapter. Although not strictly required for all IP telephony deployments, Power over Ethernet (PoE) is also another commonly used feature in environments that include IP telephony services. We cover PoE in the next section.
www.juniper.net
IP Telephony Features: Power over Ethernet

www.juniper.net
Power over Ethernet

PoE is defined in the Institute of Electrical and Electronics Engineers (IEEE) 802.3af specification. PoE allows both data and electric power to pass over a copper Ethernet LAN cable. This technology allows voice over IP (VoIP) telephones, wireless access points, video cameras, and point-of-sale devices to safely receive power from the same access ports through which network access is provided. EX Series Ethernet Switches provide either 8, 24, or 48 PoE ports. A PoE deployment consists of two primary components: the power sourcing equipment (PSE) and the powered device (PD). The PSE is any device that provides power in a PoE implementation. EX Series switches are considered PSE devices because they include PoE ports that distribute power. A PD is a device powered by a PSE. These devices might include VoIP telephones, wireless access points, video cameras, and point-of-sale devices.
www.juniper.net
PoE and PoE+

PoE and Power over Ethernet Plus (PoE+) permit electric power, along with data, to be passed over a copper Ethernet LAN cable. Powered devices that support PoE or PoE+ can receive power safely from the same access ports that are used to connect personal computers to the network. PoE was first defined in the IEEE 802.3af standard. In this standard, the amount of power that can be supplied to a powered device is limited to 15.4 W. PoE+, which was defined in the later IEEE 802.3at standard, increases the amount of power to 30 W. The PoE+ standard provides support for legacy PoE devicesan IEEE 802.3af (PoE) powered device can operate normally when connected to IEEE 802.3at (PoE+) power sourcing equipment. Whether an EX Series switch supports PoE, PoE+, or neither depends on the switch model. Consult your product-specific documentation for PoE support information.
www.juniper.net
PoE Power Budget

EX Series switches include a control mechanism for managing PoE operations. This control mechanism is known as the PoE controller. The PoE controller allocates power to the PoE ports from a set PoE power budget (pool of power that can be allocated). The PoE power budget varies depending on the switch model and, for switches that support power supplies of different capacities, the capacity of the installed power supply. For example, an EX Series switch with a 320 W power supply has a PoE power budget of 130 W, while with a 600 W power supply it has a PoE power budget of 410 W. In switches that support power supplies of different capacities, if you change your existing power supply to a lower-capacity power supply, the PoE power budget might no longer be sufficient to power all the PoE ports on the switch. If your switch supports redundant power supplies and you have installed power supplies of different capacities, the PoE power budget is based on the wattage of the lower-capacity power supply. The number of PoE ports on the switch cannot be increased by installing a larger power supply.
www.juniper.net
Power Management Modes

EX Series switches support the static and class power management modes. The mode used determines how the maximum power for a PoE interface is derived and how power is allocated to the PoE interfaces. With the static mode, you specify the maximum power for each PoE interface. The PoE controller then allocates this amount of power to the interface from its total budget. For example, if you specify a maximum value of 8.0 W for ge-0/0/3, the PoE controller allocates 8.0 W out of its total power budget for the interface. This amount is allocated to the interface whether a powered device is connected to the interface or whether the connected powered device uses less power than 8.0 W. With the class power management mode the maximum power for an interface is determined by the class of the connected powered device. The table on the slide lists the classes of powered devices and their associated power levels. When a powered device connects to power sourcing equipment (EX Series switch) it communicates its class information to the PoE controller on the switch. The PoE controller then allocates the maximum power required by the class to the PoE interface. It does not allocate power to an interface until a powered device is connected. Class 0 is the default class for powered devices that do not provide class information. Class 4 powered devices are supported only by switches that support IEEE 802.3at (PoE+). Check your product-specific documentation for support information. Continued on the next page.
www.juniper.net
Power Management Modes (contd.)

For switches that support IEEE 802.3af (PoE), the maximum power permitted on any interface is 15.4 W. This wattage guarantees that, after line loss, the powered device receives 12.95 W, which is the maximum required by 802.3af-compliant powered devices. For switches that support IEEE 802.3at (PoE+), the maximum power permitted on any interface is 30.0 W. This wattage guarantees that, after line loss, the powered device receives 25.5 W, which is the maximum required by 802.3at-compliant powered devices.
www.juniper.net
Configuring PoE
The slide illustrates the basic hierarchy and configuration options for PoE. The management option designates the way that the switch's PoE controller allocates power to the PoE interfaces. EX Series switches support the class and static management modes. The guard-band option reserves a specified amount of power (in watts) out of the PoE power budget in case of a spike in PoE consumption.
www.juniper.net
Monitoring PoE: Part 1

This slide and the next highlight some key operational-mode commands used to monitor PoE. Use the show chassis hardware command to determine the PoE capabilities of an EX Series switch. Use the show poe controller command to view PoE power usage and availability details.
www.juniper.net
Monitoring PoE: Part 2

This slide illustrates the show poe interface command, which you use to verify the operational state of PoE interfaces. The output of this command also displays the power consumption details for PDs attached to the PoE interfaces. As shown on the slide, you can choose to add the interface name to the show poe interface command to limit the generated output and display PoE details for only the specified interface.
www.juniper.net
IP Telephony Features: Neighbor Discovery

www.juniper.net
LLDP Defined
The Link Layer Discovery Protocol (LLDP) is a Layer 2 protocol that facilitates network and neighbor discovery. Neighbor discovery is made possible through advertisements sent by each network device participating in LLDP. Advertisements are sent by LLDP-enabled devices to identify themselves and to announce their capabilities to neighboring devices. LLDP is somewhat comparable in purpose to the Cisco Discovery Protocol (CDP). LLDP operates on both Layer 2 and Layer 3 interfaces. Also, for operability of the protocol, it does not matter whether the port is a trunk port or an access port because the LLDP frames are untagged. This behavior helps the protocol build the network topology, regardless of specific configuration parameters assigned to the port. LLDP is defined in IEEE 802.1ab. Any LLDP-enabled device is known as an LLDP agent. LLDP agents exchange LLDP data units (LLDPDUs) with neighboring LLDP agents. LLDP agents store their local information as well as the information learned from neighbors in a local database. LLDP periodically refreshes the local database to maintain accurate information for neighboring LLDP agents.
www.juniper.net
LLDPDU Frames
LLDP-capable devices, such as EX Series switches, transmit information in type/length/value messages (TLVs) to neighbor devices. Device information can include specifics such as chassis and port identification, system name, and system capabilities. LLDP defines some TLVs as mandatory, whereas others are listed as optional. The TLVs leverage this information from parameters that are already configured in the Junos operating system. LLDP frames are constrained to the local link, which means LLDP frames are never relayed or passed beyond a directly connected neighbor. The slide illustrates the format of an LLDPDU frame. This illustration highlights the LLDP multicast address as well as the TLVs that are required in all LLDPDUs. A basic description of the mandatory TLVs follows: Chassis ID: This TLV identifies the MAC address associated with the local system. Port ID: This TLV identifies the port from which the LLDPDU is transmitted. Time to live (TTL): This TLV identifies how long the devices information is valid. A nonzero value indicates that the information is to be updated. A value of 0 indicates that the information is no longer valid and should be removed from the receivers database. End of LLDPDU: This TLV identifies the end of TLVs in the LLDPDU.
Continued on next page.
www.juniper.net
LLDPDU Frames (contd.)

In addition to the mandatory TLVs, EX Series switches support the following set of basic TLVs: Port description: This TLV provides the user-configured port description. The port description can be a maximum of 256 characters. System name: This TLV identifies the user-configured name of the local system. The system name can be a maximum of 256 characters. System description: This TLV provides the system description containing information about the software and current image running on the system. This information is not configurable but taken from the software. System capabilities: This TLV identifies the primary function performed by the system. The capabilities that the system supports are definedfor example, bridge or router. This information is not configurable but based on the model of the product. An EX Series switch is capable of both switch and router operations. Management address: This TLV identifies the IPv4 management address of the local system.
www.juniper.net
LLDP Updates
LLDP agents send periodic LLDP updates to neighboring devices. These updates are advertised every 30 seconds by default. You can adjust the interval at which updates are sent through the LLDP-related configuration. LLDP agents also send LLDP updates as needed based on local changes. These updates are often referred to as triggered updates because a value or state change triggers the update, as opposed to the regularly scheduled updates. Triggered updates cannot occur more than once per second. LLDP updates are always sent as unsecured, one-way advertisements. Because LLDP is a stateless protocol, there is no verification or guarantee that the neighboring devices are actually receiving the transmitted advertisements. LLDP does not offer any authentication mechanism; therefore, all LLDP advertisements are unsecured. If a switch port connects to an untrusted boundary, such as a customers network, we highly suggest that LLDP be disabled on that port. We provide a configuration example on a subsequent slide in this chapter.
www.juniper.net
Transmit Agent Role

Typically a device configured for LLDP (an LLDP agent) functions as both a transmit and receiver agent. The LLDP transmit agents role is to send periodic and triggered updates to its neighboring devices. The TTL TLV mechanism is used to ensure that only valid information is stored on the receiver agent. The TTL value is determined by multiplying the msgTXInterval value with the msgTXHold value. These values are defined on the transmit agent using the advertisement-interval and hold-multiplier configuration options. As shown on the slide, the default transmit interface (msgTXInterval) is 30 seconds and the default hold value (msgTXHold) is 4 intervals. These default values produce a default TTL value of 120 seconds. Thus, if a receiver agent does not receive an update from a given neighbor (transmit agent) within 120 seconds, the information associated with that neighbor is removed from the receiver agents database. LLDP transmit agents notify their neighbors when an interface is about to become nonoperational or when LLDP is disabled on that interface. A final shutdown LLDPDU is sent with the chassis ID, port ID, TTL TLV fields set to zero (0), and the end-of-LLDPDU TLV set. If a transmit agent fails to send a shutdown TLV for an interface before it actually goes down, the receiver agent maintains the learned information on that interface until the TTL age timer expires (default of 120 seconds). Continued on the next page.
www.juniper.net
Receiver Agent Role

The LLDP receiver agent stores information received from all neighboring LLDP-enabled devices (LLDP transmit agents) in its neighbor database. The information found within the neighbor database is accessible through SNMP. With the help of the TTL TLV mechanism, the contents within the neighbor database are refreshed or purged regularly to ensure that only accurate data is maintained. The LLDP receiver agent maintains detailed statistic counters for all LLDP-enabled interfaces. The statistic counters include frames received, frames with errors, and unknown TLVs for a given interface.
www.juniper.net
LLDP-MED
LLDP-MED is an extension to LLDP (IEEE 802.1ab) and was developed to support interoperability and enhance discovery capabilities between VoIP endpoint devices, such as IP phones, and other networking devices, such as EX Series switches. LLDP-MED exchanges TLV messages between switches and IP phones (at least those that support LLDP-MED) to help facilitate the deployment of IP telephony services in a network. Some of the key TLVs supported on EX Series switches include the following: Network Policy: This TLV advertises the port VLAN configuration and associated Layer 2 and Layer 3 attributes. Attributes include the policy identifier, application types, such as voice or streaming video, 802.1Q VLAN tagging, and CoS values. Endpoint Location: This TLV advertises the physical location of the endpoint and is used for emergency location services. Extended Power through MDI: This TLV advertises the power type, power source, power priority, and power value of the port. It is the responsibility of the PSE device to advertise the power priority on a port.
These TLV messages provide detailed information about how voice traffic gets tagged and prioritized. For example, CoS and 802.1Q tag information can be sent from the switch to the IP telephone through these TLV messages. LLDP-MED was developed by the Telecommunications Industry Association (TIA) and is defined in the American National Standards Institute (ANSI)/TIA-1057 standard. Chapter 522 Deploying IP Telephony Features www.juniper.net
LLDP-MED Classification
To help determine a devices capabilities, LLDP-MED uses classification to group devices and map capabilities to each group. LLDP-MED distributes device classification information through TLVs. The LLDP-MED device class values in use today are shown in the table on the slide. Class 0 is not yet defined and classes 5 through 255 are currently reserved.
www.juniper.net
LLDP and LLDP-MED Interaction

The slide illustrates the basic LLDP and LLDP-MED message exchange sequence when an LLDP-MED-enabled IP phone is initially connected to an EX Series switch. Here you can see that the EX Series switch initially advertises a base LLDP message. This initial advertisement includes all mandatory TLVs. Once the EX Series switch receives an LLDP-MED message from the IP phone, it begins sending LLDP-MED messages. Note that both LLDP and LLDP-MED are enabled by default for all interfaces in the factory-default configuration. We provide a configuration example on a subsequent slide.
www.juniper.net
LLDP and 802.1X

When 802.1X is used on an interface, LLDP and LLDP-MED frames are advertised and processed only when a secure port is authenticated. In other words, when 802.1x is enabled on a given switch port, LLDP and LLDP-MED frames are not transmitted or received until that port becomes authenticated. In the case where an IP phone and a users PC are connected to the same switch port, both devices can be authenticated separately when the multiple supplicant mode is enabled on that port. Using multiple supplicant mode allows both devices to receive their appropriate VLAN assignments and individual policies for voice and data traffic. Voice traffic is commonly associated with a voice VLAN, which can be treated with a higher priority than data traffic using CoS. If an IP phone and a users PC are connected to the same switch port and only one of the two devices is 802.1X capable, use single supplicant mode. Single supplicant mode authenticates the 802.1X-capable device and freely permits traffic from other devices without further authentication. In this situation, both devices are permitted network access, and LLDP or LLDP-MED messages can be exchanged.
www.juniper.net
Configuring LLDP and LLDP-MED

The slide illustrates the basic hierarchy and configuration options for LLDP and LLDP-MED.
www.juniper.net
Monitoring LLDP and LLDP-MED

This slide highlights some key operational-mode commands used to monitor LLDP and LLDP-MED. We provide a sample output for some of these commands in the case study later in this chapter.
www.juniper.net
IP Telephony Features: Voice VLAN

www.juniper.net
Voice VLAN Review

Typically, network administrators choose to treat VoIP traffic differently from user data traffic. To treat these types of traffic differently, you must be able to separate common user data traffic from voice traffic. The voice VLAN feature is used for this purpose. The voice VLAN enables a single access port to accept untagged data traffic as well as tagged voice traffic and associate each type of traffic with distinct and separate VLANs. By doing this, a networks CoS implementation is used to treat voice traffic differently, generally with a higher priority than common user data traffic. We cover CoS in the next chapter. As previously mentioned you can use LLDP-MED on EX Series switches to dynamically provide the voice VLAN ID and 802.1p CoS values to the attached IP phones. This dynamic method associates each IP phone with the appropriate voice VLAN and assigns the necessary 802.1p values, which are used by CoS, to differentiate service for voice traffic within a network. Note that LLDP-MED is not strictly necessary to associate the voice VLAN ID and 802.1p values with an IP phone. With most vendors, you can manually assign these values to the IP phone directly without the use of LLDP-MED.
www.juniper.net
Voice VLAN Configuration: Part 1

This slide illustrates the basic hierarchy structure along with the available configuration options associated with the voice VLAN feature.
www.juniper.net
Voice VLAN Configuration: Part 2

This slide provides a configuration example based on the sample topology shown on the slide.
www.juniper.net
Monitoring the Voice VLAN

This slide illustrates the expected output based on our sample configuration shown on the previous slide. Here you can see that the access port (ge-0/0/6.0) is associated with the data and voice VLANs.
www.juniper.net
Case Study: Deploying IP Telephony Features

www.juniper.net
Case Study: Objectives and Topology

The slide displays the objectives and topology for our case study.
www.juniper.net
Configuring LLDP, LLDP-MED, and PoE

This slide shows the required configuration for LLDP, LLDP-MED, and PoE. Note that these features are enabled in the factory-default configuration on most EX Series switches. We show the syntax here as a review and for clarification purposes.
www.juniper.net
Configuring the Voice VLAN Feature

This slide shows the required configuration to enable the voice VLAN feature on ge-0/0/0.0. Note that you can use the access-ports configuration option rather than specifying each access port individually. Similarly, you could simplify the configuration for the interfaces and use an interface range instead of defining the access ports individually. In this example we specify the expedited-forwarding forwarding class for the voice VLAN. The configured forwarding class can be communicated to the IP phone through LLDP-MED. Note that the forwarding class must be configured on the switch along with the desired scheduling parameters. We discuss class of service in the next chapter.
www.juniper.net
Verifying LLDP
Although there are several other commands useful in determining the status of LLDP and LLDP-MED, none are more helpful when focusing on a specific interface or neighbor than the show lldp neighbors interface <interface-name> command. Notice that sample output provides Layer 2 and Layer 3 information as well as manufacturing details for the connected neighbor. Much of this information can be useful when troubleshooting network and connectivity issues.
www.juniper.net
Verifying PoE
This slide shows the output from the show poe interface ge-0/0/0 command and a capture from an LLDP frame exchanged between the switch and IP phone. Here you can see that ge-0/0/0 is enabled for PoE and that the connected powered device (the IP phone) is successfully drawing power from that PoE interface. You can also see in both the sample output as well as the capture from the LLDP frame that the IP phone is registered as a power class 2 device.
www.juniper.net
Verifying the Voice VLAN: Part 1

This slide illustrates the expected output from the show vlans <vlan-name> extensive commands. Here you can see that the access port (ge-0/0/0.0) is associated with the data and voice VLANs and that it is functioning as an untagged interface for the data VLAN and a tagged interface for the voice VLAN.
www.juniper.net
Verifying the Voice VLAN: Part 2

This slide provides a sample capture of an LLDP-MED frame exchanged between the switch and IP phone. Here you can see the expected VLAN details being sent from the switch to the IP phone.
www.juniper.net

Some common IP telephony deployment scenarios; Features that facilitate IP telephony deployments; and Configuration and monitoring features used in IP telephony deployments.
www.juniper.net
Review Questions
1. 2. 3. 4.
www.juniper.net
Lab 4: Deploying IP Telephony Features

www.juniper.net
www.juniper.net

Chapter 6: Class of Service

The purpose and basic operations of class of service (CoS); CoS features commonly used in Layer 2 networks; and Configuration and monitoring of CoS.
Chapter 62 Class of Service
www.juniper.net
Class of Service Overview

www.juniper.net
Class of Service Chapter 63
Challenges in the LAN: Part 1

Many of todays Layer 2 networks consist of multiple layers. In these environments, the aggregate bandwidth at the Access Layer is typically much higher than the aggregate bandwidth at the higher layers. Although there are typically no issues with this design, oversubscription and the resulting congestion between layers are possible. While you can add additional links between the layers to increase the aggregate throughput, this is not always possible or the best solution.
www.juniper.net
Challenges in the LAN: Part 2

Today's enterprise network has evolved into a multi-services infrastructure carrying business-critical applications, voice and video streams, and traffic from building automation and other control systems. A well designed enterprise network can increase the likelihood of meeting the performance demands of these applications in these networks, but there is no guarantee! Even in networks that are not fully utilizing the capacity on all their network links, instantaneous contention for transmission to the wire can occur. If two packets arrive at an output interface at the same time, the system transmits one packet and adds the other to a queue. The delay in the queue might be minimal in a generally uncongested network; however, even a brief delay can be significant for latency-sensitive trafficsuch as voice over IP (VoIP).
www.juniper.net
Addressing the Challenges

You can use CoS to address the challenges mentioned on the previous slides and to help meet performance requirements in todays networks. CoS allows you to treat traffic differently by providing a minimum bandwidth guarantee, low latency, low packet loss, or a combination of these things for categories of traffic. Consequently, deploying CoS can make some applications perform better. CoS cannot increase the total bandwidth of a link or decrease latency beyond the minimum limits imposed by the speed of light. CoS cannot eliminate congestion within a network. CoS can, however, help you control how this congestion affects different types of traffic. You can configure devices running the Junos operating system to guarantee certain levels of bandwidth to traffic classes. This configuration ensures that the device meets minimum bandwidth guarantees during periods of congestion. In this way, it is possible to ensure that certain types of traffic receive a guaranteed minimum level of bandwidth on each link. To treat the traffic within the defined service groups consistently throughout the network, all devices must have a similar CoS configuration. We provide configuration examples later in this chapter.
www.juniper.net
Prioritizing Traffic
As traffic enters a switch port, CoS examines the CoS settings found in the frame or packet headers. The switch uses these CoS settings to determine how that traffic should be classified. Based on the resulting classification, the traffic is associated with a forwarding class and corresponding output queue. The configuration associated with the output queue determines which packets are transmitted first when congestion exists. We examine this process in more detail on subsequent slides.
www.juniper.net
Traffic Classification
As traffic enters an incoming port, the switch examines the traffic and then associates that traffic with a forwarding class and loss priority and assign the traffic to output queues based on the associated forwarding class. This process is known as traffic classification. Note that EX Series switches can match traffic based on existing CoS values using behavior aggregate (BA) classification, or it can match on a variety of fields in a packets header (IP address, protocol, port, and so forth) using multifield classification. Classifiers associate traffic with a forwarding class. You can configure both a BA classifier and an multifield (MF) classifier on an interface. If you do this, the BA classification is performed first and then the MF classification. If the two classification results conflict, the MF classification result overrides the BA classification result. Note that when a source media access control (MAC) address is learned, the frame that contains the source MAC address is always sent out queue 0 on egress interfaces regardless of the classifier applied to the ingress interface. BA classification is often used in the core of enterprise networks. BA classifiers are based on fixed-length fields, which makes them computationally more efficient than MF classifiers. Therefore core devices, which handle high traffic volumes, are normally configured to perform BA classification. As shown on the slide there are three types of BA classifiers supported on EX Series switches: Chapter 68 Class of Service DiffServ code point (DSCP) for IP DiffServ, IP precedence bits, and Institute of Electrical and Electronics Engineers (IEEE) 802.1p CoS bits. www.juniper.net
Code Point Aliases

Code-point aliases assign names to specific patterns of CoS bits. When you configure certain CoS components such as classifiers, drop-profile maps, and rewrite rules, you can use the code-point alias instead of the corresponding bit pattern. The bit patterns represented by the code-point aliases are used to associate incoming traffic with its designated service level. Code-point aliases are available for various CoS values including DSCP, IP precedence, and IEEE 802.1 bits. An example of a code-point alias found in enterprise environments is ef (expedited forwarding) which maps to the DSCP pattern 101110. This alias is often used to classify VoIP traffic. EX Series switches are aware of common code-point aliases and their corresponding bit patterns. You can view the known aliases using the command shown on the slide. Note that you can also define custom mappings as shown in the following example: [edit class-of-service] user@switch# set code-point-aliases dscp custom-ef 101110 [edit class-of-service] user@switch# commit configuration check succeedscommit complete [edit class-of-service] user@switch# run show class-of-service code-point-aliases dscp | match ef custom-ef 101110 ef 101110 www.juniper.net Class of Service Chapter 69
Forwarding Classes
A forwarding class is a grouping mechanism switches and other network devices use to identify traffic that should receive common treatment. The network device associates traffic with a forwarding class during the classification process described earlier. During output, the network device assigns traffic to a particular output queue based on forwarding class. If a rewrite rule is enabled for the egress interface, the CoS bits are rewritten based on forwarding class. We discuss rewrite rules in more detail later in this chapter. Thinking of forwarding classes as output queues is tempting (and sometimes helpful) because a one-to-one mapping of forwarding classes and output queues usually exists. However, that definition is not necessarily true, because network devices, including EX Series switches, support more forwarding classes than queues. In these cases, combining the concepts of forwarding classes and output queues can be confusing.
www.juniper.net
Controlling Congestion
The ability to manage queues during congestion before congestion gets unmanageable can help maintain desired performance levels in a network. There are a number of mechanisms that can help manage congestion. Depending on the platform, EX Series switches support either weighted tail drop (WTD) or weighted random early detection (WRED). WTD: When the queue reaches a certain buffer capacity (fill level), the Junos OS no longer allows and begins dropping packets. By default, the level is 100% of the queue. WTD is only supported on the EX2200, EX3200, and EX4200 switches. WRED: Once the queue reaches a certain buffer capacity (fill level), the Junos OS gradually and randomly drops packets with a packet loss priority (PLP) of low or high. Packets with a PLP of high are more likely to be dropped than packets with a PLP of low. This point is illustrated on the next slide. The Junos OS supports two WRED implementationssegmented and interpolated. From a high level, segmented is a stair-step like drop profile, whereas interpolated is a smother (curve) drop profile. Regardless of the implementation, a profile is a graph where the x axis represents current buffer utilization (fill level) and the y axis is the drop probability. Depending on where the traffic is plotted against the graph, the packet will either be dropped or buffered. WRED is only supported on the EX8200 line of Ethernet switches.
In addition to the drop profiles, you can also implement shapers and policiers to rate-limit and drop traffic that exceeds a specified rate. We cover shapers and policers on subsequent slides.
www.juniper.net
Loss Priority and Drop Profiles

Drop profiles allow you to define a drop level (fill level) that notifies a queue when to start dropping packets. How a switch determines what packets to drop and when to drop those packets depends on the switch model. As previously mentioned some EX Series switches support WRED while others only support WTD. On switch models that support WRED, you can define custom drop profiles that proactively drop packets with the PLP high value thus providing more flexibility. On EX Series switches that support WTD, all packets are dropped when the drop level is reached, regardless of the PLP value. By default, when the fill level is 0 percent, the drop probability is 0 percent. When the fill level is 100 percent, the drop probability is 100 percent. You can create custom drop profiles. In the following example, the fill level is set at 75 percent which means that when the queue is 75 percent full packets destined for the associated output queue will be dropped. [edit class-of-service] user@switch# show drop-profiles { fill-to-75 { fill-level 75; } } Note that drop profiles are mapped to individual queues through the queues scheduler configuration. We discuss schedulers later in this chapter.
www.juniper.net
Rate Limiting Traffic

EX Series switches support two types of token-based rate limitingpolicing and shaping. Rate limiters are based on actual packets (preamble and inter-frame gap are excluded). Policing can drop or modify the PLP for packets above a specified rate. Policing is supported for incoming traffic only and is configured under the [edit firewall] hierarchy and applied directly to interfaces defined under the [edit interfaces] hierarchy. Port shaping enables you to shape the aggregate traffic through an egress port to a rate that is less than the line or port rate. Port shaping defines the maximum bandwidth allocated to a port, while queue shaping defines a limit at which queues transmit packets. For example, using queue shaping, you can rate-limit a strict-priority queue so that the strict-priority queue does not lock out (or starve) low-priority queues. All configuration for port and queue shaping is defined under the [edit class-of-service] hierarchy.
www.juniper.net
Allocating Resources Using Schedulers

You control how a switch services queues by configuring schedulers and scheduler maps. A scheduler contains parameters that describe how a queue should be serviced. A scheduler is associated with a particular queue and forwarding class through a scheduler map. You define the order in which packets should transmit by defining a priority and a transmission rate for a forwarding class. You can configure a transmission rate for each forwarding class. The transmission rate controls how much bandwidth the traffic associated with a given forwarding class can consume. By default on EX Series switches, the software assigns 95 percent of the bandwidth to queue 0 (the best-effort forwarding class) and 5 percent of the bandwidth to queue 7 (the network-control forwarding class). The software assigns all other queues a 0 transmission rate. By default, all queues can exceed their assigned transmission rate if other queues are not fully utilizing their assigned rates. The configured buffer size determines the size of each queue. By default, the software assigns 95 percent of the available buffer space to queue 0 and the remaining 5 percent to queue 7. By default, all other queues have 0 percent of the available buffer space; therefore, if you use queues other than 0 and 7, you should assign buffers to those queues. As the buffer fills, the likelihood of packet drops increases.
www.juniper.net
Queue Priority
Priority scheduling determines the order in which an output interface transmits traffic from the queues, thus ensuring that queues containing important traffic are provided better access to the outgoing interface. Priority scheduling is accomplished through a procedure in which the scheduler examines the priority of the queue. EX Series switches support two queue priority levels: Low: When a queue is associated with the low priority, the scheduler determines if that queue is within its defined bandwidth profile. This binary decision, which is reevaluated on a regular time cycle, compares the amount of data transmitted by the queue against the amount of bandwidth allocated to it by the scheduler. When the transmitted amount is less than the allocated amount, the queue is considered to be in profile. When the transmitted amount is more than the allocated amount, the queue is considered to be out of profile. An out-of-profile queue can only transmit if bandwidth is available. Otherwise, the traffic associated with that queue will be buffered. Strict-high: When a queue is associated with the strict-high priority it receives preferential treatment over all low priority queues. Unlimited bandwidth is assigned to strict-high priority queues. Queues are scheduled according to the queue number, starting with the highest queue 7, with decreasing priority down through queue 0. Traffic in higher queue numbers is always scheduled prior to traffic in lower queue numbers. In other words, in case of two strict-high priority queues, the queue with higher queue number is processed first. Note that packets in low priority queues are transmitted only when strict-high priority queues are empty.
www.juniper.net
Implementing Class of Service

www.juniper.net
Understanding the Defaults: Part 1

This and the next slides illustrate some of the default configuration for various CoS components. This slide specifically illustrates the default classifier configuration details associated with access and trunk ports.
www.juniper.net

This slide illustrates the default scheduler configuration details associated with EX Series switches.
www.juniper.net

This slide illustrates the default rewrite behavior on EX Series switches.
www.juniper.net
Test Your Knowledge

This slide is designed to test your understanding of how the default configuration components work on EX Series switches. In this example, switch-1 receives traffic from its attached IP phone with the DSCP CoS bits 101110 (code-point alias ef). Based on the default classifier applied to access ports, all traffic received is classified as best-effort traffic (queue 0). As previously illustrated, the CoS bits for traffic leaving queue 0 on an egress interface are rewritten to 000000. To maintain the CoS bit pattern set by the IP phone, you would need to apply a custom classifier to ge-0/0/6.0 that matches the DSCP ef bits and associates the related traffic with queue 5 (expedited forwarding class). Note that you would also need to associate scheduling resources with this queue to ensure the traffic is serviced properly.
www.juniper.net
Changing the Default Configuration

This slide introduces the next several slides which cover configuration examples that override the default CoS implementation on EX Series switches. Note that all CoS configuration covered in the remainder of this section is performed at the [edit class-of-service] hierarchy.
www.juniper.net
Enabling BA Classification
This slide provides a sample configuration used to enable BA classification with some custom definitions. This custom DSCP classifier uses the import defaults statement which imports all default classification assignments that are not specified. This example also illustrates how classifiers are associated with logical interfaces. In our example, the custom DSCP classifier is associated with all logical Gigabit Ethernet interfaces using the asterisk (*) wildcard option. Once a classifier is associated with an interface, you can verify the association using the show class-of-service interface <interface-name> command as shown in the sample capture that follows: user@switch> 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: <default>, Index: 2 Congestion-notification: Disabled Logical interface: ge-0/0/6.0, Index: 2147404772 Object Name Type Classifier my-classifier dscp
Index 13741
www.juniper.net
Defining Schedulers
This slide illustrates a sample scheduler configuration using the four system-defined forwarding classes. In this example we allocate the desired queue transmission priority level along with the transmit rate and buffer size percentages. Note that the queues with the strict-high transmission priority do not have a defined transmit rate percentage because those queues are provided as much bandwidth as they require. Because of their intrinsic behavior, strict-high priority queues can potentially consume all of the bandwidth and starve the other queues. As a safe-guard, you can implement queue shaping to prevent the starvation of low priority queues.
www.juniper.net
Configuring Scheduler Maps

Scheduler maps associate schedulers with particular forwarding classes and their respective queues. The Junos OS references queues by their associated forwarding class. You configure scheduler maps under the [edit class-of-service scheduler-maps] hierarchy. In the example on the slide, we associate four schedulers with the four default queues.
www.juniper.net
Using the EZQoS Template

This slide illustrates the use of the EZQoS configuration template which is an optional method for implementing some of the basic CoS components. This template was specifically designed for VoIP deployments and can simplify basic CoS implementations significantly.
www.juniper.net
The Resulting Configuration: Part 1

This slide shows a portion of the resulting configuration after the EZQoS template has been applied.
www.juniper.net
The Resulting Configuration: Part 2

This slide shows the remainder of the resulting configuration after the EZQoS template has been applied. Note that the EZQoS template does not include any rewrite rules. To ensure a consistent CoS implementation throughout the network and to allow downstream devices to perform proper BA classification, you should include rewrite rules on all core facing interfaces at a minimum. We covered rewrite rules earlier in this section and will illustrate how they are implemented with the EZQoS template in the next section.
www.juniper.net
Case Study
www.juniper.net
Objectives and Topology

This slide provides the objectives and topology information used for this case study.
www.juniper.net
Implementing the EZQoS Template

This slide illustrates the basic steps used to implement the EZQoS template on an EX Series switch. Note that although the configuration and monitoring steps for this case study are from AS-1s perspective, similar configuration and verification should be done on all devices within the network.
www.juniper.net
Adding a Rewrite Rule

As mentioned earlier, to ensure a consistent CoS implementation throughout the network and to allow downstream devices to perform proper BA classification, you should include rewrite rules on all core facing interfaces at a minimum. In this example we associate the default DSCP rewrite rule with all logical Gigabit Ethernet interfaces.
www.juniper.net
Monitoring the Results: Part 1

This slide shows some initial verification tasks. Here you can see that the new forwarding classes have been added. Note that there are now five forwarding classes and queues defined on AS-1; the four forwarding classes from the EZQoS template and one remaining default forwarding class, assured-forwarding, which is associated with queue 1.
www.juniper.net

This slide shows some commands and outputs used to further verify the correct application of the EZQoS template and the default DSCP rewrite rule.
www.juniper.net

This slide shows some commands and outputs used to verify scheduling parameters and statistics on AS-1s egress interface.
www.juniper.net

The purpose and basic operations of CoS; CoS features commonly used in Layer 2 networks; and Configuration and monitoring of CoS.
www.juniper.net
Review Questions
1. 2. 3.
www.juniper.net
Lab 5: Class of Service

www.juniper.net
www.juniper.net

Chapter 7: Monitoring and Troubleshooting

A basic troubleshooting method; Common issues that disrupt network operations; The tools used in network troubleshooting; and Using available tools to resolve network issues.
Chapter 72 Monitoring and Troubleshooting
www.juniper.net
Introduction to Monitoring and Troubleshooting

www.juniper.net
Monitoring and Troubleshooting Chapter 73
The Situation
You might have found yourself in a similar situation to the one highlighted on the slide. In these types of situations, you may ask yourself a number of questions such as: What is broken?, What has changed recently?, Is there really an issue or is it working as designed?, and Where do I begin? These are all relevant questions and there are a number of correct ways to approach these types of situations. We discuss a basic troubleshooting method throughout this section that can be applied to situations like the one illustrated on the slide.
www.juniper.net
A Basic Method for Troubleshooting

When beginning your troubleshooting, it is important to take a structured approach. In this chapter, we will be using the troubleshooting method outlined on the slide. Each step in this troubleshooting method is highlighted in detail on subsequent slides in this chapter.
www.juniper.net
Knowing Your Environment

To effectively troubleshoot a network you must be familiar with the network and know what is normal for your environment. There are many tools that allow you to get familiar with your environment. You can use tools, such as sFlow and SNMP, to monitor your network environment and even establish a baseline for that network environment. Note that we discuss sFlow and SNMP in further detail in a subsequent section in this chapter. In addition to the physical components in your network, you should also have a detailed understanding of the logical components and protocols in your environment. Without a detailed understanding your entire environment, troubleshooting issues can be a significant challenge and you may actually end up causing more problems by troubleshooting something that is operating as expected.
www.juniper.net
Gathering Information
Before attempting to fix a problem that may or may not exist, you should gather as much information as possible. When gathering information it is helpful to get answers to key questions relevant to the situation. The answers to these key questions should provide detailed information about the symptoms related to the issue. While talking to end users can provide some valuable information, it is also important to understand what other resources and tools you have available and use those additional resources to help gather relevant information. Ultimately it is the information gathered that will lead you to the problem and help you identify a solution. Typically the sooner you gather the relevant information for a given issue, the sooner you will be able to solve that issue and be able to get back to your video game or favorite YouTube video.
www.juniper.net
Understanding Symptoms and Layers

Recall that EX Series switches maintain a strict separation between the control plane and the data plane. When you characterize a problem, certain types of symptoms indicate the control plane as the most probable cause, whereas other symptoms indicate that the root cause ultimately lies in the data plane. In an established operating environment, it is extremely rare to find a fault in both planes simultaneously because of the different role that each plays. The control plane is responsible for installing routes and media access control (MAC) address entries into the forwarding table. This function relies on configuration, protocols, connection to peers and so on. The most common symptom of a control plane problem is incorrect or missing forwarding paths at Layer 2 and Layer 3. When in doubt, it is generally beneficial to determine whether the control plane is functioning properly before moving on to the data plane. The data plane uses the forwarding path information provided by the control plane to perform packet forwarding. The most common symptoms of a data plane issue are physical errors, intermittent connectivity and dropped packets. Problems in the data plane can result from faulty hardware or configuration-based issues such as firewall filters, policers, and so forth. Note that intermittent issues and bottlenecks almost always trace back to the data plane. Understanding how symptoms relate to the various layers in a modeled structure, such as the Open Systems Interconnection (OSI) and TCP models, and the control and data planes on EX Series switches can speed-up your troubleshooting efforts in many cases.
www.juniper.net
Hardware Troubleshooting Flowchart

The artistic aspect of troubleshooting and the various ways in which a modern communications device might malfunction combine to make a definitive set of troubleshooting steps and procedures an unobtainable goal. The purpose of the hardware troubleshooting flowchart shown on the slide is simply to provide a set of high-level steps designed to get you started with hardware fault analysis. Note that reasonable people might disagree on the exact ordering of the steps or the particular command-line interface (CLI) commands used to help isolate a hardware failure (for example, some might prefer the extensive option to the show interfaces command, whereas the sample chart calls out the terse and detail options).
www.juniper.net
Software Troubleshooting Flowchart

The purpose of the software troubleshooting flowchart shown on the slide is simply to provide a set of high-level steps designed to get you started on the path of software-related troubleshooting. Note that as with the hardware flowchart, reasonable people might disagree on the exact ordering of the steps or on the particulars of the CLI commands used to help isolate a software failure. Note that it is sometimes necessary to execute the same command multiple times over a brief period of time to see patterns or indications of problems. In some situations, configuration errors can appear as a software issue. The commands used to investigate configuration errors depends on the reported symptoms. As an example, the commands
you use to troubleshoot symptoms related to 802.1X will not be the same commands you use to troubleshoot symptoms related to MSTP. Because of the number of possible scenarios that could involve configuration errors, we do not provide the related CLI commands.
Some software issues may be related to a malfunctioning process. The slide also outlines some of the key Junos processes used on EX Series switches. These processes are responsible for individual functions including chassis and interface control as well as operations related to routing and switching. These process can be restarted using the CLI, but this should only be used as a last resort. Restarting a process might resolve an issue, but it makes determining the root cause very difficult. Restarting a process can also have a cascading and adverse effect on other process that may impact the switch or even the network as a whole.
www.juniper.net
System Logging and Traceoptions

You can use the system logging and traceoptions features on EX Series switches to gather useful information when troubleshooting hardware and software issues. This slide provides a basic review of each of these features along with configuration examples. System logging (syslog) uses a UNIX syslog-style mechanism to record system-wide, high-level operations and events, such as interfaces going up or down or users logging in to or out of the device. The Junos OS places the resulting log messages in files stored in the /var/log directory or can send the log messages to a remote server. The primary syslog file, which is included in all factory-default configurations, is the /var/log/messages file. When using traceoptions, you create a trace file that is used to store decoded protocol information received or sent by the Routing Engine (RE). As shown in the configuration example on the slide, you identify the types of messages you want logged to the trace file using traceoption flags. The Junos OS sends the tracing results to a specified file stored in the /var/log directory or to a remote syslog server. You can enable traceoptions at various hierarchies to capture detailed information pertaining to a specific protocol or feature.
www.juniper.net
Routing Engine Information

The overall health of a networking device often has a lot to do with the stability of its control plane and its dedicated resources. On EX Series switches, the RE is responsible for all control plane functions. The RE has dedicated memory and a CPU to support the various control plane functions. As with any resource, the REs memory and CPU cycles may become consumed beyond a sustainable point. If the REs memory and CPU become overwhelmed, the stability of the system, and potentially the entire network, may be in jeopardy. Although this is not typical, high memory and CPU utilization can impact the performance and overall operations of the running processes and can potentially cause those processes to fail. Note that in environments that are well designed and implemented correctly, RE CPU and memory utilization are typically maintained at a sustainable level. The utilization levels vary and are dependant on the devices configuration and processing load.
www.juniper.net
Process Failures
The software used on todays networking devices can be exceedingly complex. As a result, equally complex bugs that result from unforeseen circumstances can result in a fatal error within a software process. Most of these software faults relate to illegal memory operations caused by the process attempting to read or write data from a memory area outside the boundaries allocated for that process. In some cases, faulty hardware, such as failing memory, can cause stack or register corruption that leads to a fatal error in a software process. Core and log file analysis are used to determine whether hardware errors have led to a software panic. A core file represents the set of memory locations and stack data that was in place at the time of the fault. The core file that is generated is stored in the /var/tmp file system directory and is named in the process-name.core-tarball.core-number.tgz format. Secondary core files might be generated in the /var/crash/kernel directory as well depending on what process was involved in the core. You can easily verify if your device has core files stored on it by executing the show system core-dumps command from operational mode. If your system has generated a core file, you can contact the Juniper Networks Technical Assistance Center (JTAC) support team to assist with decoding the core file and to identify the root cause.
www.juniper.net
Creating an Action Plan

It is important to outline possible causes that correlate with the known symptoms identified in the previous step. Many common network issues fall into the following three categories: Physical: Physical issues can include, but are not limited to, faulty hardware as well as faulty cabling or fiber. Software: Software issues are often referred to as bugs and are problems in the software coding. Configuration: Configuration issues could be as simple as a missed virtual LAN (VLAN) tag or more complicated like a spanning tree setting that affects the entire network.
After narrowing down the problem, you can create a plan to prove or disprove the possible cause. Each plan should include the steps to prove or disprove the possible cause and how success is defined. It is also a good idea to have a contingency plan just in case the changes associated with a test make the situation worse. A good action plan allows you to revert back to the previous state in a short amount of time.
www.juniper.net
Testing Possible Solutions

The final step in this basic troubleshooting method is to execute the proposed test that you outlined in the previous step. If a given test does not resolve the issue, it is recommended that you remove any changes associated with that test and move on to the next test from the original starting point. This process will help keep your configuration clean and may help you avoid any unexpected issues later on. If none of your tests resolve the issue, you should return to step one and gather additional information. You might need to go through this entire troubleshooting process multiple times before identifying the resolution to the problem. If you have exhausted all of your local resources, you may consider working with JTAC. We discuss some key considerations when working with JTAC on the next slides.
www.juniper.net
Working with JTAC: Part 1

In some cases, you may need help identifying and resolving issues. You can open a support case with JTAC to get help from Juniper Networks support engineers. For non critical issues it is recommended that you open the case using the web portal located at www.juniper.net/cm. Alternatively, for critical issues it is recommended you call JTAC directly to open a new case. You should provide as much detail as you can about the issue and what steps have already been carried out. It is also a very good time to attach any relevant outputs from the affected devices. By providing as much detail about the issue and supplying the relevant outputs up front, JTAC should have a better understanding of the issue initially and be able to provide a resolution more quickly.
www.juniper.net
Working with JTAC: Part 2

When working with JTAC, you can avoid unnecessary delay by providing as much relevant information as possible when you open a support case. In addition to the outputs and details you feel are relevant to the problem, there are some standard outputs that JTAC typically request. The commands used to capture the standard outputs requested by JTAC are outlined on the slide. JTAC may request that you gather the same output several times to illustrate historical values, like incrementing traffic statistics, dropped packet counters, and incrementing errors. To help illustrate the time between each instance of a specific command, you can use the set cli timestamp command in operational mode to generate a timestamp at the beginning of each CLI output. A sample capture showing the generated timestamp is illustrated on the slide.
www.juniper.net
Monitoring and Troubleshooting Tools

www.juniper.net
Troubleshooting Tools
The Junos OS offers several tools that can be used when troubleshooting. We highlighted various CLI commands that can be used to monitor system operations as well as the system logging and traceoptions features in the preceding section. We cover the remaining tools listed on the slide in this section.
www.juniper.net
SNMP
The Junos OS supports Simple Network Management Protocol (SNMP) which can be used with a wide variety of network management systems (NMSs) to collect information and establish a meaningful baseline. SNMP defines a set of standards for network management including a protocol, a database structure specification, and a set of data objects that facilitate communications between an SNMP agent running on a managed device (like an EX Series switch) and an NMS. SNMP can be used to monitor various parameters such as CPU utilization, memory utilization, CPU temperature, interface throughput, and so on. SNMP gathers this system information by sending a GetRequest to the agent device. The agent device can send a variety of different SNMP trap message to the NMS indicating that there has been an unexpected event on the local system. You can also configure the local system to monitor the health of key components. When a threshold is exceeded, the system reports this information using trap messages to the NMS. When configuring health-monitor on a device, you can define the interval that the system checks the current values against thresholds. These thresholds can also be explicitly defined or you can use the default values. Additional information regarding the health-monitor feature can be found in KB16450, by entering this number in the KB field at http://kb.juniper.net.
www.juniper.net
sFlow Monitoring: Part 1

The sFlow (RFC 3176) technology is designed for monitoring high-speed switched or routed networks and provides visibility into the types of traffic in those networks. sFlow is a statistical sampling-based network monitoring technology that samples network packets and sends those samples to a monitoring station, known as a collector. Once the samples are received by the collector, the network administrator can determine network behaviors, traffic patterns, and detect anomalies in traffic flows. The sFlow agent is typically embedded in a switchs application-specific integrated circuit (ASIC) hardware, where it collects different samples at regular intervals. The datagrams are sent at regular intervals to the sFlow collector whose address is configured as an IP address and UDP port pair. The collector reads the datagram, estimates the traffic pattern, and generates a traffic report. The sFlow technology provides Layer 2-7 visibility. The sFlow agent does sampling in two phases, packet flow sampling, which consists of statistical data gathered from individual flows, and counter sampling, which involves the periodic polling of counters to gather interface data. Flow samples are then bundled into a datagram and the datagrams are sent out to the collector using the default UDP port 6343. Counter sampling is done at regular intervals to provide details about the interfaces, backplane, and so on. Communication between the agent and the collector is bidirectional; the agent sends datagrams to the collector, while the collector might configure some SNMP variables on the sFlow agent or might read some of the SNMP Management Information Base (MIB) using UDP packets, as they work efficiently in times of congestion. Continued on the next page. www.juniper.net Monitoring and Troubleshooting Chapter 721
sFlow Monitoring: Part 1 (contd.)

Up to four collectors can be configured on each EX Series switch, and each collector can receive the same set of sFlow data record samples. As mentioned earlier, the sFlow data record samples are sent as UDP packets. You can change the UDP port being used by modifying the configuration. The polling interval is also configurable and is defined as the interval between each port statistic polling update message, which can range from 0 to 3600 seconds. The sample rate means one out of every n packets in the traffic stream will be sampled. The range of sample rate is from 100 to 1 million. Only network Gigabit Ethernet or 10-Gigabit Ethernet ports able to accommodate routed traffic can be used for exporting sFlow data records from an EX Series switch towards the collector. Currently EX Series switches cannot export sFlow data records out the management Ethernet interface (me0) or virtual management interface (vme0).
www.juniper.net
sFlow Monitoring: Part 2

This slide provides an example scenario for configuring sFlow monitoring. The objective is to sample traffic entering switch-1s ge-0/0/1 interface and export the sFlow data records to the collector, which has the IP address 10.10.10.254. The default configuration values have been used for the polling interval, sample rate, and UDP port in this configuration example. Although not illustrated, switch-1 requires routing information for the 10.10.10.254 destination which in this case would be reachable through ge-0/0/10.
www.juniper.net
Port Mirroring: Part 1

The port mirroring feature allows you to analyze traffic passing through an EX Series switch. You can use port mirroring to monitor traffic for such purposes as network usage policy enforcement and to identify the source of problems on your network by locating abnormal or heavy bandwidth usage from particular stations or applications. Port mirroring is needed for traffic analysis on a switch because a switch, unlike a hub, does not broadcast packets to every port on the device. The switch mirrors and sends packets only out designated ports that you define. The mirrored packets are sent to and analyzed on a connected device using a protocol analyzer application. The protocol analyzer application can run either on a computer connected to the analyzer output interface or on a remote monitoring station. You can configure port mirroring to send copies of unicast traffic to either a local analyzer port or an analyzer VLAN. A configuration example is provided on a subsequent slide. We recommend that you disable port mirroring when you are finished troubleshooting and that you define specific interfaces to mirror the traffic on instead of using the all keyword option. You can also limit the amount of mirrored traffic by using statistical sampling, setting a ratio to select a statistical sample, or using a firewall filter to mirror only packets matching certain criteria. Mirroring only the necessary packets reduces any potential performance impact. Continued on the next page.
www.juniper.net
Port Mirroring (contd.)

You can use port mirroring on a switch to mirror any of the following: Packets entering or exiting a port: You can mirror the packets in any combination (on up to 256 ports). For example, you can send copies of the packets entering some ports and the packets exiting other ports to the same local analyzer port or analyzer VLAN. Packets entering a VLAN on an EX2200, EX3200, EX4200, or EX4500 switch: You can mirror the packets entering a VLAN on these switches to either a local analyzer port or to an analyzer VLAN. (On EX3200, EX4200, and EX4500 switches, you can configure multiple VLANs (up to 256 VLANs), including a VLAN range and Private VLANs (PVLANs), as ingress input to an analyzer.) Packets exiting a VLAN on an EX8200 switch: You can mirror the packets exiting a VLAN on an EX8200 switch to either a local analyzer port or to an analyzer VLAN. You can configure multiple VLANs (up to 256 VLANs), including a VLAN range and PVLANs, as egress input to an analyzer.
www.juniper.net
Port Mirroring: Part 2

This slide provides an example scenario for configuring port mirroring. The objective is to mirror all incoming packets from both employee A and employee B. You begin by creating an analyzer profile, in the example the profile name is employee-monitor. Next, you define the interfaces to be monitored and add them as the input source for the analyzer profile. Note that the ingress keyword is used to indicate that incoming packets are to be mirrored. Finally, the output interface needs to be specified. This interface is where the mirrored packets will be sent out to the packet analyzing device. Note that this is a basic configuration example and you can find additional examples of port mirroring in more complex situation by reviewing the technical documentation for your particular version and device.
www.juniper.net
Troubleshooting Case Studies: Reachability Issues

www.juniper.net
Topology, Symptoms, and Relevant Information

This slide outlines the network topology, reported symptoms, and other helpful information. In this case study, end users have reported reachability issues to a remote file server. One of the end users, Employee A, is able to communicate with the gateway router, but not the remote router or file server. It has been verified that R1 and R2 both have the required routes in place to the remote subnets but they cannot communicate with destination devices in those remote subnets or each other for that matter. The switch, connecting R1 and R2, has been configured with port mirroring to capture all incoming packets on ge-0/0/6 and ge-0/0/10 and to send those packets out ge-0/0/15 to the analyzer (Laptop running packet capturing software).
www.juniper.net
Interface Status
Start by verifying that the interfaces are up and functioning. This can easily be verified using the show interfaces terse command. As illustrated on the slide the relevant interfaces are Admin up and Link up. The interfaces are also configured for ethernet-switching which indicates that it is operating at layer 2.
www.juniper.net
Mirrored Packets
Next, a continuous ping is started on the Employee A device with the file server as the destination. The slide displays the traffic captured and indicates that: The packets are all ICMP Echo requests sourced from 10.10.10.2 (Employee A device) and destined to 12.12.12.2 (remote file server). Note that there is no return traffic. All packets are being sent from R1 with a VLAN tag value of 105.
www.juniper.net
Verify VLAN Assignments and Port Mode

Using the commands and generated output illustrated on the slide, you can see that ge-0/0/6.0 and ge-0/0/10.0 are both associated with VLAN v105 which is assigned a VLAN tag of 105. You can also tell from this output that both of these interfaces are active because of the inclusion of the asterisk (*) next to both interfaces in the output from the show vlans command. One additional piece of information that may not be so obvious is that only ge-0/0/10.0 is a tagged interface. This value is characteristic of interfaces configured for access mode (the default port mode). To allow ge-0/0/6.0 to receive tagged frames, it must be configured for trunk mode. We verify if changing the port mode on ge-0/0/6.0 to trunk mode resolves the issue on the next slide.
www.juniper.net
Test Possible solutions

The next step is to test the possible solution. The slide shows the port is now configured for trunk mode. The packet capture from the analyzer verifies that traffic from the Employee A device is now reaching the file server. The capture displays packets being sourced from the employee as well as return traffic which is sourced from the server.
www.juniper.net
Troubleshooting Case Studies: Network Congestion

www.juniper.net
Topology, Symptoms, and Relevant Information

This slide outlines the network topology, reported symptoms, and other helpful information. In this case study, users connected to AS-1 and AS-2 have been complaining for some time now about latency and congestion when accessing resources through the network. You and your team have recently implemented MSTP to load balance traffic from the various user groups (VLANs). The recent change should distribute the traffic from the various user groups between two separate paths in the network. One path should use DS-1 as the root bridge while the other path should use DS-2 as the root bridge. The end users have observed no difference in performance since the configuration was changed and continue to complain about congestion. You have been asked to investigate the situation and ensure load balancing is in effect.
www.juniper.net
Verify Root Bridge Elections

One approach when troubleshooting this type of an issue would be to start from a point close to the end users and work outward from that point. In this example we do just that and start by verifying which devices are being elected as the root bridge for the different MSTI instances from AS-1s perspective. As shown in the sample output on the slide that is taken from AS-1, the root bridge for the user-defined instances is DS-2 (note that AS-1 connects to DS-2 using ge-0/0/10.0).
www.juniper.net
Review the MSTP Configuration

To effectively troubleshoot this issue you must be familiar the protocol operations and requirements for MSTP. The lecture and lab focusing on MSTP should provide you with the required knowledge to troubleshoot and resolve the issue presented in this case study. A quick look at the show spanning-tree mstp configuration output on AS-1 and DS-1 helps identify a potential issue. As shown on the slide, the configuration digests on AS-1 and DS-1 do not match. Remember from the MSTP lecture and lab that this digest must be the same across all device in the same region. The configuration digest is comprised of the region name, revision level, and MSTI to VLAN-ID mappings. If you pay special attention to the output, you can see that there is a VLAN member mismatch between the two devices, which may be the cause of our current problem. We verify if changing the VLAN members associated with MSTI 1 fixes the issue on the next slide.
www.juniper.net
Testing the Possible Solution

This slide shows the updated configuration used to test the theory identified on the last slide. Once the illustrated configuration is in place on DS-1 all four switches illustrated in the diagram should participate in the same MSTP region. Once all four switches are participating in the same MSTP region, we should see DS-1 elected as root bridge for MSTI 1 which services VLAN-IDs 10 through 19. We verify the results of this configuration change on the next slide.
www.juniper.net
Verify Results
Now that the four switches are configured to participate in the same MSTP region, we verify the root bridge elections for the defined MSTIs using the show spanning-tree interface command. The sample output shown on the slide now shows that AS-1 considers DS-1 as root bridge for MSTI1 (AS-1 connects to DS-1 using ge-0/0/8.0) and considers DS-2 as root bridge for MSTI2 (AS-1 connects to DS-2 using ge-0/0/10.0). Now that DS-1 and DS-2 are functioning as root bridges for their respective MSTIs, you should see end-user traffic distributed between the available paths and the complaints about congestion should subside (at least for now).
www.juniper.net

A basic troubleshooting method; Common issues that disrupt network operations; The tools used in network troubleshooting; and Using available tools to resolve network issues.
www.juniper.net
Review Questions
1. 2. 3.
www.juniper.net
Lab 6: Monitoring and Troubleshooting

www.juniper.net
www.juniper.net
Appendix A: Acronym List

AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . authentication, authorization, and accounting ANSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . American National Standards Institute ASIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .application-specific integrated circuit BA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . behavior aggregate BPDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bridge protocol data unit BUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . broadcast, unicast with unknown destination, and multicast CDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cisco Discovery Protocol CFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Canonical Format Indicator CIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . common and internal spanning tree CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .command-line interface CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .class of service CST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . common spanning tree C-TAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .customer VLAN tag DAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic ARP Inspection DEI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Drop Eligibility Indicator DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Dynamic Host Configuration Protocol DoS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . denial of service DSCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DiffServ code point E-LMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ethernet local management interface EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extensible Authentication Protocol EAP-MD5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extensible Authentication Protocol-Message Digest 5 EAPoL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extensible Authentication Protocol over LAN EVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ethernet virtual connection GARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic Attribute Registration Protocol GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .graphical user interface GVRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GARP VLAN Registration Protocol IEEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Institute of Electrical and Electronics Engineers IETF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Engineering Task Force JNCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Juniper Networks Certification Program JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Juniper Networks Technical Assistance Center L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Layer 2 protocol tunneling LACP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Link Aggregation Control Protocol LDAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lightweight Directory Access Protocol LFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . link fault management LLDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link Layer Discovery Protocol LLDP-MED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Link Layer Discovery Protocol-Media Endpoint Discovery MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .media access control MF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .multifield MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management Information Base MMRP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multiple MAC Registration Protocol MRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Multiple Registration Protocol MST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .multiple spanning tree MSTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Multiple Spanning Tree Protocol MVRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multiple VLAN Registration Protocol NMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .network management system OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operation, Administration, and Maintenance OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Systems Interconnection PD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . powered device PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .protocol data unit PLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .packet loss priority PoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power over Ethernet PoE+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power over Ethernet Plus PSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . power sourcing equipment PVLAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Private VLAN PVST+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Per-VLAN Spanning Tree Plus www.juniper.net Acronym List Appendix A1
RE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Engine RPVST+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rapid-PVST+ RSTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rapid Spanning Tree Protocol SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simple Network Management Protocol SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structured Query Language S-TAG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . service VLAN tag STI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . spanning-tree instance STP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Spanning Tree Protocol TIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Telecommunications Industry Association TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . type/length/value TPID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Tag Protocol Identifier TTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . time to live UDLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unidirectional Link Detection VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual LAN VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .voice over IP VSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vendor-specific attribute VSTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .VLAN Spanning Tree Protocol VTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VLAN trunking protocol WRED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .weighted random early detection WTD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . weighted tail drop
Appendix A2 Acronym List
www.juniper.net
Appendix B: Answer Key

Chapter 1: Course Introduction
This chapter contains no review questions.
Chapter 2:
Advanced Ethernet Switching

1. Filter-based VLAN assignments are useful when you have traffic entering a single access port that needs to be assigned to different VLANs depending on specific attributes, such as source IP address. 2. PVLANs are used when traffic associated with a single broadcast domain needs to be restricted. For example, you might have multiple workgroups participating on the same network but you do not want those workgroups to communicate with each other directly. 3. MVRP dynamically manages VLAN registration in a LAN. MVRP helps reduce administration and network overhead by dynamically pruning VLAN information when a switch no longer has active interfaces for a configured VLAN. In addition to the pruning functionality, MVRP can also be used to dynamically create VLANs in switching networks. 4. L2PT allows you to send Layer 2 PDUs across a service provider network and between customer edge switches connected through a service provider network. L2PT is useful when you want to run Layer 2 protocols on a network that includes switches located at remote sites that are connected across a service provider network.
Chapter 3:
Advanced Spanning Tree

1. While RSTP provides several advantages over STP neither of these protocols allow for load balancing, which in some environments is a requirement. In environments where RSTP or STP is used, all VLANs within a LAN share the same spanning tree, which limits the number of forwarding paths for data traffic. 2. The CIST is a single topology that connects all switches (RSTP and MSTP devices) through an active topology. The CIST includes a single spanning tree as calculated by RSTP together with the logical continuation of connectivity through MST regions. MSTP calculates the CIST and the CIST ensures connectivity between LANs and devices within a bridged network. 3. MSTP ensures that your network does not slow down from the increased network traffic caused by hundreds of VLANs, each with its own spanning-tree instance. MSTP sends a single BPDU regardless of the number of instances used whereas VSTP sends a separate BPDU for each VLAN configured on the switch which can add a significant load on a switchs CPU.
www.juniper.net
Answer Key Appendix B1
Chapter 4:
Authentication and Access Control

1. Supplicants are authenticated in either single mode, single-secure mode, or multiple mode. The single supplicant mode authenticates only the first supplicant and allows all subsequent supplicants full network access without requiring authentication. The single-secure supplicant mode allows only one supplicant to connect to the port and rejects all other requests until the first supplicant logs out. The multiple supplicant mode allows multiple supplicants to authenticate through the port individually. 2. MAC RADIUS is an ideal replacement when the supplicants requesting network access do not support 802.1X client software. Some examples of non-802.1X capable devices include printers and some IP phones. 3. When an end-user device opens a Web browser and points to a remote website, the connected switch, with the captive portal feature enabled, intercepts the request and presents the user with the captive portal login HTML page. The captive portal login HTML page requests the user's user name and password. If the user is authenticated, the user's original Web-page request and subsequent access to the network is permitted. If the user is not authenticated, the users original Web-page request is denied along with all other network access.
Chapter 5:
Deploying IP Telephony Features

1. An IP telephony deployment might use one or more switch ports to accommodate the data and voice traffic for a single user. In some deployments the IP phone and the end-user device use the same switch port while in other deployments the IP phone and the end-user device use separate switch ports. The most common deployment scenario today uses a single port to accommodate the voice and data needs for end users. 2. PoE provides up to 15.4 W of power to a powered device. After line loss powered device receive approximately 12.95 W of power. PoE+ increases the amount of power to 30 W. After line loss powered devices receive approximately 25.5 W. The PoE+ standard provides support for legacy PoE devicesan IEEE 802.3af (PoE) powered device can operate normally when connected to IEEE 802.3at (PoE+) power sourcing equipment. 3. LLDP-MED is used to provide network policy discovery, power negotiation, and location discovery. Note that these services are provided through the exchange of TLVs within the LLPDU frames. 4. The voice VLAN feature allows access ports to accept both untagged (data) and tagged (voice) traffic and separate that traffic into different VLANs. You can also use the voice VLAN feature for traffic classification purposes.
Chapter 6:
Class of Service
1. The default BA classifier for access ports is based on the assumption that any and all code-point patterns cannot be trusted whereas the default BA classifier for trunk ports assumes that code-point patterns can be received. All traffic received from access ports is classified as best effort traffic and associated with queue 0 on the egress interfaces. On trunk ports, using the default BA classifier, traffic can be classified as either best effort or network control traffic based on the code-point patterns.
Appendix B2 Answer Key
www.juniper.net
2. Only queues 0 and 7 are serviced by the default scheduler map on an EX 4200 Series switch. Queue 0 receives 95 percent of the bandwidth and buffer while queue 7 receives the remaining 5 percent. 3. Both policers and shapers are used to limit the rate of traffic passed through output queues. Policers can drop or modify the PLP for packets above a specified rate. Policing is supported for incoming traffic only and is configured under the [edit firewall] hierarchy and applied directly to interfaces defined under the [edit interfaces] hierarchy. Port shapers defines the maximum bandwidth allocated to a port, while queue shaping defines a limit at which queues transmit packets. All configuration for port and queue shaping is defined under the [edit class-of-service] hierarchy.
Chapter 7:
Monitoring and Troubleshooting

1. Issues requiring troubleshooting can typically be categorized as either hardware, software, or configuration issues. 2. sFlow is a statistical sampling-based network monitoring technology that samples network packets and sends those samples to a monitoring station, known as a collector. Once the samples are received by the collector, the network administrator can determine network behaviors and traffic patterns, and can detect anomalies in traffic flows. 3. The port mirroring feature allows you to analyze traffic passing through an EX Series switch. You can use port mirroring to monitor traffic for such purposes as network usage policy enforcement and to identify the source of problems on your network by locating abnormal or heavy bandwidth usage from particular stations or applications.
www.juniper.net
Answer Key Appendix B3
Appendix B4 Answer Key
www.juniper.net

Advanced Junos Enterprise Switching: Student Guide

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Advanced Junos Enterprise Switching: Student Guide

Загружено:

Авторское право:

Доступные форматы

Advanced Junos Enterprise Switching

Worldwide Education Services

Chapter 3: Advanced Spanning Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Chapter 4: Authentication and Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Chapter 5: Deploying IP Telephony Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

Chapter 6: Class of Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1

Chapter 7: Monitoring and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

Appendix A: Acronym List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1 Appendix B: Answer Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

GUI text elements: Menu names Text field entry

Input Text Versus Output Text

Defined and Undefined Syntax Variables

Document Conventions vii

About This Publication

Juniper Networks Support

viii Additional Information