R33NET BLOG Rotating Header Image

cisco

Cisco ASDM Problem mit Windows 8 und Java

ciscoasdmIch hatte das Probleme den ASDM auf Windows 8 nicht starten zu können. Ich habe folgende Fehlermeldung erhalten „Could not find the main clasS: com.cisco.launcher.Launcher“. Das Problem hängt wohl mit der Java Version zusammen. Cisco weist darauf hin das es mit Java 64Bit und dem ASDM Probleme gibt. Mit der Java Version 7 update 45 habe ich den ASDM leider nicht zum laufen bekommen. Früher verwies der Pfad der ASDM Verknüpfung auf „C:\Windows\system32\javaw.exe“ ab einer bestimmten Java Version lautet der Pfad: C:\Windows\SysWOW64\javaw.exe. Das solltet Ihr als erstes prüfen und ggf den Pfad ändern. Als Workaround habe ich Java Version 6 update 45 installiert und habe den Pfad der ASDM Verknüpfung geändert auf das Java 6 Verzeichnis: „C:\Program Files (x86)\Java\jre6\bin\javaw.exe“ -Xms64m -Xmx512m -Dsun.swing.enableImprovedDragGesture=true -classpath lzma.jar;jploader.jar;asdm-launcher.jar;retroweaver-rt-2.0.jar com.cisco.launcher.Launcher

Cisco ASDM Troubleshooting

Cisco IOS Clock Sync (NTP) Sommer/Winter Uhrzeit

Als erstes braucht ihr einen NTP-Server. In meinem Beispiel habe ich meine Firewall genommen. Ihr könnt aber auch einen NTP Server aus dem Internet nehmen z.B. http://www.pool.ntp.org/de/

sw-dmz01(config)#ntp server 192.168.66.254

Das Cisco Gerät benötigt jetzt ein bisschen um den NTP Status zu synchronisieren. Als nächsten überprüfen wir den NTP Status

sw-dmz01#sh ntp statu
Clock is synchronized, stratum 4, reference is 192.168.66.254
nominal freq is 250.0000 Hz, actual freq is 249.9989 Hz, precision is 2**18
reference time is D610CB76.FEF1C771 (11:01:26.995 CET Tue Oct 22 2013)
clock offset is 23.3481 msec, root delay is 87.62 msec
root dispersion is 98.45 msec, peer dispersion is 0.66 msec

Jetzt haben wir die richtige Uhrzeit auf unserem Cisco Gerät. Als nächstes sollten wir die richtige Zeitzone einstellen. Folgend können wir uns Datum, Uhrzeit und die Zeitzone anzeigen lassen.

sw-dmz01#sh clock
12:21:50.010 CET Tue Oct 22 2013

In welcher Zeitzone ihr auch genau befindet könnt ihr über Google suchen für Deutschland gilt CET

Central European Time
Central European Standard Time = GMT+1 (CET)
Central European Summer Time = GMT+2 (CEST)

Am letzten Sonntag im März wird die Uhr von 02:00 auf 03:00 gestellt das ist dann die Sommerzeit(CEST) Die Sommerzeit endet am letzten Sonntag im Oktober, hier stellen wir die Uhr eine Stunde zurück von 03:00 auf 02:00 (CET)

sw-dmz01(config)#clock timezone ?
WORD name of time zone

sw-dmz01(config)#clock timezone CET ?
<-23 - 23> Hours offset from UTC

sw-dmz01(config)#clock timezone CET 2

So weit so gut, jetzt haben wir die Uhr synchronisiert und die richtige Zeitzone gesetzt. Jetzt müssen wir noch die Sommer und Winterzeit konfigurieren.

sw-dmz01(config)#clock summer-time CEST recurring last Sun Mar 02:00 last Sun Oct 03:00

Jetzt wollen wir noch das die Zeitzone in unseren Logs und Debugs angezeigt wird.

sw-dmz01(config)#service timestamps debug datetime msec localtime show-timezone
sw-dmz01(config)#service timestamps log datetime msec localtime show-timezone

