[GTER] RES: RX Pause em GE CCR1036 vs. 3c2920.

[Henrique de Moraes Holschuh]

On Wed, 07 May 2014, Douglas Fischer wrote:
> P.S.: Na verdade eu só ví isso em FC, principalmente em switchs meia boca
> onde depois de um agregation o enlace seguinte tenha algum oversubscription.

Flow-control é gerador de pesadelo de administrador de rede, simples assim.
Basta ter uma LAN com grande potencial de contenção nos uplinks/troncos, e
switches que preferem propagar pause-frame a perder pacote.

Aliás, leia isso para uma história de horror regada à flow-control:

http://monolight.cc/2011/08/flow-control-flaw-in-broadcom-bcm5709-nics-and-bcm56xxx-switches/

BCM56xxx são os famosos StrataXGS.  Tem isso dentro de tudo quanto é switch
gigabit gerenciável dos mais variados fabricantes...

> Mas o que eu quis dizer é que se existe algum problema que só ocorra quando
> em LAG, em não em interface única... Talvez o problema não esteja no
> aggregation. Talvez o aggregation esteja apenas explicitando a existência
> desse problema.

Um pause-frame recebido na hora errada pode segurar os frames de controle
(BPDUs, LACP, etc) no TX-ring/packet-buffer.  É bem fácil de imaginar que
isso pode exarcebar problemas.

> Não escondo meus receios sobre MK, mas nesse caso o design do MK é menos
> problemático no que se refere a buffers.

O que conta é o tamanho do RX-ring, porque qualquer NIC que preste vai
emitir pause-frames automaticamente (em hardware/firmware) quando o RX-ring
estiver quase cheio se o flow-control para aquela direção estiver ligado.

Exceção para portas em network processors ou ASICs, que podem ou não ter
algo diferente por trás do sistema de flow-control, mas não é o caso da
maior parte dos MKs (talvez seja caso na CCR).

De qualquer forma, o MK muito provavelmente[1] vai honrar os pause-frames
recebidos (ou seja, emitidos pela switch) sem distinção do que estiver no
TX-ring e outgoing queues, e aí pode estar o problema.

Para piorar, que eu saiba em geral Linux não conta pause-frames.  Eles vão
aparecer, *talvez*, no contador de frames multicast (e isso depende do
NIC/driver).  Certamente não achei nos "performance counters" do ethtool,
que são a base do monitoramento SNMP.  Então ou vê que tem coisa errada
pelos contadores da switch, ou não fica nem sabendo...

[1] leia-se: sempre que for Linux controlando a porta/NIC

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh