Thema Segmentierung von Netzen in der Berufsschule

Torben schrieb:
> Der
> Punkt Abgeschlossene Segmente gehört doch zur Übersicht

Nein. Du kannst ja an den Netzübergängen den Datenverkehr beeinflussen 
(Firewall), und damit verhindern, dass x-beliebige Teilnehmer Zugriff 
auf bestimmte Bereiche bekommen, oder aber verhindern, dass die Leute in 
der Produktion „surfen“, während die Entwicklung ganz gewiss vollen 
Zugriff auf das Internet braucht.

Das würde ohne Unterteilung nicht machbar sein.

Seit 802.1q muss das dabei nicht einmal mehr in allen Fällen physisch 
unterteilt werden: ein physisches Netzwerkinterface am Firewall kann da 
durchaus mehrere verschiedene Netze verwalten; die Aufteilung auf die 
Zugangspunkte („Steckdosen“) erfolgt dann im Switch.

> und die
> Kollisionsgefahr kann doch innerhalb eines Segmentes trotzdem sehr hoch
> sein jenachdem, welche Standards dort verbaut sind.

Natürlich kann man immer pathologische Fälle bauen – aber ohne 
Unterteilung ist sie zwangsweise auf jeden Fall höher.

Seit Netze nicht mehr nur durch dumme Repeater verbunden werden sondern 
durch Switche, reduziert sich zwar die Kollisionsgefahr insgesamt, aber 
insbesondere in Umgebungen mit vielen Broadcasts reduziert eine 
Unterteilung das „Geblubber“.

Der Begriff "Segmentierung" bezieht sich heute oft auf durch Firewalls 
abgetrennte Netzbereiche. Was nicht zwangsläufig eine Trennung auf Layer 
3+ bedeutet, also auf Routing-Ebene, denn man kann eine Firewall auch 
auf Layer 2 betreiben - auf beiden Seiten der Firewall hat man dann das 
gleiche IP-Netz.

Torben schrieb:
> Leider kann ich die Punkte nicht nachvollziehen. Ob ein Netzwerk
> übersichtlich oder sicher ist, hängt doch nicht davon ab, ob ich es
> segmentiere.

Die Segmentierung macht aber die Dokumentation schon einfacher. Wenn Du 
weißt das dieses Netzsegment mit jenen IPs nur für die Entwicklung ist, 
dort nur folgende Server drin erreichbar sind etc. ist es klarer und 
eindeutiger, als wenn das mit anderen Abteilungen vermischt und 
hinterher nur auf der Firewall in vielen vielen Regeln erkennbar ist.

Durch die Segmentierung wird die Dokumentation einfacher, 
übersichtlicher und schneller verständlich.

Du musst dabei auch nicht nur Dich selbst oder Deine Kollegen im Blick 
haben, sondern auch z.B. andere Firmen und deren Mitarbeiter. Sagen wir 
mal eine andere Firma ist für die TK-Anlage, die Drucker, die Wawi oder 
wasauchimmer zuständig, Du musst denen erklären wie das Netz aufgebaut 
ist und wo und wie die ihren Kram einzurichten haben.

Desto einfacher und schneller das verständlich ist, desto schneller 
verstehen die das, desto weniger Ärger hast Du mit denen und desto 
weniger Fehler passieren durch Unwissen oder Verständnisschwierigkeiten.

Torben schrieb:
> Mein Lehrer sagt nun außerdem, dass eine Subnetzbildung ohne Router
> nicht möglich ist.

Wenn auf jegliche Kommunikation nach außerhalb des Subnetzes verzichtest 
geht das auch.

> Ein Router ist doch aber dafür da, Pakete aus dem einen Netz in ein
> anderes weiterzuleiten. Demzufolge können doch Benutzer des einen Netzes
> Pakete in ein anderes Subnetz schicken, wenn man mal den Aspekt der
> Firewall vernachlässigt.
>
> Wo ist dann der Vorteil von Subnetting?

Eigene Broadcast-Domäne unter anderem

