Empfehlungen für das LANE-Design

Einführung

Dieses Dokument enthält praktische LAN-Emulation (LANE)-Richtlinien für das Netzwerkdesign. Diese Richtlinien unterstützen Sie beim Design von leistungsstarken, skalierbaren und hochverfügbaren LANE-Netzwerken. Dieses Dokument konzentriert sich zwar auf Geräte von Cisco, doch können bei der Integration von Drittanbieterprodukten dieselben Konzepte angewendet werden.

Bevor Sie beginnen

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

Voraussetzungen

Die Leser dieses Dokuments sollten über die grundlegenden Vorgänge und Konfigurationen der LANE-Netzwerke Bescheid wissen.

Verwendete Komponenten

Im Mittelpunkt dieses Dokuments stehen Ethernet-LAN-Konfigurationen.

Die in diesem Dokument enthaltenen Informationen wurden aus Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Sie in einem Live-Netzwerk arbeiten, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen, bevor Sie es verwenden.

Verständnis der Serveranforderungen

Die verschiedenen LANE-Server und deren Anforderungen sind nachfolgend dargestellt.

Der LAN Emulation Configuration Server (LECS)

Die Spezifikation LAN Emulation Over ATM Version 1.0 erfordert, dass jeder LAN Emulation Client (LEC) beim Hochfahren einen Virtual Circuit (VC) zum LAN Emulation Configuration Server (LECS) aufbaut. Der LEC fordert dann die ATM-Adresse des zugehörigen LAN Emulation Server (LES) an. Sobald der LEC seine ATM LES-Adresse hat, wird der VC zwischen dem LEC und dem LECS entfernt, und der LEC versucht nicht mehr, mit dem LECS zu kommunizieren. Wenn die Umgebung stabil ist und alle LECs betriebsbereit sind, ist das LECS inaktiv.

Wenn die LECs dem emulierten LAN (ELAN) beitreten, kontaktieren sie jeweils das LECS einzeln. Wenn das LANE-Netzwerk jedoch einem Notfall ausgesetzt ist (z. B. wenn das primäre LECS ausfällt), fallen alle Clients aus.

Hinweis: Eine Ausnahme bildet hierbei das Fast Simple Server Redundancy Protocol (FSSRP).

Da alle LECs gleichzeitig ausfallen, kontaktieren sie alle gleichzeitig das Backup-LECS. Daher benötigen Sie für das Hosting des LECS ein Gerät, das:

• kann plötzliche Datenverkehrsspitzen auf Prozessebene bewältigen.

• kann fast alle von den LECs eingehenden Anrufe gleichzeitig annehmen.

• ist für seine Stabilität bekannt. Wenn das LECS ausfällt, fällt das gesamte Netzwerk aus (mit Ausnahme von FSSRP). Daher wird nicht empfohlen, das LECS auf einem Gerät zu installieren, auf dem eine experimentelle Softwareversion ausgeführt wird.

Der LAN-Emulationsserver (LES)

Jeder LEC unterhält einen bidirektionalen VC zu den LES des ELAN (bei Verwendung von FSSRP kann es sich um mehr als ein ELAN handeln). In einer typischen, hochgeladenen Umgebung werden viele LAN Emulation Address Resolution Protocol (LE_ARP)-Anforderungen an das LES gesendet. Die Implementierung des LES auf Cisco Geräten ist ganz einfach. Alle eingehenden LE_ARP-Frames werden an die Control Distribution Virtual Channel Connection (VCC) weitergeleitet.

Sie können keine einfache Hardwarezellreplikation von der Steuerung direkt zur Control Distribution implementieren, da einige Frames (z. B. die Join-Anforderungen) vom LES-Prozess analysiert werden müssen. Daher ist ein Gerät, das als gutes LES fungieren kann, ein Gerät, das:

• verfügt über eine leistungsstarke CPU und kann in kurzer Zeit viele Anrufkonfigurationen annehmen. Dies ist erforderlich, wenn viele Clients gleichzeitig dem ELAN beitreten, aber weniger wichtig als für das LECS, da nur die LECs im ELAN beitreten müssen.

• bietet starken Hardware-Support für Segmentierung und Reassemblierung (SAR). Da alle eingehenden Zellen in Frames reassembliert werden müssen, müssen viele Verbindungsanfragen gleichzeitig eingehen und sehr schnell wieder zusammengesetzt werden.

Denken Sie daran, dass bei der Implementierung von Cisco die Prozesse LES und Broadcast und Unknown Server (BUS) kombiniert werden (d. h. Sie können die LES für ELAN-1 nicht auf einem Gerät und den BUS für ELAN-1 auf einem anderen Gerät platzieren).

