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.netReceived 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