10
Cisco CBS220 Switch hängen sich durch IGMP Streams auf
Hallo
Ich habe ein Hotel Netzwerk, welches neu einen IPTV Streamer erhalten hat, welcher mir aber grosses Kopfzerbrechen verursacht.
Das Netzwerk ist relativ simpel:
Router / Firewall welcher als Gateway, DHCP Server und die VLANs beherbergt.
Im grossen und ganzen hat es folgende Netze:
Default LAN (VALN 1) für technische Geräte
VLAN 10 für Clients
VLAN 21 für IPTV (darum geht es bei meinem Problem)
VLAN 84 für Gäste
und noch einzelne für kleinere Netze und oder Räume.
Eingesetzt wurden Cisco CBS220 24P-4X Switches und mehrheitlich LWL 10Gbit Verbindungen von Switch zu Switch.
Kein LACP, LAG oder Ring vorhanden, natürlich aber RSTP mit allen Prioritäten / Root Bridge Konfigs.
Auf den Main01 Switch geht ein IPTV Streamer, welcher permanent eine Multicast Bandbreite von ca. 630Mbit/s senden. (Daran kann nichts verändert werden)
Hierfür wurde auf dem Main01 Switch ein Access Port Untaggt im VLAN21 konfiguriert.
Danach via den Trunks zu den einzelnen Switches, woran dann die TV's wiederrum an Access Ports im Untaggt VLAN21 hängen.
Gleichzeitig wurde auf allen Switches im VLAN21 das IGMP Snopping aktiviert.
Leider gibt es vom Lieferant des IPTV Streamers nahezu keine Infos und auch das Datenblatt gibt nichts her.
Folgende Multicast Konfiguration gibt wenigstens ein Bild auf den TV's:
Grundlegend IGMP Snooping aktivieren und das weiterleiten an die MRouter Ports erlauben:
IGMP Snooping im betreffenden VLAN21 aktivieren: (IGMP Snooping wurde bewusst zum testen nur im VLAN21 aktiviert)
Danach die MRouter Ports als statisch zuweisen. Diese sind hier immer Switch zu Switch Verbindung, keine TV Client Ports.
Lasse ich hier die Konfiguration auf dynamisch, bekommen die AP Switches die Multicast Gruppen nicht zugewiesen:
Mit dieser Konfiguration funktioniert das Bild, aber sobald die jeweilige IGMP Group Timer ablaufen und sich erneuern, bleibt das TV Bild stehen.
Erst wenn auf dem TV der Kanal gewechselt wird, läuft es wieder bis der jeweilige Group Timer abläuft.
Unschön, da der Timer immer 260s ist und ich keine Ahnung habe wie ich diesen zB. so hoch stellen kann das es nicht bemerkbar ist. (zB. 12h oder so)
Gibt es da eine Möglichkeit als Workaround oder so?
Mit folgender Einstellung konnte ich das Timeout umgehen und der TV Stream scheint sauber zu funktionieren: (egal ob IGMPv2 oder v3)
ABER dann:
Sobald ein TV Client an einem Switch startet, scheint es ziemlich genau nach 30 Minuten soweit zu sein das der direkt davor gehängte Cisco Switch keinerlei sinnvolle Nutzung mehr erlaubt. zB. dreht im Web GUI dann der IGMP Status endlos, wohingehen das restliche Web GUI weiterhin funktioniert und Status Informationen abgerufen werden können. (CPU Last ist zB. max 15% und auch mit Debug Log ist nichts aussergewöhnliches zu sehen)
Aber es können auch keinerlei Konfigurationen mehr gespeichert werden, dann dreht das Web GUI ebenfalls endlos.
Auch via CLI kann ich mit dem copy running-config startup-config nichts anfangen, der Switch gibt nie das [OK] zurück.
Nach einen Neustart des Switch ist alles wieder ok bis irgend eine TV Client wieder einen TV Stream startet.
Entschuldigung für den langen Text, aber ich hoffe Ihr könnt mir helfen
Danke und Gruss
Philippe
Ich habe ein Hotel Netzwerk, welches neu einen IPTV Streamer erhalten hat, welcher mir aber grosses Kopfzerbrechen verursacht.
Das Netzwerk ist relativ simpel:
Router / Firewall welcher als Gateway, DHCP Server und die VLANs beherbergt.
Im grossen und ganzen hat es folgende Netze:
Default LAN (VALN 1) für technische Geräte
VLAN 10 für Clients
VLAN 21 für IPTV (darum geht es bei meinem Problem)
VLAN 84 für Gäste
und noch einzelne für kleinere Netze und oder Räume.
Eingesetzt wurden Cisco CBS220 24P-4X Switches und mehrheitlich LWL 10Gbit Verbindungen von Switch zu Switch.
Kein LACP, LAG oder Ring vorhanden, natürlich aber RSTP mit allen Prioritäten / Root Bridge Konfigs.
Auf den Main01 Switch geht ein IPTV Streamer, welcher permanent eine Multicast Bandbreite von ca. 630Mbit/s senden. (Daran kann nichts verändert werden)
Hierfür wurde auf dem Main01 Switch ein Access Port Untaggt im VLAN21 konfiguriert.
Danach via den Trunks zu den einzelnen Switches, woran dann die TV's wiederrum an Access Ports im Untaggt VLAN21 hängen.
Gleichzeitig wurde auf allen Switches im VLAN21 das IGMP Snopping aktiviert.
Leider gibt es vom Lieferant des IPTV Streamers nahezu keine Infos und auch das Datenblatt gibt nichts her.
Folgende Multicast Konfiguration gibt wenigstens ein Bild auf den TV's:
Grundlegend IGMP Snooping aktivieren und das weiterleiten an die MRouter Ports erlauben:
IGMP Snooping im betreffenden VLAN21 aktivieren: (IGMP Snooping wurde bewusst zum testen nur im VLAN21 aktiviert)
Danach die MRouter Ports als statisch zuweisen. Diese sind hier immer Switch zu Switch Verbindung, keine TV Client Ports.
Lasse ich hier die Konfiguration auf dynamisch, bekommen die AP Switches die Multicast Gruppen nicht zugewiesen:
Mit dieser Konfiguration funktioniert das Bild, aber sobald die jeweilige IGMP Group Timer ablaufen und sich erneuern, bleibt das TV Bild stehen.
Erst wenn auf dem TV der Kanal gewechselt wird, läuft es wieder bis der jeweilige Group Timer abläuft.
Unschön, da der Timer immer 260s ist und ich keine Ahnung habe wie ich diesen zB. so hoch stellen kann das es nicht bemerkbar ist. (zB. 12h oder so)
Mit folgender Einstellung konnte ich das Timeout umgehen und der TV Stream scheint sauber zu funktionieren: (egal ob IGMPv2 oder v3)
Sobald ein TV Client an einem Switch startet, scheint es ziemlich genau nach 30 Minuten soweit zu sein das der direkt davor gehängte Cisco Switch keinerlei sinnvolle Nutzung mehr erlaubt. zB. dreht im Web GUI dann der IGMP Status endlos, wohingehen das restliche Web GUI weiterhin funktioniert und Status Informationen abgerufen werden können. (CPU Last ist zB. max 15% und auch mit Debug Log ist nichts aussergewöhnliches zu sehen)
Aber es können auch keinerlei Konfigurationen mehr gespeichert werden, dann dreht das Web GUI ebenfalls endlos.
Auch via CLI kann ich mit dem copy running-config startup-config nichts anfangen, der Switch gibt nie das [OK] zurück.
Nach einen Neustart des Switch ist alles wieder ok bis irgend eine TV Client wieder einen TV Stream startet.
Entschuldigung für den langen Text, aber ich hoffe Ihr könnt mir helfen
Danke und Gruss
Philippe
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3076443087
Url: https://administrator.de/forum/cisco-cbs220-switch-haengen-sich-durch-igmp-streams-auf-3076443087.html
Ausgedruckt am: 23.12.2024 um 23:12 Uhr
10 Kommentare
Neuester Kommentar
Wenn kein PIM Router im Netzaktiv ist muss immer der Querrier aktiviert werden.
- Aktuellste Firmware ist auf den CBS geflasht?
- Multicast zu Unicast Konvertierung ist in den APs aktiviert?
Servus,
bei mir wird das Thema vermutlich ab Herbst interessant (IP-TV und AVoIP-Lösung ist angedacht).
Schau mal hier, da findest du eine ziemlich detaillierte Anleitung für Dante, die Multicast-Basis ist ja ziemlich ähnlich:
https://technet.genesis-technologies.ch/setup-a-cisco-sg300-500-switch-f ...
Bei dir ist ev. die Anmerkung über mehrere Switches interessant.
Ich hab schon ein paar Mal aufgeschnappt, dass bei div. AVoIP-Lösungen die SG/CBS-Serien erst ab 3xx funktionieren sollen, allerdings noch nirgends die wirkliche Einschränkung herausfinden können.
Einige Hersteller empfehlen hier Netgear (und einige Integratoren bestehen auf einem 2. phys. Netz mit Netgear-Hardware), da soll alles out of the box laufen...
Off-Topic (gerne per DM): Welche Endgeräte (TV/Settop-Boxen) setzt du ein?
Grüße, Stefan
bei mir wird das Thema vermutlich ab Herbst interessant (IP-TV und AVoIP-Lösung ist angedacht).
Schau mal hier, da findest du eine ziemlich detaillierte Anleitung für Dante, die Multicast-Basis ist ja ziemlich ähnlich:
https://technet.genesis-technologies.ch/setup-a-cisco-sg300-500-switch-f ...
Bei dir ist ev. die Anmerkung über mehrere Switches interessant.
Ich hab schon ein paar Mal aufgeschnappt, dass bei div. AVoIP-Lösungen die SG/CBS-Serien erst ab 3xx funktionieren sollen, allerdings noch nirgends die wirkliche Einschränkung herausfinden können.
Einige Hersteller empfehlen hier Netgear (und einige Integratoren bestehen auf einem 2. phys. Netz mit Netgear-Hardware), da soll alles out of the box laufen...
Off-Topic (gerne per DM): Welche Endgeräte (TV/Settop-Boxen) setzt du ein?
Grüße, Stefan
Danke für eure Antworten
@148523
Die Switches sind natürlich auf dem neuesten Stand. V2.0.1.9
Was meinst du mit Multicast zu Unicast Konvertierung? der Multicast Stream geht via die Switches direkt an die TV CLients, welche natürlich via UKV Verkabelung erschlossen sind. Kein WLAN.
@Stefan
Danke für den Link, schaut interessant aus. Wenn ich IGMP Querier aktiviert habe, dann immer auf mehr als einem Switch, vielleicht war dies ja bereits der Fehler. Ich teste es und gebe eine Rückmeldung.
Ich hoffe sehr das es nicht mit der CBS220er Serie ein Problem gibt, denn Layer 3 brauche ich nicht und daher die Wahl der CBS220er Serie. Natürlich war damals das Thema mit dem IPTV auf dem Netzwerk noch nicht bekannt....
Der IPTV Lieferant verwendet auch Netgear Switch, weshalb es aber dort problemlos gehen soll und auf einem deutlich besseren Cisco nicht, ist mir schleierhaft.
Gruss
Philippe
@148523
Die Switches sind natürlich auf dem neuesten Stand. V2.0.1.9
Was meinst du mit Multicast zu Unicast Konvertierung? der Multicast Stream geht via die Switches direkt an die TV CLients, welche natürlich via UKV Verkabelung erschlossen sind. Kein WLAN.
@Stefan
Danke für den Link, schaut interessant aus. Wenn ich IGMP Querier aktiviert habe, dann immer auf mehr als einem Switch, vielleicht war dies ja bereits der Fehler. Ich teste es und gebe eine Rückmeldung.
Ich hoffe sehr das es nicht mit der CBS220er Serie ein Problem gibt, denn Layer 3 brauche ich nicht und daher die Wahl der CBS220er Serie. Natürlich war damals das Thema mit dem IPTV auf dem Netzwerk noch nicht bekannt....
Der IPTV Lieferant verwendet auch Netgear Switch, weshalb es aber dort problemlos gehen soll und auf einem deutlich besseren Cisco nicht, ist mir schleierhaft.
Gruss
Philippe
Was meinst du mit Multicast zu Unicast Konvertierung?
https://www.heise.de/select/ct/archiv/2014/14/seite-76WiFi APs müssen zwangsweise den Multicast Stream zu Unicast konvertieren. Keine solche Konvertierung, also Flooding würde im WLAN zu massiven Performance Problemen führen. Diese Funktion muss also unbedingt auf den APs aktiviert sein wenn du MC im WLAN überträgst.
Zudem ist auch die Aktivierung von WMM dann unbedingt Pflicht auf den APs.
Eine saubere Frequenz und Kanalplanung mit Band Steering bevorzugt auf 5 GHz sollte ebenso klar sein wenne s um MV und WLAN geht.
dann immer auf mehr als einem Switch, vielleicht war dies ja bereits der Fehler.
Nein, normalerweise nicht. Richtig ist das nur einer der Querrier sein kann aber die Querrier Selection bei IGMP sorgt dafür das es nur einen aktiven gibt und das ist dann bei multiplen Querrier immer der mit der niedrigsten Mac Adresse. Kannst du mit einem Wireshark Sniffer auch ganz einfach selber prüfen.Das Netgear Argument ist natürlich Unsinn. IGMP Snooping können heutzutage auch billigste Chinesen Switches wie TP-Link & Co.. Das ist heute Standard und wenn das jemand Hersteller bezogen sieht ist das unlauter.
Natürlich war damals das Thema....
Wieso "damals"?? Was meinst du damit?? Zu Kaisers Zeiten?Multicast im Netzwerk gibt es schon seit Jahrzehnten. Guckst du auch hier:
https://www.youtube.com/watch?v=AvbSMBKBZgY
Alle 4 Teile sind unbedingt sehenswert!
Zitat von @148523:
WiFi APs müssen zwangsweise den Multicast Stream zu Unicast konvertieren. Keine solche Konvertierung, also Flooding würde im WLAN zu massiven Performance Problemen führen. Diese Funktion muss also unbedingt auf den APs aktiviert sein wenn du MC im WLAN überträgst.
Zudem ist auch die Aktivierung von WMM dann unbedingt Pflicht auf den APs.
Eine saubere Frequenz und Kanalplanung mit Band Steering bevorzugt auf 5 GHz sollte ebenso klar sein wenne s um MV und WLAN geht.
Nein, ich muss kein Multicast via WLAN übertragen. Alle TV Clients sind via UKV Leitungen erschlossen und an den verschiedenen Cisco Switches angeschlossen.Was meinst du mit Multicast zu Unicast Konvertierung?
https://www.heise.de/select/ct/archiv/2014/14/seite-76WiFi APs müssen zwangsweise den Multicast Stream zu Unicast konvertieren. Keine solche Konvertierung, also Flooding würde im WLAN zu massiven Performance Problemen führen. Diese Funktion muss also unbedingt auf den APs aktiviert sein wenn du MC im WLAN überträgst.
Zudem ist auch die Aktivierung von WMM dann unbedingt Pflicht auf den APs.
Eine saubere Frequenz und Kanalplanung mit Band Steering bevorzugt auf 5 GHz sollte ebenso klar sein wenne s um MV und WLAN geht.
dann immer auf mehr als einem Switch, vielleicht war dies ja bereits der Fehler.
Nein, normalerweise nicht. Richtig ist das nur einer der Querrier sein kann aber die Querrier Selection bei IGMP sorgt dafür das es nur einen aktiven gibt und das ist dann bei multiplen Querrier immer der mit der niedrigsten Mac Adresse. Kannst du mit einem Wireshark Sniffer auch ganz einfach selber prüfen.Das Netgear Argument ist natürlich Unsinn. IGMP Snooping können heutzutage auch billigste Chinesen Switches wie TP-Link & Co.. Das ist heute Standard und wenn das jemand Hersteller bezogen sieht ist das unlauter.
Auftragserteilung Natürlich war damals das Thema....
Wieso "damals"?? Was meinst du damit?? Zu Kaisers Zeiten?
Damals hiess es das alle TV's ein eigenes Netzwerk erhalten, welches dann ohne unser Wissen, aus vermutlich Kostengründen, gestrichen wurde...
Multicast im Netzwerk gibt es schon seit Jahrzehnten. Guckst du auch hier:
https://www.youtube.com/watch?v=AvbSMBKBZgY
Alle 4 Teile sind unbedingt sehenswert!
Danke, schaue ich mir mal anhttps://www.youtube.com/watch?v=AvbSMBKBZgY
Alle 4 Teile sind unbedingt sehenswert!
Sorry...Access Port mit Access Point in der Beschreibung verwechselt. Mea culpa 
Vergiss also alles was oben zum Thema MC und WLAN steht!!
Definiere dann als Workaround erstmal nur einen Querrier auf einem der Core Switches.
Das geht ja gar nicht anders vom Design her, also sind verschiedene Netze hier Pflicht und dein CBS220 ist ja VLAN fähig und kann das doch mit links abbilden. Wo ist also das Problem?
Vergiss also alles was oben zum Thema MC und WLAN steht!!
Genau das verstehe ich nicht und viele Optionen habe ich auf den CBS220er nicht.
Das könnte ein Bug sein...! Mit den Switches hast du ja auch Wartung und Service eingekauft. Damit solltest du dann asap ein Case im Cisco TAC dazu aufmachen!Definiere dann als Workaround erstmal nur einen Querrier auf einem der Core Switches.
Damals hiess es das alle TV's ein eigenes Netzwerk erhalten
Würde auch immer Sinn machen, ganz besonders in einem Hotel. Man will ja wohl kaum Gäste auch im TV Streaming Segment haben. Außerdem hat ein Hotel auch ein WLAN was immer in einem separaten Netz liegt. Verwaltung sowieso.Das geht ja gar nicht anders vom Design her, also sind verschiedene Netze hier Pflicht und dein CBS220 ist ja VLAN fähig und kann das doch mit links abbilden. Wo ist also das Problem?
Servus!
Ev. auch mal ins Log schauen, vielleicht findet sich dort was (Switch, SAT-IP-Server).
Das geht ja gar nicht anders vom Design her, also sind verschiedene Netze hier Pflicht und dein CBS220 ist ja VLAN fähig und kann das doch mit links abbilden. Wo ist also das Problem?
Eigenes Netzwerk heißt wirklich eigenes Netzwerk mit eigener Hardware und Verkabelung, nix VLAN. Ich kenne das von meinen Recherchen, eine größere Fa., mit der ich in Kontakt war, würde alle AVoIP-Komponenten in ein komplett getrenntes Netz mit Netgear-Switchen stecken. Netgear, weils laut ihren Angaben "einfach funktioniert". Vermutlich hat Netgear in der M-Serie für AVoIP einfach nur die richtigen Default-Werte und das Personal, das vielleicht noch von Coax&Co kommt nicht die richtige Netzwerkkenntnis 
.
Technisch natürlich schwachsinnig und ineffizient, aber nachvollziehbar, wenn es um die Verfügbarkeit geht. Wenn TV im ganzen Hotel nicht geht, weil der unwissende IT-Dienstleister oder der Sohn vom Chef meint, dass ein Hakerl am Switch für ein ganz anderes Problem verantwortlich ist und das weggeklickt gehört und prompt 100 Gäste nicht wissen, wass sie bei Schlechtwetter tun sollen...
@Philippe27 - kannst du mir bitte noch folgende Sache beantworten:
Off-Topic (gerne per DM): Welche Endgeräte (TV/Settop-Boxen) setzt du ein?
Bei mir wird das Thema im Herbst interessant, allerdings nur für eine handvoll IP-Clients.
Zitat von @148523:
Bei meinen Recherchen zu AVoIP habe ich mehrmals aufgeschnappt, dass die SG2x0er-Serie nicht richtig funktioniert (englischsprachige Communites zu Crestron/NVX bzw. Reddit). Nachvollziehbar (zumindest für mich nicht) begründet wurde es nie bzw. nur mit schwammigen Sachen wie "hat nur einen igmp querier lite".Genau das verstehe ich nicht und viele Optionen habe ich auf den CBS220er nicht.
Das könnte ein Bug sein...! Mit den Switches hast du ja auch Wartung und Service eingekauft. Damit solltest du dann asap ein Case im Cisco TAC dazu aufmachen!Definiere dann als Workaround erstmal nur einen Querrier auf einem der Core Switches.
Ich würde versuchen, alles einmal nur auf einem Switch abzubilden und dann erst größer aufzubauen.Ev. auch mal ins Log schauen, vielleicht findet sich dort was (Switch, SAT-IP-Server).
Damals hiess es das alle TV's ein eigenes Netzwerk erhalten
Würde auch immer Sinn machen, ganz besonders in einem Hotel. Man will ja wohl kaum Gäste auch im TV Streaming Segment haben. Außerdem hat ein Hotel auch ein WLAN was immer in einem separaten Netz liegt. Verwaltung sowieso.Das geht ja gar nicht anders vom Design her, also sind verschiedene Netze hier Pflicht und dein CBS220 ist ja VLAN fähig und kann das doch mit links abbilden. Wo ist also das Problem?
.Technisch natürlich schwachsinnig und ineffizient, aber nachvollziehbar, wenn es um die Verfügbarkeit geht. Wenn TV im ganzen Hotel nicht geht, weil der unwissende IT-Dienstleister oder der Sohn vom Chef meint, dass ein Hakerl am Switch für ein ganz anderes Problem verantwortlich ist und das weggeklickt gehört und prompt 100 Gäste nicht wissen, wass sie bei Schlechtwetter tun sollen...
@Philippe27 - kannst du mir bitte noch folgende Sache beantworten:
Off-Topic (gerne per DM): Welche Endgeräte (TV/Settop-Boxen) setzt du ein?
Bei mir wird das Thema im Herbst interessant, allerdings nur für eine handvoll IP-Clients.
heißt wirklich eigenes Netzwerk mit eigener Hardware und Verkabelung, nix VLAN.
Das wäre ziemlich sinnfrei. Aber nungut wenn sich Laien auf solche Firmen einlassen die sowas "raten" dann ist das deren Problem wenn sie ihr Geld verbrennen wollen. Aus technischer Sicht ist das in der Tat Schwachsinn und auch ineffizient wie de es schon richtig sagst und treibt nur deren Marge in die Höhe. Einen Nutzen hat das nicht. Und welcher Chef gibt seinem Sohn im Bastelalter Zugriff auf diese Infrastruktur?!
Servus,
die "geht nicht"-Diskussion hat mir keine Ruhe gelassen und ich hätte dafür auf Basis der Datenblätter folgende Vermutung:
In der alten SG200/SG300er-Serie hatte der SG200 tatsächlich keinen IGMP-Querier, der SG300er schon.
Alle späteren Serien (SG220/250/350, CBS220...) haben einen IGMP-Querier dabei. Dieser Umstand schlägt sich vermutlich auch in den Empfehlungen bzw. Beispielkonfigurationen div. AV-Hersteller auf Basis der SG300er-Serie nieder, die dann nur auf SG350 aktualisiert wurden.
Laut Datenblatt sollte es also funktionieren. Weitere Testmöglichkeiten: Hol dir irgendwoher ein paar Videodateien und starte mit VLC mehrere Multicaststreams. Die kannst du per VLC auch wiedergeben und dazwischen wechseln. So könntest du zumindest einmal die grundlegende Multicast-Funktionalität testen.
Grüße, Stefan
die "geht nicht"-Diskussion hat mir keine Ruhe gelassen und ich hätte dafür auf Basis der Datenblätter folgende Vermutung:
In der alten SG200/SG300er-Serie hatte der SG200 tatsächlich keinen IGMP-Querier, der SG300er schon.
Alle späteren Serien (SG220/250/350, CBS220...) haben einen IGMP-Querier dabei. Dieser Umstand schlägt sich vermutlich auch in den Empfehlungen bzw. Beispielkonfigurationen div. AV-Hersteller auf Basis der SG300er-Serie nieder, die dann nur auf SG350 aktualisiert wurden.
Laut Datenblatt sollte es also funktionieren. Weitere Testmöglichkeiten: Hol dir irgendwoher ein paar Videodateien und starte mit VLC mehrere Multicaststreams. Die kannst du per VLC auch wiedergeben und dazwischen wechseln. So könntest du zumindest einmal die grundlegende Multicast-Funktionalität testen.
Grüße, Stefan
Hol dir irgendwoher ein paar Videodateien und starte mit VLC mehrere Multicaststreams.
Wie das sehr einfach einfach geht steht z.B. HIER.
