De uma rota RIP do CE a uma VRF remota: onde o export acontece

Uma atualização RIPv2 chega ao provider edge, entra numa tabela de roteamento VRF e ali para, a menos que algo a exporte explicitamente. Três decisões acontecem em sequência, e cada uma pode recusar o prefixo por motivo próprio. Ler essas três decisões como um único evento é a razão pela qual se procura o equipamento errado quando um site remoto não alcança uma rede que o CE anuncia claramente. Siga a rota através do PE e a sequência fica óbvia.

O que o PE faz com uma atualização RIP

O PE recebe a atualização na interface da VRF, verifica que a origem é um vizinho permitido e instala o prefixo na tabela de roteamento da VRF com uma contagem de saltos derivada do anúncio. Essa tabela é uma tabela de roteamento normal, com as suas próprias distâncias administrativas e a sua própria eleição do melhor caminho. Se o CE anunciar o mesmo prefixo duas vezes com métricas diferentes, só o melhor sobrevive na tabela. Nada neste passo envolve o backbone do provedor.

O prefixo existe agora dentro do contexto de roteamento de um cliente, o que está muito longe de ser alcançável em qualquer outro lugar.

A exportação é um ato de política, não uma consequência do protocolo

Para sair da VRF, uma rota tem de ser redistribuída no processo MP-BGP que transporta rotas VPN, e precisa de uma extended community route target que identifique quais VRF remotas a podem importar. A arquitetura do RFC 4364 mantém essas trocas separadas do protocolo CE-PE exatamente por esse motivo. Usar RIP na borda não diz nada sobre o que deve atravessar a rede do provedor.

Escreva o contrato de exportação antes de configurar qualquer coisa: os prefixos de cliente que devem ser alcançáveis remotamente, as rotas que devem permanecer locais, e quaisquer defaults, rotas mais específicas ou exceções de serviço partilhado. Compare esse contrato com a VRF real, e não com uma de nome parecido pertencente a outro cliente.

O lado do import é uma segunda política, com os seus próprios route targets, e uma exportação correspondente com um import não correspondente produz um prefixo que existe no backbone e não aparece em nenhuma tabela remota.

Redistribuição e originação explícita comportam-se de forma diferente

A redistribuição pega em rotas que já existem na tabela da VRF e copia-as para o BGP, filtradas por um route map. O map decide que prefixos são elegíveis e que atributos transportam, e a métrica tem de ser definida explicitamente, porque uma contagem de saltos RIP não tem significado como métrica BGP. Tudo o que deixar por definir é herdado de uma forma que costuma surpreender quem lê a configuração seis meses depois.

A redistribuição mútua é onde ocorre o dano silencioso. Um prefixo exportado para o BGP pode voltar através de um segundo ponto de redistribuição e, sem tags nem filtros, a rota oscila enquanto ambas as tabelas parecem plausíveis em cada instante. Filtre por tags aplicadas na borda, em vez de confiar na topologia para impedir o caminho de retorno.

A originação explícita parece mais arrumada e não é incondicional. Um network statement normalmente precisa de uma rota correspondente na tabela de roteamento antes de o prefixo ser originado, pelo que o anúncio desaparece no momento em que o CE deixa de o anunciar. Muitas vezes é esse o comportamento desejado, e não é o mesmo que uma rota estática que fica configurada para sempre. Verifique a regra real da plataforma em vez de presumir um dos comportamentos.

De qualquer forma, a pergunta a fazer sobre cada prefixo é qual fonte ativa o torna elegível e o que acontece quando essa fonte desaparece.

Verifique a cadeia em quatro pontos

Observe o anúncio do CE, a tabela de roteamento da VRF, a tabela de rotas VPN com o seu route target e o import na VRF remota, por essa ordem. No IOS isso significa a saída de vizinhos do CE, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, e o mesmo comando no PE remoto. No IOS-XR a saída equivalente fica em show bgp vrf CUSTOMER ipv4 unicast. Os nomes dos comandos diferem, os quatro pontos de verificação não.

Verifique um prefixo que deve ser rejeitado com o mesmo cuidado que um que deve passar, porque uma política que permite tudo parece idêntica a uma correta até chegar a primeira exceção. Depois observe um withdrawal: desligue a interface do CE e confirme que a entrada remota desaparece dentro do temporizador esperado, em vez de permanecer.

Registe quem é dono de cada política. Quando o provedor opera o CE, o comportamento entregue pertence ao contrato de serviço, e um protocolo ou uma política de withdrawal diferente no equipamento gerido é primeiro um problema de documentação e só depois um problema de roteamento.