Windows DHCP Server Warteschlange einsehen

[Skysnake]

Mir ist jetzt auch nicht sofort klar, warum ein redesign des Netzes downtime bedeutet. Man muss halt dann Routen. Wenn ihr das benutzt ist die Auflösung der IPs ja kein Thema.

Wenn ihr kein DNS nutzt sondern statische IPs geht es auch. Man muss halt einen Service nach dem anderen umziehen und gut ist. So ganz erkenne ich das Problem aktuell nicht.

Aber nett ein ClassB Netz mit öffentlichen IPs sein eigen nennen zukönnen

 

[aemonblackfyre]

Na dann hast du doch deine Lösung ? Die Zahl nehmen nochmal +20% und ihr habt erstmal kein Problem. Wenn euch natürlich die IPs ausgehen weil ihr mittlerweile Sau wertvolle Public IPs für Clients nutzt kommt ihr um einen redesing nicht herum.

uns gehen ja nicht die öffentlichen Adressen aus. So ein Class B hält ja doch relativ lange.

Und nein das ist nicht die Lösung weil es eben nicht so einfach geht. Wir können das bestehende Netz ja nicht vergrößern müssen also so oder so die Rechner mit einem neuen Netz versehen was wir ja auch grade machen.

Die Frage war ja, wie wir rausfinden, wie viele Rechner akut Leases benötigen um zu wissen, wie viele bzw. welche Abteilungen wir umziehen müssen ins neue Netz um den nötigen Platz zu generieren und wieder zu gewährleisten, dass alle Rechner online sind.

Mal davon abgesehen dass selbst ein /22 Netz schon sehr groß ist und wir immer auf die Finger geklopft bekommen von der Netzabteilung weil die Switche teilweise Probleme bekommen bei den ganzen Broadcast sachen die unterwegs sind also wäre es auch keine Option einfach das Netz immer größer werden zu lassen selbst wenn das technisch möglich wäre.

Mir ist jetzt auch nicht sofort klar, warum ein redesign des Netzes downtime bedeutet. Man muss halt dann Routen. Wenn ihr das benutzt ist die Auflösung der IPs ja kein Thema.

Wenn ihr kein DNS nutzt sondern statische IPs geht es auch. Man muss halt einen Service nach dem anderen umziehen und gut ist. So ganz erkenne ich das Problem aktuell nicht.

Aber nett ein ClassB Netz mit öffentlichen IPs sein eigen nennen zukönnen

Naja erstmal müssen wir natürlich eine Bestandsaufnahme machen eine komplette Liste erstellen, welches Gerät wo steht an welchem Port und das dauert nunmal bei tausenden Arbeitsplätzen relativ lange. Es muss dann von einer anderen Abteilung das Netz auf die jeweiligen Kupfer Ports geschaltet werden und von einer wieder anderen auf die Glasfaser die den Switch beliefert der dann das Büro mit Kupfer versorgt. Das dauert alles seine Zeit.
Außerdem würde nach dem Umzug erstmal die Hotline glühen weil natürlich alle möglichen Programme in Firewallprobleme reinlaufen die einem garnichtmehr bewusst sind.

In einer perfekten Welt wäre das alles kein Problem und man hätte eine solche Doku schon und könnte einfach sagen ersetzt das öffentliche VLAN an Standort a mit dem neuen privaten für Standort a und das öffentliche VLAN an Standort b mit dem privaten für b. Und könnte auch die Regeln in der Firewall 1:1 umziehen. Das existiert aber alles nicht.

Aber naja wir kommen vom Thema ab, was ja eigentlich auch schon gelöst ist. Wir haben jetzt unsere Lösung um die nicht beantworteten Anfragen zu loggen und sehen ungefährt wie häufig das vorkommt.

 

[Skysnake]

Die Frage war ja, wie wir rausfinden, wie viele Rechner akut Leases benötigen um zu wissen, wie viele bzw. welche Abteilungen wir umziehen müssen ins neue Netz um den nötigen Platz zu generieren und wieder zu gewährleisten, dass alle Rechner online sind.

WireShark und den DHCP traffic snoopen. Das ist ja das schöne daran das es Broadcasts sind. Die sieht jeder.

Ich verstehe deine Probleme absolut. Ihr solltet das aber eventuell mal als Anlass nehmen eure Prozesse insgesamt zu reviewn. Ihr solltet nicht Angst haben größere Änderungen auch mal zu testen. Denn ein Rollback sollte nie länger als ein paar Minuten dauern. Das gibt Sicherheit auch mal ne 99% Lösung zu deployen.

Aber klar wenn da X Abteilungen dran sind ist es immer schwierig. Bei uns hat es sich bewährt da Teams zu bilden die zusammen arbeiten. Also Adhoc. Da ist es dann egal wer in welcher Abteilung arbeitet. Aber dafür müssen die Leute aber auch Entscheidungskompetenz haben...

 

[M-X]

Versteh mich nicht falsch (ist wirklich nicht Persönlich gemeint!) aber die "X involvierten Abteilungen" und "Tausenden Arbeitsplätze" hört sich für schon nach einem größeren Unternehmen an. Da finde ich es schon dilettantisch und erschreckend das man hier im Forum nach einer DHCP lease Warteschlagen fragt und auch offensichtlich keine Doku besteht (Firewall Regeln die wohl keiner Kennt) und bei einer Änderung der Betrieb zusammenbricht. Hier schient ein strukturelles Problem zu sein. Ihr müsst wirklich an den Prozessen und der Doku arbeiten.

