Arka fon
Çeşitli kapsamların adreslerini dağıtan bir Windows DHCP sunucum (Server 2008 R2) var. Bu kapsamlardan biri bazı Mitel IP Telefonları içindir. Telefonlar, yapılandırma bilgilerini almak için dhcp seçeneği 125 kullanacak şekilde yapılandırılmıştır. Bir telefon başladığında, hangi vlanın kullanılacağını bilmez ve bu nedenle bağlı olduğu herhangi bir bağlantı noktasının varsayılan (etiketsiz) vlanını alır. Dhcp sunucusu, seçenek 125 bilgilerini içeren bir yanıt verir ve telefon, bu yanıttan hangi vlan'ı kullanması gerektiğini okuyabilir. Telefon daha sonra orijinal adresini yayınlar ve doğru vlan etiketini kullanarak yeni bir dhcp kiralaması ister. Telefonlarda genellikle doğrudan geçiş bağlantı noktasına bağlı bilgisayarlar bulunur. Bilgisayarlardan gelen paketler asla etiketlenmez ve böylece PC'ler bağlantı noktasının orijinal (etiketsiz) vlanında kalır. Bu bizim için yıllarca çalıştı.
Sorun ve Belirtileri
Son birkaç haftada bir yerlerde bir şeyler değişti ve ne olduğundan emin değilim. Telefonlar yeniden başlatılmadıkları sürece çalışmaya devam eder, yani dhcp yenileme isteklerinin doğru bir şekilde işlenmesi gerekir. Bazı anahtarlara bağlı telefonlar yeniden başlatma durumunda bile hayatta kalabilir. Ancak, diğer anahtarlara bağlı olan telefonlar, yeniden başlatıldıklarında işlemi tamamlayamazlar. Tüm telefonlarımız bir UPS tarafından desteklenen PoE kullanıyor, bu nedenle yeniden başlatıldığından beri uzun zaman geçti. Bu, sorunun ilk ortaya çıktığı zaman hiçbir fikrim olmadığı anlamına gelir. Bildiğim şey, bir telefonun dün yeniden başlatıldığında başarısız olması ve bugün sorun gidermede bu anahtar dolabını sıfırlamamız. Şimdi bu anahtardaki telefonların hiçbiri çalışmıyor (neyse ki hala küçük bir sayı). Ayrıca Ocak ayının sonuna doğru işlerin yürüdüğünü de biliyorum,
Bir telefonun önyüklemesini izlerken, ilk adresi başarıyla aldığını görebiliyorum. Daha sonra seçenek 125 bilgisini başarıyla okur, doğru vlan etiketini ayarlar ve orijinal IP kiralamasını serbest bırakır. Sunucudan doğru vlanda bir teklif alabilir ve kabul edebilir . Ancak, işlerin durduğu yer burası. Telefonun ekranında " DHCP: Offer 2 ACC" yazan bir mesaj var , ancak Windows DHCP sunucusu kiralama işlemini kaydetmedi ve telefon hiçbir zaman devam etmiyor. Sadece DHCP TALEBİ paketinin hiçbir zaman Windows sunucusuna ulaşmadığını tahmin edebilirim ve bu nedenle telefon Windows'tan son ACK'yı beklemeye devam etmeyi bekliyor.
Geçici çözüm
Sonunda bir telefonu tekrar çalıştırabildim. Bunu yapmak için önce bilgisayarın bağlantısını kesmem gerekti. Sonra telefonun anahtar bağlantı noktasını PC vlanına üye olmadan telefonun vlanında etiketlenmemiş olarak ayarladım. Telefon şimdi doğru şekilde yeniden başlatılacak. Bu noktada, anahtar bağlantı noktası yapılandırmasını olması gerektiği yere geri koyabilirim ve bağlantı noktasını sıfırladığımda kimse bu numarayı aramaya çalışmadığı sürece, telefon asla bir atlamayı kaçırmaz. Sonra bilgisayarı yeniden bağlayabilirim. Açıkçası, bu ideal bir süreç değildir, ancak telefonlar çok nadiren yeniden başlatıldığından, kök nedeni bulana kadar insanların tekrar çalışmasını sağlamak için kullanabiliyorum. Ofisler artık hafta boyunca kapalı ve bu nedenle bu sorunun aslında hafta sonu oturmasına izin verilecek (telefonların bulunduğu bireysel ofisler için anahtarlarım yok).
Düzelttiğim bu telefon, sunucu odasındaki, doğrudan ana anahtarımıza bağlı servis telefonudur. Sorun, çekirdek anahtardaki etiketlerin yönlendirilmesi veya işlenmesiyle ilgili bir sorun olabilir, böylece geçici çözüm, paketlerin ilk olarak diğer anahtarlardan geçtiği (etiketlendiği) uzak ofislerde etkili olmayacaktır, ancak çok şaşıracağım bu olursa, dhcp yenilemelerini ve gerçek telefon görüşmelerini doğru bir şekilde işlemesi gerektiğini bildiğim göz önüne alındığında.
Bir bükülme, bağlantı noktasının PC vlanında etiketli bırakılması, telefonun " DHCP: Offer 1 ACC" mesajıyla başarısız olduğu anlamına gelir . Bunun başarılı olması için o vlanı tamamen kaldırmam gerekiyor.
Not: Artık geçici çözümlerin uzak binalarda etkili olduğunu onayladım. Bu, cihazlarımın bir şekilde doğru vlana atanmadığından şüphelenmemi sağlıyor. Çekirdek anahtarımda sorun yaşadığım ve bunun ağ üzerinde birkaç yerde aynı anda meydana gelmesi, çekirdek anahtarın sorun olabileceğini gösteriyor. Bakmak için özel bir şey yok, ben anahtarı yeniden başlatmak için hafta sonuna yakın bir bakım penceresi planlıyorum. Ürün yazılımını da güncelleyebilirim.
çevre
Çekirdek anahtarımız bir HP 5406zl'dir. Bu anahtar, vlanlar arası yönlendirmeyi idare eder. Windows DHCP sunucusu doğrudan anahtara bağlanır. Uç nokta anahtarları çekirdek anahtarına fiber SFP'ler aracılığıyla bağlanır ve bu bağlantı noktaları her iki uçtaki tüm vlanslar için etiketlenir. Çekirdek anahtar, her vlanı ip helper-addressDHCP sunucumuza yönlendiren bir ayar dhcp relay-option 82 replaceve dhcp sunucusunun hangi kapsamı kullanacağını bilmesi için bir hat ile yapılandırır . Bu yapılandırmalar ve uç nokta anahtarlarındaki bağlantı noktası yapılandırmaları en az 16 ay içinde değişmemiştir. O zamanlar başka anahtar ve telefon sıfırlamaları yaptık.
Uç nokta anahtarlarımızın çoğu HP 2530 serisidir. Bu anahtarlar düzgün çalışıyor gibi görünüyor (3 farklı 2530'lu telefonlar bugün doğru şekilde yeniden başlatıldı). Sorunları olan eski anahtarlar. Bir eski 3Com 4200 ve bir 4210 çalışmaz. Daha önce belirtilen çekirdek anahtarına doğrudan bağlı olan servis telefonu da çalışmaz.
Soru
Bu noktada en iyi tahminim, dhcp sunucusundaki bir Windows güncellemesinin davranışı değiştirdiği, ancak nasıl olduğunu göremiyorum. Ya da muhtemelen çekirdek anahtar bu REQUEST paketini doğru şekilde işlemiyor, ancak orada hiçbir şeyin değişmediğinden eminim ve neden sadece belirli uç nokta anahtarlarının etkilendiğini açıklamıyor. Bu sorunu nasıl çözebilirim?
Güncelleme:
Başarısız bir telefondan bir dhcp günlüğü alıntısı:
10,03 / 06 / 15,12: 40: 40, Ata, 10.1.2.158,, 08000F197844,, 3189088995,0 ,,, 11,03 / 06 / 15,12: 40: 40, Yenile, 10.1.2.158, , 08000F197844,, 3189088995,0 ,,, 12,03 / 06 / 15,12: 40: 41, Sürüm, 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 ,,,
10.xxx adresleri PC vlanıdır (bu seçim bana bu yerden önce gelir). Telefonlar önce bu tür bir adres almalı, bu yüzden beklenen bir şey. Ancak, sürüm mesajından sonra 192.168.16.x aralığında bir adres için bir teklif bulmayı bekliyorum, çünkü telefonda bir teklifin kabul edildiğini görebiliyorum ("ACC" yi yanlış yorumlamadığım sürece). Telefonun bir adres aldığını düşünmesine rağmen sunucunun böyle bir adres vermeye çalıştığını görmek ilginç.
Ağda hileli bir dhcp sunucusu olduğu fikrini düşündüm (Windows sunucusundan önce bir adres dağıtıyor, ancak devam etmek için telefonun ihtiyaç duyduğu dhcp seçenekleri olmadan), ancak telefonların neden yalnızca ve PC vlanına giden herhangi bir yolu tamamen kaldırırım. Her neyse, sabahları telefonumu telefon vlan için ayarlanan bir bağlantı noktasına bağlayarak test edeceğim, ancak bu arada başka biri daha iyi bir açıklamaya sahipse, duymak isterim.
Anahtar yapılandırmasının bir kopyası: