EMAIL SUPPORT

dclessons@dclessons.com

LOCATION

NZ

QOS on Nexus 7000 switch Modules

QOS on Nexus 7000 switch Modules

Posted on Jan 24, 2020 (0)

QOS on Nexus 7000 switch Modules

In the core datacenter layer switches usually COS and DHCP marking are not required because mostly these marking are done at access layer or Virtual access layer switches. In this case core layer has main responsibility to manage packet loss and core layer should trust the CoS and DHCP marking on ingress and perform the ingress and egress queuing.

In Nexus 7000 Switches, there are F and M module both supports QoS out of which we will see the differences in architecture and capabilities between these two M2/F2 Modules.

Nexus 7000 supports following QoS policies:

  • Qos: This policy is used for marking and policing.
  • Network-qos (required on F-Series modules only): Defines the characteristics of network-wide QoS properties and should be applied consistently on all switches participating in the network.
  • Queuing: This policy is used for queuing and scheduling.

Nexus 7000 trust the QoS marked traffic by default according to following rule:

  • For (L2) bridged traffic, CoS is used for ingress queue selection and DSCP values which is received is transmitted unmodified and are ignored from a QoS perspective. The received CoS markings are used for egress queue selection and are also transmitted unmodified on egress bridged ports.
  • For (L3) routed traffic, CoS is used for ingress queue selection; DSCP markings are not modified, but are used to generate new CoS markings derived from the 3 Most Significant Bits (MSB) of the DSCP; these newly generated CoS markings are then used for egress queue selection even if the egress interface is not an 802.1Q trunk and so not carrying CoS within the frame.

Let’s now understand the Nexus 7000 M2 Qos Architecture and Concepts:

Nexus 7000 M2 Module: QoS Design & Architecture

Below figure describes the Nexus 7000 M2 Series Module architecture and also labels the QoS policies applied.

In Nexus 7000 M2 Modules following are QoS policies applied in marked places in above diagram:

  1. Ingress (type queuing) policies are applied at the ingress physical port.
  2. Classification, marking and policing (type qos) policies are implemented within the forwarding engine.
  3. Fabric QoS policies are applied in the VOQs beforethe packet traverses the three-stage switching fabric.
  4. Egress (type queuing) policies are applied in the VOQs afterthe packet traverses the three-stage switching fabric.
  5. Egress (type queuing) policies are applied again in the egress physical port.

Here ingress and egress QoS policies can be configured manually or used default but fabric Qos for VOQ Queuing is not configurable and is made standard across nexus 7000 Series.

You have learned how VOQ works in Module 1 Hardware chapter, so here we are only giving snapshot of it. As soon as Qos Marked traffic inters in to Module based on its Ingress queuing policies which will be described later in this chapter, packets are queued in VOQ as per following table:



PQ1 is strict priority queue and Q2 to Q4 are scheduled with weighted Round robin (DWRR) and are assigned equal weights. These above mappings are static and are not configurable. Once central arbiter grant the permission the Packet from ingress module VOQ will be sent across to Fabric Module and are queued in to Egress VOQ queue and then is scheduled according to its marking and queue priority weight to be queued to Egress Queue by egress Queuing policy and then finally transmitted to output interface.

Below figure described each stage queuing function:

  1. Ingress port buffer:Manages congestion for ingress forwarding/replication engines
  2. Ingress VOQ buffer (fabric queue):Manages congestion toward the switching fabric
  3. Egress VOQ buffer:Receives frames from the fabric and manages congestion for multidestination frames
  4. Egress port buffer:Manages congestion at the egress interface

Now let’s understand how ingress and egress queuing is done in Nexus 7000 M2 module.

Nexus 7000 by default trust the CoS and DSCP value on ingress and there are two steps to configure QoS on M series module

  1. Configure Ingress Queuing
  2. Configure Egress Queuing

Now each Nexus 7000 M2 series module supports following types of ingress and egress QoS structure. Nexus 7000 supports four class (4Q2T ingress and 1P3Q4T egress) model and eight class (8Q2T ingress and 1P3Q4T egress) model

For Eight Class QoS model:

  • On Ingress: 8Q2T ingress Queuing structure is used
  • On Egress: 1P7Q4T egress Queuing structure is used.

The Nexus 7000 uses pre-defined ingress queuing class-maps given in below figure

Nexus 7000 also uses pre-defined egress queuing class-map given in below figure:

