Kopplung per IP-Router oder per TP-Linienkoppler? Best practise

[Gaston]

[QUOTE=saft6luck;202550]Und wie reagiert STP wenn z.B. g19 oder g18 oder g1 oder g2 ausfallen? Und warum?[quote]

Die Kurzfassung ist natürlich dass beim Ausfall von z.B. g19, g1 aus dem blocking state geht und somit wieder ein Pfad zu diesme Router (knx10) besteht.

das ist Standard STP, da g1 an switch02 keine STP-Pakete (BPDU) von switch01 erhält wird ein anderer Weg im Baum gewählt.

Wenn z,B, vorhet knx2 und knx10 miteinander "gsprochen haben" so lief die Kommunikation über switch21 und switch01. jetzt ist der Weg dann switch21, switch01 und switch02, da switch01 mein root-switch ist

Nebenbei erscheint mir dieser Aufwand (Geräte, Strom, Verkabelung etc.) doch in keinem Verhältnis zu einer direkten Verbindung aller Router zu stehen, selbst für etwas größere EFH-Anlagen.

Meine Anlage soll ja keine Referenz sein für den minimalen Aufwand den man machen muss . Wie gesagt, 2 switches mit RSTP reichen ja aus.

So gross ist der Aufwand nicht. Wenn es am Aufwand liegt dann würde man auch kein KNX machen, sondern konventionel

Mit 2 switches ohne VLAN beschränkt sich die Konfiguration eigentlich auf das Einschalten von RSTP. Auch bei mehr switches wie bei mir ginge es auch so, solange es keine VLANs gibt.

Von 6 Switches an aufwärts fängt es dann an dass der Profi optimieren kann. Mit den KNX/IP-Routern gibt es auch optimierungspotential. Erst mit VLANs wird es komplizierter da man hier entweder auf MST ("VLAN-STP") switchen muss oder mit (R)STP richtig konfigurieren muss.

Gruss,
Gaston

[saft6luck]

Die Kurzfassung ist natürlich dass beim Ausfall von z.B. g19, g1 aus dem blocking state geht und somit wieder ein Pfad zu diesme Router (knx10) besteht.

das ist Standard STP, da g1 an switch02 keine STP-Pakete (BPDU) von switch01 erhält wird ein anderer Weg im Baum gewählt.

Wenn z,B, vorhet knx2 und knx10 miteinander "gsprochen haben" so lief die Kommunikation über switch21 und switch01. jetzt ist der Weg dann switch21, switch01 und switch02, da switch01 mein root-switch ist

Beispiel g19 fällt aus:

- für STP besteht von g22 nach g14 (grün) eine Verbindung -> BPDUs gehen durch
-> g19 wird nicht überwacht, denn für den Switch01 ist die Verbindung g19 deaktiviert -> BPDUs werden nicht verschickt, da ja für den STP-Switch kein Empfänger in diesem Segment mehr vorhanden, denn er sieht die Router-Switches nicht.
-> fällt g19 aus -> g22 nach g14 existiert immer noch
-> keine Reaktion aus Sicht von STP notwendig
-> Keine Aktivierung anderer Strecken.
-> q.e.d

Mit 2 switches ohne VLAN beschränkt sich die Konfiguration eigentlich auf das Einschalten von RSTP. Auch bei mehr switches wie bei mir ginge es auch so, solange es keine VLANs gibt.

Damit es bei dir (mit VLANs) geht brauchst du sowieso MSTP.

[Gaston]

Beispiel g19 fällt aus:

Mir ist nicht ganz klar ob deine Aussage eine Behauptung oder eine Frage sein soll. Fragen beantworte Ich gern:

- für STP besteht von g22 nach g14 (grün) eine Verbindung -> BPDUs gehen durch

Ja, "grün" bedeutet per legende dass es ein "root path ist" also der beste Weg zum root-switch und in beide Richtungen offen.

-> g19 wird nicht überwacht, denn für den Switch01 ist die Verbindung g19 deaktiviert -> BPDUs werden nicht verschickt, da ja für den STP-Switch kein Empfänger in diesem Segment mehr vorhanden, denn er sieht die Router-Switches nicht.

