HP 5830 Configuration Manual

Download

Page 1

HP 5830 Switch Series

CL and QoS

Configuration Guide

Part number: 5998-2066

Software version: Release 1115, Release 1118

Document version: 6W101-20130604

Page 2

Legal and notice information

No part of this documentation may be reproduced or transmitted in any form or by any means without prior written consent of Hewlett-Packard Development Company, L.P.

The information contained herein is subject to change without notice.

HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this material.

The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Page 3

Contents

Configuring ACLs ························································································································································· 1

Applications on the switch ······································································································································ 1 ACL categories ························································································································································· 1 Numbering and naming ACLs ································································································································ 1 Match order ······························································································································································ 2 Rule comments and rule range remarks ················································································································· 2 Rule numbering ························································································································································· 3 Implementing time-based ACL rules ························································································································ 3

Fragments filtering with ACLs ·································································································································· 3 Configuration task list ······················································································································································· 4 Configuring a time range ················································································································································· 4 Configuring a basic ACL ·················································································································································· 4

Configuring an IPv4 basic ACL ······························································································································ 4

Configuring an IPv6 basic ACL ······························································································································ 5 Configuring an advanced ACL ········································································································································ 6

Configuring an IPv4 advanced ACL······················································································································· 6

Configuring an IPv6 advanced ACL······················································································································· 7 Configuring an Ethernet frame header ACL ··················································································································· 8 Copying an ACL ······························································································································································· 9

Copying an IPv4 basic, IPv4 advanced, or Ethernet frame header ACL ··························································· 9

Copying an IPv6 basic or IPv6 advanced ACL ·································································································· 10 Configuring packet filtering with ACLs ························································································································ 10

Applying an IPv4 basic, IPv4 advanced, or Ethernet frame header ACL for packet filtering ······················· 10

Applying an IPv6 basic or IPv6 advanced ACL for packet filtering ································································ 11 Displaying and maintaining ACLs ································································································································ 11 ACL configuration examples ········································································································································· 11

IPv4 packet filtering configuration example ······································································································· 12

IPv6 packet filtering configuration example ······································································································· 12

QoS overview ····························································································································································· 14

QoS service models ······················································································································································· 14

Best-effort service model ······································································································································· 14

IntServ model ························································································································································· 14

DiffServ model ······················································································································································· 14 QoS techniques ······························································································································································ 15

QoS configuration approaches································································································································· 16

MQC approach ····················································································································································· 16

Non-MQC approach ············································································································································ 16 Configuring a QoS policy ············································································································································· 16

Defining a class ····················································································································································· 17

Defining a traffic behavior ··································································································································· 19

Defining a policy ··················································································································································· 19

Applying the QoS policy ······································································································································ 20

Displaying and maintaining QoS policies ·········································································································· 21

Configuring priority mapping ··································································································································· 22

Page 4

Types of priorities ·················································································································································· 22

Priority mapping tables ········································································································································· 22

Priority trust mode on a port ································································································································· 23

Priority mapping procedure ································································································································· 23 Priority mapping configuration task list ······················································································································· 24 Configuring a priority mapping table ·························································································································· 24 Configuring the priority trust mode ······························································································································ 24 Changing the port priority of an interface ·················································································································· 25 Displaying and maintaining priority mapping ············································································································ 25 Priority mapping configuration examples ···················································································································· 25

Priority trust mode configuration example ·········································································································· 25

Priority mapping table and priority marking configuration example ······························································ 26

Configuring traffic policing, traffic shaping, and rate limit ···················································································· 30

Traffic evaluation and token buckets ··················································································································· 30

Traffic policing ······················································································································································· 31

Traffic shaping ······················································································································································· 32

Rate limit ································································································································································· 32 Configuring traffic policing ··········································································································································· 33 Configuring GTS ···························································································································································· 34 Configuring the rate limit ·············································································································································· 35 Displaying and maintaining traffic policing, GTS, and rate limit ············································································· 35 Traffic policing and GTS configuration example ········································································································ 35

Network requirements ··········································································································································· 35

Configuration procedures ····································································································································· 36

Configuring congestion management ······················································································································ 39

Causes, impacts, and countermeasures ·············································································································· 39

Congestion management techniques ·················································································································· 39 Congestion management configuration task list ········································································································· 43 Configuring SP queuing ················································································································································ 43 Configure WRR queuing ··············································································································································· 43 Configuring WFQ queuing ··········································································································································· 44 Configuring SP+WRR queuing ····································································································································· 45 Configuring SP+WFQ queuing ···································································································································· 46

Configuring congestion avoidance ··························································································································· 48

Overview ········································································································································································· 48 WRED configuration overview······································································································································ 48

Configuration approaches ··································································································································· 49

Parameters······························································································································································ 49 Configuring WRED ························································································································································ 49 Displaying and maintaining WRED ····························································································································· 49 WRED configuration example ······································································································································ 50

Configuring traffic filtering ········································································································································ 51

Configuration procedure ··············································································································································· 51 Configuration example ·················································································································································· 52

Configuring priority marking ····································································································································· 53

Page 5

Configuring traffic redirecting ··································································································································· 57

Configuration restrictions and guidelines ···················································································································· 57 Configuration procedure ··············································································································································· 57 Traffic redirecting configuration example ··················································································································· 58

Configuring class-based accounting ························································································································· 60

Configuration procedure ··············································································································································· 60 Displaying and maintaining class-based traffic accounting ······················································································ 61 Configuration example ·················································································································································· 61

Appendix ···································································································································································· 62

Appendix A Default priority mapping tables ·············································································································· 62 Appendix B Introduction to packet precedences ········································································································ 63

IP precedence and DSCP values ·························································································································· 63

802.1p priority ······················································································································································ 64

Support and other resources ····································································································································· 66

Contacting HP ································································································································································ 66

Subscription service ·············································································································································· 66 Related information ························································································································································ 66

Documents ······························································································································································ 66

Websites ································································································································································· 66 Conventions ···································································································································································· 67

Index ··········································································································································································· 69

iii

Page 6

Configuring ACLs

An access control list (ACL) is a set of rules (or permit or deny statements) for identifying traffic based on criteria such as source IP address, destination IP address, and port number.

Overview

ACLs are primarily used for packet filtering. "Configuring packet filtering with ACLs" provides an example. You can use ACLs in Quality of Service (QoS), routing, and other feature modules for identifying traffic. The packet drop or forwarding decisions varies with the modules that use ACLs.

Applications on the switch

An ACL is implemented in hardware or software, depending on the module that uses it. If the module is implemented in hardware (for example, the packet filter or QoS module), the ACL is applied to hardware to process traffic. If the module is implemented in software (for example, the routing or user interface access control module such as Telnet, SNMP, or web), the ACL is applied to software to process traffic.

The user interface access control module denies packets that do not match any ACL. Some modules (QoS, for example), ignore the permit or deny action in ACL rules and do not base their drop or forwarding decisions on the action set in ACL rules. See the specified module for information about ACL application.

ACL categories

Category ACL number IP version

Basic ACLs 2000 to 2999

Advanced ACLs 3000 to 3999

Ethernet frame header ACLs

4000 to 4999 IPv4 and IPv6

IPv4 Source IPv4 address

IPv6 Source IPv6 address

IPv4

IPv6

Numbering and naming ACLs

Each ACL category has a unique range of ACL numbers. When creating an ACL, you must assign it a number. In addition, you can assign the ACL a name for ease of identification. After creating an ACL with a name, you cannot rename it or delete its name.

Match criteria

Source IPv4 address, destination IPv4 address, packet priority, protocols over IPv4, and other Layer 3 and Layer 4 header fields

Source IPv6 address, destination IPv6 address, packet priority, protocols over IPv6, and other Layer 3 and Layer 4 header fields

Layer 2 header fields, such as source and destination MAC addresses, 802.1p priority, and link layer protocol type

For an IPv4 basic or advanced ACLs, its ACL number and name must be unique in IPv4, and for an IPv6 basic or advanced ACL, its ACL number and name must be unique in IPv6.

Page 7

Match order

gory

The rules in an ACL are sorted in a specific order. When a packet matches a rule, the device stops the matching process and performs the action defined in the rule. If an ACL contains overlapping or conflicting rules, the matching result and action to take depend on the rule order.

The following ACL match orders are available:

• config—Sorts ACL rules in ascending order of rule ID. A rule with a lower ID is matched before a

rule with a higher ID. If you use this method, carefully check the rules and their order.

• auto—Sorts ACL rules in depth-first order. Depth-first ordering makes sure that any subset of a rule

is always matched before the rule. Table 1 lists the uses to sort rules for each type of ACL.

Table 1 Sorting ACL rules in depth-first order

sequence of tie breakers that depth-first ordering

ACL cate

IPv4 basic ACL

IPv4 advanced ACL

IPv6 basic ACL

IPv6 advanced ACL

Ethernet frame header ACL

Sequence of tie breakers

1. VPN instance

2. More 0s in the source IP address wildcard (more 0s means a narrower IP

address range)

3. Rule configured earlier

4. VPN instance

5. Specific protocol type rather than IP (IP represents any protocol over IP)

6. More 0s in the source IP address wildcard mask

7. More 0s in the destination IP address wildcard

8. Narrower TCP/UDP service port number range

9. Rule configured earlier

10. VPN instance

11. Longer prefix for the source IP address (a longer prefix means a narrower IP

address range)

12. Rule configured earlier

13. VPN instance

14. Specific protocol type rather than IP (IP represents any protocol over IPv6)

15. Longer prefix for the source IPv6 address

16. Longer prefix for the destination IPv6 address

17. Narrower TCP/UDP service port number range

18. Rule configured earlier

19. More 1s in the source MAC address mask (more 1s means a smaller MAC

address)

20. More 1s in the destination MAC address mask

21. Rule configured earlier

A wildcard mask, also called an inverse mask, is a 32-bit binary and represented in dotted decimal notation. In contrast to a network mask, the 0 bits in a wildcard mask represent "do care" bits, and the 1 bits represent "don't care" bits. If the "do care" bits in an IP address are identical to the "do care" bits in an IP address criterion, the IP address matches the criterion. All "don't care" bits are ignored. The 0s and 1s in a wildcard mask can be noncontiguous. For example, 0.255.0.255 is a valid wildcard mask.

Rule comments and rule range remarks

Add a comment about an ACL rule to make it easy to understand. The rule comment appears below the rule statement.

Page 8

In addition, add a rule range remark to indicate the start or end of a range of rules created for the same purpose.

Rule numbering

ACL rules can be manually numbered or automatically numbered. This section describes how automatic ACL rule numbering works.

Rule numbering step

If you do not assign an ID to the rule you are creating, the system automatically assigns it a rule ID. The rule numbering step sets the increment by which the system automatically numbers rules. For example, the default ACL rule numbering step is 5. If you do not assign IDs to rules you are creating, they are automatically numbered 0, 5, 10, 15, and so on. The wider the numbering step, the more rules you can insert between two rules.

By introducing a gap between rules rather than contiguously numbering rules, you have the flexibility of inserting rules in an ACL. This feature is important for a config order ACL, where ACL rules are matched in ascending order of rule ID.

Automatic rule numbering and renumbering

The ID automatically assigned to an ACL rule takes the nearest higher multiple of the numbering step to the current highest rule ID, starting with 0.

For example, if the numbering step is 5 (the default), and there are five ACL rules numbered 0, 5, 9, 10, and 12, the newly defined rule is numbered 15. If the ACL does not contain any rules, the first rule is numbered 0.

Whenever the step changes, the rules are renumbered, starting from 0. For example, if there are five rules numbered 5, 10, 13, 15, and 20, changing the step from 5 to 2 causes the rules to be renumbered 0, 2, 4, 6, and 8.

Implementing time-based ACL rules

You can implement ACL rules based on the time of day by applying a time range to them. A time-based ACL rule only takes effect in any time periods specified by the time range.

The following basic types of time range are available:

• Periodic time range—Recurs periodically on a day or days of the week.

• Absolute time range—Represents only a period of time and does not recur.

You can specify a time range in ACL rules before or after you create it. However, the rules using the time range take effect only after you define the time range.

Fragments filtering with ACLs

Traditional packet filtering matches only first fragments of packets, and allows all subsequent non-first fragments to pass through. Attackers can fabricate non-first fragments to attack networks.

To avoid the risks, the HP ACL implementation does the following:

• Filters all fragments by default, including non-first fragments.

• Allows for matching criteria modification, for example, filters only non-first fragments.

Page 9

Configuration task list

Task Remarks

Configuring a time range

Configuring a basic ACL

Configuring an advanced ACL

Configuring an Ethernet frame header ACL

Copying an ACL

Configuring packet filtering with ACLs

Configuring a time range

You can create a maximum of 256 time ranges, each having a maximum of 32 periodic statements and 12 absolute statements. If a time range has multiple statements, its active period is calculated as follows:

1. Combining all periodic statements.

2. Combining all absolute statements.

3. Taking the intersection of the two statement sets as the active period of the time range.

Optional.

Applicable to IPv4 and IPv6.

Required.

Configure at least one task.

Applicable to IPv4 and IPv6.

Optional.

Applicable to IPv4 and IPv6.

Optional.

Applicable to IPv4 and IPv6.

To configure a time range:

Step Command

1. Enter system view. system-view N/A

time-range time-range-name

2. Configure a time

range.

{ start-time to end-time days [ from

time1 date1 ] [ to time2 date2 ] | from time1 date1 [ to time2 date2 ]

| to time2 date2 }

Configuring a basic ACL

This section describes how to configure an IPv4 basic ACL and an IPv6 basic ACL.

Configuring an IPv4 basic ACL

IPv4 basic ACLs match packets based only on source IP addresses.

To configure an IPv4 basic ACL:

Remarks

By default, no time range exists.

Repeat this command with the same time range name to create multiple statements for a time range.

Page 10

Step Command Remarks

1. Enter system

view.

2. Create an IPv4

basic ACL and enter its view.

3. Configure a

description for the IPv4 basic ACL.

4. Set the rule

numbering step.

5. Create or edit a

rule.

6. Add or edit a

rule comment.

7. Add or edit a

rule range remark.

8. Enable

counting ACL rule matches performed in hardware.

system-view N/A

acl number acl-number

