Sporadische Netzwerkausfälle scheinbar arp cache Probleme

[RogerG781 22]

Hallo Freunde,

derzeit evaluiere ich einen Windows SErver 2016 TP5 (installiertes CU 14.06.16).

Das ganze auf einem Intel S2600CP2 Board mit Xeon CPU. Der Server verfügt über aktivierte Hyper-V Rolle mit einigen VMs. Zwei VMs haben öffentliche IP Adressen.

 

Das ganze lief einige Wochen ohne Ausfälle oder Probleme.

 

An einem Donnerstag ohne vorherige Patch Installation oder Wartung am Server waren die VMs mit den öffentlichen IPs nur noch sporadisch erreichbar.

Mal waren die IPs erreichbar, dann wieder nicht, dies ging einige Zeit so weiter. :(

 

Nun habe ich zunächst vermutet, es gibt evtl. noch Probleme mit der TP5.

Also alle VMs abgeschaltet, Server 2012 R2 installiert. Hyper-V Rolle installiert VMs darauf hochgezogen, doch es gab keine Änderung. Die VMs waren weiterhin nur sporadisch erreichbar.

 

Danach dann folgende Maßnahmen durchgeführt:

1. Da es eine interne NIC war, BIOS Update mit anschließendem BIOS Reset und mehrere Minuten vom Strom getrennt

2. Andere NIC installiert

3. Andere IP ausprobiert

4. wie bereits geschrieben, andere Windows Server Version installiert

5. kompletten Intel Server mit Intel Confidence Tool gecheckt

 

Es brachte keine Änderung. Also alle VMs ausgeschaltet und den Host selbst mit einer öffentlichen IP ausgestattet. Auch dieser war nicht erreichbar.

Nachdem ich auf dem Server den Befehl: netsh interface ip delete arpcache absetze geht ein Ping durch und beim nächsten erfolgt Zeitüberschreitung.

Das kann ich beliebig öft wiederholen, arp cache löschen, 1. Ping geht durch die restlichen wieder nicht. :confused:

 

Neu Installation von WS2012R2. Keine Rollen aktiviert, sondern nur die NIC mit einer öffentlichen IP konfiguriert.

Problem bleibt allerdings bestehen, erster Ping geht nach löschen des Arp cache durch, der Rest wieder nicht. Sowohl von intern nach extern, als auch umgekehrt.

 

Also Server 2016 TP5 noch mal installiert und damit getestet, keine Änderung.

Nach beiden Installationen keine Rollen oder Features installiert, nur in den Firewall Einstellungen ICMP erlaubt.

Es bleibt dabei, wenn ich den arp cache lösche, geht der erste Ping sowohl von intern nach extern als auch umgekehrt durch. Danach Timeout.

 

Habt ihr einen Tipp, wo ich den Fehler suchen soll?

 

[djmaker 95]

Welche NIC-Typen bzw. Hersteller sind im Spiel? Für die NICs gibt es in der Regel separate Firmware.

[RogerG781 22]

Integrierte auf dem Mainboard ist eine Intel i350 dual LAN.

weiterer getesteter Adapter ist ein HP NC360T Dual Port 1GB mit Intel 82571EB Chip.

Die integrierte hab ich mir aktuellen treibern versorgt, bei der externen gibt es nur einen Treiber der älter als der Windows integrierte ist.

bearbeitet 18. Juli 2016 von RogerG781

[NorbertFe 1.798]

Klingt stark nach vmq Problemen. Kannst du das testweise mal deaktivieren?

[RogerG781 22]

Hab es in den Einstellungen deaktiviert, Server neu gestartet.

Verhalten bleibt identisch, 1. Ping geht durch der Rest nicht.

Allerdings ist es derzeit eine Standard WS2012R2 Installation ohne aktivierte Hyper-V Rolle.

[Userle 140]

Auch wenn Du es eingestellt hast was sagt das Firewall Protokoll ? Über welchen Weg ist der Server öffentlich erreichbar ? Appliance ? Was sagt das Log dort ?

Hast Du testweise mal die Firewall deaktiviert ? Falls vorhanden werfe auch einen Blick in die Switch Protokolle (ich meine die bzw. den physikalischen mit denen der Server verbunden ist). Ansonsten nehem Tools zum überwachen des Netzwerktraffics um das Problem zu analysieren.

 

Greetings Ralf

[RogerG781 22]

Hallo Ralf,

der vorgelagerte Switch hatte keine Auffälligkeiten wurde aber auch mal komplett rausgenommen und umgangen.

Der Server ist in einem Rack mit mehreren Servern. Die anderen Server können über die gleiche Verbindung problemlos erreicht werden, sowohl ein- als auch ausgehend.

Testweise wurde die IP auch mal einem anderen Server im selben Subnetz zugeordnet. Diese ist dann erreichbar. Sobald diese wieder auf dem eigentlichen Server gebunden wird, bleibt es beim beschriebenen Verhalten.

Auf die restliche vorgelagerte Technik habe ich keinen Zugriff. Da es aber bei anderen Servern funktioniert, scheint das Problem eher Serverseitig zu bestehen :(

[Userle 140]

Du hast aber bereits die NIC getauscht, daher gehe ich nicht von einem Hardwareproblem aus. Du solltest es wirklich mal mit einem Tool á la Wireshark versuchen oder ähnlichem. Ein "Ping" Test ist recht rudimentär.

Wenn Du selber keinen Zugriff auf die vorgelagerte Technik hast stelle eine Anfrage an die zuständige Abteilung bzw. den Dienstleister. Letzlich hatte das Ganze ja schon funktioniert. Ich habe die Erfahrung gemacht - es gibt immer irgendwo ein Protokoll in dem des Rätsel Lösung steht :D.

[RogerG781 22]

Hallo Ralf,

ich denke auch das es kein Hardware Defekt ist, da ja eine zweite NIC zum selben verhalten führt.

Aber ein wenig problematisch ist die Tatsache, dass sobald die IP einer anderen VM auf einem anderen Host zugeordnet wird,sofort einwandfrei funktioniert und erreichbar ist. Und das ist auf dem besagten Host bei unterschiedlichen VMs immer nur sehr kurzeitig der Fall, sobald der arp cache gelöscht wird.

Beide unterscheiden sich in der Hardware und auch Virtualisierungslösung. Soweit ich weiß kommt KVM bei dem anderen System zum Einsatz.

Und da gehen mir dann ein wenig die Argumente aus, wieso es am Dienstleister davor liegen sollte. :(

Ich werde mal schauen, ob ich über Wireshark mehr Informationen ermitteln kann.

bearbeitet 19. Juli 2016 von RogerG781

[Userle 140]

Keiner sagt es "liegt" am Dienstleister. Es geht darum das Problem zu isolieren. Das/die Netzwerkpakete gehen nun einmal über mehrere Stationen. Dieser Weg wird an verschiedenen Stellen protokolliert - insbesondere - wenn Fehler auftreten und Pakete "geblockt" werden. Im Endeffekt bedeutet das angefangen beim Server alle Protokolle/Logs zu checken. Wenn da nichts zu finden ist, an jedem weiteren physikalischen und virtuellen Wegpunkt das Gleiche durchführen. Eben auch beim Dienstleister anfragen wenn im eigenen Verantwortungsbereich nichts zu finden ist. Tools wie Wireshark können ebenfalls sehr hilfreich sein um den Fehler zu analysieren.

 

Der Teufel liegt oftmal im Detail und da bleibt nun einmal nur die zielgerichtete Punkt zu Punkt Suche und vor allem darf man nichts von vorneherein ausschließen. Am Ende greift dann Sherlock Holmes Regel ;) . Das was am Ende übrig bleibt so unwahrscheinlich es auch sein mag......

[RogerG781 22]

Nein, ich meinte auch nicht damit, dass es am Dienstleister "liegt" sondern eher, dass dort z.Zt. keine Notwendigkeit für weitere Tests gesehen wird, weil aus deren Sicht alles läuft.

 

Ob ich allerdings des Rätsels Lösung jemals präsentieren kann, ist ungewiss. Nachdem der Dienstleister erneut kontaktiert wurde, kam von dort zwar eher Ratlosigkeit, aber seitdem sind die Systeme wieder On. 

Bin erstmal vorsichtig optimistsich und hoffe, das bleibt auch so.

 

Generell ist es aber doch sehr spannend zu sehen, dass die öffentlichen IPs auf anderen Host/VMs liefen und auf dem eigenen nicht.

Warum es jetzt z.Zt. geht entzieht sich allerdings meiner Kenntniss ;)

Sollte ich noch was in Erfahrung bringen, gebe ich es gerne weiter.

[Light 12]

Wenn ich das richtig verstanden habe, sind das Vms oder?

Wenn ja, welche NICs hast Du unter VMWare den virtuellen Maschinen zugewiesen?

 

Light

[RogerG781 22]

Hallo Light,

ja es sind VMs, aber auf Basis von Hyper-V.

Das Problem bestand aber unabhänig davon, auch auf einem Standalone WS2012R2/WS2016TP5 ohne aktivierte Rollen/Features.

 

Problem wurde mittlerweile gefunden.

Es lag an einer externen Firewall, diese war wohl so konfiguriert, dass Pakete an nicht bekannte IPs als ungültig beantwortet wurden.

​Allerdings ist das immer noch ziemlich unbefriedigend. Es stellen sich immer noch zwei Fragen:

1. Warum der Server nicht schneller als die Fw geantwortet hat.

2. Wieso es nur Auswirkungen auf WS2012R2/WS2016TP5 hatte, Linux Server hatten mit den gleichen IPs bei zuvor gleicher Fw Konfiguration keine Schwierigkeiten.

 

Wenn da noch jemand was zu beitragen kann, wäre super ;)

[blub 115]

http://searchsecurity.techtarget.com/video/How-to-use-Wireshark-to-detect-and-prevent-ARP-spoofing

Schau dir doch dieses Video mal an. Vielleicht findest du doppelte ARP-Adressen

[RogerG781 22]

Ja, doppelte ARP-Adressen war ja von Beginn an ein Thema und evtl. auch eine Vermutung.

Nachdem die Logs gesichtet, zeitweise eine andere NIC (ohne Virtualsierung) eingesetzt wurde, konnten keine doppelten MAC Adressen ermittelt werden. 

Auch Wireshark förderte in diese Richtung nichts ungewöhnliches zu Tage.

 

Danke für den Link.