Hallo,
ich habe einen externen DHCP Server, welchen ich im UTM via DHCP-Relay auch eingetragen habe.
Seitdem wird die Log (und auch die Syslog) komplett mit dem dhcprelay Server zugespammt.
Teilweise über 2000 Einträge pro Minute.
Ein sinnvolles Monitoring und Auswerten der Log ist da nicht mehr wirklich möglich.
Gibt es irgendeine Möglichkeit, den dhcprelay aus der Syslog des UTM zu entfernen?
Danke
Viele Grüße,
Bastian Schneider
dhcprelay spammt Log zu
Moderator: Securepoint
Antwort auf die Frage: Nein. Aber das wussten Sie ja schon
Viel interessanter ist doch, warum da so viele Log-Einträge generiert werden. Im Normalfall erzeugt die Software für jedes zugestellte DHCP-Paket 2 Logeinträge. Also entweder da werden einige DHCP-Requests erzeugt, oder Ihr Server schickt irgendwelche komischen Sachen zurück. Können Sie mit tcpdump rausfinden:
Viel interessanter ist doch, warum da so viele Log-Einträge generiert werden. Im Normalfall erzeugt die Software für jedes zugestellte DHCP-Paket 2 Logeinträge. Also entweder da werden einige DHCP-Requests erzeugt, oder Ihr Server schickt irgendwelche komischen Sachen zurück. Können Sie mit tcpdump rausfinden:
Code: Alles auswählen
# tcpdump -i <serverseitiges-interface> -nnp port 67 or port 68
Ja, ich weiß, das haben wir ja telefonisch schon besprochen
Mein Gedanke war, vielleicht gibt es vorübergehend einen "kreativen" Weg der Community.
Habe den Syslog Server aufgesetzt, der durch die vielen Einträge die kommen, eine Server-CPU zu 100% auslastet und nicht nachkommt mit Speichern...
Zusätzlich ist die CPU der UTM zu 75% durch dhcprelay und Log belegt...
Daher muss ich irgendwie eine Lösung finden...
Ich habe einen tcpdump erstellt.
13:19:22.654317 IP 192.168.115.9.67 > 192.168.115.3.67: BOOTP/DHCP, Request from 1c:6f:65:4d:d3:90, length 323
13:19:22.654931 IP 192.168.115.3.67 > 192.168.115.9.67: BOOTP/DHCP, Reply, length 300
13:19:22.655269 IP 192.168.115.9.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
13:19:22.655596 IP 192.168.115.9.67 > 192.168.115.3.67: BOOTP/DHCP, Request from 74:e1:b6:bd:00:4d, length 300
13:19:22.656119 IP 192.168.115.3.67 > 192.168.115.9.67: BOOTP/DHCP, Reply, length 300
13:19:22.656460 IP 192.168.115.9.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
usw.. im Prinzip auch immer wieder die gleichen MAC-Adressen.
Das dann alle paar Millisekunden...
Für mich siehts ja aus, als liefert mein Server korrekte Antworten auf viel zu viele Requests die die Clients verursachen.
Werde jetzt mal das Netz genauer analysieren, wieso die Clients so oft requesten etc..
Bin aber schonmal einen Schritt weiter, danke für den Tipp!
Falls Sie noch einen Tipp haben, woran das liegen könnte, wäre ich auch dankbar, aber das ist ja im Prinzip kein Fall mehr für Securepoint, sondern für mich als Administrator
Mein Gedanke war, vielleicht gibt es vorübergehend einen "kreativen" Weg der Community.
Habe den Syslog Server aufgesetzt, der durch die vielen Einträge die kommen, eine Server-CPU zu 100% auslastet und nicht nachkommt mit Speichern...
Zusätzlich ist die CPU der UTM zu 75% durch dhcprelay und Log belegt...
Daher muss ich irgendwie eine Lösung finden...
Ich habe einen tcpdump erstellt.
13:19:22.654317 IP 192.168.115.9.67 > 192.168.115.3.67: BOOTP/DHCP, Request from 1c:6f:65:4d:d3:90, length 323
13:19:22.654931 IP 192.168.115.3.67 > 192.168.115.9.67: BOOTP/DHCP, Reply, length 300
13:19:22.655269 IP 192.168.115.9.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
13:19:22.655596 IP 192.168.115.9.67 > 192.168.115.3.67: BOOTP/DHCP, Request from 74:e1:b6:bd:00:4d, length 300
13:19:22.656119 IP 192.168.115.3.67 > 192.168.115.9.67: BOOTP/DHCP, Reply, length 300
13:19:22.656460 IP 192.168.115.9.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
usw.. im Prinzip auch immer wieder die gleichen MAC-Adressen.
Das dann alle paar Millisekunden...
Für mich siehts ja aus, als liefert mein Server korrekte Antworten auf viel zu viele Requests die die Clients verursachen.
Werde jetzt mal das Netz genauer analysieren, wieso die Clients so oft requesten etc..
Bin aber schonmal einen Schritt weiter, danke für den Tipp!
Falls Sie noch einen Tipp haben, woran das liegen könnte, wäre ich auch dankbar, aber das ist ja im Prinzip kein Fall mehr für Securepoint, sondern für mich als Administrator