Torben schrieb:
> Mein Lehrer sagt nun außerdem, dass eine Subnetzbildung ohne Router
> nicht möglich ist.

Wobei ein Layer 3 Switch in diesem Sinn ein Router ist. Allerdings muss 
Subnetzbildung nichts mit Segmentierung zu tun haben.

> Wo ist dann der Vorteil von Subnetting?

Wenn einem Unternehmen im Internet ein IP-Bereich 1.2.3.4/23 zugeordnet 
ist, dann kann dieses Unternehmen daraus mehrere Subnetze für 
verschiedene Aufgaben bauen, muss nicht alle 500 Server ins gleiche Netz 
packen.

Ebenso müssen intern nicht alle 5000 PCs und Server ins gleiche 
10.0.0.0/8, sondern es können viele 10.0.0.0/24 Netze genutzt werden. 
Abteilungen, Stockwerke, Standorte, Funktionen, ...

Torben schrieb:

> Mein Lehrer sagt nun außerdem, dass eine Subnetzbildung ohne Router
> nicht möglich ist.

Richtig.

> Ein Router ist doch aber dafür da, Pakete aus dem einen Netz in ein
> anderes weiterzuleiten.

Ja – da ist kein Unterschied zur vorherigen Aussage. Beides ist exakt 
das gleiche.

> Demzufolge können doch Benutzer des einen Netzes
> Pakete in ein anderes Subnetz schicken, wenn man mal den Aspekt der
> Firewall vernachlässigt.

Den kannst du 1.) nicht vernachlässigen, und 2.) ignorierst du nach wie 
vor das Detail der broadcast domain, die durch die Unterteilung 
eingeschränkt wird.

> Wo ist dann der Vorteil von Subnetting?

Du theoretisierst unnütz herum.

Es gibt ohnehin praktisch kein "Subnetting" mehr in dem Sinne: es gibt 
einfach IP-Netzwerke, bestehend aus Netzerkadresse und Netzmaske. Das 
Wort "Sub" stammt aus der Zeit der klassenbehafteten Netze, als man das 
Internet noch so schön als Klasse A, B oder C eingeteilt hat. Innerhalb 
dieser Klassen war es dann vor allem bei A und B üblich, "Subnetze" 
einzuteilen, wobei im ursprünglichen Ansatz noch die Netzmaske aller 
Subnetze gleich war.

Heutzutage reichen die öffentlichen IP(v4)-Adressen sowieso nicht mehr, 
um alle am Internet hängenden Geräte zu adressieren. Mit RFC1918 wurden 
spezielle Netzbereiche reserviert, die nur intern benutzt werden und im 
Internet nicht geroutet werden sollen.

Wenn du also heute irgendein Netzwerk aufbaust, vergibst du in 99 % der 
Fälle sowieso nur Adressen aus diesen Bereichen. Dabei legst du die 
Netzwerke so an, wie sie administrativ oder organisatorisch zusammen 
gehören, überlegst dir, wer vorrangig mit wem kommunizieren soll. Wenn 
dabei mehrere Netze entstehen, laufen die in der Regel dann sowieso 
gemeinsam auf dem Firewall auf, der zugleich zwischen den Netzen routet.

Jörg W. schrieb:
> Es gibt ohnehin praktisch kein "Subnetting" mehr in dem Sinne:

Subnetting wäre beispielsweise, wenn ein Konzern die gesamte interne 
Netzstruktur vereinheitlicht und für jedes halbwegs autonom arbeitende 
Tochterunternehmen U ein Netz 10.U.x.x/16 definiert. Ein solches 
Tochterunternehmen 17 kann dann wiederum diverse Netze 10.17.N.x/24 
verwenden.

Die Realität ist wohl eher ein Sammelsurium überlappender Netze, weil 
zusammengekaufte Unternehmen das vorher jeweils nach Laune definierten 
und man damit erst einmal leben muss. Im Ergebnis ist konzernweite 
Kommunikation dann eine üble NAT-Orgie.

> Internet noch so schön als Klasse A, B oder C eingeteilt hat.

