Top-Themen

Aktuelle Themen (A bis Z)

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWünsch Dir wasWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

gelöst Spanning Tree Probleme - topology change received - RSTP

Mitglied: tech-flare

tech-flare (Level 2) - Jetzt verbinden

13.01.2020, aktualisiert 20.02.2020, 1680 Aufrufe, 48 Kommentare

Servus alle miteinander,

ich habe leider seit ein paar Wochen Probleme, dass einige ThinClients (vielleicht 20 von 250) kurzfristig ihr Netz verlieren. 1-2 Sekunden, manche aber auch länger.

Im CoreSwitch und dementsprechend auch im Syslog erhalte ich immer wieder spanning tree topology change received.

Auch wenn die Hardware nicht die "beste" Auswahl ist und einige mit den Augen rollen werden und Aqui die Hände über den Kopf zusammenschlägt, hoffe ich auf eure Hilfe oder euren input.

Die Topologie habe ich mal grob aufgezeichnet . Insgesamt sind ca 100 Switche am Netz. Grund sind sehr viele Maschine, PC, Endgeräte, großes Gelände etc.

Core: 2x Netgear M4300-24X gestacked, Layer 3, ca 50 VLAN, 2 weitere M4300 als SFP geplant, um LAG bei allen Verteilerswitchen verwenden zu können.

AccessSwitche: Unifi 48 Port POE, dazwischen Unifi Glasswitche zum verteilen.

Einige Switche sind über LACP LAG angebunden, andere wiederum nicht. Je nachdem , ob es bisher möglich war.

Hier Auszüge vom Core:
Wie ihr seht kommt der Change nicht nur von einen Port.


Was habe ich bisher gemacht:
Jeden Switch auf die STP Priority überprüft, Neueste Firmware, Neugestartet etc.


An Wochenenden oder in den Nachtschichten treten weniger Change befehle auf.

RSTP nach IEEE 802.1w verwende ich um eine "Sicherung" gegen Schleifen an den Access Switchen zu erhalten. Die Unifi Switche haben leider keine andere Loop Protection. Ein Neukauf von anderen Geräten steht nicht zur Debatte.

Auszug Core:

Auszug Unifi Verteiler:


Auszug Unifi Access

Andere Switche sind bzw. sollten nicht im Netz sein. Wenn dann ohne unsere Zustimmung.
topo - Klicke auf das Bild, um es zu vergrößern
48 Antworten
Mitglied: Deepsys
13.01.2020 um 19:40 Uhr
Hi,

versuche doch erstmal herauszufinden wer denn die "neue" Root-Bridge wird.
10:00:08:BD:43:78:6F:7D ist wohl der Core, oder?

Komisch finde ich gerade, das es auf dem Core öfter Root-Changes gibt es im Acces.

Ach ja, Verteiler ist nicht gerade der richtige Name, das sind eher die Aggregation Switche .

Viele Grüße,
Deepsys
Bitte warten ..
Mitglied: tech-flare
13.01.2020, aktualisiert um 20:02 Uhr
versuche doch erstmal herauszufinden wer denn die "neue" Root-Bridge wird.
10:00:08:BD:43:78:6F:7D ist wohl der Core, oder?

Ja das ist der Core.

siehe dazu:
Komisch finde ich gerade, das es auf dem Core öfter Root-Changes gibt es im Acces.
Naja ich wollte jetzt ungern alle Ausgaben der Access und Aggregation Switche posten. Bei irgendeinem stimmt die Zeit schon immer.

Aber z.B. bei diesem hängen nur WLAN AP dran und dort kommt kein TC zustanden....der läufte seit Tagen einfach durch.
Ach ja, Verteiler ist nicht gerade der richtige Name, das sind eher die Aggregation Switche .
Ja...sorry ;
Bitte warten ..
Mitglied: tech-flare
13.01.2020 um 21:50 Uhr
Im Wireshark taucht immer wieder Ubiquiti / Unifi mit STP auf...und zwar wird dort als Dest MAC diese angegeben: 01:80:c2:00:00:00

Bei Netgear gibt es einen Beitragbzgl. 3rd Party AP mit der MAC 01:80:c2:00:00:1c

https://kb.netgear.com/000038810/Adding-a-MAC-ACL-on-Fully-and-Smart-Man ...">https://kb.netgear.com/000038810/Adding-a-MAC-ACL-on-Fully-and-Smart-Man ...

Ist es sinnvoll den MAC gemäß FAQ zu filtern? Wenn ja welche?
Bitte warten ..
Mitglied: IT-Prof
13.01.2020 um 22:32 Uhr
Du kennst nicht alle Mac Adressen aller Switches?

Ein Port Flapping kannst Du ausschließen?
Bitte warten ..
Mitglied: routermax
13.01.2020, aktualisiert um 22:35 Uhr
Hallo,

Hast du geprüft ob alle das gleiche STP Protokoll sprechen?

Grüße
Max
Bitte warten ..
Mitglied: tech-flare
13.01.2020 um 22:55 Uhr
Zitat von IT-Prof:

Du kennst nicht alle Mac Adressen aller Switches?

Doch doch...diese kenne ich alle.
Die 01:80:c2:00:00:00 ist da aber nicht dabei. Soweit ich das richtig deute ist das ein Multicast an eine MAc von Unifi aus - warum auch immer. Die Frage...kann es dadurch STP Probleme geben?

Ein Port Flapping kannst Du ausschließen?
Das würde mich wundern, wenn das auf allen Ports / Egal ob SFP oder Kupfer am Core auftritt.
Bitte warten ..
Mitglied: tech-flare
13.01.2020, aktualisiert um 22:57 Uhr
Hast du geprüft ob alle das gleiche STP Protokoll sprechen?

Es gibt nur 2 Hersteller im Haus.

Im Core der Netgear. Dieser läuft auf IEEE 802.1w also RSTP.

