Folgende Situation:
Großes LAN mit DHCP Server. Jetzt soll eine Aussenstelle eingerichtet werden. Verbindung über Routerstrecke.
Frage:
Wie sieht das mit DHCP aus? Die Router machen doch ein neues IP-Netzwerk auf (auch beim Subnetting) - muss ich dann in der Aussenstelle auch einen neuen DHCP-Server aufmachen, oder gibt es eine Möglichkeit, auch die Adressen der Aussenstelle weiterhin zentral zu verwalten?
Gruß
Stefan
- muss ich dann in
der Aussenstelle auch einen neuen
DHCP-Server aufmachen
das ist die eine Möglichkeit, würde ich bevorzugen wenn es geht.
oder gibt es eine
Möglichkeit, auch die Adressen der
Aussenstelle weiterhin zentral zu
verwalten?
bei NT kannst Du DHCP mit WINS verheiraten, denn können die DHCP-Clients auch mit dem zentralen DHCP-Server kommunizieren.
Gruß
Johannes
bei NT kannst Du DHCP mit WINS
verheiraten, denn können die DHCP-Clients
auch mit dem zentralen DHCP-Server
kommunizieren.
… ööhm - DHCP und WINS zusammen unter NT geht schon, nur in diesem Fall macht das nicht unbedingt Sinn, bzw hilft nicht weiter. Der Vorschlag mit einem ‚neuen‘ DHCP-Server in der Aussenstelle ist gut; er ist eigentlich nur dann nötig, wenn eine recht langsame WAN-Verbindung besteht oder der/die Router dazwischen die DHCP-Broadcasts nicht weiterleiten. Wenn sie diese Broadcasts nicht weiterleiten und trotzdem nur der eine DCP-Server verwendet werden soll, dann kann man noch einen DHCP-Relay-Agent einsetzen …
die DHCP-Broadcasts nicht weiterleiten.
Wenn sie diese Broadcasts nicht
weiterleiten und trotzdem nur der eine
DCP-Server verwendet werden soll, dann
kann man noch einen DHCP-Relay-Agent
einsetzen …
Von dem Relay-Agent habe ich auch schon gehört. Unsere Cisco’s unterstützen das sogar. Nur: Wie erkennt der DHCP-Server, aus welchem Subnet die Anfrage kam - damit er eine passende IP-Konfig schicken kann? …und kann das jeder DHCP-Server? (Wir setzen den von NW 4.11 ein).
Gruß
Stefan
Hallo,
das klappt schon.
Der Router mit der DHCP-Relay-Funktion trägt seine IP-Adresse in das Feld „Gateway Ip
Address“ ein. Und er macht aus dem Broadcast des Clients ein gerichtetes Paket an den DHCP-Server indem er ganz einfach desssen Ziel-Adresse eingibt.
Der DHCP-Server erkennt den Client an der MAC-Adresse, die der Client in den Teil „Client Hardware Address“ schreibt. Wohlgemerkt, es wird nicht nach der MAC-Adresse des Ethernet-Headers ausgewertet! Der Server antwortet an die IP-Adresse, die der Router als Gateway eingetragen hat. Der Router leitet dann an den Client weiter.
Anbei habe ich das Paketformat von BOOTP gehaengt. Das war der Vorlaeufer von DHCP. Viel hat sich an dem Paketaufbau nicht geaendert. DHCP hat ein paar Funktionen mehr und ist in einem spaeteren RFC beschrieben.
Leider schneidet der „wer-weiss-was“-Server die Leerzeichen heraus. Sorry, wenn das Paketformat ein wenig unuebersichtlich ist.
Das DHCP-Protocol ist im RFC 2131 beschrieben.
Gruesse
Stefan
±-----------±----------±-----------±------------------±-------------+
| MAC Header | IP Header | UDP Header | bootp header/data | MAC Trailer |
±-----------±----------±-----------±------------------±-------------+
| |
±--------------+ |
| |
0 31
±-------±-------±-------±-------+
| OP | HTYPE | HLEN | HOPS |
±-------±-------±-------±-------+
| TRANSACTION ID |
±----------------±----------------+
| SECONDS | UNUSED |
±----------------±----------------+
| CLIENT IP ADDRESS |
±----------------------------------+
| YOUR IP ADDRESS |
±----------------------------------+
| SERVER IP ADDRESS |
±----------------------------------+
| GATEWAY IP ADDRESS |
±----------------------------------+
| CLIENT HARDWARE ADDRESS |
| (16 bytes) |
±----------------------------------+
| SERVER HOST NAME |
| (64 bytes) |
±----------------------------------+
| BOOT FILE NAME |
| (128 bytes) |
±----------------------------------+
| VENDOR SPECIFIC AREA |
| (64 bytes) |
±----------------------------------+
OP: 1 = Request
2 = Reply
HTYPE: Network Hardware Type
±-----±---------------------------------------+
| TYPE | Description |
±-----±---------------------------------------+
| 0001 | Ethernet (10Mb) |
| 0002 | Experimental Ethernet (3Mb) |
| 0003 | Amateur Radio AX.25 |
| 0004 | Proteon ProNET Token Ring |
| 0005 | Chaos |
| 0006 | IEEE 802.X |
| 0007 | ARCNET |
| 0008 | Hyperchannel |
| 0009 | Lanstar |
| 0010 | Autonet Short Address |
| 0011 | LocalTalk |
| 0012 | LocalNet (IBM PCNet or SYTEK LocalNET) |
±-----±---------------------------------------+
HOPS: Initially set to 0 by the bootp client. If the bootp server
passes the request to another bootp server on a different IP
network, the HOPS field is incremented.
HLEN: Network Hardware Address Length
TRANS ID: Used by diskless machines to match responses with
requests. Similar to a sequence number.
SECONDS: The number of seconds sincs the client started to boot.
In the following fields, the client fills in as much information as possible
and fills the others with zeros. The bootp server that replies will fill in
the blanks.
CLIENT IP ADDRESS: The bootp client’s IP address. If the client does not
know it’s IP address, the bootp server that replies
will place the client’s IP address in the YOUR IP
ADDRESS field below. This is similar to RARP, except
that bootp uses UDP and can therefore work across
gateways.
YOUR IP ADDRESS: See Client IP Adress field above.
SERVER IP ADDRESS: If set to zero, any bootp server that receives the
request will reply. If set to non-zero, only the
server specified will reply to the request.
GATEWAY IP ADDRESS: This field is returned by the server to tell the
client the address of it’s default gateway.
CLIENT HW ADDRESS: The bootp client’s hardware address.
SERVER HOST NAME: Allows the use of a Host Name instead of an IP Address
to access the bootp server.
BOOT FILE NAME: The name of the image file that the client wants to
download from the server. This is usually the
operational program for the diskless device. If the
Boot File Name is left blank, the server returns the
name of the boot file.
VENDOR SPECIFIC AREA: Optional. Standard format shown below.
(4) (1) (1) (variable)
±-------±------±------±------±------±------±---------------+
| Magic Cookie | Type | LEN | Value |
±-------±------±------±------±------±------±---------------+
Magic Cookie: 4 bytes defining the format of the remaining items in
the Vendor Specific Area.
±----±----±----------------------------------------------------+
| Type| Len | Description: Contents of Value field |
±----±----±----------------------------------------------------+
| 0 | - | Padding: Zero, used only for padding |
| 1 | 4 | Subnet Mask: Mask of local IP subnet |
| 2 | 4 | Time of Day: Time of day in universal time |
| 3 | N | Gateways: IP Addresses of N/4 gateways |
| 4 | N | Time Server: IP Addresses of N/4 time servers |
| 5 | N | IEN116 Server: IP Addresses of N/4 IEN116 servers |
| 6 | N | Domain Server: IP Addresses of N/4 Domain servers |
| 7 | N | Log Server: IP Addresses of N/4 Log servers |
| 8 | N | Quote Server: IP Addresses of N/4 Quote servers |
| 9 | N | LPR Server: IP Addresses of N/4 LPR servers |
| 10 | N | Impress: IP Addresses of N/4 Impress servers |
| 11 | N | RLP Server: IP Addresses of N/4 RLP servers |
| 12 | N | Hostname: N bytes of client host name |
| 13 | 2 | Boot Size: 2-byte size of boot file |
|128- | - | – reserved for site specific use – |
|254 | - | – reserved for site specific use – |
±----±----±----------------------------------------------------+
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]