Estou depurando um caso de pacotes UDP perdidos em um switch gigabit de armazenamento e encaminhamento e queria visualizar o que acontece dentro do switch para entender melhor a essência do problema.
O cenário é simples - dois fluxos de dados em rajadas passam por 2 portas dentro do switch e ambos desejam sair por uma terceira porta (comum a ambos). Portanto, o switch precisa reter alguns dados no buffer de pacotes por um tempo.
O problema é: com base nos meus cálculos simples, os buffers devem ser grandes o suficiente para lidar com o caso que estou examinando. Um fluxo de dados envia rajadas de 25 kB (divididos em pacotes de 1.514 B) a cada 1,56 ms, o outro envia rajadas de 60 kB a cada 1 ms. Agora, mesmo um switch soho como o Netgear GS105E possui buffer de 128 kB. Portanto, a matemática simples (25+60 <128) indica que deve funcionar mesmo que os fluxos cheguem ao mesmo tempo (dado que não há outro tráfego substancial).
Os testes reais mostram que muitos pacotes de ambos os fluxos se perdem em alguns switches (parece estar vinculado ao tamanho do buffer, mas não apenas a ele). Na minha simulação, não consigo fazer com que o buffer fique cheio demais quando definido para 128 kB.
Gravei esta animação para um buffer de 24 kB onde há overfill. No entanto, você pode ver facilmente que aumentar o buffer em apenas alguns bytes resolveria o problema e todos os pacotes passariam.
Fiz algumas simplificações nesta simulação. Todos os pacotes têm a mesma QoS (isso também ocorre no caso real). Portanto, deixei de fora as filas de QoS da simulação e estou tratando todo o tráfego como igualmente importante. Em seguida, deixei de fora o gerenciamento de memória do buffer. Posso imaginar que seja uma parte importante do problema, mas ficaria surpreso se a minha simplificação com alocações perfeitas estivesse mais de 10% errada em relação ao caso real. Também finjo que o switch conhece o comprimento do quadro quando recebe seus primeiros bytes, para que reserve toda a memória necessária no início. Como não consegui encontrar nenhuma documentação sobre o tamanho das filas de entrada/saída das portas, presumo que todas elas sejam colocadas no buffer de pacotes compartilhado e possam ocupar a maior parte do buffer conforme necessário (embora eu ache que o culpado possa ser em algum lugar aqui). Eu configurei o atraso de processamento de cada pacote para 512 ns (o atraso de propagação de um pacote de 64 B).
Não tenho certeza se isso desempenha um papel, mas os fluxos consistem em pacotes UDP fragmentados (ou seja, o burst de 25 kB é um único pacote UDP fragmentado em 17 fragmentos de IP). O segundo fluxo cria o burst como 2 ou 3 pacotes UDP de 20 kB, cada um fragmentado em 14 fragmentos IP.
Os comandos do Iperf 3.7 para replicar streams semelhantes aos reais são:
iperf3 -c sink -u -b 128M -t 600 -l 25256 --pacing-timer 1560
iperf3 -c sink -u -b 400M -t 600 -l 20k --pacing-timer 1000
Você tem alguma ideia do que mais esqueci de levar em consideração que poderia fazer com que a simulação ficasse tão longe da realidade? Obrigado pela ajuda!
O código fonte da animação está emhttps://gist.github.com/peci1/a0346538acc6c289b2c6d596b184ad21.
Aqui está minha tabela de resultados de experimentos reais. O fluxo de dados um é fixo - 128 Mbps em pacotes UDP de 25 kB cada 1,56 ms. Eu estava alterando os parâmetros do segundo stream tentando encontrar o limite onde os pacotes do primeiro stream começarão a ser perdidos pelo switch. Eu estava alterando o -lparâmetro (comprimento) especificando o tamanho do pacote UDP e o -bparâmetro (largura de banda) especificando qual largura de banda esses pacotes deveriam gerar. --pacing-timersempre foi definido como 1000 para o segundo fluxo. Você pode ver que o D-Link e o Netgear GS105 não conseguem lidar com rajadas de 60 kB. O GS108 se sai muito melhor que o GS105, embora tenha quase o mesmo chip de switch (a mesma "família", apenas um número diferente de portas e um buffer um pouco maior).
| Trocar | Tamanho do buffer [kB] | Tráfego máximo de explosão de 1,5 KB | Tráfego máximo de explosão de 20 KB | Tráfego máximo de explosão de 60 KB |
|---|---|---|---|---|
| Gigablox robusto (VSC7512) | 220 | 825Mbps | 825Mbps | 825Mbps |
| Gigablox (RTL8367N-VB-CG) | 250 | 730Mbps | 750Mbps | 790Mbps |
| D-Link DIS-100G-5W (QCA8337N-AL3C) | 128 | 110Mbps | 1Mbps | cada explosão perde pacotes |
| Zyxel XGS 1210-12 (RTL9302B) | 1500 | 800Mbps | 830Mbps | 830Mbps |
| Netgear GS310-TP (RTL8380M) | 520 | 830Mbps | 830Mbps | 835Mbps |
| Netgear GS308T (RTL8380M) | 520 | 830Mbps | 835Mbps | 835Mbps |
| Netgear GS108 v3 (BCM53118) | 192 | 630Mbps | 660Mbps | 710Mbps |
| Netgear GS105E (BCM53114) | 128 | 120Mbps | 1Mbps | cada explosão perde pacotes |
| Renkforce RF-4270245 | ? | 740Mbps | 760Mbps | 800Mbps |
| Microtik RB260GS (AR8327) | 128 | 835Mbps | 835Mbps | 835Mbps |
| Junípero EX2300 | 4GB? | 800Mbps | 830Mbps | 830Mbps |
(Esta questão foi migrada dehttps://networkengineering.stackexchange.com/questions/78529/how-to-simulate-what-happens-inside-the-packet-buffer-of-a-simple-switchonde foi marcado como fora do tópico).