Sé que la vigilancia del tráfico no es algo que normalmente se encuentra en un entorno LAN, y desearía no encontrarlo en el mío. Dicho esto ... no tengo otra opción.
El dispositivo es un 3750X. El requisito es POLICIAR (no configurar) todo el tráfico que llega a / desde las redes 10.0.0.0 y 10.0.1.0 a un MÁXIMO de ~ 48Mbps. A continuación se muestra la configuración que se me ocurrió. ¿Qué te parece? Además, sé que probablemente debería tener esto configurado en la interfaz de entrada, pero esa es otra historia ...
ip access-list extended acl-police
permit ip 10.0.0.0 0.0.0.255 10.0.1.0 0.0.0.255
permit ip 10.0.1.0 0.0.0.255 10.0.0.0 0.0.0.255
!
class-map police-san
match access-group name acl-police
!
policy-map police-san-replication
class police-san
police 47000000 10000 20000 conform-action transmit exceed-action drop
interface <outbound>
service-policy output police-san-replication
Otra cosa ... ¿Alguien puede explicarme el "burst-normal" y "burst-max" ? ¿Esto le permite estallar por encima del límite policial (bps) que definí? ¿Cuáles son los umbrales de temporizador para eso? ¿Debo configurar estos números de ráfaga más pequeños? Más grande?
fuente
Respuestas:
Usaría la vigilancia basada en vlan que funciona mejor en estos conmutadores. Este es un ejemplo que coincide con un valor de velocidad de 48Mb
Según la política principal, debe 'establecer' algo para que funcione. Esto podría ser cualquier cosa, así que en este ejemplo simplemente estoy configurando el dscp a 0
fuente
Sus valores de ráfaga se ven un poco pequeños. Elegir valores de ráfaga no es fácil y es posible que se requieran pruebas para hacerlo bien. Además, si no recuerdo mal, 3750 no admite la vigilancia en la salida.
Bc funciona un poco diferente en la vigilancia que en la configuración. Con la configuración de los paquetes del búfer y tiene un depósito de tokens donde sea que Tc (intervalo de tiempo) tenga bytes Bc (ráfaga comprometida) agregados al depósito. La fórmula es Tc = Bc / CIR. En algunas plataformas, Tc también es fijo, por lo que no tiene la opción de configurarlo.
Cuando usa vigilancia no usa intervalos de tiempo fijos. En cambio, cuando llega el paquete, el regulador calcula cuántos bytes se han acumulado. Digamos que está vigilando a 10 Mbit / s. Ha configurado un Bc de 10000 bytes. Un paquete de ráfaga llega a t0 que conforman 5000 bytes de tráfico. Entonces se deducen 5000 bytes. Luego, a t1 5 ms más tarde, llega otro lote de 5000 bytes de paquetes. El regulador está configurado a 10 Mbit / s, que es 1250000 bytes por segundo. Eso significa que 1250000 * 0,005 = 6250 bytes se han agregado a los 5000 que quedaron de la primera ejecución en t0. Entonces se permiten los paquetes.
A partir de este ejemplo, puede ver que en t1 se le podría haber permitido enviar 5000 + 6250 = 11250 bytes, pero debido a que Bc se configuró en 10000 bytes, el regulador dejaría cualquier cosa por encima de eso. ¿Qué pasaría si hubieran llegado 6000 bytes de paquetes? Entonces algunos paquetes tendrían que ser descartados. Aquí es donde entra en juego Be. Be permitirá acumular un poco de crédito extra de los intervalos inactivos. Entonces, si Be se hubiera configurado para ser 20000 bytes, entonces los 6000 bytes podrían haberse pasado a través del regulador.
Be agrega un poco de justicia al agente de policía, pero también permite el paso de grandes ráfagas de tráfico. Recuerde que al final el CIR aún se aplica, por lo que, en promedio, no es posible enviar más que CIR.
Este artículo de Juniper recomienda establecer una ráfaga de tráfico de 5 ms, que en su caso sería de 6250000 bytes.
fuente
No creo que la vigilancia de salida funcione en esta plataforma, pero necesitaría usar SRR, y francamente siempre es preferible dar forma cuando sea posible.
Habilitar 'mls qos' willy-nilly en 3750 puede ser una receta para el desastre, los valores predeterminados son horribles, por ejemplo, EF se controla al 4%. Entonces al menos deberías leer:
Para ingresar, su configuración sugerida debería funcionar.
Me gustaría ofrecer algunas ideas adicionales sobre el dimensionamiento de su búfer CIR, sé que la tradición tradicional de Cisco CCO habla de RTT, pero RTT en realidad no tiene nada que ver con policer, ya que su enrutador / conmutador no le importa cuánto tiempo ha estado en el paquete -vuelo cuando llegue. Lo que es de importancia clave es la velocidad de la interfaz de entrada, ya que la velocidad física de la interfaz de entrada determina qué tan rápido se está llenando su 'cubo' y la velocidad de vigilancia determina qué tan rápido se vacía.
La fórmula JNPR (burst_time * interface_rate) es una regla práctica bastante útil, por lo que si tiene una interfaz de entrada 10G y tiene un regulador de salida de 1 Mbps en la interfaz A y un regulador de salida de 100 Mbps en la interfaz B, ambos policías [AB] deben tener el mismo búfer CIR , digamos 10G * 5ms para manejar la ráfaga de 5ms, solo ajuste el tiempo para que se ajuste al estallido de su perfil de tráfico.
Estoy usando 'CIR Buffer' generosamente, ya que técnicamente la vigilancia no agrega buffering fuera de sus buffers de interfaz normales. Simplemente significa cuántos bytes se enviarán, sin aplicar policer. Esto es necesario, ya que de lo contrario cada paquete excedería la tasa de vigilancia y la tasa observable sería 0.
fuente