Recommandations en matière de conception LANE

Introduction

Ce document fournit des directives pratiques pour la conception de réseaux d'émulation de réseau local (LANE). Ces directives vous aideront à concevoir des réseaux LANE hautes performances, évolutifs et haute disponibilité. Bien que ce document se concentre sur les équipements Cisco, les mêmes concepts peuvent être appliqués lors de l'intégration de produits tiers.

Avant de commencer

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Conditions préalables

Les lecteurs de ce document doivent connaître les opérations de base et les configurations des réseaux LANE.

Components Used

Ce document se concentre sur les configurations Ethernet LANE.

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Compréhension des exigences du serveur

Les différents serveurs LANE et leurs besoins sont présentés ci-dessous.

Le serveur LECS (LAN Emulation Configuration Server)

La spécification LAN Emulation Over ATM Version 1.0 exige que chaque client d’émulation LAN (LEC) établisse un circuit virtuel vers le serveur de configuration d’émulation LAN (LECS) lorsqu’il monte. Le LEC demande ensuite l’adresse ATM de son serveur d’émulation de réseau local (LES) correspondant. Une fois que l’ESL a son adresse LES ATM, le circuit virtuel entre l’ESL et le LECS est supprimé et l’ESL ne tente plus de communiquer avec le LECS. Lorsque l'environnement est stable et que tous les LEC sont opérationnels, le LECS est inactif.

Lorsque les LEC rejoignent le LAN émulé (ELAN), ils communiquent chacun avec le LECS individuellement. Cependant, lorsque le réseau LANE subit un sinistre (par exemple, lorsque le LECS principal échoue), tous les clients tombent en panne.

Remarque : l'exception à cette règle est lorsque le protocole FSSRP (Fast Simple Server Redundancy Protocol) est utilisé.

Puisque tous les LEC s’arrêtent en même temps, ils contactent tous le LECS de sauvegarde en même temps. Par conséquent, pour héberger le LECS, vous avez besoin d'un périphérique qui :

• peut gérer une rafale soudaine de trafic dirigée au niveau du processus.

• peut accepter la quasi-totalité des configurations d'appels entrants des LEC simultanément.

• est connu pour sa stabilité. Si le LECS tombe en panne, l’ensemble du réseau tombe en panne (à nouveau, à l’exception du protocole FSSRP). Par conséquent, il n'est pas recommandé de placer le LECS sur un périphérique exécutant une version logicielle expérimentale.

Le serveur d'émulation LAN (LES)

Chaque ESL maintiendra un circuit virtuel bidirectionnel vers les ERP de l’ELAN (il peut s’agir de plusieurs réseaux locaux virtuels si le protocole FSSRP est utilisé). Dans un environnement généralement très chargé, de nombreuses requêtes LE_ARP (LAN Emulation Address Resolution Protocol) sont envoyées aux ERP. La mise en oeuvre des ERP sur les périphériques Cisco est assez simple. Toutes les trames LE_ARP entrantes seront transmises au contrôle VCC (Distributed Channel Connection).

Vous ne pouvez pas implémenter une simple réplication de cellule matérielle à partir d'un contrôle direct pour contrôler la distribution, car certaines trames (telles que les demandes de jointure) doivent être analysées par le processus ERP. Par conséquent, un périphérique qui peut agir comme un bon ERP est un périphérique qui :

• dispose d'un processeur puissant et peut accepter de nombreuses configurations d'appels en peu de temps. Cela est nécessaire lorsque de nombreux clients rejoignent l’ELAN en même temps, mais moins vital que pour le LECS, car seuls les LEC de l’ELAN doivent y adhérer.

• prend en charge le matériel SAR (segmentation and reassembly). Comme toutes les cellules entrantes doivent être réassemblées en trames, si beaucoup de requêtes de jointure arrivent en même temps, elles devront être réassemblées très rapidement.

N'oubliez pas que dans la mise en oeuvre de Cisco, les processus ERP et Broadcast and Unknown Server (BUS) sont combinés (c'est-à-dire que vous ne pouvez pas mettre les ERP pour ELAN-1 sur un périphérique et le BUS pour ELAN-1 sur un autre).

Une autre chose à garder à l'esprit est un comportement préventif possible. Si la préemption est activée, les ERP/BUS ayant la priorité la plus élevée (selon la base de données LANE) prendront toujours en charge le service ERP/BUS principal. En d'autres termes, si le serveur LE/BUS principal échoue, tous les LEC de l'ELAN descendent et se reconnectent au serveur LE/BUS de sauvegarde. Si la préemptivité est configurée, si l'ERP/BUS principal redémarre, toutes les ESL vont redescendre et se reconnecter aux ERP/BUS avec la priorité la plus élevée. Dans les versions 3.2.8 et ultérieures du logiciel LANE Module, ainsi que dans les versions 11.3(4) et ultérieures du logiciel Cisco IOS®, la fonctionnalité de préemptivité peut être activée et désactivée. La fonctionnalité de préemptivité peut être configurée comme décrit dans la documentation Configuration de l'émulation de réseau local.

Serveur de diffusion et serveur inconnu

Le travail du BUS est très semblable à celui des ERP. Chaque LEC doit avoir un envoi multicast au BUS. Le LEC lui envoie tout son trafic de multidiffusion, de diffusion ou inconnu. Le BUS dispose d'un VCC point à multipoint vers tous les LEC de l'ELAN. Les trames ne doivent pas être examinées en détail par le BUS. En d'autres termes, chaque trame entrante sur l'envoi de multidiffusion peut être transmise aveuglément à la multidiffusion directe.

Un bon périphérique BUS :

• prend en charge le matériel pour la copie de trame de la multidiffusion entrante envoyée à la multidiffusion sortante. Si vous disposez d'un matériel « intelligent », cette opération de copie peut être effectuée avant le réassemblage. Cela signifie que les cellules entrantes sur l'envoi multicast sont transférées sur le transfert multicast. Cela permet d'enregistrer une segmentation et un réassemblage par trame.

• nécessite un processeur puissant s'il n'y a pas de prise en charge matérielle pour le BUS.

• doit être capable de traiter un grand nombre de configurations d'appels en même temps, mais avec une limite inférieure à la LECS.

Tableau 1 : Performances BUS par périphérique

Périphérique	Débit BUS (Kpps)
Module Catalyst 6K LANE/MPOA (OC-12)	600
Module Catalyst 5K LANE/MPOA (OC-12)	600
Module Catalyst 5K LANE/MPOA (OC-3)	166
Module Catalyst 5K LANE (OC-3)	122
RSP4 - VIP-2-50+PA-A1	92
RSP4 - VIP-2-500+PA-A3	84
RSP4 - VIP-2-40+PA-A3	78
RSP4 - VIP-2-40+PA-A1	77
4700	40
LS1010	30

Comprendre les fonctionnalités des périphériques Cisco

Cette section présente les fonctionnalités des périphériques Cisco les plus courants utilisés pour exécuter LEC, LECS, LES et BUS. Ces périphériques sont les modules Cisco LANE, le Lightstream 1010, les Catalyst 8510MSR et 8540MSR et le 7500/RSP. Leurs capacités sont comparées aux exigences énumérées ci-dessus.

Modules LANE

L'architecture de tous les modules LANE des Catalyst 5000 et 6000 repose en gros sur la vue de haut niveau suivante :

La segmentation et le réassemblage sont effectués par le matériel. La puce SAR est quelque peu intelligente et peut transférer directement les trames réassemblées vers le bus de trames du catalyseur (le fond de panier du catalyseur). Pour les trames de contrôle, la puce SAR peut transférer les trames au processeur du module LANE. Une trame de contrôle est toute trame qui doit être analysée (par exemple, ILMI (Interface de gestion locale intermédiaire), signalisation et trames destinées aux ERP), qui arrive au module LANE via un circuit virtuel spécifié.

La puce SAR peut également rediriger les cellules qui arrivent sur la multidiffusion et qui sont envoyées à la multidiffusion vers l'avant (c'est-à-dire, la multidiffusion, la diffusion et les cellules inconnues provenant des LEC). Les cellules ne sont pas réassemblées en trames. Sa facilité de mise en oeuvre donne de très bonnes performances en BUS.

Une fois qu'un fichier « data direct » et une entrée dans la table CAM (Content-Addressable Memory) ont été créés, les trames réassemblées sont envoyées directement à la trame BUS et marquées avec l'ID de réseau local virtuel (VLAN) correct. Un module LANE fait un très bon LEC parce qu'une fois que le « data direct » a été établi, le CPU n'est plus impliqué.

LightStream 1010 et Catalyst 8510MSR

Les modèles LS1010 et Catalyst 8510MSR ne prennent pas en charge le matériel SAR. Par conséquent, ces périphériques sont de mauvais choix pour la mise en oeuvre des fonctionnalités ERP/BUS. Ils conviennent toutefois au SELECT (voir exemple de conception 2 ci-dessous).

8540 MSR

Le modèle 8540MSR prend en charge le matériel SAR. Il possède également un puissant processeur Risc 5000. Il n'est pas recommandé de prendre en charge les ERP/BUS pour deux raisons :

