@gjsnow wrote:
Am I supposed to set that somewhere/somehow?
Could be your network device, could be original source app or source device, could be network device in an AS upstream of your AS.
I understand this, kinda
I understand that packets with DSCP CS1 will be marked as SCAVENGER
What I am trying to understand is how do you put these markings/classifications on this traffic?
How does my policy map know, for instance, dscp ef is voice traffic? Where does voice traffic get that marking to begin with?
BTW, since you only showed a class-map, we can say that class, named SCAVENGER, will match against packets tagged with ToS CS1, but in an actual policy-map, that class-map might not be used or another class, prior to this class, might match CS1 packets too. I.e. you cannot assume any CS1 packet will be a "SCAVENGER" packet.
Also BTW, the Scavenger RFC is a very good idea, unfortunately, it breaks the prior/earlier IPPrec model, which the DSCP model attempts to maintain backward capability with. I.e. IPPrec 1 (CS1 [and AF1x]) is better than IPPrec 0 (BE), but with this RFC, it's the opposite.
"What I am trying to understand is how do you put these markings/classifications on this traffic?"
Answered in original reply, i.e. "Could be your network device, could be original source app or source device, could be network device in an AS upstream of your AS." Basically, from the source device to every L3 capable transit device, that can mark or remark packets to whatever they want.
On many Cisco devices, e.g.
class-map Sample
match protocol ftp
set ip dscp CS1
"How does my policy map know, for instance, dscp ef is voice traffic?"
Depends how you define "know".
A ToS tag, such a DSCP EF, is just a short cut, for quick identification of traffic, usually for QoS purposes. If you only want VoIP traffic to have DSCP EF tags, you would need to enforce that, because the tag doesn't. If you enforce it (correctly), then DSCP should be just VoIP traffic. But if you don't enforce it, any traffic would have a DSCP EF tag.
BTW, insuring specific traffic has specific DSCP tags, is where the concept of trust boundaries comes into play. As traffic crosses into a "trusted" (regarding validity of DSCP tags) part of the network, packets are verified to be tagged correctly.
"Where does voice traffic get that marking to begin with?"
Again, starting with the source device to any transit device that can ToS tag. Usually. VoIP phones will initially tags their packets, as desired, and ideally, the edge port device, verifies packets are tagged correctly. If not, packet tagging is changed.
I suspect you're looking for complexity that's not there.
If you're still confused, post more questions. Sometimes the obvious doesn't appear to be obvious, at least initially.
