Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Ideally, you want to only examine traffic as it enters your network and also, ideally, the source of the traffic should mark itself.
When the source of the traffic marks itself, you may (should) verify the marking is deserved. For example, packets from a VoIP phone would be expected to have your desired VoIP markings (e.g. DSCP EF for VoIP bearer), but packets from a file server would not be expected to have these markings.
You can verify markings by additional examination of the packet (i.e. does it look like the kind of packet such a packet should be) and/or verify it's bandwidth usage (e.g. VoIP bearer packets, per flow, shouldn't exceed about 128 Kbps).
If devices are incapable of self-marking and/or you can't verify the source of the traffic, then you can resort to the type of examination like you ACL. Unfortunately, ACLs often only support rudimentary analysis and to insure you get all the packets intended, you might incorrectly mark other traffic.
On Cisco routers, that support NBAR, or Cisco switches that support FPM, "better" packet examination might be done. (Note some proxies and firewalls can also perform "better" packet examination, but they might not want to remark the ToS.)