Und die anderen sind alle Ubiquiti Unifi, welche auch auf RSTP gestellt sind.
Bitte warten ..
Mitglied: IT-Prof
13.01.2020 um 23:02 Uhr
Hast du LLDP bei den Unifis aktiviert?
Bitte warten ..
Mitglied: IT-Prof
13.01.2020 um 23:03 Uhr
Hast du UniFi Access Points und dort das Wireless Uplink aktiviert?
Bitte warten ..
Mitglied: tech-flare
13.01.2020 um 23:05 Uhr
Zitat von IT-Prof:

Hast du UniFi Access Points und dort das Wireless Uplink aktiviert?
Nein. Alle AP sind per LAN angeschlossen.
Bitte warten ..
Mitglied: IT-Prof
13.01.2020 um 23:07 Uhr
Ja, sie können per LAN angeschlossen sein und dennoch kann das Feature aktiviert sein.
Bitte warten ..
Mitglied: tech-flare
13.01.2020 um 23:09 Uhr
Zitat von IT-Prof:

Hast du LLDP bei den Unifis aktiviert?
Ja,

das ist auf den Ports, bei denen 802.1x aktiv ist, aktiviert - und das sind ca 95 % aller Ports bei mir hier
Bitte warten ..
Mitglied: IT-Prof
13.01.2020 um 23:11 Uhr
Kannst Du das testweise abstellen?

Mein Bauchgefühl sagt mir, dass du kurzzeitig einen Loop hast.

Ich persönlich würde versuchen mit Wireshark den Moment mitzuschneiden.
Bitte warten ..
Mitglied: tech-flare
13.01.2020 um 23:12 Uhr
Das ist deaktiviert. Siehe den Ausschnitt

stp_unifi - Klicke auf das Bild, um es zu vergrößern

Ich habe auch einen Switch, an den nur AP dran hängen und bei den ist der letzte Topo Change vor 30 Tagen gewesen.
Bitte warten ..
Mitglied: tech-flare
13.01.2020 um 23:20 Uhr
Kannst Du das testweise abstellen?
Spanning Tree? Das geht erst am Wochenende.


Ich persönlich würde versuchen mit Wireshark den Moment mitzuschneiden.
Läuft die ganze Zeit, aber bisher sehe ich nut die STP Packets ohne Topo Change
Bitte warten ..
Mitglied: IT-Prof
13.01.2020 um 23:23 Uhr
Das LLDP abstellen.
STP abstellen, müsste man gucken wie genau die Implementierung ist. Selbst Portfast heißt ja nicht, dass STP "aus" ist.

Die Topo Chance Pakete treffen im Core weiterhin über mehrere Ports ein? Augenscheinlich gleicher Absender?

BPDU auch alles geprüft?
Bitte warten ..
Mitglied: tech-flare
13.01.2020 um 23:28 Uhr
Das LLDP abstellen.
ja das könnte ich machen - ich stehe nur gerade auf dem Schlauch was das LLDP mit STP zu tun haben soll..

STP abstellen, müsste man gucken wie genau die Implementierung ist. Selbst Portfast heißt ja nicht, dass STP "aus" ist.

Die Topo Chance Pakete treffen im Core weiterhin über mehrere Ports ein? Augenscheinlich gleicher Absender?
ja treffen Sie....den Absender bekomme ich aber nicht raus...im Moment hängt ein Wireshark am Aggregation Switch im VLAN untagged

Eine Idee wie ich die STP Packete am Core einsehen kann? Direkt an einen Untagged Port hängen?

RSTP selbst ist ja VLAN unabhängig.
Bitte warten ..
Mitglied: IT-Prof
13.01.2020 um 23:40 Uhr
LLDP war nicht nur ein Mal Buggy. ;)
Ansonsten Ausschlussprinzip.

Lies Mal: https://community.ui.com/questions/Firmware-3-7-x-and-NetGear-Switches-i ...

Wenn du über WS am Core nicht rausbekommt, wo das Störschwein sitzt, dann suche die Links manuell ab, durch trennen der Patchkabel.

Am Anfang in Gruppen, 4 Links/Bündel auf ein Mal. Dann sieht du Recht schnell wenn du das richtige isoliert hast. Bei den vielen Vorgängen sollte Recht schnell Klarheit sich einstellen.

Du kannst auch an den Uplinks zum Core eine ACL probieren.
Bitte warten ..
Mitglied: tech-flare
13.01.2020, aktualisiert um 23:47 Uhr
Zitat von IT-Prof:

LLDP war nicht nur ein Mal Buggy. ;)
Ansonsten Ausschlussprinzip.
Ok. Können negative Effekte auftreten, wenn ich LLDP vorerst deaktivere?


Das habe ich ja weiter oben bereits geschrieben...Netgear hat das Hier erklärt. Daher habe ich mal eine ACL dazu erstellt und auf 2 Links vorerst zum test gelegt.

Wenn du über WS am Core nicht rausbekommt, wo das Störschwein sitzt, dann suche die Links manuell ab, durch trennen der Patchkabel.
Ja...das ist halt bei über 100 Switchen viiel Arbeit...wobei das kurios wäre, da an 5 von 8 Uplinks die TC auftreten, aber an die meisten Dosen die Anwender gar nicht rankommen (Industriebetrieb)

Aber vielleicht hat Aqui ja auch noch einen Idee - ich warte ja schon auf seine Antwort...auch wenn er ersta zum UniFi Gegenschlag ausholt :D
Bitte warten ..
Mitglied: IT-Prof
13.01.2020 um 23:54 Uhr
Was machst du denn mit dem LLDP über den UniFi Controller hinaus?

Die Mac Adresse, die du nennst, sendet dir jeder Hersteller, bei mehreren Protokollen. Das ist " besondere" Mac, die vielen Admins das Herz erwärmt. Manch einer hat die km Ausweis stehen.

Ich würde mich nicht auf UniFi versteifen.

Deshalb sage ich ja, am Core gleich gruppenweise offline nehmen. Gibt bestimmt was Richtung Portrange und Shutdown oder so.

Besonders in Industriebetrieben ist das nicht ungewöhnlich, eher typisch. Ich komme auch aus der Ecke (Automotive)

Und denke immer an den netten Kollegen der das Patchkabel für Dich wieder eingesteckt hat. Diesen Kollegen kennen viele.