Wobei ich bei diesem Beispiel nur deshalb eine Klassen-artige Aufteilung 
verwende, weil es andernfalls in dezimaler IP-Schreibweise beschissen 
aussieht.

Torben schrieb:
> So wie es aussieht machen wir auch kein ipv6 :)

Schlecht. Sowas sollte man in heutiger Zeit natürlich auf jeden Fall 
schon mal gehört haben.

Ist eigentlich auch nicht wirklich schlimm: die Adressen sind halt 128 
Bit statt 32 Bit breit, oder 16 statt 4 Byte. Damit die Adresse noch 
lesbar bleibt, wird sie nicht dezimal byteweise (wie bei IPv4) sondern 
hexadezimal 2-byte-weise aufgeschrieben, also 8 Gruppen zu je 2 Byte (4 
Hexadezimalstellen), getrennt durch Doppelpunkte.

Prinzipiell könnte man natürlich auch IPv4-Adressen hexadezimal 
schreiben, also statt 192.168.1.2 c0.a8.1.2. Das ist nur nicht üblich.

Eine typische IPv6-Adresse sieht dann so aus:

1

2a01:db8:4a5:33f2:a021:3301:4a:2f03

Innerhalb der Viergruppen werden führende Nullen weggelassen, also db8 
ist die Kurzform für 0db8, 4a steht für 004a. Blöcke, die komplett 
zusammenhängend aus Nullen bestehen, können weggelassen werden:

1

2a01:db8:4a5:33f2::1

Ist also die Kurzform für

1

2a01:db8:4a5:33f2:0:0:0:1

Das ist besonders bei fest vergebenen Serveradressen üblich.

Die Netzmaske wird wie bei CIDR mit einem Schrägstrich angehängt, wobei 
ein /64 die kleinste übliche Maske ist (also 2^64 Bits für die Hosts im 
Netz). "Nach oben" können dann mehrere solche /64-Blöcke zusammengefasst 
werden, meist in 8er Schritten. Du bekommst also von deinem Provider 
typischerweise eine /56-Zuweisung, das sind 256 Netze zu je /64. Dein 
Provider wiederum fasst 256 solcher Blöcke zu einem /48 zusammen etc.

Damit man die Doppelpunkte der Adresse von anderen Doppelpunkten 
(Portnummer) unterscheiden kann, werden in URLs die IPv6-Adressen in 
eckige Klammern gesetzt:

1

http://[2a01:db8:4a5:33f2:0:0:0:1]:8080/

bezeichnet damit einen HTTP-Server, der auf der genannten 
Beispieladresse auf Port 8080 (der ist dann wieder dezimal) hört.

Hier mal ein reales Beispiel. :-)

1

http://[2a00:1450:4001:815::2003]/

Fehlanzeige schrieb:
> Und schon ist man das widerliche Zeug los.

Vogel-Strauß-Mentalität?

Kann man machen. Wenn man kurz vor der Rente ist, und eine 
„Nach-mir-die-Sintflut“-Politik ansetzt. Der TE scheint jedoch in der 
Ausbildung zu sein, dann ist so eine Variante kaum zielführend.

Fehlanzeige schrieb:
>> kurz vor der Rente ist
>
> Das ist die Default-Policy aller Unternehmen die mir bis jetzt
> untergekommen sind!

Nur, weil alle Unternehmen, die dir bislang untergekommen sind, offenbar 
unfähige (oder unwillige) Admins haben, macht das die Sache kaum besser.

Übrigens: angenehmer Nebeneffekt des großen Adressraums: Portscans gibt 
es praktisch nicht mehr. Auf meinen IPv6-only Servern vermisse ich 
(nicht :) die vielen dümmlichen Port-22-Scan-Versuche – obwohl diese 
Server mit ihrem Port 22 genauso am öffentlichen Netz hängen wie die, 
die auch eine IPv4-Adresse haben.

