Dous PE, un prefixo: por que o RD decide a visibilidade
Dous encamiñadores de borde que anuncian o mesmo prefixo comparten un destino, salvo que os seus route distinguishers difiran. Asigne con deliberación e despois comprobe a VRF.
Dous encamiñadores de borde que anuncian o mesmo prefixo de cliente describen un único destino VPNv4 ata que algo os separa, e o separador é o route distinguisher. Cualifica o prefixo; non decide quen importa o resultado, que é tarefa do route target. Asigne os RD desde o conxunto de rutas que deben permanecer distinguibles en cada dominio onde eses anuncios poidan atoparse, non desde a disposición de ficheiros dunha soa caixa. O número que elixa é unha identidade da que dependerán revisións posteriores, así que pertence a un inventario antes de entrar nunha configuración.
Un RD máis un prefixo é un destino
Un RD máis un prefixo IPv4 forma o destino VPNv4 que compara o plano de control. Dea a dous PE o mesmo prefixo para clientes distintos e, sen RD diferentes, anuncian rutas cara a un único destino. Nada nunha pantalla lle di que esa agrupación é incorrecta, porque a plataforma fai exactamente o que di a identidade. Cambie o RD nun deles e o anuncio antigo retírase mentres baixo outra identidade aparece un novo. Todo o que augas abaixo dependía da identidade antiga, desde a selección de ruta ata un filtro de operador gardado, agora refírese a algo que xa non existe.
Varias rutas por destino é un comportamento normal de BGP, non un síntoma. Un speaker pode manter varias rutas recibidas mentres selecciona unha mellor para o reenvío, e a fenda entre recibida e seleccionada é onde viven as preguntas de visibilidade. Cando unha ruta pareza desaparecer, confirme se a identidade á que pertencía segue existindo antes de mirar a sesión.
Mesmo RD, mesmo destino, rutas distintas
Enríe un RD e un prefixo desde dous encamiñadores en nome do mesmo servizo e ambos ofrecen rutas cara a un único destino, normalmente con saltos seguintes distintos. Cal delas propaga un route reflector é unha decisión sobre o reflector: a súa selección de ruta, a súa capacidade de anunciar e calquera política superposta. Ningún dos encamiñadores de borde controla esa elección. Dea aos dous anuncios RD distintas e cada un convértese no seu propio destino, de modo que ambos poden sobrevivir a un plano de control que doutro xeito só transporta a ruta seleccionada para unha identidade.
Visibilidade e multipath atópanse na VRF receptora, pero non son a mesma decisión, e un reflector que transporta dúas identidades non configurou unha segunda ruta instalada. A VRF instala o que admite a súa política de importación e o que permite a súa propia configuración de máximo de rutas. Comprobe esa configuración por separado cando queira que se use a segunda ruta e non só que sexa visible.
Unha regra local de unicidade non é unha política
Dar a cada PE e a cada instancia de encamiñamento o seu propio RD é unha convención sólida: nomea a orixe, evita que servizos non relacionados colisionen nunha identidade e dálle ao inventario unha clave estable. Algunhas plataformas só esixen unicidade dentro da caixa e permiten explicitamente que os encamiñadores compartan un RD para a mesma instancia de VPN. Ese permiso é unha restrición de implementación, non unha regra entre redes que poida delegar nun provedor. Se o dominio abrangue equipos, escriba vostede mesmo a política de asignación.
A pertenza nunca vén dos díxitos. Un patrón como 65000:12 para un PE e 65000:13 para outro é un costume, mentres que uns obxectivos de exportación e importación coincidentes como 65000:112 son o que pon unha ruta nunha VRF. Trate o RD como a identidade dunha ruta e o route target como o permiso que a leva a unha VRF.
Demostre o cambio na VRF, non na pantalla
Antes de tocar un RD, anote catro cousas: que anuncia o PE hoxe, que reflicte o reflector, que importa a VRF receptora e que ruta selecciona. Un RD novo retira un anuncio e introduce outro, así que o cambio aparece nos dous lados da sesión e é fácil de ler mal se só vixía o lado que anuncia. A aceptación debería basearse na accesibilidade que quería, non nunha liña extra que apareza nunha lista de prefixos. A táboa de abaixo evita que os 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 |
Comece no PE que anuncia e compare ambas identidades para o mesmo prefixo antes de quitar nada. Os comandos IOS de abaixo responden tres preguntas por orde: segue aí o anuncio antigo, é visible a identidade nova para o reflector e selecciona a VRF 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 imprimen a mesma información con outra sintaxe, e as preguntas sobreviven a ese cambio. Se a identidade nova falta no reflector mentres o PE a lista como anunciada, o primeiro sospeitoso é a política ou a capacidade de anunciar do reflector, non a numeración.
Rexiste o PE, a instancia, o RD, os obxectivos de exportación e importación e a propiedade do prefixo nun só lugar, porque a seguinte asignación é unha consulta e non unha conxectura só cando ese rexistro existe. Manteña o RD antigo ata que a identidade nova sexa visible na VRF receptora, e retíreo despois nun segundo paso para que cada etapa siga sendo reversible.