Problemen oplossen bij transparante overbruggingsomgevingen

Doelstellingen

Transparante bruggen werden eerst ontwikkeld bij Digital Equipment Corporation (DEC) in de vroege jaren 1980 en zijn nu zeer populair in Ethernet/IEEE 802.3-netwerken.

• Dit hoofdstuk definieert eerst een transparante brug als een leerbrug die het overspannen van boomprotocol implementeert. Een diepgaande beschrijving van het omspant-boomprotocol is inbegrepen.

• Cisco-apparaten die transparante bruggen implementeren, die eerst in twee categorieën worden gesplitst: routers die software van Cisco IOS^® en het Catalyst-bereik van switches uitvoeren die specifieke software uitvoeren. Dit is niet langer het geval. Meerdere Catalyst-producten zijn nu gebaseerd op de IOS. Dit hoofdstuk introduceert de verschillende overbruggtechnieken die op IOS-apparaten beschikbaar zijn. Raadpleeg het hoofdstuk LAN-switching voor Catalyst-softwarespecifieke configuratie en probleemoplossing.

• Tenslotte introduceren we bepaalde procedures voor het opsporen en verhelpen van problemen die worden geclassificeerd door de symptomen van mogelijke problemen die doorgaans optreden in transparante overbruggingsnetwerken.

Transparante overbruggingstechnologie-basis

Transparante bruggen leiden hun naam af van het feit dat hun aanwezigheid en werking transparant zijn voor netwerkhosts. Wanneer transparante bruggen worden aangedreven, leren zij de topologie van het netwerk door analyse van het bronadres van inkomende frames van alle in bijlage netwerken. Als een brug bijvoorbeeld een kader op lijn 1 van Host A ziet aankomen, concludeert de brug dat Host A kan worden bereikt via het op lijn 1 aangesloten netwerk. Via dit proces bouwen transparante bruggen een interne overbruggingstabel zoals die in Tabel 20-1.

Tabel 20-1: Een doorzichtige overbruggingstabel

Host-adres	Netwerknummer
0000.0000.0001	1
0000.b07e.ee0e	7
?	-
0050.50e1.9b80	4
0060.b0d9.2e3d	2
0000.0c8c.7088	1
?	-

De brug gebruikt zijn overbruggingstabel als basis voor het vervoer. Wanneer een kader op één van de bridge interfaces wordt ontvangen, kijkt de brug het doeladres van het kader in zijn interne tabel op. Als de tabel in kaart wordt gebracht tussen het doeladres en een van de poorten van de brug (behalve de tabel waarop het frame werd ontvangen), wordt het frame naar de gespecificeerde poort verzonden. Als geen kaart wordt gevonden, wordt het kader overstroomd naar alle uitgaande poorten. Ook uitzendingen en multicast worden op deze manier overspoeld.

Transparante bruggen isoleren succesvol het intra-segment verkeer en verminderen het verkeer dat op elk afzonderlijk segment wordt gezien. Dit verbetert meestal de responstijden van het netwerk. De mate waarin het verkeer wordt gereduceerd en de responstijden worden verbeterd, hangt af van het volume van het intersegmentverkeer (in verhouding tot het totale verkeer), alsook van het volume van het uitzending- en multicastverkeer.

Overbrugging

Zonder een bridge-to-bridge protocol faalt het transparante bridge-algoritme wanneer er meerdere paden van bruggen en lokale LAN’s (Area Networks) zijn tussen twee LAN’s in het internetwerk. Afbeelding 20-1 illustreert een dergelijke overbruggingslus.

Afbeelding 20-1: Onnauwkeurig doorsturen en leren in transparante overbruggingsomgevingen

Stel dat Host A een frame naar Host B verstuurt. Beide bruggen ontvangen het kader en concluderen correct dat Host A op Netwerk 2 is. Helaas, nadat Host B twee exemplaren van het kader van Host A ontvangt, ontvangen beide bruggen het kader op hun Netwerk 1 interfaces opnieuw, omdat alle hosts alle berichten op uitzending LANs ontvangen. In sommige gevallen zullen de bruggen dan hun interne tabellen wijzigen om aan te geven dat Host A op Network 1 is. Als dat het geval is, wanneer Host B op het frame van Host A antwoordt, ontvangen zowel de bruggen de antwoorden, omdat hun tabellen aangeven dat de bestemming (Host A) zich op hetzelfde netwerksegment bevindt als de bron van het kader.