Es ist schier unmöglich, über so viele Adressen erschöpfende Portscans 
zu fahren. Wenn man für alle Adressen eines üblichen /64-Netzes pro 
Adresse 30 ms braucht (das impliziert schon eine explizite Ablehnung des 
Verbindungsversuchs, statt dass der andere das Paket verwirft und man 
erst auf den Timeout warten muss), müsste man 18 Milliarden Jahre lang 
scannen – für ein solches Netz … :-)

Torben schrieb:
> A.1 möchte auf den Dienst von B.1 zugreifen. Teilnehmer A.1 wurde dem
> Netz neu hinzugefügt. Er muss also erstmal einen Broadcast absetzen, um
> die Adresse von B.1 ausfindig zu machen.

Broadcasts werden nicht geroutet. Alle Pakete ausserhalb des direkt 
angeschlossenen (Sub-)Netzes müssen über einen Router.

Da sich B.1 offensichtlich nicht in A befindet, weiss A.1, dass geroutet 
werden muss. A.1 kennt aus der Konfiguration oder aus DHCP die 
IP-Adresse des Routers aka Default-Gateways, ermittelt per ARP Broadcast 
dessen MAC-Adresse und sendet das Paket dorthin. Dieser ARP Vorgang 
findet nur bei der ersten Kommunikation statt.

Die Anzahl Broadcasts wächst linear mit der Anzahl der Geräte im Subnetz 
- auch bekannt als Broadcast-Domain.

Torben schrieb:
> Übersichtlich (Netzwerkdokumentation)
> Sicherheit (Personalabteilung , Entwicklung)
> abgeschlossene Segmente  (Produktion , Administration/Entwicklung)
> geringere Kollisionsgefahr  (Geschwindigkeitsvorteil)

Mit Switches gibt es keine Kollisionen mehr. Allerdings gibt es eine 
begriffliche Falle, weil "Segmentierung" in jener Zeit, als Ethernet 
noch Kollisionen produzierte, etwas anders bedeuten konnte als heute. 
Heute versteht man darunter meist eine Netzaufteilung auf Layer 3 
aufwärts, früher konnte das auch eine Aufteilung auf Layer 2 sein. In 
diesen 4 Zeilen scheint beides vermischt zu werden, was für Konfusion 
sorgen kann.

Torben schrieb:
> Warum weiß A.1, dass geraoutet werden muss.

Wenn die Zieladresse nicht in die Netzdefinition aus eigener IP-Adresse 
und Netzmaske passt, muss geroutet werden. Eine Zieladresse 1.1.2.1 ist 
bei einer eigenen Adresse 1.1.1.1/24 nicht direkt ansprechbar.

Jörg W. schrieb:
> Es gibt ohnehin praktisch kein "Subnetting" mehr in dem Sinne:

Dock, doch. Es bezeichnet einfach den Prozess aus einem größeren Netz 
(IP Bereich) ein kleineres Netz herauszutrennen. Dazu gibt es gewisse 
Regeln. So kann ein Subnetz, entsprechend seiner Größe, nicht an einer 
beliebigen IP-Adresse beginnen oder enden.

Dabei ist es egal, ob das zu unterteilende Netz einem alten Class A, B, 
C Netz entspricht oder einem CIDR Netz.

> einfach IP-Netzwerke, bestehend aus Netzerkadresse und Netzmaske. Das
> Wort "Sub" stammt aus der Zeit der klassenbehafteten Netze, als man das
> Internet noch so schön als Klasse A, B oder C eingeteilt hat. Innerhalb
> dieser Klassen war es dann vor allem bei A und B üblich, "Subnetze"
> einzuteilen, wobei im ursprünglichen Ansatz noch die Netzmaske aller
> Subnetze gleich war.

Langsam. Class A, B, C funktionierten ohne Netzmaske, denn die Netzgröße 
war implizit durch die Klasse, und damit durch die IP-Adressen selber, 
gegeben. Netzmasken wurden erst bei Einführung von CIDR benötigt. Damit 
begann das intensive Subnetting, in dem man aus übergroßen Netzen (wie 
Class A), kleine Netze heraustrennte.

