DeathAndPain

Du bist ein Engel! Das hat funktioniert. Daß man Benutzer in Gruppen mit bestimmten Berechtigungen zusammenfassen kann hatte ich verstanden, aber daß man auch Gruppen in Gruppen reinpacken kann, war mir nicht klar. Jetzt funktioniert alles. Vielen Dank!

Wenn ich mich an einem Endanwender-Rechner, der zu einer der beiden Domänen gehört, anmelden möchte, dann bekomme ich im Dropdown beide Domänen für die Anmeldung zur Auswahl. Allerdings hat das mit der oben geschilderten Problematik nichts zu tun.

Wie soll ich das genau tun? Wenn ich in den Eigenschaften eines Benutzers die Gruppen auswähle, zu denen er gehören soll, dann werden mir nur die Gruppen der jeweiligen Domäne angeboten, nicht die anderer Domänen. Ich bin bislang davon ausgegangen, daß, wenn der Administrator einer Domäne Mitglied von "Domänen-Admins" in seiner Domäne ist, er dann auch die Privilegien dieser Gruppe in anderen Domänen genießt, mit denen eine wechselseitige Vertrauensstellung besteht. Wenn das nicht so ist, wo und vor allem wie muß ich ihn dann eintragen? Zur Veranschaulichung: Die FIBU-DOMÄNE und die SRV-DOMÄNE stehen in wechselseitiger Vertrauensstellung. Der Administrator der FIBU-DOMÄNE möchte auf eine Datei in der SRV-DOMÄNE zugreifen. Seine Gruppenmitgliedschaften sind wie folgt: Er navigiert jetzt in der SRV-DOMÄNE zu einer Datei und ruft dort Eigenschaften -> Sicherheit -> Berechtigungen auf: Hier bekommt er die Meldung, daß er die Sicherheitseigenschaften nur anzeigen darf. Das darf er offenbar, weil "Jeder" auf RX steht. Nur sollte er meiner Meinung nach eigentlich die DOMÄNEN-ADMINS-Rechte besitzen... Auffallen tut natürlich, daß in obiger Rechteliste ausdrücklich "SRV-DOMÄNE\DOMÄNEN-ADMINS" steht. Das macht schon den Eindruck, als ob es (trotz der Vertrauensstellung?) einen Unterschied zu "FIBU-DOMÄNE\DOMÄNEN-ADMINS" gibt. Aber wenn das so ist und wenn das der Grund für die fehlenden Zugriffsrechte ist, wie bekomme ich dann den Administrator (FIBU) in die Gruppe "SRV-DOMÄNE\DOMÄNEN-ADMINS"?

Ich habe eine neue NT 4.0-Domäne (mit neuem PDC) aufgesetzt und eine wechselseitige Vertrauensstellung mit meiner bereits bestehenden Domäne eingerichtet. Die Vorgehensweise war lehrbuchmäßig: Erst auf beiden Seiten die jeweils andere als "Berechtigt, dieser Domäne zu vertrauen" eingetragen und dann auf beiden Seiten die jeweils andere unter "Vertraute Domänen" eingetragen. Das System hat auch in beiden Fällen gemeldet, daß die Vertrauensstellung korrekt eingerichtet wurde. Dennoch stelle ich fest, daß ich als Administrator der einen Domäne keine Berechtigung habe, auf Verzeichnisse zuzugreifen, deren Zugriffsrechte Vollzugriff für "Administratoren" und "Domänen-Admins" vorsehen. Habe ich irgendwas übersehen?

Also daß jemand durch unsere € 20000-Firewall hindurch unseren PDC aushebelt, möchte ich eigentlich ausschließen. Zumal wir entsprechend üblicher Sicherheitsstandards nicht eine Regel in der Firewall haben, die einen direkten Durchgriff vom Internet aus in das interne Netz erlaubt.

Hunderte, Tag für Tag. Das ist normal, wenn man eine feste IP hat (sofern man Port-Scans schon als Angriff gelten läßt). Aber die scheitern an der CheckPoint-Firewall, die wir auch auf dem aktuellen Stand halten. Bei den NT-Servern sollte also nichts davon ankommen.

