Módulo 5: Pontos de Troca de Trafego(PTTs)

Conceitos Gerais : Arquiteturas de PTTs

Existem basicamente dois tipos de Pontos de Troca de Tráfego. Cada um deles apresenta pontos positivos e negativos, privilegiando de forma mais ou menos satisfatória aspectos como gerência, centralização de anúncio de rotas, segurança e o nível de intervenção da equipe de administração de um PTT. Independente do tipo de PTT, o que é comum é que os participantes devem ser sistemas autônomos e devem ter um roteador que possa suportar o protocolo BGP. Os roteadores de cada participante são interligados por um Switch com portas de alta velocidade Ethernet ou Gigabit Ethernet, que forma uma rede local onde cada participantes recebe um IP para endereçar sua interface com o PTT. Na maioria dos casos é utilizado endereçamento válido, geralmente um bloco classe C (/24).

O primeiro que será apresentado possui uma estrutura que é apresentada na Figura 2.

Figura 2 - Exemplo de PTT baseado em acordos bilaterais.

Neste tipo de PTT todos os participantes devem simplesmente estar na rede do PTT. Os acordos de troca de tráfego neste tipo de PTT são chamados bilaterais, ou seja, se determinado participante desejar trocar tráfego com um conjunto de ASs, este deverá estabelecer uma conexão BGP com cada um destes participantes diretamente. Neste caso, na entrada de um novo participante no PTT, se este desejar trocar tráfego com N participantes, N novas sessões BGP serão estabelecidas adicionalmente no PTT. Nesses casos não é necessária intervenção da equipe de suporte do PTT para estabelecer os acordos de peering, já que basta o contato entre os sistemas autônomos envolvidos no acordo. No protocolo BGP, podemos representar este tipo de PTT através da Figura 3, que representa alguns acordos bilaterais, tendo estabelecidas sessões BGP em linhas “hachuradas”. Esta figura demonstra a existência de acordos de troca de tráfego entre os ASs 1-5, 4-3 e 3-6;

Figura 3 - Exemplo de acordos bilaterais em PTT.

Outra arquitetura de PTT muito comum é baseada em Route Servers, sendo ilustrada na Figura 3.

Figura 4 - Ilustração de PTT baseado em acordos multilaterais.

Neste caso, além dos roteadores de cada participante, são utilizados dois PCs ou estações de trabalho com software que implementam o protocolo BGP e suas operações. Sendo assim, os dois computadores trabalham como centralizadores das rotas anunciadas pelos participantes do PTT. Todos os participantes não mais estabelecem sessões entre eles, mas estabelecem sessões BGP com os dois Route Servers. Neste caso são estabelecidos acordos de tráfego multilaterais (ATMs).

Na entrada de um novo participante no PTT, supondo que este tenha interesse em trocar tráfego com todos os demais participantes do PTT, serão necessárias apenas duas novas sessões BGP entre o novo participante e cada Route Server. A partir daí, sabendo que o Route Server trabalha como centralizador/distribuidor de rotas a todos participantes, o estabelecimento de duas sessões (uma para cada Route Server) já garante o recebimento dos anúncios dos demais participantes, evitando estabelecer sessões com cada um participante.

Dessa forma, a equipe de suporte do PTT deve ser acionada para estabelecer as novas sessões com os Route Servers, mas em compensação os demais participantes nada terão que fazer para iniciar a troca de tráfego com esse novo peer. Um ponto importante é que sendo o Route Server centralizador dos anúncios, este torna-se um ponto único de falha, podendo comprometer todo o PTT, caso apresente alguma falha. Neste caso adota-se a política de utilizar dois Route Servers, garantindo que na falha de um deles o outro possa manter o serviço sem interrupções. Também é aconselhável que sejam utilizados softwares diferentes em cada Route Server, evitando que um possível falha provoque a interrupção do serviço.

Os softwares utilizados para os Route Servers são diversos. Entre eles, citamos o Gated e Zebra. Estes dois softwares implementam, além do protocolo BGP, diversos protocolos de roteamento tais como RIP, OSPF, RIPv6, OSPFv6, entre outros. O software Gated é comercial, tendo disponível de forma livre apenas algumas versões mais antigas e o software Zebra é livre, podendo ser utilizado livremente sem o pagamento de licenças. Ambos são implementados para sistemas UNIX.