Naast basisconnectiviteitsproblemen, zoals het beschreven, vormt de verspreiding van uitgezonden berichten op netwerken met netwerken een potentieel ernstig netwerkprobleem. Verwijs naar figuur 20-1, neem aan dat het eerste kader van Host A een uitzending is. Beide bruggen voorwaarts de frames eindeloos, gebruiken alle beschikbare netwerkbandbreedte en blokkeren de transmissie van andere pakketten op beide segmenten.

Een topologie met lijnen zoals die in Afbeelding 20-1 wordt getoond kan nuttig, zowel als potentieel schadelijk zijn. Een lus impliceert het bestaan van meerdere paden door het internetwork. Een netwerk met meerdere paden van bron tot bestemming heeft wat wordt genoemd verbeterde topologische flexibiliteit die de globale tolerantie van de netwerkfout vergroot.

Het Spanning Tree Algoritme

Het omspannen van een boomalgoritme (STA) werd ontwikkeld door DEC, een zeer belangrijke Ethernet verkoper, om de voordelen van loops te bewaren en hun problemen te elimineren. Het DEC-algoritme werd vervolgens herzien door het comité IEEE 802 en gepubliceerd in de specificatie IEEE 802.1d. Het DEC-algoritme en het IEEE 802.1d-algoritme zijn niet hetzelfde en zijn ze ook niet compatibel.

STA wijst een lus-vrije subset van de topologie van het netwerk aan door de plaatsing van die bridge poorten, zodat, als actief, het loops in een standby (blokkerend) voorwaarde kan creëren. Brug poort blokkeren kan in geval van primaire verbindingsmislukking worden geactiveerd, wat een nieuw pad door het internetwerk verstrekt.

De STA gebruikt een conclusie uit de graaftheorie als basis voor de bouw van een lus-vrij subset van de topologie van het netwerk. Grafische theorie stelt: "Voor elke aangesloten grafiek die uit knooppunten en randen bestaat die paar knopen verbinden, is er een omspannende boom van randen die de connectiviteit van de grafiek handhaaft maar geen lijnen bevat."

Afbeelding 20-2 illustreert hoe STA lusjes elimineert. De STA roept op elke brug een unieke identificator toe te wijzen. Meestal is deze identificator een van de MAC-adressen (Media Access Control) van de brug plus een prioriteitsindicatie. Elke poort in elke brug wordt ook een uniek (binnen die brug) herkenningsteken toegewezen (typisch, zijn eigen MAC adres). Tenslotte wordt elke bridge poort gekoppeld aan padkosten. De padkosten vertegenwoordigen de kosten van de overdracht van een kader op een LAN door die poort. In afbeelding 20-2 worden de padkosten genoteerd op de lijnen die vanaf elke brug ontstaan. Padkosten zijn gewoonlijk standaardwaarden maar ze kunnen handmatig door netwerkbeheerders worden toegewezen.

Afbeelding 20-2: Transparent Bridge Network (vóór STA)

De eerste activiteit in een omspannende boomberekening is de selectie van de root-brug, de brug met de laagste bridge identifier waarde. In Afbeelding 20-2, is de root-brug Bridge 1. Daarna wordt de wortelpoort op alle andere bruggen bepaald. Een basispoort van een brug is de haven waardoor de root-brug kan worden bereikt met de minste totale wegkosten. De waarde van de minst geaggregeerde padkosten naar de wortel wordt de kosten van het wortelpad genoemd.

Tenslotte worden de aangewezen bruggen en de aangewezen havens bepaald. Een aangewezen brug is de brug op elk LAN die de minimum kosten van de wortelweg verstrekt. Een aangewezen brug van een LAN is de enige brug die kaders naar en van LAN mag sturen waarvoor het de aangewezen brug is. Een aangewezen poort van een LAN is de poort die deze aansluit op de aangewezen brug.

In sommige gevallen kunnen twee of meer bruggen dezelfde basispadkosten hebben. In afbeelding 20-2 kunnen bruggen 4 en 5 in beide gevallen Bridge 1 (de root-brug) bereiken met een padkosten van 10. In dit geval worden de brugidentificatoren opnieuw gebruikt, ditmaal, om de aangewezen bruggen te bepalen. De LAN V poort van Bridge 4 is geselecteerd via de LAN V-poort van Bridge 5.

