[c-nsp] LLQ + MLPPPoE -> ?

[Ben Steele]

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

 

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

 

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.

 

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.

 

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/