Configuration de la qualité de service sur UCS et Nexus 5000
Contenu
Introduction
Ce document décrit la configuration de la qualité de service (QoS) au sein des périphériques UCS (Unified Computing System) et Nexus.
Conditions préalables
Conditions requises
Aucune spécification déterminée n'est requise pour ce document.
Components Used
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
- Interconnexion de fabric UCS (FI) 6100 et 6200
- Nexus 5000 et 5500
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
Ce document traite des interconnexions de fabric UCS(6100 et 6200) et de la QoS Nexus(5000 et 5500) spécifiquement liées à FlexPod et vBlock.
Terminologie utilisée dans cette documentation relative à la qualité de service.
CoS = Classe de service = 802.1p = 3 bits en en-tête .1q sur chaque paquet pour indiquer au commutateur comment classer.
QoS = Qualité de service = Comment le commutateur gère chaque classe de service.
MTU = unité de transmission maximale = taille maximale d’une trame/d’un paquet autorisée sur le commutateur. La valeur la plus courante et la valeur par défaut (normale est celle que montre la capture d'écran UCS ci-dessous) est 1500.
Configuration
QoS UCS prêt à l'emploi
Paramètres QoS UCS de référence (UCSM / LAN / QoS System Class) :
Configuration QoS par défaut
P10-UCS-A(nxos)# show running-config ipqos
logging level ipqosmgr 2
class-map type qos class-fcoe
class-map type queuing class-fcoe
match qos-group 1
class-map type queuing class-all-flood
match qos-group 2
class-map type queuing class-ip-multicast
match qos-group 2
policy-map type qos system_qos_policy
class class-fcoe
set qos-group 1
class class-default
policy-map type queuing system_q_in_policy
class type queuing class-fcoe
bandwidth percent 50
class type queuing class-default
bandwidth percent 50
policy-map type queuing system_q_out_policy
class type queuing class-fcoe
bandwidth percent 50
class type queuing class-default
bandwidth percent 50
class-map type network-qos class-fcoe
match qos-group 1
class-map type network-qos class-all-flood
match qos-group 2
class-map type network-qos class-ip-multicast
match qos-group 2
policy-map type network-qos system_nq_policy
class type network-qos class-fcoe
pause no-drop
mtu 2158
class type network-qos class-default
system qos
service-policy type qos input system_qos_policy
service-policy type queuing input system_q_in_policy
service-policy type queuing output system_q_out_policy
service-policy type network-qos system_nq_policy
Informations pertinentes :
- qos-group est la manière dont le commutateur traite en interne une CoS donnée. Considérez qos-group comme un seau ou une voie dans laquelle chaque paquet va.
- Best Effort n'obtenant pas de groupe qos explicite, il utilise par défaut qos-group 0
- Fibre Channel over Ethernet (FCoE) a CoS 3 et est placé dans qos-group 1
Feuille de tricherie CoS <=> qos-group
| CoS | qos-group | |
| Platine | 5 | 2 |
| Or | 4 | 3 |
| Argent | 2 | 4 |
| Bronze | 1 | 5 |
| Meilleur effort | tous les modèles | 0 |
| Fibre Channel | 3 | 1 |
La CoS peut être modifiée en CoS 6 sur UCS. La CoS 7 est réservée aux communications UCS internes.
show queuing interface, commande
P10-UCS-A(nxos)# show queuing interface
Ethernet1/1 queuing information:
TX Queuing
qos-group sched-type oper-bandwidth
0 WRR 50
1 WRR 50
RX Queuing
qos-group 0
q-size: 360640, HW MTU: 1500 (1500 configured)
drop-type: drop, xon: 0, xoff: 360640
Statistics:
Pkts received over the port : 27957
Ucast pkts sent to the cross-bar : 0
Mcast pkts sent to the cross-bar : 27957
Ucast pkts received from the cross-bar : 0
Pkts sent to the port : 347
Pkts discarded on ingress : 0
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
qos-group 1
q-size: 79360, HW MTU: 2158 (2158 configured)
drop-type: no-drop, xon: 20480, xoff: 40320
Statistics:
Pkts received over the port : 0
Ucast pkts sent to the cross-bar : 0
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
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
Total Multicast crossbar statistics:
Mcast pkts received from the cross-bar : 347
Ce résultat montre comment cette interface met en file d'attente chaque classe.
Informations sur le port de commutateur Ethernet 1/1 :
- Best Effort obtient qos-group 0 et une taille q de 360640 octets de mémoires tampon et un MTU de 1500.
- Ce port a introduit/reçu 27957 paquets de Best Effort et a reçu/envoyé 347 paquets.
- « Pkts jetés en entrée » est le nombre de paquets qui ont été reçus mais pendant ce moment le tampon (q-size) était plein et le commutateur a décidé de rejeter, c'est aussi ce que l'on appelle la queue drop.
Port IOM
Afficher l'interface de mise en file d'attente des ports IOM (Input and Output Modules) du châssis UCS :
Ethernet1/1/1 queuing information: Input buffer allocation: Qos-group: 1 frh: 3 drop-type: no-drop cos: 3 xon xoff buffer-size ---------+---------+----------- 8960 14080 24320 Qos-group: 0 frh: 8 drop-type: drop cos: 0 1 2 4 5 6 xon xoff buffer-size ---------+---------+----------- 0 117760 126720 Queueing: queue qos-group cos priority bandwidth mtu --------+------------+--------------+---------+---------+---- 2 0 0 1 2 4 5 6 WRR 50 1600 3 1 3 WRR 50 2240 Queue limit: 66560 bytes Queue Statistics: queue rx tx ------+---------------+--------------- 2 18098 28051 3 0 0 Port Statistics: rx drop rx mcast drop rx error tx drop mux ovflow ---------------+---------------+---------------+---------------+-------------- 0 0 0 0 InActive Priority-flow-control enabled: yes Flow-control status: cos qos-group rx pause tx pause masked rx pause -------+-----------+---------+---------+--------------- 0 0 xon xon xon 1 0 xon xon xon 2 0 xon xon xon 3 1 xon xon xon 4 0 xon xon xon 5 0 xon xon xon 6 0 xon xon xon 7 n/a xon xon xon
Il y a qos-group 0 et qos-group 1, qos-group 0 reçoit les paquets marqués de cos 0 1 2 4 5 6 et qos-group 1 get cos 3. La taille de la mémoire tampon sur les extenseurs de fabric (FEX)/IOM est un peu plus petite et n'est que de 126 720 octets. Le FEX fait la QoS légèrement différemment et prend plusieurs groupes de QoS et les regroupe dans une file d'attente. Les compteurs rx et tx de chaque file d'attente peuvent être affichés.
show interface priority-flow-control
La dernière sortie à extraire est la suivante : show interface priority-flow-control
P10-UCS-A(nxos)# show interface priority-flow-control ============================================================ Port Mode Oper(VL bmap) RxPPP TxPPP ============================================================ Ethernet1/1 Auto Off 0 0 Ethernet1/2 Auto Off 0 0 Ethernet1/3 Auto Off 0 0 Ethernet1/4 Auto Off 6 0 Ethernet1/5 Auto Off 0 0 Ethernet1/6 Auto Off 0 0 Ethernet1/7 Auto Off 0 0 Ethernet1/8 Auto Off 0 0 Ethernet1/9 Auto Off 0 0 Ethernet1/10 Auto Off 2 0 ..snip.. Vethernet733 Auto Off 0 0 Vethernet735 Auto Off 0 0 Vethernet737 Auto Off 0 0 Ethernet1/1/1 Auto On (8) 0 0 Ethernet1/1/2 Auto Off 0 0 Ethernet1/1/3 Auto On (8) 0 0 Ethernet1/1/4 Auto Off 0 0
Ceci montre quelles interfaces PFC négocie (Auto On) et quelles interfaces PFC ne négocie pas (Auto Off). PFC est un moyen pour un commutateur de demander à un commutateur voisin de ne pas envoyer de paquets d'une CoS spécifique pendant une courte période. Les pauses PFC (PPP, par pause de priorité) se produisent lorsque les tampons sont pleins/presque pleins. La sortie de la commande show cdp neighbors et de la commande show fex details nous indique que le port Ethernet 1/1-4 est inférieur au port FEX/IOM du châssis 1 et le port Ethernet 1/9-10 est supérieur au port Nexus 5000. Dans ce résultat, 6 pauses ont été envoyées à FEX/IOM sur Ethernet 1/4 et 2 pauses ont été envoyées à Ethernet1/10 vers le Nexus 5000 en amont.
- Les PPP eux-mêmes NE SONT PAS UNE MAUVAISE CHOSE !
Voilà à quoi ressemble la qualité de service UCS....
Que se passe-t-il si Silver est activé ?
Cela entraîne une configuration :
class-map type qos class-fcoe
class-map type qos match-all class-silver match cos 2 class-map type queuing class-silver match qos-group 4
class-map type queuing class-all-flood
match qos-group 2
class-map type queuing class-ip-multicast
match qos-group 2
policy-map type qos system_qos_policy
class class-silver set qos-group 4
policy-map type queuing system_q_in_policy
class type queuing class-silver bandwidth percent 44
class type queuing class-fcoe
bandwidth percent 29
class type queuing class-default
bandwidth percent 27
policy-map type queuing system_q_out_policy
class type queuing class-silver bandwidth percent 44
class type queuing class-fcoe
bandwidth percent 29
class type queuing class-default
bandwidth percent 27
policy-map type queuing org-root/ep-qos-Default-Qos
class type queuing class-fcoe
class type queuing class-default
bandwidth percent 50
shape 40000000 kbps 10240
class-map type network-qos class-silver match qos-group 4class-map type network-qos class-all-flood
match qos-group 2
class-map type network-qos class-ip-multicast
match qos-group 2
policy-map type network-qos system_nq_policy
class type network-qos class-silver
class type network-qos class-fcoe
pause no-drop
mtu 2158
class type network-qos class-default
system qos
service-policy type qos input system_qos_policy
service-policy type queuing input system_q_in_policy
service-policy type queuing output system_q_out_policy
service-policy type network-qos system_nq_policy
Ethernet1/1 queuing information:
TX Queuing
qos-group sched-type oper-bandwidth
0 WRR 27
1 WRR 29
4 WRR 44
RX Queuing
qos-group 0
q-size: 308160, HW MTU: 9216 (9216 configured)
drop-type: drop, xon: 0, xoff: 301120
Statistics:
Pkts received over the port : 12
Ucast pkts sent to the cross-bar : 12
Mcast pkts sent to the cross-bar : 0
Ucast pkts received from the cross-bar : 17
Pkts sent to the port : 17
Pkts discarded on ingress : 0
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
qos-group 1
q-size: 79360, HW MTU: 2158 (2158 configured)
drop-type: no-drop, xon: 20480, xoff: 40320
Statistics:
Pkts received over the port : 7836003
Ucast pkts sent to the cross-bar : 7836003
Mcast pkts sent to the cross-bar : 0
Ucast pkts received from the cross-bar : 4551954
Pkts sent to the port : 4551954
Pkts discarded on ingress : 0
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
qos-group 4 q-size: 22720, HW MTU: 1500 (1500 configured)
drop-type: drop, xon: 0, xoff: 22720
Statistics:
Pkts received over the port : 0
Ucast pkts sent to the cross-bar : 0
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
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
Notez que le Best Effort (qos-group 0) q-size est passé de 360640 à 308160 parce que Silver (qos-group 4) a été attribué 22720 d'espace tampon.
Et si Silver est fait Jumbo ?
Définissez MTU sur 9216.
Ethernet1/1 queuing information:
TX Queuing
qos-group sched-type oper-bandwidth
0 WRR 27
1 WRR 29
4 WRR 44
RX Queuing
qos-group 0
q-size: 301120, HW MTU: 9216 (9216 configured)
drop-type: drop, xon: 0, xoff: 301120
Statistics:
Pkts received over the port : 3
Ucast pkts sent to the cross-bar : 3
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
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
qos-group 1
q-size: 79360, HW MTU: 2158 (2158 configured)
drop-type: no-drop, xon: 20480, xoff: 40320
Statistics:
Pkts received over the port : 7842224
Ucast pkts sent to the cross-bar : 7842224
Mcast pkts sent to the cross-bar : 0
Ucast pkts received from the cross-bar : 4555791
Pkts sent to the port : 4555791
Pkts discarded on ingress : 0
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
qos-group 4
q-size: 29760, HW MTU: 9216 (9216 configured)
drop-type: drop, xon: 0, xoff: 29760
Statistics:
Pkts received over the port : 0
Ucast pkts sent to the cross-bar : 0
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
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
Silver(qos-group 4) obtient maintenant 29760 q-size, contre 22720.
Et si Silver est fait sans goutte ?
Désélectionnez le paramètre Packet Drop ?
Ethernet1/1 queuing information:
TX Queuing
qos-group sched-type oper-bandwidth
0 WRR 27
1 WRR 29
4 WRR 44
RX Queuing
qos-group 0
q-size: 240640, HW MTU: 9216 (9216 configured)
drop-type: drop, xon: 0, xoff: 240640
Statistics:
Pkts received over the port : 20
Ucast pkts sent to the cross-bar : 20
Mcast pkts sent to the cross-bar : 0
Ucast pkts received from the cross-bar : 1
Pkts sent to the port : 1
Pkts discarded on ingress : 0
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
qos-group 1
q-size: 79360, HW MTU: 2158 (2158 configured)
drop-type: no-drop, xon: 20480, xoff: 40320
Statistics:
Pkts received over the port : 7837323
Ucast pkts sent to the cross-bar : 7837323
Mcast pkts sent to the cross-bar : 0
Ucast pkts received from the cross-bar : 4552726
Pkts sent to the port : 4552726
Pkts discarded on ingress : 0
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
qos-group 4 q-size: 90240, HW MTU: 9216 (9216 configured)
drop-type: no-drop, xon: 17280, xoff: 37120
Statistics:
Pkts received over the port : 0
Ucast pkts sent to the cross-bar : 0
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
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
Notez que la taille Silver (qos-group 4) q passe à 90240, que les modifications Drop à no-drop et que Best Effort qos-group 0 sont réduites à 240640.
L'espace tampon du groupe QoS 0 du meilleur effort est réalloué aux autres classes QoS.
Nexus 5000 en amont
Les configurations QoS par défaut du Nexus 5000 sont similaires mais pas exactes.
show running-config ipqos
P10-5k-a# show running-config ipqos
policy-map type network-qos jumbo
class type network-qos class-fcoe
pause no-drop
mtu 2158
class type network-qos class-default
mtu 9216
multicast-optimize
system qos
service-policy type network-qos jumbo
Le Nexus 5000 masque les options par défaut, de sorte que show running-config ipqos all est nécessaire pour voir l'ensemble de la configuration.
show queuing interface
P10-5k-a# show queuing interface
Ethernet1/1 queuing information:
TX Queuing
qos-group sched-type oper-bandwidth
0 WRR 100
1 WRR 0
RX Queuing
qos-group 0
q-size: 360640, HW MTU: 9216 (9216 configured)
drop-type: drop, xon: 0, xoff: 360640
Statistics:
Pkts received over the port : 16
Ucast pkts sent to the cross-bar : 16
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
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
qos-group 1
q-size: 79360, HW MTU: 2158 (2158 configured)
drop-type: no-drop, xon: 20480, xoff: 40320
Statistics:
Pkts received over the port : 0
Ucast pkts sent to the cross-bar : 0
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
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
show interface priority-flow-control
Les ports descendant vers l'UCS (Ethernet1/1 - 2) ont la carte PFC désactivée (Auto Off).
P10-5k-a(config-if-range)# show interface priority-flow-control ============================================================ Port Mode Oper(VL bmap) RxPPP TxPPP ============================================================ Ethernet1/1 Auto Off 0 0 Ethernet1/2 Auto Off 0 0 Ethernet1/3 Auto Off 0 0 Ethernet1/4 Auto Off 0 0 Ethernet1/5 Auto Off 0 0 Ethernet1/6 Auto Off 0 0 Ethernet1/7 Auto Off 0 0 Ethernet1/8 Auto Off 0 0 Ethernet1/9 Auto Off 0 0 Ethernet1/10 Auto On (0) 0 0 Ethernet1/11 Auto On (0) 0 0 Ethernet1/12 Auto On (0) 0 0 Ethernet1/13 Auto On (0) 0 0
..snip..
Ajouter FCoE à la configuration
Ces stratégies sont présentes par défaut sur le Nexus 5000 mais ne sont pas activées, il suffit donc de les utiliser.
system qos service-policy type queuing input fcoe-default-in-policy service-policy type queuing output fcoe-default-out-policy service-policy type qos input fcoe-default-in-policy
show interface priority-flow-control
Les ports descendant vers UCS (Ethernet1/1 - 2) ont PFC on (Auto On).
P10-5k-a(config-sys-qos)# sh int priority-flow-control ============================================================ Port Mode Oper(VL bmap) RxPPP TxPPP ============================================================ Ethernet1/1 Auto On (8) 0 0 Ethernet1/2 Auto On (8) 0 0 Ethernet1/3 Auto Off 0 0 Ethernet1/4 Auto Off 0 0
..snip..
PFC
PFC(802.1Qbb) est la manière dont les périphériques Nexus/UCS créent une structure sans perte dans le cadre du Data Center Bridging (DCBX). FCoE nécessite une structure sans perte, la FCoE à plusieurs sauts est particulièrement sujette à ce problème de configuration. Le commutateur en amont, généralement un Nexus 5000, doit correspondre aux paramètres QoS configurés sur UCS.
Comme indiqué précédemment, la carte PFC permet aux commutateurs d’avertir les commutateurs voisins de s’arrêter pour envoyer des trames supplémentaires. Réfléchissez à cela dans le contexte d’un environnement de réseau de commutateurs multiples avec un trafic qui va dans de nombreuses directions à la fois, non seulement cela ajoute des tampons de chemin1 (source1/destination1), mais cela multiplie les tampons car le commutateur voisin a probablement du trafic qui entre plusieurs ports (plusieurs tampons). Bien que la carte PFC ne soit pas nécessaire lorsque vous utilisez le stockage IP, elle contribue souvent à améliorer considérablement les performances en raison de cet effet de multiplication de mémoire tampon qui empêche la perte inutile de paquets.
Une excellente présentation PFC/DCBX.
Pourquoi PFC NE négocie-t-il PAS ?
La stratégie QoS sans abandon doit correspondre de chaque côté.
Si une classe QoS est définie sur un commutateur comme no-drop et non comme no-drop sur l'autre, PFC ne négocie pas. Comme UCS configure Platinum comme sans abandon mais désactivé prêt à l'emploi, cela se produit souvent lorsque Platinum est activé.
Les qos système doivent correspondre de chaque côté
Si les entrées de file d'attente et de file d'attente et les entrées qos ne correspondent pas, PFC ne négocie pas.
NetApp
Or
Par défaut, les filtres NetApp envoient TOUT le trafic de stockage IP étiqueté par NetApp dans CoS 4(Gold). Comme les bits de CoS se trouvent dans l'en-tête .1q lorsque NetApp est connecté à un port d'accès, le trafic NetApp est placé dans le meilleur effort.
QoS asymétrique
Une erreur de configuration courante est de choisir une autre couleur CoS (Silver) pour mettre le trafic NFS du système de fichiers réseau d'UCS dans et retourner le trafic NFS d'un NetApp est mis dans Gold. Donc le trafic est quelque chose comme :
| Serveur | UCS | Nexus 5K | NetApp |
| Envoyer | Argent > | Argent > | Meilleur effort |
| Recevoir | < Or | < Or | < Or |
Si UCS était configuré pour que Silver soit Jumbo mais NOT Gold, cela causerait des problèmes.
QoS non définie
Lorsqu'une classe QoS (Platinum/Gold/Silver/Bronze) n'est PAS activée, les périphériques UCS et Nexus traitent ces paquets comme le meilleur effort et les placent dans le groupe Qos 0.
| Serveur | UCS | Nexus 5K | NetApp |
| Envoyer | Argent > | Meilleur effort > | Meilleur effort |
| Recevoir | < Or | < Effort maximal | < Or |
Note: les bits CoS du paquet ne sont PAS modifiés/signalés, mais les paquets sont traités différemment.
QoS de l'environnement d'informatique virtuelle (VCE)
La conception QoS VCE est loin d'être idéale.
| Nexus 1k | UCS | Nexus 5K | |
| BE / CoS 0 | 1500 | 1500 | 1600 |
| FC/CoS 1 | - | 2158 (sans abandon) | - |
| CoS 6 |
gestion | - | - |
| Platine/CoS 5 |
- | 1 500 (sans abandon) | 1500 |
| Gold/CoS 4 | vexer | 1500 | 1500 |
| Silver/CoS 2 | NFS | - | 9216 (sans abandon) |
Si vous avez des classes de CoS définies à un niveau, mais ignorées à un autre niveau est compliqué et pourrait faire que les choses ne fonctionnent pas comme prévu. Par exemple, VCE utilise Silver pour NFS, mais si UCS n'a pas défini Silver, ce trafic est mis en file d'attente dans Best Effort qui n'est pas Jumbo et peut entraîner la suppression ou la fragmentation du trafic NFS. La carte PFC n'est pas négociée en raison des non-correspondances dans les politiques de suppression, mais c'est évidemment correct car la carte PFC n'est pas requise pour Ethernet.
Tampons légers
Les protocoles de stockage basés sur le protocole IP sont tous des protocoles très répandus et souvent configurés avec 9 000 MTU. En tant que tels, ils fonctionnent mal dans Platinum/Gold/Silver/Bronze en raison de la taille q 29760 / 9000 MTU autorise seulement 3 paquets dans le tampon avant que la queue-drop ne soit causé.
Tampons plus grands
La politique Ethernet UCS permet d'augmenter les tampons vNIC (taille de sonnerie). La valeur par défaut est 512 et la valeur maximale est 4096. si vous modifiez cette valeur au maximum, la latence totale de la mémoire tampon (##KB / 10Gbps) passe de 0,4 ms à 3,2 ms. Ainsi, les changements dans cette mémoire tampon permettent moins de chutes, mais au détriment d'une latence accrue.
9 216 MTU contre 9 000 MTU
Le point de la configuration des trames Jumbo est de permettre à un périphérique de point d'extrémité de parler à un autre périphérique de point d'extrémité avec des paquets de couche 3 de 9 000 octets. Lorsque des techniques d’encapsulation de couche 2 sont utilisées, les commutateurs et les routeurs entre les périphériques de point d’extrémité doivent être capables de gérer des trames de couche 2 légèrement plus grandes que 9 000 paquets de couche 3 MTU pour tenir compte de la surcharge d’encapsulation. En cas de doute, autorisez 9216 MTU sur les commutateurs.
PFC et PPP
Lorsque de nouveaux paquets sont mis en file d'attente, la mémoire tampon se remplit.
Lorsque le tampon atteint 20 Ko, il continue à se remplir.
Lorsque la mémoire tampon atteint 40 Ko, le commutateur envoie une pause PPP si cette file d'attente est sans abandon, ce qui indique que le commutateur distant doit s'arrêter pour envoyer le trafic.
Idéalement, le côté distant s'arrête rapidement pour envoyer le trafic et le reste du tampon (79360-40320) contient les paquets entrants en vol.
Les compteurs « Pkts ignorés en entrée » s'incrémentent lorsque le tampon est plein.
FC et FCoE est un protocole sans perte dans une situation idéale où le commutateur distant s'arrête pour envoyer le trafic et les niveaux de tampon finissent par tomber et atteindre 20 000. Le commutateur envoie une autre interruption PPP pour cette file d’attente sans abandon qui indique au commutateur distant de commencer à envoyer de nouveau du trafic.
Dépannage
Aucune information de dépannage spécifique n'est actuellement disponible pour cette configuration.
Informations connexes
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)