Hierdoor worden alle op elk LAN aangesloten bruggen, op één na, geëlimineerd, wat alle twee-LAN netwerken verwijdert. STA heft ook lijnen op die meer dan twee LAN’s omvatten, maar toch behoudt u de connectiviteit. Afbeelding 20-3 toont de resultaten van de toepassing van STA op het netwerk dat in Afbeelding 20-2 wordt getoond. Afbeelding 20-2 toont de boomtopologie duidelijker. Een vergelijking van dit getal met afbeelding 20-3 toont aan dat STA de poorten naar LAN V in zowel Bridge 3 als Bridge 5 in de stand-by modus heeft geplaatst.

Afbeelding 20-3: Transparent Bridge Network (na STA)

Het overspannen van een boom berekening komt voor wanneer de brug omhoog wordt aangedreven en wanneer een topologie verandering wordt ontdekt. De berekening vereist communicatie tussen het omspannen van boombruggen, die door configuratieberichten (soms de eenheden van de Gegevens van het bridge protocol of BPDU's) wordt bereikt. De configuratieberichten bevatten informatie die de brug identificeert die verondersteld wordt de wortel te zijn (root identifier) en de afstand vanaf de verzendende brug naar de root-brug (root path path-kosten). De configuratieberichten bevatten ook de brug- en poortidentificatie van de verzendende brug en de pagina van de informatie in het configuratiebericht.

Bruggen wisselen configuratieberichten uit met regelmatige tussenpozen (gewoonlijk één tot vier seconden). Als een brug faalt (wat een topologie verandering veroorzaakt), ontdekken de dichtbij bruggen spoedig het gebrek aan configuratieberichten en openen een omoverspanend boontrekalculatie.

Alle transparante besluiten over de topologie van de brug worden lokaal genomen. Configuratie-berichten worden uitgewisseld tussen bruggen in de buurt. Er is geen centrale autoriteit op het gebied van de topologie of het beheer van netwerken.

Frame Relay-indeling

Transparante bruggen ruilen configuratieberichten en de topologie-verandering uit. De berichten van de configuratie worden tussen bruggen verzonden om een netwerktopologie te creëren. De berichten van de verandering van de topologie worden verzonden nadat een topologie is ontdekt om erop te wijzen dat STA moet worden herhaald.

Tabel 20-2 toont het formaten van het IEEE 802.1d-configuratiebericht.

Tabel 20-2: Configuratie van transparante brug

Protocolidentificatie	Versie	Berichttype	Vlaggen	Root-id	Root path-kosten	Bridge-id	Poortid	Berichtenpagina	Maximale leeftijd	Hallo tijd	Verschuiving
2 bytes	1 bytes	1 bytes	1 bytes	8 bytes	4 bytes	8 bytes	2 bytes	2 bytes	2 bytes	2 bytes	2 bytes

Berichtenvelden

Transparent bridge configuratieberichten zijn uit 35 bytes. Dit zijn de berichtvelden:

• Identificatiecode protocol: Bevat waarde 0.

• Versie: Bevat waarde 0.

• Berichttype: Bevat waarde 0.

• Vlag: Een veld van één bytes, waarvan alleen de eerste twee bits worden gebruikt. Het (TC) bit van de topologie verandert. Het bit van de topologie change Recognition (TCA) wordt ingesteld om de ontvangst van een configuratiebericht met het TC-bit set te bevestigen.

• wortel-ID: Identificeert de root-brug en maakt een lijst van zijn 2-byte-prioriteit gevolgd door zijn 6-byte-ID.

• Kosten wortelpad: Bevat de kosten van het pad van de brug die het configuratiebericht naar de root-brug stuurt.

• Bridge-ID: Identificeert de prioriteit en ID van de brug die de boodschap verstuurt.

• Port-ID: Identificeert de haven waarvan het configuratiebericht werd verzonden. Dit veld maakt het mogelijk dat door meerdere aangesloten bruggen gemaakte loops worden gedetecteerd en aangepakt.

• Berichtenpagina: Specificeert de verlopen tijd sinds de wortel het configuratiebericht verzonden heeft waarop het huidige configuratiebericht gebaseerd is.

• Maximumleeftijd: Geeft aan wanneer het huidige configuratiebericht moet worden verwijderd.

• Hallo tijd: Hier vindt u de tijdsduur tussen de configuratieberichten in de root-brug.

• Verdere vertraging: Verstrekt de hoeveelheid tijdbruggen moeten wachten vóór een overgang naar een nieuwe staat na een topologie verandering. Als een brug te vroeg overgaat, kunnen niet alle netwerkverbindingen klaar zijn om hun staat te veranderen, en de lijnen kunnen resulteren.

Het bericht van de topologie-verandering formaat is vergelijkbaar met dat van het transparante bridge configuratiebericht, behalve dat het slechts uit de eerste vier bytes bestaat. Dit zijn de berichtvelden:

• Identificatiecode protocol: Bevat waarde 0.

• Versie: Bevat waarde 0.

• Berichttype: Bevat waarde 128.

Verschillende IOS-overbruggingstechnieken

Cisco-routers hebben drie verschillende manieren om overbrugging te implementeren: Standaard gedrag, gelijktijdige routing en bridging (CRB) en geïntegreerde routing en bridging (IRB).

Standaardgedrag

Voordat IRB en CRB functies beschikbaar waren, kon u een protocol alleen op basis van platform overbruggen of routeren. Dat wil zeggen, als de ip route opdracht werd gebruikt, bijvoorbeeld, werd IP routing op alle interfaces uitgevoerd. In deze situatie kon IP niet op een van de interfaces van de router worden voltooid.

Gelijktijdige routing en bridging (CRB)

Met CRB kunt u bepalen of u een protocol op een interfacebasis wilt overbruggen of routeren. Dat wil zeggen, u kunt een bepaald protocol op sommige interfaces leiden en hetzelfde protocol op bridge-group interfaces binnen dezelfde router overbruggen. De router kan dan zowel een router als een brug voor een bepaald protocol zijn, maar er kan geen elk soort communicatie tussen routing-bepaalde interfaces en bridge-groepsinterfaces zijn.

Dit voorbeeld illustreert dat, voor een bepaald protocol, één enkele router logisch als afzonderlijke, onafhankelijke apparaten kan handelen: één router en een of meer bruggen:

Afbeelding 20-4: Gelijktijdige routing en bridging (CRB)

Geïntegreerde routing en bridging (IRB)

IRB biedt de mogelijkheid om tussen een bridge-groep en een routed interface te leiden met een concept dat Bridge-Group Virtual Interface (BVI) wordt genoemd. Omdat het overbruggen op de datalink-laag en het routeren op de netwerklaag plaatsvindt, hebben zij verschillende protocol configuratiemodellen. Met IP bijvoorbeeld behoren bridge-group interfaces tot hetzelfde netwerk en hebben ze een collectief IP-netwerkadres, terwijl elke routeinterface een duidelijk netwerk met een eigen IP-netwerkadres vertegenwoordigt.

Het concept van BVI is gemaakt om deze interfaces in staat te stellen pakketten in te wisselen voor een bepaald protocol. Geconceptueel, zoals in dit voorbeeld, ziet de router van Cisco eruit als een router die met één of meer bridge-groepen wordt verbonden:

Afbeelding 20-5: Geïntegreerde routing en bridging (IRB)

BVI is een virtuele interface binnen de router die als een normale routeinterface werkt. De BVI vertegenwoordigt de correspondent bridge-groep om te routeren interfaces binnen de router. Het interfacenummer van de BVI is het nummer van de bridge-groep die door deze virtuele interface wordt weergegeven. Het nummer is de link tussen deze BVI en de bridge-groep.

Dit voorbeeld illustreert hoe het BVI-beginsel van toepassing is op de Switch van de route (RSM) in een Catalyst switch:

Afbeelding 20-6: Route Switch Module (RSM) in een Catalyst Switch.

Transparante overbrugging voor probleemoplossing

In deze sectie worden informatie over probleemoplossing gepresenteerd voor problemen met connectiviteit in transparante overbruggingsnetwerken. Het beschrijft specifieke transparante overbruggingssymptomen, de problemen die waarschijnlijk elk symptoom veroorzaken en de oplossingen voor deze problemen.

Opmerking: Problemen gerelateerd aan Source-Route Bridging (SRB), vertaalbridging en Source-Route Transparent (SRT)-overbrugging worden behandeld in Hoofdstuk 10, "Problemen oplossen IBM."

Om uw netwerk efficiënt op te lossen moet u een basiskennis van zijn ontwerp hebben, vooral wanneer een omspanende boom in het geding is.

Deze moeten beschikbaar zijn:

• Topologische kaart van het overbrugde netwerk

• Plaats van de root-brug

• Plaats van de redundante link (en geblokkeerde poorten)

Wanneer u problemen hebt met de connectiviteit van de probleemoplossing, beperkt u het probleem tot een minimum aantal hosts, idealiter alleen een client en een server.

Deze secties beschrijven de meest voorkomende netwerkproblemen in transparante overbrugde netwerken:

• Transparante overbrugging: Geen connectiviteit

• Transparante overbrugging: Onstabiele Spanning Tree

• Transparante overbrugging: Sessies verlopen onverwacht

• Transparante overbrugging: Stormen over laden en uitzenden

Transparante overbrugging: Geen connectiviteit

Symptoom: De client kan geen verbinding maken met hosts via een transparant netwerk.

Tabel 20-3 beschrijft de problemen die dit symptoom kunnen veroorzaken en stelt oplossingen voor.

Tabel 20-3: Transparante overbrugging: Geen connectiviteit

Mogelijke oorzaken	Aanbevolen acties
Problemen met hardware of media	Gebruik de opdracht Show bridge EXEC om te zien of er een aansluitingsprobleem is. Als dit zo is, zal de uitvoer geen MAC[1]-adressen in de overbruggingstabel tonen. Gebruik de opdracht EXEC van de showinterfaces om te bepalen of het interface- en lijnprotocol omhoog zijn. Als de interface is uitgevallen, kunt u de hardware of de media problemen oplossen. Raadpleeg Hoofdstuk 3, "Problemen oplossen en problemen met hardware en booting." Als het lijnprotocol is uitgevallen, controleer de fysieke verbinding tussen de interface en het netwerk. Zorg ervoor dat de verbinding veilig is en dat de kabels niet beschadigd zijn. Als het lijnprotocol is bijgewerkt maar de input en de uitvoerpakkettellers niet verhogen, controleer de media en de hostconnectiviteit. Raadpleeg het hoofdstuk Problemen oplossen bij media dat betrekking heeft op het mediatype dat in uw netwerk wordt gebruikt.
Host is uitgeschakeld	Gebruik het opdracht Show bridge EXEC op bruggen om ervoor te zorgen dat de overbruggingstabel de MAC-adressen van de aangesloten eindknooppunten bevat. De overbruggingstabel omvat de bron- en bestemmings-MAC-adressen van hosts en wordt bevolkt wanneer pakketten van een bron of bestemming door de brug worden verzonden. Als er verwachte eindknooppunten ontbreken, controleert u de status van de knooppunten om te controleren of ze aangesloten en correct geconfigureerd zijn. initialiseer of hervorm indien nodig de eindknooppunten en heronderzoek de overbruggingstabel met de opdracht showbridge.
Overbrugging pad is verbroken	Identificeer het pad dat pakketten tussen eindknooppunten moeten nemen. Als er een router op dit pad is, selecteert u de probleemoplossing in twee onderdelen: Knooppunt 1-router en routerknooppunt 2. Sluit aan op elke brug op het pad en controleer de status van de poorten die worden gebruikt op het pad tussen de eindknooppunten (zoals beschreven in de tabel "Hardware of mediaprobleem". Gebruik de opdracht Show bridge om ervoor te zorgen dat het MAC-adres van de knooppunten op de juiste poorten wordt geleerd. Als niet, kan er instabiliteit op uw overspits boomtopologie zijn. Zie tabel 20-2 "Transparante overbrugging: Onstabiele Spanning Tree." Controleer de status van de poorten met de opdracht show span. Als de poorten die verkeer tussen de eindknooppunten kunnen overbrengen niet in de staat van het verzenden zijn, kan de topologie van uw boom onverwachts zijn veranderd. Zie Tabel 20-4 "Transparante overbrugging onstabiele Spanning Tree".
Misgeconfigureerde bridging-filters	Gebruik het tonen in werking stellen-in werking stellen-enig bevoorrecht EXEC bevel om te bepalen of de bridge filters worden gevormd. Overbrugfilters op verdachte interfaces uitschakelen en bepalen of connectiviteit wordt hersteld. Als de connectiviteit niet wordt hersteld, is het filter niet het probleem. Als connectiviteit wordt hersteld nadat filters worden verwijderd, is één of meer slechte filters de oorzaak van het connectiviteitsprobleem. Als er meerdere filters bestaan of filters die toegangslijsten met meerdere verklaringen gebruiken bestaan, passen elk filter afzonderlijk toe om het probleemfilter te identificeren. Controleer de configuratie voor LSAP- en uitvoerindeling[2] en de TYPE-filters, die tegelijkertijd kunnen worden gebruikt om verschillende protocollen te blokkeren. LSAP (F0F0) kan bijvoorbeeld worden gebruikt om Netopgemerkt te blokkeren. TYPE (6004) kan worden gebruikt om het lokale gebiedstransport te blokkeren. Wijzig alle filters of toegangslijsten die verkeer blokkeren. Ga door met het testen van filters totdat alle filters ingeschakeld zijn en de verbindingen nog werken.
I- en uitvoerwachtrijen volledig	Extreem multicast of uitzendverkeer kan input- en uitvoerwachtrijen veroorzaken om te overlopen, wat resulteert in geworpen pakketten. Gebruik de opdracht Show interfaces om input- en uitvoerdruppels te zoeken. Druppels suggereren overdreven verkeer over de media. Als het huidige aantal pakketten op de invoerwachtrij consistent is met of meer dan 80% van de huidige omvang van de invoerwachtrij, moet de grootte van de invoerwachtrij worden aangepast om de pakketsnelheid aan te passen. Zelfs als het huidige aantal pakketten op de ingangsrij nooit de grootte van de ingangsrij lijkt te benaderen, kunnen bursten van pakketten de wachtrij nog overstromen. Verminder uitzending en multicast verkeer op verbonden netwerken met het gebruik van het verbinden van filters, of verdeel het netwerk met meer internetwork apparaten. Als de verbinding een seriële link is, verhoogt u de bandbreedte, past u prioriteitswachtrijen toe, vergroot u de wachtrijgrootte of wijzigt u de systeembuffergrootte. Zie voor meer informatie Hoofdstuk 15, "Problemen oplossen bij seriële lijnproblemen."

[1]MAC = Media Access Control

[2] LSAP = access point voor linkservices

Transparante overbrugging: Onstabiele Spanning Tree

Symptoom: Een voorbijgaand verlies aan connectiviteit tussen hosts. Verschillende hosts zijn getroffen.

Tabel 20-4 beschrijft de problemen die dit symptoom kunnen veroorzaken en stelt oplossingen voor.

Tabel 20-4: Transparante overbrugging: Onstabiele Spanning Tree

Mogelijke oorzaken	Aanbevolen acties
Link flaping	Gebruik show span bevel om te zien of het aantal topologieën gestaag stijgt. Als dit zo is, controleer het verband tussen uw bruggen met de opdracht tonen interface. Als deze opdracht geen koppeling tussen twee bruggen blootlegt, kunt u de bevoorrechte EXEC-opdracht van de debug spantree op uw bruggen gebruiken. Dit logt alle veranderingen in verband met het overspannen van de boom in. In een stabiele topologie kan er geen sprake zijn van. De enige links die naar sporen verwijzen zijn de bruggen die de bruggen met elkaar verbinden. Een overgang op een verbinding naar een eindstation zou geen impact moeten hebben op het netwerk. N.B.: Omdat de debug-uitvoer een hoge prioriteit in het CPU-proces krijgt toegewezen, kan het systeem onbruikbaar worden als u de opdracht spantree debug gebruikt. Om deze reden, gebruik de opdrachten debug alleen om specifieke problemen op te lossen of wanneer in sessies om problemen met de technische ondersteuning van Cisco op te lossen. Bovendien, is het best om debug opdrachten binnen periodes van laag netwerkverkeer en minder gebruikers te gebruiken. Als u binnen deze periodes debug houdt, vermindert het de waarschijnlijkheid dat de toegenomen overhead van het debug bevel het systeemgebruik zal beïnvloeden.
Root-brug blijft veranderen / meerdere bruggen beweren de wortel te zijn	Controleer de consistentie van de informatie van de root-brug over het overbrugde netwerk met de opdrachten van de show span op de verschillende bruggen. Als er meerdere bruggen zijn die de wortel zouden beweren, zorg er dan voor dat u het zelfde overspannende boomprotocol op elke brug (zie de "mismatch van het Spanning Tree algoritme" tabelingang in Tabel 20-6) gebruikt. Gebruik de opdracht bridge <group> prioriteit<number> op de root-brug om de gewenste brug te dwingen tot de wortel. Hoe lager de prioriteit, des te waarschijnlijker het is dat de brug de wortel zal vormen. Controleer de diameter van uw netwerk. Met een standaard omspant boom, mag er nooit meer dan zeven brugsprongen tussen twee hosts zijn.
Hellos niet uitgewisseld	Controleer of bruggen met elkaar communiceren. Gebruik een netwerkanalyzer voor het debug van spantree tree tree geprivilegieerde EXEC om te zien of het omspannen van boomhallo-frames wordt uitgewisseld. N.B.: Omdat de debug-uitvoer een hoge prioriteit in het CPU-proces krijgt toegewezen, kan het systeem onbruikbaar worden als u de opdracht spantree debug gebruikt. Om deze reden, gebruik de opdrachten debug alleen om specifieke problemen op te lossen of wanneer in sessies om problemen met de technische ondersteuning van Cisco op te lossen. Bovendien, is het best om debug opdrachten binnen periodes van laag netwerkverkeer en minder gebruikers te gebruiken. Als u binnen deze periodes debug houdt, vermindert het de waarschijnlijkheid dat de toegenomen overhead van het debug bevel het systeemgebruik zal beïnvloeden. Indien er geen hulpstukken uitgewisseld worden, controleer de fysieke verbindingen en de softwareconfiguratie op de bruggen.

Transparante overbrugging: Sessies verlopen onverwacht

Symptoom: Aansluitingen in een transparant geconvergeerde omgeving zijn succesvol ingesteld, maar sessies eindigen soms abrupt.

Tabel 20-5 beschrijft de problemen die dit symptoom kunnen veroorzaken en stelt oplossingen voor.

Tabel 20-5: Transparante overbrugging: Sessies verlopen onverwacht

Mogelijke oorzaken	Aanbevolen acties
Buitensporige teruggaven	Gebruik een netwerkanalyzer om host-terugzendingen te zoeken. Als u terugzendingen ziet op langzame serielijnen, verhoog u de transmissiettimers op de host. Raadpleeg de documentatie bij de verkoper voor informatie over de configuratie van de hosts. Zie Hoofdstuk 15, "Problemen oplossen bij seriële lijnproblemen" voor informatie over het oplossen van problemen. Als u terugzenders op snelle LAN-media ziet, controleert u op pakketten die op volgorde worden verzonden en ontvangen, of door een intermediair apparaat (zoals een brug of een switch) worden gedropt. Probleemoplossing voor de LAN-media naar wens. Raadpleeg voor meer informatie het hoofdstuk over het oplossen van problemen van media die het mediatype bestrijken dat in uw netwerk wordt gebruikt. Gebruik een netwerkanalyzer om te bepalen of het aantal terugzenders afneemt.
Excessieve vertraging via seriële link	Vergroot de bandbreedte, pas prioriteitswachtrij toe, vergroot de grootte van de houdwachtrij of wijzig de grootte van de systeembuffer. Zie voor meer informatie Hoofdstuk 15, "Problemen oplossen bij seriële lijnproblemen."

Transparante overbrugging: Stormen over laden en uitzenden

Symptoom: Packet looping en uitzending stormen komen in transparante bridge omgevingen voor. Eindstations worden overmatig uitgezonden, waardoor de sessies niet meer kunnen draaien of aflopen.

Opmerking: pakketlijnen worden normaal veroorzaakt door problemen met netwerkontwerp of hardwareproblemen.

Tabel 20-6 beschrijft de problemen die dit symptoom kunnen veroorzaken en stelt oplossingen voor.

Overbrugging is het slechtst denkbare scenario in een overbrugd netwerk, aangezien het potentieel van invloed is op elke gebruiker. In geval van nood, is de beste manier om connectiviteit snel terug te krijgen alle interfaces handmatig uit te schakelen die overtollig pad in het netwerk voorzien. Helaas zal de oorzaak van de overbruggingslus achteraf zeer moeilijk te identificeren zijn als je dat doet. Probeer indien mogelijk vooraf de acties in Tabel 20-6.

Tabel 20-6: Transparante overbrugging: Stormen over laden en uitzenden

Mogelijke oorzaken	Aanbevolen acties
Geen overspannen boom geïmplementeerd	Onderzoek een topologie kaart van uw internetwerk om op mogelijke loops te controleren. Vermijd eventuele loops die bestaan of zorg dat de juiste koppelingen zich in de back-upmodus bevinden. Als uitzendstormen en pakketlijnen blijven bestaan, gebruik de opdracht van de show interfaces EXEC om input en output pakkettellingen statistieken te verkrijgen. Als deze tellers tegen een abnormaal hoog tarief (met betrekking tot uw normale verkeersladingen) increment increment, is waarschijnlijk nog steeds aanwezig in het netwerk. Voer een overspannend boomalgoritme in om loops te voorkomen.
FOUT-algoritme van Spanning Tree	Gebruik het opdracht show span EXEC op elke brug om te bepalen welk omspanend boomalgoritme wordt gebruikt. Zorg ervoor dat alle bruggen het zelfde overspannende boomalgoritme (of DEC of IEEE)[1] in werking stellen. Het kan nodig zijn om zowel het DEC als het IEEE te gebruiken dat boomalgoritmen in het netwerk omspant voor sommige zeer specifieke configuraties (over het algemeen, die IRB betrekken). Als de mismatch in het omspant-boomprotocol niet is bedoeld, stel de bruggen dan zo nodig aan zodat alle bruggen hetzelfde omspant-boomalgoritme gebruiken. Opmerking: Het DEC en IEEE die boom algoritmen overspannen zijn niet compatibel.
Meervoudige overbruggingsdomeinen onjuist ingesteld	Gebruik het opdracht Show span EXEC op bruggen om ervoor te zorgen dat alle domeingroepgetallen voor bepaalde overbruggingsdomeinen overeenkomen. Als meerdere domeingroepen voor de brug zijn geconfigureerd, zorg er dan voor dat alle domeinspecificaties correct zijn toegewezen. Gebruik de opdracht bridge <group> globale configuratie om de gewenste wijzigingen aan te brengen. Zorg dat er geen loops tussen overbruggingsdomeinen bestaan. Een interdomain overbruggingsmilieu verstrekt luspreventie niet gebaseerd op het overspannen van boom. Elk domein heeft zijn eigen omspannende boom, die onafhankelijk is van het omspannen van boom in andere domeinen.
Link error (unidirectionele link), duplex-mismatch, hoog foutenniveau op een poort.	Lopen komen voor wanneer een haven die bewegingen naar de expediteur zou moeten blokkeren. Een haven moet BPDU's van een dichtbij brug ontvangen om in de blokkerende staat te blijven. Elke fout die tot verloren BPDU's leidt kan dan de oorzaak van een overbruggingslus zijn. Identificeer blokkerende havens van uw netwerkdiagram. Controleer de status van de poorten die in uw overbrugde netwerk met de show interface moeten blokkeren en toon EXEC opdrachten voor bridge EXEC. Als u een mogelijk geblokkeerde haven vindt die momenteel door:sturen of op het punt staat door te sturen (dat wil zeggen, in leer of luister staat) hebt u de echte bron van het probleem gevonden. Controleer of deze poort BPDU’s ontvangt. Als dit niet het geval is, is er waarschijnlijk een probleem op de link die naar deze poort is aangesloten. Controleer dan verbindingsfouten, duplexinstelling, enzovoort.) Als de poort nog BPDU's ontvangt, ga dan naar de brug die u verwacht voor dit LAN te worden aangewezen. Controleer vervolgens alle links op het pad naar de wortel. U zult een probleem op een van deze koppelingen vinden (op voorwaarde dat het oorspronkelijke netwerkdiagram juist was).

[1]IEEE = Instituut voor Elektrische en elektronische ingenieurs

Voordat u Cisco Systems TAC-team belt

Wanneer uw netwerk stabiel is, verzamel zoveel informatie als u over zijn topologie kunt.

Verzamel ten minste deze gegevens:

• Fysieke topologie van het netwerk

• Verwachte locatie van de root-brug (en back-up-root-brug)

• Plaats van geblokkeerde poorten

Aanvullende bronnen

Boeken:

• Interconnecties, bruggen en routers, Radia Perlman, Addison-Wesley

• Cisco LAN Switching, K.Clark, K.Hamilton, Cisco Press

Gerelateerde informatie

• Transparante overbruggingsdocumentatie
• Technische ondersteuning en documentatie – Cisco Systems