• Les performances du BUS sont d'environ 50 Kpps pour les paquets de 64 octets, bien en dessous de tout module LANE. Ceci est dû au fait qu'il n'y a pas d'accélération matérielle pour le BUS.

• Si le 8540MSR est utilisé avec des cartes ATM et Ethernet, le processeur peut être utilisé principalement pour parler avec des cartes de ligne Ethernet. Dans ce cas, le processeur du 8540MSR ne doit pas être utilisé comme ERP.

Plates-formes de routeur

Le routeur le plus couramment utilisé pour le routage inter-ELAN est la plate-forme Cisco 7500 (le module de commutation de route (RSM) et le Cisco 7200 sont également largement utilisés). La carte de port contient la puce matérielle SAR. Les processeurs de routage/commutation (RSP) tels que le RSP4 disposent d'une puissance processeur suffisante pour traiter très rapidement les trames entrantes ; ils sont donc un bon choix pour les ERP. Les performances des bus sont toutefois inférieures à celles des modules LANE.

Exemples de conceptions

L’émulation LAN est principalement utilisée dans les grands réseaux critiques. La redondance est donc obligatoire. Le protocole SSRP (Simple Server Redundancy Protocol) est le protocole de redondance le plus utilisé. Si le logiciel est récent, le protocole FSSRP est le protocole préféré (voir la Ligne directrice 11).

Supposons que nous ayons un réseau assez grand, par exemple 100 VLAN/ELAN et 100 catalyseurs, chacun avec un module LANE double liaison ascendante. Cela signifie que sur chaque module LANE, il se peut que nous ayons besoin d'une LEC par ELAN, dans ce cas 10 000 LEC. En outre, nous supposons que le protocole IP est utilisé et que la conception inclut une classe C sécurisée (254 adresses d'hôte IP, 254 adresses MAC) par VLAN.

Conception 1 : Simple, mais à éviter...

Dans cette conception, un module LANE a été choisi pour exécuter les 100 serveurs LES/BUS. Parallèlement, le LECS principal se trouve sur le même module LANE. Ceci est illustré dans le dessin ci-dessous :

Lors de la création des LEC sur le module LANE, tous les LEC s'activent dès qu'ils sont configurés. Au cours de l'opération, le processus ERP peut être surchargé et le module LANE manque de mémoire. La conception 2 ci-dessous résout ces deux problèmes.

