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: cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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; cisco-nsp@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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Freedman Sent: Thursday, 28 August 2008 12:13 AM To: cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LLQ + MLPPPoE - ?
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; cisco-nsp@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:[EMAIL PROTECTED] Sent: Thu 8/28/2008 01:26 To: David Freedman; cisco-nsp@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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Freedman Sent: Thursday, 28 August 2008 12:13 AM To: cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LLQ + MLPPPoE - ?
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:[EMAIL PROTECTED] Sent: Thursday, 28 August 2008 10:12 AM To: Ben Steele; cisco-nsp@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:[EMAIL PROTECTED] Sent: Thu 8/28/2008 01:26 To: David Freedman; cisco-nsp@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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Freedman Sent: Thursday, 28 August 2008 12:13 AM To: cisco-nsp@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
Re: [c-nsp] LLQ + MLPPPoE - ?
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. Dialer will default to interface mtu of 1500 bytes unless you specify something else. The config we are using is in the original post (https://puck.nether.net/pipermail/cisco-nsp/2008-August/053632.html) That doesn't have any of the previous recommendations i've made in it. 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? Haven't really played with the QoS on 12.4.20T much yet, but if you look back for the post with the subject [Improved queuing in 12.4(20)T?] from Per Carlson you can ask him what he was using J Let us all know if 12.4.20T does magic for you. Ben ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LLQ + MLPPPoE - ?
Dialer will default to interface mtu of 1500 bytes unless you specify something else. Sorry, to clarify, the dialer sits on top of an ATM interface which has a 4470byte MTU, from the ATM over G.SHDSL to the DSLAM, LAC, LNS and NAS there is an oversized MTU as well (2000), with the default dialer MTU of 1500 the maximum payload should leave at 1508B which is well below the MTU of all the network components end-to-end I dont believe this will cause any fragmentation? Haven't really played with the QoS on 12.4.20T much yet, but if you look back for the post with the subject [Improved queuing in 12.4(20)T?] from Per Carlson you can ask him what he was using J Let us all know if 12.4.20T does magic for you. I will try this, Thanks very much for your help, Dave. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] LLQ + MLPPPoE - ?
Have a scenario whereby I've an LLQ policy applied to a CE router doing MLPPPoE with following configuration: ! class-map match-any REALTIME match ip dscp ef class-map match-any CRITICAL-DATA match ip dscp cs6 ! ! policy-map LLQ class REALTIME priority percent 35 class CRITICAL-DATA bandwidth percent 40 random-detect dscp-based class class-default fair-queue random-detect dscp-based ! ! interface ATM0/0/0.132 point-to-point pvc 1/32 vbr-nrt 2304 2304 tx-ring-limit 3 encapsulation aal5snap service-policy output LLQ pppoe-client dial-pool-number 1 ! ! interface ATM0/1/0.132 point-to-point pvc 1/32 vbr-nrt 2304 2304 tx-ring-limit 3 encapsulation aal5snap service-policy output LLQ pppoe-client dial-pool-number 1 ! interface Dialer0 bandwidth 4608 ip address negotiated encapsulation ppp dialer pool 1 dialer idle-timeout 0 dialer-group 1 no cdp enable ppp authentication chap callin ppp chap hostname xx ppp chap password yy ppp ipcp route default ppp link reorders ppp multilink ppp multilink fragment disable max-reserved-bandwidth 100 service-policy output LLQ end So, the LLQ policy is only required to be applied to the VC and not the dialer, since I'm only queuing , but it is applied to both here. The ATM interface did indeed move to WFQ: #show queueing int atm0/0/0.132 Interface ATM0/0/0.132 VC 1/32 Queueing strategy: weighted fair Output queue: 0/512/64/0 (size/max total/threshold/drops) Conversations 0/6/128 (active/max active/max total) Reserved Conversations 1/1 (allocated/max allocated) Available Bandwidth 1 kilobits/sec But, the output of show policy-map int a0/0/0.132 does not show anything being pushed into the PQ at all #show policy-map int a0/0/0.132 | in Class-map|matched|default Class-map: REALTIME (match-any) (pkts matched/bytes matched) 0/0 Class-map: CRITICAL-DATA (match-any) (pkts matched/bytes matched) 0/0 default 0/0 0/0 0/0 20 40 1/10 Class-map: class-default (match-any) default 268/19832 0/0 0/0 20 40 1/10 #show policy-map int a0/1/0.132 | in Class-map|matched|default Class-map: REALTIME (match-any) (pkts matched/bytes matched) 0/0 Class-map: CRITICAL-DATA (match-any) (pkts matched/bytes matched) 0/0 default 0/0 0/0 0/0 20 40 1/10 Class-map: class-default (match-any) default 270/19980 0/0 0/0 20 40 1/10 ( I do see class matches, omitted here, but they do not appear to be queued) What is actually observed, is that the LLQ appears to work well until more than one member joins the bundle, then the latency + jitter becomes variable, but I'm not sure that it is even working at all since the queue counters do not increment, I could just be seeing the results of the WFQ. From the PE side, ppp multilink fragment disable and ppp link reorders are applied via RADIUS but I do not really believe they are having an effect since I'm still seeing re-order counters. (vtemplate clone applies the attributes, but assume they are being ignored) CE is 12.4(15)T7 and PE is 12.4(19) Am assuming that I'm doing this correctly as there should be no need for a shaper (not that it is accepted anyway) since we can create ATM backpressure from the ATM interfaces when I reduce the TX ring size. Any suggestions appreciated. Regards, David Freedman Group Network Engineering Claranet Limited http://www.clara.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 Also given you are running pppoe, you should be setting your MTU correctly (ip mtu 1492, if it's a 1500 byte path) and an ip tcp-adjust mss 1452 wouldn't do any harm either. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Freedman Sent: Tuesday, 26 August 2008 11:20 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] LLQ + MLPPPoE - ? Have a scenario whereby I've an LLQ policy applied to a CE router doing MLPPPoE with following configuration: ! class-map match-any REALTIME match ip dscp ef class-map match-any CRITICAL-DATA match ip dscp cs6 ! ! policy-map LLQ class REALTIME priority percent 35 class CRITICAL-DATA bandwidth percent 40 random-detect dscp-based class class-default fair-queue random-detect dscp-based ! ! interface ATM0/0/0.132 point-to-point pvc 1/32 vbr-nrt 2304 2304 tx-ring-limit 3 encapsulation aal5snap service-policy output LLQ pppoe-client dial-pool-number 1 ! ! interface ATM0/1/0.132 point-to-point pvc 1/32 vbr-nrt 2304 2304 tx-ring-limit 3 encapsulation aal5snap service-policy output LLQ pppoe-client dial-pool-number 1 ! interface Dialer0 bandwidth 4608 ip address negotiated encapsulation ppp dialer pool 1 dialer idle-timeout 0 dialer-group 1 no cdp enable ppp authentication chap callin ppp chap hostname xx ppp chap password yy ppp ipcp route default ppp link reorders ppp multilink ppp multilink fragment disable max-reserved-bandwidth 100 service-policy output LLQ end So, the LLQ policy is only required to be applied to the VC and not the dialer, since I'm only queuing , but it is applied to both here. The ATM interface did indeed move to WFQ: #show queueing int atm0/0/0.132 Interface ATM0/0/0.132 VC 1/32 Queueing strategy: weighted fair Output queue: 0/512/64/0 (size/max total/threshold/drops) Conversations 0/6/128 (active/max active/max total) Reserved Conversations 1/1 (allocated/max allocated) Available Bandwidth 1 kilobits/sec But, the output of show policy-map int a0/0/0.132 does not show anything being pushed into the PQ at all #show policy-map int a0/0/0.132 | in Class-map|matched|default Class-map: REALTIME (match-any) (pkts matched/bytes matched) 0/0 Class-map: CRITICAL-DATA (match-any) (pkts matched/bytes matched) 0/0 default 0/0 0/0 0/0 20 40 1/10 Class-map: class-default (match-any) default 268/19832 0/0 0/0 20 40 1/10 #show policy-map int a0/1/0.132 | in Class-map|matched|default Class-map: REALTIME (match-any) (pkts matched/bytes matched) 0/0 Class-map: CRITICAL-DATA (match-any) (pkts matched/bytes matched) 0/0 default 0/0 0/0 0/0 20 40 1/10 Class-map: class-default (match-any) default 270/19980 0/0 0/0 20 40 1/10 ( I do see class matches, omitted here, but they do not appear to be queued) What is actually observed, is that the LLQ appears to work well until more than one member joins the bundle, then the latency + jitter becomes variable, but I'm not sure that it is even working at all since the queue counters do not increment, I could just be seeing the results of the WFQ. From the PE side, ppp multilink fragment disable and ppp link reorders are applied via RADIUS but I do not really believe they are having an effect since I'm still seeing re-order counters. (vtemplate clone applies the attributes, but assume they are being ignored) CE is 12.4(15)T7 and PE is 12.4(19) Am assuming that I'm doing this correctly as there should be no need for a shaper (not that it is accepted anyway) since we can create ATM backpressure from the ATM interfaces when I reduce the TX ring size. Any suggestions appreciated. Regards, David Freedman Group Network Engineering Claranet Limited http://www.clara.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
