Perda de Pacotes Severa no Hop 3 (Infraestrutura NOS 10.137.202.225) - Necessito Suporte Avançado

A NOS não te presta o suporte que estás a pedir.

O que saiu de conclusão da chamada ao apoio técnico?

Boa noite ​@Bernardo Santos, 

Relativamente à questão que coloca, não é habitual que os clientes realizem testes diretamente a endereços IP internos da rede da NOS, como os da gama 10.x.x.x que podem aparecer em alguns traceroute.

Esses endereços correspondem normalmente a equipamentos internos da infraestrutura da NOS e podem não responder a ping ou apresentar perda de pacotes em ICMP por motivos de gestão ou “rate limit”, sem que isso represente necessariamente perda de tráfego real.

Do lado do cliente, os testes mais comuns passam por verificar a conectividade com o router (192.168.1.1) e testar a ligação para destinos públicos (por exemplo 8.8.8.8 ou 1.1.1.1).

O mais relevante é perceber se existe perda de pacotes no destino final, e não apenas num hop intermédio do traceroute.

Caso a situação esteja relacionada com o funcionamento do computador ou da rede local, poderá também recorrer ao serviço PC Medic, parceiro da NOS para assistência técnica informática. 

Obrigado.

Olá ​@Guimas  e ​@Jorge C , agradeço o tempo que tiraram para ler e responder.

​@Guimas , a conclusão da linha de apoio foi precisamente que os testes de 1ª linha (nível de sinal, reset ao router) passam com sucesso, mas como a linha de apoio telefónica não tem ferramentas para diagnosticar Packet Loss intermitente no backbone, orientaram-me para o Fórum para que a equipa de moderação oficial possa escalar o caso para a Engenharia de Redes / Equipa de Exterior. A NOS tem obrigação de prestar suporte a falhas graves de infraestrutura, e é isso que estou a solicitar aos moderadores.

​@Jorge C, agradeço a achega técnica, compreendo perfeitamente o conceito de ICMP Rate Limiting ou Control Plane Policing (CoPP) para proteção de CPU em routers de operadora. No entanto, essa premissa teórica não se aplica a este cenário por três motivos muito práticos:

1. Não estou a fazer ping direto ao IP 10.x.x.x
Como expliquei na metodologia, os meus pings são direcionados a destinos públicos finais (ex: 8.8.8.8 ou 1.1.1.1), mas com o TTL artificialmente limitado a 3. Eu não estou a sobrecarregar o Control Plane do router da NOS com Echo Requests diretos. Estou a forçar o tráfego de trânsito a expirar nesse salto. Quando o router falha em devolver o ICMP Time Exceeded numa taxa de 80% a 100% durante os picos de falha, não é rate limit; é o nó que está em saturação extrema ou a descartar tráfego.

2. O Packet Loss reflete-se no Tráfego Real (Data Plane)
Se fosse apenas ICMP Rate Limiting, o tráfego real (TCP/UDP) continuaria a fluir normalmente. Mas não é isso que acontece. Os momentos exatos (ao segundo) em que registo 100% de perda neste Hop 3 coincidem exatamente com a queda dos túneis de VPN (UDP/TCP), interrupção de chamadas VoIP e quebra de sessões SSH. O tráfego real (Data Plane) está efetivamente a ser descartado na vossa infraestrutura local, não é um mero bloqueio cosmético de pings.

3. O Despiste Local está fechado
Como indiquei no quadro, a monitorização ao meu router local (192.168.1.1) tem 0% de quebras durante estes exatos mesmos eventos. A minha LAN, cabos e placas de rede estão em perfeitas condições. Logo, o serviço PC Medic não tem qualquer utilidade aqui, visto que o estrangulamento ocorre da rua para a frente.

Conclusão:
O diagnóstico está feito, isolado e corroborado por quebras reais de serviço, não sendo um mero artefacto de ICMP. 

Fico assim a aguardar que um Gestor de Comunidade oficial da NOS me envie uma mensagem privada para procedermos à abertura do Ticket de Engenharia, para o qual fornecerei prontamente o ficheiro CSV com as provas técnicas.

Obrigado.

Boa noite ​@Bernardo Santos, 

Fiz um simples teste com o comando pathping ao endereço 1.1.1.1 para verificar se existia perda de pacotes ao longo do percurso.

O resultado mostra perda de pacotes elevada em alguns pontos intermédios da rede interna da NOS, com endereços 10.x.x.x. No entanto, a partir desse ponto o tráfego continua normalmente e o destino final, o servidor DNS público 1.1.1.1 da Cloudflare, apresenta zero por cento de perda de pacotes e uma latência na ordem dos vinte milissegundos.

Este comportamento é típico quando routers intermédios limitam respostas ICMP.

O equipamento continua a encaminhar tráfego mas não responde a todos os diagnósticos.

Por esse motivo podem surgir valores elevados de perda nesses pontos mesmo quando o encaminhamento real não apresenta problemas.

Como a perda não se propaga até ao destino final, este teste não indica perda de pacotes.

Para uma análise mais completa poderiam naturalmente ser utilizados outros testes e recolha de dados durante períodos mais longos, mas este resultado já permite perceber que o comportamento observado é consistente com limitação de respostas ICMP em equipamentos intermédios e não necessariamente com perda real de tráfego. 

Obrigado.

O que os moderadores vão fazer ( á partida ) é encaminhar um ticket para o mesmo apoio técnico que ligaste e passar pelos mesmos despistes. A engenharia não vai analisar o teu caso especifico. A outra opção é ligares para a pcmedic.

Olá Jorge C e Guimas.

Jorge C, o seu teste de pathping ilustra perfeitamente o comportamento normal de uma rede saudável, e concordo inteiramente com a sua observação sobre o ICMP Rate Limiting em condições normais. O problema é que o seu teste capta uma "fotografia" de uma ligação estável, enquanto os meus dados refletem um "filme" de duas semanas de uma ligação intermitente.

A diferença fundamental aqui é a correlação temporal. Num cenário de mero "Rate Limit" do router (Control Plane), a perda de ICMP pode existir, mas o payload real (Data Plane) continua a passar. No meu caso, os picos de 80% a 100% de packet loss no Hop 3 coincidem exatamente ao segundo com o drop absoluto do tráfego real (TCP/UDP) - resultando na desconexão imediata dos meus túneis IPsec de trabalho e queda de chamadas VoIP. Ou seja, nesses momentos críticos, o nó não está apenas a limitar respostas de diagnóstico; está fisicamente a descartar o tráfego de trânsito ou a ir abaixo.

Guimas, agradeço o aviso sobre o processo interno da NOS. No entanto, rejeito liminarmente qualquer reencaminhamento para a PC Medic. A PC Medic atua em problemas de software do cliente e redes locais. Estando provado e isolado que a anomalia ocorre no exterior (Hop 3) e afeta múltiplos equipamentos ligados por cabo, a responsabilidade de reparação da infraestrutura é exclusiva da operadora (NOS), sem custos adicionais para o cliente, conforme previsto na Lei das Comunicações Eletrónicas.

Se o procedimento padrão da primeira linha não permite escalar anomalias de backbone, então aguardo a intervenção de um Gestor de Comunidade (@Fórum) que tenha as devidas permissões para reportar este ticket de forma correta à Engenharia de Redes. 

Não necessito de mais despistes básicos, necessito da resolução da anomalia na infraestrutura. Fico a aguardar contacto da moderação. Obrigado.

Gostaria de adicionar um detalhe crucial aos dados recolhidos, que encerra de vez qualquer teoria sobre falhas no meu hardware local (router, cabos ou PC):

Este packet loss não é aleatório; ele segue um padrão horário perfeitamente delineado, típico de saturação de rede (Peak Hours).
Durante a madrugada (ex: 3h da manhã de uma quarta-feira), a ligação para o Hop 3 (10.137.202.225) é imaculada, com latência estável e 0% de quebras. No entanto, entre as 19h e as 23h, o nó colapsa e o packet loss dispara para os valores de 40% a 100% que documentei.

Se o problema estivesse na minha infraestrutura doméstica (como sugerido pela necessidade de usar a PC Medic ou fazer resets), a falha seria agnóstica em relação à hora do dia. Uma placa de rede avariada ou um cabo danificado não "escolhem" falhar apenas em horário nobre.

O facto de a degradação ser sazonal e dependente da hora do dia prova matematicamente que o equipamento 10.137.202.225 (ou o respetivo uplink) está subdimensionado para a agregação de tráfego atual desta célula. O buffer do nó está a saturar e a descartar tráfego (Tail Drop).

Isto é um problema clássico de capacidade/dimensionamento de infraestrutura da NOS na minha zona, e requer a análise da Engenharia para reforço do nó, e não despistes de Wi-Fi. 

Continuo a aguardar o contacto da moderação oficial para facultar os dados da minha conta.

Boa noite ​@Bernardo Santos, 

A “perda de pacotes” em hops intermédios da rede interna não significa necessariamente perda de tráfego real, sendo comum que equipamentos intermédios limitem respostas ICMP.

Nos testes que realizei para destinos públicos (ex.: 1.1.1.1), o destino final não apresenta perda de pacotes nem latência anormal.

Caso esteja a verificar interrupções no serviço, a situação deverá ser analisada pelo apoio técnico.

Obrigado.

Boa noite ​@Jorge C  e ​@Guimas.

Compreendo o que dizem, mas estamos a andar em círculos. O facto de o teste do Jorge ao 1.1.1.1 na sua área de residência não apresentar perdas apenas prova que o *seu* nó local/célula está saudável. O equipamento que serve a minha zona (o tal 10.137.202.225) não está.

Reitero os pontos que provam de forma absoluta que isto não é uma limitação cosmética de ICMP (Rate Limit), mas sim tráfego real a ser descartado:

1. A Correlação em Tempo Real (ICMP vs Tráfego Útil): Sempre que sinto quebras na utilização real da internet (túneis VPN a cair, sessões síncronas a encravar ou VoIP a falhar), consulto imediatamente o meu dashboard de monitorização. A correlação é de 100%: no exato segundo em que o meu serviço falha, o vosso equipamento no Hop 3 regista um pico de packet loss severo. O tráfego útil (Data Plane) está efetivamente a ser descartado ao mesmo tempo que os pacotes de diagnóstico, não é o router a "limitar respostas".
2. O Padrão de Horário de Ponta (Congestionamento): Esta degradação não é aleatória. De madrugada (ex: 3h da manhã), o packet loss no Hop 3 é de 0% e a latência é perfeita. No entanto, em horário de ponta (especialmente entre as 19h e as 23h), o packet loss dispara. Se fosse uma proteção de CPU do router (Rate Limit), ocorreria a qualquer hora do dia. Sendo sazonal, é o sintoma inegável de saturação do nó local. O equipamento da NOS na minha zona está subdimensionado para o tráfego agregado nestas horas, o buffer satura e faz "Tail Drop" aos pacotes.

Relativamente à sugestão de contactar o Apoio Técnico ou a PC Medic: a minha rede local (192.168.1.1) tem 0% de quebras durante estes exatos eventos. O problema é externo. Mais informo que foi a própria Linha de Apoio Técnico da NOS que me orientou a abrir este tópico. A primeira linha telefónica não tem ferramentas para monitorizar saturação de rede em Layer 3, e indicaram que a equipa de moderação do Fórum é a via correta para escalar o caso para a Engenharia de Redes / Equipa de Exterior.

Agradeço as vossas tentativas de ajuda, mas o despiste básico está encerrado. 

Fico exclusivamente a aguardar a intervenção de um moderador oficial da NOS para me solicitar o número de cliente por mensagem privada, para que possamos avançar com a resolução técnica na infraestrutura.

Obrigado.

Boa tarde ​@Bernardo Santos,

Agradecemos a sua mensagem e partilha sobre este tema, assim como a ajuda da comunidade.

Vamos ajudar a analisar. Envie-nos, por favor, uma mensagem privada para o perfil ​@Fórum com o seu NIF.

Obrigado