Resolução de Problemas de Perda de Pacotes no Socket Site

Problema

Determinar a origem da perda de pacotes e por que ela está ocorrendo nem sempre é fácil. Pacotes passam por múltiplas redes de diferentes ISPs e organizações pela Internet, e você não tem acesso a cada roteador no caminho para verificar coisas como o estado do link e carga da CPU. Além disso, a perda de pacotes pode ocorrer em qualquer ponto ao longo do caminho da rede.

Causas Possíveis

Há inúmeras razões pelas quais os pacotes podem ser descartados ao longo do caminho. Algumas razões comuns são:

• Problemas de peering de ISP
• Congestionamento do link
• Configuração incorreta (configurações de largura de banda ou velocidade e duplex da NIC)
• Falhas de hardware
• Alta utilização de CPU em um dispositivo de rede
• Tratamento de micro-rajadas

Entendendo a Perda de Pacotes no Cato

Uma boa maneira de identificar a perda de pacotes no Cato é usar a tela de Análise no Aplicativo de Gerenciamento Cato. Os gráficos de Perda de Pacotes e Descartados mostram a perda de pacotes ao longo do tempo e permitem que você se concentre em períodos específicos. Esses gráficos são úteis para identificar se a perda de pacotes está ocorrendo e quando ocorreu no passado. Além disso, você pode identificar o tipo de perda de pacotes: perda do provedor ou Cato descartado.

Nota: O menor tamanho de amostra de bucket de dados nos gráficos de Análise é de 5 segundos. Como resultado, uma micro-rajada dentro de 5ms será normalizada dentro das médias exibidas e não será mostrada como um pico no gráfico de análise.

1. Perda do provedor

Este é um exemplo de perda de pacotes entre o Socket e o PoP. Embora a maioria das perdas de pacotes do provedor seja causada por questões de conectividade na última milha fora do controle da Cato, isso não necessariamente exclui um problema relacionado à Cato.

Como a Cato Mede a Perda do Provedor 

A perda do provedor é medida comparando a quantidade de pacotes enviados e recebidos em um determinado link, tanto no Socket quanto no PoP.

• Perda de pacotes de tráfego recebido é a diferença entre o número de pacotes enviados pelo PoP e o número de pacotes recebidos pelo Socket, expressa em porcentagem.

Fórmula:

• Perda de pacotes de tráfego enviada é a diferença entre o número de pacotes enviados pelo Socket e o número de pacotes recebidos pelo PoP, expressa em porcentagem.

Fórmula:

A maneira como a Cato calcula a perda de pacotes do provedor significa que, por mais fácil que seja, você não pode culpar imediatamente o ISP. É possível que você tenha equipamento entre o Socket e o roteador do ISP que contribua para a perda de pacotes, ou pode haver problemas com o caminho de rede mais próximo do PoP que está além do controle do ISP.

2. Cato descartado

A perda de pacotes descartada pela Cato é causada pelo Cato QoS. O motor de QoS começa a descartar pacotes de baixa prioridade quando um link está congestionado e em qualquer prioridade durante rajadas de tráfego. O congestionamento ocorre quando o throughput total de um link corresponde à largura de banda configurada para o link. Cato também descarta pacotes se uma prioridade de gerenciamento de largura de banda for configurada com um limite rígido de throughput e o tráfego correspondente à prioridade atingir o limite. A perda de pacotes descartada pela Cato é um comportamento esperado e não necessariamente um sinal de problema.

Qualquer problema relacionado à perda de pacotes descartados pela Cato provavelmente é causado por uma configuração incorreta. Aplicações críticas, como VoIP, devem ter a mais alta prioridade de gerenciamento de largura de banda. Se ocorrer congestionamento, o tráfego de baixa prioridade é descartado pela Cato, mas o tráfego de alta prioridade não é descartado. Sempre certifique-se de que as prioridades de gerenciamento de largura de banda apropriadas sejam atribuídas ao tráfego.

As Análises fornecem uma visão ampla da perda de pacotes. No entanto, a menos que você esteja lidando com a perda de pacotes descartada pela Cato, somente as análises não podem lhe dizer o que está causando a perda de pacotes ou onde a perda de pacotes está ocorrendo. 

