05-21-2007 06:53 AM - edited 03-03-2019 05:04 PM
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
05-22-2007 10:51 PM
Hi,
CBWFQ inside class-based shaping is not supported on a multipoint interface.
BR,
Bjornarsb
05-22-2007 11:12 PM
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
05-22-2007 11:21 PM
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
05-22-2007 11:38 PM
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
05-23-2007 12:08 AM
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
06-27-2007 07:00 AM
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
06-27-2007 07:22 AM
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
06-27-2007 07:31 AM
Oh - Well that clears things up. Thanks!
06-28-2007 05:28 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide