Packetloss bei Multicast Paketen mehrere Router mit RSTP-Bridges
Hallo!
Folgendes Szenario: ich habe 3 Router CRS112, die im Ring miteinander verbunden sind. (R1->R2->R3->R1)
Die entsprechenden Ports liegen jeweils auf einer Bridge. Dort ist jeweils das RSTP Protokoll aktiviert. So weit so gut, es scheint für Unicast alles ganz gut zu klappen. Nun verursachen die angeschlossenen Geräte aber Multicast Traffic. Je nach Belastung tauchen nun in den Logs der Mikrotik Router folgende Einträge auf:
interface, warning: sfp01: bridge port received packet with own address as source address (01:02:03:04:05:06), probably loop
in blau
Zusätzlich scheinen einige Multicast Pakete irgendwo im Nirvana verschunden zu sein. Die einzelnen Strecken werden selbstverständlich im betrachteten Zeitraum nicht verändert. RSTP musste also nicht umrouten!
Hat Jemand ein ähnliches Problem und evtl. eine Lösung?
Vielen Dank!
Folgendes Szenario: ich habe 3 Router CRS112, die im Ring miteinander verbunden sind. (R1->R2->R3->R1)
Die entsprechenden Ports liegen jeweils auf einer Bridge. Dort ist jeweils das RSTP Protokoll aktiviert. So weit so gut, es scheint für Unicast alles ganz gut zu klappen. Nun verursachen die angeschlossenen Geräte aber Multicast Traffic. Je nach Belastung tauchen nun in den Logs der Mikrotik Router folgende Einträge auf:
interface, warning: sfp01: bridge port received packet with own address as source address (01:02:03:04:05:06), probably loop
in blau
Zusätzlich scheinen einige Multicast Pakete irgendwo im Nirvana verschunden zu sein. Die einzelnen Strecken werden selbstverständlich im betrachteten Zeitraum nicht verändert. RSTP musste also nicht umrouten!
Hat Jemand ein ähnliches Problem und evtl. eine Lösung?
Vielen Dank!
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 316627
Url: https://administrator.de/forum/packetloss-bei-multicast-paketen-mehrere-router-mit-rstp-bridges-316627.html
Ausgedruckt am: 25.04.2025 um 04:04 Uhr
14 Kommentare
Neuester Kommentar
die im Ring miteinander verbunden sind.
Dasi st schon tödlich ! Spanning Tree Protokolle sind generell NICHT für Ring Strukturen gemacht und auch geeignet !Wenn man ein solches Design macht, was per se aus Ethernet Perspektive schon falsch ist, oder machen muss, dann sollte man immer Ring optimierte Redundanz Protokolle nutzen wie REP (Cisco), RRPP (Extreme) oder MRP (Brocade) usw.
Solche Redundanz Protokolle sind auf Ring Strukturen optimiert.
Letztlich ist das auch das grundlegende Problem bei dir bzw. das was du siehst es nur ein Folgeproblem was aus diesem Missdesign resultiert.
Da du deine Multicast Implementation nicht näher beschreibst gehen wir mal davon aus das du kein IGMP Snooping aktiviert hast auf den Switches wie es eigentlich sein sollte.
Dadurch wird der Switch bzw. Router gezwungen die Multicast Pakete auf allen Ports zu fluten und das geschieht nicht über die Port Asics sondern in CPU.
Bei schwachbrüstigen Routern oder Switches wie sie in billigen Consumer Produkten üblich sind, triggert das aber jetzt einen Teufelskreis.
Das Gerät hat soviel CPU Last (Peak) das damit auch das Forwarding der RSTP BPDUs flöten geht oder das Erkennen der BPDUs an diesen Ports. Was sich letztlich dann in der Stabilität des STP zeigt.
Damit denkt der Spanning Tree Prozess dann das der Ring irgendwo offen ist und schaltet die redundanten Ports die vorher im Blocking waren in den Forwarding Mode.
Fatal, denn nun bildet sich ein Loop der im schlimmsten Falle das Netzwerk kollabieren lässt. Es kann aber sein das der STP Prozess sich wieder fängt und einen neu Topologie errechnet die dann wieder die Ports blockt. Das toggelt dann je nach Last wild hin und her.
Das geht dann so lange bis zum nächsten Multicast Peak und das Drama geht von vorn los.
Die Ringstruktur macht das doppelt schlimm, denn Konvergenzzeiten beim STP sind hier horrend höher und können bis in den Minutenbereich gehen.
Dein o.a. Verhalten lässt das ganz klar erkennen, denn das Gerät sieht seine eigenen BPDUs was zu Recht einen Loop anzeigt...und das lässt auf gravierende STP Probleme schliessen.
Fazit:
Wenn du Glück hast kommst du aus der Misere raus wenn du IGMP Snooping aktivierst was ein Muss ist in so einem MC Umfeld ! Das könnte das Verhalten stabilisieren.
Wenn das auch nichts nützt musst du ein Ethernet optimiertes Design verwenden und kein Ring Design was im Ethernet Umfeld nichts zu suchen hat ! Letztlich resultiert der Fehler aus dem falschen Topologie Design bzw. schwacher Hardware.
Musst du zwangsweise einen Ring konstruieren, dann helfen dir nur potente Switches die Ring Protokolle supporten !
Hi,
Gruß,
Peter
Zitat von @aqui:
Bei schwachbrüstigen Routern oder Switches wie sie in billigen Consumer Produkten üblich sind
Hier wird aber wohl der hier verwendet: https://www.mikrotik-store.eu/de/mikrotik-crs112-8g-4s-inBei schwachbrüstigen Routern oder Switches wie sie in billigen Consumer Produkten üblich sind
Gruß,
Peter
Ändert aber nichts an der Problematik. Eher verschlimmert er das, da hier ein Router ja als Switch missbruacht wird für was er gar ncht gemacht ist.
Falsche Hardware....oder falsches Design. Der TO kann sich das aussuchen.
Falsche Hardware....oder falsches Design. Der TO kann sich das aussuchen.
Vielen Dank für die Antworten!
Was ich nicht ganz verstehe: Wieso ist RSTP nicht für eine Ringtopologie ausgelegt? Soweit ich weiß, verhindert RSTP Netzwerk-Loops. Genau das soll es tun, das tut es auch und ist doch für meine Aufgabe genau das Richtige!?
Hier sind nochmals meine Randbedingungen, vielleicht hilft es, wenn ich präziser werde.
Die Router sind nicht "nur" in einem Ring angeordnet, vielmehr habe ich mehrere Netze, das "komplexeste" ist wie folgt:
R1->R2->Richtfunk->R3
R2->Richtfunk->R4->R5->R2
So sieht es derzeit aus. Die "normalen" Verbindungen sind in LWL ausgeführt. Die angeschlossenen Geräte kommunizieren mit Unicast und Multicast miteinander. Die maximale Bandbreite ist ca. 250-300kBit/s. Mehr nicht. Ich denke/hoffe, dass die Prozessorkapazität ausreicht um die RSTP und Switching/Bridging Aufgaben zu bewältigen.
Es gibt auch keinerlei Hinweise, dass das RSTP Protokoll umswitchen muss, also Ports von "root" auf "alternate" oder "designated" umändern muss. Von daher verstehe ich die Begründung mit RSTP wäre ungeeignet nicht.
Kannst du das nochmal ausführen?
Gibt es denn für die obige Routerkonfiguration eine bessere Lösung als Mikrotik mit Bridging? Der Switch-Teil im Router kann ja kein RSTP...
Vielen Dank schon mal.
Was ich nicht ganz verstehe: Wieso ist RSTP nicht für eine Ringtopologie ausgelegt? Soweit ich weiß, verhindert RSTP Netzwerk-Loops. Genau das soll es tun, das tut es auch und ist doch für meine Aufgabe genau das Richtige!?
Hier sind nochmals meine Randbedingungen, vielleicht hilft es, wenn ich präziser werde.
Die Router sind nicht "nur" in einem Ring angeordnet, vielmehr habe ich mehrere Netze, das "komplexeste" ist wie folgt:
R1->R2->Richtfunk->R3
R2->Richtfunk->R4->R5->R2
So sieht es derzeit aus. Die "normalen" Verbindungen sind in LWL ausgeführt. Die angeschlossenen Geräte kommunizieren mit Unicast und Multicast miteinander. Die maximale Bandbreite ist ca. 250-300kBit/s. Mehr nicht. Ich denke/hoffe, dass die Prozessorkapazität ausreicht um die RSTP und Switching/Bridging Aufgaben zu bewältigen.
Es gibt auch keinerlei Hinweise, dass das RSTP Protokoll umswitchen muss, also Ports von "root" auf "alternate" oder "designated" umändern muss. Von daher verstehe ich die Begründung mit RSTP wäre ungeeignet nicht.
Kannst du das nochmal ausführen?
Gibt es denn für die obige Routerkonfiguration eine bessere Lösung als Mikrotik mit Bridging? Der Switch-Teil im Router kann ja kein RSTP...
Vielen Dank schon mal.
In der Zwischenzeit habe ich gelesen, dass es sich bei der hier verwendeten Topologie um ein sog. vermaschtes Netz handelt. Hierfür ist RSTP allerdings oftmals empfohlen, auch wenn die Zeit des "Konvergierens" nicht die schnellste ist.
Du redest aber klar von eine Ringtopologie ! Was denn nun ?? Als lizensierter Funkamateur sollte man doch gelernt haben technische Sachverhalte sauber zu beschreiben...und auch zu lösen.
Vermascht kann ja viel heissen. L2 oder L3 vermascht.
So oder so beisst die Maus keinen Faden ab, wenn du MC machst ohne IGMP Snooping (dazu hast du auch noch rein gar nichts gesagt...?!) und das in Teilringen mit schwacher Hardware wirst du immer mit den o.a. Problemen kämpfen müssen.
Hast du denn wenigstens IGMP Snooping aktiviert ?
Vermascht kann ja viel heissen. L2 oder L3 vermascht.
So oder so beisst die Maus keinen Faden ab, wenn du MC machst ohne IGMP Snooping (dazu hast du auch noch rein gar nichts gesagt...?!) und das in Teilringen mit schwacher Hardware wirst du immer mit den o.a. Problemen kämpfen müssen.
Hast du denn wenigstens IGMP Snooping aktiviert ?
Also, die Topologie habe ich beschrieben, es ist ein Mix aus Stern und "Ringverkabelung".
Die Mikrotik Router unterstützen soweit ich weiss kein IGMP Snooping. Lediglich IGMP Proxy und MC-Routing mit PIM, das aber laut Aussagen von Mikrotik selbst in der 6er Versionsreihe fehlerhaft implementiert ist. Daher wollte ich vorerst auf das MC-Routing verzichten.
Wie gesagt, das was mich etwas stutzig macht ist, dass ich an vielen Stellen im INet lese, dass RSTP für jede Art von Topologie benutzt werden kann. Halt mit Einschränkungen was die maximale Anzahl an Ethernethops und die Konvergenzzeit angeht. Mit allem kann ich ja leben.
Das Argument mit der zu schwachen Hardware ist leider auch nur schwer nachvollziehbar, da die CPU-Last zu keiner Zeit höher als 8-10% liegt. Auch nicht bei den CRS112. Sollten es dennoch Netzwerkspitzen sein, sind die benutzten Bandbreiten mit bis zu 300kBit/s nun wirklich nicht zu hoch, als das es eine CPU im Router nicht schaffen sollte...
Ich befürchte, dass Mikrotik beim Transport von MC Paketen auch auf der Bridge Probleme hat.
In der kommenden Version ab V6.38rc2 sollen die CRS Geräte das RSTP Protokoll bereits auf der Switch-Ebene unterstützen. Das sollte dann die CPU erheblich entlasten, da ja der Switch-Chip für die Art des Pakettransportes optimiert ist. Mal sehen, vielleicht bringt das Vorteile!
Bisher habe ich in jeder beteiligten Bridge RSTP aktiviert. Kann man eigentlich bei Bridges, die in der Mitte liegen und sowieso nur 2 Ports haben das RSTP abschalten? Es gibt ja hier dann hier eh keine Möglichkeit Ports zu blocken um Loops zu verhindern! Oder? Das würde doch den Datenverkehr der BPDUs verringern...
Vielen Dank für die bisherigen Tipps!
Die Mikrotik Router unterstützen soweit ich weiss kein IGMP Snooping. Lediglich IGMP Proxy und MC-Routing mit PIM, das aber laut Aussagen von Mikrotik selbst in der 6er Versionsreihe fehlerhaft implementiert ist. Daher wollte ich vorerst auf das MC-Routing verzichten.
Wie gesagt, das was mich etwas stutzig macht ist, dass ich an vielen Stellen im INet lese, dass RSTP für jede Art von Topologie benutzt werden kann. Halt mit Einschränkungen was die maximale Anzahl an Ethernethops und die Konvergenzzeit angeht. Mit allem kann ich ja leben.
Das Argument mit der zu schwachen Hardware ist leider auch nur schwer nachvollziehbar, da die CPU-Last zu keiner Zeit höher als 8-10% liegt. Auch nicht bei den CRS112. Sollten es dennoch Netzwerkspitzen sein, sind die benutzten Bandbreiten mit bis zu 300kBit/s nun wirklich nicht zu hoch, als das es eine CPU im Router nicht schaffen sollte...
Ich befürchte, dass Mikrotik beim Transport von MC Paketen auch auf der Bridge Probleme hat.
In der kommenden Version ab V6.38rc2 sollen die CRS Geräte das RSTP Protokoll bereits auf der Switch-Ebene unterstützen. Das sollte dann die CPU erheblich entlasten, da ja der Switch-Chip für die Art des Pakettransportes optimiert ist. Mal sehen, vielleicht bringt das Vorteile!
Bisher habe ich in jeder beteiligten Bridge RSTP aktiviert. Kann man eigentlich bei Bridges, die in der Mitte liegen und sowieso nur 2 Ports haben das RSTP abschalten? Es gibt ja hier dann hier eh keine Möglichkeit Ports zu blocken um Loops zu verhindern! Oder? Das würde doch den Datenverkehr der BPDUs verringern...
Vielen Dank für die bisherigen Tipps!
Die Mikrotik Router unterstützen soweit ich weiss kein IGMP Snooping.
Das ist dann natürlich umso tödlicher in dem Umfeld.... 
Das Verhalten bei dir spricht ja auch dafür das das Gerät das in CPU fluten muss und damit an die Grenze der Leistungsfähigkeit kommt.
Die CPU Last wird vermutlich nur gemittelt angezeigt, deshalb siehst du da keinen realistischen Werte.
So oder so ist es doch aber etwas blauäugig in einem MC Umfeld einen Router zu verwenden der kein IGMP supportet. Da musst du dich dann nicht wundern wen das Netz kollabiert.
Fazit: Falsche Hardware für die Anwendung !
sollen die CRS Geräte das RSTP Protokoll bereits auf der Switch-Ebene unterstützen.
Ahem... NUR Switche supporten sinnvollerweise RSTP. Ein Router bruacht kein RSTP !! Kann das sein das du da was missverstanden hast ?!Bisher habe ich in jeder beteiligten Bridge RSTP aktiviert.
Das musst du auch zwangsläufig in einem redundanten Netz. Sonst hättest du ja sofort einen Loop !Was sind macht ist im RSTP die Edge Ports und die Uplink Ports zu definieren im Setup. Das reduziert auch schon ziemlich den BPDU Traffic.
Das mit dem "fluten der CPU" verstehe ich nicht. Wie zuvor beschrieben habe ich maximalen Traffic von ca. 300kBit/s. Wenn das für eine moderne Router/Switch CPU zu viel ist, dann weiß ich auch nicht...
Für eine moderne CPU wie du sie kennst ist das sicher ein Kinderspiel. Es sind aber keine modernen CPUs drin in solchen Switches, das ist dein Denkfehler. Dort sind billige, schwachbrüstige SoCs verbaut.
Normal reichen die auch, denn das Paket Forwarding machen zu 98% die Port ASICS und der SoC schickt nur einmalig ein paar Konfig Kommandos dahin. Bei Broadcasts und speziell Multicasts ist das aber nicht so.
Da muss die CPU die Pakete n-mal kopieren (soviel wie aktive Ports vorhanden sind) und an diesen Ports aussenden. Ohne aktives IGMP ist der Switch dazu gezwungen um diese Pakete standardkonform zu übertragen.
Tritt so ein Traffic dann bei SoCs nicht burstartig auf sondern mit konstanter Rate (und da reicht soch eine niedrige) gehen diese CPUs sofort in die Knie so wie bei dir oben.
Sie sind dann primär mit dem Forwarding beschäftigt so das der Scheduler wichtige BPDU Frames nicht mehr forwarden kann und die dann dropped oder einfach "vergisst".
Dadurch sagt der Spanning Tree dann mit einmal das kein Loop mehr da ist, und setzt so einen Port in den Forwarding Mode, was dann sofort wieder einen Loop triggert. Dann beginnt der Teufelskreis....
Ein typisches Verhalten bei billigen Consumerswitches unter Broad- und Multicast Last.
Normal reichen die auch, denn das Paket Forwarding machen zu 98% die Port ASICS und der SoC schickt nur einmalig ein paar Konfig Kommandos dahin. Bei Broadcasts und speziell Multicasts ist das aber nicht so.
Da muss die CPU die Pakete n-mal kopieren (soviel wie aktive Ports vorhanden sind) und an diesen Ports aussenden. Ohne aktives IGMP ist der Switch dazu gezwungen um diese Pakete standardkonform zu übertragen.
Tritt so ein Traffic dann bei SoCs nicht burstartig auf sondern mit konstanter Rate (und da reicht soch eine niedrige) gehen diese CPUs sofort in die Knie so wie bei dir oben.
Sie sind dann primär mit dem Forwarding beschäftigt so das der Scheduler wichtige BPDU Frames nicht mehr forwarden kann und die dann dropped oder einfach "vergisst".
Dadurch sagt der Spanning Tree dann mit einmal das kein Loop mehr da ist, und setzt so einen Port in den Forwarding Mode, was dann sofort wieder einen Loop triggert. Dann beginnt der Teufelskreis....
Ein typisches Verhalten bei billigen Consumerswitches unter Broad- und Multicast Last.
ok, das ist verständlich, vielen Dank für die Kommentare. Ich habe dann die Hoffnung, dass das FW-Update etwas bringt. Dann soll ja bereits der Switch-Teil RSTP beherrschen. Das sollte dann hoffentlich schnell genug gehen.
Bis dahin werde ich mal das detaillierte Logging für RSTP anschalten. Dort sollte man ja dann das fälschliche Umschalten bemerken.
Bis dahin werde ich mal das detaillierte Logging für RSTP anschalten. Dort sollte man ja dann das fälschliche Umschalten bemerken.
Das mit der CPU Leistung hat mir keine Ruhe gelassen. Deswegen anbei ein Auszug aus dem Datenblatt des Switches/Routers.
Der kleinste Werte liegt immer noch 10-fach höher, als ich ihn brauche.
Der kleinste Werte liegt immer noch 10-fach höher, als ich ihn brauche.
Du vertraust Marketing Werten aus dem Datenblatt ??
Dann glaubst du auch die Verbrauchswerte der Hersteller bei Autos, richtig ?!
Genau so werden die auch ermittelt.
Nimm NetIO oder iPerf und mach dir selbst ein realistisches Bild.
Dann glaubst du auch die Verbrauchswerte der Hersteller bei Autos, richtig ?!
Genau so werden die auch ermittelt.
Nimm NetIO oder iPerf und mach dir selbst ein realistisches Bild.
Hallo,
Wie @aqui schon andeutete, wenn du die Laborwerte von https://www.ietf.org/rfc/rfc2544.txt oder von http://xenanetworks.com/xena-networks-gigabit-ethernet-test-software/l2 ... mit deinen echten Traffic übereinstimmen kannst werden die Angaben wieder passen. Aber wer fährt tatsächlich ein Laborzyklus im richtigen Leben? Daher mal schauen was sich dekct un dob du das Labornachgestellt bekommst, besonders die Datenpakte mit Inhalt..... Im Labor fährt auch keine Testwagen mit einen kreischenden Beifahrer und nervenden Kindern auf den Rücksitzen bzw. im Gepäckraum
Gruß,
Peter
Wie @aqui schon andeutete, wenn du die Laborwerte von https://www.ietf.org/rfc/rfc2544.txt oder von http://xenanetworks.com/xena-networks-gigabit-ethernet-test-software/l2 ... mit deinen echten Traffic übereinstimmen kannst werden die Angaben wieder passen. Aber wer fährt tatsächlich ein Laborzyklus im richtigen Leben? Daher mal schauen was sich dekct un dob du das Labornachgestellt bekommst, besonders die Datenpakte mit Inhalt..... Im Labor fährt auch keine Testwagen mit einen kreischenden Beifahrer und nervenden Kindern auf den Rücksitzen bzw. im Gepäckraum
Gruß,
Peter