Como Resolver a Perda de Pacotes

1. Determinando o Escopo da Perda de Pacotes

Quando você começa, é realmente importante descobrir quem ou o que está sofrendo perda de pacotes. Todos os usuários estão experimentando perda de pacotes em um site, ou está isolado a um único ponto final? A perda de pacotes ocorre na Internet ou na WAN? Múltiplos sites são afetados pela perda de pacotes ou apenas um? Todo o tráfego é afetado ou é apenas uma certa aplicação? A perda de pacotes é constante ou ocorre apenas de forma intermitente?

Saber as respostas para as perguntas acima pode ajudar você a identificar eventos CMA relacionados e economizar tempo durante o processo de troubleshooting. Quanto mais detalhes você souber com antecedência, mais focado poderá ser o seu troubleshooting.

2. Verificando Análises do Site - Gráfico de Perda de Pacotes

A perda de pacotes está sendo exibida no gráfico de perda de pacotes das Análises do site? Temos diferentes recomendações baseadas em Análises gráficas que podem mostrar perda de pacotes e pacotes descartados.

Nenhuma Perda de Pacotes

É possível existir perda de pacotes sem que nenhuma perda de pacotes seja exibida na tela de Análises. Pode haver um problema na rede local, ou pode ser um problema relacionado ao PoP. Usar a Ferramenta de Rede para pingar um IP do lado LAN a partir do Socket pode ser uma boa forma de identificar a causa raiz.

Perda de Pacotes

Se a perda de pacotes for mostrada no gráfico, pode ser causada por uma configuração incorreta de Largura de Banda. Por favor, verifique a largura de banda configurada conforme descrito abaixo em Verificando a Configuração de Largura de Banda.

Para perda de pacotes do Provedor, verifique se os descartes ocorrem apenas quando há picos de tráfego (explosões). Se for esse o caso, identifique o tráfego que está causando as explosões usando a página de Análise de Aplicações. Você pode limitar o tráfego da aplicação atribuindo-o a um perfil de gerenciamento de Largura de Banda restritivo.

Frequentemente, veremos casos em que a Vazão é geralmente baixa, mas os picos de explosão causam perda de pacotes. Precisamos levar em consideração que o ISP tem sua própria política de conformação de tráfego, e, nesse caso, é provável que a política do ISP e a política de conformação de tráfego da Cato tenham diferentes políticas de explosão. Para mais informações sobre explosividade, veja abaixo Verificando micro-explosões

3. Verificando a Análise do Site - Gráfico de Pacotes Descartados

Para pacotes descartados pela Cato, você também deve investigar as prioridades de Largura de Banda. Verifique o Analisador de Prioridade na tela de Análise do site para ver qual prioridade está sendo descartada. Você pode expandir a seção de prioridade para mostrar os principais aplicativos nessa prioridade. Se a perda de pacotes afeta apenas uma aplicação específica, pode ser necessário aumentar a prioridade dessa aplicação nas Regras de Rede. Lembre-se, o QoS da Cato é projetado para descartar pacotes de baixa prioridade quando ocorre congestionamento, então a perda de pacotes descartada pela Cato nem sempre é um problema.

O QoS da Cato também pode descartar qualquer pacote, independentemente da prioridade, devido a explosões nessa fila. Este comportamento também é esperado devido à natureza da gestão de explosões. A página do Analisador de Prioridades pode ser usada para identificar se os picos de tráfego ocorrem ao mesmo tempo em que os pacotes foram descartados. Para mais informações, veja Priorização de Tráfego no Socket e QoS.

O Analisador de Prioridades na tela de Análises mostra perda de pacotes nas direções de Tráfego Recebido e Enviada para cada prioridade de QoS.

4. (Opcional) Monitoramento de Experiência na Última Milha

Clientes com licença de Monitoramento de Experiência podem verificar as abas Última Milha e Desempenho das Aplicações para possíveis perdas de pacotes e descartes de pacotes. Os dados podem ser correlacionados com as descobertas na página de análise da rede do site para entender melhor de onde se origina o problema.

5. Verificando a Análise do Site - Perda de Pacotes da Última Milha

