Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Vue d’ensemble de Walkup for Route Filters

Utilisez la fonctionnalité sans rendez-vous si vous avez des inquiétudes quant aux performances des stratégies en raison de filtres d’itinéraire fractionnés sur plusieurs termes de stratégie. La fonctionnalité walkup permet de consolider les filtres d’itinéraire sous un seul terme de stratégie.

Par défaut, Junos évalue plusieurs filtres de routage dans un terme d’énoncé de stratégie en trouvant d’abord le préfixe de correspondance le plus long, puis en évaluant les conditions attachées au filtre de routage, telles que la plage de préfixes. Si la condition de filtre de route a la valeur false (par exemple, si le préfixe n’est pas dans la plage spécifiée), le terme entier est false, même s’il existe potentiellement de vrais préfixes de filtre de route plus courtes. En raison de ce comportement, il peut y avoir des problèmes de performances si les filtres de routage sont divisés en termes d’énoncé de stratégie individuels. La fonction walkup modifie le comportement du filtre d’itinéraire par défaut.

Certains outils de stratégie automatisés (par exemple, ceux utilisés pour les routeurs de bordure de système autonome dans le Border Gateway Protocol (BGP), divisent les filtres de route en plusieurs termes en raison du comportement de filtre de route par défaut. Les filtres de routage sont également utilisés dans les protocoles de routage autres que BGP ; la fonctionnalité walkup ne se limite pas aux filtres de routage BGP.

REMARQUE :

Techniquement, BGP ne gère pas les routes de la même manière qu’OSPF ou IS-IS. Les « routes » BGP sont plus correctement appelées mises à jour des informations d’accessibilité de la couche réseau (NLRI). Cependant, le terme « route » est utilisé dans la plupart des documents et est utilisé ici.

Les filtres de route se composent de trois parties principales :

  1. Un préfixe et une longueur de préfixe (par exemple, 10.0.0.0/8)

  2. Une condition de correspondance (par exemple, exact)

  3. Action effectuée si les deux parties précédentes (le préfixe et la condition de correspondance) ont toutes deux la valeur true (par exemple, accept)

Ainsi, le filtre de route réussit si et seulement si le 10.0.0.0/8 exact accept préfixe considéré est 10.0.0.0/8 exact. Ce filtre de route rejette les routes avec tous les autres préfixes plus longs, tels que , bien qu’il 10.0.0.0/10puisse y avoir d’autres termes de filtre de route dans la chaîne de stratégie qui acceptent la 10.0.0.0/10 route.

REMARQUE :

Bien que l’itinéraire et les variantes ne soient pas spécifiquement réservés à la documentation, l’espace d’adressage privé RFC 1918 10.0.0.0/8 est utilisé dans cette rubrique en raison de la flexibilité et des scénarios réalistes qu’il 10.0.0.0/8 fournit.

Les filtres de routage peuvent être combinés en un seul terme d’énoncé de stratégie. Dans ce cas, l’évaluation devient plus complexe. Envisagez la stratégie de routage suivante :

Notez que le filtre inclut le 10.0.0.0/8 orlonger filtre dans son champ d’application 10.0.0.0/16 prefix-length-range /22-/24 . C’est-à-dire que toute 10.0.0.0 route avec un préfixe de 8 bits ou plus peut également être une route avec un préfixe compris entre 22 et 24 bits.

Par défaut, l’évaluation d’un terme d’énoncé de stratégie avec plusieurs filtres de routage est un processus en deux étapes :

  1. Le logiciel Policy Framework effectue une recherche de la correspondance la plus longue de la liste en fonction des valeurs de préfixe et de longueur de préfixe.

  2. Le logiciel prend en compte la condition du filtre de routage (orlonger, exact, etc.). L’itinéraire remplit la condition de filtre de routage (succès) ou ne correspond pas à la condition de filtre de routage (échec).

En fonction des résultats de ces deux étapes, l’action déterminée par la correspondance ou l’échec est appliquée à l’itinéraire. Dans Route-Filter-A, cela signifie que toute route qui est « vraie » est acceptée et toute route qui est « fausse » dans le RouteFilter-1 terme est rejetée. Cette route devient une route cachée (filtrée).

Par exemple, considérez ce qui se passe lorsque la route 10.0.0.0/18 est évaluée par l’énoncé RouteFilter-Ade stratégie :

Tout d’abord, l’itinéraire 10.0.0.0/18 est évalué par le RouteFilter-1 terme. Étant donné que 10.0.0.0/16 est plus long que 10.0.0.0/8, la 10.0.0.0/18 route correspond au préfixe de route le plus long et le plus spécifique. Ensuite, la correspondance échoue car l’itinéraire 10.0.0.0/18 ne correspond pas à la prefix-length-range /22-/24 condition. Par conséquent, la correspondance de route échoue dans le terme et la stratégie examine le terme suivant, le RouteFilter-1 terme par défaut. L’itinéraire 10.0.0.0/18 est rejeté par le terme par défaut.

Par conséquent, l’itinéraire 10.0.0.0/18 est masqué (filtré). (L’itinéraire 10.0.0.0/18 peut toujours être trouvé à l’aide de la show route hidden commande.)

Le problème réside dans le fait que l’utilisateur peut souhaiter que l’itinéraire 10.0.0.0/18 soit accepté, et non rejeté. Naturellement, un filtre de route avec une 10.0.0.0/18 exact configuration pourrait être ajouté. Toutefois, dans une table de routage de réseau dorsal comptant 100 000 entrées ou plus, il n’est pas possible de configurer un filtre de routage adapté à chaque route possible ou à chaque nouvelle route ajoutée au réseau.

La solution par défaut pour obtenir le comportement approprié de l’exemple de stratégie de routage consiste à configurer un terme distinct pour chaque filtre de routage. Cela se fait fréquemment, comme suit :

Désormais, la route est acceptée car, bien qu’elle échoue toujours à la condition de correspondance, elle correspond au nouveau RouteFilter-2 terme (10.0.0.0/8 est la correspondance la plus longue et la orlonger10.0.0.0/18RouteFilter-1 condition est vraie). Le problème avec cette approche est que l’évaluation de la stratégie de routage complète prend désormais plus de temps que lorsque plusieurs filtres de routage sont regroupés. Cette méthode rend également la maintenance plus complexe.

Les problèmes liés à l’approche d’un terme par filtre d’itinéraire sont résolus avec l’instruction et la fonctionnalité walkup. Walkup modifie le comportement par défaut de l’évaluation du filtre de route de manière globale ou par stratégie.

La fonction walkup permet aux termes avec plusieurs filtres d’itinéraire de « remonter » le processus d’évaluation pour inclure des itinéraires moins spécifiques ainsi que la correspondance la plus longue. En d’autres termes, le bouton walkup change le comportement par défaut de « si l’un d’entre eux échoue, alors le terme échoue » à « l’un d’entre eux correspond, alors le terme correspond ».

Envisagez l’application de la fonctionnalité walkup à l’exemple d’instruction de stratégie (vous pouvez également appliquer la représentation walk-up globalement à toutes les stratégies configurées) :

C’est ce qui se passe lorsque le préfixe 10.0.0.0/18 de route est évalué par l’instruction RouteFilter-Ade stratégie :

Le comportement par défaut est modifié par le bouton walkup. Comme précédemment, la 10.0.0.0/18 route correspond au préfixe de route plus long et plus spécifique car 10.0.0.0/16 est plus long que 10.0.0.0/8. Comme précédemment, cette correspondance échoue car l’itinéraire 10.0.0.0/18 ne correspond pas à la prefix-length-range /22-/24 condition. Cependant, cette fois-ci, le processus se poursuit par un « walk-up » et examine le filtre d’itinéraire moins spécifique 10.0.0.0/8 . La condition de route de orlonger correspond à ce filtre et, par conséquent, la route est acceptée par le RouteFilter-1 terme.

Cela peut être vérifié (pour une route BGP) par la show route protocol bgp 10.0.0.0/18 commande. Cette fois-ci, l’itinéraire n’est pas caché.

Si vous activez la fonctionnalité walkup globalement, vous pouvez la remplacer localement par stratégie avec l’instruction [edit policy-options policy-statements policy-statement-name defaults route-filter no-walkup] .

Rubriques connexes