18
Standard Gateway eines DHCP-Client
SBS 2003 --> DHCP: Client erhält falschen Standard-Gateway-Eintrag, siehe https://www.administrator.de/index.php?content=ea171af54d05af290c55e65c0 ...
Hallo,
ich bin immer noch mit dem obigen Problem beschäftigt. Ich hoffe, ihr verzeiht mir dieses Doppelposting, aber ich habe nicht die geringste Idee, was das Problem sein kann.
Nochmal die Situation:
Auf einem SBS 2003 Std habe ich einen DHCP mit Reservierungen konfiguriert. In den Bereichsoptionen des DHCP ist 003 Routers mit dem Standard Gateway belegt, Serveroptionen sind nicht konfiguriert, die Reservierungen übernehmen die Bereichsoptionen.
Der DHCP-Client übernimmt nun alle Einstellungen des Servers außer der Einstellung des Standard-Gateways. Hier steht die localIP des Clients. Falls im DHCP zwei RouterIPs angegeben sind, wird die in der Reihenfolge erste durch die localIP ersetzt.
Ein Test mit einem zweiten Rechner ergab dasselbe Ergebnis. Auch das Entfernen aus der aktuellen und einbinden in die TestDomain hat am Ergebnis nix geändert.
Frage:
Wie könnte der Client dazu kommen, die localIP als Standard Gateway zu setzen? Hat jemand eine Idee, sie darf auch zunächst abwegig klingen, vielleicht verhilft sie mir ja zu dem "da war doch mal was"- Effekt. Momentan tappe ich jedenfalls völlig im Dunkeln.
Ich bitte Euch dringend um Hilfe, geTuemII
Hallo,
ich bin immer noch mit dem obigen Problem beschäftigt. Ich hoffe, ihr verzeiht mir dieses Doppelposting, aber ich habe nicht die geringste Idee, was das Problem sein kann.
Nochmal die Situation:
Auf einem SBS 2003 Std habe ich einen DHCP mit Reservierungen konfiguriert. In den Bereichsoptionen des DHCP ist 003 Routers mit dem Standard Gateway belegt, Serveroptionen sind nicht konfiguriert, die Reservierungen übernehmen die Bereichsoptionen.
Der DHCP-Client übernimmt nun alle Einstellungen des Servers außer der Einstellung des Standard-Gateways. Hier steht die localIP des Clients. Falls im DHCP zwei RouterIPs angegeben sind, wird die in der Reihenfolge erste durch die localIP ersetzt.
Ein Test mit einem zweiten Rechner ergab dasselbe Ergebnis. Auch das Entfernen aus der aktuellen und einbinden in die TestDomain hat am Ergebnis nix geändert.
Frage:
Wie könnte der Client dazu kommen, die localIP als Standard Gateway zu setzen? Hat jemand eine Idee, sie darf auch zunächst abwegig klingen, vielleicht verhilft sie mir ja zu dem "da war doch mal was"- Effekt. Momentan tappe ich jedenfalls völlig im Dunkeln.
Ich bitte Euch dringend um Hilfe, geTuemII
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 13575
Url: https://administrator.de/contentid/13575
Ausgedruckt am: 16.11.2024 um 01:11 Uhr
18 Kommentare
Neuester Kommentar
Hallo,
also zuerst würde ich mir mal die Eigenschaften des TCP/IP Protokolls anschauen, ob da alles auf DHCP beziehen steht. Zusätzlich den Reiter für die private IP-Adresse, da auch alles leer ?
Dann existiert vielleicht ein 2. ter DHCP (Router) ? auf dem ebenfalls DHCP aktiviert ist, dass kann zu den komischten Fehlern führen...
Dann mal die Registry checken, evt. ist da das eigene Gateway fest eingetragen ?
Existiert vielleicht eine GPO, obwohl ich nicht genau weiss, ob man da überhaupt ein Gateway übergeben kann.
Exisitiert ein Script, das das Gateway setzen könnte ?
Läuft der DHCP absolut ohne Fehler, was gibt denn das Ereignis-Log aus ?
mfg
Ritchy
also zuerst würde ich mir mal die Eigenschaften des TCP/IP Protokolls anschauen, ob da alles auf DHCP beziehen steht. Zusätzlich den Reiter für die private IP-Adresse, da auch alles leer ?
Dann existiert vielleicht ein 2. ter DHCP (Router) ? auf dem ebenfalls DHCP aktiviert ist, dass kann zu den komischten Fehlern führen...
Dann mal die Registry checken, evt. ist da das eigene Gateway fest eingetragen ?
Existiert vielleicht eine GPO, obwohl ich nicht genau weiss, ob man da überhaupt ein Gateway übergeben kann.
Exisitiert ein Script, das das Gateway setzen könnte ?
Läuft der DHCP absolut ohne Fehler, was gibt denn das Ereignis-Log aus ?
mfg
Ritchy
Hallo Ritchy,
yep, alles auf DHCP (also leer).
Eigentlich nicht, daber ich hatte auch schon nochmal sicherheitshalber getestet: ohne den Server bekomme ich keine interne IP.
Isses nicht, allerdings die local IP steht unter HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\(name)\DhcpDefaultGateway Wenn ich dort den Eintrag entferne, ist er nach release-renew wieder da, falsch wie vorher. Aber das entspricht ja eigentlich dem Fehler. Im selben Zweig steht unter DefautGateway übrigens nichts, hab nochmal zur Überprüfung geguckt.
Siehste, das weiss ich eben auch nicht. Ich habe jedenfalls nix entsprechendes konfiguriert und Standard ist das nicht, bei meinem anderen DCHP auf SBS 2k3 hats auch problemlos getan --> grml.
Nein, der Server ist noch ganz frisch, also noch kaum konfiguriert, nichtmal am Standard SBS Script was geändert.
Ja, tut er. Im Log finden sich nur Einträge über Start/Stop Server und Zuweisung bzw. Freigabe von IPs. Auch die EventLogs des Servers bringen keine andere Aussage.
Grüsse, geTuemII
also zuerst würde ich mir mal die
Eigenschaften des TCP/IP Protokolls
anschauen, ob da alles auf DHCP beziehen
steht. Zusätzlich den Reiter für
die private IP-Adresse, da auch alles leer
?
Eigenschaften des TCP/IP Protokolls
anschauen, ob da alles auf DHCP beziehen
steht. Zusätzlich den Reiter für
die private IP-Adresse, da auch alles leer
?
yep, alles auf DHCP (also leer).
Dann existiert vielleicht ein 2. ter DHCP
(Router) ? auf dem ebenfalls DHCP aktiviert
ist, dass kann zu den komischten Fehlern
führen...
(Router) ? auf dem ebenfalls DHCP aktiviert
ist, dass kann zu den komischten Fehlern
führen...
Eigentlich nicht, daber ich hatte auch schon nochmal sicherheitshalber getestet: ohne den Server bekomme ich keine interne IP.
Dann mal die Registry checken, evt. ist da
das eigene Gateway fest eingetragen ?
das eigene Gateway fest eingetragen ?
Isses nicht, allerdings die local IP steht unter HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\(name)\DhcpDefaultGateway Wenn ich dort den Eintrag entferne, ist er nach release-renew wieder da, falsch wie vorher. Aber das entspricht ja eigentlich dem Fehler. Im selben Zweig steht unter DefautGateway übrigens nichts, hab nochmal zur Überprüfung geguckt.
Existiert vielleicht eine GPO, obwohl ich
nicht genau weiss, ob man da überhaupt
ein Gateway übergeben kann.
nicht genau weiss, ob man da überhaupt
ein Gateway übergeben kann.
Siehste, das weiss ich eben auch nicht. Ich habe jedenfalls nix entsprechendes konfiguriert und Standard ist das nicht, bei meinem anderen DCHP auf SBS 2k3 hats auch problemlos getan --> grml.
Exisitiert ein Script, das das Gateway
setzen könnte ?
setzen könnte ?
Nein, der Server ist noch ganz frisch, also noch kaum konfiguriert, nichtmal am Standard SBS Script was geändert.
Läuft der DHCP absolut ohne Fehler, was
gibt denn das Ereignis-Log aus ?
gibt denn das Ereignis-Log aus ?
Ja, tut er. Im Log finden sich nur Einträge über Start/Stop Server und Zuweisung bzw. Freigabe von IPs. Auch die EventLogs des Servers bringen keine andere Aussage.
Grüsse, geTuemII
Ziehen sich alle PC's das falsche Gateway oder nur einer?
In dem beschriebenen Registry-Key muss das remote Gateway stehen, nicht der PC selber, das ist klar ...
Was passiert denn, wenn Du das GW im DHCP ganz raus nimmst?
Was passiert, wenn Du die Netzwerkkarte mal "manuell" einrichtest und dann wieder auf "Autokonfig" stellst?
Was sagt ein "ipcofig /all" an, wenn Der DHCP-Server nicht verfügbar ist, zum GW?
Gruß
Atti
In dem beschriebenen Registry-Key muss das remote Gateway stehen, nicht der PC selber, das ist klar ...
Was passiert denn, wenn Du das GW im DHCP ganz raus nimmst?
Was passiert, wenn Du die Netzwerkkarte mal "manuell" einrichtest und dann wieder auf "Autokonfig" stellst?
Was sagt ein "ipcofig /all" an, wenn Der DHCP-Server nicht verfügbar ist, zum GW?
Gruß
Atti
Hallo Atti,
ich habe es mit zweien getestet, mehr kriege ich beim besten Willen nicht aus der Produktivumgebung abgezogen.
Der Client hat gar keinen GW-Eintrag mehr.
Das habe ich schon mehrfach gemacht (ich muss immer wieder auf "produktiv" zurücksetzen), das Problem ist reproduzierbar.
Windows-IP-Konfiguration
Hostname. . . . . . . . . . . . . : xxxxx
Primäres DNS-Suffix . . . . . . . : xxx.xxxxxxxx.de
Knotentyp . . . . . . . . . . . . : Broadcast
IP-Routing aktiviert. . . . . . . : Nein
WINS-Proxy aktiviert. . . . . . . : Nein
Ethernetadapter LAN-Verbindung:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Marvell Yukon 88E8001/8003/8010 PCI Gigabit Ethernet Controller
Physikalische Adresse . . . . . . : xx-xx-xx-xx-xx-xx
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IP-Adresse (Autokonfig.). . . . . : 169.254.24.141
Subnetzmaske. . . . . . . . . . . : 255.255.0.0
Standardgateway . . . . . . . . . :
Der DNS-Suffix ist lokal, ich weiss, das er nicht MS-Standard ist. Es ist eine Subdomain unserer eigenen und daher nicht Internet-verfügbar. Ist halt historisch so gewachsen
Der StandardIP-Raum ist 192.168.50.0
Gruss, geTuemII
Ziehen sich alle PC's das falsche Gateway
oder nur einer?
oder nur einer?
ich habe es mit zweien getestet, mehr kriege ich beim besten Willen nicht aus der Produktivumgebung abgezogen.
Was passiert denn, wenn Du das GW im DHCP
ganz raus nimmst?
ganz raus nimmst?
Der Client hat gar keinen GW-Eintrag mehr.
Was passiert, wenn Du die Netzwerkkarte mal
"manuell" einrichtest und dann
wieder auf "Autokonfig" stellst?
"manuell" einrichtest und dann
wieder auf "Autokonfig" stellst?
Das habe ich schon mehrfach gemacht (ich muss immer wieder auf "produktiv" zurücksetzen), das Problem ist reproduzierbar.
Was sagt ein "ipcofig
/all" an, wenn Der
DHCP-Server nicht verfügbar ist, zum
GW?
/all" an, wenn Der
DHCP-Server nicht verfügbar ist, zum
GW?
Windows-IP-Konfiguration
Hostname. . . . . . . . . . . . . : xxxxx
Primäres DNS-Suffix . . . . . . . : xxx.xxxxxxxx.de
Knotentyp . . . . . . . . . . . . : Broadcast
IP-Routing aktiviert. . . . . . . : Nein
WINS-Proxy aktiviert. . . . . . . : Nein
Ethernetadapter LAN-Verbindung:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Marvell Yukon 88E8001/8003/8010 PCI Gigabit Ethernet Controller
Physikalische Adresse . . . . . . : xx-xx-xx-xx-xx-xx
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IP-Adresse (Autokonfig.). . . . . : 169.254.24.141
Subnetzmaske. . . . . . . . . . . : 255.255.0.0
Standardgateway . . . . . . . . . :
Der DNS-Suffix ist lokal, ich weiss, das er nicht MS-Standard ist. Es ist eine Subdomain unserer eigenen und daher nicht Internet-verfügbar. Ist halt historisch so gewachsen
Der StandardIP-Raum ist 192.168.50.0Gruss, geTuemII
... das ist alles schon recht merkwürdig ... Ich vermute, dass Du in Deiner DHCP-Datenbank einen Bug hast. Wie groß ist denn Deine Umgebung bzw. die Lease-Dauer Deiner IP's? Kannst Du nicht noch einmal den DHCP-Server deinstallieren, den Inhalt des Verzeichnises "%SYSTEMROOT%\system32\dhcp" löschen und dann den Server neu einrichten?
Gruß
Atti
Gruß
Atti
Yep, _das_ finde ich auch... Dann werde ich mir mal einen Schönen Nachmittag machen und das Teil neu aufsetzen. Aber diesmal probiere ich erstmal mit _einer_ Reservierung, die anderen 97 mache ich, wenns tut [grummel]
Ich vermelde dann Erfolg oder Misserfolg.
Bis dann geTuemII
Ich vermelde dann Erfolg oder Misserfolg.
Bis dann geTuemII
Mist... Misserfolg --> ich hätte das nicht schreiben sollen
Ich habe ein DB-Backup gezogen, den DHCP gelöscht, die Files unter sys32\dhcp gelöscht und den DHCP mit Grundeinstellungen (Bereich mit DNS, Router und DomainName und Wins) neu aufgebaut.
Ergebnis: StandardGateway ist die local IP!
Ich werden morgen eine Linux-LiveCD und eine [FT]estplatte mit ins Büro nehmen und mal zwei Tests machen: was sagt die LiveCD zum Thema (IMHO kann man einen DHCP-Client konfigurieren) und was macht ein jungfräuliches Windows ohne Domainerfahrung.
Vermelde dann das Ergebnis.
Gruss, Silke
Ich habe ein DB-Backup gezogen, den DHCP gelöscht, die Files unter sys32\dhcp gelöscht und den DHCP mit Grundeinstellungen (Bereich mit DNS, Router und DomainName und Wins) neu aufgebaut.
Ergebnis: StandardGateway ist die local IP!
Ich werden morgen eine Linux-LiveCD und eine [FT]estplatte mit ins Büro nehmen und mal zwei Tests machen: was sagt die LiveCD zum Thema (IMHO kann man einen DHCP-Client konfigurieren) und was macht ein jungfräuliches Windows ohne Domainerfahrung.
Vermelde dann das Ergebnis.
Gruss, Silke
Ich liebe es, wenn ich vor lauter Level 1 nicht an einem Problem dranbleiben kann....
Also, ich habe jetzt das richtige Gateway
Falls jemand ein ähnliches Problem hat, hier die Tests und die Lösung (der Workarround):
Test 1: Von Linux LiveCD (Knoppix oder Kanotix) gebootet --> System holt vom DHCP alle Einstellungen ausser das Standard Gateway, dort ist auch in diesem Fall die lokale IP des Clients eingetragen --> _daneben_
Fazit aus 1: Die lokalen Einstellungen am XP-Client sind nicht das Problem, sonst hätte ich mit der unkonfigurierten LiveCD unter Linux das richtige Gateway.
Test 2: Den Server physikalisch vom Netzwerk getrennt und auf ein eigenes Switch gehängt, meinen Laptop, der zu meiner HeimatDomain gehört, an das Switch angeschlossen --> System holt vom DHCP alle Einstellungen incl. Standard Gateway --> _funktioniert_
Fazit aus Test 2: Der DHCP läuft an sich sauber und liefert auch die richtigen Daten.
zur Sicherheit Test 3: Server wieder ins normale Netzwerk, Laptop auch --> Ergebnis wie Tests 1 --> daneben
Fazit aus allen Test:
Das vorhandene alte Netz verhindert irgendwie die richtige Weitergabe der Adresse in 003 Router. Die angestrebte Konsolidierung des Systems (wegen derer der neue Server ja aufgebaut wird) könnte das Problem beheben.
Workarround:
Ich habe in 249 Statische Routen ohne Klassen eine static route mit dem Ziel 0.0.0.0 (default) und meiner RouterIP angelegt, diese Einträge werden vor 003 Router gelesen, eine hier eingetragene Default Route setzt so das falsche Standard Gateway ausser Kraft. der falsche Eintrag ist übrigens immernoch da, hat aber keine Auswirkung mehr.
Es würde mich aber trotzdem noch interessieren, warum dieser Fehler überhaupt auftritt. Wenn dazu jemand eine Idee hat, lasst sie hören!
Grüsse, geTuemII
Also, ich habe jetzt das richtige Gateway
Falls jemand ein ähnliches Problem hat, hier die Tests und die Lösung (der Workarround):
Test 1: Von Linux LiveCD (Knoppix oder Kanotix) gebootet --> System holt vom DHCP alle Einstellungen ausser das Standard Gateway, dort ist auch in diesem Fall die lokale IP des Clients eingetragen --> _daneben_
Fazit aus 1: Die lokalen Einstellungen am XP-Client sind nicht das Problem, sonst hätte ich mit der unkonfigurierten LiveCD unter Linux das richtige Gateway.
Test 2: Den Server physikalisch vom Netzwerk getrennt und auf ein eigenes Switch gehängt, meinen Laptop, der zu meiner HeimatDomain gehört, an das Switch angeschlossen --> System holt vom DHCP alle Einstellungen incl. Standard Gateway --> _funktioniert_
Fazit aus Test 2: Der DHCP läuft an sich sauber und liefert auch die richtigen Daten.
zur Sicherheit Test 3: Server wieder ins normale Netzwerk, Laptop auch --> Ergebnis wie Tests 1 --> daneben
Fazit aus allen Test:
Das vorhandene alte Netz verhindert irgendwie die richtige Weitergabe der Adresse in 003 Router. Die angestrebte Konsolidierung des Systems (wegen derer der neue Server ja aufgebaut wird) könnte das Problem beheben.
Workarround:
Ich habe in 249 Statische Routen ohne Klassen eine static route mit dem Ziel 0.0.0.0 (default) und meiner RouterIP angelegt, diese Einträge werden vor 003 Router gelesen, eine hier eingetragene Default Route setzt so das falsche Standard Gateway ausser Kraft. der falsche Eintrag ist übrigens immernoch da, hat aber keine Auswirkung mehr.
Es würde mich aber trotzdem noch interessieren, warum dieser Fehler überhaupt auftritt. Wenn dazu jemand eine Idee hat, lasst sie hören!
Grüsse, geTuemII
Switch puttt...
Liebe Leute: Bin zufällig hier draufgestossen. Wir sind ja meist Profis und arbeiten als Sysadmins oder sonstige IT-Freaks in Unternehmen, da sollten wir den vielen Studenten, welche solche Beiträge auch Monate nachdem Silke das Problem "gelöst" hat noch sauber abhandeln.
eigentlich sollte jedem MCSE'ler sämtliche Glocken läuten , wenn er dies hier von Silke sieht:
>Windows-IP-Konfiguration
1) Autoconf ist eingeschaltet, die Adresse ist ja eine der berühmten Autoconf. Das bedeutet nichts anderes, als dass der Client den DHCP-Server gar nie hören konnte. Das hätte man auch in den Eventlogs unter "System" nachsehen können: DHCP-Error".
Nun, in diesem Fall trägt der Client seine eigene IP- nämlich eine Autoconf -Adresse ein
2) Silke hat den DHCP-Server bezüglich der Knotentypen hoffentlich nicht auf B-Knoten gelassen. In dieser Einstellung müllen die Clients das Netz mit Broadcastmeldungen zu, sobald sie einmal eine für sie neue Verbindung herstellen müssen. Besser ist es, den Knotentyp auf H zu stellen (was n.b. auch Microsoft so empfiehlt).
Fazit und Troubleshooting:
1) Immer erst das Lämpchen an Netzwerkkarte + Switch prüfen : hab ich Link?
2) Gibt es eine Verbindung zwischen Client und Server : Ping <ServerIP> vom Client aus
(Server muss Ping natürlich erlauben)
3) Einstellungen prüfen mit Start-> CMD-> ipconfig /all : sind mehrere IP-Adressen gebunden? Gültigkeit der Adresse bis wann?
4) IP-Adresse freigeben und wieder neu beziehen: ipconfig /release und dann ipconfig /renew. Gratistipp : Wenn mehrere Bindungen vorhanden sind, einfach ein Leerschlag und Stern nachfolgen lassen , z.B. ipconfig /release *
Mit diesem Vorgehen testet man die korrekte Funktion des DHCP
5) Wenn nix geht: einfach mal eine Adresse statisch von Hand eintragen. Die Adresse muss aus dem dynamischen Bereich des DHCP stammen, also bei DHCP von z.B. 192.168.1.10 bis 254 könnte man z.B. 192.168.1.250 nehmen. Ich benutze regelmässig die hintersten Adressen, um weniger konflikte mit bereits vergebenen Adr. zu kriegen.
Nunn muss Zufriff auf die Netzwerkressourcen möglich sein.
Wenns immer noch nicht geht:
6) Sind VLAN-Switches in Betrieb? in dem speziellen Fall beim Admin die VLAN-Einstellungen prüfen und korrigieren lassen, vielleicht ist der lokale Switch oder Hub gar nicht VLAN-fähig.
Wenn das VLAN von der Netzwerkkarte aufgelöst wird, muss im Netzwerkkartentreiber alles richtig eingestellt sein!
Wenns immer noch nicht geht:
7) Ist in diesem verd. ..Netz ein exotisches Protokoll in Betrieb?
Einstellungen für Layer -2 Protokolle kontrollieren! Normal sind:
Ethernet II mit darauf laufendem IP und TCP, UDP..
oder
IEEE 802.2 mit darauf laufendem IPX und SPX
Alles Andere gienge zwar technisch, ist aber sehr exotisch und man müsste den Admin dafür mindestens 3 Monate auf die Insel Rügen verbannen...
Im Moment kommt mir nichts anderes in den Sinn.
An Silke: Hast Du Dein Problem schliesslich erklären können?
Cosy
eigentlich sollte jedem MCSE'ler sämtliche Glocken läuten , wenn er dies hier von Silke sieht:
>Windows-IP-Konfiguration
Hostname. . . . . . . . . . . . . : xxxxx
Primäres DNS-Suffix . . . . . . . : xxx.xxxxxxxx.de
Knotentyp . . . . . . . . . . . . : Broadcast
IP-Routing aktiviert. . . . . . . : Nein
WINS-Proxy aktiviert. . . . . . . : Nein
Ethernetadapter LAN-Verbindung:
Ver>bindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Marvell Yukon 88E8001/8003/8010 PCI Gigabit Ethernet >Controller
Physikalische Adresse . . . . . . : xx-xx-xx-xx-xx-xx
DHCP aktiviert. . . . . . . . . . : Ja
Aut>okonfiguration aktiviert . . . : Ja
IP-Adresse (Autokonfig.). . . . . : 169.254.24.141
Subnetzmaske. . . . . . . . . . . : 255.255.0.0
Standardgateway . . . . . . . . . :
Primäres DNS-Suffix . . . . . . . : xxx.xxxxxxxx.de
Knotentyp . . . . . . . . . . . . : Broadcast
IP-Routing aktiviert. . . . . . . : Nein
WINS-Proxy aktiviert. . . . . . . : Nein
Ethernetadapter LAN-Verbindung:
Ver>bindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Marvell Yukon 88E8001/8003/8010 PCI Gigabit Ethernet >Controller
Physikalische Adresse . . . . . . : xx-xx-xx-xx-xx-xx
DHCP aktiviert. . . . . . . . . . : Ja
Aut>okonfiguration aktiviert . . . : Ja
IP-Adresse (Autokonfig.). . . . . : 169.254.24.141
Subnetzmaske. . . . . . . . . . . : 255.255.0.0
Standardgateway . . . . . . . . . :
1) Autoconf ist eingeschaltet, die Adresse ist ja eine der berühmten Autoconf. Das bedeutet nichts anderes, als dass der Client den DHCP-Server gar nie hören konnte. Das hätte man auch in den Eventlogs unter "System" nachsehen können: DHCP-Error".
Nun, in diesem Fall trägt der Client seine eigene IP- nämlich eine Autoconf -Adresse ein
2) Silke hat den DHCP-Server bezüglich der Knotentypen hoffentlich nicht auf B-Knoten gelassen. In dieser Einstellung müllen die Clients das Netz mit Broadcastmeldungen zu, sobald sie einmal eine für sie neue Verbindung herstellen müssen. Besser ist es, den Knotentyp auf H zu stellen (was n.b. auch Microsoft so empfiehlt).
Fazit und Troubleshooting:
1) Immer erst das Lämpchen an Netzwerkkarte + Switch prüfen : hab ich Link?
2) Gibt es eine Verbindung zwischen Client und Server : Ping <ServerIP> vom Client aus
(Server muss Ping natürlich erlauben)
3) Einstellungen prüfen mit Start-> CMD-> ipconfig /all : sind mehrere IP-Adressen gebunden? Gültigkeit der Adresse bis wann?
4) IP-Adresse freigeben und wieder neu beziehen: ipconfig /release und dann ipconfig /renew. Gratistipp : Wenn mehrere Bindungen vorhanden sind, einfach ein Leerschlag und Stern nachfolgen lassen , z.B. ipconfig /release *
Mit diesem Vorgehen testet man die korrekte Funktion des DHCP
5) Wenn nix geht: einfach mal eine Adresse statisch von Hand eintragen. Die Adresse muss aus dem dynamischen Bereich des DHCP stammen, also bei DHCP von z.B. 192.168.1.10 bis 254 könnte man z.B. 192.168.1.250 nehmen. Ich benutze regelmässig die hintersten Adressen, um weniger konflikte mit bereits vergebenen Adr. zu kriegen.
Nunn muss Zufriff auf die Netzwerkressourcen möglich sein.
Wenns immer noch nicht geht:
6) Sind VLAN-Switches in Betrieb? in dem speziellen Fall beim Admin die VLAN-Einstellungen prüfen und korrigieren lassen, vielleicht ist der lokale Switch oder Hub gar nicht VLAN-fähig.
Wenn das VLAN von der Netzwerkkarte aufgelöst wird, muss im Netzwerkkartentreiber alles richtig eingestellt sein!
Wenns immer noch nicht geht:
7) Ist in diesem verd. ..Netz ein exotisches Protokoll in Betrieb?
Einstellungen für Layer -2 Protokolle kontrollieren! Normal sind:
Ethernet II mit darauf laufendem IP und TCP, UDP..
oder
IEEE 802.2 mit darauf laufendem IPX und SPX
Alles Andere gienge zwar technisch, ist aber sehr exotisch und man müsste den Admin dafür mindestens 3 Monate auf die Insel Rügen verbannen...
Im Moment kommt mir nichts anderes in den Sinn.
An Silke: Hast Du Dein Problem schliesslich erklären können?
Cosy
Hallo Bruno,
ja, aber erstmal sollten wir dazu den Beitrag auch _lesen_.
[ipconfig /all mit AutoIP 169.254.x.x]
Das war auch so gewollt, schließlich hatte Atti58 gefragt:
Ich hatte deshalb den DHCP gespoppt, damit konnte ich auch ausschließen, daß ein zweiter DHCP noch irgendwo im Netzwerk rumfroscht. Die Zusammenhänge zwischen AutoIP und DHCP sind den meisten hier bekannt, denke ich mal.
Ja, die Lämpchen brennen.
Ja, der Server erlaubt ping und ich habe einen Connect.
Nein, es ist lediglich eine IP eingebunden, die Adresse ist gültig.
Das habe ich das ein oder andere Mal gemacht, ohne Erfolg.
Danke!
Aha!
Nochmal: Ich habe kein Problem mit der Vergabe von statischen IPs. Ich habe einen DHCP konfiguriert, der alle konfigurierten Einträge an den Client sauber übergibt. Eine Ausnahme bildet das Gateway, hier wird der Eintrag von der lokalen IP des Clients überschrieben. Beim physikalischen Aushängen des Servers aus dem vorhandenen Netz übernimmt der Client in diesem MiniNetz das Gateway sauber.
Nein, einige alte Server sind noch im Netz, ich arbeite momentan mit DHCP und händisch eingetragenem Gateway.
Nachdem du jetzt hoffentlich alles nochmal gelesen hast, bin ich natürlich auf deine Lösung gespannt.
geTuemII
Liebe Leute: Bin zufällig hier
draufgestossen. Wir sind ja meist Profis und
arbeiten als Sysadmins oder sonstige
IT-Freaks in Unternehmen, da sollten wir den
vielen Studenten, welche solche Beiträge
auch Monate nachdem Silke das Problem
"gelöst" hat noch sauber
abhandeln.
draufgestossen. Wir sind ja meist Profis und
arbeiten als Sysadmins oder sonstige
IT-Freaks in Unternehmen, da sollten wir den
vielen Studenten, welche solche Beiträge
auch Monate nachdem Silke das Problem
"gelöst" hat noch sauber
abhandeln.
ja, aber erstmal sollten wir dazu den Beitrag auch _lesen_.
eigentlich sollte jedem MCSE'ler
sämtliche Glocken läuten , wenn er
dies hier von Silke sieht:
sämtliche Glocken läuten , wenn er
dies hier von Silke sieht:
[ipconfig /all mit AutoIP 169.254.x.x]
1) Autoconf ist eingeschaltet, die Adresse
ist ja eine der berühmten Autoconf. Das
bedeutet nichts anderes, als dass der Client
den DHCP-Server gar nie hören konnte.
ist ja eine der berühmten Autoconf. Das
bedeutet nichts anderes, als dass der Client
den DHCP-Server gar nie hören konnte.
Das war auch so gewollt, schließlich hatte Atti58 gefragt:
Was sagt ein "ipcofig /all" an, wenn Der DHCP-Server nicht verfügbar ist, zum GW?
Ich hatte deshalb den DHCP gespoppt, damit konnte ich auch ausschließen, daß ein zweiter DHCP noch irgendwo im Netzwerk rumfroscht. Die Zusammenhänge zwischen AutoIP und DHCP sind den meisten hier bekannt, denke ich mal.
Fazit und Troubleshooting:
1) Immer erst das Lämpchen an
Netzwerkkarte + Switch prüfen : hab ich
Link?
1) Immer erst das Lämpchen an
Netzwerkkarte + Switch prüfen : hab ich
Link?
Ja, die Lämpchen brennen.
2) Gibt es eine Verbindung zwischen Client
und Server : Ping <ServerIP> vom
Client aus
(Server muss Ping natürlich
erlauben)
und Server : Ping <ServerIP> vom
Client aus
(Server muss Ping natürlich
erlauben)
Ja, der Server erlaubt ping und ich habe einen Connect.
3) Einstellungen prüfen mit Start->
CMD-> ipconfig /all : sind mehrere
IP-Adressen gebunden? Gültigkeit der
Adresse bis wann?
CMD-> ipconfig /all : sind mehrere
IP-Adressen gebunden? Gültigkeit der
Adresse bis wann?
Nein, es ist lediglich eine IP eingebunden, die Adresse ist gültig.
4) IP-Adresse freigeben und wieder neu
beziehen: ipconfig /release und dann
ipconfig /renew.
beziehen: ipconfig /release und dann
ipconfig /renew.
Das habe ich das ein oder andere Mal gemacht, ohne Erfolg.
Gratistipp: Wenn mehrere Bindungen vorhanden
sind, einfach ein Leerschlag und Stern
nachfolgen lassen , z.B. ipconfig /release *
sind, einfach ein Leerschlag und Stern
nachfolgen lassen , z.B. ipconfig /release *
Danke!
Mit diesem Vorgehen testet man die korrekte
Funktion des DHCP
Funktion des DHCP
Aha!
5) Wenn nix geht: einfach mal eine Adresse
statisch von Hand eintragen. Die Adresse
muss aus dem dynamischen Bereich des DHCP
stammen, also bei DHCP von z.B. 192.168.1.10
bis 254 könnte man z.B. 192.168.1.250
nehmen. Ich benutze regelmässig die
hintersten Adressen, um weniger konflikte
mit bereits vergebenen Adr. zu kriegen.
Nunn muss Zufriff auf die Netzwerkressourcen
möglich sein.
statisch von Hand eintragen. Die Adresse
muss aus dem dynamischen Bereich des DHCP
stammen, also bei DHCP von z.B. 192.168.1.10
bis 254 könnte man z.B. 192.168.1.250
nehmen. Ich benutze regelmässig die
hintersten Adressen, um weniger konflikte
mit bereits vergebenen Adr. zu kriegen.
Nunn muss Zufriff auf die Netzwerkressourcen
möglich sein.
Nochmal: Ich habe kein Problem mit der Vergabe von statischen IPs. Ich habe einen DHCP konfiguriert, der alle konfigurierten Einträge an den Client sauber übergibt. Eine Ausnahme bildet das Gateway, hier wird der Eintrag von der lokalen IP des Clients überschrieben. Beim physikalischen Aushängen des Servers aus dem vorhandenen Netz übernimmt der Client in diesem MiniNetz das Gateway sauber.
An Silke: Hast Du Dein Problem schliesslich
erklären können?
erklären können?
Nein, einige alte Server sind noch im Netz, ich arbeite momentan mit DHCP und händisch eingetragenem Gateway.
Nachdem du jetzt hoffentlich alles nochmal gelesen hast, bin ich natürlich auf deine Lösung gespannt.
geTuemII
Die Adresse des Gateways muss Teil des eigenen Netzes sein. Wenn also das Netz z.B. 192.168.0.x ist mit 255.25.255.0 , dann muss der Gateway eine Zahl für X haben, die innerhalb 1..254 liegt und keine andere Adresse (geht nicht).
Hallo @all,
offenbar hat sich dieses Problemn nun endlich gelöst. Ich habe neue Switches eingebaut und in diesem Zug mal Ritchys Vermutung mit dem kaputten Switch überprüft. Offenbar war es genau das, auch wenn die Switches sonst in den letzten Jahren ihren Dienst problemlos getan haben und ich nicht wirklich eine Idee habe, wie sowas sein kann: Switch kaputt und wieder auch nicht...
Vieln Dank an alle, die zu diesem Thread einen sinnvollen Beitrag geleistet haben
geTuemII
offenbar hat sich dieses Problemn nun endlich gelöst. Ich habe neue Switches eingebaut und in diesem Zug mal Ritchys Vermutung mit dem kaputten Switch überprüft. Offenbar war es genau das, auch wenn die Switches sonst in den letzten Jahren ihren Dienst problemlos getan haben und ich nicht wirklich eine Idee habe, wie sowas sein kann: Switch kaputt und wieder auch nicht...
Vieln Dank an alle, die zu diesem Thread einen sinnvollen Beitrag geleistet haben
geTuemII
Hallo Silke,
dieser Beitrag, vor allem die Lösung, war heute bei uns aktuell! Ich habe hier einen einfachen Switch, der offenbar dafür gesorgt hat, dass die betreffende IP-Adresse der Workstation (Vista) falsch war. Statische Konfiguration der Netzwerkeinstellungen funktionierte - auch die Kommunikation über diesen Switch; die dynamische über DHCP nicht.
Herunterfahren, Ausschalten der betroffenen WS .. hat alles nichts gebracht. Andere Rechner, die den Switch nicht benutzten, funktionierten über DHCP korrekt.
Auffällig war nur, dass fast alle Lämpchen der Ports aktiv waren, auch die ohne aktives Gerät ... Die Lösung bestand darin, den Switch aus und anzuschalten. Nun geht wieder alles. Die LEDs verhalten sich wieder normal. Ich bin nur durch diesen Beitrag darauf gekommen, dass es der Switch sein kann - denn er hat bei statischer Konfiguration ja funktioniert.
Keine Ahnung, was da abläuft, etwas Grundwissen an dieser Stelle wäre für mich sicher wertvoll. Woher kommt denn die falsche IP, wenn der Switch blockt oder sich irgendwie querstellt? Auch bei uns gibt es nur einen DHCP-Server .....
Grüße
STEKER
dieser Beitrag, vor allem die Lösung, war heute bei uns aktuell! Ich habe hier einen einfachen Switch, der offenbar dafür gesorgt hat, dass die betreffende IP-Adresse der Workstation (Vista) falsch war. Statische Konfiguration der Netzwerkeinstellungen funktionierte - auch die Kommunikation über diesen Switch; die dynamische über DHCP nicht.
Herunterfahren, Ausschalten der betroffenen WS .. hat alles nichts gebracht. Andere Rechner, die den Switch nicht benutzten, funktionierten über DHCP korrekt.
Auffällig war nur, dass fast alle Lämpchen der Ports aktiv waren, auch die ohne aktives Gerät ... Die Lösung bestand darin, den Switch aus und anzuschalten. Nun geht wieder alles. Die LEDs verhalten sich wieder normal. Ich bin nur durch diesen Beitrag darauf gekommen, dass es der Switch sein kann - denn er hat bei statischer Konfiguration ja funktioniert.
Keine Ahnung, was da abläuft, etwas Grundwissen an dieser Stelle wäre für mich sicher wertvoll. Woher kommt denn die falsche IP, wenn der Switch blockt oder sich irgendwie querstellt? Auch bei uns gibt es nur einen DHCP-Server .....
Grüße
STEKER
http://de.wikipedia.org/wiki/Switch_(Computertechnik)
Eigenschaften und Funktionen, 1. Absatz.
Vermutlich hat er an dem Port irgendwann mal eine andere Station bedient oder er hat die "Lernphase" beendet und nicht gemerkt, dass eine andere/neue MAC/Adresse zu bedienen war.
Eigenschaften und Funktionen, 1. Absatz.
Vermutlich hat er an dem Port irgendwann mal eine andere Station bedient oder er hat die "Lernphase" beendet und nicht gemerkt, dass eine andere/neue MAC/Adresse zu bedienen war.
Hallo,
Vielen Dank für die schnelle Antwort. Woher kommt dann nach dem Booten der betreffenden Workstation immer wieder die gleiche Adresse bei IP-Konfig. über DHCP?
STEKER
Vielen Dank für die schnelle Antwort. Woher kommt dann nach dem Booten der betreffenden Workstation immer wieder die gleiche Adresse bei IP-Konfig. über DHCP?
STEKER
http://de.wikipedia.org/wiki/DHCP
Bitte vor dem Posten erst einmal selbst suchen. Und lass bitte alte Themen in ihrem Grab ruhen.
Bitte vor dem Posten erst einmal selbst suchen. Und lass bitte alte Themen in ihrem Grab ruhen.
Hallo zusammen,
ich ziehen mal den fred jetzt aus dem Grab.
Aufgrund von geTuemII aktion mit dem Tauschen der Switche bin ich auf die Lösung meines Problemes gekommen.
Bei mir war das gleiche Problem. iP wurde von DHCP verteilt aber der Standardgateway kam nicht mit.
Ich habe dann den Server an einen anderen Switch angeschlossen und siehe da, das SGW bekamen die client nun auch mitgeteilt.
Daraufhin habe ich ein wenig nachgeforcht und herausgefunden das man eine Option auf meine HP Switches deaktivieren mußt.
Und zwar ist es die Oprion "automatic broadcast control".
Vielleicht hilft das jemanden.
Ich jedenfalls habe mir den Wolf gesucht bis ich die Lösung hatte.
Mag sein, dass es bei aktuelleren Switches diese Option gar nicht mehr gibt.
Gruß
Charlie
ich ziehen mal den fred jetzt aus dem Grab.
Aufgrund von geTuemII aktion mit dem Tauschen der Switche bin ich auf die Lösung meines Problemes gekommen.
Bei mir war das gleiche Problem. iP wurde von DHCP verteilt aber der Standardgateway kam nicht mit.
Ich habe dann den Server an einen anderen Switch angeschlossen und siehe da, das SGW bekamen die client nun auch mitgeteilt.
Daraufhin habe ich ein wenig nachgeforcht und herausgefunden das man eine Option auf meine HP Switches deaktivieren mußt.
Und zwar ist es die Oprion "automatic broadcast control".
Vielleicht hilft das jemanden.
Ich jedenfalls habe mir den Wolf gesucht bis ich die Lösung hatte.
Mag sein, dass es bei aktuelleren Switches diese Option gar nicht mehr gibt.
Gruß
Charlie
