Es ist Montag und der Tag fängt mit einer Hiobsbotschaft von einem Kunden an, das die Telefonanlage streikt. Alle Telefone würden “Initialisierung” auf dem Display anzeigen. Ein Neustart der Telefonanlage als auch der einzelnen Telefone ändert fast nichts an diesem Zustand, ein Teil der Telefone bleibt unbenutzbar.

Nicht funktionierende Telefonie ist für nahezu jeden ein Problem, um so schlimmer wenn man eine Agentur ist, die unter anderem Call-Center-Services anbietet.

Der Kunde hat eine ältere NetPhone-Anlage (Deutsche Telekom-gelabelte Swyx) im Einsatz. Als Telefone kommen Octophone F31 (Deutsche Telekom-gelabelte Siemens optiPoint F31) zum Einsatz. Und genau an diesen Telefonen hing es letztlich, dazu gleich mehr. Die Netzwerkinfrastruktur-Dienste (AD, DHCP, DNS, …) werden von einem Microsoft Windows Small Business Server 2011 Standard (SBS) gestellt.

Die Telefone erhalten per DHCP ihre IP-Adresse, die IP-Adresse zum Netphone-Server ist wiederum fest in den Geräten konfiguriert. Manche Teilnehmer sind fest vorgegeben, soll heißen: Es wird automatisch auf Basis der MAC-Adresse des Telefons ein Teilnehmer angemeldet, andere melden sich je nachdem wo sie sitzen mit ihrer Durchwahl an.

Hinweis: Bei NetPhone/Swyx gibt es mehrere Möglichkeiten, wie bzw. woher die Telefone ihre Konfiguration erhalten. DHCP ist eine davon, manuell bzw. fest geht ebenso als auch (soweit mir bekannt) alles über’s Netz.

Spurensuche

Leider kann man am Telefon in der Initialisierungs-Phase nichts weiter machen, es steht kein Menü, Abbrechen etc. zur Verfügung. Folglich muss man sozusagen von der anderen Seite aus mit der Fehlersuche beginnen. In diesem Fall bedeutet das vom Server aus.

Bemerkung: Am Rande sei erwähnt, das diese Telefone per PoE mit Spannung versorgt werden. Es gibt eine Möglichkeit, ein Netzteil anzuschließen. Vor Ort war aber weder ein solches Netzteil noch ein unbenutzer PoE-Switch oder ein PoE-Injektor vorhanden.

Um zu sehen, was in dem Moment passiert, wenn das Telefon ans Netz geht, wurde kurzerhand Nirsoft’s SmartSniff auf dem SBS gestartet. Beobachtet man dann den Verkehr von “UDP – 0.0.0.0 – 255.255.255.255 – Service “bootpc”” (dort finden sich die DHCP-Daten) so sieht man, wie sich das Telefon am DHCP-Server meldet und die Meldung (vom Server) erhält, das die IP-Adresse bereits verwendet ist.

Da die IP bereits vergeben ist, sollte nun dem Telefon eine neue Adresse zugewiesen werden, genau das geschieht allerdings nicht. Stattdessen versucht das Telefon weiter seine alte bereits anderweitig verwendete Adresse zu verlängern.

Bemerkung: Mit anderen Geräten wie z.B. ThinClients, Notebooks und PCs vor Ort klappte der DHCP-Vorgang ohne Probleme, scheinbar ist dieses Problem auf die Telefone begrenzt gewesen.

Neustart der Telefone, ganz gleich ob Soft (per Admin-Webinterface) oder Hard (Stromlos machen…) änderte nichts an der Sache. Bei näherem Begutachten der Einstellungen im administrativen Teil des Webinterfaces eines der Telefone viel auf, das trotz aktivierten DHCP noch ein seit langem nicht mehr vorhandener DNS-Server als auch Router eingetragen ist.

Als seinerzeit der DHCP-Server migriert wurde, wurden alle aktuellen Einstellungen übernommen, scheinbar interessierte das die Telefone im Gegensatz zu allen anderen Netzwerk-Euqipment nicht.

Mit dieser Erkenntnis wurde daraufhin mittels Angry IP Scanner mal der Bereich des Netzwerks aus dem DHCP-Bereich gescannt und das Ergebnis mit den aktuellen Leases verglichen. Dabei fiel auf, das bei nahezu allen Telefonen die verwendete IP-Adresse nicht mit dem Lease im DHCP-Server übereinstimmt. Offensichtlich bestand das Problem bereits länger.

Die Lösung

Nachdem klar war, das die Telefone “auf Teufel komm raus” ihre IP zunächst nicht hergeben wollten und zu allem Unglück die vergebenen Leases nicht zu den MAC-Adressen passte, musste eine Lösung her. Die Bestand darin im DHCP-Server die Konfliktbehandlung zu aktivieren:

  • Die MMC “DHCP” öffnen.
  • Zum entsprechenden Server gehen.
  • Mit der rechten Maustaste auf “IPv4” klicken und aus dem Kontextmenü “Eigenschaften” auswählen.
  • Zur Registerkarte “Erweitert” wechseln.
  • Im Feld “Anzahl der Konflikterkennungsversuche” den Wert von “0” auf (min.) “1” ändern.
  • Auf die Schaltfläche “Übernehmen” klicken.
  • Ggf. alle Geräte, die eine IP-Adresse per DHCP erhalten neustarten.

Windows - DHCP-Server - KonflikterkennungUnd siehe da, die Telefone gaben ihre “Blockadehaltung” auf und holten sich neue IP-Adressen in dem Moment wo sie neu gestartet wurden. Letztlich war Turnschuh-Administration angesagt, jedes Telefon wurde vom Strom getrennt und neu verbunden. Anschließend wurde geprüft ob die IP-Adresse zum Lease passt.

Wie im Screenshot zu sehen, werden merhfach verwendete IP-Adressen als “BAD_ADDRESS” deklariert, die Leasezeit ist dann relativ klein (sollte ausreichen um das Problem zu lösen). Im Protokoll unter “C:\Windows\System32\dhcp” lässt sich ebenfalls der Ablauf nachvollziehen.