Wenn ein herausgetrenntes Netz (Subnetz) selber noch groß genug sind, 
dann kann man es nach den gleichen Regeln weiter zerteilen. Allerdings 
verzichtet man darauf ein solches Netz Sub-Subnetz zu nennen. Es wird, 
wenn nötig, ebenfalls einfach als Subnetz bezeichnet.

Allgemein gilt, ein Subnetz ist einfach ein Netz. Mann nennt es dann 
Subnetz, wenn man betonen will, dass es durch Heraustrennen aus einem 
größeren Netz entstanden ist. Das Heraustrennen ist bei ehemaligen Class 
A, B, C oder CIDR Netzen gleich.

Hannes J. schrieb:
> Jörg W. schrieb:
>> Es gibt ohnehin praktisch kein "Subnetting" mehr in dem Sinne:
>
> Dock, doch. Es bezeichnet einfach den Prozess aus einem größeren Netz
> (IP Bereich) ein kleineres Netz herauszutrennen.

Dann ist das ganze Internet letztlich eine Hierarchie von "Subnetzen". 
In der Hierarchie nach oben werden sie zusammengefasst (aggregation, 
Anzahl der Maskenbits wird kleiner), nach unten aufgegliedert (Anzahl 
der Maskenbits wird größer).

Das macht das Wort "Sub" darin irgendwie überflüssig.

> Dazu gibt es gewisse
> Regeln. So kann ein Subnetz, entsprechend seiner Größe, nicht an einer

> Langsam. Class A, B, C funktionierten ohne Netzmaske,

Selbstverständlich gab es den Begriff einer Netzmaske auch dort schon 
(bpsw. im ifconfig oder route Kommando), es wird nur bei fehlender 
Angabe einer Netzmaske eine vordefinierte Anzahl von Bits angenommen. 
Aber gerade für das Subnetting wurde auch damals schon eine größere 
Netzmaske explizit angegeben.

> Allgemein gilt, ein Subnetz ist einfach ein Netz.

Eben. Seit CIDR gibt es keinen Unterschied mehr.

Zwischendrin gab's dann auch noch die Kuriosität eines "Supernetting", 
aber dieser Begriff ist mit CIDR völlig wieder in der Versenkung 
verschwunden.

Torben schrieb:
> 13. Das DG nimmt den Ethernet-Frame entgegen und ersetzt im IP-Paket die
> Absender-Adresse durch seine eigene (NAT)

Ohne NAT: Setzt die eigene MAC Adresse als Absender ein, lässt die 
IP-Adresse unverändert.

> Frage: Haut das einigermaßen hin?

Ziemlich. NAT solltest du weglassen. Das hattest du bisher nicht erwähnt 
und ist vmtl ein Missverständnis deinerseits.

Torben schrieb:

> 5. A.1 muss deshalb das Paket an das Default-Gateway (DG) adressieren.

Genauer: er muss anhand seiner Routing-Tabelle ermitteln, wem er als 
next hop nun das Paket zustellen muss, da es nicht in seinem eigenen 
Ethernet-Adressbereich liegt.

Der default gateway ist dabei nur die letzte Möglichkeit, auf die er 
zurückfällt. Es könnte auch gut und gern eine Netztopologie sein, bei 
der der default gateway halt tatsächlich nur den Weg ins Internet 
beschreibt, während andere Netzwerkbereiche der eigenen Organisation 
über separate(s) Gateway(s) zu erreichen sind.

Daher listet die Routingtabelle Netzwerkbereiche (wiederum 
gekennzeichnet durch Netwerkadressse und zugehöriger Netzmaske) mit 
ihrem jeweils zugehörigen Gateway. Der default gateway hat die spezielle 
Netzwerkadresse 0.0.0.0 und auch als Netzmaske 0.0.0.0, wodurch er auf 
alles andere passt.

