Policiamento de Tráfego

Sei que o policiamento de tráfego não é algo que você normalmente encontra em um ambiente de LAN e gostaria de não encontrá-lo no meu. Dito isto ... não tenho escolha.

O dispositivo é um 3750X. O requisito é POLICIAR (não moldar) todo o tráfego proveniente das / das redes 10.0.0.0 e 10.0.1.0 para um MÁXIMO de ~ 48Mbps. Abaixo está a configuração que eu propus. O que você acha? Além disso, eu sei que provavelmente deveria ter isso configurado na interface de entrada, mas essa é outra história ...

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

Outra coisa ... Alguém pode me explicar o "burst-normal" e o "burst-max" ? Isso está permitindo que ele ultrapasse o limite de policiais (bps) que eu defini? Quais são os limites do timer para isso? Devo configurar esses números de rajada menores? Maior?

Eu usaria o policiamento baseado em vlan, que funciona melhor nesses switches. Este é um exemplo que corresponde a um valor de velocidade de 48Mb

mls qos
!
interface GigabitEthernet1/0/2
 switchport access vlan 500
 switchport mode access
 mls qos vlan-based
!
class-map match-all CUSTOMER_1
 match input-interface  GigabitEthernet1/0/2
!
policy-map VLAN500_POLICE
 class CUSTOMER_1
  police 48000000 18000000 exceed-action drop
!
policy-map VLAN500_PARENT
 class class-default
  set dscp default
  service-policy VLAN500_POLICE
!
interface Vlan500
 service-policy input VLAN500_PARENT

Sob a política pai, você precisa 'definir' algo para que ele funcione. Isso pode ser qualquer coisa, então, neste exemplo, estou simplesmente configurando o dscp para 0

Seus valores de burst parecem um pouco pequenos. A escolha dos valores de intermitência não é fácil e pode ser necessário um teste para acertar. Além disso, se bem me lembro, o 3750 não suporta policiamento na saída.

Bc funciona um pouco diferente no policiamento e na modelagem. Ao modelar os pacotes de buffer e você tem um token bucket onde sempre Tc (intervalo de tempo) você tem bytes Bc (Commited Burst) adicionados ao bucket. A fórmula é Tc = Bc / CIR. Em algumas plataformas, o Tc também é fixo, para que você não tenha a opção de configurá-lo.

Quando você usa policiamento, não usa intervalos de tempo fixos. Em vez disso, quando o pacote chega, o vigilante calcula quantos bytes foram acumulados. Então diga que você está policiando a 10 Mbit / s. Você configurou um Bc de 10000 bytes. Um pacote burst chega a t0 que compõe 5000 bytes de tráfego. Então, 5000 bytes são deduzidos. Então, em T1 5 ms depois, outro lote de 5000 bytes de pacotes chega. O vigilante está definido em 10 Mbit / s, ou seja, 1250000 bytes por segundo. Isso significa que 1250000 * 0,005 = 6250 bytes foram adicionados aos 5000 que foram deixados desde a primeira execução em t0. Portanto, os pacotes são permitidos.

A partir deste exemplo, você pode ver que em t1 poderia ser permitido enviar 5000 + 6250 = 11250 bytes, mas como Bc estava definido como 10000 bytes, o vigilante deixaria qualquer coisa acima disso. E se 6000 bytes de pacotes tivessem chegado? Então alguns pacotes teriam que ser descartados. É aqui que o Be entra em cena. O Be permitirá acumular algum crédito extra em intervalos inativos. Portanto, se Be tivesse sido configurado para ter 20000 bytes, os 6000 bytes poderiam ter sido transmitidos pelo vigilante.

O Be adiciona um pouco de justiça ao vigilante, mas também permite a passagem de maiores explosões de tráfego. Lembre-se de que, no final, o CIR ainda é aplicado, portanto, em média, não é possível enviar mais que o CIR.

Este artigo da Juniper recomenda configurar o burst para 5ms de tráfego, que no seu caso seria 6250000 bytes.

Não acho que o policiamento de saída funcione nessa plataforma, mas você precisará usar o SRR e, francamente, a modelagem é sempre preferível quando possível.

Habilitar 'mls qos' à toa ou à vontade no 3750 pode ser uma receita para um desastre, os padrões são horríveis, por exemplo, a EF é policiada em 4%. Então você deve pelo menos ler:

1. Como maximizar os buffers disponíveis
2. Exemplos de configuração de Cisco Catalyst 3750 QoS
3. Guia de configuração

Para ingresso, sua configuração sugerida deve funcionar.

Eu gostaria de oferecer algumas idéias adicionais sobre como dimensionar seu buffer CIR, sei que o conhecimento tradicional do Cisco CCO fala sobre RTT, mas o RTT na verdade não tem nada a ver com o policer, pois seu roteador / switch não se importa com o tempo de duração do pacote -Vôo quando chega. O que é de importância fundamental é a interface de taxa de entrada, pois a taxa física da interface de entrada determina a rapidez com que seu 'bucket' está sendo preenchido e a taxa de vigilante determina a velocidade com que ele é esvaziado.

A fórmula JNPR (burst_time * interface_rate) é uma regra prática bastante útil, portanto, se você possui uma interface de ingresso 10G e um policial de saída de 1 Mbps na interface A e um policial de saída de 100 Mbps na interface B, ambos os policiais [AB] devem ter o mesmo buffer CIR , digamos 10G * 5ms para lidar com 5ms de rajada, basta ajustar o tempo para ajustar a rajada de seu perfil de tráfego.

Estou usando o 'CIR Buffer' liberalmente, pois tecnicamente o policiamento não adiciona buffer fora dos buffers normais da interface. Significa apenas quantos bytes serão enviados, sem aplicar o vigilante. Isso é necessário, caso contrário, cada pacote único excederia a taxa de vigilante e a taxa observável seria 0.