Best practices voor Catalyst 4500/4000, 5500/5000 en 6500/6000 Series Switches met CatOS-configuratie en -beheer

Inleiding

Dit document bespreekt de implementatie van Cisco Catalyst 6000 Series switches in uw netwerk, met name de Catalyst 4500/4000, 5500/5000 en 6500/6000 platforms. Configuraties en opdrachten worden besproken in de veronderstelling dat u Catalyst OS (CatOS) General Implementatiesoftware 6.4(3) of hoger gebruikt. Hoewel sommige ontwerpoverwegingen worden voorgesteld, behandelt dit document geen algemeen campusontwerp.

Voorwaarden

Vereisten

Dit document veronderstelt vertrouwdheid met Catalyst 6500 Series opdrachtreferentie, 7.6.

Hoewel in het document wordt verwezen naar openbaar online materiaal voor verdere lezing, zijn dit andere basale en educatieve referenties:

• Cisco IPS Essentials - Essentiële IOS-functies die elke ISP moet overwegen.

• Richtlijnen voor Cisco-netwerkbewaking en -correlatie

• Gigabit Campus-netwerkontwerp—Principles en architectuur

• Cisco SAFE: Een security blauwdruk voor ondernemingsnetwerken

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Achtergrondinformatie

Deze oplossingen vertegenwoordigen jaren praktijkervaring van Cisco-engineers die met veel van onze grootste klanten en complexe netwerken werken. Daarom benadrukt dit document configuraties in de echte wereld die netwerken succesvol maken. Dit artikel biedt de volgende oplossingen:

• Oplossingen die statistisch de breedste blootstelling aan het veld en dus het laagste risico hebben.

• Oplossingen die eenvoudig zijn en enige flexibiliteit inruilen voor deterministische resultaten.

• Oplossingen die eenvoudig te beheren en geconfigureerd zijn door netwerkoperatieteams.

• Oplossingen die hoge beschikbaarheid en hoge stabiliteit bevorderen.

Dit document bestaat uit de volgende vier delen:

• Basis Configuration— functies die door een meerderheid van netwerken worden gebruikt, zoals Spanning Tree Protocol (STP) en trunking.

• Management Configuration - ontwerpoverwegingen samen met systeem- en gebeurtenisbewaking met Simple Network Management Protocol (SNMP), Remote Monitoring (RMON), Syslog, Cisco Discovery Protocol (CDP) en Network Time Protocol (NTP).

• Beveiligingsconfiguratie— wachtwoorden, poortbeveiliging, fysieke beveiliging en verificatie met behulp van TACACS+.

• Configuration Checklist— samenvatting van voorgestelde configuratiesjablonen.

Basisconfiguratie

De eigenschappen die met de meerderheid van Catalyst-netwerken worden geïmplementeerd, worden in deze sectie besproken.

Catalyst Control Plane-protocollen

Deze sectie introduceert de protocollen die tussen switches bij normaal gebruik lopen. Een fundamenteel begrip van deze protocollen is nuttig bij het aanpakken van elke sectie.

Supervisor verkeer

De meeste eigenschappen die in een netwerk van Catalyst worden toegelaten vereisen twee of meer switches om samen te werken, zodat moet er een gecontroleerde uitwisseling van keepalive berichten, configuratieparameters, en beheersveranderingen zijn. Of deze protocollen nu bedrijfseigen zijn van Cisco, zoals CDP, of op standaarden gebaseerde protocollen zoals IEEE 802.1d (STP), ze hebben alle bepaalde elementen gemeen wanneer ze op de Catalyst-serie worden geïmplementeerd.

In het basisframe-doorsturen, komen gebruikersgegevenskaders voort uit eindsystemen, en hun bronadres en bestemmingsadres worden niet veranderd door Layer 2 (L2) switched domeinen. Content Adressable Memory (CAM) lookup-tabellen op elke switch Supervisor Engine worden bevolkt door een bronadres leerproces en geven aan welke uitgang poort elk ontvangen frame moet doorsturen. Als het proces van het adresleren onvolledig is (de bestemming is onbekend of het kader is bestemd voor een uitzending of een multicast adres), door:sturen het (overstroomd) uit alle poorten in dat VLAN.

De switch moet ook herkennen welke frames via het systeem moeten worden geschakeld en welke naar de switch CPU zelf moeten worden geleid (ook bekend als de Network Management Processor [NMP]).

Het Catalyst-besturingsplane wordt gemaakt met behulp van speciale vermeldingen in de CAM-tabel die systeemvermeldingen worden genoemd om verkeer naar de NMP op een switch-poort te ontvangen en te leiden. Aldus, door protocollen met de bekende adressen van bestemmingsMAC te gebruiken, kan het verkeer van het controlevliegtuig van het gegevensverkeer worden gescheiden. Geef CAM systeemopdracht uit op een switch om dit te bevestigen, zoals getoond:

>show cam system

* = Static Entry. + = Permanent Entry. # = System Entry. R = Router Entry.
X = Port Security Entry
VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type]
----  ------------------    -----  -------------------------------------------
1     00-d0-ff-88-cb-ff  #          1/3

!--- NMP internal port.

1     01-00-0c-cc-cc-cc  #          1/3

!--- CDP and so on.

1     01-00-0c-cc-cc-cd  #          1/3

!--- Cisco STP.

1     01-80-c2-00-00-00  #          1/3

!--- IEEE STP.

1     01-80-c2-00-00-01  #          1/3

!--- IEEE flow control.

1     00-03-6b-51-e1-82 R#          15/1

!--- Multilayer Switch Feature Card (MSFC) router.

...

Cisco heeft een gereserveerde reeks Ethernet MAC- en protocoladressen, zoals getoond. Elke wordt behandeld later in dit document. In deze tabel is echter een samenvatting opgenomen.

De meerderheid van Cisco-controleprotocollen gebruikt een IEEE 802.3 SNAP-inkapseling, inclusief LLC 0xAAA03, OUI 0x00000C, die op een LAN-analysatorspoor kan worden gezien. Andere gemeenschappelijke eigenschappen van deze protocollen omvatten:

• Deze protocollen gaan uit van point-to-point connectiviteit. Merk op dat het welbewuste gebruik van multicast bestemmingsadressen twee Catalyst in staat stelt om transparant te communiceren over switches die niet van Cisco zijn, aangezien apparaten die de frames niet begrijpen en onderscheppen ze gewoon overstromen. Point-to-multipoint verbindingen door omgevingen met meerdere leveranciers kunnen echter leiden tot inconsistent gedrag en moeten over het algemeen worden vermeden.

• Deze protocollen eindigen op Layer 3 (L3) routers; zij werken alleen binnen een switch.