Die Routing-Policy geht dabei von einer möglichst spezifischen Route 
(der sie die höchste Priorität zugesteht) hin zu einer möglichst 
allgemeinen (wenn es einen default gateway gibt, dann ist er immer der 
letzte in der Betrachtung.

Stell dir folgende Routingtabelle vor (das eigene Netz hat die 
192.168.1.0/24):

1

Zielnetz      Netzmaske       Gateway

2

192.168.3.0   255.255.255.0   192.168.1.99

3

192.168.0.0   255.255.128.0   192.168.1.233

4

0.0.0.0       0.0.0.0         192.168.1.254

Für die folgenden Zieladressen würde er jeweils den gezeigten Gateway 
auswählen:

1

Ziel          GW

2

192.168.3.33  192.168.1.99

3

192.168.5.19  192.168.1.233

4

192.168.233.1 192.168.1.254

5

8.8.8.8       192.168.1.254

Denk über die einzelnen Beispiel bisschen nach, mal dir ggf. die Bits 
auf, damit du sehen kannst, welche Adresse in welchen Netzbereich fällt.

> 6. Um es zum DG transportieren zu können, muss A.1 einen Ethernet-Frame
> bilden.

Das müsste er übrigens auch, um es zu einem anderen Knoten im eigenen 
Netzbereich zu senden – insofern unterscheidet sich der Gateway hier 
nicht von den anderen Adressen im eigenen Netz.

> 8. A.1 bezieht zunächst die IP-Adresse des DGs vom DHCP-Server. Sie
> lautet y.y.y.y

Die bezieht er nicht erst jetzt, sondern die hat er bereits während 
seiner Netzwerk-Konfigurationsphase bekommen, zusammen mit seiner 
IP-Adresse.

> 13. Das DG nimmt den Ethernet-Frame entgegen und ersetzt im IP-Paket die
> Absender-Adresse durch seine eigene (NAT)

Wie A.K. schon schrieb: nur, wenn NAT überhaupt eine Rolle spielt. In 
meinem obigen Beispiel würde wahrscheinlich die 192.168.233.1 nur in ein 
anderes internes Netz weitergeleitet werden (es handelt sich ja immer 
noch um eine RFC1918-Adresse, die also nicht im Internet geroutet werden 
kann), während das Paket in Richtung 8.8.8.8 dann sicherlich geNATet 
wird.

Genau wie A.1 die MAC-Adresse des Routers herausfindet: ARP. Und genau 
wie der PC merkt er sich das eine Weile im ARP Cache.

Torben schrieb:
> Sinngemäß meinte mein Lehrer, es gibt so etwas wie Netzklassen nicht
> mehr.

Hat er Recht.

Das einzige, was sie noch bewirken ist, dass sie die Netzmaske 
festlegen, falls keine andere angegeben ist.

Also:

1

ifconfig eth0 192.168.3.5

ist äquivalent zu

1

ifconfig eth0 192.168.3.5 netmask 255.255.255.0

weil 192.*.*.* im Sinne der Netzklassen ein Class C wäre.

Torben schrieb:
> Datenkabel mit ihrer Dämpfung abgebildet. Da steht dann sowas wie CAT 5
> 22 dB bei 100 MHz. Was kann man denn dieser Information entnehmen?
> Kann man jetzt irgendwas Berechnen?

Nach einem geeigneten Studium der E-Technik kann man das. Als Praktiker 
schlägt man nach, wieviele Meter man mit welchem Kabeltyp bei welchem 
Netztyp gehen kann, und glaubt es einfach.

Ansonsten brauchen beispielsweise jene Fachleute solche Werte, die alte 
Netze durchmessen, um dem Kunden eine neue teure Verkabelung verkaufen 
zu können. Aber rechnen tun die auch nicht, die stellen nur fest, ob es 
noch passt.

Server muss man ihre Adressen immer fest einstellen.

Geht natürlich auch teilweise über DHCP (MAC address fixing), aber 
irgendwer muss halt das Ei für die Henne sein. ;-)

Jörg W. schrieb:
> Server muss man ihre Adressen immer fest einstellen.
>
> Geht natürlich auch teilweise über DHCP (MAC address fixing), aber
> irgendwer muss halt das Ei für die Henne sein. ;-)

