Como entender “burst normal” e “burst máximo” no Cisco CAR?


11

Pelo que entendi, o Cisco IOS CAR (Taxa de Acesso Confirmada) é baseado no algoritmo de vazamento de balde (a idéia é exatamente a mesma que o algoritmo de balde de token ) e a quantidade de bits que eu configuro como taxa média é a quantidade de "água constantemente vazando no balde " Por exemplo, aqui, a taxa limite de taxa de entrada média é de 5 Mbps:

interface FastEthernet0/0
 ip address 10.10.10.2 255.255.255.0
 rate-limit input 5000000 937500 1875000 conform-action transmit exceed-action drop

Agora, se a taxa de tráfego estiver abaixo da taxa média, ela sempre estará em conformidade. Estou certo de que a "explosão normal" determina o tamanho das rajadas de tráfego antes que a ação excedente seja aplicada? Portanto, no caso do exemplo acima, se houver uma taxa de tráfego constante de 5 Mbps (625000 bytes no bucket), eu poderia enviar por um segundo 7,5 Mbps (adiciona 312500 bytes adicionais ao bucket) de tráfego e nenhum bit será descartado ? E se os bytes no bucket estiverem entre o burst normal e o burst máximo, os bytes serão descartados com base no algoritmo do tipo RED até que todos os novos pacotes sejam descartados se o burst máximo também estiver cheio?


Alguma outra informação ou explicação que você procura na minha resposta para ganhar a recompensa que você definiu?
Keller L

Por favor, não esqueça que você deve conceder manualmente a recompensa ; se você recebeu uma resposta que não o satisfaz, explique pelo menos o que está faltando nessa resposta.
Mike Pennington

Respostas:


12

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 *


Ótima resposta realmente direta! Mas eu tenho uma pergunta sobre o policiamento de taxa única (duas cores). Você mencionou o seguinte: Existem duas "cores" para o tráfego, conformes e violações. O que eu acho que deveria ser, conforme e excedendo (em vez de violar o que deveria pertencer ao método de policiamento em cores de árvores).
Daniel15

Você está exatamente certo, atualizado conforme sugerido.
Keller L
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.