Este documento fornece uma configuração de exemplo para recursos de Qualidade de Serviço (QoS - Quality of Service) no Cisco Nexus 7000 Series Switch para simplificar a forma como a classificação e o enfileiramento são alcançados.
Certifique-se de atender a estes requisitos antes de tentar esta configuração:
Ter um conhecimento básico da configuração dos switches Nexus 7000 Series
Ter um conhecimento básico de QoS
As informações neste documento são baseadas no Nexus 7000 Series Switch.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Os parâmetros de QoS padrão no switch Nexus 7000 são suficientes para a maioria das implantações. No entanto, você precisa entender as restrições e os detalhes de configuração necessários para criar políticas personalizadas.
Há dois aspectos que você precisa considerar para QoS em placas de linha Nexus 7000 M-Series:
políticas de enfileiramento
Políticas de QoS
O enfileiramento é realizado no hardware e configurado com o uso de políticas de enfileiramento modulares QoS CLI (MQC). As políticas de QoS, usadas para marcar ou policiar o tráfego, são usadas através de uma política de MQC no formato exato como uma política de QoS padrão em outras plataformas Cisco. Por exemplo, uma lista de acesso usada para classificar o tráfego em um mapa de classe com um mapa de política correspondente para definir/policiar o tráfego.
Atualmente, os módulos da série M executam enfileiramento com base estritamente no valor de Classe de Serviço (CoS). Portanto, é preciso primeiro entender como o valor de CoS é derivado. Depois de saber qual valor de CoS entra/sai do switch, você pode se concentrar na configuração de enfileiramento para obter a QoS desejada para diferentes tipos de tráfego.
Para o tráfego unicast roteado, o valor de CoS é derivado dos 3 bits mais significativos do valor de Ponto de Código de Serviços Diferenciados (DSCP - Differentiated Services Code Point). Para o tráfego unicast em ponte, o valor de CoS é copiado do valor de CoS recebido no cabeçalho 802.1q. Observe que em links de acesso L2 não há cabeçalho de tronco. Portanto, se o tráfego for recebido em uma porta de acesso e interligado, ele sairá do switch com CoS 0. O valor de DSCP não é alterado, mas o pacote pode não obter a prioridade desejada. Você pode definir manualmente o valor de CoS em um mapa de políticas por meio de qualquer política de QoS que defina manualmente o valor de CoS ou DSCP.
É importante entender o comportamento do multicast também. O tráfego multicast roteado deriva seu valor de CoS da mesma forma que o tráfego unicast roteado. Para o tráfego de transmissão múltipla em ponte, o comportamento depende do estado L3. Se não houver nenhum estado L3 para o grupo multicast, o CoS é derivado da mesma maneira que o tráfego unicast de ponte. Se houver um estado L3 para o grupo multicast, o CoS é derivado da mesma maneira que o tráfego unicast roteado. Observe que quando você habilita o Protocol Independent Multicast (PIM) no modo esparso na interface virtual do switch (SVI) para a VLAN na qual o tráfego é recebido, uma entrada S,G é criada quando o multicast é visto.
Em resumo, o comportamento de CoS para um tipo de tráfego é mostrado aqui:
Tipo de tráfego | Comportamento de CoS |
unicast roteado | copiado de 3-MSB de ToS |
unicast interligado | inalterada |
multicast roteado | copiado de 3-MSB de ToS |
bridge multicast com estado L3 para grupo | copiado de 3-MSB de ToS |
bridge multicast sem estado L3 para grupo | inalterada |
Considere um exemplo onde o tráfego é recebido na porta de acesso (Eth8/1) e ligado na VLAN. Por padrão, o valor de CoS do tráfego unicast interligado não é alterado. Se o tráfego chegar em uma porta de acesso, o valor de CoS padrão 0 será atribuído. Neste exemplo, o tráfego de prioridade (DSCP 46) é recebido em uma porta de acesso e sai do switch com o valor de DSCP inalterado e um valor de CoS 0. Assim, o pacote não recebe a prioridade adequada.
Uma possível solução é criar uma política de QoS para definir manualmente o valor de CoS na porta de entrada.
No exemplo, somente os pacotes com DSCP 46 têm seus valores de CoS atualizados. Se houvesse vários valores de DSCP necessários para garantir um valor de CoS apropriado, seria necessário definir mapas de classe e ações adicionais no mapa de política.
Uma opção alternativa é usar um mapa de tabela com a ação 'cópia padrão'. O mapa de tabela permite redefinir o DSCP com base no valor atual do DSCP. Por exemplo, se o tráfego foi recebido com um valor de DSCP de 40 e você precisa garantir que ele foi remarcado com um valor de DSCP de 46, você poderia usar um mapa de tabela com a ação 'de 40 a 46'.
Um mapa de tabela também contém uma ação de 'cópia padrão' que define o valor de DSCP como seu valor original. Isso é semelhante a criar um mapa de política com a classificação de 'match dscp ef' e ação de 'set dscp ef'. Logicamente, o valor de DSCP não é alterado, mas a ação 'set dscp' define implicitamente o valor de CoS para o 3-MSB do novo valor de DSCP.
Portanto, se você precisar garantir que o valor de CoS seja sempre atualizado para o 3-MSB do valor de DSCP, use um mapa de tabela com uma única ação de 'cópia padrão'.
Quando o valor de CoS é derivado, você pode manipular os mapas de classe de enfileiramento global para afetar os mapeamentos de custo para fila. Esses mapas de classe são globais e afetam todos os módulos em todos os contextos de dispositivos virtuais (VDCs) para esse tipo de enfileiramento específico. Por exemplo, considere estes mapas de classe de enfileiramento padrão para os módulos M108 e M132 (1p7q4t):
class-map type queuing match-any 1p7q4t-out-pq1
Description: Classifier for egress priority queue of type 1p7q4t
match cos 5-7
class-map type queuing match-any 1p7q4t-out-q2
Description: Classifier for egress queue 2 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q3
Description: Classifier for egress queue 3 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q4
Description: Classifier for egress queue 4 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q5
Description: Classifier for egress queue 5 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q6
Description: Classifier for egress queue 6 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q7
Description: Classifier for egress queue 7 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q-default
Description: Classifier for egress default queue of type 1p7q4t
match cos 0-4
Por padrão, o cos 0-4 é mapeado para a fila padrão e o cos 5-7 é mapeado para a fila de prioridade. Eles acompanham a política de enfileiramento padrão para o mesmo tipo de enfileiramento:
policy-map type queuing default-out-policy
class type queuing out-pq1
priority level 1
queue-limit percent 16
class type queuing out-q2
queue-limit percent 1
class type queuing out-q3
queue-limit percent 1
class type queuing out-q-default
queue-limit percent 82
bandwidth remaining percent 25
A fila prioritária é 'priority' com um limite de fila de 16%. A fila padrão tem um limite de fila de 82% com um peso restante da largura de banda padrão. Às outras filas, que não estão em uso, é atribuído um limite de fila de 1%. Observe que q4, q5 e q6 não estão representados na política de enfileiramento padrão e, portanto, terão um limite de fila e peso de largura de banda ainda menores programados no hardware.
Para criar uma política de enfileiramento personalizada, faça o seguinte:
Considere um exemplo para os módulos M132 que têm uma arquitetura de enfileiramento 1p7q4t onde todos os valores de CoS 8 são mapeados para uma fila separada. A saída mostra a política de enfileiramento personalizada junto com as alterações nos mapas de classe de enfileiramento global:
policy-map type queuing 10G_POLICY
class type queuing 1p7q4t-out-pq1
priority level 1
queue-limit percent 10
class type queuing 1p7q4t-out-q2
queue-limit percent 10
bandwidth remaining percent 10
class type queuing 1p7q4t-out-q3
queue-limit percent 5
bandwidth remaining percent 5
class type queuing 1p7q4t-out-q4
queue-limit percent 5
bandwidth remaining percent 5
class type queuing 1p7q4t-out-q5
queue-limit percent 10
bandwidth remaining percent 20
class type queuing 1p7q4t-out-q6
queue-limit percent 5
bandwidth remaining percent 10
class type queuing 1p7q4t-out-q7
queue-limit percent 5
bandwidth remaining percent 10
class type queuing 1p7q4t-out-q-default
queue-limit percent 50
bandwidth remaining percent 40
! voice
class-map type queuing match-any 1p7q4t-out-pq1
match cos 5
! scavenger
class-map type queuing match-any 1p7q4t-out-q2
match cos 1
! transactional
class-map type queuing match-any 1p7q4t-out-q3
match cos 2
! call signaling
class-map type queuing match-any 1p7q4t-out-q4
match cos 3
! video
class-map type queuing match-any 1p7q4t-out-q5
match cos 4
! routing
class-map type queuing match-any 1p7q4t-out-q6
match cos 6
! management
class-map type queuing match-any 1p7q4t-out-q7
match cos 7
! best effort
class-map type queuing match-any 1p7q4t-out-q-default
match cos 0
A etapa final é aplicar a política de enfileiramento personalizado a cada interface 1p7q4t:
interface Ethernet8/1
service-policy type queuing output 10G_POLICY
A política de enfileiramento padrão supõe que os CoS 0-4 sejam mapeados para a fila padrão e os CoS 5-7 sejam mapeados para a fila de prioridade. Portanto, os limites de fila para filas q3, q4, q5, q6 e q7 são extremamente pequenos. Você pode inserir o comando show queuing interface para validar o tamanho da fila atual e a largura de banda configurada e aplicada no hardware.
Considere a política de exemplo na seção anterior em que cada valor de CoS foi mapeado para uma fila específica. No final do exemplo, a política de enfileiramento personalizada foi aplicada a Eth8/1. Além disso, suponha que haja outra interface 1p7q4t (Eth6/1) que foi deixada com a política de enfileiramento padrão:
N7k# show queuing interface e6/1
<some output omitted>
Configured queue-limit ratios
queue-limit ratios: 78[1p7q4t-out-q-default] 1[1p7q4t-out-q2] 1[1p7q4t-out-q3]
*1[1p7q4t-out-q4] *1[1p7q4t-out-q5] *1[1p7q4t-out-q6] *1[1p7q4t-out-q7] 16[1p7q4t-out-pq1]
* means unused queue with mandatory minimum queue-limit
Thresholds:
COS Queue Threshold Type Min Max
______________________________________________________________
0 1p7q4t-out-q-default DT 100 100
1 1p7q4t-out-q2 DT 100 100
2 1p7q4t-out-q3 DT 100 100
3 1p7q4t-out-q4 DT 100 100
4 1p7q4t-out-q5 DT 100 100
5 1p7q4t-out-pq1 DT 100 100
6 1p7q4t-out-q6 DT 100 100
7 1p7q4t-out-q7 DT 100 100
Na saída acima, você pode ver que as filas q2 e q3 têm um limite de fila de 1%, enquanto q4, q5, q6 e q7 têm *1%, que é o limite mínimo obrigatório de fila (em outras palavras, significativamente menor que 1%). Além disso, você pode ver que os valores de CoS 1-4 e 6-7 utilizam essas filas muito pequenas. Os pequenos tamanhos de fila resultam rapidamente em descartes de saída e podem degradar o desempenho da rede. Isso será ainda mais exacerbado se o tráfego padrão CoS 0 for mapeado para uma dessas filas pequenas.
Em resumo, se você criar uma política de enfileiramento personalizada e alterar os mapas de classe de enfileiramento global, é essencial aplicar a política de enfileiramento personalizada a todas as interfaces no chassi que compartilham o mesmo tipo de enfileiramento.
Além disso, alguns comandos soltos úteis estão listados aqui:
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
29-May-2013 |
Versão inicial |