vServer inoperabel, Verdacht auf ARP storm

S

sanbiber

Well-Known Member
Hallo BSDler,

ich hab einen vServer gemietet und der konnte plötzlich keine Namen mehr auflösen und auch das Standart-Gateway nicht mehr anpingen. Ich hab dann nach und nach alles auf dem Server abgeschaltet: keine Jails mehr, kein packet filter mehr ... und trotzdem kann der DNS Server nicht erreicht werden und das Standart-Gateway nicht angepingt werden. (Auf dem Host hab ich FreeBSD 11.4-RELEASE installiert, IPv6 ist abgeschaltet ... und er funktionierte schon eine Weile ziemlich zuverlässig - Fehlkonfiguration meinerseits also relativ unwahrscheinlich)

Ein tcpdump zeigte mir dann erstaunlicher Weise, dass von einem Host im gleichen Netz teilweise 80 ARP requests pro Sekunde reinkommen. Teilweise gibt es dann noch zusätzlich IPv6 neighbor solicitation Pakete.

Meine Frage ist: kann so ein a-normal funktionierender Host das Netz auf diese Weise so dicht machen, dass das Standart-Gateway nicht mehr erreichbar ist und dann auch die DNS-Server, die nicht im gleichen Netz liegen?

Kann ich vom vServer aus irgendwelche Maßnahmen ergreifen, um wieder operabel zu werden? (Leider erweist sich der Hoster als sehr unzuverlässig ... Ich hab mehrmals darauf hingewiesen, dass eine bestimmte IP mit einer bestimmten MAC unnormal viele Pakete schickt, empfohlen, ihn selbst oder den beschriebenen Verkehr abzuschalten - das Resultat nach einem Tag Wartezeit: der von mit gemietete vServer wurde auf ein anderes Wirtssystem [im gleichen Netz] verschoben :eek:)

Vielen Dank,
sanbiber
 
sanbiber schrieb:
Meine Frage ist: kann so ein a-normal funktionierender Host das Netz auf diese Weise so dicht machen, ...
Zum Vergrößern anklicken....
Eigentlich nicht, denn die 80 arp-requests/Sekunde sind ja nicht alle an deinen Server adressiert. Der Server wird ja nicht antworten (mit einem arp-reply) und/oder diese arp-requests evtl. loggen, oder?
 
Ja, die ARP-Requests erfragen alle möglichen Server im Netz - auch immer mal wieder meinen. Ich logge sie nicht.

Hieße das, dass nur die ausbleibende Antwort vom Gateway das Problem ist, also dass der ARP-Request von meinem Server, der die MAC des Gateways erfragt, gar nicht beantwortet wird?
 
sanbiber schrieb:
Hieße das, dass nur die ausbleibende Antwort vom Gateway das Problem ist, also dass der ARP-Request von meinem Server, der die MAC des Gateways erfragt, gar nicht beantwortet wird?
Zum Vergrößern anklicken....
Das kannst Du gezielt testen, mit z. B.:
Code: 
arping -c 3 -I <Interface> <IP-Adresse-Gateway>
Wie ist nach dem arping die Ausgabe von:
Code: 
arp -a
?
Evtl. mit der rc.conf einen statischen arp-cache-Eintrag für das Gateway testen bzw. konfigurieren:
Code: 
static_arp_pairs="gw"
static_arp_gw="<IP-Adresse-Gateway> <MAC-Adresse-Gateway>"
oder mit der rc.local (bzw. gleichwertig):
Code: 
/usr/sbin/arp -S <IP-Adresse-Gateway> <MAC-Adresse-Gateway>
siehe danach die Ausgabe von:
Code: 
arp -a
"permanent" sollte für das Gateway angezeigt werden.
 
Danke für die guten Tipps.

Hab leider kein arping da installiert und kanns grad ja auch nicht nachinstallieren ... Aber mein Host generiert auch ab und zu ARP-Requests (entweder wegen ping oder weil die IP als Gateway eingetragen ist) - und da kommt keine Antwort zurück :/
 
sanbiber schrieb:
... Aber mein Host generiert auch ab und zu ARP-Requests (entweder wegen ping oder weil die IP als Gateway eingetragen ist) - und da kommt keine Antwort zurück :/
Zum Vergrößern anklicken....
Wie ist jetzt die Ausgabe von:
Code: 
arp -a
?
Was passiert wenn Du manuell einen arp-cache-Eintrag für das gateway machst, mit:
Code: 
arp -S <IP-Adresse-Gateway> <MAC-Adresse-Gateway>
? Wie ist danach die Ausgabe von:
Code: 
arp -a
und kannst Du danach die IP-Adresse des Gateway per Ping (icmp) erreichen?
 
Fürs Gateway gibt es keinen Eintrag im Cache - da kommt auch keiner (bzw. bleibt incomplete). Und leider hab ich mir den auch nie gemerkt, kann den also nicht statisch eintragen. Und ansonsten ist die eigene MAC im Cache und die von dem a-normalen Host, der ständig ARP-Requests sendet.
 