Para avaliar se o ISP está enfrentando problemas, use a aba Última Milha na tela de Análises para verificar qualquer alteração de latência ou perda de pacotes que apareçam no link WAN. Ao contrário da perda de pacotes do provedor, os dados da última milha são baseados em testes ICMP para sites populares. Como recomendação, IPs de serviço adicionais que são pingáveis podem ser adicionados à página de Monitoramento da Última Milha. Por exemplo, se houver problemas relacionados à VoIP, o IP do servidor SIP pode ser configurado como um dos IPs.

Se for suspeito de perda de pacotes relacionada ao ISP, pergunte ao seu ISP as seguintes perguntas:

1. Você está aplicando QoS no tráfego UDP/443 ou UDP/1337 (DTLS)?
2. Você aplica alguma proteção DoS no tráfego UDP que pode estar causando perda de pacotes para o IP do PoP?
3. Há congestionamento ou alta CPU nos seus roteadores no caminho para o IP do PoP?
4. Você permite explosões acima da taxa de linha assinada?

6. Verificando a Configuração de Largura de Banda

A perda de pacotes pode ser causada por congestionamento de link, e é importante que a largura de banda para cada link WAN seja configurada corretamente no Aplicativo de Gerenciamento Cato. Certifique-se de que a largura de banda configurada corresponda ao que o ISP fornece na configuração do site. Configure a configuração de largura de banda da interface WAN do Socket de acordo com os termos da licença do site da Cato.

Ambientes Azure/AWS não têm limitações tradicionais de largura de banda. Em vez disso, a largura de banda configurada no site nunca deve exceder a largura de banda suportada para o vSocket. Para Azure, a partir da versão 21, o tamanho de VM Standard_D8ls_v5 suporta até 2Gbps. Na AWS, o tamanho da instância c5n.xlarge fornece largura de banda superior a 2Gbps. É importante garantir que a largura de banda configurada do site permaneça dentro dos limites suportados para um desempenho ideal.

Se a largura de banda configurada for menor do que a fornecida pelo ISP, o motor de QoS da Cato pode começar a descartar pacotes quando o limite de largura de banda configurado for excedido. Se for esse o caso, haverá uma linha reta no gráfico de throughput do Analytics do site igual à largura de banda configurada do site, juntamente com pacotes descartados pela Cato.

Esse mesmo comportamento pode ocorrer se a largura de banda estiver configurada corretamente, mas o link do ISP estiver congestionado. Embora esse comportamento não garanta um problema, é uma boa prática confirmar que a largura de banda está configurada corretamente nesta situação.

Se a largura de banda configurada for maior do que a fornecida pelo ISP, o motor de QoS da Cato não entra em ação quando o limite de largura de banda do ISP é excedido e, portanto, o ISP pode começar a descartar pacotes aleatoriamente. Se for esse o caso, você verá uma linha reta no gráfico de throughput do site no Analytics abaixo do nível da largura de banda configurada, juntamente com a perda de pacotes do provedor.

As informações sobre throughput e capacidade de Socket para cada modelo de Socket estão disponíveis na ficha técnica do Socket, consulte este artigo: Guias de Socket X1700, X1600 & X1500.

7. Verificar o desempenho da CPU do Socket

Na Interface Web do Socket, selecione a aba Status de HW. Isso mostrará o uso atual de CPU % para cada núcleo. Uma utilização consistente da CPU acima de 90% impactará diretamente o desempenho do socket e causará perda de pacotes e alta latência. Se uma alta CPU constante for observada enquanto ocorre perda de pacotes na rede, por favor Contate o Suporte. 

8. Eliminando Reconexões de Sites

Reconexões de Sites à Nuvem da Cato são uma fonte de perda de pacotes. Verifique Inicial > Eventos para ver se a perda de pacotes se correlaciona com eventos de reconexão. Filtrar eventos como sub-tipo = 'reconectado'.

Os eventos de reconexão exibirão uma mensagem explicando o motivo das desconexões. Consulte Compreendendo Eventos Reconectados

9. Ignorando Cato

