Switches - By Default Forwarding Behavior for QoS Marked Packets

[OBD]

Hello guys,

 I hope you are all good ! 

 I experienced very very strange behavior which is totally against my QoS knowledge. As far as I know Queueing methods and  cbwred is active when there is congestion .  And policing is drop packets based on the sla we configure.  But for the whole mechanism works, we need to implement service-policy, right ? 

 In my lab below , first I tried to performance test with udp packets from client to server and I  was reaching 300Mbps. But when I matched the udp packets and set it to the "dscp ef" in the access switch , my Iperf performance decreased to the 38Mbps . The interesting thing is I have no policy-map in the other switches and the only policy-map I am using is in the access switch (only the setting dscp ef nothing else).
  
  I tried to understand reason, and I saw the interface output drops in the switch was increasing dramatically and the "show platform qos queue stats gigabitEthernet x/x/x" was giving me tons of Drop-TH2 statistics.  Besides of it interface is 1Gig and there is no other traffic than my udp traffic. So there was no congestion. But somehow if the packet is DSCP EF , switch uses the limited capacity.  When I remove the "set dscp ef" my iperf performance peaked up to the 300Mbit again. 

 Is this behavior normal ? Because I supposed that , dscp markings only useful if you have some QoS policy in the  upward devices ?  I searched a lot in the cisco documentations and the google , but I could not find answer to this behavior .

  So if this behavior  is normal , there is no sense to set dscp ef for VoIP traffic in network which has sufficient bandwidth capacities. 

 

 

[Joseph W. Doherty]

QoS behaviors/defaults, vary between different Cisco devices, especially when dealing with switches.

This also includes whether, by default, a switch even has QoS enabled.

For example, I recall a 2960 has QoS disabled by default (the small switch norm until the 3650/3850 series).

Actual QoS capabilities also vary much between switch series.

The behavior you've noted likely due to a policer cap on PQ (I recall [?] uses a 4% default).

[OBD]

So does it means that  if there is no congestion , the packets are still put into the queue because of the priority ? 
Because I checked "show run all " as well , but still did not see any policer behind of the scenes.

[Joseph W. Doherty]

The ToS tag is used, by default, for egress queue selection.

What did the show run all show for the first queue config?

[Joseph W. Doherty]

Dang, you made me review 3850 QoS operation.  ;  )

This device doesn't have a default policer.  QoS on it depends on IOS version (including big fixes).

Suggest you review https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3850-series-switches/200594-Catalyst-3850-Troubleshooting-Output-dr.html and post additional questions, if needed.

[Joseph W. Doherty]

BTW, forgot to ask, your performance test was set for what transmission rate and using what frame/packet size?

[OBD]

Hello Joseph,
 
 Does it mean if even there is no congestion , priority queue comes into play ? Because in the documents it is said that queue only comes into play when there is congestion . So is it wrong ?  Because in my lab there was no congestion.

  Also  https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3850-series-switches/200594-Catalyst-3850-Troubleshooting-Output-dr.html was my first reference point when I experienced this issue. I have already implemented "qos queue-softmax-multiplier 1200"  as document said but it did not change anything.

 In the iperf , I set 300Mbit per second and 1400 MTU for udp packets.

[Joseph W. Doherty]

From everything you've posted, I believe you should NOT be seeing this issue.

If you have a support contract, I would suggest opening a TAC case.

Otherwise you might next try a bug search or perhaps change the IOS version to a newer/recommended version (if available).