Ich hoffe die IT Security Leute sind besser drauf bei euch

Ihr solltet das vielleicht wirklich zum Anlass nehmen hier mal ein paar Änderungen vorzunehmen

Für mich macht das Warteschlangen Ding auch nach wie vor keinen Sinn. Denkt ihr die Leute hocken da alle vor dem PC ohne Netzwerk und warten? Die meisten werden feststellen das nix geht und die Kiste wieder ausschalten oder die Hotline anrufen, da wirst du kein gutes Bild über die Clients bekommen die einen Request haben. Und selbst wenn du alle Requests sammelst wirst du viele Duplikate etc haben, das musst du dann filtern. Das ist alles Arbeit die man lieber in ein zukunftsfähiges Netz und bessere Prozesse steckt als an den Symptomen zu arbeiten.

 

[Raijin]

Mal davon abgesehen dass selbst ein /22 Netz schon sehr groß ist und wir immer auf die Finger geklopft bekommen von der Netzabteilung weil die Switche teilweise Probleme bekommen bei den ganzen Broadcast sachen die unterwegs sind also wäre es auch keine Option einfach das Netz immer größer werden zu lassen selbst wenn das technisch möglich wäre.

Das wäre ein Grund für die besagte Segmentierung, von der ich sprach. Mit VLANs verkleinert man die Braodcastdomänen und somit wird auch der Broadcasttraffic minimiert bzw. je VLAN gekapselt.

WireShark und den DHCP traffic snoopen. Das ist ja das schöne daran das es Broadcasts sind. Die sieht jeder.

In der Tat. Wenn man auf dem Server mittels WireShark und Filter "dhcp" mitschneidet, sieht man am Server neben einigen anderen potentiellen Meldungen (zB DHCP Release) :

DHCP Discover - (suche nach DHCP-Server)
Client ---> Broadcast

DHCP Offer - (Angebot einer IP vom Server an den Client)
Server ---> Client

DHCP Request - (Tatsächliche Anforderung des Clients für diese IP)
Client -----> Broadcast (mit ID des Servers aus der vorherigen Offer)

DHCP ACK - (Bestätigung der Zuteilung durch den Server)
Server ----> Client


Discover und Request sind Broadcasts und somit überall im Netzwerk sichtbar. Offer und ACK (oder auch NACK) sind allerdings Unicasts und daher nur am Server bzw. Client zu sehen. Deswegen ist WireShark direkt auf dem Server am besten aufgehoben, wenn man den DHCP-Traffic vollständig mitschneiden will.

 

[aemonblackfyre]

Versteh mich nicht falsch (ist wirklich nicht Persönlich gemeint!) aber die "X involvierten Abteilungen" und "Tausenden Arbeitsplätze" hört sich für schon nach einem größeren Unternehmen an. Da finde ich es schon dilettantisch und erschreckend das man hier im Forum nach einer DHCP lease Warteschlagen fragt und auch offensichtlich keine Doku besteht (Firewall Regeln die wohl keiner Kennt) und bei einer Änderung der Betrieb zusammenbricht. Hier schient ein strukturelles Problem zu sein. Ihr müsst wirklich an den Prozessen und der Doku arbeiten.

Ich hoffe die IT Security Leute sind besser drauf bei euch

Ihr solltet das vielleicht wirklich zum Anlass nehmen hier mal ein paar Änderungen vorzunehmen

Für mich macht das Warteschlangen Ding auch nach wie vor keinen Sinn. Denkt ihr die Leute hocken da alle vor dem PC ohne Netzwerk und warten? Die meisten werden feststellen das nix geht und die Kiste wieder ausschalten oder die Hotline anrufen, da wirst du kein gutes Bild über die Clients bekommen die einen Request haben. Und selbst wenn du alle Requests sammelst wirst du viele Duplikate etc haben, das musst du dann filtern. Das ist alles Arbeit die man lieber in ein zukunftsfähiges Netz und bessere Prozesse steckt als an den Symptomen zu arbeiten.

Die Nutzer hängen sich dann ins WLAN und nutzen den VPN.

Keine Angst ich komme eher aus der Client Administration aber aktuell sind wir Urlaubs und Krankheitsbedingt etwas gebeutelt weshalb die Server Ecke schon genug damit zu tun hat den Laden am laufen zu halten.
Bei mir schlagen eben Nutzer auf, die nicht bzw sporadisch ins Netz kommen weshalb ich mich etwas dem Problem angenommen habe.

Du schätzt die User übrigens völligst falsch ein. Viele sind permanent im VPN und WLAN und per LAN verbunden weil sie es eben nicht besser wissen oder wieder vergessen haben.

Wir haben ja wie gesagt jetzt auch unsere Lösung über den Eventviewer und das per Skript automatisiert.

Die Änderungen führen wir durch wo es für uns möglich ist. Das meiste liegt aber nicht in unseren Händen und ist durch viel Bürokratie zugenagelt.
Wir haben uns die neuen Netze erkämpft und machen das jetzt sukzessive.

Ich weiß auch nicht wo du ein Problem damit siehst in einem Forum nach Ideen zu fragen.
Wie man das Problem löst spielt doch keine Rolle das Ziel ist wichtig nicht der Lösungsweg. Wir sind hier ja nicht in der Schule.