Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Informations générales

Flux De Trafic De Monodiffusion Et Mise En Mémoire Tampon

Flux De Trafic Multicast Et Mise En Mémoire Tampon

Quelles sont les causes des rejets d'entrée ?

Scénarios de dépannage

Scénario 1. Rejets d'entrée

Étape 1. Identifier les ports avec les rejets en entrée

Étape 2. Identification ASIC

Étape 3. Identifier le port congestionné de sortie

Scenerio 2. Rejets d'entrée avec HOLB

Atténuation HOLB : Activer la limite de VOQ

Atténuation HOLB : Classification du trafic

Informations connexes

Introduction

Ce document décrit comment dépanner les rejets d'entrée sur les commutateurs de la gamme Cisco Nexus 5600/6000.

Conditions préalables

Conditions requises

Cisco vous recommande d'avoir une connaissance de base de la configuration de la gamme Cisco Nexus 6000.

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

- Cisco Nexus 6001

- 7.1(3)N1(1)

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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Les rejets en entrée indiquent un port de sortie sursouscrit. Cela signifie également que vous abandonnez probablement le trafic de monodiffusion sur ce port spécifique. Cet article vous aide à comprendre comment le trafic de monodiffusion et de multidiffusion est mis en mémoire tampon sur cette plate-forme et comment les rejets d'entrée peuvent se produire avec les étapes de réduction.

Flux De Trafic De Monodiffusion Et Mise En Mémoire Tampon

Le trafic de monodiffusion est d'abord mis en file d'attente au niveau du pool de tampons de sortie, puis le tampon d'entrée après la file d'attente de sortie est saturé, comme l'illustre l'image.

Il existe une mémoire tampon partagée de 16 Mo en entrée et une mémoire tampon partagée de 9 Mo en sortie. Les tampons sont partagés entre 12 ports 10 gig ou 3 ports 40 gig. Le tampon partagé est bon pour l'absorption de rafale.

Voici une représentation visuelle de l'allocation de mémoire pour votre référence (Bigsur est le nom du contrôleur de port ASIC/Unified) comme le montre l'image.

Flux De Trafic Multicast Et Mise En Mémoire Tampon

- Les paquets de multidiffusion sont mis en mémoire tampon et abandonnés en sortie

- Abandonner le paquet de multidiffusion près du point d'encombrement afin d'éviter le blocage du noeud de ligne (HOLB)

- Tenir à jour le fabric sans perte pour la monodiffusion, comme l'illustre l'image.

Dans la plupart des cas, les pertes de sortie sont toujours dues au trafic de multidiffusion/diffusion/monodiffusion inconnue.

Quelles sont les causes des rejets d'entrée ?

Un port de sortie encombré provoque le remplissage des tampons de sortie en premier, puis provoque la contre-pression sur l'entrée. Ceci est uniquement pour le trafic de monodiffusion. Une fois que les tampons d'entrée sont pleins, vous pouvez potentiellement supprimer le trafic en entrée, ce qui entraîne des rejets en entrée.

Cette explication est à un très haut niveau et facile à digérer, mais il y en a un peu plus particulièrement quand vous regardez différentes classes de trafic, files d'attente, etc. Il existe un concept de file d'attente de sortie virtuelle (VOQ) qui est fréquemment utilisé sur la plate-forme Nexus. VOQ est une allocation de tampons d'entrée pour chaque classe de service (CoS) IEEE 802.1p par port de sortie. Il y a donc 8 VOQ par port de sortie.

La congestion sur un port de sortie dans une CoS finit par saigner dans la congestion de sa VOQ correspondante sur le port d'entrée. Une fois la limite atteinte, le trafic est abandonné. Il n'affecte cependant pas le trafic destiné à d'autres CoS ou autres interfaces de sortie, évitant ainsi la fonction HOLB, qui autrement provoquerait la propagation de la congestion. Le flux de trafic entre le port d'entrée et le port de sortie et les différents blocs en jeu sont comme illustré dans l'image.

Scénarios de dépannage