Le problème principal de ce réseau est lorsqu’un problème majeur se produit. Supposez que le module LANE hébergeant le LECS, le LES ou le BUS devient inaccessible. Cela peut se produire, par exemple, si le module LANE du catalyseur 1 devient défectueux. La redondance se produit, mais le temps de redondance (c'est-à-dire le temps entre la défaillance principale LECS, LES ou BUS et le dernier LEC qui redevient opérationnel) peut durer jusqu'à deux heures ! Une bonne conception peut ramener ce nombre à quelques dizaines de secondes, ou à quelques minutes dans les grands réseaux.

Le problème réside dans la signalisation associée aux LEC qui rejoignent l’ELAN. Si chaque ESL doit contacter le LECS, il recevra 10 000 configurations d'appel (100 modules LANE avec 100 ESL chacun) presque simultanément. Le module LANE est conçu pour assurer un pont efficace entre le bus de trames et la liaison de cellule, mais pas pour gérer un grand nombre de configurations d'appels par seconde. Le processeur du module LANE n'est pas assez puissant pour gérer ce volume de configuration d'appels. Le résultat suivant illustre le temps de redondance dans un réseau LANE avec environ 1 600 LEC (seule une partie de la commande show processes cpu est affichée) :

ATM#show processes cpu

CPU utilization for five seconds: 99%/0%; one minute: 98%; five minutes: 69%

 PID  Runtime(ms)  Invoked   uSecs     5Sec     1Min    5Min   TTY      Process

<snip>
 7       13396       207   64714   16.55%   10.85%   3.77%     0      ATM ILMI Input 
 8       13600       188   72340   13.45%   10.54%   3.72%     0      ILMI Process 

<snip>
35      107892       553  195103   68.94%   55.34%  26.72%     0      ATMSIG Input 
36       34408      1125   30584   12.29%    9.45%   6.63%     0      ATMSIG Output 

<snip>

Comme vous pouvez le voir, le module LANE est surutilisé en raison de l’activité de signalisation entrante. Qu'est-ce qui explique le temps de redondance de deux heures ? La réponse réside dans la notion de délai d'attente. Les spécifications de signalisation indiquent clairement que si le périphérique ne reçoit pas de message de connexion après un délai spécifié lors de l'envoi d'une configuration d'appel, il doit recommencer. Les spécifications LANE exigent que le LEC revienne à son état initial et recommence à zéro. Cela signifie que si un LEC est en mesure de contacter le LECS et d'y être connecté, son paramétrage d'appel aux ERP pourrait expirer et revenir à son état initial d'essayer de contacter le LECS ! Cela peut également se produire avec les connexions depuis les ERP et depuis/vers le BUS.

Sur la base des explications ci-dessus, voici quelques recommandations de conception de base :

• Essayez de répartir les ERP/BUS pour les différents ELAN sur les différents périphériques qui peuvent les mettre en oeuvre efficacement. Idéalement, un ERP/BUS principal sur chaque module LANE, les suivants sauvegardant le premier. Dans la pratique, cela créerait une très longue base de données LECS. L'expérience montre que 10 serveurs LES/BUS par module LANE semblent être un nombre sûr.

• Essayez de ne pas placer le LECS au même emplacement que les autres serveurs LES/BUS importants. Essayez également de placer le LECS sur un périphérique doté d'une puissance CPU suffisante pour qu'il puisse gérer efficacement les informations de signalisation. Le LECS doit se trouver sur un routeur (le Cisco 7200 ou 7500 est recommandé, idéalement sans LE/BUS) ou sur un commutateur ATM.

• En supposant qu'une plage IP et une plage de classe C soient utilisées pour chaque VLAN, environ 250 adresses MAC constituent un bon nombre pour le service ERP. Pour 10 LE sur un module LANE, cela signifie le CPU d'un module LANE pour un maximum de 2 500 adresses MAC. N'oubliez pas qu'il n'y a pas de chiffres fixes et officiels, mais il s'agit d'une estimation prudente et prudente. Par contre, 200 ERP/BUS sur un module LANE, avec chaque ELAN contenant 1000 stations d'extrémité, sont sûrs tant que la station reste pratiquement inactive (voir la Ligne directrice 3 pour plus de détails).

Conception 2 : Plus complexe, mais plus sûr et plus efficace...

Dans cette conception, nous avons placé le LECS sur le commutateur ATM. Nous répartissons les LE/BUS sur différents modules LANE. Les valeurs de CPU à processus élevé ne sont visibles sur aucun module LANE et la redondance est normale.

Directives

Les lignes directrices présentées ci-dessous ne sont que des recommandations pratiques, fondées sur le déploiement de réseaux LANE de production. Bien qu'il existe des exemples de réseaux réussis dépassant les recommandations, il est nécessaire de bien comprendre comment ils affecteront le réseau avant de dépasser ces directives.

Ligne directrice 1

Si vous prévoyez d'utiliser le protocole HSRP (Hot Standby Router Protocol) sur LANE, assurez-vous que vous effectuez une mise à niveau vers une version récente et que vous avez lu Implémentation de HSRP sur LANE.

Ligne directrice 2

Distribuez le BUS LANE sur les périphériques ayant la capacité de débit BUS la plus élevée et où il aura un impact minimal sur les autres processus du périphérique.

Le BUS LANE est responsable du transfert de toutes les trames de diffusion, de multidiffusion et de monodiffusion de destination inconnue reçues des membres d’un ELAN à tous les membres de l’ELAN. Puisque LANE utilise la couche d’adaptation ATM 5 (AAL5) qui ne permet pas l’entrelacement de cellules de différentes unités de données de protocole (PDU), le BUS doit sérialiser les trames avant de les transmettre. Pour cela, le BUS doit réassembler les trames reçues, segmenter chaque trame une par une et transférer les cellules. La nécessité de réassembler et de segmenter chaque trame limite considérablement le débit de transfert du BUS, ce qui influence considérablement l’évolutivité d’un ELAN. La prolifération des applications de multidiffusion IP intensifie encore cette tâche. Rappelez-vous que seuls les modules LANE peuvent recevoir les cellules sur la multidiffusion les envoyer et les transmettre sur la multidiffusion. Cela se fait sans réassemblage.

Ligne directrice 3

Distribuer les services LANE sur plusieurs modules et périphériques.

Nous avons indiqué plus haut que 10 ERP/BUS avec chaque ELAN correspondant à un réseau IP de classe C (environ 250 utilisateurs) sont sûrs et prudents ; cependant, il existe des réseaux LANE réussis avec 10 à 60 paires LES/BUS par module. Cela dépend légèrement du module, mais vérifier la conception impliquera toujours de vérifier l'utilisation du CPU (en utilisant la commande show processes cpu), et la mémoire disponible la plus basse (en utilisant la commande show memory). Cela devrait bien sûr être effectué lors de l'utilisation maximale du réseau, car l'utilisation globale du CPU des ERP est directement liée au processus LE_ARP.

Dans un environnement LANE, il est courant de voir les paires LES/BUS situées sur un seul périphérique prenant en charge l’ensemble du réseau LANE. Non seulement cela représente un point de défaillance unique, mais cela limite les performances du BUS dans chaque ELAN.

La distribution des services LANE sur plusieurs plates-formes offre une plus grande évolutivité dans les environnements multi-ELAN, ainsi qu'une disponibilité système supérieure et des performances BUS agrégées accrues (par exemple, les performances BUS agrégées du réseau augmentent à mesure que davantage de périphériques et d'interfaces sont configurés pour la prise en charge BUS). Pour une capacité BUS maximale du point de vue de la conception, les modules ATM Catalyst 5000 et 6000 peuvent être dédiés aux services ERP et BUS.