Unbrauchbare Antipathie-Posting bezüglich deiner im Einsatz befindlichen Hardware, brauchst du nicht herbeisehnen. Sie helfen nicht und sind ein Ausdruck von persönlicher Schwäche. Du suchst hier Hilfe.
Bitte warten ..
Mitglied: Deepsys
14.01.2020 um 08:16 Uhr
Guck dir doch immer wieder mal die STP-Ausgabe an, und gucke ob da irgendwann eine andere Root-ID steht.

Ansonsten, kann das nicht Wireshark mitfiltern?
Bitte warten ..
Mitglied: tech-flare
14.01.2020 um 08:32 Uhr
Zitat von Deepsys:

Guck dir doch immer wieder mal die STP-Ausgabe an, und gucke ob da irgendwann eine andere Root-ID steht.
Bis jetzt war da nichts brauchbares dabei.

Ansonsten, kann das nicht Wireshark mitfiltern?
Ja..mal sehen was rauskommt. Seit 1 h Stunden hängt ein Laptop mit Wireshark direkt am Core und zeichnet auf.

Bisher hing er nur am Access oder Aggregation Switch und da waren nur die bpdu Packets zu sehen
Bitte warten ..
Mitglied: aqui
14.01.2020, aktualisiert um 17:29 Uhr
Ein paar wichtige Fragen zum generellen STP Design:
  • Welches STP Protokoll fährst du netzwerkweit ? STP, RSTP, MSTP ?
  • Ist das ohne Ausnhame auf allen Switches durchgehend entsprechend eingerichtet ?
  • Gibt es ggf. Fremdswitches im Netz die PVSTP oder PVSTP+ sprechen, also STP Protokolle die inkompatibel zu den oa. sind ?
  • Sind die beiden Core Switches explizit mit statischer STP Prio als Root und Backup Root gesetzt ?? (Globale RSTP Prio z.B. 4096 (Root) und 8192 (Backup Root), Rest der Switches Default 32768)
  • Wenn RSTP hast du alle Uplinks entsprechend als RSTP P2P Ports konfiguriert ? Entsprechend die Access Ports als RSTP Edge Ports ?

All das ist essentiell wichtig in einem sauberen Spanning Tree Design und extrem wichtig in einem Design mit unterschiedlichen Herstellern. Insbesondere die richtige Prio Einstellung um die Pfade vorzugeben.
Leider gibt es keinerlei Infos zu den Konfigs der Komponenten, deshalb muss man diese Banalfragen oben stellen.
Ein paar grundlegende Erklärungen liefert auch ein recht detailierter MSTP Thread hier:
https://www.administrator.de/frage/spanning-tree-modus-migration-pvst-ms ...

Nur mal nebenebei OT: Ein Netzwerk dieser Größenordnung mit Billigswitches dieser Art zu designen ist aber auch schon recht mutig wenn nicht fahrlässig. STP Topos dieser Größenordnung verlangen entsprechende CPU Power die diese Billigswitches alle nicht haben und deshalb dort nichts zu suchen haben. Von der sehr oft mehr als mickrigen STP Implementation und deren Features mal erst gar nicht zu reden.
Jeder Admin der sowas designt weiss das bei einer STP Infrastruktur dieser Größe ein anderes Kaliber von HW erforderlich ist. Der grundsätzliche Fehler ist also schon viel früher gemacht worden.
Bitte warten ..
Mitglied: tech-flare
14.01.2020, aktualisiert um 20:48 Uhr
Hi aqui,

Zitat von aqui:

Ein paar wichtige Fragen zum generellen STP Design:
  • Welches STP Protokoll fährst du netzwerkweit ? STP, RSTP, MSTP ?
Im Netgear (Core) und den Unifi Switchen ist RTSP eingestellt - so steht es auch oben

* Ist das ohne Ausnhame auf allen Switches durchgehend entsprechend eingerichtet ?
ja, sowie auf allen Ports

* Gibt es ggf. Fremdswitches im Netz die PVSTP oder PVSTP+ sprechen, also STP Protokolle die inkompatibel zu den oa. sind ?
Es war mal vor 1 Monat noch ein Cisco SG200 im Netz, welcher aufgrund Inkompatibilität entfernt worden ist

* Sind die beiden Core Switches explizit mit statischer STP Prio als Root und Backup Root gesetzt ?? (Globale RSTP Prio z.B. 4096 (Root) und 8192 (Backup Root), Rest der Switches Default 32768)
Die 2 Core sind gestackt und treten somit als ein Switch in Erscheinung und besitzen die RTSP Prio 4096

Config Core
Spanning Tree Auszug von Core

Gui RTSP Core
spanning-tree-core - Klicke auf das Bild, um es zu vergrößern

Die Access Switche waren auf 32768, aber auch eine Änderung entsprechend den Baum abwärts vom Root aus gesehen bringt keine Änderung

* Wenn RSTP hast du alle Uplinks entsprechend als RSTP P2P Ports konfiguriert ? Entsprechend die Access Ports als RSTP Edge Ports ?
Die Unifi erkennen die P2P Ports als solche (es geht oftmals wirklich nur 1 Leitung zum nächsten Switch Richtung Root)-

All das ist essentiell wichtig in einem sauberen Spanning Tree Design und extrem wichtig in einem Design mit unterschiedlichen Herstellern. Insbesondere die richtige Prio Einstellung um die Pfade vorzugeben.
Leider gibt es keinerlei Infos zu den Konfigs der Komponenten, deshalb muss man diese Banalfragen oben stellen.
Kein Problem

Ein paar grundlegende Erklärungen liefert auch ein recht detailierter MSTP Thread hier:
https://www.administrator.de/frage/spanning-tree-modus-migration-pvst-ms ...
Nur mal nebenebei OT: Ein Netzwerk dieser Größenordnung mit Billigswitches dieser Art zu designen ist aber auch schon recht mutig wenn nicht fahrlässig. STP Topos dieser Größenordnung verlangen entsprechende CPU Power die diese Billigswitches alle nicht haben und deshalb dort nichts zu suchen haben. Von der sehr oft mehr als mickrigen STP Implementation und deren Features mal erst gar nicht zu reden.
Jeder Admin der sowas designt weiss das bei einer STP Infrastruktur dieser Größe ein anderes Kaliber von HW erforderlich ist. Der grundsätzliche Fehler ist also schon viel früher gemacht worden.
Ja ich weiß....aber das ist ein anderes Thema. Grundsätzlich sollte ja "simples RSTP" funktionieren. Der Traffic selbst im Netzwerk ist nicht hoch - oftmals nur RDP von den ThinClients oder "Meldedaten"

