Wie kann ich ARP cache timer zurücksetzen ?

N

nathan2225

Jungspund
Hi, ich empfange von meiner Applikation aus Broadscasts von Netzgeräten.
Ich möchte nun (um ARP request storm bei udp senden an alle) aufgrund der bestehenden Verbindung zu diesen Geräten den ARP cache daran hindern, die link-layer Auflösung (IP<->MAC) mit der Zeit zu vergessen.

Wie kann ich das machen, ginge das z.B mit ioctl ( SIOCGARP und SIOCSARP) ?

Oder kann man sont wie einfacher den ARP cache timer zurücksetzen ?

Danke !
 
Nein, das möchste ich eben nicht, das System soll ja weiterhin voll-dynamisch bleiben. Ich will nur mein Wissen auf User-Ebene, dass eine Verbindung zum Ziel vorhanden ist (broadcast) dem ARP layer mitteilen, damit der nicht ARP requests schicken muss wenn ich ein Packet zu diesem Ziel versenden will ...
 
Ich finde das T-One Dir den richtigen Weg gezeigt hat.

Ich will nur mein Wissen auf User-Ebene, dass eine Verbindung zum Ziel vorhanden ist (broadcast) dem ARP layer mitteilen, damit der nicht ARP requests schicken muss wenn ich ein Packet zu diesem Ziel versenden will ...

Willst Du eine Bestätigung das Dein DefaultGateway erreichbar ist bevor ein ARP gesendet wird? Ich denke, daß immer ein ARP ( wenn er es nicht gerade im Cache hat und keine /etc/ethers vorliegt) versendet wird bevor das nächste Packet an die IP-Adresse gesendet wird.

Du kennst tcpdump ?

Machmal:
Code:
tcpdump -ni eth0 arp
und in einen neuen Fenster
Code:
ping www.strato.de
Code:
ping www.berlin.de
Jetzt könnte ein AHA-Effekt auftreten.

Worin besteht das Problemm, wenn Du ein paar statische Einträge (wird bei einigen Firmen als Sicherheit definiert.) in der /etc/ethers machst? Ich denke, daß selbst ein Notebook damit keine Probleme hat solange nicht im Firmen- bzw. Home- Netz die gleichen IP-Adressen verwendet werden.

Evtl. verstehe ich alles falsch. Ich bitte um Berichtigung, wenn ich falsche Informationen verbreite.
 
Fakt ist, das das System aus bis zu 250 Netzteilnehmern besteht und davon durchaus einge ausgetauscht/erweitert werden. Ich will es daher nur als letzten Ausweg verwenden, die ARP Einträge als statisch zu deklarieren, wobei noch hinzukommt das das System vom Kunden erweitert wird und man dann ja einen Techniker vor Ort einschulen müsste, der dafür Sorge tragen muss, dass die Einträge noch/weiterhin korrekt und vollständig sind.

Die Krux, warum ich die ARP Requests vermeiden will, ist, dass unsere embedded Netz-Devices vom Sender (unix-PC-System) mit ARP Requests (die ja broadcasts sind) bei einer Vollaufschaltung des Systems nach Ruhepause erschlagen werden was zu ... naja sagen wir ... Problemen führt die in der Hardware begründet sind und ich nicht beeinflussen kann.

Wenn man es irgendwie begrenzen könnte, dass nur als Beispiel 1 ARP-Request / ms erzeugt wird, wäre mir auch schon geholfen.
 
Zuletzt bearbeitet:
Fakt ist, das das System aus bis zu 250 Netzteilnehmern besteht.

Zwischenfrage:
250 PCs in einen Netz ?
Was hält Dein Kunde, wenn Ihr 64er-Netze macht ?
Ich denke, daß der Kunde die Hauptsysteme (Server) nicht sooft wechseln wird, oder ?

Evtl. hilft Dir dieser Hinweis weiter:
Code:
less /boot/config-2.6.18-164.11.1.el5 | fgrep ARPD
und
Code:
# /bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
# /bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
 
Zuletzt bearbeitet von einem Moderator:
nein, nur ein Linux PC, die anderen Netzteilnehmer sind embedded devices mit propriäterer hard/software. (91c111 netz-chip, brrrrrrrrr, nur 4 !! packetpuffer im chip)

Der PC hat kein Problem, die embedded dinger haben das problem, dass sie mit der netzwerk-paketverarbeitung nicht nachkommen ..

Was meinst du mit 64'iger Netzwerken ?
Du meinst, Netzsegmente über Router/Gateways trennen ?
Prinzipiell ja, nur leider tritt mein Problem schon bei mehr als 5 kleinen (broadcast) paketen auf (wenn dann auch sehr viel seltener)

Das mit dem Userspace ARPD hatte ich auch schon im Hinterkopf, hab aber bisher keinen gefunden, der direkt für mein Problem out of the box einsetzbar wäre, wäre aber wohl eine Lösungsmöglichkeit. Ich fand es nur einfacher, direkt den cache timer im kernel zu beinflussen, als gleich einen ganzen ARP daemon zu schreiben/adaptieren/installieren (wenn das eben ginge mit dem timer)

Könnte meine Idee mit ioctl ( SIOCSARP) eigentlich funktionieren ? Stellt ein (Neu)schreiben des ARP-Eintrags über dieses Interface den Timer zurück ? Hab das noch nicht ausprobiert ..


Aber herzlichen Dank für deine Inputs, flugopa !
 
nein, nur ein Linux PC, die anderen Netzteilnehmer sind embedded devices mit propriäterer hard/software. (91c111 netz-chip, brrrrrrrrr, nur 4 !! packetpuffer im chip)
Kannst Du die Hardwareangaben konkretisieren?

