Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

QoS - how do you know there's congestion?

I understand with Cisco router QoS that the non-FIFO QoS configured with MQC is only engaged when the tx-ring tells IOS that there is congestion.

1) How can I tell if this is happening now? The show controllers command can tell you the size of the tx-ring but not if it's ever been full (which would trigger MQC QoS to engage)
2) How can I tell if tx-ring has indicated to IOS that there is congestion in the last hour?
3) The show policy-map <name> command tells you bps and other info for each class. Assuming there is traffic matching each class is it correct that the output of this command will show bps for each class even when tx-ring is not indicating to IOS that there is any congestion?

Thanks for any help, MH

Everyone's tags (1)
5 REPLIES
Super Bronze

DisclaimerThe Author of this

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

#1 If a packet is waiting to be transmitted (i.e. it's been queued), there's congestion (i.e. that's how you tell).

tx-ring being full doesn't indicate congestion, just indicates a degree of congestion (i.e. some number of packets queued).

#2 When tx-ring overflows, software queue(s) would show packets.  (NB: such overflow, also just indicates a degree of congestion.)

#3 Yes, I believe that's correct.  I.e. CBWFQ policy map's bps is counted for all matching traffic even when not queued in the class queue(s).

New Member

Thankyou Joseph Doherty ...

Thankyou Joseph Doherty ... you have come closest to answering my questions.

 

By what show command (and by looking at which part of the output) assuming no packets are being dropped, can I tell that the queues have non-zero depth.

Super Bronze

DisclaimerThe Author of this

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

On routers, a show interface, as one of its stats, usually displays the count of currently queued packets.

Cisco Employee

Hi Mark, To what link

Hi Mark,

 

To what link utilization state, you would refer as congestion. Say suppose there is 100 mbps link carrying more than 80mbps traffic, we can say it is congested. The other way of considering congestion is , whenever packets start getting queued, link is congested. But packet queuing may happen due to bursty traffic as well. Even with 10mbps traffic on 100mbps link, you may see packets getting queued. So may be for small time interval (few milliseconds) traffic rate on that link was more than 100mbps but per second rate is always well within limit. And since traffic coming from multiple interface, may go out via one uplink, it is normal to see packets queuing in output direction and that is why we have software queues (QOS) to handle bursty traffic (or extra traffic during that small interval).

 

Till the time we are seeing output drops and link traffic rate is below a threshold level, we can consider it not congested. To see in the last hour link was congested or not, you may refer link output drops or per class queue drops.

 

Regards,

Akash

 

Super Bronze

DisclaimerThe Author of this

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Akash raises two "common" ways that many network engineers consider links congested, which are passing some load average utilization threshold and/or seeing output drops.

In my experience, both can be misleading contrasted to considering congestion as simply when packets are queued (and as such, delayed or dropped).

The principle problem with load utilizations, they actually are a measure of some actual capacity utilization over the maximum possible capacity utilization over some measured time period.

First, consider 100 Mbps ingress, running at full rate to a 100 Mbps egress.  This would measure 100% utilization, but there's no additional queuing delay; but is the link congested?

Second, consider 1 Gbps ingress and 10 Mbps egress.  If the 1 Gbps only sends full rate for 1.5 seconds every 5 minutes, is the 10 Mbps egress congested?

The principal problem with queue drops, they depend on allocated queue resources versus the transmission burst pattern of the traffic.  For example, in the prior considerations, 100 Mbps ingress to 100 Mbps egress doesn't need any buffering, but Gbps ingress to 10 Mbps egress buffering will be very dependent on how the Gbps traffic arrives even though the long term transmission rates are the same.

671
Views
10
Helpful
5
Replies