[ name acl-name ] [ match-order { auto |

config } ]

description text

step step-value

rule [ rule-id ] { deny | permit } [ counting | fragment

| logging | source { source-address

source-wildcard | any } | time-range time-range-name | vpn-instance

vpn-instance-name ] *

rule rule-id comment text

rule [ rule-id ] remark text

hardware-count enable

By default, no ACL exists.

IPv4 basic ACLs are numbered in the range of 2000 to

2999.

You can use the acl name acl-name command to enter the view of a named ACL.

Optional.

By default, an IPv4 basic ACL has no ACL description.

Optional.

The default setting is 5.

By default, an IPv4 basic ACL does not contain any rules.

• If the ACL is for QoS traffic classification, do not

• If the ACL is for packet filtering, do not specify the

Optional.

By default, no rule comments are configured.

Optional.

By default, no rule range remarks are configured.

Optional.

By default, this feature is disabled.

When the ACL is referenced by a QoS policy, this command does not take effect.

specify the vpn-instance keyword. Also, the logging and counting keywords (even if specified) do not take effect.

vpn-instance keyword.

Configuring an IPv6 basic ACL

IPv6 basic ACLs match packets based only on source IP addresses.

To configure an IPv6 basic ACL:

Step Command Remarks

1. Enter system view.

2. Create an IPv6

basic ACL view and enter its view.

system-view N/A

By default, no ACL exists.

acl ipv6 number acl6-number [ name acl6-name ] [ match-order { auto | config } ]

IPv6 basic ACLs are numbered in the range of 2000 to 2999.

You can use the acl ipv6 name acl6-name command to enter the view of a named ACL.

Page 11

Step Command Remarks

3. Configure a

description for the IPv6 basic ACL.

4. Set the rule

numbering step.

5. Create or edit a

rule.

6. Add or edit a rule

comment.

7. Add or edit a rule

range remark.

8. Enable counting

ACL rule matches performed in hardware.

description text

step step-value

rule [ rule-id ] { deny | permit }

[ counting | fragment | logging | routing [ type routing-type ] |

source { source-address source-prefix | source-address/source-prefix |

any } | time-range

time-range-name | vpn-instance vpn-instance-name ] *

rule rule-id comment text

rule [ rule-id ] remark text

hardware-count enable

Optional.

By default, an IPv6 basic ACL has no ACL description.

Optional.

The default setting is 5.

By default, an IPv6 basic ACL does not contain any rules.

• If the ACL is for QoS traffic classification, do

not specify the fragment, routing, or vpn-instance keyword. Also, the logging and counting keywords (even if specified) do not

take effect.

• If the ACL is for packet filtering, do not specify

the fragment, routing, or vpn-instance keyword.

Optional.

By default, no rule comments are configured.

Optional.

By default, no rule range remarks are configured.

Optional.

By default, this feature is disabled.

When the ACL is referenced by a QoS policy, this command does not take effect.

Configuring an advanced ACL

This section describes how to configure an IPv4 advanced ACL and an IPv6 advanced ACL.

Configuring an IPv4 advanced ACL

IPv4 advanced ACLs match packets based on source IP addresses, destination IP addresses, packet priorities, protocols over IP, and other protocol header information, such as TCP/UDP source and destination port numbers, TCP flags, ICMP message types, and ICMP message codes.

Compared to IPv4 basic ACLs, IPv4 advanced ACLs allow more flexible and accurate filtering.

To configure an IPv4 advanced ACL:

Step Command Remarks

1. Enter system view.

2. Create an IPv4

advanced ACL and enter its view.

system-view N/A

acl number acl-number [ name acl-name ] [ match-order { auto | config } ]

By default, no ACL exists.

IPv4 advanced ACLs are numbered in the range of 3000 to 3999.

You can use the acl name acl-name command to enter the view of a named ACL.

Page 12

Step Command Remarks

3. Configure a

description for the IPv4 advanced ACL.

4. Set the rule

numbering step.

5. Create or edit a rule.

description text

step step-value

rule [ rule-id ] { deny | permit }

protocol [ { { ack ack-value | fin fin-value | psh psh-value | rst rst-value | syn syn-value | urg urg-value } * | established } |

counting | destination { dest-address dest-wildcard |

any } | destination-port operator port1 [ port2 ] | dscp dscp |

fragment | icmp-type { icmp-type [ icmp-code ] | icmp-message } | logging | precedence precedence | source { source-address source-wildcard | any } | source-port operator

port1 [ port2 ] | time-range time-range-name | tos tos | vpn-instance v

pn-instance-name ]

Optional.

By default, an IPv4 advanced ACL has no ACL description.

Optional.

The default setting is 5.

By default, an IPv4 advanced ACL does not contain any rules.

If an IPv4 advanced ACL is for QoS traffic classification or packet filtering:

• Do not specify the vpn-instance keyword

or specify neq for the operator argument.

• The logging and counting keywords

(even if specified) do not take effect for QoS traffic classification.

6. Add or edit a rule

comment.

7. Add or edit a rule

range remark.

8. Enable counting ACL

rule matches performed in hardware.

rule rule-id comment text

rule [ rule-id ] remark text

hardware-count enable

Configuring an IPv6 advanced ACL

IPv6 advanced ACLs match packets based on the source IPv6 addresses, destination IPv6 addresses, packet priorities, protocols carried over IPv6, and other protocol header fields such as the TCP/UDP source port number, TCP/UDP destination port number, ICMPv6 message type, and ICMPv6 message code.

Compared to IPv6 basic ACLs, IPv6 advanced ACLs allow more flexible and accurate filtering.

To configure an IPv6 advanced ACL:

Optional.

By default, no rule comments are configured.

Optional.

By default, no rule range remarks are configured.

Optional.

By default, this feature is disabled.

When the ACL is referenced by a QoS policy, this command does not take effect.

Step Command Remarks

1. Enter system view. system-view N/A

Page 13

Step Command Remarks

By default, no ACL exists.

2. Create an IPv6

advanced ACL and enter its view.

3. Configure a

description for the IPv6 advanced ACL.

4. Set the rule

numbering step.

acl ipv6 number acl6-number [ name acl6-name ] [ match-order { auto | config } ]

description text

step step-value

IPv6 advanced ACLs are numbered in the range of 3000 to 3999.

You can use the acl ipv6 name acl6-name command to enter the view of a named ACL.

Optional.

By default, an IPv6 advanced ACL has no ACL description.

Optional.

The default setting is 5.

5. Create or edit a

rule.

6. Add or edit a rule

comment.

7. Add or edit a rule

range remark.

rule [ rule-id ] { deny | permit } protocol

[ { { ack ack-value | fin fin-value | psh psh-value | rst rst-value | syn syn-value

| urg urg-value } * | established } | counting | destination { dest-address

dest-prefix | dest-address/dest-prefix |

any } | destination-port operator port1 [ port2 ] | dscp dscp | flow-label

flow-label-value | fragment | icmp6-type { icmp6-type icmp6-code |

icmp6-message } | logging | routing [ type routing-type ] | source { source-address source-prefix |

source-address/source-prefix | any } | source-port operator port1 [ port2 time-range time-range-name | vpn-instance vpn-instance-name ] *

rule rule-id comment text

rule [ rule-id ] remark text

] |

By default, an IPv6 advanced ACL does not contain any rules.

When the protocol argument takes 43, 44, 51, or 60, the ACL cannot function for the outbound QoS application.

If an IPv6 advanced ACL is for QoS traffic classification or packet filtering:

• Do not specify the fragment, routing, or

vpn-instance keyword or specify neq

for the operator argument.

• Do not specify the flow-label keyword if

the ACL is for outbound QoS traffic classification or outbound packet filtering.

• The logging and counting keywords

(even if specified) do not take effect for QoS traffic classification.

Optional.

By default, no rule comments are configured.

Optional.

By default, no rule range remarks are configured.

8. Enable counting

ACL rule matches performed in hardware.

hardware-count enable

Optional.

By default, this feature is disabled.

When the ACL is referenced by a QoS policy, this command does not take effect.

Configuring an Ethernet frame header ACL

Ethernet frame header ACLs, also called "Layer 2 ACLs," match packets based on Layer 2 protocol header fields, such as source MAC address, destination MAC address, 802.1p priority (VLAN priority), and link layer protocol type.

To configure an Ethernet frame header ACL:

Page 14

Step Command Remarks

1. Enter system view. system-view N/A

2. Create an

Ethernet frame header ACL and enter its view.

3. Configure a

description for the Ethernet frame header ACL.

4. Set the rule

numbering step.

5. Create or edit a

rule.

acl number acl-number [ name acl-name ] [ match-order { auto |

config } ]

description text

step step-value

rule [ rule-id ] { deny | permit } [ cos vlan-pri | counting | dest-mac

dest-address dest-mask | { lsap lsap-type

lsap-type-mask | type protocol-type protocol-type-mask } | source-mac source-address source-mask | time-range time-range-name ] *

By default, no ACL exists.

Ethernet frame header ACLs are numbered in the range of 4000 to 4999.

You can use the acl name acl-name command to enter the view of a named Ethernet frame header ACL.

Optional.

By default, an Ethernet frame header ACL has no ACL description.

Optional.

The default setting is 5.

By default contain any rules.

If the ACL is for QoS traffic classification or packet filtering, to use the lsap keyword, the lsap-type argument must be AAAA, and the lasp-type-mask argument must be FFFF. Otherwise, the ACL cannot function normally.

an Ethernet frame header ACL does not

6. Add or edit a rule

comment.

7. Add or edit a rule

range remark.

8. Enable rule match

counting for the Ethernet frame header ACL.

rule rule-id comment text

rule [ rule-id ] remark text

hardware-count enable

Optional.

By default, no rule comments are configured.

Optional.

By default, no rule range remarks are configured.

Optional.

By default, rule match counting is disabled for an Ethernet frame header ACL.

Copying an ACL

You can create an ACL by copying an existing ACL (source ACL). The new ACL (destination ACL) has the same properties and content as the source ACL, but not the same ACL number and name.

To successfully copy an ACL, make sure that:

• The destination ACL number is from the same category as the source ACL number.

• The source ACL already exists, but the destination ACL does not.

Copying an IPv4 basic, IPv4 advanced, or Ethernet frame header ACL

Page 15

Step Command

1. Enter system view. system-view

2. Copy an existing IPv4

basic, IPv4 advanced, or Ethernet frame header ACL to create a new ACL.

acl copy { source-acl-number | name source-acl-name } to { dest-acl-number | name dest-acl-name }

Copying an IPv6 basic or IPv6 advanced ACL

Step Command

1. Enter system view.

2. Co py a n existing I P v 6 basic or

IPv6 advanced ACL to create a new ACL.

system-view

acl ipv6 copy { source-acl6-number | name source-acl6-name } to

{ dest-acl6-number | name dest-acl6-name }

Configuring packet filtering with ACLs

You can use an ACL to filter incoming or outgoing IPv4 or IPv6 packets.

ACLs on VLAN interfaces filter only packets forwarded at Layer 3.

When you configure packet filtering with ACLs on a port, you can use IPv4 ACLs, IPv6 ACLs, or Ethernet frame header ACLs. In a direction of a port, you can use only one ACL of a type.

NOTE:

Bridge mode (Layer 2) Ethernet ports, route mode (Layer 3) Ethernet ports, and VLAN interfaces suppor configuring packet filtering with ACLs. The term "interface" in this section collectively refers to these types of ports. You can use the port link-mode command to set an Ethernet port to operate in brid mode (see

Layer 2—LAN Switching Configuration Guide

e or route

Applying an IPv4 basic, IPv4 advanced, or Ethernet frame header ACL for packet filtering

Step Command

1. Enter system view.

2. Enter interface view.

3. Apply an IPv4 basic, IPv4

advanced, or Ethernet frame header ACL to the interface to filter packets.

system-view N/A

interface interface-type

interface-number

packet-filter { acl-number | name acl-name } { inbound | outbound }

Remarks

N/A

By default, no ACL is applied to any interface.

Make sure no one is applying an ACL to the interface when you are doing the operation.

Page 16

Applying an IPv6 basic or IPv6 advanced ACL for packet filtering

Step Command

1. Enter system view.

2. Enter interface view.

3. Apply an IPv6 basic or IPv6

advanced ACL to the interface to filter IPv6 packets.

system-view N/A

interface interface-type

interface-number

packet-filter ipv6 { acl6-number | name acl6-name } { inbound | outbound }

Displaying and maintaining ACLs

Task Command

Display configuration and match statistics for IPv4 basic, IPv4 advanced, and Ethernet frame header ACLs.

display acl { acl-number | all | name acl-name } [ slot slot-number ] [ | { begin |

exclude | include } regular-expression ]

Remarks

N/A

By default, no ACL is applied to the interface.

Make sure no one is applying an ACL to the interface when you are doing the operation.

Remarks

Available in any view.

Display configuration and match statistics for IPv6 basic and IPv6 advanced ACLs.

Display the usage of ACL rules.

Display the application status of packet filtering ACLs on interfaces.

Display the configuration and status of one or all time ranges.

Clear statistics for one or all IPv4 basic, IPv4 advanced, and Ethernet frame header ACLs.

Clear statistics for one or all IPv6 basic and advanced ACLs.

display acl ipv6 { acl6-number | all | name acl6-name } [ slot slot-number ] [ | { begin |

exclude | include } regular-expression ]

display acl resource [ slot slot-number ] [ | { begin | exclude | include }

regular-expression ]

display packet-filter { { all | interface interface-type interface-number } [ inbound | outbound ] | interface vlan-interface

vlan-interface-number [ inbound | outbound ] [ slot slot-number ] } [ | { begin | exclude |

include } regular-expression ]

display time-range { time-range-name | all } [ | { begin | exclude | include }

regular-expression ]

reset acl counter { acl-number | all | name acl-name }

reset acl ipv6 counter { acl6-number | all | name acl6-name }

Available in any view.

Available in user view.

ACL configuration examples

This section provides ACL configuration examples.

Page 17

IPv4 packet filtering configuration example

Network requirements

As shown in Figure 1, apply an ACL to the inbound direction of interface GigabitEthernet 1/0/1 on Device A so that every day, from 8:00 to 18:00, the interface allows only packets sourced from Host A to pass.

Figure 1 Network diagram

Configuration procedure

# Create a time range from 08:00 to 18:00 every day.

<DeviceA> system-view [DeviceA] time-range study 8:00 to 18:00 daily

# Create IPv4 basic ACL 2009, and configure two rules in the ACL. One rule permits packets sourced from Host A and the other denies packets sourced from any other host during the time range study.

[DeviceA] acl number 2009 [DeviceA-acl-basic-2009] rule permit source 192.168.1.2 0 time-range study [DeviceA-acl-basic-2009] rule deny source any time-range study [DeviceA-acl-basic-2009] quit

# Configure the device to output informational log messages to the console.

[DeviceA] info-center source default channel 0 log level informational

# Apply IPv4 basic ACL 2009 to filter incoming packets on GigabitEthernet 1/0/1.

[DeviceA] interface gigabitethernet 1/0/1 [DeviceA-GigabitEthernet1/0/1] packet-filter 2009 inbound [DeviceA-GigabitEthernet1/0/1] quit

IPv6 packet filtering configuration example

Network requirements

As shown in Figure 2, apply an ACL to the incoming traffic of GigabitEthernet 1/0/1 on Device A so that every day, from 8:00 to 18:00, the interface allows only packets from Host A to pass through. Configure

Page 18

Figure 2 Network diagram

Configuration procedure

# Create a time range from 08:00 to 18:00 every day.

<DeviceA> system-view [DeviceA] time-range study 8:0 to 18:0 daily

# Create IPv6 basic ACL 2009, and configure two rules for the ACL. One permits packets sourced from Host A and the other denies packets sourced from any other host during the time range study.

[DeviceA] acl ipv6 number 2009 [DeviceA-acl6-basic-2009] rule permit source 1001::2 128 time-range study [DeviceA-acl6-basic-2009] rule deny source any time-range study [DeviceA-acl6-basic-2009] quit

# Configure the device to output informational log messages to the console.

[DeviceA] info-center source default channel 0 log level informational

# Apply IPv6 basic ACL 2009 to filter incoming packets on GigabitEthernet 1/0/1.

[DeviceA] interface gigabitethernet 1/0/1 [DeviceA-GigabitEthernet1/0/1] packet-filter ipv6 2009 inbound [DeviceA-GigabitEthernet1/0/1] quit

Page 19

QoS overview

In data communications, Quality of Service (QoS) is a network's ability to provide differentiated service guarantees for diversified traffic in terms of bandwidth, delay, jitter, and drop rate.

Network resources are scarce. The contention for resources requires that QoS prioritize important traffic flows over trivial ones. For example, when bandwidth is fixed, more bandwidth for one traffic flow means less bandwidth for the other traffic flows. When making a QoS scheme, consider the characteristics of various applications to balance the interests of diversified users and to utilize network resources.

The following section describes some typical QoS service models and widely used, mature QoS techniques.

QoS service models

This section describes the QoS service models.

Best-effort service model

The best-effort model is a single-service model and is also the simplest service model. In this service model, the network does its best to deliver packets, but does not guarantee delivery or reliability.

The best-effort service model is the default model in the Internet and applies to most network applications. It uses the first in first out (FIFO) queuing mechanism.

IntServ model

The integrated service (IntServ) model is a multiple-service model that can accommodate diverse QoS requirements. This service model provides the most granularly differentiated QoS because it identifies and guarantees definite QoS for each data flow.

In the IntServ model, an application must request service from the network before it sends data. IntServ signals the service request with the Resource Reservation Protocol (RSVP). All nodes receiving the request reserve resources as requested and maintain state information for the application flow.

The IntServ model demands high storage and processing capabilities, because it requires all nodes along the transmission path to maintain resource state information for each flow. This model is suitable for small-sized or edge networks, but not large-sized networks, for example, the core layer of the Internet, where billions of flows are present.

DiffServ model

The differentiated service (DiffServ) model is a multiple-service model that can meet diverse QoS requirements. It is easy to implement and extend. DiffServ does not signal the network to reserve resources before sending data, as IntServ does.

All QoS techniques in this document are based on the DiffServ model.

Page 20

QoS techniques

The QoS techniques include traffic classification, traffic policing, traffic shaping, rate limit, congestion management, and congestion avoidance. The following section briefly introduces these QoS techniques.

Figure 3 Position of the QoS techniques in a network

As shown in Figure 3, traffic classification, traffic shaping, traffic policing, congestion management, and congestion avoidance mainly implement the following functions:

• Traffic classification uses certain match criteria to assign packets with the same characteristics to a

class. You can provide differentiated services based on classes.

• Traffic policing polices flows entering or leaving a device, and imposes penalties on traffic flows

that exceed the preset threshold to prevent aggressive use of network resources. You can apply traffic policing to both incoming and outgoing traffic of a port.

• To eliminate packet drops, traffic shaping proactively adapts the output rate of traffic to the network

resources available on the downstream device. Traffic shaping usually applies to the outgoing traffic of a port.

• Congestion management provides a resource scheduling policy to determine the packet forwarding

sequence when congestion occurs. Congestion management usually applies to the outgoing traffic of a port.

• Congestion avoidance monitors the network resource usage and is usually applied to the outgoing

traffic of a port. When congestion worsens, congestion avoidance reduces the queue length by dropping packets.

Page 21

QoS configuration approaches

This chapter describes the QoS configuration approaches.

Overview

You can configure QoS in the following approaches:

• MQC approach

• Non-MQC approach

ome features support both approaches, but some support only one.

MQC approach

In the modular QoS configuration (MQC) approach, you configure QoS service parameters by using QoS policies. A QoS policy defines the shaping, policing, or other QoS actions to take on different classes of traffic. It is a set of class-behavior associations.

A class is a set of match criteria for identifying traffic, and it uses the AND or OR operator:

• AND—A packet must match all criteria to match the class.

• OR—A packet matches the class if it matches any of the criteria in the class.

A traffic behavior defines a set of QoS actions to take on packets, such as priority marking and redirect.

By associating a traffic behavior with a class in a QoS policy, you apply the specific set of QoS actions to the class of traffic.

Non-MQC approach

In the non-MQC approach, you configure QoS service parameters without using a QoS policy. For example, you can use the rate limit feature to set a rate limit on an interface without using a QoS policy.

Configuring a QoS policy

Figure 4 shows how to configure a QoS policy.

Page 22

Figure 4 QoS policy configuration procedure

Defining a class

This section describes how to define a class.

Configuration guidelines

If a class that uses the AND operator has multiple if-match acl, if-match acl ipv6, if-match customer-vlan-id or if-match service-vlan-id clauses, a packet that matches any of the clauses matches

the class.

To successfully execute the traffic behavior associated with a traffic class that uses the AND operator, define only one if-match clause for any of the following match criteria, and enter only one value for any of the following list arguments (for example, the 8021p-list argument):

• customer-dot1p 8021p-list

• destination-mac mac-address

• dscp dscp-list

• ip-precedence ip-precedence-list

• service-dot1p 8021p-list

• source-mac mac-address

To create multiple if-match clauses for these match criteria or specify multiple values for the list arguments, specify the operator of the class as OR and use the if-match command multiple times.

Configuration procedure

To define a class:

Page 23

Step Command

1. Enter system view.

2. Create a class and

enter class view.

3. Configure match

criteria.

Table 2 The value range for the

word and argument combination Description

acl [ ipv6 ] { acl-number | name acl-name }

system-view N/A

traffic classifier tcl-name [ operator { and | or } ]

if-match match-criteria

match-criteria

Remarks

By default, the operator of a class is AND.

The operator of a class can be AND or OR.

• AND—A packet is assigned to a class only when

the packet matches all criteria in the class.

• OR—A packet is assigned to a class if it matches

any of the criteria in the class.

For more information, see the if-match command in ACL and QoS Command Reference.

argument

Matches an ACL.

The acl-number argument is in the range of 2000 to 3999 for an IPv4 ACL, 2000 to 3999 for an IPv6 ACL, and 4000 to 4999 for an Ethernet frame header ACL.

The acl-name argument is a case-insensitive string of 1 to 63 characters that must start with an English letter, and to avoid confusion, it cannot be all.

any Matches all packets.

Matches DSCP values.

dscp dscp-list

destination-mac mac-address Matches a destination MAC address.

customer-dot1p 8021p-list

service-dot1p 8021p-list

ip-precedence ip-precedence-list

protocol protocol-name

source-mac mac-address Matches a source MAC address.

customer-vlan-id { vlan-id-list | vlan-id1 to

vlan-id2 }

The dscp-list a rgum e nt is a list o f up to e ight D SCP va lues. A DSCP value can be a number from 0 to 63 or any keyword in Table 7.

Matches the 802.1p priority of the customer network.

The 8021p-list argument is a list of up to eight 802.1p priority values. An 802.1p priority is in the range of 0 to 7.

Matches the 802.1p priority of the service provider network.

The 8021p-list argument is a list of up to eight 802.1p priority values. An 802.1p priority is in the range of 0 to 7.

Matches IP precedence.

The ip-precedence-list argument is a list of up to eight IP precedence values. An IP precedence is in the range of 0 to 7.

Matches a protocol.

The protocol-name argument can be IP or IPv6.

Matches the VLAN IDs of customer networks.

The vlan-id-list argument is a list of up to eight VLAN IDs. The

vlan-id1 to vlan-id2 specifies a VLAN ID range, where the vlan-id1 must be smaller than the vlan-id2. A VLAN ID is in the

range of 1 to 4094.

Page 24

Keyword and argument combination Description

service-vlan-id { vlan-id-list | vlan-id1 to

vlan-id2 }

Defining a traffic behavior

A traffic behavior is a set of QoS actions (such as traffic filtering, shaping, policing, and priority marking) to take on a class of traffic.

To define a traffic behavior:

Step Command

1. Enter system view.

2. Create a traffic behavior and

enter traffic behavior view

system-view

traffic behavior behavior-name

Matches the VLAN IDs of ISP networks.

The vlan-id-list is a list of up to eight VLAN IDs. The vlan-id1 to vlan-id2 specifies a VLAN ID range, where the vlan-id1 must be smaller than the vlan-id2. A VLAN ID is in the range of 1 to 4094.

3. Configure actions in the traffic

behavior.

Defining a policy

You associate a behavior with a class in a QoS policy to perform the actions defined in the behavior for the class of packets.

Configuration guidelines

• If an ACL is referenced by a QoS policy for defining traffic match criteria, packets matching the ACL

are organized as a class and the behavior defined in the QoS policy applies to the class regardless of whether deny or permit is specified in the ACL rules.

• In a QoS policy with multiple class-to-traffic-behavior associations, if the action of creating an outer

VLAN tag, setting customer network VLAN ID, or setting service provider network VLAN ID is configured in a traffic behavior, do not configure any other action in this traffic behavior; otherwise, the QoS policy may not function as expected after it is applied. For more information about the action of setting customer network VLAN ID or service provider network VLAN ID, see Layer 2—LAN Switching Configuration Guide.

Configuration procedure

See the following chapters, depending on the purpose of the traffic behavior: traffic policing, traffic filtering, traffic redirecting, priority marking, traffic accounting, and so on.

To associate a class with a behavior in a policy:

Step Command

1. Enter system view.

2. Create a policy and enter

policy view.

3. Associate a class with a

behavior in the policy.

system-view N/A

qos policy policy-name N/A

classifier tcl-name behavior behavior-name [ mode dot1q-tag-manipulation ]

Remarks

Repeat this step to create more class-behavior associations.

Page 25

The dot1q-tag-manipulation keyword is only for VLAN mapping purposes. For more information about VLAN mapping, see Layer 2—LAN Switching Configuration Guide.

Applying the QoS policy

You can apply a QoS policy to the following destinations:

• An interface—The policy takes effect on the traffic sent or received on the interface.

• A VLAN—The policy takes effect on the traffic sent or received on all ports in the VLAN.

• Globally—The policy takes effect on the traffic sent or received on all ports.

Configuration guidelines

• You can modify classes, behaviors, and class-behavior associations in a QoS policy applied to an

interface, VLAN, or globally. If a class references an ACL for traffic classification, you can delete or modify the ACL (such as add rules to, delete rules from, and modify rules of the ACL).

• The QoS policies applied to ports, to VLANs, and globally are in descending priority order. If the

system finds a matching QoS policy for the incoming/outgoing traffic, the system stops matching the traffic against QoS policies.

Applying the QoS policy to an interface

A policy can be applied to multiple interfaces, but only one policy can be applied in one direction (inbound or outbound) of an interface.

The QoS policy applied to the outgoing traffic of a port does not regulate local packets, which are critical protocol packets sent by the device that hosts the interface for maintaining the normal operation of the device. The most common local packets include link maintenance packets, STP, LDP, and RSVP packets.

To apply the QoS policy to an interface:

Step Command

1. Enter system view.

2. Enter interface view.

3. Apply the policy to the

interface.

NOTE:

Layer 2 Ethernet interfaces and Layer 3 Ethernet interfaces support the QoS policy function. The term "interface" in this chapter collectively refers to these types of interfaces. You can use the port link-mode command to configure an Ethernet port as a Layer 2 or Layer 3 interface (see

Configuration Guide

Applying the QoS policy to a VLAN

You can apply a QoS policy to a VLAN to regulate traffic of the VLAN.

Remarks

system-view N/A

interface interface-type interface-number

qos apply policy policy-name { inbound

| outbound }

N/A

Layer 2—LAN Switching

QoS policies cannot be applied to dynamic VLANs, such as VLANs created by GVRP.

To apply the QoS policy to a VLAN:

Page 26

Step Command

1. Enter system view.

system-view

2. Apply the QoS policy to VLANs.

qos vlan-policy policy-name vlan vlan-id-list { inbound | outbound }

Applying the QoS policy globally

You can apply a QoS policy globally to the inbound or outbound direction of all ports.

To apply the QoS policy globally:

Step Command

1. Enter system view.

2. Apply the QoS policy globally.

system-view

qos apply policy policy-name global { inbound | outbound }

Displaying and maintaining QoS policies

Task Command

Display traffic class configuration.

Display traffic behavior configuration.

display traffic classifier user-defined [ tcl-name ] [ | { begin | exclude | include } regular-expression ]

display traffic behavior user-defined [ behavior-name ] [ | { begin | exclude | include } regular-expression ]

Remarks

Available in any view.

Display user-defined QoS policy configuration.

Display QoS policy configuration on the specified or all interfaces.

Display information about QoS policies applied to VLANs.

Display information about QoS policies applied globally.

Clear the statistics of the QoS policy applied in a certain direction of a VLAN.

Clear the statistics for a QoS policy applied globally.

display qos policy user-defined [ policy-name [ classifier tcl-name ] ] [ | { begin | exclude | include } regular-expression ]

display qos policy interface [ interface-type interface-number ] [ inbound | outbound ] [ | { begin |

exclude | include } regular-expression ]

display qos vlan-policy { name policy-name | vlan

vlan-id } [ slot slot-number ] [ inbound | outbound ] [ | { begin | exclude | include } regular-expression ]

display qos policy global [ slot slot-number ] [ inbound | outbound ] [ | { begin | exclude | include }

regular-expression ]

reset qos vlan-policy [ vlan vlan-id ] [ inbound | outbound ]

reset qos policy global [ inbound | outbound ]

Available in any view.

Available in user view.

Page 27

Configuring priority mapping

This chapter describes how to configure priority mapping.

Overview

When a packet arrives, depending on your configuration, a device assigns a set of QoS priority parameters to the packet based on either a certain priority field carried in the packet or the port priority of the incoming port. This process is called "priority mapping." During this process, the device can modify the priority of the packet depending on the status of the device. The set of QoS priority parameters determines the scheduling priority and forwarding priority of the packet.

Priority mapping is implemented with priority mapping tables and involves priorities such as 802.1p priority, DSCP, EXP, IP precedence, local precedence, and drop precedence.

Types of priorities

Priorities include the following types: priorities carried in packets, and priorities locally assigned for only scheduling.

The packet-carried priorities include 802.1p priority, DSCP precedence, IP precedence, EXP, and so on. These priorities have global significance and affect the forwarding priority of packets across the network. For more information about these priorities, see "Appendix."

The locally assigned priorities have only local significance. They are assigned by the device for only scheduling. These priorities include the local precedence and drop precedence, as follows:

• Local precedence—Local precedence is used for queuing. A local precedence value corresponds to

an output queue. A packet with a higher local precedence value is assigned to a higher-priority output queue to be preferentially scheduled.

• Drop precedence—Drop precedence is used for making packet drop decisions. Packets with the

highest drop precedence are dropped preferentially.

Priority mapping tables

Priority mapping is implemented with priority mapping tables. By looking up a priority mapping table, the device determines which priority value is to assign to a packet for subsequent packet processing. The switch provides the following priority mapping tables:

• dot1p-dp—802.1p-to-drop priority mapping table.

• dot1p-lp—802.1p-to-local priority mapping table.

• dscp-dot1p—DSCP-to-802.1p priority mapping table, which is applicable to only IP packets.

• dscp-dp—DSCP-to-drop priority mapping table, which is applicable to only IP packets.

• dscp-dscp—DSCP-to-DSCP priority mapping table, which is applicable to only IP packets.

The default priority mapping tables (as shown in Appendix A Default priority mapping tables) a available for priority mapping. They are adequate in most cases. If a default priority mapping table cannot meet your requirements, you can modify the priority mapping table as required.

Page 28

Priority trust mode on a port

The priority trust mode on a port determines which priority is used for priority mapping table lookup. Port priority was introduced to use for priority mapping in addition to the priority fields carried in packets. The device provides the following priority trust modes:

• Using the 802.1p priority carried in packets for priority mapping.

• Using the DSCP carried in packets for priority mapping.

The priority mapping procedure varies with the priority modes. For more information, see the subsequent section.

Priority mapping procedure

On receiving an Ethernet packet on a port, the switch marks the scheduling priorities (local precedence and drop precedence) for the Ethernet packet. This procedure is done according to the priority trust mode of the receiving port and the 802.1q tagging status of the packet, as shown in Figure 5.

Figure 5 Priority mapp

Use the port

priority as the

802.1p priority of the packet

Look up the

dot1p-dp and

dot1p-lp tables

Mark the packet

with local

precedence and

drop precedence

ing procedure for an Ethernet packet

Receive a

packet on a port

Which priority is

trusted on the

port?

802.1p in packets

Is the packet

802.1q tagged?

Look up the

dot1p-dp and

dot1p-lp tables

Mark the packet

with local

precedence and

drop precedence

DSCP in packets

Look up the

dscp-dp, dscp-

dot1p, and dscp-

dscp tables

Mark the packet

with 802.1p

priority, drop

precedence, and

new DSCP

precedence

Look up the

dot1p-lp table

Mark the packet

with local

precedence

Schedule the packet according to its local

precedence and drop

precedence

The priority mapping procedure shown in Figure 5 applies in the absence of priority marking. If priority marking is configured, the switch performs priority marking before priority mapping. The switch then uses the re-marked packet-carried priority for priority mapping or directly uses the re-marked scheduling

Page 29

priority for traffic scheduling depending on your configuration. Neither priority trust mode configuration on the port nor port priority configuration takes effect.

NOTE:

Layer 2 Ethernet interfaces and Layer 3 Ethernet interfaces support the priority mapping function. The term "interface" in this chapter collectively refers to these two types of interfaces. You can use the port link-mode command to configure an Ethernet port as a Layer 2 or Layer 3 interface (see

Switching Configuration Guide

Priority mapping configuration task list

You can modify priority mappings by modifying priority mapping tables, priority trust mode on a port, and port priority.

HP recommends planning QoS throughout the network before making your QoS configuration.

Perform these tasks to configure priority mapping:

Task Remarks

Configuring a priority mapping table Optional.

Layer 2—LAN

Configuring the priority trust mode Optional.

Changing the port priority of an interface Optional.

Configuring a priority mapping table

To configure a priority mapping table:

Step Command

1. Enter system view.

2. Enter priority

mapping table view.

3. Configure the

priority mapping table.

system-view N/A

qos map-table { dot1p-dp | dot1p-lp | dscp-dot1p | dscp-dp | dscp-dscp }

import import-value-list export export-value

Configuring the priority trust mode

Remarks

N/A

Newly configured mappings overwrite the old ones.

The following priority trust modes are available:

• Using the 802.1p priority of received packets for mapping.

• Using the DSCP precedence of received IP packets for mapping.

To configure the trusted packet priority type on an interface:

Page 30

Step Command

1. Enter system view.

2. Enter interface view.

3. Configure the priority

trust mode for the interface.

system-view N/A

interface interface-type interface-number N/A

• Trust the DSCP priority in packets:

qos trust dscp

• Trust the 802.1p priority in packets:

qos trust dot1p

Remarks

By default, the device trusts the 802.1p priority in packets.

Changing the port priority of an interface

Step Command

1. Enter system view.

2. Enter interface

view.

3. Set the port priority

of the interface.

system-view N/A

interface interface-type interface-number N/A

qos priority priority-value The default is 0.

Remarks

Displaying and maintaining priority mapping

Task Command

Display the priority mapping table configuration.

Display the trusted packet priority type on a port.

display qos map-table [ dot1p-dp | dot1p-lp | dscp-dot1p | dscp-dp | dscp-dscp ] [ | { begin | exclude | include }

regular-expression ]

display qos trust interface [ interface-type interface-number ] [ | { begin | exclude | include } regular-expression ]

Remarks

Available in any view.

Priority mapping configuration examples

This section provides priority mapping configuration examples.

Priority trust mode configuration example

Network requirements

As shown in Figure 6, Device A is connected to GigabitEthernet 1/0/1 of Device C, Device B is connected to GigabitEthernet 1/0/2 of Device C, and the packets from Device A and Device B to Device C are not VLAN tagged.

Configure Device C to preferentially process packets from Device A to Server when GigabitEthernet 1/0/3 of Device C is congested.

Page 31

Figure 6 Network diagram



Configuration procedure

# Assign port priority to GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2. Make sure that the priority of GigabitEthernet 1/0/1 is higher than that of GigabitEthernet 1/0/2, and that no trusted packet priority type is configured on GigabitEthernet 1/0/1 or GigabitEthernet 1/0/2.

<DeviceC> system-view [DeviceC] interface gigabitethernet 1/0/1 [DeviceC-GigabitEthernet1/0/1] qos priority 3 [DeviceC-GigabitEthernet1/0/1] quit [DeviceC] interface gigabitethernet 1/0/2 [DeviceC-GigabitEthernet1/0/2] qos priority 1 [DeviceC-GigabitEthernet1/0/2] quit

Priority mapping table and priority marking configuration example

Network requirements

As shown in Figure 7:

• The marketing department connects to GigabitEthernet 1/0/1 of Device, which sets the 802.1p

priority of traffic from the marketing department to 3.

• The R&D department connects to GigabitEthernet 1/0/2 of Device, which sets the 802.1p priority

of traffic from the R&D department to 4.

• The management department connects to GigabitEthernet 1/0/3 of Device, which sets the 802.1p

priority of traffic from the management department to 5.

Configure port priority, 802.1p-to-local mapping table, and priority marking to implement the plan as described in Table 3.

Page 32

g p

Table 3 Configuration plan

Traffic destination

Traffic priority order

R&D department >

Public servers

management department > marketing department

Management

Internet

department > marketing department > R&D department

Figure 7 Network diagram

Host

Internet

Queuin

Traffic source

lan

Output queue Queue priorit

R&D department 6 High

Management department

4 High

Marketing department 2 Low

R&D department 2 Low

Management department

6 High

Marketing department 4 Medium

Host

Server

Management department

Public servers

Configuration procedure

1. Enable trusting port priority:

# Set the port priority of GigabitEthernet 1/0/1 to 3.

<Device> system-view [Device] interface gigabitethernet 1/0/1 [Device-GigabitEthernet1/0/1] qos priority 3 [Device-GigabitEthernet1/0/1] quit

# Set the port priority of GigabitEthernet 1/0/2 to 4.

[Device] interface gigabitethernet 1/0/2

GE1/0/3

GE1/0/4

GE1/0/5

Device

GE1/0/2

GE1/0/1

Server

R&D department

Host

Server

Marketing department

Page 33

[Device-GigabitEthernet1/0/2] qos priority 4 [Device-GigabitEthernet1/0/2] quit

# Set the port priority of GigabitEthernet 1/0/3 to 5.

[Device] interface gigabitethernet 1/0/3 [Device-GigabitEthernet1/0/3] qos priority 5 [Device-GigabitEthernet1/0/3] quit

2. Configure the priority mapping table:

# Configure the 802.1p-to-local mapping table to map 802.1p priority values 3, 4, and 5 to local precedence values 2, 6, and 4. This guarantees the R&D department, management department, and marketing department decreased priorities to access the public server.

[Device] qos map-table dot1p-lp [Device-maptbl-dot1p-lp] import 3 export 2 [Device-maptbl-dot1p-lp] import 4 export 6 [Device-maptbl-dot1p-lp] import 5 export 4 [Device-maptbl-dot1p-lp] quit

3. Configure priority marking:

# Mark the HTTP traffic of the management department, marketing department, and R&D department to the Internet with 802.1p priorities 4, 5, and 3, respectively. Use the priority mapping table you have configured to map the 802.1p priorities to local precedence values 6, 4, and 2, respectively, for differentiated traffic treatment.

# Create ACL 3000 to match HTTP traffic.

[Device] acl number 3000 [Device-acl-adv-3000] rule permit tcp destination-port eq 80 [Device-acl-adv-3000] quit

# Create class http and reference ACL 3000 in the class.

[Device] traffic classifier http [Device-classifier-http] if-match acl 3000 [Device-classifier-http] quit

# Configure a priority marking policy for the management department, and apply the policy to the incoming traffic of GigabitEthernet 1/0/3.

[Device] traffic behavior admin [Device-behavior-admin] remark dot1p 4 [Device-behavior-admin] quit [Device] qos policy admin [Device-qospolicy-admin] classifier http behavior admin [Device-qospolicy-admin] quit [Device] interface gigabitethernet 1/0/3 [Device-GigabitEthernet1/0/3] qos apply policy admin inbound

# Configure a priority marking policy for the marketing department, and apply the policy to the incoming traffic of GigabitEthernet 1/0/1.

[Device] traffic behavior market [Device-behavior-market] remark dot1p 5 [Device-behavior-market] quit [Device] qos policy market [Device-qospolicy-market] classifier http behavior market [Device-qospolicy-market] quit [Device] interface gigabitethernet 1/0/1

Page 34

[Device-GigabitEthernet1/0/1] qos apply policy market inbound

# Configure a priority marking policy for the R&D department, and apply the policy to the incoming traffic of GigabitEthernet 1/0/2.

[Device] traffic behavior rd [Device-behavior-rd] remark dot1p 3 [Device-behavior-rd] quit [Device] qos policy rd [Device-qospolicy-rd] classifier http behavior rd [Device-qospolicy-rd] quit [Device] interface gigabitethernet 1/0/2 [Device-GigabitEthernet1/0/2] qos apply policy rd inbound

Page 35

Configuring traffic policing, traffic shaping, and rate limit

This chapter describes how to configure traffic policing, traffic shaping, and rate limit.

Overview

Traffic policing, traffic shaping, and rate limit are QoS techniques that help assign network resources, such as assigning bandwidth. They increase network performance and user satisfaction. For example, you can configure a flow to use only the resources committed to it in a certain time range. This avoids network congestion caused by bursty traffic.

Traffic policing and generic traffic shaping (GTS) limit the traffic rate and resource usage according to traffic specifications. Once a particular flow exceeds its specifications, such as assigned bandwidth, the flow is shaped or policed to make sure that it is under the specifications. You can use token buckets for evaluating traffic specifications.

Traffic evaluation and token buckets

This section describes traffic evaluation and token buckets.

Token bucket features

A token bucket is analogous to a container that holds a certain number of tokens. Each token represents a certain forwarding capacity. The system puts tokens into the bucket at a constant rate. When the token bucket is full, the extra tokens cause the token bucket to overflow.

Evaluating traffic with the token bucket

A token bucket mechanism evaluates traffic by looking at the number of tokens in the bucket. If the nu mber of tokens in the bucket is enough for forwarding packets, the traffic conforms to the specification, and is called "conforming traffic." Otherwise, the traffic does not conform to the specification, and is called "excess traffic."

A token bucket has the following configurable parameters:

• Mean rate at which tokens are put into the bucket, which is the permitted average rate of traffic. It

is usually set to the committed information rate (CIR).

• Burst size or the capacity of the token bucket. It is the maximum traffic size permitted in each burst.

It is usually set to the committed burst size (CBS). The set burst size must be greater than the maximum packet size.

Each arriving packet is evaluated. In each evaluation, if the number of tokens in the bucket is enough, the traffic conforms to the specification and the tokens for forwarding the packet are taken away; if the number of tokens in the bucket is not enough, the traffic is excessive.

Complicated evaluation

You can set two token buckets, bucket C and bucket E, to evaluate traffic in a more complicated environment and achieve more policing flexibility. Traffic policing uses the following parameters:

Page 36

• CIR—Rate at which tokens are put into bucket C. It sets the average packet transmission or

forwarding rate allowed by bucket C.

• CBS—Size of bucket C, which specifies the transient burst of traffic that bucket C can forward.

• Excess burst size (EBS)—Size of bucket E, which specifies the transient burst of traffic that bucket E

can forward.

• Peak information rate (PIR)—Rate at which tokens are put into bucket E, which specifies the average

packet transmission or forwarding rate allowed by bucket E.

CBS is implemented with bucket C and EBS with bucket E. In each evaluation, packets are measured against the following bucket scenarios:

• If bucket C has enough tokens, packets are colored green.

• If bucket C does not have enough tokens but bucket E has enough tokens, packets are colored

yellow.

• If neither bucket C nor bucket E has sufficient tokens, packets are colored red.

Traffic policing

Traffic policing supports policing the inbound traffic and the outbound traffic.

A typical application of traffic policing is to supervise the specification of certain traffic entering a network and limit it within a reasonable range, or to "discipline" the extra traffic to prevent aggressive use of network resources by a certain application. For example, you can limit bandwidth for HTTP packets to less than 50% of the total. If the traffic of a certain session exceeds the limit, traffic policing can drop the packets or reset the IP precedence of the packets. Figure 8 sho outbound traffic on an interface.

ws an example of policing

Figure 8 Traffic policing

Traffic policing is widely used in policing traffic entering the networks of ISPs. It can classify the policed traffic depending on the evaluation result and take pre-defined policing actions on each packet:

• Forwarding the packet if the evaluation result is "conforming."

• Dropping the packet if the evaluation result is "excess."

• Forwarding the packet with its precedence (which can be DSCP) re-marked if the evaluation result

is "conforming."

Page 37

Traffic shaping

Traffic shaping shapes the outbound traffic.

Traffic shaping limits the outbound traffic rate by buffering exceeding traffic. You can use traffic shaping to adapt the traffic output rate on a device to the input traffic rate of its connected device to avoid packet loss.

The difference between traffic policing and GTS is that packets to be dropped with traffic policing are retained in a buffer or queue with GTS, as shown in Figure 9. W bucket, the buffered packets are sent at an even rate. Traffic shaping can result in additional delay and traffic policing does not.

Figure 9 GTS

hen enough tokens are in the token

For example, in Figure 10, Device B performs traffic policing on packets from Device A and drops packets exceeding the limit. To avoid packet loss, you can perform traffic shaping on the outgoing interface of Device A so that packets exceeding the limit are cached in Device A. Once resources are released, traffic shaping takes out the cached packets and sends them out.

Figure 10 GTS application

Rate limit

Rate limit supports controlling the rate of the inbound traffic and outbound traffic.

The rate limit of a physical interface specifies the maximum rate for forwarding packets (including critical packets).

Page 38

Rate limit also uses token buckets for traffic control. With rate limit configured on an interface, all packets to be sent through the interface are handled by the token bucket for rate limiting. If enough tokens are in the token bucket, packets can be forwarded. Otherwise, packets are put into QoS queues for congestion management. In this way, the traffic passing the physical interface is controlled.

Figure 11 Rate limit implementation

The token bucket mechanism limits traffic rate when accommodating bursts. It allows bursty traffic to be transmitted if enough tokens are available. If tokens are scarce, packets cannot be transmitted until efficient tokens are generated in the token bucket. It restricts the traffic rate to the rate for generating tokens.

Rate limit controls the total rate of all packets on a physical interface. It is easier to use than traffic policing in controlling the total traffic rate on a physical interface.

NOTE:

Both Layer 2 and Layer 3 Ethernet interfaces support the traffic shaping and rate limit functions. The term "interface" in this chapter collectively refers to these two types of interfaces. You can use the port link-mode command to configure an Ethernet port as a Layer 2 or Layer 3 interface (see

Switching Configuration Guide

Configuring traffic policing

Do not configure traffic policing with any priority marking action (including local precedence, drop precedence, 802.1p priority, DSCP value, or IP precedence marking actions) in the same traffic behavior. Otherwise, you will fail to apply the QoS policy successfully.

To configure traffic policing:

Layer 2—LAN

Step Command

1. Enter system view.

2. Create a class and enter

class view.

3. Configure match criteria.

system-view N/A

traffic classifier tcl-name [ operator { and | or } ]

if-match match-criteria N/A

Remarks

N/A

Page 39

Step Command

4. Return to system view.

5. Create a behavior and

enter behavior view.

6. Configure a traffic

policing action.

7. Return to system view.

8. Create a policy and enter

policy view.

9. Associate the class with

the traffic behavior in the QoS policy.

10. Return to system view.

quit N/A

traffic behavior behavior-name N/A

car cir

committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] [ pir peak-information-rate ] [ green action ] [ yellow action ] [ red action ]

quit N/A

qos policy policy-name N/A

classifier tcl-name behavior behavior-name

quit N/A

• Applying the QoS policy to

an interface

11. Apply the QoS policy.

• Applying the QoS policy to a

VLAN

• Applying the QoS policy

globally

Remarks

N/A

Choose one of the application destinations as needed.

Configuring GTS

The device supports queue-based GTS, which shapes traffic of a specific queue.

The 5830 Switch Series supports the following types of GTS:

• Queue-based GTS—Shapes traffic of a specific queue.

• GTS applicable to all traffic—Shapes all traffic.

NOTE:

The HP 5830AF-48G and HP 5830AF-48G TAA support the two types of GTS mentioned above. The HP 5830AF-96G and HP 5830AF-96G TAA support only GTS applicable to all traffic.

Configuring queue-based GTS

Step Command

1. Enter system view.

2. Enter interface view.

3. Configure GTS for a

queue.

Remarks

system-view N/A

interface interface-type interface-number

qos gts queue queue-number cir

committed-information-rate

N/A

Page 40

Configuring GTS for all traffic

Step Command

1. Enter system view.

2. Enter interface view.

3. Configure GTS on the

interface.

system-view N/A

interface interface-type interface-number

qos gts any cir

committed-information-rate

Configuring the rate limit

The rate limit of a physical interface specifies the maximum rate of incom ing packets or outg oing pac ke ts.

To configure the rate limit:

Step Command

1. Enter system view.

2. Enter interface view.

3. Configure the rate limit

for the interface.

system-view N/A

interface interface-type interface-number

qos lr { inbound | outbound } cir

committed-information-rate [ cbs committed-burst-size ]

Remarks

N/A

Remarks

N/A

Displaying and maintaining traffic policing, GTS, and rate limit

On the device, you can configure traffic policing by using the MQC approach. For more information about the displaying and maintaining commands, see "QoS configuration approaches."

Task Command

Display interface GTS configuration information.

Display interface rate limit configuration information.

display qos gts interface [ interface-type interface-number ] [ | { begin | exclude |

include } regular-expression ]

display qos lr interface [ interface-type interface-number ] [ | { begin | exclude | include } regular-expression ]

Remarks

Available in any view.

Traffic policing and GTS configuration example

Network requirements

As shown in Figure 12:

• GigabitEthernet 1/0/3 of Device A is connected to GigabitEthernet1/0/1 of Device B.

• Server, Host A, and Host B can access the Internet through Device A and Device B.

Page 41

Perform traffic control on GigabitEthernet 1/0/1 of Device A for traffic received from Server and Host A, respectively, to meet the following requirements:

• Limit the rate of traffic from Server to 1024 kbps: Transmit the conforming traffic, and mark the

excess traffic with DSCP value 0 and then transmit the traffic.

• Limit the rate of traffic from Host A to 256 kbps: Transmit the conforming traffic, and drop the excess

traffic.

Perform traffic control on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 of Device B to meet the following requirements:

• Limit the total incoming traffic rate of GigabitEthernet 1/0/1 to 2048 kbps and drop the excess

traffic.

• Limit the outgoing HTTP traffic (traffic accessing the Internet) rate of GigabitEthernet 1/0/2 to 1024

kbps and drop the excess traffic.

Figure 12 Network diagram

Server

1.1.1.1/8 1.1.1.2/8

Ethernet

GE1/0/1

Device A

Host A

GE1/0/1

GE1/0/3

GE1/0/2

Configuration procedures

1. Configure Device A:

# Configure ACL 2001 and ACL 2002 to match traffic from Server and Host A, respectively.

<DeviceA> system-view [DeviceA] acl number 2001 [DeviceA-acl-basic-2001] rule permit source 1.1.1.1 0 [DeviceA-acl-basic-2001] quit [DeviceA] acl number 2002 [DeviceA-acl-basic-2002] rule permit source 1.1.1.2 0 [DeviceA-acl-basic-2002] quit

# Create a class named server and use ACL 2001 as the match criterion. Create a class named host and use ACL 2002 as the match criterion.

[DeviceA] traffic classifier server [DeviceA-classifier-server] if-match acl 2001 [DeviceA-classifier-server] quit [DeviceA] traffic classifier host [DeviceA-classifier-host] if-match acl 2002 [DeviceA-classifier-host] quit

# Create a behavior named server and configure the CAR action for the behavior as follows: Set the CIR to 1024 kbps, and mark the excess packets (red packets) with DSCP value 0 and transmit them.

Internet

Device B

GE1/0/2

Host B

Page 42

[DeviceA] traffic behavior server [DeviceA-behavior-server] car cir 1024 red remark-dscp-pass 0 [DeviceA-behavior-server] quit

# Create a behavior named host and configure the CAR action for the behavior as follows: Set the CIR to 256 kbps.

[DeviceA] traffic behavior host [DeviceA-behavior-host] car cir 256 [DeviceA-behavior-host] quit

# Create a QoS policy named car and associate class server with behavior server and class host with behavior host.

[DeviceA] qos policy car [DeviceA-qospolicy-car] classifier server behavior server [DeviceA-qospolicy-car] classifier host behavior host [DeviceA-qospolicy-car] quit

# Apply QoS policy car to the incoming traffic of port GigabitEthernet 1/0/1.

[DeviceA] interface GigabitEthernet 1/0/1 [DeviceA-GigabitEthernet1/0/1] qos apply policy car inbound

2. Configure Device B:

# Configure advanced ACL 3001 to match HTTP traffic.

<DeviceB> system-view [DeviceB] acl number 3001 [DeviceB-acl-adv-3001] rule permit tcp destination-port eq 80 [DeviceB-acl-adv-3001] quit

# Create a class named http and use ACL 3001 as the match criterion.

[DeviceB] traffic classifier http [DeviceB-classifier-http] if-match acl 3001 [DeviceB-classifier-http] quit

# Create a class named class and configure the class to match all packets.

[DeviceB] traffic classifier class [DeviceB-classifier-class] if-match any [DeviceB-classifier-class] quit

# Create a behavior named car_inbound and configure the CAR action for the behavior as follows: Set the CIR to 2048 kbps.

[DeviceB] traffic behavior car_inbound [DeviceB-behavior-car_inbound] car cir 2048 [DeviceB-behavior-car_inbound] quit

# Create a behavior named car_outbound and configure a CAR action for the behavior as follows: Set the CIR to 1024 kbps.

[DeviceB] traffic behavior car_outbound [DeviceB-behavior-car_outbound] car cir 1024 [DeviceB-behavior-car_outbound] quit

# Create a QoS policy named car_inbound and associate class class with traffic behavior car_inbound in the QoS policy.

[DeviceB] qos policy car_inbound [DeviceB-qospolicy-car_inbound] classifier class behavior car_inbound [DeviceB-qospolicy-car_inbound] quit

Page 43

# Create a QoS policy named car_outbound and associate class http with traffic behavior car_outbound in the QoS policy.

[DeviceB] qos policy car_outbound [DeviceB-qospolicy-car_outbound] classifier http behavior car_outbound [DeviceB-qospolicy-car_outbound] quit

# Apply QoS policy car_inbound to the incoming traffic of port GigabitEthernet 1/0/1.

[DeviceB] interface GigabitEthernet 1/0/1 [DeviceB-GigabitEthernet1/0/1] qos apply policy car_inbound inbound

# Apply QoS policy car_outbound to the outgoing traffic of port GigabitEthernet 1/0/2.

[DeviceB] interface GigabitEthernet 1/0/2 [DeviceB-GigabitEthernet1/0/2] qos apply policy car_outbound outbound

Page 44

Configuring congestion management

This chapter describes how to configure congestion management.

Overview

This section describes why congestion occurs and the congestion management techniques.

Causes, impacts, and countermeasures

Network congestion degrades service quality. Congestion is a situation where the forwarding rate decreases due to insufficient resources, resulting in extra delay.

Congestion is more likely to occur in complex packet-switching circumstances. Figure 13 sh common cases:

Figure 13 Traffic congestion causes

Congestion can bring the following negative results:

• Increased delay and jitter during packet transmission.

• Decreased network throughput and resource use efficiency.

• Network resource (memory in particular) exhaustion and even system breakdown.

Congestion is unavoidable in switched networks and multi-user application environments. To improve the service performance of your network, you must take some proper measures to address the congestion issues.

ows two

The key to congestion management is how to define a dispatching policy for resources to decide the order of forwarding packets when congestion occurs.

Congestion management techniques

Congestion management uses queuing and scheduling algorithms to classify and sort traffic leaving a port. Each queuing algorithm addresses a particular network traffic problem, and has a different impact on bandwidth resource assignment, delay, and jitter.

Queue scheduling processes packets by their priorities, preferentially forwarding high-priority packets. The following section describes in detail Strict Priority (SP) queuing, Weighted Fair Queuing (WFQ), Weighted Round Robin (WRR) queuing, SP+WRR queuing, and SP+WFQ queuing.

Page 45

SP queuing

SP queuing is designed for mission-critical applications that require preferential service to reduce the response delay when congestion occurs.

Figure 14 SP queuing

In Figure 14, SP queuing classifies eight queues on a port into eight classes, numbered 7 to 0 in descending priority order.

SP queuing schedules the eight queues in the descending order of priority. SP queuing sends packets in the queue with the highest priority first. When the queue with the highest priority is empty, it sends packets in the queue with the second highest priority, and so on. You can assign mission-critical packets to the high-priority queue to make sure that they are always served first and common service packets to the low-priority queues to be transmitted when the high-priority queues are empty.

The disadvantage of SP queuing is that packets in the lower priority queues cannot be transmitted if packets exist in the higher priority queues. This may cause lower priority traffic to starve to death.

WRR queuing

WRR queuing schedules all queues in turn to make sure that every queue is served for a certain time, as shown in Figure 15.

Page 46

Figure 15 WRR queuing

Queue 0Weight 1

Packets to be sent through

this port

Queue 1Weight 2

……

Queue N-2Weight N-1

Sent packets

Interface

Assume a port provides eight output queues. WRR assigns each queue a weight value (represented by w7, w6, w5, w4, w3, w2, w1, or w0) to decide the proportion of resources assigned to the queue.

The Switch Series supports byte-count weight (which determines the weight by the number of bytes scheduled in a cycle).

On a 100 Mbps port, you can configure the weight values of WRR queuing to 5, 3, 1, 1, 5, 3, 1, and 1 (corresponding to w7, w6, w5, w4, w3, w2, w1, and w0, respectively). In this way, the queue with the lowest priority can get a minimum of 5 Mbps of bandwidth. WRR avoids the disadvantage of SP queuing that packets in low-priority queues may fail to be served for a long time.

Another advantage of WRR queuing is that when the queues are scheduled in turn, the service time for each queue is not fixed. If a queue is empty, the next queue is scheduled immediately. This improves bandwidth resource use efficiency.

WFQ queuing

Figure 16 WFQ queuing

Packet

classification

Queue N-1 Weight N

Queue

scheduling

Sending queue

WFQ is similar to WRR. You can use WFQ as an alternative to WRR.

Page 47

Compared with WRR, WFQ can work with the minimum guaranteed bandwidth as follows:

• By setting the minimum guaranteed bandwidth, you can make sure that each WFQ queue is

assured of certain bandwidth.

• The assignable bandwidth is allocated based on the priority of each queue (assignable bandwidth

= total bandwidth – the sum of minimum guaranteed bandwidth of each queue).

For example, assume that the total bandwidth of a port is 10 Mbps and that the port has five flows, with the precedence being 0, 1, 2, 3, and 4 and the minimum guaranteed bandwidth being 128 kbps, 128 kbps, 128 kbps, 64 kbps, and 64 kbps, respectively.

• The assignable bandwidth = 10 Mbps – (128 kbps + 128 kbps + 128 kbps + 64 kbps + 64 kbps)

= 9.5 Mbps.

• The total assignable bandwidth quota is the sum of all the (precedence value + 1)s, 1 + 2 + 3 + 4

+ 5 = 15.

• The bandwidth percentage assigned to each flow is the (precedence value of the flow + 1)/total

assignable bandwidth quota. The bandwidth percentages for the flows are 1/15, 2/15, 3/15, 4/15, and 5/15, respectively.

• The bandwidth assigned to a queue = the minimum guaranteed bandwidth + the bandwidth

allocated to the queue from the assignable bandwidth.

SP+WRR queuing

You can assign some queues on a por t to the SP scheduling group and the others to the WRR scheduling group (group 1) to implement SP + WRR queue scheduling. The switch schedules packets in the SP scheduling group preferentially, and when the SP scheduling group is empty, it schedules the packets in the WRR scheduling group. Queues in the SP scheduling group are scheduled with the SP queue scheduling algorithm. Queues in the WRR scheduling group are scheduled with WRR.

SP+WFQ queuing

SP+WFQ queuing is similar to SP+WRR queuing. You can assign some queues on a port to the SP scheduling group and others to the WFQ scheduling group to implement SP + WFQ queue scheduling. The switch first uses SP queuing to schedule the queues in the SP scheduling group, then schedules packets of queues in the WFQ group based on their minimum guaranteed bandwidth settings when the SP scheduling group is empty, and at last uses WFQ to schedule the queues in the WFQ scheduling group in a round robin fashion according to their weights.

NOTE:

Both Layer 2 and Layer 3 Ethernet interfaces support the congestion management function. The term "interface" in this chapter collectively refers to these two types of interfaces. You can use the port link-mode command to configure an Ethernet port as a Layer 2 or Layer 3 interface (see

Switching Configuration Guide

Layer 2—LAN

Page 48

Congestion management configuration task list

Task Remarks

Configuring SP queuing

Configure WRR queuing

Configuring WFQ queuing

Configuring SP+WRR queuing

Configuring SP+WFQ queuing

Configuring SP queuing

Step Command

1. Enter system view.

2. Enter interface view.

3. Configure SP queuing.

4. Display SP queuing

configuration.

For example, configure GigabitEthernet 1/0/1 to use SP queuing:

system-view N/A

interface interface-type interface-number

qos sp

display qos sp interface

[ interface-type interface-number ] [ | { begin | exclude | include } regular-expression ]

Perform one of the tasks as needed.

Remarks

N/A

The default queuing algorithm on an interface is SP queuing.

Optional.

Available in any view.

# Enter system view.

<Sysname> system-view

# Configure GigabitEthernet1/0/1 to use SP queuing.

[Sysname] interface gigabitethernet 1/0/1 [Sysname-GigabitEthernet1/0/1] qos sp

Configure WRR queuing

Step Command

1. Enter system view.

2. Enter interface view.

system-view N/A

interface interface-type

interface-number

Remarks

N/A

Page 49

Optional.

3. Enable WRR queuing.

4. Configure the scheduling

weight for a queue.

qos wrr [ byte-count | weight ]

qos wrr queue-id group group-id byte-count schedule-value

The default queuing algorithm on an interface is SP.

The weight keyword is not supported.

Optional.

By default, the weights of queues 0 through 7 are 1, 2, 3, 4, 5, 6, 7, and 8 on an interface with WRR enabled.

5. Display WRR queuing

configuration information on interfaces.

display qos wrr interface [ interface-type interface-number ] [ | { begin | exclude | include } regular-expression ]

Optional.

Available in any view.

For example, enable byte-count WRR on port GigabitEthernet 1/0/1, and assign queues 0 through 7 to the WRR group, with the weights being 1, 2, 4, 6, 8, 10, 12, and 14.

# Enter system view.

<Sysname> system-view

# Configure WRR queuing on port GigabitEthernet 1/0/1.

[Sysname] interface GigabitEthernet 1/0/1 [Sysname-GigabitEthernet1/0/1] qos wrr byte-count [Sysname-GigabitEthernet1/0/1] qos wrr 0 group 1 byte-count 1 [Sysname-GigabitEthernet1/0/1] qos wrr 1 group 1 byte-count 2 [Sysname-GigabitEthernet1/0/1] qos wrr 2 group 1 byte-count 4 [Sysname-GigabitEthernet1/0/1] qos wrr 3 group 1 byte-count 6 [Sysname-GigabitEthernet1/0/1] qos wrr 4 group 1 byte-count 8 [Sysname-GigabitEthernet1/0/1] qos wrr 5 group 1 byte-count 10 [Sysname-GigabitEthernet1/0/1] qos wrr 6 group 1 byte-count 12 [Sysname-GigabitEthernet1/0/1] qos wrr 7 group 1 byte-count 14

Configuring WFQ queuing

To guarantee successful WFQ configuration, make sure that the scheduling weight type (byte-count or packet-based) is the same as the WFQ queuing type (byte-count or packet-based) when configuring the scheduling weight for a WFQ queue.

On an EA card, the scheduling weight of a WFQ queue can only be configured as 1.

To configure WFQ queue:

Step Command

1. Enter system view.

2. Enter interface view or.

3. Enable byte-count or

packet-based WFQ queuing.

system-view N/A

interface interface-type interface-number

qos wfq [ byte-count | weight ]

Remarks

N/A

The default queuing algorithm on an interface is SP queuing. The weight keyword is not supported.

Page 50

4. Configure the scheduling

weight for a queue.

5. Configure the minimum

guaranteed bandwidth for a WFQ queue.

6. Display WFQ queuing

configuration.

qos wfq queue-id group group-id byte-count schedule-value

qos bandwidth queue queue-id min bandwidth-value

display qos wfq interface

[ interface-type interface-number ] [ | { begin |

exclude | include }

regular-expression ]

If you have enabled WFQ on the port, the default scheduling weight is 1 for each queue.

Optional.

By default, the minimum guaranteed bandwidth is not configured for a WFQ queue.

Optional.

Available in any view.

For example, configure WFQ queues on an interface, and assign the scheduling weight 1, 5, 10, 20, and 10 to queue 1, queue 3, queue 4, queue 5, and queue 6, respectively.

# Enter system view.

<Sysname> system-view

# Configure WFQ queues on GigabitEthernet 1/0/1.

[Sysname] interface gigabitethernet 1/0/1 [Sysname-GigabitEthernet1/0/1] qos wfq [Sysname-GigabitEthernet1/0/1] qos wfq 1 byte-count 2 [Sysname-GigabitEthernet1/0/1] qos wfq 3 byte-count 5 [Sysname-GigabitEthernet1/0/1] qos wfq 4 byte-count 10 [Sysname-GigabitEthernet1/0/1] qos wfq 5 byte-count 10 [Sysname-GigabitEthernet1/0/1] qos wfq 6 byte-count 10

Configuring SP+WRR queuing

Step Command

1. Enter system view.

2. Enter interface view.

3. Enable WRR queuing on the

port.

4. Assign a queue to the SP

queue scheduling group.

5. Assign a queue to WRR

group 1, and configure the scheduling weight for the queue.

For example:

• Configure SP+WRR queuing on GigabitEthernet 1/0/1, and use byte-count WRR.

system-view N/A

interface interface-type

interface-number

qos wrr [ byte-count | weight ]

qos wrr queue-id group sp

qos wrr queue-id group 1 byte-count schedule-value

Remarks

N/A

Optional.

By default, all ports use SP queuing.

The weight keyword is not supported.

By default, all the queues of a WRR-enabled port use the WRR queue scheduling algorithm.

By default, on a WRR-enabled port, the weights of queues 0 through 7 are 1, 2, 3, 4, 5, 6, 7, and 8.

Page 51

• Assign queue 0, queue 1, queue 2, and queue 3 on GigabitEthernet 1/0/1 to the SP queue

scheduling group.

• Configure queue 4, queue 5, queue 6, and queue 7 on GigabitEthernet 1/0/1 to use WRR

queuing, with the weights 2, 4, 6, and 8, respectively.

The following is the configuration procedure:

# Enter system view.

<Sysname> system-view

# Enable the SP+WRR queue scheduling algorithm on GigabitEthernet1/0/1.

[Sysname] interface GigabitEthernet 1/0/1 [Sysname-GigabitEthernet1/0/1] qos wrr byte-count [Sysname-GigabitEthernet1/0/1] qos wrr 0 group sp [Sysname-GigabitEthernet1/0/1] qos wrr 1 group sp [Sysname-GigabitEthernet1/0/1] qos wrr 2 group sp [Sysname-GigabitEthernet1/0/1] qos wrr 3 group [Sysname-GigabitEthernet1/0/1] qos wrr 4 group 1 byte-count 2 [Sysname-GigabitEthernet1/0/1] qos wrr 5 group 1 byte-count 4 [Sysname-GigabitEthernet1/0/1] qos wrr 6 group 1 byte-count 6 [Sysname-GigabitEthernet1/0/1] qos wrr 7 group 1 byte-count 8

Configuring SP+WFQ queuing

To guarantee successful WFQ configuration, make sure that the scheduling weight type (byte-count or packet-based) is the same as the WFQ queuing type (byte-count) when you configure the scheduling weight for a WFQ queue.

To configure SP + WFQ queuing:

Step Command

1. Enter system view.

2. Enter interface view.

3. Enable byte-count or

packet-based WFQ queuing.

4. Assign a queue to the SP

queue scheduling group.

5. Assign a queue to the WFQ

queue scheduling group, and configure a scheduling weight for the queue.

6. Configure the minimum

guaranteed bandwidth for a queue.

system-view N/A

interface interface-type interface-number

qos wfq [ byte-count | weight ]

qos wfq queue-id group sp

qos wfq queue-id group 1 byte-count schedule-value

qos bandwidth queue queue-id min bandwidth-value

Remarks

N/A

The default queuing algorithm on an interface is SP queuing.

The weight keyword is not supported.

By default, all the queues of a WFQ-enabled port use are in the WFQ group.

Select weight or byte-count according to the WFQ type (byte-count or packet-based) you have enabled.

If you have enabled WFQ on the port, the default scheduling weight is 1 for each queue.

Optional.

64 kbps for each queue by default.

Page 52

For example:

• Configure SP+WFQ queuing on GigabitEthernet 1/0/1, and use byte-count WFQ scheduling

weights.

• Assign queue 0, queue 1, queue 2, and queue 3 on GigabitEthernet 1/0/1 to the SP queue

scheduling group.

• Configure queue 4, queue 5, queue 6, and queue 7 on GigabitEthernet 1/0/1 to use WFQ

queuing, with the weights 2, 4, 6, and 8 and the minimum guaranteed bandwidth 128 kbps.

The following is the configuration procedure:

# Enter system view.

<Sysname> system-view

# Enable the SP+WFQ queue scheduling algorithm on GigabitEthernet 1/0/1.

[Sysname] interface GigabitEthernet 1/0/1 [Sysname-GigabitEthernet1/0/1] qos wfq byte-count [Sysname-GigabitEthernet1/0/1] qos wfq 0 group sp [Sysname-GigabitEthernet1/0/1] qos wfq 1 group sp [Sysname-GigabitEthernet1/0/1] qos wfq 2 group sp [Sysname-GigabitEthernet1/0/1] qos wfq 3 group sp [Sysname-GigabitEthernet1/0/1] qos wfq 4 group 1 byte-count 2 [Sysname-GigabitEthernet1/0/1] qos bandwidth queue 4 min 128 [Sysname-GigabitEthernet1/0/1] qos wfq 5 group 1 byte-count 4 [Sysname-GigabitEthernet1/0/1] qos bandwidth queue 5 min 128 [Sysname-GigabitEthernet1/0/1] qos wfq 6 group 1 byte-count 6 [Sysname-GigabitEthernet1/0/1] qos bandwidth queue 6 min 128 [Sysname-GigabitEthernet1/0/1] qos wfq 7 group 1 byte-count 8 [Sysname-GigabitEthernet1/0/1] qos bandwidth queue 7 min 128

Page 53

Configuring congestion avoidance

This chapter describes how to configure congestion avoidance.

Overview

Avoiding congestion before it occurs is a proactive approach to improving network performance. As a flow control mechanism, congestion avoidance actively monitors network resources (such as queues and memory buffers), and drops packets when congestion is expected to occur or deteriorate.

Compared with end- to -end flow control, this flow control mechanism controls the load of more flows in a device. When dropping packets from a source end, it cooperates with the flow control mechanism (such as TCP flow control) at the source end to regulate the network traffic size. The combination of the local packet drop policy and the source-end flow control mechanism helps maximize throughput and network use efficiency and minimize packet loss and delay.

Tail drop

Congestion management techniques drop all packets arriving at a full queue. This tail drop mechanism results in global TCP synchronization. If packets from multiple TCP connections are dropped, these TCP connections go into the state of congestion avoidance and slow start to reduce traffic, but traffic peak occurs later. Consequently, the network traffic jitters all the time.

RED and WRED

You can use random early detection (RED) or weighted random early detection (WRED) to avoid global TCP synchronization.

Both RED and WRED avoid global TCP synchronization by randomly dropping packets. When the sending rates of some TCP sessions slow down after their packets are dropped, other TCP sessions remain at high sending rates. Link bandwidth is efficiently used because TCP sessions at high sending rates always exist.

The RED or WRED algorithm sets an upper threshold and lower threshold for each queue and processes the packets in a queue as follows:

• When the queue size is shorter than the lower threshold, no packets are dropped.

• When the queue size reaches the upper threshold, all subsequent packets are dropped.

• When the queue size is between the lower threshold and the upper threshold, the received packets

are dropped at the user-configured drop probability.

NOTE:

Both Layer 2 and Layer 3 Ethernet interfaces support the congestion avoidance function. The term "interface" in this chapter collectively refers to these two types of interfaces. You can use the port link-mode command to configure an Ethernet port as a Layer 2 or Layer 3 interface (see

Switching Configuration Guide

Layer 2—LAN

WRED configuration overview

This section describes WRED configuration approaches and WRED parameters.

Page 54

Configuration approaches

On the device, WRED is implemented with WRED tables. WRED tables are created globally in system view and then applied to interfaces.

Parameters

Before configuring WRED, determine the following parameters:

• Upper threshold and lower threshold—When the average queue length is below the lower

threshold, no packets are dropped. When the average queue length is between the lower threshold and the upper threshold, the incoming packets are dropped at the user-configured drop probability. When the average queue length is above the upper threshold, all incoming packets are dropped.

• Drop precedence—Parameter used in packet drop. Value 0 represents green packets, 1 represents

yellow packets, and 2 represents red packets. Red packets are preferentially dropped.

• Drop probability—Probability of dropping packets (in percentage). A higher value means a higher

drop probability.

Configuring WRED

In a WRED table, drop parameters are configured on a per-queue basis because WRED regulates packets on a per-queue basis.

A WRED table can be applied to multiple interfaces. For a WRED table already applied to an interface, you can modify the values of the WRED table, but you cannot remove the WRED table.

To configure and apply a queue-based WRED table:

Step Command

1. Enter system view.

2. Create a WRED table

and enter its view.

3. Configure the WRED

parameters.

4. Enter interface view.

5. Apply the WRED table

to the interface.

system-view N/A

qos wred queue table table-name N/A

queue queue-value [ drop-level

drop-level ] low-limit low-limit high-limit high-limit [ discard-probability discard-prob ]

interface interface-type interface-number

qos wred apply table-name N/A

Remarks

Optional.

By default, low-limit is 10, high-limit is 80, and discard-prob is

15.

N/A

Displaying and maintaining WRED

Task Command

Display WRED configuration information on an interface or all interfaces.

display qos wred interface [ interface-type interface-number ] [ | { begin | exclude |

include } regular-expression ]

Remarks

Available in any view.

Page 55

Display configuration information about a WRED table or all WRED tables.

display qos wred table [ table-name ] [ | { begin | exclude | include } regular-expression ]

WRED configuration example

Network requirements

Apply a WRED table to port GigabitEthernet 1/0/2. Configure the WRED table as follows:

• To try best to forward the high priority traffic, assign lower drop probability values to queues with

higher numbers. Configure different drop parameters for queue 0, queue 3, and queue 7.

• Configure different drop probability values for packets in different colors. In queue 0, configure the

drop probability as 25%, 50%, and 75% for green, yellow, and red packets. In queue 3, configure the drop probability as 5%, 10%, and 25% for green, yellow, and red packets. In queue 7, configure the drop probability as 1%, 5%, and 10% for green, yellow, and red packets.

Configuration procedure

# Create a queue-based WRED table, and configure different drop parameters for each drop precedence value in queue 0, queue 3, and queue 7.

[Sysname] qos wred queue table queue-table1 [Sysname-wred-table-queue-table1] queue 0 drop-level 0 low-limit 15 high-limit 50

discard-probability 25 [Sysname-wred-table-queue-table1] queue 0 drop-level 1 low-limit 15 high-limit 50

discard-probability 50 [Sysname-wred-table-queue-table1] queue 0 drop-level 2 low-limit 15 high-limit 50

discard-probability 75 [Sysname-wred-table-queue-table1] queue 3 drop-level 0 low-limit 25 high-limit 60

discard-probability 5 [Sysname-wred-table-queue-table1] queue 3 drop-level 1 low-limit 25 high-limit 60

discard-probability 10 [Sysname-wred-table-queue-table1] queue 3 drop-level 2 low-limit 25 high-limit 60

discard-probability 25 [Sysname-wred-table-queue-table1] queue 7 drop-level 0 low-limit 50 high-limit 85

discard-probability 1 [Sysname-wred-table-queue-table1] queue 7 drop-level 1 low-limit 50 high-limit 85

discard-probability 5 [Sysname-wred-table-queue-table1] queue 7 drop-level 2 low-limit 50 high-limit 85

discard-probability 10 [Sysname-wred-table-queue-table1] quit

Available in any view.

# Apply the WRED table named queue-table1 to GigabitEthernet 1/0/2.

[Sysname] interface gigabitethernet 1/0/2 [Sysname-GigabitEthernet1/0/2] qos wred apply queue-table1 [Sysname-GigabitEthernet1/0/2] quit

Page 56

Configuring traffic filtering

You can filter in or filter out a class of traffic by associating the class with a traffic filtering action. For example, you can filter packets sourced from a specific IP address according to network status.

Configuration procedure

To configure traffic filtering:

Step Command

1. Enter system view.

2. Create a class and enter

class view.

3. Configure match criteria.

4. Return to system view.

5. Create a behavior and

enter behavior view.

6. Configure the traffic

filtering action.

7. Return to system view.

8. Create a policy and enter

policy view.

system-view N/A

traffic classifier tcl-name [ operator { and | or } ]

if-match match-criteria N/A

quit N/A

traffic behavior behavior-name N/A

filter { deny | permit }

quit N/A

qos policy policy-name N/A

Remarks

N/A

• deny—Drops packets.

• permit—Permits packets to

pass through.

With filter deny configured for a traffic behavior, the other actions (except class-based accounting and mirroring) in the traffic behavior do not take effect.

9. Associate the class with the

traffic behavior in the QoS policy.

10. Return to system view.

classifier tcl-name behavior behavior-name

quit N/A

N/A

• Applying the QoS policy to an

11. Apply the QoS policy.

interface

• Applying the QoS policy to a VLAN

Choose one of the application destinations as needed.

• Applying the QoS policy globally

12. Display the traffic filtering

configuration.

display traffic behavior user-defined [ behavior-name ] [ | { begin | exclude | include } regular-expression ]

Optional.

Available in any view.

Page 57

Configuration example

Network requirements

As shown in Figure 17, configure traffic filtering to filter the packets whose source port is 21 and which are received on GigabitEthernet 1/0/1.

Figure 17 Network diagram



Configuration procedure

# Create advanced ACL 3000 and configure a rule to match packets whose source port number is 21.

<DeviceA> system-view [DeviceA] acl number 3000 [DeviceA-acl-adv-3000] rule 0 permit tcp source-port eq 21 [DeviceA-acl-adv-3000] quit

# Create a class named classifier_1 and use ACL 3000 as the match criterion in the class.

[DeviceA] traffic classifier classifier_1 [DeviceA-classifier-classifier_1] if-match acl 3000 [DeviceA-classifier-classifier_1] quit

# Create a behavior named behavior_1 and configure the traffic filtering action to drop packets.

[DeviceA] traffic behavior behavior_1 [DeviceA-behavior-behavior_1] filter deny [DeviceA-behavior-behavior_1] quit

# Create a policy named policy and associate class classifier_1 with behavior behavior_1 in the policy.

[DeviceA] qos policy policy [DeviceA-qospolicy-policy] classifier classifier_1 behavior behavior_1 [DeviceA-qospolicy-policy] quit

# Apply the policy named policy to the incoming traffic of GigabitEthernet 1/0/1.

[DeviceA] interface gigabitethernet 1/0/1 [DeviceA-GigabitEthernet1/0/1] qos apply policy policy inbound

Page 58

Configuring priority marking

Priority marking sets the priority fields or flag bits of packets to modify the priority of traffic. For example, you can use priority marking to set IP precedence or DSCP for a class of IP traffic to change its transmission priority in the network. Priority marking can be used together with priority mapping. For more information, see "Configuring priority mapping."

o configure priority marking, you can associate a class with a behavior configured with the priority

marking action to set the priority fields or flag bits of the class of packets.

Configuration procedure

To configure priority marking:

Step Command

1. Enter system view.

2. Create a class and enter class

view.

3. Configure match criteria.

4. Return to system view.

5. Create a behavior and enter

behavior view.

6. Set the DSCP value for packets.

7. Set the 802.1p priority for

packets.

8. Set the drop precedence for

packets.

9. Set the IP precedence for

packets.

10. Set the local precedence for

packets.

11. Return to system view.

12. Create a policy and enter

policy view.

system-view N/A

traffic classifier tcl-name [ operator { and | or } ]

if-match match-criteria N/A

quit N/A

traffic behavior behavior-name N/A

remark dscp dscp-value Optional.

remark dot1p 8021p Optional.

remark drop-precedence drop-precedence-value

remark ip-precedence

ip-precedence-value

remark local-precedence local-precedence

quit N/A

qos policy policy-name N/A

Remarks

N/A

Optional.

Applicable to only the outbound direction.

Optional.

13. Associate the class with the

traffic behavior in the QoS policy.

14. Return to system view.

classifier tcl-name behavior behavior-name

quit N/A

N/A

Page 59

Step Command

Remarks

• Applying the QoS policy to an

interface

15. Apply the QoS policy.

• Applying the QoS policy to a

VLAN

Choose one of the application destinations as needed.

• Applying the QoS policy

globally

16. Display the priority marking

configuration.

display traffic behavior user-defined [ behavior-name ] [ | { begin | exclude | include }

regular-expression ]

Optional.

Available in any view.

Priority marking configuration example

Network requirements

As shown in Figure 18, configure priority marking on Device to meet the following requirements:

Traffic source Destination

Processing priority

Host A, B Data server High

Host A, B Mail server Medium

Host A, B File server Low

Figure 18 Network diagram



Configuration procedure

# Create advanced ACL 3000 and configure a rule to match packets with destination IP address

192.168.0.1.

<Device> system-view [Device] acl number 3000 [Device-acl-adv-3000] rule permit ip destination 192.168.0.1 0 [Device-acl-adv-3000] quit

Page 60

# Create advanced ACL 3001 and configure a rule to match packets with destination IP address

192.168.0.2.

[Device] acl number 3001 [Device-acl-adv-3001] rule permit ip destination 192.168.0.2 0 [Device-acl-adv-3001] quit

# Create advanced ACL 3002 and configure a rule to match packets with destination IP address

192.168.0.3.

[Device] acl number 3002 [Device-acl-adv-3002] rule permit ip destination 192.168.0.3 0 [Device-acl-adv-3002] quit

# Create a class named classifier_dbserver and use ACL 3000 as the match criterion in the class.

[Device] traffic classifier classifier_dbserver [Device-classifier-classifier_dbserver] if-match acl 3000 [Device-classifier-classifier_dbserver] quit

# Create a class named classifier_mserver and use ACL 3001 as the match criterion in the class.

[Device] traffic classifier classifier_mserver [Device-classifier-classifier_mserver] if-match acl 3001 [Device-classifier-classifier_mserver] quit

# Create a class named classifier_fserver and use ACL 3002 as the match criterion in the class.

[Device] traffic classifier classifier_fserver [Device-classifier-classifier_fserver] if-match acl 3002 [Device-classifier-classifier_fserver] quit

# Create a behavior named behavior_dbserver and configure the action of setting the local precedence value to 4.

[Device] traffic behavior behavior_dbserver [Device-behavior-behavior_dbserver] remark local-precedence 4 [Device-behavior-behavior_dbserver] quit

# Create a behavior named behavior_mserver and configure the action of setting the local precedence value to 3.

[Device] traffic behavior behavior_mserver [Device-behavior-behavior_mserver] remark local-precedence 3 [Device-behavior-behavior_mserver] quit

# Create a behavior named behavior_fserver and configure the action of setting the local precedence value to 2.

[Device] traffic behavior behavior_fserver [Device-behavior-behavior_fserver] remark local-precedence 2 [Device-behavior-behavior_fserver] quit

# Create a policy named policy_server and associate classes with behaviors in the policy.

[Device] qos policy policy_server [Device-qospolicy-policy_server] classifier classifier_dbserver behavior

behavior_dbserver [Device-qospolicy-policy_server] classifier classifier_mserver behavior

behavior_mserver [Device-qospolicy-policy_server] classifier classifier_fserver behavior

behavior_fserver [Device-qospolicy-policy_server] quit

Page 61

# Apply the policy named policy_server to the incoming traffic of GigabitEthernet 1/0/1.

[Device] interface gigabitethernet 1/0/1 [Device-GigabitEthernet1/0/1] qos apply policy policy_server inbound [Device-GigabitEthernet1/0/1] quit

Page 62

Configuring traffic redirecting

Traffic redirecting is the action of redirecting the packets matching the specific match criteria to a certain location for processing.

The following redirect actions are supported:

• Redirecting traffic to the CPU—Redirects packets that require processing by the CPU to the CPU.

• Redirecting traffic to an interface—Redirects packets that require processing by an interface to the

interface. Note that this action applies to only Layer 2 packets, and the target interface must be a Layer 2 interface.

• Redirecting traffic to the next hop—Redirects packets that require processing by an interface to the

interface. This action only applies to Layer 3 packets.

Configuration restrictions and guidelines

• The actions of redirecting traffic to the CPU, redirecting traffic to an interface, and redirecting traffic

to the next hop are mutually exclusive with each other in the same traffic behavior.

• A QoS policy with traffic redirecting actions can be applied to only the inbound direction of a port,

VLAN, or all ports.

• You can use the display traffic behavior user-defined command to view the traffic redirecting

configuration.

Configuration procedure

To configure traffic redirecting:

Step Command

1. Enter system view.

2. Create a class and enter

class view.

3. Configure match criteria.

4. Return to system view.

5. Create a behavior and

enter behavior view.

6. Configure a traffic

redirecting action.

7. Return to system view.

8. Create a policy and enter

policy view.

system-view N/A

traffic classifier tcl-name [ operator { and | or } ]

if-match match-criteria N/A

quit N/A

traffic behavior behavior-name N/A

redirect { cpu | interface interface-type

interface-number | next-hop { ipv4-add1 [ ipv4-add2 ] | ipv6-add1 [ interface-type

interface-number ] [ ipv6-add2 [ interface-type interface-number ] ] } }

quit N/A

qos policy policy-name N/A

Remarks

N/A

Page 63

Step Command

9. Associate the class with the

traffic behavior in the QoS policy.

10. Return to system view.

11. Apply the QoS policy.

classifier tcl-name behavior behavior-name N/A

quit N/A

• Applying the QoS policy to an interface

• Applying the QoS policy to a VLAN

• Applying the QoS policy globally

Remarks

Choose one of the application destinations as needed.

Traffic redirecting configuration example

Network requirements

As shown in Figure 19:

• Device A is connected to Device B through two links. At the same time, Device A and Device B are

each connected to other devices.

• GigabitEthernet 1/0/2 of Device A and GigabitEthernet 1/0/2 of Device B belong to VLAN 200.

• GigabitEthernet 1/0/3 of Device A and GigabitEthernet 1/0/3 of Device B belong to VLAN 201.

• On Device A, the IP address of VLAN-interface 200 is 200.1.1.1/24 and that of VLAN-interface 201

i s 2 01.1.1.1 / 24 .

• On Device B, the IP address of VLAN-interface 200 is 200.1.1.2/24 and that of VLAN-interface 201

i s 2 01.1.1. 2 / 24 .

Configure the actions of redirecting traffic to the next hop to implement policy-based routing and meet the following requirements:

• Packets with source IP address 2.1.1.1 received on GigabitEthernet 1/0/1 of Device A are

forwarded to IP address 200.1.1.2.

• Packets with source IP address 2.1.1.2 received on GigabitEthernet 1/0/1 of Device A are

forwarded to IP address 201.1.1.2.

• Other packets received on GigabitEthernet 1/0/1 of Device A are forwarded according to the

routing table.

Figure 19 Network diagram



Configuration procedure

# Create basic ACL 2000 and configure a rule to match packets with source IP address 2.1.1.1.

<DeviceA> system-view [DeviceA] acl number 2000

Page 64

[DeviceA-acl-basic-2000] rule permit source 2.1.1.1 0 [DeviceA-acl-basic-2000] quit

# Create basic ACL 2001 and configure a rule to match packets with source IP address 2.1.1.2.

[DeviceA] acl number 2001 [DeviceA-acl-basic-2001] rule permit source 2.1.1.2 0 [DeviceA-acl-basic-2001] quit

# Create a class named classifier_1 and use ACL 2000 as the match criterion in the class.

[DeviceA] traffic classifier classifier_1 [DeviceA-classifier-classifier_1] if-match acl 2000 [DeviceA-classifier-classifier_1] quit

# Create a class named classifier_2 and use ACL 2001 as the match criterion in the class.

[DeviceA] traffic classifier classifier_2 [DeviceA-classifier-classifier_2] if-match acl 2001 [DeviceA-classifier-classifier_2] quit

# Create a behavior named behavior_1 and configure the action of redirecting traffic to the next hop

200.1.1.2.

[DeviceA] traffic behavior behavior_1 [DeviceA-behavior-behavior_1] redirect next-hop 200.1.1.2 [DeviceA-behavior-behavior_1] quit

# Create a behavior named behavior_2 and configure the action of redirecting traffic to the next hop

200.1.1.2.

[DeviceA] traffic behavior behavior_2 [DeviceA-behavior-behavior_2] redirect next-hop 201.1.1.2 [DeviceA-behavior-behavior_2] quit

# Create a policy named policy, associate class classifier_1 with behavior behavior_1, and associate class classifier_2 with behavior behavior_2 in the policy.

[DeviceA] qos policy policy [DeviceA-qospolicy-policy] classifier classifier_1 behavior behavior_1 [DeviceA-qospolicy-policy] classifier classifier_2 behavior behavior_2 [DeviceA-qospolicy-policy] quit

# Apply the policy named policy to the incoming traffic of GigabitEthernet 1/0/1.

[DeviceA] interface gigabitethernet 1/0/1 [DeviceA-GigabitEthernet1/0/1] qos apply policy policy inbound

Page 65

Configuring class-based accounting

Class-based accounting collects statistics (in packets or bytes) on a per-traffic class basis. For example, you can define the action to collect statistics for traffic sourced from a certain IP address. By analyzing the statistics, you can determine whether anomalies have occurred and what action to take.

Configuration procedure

To configure class-based accounting:

Step Command

1. Enter system view.

2. Create a class and enter

class view.

3. Configure match criteria.

4. Return to system view.

5. Create a behavior and

enter behavior view.

6. Configure the accounting

action.

7. Return to system view.

8. Create a policy and enter

policy view.

9. Associate the class with the

traffic behavior in the QoS policy.

system-view N/A

traffic classifier tcl-name [ operator { and | or } ]

if-match match-criteria N/A

quit N/A

traffic behavior behavior-name N/A

accounting { byte | packet }

quit N/A

qos policy policy-name N/A

classifier tcl-name behavior behavior-name

Remarks

N/A

Optional.

• byte—Counts traffic in

bytes.

• packet—Counts traffic in

packets.

N/A

10. Return to system view.

quit N/A

• Applying the QoS policy to an

11. Apply the QoS policy.

interface

• Applying the QoS policy to a VLAN

Choose one of the application destinations as needed.

• Applying the QoS policy globally

Page 66

Displaying and maintaining class-based traffic accounting

To verify the class-based accounting configuration, use the display qos policy global, display qos policy interface, or display qos vlan-policy command in any view to display the traffic statistics collected after the configuration is complete.

Configuration example

Network requirements

As shown in Figure 20, configure class-based accounting to collect the number of packets sourced from

1.1.1.1/ 2 4 a n d r e c e i v e d o n G i g a b i t E t h e r n e t 1 / 0 / 1.

Figure 20 Network diagram



Configuration procedure

# Create basic ACL 2000 and configure a rule to match packets with source IP address 1.1.1.1.

<DeviceA> system-view [DeviceA] acl number 2000 [DeviceA-acl-basic-2000] rule permit source 1.1.1.1 0 [DeviceA-acl-basic-2000] quit

# Create a class named classifier_1 and use ACL 2000 as the match criterion in the class.

[DeviceA] traffic classifier classifier_1 [DeviceA-classifier-classifier_1] if-match acl 2000 [DeviceA-classifier-classifier_1] quit

# Create a behavior named behavior_1 and configure the traffic accounting action that counts traffic in packets.

[DeviceA] traffic behavior behavior_1 [DeviceA-behavior-behavior_1] accounting packet [DeviceA-behavior-behavior_1] quit

# Create a policy named policy, and associate class classifier_1 with behavior behavior_1 in the policy.

[DeviceA] qos policy policy [DeviceA-qospolicy-policy] classifier classifier_1 behavior behavior_1 [DeviceA-qospolicy-policy] quit

# Apply the policy named policy to the incoming traffic of GigabitEthernet 1/0/1.

[DeviceA] interface gigabitethernet 1/0/1 [DeviceA-GigabitEthernet1/0/1] qos apply policy policy inbound [DeviceA-GigabitEthernet1/0/1] quit

# Display traffic statistics to verify the configuration.

[DeviceA] display qos policy interface gigabitethernet 1/0/1

Page 67

mapping

Interface: GigabitEthernet1/0/1

Direction: Inbound

Policy: policy Classifier: classifier_1 Operator: AND Rule(s) : If-match acl 2000 Behavior: behavior_1 Accounting Enable: 28529 (Packets)

Appendix

This chapter lists the appendix for QoS.

Appendix A Default priority mapping tables

For the default dscp-dscp priority mapping table, an input value yields a target value equal to it.

Table 4 Default dot1p-lp and dot1p-dp priority mapping tables

ut priority value dot1p-l

802.1p priority (dot1p)

0 2 0

1 0 0

2 1 0

3 3 0

4 4 0

5 5 0

6 6 0

7 7 0

Local precedence (l

dot1p-dp mapping

Drop precedence (dp)

Table 5 Default dscp-dp and dscp-dot1p priority mapping tables

ut priority value dscp-d

dscp-dot1p mapping

DSCP Drop precedence (dp)

0 to 7 0 0

8 to 15 0 1

16 to 23 0 2

24 to 31 0 3

802.1p priority (dot1p)

Page 68

mapping

Input priority value dscp-d

32 to 39 0 4

40 to 47 0 5

48 to 55 0 6

56 to 63 0 7

dscp-dot1p mapping

Appendix B Introduction to packet precedences

This section describes packet precedences.

IP precedence and DSCP values

Figure 21 ToS and DS fields

As shown in Figure 21, the ToS field in the IPv4 header contains 8 bits, where the first 3 bits (0 to 2) represent IP precedence from 0 to 7, and the Traffic Classes field in the IPv6 header contains 8 bits, where the first 3 bits (0 to 2) represent IP precedence from 0 to 7. According to RFC 2474, the ToS field in the IPv4 header or the Traffic Classes field in the IPv6 header is redefined as the differentiated services (DS) field, where a DSCP value is represented by the first 6 bits (0 to 5) and is in the range of 0 to 63. The remaining 2 bits (6 and 7) are reserved.

Table 6 IP precedence

recedence (decimal) IP precedence (binary) Description

0 000 Routine

1 001 priority

2 010 immediate

3 011 flash

4 100 flash-override

5 101 critical

6 110 internet

7 111 network

Page 69

Table 7 DSCP values

DSCP value (decimal) DSCP value (binar

46 101110 ef

10 001010 af11

12 001100 af12

14 001110 af13

18 010010 af21

20 010100 af22

22 010110 af23

26 011010 af31

28 011100 af32

30 011110 af33

34 100010 af41

36 100100 af42

38 100110 af43

8 001000 cs1

16 010000 cs2

) Description

24 011000 cs3

32 100000 cs4

40 101000 cs5

48 110000 cs6

56 111000 cs7

0 000000 be (default)

802.1p priority

802.1p priority lies in the Layer 2 header and applies to occasions where Layer 3 header analysis is not needed and QoS must be assured at Layer 2.

Figure 22 An Ethernet frame with an 802.1Q tag header

As shown in Figure 22, the 4-byte 802.1Q tag header consists of the TPID (2 bytes in length), whose value is 0x8100, and the TCI (2 bytes in length). Figure 23 sho The Priority field in the 802.1Q tag header is called the "802.1p priority", because its use is defined in IEEE 802.1p. Table 8 sho

ws the format of the 802.1Q tag header.

ws the values for 802.1p priority.

Page 70

p p

Figure 23 802.1Q tag header

Table 8 Description on 802.1p priority

802.1

0 000 best-effort

1 001 background

2 010 spare

3 011 excellent-effort

4 100 controlled-load

5 101 video

6 110 voice

7 111 network-management

riority (decimal) 802.1p priority (binary) Description

Page 71

Support and other resources

Contacting HP

For worldwide technical support information, see the HP support website:

http://www.hp.com/support

Before contacting HP, collect the following information:

• Product model names and numbers

• Technical support registration number (if applicable)

• Product serial numbers

• Error messages

• Operating system type and revision level

• Detailed questions

Subscription service

HP recommends that you register your product at the Subscriber's Choice for Business website:

http://www.hp.com/go/wwalerts

After registering, you will receive email notification of product enhancements, new driver versions, firmware updates, and other product resources.

Related information

Documents

To find related documents, browse to the Manuals page of the HP Business Support Center website:

http://www.hp.com/support/manuals

• For related documentation, navigate to the Networking section, and select a networking category.

• For a complete list of acronyms and their definitions, see HP FlexNetwork Technology Acronyms.

Websites

• HP.com http://www.hp.com

• HP Networking http://www.hp.com/go/networking

• HP manuals http://www.hp.com/support/manuals

• HP download drivers and software http://www.hp.com/support/downloads

• HP software depot http://www.software.hp.com

• HP Education http://www.hp.com/learn