PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,282
- Punkte für Reaktionen
- 1,754
- Punkte
- 113
Das mit dem HTTP-GUI ab V3 merke auch ich mir für die Zukunft, auch wenn ich (wg. ihres Dienstalters und weil die wohl nicht kaputt gehen wollen - allerdings sind sie nicht ganz kalt im Betrieb) hier nur die v1 in mehrfacher Ausfertigung am Werkeln habe.
Bleibt nur noch die Feststellung, daß es von der 8-Port-Variante v1, v2 und v3 gibt (bei der 5-Port wohl nur bis v2), wobei die v3 sogar derzeit die preiswerteste ist und bei einer Suche auf < 5 EUR/Port kommt. Allerdings muß man höllisch aufpassen, denn bei der 8-Port-Variante sind alle Versionen noch im Handel erhältlich.
Bei der 5-Port-Variante zahlt man zwar etwas mehr pro Port (knapp 6 EUR/Port), aber wenn man diesen Switch an einem Aufstellort benötigt, wo man definitiv nur eine begrenzte Zahl an Geräten anschließen will (meinetwegen in der Nähe des Fernsehers, wo dann die kommende Leitung, Smart-TV, STB, Game-Console und vielleicht noch ein AV-Receiver mit Internet-Radio angeschlossen werden sollen), dann ist dieses Gerät eben auch kleiner, fällt damit weniger auf und warum soll man für Ports Geld ausgeben, die man ohnehin nicht benutzt. Selbst wenn kein Port in Reserve offen bleibt, kann man notfalls später immer noch kaskadieren (oder doch austauschen), wenn es überraschend nicht reichen sollte.
Nicht unerwähnt sollte auch bleiben, daß es von TP-Link ein ähnliches Produkt wie den GS105E gibt, der heißt dann TL-SG105. Er kann wohl IGMP-Snooping und QoS nach 802.1p, aber kein VLAN (braucht damit auch keine Konfigurationsmöglichkeiten). Der kostet noch etwas weniger ... über die Qualität des Produkts kann ich selbst nichts berichten. Wenn es tatsächlich rein darum geht, das Netz nicht mit Multicast-to-Unicast-Traffic zu fluten, reicht der eventuell auch schon aus ... aber dann muß tatsächlich der Absender der Videodaten (wohl der SAT>IP-Umsetzer) die Pakete entsprechend taggen, wenn man von QoS profitieren will, was je nach Traffic-Volumen schon notwendig sein kann.
Ob man den (internen) VoIP-Traffic nun in einem eigenen VLAN isoliert (automatisch wie bei Cisco oder D-Link oder manuell) ist in meinen Augen reine Geschmackssache im Home-Network ... erhöhte Sicherheit erwarte ich davon nicht, solange der "Beitritt" eines Port zu diesem VLAN auf der Basis bestimmter Konditionen automatisch erfolgen kann.
In einem komplett geswitchten Netzwerk benötigt man ohnehin Zugriff auf einen der Knotenpunkte (also einen Switch oder ein Gateway), wenn man Pakete abfangen will, die nicht für die eigene MAC-Adresse (oder die Broadcast-Adresse) bestimmt sind. Hat jemand diesen Zugriff, sollte auch die Isolation in einem eigenen VLAN keine "echte Hürde" mehr sein. Rein für das Bandbreitenmanagement bringt VLAN-Tagging m.W. nur bei proprietären Implementierungen von Switch-Herstellern etwas, wenn anstelle von "richtigem QoS" eine Reservierung auf der Basis von VLAN implementiert ist (oder gar "feste Ports", wie beim Zyxel GS105S).
Wenn das IP-Telefonie-System seinerseits "ordnungsgemäß" das PCP-Feld auf 5 (Voice) oder 4 (Video) setzt, sollte jeder 802.1p-kompatible Switch damit klarkommen ... meines Erachtens braucht es keine weitere Priorisierung von IP-Telefonie. Vielleicht habe ich aber auch nur etwas fundamental falsch verstanden ... bei einem Router (der das originale IP-Paket ändert im Unterschied zum Switch) gibt es natürlich mehr Notwendigkeiten/Möglichkeiten, da etwas zu konfigurieren.
Um auch noch mal auf die im anderen Thread hinzugekommene "Forderung" nach rückwärtigen Anschlüssen einzugehen ... die passenden Zyxel-Modelle haben m.W. auch alle die kompletten Anschlüsse (inkl. Netzteil) hinten. Ob die nun aber tatsächlich auch IGMPv3 beherrschen (lt. Webseite nur v1/v2 und das auch nur bei den 5-Port-Modellen, bei den 8-Port-Modellen fehlt auch diese Angabe), weiß ich nicht ... aber QoS machen sie wohl nur fix portbasiert und nicht nach 802.1p.
Wobei dieses "QoS-Management" dann nach meinem Verständnis nur darin bestehen kann, daß Pakete von einem Source-Port mit hoher Priorität immer vor den Paketen anderer Ports eingereiht werden in der Target-Queue. Ob das bei einer funktionierenden GbE-Verbindung selbst bei HD-Voice-Streams wirklich einen Vorteil ggü. der "Bedienung reihum" bietet (und wir reden hier nicht von 48 Ports pro Switch), würde ich angesichts der Nettodatenrate selbst von HD-Voice eher bezweifeln. Wenn das am Zielport hängende Gerät der WAN-Router ist, sollte allerdings dieser tatsächlich eine Priorisierung erlauben ... aber das ist dann auch nicht mehr Aufgabe des Switches.
Wie das in einer Kaskade von solchen Switches dann überhaupt funktionieren soll, erschließt sich mir auch noch nicht. Wenn dann ein Switch sowohl ein "realtime communication device" und (sagen wir mal) ein NAS über einen gemeinsamen "uplink port" mit dem Rest des Netzes verbindet, in welchen Port eines Switches mit einem "portbasierten QoS" steckt man das Kabel mit dem Uplink dann eigentlich? Bei "high priority" kann ein simpler FTP-Transfer vom/zum NAS eine RTP-Verbindung eines anderen Gerätes (an einem anderen Port des Uplink-Switches mit niedrigerer Priorität) empfindlich stören, wenn die Daten nur schnell genug fließen können. An einem niedriger priorisierten Port tritt dieser Effekt dann für das eigene eine Ebene tiefer angeschlossene Telefon ein, wenn ein anderer Dienst am "high priority"-Port die Verbindung auslastet. Irgendwie kann ich mir solche Switches mit festen Port-Prioritäten nur in einer sehr sehr flachen Netzwerkstruktur (und damit entweder vielen langen Kabeln oder einer hohen Lokalität der Clients) mit nur wenigen Clients vorstellen. Oder kann mir jemand den Denkfehler meinerseits aufzeigen?
Hat zwar mit "Entertain" auch nur noch am Rande zu tun ... aber zumindest IGMPv3-Unterstützung kommt ja in diesem Beitrag auch noch vor.
Bleibt nur noch die Feststellung, daß es von der 8-Port-Variante v1, v2 und v3 gibt (bei der 5-Port wohl nur bis v2), wobei die v3 sogar derzeit die preiswerteste ist und bei einer Suche auf < 5 EUR/Port kommt. Allerdings muß man höllisch aufpassen, denn bei der 8-Port-Variante sind alle Versionen noch im Handel erhältlich.
Bei der 5-Port-Variante zahlt man zwar etwas mehr pro Port (knapp 6 EUR/Port), aber wenn man diesen Switch an einem Aufstellort benötigt, wo man definitiv nur eine begrenzte Zahl an Geräten anschließen will (meinetwegen in der Nähe des Fernsehers, wo dann die kommende Leitung, Smart-TV, STB, Game-Console und vielleicht noch ein AV-Receiver mit Internet-Radio angeschlossen werden sollen), dann ist dieses Gerät eben auch kleiner, fällt damit weniger auf und warum soll man für Ports Geld ausgeben, die man ohnehin nicht benutzt. Selbst wenn kein Port in Reserve offen bleibt, kann man notfalls später immer noch kaskadieren (oder doch austauschen), wenn es überraschend nicht reichen sollte.
Nicht unerwähnt sollte auch bleiben, daß es von TP-Link ein ähnliches Produkt wie den GS105E gibt, der heißt dann TL-SG105. Er kann wohl IGMP-Snooping und QoS nach 802.1p, aber kein VLAN (braucht damit auch keine Konfigurationsmöglichkeiten). Der kostet noch etwas weniger ... über die Qualität des Produkts kann ich selbst nichts berichten. Wenn es tatsächlich rein darum geht, das Netz nicht mit Multicast-to-Unicast-Traffic zu fluten, reicht der eventuell auch schon aus ... aber dann muß tatsächlich der Absender der Videodaten (wohl der SAT>IP-Umsetzer) die Pakete entsprechend taggen, wenn man von QoS profitieren will, was je nach Traffic-Volumen schon notwendig sein kann.
Ob man den (internen) VoIP-Traffic nun in einem eigenen VLAN isoliert (automatisch wie bei Cisco oder D-Link oder manuell) ist in meinen Augen reine Geschmackssache im Home-Network ... erhöhte Sicherheit erwarte ich davon nicht, solange der "Beitritt" eines Port zu diesem VLAN auf der Basis bestimmter Konditionen automatisch erfolgen kann.
In einem komplett geswitchten Netzwerk benötigt man ohnehin Zugriff auf einen der Knotenpunkte (also einen Switch oder ein Gateway), wenn man Pakete abfangen will, die nicht für die eigene MAC-Adresse (oder die Broadcast-Adresse) bestimmt sind. Hat jemand diesen Zugriff, sollte auch die Isolation in einem eigenen VLAN keine "echte Hürde" mehr sein. Rein für das Bandbreitenmanagement bringt VLAN-Tagging m.W. nur bei proprietären Implementierungen von Switch-Herstellern etwas, wenn anstelle von "richtigem QoS" eine Reservierung auf der Basis von VLAN implementiert ist (oder gar "feste Ports", wie beim Zyxel GS105S).
Wenn das IP-Telefonie-System seinerseits "ordnungsgemäß" das PCP-Feld auf 5 (Voice) oder 4 (Video) setzt, sollte jeder 802.1p-kompatible Switch damit klarkommen ... meines Erachtens braucht es keine weitere Priorisierung von IP-Telefonie. Vielleicht habe ich aber auch nur etwas fundamental falsch verstanden ... bei einem Router (der das originale IP-Paket ändert im Unterschied zum Switch) gibt es natürlich mehr Notwendigkeiten/Möglichkeiten, da etwas zu konfigurieren.
Um auch noch mal auf die im anderen Thread hinzugekommene "Forderung" nach rückwärtigen Anschlüssen einzugehen ... die passenden Zyxel-Modelle haben m.W. auch alle die kompletten Anschlüsse (inkl. Netzteil) hinten. Ob die nun aber tatsächlich auch IGMPv3 beherrschen (lt. Webseite nur v1/v2 und das auch nur bei den 5-Port-Modellen, bei den 8-Port-Modellen fehlt auch diese Angabe), weiß ich nicht ... aber QoS machen sie wohl nur fix portbasiert und nicht nach 802.1p.
Wobei dieses "QoS-Management" dann nach meinem Verständnis nur darin bestehen kann, daß Pakete von einem Source-Port mit hoher Priorität immer vor den Paketen anderer Ports eingereiht werden in der Target-Queue. Ob das bei einer funktionierenden GbE-Verbindung selbst bei HD-Voice-Streams wirklich einen Vorteil ggü. der "Bedienung reihum" bietet (und wir reden hier nicht von 48 Ports pro Switch), würde ich angesichts der Nettodatenrate selbst von HD-Voice eher bezweifeln. Wenn das am Zielport hängende Gerät der WAN-Router ist, sollte allerdings dieser tatsächlich eine Priorisierung erlauben ... aber das ist dann auch nicht mehr Aufgabe des Switches.
Wie das in einer Kaskade von solchen Switches dann überhaupt funktionieren soll, erschließt sich mir auch noch nicht. Wenn dann ein Switch sowohl ein "realtime communication device" und (sagen wir mal) ein NAS über einen gemeinsamen "uplink port" mit dem Rest des Netzes verbindet, in welchen Port eines Switches mit einem "portbasierten QoS" steckt man das Kabel mit dem Uplink dann eigentlich? Bei "high priority" kann ein simpler FTP-Transfer vom/zum NAS eine RTP-Verbindung eines anderen Gerätes (an einem anderen Port des Uplink-Switches mit niedrigerer Priorität) empfindlich stören, wenn die Daten nur schnell genug fließen können. An einem niedriger priorisierten Port tritt dieser Effekt dann für das eigene eine Ebene tiefer angeschlossene Telefon ein, wenn ein anderer Dienst am "high priority"-Port die Verbindung auslastet. Irgendwie kann ich mir solche Switches mit festen Port-Prioritäten nur in einer sehr sehr flachen Netzwerkstruktur (und damit entweder vielen langen Kabeln oder einer hohen Lokalität der Clients) mit nur wenigen Clients vorstellen. Oder kann mir jemand den Denkfehler meinerseits aufzeigen?
Hat zwar mit "Entertain" auch nur noch am Rande zu tun ... aber zumindest IGMPv3-Unterstützung kommt ja in diesem Beitrag auch noch vor.
