Latar Belakang
Saya memiliki server Windows DHCP (Server 2008 R2) yang membagikan alamat untuk beberapa cakupan. Salah satu cakupannya adalah untuk beberapa Ponsel IP Mitel. Telepon dikonfigurasikan untuk menggunakan opsi dhcp 125 untuk mendapatkan informasi konfigurasi. Ketika telepon dinyalakan, ia tidak tahu vlan mana yang harus digunakan, sehingga hanya mendapat vlan default (tidak ditandai) dari port apa pun yang terhubung dengannya. Server dhcp memberikan respons yang mencakup opsi 125 informasi, dan telepon dapat membaca vlan apa yang harus digunakan dari respons ini. Telepon kemudian melepaskan alamat aslinya dan meminta sewa dhcp baru menggunakan tag vlan yang benar. Ponsel juga biasanya memiliki komputer yang terhubung ke port pass-through. Paket-paket dari komputer tidak pernah ditandai, sehingga PC akan tetap menggunakan vlan asli (tidak ditandai) untuk porta. Ini telah bekerja untuk kita selama bertahun-tahun.
Masalah dan Gejala
Di suatu tempat dalam beberapa minggu terakhir, sesuatu berubah, dan saya tidak yakin apa. Ponsel akan terus berfungsi selama tidak restart, artinya permintaan perpanjangan dhcp harus diproses dengan benar. Ponsel yang terhubung ke sakelar tertentu bahkan dapat bertahan hidup dengan restart. Namun, telepon yang terhubung ke sakelar lain akan gagal untuk menyelesaikan proses tersebut ketika mereka mem-boot ulang. Semua ponsel kami menggunakan PoE yang didukung oleh UPS, jadi sudah lama sejak ada yang restart. Ini berarti saya tidak tahu kapan masalah pertama kali muncul. Apa yang saya tahu adalah bahwa satu telepon gagal ketika dihidupkan kembali kemarin, dan dalam pemecahan masalah hari ini kita mereset lemari saklar itu. Sekarang tidak ada telepon di saklar yang berfungsi (untungnya itu masih sejumlah kecil). Saya juga tahu bahwa segala sesuatunya bekerja pada akhir Januari,
Ketika saya menonton telepon menyala, saya bisa melihatnya berhasil mendapatkan alamat pertama. Itu kemudian berhasil membaca informasi opsi 125, menetapkan tag vlan yang benar, dan melepaskan sewa IP asli. Bahkan dapat menerima dan menerima tawaran pada vlan yang benar dari server . Namun, di situlah segalanya berhenti. Ponsel ini memiliki pesan di layar yang bertuliskan, " DHCP: Offer 2 ACC", tetapi server Windows DHCP belum mencatat sewa dan telepon tidak pernah bergerak. Saya hanya bisa menebak bahwa paket DHCP REQUEST tidak pernah mencapai server Windows, dan karena itu telepon sedang menunggu ACK final dari Windows yang boleh dilanjutkan.
Penanganan masalah
Saya akhirnya bisa membuat telepon berfungsi kembali. Untuk melakukannya, saya harus memutuskan dulu komputer. Kemudian saya mengatur port switch telepon menjadi untagged pada vlan ponsel, tanpa keanggotaan pada vlan PC. Telepon sekarang akan reboot dengan benar. Pada titik ini, saya dapat meletakkan konfigurasi port switch kembali ke tempat yang seharusnya, dan selama tidak ada yang mencoba memanggil nomor itu saat saya mereset portnya, telepon tidak akan pernah berhenti berdetak. Kemudian saya dapat menghubungkan kembali komputer. Jelas, itu bukan proses yang ideal, meskipun karena ponsel reboot jadi jarang saya akan dapat menggunakannya untuk membuat orang bekerja lagi sampai saya dapat menemukan akar penyebabnya. Kantor ditutup sekarang untuk minggu ini, dan masalah ini sebenarnya akan diizinkan untuk duduk selama akhir pekan (saya tidak punya kunci untuk masing-masing kantor di mana telepon berada).
Telepon yang saya perbaiki ini adalah telepon layanan di ruang server, yang terhubung langsung ke sakelar inti kami. Mungkin masalahnya adalah masalah dengan perutean atau pemrosesan tag pada switch inti, sehingga solusinya tidak akan efektif pada kantor jarak jauh di mana paket pertama kali melewati (ditandai oleh) switch lain, tapi saya akan sangat terkejut jika itu terjadi, mengingat bahwa saya tahu itu harus memproses pembaruan dhcp dan percakapan telepon yang sebenarnya dengan benar.
Kelokan adalah bahwa meninggalkan port yang ditandai pada PC vlan berarti telepon itu gagal dengan pesan " DHCP: Offer 1 ACC". Saya perlu menghapus vlan itu sepenuhnya agar ini berhasil.
Catatan: Saya sekarang telah mengkonfirmasi bahwa solusi efektif di bangunan terpencil. Ini membuat saya curiga bahwa perangkat saya entah bagaimana tidak ditugaskan ke vlan yang benar. Fakta bahwa saya mengalami masalah pada sakelar inti saya, dan hal itu terjadi di beberapa tempat di jaringan pada waktu yang bersamaan, menunjukkan bahwa sakelar inti mungkin merupakan masalahnya. Dengan tidak ada yang spesifik untuk dilihat, saya menjadwalkan jendela pemeliharaan di dekat akhir minggu untuk me-reboot switch. Saya juga dapat memperbarui firmware.
Lingkungan Hidup
Sakelar inti kami adalah HP 5406zl. Switch ini menangani perutean antar-vlan. Server Windows DHCP terhubung langsung ke sakelar. Switch endpoint terhubung ke switch inti melalui SFP serat, dan port ini ditandai untuk semua vlan di kedua ujungnya. Sakelar inti mengkonfigurasi setiap vlan dengan ip helper-addresspengaturan yang mengarahkannya ke server DHCP kami, dan sebuah dhcp relay-option 82 replacegaris sehingga server dhcp akan mengetahui ruang lingkup apa yang akan digunakan. Konfigurasi ini, dan konfigurasi port pada sakelar titik akhir, belum berubah setidaknya dalam 16 bulan. Kami memiliki sakelar dan pengaturan ulang telepon lainnya pada waktu itu.
Sebagian besar saklar titik akhir kami adalah HP 2530 series. Sakelar ini tampaknya berfungsi dengan benar (ponsel pada 3 2530 yang berbeda telah dimulai ulang dengan benar hari ini). Switch lama yang memiliki masalah. Kami memiliki satu 3Com 4200 dan satu 4210 yang tidak berfungsi. Telepon layanan yang terhubung langsung ke sakelar inti yang disebutkan sebelumnya juga tidak akan berfungsi.
Pertanyaan
Pada titik ini tebakan terbaik saya adalah bahwa pembaruan Windows pada server dhcp mengubah perilaku, tetapi saya tidak bisa melihat caranya. Atau mungkin core switch tidak menangani paket REQUEST dengan benar, tapi saya yakin tidak ada yang berubah di sana, dan itu tidak menjelaskan mengapa hanya switch endpoint tertentu yang terpengaruh. Bagaimana saya bisa mengatasi masalah ini?
Memperbarui:
Berikut ini kutipan dhcp log dari ponsel yang gagal:
10,03 / 06 / 15,12: 40: 40, Assign, 10.1.2.158,, 08000F197844,, 3189088995,0 ,,, 11,03 / 06 / 15,12: 40: 40, Renew, 10.1.2.158, , 08000F197844,, 3189088995,0 ,,, 12,03 / 06 / 15,12: 40: 41, Rilis, 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: NACK, 10.1.2.154,, 08000F197844,, 0,6 ,,,
Alamat 10.xxx adalah PC vlan (pilihan tersebut membuat saya lebih dulu berkencan di tempat ini). Ponsel seharusnya mendapatkan alamat semacam itu pada awalnya, jadi itu sudah diharapkan. Namun, setelah pesan rilis saya juga berharap untuk menemukan tawaran untuk alamat di kisaran 192.168.16.x, karena saya dapat melihat di telepon bahwa tawaran diterima (kecuali saya salah menafsirkan "ACC"). Sangat menarik bahwa saya tidak pernah melihat server mencoba mengeluarkan alamat seperti itu, meskipun telepon berpikir itu menerima satu.
Saya menganggap ide ada server dhcp jahat di jaringan (membagikan alamat sebelum server Windows, tetapi tanpa opsi dhcp yang diperlukan oleh ponsel untuk melanjutkan), tetapi itu tidak menjelaskan mengapa ponsel berfungsi jika dan hanya jika Saya benar-benar menghapus jalan apa pun ke PC vlan. Saya akan mengujinya di pagi hari dengan menghubungkan laptop saya ke port yang ditetapkan untuk telepon vlan, tetapi jika ada orang lain yang memiliki penjelasan yang lebih baik untuk saat ini, saya ingin mendengarnya.
Berikut adalah salinan konfigurasi sakelar:
sumber
Jawaban:
Saya memperbaiki masalah hari ini dengan menghapus tag vlan untuk vlan telepon pada port yang terhubung ke server dhcp kami. Sangat aneh bagi saya bahwa ini berhasil, karena sistem lain yang menggunakan skema serupa (alias: Wifi SSID menggunakan 802.1q) memerlukan tag atau klien tidak bisa mendapatkan alamat. Itu berhasil, jadi saya tidak akan terlihat terlalu keras, tetapi saya akan tertarik melihat jawaban dengan teori mengapa ini seperti itu.
sumber
Anda harus mempertimbangkan menjalankan penangkapan paket di kedua sisi sakelar yang bermasalah dan kemudian memeriksanya di Wireshark. Ini akan dapat memberi tahu Anda 1) jika lalu lintas sedang dicegat oleh server DHCP jahat (berdasarkan alamat MAC) dan 2) jika ada sesuatu yang rusak atau jatuh (misalnya, mungkin Anda perlu relay DHCP). Ini mungkin memerlukan mirroring port, atau 3com dapat mendukung penangkapan langsung pada sakelar.
sumber
Jika Anda menemukan bahwa masalah ini muncul lagi, Anda mungkin ingin memeriksa ukuran lingkup DHCP Anda dan berapa banyak sewa yang digunakan. Jika sewa DHCP lama tidak dihancurkan, server Anda mungkin berpikir bahwa tidak ada alamat yang tersisa di kumpulan ini dan tidak dapat menetapkan alamat baru. Ini benar bahkan jika tidak ada perangkat yang merespons di vlan. Jika ruang lingkup DHCP Anda adalah 7 hari, bisa jadi 7 hari sebelum Anda bisa mendapatkan sewa baru. Demikian juga, mengubah konfigurasi Anda akan menyelesaikan masalah karena akan ada rentang alamat baru yang dapat dihilangkan, atau mungkin menyiram sewa tergantung pada perubahan konfigurasi. Saya akan menyarankan mengatur masa sewa untuk sesuatu yang sangat rendah, seperti satu jam untuk ruang lingkup itu jika ini masalahnya.
sumber