Política de exportación de Junos: el nombre no es la condición de coincidencia

Alguien llamó EXPORT-STATIC a una política, la enlazó y ahora se pregunta por qué un prefijo de la instancia de enrutamiento VPN nunca llega al extremo remoto. El nombre no tiene ningún efecto en la selección. Una política es una definición más un enlace, y lo que exporta lo deciden sus condiciones de coincidencia, sus términos ordenados y el contexto que la utiliza. Lea esos tres en ese orden y el misterio suele reducirse a un término que nunca coincidió.

El nombre es una etiqueta, no una condición

Junos no interpreta los nombres de las políticas. Una política que con sensatez se llamaría exportación estática puede coincidir con el protocolo static, puede coincidir con un prefijo de dirección, o puede no coincidir con nada y aceptar todo lo que pase. La etiqueta es documentación escrita por quien la creó, y es exactamente tan fiable como la memoria que esa persona tiene de la intención.

Trate un resultado de exportación sorprendente como una petición de leer la definición, no como prueba de que el enlace está roto. Lea la definición y deje que contradiga a la etiqueta.

Encuentre el enlace antes que los términos

Una definición correcta enlazada en el lugar equivocado cambia otro intercambio. Determine qué instancia de enrutamiento, protocolo y vecino o grupo hacen referencia realmente a la política, porque una política enlazada bajo un grupo BGP no afecta a otro, y una política enlazada a la instancia no se aplica necesariamente a todos los protocolos que contiene. Junos distingue estos niveles, y una exportación ausente en el nivel de grupo es habitual cuando la intención se expresó en el nivel de instancia.

Anote la ruta del enlace antes de leer un solo término. La mitad de estas investigaciones terminan ahí, con la definición intacta y la sentencia de exportación movida. Registre la diferencia en el registro de cambios para que nadie la revierta como un error.

Los términos se evalúan en orden y la primera decisión gana

Los términos van del primero al último, y un término que acepta o rechaza es una decisión terminante. Un término posterior que parece la excepción prevista nunca se ejecuta si un término anterior ya decidió el destino de la ruta, por lo que una política puede leerse correctamente de arriba abajo y aun así comportarse en contra de la intención. Compruebe el orden con respecto a la ruta que le interesa, no con respecto al orden en que se escribieron los términos.

Un término que omite su acción no termina; la evaluación continúa al término siguiente, y el resultado final depende de lo que sigue y del valor predeterminado aplicable. Eso es una construcción realmente útil y una fuente fiable de sorpresas cuando no es intencionada.

Un ejemplo que exporta solo rutas estáticas, con el enlace en el grupo:

policy-options {
    policy-statement EXPORT-STATIC {
        term statics { from protocol static; then accept; }
    }
}
protocols bgp group TO-PEER { export EXPORT-STATIC; }

Un prefijo aprendido por OSPF en lugar de configurado como ruta estática falla la coincidencia y cae, se llame como se llame la política.

Las acciones cambian una copia, no la ruta original

Las acciones de la política operan sobre la ruta tal como se evalúa para ese anuncio, que es una copia y no la entrada de la tabla de enrutamiento. Por tanto, un comando local show route puede mostrar una ruta con un conjunto de atributos mientras la versión exportada lleva otros, y la original no es reescrita por la exportación. Esa distinción explica varias discusiones sobre qué salida es correcta: ambas lo son, y describen objetos distintos. Diga qué vista cita siempre que dos ingenieros discrepen sobre un atributo de ruta.

Aceptar y rechazar son decisiones terminantes; los cambios de atributos no necesariamente lo son. No asuma que establecer una community termina la política, porque la evaluación puede continuar en términos que no consideró.

Compare la vista anunciada con la expectativa

Use la vista específica del protocolo en el par real, como show route advertising-protocol bgp 192.0.2.1, y léala en el contexto correcto de la instancia de enrutamiento. Una ruta presente en una VRF no ha pasado necesariamente la política de exportación, y una ruta que aparece en la salida anunciada no ha sido necesariamente aceptada por el extremo remoto. Son tres estados separados y fallan de formas distintas.

Acepte el diseño con un prefijo que debe anunciarse y otro que debe permanecer local. Eso da a la política un contrato que puede probar, y evita la solución alternativa de ampliar la exportación hasta que por fin aparezca una única ruta con nombre.