Das Log sieht dann wie folgt aus:

Oct 22 13:37:00.590 CEST: ICMP: echo reply sent, src 192.168.66.121, dst 192.168.66.126
Oct 22 13:36:26.184 CEST: %SYS-5-CONFIG_I: Configured from console by vty0 (192.168.66.126)

Dateien im flash mit TCL bearbeiten/erstellen

Mal angenommen ihr habt einen Router und wollt eine neue startup-config erstellen/kopieren habt aber keine Möglichkeit das via TFTP oder so zu machen. Es gibt eine einfache Möglichkeit eine Datei im flash über die Kommandozeile [CLI] zu erstellen.  Das machen wir mit Tcl (Tool command language) eine Open Source-Skriptsprache.  In diesen Beispiel schreibe ich nur zwei Zeilen in eine Datei. Es kann aber auch eine komplette Konfiguration in die Datei geschrieben werden.

Als erstes öffnen wir tclsh:

Router#tclsh

Wir öffnen eine Datei mit den Namen „conf.txt“ Das W+ bedeutete überschreibe die Datei.

Router(tcl)#set x [open „flash:conf.txt“ w+]
file0

Gebt folgendes Kommando ein damit ihr in die Datei schreiben könnt Klammer“auf“

Router(tcl)#set lst {

Jetzt kopiert ihr den Inhalt den ihr in die Datei schreiben wollt

+>no access-list 101
+>access-list 101 per ip any host 10.0.0.1

Wenn ihr alles eingegeben habt schließt ihr das ganze mit der Klammer“zu“

+>}

Es wird nochmal alles Angezeit was in die Datei geschrieben wird

no access-list 101
access-list 101 per ip any host 10.0.0.1

Wir speichern und schließen die Datei

Router(tcl)#puts $x $lst
Router(tcl)#close $x

Wir beenden TCL

Router(tcl)#tclquit

Solltet ihr jetzt eine fertige Konfiguration in eine Datei geschrieben haben, könnt ihr das einfach mit „copy flash:conf.txt startup-config“ in die startup-config kopieren. Die vlan.dat nicht vergessen, also VLANs und VTP anlegen und durchstarten. Der Router/Switch läuft dann mit der neuen Konfiguration.

Weiter Informationen und Möglichkeiten mit TCL
Tcl (Tool command language)

Multicast / IGMP / IGMP Snooping

IGMP „Internet Group Message Protocol“ ist eine Erweiterung des Internet Protocols (IPv4). Mit IGMP ist IP-Multicasting (Gruppenkommunikation) möglich. IP-Multicasting ist die Verteilung von IP-Paketen mit einer Ziel-IP-Adresse an mehrere Stationen gleichzeitig. Das Gegenstück von IGMP von IPv4 ist bei IPv6 MLD (Multicast Listener Discovery).
Das Internet Group Message Protocol wird benutz um Hosts zu ermöglichen, die Teilnehmerliste für Multicast-Gruppentelegramme im Netz bekannt zu geben.
Router und Switches lernen beim Empfang von IGMP Membership Requests, welche der angeschlossenen Geräte zu einer Multicast-Gruppe gehören. Wird ein Multicast für eine Gruppe empfangen, wird die Nachricht nur an den entsprechenden Ports, die zu dieser Multicastgruppe gehören weitergeleitet, die anderen Ports sehen diese Nachrichten nicht.

Wenn keine Multicast-Filterung mit IGMP vorgenommen wird, werden die Multicast-Nachrichten auf allen Ports versendet. Dieses Multicast-Filtering ist umso wichtiger, je größer die Netzwerke sind. In großen Netzstrukturen mit kaskadierten Switches wird eine unnötig hohe Netzlast in der Domäne entstehen oder einige Geräte werden möglicherweise überfordert, wenn sie permanent auf Multicastverkehr reagieren müssen, der nicht für sie bestimmt ist.

