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:[EMAIL PROTECTED] Sent: Thursday, 28 August 2008 10:12 AM To: Ben Steele; [email protected] 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:[EMAIL PROTECTED] Sent: Thu 8/28/2008 01:26 To: David Freedman; [email protected] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Freedman Sent: Thursday, 28 August 2008 12:13 AM To: [email protected] 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 [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
