12
Im VLAN wird durch DHCP-Server immer die zuerst zugeteite IP vergeben
Hallo Kollegen,
ich habe da ein kleines Problem und wäre für konstruktive Beiträge dankbar:
Umgebung:
- CISCO Switches (29xx-Serie als Access-Switches, 45xx als Cores mit Routing-Funktion)
- Alle Ports sind mit genau einem VLAN behaftet
- Netzwerk 10.10.1.x / 22 (1024 Adressen) aufegteilt in 8 Sub-Netzwerke a 128 Adressen
- in den Cores werden die Netzwerke geroutet (Funktionstest hier sind erfolgreich, das Netz ist in Produktion)
- In den Cores sind die DHCP-Helper für jedes VLAN auf den DHCP-Server 10.10.1.50 eingetragen
- DHCP-Server: Windows 2003 SP3 deutsch, jedes VLAN als eigener Scope inkl. Optionen (Domain-Suffix, Gateway, DNS, ...)
Problem:
Sobald sich ein Client erstmalig in einem beliebigen Subnet angemeldet hat behät er diese IP-Adresse, auch wenn er sich an einem anderen VLAN-Port connectiert.
Umgehung des Poblems (z.Zt.): Löschen des Leases im DHCP-Server, Downen des DHCP Servers (-Dienstes), ipconfig /release auf dem Cient, Up des DHCP-Servers, ipconfig /renew. Danach wird die dem am Switch eingestellte IP angezogen und auch im DHCP-Server hinterlegt.
Aus historischen Umgebungen gibt es bei uns noch einen alten Windows2000-DHCP-Server in einem komplett anderem IP-Netz, jedoch im physikalischen LAN.
Auch dieser wir mit einem seperaten DHCP-Helper auf den Cores angesprochen und kann (eigentlich) nichts mit obigem Problem zu tun haben?
Wir schließen aufgrund der nachgewiesenen Erfahrung unseres Cisco-Beraters eine Fehlconfiguration der Switching-Umgebung aus.
Kennt jemand dieses Phänomen und hat Anregungen/Lösungen dazu?
wir planen folgende weitere Schritte:
- Prüfen der DHCP-Request-Pakete auf Vollständigkeit
- Prüfen evtl. Defekt im Log-Script der Cores.
- bei Versagen des MS-DHCP-Servers aufsetzen eines DHCP unter Linux (Debian mit ISC-DHCP).
Hat jemand zu diesem Problem Ideen?
Thx für jede sinnvolle Antwort oder Kommentar...
Bernd
ich habe da ein kleines Problem und wäre für konstruktive Beiträge dankbar:
Umgebung:
- CISCO Switches (29xx-Serie als Access-Switches, 45xx als Cores mit Routing-Funktion)
- Alle Ports sind mit genau einem VLAN behaftet
- Netzwerk 10.10.1.x / 22 (1024 Adressen) aufegteilt in 8 Sub-Netzwerke a 128 Adressen
- in den Cores werden die Netzwerke geroutet (Funktionstest hier sind erfolgreich, das Netz ist in Produktion)
- In den Cores sind die DHCP-Helper für jedes VLAN auf den DHCP-Server 10.10.1.50 eingetragen
- DHCP-Server: Windows 2003 SP3 deutsch, jedes VLAN als eigener Scope inkl. Optionen (Domain-Suffix, Gateway, DNS, ...)
Problem:
Sobald sich ein Client erstmalig in einem beliebigen Subnet angemeldet hat behät er diese IP-Adresse, auch wenn er sich an einem anderen VLAN-Port connectiert.
Umgehung des Poblems (z.Zt.): Löschen des Leases im DHCP-Server, Downen des DHCP Servers (-Dienstes), ipconfig /release auf dem Cient, Up des DHCP-Servers, ipconfig /renew. Danach wird die dem am Switch eingestellte IP angezogen und auch im DHCP-Server hinterlegt.
Aus historischen Umgebungen gibt es bei uns noch einen alten Windows2000-DHCP-Server in einem komplett anderem IP-Netz, jedoch im physikalischen LAN.
Auch dieser wir mit einem seperaten DHCP-Helper auf den Cores angesprochen und kann (eigentlich) nichts mit obigem Problem zu tun haben?
Wir schließen aufgrund der nachgewiesenen Erfahrung unseres Cisco-Beraters eine Fehlconfiguration der Switching-Umgebung aus.
Kennt jemand dieses Phänomen und hat Anregungen/Lösungen dazu?
wir planen folgende weitere Schritte:
- Prüfen der DHCP-Request-Pakete auf Vollständigkeit
- Prüfen evtl. Defekt im Log-Script der Cores.
- bei Versagen des MS-DHCP-Servers aufsetzen eines DHCP unter Linux (Debian mit ISC-DHCP).
Hat jemand zu diesem Problem Ideen?
Thx für jede sinnvolle Antwort oder Kommentar...
Bernd
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: 119556
Url: https://administrator.de/contentid/119556
Ausgedruckt am: 23.11.2024 um 03:11 Uhr
12 Kommentare
Neuester Kommentar
Erstmal ein paar Vorbemerkungen die du noch näher klären solltest:
"...nachgewiesenen Erfahrung unseres Cisco-Beraters "
Oha, sowas ist immer relativ. Jeder der schon mal ein Cisco CLI gesehen hat ist ein erfahrener Cisco Berater....!!
"Alle Ports sind mit genau einem VLAN behaftet....
Netzwerk 10.10.1.x / 22 (1024 Adressen) aufegteilt in 8 Sub-Netzwerke a 128 Adressen "
Diese Aussage ist mehr als unverständlich !!! Wenn alle Ports mit genau einem VLAN behaftet sind, dann hast du bei einem 2948 dann 48 separate VLANs bei 2 mal 2948 dann schon 96 usw. usw.
Wie bitte sehr, ist das in Einklang zu bringen mit deiner Aussage "8 Sub-Netzwerke a 128 Adressen" denn allein bei 2 Stück 2948 benötigst du ja schon 96 Subnetze sofern du eine saubere Konfiguration gemacht hat und jedes VLAN auch ein eigenes Subnetz ist ??!!
Das müsste der Berater ja auch geraten haben....
Das ist also schonmal etwas undurchsichtig in deiner Beschreibung !!
Zurück zum Problem:
Was du beschreibst kann eigentlich nicht sein. Sowie du einen Windows Rechner vom Netz trennst also das Kabel ziehst und der Link physisch runter geht wird auch die DHCP Adresse auf diesem Client geflusht. Das ist reproduzierbar in jedem Home Netzwerk nachweisbar.
Insofern ist es unverständlich das deine Clients komplett anders reagieren als der Rest der Winblows Welt ?!
Ein ip helper address Eintrag auf dem VLAN Interface bewirkt eine Kopie des UDP Broadcast Frames (bzw. das was am Cisco mit ip udp forward protocol definiert ist an Broadcast Frames) an diesem Interface durch die Switch CPU und ein Forwarding an die angegeben Helper IP Adresse. Der Switch ersetzt die Quell IP mit seiner VLAN IP damit der DHCP Server den Scope erkennen kann.
Dieses Forwarding passiert zeitgleich an ALLE helper Adressen also auch an den ollen 2000 Server sofern beide als helper definiert sind.
Wenn dieser jetzt einen entsprechenden Scope hat dann gibt es ein Wettrennen wer schneller ist. DHCP kann mit parallelen unabhängigen Servern nicht umgehen schon gar nicht Winblows DHCP Server.
Wer am schnellsten ist gewinnt also. Das kann natürlich zu Adress Tohuwabohu führen also genau dem was du auch siehst. Das wäre ein grundsätzlicher Designfehler mit DHCP Servern bzw. deren helpern das ein Berater sofort hätte sehen müssen !!
Fazit: Das ist eine Fehlkonfiguration und sollte nur dann so gemacht werden wenn für dedizierte VLANs auch dedizierte DHCP Server verantwortlich sind.
Einfach gesprochen: NUR auf den VLANs wo der 2000er Server verandwortlich ist sollte der 2k Server als helper konfiguriert sein..und nur der !
Analog beim anderen DHCP Server. Nur wo der die entsprechende VLANs bedient sollte der eingetragen werden.
Niemals beide zusammen um eine Race Situation sicher zu vermeiden !!
"...nachgewiesenen Erfahrung unseres Cisco-Beraters "
Oha, sowas ist immer relativ. Jeder der schon mal ein Cisco CLI gesehen hat ist ein erfahrener Cisco Berater....!!
"Alle Ports sind mit genau einem VLAN behaftet....
Netzwerk 10.10.1.x / 22 (1024 Adressen) aufegteilt in 8 Sub-Netzwerke a 128 Adressen "
Diese Aussage ist mehr als unverständlich !!! Wenn alle Ports mit genau einem VLAN behaftet sind, dann hast du bei einem 2948 dann 48 separate VLANs bei 2 mal 2948 dann schon 96 usw. usw.
Wie bitte sehr, ist das in Einklang zu bringen mit deiner Aussage "8 Sub-Netzwerke a 128 Adressen" denn allein bei 2 Stück 2948 benötigst du ja schon 96 Subnetze sofern du eine saubere Konfiguration gemacht hat und jedes VLAN auch ein eigenes Subnetz ist ??!!
Das müsste der Berater ja auch geraten haben....
Das ist also schonmal etwas undurchsichtig in deiner Beschreibung !!
Zurück zum Problem:
Was du beschreibst kann eigentlich nicht sein. Sowie du einen Windows Rechner vom Netz trennst also das Kabel ziehst und der Link physisch runter geht wird auch die DHCP Adresse auf diesem Client geflusht. Das ist reproduzierbar in jedem Home Netzwerk nachweisbar.
Insofern ist es unverständlich das deine Clients komplett anders reagieren als der Rest der Winblows Welt ?!
Ein ip helper address Eintrag auf dem VLAN Interface bewirkt eine Kopie des UDP Broadcast Frames (bzw. das was am Cisco mit ip udp forward protocol definiert ist an Broadcast Frames) an diesem Interface durch die Switch CPU und ein Forwarding an die angegeben Helper IP Adresse. Der Switch ersetzt die Quell IP mit seiner VLAN IP damit der DHCP Server den Scope erkennen kann.
Dieses Forwarding passiert zeitgleich an ALLE helper Adressen also auch an den ollen 2000 Server sofern beide als helper definiert sind.
Wenn dieser jetzt einen entsprechenden Scope hat dann gibt es ein Wettrennen wer schneller ist. DHCP kann mit parallelen unabhängigen Servern nicht umgehen schon gar nicht Winblows DHCP Server.
Wer am schnellsten ist gewinnt also. Das kann natürlich zu Adress Tohuwabohu führen also genau dem was du auch siehst. Das wäre ein grundsätzlicher Designfehler mit DHCP Servern bzw. deren helpern das ein Berater sofort hätte sehen müssen !!
Fazit: Das ist eine Fehlkonfiguration und sollte nur dann so gemacht werden wenn für dedizierte VLANs auch dedizierte DHCP Server verantwortlich sind.
Einfach gesprochen: NUR auf den VLANs wo der 2000er Server verandwortlich ist sollte der 2k Server als helper konfiguriert sein..und nur der !
Analog beim anderen DHCP Server. Nur wo der die entsprechende VLANs bedient sollte der eingetragen werden.
Niemals beide zusammen um eine Race Situation sicher zu vermeiden !!
Also zur Erklärung/Präzisierung:
Durch den Provider unseres VPN's sind uns 1024 IP-Adressen (10.10.0.0/22) zugeteilt (VPN-Config des ISP für eine Enterprise-Umgebung).
Innerhalb diese Netzwerkes wurden (auch unter Beachtung eines Transfer-Netzes) mehrere Subnetze angelegt (Die für den DHCP-Server relevanten Netze sind dabei in Subnetze a 128 IP-Adressen (10.10.y.x / 25 mit den Bezeichnungen VLAN10, 20, 30,... ) unterteilt.
Das entspricht 8x 128 IP-Adressen - ja, ok, vereinfacht, das erste Netzwerk 10.10.0.0 / 25 ist weiter unterteilt, sollte aber für die hier herschende Problematik kein Issue darstellen, da der DHCP-Server nur für die restlichen 7 Subnetze a 128 IP-Adressen zuständig ist
Das VLAN1 wurde auf einem (leider) noch bestehenden Prallel-Netzwerk konfiguriert (siehe unten).
Für jedes Subnetz wurde als IP-Adress-Helper der gültige DHCP-Server (welcher in einem der Subnetze VLAN5 liegt) eingetragen.
Das VLAN1 erhlielt dabei als einziges eine anderen Server (siehe unten)
Das Routing der Netze erfolgt auf zwei Core-Switche, welche in allen Subnetzen Ihre eigenen IP's (und auch den HSRP-Gateway) besitzen.
Alle Access-Switche werden im Trunk von den Cores mit allen VLAN's bedient.
Der Filter der Clients wird in den Access-Switches direkt auf das Interface konfiguriert (Cisco-Befehl: "Switchport Access Vlan xx").
Der besondere w2k-DHCP-Server wird durch einen eigenen Eintrag in den Core-Switches als DHCP-Helper für VLAN1 gesetzt.
Dieser Serveresitzt eine eigene Hardware und bedient ein eigenes öffentlich registriertes Class-B-Netzwerk , welches jedoch nur in einem VPN Verwendung findet (und demnächst abgelöst werden soll).
Beide im VPN(WAN) verfügbaren Netzwerke werden durch die ISP-Router gleichwertig unterstützt.
Der Cisco-Consultant bedient u.a. weltweit tätige Backbones von GROSSEN Banken und sollte allein aufgrund seiner Referenzliste genügend Erfahrung besitzen (Sorry, ich kann den Namen nicht nennen, aber der Mann gehört wirklich zu den Top-Networkern, und das seit ca. 15 Jahren...)
Der W2003-DHCP:
- hat in einem der VLAN's eine gültige IP
- Für jedes Sub-Netz eine gültige Einstellung inkl. Standard-Options, wie DNS, Domain-Suffix, Gateway.
Der Gag an der ganzen Sache ist ja folgender:
Ein Neuer Client erhält eine gültige Adresse im (am Cisco-Interface eingestellten) VLAN mit allen Optionen - und funktioniert.
DANN...
- ...wechselt er das Stockwerk (und damit das VLAN) und der DHCP-Server aktualisiert die IP-Einstellungen nicht. Vorhige IP-Adresse, Gateway, etc. Funktion des Clients dadurch natürlich nahezu null.
- Ein ipconfig /release gefolgt von ipconfig /renew bringt die gleiche IP-Adresse (und nicht z.B. eine RADIUS-Adresse nach MS-Standard) des vorherigen Netzwerkes (sprich des Cisco-Ports, denn dort liegt ja die VLAN-Config)
- Erst das Löschen des Leases, reboot des MS-DHCP-Servers und reconfig des Clients bringt eine gültige IP im konfigurierten VLAN.
Die Scopes sind NICHT parallell eingerichtet, Die Helpers sind für jedes VLAN einzeln korrekt definiert. -Daher sollte es keinen Wettbewerb unter den DHCP-Servern geben.
Obige Angaben wurden in den letzten Wochen mehrfach - auch von Dritten - geprüft.
Wenn jemand noch eine Idee hat -
- wir haben keine zündende mehr - bitte meldet Euch.
Durch den Provider unseres VPN's sind uns 1024 IP-Adressen (10.10.0.0/22) zugeteilt (VPN-Config des ISP für eine Enterprise-Umgebung).
Innerhalb diese Netzwerkes wurden (auch unter Beachtung eines Transfer-Netzes) mehrere Subnetze angelegt (Die für den DHCP-Server relevanten Netze sind dabei in Subnetze a 128 IP-Adressen (10.10.y.x / 25 mit den Bezeichnungen VLAN10, 20, 30,... ) unterteilt.
Das entspricht 8x 128 IP-Adressen - ja, ok, vereinfacht, das erste Netzwerk 10.10.0.0 / 25 ist weiter unterteilt, sollte aber für die hier herschende Problematik kein Issue darstellen, da der DHCP-Server nur für die restlichen 7 Subnetze a 128 IP-Adressen zuständig ist
Das VLAN1 wurde auf einem (leider) noch bestehenden Prallel-Netzwerk konfiguriert (siehe unten).
Für jedes Subnetz wurde als IP-Adress-Helper der gültige DHCP-Server (welcher in einem der Subnetze VLAN5 liegt) eingetragen.
Das VLAN1 erhlielt dabei als einziges eine anderen Server (siehe unten)
Das Routing der Netze erfolgt auf zwei Core-Switche, welche in allen Subnetzen Ihre eigenen IP's (und auch den HSRP-Gateway) besitzen.
Alle Access-Switche werden im Trunk von den Cores mit allen VLAN's bedient.
Der Filter der Clients wird in den Access-Switches direkt auf das Interface konfiguriert (Cisco-Befehl: "Switchport Access Vlan xx").
Der besondere w2k-DHCP-Server wird durch einen eigenen Eintrag in den Core-Switches als DHCP-Helper für VLAN1 gesetzt.
Dieser Serveresitzt eine eigene Hardware und bedient ein eigenes öffentlich registriertes Class-B-Netzwerk , welches jedoch nur in einem VPN Verwendung findet (und demnächst abgelöst werden soll).
Beide im VPN(WAN) verfügbaren Netzwerke werden durch die ISP-Router gleichwertig unterstützt.
Der Cisco-Consultant bedient u.a. weltweit tätige Backbones von GROSSEN Banken und sollte allein aufgrund seiner Referenzliste genügend Erfahrung besitzen (Sorry, ich kann den Namen nicht nennen, aber der Mann gehört wirklich zu den Top-Networkern, und das seit ca. 15 Jahren...)
Der W2003-DHCP:
- hat in einem der VLAN's eine gültige IP
- Für jedes Sub-Netz eine gültige Einstellung inkl. Standard-Options, wie DNS, Domain-Suffix, Gateway.
Der Gag an der ganzen Sache ist ja folgender:
Ein Neuer Client erhält eine gültige Adresse im (am Cisco-Interface eingestellten) VLAN mit allen Optionen - und funktioniert.
DANN...
- ...wechselt er das Stockwerk (und damit das VLAN) und der DHCP-Server aktualisiert die IP-Einstellungen nicht. Vorhige IP-Adresse, Gateway, etc. Funktion des Clients dadurch natürlich nahezu null.
- Ein ipconfig /release gefolgt von ipconfig /renew bringt die gleiche IP-Adresse (und nicht z.B. eine RADIUS-Adresse nach MS-Standard) des vorherigen Netzwerkes (sprich des Cisco-Ports, denn dort liegt ja die VLAN-Config)
- Erst das Löschen des Leases, reboot des MS-DHCP-Servers und reconfig des Clients bringt eine gültige IP im konfigurierten VLAN.
Die Scopes sind NICHT parallell eingerichtet, Die Helpers sind für jedes VLAN einzeln korrekt definiert. -Daher sollte es keinen Wettbewerb unter den DHCP-Servern geben.
Obige Angaben wurden in den letzten Wochen mehrfach - auch von Dritten - geprüft.
Wenn jemand noch eine Idee hat -
- wir haben keine zündende mehr - bitte meldet Euch.
OK, DHCP seitig aus Netzwerk Sicht hast du dann alles richtig gemacht. Viel falsch machen kann man da auch nicht, denn das Design ist auch nichts Besonderes sondern ein absolutes Standard VLAN Design.
Vermutlich hat es auch nichts mit dem VLAN bzw. dem Netzwerk zu tun, denn wenn du genau das Szenario in einem Laboraufbau nachstellst mit einem Linux DHCP Server funktioniert es einwandfrei.
Du solltest dich also mehr auf den DHCP Server konzentrieren bei der Suche.
2 Zusatzfragen:
1.) Ist der Top Berater einmal auf die Idee gekommen einen Sniffer in das Client Netz zu hängen und einmal die DHCP Kommunikation mitzusniffern ?? Speziell den reconnect in ein neues Netzwerk und den darauffolgenden Renew der Adresse ???
Was kommt dabei raus ?? Wo liegen die Unterschiede zu einem Szenario wo es sauber klappt ?
2.) Hast du den DHCP Server einmal getauscht gegen einen Linux DHCP Server z.B. Das lässt sich mit einer Live Boot CD in 3 Minuten aufsetzen !
Ein kleiner Laboraufbau mit nur einem Switch (oder auch 2) verifiziert dir dann die korrekte Funktion !!
Ein aktuelles IOS Image und alle MS Patches sollten ja so oder so Standard sein....
Vermutlich hat es auch nichts mit dem VLAN bzw. dem Netzwerk zu tun, denn wenn du genau das Szenario in einem Laboraufbau nachstellst mit einem Linux DHCP Server funktioniert es einwandfrei.
Du solltest dich also mehr auf den DHCP Server konzentrieren bei der Suche.
2 Zusatzfragen:
1.) Ist der Top Berater einmal auf die Idee gekommen einen Sniffer in das Client Netz zu hängen und einmal die DHCP Kommunikation mitzusniffern ?? Speziell den reconnect in ein neues Netzwerk und den darauffolgenden Renew der Adresse ???
Was kommt dabei raus ?? Wo liegen die Unterschiede zu einem Szenario wo es sauber klappt ?
2.) Hast du den DHCP Server einmal getauscht gegen einen Linux DHCP Server z.B. Das lässt sich mit einer Live Boot CD in 3 Minuten aufsetzen !
Ein kleiner Laboraufbau mit nur einem Switch (oder auch 2) verifiziert dir dann die korrekte Funktion !!
Ein aktuelles IOS Image und alle MS Patches sollten ja so oder so Standard sein....
Hallo Bernd,
also ich kenne das Problem, vorab ich habe auch keine Lösung.
Meine Umgebung ist nahzu identisch wie Deine, was mir allerdings aufgefallen ist das es manchmal funktioniert. Aber meistens eben nicht.
Als workaround reicht es normalerweise am Client ipconfig /release --> /renew durchzuführen dazu braucht man aber die entsprechenden Rechte normalerweise haben die Anwender die nicht.
Und das ist auch die Stelle wo ich den Fehler vermute.
Ich glaube das der PC eine neue IP anfordern kann aber nicht der Benutzer und da beißt sich dann irgendwas ich habe es schon mit Gruppenrichtlinien probiert aber das hilft auch nichts.
Wenn du lokaler Admin bist geht es meistens.
Wenn du eine Lösung finden solltest sag mir einfach bescheid.
Nur so als Hinweis wenn Du dann noch dot1x verwenden willst geht es gar nicht mehr ... keine Ahnung warum.
Grüße
Cuthullu
also ich kenne das Problem, vorab ich habe auch keine Lösung.
Meine Umgebung ist nahzu identisch wie Deine, was mir allerdings aufgefallen ist das es manchmal funktioniert. Aber meistens eben nicht.
Als workaround reicht es normalerweise am Client ipconfig /release --> /renew durchzuführen dazu braucht man aber die entsprechenden Rechte normalerweise haben die Anwender die nicht.
Und das ist auch die Stelle wo ich den Fehler vermute.
Ich glaube das der PC eine neue IP anfordern kann aber nicht der Benutzer und da beißt sich dann irgendwas ich habe es schon mit Gruppenrichtlinien probiert aber das hilft auch nichts.
Wenn du lokaler Admin bist geht es meistens.
Wenn du eine Lösung finden solltest sag mir einfach bescheid.
Nur so als Hinweis wenn Du dann noch dot1x verwenden willst geht es gar nicht mehr ... keine Ahnung warum.
Grüße
Cuthullu
Hallo,
welche Einstellung hast du den auf dem DHCP-Server bzgl. der Requests (DHCP, BootP oder Beides)?
DHCP-Scope --> Rechtsklick --> Registerkarte "Erweitert"
Dort sollte entweder "DHCP" oder "Beides" aktiert sein, keinesfalls aber "BootP".
mfg
Harald
welche Einstellung hast du den auf dem DHCP-Server bzgl. der Requests (DHCP, BootP oder Beides)?
DHCP-Scope --> Rechtsklick --> Registerkarte "Erweitert"
Dort sollte entweder "DHCP" oder "Beides" aktiert sein, keinesfalls aber "BootP".
mfg
Harald
Thanx,
der Sniffer wird vorr. morgen aktiviert,
Der Linux-Server ist ebenfalls in Arbeit.
der Sniffer wird vorr. morgen aktiviert,
Der Linux-Server ist ebenfalls in Arbeit.
Hi Cuthullu,
Thanx für den Beitrag - er hat mich auf eine Idee gebracht:
- Wenn es sich mit .net1 weiter verschlechtert könnte es evtl. ausschließlich an Windows Clients und derne .Net-Versio liegen.
darauf habe ich mal als Versuch einen WLAN-Acces-Point Cisco (defiinitiv OHNE Microsoft Betriebssystem) im VLAN gedreht - und siehe es funktioniert.
Jetzt habe ich die Config des DHCP-Servers geprüft und festegestellt, dass hier nut .net 3.0 und 3.5 instelliert ist.
Ich werde mal 1.0 und 2.0 nachinstallieren und schauen was da so passiert.
- Ach ja, vorher backuppen......
Testing wird Anfang nächster Woche passieren.
Melde mich sobald es was Neues gibt....
P.S.: Hallo harad21 auf dem Server ist (bis auf wenige begründete Ausnahmen) immer "beides" angehakt, da wir meines Wissens für den PXE-Boot mit der dort angehängten Installationsroutine BootP benötigen, und im Betrieb dann DHCP - ist aber ein guter Hinweis, ich werde unser Installteam mal mit der Frage belästigen, ob wir BootP überhaupt brauchen.....
Thanx für den Beitrag - er hat mich auf eine Idee gebracht:
- Wenn es sich mit .net1 weiter verschlechtert könnte es evtl. ausschließlich an Windows Clients und derne .Net-Versio liegen.
darauf habe ich mal als Versuch einen WLAN-Acces-Point Cisco (defiinitiv OHNE Microsoft Betriebssystem) im VLAN gedreht - und siehe es funktioniert.
Jetzt habe ich die Config des DHCP-Servers geprüft und festegestellt, dass hier nut .net 3.0 und 3.5 instelliert ist.
Ich werde mal 1.0 und 2.0 nachinstallieren und schauen was da so passiert.
- Ach ja, vorher backuppen......
Testing wird Anfang nächster Woche passieren.
Melde mich sobald es was Neues gibt....
P.S.: Hallo harad21 auf dem Server ist (bis auf wenige begründete Ausnahmen) immer "beides" angehakt, da wir meines Wissens für den PXE-Boot mit der dort angehängten Installationsroutine BootP benötigen, und im Betrieb dann DHCP - ist aber ein guter Hinweis, ich werde unser Installteam mal mit der Frage belästigen, ob wir BootP überhaupt brauchen.....
Hallo Bernd,
also .net 2 ist bei uns auch auf dem DHCP Server drauf und die Probleme bestehen trotzdem auf den Clients ist allerdings ab Version 1.1 alles installiert ... was ich noch nicht probiert habe ist ein Linux-Client ob es da besser ist.
Ich verstehe allerdings auch nicht was die .net damit zu tun hat. Vielleicht kannst Du das etwas erhellen.
Grüße Cuthullu
also .net 2 ist bei uns auch auf dem DHCP Server drauf und die Probleme bestehen trotzdem auf den Clients ist allerdings ab Version 1.1 alles installiert ... was ich noch nicht probiert habe ist ein Linux-Client ob es da besser ist.
Ich verstehe allerdings auch nicht was die .net damit zu tun hat. Vielleicht kannst Du das etwas erhellen.
Grüße Cuthullu
Also der Versuch mit Knoppix war erfolgreich. Es merkt sogar on the fly das das VLAN gewechselt wurde.
Dauert allerdings ein bißchen, einfacher geht es dann mit sudo dhclient -r --> sudo dhclient oder einfach den Netzwerkstecker ziehen.
Als Schlußfolgerung ziehe ich jetzt mal folgendes.
CISCO Umgebung ist OK
DHCP Server ist OK
Netzwerk ist OK
Client sprich WindowsXP SP3 und SP2 ist NICHT OK
.net 1.1 muß ich noch installieren, unser Backupteam will erst ein geprüftes vollständiges Backup vom Server (Feiglinge)))). Mir ist aber auch nach längerer Suche noch nicht klar was das mit DHCP zu tun haben könnte.
Also falls noch jemand nützliche Ideen hat wäre das bestimmt hilfreich.
PS: Bitte bitte jetzt keine Grundsatzdiskussion zu Linux und Windows anfangen das hilft nämlich gar nichts.
Cuthullu
Dauert allerdings ein bißchen, einfacher geht es dann mit sudo dhclient -r --> sudo dhclient oder einfach den Netzwerkstecker ziehen.
Als Schlußfolgerung ziehe ich jetzt mal folgendes.
CISCO Umgebung ist OK
DHCP Server ist OK
Netzwerk ist OK
Client sprich WindowsXP SP3 und SP2 ist NICHT OK
.net 1.1 muß ich noch installieren, unser Backupteam will erst ein geprüftes vollständiges Backup vom Server (Feiglinge
)))). Mir ist aber auch nach längerer Suche noch nicht klar was das mit DHCP zu tun haben könnte.Also falls noch jemand nützliche Ideen hat wäre das bestimmt hilfreich.
PS: Bitte bitte jetzt keine Grundsatzdiskussion zu Linux und Windows anfangen das hilft nämlich gar nichts.
Cuthullu
Hallo Bernd,
eine Halblösung ist es in der Registry einen Key zu ändern so das der Client bei jedem Neustart eine neue IP vom DHCP-Server zieht.
Unter:
HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Services\ Tcpip\ Enum
hier gibt es den Eintrag "NextInstance" als Datentyp REG_DWORD welcher den Wert "00000001" besitzt.
Wenn dieser Wert auf "00000000" ändern, zieht sich der Client nach einem Reboot eine neue Adresse vom DHCP- Server.
Natürlich geht das auch über Gruppenrichtlinien das ADM-File sieht dann etwa so aus:
CLASS MACHINE
CATEGORY SYSTEM\CurrentControlSet\Services\Tcpip
POLICY Enum
KEYNAME SYSTEM\CurrentControlSet\Services\Tcpip\Enum
PART 0 EDITTEXT
VALUENAME "0"
END PART
PART Count NUMERIC
VALUENAME "Count"
END PART
PART NextInstance NUMERIC
VALUENAME "NextInstance"
MIN 0 MAX 1
END PART
END POLICY
END CATEGORY
Natürlich müssen dann noch die Einträge in der Policy gesetzt werden.
Cuthullu
eine Halblösung ist es in der Registry einen Key zu ändern so das der Client bei jedem Neustart eine neue IP vom DHCP-Server zieht.
Unter:
HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Services\ Tcpip\ Enum
hier gibt es den Eintrag "NextInstance" als Datentyp REG_DWORD welcher den Wert "00000001" besitzt.
Wenn dieser Wert auf "00000000" ändern, zieht sich der Client nach einem Reboot eine neue Adresse vom DHCP- Server.
Natürlich geht das auch über Gruppenrichtlinien das ADM-File sieht dann etwa so aus:
CLASS MACHINE
CATEGORY SYSTEM\CurrentControlSet\Services\Tcpip
POLICY Enum
KEYNAME SYSTEM\CurrentControlSet\Services\Tcpip\Enum
PART 0 EDITTEXT
VALUENAME "0"
END PART
PART Count NUMERIC
VALUENAME "Count"
END PART
PART NextInstance NUMERIC
VALUENAME "NextInstance"
MIN 0 MAX 1
END PART
END POLICY
END CATEGORY
Natürlich müssen dann noch die Einträge in der Policy gesetzt werden.
Cuthullu
Hallo,
bei mir bleibt bei einem VLAN wechsel die alte IP bestehen!
könnte mir dabei auch jemand helfen?
mfg Steger
bei mir bleibt bei einem VLAN wechsel die alte IP bestehen!
könnte mir dabei auch jemand helfen?
mfg Steger
Falls du im DHCP-Server Gruppierungen für deine VLANs verwendest, müssen diese aufgehoben werden.