Ohne Defekt:

g19 ist ein designated port (blau) und somit sehr wohl aktiv. Über diesen Port werden alle Pakete weitergeleitet inklusive BPDU.

Jede Verbindung zwischen zwei STP Switches ist technisch in der STP Spezifikation ein Netz (keine Verbindung), und jedes Netz im ST ist aktiv und hat somit zumindts einen aktiven designated port und optional zusätzlich einen aktiven root port. Alle anderen Ports sind "blocked" (non-designated).

Alle Ports im root server sind designated ports und somit aktiv.

-> fällt g19 aus -> g22 nach g14 existiert immer noch

Klar

-> keine Reaktion aus Sicht von STP notwendig

Das ist deine Theorie, nicht die STP Spezifikation !

Natürlich ist aus Sicht des STP etwas zu tun denn ein Netz ist nun ohne aktive Verbindung.

Vor dem Defekt hat g1 alle Pakete fallen gelassen aber dennoch gemerkt dass welche von g19 ankommen (mindesten BPDUs). Bleiben diese aus wird der designated port (g19) als defekt erkannt und STP wird umkonfiguriert so dass g19 non-designated (blocked) und g1 designated (aktiv) wird..

-> Keine Aktivierung anderer Strecken.

Ja, keine Strecken, nur Ports

-> q.e.d

Das was Du Bewiesen hat ist dass Du dich mit den Grundprinzipien bon STP etwas auskennst aber ncicht mit dem ganzen Protokol und seiner Theorie.

Damit es bei dir (mit VLANs) geht brauchst du sowieso MSTP.

Komplett falsch. Man benötige für STP mit VLANs weder praktisch noch theoretisch unbedingt MSTP (o.ä.). MSTP dient der "nur" Optimierung des STP in VLANs.

Fragen werden weiterhin gerne beantwortet, bei Behauptungen solltest du die Spezifikationen erst einmal genau studieren, wobei STp eine der kompexesten Spezifikationen im Netzwerkbereich ist. Deshalb wird die Darstellung davon oft vereinfacht was dann bei komplexeren Anlagen zu Fehleinschätzungen führt.

Gruss,
Gaston

[saft6luck]

Das ist deine Theorie, nicht die STP Spezifikation !

Das ist wohl der Punkt, du behauptest, die Spec. zu kennen, ich sage, es ist anders und dann kommst du und behauptest wieder die Spec. zu kennen.

Zeig mir den Punkt in der STP Spec. der die Überwachung inaktiver Links bzw. von aktiven Endgeräten vorsieht. Ich kenne kein solches Requirement im STP.

Man stelle sich vor, ein Netz überwacht ständig alle inaktiven Pfade oder organisiert sich neu, wenn ein Endgerät (z.B. Laptop) abgesteckt wird.

[Gaston]

Man stelle sich vor, ein Netz überwacht ständig alle inaktiven Pfade oder organisiert sich neu, wenn ein Endgerät (z.B. Laptop) abgesteckt wird.

Oh Mein Gott ! Es ist ja noch viel schlimmer als Ich dachte.

Wenn ein Endgerät das an einem STP Switch angeschlossen ist, so ist sein port ein Edge-Port und hat somit mit der rekonfiguration der STP topologie nix am Hut.

Wenn Du das Protokol kennen würdest dann wüsstest Du auch dass der Grund aus dem ein angeschlossenes Laptop an einem STP Switch an dem alle Ports STP-Enabled sind überhaupt Zugang zum Netz bekommt genau der gleiche Mechanismus ist der zum Failover in meinem Beispiel führt ! Du widerspricht Dir also selbst.

Es gibt aus Netzwerk sicht keinen Unterschied ob da direkt ein laptop angeschlosen ist oder eine Verbindung zu einem weiteren STP Switch mit einem KNX/IP-Router in der Mitte und einem defekten Switch port.

Das ein-und ausstöplseln des Kabels (also port up/down) ist für STP irrelevant.

Zeig mir den Punkt in der STP Spec. der die Überwachung inaktiver Links bzw. von aktiven Endgeräten vorsieht. Ich kenne kein solches Requirement im STP.

