Question regarding output of traffic shaping

Unanswered Question
Mar 18th, 2009
User Badges:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.3 (3 ratings)
Loading.
Joseph W. Doherty Wed, 03/18/2009 - 13:21
User Badges:
  • Super Bronze, 10000 points or more

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.

wongtungho Thu, 03/19/2009 - 19:12
User Badges:

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.

Joseph W. Doherty Thu, 03/19/2009 - 20:08
User Badges:
  • Super Bronze, 10000 points or more

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.

wongtungho Thu, 03/19/2009 - 20:15
User Badges:

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.

izackvail Wed, 03/18/2009 - 14:15
User Badges:
  • Bronze, 100 points or more

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.

wongtungho Thu, 03/19/2009 - 19:15
User Badges:

Thanks izackvail.


The default Tc for me is 25ms, on all our routers.

Actions

This Discussion