@touristsis - It looks like you have set up 4 match criteria for traffic to prioritized. The QoS map will prioritize any traffic that has ANY of the following:
- DSCP value of 46
- DSCP value of 26
- RTP packets on even destination ports between 10020
- RTP packets on even and odd destination ports between 10020 and 10083
The fact that you are not seeing any packets matched tells me that there is no matching traffic going out the interface you have assigned the QoS map too. Keep in mind that your QoS map should be applied on the WAN interface of your AOS device in this scenario.
An input QoS map should not be required unless you need the router to mark traffic to be prioritized further down the pipe.
I would be more than happy to take a look at your configuration. Please remember to remove any information that may be sensitive to your company or network.
Yay! So I've found the problem. Actually Adtran Tech Support did. Qos on VPN will not work unless you tag the traffic for DSCP. All those packets were encrypted via VPN, that's the reason why the packet will not match.
What I had to do was create an extended access list. Tell it to tag certain traffic with DSCP value.
Step 1. In my case, I created and access list call VOIPTAG
Extended IP access list VOIPTAG
permit ip any host x.x.x.x (my destination ip address of the phone server).
Step 2. Then I created a QoS MAP
qos map VOIPTAG
map entry 10
match ACL VOIPTAG
set DSCP value to 46
Apply policy to the LAN interface.
qos-policy in VOIPTAG
So in a nutshell. Adtran Tag all traffic to the server with dscp value of 46. Now, Qos will work because the VPN encryption does not mess with dscp value. Hope that helps at least 1 other person.
Glad to hear you got this working! I just wanted to clarify a couple of things you mentioned in your post above.
DSCP and IP Precedence values are the only match criteria on a QoS map that is NOT encrypted when going over the VPN tunnel. Matching by any other criteria will not work as the VPN will encrypt that information. The following post discusses this subject as well:
Based on the fact that you had to create a QoS map to mark the traffic as it came inbound to the AOS device before the outbound QoS map matched it, tells me a couple of things. This usually points to the fact that traffic was either coming in tagged with a DSCP value OTHER than what you specified in your oubound QoS map or that the traffic was coming in not tagged at all. This is why, once you created an inbound QoS map to tag the incoming traffic with the correct DSCP value, you saw matches start to count up on your outbound QoS map.
Let us know if you have any further questions.
@touristsis - I marked this as "assumed answered," but if you have further questions on this topic do not hesitate to reply. I will be happy to help.