Exemplo: configuração e aplicação de um classificador agregado de comportamento DSCP padrão

Para verificar esse procedimento, este exemplo usa um gerador de tráfego. O gerador de tráfego pode ser baseado em hardware ou pode ser um software em execução em um servidor ou máquina de host. Se você não tiver acesso a um gerador de tráfego, você pode usar ping estendido para verificação. Essa abordagem também é mostrada.

A funcionalidade neste procedimento é amplamente suportada em dispositivos que executam o Junos OS. O exemplo mostrado aqui foi testado e verificado em roteadores da Série MX que executam o Junos OS Release 10.4.

A base do Junos OS CoS é a diferenciação de tráfego. Atribuir tráfego a diferentes classes de serviço fornece a diferenciação necessária. Do ponto de vista de um roteador, a classe de serviço atribuída a um pacote define como o roteador se comporta em relação ao pacote. O conceito de diferenciação de tráfego está presente em todas as ferramentas de CoS e, como resultado, as aulas de serviço estão presentes em todo o projeto CoS. Um classificador tem uma entrada, o pacote de entrada, e ele tem N saídas possíveis, onde N é o número de classes de serviço possíveis nas quais o pacote pode ser classificado.

A classificação BA é usada quando o tráfego que entra em seu dispositivo já tem valores de CoS confiáveis no cabeçalho do pacote. Por exemplo, o classificador DSCP BA padrão especifica que os pacotes que chegam com pontos de código 000000 são atribuídos à classe de encaminhamento de melhor esforço e recebem uma prioridade de perda baixa.

Uma prioridade de classe de encaminhamento e perda é atribuída por padrão a cada DSCP bem conhecido. Para ver isso, execute o show class-of-service classifier comando.

A classe de encaminhamento determina a fila de saída. Por padrão, todo o tráfego de melhor esforço usa a fila 0.

Para ver as filas associadas, por padrão, a cada classe de encaminhamento, use o show class-of-service forwarding-class comando. (Para obter clareza, parte da saída está excluída.)

A prioridade de perda é usada pelos agendadores em conjunto com o algoritmo de detecção antecipada aleatória (RED) para controlar o descarte de pacotes durante períodos de congestionamento. Quando você está pensando em prioridades de perda, tenha em mente que, a menos que você as configure, elas não têm significado. O comportamento de queda padrão é esperar até que a fila esteja 100% cheia e, em seguida, começar a soltar pacotes indiscriminadamente. Quando a fila cai abaixo de 100% cheia, os pacotes param de cair.

O comportamento de queda padrão é mostrado no show class-of-service drop-profile comando.

Para criar significados para as várias prioridades de perda, você deve configurar perfis de quedas personalizados. Por exemplo, você pode definir a baixa prioridade de perda para significar uma probabilidade de queda de 10% quando a fila está 75% cheia e uma probabilidade de queda de 40% quando o nível de preenchimento da fila é de 95%. Você pode definir a alta prioridade de perda para significar uma probabilidade de queda de 50% quando o nível de preenchimento é de 25% e uma probabilidade de queda de 90% quando o nível de preenchimento é de 50%. Os perfis de queda personalizados não estão incluídos neste exemplo, mas são mencionados aqui para clareza porque os classificadores atribuem prioridades de perda. É importante entender que essas atribuições não têm sentido até que você crie perfis de quedas.

A operação de classificação padrão é mostrada na Figura 1. A figura mostra dois pacotes IPv4 entrando em uma interface e sendo classificados de acordo com os pontos de código DSCP nos cabeçalhos de pacotes.

Os classificadores são descritos com mais detalhes no vídeo do Juniper Networks Learning Byte a seguir.

Confirme se a configuração está funcionando corretamente.