03-18-2009 02:41 AM - edited 03-06-2019 04:40 AM
Hi all,
Since last year I deployed the 'shape average BW' to fix the unexpected packet drop by Verizon's PE router. The BW is set to match the BW subscription with Verizon. Getting started the usage monitoring, I started seeing the OQD increasing daily but the Netflow reports the usage is below the max. Today I finally took the shaping away from one of the CE router and see if the packet loss becomes less. On the other hand, I started studying the effect of the parameters for the shaping command.
Below is the router configuration with Verizon link of 3Mbps.
class-map match-all critical
description critical apps
match any
policy-map QoS
class critical
shape average 3000000 12000 0
class class-default
interface GigabitEthernet0/1
description Verizon
no ip address
duplex full
speed 100
service-policy output QoS
interface GigabitEthernet0/1.8
description Verizon
encapsulation dot1Q 8
ip address x.x.x.x 255.255.255.252
ip flow ingress
ip flow egress
no snmp trap link-status
Initially I simply used 'shape average 3000000' and the OQD is large. Today I read some articles about the advanced QoS configuration, it's found that the byte limit is better to be multiple of 1500 (max MTU) and least sustain bit/int so as to get the minimum interval (Tc). Is it true?
Besides, I checked the network usage again by Netflow and found the usage is below the max. Unfortunately the OQD is not zero, as below, and that makes me puzzled.
GigabitEthernet0/1
Service-policy output: QoS
Class-map: critical (match-all)
668950 packets, 116032833 bytes
5 minute offered rate 150000 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
3000000/3000000 1500 12000 0 4 1500
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 668738 116009290 62896 35730671 no
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
*: interface is up
IHQ: pkts in input hold queue IQD: pkts dropped from input queue
OHQ: pkts in output hold queue OQD: pkts dropped from output queue
RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec)
TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec)
TRTL: throttle count
Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL
------------------------------------------------------------------------
* GigabitEthernet0/0 0 0 0 0 153000 119 181000 118 0
* GigabitEthernet0/1 0 0 0 213 185000 119 160000 121 0
* GigabitEthernet0/1.15 - - - - - - - - -
* Loopback0 0 0 0 0 0 0 0 0 0
NOTE:No separate counters are maintained for subinterfaces
Hence Details of subinterface are not shown
Please help/advise.
Thanks in advance.
Steven
03-18-2009 01:21 PM
Keep in mind when looking at stats like Netflow's, they might cover multiple minute averages for utilization, but things like queue depths, and queue overflows (drops), can occur at the millisecond level.
Your shapers's stats shows packets have been delayed, if they're delayed they're queued, if too many queued, you get drops. Again, all this can happen even though Netflow shows lower (average) utilization.
Adjustments to Tc, may impact drops, especially with such a large delta between the shaped rate of 3 Mbps and the interface rate of 100 Mbps.
Best value for Tc "depends". Allowing Cisco to default, is often a good starting point.
PS:
From what you've posted, you don't need to define an explict class. You could have just shaped the class-default.
Since you've mentioned Verizon and PE and Ethernet, see if you can obtain a copy of their document on Ethernet shaping.
03-19-2009 07:12 PM
Thanks Joseph for your explanation.
Is there any ways that I can use for monitoring traffic in 1 second or at ms level though I wonder if Cisco has features to give this out? Speed is really critical to us.
03-19-2009 08:08 PM
In answer to your question about monitoring traffic from 1 second down to milliseconds, you could try to poll various stats with short time intervals, but doing so to quickly may load the device down with processing the polls. Plus, I'm unsure you would obtain the benefit you need.
Cisco did incorporate Corvil Bandwidth analysis in some IOSs, that internally monitors traffic down at the ms level. Given some parameters for what your traffic must meet, it indicates the bandwidth needed. (There may be issues with this technolgy working correctly and it also requires a feature license, I belive.)
Since "Speed is really critical to us.", you might need to analyse the performance needs of your traffic, such as for bandwidth and latency, and then insure the network and hosts provide them.
Doing this can be both sometimes simple or complex. For instance, if you had some interactive application that needed to transfer 14 KB of traffic very quickly using TCP across a link with good bandwidth but high latency, a complex solution might have the application use 7 conconcurrent sessions that might allow the transfer to go 3x faster. A simple solution, might be a WAAS/WAFS appliance might deliver the same performance.
If you don't have this level of expertise internally, you might look to contract it.
03-19-2009 08:15 PM
Thanks Josephy again.
Fast monitoring vs high CPU loading is really an issue on our box. I may take a look at Corvil stuff to see if it's worth ;)
About the WAAS, it is too far away from us.
03-18-2009 02:15 PM
Typically you would only set such a low Tc when you have voice or video going across the link to avoid serialization delay (jitter). Your Tc is currently at 4ms which is unnecessarily low for plain data traffic. I believe the default is 125ms which allows your router to send more traffic per interval without having to wait for the next interval to begin. 125ms would give you a Tc of 375000.
03-19-2009 07:15 PM
Thanks izackvail.
The default Tc for me is 25ms, on all our routers.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide