Re: Puzzling QoS Issue

Hey guys, thanks for the responses thusfar.

Matt -- I did indeed try removing the child from the parent, re-applying
etc with no results. I even tried a test nested policy that just contained
the shaper in the parent policy and no CBWFQ at all in the child (just
class class-default) and had the same issues. I actually did not look at
CPU yet, but will do that tomorrow

Tony - Code is 15.2(4)M2. The router is maxed out with 4GB of RAM.
Resource wise, this router is overkill for the site. I mean we are talking
about a site with 10Mbps WAN link, maybe a few hundred users at most, most
of which is terminal stuff (it's a distribution warehouse). The point is,
throughput should not be an issue really.

I will check CPU for sure and see what I can find.

On Fri, Apr 19, 2013 at 7: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
> >
> >
> >
> >
> >
> >
> >
>

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