01.03.2012, aktualisiert um 21:07:02 Uhr

7280

Viele, viele unbekannte Netzwerkpakete

In einer Arbeitsgruppenumgebung mit zwei Windows 2003 Servern und ca. 30 Clienten haben wir folgendes Problem:

Auf dem großen (also der Server, der die meiste Last trägt) Server kommen, laut WireShark Analsyse , ohne Ende unbekannte Pakete von diversen Clienten an und ich habe den Verdacht, das diese unbekannte Pakete zum großen Teil dafür sind, das die Netzwerkperformance sehr schankend (mal sehr schnell, mal äusserst langsam) ist.

Kann mir jemand sagen, wie ich die Ursache dieser unbekannten Pakete sein könnte?

Der Port auf dem Switch wurde schon mehrfach gewechselt und der Elektriker hat das Netzwerk auch schon durchgemessen und hat keine Probleme festgestellt.

Danke für Eure Hilfe!

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 181319

Url: https://administrator.de/contentid/181319

Ausgedruckt am: 19.11.2024 um 22:11 Uhr

39 Kommentare

Neuester Kommentar

Was sind "unbekannte Pakete"?
Haben die keinen Zoll-Stempel?

Mal ehrlich, in einem Produktiv-Netzwerk auch mit nur 30 Clients wandern normalerweise über 500 Pakete pro Minute (bei aktiven Übertragungen noch viel mehr), das ist ganz normales Grundrauschen.

Nen gewisses Grundrauschen, ok, aber wenn jedes zweite oder dritte Paket als "unbekannt" indentifiziert wird, finde ich das schon eher merkwürdig.

IT Performance ist eine Wissenschaft.

Da sollte alles passen damit es "aus Anwendersicht rein subjektiv" schnell flutscht mit den bits und bytes.
Paar Punkte auf die Schnelle...

1. Netzwerk
Ungünstiges Netzdesign / Nadelöhr Switchuplink oder Serveranbindung
Duplex / Speed Probleme?
Bandbreite messen (zb ftp end-to-end download).
Lahme WAN Bandbreite? Wanbeschleuniger sinnvoll?
Ungünstige Zweck-Planung (z. B. die Leute müssen ständig riesen Datenmengen über lahme Leitungen transferierne anstatt lokal schnelle Server u. Netzanbindungen zu haben)
und vieles mehr..

2. Server
Lokale Platten mit unerkannten/ungelösten Problemen, fragmentiert? Lahme Festplatten? Prozessor Auslastung?
SAN Probleme?

3. Anwendungen
Schlecht programmierte Applikationen z. B. zuviel Datenbankabfragen.
Lokale Anwendungen statt Terminalservices (wie Citrix) bei lahmen WAN Anbindungen problematisch..

1. Netzwerk
Ungünstiges Netzdesign / Nadelöhr Switchuplink oder Serveranbindung

Der Switch ist nen GigaBit Teil und der Server dort direkt angebunden.

Duplex / Speed Probleme?

Eigentlich nicht, die Ping Zeiten sind alle ok.

Bandbreite messen (zb ftp end-to-end download).

Was meinst Du damit?

Lahme WAN Bandbreite? Wanbeschleuniger sinnvoll?

Nö, eigentlich nicht, wie gesagt, es ist ein Gbit Netz.

Ungünstige Zweck-Planung (z. B. die Leute müssen ständig riesen Datenmengen über lahme Leitungen transferierne
anstatt lokal schnelle Server u. Netzanbindungen zu haben)
und vieles mehr..

Gut, da kann man sicherlich einiges falsch machen, aber wie oben schon gesagt, die Ping Zeiten sind ok.

2. Server
Lokale Platten, fragmentiert? Lahme Festplatten? Prozessor Auslastung?
SAN Probleme?

Fragmentiert sind die Platten kaum und es tun 10.000k Platten im Raid5 Verbund Ihren Dienst. Die Prozessorauslastung übersteigt kaum 50 % Last.

3. Anwendungen
Schlecht programmierte Applikationen z. B. zuviel Datenbankabfragen.
Lokale Anwendungen statt Terminalservices (wie Citrix) bei lahmen WAN Anbindungen problematisch..

