RE: Puzzling QoS Issue

From: Joseph L. Brunner <joe_at_affirmedsystems.com>
Date: Sat, 20 Apr 2013 01:19:43 +0000

Your carrier has a aggregate shaper applied or some other type of qos mechanism applied.

You're maxing it pal.

They probably did the wrong "BE" setting, etc.

:)

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Tony Singh
Sent: Friday, April 19, 2013 8:32 PM
To: Joe Astorino
Cc: Matt Bentley; Groupstudy
Subject: Re: Puzzling QoS Issue

yeh without further tests it's hard to say what the issue is, what's the uptime? is the code/license identical to your other working router ;)

--
BR
Tony
Sent from my iPhone on 3
On 20 Apr 2013, at 00:50, Joe Astorino <joeastorino1982_at_gmail.com> wrote:
> 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
Received on Sat Apr 20 2013 - 01:19:43 ART

This archive was generated by hypermail 2.2.0 : Wed May 01 2013 - 06:47:40 ART