Re: Puzzling QoS Issue

1) not yet

2) we ordered and paid for 10Mbps MPLS link with Ethernet handoff. I did
try different shaper values as well like 8 and 9 Mbps just to test and same
results

3) The line rate is actually hard set to 10/full and that is the only
combination that results in up/up. Getting rid of the shaper logically
makes sense as there is no need to shape to line rate - however , I wish to
use CBWFQ and traffic must be tagged. Therefore, shaping at the parent
level is a requirement, as you can't apply queuing on an Ethernet
subinterface otherwise

Sent from my iPhone

On Apr 19, 2013, at 10:18 PM, Adam Booth <adam.booth_at_gmail.com> wrote:

Hi Joe,

Here are some random thoughts without a lot of methodology...

1) I don't know if tweaking tx-ring-limit is of any help in this situation
but have you looked at it? Adjusting it down can be helpful in reducing
jitter.

2) Have you clarified what the SP means by 100Mbps is it at L2 (including
VLAN tag) or L3, what about MBS values? You may need to drop your egress
shaper down, try 90% of that value first and see if its more in alignment

3) This doesn't necessarily identify and resolve the issue but if the
importance is getting services working ahead of finding the root cause, are
you sharing other services on that interface? If not, could you ask your
SP to just set the interface to operate at 10Mbps assuming it's a copper
port and drop the shaping component?

Cheers,
Adam

On Sat, Apr 20, 2013 at 7:49 AM, 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
>
>
> 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 Fri Apr 19 2013 - 22:25:07 ART