Scénario 1. Rejets d'entrée

Configuration des travaux pratiques :

Trafic de débit de ligne sortant e1/3 et surabonnement possible :

nexus6001# sh int e1/3

Ethernet1/3 is up

Dedicated Interface

Hardware: 1000/10000 Ethernet, address: 002a.6a56.7a8a (bia 002a.6a56.7a8a)

Description: spirent 4/11

MTU 1500 bytes, BW 1000000 Kbit,, BW 1000000 Kbit, DLY 10 usec

reliability 255/255, txload 251/255, rxload 25/255

Encapsulation ARPA, medium is broadcast

Port mode is trunk

full-duplex, 1000 Mb/s

Beacon is turned off

Input flow-control is off, output flow-control is off

Switchport monitor is off

EtherType is 0x8100

Last link flapped 11:39:20

Last clearing of "show interface" counters 00:00:15

0 interface resets

30 seconds input rate 98683696 bits/sec, 8223 packets/sec

30 seconds output rate 986853640 bits/sec, 82019 packets/sec

Load-Interval #2: 5 minute (300 seconds)

input rate 98.68 Mbps, 8.22 Kpps; output rate 986.85 Mbps, 82.01 Kpps

RX

124003 unicast packets  0 multicast packets  0 broadcast packets

124003 input packets  186004500 bytes

0 jumbo packets  0 storm suppression bytes

0 runts  0 giants  0 CRC  0 no buffer

0 input error  0 short frame  0 overrun   0 underrun  0 ignored

0 watchdog  0 bad etype drop  0 bad proto drop  0 if down drop

0 input with dribble  0 input discard

0 Rx pause

TX

1236745 unicast packets  9 multicast packets  0 broadcast packets

1236754 output packets  1860065401 bytes

0 jumbo packets

0 output error  0 collision  0 deferred  0 late collision

0 lost carrier  0 no carrier  0 babble 0 output discard

0 Tx pause

nexus6001# sh int e1/4

Ethernet1/4 is up

Dedicated Interface

Hardware: 1000/10000 Ethernet, address: 002a.6a56.7a8b (bia 002a.6a56.7a8b)

Description: spirent 4/12

MTU 1500 bytes, BW 1000000 Kbit,, BW 1000000 Kbit, DLY 10 usec

reliability 255/255, txload 25/255, rxload 251/255

Encapsulation ARPA, medium is broadcast

Port mode is access

full-duplex, 1000 Mb/s

Beacon is turned off

Input flow-control is off, output flow-control is off

Switchport monitor is off

EtherType is 0x8100

Last link flapped 10:53:31

Last clearing of "show interface" counters 00:00:04

0 interface resets

30 seconds input rate 986840376 bits/sec, 82236 packets/sec

30 seconds output rate 98421072 bits/sec, 8223 packets/sec

Load-Interval #2: 5 minute (300 seconds)

input rate 986.84 Mbps, 82.23 Kpps; output rate 98.42 Mbps, 8.22 Kpps

RX

326332 unicast packets  0 multicast packets  0 broadcast packets

326332 input packets  489496500 bytes

0 jumbo packets  0 storm suppression bytes

0 runts  0 giants  0 CRC  0 no buffer

0 input error  0 short frame  0 overrun   0 underrun  0 ignored

0 watchdog  0 bad etype drop  0 bad proto drop  0 if down drop

0 input with dribble  863 input discard >>>>>>

0 Rx pause

TX

32633 unicast packets  2 multicast packets  0 broadcast packets

32635 output packets  48819096 bytes

0 jumbo packets

0 output error  0 collision  0 deferred  0 late collision

0 lost carrier  0 no carrier  0 babble 0 output discard

0 Tx pause

Dans une configuration simulée comme ici, vous connaissez la cause du surabonnement mais dans une configuration de production où le profil de trafic a éclaté et il peut être difficile de repérer les ports de sortie encombrés à l'aide de ces commandes.

Les étapes répertoriées ici vous aident à identifier les ports de sortie congestionnés.

