dnsmasq als DHCP-Proxy statt als DHCP-Server

[Stefan Baur]

Hallo Liste,

man kann dnsmasq ja als DHCP-Proxy in einem Netz, in dem bereits ein
DHCP-Server aktiv ist, laufen lassen:

dhcp-range=<dhcpproxy.server.ip.hier>,proxy

statt

dhcp-range=192.168.0.50,192.168.0.150,12h

Meistens macht man das ja, um eine PXE-Bootkonfiguration zu verteilen,
wenn man den eigentlichen DHCP-Server nicht dahingehend erweitern kann.

Aber sollte das auch für andere Parameter klappen?

Also wenn ich statt PXE-Kram z.B. einfach nur ein paar zusätzliche
statische Routen bekannt geben möchte?

Ich habe diesen "Header" verwendet, das ganze auf einem Debian 10:

interface=br0
bind-interfaces
port=0
log-dhcp
dhcp-no-override
dhcp-range=dhcpproxy.server.ip.hier,proxy

Und dann abwechselnd

dhcp-option=249,192.168.123.0/24,dhcpproxy.server.ip.hier

und

dhcp-option=121,192.168.123.0/24,dhcpproxy.server.ip.hier

Leider funktioniert das nicht.
Ich habe es mit einem Ubuntu 20.04, einem Windows XP, und einem Windows
10 als Clients versucht, keiner davon hat die zusätzliche Route angezeigt.

Im syslog des dhcpproxys stehen nach den startup-Meldungen immer nur
Einträge wie

Jun 14 19:41:16 dhcpproxybox dnsmasq-dhcp[5486]: 4106169769 available
DHCP subnet: dhcpproxy.server.ip.hier/255.255.255.0
Jun 14 19:41:16 dhcpproxybox dnsmasq-dhcp[5486]: 4106169769 vendor
class: MSFT 5.0
Jun 14 19:41:16 dhcpproxybox dnsmasq-dhcp[5486]: 4106169769 client
provides name: WINDOWS10BOX

- mehr passiert offenbar nicht.

Geht das, was ich vorhabe, im Proxy-Mode gar nicht (müsste dnsmasq dazu
der echte DHCP-Server sein?), mache ich etwas falsch, oder ist hier was
kaputt?

Gruß
Stefan

[Peter Wiersig]

Post by Stefan Baur
dhcp-option=121,192.168.123.0/24,dhcpproxy.server.ip.hier

aus "man dnsmasq":
-O, --dhcp-option=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],][<opt>|option:<opt-name>|option6:<opt>|option6:<opt-name>],[<value>[,<value>]]

Ich habe das noch nicht verwenden müssen, kannst du mir sagen, worauf
deine Zeile von o.g. matchen sollte? Ich denke das ist die
<opt>,<value>,<value> Schreibweise?

Und was war noch Option 249 oder 121? Ich habe die auch nicht mehr im
Kopf, und die Manpage beschreibt diese beiden nicht.

weiterhin: willst du nicht eigentlich dhcp-proxy=... oder so benutzen?
oder kann dhcpproxy.server.ip.hier die Options alle gar nicht setzen?

Könntest du auch nur mit den dnsmasq arbeiten, bzw. wo kommt dein
größeres Problem eigentlich her? Ich habe bei deiner Frage irgendene
komische "Z geht nicht weil Y" obwohl das Problem eher X ist.

Post by Stefan Baur
Geht das, was ich vorhabe, im Proxy-Mode gar nicht (müsste dnsmasq dazu
der echte DHCP-Server sein?), mache ich etwas falsch, oder ist hier was
kaputt?

Du willst das auch für den """ PXE "proxy-DHCP" """ aus der Manpage
nutzen?

Wenn du deine Konfiguration mit Ubuntu ausprobierst, was ist dann bei
"dhclient -v " o.ä. auf der Client Seite zu sehen?

In deinem Log ist dhcpproxybox der dnsmasq und dhcpproxy der entfernte
nicht änderbare dhcp-Server?

Peter

[Stefan Baur]

Post by Peter Wiersig

Post by Stefan Baur
dhcp-option=121,192.168.123.0/24,dhcpproxy.server.ip.hier

-O, --dhcp-option=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],][<opt>|option:<opt-name>|option6:<opt>|option6:<opt-name>],[<value>[,<value>]]
Ich habe das noch nicht verwenden müssen, kannst du mir sagen, worauf
deine Zeile von o.g. matchen sollte? Ich denke das ist die
<opt>,<value>,<value> Schreibweise?

Richtig, das ist sie.
121 bzw. 249 ist die zu setzende Option, 192.168.123.0/24 ist das Netz,
für das die Route gesetzt werden soll, dhcpproxy.server.ip.hier ist die
IP des Systems, auf dem dieser dnsmasq läuft - denn der Rechner ist auch
gleichzeitig der, der das Gateway ins 192.168.123.0/24 konfiguriert hat.

Er hängt mit einem Interface darin, das IP-Forwarding etc. ist auch
passend eingestellt, d.h. wenn ich an den Clients die oben genannte
Route manuell setze, läuft alles wie es soll. Ich möchte nur das
manuelle Setzen der Routen an Maschinen, die ihre restliche
IP-Konfiguration per DHCP bekommen, vermeiden - und zwar ohne den
bestehenden DHCP-Server anfassen zu müssen. Deswegen der Ansatz mit dem
Proxy-Mode. Der für PXE wie gesagt wunderbar funktioniert.

Post by Peter Wiersig
Und was war noch Option 249 oder 121? Ich habe die auch nicht mehr im
Kopf, und die Manpage beschreibt diese beiden nicht.

Je nachdem, welcher Doku Du glauben willst, ist entweder 249 oder 121
die Option, um eine statische Route per DHCP zum Client zu pushen.

Post by Peter Wiersig
weiterhin: willst du nicht eigentlich dhcp-proxy=... oder so benutzen?
oder kann dhcpproxy.server.ip.hier die Options alle gar nicht setzen?

Laut manpage schaltet sich dnsmasq in den DHCP-Proxy-Modus, wenn man
statt (z.B.)

dhcp-range=192.168.0.50,192.168.0.150,12h

den Parameter so befüllt:

dhcp-range=<dhcpproxy.server.ip.hier>,proxy

Also die eigene IP des Rechners mit dnsmasq dort angibt.

Und wie gesagt: Wenn man dnsmasq als DHCP-Proxy verwenden will, um in
einem Netz mit vorhandenem DHCP-Server die notwendigen Informationen für
PXE zu ergänzen, dann klappt das so auch. Selbst schon mehrfach genutzt.

Post by Peter Wiersig
Könntest du auch nur mit den dnsmasq arbeiten, bzw. wo kommt dein
größeres Problem eigentlich her? Ich habe bei deiner Frage irgendene
komische "Z geht nicht weil Y" obwohl das Problem eher X ist.

Siehe oben: DHCP-Server im Netz aktiv und die Config soll nicht
angefasst werden. Trotzdem soll die zusätzliche Route auf den Clients
eingetragen werden.
Frage daher: Geht das analog dem Ergänzen der für PXE benötigten
Informationen mit dnsmasq im DHCP-Proxy-Modus, oder ist dnsmasq dafür
schlichtweg nicht geeignet und daher jegliche Suche nach einer passenden
Konfiguration sinnlose Zeitverschwendung?

Post by Peter Wiersig

Post by Stefan Baur
Geht das, was ich vorhabe, im Proxy-Mode gar nicht (müsste dnsmasq dazu
der echte DHCP-Server sein?), mache ich etwas falsch, oder ist hier was
kaputt?

Du willst das auch für den """ PXE "proxy-DHCP" """ aus der Manpage
nutzen?

Also grundsätzlich ist bei dnsmasq die Manpage leider nicht so hilfreich
wie die Kommentare im Config-File, das von Debian als Default
mitgeliefert wird.

Die Manpage scheint mehr davon auszugehen, dass man dnsmasq manuell an
der Kommandozeile starten will, mit diversen Parametern, statt einem
Configfile.

Aber im Block für

-F,--dhcp-range=[tag:<tag>[,tag:<tag>],][set:<tag>,]<start-addr>[,<end-addr>|<mode>][,<netmask>[,<broadcast>]][,<lease
time>]

-F,--dhcp-range=[tag:<tag>[,tag:<tag>],][set:<tag>,]<start-IPv6addr>[,<end-IPv6addr>|constructor:<interface>][,<mode>][,<prefix-len>][,<lease
time>]

findet sich der Absatz

For IPv4, the <mode> may be proxy in which case dnsmasq will
provide proxy-DHCP on the specified subnet. (See --pxe-prompt
and --pxe-service for details.)

