Überprüfen der Hardware-VoQ-Programmierung auf einem Multichassis NCS4K

Einleitung

In diesem Dokument wird das Verfahren zum Überprüfen der Hardware-(HW-)VoQ-Programmierung (Virtual Output Queueing) auf einem Multi-Chassis-NCS4K beschrieben.

Vorgehensweise

Hierbei handelt es sich um einen Schritt-für-Schritt-Ansatz zur Verifizierung der Hardware-VoQ-Programmierung auf NCS4K-Knoten.

Multichassis-Knoten in Version 6.5.26 sind potenziell von der Cisco Bug-ID CSCvz41459 betroffen, wobei VoQ auf der virtuellen Eingangs-Linecard (LC)-Maschine (VM) falsch programmiert ist.

Schritt 1: Zunächst müssen Sie die Eingangs- und Ausgangsschnittstelle auf den Datenverkehrsfluss überprüfen.

In diesem Beispiel ist die Eingangsschnittstelle TenGigE1/3/0/0/1.4001 (Rack 1), die Ausgangsschnittstelle ist Hu0/9/0/11/2.4001(Rack 0). Eingangs- und Ausgangsschnittstellen befinden sich in verschiedenen Racks, und Sie können möglicherweise durch Distributed Defect Tracking System (DDTS) mit der Cisco Bug-ID CSCvz41459 beeinträchtigt werden.

Siehe beispielsweise Tunnel 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

Schritt 2: Aktive LC VM in Rack 0 und Rack 1 prüfen:

#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)

In diesem Beispiel ist 0/LC0 eine aktive VM in Rack 0 und 1/LC0 in Rack 1.

Schritt 3: Überprüfen Sie anschließend die SysPort-Nummer für die Ausgangsschnittstelle im ausgehenden LC VM:

#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

In diesem Fall ist SysPort 24655 und die VoQ-Basis 1336.

Schritt 4: Überprüfen Sie den gleichen SysPort auf der Eingangs-Linecard und der Eingangs-VM.

Der Befehl lautet:

show controllers fia diagnoshell <Eingangs-Linecard-Nummer> "dump IRR_DESTINATION_TABLE <SysPort>" location <Eingangs-LC-VM>

Beispiele:

#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]: 
     
      
     

In diesem Beispiel ist QUEUE_NUMBER 0x538 in HEX und entspricht damit Ihrer VoQ-Basis 1336 (dec) aus der vorherigen Ausgabe.

Wenn Sie auf Cisco Bug-ID CSCvz41459 klicken QUEUE_NUMBER ist 0x1ffff.

Beispiele:

#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]: 
     
     

Wiederherstellungsmethode

Die Wiederherstellungsmethode für dieses Problem besteht darin, die betroffene Egress-Subschnittstelle zu entfernen und sie erneut anzuwenden.

Vergessen Sie nicht, den Strömungsweg auch in umgekehrter Richtung zu prüfen.