cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
376
Views
0
Helpful
4
Replies

QoS Policy not activating

Brian Green
Level 1
Level 1

I am having a problem getting a QoS policy to activate.

I have a 2921 ISR router with several VRFs defined on it, and several DMVPNs.  What I'm trying to do is enact QoS using a simple policy - I would think the place to apply it would be the router egress interface since that interface doesn't use VRFs or DMVPNs.  When I view the policy using "show policy-map interface" the number of packets in the class stay at 0.

 

I have an Extended Access List:

 

ip access-list extended name Test1_acl

 permit ip X.X.0.0 0.0.255.255 X.X.0.0 0.0.255.255

 

where X.X.0.0 is the subnet of nodes within one of the VRFs going to a destination over a DMVPN Tunnel.

 

And that connects to a Class Map:

 

class-map Test1_cm

 match access-group Test1_acl

 

which connects to a Policy Map:

 

policy-map Test1_pm

 class Test1_cm

  bandwidth percent 25

  set dscp af31

 

I've applied this to an interface:

 

interface GigabitEthernet0/2

 ip address Y.Y.224.1 255.255.255.0

 service-policy output Test1_pm

 

When I issue a ping from a workstation on the X.X.0.0 subnet, the packet (as I underdstand it) goes to the 2921 router, enters the DMVPN, then gets sent out on g0/2 - but the Source and Destination IPs are left unchanged.

 

What I am seeing when running an infinite png is all the packets go into the default class and none into Test1_cm.

 

Any ideas how I can make this work?

 

Thanks,

 

Brian

4 Replies 4

Joseph W. Doherty
Hall of Fame
Hall of Fame

You policy is on the physical egress interface?  If so, what IPs are you matching against, tunnel end-points, or pre-DMVPN source/destination IPs?

I managed to find a working solution - I created a simple policy map to apply the DSCP markings to the packet on its way IN to the router - so the QoS policy on the output interface can use that as the differentiator.  Not elegant, but (I think) it works.

 

Thanks!

 

Brian

Yes, that could be a solution because generally original packet's ToS byte is copied to the encapsulated header's ToS byte.

Otherwise, without using qos pre-classify (don't recall whether it works with DMVPN), egress interface QoS policies "see" the encapsulated header.

I was looking at some captured packets - the IPv4 Header had the DSCP field set properly once I changed it on the ingress interface.  So it does propogate it through.  I do have the "qos pre-classify" command set on all my VPN tunnels.

 

Brian

Review Cisco Networking products for a $25 gift card