Um caminho ECMP com defeito ECMP / link bundle member fault
ID da causa isp-ecmp · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
Operadoras e data centers mantêm vários caminhos para o mesmo destino e mandam cada conexão por um deles. Se só um caminho falha, só quem caiu nesse caminho continua com lag.
Por quê Em um trecho com vários links agregados, um link ou um equipamento está com defeito ou congestionado → Efeito O caminho é escolhido pela combinação de endereços e portas (hash), então só as conexões que caem nesse caminho sofrem perda e atraso → Na tela Mesma região e mesma operadora, mas só alguns jogadores têm teleporte constante. Às vezes reconectar resolve
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
O que fazer (Equipe de desenvolvimento)
Registrar estatísticas de perda e retransmissão por conexão, para poder extrair o IP, a porta e o horário de quem é afetado (no TCP, o número de retransmissões do TCP_INFO; no UDP, calcular pelos números de sequência que faltam).
O que fazer (Equipe de infraestrutura)
Juntar IP, porta e horário de quem é afetado e repassar à operadora ou ao data center, monitorar a perda por caminho, medir os caminhos com o mesmo protocolo e a mesma porta do jogo (mtr --tcp ou --udp com --port), tirar do grupo o link ou equipamento com defeito se o caminho passar pelos nossos equipamentos.
O que fazer (Externo)
Pedir à operadora que verifique e substitua o caminho com defeito, orientar os jogadores a reconectar para contornar o problema por enquanto (quando a reconexão muda a porta).
Números de referência
Com 4 caminhos, só cerca de um quarto dos jogadores é afetado. O teste de ping pode seguir um caminho diferente do jogo e dar resultado normal.
No gráfico
Alto só em alguns · Perda e retransmissões por conexão (por IP e porta)
Onde olhar
Separar a perda e as retransmissões por conexão por IP e porta de origem. Rodar o mtr em UDP (-u) contra a porta do jogo (-P) com a porta de origem fixa (-L) e repetir várias vezes trocando a porta de origem. Com -P e sem -L, a porta de origem muda a cada requisição e vários caminhos se misturam
Confirma se
Dentro da mesma região e operadora, só certas combinações de porta (ou endereço) de origem têm perda constante, e o problema some quando uma reconexão muda a porta
Descarta se
Ruim com qualquer porta: congestionamento ou falha em um trecho inteiro
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Para não embaralhar a ordem dos pacotes de uma conexão, os equipamentos (ECMP, LAG) fixam cada conexão em um caminho com base em um valor calculado a partir dos endereços e portas (ou só dos endereços, conforme a configuração do equipamento). Onde só os endereços são usados, reconectar cai no mesmo caminho e não ajuda. Por isso, quando chegam juntos reports como “o ping está normal, mas o jogo tem lag” e “reconectei e melhorou”, suspeite desta causa.
RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop SelectionIETF O critério que define um fluxo varia conforme a implementação (só o endereço de destino, o par de endereços ou incluindo as portas); com vários caminhos, é difícil confiar nos resultados de ping e traceroute
mtr(8) manual page sourcemtr Opções -u (UDP), -P (porta de destino) e -L (porta de origem UDP); só com -P, o número de sequência da requisição vai na porta de origem, que muda a cada requisição