[caiu] Perda de pacotes passando pelo PTT-SP

Henrique de Moraes Holschuh henrique.holschuh em ima.sp.gov.br
Sexta Agosto 24 09:41:07 BRT 2012


On 24-08-2012 08:34, Fábio - RJ Network wrote:
> Fui prontamente atendido pelo Bruno da Central Server mesmo antes de
> abrir essa thread, e o problema foi resolvido, mas eu abri essa
> discussão justamente porque fiquei na dúvida de como diagnosticar
> isso precisamente. No traceroute de ida ocorria a perda no
> as262790.sp.ptt.br (187.16.217.85) e no traceroute sentido contrário
> ocorria a perda no as16735.sp.ptt.br(187.16.216.241).
>
> Se ocorrer esse problema com algum outro cliente, vou cair no mesmo
> ponto.
>
> Como posso identificar o que realmente está ocorrendo dentro do PTT?
> Aliás, é possível identificar isso precisamente? Pode ser gargalo?
> Pode ser problema físico? Em qual das conexões? Como consigo uma
> evidência?

Você precisa de diversos traceroutes de tipos diferentes (ICMP, etc) e
por caminhos diferentes para ter certeza.  Por exemplo, somando o meu
traceroute com o seu, a possibilidade de ser problema no AS16735 foi
descartada (pois tenho conexão direta com o PTT-SP, sem passar pelo
AS16735 apesar de coincidentemente, o AS16735 ser um dos meus upstreams).

Traceroute depende explicitamente de ICMP TTL exceeded, portanto está
*sempre* sujeito a três importantes fatores:

1. rate-limit de _geração_ de ICMP pelo roteador que tem que gerar o ICMP;

2. qual endereço o roteador irá utilizar para gerar esse ICMP (que pode
mudar drasticamente o que você vê no reverso, por exemplo);

3. caminho de retorno do ICMP (que pode gerar falso-positivo para perda
de pacotes.

Tipicamente, você precisa de, no mínimo, um traceroute bidirecional para
mitigar erros de interpretação causados por (2) e (3).  O ideal é ter
vários traceroutes que passam por caminhos de rede diversos para tentar
isolar a região mais provável de falha.

Você também tem que lembrar que problemas de perda de pacote em qualquer
direção perto da origem do traceroute vão falsificar todas as leituras
para os hops posteriores.

No caso do PTT, faça medidas bidirecionais, meça outros destinos para
ter certeza que não é problema no seu circuito ou provedor(es) upstream,
e faça medidas que não passam pelo PTT para atingir o alvo como forma de
verificar se o problema não é mais geral.  Depois disso, se necessário
peça outros traceroutes aqui na caiu, que é o motivo de existência da
lista para começo de história...

-- 
Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
IM@ - Informática de Municípios Associados
Engenharia de Telecomunicações
TEL +55-19-3755-6555/CEL +55-19-9293-9464

Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
e do custo que você pode evitar.


Mais detalhes sobre a lista de discussão caiu