Ein weiterer wichtiger Aspekt ist das mögliche Präventivverhalten. Ist die Freischaltung aktiviert, übernimmt der LES/BUS mit der höchsten Priorität (laut LANE-Datenbank) stets die primäre LES/BUS-Pflicht. Mit anderen Worten: Wenn das primäre LES/BUS ausfällt, werden alle LECs des ELAN ausfallen und erneut eine Verbindung zum Sicherung des LES/BUS herstellen. Wenn eine Vorbelegung konfiguriert ist, werden bei einem erneuten Anstieg des primären LES/BUS alle LECs erneut deaktiviert und die Verbindung zum LES/BUS mit der höchsten Priorität wiederhergestellt. In der LANE Module Software Version 3.2.8 und höher sowie in der Cisco IOS® Software Version 11.3(4) und höher kann die Preemptivity-Funktion aktiviert und deaktiviert werden. Die Präventivitätsfunktion kann wie in der Dokumentation zur Konfiguration der LAN-Emulation beschrieben konfiguriert werden.

Broadcast- und unbekannter Server

Die Arbeit des BUS ist der Arbeit des LES ziemlich ähnlich. Jeder LEC muss einen Multicast-Sendevorgang an den BUS haben. Der LEC sendet den gesamten Multicast-, Broadcast- oder unbekannten Datenverkehr an ihn. Der BUS verfügt über einen Point-to-Multipoint-VCC für alle LECs im ELAN. Frames müssen vom BUS nicht detailliert untersucht werden. Mit anderen Worten: Jeder eingehende Frame auf dem Multicast-Sende kann blind an die Multicast-Weiterleitung weitergeleitet werden.

Ein gutes BUS-Gerät:

• bietet Hardwareunterstützung für die Frame-Kopie vom eingehenden Multicast, der an die ausgehende Multicast-Weiterleitung gesendet wird. Wenn Sie über "intelligente" Hardware verfügen, kann dieser Kopiervorgang vor der Reassemblierung durchgeführt werden. Das bedeutet, dass beim Multicast-Senden eingehende Zellen bei der Multicast-Weiterleitung weitergeleitet werden. Dadurch wird pro Frame eine Segmentierung und Reassemblierung gespeichert.

• benötigt eine starke CPU, wenn keine Hardware-Unterstützung für das BUS vorhanden ist.

• muss in der Lage sein, viele Anrufkonfigurationen gleichzeitig zu verarbeiten, jedoch mit einer niedrigeren als der LECS.

Tabelle 1: BUS-Leistung pro Gerät

Gerät	BUS-Durchsatz (Kpps)
Catalyst 6000-LAN/MPOA-Modul (OC-12)	600
Catalyst 5K LANE/MPOA-Modul (OC-12)	600
Catalyst 5K LANE/MPOA-Modul (OC-3)	166
Catalyst 5K LANE-Modul (OC-3)	122
RSP4 - VIP-2-50+PA-A1	92
RSP4 - VIP-2-500+PA-A3	84
RSP4 - VIP-2-40+PA-A3	58
RSP4 - VIP-2-40+PA-A1	77
4700	40
LS1010	30

Funktionen von Cisco Geräten

In diesem Abschnitt werden die Funktionen der gängigsten Cisco Geräte erläutert, die zum Ausführen von LEC, LECS, LES und BUS verwendet werden. Bei diesen Geräten handelt es sich um die Cisco LANE-Module, den Lightstream 1010, den Catalyst 8510MSR und 8540MSR sowie den 7500/RSP. Ihre Fähigkeiten werden mit den oben aufgeführten Anforderungen verglichen.

LANE-Module

Die Architektur aller LAN-Module für den Catalyst 5000 und 6000 basiert in etwa auf der folgenden allgemeinen Ansicht:

Segmentierung und Reassemblierung erfolgen durch die Hardware. Der SAR-Chip ist etwas intelligent und kann die wieder montierten Frames direkt an den Frame-Bus des Katalysators (die Catalyst-Rückwandplatine) weiterleiten. Bei Control-Frames kann der SAR-Chip die Frames an die CPU des LANE-Moduls weiterleiten. Ein Steuerungs-Frame ist ein jeder Frame, der analysiert werden muss (z. B. Interim Local Management Interface (ILMI), Signalisierung und Frames, die für die LES bestimmt sind) und der über eine angegebene VC zum LANE-Modul gelangt.

Der SAR-Chip kann auch Zellen, die vom Multicast kommen, an die Multicast-Weiterleitung weiterleiten (d. h. Multicast-, Broadcast- und unbekannte Zellen, die von den LECs kommen). Die Zellen werden nicht in Rahmen reassembliert. Seine einfache Implementierung führt zu einer sehr guten BUS Performance.

Nach dem Erstellen eines "Data Direct" und eines Eintrags in die Tabelle des Content-Addressable Memory (CAM) werden die wieder zusammengesetzten Frames direkt an den Frame-BUS gesendet und mit der richtigen virtuellen LAN (VLAN)-ID getaggt. Ein LANE-Modul macht einen sehr guten LEC, da die CPU nicht mehr involviert ist, sobald der "Data Direct" eingerichtet wurde.

