Verificar a programação HW VoQ em um NCS4K multichassi

Introduction

Este documento descreve o procedimento para verificar a programação de enfileiramento de saída virtual (VoQ - Virtual Output Queueing) de hardware (HW) em um NCS4K multichassi.

Procedimento

Essa é uma abordagem passo a passo para verificar a programação HW VoQ em nós NCS4K.

Os nós multichassi na versão 6.5.26 são potencialmente afetados pelo bug da Cisco ID CSCvz41459, onde o VoQ é mal programado na Máquina Virtual (VM) da Placa de Linha de Entrada (LC).

Etapa 1. Primeiro, você precisa verificar a interface de entrada e saída do fluxo de tráfego.

Neste exemplo, a interface de entrada é TenGigE1/3/0/0/1.4001 (rack 1), e a interface de saída é Hu0/9/0/11/2.4001 (rack 0). Assim, as interfaces de entrada e saída estão em racks diferentes e você pode ser potencialmente afetado pelo bug do DDTS (Distributed Defect Tracking System) da Cisco ID CSCvz41459

Por exemplo, consulte túnel 117:

#show mpls forwarding tunnels 117
Wed Nov  9 13:15:47.159 UTC
Tunnel        Outgoing    Outgoing     Next Hop        Bytes
Name          Label       Interface                    Switched
------------- ----------- ------------ --------------- ------------
tt117             24764       Hu0/9/0/11/2.4001 172.16.13.170   0

Etapa 2. Verificar a VM LC ativa nos racks 0 e 1:

#show redundancy summary
Wed Nov  9 13:16:59.309 UTC
    Active Node    Standby Node
    -----------    ------------
          1/LC0           1/LC1 (Node Ready, NSR:Not Configured)
          0/RP1           1/RP0 (Node Ready, NSR:Ready)
          0/RP0           1/RP1 (Node Ready, NSR:Not Configured)
          0/LC0           0/LC1 (Node Ready, NSR:Not Configured)

Neste exemplo, 0/LC0 é uma VM ativa no rack 0 e 1/LC0 está no rack 1.

Etapa 3. Como próxima etapa, verifique o número de SysPort da interface de saída na LC VM de saída:

#show controllers npu voq-usage interface HundredGigE 0/9/0/11/2.4001 instance all location 0/lc0
Wed Nov  9 13:16:45.149 UTC

-------------------------------------------------------------------
Node ID: 0/LC0
Intf         Intf     NPU NPU  PP   Sys   VOQ   Flow   VOQ    Port
name         handle    #  core Port Port  base  base   port   speed
             (hex)                                     type
----------------------------------------------------------------------
Hu0/9/0/11/2.4001 8000bd4  18   1  448 24655   1336   5152 local   100G
Hu0/9/0/11/2.4001 8000bd4   0   0    0 24655   1144      0 remote    0M

Nesse caso, SysPort é 24655 e VoQ base é 1336.

Etapa 4. Verifique o mesmo SysPort na placa de linha de entrada e na VM de entrada.

O comando é:

show controllers fia diagshell <número da placa de linha de ingresso> "dump IRR_DESTINATION_TABLE <SysPort>" location <VM LC de ingresso>

Por exemplo:

#show controllers fia diagshell 3 "dump IRR_DESTINATION_TABLE 24655" location 1/lc0
Wed Nov  9 13:18:00.684 UTC

Node ID: 1/LC0
IRR_DESTINATION_TABLE.IRR0[24655]: 
     
      
     

Neste exemplo, QUEUE_NUMBER é 0x538 em HEX, que corresponde à sua base de VoQ 1336 (dec) da saída anterior.

Se você clicar no ID de bug Cisco CSCvz41459 o QUEUE_NUMBER é 0x1ffff.

Por exemplo:

#show controllers fia diagshell 3 "dump IRR_DESTINATION_TABLE 24655" location 1/LC0
Wed Nov  9 12:44:54.270 UTC
 
Node ID: 1/LC0
IRR_DESTINATION_TABLE.IRR0[24655]: 
     
     

Método de Recuperação

O método de recuperação para esse problema é remover a subinterface de saída afetada e reaplicá-la.

Não se esqueça de verificar também o caminho do fluxo na direção inversa.