Wird ein Gerät auf einen anderen Switchport gesteckt würde der Switch die Multicast-Nachrichten zum falschen Port senden und das Gerät würde keine Multicast-Nachrichten mehr erhalten. Um das zu verhindern, fordert beim IGMP Snooping (ein) zerntrales Gerät iterativ alle Endgeräte auf, ihre Multicast-Gruppenzugehörigkeit bekanntzugeben, der sogenannte IGMP Querier.  Die Antworten auf Querier-Anfragen (IGMP Reports) veranlassen die Switche ihre Membership-Listen entsprechen zu aktualisieren.

Es gibt 3 IGMP-Versionen:

Version 1 (RFC 1112) kannte nur zwei Nachrichtentypen: Host Membership Query und Host Membership Report. Der Router kann mit IGMPv1 periodisch alle Hosts fragen, welche Gruppen sie denn empfangen möchten, und Hosts können als Antwort oder spontan pro Gruppe einen Report abschicken.
Bei Version 1 kann ein Host eine Gruppe nicht verlassen, er kann nur warten, bis der Router das nächste Mal eine Anfrage stellt und dann keinen Report mehr abschicken.

Version 2 (RFC 2236) fügt eine Nachricht dazu, mit der man Groups verlassen kann, und spezifiziert eine Methode, wie mehr als ein Multicast-Router in einem Ethernet koexistieren können.
Dabei wird der Router mit der kleineren IP-Nummer als Querier ausgewählt, d.h. fortan wird nur noch dieser Host Reports anfordern. Der andere Router übernimmt wieder,
wenn der erste eine Anfrage nicht rechtzeitig gestellt hat (und damit ausgefallen zu sein scheint).

Version 3 erlaubt die Angabe von ACLs zur Sender-Auswahl. Ein Host kann beim Beitritt zu einer Gruppe erklären, daß er nur Traffic von einem bestimmten Sender empfangen möchte (oder einer Liste von Sendern), oder er kann Sender explizit ausschließen.

LINKS:

RFC 1112 – Host Extensions for IP Multicasting
RFC 2236 – Internet Group Management Protocol, Version 2
RFC 3376 – Internet Group Management Protocol, Version 3
RFC 2933 – Internet Group Management Protocol MIB

Wiki: Multicast

IPv4 Multicast Address Space Registry

Multicast-Routing-Protokolle
Distance Vector Multicast Routing Protocol (DVMRP)
Multicast Open Shortest Path First (MOSPF)
Protocol Independent Multicast (PIM)

Cisco IOS Software Packaging for Cisco Switches

Da wir ab sofot nurnoch die Catalys 3750-X Series nutzen wurde ich gefragbt welches IOS ich brauche.  IPBase, IPServices oder Advanced IPServices? Naja…..wo ist der Unterschied? Da ich bisher nur das IPServices genutzt habe, musste ich mich gleich mal bei Cisco schlau machen. Hier die Übersicht (Unterschiede) der IOS-Versionen von Cisco:

Layer 2 Base – IEEE 802.1D support, 802.1x point authentication, 802.3ad EtherChannel, 802.1s/w Rapid Spanning Tree, Port Security, SmartPorts, and SSHv2.
LAN Base – Includes Layer 2 Base plus Advanced 802.1x, Advanced Access Lists (Layer 2-4 filtering, Time Based ACLs, Port Based ACLs), and Advanced QoS.
IP Base – Includes all the features of LAN Base, plus Edge IP Routing (Static, RIP, EIGRP-STUB & Basic PIM), HSRP/ VRRP, and GRE Tunneling.
IP Services – Includes all the features of IP Base plus full IP routing (EIGRP, OSPF & PIM), BGP, Policy Based Routing, GLBP, High Availability, Redundant PR+, Multi-VRF, WAN Protocols1, enhanced QoS functionality (NBAR)1, and Catalyst 6500 Virtual Switching System.
Advanced IP Services – Includes all the features of IP Services plus additional features including ISIS, MPLS, Layer 2 VPNs, Layer 3 VPNs, and IPv6.
Enterprise Services – Includes IPv6, all the features of IP Services and additional features for Layer 3 multi-protocol environments, such as AppleTalk Routing, IPX Routing, and IBM Networking Services.
Advanced Enterprise Services – Includes all the features of IP Services and Enterprise Services.

