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

[Fábio Rodrigues Ribeiro]

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
>