Unser NT-4.0 PDC demotet sich immer wieder selber. Es sind dann zwei BDC (er und der richtige BDC) und kein PDC mehr in der Domäne vorhanden. Ich promote ihn dann wieder zum PDC. Aber nach einem unregelmäßigen Zeitabstand - mal ein paar Stunden, mal ein paar Tage - ist er dann plötzlich wieder BDC. Anmeldungen nimmt er als solcher natürlich trotzdem entgegen. Ich merke das in der Regel erst dann, wenn ich mal wieder den Benutzer-Manager oder den Server-Manager aufrufe (weil er dann meckert, daß er den PDC nicht finden kann). Bisher ist es mir nicht gelungen, ein System zu erkennen, wann genau der automatische Demote erfolgt. Kennt jemand dieses Phänomen oder generell Situationen, in denen sich ein PDC selber demotet (außer, wenn ein BDC promotet wird)? Im Event Log sind für den fraglichen Zeitraum keine außergewöhnlichen Meldungen drin.

Der Knowledgebase zufolge war NT 4.0 das erste Windows NT, bei dem das so funktioniert hat. Ich hab das jetzt auch ausprobiert. Er macht es, löscht dabei aber die Bits mit den Werten 8 und 16 gleich mit. Damit bleibt meine Frage offen, welche möglicherweise nützlichen Funktionalitäten in diesen Bits versteckt sind.

Hallo, auf der Seite http://www.oreilly.com/catalog/winlog/chapter/ch02.html steht in der Mitte (sucht auf der Seite nach dem Wort "print", um die Stelle zu finden), wie man das Event Logging bei Print Spooler Events einschränkt. Die hier wiedergegebene Differenzierung in Information, Warning und Error messages kann ich jedoch in der MS Knowledgebase nicht wiederfinden. Auch die aus der o.g. Seite referenzierten Knowledgebase-Artikel 143132 und 115841 geben nur an, daß man das Logging durch Setzen einer 0 im DWORD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Providers\EventLog komplett abschaltet. Die Differenzierung finde ich aber nützlich (ohne sie schon ausprobiert zu haben). Ich stelle jedoch fest, daß in diesem Registrierungsschlüssel bei meinem NT 4.0-Server vorgabemäßig eine 31 steht. Nachdem die o.g. Seite nun die Bitwerte für 1, 2 und 4 beschreibt, würde ich gerne wissen, wofür die restlichen Bits (8 und 16) stehen, bevor ich sie einfach abschalte.

Vielen Dank für den Hinweis. Leider funktioniert das Programm offenbar nicht. Ich hab es mit einem Dokument ausprobiert und den von Dir genannten Haken gesetzt. Er meinte denn auch, daß das File successfully gescrubbt worden sei. Ein nachfolgender "Analyze" ergab aber, daß sich das in der Datei hinterlegte Template nicht verändert hat. Dabei spielt es keine Rolle, ob ich den Haken für das Überschreiben des Originals setze oder hinterher die _scrubbed-Kopie analysiere.

Na ja, das wird bei diesen Dokumenten "\\WIN-BLN\Vorlage\Transktionsvorlage.dot sein". Wobei WIN-BLN der alte, nicht mehr existierende Server ist. Auf dem neuen Server liegt die entsprechende Vorlage in einer namensgleichen Freigabe, aber wenn der konkrete UNC samt Servername in den Dokumenten gespeichert ist, dann habe ich davon nichts. Jetzt würde ich zunächst mal gerne wissen, an welcher Stelle ich die referenzierte Vorlage ändern kann, wenn ich eines dieser Dokumente in Word 97 öffne. Unter Menü Datei -> Eigenschaften habe ich auf keiner Registerkarte einen Verweis auf die Vorlage gefunden. Die nächste Frage wäre die nach einem gangbaren Weg für die Massenänderung. Hunderte von Word-Dokumenten händisch anzupassen ist nicht wirklich praktikabel.

zu 1.: Nein, das Zeitverhalten ist in all diesen Fällen dasselbe. zu 2.: Nein, Caches scheinen da keine Rolle zu spielen. zu 3.: Word-Dokumente sind die einzigen, bei denen dieses Verhalten bislang aufgefallen ist. Stichprobenweise hatte ich nicht den Eindruck, daß die Problematik auch bei anderen Dateitypen besteht. zu 4.: Dies scheint nicht der Fall zu sein (ohne jedes einzelne geprüft zu haben). zu 5.: Ich habe den Batch zwar nicht implementiert, aber er macht doch letztlich nichts anderes, als die Datei zuerst auf die lokale Festplatte zu kopieren und dann von dort aus zu starten. Dies habe ich - wie schon oben erläutert - händisch ausprobiert, indem ich das Word-Dokument mit dem Windows Explorer auf die lokale Festplatte kopiert und dann mit Word von dort aus geöffnet habe. Die Wartezeit bestand auch dann. Einen Fortschritt habe ich bereits erzielt: Ich habe den alten, abgeschalteten Server aus der WINS-Datenbank herausgenommen. Dadurch kann sein Name nicht mehr in seine IP aufgelöst werden. In der Folge kann der Client für diese IP auch keine ARP-Anfrage mehr stellen. Dadurch konnte ich die Wartezeit schon mal auf wenige Sekunden reduzieren. Sie besteht jetzt anscheinend nur noch aus der Zeit, die der Client braucht, die WINS-Anfrage erst an den primären WINS-Server, dann an den sekundären WINS-Server und schließlich per Broadcast rauszuschicken und auf eine Antwort zu warten (beobachtet mit Netzwerksniffer). Nachdem er einsieht, daß er die nicht bekommen wird, öffnet er anstandslos das Dokument.

Beim Öffnen bestimmter Word-Dokumente aus unserer Dateiablage vergehen seit einiger Zeit präzise 45 Sekunden, bevor Word 97 das Dokument öffnet. Dies scheint damit zusammenzuhängen, daß die Dateiablage vor ein paar Tagen auf einen neuen Server umgezogen ist. Nutrition Facts Die meisten, aber nicht alle Word-Dokumente sind betroffen. Die Zeitdauer scheint nicht mit der Größe des Word-Dokumentes zusammenzuhängen. Nur sehr kleine Dokumente scheinen nicht betroffen zu sein. Könnte aber auch Zufall sein, daß ich bei den sehr kleinen nur mit nicht betroffenen getestet habe. Es liegt nicht am Netzwerk, zumindest nicht direkt: Wenn ich mir ein betroffenes Dokument mit dem Explorer auf die lokale Platte kopiere, dann läuft der Kopiervorgang mit voller LAN-Geschwindigkeit ab. Will ich es anschließend mit Word 97 von der lokalen Platte öffnen, muß ich die 45 Sekunden warten. Das Phänomen wurde an verschiedenen Endanwender-Clients nachvollzogen; es liegt also nicht an einem bestimmten Endanwender-PC. Manche der Word-Dokumente enthalten Hyperlinks, doch auch Dokumente, die keine Hyperlinks enthalten, sind betroffen. Im Event Log von Windows wird während der Wartezeit nichts geloggt. Während der Wartezeit sehe ich mit einem Netzwerksniffer ARP-Pakete, die aus meinem PC abgehen. Darin sucht er nach dem alten Server. Der ist jedoch nicht mehr am Netz; die ARP-Pakete bleiben unbeantwortet. Die Frage scheint nun zu sein, an welcher Stelle in den Dokumenten es noch einen Verweis auf den alten Server gibt, durch den die ARP-Pakete ausgelöst werden. Ich denke da in die Richtung, daß vielleicht irgendwo in den Dateiattributen noch der alte UNC-Pfad steht, und Word da beim Öffnen der Datei einfach mal nachsieht. Wie kann man der Sache auf den Grund gehen? Teilweise handelt es sich bei den Dokumenten um primitive Einseiter. Ob er vielleicht den Namen der Vorlage, mit der das Dokument seinerzeit angelegt wurde, nebst UNC-Namen des damaligen Servers irgendwo in den Dokumenteigenschaften abgelegt hat? Wenn ja: Wie kriegt man den geändert, besonders bei einer großen Anzahl an Dokumenten?

Vielen Dank. Ich habe die beiden anderen Server vorläufig mal abgeschaltet, denn ein ausgeschalteter Server wird sicherlich keine Client-Anmeldungen entgegennehmen. Aber jetzt stehe ich plötzlich vor folgendem Phänomen: Ich starte den Server-Manager auf dem PDC. Der listet sich selber und den anderen (richtigen) BDC jetzt aber beide als BDCs der Domäne! Laut dieser Server-Manager-Liste gibt es in dieser Domäne derzeit keinen PDC mehr. An dieser Stelle ergeben sich folgende Fragen: Ist der PDC wirklich nicht mehr PDC (d.h. hat er sich selber aus irgendeinem Grund demotet), oder stimmt nur was in der Server-Manager-Anzeige nicht? Kann ich einfach hingehen und den Rechner wieder zum PDC promoten? Oder könnte es aufgrund der unklaren Ausgangslage dazu kommen, daß er dann die Beine durcheinanderkriegt (weil er ja eigentlich schon vorher PDC war)?

