Q1: 2148T hardware can only support CoS based traffic classification.
You can still configure ACL based classification on the 2148T interfaces (including DSCP), this actual classification will occur on the Nexus 5000.
I don't know the specific about roadmaps for future support on DSCP, I advise you here to contact your Cisco System Engineer / Account team to find out more. Also, note that the 2148T supports two classes of services and 2 queues. The 2200 series (2224,2232,2248) support 6 hardware queues.
Q2: You can only do CoS marking, not DSCP, so there is no way to police with dscp either.
There are 3 policy types:
-qos: define traffic classification rules. Attach point is system qos or ingress interface
-queuing: set priority queue, deficit weigh round robin. Attach point is system qos, egress, ingress interface.
-network-qos: system class type (drop / no-drop), MTU per class of service, Buffer size, marking. Attach point is system qos.
Prefer service policy attached under interface when same type of service policy is attached at both system qos and interface.
Qos and network-qos policy-map are required to create new system classes.
As indicated above, network-qos policy is used for packet marking.
When congestion occurs, depending on the policy configuration:
-PAUSE upstream transmitter for lossless traffic
-Tail drop for regular traffic when buffer is exhausted
Priority flow control (PFC) or 802.3X PAUSE can be deployed to ensure lossless for applications that can not tolerate packet loss.
A buffer management module monitors buffer usage for no-drop class of service. It will signal MAC to generate PFC or PAUSE when the buffer usage crosses threshold.
The FCoE traffic is assigned to class-fcoe which is a no-drop system class.
The other class of service by default have normal drop behavior (tail drop) and can be configured as no-drop.
Q3: Exactly, you can use bandwitdh percent 0 for the fcoe class if you don't plan on using it.
Q4: No remarking due to platform limitations
I want to use your question here to explain more about the QoS on Nexus 5000/2000 with configuration examples:
The service policy configured under “system qos” will be populated from N5k to FEX only when all the matching criteria are “match cos”.
If there are some other match clauses, such as match dscp, or match ip access-group in the qos policy-map the FEX won’t accept the service policy and all the traffic will be placed into the default queue.
For the ingress traffic(from server to network direction) if the traffic is not marked with CoS value it will be placed in the default queue on FEX.
Once the traffic is received on N5k it will be classified based on configured rule and are placed in the proper queue.
For the egress traffic (from N5k to FEX to server) it is recommended to mark the traffic with CoS value on N5k so that FEX can classify and queue the traffic properly.
Here is a a complete configuration for N5k and Nexus 2248 to classify the traffic and configure proper bandwidth for each type of traffic.
The configuration example only applies to N5k and 2248. The configuration for 2148 is slightly different due to the fact that 2148 has only two queues for user data. The Nexus 2248 has 6 hardware queues for user data, which is same as Nexus 5000. You can apply similar configuration by reducing the number of queues used.
Class-map for global qos policy-map, which will be used to create CoS-queue mapping.
class-map type qos voice-global
match cos 5
class-map type qos critical-global
match cos 6
class-map type qos scavenger-global
match cos 1
class-map type qos video-signal-global
match cos 4
This qos policy-map will be attached under “system qos”. It will be downloaded to 2248 to create CoS to queue mapping.
policy-map type qos classify-5020-global
class voice-global
set qos-group 5
class video-signal-global
set qos-group 4
class critical-global
set qos-group 3
class scavenger-global
set qos-group 2
class-map type qos Video
match dscp 34
class-map type qos Voice
match dscp 40,46
class-map type qos Control
match dscp 48,56
class-map type qos BulkData
match dscp 10
class-map type qos Scavenger
match dscp 8
class-map type qos Signalling
match dscp 24,26
class-map type qos CriticalData
match dscp 18
This qos policy-map will be applied under all N5k and 2248 interfaces to classify all incoming traffic based on DSCP marking. T
he policy-map will be applied under Nexus 2248 interfaces the traffic will be classified on N5k.
policy-map type qos Classify-5020
class Voice
set qos-group 5
class CriticalData
set qos-group 3
class Control
set qos-group 3
class Video
set qos-group 4
class Signalling
set qos-group 4
class Scavenger
set qos-group 2
class-map type network-qos Voice
match qos-group 5
class-map type network-qos Critical
match qos-group 3
class-map type network-qos Scavenger
match qos-group 2
class-map type network-qos Video-Signalling
match qos-group 4
This policy-map type network-qos will be applied under “system qos” to define the MTU, marking and queue-limit(not configured here).
policy-map type network-qos NetworkQoS-5020
class type network-qos Voice
set cos 5
class type network-qos Video-Signalling
set cos 4
mtu 9216
class type network-qos Scavenger
set cos 1
mtu 9216
class type network-qos Critical
set cos 6
mtu 9216
class type network-qos class-default
mtu 9216
class-map type queuing Voice
match qos-group 5
class-map type queuing Critical
match qos-group 3
class-map type queuing Scavenger
match qos-group 2
class-map type queuing Video-Signalling
match qos-group 4
The queuing interface will be applied under “system qos” to define the priority queue and how bandwidth is shared among non-priority queues.
policy-map type queuing Queue-5020
class type queuing Scavenger
bandwidth percent 1
class type queuing Voice
priority
class type queuing Critical
bandwidth percent 6
class type queuing Video-Signalling
bandwidth percent 20
class type queuing class-fcoe
bandwidth percent 0
class type queuing class-default
bandwidth percent 73
The input queuing policy determines how bandwidth are shared for FEX uplink in the direction from FEX to N5k.
The output queueing policy determines the bandwidth allocation for both N5k interfaces and FEX host interfaces.
system qos
service-policy type qos input classify-5020-global
service-policy type network-qos NetworkQoS-5020
service-policy type queuing input Queue-5020
service-policy type queuing output Queue-5020
Apply service-policy type qos under physical interface in order to classify traffic based on DSCP.
For etherchannel member the service-policy needs to be configured under interface port-channel.
interface eth1/1-40
service-policy type qos input Classify-5020
interface eth100/1/1-48
service-policy type qos input Classify-5020
You can check if the CoS to queue mapping are properly configured under FEX interfaces with the command show queuing interface.
You can also use it to check the bandwidth and MTU configuration. And, the same commands apply for N5K.
N5k# sh queuing interface ethernet 100/1/1
Ethernet100/1/1 queuing information:
Input buffer allocation:
Qos-group: 0 2 3 4 5 (shared)
frh: 2
drop-type: drop
cos: 0 1 2 3 4 5 6
xon xoff buffer-size
---------+---------+-----------
21760 26880 48640
Queueing:
queue qos-group cos priority bandwidth mtu
--------+------------+--------------+---------+---------+----
2 0 0 2 3 WRR 73 9280
4 2 1 WRR 1 9280
5 3 6 WRR 6 9280
6 4 4 WRR 20 9280
7 5 5 PRI 0 1600
Queue limit: 64000 bytes
Queue Statistics:
queue rx tx
------+---------------+---------------
2 113822539041 1
4 0 0
5 0 0
6 417659797 0
7 0 0
Port Statistics:
rx drop rx mcast drop rx error tx drop
---------------+---------------+---------------+---------------
0 0 0 0
Priority-flow-control enabled: no
Flow-control status:
cos qos-group rx pause tx pause masked rx pause
-------+-----------+---------+---------+---------------
0 0 xon xon xon
1 2 xon xon xon
2 0 xon xon xon
3 0 xon xon xon
4 4 xon xon xon
5 5 xon xon xon
6 3 xon xon xon
7 n/a xon xon xon
N5k#
Latest QoS configuration guide:
