[GTER] Problema de tráfego Adapt Link

Tue Nov 14 22:11:02 -02 2017

Gustavo, se entendi bem, você é um usuário final, logo não tem controle sobre as rotas, correto?

Bom, vamos então entender o que pode estar ocorrendo e se isso impacta você ou não, e se impacta o quanto.

Vamos agora entender o que são os IPs, se eles são de seu provedor ou não e se isso te afeta.

Via whois novamente, vejo um IP de seu provedor que responde externamente, 186.219.120.20, vamos fazer alguns testes.

Podemos começar encontrando os possiveis fornecedores dele: https://bgp.he.net/AS61890#_asinfo no caso Algar, Level3.

Vamos ver um traceroute de um provedor externo para ele.

http://www.isptools.com.br/traceroute#26!186.219.120.20 - Via G8, participante do IX.Br São Paulo.

Veja que o Salto 4 corresponde a um IP do IX SP, 187.16.217.90, esse mesmo IP é informado por seu provedor como sendo a interface dele https://www.peeringdb.com/asn/61890, logo o salto 5 (172.16.88.5) está dentro da rede dele.

http://www.isptools.com.br/traceroute#36!186.219.120.20 - Teste via Emmex participante do IX.Br Rio de Janeiro

Veja que o salto 3 também é do IX, mas dessa vez do Rio, 45.6.52.150, consultando aquele link do peeringdb você irá ver que seu provedor também diz ser dele, veja que o próximo salto após ele também é 172.16.88.5, ou seja esse IP novamente aparece na rede dele.

Até aqui não tem nada indicando que outros provedores estão no meio.

Você apresentou um traceroute para 8.23.24.100 (Riot), depois do salto 172.16.88.x, temos um salto em 104.160.152.103, que pertence a RIOT, ou seja, seu provedor parece entregar diretamente para ele em São Paulo, sem passar por mais ninguém. No mesmo traceroute vemos os IPs 10.131.246.X, esse carinha já está na rede da RIOT.

Já no outro traceroute para a Amazon 54.207.107.12, o salto 6 (as16509.saopaulo.sp.ix.br [187.16.218.79]) é um IP da Amazon em São Paulo, no IX SP, esse nome que você vê AS16509 é uma identificação para a Amazon, pode buscar no Google ;) Todos os IPs após também pertencem a Amazon. Seu provedor novamente entregou direto.

Agora que já observamos isso, podemos chegar a uma conclusão, os IPs 172.16.x.x que você vê nos traceroutes pertencem sim ao seu provedor, fazendo parte da rede dele e ninguém está entrando no meio. Provavelmente renumeraram a rede para começar a aplicar técnicas de CGNAT.

O fato deles passarem a usar esses IPs privados não causaria problemas para você, outro detalhe é que esses IPs muitas vezes aparecem pois o provedor não está descartando o pacote, no traceroute não há ping para cada ponto, mas sempre para o destino, apenas alterando o TTL, isso faz com que os roteadores no meio do caminho retornem um erro que conterá um dos IPs dele, em geral o menor da interface. Comprove você mesmo, faça o seguinte comando "ping -t 4 8.23.24.100", você verá ele respondendo 172.16.88.1 "time to live exceeded" ou parecido.

Ah, mas não vamos esquecer dos saltos perdidos. Isso ocorre por em algum lugar no meio do caminho, um firewall descartar esse tipo de pacote, costuma ocorrer no próprio roteador que deveria informar "time to live exceeded", alguns operadores acham melhor descartar. Mas isso não afeta nada. Até mesmo em um MTR, se o fim não tem mesma taxa de perdas ou aumento, no máximo o que você vê onde ele fala LOSS, são descartes, alguns operadores descartam para poupar o roteador.

Ok, entendemos muita coisa até agora de como isso tudo opera, falta entender que ele usar esses IPs não interfere em nada na sua casa, mas o ideal era que fizessem o uso do 100.64.0.0/10.

Agora entra um fato que poderia causar algum problema e qualquer provedor hoje terá o mesmo problema, o uso de CGNAT, bom IPv4 só esta sendo alocado para novos provedores, quem já tem IP não pode pedir mais (http://www.lacnic.net/agotamiento), então a palavra de ordem é economizar IP, ai surgiu uma técnica chamada CGNAT, que permite ao provedor dividir um único IP com vários clientes e assim permitir que seus clientes possam navegar na rede legada IPv4 durante o período de transição. O CGNAT sim pode gerar alguns probleminhas chatos, e seu provedor pode não ter culpa; Se ele já está entregando IPv6, você precisa cobrar dos prestadores de serviço (Jogos, Sites, E-mails, e afins) que passem a operar em IPv6, pois ai cada equipamento tem seu próprio IP e fala direto, sem ter problemas. Agora se seu provedor não entrega IPv6, ai sim, você precisa cobrar dele. No mais o CGNAT irá causar problemas com tudo que precise de direcionamento de portas (ou uPnP), tipo seu DVR quando você quiser acessar via internet, ou a PSN que ainda não suporta IPv6.

Se ainda assim você possui dúvidas, o SAC não consegue sana-las, recomendo contato com os endereços cadastrados no ASN deles, o de buse está setado para a RR64, essa empresa presta serviços para provedores, suporte at rr64.net e também há um contato de roteamento noc at adaptlink.com.br, tente explicar seu problema e dúvidas enviando um e-mail para ambos.

E desculpe ai o post longo. Caso alguém observe algum erro, por favor, me corrija.

_______________________________
Diego Canton de Brito

________________________________
De: gter <gter-bounces at eng.registro.br> em nome de Gustavo Leite de Souza <gustavo.1510 at hotmail.com>
Enviado: segunda-feira, 13 de novembro de 2017 21:20
Para: Grupo de Trabalho de Engenharia e Operacao de Redes
Assunto: [GTER] Problema de tráfego Adapt Link

Boa noite.
Estou com um problema na rota da minha conexão. Depois do dia 20/09 a minha rota começou a pegar IP's de outros provedores além do meu provedor e também dando uns saltos perdidos. Prejudicando não só a minha conexão, mas creio que também de outros provedores como também o tráfego de dados.
Meu provedor é Adapt Link e participa do projeto da IX.br. Estou enviando um tracert para ilustrar melhor o problema que estou passando.
Fui direcionado à solicitar ajuda de vocês para resolver o meu problema para que a minha rota só pegue IP's do meu provedor.
Se precisarem de algum documento ou arquivo me enviem um e-mail que estarei disponibilizando.

Boa semana!

---
Gustavo Leite de Souza