Comprendre CoS IEEE priorités 802.1p pour les flux de trafic sans perte

Configuration des classes de forwarding sans perte (attribut de perte de paquets)

Junos OS version 12.3 a introduit le paramètre d’absence de perte pour la configuration de la classe de forwarding. (Bien qu’il utilise le même nom, il ne s’agit pas de la classe de forwarding par défaut sans perte. Il s’agit d’un attribut de perte de paquets que vous pouvez spécifier pour configurer n’importe quelle classe de forwarding en tant que classe de passation sans perte.)

Remarque:

Sur les commutateurs qui utilisent différentes classes de transfert pour le trafic unicast et multidestré, la classe de transfert doit être une classe de transfert unicast. Sur les commutateurs qui utilisent les mêmes classes de transfert pour le trafic unicast et multidestré, seul le trafic unicast reçoit un traitement sans perte.

Vous pouvez configurer jusqu’à six classes de forwarding (en fonction de l’architecture système et de la disponibilité des ressources système) en tant que classes de forwarding sans perte en incluant l’attribut de perte au niveau de no-loss [edit class-of-service forwarding-classes class forwarding-class-name queue-num queue-number] la hiérarchie.

Si vous utilisez les classes de fcoe ou de forwarding sans perte par défaut, elles incluent l’attribut de perte sans perte par défaut. Si vous configurez les classes de forwarding fcoe ou sans perte et que vous souhaitez conserver leur comportement sans perte, vous devez inclure l’attribut de perte sans perte dans la configuration.

Remarque:

Toutes les classes de forwarding sont machées sur la même file d’attente de sortie et doivent avoir le même attribut de perte de paquets. (Toutes les classes de forwarding doivent être soit en perte, soit en perte) sur la même file d’attente de sortie. Vous ne pouvez pas mettre en place à la fois une classe de forwarding sans perte et une perte vers la même file d’attente.)

Pour éviter le fate sharing (un flux congestionné affectant un flux non ingéré), utilisez une mise en correspondance un à un des classes de passation sans perte vers les points de code (priorités) IEEE 802.1p et les files d’attente. Mapriez chaque classe de transfert sans perte vers une file d’attente différente et classifiez le trafic entrant en classes de transfert afin que chaque classe de transfert transporte le trafic d’une seule priorité (point de code).

Les classes fcoe et de forwarding sans perte sont des cas spéciaux, car dans la configuration par défaut, elles sont configurées pour un comportement sans perte (à condition que la fonction PFC soit également en place sur les priorités entre les classes fcoe et de forwarding sans perte dans la catégorie d’entrée CNP).

Le Tableau 2 résume les configurations possibles des classes de forwarding fcoe et sans perte dans Junos OS Version 12.3 et ultérieure, ainsi que le résultat de ces configurations en termes de comportement de trafic sans perte. Il est supposé que les PFC, DCBX et les classificateurs sont correctement configurés.

Pour toutes les autres classes de forwarding, à l’exception des classes de forwarding et de forwarding, vous devez configurer expressément le transport sans perte en spécifiant l’attribut de perte de paquet sans perte, car la configuration par défaut de toutes les autres classes de passation de paquets est sans perte (l’attribut de perte de paquet n’est pas fcoe no-loss appliqué).

Profils de notification de congestion (configuration PFC)

Utilisez les CPC pour configurer les caractéristiques PFC sans perte sur les interfaces d’entrée et de sortie.

La section entrée d’un CNP permet d’utiliser le PFC sur les priorités 802.1p IEEE spécifiées et d’affiner les paramètres de mise en mémoire tampon en configurant la valeur maximale de l’unité de réception (MRU) et la longueur du câble sur les interfaces d’entrée.

La chaîne de sortie d’un CNP permet de mettre en place un contrôle de flux PFC sur les files d’attente de sortie pour les priorités IEEE 802.1p spécifiées afin que les files d’attente peuvent répondre aux messages de pause PFC envoyés par l’pair connecté au niveau de priorité de votre choix. (Par défaut, les files d’attente de sortie 3 et 4 répondent aux messages PFC reçus lorsque ces files d’attente transportent respectivement du trafic sans perte dans les classes fcoe et de forwarding sans perte.)

