Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Aplicación de políticas

Descripción general de la aplicación de políticas

Los aplicadores de políticas le permiten realizar una vigilancia de tráfico sencilla en interfaces específicas o redes privadas virtuales (VPN) de capa 2 sin configurar un filtro de firewall. Para aplicar policías, incluya la instrucción:policer

Puede incluir estas instrucciones en los siguientes niveles jerárquicos:

  • [edit interfaces interface-name unit logical-unit-number family family]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family family]

En la instrucción, la familia de protocolos puede ser , , , , , o .familycccinetinet6mplstccvpls

En la instrucción, enumere el nombre de una plantilla de policía que se evaluará cuando se reciban paquetes del Protocolo de resolución de direcciones (ARP) en la interfaz.arp De forma predeterminada, se instala un aplicador de políticas ARP que se comparte entre todas las interfaces Ethernet en las que haya configurado la instrucción.family inet Si desea una vigilancia más estricta o indulgente de los paquetes ARP, puede configurar un aplicador de policía específico de la interfaz y aplicarlo a la interfaz. Puede configurar un aplicador ARP del mismo modo que lo haría con cualquier otro aplicador en el nivel jerárquico .[edit firewall policer] Si aplica este aplicador de policía a una interfaz, se reemplaza el aplicador de paquetes ARP predeterminado. Si elimina este aplicador de policía, el aplicador de policía predeterminado vuelve a surtir efecto.

  • Puede configurar un aplicador de políticas diferente en cada familia de protocolos en una interfaz, con un controlador de entrada y un aplicador de salida para cada familia. Al aplicar policías, puede configurar la familia , , , , o sólo, y un policía ARP sólo para el protocolo familiar.cccinetinet6mplstccvplsinet Cada vez que se hace referencia a un policer, se instala una copia independiente del policer en los componentes de reenvío de paquetes para esa interfaz.

  • Si aplica tanto los controladores como los filtros de firewall a una interfaz, los aplicadores de políticas de entrada se evalúan antes que los filtros de firewall de entrada y los aplicadores de políticas de salida se evalúan después de los filtros de firewall de salida. En la instrucción, enumere el nombre de una plantilla de policía que se evaluará cuando se reciban paquetes en la interfaz.input En la instrucción, enumere el nombre de una plantilla de policía que se evaluará cuando se transmitan paquetes en la interfaz.output

  • Para los suscriptores que terminan en enrutadores de la serie MX a través de una interfaz Ethernet agregada (AE) que abarca varios FPC, es posible que una tasa de suscriptor general supere la velocidad configurada porque el límite configurado en el aplicador se aplica por separado a cada interfaz del paquete AE. Así, por ejemplo, si pretende que un controlador en una interfaz AE de tres miembros ejecute un de , tendría que configurar el en el aplicador para tener en cuenta las tres interfaces en el AE (es decir, 200 Mbps por interfaz, para un total combinado de 600 Mbps).bandwidth-limit600mbandwidth-limit200m

  • Si aplica el aplicador de políticas a la interfaz , se aplica a los paquetes recibidos o transmitidos por el motor de enrutamiento.lo0

  • En las plataformas de la serie T, M120 y M320, si las interfaces están en el mismo FPC, los filtros o las políticas no actúan sobre la suma del tráfico que entra y sale de las interfaces.

Aplicación de políticas de agregado

Aplicación de políticas de agregado

De forma predeterminada, si aplica un aplicador de policía a varias familias de protocolos en la misma interfaz lógica, el aplicador restringe el tráfico para cada familia de protocolos individualmente. Por ejemplo, un aplicador de políticas con un límite de ancho de banda de 50 Mbps aplicado al tráfico IPv4 e IPv6 permitiría que la interfaz aceptara 50 Mbps de tráfico IPv4 y 50 Mbps de tráfico IPv6. Si aplica un controlador de control agregado, el controlador permitiría que la interfaz reciba solo 50 Mbps de tráfico IPv4 e IPv6 combinados.

Para configurar un aplicador de control de agregados, incluya la instrucción en el nivel de jerarquía:logical-interface-policer[edit firewall policer policer-template-name]

Para que el aplicador de políticas se trate como un agregado, debe aplicarlo a varias familias de protocolos en una única interfaz lógica incluyendo la instrucción:policer

Puede incluir estas instrucciones en los siguientes niveles jerárquicos:

  • [edit interfaces interface-name unit logical-unit-number family family]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family family]

En la instrucción, la familia de protocolos puede ser , , , , , o .familycccinetinet6mplstccvpls

Las familias de protocolo en las que no se aplica el policer no se ven afectadas por el policer. Por ejemplo, si configura una única interfaz lógica para aceptar tráfico MPLS, IPv4 e IPv6 y aplica el aplicador de política de interfaz lógica sólo a las familias de protocolos IPv4 e IPv6, el tráfico MPLS no está sujeto a las restricciones de .policer1policer1

Si aplica a una interfaz lógica diferente, hay dos instancias del aplicador de policía.policer1 Esto significa que Junos OS controla el tráfico en interfaces lógicas independientes por separado, no como un agregado, incluso si se aplica el mismo aplicador de interfaz lógica a varias interfaces lógicas en el mismo puerto de interfaz física.

Ejemplo: Aplicación de políticas de agregado

Configure dos políticas de interfaz lógica: aggregate_police1 y aggregate_police2. Aplicar al tráfico IPv4 e IPv6 recibido en la interfaz lógica.aggregate_police1 fe-0/0/0.0 Se aplica al tráfico CCC y MPLS recibido en la interfaz lógica fe-0/0/0.0.aggregate_police2 Esta configuración hace que el software cree sólo una instancia de y una instancia de .aggregate_police1aggregate_police2

Aplicar al tráfico IPv4 e IPv6 recibido en otra interfaz lógica.aggregate_police1fe-0/0/0.1 Esta configuración hace que el software cree una nueva instancia de , una que se aplica a la unidad 0 y otra que se aplica a la unidad 1.aggregate_police1

Aplicación de políticas jerárquicas en PIC de colas inteligentes mejoradas

Aplicación de políticas jerárquicas en PIC de colas inteligentes mejoradas

Los enrutadores perimetrales M40e, M120 y M320, así como los enrutadores de núcleo serie T con PIC de cola inteligente mejorada (IQE) admiten políticas jerárquicas en la dirección de entrada y permiten aplicar un aplicador jerárquico para los niveles de tráfico premium y agregado (premium más normal) a una interfaz. Los aplicadores jerárquicos proporcionan funcionalidad cruzada entre la interfaz física configurada y el motor de reenvío de paquetes.

Antes de comenzar, hay algunas restricciones generales que se aplican a los policías jerárquicos:

  • Solo se puede configurar un tipo de aplicador para una interfaz lógica o física. Por ejemplo, no se permite un controlador jerárquico ni un controlador regular en la misma dirección para la misma interfaz lógica.

  • No se permite el encadenamiento de los policías, es decir, la aplicación de políticas tanto a un puerto como a las interfaces lógicas de ese puerto.

  • Hay un límite de 64 políticas por interfaz en caso de que no haya una clasificación BA, lo que proporciona una sola política por DLCI.

  • Solo se puede aplicar un tipo de aplicador en una interfaz física o lógica.

  • El policía debe ser independiente de la clasificación BA. Sin la clasificación BA, todo el tráfico de una interfaz se tratará como EF o no EF, según la configuración. Con la clasificación BA, una interfaz puede admitir hasta 64 policías. Una vez más, la interfaz aquí puede ser una interfaz física o una interfaz lógica (por ejemplo, DLCI).

  • Con la clasificación BA, el tráfico misceláneo (el tráfico que no coincide con ninguno de los bits DSCP/EXP de la clasificación BA) se vigilará como tráfico no EF. No se instalarán políticas independientes para este tráfico.

Descripción general de Hierarchical Policer

La vigilancia jerárquica utiliza dos grupos de tokens, uno para el tráfico agregado (no EF) y otro para el tráfico premium (EF). El tráfico que es EF y el que no es EF viene determinado por la configuración de clase de servicio. Lógicamente, la vigilancia jerárquica se logra encadenando a dos policías.

Figura 1: Jerárquico PolicerJerárquico Policer

En el ejemplo de , el tráfico EF es vigilado por Premium Policer y el tráfico que no es EF es vigilado por Aggregate Policer.Figura 1 Lo que esto significa es que, para el tráfico EF, la acción fuera de especificación será la que está configurada para Premium Policer, pero el tráfico EF dentro de la especificación seguirá consumiendo los tokens del Aggregate Policer.

Pero el tráfico EF nunca se someterá a la acción fuera de especificación del Aggregate Policer. Además, si la acción fuera de especificación del Aplicador Premium no está establecida en Descartar, esos paquetes fuera de especificación no consumirán los tokens del Aplicador de agregados. Aggregate Policer solo controla el tráfico que no es EF. Como puede ver, el bucket de tokens Aggregate Policer puede volverse negativo si todos los tokens son consumidos por el tráfico que no es EF y luego obtiene ráfagas de tráfico EF. Pero eso será por un tiempo muy corto, y durante un período de tiempo promediará. Por ejemplo:

  • Premium Policer: Ancho de banda 2 Mbps, Acción OOS: Deseche

  • Aplicador de políticas agregadas: Ancho de banda 10 Mbps, Acción OOS: Deseche

En el caso anterior, el tráfico EF tiene garantizado 2 Mbps y el tráfico no EF obtendrá de 8 Mbps a 10 Mbps, dependiendo de la velocidad de entrada del tráfico EF.

Características policiales jerárquicas

Las características jerárquicas del bucket de tokens incluyen:

  • El tráfico de entrada se clasifica primero en tráfico EF y no EF antes de aplicar un aplicador de políticas:

    • La clasificación se realiza mediante la búsqueda Q-tree

  • El número de canal selecciona un aplicador de control de bucket de token compartido:

    • El controlador de bucket de token dual se divide en dos aplicadores de bucket únicos:

      • Policer1: tráfico EF

      • Policer2: tráfico que no es EF

  • El bucket de token compartido se utiliza para vigilar el tráfico de la siguiente manera:

    • Policer1 se establece en velocidad EF (por ejemplo, 2 Mbps)

    • Policer2 se establece para agregar la velocidad de vigilancia de la interfaz (por ejemplo, 10 Mbps).

    • El tráfico EF se aplica a Policer1.

      • Si el tráfico está dentro de las especificaciones, se le permite pasar y disminuir desde Policer1 y Policer2.

      • Si el tráfico está fuera de especificación, se puede descartar o marcar con un nuevo FC o prioridad de pérdida. Policer2 no hará nada con el tráfico EF fuera de especificación.

    • El tráfico que no es EF solo se aplica a Policer2.

      • Si el tráfico está dentro de las especificaciones, se le permite pasar a través y disminuir Policer2.

      • Si el tráfico está fuera de especificación, se descarta o se marca con un nuevo FC o se establece con una nueva prioridad de caída.

  • Límite de velocidad de la velocidad del puerto a la velocidad deseada en la capa 2

  • Limitar la velocidad del tráfico de EF

  • Limitar la velocidad del tráfico que no es EF

  • Gotas policiales contadas por color

Configuración de políticas jerárquicas

Para configurar un aplicador jerárquico, aplique la instrucción a la clase de reenvío adecuada y configure un aplicador jerárquico para los niveles agregado y premium.policing-priority Para obtener más información acerca de la clase de servicio, consulte la Guía del usuario de la clase de servicio de Junos OS para dispositivos de enrutamiento.https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/cos/config-guide-cos.html

Nota:

Los aplicadores jerárquicos solo se pueden configurar en interfaces físicas SONET alojadas en una PIC IQE. Solo se admiten los niveles agregado y premium.

Configuración CoS de clases de reenvío para aplicadores jerárquicos

Para obtener información detallada sobre la configuración y las instrucciones de clase de servicio, consulte la Guía del usuario de clase de servicio de Junos OS para dispositivos de enrutamiento.https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/cos/config-guide-cos.html

Configuración del firewall para aplicadores jerárquicos

Puede aplicar el aplicador de control jerárquico de la siguiente manera:

También tiene la opción de aplicar el aplicador de políticas en el nivel de puerto físico de la siguiente manera:

Configuración de un aplicador de dos colores de velocidad única

Puede configurar un aplicador de dos colores de velocidad única de la siguiente manera:

Puede aplicar el aplicador de políticas de la siguiente manera:

También tiene la opción de aplicar el aplicador de políticas en el nivel de puerto físico de la siguiente manera:

Configuración de un aplicador de control daltónico de tasa única

Esta sección describe a los policías daltónicos y conscientes del color de una sola tasa.

Puede configurar un controlador de daltónico de tasa única de la siguiente manera:

Puede aplicar el controlador de daltónico de tasa única de la siguiente manera:

Puede configurar un aplicador con reconocimiento de color de tasa única de la siguiente manera:

Puede aplicar el aplicador de control con reconocimiento de color de tasa única de la siguiente manera:

También tiene la opción de aplicar el aplicador de políticas en el nivel de puerto físico de la siguiente manera:

Configuración de un analizador de marcadores tricolor de dos velocidades

La policía de ingreso se implementa utilizando un marcador tricolor de dos tasas (trTCM). Esto se hace con un bucket de token dual (DTB) que mantiene dos tasas, confirmada y un pico. La vigilancia estática de salida también usa un bucket de tokens.

Los buckets de tokens realizan las siguientes funciones de vigilancia de entrada:

  • (1K) trTCM - Cubo de token dual (marcado rojo, amarillo y verde)

  • La vigilancia se basa en el tamaño del paquete de capa 2:

    • Después del ajuste de +/- byte desplazado

  • El marcado es consciente del color y daltónico:

    • El color consciente debe tener el color establecido por la búsqueda de árbol q en función de:

      • TDS

      • EXP

  • Acciones de marcado programables:

    • Color (rojo, amarillo, verde)

    • Caída basada en el color y el perfil de congestión

  • Policer se selecciona en función del número de canal que llega:

    • La LUT de número de canal genera un índice de policía y un índice de cola

    • Varios canales pueden compartir el mismo aplicador de políticas (la LUT produce el mismo índice de aplicador de políticas)

  • Apoyar la vigilancia de ingreso y la trTCM en los siguientes niveles:

    • Cola

    • Interfaz lógica (ifl/DLCI)

    • Interfaz física (ifd)

    • Puerto físico (controlador ifd)

    • Cualquier combinación de interfaz lógica, interfaz física y puerto

  • Porcentaje de soporte de velocidad de interfaz y bits por segundo

Los límites de velocidad se pueden aplicar a las colas seleccionadas en la entrada y en las colas predefinidas en la salida. El bucket de tokens funciona en los modos consciente del color y daltónico (especificado por RFC 2698).

Configuración de un trTCM daltónico

Puede aplicar el aplicador de tres colores y dos velocidades daltónicas de la siguiente manera:

También tiene la opción de aplicar el aplicador de políticas en el nivel de puerto físico de la siguiente manera:

Configuración de un trTCM consciente del color

Puede aplicar el aplicador de control de color de dos velocidades de tres colores de la siguiente manera:

También tiene la opción de aplicar el aplicador de políticas en el nivel de puerto físico de la siguiente manera: