LANE-ontwerpaanbevelingen

Inleiding

Dit document bevat praktische LAN-richtlijnen (LANE) voor het netwerkontwerp. Deze richtlijnen zullen u helpen bij het ontwerp van hoogwaardige, schaalbare en hoge beschikbaarheid LANE-netwerken. Terwijl dit document zich op Cisco-apparatuur concentreert, kunnen dezelfde concepten worden toegepast bij het integreren van producten van derden.

Voordat u begint

Conventies

Zie de Cisco Technical Tips Convention voor meer informatie over documentconventies.

Voorwaarden

Lezers van dit document moeten kennis hebben van basisbewerkingen en configuraties van LANE-netwerken.

Gebruikte componenten

Dit document is gericht op Ethernet LANE-configuraties.

De informatie in dit document is gebaseerd op apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als u in een levend netwerk werkt, zorg er dan voor dat u de potentiële impact van om het even welke opdracht begrijpt alvorens het te gebruiken.

De serververeisten begrijpen

De verschillende LANE-servers en hun vereisten worden hieronder weergegeven.

De LAN Emulation Configuration Server (LECS)

De specificatie van LAN Emulation over ATM versie 1.0 vereist dat elke LAN Emulation Client (LEC) een virtueel circuit (VC) instelt op de LAN Emulation Configuration Server (LECS) wanneer deze toeneemt. LEC vraagt vervolgens het ATM-adres van de corresponderende LAN Emulation Server (LES). Zodra de LEC zijn ATM LES-adres heeft, wordt de VC tussen de LEC en de LECS verwijderd en probeert de LEC niet langer te communiceren met de LECS. Wanneer het milieu stabiel is en alle LEC's operationeel zijn, is de LECS niet actief.

Wanneer de LEC's zich bij het gecodeerde LAN (ELAN) aansluiten, nemen zij elk afzonderlijk contact op met de LECS. Wanneer het LANE-netwerk echter een ramp ondergaat (bijvoorbeeld wanneer de primaire LECS mislukt), gaan alle klanten naar beneden.

Opmerking: De uitzondering hierop is wanneer Fast Simple Server Redundancy Protocol (FSSRP) wordt gebruikt.

Aangezien alle LEC's tegelijkertijd naar beneden gaan, zullen ze tegelijkertijd allemaal contact opnemen met de LECS-back-up. Daarom hebt u voor het organiseren van de LECS een apparaat nodig dat:

• kan een plotse uitbarsting van verkeer op procesniveau aan.

• kan bijna alle inkomende opriepen van de LEC's tegelijkertijd accepteren.

• staat bekend om zijn stabiliteit. Als de LECS afneemt gaat het hele netwerk omlaag (opnieuw, met uitzondering van FSSRP). Daarom wordt het niet aanbevolen om de LECS op een apparaat te zetten dat een experimentele softwareversie gebruikt.

De LAN Emulation Server (ELS)

Elke LEC zal een bidirectionele VC aan de LE van de ELAN houden (het kan meer dan één ELAN zijn als FSSRP wordt gebruikt). In een typisch zeer geladen omgeving, zullen veel LAN Emulation Address Protocol (LE_ARP) verzoeken naar de LES worden verzonden. De implementatie van de LES op Cisco-apparaten is vrij eenvoudig. Alle inkomende LE_ARP frames zullen worden doorgestuurd naar de control Distributed Virtual Channel Connection (VCC).

U kunt geen eenvoudige hardwarecelreplicatie vanuit besturing direct uitvoeren om te distribueren omdat sommige frames (zoals de verbindingsaanvragen) door het LES-proces moeten worden geanalyseerd. Daarom is een apparaat dat als een goede LES kan fungeren een apparaat dat:

• heeft een krachtige CPU en kan veel oprichters in korte tijd accepteren. Dit is noodzakelijk wanneer veel klanten zich tegelijkertijd bij de ELAN aansluiten, maar minder vitaal dan voor de LECS, aangezien alleen de LEC's in de ELAN moeten toetreden.

• krachtige ondersteuning voor segmentatie en hermontage (SAR). Omdat alle binnenkomende cellen in frames moeten worden geherassembleerd, als veel samengevoegde verzoeken tegelijkertijd arriveren, zullen ze zeer snel opnieuw in elkaar moeten worden gezet.

Onthoud dat in de implementatie van Cisco, LES en Broadcast en Onbekende Server (BUS) processen worden gecombineerd (dwz, u kunt de LES voor ELAN-1 niet op één apparaat en de BUS voor ELAN-1 op een ander apparaat).