Para perda de pacotes na Internet, configure um bypass de origem ou destino para rapidamente descartar um problema com a Nuvem da Cato. A maneira mais fácil de fazer isso é configurar um bypass de origem para o endereço IP de um único usuário na configuração do site e ver se a perda de pacotes continua. Se a perda de pacotes continuar, o problema pode estar na LAN, no Socket ou no ISP, mas o problema não estaria relacionado a um PoP.

10. Executando testes de Ping

Inicie um ping contínuo entre um endereço IP de origem e destino afetado por perda de pacotes. Os pings são mais fáceis de rastrear e podem ser analisados em capturas de pacotes. Quando algumas das solicitações de ping não chegam ao destino, você provavelmente está enfrentando perda de pacotes e isso será mostrado como tempo de espera esgotado para a solicitação.

A UI do Socket também permite que você pingue por nome do host ou IP com a ferramenta de ping. Você pode selecionar a interface para enviar o ping, seja através da Cato ou diretamente pelo link WAN. Procure qualquer inconsistência nos resultados do ping, como perda de pacotes ou alta latência. Se a perda de pacotes estiver presente com e sem o uso da Cato, isso pode indicar um problema com o ISP. Além disso, se um dos links for 4G/LTE, você deve lembrar que esses links são mais sensíveis à perda de pacotes.

A UI só envia 10 solicitações de ping, então se você precisar de mais pings, será necessário clicar novamente no botão Ping. 

Nota: Os testes de ping são bons para verificar a saúde básica da rede, mas a ausência de quedas de ping não indica necessariamente uma linha limpa.

11. Executando testes de Rastreamento de rota

Rastreamento de rota é usado para identificar os roteadores (saltos) entre uma origem e um destino. Ele exibirá perda de pacotes e latência para cada um dos saltos.

O Rastreamento de rota pode ser executado pela UI do Socket com a ferramenta de Rastreamento de rota. Execute o Rastreamento de rota para encontrar qualquer perda de pacotes ou latência inesperadamente alta em qualquer um dos saltos sobre o Link WAN entre o Socket e o Destino. A IU só envia um pacote para cada salto e mostra a perda de pacotes para cada salto. Como há apenas um pacote sendo enviado, você só verá perda de 0% ou 100%.

Análise de resultados de Rastreamento de rota

Esteja ciente de que a perda de pacotes mostrada em qualquer salto individual não é necessariamente um sinal de problema. Um único salto pode mostrar uma perda de pacotes de 100% simplesmente porque o ICMP não está ativado no roteador. Um salto também pode mostrar menos de 100% de perda de pacotes sem que haja um problema devido à limitação de taxa ICMP. Se você observar alguma perda de pacotes em um salto e 0% de perda de pacotes no próximo salto, é provável que esteja presenciando uma limitação de taxa ICMP.

Se houver um problema real com a perda de pacotes, ele começará em um salto e continuará por múltiplos saltos, com cada salto mostrando perda de pacotes.. Também é possível que múltiplos roteadores em um caminho estejam contribuindo para a perda de pacotes, portanto, a quantidade de perda de pacotes pode variar em cada salto. Por exemplo, há oito saltos na rota e o Rastreamento de Rota mostra perda de pacotes para os saltos 3-7.

12. Gerando alta carga de tráfego para detectar perda de pacotes

A tela Tempo Real pode ajudar a detectar quaisquer mudanças de vazão atuais para identificar perda de pacotes imediata e pacotes descartados. Use a ferramenta de teste de velocidade do Socket para simular alta carga e reproduzir perda de pacotes devido à alta demanda durante a solução de problemas.

É esperado que os resultados do Speedtest do Socket via Cato estejam próximos à Largura de Banda configurada para o Link no Aplicativo de Gerenciamento Cato. Esteja ciente de que a sobrecarga do túnel DTLS (117 bytes) pode reduzir ligeiramente a vazão. 

O teste irá saturar o link e mostrar qualquer perda de pacotes relacionada ao ISP na tela de Análise de Rede. Pacotes descartados são esperados ao executar o teste se a Largura de Banda configurada do link for menor que a Largura de Banda fornecida pelo ISP.

Teste de Velocidade Direto 

