Hintergrund
Ich habe einen Windows-DHCP-Server (Server 2008 R2), der Adressen für mehrere Bereiche verteilt. Einer dieser Bereiche gilt für einige Mitel IP-Telefone. Die Telefone sind so konfiguriert, dass sie die DHCP-Option 125 verwenden, um Konfigurationsinformationen abzurufen. Wenn ein Telefon gestartet wird, weiß es nicht, welches VLAN zu verwenden ist, und erhält daher nur das Standard-VLAN (ohne Tag) des Ports, mit dem es verbunden ist. Der DHCP-Server gibt eine Antwort mit Informationen zu Option 125 aus, und das Telefon kann aus dieser Antwort lesen, welches VLAN verwendet werden soll. Das Telefon gibt dann seine ursprüngliche Adresse frei und fordert unter Verwendung des richtigen vlan-Tags eine neue DHCP-Lease an. Die Telefone haben normalerweise auch Computer, die an einen Durchgangsport angeschlossen sind. Die Pakete von den Computern werden nie mit Tags versehen, sodass die PCs auf dem ursprünglichen (nicht mit Tags versehenen) VLAN für den Port verbleiben. Das funktioniert bei uns seit Jahren.
Problem und Symptome
Irgendwo in den letzten Wochen hat sich etwas geändert, und ich bin mir nicht sicher, was. Die Telefone funktionieren so lange weiter, wie sie nicht neu gestartet werden. Das bedeutet, dass DHCP-Erneuerungsanforderungen korrekt verarbeitet werden müssen. Telefone, die an bestimmte Switches angeschlossen sind, können sogar einen Neustart überstehen. Mit anderen Switches verbundene Telefone können den Vorgang jedoch nicht abschließen, wenn sie neu gestartet werden. Alle unsere Telefone verwenden PoE, das von einer USV gesichert wird. Es ist also schon lange her, dass sie neu gestartet wurden. Das heißt, ich habe keine Ahnung, wann das Problem zum ersten Mal aufgetreten ist. Was ich weiß, ist, dass ein Telefon beim gestrigen Neustart ausgefallen ist. Bei der heutigen Fehlerbehebung haben wir diesen Schaltschrank zurückgesetzt. Jetzt funktioniert keines der Telefone an diesem Schalter (zum Glück ist es immer noch eine kleine Nummer). Ich weiß auch, dass die Dinge gegen Ende Januar funktionierten,
Wenn ich sehe, wie ein Telefon hochfährt, kann ich sehen, dass es die erste Adresse erfolgreich erhält. Anschließend werden die Informationen zu Option 125 erfolgreich gelesen, das richtige vlan-Tag festgelegt und die ursprüngliche IP-Lease freigegeben. Es ist sogar in der Lage, ein Angebot auf dem richtigen VLAN vom Server zu empfangen und anzunehmen . Hier hört es jedoch auf. Auf dem Bildschirm des Telefons wird die Meldung " DHCP: Offer 2 ACC" angezeigt , aber der Windows-DHCP-Server hat die Lease nicht aufgezeichnet, und das Telefon wird niemals weitergeführt. Ich kann nur vermuten, dass das DHCP-Anforderungspaket den Windows-Server nie erreicht, und das Telefon wartet auf die endgültige Bestätigung von Windows, dass es in Ordnung ist, fortzufahren.
Umgehung
Ich konnte endlich wieder ein Telefon in Betrieb nehmen. Dazu musste ich zuerst den Computer trennen. Dann habe ich den Switch-Port des Telefons so eingestellt, dass er auf dem Telefon-VLAN nicht markiert ist und keine Mitgliedschaft auf dem PC-VLAN aufweist. Das Telefon wird jetzt korrekt neu gestartet. An diesem Punkt kann ich die Switch-Port-Konfiguration wieder auf den gewünschten Wert zurücksetzen. Solange beim Zurücksetzen des Ports niemand versucht, diese Nummer anzurufen, lässt das Telefon keinen Takt aus. Dann kann ich den Computer wieder anschließen. Offensichtlich ist das kein idealer Prozess, aber da Telefone so selten neu gestartet werden, kann ich damit die Leute wieder zum Arbeiten bringen, bis ich die Grundursache gefunden habe. Die Büros sind jetzt für die Woche geschlossen, sodass diese Ausgabe über das Wochenende verteilt werden kann (ich habe keine Schlüssel für einzelne Büros, in denen sich die Telefone befinden).
Dieses Telefon, das ich repariert habe, ist das Service-Telefon im Serverraum, das direkt mit unserem Core-Switch verbunden ist. Möglicherweise liegt das Problem beim Weiterleiten oder Verarbeiten von Tags auf dem Core-Switch vor, sodass die Problemumgehung an den Remotestandorten, an denen Pakete zuerst durch andere Switches geleitet (von diesen getaggt) werden, nicht effektiv ist, aber ich bin sehr überrascht Wenn dies passiert, muss ich wissen, dass DHCP-Erneuerungen und tatsächliche Telefongespräche korrekt verarbeitet werden.
Ein Twist ist, dass das Verlassen des Ports auf dem PC-VLAN bedeutet, dass das Telefon stattdessen mit der Meldung " DHCP: Offer 1 ACC" ausfällt . Ich muss dieses vlan vollständig entfernen, damit dies gelingt.
Hinweis: Ich habe jetzt bestätigt, dass die Problemumgehung in abgelegenen Gebäuden wirksam ist. Dies lässt mich vermuten, dass meine Geräte irgendwie nicht dem richtigen VLAN zugeordnet sind. Die Tatsache, dass das Problem bei meinem Core-Switch aufgetreten ist und dass es an mehreren Stellen im Netzwerk ungefähr zur gleichen Zeit aufgetreten ist, deutet darauf hin, dass der Core-Switch möglicherweise das Problem ist. Da nichts Besonderes zu sehen ist, plane ich gegen Ende der Woche ein Wartungsfenster, um den Switch neu zu starten. Ich kann auch die Firmware aktualisieren.
Umgebung
Unser Core-Switch ist ein HP 5406zl. Dieser Switch verwaltet das Inter-VLAN-Routing. Der Windows-DHCP-Server ist direkt mit dem Switch verbunden. Endpoint-Switches sind über Glasfaser-SFPs mit dem Core-Switch verbunden, und diese Ports sind für alle vlans an beiden Enden markiert. Der Core Switch konfiguriert jedes vlan mit einer ip helper-addressEinstellung, die es auf unseren DHCP-Server verweist, und einer dhcp relay-option 82 replaceZeile, damit der DHCP-Server den zu verwendenden Bereich erkennt. Diese Konfigurationen und die Portkonfigurationen auf den Endpoint-Switches haben sich seit mindestens 16 Monaten nicht geändert. In dieser Zeit wurden andere Schalter und Telefone zurückgesetzt.
Bei den meisten unserer Endpunktschalter handelt es sich um die HP 2530-Serie. Diese Schalter scheinen korrekt zu funktionieren (Telefone auf 3 verschiedenen 2530s wurden heute korrekt neu gestartet). Es sind ältere Switches, die Probleme haben. Wir haben einen alten 3Com 4200 und einen 4210, die nicht funktionieren werden. Das Service-Telefon, das direkt an den oben erwähnten Core-Switch angeschlossen ist, funktioniert ebenfalls nicht.
Frage
An diesem Punkt ist meine beste Vermutung, dass ein Windows-Update auf dem DHCP-Server das Verhalten geändert hat, aber ich kann nicht sehen, wie. Oder möglicherweise verarbeitet der Core-Switch dieses REQUEST-Paket nicht richtig, aber ich bin sicher, dass sich dort nichts geändert hat, und es erklärt nicht, warum nur bestimmte Endpoint-Switches betroffen sind. Wie kann ich dieses Problem beheben?
Aktualisieren:
Hier ist ein DHCP-Protokollauszug von einem ausgefallenen Telefon:
10,03 / 06 / 15,12: 40: 40, Zuweisen, 10.1.2.158,, 08000F197844,, 3189088995,0 ,,, 11,03 / 06 / 15,12: 40: 40, Erneuern, 10.1.2.158, , 08000F197844,, 3189088995,0 ,,, 12,03 / 06 / 15,12: 40: 41, Release, 10.1.2.158,, 08000F197844,, 3189088995,0 ,,, 15,03 / 06 / 15,12: 40: 45, NACK, 10.1.2.154, 08000F197844, 0,6 ,,, 15,03 / 06 / 15,12: 40: 45, NACK, 10.1.2.154, 08000F197844, 0,6 ,,,
Die 10.xxx-Adressen sind das PC-VLAN (diese Auswahl datiert mich an dieser Stelle vor). Telefone sollten zuerst diese Art von Adresse erhalten, das wird also erwartet. Nach der Freigabemeldung erwarte ich jedoch auch, ein Angebot für eine Adresse im Bereich 192.168.16.x zu finden, da ich auf dem Telefon sehen kann, dass ein Angebot angenommen wurde (sofern ich "ACC" nicht falsch interpretiere). Es ist interessant, dass der Server nie versucht, eine solche Adresse auszugeben, obwohl das Telefon denkt, dass es eine Adresse erhalten hat.
Ich dachte, es gibt einen falschen DHCP-Server im Netzwerk (der eine Adresse vor dem Windows-Server ausgibt, aber ohne die DHCP-Optionen, die das Telefon benötigt, um fortzufahren), aber das erklärt nicht, warum die Telefone genau dann funktionieren, wenn Ich entferne vollständig jeden Pfad zum PC-VLAN. Ich werde es trotzdem morgens testen, indem ich meinen Laptop an einen für das Telefon-VLAN festgelegten Anschluss anschließe. Wenn jedoch in der Zwischenzeit jemand eine bessere Erklärung hat, würde ich es gerne hören.
Hier ist eine Kopie der Switch-Konfiguration:
quelle
Antworten:
Ich habe das Problem heute behoben, indem ich das VLAN-Tag für das Telefon-VLAN auf dem Port, der mit unserem DHCP-Server verbunden ist, entfernt habe. Es ist für mich sehr merkwürdig, dass dies funktioniert, da andere Systeme, die ein ähnliches Schema verwenden (auch bekannt als: Wifi-SSIDs mit 802.1q), das Tag benötigen oder Clients keine Adressen abrufen können. Es hat funktioniert, also werde ich nicht zu genau hinschauen, aber ich wäre daran interessiert, Antworten mit Theorien zu finden, warum dies so ist.
quelle
Sie sollten in Betracht ziehen, auf beiden Seiten der problematischen Switches eine Paketerfassung durchzuführen und diese dann in Wireshark zu überprüfen. Dies kann Ihnen mitteilen, 1) ob der Datenverkehr von einem nicht autorisierten DHCP-Server (basierend auf der MAC-Adresse) abgefangen wird und 2) ob etwas beschädigt oder fallengelassen wird (z. B. benötigen Sie ein DHCP-Relay). Dies erfordert möglicherweise eine Portspiegelung, oder die 3com unterstützt die Erfassung direkt am Switch.
quelle
Wenn Sie feststellen, dass dieses Problem erneut auftritt, möchten Sie möglicherweise die Größe Ihres DHCP-Bereichs und die Anzahl der verwendeten Leases überprüfen. Wenn alte DHCP-Leases nicht zerstört werden, ist Ihr Server möglicherweise der Ansicht, dass keine Adressen mehr im Pool vorhanden sind, und kann keine neuen Adressen zuweisen. Dies gilt auch dann, wenn im vlan keine Geräte reagieren. Wenn Ihr DHCP-Bereich 7 Tage beträgt, kann es bis zu 7 Tage dauern, bis Sie eine neue Lease erhalten können. Ebenso kann das Problem durch Ändern der Konfiguration behoben werden, da ein neuer Adressbereich vorhanden ist, der ausgebucht werden kann, oder die Leases werden abhängig von den Konfigurationsänderungen gelöscht. Ich würde vorschlagen, die Laufzeit des Leasingvertrags auf einen sehr niedrigen Wert festzulegen, z. B. eine Stunde für diesen Zeitraum, wenn dies der Fall ist.
quelle