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
As Alexander has already noted, it's possible to both mark and apply a QoS policy, on your 2921, toward the Internet.
However, toward the Internet, there isn't a need to mark the traffic, as the Internet doesn't generally honor any marking and you don't need to to manage any egress congestion.
Regarding what criteria to use, that depends on what you QoS goals are. You can give preference to VLAN 1 traffic over VLAN 2 traffic; the amount of preference could be from a slight bump to almost absolute right-of-way. You also can treat traffic differently based on application, alone or also considering the source VLAN.
Generally, I initially recommend fair-queue for all traffic (except real-time). You can later, further evolve a QoS policy, but FQ at least often insures that a bandwidth hog isn't adverse to other flows.
Lastly, with Internet, there's the problem of the QoS treatment for inbound traffic. Unfortunately, if you're unable to (QoS) manage the far side's egress (to you), you're very much impeded by how effective you ingress QoS might be.
Oh, and the type of documentation that Alexander recommended is very good, but it will probably recommend end-to-end and edge QoS. Nothing wrong with that, but having an effective QoS policy at your principle congestion point(s), alone, can be a very effective ROI.
