Problemas de velocidade do site interno para VPN do site sobre MPLS?

Question

Como faço para solucionar problemas de desempenho lento de um site para o túnel VPN do site em um circuito MPLS? Quais são os relatórios / estatísticas relevantes que eu deveria estar observando?

Histórico: Eu suporto uma extremidade de um site para site VPN que é usado para conectar duas extremidades de uma rede de controle de processo (PCN). O PCN é separado da rede empresarial / corporativa por firewalls Juniper SRX / SSG que também fornecem os terminais VPN.

Originalmente, a rede comercial entre os sites estava conectada a uma conexão AT & GigaMAN, que, segundo entendi, é uma marca do Serviço Metro Ethernet. Um site era um sub-site do site principal (meu) e qualquer tráfego que precisasse ir para um site da empresa diferente do meu do sub-site passava pelo site principal antes de rotear para os outros sites da empresa. / p>

Devido em parte pelo custo e em parte pela confiabilidade adicional, o Metro Ethernet foi substituído por um circuito T3 vinculado à empresa MPLS no subsite. O site principal já estava no MPLS com o resto da empresa. Um dos usos para a VPN são transferências de arquivos agendadas entre sites e, desde a mudança para MPLS no subsite, teremos tempos de espera intermitentes para as transferências.

Eu não controlo a LAN ou a WAN da empresa, apenas o PCN, por isso tenho de trabalhar com outro grupo para encontrar a causa principal, mas não sei as perguntas certas a fazer.

    

Answer 1

Coisas que eu recomendaria ver:

• Puxe os logs de eventos das caixas do Juniper, especialmente procurando por gotas no túnel.
• Execute os logs de depuração nas caixas do Juniper, especialmente se os problemas forem consistentes o suficiente para que você possa fazer isso sem se preocupar com a sobreposição de logs ou problemas de desempenho durante a depuração.
• Obtenha todos os relatórios MPLS que mostrem perda de conectividade, utilização da largura de banda etc., o mais granular possível no período de tempo
• Faça alguns testes normais. Teste vários endpoints, tamanhos de arquivo, tamanhos de MTU, testes de QCheck, etc. em vários momentos do dia. Se você puder executá-los durante os problemas intermitentes, melhor ainda.
• Se puder ser reproduzido, mesmo diariamente, tente executar os endpoints com o log wireshark e, em seguida, analise esses logs.
• Experimente diferentes protocolos de transferência de arquivos. Veja se o problema é o próprio protocolo. O SMB é muito ruim em um túnel VPN. Tente FTP em seu lugar. Teste e colete resultados.

Realmente no geral, quanto mais pontos de dados e registros você conseguir reunir de vários ângulos, mais fácil será montar o quebra-cabeça.

    

Answer 2

Veja o MTU. Você está usando um valor grande o suficiente para causar fragmentação que, por sua vez, poderia resultar em atrasos. Imagine que o tamanho do seu pacote seja 5 bytes maior. Então dois fragmentos são enviados e o pequeno, apenas 5 bytes, chega primeiro. Então tem que esperar até que o apanhador se alcance antes da remontagem. E se os buffers transbordarem, você terá a clássica situação de caixa eletrônico em que um pequeno número de fragmentos perdidos causa muitas retransmissões de pacotes.

Faça alguns testes de ping com tamanhos de pacotes específicos, em particular use o tamanho da MTU e algo como MTU + 5. Calcule também a sobrecarga de encapsulamento (OVH) e use MTU - OVH e MTU - OVH + 5

Obtenha um relatório de distribuição de tamanho de pacote para ter uma ideia do tamanho médio do pacote e da forma de distribuição que você tem.