Dunha ruta CE RIP a unha VRF remota: onde ocorre a exportación

Unha actualización RIPv2 chega á borde do provedor, cae nunha táboa de rutas VRF e detense alí a non ser que algo a exporte explicitamente. Tres decisións ocorren en secuencia, e cada unha pode rexeitar o prefixo pola súa propia razón. Leelas como un único evento é o motivo polo que a xente busca a caixa equivocada cando un sitio remoto non pode alcanzar unha rede que o CE anuncia claramente. Segue a ruta polo PE e a secuencia faise obvia.

Que fai o PE cunha actualización RIP

O PE recibe a actualización na interface VRF, comproba que a orixe é un veciño permitido e instala o prefixo na táboa de rutas VRF cun número de saltos derivado do anuncio. Esa táboa é unha táboa de rutas normal coas súas propias distancias administrativas e a súa propia elección da mellor ruta. Se o CE anuncia dúas veces o mesmo prefixo con métricas distintas, só a mellor sobrevive na táboa. Nada neste paso implica a rede troncal do provedor.

O prefixo existe agora dentro do contexto de rutas dun só cliente, o que está moi lonxe de ser alcanzable en calquera outro lugar.

A exportación é un acto de política, non unha consecuencia do protocolo

Para saír da VRF, unha ruta ten que redistribuírse no proceso MP-BGP que transporta rutas VPN, e necesita unha comunidade estendida de destino de ruta que identifique que VRF remotas poden importala. A arquitectura de RFC 4364 mantén eses intercambios separados do protocolo CE-a-PE exactamente por esta razón. Usar RIP no borde non di nada sobre o que debe cruzar a rede do provedor.

Escribe o contrato de exportación antes de configurar nada: os prefixos de cliente que deben ser alcanzables remotamente, as rutas que deben permanecer locais e calquera predeterminada, máis-específicas ou excepcións de servizo compartido. Compara ese contrato coa VRF real en vez de cunha dun nome similar pertencente a outro cliente.

O lado de importación é unha segunda política coas súas propias rutas de destino, e unha exportación coincidente cunha importación non coincidente produce un prefixo que existe na rede troncal e non aparece en ningunha táboa remota.

A redistribución e a orixe explícita compórtanse de xeito diferente

A redistribución toma rutas que xa existen na táboa VRF e cópiaas en BGP, filtradas por un mapa de rutas. O mapa decide que prefixos son elixibles e que atributos levan, e a métrica ten que establecerse explicitamente porque un número de saltos RIP non ten sentido como métrica BGP. Todo o que deixes sen definir hereda dun xeito que adoita sorprender a quen le a configuración seis meses despois.

A redistribución mutua é onde ocorre o dano silencioso. Un prefixo exportado a BGP pode volver por un segundo punto de redistribución, e sen etiquetas nin filtros a ruta oscila mentres ambas as táboas parecen plausibles en calquera instante. Filtra por etiquetas aplicadas no borde en vez de confiar na topoloxía para evitar o camiño de volta.

A orixe explícita parece máis ordenada e non é incondicional. Unha declaración de rede adoita necesitar unha ruta coincidente na táboa de rutas antes de que se orixine o prefixo, así que o anuncio desaparece no momento en que o CE deixa de anuncialo. Iso é a miúdo o comportamento que queres, e non é o mesmo que unha ruta estática que permanece configurada para sempre. Comproba a regra real da plataforma en vez de asumir calquera dos dous comportamentos.

De calquera xeito, a pregunta que hai que facer sobre cada prefixo é que fonte activa o fai elixible e que acontece cando esa fonte desaparece.

Verifica a cadea en catro lugares

Mira o anuncio do CE, a táboa de rutas VRF, a táboa de rutas VPN coa súa ruta de destino e a importación na VRF remota, nesa orde. En IOS iso significa a saída do veciño CE, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, e o mesmo comando no PE afastado. En IOS-XR a saída equivalente está baixo show bgp vrf CUSTOMER ipv4 unicast. Os nomes dos comandos cambian, os catro puntos de control non.

Comproba un prefixo que debería ser rexeitado con tanto coidado como un que debería pasar, porque unha política que permite todo parécese a unha correcta ata que chega a primeira excepción. Despois observa unha retirada: apaga a interface do CE e confirma que a entrada remota desaparece dentro do temporizador esperado en vez de permanecer.

Rexistra quen é o dono de cada política. Cando o provedor xestiona o CE, o comportamento entregado pertence ao contrato de servizo, e un protocolo ou unha política de retirada diferente no dispositivo xestionado é un problema de documentación antes de ser un problema de rutas.