Ich habe heute den ganzen Tag am Core Wireshark mitlaufen lassen...Filter: STP - trotz das Topo Changes stattgefunden haben, konnte ich nur die bpdu Packets aller 2 Sekunden aufzeichnen. Habe ich eine Chance den Verursacher zu finden, außer alle Kabel Temporär abzuziehen?

Weitere Frage
Port 1/15 am Core - dort hängt ein Bereich dran, welcher im November komplett neu aufgebaut worden ist - dort ist defintiv keine Schleife...die Dose hängen alle an Kabeltraversen und darunter stehen nur Maschinen - dennoch kommt von da hin und wieder ein Topology Change. Kann das auch passieren, wenn in einem anderen Bereich etwas "verrückt" spielt?

Anmerkung

Ich habe hier ein NAC im Einsatz (Mac Auth im LAN), sodass ein fremder Switch normalweise bei mir hier als unregistriertes Gerät auftauchen müsste
Bitte warten ..
Mitglied: Deepsys
15.01.2020 um 12:17 Uhr
Was ist denn mit der Zeile:
Port Triggered TC.............................. 1/0/21

TC? Topology Change?
Was hängt denn da dran?
Bitte warten ..
Mitglied: tech-flare
15.01.2020 um 18:09 Uhr
Zitat von Deepsys:

Was ist denn mit der Zeile:
Port Triggered TC.............................. 1/0/21

TC? Topology Change?
ja
Was hängt denn da dran?
Ein Aggregation Switch, an dem hängen aber dann 4 x 48 Port Access Switche. Jedoch tritt das Problem an 3 Ports am Core auf.

Ich versuche gerade die 48 Port Switche einzeln (zumindest temporär) am Core direkt anzuschließen, damit ich den Verursacher besser eingrenzen kann. Denn am Core sehe ich letztendlich von welchem Port es kommt
Bitte warten ..
Mitglied: aqui
LÖSUNG 15.01.2020, aktualisiert um 19:41 Uhr
Ziehe erstmal die 3 problematischen Ports ab wenn das geht. (Physische Trennung)
Dann checkst du ob die TC Changes aufhören was sie sollten.
Wenn ja, steckst du sie einzelnd sukzessive wieder zu auch ggf. die Switches die hinterher kaskadiert sind an diesem Aggregation Switch.
In der Regel ist an dem Switch dann der Fehler wo die TC Changes wieder auftauchen.
Die Vorgehensweise klingt im ersten Moment etwas dilletantisch aber STP zu troubleshooten auf diesen billigen SoHo Switches ist nicht einfach weil denen vollständig jegliche Debug Funktionen fehlen die im Premium Bereich üblich sind.
Es hilft aber in der Regel immer so den Fehler ziemlich schnell und genau einzukreisen.
Bitte warten ..
Mitglied: tech-flare
15.01.2020 um 20:49 Uhr
Ziehe erstmal die 3 problematischen Ports ab wenn das geht. (Physische Trennung)
die geht leider nicht ohne weiteres - da hängen Maschinen ran -> muss ich aufs WE verschieben.

Die Vorgehensweise klingt im ersten Moment etwas dilletantisch aber STP zu troubleshooten auf diesen billigen SoHo Switches ist nicht einfach weil denen vollständig jegliche Debug Funktionen fehlen die im Premium Bereich üblich sind.
Da gebe ich dir recht....das merke ich gerade

Aber ich bin bereits ein Stück weiter
Ich habe heute einen uralt Netgear Switch ausfindig gemacht, welcher an einer Maschine verbaut war....wer auch immer den wann dort hingebaut hat....laut Datenblatt ist der unmanged (somit sollte er doch keine STP Befehle senden, oder?)

Ich habe den 8 Port Switch natürlich sofort entfernt und gegen ein managed getauscht auf den RTSP aktiv ist.

Auch wenn man im Unifi Controller leider die BPDU Packets leider nicht einsehen kann, so haben sie doch wenigstens eine vollwertige CLI ;)
An dem Port wurden auf jedenfall BPDU Packet empfangen und gesendet.
Bei den anderen Ports steht nur auf "Transmitted". Kann das stimmen?

Am Core werden die Logs weniger - so habe ich nach ein paar Stunden den Eindruck, aber irgendwo muss noch ein Gerät hängen - warum auch immer. (Das sind aber nochmal 6 x 48 Port Switche).

Kann ich über die CLI nach RSTP BPDUs Received filtern, oder muss ich jedes Interface einzeln anschauen?
Bitte warten ..
Mitglied: tech-flare
15.01.2020 um 20:56 Uhr
Noch etwas:

Die Config der Unifi sieht so aus (gekürzt)

und vom Core:
Beim Core steht bei Spanning Tree nicht "RTSP", obwohl dies laut GUI aktiviert ist.

Im Handbuch (Link) auf Seite 201 lese ich, dass MSTP im RTSP Modus arbeitet, wenn die aktiviert ist. Deute ich das richtig?

Bitte warten ..
Mitglied: IT-Prof
13.02.2020 um 13:00 Uhr
Wie ging dieses Thema eigentlich weiter?
Bitte warten ..
Mitglied: aqui
13.02.2020 um 15:47 Uhr
Wäre in der Tat mal spannend...
Zumal der TO den Thread auch noch nicht auf "Gelöst" gesetzt hat ?!!
Bitte warten ..
Mitglied: tech-flare
17.02.2020, aktualisiert um 00:52 Uhr
Zitat von aqui:

Wäre in der Tat mal spannend...
Zumal der TO den Thread auch noch nicht auf "Gelöst" gesetzt hat ?!!
Leider gibt es noch nichts konkretes neues....wir sind derzeit auf Ursachensuche....

Stand ist, dass wir über 2000 AccessPort haben , wo Endgeräte theroretisch ran könnten (insgesamt sind es viel mehr Ports, aber da stehen einige im RZ bwz in zutrittbeschränkten Räumen). Da die meisten Doppeldosen an oder auf Kabelrinnen sind, haben wir leider noch nicht alle überprüfen können.

Folgendes kann ich sagen:

- Die Topo Changes kommen meistens von bestimmen TrunkPorts (von einigen anderen kommt gar nichts)
- Es gibt Switche.....da findet ein Topo Changes statt , aber da hängen nur ein Dutzend Endgeräte dran - selbst überprüf - wie kann das sein?

Kann es sein, dass wenn ein Switch "verrückt" spielt sich das ganze hochschaukelt und dann für eine Gewisse Zeit normalisiert?
Ist es denkbar, dass die BPDU zu "lang" für den Weg benötigen (hohe Last etc...) und es daher zu den Topo Changes kommt?

Als Workaround habe ich auf den Trunkports am CoreStack derzeit "Root Guard" & TCN Guard aktiviert, sodass dieser die TopoChanges sieht, aber nicht darauf reagiert.....seitdem ist es erstmal stabiler, aber ja nicht die Ursache.

Können Probleme Auftreten, wenn auf den Ports am Coreswitch (Root Bridge) der Root Guard / TCN Guard aktiviert ist? Eigtl müsste der Port bei RootGuard doch blockiert werden... tut er aber nicht... also er verwirrt die TC nur und die Geräte dahinter sind weiterhin erreichbar

Use Root Guard to configure the root guard mode, which sets a port to discard any superior information received by the port and thus protect against root of the device from changing.

Use TCN Guard to configure the TCN guard for a port restricting the port from propagating any topology change information received through that port



BDPU guard habe ich extra nicht aktiviert, da ja sonst der Port auf blockiert geht. Korrekt?

PS.: mir kommt es so vor, dass die TC stattfinden, wenn Geräte angeschaltet werden, da in der Nacht und am Wochenende Ruhe ist. Kann das sein? Wen ja wodurch? Die Geräte sind meist ThinClients oder Industrie PC. Die Maschinen haben immer ein eigenes physisches Netz und hängen nicht bei uns drin.
Bitte warten ..
Mitglied: aqui
LÖSUNG 17.02.2020 um 13:07 Uhr
Kann es sein, dass wenn ein Switch "verrückt" spielt sich das ganze hochschaukelt und dann für eine Gewisse Zeit normalisiert?
Könnte sein, würde dann aber auch klar auf temporäre Loops oder andere STP Probleme hinweisen. Ggf. Broadcast Stürme usw.
Ist es denkbar, dass die BPDU zu "lang" für den Weg benötigen
Nein, das ist völlig ausgeschlossen denn BPDU Beziehungen bestehen immer nur rein Punkt zu Punkt. Also immer nur von einem Switch zum nächsten. Sowas wir nicht weitergereicht wie IP Pakete z.B. Sollte man als Netzwerker aber eigentlich auch wissen !
seitdem ist es erstmal stabiler, aber ja nicht die Ursache.
Richtig ! Damit hast du nur die Symptome bekämpft aber nicht die Ursache. Das Netz bleibt also weiter latent instabil.
Eigtl müsste der Port bei RootGuard doch blockiert werden
Wenn Root Guard aktiviert ist auf den Roots Uplink Ports bleibt der in seiner Designated Rolle. Sollte er dort BPDU Pakete mit einer höheren Priority empfangen wird der Port in den Inconsistend State gesetzt was vergleichbar mit Blocking bzw Discard ist. Kein Traffic wir mehr geforwardet und eine SNMP und Syslog Message generiert. . No further traffic is forwarded on this port. So wird verhindert das falsch oder fehlkonfigurierte Switches Root Ports kapern können.
Kommen an solchen RG Ports keine BPDUs mehr geht der Port sofort wieder in den Learning und Forwarding State.
Es ist also sehr sinnvoll Root Guard auf den Root Uplink Ports zu aktivieren um hier Sicherheit zu erlangen.
BDPU guard habe ich extra nicht aktiviert, da ja sonst der Port auf blockiert geht. Korrekt?
Das ist korrekt wenn es eben diese dedizierten Uplink Ports sind. Auf Access Ports aktiviert man das z.B. damit nicht unbefugte dort STP Switches anschliessen die dir deine gesamte Spanning Tree Topologie damit aus dem Tritt bringen und damit dein Netzwerk in den Orcus reissen.
mir kommt es so vor, dass die TC stattfinden, wenn Geräte angeschaltet werden
Das ist gut möglich. Deshalb definiert man m 802.1w STP Edge Ports im RSTP ja auch immer als Edge Ports dann haben Port Changes an diesen Ports keinerlei Topo Changes zur Folge. Das ist also ein zwingendes ToDo mit dem Kommando: Admin Edge Port
Andersrum definiert man Uplink Ports immer zwingend als Point to Point Ports: Admin Pt2pt Mac
Die Maschinen haben immer ein eigenes physisches Netz und hängen nicht bei uns drin.
Ist dieses Netz dann physisch vollkommen getrennt ??
Wenn ja kann es ja so oder so niemals eine RSTP Wechselwirkung geben.
Wenn nein dann schon. Ist also die Frage wie "getrennt" genau gemeint ist ?!
Bitte warten ..
Mitglied: tech-flare
17.02.2020, aktualisiert um 14:58 Uhr
Zitat von aqui:

Könnte sein, würde dann aber auch klar auf temporäre Loops oder andere STP Probleme hinweisen. Ggf. Broadcast Stürme usw.
ok

Richtig ! Damit hast du nur die Symptome bekämpft aber nicht die Ursache. Das Netz bleibt also weiter latent instabil.
ja ich weiß, aber somit ist es erstmal "behoben"....natürlich möchte ich die Ursache beheben.

