[c-nsp] C836 ADSLoISDN DMVPN/QoS trouble

Dennis Breithaupt mail at dennisbreithaupt.de
Mon Aug 20 03:07:54 EDT 2007


 Hello all,  
 we're manageing a network with more then 1200 C836 ADSLoISDN routers
in a hub-and-spoke DMVPN (SLB, mGRE-tunnel at the hub, NHRP, tunnel
protection) construct.  
 Since we mostly have only routers with 48 MB working right now,
we're using the latest possible IOS 12.3(11)T11. Migration to 876
platform with a recent 12.4 IOS is on the move, but a long way to go.
  
 The QoS-features are quite limited in this setup, because of the
platform and the IOS:  
 - "shape average" is not supported   
 - Inbound Marking with outbound policying does not work, since the
"ToS-copying" feature is not available, too   
 So we're developing a QoS-concept consisting out of the following
components:  
 - ppp multilink with lfi (otherwise service-policy won't work; we're
also administrating the LNS-routers, so this setup works)   
 - service-policy with "qos pre-classify" in the dialer with priority
queue for "business critical" traffic, later maybe also capable of
carrying voice, if possible   
 - tx-ring-limit set to a small value (3) in the pvc according to
CCO-documentation  
 But things do not work, as expected, so I request any hints from
you! :)  
 - service-policy and business-critical classes do match in the
service-policy output and access-lists display  
 - ppp multilink seems also to work  
 but, when the upstream is fully loaded, we're experiencing bad
service-quality:  
 - "business critical" priority traffic has RTT's of 800 ms or more  

 - "sh queue atm0.1" shows 40 packets in the queue, while dialer- und
tunnel-queues are empty  
 I think, the main-problem is, that when the upstream gets high load,
because of the behaviour of DSL, RTT's are raising extremly. At the
moment there is no component in my setup limiting the traffic-flow,
as "shape average" would do. Normally and on bigger routers tested,
I'd limit the upstream to 80% of the physical possible value with
"shape average" and everything would be fine, but that is not
possible in this setup here.  <  >Of course, I could use a policyier
"police cir ", but that would only apply to the different classes
individually, but not a parent class as I would do with "shape". But
I definitivly want the background-traffic to fill the whole pipe,
when no business-traffic is available. (a.k.a. "dynamic shaping")
  > 
 I also experimented with different "vbr-nrt" values in the PVC, but
neither small nor maxed out values influenced my RTT's in a positive
way.  
 Has anyone experiences with a DMVPN-setup and a saturated upstream
on these small routers?  
 Has anyone active setups like that, even supporting voice? Any other
hints?  
 Is there any possibility to limit the upstream like "shape average"
to keep the RTT's responsive?  
 Thank you very much in advance,  
 Dennis  
    


More information about the cisco-nsp mailing list