Wer weitere Informationen über Cisco Software benötigt sollte sich das White Paper: Cisco IOS and NX-OS Software Reference Guide unbeding mal anschauen.

Backup/Restore/Update Cisco-IOS via TFTP-Server

imageUm euer IOS zu sichern oder auf ein neues IOS zu aktualisieren benötigt ihr einen TFTP-Server. Ich empfehle euch tftpd32/64 (Download). Das Programm bietet weitere nützlich Funktionen wie z.B. DHCP-Server, DNS-Server, Syslog-Server, SNTP-Server und es ist wirklich einfach zu bedienen. Legt ein Verzeichnis fest und gebt (falls mehrere vorhanden) das richtige Netzwerkinterface an. Wichtig ist, dass euer Switch/Router und der TFTP-Server eine IP-Adresse haben und sich erreichen können.

Sichern des IOS auf einem TFTP Serverimage

Wiederherstellen/Updaten des IOS von einem TFTP-Serverimage

Wiederherstellung Cisco IOS mit Xmodem

imageSolltet ihr bei eurem Router/Switch das IOS zerschossen haben, oder den Flash gelöscht haben, wir das Gerät nicht mehr starten. Damit das Gerät wieder ein IOS laden kann, muss wieder eins in den Flash geladen werden. Als erstes solltet ihr ein ordentliches Terminalprogramm herunterladen. Ich empfehle TeraTerm (Download). Mit “show flash” könnt ihr euch den Inhalt des Flash-Speichers anzeigen lassen. Das geht natürlich nur wenn noch ein IOS drauf ist, wie in meinem Fall. Ich lösche jetzt meinen Flash mit “erase flash:”. imageNach einem Neustart des Routers findet er kein IOS mehr. Es erscheint eine Fehlermeldung “boot: cannot open flash:”. Mit der Eingabe von “confreg” erscheint die Konfigurationszusammenfassung. Wir ändern nur die “Boud rate” damit wir das Image schneller kopieren können. Anschließend tippen wir “reset” um die neue Konsoleneinstellung zu laden. Jetzt über TeraTerm “Einstellungen/Seriellen Port einrichten” die Boud rate anpassen.image

Im nächsten Schritt sagen wir welches Cisco IOS er laden soll. In meinem Fall “xmodem c2600-ipbase-mz.123-9b.bin”. Nachdem wir das eingegeben haben werden wir gefragt “ Do you wish to continue?” wir bestätigen das mit Y. Jetzt müssen wir das IO-Image noch mit TeraTerm an den Router senden. Über “Datei/Transfer/Xmodem/Senden” wählen wir das IOS-Image aus. Das kopieren dauert etwas.

Nach einem Neustart lädt der Router/Switch das eingespielte IOS. Wichtig ist, dass ihr die Boud rate wieder auf 9600 zurück setzt.
Router(config)#line con 0
Router(config-line)# speed 9600
Router(config-line)# exit

Überprüfen könnt Ihr die IOS-Version mit “show version”

Bei einem Switch ist der Ablauf etwas anders. Den „Mode“ Knoopf gedrückt halten und den Switch an Strom anschliessen, Knopf gedrückt halten.

switch: flash_init (Falsh initialisieren)
switch: BAUD 115200 (Baud-Rate erhöhen)
switch: copy xmodem: flash:c2960-lanbasek9-mz.122-55.SE1.bin (Mit xmodem über Terminalprog. senden)
switch: set BOOT flash:c2960-lanbasek9-mz.122-55.SE1.bin (Boot-Parameter anpassen)
switch: set BAUD 9600 (Baud-Rate wie auf Standard)
switch: boot (IOS booten)

Etherchannel, PagP & LACP

image

