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

rafael at rafaelduarte.eti.br rafael at rafaelduarte.eti.br
Tue Jan 16 12:26:42 -02 2018 

Pessoal, aproveitando o assunto, algum provedor da lista conseguiu realizar acordo de troca de trafego com o AS da NET na própria cidade onde atua?

Att

Rafael Agostinho Duarte
Diretor
PRISMA REDE TELECOMUNICAÇÕES LTDA.
Tel.: 55 (18) 3303-0106
Cel.: 55 (18) 99149-7767
rafael at prismarede.com.br 
www.prismarede.com.br




-----Mensagem original-----
De: gter [mailto:gter-bounces at eng.registro.br] Em nome de Fábio Rodrigues Ribeiro
Enviada em: terça-feira, 16 de janeiro de 2018 11:11
Para: gter at eng.registro.br
Assunto: Re: [GTER] NET Virtua (AS28573) não tem aprendido rotas pelo ATM do de cas.ptt.br

Olá

Foi uma dúvida que pedi para esclarecer... e fui prontamente atendido.
Era a respeito do como eles eleição e decidir o roteamento para as CDNS

E possivelmente a interferência no processo decisório, tanto para o ISP ou cliente.

Abraços.

Em 14-Jan-18 18:55, Fernando Frediani escreveu:
> 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
> 
> -- 
> gter list    https://eng.registro.br/mailman/listinfo/gter

--
gter list    https://eng.registro.br/mailman/listinfo/gter

More information about the gter mailing list