Dos PE, un prefijo: por qué el RD decide la visibilidad
Dos enrutadores de borde que anuncian el mismo prefijo comparten un destino, salvo que sus route distinguishers difieran. Asigne a propósito y luego compruebe la VRF.
Dos enrutadores de borde que anuncian el mismo prefijo de cliente describen un único destino VPNv4 hasta que algo los separa, y el separador es el route distinguisher. Califica el prefijo; no decide quién importa el resultado, que es tarea del route target. Asigne los RD desde el conjunto de rutas que deben seguir siendo distinguibles en cada dominio donde esos anuncios puedan encontrarse, no desde la disposición de archivos de una sola caja. El número que elija es una identidad de la que dependerán revisiones posteriores, así que pertenece a un inventario antes de entrar en una configuración.
Un RD más un prefijo es un solo destino
Un RD más un prefijo IPv4 forma el destino VPNv4 que compara el plano de control. Dé a dos PE el mismo prefijo para clientes distintos y, sin RD diferentes, anuncian rutas hacia un solo destino. Nada en una pantalla le dice que esa agrupación es incorrecta, porque la plataforma hace exactamente lo que dice la identidad. Cambie el RD en uno de ellos y el anuncio antiguo se retira mientras bajo otra identidad aparece uno nuevo. Todo lo que aguas abajo dependía de la identidad antigua, desde la selección de ruta hasta un filtro de operador guardado, ahora se refiere a algo que ya no existe.
Varias rutas por destino es un comportamiento normal de BGP, no un síntoma. Un speaker puede mantener varias rutas recibidas mientras selecciona una mejor para el reenvío, y la brecha entre recibida y seleccionada es donde viven las preguntas de visibilidad. Cuando una ruta parezca haber desaparecido, confirme si la identidad a la que pertenecía sigue existiendo antes de mirar la sesión.
Mismo RD, mismo destino, rutas distintas
Envíe un RD y un prefijo desde dos enrutadores en nombre del mismo servicio y ambos ofrecen rutas hacia un único destino, normalmente con saltos siguientes distintos. Cuál de ellas propaga un route reflector es una decisión sobre el reflector: su selección de ruta, su capacidad de anunciar y cualquier política superpuesta. Ninguno de los enrutadores de borde controla esa elección. Dé a los dos anuncios RD distintas y cada uno se convierte en su propio destino, de modo que ambos pueden sobrevivir a un plano de control que de otro modo solo transporta la ruta seleccionada para una identidad.
Visibilidad y multipath se encuentran en la VRF receptora, pero no son la misma decisión, y un reflector que transporta dos identidades no ha configurado una segunda ruta instalada. La VRF instala lo que admite su política de importación y lo que permite su propia configuración de máximo de rutas. Compruebe esa configuración por separado cuando quiera que se use la segunda ruta y no solo que sea visible.
Una regla local de unicidad no es una política
Dar a cada PE y a cada instancia de enrutamiento su propio RD es una convención sólida: nombra el origen, evita que servicios no relacionados colisionen en una identidad y da al inventario una clave estable. Algunas plataformas solo exigen unicidad dentro de la caja y permiten explícitamente que los enrutadores compartan un RD para la misma instancia de VPN. Ese permiso es una restricción de implementación, no una regla entre redes que pueda delegar en un proveedor. Si el dominio abarca equipos, escriba usted mismo la política de asignación.
La pertenencia nunca viene de los dígitos. Un patrón como 65000:12 para un PE y 65000:13 para otro es una costumbre, mientras que unos objetivos de exportación e importación coincidentes como 65000:112 son lo que pone una ruta en una VRF. Trate el RD como la identidad de una ruta y el route target como el permiso que la lleva a una VRF.
Demuestre el cambio en la VRF, no en la pantalla
Antes de tocar un RD, anote cuatro cosas: qué anuncia el PE hoy, qué refleja el reflector, qué importa la VRF receptora y qué ruta selecciona. Un RD nuevo retira un anuncio e introduce otro, así que el cambio aparece en ambos lados de la sesión y es fácil de leer mal si solo vigila el lado que anuncia. La aceptación debería basarse en la accesibilidad que quería, no en una línea extra que aparezca en una lista de prefijos. La tabla de abajo evita que los tres identificadores se confundan durante esa revisión.
| Identifier | Question it answers | What breaks when it is confused with another |
|---|---|---|
| Route distinguisher | Which route identity is this? | Two services collapse into one destination, so one advertisement withdraws the other |
| Route target | Who is allowed to import it? | Routes arrive in a VRF that should not have them, or never arrive at all |
| VRF import policy | What does this instance accept and install? | The route is visible on the PE but never selected in the VRF |
Empiece en el PE que anuncia y compare ambas identidades para el mismo prefijo antes de quitar nada. Los comandos IOS de abajo responden tres preguntas en orden: sigue ahí el anuncio antiguo, es visible la identidad nueva para el reflector y selecciona la VRF el prefijo.
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
Otras plataformas imprimen la misma información con otra sintaxis, y las preguntas sobreviven a ese cambio. Si la identidad nueva falta en el reflector mientras el PE la lista como anunciada, el primer sospechoso es la política o la capacidad de anunciar del reflector, no la numeración.
Registre el PE, la instancia, el RD, los objetivos de exportación e importación y la propiedad del prefijo en un solo lugar, porque la siguiente asignación es una consulta y no una conjetura solo cuando ese registro existe. Mantenga el RD antiguo hasta que la identidad nueva sea visible en la VRF receptora, y retírelo después en un segundo paso para que cada etapa siga siendo reversible.