Étape 1. Identifier les ports avec les rejets en entrée

Ignorations d'entrée affichées sur le port e1/4 :

nexus6001# sh int e1/4 | in i disc

0 input with dribble  3024 input discard

0 lost carrier  0 no carrier  0 babble 0 output discard

nexus6001# sh queuing int e1/4

Ethernet1/4 queuing information:

TX Queuing

qos-group  sched-type  oper-bandwidth

0       WRR            100

RX Queuing

qos-group 0 >>>> Drops in QOS 0

q-size: 100160, q-size-40g: 100160, HW MTU: 1500 (1500 configured)

drop-type: drop, xon: 0, xoff: 0

Statistics:

Pkts received over the port             : 9612480

Ucast pkts sent to the cross-bar        : 9587016

Mcast pkts sent to the cross-bar        : 0

Ucast pkts received from the cross-bar  : 961249

Pkts sent to the port                   : 961261

Pkts discarded on ingress               : 3024 >>>>>>

Per-priority-pause status               : Rx (Inactive), Tx (Inactive)

Étape 2. Identification ASIC

- Associez l'interface au numéro ASIC (UPC) interne à partir de cette sortie.

- Découvrez l'ID ASIC d'entrée à partir de l'ID de port d'entrée sur lequel vous avez remarqué des abandons.

nexus6001# sh hard internal bigsur all-ports

Bigsur Port Info:

Port     |asic|inst|inst|

name     |idx |slot|asic|eport|logi|flag|adm|opr|if_index|diag|ucVer

---------+----+----+----+-----+----+----+---+---+--------+----+-----

sup1     |0   |0   |0   | 0 - |48  |b3  |en |dn |15010000|pass| 0.00

sup0     |0   |0   |0   | 1 - |49  |b3  |en |dn |15020000|pass| 0.00

1gb1/1   |1   |0   |1   | 2 - |0   |b3  |en |up |1a000000|pass| 0.00

1gb1/2   |1   |0   |1   | 3 - |1   |b3  |en |up |1a001000|pass| 0.00

1gb1/3   |1   |0   |1   | 0 - |2   |b3  |en |up |1a002000|pass| 0.00

1gb1/4   |1** |0   |1   | 1 - |3   |b3  |en |up |1a003000|pass| 0.00 >>>>** is the asic number

1gb1/5   |1   |0   |1   | 6 - |4   |b3  |en |up |1a004000|pass| 0.00

1gb1/6   |1   |0   |1   | 7 - |5   |b3  |en |up |1a005000|pass| 0.00

1gb1/7   |1   |0   |1   | 4 - |6   |b3  |en |up |1a006000|pass| 0.00

1gb1/8   |1   |0   |1   | 5 - |7   |b3  |en |up |1a007000|pass| 0.00

1gb1/9   |1   |0   |1   |10 - |8   |b3  |en |up |1a008000|pass| 0.00

1gb1/10  |1   |0   |1   |11 - |9   |b3  |en |up |1a009000|pass| 0.00

1gb1/11  |1   |0   |1   | 8 - |10  |b3  |en |up |1a00a000|pass| 0.00

xgb1/12  |1   |0   |1   | 9 - |11  |b3  |en |dn |1a00b000|pass| 0.00

xgb1/13  |2   |0   |2   | 2 - |12  |b3  |en |dn |1a00c000|pass| 0.00

xgb1/14  |2   |0   |2   | 3 - |13  |b3  |en |dn |1a00d000|pass| 0.00

xgb1/15  |2   |0   |2   | 0 - |14  |b3  |en |dn |1a00e000|pass| 0.00

xgb1/16  |2   |0   |2   | 1 - |15  |b3  |en |dn |1a00f000|pass| 0.00

xgb1/17  |2   |0   |2   | 6 - |16  |b3  |en |dn |1a010000|pass| 0.00

xgb1/18  |2   |0   |2   | 7 - |17  |b3  |en |dn |1a011000|pass| 0.00

