Ouvi o termo "servidor de rota" e "espelho" ser jogado por aqui. O que são e por que devo me importar?

— John Jensen
fonte

(Observe que esses dois termos geralmente são usados de forma intercambiável, o que pode levar a alguma confusão.)

Óculos de sol

Um espelho geralmente é um site (geralmente CGI) que faz interface com roteadores pertencentes e operados por um único ISP ou outro operador de rede. Na maioria das vezes, eles são acessíveis ao público, mas pode haver casos em que não o são. O espelho fornece uma visão (em formato de site) em uma tabela BGP de um roteador específico na rede de uma operadora. Muitas vezes, as implementações de espelho também incluem outros utilitários, como a capacidade de executar um traceroute para um destino como se fosse executado no próprio roteador da operadora de rede. Os óculos de visão são úteis porque fornecem uma perspectiva da tabela BGP de um upstream. A Level3, uma conhecida transportadora de primeira linha nos EUA, tem um espelho disponível aqui. Essas são ferramentas de solução de problemas amplamente usadas.

Servidores de rota

O termo "servidor de rota" evoluiu para significar duas coisas diferentes, as quais serão explicadas. Estou definindo dois "subtipos" de servidor de rota aqui que devem tornar a distinção mais clara. Essas definições são minhas e são usadas apenas para tentar dissipar qualquer possível confusão. Na realidade, o servidor de rota público também é chamado de "coletor de rota" ou "servidor de exibição de rota" (o último originário do projeto de visualizações de rota da Universidade de Oregon ).

Servidor de rota pública

Estes são sistemas (geralmente roteadores, mas existem alguns que executam daemons de roteamento de código aberto) acessíveis ao público, geralmente via Telnet, e também é possível executar pings, traceroutes e "show ip bgp" (também existem alguns Juniper rotear servidores por aí, não se preocupe!) comandos. A diferença entre um servidor de rota público e um espelho (além de um LG que possui um CGI bacana) é que uma grande variedade de redes (incluindo algumas operadoras de primeira linha) fazem pares com um servidor de rota, então há uma imagem geral "geral" de quais prefixos são provenientes de quais ASNs. A política de autorização de comando varia de servidor para servidor de rota. Aqui está uma lista de servidores de rota IPv4 . Eles também têm uma página separada com servidores de rota IPv6.servidor de rota , pode-se pensar no espelho como uma interface para um servidor de rota, seja ele próprio servidor público ou privado.

Você não pode executar um espelho em um servidor de rota pública?

Você pode, mas normalmente as pessoas que usam óculos são aquelas que podem se dar ao luxo de operar e manter os servidores nos quais os óculos funcionam. Com um servidor de rota pública, tudo o que você precisa é de um roteador (ou um servidor executando um daemon de roteamento de código aberto), uma boa política AAA e algumas pessoas que estejam dispostas a fornecer feeds BGP. Também é importante observar que algumas operadoras de rede também hospedam servidores de rotas acessíveis ao público, e você pode até encontrar algumas operadoras que executam um servidor de rotas, além de um espelho.

Servidor de rota IXP

Esta versão do servidor de rota é um pouco diferente. Em malhas de ponto compartilhado nos IXP, a barreira de entrada para uma organização começar o ponto é menor. Você tem uma única porta (que o IXP lhe vende) conectada à rede local de IXP, e o IXP recebe um endereço IP. Agora você pode ver com mais alguém na tela; Compare isso com um PNI, que envolve uma conexão física dedicada separada entre você e outra entidade. Com uma conexão com a LAN de peering de um IXP, além de sua única porta ser o gargalo, é necessário configurar manualmente as sessões do eBGP com quem você deseja peer. Isso é chamado de interconexão bilateral- há uma sessão entre você e o colega, e somente você e o colega trocam os anúncios. Se o IXP tiver muitos membros, isso pode se tornar complicado. Nesse caso, um servidor de rota é normalmente implantado no IXP para ser o "balcão único" para uma organização configurar uma sessão de eBGP com o objetivo de receber prefixos de quem quer que seja o seu servidor de rota. Isso é chamado de interconexão multilateral . Uma sessão BGP entre você e o servidor de rota e você recebe os anúncios de todos os outros que também fazem a mesma coisa com o servidor de rota.

Algumas organizações confiarão na (s) sessão (s) do servidor de rota eBGP, enquanto outras a usarão como backup dos seus pares existentes do eBGP na malha IXP. A maioria dos IXPs terá servidores de rota redundantes e sugere que as organizações façam a mesma parceria com as duas, caso elas façam parte da mesma.

E o BGP?

