Dois PE, um prefixo: por que o RD decide a visibilidade

Dois roteadores de borda que anunciam o mesmo prefixo de cliente descrevem um único destino VPNv4 até que algo os separe, e o separador é o route distinguisher. Ele qualifica o prefixo; não decide quem importa o resultado, isso é tarefa do route target. Aloque os RD a partir do conjunto de rotas que devem permanecer distinguíveis em cada domínio onde esses anúncios se possam encontrar, não a partir da disposição de ficheiros de uma única caixa. O número que escolhe é uma identidade da qual dependerão revisões posteriores, por isso pertence a um inventário antes de entrar numa configuração.

Um RD mais um prefixo é um só destino

Um RD mais um prefixo IPv4 formam o destino VPNv4 que o plano de controlo compara. Dê a dois PE o mesmo prefixo para clientes diferentes e, sem RDs distintos, eles anunciam rotas para um único destino. Nada no ecrã diz que esse agrupamento está errado, porque a plataforma faz exatamente o que a identidade diz. Mude o RD num deles e o anúncio antigo é retirado enquanto sob outra identidade surge um novo. Tudo o que a jusante dependia da identidade antiga, da seleção de rota a um filtro de operador guardado, agora refere-se a algo que já não existe.

Várias rotas por destino é comportamento normal do BGP, não um sintoma. Um speaker pode manter várias rotas recebidas enquanto seleciona a melhor para o encaminhamento, e a lacuna entre recebida e selecionada é onde vivem as questões de visibilidade. Quando uma rota parecer ter desaparecido, confirme se a identidade a que pertencia ainda existe antes de olhar para a sessão.

O mesmo RD, o mesmo destino, rotas diferentes

Envie um RD e um prefixo de dois roteadores em nome do mesmo serviço e ambos oferecem rotas para um único destino, geralmente com próximos saltos diferentes. Qual delas um route reflector propaga é uma decisão sobre o reflector: a sua seleção de rota, a sua capacidade de anunciar e qualquer política sobreposta. Nenhum dos roteadores de borda controla essa escolha. Dê aos dois anúncios RDs distintos e cada um torna-se o seu próprio destino, de modo que ambos podem sobreviver a um plano de controlo que de outro modo transporta apenas a rota selecionada para uma identidade.

Visibilidade e multipath encontram-se na VRF recetora, mas não são a mesma decisão, e um reflector que transporta duas identidades não configurou uma segunda rota instalada. A VRF instala o que a sua política de importação admite e o que a sua própria configuração de máximo de rotas permite. Verifique essa configuração separadamente quando quiser que a segunda rota seja usada e não apenas visível.

Uma regra local de unicidade não é uma política

Dar a cada PE e a cada instância de encaminhamento o seu próprio RD é uma convenção sólida: nomeia a origem, evita que serviços não relacionados colidam numa identidade e dá ao inventário uma chave estável. Algumas plataformas exigem unicidade apenas dentro da caixa e permitem explicitamente que os roteadores partilhem um RD para a mesma instância de VPN. Essa permissão é uma restrição de implementação, não uma regra entre redes que possa delegar a um fornecedor. Se o domínio abrange equipas, escreva você mesmo a política de alocação.

A associação nunca vem dos dígitos. Um padrão como 65000:12 para um PE e 65000:13 para outro é um hábito, enquanto alvos de exportação e importação correspondentes como 65000:112 são o que coloca uma rota numa VRF. Trate o RD como a identidade de uma rota e o route target como a permissão que a leva a uma VRF.

Prove a mudança na VRF, não no ecrã

Antes de tocar num RD, anote quatro coisas: o que o PE anuncia hoje, o que o reflector reflete, o que a VRF recetora importa e qual rota seleciona. Um novo RD retira um anúncio e introduz outro, por isso a mudança aparece nos dois lados da sessão e é fácil ler mal se só observa o lado que anuncia. A aceitação deve assentar na acessibilidade desejada, não numa linha extra que apareça numa lista de prefixos. A tabela abaixo impede que os três identificadores se confundam durante essa revisão.

Comece no PE que anuncia e compare as duas identidades para o mesmo prefixo antes de remover qualquer coisa. Os comandos IOS abaixo respondem a três perguntas por ordem: o anúncio antigo ainda está lá, a nova identidade é visível para o reflector e a VRF seleciona o prefixo.

show bgp vpnv4 unicast rd 65000:12 203.0.113.0/24
show bgp vpnv4 unicast rd 65000:13 203.0.113.0/24
show ip route vrf CUSTOMER-A 203.0.113.0/24

Outras plataformas imprimem a mesma informação com outra sintaxe, e as perguntas sobrevivem a essa mudança. Se a nova identidade faltar no reflector enquanto o PE a lista como anunciada, o primeiro suspeito é a política ou a capacidade de anúncio do reflector, não a numeração.

Registe o PE, a instância, o RD, os alvos de exportação e importação e a propriedade do prefixo num só lugar, porque a próxima alocação é uma consulta e não um palpite apenas quando esse registo existe. Mantenha o RD antigo até a nova identidade ser visível na VRF recetora, e retire-o depois num segundo passo para que cada etapa continue reversível.