Ethernet e Wi‑Fi para servidores: link, duplex, MTU e estabilidade

Ethernet e Wi‑Fi no contexto de servidores

Para um servidor, a conectividade local precisa ser previsível: link estável, baixa perda, latência consistente e configuração coerente com o restante da rede (switch, roteador, firewall, hypervisor). Ethernet (cabo) tende a oferecer maior estabilidade e menor variação de latência. Wi‑Fi pode funcionar, mas é mais sujeito a interferência, variação de sinal e mudanças de taxa, o que pode causar sintomas intermitentes difíceis de diagnosticar.

Quando preferir cabo e quando Wi‑Fi é aceitável

• Preferência por cabo (recomendado para servidores): produção, bancos de dados, virtualização, storage (NFS/iSCSI), serviços sensíveis a latência (VoIP, jogos, trading), backups grandes e janelas curtas.
• Wi‑Fi aceitável (com ressalvas): laboratório, homelab, servidor temporário, appliance de monitoramento leve, ou quando não há infraestrutura de cabeamento e o impacto de instabilidade é tolerável.
• Evite Wi‑Fi para tráfego intenso e contínuo, e para serviços que não toleram perda/variação (ex.: replicação, cluster, storage remoto).

Link (up/down): o que significa e por que importa

Link up indica que a camada física está “fechando” (cabo conectado, sinal elétrico/óptico presente; no Wi‑Fi, associação ativa ao AP). Link down indica perda dessa conectividade. Em servidores, flaps (up/down repetidos) normalmente causam timeouts, reconexões, quedas de sessão e lentidão intermitente.

Sintomas comuns de problemas de link

• Aplicações “congelam” e depois voltam (retries e reconexões).
• Timeouts em SSH/RDP, ou sessões que caem.
• Erros em backups (interrompidos) e transferências que reiniciam.
• Logs com mensagens de interface indo para baixo e subindo.

Como validar link e flaps (passo a passo)

1. Verifique o estado da interface no sistema operacional.
2. Verifique logs procurando eventos de link up/down.
3. Correlacione com o switch/AP: porta com flaps, contadores de erro, renegociação.

Linux (exemplos):

ip link show dev eth0
ethtool eth0
journalctl -k | egrep -i "eth0|link is|reneg|down|up"

Windows (exemplos):

Get-NetAdapter | Format-Table Name, Status, LinkSpeed
Get-WinEvent -LogName System | ? { $_.Message -match "network" -or $_.Message -match "link" } | Select-Object -First 20

Indicadores úteis: LEDs da placa e do switch (link/atividade), e no Wi‑Fi o RSSI/sinal e taxa negociada.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Negociação de velocidade e duplex (Ethernet)

Em Ethernet, a interface e o switch negociam automaticamente velocidade (ex.: 100M/1G/10G) e duplex (half/full). Em redes modernas, full duplex é o esperado. Um dos problemas clássicos é mismatch de duplex (um lado full, outro half), que causa colisões, retransmissões e desempenho errático.

O que observar na prática

• Velocidade abaixo do esperado (ex.: caiu de 1G para 100M): pode indicar cabo ruim, par rompido, conector mal crimpado, porta com limitação, autonegociação falhando.
• Duplex incorreto: pode gerar lentidão intermitente, especialmente sob carga (uploads/downloads simultâneos).
• Renegociação frequente: link flapping ou instabilidade elétrica/cabo.

Como checar velocidade/duplex e autonegociação (passo a passo)

Linux:

ethtool eth0

Procure campos como Speed:, Duplex:, Auto-negotiation:, Link detected:.

Windows:

Get-NetAdapter | Select Name, Status, LinkSpeed
Get-NetAdapterAdvancedProperty -Name "Ethernet" | ? DisplayName -match "Speed|Duplex"

Boas práticas:

• Deixe autonegociação habilitada em ambos os lados na maioria dos cenários.
• Se precisar fixar velocidade/duplex, fixe nos dois lados (servidor e switch) e documente.
• Ao ver queda para 100M, teste com outro cabo/porta e verifique categoria (Cat5e/6/6A) e integridade.

Erros de camada 2: CRC, drops e o que eles indicam

