[c-nsp] LLQ + MLPPPoE -> ?

[David Freedman]

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