xgb1/19  |2   |0   |2   | 4 - |18  |b3  |en |dn |1a012000|pass| 0.00

xgb1/20  |2   |0   |2   | 5 - |19  |b3  |en |dn |1a013000|pass| 0.00

xgb1/21  |2   |0   |2   |10 - |20  |b3  |en |dn |1a014000|pass| 0.00

xgb1/22  |2   |0   |2   |11 - |21  |b3  |en |dn |1a015000|pass| 0.00

xgb1/23  |2   |0   |2   | 8 - |22  |b3  |en |dn |1a016000|pass| 0.00

xgb1/24  |2   |0   |2   | 9 - |23  |b3  |en |dn |1a017000|pass| 0.00

xgb1/25  |3   |0   |3   | 2 - |24  |b3  |en |dn |1a018000|pass| 0.00

xgb1/26  |3   |0   |3   | 3 - |25  |b3  |en |dn |1a019000|pass| 0.00

xgb1/27  |3   |0   |3   | 0 - |26  |b3  |en |dn |1a01a000|pass| 0.00

xgb1/28  |3   |0   |3   | 1 - |27  |b3  |en |dn |1a01b000|pass| 0.00

xgb1/29  |3   |0   |3   | 6 - |28  |b3  |en |dn |1a01c000|pass| 0.00

xgb1/30  |3   |0   |3   | 7 - |29  |b3  |en |dn |1a01d000|pass| 0.00

xgb1/31  |3   |0   |3   | 4 - |30  |b3  |en |dn |1a01e000|pass| 0.00

xgb1/32  |3   |0   |3   | 5 - |31  |b3  |en |dn |1a01f000|pass| 0.00

xgb1/33  |3   |0   |3   |10 - |32  |b3  |en |dn |1a020000|pass| 0.00

xgb1/34  |3   |0   |3   |11 - |33  |b3  |en |dn |1a021000|pass| 0.00

xgb1/35  |3   |0   |3   | 8 - |34  |b3  |en |dn |1a022000|pass| 0.00

xgb1/36  |3   |0   |3   | 9 - |35  |b3  |en |dn |1a023000|pass| 0.00

xgb1/37  |4   |0   |4   | 2 - |36  |b3  |en |dn |1a024000|pass| 0.00

xgb1/38  |4   |0   |4   | 3 - |37  |b3  |en |dn |1a025000|pass| 0.00

xgb1/39  |4   |0   |4   | 0 - |38  |b3  |en |dn |1a026000|pass| 0.00

xgb1/40  |4   |0   |4   | 1 - |39  |b3  |en |dn |1a027000|pass| 0.00

xgb1/41  |4   |0   |4   | 6 - |40  |b3  |en |dn |1a028000|pass| 0.00

xgb1/42  |4   |0   |4   | 7 - |41  |b3  |en |dn |1a029000|pass| 0.00

xgb1/43  |4   |0   |4   | 4 - |42  |b3  |en |dn |1a02a000|pass| 0.00

xgb1/44  |4   |0   |4   | 5 - |43  |b3  |en |dn |1a02b000|pass| 0.00

xgb1/45  |4   |0   |4   |10 - |44  |b3  |en |dn |1a02c000|pass| 0.00

xgb1/46  |4   |0   |4   |11 - |45  |b3  |en |dn |1a02d000|pass| 0.00

xgb1/47  |4   |0   |4   | 8 - |46  |b3  |en |dn |1a02e000|pass| 0.00

xgb1/48  |4   |0   |4   | 9 - |47  |b3  |en |dn |1a02f000|pass| 0.00

40gb2/1  |5   |1   |0   | 2 - |0   |b3  |dis|dn |1a0f0000|pass| 0.00

40gb2/2  |5   |1   |0   | 1 - |1   |b3  |dis|dn |1a0f1000|pass| 0.00

40gb2/3  |6   |1   |1   | 2 - |2   |b3  |dis|dn |1a0f2000|pass| 0.00

40gb2/4  |6   |1   |1   | 1 - |3   |b3  |dis|dn |1a0f3000|pass| 0.00