sanbiber schrieb:
Fürs Gateway gibt es keinen Eintrag im Cache - da kommt auch keiner (bzw. bleibt incomplete).
Zum Vergrößern anklicken....
Das ist m. E. nicht gut. Wenn Du den Server neu startest, ist das dann auch so?
Wie ist das default gateway in der Ausgabe von:
Code: 
netstat -nr -f inet
?
Benutzt Du nur IPv4 oder auch IPv6 mit diesem Server?
 
Bleibt auch so nach Neustart, Default Gateway (defaultrouter in rc.conf) wird richtig eingetragen (taucht auch im netstat auf). Und ich nutze nur IPv4 da.
 
sanbiber schrieb:
Default Gateway (defaultrouter in rc.conf) wird richtig eingetragen (taucht auch im netstat auf).
Zum Vergrößern anklicken....
Und Du kannst weder die IPv4-Adresse des default gateway, noch eine andere IPv4-Adresse im Internet (z. b. 1.1.1.1), per Ping (icmp) erreichen? Welche hops werden mit einem traceroute angezeigt? Z. B.:
Code: 
traceroute 1.1.1.1
?

EDIT:

Für den Ping (zum gateway) und den traceroute ins Internet, sollte der statische/permanente arp-cache-Eintrag für das gateway konfiguriert sein. Das ist aber nur dann möglich, wenn Du die richtige MAC-Adresse von gateway kennst.
Mit unvollständigen (incomplet) arp-cache-Eintrag für das gateway, kann der Ping bzw. das Routing ins Internet nicht funktionieren.
 
Zuletzt bearbeitet:
So, endlich geht es wieder. Der Anbieter hatte lt. eigener Aussage einen Fehler im Switch und den trotz Support-Anfrage bis eben nicht behoben ... seit ca. 19.6. 19:30 Uhr konnt ich den Server nicht benutzen ... sehr ärgerlich. Die ARP-Requests wurden als normale Hintergrundaktivität bezeichnet ... vllt. eine Art Monitoring?!

Vielen Dank für den Support hier - das waren tolle Hinweise, die auch in anderen Fällen genutzt werden können.

Ich werde mir gleich mal die MAC vom Gateway notieren ;)
 
KobRheTilla schrieb:
Das bringt dir nichts, wenn das Switch im Eimer ist.
ARP war wohl hier nicht das Problem.

Rob
Zum Vergrößern anklicken....
mir ist auch klar, dass das eigentlich nicht Sinn der Sache ist - wenn die Hardware ausgetauscht wird, verändert sich höchstwahrscheinlich die MAC. Und klar: wenn der Switch kaputt ist, bringt das auch nichts ... aber wie @morromett meinte: dann kann ich wenigstens beim nächsten Mal noch ein bisschen mehr testen

Der Anbieter meinte übrigens mittlerweile, dass die vielen ARP-Requests von VRRP herrührten. Kommt mir immer noch nicht plausibel vor ...
 
Nicht nur wenn die Hardware getauscht wird, oft sind das ja "virtuelle" Mac-Addressen z.B. wenn der Switch auch die Routing instanz ist oder sonst irgendwo keine "Hardware" im engsten sinne.
 
Hast Du mal probiert, die IP ueber DHCP anzufordern? Evtl. hat sich da ja was geaendert, z.B. das subnet oder aehnliches. Wie verbindest Du dich denn mit dem Server? Ohne Gateway sollte das ja eigentlich nicht moeglich sein. Hast Du bei deinem Anbieter evtl. ein Rescue System oder aehnliches? Dort koenntest Du dann vergleichen, ob die Routen stimmen usw.
 
Das könnte auch eine Schleife im Netz bei abgeschaltetem Spanning Tree und / oder billigen Switches gewesen sein. Schön eine Schleife gebaut und der ARP-Storm sagt Hallo. :D
 
Nur, damit die Fragen hier unhöflicher Weise nicht unbeantwortet bleiben ...

midnight schrieb:
Hast Du mal probiert, die IP ueber DHCP anzufordern?
Zum Vergrößern anklicken....
Nein.
midnight schrieb:
Evtl. hat sich da ja was geaendert, z.B. das subnet oder aehnliches. Wie verbindest Du dich denn mit dem Server? Ohne Gateway sollte das ja eigentlich nicht moeglich sein.
Zum Vergrößern anklicken....
Der Anbieter hat ein Webinterface zur Steuerung der VM und da gibt es eine console.
midnight schrieb:
Hast Du bei deinem Anbieter evtl. ein Rescue System oder aehnliches? Dort koenntest Du dann vergleichen, ob die Routen stimmen usw.
Zum Vergrößern anklicken....
Das gab/gibt es tatsächlich. Das Problem war nur, dass das rescue-system über PXE starten sollte und die Maschine aber ja noch am gleichen Netz hing ...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben