DHCP Broadcast Frage

[Fox1]

Hallo zusammen,

Da ich bald eine Klausur schreibe, habe ich einige Fragen zu Thema DHCP.

Ich kenne das Prinzip wie´s abläuft, D-O-R-A.

Nun die Frage ist: Laufen alle Schritte auf Schicht 3 als Broadcast, bzw ist die Dest.IP bei allen Schritten 255.255.255.255?

Wie sieht es dann auf der Schicht 2 aus?

Wenn auf der IP Ebene ein Broadcast bzw Limited Broadcast gesendet wird ist die zugehörige MAC Adresse auch FF:FF:FF:FF:FF:FF?

Wenn dem so ist und die Source Mac nur im DHCP Paket drin steht dann muss jeder Rechner die Pakete bis zum DHCP Teil öffnen und dann nachsehen?!?

Bedanke mich schonmal im vorraus.

[Jack_Wolfklaue]

Das sagt Wiki dazu:

"Broadcasts gibt es auf verschiedenen Ebenen des OSI-Referenzmodells. Allen gemein ist, dass Broadcasts einer höheren Ebene auf die Ebene des verwendeten physischen Netzwerkes angepasst werden müssen. So muss z. B. ein IP-Broadcast in einem Ethernet-Netzwerk als Ethernet-Broadcast an die MAC-Adresse FF:FF:FF:FF:FF:FF versendet werden."

mfg Jack

[Fox1]

Danke für die Antwort.

Das hatte ich schon gelesen, aber war mir nicht ganz sicher.

Also ist ein IP Broadcast gleichzeitig auch immer ein MAC Broadcast!?

Was aber ist nun mit der DHCP Geschichte?

Sind nun alle Schritte an eine Broadcast adresse gerichtet?Wenn ja, ist die eindeutige Client Identifizierung nur anhand des DHCP Pakets möglich??

Für einen guten Link wäre ich auch sehr dankbar.

[Jack_Wolfklaue]

ich hab gleich Mittagspause, bin dann zuhause und werd meine Schulunterlagen zu rate ziehen. Werde mich dann nochmal melden =)

[Jack_Wolfklaue]

Also:

Als erstes wird ein Mac-Broadcast gemacht. Der wird halt mit der MAC-Adresse FF:FF:FF:FF:FF:FF abgeschickt.

Dann Antwort der DHCP-Server auf die Quellmac von dem angekommen Packet Er bietet so dem Client halt eine IP an. Alle anderern Verwerfen das ankommende Packet. Ich schätze das Sie bis TYP vom Frame kontrollieren werden ob das Packet für Sie ist. Vorher können Sie es ja auf keinen fall feststellen.

Der Antwort nun auf die ihm nun bekannte Addresse vom DHCP-Server und meldet sozusagen, "Ich brauch die wohl".

Der Server bestätigt das dann nochmal.

_ _ _ _ _ _ _ _ _ _ _ _

Von IP-Broadcast hab ich nun nicht in meiner Mappe gefunden. Da werde ich gleich mal in unsern Fachbüchern schauen. Das hat mein ergeiz geweckt.

[Fox1]

Vielen Dank für deine Antwort

So wie ich das jetzt überall gelesen hab, finden alle Schritte als Broadcast statt.

1. Client kennt nicht IP des Servers.(Discover)

2. Server offert dem client(der noch keine IP hat) IP Adressen per Broadcast.

3.Client kann sich IP aussuchen, aber damit eventuell alle anderen Server wissen müssen für welche sich der Client sich entschieden hat schickt er das Request auch per Broadcast.

4. Server bestätigt mit Ack, aber der der Client immer noch keine IP hat schickt er das paket auch per Broadcast.

Und wenn IP Broadcast ist, ist Mac auch immer Broadcast?!

Und damit der Client weiss, dass das Paket auch für ihn ist, muss er Schicht 2(Ethernet/MAC), Schicht3(IP), Schicht4 (UDP) bis Schicht 7(DHCP) "aufmachen" und nachsehen ob seine MAC im chaddr (Client Ethernet Address) drin steht ?! Hab ich das jetzt soweit richtig verstanden???

Informationen stammen vom folgenden Link Grundlagen zu DHCP (Dynamic Host Configuration Protocol)

