DE69836673T2

DE69836673T2 - Verfahren und Vorrichtung zur Konfigurierung eines Netzknotens um sich selbst Netzübergang zu sein

Info

Publication number: DE69836673T2
Application number: DE69836673T
Authority: DE
Inventors: Sundararajan Roseville Subramaniam; Paul T. Granit Bay Congdon
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 1998-03-26
Filing date: 1998-10-15
Publication date: 2007-10-11
Anticipated expiration: 2018-10-16
Also published as: EP0946027A3; JP4519214B2; EP0946027A2; JP2000041069A; EP0946027B1; US6070187A; DE69836673D1

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf eine Kommunikation zwischen Netz- bzw. Netzwerkknoten. Insbesondere bezieht sich die vorliegende Erfindung auf ein Verfahren und eine Vorrichtung, die es ermöglichen, dass ein Netzknoten automatisch konfiguriert werden kann, um sein eigener Vorgabe-Gateway bzw. -netzübergang zu sein.
Beschreibung der verwandten Technik
Auf dem Gebiet eines Computernetzwerkbetriebs werden Protokollstapel häufig verwendet, um Daten zwischen Netzknoten zu übertragen, die durch Netzwerkmedien gekoppelt sind, wie z. B. ein Koaxialkabel oder eine verdrillte Verdrahtung. Netzknoten umfassen Vorrichtungen, wie z. B. Computerarbeitsplatzrechner, Server, Netzwerkdrucker, Netzwerkscanner und dergleichen. Um die Entwicklung und Implementierung von Protokollstapeln zu harmonisieren, hat die International Standards Organization (ISO = internationale Standard-Organisation) ein OSI-Referenzmodell (OSI = Open System Interconnection = Kommunikation offener Systeme) veröffentlicht, das sieben Schichten von Netzwerkprotokollen vorgegeben hat.
1 ist ein Blockdiagramm 10 des OSI-Referenzmodells. Das Modell umfasst eine Hardware-Schicht 12, eine Datenverbindungsschicht 14, eine Netzwerkschicht 16, eine Transportschicht 18, eine Sitzungsschicht 20, eine Präsentationsschicht 22 und eine Anwendungsschicht 24. Jede Schicht ist für die Durchführung einer bestimmten Aufgabe verantwortlich. Die Hardware-Schicht 12 ist für das Handhaben sowohl der mechanischen als auch elektrischen Details der physischen Übertragung eines Bitstroms verantwortlich. Die Datenverbindungsschicht 14 ist für die Handhabung der Pakete verantwortlich, einschließlich einer Erzeugung und Decodierung der Adresse, die durch das Hardware-Protokoll verwendet wird, und möglicher Fehlererfassung und Wiedergewinnung, die in der physischen Schicht aufgetreten sind. In einem Ethernet-Netzwerk z. B. ist die Datenverbindungsschicht 14 für ein Erzeugen und Decodieren der Medienzugriffssteueradresse (MAC-Adresse; MAC = media access control) verantwortlich. Die Netzwerkschicht 16 ist für die Bereitstellung von Verbindungen und das Routen von Paketen in dem Kommunikationsnetzwerk verantwortlich, einschließlich eines Erzeugens und Decodierens der Adresse, die durch Protokolle auf hoher Ebene verwendet wird, und eines Beibehaltens von Routing-Informationen für eine geeignete Antwort auf sich verändernde Lasten. Bei dem TCP/IP-Protokoll z. B. ist die Netzwerkschicht 16 für ein Erzeugen und Decodieren der IP-Adresse verantwortlich. Die Transportschicht 18 ist für Ende-Zu-Ende-Verbindungen zwischen Knoten in dem Netzwerk und die Übertragung von Nachrichten zwischen den Benutzern verantwortlich, einschließlich eines Partitionierens von Nachrichten in Pakete, Beibehaltens einer Paketordnung und -lieferung, Flusssteuerung und Erzeugung einer physischen Adresse. Die Sitzungsschicht 20 ist für ein Implementieren der Prozess-Zu-Prozess-Protokolle verantwortlich. Die Präsentationsschicht 22 ist für ein Auflösen von Unterschieden bei Formaten unter den verschiedenen Orten in dem Netzwerk verantwortlich, einschließlich Zeichenumwandlungen und Duplex (Echovorgang). Schließlich ist die Anwendungsschicht 24 für eine direkte Wechselwirkung mit den Benutzern verantwortlich. Die Schicht 24 könnte Anwendungen, wie z. B. elektronische Post, verteilte Datenbanken, Web-Browser und dergleichen, umfassen.
Bevor die ISO das OSI-Referenzmodell veröffentlicht hat, hat die Defense Advanced Research Projects Agency (DARPA = Agentur für moderne Abwehr-Forschungsprojekte) das ARPNET-Referenzmodell veröffentlicht. Das ARPNET-Referenzmodell umfasst vier Schichten, eine Netzwerk-Hardware-Schicht, eine Netzwerk-Schnittstellenschicht, eine Host-Zu-Host-Schicht und eine Prozess-/Anwendungsschicht.
Wie ihre Namen implizieren, stellen das OSI- und das ARPNET-Referenzmodell Richtlinien bereit, für deren Befolgung sich Entwerfer von Netzwerkbetriebskommunikationsprotokollen entscheiden können oder auch nicht. Die meisten Netzwerkbetriebsprotokolle jedoch definieren Schichten, die zumindest lose einem Referenzmodell entsprechen.
Auf dem Gebiet des Rechnens gibt es viele beliebte Protokolle, die zur Übertragung von Daten zwischen Netzknoten eingesetzt werden. TCP/IP, AppleTalk^®, NetBEUI und IPX z. B. sind alles beliebte Protokolle, die zur Übertragung von Daten zwischen Servern, Arbeitsplatzrechnern, Druckern und anderen Vorrichtungen, die mit Computernetzwerken gekoppelt sind, verwendet werden.
Es ist üblich, dass mehrere Protokolle gleichzeitig innerhalb eines einzelnen Netzknotens arbeiten, selbst wenn der Netzknoten eine einzelne Netzschnittstelle besitzt. Ein typischer Computerarbeitsplatzrechner z. B. könnte TCP/IP verwenden, um über das Internet zu kommunizieren, und IPX, um mit einem Netzwerkserver zu kommunizieren. Ähnlich könnte ein Drucker konfiguriert sein, um Druckaufträge unter Verwendung von entweder dem AppleTalk^®-Protokoll oder dem NetBEUI-Protokoll zu empfangen. Typischerweise kommunizieren diese Protokolle mit Hardware-Protokollen auf niedrigerer Ebene und stehen mit denselben in Wechselwirkung. Es ist z. B. häufig, dass zwei Computersysteme, die über ein Ethernet-Netzwerk gekoppelt sind, unter Verwendung des TCP/IP-Protokolls kommunizieren. Allgemein leitet bzw. routet eine Software-Routine, die an der Datenverbindungsschicht 14 oder der Netzwerkschicht 16 vorliegt, Datenpakete zwischen dem Netzwerkadapter und dem geeigneten Protokollstapel.
Es wird ein TCP/IP-Paket betrachtet, das über ein Ethernet-Netzwerk übertragen wird. Jedes Paket umfasst eine 48-Bit-Medienzugriffssteuer-(MAC-)Adresse, die einem anderen Knoten auf dem Ethernet-Netzwerk identifiziert. Die MAC-Adresse ist allgemeiner als Hardware-Adresse bekannt. Das gesamte Ethernet-Paket wird durch einen Code einer zyklischen Redundanzprüfung (CRC-Code; CRC = cyclic redundancy check) geschützt, der berechnet und durch den sendenden Netzwerkadapter in das Ethernet-Paket gestopft wird. Der empfangende Netzwerkadapter decodiert den CRC, um die Integrität des Ethernet-Pakets zu verifizieren. Wenn die Integrität des Pakets nicht verifiziert werden kann, d. h. ein Fehler erfasst wird, wird das Paket verworfen. In ein Ethernet-Paket eingekapselt ist der IP-Abschnitt des TCP/IP-Protokolls, der in der Technik als „Datagramm" bekannt ist. Das Datagramm umfasst eine 32-Bit-IP-Adresse und einen 16-Bit-Prüfsummencode, der den IP-Anfangsblock schützt. Das IP ist allgemeiner als eine Netzadresse bekannt. Wenn die Integrität des IP-Anfangsblocks nicht verifiziert werden kann, wird das Datagramm verworfen. Der TCP-Abschnitt des TCP/IP-Protokolls ist in das Datagramm eingekapselt und besitzt einen 16-Bit-Prüfsummencode, der den TCP-Anfangsblock und den Inhalt des TCP-Abschnitts des Datagramms schützt. Wenn die Integrität des TCP-Anfangsblocks oder des Inhalts des TCP-Abschnitts nicht verifiziert werden kann, wird das Datagramm verworfen und der Sender überträgt da Paket nochmals, nachdem er kein Bestätigungsdatagramm von dem beabsichtigten Empfänger empfangen hat. Es wird angemerkt, dass dieses Paket zwei Adressen beinhaltet, eine Hardware-(Ethernet-)Adresse und eine Netz-(IP-)Adresse. Die Beziehung zwischen diesen beiden Adressen ist unten detaillierter beschrieben.
2 ist ein Diagramm, das ein Netzwerk 26 des Stands der Technik zeigt. Das Netzwerk 26 verbindet Netzknoten 28, 30, 32, 34, 36, 38, 40, 42 und 44 miteinander. Wie oben beschrieben wurde, könnten die Netzknoten Vorrichtungen, wie z. B. Computerarbeitsplatzrechner, Server, Netzwerkdrucker, Netzwerkscanner und dergleichen, sein. Aus Erläuterungsgründen wird angenommen, dass die Netzknoten mit Ethernet-Netzwerkadaptern ausgerüstet sind und Daten unter Verwendung des TCP/IP-Protokolls übertragen. Viele Netzwerke erfüllen eine Serie von Standards, die durch das Institute of Electrical and Electronics Engineers (IEEE = Institut von Elektrik- und Elektronik-Ingenieuren) veröffentlicht wurden. Diese Serie von Standards ist in der Technik als die IEEE-802-Familie von Standards bekannt.
Die Netzknoten sind über Hubs bzw. Naben miteinander in LAN-Segmente gekoppelt. Alle Knoten in einem LAN-Segment befinden sich in einem gemeinsamen Kollisionsbereich, da jeder Knoten in einem LAN-Segment ein Signal empfängt, wenn ein anderer Knoten versucht, ein Paket zu übertragen, und wenn zwei Knoten in einem LAN-Segment gleichzeitig versuchen, ein Paket zu übertragen, tritt eine Kollision auf. Das Ethernet-Protokoll umfasst einen Neuübertragungsalgorithmus, der die Wahrscheinlichkeit, dass eine weitere Kollision auftreten wird, wenn die beiden Knoten versuchen, ihre jeweiligen Pakete erneut zu übertragen, minimiert. In 2 sind die Netzknoten 28, 30 und 32 miteinander über ein Hub 46 in ein LAN-Segment 48 gekoppelt. Ähnlich sind die Netzknoten 34, 36 und 38 miteinander über ein Hub 50 in ein LAN-Segment 52 gekoppelt und die Netzknoten 40, 42 und 44 sind miteinander über ein Hub 54 in ein LAN-Segment 56 gekoppelt.
Schalter und Brücken werden verwendet, um lokale oder entfernte LAN-Segmente miteinander zu verbinden. Schalter und Brücken bilden ein einzelnes logisches Netzwerk (oft als ein Teilnetz bezeichnet) und arbeiten an einer Datenverbindungsschicht 14 und einer Hardware-Schicht 12 des OSI-Referenzmodells 10. In 2 verbindet ein Schalter 58 die LAN-Segmente 48 und 52. In dem Ethernet-Protokoll werden Pakete durch eine Medienzugriffssteuer-(MAC-)Adresse adressiert. Schalter und Brücken behalten Listen der MAC-Adresse der Netzknoten auf jedem LAN-Segment bei, an das dieselben angefügt sind, um in der Lage zu sein, einzelne Pakete an den geeigneten Port in dem Schalter oder der Brücke zum Routen jedes Pakets zu dem LAN-Segment, das den Knoten beinhaltet, der durch die MAC-Adresse adressiert wird, weiterzuleiten.
Während Schalter und Brücken LAN-Segmente miteinander verbinden, um Teilnetze zu bilden, werden Router verwendet, um Teilnetze über ein anderes Netzwerk, wie z. B. das Internet oder ein Weitverkehrsnetz (WAN; WAN = wide area network), miteinander zu verbinden. Router könnten auch verwendet werden, um Pakete innerhalb eines gemeinsamen Teilnetzes zu routen, was unten beschrieben wird. Router behalten Tabellen bei, die Adressen eines Protokolls auf höherer Ebene (wie z. B. eine IP-Adresse) Ports des Routers zuordnen. Im Gegensatz zu Schaltern und Brücken sind Router auch in der Lage, das Netzwerk als eine hierarchische Topologie zu betrachten, wobei große Blöcke und Bereiche von Adressen zu anderen Routern zum weiteren Routen geroutet werden. Aus diesem Grund werden Router oft verwendet, um Pakete in sehr großen Netzwerken, wie z. B. dem Internet, zu routen.
Ein Vorgabe-Gateway ist der Router, zu dem ein Knoten ein Paket routet, wenn der Knoten nicht bestimmen kann, dass ein ausgehendes Paket an einen Knoten auf dem gleichen Teilnetz adressiert ist. Ein Paket, das zu einem Vorgabe-Gateway übertragen wird, könnte durch mehrere andere Router verarbeitet werden, bevor es an dem Zielknoten ankommt.
Mehrere Protokolle wurden definiert, die es ermöglichen, dass das TCP/IP-Protokoll mit Hardware-Protokollen auf niedrigerer Ebene, wie z. B. dem Ethernet-Protokoll, arbeiten kann. Einem Ethernet-Knoten z. B., der konfiguriert ist, um TCP/IP zu verwenden, ist eine IP-Adresse, eine Teilnetzmaske und eine Vorgabe-Gateway-Adresse zugewiesen. Die Teilnetzmaske identifiziert IP-Adressen, die auf dem gleichen Teilnetz sind, und die Vorgabe-Gateway-Adresse identifiziert einen Router, der Pakete verarbeitet, die nicht auf dem gleichen Teilnetz sind. Für Pakete auf dem gleichen Teilnetz wird das ARP (Address Resolution Protocol = Adressauflösungsprotokoll) verwendet, um die IP-Adresse eines Zielknotens zu finden.
Es wird angenommen, dass der Knoten 28 eine IP-Adresse 192.44.133.13 aufweist, und es wird angenommen, dass der Knoten 30 eine IP-Adresse 192.44.133.25 aufweist. Ferner wird angenommen, dass die Teilnetzmaske des Knotens 28 auf 255.255.255.0 gesetzt ist. Um ein Paket an den Knoten 30 zu senden, führt der Knoten 28 zuerst eine bit-weise UND-Operation der IP-Adresse des Knotens 30 mit der Teilnetzmaske durch und vergleicht das Ergebnis mit einer bit-weisen UND-Operation der IP-Adresse des Knotens 28 und der Teilnetzmaske. Wenn die Ergebnisse der beiden UND-Operationen übereinstimmen, befindet sich der Knoten 30 auf dem gleichen Teilnetz wie der Knoten 28 und die MAC-Adresse des Knotens 30 kann unter Verwendung des ARP gefunden werden. Als Nächstes sendet der Knoten 28 ein Rundsende-Ethernet-Paket mit seiner eigenen MAC-Adresse und der IP-Adresse des Knotens 30 gemäß dem ARP aus. Das Ethernet-Protokoll unterstützt Einsende- und Rundsendepakete. Ein Rundsendepaket ist an alle Knoten auf einem Teilnetz adressiert und wird durch alle empfangen, während ein Einsendepaket an einen spezifischen Knoten adressiert ist und durch denselben empfangen wird. Der Knoten 30 spricht auf diese Nachricht durch ein Übertragen eines Einsendepakets, das die MAC-Adresse des Knotens 30 beinhaltet, zurück zu dem Knoten 28 an. Der Knoten 28 überträgt dann das TCP/IP-Paket unter Verwendung der MAC-Adresse, die gerade von dem Knoten 30 empfangen wurde, an den Knoten 30. Ferner speichern Knoten diese Informationen für zukünftige Übertragungen zwischen, wodurch der Bedarf eines wiederholten Findens der MAC-Adresse von Knoten auf dem gleichen Teilnetz minimiert wird.
Es wird nun angenommen, dass der Knoten 28, der weiterhin wie oben konfiguriert ist, ein Paket an einen Knoten 40 senden möchte, der eine IP-Adresse 168.45.198.2 aufweist. Der Knoten 28 bestimmt, dass der Knoten 40 nicht auf dem gleichen Teilnetz ist, basierend auf der Teilnetzmaske unter Verwendung der oben beschriebenen bit-weisen UND-Operationen. Sobald dies erledigt ist, leitet der Knoten 28 das Paket an einen Router 62 weiter, der der Vorgabe-Gateway ist, der durch den Knoten 28 verwendet wird, um Pakete zu übertragen, die an Knoten adressiert sind, die der Knoten 28 nicht als auf dem gleichen Teilnetz befindlich verifizieren kann. Der Router 62 wiederum leitet das Paket an einen Router 68 weiter, der Router 68 leitet das Paket an einen Router 69 weiter und der Router 69 leitet das Paket an einen Router 60 weiter. Da der Router 60 auf dem gleichen Teilnetz wie der Knoten 40 (der Zielknoten) ist, entdeckt der Router 60 die MAC-Adresse des Knotens 40 unter Verwendung des ARP, adressiert das Paket neu mit der MAC-Adresse des Knotens 40 und überträgt das Paket an das LAN-Segment 56, an dem das Paket durch den Knoten 40 empfangen wird.
Eine Vielzahl von Protokollen wurde definiert, die es ermöglichen, dass ein Knoten mit einer IP-Adresse, einer Teilnetzadresse, der Adresse eines Vorgabe-Gateways sowie anderen Parametern konfiguriert sein kann. In der folgenden Erläuterung beziehen sich die Ausdrücke „Client", „Clientknoten" und „zu konfigurierender Knoten" auf den Netzknoten, der Konfigurationsparameter für sich selbst erhalten möchte. Der Ausdruck „Server" bezieht sich auf den Netzknoten, der Konfigurationsparameter bereitstellt. Ein einfaches Protokoll ist das RARP (Reverse Address Resolution Protocol = Rückadressauflösungsprotokoll), das über ein Ethernet-Netzwerk ausgeführt wird und eine Ethernet-Adresse in eine IP-Adresse umwandelt. Der Client sendet ein Ethernet-Paket mit seiner MAC-Adresse rund und der Server spricht durch ein übertragen eines Einsendepakets an den Clienten, der die IP-Adresse des Clienten beinhaltet, an. Das RARP wird hauptsächlich durch plattenlose Netzknoten verwendet.
Ein weiterer Protokollstandard, das Bootstrap- bzw. Urlade-Protokoll (BOOTP) wird häufig in Netzwerken mit plattenlosen Knoten verwendet. Das BOOTP verwendet das UDP (User Datagram Protocol = Benutzerdatagrammprotokoll). Das BOOTP ermöglicht es, dass ein Knoten seine eigene IP-Adresse, die Teilnetzmaske, die Vorgabe-Gateway-Adresse, die Adresse eines BOOTP-Servers und einen Pfadnamen bestimmen kann, der auf eine Boot- bzw. Hochfahr-Datei zeigt, die von dem BOOTP-Server geladen werden kann, wenn der Knoten hochfährt. Das BOOTP definiert außerdem BOOTP-Weiterleitagenten, die es ermöglichen, dass ein Knoten, der Konfigurationsparameter sucht, durch einen BOOTP-Server auf einem anderen Teilnetz bedient werden kann. Das BOOTP ist in dem RFC (Request For Comment = Anforderung nach Kommentar) 951 definiert, das hierin durch Bezugnahme aufgenommen ist.
Das NIP (Network Information Protocol = Netzwerkinformationsprotokoll) ermöglicht es außerdem, dass ein Netzknoten seine eigene IP-Adresse bestimmen kann und verfügbare IP-Adressen durch ein Verwenden eines „Abfrage/Abwehr"-Mechanismus identifizieren kann, durch den Netzknoten abgefragt werden, um zu bestimmen, ob IP-Adressen in Verwendung sind. Clienten verteidigen IP-Adressen, die in Verwendung sind, durch ein Ansprechen auf die Abfragenachrichten. Wenn ein Client eine Nachricht ausgibt, die eine IP-Adresse sucht, gibt der NIP-Server einen Satz von IP-Adressen, die auf dem Netzwerk verfügbar sind, zurück. Der Client wählt eine der IP-Adressen aus und prüft doppelt, um sicherzustellen, dass diese verfügbar ist, unter Verwendung des ARP. Der Client reserviert dann die IP-Adresse für sich selbst, durch ein Ansprechen auf den NIP-Server, der die zugeteilte IP-Adresse aufzeichnet.
Schließlich ist das DHCP (Dynamic Host Configuration Protocol = dynamisches Host-Konfigurationsprotokoll) eine Erweiterung des BOOTP und ist im RFC 1541 und RFC 1533 beschrieben, die hierin beide durch Bezugnahme aufgenommen sind. Da das DHCP eine Erweiterung des BOOTP ist, stellt es alle Dienste bereit, die durch das BOOTP bereitgestellt werden. Es ist auch in der Lage, eine automatische Zuteilung von IP-Adressen, die eine endliche Miete (und deshalb zu einer späteren Zeit auslaufen) aufweisen, eine automatische Zuteilung von IP-Adressen, die eine unendliche Miete aufweisen (und deshalb niemals auslaufen), und eine statische Zuteilung von IP-Adressen, die durch einen Netzwerkadministrator ausgewählt werden, bereitzustellen.