Und wie Du oben siehst, ja, genau das tue ich.
dhcp-range=<dhcpproxy.server.ip.hier>,proxy
^^^^^

Post by Peter Wiersig
Wenn du deine Konfiguration mit Ubuntu ausprobierst, was ist dann bei
"dhclient -v " o.ä. auf der Client Seite zu sehen?

Genau das gleiche, wie wenn der Proxy nicht aktiv ist. Das ist etwas
frustrierend. So was wie -vv kennt dhclient leider nicht.

Post by Peter Wiersig
In deinem Log ist dhcpproxybox der dnsmasq und dhcpproxy der entfernte
nicht änderbare dhcp-Server?

Nein. "dhcpproxybox" ist der Hostname zur IP-Adresse
"dhcpproxy.server.ip.hier".

Wenn es das für Dich einfacher macht, stell Dir vor, es spielt alles im
192.168.0.0/24, Gateway, DNS und DHCP-Server ist 192.168.0.*1*, und der
dnsmasq läuft auf einer Maschine mit dem Namen dhcpproxybox und der IP
192.168.0.*2* - diese Maschine hat auch ein zweites Interface mit
192.168.123.2, worüber sie das 192.168.123.0/24 erreichen kann.

Und wie gesagt: Am Routing etc. hängt es nicht, trage ich die Routen
manuell ein, klappt alles.

Es geht um die zentrale Frage: Kann dnsmasq überhaupt im Proxy-Modus
Routen an DHCP-Pakete "anhängen", oder geht das nur für PXE-Kram?
Und nur wenn das überhaupt auch für Routen geht, gibt es die Folgefrage:
Was mache ich falsch?

Gruß
Stefan

[Stefan Baur]

Post by Stefan Baur
Laut manpage schaltet sich dnsmasq in den DHCP-Proxy-Modus, wenn man
statt (z.B.)
dhcp-range=192.168.0.50,192.168.0.150,12h
dhcp-range=<dhcpproxy.server.ip.hier>,proxy
Also die eigene IP des Rechners mit dnsmasq dort angibt.

Hier war ein Fehler in meinem Verständnis/Aufschrieb. An dieser Stelle
darf man nicht dhcpproxy.server.ip.hier setzen, sondern muss die
Netzwerkadresse verwenden, also beispielhaft bei einem 192.168.0.0/24
die 192.168.0.0 - ohne /24 oder 255.255.255.0 dahinter. Nur, leider löst
das mein Problem mit den nicht hinzugefügten Routen weiterhin nicht.

Gruß
Stefan

[Christian Knoke]

Post by Stefan Baur

Post by Stefan Baur
Laut manpage schaltet sich dnsmasq in den DHCP-Proxy-Modus, wenn man
statt (z.B.)
dhcp-range=192.168.0.50,192.168.0.150,12h
dhcp-range=<dhcpproxy.server.ip.hier>,proxy
Also die eigene IP des Rechners mit dnsmasq dort angibt.

Hier war ein Fehler in meinem Verständnis/Aufschrieb. An dieser Stelle
darf man nicht dhcpproxy.server.ip.hier setzen, sondern muss die
Netzwerkadresse verwenden, also beispielhaft bei einem 192.168.0.0/24
die 192.168.0.0 - ohne /24 oder 255.255.255.0 dahinter. Nur, leider löst
das mein Problem mit den nicht hinzugefügten Routen weiterhin nicht.

Ich vermute, dein Problem rührt daher, dass sich zwei DHCP-Server im selben
Netzsegment in die Quere kommen.

Gruß
Christian

[Stefan Baur]

Post by Christian Knoke
Ich vermute, dein Problem rührt daher, dass sich zwei DHCP-Server im selben
Netzsegment in die Quere kommen.

Eigentlich nicht: Deswegen ist dnsmasq ja im Proxy-Modus, anstatt dass
er versucht, selbst IPs zu vergeben.

Er brüllt quasi nur hinterher, was fehlt, sobald der offizielle Server
geantwortet hat. Für die zusätzlichen Parameter, die man für PXE
braucht, ist das dokumentiertes, erlaubtes, standardkonformes Verhalten.

Ob es für zusätzliche Routen auch geht, dazu schweigt sich die Doku aus.
Deswegen meine Frage, da es bei mir nicht geht: Geht das überhaupt, so
wie es auch für PXE geht, oder jage ich einem Phantom nach?

Gruß
Stefan

[Christian Knoke]

Post by Stefan Baur

Post by Christian Knoke
Ich vermute, dein Problem rührt daher, dass sich zwei DHCP-Server im selben
Netzsegment in die Quere kommen.

Eigentlich nicht: Deswegen ist dnsmasq ja im Proxy-Modus, anstatt dass
er versucht, selbst IPs zu vergeben.

Wenn ich so die man page betrachte, würde ich sagen, IP- und
Routen/r-Konfiguration gehören zusammen. Der zuerst erreichte DHCP-Server
hat das Sagen.

Proxy oder Relay macht Sinn für entfernte DHCP-Server.

Gruß
Christian

Post by Stefan Baur
Er brüllt quasi nur hinterher, was fehlt, sobald der offizielle Server
geantwortet hat. Für die zusätzlichen Parameter, die man für PXE
braucht, ist das dokumentiertes, erlaubtes, standardkonformes Verhalten.
Ob es für zusätzliche Routen auch geht, dazu schweigt sich die Doku aus.
Deswegen meine Frage, da es bei mir nicht geht: Geht das überhaupt, so
wie es auch für PXE geht, oder jage ich einem Phantom nach?
Gruß
Stefan

[Stefan Baur]

Post by Christian Knoke
Wenn ich so die man page betrachte, würde ich sagen, IP- und
Routen/r-Konfiguration gehören zusammen. Der zuerst erreichte DHCP-Server
hat das Sagen.
Proxy oder Relay macht Sinn für entfernte DHCP-Server.

Eben nicht nur: Man setzt es auch ein, wenn man den bestehenden
DHCP-Server nicht anfassen kann/will, und PXE-Boot einführen will.

Ist z.B. in Netzen brauchbar, in denen man "nur mal eben schnell" was
mit PXE testen/vorführen will, dann muss man nicht die Config des
produktiven Systems umbiegen. Einfach risikoärmer. Tut alles, ist's gut,
tut's nicht, kann man das Ding wieder vom Netz nehmen und alles ist wie
vorher.

Oder wenn Du eine Windows-Umgebung hast, wo auch DHCP und DNS vom
Windows-AD kommen, aber kein PXE aktiv ist, weil bislang niemand Clients
vom Netz installiert, und $ADMIN nicht willens und/oder nicht fähig ist,
PXE einzurichten.

Genauso gibt es die Situation im Privatnutzerbereich, wenn man einen
Zwangsrouter/Plasterouter vom Provider hat (Kabelprovider, I'm looking
at you), der halt keine PXE-Config verteilen kann. Raspi oder irgendeine
kleine Kiste dazu, dnsmasq im Proxy-Mode drauf, PXE-Konfiguration
dazuklatschen, glücklich sein.

Gruß
Stefan

[Christian Knoke]

Post by Stefan Baur

Post by Christian Knoke
Wenn ich so die man page betrachte, würde ich sagen, IP- und
Routen/r-Konfiguration gehören zusammen. Der zuerst erreichte DHCP-Server
hat das Sagen.
Proxy oder Relay macht Sinn für entfernte DHCP-Server.

Eben nicht nur: Man setzt es auch ein, wenn man den bestehenden
DHCP-Server nicht anfassen kann/will, und PXE-Boot einführen will.

Laut wikipedia geht es, wenn du die beiden DHCP-Server im Segment
aufspaltest, und dein dnsmasq nur die PXE-Abfragen (per DHCP-Protokoll)
beantwortet (und der Router-Server den Rest).

https://de.wikipedia.org/wiki/Preboot_Execution_Environment#Proxy_DHCP

Gruß
Christian

[Stefan Baur]

Post by Christian Knoke
Laut wikipedia geht es, wenn du die beiden DHCP-Server im Segment
aufspaltest, und dein dnsmasq nur die PXE-Abfragen (per DHCP-Protokoll)
beantwortet (und der Router-Server den Rest).
https://de.wikipedia.org/wiki/Preboot_Execution_Environment#Proxy_DHCP

Das war ja aber nicht die Frage. Dass es für PXE geht, weiß ich aus
Theorie und Praxis.

Die Frage ist, kann ich den gleichen Weg, der dazu dient,
PXE-Geschichten "hinterherzubrüllen", auch dazu benutzen, zusätzliche
Routen zu verteilen, oder nicht?

Gruß
Stefan

[Christian Knoke]

Post by Stefan Baur

Post by Christian Knoke
Laut wikipedia geht es, wenn du die beiden DHCP-Server im Segment
aufspaltest, und dein dnsmasq nur die PXE-Abfragen (per DHCP-Protokoll)
beantwortet (und der Router-Server den Rest).
https://de.wikipedia.org/wiki/Preboot_Execution_Environment#Proxy_DHCP

Das war ja aber nicht die Frage. Dass es für PXE geht, weiß ich aus
Theorie und Praxis.
Die Frage ist, kann ich den gleichen Weg, der dazu dient,
PXE-Geschichten "hinterherzubrüllen", auch dazu benutzen, zusätzliche
Routen zu verteilen, oder nicht?

Hinterherbrüllen geht nicht.

Ich verstehe es so, dass der eine DHCP-Server (dnsmasq) die PXE-Abfragen
beantwortet, der andere (Router) den Rest, also IP-Nummern usw. Da Routen zu
letzterem gehören (und nicht zu PXE), werden sie vom Router verteilt. Wenn
dnsmasq in diesem Kontext auch Routen verteilt, würde es dem im gleichen
Segment arbeitenden DHCP-Server des Routers in die Quere kommen.

Also nein.

Von daher macht also auch der Proxymodus keinen Sinn. Der ist zur Abfrage
von entfernten, im Segment nicht erreichbaren Servern gedacht.

Du hättest dann einen undefinierten Zustand. Die Clients würden sich mal bei
dem einen, mal bei dem anderen Server die IPs und Routen holen.

Gruß
Christian

[Stefan Baur]

Post by Christian Knoke
Von daher macht also auch der Proxymodus keinen Sinn. Der ist zur Abfrage
von entfernten, im Segment nicht erreichbaren Servern gedacht.

Und eben ganz hochoffiziell zum Verteilen des PXE-Krams, ohne dabei auch
IP-Adressen rauszuballern.
Proxymodus heißt bei dnsmasq (auch), dass er nicht selbst auf die Idee
kommen soll, IP-Adressen zu verteilen. Auch wenn er im gleichen Netz
steht um den PXE-Kram zu ergänzen, hat er deswegen im Proxymodus zu laufen.

Post by Christian Knoke
Du hättest dann einen undefinierten Zustand. Die Clients würden sich mal bei
dem einen, mal bei dem anderen Server die IPs und Routen holen.

Undefiniert würde ich das nicht nennen. Da dnsmasq im Proxymode ist,
verteilt er ja gar keine IPs - anders als ein rogue DHCP server. Nur
passiert halt einfach nicht das gewünschte, weil dnsmasq die Routen auch
nicht verteilt. Er fühlt sich nicht angesprochen und daher nicht
motiviert, Dinge zu tun. Ist halt schade, dass es scheinbar keine
offizielle Doku gibt, die sagt "geht nur für PXE" oder "geht auch für
sonstige DHCP-Options", und man mutmaßen muss.

Gruß
Stefan

[Marc Haber]

Post by Christian Knoke
Ich vermute, dein Problem rührt daher, dass sich zwei DHCP-Server im selben
Netzsegment in die Quere kommen.

Das tun sie nicht notwendigerweise. Der der schneller antwortet oder
den vom Client erwarteten Optionsumfang liefert, gewinnt. Usecases:

(1)
zwei DHCP-Server, die voneinander wissen und ihre Leases-Datenbanken
miteinander abgleichen: Redundanz. Abhängig von der eingesetzten
Software bekommt ein Client nur eine Antwort und der andere Server
schweigt oder er der Client bekommt zweimal dieselbe Adresse
angeboten. Es gibt vermutlich auch Szenarios, wo der Client zwei
unterschiedliche Adressen angeboten bekommt und sich eine aussuchen
kann, auch das funktioniert wenn sich die Server sicher sein können
dass die Adressen die sie gerade anbieten auch wirklich frei sind.

(2)
zwei DHCP-Server, die IP-Adressen aus zwei nicht überlappenden Pools
verteilen: Kann ich mir nicht vorstellen, warum man das haben möchte,
funktionieren tut es aber. Der schnellere gewinnt.

(3)
Softwareverteilung. Ich habe mal eine Enterprise-Software zur
Softwareverteilung gegeben, die ohne Eingriff in den vorhandenen
DHCP-Server funktioniert hat: Der Softwareverteilungsserver hat sich,
wenn ein Client aus dem Netz booten wollte, und dieser Client als
"soll installiert werden" in der Softwareverteilung stand, schnell für
die MAC-Adresse des Clients beim "richtigen" DHCP-Server eine
IP-Adresse geholt und diese dann selbst dem Client zusammen mit den
Informationen für den PXE-Boot angeboten. Der Client weiß ja auch,
dass er aus dem Netz booten möchte, hat die Antwort vom "echten"
DHCP-Server, die keine Informationen fürs Booten enthält, ignoriert
und dann mit den von der Softwareverteilung angebotenen Daten aus dem
Netz gebootet. Abwegig, funktioniert aber auch.

Grüße
Marc

[Stefan Baur]

Post by Marc Haber
(3)
Softwareverteilung. Ich habe mal eine Enterprise-Software zur
Softwareverteilung gegeben, die ohne Eingriff in den vorhandenen
DHCP-Server funktioniert hat: Der Softwareverteilungsserver hat sich,
wenn ein Client aus dem Netz booten wollte, und dieser Client als
"soll installiert werden" in der Softwareverteilung stand, schnell für
die MAC-Adresse des Clients beim "richtigen" DHCP-Server eine
IP-Adresse geholt und diese dann selbst dem Client zusammen mit den
Informationen für den PXE-Boot angeboten. Der Client weiß ja auch,
dass er aus dem Netz booten möchte, hat die Antwort vom "echten"
DHCP-Server, die keine Informationen fürs Booten enthält, ignoriert
und dann mit den von der Softwareverteilung angebotenen Daten aus dem
Netz gebootet. Abwegig, funktioniert aber auch.

Ist aber wie gesagt für diesen Zweck gar nicht notwendig, das so
aufwendig zu gestalten. Den dnsmasq im Proxy-Modus ins gleiche Netz
hängen (er braucht nur ein Interface), PXE-Infos ergänzen, fertig. IP,
DNS, Default Gateway kommt vom regulären DHCP-Server, PXE-Infos vom
dnsmasq. Bauanleitung z.B. hier:
<https://manski.net/2016/09/pxe-server-on-existing-network-dhcp-proxy-on-ubuntu/>

Gruß
Stefan

[Marc Haber]

Post by Christian Knoke
Ich vermute, dein Problem rührt daher, dass sich zwei DHCP-Server im selben
Netzsegment in die Quere kommen.

Das tun sie nicht notwendigerweise. Der der schneller antwortet oder
den vom Client erwarteten Optionsumfang liefert, gewinnt. Usecases:

(1)
zwei DHCP-Server, die voneinander wissen und ihre Leases-Datenbanken
miteinander abgleichen: Redundanz. Abhängig von der eingesetzten
Software bekommt ein Client nur eine Antwort und der andere Server
schweigt oder er der Client bekommt zweimal dieselbe Adresse
angeboten. Es gibt vermutlich auch Szenarios, wo der Client zwei
unterschiedliche Adressen angeboten bekommt und sich eine aussuchen
kann, auch das funktioniert wenn sich die Server sicher sein können
dass die Adressen die sie gerade anbieten auch wirklich frei sind.

(2)
zwei DHCP-Server, die IP-Adressen aus zwei nicht überlappenden Pools
verteilen: Kann ich mir nicht vorstellen, warum man das haben möchte,
funktionieren tut es aber. Der schnellere gewinnt.

(3)
Softwareverteilung. Ich habe mal eine Enterprise-Software zur
Softwareverteilung gegeben, die ohne Eingriff in den vorhandenen
DHCP-Server funktioniert hat: Der Softwareverteilungsserver hat sich,
wenn ein Client aus dem Netz booten wollte, und dieser Client als
"soll installiert werden" in der Softwareverteilung stand, schnell für
die MAC-Adresse des Clients beim "richtigen" DHCP-Server eine
IP-Adresse geholt und diese dann selbst dem Client zusammen mit den
Informationen für den PXE-Boot angeboten. Der Client weiß ja auch,
dass er aus dem Netz booten möchte, hat die Antwort vom "echten"
DHCP-Server, die keine Informationen fürs Booten enthält, ignoriert
und dann mit den von der Softwareverteilung angebotenen Daten aus dem
Netz gebootet. Abwegig, funktioniert aber auch.

Grüße
Marc

[Marc Haber]

