Beruflich Dokumente
Kultur Dokumente
10.b
Student Guide
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
www.juniper.net
Contents iii
iv Contents
www.juniper.net
Course Overview
This two-day course provides detailed coverage of virtual LAN (VLAN) operations, Multiple Spanning Tree Protocol (MSTP) and VLAN Spanning Tree Protocol (VSTP), authentication and access control for Layer 2 networks, IP telephony features, class of service (CoS) and monitoring and troubleshooting tools and features supported on the EX Series Ethernet Switches. Through demonstrations and hands-on labs, students will gain experience in configuring and monitoring the Junos operating system and in monitoring device and protocol operations.
Objectives
After successfully completing this course, you should be able to: Implement filter-based VLAN assignments. Restrict traffic flow within a VLAN. Manage dynamic VLAN registration. Tunnel Layer 2 traffic through Ethernet networks. Review the purpose and operations of a spanning tree. Implement multiple spanning tree instances in a network. Implement one or more spanning tree instances for a VLAN. List the benefits of implementing end-user authentication. Explain the operations of various access control features. Configure and monitor various access control features. Describe processing considerations when multiple authentication and access control features are enabled. Describe some common IP telephony deployment scenarios. Describe features that facilitate IP telephony deployments. Configure and monitor features used in IP telephony deployments. Explain the purpose and basic operations of class of service. Describe class of service features used in Layer 2 networks. Configure and monitor class of service in a Layer 2 network. Describe a basic troubleshooting method. List common issues that disrupt network operations. Identify tools used in network troubleshooting. Use available tools to resolve network issues.
Intended Audience
This course benefits individuals responsible for configuring and monitoring EX Series switches.
Course Level
Advanced Junos Enterprise Switching is an advanced-level course.
Prerequisites
Students should have an intermediate-level of networking knowledge and an understanding of the Open Systems Interconnection (OSI) reference model and the TCP/IP protocol suite. Students should also attend the Introduction to the Junos Operating System (IJOS), the Junos Routing Essentials (JRE), and the Junos Enterprise Switching (JEX) courses prior to attending this class.
www.juniper.net
Course Overview v
Course Agenda
Day 1
Chapter 1: Course Introduction Chapter 2: Advanced Ethernet Switching Lab 1: Advanced Ethernet Switching 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.
Select File > Open, and then click Configuration.conf in the Filename text box.
GUI Undefined
www.juniper.net
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/.
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.
www.juniper.net
www.juniper.net
Introductions
The slide asks several questions for you to answer during class introductions.
www.juniper.net
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
www.juniper.net
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
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
www.juniper.net
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
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
www.juniper.net
www.juniper.net
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
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
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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
www.juniper.net
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
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Review Questions
1. 2. 3. 4.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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
www.juniper.net
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
www.juniper.net
www.juniper.net
www.juniper.net
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
www.juniper.net
www.juniper.net
www.juniper.net
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
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
www.juniper.net
www.juniper.net
www.juniper.net
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
www.juniper.net
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
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
www.juniper.net
www.juniper.net
www.juniper.net
Review Questions
1. 2. 3.
www.juniper.net
www.juniper.net
www.juniper.net
Authentication Overview
The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
www.juniper.net
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
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
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
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
www.juniper.net
www.juniper.net
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
www.juniper.net
www.juniper.net
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
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Monitoring 802.1X
This slide displays some common operational mode commands used to monitor 802.1X.
www.juniper.net
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
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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
3.
www.juniper.net
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
www.juniper.net
Review Questions:
1. 2. 3.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Deployment Scenarios
The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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
www.juniper.net
www.juniper.net
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.
www.juniper.net
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
www.juniper.net
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
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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
www.juniper.net
www.juniper.net
www.juniper.net
Review Questions
1. 2. 3. 4.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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
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
www.juniper.net
www.juniper.net
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
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Case Study
The slide highlights the topic we discuss next.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Review Questions
1. 2. 3.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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
www.juniper.net
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
www.juniper.net
www.juniper.net
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
www.juniper.net
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
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
www.juniper.net
www.juniper.net
www.juniper.net
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
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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
www.juniper.net
Review Questions
1. 2. 3.
www.juniper.net
www.juniper.net
www.juniper.net
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
www.juniper.net
Chapter 2:
Chapter 3:
www.juniper.net
Chapter 4:
Chapter 5:
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.
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:
www.juniper.net
www.juniper.net