Man kann natürlich mehrere DHCP Server verwenden. Nur sollte man dann 
aufpassen, dass wirklich immer einer davon läuft. ;-)

Irgendeine IP-Adresse im betreffenden Netz braucht man. Ist aber egal 
welche. Fest muss die nur sein, wenn ein Router die DHCP-Requests eines 
anderen Netzes forwarded.

torben_25 schrieb:
> Welche IP-Adresse bekommt eigentlich ein DHCP-Server? Muss man ihm von
> Hand eine statische zuweisen?

Sollte man. Alles andere ist für Leute gedacht, die Spass an Problemen 
zum unmöglichsten Zeitpunkt haben.

A. K. schrieb:
> Man kann natürlich mehrere DHCP Server verwenden. Nur sollte man dann
> aufpassen, dass wirklich immer einer davon läuft.

Jau.

> Alles andere ist für Leute gedacht, die Spass an Problemen zum
> unmöglichsten Zeitpunkt haben.

:-)

Grundsätzlich ist es natürlich richtig, der DHCP-Server wird über 
Broadcasts angesprochen (an die generische Broadcast-Adresse 
255.255.255.255), aber ihn nicht auf eine feste IP-Adresse zu legen, 
wäre schon ausgesprochen unklug. Außerdem, woher sollte er seine Adresse 
denn nehmen, wenn sie ihm nicht fest vorgegeben worden ist? Es gibt ja 
dann niemanden, der ihm eine verteilen könnte.

Jörg W. schrieb:
> Außerdem, woher sollte er seine Adresse
> denn nehmen, wenn sie ihm nicht fest vorgegeben worden ist? Es gibt ja
> dann niemanden, der ihm eine verteilen könnte.

Man könnte dem Netz eine 169.254-er Range geben, wenn Microsoft. Die 
gibts, wenn dem System sonst nichts einfällt. ;-)

Manfred schrieb:
> Um die Verwirrung zu erhöhen: Ich hatte auch schon zwei DHCP im selben
> Netz, aber so konfiguriert, dass sie unterschiedliche Adressen vergeben.

Wolltest du den schnellsten DHCP-Server ermitteln? Wer ruft zuerst 
"hier!" auf einen DHCP-Request? ;-)

Manfred schrieb:
> Du wolltest schreiben "immer nur einer davon läuft."

Nein.

> Um die Verwirrung zu erhöhen: Ich hatte auch schon zwei DHCP im selben
> Netz, aber so konfiguriert, dass sie unterschiedliche Adressen vergeben.

Ebendies. Kein Hexenwerk.

Manfred schrieb:
> A. K. schrieb:
>> Man kann natürlich mehrere DHCP Server verwenden. Nur sollte man dann
>> aufpassen, dass wirklich immer einer davon läuft. ;-)
>
> Du wolltest schreiben "immer nur einer davon läuft."
>

Das stimmt in dieser Absloutheit nicht. Wenn es mehrere DHCP-Server 
gibt, muss man lediglich darauf achten, dass sich deren IP-Pools und die 
fest vergebenen Adressen nicht überschneiden und dass die ausgereichten 
IP-Adressen (nebst Zusatzinfos wie Gateway, DNS usw.) korrekt sind.

Ich war kürzlich gezwungen, genau sowas einzurichten. Ein etwas weiter 
ab gelegenes Gebäude einer Firma wurde über eine weitere Zwischenstation 
mit  einer Richtfunkstrecke mit dem Hauptsitz verbunden. Offenbar 
ergaben sich für die DHCP-Anfrage einiger Laptops zu lange Laufzeiten, 
so dass die sich immer schon eine 169er APIPA zugelegt hatten, bevor die 
Antwort kam. Also wurde in der letzten WLAN-Bridge der (normalerweise 
ungenutzte) DHCP-Server entsprechend konfiguriert und aktiviert. Geht.

Frank E. schrieb:
> Das stimmt in dieser Absloutheit nicht.

Gebe ich dir Recht, wenngleich das schon eher ein ziemlicher Sonderfall 
ist, wo das mal Sinn hat, das zu machen.