Ales Etherchannel bezeichnet man ein Verfahren zur Bündelung mehrerer physikalischer Ethernet-Schnittstellen zu einem logischen Kanal. Etherchannel hat sich teilweise als alltäglicher Ausdruck für die Ethernet-Kanal-Bündelung etabliert und wird umgangssprachlich nicht nur für Cisco-Produkte benutzt. He nach Hersteller werden für die Bündelung andere Synonyme benutzt:
    -Bonding, im Linux Umfeld.
    -Etherchannel, bei Cisco.
    -Link Aggregation, bei IEEE
    -Port Aggregation, bei Hewlett-Packard.
    -Trunking, bei Sun Microsystems

Richtlinien für die Konfiguration:
-Bis zu 8 Ethernet Interfaces des selben Typs (nicht den GigaStack GBIC nutzen)
-Geschwindigkeit und Duplex Mode müssen gleich sein.
-"enable" alle Interfaces
-Ein Interface das als SPAN-Port (Switched Port Analyzer) oder 802.1X konfiguriert ist, wird nicht im Etherchannel unterstützt.
-Alle Interfaces müssen sich im selben VLAN befinden oder als Trunk gesetzt sein.
-Bei Trunking bitte den Mode beachtetn ISL oder 802.1Q müssen identisch sein

Port Aggregation Protocol (PagP)image
Vom Funktionsprinzip ähnelt das proprietäre PAgP (CISCO) dem offenen LACP. Das PAgP erkennt, durch das Aussenden sogenannter Hello-Pakete, ob zwei Switches über mehr als eine physikalische Verbindung direkt verbunden sind. Das senden der Hello-Pakete findet nur im "desirable" Modus statt, während im "auto" Modus nur auf diese Pakete geantwortet wird.

Link Aggregation Control Protocol (LACP) IEEE 802.1AX-2008 (früher IEEE 802.3ad)
LACP hat den Vorteil das es Herstellerübergreifend arbeitet. Bei LACP kann jeder einzelne Port als Active LACP oder Passive LACP konfiguriert werden:
Passive LACP: der Port bevorzugt von sich aus keine LACPDUs zu übertragen. Nur wenn die Gegenstelle Active LACP hat, überträgt der Port LACPDUs (preference not to speak unless spoken to).
Active LACP: der Port bevorzugt LACPDUs zu übertragen und somit das Protokoll zu sprechen unabhängig davon ob die Gegenstelle Passive LACP hat oder nicht (a preference to speak regardless).

Cisco: Configuring EtherChannels

Befehle:
Das Konfigurationsbeispiel erstellt einen Etherchannel aus den Interfaces Gigabit Ethernet 0/4 und 0/5 als static-acces Ports in VLAN 10 zu Channel 5 mit PAgP-Modus “desirable”

Switch# configure terminal
Switch(config)# interface range gigabitethernet0/4 -5
Switch(config-if-range)# switchport mode access
Switch(config-if-range)# switchport access vlan 10
Switch(config-if-range)# channel-group 5 mode desirable
Switch(config-if-range)# end

Route Summarization (Routenzusammenfassung)

Bei der Routenzusammenfassung geht darum, die Updates die zwischen den Routern gesendet werden möglichst klein zu halten. In diesem Beispiel werden wird die Routen des „Seville“ Routers zusammen fassen.

image

An Seville sind die Subnetze 10.3.4.0, 10.3.5.0,10.3.6.0 und 10.3.7.0 angeschlossen, die alle die Subnetzmaske 255.255.255.0 haben. Als erstes stellen wir alle Subnetzadressen in Binärform da.

00001010 00000011 00000100 00000000 = 10.3.4.0
00001010 00000011 00000101 00000000 = 10.3.5.0
00001010 00000011 00000110 00000000 = 10.3.6.0
00001010 00000011 00000111 00000000 = 10.3.7.0

Jetzt ermitteln wir alle gemeinsamen Bits am Anfang aller Subnetze. Wir sehen das die ersten beiden Oktette in allen vier Subnetzen identisch sind also sind die ersten 16Bit identisch. Die ersten sechst Bits des dritten Oktetts stimmen ebenfalls überein. Das siebte Bit im dritten Oktett weist unterschiedliche Werte auf. Der gemeinsame Anteil der vier Subnetze umfasst die ersten 22 Bits, hier rot dargestellt.