Zu der Anwendungen und wie die programmiert sind, kann ich natürlich nix sagen, aber es ist keine wirkliche Datenbank im Einsatz sondern einfach nur eine FoxPro Anwendung, nen eMail Server, nen paar kleine Dienstprogramme und hat das Dateihosting.

Also alles nix ungewöhnliches, trotzdem halt dieses Problem mit den vielen unbekannten Netzwerkpaketen und halt diesen Problemen.

ftp ist halt ein billiger performancetest.
ftp server auf zielsystem installieren, übers LAN z. B. Linux ISO File transferieren und guggen wie schnell.
ftp get ...
ftp put ..

oder...
http://www.heise.de/download/netio.html

Netzdesign... BAndbreiten(ver)planung:
Alle Clients an Gigabit Ports ------SwitchUplinkGigabitPort------------ServerGigabitport
??

Wenn 50 Clients mit 1Gbit/s Netzwerkkarte Daten transferieren sind das brutto 50Gbit/s die der Server / Switches u. U. in Spitzenzeiten bewältigen müssen.
Nadelöhr Switchuplink bei kaskadierten Switches?
Nadelöhr Serverport?

- Wenn die Performance mal "schlecht" ist - gehen dann die Ping Zeiten hoch ==> Bandbreite?
- Prozessorauslastung auf Client? Auffällige Prozesse die sich aufhängen?
- haben Clients punktuell da Problem - oder wenn, dann alle gleichzeitig?
- Nutzt ihr Internetproxy mit Contentfilter? Saugt einer Filme aus dem Internet?

