To answer your questions:
- RDP traffic should get up to the 25% of the remaining bandwidth. Where the already reserved bandwidth is the 35% ( class-default gets 25% by default and EF get 10% ). So, if i'm right, you assigned ~665Kbps to RDP. Anyway you should check if you're dropping packets issuing the command below:
show policy-map <your wan interface> output class REMOTEDESKTOP
and checking for dropped packets.
Cisco assign a queue to each user-defined class that includes the bandwidth or police commands. To make a long-story simple those commands define the amount of bandwidth assigned to every queue during congestions.
In theory every TCP based stream should be OK with drops. In practice some of them aren't. Dropping precedence bits tell the routers what packets should be dropped, within a given class, before congestion happens. Since RDP is the only type of traffic defined in your REMOTEDESKTOP class, you should not worry about it.
Bandwidth percentage are not in order ( as Jeremy stated ).
That said, there are a lot of things that i would change in your configuration:
There are no matches between some of classes of the setTos and the useTos policy-map. For instance the one named AF-HIGH is processing no packets since no class in setTos sets DSCP to AF41.
BE class in setTos is somehow self-defeating since it makes the class-default class useless. Note that class-default is the only system-defined class and get the 25% of the bandwidth by default ( 100 - max-reserved-bandwidth ) .
bandwidth remaining percent is not the best options ( as Jeremy explained ). I would change it to bandwidth percent.
I would prefer to mark EF packets by myself and not to rely on the phones' settings.
Your question's pretty broad. There's a lot of different commands you can use to troubleshoot and monitor QoS, so I'll focus on the primary question you have, which is how to reasonably verify your QoS configuration is working and how to read the policy-map interface output.
The only true way to verify that QoS is working is to hook up a traffic generator and monitor your drop rate in various queues. Since that isn't typically feasible, particularly in a production environment, all you can really do is verify that the traffic is being marked and classified properly.
What you're really looking for, when it comes to verifying if your QoS configuration is working, is for the counters in the policy-map interface command to increment.
So, for example, in the output your provided:
Class-map: VOICE (match-any)
3860628 packets, 1070196895 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol sip
97348 packets, 49867304 bytes
5 minute rate 0 bps
Match: protocol rtp
3763280 packets, 1020329591 bytes
5 minute rate 0 bps
Match: access-group name NEC-PBX
0 packets, 0 bytes
5 minute rate 0 bps
Priority: 40% (340 kbps), burst bytes 8500, b/w exceed drops: 5
You can see that you're seeing packets under SIP and RTP, but not NEC-PBX. If you know you're getting SIP and RTP traffic across a link, you should see the packet counts increment and that's a reasonable way to know that your configuration is basically working.
Best Answer
For Cisco IP phones, you've definitely got the right configuration:
Yes,
auto qos voip trustis required on both sides of any uplink for end-to-end QoS functionality (which is what you'd want, of course).There is no downtime associated with QoS settings. I have enabled qos (platform-wide, and on individual links) with no observable impact; even on links that were heavily utilized, there was no perceivable downtime for transit traffic.
For more info, you can reference Cisco's Auto QoS Whitepaper