Im nächsten Schritt erstellen wir eine Subnetzadresse für die zusammengefassten Subnetze.
Hier werden die gemeinsamen Bits notiert (ROT) und für die verbleibenden Bits binäre Nullen gesetzt. Sieht wie folgt aus.

00001010 00000011 00000100 00000000 = 10.3.4.0

Jetzt wird die Maske ermittelt. Wir setzten für die gemeinsam genutzten Bits Einsen (rot), für die bleibenden Bits setzen wir Nullen (grün)

11111111 11111111 11111100 00000000 – 255.255.252.0

Jetzt steht unsere zusammengefasste Route fest.

10.3.4.0 /22

Das ganze können wir mit Subnetting überprüfen. Die zusammengefasste Route sollte alle IP-Adressen der vier Subnetze umfassen. Der Adressbereich beginnt bei 10.3.4.0. Die erste gültige Adresse ist 10.3.4.1, die letzte 10.3.7.254. Als Broadcast-Adresse wird die 10.3.7.255 verwendet. Unsere zusammengefasste Route enthalt also alle IP-Adressen der vier zusammengefassten Routen und keine Fremdadressen.

Spanning Tree Protocol (STP IEEE802.1d / RSTP IEEE802.1w)

Spanning Tree Protocol (STP IEEE 802.1d)

Das Spanning Tree Protocol (Schleifenverhinderungsmechanismus) dient zur Vermeidung redundanter Netzpfade (Schleifen) im LAN, speziell in geswitchten Umgebungen. In einem Netzwerk, mit mehreren, untereinander verbundenen Bridges kann es passieren, dass Frames, die zu einer unbekannten MAC geleitet werden sollen, unendlich lange im Kreis laufen.
Funktionsweise: Zur Kommunikation zwischen den Switches wird das Bridge-Protokoll genutzt. Die Bezeichnung Switch ist abgeleitet von Bridge, da Switches die Weiterentwicklung der Bridge sind (Switches werden auch als Multiport-Bridges bezeichnet). Die Pakete dieses Protokolls werden Bridge Protocol Data Unit (BPDU) genannt. Sie werden im Datenfeld eines Ethernet-Datenpaketes (Ethernet-Frame) per Broadcast an die benachbarten Switches versendet.
Zunächst wird unter den Spanning Tree fähigen Bridges im Netz eine sog. Root Bridge gewählt, die die „Chef” des Netzes wird. Dies geschieht, indem alle Bridges ihre Bridge-ID (die jede Bridge besitzt) an eine bestimmte Multicast-Gruppe mitteilen. Die Bridge ID ist 8 Byte lang (2 Bytes Bridge Priority und 6 Bytes MAC Adresse). Die Bridge mit der niedrigsten Priorität wird zur Root Bridge. Sollte die Bridge Priority identisch sein, wird als ergänzendes Kriterium die MAC Adresse der Komponenten benutzt (auch hier gewinnt wieder die Bridge mit der niedrigeren Zahl).
Von der Root Bridge aus werden nun Pfade festgelegt, über die die anderen Bridges im Netz erreichbar sind. Sind redundante Pfade vorhanden, so müssen die dortigen Bridges den entsprechenden Port deaktivieren. Die Pfade, über die kommuniziert werden darf, werden anhand von Pfadkosten bestimmt, die die dortige Bridge übermittelt.
Die Kosten sind abhängig vom Abstand zur Root Bridge und dem zur Verfügung stehenden Uplink zum Ziel. Ein 10 Mbit/s-Uplink hat üblicherweise höhere Pfadkosten als ein 100 Mbit/s-Uplink zum gleichen Ziel, der 10 Mbit Link würde daher als redundanter Pfad geblockt werden. Die Pfadkosten sind nach IEEE-Vorgaben genormt, können aber manuell abweichend festgelegt werden, beispielsweise um bei gleicher Geschwindigkeit einen bevorzugten Uplink auszuwählen, um so die reellen Kosten von Standleitungen widerzuspiegeln. Auf diese Weise ist jedes Teilnetz im geswitchten LAN nur noch über eine einzige, die Designated Bridge, erreichbar. In der grafischen Darstellung ergibt sich ein Baum aus Netzpfaden, der dem Algorithmus sowie dem Protokoll seinen Namen gab.
Die Root Bridge teilt den in der Hierarchie eine Stufe unterhalb liegenden Designated Bridges im Abstand von zwei Sekunden mit, dass sie noch da ist, woraufhin die empfangende Designated Bridge ebenfalls an nachfolgende Bridges die entsprechende Information senden darf. Wenn diese Hello-Pakete ausbleiben, hat sich folglich an der Topologie des Netzes etwas geändert, und das Netz muss sich reorganisieren. Diese Neuberechnung des Baumes dauert im schlimmsten Fall bis zu 30 Sekunden. Während dieser Zeit dürfen die Spanning-Tree fähigen Bridges außer Spanning-Tree-Informationen keine Pakete im Netz weiterleiten. Dies ist einer der größten Kritikpunkte am klassischen Spanning Tree Protokoll, da es möglich ist, mit gefälschten Spanning-Tree-Paketen eine Topologieänderung zu signalisieren und das gesamte Netz für bis zu 30 Sekunden lahmzulegen. Um diesen potenziellen Sicherheitsmangel zu beheben, aber auch um bei echten Topologieänderungen das Netz schnell wieder in einen benutzbaren Zustand zu bringen, wurden schon früh von verschiedenen Herstellern Verbesserungen an der Implementierung des Spanning Tree Protokolls bzw. der dazu verwendeten Algorithmen entwickelt. Eine davon, das Rapid Spanning Tree Protocol (RSTP), ist inzwischen zum offiziellen IEEE-Standard 802.1w geworden.