Ao executar o Speedtest diretamente via porta WAN, o resultado upstream deve estar próximo à Licença de Largura de Banda configurada no Aplicativo de Gerenciamento Cato. O Socket ainda usará QoS para o teste de velocidade direto upstream conforme a Licença de Largura de Banda do site. Por outro lado, o resultado downstream mostrará a capacidade total do ISP local.

13. Testando o link com iPerf

A Interface Web do Socket permite que você use a ferramenta iPerf para solucionar problemas de desempenho da última milha entre o Socket e o PoP Conectado na Cato Cloud. O Socket que está executando o cliente iPerf realiza o teste contra o servidor iPerf que está sendo executado no PoP Conectado.

Execute o teste iPerf via Cato e diretamente sobre o WAN na página de ferramentas da Interface do Socket. Selecione UDP como o protocolo (para descartar o controle de fluxo TCP), defina a direção (upstream ou downstream) e a taxa de destino como a Largura de Banda configurada. Esta ferramenta pode confirmar melhor que a vazão sobre Cato e sobre o WAN é como esperado. Esteja ciente de que a sobrecarga do túnel DTLS (117 bytes) pode reduzir ligeiramente a vazão. 

No exemplo abaixo estamos definindo 45Mbps como a taxa de destino (que é a mesma Largura de Banda configurada no Aplicativo de Gerenciamento Cato) e a taxa recebida é menor do que o esperado com uma perda de pacotes de 3,7%

14. Verificando Links de Agregação de Links (LAG)

Perda de pacotes e alta latência podem ser causadas por uma configuração incorreta de Link Aggregation (LAG) entre o Socket e um switch interno. Este problema específico não pode ser detectado na Análise de Rede, em vez disso, precisa ser resolvido dentro da LAN. Cato suporta apenas LAG estático e o par LAG deve suportar o mesmo modo. Incompatibilidades de configuração de LAG levarão à perda de pacotes.

Para mais informações de solução de problemas, consulte Link Aggregation (LAG) Link Experiencing High Latency and Packet Loss

15. Verificando a Velocidade do Link do Socket

Uma possível causa de perda do provedor é que um Link do Socket está operando em half duplex. Isso significa que os pacotes só podem viajar em uma direção (entrada ou saída) por vez, o que reduz drasticamente a vazão e resulta em perda de pacotes. Todos os links do Socket devem sempre estar em full-duplex sem exceção.

Além disso, certifique-se de que as velocidades de link WAN e LAN sejam iguais ou superiores à Largura de Banda configurada para um site. A velocidade do link pode ser o fator limitante para a vazão. Por exemplo, se a Largura de Banda configurada de um site for 200 Mbps mas o link LAN só negociou em 100 Mbps full-duplex, um computador conectado ao Socket não pode alcançar mais de 100 Mbps de vazão.

Para verificar o estado do link, faça login na Interface do Socket e veja o Estado do Link na página de Monitoramento. O exemplo abaixo mostra o link WAN1 em 100 Mbps half-duplex.

Se você notar um link em half-duplex ou configurado para a velocidade errada, verifique as configurações de porta no dispositivo ao qual o link do Socket está conectado. Certifique-se de que esteja configurado para auto-negociação ou que corresponda às configurações de velocidade do Socket. Todos os links do Socket têm como padrão a auto-negociação, mas você pode forçar a velocidade na página de Configurações de Rede.

Se as configurações de porta estiverem corretas no outro dispositivo, o cabo Ethernet pode estar danificado. Substitua o cabo por um que seja conhecido por funcionar e veja se o duplex ou a velocidade mudam. Se isso não funcionar, conecte um computador portátil ou outro dispositivo à porta do Socket e verifique o status do link. Faça o mesmo no outro dispositivo. Se o link do Socket aparecer na velocidade esperada e full-duplex, mas o link do outro dispositivo não, você saberá que o problema está no outro dispositivo.

16. Verificando endereços IP duplicados

Outro problema no nível do Socket que pode causar a perda de pacotes são os endereços IP duplicados na rede. O Socket geralmente pode detectar conflitos de IP com os seus endereços IP de interface configurados. Um conflito de IP existe quando dois dispositivos na mesma rede são atribuídos ao mesmo endereço IP. Se isso acontecer, você verá o erro abaixo na página de Monitor do Socket UI.