Wenn Root Guard aktiviert ist auf den Roots Uplink Ports bleibt der in seiner Designated Rolle. Sollte er dort BPDU Pakete mit einer höheren Priority empfangen wird der Port in den Inconsistend State gesetzt was vergleichbar mit Blocking bzw Discard ist. Kein Traffic wir mehr geforwardet und eine SNMP und Syslog Message generiert. . No further traffic is forwarded on this port. So wird verhindert das falsch oder fehlkonfigurierte Switches Root Ports kapern können.
Kommen an solchen RG Ports keine BPDUs mehr geht der Port sofort wieder in den Learning und Forwarding State.
Es ist also sehr sinnvoll Root Guard auf den Root Uplink Ports zu aktivieren um hier Sicherheit zu erlangen.
Also stelle ich den Root Guard an allen Ports auf enabled am RootSwitch (core), an denen die AccessSwitch angeschlossen sind, richtig?

Das ist gut möglich. Deshalb definiert man m 802.1w STP Edge Ports im RSTP ja auch immer als Edge Ports dann haben Port Changes an diesen Ports keinerlei Topo Changes zur Folge. Das ist also ein zwingendes ToDo mit dem Kommando: Admin Edge Port
Am CoreSwitch sind nur AccessSwitche & Server angeschlossen -> daher betrifft mich das am Core (root) ja nicht. Dies müsste ich ja an den AccessPorts vornehmen

Ist dieses Netz dann physisch vollkommen getrennt ??
Wenn ja kann es ja so oder so niemals eine RSTP Wechselwirkung geben.
Wenn nein dann schon. Ist also die Frage wie "getrennt" genau gemeint ist ?!
Meist ist es so, dass es einen InudstriePC gibt mit 2 LAN Schnittstellen. 1 Schnittstelle im Firmennetz, 2. Schnittstelle geht direkt an die Maschine. Somit Physisch getrennt. Die Schnittstellen sind niemals gebrückt.
Bitte warten ..
Mitglied: tech-flare
18.02.2020, aktualisiert um 23:38 Uhr
Aslo evtl. bin ich ein Stück weiter....

Wir setzen seit dem Sommer 2019 im ganzen Gelände Alcatel-Lucent 8378 DECT IP-xBS DECT IP Repeater ein. Kein Typisches VOIP. Nur die DECT Repeater sind VOIP und alle Geräte sind über DECT angebunden.

Aber jetzt kommt der gemeinsame Nenner...An allen AccessSwitchen, an denen ein Alcatel-Lucent 8378 DECT IP-xBS Repeater angeschlossenist, findet regelmäßig ein Topo Change statt. Manchmal steckt an einem 48 Port Switch auch nur ein Repeater.

Ich habe heute versuchweiße an dem Port direkt am Switch LLDP-MED und RTSP deaktiviert.....und siehe da....der Switch hat seit 16 Stunden keinen Topo Change...LLDP verhindert ja auch Schleifenbildung, Richtig? Ist das kompatible zu RTSP? Liegt da der Hase begraben?

Benötige ich zwingend LLDP-MED, wenn ich keine reinen VOIP Telefone einsetze?

Hier das Datenblatt für den Repeater https://www.al-enterprise.com/-/media/assets/internet/documents/8378-dec ...">https://www.al-enterprise.com/-/media/assets/internet/documents/8378-dec ...

Hier ein Auszug vom Switch mit LLDP


Hier ohne LLDP am Port

Man sieh, es finden viel weniger Topo Changes statt.

Weiter oben hat ja bereits jemand erwähnt, dass LLDP Probleme verursachen kann. @aqui....hast du da Erfahrungen oder Infos?

Ps.: Der Port für die VOIP DECT Repeater wird per 802.1 x mac auth untagged für das VOIP zugeordnet. Alternativ wäre eine statische VLAN Zuordnung für den Port möglich
Bitte warten ..
Mitglied: IT-Prof
19.02.2020 um 09:06 Uhr
Ich hatte ja schon Mal erwähnt, dass LLDP aus der Masse zu nehmen.
Ich erlebe es nicht so selten, dass LLDP Buggy ist. Irgendwie ist das auch mehr geworden über die letzten Jahre.

Für mich wären jetzt die Fragen:

Müssen die DECT-Basen LLDP haben?
Ist es eine grundsätzliche und beidseitige Inkompatibilität oder eine einseitige einer Hardware.

Ich würde LLDP-MED bestenfalls für ein VoIP Phone aktivieren. Für die APs vermutlich nicht, wenn Alcatel nicht gute Gründe liefert.

Mein Chef 2008 und Telekom-Lebenslauf, Zitat: Keine dummen Frauen und nichts was Franzosen bauen.

Er hat nur Panasonic PBX gemacht und Alcatel hat ihm gleich Pickel am Arsch verschafft. War immer sehr lustig.
Bitte warten ..
Mitglied: tech-flare
19.02.2020 um 11:27 Uhr
Zitat von IT-Prof:

Ich hatte ja schon Mal erwähnt, dass LLDP aus der Masse zu nehmen.
Ich erlebe es nicht so selten, dass LLDP Buggy ist. Irgendwie ist das auch mehr geworden über die letzten Jahre.

ja eben...das habe ich ja nochml erwähnt.....danke dir dahingehend schon mal. ich kann mir nur noch nicht erklären wie das ganze Zusammenhängen kann....Aber LLDP-MED baut j auch eine Topologie auf

Für mich wären jetzt die Fragen:

Müssen die DECT-Basen LLDP haben?
Ist es eine grundsätzliche und beidseitige Inkompatibilität oder eine einseitige einer Hardware.
Gute Frage....Ich kann ja dasn VOIP VLAN für die DECT IP Basen auch statisch zuordnen.

Ich würde LLDP-MED bestenfalls für ein VoIP Phone aktivieren. Für die APs vermutlich nicht, wenn Alcatel nicht gute Gründe liefert.
>VOIP Phones haben wir nicht. Nur die DECT Basen gehen über VOIP.


Mein Chef 2008 und Telekom-Lebenslauf, Zitat: Keine dummen Frauen und nichts was Franzosen bauen.
das sehe ich mittlerweile auch so
Bitte warten ..
Mitglied: IT-Prof
19.02.2020 um 11:47 Uhr
Frage Mal den Händler oder Alcatel was der Mehrwert sein soll für die DECT-Basen und LLDP-MED.
Mir persönlich wäre das nicht wichtig.