Een ander ding om in gedachten te houden is mogelijk preventief gedrag. Als pre-emption is ingeschakeld, zal de LES/BUS met de hoogste prioriteit (volgens de LANE-databank) altijd de primaire LES/BUS-rechten overnemen. Met andere woorden, als de primaire LES/BUS mislukt, zullen alle LECs van de ELAN naar beneden gaan en opnieuw worden aangesloten op de reservekopie LES/BUS. Als pre-emptivity is geconfigureerd, als de primaire LES/BUS opnieuw omhoog gaat, zullen alle LECs weer omlaag gaan en met de hoogste prioriteit opnieuw op de LES/BUS worden aangesloten. In LANE Module softwarerelease 3.2.8 en hoger, en Cisco IOS® softwarerelease 11.3(4) en later, kan de pre-emptivity optie in en uit worden gezet. De pre-emptivity optie kan worden geconfigureerd zoals wordt beschreven in de documentatie bij het configureren van LAN-emulatie.

De broadcast- en onbekende server

Het werk van de BUS lijkt sterk op dat van de LES. Elke LEC moet één multicast verzenden naar de BUS. De LEC stuurt al haar multicast, uitgezonden of onbekend verkeer naar het station. De BUS heeft een point-to-multipoint VCC voor alle LEC's in de ELAN. Frames hoeven niet in detail door de BUS te worden onderzocht. Met andere woorden, elk inkomend frame op de multicast verzenden kan blind worden doorgestuurd naar de multicast voorwaarts.

Een goed BUS-apparaat:

• heeft hardwareondersteuning voor het frame-exemplaar van de inkomende multicast die naar de uitgaande multicast wordt verzonden. Als u "slimme" hardware hebt, kan deze kopieerbewerking worden uitgevoerd voordat u het apparaat opnieuw monteert. Dit betekent dat cellen die in de multicast binnenkomen, worden doorgestuurd in de multicast voorwaarts. Dit bespaart één segmentatie en hermontage per frame.

• vereist een sterke CPU als er geen hardwareondersteuning voor de BUS is.

• moet in staat zijn om een groot aantal opriepen tegelijkertijd te verwerken, maar met een lagere limiet dan de LECS.

Tabel 1: BUS-prestaties per apparaat

Apparaat	BUS-doorvoersnelheid (KPPS)
Catalyst 6K LANE/MPOA-module (OC-12)	600
Catalyst 5K LANE/MPOA-module (OC-12)	600
Catalyst 5K LANE/MPOA-module (OC-3)	166
Catalyst 5K LANE-module (OC-3)	122
RSP4 - VIP-2-50+PA-A1	92
RSP4 - VIP-2-500+PA-A3	84
RSP4 - VIP-S2-40+PA-A3	78
RSP4 - VIP-S2-40+PA-A1	77
4700	40
LS1010	30

De mogelijkheden van Cisco-apparaten begrijpen

Deze sectie bestrijkt de functies van de meest gebruikelijke Cisco-apparaten die worden gebruikt om LEC, LECS, LES en BUS uit te voeren. Deze apparaten zijn de Cisco LANE-modules, de Lightstream 1010, Catalyst 8510MSR en 8540MSR en de 7500/RSP. Hun mogelijkheden worden vergeleken met de hierboven genoemde eisen.

LANE-modules

De architectuur van alle LANE-modules voor Catalyst 5000 en 6000 is ruwweg gebaseerd op de volgende hoogvlakke visie:

Segmentering en hermontage worden uitgevoerd door de hardware. De SAR-chip is ietwat intelligent en kan de opnieuw gemonteerde frames rechtstreeks naar de frame-bus van de katalysator (de katalysator backplane) doorsturen. Voor besturingsframes kan de SAR-chip de frames naar de CPU van de LANE-module doorsturen. Een bedieningskader is elk frame dat moet worden geanalyseerd (bijvoorbeeld Interim Local Management Interface (ILMI), signalering en frames bestemd voor de LE), dat via een gespecificeerde VC naar de LANE-module komt.

De SAR-chip kan ook cellen die op de multicast komen, hersturen naar de multicast voorwaarts (dat wil zeggen, multicast, broadcast en onbekende cellen die afkomstig zijn van de LEC’s). De cellen worden niet opnieuw in frames geassembleerd. Het gemak waarmee de uitvoering verloopt, levert zeer goede BUS-prestaties op.

Zodra een "data direct" en een ingang in de content-adressable memory (CAM) tabel zijn gemaakt, worden de geherassembleerde frames direct naar het frame BUS verzonden en getagd met de juiste virtuele LAN (VLAN)-id. Een LANE-module maakt een zeer goede LEC omdat, wanneer de "data direct" is ingesteld, de CPU niet langer betrokken is.

LightStream 1010 en Catalyst 8510MSR

LS1010 en Catalyst 8510MSR hebben geen hardwareondersteuning voor SAR. Als gevolg daarvan zijn deze apparaten een slechte keuze voor het implementeren van LES/BUS-functies. Zij zijn echter geschikt voor de LECS (zie voorbeeldontwerp 2 hieronder).

8540 MSR

De 8540MSR heeft hardwareondersteuning voor SAR. Het heeft ook een krachtige Risc 5000-processor. 8540MSR wordt niet aanbevolen om de LES/BUS te ondersteunen, en wel om twee redenen:

• De BUS-prestaties zijn ongeveer 50 kps voor 64 byte-pakketten, ver onder een LANE-module. Dit komt doordat er geen hardwareversnelling is voor de BUS.

• Als de 8540MSR wordt gebruikt met ATM- en Ethernet-kaarten, kan de CPU primair worden gebruikt om met Ethernet-lijnkaarten te praten. In dit geval moet de 8540MSR-processor niet als een LE worden gebruikt.

Routerplatforms

De meest gebruikte router voor inter-ELAN-routing is Cisco 7500 platform (de RSM-Switch van de route) en Cisco 7200 wordt ook veel gebruikt). De poortadapter bevat de SAR-hardwarechip. RSP4-routeprocessors (RSP4) zoals de RSP4 beschikken over voldoende CPU-voeding om inkomende frames zeer snel te verwerken; daarom zijn zij een goede keuze voor de LES . De prestaties in de VS liggen echter onder die van de LANE-modules.

Modellen

LANE wordt voornamelijk gebruikt in grote en kritieke netwerken. Als zodanig is redundantie verplicht. Simple Server Redundancy Protocol (SSRP) is het meest gebruikte redundantie-protocol. Als de software recent is, is FSSRP het voorkeurprotocol (zie Richtsnoer nr. 11).

Laten we aannemen dat we een vrij groot netwerk hebben, bijvoorbeeld 100 VLAN's/ELAN's en 100 katalysatoren, elk met een dubbele uplinks LAN-module. Dit betekent dat we bij elke LANE-module misschien één LEC per ELAN nodig hebben, in dit geval 10.000 LEC's. Daarnaast gaan we ervan uit dat IP wordt gebruikt en dat het ontwerp een safe Class C (254 IP host-adressen, 254 MAC-adressen) per VLAN omvat.

Ontwerp 1: Eenvoudig, maar te voorkomen...

In dit ontwerp is één LANE-module gekozen om de 100 LES/BUS-servers te starten. Tegelijkertijd is de primaire LECS op dezelfde LANE module gericht. Dit wordt in de onderstaande tekening weergegeven:

Wanneer u de LEC's maakt op de LANE-module, gaan alle LEC's omhoog zodra ze zijn geconfigureerd. Tijdens de bewerking kan het LES-proces worden overbelast en is de LANE-module niet langer geheugen. Ontwerp 2 hieronder lost beide problemen op.

Het belangrijkste probleem in dit netwerk is wanneer er een groot probleem optreedt. Stel dat de LANE-module die de LECS, LES of BUS host, onbereikbaar wordt. Dit kan bijvoorbeeld gebeuren als de LANE-module van Catalyst 1 defect wordt. U ziet redundantie plaatsvinden, maar de redundantie (dat wil zeggen, de tijd tussen de primaire LECS, LES of BUS-mislukking, en de laatste LEC die opnieuw in bedrijf wordt) kan tot twee uur duren! Een goed ontwerp kan dit aantal terugbrengen naar tientallen seconden, of een paar minuten in grote netwerken.

Het probleem ligt bij de signalering die betrokken is bij de aansluiting van de LEC's bij de ELAN. Als de LECS door elke LEC moet worden benaderd, zal zij bijna gelijktijdig 10.000 telefoontjes ontvangen (100 LANE-modules met elk 100 LEC's). De LANE-module is ontworpen om efficiënt te overbruggen tussen de frame-bus en de cellink, maar niet om veel oprichters per seconde aan te kunnen. De CPU van de LANE-module is niet krachtig genoeg om dit volume van oprichters aan te kunnen. De volgende uitvoer illustreert redundantietijd in een LANE-netwerk met ongeveer 1600 LECs (het cpu-bevel van de show processen wordt slechts gedeeltelijk weergegeven):

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>

Zoals u kunt zien, wordt de LANE-module te veel gebruikt door de inkomende signaleringsactiviteit. Wat is de periode van twee uur voor redundantie? Het antwoord ligt in het begrip 'time-out'. De signaleringsspecificaties vermelden duidelijk dat als het apparaat geen "connect"-bericht terugkrijgt na een bepaalde tijd wanneer een "call Setup" wordt verstuurd, het opnieuw moet starten. LANE specificaties vereisen dat de LEC terugkeert naar de oorspronkelijke toestand en opnieuw begint. Dit betekent dat als een LEC contact kan opnemen met de LECS en er verbinding mee kan maken, de belleninstelling op de LES uitvalt en het terugkeert naar de eerste toestand van de LECS-verbinding. Dit kan ook gebeuren met verbindingen vanaf de LE en van/naar de BUS.

Gebaseerd op de bovenstaande verklaringen zijn hier een paar basisontwerpaanbevelingen:

• Probeer de LES/BUS voor de verschillende LAN’s te verspreiden op de verschillende apparaten die dit efficiënt kunnen implementeren. Idealiter één primaire LES/BUS op elke LANE-module met de volgende back-up van de eerste. In de praktijk zou dit een zeer lange LECS-database opleveren. De ervaring leert dat 10 LES/BUS-servers per LANE-module een veilig aantal lijken te zijn.

• Probeer de LECS niet op dezelfde locatie te plaatsen als andere belangrijke LES/BUS-servers. Probeer ook de LECS op een apparaat met voldoende CPU-voeding te zetten zodat u de signaleringsinformatie efficiënt kunt verwerken. LECS moet op een router zijn (Cisco 7200 of 7500 wordt aanbevolen, idealiter zonder LES/BUS) of op een ATM-switch.

• Aangenomen dat IP en één Klasse C bereik voor elk VLAN wordt gebruikt, zijn ongeveer 250 MAC adressen een goed aantal voor de LES-functie. Voor 10 LES op een LANE-module betekent dit de CPU van één LANE-module voor maximaal 2500 MAC-adressen. Let op dat er geen vaste en officiële cijfers zijn, maar dit is een veilige en conservatieve schatting. Aan de andere kant zijn 200 LES/BUS op een LANE-module, waarbij elke ELAN 1000 eindstations bevat, veilig zolang het station praktisch leeg blijft (zie Richtsnoer nr. 3 voor meer informatie).

Ontwerp 2: Nog complexer, maar veiliger en efficiënter...

In dit ontwerp zetten we de LECS op de ATM switch. We spreiden de LES/BUS over verschillende LANE-modules. Hoge proces-CPU-waarden worden niet op enige LANE-modules gezien en redundantie is normaal.

Richtsnoeren

De onderstaande richtsnoeren zijn uitsluitend praktische aanbevelingen, gebaseerd op de invoering van LAN-productienetwerken. Hoewel er voorbeelden zijn van succesvolle netwerken die de aanbevelingen overtreffen, is er een grondig inzicht nodig in de manier waarop ze het netwerk zullen beïnvloeden voordat ze deze richtlijnen overtreffen.

Richtsnoer nr. 1

Als u van plan bent het Hot Standby Router Protocol (HSRP) te gebruiken via LANE, zorg er dan voor dat u upgrades uitvoert naar een recente release en HSRP via LANE hebt gelezen.

Richtsnoer nr. 2

Verdeel de LANE BUS op apparaten met de hoogste doorvoercapaciteit van de BUS en waar deze minimale invloed heeft op andere processen in het apparaat.