O peering multilateral usando servidores de rota traz desafios interessantes em relação ao BGP. Um servidor de rota propriamente dito é um orador do eBGP, no entanto, deve haver considerações específicas para um servidor de rota e um par multilateral de BGP. Algumas dessas regras serão uma reminiscência da reflexão da rota do iBGP e, de fato, existem muitas semelhanças. Houve um trabalho recente para padronizar comportamentos de um servidor de rota quando se trata desses recursos específicos. As seguintes advertências são dignas de nota aqui:

Atributo NEXT_HOP - este atributo deve ser passado sem modificação entre o servidor de rota e seus clientes. Embora a própria implementação do servidor de rota não modifique esse atributo, ainda é uma boa prática definir o "próximo salto" nas sessões do eBGP do roteador para um servidor de rota.
Atributo AS_PATH - Novamente, como o servidor de rota deve ser transparente e não participar de nenhuma decisão de roteamento, e a modificação desse atributo pode afetar o melhor processo de tomada de decisão dos clientes do servidor de rota, a implementação do servidor de rota não deve modificar esse atributo. Além disso, o servidor de rota não enviará seu próprio ASN nas atualizações de BGP para seus clientes; portanto, é necessário definir "nenhum bgp forçar primeiro" (específico da Cisco) no roteador do cliente para permitir que a sessão do eBGP entre o cliente e o servidor de rota.
Atributo MULTI_EXIT_DISC - MED é outro atributo que deve ser propagado para rotear clientes do servidor sem modificação pelo servidor de roteamento, pois também pode ser usado para influenciar o melhor processo de seleção de caminho.
Atributos de comunidades - não devem ser modificados pelo servidor de rota, a menos que a comunidade (ou comunidades) seja destinada ao processamento pelo próprio servidor de rota. Normalmente, as comunidades são usadas pelas implementações do servidor de rota IXP para permitir que os pares do servidor de rota manipulem atualizações de roteamento para outros pares de servidores de rota.

É importante lembrar duas distinções em relação à implementação do servidor de rota IXP:

O servidor de rota não participa de nenhum roteamento ou encaminhamento. É suposto ser o mais transparente possível.
Os clientes do servidor de rota dependem do servidor de rota para executar sua filtragem de saída para eles.

Opções de implementação do servidor de rota IXP

Normalmente, os operadores IXP implementam daemons de roteamento de código aberto como servidores de rota. Existem três opções populares:

Quagga, especificamente bgpd . Executa no Linux e BSD. Já existe há mais tempo e provavelmente tem o máximo de informações disponíveis. Houve vários garfos do Quagga ao longo dos anos, incluindo um trem com desenvolvimento patrocinado pela EuroIX , um trem desenvolvido pelo grupo Open Source Routing (que tem como objetivo melhorar a funcionalidade IGP com OSPF e ISIS) e o Quagga-RE (Release Engenharia) que possui recursos experimentais. O Google também criou seu próprio fork do Quagga. O Quagga bgpd suporta IPv6 e IPv4, no entanto, a maioria dos operadores IXP (e até mesmo alguns mantenedores do Quagga) desaconselham o uso do trem Quagga "principal" para operar um servidor de rota em um IXP.
PÁSSARO . Executa no Linux e BSD. O BIRD ganhou bastante popularidade devido à sua estabilidade e à poderosa linguagem e recursos de filtragem, além de seu muito bom sistema de agendamento. Houve algumas comparações publicadas e testes de escala entre Quagga e BIRD. No geral, o BIRD tende a ser mais estável e não é tão suscetível à perda de CPU e memória quanto o Quagga. No entanto, o BIRD e o Quagga são de thread único, mas isso é intencional. Além disso, embora o BIRD suporte IPv4 e IPv6, ele requer dois processos diferentes (binários compilados) para IPv4 e IPv6.
OpenBGPD . Apenas BSD . O OpenBGPD é o único daemon BGP de código aberto multiencadeado disponível. É conhecido por ser bastante estável sob carga, no entanto, o suporte ao TCP MD5 é um pouco ruim.

Além dos daemons de código aberto, a Cisco também oferece uma implementação de servidor de rota para o IOS-XE , que roda na plataforma ASR. No momento da redação deste artigo, a Juniper não oferece uma implementação de servidor de rota em seu hardware ou sistema operacional, mas isso pode mudar no futuro.

Em termos de avaliação de um daemon de roteamento de código aberto, no que diz respeito ao gerenciamento e arquitetura de memória, pode-se supor com segurança que o BIRD> OpenBGPD> Quagga, no entanto, a plataforma ASR e o IOS-XE também são declaradamente muito mais capazes em escala quando comparados ao open opções do daemon de origem disponíveis.

Espero que isso mostre alguma luz sobre os servidores de rotas / óculos em geral.