Como interpreto a perda de pacotes identificada pelo WinMTR?

1

Fui solicitado a analisar um problema de perda de pacotes que um consultor anterior identificou em um cliente. Eles têm duas conexões ADSLMax, uma para dados e outra dedicada ao VoIP. A perda de pacotes está causando problemas para chamadas VoIP, mas meu primeiro esforço foi executar o WinMTR pela conexão data para me fornecer um quadro de referência antes de testar a linha VoIP.

Eu achei os resultados interessantes, apesar de não saber como interpretá-los. Em ambos os casos, 10.5.4.1 é um gateway do Linux, 10.5.4.254 é o roteador ADSL e 212.74.102.14 é o gateway no final do ISP. Minha primeira corrida foi produzida:

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                                10.5.4.1 -   10 | 1215 | 1094 | -24901298 | 2353567 | 24901342 | 24901342 |
|                              10.5.4.254 -    0 | 2149 | 2149 | -24901307 | 222826 | 24899947 |    0 |
|                           212.74.102.14 -    0 | 2138 | 2138 | -24901309 | 1904058 | 24901369 |   30 |
|________________________________________________|______|______|______|______|______|______|

Para minha segunda execução, cortei o gateway Linux alterando o endereço do gateway para 10.5.4.254 (o roteador de dados):

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                              10.5.4.254 -    0 |  955 |  955 | -24896677 | 3722073 | 24896756 |    0 |
|                           212.74.102.14 -    0 |  821 |  821 | -24896534 | 2222737 | 24896284 | -297383 |
|________________________________________________|______|______|______|______|______|______|

Perguntei ao consultor por sua interpretação dos testes e ele disse:

The linux box just doesn't actually route internet traffic, it is the default route to make routing across VPNs easier but it does an ICMP redirect to the actual router for most traffic.

ICMP is not always representative of packet loss except for end-to-end where the both ends are under your control. Intermediate routers often throttle ICMP echo responses.

Essencialmente, ele acredita que a perda de pacotes está ocorrendo na linha ADSL depois que ele sai do roteador, mas sua resposta à minha pergunta "O teste que você fez para medir a perda de pacotes - é apenas nos logs do Asterisk ou você usou uma ferramenta para medir isso? " foi:

I don't remember - it was several years ago.

Minha pergunta é se essa é uma interpretação útil dos dados ou se identifiquei um possível problema que poderia ser solucionado ao consertar o gateway ao nosso alcance.

Por favor, note que eu não estou tentando denegrir ou lançar asperezas sobre o consultor ou suas habilidades - muito do trabalho que ele fez para este cliente não foi pago (é uma instituição de caridade). Eu só estou esperando para obter uma segunda opinião especialista: -)

    
por Jack Douglas 14.02.2012 / 11:06

1 resposta

3
Basicamente, ele está certo sobre as propriedades dos pacotes ICMP descartados, embora seja um tanto atípico ver dropouts em uma máquina Linux local - especialmente na faixa de 10%. Você deve usar outro host Linux e executar um ping -f 10.5.4.1 para verificar se pode haver um problema de conectividade local. Se você vir perdas dentro da mesma magnitude, faça um iperf correr contra esta máquina para ver se ela afetaria outros protocolos (isto é, TCP e UDP) também.

As estatísticas do WinMTR indicam que a conexão está bem - as solicitações de eco para 212.74.102.14 tiveram 100% de respostas. Se os dados de VoIP estão passando a VPN através do 10.5.4.1 e este mesmo hospedeiro tem problemas de conectividade local por qualquer razão, esta seria a causa provável para seus dropouts de VoIP.

    
por 14.02.2012 / 11:18