Unten befinden sich die Hauptnachrichten, die gemäß dem DHCP-Protokoll ausgetauscht werden, zusammen mit einer Beschreibung der Client-Server-Wechselwirkung.

Nachricht	Verwendung
DHCPDISCOVER	Client-Nachricht zur Lokalisierung verfügbarer Server.
DHCPOFFER	Server-Nachricht an Clienten ansprechend auf DHCPDISCOVER, Nachricht umfasst ein Angebot an Konfigurationsparametern.
DHCPREQUEST	Client-Nachricht an DHCP-Server, die angebotene Parameter von einem Server anfordert und implizit Angebote von allen anderen DHCP-Servern ablehnt.
DHCPACK	Server-Nachricht an Clienten mit Konfigurationsparametern, einschließlich zweckgebundener IP-Adresse.
DHCPNAK	Server-Nachricht an Clienten, die Anforderung nach Konfigurationsparametern verweigert.
DHCPDECLINE	Client-Nachricht an Server, die anzeigt, dass Konfigurationsparameter (z. B. IP-Adresse) ungültig sind.
DHCPRELEASE	Client-Nachricht an Server, die Netzadresse aufgibt und verbleibende Miete löscht.

Der Konfigurationsdialog zwischen dem Clienten und dem Server beginnt damit, dass der Client eine DHCPDISCOVER-Nachricht auf seinem lokalen Teilnetz rundsendet. Ein BOOTP-Weiterleit-Software-Agent auf dem Teilnetz könnte die Nachricht an DHCP-Server weiterleiten, die nicht auf dem gleichen Teilnetz sind. Als Nächstes könnte jeder Server mit einer DHCPOFFER-Nachricht ansprechen, die eine verfügbare Netz-IP-Adresse und andere Konfigurationsparameter umfasst. Der Server führt ein Einsenden der DHCPOFFER-Nachricht an den Clienten, falls möglich, durch und verwendet den BOOTP-Weiterleit-Agenten, falls dies nötig ist. Alternativ könnte der Server die Nachricht unter Verwendung einer Rundsendeadresse an das Teilnetz des Clienten rundsenden.
Der Client empfängt dann eine oder mehrere DHCPOFFER-Nachrichten von einem oder mehreren Servern. Der Client könnte auswählen, auf mehrere Antworten zu warten. Der Client wählt dann einen Server aus, von dem Konfigurationsparameter angefordert werden sollen, und zwar basierend auf den Konfigurationsparametern, die in den DHCPOFFER-Nachrichten angeboten werden. Der Client führt dann ein Rundsenden einer DHCPREQUEST-Nachricht durch, die eine „Serveridentifizierer"-Option umfassen muss, um anzuzeigen, welchen Server der Client ausgewählt hat. Diese Nachricht könnte andere Optionen umfassen, die erwünschte Konfigurationswerte spezifizieren.
Die Server empfangen das DHCPREQUEST-Rundsenden von dem Clienten und die Server, die durch die DHCPREQUEST-Nachricht nicht ausgewählt werden, verwenden die Nachricht als Benachrichtigung, dass der Client das Angebot des Servers abgelehnt hat. Der durch den Clienten in der DHCPREQUEST-Nachricht ausgewählte Server übergibt dann die Bindung für den Clienten und spricht mit einer DHCPACK-Nachricht, die die Konfigurationsparameter beinhaltet, an. Wenn der ausgewählte Server nicht in der Lage ist, die DHCPREQUEST-Nachricht zu erfüllen, spricht der Server mit einer DHCPNAK-Nachricht an, die die Anforderung des Clienten verweigert.
Wenn der Client eine DHCPNAK-Nachricht empfängt, beginnt er neu. Wenn der Client eine DHCPACK-Nachricht mit Konfigurationsparametern empfängt, führt der Client eine letzte Prüfung an den Parametern durch und notiert die Länge einer Zeit, für die die IP-Adresse gültig ist (die Dauer der Miete), und eine Mietidentifizierung, die in der DHCPACK-Nachricht spezifiziert ist. An diesem Punkt ist der Client mit einer Client-IP-Adresse, einer Teilnetzmaske und einer Vorgabe-Gateway-Adresse konfiguriert. Wenn der Client ein Problem mit den Parametern in der DHCPACK-Nachricht erfasst, sendet der Client eine DHCPDECLINE-Nachricht zurück an den Server und startet den Konfigurationsprozess neu. Der Client könnte seine Miete auf eine IP-Adresse durch ein Senden einer DHCPRELEASE-Nachricht an den Server abgeben. Die Wechselwirkung von Nachrichten in dem BOOTP-Protokoll ist ähnlich.
Zusammenfassung der Erfindung
Die vorliegende Erfindung ist ein Konfigurationsagent, der es ermöglicht, dass ein Netz- bzw. Netzwerkknoten, der automatisch mit einer IP-Adresse und einer Vorgabe-Gateway-Adresse konfiguriert werden möchte, als sein eigenes Gateway konfiguriert werden kann. Durch ein Konfigurieren eines Knotens, um sein eigener Vorgabe-Gateway zu sein, ist der Knoten in der Lage, eine übliche Vorgabe-Gateway-Routine auszuführen, die sowohl Paketen auf dem Teilnetz als auch außerhalb des Teilnetzes verarbeitet. Im Gegensatz dazu haben Knoten des Stands der Technik eine Teilnetzmaske verwendet, um zu bestimmen, ob ein Zielknoten auf dem gleichen Teilnetz ist. Der Teilnetzmaskenmechanismus ist weniger flexibel, da Knotenadressen in Potenzen von Zwei zu dem Teilnetz hinzugefügt werden müssen, was nicht immer praktisch oder unmöglich ist. Während es wünschenswert ist, einen Knoten zu konfigurieren, um sein eigener Gateway zu sein, ermöglichen es Konfigurationsprotokolle des Stands der Technik, wie z. B. das Dynamic Host Configuration Protocol (DHCP), nicht, dass ein Netzknoten als sein eigener Gateway konfiguriert werden kann.
Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des Anspruchs 1 und durch eine Vorrichtung mit den Merkmalen des Anspruchs 14 gelöst. Bevorzugte Ausführungsbeispiele derselben sind in den jeweiligen abhängigen Ansprüchen definiert.
Bei einem ersten und einem zweiten Ausführungsbeispiel der vorliegenden Erfindung befindet sich der Konfigurationsagent auf einer Netzvorrichtung (wie z. B. einem Schalter oder einer Brücke), die mit zwei Netzsegmenten gekoppelt ist, wobei ein Netzsegment einen zu konfigurierenden Knoten umfasst und ein anderes Netzsegment einen Server umfasst, der in der Lage ist, automatisch Konfigurationsparameter bereitzustellen.
Bei dem ersten Ausführungsbeispiel der Erfindung wirkt der Konfigurationsagent als ein schnüffelnder Agent. Nachrichten von dem Konfigurationsserver an den zu konfigurierenden Knoten werden „abgeschnüffelt", um Nachrichten zu entdecken, die eine IP-Adresse und eine Vorgabe-Gateway-Adresse beinhalten. Derartige Nachrichten werden verändert, um die IP-Adressen, die den eine Konfiguration suchenden Knoten angeboten werden, in die Vorgabe-Gateway-Adressen zu kopieren, und die Nachrichten werden auf ihren Weg geschickt, wodurch bewirkt wird, dass Konfiguration suchende Knoten als ihr eigener Vorgabe-Gateway konfiguriert werden. Bei vielen Konfigurationen werden Nachrichten von dem zu konfigurierenden Knoten an den Konfigurationsserver verändert, um sicherzustellen, dass Nachrichten von dem Konfigurationsserver an den Konfiguration suchenden Knoten Rundsende-Nachrichten sind.
Bei dem zweiten Ausführungsbeispiel der Erfindung wirkt die Konfiguration wie ein Proxy-Agent. Vom Standpunkt des Konfiguration suchenden Knotens aus erscheint der Proxy-Agent wie ein Konfigurationsagent. Vom Standpunkt des Konfigurationsservers aus erscheint der Proxy-Agent wie ein Weiterleitagent, wenn der Konfigurationsserver und der Konfiguration suchende Knoten auf unterschiedlichen Teilnetzen sind. Wenn diese auf dem gleichen Teilnetz sind, verarbeitet der Proxy-Agent Nachrichten von dem Konfigurationsserver an den Konfiguration suchenden Knoten in einer ähnlichen Weise wie der schnüffelnde Agent.
Wenn der Konfiguration suchende Knoten Nachrichten sendet, die anzeigen, dass er mit einer IP-Adresse und einem Vorgabe-Gateway konfiguriert werden möchte, empfängt der Proxy-Agent die Nachrichten. Basierend auf der Konfiguration des zweiten Ausführungsbeispiels könnte der Proxy-Agent die Nachrichten verändern, um Einsende- oder Rundsendeantworten von dem Server anzufordern. Zusätzlich wird, wenn der zu konfigurierende Knoten und der Konfigurationsagent nicht auf dem gleichen Teilnetz sind, die Nachricht verändert, um zu bewirken, dass der Konfigurationsserver den Proxy-Agenten als einen Weiterleitagenten behandelt.
Wenn der Konfigurationsserver Nachrichten an den zu konfigurierenden Knoten sendet (und möglicherweise den Proxy-Agenten als einen Weiterleitagenten behandelt), fängt der Proxy-Agent die Nachricht ab und kopiert die angebotene IP-Adresse in die Vorgabe-Gateway-Adresse in der Nachricht, wodurch bewirkt wird, dass der Konfiguration suchende Knoten als sein eigener Gateway konfiguriert wird. Der Proxy-Agent ersetzt außerdem seine IP-Adresse durch die IP-Adresse des tatsächlichen Konfigurationsservers, wodurch bewirkt wird, dass der Konfiguration suchende Knoten den Proxy-Agenten als den Konfigurationsagenten behandelt.
Kurze Beschreibung der Zeichnungen
1 ist ein Blockdiagramm des Open System Interconnection-(OSI-)Referenzmodells.
2 ist ein Diagramm, das ein Netzwerk des Stands der Technik zeigt.
3 zeigt ein Netz, das einen Schalter umfasst, mit einem Konfigurationsagenten gemäß der vorliegenden Erfindung.
4 zeigt einen N-Port-Schalter gemäß einem ersten Ausführungsbeispiel der vorliegenden Erfindung, bei dem der Konfigurationsagent ein schnüffelnder Agent des Dynamic Host Configuration Protocol (DHCP) ist.
5 ist ein Flussdiagramm, das darstellt, wie der schnüffelnde DHCP-Agent, der in 4 gezeigt ist, Pakete verarbeitet.
6 zeigt einen N-Port-Schalter gemäß dem zweiten Ausführungsbeispiel der vorliegenden Erfindung, bei dem der Konfigurationsagent ein DHCP-Proxy-Agent ist.
7 bis 10 zusammengenommen sind ein Flussdiagramm, das darstellt, wie der DHCP-Proxy-Agent aus 6 Pakete verarbeitet.
Detaillierte Beschreibung der bevorzugten Ausführungsbeispiele
Die vorliegende Erfindung ist ein Konfigurationsagent, der sich auf einer Netz- bzw. Netzwerkvorrichtung befindet, wie z. B. ein Schalter. Der Konfigurationsagent ermöglicht es einem Netzknoten, der Konfigurationsparameter sucht, als sein eigener Vorgabe-Gateway konfiguriert zu sein, zu dem Zweck eines direkten Kommunizierens mit Knoten, die sich auf dem gleichen Teilnetz befinden, obwohl eine Teilnetzmaske anzeigen könnte, dass die Knoten auf unterschiedlichen Teilnetzen sein könnten. Bevor die vorliegende Erfindung unten detaillierter erläutert wird, ist es hilfreich, einige gegenwärtige Trends auf dem Gebiet des Computernetzwerkbetriebs zu verstehen.
Herkömmlicherweise haben große TCP/IP-Netzwerke oft Router verwendet, um Pakete zwischen Netzknoten zu übertragen. Verglichen mit Schaltern jedoch sind Router relativ langsam und prozessorintensiv. Zusätzlich sind Router wesentlich teurer als Schalter.
Wie oben erläutert wurde, können zwei TCP/IP-Knoten, die über ein Ethernet-Netzwerk verbunden sind, direkt ohne einen Router kommunizieren, unter der Voraussetzung, dass die Teilnetzmaske eines sendenden Knotens anzeigt, dass sich die Ziel-IP-Adresse auf dem gleichen Ethernet-Netzwerk befindet. Der sendende Knoten führt eine bit-weise UND-Operation mit der Teilnetzmaske und seiner IP-Adresse durch und vergleicht das Ergebnis mit einer bit-weisen UND-Operation der Teilnetzmaske und der Ziel-IP-Adresse. Wenn die Ergebnisse übereinstimmen, verwendet der sendende Knoten das ARP (Address Resolution Protocol = Adressauflösungsprotokoll), um die IP-Adresse in eine Ethernet-Adresse umzuwandeln, bevor ein TCP/IP-Paket ausgesendet wird. Wie der Ausdruck „Hardware-Adresse" hierin verwendet wird, bezieht er sich auf eine Adresse auf niedrigerer Ebene, die durch die Netzwerkbetriebs-Hardware verwendet wird, wie z. B. eine Ethernet-MAC-Adresse. Der Ausdruck „Netzadresse" bezieht sich auf die Adresse, die auf höheren Ebenen des Protokollstapels verwendet wird, wie z. B. eine IP-Adresse.
Die Teilnetzmaske ist ein relativ roher Mechanismus. IP-Adressen können nur in Potenzen von Zwei zu dem Netzwerk bzw. Netz hinzugefügt werden. Entsprechend sind, wenn eine Teilnetzmaske auf 255.255.252.0 gesetzt ist, 1.024 eindeutige IP-Adressen auf dem Netz verfügbar und die Knoten, die diesen Adressen zugeordnet sind, könnten direkt miteinander kommunizieren, ohne dass ein Router erforderlich ist. Wenn jedoch ein Netzwerkadministrator mehr IP-Adressen hinzufügen möchte, muss eines der Bits in der Teilnetzmaske gelöscht werden, wodurch 2.048 eindeutige Adressen bereitgestellt werden. In vielen Situationen sind unter Umständen nicht alle dieser Adressen verfügbar. Deshalb ist der Netzwerkadministrator gezwungen, TCP/IP zu konfigurieren, um bestimmte Pakete zu einem Router zu übertragen, der durch eine Vorgabe-Gateway-Adresse identifiziert ist, obwohl die durch das Paket adressierten Zielknoten auf dem gleichen Teilnetz sind. Tatsächlich werden zur Minimierung von Konfigurationsproblemen viele Netzknoten einfach konfiguriert, um alle TCP/IP-Pakete an das Vorgabe-Gateway zu übertragen.
Eine Lösung für dieses Problem besteht darin, die Vorgabe-Gateway-Adresse jedes Knotens zu der IP-Adresse des Knotens selbst zu konfigurieren. Deshalb routet, wenn ein Netzknoten ein TCP/IP-Paket senden möchte, eine Gateway-Teilroutine auf dem Netzknoten das Paket. Die Gateway-Teilroutine verwendet ARP, um die MAC-Adresse zu finden, zu der das Paket geroutet werden soll. Es wird angemerkt, dass Router und Schalter konfiguriert sein können, um einen ARP-Proxy-Server zu umfassen. In Bezug auf einen Schalter reduziert ein ARP-Proxy-Server einfach einen Netzwerkverkehr durch ein Zwischenspeichern der MAC-Zu-IP-Adresse, die alle Knoten auf dem Teilnetz abbildet. Entsprechend wird, wenn ein Knoten versucht, die IP-Adresse eines entfernten Knotens auf dem gleichen Teilnetz zu finden, und ein ARP-Anforderungspaket rundsendet, das Paket nur innerhalb des LAN-Segments übertragen. Ein ARP-Proxy-Server ist nicht erforderlich, wenn LAN-Segmente miteinander über Schalter in ein Teilnetz gekoppelt sind. Ohne ARP-Proxy-Server auf den Schaltern jedoch werden ARP-Rundsendungen an alle Knoten auf dem Teilnetz übertragen, wodurch ein Netzverkehr zunimmt. Wenn die Gateway-Teilroutine ARP verwendet, um die MAC-Adresse eines entfernten Knotens auf einem anderen LAN-Segment zu finden, und der Schalter einen ARP-Proxy-Server aufweist, stellt der ARP-Proxy-Server die MAC-Adresse des entfernten Knotens bereit.
Im Gegensatz dazu ist ein ARP-Proxy-Server auf einem Router nötig, wenn Knoten auf unterschiedlichen Teilnetzen unter Verwendung des ARP kommunizieren sollen. Der ARP-Proxy-Server des Routers behält eine Entsprechung zwischen MAC-Adresse und IP-Adresse bei. Für Knoten außerhalb des Teilnetzes jedoch ist die MAC-Adresse, die durch den ARP-Proxy-Server des Routers bereitgestellt wird, die MAC-Adresse des Routers selbst. Wenn die Gateway-Teilroutine ARP verwendet, um die MAC-Adresse eines entfernten Knotens auf einem anderen Teilnetz zu finden, spricht der ARP-Proxy-Server des Routers mit der MAC-Adresse des Routers an, wodurch bewirkt wird, dass das Paket zum weiteren Routen an den Router gesendet wird.
Da das ARP verwendet wird, um alle IP-Adressen aufzulösen, werden alle Pakete auf dem gleichen Teilnetz durch Schalter geroutet und ein Router wird nur verwendet, um Pakete zu übertragen, die tatsächlich außerhalb des Ethernet-Netzwerks sind. TCP/IP-Pakete, die innerhalb des Netzes übertragen werden, werden schneller übertragen, da Schalter schneller sind als Router. Verglichen mit dem Teilnetzmaskenmechanismus ist die Gateway-Teilroutine nicht auf ein Hinzufügen von IP-Adressen in Potenzen von Zwei eingeschränkt. Außerdem müssen hinzugefügte Bereiche nicht zusammenhängend sein. Deshalb besitzt ein Netzwerkadministrator mehr Flexibilität beim Zuweisen von IP-Adressen zu einem Ethernet-Netzwerk.
Beim Verfolgen dieses Ansatzes ist ein Problem, dem sich der Netzwerkadministrator gegenübersieht, ein Konfigurieren jedes Netzknotens, um sein eigner Gateway zu sein. Natür lich kann dies manuell durchgeführt werden, dies ist jedoch für Anfängerbenutzer unter Umständen keine akzeptable Lösung. Zusätzlich könnte dies für Netzwerke mit vielen Knoten keine akzeptable Lösung sein.
Um eine Netzwerkadministration zu vereinfachen, haben viele Netzwerkadministratoren sich zu einem automatischen Host-Konfigurationsprotokoll bewegt, wie z. B. dem Bootstrap Protocol (BOOTP) oder dem Dynamic Host Configuration Protocol (DHCP). Leider unterstützen diese Protokolle kein Konfigurieren eines Netzknotens, um sein eigener Gateway zu sein. Nachdem ein Netzwerkadministrator die Aufgabe eines Einrichtens eines Servers mit automatischem Host-Konfigurationsprotokoll unternommen hat und alle Netzknoten konfiguriert hat, um Konfigurationsparameter von dem Server zu empfangen, kehrt der Administrator wahrscheinlich nicht zu einer manuellen Konfiguration zurück.
Die vorliegende Erfindung löst dieses Dilemma. Bei einem Ausführungsbeispiel umfasst ein Schalter (oder eine ähnliche Netzvorrichtung) einen schnüffelnden DHCP-Agenten. Der schnüffelnde Agent beschnüffelt Pakete, die durch den Schalter übertragen werden, und schaut nach DHCP-Konfigurationsnachrichten aus. Wenn der schnüffelnde Agent eine Nachricht erfasst, die an einen Netzknoten gerichtet ist und Konfigurationsparameter beinhaltet, kopiert der Agent das Feld, das die in Frage kommende IP-Adresse beinhaltet, in das Feld, das den Vorgabe-Gateway beinhaltet. Der schnüffelnde Agent sendet dann das Paket auf seinen Weg, wodurch bewirkt wird, dass die Vorgabe-Gateway-IP-Adresse, die auf dem Netzknoten gespeichert ist, als die IP-Adresse des Knotens selbst gesetzt wird.
Bei einem zweiten weiterentwickelten Ausführungsbeispiel umfasst ein Schalter (oder eine ähnliche Vorrichtung) einen DHCP-Proxy-Agenten. Vom Standpunkt des Netzknotens aus, der Konfigurationsinformationen sucht, erscheint der Proxy-Agent wie ein DHCP-Server. Vom Standpunkt des DHCP-Servers aus erscheint der Proxy-Agent wie ein DHCP/BOOTP-Weiterleitagent, wenn der zu konfigurierende Client und der DHCP-Server auf unterschiedlichen Teilnetzen sind. Wenn der Client und der Server auf dem gleichen Teilnetz sind, verarbeitet der Proxy-Agent Nachrichten von dem Server an den Clienten in einer ähnlichen Weise wie der schnüffelnde Agent. DHCP/BOOTP-Weiterleitagenten sind in der Technik bekannt und werden verwendet, um Konfigurationsparameter zwischen Netzwerken weiterzuleiten. Da der Proxy-Agent zwischen dem Netzknoten, der Konfigurationsparameter sucht, und dem DHCP-Server steht, ist der Proxy-Agent in einer Position, um die Nachrichten, die zu und von dem DHCP-Server übertragen werden, zu verändern, indem das Feld, das die in Frage kommende IP-Adresse beinhaltet, in das Feld kopiert wird, die den Vorgabe-Gateway beinhaltet. Beide Ausführungsbeispiele sind unten detaillierter beschrieben.
Die vorliegende Erfindung wird unter Bezugnahme auf das Dynamic Host Configuration Protocol beschrieben. Die Erfindung ist jedoch nicht auf das DHCP eingeschränkt. Fachleute auf dem Gebiet werden erkennen, dass die vorliegende Erfindung auf andere ähnliche Protokolle, wie z. B. das Bootstrap-Protocol, angewendet werden kann. Das Format einer DHCP-Nachricht ist unten in Tabelle 1 aufgeführt. Das Format ist von RFC 1541 hergeleitet, das oben gemeinsam mit dem RFC 1533 und RFC 951 durch Bezugnahme aufgenommen wurde.
TABELLE 1
Die Felder sind wie folgt definiert:
3 zeigt ein Netz 74, das einen Schalter 76 mit einem Konfigurationsagenten gemäß der vorliegenden Erfindung umfasst. 3 ist generisch für sowohl das erste Ausführungsbeispiel der vorliegenden Erfindung, bei dem der Konfigurationsagent ein schnüffelnder DHCP-Agent ist, als auch das zweite Ausführungsbeispiel der Erfindung, bei dem der Konfigurationsagent ein DHCP-Proxy-Agent ist.
Der Schalter 76 koppelt ein LAN-Segment 78 mit einem LAN-Segment 82 über ein Hub 80 bzw. ein Hub 84. Das LAN-Segment 78 umfasst einen Netzknoten 86, der konfiguriert werden möchte, und das LAN-Segment 82 umfasst einen DHCP-Server 88, der Konfigurationsparameter bereitstellt. Bei beiden Konfigurationen der vorliegenden Erfindung verändert der Konfigurationsagent auf dem Schalter die Wechselwirkung zwischen dem Knoten 86 und dem Server 88. Deshalb ist der Schalter 76 vorzugsweise zwischen dem Knoten 86 und dem Server 88 positioniert, so dass der Kommunikationspfad zwischen dem Knoten 86 und dem Server 88 durch den Schalter 76 fließt.
4 zeigt einen N-Port-Schalter 90 gemäß dem ersten Ausführungsbeispiel der vorliegenden Erfindung. Jeder Port besitzt einen Eingangspfad zu einer Weiterleiteinheit 100 und einen Ausgangspfad, der einen Ausgangspuffer umfasst, wie z. B. Ausgangspuffer 92, 94, 96 und 98. Ferner umfasst die Weiterleiteinheit 100 einen schnüffelnden DHCP-Agenten 102. Mit Ausnahme von dem, was unten erläutert ist, leitet die Weiterleiteinheit 100 Pakete in einer im Stand der Technik bekannten Art und Weise weiter.
5 ist ein Flussdiagramm 104, das darstellt, wie der schnüffelnde DHCP-Agent 102 Pakete verarbeitet. Bei einem Block 106 wird das Paket empfangen. Ein Block 108 bestimmt, ob das Paket ein DHCPDISCOVER-, DHCPREQUEST-, DHCPOFFER- oder DHCPACK-Paket ist, das einen Netzknoten, der als sein eigener Gateway konfiguriert werden soll, spezifiziert. Es wird angemerkt, dass bei einer Konfiguration der vorliegenden Erfindung der Schalter 90 konfiguriert sein könnte, um nur Knoten zu „helfen", die bestimmte MAC-Adressen besitzen, indem eine Tabelle von zu „helfenden" Knoten beibehalten wird. Anders ausgedrückt könnte es wünschenswert sein, dass einige Knoten als ihre eigenen Gateways konfiguriert sind, während andere Knoten gemäß dem Stand der Technik konfiguriert sein könnten. Wenn das Paket nicht eines der obigen Typen ist, oder wenn das Paket von einem Knoten ist, dem nicht „geholfen" werden soll, wird der „NEIN"-Zweig zu einem Block 110 genommen, bei dem das Paket übertragen wird. Die Steuerung gelangt dann zurück zu Block 106, um auf das nächste Paket zu warten.
Wenn das Paket ein DHCPDISCOVER- oder DHCPREQUEST-Paket ist, wird der „JA"-Zweig ganz rechts zu einem Entscheidungsblock 112 genommen, der testet, um zu sehen, ob das B-Flag des Pakets gesetzt ist. Die Funktion des B-Flags ist im RFC 1541 wie folgt definiert:
Ein Client, der keine Einsende-IP-Datagramme empfangen kann, bis seine Protokoll-Software mit einer IP-Adresse konfiguriert wurde, SOLLTE das BROADCAST- bzw. RUNDSENDE-Bit (B-Flag) in dem „Flags"-Feld bei einer DHCPDISCOVER- oder DHCPREQUEST-Nachricht, die der Client sendet, auf 1 setzen. Das B-Flag liefert einen Hinweis für den DHCP-Server und den BOOTP-Weiterleitagenten, alle Nachrichten an den Clienten auf dem Teilnetz des Clienten rundzusenden. Ein Client, der Einsende-IP-Datagramme empfangen kann, bevor seine Protokoll-Software konfiguriert wurde, SOLLTE das B-Flag-Bit auf 0 löschen. Ein Server oder Weiterleitagent, der eine DHCP-Nachricht direkt an einen DHCP-Clienten sendet oder weiterleitete (d. h. nicht an einen Weiterleitagenten, der in dem „GIADDR"-Feld spezifiziert ist), SOLLTE das B-Flag prüfen. Wenn das B-Flag auf 1 gesetzt ist, SOLLTE die DHCP-Nachricht als ein IP-Rundsenden unter Verwendung einer IP-Rundsendeadresse (vorzugsweise 255.255.255.255) als IP-Zieladresse, und der Verbindungsschicht-(Ethernet-)Rundsendeadresse als Verbindungsschicht-(Ethernet-)Zieladresse gesendet werden. Wenn das B-Flag auf 0 gelöscht ist, SOLLTE die Nachricht als ein IP-Rundsenden an die IP-Adresse, die in dem „YIADDR"-Feld spezifiziert ist, und die Verbindungsschicht-(Ethernet-)Adresse, die in dem „CHADDR"-Feld spezifiziert ist, gesendet werden. Wenn kein Einsenden möglich ist, KÖNNTE die Nachricht als ein IP-Rundsenden unter Verwendung einer IP-Rundsendeadresse (vorzugsweise 255.255.255.255) als IP-Zieladresse und der Verbindungsschicht-(Ethernet-)Rundsendeadresse als Verbindungsschicht-(Ethernet-)Zieladresse gesendet werden.
Einige Schalter sind in der Lage, sowohl Einsende- als auch Rundsendepakete einzufangen und zu verarbeiten. Ein Schalter dieses Typs könnte Blöcke 112 und 114 auslassen und das Paket bei Block 110, das B-Flag bei Block 110 gelöscht, senden. Andere Schalter sind jedoch nur in der Lage, Rundsendepakete oder Pakete, die direkt an eine Schalter-MAC-Adresse adressiert sind, einzufangen. Für einen Schalter dieses Typs ist es wichtig, dass alle Pakete, die bei dem Konfigurationsdialog beinhaltet sind, Ethernet-Rundsende pakete sind, so dass die CPU des Schalters in der Lage ist, die Pakete abzufangen.
Anfängliche DHCPDISCOVER- und DHCPREQUEST-Pakete sind typischerweise Ethernet-Rundsendepakete, da der Client üblicherweise die IP-Adresse des DHCP-Servers nicht kennt. Wenn der Client jedoch Einsende-IP-Diagramme vor einer Konfiguration mit einer IP-Adresse empfangen kann, könnte der Client das B-Flag setzen und der DHCP-Server könnte das B-Flag als einen Hinweis verwenden, wenn entschieden wird, wie Antworten an den Knoten übertragen werden. Wenn das Flag gelöscht wird, könnten DHCPOFFER-, DHCPACK- und DHCPNAK-Pakete einem Einsenden zurück zu dem Knoten unterzogen werden, wodurch nicht ermöglicht wird, dass der Agent 102 die Pakete abfängt, wenn der Schalter Einsendepakte nicht einfangen kann. Es ist wahrscheinlich, dass das B-Flag bereits gesetzt ist, da viele Knoten nicht in der Lage sind, Einsende-IP-Datagramme zu empfangen, bis sie mit einer IP-Adresse konfiguriert sind. Wenn das B-Flag gesetzt ist, wird der „JA"-Zweig zu Block 110 genommen, das Paket wird übertragen und eine Steuerung gelangt zu Block 106, um auf das nächste Paket zu warten. Wenn das Flag gelöscht ist, wird der „NEIN"-Zweig zu Block 114 genommen, das B-Flag des Pakets wird gesetzt und die Ethernet-Prüfsumme wird neu berechnet. Die Steuerung gelangt dann zu Block 110, das Paket wird übertragen und die Steuerung gelangt zurück zu Block 106, um auf das nächste Paket zu warten.
Zurückkehrend zu dem Entscheidungsblock 108 wird, wenn das Paket ein DHCPOFFER- oder DHCPACK-Paket ist, der untere „JA"-Zweig zu einem Block 116 genommen. Block 116 kopiert die in Frage kommende IP-Adresse aus dem YIADDR-Feld zu dem Vorgabe-Gateway-Feld in dem Optionenfeld, wodurch der Netzknoten konfiguriert wird, um sein eigener Gateway zu sein, und berechnet die Paketprüfsumme neu. Die Steuerung gelangt dann zu Block 110, das Paket wird übertragen und die Steuerung gelangt zurück zu Block 106, um auf das nächste Paket zu warten.
Ein Hauptvorteil dieses Ausführungsbeispiels der vorliegenden Erfindung besteht darin, dass es einfach in der Implementierung ist und wenig Mehraufwand erfordert. Dieses Ausführungsbeispiel besitzt jedoch einige kleinere Beschränkungen. In Bezug auf Schalter, die nicht in der Lage sind, Einsendepakete abzufangen, könnte, wenn der Konfiguration suchende Knoten die Adresse des DHCP-Servers kennt, der Knoten diese Adresse verwenden, um das DHCPDISCOVER- und DHCPREQUEST-Paket einem Einsenden zu unterziehen. Da die anfänglichen DHCP-Pakete nicht rundgesendet werden, sieht der schnüffelnde DHCP-Agent diese nicht und kann deshalb das B-Flag nicht setzen. Bei den meisten Implementierungen des DHCP-Protokolls jedoch kennt der Konfiguration suchende Knoten die Adresse des DHCP-Servers nicht, wodurch sichergestellt wird, dass die anfänglichen DHCP-Pakete nicht rundgesendet werden.
Eine ähnliche Schwierigkeit könnte auftreten, wenn ein Netzknoten die Miete auf seine IP-Adresse erneuern möchte. Da der Knoten die Adresse des DHCP-Servers kennt, unterzieht der Knoten typischerweise ein DHCPREQUEST-Paket einem Einsenden an den Server. Ein schnüffelnder DHCP-Agent, der sich auf einem Schalter befindet, der nicht in der Lage ist, Einsendepakete abzufangen, überträgt diese Nachricht direkt an den Server, ohne dass er die Gelegenheit besitzt, das B-Flag zu setzen. Da der Client mit einer IP-Adresse konfiguriert ist und deshalb in der Lage ist, ein Einsende-IP-Datagramm zu empfangen, löscht der Client sehr wahrscheinlich das B-Flag und der DHCP-Server spricht sehr wahrscheinlich mit Einsendenachrichten an. Der DHCP-Server könnte der modifizierten Vorgabe-Gateway-Adresse nicht zustimmen und könnte abbrechen oder könnte versuchen, die Vorgabe-Gateway-Adresse zu der Adresse wiederherzustellen, von der er glaubt, dass sie korrekt ist. Da die Nachrichten an den Clienten eingesendet werden, hat der schnüffelnde DHCP-Agent nicht die Gelegenheit, die Vorgabe-Gateway-Adresse zu modifizieren. Entsprechend könnte ohne ein Modifizieren des DHCP-Servers dieses Ausführungsbeispiel Schwierigkeit haben, eine dynamische Adresszuteilung auf Schaltern zu unterstützen, die nicht in der Lage sind, Einsendepakete abzufangen. Während der DHCP-Server modifiziert sein könnte, um den Vorgabe-Gateway zu verwenden, der durch den Clienten bereitgestellt wird, besteht einer der Hauptvorteile der vorliegenden Erfindung darin, dass sie mit DHCP-Servern des Stands der Technik funktioniert. Natürlich werden Schalter, die in der Lage sind, Einsendepakete abzufangen, nicht beeinflusst.
Ein weiterer kleinerer Nachteil besteht darin, dass ein Setzen des B-Flags bewirken könnte, dass der Netzwerkverkehr in Konfigurationen, die andernfalls das B-Flag gelöscht ließen, leicht zunimmt. Trotz dieser kleineren Nachteile stellt der schnüffelnde DHCP-Agent eine wirksame und leicht zu konfigurierende Lösung für viele Netzwerke bereit, bei der ein Netzwerkadministrator Knoten als ihre eigenen Gateways konfigurieren möchte, unter Verwendung eines automatischen Konfigurationsprotokolls des Stands der Technik, wie z. B. DHCP oder BOOTP.
Das zweite Ausführungsbeispiel der vorliegenden Erfindung leidet nicht unter diesen kleineren Nachteilen. 6 zeigt einen N-Port-Schalter 118 gemäß dem zweiten Ausführungsbeispiel der vorliegenden Erfindung. Jeder Port besitzt einen Eingangspfad zu einer Weiterleiteinheit 120 und einen Ausgangspfad, der einen Ausgangspuffer umfasst, wie z. B. Ausgangspuffer 122, 124, 126 und 128. Ferner umfasst die Weiterleiteinheit 120 einen DHCP-Proxy-Agenten 130. Der Proxy-Agent 130 ist konfiguriert, um für Konfiguration suchende Knoten als DHCP-Server 132 zu erscheinen. Zusätzlich ist der schnüffelnde DHCP/BOOTP-Weiterleitagent 134 des DHCP-Proxy-Agenten 130 konfiguriert, um für DHCP-Server als DHCP/BOOTP-Weiterleitagent zu erscheinen, wenn der DHCP-Server nicht auf dem gleichen Teilnetz ist. Wenn der zu konfigurierende Client und der DHCP-Server auf dem gleichen Teilnetz sind, funktioniert der schnüffelnde DHCP/BOOTP-Weiterleitagent 134 wie ein schnüffelnder Agent (ähnlich wie bei dem ersten Ausführungsbeispiel) für Pakete, die von dem DHCP-Server an den Clienten übertragen werden. Mit Ausnahme von dem, was unten erläutert wird, leitet die Weiterleiteinheit 120 Pakete in einer im Stand der Technik bekannten Art und Weise weiter.
Die 7–10 zusammengenommen sind ein Flussdiagramm 136, das darstellt, wie der DHCP-Proxy-Agent 130 Pakete verarbeitet. Bei einem Block 138 wird ein Paket empfangen. Die Steuerung gelangt dann zu einem Entscheidungsblock 140, der bestimmt, ob das Paket ein DHCPDISCOVER-, DHCPREQUEST-, DHCPOFFER-, DHCPACK- oder DHCPNAK-Paket ist, das einen Netzknoten spezifiziert, der als sein eigener Gateway konfiguriert werden soll. Ähnlich wie der oben beschriebene schnüffelnde DHCP-Agent 102 kann der Proxy-Agent 120 auch konfiguriert sein, um eine Tabelle von MAC-Adressen beizubehalten, die Netzknoten identifiziert, denen „geholfen" werden soll. Wenn das Paket keines dieser Pakete ist oder der Knoten nicht als „Hilfe" empfangend konfiguriert ist, wird der „NEIN"-Zweig zu einem Block 142 genommen, bei dem das Paket übertragen wird. Die Steuerung gelangt dann zu Block 138, um auf das nächste zu empfangende Paket zu warten. Es wird angemerkt, dass der DHCP-Proxy-Agent 130 konfiguriert ist, um alle Rundsendepakete, die in dem Konfigurationsdialog übertragen werden, zu empfangen. Zusätzlich empfängt, wenn bestimmte der Pakete von dem Clienten eingesendet werden, der Agent 130 auch diese Pakete, da der Konfiguration suchende Client glaubt, dass der Agent 130 sein DHCP-Server ist, wie unten detaillierter beschrieben ist.
Wenn das Paket ein DHCPDISCOVER- oder DHCPREQUEST-Paket ist, wird der „JA"-Zweig ganz rechts zu einem Entscheidungsblock 144 in 8 über eine Bezeichnung A genommen. Der Entscheidungsblock 144 bestimmt, ob das Paket ein DHCPREQUEST-Paket ist, das eine IP-Adresse in dem CIADDR-Feld umfasst. Wie oben in Tabelle 1 gezeigt ist, wird das CIADDR-Feld in einem DHCPREQUEST-Paket durch den Clientknoten ausgefüllt, wenn der Clientknoten zuvor zugeteilte Konfigurationsparameter verifizieren möchte. Dieser Prozess ist in der Technik als Mieterneuerung bekannt. Wenn das Paket ein DHCPREQUEST-Paket ist, das eine IP-Adresse in dem CIADDR-Feld umfasst, wird der „JA"-Zweig über eine Bezeichnung D zu einem Entscheidungsblock 145 in 10 genommen.
Der Entscheidungsblock 145 bestimmt, ob der DHCP-Server und der Schalter auf dem gleichen Teilnetz sind. Dies kann bestimmt werden, indem der DHCP-Proxy-Agent 130 durch einen DHCP-Server konfiguriert wird, oder der Schalter kann dynamisch über sein Vorliegen lernen, wenn er mögliche DHCP-Antworten empfängt. Wenn der DHCP-Server und der Schalter auf dem gleichen Teilnetz sind, gelangt die Steuerung zu einem Block 146. Block 146 greift zuerst auf eine Serverzuteilungstabelle zu. Die Serverzuteilungstabelle behält eine Entsprechung zwischen Clienten, die zuvor konfiguriert wurden, und den DHCP-Servern, die die Konfigurationsinformationen bereitstellen, bei. Es wird angemerkt, dass die Serverzuteilungstabelle in Netzen mit nur einem DHCP-Server nicht nötig ist. Einträge werden in der Tabelle gespeichert, wenn DHCPACK- und DHCPREQUEST-Pakete verarbeitet werden, wie unten beschrieben ist.
Block 146 gewinnt die Adresse des DHCP-Servers, der den Clienten konfiguriert hat, aus der Serverzuteilungstabelle wieder. Da der Server und der Client auf dem gleichen Teilnetz sind, kann die Adresse eine MAC-Adresse sein oder eine IP-Adresse, (die unter Verwendung des ARP in eine MAC-Adresse umgewandelt wird). Als Nächstes adressiert Block 146 das Paket an die MAC-Adresse des wiedergewonnenen DHCP-Servers um. Block 146 setzt dann das B-Flag (wenn nicht bereits gesetzt), wodurch sichergestellt wird, dass der DHCP-Server mit Rundsendenachrichten anspricht, die abgefangen werden, in einer Art und Weise, die dem ersten oben beschriebenen Ausführungsbeispiel ähnelt. Schließlich wird die Paketprüfsumme neu berechnet und die Steuerung gelangt über eine Bezeichnung C zurück zu Block 142 in 7.
Zurückkehrend zu dem Entscheidungsblock 145 in 10 gelangt, wenn der DHCP-Server und der Schalter nicht auf dem gleichen Teilnetz sind, die Steuerung zu einem Block 147. Wie oben greift Block 147 auf die Serverzuteilungstabelle zu und gewinnt die IP-Adresse des DHCP-Servers, der den Clienten konfiguriert hat, gemeinsam mit der Vorgabe-Gateway-Adresse, die durch den Server bereitgestellt wird, wieder. Block 147 adressiert dann das Paket an die IP-Adresse des DHCP-Servers um, fügt die IP-Adresse des DHCP-Proxy-Agenten 130 zu dem GIADDR-Feld hinzu, löscht das B-Flag (wenn nicht bereits gelöscht) und berechnet die Prüfsumme neu. Durch ein Hinzufügen der IP-Adresse des DHCP-Proxy-Agenten 130 zu dem GIADDR-Feld und ein Löschen des B-Flags erscheint der Agent 130 für den DHCP-Server wie ein DHCP/BOOTP-Weiterleitagent und Rückgabepakete werden zurück an den Agenten 130 eingesendet. Die Steuerung gelangt dann über die Bezeichnung C zurück zu Block 142 in 7, wo das Paket über den Vorgabe-Gateway des DHCP-Proxy-Agenten 130 an den DHCP-Server übertragen wird. Die Steuerung gelangt dann zu Block 138, um auf das nächste Paket zu warten.
Zurückkehrend zu dem Entscheidungsblock 144 in 8 wird, wenn das Paket kein DHCPREQUEST-Paket ist, das eine IP-Adresse in dem CIADDR-Feld umfasst, der „NEIN"-Zweig zu einem Entscheidungsblock 148 genommen. Der Entscheidungsblock 148 bestimmt, ob das Paket ein DHCPREQUEST-Paket ist (das natürlich keine Adresse in dem CIADDR-Feld hätte, da, falls dies der Fall wäre, der „JA"-Zweig bei dem Entscheidungsblock 144 genommen würde) oder ein DHCPDISCOVER-Paket ist. Wenn es ein DHCPREQUEST-Paket ist, beinhaltet das Paket Parameter, die durch den Konfiguration suchenden Knoten angefordert wurden, und der „DHCPREQUEST"-Paket-Zweig zu einem Block 150 wird genommen. Block 150 aktualisiert die Serverzuteilungstabelle mit der vorgeschlagenen Netzknoten-Zu-DHCP-Serverabbildung. Diese Tabelle wird verwendet, wenn der Client seine Miete auf eine IP-Adresse über ein DHCPREQUEST-Paket erneuern möchte, wie oben unter Bezugnahme auf die 8 und 10 erläutert wurde. Die Steuerung gelangt dann zu einem Entscheidungsblock 152. Zurückkehrend zu dem Entscheidungsblock 148 gelangt, wenn das Paket ein DHCPDISCOVER-Pakete ist, die Steuerung ebenso über den „DHCPDISCOVER"-Paket-Zweig zu dem Entscheidungsblock 152.
Der Entscheidungsblock 152 bestimmt, ob der DHCP-Server und der Schalter auf dem gleichen Teilnetz sind. Dies kann bestimmt werden, wie oben unter Bezugnahme auf Schritt 145 in 10 beschrieben wurde. Wenn der Schalter und der DHCP-Server nicht auf dem gleichen Teilnetz sind, wird der „NEIN"-Zweig zu einem Block 154 genommen. Block 154 fügt die IP-Adresse des DHCP-Proxy-Agenten 130 in das GIADDR-Feld ein, wodurch der Agent 130 für den DHCP-Server wie ein DHCP/BOOTP-Weiterleitagent erscheint. Block 30 löscht dann das B-Flag (wenn nicht bereits gelöscht), wodurch eine Einsendeübertragung angefordert wird. Dies bewahrt Netzwerkbandbreite. Als Nächstes wird das Paket mit der IP-Adresse eines DHCP-Servers adressiert. Da der Agent 130 wie ein DHCP/BOOTP-Weiterleitagent in Bezug auf den teilnetzexternen DHCP-Server wirkt, könnte der Agent 130 die gleichen Techniken des Stands der Technik verwenden, um Listen verfügbarer DHCP-Server beizubehalten, wie z. B. manuelle Konfiguration von DHCP-Server-Adressen oder dynamisches Entdecken von DHCP-Servern durch ein Prüfen von Antwortpaketen. Schließlich wird die Paketprüfsumme neu berechnet und die Steuerung gelangt über die Bezeichnung C zurück zu Block 142 in 7, wo das Paket über den Vorgabe-Gateway des Agenten 130 übertragen wird. Die Steuerung gelangt dann zu Block 138, um auf das nächste Paket zu warten.
Zurückkehrend zu dem Entscheidungsblock 152 wird, wenn der DHCP-Server und der Schalter auf dem gleichen Teilnetz sind, der „JA"-Zweig zu einem Block 156 genommen. Block 156 setzt das B-Flag, wodurch eine Rundsendeübertragung von dem DHCP-Server angefordert wird, und berechnet die Prüfsumme neu, wenn das B-Flag gelöscht wurde. Die Steuerung gelangt dann über die Bezeichnung C zurück zu Block 142 in 7, wo das Paket übertragen wird. Dann gelangt die Steuerung zu Block 138, um auf das nächste Paket zu warten.
Zurückkehrend zu dem Entscheidungsblock 140 in 7 wird, wenn das Paket ein DHCPOFFER-, DHCPACK- oder DHCPNAK-Paket aus einem Netzwerk ist, das als „Hilfe" empfangend konfiguriert ist, der untere „JA"-Zweig zu einem Entscheidungsblock 158 in 9 über eine Bezeichnung B genommen. Block 158 bestimmt, ob das Paket ein DHCPACK-Paket ist. Falls dies der Fall ist, beinhaltet das Paket Konfigurationsinformationen und der „JA"-Zweig zu einem Block 160 wird genommen, der die Serverzuweisungstabelle mit der Netzknoten-Zu-DHCP-Server-Abbildung aktualisiert, ähnlich wie bei Schritt 150 in 8. Die Steuerung gelangt dann zu einem Block 162. Zusätzlich gelangt, wenn das Paket kein DHCPACK-Paket ist, die Steuerung auch zu Block 162.
Block 162 kopiert die IP-Adresse des DHCP-Proxy-Agenten 132 in das SIADDR-Feld, wodurch bewirkt wird, dass der Konfiguration suchende Netzknoten den Agenten 132 als seinen DHCP-Server behandelt. Block 162 löscht dann das GIADDR-Feld, so dass der Agent 132 für den Clientknoten nicht als ein DHCP/BOOTP-Weiterleitagent erscheint. Als Nächstes wird die in Frage kommende IP-Adresse aus dem YIADDR-Feld in das Vorgabe-Gateway-Feld in dem Optionenfeld kopiert, wodurch der Knoten als sein eigener Gateway konfiguriert wird. Schließlich wird die Paketprüfsumme neu berechnet und die Steuerung gelangt über die Bezeichnung C wieder zurück zu Block 142 in 7, wo das Paket an den zu konfigurierenden Clienten übertragen wird. Dann gelangt die Steuerung zu Block 138, um auf das nächste Paket zu warten.
Das zweite Ausführungsbeispiel der vorliegenden Erfindung stellt eine umfassende Lösung für Netzadministratoren bereit, die DHCP-Server des Stands der Technik beibehalten möchten, während außerdem alle Aspekte des DHCP-Nachrichtendialogs, einschließlich Mieterneuerung und Einsendeübertragungen, unterstützt werden. Zusätzlich ist das zweite Ausführungsbeispiel der vorliegenden Erfindung vollständig funktionsfähig, wenn es mit Schaltern verwendet wird, die in der Lage sind, nur Rundsendepakete abzufangen.
Durch ein Ermöglichen, dass ein Netzknoten automatisch als sein eigener Gateway konfiguriert werden kann, ermöglichen es beide Ausführungsbeispiele der vorliegenden Erfindung einem Netzwerkadministrator, ein Netzwerk zu erweitern, indem Schalter und Brücken hinzugefügt werden, während eine automatische Konfiguration beibehalten wird, und ohne einen zu Routern gerouteten Verkehr wesentlich zu erhöhen. Schalter und Brücken sind viel schneller und weniger teuer als Router, so dass die vorliegende Erfindung einen Netzwerkadministrator mit der Gelegenheit schafft, die Kosten einer Erweiterung eines Netzwerks zu minimieren, die Geschwindigkeit des Netzwerks zu maximieren und eine automatische Konfiguration beizubehalten.
Im Stand der Technik hatte ein Netzwerkadministrator drei Wahlmöglichkeiten beim Erweitern eines Netzwerks durch Hinzufügen von Brücken oder Schaltern. Erstens konnte der Administrator die Teilnetzmaske verändern. Diese Wahlmöglichkeit erlaubte eine automatische Konfiguration, IP-Adressen jedoch mussten in Potenzen von Zwei zu dem Teilnetz hinzugefügt werden, was oft nicht praktisch ist. Zweitens konnte der Netzwerkadministrator manuell jeden Clienten konfigurieren, um sein eigener Vorgabe-Gateway zu sein, was keine sehr ansprechende Aussicht ist, wenn der Administrator bereits die Kosten eines Einrichtens eines automatischen Konfigurationsprotokolls, wie z. B. von DHCP, auf sich genommen hat. Schließlich konnte der Netzwerkadministrator Router verwenden, die teuer und langsam sind. Die vorliegende Erfindung stellt eine vierte Wahlmöglichkeit bereit. Gemäß der vorliegenden Erfindung ermöglicht es ein Konfigurationsagent, dass ein beliebiges Inkrement von IP-Adressen zu einem Teilnetz hinzugefügt werden kann, ohne eine manuelle Konfiguration durchführen zu müssen und ohne auf Router zurückgreifen zu müssen.
Obwohl die vorliegende Erfindung unter Bezugnahme auf bevorzugte Ausführungsbeispiele beschrieben wurde, werden Fachleute auf dem Gebiet erkennen, dass Veränderungen an Form und Detail vorgenommen werden könnten, ohne von der Wesensart und dem Schutzbereich der Erfindung abzuweichen.

