first
about the WRR is related to port transmit and recieve queues
according to cisco SRND
Ingress congestion implies that the combined ingress rates of traffic exceed the switch fabric channel
speed, and thus would need to be queued simply to gain access to the switching fabric. On newer
platforms, such as the Catalyst 6500 Sup720, this means that a combined ingress rate of up to 40 Gbps
per slot would be required to create such an event.
However, to obviate such an extreme event, the Catalyst 6500 schedules ingress traffic through the
receive queues based on CoS values. In the default configuration, the scheduler assigns all traffic with
CoS 5 to the strict-priority queue (if present); in the absence of a strict priority queue, the scheduler
assigns all traffic to the standard queues. All other traffic is assigned to the standard queue(s) (with
higher CoS values being assigned preference over lower CoS values, wherever supported). Additionally,
if a port is configured to trust CoS, then the ingress scheduler implements CoS-value-based
receive-queue drop thresholds to avoid congestion in received traffic. Thus, even if the extremely
unlikely event of ingress congestion should occur, the default settings for the Catalyst 6500 linecard
receive queues are more than adequate to protect VoIP and network control traffic.
Therefore, the focus of this section is on Catalyst 6500 egress/transmit queuing design
recommendations.
There are currently six main transmit queuing/dropping options for Catalyst 6500 linecards:
• 2Q2T-Indicates two standard queues, each with two configurable tail-drop thresholds.
• 1P2Q1T-Indicates one strict-priority queue and two standard queues, each with one configurable
WRED-drop threshold (however, each standard queue also has one nonconfigurable tail-drop
threshold)
1P2Q2T-Indicates one strict-priority queue and two standard queues, each with two configurable
WRED-drop thresholds.
• 1P3Q1T-Indicates one strict-priority queue and three standard queues, each with one configurable
WRED-drop threshold (however, each standard queue also has one nonconfigurable tail-drop
threshold).
• 1P3Q8T-Indicates one strict-priority queue and three standard queues, each with eight
configurable WRED-drop thresholds (however, each standard queue also has one nonconfigurable
tail-drop threshold).
• 1P7Q8T-Indicates one strict-priority queue and seven standard queues, each with eight
configurable WRED-drop thresholds (on 1p7q8t ports, each standard queue also has one
nonconfigurable tail-drop threshold).
Almost all Catalyst 6500 linecards support a strict-priority queue and when supported, the switch
services traffic in the strict-priority transmit queue before servicing the standard queues. When the
switch is servicing a standard queue, after transmitting a packet, it checks for traffic in the strict-priority
queue. If the switch detects traffic in the strict-priority queue, it suspends its service of the standard
queue and completes service of all traffic in the strict-priority queue before returning to the standard
queue.
Additionally, Catalyst 6500 linecards implement CoS-value-based transmit-queue drop thresholds to
avoid congestion in transmitted traffic. WRED thresholds can also be defined on certain linecards, where
the CoS value of the packet (not the IP Precedence value, although they likely match) determines the
WRED weight.
in ur case why u dont apply it in the inbound direction?
u can apply ur policy like
corertr1(config-if)#service-policy input TNET-CORE-QOS
and the link u use is very good refrence
good luck
please, if helpful rate