O funcionamento de um PTT baseado em Route Server (acordos de tráfego multilaterais) é um pouco mais complexo que o primeiro modelo apresentado (acordos de tráfego bilaterais) , pois existem alguns detalhes importantes no seu funcionamento. No caso de PTTs baseados em acordos de tráfego bilaterais, a troca de anúncios é feita diretamente entre as partes envolvidas. Isso significa que a sessão BGP é estabelecida diretamente entre as interfaces que cada participante tem no PTT, no caso a interface da rede local de cada um. Dessa forma os anúncios chegam ao destino com os mesmos valores que o AS que originou tais anúncios criou, sem nenhuma alteração no caminho. No caso de PTTs baseados em Route Server, cada participante estabelece sessões com os Route Servers, que por sua vez divulgam as rotas para os demais participantes. Vale lembrar aqui que os dois Route Servers estão logicamente em um AS diferente dos demais participantes. Este número geralmente é na faixa de número de AS privados, formando um “AS imaginário”, que serve apenas para permitir que os Route Servers possam estabelecer sessões eBGP com os participantes. Nesse ponto surge um detalhe muito importante, onde a Figura 5 nos ajuda a demonstrar:

Figura 5 - Exemplo de PTT baseado em Route Server.

O detalha importante a ser citado refere-se ao comportamento normal do protocolo BGP que é receber anúncios de rotas - neste caso de outros ASs - aplicar o algoritmo de escolha do melhor caminho e por fim divulgar a seus peers. Na divulgação o atributo NEXT_HOP é alterado para a interface de quem está anunciando e no atributo AS_PATH é incluído o AS de quem está anunciando. Sendo assim, como todos os anúncios passam obrigatoriamente pelos Route Servers (AS 65000), todos os anúncios chegariam aos demais participantes do PTT com o atributo NEXT_HOP definido para a interface do Route Server e o AS_PATH incluído do AS dos Route Servers (AS 65000).

Dessa forma, se determinado AS enviar um pacote para uma rede anunciada por um outro participante, o pacote passará pelo Route Server, que foi quem anunciou a rota incluindo a sua interface como NEXT_HOP e em seguida será repassado do roteador do participante destino. Fazendo uma análise sobre isso, pode-se concluir que esta abordagem funciona, mas poderia ser melhorada, fazendo com que os pacotes do tráfego do PTT propriamente ditos não passassem por um dos Route Servers.

Essa observação se torna uma necessidade, visto que a interface dos Route Servers será o “gargalo” do tráfego geral do PTT. Como em PTTs é normal alcançar altas taxas de tráfego (600 Mbps no PTT da ANSP por exemplo), torna-se quase impossível suportar esse tráfego por limitações de hardware dos route servers. Para contornar este problema, na configuração dos Route Servers é feita uma alteração da forma que nos anúncios recebidos não sejam alterados os atributos de NEXT HOP ou AS_PATH. Esse ajuste que parece simples faz com que o tráfego passa diretamente de um roteador para outro, passando apenas pelo switch. Assim, o tráfego que segue para os Route Servers será apenas do protocolo BGP. Pode-se também visualizar a figura anterior para demonstrar o fluxo obtido. Maiores detalhes sobre tal prática serão abordados nas seções adiante.

Um outro componente muito utilizado em PTTs deste tipo é o chamado looking glass, apresentado na Figura 6.

Figura 6 - PTT baseado em Route Servers, utilizando Looking Glass.

O componente looking glass trata-se de um roteador ou um PC que possui suporte a BGP que fica conectado aos Route Servers, sob um AS também privado diferente destes, por exemplo 65001. O número de AS poderia ser qualquer um da faixa privada, desde que seja diferente do AS formado pelos Route Servers. A utilidade de tal recurso é que este, uma vez conectado aos Route Servers, recebe todos os anúncios dos participantes do PTT e pode usado para consulta das rotas anunciadas no PTT e a preferência que cada uma destas tem sob as demais anunciadas. Isso acaba sendo útil aos participantes do PTT para verificar se seus anúncios estão sendo feitos corretamente e se o efeito está de acordo com o esperado, sem contar que a mesma informação pode ser consultada por pessoas de outros sistemas autônomos para verificar a visibilidade de determinado anúncio ou ainda, para verificar quais os anúncios existentes no PTT e usar tais informações como motivação para participação no PTT.

Por fim, mais um recurso utilizado em PTTs é a aplicação de um RA, conhecido como Router Arbiter. Esta ferramenta serve para certificar as rotas que cada sistema autônomo pode exportar e importar de um peer. Isso é feito mediante o registro de cada AS em uma base de dados, declarando quais prefixos pode aceitar e quais pode enviar. Dessa forma os Route Servers podem ser configurados para que somente sejam repassados prefixos a outros peers em um PTT caso as características dos prefixos estejam de acordo com a base de dados no RA. No exterior essa funcionalidade é muito utilizada, tornando os PTTs baseados em Route Servers mais restritivos em seus anúncios. No Brasil tal prática ainda não vem sendo utilizada até 2003.