Das Wundert mich nicht denn die Spezifikationen kannst Du nicht reinmal im Ansatz kennen ansonsten wüsstest Du dass da da gar nicht so stehen kann ! Das sind Standard-Spezifikationen keine Waschmaschinenanleitung !

Aber Ich bin gerne bereit die eine Protokolanalyse auf diene Fall zu erstellen mit allen nötigen Referenzen auf die 802.1D Spzifikationen wenn Du mir mein stündliches Beraterhonorar defür zahlst . Ansonsten Verweise Ich auf Kapitel 17 RSTP und dort u,a, auf die state machines (17.15++).

Ansonsten gibt es bei Cisco genügend Beispiele die den designated Port erläutern.

Zusätzlich habe Ich zwei Bilder des Management Interfaces meiner Switches (01 & 02) angehängt aus denen, wie erwartet, hervorgeht dass g1 blocking ist und g19 nicht.

Dann hab Ich noch einen Simulator gefunden: SA: LAN Bridge Spanning Tree Animation

Als Anhang findest Du eine zip Datei mit einer XML Datei meiner Konfiguration die du in den Simulator laden kannst:

1. File->Open
2. Simulation->Start
3. Da STP verwendet wird den Schieber oben hochdrehen um das ganze zu beschleunigen

Du siehst nun Gelb die BPDUs(gelb) und siehst welche Posrt blockieren (rot) und welche nicht (grün), nach der "learning" Phase (blau).

Switch01 wäre hier "00", switch02 "01". Root ist "00". Switch IDs und Ports wurden so gewählt dass es meiner Konfiguration entspricht.

Du kannst einen Host (kleine Kästchen), sprich KNX/IP Router anwählen und Packete versenden (rot).

Nun schalten wir Port 3 an switch 00 (also g19 an switch01) aus (defekt):

Switch anwählen und Port 3 abwählen (->disabled)...ud schauen was passiert.

Naja, mag sein dass der Typ eder das geschrieben hat genau so wenig Ahnung hat wie Ich, und das gleiche trifft dann auf seinen Uni-Professor zu der das so abgenommen hat, aber auf jedenfall habe Ich meine Beweispflicht getan. Nun bist Du dran !

[Gaston]

LOL, das Beste hat Ich ja noch glatt übersehen:

-> g19 wird nicht überwacht, denn für den Switch01 ist die Verbindung g19 deaktiviert -> BPDUs werden nicht verschickt, da ja für den STP-Switch kein Empfänger in diesem Segment mehr vorhanden, denn er sieht die Router-Switches nicht.

Ich sage ja immer dass etwas was funktioniert kein Beweis ist dass es richtig ist, aber da behauptest Du doch glatt das das was bei mir seit Monaten funktioniert gar nicht gehen kann.

Ausserdem schaut das STP Protokol (und darf das auch nicht) ob da ein Empfänger ist oder nicht.

[saft6luck]

Oh Mein Gott ! Es ist ja noch viel schlimmer als Ich dachte.

Ich hatte dich bereits darauf hingewiesen, deine arrogante, herablassende Art zu lassen! Wenn du meinst der einzige Einäugige unter Blinden zu sein gibt dir das noch lange nicht das Recht ausfallend zu werden. Ansonsten werde ich dich auch entsprechend abwertend behandeln, Beispiel folgt, man möge mir verzeihen.

Wenn ein Endgerät das an einem STP Switch angeschlossen ist, so ist sein port ein Edge-Port und hat somit mit der rekonfiguration der STP topologie nix am Hut.

Wenn Du das Protokol kennen würdest dann wüsstest Du auch dass der Grund aus dem ein angeschlossenes Laptop an einem STP Switch an dem alle Ports STP-Enabled sind überhaupt Zugang zum Netz bekommt genau der gleiche Mechanismus ist der zum Failover in meinem Beispiel führt ! Du widerspricht Dir also selbst.

Es gibt aus Netzwerk sicht keinen Unterschied ob da direkt ein laptop angeschlosen ist oder eine Verbindung zu einem weiteren STP Switch mit einem KNX/IP-Router in der Mitte und einem defekten Switch port.