Done.

Étape 3. Identifier le port congestionné de sortie

- Identifiez le port de sortie congestionné avec des compteurs VOQ.

- Utilisez le numéro ASIC dans counters voq asic-num afin de déterminer quel port de sortie contribue aux pertes.

nexus6001# sh plat soft qd info counters voq asic-num 1

+----------+------------------------------+------------------------+-----------+

|      port|                      TRANSMIT|               TAIL DROP|  HEAD DROP|

+----------+------------------------------+------------------------+-----------+

Eth1/3

QUEUE-3                       3222876464                  8545008           0

Eth1/4

QUEUE-3                        323451170                        0           0

Eth1/6

QUEUE-3                           871362                        0           0

SUP_HI

QUEUE-0                             2041                        0           0

+----------+------------------------------+------------------------+-----------+

Scenerio 2. Rejets d'entrée avec HOLB

Configuration des travaux pratiques :

Tous les ports sont dans le VLAN 100.

Vous pouvez voir les rejets d'entrée sur e1/4 et e1/1 qui dépendent du débit de trafic sur les interfaces d'entrée vers 1/3.

nexus6001# sh int e1/4 | in discard|rate

30 seconds input rate 592103840 bits/sec, 49341 packets/sec

30 seconds output rate 166412120 bits/sec, 13863 packets/sec

input rate 592.10 Mbps, 49.34 Kpps; output rate 834.82 Mbps, 69.55 Kpps

0 input with dribble  15245 input discard

0 lost carrier  0 no carrier  0 babble 0 output discard

nexus6001# sh int e1/1 | in discard|rate

30 seconds input rate 986839872 bits/sec, 82236 packets/sec

30 seconds output rate 99790992 bits/sec, 8310 packets/sec

input rate 986.84 Mbps, 82.23 Kpps; output rate 500.88 Mbps, 41.73 Kpps

0 input with dribble  110632 input discard

0 lost carrier  0 no carrier  0 babble 0 output discard

Avec l'utilisation du même processus que celui documenté pour Scenerio 1. Vous pouvez trouver le port congestionné de sortie.

nexus6001# sh plat so qd info counters voq asic-num 1 <snip>

+----------+------------------------------+------------------------+-----------+

|      port|                      TRANSMIT|               TAIL DROP|  HEAD DROP|

+----------+------------------------------+------------------------+-----------+

Eth1/3

QUEUE-3                       3893719464                164782171           0

Le flux qui doit être affecté est vers 10.10.10.50. Le flux entre 10.10.10.101 et 10.10.10.102 doit être propre.

Ce n'est toutefois pas le cas. Un port de sortie bloqué ou à drainage lent peut entraîner l'épuisement de toutes les tampons sur un ou plusieurs ports d'entrée qui envoie le trafic vers le port de sortie, ce qui affecte ainsi l'ensemble du trafic sur ces ports d'entrée. C'est le problème classique de la HOLB.

Les générateurs de trafic indésirables montrent que les flux sont abandonnés. Les numéros de port sont des numéros de port Spirent, comme le montre l'image.

Atténuation HOLB : Activer la limite de VOQ

Afin d'éviter ce scénario, les VOQ (uniquement pour le trafic de monodiffusion) peuvent être configurées avec un seuil défini.

nexus6001(config)# hard unicast voq-limit

Après la configuration, les flux vers les ports non encombrés ne sont pas affectés.

L'affichage du générateur de trafic indésirable après la configuration de la limite de VOQ est comme illustré dans l'image.

Bien que cette configuration présente un avantage clair afin d'éviter les chutes dues à la HOLB. Pourquoi n'est-ce pas la configuration par défaut ?

En général, le trafic dans un environnement de production peut éclater dans la nature. En désactivant le seuil VOQ, vous autorisez les tampons d'entrée à absorber une micro-rafale de trafic sans avoir à être abandonnés.

À moins que la situation ne justifie la nécessité d'activer la limite de VOQ, il est recommandé d'utiliser la valeur par défaut qui est de la désactiver.

