DHCP-Problem

[mrserious]

Moin,

bekomme von meinem Router seit ein paar Tagen öfter mal derartige Meldungen.
Die IP ist definitiv nur an diesem einen Rechner in Verwendung, wie kann es dazu kommen?

Code: Alles auswählen

Mar  5 08:01:03 Router dhcpd: DHCPREQUEST for 192.168.7.6 (192.168.0.1) from 68:17:29:a3:xx:xx via eth2
Mar  5 08:01:03 Router dhcpd: DHCPACK on 192.168.7.6 to 68:17:29:a3:xx:xx via eth2
Mar  5 08:01:04 Router dhcpd: DHCPDECLINE of 192.168.7.6 from 68:17:29:a3:xx:xx via eth2: not found

Und was sagt mir die eingeklammerte IP? Das ist nämlich die, ebenjenes Routers.

[4A4B]

Der Router (192.168.0.1) befindet sich nicht im selben Subnetz wie 192.168.7.6 - deswegen vielleicht das "not found" am Ende der letzten Zeile?

[mrserious]

Jau, stimmt!
Allerdings hat der Router auch noch eine IP IN diesem Subnetz (192.168.7.1).
Außerdem werfen andere Clients aus diesem Subnetz keine derartige Fehlermeldung.
Gestern betraf es zwei andere Rechner dieses Subnetzes, die habe ich vorläufig mal aus dem Verkehr gezogen.

[mrserious]

Stelle gerade fest:
Das Problem betrifft alle Clients dieses Subnetzes.
Beim ersten Beziehen der IP klappt alles, danach erscheint immer das bekannte "not found".
Könnt ihr euch das erklären?
Die zuständige config-Sparte in der dhcp.conf sieht aus, wie die der anderen Subnetze.
Hängt es mit meiner Leasetime zusammen? Die liegt moemntan bei 43200.

Besonderheit dieses Subnetzes: Es besteht ausschließlich aus baugleichen Laptops, welche auch alle mit dem selben Windows-Image bespielt wurden.
Das Image hat aber keine besonderen Netzwerkeinstellungen, die zugehörigen Netzwerkkarten stehen alle auf DHCP-Konfiguration und bekommen vom DHCP-Server dann über ihre MAC-Adresse eine einmalige, eindeutige IP-Adresse zugewiesen.
An anderen Stellen im Netz mache ich es genauso und da klappt es wunderbar.

[Cae]

Der Host fragt nach einer bestimmten IP, bekommt sie und stoesst sie praktisch sofort wieder ab, aber der Server kennt sie nicht. Vielleicht ist das Backend zu langsam? Koennten da duplizierte MAC-Adressen im Spiel sein?

Gruss Cae

[mrserious]

Guten Morgen
Was ich auf die Schnelle sagen kann: Die MAC-Adressen der Laptops, die entsprechende Fehlermeldungen warfen sind in meiner dhcp-config eindeutig.

Mit der lease-time kann das nichts zu tun haben?
Habe sie jetzt mal auf 3600 runtergedreht und zumindest bis jetzt noch keine weiteren Fehlermeldungen erhalten.

[hec_tech]

Die Lease Time hat mit deinem Problem nichts zu tun dazu musst du erst mal eine IP bekommen haben.

Die Leasetime gibt an wie lange eine IP einem Client zugeordnet ist bevor sie erneuert wird.

[DynaBlaster]

Hoi,

nach ein bisschen Recherche mal ein Schuss ins Blaue: https://lists.isc.org/pipermail/dhcp-us ... 12213.html

Ich hatte auf der Arbeit ein ähnliches Problem mit einem Bintec-Router und einem Windows-Terminal-Server-Cluster über NLB. Da hat das Bintec-Mist-Ding auf etwaige ARP-Requests in dem Subnet geantwortet, das immer wenn der Loadbalancer den User von TS-01 auf TS-02 "schieben" wollte, RDP über TCP 3389 nicht erreichbar war. Ein "direktes" Login auf beide TS funktionierte immer. Glücklicherweise konnten wir das Bintec-Teil rausschneissen und ich habe die Ursache nicht weiter verfolgt.

