PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : dhcp-server soll mehrer ip-adress-bereiche bedienen



Seiten : [1] 2

lziegler
14.04.07, 17:54
Hi,

ich hab mal wieder ein dringendes Problem.
Ich möchte einen Server mit einer netzwerkkarte im bereich 192.168.101.x dazu benutzen gleichzeichtig auch adressen an rechner in den Bereichen 192.168.102.x und 192.168.103.x zu vergeben.
Dazu hab ich zwei virtuelle Netzwerkkarten eingerichtet, und den dhcp so eingestellt, dass er adressen an beide adressbereiche vergibt. zusätzlich hab ich auf dem Server den dhcprelay agent aktiviert, der auf das Interface 192.168.101.1 hört. In der Config hab ich abgegeben, dass die dhcp-server die 192.168.102.1 und 192.168.103.1 (ip der virtuellen NICs) sind.
Zuerst hatte ich gedacht, dass das ganze funktioniert. nun musste ich aber feststellen, dass das immer nur auf einem Adressbereich richtig gemacht wird, beim anderen funktioniert die Adressvergabe nicht.

Weiß jemand wo der Fehler liegt?

meine dhcp.conf

# dhcpd.conf
option ntp-servers 192.168.101.253;
default-lease-time 600;
max-lease-time 7200;
allow booting;
allow bootp;
ddns-update-style none; ddns-updates off;
authoritative;

shared-network TEST {

subnet 192.168.102.0 netmask 255.255.255.0 {
range 192.168.102.1 192.168.102.99;
option domain-name-servers 192.168.101.254, 192.168.101.253;
option routers 192.168.102.230;
}

subnet 192.168.103.0 netmask 255.255.255.0 {
range 192.168.103.1 192.168.103.99;
option domain-name-servers 192.168.101.254, 192.168.101.253;
option routers 192.168.103.230;
}

}


meine /etc/sysconfig/dhcrelay

## Path: Network/DHCP/DHCP Relay agent
## Description: Configuration file for DHCP relay agent
## Type: string
## Default: ""
## ServiceRestart: dhcrelay
#
# Interface(s) for DHCP relay agent to listen on
#
# Instead of the interface name, the name of its configuration can be given.
# If the configuration file is named
# /etc/sysconfig/network/ifcfg-eth-id-00:50:fc:e4:f2:65
# then id-00:50:fc:e4:f2:65 would be suitable to identify the configuration.
#
# Examples: DHCPD_INTERFACE="eth0"
# DHCPD_INTERFACE="eth0 eth1 eth2 tr0 wlan0"
# DHCPD_INTERFACE="internal0 internal1"
# DHCPD_INTERFACE="id-00:50:fc:e4:f2:65 id-00:a0:24:cb:cc:5c wlan0"
#
DHCRELAY_INTERFACES="bond0"

## Type: string
## Default: ""
## ServiceRestart: dhcrelay
#
# DHCP servers to be used by DHCP relay agent
# (separated by spaces, e.g. "192.168.0.11 191.168.0.12")
#
DHCRELAY_SERVERS="192.168.103.1 192.168.102.1"

## Type: string
## Default: ""
## ServiceRestart: dhcrelay
#
# Additional options
# Example: "-c 8"
#
DHCRELAY_OPTIONS=""

bla!zilla
15.04.07, 09:59
Das DHCP Relay steht an der falschen Stelle. Jeweils ein Relay muss in die Netze 192.168.102.0 und 192.168.103.0.

lziegler
15.04.07, 10:54
Kannst du noch mal ganz kurz erläutern was du damit meinst, dass sie an der falschen stelle stehen?

bla!zilla
15.04.07, 11:05
Hab ich dir doch erst letzte Woche erklärt (http://www.linuxforen.de/forums/showpost.php?p=1523166&postcount=9).

lziegler
15.04.07, 11:20
Ich hab pro subnetz ein dhcrelay. Bei mir übernehmen switches die Aufgabe, die daten weiterzuleiten.
Also mein clients soll im subnetz 192.168.102.0 und 192.168.103.0 sein. Mein server hat eine reelle NIC 192.168.101.1. weiterhin zwei virtuelle 192.168.102.1 ud 192.168.103.1. mein switch schickt nun die dhcp-anfragen an der server 192.168.101.1, der diese dann per dhcrelay an 192.168.102.1 und 192.168.103.1 weiterschicken soll.
Aber hab den Eindruck, dass die Anfragen zwar weitergeleitet werden, der Server aber nicht weiß, ob die Anfrage aus dem netz 192.168.102.0 oder 192.168.103.0 kam, und entsprechend an die falsche virtuelle NIC weiterleitet.

bla!zilla
15.04.07, 22:39
Ich hab pro subnetz ein dhcrelay. Bei mir übernehmen switches die Aufgabe, die daten weiterzuleiten.
Also mein clients soll im subnetz 192.168.102.0 und 192.168.103.0 sein. Mein server hat eine reelle NIC 192.168.101.1. weiterhin zwei virtuelle 192.168.102.1 ud 192.168.103.1. mein switch schickt nun die dhcp-anfragen an der server 192.168.101.1, der diese dann per dhcrelay an 192.168.102.1 und 192.168.103.1 weiterschicken soll.

Das DHCP Relay hat auf dem DHCP nichts zu suchen. Ein DHCP Relay nimmt die DHCP Anfragen der Clients (Broadcasts) an und leitet sie per Unicast an einen DHCP weiter.



Aber hab den Eindruck, dass die Anfragen zwar weitergeleitet werden, der Server aber nicht weiß, ob die Anfrage aus dem netz 192.168.102.0 oder 192.168.103.0 kam, und entsprechend an die falsche virtuelle NIC weiterleitet.

Pack mal den Packetsniffer aus und schau mal nach was da genau passiert. Möglicherweise ein Konfigurationsfehler, evtl. bauen die Switches Mist.

lziegler
17.04.07, 12:09
Ich brauch aber den dhcrelay auf dem DHCP-Server. da dieser ja mehrere Subnetze besitzt. Ohne diese kann er doch die dhcp-Anfragen nicht ncht vom 101-Netz aufs 102- und 103-Netz schicken.

Das mit dem Sniffer werd ich bei gelegenheit mal ausprobieren. Also ich erhalte immer wieder eine Meldung
"packet to bogus giadrr" gefolgt von der IP des jeweiligen Switch-Ports. Also der Switch schickt meiner Meinung nach die Infos übers Subnetz mit. Der Server scheint dann aber bei der Weiterleitung misst zu bauen.

bla!zilla
17.04.07, 19:46
Ich brauch aber den dhcrelay auf dem DHCP-Server. da dieser ja mehrere Subnetze besitzt. Ohne diese kann er doch die dhcp-Anfragen nicht ncht vom 101-Netz aufs 102- und 103-Netz schicken.

Du hast immer noch nicht verstanden wie und was ein DHCP Relay ist...

Noch mal: Ein DHCP Relay nimmt in einem Subnet die Broadcast-Anfragen entgegen und schickt diese per Unicast an einen DHCP Server. Dein Server kommt doch in die Netze, aber die Clients erreichen deinen Server nicht! Die DHCP Anfragen sind doch Broadcasts und die werden bekanntlich an Broadcastgrenzen nun mal gedroppt!

In einem DHCP Pakete eines Clients steht als Absenderadresse die MAC-Adresse des Clients. Der Server antwortet doch mit einem Unicast, nicht mit einem Broadcast. Also welchen Sinn soll das Relay auf deinem Server machen?



Das mit dem Sniffer werd ich bei gelegenheit mal ausprobieren. Also ich erhalte immer wieder eine Meldung
"packet to bogus giadrr" gefolgt von der IP des jeweiligen Switch-Ports. Also der Switch schickt meiner Meinung nach die Infos übers Subnetz mit. Der Server scheint dann aber bei der Weiterleitung misst zu bauen.

Ist ja auch korrekt. giadrr ist die Adresse des Relay-Agents. Schau dir mal ein DHCP Paket an, dir wird ein vier Byte großes Feld dafür auffallen. Im Prinzip hast du da zwei Relays laufen. Also schalt endlich das Relay auf dem Server ab.

Kann doch alles nicht so schwer sein....

lziegler
17.04.07, 20:58
Du hast immer noch nicht verstanden wie und was ein DHCP Relay ist...

Noch mal: Ein DHCP Relay nimmt in einem Subnet die Broadcast-Anfragen entgegen und schickt diese per Unicast an einen DHCP Server. Dein Server kommt doch in die Netze, aber die Clients erreichen deinen Server nicht! Die DHCP Anfragen sind doch Broadcasts und die werden bekanntlich an Broadcastgrenzen nun mal gedroppt!


Doch ich habe verstanden was ein dhcrelay ist.
Da mein Server real im Subnetz 192.168.101.0 ist, seine virtuellen Netzwerkkarten die die DHCP anfragen beantworten sollen jedoch in den Subnetzen 192.168.102.0 und 192.168.103.0 sind, muss ich also um die Subnetzgrenzen zu überwinden einen DHCRelay auf meinem Server einsetzen, der die Infos vom Subnetz 192.168.101 zu 192.168.102 und 192.168.103 weiterleitet.

Dennoch werde ich deinen Vorschlag, den dhcrelay auf dem DHCP Server 7 abzuschalten, mal testen, auch wenn ich der Meinung bin, das schon mal ausprobiert zu haben.

bla!zilla
17.04.07, 21:14
Doch ich habe verstanden was ein dhcrelay ist.
Da mein Server real im Subnetz 192.168.101.0 ist, seine virtuellen Netzwerkkarten die die DHCP anfragen beantworten sollen jedoch in den Subnetzen 192.168.102.0 und 192.168.103.0 sind, muss ich also um die Subnetzgrenzen zu überwinden einen DHCRelay auf meinem Server einsetzen, der die Infos vom Subnetz 192.168.101 zu 192.168.102 und 192.168.103 weiterleitet.

Und dieser Gedanke ist eben falsch. :rolleyes: Du brauchst die Interfaces nur, damit der DHCP für die jeweiligen IP-Pools der Subnetze ein passendes Interface im Netz hat. Aber mach du mal. Die ganze Zeit erkläre ich es dir und dich scheint das nicht zu interessieren. Wenn du dir nicht helfen lassen willst, dann ist das okay, aber dann sag es einfach.

lziegler
17.04.07, 21:36
oooooooohhh, entschuldige dass ich nochmals nachgefragt habe. Ich will ja nichts sagen, aber dein Hinweis, dass ein PC intern über ein Subnetz hinweg ein Broadcast auch ohne dhcrelay weiterleitet, kam gerade zum ersten mal.
Ansonsten haben mich deine Ausführungen dennoch interessiert.

bla!zilla
17.04.07, 21:40
Ich will ja nichts sagen, aber dein Hinweis, dass ein PC intern über ein Subnetz hinweg ein Broadcast auch ohne dhcrelay weiterleitet, kam gerade zum ersten mal.

Wenn du dich mit DHCP beschäftigt hättest, wäre dir das sofort aufgefallen und bewusst geworden.

lziegler
18.04.07, 21:21
Ich hab mich sehr wohl mit DHCP beschäftigt, wie hätte ich wohl sonst einen Server aufsetzen können. Nur hatte ich dieses Problem mit den Subnetz-übergreifenden DHCP-Servern nicht. da ich bislang den zentralen Server mit 6 NICs direkt in alle Subnetze verbunden hatte.
Mal ganz davon abgesehen verstehe ich dich nicht, schließlich ist ein Forum dazu da, Fragen zu stellen.

bla!zilla
19.04.07, 15:13
Ich hab mich sehr wohl mit DHCP beschäftigt, wie hätte ich wohl sonst einen Server aufsetzen können.

Du hast dich mit DHPCd beschäftigt, weniger mit dem Protokoll.



Mal ganz davon abgesehen verstehe ich dich nicht, schließlich ist ein Forum dazu da, Fragen zu stellen.

Klar ist es dazu da um Fragen zu stellen, aber man muss sich auch helfen lassen und sollte nicht, wie du, immer die gleichen Fragen stellen, Probleme posten und die Tips ignorieren.

lziegler
19.04.07, 20:49
Klar ist es dazu da um Fragen zu stellen, aber man muss sich auch helfen lassen und sollte nicht, wie du, immer die gleichen Fragen stellen, Probleme posten und die Tips ignorieren.

Also ich bin nicht der Meinung, dass ich deine Tipps ignoriert habe. Aber wie dem auch sei, das hat ja sowieso keinen Sinn jetzt irgendeine schwachsinnige Diskussion vom Zaun zu brechen. Ich werde dann bescheid geben, ob dein Tipp den DHCRelay am Server abzuschalten etwas genutzt hat.

bla!zilla
19.04.07, 21:12
Sorry, ich habe dir drei Mal gesagt, dass das DHCP Relay an der falschen Stelle steht. Es läuft immer noch auf dem Server, wo es nicht hingehört. Allein die von dir genannte Fehlermeldung (packet to bogus giaddr) deutet ein Problem mit dem Relay hin. Normalerweise steht im Feld für giaddr 0.0.0.0 und wird beim Empfang des Paketes durch die IP von dem Interface ersetzt, auf dem das Paket empfangen wurde. Durch eine logische UND Verknüpfung mit der Subnetmask findet der DHCP Server heraus welche Netzmaske das Netz hat und aus welchem Pool er eine IP nehmen soll. Steht in dem giaddr Feld eine IP, dann ist das die IP des Relay Agents. Und auch hier versucht der DHCP wieder über eine logische UND Verknüpfung die IP herauszufinden und schickt diese per Unicast zurück. Du schreibst natürlich nicht welche IP da in dem Feld steht, aber du hast das Relay auf dem Server ja auch noch nicht abgeschaltet. Durchaus möglich das der Relay Agent auf dem Server die Pakete entgegennimmt und sich dann wundert was da für komische IPs im giaddr Feld stehen. Einfach mal in das RFC von DHCP reingucken, oder den Quellcode vom DHCPd. Da findet man ganz interessante Informationen....

lziegler
21.04.07, 13:49
Also der Relay ist abgeschaltet, dhcp funktioniert trotzdem nicht richtig. Wenn ich in meiner dhcp.conf eine feste Zuordnung zwischen IP und MAC vornehme, dann werden die Adressen richtig vergeben. Geh ich jedoch mit anderen Rechner ans Netzwerk, dessen MAC nicht in der dhcp.conf steht, dann funktioniert die Vergabe nicht korrekt. Aus den Log-Files kann ich zwar rauslesen, dass eine Anfrage weitergeleitet wird, und aus welchem Netz sie stammt, aber bedauerlicherweise vergibt der DHCP beispielsweise die Adresse 192.168.102.200 an einen Rechner aus dem Netz 192.168.101.0.

bla!zilla
22.04.07, 10:16
Welche IP hat das Relay was die Daten liefert?

lziegler
22.04.07, 16:45
Also für alle Rechner aus dem Netz 192.168.101.0 hat das Relay die Adresse 192.168.101.230, für die aus dem 102er Netz die Adresse 192.168.102.230. Es handelt sich dabei wie gesagt um die IPs meines Switchs im jeweiligen Netz.
Im übrigen steht in der LOG-File auch drin, dass der DHCPOFFER über die 101.230 bzw. 102.230 geschickt wird. Je nachdem aus welchem Netz der DISCOVER kam.

bla!zilla
22.04.07, 18:02
Bin ich blind, oder fehlt in deiner dhcp.conf ein Subnetz-Eintrag für 192.168.101.0? Poste bitte noch mal deine vollständige dhcp.conf. In der Konfigurationsdatei muss es drei Subnetz-Einträge geben, für die Netze 192.168.101.0/24, 192.168.102.0/24 und 192.168.103.0/24. Auf dem Server darf selber kein DHCP-Relay laufen.

lziegler
22.04.07, 18:25
Sorry da hab ich mich verzettelt. Meine Subnetze sind 101.0 (da ist der Server drin), 102.0 (1. Raum) 103.0 (2. Raum).
Also Adressen sollen nur in 102.0 und 103.0 vergeben werden, nicht aber für das Subnetz wo mein server drin hängt.
Die DHCRelays haben also die Adressen 102.230 und 103.230.
Passt also, dass keine Subnetzdeklaration für 101.0 in der dhcp.conf existiert.
Auf dem Server läuft kein DHCRelay.

bla!zilla
22.04.07, 18:42
Warum kommen dann DHCP Request aus dem Netz 192.168.101.0?



Aus den Log-Files kann ich zwar rauslesen, dass eine Anfrage weitergeleitet wird, und aus welchem Netz sie stammt, aber bedauerlicherweise vergibt der DHCP beispielsweise die Adresse 192.168.102.200 an einen Rechner aus dem Netz 192.168.101.0.Schau dir bitte mal die DHCP Pakete an, besonders die Pakete für DHCPOFFER und DHCPREQUEST. Der DHCP Server sollte aufgrund der giaddr im DHCP Paket herausfinden für welches Subnetz er eine IP vergibt, daher auch meine Frage nach den IPs der DHCP Relays.

lziegler
23.04.07, 08:10
Warum kommen dann DHCP Request aus dem Netz 192.168.101.0?

Das ist natürlich auch Quatsch. müsste natürlich 102.0 und 103.0 sein. Ich kann jetzt im Moment nicht an der Server ran, aber sobald das geht, schick ich mal den Log-File-Eintrag und und schau mir mal die DHCP-Pakete an.
Also entweder mein DHCP-Server liest die giaddr nicht aus oder mein Switch schreibt falsche Werte in die giaddr rein, was ich mir allerdings nicht vorstellen kann.

bla!zilla
23.04.07, 09:04
Also noch mal zusammengefasst.. :rolleyes:

Ein Server, drei Subnetze (192.168.101.0/24, 192.168.102.0/24 und 192.168.103.0/24). Der Server steht im Netz 192.168.101.0/24 und soll für die anderen beiden Netze DHCP Leases verteilen. Die 192.168.102.230/25 und die 192.168.103.230/24 sind die DHCP Relays. Statt die Adressen korrekt zu verteilen, verteilt der DHCP Server Leases aus dem Range 192.168.102.0/24 an Rechner im Netz 192.168.103.0/24 und umgekehrt.

Korrekt?

lziegler
24.04.07, 11:56
du hast den Nagel auf den Kopf getroffen.

bla!zilla
24.04.07, 11:59
Dann schau dir noch mal die DHCP Pakete an, vor allem das giaddr Feld.

lziegler
24.04.07, 12:01
mach ich. Ich hoffe das ich das heute Abend noch schaffe, dann geb ich wieder bescheid.

lziegler
28.04.07, 14:35
Also ich bin jetzt endlich mal dazu gekommen die DHCP-Pakete zu sniffen. Dabei kam für das DHCP-Discover folgendes raus:


No. Time Source Destination Protocol Info
1 0.000000 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0xf5375cd6

Frame 1 (590 bytes on wire, 590 bytes captured)
Ethernet II, Src: AsustekC_37:5c:d6 (00:11:11:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 576
Identification: 0x0002 (2)
Flags: 0x00
Fragment offset: 0
Time to live: 20
Protocol: UDP (0x11)
Header checksum: 0xa4ac [correct]
[Good: True]
[Bad : False]
Source: 0.0.0.0 (0.0.0.0)
Destination: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Source port: bootpc (68)
Destination port: bootps (67)
Length: 556
Checksum: 0x2f0f [correct]
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0xf5375cd6
Seconds elapsed: 10
Bootp flags: 0x8000 (Broadcast)
1... .... .... .... = Broadcast flag: Broadcast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: AsustekC_37:5c:d6 (00:11:11:11:11:11)
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option: (t=53,l=1) DHCP Message Type = DHCP Discover
Option: (53) DHCP Message Type
Length: 1
Value: 01
Option: (t=55,l=24) Parameter Request List
Option: (55) Parameter Request List
Length: 24
Value: 01020305060B0C0D0F1011122B363C438081828384858687
1 = Subnet Mask
2 = Time Offset
3 = Router
5 = Name Server
6 = Domain Name Server
11 = Resource Location Server
12 = Host Name
13 = Boot File Size
15 = Domain Name
16 = Swap Server
17 = Root Path
18 = Extensions Path
43 = Vendor-Specific Information
54 = Server Identifier
60 = Vendor class identifier
67 = Bootfile name
128 = Private
129 = Private
130 = Private
131 = Private
132 = Private
133 = Private
134 = Private
135 = Private
Option: (t=57,l=2) Maximum DHCP Message Size = 1260
Option: (57) Maximum DHCP Message Size
Length: 2
Value: 04EC
Option: (t=97,l=17) UUID/GUID-based Client Identifier
Option: (97) UUID/GUID-based Client Identifier
Length: 17
Value: 0000501D51548A0D109E1AA62C3F8C7289
Client Identifier (UUID): 511d5000-8a54-100d-9e1a-a62c3f8c7289
Option: (t=93,l=2) Client System Architecture = IA x86 PC
Option: (93) Client System Architecture
Length: 2
Value: 0000
Option: (t=94,l=3) Client Network Device Interface
Option: (94) Client Network Device Interface
Length: 3
Value: 010201
Client Network ID Major Version: 2
Client Network ID Minor Version: 1
Option: (t=60,l=32) Vendor class identifier = "PXEClient:Arch:00000:UNDI:002001"
Option: (60) Vendor class identifier
Length: 32
Value: 505845436C69656E743A417263683A30303030303A554E44.. .
End Option
Padding


und beim DHCP-Offer hat sich folgendes ergeben:


No. Time Source Destination Protocol Info
2 0.348283 192.168.103.230 255.255.255.255 DHCP DHCP Offer - Transaction ID 0xf5375cd6

Frame 2 (342 bytes on wire, 342 bytes captured)
Ethernet II, Src: D-Link_da:c2:c3 (00:22:22:22:22:22), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 192.168.103.230 (192.168.103.230), Dst: 255.255.255.255 (255.255.255.255)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 328
Identification: 0xee98 (61080)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 63
Protocol: UDP (0x11)
Header checksum: 0x227e [correct]
[Good: True]
[Bad : False]
Source: 192.168.103.230 (192.168.103.230)
Destination: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Source port: bootps (67)
Destination port: bootpc (68)
Length: 308
Checksum: 0xa990 [correct]
Bootstrap Protocol
Message type: Boot Reply (2)
Hardware type: Ethernet
Hardware address length: 6
Hops: 2
Transaction ID: 0xf5375cd6
Seconds elapsed: 10
Bootp flags: 0x8000 (Broadcast)
1... .... .... .... = Broadcast flag: Broadcast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 192.168.102.99 (192.168.102.99)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 192.168.103.230 (192.168.103.230)
Client MAC address: AsustekC_37:5c:d6 (00:11:11:11:11:11)
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option: (t=53,l=1) DHCP Message Type = DHCP Offer
Option: (53) DHCP Message Type
Length: 1
Value: 02
Option: (t=54,l=4) Server Identifier = 192.168.101.1
Option: (54) Server Identifier
Length: 4
Value: C0A865FE
Option: (t=51,l=4) IP Address Lease Time = 10 minutes
Option: (51) IP Address Lease Time
Length: 4
Value: 00000258
Option: (t=1,l=4) Subnet Mask = 255.255.255.0
Option: (1) Subnet Mask
Length: 4
Value: FFFFFF00
Option: (t=3,l=4) Router = 192.168.103.230
Option: (3) Router
Length: 4
Value: C0A869E6
Option: (t=6,l=8) Domain Name Server
Option: (6) Domain Name Server
Length: 8
Value: C0A865FEC0A865FD
IP Address: 192.168.101.1
IP Address: 192.168.101.2
Option: (t=15,l=20) Domain Name = ""
Option: (15) Domain Name
Length: 20
Value: 6E6261752E666C73682E6564752E696E7465726E
End Option


Die Anfrage wurde aus dem 103.0 Netz gestellt und mit einer 102.0 IP quittiert.

bla!zilla
28.04.07, 18:30
Die DISCOVER ist aus dem Netz des Clients gesnifft, richtig? Mich hätte die DISCOVER interessiert, die am Server angekommen ist.

lziegler
29.04.07, 19:19
ja korrekt. Die hab ich auch noch gesnifft. Da Stand aber das selbe drin, außer dass die Relay agent IP address: 192.168.103.230
lautete.