LightStream 1010 und Catalyst 8510MSR

LS1010 und Catalyst 8510MSR bieten keine Hardware-Unterstützung für SAR. Folglich sind diese Geräte eine schlechte Wahl für die Implementierung von LES/BUS-Funktionen. Sie sind jedoch für das LECS geeignet (siehe Muster 2 unten).

8540MSR

Der 8540MSR bietet Hardwareunterstützung für SAR. Er verfügt außerdem über einen leistungsstarken Risc 5000-Prozessor. 8540MSR wird aus zwei Gründen nicht empfohlen, das LES/BUS zu unterstützen:

• Die BUS-Leistung liegt bei 64-Byte-Paketen bei etwa 50 Kpps, weit unter allen LANE-Modulen. Der Grund hierfür ist, dass für den BUS keine Hardwarebeschleunigung erfolgt.

• Wenn der 8540MSR mit ATM- und Ethernet-Karten verwendet wird, kann die CPU hauptsächlich für die Kommunikation mit Ethernet-Linecards verwendet werden. In diesem Fall sollte die CPU des 8540MSR nicht als LES verwendet werden.

Router-Plattformen

Der am häufigsten für ELAN-übergreifendes Routing verwendete Router ist die Cisco 7500-Plattform (das Route Switch Module (RSM) und der Cisco 7200 werden ebenfalls häufig verwendet). Der Port-Adapter enthält den SAR-Hardwarechip. Route/Switch Processors (RSPs) wie der RSP4 verfügen über genügend CPU-Leistung, um eingehende Frames sehr schnell verarbeiten zu können. Daher sind sie eine gute Wahl für die LES. Die BUS-Leistung liegt jedoch unter der der LANE-Module.

Beispieldesigns

LANE wird hauptsächlich in großen und kritischen Netzwerken eingesetzt. Daher ist Redundanz obligatorisch. Simple Server Redundancy Protocol (SSRP) ist das am häufigsten verwendete Redundanzprotokoll. Wenn die Software neu ist, ist FSSRP das bevorzugte Protokoll (siehe Leitlinie 11).

Nehmen wir an, wir haben ein relativ großes Netzwerk, z. B. 100 VLANs/ELANs und 100 Katalysatoren, die jeweils über ein Dual-Uplink-LANE-Modul verfügen. Das bedeutet, dass für jedes LANE-Modul möglicherweise ein LEC pro ELAN, in diesem Fall 10.000 LECs, benötigt wird. Darüber hinaus wird davon ausgegangen, dass IP verwendet wird und das Design eine sichere Klasse C (254 IP-Host-Adressen, 254 MAC-Adressen) pro VLAN umfasst.

Design 1: Einfach, aber zu vermeiden ...

In diesem Design wurde ein LAN-Modul für die Ausführung der 100 LES/BUS-Server ausgewählt. Gleichzeitig befindet sich das primäre LECS im gleichen LANE-Modul. Dies wird in der Zeichnung unten veranschaulicht:

Beim Erstellen der LECs auf dem LANE-Modul gehen alle LECs hoch, sobald sie konfiguriert sind. Während des Betriebs wird der LES-Prozess möglicherweise überlastet, und dem LANE-Modul wird der Arbeitsspeicher erschöpft. Mit Design 2 werden diese beiden Probleme gelöst.

Das Hauptproblem in diesem Netzwerk ist, wenn ein großes Problem auftritt. Nehmen Sie an, dass das LANE-Modul, das LECS, LES oder BUS hostet, nicht erreichbar ist. Dies kann beispielsweise passieren, wenn das LANE-Modul von Catalyst 1 fehlerhaft ist. Die Redundanz wird zwar angezeigt, aber die Redundanzzeit (d. h. die Zeit zwischen dem Ausfall des primären LECS, LES oder BUS und der erneuten Inbetriebnahme des letzten LEC) kann bis zu zwei Stunden dauern! Bei einem guten Design kann diese Zahl auf einige Dutzend Sekunden oder einige Minuten in großen Netzwerken reduziert werden.

Das Problem liegt in der Signalisierung, die mit der Verbindung der LECs zum ELAN verbunden ist. Wenn jedes LEC das LECS kontaktieren muss, erhält es fast gleichzeitig 10.000 Anrufkonfigurationen (100 LANE-Module mit jeweils 100 LECs). Das LANE-Modul ist so konzipiert, dass eine effiziente Verbindung zwischen dem Frame-Bus und der Mobilfunkverbindung hergestellt werden kann, jedoch nicht für eine große Anzahl von Anrufkonfigurationen pro Sekunde. Die CPU des LANE-Moduls ist nicht leistungsfähig genug, um dieses Volumen an Anrufkonfigurationen zu bewältigen. Die folgende Ausgabe zeigt die Redundanzzeit in einem LANE-Netzwerk mit ca. 1600 LECs (nur ein Teil des Befehls show process cpu wird angezeigt):

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>