Im Rahmen einer Serverzusammenfassung sind wir auf einen neuen NT 4.0 PDC umgezogen. Zwei schon bisher vorhandene NT 4.0-Server waren bislang BDC. Diese Funktion sollen sie jetzt aber nicht mehr erfüllen. Also habe ich sie auf dem neuen PDC aus der Domäne rausgenommen. Das hat soweit auch geklappt. In der Anzeige im Server-Manager stehen sie aber noch als BDCs drin. Wenn man nochmal versucht, sie aus der Domäne rauszunehmen, dann kommt eine Meldung, daß sie in Wahrheit gar nicht mehr in der Domäne drin seien und dies bei der nächsten Aktualisierung nach 15 Minuten auch im Server-Manager aktualisiert werden würde. Doch auch nach einer Woche stehen sie noch unverändert drin. Es ist dabei egal, ob ich im Server-Manager des PDC oder der alten BDCs nachsehe. Das Verhalten ist überall dasselbe. Unangenehmer noch: Diese Zombie-BDCs nehmen offenbar auch noch Domänenanmeldungen von Clients an. Dies erkenne ich daran, daß Clients nach der Domänenanmeldung mit den alten Login-Skripten starten. Die Replikation der aktuellen Skripte vom PDC habe ich natürlich nicht auf die alten BDCs ausgedehnt, weil die ja keine BDCs mehr sein sollen. Hierzu habe ich folgende Fragen: Wann werden Server-Änderungen (Mitgliedschaft und Funktion in der Domäne) im Server-Manager tatsächlich wirksam? Das mit der Viertelstunde ist ja offenbar eine Lüge. Wie kann ich der Sache Beine machen? Was kann ich in diesem Zusammenhang sonst noch tun? Schönen Dank im voraus, Jens

Aber wenn ich das Kabel frisch verlegt und die Stecker angequetscht habe, dann kann ich an die beiden Enden dieses einen Kabels je einen PC anschließen und schauen, ob ich die volle Datenrate über dieses Kabel übertragen kann (mit einem Tool wie netio). Wenn ja, dann kann ich das Kabel (einschließlich gecrimpter Stecker) als brauchbar ansehen. Maximaler Pechfall wäre, daß meine Test-PCs mit der Kabelqualität gerade noch klarkommen, die Switches für den Realbetrieb aufgrund anderer Bauteiltoleranzen aber nicht mehr. Aber dieses Risiko halte ich für sehr gering. Ist an diesem Ansatz etwas auszusetzen? Nebensprechen entsteht aber nicht durch mangelhaft gequetschte Stecker, sondern hängt hauptsächlich von der Qualität des Kabels selbst ab. Da könntest Du mit Festverlegekabel genauso viel oder wenig Probleme haben. Man kann auch gegen Nebensprechen abschirmen - und das dürfte der Sinn einer adernpaarweisen Schirmung sein. Wie lefg zu Recht angemerkt hat, ist Nebensprechen durchaus ein Faktor bei der Übertragungsqualität. Insofern wäre es schon interessant, ob ein Kabel, das das Siegel "STP" trägt, in jedem Fall mit der höherwertigen adernpaarweisen Schirmung ausgestattet ist.

