[c-nsp] QOS Tx Drops on N3k

[Saku Ytti]

Best information I could find the device has aggregate 5MB of buffers,
5MB/10Gbps is 4ms. But any other port using buffers is going to
compete for those.


If you just have 1 ingress port and 1 egress port and they are same
rate, no buffering should be needed. But maybe you have lot of 1GE
ingresses? Unfortunately I've not ran this platform so I cannot offer
platform specific advice. Maybe time for CTAC case.



On 18 March 2018 at 23:02, Sergey S. <gforgx at fotontel.ru> wrote:
> Hi, Saku!
>
> There is only one more 10G port (ingress) in the same VLAN.
>
>
>
>
> On 03/18/2018 11:47 AM, Saku Ytti wrote:
>>
>> Hey Sergey,
>>
>>
>> Your intuition seems right. My initial guess as well would be that
>> these are consequence of microbursts. So any effort to understand
>> buffer utilisation is needed to exclude or prove that.
>>
>>
>> Do you have ingress ports operating at 100GE or do you have multiple
>> 10GE ingress ports competing for that 10GE egress port?
>>
>>
>> On 18 March 2018 at 00:52, Sergey S. <gforgx at fotontel.ru> wrote:
>>>
>>> Hi,
>>>
>>> I'm running NXOS 7.0(3)I5(2) on N3K-C3064PQ-10GE.
>>>
>>> Output discards counter is gradually incrementing on one 10G port despite
>>> it
>>> not being oversubscribed in those moments of time.
>>>
>>> If I look at "sh hardware internal interface asic counters module 1"
>>> these
>>> drops are displayed as QOS Tx Drops.
>>>
>>> I've tried setting up "hardware profile buffer info port-threshold" even
>>> to
>>> the lowest values (e. g., 1%) to figure out if there is a problem with
>>> QoS
>>> queues, however there isn't any information in "sh hardware internal
>>> buffer
>>> info pkt-stats port-log" (most likely I don't understand the concept of
>>> buffer monitoring and/or it's totally unrelated to my issue).
>>>
>>> There isn't any special QoS configuration on the switch. It is just as
>>> follows:
>>>
>>> policy-map type network-qos jumbo
>>>    class type network-qos class-default
>>>      mtu 9216
>>> system qos
>>>    service-policy type network-qos jumbo
>>>
>>> Not sure whether this gives some clue, anyway, the port in the subject is
>>> connected to a large broadcast domain (Internet Exchange Point).
>>>
>>> Thank you for any hint!
>>>
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>>
>



-- 
  ++ytti