Hab auch schon in einigen Fachbüchern geschaut aber ins Detail gehen die alle nicht :-( Und über das was auf der zweiten Schicht steht nirgends...

ICh wäre jetzt ja schon davon überzeugt das ich alles richtig verstanden habe, wenn nicht mein Lehrer letzte Stunde gesagt hätte das auf Schicht 2 nur die ersten Schritte 2 Schritte (Discover, offer) als Broadcast und der Rest würde über eine gezielte Mac addressierung laufen.Gleichzeitig sagte er aber auch das auf Schicht 3 alle Schritte über Broadcast laufen??????*wiederspruch??*

Deswegen bin ich jetzt ja irritiert...

[Jack_Wolfklaue]

Ich habe es so gelernt:

1.Discover

Der Client sendet einen MAC-Broadcast um den DHCP-Server zu finden.

In dem Frame den der Client versendet steht seine MAC-Addresse

2.Offer

Der Server nimmt die Anfrage an und erkennt am "TYP" im Frame das es sich um eine eine solche handelt. Der Server kann nun eine gezielte Antwort an den Client schicken, weil der Server nun ja die MAC-Addresse vom Client kennt. Der Server bietet dem Client nun an ihm eine IP-Addresse zu geben.

-------------------------------------------------------------------------

Hier haben beide die Addresse des andern. Es ist nicht mehr nötig ein BC zu senden

-------------------------------------------------------------------------

3.Request

Der Client fordert nun eine bestimmte IP-Addresse vom Server an.

4. Acknowledge

Der Server bestätigt die Anfrage

Bearbeitet 22. April 2010 von Jack_Wolfklaue

[Fox1]

Hast du mal den Link gesehen? Da steht aber was anderes drin. Das type Feld im Ethernet-Frame gibt doch eigentlich an um welches Protokoll es sich in der 3. Schicht handelt zb. IP oder ARP. Oder meinst du das Type Feld im DHCP Paket?

[Jack_Wolfklaue]

Ich hab geschrieben das ich es so gelernt habe. Der Link beschreibt das ja ganz anders. Da ist ja jeder Schritt vom DORA Prinzip mit einem BC verbunden.

Das wäre in meinen Augen jedoch auch irgendwie komisch Da die MAC-Addressen ja nach "Offer" beiden bekannt sind.

:confused:

[Fox1]

:upps habs ja auch so gelernt wie du das sagst.Aber anscheinend haben wir was falsches gelernt.

Aber es ist für mich logischer das alles per BC passiert, da ja sonst andere DHCP server nichts davon mitbekämen für welche IP von welchen Server sich der Client sich entschieden hätte. Ausserdem hat der der server nach dem Discover zwar die Mac vom Client, aber keine IP(da dieser noch keine hat).Also wie sollte er sonst auf Layer 3 adressieren, ausser BC? Und es ist ja dann auch unlogisch auf Layer 3 BC und auf layer 2 per Mac direkt zu addressieren.ODER?????:confused:

[Jack_Wolfklaue]

:

Und es ist ja dann auch unlogisch auf Layer 3 BC und auf layer 2 per Mac direkt zu addressieren.ODER?????

naja die Switches entscheiden ja anhand der MAC-Addresse... das würde ja das Netzwerk weniger belasten. Aber weitere DHCP-Server würden dann natürlich nichts vom dem ganzen mitbekommen. Aber könnten man das nicht geschickter lösen :confused:

[hades]

DHCP Discover, DHCP Offer, DHCP Request und DHCP Ack/Nak sind sowohl Ethernet- (FF:FF:FF:FF:FF:FF) als auch IP-Broadcasts (255.255.255.255).

Die eigentlichen DHCP Daten (welcher DHCP-Server, welcher Client, Lease /-time) stehen im Payload des IP-Paketes (Nutzdaten Schicht 5-7).

Damit ein DHCP Client und ein DHCP Server die IP-Pakete unterscheiden kann, werden Source Port und Destination Port genutzt.

Bei der Richtung DHCP Client -> DHCP Server wird der Source Port auf UDP 68 und der Destination Port auf UDP 67 gesetzt.

Bei der Richtung DHCP Server -> DHCP Client wird der Source Port auf UDP 67 und der Destination Port auf UDP 68 gesetzt.

Eine Ausnahme gibt es bei der Erneuerung der DHCP Lease: Dort gibt es bei T1 und T2 nur DHCP Request und DHCP Ack/Nak.

Der DHCP Request nach T1 (Haelfte der Leasetime) ist Unicast, gerichtet an den DHCP-Server der die Lease vergab (Renew).

Falls das nicht beantwortet wird gibt es T2:

Der DHCP Request nach T2 (7/8 der Leasetime) ist wiederum Broadcast, um andere DHCP-Server zu erreichen (Rebind).

Falls dieser wiederholte Wunsch der Leaseerneuerung auch nicht beantwortet wird, dann laeuft die Lease ab und der gesamte DHCP Prozess faengt von vorne an.

Bearbeitet 29. April 2010 von hades

[Fox1]

Ja genau so ist es.

Ich habe mir die Mühe gemacht und in der RFC nachgelesen, 2131.

Es gibt sowohl BC als auch unicast verfahren.Letztendlich entscheidet das Broadcast Flag ob nun als BC oder eben nicht kommuniziert wird.

Hier ein Auszug:

" If the 'giaddr'

field is zero and the 'ciaddr' field is nonzero, then the server

unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.

If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is

set, then the server broadcasts DHCPOFFER and DHCPACK messages to

0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and

'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK

messages to the client's hardware address and 'yiaddr' address."

Die Klausur ist bereits geschrieben und jetzt bin ich gespannt auf das Ergebnis:)

Trotzdem vielen Dank nochmal