[c-nsp] LLQ + MLPPPoE -> ?

[Ben Steele]

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: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman
Sent: Tuesday, 26 August 2008 11:20 PM
To: cisco-nsp at 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 at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/