Layer 3 QoS
Available Languages
Table Of Contents
Weighted Random Early Detection (WRED)
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
Changing the Ordering of CAR Policies on an Interface
Editing or Deleting a CAR Policy
CAR Policy Apply Window—Detailed Description
Creating a CoS Queue Group Under WRED
Editing or 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
Associated COS Queue Group Info
Layer 3 QoS
The Layer 3 QoS chapter contains the following information:
•
CoS Queue Group Configuration
CAR and WRED Overview
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 adjusted IP precedence to determine how to treat the traffic. CAR services limit the input or output transmission rate on an interface or subinterface 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, IP precedence, or IP access list. You 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.
Weighted Random Early Detection (WRED)
WRED is a congestion avoidance mechanism that takes advantage of TCPs (Transmission Control Protocol) 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 precedences to packets as they enter the network. WRED uses these precedents to determine how it treats different types of traffic. 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 arede-queued from the low-latency queue in relation to other queues. They are:
•
•
MDRR in CGM
The GSR MDRR implementation uses COS Queue Groups to encapsulate the required profile. Consequently, CGM 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
In CGM 2.0, there was no provision for the different engine types available on GSR line cards. Put simply, the 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:
•
•
•
CGM will detect the engine type applicable to a given module (line card) and prevent operations that are not applicable.
CAR and WRED in CGM
CAR and WRED are modeled as objects in CGM. There are two types of CAR objects: CAR policies and access lists. There is one type of WRED object: CoS (Class of Service) queue groups.
When you create these objects in CGM, 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.
Tips
It is important to note that Layer 3 QoS CAR and WRED objects (access lists, policies, CoS queue groups) are global, meaning they can be applied to any interface object within CGM.
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, 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 rate policies that are associated with one of the following:
•
•
•
•
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. With multiple rate policies, the router examines each policy in the order entered until the packet matches. If a match is not found, the default action is to transmit.
The rate policies can be independent; each rate policy deals with a different type of traffic. Alternatively, rate policies can be cascading; a packet can be compared to multiple different rate policies in succession. You can configure up to 20 rate policies on a subinterface.
The CAR Policies section covers the following areas:
•
•
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 issued to the client if an attempt is made to use CAR functionality outwith that listed above.
On engine 0, 1 and 4 modules, the full range of CAR functions is supported.
Creating a CAR Policy
To create a CAR policy, proceed as follows:
Step 1
Layer 3 QoS>CAR>Policy Configuration. The CAR Policy Configuration window appears.Figure 10-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 left.
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 window has one tab, CAR Policy Configuration, with four areas:
•
•
•
•
CAR Parameters
The CAR Parameters area 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 Mbps.
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 area 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 area 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 precendence to an integer and continue.
Set Prec. To X and Transmit—(numbers 0-7) Set precendence to an integer and transmit.
Exceed Action
The Exceed Action area 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 precendence to an integer and continue.
Set Prec To Y and Transmit—(numbers 0-7) Set precendence 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, etc. They allow you further specificity when creating your CAR policies.
The Access List section covers the following areas:
•
Creating Access Lists
To create an access list, proceed as follows:
Step 1
Layer 3 QoS>CAR>Access List Configuration. The Access List Configuration window appears, with the General tab displayed.Figure 10-2 Access List Configuration—General Tab
Step 2
Step 3
A window appears, confirming if you were successful or not. The name of your new access list appears in the list box at left.
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 click 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 is automatically reallocated to the next available index for the new type selected.
The Access List Configuration window contains five tabs:
•
•
•
•
•
Note that the General tab is always accessible. The corresponding tab, based on the access list type, is also accessible. Any non-relevant tabs are grayed out. The fields in all the tabs are populated with default values. The fields can be changed as desired.
General Tab
The General tab contains one area: Action.
Action
The Action area contains three fields:
Index—Identification number for an access list that is automatically generated by CGM.
Type—Lists the type of access list. Possible types include:
•
•
•
•
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 will be generated.
IP Standard Tab
The IP Standard tab appears as follows:
Figure 10-3 Access List Configuration—IP Standard Tab
The IP Standard tab contains one area: IP Standard.
IP Standard
The IP Standard area contains 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:
•
•
•
•
•
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 Precendence tab appears as follows:
Figure 10-4 Access List Configuration—IP Precedence Tab
The IP Precedence tab contains one area: IP Precedence.
IP Precedence
The IP Precedence area contains three fields:
Mask—If more than one precendence 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 to be enabled.
Precedence—IP precedence to be matched. Possible values are 0 - 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-xx.
MAC
The MAC tab appears as follows.
Figure 10-5 Access List Configuration—MAC Tab
The MAC tab contains one area: MAC.
MAC
The MAC area contains one field:
MAC Address—Type in the MAC address for the packets to be classified.
IP Extended Tab
The IP Extended tab appears as follows.
Figure 10-6 Access List Configuration Window—IP Extended Tab
The IP Extended tab contains one area: IP Extended. The IP Extended area is further split into three subareas:
•
•
•
IP Extended
The IP Extended area 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 - 255. Valid protocol names are as follows:
Table 10-1 Valid Protocol Names
ahp
ipinip
eigrp
nos
gre
ospf
icmp
pcp
igmp
pim
igrp
tcp
ip
udp
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 areas 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 subarea in the Source and Destination areas 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
Step 1
Figure 10-7 CAR Policy Apply Window
Step 2
Step 3
Note
Step 4
If the interface is being managed, then the selected CAR policies are 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 a CAR policies from an interface, proceed as follows:
Step 1
Any CAR policies that are currently applied to the selected interface appear in the required order list in the CAR Policy Apply tab. Any available CAR policies that are not being used appear in the available policies list in the CAR Policy Apply tab.
Step 2
Step 3
Changing the Ordering of CAR Policies on an Interface
To change the ordering of CAR policies already applied to an interface, proceed as follows:
Step 1
Any CAR policies that are currently applied to the selected interface appear in the required order list in the CAR Policy Apply tab. Any available CAR policies that are not being used appear in the available policies list in the CAR Policy Apply tab.
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 any interfaces. Once you have applied a CAR policy to an interface, you cannot edit or delete it unless you remove it from the interface. If that CAR policy is being used by any other interfaces, 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 10-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 areas, Actions and Apply Status.
Available Policies—Lists all created CAR Policies that are available to apply to a selected interface.
Required Order—Lists all CAR policies that are applied to the selected interface.
Actions
The Actions area contains three buttons, as follows:
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—Allows you to apply the CAR policies in the Required Order list to the selected interface.
Apply Status
The Apply Status area 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 Status
The CAR Status section covers the following area:
Viewing the CAR Status
The CAR Policy Status window shows you what CAR policies are currently applied to a selected interface, and in what order.
Step 1
Figure 10-9 CAR Policy Status Window
Step 2
All of the current CAR policies that are applied to the selected interface appear, in numerical order, in the pane at right.
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. Only one CoS queue group can be applied to any amount of interfaces at a time.
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
Step 1
Layer 3 QoS>WRED>CoS Queue Group Configuration. The CoS Queue Group Configuration window appears.Figure 10-10 CoS Queue Group Configuration Window—CoS Queue Group Tab
Step 2
Step 3
A window appears, confirming if you were successful or not. The name of your new CoS queue group appears in the list box at left.
Step 4
Step 5
Editing or Deleting an Existing CoS Queue Group
An existing CoS queue group can only be edited or deleted if it is not currently being applied to any interfaces. Once you have applied a CoS queue group to an interface, you cannot edit or delete it unless you remove it from the interface. If that CoS queue group is being used by any other interfaces, you will still not be able to edit or delete the CoS queue group. For this reason, it is a good idea to note down which interfaces have which CoS queue groups applied to them. If you keep such a list, if you later want to edit or delete the CoS queue group, you can simply remove it from the interfaces that are using it, then proceed to edit the fields within the CoS Queue Group Configuration window or delete the CoS queue group.
To delete an existing CoS queue group, proceed as follows:
Step 1
Step 2
Figure 10-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 areas: IP Precendence and WRED Parameters. The CoS Queue Group tab also has one outside field, as follows:
Exponential Weighting Constant—(numbers 0-15) Sets the weight used in calculating the average queue depth for this COS queue group.
IP Precedence
The IP Precendence area contains two headings: IP Precendence and Drop Label.
IP Precendence—This area allows the user to map packets that have a particular IP precendence 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, precendence values are mapped so that they are not dropped due to WRED.
Drop Label—Select a number, 1 - 6, which is the number of the corresponding drop label in the WRED parameters table.
WRED Parameters
The WRED Parameters area contains 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 10-12 CoS Queue Group Configuration Window—DRR Tab
The DRR tab has two areas: DRR Mapping and DRR Queue. There is also a Low-latency field.
DRR Mapping
The DRR Mapping area allows you to map a particular IP precedence to a regular DRR queue (values 0-6 or low-latency).
DRR Queue
The DRR Queue area 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 area.
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 10-13 WRED Tx Configuration Window
Step 2
Step 3
Step 4
Note
Removing a CoS Queue Group from an Interface
To remove an applied CoS queue group from an interface, follow the steps above but, instead of clicking Apply, click Remove.
Changing the Association of a CoS Queue Group
If you want to apply a different CoS queue group to a selected interface or interfaces, you can simply follow steps 1 - 2 above, then select the new CoS queue group you want to apply, and click Apply. Any previously applied CoS queue groups are removed and the new CoS queue group is applied.
WRED Tx Configuration Window—Detailed Description
The WRED Tx Configuration window contains two areas:
•
•
Available COS Queue Group
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.
Apply—Once you have highlighted the CoS queue group in the Available COS Queue Group list, click Apply to apply it to the selected interface.
Remove—Once you have highlighted the CoS queue group in the Available COS Queue Group list, click 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:
•
•
•
Feedback