O endereço IP duplicado pode falhar em ser detectado quando um endereço IP estático é configurado na interface WAN, pois o Socket apenas monitora passivamente um conflito de IP. Ele detectará um conflito de IP somente se o Socket receber um ARP do dispositivo com o IP em conflito.

Uma vez resolvido o problema do IP em conflito, pode levar até 24 horas para que o aviso desapareça do WebUI. Consulte Conflito de Endereço IP Relatado na UI do Socket Mesmo Após a Resolução

17. Verificando micro explodimentos

Outra causa potencial de perda de pacotes são os micro explodimentos (estouro). Os micro explodimentos se caracterizam por um aumento repentino de pacotes ou quadros de dados que ocorrem em um período de tempo muito curto, normalmente durando apenas alguns microssegundos a milissegundos. Em situações em que micro explodimentos ocorrem e excedem o limite de taxa do link, o Provedor (ISP) pode descartar tráfego excessivo, resultando em perda de pacotes.

No gráfico abaixo, você pode ver um exemplo de perda de pacotes típicos causados por micro explodimentos e a melhoria após ajustar as configurações de valor de burstiness. 

No exemplo acima, o valor do nível de burstiness foi Modificado do valor Padrão de 0,2 para 0,01, o que significa que o Socket e o PoP aplicam uma modelagem mais Agressivo no Tráfego, resolvendo assim o problema de Perda de Pacotes.  

Ajustando configurações de nível de burstiness para mitigar a perda de pacotes

O valor padrão de burstiness aplicado para as direções upstream e downstream é 0,2. Com esse valor, o Socket e o PoP serializam os pacotes para a mídia o mais rápido possível, permitindo que mais bytes sejam enviados nos primeiros microssegundos do balde de período de tempo. Esta configuração otimiza o desempenho ao reduzir o atraso de serialização e a latência geral. 

Como parte deste processo de solução de problemas, você precisa reduzir gradualmente o nível de burstiness até que a perda de pacotes seja mitigada. À medida que você reduz o valor do nível de burstiness, o Socket e o PoP aplicam uma modelagem mais agressiva no tráfego, suavizando assim os micro explodimentos. O menor valor que você pode configurar é 0,001.

A melhor prática para ajustar o nível de burstiness é reduzir gradualmente o valor (por exemplo, de 0,2 para 0,18).  Depois de reduzir o valor, monitore o impacto analisando a perda de pacotes na tela de Monitoramento do Site Tempo Real ou Análise de Rede. Tenha em mente que as métricas do site geralmente demoram alguns minutos para serem atualizadas. Continue reduzindo o valor de burstiness até que a perda de pacotes seja mitigada. 

Se a perda de pacotes não for resolvida por este procedimento, significa que é causada por um motivo diferente de micro explodimentos.  Nesse caso, restaure o valor Padrão de burstiness de 0,2 e Contatar Suporte para mais assistência. 

Modificando o nível de Burstiness

O nível de burstiness pode ser ajustado para as direções upstream e downstream. Esta configuração afeta todos os links WAN do site. 

A configuração é aplicada a nível de site ou a nível de conta. A configuração ao nível de site tem precedência sobre a de nível de conta.

Para configurar o nível de Burstiness:

1. No menu de navegação, selecione Recursos > Configuração Avançada para nível de conta ou Configurações do Site > Configuração Avançada para configuração a nível de site.
   
2. Selecione valor de burstiness downstream ou valor de burstiness upstream.
3. Habilite a configuração e ajuste o valor entre a faixa de 0,001 - 0,2.
   
4. Clique em Aplicar
5. Clique em Salvar

Notas: 

• Se o burstiness foi previamente ajustado pelo Suporte Cato, o valor ajustado será mostrado em vez do valor padrão de 0,2
• Os valores de burstiness só podem ser ajustados para sites Socket
• O menor bucket de dados na Aplicação de Gerenciamento da Cato é 5 segundos, os micro explodimentos são normalizados dentro dos buckets de dados menores e geralmente são difíceis de identificar.