-
Cisco 12000 Manager Release 2.2
- Reelase Notes for Cisco 12000/10720 Router Manager 2.2
- Cisco 12000/10720 Router Manager Installation and Configuration Guide, 2.2
-
Cisco 12000/10720 Router Manager User's Guide, 2.2
-
About This Guide
-
C12kM Overview
-
C12kM Concepts
-
Getting Started
-
Chassis Management
-
Managing Modules
-
Managing Interfaces
-
Interface Profiles
-
Interface Configuration
-
Interface Status
-
Interface Performance
-
Layer 3 QoS
-
Managing ATM Connections
-
VLAN Management
-
Fault Management
-
Change Management
-
Performance Management and Historical Data
-
SONET/SDH COnversion Chart
-
Table Of Contents
Launching the Layer 3 QoS Windows
Weighted Random Early Detection (WRED)
Per Interface Rate Control (PIRC) Support
Applying an Access List to a CAR Policy
CAR Policy Configuration Window—Detailed Description
Access List Configuration Window—Detailed Description
Applying CAR Policies to an Interface
Removing a CAR Policy from an Interface
Editing or Deleting a CAR Policy
CAR Policy Apply Window—Detailed Description
Viewing the CAR Policy Status Window
Creating a CoS Queue Group Under WRED
Editing an Existing CoS Queue Group
Deleting an Existing CoS Queue Group
CoS Queue Group Configuration Window—Detailed Description
Applying a CoS Queue Group to an Interface
Removing a CoS Queue Group from an Interface
Changing the Association of a CoS Queue Group
WRED Tx Configuration Window—Detailed Description
Editing an Existing ToFab policy
Deleting an Existing ToFab policy
WRED ToFab Policy Configuration Window - Detailed Description
ToFab Policy Configuration tab
Associating a ToFab policy to a Linecard
Disassociating a ToFab Policy from a Linecard
Changing the association of a ToFab Policy
WRED Rx Configuration Window-Detailed Description
Layer 3 QoS
This chapter describes how to create and configure Layer 3 QoS (Quality of Service), Committed Access Rate (CAR) policies, Cos Queue groups and WRED ToFab policies.
This chapter contains the following information:
•
Launching the Layer 3 QoS Windows
•
Launching the Layer 3 QoS Windows
Table 11-1 displays the Layer 3 QoS windows that can be launched from each of the available object types. For example, the CAR Policy Configuration window can be launched from a Site, Shelf, Chassis, Module, Interface or a CAR Policy, but not from an Access List, WRED-MDRR container or a CoS Queue Group object.
Note
CAR and WRED Overview
Access Lists
Access lists enhance the abilities of a CAR policy. For example, access lists allow you to specify certain types of traffic, or certain locations where the traffic is coming from.
Committed Access Rate (CAR)
CAR is a policing mechanism that allows you to partition your network into multiple priority levels or classes of service. You set the IP precedence for packets entering the network. Networking devices (within your network) can then use the configured IP precedence in the packets to determine how to treat the traffic. CAR services, limit the input or output transmission rate on an interface or sub-interface, based on a flexible set of criteria. CAR is often configured on interfaces at the edge of a network to limit traffic into or out of the network. CAR, can rate limit traffic based on certain matching criteria, such as incoming interface, incoming and outgoing traffic, IP precedence, or IP access list. You can configure the actions CAR will take when traffic conforms to or exceeds the rate limit. Each interface can have multiple CAR policies, corresponding to different types of traffic. For example, low priority traffic can be limited to a lower rate than high priority traffic.
Note
Weighted Random Early Detection (WRED)
WRED is a congestion avoidance mechanism that takes advantage of Transmission Control Protocol (TCP) congestion control mechanism. WRED drops packets selectively, prior to periods of high congestion, based on IP precedence. Packets with a higher IP precedence are less likely to be dropped than packets with a lower precedence. WRED is normally used in the core routers of a network, rather than on the edge. Edge routers assign IP precedence to packets as they enter the network. WRED uses these precedents to determine how it treats different types of traffic.
You can have a symmetric as well as asymmetric data rate for network transmissions. In order to smoothen the data traffic at transmit as well as the receive end, the WRED QoS parameters can be configured for the transmitting and receiving traffic. The WRED ToFabric (henceforth referred as WRED ToFab) feature enables the user to configure the WRED at the receive side in conjunction with the transmit side.
All WRED processing takes place on the line card, rather than on the GRP management card. No default configuration values are supplied. You must provide values for all configurable fields. WRED also incorporates Modified Deficit Round Robin (MDRR).
You can see from the descriptions where these two mechanisms differ. CAR focuses more on classifying traffic according to QoS parameters, while WRED functions to ease network traffic and prioritize specified traffic.
MDRR Overview
Modified Deficit Round Robin (MDRR) is a traffic latency control function. It allows the operators to guarantee traffic latency for differentiated flows by controlling the packet de-queuing process. Packet classification is based on IP Precedence. MDRR differs from DRR in that one of the eight available queues is designated as a low-latency queue.
There are two basic modes of operation which govern how packets are de-queued from the low-latency queue in relation to other queues. They are:
•
•
MDRR in C12kM
The MDRR implementation uses COS Queue Groups to encapsulate the required profile. Consequently, C12kM provides MDRR support via COS Queue Groups: the operator creates a COS Queue Group & uses the MDRR configuration Window to encapsulate the required parameters. The COS Queue Group is then available to be applied to any interface.
Implications of Engine Type
Engine type refers to different hardware architectures. From a management perspective, the engine type determines what functionality is available to the client. Currently, this only applies to Layer 3 QoS. The following is a summary of how engine type affects Layer 3 QoS:
•
•
•
C12kM will detect the engine type applicable to a given module (line card) and prevent operations that are not applicable.
CAR and WRED in C12kM
CAR and WRED are modeled as objects in C12kM. There are two types of CAR objects: CAR policies and access lists. There is two types of WRED objects: CoS (Class of Service) queue groups and ToFab policies.
When you create these objects in C12kM, you can work within the Layer 3 QoS view to create, apply, delete or edit Layer 3 QoS objects. Created CAR policies are placed under the CAR Policies container in the Layer 3 QoS view. Created access lists are placed under the Access List container in the Layer 3 QoS view. Created CoS queue groups are placed under the WRED-MDRR container in the Layer 3 QoS view. Created ToFab polices are placed under the WRED-MDRR container in the Layer3QoS view.
Tip
It is important to note that Layer 3 QoS CAR and WRED objects (access lists, policies, CoS queue groups, ToFab policies) are global, meaning they can be applied to any module/interface object within C12kM. For example, the CosQ groups are applied to interfaces whereas the ToFab policies are applied to modules (linecards).
The Workflow for CAR
To begin working with CAR objects, proceed as follows:
Step 1
Step 2
Step 3
Step 4
At any given time, you also have the option to edit or delete CAR policies (which are not applied), change the association of CAR policies, or view the status of CAR policies on any interface.
CAR Policies
CAR policies can rate limit traffic based on certain matching criteria, such as incoming interface, IP Precedence, or IP access list. You configure the actions CAR will take when traffic conforms to or exceeds the rate limit. You can set CAR policies that are associated with one of the following:
•
•
•
•
Each interface can have only one CAR policy applied.
The CAR Policies section covers the following areas:
•
•
Per Interface Rate Control (PIRC) Support
From the operator's perspective, the same workflows used for CAR will be available for the creation, application and maintenance of PIRC Policies. Specifically, the following functions are applicable to PIRC:
•
•
•
–
–
–
•
•
–
–
–
If an attempt is made to apply a CAR policy to an engine 2 module, then the request will be refused and an appropriate error message is displayed, if an attempt is made to use CAR functionality outwith that listed above.
On engine 0 and 1 modules, the full range of CAR functions is supported.
Creating a CAR Policy
To create a CAR policy, proceed as follows:
Step 1
Figure 11-1 CAR Policy Configuration Window
Step 2
Step 3
A window appears, confirming if you were successful or not. The name of your new profile appears in the list box at the left of the window.
Step 4
Step 5
Applying an Access List to a CAR Policy
Step 1
Step 2
Step 3
Step 4
Step 5
CAR Policy Configuration Window—Detailed Description
The CAR Policy Configuration displays a single CAR Policy Configuration tab.
CAR Policy Configuration Tab
The CAR Policy Configuration tab displays four tabs: CAR Parameters, Access List Choice, Conform Action, and Exceed Action.
CAR Parameters
The CAR Parameters frame contains the following fields:
Traffic Direction—Choose either incoming (input) or outgoing (output) traffic.
Average Transmission Rate—Normal transmission rate based on a long term average in bps.
Normal Burst Size (in bytes)—Bytes allowed in a burst before some packets will exceed the rate limit. Larger bursts are more likely to exceed the rate limit.
Maximum Burst Size (in bytes)—Bytes allowed in a burst before all packets will exceed the rate limit.
Access List Choice
The Access List Choice frame contains the following fields:
With Access List—Choose yes to apply a selected access list to the selected CAR policy; choose No if you do not want to apply an access list to the selected CAR policy.
Available Access List—Pane that lists all created access lists.
Actions—Contains two arrow buttons to move access lists between the available access list and the required access list.
Required Access List—Pane that lists all access lists, which are required to be associated with the selected CAR policy.
Conform Action
The Conform Action frame contains the following fields:
Continue—Evaluate the next rate-limit command.
Drop—Choose to drop the packet or not.
Transmit—Choose to transmit the packet or not.
Set Prec. To X and Continue—(numbers 0-7) Set precedence to an integer and continue.
Set Prec. To X and Transmit—(numbers 0-7) Set precedence to an integer and transmit.
Exceed Action
The Exceed Action frame contains the following fields:
Continue—Evaluate the next rate-limit command.
Drop—Choose to drop the packet or not.
Transmit—Choose to transmit the packet or not.
Set Prec. To Y and Continue—(numbers 0-7) Set precedence to an integer and continue.
Set Prec To Y and Transmit—(numbers 0-7) Set precedence to an integer and transmit.
Access Lists
Access lists are supplemental to CAR policies. They enhance the abilities of a CAR policy. For example, access lists allow you to specify certain types of traffic, or certain locations where the traffic is coming from.
The Access List section covers the following areas:
•
Creating Access Lists
To create an access list, proceed as follows:
Step 1
Figure 11-2 Access List Configuration—General Tab
Step 2
Step 3
A window appears, confirming if the access list creation was successful or not. The name of your new access list appears in the list box at the left of the window.
Step 4
Step 5
Step 6
Step 7
Access List Configuration Window—Detailed Description
The Access List Configuration window contains one button, Create. The Create button is used to create an access list. When you choose Create, a new access list of type IP standard is created and the next available index is assigned. The access list type can be changed and saved if desired. When the access list type is changed, the index can be manually or automatically reallocated to the next available index for the new type selected.
The Access List Configuration window displays five tabs: General, IP Standard, IP Precedence, MAC, and IP Extended.
Note
General Tab
The General tab contains a single General tab.
General
The General tab displays four fields:
Index Allocation Mode—Possible values are Manual or Automatic. When the access list type is changed, the index can be manually or automatically reallocated to the next available index for the new type selected.
Index—Identification number for an access list. The Index field is automatically generated if the Index Allocation Mode is set to Automatic.
Type—Lists the type of access list. Possible types include: IP Standard, IP Precedence, MAC and IP Extended.
Logging Level—(This field is only applicable to IP standard and IP extended access lists). If you enable the logging level, then informational messages about the packet that matched the criteria specified in the access list are generated.
IP Standard Tab
The IP Standard tab displays a single IP Standard panel:
Figure 11-3 Access List Configuration—IP Standard Tab
IP Standard
The IP Standard panel displays five fields:
Access Action—Action to be taken if the conditions are matched. This value will be either deny or permit.
Host Type—Host type indicates the hosts for which the access action are available. Possible values for this field include the following:
•
•
•
•
•
Note
Host Name—Name of the host (or source of the packet) for which the access action is applicable.
IP Address—IP address of the host (or source of the packet) for which the access action is applicable.
Wild Card—If the access action is applicable for more than one host, then this field should be used as a mask. For example, the wild card 255.255.255.255 effectively represents any.
IP Precedence Tab
The IP Precedence tab appears as follows:
Figure 11-4 Access List Configuration—IP Precedence Tab
The IP Precedence tab contains one panel: IP Precedence.
IP Precedence
The IP Precedence panel contains three fields:
Mask—If more than one precedence comes into the same classification, mask should be used for classification. Enabling mask enables the precedence bit mask field and disabling mask enables the precedence field.
Precedence—IP precedence to be matched. Possible values are 0 to 7.
Precedence Bit Mask—If more than one precedence comes into the same classification, precedence bit mask should be used. Possible values for this field are 00 to FF.
MAC
The MAC tab appears as follows:
Figure 11-5 Access List Configuration—MAC Tab
The MAC tab contains one panel: MAC.
MAC
The MAC panel contains one field:
MAC Address—Type in the MAC address for the packets to be classified.
IP Extended Tab
The IP Extended tab displays a single IP Extended panel. The IP Extended frame is further split into three sub-frames: Dynamic List, Source, and Destination.
Figure 11-6 Access List Configuration Window—IP Extended Tab
IP Extended
The IP Extended frame contains two fields:
Access Action—Action to be taken if the conditions are matched. Possible actions are deny and permit.
Protocol Name—Name or number of an IP protocol. Valid protocol number values are 0 to 255. Valid protocol names are as follows:
Table 11-2 Valid Protocol Names
ahp
ipinip
eigrp
nos
gre
ospf
icmp
pcp
igmp
pim
igrp
tcp
ip
udp
esp
Dynamic—Defines the selected access list to be dynamic. Dynamic access lists grant access per user to a specific source or destination host through a user authentication process. You can allow user access through a firewall dynamically, without compromising security restrictions.
Dynamic List
Name—Defines a name for the dynamic list (only available if Dynamic button is selected).
Time Out—Specifies the absolute length of time (in minutes) that a temporary access list entry can remain in a dynamic access list. The default (0) is an infinite length of time and allows an entry to remain permanently (only available if Dynamic button is selected).
Source and Destination
The Source and Destination frames contain the following fields:
Host Type—Indicates the hosts for which the access action are available. Possible values for this field include the following:
•
•
•
•
Host Name—Name of the host (or source of the packet) for which the access action is applicable.
IP Address—IP address of the host (or source of the packet) for which the access action is applicable.
Wild Card—If the access action is applicable for more than one host, then this field should be used as a mask. For example, the wild card 255.255.255.255 effectively represents any.
Port Criteria—Criteria to be applied on the specified port (interface) number. Possible values are as follows:
•
•
•
•
•
•
Port
The Port sub-frame in the Source and Destination frames contains the following fields:
Number—Port (interface) number from/to where the packet is sent or destined.
Range—Defines which port (interface) numbers will be allowed through this filter.
CAR Policy Apply
The CAR Policy Apply section covers the following areas:
•
•
•
•
Applying CAR Policies to an Interface
To apply a CAR policy to an interface, proceed as follows:
Step 1
Figure 11-7 CAR Policy Apply Window
Step 2
Step 3
Step 4
Note
If the interface is being managed, the selected CAR policy is downloaded to the device.
For more details on the fields within this tab, refer to "CAR Policy Apply Window—Detailed Description" section.
Removing a CAR Policy from an Interface
To remove CAR policies from an interface, proceed as follows:
Step 1
Step 2
Step 3
Editing or Deleting a CAR Policy
A CAR policy can only be edited or deleted if it is not currently being applied to an interface. Once you have applied a CAR policy to an interface, you cannot edit or delete it unless you first remove it from the interface. If that CAR policy is being used by any other interface, you will still not be able to edit or delete the CAR policy. For this reason, it is a good idea to note down which interfaces have which CAR policies applied to them. If you keep such a list, if you later want to edit or delete the CAR policy, you can simply remove it from the interfaces that are using it, then proceed to edit the fields within the CAR Configuration window or delete the CAR policy.
To delete an existing CAR policy, proceed as follows:
Step 1
Step 2
Figure 11-8 Deployment Wizard—Summary
Step 3
CAR Policy Apply Window—Detailed Description
The CAR Policy Apply window has one tab, CAR Policy Apply.
CAR Policy Apply Tab
The CAR Policy Apply tab contains two list boxes and two frames, Actions and Apply Status.
Available Policies—Lists all created CAR Policies that are available to apply to a selected interface.
Required Order—Displays CAR policy that is applied to the selected interface.
Actions
The Actions frame displays the following:
Force synchronization?—Allows you to select whether to force synchronization with the selected device or not. Select Yes to force synchronization or select No if you do not wish to force synchronization.
Right arrow button (>>)—Allows you to move CAR policies from the Available Policies list to the Required Order list.
Left arrow button (<<)—Allows you to move CAR policies from the Required Order list to the Available Policies list.
Apply button—Allows you to apply the CAR policies listed in the Required Order list to the selected interface.
Apply Status
The Apply Status frame contains one field, as follows:
Status of Last Apply—Status of the last CAR policy applied to an interface. This value can be either succeeded or failed.
CAR Policy Status
The CAR Policy Status window displays the CAR policies that are currently applied to a selected interface, and in what order.
Viewing the CAR Policy Status Window
To view the CAR Policy Status window, proceed as follows:
Step 1
Figure 11-9 CAR Policy Status Window
Step 2
The Workflow for WRED/DRR
To begin working with WRED objects, the first step is to create and configure a CoS queue group (which includes DRR, or Distributed Round Robin). You can then apply the created CoS queue group to one or multiple interfaces. At a time, only one CoS queue group can be applied to any number of interfaces.
At any given time, you also have the option to edit, delete, or change the association of a CoS queue group.
Engine Type Support for WRED
If an attempt is made to apply a WRED policy to an engine 1 module, then the request will be refused and an appropriate error message issued to the client. The full range of WRED functionality will be supported for engine 0, 2 and 4 modules.
CoS Queue Group Configuration
The CoS Queue Group Configuration section covers the following areas:
•
•
•
•
Creating a CoS Queue Group Under WRED
To create a CoS queue group under WRED, proceed as follows:
Step 1
Figure 11-10 CoS Queue Group Configuration Window—CoS Queue Group Tab
Step 2
Step 3
Step 4
Step 5
Editing an Existing CoS Queue Group
An existing CoS queue group can only be edited if it is not currently being applied to any interfaces. Once you have applied a CoS queue group to an interface, you cannot edit it unless you remove it from the interface.
To edit an existing CoS queue group, proceed as follows:
Step 1
Step 2
Step 3
Step 4
Deleting an Existing CoS Queue Group
An existing CoS queue group can only be deleted if it is currently not applied to any interfaces. Once you have applied a CoS queue group to an interface, you cannot delete it unless you remove it from the interface.
To delete an existing CoS queue group, proceed as follows:
Step 1
Step 2
Figure 11-11 Deployment Wizard—Summary
Step 3
CoS Queue Group Configuration Window—Detailed Description
The CoS Queue Group Configuration window has two tabs: CoS Queue Group and DRR (Deficit Round Robin).
CoS Queue Group Tab
In the CoS Queue Group tab, you can configure the WRED parameters and the mapping of the IP precedence to the specific WRED profile you wish to use. The CoS Queue Group tab has two frames: IP Precedence and WRED Parameters. The CoS Queue Group tab also has one outside field, as follows:
Exponential Weighting Constant—(numbers 0 to 16) Sets the weight used in calculating the average queue depth for this COS queue group.
IP Precedence
The IP Precedence frame contains a table with two headings: IP Precedence and Drop Label.
IP Precedence—This column allows the user to map packets that have a particular IP precedence to a WRED profile in this CoS queue group. You can map several or all precedences to the same WRED profile if you wish. By default, precedence values are mapped so that they are not dropped due to WRED.
Drop Label—Select a number, 0 to 6, which is the number of the corresponding drop label in the WRED parameters table.
All—On checking All, the configuration of the first IP precedence is applied to all the Ip precedences.
WRED Parameters
The WRED Parameters frame contains a table with four headings: Drop Label, Min Threshold, Max Threshold, and Max Prob Denominator. The last three headings describe the actual WRED curve.
Drop Label—Drop label is a placeholder number for this set of WRED parameters. This is the number you map IP precedence values to.
Min Threshold—When the weighted queue average is below the minimum threshold, no packets are dropped.
Max Threshold—When the weighted queue average is above the maximum queue threshold, all packets are dropped until the average drops below the maximum threshold.
Max Prob Denominator—When the weighted queue average is between the minimum and the maximum thresholds, the probability that the packet is going to be dropped can be calculated by a straight line from the minimum threshold (probability of drop will be 0) to the maximum threshold (probability of drop is equal to the max prob denominator).
DRR Tab
The DRR tab appears as follows:
Figure 11-12 CoS Queue Group Configuration Window—DRR Tab
The DRR tab has two frames: DRR Mapping and DRR Queue. There is also a Low-latency field.
DRR Mapping
The DRR Mapping frame allows you to map a particular IP precedence to a regular DRR queue (values 0-6 or low-latency).
DRR Queue
The DRR Queue frame allows you to give a relative weight to each DRR queue.
Low-latency—Only applicable for MDRR. This value can be set to one of the following values:
Alternate priority—You must specify a weight in the DRR queue frame.
Strict priority—No weight is specified.
None—If low latency is not mapped to any of the IP Precedences in the DRR Queue, then you must set the low latency to none.
WRED Tx Configuration
The WRED Tx Configuration section covers the following areas:
•
•
•
•
Applying a CoS Queue Group to an Interface
To apply a CoS Queue Group to an interface, proceed as follows:
Step 1
Figure 11-13 WRED Tx Configuration Window
Step 2
Step 3
Step 4
Note
Note
Removing a CoS Queue Group from an Interface
To remove an applied CoS queue group from an interface, proceed as follows:
Step 1
Step 2
Step 3
Step 4
Changing the Association of a CoS Queue Group
To change the association of a CoS queue group, proceed as follows:
Step 1
Step 2
Step 3
Step 4
WRED Tx Configuration Window—Detailed Description
The WRED Tx Configuration window displays a single Tx Config tab.
Tx Config Tab
The Tx Config tab displays three frames: Available COS Queue Group, Associated COS Queue Group Information, and Apply Status.
Available COS Queue Group
The Available CoS Queue Group frame displays the following fields:
Available COS Queue Group—This list box displays all the available CoS queue groups. You can Apply or Remove a CoS queue group from the selected interface in this pane as well. If the selected interface has a CoS queue group applied to it, that CoS queue group will be highlighted in this box. If the selected interface has no CoS queue group applied to it, the top CoS queue group will be highlighted by default.
Actions
The Available CoS Queue Group frame displays an Actions sub-frame. The Actions sub-frame displays two buttons: Apply and Remove.
Apply—Once you have highlighted the CoS queue group in the Available COS Queue Group list, choose Apply to apply it to the selected interface.
Remove—Once you have highlighted the CoS queue group in the Available COS Queue Group list, choose Remove to remove it from the selected interface.
Associated COS Queue Group Info
Associated COS Queue Group Info—Status of the selected CoS queue group. Values can be as follows:
•
•
•
Apply Status
This frame displays the status of the last apply action.
WRED ToFab Configuration
The WRED ToFab section covers the following areas:
•
•
•
Creating a ToFab Policy
A user can create a WRED ToFab policy and associate the policy to linecards across devices. To create a ToFab policy under WRED, proceed as follows:
Step 1
Note
Figure 11-14 ToFab Configuration Window-ToFab Policy Configuration Tab
Step 2
Step 3
Step 4
Editing an Existing ToFab policy
A ToFab Policy can be edited only if it is not associated to any linecard. If the policy is associated to a linecard(s), it cannot be edited unless it is disassociated from the linecard(s).
To edit an existing ToFab policy, proceed as follows:
Step 1
Step 2
Step 3
Step 4
Deleting an Existing ToFab policy
A ToFab policy can be deleted only if it is not currently associated to any linecards. If a policy is associated to a linecard, it cannot be deleted unless it is disassociated from the linecard.
To delete an existing ToFab policy, proceed as follows:
Step 1
Step 2
Step 3
Figure 11-15 Deployment Wizard—Summary
Step 4
Note
WRED ToFab Policy Configuration Window - Detailed Description
The WRED ToFab Policy Configuration window displays a single ToFab Policy Configuration tab.
ToFab Policy Configuration tab
In the WRED ToFab Policy Configuration tab, the left hand side indicates the ToFab policies available in the device. The right hand side of the tab displays the slot numbers, the available COS-Queue groups and the combination of the Slot-CosQ group configurations.
Slot Table Parameters
On creation of a ToFab policy, the Slot-CosQ Groups listbox is empty. The user needs to select the slot number to which a CosQ group has to be associated. However, different CosQ groups cannot be associated with the same slot number. The status of the policy indicates the number of modules that are using the current ToFab Policy.
Slot Number - Displays the destination slot number.
Note
CosQ Groups - The user can select a CosQ group from this list to associate it to a slot.
Actions
Add - To add a Slot-CosQ group combination, select a slot from the drop down list box and select the CosQ group to be associated for the slot and then click the Add button. This action results in adding an entry into the ToFab policy in the SlotNumber-COSQueue group name format.
Remove - To remove a Slot-CosQ group combination from the list, select Remove. This action results in the removal of the Slot-CosQ group combination from the list.
Create - To create a ToFab policy, click Create, a window pops up asking the user to enter the name for the ToFab policy.
Slot-CosQ Groups
The Slot-CosQ group listbox lists the combination of the slots and the respective CosQ groups associated.
WRED Rx Configuration
The WRED Rx Configuration section covers the following areas:
•
•
•
•
Associating a ToFab policy to a Linecard
To associate a ToFab policy to a linecard, proceed as follows:
Step 1
Figure 11-16 WRED Rx Configuration
Step 2
Step 3
Step 4
Disassociating a ToFab Policy from a Linecard
To disassociate a ToFab policy from a linecard, proceed as follows:
Step 1
Step 2
Step 3
Changing the association of a ToFab Policy
To change the association of a ToFab policy to a linecard, proceed as follows:
Step 1
Step 2
Step 3
Step 4
Note
WRED Rx Configuration Window-Detailed Description
The WRED Rx Configuration window displays a single Rx Configuration Tab.
Rx Configuration Tab
Policy Name - The user can select the ToFab policy from this list. This list contains all the ToFab policies.
Actions
Associate - Highlight the ToFab Policy in the ToFab list, click Associate to apply it to the selected modules.
Disassociate - Choose the chassis and module from the listbox on the left side of the window, click Disassociate to remove it from the selected module.
Associated slot - Table Info
The associated ToFab policy is displayed in this frame.
Apply Status
This frame displays the status of the previous apply action.