STP Port Modi
-Listening – Lauscht auf Hello Nachrichten. Es werden keine MAC gelernt. Zwischending zwischen blocking und forwarding
-Learning – Lauscht ebenfalls auf BPDUs, lernt MACs, leitet aber nicht weiter.
-Disabled – Port ist down

Optionale STP Features

Etherchannel
Etherchannel Verbindungen werden als einzelner Link betrachtet und können aus zwei bis 8 Verbindungen zwischen zwei Switches bestehen. Dadurch erhöht sich die Bandbreite und die Anzahl paralleler Verbindungen wird reduziert. Diese Verbindungen werden Trunks genannt. Alle Trunks sind im Etherchannel entweder im forwarding oder im blocking modus

PortFast
PortFast versetzt einen Port, direkt nach dem aktivieren in den forwarding Modus. Da dies auf Ports, an denen Bridges hängen wenig Sinn macht, wird PortFast nur für die Ports aktiviert, an denen PCs, bzw. andere End-Geräte angeschlossen sind. Sie können eine Sicherung aktivieren, die PortFast deaktiviert, sobald ein BPDU eingeht.

Spanning-Tree
Protokoll zum verhindern von Schleifen in geswitchten Netzwerken
STP setzt die Ports entweder in einen FORWARD oder in einen BLOCKING Zustand
FORWARD -> ist Teil des Spanning-Trees -> sendet und empfängt Frames
BLOCKING -> sendet keine Frames und ignoriert eingehende Frames


STP verursacht, dass Frames längere Wege zurücklegen müssen
großer Vorteil ist aber es entstehen keine Schleifen

Funktionsweise STP
-Spanning-Tree-Algorithmus erstellt eine Baumstruktur, in der es immer nur einen Weg zu einem Segment (Kollisionsdomain) gibt
-Da es nur einen Weg gibt, gibt es keine Schleifen
-Es werden nur die Ports in den Spanning-Tree aufgenommen, die gebraucht werden (FORWARD), alle Anderen werden auf BLOCKING gesetzt.
-Es gibt 3 Kriterien, wann ein Port auf FORWARD steht
-STP wählt eine Root-Bridge (alle Ports auf FORWARD)
D-er Port an den Non-Root-Bridges mit den geringsten administrativen Kosten zur Root-Bridge wird Root-Port (FORWARD)
-Der Port zu einem Segment mit den geringsten administrativen Kosten zur Root-Bridge wird Designated-Port genannt (FORWARD)
-Alle anderen Ports werden auf BLOCKING gesetzt

