1
Netgear GS724TPv3 und Apple-TV finden sich nicht
Hallo Forum,
wir haben in einer Schule 7 Netgear Switches vom Type GS724TPv3 verbaut. 11 VLANs sind eingerichtet. Das Management-VLAN ist 11. VLAN 1 wird nicht über den Trunk weitergeleitet.
Wir nutzen Ubiquiti UAP-AC-Pro als AP.
Grundsätzlich funktioniert auch alles.
In dem einen WLAN (VLAN 77) befinden sich iPads, Apple-TVs und Roku Express.
Anfangs haben die iPads die Apple-TVs und Rokus nicht gefunden.
Ich habe dann IGMP-Snooping eingerichtet für das VLAN nach dieser Anleitung:
support.biamp.com/Tesira/AVB/Configuring_IGMP_Snooping_on_the_Netgear_GS724Tv4
Das hatte zumindest den Effekt, dass sich die Geräte kurzzeitig mal finden. Meistens aber nicht.
Auffallend ist, dass ich die TVs finde, wenn iPad und TV am gleichen Switch sind. Nicht unbedingt am am gleichen AP.
Über die Switch-Grenzen hinaus geht es manchmal.
Hat jemand eine Idee, was da schiefläuft?
In einer anderen Schule mit nur zwei Switches ein gleiches Problem. Da hat die Konfiguration nach der o. g. Anleitung funktioniert.
Die aktuell Firmware ist auf den Geräten installiert.
Danke für Eure Antworten!
Viele Grüße
Thomas
wir haben in einer Schule 7 Netgear Switches vom Type GS724TPv3 verbaut. 11 VLANs sind eingerichtet. Das Management-VLAN ist 11. VLAN 1 wird nicht über den Trunk weitergeleitet.
Wir nutzen Ubiquiti UAP-AC-Pro als AP.
Grundsätzlich funktioniert auch alles.
In dem einen WLAN (VLAN 77) befinden sich iPads, Apple-TVs und Roku Express.
Anfangs haben die iPads die Apple-TVs und Rokus nicht gefunden.
Ich habe dann IGMP-Snooping eingerichtet für das VLAN nach dieser Anleitung:
support.biamp.com/Tesira/AVB/Configuring_IGMP_Snooping_on_the_Netgear_GS724Tv4
Das hatte zumindest den Effekt, dass sich die Geräte kurzzeitig mal finden. Meistens aber nicht.
Auffallend ist, dass ich die TVs finde, wenn iPad und TV am gleichen Switch sind. Nicht unbedingt am am gleichen AP.
Über die Switch-Grenzen hinaus geht es manchmal.
Hat jemand eine Idee, was da schiefläuft?
In einer anderen Schule mit nur zwei Switches ein gleiches Problem. Da hat die Konfiguration nach der o. g. Anleitung funktioniert.
Die aktuell Firmware ist auf den Geräten installiert.
Danke für Eure Antworten!
Viele Grüße
Thomas
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: 668228
Url: https://administrator.de/contentid/668228
Ausgedruckt am: 23.11.2024 um 10:11 Uhr
1 Kommentar
Grundsätzlich ist dein Ansatz zur Fehlersuche richtig, denn alle Geräte nutzen mDNS und damit dann Multicasting (IPv4: 224.0.0.251, IPv6: ff02::fb, UDP-Port 5353) um sich im Netzwerk untereinander bekannt zu machen.
Nur eine vage Vermutung aber es wird sehr wahrscheinlich kein Fehler der NG Switches sein, denn die haben bei Multicast Traffic grundsätzlich nur 2 Optionen:
Das sollte man also in jedem Falle einmal wasserdicht testen, was schnell und problemlos umzusetzen ist!!
Dazu sind 2 Punkte wichtig:
Anhand der Aktivitäten LEDs an den Switchports kann man sehr schön beobachten ob IGMP Snooping greift. (oder nicht)
Man kann dies gut testen indem man einmal kein IGMP Snooping aktiviert und einmal mit. So ist der Switch einmal zum Fluten des Multicast Traffics gezwungen und einmal kann er intelligent forwarden, was man an den Port Activity LEDs sehr gut beobachten kann. Natürlich auch mit einem Wireshark Sniffer an einem Mirror Port.
Rennt das wie es soll auf allen Kupfer basierten Anschlüssen, kann man es einmal mit einem entsprechenden VLC Client auf das WLAN ausweiten. VLC ist u.a. auch für iPads im App Store kostenfrei verfügbar.
Hier sollte erwartungsgemäß ein gleiches Verhalten zu beobachten sein.
Knackpunkt im WLAN ist üblicherweise immer die Multicast zu Unicast Konvertierung. Siehe dazu auch HIER.
Es wäre zumindestens denkbar das Billigheimer UBQT hier patzt von der Firmware oder sonstwie Probleme hat das umzusetzen. Billiganbieter sparen sich auch oftmals diese Funktion mit fatalen Folgen das der AP dann für alle assozierten Clients den MC Traffic kopieren muss was dann bei der üblichen schwachen Hardware Bestückung dieser Hersteller in der Regel zum Zusammenbruch solcher Streams oder generellen Einbußen der AP Performance führt. Als HW Entwickler kennt man sowas.
Mit dem o.a. Testverfahren hast du aber ein gutes Testtool an der Hand um die korrekte und protokollkonforme Behandlung von Multicast Traffic im Netz wasserdicht zu checken. Das sollte also der erste Step sein um den Fehler einzugrenzen.
Hier ist ein ähnlicher Thread zu der Thematik.
Nur eine vage Vermutung aber es wird sehr wahrscheinlich kein Fehler der NG Switches sein, denn die haben bei Multicast Traffic grundsätzlich nur 2 Optionen:
- Kein IGMP Snooping = Switch kopiert und flutet Multicast an alle Ports = performancelastig und schlechtes Design
- IGMP Snooping aktiv = Switch forwardet dediziert nur an Ports wo entsprechende Endgeräte sind = generell sinnvolles Setup in Netzwerken und sollte global gesetzt sein das es grundsätzlich für alle VLANs gilt.
Das sollte man also in jedem Falle einmal wasserdicht testen, was schnell und problemlos umzusetzen ist!!
Dazu sind 2 Punkte wichtig:
- Aktuelle Firmware auf allen Netgear Switches mit dem gleichen Release
- Testen des Multicast / IGMP Verhaltens auf der LAN Infrastruktur.
Anhand der Aktivitäten LEDs an den Switchports kann man sehr schön beobachten ob IGMP Snooping greift. (oder nicht)
Man kann dies gut testen indem man einmal kein IGMP Snooping aktiviert und einmal mit. So ist der Switch einmal zum Fluten des Multicast Traffics gezwungen und einmal kann er intelligent forwarden, was man an den Port Activity LEDs sehr gut beobachten kann. Natürlich auch mit einem Wireshark Sniffer an einem Mirror Port.
Rennt das wie es soll auf allen Kupfer basierten Anschlüssen, kann man es einmal mit einem entsprechenden VLC Client auf das WLAN ausweiten. VLC ist u.a. auch für iPads im App Store kostenfrei verfügbar.
Hier sollte erwartungsgemäß ein gleiches Verhalten zu beobachten sein.
Knackpunkt im WLAN ist üblicherweise immer die Multicast zu Unicast Konvertierung. Siehe dazu auch HIER.
Es wäre zumindestens denkbar das Billigheimer UBQT hier patzt von der Firmware oder sonstwie Probleme hat das umzusetzen. Billiganbieter sparen sich auch oftmals diese Funktion mit fatalen Folgen das der AP dann für alle assozierten Clients den MC Traffic kopieren muss was dann bei der üblichen schwachen Hardware Bestückung dieser Hersteller in der Regel zum Zusammenbruch solcher Streams oder generellen Einbußen der AP Performance führt. Als HW Entwickler kennt man sowas.
Mit dem o.a. Testverfahren hast du aber ein gutes Testtool an der Hand um die korrekte und protokollkonforme Behandlung von Multicast Traffic im Netz wasserdicht zu checken. Das sollte also der erste Step sein um den Fehler einzugrenzen.
Hier ist ein ähnlicher Thread zu der Thematik.
1