Setz mal Broadcast-Pings ab. Ggf. werkelt bei dir ja ein ähnliches Gerät im Netz rum und antwortet, obwohl es den Mund halten soll.

[mrserious]

Hab nen Ansatz!

Wollte einige der fehlerhaften Laptops testweise in ein anderes (vorher noch nicht existentes) Subnetz packen.
Nun bekomme ich immer Fehlermeldungen der Art

Code: Alles auswählen

DHCPREQUEST for $IP from $MACADRESSE via eth2: unknown lease $IP

Dazu ist jetzt zu sagen: Vor einigen Tagen habe ich die IPs in dem alten Subnetz mal "aufgeräumt" und wieder sauber durchnummeriert.
Dabei ist natürlich zwangsläufig passiert, dass einige IPs jetzt an andere Geräte als vorher vergeben sind.
Ist das unter Umständen ein Problem? Und wenn ja: Wie behebe ich es? Denn die Laptops versuchen ja wieder IPs zu bekommen, die sie vorher schonmal irgendwann hatten und davon kann ich sie auch erstmal nicht abbringen.
Der DHCP-Server hat die IP 192.168.0.1 und steht im übergeordneten Subnetz /16. Die Clients selber innerhalb von 192.168.7.0/24. Hat vorher aber nie Probleme gemacht, da der DHCP-Server in diesem Subnetz eben auch eine IP hat.
Trotzdem ist in den Windows-Clients als DHCP-Server die 192.168.0.1 eingetragen.
Fehlt mir da u.U. einfach eine passende Routing-Regel im iptables-Skript? Das Merkwürdige daran: Die ganze Zeit vorher lief es ja, also müssen die Requests ja irgendwie zum Server durchkommen...

Also kann ich den DHCP-Server z.B. in mehreren Bereichen lauschen lassen, bzw. sollte ich eine Art Forwarding machen in der Art

Code: Alles auswählen

192.168.7.X/24 -> 192.168.0.1/16

Das müsste eigentlich schon gehen, jedenfalls nimmt der Server Anfragen aus diesem IP-Bereich entgegen und kann auch selbst dorthin Pakete senden.

?

Habt ihr eine Idee?


Edit: Sehe gerade, das Problem tritt auch in einem anderen Subnet auf, in dem ich den DHCP-Block "aufgeräumt" habe.

[mrserious]

Habe in die einzelnen Subnetz-Blöcke meiner dhcp-config gerade mal folgendes eingebaut:

Code: Alles auswählen

option dhcp-server-identifier                   192.168.X.1;

Meint ihr, das könnte das Probem lösen?
Damit müssten die Clients doch veranlasst werden, künftige dhcp-Requests an "ihren" DHCP-Server zu stellen?
Also an die jeweilige IP des DHCP-Servers in ihrem Subnetz.


Edit:

Habe gerade testweise in einem anderen Subnetz auch mal IPs in der dhcp-config geändert und laut syslog bekommen die Geräte ohne Murren ihre neuen Adressen zugewiesen. Auch der Rück-Wechsel zum Ursprungszustand ist kein Problem.
Und das, obwohl die Subnetze Firewall-seitig und auch von der dhcp-config her identisch sind (außer eben verschiedene IP-Bereiche besitzen).
Ich beschreib's mal globaler:

Der Server hat eine Netzwerkkarte (eth2 mit 192.168.0.1/16), diese hat diverse virtuelle Netzwerkkarten (eth2:1, eth2:2, ... eth2:n).
Die virtuellen Karten haben jeweils Adressen aus dem Bereich 192.168.X.1/24.
Aus den 24er Netzen kann man die 192.168.0.1 wunderbar erreichen, auch andersrum funktioniert es.
Daher verstehe ich nicht, an welcher Stelle der DHCP-Request fehlschlägt und warum sich Geräte z.T. nicht ihre neuen Adressen holen, es bei anderen Geräten aber wunderbar funktioniert.
("Andere Geräte" sind zwei Windows 7-Rechner und an die 20 Accesspoints verschiedener Hersteller).

[mrserious]

Hat niemand eine Idee?