Also queuing feature are enabled by default on nexus 7000 via system defaults policy-maps applied on each interface and port-channel. The default 8Q2T ingress and default 1P7Q4T egress queuing models are given in below figure:

This can be verified by following commands where in explicit policies are attached and shows how default policy is working both for ingress and egress.

N7K# show policy-map interface Ethernet 2/1
Global statistics status : enabled
Ethernet2/24
Service-policy (queuing) input: default-in-policy
policy statistics status: enabled (current status: enabled)
Class-map (queuing): in-q1 (match-any)
queue-limit percent 50
bandwidth percent 80
queue dropped pkts : 0
Class-map (queuing): in-q-default (match-any)
queue-limit percent 50
bandwidth percent 20
queue dropped pkts : 0
Service-policy (queuing) output: default-out-policy
policy statistics status: enabled (current status: enabled)
Class-map (queuing): out-pq1 (match-any)
priority level 1
queue-limit percent 16
queue dropped pkts : 0
Class-map (queuing): out-q2 (match-any)
queue-limit percent 1
queue dropped pkts : 0
Class-map (queuing): out-q3 (match-any)
queue-limit percent 1
queue dropped pkts : 0
Class-map (queuing): out-q-default (match-any)
queue-limit percent 82
bandwidth remaining percent 25
queue dropped pkts : 0
N7K#

If you configure any explicit policy then it will overwrite the default policy applied on interface. If you want to change the CoS to queue assignment in the system-specified queuing class maps, it should be performed on the primary VDC then it will effect on all other non VDC.

Generally we follow following CoS to queue mapping in Nexus 7000 M2 Eight class queuing model:

  • Real-time traffic (marked EF, mapped by default to CoS 5) is allocated 10 percent bandwidth in the ingress 8Q2T model, but is enabled with strict-priority queuing in the egress 1P7Q4T model.
  • Network control traffic (marked CoS 7) is allocated 5 percent bandwidth in the ingress 8Q2T model and a 5 percent bandwidth-remaining allocation in the egress 1P7Q4T model.
  • Internetwork control traffic (marked CS6, mapped by default to CoS 6) is allocated 5 percent bandwidth in the ingress 8Q2T model and a 5 percent bandwidth-remaining allocation in the egress 1P7Q4T model.
  • Video traffic (marked AF4 and mapped by default to CoS 4 or marked AF31 and explicitly mapped to CoS 4) is allocated 25 percent bandwidth in the ingress 8Q2T model and a 25 percent bandwidth-remaining allocation in the egress 1P7Q4T model.
  • Signaling traffic (marked CS3, mapped by default to CoS 3) is assigned to a dedicated non-priority queue with a 10 percent bandwidth allocation in the ingress 8Q2T model and a 10 percent bandwidth-remaining allocation in the egress 1P7Q4T model.
  • Transactional data (marked AF2, mapped by default to CoS 2) is assigned to dedicated non-priority queue with a 10 percent bandwidth allocation in the ingress 8Q2T model and a 10 percent bandwidth-remaining allocation in the egress 1P7Q4T model.
  • Bulk data (marked AF1, mapped by default to CoS 1) is assigned to dedicated non-priority queue with a 10 percent bandwidth allocation in the ingress 8Q2T model and a 10 percent bandwidth-remaining allocation in the egress 1P7Q4T model.
  • Best-effort traffic (marked DF, mapped by default to CoS 0) is assigned to the default queue with a 25 percent bandwidth allocation in the ingress 8Q2T model and a 35 percent bandwidth-remaining allocation in the egress 1P7Q4T model.

Below figure described these eight class mapping along with bandwidth and buffer allocation and congestion avoidance policies.

Below is the corresponding configuration of eight-class (8Q2T ingress and 1P7Q4T egress) queuing.

