[c-nsp] C836 ADSLoISDN DMVPN/QoS trouble

[Rodney Dunn]

shape average isn't supported in the parent policy when applied
to the PVC directly?

Show us the config.

>  - Inbound Marking with outbound policying does not work, since the
> "ToS-copying" feature is not available, too
 ?

You inbound mark and the TOS bits should be copied to the mGRE/IPSEC
header. I know there are limitations on some of those lower
end CPE's but I don't recall this being one of them.

Get a 'sh int dialer' stat and 'show int atm <blah>' stat.

Are you not CEF switching the traffic?


On Mon, Aug 20, 2007 at 09:07:54AM +0200, Dennis Breithaupt wrote:
> 
>  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  
>     
> _______________________________________________
> 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/