cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
573
Views
1
Helpful
5
Replies

QoS Question - Scavenger class and others

gjsnow
Level 1
Level 1

class-map match-all SCAVENGER

match ip dscp cs1

 

Assuming I have a policy map and service policy applying QoS to switchports and interfaces between routers etc.

How does the device know what "SCAVENGER" traffic is? Its a variable term with no meaning. I am assuming it matches based off the DSCP value. How does the device know the DSCP value of this traffic? Am I supposed to set that somewhere/somehow? 

Am I missing something?

1 Accepted Solution

Accepted Solutions


@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.

View solution in original post

5 Replies 5

Joseph W. Doherty
Hall of Fame
Hall of Fame

How does the device know what "SCAVENGER" traffic is?

class-map match-all SCAVENGER

match ip dscp cs1

I.e. any packet passing through a service policy, with the above class, assuming another class in the same policy doesn't match the packet first. (NB: As your class map just matches, it could be used in an ingress or egress service policy implementation.

How does the device know the DSCP value of this traffic?

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus1000/sw/4_0/qos/configuration/guide/nexus1000v_qos/qos_6dscp_val.pdf

cs1 = DSCP 8 (decimal)  (NB: first six bits of the ToS octet.)

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.

How does the device know what "SCAVENGER" traffic is?

class-map match-all SCAVENGER

match ip dscp cs1

I.e. any packet passing through a service policy, with the above class, assuming another class in the same policy doesn't match the packet first. (NB: As your class map just matches, it could be used in an ingress or egress service policy implementation.

I understand this

How does the device know the DSCP value of this traffic?

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus1000/sw/4_0/qos/configuration/guide/nexus1000v_qos/qos_6dscp_val.pdf

cs1 = DSCP 8 (decimal)  (NB: first six bits of the ToS octet.)

I understand this

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?


@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.

"I suspect you're looking for complexity that's not there."

Well phrased and I usually am.

I guess I just want to know how to make sure the right traffic has the right tags. 

 

This helped clear a lot up.

class-map Sample
 match protocol ftp
 set ip dscp CS1

I also read you can set by IPs/VLANs for trusted traffic via ACL. What are the best practices assuming the entire environment is Cisco.

I also don't have control/access of/to the CUCM and it appears the DSCP values are not set for voice or video traffic. How can I verify the values being presented?

I am going to test some VTCs as I can get to there GUI and see that they have QoS information available to be set.

If it sounds like too much "hand holding" I will keep working it based on the info provided above.

Thanks

 


@gjsnow wrote:

I guess I just want to know how to make sure the right traffic has the right tags. 


Again, that's what often happens at the "trust" boundary.  It's not always simple, nor, somewhat surprisingly, does it always need to be done.

Years ago, read a suggestion, that was very handy.  It suggested, if your trust boundary was as the host port edge, and you want to insure DSCP EF wasn't being use for non-voice traffic, rather than doing complicated analysis whether incoming traffic was, in fact, voice traffic, just police DSCP EF to the acceptable voice needed bit rate, which even for G.711, is only about 100 Kbps.

I.e. if someone sends into that port, FTP traffic, that traffic will be limited to 100 Kbps, which your network can well handle, assuming it was prepared to handle that much for VoIP.  And if, same port tried to send, concurrently, 100 Kbps of VoIP traffic, sender's FTP traffic would ruin their VoIP call.  Gee, too bad, but why is host sending FTP traffic with DSCP EF?  Suggest host stop doing that.  ; )


@gjsnow wrote:

I also read you can set by IPs/VLANs for trusted traffic via ACL. What are the best practices assuming the entire environment is Cisco.


Oh, yeah, often you can create very complicated packet analysis, especially if you have NBAR support.  You can also infer things on edge ports either assuming what the "authorized" host should be, or by perhaps CDP/LLDP identification, etc.

Best practice is you do whatever you need to do to insure QoS works as you desire.  Ideally, you like to get the trust boundary as near to the source of the packets as possible.  Even the source might be the trust boundary.  E.g. a VoIP phone that flips itself to a voice VLAN and generates CDP packets announcing it's a VoIP phone.


@gjsnow wrote:

I also don't have control/access of/to the CUCM and it appears the DSCP values are not set for voice or video traffic. How can I verify the values being presented?


Various ways to accomplish that, often dependent on platform capabilities.  For example, you might use an ingress service policy that class matches on different DSCP markings, and look as the stats.  On switches, some will implicitly count packets against packet ToS markings.  Some platforms supported embedded packet captures,  Or, you might you an ACL to permit packets, but matching specific ToS markings and look as ACL's ACEs match counts.

Review Cisco Networking for a $25 gift card