Administrative Kosten (IEEE)

Ethernet Speed Original Kosten Geänderte Kosten
10 MBit/s 100 100
100 MBit/s 10 19
1 GBit/s 1 4
10 GBit/s 1 2

Diese Werte können auch pro Port verändert werden

Rapid Spanning Tree (RSTP IEEE 802.1w)

-RSTP funktioniert ähnlich wie STP
-Root Bridge wird gewählt (selbe Bedingungen)
-Root Ports werden definiert
-Designated Ports werden definiert
-forwarding oder blocking Modus (blocking heißt hier discarding)
RSTP bezeichnet Verbindungen zwischen Switches als link Type und Verbindungen zu Endgeräten als edge Type. Ist ein Gerät direkt angeschlossen, (z.B. PC an Switch) bezeichnet RSTP dies als Point to Point (Full Duplex!!) Verbindung (In diesem Fall edge type pt-pt). Hängen mehrere Geräte (z.B. Hub zwischen PCs und Switch) wird diese als shared bezeichnet (z.B. link Type shared – Hub an Switch).RSTP reduziert die Konvergenzzeit für link Type pt-pt und edge Type pt-pt.

Im discarding Modus werden sämtliche Frames geblockt, außer BPDUs. Der Zeitraum für den learning mode ist bei RSTP kürzer.

Zusätzliche Port Funktionen

Backup Port
Diese Funktion kann nur genutzt werden, wenn ein Switch zwei Verbindungen in ein Netzwerksegment besitzt, also an einem Hub angeschlossen ist. Port 1 sendet BPDUs, welche auf Port 2 ankommen, und trotz dicarding mode angenommen werden. Der Switch weiß nun, dass zwei Verbindungen in dieses Segment bestehen und markiert Port 2 als Backup Port, zu dem bei Ausfall von Port 1, sofort gewechselt werden kann.

RSTP alternate port
RSTP definiert zusätzlich zum root port einen alternativen Port. Dieser Port wird bestimmt, durch die Kosten zur root Bridge. Der „billigste“ Port wird root port und der Zweitplatzierte alternate Port. Sollte der root port ausfallen, wird in kürzester Zeit zum alternate port umgeschaltet, damit wieder Konvergenz hergestellt werden kann.

Cisco Switches nutzen grundsätzlich STP, verhindern automatisch Schleifen, ohne, dass Sie sich um Einstellungen kümmern müssten! Sie können allerdings Änderungen am STP vornehmen, wenn Sie z.B. andere Parameter für Ihr VLAN nutzen wollen.

Befehle (Cisco)

Switch# show spanning-tree zeigt Root-Bridge ID und Eigene-ID

zeigt die Timereinstellungen

zeigt den derzeitigen Portstatus (FWD;BLK)

Switch# show spanning-tree detail Zeigt Infos zu Spanning-Tree pro Interface
Switch# terminal monitor Aktiviert die Ausgabe von Debug-Meldungen
Switch# debug spanning-tree events Gibt Statusmeldungen aus, wenn die STP Topologie geändert wird
Switch(config-if)# spanning-tree cost 2 Ändert die Kosten eines Interfaces
Switch(config)#
spanning-tree vlan 1 root primary
Die Bridge/Switch wird Root-Bridge

(die Priorität wird automatisch verringert)

EtherChannel

Switch(config-if)#

channel-group 1 mode on

Fügt das Interface dem Port-Channel hinzu

(EtherChannels wird als Po1 dargestellt)

Switch# show etherchannel 1 summary Zeigt den Status über den EtherChannel an.

welche Ports sind in dem EtherChannel

PortFast

Switch(config-if)#

switchport mode access

FastPort kann nur für Access-Link aktiviert werden
Switch(config-if)# spanning-tree portfast Aktiviert PortFast für dieses Interface