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

Sun Jan 14 18:55:56 -02 2018

Reforço a solicitação inicial do Ayub sobre um contato com o pessoal que 
gerencia o AS28573. Ao menos para verificar se esta mudança (de não mais 
eleger o que é anunciado no IX-CAS - e possivelmente outros) foi 
deliberada ou se foi apenas uma manutenção que esqueceram de voltar ao 
normal.

Antes haviam algumas rotas nacionais muito melhores saindo pelo IX-CAS e 
hoje tenho visto ocasiões aonde o pacote da aquela voltinha em Miami.

Fernando Frediani

On 14/01/2018 01:02, Fábio Rodrigues Ribeiro wrote:
> 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
>>
>
> -- 
> gter list    https://eng.registro.br/mailman/listinfo/gter