Calculemos a qué nos enfrentamos aquí. CAR es básicamente la versión anterior de la vigilancia de iOS, por lo que todos estos conceptos se aplican a ambos.
Committed Information Rate (CIR) = 5,000,000 (5Mbps)
Burst Commit Bucket (Bc) = 937,500
Burst Excess Bucket (Be) = 1,875,000
Time Interval (Tc) = Bc / CIR = 0.1875 s = 187.5 ms
La tasa a la que queremos restringir los flujos es de 5Mbps. El depósito de confirmación es de 937.500 bytes. El Cubo de ráfaga tiene 1,875,000 bytes. Y los cubos se vuelven a llenar cada 187,5 ms.
Como mencionó, IOS utiliza un mecanismo de depósito para restringir la cantidad de tráfico que puede pasar. ¡No suaviza el tráfico al X% del ancho de banda de la interfaz durante un período de tiempo arbitrario! En cambio, permite el acceso completo al ancho de banda de la interfaz siempre que tenga los tokens para pagarlo.
Además, dado que esto es vigilancia, RED / WRED no están en juego. RED solo ocurre cuando hay una cola para administrar. No hay almacenamiento en búfer / colas en la vigilancia, solo en la configuración.
Tratemos primero con el Bucket Commit (Bc). Suponga que no hay un exceso de depósito (Be) por ahora.
* Confirmar solo cubo (Policer bicolor) *
Este es un regulador muy estricto que solo le permitirá enviar dentro del CIR exactamente; sin estallar arriba. Solo hay un cubo, Bc. Hay dos "colores" para el tráfico, conforme y superior .
Tiempo = 0 ms: el depósito comienza lleno, con 937,500 bytes de tokens. Digamos que envía 7.500 bytes a través de la interfaz. Ahora IOS disminuye el depósito en 7,500 bytes, y el depósito ahora tiene 930,000 bytes en tokens. El tráfico enviado se considera "conforme" y se le aplica la "acción conforme".
Tiempo = 187.5 ms - Golpeamos el Tc ahora, y rellenamos el cubo Bc. Se agregan 937,500 bytes de tokens. Cualquier ficha extra se derrama y se pierde.
Tiempo = 190 ms: el depósito de confirmación tiene 937,500 tokens. Recibimos 2,000,000 bytes de tráfico. Los primeros 937.500 bytes se transfieren bien, ya que el depósito tiene tokens. El tráfico restante se considera "superior" y se trata de acuerdo con la "acción superior". Recuerde, no hay almacenamiento en búfer en la vigilancia (eso se llama modelado): puede transmitir, comentar y transmitir, o descartar.
Tiempo = 375 ms: golpeamos Tc nuevamente, y el cubo Bc se rellena con 937,500 tokens.
* Confirmar cubo con exceso de cubo (Policer tricolor) *
Opcionalmente, puede agregar un cubo de exceso (Be). Esto permite que el tráfico supere el segmento Bc de forma temporal. El CIR general debería permanecer igual. Este es un policía de tres "colores": conforme, superando y violando .
Tiempo = 0 ms: ambos segmentos (Bc y Be) comienzan llenos. Bc tiene 937,500 tokens, Be tiene 1,875,000 tokens.
Tiempo = 50 ms: llegan 2,000,000 bytes de tráfico. El enrutador primero disminuye los tokens de depósito Bc. Reduce el cubo Bc a cero. Los 937.500 bytes de tráfico cubiertos por Bc se consideran "conformes" y se les aplica la "acción conforme".
Eso deja 1,062,500 bytes de tráfico que aún no tiene tokens. Ahora el enrutador se sumerge en el cubo Be y resta 1.062.500 tokens para cubrir el resto del tráfico. Estos bytes se consideran "superiores" y se les aplicará la "acción superior". En su ejemplo, se eliminaría el tráfico, pero podría comentarlo o simplemente transmitirlo.
Si llevas la cuenta en casa, Bc ahora tiene cero fichas, Be tiene 812.500 fichas.
Tiempo = 75 ms: ahora, el enrutador recibe otros 1,200,000 bytes de tráfico. El cubo Bc está vacío, así que no hay ayuda allí. El depósito Be puede ayudar, por lo que cubre los primeros 812.500 bytes de tráfico con sus tokens, y ahora está vacío. Este tráfico se considera "superior" y se le aplicará la "acción superior".
Ahora los cubos están secos, pero todavía quedan 387.500 bytes para tratar. Este tráfico se considera "infractor" y siempre se elimina con CAR (puede hacer otras cosas con MQC y el comando de la policía con "infracción").
Tiempo = 187.5 ms - Ahora llegamos al primer intervalo Tc, tiempo para llenar nuestros cubos. ¡Un punto clave es que solose recargan los tokens por valor de Bc ! El cubo Bc se llena primero hasta 937,500. El cubo Be queda VACÍO.
Tiempo = 375 ms: ha sido silencioso y llegamos al siguiente intervalo de Tc. Se agregan tokens por valor de Bc al depósito de Bc. Dado que el depósito Bc ya está lleno, los tokens en exceso no se pierden, sino que se "derraman" en el depósito Be. Ahora el cubo Bc está lleno con 937,500 tokens y el cubo Be está parcialmente lleno con 937,500 tokens.
Tiempo = 562.5 ms - Silencio aún, y estamos en la próxima Tc. Los tokens por valor de Bc se agregan al depósito de Bc, que ya está lleno. Todo se derrama en el cubo Be (que ya tiene 937,500 tokens). El Be llena hasta 1,875,000 tokens.
* Notas finales *
Su configuración no está haciendo uso del cubo Be. Está limitando la velocidad / vigilando usando solo el depósito Bc, que puede tener efectos secundarios no deseados si el vigilante / modelador que le envía los datos no está configurado de manera idéntica y no está sincronizado en Tc.
CAR / rate-limit es muy antiguo y está en desuso. Considere cambiar a MQC y QoS moderna para implementar esto, ya que le dará más información y opciones.
Ignoro totalmente el retraso de serialización (el tiempo que lleva transmitir datos en la línea) anterior, y estoy bastante seguro de que las matemáticas no funcionan en un escenario real. Pero los conceptos son sólidos independientemente de los números exactos en uso.
* Ejemplo de MQC *
policy-map PM-FA0/0-IN
class class-default
police cir 5000000 bc 937500 be 1875000
!
interface Fa0/0
service-policy input PM-FA0/0-IN
!
* Fuentes *