Mikrotik DHCP bekommt keine Anfrage von älteren Clients
Nochmals hallo zusammen,
nachdem ich mit der Hilfe aus dem Forum hier fast mein gesamtes Netz auf einen MT RB5009 migriert habe, stehe ich vor einem seltsamen Phänomen.
Schließe ich einen Laptop an einen Port an, der auf ein bestimmtes VLAN gebunden ist (VLAN 30), bekomme ich eine DHCP-Anfrage auf dem passenden DCHP-Server (dhcp30) und es wird eine Lease vergeben, alles prima.
Schließe ich jedoch ältere Hardware an denselben Port an, die ebenfalls DHCP Clients sind, bekomme ich keine Anfragen. Schließe ich dieselbe Hardware jedoch an meine FritzBox an, bekommen die Geräte eine IP.
Es handelt sich um einen D-Link DP-301 Printserver (für Parallelport, für die älteren unter uns ;) und eine älteres IP-Übertragungsgerät einer Einbruchmeldeanlage).
Hat jemand eine Idee, wo ich weitersuchen könnte? Debugging auf dem dhcp des MT liefert wie gesagt keine Anfragen.
nachdem ich mit der Hilfe aus dem Forum hier fast mein gesamtes Netz auf einen MT RB5009 migriert habe, stehe ich vor einem seltsamen Phänomen.
Schließe ich einen Laptop an einen Port an, der auf ein bestimmtes VLAN gebunden ist (VLAN 30), bekomme ich eine DHCP-Anfrage auf dem passenden DCHP-Server (dhcp30) und es wird eine Lease vergeben, alles prima.
Schließe ich jedoch ältere Hardware an denselben Port an, die ebenfalls DHCP Clients sind, bekomme ich keine Anfragen. Schließe ich dieselbe Hardware jedoch an meine FritzBox an, bekommen die Geräte eine IP.
Es handelt sich um einen D-Link DP-301 Printserver (für Parallelport, für die älteren unter uns ;) und eine älteres IP-Übertragungsgerät einer Einbruchmeldeanlage).
Hat jemand eine Idee, wo ich weitersuchen könnte? Debugging auf dem dhcp des MT liefert wie gesagt keine Anfragen.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 13335136647
Url: https://administrator.de/contentid/13335136647
Ausgedruckt am: 13.11.2024 um 08:11 Uhr
20 Kommentare
Neuester Kommentar
Was meinst du mit Debugging genau?? Hast du mit dem Torch Tool auf dem MT geprüft ob du die DHCP Requests sehen kannst?
Wenn dort gar keine DHCP Requests kommen, dann hat das 2 Gründe:
Ideal wäre auch gewesen du hättest beide DHCP Requests einmal mit dem Wireshark mitgeschnitten und nach Unterschieden gesucht. So kann man leider nur mit dir mitraten...
Wenn dort gar keine DHCP Requests kommen, dann hat das 2 Gründe:
- Das Gerät sendet gar keine DHCP Requests
- Du hast einen Fehler in deinem VLAN bzw. PVID Setup gemacht
Ideal wäre auch gewesen du hättest beide DHCP Requests einmal mit dem Wireshark mitgeschnitten und nach Unterschieden gesucht. So kann man leider nur mit dir mitraten...
Moin,
vielleicht haben die älteren Geräte auch ein Autonegotiation-Problem mit dem Mikrotik, der D-Link Printserver kann max. Fast-Ethernet (10/100 Mbit) das Meldegerät vielleicht sogar nur 10 Mbit?
Vielleicht kommt gar kein richtiger Link zustande. Entweder mal testweise einen Fast-Ethernet Switch dazwischenschalten oder den Port des Mikrotik mal fest einstellen.
Gruß
cykes
vielleicht haben die älteren Geräte auch ein Autonegotiation-Problem mit dem Mikrotik, der D-Link Printserver kann max. Fast-Ethernet (10/100 Mbit) das Meldegerät vielleicht sogar nur 10 Mbit?
Vielleicht kommt gar kein richtiger Link zustande. Entweder mal testweise einen Fast-Ethernet Switch dazwischenschalten oder den Port des Mikrotik mal fest einstellen.
Gruß
cykes
ein Autonegotiation-Problem mit dem Mikrotik
Dafür spräche was der TO sagt, das z.B. Torch usw. keinen eingehenden DHCP Request zeigt!Wenn dem so ist macht es Sinn den Anschlussport dieses Printservers im Interface Setting des MT einmal statisch (Haken bei Autonegotiation entfernen) fest auf 10 oder 100 Mbit zu setzen je nachdem was der max. kann.
(STP, IPX ist weggefiltert)
Was soll denn IPX sein?? Novell ist schon seit Jahrzehnten mausetot. Sinnvoll wäre gewesen einen Capture Filter auf UDP 67 und 68 zu setzen um nur DHCP Frames zu bekommen.Die .20.7 ist das der Printserver??
Leider hast du keinerlei Angaben zur Mac Adresse gemacht so das man nicht sicher sagen kann von wem der Request kommt.
Sicher ist aber das der DHCP Server dem Anfragenden die .20.7 zuteilt und die auch mit einem Ping Check überprüft.
Leider aber alles wild geraten weil...
- Der Request mit einer 0.0.0.0 IP kommt und daraus die Mac Adresse des Printservers nicht ersichtlich ist
- Mit den dann folgenden Offer wird nur die IP Adresse gezeigt und du hast es versäumt im Layer 2 die Mac Adresse sichtbar zu machen.
Unter diesen Umständen können auch wir nur im Trüben stochern und wild Kristallkugeln.
Gleiches gilt für das Endgerät unten was die .20.26 bekommt.
Siehst du irgendwas in den DHCP Leases im Mikrotik?
Was sagt ein Torch Sniffern auf UDP 67 und 68?
Moin,
auch nur wild geraten, aber Du hattest in Deiner Eingangsfrage geschrieben, dass der Port des MT (ether2?), an dem Du den Printserver bzw. das Meldegerät anschliesst, an VLAN 30 gebunden ist, die Anfragen/Antworten scheinen aber laut Trace aus/an VLAN 20 zu kommen - kann das vielleicht das Problem sein?
Gruß
cykes
auch nur wild geraten, aber Du hattest in Deiner Eingangsfrage geschrieben, dass der Port des MT (ether2?), an dem Du den Printserver bzw. das Meldegerät anschliesst, an VLAN 30 gebunden ist, die Anfragen/Antworten scheinen aber laut Trace aus/an VLAN 20 zu kommen - kann das vielleicht das Problem sein?
Gruß
cykes
Torch auf ether2 mit den Ports 67 + 68
Das ist leider fehlerhaft, denn du snifferst, wie man am Screeshot sieht leider immer getrennt nur nach Port 67 oder nur 68. Du hättest am Port Fenster einfach auf den "Pfeil nach unten" klicken sollen und zusätzlich noch 68 eintragen müssen um beides Request und Reply in einem Torch zu sehen!!
Man kann aber sehen das zum Request auch ein Reply kommt und der Printserver die .20.26 erhält, denn die Layer 2 Mac Adresse korrespondiert zu dieser IP!!
Damit pingt der Printserver ja sogar den Mikrotik. Er bekommt also eine gültige IP vom Server und nutzt diese auch. Die .20.26 müsste auch in den DHCP Leases im MT auftauchen und von allen anderen Geräten pingbar sein. Die Bindung seiner Mac Adresse an die .20.26 ist da eindeutig.
Nebenbei:
Hast du einmal gecheckt ob es beim Hersteller des Printservers ggf. eine neuere, aktuellere Firmware Version gibt als die die du derzeit verwendest?
Falls ja solltest du den PS in jedem Falle updaten.
Da stimmt ggf. etwas mit dem Pool bzw. den Ranges in dem Pool nicht das den Server zwingt mit einem NAK zu antworten?
Kann es sein das du da für das VLAN 20 einen Tippfehler begangen hast was die Maske oder die Ranges anbetrifft?
Sie dazu auch HIER.
Checke zu den Masken des Pools auch nochmal die Maske des VLAN 20 IP Interfaces. Da darf es keinerlei Unterschiede geben!
An den zeiten kann es nicht liegen denn DHCP kennt keine Uhrzeiten. Lediglich die Lease Time die aber einzig nur für den Server relevant ist.
Kann es sein das du da für das VLAN 20 einen Tippfehler begangen hast was die Maske oder die Ranges anbetrifft?
Sie dazu auch HIER.
Checke zu den Masken des Pools auch nochmal die Maske des VLAN 20 IP Interfaces. Da darf es keinerlei Unterschiede geben!
An den zeiten kann es nicht liegen denn DHCP kennt keine Uhrzeiten. Lediglich die Lease Time die aber einzig nur für den Server relevant ist.
Just for Info aus der MS Knowledgebase:
"Both Windows and MacOS does not use DHCP option 15 for domain search when DHCP option 119 is provided. "
Macht also wenig Sinn das zusammen zu setzen....
Hast du testweise die Options mal deaktiviert oder den PS mal in ein Segment gehängt wo der DHCP Server diese Options NICHT verwendet??
Da die Fritzbox ja auch keinerlei Options im DHCP Server supportet wäre das ggf. Wert einmal auszutesten ob diese Options den PS ggf. ins Straucheln bringen.
"Both Windows and MacOS does not use DHCP option 15 for domain search when DHCP option 119 is provided. "
Macht also wenig Sinn das zusammen zu setzen....
Hast du testweise die Options mal deaktiviert oder den PS mal in ein Segment gehängt wo der DHCP Server diese Options NICHT verwendet??
Da die Fritzbox ja auch keinerlei Options im DHCP Server supportet wäre das ggf. Wert einmal auszutesten ob diese Options den PS ggf. ins Straucheln bringen.
Moin.
Die aktuellen Mikrotik-Firmwares haben ein Problem das sie alte ARP-Einträge nicht korrekt nach der Ablaufzeit von 30 Sekunden (Default) "flushen" wenn das Gerät nicht mehr antwortet und so Konflikte entstehen können. Es bleiben also alte Einträge darin hängen. Das kannst du momentan entweder durch ein Mikrotik-Skript beheben das man regelmäßig durchlaufen lässt und verwaiste Einträge aus der ARP-Tabelle entfernt, oder du setzt im DHCP-Server die folgende Option:
Dann werden die ARP-Entries durch den DHCP-Server selbst angelegt und auch wieder zuverlässig entfernt sobald die DHCP-Lease für die MAC abgelaufen ist.
Vorher bitte sämtliche alten Einträge zur MAC aus der ARP Tabelle löschen.
Wenn du in dem VLAN keine statisch konfigurierten Clients hast kannst du auf dem Interface auch ARP deaktivieren und wenn du o.g. Option setzt. Dann können nur noch DHCP-Clients miteinander kommunizieren, oder wenn man statisch konfigurierte Clients manuell in die ARP Tabelle einträgt.
Gruß sid
Die aktuellen Mikrotik-Firmwares haben ein Problem das sie alte ARP-Einträge nicht korrekt nach der Ablaufzeit von 30 Sekunden (Default) "flushen" wenn das Gerät nicht mehr antwortet und so Konflikte entstehen können. Es bleiben also alte Einträge darin hängen. Das kannst du momentan entweder durch ein Mikrotik-Skript beheben das man regelmäßig durchlaufen lässt und verwaiste Einträge aus der ARP-Tabelle entfernt, oder du setzt im DHCP-Server die folgende Option:
Dann werden die ARP-Entries durch den DHCP-Server selbst angelegt und auch wieder zuverlässig entfernt sobald die DHCP-Lease für die MAC abgelaufen ist.
Vorher bitte sämtliche alten Einträge zur MAC aus der ARP Tabelle löschen.
Wenn du in dem VLAN keine statisch konfigurierten Clients hast kannst du auf dem Interface auch ARP deaktivieren und wenn du o.g. Option setzt. Dann können nur noch DHCP-Clients miteinander kommunizieren, oder wenn man statisch konfigurierte Clients manuell in die ARP Tabelle einträgt.
Gruß sid
Das ist nicht definitiv nicht normal. Vermutlich die Mikrotik-Config nicht mehr konsistent. Würde das Teil erst mal komplett zurücksetzen und neu clean starten.
Gerät mit doppelter MAC im Netz die dir da einen Streich spielt?
Und nimm mal testweise die Conflict-Detection raus.
Welche RouterOS Firmware geflasht?
Gerät mit doppelter MAC im Netz die dir da einen Streich spielt?
Und nimm mal testweise die Conflict-Detection raus.
Welche RouterOS Firmware geflasht?
Zitat von @maximalz:
Wie sind eure Regeln hier: Für ein (vermutlich) anderes DHCP-Problem mit einem anderen Endgerät (sendet DISCOVER ohne end-of-options) eröffne ich einen neuen Thread? Oder derselbe?
Anderes Thema bitte neuer Thread.Wie sind eure Regeln hier: Für ein (vermutlich) anderes DHCP-Problem mit einem anderen Endgerät (sendet DISCOVER ohne end-of-options) eröffne ich einen neuen Thread? Oder derselbe?