Wenn Du die von Dir zitierten englischen Formulierungen genau durchliest, dann definieren die STP eindeutig mit Schirm um die einzelnen Adernpaare. Ergänzend ("optional") kann dann noch ein zusätzlicher Schirm um das ganze Kabel hinzukommen. UTP definieren sie hingegen als Kabel mit Adernpaaren ohne jeden Schirm. Damit wäre ein TP-Kabel mit den üblichen vier Adernpaaren und lediglich einem Schirm um das ganze Kabel herum weder UTP noch STP, sondern irgendwas dazwischen. Die Frage ist allerdings, ob das Glossar, auf das Du Dich beziehst, tatsächlich die allgemeingültige Definition darstellt, oder am Ende auch nur die Privatmeinung der Webseitenautoren von Castle Networking. Ich habe einen LAN-Tester, allerdings nur auf dem Niveau "verbunden oder nicht verbunden". Damit erkenne ich grobe Fehler wie vertauschte Adern, kann aber keine Leitungsdämpfung und dergleichen messen. Geräte, die das können, kosten über 4000 Euro. Aber ich kann hingehen und den effektiven Datendurchsatz messen. Im Netz werden sich Störungen nicht weiter ausbreiten, weil an beiden Enden Switches hängen. Wenn ich Probleme habe, kann ich auf gut Glück einen Stecker abschnippeln, neu quetschen und wieder testen. Dieser Ansatz ist sicherlich nicht für einen Installateur geeignet, der jeden Tag Dutzende Kabel verlegt, aber für zwei Einzelleitungen kann man den Aufwand schon treiben. Und wenn ein Draht nicht optimal aufgelegt ist? Das würde ich auch nur durch eine Messung rausbekommen.

Dieser Einwand ist aber rein theoretischer Natur. Wenn ich mit den verschiedensten Leuten im Internet chatte, die teilweise in Amerika sitzen, dann ist da in der Praxis nicht nur ein Hop dazwischen. Im übrigen sind die Router im Internet auch nicht alle direkt mit einem Kabel verbunden. Da sitzen auch jede Menge Switches dazwischen. In der Praxis hast Du im Internet auf jeden Fall bedeutend mehr verzögernde Elemente als in einem halbwegs vernünftig strukturierten LAN. Auf jeden Fall aber muß er alles das auch tun, was ein Switch machen muß. Die Switching-Funktionalität ist gewissermaßen eine Teilmenge der Routing-Funktionalität. Damit kann der Router nicht schneller sein als ein Switch (es sei denn, Du verwendest höherwertige Hardware, aber das kannst Du beim Switch auch jederzeit tun). Dein Argument, daß im Internet nicht geswitcht, sondern geroutet wird, ist damit gegenstandslos (und noch nicht mal richtig, denn Switches hast Du im Internet außerdem). Die Signallaufzeit kann aus den oben genannten Gründen beim Einsatz von Routern bestenfalls genauso gut sein wie beim Einsatz von Switches. Und um Beeinflussungen der Signallaufzeit, um Jitter und Lag ging es in dieser Diskussion. Auf diesem Hintergrund bitte ich Dich, mir nicht böse zu sein, aber Du bist jetzt wirklich kleinkariert, und Deine Argumente sind im Sinne dieses Threads in keiner Weise zielführend.

Da gehen die Definitionen aber auch etwas durcheinander. Die einen betrachten es als STP, wenn ein Metallfolienmantel außen um die vier Adernpaare gelegt ist. Andere behaupten, daß STP für einzeln geschirmte Adernpaare steht (und den Außenmantel noch obendrauf). Ich muß gestehen, daß ich nicht mit Sicherheit sagen kann, was nun Lüge und was wahr ist. Wenn man 100BaseTX macht und die freien Adernpaare für ISDN nutzt, ist eine paarweise Schirmung sicherlich wichtig. Aber ist Übersprechen zwischen den verschiedenen Adernpaaren desselben Patchkabels bei 1000BaseT tatsächlich ein gravierendes Problem? Die Wahrheit ist eine Büroumgebung. Das Kabel wird durch einen doppelten Fußboden gelegt (abhebbare Bodenplatten mit 10-20cm Luft zum Betonfußboden drunter). Hinten geht es dann durch ein Loch im Beton in die nächste Etage hoch. Soweit zumindest die momentane Planung. Ich hatte nicht vor, es mit Starkstromkabeln zu bündeln. Dennoch kann es schon mal vorkommen, daß mein Patchkabel an solch Leitung vorbeikommt. Ich werde das von der 100m-Rolle verlegen und die Stecker selber anquetschen (Hirose). Wenn ein Stecker mangelhaft gequetscht sein sollte, kann ich den also abkneifen und einen neuen anquetschen. Allerdings habe ich nicht das Meßwerkzeug, um die Leitungsqualität richtig durchzumessen.

Das mit den Routern ist zwar richtig, ist aber für diese Frage belanglos. Lag und Jitter werden nicht dadurch geringer, daß man Router statt Switches einsetzt. Bei Routern würde ich eher mit noch größeren Signalverzögerungen rechnen (wegen der aufwendigeren Paketverarbeitung).

