Descripción general del walkup para filtros de ruta
Utilice la función de seguimiento si le preocupa el rendimiento de las políticas debido a los filtros de ruta dividida en varios términos de política. La función de walkup permite la consolidación de filtros de ruta bajo un término de política.
De forma predeterminada, Junos evalúa varios filtros de ruta en un término de instrucción de política encontrando primero el prefijo de coincidencia más largo y, luego, evaluando las condiciones adjuntas al filtro de ruta, como el intervalo de prefijos. Si la condición del filtro de ruta es false (por ejemplo, el prefijo no está en el rango especificado), entonces el término completo es false, incluso si hay prefijos potencialmente verdaderos de filtro de ruta más corto. Debido a este comportamiento, puede haber problemas de rendimiento si los filtros de ruta se dividen en términos de instrucción de política individual. La función de walkup cambia el comportamiento predeterminado del filtro de ruta.
Algunas herramientas de políticas automatizadas , por ejemplo, las que se utilizan para enrutadores de borde de sistema autónomo en el Protocolo de puerta de enlace de borde (BGP) de borde, dividen los filtros de ruta en varios términos debido al comportamiento predeterminado del filtro de ruta. Los filtros de ruta también se utilizan en protocolos de enrutamiento distintos al BGP; la función de walkup no se limita a los filtros de ruta del BGP.
Técnicamente, el BGP no trata las rutas de la misma manera que OSPF o IS-IS. Las "rutas" del BGP se denominan más correctamente actualizaciones de información de accesibilidad de capa de red (NLRI). Sin embargo, el término "ruta" se utiliza en la mayoría de la documentación y se utiliza aquí.
Los filtros de ruta constan de tres partes principales:
Longitud de prefijo y prefijo (por ejemplo,
10.0.0.0/8)Una condición de coincidencia (por ejemplo,
exact)Una acción que se lleva a cabo si ambas partes anteriores (el prefijo y la condición de coincidencia) se evalúan como true (por ejemplo,
accept)
Por lo tanto, el 10.0.0.0/8 exact accept filtro de ruta tiene éxito si y solo si el prefijo considerado es 10.0.0.0/8 exactamente. Este filtro de ruta rechaza rutas con todos los demás prefijos más largos, como 10.0.0.0/10, aunque puede haber otros términos de filtro de ruta en la cadena de políticas que acepten la 10.0.0.0/10 ruta.
Aunque la ruta y las 10.0.0.0/8 variaciones no están específicamente reservados para la documentación, el espacio de direcciones privado de RFC 1918 10.0.0.0/8 se utiliza en este tema debido a la flexibilidad y los escenarios realistas que ofrece este espacio de direcciones.
Los filtros de ruta se pueden combinar en un solo término de instrucción de política. En ese caso, la evaluación se vuelve más compleja. Considere la siguiente política de enrutamiento:
[edit policy-options]
policy-statement RouteFilter-A {
term RouteFilter-1 {
from {
route-filter 10.0.0.0/16 prefix-length-range /22-/24;
route-filter 10.0.0.0/8 orlonger;
}
then accept;
}
term default {
then reject;
}
}
Tenga en cuenta que el 10.0.0.0/8 orlonger filtro incluye el 10.0.0.0/16 prefix-length-range /22-/24 filtro en su ámbito. Es decir, cualquier 10.0.0.0 ruta con un prefijo de 8 bits o más podría ser también una ruta con un prefijo en el rango entre 22 y 24 bits.
De forma predeterminada, la evaluación de un término de instrucción de política con varios filtros de ruta es un proceso de dos pasos:
El software del marco de políticas realiza una búsqueda de coincidencia más larga en la lista basada en valores de prefijo y longitud de prefijo.
El software considera la condición del filtro de ruta (
orlonger,exacty así sucesivamente). La ruta cumple la condición del filtro de ruta (éxito) o no coincide con la condición de filtro de ruta (error).
Según los resultados de estos dos pasos, la acción determinada por la coincidencia o el error se aplica a la ruta. En Route-Filter-A, esto significa que se acepta cualquier ruta que sea "true" y que cualquier ruta que sea "false" en el RouteFilter-1 término se rechaza. Esta ruta se convierte en una ruta oculta (filtrada).
Por ejemplo, considere lo que ocurre cuando la ruta 10.0.0.0/18 se evalúa mediante la instrucción de política RouteFilter-A:
En primer lugar, la 10.0.0.0/18 ruta se evalúa por el RouteFilter-1 término. Dado que 10.0.0.0/16 es más larga que 10.0.0.0/8, la 10.0.0.0/18 ruta coincide con el prefijo de ruta más largo y específico. A continuación, se produce un error en la coincidencia porque la 10.0.0.0/18 ruta no coincide con la prefix-length-range /22-/24 condición. Por lo tanto, la coincidencia de ruta falla en el RouteFilter-1 término, y la política examina el siguiente término, el plazo predeterminado. La 10.0.0.0/18 ruta se rechaza por el término predeterminado.
Como resultado, la 10.0.0.0/18 ruta se oculta (se filtra). (La 10.0.0.0/18 ruta aún se puede encontrar con el show route hidden comando.)
El problema es que el usuario puede realmente desear que la 10.0.0.0/18 ruta se acepte, no se rechace. Naturalmente, se podría agregar un filtro de ruta con una 10.0.0.0/18 exact configuración. Sin embargo, en una tabla de enrutamiento troncal con 100 000 o más entradas, no es posible configurar un filtro de ruta ajustado a cada ruta posible o a cada ruta nueva posible agregada a la red.
La solución predeterminada para lograr el comportamiento adecuado de la política de enrutamiento de ejemplo es configurar un término independiente para cada filtro de ruta. Esto se hace con frecuencia de la siguiente manera:
[edit policy-options]
policy-statement RouteFilter-A {
term RouteFilter-1 {
from {
route-filter 10.0.0.0/16 prefix-length-range /22-/24;
}
then accept;
}
term RouteFilter-2 {
from {
route-filter 10.0.0.0/8 orlonger;
}
then accept;
}
term default {
then reject;
}
}
Ahora la 10.0.0.0/18 ruta se acepta porque, aunque sigue fallando la RouteFilter-1 condición de coincidencia, coincide con el nuevo RouteFilter-2 término (10.0.0.0/8 es la coincidencia más larga, y la orlonger condición es verdadera). El problema de este enfoque es que ahora la política de enrutamiento completa tarda más tiempo en evaluarse que cuando se agrupan varios filtros de ruta. Este método también hace que el mantenimiento sea más complejo.
Los problemas con el enfoque de filtros de un término por ruta se resuelven con la instrucción y la característica walkup. El walkup altera el comportamiento predeterminado de la evaluación del filtro de ruta de forma global o por política.
La función de seguimiento permite que los términos con varios filtros de ruta "rebasen" el proceso de evaluación para incluir rutas menos específicas, así como la coincidencia más larga. En otras palabras, la perilla del walkup cambia el comportamiento predeterminado de "si uno falla, entonces el término falla" a si "uno coincide, entonces el término coincide".
Considere la aplicación de la función de seguimiento a la instrucción de política de ejemplo (también puede aplicar el tutorial globalmente a todas las políticas configuradas):
[edit policy-options]
policy-statement RouteFilter-A {
defaults {
route-filter walkup;
}
term RouteFilter-1 {
from {
route-filter 10.0.0.0/16 prefix-length-range /22-/24;
route-filter 10.0.0.0/8 orlonger;
}
then accept;
}
term default {
then reject;
}
}
Esto es lo que ocurre cuando el prefijo 10.0.0.0/18 de ruta es evaluado por la instrucción de política RouteFilter-A:
El comportamiento predeterminado se altera mediante la botón walkup. Como antes, la 10.0.0.0/18 ruta coincide con el prefijo de ruta más largo y específico, ya 10.0.0.0/16 que es más largo que 10.0.0.0/8. Como antes, esta coincidencia falla porque la 10.0.0.0/18 ruta no coincide con la prefix-length-range /22-/24 condición. Sin embargo, esta vez el proceso continúa con un "walk up" y examina el filtro de ruta menos específico 10.0.0.0/8 . La condición de ruta coincide orlonger con este filtro y, por lo tanto, la ruta es aceptada por el RouteFilter-1 término.
Esto se puede verificar (en el caso de una ruta BGP) mediante el show route protocol bgp 10.0.0.0/18 comando. Esta vez, la ruta no está oculta.
Si habilita la función de seguimiento globalmente, puede invalidarla localmente por política con la [edit policy-options policy-statements policy-statement-name defaults route-filter no-walkup] instrucción.