Cómo se evalúan las comunidades BGP y las comunidades extendidas en condiciones de coincidencia de políticas de enrutamiento
Cuando se utilizan comunidades BGP y comunidades extendidas como condiciones de coincidencia en una política de enrutamiento, el software del marco de políticas las evalúa de la siguiente manera:
Cada ruta se evalúa con respecto a cada comunidad nombrada en una instrucción de política
from
de enrutamiento. Si una ruta coincide con una de las comunidades nombradas en lafrom
instrucción, la evaluación del término actual continúa. Si una ruta no coincide, finaliza la evaluación del término actual.La ruta se evalúa contra cada miembro de una comunidad nombrada. La evaluación de todos los miembros debe ser exitosa para que la evaluación de la comunidad nombrada sea exitosa.
Cada miembro de una comunidad con nombre se identifica mediante un valor de comunidad literal o una expresión regular. Cada miembro es evaluado contra cada comunidad asociada con la ruta. (Las comunidades son una propiedad desordenada de una ruta. Por ejemplo, 1:2 3:4 es lo mismo que 3:4 1:2.) Solo se requiere que una comunidad de la ruta coincida para que la evaluación de los miembros sea exitosa.
Las expresiones regulares de la comunidad se evalúan carácter por carácter. Por ejemplo, si una ruta contiene la comunidad 1234:5678, las expresiones regulares ven nueve caracteres discretos, incluidos los dos puntos (:), en lugar de dos conjuntos de números (1234 y 5678) separados por dos puntos. Por ejemplo:
[edit] policy-options { policy-statement one { from { community [comm-one comm-two]; } } community comm-one members [ 1:2 "^4:(5|6)$" ]; community comm-two members [ 7:8 9:10 ]; }
Si un miembro de la comunidad es una expresión regular, se realiza una coincidencia de cadena en lugar de una coincidencia numérica.
Por ejemplo:
community example1 members 100:100 community example2 members 100:1..
Dada una ruta con un valor de comunidad de 1100:100, esta ruta coincide
community example2
pero noexample1
.Para que coincida con la directiva
one
de enrutamiento, la ruta debe coincidir con ocomm-one
comm-two
.Para coincidir
comm-one
, la ruta debe tener una comunidad que coincida con 1:2 y una comunidad que coincida con 4:5 o 4:6.Para coincidir
comm-two
, la ruta debe tener una comunidad que coincida con 7:8 y una comunidad que coincida con 9:10.
Múltiples coincidencias
Cuando se encuentran varias coincidencias, no se produce la agregación de etiquetas. Considere la siguiente configuración:
family inet-vpn { unicast { aggregate-label { community community-name; } } }
family inet-vpn { labeled-unicast { aggregate-label { community community-name; } } }
Supongamos, por ejemplo, que se reciben dos rutas con atributos target:65000:1000 origin:65200:2000
de comunidad y que el nombre de la comunidad es "5...:.*"
. En este caso, ambos atributos target:65000:1000
de comunidad extendida y origin:65200:2000
coinciden con la expresión regular del nombre de comunidad. En este caso, no se produce la agregación de etiquetas. En el ejemplo siguiente, el Label operation
campo muestra que las etiquetas no se agregan.
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101056 Push 101056 Communities: target:65000:1000 origin:65200:2000
Puede resolver este problema de cualquiera de las siguientes maneras:
Sea más específico en la expresión regular si el atributo de comunidad extendida del sitio de origen no se superpone con el de destino.
Especifique el lugar de origen en el nombre de la comunidad.
Ambos métodos se muestran en los ejemplos siguientes.
Sea más específico en la expresión regular
user@host# set policy-options community community-name members "52..:.*" user@host# commit
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000
Especifique el lugar de origen en el nombre de la comunidad
user@host# set policy-options community community-name members "origin:65...:.*" user@host# commit
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000
Invertir coincidencias de comunidad
La community
condición de coincidencia define una expresión regular y, si coincide con el atributo community del prefijo recibido, Junos OS devuelve un resultado TRUE. De lo contrario, Junos OS devuelve un resultado FALSE. La invert-match
instrucción hace que Junos OS se comporte de manera contraria. Si hay una coincidencia, Junos OS devuelve un resultado FALSE. Si no hay ninguna coincidencia, Junos OS devuelve un resultado VERDADERO. Para invertir los resultados de la coincidencia de expresiones de comunidad, incluya la invert-match
instrucción en la configuración de comunidad.
[edit policy-options community name] invert-match;
Tipo de comunidad extendida
Las expresiones regulares no tienen en cuenta el tipo de comunidad extendida. Considere, por ejemplo, los siguientes atributos de comunidad y nombre de comunidad.
Comunidades:
-
5200:1000
-
target:65000:1000
-
origin:65200:2000
Atributo de la comunidad:
-
miembros del nombre de la comunidad "5...:.*"
En este caso, tanto el atributo 5200:1000
de comunidad extendida como el atributo de comunidad extendida, origin:65200:2000
, coinciden con la expresión regular del nombre de la comunidad. Por lo tanto, la agregación de etiquetas no se produce, como se muestra aquí:
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: 5200:1000 target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101056 Push 101056 Communities: 5200:1000 target:65000:1000 origin:65200:2000
Puede resolver este problema mediante una expresión regular más específica. Por ejemplo, puede utilizar el carácter de anclaje (^
) para enlazar la ubicación de los dígitos, como se muestra a continuación:
user@host# set policy-options community community-name members "^5...:.*" user@host# commit
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: 5200:1000 target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: 5200:1000 target:65000:1000 origin:65200:2000
Con la implementación de la característica de comunidad grande en la versión 17.3, Junos OS comprueba que las comunidades extendidas o grandes coincidan con el BGP base o las comunidades de expresión regular BGP base. En otras palabras, una comunidad recibida solo puede compararse con el patrón de comunidad silvestre apropiado, como las comunidades normales contra las comunidades silvestres simples, las comunidades extendidas contra las comunidades silvestres extendidas y las comunidades grandes contra los patrones silvestres grandes. Por ejemplo, para permitir la publicidad de rutas que llevan la comunidad extendida de origen, use la origin:*:65020
expresión.
Varias comunidades se emparejan con la lógica ex-OR
Esto difiere de la lógica de coincidencia AND utilizada para las comunidades no extendidas en BGP.
Si, por ejemplo, se reciben cuatro rutas con dos conjuntos de atributos de comunidad, la expresión regular podría coincidir con ambos atributos de comunidad. Considere el siguiente ejemplo:
Comunidades—5200:1000 objetivo:65000:1000
Comunidades—objetivo:65000:1000 origen:65200:2000
Atributo de la comunidad—miembro del nombre de la comunidad [ "^5...:.*" origin:65.*:.* ]
Ambas etiquetas se agregan, como se muestra aquí:
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000 10.1.1.16/30 (1 entry, 1 announced) Label operation: Push 121104 Push 101104 Communities: 5200:1000 target:65000:1000 10.1.1.20/30 (1 entry, 1 announced) Label operation: Push 121104 Push 101104 Communities: 5200:1000 target:65000:1000
Un ejemplo más completo de los valores de la comunidad se muestra aquí:
user@host> show policy-options community community-name members [ "(^1...:*)|(^3...:*)|(^4...:*)" origin:2.*:* origin:3.*:* origin:6.*:* ]
Esta expresión regular coincide con valores de comunidad que comienzan con 1, 3 o 4, y coincide con valores de comunidad extendidos de origen de tipo cuyo valor administrativo comienza por 2, 3 o 6.
Inclusión de comunidades BGP y comunidades extendidas en condiciones de coincidencia de políticas de enrutamiento
Para incluir una comunidad BGP o una comunidad extendida en una condición de coincidencia de política de enrutamiento, incluya la community
condición en la from
instrucción de un término de política:
from { community [ names ]; }
Además, puede excluir explícitamente la información de la comunidad BGP con una ruta estática mediante la none
opción. Incluya esta opción cuando configure una ruta individual en la route
parte que desea anular una opción de comunidad especificada en la defaults
parte.
Puede incluir los nombres de varias comunidades en la community
condición de coincidencia. Si hace esto, solo una comunidad necesita coincidir para que se produzca una coincidencia (la coincidencia es efectivamente una operación OR lógica).