Wie Sie sehen können, ist das LANE-Modul aufgrund der eingehenden Signalisierungsaktivität überlastet. Wie wird die Redundanzzeit von zwei Stunden berücksichtigt? Die Antwort liegt im Begriff der Zeitüberschreitung. In den Signalisierungsspezifikationen wird eindeutig angegeben, dass das Gerät neu beginnen muss, wenn es nach einer bestimmten Zeit, wenn eine "Anrufeinrichtung" gesendet wird, keine "Verbindung"-Nachricht zurückerhält. Die LANE-Spezifikationen erfordern, dass der LEC in seinen ursprünglichen Zustand zurückkehren und von vorne beginnen muss. Wenn ein LEC in der Lage ist, das LECS zu kontaktieren und eine Verbindung herzustellen, kann die Anrufeinrichtung an das LES zeitausgeschaltet werden, und es kehrt zum ursprünglichen Zustand zurück, in dem versucht wird, das LECS zu kontaktieren! Dies kann auch bei Verbindungen vom LES und vom/zum BUS passieren.

Basierend auf den obigen Erklärungen sind hier einige grundlegende Designempfehlungen aufgeführt:

• Versuchen Sie, den LES/BUS für die verschiedenen ELANs auf den verschiedenen Geräten zu verbreiten, die ihn effizient implementieren können. Im Idealfall sollte für jedes LAN-Modul ein primärer LES/BUS vorhanden sein, wobei die nächsten Module das erste Modul sichern. In der Praxis würde dies eine sehr lange LECS-Datenbank generieren. Die Erfahrung zeigt, dass 10 LES/BUS-Server pro LANE-Modul eine sichere Nummer sind.

• Versuchen Sie, das LECS nicht am gleichen Ort wie andere wichtige LES/BUS-Server zu platzieren. Versuchen Sie außerdem, das LECS auf einem Gerät mit ausreichender CPU-Leistung aufzustellen, damit es die Signalisierungsinformationen effizient verarbeiten kann. Das LECS sollte sich auf einem Router (der Cisco 7200 oder 7500 wird empfohlen, idealerweise ohne LES/BUS) oder auf einem ATM-Switch befinden.

• Wenn für jedes VLAN eine IP-Adresse und ein Class C-Bereich verwendet wird, sind ca. 250 MAC-Adressen eine gute Zahl für den LES-Dienst. Für 10 LES auf einem LANE-Modul bedeutet dies die CPU eines LANE-Moduls für maximal 2.500 MAC-Adressen. Denken Sie daran, dass es keine festen und offiziellen Zahlen gibt, aber dies ist eine sichere und konservative Schätzung. Auf der anderen Seite sind 200 LES/BUS auf einem LANE-Modul, jedes ELAN enthält 1000 Endstationen, sicher, solange die Station praktisch inaktiv ist (weitere Einzelheiten siehe Leitlinie 3).

Design 2: Komplexer, aber sicherer und effizienter ...

In diesem Design wird das LECS auf den ATM-Switch eingesetzt. Wir verteilen die LES/BUS auf verschiedene LANE Module. Hohe CPU-Werte für Prozesse werden auf keinem LAN-Modul angezeigt, und die Redundanz ist normal.

Richtlinien

Die nachfolgenden Leitlinien sind nur praktische Empfehlungen, die auf der Bereitstellung von produktiven LANE-Netzwerken basieren. Es gibt zwar Beispiele erfolgreicher Netzwerke, die die Empfehlungen übertreffen, aber es ist ein gründliches Verständnis dessen erforderlich, wie sich diese Netzwerke auf das Netzwerk auswirken, bevor diese Richtlinien überschritten werden.

Leitlinie 1

Wenn Sie die Verwendung von Hot Standby Router Protocol (HSRP) über LANE planen, sollten Sie ein Upgrade auf eine aktuelle Version durchführen und HSRP über LANE implementieren.

Leitlinie 2

Verteilen Sie den LANE BUS auf Geräten mit der höchsten BUS-Durchsatzkapazität, wo dies nur minimale Auswirkungen auf andere Prozesse im Gerät hat.

Der LANE BUS leitet alle Broadcast-, Multicast- und unbekannten Ziel-Unicast-Frames, die von Mitgliedern eines ELANs empfangen wurden, an alle Mitglieder des ELAN weiter. Da LANE ATM Adaption Layer 5 (AAL5) verwendet, die das Verschmelzen von Zellen aus unterschiedlichen Protokolldateneinheiten (Protocol Data Units, PDUs) nicht zulässt, muss der BUS die Frames vor der Weiterleitung serialisieren. Dazu muss der BUS die empfangenen Frames neu zusammensetzen, jeden Frame einzeln segmentieren und die Zellen weiterleiten. Die Anforderung, jeden Frame neu zusammenzufügen und zu segmentieren, beschränkt den Weiterleitungsdurchsatz des BUS erheblich, was die Skalierbarkeit eines ELAN erheblich beeinflusst. Die Verbreitung von IP-Multicast-Anwendungen verschärft diese Aufgabe noch weiter. Denken Sie daran, dass nur LANE-Module die Zellen auf Multicast-Sende empfangen und sie über die Multicast-Weiterleitung weiterleiten können. Dies erfolgt ohne Reassemblierung.