Claims

Ein Verfahren zum Konfigurieren eines Clienten (86), um sein eigener Vorgabe-Gateway zu sein, das folgende Schritte aufweist: Abfangen einer Nachricht (108), die Teil eines Konfigurationsdialogs zwischen einem Konfigurationsserver und einem Clienten ist, wobei die Nachricht eine Vorgabe-Gateway-Adresse umfasst, die durch einen Clienten verwendet werden wird oder gerade verwendet wird; Modifizieren der Vorgabe-Gateway-Adresse in der Nachricht, um eine Adresse des Clienten (116) zu sein; und Senden (110) der Nachricht.
Das Verfahren gemäß Anspruch 1, bei dem die Nachricht eine Anbieten-Nachricht ist.
Das Verfahren gemäß Anspruch 1, bei dem die Nachricht eine Bestätigen-Nachricht ist.
Das Verfahren gemäß Anspruch 1, bei dem: das Abfangen einer Nachricht folgenden Schritt aufweist: Empfangen der Nachricht von dem Server; und das Senden der Nachricht folgenden Schritt aufweist: Senden der Nachricht an den Clienten.
Das Verfahren gemäß Anspruch 1, bei dem das Modifizieren der Vorgabe-Gateway-Adresse folgende Schritte aufweist: Kopieren einer in Frage kommenden Netzadresse, die als die Netzadresse des Clienten verwendet werden wird oder gerade verwendet wird, von einem Client-Netzadressfeld der Nachricht; und Speichern der in Frage kommenden Adresse in einem Vorgabe-Gateway-Adressfeld der Nachricht.
Das Verfahren gemäß Anspruch 5, das ferner folgenden Schritt aufweist: Neuberechnen einer Prüfsumme, die der Nachricht zugeordnet ist.
Das Verfahren gemäß Anspruch 1, das ferner folgende Schritte aufweist: Abfangen einer Entdecken-Nachricht oder einer Anfordern-Nachricht, die Teil des Konfigurationsdialogs zwischen einem Konfigurationsserver und einem Clienten ist; Prüfen der Entdecken-Nachricht oder der Anfordern-Nachricht, um zu bestimmen, ob ein Rundsendeflag der Entdecken-Nachricht oder der Anfordern-Nachricht gesetzt ist; Setzen des Rundsendeflags, wenn das Rundsendeflag nicht gesetzt war; Neuberechnen einer Prüfsumme, die der Entdecken-Nachricht oder der Anfordern-Nachricht zugeordnet ist; und Senden der Entdecken-Nachricht oder der Anfordern-Nachricht.
Das Verfahren gemäß Anspruch 1, das ferner folgenden Schritt aufweist: Speichern einer Netzadresse des Konfigurationsagenten in ein Konfigurationsserveradressfeld der Nachricht.
Das Verfahren gemäß Anspruch 1, das ferner folgende Schritte aufweist: Bestimmen, ob die Nachricht eine Bestätigen-Nachricht ist; und Speichern eines Eintrags in einer Serverzuteilungstabelle, die den Clienten und den Konfigurationsserver korreliert, wenn die Nachricht eine Bestätigen-Nachricht ist.
Das Verfahren gemäß Anspruch 1, das ferner folgende Schritte aufweist: Abfangen einer Anfordern-Nachricht, die eine Netzadresse umfasst, für die der Client eine Miete erneuern möchte; Neuadressieren der Anfordern-Nachricht an eine Adresse des Konfigurationsservers; und Senden der Anfordern-Nachricht an den Konfigurationsserver.
Das Verfahren gemäß Anspruch 10, das ferner folgende Schritte aufweist: Bestimmen, ob der Konfigurationsagent und der Konfigurationsserver auf dem gleichen Teilnetz sind; wenn der Konfigurationsagent und der Konfigurationsserver auf dem gleichen Teilnetz sind; Setzen eines Rundsendeflags der Anfordern-Nachricht, wenn das Rundsendeflag nicht gesetzt ist; und Neuberechnen einer Prüfsumme, die der Anfordern-Nachricht zugeordnet ist; wobei das Neuadressieren der Anfordern-Nachricht an eine Adresse des Konfigurationsservers ein Neuadressieren einer Hardware-Adresse der Anfordern-Nachricht an eine Hardware-Adresse des Konfigurationsservers aufweist; und wenn der Konfigurationsagent und der Konfigurationsserver nicht auf dem gleichen Teilnetz sind; Löschen eines Rundsendeflags der Anfordern-Nachricht, wenn das Rundsendeflag nicht gelöscht ist; Speichern einer Netzadresse des Konfigurationsagenten in einem Weiterleit-Agentenfeld der Anfordern-Nachricht; und Neuberechnen einer Prüfsumme, die der Anfordern-Nachricht zugeordnet ist; wobei das Neuadressieren der Anfordern-Nachricht an eine Adresse des Konfigurationsservers ein Neuadressieren einer Netzadresse der Anfordern-Nachricht an eine Netzadresse des Konfigurationsservers aufweist.
Das Verfahren gemäß Anspruch 10, bei dem das Neuadressieren der Anfordern-Nachricht an eine Adresse des Konfigurationsservers folgende Schritte aufweist: Zugreifen auf eine Serverzuteilungstabelle, um eine Adresse eines Konfigurationsservers, die dem Client zuvor zugeordnet wurde, zu bestimmen; Neuadressieren der Anfordern-Nachricht an die Adresse eines Konfigurationsservers, die dem Client zuvor zugeordnet wurde.
Das Verfahren gemäß Anspruch 1, das ferner folgende Schritte aufweist: Abfangen einer Entdecken-Nachricht oder einer Anfordern-Nachricht, die Teil des Konfigurationsdialogs zwischen dem Konfigurationsserver und dem Clienten ist; Bestimmen, ob der Konfigurationsagent und der Konfigurationsserver auf dem gleichen Teilnetz sind; wenn der Konfigurationsagent und der Konfigurationsserver auf dem gleichen Teilnetz sind; Setzen eines Rundsendeflags der Entdecken-Nachricht oder der Anfordern-Nachricht, wenn das Rundsendeflag nicht gesetzt ist; Neuberechnen einer Prüfsumme, die der Entdecken-Nachricht oder der Anfordern-Nachricht zugeordnet ist; und Senden der Entdecken-Nachricht oder der Anfordern-Nachricht; wenn der Konfigurationsagent und der Konfigurationsserver nicht auf dem gleichen Teilnetz sind; Löschen eines Rundsendeflags der Entdecken-Nachricht oder der Anfordern-Nachricht, wenn das Rundsendeflag nicht gelöscht ist; Speichern einer Netzadresse des Konfigurationsagenten in einem Weiterleit-Agentenfeld der Entdecken-Nachricht oder der Anfordern-Nachricht; Neuberechnen einer Prüfsumme, die der Entdecken-Nachricht oder der Anfordern-Nachricht zugeordnet ist; und Senden der Entdecken-Nachricht oder der Anfordern-Nachricht.
Eine Netzvorrichtung (76), die folgende Merkmale aufweist: einen ersten Port, der mit einem Konfigurationsserver gekoppelt ist, der in der Lage ist, einen Clienten mit einer Vorgabe-Gateway-Adresse zu konfigurieren; einen zweiten Port, der mit einem Clienten gekoppelt ist, der mit einer Vorgabe-Gateway-Adresse konfiguriert werden möchte; eine Weiterleitungseinheit (100), die zwischen den ersten und den zweiten Port geschaltet ist, zum Weiterleiten von Paketen zwischen dem ersten und dem zweiten Port, wobei die Weiterleitungseinheit folgendes Merkmal umfasst: einen Konfigurationsagenten, der ein Konfigurationspaket abfängt, das Teil eines Konfigurationsdialogs zwischen dem Konfigurationsserver und dem Clienten ist, wobei das Konfigurationspaket eine Vorgabe-Gateway-Adresse beinhaltet, die durch den Clienten verwendet werden soll, und der Konfigurationsagent die Vorgabe-Gateway-Adresse modifiziert, um eine Netzadresse des Clienten zu sein, und das Konfigurationspaket sendet.
Die Netzvorrichtung gemäß Anspruch 14, bei der das Konfigurationspaket eine Anbieten-Nachricht umfasst.
Die Netzvorrichtung gemäß Anspruch 14, bei der das Konfigurationspaket eine Bestätigen-Nachricht umfasst.
Die Netzvorrichtung gemäß Anspruch 14, bei der der Konfigurationsagent das Konfigurationspaket abfängt, indem er das Konfigurationspaket von dem Konfigurationsserver an dem ersten Port empfängt, und das Konfigurationspaket sendet, indem er das Konfigurationspaket an dem zweiten Port an den Clienten sendet.
Die Netzvorrichtung gemäß Anspruch 14, bei der der Konfigurationsagent die Vorgabe-Gateway-Adresse modifiziert, um durch den Client verwendet zu werden, indem er eine in Frage kommende Netzadresse, die als die Netzadresse des Clienten verwendet werden wird oder gerade verwendet wird, von einem Client-Netzadressfeld des Konfigurationspakets kopiert und die in Frage kommende Adresse in einem Vorgabe-Gateway-Adressfeld des Konfigurationspakets speichert.
Die Netzvorrichtung gemäß Anspruch 14, bei der der Konfigurationsagent eine Prüfsumme, die dem Konfigurationspaket zugeordnet ist, vor einem Senden des Konfigurationspakets neu berechnet.
Die Netzvorrichtung gemäß Anspruch 14, bei der der Konfigurationsagent außerdem ein Paket abfängt, das eine Entdecken-Nachricht oder eine Anfordern-Nachricht umfasst, die Teil des Konfigurationsdialogs zwischen einem Konfigurationsserver und einem Clienten ist, die Entdecken-Nachricht oder die Anfordern-Nachricht prüft, um zu bestimmen, ob ein Rundsendeflag der Entdecken-Nachricht oder der Anfordern-Nachricht gesetzt ist, das Rundsendeflag setzt, wenn das Rundsendeflag nicht gesetzt war, eine Prüfsumme, die dem Paket zugeordnet ist, neu berechnet und das Anfordern-Paket sendet.
Die Netzvorrichtung gemäß Anspruch 14, bei der der Konfigurationsagent außerdem eine Netzadresse des Konfigurationsagenten in ein Konfigurationsserveradressfeld des Konfigurationspakets speichert.
Die Netzvorrichtung gemäß Anspruch 14, bei der der Konfigurationsagent außerdem bestimmt, ob das Konfigurationspaket eine Bestätigen-Nachricht umfasst, und einen Eintrag in einer Server-Zuteilungstabelle speichert, der den Clienten und den Konfigurationsserver korreliert, wenn das Konfigurationspaket eine Bestätigen-Nachricht umfasst.
Die Netzvorrichtung gemäß Anspruch 14, bei der der Konfigurationsagent außerdem ein Paket abfängt, das eine Anfordern-Nachricht umfasst, die eine Netzadresse beinhaltet, für die der Client eine Miete erneuern möchte, das Paket an eine Adresse des Konfigurationsservers neu adressiert und das Paket an den Konfigurationsserver sendet.
Die Netzvorrichtung gemäß Anspruch 23, bei der der Konfigurationsagent auch bestimmt, ob der Konfigurationsagent und der Konfigurationsserver auf dem gleichen Teilnetz sind, und wenn der Konfigurationsagent und der Konfigurationsserver auf dem gleichen Teilnetz sind, der Konfigurationsagent ein Rundsendeflag der Anfordern-Nachricht setzt, wenn das Rundsendeflag nicht gesetzt ist, und eine Prüfsumme, die dem Paket zugeordnet ist, neu berechnet, wobei das Paket an eine Hardwareadresse des Konfigurationsservers neu adressiert wird, und wenn der Konfigurationsagent und Konfigurationsserver nicht auf dem gleichen Teilnetz sind, der Konfigurationsagent ein Rundsendeflag der Anfordern-Nachricht löscht, wenn das Rundsendeflag nicht gelöscht ist, eine Netzadresse des Konfigurationsagenten in einem Weiterleit-Agentenfeld der Anfordern-Nachricht speichert und eine Prüfsumme, die dem Paket zugeordnet ist, neu berechnet, wobei das Paket an eine Netzadresse des Konfigurationsservers neu adressiert wird.
Die Netzvorrichtung gemäß Anspruch 23, bei der der Konfigurationsagent das Paket an eine Adresse des Konfigurationsservers neu adressiert, indem er auf eine Serverzuteilungstabelle zugreift, um eine Adresse eines Konfigurationsservers, die dem Clienten zuvor zugeordnet wurde, zu bestimmen, und indem er das Paket an die Adresse eines Konfigurationsservers neu adressiert, die dem Clienten zuvor zugeordnet wurde.
Die Netzvorrichtung gemäß Anspruch 14, bei der der Konfigurationsagent außerdem ein Paket abfängt, das eine Entdecken-Nachricht oder eine Anfordern-Nachricht umfasst, die Teil des Konfigurationsdialogs zwischen dem Konfigurationsserver und dem Clienten ist, und bestimmt, ob der Konfigurationsagent und der Konfigurationsserver auf dem gleichen Teilnetz sind, und wenn der Konfigurationsagent und der Konfigurationsserver auf dem gleichen Teilnetz sind, der Konfigurationsagent ein Rundsendeflag der Entdecken-Nachricht oder der Anfordern-Nachricht setzt, wenn das Rundsendeflag nicht gesetzt ist, eine Prüfsumme, die dem Paket zugeordnet ist, neu berechnet und das Paket sendet, und wenn der Konfigurationsagent und der Konfigurationsserver nicht auf dem gleichen Teilnetz sind, der Kon figurationsagent ein Rundsendeflag der Entdecken-Nachricht oder der Anfordern-Nachricht löscht, wenn das Rundsendeflag nicht gelöscht ist, eine Netzadresse des Konfigurationsagenten in einem Weiterleit-Agentenfeld der Entdecken-Nachricht oder der Anfordern-Nachricht speichert, eine Prüfsumme, die dem Paket zugeordnet ist, neu berechnet und das Paket sendet.