En connaissant la capacité du BUS et en estimant la quantité de trafic de diffusion ou de multidiffusion attendue dans chaque ELAN, vous pouvez calculer le nombre de paires ERP/BUS pouvant être appliquées à une interface donnée. Vous pouvez également mesurer la capacité du BUS.

Il est toutefois plus difficile d’estimer la quantité de trafic de diffusion ou de multidiffusion pour chaque ELAN. Une méthode pour estimer la quantité de trafic de diffusion ou de multidiffusion pour chaque réseau local Ethernet consiste à mesurer ce trafic sur le réseau existant. Un analyseur de réseau ou un périphérique de sonde RMON (Remote Monitoring) peut être inséré dans le réseau local existant pour mesurer la quantité de trafic de diffusion et de multidiffusion. Une autre méthode consiste à interroger les objets mib « ifOutMulticastPkts » et « ifOutBroadcastPkts ». Vérifiez d'abord s'ils sont pris en charge sur votre plate-forme IOS.

Vous pouvez également, dans une certaine mesure, calculer la quantité de trafic de diffusion ou de multidiffusion en calculant la bande passante consommée par les diffusions de protocole de routage, par exemple. Pour les protocoles IPX (Internetwork Packet Exchange), RIP (Routing Information Protocol) et SAP (Service Advertising Protocol), la consommation de bande passante peut être déterminée avec précision si le nombre de routes IPX et de SAP est connu. Il en va de même pour IP et pour le protocole de routage particulier utilisé.

La capacité de BUS supplémentaire doit être réservée pour :

• Prise en charge du trafic de monodiffusion lors de l’établissement d’un circuit virtuel direct de données et jusqu’à ce qu’un paquet de vidage soit reconnu sur le LEC récepteur.

• Applications de multidiffusion IP à la demande qui sont utilisées à différentes heures du jour (elles doivent être prises en compte dans le volume de multidiffusion global).

• Trafic de routage supplémentaire lorsqu’un protocole est en cours d’exécution et dans un état de convergence (c’est-à-dire, les LSA échangées lors d’une modification de topologie OSPF (Open Shortest Path First)).

• Volume élevé de requêtes ARP (Address Resolution Protocol), en particulier le matin où les stations de travail se connectent pour la première fois aux serveurs LAN et réseau.

Quelle que soit la méthode disponible, l'objectif est d'avoir une représentation précise de la quantité de trafic de diffusion et de multidiffusion qui existera sur chaque ELAN. Malheureusement, ces informations sont rarement disponibles pour le concepteur du réseau pour diverses raisons. Face à cette situation, il est possible d'utiliser certaines lignes directrices générales conservatrices. En guise de recommandation, un réseau type de 250 utilisateurs par réseau local Ethernet, exécutant les applications les plus courantes, doit recevoir au moins 10 Kpps de capacité BUS. Le tableau 1 illustre le nombre maximal recommandé de paires ERP/BUS par interface.

Ces numéros doivent être utilisés conjointement avec la Ligne directrice 4, qui limite à 250 le nombre d’ESL desservies par toutes les paires ERP/BUS configurées sur une interface. En outre, ces numéros doivent être ajustés en fonction du nombre réel d’utilisateurs dans chaque ELAN, tout en accordant une attention particulière à toute application de diffusion ou de multidiffusion qui sera exécutée sur l’ELAN.

Ligne directrice 4