- Würmer im Netz gelegentlich am rumwurmen? (zb wenn Aussendienstler Herr maier "mal wieder" sein Aussendienstnotebook im LAN anstöpselt..)
- Spanning Tree Probleme (Broadcaststorm - Azubi Peterle hat mal wieder aufgrund Restalkohol den Switch mit LAN Kabel kurzgeschlossen .. / Spanning Tree Recalculation bis 50Sek Netzausfall oder kompletter Stillstand

- Swiitchuplinks ETherchannel / LACP / PAGP Channels bilden (bis 8Gbit Interfaces, oder 10Gbit Uplink..)
- Server via Teaming / LACP mit mehreren Netzwerkkarten anbinden
- Cacti Switchinterfaceauslastung monitoren zb

aber wenn jedes zweite oder dritte Paket als "unbekannt" indentifiziert wird,

Was sind "unbekannte Pakete"?

zeig doch mal wireshark auszug der ominösen unbekannten pakete...
ich bin neugierig...

Hi

stell uns doch bitte die Logs vom Wireshark hier rein bzw. einen Auszug und dann kann dir sicher jemand sagen wozu deine unbekannten Packete gehören.

Switchports ändern und Netzwerkdurchmessen hat jetzt wenig mit Packeten zu tun. Hast du mal auf deinem Server den Taskmanager aufgemacht und hast da mal den Reiter Netzwerk angeklickt und geguckt was die Auslastung in % sagt ???
Wäre vll. Sinnvoll.

Hast du mal den anderen Server mit wireshark belauscht, ob da auch unbekannte Packete ankommen???

Vor allem die Aussage : Mal schnell, mal langsam...

Es kann mal langsam sein wenn ein Client halt mal eben ein paar 100 bis 1000 MB vom Server läd oder auf den Server kopiert.

Was ist das für ein Fileserver : ....und hat das Dateihosting.

Was für Dateien ??? Officedateien, CAD Zeichnungen, Photoshop ....

Ausserdem fragt man dich nach Duplex /Speed Problemen und bekommt ne Antwort die was von nem Ping enthält ....

"
Duplex / Speed Probleme?

Eigentlich nicht, die Ping Zeiten sind alle ok.
"
Was verstehst du unter Pingzeiten sind OK ??? 1 ms, 10 ms, ...

Werte wären nicht schlecht.

Wieder so ein Problem, wo nichts von dem Problem beschrieben wird .... Und man alles aber wirklich alles aus der Nase saugen muss.

MfG Nemesis

Hi !

Zitat von @spacyfreak:

zeig doch mal wireshark auszug der ominösen unbekannten pakete...
ich bin neugierig...

Das ist ja genau das was dog im Prinzip schon indirekt vorgeschlagen hatte, denn unbekannte Pakete kann alles Mögliche bedeuten und mit den bisherigen Aussagen des TO sind wir genauso schlau wie vorher, denn - Gigabit Teil und Pingzeiten OK - sind halt genauso "fachmännisch qualifizierte Aussagen" wie unbekannte Pakete.

mrtux

Hallo,

hier ist der gewünschte Auszug aus dem Wireshark Protokoll:

<No. Time Source Destination Protocol Info
1 0.000000 192.168.11.32 192.168.11.199 SMB Trans2 Request, FIND_FIRST2, Pattern: \EasyFOOD\kdabfbrg.PRG

Frame 1 (184 bytes on wire, 184 bytes captured)
Ethernet II, Src: 00:25:11:8b:5f:a3 (00:25:11:8b:5f:a3), Dst: IntelCor_6d:29:9d (00:1b:21:6d:29:9d)
Internet Protocol, Src: 192.168.11.32 (192.168.11.32), Dst: 192.168.11.199 (192.168.11.199)
Transmission Control Protocol, Src Port: 1033 (1033), Dst Port: netbios-ssn (139), Seq: 0, Ack: 0, Len: 130
Source port: 1033 (1033)
Destination port: netbios-ssn (139)
Sequence number: 0 (relative sequence number)
[Next sequence number: 130 (relative sequence number)]
Acknowledgement number: 0 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
Window size: 64491
Checksum: 0xf410 [correct]
NetBIOS Session Service
SMB (Server Message Block Protocol)

No. Time Source Destination Protocol Info
2 0.000134 192.168.11.199 192.168.11.32 SMB Trans2 Response, FIND_FIRST2, Error: STATUS_NO_SUCH_FILE

Frame 2 (126 bytes on wire, 126 bytes captured)
Ethernet II, Src: IntelCor_6d:29:9d (00:1b:21:6d:29:9d), Dst: 00:25:11:8b:5f:a3 (00:25:11:8b:5f:a3)
Internet Protocol, Src: 192.168.11.199 (192.168.11.199), Dst: 192.168.11.32 (192.168.11.32)
Transmission Control Protocol, Src Port: netbios-ssn (139), Dst Port: 1033 (1033), Seq: 0, Ack: 130, Len: 72
Source port: netbios-ssn (139)
Destination port: 1033 (1033)
Sequence number: 0 (relative sequence number)
[Next sequence number: 72 (relative sequence number)]
Acknowledgement number: 130 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
Window size: 65063
Checksum: 0x989a [incorrect, should be 0x242f (maybe caused by "TCP checksum offload"?)]
[SEQ/ACK analysis]
NetBIOS Session Service
SMB (Server Message Block Protocol)

No. Time Source Destination Protocol Info
3 0.002288 192.168.11.32 192.168.11.199 SMB Trans2 Request, QUERY_PATH_INFO, Query File Basic Info, Path: \EasyFOOD\DBF\kdabfbrg.PRG

Frame 3 (186 bytes on wire, 186 bytes captured)
Ethernet II, Src: 00:25:11:8b:5f:a3 (00:25:11:8b:5f:a3), Dst: IntelCor_6d:29:9d (00:1b:21:6d:29:9d)
Internet Protocol, Src: 192.168.11.32 (192.168.11.32), Dst: 192.168.11.199 (192.168.11.199)
Transmission Control Protocol, Src Port: 1033 (1033), Dst Port: netbios-ssn (139), Seq: 130, Ack: 72, Len: 132
Source port: 1033 (1033)
Destination port: netbios-ssn (139)
Sequence number: 130 (relative sequence number)
[Next sequence number: 262 (relative sequence number)]
Acknowledgement number: 72 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
Window size: 64419
Checksum: 0x5662 [correct]
[SEQ/ACK analysis]
NetBIOS Session Service
SMB (Server Message Block Protocol)

No. Time Source Destination Protocol Info
4 0.002400 192.168.11.199 192.168.11.32 SMB Trans2 Response, QUERY_PATH_INFO, Error: STATUS_OBJECT_NAME_NOT_FOUND

Frame 4 (93 bytes on wire, 93 bytes captured)
Ethernet II, Src: IntelCor_6d:29:9d (00:1b:21:6d:29:9d), Dst: 00:25:11:8b:5f:a3 (00:25:11:8b:5f:a3)
Internet Protocol, Src: 192.168.11.199 (192.168.11.199), Dst: 192.168.11.32 (192.168.11.32)
Transmission Control Protocol, Src Port: netbios-ssn (139), Dst Port: 1033 (1033), Seq: 72, Ack: 262, Len: 39
Source port: netbios-ssn (139)
Destination port: 1033 (1033)
Sequence number: 72 (relative sequence number)
[Next sequence number: 111 (relative sequence number)]
Acknowledgement number: 262 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
Window size: 64931
Checksum: 0x9879 [incorrect, should be 0x741b (maybe caused by "TCP checksum offload"?)]
[SEQ/ACK analysis]
NetBIOS Session Service
SMB (Server Message Block Protocol)

No. Time Source Destination Protocol Info
5 0.002898 192.168.11.32 192.168.11.199 SMB Trans2 Request, FIND_FIRST2, Pattern: \EasyFOOD\DBF\kdabfbrg.PRG

Frame 5 (192 bytes on wire, 192 bytes captured)
Ethernet II, Src: 00:25:11:8b:5f:a3 (00:25:11:8b:5f:a3), Dst: IntelCor_6d:29:9d (00:1b:21:6d:29:9d)
Internet Protocol, Src: 192.168.11.32 (192.168.11.32), Dst: 192.168.11.199 (192.168.11.199)
Transmission Control Protocol, Src Port: 1033 (1033), Dst Port: netbios-ssn (139), Seq: 262, Ack: 111, Len: 138
Source port: 1033 (1033)
Destination port: netbios-ssn (139)
Sequence number: 262 (relative sequence number)
[Next sequence number: 400 (relative sequence number)]
Acknowledgement number: 111 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
Window size: 64380
Checksum: 0x4ae1 [correct]
[SEQ/ACK analysis]
NetBIOS Session Service
SMB (Server Message Block Protocol)
<

Den Taskmanager habe ich selbstverständlich schon kontrolliert, da war aber in der Netzwerklast keine auffällige Last zu sehen, wenn es hoch kommt, waren es mal 20 % Auslastung.

Ich habe gerade noch einmal mehrere Clienten angepingt, die Antwortzeiten waren alle <1ms.

Der Server hostet auf dem Server Office Dateien und Dateien, die zur FoxPro Datenbank gehören.

Entschuldigung für meine, im Ausgangsposting unklaren Aussagen, aber es war für mich halt recht schwierig zu beschreiben.

Hi Arkenau,

wo läuft denn der Wireshark?
Wohl doch nicht auf dem Server?
Wie wird die der Wireshark ins Netz eingebunden?
Kann der Client mit dem Wireshark die Pakete auch verarbeiten? Wenn nein, dann ist Wireshark unter Windows einfach zu schwach um eine sichere Analyse durchzuführen.

Auch gute Werkzeuge können bei unbedachter Handhabung keine guten Ergebnisse erbringen.

Unbekannte Pakete?
Unbekanntes Protokoll? Unbekanntes IP-Protokoll? Unbekanntes TCP-Protokoll?
In allen Paketen, auch in "unbekannten" steht immer ein Absender....

Danach kann es erst einen Schritt weiter gehen.
Aufnahme der Broadcastdaten (mit Wireshark) .....

Gruß
Netman

Morgen,

also ich sehe da nichts unbekanntes.
Ich sehe es so (bitte korrigieren, falls ich mich hier verhaue):

Server/PC 192.168.11.32 fragt Server/PC 192.168.11.199 über SMB nach der Datei \EasyFOOD\kdabfbrg.PRG
Server/PC 192.168.11.199 sagt aber habe ich nicht (/STATUS_NO_SUCH_FILE)

Und dann geht das Spiel so weiter, aber das sollte nicht dein Netzwerk lähmen.

VG
deepsys

Eines ist aber komisch:

Alle Pakete von 192.168.11.199 haben ungültige Checksummen:

Checksum: 0x9879 [incorrect, should be 0x741b (maybe caused by "TCP checksum offload"?)]

Was ist denn 192.168.11.199?

Moin,

192.168.11.199 ist ein Windows 2003 Server, oder was meinst Du mit "Was..."?

Hi,

dann würde ich der TCP checksum offload Meldung mal nachgehen:
- Neuer Treiber Netzwerkkarte (was für eine ist das denn überhaupt?)
- Oder TCP checksum offload abschalten

Guck mal hier:
http://www.techsupportforum.com/forums/f137/wireshark-question-tcp-chec ...
http://support.microsoft.com/?scid=kb%3Ben-us%3B243294&x=9&y=14

VG
Deepsys

Moin,

also was genau stört dich denn an der Konversation

0.000000 192.168.11.32 192.168.11.199 SMB Trans2 Request, FIND_FIRST2, Pattern: \EasyFOOD\kdabfbrg.PRG
0.000134 192.168.11.199 192.168.11.32 SMB Trans2 Response, FIND_FIRST2, Error: STATUS_NO_SUCH_FILE
0.002288 192.168.11.32 192.168.11.199 SMB Trans2 Request, QUERY_PATH_INFO, Query File Basic Info, Path: \EasyFOOD\DBF\kdabfbrg.PRG
0.002400 192.168.11.199 192.168.11.32 SMB Trans2 Response, QUERY_PATH_INFO, Error: STATUS_OBJECT_NAME_NOT_FOUND

?
Da unterhalten Sich 192.168.11.32 und .199 über das Verzeichniss "\EasyFOOD\kdabfbrg.PRG" - das ist eine ganz normale Sache (in Windows Netzwerken).
Wenn dich das stört musst du entweder auf dem .32 den Grund für die Abfragen abstellen, oder auf dem .199 den Zugriff auf das Verzsichinis freigeben/herstellen

/EDIT: Schonmal die Fehlercounter an deinen/m Switch(es) überprüft?

g,
Slainte

Hi, danke für Eure Hilfe erstmal,

ich werde mich mit den Switchen ausführlich beschäftigen, ich bin nämlich beim nachschauen der WireShark Logs auf das Phänomen gestoßen, das die IP Adresse 192.168.11.255 in den Logs auftaucht, die es aber gar nicht gibt.

Wenn ich diese Adresse anpinge antworten mir, soweit ich das sehen kann, mindestens 4 Geräte auf die Anfrage, was ja eigentlcih auch nicht sein kann.

ich werde mich mit den Switchen ausführlich beschäftigen, ich bin nämlich beim nachschauen der WireShark Logs auf
das Phänomen gestoßen, das die IP Adresse 192.168.11.255 in den Logs auftaucht, die es aber gar nicht gibt.

Ähm, das ist der Broadcast, den gibt es immer!
Ich schätze mal das der WireShark mit seinen Daten doch noch zu früh für dich ist, denn das solltest du schon wissen, sonst sieht du den Wald vor lauter IPs nicht mehr ...

http://de.wikipedia.org/wiki/Broadcast

Wenn ich diese Adresse anpinge antworten mir, soweit ich das sehen kann, mindestens 4 Geräte auf die Anfrage, was ja
eigentlcih auch nicht sein kann.

Doch ....

Ich schätze mal das der WireShark mit seinen Daten doch noch zu früh für dich ist

Das hast jetzt aber schoen formuliert

dann würde ich der TCP checksum offload Meldung mal nachgehen:
- Neuer Treiber Netzwerkkarte (was für eine ist das denn überhaupt?)
- Oder TCP checksum offload abschalten
Guck mal hier:
http://www.techsupportforum.com/forums/f137/wireshark-question-tcp-chec ...

-> würde darauf tippen, das es das ist.
Wichtig wäre eine Messung z.B. mit netio und eine vernünftige Fehlerbeschreibung (Mitarbeiter am besten eine Excel Liste ausfüllen lassen, wann sich die Performance bei welcher Tätigkeit auswirkt). Wenn alle 30 Mitarbeiter über eine DSL 2000 Leitung in der Mittagszeit Ihre Privatmails checken wirds halt langsam

Wenn meine Annahme falsch sein sollte möge mich jemand korrigieren, aber ich kann mir nicht vorstellen, das die korrekte Antwort von "ping 192.168.11.255"

"Antwort von 192.168.11.82
Antwort von 192.168.11.233
Antwort von 192.168.11.233
Antwort von 192.168.11.233"

sein soll.

Du hast dich aber mal über den Broadcast informiert, ja?

Es gibt die Addresse 192.168.11.255 so nicht, und pingbar ist die auch nicht.

Ich habe das mit dem ping gerade auch mal probiert, und bekomme auch die Antwort von zwei Rechnern.
Nochmal, das ist nicht dein Fehler, eher das mit dem TCP checksum offload ...

Schönes WE!

Du hast dich aber mal über den Broadcast informiert, ja?

Anscheinend nicht

Nochmal, das ist nicht dein Fehler, eher das mit dem TCP checksum offload ...

Das muss kein Fehler sein, wenn die Kontrolle auf der Netzwerkkarte gemacht wird werden die entsprechenden Pakete in Wireshark dargestellt, als wäre diese Kontrolle nicht (oder falsch?) erfolgt. Wie man das zur Kontrolle abschalten kann steht ja in Deinem eigenen Link.

Schönes WE!

Dito.

Natürlich habe ich mich mit Hilfe von Wikipedia über den Broadcast informiert, war aber bisher eigentlich immer davon ausgegangen, das es auf einen Ping an eine Adresse, dies nicht gibt auch keine Antwort geben kann.

Natürlich habe ich mich mit Hilfe von Wikipedia über den Broadcast informiert, war aber bisher eigentlich immer davon
ausgegangen, das es auf einen Ping an eine Adresse, dies nicht gibt auch keine Antwort geben kann.

Das ist im Prinzip ja auch richtig, aber die Broadcast Addresse ist eben keine richtige Addresse.
Nimm mal zum Beispiel DHCP, der Client hat am Anfang ja keine Ahnung wer der DHCP-Server ist, darum schickt er die DHCP-Anfrage einfach an alle (eben die Broadcast-Addresse).

So und nun endlich ab ins WE!

VG
Deepsys

Joo, danke für die Aufklärung und ein wirklich schönes WE.

- Oder TCP checksum offload abschalten

Wieso sollte man den Server zusätzlich belasten nur weil Wireshark nicht mit den Paketen klar kommt?

Checksum-Offloading heißt, dass die Prüfsumme auf der Netzwerkkarte berechnet wird - also nachdem Wireshark das Paket gesehen hat.
Darum wird Wireshark IMMER diesen Fehler anzeigen.

Das ist ein Feature von besseren Netzwerkkarten, da man dadurch die CPU stark entlastet!

Antwort von 192.168.11.82
Antwort von 192.168.11.233

Vor und Nachteil des Internet und der IT:
Es gibt oft mehr als eine Antwort und mehr als eine Möglichkeit. z.B. Ping Linux

Der Wireshark Auszug zeigt mir jetzt nix abenteuerliches - netbios session halt.
Checksum Fehler in Wireshark Outputs sind normal und sollten einen nicht beunruhigen.

http://wiki.wireshark.org/TCP_Checksum_Verification

Hallo,

was hast du für Clients im Netz? Wir hatten bei einem Kunden den Effekt, das das Netz immer langsammer wurde. Ich spar die jetzt die Suchgeschichte, aber das Ende vom lied war, das mit steigender Zahl der Windows 7 PC´s auch die Zahl der Rechner die via IPv6 und Broadcast im Netz werkeln gestiegen ist. Das haben die 2x 48 Port linksys Switche einfach nicht mehr bewältigt. Vernünftige HP reingehange, alles läuft wieder normal.

MfG Marcel

Hallo Marcel,
kann das eventuell an der Einstellung für die Broadcastrate in den Linksys Switchen liegen? Broadcaststorm ... Limit 5%
Damit wäre aber das Problem im Netzwerk nicht gelöst nur für ein Weilchen die Folgen davon.

Gruß
Netman

Wir haben in der Tat eine wachsende Anzahle Windows 7 PCs im Netz.

Sollte man also das IPv6 Protokoll aus den Systemen entfernen?

Guten Morgen,

Wieso sollte man den Server zusätzlich belasten nur weil Wireshark nicht mit den Paketen klar kommt?

Ach so, ja dann macht das Deaktivieren keinen Sinn.
Wieder was gelernt, danke dog!

Hallo,

das entfernen von IPv6 wäre nur ein Aufschub der Problematik. Wir haben auch mit dem Gedanken gespielt, ihn aber schnell wieder verworfen da wir ja Zukunftssicher bauen wollen.

Was habt ihr denn aktuell für Switchtechnik hängen?

Ich würde mich einmal an ein Systemhaus in der Nähe wenden und anfragen, ob die ein performantes Leihgerät haben für eine Woche. So könntest du das Problem eingrenzen und wenn damit alles wieder normal funktionieren sollte, ist es glaub auch kein Problem den Chef davon zu überzeugen das Gerät zu kaufen.

MfG Marcel

Sollte man also das IPv6 Protokoll aus den Systemen entfernen?

Wenn du keine IPv6-Infrastruktur hast (Router, Switche mit Filtern), dann solltest du es AUF JEDEN FALL DEAKTIVIEREN!

IPv6 in der Standardkonfiguration von Windows ist ein enormes Sicherheitsrisiko für ein Netzwerk.
http://www.ipv6.om/gctcms/Editor/files/hacking%20ipv6%20networks.pdf

Was habt ihr denn aktuell für Switchtechnik hängen?

Zur Zeit haben wir an der zentralen Stelle, also da wo die Server stehen, zwei Gigabit Switche mit 24 Ports sowie einen kleine 8 Port GB Switch an einem entfernteren Standort sowie einen 100 Mbit Switch über den das WLAN abgewickelt wird.

Was habt ihr denn aktuell für Switchtechnik hängen?

Ich wollte die genauen Typen wissen. Es gibt schon einen Unterschied zwischen TP-Link und HP

IPv6 in der Standardkonfiguration von Windows ist ein enormes Sicherheitsrisiko für ein Netzwerk.

Nur das man dazu erstmal ins lokale Netz eindringen muss womit sich das ganze mit einer vernünftigen Firewall schon wieder relativiert. Im Netz gibts auch bei IPv4 viele Angriffspunkte wenn man die defaulteinstellungen beibehällt. Das ganze erinnert mich stark an einseitig aufgebauschte Verschwörungstheorien, welche sämtliche Variablen die dagegensprechen still und leise ausblenden.

AUF JEDEN FALL DEAKTIVIEREN!

Ich finde diese globale Aussage ziemlich überzogen und unprofessionell. Dazu kommt, das Microsoft eindringlich davor warnt auf Servertechnik das IPv6 zu deaktivieren. Aber das ganze sollten wir nicht hier ausdiskutieren, da es ziemlich am Thema vorbeigeht.

Die großen Gigabit Switche sind D-Link Switche, der kleine, 8 Port, Switch ist ein 3Com und der 100 Mbit Switch is ein Netgear.

Zitat von @k.arkenau:

Die großen Gigabit Switche sind D-Link Switche, der kleine, 8 Port, Switch ist ein 3Com und der 100 Mbit Switch is ein
Netgear.

Gehts noch bisschen genauer? Mir gehts um die spezifischen Durchsatzwerte und unterstützten Dienste. Spitze wenn man jemanden alles aus der Nase ziehen muss.

Auch Switche haben Prozessoren und Speicher eingebaut. Manche sind leistungsfähiger als andere. Manche haben eine Weboberfläche, auf der man die Last auswerten kann, andere nicht.

gelöst Frage Microsoft Windows Netzwerk

Mehr von k.arkenau

Problem Anmeldung Integration Servicesk.arkenau

Remotedesktop Sitzungen auf Windows Server 2008 R2k.arkenau - 8 Kommentare

FoxPro nochmal Immer wieder Abstürze nach Umzug auf einen virtualisiertes Windows Server 2008 64 bitk.arkenau - 4 Kommentare

MySQL Problem mit ODBC Treiberk.arkenau - 4 Kommentare

Heiß diskutiert