Das ein-und ausstöplseln des Kabels (also port up/down) ist für STP irrelevant.

Du bist so einfach gestrickt, dass dir nicht einmal auffällt, dass ich genau das sage: wenn der KNX/IP-Router keine Verbindung mehr hat wird STP nichts daran ändern, da es für STP irrelevant ist.

Schenkelklopfer!

Das sind Standard-Spezifikationen keine Waschmaschinenanleitung !

Genauso wie du versuche ich das Thema verständlich zu halten. Standard-Spezifikationen sind aber nicht per Definition unverständlich, viel mehr versuchen gute Spezifizieren genau das, wie eine Waschanleitung verständlich zu sein.

Ansonsten Verweise Ich auf Kapitel 17 RSTP und dort u,a, auf die state machines (17.15++).

Hm, RFC, IEEE, ISO? In der IEEE 802.1D-2004, die ich grad da hab find ich das nicht (ist RSTP).

[..]
Switch anwählen und Port 3 abwählen (->disabled)...ud schauen was passiert.

Vielen Dank für die Mühe. Dann schau ich mir deine Konfiguration und den Simulator mal an. Ist denn das "disable" eines Portes wirklich gleichbedeutend mit einem defekten Link?

[saft6luck]

Ausserdem schaut das STP Protokol (und darf das auch nicht) ob da ein Empfänger ist oder nicht.

Schon wieder so ein 100% korrekter Satz, der nur mit viel Phantasie verständlich wird?

[Gaston]

Ich hatte dich bereits darauf hingewiesen, deine arrogante, herablassende Art zu lassen!

Muttu, nicht gleich weinen. Du hattest mit "Ho, ho, du machst mir Angst!" auch nicht schlecht vorgelegt.

Wenn du meinst der einzige Einäugige unter Blinden zu sein gibt dir das noch lange nicht das Recht ausfallend zu werden.

Ok, zumindest eine Einsicht dass Du blind bist

Du bist so einfach gestrickt, dass dir nicht einmal auffällt, dass ich genau das sage: wenn der KNX/IP-Router keine Verbindung mehr hat wird STP nichts daran ändern, da es für STP irrelevant ist.

Schenkelklopfer!

Häh ? Verstehst Du eigentlich selbst was Du schreibst ? Das versteht jeder hier dass wenn man beide Kabel vom Router entfernt keine Verbindung mehr bestehen kann, aber erst dann !!!!!

Mal davon ausgehend dass Du nicht das meinst liegst Du eben falsch und machst hier den klassischen Anfängerfehler bei STP,und siehst Verbindungen zwischen 2 STP switches als reine Verbindung, das ist aber nicht derr FALL, und da wiederhole Ich mich gern: Das sind Netzwerke für STP, und STP hat immer eine Verbindung zu all seinen Netzwerken offen.

Fazit: Verbindung zum Router ist erst dann weg wenn beide Ports defekt sind, bzw Kabel weg sind oder Router tot.

Ich bin also einfach gestrickt weil Ich deinen Fehler erkannt habe, und du nicht, da Du Ihn zur Rechtfertigung wiederholst. Cool

Hm, RFC, IEEE, ISO? In der IEEE 802.1D-2004, die ich grad da hab find ich das nicht (ist RSTP).

Du hast eine 802.1D-2004 ohne Kapitel 17 RSTP ?????

Vielen Dank für die Mühe. Dann schau ich mir deine Konfiguration und den Simulator mal an. Ist denn das "disable" eines Portes wirklich gleichbedeutend mit einem defekten Link?

Ui, versöhnliche Töne ! Und das mein Ich jetzt nicht sakarstisch sondern als "Licht am Ende des Tunnels".

Wäre ich nicht wie Ich bin, dann würde Ich einfach "Ja" antworten . Die Realität ist etwas differenzierter.

Im Simulator is disabled=defekt=tot, Ja. Da es hier um die Grundprinzipien des STP geht kann man auch in der Realität ein disableten Port gleichsetzen mit "tot".