Was meinst du mit 64'iger Netzwerken ?
Du meinst, Netzsegmente über Router/Gateways trennen ?
Oft werden Switche eingesetzt auf denen man VLANs abbildet.
Theorie: ein Switch mit 48Ports kann 48-VLANs verwalten. (Einsatz dieser Konfiguration meistens nur im Testfeld)
VLAN bedeutet, daß der Boradcast im VLAN bleibt.
Ein großer Cisco kann noch mehr.

Prinzipiell ja, nur leider tritt mein Problem schon bei mehr als 5 kleinen
Evtl. doch ein Cisco-Switch ?

Noch eine Idee die mir gerade durch den Kopf schiesst....
Den Linux-PC mit 250-VLANs konfigurieren. Evtl. kann uns ein Profi sagen, ob das Schwachsinn ist, oder nicht unter Berücksitigung Deiner Beschreibung.

Noch eine URL zur Anregung: http://www.linuxjournal.com/article/7268
 
Warum laufen denn die embedded-Devices nicht in einem separaten Netz?
.
.
.
EDIT (autom. Beitragszusammenführung) :
.

oder sind das 250 Embedded-Devices?
 
Zuletzt bearbeitet:
Also die 250 embedded + der PC laufen in einem eigenen Netzsegment, es muss jeder mit jedem reden können

Bzg VLAN: Ich bin mir nicht sicher, ob das wirklich die broadcasts in alle netze verhindert, denn leider bekommt dann ja trotzdem jeder angeschlossene Teilnehmer den broadcast, irgendwer muss ja wissen/feststellen in welchem Netz sich dann welche IP-Adresse befindet, oder ? Bin da aber nicht so firm.
Ich verwende allerdinge bereits ein VLAN auf dem PC, worüber ich einem Multicast Datenstrom führe (verwende derzeit nur den VLAN Tag zur Priorisierung im Verkehr über switches) (der alle devices erreichen können muss - igmp support ist in Planung)

Mein ursächliches Problem ist, das der Netzchip in den embedded devices nur über 4 Packetpuffer verfügt und die Interrupt-Latenz zum Auslesen schon bei 40µs liegt und in der Zeit mir der Puffer übergeht und einfach Datenpackete verloren gehen (weil viele kleine Pakete in kurzer zeit ankommen -> ARP requests)
Zwar wiederholt der PC ja die ARP requests und irgendwann kommt die Verbindung dann meist zustande, aber das passiert dann schon nach einem Timeout im System ist ist als Fehler bemerkbar.

Über das embedded system kann ich nicht viel sagen, ist ein eigenbau-OS mit softcore auf FPGA.

Ich bin mir bewusst, das das ganze nie ganz sauber laufen kann, habe aber darauf leider keinen wirklichen Einfluss, nur auf die Linux-PC Software.
 
Zuletzt bearbeitet:
Über das embedded system kann ich nicht viel sagen, ist ein eigenbau-OS mit softcore auf FPGA.

Ich bin mir bewusst, das das ganze nie ganz sauber laufen kann, habe aber darauf leider keinen wirklichen Einfluss, nur auf die Linux-PC Software.

Wenn der Kunde so eine Hardware unbedingt einsetzen will, sollte er auch tief in die Tasche greifen und einen großen Cisco-Catalyst Ordern. Danach kannst Du 250 VLANs kreieren und Dein Problem ist gelöst, den Du bist ja nicht Johann Friedrich Böttger der "Gold" herstellen kann. Es wäre das gleiche, wenn einer sagt: mach aus einen C64 ein 3D-Kino.

Ich denke das die Projektplaner nochmal in sich gehen sollten, denn mehr weiss ich nicht. Du kannst ja als hinhaltetaktik den Vorgesetzten sagen, daß Du ein 10Gbit-Netz brauchst incl. der 10Gbit-Switche in LWL-Ausführung und Messprotokoll von jeder Kabelverbindung.
 
Ha, die Antwort vom Projektmanagement kann ich mir lebhaft vorstellen :-), das System steht ja schon beim Kunden, hab das ja nur per Fernwartung analysieren dürfen ....

Da bleibt wohl nur (zumindest als Übergangslösung) es mal mit stat. ARP-Einträgen zu versuchen ...
 
Nein, das möchste ich eben nicht, das System soll ja weiterhin voll-dynamisch bleiben. Ich will nur mein Wissen auf User-Ebene, dass eine Verbindung zum Ziel vorhanden ist (broadcast) dem ARP layer mitteilen, damit der nicht ARP requests schicken muss wenn ich ein Packet zu diesem Ziel versenden will ...
Die Embedded Geräte haben offensichtlich ein Problem mit den vielen ARP-Requests... oder?
Nun möchtest Du einen Broadcast schicken um zu prüfen, ob der Client noch erreichbar ist - wenn ja dann den ARP-Timer noch mal verlängern....?

Habe ich das richtig verstanden?

Die Broadcast werden den Embedded-Clients auch wieder zu schaffen machen....
Wenn ich die Frage richtig interpretiert habe, könntest Du doch den ARP-Timer auf mehrere Stunden hoch schrauben.
Allerdings könntest Du dann Probleme in Verbindung mit DHCP bekommen (falls im Einsatz)
Bei fester IP-Vergabe sollte es aber kein Problem sein, da Du selten die Netzwerkkarte an einem Gerät oder das ganze Gerät tauschst....
Falls doch, musst Du ggf. den einen ARP-Eintrag manuell auf dem Server löschen....


hier noch eine gute Erklärung zu ARP....
http://linux-ip.net/html/ether-arp.html
 

Ähnliche Themen

Ubuntu X / dbus problem

Squid nur zum maskieren der eigenen IP, nicht für Webserver auf port 80

Linuxpartition zerschossen

WLan: Prism54 - USB

Externe Medien nicht mountbar

Zurück
Oben