Pour parvenir à un transport sans perte, la priorité suspendue aux interfaces d’entrée doit correspondre à la priorité suspendue au niveau des interfaces de sortie pour un flux de trafic donné. Par exemple, si vous configurez des interfaces d’entrée pour interrompre le trafic marqué avec IEEE 802.1p priority 5 (code point 101) et que le trafic de priorité 5 est associé à la file d’attente de sortie 5, vous devez également configurer les interfaces de sortie correspondantes pour interrompre la priorité 5 sur la file d’attente 5. De plus, la classe de forwarding mapée dans la file d’attente 5 doit être configurée comme une classe de forwarding sans perte (à l’aide de l’attribut de perte sans perte).

Attention:

Toute modification de la configuration PFC sur un port bloque temporairement l’ensemble du port (et non seulement les priorités affectées par le changement PFC) pour que le port puisse mettre en œuvre la modification, puis débloquer le port. Le blocage du port stoppe le trafic d’entrée et de sortie et provoque la perte de paquets sur toutes les files d’attente du port jusqu’à ce que le port soit bloqué.

Une modification de la configuration PFC implique toute modification d’un CNP, y compris la modification de la partie d’entrée du CNP (activation ou désactivation du PFC sur une priorité, modification du MRU ou des valeurs de longueur de câble) ou modification de la partie sortie du CNP qui active ou désactive le contrôle du flux de sortie sur une file d’attente. Une modification de configuration PFC affecte uniquement les ports qui utilisent le CNP modifié.

Les actions suivantes modifient la configuration PFC:

• Suppression ou désactivation d’une configuration PFC (entrée ou sortie) dans un CNP utilisé sur une ou plusieurs interfaces. Par exemple:

  1. Un CNP existant avec une sanza d’entrée qui permet d’établir les priorités 3, 5 et 6 est configurée sur les interfaces xe-0/0/20 et xe-0/0/21.

  2. Nous désactivons la configuration PFC pour la priorité 6 dans le CNP d’entrée, puis validation de la configuration.

  3. La modification de configuration PFC provoque l’arrêt de tout le trafic sur les interfaces xe-0/0/20 et xe-0/0/21 jusqu’à ce que la modification PFC soit implémentée. Une fois la modification PFC implémentée, le trafic reprend.

• La configuration d’un CNP sur une interface. (Cette évolution de l’état du PFC passe par l’activation du PFC sur une ou plusieurs priorités.)

• Suppression d’un CNP sur une interface. (Cette fonction modifie l’état PFC en désactivant le PFC sur une ou plusieurs priorités.)

Configuring Input Interface Flow Control (PFC and Headroom Buffer Calculation)

Sur les interfaces Ethernet, la sanza d’entrée du CNP permet au PFC de spécifier des priorités afin que l’interface d’entrée puisse envoyer un message de pause à l’pair connecté en cas de congestion. Les CPC d’entrée et d’entrée affiner les tampons de réserve utilisés pour la prise en charge de la technologie PFC en vous permettant de configurer la valeur MRU et la longueur du câble (si vous ne souhaitez pas utiliser la configuration par défaut).

Les tampons Headroom offrent une prise en charge du transport sans perte en stockant le trafic qui arrive à l’interface après que l’interface a envoyé un message de contrôle de flux PFC pour interrompre le trafic entrant. Jusqu’à ce que l’pair connecté reçoit le message de contrôle des flux et interrompe le trafic, l’interface continue de recevoir le trafic et doit le mettre en mémoire tampon (et le trafic reste sur le fil après la pause du pair) afin d’empêcher la perte de paquets.

Le système utilise la MRU et la longueur du câble physique associé pour calculer l’allocation des ressources tampons. Les valeurs de configuration par défaut sont les à:

• MRU pour le trafic de priorité 3: 2 500 octets

• MRU pour le trafic de priorité 4: 9 216 octets

• Longueur du câble: 100 mètres (environ 328 pieds)

Remarque:

Si vous configurez le contrôle de flux sur une priorité qui n’est pas l’une des priorités de contrôle de flux par défaut, la valeur MRU par défaut est de 2 500 octets. Par exemple, si vous configurez le contrôle des flux sur la priorité 5 et que vous ne configurez pas explicitement une valeur MRU, la valeur MRU par défaut est de 2 500 octets.

Vous pouvez ajuster la longueur du câble et le MRU pour ajuster la taille de la mise en mémoire tampon des chambres d’interface. Le commutateur dispose d’une liste de tampon globale partagée et alloue de manière dynamique l’espace tampon en réserve aux files d’attente sans perte, selon les besoins.

Un MRU inférieur ou une longueur de câble plus courte réduisent le niveau de mise en mémoire tampon requise sur une interface et laissent davantage d’espace tampon pour les autres interfaces. Un MRU plus élevé ou une longueur de câble plus longue augmente la quantité d’espace tampon requis sur une interface et laisse moins d’espace tampon pour les autres interfaces.

Dans de nombreux cas, vous pouvez mieux utiliser les tampons de réserve en réduisant la valeur du MRU (par exemple, un MRU de 2180 est suffisant pour la plupart des réseaux FCoE) et en réduisant la valeur de la longueur du câble si le câble physique est inférieur à 100 mètres.

Remarque:

Lorsque vous configurez les mise en mémoire tampon des salles d’en-tête en modifiant la longueur du MRU ou de la longueur du câble, et que vous commitz la configuration, le système effectue un contrôle de validation et rejette la configuration si l’espace tampon en réserve n’est pas disponible.

Toutefois, le système n’effectue pas de vérification de validation, mais renvoie plutôt une erreur de syslog si:

• Les tampons sont configurés sur une interface LAG.

• Le classificateur par défaut est utilisé sur l’interface (au lieu d’un classificateur configuré par l’utilisateur).

• L’interface n’a pas encore été créée.

Configuring Output Interface Flow Control (PFC)

Sur les interfaces Ethernet, vous pouvez utiliser la sanza de sortie du CNP pour configurer le contrôle de flux sur les files d’attente de sortie et activer la réponse PFC interrompre la réponse sur les priorités 802.1p IEEE 802.1p.

Remarque:

Sur les commutateurs qui utilisent différentes files d’attente de sortie pour le trafic unicast et multidestré, la file d’attente doit être une file d’attente de sortie unicast.

Par défaut, les files d’attente de sortie 3 et 4 sont activées pour que le PFC interrompe les priorités 3 (IEEE point de code 802.1p 011) et 4 (IEEE code 802.1p code point 100). Le PFC par défaut interrompt la réponse et prend en charge la configuration de la classe de forwarding sans perte par défaut, qui masque la classe de forwarding fcoe vers la file d’attente 3 et la priorité 3, et masque la classe de passation sans perte vers la file d’attente 4 et la priorité 4.

La configuration du PFC sur les files d’attente de sortie vous permet d’interrompre toute priorité sur n’importe quelle file d’attente de sortie sur n’importe quelle interface Ethernet. Le contrôle du flux de sortie vous permet d’utiliser plus de deux files d’attente de sortie pour prendre en charge des flux de trafic sans perte (vous pouvez configurer jusqu’à six classes de forwarding sans perte et les mapper vers différentes files d’attente de sortie activées pour la pause PFC). Le contrôle de flux de la file d’attente de sortie vous permet également de prendre en charge plusieurs classes de flux sans perte (toutes sont machées sur une priorité et une file d’attente de sortie différentes) pour une classe de trafic.

Remarque:

Le contrôle du flux de sortie ne s’active que lorsque le PFC est activé dans le sanza d’entrée CNP sur les priorités correspondantes sur l’interface. Par exemple, si vous activez le contrôle du flux de sortie sur la priorité 5 (IEEE point de code 802.1p 101), vous devez également activer le PFC dans le CNP sur la stanza d’entrée sur la priorité 5.

Par exemple, si le réseau Ethernet convergé utilise deux priorités différentes pour le trafic FCoE (par exemple, priorité 3 et priorité 5), vous pouvez classifier ces priorités en différentes classes de forwarding sans perte qui sont maillées vers différentes files d’attente de sortie:

1. Configurez deux classes de forwarding sans perte pour FCoE, chaque classe de forwarding est machée sur une file d’attente de sortie différente. Par exemple, vous pouvez utiliser la classe de forwarding fcoe par défaut, qui est mappée dans la file d’attente 3, et configurer une deuxième classe de forwarding sans perte appelée fcoe1 et l’mapquer vers la file d’attente 5. La classe de forwarding fcoe est pour le trafic FCoE 3 (point de code 011) et la classe de passation fcoe1 pour la priorité 5 (code point 101) FCoE trafic.

2. Configurez un classificateur qui ma mappe chaque classe de forwarding vers le point de code 802.1p souhaité et IEEE point de code 802.1p (priorité). Si FCoE trafic sur ces deux priorités utilise une seule interface, le classificateur doit classifier les deux classes de passation vers les priorités correctes. Si FCoE trafic de différentes priorités utilise différentes interfaces, la configuration du classificateur sur chaque interface doit correspondre à la classe de priorité sans perte correspondant.

3. Appliquez le classificateur aux interfaces qui transportent FCoE trafic. Le classificateur détermine la mappage des classes de priorité sur chaque interface.

Pour configurer le transport sans perte de ces classes de forwarding, vous devez également:

• Activer le PFC sur les deux priorités (3 et 5 dans cet exemple) sur les interfaces d’entrée dans la sanza d’entrée CNP.

• Configurez le PFC sur les files d’attente de sortie et les priorités pour les classes de forwarding dans la catégorie de sortie CNP afin que l’interface puisse répondre aux messages de pause reçus de l’pair connecté.

  Remarque:

  Lorsque vous configurez le CNP sur une interface, tout le trafic d’entrée et de sortie est bloqué jusqu’à ce que la configuration soit implémentée, alors l’interface est débloqué et le trafic reprend. Pendant le blocage de l’interface, toutes les files d’attente sur l’expérience de perte de paquet de l’interface.

• Configurez la DCBX pour qu’elles échangent des TV de protocoles d’application FCoE priorités spécifiques.

Remarque:

Si vous ne configurez pas le contrôle des flux pour interrompre les files d’attente en sortie, la configuration par défaut utilise une mise en correspondance un à un des points de code IEEE 802.1p (priorités) vers les files d’attente en sortie par numéro. Par exemple, la priorité 0 (point de code 000) est machée sur la file d’attente 0, la priorité 1 (point de code 001) est machée sur la file d’attente 1, etc. Par défaut, seules les files d’attente 3 et 4 sont activées pour répondre aux messages de l’pair connecté et vous devez activer la fonction PFC sur les priorités correspondantes dans la sanza d’entrée CNP afin d’atteindre un comportement sans perte.

Si vous n’utilisez pas la configuration par défaut, vous devez configurer explicitement le contrôle de flux sur chaque file d’attente de sortie que vous souhaitez activer pour la pause PFC. Par exemple, si vous configurez explicitement le contrôle de flux dans la file d’attente de sortie 5, la configuration par défaut n’est plus valide et seule la file d’attente 5 de sortie est activée pour la pause PFC. Les files d’attente de sortie 3 et 4 ne sont plus activées pour la pause PFC. Ainsi, le trafic utilisant ces files d’attente ne répond plus aux messages de pause PFC même si la classe de forwarding correspondante est configurée avec l’attribut de perte sans perte. Pour conserver la configuration de pause dans les files d’attente de sortie 3 et 4 et configurer le contrôle du flux dans la file d’attente 5, vous devez configurer le contrôle des flux sur les files d’attente 3, 4 et 5.

Sur les commutateurs qui utilisent différentes files d’attente de sortie pour le trafic unicast et multidestré, vous ne pouvez pas configurer le contrôle de flux pour interrompre une file d’attente de sortie multidest en sortie. Vous pouvez configurer le contrôle de flux pour interrompre uniquement les files d’attente de sortie unicast. Sur les commutateurs qui utilisent les mêmes files d’attente de sortie pour le trafic unicast et multidestré, seul le trafic unicast reçoit un traitement sans perte.

Output Interface Flow Control Profiles

La configuration de la sanza de sortie CNP crée un profil de contrôle du flux de sortie qui indique aux ports de sortie les files d’attente sur lesquelles l’interface Ethernet doit répondre aux messages de pause PFC. Bien que vous pouvez créer un nombre illimité de CPE contenant uniquement des sanzas en entrée, le nombre de CPE que vous pouvez configurer avec les sanzas de sortie est limité:

• Pour les commutateurs autonomes qui ne font pas partie d’un système QFabric, vous pouvez configurer jusqu’à deux profils de contrôle de flux d’interface de sortie. (Vous pouvez configurer jusqu’à deux CPE avec des sanzas de sortie.)

• Pour les systèmes QFabric, vous pouvez configurer un profil de contrôle de flux d’interface de sortie par équipement de nœud. (Vous pouvez configurer un CNP avec une sanza de sortie par équipement de nœud.)

Il existe un total de quatre profils de contrôle des flux de sortie.

Le système dispose d’un profil de contrôle des flux de sortie par défaut qui s’applique à toutes les interfaces Ethernet lorsque le CNP connecté à l’interface ne présente qu’une sanza d’entrée et n’inclut pas de sanza de sortie. Le profil par défaut répond aux messages de pause PFC reçus dans la file d’attente 3 (pour la priorité 3, pour la classe de forwarding fcoe par défaut) et dans la file d’attente 4 (pour la priorité 4, pour la classe de passation par défaut sans perte), et n’est efficace que si le PFC est configuré sur ces priorités dans la catégorie d’entrée CNP.

En outre, le système possède deux profils de contrôle des flux de sortie internes qu’il applique automatiquement aux ports de structure (FTE) et aux interfaces FC natives (NP_Ports). Si le commutateur ne fait pas partie d’un système QFabric, le profil normalement utilisé pour les ports FTE est disponible pour la configuration de l’utilisateur et fournit un deuxième profil configurable par l’utilisateur. (C’est pourquoi les commutateurs autonomes ont deux profils de contrôle des flux de sortie configurables par l’utilisateur, mais les équipements de nœuds d’un système QFabric n’ont qu’un seul profil de contrôle du flux de sortie configurable par l’utilisateur.)

Étant donné qu’un CNP de sortie peut configurer la réponse de pause PFC sur plusieurs files d’attente de sortie (priorités), un CNP de sortie configurable par l’utilisateur est en général assez flexible pour spécifier la réponse PFC souhaitée sur toutes les interfaces programmées.

Remarque:

Chaque port peut utiliser un profil de contrôle du flux de sortie. Vous ne pouvez pas appliquer plusieurs profils à un seul port.

Les profils de contrôle des flux de sortie peuvent être exprimés au format du tableau. Par exemple, le tableau 3 montre le profil de contrôle de flux de sortie par défaut qui met fin aux priorités 3 et 4 dans les files d’attente 3 et 4 (n’oubliez pas que le PFC doit également être activé sur les points de code 3 et 4 dans la stanza d’entrée CNP pour que le PFC fonctionne):

Le tableau 4 est un exemple de profil de contrôle de flux de sortie configuré par l’utilisateur. À l’aide de l’exemple de la section précédente, la catégorie de sortie CNP configure le contrôle de flux sur la file d’attente de sortie 5, et configure également le contrôle du flux de sortie dans les files d’attente 3 et 4 pour les classes de forwarding fcoe et sans perte. (Si vous configurez un CNP de sortie, vous devez configurer explicitement chaque file d’attente de sortie pour répondre aux messages PFC, car le profil configuré par l’utilisateur remplace le profil par défaut. Si cet exemple n’inclut pas les files d’attente 3 et 4, ces files d’attente ne répondraient plus aux messages PFC reçus.)

N’oubliez pas que vous devez également activer la fonction PFC sur les points de code 3, 4 et 5 dans la sanza d’entrée CNP pour que cette configuration fonctionne. Lorsque vous configurez le CNP sur une interface, tout le trafic d’entrée et de sortie est bloqué jusqu’à ce que la configuration soit implémentée, alors l’interface est débloqué et le trafic reprend. Pendant le blocage de l’interface, toutes les files d’attente sur l’expérience de perte de paquet de l’interface.

Configuring PFC Across Layer 3 Interfaces on QFX5210, QFX5200, QFX5100, EX4600, and QFX10000 Switches

L’activation du PFC sur les flux de trafic est basée sur le point de code IEEE 802.1p (priorité) du champ de point de code de priorité (PCP) de l’en-tête de trames Ethernet (parfois appelé bits CoS). Pour activer une fonction PFC sur le trafic qui traverse les interfaces de couche 3, le trafic doit être classifié par son point de code IEEE 802.1p, et non par son point de code DSCP (ou IPv6 DSCP).

Découvrez la fonctionnalité PFC sur les interfaces de couche 3 pour une présentation conceptuelle de la manière d’activer le PFC sur le trafic sur les interfaces de couche 3. Voir l’exemple: Configurer PFC sur les interfaces de couche 3 par exemple de la manière de configurer le PFC sur le trafic qui traverse les interfaces de couche 3.

Configuration de DCBX (Application Protocol TLV Exchange)

Pour les applications nécessitant un transport sans perte, DCBX échange les TLV de protocole d’application avec l’interface pair connectée. Par défaut, DCBX fait la publicité des FCoE protocoles d’application sur toutes les interfaces activées pour DCBX. Par défaut, la DCBX est activée sur toutes les interfaces. DCBX ne fait la publicité d’aucune autre application par défaut.

