DocData

Es ist absolut nichts ungewöhnliches. Mit genügen krimineller Energie geht viel, deswegen muss es ein entsprechendes Logging geben. Der Rest ist Konfigurationsaufwand. Im Vorfeld sollte aber klar abgesteckt werden wer was können muss. Abschließend ist ein Berechtigungssystem im Sinne eines RBAC aufzubauen.

Aha... Und wie wahrscheinlich ist es, dass die genannten Switches wegen ein paar BPDU Paketen schlapp machen? Eher unwahrscheinlich... Zudem würde sich das Problem anders äußern. KISS. In dem Konstrukt ist es total egal wo Server und DSL angeschlossen werden. Das ist ein Mininetzwerk.

Du hast Topology Changes? Wie oft kommen die vor? Das ist Murks. Du behebst ein Symptom, nicht das Problem. Mal etwas zum Thema "Der Switch ist evtl. ausgelastet": Selbst die Popel-Switches machen auf der Backplane ~ 100 Gb/s und bei 64 Byte Paketen schleust der ~77 Millionen Pakete pro Sekunde dadurch. Man kann vielleicht einen oder mehrere Ports auslasten, aber nicht den ganzen Switch. Sollte ein Port ein Bottleneck sein, dann sieht man aber auch das relativ schnell.

Igitt... dann müsste man dem Computerobjekt das Recht verweigern den Computerteil der GPO zu ziehen. Geht über Delegation > Advanced > Read > Deny. Sehr ekelhaft. Das gilt dann aber für alle Benutzer.

Ich sag das ja nur ungern, aber da ist keine Fehlermeldung. Ich denke du spielst auf das "[ETHERNET FRAME CHECK SEQUENCE INCORRECT]" an. Das ist kein Fehler, das ist normal. Man kann Wireshark sagen, dass es die Frame Checksumme nicht prüfen soll ("Validate the Ethernet checksum if possible"). Das Artefakt was du da beobachtest und für einen Fehler hälst liegt darin begründet, dass die FCS durch die NIC berechnet und an den Frame angehangen wird. Wireshark bekommt das nicht mit. Ansonsten ist es natürlich völlig korrekt das du die STP Pakete alle 2 Sekunden siehst. Du hast da ein stinknormales BPDU Paket gesnifft. Wenn du STP für das Problem hälst, dann konfiguriere es endlich ordentlich auf allen Komponenten. Ich habe hier in meinem Lab 1910-24G, 1910-8G und 5820. Wenn ich nur die beiden 1910-24G und 1910-8G betrachte (werden bei mir für ein paar Thin Clients, Lab Firewall etc. verwendet), dann funktionieren die einwandfrei - sogar mit aktiviertem RSTP.

Und wo ist da die Fehlermeldung?

Ich warte gespannt auf die Fehlermeldung.

Hä? Der 1910-48G macht auf der Backplane ~100 Gb/s bei 48 1 GbE Ports. Wie kommst du auf die 10 Gbit? Der 5406zl macht 380 Gb/s im Backend, also der Fabric. Den kannst du also entspannt mit 144 1 GbE Ports vollmachen, volle Möhre auf allen Ports und der fängt nicht mal an zu schwitzen.

Korrekt. Der Frame kommt ohne Tag an, der Port ist untagged Member eines VLANs und damit bekommt der Frame beim Ankommen (quasi für den Transport innerhalb des Switches) das Tag für das VLAN, in dem der Port untagged Member ist. Ich weiß nicht ob ich dich hier richtig verstehe. Wenn nun ein Frame einen der Ports (21,22,23,24) verlässt, dann bekommt er beim ausgehen das Tag (bzw. er behält es) das er bekommen hat. Der Switch MFSYS macht damit nichts, kann aber den Frame an die NICs weiterleiten, die Mitglied des VLANs sind. Da die NICs eine VLAN ID zugeordnet bekommen haben, muss der Frame über ein VLAN Tag verfügen.

Wie wäre es mit einer sauberen Problemanalyse und anschließend einer zielgerichteten problemlösung? Aber die meisten hier scheinen sich eher an approximativen Problemlösungsverfahren zu erfreuen...

