Re: Puzzling QoS Issue

From: Tony Singh <mothafungla_at_gmail.com>
Date: Sat, 20 Apr 2013 03:44:25 +0100

Joe may be onto something there

For example some of Verizons policies where they use a local carrier they have to account for a 20 byte padding doing nothing in the Ethernet frame as a result reduce your cir by a certain percentage

But I think in this case he applies the policy then gets the drop, without is ok

--
BR
Sent from my iPhone on 3
On 20 Apr 2013, at 03:36, "Joseph L. Brunner" <joe_at_affirmedsystems.com> wrote:
> We can only speculate until you get the right person on the phone;
> 
> But if you remove the shaper and run the line hard - when do the pings get to 200-400ms?
> 
> Here's a better question - why does the carrier REQUIRE 802.1q tags? 
> 
> Sounds again like youre not talking to the right person...
> 
> That's a highly irregular config...
> 
> What if you didn't have a router capable of 802.1q tagging? 
> 
> Would they let you out of your contract?
> 
> LOL
> 
> My policy has all routers at the edge with routed interfaces - wouldn't I just ignore the tag if they put the ip on a vlan int. without tagging?
> 
> There is more to this we have to dig into...
> 
> I think the tags are effecting something - just got to find out where...
> 
> -----Original Message-----
> From: Joe Astorino [mailto:joeastorino1982_at_gmail.com] 
> Sent: Friday, April 19, 2013 10:33 PM
> To: Joseph L. Brunner
> Cc: Tony Singh; Matt Bentley; Groupstudy
> Subject: Re: Puzzling QoS Issue
> 
> Joseph,
> 
> If it was a carrier shaping/policing issue though, why does removing the shaper on my end resolve the issue
> 
> Sent from my iPad
> 
> On Apr 19, 2013, at 9:20 PM, "Joseph L. Brunner"
> <joe_at_affirmedsystems.com> wrote:
> 
>> 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
>> 
>> ______________________________________________________________________
>> _ Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Sat Apr 20 2013 - 03:44:25 ART

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