If there is still possibility to do something better I try ;).

Here you are version 3 of QoS Values Calculator.

I have added applications description and DSCP 0.

Do you think that something is still missing? ūüôā

QoS Values Calculator v3 in PDF format here.

, , , ,

Here you are our most popular NetContractor’s post about QoS fields mystery.

QoS Classification is done mainly based on¬†two fields: in¬†Ethernet it’s CoS¬†field¬†and¬†in IP header it’s ToS. Naming convention for specific fields in IP header has developed over years from the CS and IPP to DSCP. The main reason for that was¬†not enough naming class to¬†classify traffic. BTW, today¬†once we¬†classify traffic and would send it¬†over provider’s MPLS cloud we have to properly map our classes to provider classes to take advantage from the¬†QoS features that have been purchased. What is interesting that MPLS frame uses¬† 3-bits long EXP field that can only address up tp 8 classes of traffic so marking more classes (from the client perspective)¬†have no sense when we would push it over MPLS.

But let’s back to the naming. Due to demand for more classes naming has changed. At the begining just first¬†3 bits of 8-bits ToS was used to name and mark traffic, it would be enough even until now. Then QoS fetures and class naming has changed¬†due to fast grow¬†of VoIP.¬†QoS¬†has been popular and key significant to achieve better voice quality. Engineers tried to involve more bits to mark more classes. Finally we have still 8-bits long ToS field with few class¬†names depends on what part of the field we take. ¬†For someone that is just starting with QoS it maybe confusing so I thought to share with you the QoS Values Calculator that I¬†have created and used during my CCIE study.

I’ve added ToS in HEX to the QoS Values Calculator v2¬†. These values are useful when you would like to generate IP traffic with specific ToS/DSCP value by ping command from the IOS CLI. Ping with ToS is very helpful during QoS configuration test. You can easily generate¬†test ICMP traffic with specific value in ToS field¬† and see if it matches rigth QoS class.

Be aware that during extended ping from IOS CLI, TOS HEX value has to be defined in the 0xHH format where HH is HEX value.

To be honest this is the most popular post of this blog.

Please take a look, any feedbacks are more then welcome. Enjoy.

QoS Values Calculator v3 in PDF format here.

, , , ,

Is it a issue to achive proper QoS for IP tunneled traffic over GRE encrypted by IPsec tunnel – for Cisco router is not the case. With use of GRE/IPsec ToS byte is copied from the original IP header to the new GRE and IPsec IP headers. It’s done by default without any specific configuration, this process is called the “ToS Byte Preservation” feature.
For example if router gets IP packet with DSCP value equal to 46 then packet is encapsulated in to GRE header, ToS byte is copied to the GRE IP header ToS field. In case this GRE packet is subject to IPsec encryption the same process occurs and ToS byte from GRE headers is copied into IPsec IP header – all is done by automatically. But what if QoS policy would classify and do action based on original source IP and specific TCP or UDP port. Solution is the QoS pre-classify feature. It allows router to temporarily copy and store the layer 3 and 4 headers from the original IP packet and take action based on these values so classify, queue and schedule on the router’s egress interface accordingly.

To achive above QoS feature have to be enabled both under GRE tunnel and IPsec crypto map as follows:
Router(config)#int tun 0
Router(config-if)#qos pre-classify
Router(config)#crypto map MAPA 100 ipsec-isakmp
Router(config-crypto-map)#qos pre-classify

Now you are ready to go with class-map and policy-map. Remember that in this case policy needs to be assigned to physical interface where crypto map is configured already.

, , , , , ,

By default Cisco Catalyst switch does not take into account any bit from the Layer 2 CoS or Layer 3 ToS field. Does it mean that packets will be transmited in the original for and CoS/ToS fiels will be untouched.
Once we enable quality of service (QoS) for the entire switch using:
SW(config)#mls qosQoS will be enabled with the default parameters on all ports in the system. What it means that switch by default will remark CoS and ToS values to default 0 (zero).
Once we enable trusting under interface then system will analyze CoS and ToS fields. We have two options; trusting CoS or ToS (DSCP). If you would learn more about the QoS language take a look on this post.

Below you can find some examples and clarifications about sepcific options:

Trusting CoS
SW(config-if)#mls qos trust cos

  • Switch gets packet with CoS=5
  • Switch will pass¬†through¬†CoS¬†value¬†untouch, but¬†DSCP¬†will be rewritten based on the map table (by default CoS 5¬†will set DSCP to 46)
  • Conclustion:¬†DSCP value¬†is set based on the¬†mls qos map cos-dscp

Trusting DSCP
SW(config-if)#mls qos trust dscp

  • Switch gets packet with CoS=4 and¬†DSCP=46
  • Switch will pass through DSCP value untouch but CoS will be rewritten based on the map table (by default¬†DSCP will rewrite CoS to 5¬†)
  • Conclusion:¬†CoS value¬†is set based on the mls qos map dscp-cos

Assigning CoS to port
SW(config-if)#mls qos cos 5

  • Switch gets packet on CoS untrusted port without QoS field, so it’s kind of¬†untagged frame without¬†802.1p field(like in case of native VLAN)
  • Switch sets¬†default CoS value that is assigned to the port, in this case CoS 5 (by¬†default is 0). Marked value (CoS¬†5)¬†later on¬†is used¬†to¬†mark¬†DSCP based on the mls qos map cos-dscp.
  • Conclusion:¬†CoS value¬†is set for all non capable¬†802.1p tag (layer 2 QoS field) frames

CoS overriding
SW(config-if)#mls qos cos 5
SW(config-if)#mls qos cos override

  • Switch gets tagged frame with CoS value of 4
  • Switch will tag frame with CoS value of 5 then it’s used to mark DSCP base on the mls qos map cos-dscp.
  • Conclusion: switch sets CoS for all frames even if they have CoS value already assigned to¬†(base on the value in mls qos cos x)

Trusting DSCP just from Cisco IP Phone
SW(config-if)#mls qos trust dscp
SW(config-if)#mls qos trust device cisco-phone

  • Switch has Cisco IP Phone connected (phone’s visible over CDP) that sends frames with DSCP=46
  • Switch will pass¬†through¬†DSCP value untouch,¬†CoS will be marked based on the mls qos map dscp-cos
  • Conclusion: trusting DSCP value only when a Cisco Phone is connected and reported via CDP on the respective interface; works in conjunction with the mls qos trust dscp and mls qos trust cos commands

Here you are QoS settings for not connected port (base on the above configuration):
SW#sh mls qos interface gi1/0/1
trust state: not trusted
trust mode: trust dscp
trust enabled flag: dis
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: cisco-phone
qos mode: port-based

And here you are QoS settings output once we connected Cisco IP Phone to the port:
SW#sh mls qos interface gi1/0/1
trust state: trusted
trust mode: trust dscp
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: cisco-phone
qos mode: port-based

as you can notice enabled flag field has changed to ena (enabled) and trust state changed to trusted state, so port is ready to trust DSCP.

No DSCP/IPP to CoS rewriting (3550 only)
SW(config-if)#mls qos trust dscp pass-through cos

  • Switch gets packet¬†with DSCP=46 and CoS=0
  • Switch will pass¬†through¬†DSCP and CoS value¬†untouch, so¬†DSCP=46 and¬†CoS=0
  • Conclustion: switch does not¬†remark¬†CoS value

No CoS to DSCP rewrite (2960, 3560, 3750 only)
SW(config)#no mls qos rewrite ip dscp
SW#show mls qos
QoS is enabled
QoS ip packet dscp rewrite is disabled

  • Switch gets packet with DSCP=46
  • Switch will pass through DSCP value untouch
  • Conclustion:¬†CoS will be trusted, DSCP will be preserved, switch does not¬†modify¬†DSCP value, leave it default as it is in the outgoing packet

Matching traffic with specific DSCP value in ACL (VLAN-Based) SW(config)#interface FastEthernet 1/1
SW(config-if)#switchport access vlan 100
SW(config-if)#switchport voice vlan 110
SW(config-if)#spanning-tree portfast
SW(config-if)#mls qos vlan-based
SW(config-if)#srr-queue bandwidth shape 10 0 0 0
SW(config-if)#srr-queue bandwidth share 10 30 40 20
SW(config-if)#queue-set 1
SW(config-if)#priority-queue out
SW(config-if)#ip access-list extended RTP
SW(config-ext-nacl)#permit udp any any range 16384 32767 dscp 46
SW(config-ext-nacl)#class-map match-any VOICE
SW(config-cmap)#match access-group name RTP
SW(config-cmap)#policy-map POLICY-VOICE
SW(config-cmap)#class VOICE
SW(config-pmap-c)#set dscp af31
SW(config-pmap-c)#interface vlan 110
SW(config-if)#service-policy input POLICY-VOICE

  • Switch gets packet¬†with DSCP=46 and CoS=0
  • Switch will set¬†DSCP to 26 and CoS value¬†based the mls qos map dscp-cos map table
  • Conclustion: mls qos vlan-based overrides QoS interfaces level trusting seetings, port will not clear the CoS/DSCP field even that we don’t have trusting under policy, CoS/DSCP will be preserve and can be match by class-map
  • If you have more or better example please share with us under comments. Enjoy!

    , ,