Gibt es einen Grund, das VoIP LAN nicht statische zugeordnet zu haben? In dem Umfeld und der Geräteklasse fällt mir spontan kein Grund ein.

Ansonsten muss ich feststellen, dass ich schmerzhafte Erinnerungen an LLDP Inbetriebnahmen habe.
Bitte warten ..
Mitglied: tech-flare
19.02.2020 um 12:07 Uhr
Zitat von IT-Prof:

Frage Mal den Händler oder Alcatel was der Mehrwert sein soll für die DECT-Basen und LLDP-MED.
Mir persönlich wäre das nicht wichtig.
kann ich machen, aber von Alcatel direkt kommt da sicherlich nichts

Gibt es einen Grund, das VoIP LAN nicht statische zugeordnet zu haben? In dem Umfeld und der Geräteklasse fällt mir spontan kein Grund ein.
Also mit statisch meinte ich den Port auf VOIP VLAN untagged setzen.
Da ich hier ein NAC habe, setze ich die Ports dynmissch nach MAC Auth. E

Ansonsten muss ich feststellen, dass ich schmerzhafte Erinnerungen an LLDP Inbetriebnahmen habe.
gut zu wissen
Bitte warten ..
Mitglied: tech-flare
20.02.2020 um 20:00 Uhr
Ansonsten muss ich feststellen, dass ich schmerzhafte Erinnerungen an LLDP Inbetriebnahmen habe.
LLDP-MED wurde gestern abgestellt, doch leider keine Besserung
Bitte warten ..
Mitglied: tech-flare
20.02.2020, aktualisiert um 20:09 Uhr
Aber vielleicht aqui oder wer auch anders eine Idee?

Ich hab ja die Vermutung, dass die IndustriePC oder ein anderes Gerät evtl. schuld sind. KAnn das sein, dass die ein TC auslösen, wenn diese angeschalten werden? Die haben immer 2 Netzwerkkarten...aber zu 90 % ist nur eine am Netz......
Bitte warten ..
Mitglied: IT-Prof
LÖSUNG 20.02.2020 um 21:01 Uhr
Ja, ist möglich. Unwahrscheinlich aber möglich.

In Industrieumgebung musst Du mit sowas rechnen.
Bitte warten ..
Mitglied: tech-flare
08.03.2020 um 13:52 Uhr
So Leute.....erstmal danke für die ganzen Hilfen von euch.

Die Verursacher sind die kleinen 8 Port Switche, welche manchmal an einzeln Ports angeschlossen sind.

Beispiel:

48 Port Switch Produktion, 1 Leitung geht zum Arbeitsplatz -> 8 Port Switch -> PC; Maschine; Etikettendrucker

Schleife kann dort ausgeschlossen werden.

Die 8 Port Switche laufen auch mit RSTP; Priority 53248


Wenn ich beim 48Port Switch am Downlink Port zum 8 Port Spanning Tree deaktivere ist Ruhe und keine TopoChanges.

Derzeit gibt es für die Switche eine neue Firmware, ich werde die jetzt mal testen.

Somit ist das Thema gelöst bzw der Verursacher gefunden
Bitte warten ..
Mitglied: aqui
08.03.2020 um 15:04 Uhr
Schleife kann dort ausgeschlossen werden.
So so... Und wie schliesst du dann sicher aus das der Azubi einfach mal versehntlich ein Patchkabel am 8 Poert Switch wieder in den Switch steckt ? Sowas bleibt permanent unsicher, denn gegen solche Loops hilft dir nichtmal Spanning Tree sondern nur eine Port Loop Detection sofern den Core Switch sowas überhaupt supportet ?!
Die 8 Port Switche laufen auch mit RSTP; Priority 53248
Sehr merkwürdige Priority und absolut unüblich. Üblich ist der Default Wert von 32.768 ! Auch vor dem Hinblick das die RSTP Priority immer nur modulo 4096 sein kann ist dieser Wert vollkommen falsch und technisch völlig unsinnig. Vermutlich billigste China Hardware unterster Kategorie aber egal.
Sinnvoll ist diesen den Priority Default Wert von 32768 zu geben und einzig nur den Core Switches 4096 oder 8192 (Root und Backup Root) um so einen saubere Spanning Tree Hierarchie zu gewährleisten !
Kein Wunder also das dieser Schrott mit den völlig irren RSTP Settings dir da Chaos schafft.
Kann man nur hoffen das eine neue Firmware da Abhilfe schafft.
Wenn allerdings einen Frimware schon an solchen banalen Basics scheitert sollte dir das erheblich zu denken geben ob du dort die richtige Hardware im Einsatz hast !
Beachte auch das manche Premium Hersteller PVRSTP oder PVRSTP+ per Default machen. Das ist inkompatibel zu Single Span RSTP dieser Billigswitches !
Bitte warten ..
Mitglied: tech-flare
09.03.2020 um 12:19 Uhr
So so... Und wie schliesst du dann sicher aus das der Azubi einfach mal versehntlich ein Patchkabel am 8 Poert Switch wieder in den Switch steckt ? Sowas bleibt permanent unsicher, denn gegen solche Loops hilft dir nichtmal Spanning Tree sondern nur eine Port Loop Detection sofern den Core Switch sowas überhaupt supportet ?!
Nein nicht falsch verstehen...ich meinte nicht, dass das grundsätzlich ausgeschlosseb werden. Das war nur meine Aussage zum Zeitpunkt der Prüfung, als das Problem aufgetreten ist . Verstehst du?

