DMVPN QOS Problem

[ric_nsgdata]

We are doing a proof-of concept for a DMVPN solution for an enterprise.

To start with we have configured only one HUB & one spoke.

DMVPN HUB-Spoke topology is deployed, with MGRE at HUB and GRE at Spoke.

We have used OSPF as the routing protocol within GRE.

Normal Encryption/Decryption is working with some anamolies.

Spoke CPE: 1841-secK9

SPoke IOS: Advanced Security K9 12.4 (3b)

Anamoly 1:

At spokes WAN-serial incoming interface i cannot see traffic more than 1-2 Kbps.

Where as at the same time, the tunnel input traffic is showing 60Kbps (thats the traffic i had generated).

Isnt it wierd to see trffic on the Tunnel interface whereas, the physical interface isnt showing any significant traffic.

For Traffic from Spoke to Hub (Output Traffic), the output traffic on Serial-WAN interface and the Tunnel Output is matching.

Is it an IOS bug?

Query 2: Is it possible to Mark the DSCP bits and perform QOS at the same time on the Tunnel or WAN Interface.

I have used qos-pre-classify command on the Tunnel Interface and applied the QOS policy on the WAN-Serial interface. Sample QOS Policy Applied:

policy-map COS-128K

class SILVER

set ip dscp af21

bandwidth 64

class class-default

set ip dscp default

fair-queue

My observations, that the there are not hits on the ACL which is reference by SILVER. even if configure then acl as any any.

Should i perform QOS Marking on the LAN Interface and CBWFQ on the WAN Interface with qos pre-classify on Tunnel Interface.

Has anybody sucessfully deployed QOS within DMVPN with QOS MArking on the Router. IF yes, can somebody share some sample configurations. THe DMVPN Design guide doesnt talk abt QOS Markings, it assumes that the packets are pre-marked.

Thanks in Advance...

[mheusinger]

Hello,

regarding QoS with tunnels: the new tunnel header will get a copy of the original IP DSCP settings. So in case you mark at input (or in another device before the router) this should be sufficient. "qos pre-classify" will keep a copy of the original header in memory to use it on the output interface regardless of the new header.

I am not too much a friend of access-lists in classification, because they are often to coarse, or not able to grab the traffic (f.e. FTP traffic).

Also be aware that you need CEF for proper operation.

Classification in this scenario could be done through DSCP markings or with NBAR (ok, or access-lists) and "qos pre-classify" on the output. In case this doesn´t work for whatever reason, you could also use qos-groups set on input interface for output classifications.

Regarding your "1 kbps traffic stats" problem: what is the real throughput? In case this is definately more than 1 kbps then I would consider it as a bug in the show commands. You could still post the observed facts for further investigation.

Hope this helps! Please rate all posts.

Regards, Martin