! This section configures the ingress queuing class maps
N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q1
N7K(config-cmap-que)# match cos 5
! Voice traffic (DSCP EF/CoS 5) is mapped to ingress Q1
N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q2
N7K(config-cmap-que)# match cos 7
! Network Control traffic (CoS 7) is mapped in ingress Q2
N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q3
N7K(config-cmap-que)# match cos 6
! Network control traffic (DSCP CS6/CoS 6) is mapped in ingress Q3
N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q4
N7K(config-cmap-que)# match cos 4
! Video traffic (DSCP AF4/CoS 4) is mapped in ingress Q4
N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q5
N7K(config-cmap-que)# match cos 3
! Signaling (DSCP CS3/CoS 3) is mapped to ingress Q5
N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q6
N7K(config-cmap-que)# match cos 2
! Transactional-Data (DSCP AF2/CoS 2) is mapped to ingress Q6
N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q7
N7K(config-cmap-que)# match cos 1
! Bulk-Data (DSCP AF1/CoS 1) is mapped to ingress Q7
! This section configures the egress queuing class maps
N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-pq1
N7K(config-cmap-que)# match cos 5
! Voice traffic (DSCP EF/CoS 5) is mapped to egress PQ1
N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q2
N7K(config-cmap-que)# match cos 7
! Network Control traffic (CoS 7) is mapped in egress Q2
N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q3
N7K(config-cmap-que)# match cos 6
! Network control traffic (DSCP CS6/CoS 6) is mapped in egress Q3
N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q4
N7K(config-cmap-que)# match cos 4
! Video traffic (DSCP AF4/CoS 3) is mapped in egress Q4
N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q5
N7K(config-cmap-que)# match cos 3
! Signaling (DSCP CS3/CoS 3) is mapped to egress Q5
N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q6
N7K(config-cmap-que)# match cos 2
! Transactional-Data (DSCP AF2/CoS 2) is mapped to egress Q6
N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q7
N7K(config-cmap-que)# match cos 1
! Bulk-Data (DSCP AF1/CoS 1) is mapped to egress Q7
! This section configures the 8Q2T ingress queuing policy map
N7K(config)# policy-map type queuing 8Q2T-INGRESS
N7K(config-pmap-que)# class type queuing 8q2t-in-q1
N7K(config-pmap-c-que)# bandwidth percent 10
N7K(config-pmap-c-que)# queue-limit percent 10
! Ingress Q1 (Voice) is allocated 10% bandwidth and 10% queue-limit
N7K(config-pmap-c-que)# class type queuing 8q2t-in-q2
N7K(config-pmap-c-que)# bandwidth percent 5
N7K(config-pmap-c-que)# queue-limit percent 5
! Ingress Q2 (OAM) is allocated 5% bandwidth and 5% queue-limit
N7K(config-pmap-c-que)# class type queuing 8q2t-in-q3
N7K(config-pmap-c-que)# bandwidth percent 5
N7K(config-pmap-c-que)# queue-limit percent 5
! Ingress Q3 (Routing) is allocated 5% bandwidth and 5% queue-limit
N7K(config-pmap-c-que)# class type queuing 8q2t-in-q4
N7K(config-pmap-c-que)# bandwidth percent 25
N7K(config-pmap-c-que)# queue-limit percent 25
! Ingress Q4 (Video) is allocated 25% bandwidth and 25% queue-limit
N7K(config-pmap-c-que)# random-detect cos-based
N7K(config-pmap-c-que)# random-detect cos 4 minimum-threshold percent 80 maximum-threshold percent 100
! CoS-Based WRED is enabled and tuned on video queue (Q4)
N7K(config-pmap-c-que)# class type queuing 8q2t-in-q5
N7K(config-pmap-c-que)# bandwidth percent 10
N7K(config-pmap-c-que)# queue-limit percent 10
! Ingress Q5 (Signaling) gets 10% bandwidth and 10% queue-limit
N7K(config-pmap-c-que)# class type queuing 8q2t-in-q6
N7K(config-pmap-c-que)# bandwidth percent 10
N7K(config-pmap-c-que)# queue-limit percent 10
! Ingress Q6 (Trans-Data) gets 10% bandwidth and 10% queue-limit
N7K(config-pmap-c-que)# random-detect cos-based
N7K(config-pmap-c-que)# random-detect cos 2 minimum-threshold percent 80 maximum-threshold percent 100
! CoS-Based WRED is enabled and tuned on Trans-Data queue (Q6)
N7K(config-pmap-c-que)# class type queuing 8q2t-in-q7
N7K(config-pmap-c-que)# bandwidth percent 10
N7K(config-pmap-c-que)# queue-limit percent 10
! Ingress Q7 (Bulk-Data) gets 10% bandwidth and 10% queue-limit
N7K(config-pmap-c-que)# random-detect cos-based
N7K(config-pmap-c-que)# random-detect cos 1 minimum-threshold percent 80 maximum-threshold percent 100
! CoS-Based WRED is enabled and tuned on Bulk-Data queue (Q7)
N7K(config-pmap-c-que)# class type queuing 8q2t-in-q-default
N7K(config-pmap-c-que)# bandwidth percent 25
N7K(config-pmap-c-que)# queue-limit percent 25
! Default Ingress Queue is allocated 25% bandwidth and 25% queue-limit
N7K(config-pmap-c-que)# random-detect cos-based
N7K(config-pmap-c-que)# random-detect cos 0 minimum-threshold percent 80 maximum-threshold percent 100
! CoS-Based WRED is enabled and tuned on default queue
! This section configures the 1P7Q4T egress queuing policy map
N7K(config)# policy-map type queuing 1P7Q4T-EGRESS
N7K(config-pmap-que)# class type queuing 1p7q4t-out-pq1
N7K(config-pmap-c-que)# priority
! Strict priority is enabled on egress PQ1
N7K(config-pmap-c-que)# queue-limit percent 10
! Egress PQ (Realtime) is allocated 10% of buffers
N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q2
N7K(config-pmap-c-que)# bandwidth remaining percent 5
N7K(config-pmap-c-que)# queue-limit percent 5
! Egress Q2 (OAM) is allocated 5% BWR and 5% queue-limit
N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q3
N7K(config-pmap-c-que)# bandwidth remaining percent 5
N7K(config-pmap-c-que)# queue-limit percent 5
! Egress Q3 (Routing) is allocated 5% BWR and 5% queue-limit
N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q4
N7K(config-pmap-c-que)# bandwidth remaining percent 25
N7K(config-pmap-c-que)# queue-limit percent 25
! Egress Q4 (Video) is allocated 25% BWR and 25% queue-limit
N7K(config-pmap-c-que)# random-detect cos-based
N7K(config-pmap-c-que)# random-detect cos 4 minimum-threshold percent 80 maximum-threshold percent 100
! CoS-Based WRED is enabled and tuned on video queue (Q4)
N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q5
N7K(config-pmap-c-que)# bandwidth remaining percent 10
N7K(config-pmap-c-que)# queue-limit percent 10
! Egress Q5 (Signaling) gets 10% BWR and 10% queue-limit
N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q6
N7K(config-pmap-c-que)# bandwidth remaining percent 10
N7K(config-pmap-c-que)# queue-limit percent 10
! Egress Q6 (Trans-Data) gets 10% BWR and 10% queue-limit
N7K(config-pmap-c-que)# random-detect cos-based
N7K(config-pmap-c-que)# random-detect cos 2 minimum-threshold percent 80 maximum-threshold percent 100
! CoS-Based WRED is enabled and tuned on Trans-Data queue (Q6)
N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q7
N7K(config-pmap-c-que)# bandwidth remaining percent 10
N7K(config-pmap-c-que)# queue-limit percent 10
! Egress Q7 (Bulk-Data) gets 10% BWR and 10% queue-limit
N7K(config-pmap-c-que)# random-detect cos-based
N7K(config-pmap-c-que)# random-detect cos 1 minimum-threshold percent 80 maximum-threshold percent 100
! CoS-Based WRED is enabled and tuned on Bulk-Data queue (Q7)
N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q-default
N7K(config-pmap-c-que)# bandwidth remaining percent 35
N7K(config-pmap-c-que)# queue-limit percent 25
! Default Egress Queue is allocated 35% BWR and 25% queue-limit
N7K(config-pmap-c-que)# random-detect cos-based
N7K(config-pmap-c-que)# random-detect cos 0 minimum-threshold percent 80 maximum-threshold percent 100
! CoS-Based WRED is enabled and tuned on default queue
! This section applies the queuing policies to the interface(s)
N7K(config)# interface Ethernet 1/20
N7K(config-if)# service-policy type queuing input 8Q2T-INGRESS
! 8Q2T ingress queuing policy is attached to the interface (s)
N7K(config-if)# service-policy type queuing output 1P7Q4T-EGRESS
! 1P7Q4T egress queuing policy is attached to the interface (s)

