Um cliente liga: o vídeo está lento desde terça-feira. Um cliente empresarial envia uma captura de ecrã com 300 ms de ping. Dentro da sua rede, todos os gráficos estão a verde. A degradação costuma estar na fronteira do que controla: uma porta de peering saturada, um trânsito a reencaminhar por outro ponto de troca, ou o próprio destino. Precisa de ver o caminho como o cliente o vê, e como surge de outras redes, antes de decidir se a falha é sua, do upstream ou de ninguém.
Um traceroute visual a partir de vários pontos, a sua região, outra região, uma sonda na rede de um concorrente, mostra cada salto com latência, jitter, perda e ASN, e mapeia onde o tráfego sai do seu AS. Os traceroutes agendados dão a tendência antes de as reclamações chegarem; a comparação mostra o caminho antes e depois de uma alteração de encaminhamento; a exportação dá um documento datado, com os dados de cada salto, para enviar a um trânsito ou peer em vez de discutir ao telefone.
Vigiar as fronteiras de peering e de trânsito ao longo do tempo
Agende traceroutes a partir de Falkenstein, Gravelines ou de uma sonda Globalping na sua base de clientes para os destinos das reclamações: grandes CDN, regiões de cloud, anfitriões de jogos, resolvedores públicos. Defina alertas de latência, perda e mudança de rota. Um alerta de mudança de rota é o primeiro sinal de que uma sessão caiu ou uma política mudou a montante. Leia o salto onde o seu ASN entrega o tráfego. Se latência e jitter sobem aí, em hora de ponta, no mesmo salto todas as noites, essa porta está saturada ou o peer limita. Se sobem dois saltos adiante, na rede do trânsito, o problema é deles, e a exportação mostra-o. Compare um traceroute de hora calma com um de hora de ponta para medir a degradação.
Transformar uma reclamação numa falha localizada em minutos
Peça ao cliente o destino e a hora. Trace até lá a partir da origem mais próxima dele e a partir de uma sonda fora da sua rede. Três desfechos. Ambos os traceroutes limpos: o problema está nas instalações do cliente, no Wi-Fi ou no CPE, ou é intermitente; peça-lhe que avise quando voltar a acontecer. O seu traceroute mau e o exterior limpo para o mesmo alvo: a falha está do seu lado da passagem ou no seu caminho de trânsito, por isso veja o salto onde o atraso começa. Ambos maus a partir do mesmo salto: o destino ou o seu fornecedor está degradado, e pode dizê-lo ao cliente com provas. Perda num único salto intermédio que desaparece no destino é limitação de ICMP, não algo a escalar.
Validar uma alteração BGP a partir do exterior
Depois de anunciar um prefixo novo, movê-lo para outro trânsito ou acrescentar um prepend, verifique a propagação com o BGP Viewer: que ASN de origem os coletores veem, por que upstreams, e quantos coletores a transportam. Depois trace até um endereço do prefixo a partir de sondas em vários países e compare: o tráfego de entrada deve chegar ao seu AS pelo trânsito esperado. Se as sondas de uma região continuam a chegar pelo caminho antigo horas depois, esse upstream não atualizou ou um filtro rejeitou o anúncio. Guarde o traceroute anterior à alteração e compare-o com o de depois; a vista lado a lado mostra o salto onde os caminhos divergem. O encaminhamento assimétrico, sair por um trânsito e entrar por outro, é normal, mas deve ser intencional.
Ler um traceroute: perda que começa dentro de um trânsito
Exemplo pedagógico, não uma medição real. De uma sonda na sua rede até uma CDN de vídeo, os saltos 1 a 3 ficam no seu AS a 2 a 4 ms, sem perda. O salto 4 é a passagem para o trânsito: 5 ms, 0% de perda. O salto 5, ainda no ASN do trânsito, marca 6 ms mas 30% de perda, e os saltos 6 a 9 mostram 28 a 32%. A perda persiste até ao destino, logo é real, e começa na rede do trânsito um salto após a sua fronteira. O mesmo traceroute de uma sonda Globalping noutro operador mostra 0% de perda: a CDN está bem. Conclusão: uma ligação degradada ou porta congestionada no trânsito. A exportação, com datas e os dois traceroutes, vai para o NOC deles; um traceroute agendado diz quando ficou resolvido.
Ferramentas que completam o quadro
O BGP Viewer mostra quem origina um prefixo, os upstreams e quantos coletores o veem: a primeira verificação após alterar os anúncios. O WHOIS e o IP Reputation identificam um destino ou um endereço de cliente quando uma reclamação menciona bloqueio ou lista negra. O DNS Lookup, com o resolvedor à escolha, confirma que uma CDN ou serviço anycast envia os clientes para um nó próximo. O Ping durante um período confirma o jitter numa ligação antes de traçar, e o Port Check verifica a filtragem do exterior.
Perguntas frequentes
- Posso traçar do ponto de vista de um cliente sem o dispositivo dele?
- Escolha uma origem próxima dele: Falkenstein, Gravelines ou uma das sondas Globalping, algumas das quais estão em redes residenciais ou de outros operadores. O traceroute não incluirá o salto de casa dele, mas mostra o caminho desde uma rede vizinha até ao destino. Se esse caminho estiver limpo enquanto a reclamação persiste, o problema está muito provavelmente entre o CPE do cliente e o seu primeiro router.
- Como funciona um alerta de mudança de rota?
- Um traceroute agendado corre no intervalo que definir. Cada execução regista a sequência de endereços dos saltos e, quando difere da execução anterior, é enviado um alerta, sujeito a um período de espera para que um caminho instável não o notifique de poucos em poucos minutos. Combine-o com limites de latência e de perda para apanhar tanto reencaminhamentos silenciosos como degradações lentas, e abra os dois traceroutes lado a lado para ver onde divergem.
- Posso provar a um fornecedor de trânsito que a falha está do lado dele?
- Pode entregar-lhe um traceroute datado a partir da sua rede e outro a partir de uma sonda exterior para o mesmo destino, ambos a mostrar perda ou latência a aparecer dentro do ASN dele e a persistir até ao fim. Exporte em PDF ou JSON e anexe ao ticket. É prova ao nível do salto, com atribuição de ASN, que é o que o NOC deles precisa para olhar para a ligação certa, mesmo que contestem a conclusão.