Atténuation HOLB : Classification du trafic

Il existe une autre méthode pour atténuer la charge HOLB avec l'utilisation de la configuration QoS. Puisque les rejets en entrée affectent uniquement une VOQ spécifique qui est à son tour une classe QOS spécifique, vous pouvez mapper le trafic affecté à un port non encombré à un autre groupe QOS. À partir de cette sortie, les rejets d'entrée affectent la classe de groupe 0 QOS.

nexus6001# sh queuing int e1/4

Ethernet1/4 queuing information:

TX Queuing

qos-group  sched-type  oper-bandwidth

0       WRR            100

RX Queuing

qos-group 0 >>>> Drops in QOS 0

q-size: 100160, q-size-40g: 100160, HW MTU: 1500 (1500 configured)

drop-type: drop, xon: 0, xoff: 0

Statistics:

Pkts received over the port             : 9612480

Ucast pkts sent to the cross-bar        : 9587016

Mcast pkts sent to the cross-bar        : 0

Ucast pkts received from the cross-bar  : 961249

Pkts sent to the port                   : 961261

Pkts discarded on ingress               : 3024 >>>>>>

Per-priority-pause status               : Rx (Inactive), Tx (Inactive)

La configuration ici mappe le trafic important vers QoS-Group 2.

1. Définissez une liste de contrôle d’accès pour le trafic qui ne doit pas être abandonné. L'objectif est de classer ce trafic dans un groupe QOS différent afin qu'il ne soit pas affecté.

ip access-list SINGLEFLOW

statistics per-entry

10 permit ip 10.10.10.101/32 10.10.10.102/32

2. Classification QoS :

class-map type qos match-all FIX_AFFECTED_FLOW

match access-group name SINGLEFLOW

policy-map type qos QOS_POLICY_FIX_AFFECTED_FLOW

class FIX_AFFECTED_FLOW

set qos-group 2

3. Configuration QoS du réseau :

class-map type network-qos QOSGRP2

match qos-group 2

policy-map type network-qos NQOS-GRP2

class type network-qos QOSGRP2

class type network-qos class-default

4. Appliquez les différentes politiques. La QoS du réseau s'étend à l'ensemble du système, tandis que la stratégie de classification peut être appliquée à une interface unique.

system qos

service-policy type network-qos NQOS-GRP2

interface Ethernet1/1

service-policy type qos input QOS_POLICY_FIX_AFFECTED_FLOW

5. Les pertes ne sont pas visibles pour la classe de groupe QoS 2 :

nexus6001(config-if)# sh queuing int e1/1

Ethernet1/1 queuing information:

TX Queuing

qos-group  sched-type  oper-bandwidth

0       WRR            100

2       WRR              0

RX Queuing

qos-group 0

q-size: 100160, q-size-40g: 100160, HW MTU: 1500 (1500 configured)

drop-type: drop, xon: 0, xoff: 0

Statistics:

Pkts received over the port             : 525111

Ucast pkts sent to the cross-bar        : 327510

Mcast pkts sent to the cross-bar        : 0

Ucast pkts received from the cross-bar  : 0

Pkts sent to the port                   : 0

Pkts discarded on ingress               : 197868 >>>>

Per-priority-pause status               : Rx (Inactive), Tx (Inactive)

qos-group 2

q-size: 100160, q-size-40g: 100160, HW MTU: 1500 (1500 configured)

drop-type: drop, xon: 0, xoff: 0

Statistics:

Pkts received over the port             : 131413

Ucast pkts sent to the cross-bar        : 132096

Mcast pkts sent to the cross-bar        : 0

Ucast pkts received from the cross-bar  : 0

Pkts sent to the port                   : 0

Pkts discarded on ingress               : 0 >>> No Drops

Per-priority-pause status               : Rx (Inactive), Tx (Inactive)

Informations connexes

- Exemple de configuration QoS des commutateurs de la gamme Nexus 6000

- Support et documentation techniques - Cisco Systems