Defekte an sich können in seltenen Fällen natürtlich fieser sein als nur "tot". Wenn z.B. an port g19 sehr viele Fehler beim senden auftauchen ist es möglich dass noch genügend BPDUs durchgehen dass g1 nie einen Topologiewechsel einleiten wird.

Gruss,
Gaston

[Gaston]

Ausserdem schaut das STP Protokol nicht (und darf das auch nicht) ob da ein Empfänger ist oder nicht.

Schon wieder so ein 100% korrekter Satz, der nur mit viel Phantasie verständlich wird?

Dieser Satz war die Antwort auf:

"Ausserdem schaut das STP Protokol (und darf das auch nicht) ob da ein Empfänger ist oder nicht."

Aber richtig, da habe Ich beim Editieren wohl ein "nicht" (oben fett eingefügt) in die Klammer "verschluckt". Ich hoffe nun ist es klar.

[saft6luck]

[.. unsäglich viel ??? gelöscht ..]

Du kannst es nicht lassen, mit dir zu argumentieren ist einfach nicht zielführend, ufert ins Unsachliche aus und bringt nichts. Zudem ist mir deine Lösung, erst recht nach der detaillierten Darstellung, weitere Argumentationen nicht mehr wert.

Meine Ignorier-Liste ist um einen Nutzer reicher.

[Gaston]

Dabei sah es so vielverspechend am Ende aus...

Zum Protokol:

Nach deinen eigenen Aussagen haben wir beide nur Behauptungen aufgestellt, und Du hast Beweise gefordert. Diese hast Du erhalten, woraufhin Du nur weiter Behauptungen aufgestellt hast ohne Beweise die Du so gerne von anderen forderts.

Wen wundert's denn das was Du sagst dass nicht so funktioniert wie ich es "behaupte" das:

1. Funktioniert bei mir seit Monaten
2. Habe Ich mit Screenshots meiner switches belegt
3. Wird durch einen STP-Simulator der als Masterarbeit erstellt wurde bestätigt
4. Wird durch Grafiken bestätigt (z.B. Wikipedia, eins der wenigen Beispiele die nicht so weit vereinfacht sind dass man die Netwerke nicht mehr wahrnimmt)

An Sachlichkeit hast Du diesen Fakten nichts engegengestellt und Ich bin mir sicher dass es Dir spätestens beim Simulator klar geworden sein muss dass Du auf dem falschen Dampfer wars deshalb wohl dieser Rückzieher.

Wenn Ich dafür auf eine Ignorliste komme dann kratzt das mich sehr wenig, denn das erspart mir dann in der Zukunft ja diese sinnlosen Diskussionen

[Gaston]

Ich krame diesen alten Thread mal wieder hervor falls jemand das hier liest und sich für STP interessiert und sich durch die unsinnige Diskussion verunsichert fühlt.

Ich musste vor kurzem beruflich das Spannning-Tree erläutern und hatte dabei Zugriff auf den Simulator "Cisco Paket Tracer". Ich habe davon profitiert meine Anlage für dieses Forum zu simulieren.

Im Angang die Cisco Simulation meiner Anlage, wie die Zeichnung in einem der alten Beitäge. Im ersten Bild sieht man die den Status kurz nach dem hochfahren aller Komponenten.

Bei den Gira KNX/IP Routern (mit 2-fach switch) wurde das Spanning-Tree in der Simulation ausgeschaltet da diese keins können. deshalb sind auch doe Ports dieser Switche so wie der Port des Computers alle schon grün (sprich funktional) da sie kein STP kennen.

Alle anderen Ports sind im blocking/discarding mode (orange). Das heist sie senden und empfangen keine Pakete ausser den STP eigenen BPDUs. Über diese BPDUs wird dann zuerst ein Root-Switch ausgesucht was derjenige mit der niedrigsten Priorität ist und bei gleicher Priorität der kleinsten MAC Adresse. Bei mir ist Switch01 per Priorität der root Switch.

Nachdem die Switches über die BPDUs damit begonnen haben einen Baum aufzubauen schalten sie die Ports entsprechend dieses Baums durch (grün/forwarding). Bild 2 zeigt die Simulation bei voll aufgebautem Baum. Der root Switch (switch01) ist i.d.R. dadurch gekennzeichnet dass all seine Ports "forwarding" sind, aber auch andere Switches können alle Ports offen haben (z.B. switch24 hier).