LANE BUS is verantwoordelijk voor het doorsturen van alle uitzendingen, multicast en onbekende bestemming die eenastframes ontvangen van leden van een ELAN, naar alle leden van de ELAN. Aangezien LANE ATM-aanpassingslaag 5 (AAL5) gebruikt die niet toestaat dat cellen van verschillende protocol gegevenseenheden (PDU's) worden ondergebracht, moet de BUS de frames serializeren voordat het verzenden wordt. Dit vereist dat de BUS de ontvangen frames opnieuw monteert, elk frame één voor één segmenteert en de cellen doorstuurt. De vereiste om elk frame opnieuw te monteren en te segmenteren beperkt aanzienlijk de doorvoerdoorvoerdoorvoersnelheid van de BUS, wat de schaalbaarheid van een ELAN aanzienlijk beïnvloedt. De proliferatie van IP multicast toepassingen intensiveert deze taak verder. Denk eraan dat alleen LANE modules de cellen kunnen ontvangen op multicast verzenden en doorsturen in de multicast voorwaarts. Dit gebeurt zonder hermontage.

Richtsnoer nr. 3

Verdeel de LANE diensten over meerdere modules en apparaten.

We hebben hierboven verklaard dat 10 LES/BUS bij elke ELAN die overeenkomt met een IP-netwerk van klasse C (ongeveer 250 gebruikers) veilig en conservatief zijn; er bestaan echter succesvolle LANE-netwerken met 10-60 LES/BUS-paren per module. Dit is iets afhankelijk van de module, maar bij het controleren van het ontwerp wordt altijd het CPU-gebruik gecontroleerd (met de opdracht tonen processen cpu), en het laagst beschikbare geheugen (met de opdracht getoond geheugen). Dit dient uiteraard te worden uitgevoerd tijdens pieknetwerkgebruik, aangezien het totale CPU-gebruik van de LES direct verband houdt met het LE_ARP-proces.

In een LANE-omgeving is het gebruikelijk om de LES/BUS-paren te zien op één apparaat dat het gehele LANE-netwerk ondersteunt. Niet alleen betekent dit één enkel punt van mislukking, maar het beperkt de prestaties van de BUS binnen elke ELAN.

Het distribueren van LANE-services over meerdere platforms biedt een grotere schaalbaarheid in meerdere LAN-omgevingen, een hogere systeembeschikbaarheid en hogere totale BUS-prestaties (bijvoorbeeld de totale BUS-prestaties in het netwerk toenemen naarmate meer apparaten en interfaces voor BUS-ondersteuning worden geconfigureerd). Voor een maximale BUS-capaciteit vanuit een ontwerpperspectief kunnen Catalyst 5000- en 6000 ATM-modules worden toegewezen aan LES en BUS-diensten.

Bekend de capaciteit van de BUS, en schat de hoeveelheid uitzending of multicast verkeer die in elk ELAN wordt verwacht, kunt u het aantal LES/BUS paren berekenen die op een bepaalde interface kunnen worden toegepast. U kunt ook de capaciteit van de VS meten.

Het schatten van de hoeveelheid uitzending of multicast verkeer voor elk ELAN is echter uitdagender. Eén methode om de hoeveelheid uitgezonden of multicast verkeer voor elke ELAN te schatten is dit verkeer op het bestaande netwerk te meten. Een apparaat voor netwerkanalyse of afstandsbediening (RMON) kan in het bestaande LAN worden geplaatst om de hoeveelheid broadcast en multicast verkeer te meten. Een andere manier is om de mib "ifOutMulticastPkts" en "ifOutBroadcastPkts" te vragen. Controleer eerst of ze al dan niet ondersteund worden op uw IOS/platform.

In plaats hiervan kunt u, tot op zekere hoogte, de hoeveelheid uitzending of multicast verkeer berekenen door de bandbreedte te berekenen die door protocol uitzendingen, bijvoorbeeld, te routeren. Voor Internetwork Packet Exchange (IPX), Routing Information Protocol (RIP), en Service Advertisation Protocol (SAP), kan het bandbreedteverbruik nauwkeurig worden bepaald als het aantal IPX-routes en SAP’s bekend is. Het zelfde is waar voor IP en het bijzondere routingprotocol dat wordt gebruikt.

Aanvullende BUS-capaciteitsruimte dient te worden gereserveerd voor:

• Het ondersteunen van het eenastverkeer terwijl een data direct VC wordt opgericht en tot een flushpakket op de ontvangende LEC wordt erkend.

• IP-multicast toepassingen op aanvraag die op verschillende tijdstippen van de dag worden gebruikt (deze moeten worden gezien in het algehele multicast volume).

• Aanvullende routingverkeer wanneer een protocol wordt uitgevoerd en in een conversiestatus (dat wil zeggen, link-state advertenties (LSAs) die tijdens een Open Shortest Path First (OSPF) topologie worden uitgewisseld).

• Hoge volumes van de verzoeken van het Protocol van de Resolutie van het Adres (ARP), specifiek in de ochtend wanneer de werkstations eerst in LAN en netwerkservers registreren.

Met elke beschikbare methode is het doel een nauwkeurige weergave te hebben van de hoeveelheid uitzending en multicast verkeer die op elke ELAN zal bestaan. Helaas is deze informatie om verschillende redenen zelden beschikbaar voor de netwerkontwerper. In het licht van deze situatie kunnen enkele algemene conservatieve richtsnoeren worden gebruikt. Als aanbeveling zou een typisch netwerk met 250 gebruikers per ELAN, dat de meest voorkomende toepassingen beheert, ten minste 10 Kpps BUS-capaciteit moeten krijgen. Tabel 1 illustreert het maximaal aanbevolen aantal LES/BUS-paren per interface.

Deze getallen moeten worden gebruikt in combinatie met Richtsnoer nr. 4, dat het aantal LEC's dat wordt bediend door alle LES/BUS-paren die op een interface zijn geconfigureerd tot 250. Ook moeten deze getallen worden aangepast op basis van het werkelijke aantal gebruikers in elk ELAN, waarbij bijzondere aandacht wordt besteed aan alle uitzending- of multicast-toepassingen die op het ELAN zullen worden uitgevoerd.

Richtsnoer nr. 4

Beperk het totale aantal LEC's dat door het LES/BUS-paar wordt onderhouden tot maximaal 250. Tijdens de initialisatie en na een netwerkstoring, moeten de LANE-klanten meerdere verbindingen tot stand brengen en verzoeken indienen bij hun LANE-servicecomponenten om zich bij hun ELAN aan te sluiten. Aangezien de apparaten die de LANE-diensten ondersteunen een eindig tarief hebben waarmee zij de verbindingen en verzoeken kunnen verwerken, wordt aanbevolen om de LES/BUS-paren die op een interfacedienst zijn ingesteld, maximaal 250 LANE-klanten te laten uitvoeren. Een interface kan bijvoorbeeld worden geconfigureerd met 10 LES/BUS-paren, waarbij elke servicemodule 25 LEC’s onderhoudt voor in totaal 250 LEC’s die door de interface worden onderhouden. Dit zal een tijdige initialisering en herstel van mislukkingen garanderen.

Richtsnoer nr. 5

Plaats de LES/BUS voor een bepaalde ELAN in dichtbij om het even welke grote uitzending of multicast verkeersbron.

In een LANE-omgeving, specifiek waar multicast toepassingen in gebruik zijn (dat wil zeggen IP/TV), is het een goede ontwerppraktijk om de BUS zo dicht mogelijk bij de bekende multicast bron te plaatsen. Aangezien multicast verkeer eerst naar de BUS moet worden verstuurd, die op haar beurt het verkeer naar alle klanten doorstuurt, bespaart het verkeer van de BUS in de nabijheid van de multicast-bron door de ATM-backbone tweemaal te overschrijden.

Hierdoor kan het LANE-netwerk naar een grotere schaal schalen. Daarnaast dient de BUS niet op dezelfde interface te worden geplaatst als de LEC die de multicast bron ondersteunt, aangezien het multicast verkeer de verzendlink tweemaal zou doorkruisen.

Let op als u LANE beschouwt als de netwerktechnologie ter ondersteuning van een multicast omgeving. Hoewel LANE multicast verkeer ondersteunt, doet het dat redelijk inefficiënt. LANE overspoelt simpelweg het multicast verkeer naar alle klanten in het ELAN ongeacht of ze al dan niet deel uitmaken van de multicast groep. Meer multicast verkeer kunnen de prestaties van werkstations aanzienlijk verbeteren (zoals besproken in Richtsnoer nr. 6), terwijl het overstroomgedrag backbone-bandbreedte verspilt.

Richtsnoer nr. 6

Beperk het aantal eindsystemen in een bepaalde LAN tot 500 of minder, indien het netwerk alleen IP-pakketten vervoert. Tabel 2 bevat een aantal basisaanbevelingen op basis van de hoeveelheid uitzending die door het protocol wordt gegenereerd. Opnieuw, voor het geval u niet helemaal zeker bent welke protocollen nodig zullen zijn, houd rekening met de 250 aanbeveling van het eindstation die we in het verleden hebben gedaan.

Per definitie vertegenwoordigt een ELAN een uitgezonden domein. Daarom worden in een ELAN alle uitzending- en multicast pakketten naar alle leden van het ELAN overspoeld. De werkstations moeten elk ontvangen uitzending en multicast pakket verwerken om te bepalen of het van belang is. Bij de verwerking van "oninteressante" uitzendingen worden de werkstationcycli van CPU’s verspild. Wanneer het niveau van de uitzendactiviteit hoog wordt (in verhouding tot de verwerkingscapaciteit van de werkstations), kunnen zij ernstig worden beïnvloed en worden belet hun geplande taken uit te voeren.

Het aantal eindsystemen, toepassingen en het (de) gebruikte protocol(nen) bepalen het niveau van de omroep binnen een ELAN. Tests hebben aangetoond dat, bij het ontbreken van uitzending-intensieve toepassingen, het aantal eindsystemen dat veilig in één enkele ELAN kan worden geconfigureerd varieert van 200 tot 500 afhankelijk van de protocolmix.

Tabel 2: Maximum aantal aanbevolen eindsystemen per LAN op basis van Protocol Mix

Type protocol	Aantal eindsystemen
IP	500
IPX	300
AppleTalk	200
Gemengde	200

Richtsnoer nr. 7

Bereken het gebruik van de netwerk VC om er zeker van te zijn dat dit binnen de capaciteit van de ATM-apparaten valt.

VC-gebruik

ATM-switches en -randapparaten ondersteunen een beperkt aantal VC’s. Bij het ontwerpen van ATM-netwerken is het belangrijk om ervoor te zorgen dat de VC-capaciteit van de apparatuur niet wordt overschreden. Dit is met name belangrijk in LANE-netwerken, aangezien LANE niet genoteerd wordt voor de efficiëntie van de VC. Tijdens de fase van het netwerkontwerp, zou u het verwachte gebruik van VC voor de backbone, evenals voor elk afzonderlijk randapparaat, moeten berekenen. Het VC-gebruik van de backbone komt overeen met het totale aantal VC’s dat in het netwerk wordt verwacht. Deze hoeveelheid moet worden vergeleken met het aantal VC’s dat door de ATM-switches wordt ondersteund.

Aangezien niet alle VC’s een bepaalde switch oversteken, dient dit nummer als een bovengrens. De eigenlijke topologie van de backbone en de verkeerspatronen moet in verhouding tot het totale aantal VC's in aanmerking worden genomen om te bepalen of de VC-capaciteit van de ATM-switches zal worden overschreden.

Op dezelfde manier dient het gebruik van de VC voor elk randapparaat te worden berekend. Dit heeft betrekking op het aantal VC's dat op een bepaalde interface van een randapparaat zal eindigen. Dit nummer moet vervolgens worden vergeleken met de VC-capaciteit van de interface.

De volgende formules kunnen worden gebruikt bij het berekenen van het gebruik van de VC in het netwerk. Deze formules nemen het gebruik van Cisco LANE services en klanten aan en zijn van toepassing op SSRP en FSSRP. Indien aanwezig, worden verschillen in gebruik van de VC tussen de twee protocollen aangegeven.

Backbone VC-gebruik

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

Gebruik van Edge-apparaatinterface VC

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

Vergelijk de resultaten met de VC-capaciteit van de relevante apparaten met behulp van tabel 3 zodra u het gebruik van de VC hebt berekend.

Tabel 3: Inter-ELAN routing - VC-capaciteit voor diverse Cisco-apparaten

Apparaat	Virtual Circuit-begroting
Catalyst 8540 MSR switch	256 k
Catalyst 8510 MSR/LS 1010 switch	16 MB dynamisch geheugen met willekeurige toegang (DRAM) = 4k
	32 MB DRAM = 16k
	64 MB DRAM = 32k
Cisco 7500/7200 ATM fijne was	4 k
Cisco 7500/7200 ATM Lite-software	2k
Catalyst 6K - LANE/MPOA OC-12	4 k
Catalyst 5K - LANE/MPOA OC-12	4 k
Catalyst 5K - LANE/MPOA OC-3	4 k
Catalyst 5K - LANE OC-3	4 k
Catalyst 2900XL - LANE OC-3 switch	1k

Richtsnoer nr. 8

Als u verschillende campus ATM-netwerken wilt verbinden met permanente virtuele paden (PVP's), "route" tussen de sites in plaats van autochtone LAN's te laten lopen op verschillende campus ATM-netwerken.

Richtsnoer nr. 9

Bepaal de routercapaciteit nodig door de hoeveelheid inter-ELAN routing te schatten die vereist is.

De hoeveelheid routingcapaciteit die in een bepaald LAN-netwerk vereist is, varieert sterk. Daarom moet de hoeveelheid routingcapaciteit tijdens het netwerkontwerpproces worden geschat. Na het bepalen van de benodigde capaciteit kan het aantal routers en routerinterfaces worden bepaald met behulp van de volgende doorvoertabel:

Tabel 4: Inter-ELAN routingcapaciteit voor verschillende Cisco-apparaten

Apparaat	Cisco Express Forwarding (CEF) Gedistribueerd (KPPS)	Cisco Express Forwarding (CEF) Doorsturen (KPS)
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

Hoewel de "één-gewapende" routerconfiguratie populair is in LANE-ontwerpen, biedt dit doorgaans geen geschikte routingcapaciteit. In plaats daarvan zijn meerdere interfaces en/of meerdere routers vereist. De CEF-expediteits die in de tabel hierboven zijn vermeld, veronderstellen een 1-gewapende routerconfiguratie. Om deze snelheden te bereiken wordt de centrale processor van de router naar bijna 100% van het gebruik gestuwd. Daarentegen worden de gedistribueerde verzendsnelheden behaald met de processor die op de veelzijdige interfaceprocessor (VIP) berust, zonder dat dit gevolgen heeft voor de gecentraliseerde routerprocessor. Als resultaat hiervan kunnen meerdere ATM interfaces worden geïnstalleerd in de router die leidt tot een veel hogere totale doorvoersnelheid.

Richtsnoer nr. 10

Verstrek dual-home ATM-randapparatuur aan ten minste twee verschillende ATM-switches voor redundantie.

In een LANE-netwerk kan de ATM-switch die de randapparaten ondersteunt, één uitvalpunt zijn voor connectiviteit op de backbone. De Catalyst 6K en 5K bieden OC-12/OC-3 duale sublaag (PHY) uplinemodules voor redundante connectiviteit op ATM-switches stroomafwaarts. De dual-homed LANE modules bieden een "Fibre Distributed Data Interface (FDDI)-achtige" dual-PHY-functie. Deze dubbele PHY uplink-module biedt een primaire en secundaire ATM-interface. Als de primaire interface verbindingsconnectiviteit met de ATM switch verliest, zal de module automatisch de verbinding over aan de secundaire interface switches.

Het wordt ten zeerste aanbevolen dat de netwerkontwerper gebruik maakt van de dubbele PHY-interfaces op de LANE-modules en dubbele gehomeerde uplinks in de kern aan twee verschillende ATM-switches ter beschikking stelt. Hierdoor worden de randapparaten beschermd tegen het falen van één enkele ATM-switch.

Richtsnoer nr. 11

Gebruik FSSRP tenzij de VC-begroting beperkingen heeft.

Aangezien de verschillende LANE-servicecomponenten enkele punten van mislukking in een LANE-netwerk zijn, moeten productienetwerken met redundantie worden ontworpen. Cisco ondersteunt twee redundantiesystemen voor LANE-services: Simple Server Redundancy Protocol (SSRP) en Fast SSRP (FSSRP).

FSSRP is in de meeste gevallen de aanbevolen redundantieregeling. Het voorziet bijna onmiddellijke failover zonder verlies van gegevens, zelfs in grote netwerken. Aan de andere kant zal SSRP resulteren in verlies tijdens een failover, en de hersteltijden kunnen substantieel zijn (soms minuten) in grote netwerken.

Er is één situatie waarin SSRP wordt aanbevolen via FSSRP: wanneer het netwerk met een VC-beperking is verbonden. In tegenstelling tot SSRP houden FSSRP LECs back-upverbindingen met de redundante LES/BUS-paren. U kunt maximaal drie reservekopieën/BUS-paren instellen in vergelijking met een totaal van vier per ELAN. De VC-gebruikstoename die het netwerk onder FSSRP zal ervaren, kan worden berekend met behulp van de volgende formule:

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

Als het netwerk zijn VC-capaciteit bereikt, wordt SSRP daarom aanbevolen via FSSRP. Als u FSSRP gebruikt, moet u het aantal redundante LES/BUS-onderdelen verminderen. In de meeste gevallen biedt een totaal van twee LES/BUS-paren per ELAN een aanvaardbaar evenwicht tussen het gebruik van VC en het elimineren van enkele punten van falen.

Gerelateerde informatie

• HSRP via LANE implementeren
• ATM-ondersteuning - LAN Emulation (LANE)
• ATM algemene informatie
• Technische ondersteuning en documentatie – Cisco Systems