Post by Christian Knoke
Ich vermute, dein Problem rührt daher, dass sich zwei DHCP-Server im selben
Netzsegment in die Quere kommen.

Das tun sie nicht notwendigerweise. Der der schneller antwortet oder
den vom Client erwarteten Optionsumfang liefert, gewinnt. Usecases:

(1)
zwei DHCP-Server, die voneinander wissen und ihre Leases-Datenbanken
miteinander abgleichen: Redundanz. Abhängig von der eingesetzten
Software bekommt ein Client nur eine Antwort und der andere Server
schweigt oder er der Client bekommt zweimal dieselbe Adresse
angeboten. Es gibt vermutlich auch Szenarios, wo der Client zwei
unterschiedliche Adressen angeboten bekommt und sich eine aussuchen
kann, auch das funktioniert wenn sich die Server sicher sein können
dass die Adressen die sie gerade anbieten auch wirklich frei sind.

(2)
zwei DHCP-Server, die IP-Adressen aus zwei nicht überlappenden Pools
verteilen: Kann ich mir nicht vorstellen, warum man das haben möchte,
funktionieren tut es aber. Der schnellere gewinnt.

(3)
Softwareverteilung. Ich habe mal eine Enterprise-Software zur
Softwareverteilung gegeben, die ohne Eingriff in den vorhandenen
DHCP-Server funktioniert hat: Der Softwareverteilungsserver hat sich,
wenn ein Client aus dem Netz booten wollte, und dieser Client als
"soll installiert werden" in der Softwareverteilung stand, schnell für
die MAC-Adresse des Clients beim "richtigen" DHCP-Server eine
IP-Adresse geholt und diese dann selbst dem Client zusammen mit den
Informationen für den PXE-Boot angeboten. Der Client weiß ja auch,
dass er aus dem Netz booten möchte, hat die Antwort vom "echten"
DHCP-Server, die keine Informationen fürs Booten enthält, ignoriert
und dann mit den von der Softwareverteilung angebotenen Daten aus dem
Netz gebootet. Abwegig, funktioniert aber auch.

Grüße
Marc

[Marc Haber]

Post by Christian Knoke
Ich vermute, dein Problem rührt daher, dass sich zwei DHCP-Server im selben
Netzsegment in die Quere kommen.

Das tun sie nicht notwendigerweise. Der der schneller antwortet oder
den vom Client erwarteten Optionsumfang liefert, gewinnt. Usecases:

(1)
zwei DHCP-Server, die voneinander wissen und ihre Leases-Datenbanken
miteinander abgleichen: Redundanz. Abhängig von der eingesetzten
Software bekommt ein Client nur eine Antwort und der andere Server
schweigt oder er der Client bekommt zweimal dieselbe Adresse
angeboten. Es gibt vermutlich auch Szenarios, wo der Client zwei
unterschiedliche Adressen angeboten bekommt und sich eine aussuchen
kann, auch das funktioniert wenn sich die Server sicher sein können
dass die Adressen die sie gerade anbieten auch wirklich frei sind.

(2)
zwei DHCP-Server, die IP-Adressen aus zwei nicht überlappenden Pools
verteilen: Kann ich mir nicht vorstellen, warum man das haben möchte,
funktionieren tut es aber. Der schnellere gewinnt.

(3)
Softwareverteilung. Ich habe mal eine Enterprise-Software zur
Softwareverteilung gegeben, die ohne Eingriff in den vorhandenen
DHCP-Server funktioniert hat: Der Softwareverteilungsserver hat sich,
wenn ein Client aus dem Netz booten wollte, und dieser Client als
"soll installiert werden" in der Softwareverteilung stand, schnell für
die MAC-Adresse des Clients beim "richtigen" DHCP-Server eine
IP-Adresse geholt und diese dann selbst dem Client zusammen mit den
Informationen für den PXE-Boot angeboten. Der Client weiß ja auch,
dass er aus dem Netz booten möchte, hat die Antwort vom "echten"
DHCP-Server, die keine Informationen fürs Booten enthält, ignoriert
und dann mit den von der Softwareverteilung angebotenen Daten aus dem
Netz gebootet. Abwegig, funktioniert aber auch.

Grüße
Marc

[Henning Follmann]

Hallo Marc,
ist Dein E-Mail Setup kaputt?
Ich habe die Nachricht 4 mal bekommen (immer mit einer
neuen Id).

-H