Por Tomas Lynch – Sênior Network Architect na Vultr
Como saber se um prefixo que estamos propagando desde diferentes pontos é considerada a melhor rota por outras redes? Vamos começar definindo que é ser a melhor rota para um prefixo. Para mim, e imagino que para todos, é a rota que tem menor tempo de resposta e zero perda de pacotes.
Se a rota for única, não há muito o que fazer, esta vai ser a melhor apesar de uma latência alta. Para uma rede propagada a partir de um único ponto, ou prefixo unicast, também não haverá muitas opções para escolher, embora existam mais opções. No entanto, a melhor rota para um prefixo propagado a partir de diferentes pontos, chamadas redes anycast, pode ser um grande desafio.
Este desafio surgiu desde o início da Internet. A Internet é uma rede topológica e não geográfica. Os pacotes para ir de uma cidade a outra geralmente não seguem os caminhos físicos mais curtos, mas são guiados por uma série de interconexões entre diferentes redes. Vejamos a seguinte imagem de um país imaginário chamado Carlandia.
(Acesso livre, não requer assinatura)
Embora as pessoas da Cidade D reclamem que os tempos de resposta para a Cidade C são duas vezes mais longos que para a Cidade A, Carlos II, rei de Carlandia, decidiu que o centro do poder estava na Cidade A e que todos os links da Internet deveriam passar por lá. Brincadeiras à parte, isso acontece muito dentro dos países reais, muito mais entre países e muito mais quando o fornecedor principal é, por sua vez, cliente de outros fornecedores. Se, além disso, levarmos em conta que usando diferentes atributos BGP uma rede pode decidir que a melhor rota para um prefixo anycast é aquela com o pior tempo de resposta, os problemas de latência tornam-se difíceis de resolver sem poder saber o que acontece do outro lado.
A apresentação “Medição de latência de prefixos Anycast com NLNOG Ring” que fiz no âmbito do LACNIC41, visa resolver estes problemas de rotas não ótimas e entender por que elas acontecem e como podemos influenciar na seleção de rotas em redes de terceiros. Para isso, apresentei uma ferramenta muito útil e aberta a todos os interessados, que é o projeto Ring de NLNOG.
Quantas vezes ligamos para amigos e colegas pedindo um teste de ping desde suas redes para um prefixo nosso para medir a latência? Quantas vezes desistimos de ligar para eles pensando que somos chatos? A ideia por trás do projeto Ring é muito simples: se você nos permitir acessar um servidor ou máquina virtual na sua rede, nós permitiremos que você acesse as nossas.
Embora as pessoas da Cidade D reclamem que os tempos de resposta para a Cidade C são duas vezes mais longos que para a Cidade A, Carlos II, rei de Carlandia, decidiu que o centro do poder estava na Cidade A e que todos os links da Internet deveriam passar por lá. Brincadeiras à parte, isso acontece muito dentro dos países reais, muito mais entre países e muito mais quando o fornecedor principal é, por sua vez, cliente de outros fornecedores. Se, além disso, levarmos em conta que usando diferentes atributos BGP uma rede pode decidir que a melhor rota para um prefixo anycast é aquela com o pior tempo de resposta, os problemas de latência tornam-se difíceis de resolver sem poder saber o que acontece do outro lado.
A apresentação “Medição de latência de prefixos Anycast com NLNOG Ring” que fiz no âmbito do LACNIC41, visa resolver estes problemas de rotas não ótimas e entender por que elas acontecem e como podemos influenciar na seleção de rotas em redes de terceiros. Para isso, apresentei uma ferramenta muito útil e aberta a todos os interessados, que é o projeto Ring de NLNOG.
Quantas vezes ligamos para amigos e colegas pedindo um teste de ping desde suas redes para um prefixo nosso para medir a latência? Quantas vezes desistimos de ligar para eles pensando que somos chatos? A ideia por trás do projeto Ring é muito simples: se você nos permitir acessar um servidor ou máquina virtual na sua rede, nós permitiremos que você acesse as nossas.
Teremos acesso de root a essas máquinas e poderemos realizar todo tipo de testes: ping, mtr, ssh, scp, etc. como se estivéssemos fazendo isso desde uma máquina própria. Também temos a capacidade de gerar comandos simples a partir de um conjunto de máquinas, bem como desde todas elas. A seguir, vemos um exemplo de um ping desde 10 máquinas membros de Ring para um prefixo anycast simulado:
O comando ring-ping é usado para gerar pings desde diferentes máquinas para um IP específico. Neste caso, o ping é gerado em 10 máquinas aleatórias para 2001:db8::1. Dependendo da presença que tenha em cada país posso dizer se a latência é adequada. Por exemplo, se não tivesse presença na Dinamarca, mas sim em algum lugar da Europa, 10 milissegundos de latência seriam apropriados. Do outro lado, se tivesse presença na Austrália, dependendo da cidade, esses 36 milissegundos poderiam ser um alarme e aí eu teria que ver como o AS136557 chega ao meu DNS. Isso pode ser feito simplesmente acessando a máquina “hostuniversal07” e fazendo um mtr para endereços de meus prefixos anycast.
Quer dizer, o projeto Ring nos permite ver abertamente como outras redes chegam aos prefixos que propagamos para a Internet, ajudando assim a melhorar o desempenho da nossa rede. Até as ferramentas de RIPE Atlas são instaladas em todos os nós RING, combinando as funcionalidades de ambas as plataformas. Hoje o projeto conta com mais de 500 organizações com diferentes sistemas autônomos em mais de 60 países.
Mas… Há sempre um mas, o número de máquinas da região LACNIC que participam do projeto é muito baixo até o momento. Apenas 15 máquinas das mais de 600 que fazem parte do projeto Ring estão na região. É por isso que aproveito para convidá-los a participar deste projeto. Basta prover uma máquina, que pode ser virtual, para acessar a uma ferramenta extremamente útil e com ampla distribuição geográfica. Para participar deste projeto e ler mais detalhadamente os requisitos e participantes, convido vocês a acessarem https://ring.nlnog.net/.