M2 OTV QoS Design:

From QoS point of view before the Layer-2 frame is encapsulated to OTV header, OTV edge device copies the CoS bits from original Layer 2 packet and paste it to OTV shim header and same for DSCP , DSCP values are copied from original IP header and is put to outer DSCP field. This make the QoS consistence across OTV and Sites. When packet arrives at destination and is decapsulated CoS value is recovered from OTV Shim and is added to original 802.1Q TC field.

If the packet is untagged with CoS will have the outer DSCP value 0.

Nexus 7000 F2 Module: QoS design and Architecture:

Nexus 7000 F2/F2e modules have different QoS architecture and design compared to M series module. Below figure describes where QoS policies can be applied on F2 Modules.

QoS policies are applied at the following points on F2 modules:

  1. Classification, marking and policing (type qos) policies are implemented within the forwarding engine.
  2. Ingress and egress (type queuing) policies are applied in the VOQs beforethe packet traverses the three-stage switching fabric; the ingress queuing policies define the buffers allocations for these VOQs. However, it is the egress queuing policies define the scheduling of these VOQs.
  3. Egress (type queuing) policies are applied in the VOQs afterthe packet traverses the three-stage switching fabric; buffer allocations for these post-fabric VOQs are fixed, but the egress queuing policy defines the scheduling of these VOQs.

