A funcionalidade de reflexão de rota BGP foi criada para facilitar os projetos de onde era necessária uma malha completa de iBGP, entretanto, realizar uma malha de configuração completa não é nada escalável e demandaria muito tempo e muita documentação para mapear todas as sessões de acordo com o crescimento da rede.
Meu objetivo principal é dissertar sobre redundância de route reflectors, como a criação de clusters e seu objetivo em um projeto de redes.
O que é um Cluster route reflector?
Primeiro é necessário explicar o atributo Cluster_list e Cluster_ID:
· Cluster_ID: é obtido do Route Reflector Router ID ou pode ser configurado. Se dois roteadores compartilham o mesmo Cluster_ID, eles pertencem ao mesmo cluster. Antes de refletir uma rota, os refletores de rota anexam seu Cluster_ID na Cluster_list. Se a rota se originou do próprio refletor de rotas, o refletor de rotas não criará um Cluster_List.
· Cluster_list: ele previne loops entre os route reflectors, clients não utilizam o atributo, visto que eles não sabem a qual cluster pertencem.
Então, um Cluster de route reflector nada mais é que um ou mais roteadores route reflectors que fecham sessões de reflexão entre si.
De acordo com a RFC 4456 Se um Route reflector receber rotas com um mesmo Cluster_ID ela será descartada para prevenir loop de roteamento. Também de acordo com a RFC, um Cluster é um único Route reflector, com seu ID, entretanto isso pode ser um ponto de falha e necessitamos de uma redundância, neste caso, é possível termos vários route reflectors participando de um mesmo Cluster, então podemos configura-los com um mesmo Cluster_ID para que descartem rotas uns dos outros ou não.
Mas que seria melhor? Dois ou mais route reflectors com Clusters ID iguais ou diferentes?
O papel do designer de rede é identificar adequadamente quais refletores de rota e seus clientes formarão um cluster e atribuir um Cluster_ID exclusivo. Um route reflector pode refletir rotas apenas dentro de um único cluster, entretanto um route reflector pode participar de outro cluster, como client.
Em um cluster com route reflectors redundantes, o client encaminhará a atualização EBGP recebida para ambos os refletores, os route reflectors encaminham a atualização para a malha completa do IBGP. Esse comportamento significa que eles também enviarão a atualização um para o outro, mas quando um refletor de rota recebe uma atualização BGP de outro refletor de rota, ele reconhecerá seu número de Cluster_ID comum no atributo Cluster-list, portanto, a atualização de rota recém-recebida é ignorada.
Para provar a teoria das documentações e RFC criei um laboratório emulando 3 cenários.
Cluster com mesmo ID:
RR1 e RR2 são roteadores Route reflectors (out of band) em um Cluster_ID único
RR1 e RR2 recebem rotas de Client-1, Client-2, Client-3 e BORDA, e neste caso, como utilizam o mesmo ID, descartam as rotas um do outro.
Vejamos a configuração e tabela de roteamento de RR1
Agora vejamos a configuração a tabela de roteamento de RR2
Quando RR2 reflete as rotas de Clients para RR1 ou vice-versa, o par descartará essas rotas. Além disso, cada um deles aprenderá as rotas do client por meio da sessão direta do IBGP, porém caso houvesse uma falha nessas sessões RR1 ou RR2 não teriam as rotas do client em questão.
Vamos testar o cenário, com podemos ver nas imagens acima, ambos os roteadores aprendem os prefixos de clientes apenas de sessões diretas, o que aconteceria se Client-3 Perdesse seu BGP com RR2 e mantivesse apenas com RR1? Isso mesmo, RR2 não receberia mais a rota devido a prevenção de loop do Cluster_list.
Até então não temos problemas pois RR1 tem reflexão redundante para o restante do cenário, e ele se conecta diretamente a Client-3, entretanto uma outra queda de vizinhança geraria diversos problemas.
Caso Client-1 perdesse sua sessão com RR1, como ele receberia as rotas de Client-3 e como Client-3 receberia as rotas de Client-1 ?
Então ter um mesmo cluster-ID nos route reflector economiza memória e recursos, porém a resiliência do cenário é afetada, e para este modelo é necessária altíssima redundância.
Cluster com diferentes IDs:
Se usássemos diferentes Cluster_ID em RR1 e RR2, RR1 aceitaria rotas refletidas de RR2 além das rotas da sessão direta com R4, neste caso, se não houver nenhum problema de recurso, ter um ID de cluster diferente fornece convergência mais rápida, e é menos suscetível a falhas de recursividade, porém exige mais recursos.
Vejamos a configuração e tabelas de rotas abaixo, realizando o mesmo experimento anterior. Configuração e tabela de rotas de RR1:
Agora em RR2:
Abrindo a rota recebida em ambos, podemos ver que existe uma rota principal e uma rota secundária, via seu cluster par.
Agora simulando o mesmo cenário anterior onde Client-3 perde vizinhança com RR2 e Client-1 com RR1 teremos o seguinte resultado:
Nos clientes mesmo com falha nas sessões, via este modelo as rotas ainda são recebidas, pois os route reflectors não descartam as rotas pois tem Cluster_list diferentes.
Cluster com mesmo ID porém sem iBGP reflector entre eles
Este cenário exemplifica basicamente dois route reflectors trabalhando separadamente, porém com um único Cluster_ID, eles não trocam rotas entre si pois não tem vizinhança, então todos os roteadores clientes, dependem de total conectividade, julgando o mesmo cenário anterior nesta topologia, qual deverá ser o comportamento? Caso Client-1 perca vizinhança com RR1 e Client-3 perca a vizinhança com RR2 teremos o seguinte comportamento.
Isso acontece pois RR1 e RR2 não tem como trocar tabelas, então, ainda assim temos uma falha que pode acabar ocorrendo e afetar a conectividade do cenário pela falta de recursividade.
Chegando a uma conclusão, com base na exploração de documentações e cenários, qual é o melhor modelo?
A resposta é: Depende
Podemos usar um mesmo Cluster_ID em route reflectors pares para reduzir a quantidade de atualizações de BGP.
Contudo, assim como a remoção da sessão IBGP entre refletores de rota, definir o mesmo Cluster_ID em refletores de rota reduz a resiliência do projeto, uma falha de um route reflector (ou duas sessões BGP perdidas) pode resultar em perda de conectividade e problemas na topologia.
Trabalhando com route reflectors com Cluster_ID diferentes e em pares podemos ver que temos uma maior utilização do recurso, mas é altamente redundante.
E trabalhando com router reflectors independentes dentro de um mesmo cluster ainda podemos temos um problema de recursividade no ambiente, um adendo para esse modelo é, cuidar a escala, pois novamente, route reflectors com um mesmo Cluster_list descartam rotas, outro roteador mal inserido neste cenário poderia causar a falta de conectividade com um novo link.
Sobre a escalabilidade dos cenários, todos são escaláveis de acordo com o projeto de rede, e a configuração de hierarquia de route reflectors é maleável então mesmo que tenhamos clusters diferentes no primeiro nível, no segundo nível poderia ser realizado um cluster responsável pelos pares abaixo.
O que achou deste conteúdo ? Sinta-se livre para me chamar no Linkedin e trocar mais ideias sobre conteúdos de redes !