Die "dummen" KNX switches interessieren STP überhaut nicht da sie einfach nur die BPDUs wie andere Pakete weiterleiten. Für die STP Switches sind sie somit transparent. Allerdings wie sehr schön zu sehen ist in jedem Segment immer eine Seite forwarding dies weil die Switches eben nicht wissen ob da andere "dumme" Geräte auf dem Segment sind.

In den meisten Grafiken zum Thema STP sind die Verbindungen zwischen Switches immer als Point-to-Point gezeichnet was meistens zur falschen Annahme dass eine solche "Verbindung" entweder offen oder zu ist. In Wirklichkeit sind dies aber laut Spezifikation Segmente und müssen auf einer Seite offen sein um deren Funktion zu gewährleisten.

Aus diesem Grund muss man STP auch nicht einzeln per Port ein oder ausschalten es kann an allen Ports an bleiben. Dies ist auch default mässig der Fall da nur diese Konfiguration eine sichere Funktion in allen Konfigurationen gewährleistet. Wie man in der ersten Grafik sehen kann ist z.B. der Port zum PC im STP discarding Modus, aslo mit aktiviertem STP und der PC kann natürlich kein STP. Der Switch öffnet nach einer kurzen Zeit diesen Port da er keine BPDUs hier empfängt und somit davon aus geht dass hier auch keine Schleife sein kann/darf.

Würde jetzt switch01 ausfallen dann wäre für die KNX Switche (mit dem KNX router) 01 & 10 nicht anders als vorher für den PC. switch02 würde keine BPDUs mehr empfangen und somit diesen Port seine Ports in den forwarding Modus schalten (Bild3). Da jetzt auch keine offene Verbindung zu switch21 existiert öfnnet 21 seine Ports zu diesem Switch. switch21 setzt von diesen 3, 2 stück auf discarding da er jetzt am weitesten vom root entfernt ist.

In Bild4 noch das in einem Beitrag genannte Beispiel eines Port-Ausfalls zu einem der KNX switches (hier die Verbindung switch24 - KNX2). Auch dieser Fall ist "untechnisch" betrachtet nichts anderes als der Anschluss eines PCs an eine Switchport. Switch 22 erhält auf diesem Segment nun keine BPDUs mehr und schaltet den Port auf forwarding (grün).

STP vs RSTP

Bei STP schickt nur der rot Switch BPDUs was das Netzwerk weniger belastet benötigt deshalb aber länger um seine Entscheidungen zu treffen (bis hin zu mehreren Minuten). Beim Start denkt jeder Switch er sei root und sendet somit erst mal BPDUs weshalb das einfügen eines Switches kein Problem ist. Bei RSTP senden alle Switches BPDUs was eine sehr viel schnellere Entscheidung im Fehlerfall erlaubt.

MSTP

Wenn man VLANs verwendet muss man mit STP gut aufpassen nicht dass es beim umschalten dazu führen kann dass ein Weg ausgesucht wird auf dem ein oder mehrere VLANs nicht vertreten sind. Somit wären diese VLANs nämlich abgeschnitten. In meinem Fall habe Ich dies über die Prioritäten sichergestellt die Ich auch dazu verwendet habe den Traffic zu "shapen".

Es stehen aber auch spezielle STP Varianten, wie MSTP oder PVST (Cisco), zur Verfügung die dies automatisch machen indem sie einen STP Baum per VLAN erstellen.


P.S.: Die Simulation zeigt im normalen Zustand (Bild2) nicht genau den von mir gezeichneten Zustand so wie er hier bei uns ist. Dies liegt daran dass ich bei uns die Port-Costs so angepasst habe dass das die KNX Segmente nicht durch inter-switch Traffic belastet werden und diese lediglich als failover für KNX dienen. So läuft in der Simulation z.B. der Traffic von switch01 zu switch02 und switch22 über KNX1. Bei mir ist da die direkte Verbindung prioritisiert.

Ich hoffe jetzt sind alle Klarheiten beseitigt

Gruss,
Gaston