QoS DMVPN

[jspichalla]

Hello,

I?ve a DMVPN network with a hub and spoke model. The spokes have different bandwidth to the WAN. Now, I want implement a hierarchical CBWFQ concept. On the Hub Router (3845) is this configured:

ip access-list extended TEST

permit ip any 10.1.1.0 0.0.0.255

class-map match-any TELNET

match protocol telnet

class-map match-all TEST

match access-group name TEST

class-map match-any CITRIX

match protocol citrix

class-map match-all VOICE

match ip dscp ef

!

!

policy-map BRANCH

class TELNET

bandwidth percent 2

class CITRIX

bandwidth percent 40

class VOICE

priority percent 40

class class-default

fair-queue

random-detect

policy-map SHAPE

class TEST

shape average 1024000 640000

service-policy BRANCH

on the outside intefaces is configured "qos pre-classify" and "service-policy outside SHAPE".

When I start a telnet session to the branch (10.1.1.x), the output from show policy-map interface is in the attachment.

no packets are marked for telnet.

I don?t find the reason. I hope you can help me.

thanks

Jens

[bjornarsb]

Hi,

CBWFQ inside class-based shaping is not supported on a multipoint interface.

BR,

Bjornarsb

[mheusinger]

Hi,

where exactly do you configure "qos pre-classify"? Can you post the relevant portion of the config? It should be placed inside the crypto-map, Tunnel interface or virtual template. If it is not placed there, then the physical interface (GE) only "sees" encrypted traffic and thus no telnet can be detected.

Hope this helps!

Regards, Martin

[bjornarsb]

Your set-up is not supported.

However:

You can apply a service policy to either the tunnel interface or to the underlying physical interface. The decision of where to apply the policy depends on the QoS objectives. It also depends on which header you need to use for classification.

Apply the policy to the tunnel interface without qos-preclassify when you want to classify packets based on the pre-tunnel header.

Apply the policy to the physical interface without qos-preclassify when you want to classify packets based on the post-tunnel header. In addition, apply the policy to the physical interface when you want to shape or police all traffic belonging to a tunnel, and the physical interface supports several tunnels.

Apply the policy to a physical interface and enable qos-preclassify when you want to classify packets based on the pre-tunnel header.

HTH

Regards,

Bjornarsb

[mheusinger]

Hi Bjornarsb,

The output indicates, that the policy-map is applied to the physical interface. Nested policies are allowed there. So why do you assume the setup is not supported? The solution should in the end be the last case you mentioned.

Regards, Martin

[bjornarsb]

Hi,

I'm sorry I believed that the policy was applied to the tunnel inteface.

Then the case is that when you want to classify packets based on the pre-tunnel header. You need to enable qos-preclassify at the tunnel interface in addition to apply the policy to a physical interface

BR,

Bjornarsb

[nstrech]

Hey jspichalla, did you ever figure out your issue? I don't really see an answer here.

I believe I have the exact same issue. I have an 871 router at a remote office connecting back to HQ via a DMVPN connection. QOS Pre-Classify is enabled on my tunnel interface and a "show policy-map interface" shows that my traffic is being classified correctly, however my voice traffic class-maps showing 0 matches.

Class-map: AutoQoS-VoIP-RTP-Trust (match-any)

1940 packets, 356638 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: ip dscp ef (46)

1940 packets, 356638 bytes

30 second rate 0 bps

Queueing

Strict Priority

Output Queue: Conversation 72

Bandwidth 70 (%)

Bandwidth 700 (kbps) Burst 17500 (Bytes)

(pkts matched/bytes matched) 0/0

(total drops/bytes drops) 0/0

I've attached the other relevant parts of the config as a text file.

Thanks!

Nate Strech

SynClear Technology Group, Inc.

synclear.com

[mheusing]

Hi Nate,

This might not be an issue, but normal behaviour, as the config looks fine from what I can see. Queueing is only invoked, if an overload condition exists and only queued packets are counted. Given the small number of packets shown, I would assume there was no overload condition. Check the following document for a more detailed explanation:

"Understanding Packet Counters in show policy-map interface Output"

http://www.cisco.com/en/US/tech/tk543/tk760/technologies_tech_note09186a0080108e2d.shtml

Hope this helps!

Regards, Martin

[nstrech]

Oh - Well that clears things up. Thanks!

[nstrech]

Well it turns out I was still having an issue and figured I'd share the final solution.

Large amounts of packets were still slipping past the class-maps even though they matched. Removing "QOS Pre-Classify" from the Tunnel interface resolved the issue. You do not enable QOS Pre-Classify if your simply matching packets based on the ToS bit or the DSCP values since the VPN will copy this ToS bit to the newly encrypted packet. QOS Pre-Classify is only necessary when your marking packets based on header values such as source, destination, or port numbers, etc.

Nate Strech

SynClear Technology Group, Inc.

synclear.com