Évaluation des communautés BGP et des communautés étendues dans les conditions de correspondance des stratégies de routage

Lorsque vous utilisez des communautés BGP et des communautés étendues comme conditions de correspondance dans une stratégie de routage, le logiciel Policy Framework les évalue comme suit :

Chaque route est évaluée par rapport à chaque communauté nommée dans une instruction de stratégie de routage from . Si un itinéraire correspond à l’une des communautés nommées dans l’énoncé from , l’évaluation du terme actuel se poursuit. Si un itinéraire ne correspond pas, l’évaluation du terme en cours se termine.
L’itinéraire est évalué par rapport à chaque membre d’une communauté nommée. L’évaluation de tous les membres doit être réussie pour que l’évaluation de la communauté désignée soit réussie.
Chaque membre d’une communauté nommée est identifié soit par une valeur communautaire littérale, soit par une expression régulière. Chaque membre est évalué par rapport à chaque communauté associée à l’itinéraire. (Les communautés sont une propriété non ordonnée d’un itinéraire. Par exemple, 1:2 3:4 est identique à 3:4 1:2.) Une seule communauté de l’itinéraire doit être jumelée pour que l’évaluation des membres soit réussie.
Les expressions régulières de la communauté sont évaluées caractère par caractère. Par exemple, si une route contient la communauté 1234:5678, les expressions régulières voient neuf caractères discrets, y compris les deux-points (:), au lieu de deux ensembles de nombres (1234 et 5678) séparés par un deux-points. Par exemple :
Si un membre de la communauté est une expression régulière, une correspondance de chaîne est établie plutôt qu’une correspondance numérique.

Par exemple :
Étant donné une route avec une valeur de communauté de 1100:100, cette route correspond community example2 mais pas example1à .
Pour correspondre à la stratégie de routage one, l’itinéraire doit correspondre à ou comm-onecomm-two.
Pour correspondre comm-oneà , l’itinéraire doit avoir une communauté qui correspond à 1:2 et une communauté qui correspond à 4:5 ou 4:6.
Pour correspondre comm-twoà , l’itinéraire doit avoir une communauté qui correspond à 7:8 et une communauté qui correspond à 9:10.

Correspondances multiples

Lorsque plusieurs correspondances sont trouvées, l’agrégation d’étiquettes ne se produit pas. Prenons l’exemple de la configuration suivante :

Supposons, par exemple, que deux routes soient reçues avec des attributs target:65000:1000 origin:65200:2000 de communauté et que le nom de la communauté soit "5...:.*". Dans ce cas, target:65000:1000 les attributs de la communauté étendue et origin:65200:2000 correspondent à l’expression régulière du nom de la communauté. Dans ce cas, l’agrégation d’étiquettes n’a pas lieu. Dans l’exemple suivant, le Label operation champ indique que les étiquettes ne sont pas agrégées.

Vous pouvez résoudre ce problème de l’une des manières suivantes :

Soyez plus précis dans l’expression régulière si l’attribut de communauté étendue du site d’origine ne chevauche pas l’attribut cible.
Spécifiez le site d’origine dans le nom de la communauté.

Les deux méthodes sont illustrées dans les exemples suivants.

Soyez plus précis dans l’expression régulière

Précisez le site d’origine dans le nom de la communauté

Inversion des correspondances de la communauté

La community condition de correspondance définit une expression régulière et si elle correspond à l’attribut community du préfixe reçu, Junos OS renvoie un résultat TRUE. Sinon, Junos OS renvoie un résultat FALSE. Cette invert-match déclaration fait en sorte que Junos OS se comporte différemment. En cas de correspondance, Junos OS renvoie un résultat FALSE. S’il n’y a pas de correspondance, Junos OS renvoie un résultat TRUE. Pour inverser les résultats de la correspondance d’expression de communauté, incluez l’instruction invert-match dans la configuration de la communauté.

Type de communauté étendue

Le type de communauté étendue n’est pas pris en compte par les expressions régulières. Considérez, par exemple, les attributs et le nom de communauté suivants.

Communautés:

5200:1000
target:65000:1000
origin:65200:2000

Attribut de la communauté :

membres du nom de la communauté « 5... :.* »

Dans ce cas, l’attribut 5200:1000 de communauté étendue et l’attribut origin:65200:2000de communauté étendue , correspondent à l’expression régulière du nom de la communauté. Par conséquent, l’agrégation d’étiquettes ne se produit pas, comme illustré ici :

Vous pouvez résoudre ce problème à l’aide d’une expression régulière plus spécifique. Par exemple, vous pouvez utiliser le caractère d’ancrage (^) pour lier l’emplacement des chiffres, comme indiqué ici :

REMARQUE :

Avec l’implémentation de la fonctionnalité Grande communauté dans la version 17.3, Junos OS vérifie pour empêcher la mise en correspondance de communautés étendues ou étendues avec BGP de base ou les communautés d’expressions régulières BGP de base. En d’autres termes, une communauté reçue ne peut être comparée qu’au modèle de communauté sauvage approprié, comme les communautés normales contre les simples sauvages, les communautés étendues contre les étendues sauvages et les grandes communautés contre les grands modèles sauvages. Par exemple, pour permettre la publicité d’itinéraires portant la communauté étendue d’origine, utilisez l’expression origin:*:65020 .

Plusieurs communautés sont mises en correspondance avec une logique Ex-OR

Cela diffère de la logique de correspondance ET utilisée pour les communautés non étendues dans BGP.

Si, par exemple, quatre routes sont reçues avec deux ensembles d’attributs de communauté, l’expression régulière peut correspondre aux deux attributs de communauté. Prenons l’exemple suivant :

Communautés : 5200:1000, cible :65000:1000
Communautés : cible :65000:1000 origine :65200:2000
Attribut de communauté : nom de la communauté membre [ « ^5... :.* » origine :65.* :.* ]

Les deux étiquettes sont agrégées, comme illustré ci-dessous :

Un exemple plus complet des valeurs communautaires est présenté ici :

Cette expression régulière correspond aux valeurs de communauté commençant par 1, 3 ou 4 et correspond aux valeurs de communauté étendues de type origin dont la valeur administrative commence par 2, 3 ou 6.

Inclusion des communautés BGP et des communautés étendues dans les conditions de correspondance de la stratégie de routage

Pour inclure une communauté BGP ou une communauté étendue dans une condition de correspondance de stratégie de routage, incluez la community condition dans l’énoncé from d’un terme de stratégie :

En outre, vous pouvez exclure explicitement les informations de communauté BGP avec une route statique à l’aide de l’option none . Incluez cette option lors de la configuration d’un itinéraire individuel dans la route portion pour remplacer une option de communauté spécifiée dans la defaults partie.

Vous pouvez inclure les noms de plusieurs communautés dans la community condition de correspondance. Si vous faites cela, une seule communauté doit correspondre pour qu’une correspondance se produise (la correspondance est en fait une opération logique OU).

Sur cette page