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 policer instrucción:
policer { arp policer-template-name; input policer-template-name; output policer-template-name; }
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 family instrucción, la familia de protocolos puede ser ccc, inet, inet6, mplstcc, , o vpls.
En la arp 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. 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 family inet instrucción. 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
ccc,inet, ,tccmplsinet6, ovplssólo, y un policía ARP sólo para el protocolo familiarinet. 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
inputinstrucción, enumere el nombre de una plantilla de policía que se evaluará cuando se reciban paquetes en la interfaz. En laoutputinstrucción, enumere el nombre de una plantilla de policía que se evaluará cuando se transmitan paquetes en la interfaz.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
bandwidth-limitde 600m, tendría que configurar elbandwidth-limiten el aplicador 200m para tener en cuenta las tres interfaces en el AE (es decir, 200 Mbps por interfaz, para un total combinado de 600 Mbps).Si aplica el aplicador de políticas a la interfaz
lo0, se aplica a los paquetes recibidos o transmitidos por el motor de enrutamiento.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 logical-interface-policer instrucción en el nivel de [edit firewall policer policer-template-name] jerarquía:
[edit firewall policer policer-template-name] logical-interface-policer;
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 policer instrucción:
policer { arp policer-template-name; input policer-template-name; output policer-template-name; }
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 family instrucción, la familia de protocolos puede ser ccc, inet, inet6, mplstcc, , o vpls.
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 policer1 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 policer1.
Si aplica policer1 a una interfaz lógica diferente, hay dos instancias del aplicador de policía. 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 aggregate_police1 al tráfico IPv4 e IPv6 recibido en la interfaz fe-0/0/0.0 lógica. Se aplica aggregate_police2 al tráfico CCC y MPLS recibido en la interfaz lógica fe-0/0/0.0. Esta configuración hace que el software cree sólo una instancia de aggregate_police1 y una instancia de aggregate_police2.
Aplicar aggregate_police1 al tráfico IPv4 e IPv6 recibido en otra interfaz fe-0/0/0.1lógica. Esta configuración hace que el software cree una nueva instancia de aggregate_police1, una que se aplica a la unidad 0 y otra que se aplica a la unidad 1.
[edit firewall]
policer aggregate_police1 {
logical-interface-policer;
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 500k;
}
then {
discard;
}
}
policer aggregate_police2 {
logical-interface-policer;
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 200k;
}
then {
discard;
}
}
[edit interfaces fe-0/0/0]
unit 0 {
family inet {
policer {
input aggregate_police1;
}
}
family inet6 {
policer {
input aggregate_police1;
}
}
family ccc {
policer {
input aggregate_police2;
}
}
family mpls {
policer {
input aggregate_police2;
}
}
}
unit 1 {
family inet {
policer {
input aggregate_police1;
}
}
family inet6 {
policer {
input 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.
En el ejemplo de Figura 1, el tráfico EF es vigilado por Premium Policer y el tráfico que no es EF es vigilado por Aggregate Policer. 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: Descartar
Aplicador de políticas agregadas: Ancho de banda 10 Mbps, Acción OOS: Descartar
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
Consulte también
Configuración de políticas jerárquicas
Para configurar un aplicador jerárquico, aplique la policing-priority instrucción a la clase de reenvío adecuada y configure un aplicador jerárquico para los niveles agregado y premium. 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.
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
[edit class-of-service forwarding-classes] class fc1 queue-num 0 priority high policing-priority premium; class fc2 queue-num 1 priority low policing-priority normal; class fc3 queue-num 2 priority low policing-priority normal; class fc4 queue-num 3 priority low policing-priority normal;
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.
Configuración del firewall para aplicadores jerárquicos
[edit firewall hierarchical-policer foo]
aggregate {
if-exceeding {
bandwidth-limit 70m;
burst-size-limit 1500;
}
then {
discard;
}
premium {
if-exceeding {
bandwidth-limit 50m;
burst-size-limit 1500;
}
then {
discard;
}
}
Puede aplicar el aplicador de control jerárquico de la siguiente manera:
[edit interfaces so-0/1/0 unit 0 layer2-policer] input-hierarchical-policer foo;
También tiene la opción de aplicar el aplicador de políticas en el nivel de puerto físico de la siguiente manera:
[edit interfaces so-0/1/0 layer2-policer] input-hierarchical-policer foo;
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:
[edit firewall policer foo]
if-exceeding {
bandwidth-limit 50m;
burst-size-limit 1500;
}
then {
discard;
}
Puede aplicar el aplicador de políticas de la siguiente manera:
[edit interfaces so-0/1/0 unit 0 layer2-policer] input-policer foo;
También tiene la opción de aplicar el aplicador de políticas en el nivel de puerto físico de la siguiente manera:
[edit interfaces so-0/1/0 layer2-policer] input-policer foo;
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:
[edit firewall three-color-policer foo]
single-rate {
color-blind;
committed-information-rate 50m;
committed-burst-size 1500;
excess-burst-size 1500;
}
Puede aplicar el controlador de daltónico de tasa única de la siguiente manera:
[edit interfaces so-0/1/0 unit 0 layer2-policer] input-three-color foo;
Puede configurar un aplicador con reconocimiento de color de tasa única de la siguiente manera:
[edit firewall three-color-policer bar]
single-rate {
color-aware;
committed-information-rate 50m;
committed-burst-size 1500;
excess-burst-size 1500;
}
Puede aplicar el aplicador de control con reconocimiento de color de tasa única de la siguiente manera:
[edit interfaces so-0/1/0 unit 0 layer2-policer] input-three-color foo;
También tiene la opción de aplicar el aplicador de políticas en el nivel de puerto físico de la siguiente manera:
[edit interfaces so-0/1/0 layer2-policer] input-three-color bar;
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
[edit firewall three-color-policer foo]
two-rate {
color-blind;
committed-information-rate 50m;
committed-burst-size 1500;
peak-information-rate 100m;
peak-burst-size 3k;
}
Puede aplicar el aplicador de tres colores y dos velocidades daltónicas de la siguiente manera:
[edit interfaces so-0/1/0 unit 0 layer2-policer] input-three-color foo;
También tiene la opción de aplicar el aplicador de políticas en el nivel de puerto físico de la siguiente manera:
[edit interfaces so-0/1/0 layer2-policer] input-three-color foo;
Configuración de un trTCM consciente del color
[edit firewall three-color-policer bar]
two-rate {
color-aware;
committed-information-rate 50m;
committed-burst-size 1500;
peak-information-rate 100m;
peak-burst-size 3k;
}
Puede aplicar el aplicador de control de color de dos velocidades de tres colores de la siguiente manera:
[edit interfaces so-0/1/0 unit 0 layer2-policer] input-three-color bar;
También tiene la opción de aplicar el aplicador de políticas en el nivel de puerto físico de la siguiente manera:
[edit interfaces so-0/1/0 layer2-policer] input-three-color bar;