Dit document behandelt algemene en specifieke oorzaken voor langzame prestaties op ATM netwerken en procedures om problemen op te lossen. De focus van dit document is op problemen met IP-prestaties oplossen, specifiek op ATM-netwerken. Meestal worden de prestaties gemeten met behulp van vertraging en doorvoersnelheid. De prestaties worden vaak getest met het gebruik van FTP of andere TCP/IP toepassingen om een bestand tussen twee eindapparaten over te brengen en dan de tijd te meten die nodig is om het bestand over te brengen. Wanneer de doorvoersnelheid die bij de bestandsoverdracht wordt gezien, niet gelijk is aan de bandbreedte die via het ATM-circuit beschikbaar is, wordt dit beschouwd als een prestatiekwestie. Er zijn veel factoren zoals de instellingen van het TCP-venster, MTU, pakketverlies en vertraging die de doorvoersnelheid bepalen die in een ATM-circuit wordt gezien. Dit document behandelt kwesties die de prestaties via ATM routed Virtual Circuits (PVC’s), Switched Virtual Circuits (SVC’s) en LAN Emulation (LANE)-implementaties beïnvloeden. De oorzaak van prestatiekwesties is gemeenschappelijk tussen routed PVC, SVC en LANE implementaties.
Er zijn geen specifieke vereisten van toepassing op dit document.
Dit document is niet beperkt tot specifieke software- en hardware-versies.
Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.
De eerste stap bij het oplossen van een probleem met betrekking tot de prestaties is het selecteren van één bron- en doelapparaten om tussen te testen. Vermeld de omstandigheden waaronder het probleem zich voordoet en de omstandigheden waarin het niet voorkomt. Selecteer testapparaten om de complexiteit van het probleem te verminderen. Bijvoorbeeld, test geen tussen apparaten die tien router behalve zijn als het probleem bestaat wanneer u door twee routers gaat.
Zodra de testapparaten zijn geselecteerd, bepalen of de prestaties gerelateerd zijn aan de inherente aard van TCP toepassingen of of of het probleem veroorzaakt wordt door andere factoren. Tussen eindapparaten pingen om te bepalen of pakketverlies optreedt en de rondreisvertraging voor ping van pakketten. Ping tests moeten met verschillende pakketformaten worden uitgevoerd om te bepalen of de grootte van het pakket van invloed is op het pakketverlies. Ping-tests moeten worden uitgevoerd vanaf de geteste eindapparatuur en niet vanaf routers. De Ronde Trip Time (RTT) die u ziet wanneer u naar en van een router pingt, is mogelijk niet nauwkeurig. Dit is omdat het ping proces een proces met lage prioriteit op de router is en het kan niet onmiddellijk antwoorden pingelen.
Een klant heeft een ATM PVC tussen New York en Los Angeles. Het virtuele circuit (VC) is ingesteld met een vaste celsnelheid (solvabiliteitskapitaalvereiste) van 45 Mbps. De klant test dit circuit door een bestand met FTP-server over te sturen naar een client en ontdekt dat de doorvoersnelheid voor de bestandsoverdracht ongeveer 7,3 Mbps is. Wanneer zij TFTP gebruiken, daalt de doorvoersnelheid tot 58 Kbps. De ping responstijd tussen de client en de server is ongeveer 70 ms.
Het eerste wat in dit voorbeeld te begrijpen is, is dat TCP betrouwbaar transport van gegevens tussen apparaten verschaft. De zender stuurt gegevens in een stream waarin de bytes worden geïdentificeerd door de sequentienummers. De ontvanger erkent dat hij de gegevens heeft ontvangen door het sequentienummer (ontvangstnummer) van de volgende byte van gegevens te verzenden die hij verwacht te ontvangen. De ontvanger adverteert ook zijn venstergrootte aan de afzender om de hoeveelheid gegevens te adverteren die hij kan accepteren.
TCP/IP-eindapparaten bevatten doorgaans de mogelijkheid om de TCP/IP-venstergrootte te configureren.
Als apparaten hun TCP venstergrootte te laag hebben ingesteld, kunnen die apparaten niet de volledige bandbreedte van een ATM VC gebruiken.
RTT op een ATM VC kan de TCP-doorvoersnelheid drastisch verminderen als het venster te klein is.
Een eindapparaat stuurt ongeveer één grootte van het verkeer in bytes per RTT.
Als de RTT bijvoorbeeld 70 ms is, gebruikt u deze formule om de benodigde venstergrootte te berekenen om een gehele DS3 aan bandbreedte op te vullen:
0,07s * 45 Mbps * 1 bytes/8 bits = 393.750 bytes
Standaard TCP maakt een maximale venstergrootte van 64.000 bytes mogelijk. Met de optie WINScale TCP kan de venstergrootte veel hoger zijn als de apparaten op beide eindpunten deze optie ondersteunen en de FTP-toepassing deze optie ook ondersteunt.
Gebruik deze formule om de venstergrootte op 64.000 bytes in te stellen en gebruik de RTT van 70 ms om de doorvoersnelheid op te lossen.
0,07x * 1 bytes/8 bits = 6400 bytes
waarbij x= 7,31428 Mbps
Als de FTP-toepassing alleen een venstergrootte van 32.000 bytes ondersteunt, gebruikt u deze formule.
0,07x * 1 bytes/8 bits = 3200
waarbij x= 3,657142 Mbps
Met TFTP stuurt de afzender 512 byte-pakketten en moet een ontvangstbevestiging voor elk pakket ontvangen voordat zij het volgende pakket verzenden. Het beste case scenario is om elke 70 ms 1 pakket te verzenden. Gebruik deze berekening van de doorvoersnelheid.
1 pakje /.070s = 14.28571 pakketten/seconde
512 bytes/pakket * 8 bits/bytes * 14.28571 pakketten/seconde = 58.514 Kbps
Deze doorvoerberekening laat zien dat de vertraging over een link en de grootte van het TCP-venster de doorvoersnelheid over die link drastisch kunnen beïnvloeden wanneer het TCP/IP-toepassingen gebruikt om doorvoersnelheid te meten. Identificeer de verwachte doorvoersnelheid voor elke TCP-verbinding. Als FTP wordt gebruikt om de doorvoersnelheid te testen, start u meerdere bestandsoverdrachten tussen verschillende klanten en servers om te bepalen of de doorvoersnelheid beperkt is door de inherente aard van TCP/IP of als er andere problemen zijn met het ATM-circuit. Als de TCP-toepassing de doorvoersnelheid beperkt, moet u meerdere servers kunnen hebben die tegelijkertijd en tegen vergelijkbare snelheden verzenden.
Bewijs vervolgens dat u verkeer over de link kunt overbrengen tegen de solvabiliteitstarief van het circuit. Om dit te doen, gebruik een verkeersbron en een verbinding die TCP niet gebruikt en stuur een stroom van gegevens over ATM VC. Controleer ook of het ontvangen tarief gelijk is aan het verzonden tarief. Verzend uitgebreide pingpakketten van een router met een waarde van 0 tijd-uit om verkeer over een circuit van ATM te genereren. Dit bewijst dat u verkeer via de link kunt versturen met de ingestelde snelheid van het circuit.
Oplossing: Vergroot de grootte van het TCP/IP-venster.
Belangrijk: Met een zeer kleine RTT en een venstergrootte die groot genoeg is om theoretisch het solvabiliteitskapitaalvereiste te vullen, zult u nooit het solvabiliteitskapitaalvereiste kunnen bereiken vanwege ATM-overhead. Als u het voorbeeld overweegt van de 512-byte pakketten die over een 4 Mbps (solvabiliteitskapitaalvereiste=PCR) AAL5SNAP PVC worden verzonden, berekent u de echte IP-doorvoersnelheid die wordt gemeten. Het wordt verondersteld de grootte van het TCP venster en RTT zijn van dergelijke aard dat de bron gegevens bij 4 Mbps kan verzenden. Eerst en vooral, introduceren ATM Adapter Layer 5 (AAL5) en SNAP elke 8 bytes overhead. Om deze reden kan het nodig zijn om de AAL5 protocol gegevens unit (PDU) aan te vullen om er zeker van te zijn dat de AAL5 protocol gegevens unit (PDF) met 48 gedeeld kan worden. Vervolgens wordt in elke cel 5 bytes overhead per cel geïntroduceerd. In dit geval betekent het dat de AAL5-laag 512+8+8=528 bytes (niet nodig om de lens op te vullen) is. Deze 528 bytes vereisen dat 11 cellen worden overgedragen. Dit betekent dat voor elk pakket van 512 bytes dat moet worden verzonden, 583 bytes op de draad worden verzonden (11 * 53). Met andere woorden, er worden 71 bytes overhead geïntroduceerd. Dit betekent dat slechts 88% van de bandbreedte door de IP-pakketten kan worden gebruikt. Daarom betekent het, met het 4 Mbps PVC, dat de bruikbare IP-doorvoersnelheid slechts 3,5 Mbps is.
Hoe kleiner de pakketgrootte, hoe groter de overhead en hoe lager de doorvoersnelheid.
De meest voorkomende reden voor prestatieproblemen is het gevolg van pakketverlies via ATM-circuits. Elk celverlies via een ATM-circuit leidt tot verslechtering van de prestaties. Packet loss betekent hertransmissie en ook vermindering van de TCP-venstergrootte. Dit resulteert in een lagere doorvoersnelheid. Normaal gesproken identificeert een eenvoudige ping-test of er tussen de twee apparaten pakketten verloren zijn gegaan. Cyclic overtollige controles (CRC) fouten en cel/pakketdalingen op ATM-circuits resulteren in het opnieuw verzenden van gegevens. Als ATM-cellen door een ATM-schakelaar worden verwijderd vanwege toezicht of bufferuitputting, worden CRC-fouten gezien op het eindapparaat wanneer de cellen in pakketten worden geherassembleerd. ATM edge-apparaten kunnen pakketten laten vallen of vertragen wanneer de uitgaande pakketsnelheid op een VC hoger is dan de ingesteld traffic shaping-snelheid op de VC.
Zie deze documenten voor meer informatie over het oplossen van de meest gebruikelijke oorzaken van pakketverlies via ATM-netwerken:
Invoerdruppels voor probleemoplossing op ATM-routerinterfaces
De betekenis van afgekeurde/afgedankte celtellers op ATM-switchrouters
Oplossing: Probleemoplossing en elk pakketverlies verwijderen.
De hoeveelheid tijd die het kost voor een pakje om van bron naar bestemming te reizen, en dan voor een ontvangstbevestiging om naar de zender terug te keren, kan de doorvoersnelheid die over dat circuit wordt gezien drastisch beïnvloeden. De vertraging in een ATM-circuit kan het gevolg zijn van een normale transmissievertraging. Het kost minder tijd om een pakketje van New York naar Washington te sturen dan van New York naar Los Angeles wanneer het ATM-circuit dezelfde snelheid heeft. Andere bronnen voor vertraging zijn het in de wachtrij stellen van vertraging door routers en switches en de verwerkingsvertraging door Layer 3-routingapparaten. De verwerkingsvertraging die aan routingapparaten is gekoppeld, is sterk afhankelijk van het gebruikte platform en het switchpad. De details verbonden met de routingvertraging en interne hardwarevertraging vallen buiten het bereik van dit document. Deze vertraging heeft invloed op elke router, ongeacht de interfacetypen. Het is ook verwaarloosbaar in vergelijking met de vertraging die gepaard gaat met het verzenden van pakketten en het in de wachtrij plaatsen. Als een router echter overstapverkeer verwerkt, kan dit leiden tot een aanzienlijke vertraging en moet hiermee rekening worden gehouden.
De vertraging wordt gewoonlijk gemeten door tussen de eindapparaten pakketten te pingelen om de gemiddelde en maximale retourvertraging te bepalen. Tijdens het piekgebruik en tijdens perioden van inactiviteit moeten vertragingsmetingen worden uitgevoerd. Dit helpt om te bepalen of de vertraging kan worden toegeschreven aan wachtvertraging op verstopte interfaces.
Congestie van interfaces leidt tot een wachttijd. Congestion is doorgaans het resultaat van bandbreedte-onovereenkomsten. Als u bijvoorbeeld een circuit via een ATM-switch hebt dat stappen van een OC-12-interface naar een DS3 ATM-interface doorvoert, dan kan dit een wachtvertraging veroorzaken. Dit gebeurt wanneer cellen sneller op de OC-12 interface aankomen dan ze op de DS3 interface kunnen worden uitgevoerd. ATM scherpste routers die voor traffic shaping zijn geconfigureerd, beperken het tempo waarin zij verkeer op de interface uitvoeren. Als het aankomstpercentage van verkeer dat bestemd is voor ATM VC groter is dan de traffic shapingssnelheden op de interface, dan worden de pakketten/cellen in de wachtrij op de interface geplaatst. Meestal is de vertraging die door de wachttijd wordt geïntroduceerd de vertraging die prestatiekwesties veroorzaakt.
Oplossing: Voer IP-naar-ATM serviceklasse (CoS) in voor gedifferentieerde service. Gebruik functies zoals Class Based Weighted Fair Queuing (CBWFQ) en Low Latency Queuing (LLQ) om vertragingen voor missie-cruciaal verkeer te verminderen of voorkomen. Vergroot de bandbreedte van virtuele circuits om congestie te voorkomen.
ATM PVC’s en SVC’s hebben QoS-parameters (Quality of Service) die aan elk circuit zijn gekoppeld. Er wordt een verkeerscontract opgesteld tussen het ATM-randapparaat en het netwerk. Wanneer PVC’s worden gebruikt, wordt dit contract handmatig ingesteld in het ATM-netwerk (ATM-switches). Met SVC’s wordt ATM-signalering gebruikt om dit contract op te zetten. ATM scherpste apparaten van de verkeersvorm om met het gespecificeerde contract in overeenstemming te zijn. ATM Network Devices (ATM-switches) monitort het verkeer op het circuit om te voldoen aan het opgegeven contract- en tag-verkeer (markering) of verwerp (politie) dat niet conform is.
Als een ATM-randapparaat Peak Cell Rate (PCR)/SKF heeft ingesteld voor een hogere snelheid dan is voorzien in het netwerk, is pakketverlies een waarschijnlijk resultaat. De traffic shaping-snelheden die op het randapparaat zijn ingesteld, moeten overeenkomen met de formaten end-to-end door het netwerk. Controleer dat de configuratie door alle geconfigureerde apparaten overeenkomt. Als het randapparaat cellen naar het netwerk stuurt die niet in overeenstemming zijn met het contract dat voor levering is voorzien door het netwerk, worden de cellen die binnen het netwerk worden weggegooid, doorgaans gezien. Dit kan meestal worden gedetecteerd door ontvangst van CRC-fouten aan het eind wanneer de ontvanger probeert het pakket opnieuw te assembleren.
Een ATM-randapparatuur met een PCR/solvabiliteitsclassificatie die is ingesteld voor een lagere snelheid dan die welke is voorzien in het netwerk veroorzaakt verminderde prestaties. In deze situatie wordt het netwerk geconfigureerd om meer bandbreedte te bieden dan het randapparaat verstuurt. Deze voorwaarde kan resulteren in extra wachtrijen vertraging en zelfs daling van de uitvoerwachtrij op de noodopdracht van ATM.
SVC’s worden op de randapparatuur geconfigureerd, maar het netwerk kan niet de SVC end-to-end met dezelfde verkeersparameters instellen. Dezelfde concepten en problemen zijn van toepassing op SVC’s die van toepassing zijn op PVC’s. Het netwerk kan de SVC end-to-end met dezelfde QoS-klassen en -parameters niet instellen. Dit soort problemen wordt doorgaans veroorzaakt door problemen met een bug of interoperabiliteit. Wanneer een SVC wordt gesignaleerd, specificeert de oproepende partij de QoS traffic shaping-parameters in de voorwaartse en achterwaartse richting. Het kan voorkomen dat de opgeroepen partij de SVC niet met de juiste vormparameters installeert. De configuratie van Streng Traffic Shaping op routerinterfaces kan verhinderen dat SVC’s worden ingesteld met vormgevende parameters die niet worden geconfigureerd.
De gebruiker moet het pad van de SVC via het netwerk overtrekken en controleren of dit met het gebruik van de QoS-klasse en de parameters die op het oorspronkelijke apparaat zijn ingesteld, is ingesteld.
Oplossing: Vermijd traffic shaping/policy-configuratiefouten. Als SVC’s worden gebruikt, controleert u of deze instellingen end-to-end zijn met de juiste vormgevings-/controleparameters. Configureer strikte traffic shaping op ATM-routerinterfaces met de ATM sig-traffic-shaping strikte opdracht.
SVC’s die voor UBR (Unfied Bit Rate) zijn ingesteld, kunnen via niet-optimale paden worden ingesteld. Een UBR VC is beperkt in bandbreedte tot het lijntarief van de koppelingen die VC verplaatsen. Daarom, als een hogesnelheidslijn naar beneden zou gaan, kunnen de VC's die die verbinding verplaatsen zich over een langzamere verbinding herstellen. Zelfs wanneer de snelle verbinding wordt hersteld, worden de VC's niet afgebroken en opnieuw ingesteld via de snellere verbinding. Dit komt doordat het tragere pad voldoet aan de gevraagde (niet-gespecificeerde) QoS-parameters. Dit probleem komt zeer vaak voor in LANE-netwerken die alternatieve paden door het netwerk hebben. In gevallen waarin de alternatieve paden dezelfde koppelingssnelheid hebben, veroorzaakt het falen van een van de koppelingen dat alle SVC's over hetzelfde pad worden routeerd. Deze situatie kan de doorvoersnelheid en prestaties van het netwerk drastisch beïnvloeden aangezien de effectieve bandbreedte van het netwerk in tweeën wordt verminderd.
Zelfs Variable Bit Rate (VBR) en Constant Bit Rate (CBR) SVC’s kunnen via niet-optimale paden worden uitgevoerd. Eindapparaten vragen om specifieke verkeersparameters (PCR, solvabiliteitskapitaalvereiste, maximale barstgrootte {MBS}). Het doel van Private Network-Network Interface (PNNI) en ATM-signalering is een pad te bieden dat voldoet aan de QoS-vereisten van het verzoek. In het geval van CBR- en VBR-rt-oproepen omvat dit ook de maximale celoverdrachtvertraging. Een pad kan voldoen aan de vereisten die door de verzoeker vanuit het bandbreedtepunt-van-mening worden gespecificeerd, maar niet het optimale pad zijn. Dit probleem is gebruikelijk wanneer er paden met langere vertraging zijn die nog steeds voldoen aan de bandbreedtevereisten voor VBR en CBR VC’s. Dit kan worden gezien als een prestatieprobleem voor de klant die nu grotere vertragingskenmerken over het netwerk ziet.
Oplossing: SVC’s in een ATM-netwerk worden op aanvraag ingesteld en worden doorgaans niet afgekoppeld en via een ander pad omgeleid, tenzij de SVC wordt afgebroken (wegens inactiviteit of om andere redenen vrijgelaten). Cisco LightStream 1010 en Catalyst 8500 ATM-switches bieden de optimaliseringsfunctie voor zachte PVC-route. Deze optie biedt de mogelijkheid om een zacht PVC dynamisch te omleiden wanneer er een betere route beschikbaar is. Een soortgelijke functionaliteit is niet beschikbaar voor SVC’s die niet op de ATM-switches eindigen.
Eén mogelijke oplossing voor dit probleem is het gebruik van PVC’s tussen de ATM-randapparaten en de aangesloten ATM-switches. Zachte PVC’s met routeoptimalisatie tussen ATM-switches bieden de mogelijkheid om het verkeer te verplaatsen van niet-optimale paden na een koppelingsstoring en een opvolgend herstel.
Configureer het tussenkomst van de inactiviteitstimer voor SVC’s laag zodat deze vaker worden afgebroken en opnieuw worden geïnstalleerd. Gebruik de opdracht Ongebruikte seconden [minimum tarief] om de hoeveelheid tijd en verkeerssnelheden te veranderen die ervoor zorgen dat de SVC wordt afgebroken. Dit kan niet zeer effectief blijken aangezien de VC inactief moet zijn om over het optimale pad te worden gerenommeerd.
Als al het andere mislukt, zorg er dan voor dat het optimale pad is hersteld tot gebruik en stoot dan een van de ATM interfaces gekoppeld aan het langzame overbodige pad of een van de routerinterfaces die de SVC beëindigen.
De architectuur van de PA-A1 ATM poortadapter en het gebrek aan treingeheugen kunnen leiden tot verminderde prestaties. Dit probleem kan zich in abort, overschrijding, onwetendheid, en CRCs op de interface manifesteren. Het probleem wordt verergerd wanneer het wordt gebruikt met een Cisco 7200 router met NPE-100/175/225/300.
Raadpleeg Invoerfouten voor probleemoplossing op PA-A1 ATM-poortadapters voor extra informatie.
Oplossing: Vervang PA-A1 ATM-poortadapters met PA-A3 (ten minste herziening 2) of PA-A6 ATM-poortadapters.
Met de PA-A3 hardware reassembleert u cellen niet in pakketten die het onboard statische RAM (SRAM) op de poortadapter gebruiken. De adapter stuurt de cellen over de PCI-bus (randcomponent interconnect) naar het woekerinterfaceprocessor (VIP) of Network Processing Engine (NPE) host-geheugen waar deze de pakketten opnieuw assembleert. Dit resulteert in soortgelijke prestatiegerelateerde problemen als die gezien worden met de PA-A1 ATM poortadapter.
Raadpleeg I/O-fouten bij het opsporen en verhelpen van problemen bij PA-A3 ATM-poortadapters voor meer informatie.
Oplossing: Vervang PA-A3 hardware-revisie 1 ATM-poortadapters met PA-A3 (minstens revisie 2) of PA-A6 ATM-poortadapters.
De PA-A3-OC3SMM, PA-A3-OC3SMI en PA-A3-OC3SML zijn ontworpen om maximale switchprestaties te bieden wanneer één poortadapter in één VIP2-50 is geïnstalleerd. Eén PA-A3-OC3SMM, PA-A3-OC3SMI of PA-A3-OC3SML in een VIP-2 50 biedt in elke richting tot ongeveer 85.000 pakketten per seconde van de switchcapaciteit met behulp van 64 bytes. Merk op dat één PA-A3-OC3SMM, PA-A3-OC3SMI of PA-A3-OC3SML alleen de gehele switchcapaciteit van één VIP2-50 kan gebruiken.
Voor toepassingen waarvoor maximale poortdichtheid of lagere systeemkosten vereist zijn, worden de configuraties van de dubbele poortadapter met de OC-3/STM-1 versie van de PA-A3 in dezelfde VIP2-50 nu ondersteund. De twee poortadapters in dezelfde VIP2-50 delen ongeveer 95.000 pakketten per seconde van switchcapaciteit in elke richting met 64 byte-pakketten.
De VIP-50 biedt tot 400 megabits per seconde (mbps) van totale bandbreedte afhankelijk van de combinaties van poortadapter. In de meeste configuraties van de poortadapter met de PA-A3-OC3SMM, PA-A3-OC3SMI of PA-A3-OC3SML overschrijdt de combinatie van poortadapters deze totale bandbreedtecapaciteit.
Bijgevolg worden de prestaties gedeeld tussen de twee poortadapters die in dezelfde VIP2-50 zijn geïnstalleerd, beperkt door de totale switchcapaciteit (95 kpps) bij kleine pakketformaten en door de totale bandbreedte (400 mbps) bij grote pakketformaten.
Deze prestatie-voorbehouden moeten in overweging worden genomen wanneer u ATM-netwerken aanwijst met de PA-A3-OC3SMM, PA-A3-OC3SMI of PA-A3-OC3SML. Afhankelijk van het ontwerp kunnen de prestaties van dubbele poortadapters in dezelfde VIP2-50 al dan niet aanvaardbaar zijn.
Raadpleeg PA-A1- en PA-A3 VIP2-configuraties die worden ondersteund voor extra informatie.
Overmatige aantallen eindsystemen in één LANE-ELAN kunnen de prestaties van alle eindstations aanzienlijk bemoeilijken. Een ELAN vertegenwoordigt een uitgezonden domein. Alle werkstations en servers in het ELAN ontvangen uitzending en mogelijk multicast verkeer van alle andere apparaten in het ELAN. Als het uitzendverkeer hoog is in verhouding tot de verwerkingscapaciteit van het werkstation, lijdt de prestatie van de werkstations onder.
Oplossing: Beperk het aantal eindstations binnen één enkele LAN tot minder dan 500. Controleer het netwerk voor Broadcast/Multicast-stormen die de prestaties van de server/werkstations negatief kunnen beïnvloeden.
Raadpleeg de LANE Design Aanbevelingen voor aanvullende informatie.
Andere problemen die tot slechte prestaties in een netwerk van LANE kunnen leiden zijn overdreven activiteit LANE ARP (LE-ARP) en de veranderingen van de Spanning Tree Topologie. Deze problemen leiden tot onopgeloste LE-ARP’s die leiden tot verkeer dat over de bus wordt verstuurd. Dit kan ook leiden tot een hoog CPU-gebruik op de LEC's in het netwerk, wat ook prestatiegerelateerde problemen kan veroorzaken. Meer informatie over deze problemen kunt u vinden in Spanning-Tree tegen LANE bij Problemen oplossen.
Configuratie van Spanning Tree PortFast op de host-poorten van LANE verbonden Ethernet-switches om Spanning Tree Topologie-wijzigingen te beperken. Configureer de lokale LE-ARP-herverificatie op Catalyst 5000 en 6000 switches die voor LANE zijn geconfigureerd om LE-ARP-verkeer te verminderen.
Met behulp van LANE versie 1 worden SVC’s ingesteld als UBR-servicecategorie. LANE versie 2 ondersteunt de mogelijkheid om directe SVC’s in te stellen met behulp van andere servicecategorieën zoals VBR-NRTT. Een derde verkoper heeft een bug in hun LANE-clientimplementatie die ervoor kan zorgen dat de Data Direct SVC’s die zijn ingesteld op Cisco-apparaten VBR-NRTT zijn met een solvabiliteitsclassificatie van 4 Kbps. Als uw ATM-backbone bestaat uit OC-3 (155 Mbps) en OC-12 (622 Mbps) koppels en u stelt SVC in op die stammen met een permanent celtarief van 4 Kbps, dan lijdt uw prestaties onder. Hoewel dit specifieke probleem niet gebruikelijk is, wijst het op een belangrijke behoefte wanneer u problemen met de prestaties via ATM-circuits oplost. U moet het pad volgen dat uw SVC’s door het netwerk verplaatsen en bevestigen dat de VC’s met de gewenste servicecategorie en verkeersparameters zijn ingesteld.
LANE Data Direct VC’s zijn bidirectionele point-to-point SVC’s die worden ingesteld tussen twee LAN Emulation Clients (LEC’s) en worden gebruikt voor de uitwisseling van gegevens tussen deze clients. LANE klanten verzenden LE-ARP verzoeken om de ATM adressen te leren die met een adres van MAC verbonden zijn. Vervolgens proberen zij een Direct VC-gegevensbank op dat ATM-adres op te zetten. Vóór de oprichting van Data Direct VC overspoelen LANE-cliënten onbekende eenpakketten naar de Broadcast en Onbekende Server (BUS). Een LANE-client kan er niet in slagen een Data Direct VC aan een andere LEC op te zetten met het oog op het verzenden van eenastgegevens. Als dit gebeurt, kan dit leiden tot verslechtering van de prestaties. Het probleem is aanzienlijk als het apparaat dat is gekozen om de BUS-services uit te voeren niet beschikt over voldoende voeding, capaciteit of overbelasting. Bovendien kunnen sommige platformen limietberichten invoeren die naar de BUS worden doorgestuurd. De Catalyst 2900XL LANE module is zo'n doos dat het eenastverkeer verstikt dat naar de BUS wordt verzonden terwijl Catalyst 5000 en Catalyst 6000 dat niet doen.
De Data Direct SVC kan om één van deze redenen niet worden vastgesteld of gebruikt:
LEC ontvangt geen antwoord op het LE-ARP verzoek.
De SVC kan niet worden gemaakt vanwege problemen met ATM-routing of -signalering.
LANE Flush Message Protocol-storing. Zodra de Data Direct VC is opgericht, stuurt de LEC een Flush-verzoek op de Muticast Send VC om ervoor te zorgen dat alle gegevensframes die via de BUS zijn verzonden, hun bestemming hebben bereikt. Wanneer de LEC die het Flush-verzoek heeft verstuurd, een respons ontvangt, stuurt zij gegevens via de Data Direct VC. Het Flush mechanisme kan worden uitgeschakeld met de opdracht zonder lane client spoelen.
UBR VC’s op Inverse Multiplexing (IMA)-interfaces worden ingesteld met een PCR van 1,5 Mbps in plaats van de som van alle omhoog/omhoog fysieke interfaces die in de IMA-groep zijn geconfigureerd. Deze voorwaarde ondergraaft de prestaties omdat de VC traffic shaping is met een lagere snelheid dan de gecombineerde bandbreedte van alle koppelingen in de IMA-groep.
Oorspronkelijk was de bandbreedte van een IMA-groepsinterface beperkt tot het minimum aantal actieve IMA-koppelingen dat nodig was om de IMA-interface omhoog te houden. De opdracht om deze waarde te definiëren is IMA actief-links-minimum. Bijvoorbeeld, als vier fysieke ATM interfaces als leden van IMA groep nul worden gevormd en de IMA actief-links-minimum waarde wordt ingesteld op één, is de bandbreedte gelijk aan één T1 of 1,5 Mbps, niet 6 Mbps.
Cisco bug-ID CSCdr12395 (alleen geregistreerde klanten) verandert dit gedrag. De PA-A3-8T1IMA-adapter gebruikt nu de bandbreedte van alle omhoog/omhoog ATM fysieke interfaces die als IMA-groepsleden zijn geconfigureerd.
Cisco bug-IDs CSCdt67354 (alleen geregistreerde klanten) en CSCdv67523 (alleen geregistreerde klanten) zijn volgende verbeteringsverzoeken om de bandbreedte van IMA-groep te bijwerken wanneer een interface wordt toegevoegd of verwijderd uit de IMA-groep, dicht/nee of bellen vanwege een tekort koppelingsfout of wijziging aan het afstandseinde. De veranderingen die in Cisco bug IDCSCdr12395 (alleen geregistreerde klanten) zijn geïmplementeerd, vormen de bandbreedte van de IMA-groep tot de totale bandbreedte van de koppelingen van zijn leden alleen wanneer de IMA-groep oploopt. Wijzigingen in de IMA-groep na de initiële omhoog status worden niet weerspiegeld.
Raadpleeg ATM-links voor probleemoplossing in de 7x00 IMA-poortadapter voor extra informatie.