Mesmo com link “up”, quadros podem chegar corrompidos ou ser descartados. Em Ethernet, erros de camada 2 frequentemente aparecem como contadores de CRC, frame errors, rx/tx errors e drops. Em Wi‑Fi, perdas e retransmissões são mais comuns por natureza do meio compartilhado e interferência.

Principais contadores e interpretações

• CRC / FCS errors (RX): quadros chegaram corrompidos. Causas comuns: cabo/porta ruim, interferência elétrica, transceiver defeituoso, NIC com problema.
• Drops (RX/TX): pacotes descartados por falta de buffer, congestionamento, driver, ou políticas (ex.: QoS). Em servidores, drops sob carga podem indicar gargalo (CPU/IRQ, fila de NIC, buffer do switch).
• Overruns / missed: a interface não conseguiu processar a tempo (alta taxa de pacotes, interrupções, driver).
• Collisions / late collisions: em redes modernas full duplex não deveria ocorrer; se aparecer, suspeite fortemente de duplex mismatch ou equipamento legado.

Como checar erros e drops (passo a passo)

Linux:

ip -s link show dev eth0
ethtool -S eth0

Windows: (contadores variam por driver; use Performance Monitor e propriedades do adaptador)

Get-NetAdapterStatistics -Name "Ethernet"

O que fazer quando há CRC subindo continuamente (roteiro rápido):

1. Troque o cabo por um conhecido bom.
2. Mude a porta do switch.
3. Verifique se a velocidade negociada caiu (ex.: 1G→100M).
4. Se for SFP/SFP+, troque o módulo e limpe/conferir fibra.
5. Atualize driver/firmware da NIC e do switch (quando aplicável).

MTU: tamanho máximo de quadro e impactos reais

MTU (Maximum Transmission Unit) é o maior tamanho de payload IP que pode ser transportado sem fragmentação naquele enlace. Em Ethernet padrão, o MTU comum é 1500. Em alguns ambientes, usa-se jumbo frames (ex.: 9000) para reduzir overhead em tráfego grande (storage, backups), mas isso exige consistência ponta a ponta.

Por que MTU causa problemas “misteriosos”

Quando há inconsistência de MTU no caminho, pacotes grandes podem falhar enquanto pacotes pequenos funcionam. Isso gera sintomas como:

• Ping funciona, mas HTTPS/SSH/transferências travam em certos momentos.
• VPN conecta, mas acesso a alguns sites/serviços falha.
• Conexões ficam lentas com retransmissões e timeouts.

MTU e encapsulamento (VPN, túneis e VLAN)

Encapsulamentos adicionam cabeçalhos extras (overhead). Exemplos comuns:

• VPN (WireGuard, IPsec, OpenVPN): adiciona overhead; se você mantiver MTU 1500 no túnel sem ajustar, pode estourar o MTU do caminho físico e causar fragmentação ou drops.
• PPPoE: reduz MTU efetivo (muito comum em links de operadoras), frequentemente para 1492.
• VXLAN/GRE: overhead significativo; em datacenters é comum aumentar MTU do underlay para acomodar o overlay.

Regra prática: o MTU efetivo do túnel deve considerar o overhead. Se o caminho físico é 1500, o túnel geralmente precisa de MTU menor (ex.: 1420–1460, dependendo do protocolo).

Como checar e ajustar MTU (passo a passo)

1) Ver MTU atual

ip link show dev eth0

2) Testar o maior pacote sem fragmentar (descoberta prática de MTU)

No Linux/Windows, use ping com “não fragmentar” e ajuste o tamanho até passar. Lembre que o tamanho do ping é payload ICMP; há overhead de IP/ICMP.

# Linux (IPv4): -M do = don't fragment; -s = tamanho do payload ICMP
ping -M do -s 1472 8.8.8.8

# Windows: -f = don't fragment; -l = tamanho do payload
ping -f -l 1472 8.8.8.8

Se 1472 falhar e 1464 passar, você está encontrando o limite do caminho. (1472 + 28 bytes de cabeçalhos IP+ICMP = 1500.)

3) Ajustar MTU (exemplo Linux; ajuste conforme sua interface)

sudo ip link set dev eth0 mtu 1500

Cuidados com jumbo frames:

• Ative jumbo apenas se todas as interfaces/switches no caminho suportarem e estiverem configuradas.
• Teste com tráfego real (backup, storage) e monitore drops/erros.
• Em ambientes virtualizados, lembre do MTU em: VM, vSwitch/bridge, host e físico.

Estabilidade: latência, jitter e perda (como interpretar)

Para servidores, não é só “ter conectividade”; é ter consistência. Três sinais importantes:

• Latência: tempo de ida e volta (RTT). Alta latência pode ser normal em WAN, mas em LAN deve ser baixa e estável.
• Jitter: variação da latência. Jitter alto causa problemas em aplicações sensíveis (voz, streaming, alguns protocolos de cluster).
• Perda: pacotes que não chegam. Mesmo 0,5% pode derrubar desempenho de TCP e causar timeouts em aplicações.

Como medir rapidamente (passo a passo)

1) Ping para o gateway e para um host na mesma rede

ping -c 50 192.168.1.1
ping -c 50 192.168.1.10

Interpretação:

• Perda para o gateway: problema local (cabo/switch/AP/NIC).
• Sem perda, mas latência variando muito em Wi‑Fi: interferência, roaming, sinal fraco, congestionamento do canal.

2) Traceroute para identificar onde a latência aumenta

traceroute 8.8.8.8
# ou
tracepath 8.8.8.8

3) Teste de throughput (quando possível em ambiente controlado)

# Exemplo com iperf3 (requer servidor iperf3 em outro host)
iperf3 -c 192.168.1.10 -t 30
iperf3 -c 192.168.1.10 -R -t 30

Compare upload e download; assimetrias podem indicar duplex/driver/QoS, ou no Wi‑Fi limitações de uplink.

Wi‑Fi: particularidades que afetam servidores

Wi‑Fi é um meio compartilhado e sujeito a interferência. Mesmo com “sinal cheio”, a taxa real pode variar por ruído, distância, obstáculos, número de clientes e largura de canal. Além disso, há economia de energia e roaming (em notebooks) que não se aplicam bem a servidores, mas podem existir em mini PCs.

Sinais de alerta em Wi‑Fi

• Latência oscilando (ex.: 2 ms → 80 ms) sem mudança de tráfego.
• Perda intermitente, especialmente em horários de pico.
• Taxa negociada variando muito (MCS/PHY rate).
• Desconexões e reconexões (reassociação).

Boas práticas se precisar usar Wi‑Fi

• Prefira 5 GHz/6 GHz (menos interferência que 2,4 GHz) e canais adequados.
• Fixe o servidor em um local com bom RSSI e pouca obstrução; evite ficar atrás de metal/armários.
• Evite modos de economia de energia agressivos na placa Wi‑Fi.
• Monitore perda/latência continuamente (mesmo com ferramentas simples) para detectar degradação.

Exemplos de sintomas e como validar com indicadores do sistema

Caso 1: “Lentidão intermitente” em cópias e backups

Sintomas: cópia começa rápida, depois cai muito; sessões SSH continuam, mas comandos demoram; backup falha às vezes.

Validação:

• Checar se a interface caiu para 100M: ethtool eth0 / Get-NetAdapter.
• Checar CRC/drops aumentando: ip -s link, ethtool -S, Get-NetAdapterStatistics.
• Testar outro cabo/porta do switch.

Caso 2: “Timeouts” ao acessar um serviço via VPN

Sintomas: VPN conecta, mas alguns sites internos não abrem; RDP/SSH trava; ping pequeno funciona.

Validação:

• Testar MTU com ping DF: ping -M do -s 1472 ... (Linux) / ping -f -l 1472 ... (Windows).
• Usar tracepath para observar MTU do caminho (quando disponível).
• Ajustar MTU do túnel (ou MSS clamping no gateway, quando aplicável).

Caso 3: “Link up/down” e quedas de sessão

Sintomas: logs mostram desconexões; containers/VMs perdem rede; monitoramento acusa host “flapping”.

Validação:

• Logs do kernel: journalctl -k filtrando por interface.
• Verificar renegociação no ethtool e contadores no switch.
• Checar alimentação/temperatura (NICs e switches podem falhar sob calor), e cabos mal encaixados.

Checklist rápido de diagnóstico (Ethernet/Wi‑Fi)