Leitlinie 3

Verteilen Sie die LANE-Services auf mehrere Module und Geräte.

Wir haben bereits erklärt, dass 10 LES/BUS mit jedem ELAN, das einem IP-Netzwerk der Klasse C (etwa 250 Benutzer) entspricht, sicher und konservativ sind. Erfolgreiche LANE-Netzwerke mit 10-60 LES/BUS-Paaren pro Modul sind jedoch vorhanden. Dies hängt geringfügig vom Modul ab, aber die Überprüfung des Designs erfordert immer die Überprüfung der CPU-Auslastung (mit dem Befehl show process cpu) und des kleinsten verfügbaren Speichers (mit dem Befehl show memory). Dies sollte natürlich während der Spitzenauslastung des Netzwerks erfolgen, da die Gesamt-CPU-Auslastung des LES direkt mit dem LE_ARP-Prozess zusammenhängt.

In einer LANE-Umgebung sind die LES/BUS-Paare, die sich auf einem einzigen Gerät befinden und das gesamte LANE-Netzwerk unterstützen, häufig zu sehen. Dies stellt nicht nur einen Single-Point-of-Failure dar, sondern beschränkt auch die BUS-Leistung innerhalb jedes ELAN.

Die Verteilung von LANE-Services über mehrere Plattformen hinweg bietet eine höhere Skalierbarkeit in Multi-ELAN-Umgebungen sowie eine höhere Systemverfügbarkeit und eine höhere aggregierte BUS-Leistung (z. B. die aggregierte BUS-Leistung im Netzwerk steigt, wenn mehr Geräte und Schnittstellen für die BUS-Unterstützung konfiguriert werden). Für eine maximale BUS-Kapazität im Hinblick auf das Design können die Catalyst 5000- und 6000-ATM-Module für LES- und BUS-Services dediziert werden.

In Kenntnis der BUS-Kapazität und der Schätzung der erwarteten Menge an Broadcast- oder Multicast-Datenverkehr in jedem ELAN können Sie die Anzahl der LES/BUS-Paare berechnen, die auf eine bestimmte Schnittstelle angewendet werden können. Sie können auch die Kapazität des BUS messen.

Die Schätzung der Menge an Broadcast- oder Multicast-Datenverkehr für jedes ELAN ist jedoch eine größere Herausforderung. Eine Methode zur Schätzung der Menge an Broadcast- oder Multicast-Datenverkehr für jedes ELAN besteht in der Messung des Datenverkehrs im vorhandenen Netzwerk. Zur Messung des Broadcast- und Multicast-Datenverkehrs kann ein Netzwerkanalyse- oder Remote Monitoring (RMON)-Prüfgerät in das bestehende LAN eingefügt werden. Eine andere Möglichkeit besteht darin, die MIB-Objekte "ifOutMulticastPkts" und "ifOutBroadcastPkts" abzufragen. Überprüfen Sie zunächst, ob diese von Ihrer IOS/Plattform unterstützt werden.

Alternativ können Sie die Menge des Broadcast- oder Multicast-Datenverkehrs bis zu einem gewissen Grad berechnen, indem Sie beispielsweise die von Routing-Protokoll-Broadcasts benötigte Bandbreite berechnen. Bei Internetwork Packet Exchange (IPX), Routing Information Protocol (RIP) und Service Advertising Protocol (SAP) kann die Bandbreitennutzung genau bestimmt werden, wenn die Anzahl der IPX-Routen und SAPs bekannt ist. Dasselbe gilt für IP und das verwendete Routing-Protokoll.

Zusätzliche Reserven für BUS-Kapazität sollten reserviert werden für:

• Unterstützung von Unicast-Datenverkehr, solange ein Daten-Direct-VC eingerichtet wird und bis ein Flush-Paket auf dem empfangenden LEC bestätigt wird.

• On-Demand-IP-Multicast-Anwendungen, die zu verschiedenen Tageszeiten genutzt werden (diese sollten im gesamten Multicast-Volumen berücksichtigt werden).

• Zusätzlicher Routing-Datenverkehr, wenn ein Protokoll ausgeführt wird und sich in einem Konvergenzzustand befindet (d. h. LSAs, die während einer OSPF-Topologieänderung (Open Shortest Path First) ausgetauscht werden).

• Hohe Mengen an ARP-Anfragen (Address Resolution Protocol), insbesondere am Morgen, wenn sich die Workstations zuerst bei den LAN- und Netzwerkservern anmelden.

Mit welcher Methode auch immer diese verfügbar ist, soll eine genaue Darstellung der Menge an Broadcast- und Multicast-Datenverkehr erhalten, die in jedem ELAN vorhanden sein wird. Leider sind diese Informationen dem Netzwerkdesigner aus verschiedenen Gründen selten zur Verfügung gestellt. Angesichts dieser Situation können einige allgemeine konservative Leitlinien herangezogen werden. Als Empfehlung sollte einem typischen Netzwerk mit 250 Benutzern pro ELAN, das die gängigeren Anwendungen ausführt, mindestens 10 Kpps BUS-Kapazität zugewiesen werden. Tabelle 1 zeigt die empfohlene Höchstzahl von LES/BUS-Paaren pro Schnittstelle.

Diese Zahlen sollten in Verbindung mit Leitlinie 4 verwendet werden, der zufolge die Anzahl der LECs, die von allen auf einer Schnittstelle konfigurierten LES/BUS-Paaren bedient werden, auf 250 begrenzt ist. Außerdem sollten diese Zahlen an die tatsächliche Anzahl der Benutzer in jedem ELAN angepasst werden, wobei Broadcast- oder Multicast-Anwendungen, die im ELAN ausgeführt werden, besonders zu beachten sind.

Leitlinie 4

Begrenzen Sie die Gesamtanzahl der vom LES/BUS-Paar bedienten LECs auf maximal 250. Während der Initialisierung und nach einem Netzwerkausfall müssen die LANE-Clients mehrere Verbindungen herstellen und Anfragen an ihre LANE-Servicekomponenten richten. Da die Geräte, die die LANE-Dienste unterstützen, über eine begrenzte Rate verfügen, mit der sie die Verbindungen und Anfragen verarbeiten können, wird empfohlen, dass die auf einem Schnittstellendienst konfigurierten LES/BUS-Paare maximal 250 LANE-Clients umfassen. Beispielsweise kann eine Schnittstelle mit 10 LES/BUS-Paaren konfiguriert werden, von denen jeder 25 LECs bedient, sodass insgesamt 250 LECs von der Schnittstelle gewartet werden. Dadurch wird eine rechtzeitige Initialisierung und Wiederherstellung nach Ausfällen gewährleistet.

Leitlinie 5

Stellen Sie den LES/BUS für ein bestimmtes ELAN in unmittelbarer Nähe zu einer beliebigen großen Broadcast- oder Multicast-Quelle bereit.

In einer LANE-Umgebung, insbesondere wenn Multicast-Anwendungen genutzt werden (d. h. IP/TV), empfiehlt es sich, den BUS so nahe wie möglich an der bekannten Multicast-Quelle zu platzieren. Da Multicast-Datenverkehr zunächst an den BUS gesendet werden muss, der den Datenverkehr wiederum an alle Clients weiterleitet, wird durch die Lage des BUS in unmittelbarer Nähe zur Multicast-Quelle verhindert, dass der Datenverkehr den ATM-Backbone zweimal überquert.

Auf diese Weise kann das LAN-Netzwerk um eine größere Größe skaliert werden. Darüber hinaus sollte sich der BUS nicht auf derselben Schnittstelle wie der LEC befinden, der die Multicast-Quelle unterstützt, da der Multicast-Datenverkehr die Übertragungsverbindung zweimal überqueren würde.

Seien Sie vorsichtig, wenn Sie LANE als Netzwerktechnologie zur Unterstützung einer Multicast-Umgebung in Betracht ziehen. Während LANE Multicast-Datenverkehr unterstützt, ist dies eher ineffizient. LANE überschwemmt einfach den Multicast-Datenverkehr an alle Clients im ELAN, unabhängig davon, ob sie zur Multicast-Gruppe gehören oder nicht. Exzessiver Multicast-Datenverkehr kann die Leistung von Workstations erheblich beeinträchtigen (wie in Leitlinie 6 beschrieben), während das Flooding-Verhalten Backbone-Bandbreite verschwendet.

Leitlinie 6

Begrenzen Sie die Anzahl der Endsysteme in einem bestimmten ELAN auf maximal 500, wenn das Netzwerk nur IP-Pakete enthält. In Tabelle 2 unten finden Sie einige grundlegende Empfehlungen, die auf der vom Protokoll generierten Sendemenge basieren. Falls Sie sich nicht sicher sind, welche Protokolle benötigt werden, sollten Sie auch die Empfehlungen der 250 Endstation berücksichtigen, die wir in der Vergangenheit gegeben haben.

Ein ELAN stellt per Definition eine Broadcast-Domäne dar. Daher werden innerhalb eines ELAN alle Broadcast- und Multicast-Pakete an alle Mitglieder des ELANs geflutet. Workstations müssen jedes empfangene Broadcast- und Multicast-Paket verarbeiten, um zu ermitteln, ob es von Interesse ist. Die Verarbeitung "uninteressanter" Broadcast-Pakete vergeudet Workstation-CPU-Zyklen. Wenn der Umfang der Broadcast-Aktivität hoch wird (im Verhältnis zur Verarbeitungskapazität der Workstations), können diese schwerwiegende Auswirkungen haben und daran gehindert werden, ihre beabsichtigten Aufgaben auszuführen.

Die Anzahl der Endsysteme, Anwendungen und die verwendeten Protokolle bestimmen den Übertragungsgrad innerhalb eines ELAN. Tests haben gezeigt, dass die Anzahl der Endsysteme, die in einem einzigen ELAN sicher konfiguriert werden können, ohne dass es Anwendungen mit intensivem Broadcast gibt, je nach Protokoll-Mix zwischen 200 und 500 liegt.

Tabelle 2: Maximale Anzahl empfohlener Endsysteme pro ELAN basierend auf Protokoll-Mix

Protokolltyp	Anzahl der Endsysteme
IP	500
IPX	300
AppleTalk	200
Gemischt	200

Leitlinie 7

Berechnen Sie die Netzwerk-VC-Nutzung, um sicherzustellen, dass sie in der Kapazität der ATM-Geräte liegt.

VC-Nutzung

ATM-Switches und Edge-Geräte unterstützen eine begrenzte Anzahl von VCs. Beim Entwurf von ATM-Netzwerken muss unbedingt sichergestellt werden, dass die VC-Kapazität der Geräte nicht überschritten wird. Dies ist besonders bei LANE-Netzwerken wichtig, da LANE nicht für seine VC-Effizienz bekannt ist. Während der Netzwerkdesign-Phase sollten Sie die erwartete VC-Nutzung für den Backbone sowie für jedes einzelne Edge-Gerät berechnen. Die VC-Nutzung des Backbone entspricht der erwarteten Gesamtzahl von VCs im Netzwerk. Diese Menge sollte mit der Anzahl der von den ATM-Switches unterstützten VCs verglichen werden.

Da nicht alle VCs einen bestimmten Switch durchlaufen, dient diese Zahl als Obergrenze. Die tatsächliche Topologie des Backbones und die Datenverkehrsmuster müssen im Verhältnis zur Gesamtzahl der VCs berücksichtigt werden, um zu ermitteln, ob die VC-Kapazität der ATM-Switches überschritten wird.

Ebenso sollte die VC-Nutzung für jedes Edge-Gerät berechnet werden. Dies bezieht sich auf die Anzahl der VCs, die an einer bestimmten Schnittstelle eines Edge-Geräts enden. Diese Zahl muss dann mit der VC-Kapazität der Schnittstelle verglichen werden.

Die folgenden Formeln können zur Berechnung der VC-Nutzung des Netzwerks verwendet werden. Diese Formeln setzen die Nutzung von Cisco LANE-Services und -Clients voraus und gelten für SSRP und FSSRP. Wenn diese beiden Protokolle verwendet werden, sind Unterschiede bei der VC-Nutzung angegeben.

Backbone VC-Nutzung

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

VC-Nutzung der Edge-Geräteschnittstelle

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

Wenn Sie die VC-Nutzung berechnet haben, vergleichen Sie die Ergebnisse mit der VC-Kapazität der relevanten Geräte in Tabelle 3.

Tabelle 3: ELAN-übergreifendes Routing - VC-Kapazität für verschiedene Cisco Geräte

Gerät	Virtual Circuit-Budget
Catalyst 8540 MSR	256.000
Catalyst 8510 MSR/LS1010	16 MB DRAM (Dynamic Random Access Memory) = 4.000
	32 MB DRAM = 16.000
	64 MB DRAM = 32.000
Cisco 7500/7200 ATM Deluxe	4.000
Cisco 7500/7200 ATM Lite	2.000
Catalyst 6000 - LANE/MPOA OC-12	4.000
Catalyst 5K - LANE/MPOA OC-12	4.000
Catalyst 5K - LANE/MPOA OC-3	4.000
Catalyst 5K - LANE OC-3	4.000
Catalyst 2900 XL - LANE OC-3	1 k

Leitlinie 8

Wenn Sie verschiedene Campus-ATM-Netzwerke mit permanenten virtuellen Pfaden (PVPs) verbinden möchten, "routen" Sie stets zwischen den Standorten, anstatt nativen ELANs die Nutzung verschiedener Campus-ATM-Netzwerke zu ermöglichen.

Leitlinie 9

Analysieren Sie die benötigte Router-Kapazität, indem Sie die benötigte Anzahl an ELAN-übergreifendem Routing ermitteln.

Die in einem LANE-Netzwerk erforderliche Routing-Kapazität ist sehr unterschiedlich. Daher muss die Routing-Kapazität während des Netzwerkdesignprozesses geschätzt werden. Nachdem die erforderliche Kapazität bestimmt wurde, kann die Anzahl der erforderlichen Router und Router-Schnittstellen mithilfe der folgenden Weiterleitungstabellen ermittelt werden:

Tabelle 4: ELAN-übergreifende Routing-Kapazität für verschiedene Cisco Geräte

Gerät	Cisco Express Forwarding (CEF) Distributed (Kpps)	Cisco Express Forwarding (CEF) Forwarding (Kpps)
RSP4/VIP2-50 ATM PA-A3	118	101
RSP4/VIP2-50 ATM PA-A1	91	91
RSP4/VIP2-40 ATM PA-A3	83	60
RSP4/VIP2-40 ATM PA-A1	66	66

Die Konfiguration eines bewaffneten Routers ist in LAN-Designs zwar beliebt, bietet jedoch in der Regel keine ausreichende Routing-Kapazität. Stattdessen sind mehrere Schnittstellen und/oder mehrere Router erforderlich. Bei den in der obigen Tabelle aufgeführten CEF-Weiterleitungsraten wird von einer Konfiguration eines bewaffneten Routers ausgegangen. Um diese Raten zu erreichen, wird der Zentralprozessor des Routers auf fast 100 % ausgebaut. Im Gegensatz dazu werden die verteilten Weiterleitungsraten mit dem auf dem VIP (Versatile Interface Processor) befindlichen Prozessor erreicht, ohne dass dies Auswirkungen auf den zentralisierten Router-Prozessor hat. Infolgedessen können im Router mehrere ATM-Schnittstellen installiert werden, was zu einem wesentlich höheren Gesamtdurchsatz führt.

Leitlinie 10

Stellen Sie aus Redundanzgründen ATM-Edge-Geräte für zwei verschiedene ATM-Switches bereit.

In einem LANE-Netzwerk kann der ATM-Switch, der die Edge-Geräte unterstützt, ein Single Point of Failure für die Verbindung zum Backbone sein. Die Catalyst 6000- und 500-Switches verfügen über OC-12/OC-3-PHY-Uplink-Module (Dual-Physical Sublayer) für eine redundante Verbindung zu Downstream-ATM-Switches. Die Dual-Homed LANE-Module bieten eine "Fiber Distributed Data Interface (FDDI)-ähnliche" Dual-PHY-Funktion. Dieses Dual-PHY-Uplink-Modul bietet eine primäre und sekundäre ATM-Schnittstelle. Wenn die Verbindung zwischen der primären Schnittstelle und dem ATM-Switch unterbrochen wird, schaltet das Modul die Verbindung automatisch zur sekundären Schnittstelle um.

Es wird dringend empfohlen, dass der Netzwerkdesigner die Dual-PHY-Schnittstellen der LANE-Module nutzt und Dual-Homed-Uplinks zu zwei verschiedenen ATM-Switches im Core bereitstellt. Dadurch werden die Edge-Geräte vor dem Ausfall eines einzigen ATM-Switches geschützt.

Leitlinie 11

Verwenden Sie FSSRP, sofern das VC-Budget keine Einschränkungen aufweist.

Da die verschiedenen LANE-Servicekomponenten einzelne Fehlerpunkte in einem LANE-Netzwerk darstellen, sollten Produktionsnetzwerke redundant ausgelegt sein. Cisco unterstützt zwei Redundanzschemata für LANE-Services: Simple Server Redundancy Protocol (SSRP) und Fast SSRP (FSSRP)

FSSRP ist in den meisten Fällen das empfohlene Redundanzschema. Sie bietet beinahe sofortiges Failover ohne Datenverlust auch in großen Netzwerken. Andererseits führt SSRP bei einem Failover zu Verlusten, und die Wiederherstellungszeiten können in großen Netzwerken erheblich (manchmal Minuten) sein.

In einer Situation wird SSRP gegenüber FSSRP empfohlen: wenn das Netzwerk VC-eingeschränkt ist. Im Gegensatz zu SSRP unterhalten FSSRP-LECs Backup-Verbindungen zu den redundanten LES/BUS-Paaren. Es können bis zu drei Backup-LES/BUS-Paare konfiguriert werden, im Vergleich zu insgesamt vier pro ELAN. Die VC-Nutzung erhöht, dass das Netzwerk im Rahmen des FSSRP genutzt wird, und kann mit der folgenden Formel berechnet werden:

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

Wenn das Netzwerk seine VC-Kapazität erreicht, wird daher SSRP gegenüber FSSRP empfohlen. Wenn Sie FSSRP verwenden, sollten Sie die Anzahl der redundanten LES/BUS-Komponenten reduzieren. In den meisten Fällen bieten insgesamt zwei LES/BUS-Paare pro ELAN ein akzeptables Gleichgewicht zwischen der VC-Nutzung und der Vermeidung von Single Points of Failure.

Zugehörige Informationen

• Implementierung von HSRP über LANE
• ATM-Unterstützung - LAN-Emulation (LANE)
• Allgemeine Informationen zu ATM
• Technischer Support und Dokumentation - Cisco Systems