Die 8 Port Switche laufen auch mit RSTP; Priority 53248
Sehr merkwürdige Priority und absolut unüblich. Üblich ist der Default Wert von 32.768 ! Auch vor dem Hinblick das die RSTP Priority immer nur modulo 4096 sein kann ist dieser Wert vollkommen falsch und technisch völlig unsinnig. Vermutlich billigste China Hardware unterster Kategorie aber egal.
Sinnvoll ist diesen den Priority Default Wert von 32768 zu geben und einzig nur den Core Switches 4096 oder 8192 (Root und Backup Root) um so einen saubere Spanning Tree Hierarchie zu gewährleisten !
Kein Wunder also das dieser Schrott mit den völlig irren RSTP Settings dir da Chaos schafft.
Kann man nur hoffen das eine neue Firmware da Abhilfe schafft.
Wenn allerdings einen Frimware schon an solchen banalen Basics scheitert sollte dir das erheblich zu denken geben ob du dort die richtige Hardware im Einsatz hast !
Beachte auch das manche Premium Hersteller PVRSTP oder PVRSTP+ per Default machen. Das ist inkompatibel zu Single Span RSTP dieser Billigswitches !

Ja das sind 8 Port Billiggurken von D-Link. Ich werde die jetzte ersetzen bzw. nur noch zusätzliche Leitung ziehen lassen, sodass die Geräte direkt an den 48 Port gehen.

Aber Priority 53248 ist Modulo 4096 ;). 53248/4096 = 13 ;). Nichtdestotrotz ist das Teil nicht besonders schön
Bitte warten ..
Mitglied: aqui
LÖSUNG 09.03.2020 um 15:51 Uhr
Verstehst du?
Jupp, verstanden !
Aber Priority 53248 ist Modulo 4096
Nee, das ist binär ! Guckst du hier:
stp-prio - Klicke auf das Bild, um es zu vergrößern
Die Priority sind nur die höheren 4 Bit der 2 System ID Bytes.
Bitte warten ..
Mitglied: tech-flare
09.03.2020 um 18:14 Uhr
Nee, das ist binär ! Guckst du hier:
stp-prio - Klicke auf das Bild, um es zu vergrößern
Die Priority sind nur die höheren 4 Bit der 2 System ID Bytes.
Ok da habe ich das etwas durcheinander geworfen
Asche auf mein Haupt. Aber dafür seid ihr ja da... zum lernen und helfen ;)
Bitte warten ..
Ähnliche Inhalte
LAN, WAN, Wireless

MSTP ohne VLAN-Instanzen oder Umkonfiguration Spanning Tree von MSTP zu RSTP möglich?

gelöst Frage von diemilzLAN, WAN, Wireless5 Kommentare

Hallo zusammen, in unserem Netzwerk, bestehend aus HP/Aruba-Switchen der Typen 5406r zl2 (3 Stück), 5412r zl2 (einer), E3800-48G (insgesamt ...

Netzwerkgrundlagen

VLANs mit RSTP

gelöst Frage von Alex29Netzwerkgrundlagen15 Kommentare

Hallo zusammen, ich bin kein gelernter Netzwerktechniker arbeite mich aber im Selbststudium vor. Aktuell möchte ich mein vorhandenes Netzwerk ...

Netzwerkgrundlagen

RSTP HP 2510-24

gelöst Frage von deredvtypNetzwerkgrundlagen17 Kommentare

Hallo liebe Administratoren und Supporter, ich möchte auf einem HP 2510-24 (mir persönlich wäre Cisco lieber gewesen aber so ...

Netzwerkgrundlagen

Spanning Tree Designated Ports

Frage von Sven91Netzwerkgrundlagen2 Kommentare

Hallo Community, ich, Azubi, benötige einen kleinen Denkanstoß. Auf einer Skizze über ich grade die Verteilung der Portrollen mit ...

Neue Wissensbeiträge
Monitoring

Unabhängiger Ansatz - IoT (frei von Cloud- oder Appzwang) - Hier mit Schaltsteckdosen

Anleitung von beidermachtvongreyscull vor 1 TagMonitoring2 Kommentare

Tach Kollegen, ich erzähle Euch mal von meiner Ausgangslage und den/m Problem(chen) Ich benutze ein NAS zur Lagerung meiner ...

Microsoft
Microsoft Advanced Threat Protection for Linux
Information von Dani vor 4 TagenMicrosoft

Microsoft Defender Advanced Threat Protection (MD ATP) support for Linux with kernel version 3.10.0-327 or later, including the following ...

Humor (lol)
! ! Today ist SysAdmin-Day ! !
Information von VGem-e vor 5 TagenHumor (lol)5 Kommentare

Moin, "Happy Birthday" an alle Systemadministratoren, Mausschubser, System-/EDV-Betreuer, SysOps etc!! Siehe auch. Edit (Video hinzugefügt): Gruß VGem-e

Exchange Server
Basic Authentication and Exchange Online
Information von Dani vor 7 TagenExchange Server

Today we are pleased to announce some new changes to Modern Authentication controls in the Microsoft 365 Admin Center, ...

Heiß diskutierte Inhalte
Google Android
Handy gehackt ? - Gegemassnahmen
Frage von hushpuppiesGoogle Android27 Kommentare

Hallo zusammen, folgendes Szenario: Kollegin kommt heute zu mir und erzählt, dass ihre Tochter gestern über WhatsApp von einem ...

Windows Server
Windows-NAS zum sekundären DNS-Server machen?
Frage von DanielG1974Windows Server18 Kommentare

Moin. Wer so ein bissel meine Situation meiner Arbeitsstelle kennt Mein Chef hat immer noch keinen neuen ESXi-Server angeschafft. ...

Hyper-V
Hardware Empfehlung Hyper-V Host
Frage von TraxxTecHyper-V14 Kommentare

Hi, ich habe keine Ahnung was aktuell an Hardware unterwegs ist, deshalb bräuchte ich eine grobe Empfehlung für einen ...

Batch & Shell
Telefonserver remote starten
Frage von imebroBatch & Shell12 Kommentare

Hallo, ich hatte ein ähnliches Problem schon einmal. Damals hatten sich jedoch die Gegebenheiten dann verändert, sodass sich das ...

Weniger Werbung?
Administrator Magazin
07 | 2020 In der Juli-Ausgabe beleuchtet das IT-Administrator Magazin den Themenschwerpunkt "Monitoring & Support". Darin zeigt die Redaktion unter anderem, wie Sie die Leistung von Terminalservern im Blick behalten und welche Neuerungen das Ticketsystem OTRS 8 mitbringt. Auch die Überwachung von USV-Anlagen darf nicht fehlen. In ...