Limitez le nombre total de LEC desservis par la paire LES/BUS à un maximum de 250. Au cours de l'initialisation, et après une défaillance du réseau, pour que les clients LANE rejoignent leur ELAN, ils doivent établir plusieurs connexions et envoyer des requêtes à leurs composants de service LANE. Étant donné que les périphériques prenant en charge les services LANE disposent d’un débit fini auquel ils peuvent traiter les connexions et les requêtes, il est recommandé que les paires ERP/BUS configurées sur un service d’interface aient un maximum de 250 clients LANE. Par exemple, une interface peut être configurée avec 10 paires LES/BUS, chacune assurant la maintenance de 25 ESL pour un total de 250 ESL traitées par l'interface. Cela garantit l'initialisation en temps opportun et la reprise après échec.

Ligne directrice no 5

Placez les LE/BUS pour un ELAN donné à proximité de toute source de trafic de diffusion ou de multidiffusion majeure.

Dans un environnement LANE, particulièrement lorsque des applications de multidiffusion sont utilisées (c'est-à-dire IP/TV), il est recommandé de placer le BUS le plus près possible de la source de multidiffusion connue. Puisque le trafic de multidiffusion doit d’abord être envoyé au BUS, qui transfère le trafic à tous les clients, placer le BUS à proximité de la source de multidiffusion évite au trafic de traverser deux fois le backbone ATM.

Cela permet au réseau LANE de s’étendre à une plus grande échelle. En outre, le BUS ne doit pas être situé sur la même interface que le LEC prenant en charge la source de multidiffusion, car le trafic de multidiffusion traverserait deux fois la liaison de transmission.

Soyez prudent si vous considérez LANE comme la technologie de réseau pour prendre en charge un environnement de multidiffusion. Bien que le LANE prenne en charge le trafic de multidiffusion, il le fait de manière plutôt inefficace. LANE diffuse simplement le trafic de multidiffusion à tous les clients de l'ELAN, qu'ils fassent ou non partie du groupe de multidiffusion. L'excès de trafic de multidiffusion peut considérablement dégrader les performances des stations de travail (comme indiqué dans la ligne directrice 6), tandis que le comportement d'inondation gaspille la bande passante du réseau fédérateur.

Ligne directrice no 6

Limitez le nombre de systèmes d’extrémité dans un ELAN donné à 500 ou moins si le réseau ne transporte que des paquets IP. Le tableau 2 ci-dessous donne quelques recommandations de base basées sur la quantité de diffusion générée par le protocole. Encore une fois, si vous n'êtes pas sûr des protocoles nécessaires, gardez à l'esprit la recommandation de 250 stations d'extrémité que nous avons faite dans le passé.

Par définition, un ELAN représente un domaine de diffusion. Par conséquent, au sein d’un réseau ELAN, tous les paquets de diffusion et de multidiffusion sont diffusés à tous les membres de ce réseau. Les stations de travail doivent traiter chaque paquet de diffusion et de multidiffusion reçu pour déterminer s’il présente un intérêt. Le traitement de paquets de diffusion « inintéressants » gaspille les cycles de CPU des stations de travail. Lorsque le niveau d’activité de diffusion devient élevé (par rapport à la capacité de traitement des stations de travail), il peut être gravement affecté et empêché d’effectuer les tâches prévues.

Le nombre de systèmes d’extrémité, d’applications et de protocoles utilisés détermine le niveau de diffusion au sein d’un ELAN. Les tests ont montré qu'en l'absence d'applications intensives en diffusion, le nombre de systèmes finaux pouvant être configurés en toute sécurité dans un seul ELAN varie de 200 à 500 en fonction de la combinaison de protocoles.

Tableau 2 : Nombre maximal de systèmes finaux recommandés par réseau local virtuel basé sur la combinaison de protocoles

Type de protocole	Nombre de systèmes finaux
IP	500
IPX	300
AppleTalk	200
Mixte	200

Ligne directrice no 7

Calculez l’utilisation du circuit virtuel réseau pour vous assurer qu’il est dans la capacité des périphériques ATM.

Utilisation de circuits virtuels

Les commutateurs ATM et les périphériques de périphérie prennent en charge un nombre limité de circuits virtuels. Lors de la conception de réseaux ATM, il est important de s’assurer que la capacité VC de l’équipement n’est pas dépassée. Ceci est particulièrement important dans les réseaux LANE, car LANE n’est pas reconnu pour son efficacité de circuit virtuel. Au cours de la phase de conception du réseau, vous devez calculer l'utilisation prévue du circuit virtuel pour le backbone, ainsi que pour chaque périphérique périphérique périphérique. L’utilisation du circuit virtuel du backbone correspond au nombre total de circuits virtuels attendus sur le réseau. Cette quantité doit être comparée au nombre de circuits virtuels pris en charge par les commutateurs ATM.

Comme tous les circuits virtuels ne traversent pas un commutateur donné, ce nombre sert de limite supérieure. La topologie réelle des modèles de réseau fédérateur et de trafic doit être prise en compte, par rapport au nombre total de circuits virtuels, pour déterminer si la capacité VC des commutateurs ATM sera dépassée.

De même, l'utilisation du circuit virtuel pour chaque périphérique de périphérie doit être calculée. Il s'agit du nombre de circuits virtuels qui se termineront sur une interface donnée d'un périphérique de périphérie. Ce nombre doit ensuite être comparé à la capacité VC de l’interface.

Les formules suivantes peuvent être utilisées pour calculer l'utilisation du circuit virtuel du réseau. Ces formules supposent l'utilisation des services et des clients Cisco LANE et s'appliquent aux protocoles SSRP et FSSRP. Lorsqu’elles sont présentes, les différences d’utilisation du circuit virtuel entre les deux protocoles sont indiquées.

Utilisation du circuit virtuel principal

a. LEC-LANE Service VCs:

       SSRP: 4 (#LEC_per_ELAN)(#ELAN)
       FSSRP: 4 (#LEC_per_ELAN)(#LES/BUS_per_ELAN)(#ELAN) 

b. LECS-LES Control VCs:

       (#LES/BUS_per_ELAN)(#ELAN)

c. LECS-LECS Control VCs:

       (#LECS)(#LECS - 1) / 2 

d. LEC-LEC Data Direct VCs:

       If mesh_factor < 1.0:

         (#LEC_per_ELAN) [(#LEC_per_ELAN)(mesh_factor)/2](#ELAN)

       If mesh_factor = 1.0: (recommended in most designs) 

         (#LEC_per_ELAN) [((#LEC_per_ELAN) - 1)/2](#ELAN) 

       where: 

       mesh_factor = fraction of LECs within an ELAN communicating a given time. (When determining the fraction of 
       LECs within an ELAN communicating at a given time, the data direct timeout period must be considered. 
       Even a brief conversation between two LECs will cause a data direct connection to be maintained for the 
       timeout period. Therefore, unless the traffic patterns are very clearly understood, a mesh_factor = 1.0
       is highly recommended).

       Backbone VC Usage = a + b + c + d

Utilisation du circuit virtuel de l'interface du périphérique Edge

a. LEC-LANE Service VCs: 

       SSRP: (#active_LES/BUS_on_interface) (2 * #LEC_per_ELAN + 2) 
       FSSRP: (#LES/BUS_on_interface) (2 * #LEC_per_ELAN + 2)

b. LECS-LES Control VC's:

       (#LES/BUS_on_interface)

c. LECS-LECS Control VCs 

       (#LECS - 1)

d. LEC-LEC Data Direct VCs:

       (#LEC)[(#LEC_per_ELAN)(#LEC_per_ELAN)(mesh_factor)/2] 

       Interface VC usage = a + b + c + d

Une fois que vous avez calculé l'utilisation du circuit virtuel, comparez les résultats à la capacité du circuit virtuel des périphériques concernés à l'aide du tableau 3.

Tableau 3 : Routage inter-ELAN - Capacité VC pour divers périphériques Cisco

Périphérique	Budget des circuits virtuels
Catalyst 8540 MSR	256 000
Catalyst 8510 MSR/LS1010	16 Mo de mémoire DRAM = 4 000
	DRAM : 32 Mo = 16 000
	64 Mo de DRAM = 32 000
Cisco 7500/7200 ATM Deluxe	4 Ko
Cisco 7500/7200 ATM Lite	2 000
Catalyst 6K - LANE/MPOA OC-12	4 Ko
Catalyst 5K - LANE/MPOA OC-12	4 Ko
Catalyst 5K - LANE/MPOA OC-3	4 Ko
Catalyst 5K - LANE OC-3	4 Ko
Catalyst 2900 XL - LANE OC-3	1 000

Ligne directrice 8

Si vous voulez relier différents réseaux ATM de campus à des chemins virtuels permanents (PVP), toujours « router » entre les sites plutôt que de permettre aux réseaux ELAN natifs de s'étendre sur différents réseaux ATM de campus.

Ligne directrice no 9

Évaluer la capacité du routeur en estimant la quantité de routage inter-ELAN requise.

La capacité de routage requise dans un réseau LANE donné varie considérablement. Par conséquent, la capacité de routage doit être estimée au cours du processus de conception du réseau. Après avoir déterminé la capacité requise, le nombre de routeurs et d’interfaces de routeur nécessaires peut être déterminé à l’aide de la table de débit de transfert suivante :

Tableau 4 : Capacité de routage inter-ELAN pour différents périphériques Cisco

Périphérique	Transfert express Cisco (CEF) distribué (Kpps)	Transfert CEF (Cisco Express Forwarding) (Kpps)
PA-A3 ATM RSP4/VIP2-50	118	101
PA-A1 ATM RSP4/VIP2-50	91	91
PA-A3 ATM RSP4/VIP2-40	83	60
PA-A1 ATM RSP4/VIP2-40	66	66

Bien que la configuration de routeur à bras unique soit populaire dans les conceptions de LANE, elle ne fournit généralement pas une capacité de routage adéquate. Au lieu de cela, plusieurs interfaces et/ou plusieurs routeurs sont nécessaires. Les débits de transfert CEF répertoriés dans le tableau ci-dessus supposent une configuration de routeur à bras unique. Pour atteindre ces débits, le processeur central du routeur est poussé à une utilisation de presque 100 %. En revanche, les débits de transfert distribués sont obtenus à l'aide du processeur résidant sur le processeur VIP (Versatile Interface Processor), sans impact sur le processeur du routeur centralisé. Par conséquent, plusieurs interfaces ATM peuvent être installées sur le routeur, ce qui augmente considérablement le débit agrégé.

Ligne directrice 10

Fournir des périphériques de périphérie ATM à double domicile à au moins deux commutateurs ATM différents pour assurer la redondance.

Dans un réseau LANE, le commutateur ATM prenant en charge les périphériques de périphérie peut constituer un point de défaillance unique pour la connectivité au réseau fédérateur. Les Catalyst 6K et 5K fournissent des modules de liaison ascendante à double couche physique (PHY) OC-12/OC-3 pour une connectivité redondante aux commutateurs ATM en aval. Les modules LANE à double résidence fournissent une fonction double interface de données distribuées par fibre optique (FDDI). Ce module de liaison ascendante à double interface physique fournit une interface ATM principale et secondaire. Si l’interface principale perd la connectivité de liaison avec le commutateur ATM, le module bascule automatiquement la connexion vers l’interface secondaire.

Il est vivement recommandé au concepteur de réseau de tirer parti des interfaces double interface PHY sur les modules LANE et de fournir des liaisons ascendantes à double connexion à deux commutateurs ATM différents dans le coeur de réseau. Cela protégera les périphériques de périphérie de la défaillance d’un commutateur ATM unique.

Ligne directrice 11

Utilisez le protocole FSSRP, sauf si le budget du circuit virtuel comporte des contraintes.

Étant donné que les différents composants de service LANE sont des points de défaillance uniques dans un réseau LANE, les réseaux de production doivent être conçus avec redondance. Cisco prend en charge deux schémas de redondance pour les services LANE : SSRP (Simple Server Redundancy Protocol) et FSSRP (Fast SSRP).

Le protocole FSSRP est le système de redondance recommandé dans la plupart des cas. Il assure un basculement quasi immédiat sans perte de données, même sur les grands réseaux. Par contre, le protocole SSRP entraîne des pertes lors d'un basculement et les temps de récupération peuvent être importants (parfois minutes) sur les grands réseaux.

Il existe une situation dans laquelle le protocole SSRP est recommandé par rapport au protocole FSSRP : lorsque le réseau est limité en VC. Contrairement à SSRP, les LEC FSSRP gèrent les connexions de sauvegarde aux paires LES/BUS redondantes. Il est possible de configurer jusqu'à trois paires LES/BUS de sauvegarde, contre un total de quatre par réseau local virtuel. L’augmentation de l’utilisation du circuit virtuel que connaîtra le réseau dans le cadre du protocole FSSRP peut être calculée à l’aide de la formule suivante :

4 (#LEC_per_ELAN) (#LES/BUS_per_ELAN - 1) (#ELAN) 

Par conséquent, si le réseau atteint sa capacité VC, le protocole SSRP est recommandé sur le protocole FSSRP. Si vous utilisez le protocole FSSRP, vous devez réduire le nombre de composants LES/BUS redondants. Dans la plupart des cas, un total de deux paires ERP/BUS par ELAN offre un équilibre acceptable entre l’utilisation du circuit virtuel et l’élimination des points de défaillance uniques.

Informations connexes

• Implémentation de HSRP sur LANE
• Prise en charge ATM - émulation LAN (LANE)
• Informations générales sur ATM
• Support et documentation techniques - Cisco Systems