Also wenn der Rechner 2 nicht mal seine eigene IP erfolgreich anpingen kann, dann stimmt bei der Maschine was in der Konfiguration ganz gewaltig nicht. Vielleicht ist was in der Routingtabelle falsch. Obwohl Windows die Routingtabelle normalerweise automatisch so weit pflegt, daß man sich selber anpingen kann.

In der c't stand, daß Patchkabel (d.h. Netzwerkkabel für flexible Verlegung) nur bis maximal 5m pro Seite zugelassen sind (laut Spezifikation). Für die richtige Distanz müsse man Festverlegekabel verwenden, da dieses bessere elektrische Eigenschaften habe. Ich würde gerne wissen, wie ernst man das nehmen muß. Ich will nämlich zwei Gigabit-Switches über Cat. 5e-Flexkabel vernetzen (ca. 30m Distanz, mit Außenschirm, aber ohne zusätzliche Einzelschirmung der Adernpaare). 19"-Rackschränke mit Patchpanels möchte ich mir kneifen. Aber nur zwischen Patchpanels bzw. Dosen kann man Festverlegekabel legen (das kann man nicht einfach an einen RJ45-Stecker quetschen). Mein Ansatz hat elektrisch natürlich den Vorteil, daß ich weniger Steckkontakte habe. Es entfallen die Anklemmungen in den Dosen auf beiden Seiten sowie die Steckkontakte der üblichen Patchkabel. In meinem Fall wäre es einfach ein 30m langes Patchkabel direkt von Switch zu Switch. Wird das hinhauen?

Dann halte ich die IP-Phones technologisch für Pfusch. Schon vor Jahren habe ich mit dem Battle.com bei einer gepflegten Runde Starcraft über das Internet mit meinen Mitspielern gechattet. Das Internet war damals noch weit weniger leistungsfähig als heute, meine Anbindung bestand aus einem 56k-Modem und die dadurch bereitgestellte Bandbreite mußte sich der Battle.com mit den laufenden Verbindungsdaten des Online-Spieles teilen. Dennoch war es zumindest häufig möglich, sich knackfrei wunderbar zu unterhalten. Heutzutage habe ich in dem Bereich überhaupt keine Probleme mehr. Battle.com ist zwar Geschichte, aber es gibt genug andere Programme, die Sprache über IP übertragen. Es ist also machbar, die Frage ist nur, wie gut die Implementierung ist. Du redest von Jitter. Dieses Problem löst man klassisch durch Puffer. Man spielt die eingehenden Audiodaten erst mit einer gewissen Verzögerung ab. So haben verspätete Pakete noch die Chance, rechtzeitig einzutreffen. Wenn man diese Methodik übertreibt, entstehen freilich merkwürdige Gesprächspausen, in denen der eine Gesprächsteilnehmer auf Antwort wartet, während der andere noch zuhört. Also muß man die Puffergröße mit Bedacht wählen, um ein möglichst gutes Ergebnis zu erzielen. Im Internet mag sich eine gewisse Einschränkung durch diesen Kompromiß nicht vermeiden lassen. Aber in einem LAN mit 100 MBit oder sogar noch mehr sollte das kein Problem sein. Es sei denn, einige User kopieren gigabyteweise Daten durch die Leitung. Aber einzelne Broadcast-Paketchen sind da kein Thema.

Das klingt mir aber eher nach QoS (Quality of Service; Bandbreitenreservierung) als nach einem Problem der Anzahl hintereinandergeschalteten Switches. In dem Fall muß man also Geräte verwenden, die QoS unterstützen. Andererseits - im Internet hat man auch kein QoS und zudem riesige Distanzen, und dennoch chatte ich per Headset ganz wunderbar mit Leuten, die teilweise in Venezuela sitzen. Man mag innerhalb einer Firma noch etwas höhere Ansprüche an die Sprachqualität stellen, aber dafür reden wir in dem Fall von einem LAN mit viel kürzeren Distanzen und viel höherer Bandbreite. Insofern ist mir nicht ganz klar, wie es da zu einem qualitativen Engpaß kommen soll. Es sei denn, die für die Sprachübertragung verwendete Software ist minderwertig (Kompression, ...).

Umm... Repeater und Hubs waren eigentlich nicht Gegenstand dieses Threads... Also Switches kann man beliebig viele hintereinanderschalten?