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 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.
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 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.
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 |
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.
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.
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:
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 |
|
Host is uitgeschakeld |
|
Overbrugging pad is verbroken |
|
Misgeconfigureerde bridging-filters |
|
I- en uitvoerwachtrijen volledig | Extreem multicast of uitzendverkeer kan input- en uitvoerwachtrijen veroorzaken om te overlopen, wat resulteert in geworpen pakketten.
|
[1]MAC = Media Access Control
[2] LSAP = access point voor linkservices
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 |
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 |
|
Hellos niet uitgewisseld |
|
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 |
|
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." |
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 |
|
FOUT-algoritme van Spanning Tree |
Opmerking: Het DEC en IEEE die boom algoritmen overspannen zijn niet compatibel. |
Meervoudige overbruggingsdomeinen onjuist ingesteld |
|
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.
|
[1]IEEE = Instituut voor Elektrische en elektronische ingenieurs
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
Boeken:
Interconnecties, bruggen en routers, Radia Perlman, Addison-Wesley
Cisco LAN Switching, K.Clark, K.Hamilton, Cisco Press