• Deze protocollen ontvangen prioritering over gebruikersgegevens door toegangsapplicatie-specifieke verwerking en planning van geïntegreerde schakelingen (ASIC's).

Na de introductie van de doeladressen van het controleprotocol moet het bronadres ook volledig worden beschreven. Switch-protocols gebruiken een MAC-adres dat afkomstig is van een bank met beschikbare adressen die door een EPROM op het chassis zijn verstrekt. Geef het bevel van de showmodule uit om de adresbereiken te tonen beschikbaar aan elke module wanneer het verkeer zoals STP brug protocol data units (BPDUs) of ISL frames bronst.

>show module

...
Mod MAC-Address(es)                        Hw     Fw         Sw
--- -------------------------------------- ------ ---------- -----------------
1   00-01-c9-da-0c-1e to 00-01-c9-da-0c-1f 2.2    6.1(3)     6.1(1d)
    00-01-c9-da-0c-1c to 00-01-c9-da-0c-1
    00-d0-ff-88-c8-00 to 00-d0-ff-88-cb-ff

!--- MACs for sourcing traffic.

...
VLAN 1

VLAN 1

VLAN 1 heeft een speciale betekenis in Catalyst-netwerken.

De Catalyst Supervisor Engine gebruikt altijd de standaard VLAN, VLAN 1, om een aantal controle- en beheerprotocollen te taggen tijdens trunking, zoals CDP, VTP en PAgP. Alle poorten, inclusief de interne sc0-interface, zijn standaard geconfigureerd om lid te zijn van VLAN 1. Alle trunks dragen standaard VLAN 1, en in CatOS-softwareversies eerder dan 5.4 was het niet mogelijk om gebruikersgegevens in VLAN 1 te blokkeren.

Deze definities zijn nodig om een aantal goed gebruikte termen in Catalyst-netwerken te helpen verduidelijken:

• Het beheer VLAN is waar sc0 verblijft; dit VLAN kan worden gewijzigd.

• Inheems VLAN wordt gedefinieerd als VLAN waarnaar een poort terugkeert wanneer er geen trunking is en het niet-gelabelde VLAN op een 802.1Q-trunk is. Standaard is VLAN 1 het native VLAN.

• Om inheems VLAN te veranderen, geef het vastgestelde bevel van VLAN-ID mod/port uit.

  Opmerking: Maak het VLAN voordat u het instelt als het native VLAN van de trunk.

Dit zijn verschillende goede redenen om een netwerk af te stemmen en het gedrag van poorten in VLAN 1 te wijzigen:

• Wanneer de diameter van VLAN 1, zoals een ander VLAN, groot genoeg wordt om een risico voor stabiliteit te zijn (in het bijzonder vanuit een perspectief STP) moet het worden teruggesnoeid. Dit wordt in de sectie In-Band Management van dit document meer in detail besproken.

• De besturingsplanegegevens op VLAN 1 moeten gescheiden worden gehouden van de gebruikersgegevens om het oplossen van problemen te vereenvoudigen en de beschikbare CPU-cycli te maximaliseren.

• L2-lijnen in VLAN 1 moeten worden vermeden wanneer netwerken op meerdere lagen-campus worden ontworpen zonder STP, en trunking is nog steeds vereist op de toegangslaag als er meerdere VLAN’s en IP-subnetten zijn. Om dit te doen, wissen we handmatig VLAN 1 van trunkpoorten.

Samenvattend, noteer deze informatie over trunks:

• CDP-, VTP- en PAgP-updates worden altijd op trunks doorgestuurd met een VLAN 1-tag. Dit is het geval zelfs als VLAN 1 van de trunks wordt ontruimd en niet inheems VLAN is. Als VLAN 1 wordt ontruimd voor gebruikersgegevens, is dit geen invloed op het verkeer van het controlevliegtuig dat nog het gebruiken VLAN 1 wordt verzonden.

• Op een ISL-trunk worden DTP-pakketten verzonden op VLAN1. Dit is het geval, zelfs als VLAN 1 is gewist uit de trunk en niet langer het native VLAN is. Op een 802.1Q trunk worden DTP-pakketten verzonden op het native VLAN. Dit is het geval zelfs als inheems VLAN wordt ontruimd uit de trunk.

• In PVST+ worden de 802.1Q IEEE BPDU's doorgestuurd zonder tag op de gemeenschappelijke Spanning Tree VLAN 1 voor interoperabiliteit met andere leveranciers, tenzij VLAN 1 uit de trunk is gewist. Dit is het geval ongeacht de native VLAN-configuratie. Cisco PVST+ BPDU’s worden verzonden en getagd voor alle andere VLAN’s. Raadpleeg het gedeelte Spanning Tree Protocol in dit document voor meer informatie.

• 802.1s MST (Multiple Spanning Tree) BPDU’s worden altijd op VLAN 1 op zowel ISL- als 802.1Q-trunks verzonden. Dit is zelfs van toepassing wanneer VLAN 1 uit de trunks wordt gewist.

• Schakel VLAN 1 niet uit op trunks tussen MST-bruggen en PVST+-bruggen. Maar in het geval dat VLAN 1 is uitgeschakeld, moet de MST-brug wortel worden zodat alle VLAN’s voorkomen dat de MST-brug zijn grenspoorten in de root-inconsistente staat zet. Zie Meervoudige Spanning Tree Protocol (802.1s) voor meer informatie.

Aanbevelingen

Om VLAN in een up/up-staat te houden zonder clients of hosts die in dat VLAN zijn aangesloten, moet u ten minste één fysiek apparaat hebben dat in dat VLAN is aangesloten. Anders heeft VLAN een omhoog/omlaag status. Momenteel is er geen opdracht om een VLAN-interface omhoog/omhoog te zetten wanneer er geen actieve poorten in de switch zijn voor dat VLAN.

Als u geen apparaat wilt aansluiten, sluit u een loopback-stekker aan op een willekeurige poort voor dat VLAN. Als alternatief, probeer een oversteekplaatskabel die twee poorten in dat VLAN op de zelfde switch verbindt. Deze methode dwingt de poort omhoog. Raadpleeg het gedeelte Loopback Plug van Loopback Tests voor T1/56K Lines voor meer informatie.

Wanneer een netwerk aan dienstverleners multihomed is, handelt het netwerk als een transitnetwerk tussen twee dienstverleners. Als het VLAN-nummer dat in een pakket wordt ontvangen, moet worden vertaald of gewijzigd wanneer het wordt doorgegeven van de ene serviceprovider naar een andere serviceprovider, is het raadzaam de QinQ-functie te gebruiken om het VLAN-nummer te vertalen.

VLAN-trunkingprotocol

Voordat u VLAN’s maakt, bepaalt u de VTP-modus die in het netwerk moet worden gebruikt. VTP maakt het mogelijk dat de wijzigingen in de VLAN-configuratie centraal op een of meer switches worden aangebracht. Die veranderingen komen automatisch naar alle andere switches in het domein.

Operationeel overzicht

VTP is een L2-berichtenprotocol dat de VLAN-configuratiestatus behoudt. VTP beheert de toevoeging, verwijdering en hernoeming van VLAN’s op netwerkbrede basis. VTP minimaliseert foutenconfiguraties en configuratieinconsistenties die een aantal problemen kunnen veroorzaken, zoals dubbele VLAN-namen, onjuiste VLAN-type specificaties en beveiligingsschendingen. De VLAN-database is een binair bestand en wordt afzonderlijk van het configuratiebestand opgeslagen in NVRAM op VTP-servers.

Het VTP-protocol communiceert tussen switches met behulp van een Ethernet-doelmulticast MAC-adres (01-00-0c-cc-cc-cc) en SNAP HDLC-protocoltype Ox2003. Het werkt niet via niet-trunkpoorten (VTP is een payload van ISL of 802.1Q), dus berichten kunnen niet worden verzonden tot DTP de trunk online heeft gebracht.

Berichttypes omvatten summiere advertenties om de vijf minuten, subset advertenties en aanvraagadvertenties wanneer er veranderingen zijn, en treedt toe wanneer het snoeien VTP is ingeschakeld. Het aantal van de VTP- configuratierevisie wordt verhoogd door met elke verandering op een server, die dan de nieuwe lijst over het domein verspreidt.

Als een VLAN wordt verwijderd, worden poorten die ooit lid waren van dat VLAN in een inactieve staat geplaatst. Op dezelfde manier als een switch in de clientmodus de VTP VLAN-tabel niet kan ontvangen bij het opstarten (vanaf een VTP-server of een andere VTP-client), worden alle poorten in VLAN’s anders dan de standaard VLAN-1 gedeactiveerd.

Deze tabel biedt een vergelijkende samenvatting van de functies voor verschillende VTP-modi:

In VTP transparante modus worden VTP-updates genegeerd (het VTP multicast MAC-adres wordt verwijderd uit de systeemCAM die normaal wordt gebruikt om controleframes op te halen en naar de supervisor-engine te sturen). Aangezien het protocol een multicast-adres gebruikt, wordt het frame door een switch in de transparante modus (of door een andere switch van een leverancier) eenvoudigweg overspoeld naar andere Cisco-switches in het domein.

¹ CatOS softwarerelease 7.1 introduceert de optie om VTP uit te schakelen met gebruik van de uitstand. In VTP off mode gedraagt de switch zich op een manier die erg lijkt op de VTP transparante mode, behalve dat uit mode ook het doorsturen van VTP updates onderdrukt.

Deze tabel geeft een samenvatting van de oorspronkelijke configuratie:

VTP versie 2 (VTPv2) biedt deze functionele flexibiliteit. Het is echter niet interoperabel met VTP versie 1 (VTPv1):

• Ondersteuning van Token Ring

• Niet-herkende VTP-informatieondersteuning; switches verspreiden nu waarden die ze niet kunnen ontleden.

• Versie-afhankelijke transparante modus; De transparante modus controleert de domeinnaam niet meer. Dit maakt ondersteuning van meer dan één domein over een transparant domein mogelijk.

• Versienummerdoorgifte; als VTPv2 op alle switches mogelijk is, kan alles worden ingeschakeld door de configuratie van één switch.

Raadpleeg begrip en configuratie van VLAN Trunk Protocol (VTP) voor meer informatie.

VTP versie 3

CatOS softwarerelease 8.1 introduceert ondersteuning voor VTP versie 3 (VTPv3). VTPv3 biedt verbeteringen ten opzichte van de bestaande versies. Deze verbeteringen maken het mogelijk:

• Ondersteuning voor uitgebreide VLAN’s

• Ondersteuning voor het maken en adverteren van private VLAN’s

• Ondersteuning voor VLAN-instanties en MST-voortplantingsinstanties (die worden ondersteund in CatOS release 8.3)

• Verbeterde serververificatie

• Bescherming tegen accidentele invoeging van de "verkeerde" database in een VTP-domein

• Interactie met VTPv1 en VTPv2

• De mogelijkheid om per poort te worden geconfigureerd

Een van de belangrijkste verschillen tussen VTPv3-implementatie en de eerdere versie is de introductie van een VTP primaire server. Idealiter moet er slechts één primaire server in een VTPv3-domein zijn, als het domein niet wordt gepartitioneerd. Om het even welke veranderingen die u aan het domein aanbrengt VTP moeten op de primaire server van VTP worden uitgevoerd om aan het domein worden verspreid VTP. Er kunnen meerdere servers zijn binnen een VTPv3-domein, die ook wel secundaire servers worden genoemd. Wanneer een switch is ingesteld op een server, wordt de switch standaard een secundaire server. De secundaire server kan de configuratie van het domein opslaan, maar kan de configuratie niet wijzigen. Een secundaire server kan de primaire server worden met een geslaagde overname van de switch.

Switches die VTPv3 uitvoeren, accepteren alleen een VTP-database met een hoger revisienummer dan de huidige primaire server. Dit proces verschilt aanzienlijk van VTPv1 en VTPv2, waarin een switch altijd een superieure configuratie accepteert van een buur in hetzelfde domein. Deze verandering met VTPv3 biedt bescherming. Een nieuwe switch die wordt geïntroduceerd in het netwerk met een hoger VTP-revisienummer kan de VLAN-configuratie van het gehele domein niet overschrijven.

VTPv3 introduceert ook een verbetering in hoe VTP wachtwoorden behandelt. Als u de optie voor de configuratie van het verborgen wachtwoord gebruikt om een wachtwoord in te stellen op "verborgen", gebeuren deze items:

• Het wachtwoord verschijnt niet in onbewerkte tekst in de configuratie. Het geheime hexadecimale formaat van het wachtwoord wordt opgeslagen in de configuratie.

• Als u probeert de switch te configureren als een primaire server, wordt u om het wachtwoord gevraagd. Als uw wachtwoord overeenkomt met het geheime wachtwoord, wordt de switch een primaire server, waarmee u het domein kunt configureren.

Opmerking: het is belangrijk om op te merken dat de primaire server alleen nodig is wanneer u de VTP-configuratie moet wijzigen. Een VTP-domein kan werken zonder actieve primaire server omdat de secundaire servers zorgen voor persistentie van de configuratie via reloads. De status van de primaire server wordt om de volgende redenen afgesloten:

• Opnieuw laden van een switch

• Een overschakeling met hoge beschikbaarheid tussen de actieve en redundante supervisor-modules

• Overname van een andere server

• Een wijziging in de configuratie van de modus

• Elke wijziging in de VTP-domeinconfiguratie, zoals een wijziging in:

  • Versie

  • Domeinnaam

  • Domeinwachtwoord

VTPv3 staat ook de switches toe om aan meerdere instanties van VTP deel te nemen. In dit geval kan dezelfde switch de VTP-server zijn voor één instantie en een client voor een andere instantie omdat de VTP-modi specifiek zijn voor verschillende VTP-instanties. Een switch kan bijvoorbeeld in de transparante modus werken voor een MST-instantie, terwijl de switch in de server-modus is geconfigureerd voor een VLAN-instantie.

In termen van interactie met VTPv1 en VTPv2, is het standaardgedrag in alle versies van VTP geweest dat de vroegere versies van VTP eenvoudig de nieuwe versieupdates laten vallen. Tenzij de VTPv1- en VTPv2-switches in de transparante modus staan, worden alle VTPv3-updates verbroken. Aan de andere kant, nadat VTPv3 switches een erfenis VTPv1 of VTPv2 kader op een trunk ontvangen, geven de switches een verlaagde versie van hun database update door aan de VTPv1 en VTPv2 switches. Deze informatie-uitwisseling is echter unidirectioneel in die zin dat er geen updates van VTPv1- en VTPv2-switches worden geaccepteerd door de VTPv3-switches. Op trunkverbindingen blijven VTPv3-switches geschaalde updates en volwaardige VTPv3-updates uitsturen om te kunnen inspelen op het bestaan van VTPv2- en VTPv3-buren in de trunkpoorten.

Om VTPv3-ondersteuning te bieden voor uitgebreide VLAN’s wordt het formaat van de VLAN-database, waarin VTP 70 bytes per VLAN toewijst, gewijzigd. De wijziging maakt alleen codering van niet-standaardwaarden mogelijk, in plaats van het dragen van ongewijzigde velden voor de legacy-protocollen. Wegens deze verandering, is de steun van 4K VLAN de grootte van het resulterende gegevensbestand van VLAN.

Aanbeveling

Er is geen specifieke aanbeveling over of om client/server modi VTP of transparante modus VTP te gebruiken. Sommige klanten geven de voorkeur aan het gemak van het beheer van VTP client/server mode ondanks enkele overwegingen die later opgemerkt worden. Aanbevolen wordt om in elk domein twee switches voor servermodus te hebben voor redundantie, meestal de twee distributielaag switches. De rest van de switches in het domein moet worden ingesteld op client mode. Wanneer u client/server mode met het gebruik van VTPv2 implementeert, moet u er rekening mee houden dat een hoger revisienummer altijd geaccepteerd wordt in hetzelfde VTP domein. Als een switch die in of cliënt VTP of serverwijze wordt gevormd in het domein VTP wordt geïntroduceerd en een hoger revisieaantal dan de bestaande servers VTP heeft, beschrijft dit het gegevensbestand van VLAN binnen het domein VTP. Als de configuratiewijziging onbedoeld is en VLAN’s worden verwijderd, kan de overschrijving een grote storing in het netwerk veroorzaken. Om ervoor te zorgen dat client- of server-switches altijd een configuratie-revisienummer hebben dat lager is dan dat van de server, wijzigt u de client-VTP-domeinnaam in iets anders dan de standaardnaam. Keer vervolgens terug naar de standaard. Met deze actie wordt de configuratie revisie op de client op 0 ingesteld.

Er zijn voor- en nadelen van de VTP-mogelijkheid om eenvoudig wijzigingen aan te brengen op een netwerk. Veel ondernemingen geven de voorkeur aan de voorzichtige benadering van VTP transparante mode om deze redenen:

• Het moedigt goede veranderingscontrole praktijken aan, aangezien het vereiste om VLAN op een switch of een boomstamhaven te wijzigen als één switch tegelijkertijd moet worden beschouwd.

• Het beperkt het risico van een beheerderfout die het gehele domein beïnvloedt, zoals de verwijdering van een VLAN per ongeluk.

• Er is geen risico dat een nieuwe switch die in het netwerk met een hoger VTP revisieaantal wordt geïntroduceerd de volledige domein VLAN-configuratie kan overschrijven.

• Het moedigt VLAN's aan om van trunks die naar switches lopen die geen poorten in dat VLAN hebben, gesnoeid te worden. Dit maakt frame overstroming efficiënter voor bandbreedte. Handmatig snoeien is ook nuttig omdat het de overspannende boomdiameter vermindert (zie de sectie DTP van dit document). Alvorens ongebruikte VLAN’s op poortkanaaltrunks te snoeien, zorg ervoor dat alle poorten die met IP-telefoons zijn verbonden, als toegangspoorten met spraak-VLAN zijn geconfigureerd.

• Het uitgebreide VLAN-bereik in CatOS 6.x en CatOS 7.x, nummers 1025 tot 4094, kan alleen op deze manier worden geconfigureerd. Zie de sectie Uitgebreid VLAN en MAC-adresbeperking van dit document voor meer informatie.

• VTP transparante modus wordt ondersteund in Campus Manager 3.1, deel van Cisco Works 2000. De oude beperking die minstens één server in een domein van VTP vereiste is verwijderd.

Opmerking: als u VLAN’s met de ingestelde opdracht specificeert, worden alleen VLAN’s toegevoegd en worden deze niet gewist. Bijvoorbeeld, de set trunk x/y 1-10 opdracht stelt de toegestane lijst niet in op alleen VLAN’s 1-10. Geef de duidelijke trunk x/y 11-1005-opdracht uit om het gewenste resultaat te bereiken.

Hoewel symbolische ringswitching buiten het bereik van dit document valt, merk op dat VTP transparante modus niet wordt aanbevolen voor TR-ISL netwerken. De basis voor token ring switching is dat het gehele domein een enkele gedistribueerde multi-poorts bridge vormt, zodat elke switch dezelfde VLAN-informatie moet hebben.

Overige opties

VTPv2 is een vereiste in symbolische ringomgevingen, waar client/server modus ten zeerste wordt aanbevolen.

VTPv3 biedt de mogelijkheid om striktere verificatie en configuratie revisie controle te implementeren. VTPv3 biedt in wezen hetzelfde niveau van functionaliteit, maar met meer verbeterde beveiliging, zoals VTPv1/VTPv2 transparante modus biedt. Daarnaast is VTPv3 gedeeltelijk compatibel met de oudere VTP-versies.

De voordelen van het snoeien van VLAN's om onnodige frame-overstroming te verminderen, worden in dit document bepleit. Met de instelling vtp-snoeien kunnen commando's automatisch VLAN's snoeien, waardoor de inefficiënte overstroming van frames wordt gestopt waar ze niet nodig zijn. In tegenstelling tot het handmatig snoeien van VLAN beperkt automatisch snoeien de Spanning Tree-diameter niet.

Vanaf CatOS 5.1 kunnen de Catalyst switches 802.1Q VLAN-nummers groter dan 1000 toewijzen aan ISL VLAN-nummers. In CatOS 6.x ondersteunen Catalyst 6500/6000 switches 4096 VLAN’s volgens de IEEE 802.1Q-standaard. Deze VLAN’s zijn georganiseerd in deze drie rangen, waarvan slechts enkele worden gepropageerd naar andere switches in het netwerk met VTP:

• VLAN’s met normaal bereik: 1–1001

• VLAN’s met uitgebreid bereik: 1025-4094 (alleen door VTPv3 vermeerderd)

• gereserveerde VLAN’s: 0, 1002-1024, 4095

IEEE heeft een op standaarden gebaseerde architectuur geproduceerd om vergelijkbare resultaten als VTP te behalen. Als lid van het 802.1Q Generic Attribute Registration Protocol (GARP) maakt het Generic VLAN Registration Protocol (GVRP) interoperabiliteit van VLAN-beheer tussen leveranciers mogelijk, maar dit valt buiten het bereik van dit document.

Opmerking: CatOS 7.x introduceert de optie om VTP in te stellen op uit-modus, een modus die erg lijkt op transparant. De switch doorstuurt echter geen VTP-frames. Dit kan in sommige ontwerpen nuttig zijn wanneer trunking aan switches buiten uw bestuurlijke controle.

Uitgebreide VLAN- en MAC-adresbeperking

De functie voor MAC-adresreductie maakt identificatie van VLAN met uitgebreid bereik mogelijk. De inschakeling van MAC-adresreductie schakelt de pool van MAC-adressen uit die worden gebruikt voor de VLAN-overspannende boom en laat één MAC-adres achter. Dit MAC-adres identificeert de switch. CatOS softwarerelease 6.1(1) introduceert ondersteuning voor MAC-adresreductie voor Catalyst 6500/6000 en Catalyst 4500/4000 switches ter ondersteuning van 4096 VLAN’s in overeenstemming met de IEEE 802.1Q-standaard.

Overzicht van bewerkingen

De chassisprotocollen gebruiken een MAC-adres dat afkomstig is van een bank met beschikbare adressen die een EPROM op de switch biedt als onderdeel van de bridge identifiers voor VLAN’s die worden uitgevoerd onder PVST+. Catalyst 6500/6000 en Catalyst 4500/4000 switches ondersteunen 1024 of 64 MAC-adressen, die afhankelijk zijn van het chassistype.

Catalyst switches met 1024 MAC-adressen maken het standaard verminderen van MAC-adres niet mogelijk. De adressen van MAC worden opeenvolgend toegewezen. Het eerste MAC-adres in het bereik wordt toegewezen aan VLAN 1. Het tweede MAC-adres in het bereik wordt toegewezen aan VLAN 2, enzovoort. Dit laat de switches toe om 1024 VLANs met elk VLAN te steunen die een uniek brugherkenningsteken gebruiken.

¹ MAC-adresreductie is standaard ingeschakeld voor switches met 64 MAC-adressen, en de functie kan niet worden uitgeschakeld.

Voor Catalyst Series switches met 1024 MAC-adressen biedt een instelbare MAC-adresreductie ondersteuning voor 4096 VLAN’s die worden uitgevoerd onder PVST+- of 16 instanties met MSTP (Multiple Instance STP) om unieke identificatoren te hebben zonder dat het aantal MAC-adressen dat op de switch vereist is, toeneemt. MAC-adresreductie vermindert het aantal MAC-adressen dat door de STP van één per VLAN- of MISTP-instantie wordt vereist tot één per switch.

Dit cijfer toont aan dat de het adresvermindering van het brugherkenningsteken van MAC niet wordt toegelaten. De bridge identifier bestaat uit een 2-byte bridge-prioriteit en een 6-byte MAC-adres:

MAC-adresreductie wijzigt het STP-bridge-identificatiegedeelte van de BPDU. Het oorspronkelijke prioriteitsveld van 2 bytes wordt in twee velden gesplitst. Deze splitsing resulteert in een 4-bits brug prioriteitsveld en een 12-bits systeem-ID-uitbreiding die VLAN-nummering van 0 tot en met 4095 mogelijk maakt.

Wanneer u MAC-adresreductie op Catalyst-switches hebt ingeschakeld om gebruik te maken van uitgebreide VLAN’s, dient u MAC-adresreductie in te schakelen voor alle switches binnen hetzelfde STP-domein. Deze stap is nodig om de STP-wortelberekeningen op alle switches consistent te houden. Nadat u MAC-adresreductie hebt ingeschakeld, wordt de root-brug-prioriteit een veelvoud van 4096 plus de VLAN-id. De switches zonder MAC-adresreductie kunnen per ongeluk wortel claimen omdat deze switches een fijnere granulariteit hebben in de selectie van de bridge-id.

Configuratierichtlijnen

U moet bepaalde richtlijnen volgen wanneer u een uitgebreid VLAN-bereik configureert. De switch kan een blok VLAN’s uit het uitgebreide bereik toewijzen voor interne doeleinden. De switch kan bijvoorbeeld de VLAN’s toewijzen voor de Routed Port- of Flex WAN-modules. De toewijzing van het blok VLAN’s begint altijd vanaf VLAN 1006 en gaat omhoog. Als u VLAN’s hebt binnen het bereik dat de Flex WAN-module vereist, worden alle vereiste VLAN’s niet toegewezen omdat de VLAN’s nooit worden toegewezen van de gebruiker VLAN-gebied. Geef het show VLAN bevel of het show VLAN summiere bevel op een switch uit om zowel de gebruiker-toegewezen als interne VLANs te tonen.

>show vlan summary

Current Internal Vlan Allocation Policy - Ascending

Vlan status    Count  Vlans
-------------  -----  ------------------------------------------
VTP Active         7   1,17,174,1002-1005

Internal           7   1006-1011,1016

!--- These are internal VLANs.

>show vlan
---- -------------------------------- --------- ------- --------

1    default                          active    7       4/1-48



!--- Output suppressed.


1006 Online Diagnostic Vlan1          active    0       internal
1007 Online Diagnostic Vlan2          active    0       internal
1008 Online Diagnostic Vlan3          active    0       internal
1009 Voice Internal Vlan              active    0       internal
1010 Dtp Vlan                         active    0       internal
1011 Private Vlan Internal Vlan       suspend   0       internal
1016 Online SP-RP Ping Vlan           active    0       internal

!--- These are internal VLANs.

Bovendien moet u, voordat u het uitgebreide VLAN gebruikt, alle bestaande 802.1Q-to-ISL-toewijzingen verwijderen. Ook, in versies vroeger dan VTPv3, moet u uitgebreid VLAN op elke switch met het gebruik van VTP transparante wijze statisch vormen. Raadpleeg het gedeelte VLAN-configuratierichtlijnen voor uitgebreid bereik van VLAN’s configureren voor meer informatie.

Opmerking: in software die ouder is dan softwarerelease 8.1(1), kunt u de VLAN-naam voor VLAN’s met uitgebreid bereik niet configureren. Deze mogelijkheid is onafhankelijk van elke VTP versie of modus.

Aanbeveling

Probeer een consistente configuratie van MAC-adresreductie te handhaven binnen hetzelfde STP-domein. Het afdwingen van MAC-adresreductie op alle netwerkapparaten kan echter onpraktisch zijn wanneer nieuwe chassis met 64 MAC-adressen aan het STP-domein worden geïntroduceerd. MAC-adresreductie is standaard ingeschakeld voor switches die 64 MAC-adressen hebben, en de functie kan niet worden uitgeschakeld. Begrijp dat, wanneer twee systemen met de zelfde overspannen-boomprioriteit worden gevormd, het systeem zonder het adresvermindering van MAC een betere overspannen-boomprioriteit heeft. Geef deze opdracht uit om MAC-adresreductie in of uit te schakelen:

set spantree macreduction enable | disable

De toewijzing van interne VLAN’s gebeurt in oplopende volgorde en begint bij VLAN 1006. Wijs de gebruiker VLAN’s zo dicht mogelijk bij VLAN 4094 toe om conflicten tussen de gebruiker VLAN’s en de interne VLAN’s te voorkomen. Met Catalyst 6500 switches waarop Cisco IOS®-systeemsoftware wordt uitgevoerd, kunt u de interne VLAN-toewijzing in aflopende volgorde configureren. De Command-Line Interface (CLI) equivalent voor CatOS software wordt niet officieel ondersteund.

Automatische onderhandeling

Ethernet/Fast Ethernet

Autonegotiation is een optionele functie van de IEEE Fast Ethernet (FE) standaard (802.3u) waarmee apparaten automatisch informatie kunnen uitwisselen via een link over snelheid en duplexmogelijkheden. Autonegotiation werkt op Layer 1 (L1) en heeft als doel toegang tot laagpoorten waar tijdelijke gebruikers zoals pc’s verbinding maken met het netwerk.

Operationeel overzicht

De meest voorkomende oorzaak van prestatiekwesties op 10/100 Mbps Ethernet-links treedt op wanneer één poort op de link werkt op een half-duplex terwijl de andere poort op een full-duplex staat. Dit gebeurt af en toe wanneer een of beide poorten op een link worden gereset en het proces van zelfstandig onderhandelen niet veroorzaakt dat beide link partners dezelfde configuratie hebben. Het gebeurt ook wanneer beheerders de ene kant van een link opnieuw configureren en vergeten om de andere kant opnieuw te configureren. De kenmerkende symptomen hiervan zijn toenemende framecontrolesequentie (FCS), cyclische redundantiecontrole (CRC), uitlijning of tellers op de switch.

Autonome onderhandelingen worden in detail besproken in deze documenten. Deze documenten omvatten toelichtingen van hoe autonegotiation werkt en configuratieopties.

• Automatische onderhandeling van Ethernet 10/100 MB voor halve/volledige duplexeenheid configureren en probleemoplossing bieden

• Troubleshooting Cisco Catalyst Switches to NIC Compatibility Issues (NIC-compatibiliteitsproblemen bij Cisco Catalyst-switches oplossen)

Een veel voorkomend misverstand over autonegotiation is dat het mogelijk is om één link partner handmatig te configureren voor 100 Mbps full-duplex en autonegotiate voor full-duplex met de andere link partner. Een poging om dit te doen resulteert in een duplex mismatch. Dit is een gevolg van één verbindingspartner die, die geen parameters van autonegotiation van de andere verbindingspartner ziet, en in gebreke blijft aan half-duplex.

De meeste Catalyst Ethernet-modules ondersteunen 10/100 Mbps en half/full-duplex, maar de mod/port-opdracht voor de showpoortmogelijkheden bevestigt dit.

FEFI

Far-end Error Indication (FEFI) beschermt 100BASE-FX (glasvezel) en Gigabit interfaces, terwijl autonoom onderhandelen 100BASE-TX (koper) beschermt tegen fysieke Layer/signalering-gerelateerde fouten.

Een verre eindfout is een fout in de verbinding die één post kan ontdekken terwijl andere niet, zoals een losgemaakte TX-draad kan ontdekken. In dit voorbeeld, kon het verzendende station nog geldige gegevens ontvangen en ontdekken dat de verbinding door de verbinding-integriteit-monitor goed is. Het detecteert niet dat de transmissie niet door het andere station wordt ontvangen. Een station 100BASE-FX dat een dergelijke externe fout detecteert, kan de doorgezonden IDLE stream wijzigen om een speciaal bitpatroon (het FEFI IDLE patroon) te versturen om de buur van de externe fout te informeren. het FEFI-IDLE patroon activeert vervolgens een afsluiten van de externe poort (erreless). Raadpleeg het UDLD-gedeelte van dit document voor meer informatie over de bescherming van fouten.

FEFI wordt ondersteund door deze hardware en modules:

• Catalyst 5500/5000: WS-X521R, WS-X5305, WS-X5236, WS-X5237, WS-U538 en WS-U5539

• Catalyst 6500/6000 en 4500/4000: Alle 100BASE-FX-modules en GE-modules

Aanbeveling

Of u autonegotiation op 10/100 koppelingen of op vaste codesnelheid en duplex wilt configureren, hangt uiteindelijk af van het type koppelingspartner of eindapparaat dat u hebt aangesloten op een Catalyst switch-poort. Automatisch onderhandelen tussen eindapparaten en Catalyst-switches werkt over het algemeen goed en Catalyst-switches zijn compatibel met de IEEE 802.3u-specificatie. Problemen kunnen echter ontstaan wanneer NIC of leverancier switches niet exact overeenkomen. Hardware-incompatibiliteit en andere problemen kunnen ook bestaan als gevolg van leverancier-specifieke geavanceerde functies, zoals auto-polariteit of bekabeling integriteit, die niet worden beschreven in de IEEE 802.3u-specificatie voor 10/100 Mbps autonomie. Raadpleeg de melding uit het veld: Prestatieproblemen met Intel Pro/1000T NIC's die zijn aangesloten op CAT4K/6K, bijvoorbeeld.

Verwacht dat er enkele situaties zullen zijn waarin host, poortsnelheid en duplex moeten worden ingesteld. In het algemeen volgt u de volgende stappen voor probleemoplossing:

• Zorg ervoor dat of autonegotiation aan beide kanten van de verbinding wordt gevormd of de harde codering aan beide kanten wordt gevormd.

• Controleer de CatOS release notities voor algemene voorbehouden.

• Controleer de versie van de NIC-stuurprogramma of het besturingssysteem dat u gebruikt, aangezien de laatste driver of patch vaak wordt vereist.

Als regel, probeer om autonegotiation eerst voor om het even welk type van verbindingspartner te gebruiken. Er zijn duidelijke voordelen aan het configureren van zelfstandigheid voor transiënte apparaten zoals laptops. Idealiter werkt automatisch onderhandelen ook goed met niet-transiënte apparaten zoals servers en vaste werkstations of van switch-naar-switch en switch-naar-router. Om een aantal van de genoemde redenen kunnen er onderhandelingen ontstaan. In deze gevallen volgt u de basisstappen voor probleemoplossing die in de meegeleverde TAC-koppelingen zijn beschreven.

Als de poortsnelheid is ingesteld op auto op een 10/100 Mbps Ethernet-poort, worden zowel snelheid als duplex autonoom onderhandeld. Geef deze opdracht uit om de poort in te stellen op auto:

set port speed port range auto

!--- This is the default.

Als harde codering van de poort, geeft u deze configuratieopdrachten:

set port speed port range 10 | 100
set port duplex port range full | half

In CatOS 8.3 en hoger heeft Cisco het optionele auto-10-100-trefwoord geïntroduceerd. Gebruik het trefwoord auto-10-100 op poorten die snelheden van 10/100/1000 Mbps ondersteunen, maar waarbij autonoom onderhandelen met 1000 Mbps ongewenst is. Het gebruik van het sleutelwoord auto-10-100 zorgt ervoor dat de poort zich op dezelfde manier gedraagt als een 10/100-Mbps poort waarop de snelheid is ingesteld op auto. De snelheid en de duplex worden alleen overeengekomen voor 10/100-Mbps poorten en de 1000-Mbps-snelheid neemt niet deel aan de onderhandeling.

set port speed port_range auto-10-100

Overige opties

Als er geen autonome onderhandeling tussen switches wordt gebruikt, kan de foutmelding L1 ook verloren gaan voor bepaalde problemen. Het is handig om L2-protocollen te gebruiken om de detectie van storingen te verbeteren, zoals agressieve UDLD.

Gigabit Ethernet

Gigabit Ethernet (GE) heeft een zelfonderhandelingsprocedure (IEEE 802.3z) die uitgebreider is dan die voor 10/100 Mbps Ethernet en wordt gebruikt voor het uitwisselen van flow-control parameters, informatie over externe fouten en duplexinformatie (ook al ondersteunen Catalyst-series GE-poorten alleen de full-duplex modus).

Opmerking: 802.3z is vervangen door specificaties van IEEE 802.3:2000. Raadpleeg het abonnement IEEE Standards on line LAN/MAN-standaarden: Archieven voor meer informatie.

Operationeel overzicht

GE-poortonderhandeling is standaard ingeschakeld en de poorten aan beide uiteinden van een GE-link moeten dezelfde instelling hebben. In tegenstelling tot FE komt de GE-link niet naar boven als de instelling voor zelfstandig onderhandelen op de poorten aan elk uiteinde van de link verschilt. De enige voorwaarde die echter vereist is om een autonoom onderhandelde poort te kunnen koppelen, is een geldig Gigabit-signaal aan het einde van de verbinding. Dit gedrag is onafhankelijk van de autonome onderhandelingsconfiguratie van het verre eind. Bijvoorbeeld, veronderstel dat er twee apparaten zijn, A en B. Elk apparaat kan toegelaten of gehandicapte autonegotiation hebben. Deze tabel bevat een lijst van mogelijke configuraties en respectievelijke koppelingsstaten:

In GE, worden synchronisatie en autonegotiation (als zij worden toegelaten) uitgevoerd op verbindingsopstarten door het gebruik van een speciale opeenvolging van gereserveerde woorden van de verbindingscode.

Opmerking: er is een woordenboek met geldige woorden en niet alle mogelijke woorden zijn geldig in GE.

De levensduur van een GE-verbinding kan op deze manier worden gekarakteriseerd:

Een verlies van synchronisatie betekent dat de MAC een koppeling omlaag detecteert. Het verlies van synchronisatie is van toepassing of autonegotiation wordt ingeschakeld of uitgeschakeld. Synchronisatie gaat verloren onder bepaalde mislukte omstandigheden, zoals de ontvangst van drie ongeldige woorden na elkaar. Als deze voorwaarde 10 ms blijft bestaan, wordt een "sync failliet" voorwaarde bevestigd en wordt de link gewijzigd in de link_down staat. Nadat de synchronisatie is verloren, zijn nog drie opeenvolgende geldige idles noodzakelijk om opnieuw te synchroniseren. Andere catastrofale gebeurtenissen, zoals een verlies van het ontvangstsignaal (Rx), veroorzaakt een link-down gebeurtenis.

Autonegotiation is een onderdeel van het koppelingsproces. Wanneer de link is opgestart, is automatisch onderhandelen voorbij. De switch controleert echter nog steeds de status van de link. Als autonegotiation op een poort uitgeschakeld is, is de fase "autonoom" niet langer een optie.

De GE-koperspecificatie (1000BASE-T) ondersteunt wel autonomie via een Next Page Exchange. Next Page Exchange maakt autonome onderhandeling mogelijk voor snelheden van 10/100/1000-Mbps op koperpoorten.

Opmerking: de GE-glasvezelspecificatie bevat alleen bepalingen voor de onderhandeling van duplex-, flow control- en afstandsdetectie van fouten. GE-glasvezelpoorten onderhandelen niet over poortsnelheid. Raadpleeg de secties 28 en 37 van de IEEE 802.3-2002-specificatie voor meer informatie over zelfonderhandeling.

De vertraging van het synchronisatiestart is een softwarefunctie die de totale tijd van de autonegotivering controleert. Als autonegotiation niet succesvol is binnen deze tijd, start de firmware opnieuw autonegotiation voor het geval er een impasse is. De ingestelde poortsync-start-vertragingsopdracht heeft alleen een effect wanneer autonegotiation is ingesteld om in te schakelen.

Aanbeveling

Autonome onderhandeling inschakelen is veel kritischer in een GE-omgeving dan in een 10/100-omgeving. In feite mag autonegotiation alleen worden uitgeschakeld op switch poorten die worden aangesloten op apparaten die niet in staat zijn om onderhandeling te ondersteunen of waar connectiviteitsproblemen ontstaan door interoperabiliteitsproblemen. Cisco raadt aan Gigabit-onderhandeling in te schakelen (standaard) op alle switch-naar-switch links en in het algemeen op alle GE-apparaten. Geef dit commando uit om zelfstandig onderhandelen mogelijk te maken:

set port negotiation port range enable

!--- This is the default.

Een bekende uitzondering is wanneer er een verbinding is met een Gigabit Switch Router (GSR) waarop Cisco IOS-software wordt uitgevoerd eerder dan release 12.0(10)S, de release die flow control en autonomie toevoegde. In dit geval, zet die twee eigenschappen uit, of de de havenrapporten van de switch niet verbonden, en GSR meldt fouten. Dit is een voorbeeldopdrachtreeks:

set port flowcontrol receive port range off
set port flowcontrol send port range off
set port negotiation port range disable

Switch-to-server verbindingen moeten per geval bekeken worden. Cisco-klanten zijn op problemen gestuit met Gigabit-onderhandeling op Sun-, HP- en IBM-servers.

Overige opties

Flow Control is een optioneel onderdeel van de 802.3x specificatie en moet worden onderhandeld indien gebruikt. Apparaten kunnen al dan niet in staat zijn om te verzenden en/of te reageren op een PAUSE frame (bekend als MAC 01-80-C2-00-00-00 0F). Ook kunnen ze niet instemmen met het flow-control verzoek van de verre buur. Een poort met een invoerbuffer die wordt opgevuld, stuurt een PAUSE-frame naar zijn koppelingspartner, die de transmissie stopt, en houdt extra frames in de uitvoerbuffers van de koppelingspartner. Dit lost geen enkel probleem op met betrekking tot het over-abonnement van de steady-state, maar maakt de inputbuffer tijdens uitbarstingen effectief groter door één of andere fractie van de buffer van de partneroutput.

Deze functie kan het best worden gebruikt bij koppelingen tussen toegangspoorten en eindhosts, waar de host-uitvoerbuffer potentieel zo groot is als hun virtuele geheugen. Het gebruik van switch tot switch heeft beperkte voordelen.

Geef deze opdrachten uit om dit in de switch-poorten te regelen:

set port flowcontrol mod/port receive | send off |on | desired


>show port flowcontrol

 Port  Send FlowControl    Receive FlowControl   RxPause TxPause
       admin    oper       admin    oper
-----  -------- --------   -------- --------     ------- -------
 6/1   off      off        on       on           0       0
 6/2   off      off        on       on           0       0
 6/3   off      off        on       on           0       0

Opmerking: alle Catalyst-modules reageren op een PAUSE-frame indien ze worden onderhandeld. Sommige modules (bijvoorbeeld WS-X5410, WS-X4306) sturen nooit PAUSE frames, zelfs als ze onderhandelen om dit te doen, omdat ze niet blokkeren.

Dynamisch trunkingprotocol

Type insluiting

Trunks breiden VLAN’s uit tussen apparaten door de oorspronkelijke Ethernet-frames tijdelijk te identificeren en te labelen (link-lokaal), zodat ze multiplexing over één link mogelijk maken. Dit garandeert ook dat de afzonderlijke VLAN-broadcast- en beveiligingsdomeinen tussen de switches worden onderhouden. CAM-tabellen onderhouden de frame-to-VLAN-toewijzing binnen de switches.

Trunking wordt ondersteund op verschillende typen L2-media, waaronder ATM LANE, FDDI 802.10 en Ethernet, hoewel alleen de laatste hier wordt weergegeven.

ISL - operationeel overzicht

Cisco-systeem voor bedrijfseigen identificatie of codering, ISL, wordt al vele jaren gebruikt. De 802.1Q IEEE-standaard is ook beschikbaar.

Door het oorspronkelijke frame volledig in te kapselen in een coderingsschema op twee niveaus, is ISL effectief een tunnelprotocol en heeft ISL het extra voordeel om niet-Ethernet frames te dragen. Het voegt een 26-byte header en 4-byte FCS toe aan het standaard Ethernet frame - de grotere Ethernet frames worden verwacht en behandeld door poorten geconfigureerd om trunks te zijn. ISL ondersteunt 1024 VLAN’s.

ISL-frame-indeling

Raadpleeg InterSwitch Link en IEEE 802.1Q Frame Format voor meer informatie.

802.1Q overzicht van bedrijfsvoering

De standaard IEEE 802.1Q specificeert veel meer dan inkapselingstypen, waaronder Spanning Tree-verbeteringen, GARP (zie het VTP-gedeelte van dit document) en 802.1p QoS-codering (Quality of Service).

Het 802.1Q frame formaat behoudt het oorspronkelijke Ethernet-bronadres en doeladres, maar switches moeten nu verwachten dat babyreuzenframes worden ontvangen, zelfs op toegangspoorten waar hosts codering kunnen gebruiken om 802.1p gebruikersprioriteit voor QoS-signalering uit te drukken. De tag is 4 bytes, dus 802.1Q Ethernet v2 frames zijn 1522 bytes, een IEEE 802.3ac werkgroepprestatie. 802.1Q ondersteunt ook nummeringsruimte voor 4096 VLAN’s.

Alle verzonden en ontvangen datakaders zijn 802.1Q-getagd behalve die op het native VLAN (er is een impliciete tag op basis van de ingress switch poortconfiguratie). Frames op het native VLAN worden altijd verzonden zonder tag en normaal ontvangen zonder tag. Ze kunnen echter ook gelabeld worden.

Raadpleeg VLAN-standaardisering via IEEE 802.10 en ontvang IEEE 802 voor meer informatie.

802.1Q/801.1p frame-formaat

Aanbeveling

Aangezien alle nieuwere hardware 802.1Q ondersteunt (en sommige alleen 802.1Q ondersteunen, zoals Catalyst 4500/4000 Series en CSS 11000), raadt Cisco aan dat alle nieuwe implementaties de IEEE 802.1Q-standaard volgen en oudere netwerken geleidelijk van ISL migreren.

De IEEE-standaard maakt interoperabiliteit tussen leveranciers mogelijk. Dit is voordelig in alle Cisco-omgevingen wanneer nieuwe, voor host 802.1p geschikte NIC's en apparaten beschikbaar komen. Hoewel zowel ISL- als 802.1Q-implementaties volledig zijn ontwikkeld, zal de IEEE-standaard uiteindelijk een grotere blootstelling aan velden en meer ondersteuning van derden hebben, zoals ondersteuning voor netwerkanalyzers. De lagere inkapselingsoverheadkosten van 802.1Q in vergelijking met ISL zijn een minder belangrijk punt voor 802.1Q eveneens.

Aangezien het inkapselingstype tussen switches via DTP wordt onderhandeld, waarbij ISL standaard als winnaar wordt gekozen als beide eindpunten het ondersteunen, is het noodzakelijk dit commando te geven om dot1q te specificeren:

set trunk mod/port mode dot1q

Als VLAN 1 uit een trunk wordt gewist, zoals besproken in de sectie In-Band Management van dit document, hoewel er geen gebruikersgegevens worden verzonden of ontvangen, blijft het NMP controleprotocollen zoals CDP en VTP op VLAN 1 doorgeven.

Ook, zoals besproken in de sectie VLAN 1 van dit document, worden CDP-, VTP- en PAgP-pakketten altijd op VLAN 1 verzonden tijdens trunking. Wanneer dot1q-insluiting wordt gebruikt, worden deze besturingsframes getagd met VLAN 1 als het native VLAN van de switch wordt gewijzigd. Als dot1q-trunking naar een router is ingeschakeld en het native VLAN op de switch is gewijzigd, is er een subinterface in VLAN 1 nodig om de gelabelde CDP-frames te ontvangen en CDP-buurzichtbaarheid op de router te bieden.

Opmerking: er is een potentiële veiligheidsoverweging met dot1q veroorzaakt door de impliciete tagging van het native VLAN, aangezien het mogelijk kan zijn om frames van het ene VLAN naar een ander zonder router te verzenden. Raadpleeg Zijn er kwetsbaarheden in VLAN-implementaties? voor nadere bijzonderheden. De tijdelijke oplossing is om een VLAN-id te gebruiken voor het native VLAN van de trunk die niet wordt gebruikt voor toegang door eindgebruikers. De meerderheid van Cisco-klanten verlaat VLAN 1 als het native VLAN op een trunk en wijst toegangspoorten toe aan VLAN’s anders dan VLAN 1 om dit eenvoudig te bereiken.

Trunkingmodus

DTP is de tweede generatie van Dynamic ISL (DISL) en bestaat om ervoor te zorgen dat de verschillende parameters die betrokken zijn bij het verzenden van ISL- of 802.1Q-frames, zoals het geconfigureerde inkapselingstype, native VLAN en hardwarevermogen, door de switches aan beide uiteinden van een trunk worden overeengekomen. Dit helpt ook beschermen tegen niet-trunkhavens die gelabelde frames overspoelen, een potentieel ernstig veiligheidsrisico, door ervoor te zorgen dat havens en hun buren in consistente staten zijn.

Operationeel overzicht

DTP is een L2-protocol dat configuratieparameters bespreekt tussen een switch en de naburige poort. Het gebruikt een ander multicast MAC-adres (01-00-0c-cc-cc-cc) en een SNAP-protocoltype van 0x2004. Deze tabel is een samenvatting van de configuratiemodi:

Dit zijn enkele hoogtepunten van het protocol:

• DTP gaat uit van een point-to-point verbinding en Cisco-apparaten ondersteunen alleen 802.1Q trunkpoorten die point-to-point zijn.

• Tijdens DTP-onderhandeling nemen de poorten niet deel aan STP. Pas nadat de poort een van de drie DTP-typen is geworden (access, ISL of 802.1Q) wordt de poort toegevoegd aan STP. Anders is PAgP, indien geconfigureerd, het volgende proces dat moet worden uitgevoerd voordat de poort aan STP deelneemt.

• Als de poort in ISL-modus werkt, worden DTP-pakketten op VLAN 1 verzonden, anders (voor 802.1Q-trunkingpoorten of niet-trunkingpoorten) worden ze op het native VLAN verzonden.

• In de gewenste modus, DTP pakketten overbrengen de VTP domeinnaam (die moet overeenkomen voor een onderhandelde trunk om te komen), plus trunkconfiguratie en admin status.

• Berichten worden elke seconde verzonden tijdens de onderhandeling, en elke 30 seconden daarna.

• Zorg ervoor dat u begrijpt dat modi aan, niet onderhandelen en uit expliciet specificeren in welke staat de poort eindigt. Een slechte configuratie kan tot een gevaarlijke/inconsistente staat leiden waar de ene kant trunking is en de andere niet.

• Een poort in de modus aan, automatisch of gewenste verzendt periodiek DTP-frames. Als een poort in de automatische of gewenste modus geen DTP-pakket in vijf minuten ziet, is deze ingesteld op non-trunk.

Raadpleeg ISL-trunking configureren op Switches van de Catalyst 5500/5000- en 6500/6000-reeks voor meer ISL-gegevens. Raadpleeg Trunking tussen Catalyst 4500/4000, 5500/5000 en 6500/6000 Series Switches met 802.1Q-insluiting met Cisco CatOS-systeemsoftware voor meer informatie over 802.1Q.

Aanbeveling

Cisco raadt een expliciete trunkconfiguratie aan van gewenste instellingen aan beide uiteinden. In deze modus kunnen netwerkoperatoren syslog en opdrachtregel statusberichten vertrouwen dat een poort omhoog en trunking is, in tegenstelling tot modus, die een poort kan laten verschijnen, zelfs als de buur verkeerd is geconfigureerd. Daarnaast biedt wenselijke mode trunk stabiliteit in situaties waar één kant van de link geen trunk kan worden of de trunkstatus laat vallen. Geef deze opdracht uit om de gewenste modus in te stellen:

set trunk mod/port desirable ISL | dot1q

Opmerking: Stel de trunk in op uit op alle niet-trunkpoorten. Dit helpt verspilde onderhandelingstijd te elimineren bij het omhoog brengen van hostpoorten. Dit bevel wordt ook uitgevoerd wanneer het vastgestelde bevel van de poortgastheer wordt gebruikt; Raadpleeg de STP-sectie voor meer informatie. Geef deze opdracht uit om een trunk op een reeks poorten uit te schakelen:

set trunk port range off

!--- Ports are not trunking; part of the set port host command.

Overige opties

Een andere gebruikelijke klantconfiguratie gebruikt wenselijke modus alleen op de distributielaag en de eenvoudigste standaardconfiguratie (automatische modus) op de toegangslaag.

Sommige switches, zoals Catalyst 2900XL, Cisco IOS-routers of andere leverancierapparaten, ondersteunen momenteel geen trunkonderhandeling via DTP. U kunt nonegotiate modus gebruiken op Catalyst 4500/4000, 5500/5000 en 6500/6000 switches om een poort onvoorwaardelijk in te stellen met deze apparaten, die kunnen helpen standaardiseren op een gemeenschappelijke instelling op de campus. U kunt ook de modus non-onderhandelen implementeren om de tijd voor het initialiseren van de "algemene" link te reduceren.

Opmerking: factoren zoals de kanaalmodus en STP-configuratie kunnen ook de initialisatietijd beïnvloeden.

Geef deze opdracht uit om de modus zonder onderhandeling in te stellen:

set trunk mod/port nonegotiate ISL | dot1q

Cisco raadt nonegotiate aan als er een verbinding met een Cisco IOS-router is, omdat wanneer overbrugging wordt uitgevoerd, sommige DTP-frames die van op de modus worden ontvangen, terug naar de trunkpoort kunnen worden getransporteerd. Op ontvangst van het DTP frame, probeert de switch poort onnodig opnieuw te onderhandelen (of de trunk naar beneden en naar boven te brengen). Als nonegotiate is ingeschakeld, verstuurt de switch geen DTP-frames.

Spanning Tree-protocol

Overwegingen

Spanning Tree Protocol (STP) handhaaft een lusvrije L2-omgeving in redundante switched en overbrugde netwerken. Zonder STP, frames loop en/of vermenigvuldigen zich oneindig, wat een netwerkmeltdown veroorzaakt als alle apparaten in het broadcast-domein continu worden onderbroken door hoog verkeer.

Hoewel STP in sommige opzichten een volledig protocol is dat oorspronkelijk is ontwikkeld voor langzame software-gebaseerde brugspecificaties (IEEE 802.1d), kan het complex zijn om goed te implementeren in grote switched netwerken met veel VLAN’s, veel switches in een domein, ondersteuning voor meerdere leveranciers en nieuwere IEEE-verbeteringen.

Voor toekomstige verwijzing, blijft CatOS 6.x nieuwe STP-ontwikkeling, zoals MISTP, loop-guard, root-guards, en BPDU aankomsttijd scheefheid detectie nemen. Bovendien zijn er nog meer gestandaardiseerde protocollen beschikbaar in CatOS 7.x, zoals IEEE 802.1s gedeelde Spanning Tree en IEEE 802.1w snelle convergentie Spanning Tree.

Operationeel overzicht

De root-brug per VLAN wordt behaald door de switch met het laagste root-brug-identificatienummer (BID). Het bod is de brugprioriteit die met het adres van MAC van de switch wordt gecombineerd.

Aanvankelijk worden BPDU's vanuit alle switches verzonden, met het BID van elke switch en de padkosten om die switch te bereiken. Hiermee kunnen de root-brug en het pad met de laagste kosten naar de hoofdmap worden bepaald. Aanvullende configuratieparameters die in BPDU's van de hoofdmap worden gedragen, negeren de parameters die lokaal zijn geconfigureerd, zodat het hele netwerk consistente timers gebruikt.

De topologie komt dan door deze stappen samen:

1. Er wordt één root-brug gekozen voor het gehele Spanning Tree-domein.

2. Eén wortelpoort (met uitzicht op de root-brug) wordt gekozen op elke niet-root-brug.

3. Een aangewezen haven wordt verkozen voor het door:sturen BPDU op elk segment.

4. Niet-aangewezen poorten blokkeren.

Raadpleeg Spanning Tree configureren voor meer informatie.

De twee types van BPDUs in STP zijn configuratie BPDUs en van het Bericht van de Verandering van de Topologie (TCN) BPDUs.

Configuratie-BPDU-stroom

De configuratie BPDU's zijn afkomstig van elke hello-interval vanaf elke poort op de root-brug en stromen vervolgens naar alle bladpoorten om de status van de Spanning Tree te behouden. switches In steady-state is de BPDU-stroom unidirectioneel: de wortelpoorten en blokkerende poorten ontvangen alleen configuratie-BPDU's, terwijl aangewezen poorten alleen configuratie-BPDU's verzenden.

Voor elke BPDU die door een switch van de wortel wordt ontvangen, wordt nieuwe verwerkt door Catalyst Central NMP en verzonden die de wortelinformatie bevat. Met andere woorden, als de root-brug verloren gaat of alle paden naar de root-brug verloren gaan, stoppen BPDU's met ontvangen worden (totdat de maxage timer herverkozen wordt).

TCP/BPDU-stroom

TCN BPDU's zijn afkomstig van bladbomen en stromen naar de root-brug wanneer een topologieverandering in de overspannende switch wordt gedetecteerd. Root-poorten verzenden alleen TCN's, en aangewezen poorten ontvangen alleen TCN's.

De TCN BPDU reist naar de wortelrand en wordt bij elke stap erkend, dus dit is een betrouwbaar mechanisme. Zodra de root-brug is bereikt, waarschuwt de root-brug het gehele domein dat een wijziging is opgetreden door te zoeken naar Configuration BPDU's met de TCN-vlag ingesteld voor max + fwdvertragingstijd (standaard 35 seconden). Dit zorgt ervoor dat alle switches hun normale CAM-verouderingstijd wijzigen van vijf minuten (standaard) naar het interval aangegeven door fwddelagen (15 seconden standaard). Raadpleeg Spanning Tree Protocol-topologiewijzigingen begrijpen voor meer informatie.

Spanning Tree-modi

Er zijn drie verschillende manieren om VLAN’s te correleren met Spanning Tree:

• Eén Spanning Tree-protocol voor alle VLAN’s of één Spanning Tree-protocol, zoals IEEE 802.1Q

• Een Spanning Tree per VLAN of gedeelde Spanning Tree, zoals Cisco PVST

• Een Spanning Tree per set VLAN’s of meerdere Spanning Tree-switches, zoals Cisco MISTP en IEEE 802.1s

Een monoSpanning Tree voor alle VLAN’s biedt slechts één actieve topologie en dus geen taakverdeling. Een STP blokkeert poortblokken voor alle VLAN’s en draagt geen gegevens.

Eén Spanning Tree per VLAN maakt taakverdeling mogelijk maar vereist meer BPDU CPU-verwerking naarmate het aantal VLAN’s toeneemt. De CatOS release notities geven richtlijnen over het aantal logische poorten dat wordt aanbevolen in de Spanning Tree per switch. De Catalyst 6500/6000 Supervisor Engine 1-formule is bijvoorbeeld als volgt:

aantal poorten + (aantal trunks * aantal VLAN’s op trunks) < 4000

Cisco MISTP en de nieuwe 802.1s-standaard staan de definitie van slechts twee actieve STP-instanties/topologieën en de toewijzing van alle VLAN’s aan een van deze twee bomen toe. Deze techniek staat STP toe om aan vele duizenden VLAN's te schalen terwijl het in evenwicht brengen van de lading wordt toegelaten.

BPDU-formaten

Om de IEEE 802.1Q-standaard te ondersteunen, is de bestaande Cisco STP-implementatie uitgebreid tot PVST+ door ondersteuning toe te voegen voor tunneling in een IEEE 802.1Q monoSpanning Tree-gebied. PVST+ is daarom compatibel met zowel IEEE 802.1Q MST- als Cisco PVST-protocollen en vereist geen extra opdrachten of configuratie. Daarnaast voegt PVST+ verificatiemechanismen toe om ervoor te zorgen dat er geen configuratie-inconsistentie is tussen poorttrunking en VLAN-ID’s over switches.

Dit zijn enkele operationele hoogtepunten van het PVST+ protocol:

• PVST+ maakt gebruik van 802.1Q mono Spanning Tree via de zogeheten Common Spanning Tree (CST) via een 802.1Q-trunk. CST is altijd op VLAN 1, zodat moet dit VLAN op de boomstam worden toegelaten om met andere verkopers interworking te zijn. CST BPDU's worden verzonden, altijd zonder tag, naar de IEEE Standard Bridge-Group (MAC-adres 01-80-c2-00-00-00, DSAP 42, SAP 42). Voor de volledigheid van de beschrijving wordt ook een parallelle set BPDU's verzonden naar het Cisco gedeelde Spanning Tree MAC-adres voor VLAN 1.

• PVST+-tunnels PVST-BPDU’s over 802.1Q VLAN-regio’s als multicastgegevens. Cisco gedeelde Spanning Tree BPDU’s worden verzonden naar MAC-adres 10-00-0c-cc-cc-cd (SNAP HDLC-protocoltype 0x010b) voor elk VLAN op een trunk. BPDU's zijn niet-gelabeld op het native VLAN en gelabeld voor alle andere VLAN's.

• PVST+ controleert poort- en VLAN-inconsistenties. PVST+ blokkeert de poorten die inconsistente BPDU's ontvangen om doorsturen van lusjes te voorkomen. Het brengt gebruikers ook via syslog berichten op de hoogte over eventuele configuratie mismatch.

• PVST+ is achterwaarts compatibel met bestaande Cisco-switches die PVST op ISL-trunks uitvoeren. ISL-ingekapselde BPDU's worden nog steeds verzonden of ontvangen met behulp van het IEEE MAC-adres. Met andere woorden, elk BPDU-type is link-lokaal; er zijn geen vertaalproblemen.

Aanbeveling

Alle Catalyst switches hebben standaard STP ingeschakeld. Dit wordt aanbevolen, zelfs als er een ontwerp wordt gekozen dat geen L2-lussen bevat, zodat STP niet is ingeschakeld, in die zin dat het actief een geblokkeerde poort onderhoudt.

set spantree enable all

!--- This is the default.

Cisco raadt aan STP om de volgende redenen ingeschakeld te laten:

• Als er een lus is (geïnduceerd door foutieve patching, slechte kabel, enzovoort.), voorkomt STP schadelijke effecten op het netwerk veroorzaakt door multicast- en broadcast-gegevens.

• Bescherming tegen een uitval van EtherChannel.

• De meeste netwerken zijn geconfigureerd met STP, dat maximale veldbelichting geeft. Meer blootstelling komt over het algemeen overeen met stabiele code.

• Bescherming tegen dubbel aangesloten NIC's die zich misdragen (of bridging ingeschakeld op servers).

• De software voor veel protocollen (zoals PAgP, IGMP-snooping en trunking) is nauw verwant aan STP. Het lopen zonder STP kan tot ongewenste resultaten leiden.

Wijzig de timers niet, omdat dit een nadelige invloed kan hebben op de stabiliteit. De meerderheid van geïmplementeerde netwerken is niet afgestemd. De eenvoudige STP timers die via de opdrachtregel toegankelijk zijn, zoals hello-interval en Maxage, bestaan zelf uit een complexe set van andere veronderstelde en intrinsieke timers, dus het is moeilijk om timers af te stemmen en alle vertakkingen te overwegen. Bovendien bestaat het gevaar dat de bescherming van de UDLD wordt ondermijnd.

Ideaal gezien, houd gebruikersverkeer van het beheer VLAN. Vooral bij oudere Catalyst switch processors is het het beste om problemen met STP te voorkomen door het beheer VLAN gescheiden te houden van gebruikersgegevens. Eén eindstation dat zich misdraagt kan de supervisor-machineverwerker zo bezig houden met uitzendingspakketten dat het een of meer BPDU's kan missen. Maar nieuwere switches met krachtigere CPU's en gaspedalen maken dit minder belangrijk. Zie de sectie In-Band Management van dit document voor meer informatie.

Overontwerp geen redundantie. Dit kan leiden tot een nachtmerrie bij het oplossen van problemen - te veel blokkerende poorten hebben een negatieve invloed op de stabiliteit op de langere termijn. De totale NBP-diameter onder zeven hops houden. Probeer te ontwerpen op het Cisco meerlaagse model, met zijn kleinere switched domeinen, STP-driehoeken en deterministische geblokkeerde poorten (zoals uitgelegd in Gigabit Campus Network Design—Principles and Architecture) waar dat mogelijk is.

Invloed en weet waar de functionaliteit van de Wortel en de geblokkeerde havens verblijven, en documenteert hen op het topologiediagram. De geblokkeerde poorten zijn waar STP-probleemoplossing begint - wat ze van blokkering naar doorsturen heeft gemaakt, is vaak het belangrijkste onderdeel van de analyse van de basisoorzaak. Kies de distributie- en kernlagen als de locatie van wortel/secundaire wortel, aangezien deze worden beschouwd als de meest stabiele delen van het netwerk. Controleer op optimale L3- en HSRP-overlay met L2-datatranspaden. Dit bevel is een macro die de brugprioriteit vormt; De wortel plaatst het veel lager dan het gebrek (32768), terwijl wortel secundaire het redelijk lager dan het gebrek plaatst:

set spantree root secondary vlan range

Opmerking: Deze macro stelt de hoofdprioriteit in op 8192 (standaard), de huidige hoofdprioriteit minus 1 (als een andere root-brug bekend is) of de huidige hoofdprioriteit (als het MAC-adres lager is dan de huidige hoofdprioriteit).

Overbodige VLAN’s uitsluiten van trunkpoorten (een bidirectionele oefening). Dit beperkt de diameter van STP- en NMP-verwerkingsoverhead op delen van het netwerk waar bepaalde VLAN’s niet nodig zijn. VTP automatisch snoeien verwijdert STP niet uit een trunk. Raadpleeg de VTP-sectie van dit document voor meer informatie. De standaard VLAN 1 kan ook worden verwijderd van trunks met CatOS 5.4 en hoger.

Raadpleeg Problemen met Spanning Tree Protocol en verwante ontwerpoverwegingen voor meer informatie.

Overige opties

Cisco heeft een andere STP die bekend staat als VLAN-bridge. Dit protocol werkt met behulp van een bestemming MAC-adres van 01-00-0c-cd-cd-ce en protocoltype 0x010c.

Dit is het meest nuttig als er een noodzaak is om niet-routeerbare of legacy protocollen tussen VLAN’s te overbruggen zonder tussenkomst van de IEEE Spanning Tree-instantie(s) die op die VLAN’s actief is. Als VLAN-interfaces voor niet-overbrugd verkeer worden geblokkeerd voor L2-verkeer (en dit zou makkelijk kunnen gebeuren als ze aan dezelfde STP deelnamen als IP VLAN’s), wordt ook het overlay L3-verkeer per ongeluk weggesnoeid - een ongewenst neveneffect. VLAN-bridge is daarom een afzonderlijk geval van STP voor overbrugde protocollen, dat een afzonderlijke topologie biedt die kan worden gemanipuleerd zonder IP-verkeer te beïnvloeden.

Cisco raadt aan VLAN-bridge uit te voeren als overbrugging tussen VLAN’s op Cisco-routers zoals de MSFC vereist is.

PortFast

PortFast wordt gebruikt om de normale Spanning Tree-werking op toegangspoorten te omzeilen om de connectiviteit tussen eindstations en de services waarmee ze verbinding moeten maken na linkinitialisatie te versnellen. Voor sommige protocollen, zoals IPX/SPX, is het belangrijk om de toegangshaven te zien in de doorstuurmodus onmiddellijk nadat de verbindingsstaat is gestegen om problemen met GNS te voorkomen.

Zie Verbindingsvertragingen voor werkstations herstellen met Portfast en andere opdrachten voor meer informatie.

Operationeel overzicht

PortFast slaat de normale afluister- en leertoestanden van STP over door een poort direct van blokkering naar doorsturen modus te verplaatsen nadat bekend is dat de link actief is. Als deze functie niet is ingeschakeld, worden alle gebruikersgegevens door STP verwijderd totdat de poort klaar is om te worden verplaatst naar de verzendmodus. Dit kon tot tweemaal de ForwardDelay tijd (een totaal van 30 seconden door gebrek) vergen.

PortFast-modus voorkomt ook dat een STP-TCN wordt gegenereerd telkens wanneer een poortstaat verandert van leren naar doorsturen. TCN's zijn op zich geen probleem, maar als een golf van TCN's de root-brug raakt (meestal in de ochtend als mensen hun PC's aanzetten), zou het convergentietijd onnodig kunnen verlengen.

STP PortFast is met name belangrijk voor zowel multicast CGMP- als Catalyst 5500/5000 MLS-netwerken. TCN's in deze omgevingen kunnen ervoor zorgen dat de statische CGMP CAM-tabelvermeldingen worden verouderd, wat resulteert in multicast pakketverlies tot het volgende IGMP-rapport, en/of flush MLS-cacheingangen die dan opnieuw moeten worden opgebouwd en kunnen resulteren in een router CPU-piek, afhankelijk van de grootte van het cachegeheugen. (Catalyst 6500/6000 MLS-implementaties en multicast-vermeldingen die u hebt geleerd van IGMP-spionage, worden niet beïnvloed.)

Aanbeveling

Cisco raadt aan STP PortFast in te schakelen voor alle actieve hostpoorten en uit te schakelen voor switch-switch-koppelingen en poorten die niet in gebruik zijn.

Trunking en kanalisatie moeten ook worden uitgeschakeld voor alle hostpoorten. Elke toegangshaven is standaard ingeschakeld voor trunking en kanalisatie, maar switch-buren worden niet verwacht door ontwerp op host-poorten. Als deze protocollen nog moeten worden overeengekomen, kan de daaropvolgende vertraging in de poortactivering leiden tot ongewenste situaties waarin eerste pakketten van werkstations, zoals DHCP-verzoeken, niet worden doorgestuurd.

CatOS 5.2 introduceerde een macroopdracht, een poorthostpoortbereik dat deze configuratie implementeert voor toegangspoorten en aanzienlijk helpt bij autonegotiation en verbindingsprestaties:

set port host port range


!--- Macro command for these commands:

set spantree portfast port range enable
set trunk port range off
set port channel port range mode off

Opmerking: PortFast betekent niet dat Spanning Tree helemaal niet op die poorten wordt uitgevoerd. BPDU's worden nog steeds verzonden, ontvangen en verwerkt.

Overige opties

PortFast BPDU-guard biedt een manier om loops te voorkomen door een niet-trunkingpoort naar een erreless status te verplaatsen wanneer een BPDU op die poort wordt ontvangen.

Een BPDU-pakket moet nooit worden ontvangen op een toegangspoort die voor PortFast is geconfigureerd, aangezien hostpoorten niet aan switches mogen worden gekoppeld. Als een BPDU wordt geobserveerd, geeft dit een ongeldige en mogelijk gevaarlijke configuratie aan die bestuurlijke actie vereist. Wanneer de BPDU-guard functie is ingeschakeld, sluit Spanning Tree poortFast-geconfigureerde interfaces die BPDU's ontvangen, in plaats van ze in de STP-blokkerende staat te zetten.

Het commando werkt per switch, niet per poort, zoals wordt getoond:

set spantree portfast bpdu-guard enable

De netwerkbeheerder wordt door een SNMP-trap of syslog-bericht op de hoogte gesteld als de poort uitvalt. Het is ook mogelijk om een automatische hersteltijd voor opnieuw uitgeschakeld poorten te configureren. Raadpleeg het gedeelte UDLD van dit document voor meer informatie. Raadpleeg voor meer informatie Verbetering in Spanning Tree Portfast BPDU Guard.

Opmerking: PortFast voor trunkpoorten is geïntroduceerd in CatOS 7.x en heeft geen effect op trunkpoorten in eerdere releases. PortFast voor trunkpoorten is ontworpen om de convergentietijden voor L3-netwerken te verhogen. Om deze functie aan te vullen, introduceerde CatOS 7.x ook de mogelijkheid van de configuratie van PortFast BPDU-guard per poort.

UplinkFast

UplinkFast biedt snelle STP-convergentie na een directe koppelingsfout in de netwerktoegangslaag. Het wijzigt STP niet en het doel is om de convergentietijd in een specifieke omstandigheid te versnellen naar minder dan drie seconden, in plaats van de gebruikelijke vertraging van 30 seconden. Raadpleeg Begrijpen en configureren van de Cisco Uplink Fast Feature voor meer informatie.

Operationeel overzicht

Gebruikend het meerlaagse ontwerpmodel van Cisco bij de toegangslaag, als de het door:sturen opstraalverbinding wordt verloren, wordt de het blokkeren opstraalverbinding onmiddellijk verplaatst naar een het door:sturen staat zonder het wachten op het luisteren en het leren staten.

Een uplinkgroep is een verzameling poorten per VLAN die kan worden gezien als een hoofdpoort en een back-uphoofdpoort. Onder normale omstandigheden garanderen de wortelpoort(en) connectiviteit van de toegang tot de wortel. Als deze primaire wortel-verbinding om het even welke reden ontbreekt, de reservewortelverbinding onmiddellijk zonder het moeten door typische 30 seconden van convergentievertraging gaan.

Omdat dit effectief het normale STP topologie verandering-behandelend proces (het luisteren en het leren) omzeilt, is een alternatief mechanisme van de topologiecorrectie nodig om switches in het domein bij te werken dat de lokale eindposten door een afwisselende weg bereikbaar zijn. De switch van de toegangslaag die UplinkFast in werking stelt produceert ook kaders voor elk adres van MAC in zijn CAM aan een multicast adres van MAC (01-00-0c-cd-cd-cd, HDLC protocol 0x200a) om de CAM lijst in alle switches in het domein met de nieuwe topologie bij te werken.

Aanbeveling

Cisco raadt aan UplinkFast in te schakelen voor switches met geblokkeerde poorten, doorgaans op de toegangslaag. Niet gebruiken op switches zonder de impliciete topologiekennis van een reservewortelverbinding - typisch distributie en kern switches in het meerlaagse ontwerp van Cisco. Het kan worden toegevoegd zonder onderbreking van een productienetwerk. Geef deze opdracht uit om UplinkFast in te schakelen:

set spantree uplinkfast enable 

Dit commando stelt ook de brugprioriteit hoog in om het risico te minimaliseren dat dit een root-brug wordt en de havenprioriteit hoog om te minimaliseren dat het een aangewezen poort wordt, die de functionaliteit breekt. Wanneer u een switch herstelt die UplinkFast ingeschakeld had, moet de functie worden uitgeschakeld, de uplink-database gewist met "clear uplink" en de overbruggingsprioriteiten handmatig hersteld.

Opmerking: het sleutelwoord all protocols voor de opdracht UplinkFast is nodig wanneer de functie voor protocolfiltering is ingeschakeld. Aangezien de CAM het protocoltype evenals de informatie van MAC en VLAN registreert wanneer het protocol filtering wordt toegelaten, moet een kader UplinkFast voor elk protocol op elk adres van MAC worden geproduceerd. Het snelheidssleutelwoord geeft de pakketten per seconde aan van de updatekaders van de uplinkfast topologie. De standaardinstelling wordt aanbevolen. U hoeft BackboneFast niet te configureren met Rapid STP (RSTP) of IEEE 802.1w omdat het mechanisme standaard is opgenomen en automatisch is ingeschakeld in RSTP.

Backbone Fast

BackboneFast biedt snelle convergentie van indirecte koppelingsfouten. Met de toegevoegde functionaliteit aan STP, kunnen de convergentietijden typisch van het gebrek van 50 seconden tot 30 seconden worden verminderd.

Operationeel overzicht

Het mechanisme wordt geïnitieerd wanneer een wortelhaven of een geblokkeerde haven op een switch inferieure BPDUs van zijn aangewezen brug ontvangen. Dit kan gebeuren wanneer een stroomafwaartse switch zijn verbinding met de wortel heeft verloren en zijn eigen BPDUs begint te verzenden om een nieuwe wortel te selecteren. Een inferieure BPDU identificeert een switch als zowel de root-brug als de aangewezen brug.

Onder normale Spanning Tree-regels negeert de ontvangende switch inferieure BPDU's voor de geconfigureerde maximale verouderingstijd, standaard 20 seconden. Met BackboneFast ziet de switch de inferieure BPDU echter als een signaal dat de topologie had kunnen veranderen, en probeert te bepalen of het een alternatief pad naar de root-brug heeft met behulp van Root Link Query (RLQ) BPDU's. Deze protocoltoevoeging staat een switch toe om te controleren of de wortel nog beschikbaar is, verplaatst een geblokkeerde poort naar doorsturen in minder tijd, en waarschuwt de geïsoleerde switch die de inferieure BPDU heeft verzonden dat de wortel nog steeds daar is.

Dit zijn een paar hoogtepunten van de protocolverrichting:

• Een switch stuurt het RLQ-pakket alleen vanuit de hoofdpoort (dat wil zeggen, naar de root-brug).

• Een switch die een RLQ ontvangt kan antwoorden of als het de wortel switch is, of als het weet dat het verbinding met de wortel heeft verloren. Als het deze feiten niet kent, moet het de vraag uit zijn wortelhaven door:sturen.

• Als een switch verbinding met de wortel heeft verloren, moet het in negatief op deze vraag antwoorden.

• Het antwoord moet alleen worden verzonden vanuit de haven waar de vraag vandaan kwam.

• De root switch moet altijd reageren op deze query met een positief antwoord.

• Als het antwoord op een niet-wortelhaven wordt ontvangen, wordt het verworpen.

STP-convergentietijden kunnen daarom tot 20 seconden verkort worden, omdat deze limiet niet hoeft te verlopen.

Raadpleeg Backbone Fast begrijpen en configureren op Catalyst-Switches voor meer informatie.

Aanbeveling

Het is raadzaam van Cisco om BackboneFast in te schakelen op alle switches met STP. Het kan worden toegevoegd zonder onderbreking van een productienetwerk. Geef deze opdracht uit om BackboneFast in te schakelen:

set spantree backbonefast enable

Opmerking: deze opdracht op mondiaal niveau moet op alle switches in een domein worden geconfigureerd, omdat het functionaliteit toevoegt aan het STP-protocol dat alle switches moeten begrijpen.

Overige opties

BackboneFast wordt niet ondersteund op 2900XL's en 3500s. Het moet niet worden ingeschakeld als het switch-domein deze switches bevat naast Catalyst 4500/4000, 5500/5000 en 6500/6000 switches.

U hoeft BackboneFast niet te configureren met RSTP of IEEE 802.1w omdat het mechanisme standaard is opgenomen en automatisch is ingeschakeld in RSTP.

Spanning Tree Loop Guard

Loop guard is een eigen optimalisatie van Cisco voor STP. Loop guard beschermt L2 netwerken tegen lussen die veroorzaakt worden door:

• Netwerkinterfaces die defect zijn

• Bezette CPU’s

• Alles wat het normale doorsturen van BPDU's verhindert

Een lijn STP komt voor wanneer een blokkerende haven in een overtollige topologie foutief overgangen naar de door:sturen staat. Deze overgang gebeurt gewoonlijk omdat één van de poorten in een fysiek redundante topologie (niet noodzakelijk de blokkerende poort) ophoudt BPDU's te ontvangen.

Loop guard is alleen bruikbaar in switched netwerken waar switches verbonden zijn door point-to-point links. De meeste moderne campus- en datacenternetwerken zijn dit soort netwerken. Voor een punt-tot-punt verbinding, kan een aangewezen brug niet verdwijnen tenzij het een inferieure BPDU verzendt of de verbinding neer brengt. De STP-lusbeveiliging werd geïntroduceerd in CatOS versie 6.2(1) voor Catalyst 4000 en Catalyst 5000 platforms en in versie 6.2(2) voor Catalyst 6000 platform.

Raadpleeg Verbeteringen in Spanning-Tree Protocol met behulp van Loop Guard en BPDU Skew Detection-functies voor meer informatie over lusbeveiliging.

Operationeel overzicht

Loop guard controleert om te bepalen of een root poort of een alternatieve / back-up root poort BPDU's ontvangt. Als de poort geen BPDU's ontvangt, wordt de poort door lusbeveiliging in een inconsistente status (blokkering) geplaatst totdat de poort begint met het opnieuw ontvangen van BPDU's. Een poort in de inconsistente status verzendt geen BPDU's. Als zo'n poort opnieuw BPDU's ontvangt, wordt de poort (en link) opnieuw levensvatbaar geacht. De loop-inconsistente voorwaarde wordt verwijderd uit de poort en de STP bepaalt de poortstatus omdat een dergelijk herstel automatisch is.

Loop guard isoleert de fout en laat het overspannen - boom samenkomen in een stabiele topologie zonder de mislukte link of brug. Loop guard voorkomt STP loops met de snelheid van de STP versie in gebruik. Er is geen afhankelijkheid van STP zelf (802.1d of 802.1w) of wanneer de STP-timers worden afgestemd. Om deze redenen, implementeer loop guard in combinatie met UDLD in topologieën die vertrouwen op STP en waar de software de functies ondersteunt.

Wanneer de lusbescherming een inconsistente poort blokkeert, wordt dit bericht vastgelegd:

%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated
in VLAN 77. Moved to root-inconsistent state.

Wanneer de BPDU op een poort wordt ontvangen in een loop-inconsistente STP-status, verandert de poort in een andere STP-status. In overeenstemming met de ontvangen BPDU, de terugwinning is automatisch, en geen interventie is noodzakelijk. Na het herstel wordt dit bericht vastgelegd.

SPANTREE-2-LOOPGUARDUNBLOCK: port 3/2 restored in vlan 3.

Interactie met andere STP-functies

• Root Guard

  De hoofdbewaker dwingt een haven af die altijd moet worden aangewezen. Loop guard is alleen effectief als de port de wortelpoort is of een alternatieve poort. Deze functies sluiten elkaar wederzijds uit. Loop guard en root guard kunnen niet tegelijkertijd worden ingeschakeld op een poort.

• UplinkFast

  Loop guard is compatibel met UplinkFast. Als de lijnwacht een wortelhaven in een blokkerende staat zet, zet UplinkFast een nieuwe wortelhaven in het door:sturen van staat. Ook, selecteert UplinkFast geen lijn-inconsistente poort als wortelpoort.

• Backbone Fast

  Loop guard is compatibel met BackboneFast. De ontvangst van een inferieure BPDU die van een aangewezen brug komt brengt BackboneFast teweeg. Omdat BPDU's van deze link worden ontvangen, wordt lusbeveiliging niet geactiveerd, zodat BackboneFast en lusbeveiliging compatibel zijn.

• PortFast

  PortFast zet een poort onmiddellijk na de verbinding over naar de door-sturen aangewezen staat. Omdat een PortFast-enabled poort geen root of alternatieve poort kan zijn, sluiten lusbeveiliging en PortFast elkaar wederzijds uit.

• PAgP

  Loop guard gebruikt de poorten die bekend zijn bij STP. Daarom kan de loopwacht voordeel halen uit de abstractie van logische poorten die PAgP biedt. Om een kanaal te vormen, moeten alle fysieke poorten die zijn gegroepeerd in het kanaal compatibele configuraties hebben. PAgP dwingt de uniforme configuratie van lusbeveiliging op alle fysieke poorten af om een kanaal te vormen.

  Opmerking: dit zijn voorbehouden bij het configureren van lusbewaking op een EtherChannel:

  • STP kiest altijd de eerste operationele poort in het kanaal om de BPDU's te verzenden. Als die link unidirectioneel wordt, blokkeert de lusbewaker het kanaal, zelfs als andere koppelingen in het kanaal goed functioneren.

  • Als poorten die al worden geblokkeerd door lusbeveiliging worden gegroepeerd om een kanaal te vormen, verliest STP alle statusinformatie voor die poorten. De nieuwe kanaalpoort kan de verzendstaat bereiken met een aangewezen rol.

  • Als een kanaal wordt geblokkeerd door looppas bewaker en de kanaalonderbrekingen, verliest STP alle staatsinformatie. De individuele fysieke poorten kunnen de doorsturen staat bereiken met een aangewezen rol, zelfs als een of meer van de koppelingen die het kanaal vormden unidirectioneel zijn.

  In de laatste twee gevallen in deze lijst is er een mogelijkheid van een lus totdat UDLD de fout detecteert. Maar lusbescherming is niet in staat om de lus te detecteren.

Vergelijking van functies voor Loop Guard en UDLD

De functionaliteit van de lusbewaker en de functionaliteit UDLD gedeeltelijk overlappen. Beiden beschermen tegen STP-fouten die unidirectionele links veroorzaken. Maar deze twee kenmerken zijn verschillend in de benadering van het probleem en ook in functionaliteit. Met name zijn er bepaalde unidirectionele storingen die UDLD niet kan detecteren, zoals storingen die worden veroorzaakt door een CPU die geen BPDU's verzendt. Bovendien kan het gebruik van agressieve STP-timers en RSTP-modus resulteren in lussen voordat UDLD de storingen kan detecteren.

Loop guard werkt niet op gedeelde links of in situaties waarin de link unidirectioneel is geweest sinds de koppeling. In het geval dat de verbinding sinds de verbinding unidirectioneel is geweest, ontvangt de haven nooit BPDUs en wordt aangewezen. Dit gedrag kan normaal zijn, dus lusbescherming dekt dit specifieke geval niet. UDLD biedt bescherming tegen een dergelijk scenario.

Schakel zowel de UDLD als de lusbeveiliging in om het hoogste beschermingsniveau te bieden. Raadpleeg het gedeelte Loop Guard vs. Unidirectional Link Detection van de verbeteringen van Spanning-Tree Protocol met Loop Guard en BPDU Skew Detection Properties voor een vergelijking van lusbewakers en UDLD-functies.

Aanbeveling

Cisco raadt u aan loop guard globaal toe te laten op een switch netwerk met fysieke loops. In versie 7.1(1) van de Catalyst-software en hoger kunt u lusbeveiliging wereldwijd op alle poorten inschakelen. Deze optie is effectief ingeschakeld voor alle point-to-point links. De duplexstatus van de link detecteert de point-to-point link. Als duplex volledig is, wordt de link beschouwd als point-to-point. Geef dit commando uit om global loop guard mogelijk te maken:

set spantree global-default loopguard enable

Overige opties

Voor switches die de globale configuratie van de lijnwacht niet steunen, laat de eigenschap op alle individuele havens toe, die de havens van het havenkanaal omvat. Alhoewel er geen voordelen zijn om lusbescherming op een aangewezen haven toe te laten, is dit geen kwestie. Bovendien kan een geldige overspannen - boomreconvergentie een aangewezen haven in een wortelhaven eigenlijk veranderen, die de eigenschap op deze haven nuttig maakt. Geef deze opdracht uit om loop guard mogelijk te maken:

set spantree guard loop mod/port

Netwerken met lusvrije topologieën kunnen nog steeds profiteren van loop guard in het geval dat loops per ongeluk worden geïntroduceerd. Echter, het inschakelen van loop guard in dit type van topologie kan leiden tot netwerk isolatie problemen. Om lijn-vrije topologieën te bouwen en netwerk isolatieproblemen te vermijden, geef deze bevelen uit om lijn wacht globaal of individueel onbruikbaar te maken. Schakel geen loop guard in op gedeelde links.

• set spantree global-default loopguard disable
  
  !--- This is the global default.
  
  

  of

• set spantree guard none mod/port
  
  
  !--- This is the default port configuration.
  
  

Spanning Tree Root Guard

De root guard-functie biedt een manier om de plaatsing van de root-brug in het netwerk af te dwingen. Root guard zorgt ervoor dat de poort waarop root guard is ingeschakeld de aangewezen poort is. Normaal gesproken zijn root-brugpoorten allemaal aangewezen poorten, tenzij twee of meer poorten van de root-brug met elkaar zijn verbonden. Als de brug superieure STP BPDUs op een wortelbewaker-toegelaten haven ontvangt, beweegt de brug deze haven naar een wortel-inconsistente STP staat. Deze root-inconsistente toestand is effectief gelijk aan een luistertoestand. Over deze poort wordt geen verkeer doorgestuurd. Op deze manier wordt de positie van de root-brug afgedwongen. Root guard is beschikbaar in CatOS voor Catalyst 29xx, 4500/4000, 5500/5000 en 6500/6000 in softwareversie 6.1.1 en hoger.

Operationeel overzicht

Root guard is een STP-ingebouwd mechanisme. Root guard heeft geen eigen timer en is alleen afhankelijk van de ontvangst van BPDU. Wanneer root guard wordt toegepast op een port, kan root guard geen port worden om een root port te worden. Als de ontvangst van een BPDU een overspannende boomconvergentie teweegbrengt die een aangewezen haven een wortelhaven maakt worden, wordt de haven gezet in een wortel-inconsistente staat. Dit syslogbericht toont de actie:

%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated
in VLAN 77. Moved to root-inconsistent state

Nadat de poort stopt met het verzenden van superieure BPDU's wordt de poort opnieuw ontgrendeld. Door STP gaat de poort van de luisterstaat naar de leerstaat en uiteindelijk naar de doorstuurstaat. Herstel is automatisch en er is geen menselijk ingrijpen nodig. Dit syslogbericht geeft een voorbeeld:

%SPANTREE-2-ROOTGUARDUNBLOCK: Port 1/1 restored in VLAN 77

Root guard dwingt een poort aan te wijzen en loop guard is alleen effectief als de poort de root poort is of een alternatieve poort. Daarom sluiten de twee functies elkaar uit. Loop guard en root guard kunnen niet tegelijkertijd worden ingeschakeld op een poort.

Raadpleeg Verbetering in Spanning Tree Protocol Root Guard voor meer informatie.

Aanbeveling

Cisco raadt u aan de functie voor basisbewaking in te schakelen op poorten die verbinding maken met netwerkapparaten die niet onder directe administratieve controle staan. Om wortelwacht te vormen, geef dit bevel uit:

set spantree guard root mod/port

EtherChannel

EtherChannel-technologieën maken het inverse multiplexing van meerdere kanalen (tot acht op Catalyst 6500/6000) mogelijk in één logische link. Hoewel elk platform verschilt van de volgende in implementatie, is het belangrijk om de gemeenschappelijke vereisten te begrijpen:

• Een algoritme om statistisch multiplex frames over meerdere kanalen

• Creatie van een logische poort zodat één instantie van STP kan worden uitgevoerd

• Een kanaalbeheerprotocol zoals PAgP of Link Aggregation Control Protocol (LACP)

Frame Multiplexing

EtherChannel omvat een frame distributiealgoritme dat op efficiënte wijze frames over de component 10/100 of gigabit links multiplext. Verschillen in algoritmen per platform ontstaan door het vermogen van elk type hardware om framekopbal informatie te halen om de distributiebeslissing te nemen.

Het algoritme van de ladingsdistributie is een globale optie voor beide kanaal-controle protocollen. PAgP en LACP gebruiken het frame-distributiealgoritme omdat de IEEE-standaard geen specifieke distributie-algoritmen verplicht. Een distributiealgoritme zorgt er echter voor dat, wanneer frames ontvangen worden, het algoritme niet de misschikking veroorzaakt van frames die deel uitmaken van een bepaalde conversatie of duplicatie van frames.

Opmerking: Deze informatie moet in aanmerking worden genomen:

• Catalyst 6500/6000 heeft meer recente schakelhardware dan Catalyst 5500/5000 en kan IP Layer 4 (L4)-informatie lezen met een bedradingssnelheid om een intelligentere multiplexing-beslissing te maken dan eenvoudige MAC L2-informatie.

• De mogelijkheden van Catalyst 5500/5000 zijn afhankelijk van de aanwezigheid van een Ethernet Bundling Chip (EBC) op de module. De mod/poortopdracht voor mod/poort van show port bevestigt wat voor elke poort mogelijk is.

Verwijs naar deze lijst, die het algoritme van de kaderdistributie voor elk vermeld platform in detail illustreert:

¹ FEC = Fast EtherChannel

² UDP = User Datagram Protocol

Deze tabel geeft de distributiemethoden aan die worden ondersteund op de verschillende Catalyst 6500/6000 Supervisor Engine-modellen en hun standaardgedrag.

Opmerking: bij L4-distributie maakt het eerste gefragmenteerde pakket gebruik van L4-distributie. Alle volgende pakketten gebruiken L3 distributie.

Meer informatie over EtherChannel-ondersteuning op andere platforms en hoe u deze kunt configureren en oplossen, vindt u in deze documenten:

• Inzicht in EtherChannel-taakverdeling en redundantie op Catalyst-switches

• EtherChannel configureren tussen Catalyst 4500/4000, 5500/5000 en 6500/6000 switches met CatOS-systeemsoftware

• LACP (802.3ad) configureren tussen een Catalyst 6500/6000 en een Catalyst 4500/4000 switch

• Layer 3 en Layer 2 EtherChannel configureren

Aanbeveling

Catalyst 6500/6000 Series switches voeren standaard taakverdeling op IP-adres uit. Dit wordt aanbevolen in CatOS 5.5, ervan uitgaande dat IP het dominante protocol is. Geef deze opdracht uit om taakverdeling in te stellen:

set port channel all distribution ip both

!--- This is the default.

Catalyst 4500/4000 en 5500/5000 Series frameverdeling door L2 MAC-adres is in de meeste netwerken aanvaardbaar. Echter, dezelfde link wordt gebruikt voor al het verkeer als er slechts twee hoofdapparaten zijn die over een kanaal praten (als SMAC en DMAC constant zijn). Dit kan typisch een kwestie voor serverback-up en andere grote bestandsoverdrachten zijn of voor een transitesegment tussen twee routers.

Hoewel de logische aggregaatpoort (agport) door SNMP kan worden beheerd als een afzonderlijke instantie en geaggregeerde doorvoerstatistieken kunnen worden verzameld, raadt Cisco u nog steeds aan om elk van de fysieke interfaces afzonderlijk te beheren om te controleren hoe de framedistributiemechanismen werken en of statistische taakverdeling wordt bereikt.

Een nieuwe opdracht, de show channel traffic commando, in CatOS 6.x kan de statistieken van de percentagedistributie eenvoudiger weergeven dan wanneer u individuele poorttellers controleert met de show tellers mod/port commando of de show mac mod/port commando in CatOS 5.x. Een andere nieuwe opdracht, de show channel hash commando, in CatOS 6.x kunt u controleren, gebaseerd op de distributiemodus, welke poort zou worden geselecteerd als de uitgaande poort voor bepaalde adressen en/of poortnummers. De equivalente opdrachten voor LACP-kanalen zijn de show lacp-channel traffic commando en de show lacp-channel hash commando.

Overige opties

Dit zijn mogelijke stappen om te nemen als de relatieve beperkingen van op Catalyst 4500/4000 of Catalyst 5500/5000 op MAC gebaseerde algoritmen een probleem zijn en geen goede statistische taakverdeling wordt bereikt:

• Point-opstellen van Catalyst 6500/6000 switches

• Vergroot de bandbreedte zonder kanalisatie door bijvoorbeeld te schakelen van meerdere FE-poorten naar één GE-poort of van meerdere GE-poorten naar één 10 GE-poort

• Richt paren van eindstations met grote volumestromen opnieuw

• Speciale links/VLAN’s voor apparaten met hoge bandbreedte

Richtlijnen en beperkingen voor EtherChannel-configuratie

EtherChannel verifieert poorteigenschappen op alle fysieke poorten voordat het compatibele poorten samenvoegt tot één logische poort. De configuratierichtlijnen en -beperkingen verschillen voor de verschillende switch-platforms. Volg de richtlijnen om problemen met de bundeling te voorkomen. Als QoS bijvoorbeeld is ingeschakeld, vormen EtherChannel geen modules die Catalyst 6500/6000 Series switches met verschillende QoS-mogelijkheden bundelen. In Cisco IOS-software kunt u de controle van de QoS-poortkenmerken op de EtherChannel-bundeling uitschakelen met de opdracht Geen MLS QoS-kanaal-consistentie poortkanaal-kanaal interface. Een equivalente opdracht om de controle van de QoS-poortkenmerken uit te schakelen, is niet beschikbaar in CatOS. U kunt de mod/poortopdracht voor show port geven om de QoS-poortcapaciteit weer te geven en te bepalen of poorten compatibel zijn.

Volg deze richtlijnen voor verschillende platforms om configuratieproblemen te voorkomen:

• De sectie EtherChannel Configuration Guidelines bij het configureren van EtherChannel (Catalyst 6500/6000)

• Het gedeelte EtherChannel Configuration Guidelines and Restrictions van Fast EtherChannel en Gigabit EtherChannel (Catalyst 4500/4000)

• Het gedeelte EtherChannel Configuration Guidelines and Restrictions van Fast EtherChannel en Gigabit EtherChannel (Catalyst 5000)

Opmerking: het maximale aantal poortkanalen dat door Catalyst 4000 wordt ondersteund, is 126. Met softwarereleases 6.2(1) en eerder ondersteunen de Catalyst 6500 Series switches met zes en negen sleuven maximaal 128 EtherChannel. In softwarerelease 6.2(2) en latere releases, verwerkt de overspanningsboomfunctie de poort-ID. Daarom is het maximumaantal EtherChannel met ondersteuning 126 voor een zes- of negen-sleuven chassis en 63 voor een 13-sleuven chassis.

Poortaggregatieprotocol

PAgP is een beheerprotocol dat aan beide uiteinden van de link controleert op parameterconsistentie en het kanaal helpt zich aan te passen aan koppelingsuitval of toevoeging. Let op deze feiten over PAgP:

• PAgP vereist dat alle poorten in het kanaal tot hetzelfde VLAN behoren of als trunkpoorten zijn geconfigureerd. (Omdat dynamische VLAN’s de wijziging van een poort in een ander VLAN kunnen afdwingen, zijn ze niet opgenomen in de EtherChannel-deelname.)

• Wanneer een bundel reeds bestaat en de configuratie van één haven wordt gewijzigd (zoals veranderend VLAN of trunking wijze), worden alle havens in de bundel gewijzigd om die configuratie aan te passen.

• PAgP groepeert geen poorten die op verschillende snelheden of poortduplex werken. Als snelheid en duplex worden veranderd wanneer een bundel bestaat, verandert PAgP de poortsnelheid en duplex voor alle poorten in de bundel.

Operationeel overzicht

De PAgP-poort regelt elke afzonderlijke fysieke (of logische) poort die moet worden gegroepeerd. PAgP-pakketten worden verzonden met hetzelfde multicast groep MAC-adres dat wordt gebruikt voor CDP-pakketten, 01-00-0c-cc-cc-cc. De protocolwaarde is 0x0104. Dit is een samenvatting van de protocolbewerking:

• Zolang de fysieke poort omhoog is, worden PAgP-pakketten elke seconde tijdens de detectie en elke 30 seconden in de stationaire toestand verzonden.

• Het protocol luistert naar PAgP-pakketten die aantonen dat de fysieke poort een tweerichtingsverbinding heeft met een ander PAgP-apparaat.

• Als er gegevenspakketten maar geen PAgP-pakketten worden ontvangen, wordt aangenomen dat de poort is aangesloten op een apparaat dat niet voor PAgP geschikt is.

• Zodra er twee PAgP-pakketten zijn ontvangen op een groep fysieke poorten, probeert het een geaggregeerde poort te vormen.

• Als PAgP-pakketten een bepaalde tijd stoppen, wordt de status PAgP omlaag gedraaid.

Normale verwerking

Deze begrippen moeten worden gedefinieerd om een beter inzicht te krijgen in het gedrag van het protocol:

• Agport - een logische poort die bestaat uit alle fysieke poorten in dezelfde aggregatie, kan worden geïdentificeerd door zijn eigen SNMP ifIndex. Daarom bevat een luchthaven geen niet-operationele havens.

• kanaal—een aggregatie die voldoet aan de vormingscriteria; zij zou derhalve niet-operationele havens kunnen bevatten (agports zijn een subset van kanalen). Protocollen met inbegrip van STP en VTP, maar exclusief CDP en DTP, lopen boven PAgP over de poorten. Geen van deze protocollen kan pakketten verzenden of ontvangen totdat PAgP hun poorten aan een of meer fysieke poorten heeft gekoppeld.

• Group Capability—elke fysieke poort en poort bezit een configuratieparameter die de groep-mogelijkheid wordt genoemd. Een fysieke poort kan alleen dan worden samengevoegd met een andere fysieke poort als en alleen als ze dezelfde groepsmogelijkheid hebben.

• Aggregatieprocedure—wanneer een fysieke poort de UpData- of UpPAgP-status bereikt, is deze poort gekoppeld aan een juiste poort. Als het een van deze staten verlaat voor een andere staat, wordt het losgekoppeld van de agport.

De definities van de staten en de creatieprocedures worden in deze tabel gegeven:

Beide uiteinden van beide verbindingen moeten het eens worden over wat de groepering zal zijn, die als grootste groep havens in de haven wordt gedefinieerd die door beide einden van de verbinding wordt toegestaan.

Wanneer een fysieke poort de UpPAgP-status bereikt, wordt deze toegewezen aan de poort die fysieke poorten van leden heeft die overeenkomen met de groep-mogelijkheid van de nieuwe fysieke poort en die zich in de toestanden BiDir of UpPAgP bevinden. (Al deze BiDir-poorten worden tegelijkertijd naar de UpPAgP-status verplaatst.) Als er geen poort is waarvan de samenstellende fysieke poortparameters compatibel zijn met de nieuw klaargemaakte fysieke poort, wordt deze toegewezen aan een poort met geschikte parameters die geen bijbehorende fysieke poorten heeft.

Een PAgP timeout kan voorkomen op de laatste buurman die bekend is op de fysieke poort. De poorttiming wordt van de poort verwijderd. Tegelijkertijd worden alle fysieke poorten op dezelfde poort waarvan de timers ook hebben uitgetimed verwijderd. Dit maakt het mogelijk dat een agport waarvan het andere uiteinde is gestorven, in één keer wordt afgebroken, in plaats van één fysieke poort per keer.

Gedrag in falen

Als een koppeling in een bestaand kanaal is mislukt (bijvoorbeeld poort is losgekoppeld, Gigabit Interface Converter [GBIC] is verwijderd of glasvezel is gebroken), wordt de poort bijgewerkt en wordt het verkeer binnen een seconde over de resterende koppelingen gehakt. Elk verkeer dat na de storing niet opnieuw hoeft te worden gecensureerd (verkeer dat dezelfde link blijft gebruiken) hoeft geen verlies te lijden. Het herstel van de mislukte link zorgt voor een nieuwe update van de poort en het verkeer wordt weer gehakt.

Opmerking: Het gedrag wanneer een link in een kanaal mislukt door een uitschakeling of het verwijderen van een module kan anders zijn. Per definitie moeten er twee fysieke poorten naar een kanaal zijn. Als één poort verloren is van het systeem in een twee-poorts kanaal, wordt de logische poort uitgeschakeld en wordt de oorspronkelijke fysieke poort opnieuw geïnitialiseerd met betrekking tot Spanning Tree. Dit betekent dat verkeer kan worden verwijderd tot STP de poort weer beschikbaar maakt voor gegevens.

Er is een uitzondering op deze regel op Catalyst 6500/6000. In eerdere versies dan CatOS 6.3 wordt een poort niet afgebroken tijdens de verwijdering van de module als het kanaal uitsluitend bestaat uit poorten op modules 1 en 2.

Dit verschil in de twee storingsmodi is belangrijk wanneer het onderhoud van een netwerk gepland is, aangezien er een STP TCN kan zijn om te overwegen wanneer het uitvoeren van een online verwijdering of een toevoeging van een module. Zoals gezegd is het belangrijk om elke fysieke verbinding in het kanaal met de NMS te beheren, aangezien de poort ongestoord kan blijven door een storing.

Dit zijn voorgestelde stappen om een ongewenste topologieverandering op Catalyst 6500/6000 te verlichten:

• Als per module één poort wordt gebruikt om een kanaal te vormen, moeten drie of meer modules worden gebruikt (drie poorten of meer in totaal).

• Als het kanaal twee modules omvat, moeten er twee poorten op elke module worden gebruikt (vier poorten in totaal).

• Als een twee-poorts kanaal nodig is over twee kaarten, gebruik dan alleen de Supervisor Engine poorten.

• Upgrade naar CatOS 6.3, die module-verwijdering verwerkt zonder STP-herberekening voor kanalen die over modules zijn verdeeld.

Configuratieopties

EtherChannel kan in verschillende modi worden geconfigureerd, zoals in deze tabel is samengevat:

De stille/niet-stille instellingen beïnvloeden hoe poorten reageren op situaties die unidirectioneel verkeer veroorzaken of hoe ze failover bereiken. Wanneer een poort niet kan verzenden (bijvoorbeeld door een mislukte fysieke sublaag [PHY] of een kapotte glasvezel of kabel), kan de buurpoort nog steeds in een operationele staat blijven. De partner blijft gegevens verzenden, maar gegevens gaan verloren, omdat er geen retourverkeer kan worden ontvangen. Spanning Tree loops kunnen ook worden gevormd door de unidirectionele aard van de link.

Sommige glasvezelpoorten hebben de gewenste mogelijkheid om de poort naar een niet-operationele status te brengen wanneer deze het ontvangstsignaal (FEFI) verliest. Dit zorgt ervoor dat de partnerhaven niet-operationeel wordt en zorgt er effectief voor dat de havens aan beide uiteinden van de verbinding naar beneden gaan.

Bij het gebruik van apparaten die gegevens verzenden (zoals BPDU's) en geen unidirectionele omstandigheden kunnen detecteren, moet een niet-stille modus worden gebruikt om de poorten buiten bedrijf te laten blijven totdat de ontvangstgegevens aanwezig zijn en de koppeling wordt geverifieerd als bidirectioneel. De tijd die er voor PAgP nodig is om een unidirectionele link te detecteren ligt rond 3,5 * 30 seconden = 105 seconden, waarbij 30 seconden de tijd is tussen twee opeenvolgende PAgP berichten. UDLD wordt aanbevolen als een snellere detector voor unidirectionele koppelingen.

Wanneer apparaten worden gebruikt die geen gegevens verzenden, moet de stille modus worden gebruikt. Dit dwingt de poort om verbonden en operationeel te worden, ongeacht of de ontvangen gegevens aanwezig zijn of niet. Bovendien, voor die poorten die de aanwezigheid van een unidirectionele voorwaarde kunnen detecteren, zoals nieuwere platforms met L1 FEFI en UDLD, wordt de stille modus standaard gebruikt.

Verificatie

In de tabel wordt een overzicht gegeven van alle mogelijke scenario's voor PAgP-kanaalmodus tussen twee direct verbonden switches (Switch-A en Switch-B). Sommige van deze combinaties kunnen STP veroorzaken om de poorten aan de kanaliserende kant in de erreless staat (dat wil zeggen, sommige van de combinaties sluiten de poorten aan de kanaliserende kant).

Aanbeveling

Cisco raadt aan om PAgP in te schakelen op alle switch-naar-switch kanaalverbindingen, zonder gebruik van de modus. De voorkeurmethode is om de gewenste modus aan beide uiteinden van een link in te stellen. Het is raadzaam om het stille/niet-stille trefwoord standaard te laten staan - stil op Catalyst 6500/6000 en 4500/4000 switches, niet-stil op Catalyst 5500/5000 glasvezelpoorten.

Zoals besproken in dit document, is de expliciete configuratie van het uitsturen op alle andere poorten nuttig voor het snel doorsturen van gegevens. Wachten tot 15 seconden op PAgP naar timeout op een poort die niet gebruikt wordt voor het kanaliseren moet vermeden worden, vooral omdat de poort dan wordt overgedragen aan STP, die zelf 30 seconden kan duren om data-doorsturen toe te staan, plus mogelijk 5 seconden voor DTP voor een totaal van 50 seconden. Het ingestelde poorthostcommando wordt in de STP-sectie van dit document meer in detail besproken.

set port channel port range mode desirable

set port channel port range mode off

!--- Ports not channeled; part of the set port hostcommand.

Deze opdracht wijst kanalen een admin groep nummer toe, gezien met een show channel groep opdracht. Toevoeging en verwijdering van het kanaliseren van poorten naar dezelfde poort kan dan worden beheerd door het admin nummer indien gewenst.

Overige opties

Een andere gemeenschappelijke configuratie voor klanten die een model van minimaal beheer bij de toegangslaag hebben is de wijze te plaatsen aan wenselijk bij de distributie en kernlagen, en de switches van de toegangslaag bij de standaard autoconfiguratie te verlaten.

Bij het kanaliseren naar apparaten die geen PAgP ondersteunen, moet het kanaal hard-gecodeerd worden op. Dit is van toepassing op apparaten zoals servers, Local Director, content switches, routers, switches met oudere software, Catalyst XL switches en Catalyst 8540s. Voer de volgende opdracht uit:

set port channel port range mode on

De nieuwe 802.3ad IEEE LACP-standaard, beschikbaar in CatOS 7.x, zal waarschijnlijk op de lange termijn de opvolger van PAgP zijn, omdat het voordeel van cross-platform en leverancier interoperabiliteit brengt.

Link Aggregation Control Protocol

LACP is een protocol dat het mogelijk maakt dat havens met soortgelijke eigenschappen een kanaal vormen door middel van dynamische onderhandelingen met aangrenzende switches. PAgP is een bedrijfseigen Cisco-protocol dat alleen op Cisco-switches kan worden uitgevoerd en op switches die door gelicentieerde leveranciers worden vrijgegeven. Maar LACP, dat in IEEE 802.3ad wordt gedefinieerd, stelt Cisco-switches in staat Ethernet-kanalisatie te beheren met apparaten die voldoen aan de 802.3ad-specificatie. CatOS 7.x-softwarereleases introduceerden LACP-ondersteuning.

Vanuit functioneel oogpunt is er weinig verschil tussen LACP en PAgP. Beide protocollen ondersteunen een maximum van acht poorten in elk kanaal, en dezelfde poorteigenschappen worden gecontroleerd voor de vorming van de bundel. Deze poorteigenschappen omvatten:

• Speed

• Duplex

• Native VLAN

• Type trunking

De opmerkelijke verschillen tussen LACP en PAgP zijn:

• LACP kan alleen op full-duplex poorten lopen, en LACP ondersteunt geen half-duplex poorten.

• LACP ondersteunt hot standby-poorten. LACP probeert altijd het maximale aantal compatibele poorten in een kanaal te configureren, tot het maximale aantal dat de hardware toestaat (acht poorten). Indien LACP niet in staat is alle compatibele havens samen te voegen, worden alle havens die niet actief in het kanaal kunnen worden opgenomen, in hot standby-status geplaatst en alleen gebruikt als een van de gebruikte havens mislukt. Een voorbeeld van een situatie waarin LACP niet alle compatibele havens kan bijeenvoegen, is als het systeem op afstand meer beperkende hardwarebeperkingen heeft.

Opmerking: in CatOS is het maximum aantal poorten dat dezelfde beheersleutel kan worden toegewezen acht. In Cisco IOS-software probeert LACP het maximale aantal compatibele poorten in een EtherChannel te configureren, tot het maximale aantal dat door de hardware is toegestaan (acht poorten). Er kunnen acht extra poorten worden geconfigureerd als hot standby-poorten.

Operationeel overzicht

De LACP controleert elke afzonderlijke fysieke (of logische) haven die moet worden gebundeld. LACP-pakketten worden verzonden met gebruik van het multicast-MAC-adres van de groep, 01-80-c2-00-00-02. De type/veldwaarde is 0x8809 met een subtype van 0x01. Hier is een samenvatting van de protocolwerking:

• Het protocol vertrouwt op de apparaten om hun aggregatiemogelijkheden en staatsinformatie te adverteren. De uitzendingen worden op regelmatige, periodieke basis verzonden over elke "geaggregeerde" link.

• Zolang de fysieke poort omhoog is, worden LACP-pakketten elke seconde verzonden tijdens de detectie en elke 30 seconden in stabiele toestand.

• De partners op een "aggregatable" link luisteren naar de informatie die binnen het protocol wordt verstuurd en beslissen welke acties moeten worden ondernomen.

• Compatibele poorten worden geconfigureerd in een kanaal, tot het maximum aantal dat de hardware toestaat (acht poorten).

• De aggregaties worden beheerd door de regelmatige, tijdige uitwisseling van actuele informatie over de staat tussen de koppelingspartners. Als de configuratie verandert (bijvoorbeeld als gevolg van een koppelingsfout), gaat het protocol samen met de time-out en onderneemt het de juiste actie op basis van de nieuwe status van het systeem.

• Naast periodieke LACP-dataoverdracht (LACPDU) stuurt het protocol, als er een wijziging is in de informatie van de staat, een gebeurtenisgestuurde LACPDU naar de partner. De protocolpartners nemen passende maatregelen op basis van de nieuwe status van het systeem.

LACP-parameters

Om LACP in staat te stellen te bepalen of een reeks koppelingen met hetzelfde systeem verbonden is en of die koppelingen vanuit het oogpunt van aggregatie compatibel zijn, is het noodzakelijk deze parameters vast te stellen:

• Een wereldwijd unieke identificatiecode voor elk systeem dat deelneemt aan koppelingsaggregatie

  Elk systeem dat LACP uitvoert, moet een prioriteit krijgen die automatisch of door de beheerder kan worden gekozen. De standaardsysteemprioriteit is 32768. De systeemprioriteit wordt voornamelijk gebruikt in combinatie met het MAC-adres van het systeem om de systeemidentificatie te vormen.

• Een middel tot identificatie van de reeks capaciteiten die met elke haven en met elke aggregator zijn verbonden, zoals een bepaald systeem ze begrijpt

  Elke poort in het systeem moet automatisch of door de beheerder een prioriteit krijgen toegewezen. De standaardinstelling is 128. De prioriteit wordt gebruikt in combinatie met het poortnummer om de poortidentificatie te vormen.

• Een middel tot identificatie van een groep koppelingsaggregatie en de bijbehorende aggregator ervan

  De mogelijkheid van een poort om samen te voegen met een andere wordt samengevat door een simpele 16-bits gehele parameter die strikt groter is dan nul. Deze parameter wordt de "toets" genoemd. Elke sleutel wordt door verschillende factoren bepaald, zoals:

  • De fysieke kenmerken van de haven, waaronder:

    • Gegevenssnelheid

    • duplexiteit

    • Point-to-point of gedeeld medium

  • Configuratiebeperkingen die de netwerkbeheerder vaststelt

  Met elke poort zijn twee toetsen gekoppeld:

  • Een administratieve sleutel-Deze sleutel staat voor de manipulatie van zeer belangrijke waarden door het beheer toe. Een gebruiker kan deze sleutel kiezen.

  • Een operationele sleutel-het systeem gebruikt deze sleutel om samenvoegingen te vormen. Een gebruiker kan deze toets niet rechtstreeks kiezen of wijzigen.

    De reeks havens in een systeem die dezelfde operationele sleutelwaarde delen, worden geacht lid te zijn van dezelfde sleutelgroep.

Als u twee systemen en een reeks poorten met dezelfde beheersleutel hebt, probeert elk systeem de poorten samen te voegen. Elk systeem begint vanaf de haven met de hoogste prioriteit in het systeem met de hoogste prioriteit. Dit gedrag is mogelijk omdat elk systeem zijn eigen prioriteit kent, die de gebruiker of het systeem heeft toegewezen, en zijn partnerprioriteit, die werd ontdekt door LACP-pakketten.

Gedrag in falen

Het faalgedrag van LACP is hetzelfde als dat van PAgP. Als een koppeling in een bestaand kanaal is mislukt, wordt de poort bijgewerkt en wordt het verkeer binnen een seconde gehakt op de resterende koppelingen. Een link kan om deze en andere redenen mislukken:

• Een poort is verwijderd

• Een GBIC wordt verwijderd

• Een vezel is gebroken

• Hardware-storing (interface of module)

Elk verkeer dat na de storing niet opnieuw hoeft te worden gecensureerd (verkeer dat dezelfde link blijft gebruiken) hoeft geen verlies te lijden. Het herstel van de mislukte link zorgt voor een nieuwe update van de poort en het verkeer wordt weer gehakt.

Configuratieopties

LACP EtherChannel kan in verschillende modi worden geconfigureerd, zoals in deze tabel wordt samengevat:

Verificatie (LACP en LACP)

De tabel in dit deel geeft een overzicht van alle mogelijke LACP-kanaliseringsmodusscenario's tussen twee direct verbonden switches (Switch-A en Switch-B). Sommige van deze combinaties kunnen STP veroorzaken om de havens aan de kanaliserende kant in de erreless staat te zetten. Dit betekent dat sommige combinaties de havens aan de kanaalzijde afsluiten.

Verificatie (LACP en PAgP)

In de tabel in dit deel wordt een overzicht gegeven van alle mogelijke scenario’s voor de LACP-naar-PAgP-kanaalmodus tussen twee direct verbonden switches (Switch-A en Switch-B). Sommige van deze combinaties kunnen STP veroorzaken om de havens aan de kanaliserende kant in de erreless staat te zetten. Dit betekent dat sommige combinaties de havens aan de kanaalzijde afsluiten.

Aanbeveling

Cisco raadt aan PAgP op kanaalverbindingen tussen Cisco-switches in te schakelen. Wanneer u naar apparaten kanaliseert die geen PAgP ondersteunen maar LACP ondersteunen, laat LACP toe door de configuratie van LACP actief op beide uiteinden van de apparaten. Als één van beide uiteinden van de apparaten LACP of PAgP niet ondersteunt, moet u het kanaal hard programmeren om op te zetten.

• 
  set channelprotocol lacp module 
  
  

  Op switches die CatOS uitvoeren, alle poorten op een Catalyst 4500/4000 en Catalyst 6500/6000 gebruiken kanaalprotocol PAgP standaard en, als zodanig, niet LACP. Om poorten te kunnen configureren om LACP te kunnen gebruiken, moet u het kanaalprotocol op de modules instellen op LACP. LACP en PAgP kunnen niet op dezelfde module draaien op switches die CatOS draaien.

• set port lacp-channel port_range admin-key
  
  

  Een admin key (administratiesleutel) parameter wordt uitgewisseld in het LACP-pakket. Een kanaal vormt zich alleen tussen poorten die dezelfde admin-toets hebben. De ingestelde port-lacp-channel port_range admin-key opdracht wijst kanalen een admin-sleutel nummer toe. Het show lacp-kanaal groep commando toont het nummer. De ingestelde port-lacp-channel port_range admin-key opdracht wijst dezelfde admin-toets toe aan alle poorten in het poortbereik. De admin-toets wordt willekeurig toegewezen als een specifieke toets niet is geconfigureerd. Vervolgens kunt u, indien gewenst, verwijzen naar de admin-toets om de toevoeging en verwijdering van kanalisatiepoorten naar dezelfde poort te beheren.

• set port lacp-channel port_range mode active
  

  De ingestelde port lacp-channel port_range mode actieve opdracht verandert de kanaalmodus in actief voor een set poorten die eerder aan dezelfde admin-toets waren toegewezen.

Daarnaast maakt LACP gebruik van een intervaltimer van 30 seconden (Slow_Periodic_Time) nadat de LACP EtherChannel zijn ingesteld. Het aantal seconden voor ongeldigverklaring van ontvangen LACPDU-informatie met het gebruik van lange time-outs (3 x Slow_Periodic_Time) is 90. Gebruik UDLD, wat een snellere detector is van unidirectionele links. U kunt de LACP-timers niet aanpassen en vandaag kunt u de switches niet configureren om de snelle PDU-transmissie (elke seconde) te gebruiken om het kanaal te behouden nadat het kanaal is gevormd.

Overige opties

Als u een model van minimaal beheer op de toegangslaag hebt, is een gemeenschappelijke configuratie om de modus in te stellen op actief op de distributie- en kernlagen. Verlaat de switches van de toegangslaag bij de standaard passieve configuratie.

Unidirectionele linkdetectie

UDLD is een lichtgewicht Cisco-protocol dat is ontwikkeld om gevallen van unidirectionele communicatie tussen apparaten te detecteren. Hoewel er andere methoden zijn om de bidirectionele staat van de transmissiemedia te detecteren, zoals FEFI, zijn er bepaalde gevallen waarin de L1 detectiemechanismen niet voldoende zijn. Deze scenario's kunnen in om het even welk van deze voorkomen resulteren:

• De onvoorspelbare werking van STP

• Onjuist of overmatig vollopen van pakketten

• Het zwarte gat van het verkeer

De UDLD-functie is bedoeld om deze storingsomstandigheden op glasvezel- en koper-Ethernet-interfaces aan te pakken:

• Bewaak fysieke bekabeling configuraties en sluit alle verkeerd bedrade poorten af als errunk.

• Beschermen tegen unidirectionele links. Wanneer een unidirectionele verbinding, wegens media of haven/interfacestoornis wordt ontdekt, wordt de beïnvloede haven gesloten aangezien erreless, en een overeenkomstig syslogbericht geproduceerd.

• Bovendien controleert de agressieve modus van UDLD dat een link die eerder als tweerichtingsverkeer werd beschouwd, geen connectiviteit verliest tijdens stremmingen en onbruikbaar wordt. UDLD voert continue connectiviteitstests uit via de link. Het primaire doel van de agressieve modus van de UDLD is het voorkomen van het zwart vasthouden van verkeer in bepaalde defecte omstandigheden.

Spanning Tree, met zijn steady state unidirectionele BPDU stroom, was een acute lijder van deze mislukkingen. Het is gemakkelijk om te zien hoe een haven plotseling niet kan BPDUs overbrengen, veroorzakend een STP staatsverandering van het blokkeren aan het door:sturen op de buur. Deze verandering leidt tot een lijn, aangezien de haven nog kan ontvangen.

Operationeel overzicht

UDLD is een L2-protocol dat boven de LLC-laag werkt (bestemming MAC 10-00-0c-cc-cc, SNAP HDLC protocol type 0x0111). Wanneer UDLD wordt uitgevoerd in combinatie met FEFI- en autonegotiation L1-mechanismen, is het mogelijk om de fysieke (L1) en logische (L2) integriteit van een link te valideren.

UDLD heeft bepalingen voor functies en bescherming die FEFI en autonegotiation niet kunnen uitvoeren, namelijk de detectie en caching van buurinformatie, de mogelijkheid om slecht verbonden poorten te sluiten en logische interface/poort storingen of fouten op koppelingen die niet point-to-point zijn (die media-converters of hubs doorkruisen) te detecteren.

UDLD maakt gebruik van twee basismechanismen; het leert over de buren, houdt de informatie up-to-date in een lokaal cachegeheugen, en stuurt een trein van UDLD sonde/echo (hallo) berichten wanneer het een nieuwe buur ontdekt of wanneer een buur vraagt om een re-synchronisatie van het cachegeheugen.

UDLD stuurt voortdurend sonde-berichten op alle poorten waarop UDLD is ingeschakeld. Wanneer een specifiek "triggering" UDLD-bericht op een poort wordt ontvangen, begint een detectiefase en validatieproces. Als aan het eind van dit proces aan alle geldige voorwaarden is voldaan, wordt de havenstaat niet gewijzigd. Om aan de voorwaarden te voldoen, moet de haven bidirectioneel zijn en correct worden aangesloten. Anders wordt de poort uitgeschakeld en verschijnt er een syslog-bericht. Het syslogbericht is gelijkaardig aan deze berichten:

• UDLD-3-UITSCHAKELEN: Unidirectionele link gedetecteerd op poort [dec]/[dec]. Poorten uitgeschakeld

• UDLD-4 ONEWAYPATH: Een unidirectionele verbinding van haven [dec]/[dec] aan haven

  [dec]/[dec] van apparaat [chars] werd gedetecteerd

Raadpleeg Berichten en herstelprocedures (Catalyst Series switches, 7.6) voor een volledige lijst met systeemmeldingen per voorziening, inclusief UDLD-gebeurtenissen.

Nadat een verbinding wordt gevestigd en als tweerichtingsberichten geclassificeerd, blijft UDLD sonde/echoberichten met een standaardinterval van 15 seconden adverteren. Deze tabel geeft de geldige UDLD-koppelingsstaten weer zoals die zijn gerapporteerd in de uitvoer van de opdracht show udld port:

• Het Onderhoud van het Geheime voorgeheugen van de buur-UDLD verzendt periodiek hello sonde/echopakketten op elke actieve interface, om de integriteit van het UDLD buurgeheime voorgeheugen te handhaven. Wanneer een hello bericht wordt ontvangen, wordt het in het geheugen opgeslagen en bewaard voor een maximumperiode die als de hold-time wordt gedefinieerd. Wanneer de hold-time verloopt, wordt de respectieve cache-ingang verouderd. Als een nieuw hello bericht binnen de greeptijd periode wordt ontvangen, vervangt het nieuwe de oudere ingang en de overeenkomstige tijd-aan-levende tijdopnemer wordt teruggesteld.

• Om de integriteit van het UDLD-cachegeheugen te behouden, wanneer een UDLD-enabled interface uitgeschakeld wordt of een apparaat opnieuw wordt ingesteld, worden alle bestaande cacheingangen voor de interfaces die door de configuratiewijziging worden beïnvloed, gewist en UDLD stuurt ten minste één bericht om de respectieve buren te informeren de overeenkomstige cacheingangen te spoelen.

• Echo Detection Mechanism—het echomechanisme vormt de basis van het detectiealgoritme. Wanneer een UDLD-apparaat leert over een nieuwe buur of een resynchronisatieverzoek ontvangt van een niet-synchrone buur, start/herstart het detectievenster aan de zijkant van de verbinding en verstuurt een burst van echoberichten in antwoord. Aangezien dit gedrag het zelfde over alle buren moet zijn, verwacht de echoafzender om echo's terug in antwoord te ontvangen. Als het detectievenster eindigt en er geen geldig antwoordbericht is ontvangen, wordt de koppeling als unidirectioneel beschouwd en kan een proces voor het opnieuw instellen van de link of het afsluiten van de poort worden geactiveerd.

Convergentietijd

Om STP-lussen te voorkomen, verkleinde CatOS 5.4(3) het UDLD-standaardberichtinterval van 60 seconden tot 15 seconden om een unidirectionele link af te sluiten voordat een geblokkeerde poort in staat was om over te schakelen naar een doorstuurstatus.

Opmerking: de berichtinterfacewaarde bepaalt de snelheid waarmee een buur UDLD-sondes verstuurt na de verbinding- of detectiefase. Het berichtinterval hoeft niet aan beide uiteinden van een link te worden aangepast, hoewel consistente configuratie waar mogelijk gewenst is. Wanneer UDLD-buren worden ingesteld, wordt het geconfigureerde berichtinterval verzonden en wordt het time-out-interval voor die peer berekend als (3 * message_interval). Daarom wordt een peer relatie na drie opeenvolgende hellos (of sondes) gemist. Met de berichtintervallen verschillend aan elke kant, is deze onderbrekingswaarde verschillend aan elke kant.

De geschatte tijd die voor UDLD nodig is om een unidirectionele storing te detecteren is ongeveer (2,5 * message_interval + 4 seconden), of ongeveer 41 seconden met gebruik van het standaard bericht interval van 15 seconden. Dit is duidelijk onder de 50 seconden die gewoonlijk noodzakelijk zijn voor STP om terug te keren. Als de NMP CPU enige reservecycli heeft en als u zorgvuldig het gebruiksniveau bewaakt, kunt u het berichtinterval (even) tot een minimum van 7 seconden beperken. Dit berichtinterval helpt de detectie te versnellen met een significante factor.

Daarom heeft UDLD een veronderstelde afhankelijkheid van standaard overspannen - boomtimers. Als u STP afstemt om sneller samen te komen dan UDLD, overweeg dan een alternatief mechanisme, zoals de CatOS 6.2-lusbeveiliging. Overweeg ook een afwisselend mechanisme wanneer u RSTP (IEEE 802.1w) implementeert omdat RSTP convergentiekenmerken heeft in de milliseconden, die afhankelijk zijn van de topologie. Voor deze gevallen, gebruik loop guard in combinatie met UDLD, die de meeste bescherming biedt. Loop guard voorkomt STP-lussen met de snelheid van de STP-versie die in gebruik is, en UDLD detecteert unidirectionele verbindingen op individuele EtherChannel-links of in gevallen waarin BPDU's niet langs de gebroken richting stromen.

Opmerking: UDLD vangt niet elke STP-storingssituatie, zoals storingen die worden veroorzaakt door een CPU die BPDU's niet voor een langere tijd stuurt dan (2 * FwdDelay + Maxage). Om deze reden raadt Cisco u aan UDLD te implementeren in combinatie met loop guard (die is geïntroduceerd in CatOS 6.2) in topologieën die vertrouwen op STP.

Waarschuwing: Pas op voor eerdere releases van UDLD die een niet-configureerbaar 60-seconde-standaard berichtinterval gebruiken. Deze releases zijn gevoelig voor overspannings-boomlusvoorwaarden.

UDLD-agressieve modus

Agressieve UDLD werd gecreëerd om specifiek die (weinig) gevallen aan te pakken waarin een voortdurende test van bidirectionele connectiviteit noodzakelijk is. Als zodanig biedt de agressieve modus een verbeterde bescherming tegen gevaarlijke unidirectionele linkomstandigheden in deze situaties:

• Wanneer het verlies van UDLD-PDU's symmetrisch is en beide uiteinden van de time-out, is geen van beide poorten opnieuw uitgeschakeld.

• Aan één kant van een link zit een poort vast (zowel verzenden [Tx] als Rx).

• De ene kant van een link blijft omhoog terwijl de andere kant van de link naar beneden is gegaan.

• Autonegotiation of een ander L1-foutendetectiemechanisme is uitgeschakeld.

• Een vermindering van het vertrouwen op L1 FEFI-mechanismen is wenselijk.

• Maximale bescherming tegen unidirectionele linkstoringen op point-to-point FE/GE-links is noodzakelijk. In het bijzonder, waar geen mislukking tussen twee buren toelaatbaar is, kunnen UDLD-agressieve sondes als een "hartslag" worden beschouwd, waarvan de aanwezigheid de gezondheid van de verbinding waarborgt.

Het meest voorkomende geval voor een implementatie van agressieve UDLD is om de connectiviteitscontrole uit te voeren op een lid van een bundel wanneer autonegotiation of een ander L1 fout-detectiemechanisme uitgeschakeld of onbruikbaar is. Dit geldt met name voor EtherChannel-verbindingen, omdat PAgP/LACP, zelfs als deze optie is ingeschakeld, geen zeer lage hello-timers gebruikt bij steady state. In dit geval heeft agressieve UDLD het extra voordeel van de preventie van mogelijke overspannen-tree loops.

De omstandigheden die bijdragen aan het symmetrische verlies van UDLD-sondepakketten zijn moeilijker te karakteriseren. U moet begrijpen dat normale UDLD controleert op een unidirectionele linkvoorwaarde, zelfs nadat een link bidirectionele status bereikt. De bedoeling van UDLD is om L2 problemen te detecteren die STP-lussen veroorzaken, en die problemen zijn meestal unidirectioneel omdat BPDU's slechts in één richting stromen bij steady state. Daarom is het gebruik van normale UDLD in combinatie met autonome onderhandeling en lusbeveiliging (voor netwerken die op STP vertrouwen) bijna altijd voldoende. UDLD agressieve modus is echter gunstig in situaties waarin de congestie in beide richtingen gelijk wordt beïnvloed, wat het verlies van UDLD-sondes in beide richtingen veroorzaakt. Dit verlies van UDLD-sondes kan bijvoorbeeld optreden als CPU-gebruik op elk uiteinde van de link is verhoogd. Andere voorbeelden van bidirectioneel verlies van connectiviteit omvatten de fout van één van deze apparaten:

• Een Dense Wavelength Division Multiplexing (DWDM)-transponder

• Een mediaconverter

• Een hub

• Een ander L1-apparaat

  Opmerking: de fout kan niet worden gedetecteerd door autonegotiation.

Agressieve UDLD-fout schakelt de poort uit in deze storingssituaties. Overweeg de vertakkingen zorgvuldig wanneer u UDLD agressieve wijze op verbindingen toelaat die niet punt om te richten zijn. Koppelingen met mediaconverters, hubs of vergelijkbare apparaten zijn geen point-to-point. Tussentijdse apparaten kunnen het doorsturen van UDLD-pakketten voorkomen en dwingen een link onnodig af te sluiten.

Nadat alle buren van een poort zijn verouderd, herstart UDLD agressieve modus (als deze is ingeschakeld) de koppelingsreeks in een poging om te synchroniseren met potentieel out-of-sync buren. Deze inspanning vindt plaats in de advertentie- of detectiefase. Als na een snelle trein van berichten (acht mislukte pogingen) de link nog steeds als "onbepaald" wordt beschouwd, wordt de poort dan in erreless status gezet.

Opmerking: sommige switches zijn niet agressief geschikt voor UDLD. Op dit moment hebben Catalyst 2900XL en Catalyst 3500XL hardgecodeerde berichtintervallen van 60 seconden. Dit interval wordt niet beschouwd als voldoende snel om te beschermen tegen potentiële STP-loops (bij gebruik van de standaard STP-parameters).

UDLD op Routed Links

Ten behoeve van deze discussie is een gerouteerde link een van de volgende twee verbindingstypen:

• Point-to-point tussen twee routerknooppunten

  Deze link is geconfigureerd met een 30-bits subnetmasker.

• Een VLAN met meerdere poorten maar dat alleen routeringsverbindingen ondersteunt

  Een voorbeeld is een gesplitste L2 kerntopologie.

Elk Interior Gateway Routing Protocol (IGRP) heeft unieke kenmerken met betrekking tot de manier waarop het omgaat met buurrelaties en routeconvergentie. De kenmerken, die in deze sectie worden besproken, zijn relevant wanneer u twee van de meest voorkomende routeringsprotocollen die vandaag worden gebruikt, Open Shortest Path First (OSPF) Protocol en Enhanced IGRP (EIGRP) met elkaar vergelijkt.

Houd er eerst rekening mee dat een L1- of L2-storing op een point-to-point routed-netwerk resulteert in een vrijwel onmiddellijke uitval van de L3-verbinding. Omdat de enige switch poort in die VLAN overgaat naar een niet-verbonden status na de L1/L2-fout, synchroniseert de MSFC auto-state-functie de L2- en L3-poortstaten in ongeveer twee seconden. Deze synchronisatie plaatst de L3 VLAN-interface in een up/down-staat (met het lijnprotocol omlaag).

Ga uit van standaardtimerwaarden. OSPF verzendt hello-berichten elke 10 seconden en heeft een dood interval van 40 seconden (4 * hello). Deze timers zijn consistent voor OSPF point-to-point en broadcast-netwerken. Omdat OSPF bidirectionele communicatie vereist om een nabijheid te vormen, is de slechtst-geval failover tijd 40 seconden. Deze failover is zelfs het geval als de L1/L2 storing niet puur is op een point-to-point verbinding, wat een half-operationeel scenario verlaat waar het L3 protocol mee te maken moet krijgen. Omdat de detectietijd van UDLD sterk lijkt op de tijd van een dode OSPF-timer die verloopt (ongeveer 40 seconden), zijn de voordelen van de configuratie van de normale UDLD-modus op een OSPF L3 point-to-point link beperkt.

In veel gevallen convergeert EIGRP sneller dan OSPF. U moet er echter rekening mee houden dat communicatie in twee richtingen niet nodig is om ervoor te zorgen dat buren routeringsinformatie kunnen uitwisselen. In zeer specifieke half-operationele mislukkingsscenario's, is EIGRP kwetsbaar voor het zwarte houden van verkeer dat duurt tot één of andere gebeurtenis de routes als die buur "actief"maakt. De normale modus van de UDLD kan de omstandigheden verlichten die in deze sectie worden aangegeven. UDLD normale modus detecteert de unidirectionele link fout en de fout schakelt de poort uit.

Voor L3-routed verbindingen die elk routeringsprotocol gebruiken, biedt UDLD normal nog steeds bescherming tegen problemen bij de initiële linkactivering. Zulke problemen zijn onder meer verkeerde bekabeling of defecte hardware. Bovendien biedt de agressieve UDLD-modus deze voordelen bij L3-routeringsverbindingen:

• Voorkomt onnodig zwart gaten in het verkeer

  Opmerking: In sommige gevallen zijn minimumtimers vereist.

• Plaatst een flappende link in de erreless status

• Beschermt tegen lijnen die resulteren uit L3 EtherChannel-configuraties

Standaardgedrag van UDLD

UDLD wordt standaard wereldwijd uitgeschakeld en ingeschakeld op glasvezelpoorten. Omdat UDLD een infrastructuurprotocol is dat alleen tussen switches nodig is, wordt UDLD standaard uitgeschakeld op koperpoorten. Koperpoorten worden meestal gebruikt voor toegang tot de host.

Opmerking: UDLD moet globaal en op interfaceniveau zijn ingeschakeld voordat buren een tweerichtingsstatus kunnen bereiken. In CatOS 5.4(3) en hoger is het standaardberichtinterval 15 seconden en kan worden ingesteld tussen 7 en 90 seconden.

Erreless herstel is standaard wereldwijd uitgeschakeld. Nadat het globaal wordt toegelaten, als een haven in erreless staat gaat, wordt de haven automatisch opnieuw toegelaten na een geselecteerd tijdinterval. De standaardtijd is 300 seconden. Dit is een wereldwijde timer en wordt voor alle poorten in een switch onderhouden. U kunt handmatig voorkomen dat een poort opnieuw wordt ingeschakeld als u de time-out voor het opnieuw uitschakelen van die poort instelt op uitschakelen. Geef de vastgestelde haven errunk-onderbreking mod/port uitschakelen opdracht uit.

Opmerking: het gebruik van deze opdracht is afhankelijk van de softwareversie.

Overweeg het gebruik van de erreless onderbrekingsfunctie wanneer u UDLD agressieve modus implementeert zonder out-of-band netwerkbeheermogelijkheden, met name in de toegangslaag of op elk apparaat dat geïsoleerd kan raken van het netwerk in het geval van een erreless situatie.

Raadpleeg Configureren Ethernet, Fast Ethernet, Gigabit Ethernet en 10 Gigabit Ethernet-switching voor meer informatie over hoe u een time-outperiode kunt configureren voor poorten die in de status ereless zijn.

Aanbeveling

Normale modus UDLD is in de overgrote meerderheid van de gevallen voldoende als u het correct en in combinatie met de juiste functies en protocollen gebruikt. Deze functies/protocollen omvatten:

• FEFI

• Automatische onderhandeling

• Loop Guard

Wanneer u UDLD implementeert, moet u overwegen of een doorlopende test van bidirectionele connectiviteit (agressieve modus) noodzakelijk is. Typisch, als autonegotiation wordt toegelaten, is de agressieve wijze niet noodzakelijk omdat autonegotiation de foutenopsporing bij L1 compenseert.

Cisco raadt de inschakeling van de normale UDLD-modus aan op alle point-to-point FE/GE-koppelingen tussen Cisco-switches waarin het UDLD-berichtinterval is ingesteld op de standaardinstelling van 15 seconden. Bij deze configuratie wordt uitgegaan van de standaard 802.1d-omspanningsboomtimers. Bovendien, gebruik UDLD in combinatie met lijnwacht in netwerken die zich op STP voor overtolligheid en convergentie baseren. Deze aanbeveling is van toepassing op netwerken waarin een of meer poorten in de STP-blokkeringsstatus in de topologie aanwezig zijn.

Geef deze opdrachten uit om UDLD in te schakelen:

set udld enable

!--- After global enablement, all FE and GE fiber !--- ports have UDLD enabled by default.


set udld enable port range


!--- This is for additional specific ports and copper media, if needed.

U moet poorten handmatig inschakelen die zijn uitgeschakeld als gevolg van unidirectionele linksymptomen. Geef de vastgestelde haven uit om bevel toe te laten.

Raadpleeg Inzicht in en configuratie van de UDLD-functie (Unidirectional Link Detection Protocol) voor meer informatie.

Overige opties

Voor maximale bescherming tegen symptomen die het gevolg zijn van unidirectionele links, configureer agressieve modus UDLD:

set udld aggressive-mode enable port_range

Daarnaast kunt u de UDLD-berichtinterfacewaarde tussen 7 en 90 seconden op elk uiteinde instellen, waar deze wordt ondersteund, voor snellere convergentie:

set udld interval time

Overweeg het gebruik van de erreless onderbrekingseigenschap op om het even welk apparaat dat van het netwerk in het geval van een erreless situatie kan worden geïsoleerd. Deze situatie is typisch waar van de toegangslaag en wanneer u agressieve wijze UDLD zonder out-of-band netwerkbeheermogelijkheden uitvoert.

Als een poort in de ereless status wordt geplaatst, blijft de poort standaard ingedrukt. U kunt deze opdracht geven, waarmee poorten na een time-outinterval opnieuw worden ingeschakeld:

Opmerking: de time-out interval is standaard 300 seconden.

>set errdisable-timeout enable ?
bpdu-guard

!--- This is BPDU port-guard.


channel-misconfig

!--- This is a channel misconfiguration.


duplex-mismatch
udld
other

!--- These are other reasons.


all

!--- Apply errdisable timeout to all reasons.

Als het partnerapparaat niet UDLD-Geschikt is, zoals een eindgastheer of een router, stel niet het protocol in werking. Voer de volgende opdracht uit:

set udld disable port_range

Test en monitor UDLD

UDLD is niet gemakkelijk te testen zonder een werkelijk defecte/unidirectionele component in het laboratorium, zoals een defecte GBIC. Het protocol werd ontworpen om minder-gemeenschappelijke mislukkingsscenario's te ontdekken dan die scenario's die gewoonlijk in een laboratorium worden tewerkgesteld. Bijvoorbeeld, als u een eenvoudige test uitvoert en één draad van een vezel loskoppelt om de gewenste erreless staat te zien, moet u L1 autonomegotiation hebben uitgezet. Anders gaat de fysieke poort naar beneden, waardoor UDLD-berichtcommunicatie wordt hersteld. Het afgelegen uiteinde beweegt naar de onbepaalde status in UDLD normaal. Als u de agressieve modus van de UDLD gebruikt, wordt de toestand van het externe uiteinde naar de onbruikbare toestand verplaatst.

Er is een aanvullende testmethode om het verlies van de buur-PDU voor UDLD te simuleren. Gebruik filters op de MAC-laag om het UDLD/CDP-hardwareadres te blokkeren, maar andere adressen te laten passeren.

Om UDLD te controleren, geef deze bevelen uit:

>show udld

UDLD              : enabled
Message Interval  : 15 seconds


>show udld port 3/1

UDLD              : enabled
Message Interval  : 15 seconds
Port      Admin Status  Aggressive Mode  Link State
--------  ------------  ---------------  ----------------
	3/1      enabled       disabled         bidirectional

Ook van Enable mode, kunt u de verborgen show oud buurbevel uitgeven om de UDLD cacheinhoud (in de manier die CDP) te controleren. Een vergelijking van het UDLD-cachegeheugen met het CDP-cachegeheugen om na te gaan of er een protocolspecifieke anomalie is, is vaak nuttig. Wanneer CDP ook wordt beïnvloed, worden doorgaans alle PDU's/BPDU's gewijzigd. Controleer daarom ook STP. Controleer bijvoorbeeld of er recente wijzigingen in de rootidentiteit of wijzigingen in de rootplaatsing of de aangewezen poortplaatsing zijn.

>show udld neighbor 3/1

Port  Device Name            Device ID    Port-ID OperState
----- ---------------------  ------------ ------- ----------
	3/1   TSC07117119M(Switch)   000c86a50433 3/1     bidirectional

Bovendien kunt u de status en de configuratieconsistentie van de UDLD bewaken bij gebruik van de Cisco UDLD SNMP MIB-variabelen.

Jumboframe

De standaard framegrootte van Max. Transmissie-eenheid (MTU) is 1518 bytes voor alle Ethernet-poorten, inclusief GE en 10 GE. De functie jumboframe maakt switch-frames mogelijk die groter zijn dan de standaard Ethernet-framegrootte. Deze voorziening is handig om de prestaties van server-naar-server te optimaliseren en toepassingen te ondersteunen zoals Multi-Protocol Label Switching (MPLS), 802.1Q-tunneling en L2 Tunneling Protocol versie 3 (L2TPv3), die de omvang van de oorspronkelijke frames vergroten.

Operationeel overzicht

De standaardspecificatie van IEEE 802.3 definieert een maximale Ethernet-framegrootte van 1518 bytes voor reguliere frames en 1522 bytes voor 802.1Q ingekapselde frames. De 802.1Q ingekapselde frames worden soms aangeduid als "babyreuzen". Over het algemeen worden pakketten geclassificeerd als gigantische frames wanneer de pakketten de gespecificeerde Ethernet-maximale lengte voor een specifieke Ethernet-verbinding overschrijden. Reuzenpakketten worden ook wel jumboframes genoemd.

Er zijn verschillende redenen waarom de MTU-grootte van bepaalde frames 1518 bytes kan overschrijden. Dit zijn een paar voorbeelden:

• Leverancierspecifieke vereisten: toepassingen en bepaalde NIC's kunnen een MTU-grootte opgeven die buiten de standaard 1500 bytes valt. De tendens om dergelijke MTU-maten te specificeren is het gevolg van studies die zijn uitgevoerd, die bewijzen dat een toename in de grootte van een Ethernet-frame de gemiddelde doorvoersnelheid kan verhogen.

• Trunking-om de informatie van VLAN-id tussen switches of andere netwerkapparaten te dragen, is trunking ingezet om het standaard Ethernet-frame te vergroten. Vandaag, zijn de twee meest voorkomende vormen van trunking de merkgebonden ISL inkapseling van Cisco en IEEE 802.1Q.

• MPLS—Nadat MPLS op een interface is ingeschakeld, kan de framegrootte van een pakket worden vergroot. Deze versterking is afhankelijk van het aantal labels in de labelstack voor een MPLS-gelabeld pakket. De totale grootte van een label is 4 bytes. De totale grootte van een labelstack is n x 4 bytes. Als een labelstapel wordt gevormd, kunnen de frames de MTU overschrijden.

• 802.1Q tunneling—802.1Q tunneling pakketten bevatten twee 802.1Q tags, waarvan meestal slechts één tag tegelijkertijd zichtbaar is voor de hardware. Daarom voegt de interne tag 4 bytes toe aan de MTU-waarde (payloadgrootte).

• Universal Transport Interface (UTI)/L2TPv3—UTI/L2TPv3 kapselt L2-gegevens in die via het IP-netwerk moeten worden doorgestuurd. De insluiting kan de oorspronkelijke framegrootte met maximaal 50 bytes vergroten. Het nieuwe frame bevat een nieuwe IP-header (20 bytes), een L2TPv3-header (12 bytes) en een nieuwe L2-header. De L2TPv3 payload bestaat uit het volledige L2 frame, dat de L2 header bevat.

Het vermogen van de verschillende Catalyst switches om verschillende framegrootte te ondersteunen, hangt af van vele factoren, waaronder de hardware en software. Bepaalde modules kunnen grotere framegrootte ondersteunen dan anderen, zelfs binnen hetzelfde platform.

• De Catalyst 5500/5000 switches bieden ondersteuning voor jumboframes in de CatOS 6.1 release. Wanneer de functie jumboframes is ingeschakeld op een poort, wordt de MTU-grootte verhoogd tot 9216 bytes. Op 10/100-Mbps unshielded Twisted pair (UTP)-gebaseerde lijnkaarten is de maximale framegrootte die wordt ondersteund slechts 8092 bytes. Deze beperking is een ASIC-beperking. Er zijn over het algemeen geen beperkingen in de mogelijkheid van de jumboframegrootte functie. U kunt deze functie gebruiken met trunking/nontrunking en het kanaliseren/nonchaneling.

• Catalyst 4000 switches (Supervisor Engine 1 [WS-X4012] en Supervisor Engine 2 [WS-X4013]) ondersteunen jumboframes niet vanwege een ASIC-beperking. De uitzondering is echter 802.1Q-trunking.

• De Catalyst 6500 Series platform kan jumboframegrootte ondersteunen in CatOS release 6.1(1) en hoger. Deze ondersteuning is echter afhankelijk van het type lijnkaarten dat u gebruikt. Er zijn over het algemeen geen beperkingen in de mogelijkheid van de jumboframegrootte functie. U kunt deze functie gebruiken met trunking/nontrunking en het kanaliseren/nonchaneling. De standaard MTU grootte is 9216 bytes nadat de steun van het jumbokader op de individuele haven is toegelaten. De standaard MTU is niet configureerbaar met het gebruik van CatOS. Cisco IOS-softwarerelease 12.1(13)E heeft echter de opdracht jumbomtu van het systeem geïntroduceerd om de standaard-MTU te omzeilen.

Raadpleeg Jumbo/Giant Frame Support op Catalyst Switches Configuration Voorbeeld voor meer informatie.

In deze tabel worden de MTU-formaten beschreven die door verschillende lijnkaarten voor Catalyst 6500/6000 Series switches worden ondersteund:

Opmerking: de MTU-grootte of pakketgrootte verwijst alleen naar de Ethernet-payload.

Ondersteuning van Layer 3 Jumbo Frame

Met CatOS die op de Supervisor Engine en Cisco IOS-software draait die op MSFC draait, bieden de Catalyst 6500/6000-switches ook L3 jumbo frame-ondersteuning in Cisco IOS®-softwarerelease 12.1(2)E en hoger met het gebruik van PFC/MSFC2, PFC2/MSFC2 of latere hardware. Als zowel ingang als uitgang VLANs voor jumboframes worden gevormd, zijn alle pakketten hardware die door PFC bij draadsnelheid wordt geschakeld. Als de toegang VLAN is geconfigureerd voor jumboframes en het uitgaande VLAN niet is geconfigureerd, zijn er twee scenario's:

• Een jumboframe dat wordt verzonden door de eindhost met de Don't Fragment (DF)-bitset (voor pad MTU-detectie). Het pakket wordt gedropt en een ICMP-protocol (Internet Control Message Protocol) wordt onbereikbaar naar de eindhost verzonden met het benodigde berichtcodefragment en de PDF-set.

• Een jumboframe dat door de eindhost wordt verzonden met de DF-bit niet ingesteld. Pakketten worden gepunteerd naar MSFC2/MSFC3 om gefragmenteerd en switched in software.

In deze tabel wordt de jumboondersteuning van de L3 voor verschillende platforms samengevat:

¹ RSM = Route Switch-module

² RSFC = Route Switch-functiekaart

Overweging van netwerkprestaties

De prestaties van TCP over WAN’s (het internet) zijn uitgebreid bestudeerd. Deze vergelijking legt uit hoe TCP-doorvoersnelheid een bovengrens heeft die is gebaseerd op:

• De maximale segmentgrootte (MSS), zijnde de MTU-lengte minus de lengte van de TCP/IP-headers

• De ronde reistijd (RTT)

• Het pakketverlies

Volgens deze formule is de maximale TCP-doorvoersnelheid die haalbaar is recht evenredig met de MSS. Met constante RTT en pakketverlies, kunt u de doorvoersnelheid van TCP verdubbelen als u de pakketgrootte verdubbelt. Op dezelfde manier kan een zesvoudige toename in grootte bij het gebruik van jumboframes in plaats van 1518-byte frames een potentiële zesvoudige verbetering van de TCP-doorvoersnelheid van een Ethernet-verbinding opleveren.

Ten tweede, de steeds toenemende prestatievereisten van serverfarms vereisen een efficiënter middel om hogere gegevenssnelheden te verzekeren met Network File System (NFS) UDP-datagrammen. NFS is het meest gebruikte mechanisme voor gegevensopslag om bestanden tussen UNIX-gebaseerde servers over te dragen en beschikt over 8400-byte datagrammen. Gezien de uitgebreide 9 kB MTU van Ethernet, is één enkel jumbokader groot genoeg om een 8 kB toepassingsdatagram (bijvoorbeeld, NFS) plus de pakketheader boven te dragen. Deze mogelijkheid maakt overigens een efficiëntere directe geheugentoegang (DMA) mogelijk op de hosts, omdat software niet meer nodig heeft om NFS-blokken in afzonderlijke UDP-datagrammen te fragmenteren.

Aanbeveling

Wanneer u ondersteuning voor jumboframes wilt, beperkt u het gebruik van jumboframes tot gebieden van het netwerk waar alle switch modules (L2) en interfaces (L3) jumboframes ondersteunen. Deze configuratie voorkomt fragmentatie overal op het pad. De configuratie van jumboframes die groter zijn dan de ondersteunde framelengte op het pad elimineert elke versterking die wordt bereikt door het gebruik van de functie omdat fragmentatie vereist is. Zoals de tabellen in dit gedeelte Jumbo Frame laten zien, kunnen verschillende platforms en lijnkaarten variëren met betrekking tot de maximale pakketgrootte die wordt ondersteund.

Configureer jumbo frame-bewuste hostapparaten met een MTU-grootte die de minimale gemeenschappelijke noemer is die wordt ondersteund door netwerkhardware voor het gehele L2 VLAN waar het hostapparaat zich bevindt. Om de jumboframe-ondersteuning voor modules met jumboframe-ondersteuning in te schakelen, geeft u deze opdracht uit:

set port jumbo mod/port enable

Als u ondersteuning van jumboframes over L3-grenzen wenst, moet u bovendien de grootste beschikbare MTU-waarde van 9216 bytes op alle toepasselijke VLAN-interfaces configureren. Geef het mtu-commando uit onder de VLAN-interfaces:

interface vlan vlan#
mtu 9216

Deze configuratie zorgt ervoor dat de L2 jumboframe MTU die wordt ondersteund door de modules altijd minder is dan, of gelijk is aan, de waarde die is geconfigureerd voor de L3 interfaces waar het verkeer doorheen gaat. Dit voorkomt fragmentatie wanneer het verkeer via de L3-interface van VLAN wordt gerouteerd.

Beheerconfiguratie

Overwegingen om controle, voorziening en probleemoplossing bij een Catalyst-netwerk te ondersteunen, worden in deze sectie besproken.

Netwerkdiagram

Duidelijke netwerkdiagrammen zijn een fundamenteel onderdeel van netwerkbewerkingen. Zij worden kritisch tijdens het oplossen van problemen en zijn het belangrijkste vehikel voor de communicatie van informatie wanneer opgeschaald naar leveranciers en partners tijdens een stroomonderbreking. Hun voorbereiding, bereidheid en toegankelijkheid moeten niet worden onderschat.

Aanbeveling

Cisco raadt u aan deze drie diagrammen te maken:

• Algemeen Diagram-zelfs voor de grootste netwerken, is een diagram dat de fysieke en logische connectiviteit van begin tot eind toont belangrijk. Het kan voor ondernemingen gemeenschappelijk zijn die een hiërarchisch ontwerp hebben uitgevoerd om elke laag afzonderlijk te documenteren. Tijdens het plannen en oplossen van problemen, echter, is het vaak een goede kennis van hoe de domeinen die van belang is met elkaar verbinden.

• Physical Diagram—toont alle switch- en routerhardware en -bekabeling. Trunks, links, snelheden, kanaalgroepen, poortnummers, slots, chassistypen, software, VTP-domeinen, root-brug, back-up root-brug, MAC-adres en blokkeerpoorten per VLAN moeten worden geëtiketteerd. Het is vaak duidelijker om interne apparaten, zoals Catalyst 6500/6000 MSFC, af te beelden als een router op een stok die via een trunk is aangesloten.

  

• Logisch diagram—toont alleen L3-functionaliteit (routers als objecten, VLAN’s als Ethernet-segmenten). IP-adressen, subnetten, secundaire adressering, actieve en stand-by HSRP, access-core-distributielagen en routing-informatie moeten worden geëtiketteerd.

  

Inband-beheer

Afhankelijk van de configuratie kan de switch in-band (intern) beheerinterface (bekend als sc0) deze gegevens moeten verwerken:

• Switch-beheerprotocollen zoals SNMP, Telnet, Secure Shell-protocol (SSH) en syslog

• Gebruikersgegevens zoals uitzendingen en multicast

• Switch-controleprotocollen zoals STP BPDU’s, VTP, DTP, CDP, enzovoort

Het is algemeen gebruik in het meerlaagse ontwerp van Cisco om een beheer VLAN te configureren dat een switched domein overspant en alle sc0 interfaces bevat. Dit helpt beheerverkeer te scheiden van gebruikersverkeer en verhoogt de beveiliging van de switch-beheerinterfaces. In deze sectie worden de betekenis en mogelijke problemen beschreven van het gebruik van het standaard VLAN 1 en het uitvoeren van beheerverkeer naar de switch in hetzelfde VLAN als gebruikersverkeer.

Operationeel overzicht

De belangrijkste zorg over het gebruik van VLAN 1 voor gebruikersgegevens is dat de Supervisor Engine NMP in het algemeen niet hoeft te worden onderbroken door een groot deel van het multicast- en broadcast-verkeer dat door eindstations wordt gegenereerd. Oudere Catalyst 5500/5000 hardware, de Supervisor Engine I en Supervisor Engine II in het bijzonder, heeft beperkte middelen voor het omgaan met dit verkeer, hoewel het principe van toepassing is op alle Supervisor Motoren. Als de Supervisor Engine CPU, buffer of in-band kanaal naar de backplane volledig is bezet door het luisteren naar onnodig verkeer, is het mogelijk dat controleframes kunnen worden gemist. In het slechtste geval kan dit leiden tot een Spanning Tree-lus of een EtherChannel-fout.

Als de showinterface en ip-stats-opdrachten op de Catalyst worden gegenereerd, kunnen ze een bepaalde indicatie geven van de verhouding van uitzending tot unicastverkeer en de verhouding van IP tot niet-IP-verkeer (niet kenmerkend gezien in beheer-VLAN’s).

Een verdere check voor oudere Catalyst 5500/5000 hardware is om de output van show inband te onderzoeken | biga (verborgen opdracht) voor resourcefouten (RscrcErrors), vergelijkbaar met bufferdruppels in een router. Als deze resourcefouten continu omhoog gaan, is het geheugen niet beschikbaar om systeempakketten te ontvangen, misschien vanwege een aanzienlijke hoeveelheid uitzendverkeer in het beheer VLAN. Een enkele resourcefout kan betekenen dat de Supervisor Engine geen pakket zoals BPDU's kan verwerken, wat snel een probleem kan worden omdat protocollen zoals overspannen - boom geen gemiste BPDU's opnieuw verzenden.

Aanbeveling

Zoals in de sectie Kattencontrole van dit document is gemarkeerd, is VLAN 1 een speciaal VLAN dat het grootste deel van het verkeer van het controlevliegtuig etiketteert en behandelt. VLAN 1 is standaard ingeschakeld op alle trunks. Met grotere campusnetwerken, moet de zorg over de diameter van VLAN 1 worden genomen STP domein; instabiliteit in één deel van het netwerk kan VLAN 1 beïnvloeden, waardoor de stabiliteit van besturingsplane en dus de STP-stabiliteit voor alle andere VLAN’s worden beïnvloed. In CatOS 5.4 en hoger is het mogelijk geweest VLAN 1 te beperken van het overdragen van gebruikersgegevens en het uitvoeren van STP met deze opdracht:

clear trunk mod/port vlan 1

Dit houdt niet op controlepakketten die van switch naar switch in VLAN 1 worden verzonden, zoals die met een netwerkanalyzer worden gezien. Er worden echter geen gegevens doorgestuurd en STP wordt niet via deze link uitgevoerd. Daarom kan deze techniek worden gebruikt om VLAN 1 in kleinere mislukkingsdomeinen op te delen.

Opmerking:  Het is momenteel niet mogelijk om VLAN 1 trunks op 3500s en 2900XLs te wissen.

Zelfs als met het campusontwerp de zorg is genomen om gebruiker VLANs tot relatief kleine switch domeinen en overeenkomstig kleine mislukking/L3 grenzen te beperken, zijn sommige klanten nog verleidelijk om het beheer VLAN verschillend te behandelen en te proberen om het gehele netwerk met één enkel beheerssubnetje te behandelen. Er is geen technische reden dat een centrale NMS applicatie L2-naast de apparaten die het beheert moet zijn, noch is dit een gekwalificeerd veiligheidsargument. Cisco raadt u aan de diameter van het beheer van VLAN’s te beperken tot dezelfde routed domain structuur als gebruikers-VLAN’s en out-of-band beheer en/of ondersteuning van CatOS 6.x SSH te overwegen als een manier om de netwerkbeheerbeveiliging te verbeteren.

Overige opties

Er zijn echter ontwerpoverwegingen voor deze Cisco-aanbevelingen in bepaalde topologieën. Bijvoorbeeld, is een wenselijk en gemeenschappelijk meerlaags ontwerp van Cisco één dat het gebruik van een actieve het Overspannen - boom vermijdt. Dit vereist dat u elke IP-subnetverbinding/VLAN beperkt tot één switch op de toegangslaag of een cluster van switches. In deze ontwerpen, kon er geen trunking neer aan de toegangslaag worden gevormd.

Er is geen gemakkelijk antwoord op de vraag of een afzonderlijk beheer VLAN worden gecreëerd en trunking toegelaten om het tussen L2 toegang en L3 distributielagen te dragen. Dit zijn twee opties voor ontwerpcontrole met uw Cisco-engineer:

• Optie 1: Trunk twee of drie unieke VLAN’s vanaf de distributielaag tot aan elke switch op de toegangslaag. Dit staat voor gegevens VLAN, een stem VLAN, en een beheer VLAN toe, bijvoorbeeld, en heeft nog het voordeel dat STP inactief is. (Merk op dat als VLAN 1 van de trunks wordt ontruimd, er een extra configuratiestap is.) In deze oplossing, zijn er ook ontwerppunten om na te denken om het tijdelijke zwart-holing van gerouteerd verkeer tijdens mislukkingsterugwinning te vermijden: STP PortFast voor trunks (CatOS 7.x en hoger) of VLAN Autostate synchronisatie met STP-doorsturen (later dan CatOS 5.5[9]).

• Optie 2: één VLAN voor gegevens en beheer zou aanvaardbaar kunnen zijn. Met nieuwere switch hardware, zoals krachtigere CPU's en control-plane snelheidsbeperkende besturingselementen, plus een ontwerp met relatief kleine uitzenddomeinen zoals bepleit door het meerlaagse ontwerp, is de realiteit voor veel klanten dat het behouden van de sc0 interface gescheiden van de gebruikersgegevens minder een probleem is dan het ooit was. Een definitieve beslissing wordt waarschijnlijk het best genomen met het onderzoek van het broadcast-verkeersprofiel voor dat VLAN en een discussie over de mogelijkheden van de switch-hardware met uw Cisco-engineer. Als het beheer VLAN inderdaad alle gebruikers op die switch op de toegangslaag bevat, wordt het gebruik van IP-invoerfilters ten zeerste aanbevolen om de switch van gebruikers te beveiligen, zoals wordt besproken in het gedeelte Security Configuration van dit document.

Out-of-band beheer

Met de argumenten van de vorige paragraaf een stap verder, kan netwerkbeheer hoger beschikbaar worden gemaakt met de bouw van een aparte beheerinfrastructuur rond het productienetwerk, zodat apparaten altijd op afstand bereikbaar zijn, ongeacht welke door verkeer gedreven of regelvliegtuig gebeurtenissen zich voordoen. Deze twee benaderingen zijn kenmerkend:

• Out-of-Band beheer met een exclusief LAN

• Out-of-Band beheer met terminalservers

Operationeel overzicht

Elke router en switch in het netwerk kan worden voorzien van een out-of-band Ethernet-beheerinterface op een beheer-VLAN. Eén Ethernet-poort op elk apparaat wordt geconfigureerd in het beheer VLAN en buiten het productienetwerk bekabeld naar een afzonderlijk switched beheernetwerk via de sc0-interface. Merk op dat Catalyst 4500/4000 switches een speciale me1-interface op de Supervisor Engine hebben die alleen moet worden gebruikt voor out-of-band beheer, niet als een switch poort.

Bovendien kan terminalserverconnectiviteit worden bereikt door de configuratie van Cisco 2600 of 3600 met RJ-45-naar-seriële kabels om toegang te krijgen tot de consolepoort van elke router en switch in de lay-out. Een eindserver vermijdt ook de behoefte aan de configuratie van reservescenario's, zoals modems op hulphavens voor elk apparaat. Een enkele modem kan op de hulppoort van de terminalserver worden geconfigureerd om inbelservice te bieden aan de andere apparaten tijdens een storing in de netwerkconnectiviteit.

Aanbeveling

Met deze indeling zijn twee out-of-band paden naar elke switch en router mogelijk naast talloze in-band paden, waardoor hoogbeschikbaar netwerkbeheer mogelijk is. Out-of-band is verantwoordelijk voor:

• Out-of-band scheidt beheerverkeer van gebruikersgegevens.

• Out-of-band heeft het IP-adres voor beheer in een aparte subnetverbinding, VLAN en switch voor een hogere beveiliging.

• Out-of-band biedt een hogere mate van zekerheid voor de levering van beheergegevens tijdens netwerkstoringen.

• Out-of-band heeft geen actieve Spanning Tree in beheer-VLAN. Redundantie is niet cruciaal.

Systeemtests

Opstartdiagnostiek

Tijdens het opstarten van een systeem wordt een aantal processen uitgevoerd om ervoor te zorgen dat er een betrouwbaar en operationeel platform beschikbaar is, zodat defecte hardware het netwerk niet verstoort. De laarsdiagnostiek van Catalyst wordt verdeeld tussen Power-On Self Test (POST) en online diagnostiek.

Operationeel overzicht

Afhankelijk van het platform en de hardwareconfiguratie worden verschillende diagnoses uitgevoerd bij opstarten en wanneer een kaart in het chassis wordt verwisseld. Een hoger niveau van diagnostiek resulteert in een groter aantal gedetecteerde problemen maar een langere opstartcyclus. Deze drie niveaus van POST diagnostiek kunnen worden geselecteerd (alle tests controleren DRAM, RAM, en de aanwezigheid en grootte van het cachegeheugen en initialiseren hen):

Online diagnose

Deze tests controleren intern pakketpaden in de switch. Het is belangrijk op te merken dat online diagnostiek daarom systeembrede tests zijn, niet alleen poorttests. Op Catalyst 5500/5000- en 6500/6000-switches worden tests eerst uitgevoerd vanuit de stand-by Supervisor Engine en vervolgens vanuit de primaire Supervisor Engine. De lengte van de diagnose hangt af van de systeemconfiguratie (aantal sleuven, modules, poorten). Er zijn drie categorieën tests:

• Loopback test-pakketten van de Supervisor Engine NMP worden naar elke poort verzonden, en vervolgens naar de NMP teruggestuurd en op fouten onderzocht.

• De bundelende test-kanalen van maximaal acht havens worden gecreëerd en loopback tests die aan de poort worden uitgevoerd om het hakken aan specifieke verbindingen te verifiëren (verwijs naar de sectie EtherChannel van dit document voor verdere informatie).

• Enhanced Address Recognition Logic (EARL) test - zowel de Central Supervisor Engine als inline Ethernet module L3 herschrijfmachines worden getest. Hardware-doorsturen ingangen en routed poorten worden gecreëerd voordat voorbeeldpakketten worden verzonden (voor elk type protocolinkapseling) vanuit de NMP via de switching-hardware op elke module en terug naar de NMP. Dit is voor Catalyst 6500/6000 PFC-modules en nieuwer.

Volledige online diagnostiek kan ongeveer twee minuten duren. De minimale diagnostiek voert geen bundel uit of herschrijft het testen op modules buiten de Supervisor Engine, en kan ongeveer 90 seconden vergen.

Tijdens een geheugentest, wanneer een verschil in het teruggelezen patroon in vergelijking met het geschreven patroon wordt gevonden, wordt de havenstaat veranderd in defect. De resultaten van deze tests zijn zichtbaar als de opdracht voor de showtest wordt gegeven, gevolgd door het modulenummer dat moet worden onderzocht:

>show test 9

Diagnostic mode: complete (mode at next reset: complete)

!--- Configuration setting.

Module 9 : 4-port Multilayer Switch
Line Card Status for Module 9 : PASS
Port Status :
  Ports 1  2  3  4
  -----------------
        .  .  .  .
Line Card Diag Status for Module 9 (. = Pass, F = Fail, N = N/A)
 Loopback Status [Reported by Module 1] :
  Ports 1  2  3  4
  -----------------
        .  . F  .

!--- Faulty.

 Channel Status :
  Ports 1  2  3  4
  -----------------
        .  .  .  .

Aanbeveling

Cisco raadt aan alle switches in te stellen op gebruik van volledige diagnostiek om maximale foutdetectie te bieden en storingen tijdens normale bewerkingen te voorkomen.

Opmerking: deze wijziging wordt pas van kracht wanneer het apparaat opnieuw wordt opgestart. Geef deze opdracht uit om volledige diagnostiek in te stellen:

set test diaglevel complete 

Overige opties

In sommige situaties is een snelle opstarttijd te verkiezen boven wachten om volledige diagnostiek uit te voeren. Er zijn andere factoren en timing betrokken bij het opvoeden van een systeem, maar over het algemeen voegen POST en online diagnostiek ongeveer een derde in tijd toe. In het testen met een volledig ingevuld single Supervisor Engine chassis met negen sleuven met een Catalyst 6509, was de totale opstarttijd ongeveer 380 seconden met volledige diagnostiek, ongeveer 300 seconden met minimale diagnostiek, en slechts 250 seconden met diagnostiek omzeild. Geef deze opdracht uit om bypass te configureren:

set test diaglevel bypass

Opmerking: Catalyst 4500/4000 accepteert dat u geconfigureerd bent voor minimale diagnostiek, maar dit resulteert nog steeds in een volledige test die wordt uitgevoerd. De minimale modus kan in de toekomst op dit platform worden ondersteund.

Run-time diagnostiek

Zodra het systeem in werking is, voert de switch Supervisor Engine verschillende monitoring van de andere modulen uit. Als een module niet bereikbaar is via de beheerberichten (Serial Control Protocol [SCP] die over de out-of-band beheerbus loopt), probeert de Supervisor Engine de kaart opnieuw te starten of andere actie te ondernemen zoals aangewezen.

Operationeel overzicht

De Supervisor Engine voert automatisch verschillende controles uit; dit vereist geen configuratie. Voor Catalyst 5500/5000 en Catalyst 6500/6000 worden deze onderdelen van de switch gecontroleerd:

• NMP via een waakhond

• Verbeterde EARL-chipfouten

• Inband-kanaal van Supervisor Engine naar backplane

• Modules via keepalives via out-of-band kanaal (Catalyst 6500/6000)

• Active Supervisor Engine wordt gecontroleerd door de standby Supervisor Engine voor status (Catalyst 6500/6000)

Detectie van systeem- en hardwarefouten

Operationeel overzicht

In CatOS 6.2 en hoger is verdere functionaliteit toegevoegd om kritieke systeem en hardware-level componenten te monitoren. Deze drie hardwarecomponenten worden ondersteund:

• Inband

• Poortteller

• Geheugen

Wanneer de functie is ingeschakeld en een foutvoorwaarde wordt gedetecteerd, genereert de switch een syslog-bericht. Het bericht informeert de beheerder dat er een probleem bestaat voordat merkbaar prestatieverlies optreedt. In CatOS-versies 6.4(16), 7.6(12), 8.4(2) en hoger, veranderde de standaardmodus voor alle drie componenten van uitgeschakeld naar ingeschakeld.

Inband

Als een inband fout wordt gedetecteerd, een syslog bericht u dat een probleem bestaat voordat merkbaar prestatieverlies optreedt. De fout toont het type van inband mislukkingsvoorkomen. Voorbeelden hiervan zijn:

• Inband vast

• Resourcefouten

• Inband failliet tijdens bootup

Bij de detectie van een inband ping-fout, meldt de functie ook een extra syslog-bericht met een snapshot van de huidige Tx en Rx-snelheid op de inband-verbinding, CPU en de backplane belasting van de switch. Met dit bericht kunt u op de juiste manier bepalen of de inband vast zit (geen Tx/Rx) of overbelast is (excessief Tx/Rx). Deze extra informatie kan u helpen de oorzaak van inband pingfouten te bepalen.

Poortteller

Wanneer u deze functie inschakelt, maakt en start het een proces om poorttellers te debuggen. De poortteller controleert periodiek geselecteerde interne poortfoutentellers. De architectuur van de lijnkaart, en meer specifiek de ASIC's op de module, bepaalt welke functies de vragen van de functie weergeeft. Cisco Technical Support of Development Engineering kan deze informatie vervolgens gebruiken om problemen op te lossen. Deze functie ondervraagt geen fouttellers zoals FCS, CRC, uitlijning en looppas die direct zijn gekoppeld aan de verbinding tussen partners. Raadpleeg het gedeelte EtherChannel/Link Errors Handling van dit document om deze mogelijkheid te kunnen integreren.

De enquête wordt elke 30 minuten uitgevoerd en wordt uitgevoerd op de achtergrond van geselecteerde fout tellers. Als de telling tussen twee volgende opiniepeilingen op dezelfde poort omhoog gaat, meldt een syslog-bericht het incident en geeft de module/poort en fout teller details.

De poortteller-optie wordt niet ondersteund op het Catalyst 4500/4000-platform.

Geheugen

Het in staat stellen van deze eigenschap voert achtergrond controle en de opsporing van de corruptievoorwaarden van de BORREL uit. Dergelijke geheugencorruptieomstandigheden omvatten:

• Toewijzing

• bevrijding

• Buiten bereik

• Slechte uitlijning

Aanbeveling

Schakel alle functies voor foutdetectie in, waaronder inband, poorttellers en geheugen, waar deze worden ondersteund. Het inschakelen van deze functies zorgt voor verbeterde proactieve systeem- en hardwareverwaringdiagnostiek voor het Catalyst switch-platform. Geef deze opdrachten uit om alle drie de functies voor foutdetectie in te schakelen:

set errordetection inband enable

!--- This is the default in CatOS 6.4(16), 7.6(12), 8.4(2), and later.


set errordetection portcounters enable

!--- This is the default in CatOS 6.4(16), 7.6(12), 8.4(2), and later.


set errordetection memory enable

!--- This is the default in CatOS 6.4(16), 7.6(12), 8.4(2), and later.

Geef deze opdracht uit om te bevestigen dat foutdetectie is ingeschakeld:

>show errordetection

Inband error detection:                   enabled
Memory error detection:                   enabled
Packet buffer error detection:            errdisable
Port counter error detection:             enabled
Port link-errors detection:               disabled
Port link-errors action:                  port-failover
Port link-errors interval:                30 seconds

Behandeling van EtherChannel/Link-fouten

Operationeel overzicht

In CatOS 8.4 en hoger is een nieuwe functie geïntroduceerd om een automatische failover van verkeer te bieden van de ene poort in een EtherChannel naar een andere poort in dezelfde EtherChannel. De poortfailover treedt op wanneer een van de poorten in het kanaal een configureerbare foutdrempel binnen het opgegeven interval overschrijdt. De poortfailover vindt alleen plaats als er nog een operationele poort in EtherChannel over is. Als de mislukte poort de laatste poort in EtherChannel is, voert de poort de poort-failover-status niet in. Deze poort blijft verkeer doorgeven, ongeacht het type fouten dat wordt ontvangen. De enige, niet kanaliserende havens gaan niet in de haven-failover staat. Deze poorten gaan naar de erreless status wanneer de foutdrempel binnen het opgegeven interval wordt overschreden.

Deze optie is alleen effectief wanneer u foutdetectiepoorttellers inschakelt. De te controleren koppelingsfouten zijn gebaseerd op drie tellers:

• In fouten

• RXCRC’s (CRC-lampfouten)

• TxCRC’s

Geef de show tellers opdracht uit op een switch om het aantal error tellers weer te geven. Hierna volgt een voorbeeld:

>show counters 4/48

.......

32 bit counters

0  rxCRCAlignErrors           =          0
.......

6  ifInErrors                 =          0
.......

12 txCRC                      =          0

Deze tabel bevat een lijst met mogelijke configuratieparameters en de bijbehorende standaardconfiguratie:

Als de functie is ingeschakeld en de foutentelling van een poort de hoge waarde bereikt van de configureerbare drempelwaarde binnen de opgegeven bemonsteringstijdsperiode, is de configureerbare actie hetzij de fout uitschakelen of de poortfailover. De fout schakelt actie uit en plaatst de poort in de ereless status. Als u de poortfailover-actie configureert, wordt de status van het poortkanaal in overweging genomen. De poort is alleen uitgeschakeld als de poort zich in een kanaal bevindt, maar die poort is niet de laatste operationele poort in het kanaal. Bovendien, als de geconfigureerde actie een poortfailover is en de poort één poort is of niet-gekanaliseerde poort, wordt de poort in de ereless status geplaatst wanneer het aantal poortfouten de hoge waarde van de drempel bereikt.

Het interval is een timer constante voor het lezen van de poortfoutentellers. De standaardwaarde van het link-error interval is 30 seconden. Het toegestane bereik ligt tussen 30 en 1800 seconden.

Er bestaat een risico dat een haven door een onverwachte eenmalige gebeurtenis per ongeluk wordt uitgeschakeld. Om dit risico tot een minimum te beperken, worden alleen handelingen naar een haven verricht wanneer de toestand blijft voortduren door dit opeenvolgende aantal monsternemingen. De standaardbemonsteringswaarde is 3 en het toegestane bereik ligt tussen 1 en 255.

De drempelwaarde is een absoluut aantal dat moet worden gecontroleerd op basis van de link-error-interval. De standaard link-fout lage drempel is 1000 en het toegestane bereik is 1 tot 65.535. De standaard link-fout hoge drempel is 1001. Wanneer het opeenvolgende aantal bemonsteringstijden de lage drempel bereikt, wordt een syslog verzonden. Als de opeenvolgende bemonsteringstijden de hoge drempel bereiken, wordt een syslog verzonden en wordt een fout uitgeschakeld of poortfailover-actie geactiveerd.

Opmerking: gebruik dezelfde poortfout-detectieconfiguratie voor alle poorten in een kanaal. Verwijs naar deze secties van de de softwareconfiguratiegids van Catalyst 6500 Series voor meer informatie:

• Het gedeelte EtherChannel/Link Error Handling (Foutebehandeling EtherChannel/Link) controleren van status en connectiviteit

• Het gedeelte Configuration Port Error Detection van Configuration Ethernet, Fast Ethernet, Gigabit Ethernet en 10-Gigabit Ethernet-switching

Aanbevelingen

Omdat de functie SCP-berichten gebruikt om de gegevens op te nemen en te vergelijken, kunnen grote aantallen actieve poorten CPU-intensief zijn. Dit scenario is nog CPU-intensiever wanneer het drempelinterval is ingesteld op een zeer kleine waarde. Schakel deze optie discreet in voor poorten die zijn aangewezen als kritieke verbindingen en verkeers voor gevoelige toepassingen. Geef deze opdracht uit om de detectie van linkfouten wereldwijd mogelijk te maken:

set errordetection link-errors enable

Begin ook met de standaarddrempel, het interval en de bemonsteringsparameters. En gebruik de standaardactie, poortfailover.

Geef deze opdrachten uit om de globale link-error parameters op afzonderlijke poorten toe te passen:

set port errordetection mod/port inerrors enable

set port errordetection mod/port rxcrc enable

set port errordetection mod/port txcrc enable

U kunt deze opdrachten geven om de configuratie van link-fouten te verifiëren:

show errordetection

show port errordetection {mod | mod/port}

Catalyst 6500/6000 pakketbufferdiagnostiek

In CatOS-versies 6.4(7), 7.6(5) en 8.2(1) werd Catalyst 6500/6000 pakketbufferdiagnostiek geïntroduceerd. De pakketbufferdiagnostiek, die standaard is ingeschakeld, detecteert pakketbufferfouten die worden veroorzaakt door tijdelijke Statische RAM-fouten (SRAM). Detectie vindt plaats op deze 48-poorts 10/100 Mbps lijnmodules:

• WS-X6248-RJ45 switch

• WS-X6248-RJ21 switch

• WS-X6348-RJ45 switch

• WS-X6348-RJ21 switch

• WS-X6148-RJ45 switch

• WS-X6148-RJ21 switch

Wanneer de mislukkingsvoorwaarde voorkomt, blijven 12 van de 48 10/100-Mbps poorten verbonden en kunnen zij willekeurige connectiviteitsproblemen ervaren. De enige manier om te herstellen van deze toestand is de stroomcyclus van de lijnmodule.

Operationeel overzicht

De pakketbufferdiagnostiek controleert de gegevens die in een specifieke sectie van de pakketbuffer zijn opgeslagen om te bepalen als het door voorbijgaande SRAM-fouten wordt beschadigd. Als het proces iets anders leest dan wat het geschreven heeft, voert het twee mogelijke configureerbare herstelopties uit:

1. De standaardactie is om de lijnkaartpoorten die worden beïnvloed door de bufferfout, uit te schakelen.

2. De tweede optie is om cyclus de lijnkaart aan te drijven.

Er zijn twee syslogberichten toegevoegd. De berichten voorzien in een waarschuwing van de fout onmogelijkheid van de poorten of de stroomcyclus van de module vanwege pakketbufferfouten:

%SYS-3-PKTBUFFERFAIL_ERRDIS:Packet buffer failure detected.
Err-disabling port 5/1.
%SYS-3-PKTBUFFERFAIL_PWRCYCLE: Packet buffer failure detected.
Power cycling module 5.

In CatOS-versies die eerder zijn dan 8.3 en 8.4, ligt de stroomcyclustijd van de lijnkaart tussen 30 en 40 seconden. Een Rapid Boot-functie werd geïntroduceerd in CatOS-versies 8.3 en 8.4. De functie downloadt de firmware automatisch naar de geïnstalleerde lijnkaarten tijdens het initiële opstartproces om de opstarttijd te minimaliseren. Met de functie Rapid Boot kunt u de tijd voor het opstarten van het apparaat terugbrengen tot ongeveer 10 seconden.

Aanbeveling

Cisco raadt de standaardoptie ereless aan. Deze actie heeft de minste invloed op de netwerkservice tijdens de productietijden. Verplaats, indien mogelijk, de verbinding die door de foutloze poorten is aangetast naar andere beschikbare switch poorten om de service te herstellen. Plan een handmatige stroomcyclus van de lijnkaart tijdens het onderhoudsvenster. Geef de reset module mod-opdracht uit om volledig te herstellen van de beschadigde pakketbuffer-voorwaarde.

Opmerking: Als de fouten blijven bestaan nadat de module is hersteld, probeer dan de module opnieuw te plaatsen.

Geef deze opdracht uit om de erreless optie in te schakelen:

set errordetection packet-buffer errdisable

!--- This is the default.

Andere optie

Omdat een energiecyclus van de lijnkaart nodig is om alle poorten die een SRAM-fout hebben ondervonden volledig te herstellen, is een alternatieve herstelactie om de stroomkringoptie te configureren. Deze optie is nuttig in omstandigheden waarin een stroomonderbreking in netwerkdiensten die tussen 30 en 40 seconden kan duren, aanvaardbaar is. Deze tijdsduur is de tijd die nodig is om een lijnmodule volledig te laten draaien en zichzelf weer in dienst te stellen zonder de Rapid Boot-functie. Met de functie Rapid Boot kunt u de tijd van de stroomonderbreking in netwerkservices terugbrengen tot 10 seconden met de optie voor het energiecyclus. Geef deze opdracht uit om de voedingsprogrammaoptie in te schakelen:

set errordetection packet-buffer power-cycle

Packet Buffer diagnostiek

Deze test is alleen voor Catalyst 5500/5000 switches. Deze test is ontworpen om defecte hardware te vinden op Catalyst 5500/5000 switches die Ethernet-modules gebruiken met specifieke hardware die 10/100-Mbps connectiviteit biedt tussen gebruikerspoorten en de switch-backplane. Aangezien zij geen CRC kunnen uitvoeren die trunked kaders controleren, als een buffer van het poortpakket tijdens runtime gebrekkig wordt, zouden de pakketten kunnen worden bedorven en CRC fouten veroorzaken. Helaas, dit kan leiden tot de verspreiding van slechte frames verder in het Catalyst 5500/5000 ISL-netwerk, die mogelijk regelvliegtuig verstoring en uitzending stormen in slechtst denkbare scenario's veroorzaakt.

Nieuwe Catalyst 5500/5000 modules en andere platforms hebben hardwarefoutcontroles bijgewerkt ingebouwd en hebben de pakketbuffertests niet nodig, zodat er geen optie is om het te configureren.

De lijnmodules die de pakketbufferdiagnostiek nodig hebben zijn WS-X5010, WS-X5011, WS-X5013, WS-X5020, WS-X511, WS-X5113, WS-X5114, WS-X5201, WS-X5203, WS-X5213/a, WS-X223, WS-X 524, WS-X5506, WS-X5509, WS-U5531, WS-U5533 en WS-U5535.

Operationeel overzicht

Deze diagnostische controle zorgt ervoor dat gegevens die zijn opgeslagen in een specifieke sectie van de pakketbuffer niet per ongeluk worden beschadigd door defecte hardware. Als het proces iets anders leest dan het schreef, sluit het de poort in mislukte modus af, omdat die poort gegevens kan beschadigen. Er is geen foutdrempel nodig. Mislukte poorten kunnen niet opnieuw worden ingeschakeld tot de module is gereset (of vervangen).

Er zijn twee modi voor pakketbuffertests: gepland en op aanvraag. Wanneer een test begint, worden syslog-berichten gegenereerd om de verwachte lengte van de test aan te geven (afgerond tot op de dichtstbijzijnde minuut) en het feit dat de test is begonnen. De exacte lengte van de test varieert per poorttype, grootte van de buffer en het type testrun.

Op aanvraag testen zijn agressief om binnen enkele minuten af te ronden. Aangezien deze tests actief interfereren met pakketgeheugen, moeten poorten administratief worden uitgeschakeld voordat ze worden getest. Geef deze opdracht uit om de poorten te sluiten:

> (enable) test packetbuffer 4/1
Warning: only disabled ports may be tested on demand - 4/1 will be skipped.
> (enable) set port disable 4/1
> (enable) test packetbuffer 4/1
Packet buffer test started. Estimated test time: 1 minute.
%SYS-5-PKTTESTSTART:Packet buffer test started
%SYS-5-PKTTESTDONE:Packet buffer test done. Use 'show test' to see test results

Geplande tests zijn veel minder agressief dan de tests op aanvraag, en ze worden uitgevoerd op de achtergrond. De tests worden parallel uitgevoerd over meerdere modules maar op één poort per module tegelijk. De test bewaart, schrijft en leest kleine secties van pakketbuffergeheugen voordat de gebruiker pakketbuffergegevens terugzet en genereert dus geen fouten. Aangezien de test echter is geschreven om geheugen te bufferen, blokkeert het inkomende pakketten voor een paar milliseconden en veroorzaakt wat verlies op drukke links. Standaard is er een pauze van acht seconden tussen elke buffer-schrijftest om elk pakketverlies te minimaliseren, maar dit betekent dat een systeem vol modules die de pakketbuffertest nodig hebben meer dan 24 uur kan duren voordat de test kan worden voltooid. Deze geplande test kan standaard wekelijks om 03:30 op zondag vanaf CatOS 5.4 of later worden uitgevoerd en de teststatus kan met deze opdracht worden bevestigd:

>show test packetbuffer status


!--- When test is running, the command returns !--- this information:

Current packet buffer test details
Test Type           : scheduled
Test Started        : 03:30:08 Jul 20 2001
Test Status         : 26% of ports tested
Ports under test    : 10/5,11/2
Estimated time left : 11 minutes

!--- When test is not running, !--- the command returns this information:

Last packet buffer test details
Test Type           : scheduled
Test Started        : 03:30:08 Jul 20 2001
Test Finished       : 06:48:57 Jul 21 2001

Aanbeveling

Cisco raadt u aan de geplande pakketbuffertestfunctie voor Catalyst 5500/5000-systemen te gebruiken, aangezien het voordeel van het detecteren van problemen op modules zwaarder weegt dan het risico van laag pakketverlies.

Er moet dan een gestandaardiseerde wekelijkse tijd worden gepland over het netwerk, die de klant in staat stelt om naar behoefte verbindingen te wijzigen van defecte poorten of RMA-modules. Omdat deze test pakketverlies kan veroorzaken, afhankelijk van de netwerkbelasting, moet deze worden gepland voor stillere netwerktijden, zoals de standaard van 3:30 AM op een zondagochtend. Geef deze opdracht op om de testtijd in te stellen:

set test packetbuffer Sunday 3:30

!--- This is the default.

Zodra ingeschakeld (zoals wanneer CatOS wordt opgewaardeerd naar 5.4 en later voor het eerst), is er een kans dat een eerder verborgen geheugen/hardware probleem wordt blootgesteld, en een poort wordt automatisch uitgeschakeld als gevolg daarvan. U kunt dit bericht zien:

%SYS-3-PKTBUFBAD:Port 1/1 failed packet buffer test

Overige opties

Als het niet aanvaardbaar is om een laag niveau van pakketverlies per poort op een wekelijkse basis te riskeren, dan wordt het aanbevolen om de on-demand functie te gebruiken tijdens geplande uitval. Geef deze opdracht uit om deze optie per bereik handmatig te starten (hoewel de poort eerst administratief moet worden uitgeschakeld):

test packetbuffer port range

Vastlegging systeem

Syslog-berichten zijn Cisco-specifiek en een belangrijk onderdeel van proactief foutenbeheer. Een bredere reeks netwerk- en protocolvoorwaarden wordt gerapporteerd met syslog dan mogelijk is via gestandaardiseerde SNMP. De beheerplatforms, zoals Cisco Resource Manager Essentials (RME’s) en Network Analysis Toolkit (NATkit), maken krachtig gebruik van sysloginformatie omdat zij deze taken uitvoeren:

• Presenteer analyse per ernst, bericht, apparaat, enzovoort

• Schakel het filteren van berichten in die voor analyse binnenkomen

• Waarschuwing van triggers, zoals pagers, of op aanvraag verzamelen van inventaris- en configuratiewijzigingen

Aanbeveling

Een belangrijk aandachtspunt is welk niveau van logboekinformatie lokaal moet worden gegenereerd en in de switch buffer moet worden gehouden in tegenstelling tot het niveau dat naar een syslog server wordt verzonden (met behulp van de ingestelde waarde voor de waarde van de logboekserver). Sommige organisaties registreren een hoog niveau van informatie centraal, terwijl anderen naar de switch zelf gaan om de meer gedetailleerde logboeken voor een gebeurtenis te bekijken of een hoger niveau van syslog toe te laten vangen slechts tijdens het oplossen van problemen.

Debugging is anders op CatOS-platforms dan Cisco IOS-software, maar gedetailleerd systeemvastlegging kan worden ingeschakeld op een per-sessie basis met ingestelde vastlegging sessie inschakelen zonder te veranderen wat standaard is gelogd.

Cisco raadt u over het algemeen aan de steeksleutel en de systeemsynchronisatiefaciliteiten naar niveau 6 te brengen, aangezien dit belangrijke stabiliteitsfuncties zijn die moeten worden bijgehouden. Bovendien voor multicast milieu's, wordt het brengen van het registrerenniveau van de maskerfaciliteit tot 4 geadviseerd zodat syslog berichten worden geproduceerd als de routerhavens worden geschrapt. Helaas, voor CatOS 5.5(5) kan dit resulteren in syslog berichten worden opgenomen voor IGMP toetreedt en vertrekt, wat te luidruchtig is om te controleren. Tot slot, als IP-invoerlijsten worden gebruikt, wordt een minimum registratieniveau van 4 aanbevolen om onbevoegde aanmeldingspogingen op te nemen. Geef deze opdrachten uit om deze opties in te stellen:

set logging buffer 500

!--- This is the default.

set logging server syslog server IP address
set logging server enable

!--- This is the default.

set logging timestamp enable
set logging level spantree 6 default

!--- Increase default STP syslog level.

set logging level sys 6 default

!--- Increase default system syslog level.

set logging server severity 4

!--- This is the default; !--- it limits messages exported to syslog server.

set logging console disable

Schakel de consoleberichten uit om te beschermen tegen het risico dat de switch ophangt terwijl hij wacht op een reactie van een langzame of niet-bestaande terminal wanneer het berichtvolume hoog is. Logboekregistratie voor console is een hoge prioriteit onder CatOS en wordt voornamelijk gebruikt om de laatste berichten lokaal vast te leggen tijdens probleemoplossing of in een switch crashscenario.

Deze tabel geeft de individuele logboekfaciliteiten, standaardniveaus en aanbevolen wijzigingen voor Catalyst 6500/6000. Elk platform heeft enigszins verschillende faciliteiten, afhankelijk van de ondersteunde functies.

¹ In CatOS 7.x en hoger vervangt de ethische faciliteitscode de pagp faciliteitscode om LACP-ondersteuning weer te geven.

Opmerking: momenteel registreren de Catalyst switches een bericht op systeemniveau 6 van de configuratiewijziging voor elke set of duidelijke opdracht die is uitgevoerd, in tegenstelling tot Cisco IOS-software, die het bericht alleen activeert nadat u de configuratiemodus hebt verlaten. Als u RME's nodig hebt om back-ups te maken van configuraties in real-time op deze trigger, dan moeten deze berichten ook naar de RME's syslog server worden verzonden. Voor de meeste klanten zijn periodieke configuratieback-ups voor Catalyst-switches voldoende en is er geen wijziging van de logboekernst van de standaardserver nodig.

Als u uw NMS-meldingen afstemt, raadpleegt u de systeemberichtengids.

Simple Network Management Protocol

SNMP wordt gebruikt om statistieken, tellers en tabellen op te halen die zijn opgeslagen in Network Device Management Information Bases (MIB’s). De verzamelde informatie kan door NMS's (zoals HP Openview) worden gebruikt om realtime waarschuwingen te genereren, beschikbaarheid te meten en informatie over capaciteitsplanning te produceren, en om configuratie- en probleemoplossingscontroles te helpen uitvoeren.

Operationeel overzicht

Met sommige beveiligingsmechanismen kan een netwerkbeheerstation informatie ophalen in de MIB's met SNMP-protocol volgende verzoeken ontvangen en ontvangen en parameters wijzigen met de ingestelde opdracht. Bovendien kan een netwerkapparaat worden geconfigureerd om een trap-bericht voor de NMS te genereren voor real-time alarmering. SNMP-polling gebruikt IP UDP-poort 161 en SNMP-traps gebruiken poort 162.

Cisco ondersteunt deze versies van SNMP:

• SNMPv1: RFC 1157 Internet Standard, met behulp van clear tekst community-string security. Een IP-adrestoegangscontrolelijst en een wachtwoord definiëren de community van managers die toegang kunnen krijgen tot de agent MIB.

• SNMPv2C: een combinatie van SNMPv2, een concept-internetstandaard die is gedefinieerd in RFC's 1902 tot en met 1907, en SNMPv2C, een op de gemeenschap gebaseerd beheerskader voor SNMPv2 dat een experimenteel concept is dat is gedefinieerd in RFC 1901. De voordelen omvatten een bulkherroepingsmechanisme dat het herwinnen van lijsten en grote hoeveelheden informatie steunt, minimaliseert het aantal vereiste ronde-reizen, en verbetert fout behandeling.

• SNMPv3: RFC 2570 (voorgesteld concept) biedt beveiligde toegang tot apparaten via de combinatie van verificatie en versleuteling van pakketten via het netwerk. De beveiligingsfuncties in SNMPv3 zijn:

  • Berichtintegriteit: garandeert dat er niet met een pakket is geknoeid tijdens het transport

  • Verificatie: bepaalt dat het bericht afkomstig is van een geldige bron

  • Versleuteling: door de inhoud van een pakket bladeren om te voorkomen dat het door een niet-geautoriseerde bron gemakkelijk wordt bekeken

In deze tabel worden de combinaties van beveiligingsmodellen aangegeven:

Opmerking: Houd deze informatie in gedachten over SNMPv3-objecten:

• Elke gebruiker behoort tot een groep.

• Een groep definieert het toegangsbeleid voor een verzameling gebruikers.

• Een toegangsbeleid definieert welke SNMP-objecten kunnen worden benaderd om te lezen, te schrijven en te maken.

• Een groep bepaalt de lijst met meldingen die de gebruikers kunnen ontvangen.

• Een groep definieert ook het beveiligingsmodel en het beveiligingsniveau voor de gebruikers.

Aanbeveling SNMP-trap

SNMP is de basis van al het netwerkbeheer en is ingeschakeld en gebruikt op alle netwerken. De SNMP-agent op de switch moet worden ingesteld om de versie van SNMP te gebruiken die door het beheerstation wordt ondersteund. Aangezien een agent kan communiceren met meerdere managers, is het mogelijk om de software te configureren om communicatie met één beheerstation te ondersteunen met behulp van het SNMPv1 protocol en een ander met behulp van het SNMPv2 protocol, bijvoorbeeld.

De meeste NMS-stations maken vandaag gebruik van SNMPv2C onder deze configuratie:

set snmp community read-only string


!--- Allow viewing of variables only.


set snmp community read-write string


!--- Allow setting of variables.


set snmp community read-write-all string

!--- Include setting of SNMP strings. 

Cisco raadt aan SNMP-traps in te schakelen voor alle gebruikte functies (niet-gebruikte functies kunnen desgewenst worden uitgeschakeld). Als een trap is ingeschakeld, kan deze worden getest met de test SNMP-opdracht en de juiste verwerkingsinstelling op de NMS voor de fout (zoals een pager-waarschuwing of pop-up).

Alle traps zijn standaard uitgeschakeld en moeten aan de configuratie worden toegevoegd, individueel of door met de all parameter, zoals getoond:

set snmp trap enable all
set snmp trap server address read-only community string

De beschikbare vallen in CatOS 5.5 omvatten:

Opmerking: De syslog val verstuurt alle syslog berichten die door de switch gegenereerd worden ook als SNMP trap naar de NMS. Als syslogwaarschuwing al wordt uitgevoerd door een analyzer zoals Cisco Works 2000 RME’s, is het niet noodzakelijk nuttig om deze informatie twee keer te ontvangen.

In tegenstelling tot Cisco IOS-software zijn SNMP-traps op poortniveau standaard uitgeschakeld omdat switches honderden actieve interfaces kunnen hebben. Cisco raadt daarom aan dat belangrijke poorten, zoals infrastructuurlinks naar routers, switches en hoofdservers, SNMP-traps op poortniveau hebben ingeschakeld. Andere poorten, zoals host-poorten van gebruikers, zijn niet nodig, wat het netwerkbeheer helpt te vereenvoudigen.

set port trap port range enable

!--- Enable on key ports only.

SNMP-opiniepeiling

Een netwerkbeheeroverzicht wordt aanbevolen om specifieke behoeften in detail te bespreken. Er worden echter enkele fundamentele Cisco-filosofieën voor het beheer van grote netwerken vermeld:

• Doe iets eenvoudigs en doe het goed.

• Verminder de overbelasting van het personeel door excessieve data polling, verzameling, tools en handmatige analyse.

• Netwerkbeheer is mogelijk met slechts een paar tools, zoals HP OpenView als een NMS, Cisco RME's als configuratie, syslog, inventaris en softwarebeheerder, Microsoft Excel als een NMS data analyzer en CGI als een manier om te publiceren naar het web.

• Het publiceren van rapporten aan het web stelt gebruikers, zoals senior management en analisten, in staat om zichzelf te helpen met informatie zonder het verrichtingenpersoneel te belasten met vele speciale verzoeken.

• Ontdek wat goed werkt op het netwerk en laat het met rust. Concentreer je op wat niet werkt.

De eerste fase van de implementatie van NMS moet zijn aan basislijn de netwerkhardware. Er kan veel worden afgeleid over de status van apparaten en protocollen van eenvoudige CPU’s, geheugen en buffergebruik op routers, en NMP-CPU’s, geheugen en backplane gebruik op switches. Pas na een hardwarestandlijn worden de L2 en L3 verkeersbelasting, piek en gemiddelde basislijnen volledig betekenisvol. Basislijnen worden meestal vastgesteld over een aantal maanden om inzicht te krijgen in dagelijkse, wekelijkse en driemaandelijkse trends - volgens de bedrijfscyclus van het bedrijf.

Vele netwerken lijden aan NMS prestaties en capaciteitsproblemen die door overopiniepeilingen worden veroorzaakt. Het is daarom aanbevolen om, zodra de basislijn is vastgesteld, alarm- en RMON-drempels in te stellen op de apparaten zelf om de NMS te waarschuwen voor abnormale veranderingen en zo de stemming te verwijderen. Dit stelt het netwerk in staat om de operatoren te vertellen wanneer iets niet normaal is in plaats van voortdurend te stemmen om te zien of alles normaal is. Drempelwaarden kunnen worden ingesteld op basis van verschillende regels, zoals een maximumwaarde plus een percentage of standaardafwijking van een gemiddelde, en vallen buiten het toepassingsgebied van dit document.

De tweede fase van implementatie NMS is bijzondere gebieden van het netwerk met SNMP meer in detail te pollen. Dit zijn onder andere de gebieden waar twijfel bestaat, de gebieden die voor verandering staan, of de gebieden die als goed functionerend kunnen worden aangemerkt. Gebruik de NMS-systemen als zoeklicht om het netwerk in detail te scannen en hotspots te belichten (probeer niet het hele netwerk op te lichten).

De Cisco Network Management Consulting-groep stelt voor dat deze belangrijke fout-MIB's worden geanalyseerd of bewaakt in campusnetwerken. Raadpleeg de richtlijnen voor netwerkbewaking en gebeurteniscorrelatie van Cisco voor meer informatie (bijvoorbeeld over prestaties en MIB's voor opiniepeiling).

Raadpleeg Cisco Network Management Toolkit - MIB’s voor meer informatie over ondersteuning van Cisco MIB.

Opmerking: sommige standaard MIB's gaan ervan uit dat een bepaalde SNMP-entiteit slechts één instantie van de MIB bevat. De standaard MIB heeft dus geen index die gebruikers rechtstreeks toegang geeft tot een bepaald geval van de MIB. In deze gevallen wordt community string indexering geleverd om toegang te krijgen tot elke instantie van de standaard MIB. De syntaxis is [community string]@[instance number], waarbij de instantie doorgaans een VLAN-nummer is.

Overige opties

De veiligheidsaspecten van SNMPv3 betekenen dat het gebruik ervan naar verwachting SNMPv2 op tijd zal inhalen. Cisco raadt klanten aan zich voor te bereiden op dit nieuwe protocol als onderdeel van hun NMS-strategie. De voordelen zijn dat de gegevens veilig uit de apparaten van SNMP zonder angst voor manipulatie of corruptie kunnen worden verzameld. switch Vertrouwelijke informatie, zoals in SNMP ingestelde opdrachtpakketten die een netwerkconfiguratie wijzigen, kan worden versleuteld om te voorkomen dat de inhoud ervan op het netwerk wordt weergegeven. Bovendien kunnen verschillende gebruikersgroepen verschillende rechten hebben.

Opmerking: de configuratie van SNMPv3 is aanzienlijk anders dan de SNMPv2-opdrachtregel en een verhoogde CPU-belasting op de Supervisor Engine is te verwachten.

Externe bewaking

RMON maakt het mogelijk dat MIB-gegevens vooraf door het netwerkapparaat zelf worden verwerkt, ter voorbereiding op gemeenschappelijk gebruik of toepassing van die informatie door de netwerkbeheerder, zoals het uitvoeren van historische basislijnbepaling en drempelanalyse.

De resultaten van RMON-verwerking worden opgeslagen in RMON MIB's voor verdere verzameling door een NMS, zoals gedefinieerd in RFC 1757.

Operationeel overzicht

Catalyst switches ondersteunen mini-RMON in hardware op elke poort, die bestaat uit vier basis-RMON-1-groepen: Statistieken (groep 1), Geschiedenis (groep 2), Alarmen (groep 3) en Evenementen (groep 9).

Het krachtigste deel van RMON-1 is het drempelmechanisme dat door de alarm- en gebeurtenisgroepen wordt geboden. Zoals besproken stelt de configuratie van RMON-drempels de switch in staat een SNMP-trap te verzenden wanneer zich een abnormale situatie voordoet. Zodra zeer belangrijke poorten zijn geïdentificeerd, kan SNMP worden gebruikt om tellers of RMON-geschiedenisgroepen te pollen en basislijnen te maken die normale verkeersactiviteit voor die poorten opnemen. Vervolgens kan RMON worden ingesteld op stijgende en dalende drempels en kunnen alarmen worden geconfigureerd voor wanneer er een gedefinieerde afwijking van de basislijn is.

De configuratie van drempelwaarden kan het best worden uitgevoerd met een RMON-beheerpakket, omdat de succesvolle aanmaak van de rijen van parameters in de tabellen van het alarm en de gebeurtenis vervelend is. Commerciële RMON-NMS-pakketten, zoals Cisco Traffic Director, een deel van Cisco Works 2000, nemen GUI's op die de instelling van RMON-drempels veel eenvoudiger maken.

Voor basislijndoeleinden, verstrekt de groep etherStats een nuttige waaier van L2 verkeersstatistieken. De objecten in deze tabel kunnen worden gebruikt voor het verkrijgen van statistieken over unicast-, multicast- en broadcast-verkeer en een aantal L2-fouten. De RMON-agent op de switch kan ook worden geconfigureerd om deze bemonsterde waarden in de geschiedenisgroep op te slaan. Dit mechanisme maakt het mogelijk de hoeveelheid stemmen te verminderen zonder het steekproefpercentage te verlagen. RMON-geschiedenissen kunnen nauwkeurige basislijnen geven zonder substantiële opiniepeilingen. Hoe meer geschiedenissen er echter worden verzameld, des te meer switches er worden gebruikt.

Terwijl de switches slechts vier basisgroepen RMON-1 verstrekken, is het belangrijk om de rest van RMON-1 en RMON-2 niet te vergeten. Alle groepen worden bepaald in RFC 2021, met inbegrip van Gebruikersgeschiedenis (groep 18) en ProbeConfig (groep 19). L3 en hogere informatie kan worden opgehaald uit switches met de SPAN-poort of VLAN ACL-functies voor omleiding die u in staat stellen verkeer te kopiëren naar een externe RMON-switchsonde of een interne Network Analysis Module (NAM).

NAMs ondersteunt alle RMON-groepen en kan zelfs gegevens op toepassingslaag onderzoeken, inclusief NetFlow-gegevens die worden geëxporteerd van Catalyst wanneer MLS is ingeschakeld. Het uitvoeren van MLS betekent dat de router niet alle switches in een stroom uitvoert, dus alleen NetFlow-data-export en geen interfacetellers geven betrouwbare VLAN-accounting.

U kunt een SPAN-poort en een pakketsonde gebruiken om een pakketstroom voor een bepaalde switch, trunk of VLAN op te nemen en de pakketten te uploaden om te decoderen met een RMON-beheerpakket. De SPAN-poort is SNMP-controleerbaar via de SPAN-groep in Cisco-STACK-MIB, zodat dit proces eenvoudig kan worden geautomatiseerd. De Traffic Director maakt gebruik van deze functies met zijn functie voor zwervende agenten.

Er zijn voorbehouden voor het overspannen van een heel VLAN. Zelfs als u een 1 Gbps sonde gebruikt, kan de volledige pakketstroom van één VLAN of zelfs één 1 Gbps full-duplex poort de bandbreedte van de SPAN-poort overschrijden. Als de SPAN-poort continu op volledige bandbreedte draait, zijn er kansen dat er gegevens verloren gaan. Raadpleeg De functie Catalyst Switched Port Analyzer (SPAN) configureren voor meer informatie.

Aanbeveling

Cisco raadt aan RMON-drempels en -alarmering te implementeren om netwerkbeheer op een intelligentere manier te ondersteunen dan alleen SNMP-polling. Dit vermindert het overheadkosten van het netwerkbeheerverkeer en staat het netwerk toe om intelligent te alarmeren wanneer iets van de basislijn is veranderd. RMON moet worden bestuurd door een externe agent zoals Traffic Director; er is geen CLI-ondersteuning. Geef deze opdrachten uit om RMON in te schakelen:

set snmp rmon enable
set snmp extendedrmon netflow enable mod


!--- For use with NAM module only.

Het is belangrijk om te onthouden dat de belangrijkste functie van een switch het doorsturen van frames is, en niet het fungeren als een grote multi-poorts RMON sonde. Daarom, als u geschiedenissen en drempels op meerdere poorten voor meerdere voorwaarden instelt, houd er dan rekening mee dat de middelen worden verbruikt. Overweeg een NAM module als u RMON opschraapt. Herinner ook de kritieke havenregel: alleen opiniepeiling en vaststelling van drempelwaarden voor de havens die in de planningsfase als belangrijk zijn aangemerkt.

Geheugenvereisten

RMON geheugengebruik is constant over alle switch platforms met betrekking tot statistiek, geschiedenissen, alarmen, en gebeurtenissen. RMON gebruikt een emmer om geschiedenissen en statistische gegevens over de RMON-agent (in dit geval de switch) op te slaan. De emmergrootte wordt bepaald op de sonde RMON (Switch Probe) of toepassing RMON (Traffic Director), dan verzonden naar de switch om te worden ingesteld. Meestal zijn geheugenbeperkingen slechts een overweging op oudere Supervisor Engines met minder dan 32MB van DRAM. Raadpleeg deze richtlijnen:

• Ongeveer 450K coderuimte wordt toegevoegd aan het beeld van NMP om mini-RMON te steunen (die vier groepen van RMON is: statistiek, geschiedenis, alarmen en gebeurtenissen). De vereiste voor dynamisch geheugen voor RMON varieert omdat dit afhankelijk is van de uitvoeringsconfiguratie. De runtime RMON-geheugengebruiksinformatie voor elke mini-RMON-groep wordt hier uitgelegd:

  • Ethernet Statistics group—neemt 800 bytes voor elke switched Ethernet/FE-interface.

  • Geschiedenisgroep-Voor de Ethernet-interface neemt elke geconfigureerde geschiedeniscontrole-ingang met 50 emmers ongeveer 3,6KB geheugenruimte en 56 bytes voor elke extra emmer.

  • Alarmen en gebeurtenissen groep-neemt 2.6KB voor elk geconfigureerd alarm en de bijbehorende gebeurtenisvermeldingen.

• Om de op RMON betrekking hebbende configuratie op te slaan, hebt u ongeveer 20K NVRAM ruimte nodig als de totale NVRAM-grootte van het systeem 256K of meer is en 10K NVRAM ruimte als de totale NVRAM-grootte 128K is.

Network Time Protocol

De NTP, RFC 1305, synchroniseert tijdregistratie tussen een reeks gedistribueerde tijdservers en clients en maakt het mogelijk gebeurtenissen te correleren wanneer systeemlogbestanden worden gemaakt of andere tijdspecifieke gebeurtenissen zich voordoen.

NTP biedt accurate clienttijd, doorgaans binnen een milliseconde op LAN’s en tot een paar tientallen milliseconden op WAN’s, ten opzichte van een primaire server die is gesynchroniseerd met Coordinated Universal Time (UTC). Typische NTP-configuraties maken gebruik van meerdere redundante servers en diverse netwerkpaden om een hoge nauwkeurigheid en betrouwbaarheid te bereiken. Sommige configuraties omvatten cryptografische verificatie om toevallige of kwaadaardige protocolaanvallen te voorkomen.

Operationeel overzicht

NTP werd voor het eerst gedocumenteerd in RFC 958, maar is geëvolueerd door RFC 1119 (NTP versie 2) en is nu in zijn derde versie zoals gedefinieerd in RFC 1305. Het loopt over UDP-poort 123. Alle NTP-communicatie maakt gebruik van UTC, wat hetzelfde is als Greenwich Mean Time.

Openbare tijdservers gebruiken

Het NTP-subnetnummer omvat momenteel meer dan 50 openbare primaire servers die direct met UTC zijn gesynchroniseerd via radio, satelliet of modem. Normaal gesproken synchroniseren clientwerkstations en servers met een relatief klein aantal clients niet met primaire servers. Er zijn ongeveer 100 openbare secundaire servers gesynchroniseerd met de primaire servers die synchronisatie aan meer dan 100.000 cliënten en servers op Internet verstrekken. De huidige lijsten worden bijgehouden op de pagina Lijst van openbare NTP-servers, die regelmatig wordt bijgewerkt. Er zijn tal van privaat primaire en secundaire servers die normaal niet beschikbaar zijn voor het publiek. Voor een lijst van openbare NTP-servers en informatie over hoe ze te gebruiken, raadpleegt u de website van de University of Delaware Time Synchronisation Server.

Aangezien er geen garantie is dat deze openbare Internet NTP servers beschikbaar zullen zijn, of dat zij de juiste tijd produceren, is het sterk aan te raden dat andere opties worden overwogen. Hierbij kan het gaan om het gebruik van diverse standalone GPS-apparaten (Global Positioning Service) die rechtstreeks op een aantal routers zijn aangesloten.

Een andere mogelijke optie is het gebruik van verschillende routers geconfigureerd als Stratum 1 meesters, hoewel dit niet wordt aanbevolen.

Stratum

Elke NTP server neemt een stratum dat aangeeft hoe ver weg van een externe bron van tijd de server is. Stratum 1 servers hebben toegang tot een soort externe tijdbron, zoals een radioklok. Stratum 2 servers verkrijgen tijdsgegevens van een genomineerde reeks Stratum 1 servers, terwijl Stratum 3 servers tijdsgegevens verkrijgen van Stratum 2 servers, enzovoort.

Relatie tussen servers

• Een server is er een die reageert op de verzoeken van de client, maar probeert geen datuminformatie uit een tijdbron op te nemen.

• Een peer is er een die reageert op de verzoeken van de klant, maar probeert de verzoeken van de klant te gebruiken als een potentiële kandidaat voor een betere tijdbron en om te helpen bij het stabiliseren van zijn klokfrequentie.

• Om een echte peer te zijn, moeten beide kanten van de verbinding in een peer relatie ingaan in plaats van één gebruiker een peer en de andere gebruiker een server te hebben. Het wordt ook aanbevolen dat peers sleutels uitwisselen, zodat alleen vertrouwde hosts met elkaar praten als peers.

• In een cliëntverzoek aan een server, beantwoordt de server de cliënt en vergeet dat de cliënt ooit een vraag stelde; in een cliëntverzoek aan een peer, beantwoordt de server de cliënt en houdt staatsinformatie over de cliënt om te volgen hoe goed het bij tijd het houden doet en welke stratumserver het in werking stelt.

  Opmerking: CatOS kan alleen optreden als NTP-client.

Het is geen probleem voor een NTP server om vele duizenden cliënten te behandelen. De verwerking van honderden peers heeft echter een geheugenimpact en het onderhoud van de staat verbruikt meer CPU-bronnen op de doos en bandbreedte.

Stemming

Het NTP protocol staat een client toe om een server te vragen wanneer het wil. In feite, wanneer NTP eerst in een apparaat van Cisco wordt gevormd, stuurt het acht vragen in snelle opeenvolging bij (24 = 16 tweede) intervallen NTP_MINPOLL. De NTP_MAXPOLL is 214 seconden (dat is 16.384 seconden of 4 uur, 33 minuten, 4 seconden), de maximumtijd die het vergt voor NTP polls opnieuw voor een reactie. Momenteel heeft Cisco geen methode om de POLL-tijd handmatig in te stellen door de gebruiker.

De NTP-peilingteller begint op 2⁶ (64) seconden en wordt verhoogd met twee (als de twee servers met elkaar synchroniseren) tot 2¹⁰. Dat wil zeggen dat u kunt verwachten dat de synchronisatieberichten worden verzonden met een interval van 64, 128, 256, 512 of 1024 seconden per geconfigureerde server of peer. De tijd varieert tussen 64 seconden en 1024 seconden als een kracht van twee gebaseerd op de fase-vergrendelde-lus die pakketten verstuurt en ontvangt. Als er veel schokken in de tijd zijn, wordt er vaker gestemd. Als de referentieklok nauwkeurig is en de netwerkconnectiviteit consistent, ziet u dat de opiniepeiltijden op 1024 seconden tussen elke opiniepeiling convergeren.

In de echte wereld betekent dit dat het NTP Poll Interval verandert als de verbinding tussen de client en de server verandert. Hoe beter de verbinding, hoe langer het poll interval, wat betekent dat de NTP-client acht reacties heeft ontvangen voor de laatste acht verzoeken (het poll interval wordt dan verdubbeld). Door een enkele gemiste respons wordt het poll interval gehalveerd. Het opiniepeilingsinterval begint bij 64 seconden en gaat naar een maximum van 1024 seconden. In de beste omstandigheden duurt het iets meer dan twee uur voordat de opiniepeiling van 64 seconden naar 1024 seconden gaat.

Uitzendingen

NTP-uitzendingen worden nooit doorgestuurd. Het bevel van de ntp uitzending veroorzaakt de router om NTP uitzendingen op de interface te voortkomen waarop het wordt gevormd. Het ntp broadcast client commando zorgt ervoor dat de router of switch naar NTP uitzendingen luistert op de interface waarop het is geconfigureerd.

NTP-verkeersniveaus

De bandbreedte die door NTP wordt gebruikt is minimaal, aangezien het interval tussen pollingberichten die tussen peers worden uitgewisseld meestal terugloopt naar niet meer dan één bericht elke 17 minuten (1024 seconden). Met zorgvuldige planning, kan dit binnen routernetwerken over de verbindingen van WAN worden gehandhaafd. De NTP-clients moeten peer zijn voor lokale NTP-servers, niet helemaal over het WAN naar de centrale webcore-routers die stratum 2-servers zullen zijn.

Een geconvergeerde NTP-client gebruikt ongeveer 0,6 bits/seconde per server.

Aanbeveling

Veel klanten hebben NTP geconfigureerd in client-modus vandaag op hun CatOS-platforms, gesynchroniseerd via verschillende betrouwbare feeds van het internet of een radioklok. Een eenvoudiger alternatief voor de servermodus bij het gebruik van een groot aantal switches is echter om NTP in de broadcast-clientmodus in te schakelen op het beheer VLAN in een switched domain. Dit mechanisme staat een volledig domein van Katalysatoren toe om een klok van één enkel uitzendingsbericht te ontvangen. De nauwkeurigheid van de tijdsbewaring wordt echter marginaal verminderd omdat de informatiestroom eenrichtingsverkeer is.

Het gebruik van loopback-adressen als bron van updates kan ook helpen bij consistentie. Beveiligingsproblemen kunnen op deze twee manieren worden aangepakt:

• Filterserver-updates

• Verificatie

Tijdscorrelatie van gebeurtenissen is in twee gevallen uiterst waardevol: problemen oplossen en beveiligingsaudits uitvoeren. Er moet zorgvuldig worden omgegaan met de bescherming van de tijdbronnen en gegevens, en encryptie wordt aanbevolen om te voorkomen dat belangrijke gebeurtenissen opzettelijk of onopzettelijk worden gewist.

Cisco raadt deze configuraties aan:

set ntp broadcastclient enable
set ntp authentication enable
set ntp key key    

!--- This is a Message Digest 5 (MD5) hash.

set ntp timezone 
set ntp summertime 

!--- This more traditional configuration creates !--- more configuration work and NTP peerings.

set ntp client enable
set ntp server IP address of time server
set timezone zone name
set summertime date change details

!--- This is a sample router configuration to distribute !--- NTP broadcast information to the Catalyst broadcast clients.

ntp source loopback0
ntp server IP address of time server
ntp update-calendar
clock timezone zone name
clock summer-time date change details ntp authentication key key
ntp access-group access-list


!--- To filter updates to allow only trusted sources of NTP information.

Interface to campus/management VLAN containing switch sc0
        ntp broadcast

Cisco-detectieprotocol

CDP uitwisselt informatie tussen aangrenzende apparaten over de datalink-laag en is uiterst nuttig bij de bepaling van de netwerktopologie en de fysieke configuratie buiten de logische of IP-laag. Ondersteunde apparaten zijn voornamelijk switches, routers en IP-telefoons. In deze sectie worden enkele verbeteringen van CDP versie 2 ten opzichte van versie 1 belicht.

Operationeel overzicht

CDP gebruikt SNAP-insluiting met typecode 2000. Op Ethernet, ATM en FDDI wordt het doelmulticastadres 01-00-0c-cc-cc-cc, HDLC-protocoltype 0x2000 gebruikt. Op Token Rings wordt het functionele adres c000.0800.0000 gebruikt. CDP-frames worden standaard elke minuut verzonden.

CDP-berichten bevatten een of meer subberichten waarmee de doelapparaten informatie over elk buurapparaat kunnen verzamelen en opslaan.

CDP, versie 1, ondersteunt deze parameters:

In CDP versie 2 zijn er extra protocolvelden geïntroduceerd. CDP versie 2 ondersteunt elk veld, maar de genoemde kunnen bijzonder nuttig zijn in switched omgevingen en worden gebruikt in CatOS.

Opmerking:  Wanneer een switch CDPv1 uitvoert, worden v2-frames gezakt. Wanneer een switch met CDPv2 een CDPv1-frame op een interface ontvangt, worden er naast CDPv2-frames CDPv1-frames verzonden vanuit die interface.

Aanbeveling

CDP is standaard ingeschakeld en is essentieel om inzicht te krijgen in aangrenzende apparaten en voor probleemoplossing. Het wordt ook gebruikt door netwerkbeheertoepassingen om L2 topologiekaarten te bouwen. Geef deze opdrachten uit om CDP in te stellen:

set cdp enable

!--- This is the default.

set cdp version v2

!--- This is the default.

In delen van het netwerk waar een hoog beveiligingsniveau vereist is (zoals Internet-facing DMZs), moet CDP als zodanig zijn uitgeschakeld:

set cdp disable port range

Het showcdp buren bevel toont de lokale CDP lijst. Inzendingen die gemarkeerd zijn met een ster (*) geven een VLAN-mismatch aan. de ingangen die met a # worden gemarkeerd wijzen op een duplex wanverhouding. Dit kan een waardevolle hulp zijn bij het oplossen van problemen.

>show cdp neighbors

* - indicates vlan mismatch.
# - indicates duplex mismatch.
Port  Device-ID          Port-ID Platform
----- ------------------ ------- ------------
 3/1  TBA04060103(swi-2) 3/1     WS-C6506
 3/8  TBA03300081(swi-3) 1/1     WS-C6506
15/1  rtr-1-msfc         VLAN 1  cisco    Cat6k-MSFC
16/1  MSFC1b             Vlan2   cisco    Cat6k-MSFC

Overige opties

Sommige switches, zoals Catalyst 6500/6000, hebben de mogelijkheid om voeding te leveren via UTP-kabels naar IP-telefoons. Informatie die door middel van CDP wordt ontvangen, helpt het energiebeheer op de switch.

Aangezien IP-telefoons een pc kunnen hebben die ermee is verbonden en beide apparaten verbinding maken met dezelfde poort op de Catalyst, heeft de switch de mogelijkheid om de VoIP-telefoon in een apart VLAN, de hulpmodule, te zetten. Hierdoor kan de switch eenvoudig een andere Quality of Service (QoS) toepassen voor het VoIP-verkeer.

Als de hulpVLAN wordt aangepast (bijvoorbeeld om de telefoon te dwingen een specifiek VLAN of een specifieke coderingsmethode te gebruiken), wordt deze informatie via CDP naar de telefoon verzonden.

Opmerking: Catalyst 2900 en 3500XL switches ondersteunen momenteel geen CDPv2.

Beveiligingsconfiguratie

Idealiter heeft de klant al een beveiligingsbeleid ingesteld om te helpen definiëren welke tools en technologieën van Cisco zijn gekwalificeerd.

Opmerking: Cisco IOS-softwareveiligheid wordt, in tegenstelling tot CatOS, in veel documenten behandeld, zoals Cisco ISP Essentials.

Basisbeveiligingsfuncties

Wachtwoorden

Wachtwoord op gebruikersniveau configureren (aanmelding). Wachtwoorden zijn hoofdlettergevoelig in CatOS 5.x en hoger, en kunnen van 0 tot 30 tekens lang zijn, inclusief spaties. Stel het wachtwoord voor het inschakelen in:

set password password
set enablepass password

Alle wachtwoorden moeten voldoen aan de minimum lengtenormen (bijvoorbeeld minimaal zes tekens, een combinatie van letters en cijfers, hoofdletters en kleine letters) om te kunnen inloggen en om wachtwoorden in te schakelen wanneer deze worden gebruikt. Deze wachtwoorden worden versleuteld met het MD5-hashingalgoritme.

Cisco raadt het gebruik van een TACACS+ server aan om meer flexibiliteit toe te staan bij het beheer van wachtwoordbeveiliging en apparaattoegang. Raadpleeg het gedeelte TACACS+ van dit document voor meer informatie.

Secure Shell-beveiliging

Gebruik SSH-encryptie om beveiliging te bieden voor Telnet-sessies en andere externe verbindingen met de switch. SSH-codering wordt alleen ondersteund voor externe aanmeldingsgegevens bij de switch. U kunt Telnet-sessies die vanaf de switch worden gestart niet versleutelen. SSH versie 1 wordt ondersteund in CatOS 6.1 en versie 2 ondersteuning is toegevoegd in CatOS 8.3. SSH versie 1 ondersteunt de Data Encryption Standard (DES) en Triple-DES (3-DES) coderingsmethoden en SSH versie 2 ondersteunt de 3-DES en Advanced Encryption Standard (AES) coderingsmethoden. U kunt SSH-versleuteling gebruiken met RADIUS- en TACACS+-verificatie. Deze optie wordt ondersteund met SSH (k9)-afbeeldingen. Raadpleeg Hoe u SSH kunt configureren op Catalyst Switches met CatOS voor meer informatie.

set crypto key rsa 1024

Om versie 1 fallback uit te schakelen en versie 2-verbindingen te accepteren, geeft u deze opdracht uit:

set ssh mode v2

IP-toegangsfilters

Dit zijn filters om toegang tot de management sc0 interface te beschermen via Telnet en andere protocollen. Deze zijn bijzonder belangrijk wanneer VLAN dat voor beheer wordt gebruikt ook gebruikers bevat. Geef deze opdrachten uit om IP-adres en poortfiltering mogelijk te maken:

set ip permit enable
set ip permit IP address mask Telnet|ssh|snmp|all

Als echter de Telnet-toegang met deze opdracht beperkt is, kan toegang tot CatOS-apparaten alleen worden bereikt via een paar vertrouwde eindstations. Deze instelling kan een hinderpaal zijn voor het oplossen van problemen. Houd in gedachten dat het mogelijk is om IP-adressen te parodiëren en gefilterde toegang te bedriegen, dus dit is slechts de eerste beschermingslaag.

Poortbeveiliging

Overweeg het gebruik van poortbeveiliging om slechts één of meerdere bekende MAC-adressen toe te staan om gegevens over een bepaalde poort door te geven (bijvoorbeeld om te voorkomen dat statische eindstations worden geruild voor nieuwe stations zonder wijzigingscontrole). Dit is mogelijk door met statische MAC-adressen.

set port security mod/port enable MAC address

Dit is ook mogelijk door het leren van beperkte MAC-adressen dynamisch.

set port security port range enable 

Deze opties kunnen worden geconfigureerd:

• de vastgestelde de tijdwaarde van de havenveiligheid mod/van de haventijd-specificeert de duur waarvoor de adressen op de haven worden beveiligd alvorens een nieuw adres kan worden geleerd. Geldige tijd in minuten is 10 - 1440. Standaard is veroudering niet toegestaan.

• de vastgestelde waarde van de poortbeveiliging mod/port maximum-sleutelwoord dat het maximumaantal te beveiligen MAC-adressen op de poort specificeert. De geldige waarden zijn 1 (standaard) - 1025.

• de vastgestelde wijze van de havenveiligheid/de onderbreking van de havenschending —sluit haven (gebrek) af als de schending voorkomt evenals syslog bericht (gebrek) verzendt en het verkeer verwerpt.

• de vastgestelde de tijdwaarde van de havenveiligheid mod/van de havensluiting—duur waarvoor een haven gehandicapt blijft. Geldige waarden zijn 10 - 1440 minuten. Standaard wordt de machine permanent uitgeschakeld

Met CatOS 6.x en hoger heeft Cisco 802.1x-verificatie geïntroduceerd waarmee clients zich op een centrale server kunnen verifiëren voordat poorten voor gegevens kunnen worden ingeschakeld. Deze functie bevindt zich in de eerste stadia van ondersteuning op platforms zoals Windows XP, maar kan door veel bedrijven als een strategische richting worden beschouwd. Raadpleeg Poortbeveiliging configureren voor informatie over het configureren van poortbeveiliging op switches waarop Cisco IOS-software wordt uitgevoerd.

Inlogbanners

Maak passende apparaatbanners om specifiek de acties te vermelden die zijn ondernomen voor onbevoegde toegang. adverteer geen sitenaam of netwerkgegevens die informatie kunnen leveren aan onbevoegde gebruikers. Deze banners bieden hulp in geval een apparaat wordt gecompromitteerd en de dader wordt gepakt:.

# set banner motd ^C
*** Unauthorized Access Prohibited ***
***  All transactions are logged   ***
------------- Notice Board -------------
----Contact Joe Cisco at 1 800 go cisco for access problems----
^C

Fysieke security

Apparaten mogen zonder de juiste toestemming niet fysiek toegankelijk zijn, dus de apparatuur moet zich in een gecontroleerde (vergrendelde) ruimte bevinden. om ervoor te zorgen dat het netwerk operationeel blijft en niet wordt aangetast door kwaadwillige manipulatie van omgevingsfactoren, moet alle apparatuur een juiste UPS (met redundante bronnen waar mogelijk) en temperatuurregeling (airco) hebben. Vergeet niet dat als fysieke toegang wordt geschonden door een persoon met kwaadwillige bedoeling, verstoring door wachtwoordherstel of andere methoden veel waarschijnlijker is.

Terminal Access Controller-toegangscontrolesysteem

Standaard zijn niet-geprivilegieerde en geprivilegieerde wachtwoorden wereldwijd van toepassing op elke gebruiker die toegang heeft tot de switch of router, via de consolepoort of via een Telnet-sessie over het netwerk. Hun implementatie op netwerkapparaten is tijdrovend en niet gecentraliseerd. Het is ook moeilijk om toegangsbeperkingen te implementeren met behulp van toegangslijsten die gevoelig kunnen zijn voor configuratiefouten.

Er zijn drie beveiligingssystemen beschikbaar om de toegang tot netwerkapparaten te controleren en te bewaken. Deze maken gebruik van client-/serverarchitecturen om alle beveiligingsinformatie in één centrale database te plaatsen. Deze drie beveiligingssystemen zijn:

• TACACS +

• RADIUS

• Kerberos

TACACS+ is een veelgebruikte implementatie in Cisco-netwerken en is de focus van dit hoofdstuk. Het biedt de volgende functies:

• Verificatie: het identificatie- en verificatieproces voor een gebruiker. Er kunnen verschillende methoden worden gebruikt voor het verifiëren van een gebruiker, maar de meest gebruikelijke methode is een combinatie van een gebruikersnaam en wachtwoord.

• Toestemming voor verschillende opdrachten kan worden verleend zodra een gebruiker is geverifieerd.

• De accounting—de opname wat een gebruiker doet of heeft gedaan op het apparaat.

Raadpleeg TACACS+, RADIUS en Kerberos configureren op Cisco Catalyst-Switches voor meer informatie.

Operationeel overzicht

Het TACACS+ protocol verstuurt gebruikersnamen en wachtwoorden naar de gecentraliseerde server, versleuteld over het netwerk met MD5 one-way hashing (RFC 1321). Het gebruikt TCP-poort 49 als zijn transportprotocol; dit biedt deze voordelen ten opzichte van UDP (gebruikt door RADIUS):

• Verbindingsgericht vervoer

• Afzonderlijke bevestiging dat een verzoek is ontvangen (TCP-ACK), ongeacht hoe het back-end-verificatiemechanisme momenteel wordt geladen

• Onmiddellijke indicatie van een servercrash (RST-pakketten)

Tijdens een sessie, als extra autorisatiecontrole nodig is, controleert de switch met TACACS+ om te bepalen of de gebruiker toestemming heeft om een bepaalde opdracht te gebruiken. Dit biedt een grotere controle over de opdrachten die op de switch kunnen worden uitgevoerd tijdens het ontkoppelen van het verificatiemechanisme. Met behulp van commando accounting is het mogelijk om de opdrachten te controleren die een bepaalde gebruiker heeft uitgegeven terwijl deze gekoppeld zijn aan een bepaald netwerkapparaat.

Wanneer een gebruiker een eenvoudige ASCII-aanmelding probeert te verifiëren op een netwerkapparaat met TACACS+, gebeurt dit proces meestal:

• Wanneer de verbinding tot stand is gebracht, neemt de switch contact op met de TACACS+ daemon om een gebruikersnaam te vragen, die vervolgens wordt weergegeven aan de gebruiker. De gebruiker voert een gebruikersnaam in en de switch neemt contact op met de TACACS+ daemon om een wachtwoordprompt te verkrijgen. De switch geeft de wachtwoordmelding weer aan de gebruiker, die vervolgens een wachtwoord invoert dat ook naar de TACACS+ daemon wordt verzonden.

• Het netwerkapparaat ontvangt uiteindelijk een van deze reacties van de TACACS+ daemon:

  • ACCEPTEREN—de gebruiker is geverifieerd en de service kan starten. Als het netwerkapparaat is geconfigureerd voor vereiste autorisatie, wordt op dit moment met de autorisatie begonnen.

  • AFWIJZEN—de gebruiker heeft geen verificatie uitgevoerd. De gebruiker kan verdere toegang worden ontzegd of wordt gevraagd om de loginvolgorde opnieuw te proberen afhankelijk van de TACACS+ daemon.

  • FOUT - Er is een fout opgetreden tijdens de verificatie. Dit kan zowel bij daemon als in de netwerkverbinding tussen daemon en switch zijn. Als een ERROR-reactie wordt ontvangen, probeert het netwerkapparaat doorgaans een andere methode te gebruiken om de gebruiker te verifiëren.

  • DOORGAAN—De gebruiker wordt gevraagd om aanvullende verificatie-informatie.

• Gebruikers moeten eerst succesvol TACACS+ verificatie voltooien voordat ze overgaan naar TACACS+ autorisatie.

• Als een TACACS+-autorisatie vereist is, wordt opnieuw contact opgenomen met de TACACS+-daemon en wordt een acceptatie of AFwijzing van de autorisatiereactie teruggestuurd. Als een Accepteer antwoord wordt teruggestuurd, bevat het antwoord gegevens in de vorm van kenmerken die worden gebruikt om de EXEC- of NETWORK-sessie voor die gebruiker te sturen en te bepalen tot welke opdrachten de gebruiker toegang kan krijgen.

Aanbeveling

Cisco raadt het gebruik van TACACS+ aan, omdat dit eenvoudig kan worden geïmplementeerd met Cisco Secure ACS voor NT, Unix of andere software van derden. De functies van TACACS+ omvatten gedetailleerde accounting om statistieken te leveren over opdrachtgebruik en systeemgebruik, MD5-encryptie-algoritme en administratieve controle van verificatie- en autorisatieprocessen.

In dit voorbeeld, login en laat wijzen toe gebruiken de server TACACS+ voor Verificatie en kan terug naar lokale authentificatie vallen als de server niet beschikbaar is. Dit is een belangrijke achterdeur om in de meeste netwerken weg te gaan. Geef deze opdrachten uit om TACACS+ in te stellen:

set tacacs server server IP primary
set tacacs server server IP


!--- Redundant servers are possible.

set tacacs attempts 3

!--- This is the default.

set tacacs key key


!--- MD5 encryption key.

set tacacs timeout 15

!--- Longer server timeout (5 is default).

set authentication login tacacs enable
set authentication enable tacacs enable
set authentication login local enable
set authentication enable local enable

!--- The last two commands are the default; they allow fallback !--- to local if no TACACS+ server available.

Overige opties

Het is mogelijk om TACACS+ autorisatie te gebruiken om de opdrachten te beheren die elke gebruiker of gebruikersgroep kan uitvoeren op de switch, maar het is moeilijk om een aanbeveling te doen omdat alle klanten individuele eisen hebben op dit gebied. Raadpleeg Toegang tot de Switch controleren met behulp van verificatie, autorisatie en accounting voor meer informatie.

Tot slot verstrekken de boekhoudingsbevelen een controlespoor van wat elke gebruiker typte en gevormd. Dit is een voorbeeld van de gebruikelijke praktijk om de auditinformatie aan het eind van het commando te ontvangen:

set accounting connect enable start-stop tacacs+
set accounting exec enable start-stop tacacs+
set accounting system enable start-stop tacacs+
set accounting commands enable all start-stop tacacs+
set accounting update periodic 1

Deze configuratie heeft de volgende functies:

• Met de connect-opdracht kunt u accounting voor uitgaande verbindingsgebeurtenissen op de switch, zoals Telnet, inschakelen.

• De exec-opdracht maakt het mogelijk om logsessies op de switch te registreren, zoals de verrichtingspersoneel.

• De systeemopdracht maakt het mogelijk om systeemgebeurtenissen op de switch te registreren, zoals opnieuw laden of opnieuw instellen.

• De commando 'commando' maakt accounting van wat er op de switch was ingevoerd mogelijk, voor zowel show- als configuratieopdrachten.

• Periodieke updates elke minuut op de server zijn nuttig om te registreren of gebruikers nog steeds ingelogd zijn.

Configuratiechecklist

Deze sectie geeft een samenvatting van de aanbevolen configuraties, exclusief beveiligingsdetails.

Het is zeer nuttig om alle poorten te labelen. Geef deze opdracht uit om de poorten te labelen:

set port description descriptive name

Gebruik deze toets in combinatie met de Opdrachttabellen:

Opdrachten voor wereldwijde configuratie

Configuratieopdrachten voor hostpoorten

Opdrachten voor serverconfiguratie

Configuratieopdrachten voor ongebruikte poorten

Infrastructuurpoorten (switch-switch, switch-router)

Gerelateerde informatie

• Veelvoorkomende CatOS-foutmeldingen bij Catalyst 4500/4000 Series switches
• Veelvoorkomende CatOS-foutmeldingen bij Catalyst 5000/5500 Series switches
• Veelvoorkomende CatOS-foutmeldingen bij Catalyst 6500/6000 Series switches
• Productondersteuning voor switches
• Ondersteuning voor LAN-switching technologie
• Technische ondersteuning en documentatie – Cisco Systems