Table of Contents
Advertisement
Quick Links
This chapter describes the QoS feature as it is implemented on the Matrix N‐Series Switch/Router,
SecureStack, and Secure Switch.
For information about...
What Is Quality of Service?
Why Would I Use It in My Network?
How Can I Implement Quality of Service?
Quality of Service Overview
Understanding QoS Configuration on the Matrix N-Series
Feature Differences
The QoS CLI Command Flow
QoS Configuration Example
Terms and Definitions
What Is Quality of Service?
Quality of Service (QoS) is:
•
A mechanism for the management of bandwidth
•
The ability to give preferential treatment to some packets over others
•
Based upon packet classification and forwarding treatment
You configure packet preference and forwarding treatment based upon a flow's sensitivity to
delay, delay variation (jitter), bandwidth, availability and packet drop. QoS uses packet priority, in
conjunction with queue treatment configuration, to determine the interface's inbound and
forwarding behavior for this packet. Packet preference and forwarding treatment for a given flow
can be applied to roles configured in Enterasys policy.
Why Would I Use It in My Network?
Without QoS, all packets are treated as though the delivery requirements and characteristics of
any given packet are equal to any other packet. In other words, non‐QoS packet delivery is not
able to take into account application sensitivity to packet delay, jitter, amount of bandwidth
February 22, 2008
Note: Please see the Enterasys Matrix™ X Secure Core Router Configuration Guide for a
complete discussion of QoS as it applies to the Matrix X-Series.
QoS Configuration
Refer to page...
1
1
2
2
9
20
21
23
28
Page 1 of 29
Advertisement
Table of Contents
Related Manuals for Enterasys Matrix 7G4270-09
Summary of Contents for Enterasys Matrix 7G4270-09
-
Page 1: Qos Configuration
This chapter describes the QoS feature as it is implemented on the Matrix N‐Series Switch/Router, SecureStack, and Secure Switch. Note: Please see the Enterasys Matrix™ X Secure Core Router Configuration Guide for a complete discussion of QoS as it applies to the Matrix X-Series. For information about... What Is Quality of Service? Why Would I Use It in My Network? -
Page 2: Quality Of Service Overview
How Can I Implement Quality of Service? required, packet loss, or availability requirements of the flow. QoS provides management mechanisms for these flow characteristics. QoS achieves its bandwidth management capabilities by: • Setting priorities that define traffic handling • Dedicating bandwidth and prioritizing queuing for specific applications, and reducing packet transmission delay and jitter • Managing congestion by shifting packet loss to applications that can tolerate it How Can I Implement Quality of Service? QoS determines how a flow will be treated as it transits the link. To determine how a flow should be treated, you must first understand the characteristics of the flows on your network, and secondly, you must identify these flows in a way that QoS can recognize. In this sense, QoS is the third step in a three step process. The three‐steps Enterasys recommends for configuring QoS are: • Understand your network flows using NetFlow • Associate the flows on your network with a well defined role using Enterasys policy • Configure the appropriate link behavior for that role by associating the role with a QoS configuration Quality of Service Overview QoS is all about managing the bandwidth in a manner that aligns the delivery characteristics of a given flow with the available port resources. In a QoS context, a flow is a stream of IP packets that are classified with the same class of service as it transits the interface. QoS manages bandwidth for each flow by taking advantage of its ability to: • Assign different priority levels to different packet flows •... -
Page 3: Cos Priority And Tos Rewrite
Quality of Service Overview • Priority Transmit Queue (TxQ) with configurable forwarding behavior • In‐bound and/or outbound rate Limiter (IRL) per transmit queue • Outbound rate shaper per transmit queue The CoS configuration for each service can be easily viewed using the CoS setting tables. Ports are bundled into port groups with the group assigned to a CoS, significantly cutting down on operational overhead and complexity. CoS Priority and ToS Rewrite The two parameters configurable for CoS priority are 802.1p and Type of Service (ToS). Each CoS can be mapped to an 802.1p priority and a ToS rewrite value. The 802.1p parameter is: • A subset of ToS with values 0–7 (upper 3 bits of the 8 bit ToS field) • Supported in both layer 2 and layer 3 The ToS parameter is: • An 8‐bit field with values 0–255 • Supported in layer 3 only • Also referred to as the Differentiated Services Code Point (DSCP) when limited to the lower 5 bits of the field Figure 1 displays the relationship between your application, priority level, 802.1p, and ToS assignments (shown here using DSCP terminology). QoS priority/ToS configuration: • Derives its characteristic requirements from the end‐system application. • Is configured on the edge device the application is connected to •... -
Page 4: Preferential Queue Treatment For Packet Forwarding
Quality of Service Overview Figure 1 Assigning and Marking Traffic with a Priority The ICMP protocol, used for error messaging, has a low bandwidth requirement, with a high tolerance for delay and jitter, and is appropriate for a low priority setting. HTTP and FTP protocols, used respectively for browser‐generated and file transfer traffic, have a medium to high bandwidth requirement, with a medium to high tolerance for delay and jitter, and are appropriate for a medium priority level. Voice (VoIP), used for voice calls, has a low bandwidth requirement, but is very sensitive to delay and jitter and is appropriate for a high priority level. See RFC 1349 for further details on ToS. See RFCs 2474 and 2475 for further details on DSCP. Preferential Queue Treatment for Packet Forwarding There are three types of preferential queue treatments for packet forwarding: strict, weighted fair, and hybrid. Strict Queuing With Strict Priority Queuing, a higher priority queue must be empty before a lower priority queue can transmit any packets. Strict queuing is depicted in Figure upper left and proceed to the appropriate queue, based upon the TxQ configuration in the CoS. Outbound packets exit the queues on the lower right. At this time only queue 3 packets are forwarded. This will be true until queue 3 is completely empty. Queue 2 packets will then be forwarded. Queue 1 packets will only forward if both queue 2 and queue 3 are empty. Queue 0 packets will only forward if all other queues are empty. Strict queuing assures that the highest priority queue with any packets in it will get 100 percent of the bandwidth available. This is particularly useful for one or more priority levels with low bandwidth and low tolerance for delay. The problem with strict queuing is that should the higher level queues never fully empty, lower level queues can be starved of bandwidth. ... -
Page 5: Weighted Fair Queuing
Quality of Service Overview Figure 2 Strict Priority Queuing Packet Behavior Weighted Fair Queuing With weighted fair queuing, queue access to bandwidth is divided up by percentages of the time slices available. For example, if 100 percent is divided into 64 time slices, and each queue is configured for 25 percent, each queue will get 16 time slices, after which the next lowest priority queue will get the next 16, and so on. Should a queue empty before using its current share of time slices, the next priority queue inherits the time slices that remain. Figure fair queuing works. Inbound packets enter on the upper left of the box and proceed to the appropriate priority queue. Outbound packets exit the queues on the lower right. Queue 3 has access to its percentage of time slices so long as there are packets in the queue. Then queue 2 has access to its percentage of time slices, and so on round robin. Weighted fair queueing assures that each queue will get at least the configured percentage of bandwidth time slices. The value of weighted fair queueing is in its assurance that no queue is starved for bandwidth. The downside of weighted fair queueing is that packets in a high priority queue, with low tolerance for delay, will wait until all other queues have used the time slices available to them before forwarding. So weighted fair queuing would not be appropriate for applications with high sensitivity to delay or jitter, such as VoIP. February 22, 2008 3 depicts how weighted Page 5 of 29... -
Page 6: Hybrid Queuing
Quality of Service Overview Figure 3 Weighted Fair Queuing Packet Behavior Hybrid Queuing Hybrid queuing combines the properties of both strict and weighted fair queuing. Figure page 7, depicts hybrid queuing. The configuration is for strict queuing on queue 3 and weighted fair queuing for the remaining queues, with queue 2 receiving 50 percent of the remaining time slices, and the other queues receiving 25 percent each. The benefit of hybrid queueing is that queues configured as strict will receive all the bandwidth that is available in the order of their priority until empty. Remaining bandwidth will be used by the weighted fair queues based upon the time slice percentages configured. The down side remains that anytime strict queuing is used, should the strict queues never fully empty, remaining queues will be starved of bandwidth. February 22, 2008 4 on Page 6 of 29... -
Page 7: Rate Limiting
Quality of Service Overview Figure 4 Hybrid Queuing Packet Behavior Rate Limiting Rate limiting is used to control the rate of traffic entering (inbound) and/or leaving (outbound) a switch per CoS. Rate limiting allows for the throttling of traffic flows that consume available bandwidth, in the process providing room for other flows. Rate limiting guarantees the availability of bandwidth for other traffic by preventing the rate limited traffic from consuming more than the assigned amount of a network’s resources. Rate limiting accomplishes this by setting a cap on the bandwidth utilization of specific types of both inbound and outbound traffic. When a rate limit has been exceeded, the CoS can be configured to perform one or all of the following: record a Syslog message, send an SNMP trap to inform the administrator, and automatically disable the port. Figure 5 illustrates how bursty traffic is clipped above the assigned threshold with rate limiting applied. February 22, 2008 Page 7 of 29... -
Page 8: Rate Shaping
Quality of Service Overview Figure 5 Rate Limiting Clipping Behavior Rate Shaping Rate Shaping throttles the rate at which a port transmits (outbound) queued packets. Rate Shaping buffers packets received above the configured rate on a per CoS basis, rather than dropping them. Only when buffer capacity is exceeded are packets dropped. Rate shaping may be configured for a CoS on a port, for an 802.1p priority on a port, or for all Classes of Service on a port. Figure 6 illustrates how bursty traffic is smoothed out when it bursts above the assigned threshold with rate shaping applied. Figure 6 Rate Shaping Smoothing Behavior Rate shaping retains excess packets in a queue and then schedules these packets for later transmission over time. Therefore, the packet output rate is smoothed and bursts in transmission are not propagated as seen with rate limiting. Rate shaping can be implemented for multiple reasons, such as controlling bandwidth, to offer differing levels of service, or to avoid traffic congestion on other links in the network by removing the burstiness property of traffic that can lead to discarded packets. Rate shaping is important for real‐time traffic, where packet loss is extremely detrimental to these applications. Instead of February 22, 2008 Page 8 of 29... - Page 9 Note: It is recommended that you use Enterasys NetSight Policy Manager as an alternative to CLI for configuring policy-based CoS on the Enterasys Matrix Series devices. A policy discussion is outside the scope of this document and will be limited to the relevant configuration example commands.
- Page 10 Understanding QoS Configuration on the Matrix N-Series Determining CoS Port-Type Based on physical capability, all physical DFE ports belong to one of two port‐types. The importance of this port‐type distinction lies in the resources available for Transmit Queue and Inbound Rate Limiting CoS features. The nomenclature distinguishes the types as port type 0 and port type 1. The Enterasys Matrix DFE 7GR4270‐12, 7G4270‐12, 7G4270‐09, and 7G4270‐10 modules have a port type of 0. All other modules have a port type of 1. Port type 0 supports sixteen transmit queues, while type 1 supports four. Use the show cos port‐type txq to display all the systemʹs ports currently associated to each type. The following example displays default values for the show cos port‐type txq command output: Matrix(su)->show cos port-type txq Number of resources: txq = transmit queue(s) irl = inbound rate limiter(s) orl = outbound rate limiter(s) Port type...
- Page 11 Understanding QoS Configuration on the Matrix N-Series The following example displays default values for the show cos port‐type irl command output: Matrix(su)->show cos port-type irl Number of resources: txq = transmit queue(s) irl = inbound rate limiter(s) orl = outbound rate limiter(s) Port type Index description ----- ------------ DFE-P 32 IRL DFE-P 8 IRL Configuring CoS Port Groups CoS port groups provide for grouping ports by CoS feature configuration and port type. Ports are ...
- Page 12 Understanding QoS Configuration on the Matrix N-Series Port-Groups: TxQ Configuration TxQ Port‐Groups contain user settings for specific types of ports and their matching transmit queue settings. Port groups 0.0 and 0.1 exist by default. New port groups can be configured with a name and ports can be added according to device port‐type. Transmit queue behavior can also be configured per port group; port‐groups 0.0 and 0.1 are configured in strict queuing mode. Additional port groups also default to strict queuing mode, though each TxQ port group can be configured for weighted‐fair queuing if desired. The show cos port‐config txq command displays all configured TxQ port‐groups. Group name and type are displayed as well as ports associated with the port group. For show cos port‐config txq output, arbiter mode (TxQ mode) is displayed along with a picture of the supported queues and the number of slices allotted to the group. Queuing is also displayed by percentage. The following example displays default values for the show cos port‐config txq command output: Matrix(su)->show cos port-config txq * Percentage/queue (if any) are approximations based on [(slices/queue) / total number of slices] Transmit Queue Port Configuration Entries ---------------------------------------------------------------------- Port Group Name Port Group...
- Page 13 Understanding QoS Configuration on the Matrix N-Series • Optionally, specify port‐group Name, associated ports, and arb‐percentage or arb‐slices Port-Groups: IRL Configuration IRL Port‐Groups contain user settings for specific types of ports and their matching inbound rate limiting configurations. Port groups 0.0 and 0.1 exist by default. Each new group can be configured with a name and ports added to each group according to device port‐type. Use the show cos port‐config irl command to display each IRL port‐group configured by group and type, with group name and associated ports. The following example displays default values for the show cos port‐config irl command output: Matrix(su)->show cos port-config irl Inbound Rate Limiting Port Configuration Entries ---------------------------------------------------------------------- Port Group Name Port Group Port Type Assigned Ports ---------------------------------------------------------------------- Port Group Name Port Group Port Type Assigned Ports...
- Page 14 Understanding QoS Configuration on the Matrix N-Series The following example displays default values for the show cos port‐resource txq command output: Matrix(su)->show cos port-resource txq '?' after the rate value indicates an invalid rate value Group Index Resource Type Unit ----------- -------- ---- ---- ---------- The set cos port‐resource txq command is used for creating outbound rate shapers. You need to: • Identify the port group for configuration • Identify the queue resource ID, along with unit and rate desired for that queue CoS IRL Port-Resource (Inbound Rate Limiter) Unlike rate shaping, inbound rate limiting or rate policing simply drops or clips traffic inbound if ...
- Page 15 Understanding QoS Configuration on the Matrix N-Series solutions-r1(su)->show cos port-resource irl '?' after the rate value indicates an invalid rate value Group Index Resource Type Unit ----------- -------- ---- ---- ---------- No violators exist for this/these irl(s) The set cos port‐resource irl command is used for creating inbound rate limiters. You need to: • Identify the port group for configuration •...
- Page 16 Understanding QoS Configuration on the Matrix N-Series • virtual queues 12‐15 to physical queue 3 • virtual queues 8‐11 map to physical queue 2 • virtual queues 4‐7 map to physical queue 1 • virtual queues 0‐3 map to physical queue 0 The TxQ reference table can be displayed using the show cos reference txq command and displays port‐group, reference index, and physical queue. The following example displays default values for the show cos reference txq command output: Matrix(su)->show cos reference txq Group Index Reference Type ----------- --------- ---- ------------ Although the TxQ reference table is populated by default, the Queue‐to‐Reference mapping can be configured using the set cos reference txq command. You need to: • Identify the port group for configuration • Identify the transmit queue reference, along with the associated queue February 22, 2008 Queue Page 16 of 29...
- Page 17 Understanding QoS Configuration on the Matrix N-Series CoS IRL Reference Mapping Table The CoS IRL reference table uses 32 indexes or virtual rate limiters, and maps each virtual limiter to a physical limiter or resource. An IRL reference table exists for each port group configured, and is indexed similarly to port‐resources, as port‐group.port‐type reference. Because it is an optional configuration, IRL references are not populated with limiters (resources), but can be configured by you. The IRL reference table can be displayed using the show cos reference irl command. The following example displays default values for the show cos reference irl command output: solutions-r1(su)->show cos reference irl Group Index Reference Type Rate Limiter ----------- --------- ---- ------------ Physical‐Limiter to reference mapping can be configured using the set cos reference irl command. The other references not configured are indicated by rate limiter “none”. You need to: • Identify the port group for configuration • Identify the rate‐limit reference Configuring the CoS Index The CoS settings table assigns a priority, a ToS value, TxQ reference and an IRL reference to a CoS ...
- Page 18 Understanding QoS Configuration on the Matrix N-Series Priority: For each new CoS index created, you have the option to assign an 802.1p priority value 0‐7 for the class of service. CoS indexes 0‐7 map directly to 802.1p priorities and cannot be changed as they exist for backward compatibility. All other CoS index entries can have a priority value set between 0 and 7. ToS: The IP header Type of Service field is an 8‐bit field also referred to as the DiffServ Code Point (DSCP) field. This optional value can be set per class of service to a value between 0–255. When a frame is assigned to a class of service for which this value is configured, the ToS field of the incoming IP packet will be overwritten to values defined by you. This ToS rewrite option also allows masking. The ToS can selectively mask (change) certain bits of the field, without changing others. For instance masking the ToS could be used to modify the ToS precedence without modifying the DTR/ECN bits. The mask specified contains the bits to be changed. CLI input can be in decimal or hex value, and a mask is not required. If the mask is not specified in the ToS input, all bits will be overwritten. ToS can be set for CoS indexes 0‐7. TxQ Reference: Because all traffic requires association to a transmit queue, the CoS TxQ reference field will always be populated when a new CoS index is created. If a TxQ reference value is not chosen, TxQ reference 0 will be assigned. The reference does not indicate the actual transmit queue to be assigned by CoS; it points to the CoS TxQ Reference Mapping Table Index entry. It may be thought of as the virtual queue that is associated to a physical queue defined by the TxQ Reference Mapping Table. TxQ Reference Mapping Table defines 16 TxQ references, therefore CLI input for TxQ reference in the CoS Settings Table is 0‐15. See “CoS TxQ Reference Mapping” on page 15 for a TxQ reference configuration discussion. IRL Reference: The CoS IRL reference field is optional, as rate limits are not required. Like the TxQ reference field, the IRL reference does not assign an inbound rate limit but points to the CoS IRL Reference Mapping Table. This reference may also be thought of as the virtual rate limiter that will assign the physical rate limiter defined by the IRL Reference Mapping Table. The IRL Reference Mapping Table defines 32 IRL references, therefore input for IRL reference in the CoS Settings Table is 0‐31. See “CoS IRL Reference Mapping Table” on page configuration discussion. New CoS Indexes can be created using the set cos settings command. ToS, 802.1p priority, TxQ reference, and IRL Reference can be configured for each CoS Index. You need to: • Enter a CoS Index value from 0–255 •...
-
Page 19: Enabling Cos State
Understanding QoS Configuration on the Matrix N-Series The following example displays default values for the show cos settings command output: Matrix(su)->show cos settings * Means attribute has not been configured CoS Index Priority --------- ---------- Enabling CoS State CoS state is a global setting that must be enabled for CoS configurations to be applied to a port. When CoS state is enabled, controls configured for CoS supersede port level controls for priority queue mapping, IRL, and TxQ. These port level settings can be configured independent of CoS state, but will have no affect while CoS is enabled. Disabling CoS results in the restoration of current port level settings. Use the set cos state enable command to enable CoS state globally for this system. Use the set cos state disable command to disable CoS state globally for this system. Use the show cos state command to display the current status of CoS state. Displaying CoS IRL Violation IRL violations can be displayed per physical rate limit to show you when an inbound rate limit has been violated. Use the show cos violation irl command to display ports that have a limiter violated as well as any ports that may be disabled by the limiter. -
Page 20: Feature Differences
Violations are also displayed by resource and port using the show cos port‐resource irl command. Violating ports are displayed at the end of the resource table. Feature Differences The Enterasys SecureStack and standalone secure switch devices differ in CoS feature set from the N‐Series in the following ways: • CoS TxQ features are not supported. • Only the IRL Kbps unit option is supported. • Syslog, trap, and port disable options are not supported. • Supports 99 IRL references instead of the 32/8 supported by the N‐Series port types 0 and 1, respectively. • All SecureStacks belong to port group 0.0. No port type 1 exists for the SecureStack. • For the C3, IRL configuration is only supported within a policy role context. Configuration of IRLs within rules are not supported. In a mixed‐stack, C3 CoS feature limitations apply. February 22, 2008 Rate-Limiter Rate-Limiter... -
Page 21: The Qos Cli Command Flow
The QoS CLI Command Flow The QoS CLI Command Flow Procedure 1 provides a CLI flow summary of each step in the configuration flow along with the show commands to verify the configuration. Procedure 1 Class of Service CLI Configuration Command Summary Step Task Inspect both the TxQs and IRL support for the installed ports. This information is used to determine the module port type for port group. - Page 22 The QoS CLI Command Flow Procedure 1 Class of Service CLI Configuration Command Summary (continued) Step Task Modify a currently configured CoS or create a new CoS. Verify the new CoS configuration. All TxQ to port group mappings are associated with the transmit queue reference.
-
Page 23: Qos Configuration Example
VoIP end point with CEP H.323 authentication, you will need to adjust the VoIP policy accordingly. For instance, SIP uses UDP port 5060, not the TCP port 1720. Notes: Enterasys highly recommends that you use the NetSight Policy Manager to configure QoS on your network, whether you are applying policy or not. This example discusses the QoS configuration using Policy Manager followed by CLI input summaries. - Page 24 QoS Configuration Example Figure 7 QoS Configuration Example A core profile for the router and an edge profile for the switch provide for the difference in rate limiting needs between the enduser and aggregation devices. A call setup profile rate limiting the setup aspect of the VoIP call. Each edge and core VLAN profile will be configured for default CoS 5 (best default priority for voice and video), the addition of its associated VLAN to its egress VLAN list, and ToS overwrite. We will create a separate CoS for both the edge and core to handle ToS, rate‐limit and queue configuration for these devices. The H.323 call setup profile will be configured so that TCP call setup traffic on the TCP destination port 1720:10.0.0.1 of its gigabit link will be configured for the proper rate limit on that port. Using NetSight Policy Manager, configure the policy roles and related services as follows: Setting the VoIP Core Policy Profile (Router 1) For DFE router 1, we configure a separate policy for VoIP Core. VoIP Core policy deals with packets transiting the core network using VoIP VLAN 22. For role VoIPCore we will: • Configure VoIPEdge‐VLAN22 as the name of the role. • Set default CoS to 5. • Set the default access control to VLAN 22. • Enable TCI overwrite so that ToS will be rewritten for this policy. February 22, 2008 Page 24 of 29...
- Page 25 Create Class of Service for VoIPEdge Policy Create CoS 8 as follows: • 802.1p priority: 5 • ToS: B8 • Specify IRL index 0 to associate this CoS to the rate limit Create a Rule • Create a Layer 2 traffic classification rule for VLAN ID 22 within the VoIPCore service. • Associate CoS 8 as the action for the rule. Setting the VoIP Edge Policy Profile (Switch 1) For DFE Switch 1, we configure a separate policy for VoIP edge. VoIP edge policy deals with packets transiting the edge network using VoIP VLAN 12 with edge access. For role VoIPEdge we will: • Configure VoIPEdge‐VLAN12 as the name of the role. • Set default CoS to 5. • Set the default access control to VLAN 22. • Enable TCI overwrite so that ToS will be rewritten for this policy. Create a Policy Service •...
- Page 26 • 802.1p priority: 5 • ToS: B8 • Specify IRL index 0 to associate this CoS to the rate limit Create a Rule • Create a Layer 2 traffic classification rule for VLAN ID 22 within the VoIPEdge service. • Associate CoS 9 as the action for the rule. Setting the H.323 Call Setup Policy Profile H.323 Call Setup policy deals with the call setup traffic for VoIP H.323 authenticated users directly attached to Switch 1 using link ge.1.10. For role H.323 Call Setup we will: • Configure H323CallSetup as the name of the role. • Set default CoS to 5. • Enable TCI overwrite so that ToS will be rewritten for this policy. Create a Policy Service • Name the service H323CallSetup Service. • Apply the service to the H323CallSetup Policy Role. Create a Rate-limiter Create a rate‐limit as follows: •...
- Page 27 Matrix(su)->set cos 8 priority 5 tos-value 184.0 txq-reference 8 irl-reference 0 Matrix(su)->set cos state enable Summary of Command Line Input for DFE Switch 1 Matrix(su)->set policy profile 1 name VoIPEdge-VLAN12 cos 5 egress-vlans 12 tci-overwrite enable Matrix(su)->set policy rule admin-profile vlantag 12 mask 12 port-string ge.1.10-13 admin-pid 1...
-
Page 28: Terms And Definitions
Terms and Definitions Matrix(su)->set policy rule admin-profile port ge.1.10 mask 16 port-string ge.1.10 admin-pid 2 Matrix(su)->set policy rule 1 tcpdestportIP 1720:10.0.0.1 cos 10 port-string ge.1.10 Matrix(su)->set cos port-resource irl 3.1 2 unit pps rate 5 Matrix(su)->set cos reference irl 3.1 10 rate-limit 1 Matrix(su)->set cos 10 priority 5 tos-value 184.0 txq-reference 8 irl-reference 2 Matrix(su)->set cos state enable... -
Page 29: Revision History
The hardware, firmware, or software described in this document is subject to change without notice. IN NO EVENT SHALL ENTERASYS NETWORKS BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS) ARISING OUT OF OR RELATED TO THIS DOCUMENT, WEB SITE, OR THE INFORMATION CONTAINED IN THEM, EVEN IF ENTERASYS NETWORKS HAS BEEN ADVISED OF, KNEW OF, OR SHOULD HAVE KNOWN OF, THE POSSIBILITY OF SUCH DAMAGES. Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01810 © 2008 Enterasys Networks, Inc. All rights reserved. ENTERASYS, ENTERASYS NETWORKS, ENTERASYS MATRIX, ENTERASYS NETSIGHT, LANVIEW, WEBVIEW, and any logos associated therewith, are trademarks or registered trademarks of Enterasys Networks, Inc., in the United States and other countries. All other product names mentioned in this manual may be trademarks or registered trademarks of their respective companies. Revision History Description Initial Release of the Document Modifications due to product branding changes.