Re: Puzzling QoS Issue

CPU and memory seem to be OK. sh proc cpu shows it sitting about 7-10%
when the problem occurs. sh proc cpu history does not show any really bad
spikes. sho proc mem seems to show I have plenty of free RAM as well.

On Fri, Apr 19, 2013 at 7:43 PM, Joe Astorino <joeastorino1982_at_gmail.com>wrote:

> Sorry, 2GB of RAM is what it has
>
>
> On Fri, Apr 19, 2013 at 7:41 PM, Matt Bentley <mattdbentley_at_gmail.com>wrote:
>
>> Interesting. I've done testing with Spirent and other traffic-gen
>> platforms. I never saw shaping add to the latency - until I actually got
>> up close to the CIR - maybe slightly with a lower-end platform. But I
>> don't think shaping even activates until it senses backpressure and
>> activates "itself".
>>
>>
>> On Fri, Apr 19, 2013 at 4:17 PM, Tony Singh <mothafungla_at_gmail.com>wrote:
>>
>>> The reason why you get the extra delay when the policy is applied is
>>> down to the extra work the CPU has to do on top of inbound congestion,
>>> what's your memory/free?
>>>
>>> I would also raise a TAC to get the definitive answer "show
>>> tech-support" & pass to them
>>>
>>> --
>>> BR
>>>
>>> Sent from my iPhone on 3
>>>
>>> On 19 Apr 2013, at 23:13, Joe Astorino <joeastorino1982_at_gmail.com>
>>> wrote:
>>>
>>> > Another interesting fact - When the policy is applied as shown above,
>>> the
>>> > problem only occurs when the inbound RX is congested.
>>> >
>>> > So basically, if the service-policy is applied outbound towards the
>>> WAN as
>>> > shown, and the output utilization of the WAN link (TX) is low, and the
>>> > inbound (RX) utilization is low, everything is fine.
>>> >
>>> > In the event that the inbound utilization of the interface (RX) is
>>> > significant, and the policy is applied outbound as usual, the policy is
>>> > adding the 200-400ms extra delay. If I remove the policy, the extra
>>> delay
>>> > goes away.
>>> >
>>> > I guess I don't understand why inbound congestion would change how the
>>> > outbound queue / shaping works.
>>> >
>>> > input is low, output is low, policy applied: fine
>>> > input is high, output is low, policy not applied: expected poor
>>> response
>>> > times
>>> > input is high, output is low, policy is applied: expected poor response
>>> > time PLUS an additional 200-400ms of delay
>>> >
>>> >
>>> > On Fri, Apr 19, 2013 at 5:49 PM, Joe Astorino <
>>> joeastorino1982_at_gmail.com>wrote:
>>> >
>>> >> I have a 3945 ISR router connected via a GigabitEthernet link to a
>>> service
>>> >> provider that is providing 10Mbps WAN access. I wish to use CBWFQ
>>> and the
>>> >> service provider requires dot1q tagging. As such, I must shape my
>>> >> sub-interface and use a hierarchical type QoS policy...no big deal
>>> >>
>>> >> policy-map WAN-EDGE
>>> >> class VOICE
>>> >> priority percent 20
>>> >> !
>>> >> class VIDEO
>>> >> bandwidth remaining percent 60
>>> >> queue-limit 128 packets
>>> >> !
>>> >> class APPS_SIGNALING
>>> >> set dscp af21
>>> >> bandwidth remaining percent 30
>>> >> !
>>> >> class class-default
>>> >> bandwidth remaining percent 10
>>> >> !
>>> >> !
>>> >> policy-map SHAPE-OUT
>>> >> class class-default
>>> >> shape average 10000000
>>> >> service-policy WAN-EDGE
>>> >> !
>>> >> !
>>> >> int gi0/1.2
>>> >> encapsulation dot1q 2
>>> >> ip address ...
>>> >> service-policy output SHAPE-OUT
>>> >>
>>> >>
>>> >> Here is the very strange thing. Even when the TX of this WAN
>>> interface is
>>> >> barely being used, when and only when the service-policy is applied,
>>> the
>>> >> response in pings to anything behind this router increase immediately
>>> by
>>> >> 200-400ms. Immediately after removing the service-policy things
>>> return to
>>> >> normal.
>>> >>
>>> >> Investigating the output of "show policy-map interface" reveals a
>>> large
>>> >> number of output drops in the shaper class-default. So far I have
>>> tried
>>> >>
>>> >> - increasing the queue-limit to many different combinations
>>> >> - increasing the burst size
>>> >>
>>> >> I also have the exact same configuration on another remote site router
>>> >> running the same version of IOS with the same setup (10Mbps Ethernet
>>> WAN
>>> >> link) on the same platform.
>>> >>
>>> >> I'm really baffled as to what would cause this. Any insight
>>> appreciated.
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Regards,
>>> >>
>>> >> Joe Astorino
>>> >> CCIE #24347
>>> >> http://astorinonetworks.com
>>> >>
>>> >> "He not busy being born is busy dying" - Dylan
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Regards,
>>> >
>>> > Joe Astorino
>>> > CCIE #24347
>>> > http://astorinonetworks.com
>>> >
>>> > "He not busy being born is busy dying" - Dylan
>>> >
>>> >
>>> > Blogs and organic groups at http://www.ccie.net
>>> >
>>> > _______________________________________________________________________
>>> > Subscription information may be found at:
>>> > http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
> Regards,
>
> Joe Astorino
> CCIE #24347
> http://astorinonetworks.com
>
> "He not busy being born is busy dying" - Dylan
>

-- 
Regards,
Joe Astorino
CCIE #24347
http://astorinonetworks.com
"He not busy being born is busy dying" - Dylan
Blogs and organic groups at http://www.ccie.net