Help decoding a QoS config

[poulid]

Hey everyone. We're experiencing some Skype performance issues, and I'm attempting to decode some QoS stats on the 3850 switch that connects the Skype server to the network. I'm seeing what looks like a ton of drops on the interface that connects the server, and I'm wondering if this is the root of the problem;

show policy-map interface gi 3/0/46

 GigabitEthernet3/0/46

  Service-policy input: PM-QOS-MARKING-V2

      Class-map: CM-QOS-EF-LYNC-CLIENT-AUDIO (match-any)

      63016338 packets

      Match: access-group name ACL-QOS-LYNC-CLIENT-AUDIO

        0 packets, 0 bytes

        5 minute rate 0 bps

      QoS Set

        ip dscp ef

      police:

          cir 1000000 bps, bc 31250 bytes

        conformed 20282017987 bytes; actions:

          transmit

        exceeded 1038009960 bytes; actions:

          drop

        conformed 21000 bps, exceeded 0000 bps

Could someone explain what the "bc 31250 bytes" switch is doing?

[Joseph W. Doherty · Accepted solution]

Bc (burst committed) 31250 bytes defines the Tc (=Bc/CiR, or in this case 31250 * 8 [bits per byte] / 1000000 = 258 ms for Tc).

The forgoing, in "English", means whether the number of bits, seen crossing the interface within the Tc is <= or > greater than the CiR that's allowed for the Tc. Those greater are dropped.

BTW, drops of sensitive traffic's packets often does adversely impact the application.

[poulid]

Thank you for the reply. Could that be a typo? Seems awfully low considering there's a Skype for Business server plugged into that port that supports 300 users on a daily basis. There are also a lot of clients plugged into that same switch, wondering if the server port just got lumped in with the rest of the clients.

[Joseph W. Doherty]

Low - you mean the CiR or the Tc?

In either case, if it's expected production traffic, generally you shouldn't see a policer dropping some of it.