*reiße die Arme hoch* *Jubel* Getroffen!

Das hat er getan. Lies es dir noch mal durch. Hat er doch. Die Firma hat er doch neu aufgetan. Du bist kein Dienstleister, oder?

Das Backupsoftware zum Sichern von Postfächern (was eh nicht supported ist) Vollzugriff braucht, ist mir neu. Sicher die Datenbanken und wenn du ein Postfach oder ein Objekt daraus brauchst, dann arbeite mit Wiederherstellungsdatenbanken. Dann ist es sauber.

Intern taggen Switches alle Frames. Kommt ein Frame auf einem Port rein, der tagged Member eines VLANs ist, dann muss dieser Frame ein VLAN Header enthalten. In diesem Fall muss das Endgerät den Frame den VLAN Tag verpasst haben. Kann das angeschlossene Endgerät keinen Tag setzen, dann muss der Port untagged Member des VLANs sein. Im Umkehrschluss wird ein Switch, wenn ein Frame einen Port verlässt, das VLAN Tag entfernen, wenn der Port untagged Member ist, und den VLAN Tag NICHT entfernen, wenn der Port tagged Member ist. In letzteren Fall muss das Endgerät den VLAN Tag interpretieren können.

An einer für beide Seiten gewinnbringenden Partnerschaft. Hört sich doof an, ist aber langfristig die beste Variante. Im oben genannten Fall hat der Vertriebler den Kunden (absichtlich oder unabsichtlich) über das Ergebnis der Analyse, den Grund für die Fehler und den Funktionsumfang der Switches belogen. Sowas sind immer Steilvorlagen für andere Dienstleister. Ich habe sowas schon mehrfach genutzt. Viele Kunden die ich betreue, betreue ich seit über 10 Jahren. Das macht man nicht, wenn einer den anderen besc***t...

Entschuldige bitte, aber das war total unseriös. Die Techniker offenbar planlos, der Vertrieb nur am Verkaufen interessiert. Was für Verlierer...

Tolle Fachfirma. Der hätte bei mir nicht mal seinen Kaffee austrinken dürfen....

Eine schleife würdest du auch anders erkennen. Hänge dich NICHT an einen Monitoring Port und achte auf Verkehr den du nicht sehen solltest. Also alles was nicht an dich adressiert ist und nicht Multicast/ Broadcast ist. Siehst du diesen Verkehr, dann hast du irgendwo einen Loop. Auch der 1920 ist ein Comware Device.

Die V1910 sind 3COM/ Comware. Die kennen kein "show tech all"....

Warum nicht "Associate Vice President"?

Da waren ja wohl Profis am Werk. "Duplicate Acks" im Wireshark sind das typische Ereignis einer sog. "out out order arrival", also wenn Pakete nicht in der Reihenfolge beim Empfägner ankommen wie sie sollten oder ein Anzeichen für Packet Loss. Jumbo Frames können bedenkenlos aktiviert bleiben. Viele Switches haben es heute per Default an. Flow Control ist wohl auch weniger das das Problem. Probleme deren Lösung "Flow Control" heißt würden sich anders bemerkbar machen und die Indizien hätte man wohl mittlerweile gefunden. Wenn ich spekulieren dürfte: Verkabelung.

Bin ich der einzige der gerade wild schreiend und mit den Armen wedelnd durch die Gegend laufen will??

Also beim 1910 der hier in meinem Lab läuft geht es mit der Standard-Firmware... btw: HP Silver Partner wird man mit ein paar Sales und einfachen technischen Zertifizierungen. Der Partnerstatus ist kein Garant für technisches Knowhow.

Wenn sich die Threads hier im Forum das das Notwendigste beschränken würden, dann wäre es hier sehr, sehr, sehr trostlos...

Dell baut keine Switches, die kleben nur ihren Namen darauf. Die haben in den letzten 15 Jahren so ziemlich alles verkauft: Cisco, Juniper, Brocade, OEM Broadcom. 2010 oder 2011 haben sie Force10 gekauft. Der WLAN Kram ist AFAIK von Aruba.