[GTER] NET Virtua (AS28573) não tem aprendido rotas pelo ATM do de cas.ptt.br

[Fábio Rodrigues Ribeiro]

Olá, boa noite!

Recordei, no histórico da lista, como verificar se o DNS está resolvendo
corretamente.

Usando o nslookup:

nslookup whoami.akamai.net 8.8.8.8

ou usando EDNS:

nslookup -q=txt o-o.myaddr.l.google.com 8.8.4.4

Dica do Diego Canton de Brito, sobre o assunto DNS POISONING do Virtua.
Na época estava na Vivo, hoje estou no Virtua! Então testarei a
qualidade das entradas DNS.

Em 09-Jan-18 13:18, THIAGO AYUB escreveu:
> Olá Fabio,
> 
> 
> O GeoIP do cliente não conta. Note que antes da conexão TCP ser
> estabelecida entre o usuário e o edge da CDN, o que ocorre é a resolução de
> DNS. E o que a CDN tem como saber é o IP do DNS resolver, quem perguntou ao
> DNS autoritativo a resolução de DNS. Quando o IP do endpoint é conhecido,
> essa eleição já foi feita. Ainda haveria a oportunidade de uma vez
> conhecido, fazer um HTTP 302 para um FQDN com IP único de um edge mais
> próximo, mas isso aumentaria o tempo do início da entrega do conteúdo (o
> que para web apps é muito incômodo).
> 
> Talvez em algumas aplicações proprietárias alguém lance mão desse recurso
> de usar o GeoIP do usuário mas nunca o vi. Nunca um content provider nos
> procurou dizendo que faria isso. A decisão de qual edge de uma CDN entrega
> o conteúdo ainda é baseado na esmagadora maioria dos casos na resolução de
> DNS e por esse motivo, pensando em performance, ainda é importante usar o
> DNS resolver do ISP em vez dos serviços gratuitos como Google DNS e Open
> DNS.
> 
> Agora a forma de saber a eleição de edge mais precisa é você fazer ver qual
> é o IP que resolve o FQDN que entregou o conteúdo (ex.:
> images.nomedosite.com.br) e traçar rota para esse IP para tentar inferir se
> ele está próximo ou longe.
> 
> Abraços,
> 
> 
> 
> 
> *T. Ayub* | Chief Technology Officer
> 
> T.  +55 11 2626 3952 <+55%2011%202626-3952>
> 
> www.upx.com
> 
> Em 8 de janeiro de 2018 23:39, Fábio Rodrigues Ribeiro <
> listas at farribeiro.com.br> escreveu:
> 
>> Olá, boa noite
>>
>> Obrigado! Desconhecia a forma de eleição, como explicou, dos CDNs.
>> Acreditava que era melhor usar o DNS do provedor pois a reescrita da
>> entrada (ou mascarando pacotes) da caixa apontando para o que está dentro
>> do provedor. E o GEO do IP do cliente não conta?
>>
>> Sobre o que imaginei sobre a eleição usando GPS, talvez seria possível,
>> mas a nível de aplicação, embora nem o mais perto é o que entrega a menor
>> latência considerando a velocidade do link. Acredito que o IX mais próximo
>> de mim não é qual estou conectado, embora as telecoms daqui preferem
>> diretamente em SP, onde os big players se encontram lá, logo, são dois ou
>> mais saltos. Fora dar a volta no estado inteiro (pela fronteira, SJRP e
>> RIBEIRÃO), em vez de uma linha imaginária, cortando se no meio de fora a
>> fora.
>>
>> Não sei, até uns 3a atrás, a última milha de fibra em SP STATE era Ilha,
>> Araçatuba e Prudente. Cidades até a TRÊS LAGOAS era tudo por rádio. Agora é
>> saber se estão elegendo corretamente, se não como fazer correções em
>> entrada DNS recursivo?
>>
>> Em 08-Jan-18 17:24, THIAGO AYUB escreveu:
>>
>>> Olá Fábio,
>>>
>>>
>>> A esmagadora maioria das CDNs elege o edge para entregar o conteúdo a
>>> partir da consulta de DNS, ou seja, a geolocalização do IP do DNS resolver
>>> importa. É o caso da nossa CDN UPX. Se o DNS resolver estiver nos EUA, os
>>> endereços IPv4 e IPv6 da resposta de DNS corresponderão a um servidor nos
>>> EUA. Isso se torna complicado quando se usa Google DNS ou outros DNS
>>> resolvers abertos como o da Level 3, pois atrapalha a eleição de edges e
>>> torna o conteúdo das CDNs mais lentos, o que é explicado nesse vídeo [0] e
>>> na própria documentação oficial do Google DNS [1]. Esse é um dos motivos
>>> de
>>> o uso de Open DNS e Google DNS não ser recomendável na minha avaliação.
>>>
>>> Tanto o Google DNS como o Open DNS implementaram um recurso adicional que
>>> ao fazer a consulta no DNS autoritativo, eles dizem qual é parte do
>>> prefixo
>>> do real solicitado para ajudar as CDNs a não acharem que todos os usuários
>>> deste serviço estão nos EUA mas vale lembrar que o mundo não é feito só de
>>> Akamai, Google e outras gigantes. A maioria das CDNs não suporta este
>>> recurso e a penalização na performance será sentida.
>>>
>>> Outra técnica mas bem mais rara é o uso de BGP Anycast. Neste caso, não é
>>> a
>>> geografia que pesa e sim a telegeografia (ex.: ASPATH, rotas conhecidas
>>> por
>>> route servers em internet exchanges). CDNs que operam o próprio backbone
>>> são as que conseguem fazer melhor uso desta modalidade.
>>>
>>> Nunca encontrei qualquer outra técnica além destas, nada sequer parecido
>>> pelo uso de geolocalização do dispositivo como você imaginou. Apesar de
>>> interessante num primeiro olhar, note que o fato de dois pontos estarem
>>> geograficamente próximos não significa que eles estão conectados. Muitos
>>> sistemas autônomos presentes na mesma cidade seja diretamente ou através
>>> de
>>> seus upstreams se encontram em São Paulo para só então o tráfego voltar a
>>> suas cidades. Por esse motivo, a conectividade, o mapa da internet pesa
>>> mais na performance que o mapa geográfico.
>>>
>>> Para as CDNs de aluguel (como a nossa), que estão à disposição de qualquer
>>> dono de conteúdo, a distribuição dos edges leva em conta este tipo de
>>> critério. É uma pena ainda encontrar RFPs e licitações públicas que tomem
>>> como único critério o número de cidades com edges presentes. Uma CDN com
>>> uma lista menor porém melhor conectada proporcionará melhor performance.
>>>
>>> Links:
>>>
>>> [0] https://www.youtube.com/watch?v=h_o7zeKMab
>>> [1]
>>> https://developers.google.com/speed/public-dns/faq?authuser=
>>> 1&pageId=106568075635932514862#cdn
>>>
>>>
>>> Abraços,
>>>
>>>
>>>
>>>
>>> *T. Ayub* | Chief Technology Officer
>>>
>>> T.  +55 11 2626 3952 <+55%2011%202626-3952>
>>>
>>> www.upx.com
>>>
>>> Em 8 de janeiro de 2018 14:43, Fábio Rodrigues Ribeiro <
>>> listas at farribeiro.com.br> escreveu:
>>>
>>> Olá boa tarde
>>>>
>>>> Em 26-Dec-17 15:43, THIAGO AYUB escreveu:
>>>>
>>>> Olá,
>>>>>
>>>>>
>>>>> Tenho observado há pelo menos 3 meses que o NET Virtua não tem aprendido
>>>>> rotas anunciadas no ATM do IX.br de Campinas/SP. Isso tem sido um
>>>>> problema
>>>>> principalmente para IPv6 pois a adjacência entre a hoje Claro (AS4230 -
>>>>> na
>>>>> prática único upstream do Virtua) e a Hurricane Eletric (AS6939, maior
>>>>> Tier-1 em IPv6) se dá somente nos Estados Unidos.
>>>>>
>>>>> Como consequências, rotas IPv6 entre clientes NET Virtua e dos demais
>>>>> ISPs
>>>>> e CDNs poderiam ter latência nacional enquanto têm internacional. Até
>>>>> pouco
>>>>>
>>>>>
>>>> É uma dúvida bem genérica:
>>>>
>>>> Como saber/forçar/determinar os dispositivos* buscarem os CDNs
>>>> corretamente? Será resolve com um recursivo. Existe como refazer a
>>>> localização, embora correta, e já vi casos onde o geo era uma locura como
>>>> cliente final? Mesmo com GPS do celular?
>>>>
>>>> E como poderei checar se os pacotes estão sendo roteado/destinados como
>>>> deveria ser. E sem dar uma voltinha nos EUA.
>>>>
>>>> * acredito que são os apps/browser que determina qual será o CDN de
>>>> destino, por (geo ou latência/jitter), entretanto, a resposta do
>>>> DNS/pacote
>>>> pode traduzida para que o AS determinou, mascarando destinatário correto
>>>>
>>>> tempo atrás, nas cidades em que empiricamente apurei, o NET Virtua tinha
>>>>
>>>>> uma rota default para o AS4230 e aprendia todas as rotas do ATM.
>>>>>
>>>>> Isso significaria uma mudança na política de roteamento do Virtua? Mais
>>>>> alguém nesta ou em outra praça tem observado problema similar? Algum
>>>>> profissional de BGP do NET Virtua poderia entrar em contato para
>>>>> demonstrarmos o problema e auxiliarmos na melhoria dos serviços que a
>>>>> NET
>>>>> Virtua presta aos seus clientes?
>>>>>
>>>>>
>>>>> Atenciosamente,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *T. Ayub* | Chief Technology Officer
>>>>>
>>>>> T.  +55 11 2626 3952 <+55%2011%202626-3952>
>>>>>
>>>>> www.upx.com
>>>>> --
>>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>>>
>>>>>
>>>>> --
>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>>
>>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>>
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>