Cerca de 15% de perda de pacotes através de um SFP+ de cobre S+RJ10 num CRS518-16XS-2XQ, enquanto o caminho direto em 100G está limpo
Empurramos tráfego de um servidor de laboratório para um CRS518-16XS-2XQ por um uplink 100G QSFP28, e ele sai do switch por um SFP+ de cobre MikroTik S+RJ10 para um host comum com RJ45 1G. O lado receptor está perdendo uma boa fatia dos pacotes e não consigo cravar a causa em nada óbvio.
Configuração:
- MikroTik CRS518-16XS-2XQ, uplink 100G QSFP28 vindo da fonte de tráfego
- SFP+ de cobre MikroTik S+RJ10 numa das cages, dispositivo RJ45 1G na outra ponta
- captura rodando no host receptor
O que a captura mostra:
100G QSFP28 uplink -> CRS518-16XS-2XQ -> S+RJ10 -> 1G RJ45 host
capture on the 1G host: ~15% of the packets never arrive
same source, direct 100G connection: nothing missing
switch CPU load: 1%Já tentei:
- conectei a mesma fonte direto em 100G, nenhuma perda, então o remetente em si está bem
- baixei a carga de CPU do switch, agora ela fica em 1% enquanto a perda continua acontecendo
- reencaixei o S+RJ10 e troquei o cordão até o dispositivo 1G
O módulo de cobre é meu principal suspeito nesse ponto, mas o link está limpo e a interface não mostra erro nenhum. O S+RJ10 é conhecido por comer tráfego desse jeito, ou eu deveria estar procurando em outro lugar dentro do switch?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
400-500 Mbps de média com um remetente em rajadas é a história toda. Seu tráfego não está distribuído igualmente: rajadas curtas saem da fonte mais rápido que 1 Gbps, e tudo acima dessa linha precisa ficar no buffer de egress da porta até o lado 1G escoar. Quando o buffer enche, o switch descarta. É exatamente isso que o movimento do rx-overflow está te dizendo, e é por isso que a conexão direta em 100G não mostra nada - não existe redução de velocidade ali para gerar buffer contra.
O transceptor é inocente. Qualquer coisa naquela cage, cobre ou fibra, se comportaria do mesmo jeito, porque o descarte acontece na redução de 100G para 1G, não dentro do módulo.
Duas coisas para fazer. A correção de verdade é no remetente: ritmar ele para os pacotes saírem distribuídos igualmente em vez de serem escritos em rajadas. Assim que a fonte parar de produzir rajadas acima da taxa de egress, a perda desaparece.
No switch você pode deixar a situação do buffer menos hostil:
Isso compra margem e deixa uma rajada se sustentar por mais tempo, mas não remove a causa - se o remetente rajar forte o suficiente por tempo suficiente, nenhum tamanho de buffer vai te salvar. Continue observando as estatísticas de QoS do switch e os contadores de rx-overflow depois da mudança, para ver se você ainda está batendo no teto ou só tocando nele ocasionalmente.
A lição geral vale a pena guardar: uma porta com link limpo, sem erros e um módulo saudável ainda pode descartar uma fatia de dois dígitos do tráfego só por causa de uma redução de velocidade entre portas.
Antes de culpar o módulo, olhe o que os contadores da porta realmente dizem. Rode
na porta de ingress 100G e na cage com o S+RJ10, e vá direto na linha rx-overflow em vez dos contadores usuais de erro rx/tx. Um SFP+ de cobre genuinamente quebrado se anuncia como erros de FCS ou um link piscando, não como um corte arrumadinho de 15% num fluxo que por outro lado é saudável.
Segunda pergunta: qual é a taxa média por esse caminho, e você tem alguma ideia dos picos? Perder um pacote em cada sete com a CPU em 1% cheira muito mais a porta de egress ficando sem buffer do que a falha de transceptor.
Contadores primeiro: nenhum erro em nenhuma das portas, o link fica up o tempo todo e o módulo não reporta nada incomum. rx-overflow é o único lugar onde os números se mexem.
Sobre taxa, o caminho tem média de 400-500 Mbps, então no papel está longe de saturar o lado 1G. Não tenho medição de pico, mas o tráfego é em rajadas por natureza - o remetente escreve um bloco e depois fica quieto por um tempo. A CPU continua em 1% enquanto os pacotes somem.
Falha diferente, mesma lição sobre confiar em contadores em vez de intuição. Eu tinha um CRS354-48G-4S+2Q+RM no SwOS 2.18 com Rx FCS Errors crescendo continuamente nas duas portas QSFP+, e Rx MAC Errors numa taxa menor. As duas portas ficavam em 40G full duplex com MTU 1500, e do outro lado havia hosts ESXi com placas Mellanox ConnectX-3 Pro CX324A.
A parte interessante: o lado da NIC não reportava absolutamente nada.
Limpo. Cabos comprovadamente bons não mudaram nada, e as portas SFP+ 10G da mesma caixa ficaram sem erro o tempo todo. Nunca cheguei a um diagnóstico de verdade - mudar o switch de SwOS para RouterOS fez os contadores sumirem, o que eu considero esconder o problema em vez de resolver.
O método que sobreviveu: zerar os contadores, reler eles num intervalo fixo e ver se os erros acompanham o volume de tráfego. No seu caso eles vão acompanhar as rajadas, no meu não acompanhavam nada útil, e só essa diferença já diz de que lado continuar cavando.
Uma coisa para ter em mente enquanto você experimenta nessa porta: não recorra a forçar velocidade e duplex como saída. O comportamento documentado dos módulos de cobre MikroTik, tanto o S-RJ01 quanto o S+RJ10, é que eles só funcionam com autonegociação ligada - fixe a taxa estaticamente e o link simplesmente não sobe. A prática contradiz isso em parte, já que alguns donos de RB5009 e RB4011 relatam o oposto e só conseguiram estabilizar um S-RJ01 forçando 1G full duplex, então é mais um "teste os dois no seu próprio hardware" do que uma regra. De qualquer forma é um desvio do seu problema real, que está do lado do buffer.
Outro detalhe do S+RJ10 que vale saber para depois: ele consome bem mais energia que um óptico normal e esquenta, então não é recomendado num equipamento resfriado passivamente sem fluxo de ar extra. Se esse módulo algum dia começar a se comportar mal num chassi quente, temperatura é a primeira coisa que eu checaria.