Calcoliamo con cosa abbiamo a che fare qui. CAR è fondamentalmente la versione precedente della polizia di IOS, quindi tutti questi concetti si applicano ad entrambi.
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 velocità a cui vogliamo limitare i flussi è di 5 Mbps. Il bucket di commit è 937.500 byte. Il secchio a raffica è di 1.875.000 byte. E i secchi vengono ricaricati ogni 187,5 ms.
Come accennato, IOS utilizza un meccanismo bucket per limitare la quantità di traffico che può passare. Non attenua il traffico all'X% della larghezza di banda dell'interfaccia per un periodo di tempo arbitrario! Invece, consente l'accesso completo alla larghezza di banda dell'interfaccia, purché tu abbia i token per pagarla.
Inoltre, poiché si tratta di attività di polizia, RED / WRED non sono in gioco. Il ROSSO si verifica solo quando c'è una coda da gestire. Non vi è buffering / accodamento nella polizia, solo nella modellatura.
Affrontiamo prima Commit Bucket (Bc). Supponiamo che per ora non ci sia un eccesso di secchio (Be).
* Impegna solo benna (policer bicolore) *
Questo è un poliziotto molto rigoroso che ti consentirà di inviare esattamente solo all'interno del CIR; nessuno scoppio sopra. C'è solo un secchio, Bc. Esistono due "colori" per il traffico, conformi e superiori .
Tempo = 0 ms - Il bucket inizia completamente, con 937.500 byte di token al suo interno. Supponiamo che tu invii 7.500 byte attraverso l'interfaccia. Ora IOS riduce il bucket di 7.500 byte e il bucket ora contiene 930.000 byte di token. Il traffico inviato è considerato "conforme" e ad esso è applicata l '"azione conforme".
Tempo = 187,5 ms - Ora colpiamo il Tc e riempiamo il secchio Bc. Vengono aggiunti 937.500 byte di token. Eventuali token extra si riversano e vengono persi.
Tempo = 190 ms - Il bucket di commit contiene 937.500 token. Riceviamo 2.000.000 di byte di traffico. I primi 937.500 byte vengono trasferiti correttamente poiché il bucket ha token per esso. Il traffico rimanente è considerato "in eccesso" e viene trattato in base al "superamento dell'azione". Ricorda, non c'è buffering nella polizia (che si chiama modellamento): o trasmetti, osservi e trasmetti o rilasci.
Tempo = 375 ms - Abbiamo nuovamente premuto Tc e il bucket Bc viene riempito con 937.500 token.
* Impegna la benna con una benna in eccesso (Policer a tre colori) *
Se lo desideri, puoi aggiungere un Secchio in eccesso (Be). Ciò consente al traffico di superare temporaneamente il bucket Bc. Il CIR complessivo dovrebbe rimanere lo stesso. Questo è un poliziotto a tre colori: conforme, eccedente e violante .
Tempo = 0 ms - Entrambi i bucket (Bc e Be) iniziano completamente. Bc ha 937.500 token, Be ha 1.875.000 token.
Tempo = 50 ms - arrivano 2.000.000 di byte di traffico. Il router prima decrementa i token bucket Bc. Riduce a zero il bucket Bc. I 937.500 byte di traffico coperti da Bc sono considerati "conformi" e ad essi è applicata l '"azione conforme".
Ciò lascia 1.062.500 byte di traffico che non hanno ancora token. Ora il router si immerge nel bucket Be e sottrae 1.062.500 token per coprire il resto del traffico. Questi byte vengono considerati "eccedenti" e gli verrà applicato l '"azione superata". Nel tuo esempio, il traffico verrebbe eliminato, ma potresti potenzialmente osservarlo o semplicemente trasmetterlo.
Se stai mantenendo il punteggio in casa, Bc ora ha zero token, Be ha 812.500 token.
Tempo = 75 ms - Ora il router riceve altri 1.200.000 byte di traffico. Il secchio Bc è vuoto, quindi nessun aiuto lì. Il secchio Be può aiutare, quindi copre i primi 812.500 byte di traffico con i suoi token ed è ora vuoto. Questo traffico è considerato "eccedente" e verrà applicato il "superamento dell'azione".
Ora i secchi sono asciutti, ma rimangono ancora 387.500 byte da gestire. Questo traffico è considerato "violativo" e viene sempre eliminato con CAR (puoi fare altre cose con MQC e il comando di polizia con "violazione-action").
Tempo = 187,5 ms - Ora arriviamo al primo intervallo Tc, tempo per riempire i nostri secchi. Un punto chiave è chevengono ricaricatisolo itoken di valore Bc ! Il secchio Bc viene riempito per primo a 937.500. Il secchio Be RIMANE VUOTO.
Tempo = 375 ms - È stato silenzioso e passiamo al successivo intervallo Tc. I token in valore Bc vengono aggiunti al bucket Bc. Poiché il bucket Bc è già pieno, i token in eccesso non vengono persi, ma vengono "versati" sul bucket Be. Ora il bucket Bc è pieno con 937.500 token e il bucket Be è parzialmente pieno con 937.500 token.
Tempo = 562,5 ms - Ancora tranquillo, e siamo al prossimo Tc. I token in valore Bc vengono aggiunti al bucket Bc, che è già pieno. Tutto si riversa nel secchio Be (che ha già 937.500 token). L'Ess si riempie fino a 1.875.000 token.
* Note finali *
La tua configurazione non utilizza Be bucket. Stai limitando la frequenza / la polizia utilizzando solo il bucket Bc, che potrebbe avere effetti collaterali indesiderati se il poliziotto / shaper che ti invia i dati non è configurato in modo identico e non è sincronizzato con Tc.
CAR / limite di velocità è molto vecchio e deprecato. Prendi in considerazione la possibilità di passare a MQC e QoS moderno per implementarlo, poiché ti fornirà maggiori informazioni e opzioni.
Ignoro totalmente il ritardo di serializzazione (il tempo necessario per trasmettere i dati sulla linea) sopra e sono abbastanza sicuro che la matematica non si risolva in uno scenario reale. Ma i concetti sono solidi indipendentemente dai numeri esatti in uso.
* Esempio 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
!
* Fonti *