QOS doesn't match ACL

[fnbisson]

Hi,

I have two qos maps. The first one VOICE-DSCP 10 match dscp 46 and 48 and I see the matched packet correctly.

But I also need to priorize an entire subnet. So I create an extended ACL and create a new qos map VOICE-DSCP 20 but it seems that the packet doesn't match this map.

Below is my qos map and my extended ACL

qos map VOICE-DSCP 10

  match dscp 46

  match dscp 48

  priority 600

qos map VOICE-DSCP 20

  match list Securite

  priority 100     

Extended IP access list Securite

   permit ip 172.16.116.0 0.0.0.255  any    log (0 matches)

Can you help me to solve this ?

Thanks

*EDIT*:

I forgot to add the following to my interface vlan

ip access-group Securite in

ip access-group Securite out

But do I need to add permit ip any any to the extended ACL ?

[Anonymous]

:

Thank you for asking this question in the support community.  It appears, based on the information above, that the configuration may not be exactly correct.  Most likely, you should not have "access-groups" assigned to the VLAN interface for the purpose of QoS.  When you get a chance, if you reply with an attached copy of the configuration, I will be happy to review it for you and provide suggestions (please, remember to remove any information that may be sensitive to the organization).

Also, here is the Configuring QoS in AOS guide for reference.

Levi

[fnbisson]

Removed configuration and added it as an attachment.

Message was edited by: levi

[Anonymous]

- After reviewing your configuration, I do not believe you will see matches because the traffic will have been NATted before the QoS map is implemented as traffic leaves the WAN interface. Based on your configuration, your ACL is matching traffic being sourced from the 172.16.116.x network.However, by the time the QoS map checks the traffic, the traffic will have already been source NATted to the IP address of eth 0/2. That traffic will look like its being sourced from eth 0/2's IP address instead of the 172.16.116.x network, therefore the ACL will have no matches.

The way to get around this is to create an inbound QoS map on the LAN interface (eth 0/1) that matches traffic sourced from the 172.16.116.x network, and to then tag that traffic with an IP precedence or DSCP value. You could tag the traffic with the same DSCP value that you are already matching on in the QoS map VOICE-DSCP. However, if you would like for it to have a different priority, you could tag the traffic with another DSCP value or IP precedence value and then add another entry to the VOICE-DSCP map that matches based on that.

An example of the QoS setup I am referring to can be found in the guide below:

Configuring QoS in AOS

Specifically, you will want to reference the multi-tenant example (example #4) on page 45. However, instead of using the "shape average" command that is used in the example, you could use the "priority" command as you did with the first VOICE-DSCP qos map entry.

Please do not hesitate to let us know if you have any questions.

Thanks,

Noor

[Anonymous · Accepted solution]

-

I went ahead and flagged this post as “Assumed Answered.”  If any of the responses on this thread assisted you, please mark them as either Correct or Helpful answers with the applicable buttons.  This will make them visible and help other members of the community find solutions more easily.  If you still need assistance, I would be more than happy to continue working with you on this - just let me know in a reply.

Thanks,

Noor

[Anonymous]

I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post and unmark it and select another in its place with the applicable buttons.  If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

Thanks,

Noor