Vamos calcular com o que estamos lidando aqui. O CAR é basicamente a versão mais antiga do policiamento do IOS, portanto todos esses conceitos se aplicam 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
A taxa para a qual queremos restringir os fluxos é de 5 Mbps. O depósito de confirmação é de 937.500 bytes. O bucket de explosão é de 1.875.000 bytes. E os baldes são recarregados a cada 187,5 ms.
Como você mencionou, o IOS usa um mecanismo de bucket para restringir a quantidade de tráfego que pode passar. Não suaviza o tráfego para X% da largura de banda da interface durante um período arbitrário! Em vez disso, permite acesso total à largura de banda da interface, desde que você tenha os tokens para pagar por ela.
Além disso, como isso é policiamento, RED / WRED não está em jogo. O VERMELHO só acontece quando há uma fila para gerenciar. Não há buffer / enfileiramento no policiamento, apenas na modelagem.
Vamos lidar primeiro com o Commit Bucket (Bc). Suponha que não haja excesso de balde (Be) por enquanto.
* Confirmar somente balde (Policer de duas cores) *
Este é um policial muito rigoroso que só permite enviar exatamente dentro do CIR; não estouro acima. Existe apenas um balde, Bc. Existem duas "cores" para o tráfego, conformes e excedentes .
Tempo = 0 ms - O depósito começa cheio, com 937.500 bytes de tokens. Digamos que você envie 7.500 bytes pela interface. Agora, o IOS diminui o depósito em 7.500 bytes, e agora o depósito possui 930.000 bytes de tokens. O tráfego enviado é considerado "em conformidade" e tem a "ação de conformidade" aplicada a ele.
Tempo = 187,5 ms - Agora atingimos o Tc e recarregamos o balde de Bc. São adicionados 937.500 bytes de tokens. Quaisquer fichas extras são derramadas e perdidas.
Tempo = 190 ms - O depósito de confirmação possui 937.500 tokens. Recebemos 2.000.000 de bytes de tráfego. Os primeiros 937.500 bytes são transferidos corretamente, pois o bucket possui tokens para ele. O tráfego restante é considerado "excedente" e é tratado de acordo com a "ação excedente". Lembre-se de que não há buffer no policiamento (que é chamado de modelagem) - você transmite, observa e transmite ou descarta.
Tempo = 375 ms - Atingimos Tc novamente e o balde Bc é recarregado com 937.500 tokens.
* Confirmar caçamba com excesso de caçamba (Policer de três cores) *
Opcionalmente, você pode adicionar um excesso de bucket (Be). Isso permite que o tráfego exceda o balde Bc temporariamente. O CIR geral deve permanecer o mesmo. Este é um policial de três cores: conformar, exceder e violar .
Tempo = 0 ms - Ambos os buckets (Bc e Be) começam cheios. Bc possui 937.500 fichas, Be possui 1.875.000 fichas.
Tempo = 50 ms - chega a 2.000.000 bytes de tráfego. O roteador primeiro decrementa os tokens de balde Bc. Reduz o balde Bc para zero. Os 937.500 bytes de tráfego cobertos por Bc são considerados "em conformidade" e têm a "ação de conformidade" aplicada a ele.
Isso deixa 1.062.500 bytes de tráfego que ainda não possui tokens. Agora, o roteador mergulha no balde Be e subtrai 1.062.500 tokens para cobrir o restante do tráfego. Esses bytes são considerados "excedentes" e terão a "ação excedente" aplicada a ele. No seu exemplo, o tráfego seria descartado, mas você poderia comentar ou simplesmente transmiti-lo.
Se você está mantendo a pontuação em casa, o Bc agora tem zero fichas, o Be tem 812.500 fichas.
Tempo = 75 ms - Agora, o roteador recebe outros 1.200.000 bytes de tráfego. O balde Bc está vazio, então não há ajuda lá. O depósito Be pode ajudar, cobrindo os primeiros 812.500 bytes de tráfego com seus tokens e agora está vazio. Esse tráfego é considerado "excedente" e terá a "ação excedente" aplicada a ele.
Agora, os baldes estão secos, mas ainda há 387.500 bytes para lidar. Esse tráfego é considerado "violador" e sempre é descartado no CAR (você pode fazer outras coisas usando o MQC e o comando police com "violate-action").
Tempo = 187,5 ms - Agora chegamos ao primeiro intervalo Tc, hora de encher nossos baldes. Um ponto importante é que apenas Bc em tokens são recarregados! O balde Bc é preenchido primeiro para 937.500. O balde Be permanece vazio.
Tempo = 375 ms - Está tudo quieto e chegamos ao próximo intervalo Tc. Bc em tokens são adicionados ao balde Bc. Como o balde Bc já está cheio, os tokens em excesso não são perdidos - eles são "derramados" no balde Be. Agora, o balde Bc está cheio com 937.500 fichas e o balde Be está parcialmente cheio com 937.500 fichas.
Tempo = 562,5 ms - Calma ainda, e estamos no próximo Tc. Bc em tokens são adicionados ao balde Bc, que já está cheio. Tudo isso se espalha no balde Be (que já possui 937.500 fichas). O Be preenche até 1.875.000 fichas.
* Notas finais *
Sua configuração não está usando o bucket Be. Você limita a taxa / policia usando apenas o depósito Bc, que pode ter efeitos colaterais indesejados se o vigilante / modelador que está enviando dados para você não estiver configurado de forma idêntica e não estiver sincronizado em Tc.
O CAR / limite de taxa é muito antigo e obsoleto. Considere mudar para o MQC e a QoS moderna para implementar isso, pois ele fornecerá mais informações e opções.
Ignoro totalmente o atraso de serialização (o tempo que leva para transmitir dados na linha) acima e tenho certeza de que a matemática não funciona em um cenário real. Mas os conceitos são sólidos, independentemente dos números exatos em uso.
* Exemplo 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
!
* Fontes *