[c-nsp] LLQ + MLPPPoE -> ?

Wed Aug 27 21:42:02 EDT 2008

>I would say it sounds like one interface is performing differently to the
>other(performance wise) but if it works fine when using the multilink
>interface that doesn't make as much sense, do you notice any drops or errors
>of any sort on the atm int's when you have the dialer configuration up? Also
>check the output of a "sh dsl int atmx" for each one to see if you are
>erroring there or syncing at different speeds or have a low noise margin on
>one etc..

They both perform fine on their own, only together does it cause a problem,
we dont see any drops, just big changes in latency 

>Out of curiosity did you set that ip mtu 1492 on your dialer when you were
>testing? As you would've been fragmenting otherwise trying to push 1500 byte
>over a 1500 byte link with pppoe

I believe in the setup we are testing with we have a >1500 mtu either end
so the pppoe overhead shouldn't be an issue, but will double check.

>Can you show me your exact config (minus passwords) that you are using when
>you are testing this including the output of a "sh dsl int atmx" for each
>int.

The config we are using is in the original post 
(https://puck.nether.net/pipermail/cisco-nsp/2008-August/053632.html)

There are no DSL errors recorded on the controllers, nor is there
anything remarkable in the sh int output:

#show int a0/0/0 | in rror|drop|throt|clear
  Last clearing of "show interface" counters 1d12h
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 output errors, 0 collisions, 0 interface resets

#show int a0/1/0 | in rror|drop|throt|clear
  Last clearing of "show interface" counters 1d12h
  Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 output errors, 0 collisions, 0 interface resets

>Another thought might be worth trying the new 12.4.20T IOS given it's QoS
>overhaul with HQF and the improved latency results shown by someone in an
>earlier thread.

This I will try, just out of interest, do you have such a setup in production?
if so , what version are you using on the CPE?

Dave.

From: David Freedman [mailto:david.freedman at uk.clara.net] 
Sent: Thursday, 28 August 2008 10:12 AM
To: Ben Steele; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] LLQ + MLPPPoE -> ?

Yes, it seems to be working when applied to the dialer (i.e , the class is
seeing traffic matched
and queued into the correct queue) but when the bundle contains more than
one member, the latency and jitter increases when there is congestion, which
leads me to think that either:

1. The queuing has stopped working
or
2. This is a side effect of having more than one member in the bundle in
this configuration.

We've taken all the usual precautions (i.e disabling LFI and permitting link
re-ordering on the bundle) but the quality still degrades under load when we
add another member.

Interestingly, when we create a multilink virtual interface (int mu1) and do
straight unauthenticated mlpppoa with the same LLQ policy, it works great.

------------------------------------------------
David Freedman
Group Network Engineering
Claranet Limited
http://www.clara.net

-----Original Message-----
From: Ben Steele [mailto:ben.steele at internode.on.net]
Sent: Thu 8/28/2008 01:26
To: David Freedman; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] LLQ + MLPPPoE -> ?

That example is using a virtual-template, not a dialer, there used to be an
issue some time ago where if you didn't run MLPPP on your dialer your
QoS(CBWFQ) wouldn't work properly as it required an MLP Bundle to attach to,
a work around for this was using virtual-template and ATM int for QoS.

If you are using MLPPP as it appears you are by your config, then all that's
needed in your ATM is to specify the correct service class (ie cbr/ubr/vbr)
and speed, the tx-ring-limit will make sure you don't buffer up any packets
in the ATM interface then all your magic should be done on the dialer with
your service-policy.

Make sure you set the bandwidth appropriately (ie subtract 15% for atm cell
tax overhead) and you should see it all come to life through your MLP
Bundle.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman
Sent: Thursday, 28 August 2008 12:13 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] LLQ + MLPPPoE -> ?

>Remove the service policy from your ATM int's and just leave it on your
>Dialer, then do a "sh users" and you should see an interface listed as the
>MLP Bundle, this is the one you want to be watching, if for example it is
>Vi4 then do a "sh policy-map int vi4"

I was following the advice at
http://www.cisco.com/en/US/tech/tk543/tk544/technologies_tech_note09186a0080
094ad2.shtml
which states:

". When you use a combination of Class-based Marking or Class- based
Policing and Class-based Queuing, the order of operations is this:

   1.

      The service-policy command configured on the Virtual-Template
interface marks or polices the packets.
   2.

      The service-policy command on the ATM PVC queues the packets
"

Is this not correct?

------------------------------------------------
David Freedman
Group Network Engineering
Claranet Limited
http://www.clara.net

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/