The scheduling of VOQ policies for access the fabric is controlled by egress type queuing policies on F2 Module whereas on M2 module these Fabric policies are not configurable.

F2 Module does not have are physical port queuing buffers on egress. You can compare both M2 and F2 Physical port queuing port buffers.

Following is the F2 virtual queuing buffers and its related functions are as follows:

  1. Ingress pause latency (“skid”) buffer:receives packets in flight and manages congestion for ingress forwarding/replication engines
  2. Ingress VOQ buffer (fabric queue):Manages congestion toward the switching fabric
  3. Egress VOQ buffer:Receives frames from the fabric and manages congestion for multidestination frames

 F2 QoS Design:

Whenever any 2 module are installed on Nexus 7000 series switches following three steps are required to configure QOS.

  1. Apply the correct network-qospolicy to the system.
  2. Configure ingress queuing.
  3. Configure egress queuing.

Whenever Nexus F2 module are instated in Nexus 7000 switch are is operation following five network-Qos policies templates are automatically added to the system.

Network QoS policy template names contain the abbreviation nq to refer to network-qos. In addition, the numbers 4, 6, 7, and 8 denote the number of the drop CoS values (CoS values that may be dropped during congestion) that is defined within the policy template, and finally e denotes Ethernet. The 4Q4T in default-nq-8e-4q4q-policy refers to the fact that both the ingress and egress queuing structures use four queues (as opposed to the default-nq-8e-policy template that uses four queues on egress, but only two on ingress).

By default, the default-nq-8e-policy is applied to the system. These policy templates can be copied and modified or they can be simply applied globally by attaching them to system qos.

Therefore, the default-nq-7e-policy network qos template is used here  because it meets the minimum requirements for enabling FCoE in Nexus line cards. Therefore, in below configuration the network-qos template default-nq-7e-policyis applied globally (that is, to system qos) because this policy auto configures a no-drop service for FCoE.

! This section applies the default-nq-7e-policy to system qos
N7K(config)# system qos
N7K(config-sys-qos)# service-policy type network-qos default-nq-7e-policy
! Applies the default-nq-7e-policy globally
2013 May 30 09:47:02 N7K -QOS %$ VDC-3 %$ %IPQOSMGR-2-QOSMGR_NETWORK_QOS_POLICY_
CHANGE: Policy default-nq-7e-policy is now active
2013 May 30 09:47:02 N7K%$ VDC-1 %$ %IPQOSMGR-2-QOSMGR_NETWORK_QOS_POLICY_CHANGE:
Policy default-nq-7e-policy is now active
N7K (config-sys-qos)#
N7K# show class-map type network-qos c-nq-7e-drop
!
Type network-qos class-maps
===========================
class-map type network-qos match-any c-nq-7e-drop
Description: 7E Drop CoS map
match cos 0-2,4-7
N7K# show class-map type network-qos c-nq-7e-ndrop-fcoe
Type network-qos class-maps
=============================================
class-map type network-qos match-any c-nq-7e-ndrop-fcoe
Description: 7E No-Drop FCoE CoS map
match cos 3
match protocol fcoe

As shown in above example all CoS values except 3 are assigned to the Drop class (c-nq-7e-drop), while FCoE is matched on CoS 3 and by protocol fcoe and assigned to the No Drop class (c-nq-7e-ndrop-fcoe). Incidentally, the match protocol fcoe command also advertises fcoe in DCB Exchanges (DCBX).

It may be of interest to note that the ingress and egress queuing policies are actually hierarchical QoS policies (with queuing policies nested within queuing policies). Specifically, the default-4q-7e-drop-in-policy and default-4q-7e-ndrop-in-policy are nested within the default-4q-7e-in-policy on ingress, and the default-4q-7e-drop-out-policy and default-4q-7e-ndrop-out-policy are nested within the default-4q-7e-out-policy on egress. The egress hierarchical queuing policies are given in below figure:

F2 Queuing Models:

The below figure describes the default ingress and egress queuing models by network-Qos policy template:

Each default ingress and egress queuing policy has corresponding system-defined class map names, as summarised below:

Default Ingress queuing policy class-map

Default egress queuing policy class-map

Below figure describes the F2 default ingress queuing models by Network Qos policy template.

Below figure describes the F2 default egress queuing models by Network Qos policy template.

Now As Nexus 7000 M series module has eight class ingress and egress queuing models same ways F2 Module has same default eight class ingress and egress queuing models.

However, for the sake of demonstration purposes, let’s consider an example where you might want to modify this nq-7e policy template to tune it more tightly to your requirements and environment.

You first have to clone the default queuing policy—either prepending it with a prefix (with the prefix keyword) or appending it with a suffix (with the suffix keyword). This is shown in below Example where the default policy is prepended with the prefix MODIFIED-.

After the policy has been cloned and prepended, it will appear within the configuration, as shown

N7K# show run | begin MODIFIED
policy-map type queuing MODIFIED-4q-7e-drop-in
class type queuing 4q4t-7e-in-q1
queue-limit percent 10
bandwidth percent 25
class type queuing 4q4t-7e-in-q-default
queue-limit percent 45
bandwidth percent 25
class type queuing 4q4t-7e-in-q3
queue-limit percent 45
bandwidth percent 25
!
policy-map type queuing MODIFIED-4q-7e-ndrop-in
class type queuing 4q4t-7e-in-q4
queue-limit percent 100
bandwidth percent 25
!
policy-map type queuing MODIFIED-4q-7e-in
class type queuing c-4q-7e-drop-in
service-policy type queuing MODIFIED-4q-7e-drop-in
queue-limit percent 70
class type queuing c-4q-7e-ndrop-in
service-policy type queuing MODIFIED-4q-7e-ndrop-in
queue-limit percent 30
!

As you may notice, the ingress queue-limit allocation is not evenly balanced among the three drop queues—Q1, Q2/default, and Q3, as highlighted in Example These queue limits are 10 percent, 45 percent, and 45 percent, respectively, and are applied against the parent policy’s queue limit of 70 percent (for effective queue limits of 7 percent, 31.5 percent, and 31.5 percent, respectively).

Suppose that you to balance these queue limits more evenly. If so, you could make the policy changes shown.

! This section modifies the cloned ingress queuing policy
N7K(config)# policy-map type queuing MODIFIED-4q-7e-drop-in
N7K(config-pmap-que)# class type queuing 4q4t-7e-in-q1
N7K(config-pmap-c-que)# queue-limit percent 33
! Changes queue-limit for In-Q1 to 33% (of 70%) ≈ 23%
N7K(config-pmap-c-que)# class type queuing 4q4t-7e-in-q-default
N7K(config-pmap-c-que)# queue-limit percent 34
! Changes queue-limit for the default queue to 34% (of 70%) ≈ 24%
N7K(config-pmap-c-que)# class type queuing 4q4t-7e-in-q3
N7K(config-pmap-c-que)# queue-limit percent 33
! Changes queue-limit for In-Q3 to 33% (of 70%) ≈ 23%
!
N7K# show run | begin MODIFIED
policy-map type queuing MODIFIED-4q-7e-drop-in
class type queuing 4q4t-7e-in-q1
queue-limit percent 33
bandwidth percent 25
class type queuing 4q4t-7e-in-q-default
queue-limit percent 34
bandwidth percent 25
class type queuing 4q4t-7e-in-q3
queue-limit percent 33
bandwidth percent 25
!
policy-map type queuing MODIFIED-4q-7e-ndrop-in
class type queuing 4q4t-7e-in-q4
queue-limit percent 100
bandwidth percent 25
!
policy-map type queuing MODIFIED-4q-7e-in
class type queuing c-4q-7e-drop-in
service-policy type queuing MODIFIED-4q-7e-drop-in
queue-limit percent 70
class type queuing c-4q-7e-ndrop-in
service-policy type queuing MODIFIED-4q-7e-ndrop-in
queue-limit percent 30

Apply on interface:

N7K(config)# interface Ethernet3/44
N7K(config-if)# service-policy type queuing input MODIFIED-4q-7e-in
! Attaches the modified parent ingress queuing policy to the int(s)


Comment

    You are will be the first.

LEAVE A COMMENT

Please login here to comment.