Pour chaque application (par exemple, iSCSI) que vous souhaitez configurer pour un transport sans perte, vous devez activer les interfaces responsables du trafic de l’application pour qu’elles échangent les TLV du protocole DCBX avec l’pair connecté. L’échange TLV permet aux interfaces pairs de négocier une configuration compatible pour prendre en charge l’application.

Si vous configurez DCBX pour faire la publicité d’une application, la publicité DCBX par défaut est override, et DCBX ne fait que la publicité des applications configurées. Si vous souhaitez qu’une interface ne publicitaire que l’application FCoE, vous n’avez pas à configurer le protocole DCBX application TLV Exchange ; vous pouvez utiliser la configuration par défaut.

Si vous souhaitez que DCBX promouvoir d’autres applications, vous devez configurer une carte d’application et l’appliquer aux interfaces sur lesquelles vous souhaitez échanger des VTL de protocole pour ces applications. Si vous souhaitez échanger des FCoE de protocole d’application en plus des autres téléviseurs TLV de protocole d’application, vous devez également configurer l’application FCoE dans la carte d’application. Understanding DCBX Application Protocol TLV Exchange décrit le fonctionnement du mappage d’applications.

Remarque:

Le transport sans perte nécessite également l’utilisation du PFC sur la priorité correcte (IEEE point de code 802.1p) sur les interfaces d’entrée à l’aide d’un CNP d’entrée. Si la priorité que vous interrompez au niveau des interfaces d’entrée n’est pas correspondance avec la file d’attente 3 ou la file d’attente 4 (les deux files d’attente de sortie activées pour le contrôle de flux de pause PFC par défaut), vous devez également activer les files d’attente en sortie correspondant aux priorités d’entrée suspendues pour interrompre l’utilisation de la stanza de sortie du CNP.

Fate Sharing entre les classes de trafic

Vous pouvez configurer différents flux de trafic sans perte (ou perte) pour partager le destin qui vous est réservé, c’est-à-dire pour CoS traitement approprié.

Le fate sharing n’est pas souhaitable pour la convergence des I/O. Au lieu d’un contrôle indépendant sur le sort de chaque type de flux, les différents types de flux reçoivent le même traitement. Le fate sharing est particulièrement indésirable pour les flux sans perte. Si un flux sans perte subit une congestion et doit être arrêté, cela affecte les flux qui partagent le même sort avec le flux congestionné même si les autres flux ne sont pas encombrés et peuvent également causer la congestion des ports d’entrée. Si votre réseau exige que toutes les priorités 802.1p soient sans perte, vous pouvez le faire en permettant un partage du destin entre les huit priorités en les propageant entre jusqu’à six classes de distribution sans perte.

Si le nombre de priorités sans perte est inférieur ou égal au nombre de classes de forwarding sans perte configurées, alors vous pouvez éviter le partage du destin en configurant une mise en correspondance un-en-un des classes de passation vers des points de code (priorités) IEEE 802.1p et des files d’attente en sortie. (Chaque classe de forwarding doit être machée sur une autre file d’attente de sortie et classée sur une autre priorité.)

Si vous souhaitez configurer différents flux de trafic pour partager son destin, deux configurations fate sharing sont prise en charge: mappage d’une classe de forwarding à plusieurs points de code IEEE 802.1p (priorité) et mappage de deux classes de forwarding vers la même file d’attente de sortie:

1. Si vous associez une classe de forwarding sans perte à plusieurs priorités, le trafic marqué avec chacune des priorités utilise les mêmes propriétés de CoS associées (les propriétés CoS associées à la classe de forwarding). Par exemple, la configuration d’une classe de passation appelée FC1, sa mise en file d’attente 1 et sa mise en correspondance avec les points de code 101 et 110 à l’aide d’un classificateur nommé catégorisation1 résultats du trafic balisé avec les priorités 101 et 110 partage:

   Dans ce cas, si le trafic est maché pour traiter l’un ou l’autre des problèmes d’encombrement, les deux priorités sont suspendues car elles sont machées sur la même classe de passation et sont donc traitées de la même manière.

2. Si vous mappé plusieurs classes de forwarding sans perte dans la même file d’attente de sortie, le trafic mappé aux classes de forwarding utilise la même file d’attente de sortie. Cela augmente le volume de trafic dans la file d’attente et peut créer une congestion qui affecte tous les flux de trafic qui sont mapés à la file d’attente. Par exemple, la configuration de deux classes de forwarding appelées FC1 et FC2, ma mappage des classes de passation vers la file d’attente 1, et mappage des classes de passation de code 101 et 110 (respectivement) à l’aide d’un classificateur nommé Classification1, entraîne le trafic balisé avec les priorités 101 et 110 partage du destin sur la même file d’attente de sortie:

   Dans ce cas, même si les deux classes de forwarding utilisent différentes priorités IEEE 802.1p, si l’une d’entre elles connaît un encombrement, elle affecte l’autre classe de passation. La raison est que si la file d’attente en sortie est suspendue en raison d’une congestion dans les deux classes de forwarding, tout le trafic qui utilise cette file d’attente est arrêté. Puisque les deux classes de forwarding sont machées dans la file d’attente, le trafic est mis en pause.

   Remarque:

   Si vous mappé plus d’une classe de passation vers une file d’attente, toutes les classes de forwarding mappées vers la même file d’attente doivent avoir le même attribut de perte de paquets (toutes les classes de forwarding doivent être pertes ou toutes les classes de forwarding mappées vers une file d’attente doivent être sans perte).

Configuration des commutateurs de transit vs. FCoE-FC Configuration de la passerelle

Sur un commutateur de transit (tous les ports Ethernet, aucun port FC natif) qui transfert le trafic FCoE (ou tout autre trafic nécessitant un transport sans perte sur le réseau Ethernet), la configuration des classificateurs, des classes de transfert sans perte, DCBX et PFC sur les interfaces d’entrée et de sortie pour prendre en charge le transport sans perte est décrite dans ce document.

Lorsqu’un commutateur agit comme une passerelle FCoE FC (si les interfaces FC natives sont prise en charge sur votre commutateur), le système utilise des interfaces FC natives (NP_Ports) pour se connecter au commutateur FC (ou au transfert FCoE) à la périphérie du réseau FC. Vous ne pouvez pas appliquer les CPE ou DCBX aux interfaces FC natives, uniquement aux interfaces Ethernet.

Sur une passerelle FCoE-FC, la configuration de l’interface Ethernet des classificateurs, DCBX et PFC est la même que la configuration de l’interface Ethernet sur un commutateur de transit. La configuration des classes de forwarding sans perte est également la même.

Toutefois, la prise en charge du transport sans perte sur les interfaces FC natives nécessite de réécriture la valeur de priorité IEEE 802.1p si votre réseau utilise une priorité autre que 3 (point de code IEEE 011) pour le trafic FCoE. Si votre réseau utilise la priorité 3 pour FCoE, vous pouvez et devez utiliser la configuration par défaut sur les interfaces FC natives.

Par défaut, les interfaces FC natives encapsulent les paquets FC entrants dans Ethernet avec la priorité 3. Si votre réseau FCoE utilise une priorité différente de 3 pour le trafic FCoE, vous devez réécrire la valeur de priorité sur la valeur que votre réseau utilise sur l’interface FC, classifier le trafic FCoE sur la priorité correcte sur les interfaces Ethernet et activer la fonction PFC sur la priorité correcte sur les interfaces Ethernet, telles que décrites dans Understanding CoS IEEE 802.1p Priority Remapping on an FCoE-FC Gateway.

Résultats de la configuration et vérifications des validations

Les différentes configurations des classes de forwarding et leurs attributs de baisse, leurs classificateurs, leurs CPE (contrôle de flux PFC) et la pause Ethernet (contrôle de flux IEEE 802.3X) entraînent différents comportements système.

Le tableau 5 décrit dans chaque cas les résultats de configurations de transport possibles sans perte. L’hypothèse que l’on trouve dans la colonne « Résultats » est que le calcul des réserves de tampon du système a permis de réussir la configuration.

Toutefois, si le système calcule l’espace tampon insuffisant pour prendre en charge la configuration, une vérification de validation vous empêche de valider la configuration sur une interface Ethernet individuelle. Pour les interfaces LAG, le système n’envoie pas d’erreur de validation, mais plutôt un message syslog.

Remarque:

Une fois que vous avez configuré le transport sans perte pour une interface LAG, assurez-vous de vérifier les messages syslog pour confirmer que la validation a réussi.

Remarque:

Si vous tentez de configurer à la fois PFC et Ethernet INTERROMPRE sur une liaison, le système renvoie une erreur de validation. Les PFC et Ethernet PAUSE sont des configurations mutuellement exclusives sur une interface.