Ao configurar o MP-BGP, no hardware Juniper, pode ocorrer uma situação (não) óbvia de restabelecimento da vizinhança. O motivo é descrito em detalhes na base de conhecimento KB20870 da Junuper . Aqui está uma breve recontagem com meus comentários.
Como você sabe, ao trabalhar com VPNs, várias tabelas de roteamento são usadas. Estaremos interessados em dois principais: vrf.inet.0 e bgp.l3vpn.0 (a seguir, a situação com L3VPN é descrita, mas isso também é válido para outros serviços em que o BGP é um protocolo de sinalização).
A tabela bgp.l3vpn.0 contém todas as rotas recebidas dos vizinhos BGP.
As rotas diretas / estáticas de um roteador PE específico são colocadas na tabela vrf.inet.0 , bem como as rotas de entrada de vizinhos da tabela bgp.l3vpn.0 que atendem à política de importação (se configurada) são importadas.
Ao mesmo tempo, a exportação do vrf.inet.0 para o bgp.l3vpn.0 não ocorre e as rotas são anunciadas diretamente aos vizinhos.
Se o roteador funcionar como um refletor de rota ou se houver vizinhos MP eBGP, as rotas serão colocadas na tabela vrf.inet.0 e em bgp.l3vpn . Nesse caso, é feita uma comparação com rotas locais e (se necessário) o melhor caminho é selecionado.
Assim, o roteador pode operar em um dos dois modos definidos:
- nenhum refletor de roteador está configurado no roteador e não há vizinhos eBGP;
- o roteador é um refletor de rota e / ou há vizinhos do eBGP nele.
A mudança de modos implica reiniciar as sessões MP-BGP. Claramente, isso pode ser visto na seguinte topologia:
Na primeira versão (Fig. 1), é apresentado o esquema iBGP de malha completa. Agora imagine que precisamos adicionar o roteador R4. Por um motivo ou outro, decidimos fazer isso configurando R1 como um refletor de rota para R4 (Fig. 2). A realização das configurações do refletor de rota no R1 implicará a reinstalação de todas as sessões do MP-BGP (com roteadores R2 e R3), o que implicará tempo de inatividade na prestação de serviços.
Para evitar isso, propõe-se transferir firmemente o roteador para o segundo modo de operação. Uma maneira é criar um grupo fictício de eBGP. Por exemplo:
group fake-vpn { type external; description "## Preventing mpbgp sessions flap ##"; passive; family inet { any; family inet-vpn { any; family iso-vpn { unicast; family l2vpn { signaling; family evpn { signaling; family inet-mvpn { signaling; family inet-mdt { signaling; neighbor 192.0.2.1 { peer-as 65536; }
AS: 65536 e IP: 192.0.2.1 podem ser absolutamente qualquer coisa, e o modo passivo permite evitar tentativas desnecessárias para estabelecer uma sessão inexistente do roteador.
Quando pode ser útil:
- não há refletores de rota dedicados na rede. O papel do RR são os roteadores principais da rede. Ao mesmo tempo, existe a possibilidade de uma alteração em sua função (por exemplo, de um roteador P para um P / RR ou vice-versa);
- existe a possibilidade de uma interface eBGP aparecer com a família MP-BGP, por exemplo, Inter-AS.