Amir Jabbari
وقتی تلفن روی Configuring IP می‌ماند، معمولاً هنوز درگیر Voice VLAN، DHCP و تنظیمات اولیه شبکه است. اما اگر دستگاه IP معتبر دارد و به مرحله Registering رسیده، باید بیشتر سراغ DNS، TFTP یا Provisioning، فایل تنظیمات و در نهایت CUCM یا SIP Server بروید.
در این راهنما مسیر Boot تلفن Cisco را مرحله‌به‌مرحله باز می‌کنیم تا بتوانید فقط با مشخص‌کردن آخرین مرحله موفق، محدوده مشکل را کوچک کنید. تمرکز اصلی روی خانواده‌های Cisco 78xx و 88xx است و تفاوت Enterprise/CUCM با MPP/3PCC نیز در جاهایی که اهمیت دارد مشخص می‌شود.
تشخیص سریع: اگر تلفن هنوز IP ندارد، CUCM و SIP را فعلاً کنار بگذارید. اگر IP، Gateway و VLAN درست است ولی روی Registering مانده، DHCP پایه احتمالاً کامل شده و باید مرحله بعدی زنجیره را بررسی کنید.
تلفن Cisco هنگام روشن‌شدن چه مراحلی را طی می‌کند؟
برای عیب‌یابی درست باید Boot را به چند مرحله جدا تقسیم کنیم. ممکن است جزئیات میان Firmwareها متفاوت باشد، اما منطق کلی در محیط CUCM تقریباً چنین است:
| مرحله | تلفن چه کاری انجام می‌دهد؟ | اگر اینجا گیر کرد |
|---|---|---|
| ۱. Link / VLAN | لینک شبکه بالا می‌آید و Voice VLAN از CDP/LLDP یا تنظیمات دیگر مشخص می‌شود | سوئیچ، Voice VLAN، CDP و LLDP را بررسی کنید |
| ۲. DHCP | IP، Mask، Gateway، DNS و معمولاً TFTP دریافت می‌شود | Configuring IP معمولاً به این محدوده مربوط است |
| ۳. DNS/TFTP | تلفن Server را پیدا می‌کند و فایل‌های Trust/Configuration را می‌گیرد | Option 150، DNS، Routing، Firewall و TFTP را بررسی کنید |
| ۴. Registration | تلفن به CUCM یا SIP Server معرفی می‌شود | MAC، Device Config، SIP/CUCM، TLS و Authentication را بررسی کنید |
Configuring IP دقیقاً یعنی چه؟
وقتی تلفن روی Configuring IP می‌ماند، معمولاً هنوز نتوانسته مجموعه تنظیمات پایه IPv4 را کامل کند. در حالت DHCP، تلفن باید یک Lease معتبر شامل IP Address، Subnet Mask و Default Gateway دریافت کند.
اگر شبکه Voice VLAN دارد، قبل از DHCP باید تلفن روی VLAN درست قرار گرفته باشد. اگر دستگاه روی VLAN اشتباه DHCP بفرستد، ممکن است IP اشتباه دریافت کند یا هیچ Serverی پاسخ ندهد.
بنابراین برای Configuring IP مسیر صحیح عیب‌یابی این است:
Voice VLAN → DHCP DORA → Gateway → DNS/TFTP Option
نه اینکه مستقیماً CUCM را Restart کنیم.
DHCP DORA چیست و کدام مرحله ممکن است خراب شود؟
DORA نام کوتاه چهار پیام اصلی DHCP است:
| مرحله | پیام | معنی |
|---|---|---|
| D | DHCP Discover | تلفن دنبال DHCP Server می‌گردد |
| O | DHCP Offer | Server یک IP و گزینه‌های شبکه پیشنهاد می‌دهد |
| R | DHCP Request | تلفن Lease پیشنهادی را درخواست می‌کند |
| A | DHCP ACK | Server Lease و Optionهای نهایی را تأیید می‌کند |
اگر Discover از تلفن خارج می‌شود اما Offer نمی‌آید، DHCP Server، VLAN Transport، Relay یا DHCP Snooping را بررسی کنید.
اگر Offer می‌آید ولی ACK کامل نمی‌شود، Packet Capture کمک می‌کند مشخص شود Request یا پاسخ نهایی در کدام سمت قطع شده است.
اول Voice VLAN را بررسی کنید
اگر Cisco Phone در شبکه‌ای با Voice VLAN قرار دارد، تلفن باید قبل از گرفتن IP VLAN صحیح را یاد بگیرد.
روی Catalyst وضعیت Interface را ببینید:
show interfaces GigabitEthernet1/0/12 switchportAccess VLAN و Voice VLAN را جداگانه بررسی کنید.
بعد وضعیت همسایه را با CDP ببینید:
show cdp neighbors detailیا اگر LLDP-MED استفاده می‌کنید:
show lldp neighbors detailاگر تلفن Voice VLAN را یاد نگرفته باشد، DHCP ممکن است روی Data VLAN انجام شود و دستگاه IP اشتباه بگیرد.
📌 نکته مرتبط: اگر تلفن IP شبکه Data را می‌گیرد، مشکل را قبل از DHCP Server در Voice VLAN، CDP و LLDP-MED دنبال کنید. اگر Voice VLAN صحیح است ولی هیچ IP دریافت نمی‌شود، آن‌وقت DHCP Relay، Scope و Snooping اهمیت بیشتری پیدا می‌کنند.
با Packet Capture بفهمید DORA کجا متوقف شده است
برای Configuring IP یکی از بهترین فیلترهای Wireshark این است:
dhcp || bootpبعد تلفن را Reboot کنید و ترتیب Discover، Offer، Request و ACK را ببینید.
اگر فقط Discover دیده می‌شود، تلفن درخواست را فرستاده اما Server پاسخ نداده یا پاسخ در مسیر برگشت Drop شده است.
اگر هر چهار مرحله کامل است، Configuring IP نباید صرفاً به نبود Lease مربوط باشد. حالا IP، Gateway، VLAN و Optionهای DHCP را بررسی کنید.
DHCP ACK فقط IP نیست
در DHCP ACK فقط آدرس IP مهم نیست. Cisco Phone ممکن است اطلاعات دیگری مثل DNS و TFTP Server را نیز از DHCP بگیرد.
در محیط CUCM، Cisco همچنان Option 150 را برای معرفی TFTP Server توصیه می‌کند و در صورت نبود آن Option 66 نیز قابل استفاده است.
بنابراین ممکن است تلفن IP گرفته باشد اما چون TFTP Address ندارد، از مرحله شبکه عبور کند و بعد در Registration یا Activation متوقف شود.
اگر IP گرفته، دقیقاً چه چیزهایی را روی تلفن بررسی کنیم؟
در Network Status یا IPv4 Setup این اطلاعات را یادداشت کنید:
🔹 IP Address
🔹 Subnet Mask
🔹 Default Router
🔹 DNS Server
🔹 Operational VLAN ID
🔹 TFTP Server 1 و 2 در Enterprise
🔹 CUCM Serverهای شناخته‌شده در صورت نمایش
راهنمای مانیتورینگ فعلی Cisco برای 8800 نیز همین دسته اطلاعات را از وضعیت شبکه تلفن قابل مشاهده می‌داند.
تلفن از Configuring IP عبور کرد؛ حالا DNS را بررسی کنید
اگر سرورها با FQDN تعریف شده‌اند، DNS مرحله حیاتی بعدی است.
ممکن است تلفن IP، Gateway و حتی TFTP Server داشته باشد اما نتواند نام CUCM یا Provisioning Server را Resolve کند.
از یک سیستم داخل همان شبکه می‌توانید بررسی اولیه انجام دهید:
nslookup cucm.example.netدر Wireshark نیز:
dnsاگر Query از تلفن خارج می‌شود اما Response نمی‌آید، DNS Server یا مسیر شبکه را بررسی کنید.
TFTP در کدام مرحله وارد می‌شود؟
در تلفن Enterprise/CUCM، بعد از اینکه دستگاه تنظیمات پایه شبکه و TFTP Server را پیدا کرد، باید فایل‌های لازم را از TFTP دریافت کند.
در Registration Process رسمی SIP، تلفن ابتدا فایل‌های Trust لازم را بررسی می‌کند و بعد فایل تنظیمات مخصوص دستگاه را درخواست می‌کند.
فایل اصلی معمولاً ساختاری شبیه این دارد:
SEP001122AABBCC.cnf.xmlبخش MAC در مثال بالا ساختگی است.
این Configuration File اطلاعاتی از جمله Call Manager Group، سرورها، پورت‌ها و تنظیمات لازم برای ادامه Registration را در اختیار تلفن قرار می‌دهد.
اگر فایل SEP پیدا نشود چه اتفاقی می‌افتد؟
اگر TFTP پاسخ می‌دهد اما فایل مخصوص دستگاه وجود ندارد، مشکل با Timeout فرق دارد.
در راهنمای Cisco برای 7800، پیام CFG File Not Found می‌تواند زمانی دیده شود که تلفن در دیتابیس CUCM وجود ندارد و Configuration File برای آن ساخته نشده است.
در این حالت MAC Address روی تلفن را با Device Name داخل CUCM مقایسه کنید.
مسیر کلی در CUCM:
Device → Phone
تلفن را با MAC پیدا کنید و مطمئن شوید مدل و Device Pool درست هستند.
Configuring IP با Registering چه تفاوت عملی دارد؟
| پیام | مرحله محتمل | تمرکز اصلی |
|---|---|---|
| Configuring IP | پیش از تکمیل شبکه | VLAN، DHCP DORA، Relay، Snooping |
| IP گرفته ولی TFTP Error | Provisioning | Option 150، DNS، Routing، TFTP |
| Registering | ثبت روی Call Control | CUCM/SIP، Config File، MAC، TLS/Auth |
وقتی روی Registering گیر کرده، چه چیزی را بررسی کنیم؟
اگر تلفن IP دارد، Gateway درست است، TFTP را می‌شناسد و Configuration File را دریافت کرده اما همچنان روی Registering می‌ماند، اکنون باید Call Control را بررسی کنید.
در Enterprise/CUCM این موارد مهم‌اند:
MAC Address دستگاه باید دقیقاً در CUCM ثبت شده باشد. Configuration File باید CUCM Server مناسب را معرفی کند. Cisco CallManager Service باید فعال باشد و مسیر TCP/TLS بین تلفن و Nodeهای CUCM برقرار باشد.
اگر Cluster از Security و TLS استفاده می‌کند، CTL/ITL، Certificate و Trust نیز وارد عیب‌یابی می‌شوند.
Registration در SIP چه تفاوتی دارد؟
در MPP یا Third-Party SIP، Registering الزاماً به CUCM مربوط نیست.
تلفن ممکن است تلاش کند به SIP Proxy یا Registrar متصل شود و پیام SIP REGISTER بفرستد.
در این سناریو باید این موارد را بررسی کنید:
🔹 Proxy / Registrar Address
🔹 SIP Transport: UDP، TCP یا TLS
🔹 SIP Port
🔹 User ID و Authentication ID
🔹 Password
🔹 DNS در صورت استفاده از FQDN
🔹 Certificate و NTP در صورت TLS
اگر SIP REGISTER به Server می‌رسد اما پاسخ Authentication یا Reject دریافت می‌شود، دیگر DHCP مشکل اصلی نیست.
با Packet Capture مرحله Registering را تشخیص دهید
برای SIP می‌توانید از این فیلتر Wireshark شروع کنید:
sipبرای پورت‌های رایج:
tcp.port == 5060 || udp.port == 5060 || tcp.port == 5061اگر هیچ REGISTER از تلفن خارج نمی‌شود، تنظیم Proxy یا Provisioning را بررسی کنید.
اگر REGISTER خارج می‌شود ولی هیچ پاسخی نمی‌رسد، Routing یا Firewall مطرح است.
اگر 401 دریافت می‌شود و بعد REGISTER همراه Authorization ارسال می‌شود، این می‌تواند بخشی از Authentication عادی SIP باشد.
اگر در نهایت 403 یا چرخه مداوم Authentication دارید، Credential، Realm و تنظیم Account را بررسی کنید.
در CUCM چطور بفهمیم تلفن اصلاً تلاش به Registration کرده؟
در CUCM Administration ابتدا Device را با MAC جست‌وجو کنید.
اگر دستگاه اصلاً وجود ندارد و Auto Registration نیز استفاده نمی‌شود، تلفن فایل و Registration درست دریافت نخواهد کرد.
اگر Device وجود دارد ولی Register نمی‌شود، CallManager Trace و لاگ Endpoint را روی همان Timestamp بررسی کنید.
Cisco برای مشکلات Unregistration نیز توصیه می‌کند اطلاعات Phone، PRT/Console Logs، CUCM Traces و در صورت نیاز Packet Capture با یک بازه زمانی مشترک جمع‌آوری شوند.
Operational VLAN ID را فراموش نکنید
ممکن است تلفن IP داشته باشد اما از VLAN اشتباه IP گرفته باشد. این حالت بسیار خطرناک‌تر از «IP نگرفتن» است چون ظاهراً شبکه سالم به نظر می‌رسد.
در صفحه Network Status به Operational VLAN ID نگاه کنید.
اگر قرار بوده تلفن در VLAN 20 باشد ولی Operational VLAN برابر 10 است، قبل از TFTP و CUCM به Voice VLAN برگردید.
اگر PC پشت تلفن اینترنت دارد ولی تلفن روی Configuring IP است
این اتفاق کاملاً ممکن است.
PC معمولاً روی Data VLAN است و تلفن روی Voice VLAN. سالم‌بودن PC فقط ثابت می‌کند Access VLAN و پورت فیزیکی تا حدی کار می‌کنند؛ تضمین نمی‌کند Voice VLAN، DHCP Voice Scope یا Relay سالم باشند.
پس جمله «کامپیوتر اینترنت دارد، پس شبکه تلفن سالم است» نتیجه‌گیری درستی نیست.
DHCP Snooping بعد از فعال‌سازی
اگر Configuring IP دقیقاً بعد از فعال‌شدن DHCP Snooping شروع شده، مسیر Trust را بررسی کنید.
show ip dhcp snooping
show ip dhcp snooping bindingاگر پاسخ DHCP از پورت Untrusted وارد شود، ممکن است Offer یا ACK Drop شود.
📌 مقاله مرتبط: اگر مشکل درست بعد از فعال‌سازی DHCP Snooping شروع شده است، راهنمای رفع مشکل نگرفتن IP بعد از فعال‌سازی DHCP Snooping را نیز بررسی کنید.
یک Capture کامل برای کل Boot بگیرید
اگر می‌خواهید بدون حدس مشکل را پیدا کنید، Capture را قبل از روشن‌شدن تلفن شروع کنید و تا رسیدن به Configuring IP یا Registering ادامه دهید.
بعد به ترتیب این فیلترها را بررسی کنید:
dhcp || bootp
dns
tftp
sip
tlsهرجا جریان قطع شد، همان مرحله محدوده مشکل را مشخص می‌کند.
نمونه Timeline سالم
یک Boot سالم Enterprise می‌تواند تقریباً چنین الگویی داشته باشد:
| زمان نمونه | رخداد |
|---|---|
| 00:00 | Link Up و Voice VLAN |
| 00:02 | DHCP Discover |
| 00:02 | DHCP Offer |
| 00:03 | DHCP Request / ACK |
| 00:04 | DNS یا TFTP Request |
| 00:05 | دریافت فایل Configuration |
| 00:06+ | تلاش برای Registration روی CUCM |
زمان‌های جدول فقط برای نمایش ترتیب هستند و معیار سرعت واقعی همه مدل‌ها محسوب نمی‌شوند.
جدول نهایی تشخیص بر اساس آخرین مرحله موفق
| آخرین چیزی که کار می‌کند | مرحله بعدی خراب است | چه چیزی را بررسی کنیم؟ |
|---|---|---|
| Link Up | VLAN/DHCP | CDP، LLDP، Voice VLAN، DHCP Discover |
| DHCP Discover | DHCP Response | Relay، Scope، Snooping، VLAN Transport |
| DHCP ACK | DNS/TFTP | DNS، Option 150، Routing و TFTP |
| TFTP Request | Config File | SEP<MAC>.cnf.xml و CUCM Device |
| Config File Download | Registration | CUCM/SIP Server، MAC، Service، TLS/Auth |
| SIP REGISTER | Server Response/Auth | 401/403، Credentials، Firewall و Registrar |
چه زمانی Factory Reset کنیم؟
Factory Reset نباید اولین کار برای Configuring IP یا Registering باشد.
اگر DHCP Offer نمی‌رسد، Reset شبکه را درست نمی‌کند. اگر Voice VLAN خراب است، Reset سوئیچ را اصلاح نمی‌کند. اگر Option 150 اشتباه است، Reset باعث نمی‌شود DHCP مقدار دیگری بدهد.
Reset بیشتر زمانی مطرح است که تلفن از محیط دیگری منتقل شده، Alternate TFTP قدیمی دارد، Trust List یا Provisioning قدیمی باقی مانده و بعد از ثبت تنظیمات لازم می‌خواهید دستگاه را از وضعیت پاک دوباره راه‌اندازی کنید.
پرسش‌های رایج
Configuring IP در Cisco Phone یعنی چه؟
معمولاً یعنی تلفن هنوز تنظیمات شبکه موردنیاز خود را کامل نکرده است. Voice VLAN، DHCP DORA، IP، Mask، Gateway و در بعضی سناریوها DHCP Options باید بررسی شوند.
چرا PC پشت تلفن کار می‌کند ولی Cisco Phone روی Configuring IP مانده؟
PC و تلفن می‌توانند روی VLANهای متفاوت باشند. سالم‌بودن Data VLAN تضمین نمی‌کند Voice VLAN یا DHCP Scope مخصوص تلفن سالم باشد.
اگر Cisco Phone IP گرفته ولی Registering است، DHCP سالم است؟
بخش اصلی تخصیص IP احتمالاً کامل شده، اما هنوز باید بررسی شود Optionهای لازم مثل TFTP Server درست دریافت شده‌اند. بعد از آن DNS، TFTP، فایل تنظیمات و CUCM یا SIP Server مطرح هستند.
Option 150 چه نقشی دارد؟
در Enterprise/CUCM، Cisco استفاده از DHCP Option 150 را برای اعلام TFTP Server توصیه می‌کند. تلفن برای دریافت Configuration File به این سرور نیاز دارد.
چرا تلفن Configuration File را پیدا نمی‌کند؟
ممکن است TFTP Server اشتباه باشد، مسیر شبکه بسته باشد یا تلفن با MAC اشتباه در CUCM ثبت شده باشد و فایل SEP مخصوص آن تولید نشده باشد.
Registering در MPP یعنی CUCM مشکل دارد؟
نه لزوماً. MPP می‌تواند به یک SIP Proxy یا Registrar ثالث وصل شود. در این حالت Proxy، Port، Transport، Credential، DNS و در TLS گواهی و ساعت دستگاه بررسی می‌شوند.
برای تشخیص سریع چه Captureای بگیریم؟
Capture را از لحظه Boot شروع کنید و DHCP، DNS، TFTP، SIP و TLS را به ترتیب بررسی کنید. اولین مرحله‌ای که درخواست یا پاسخ در آن قطع می‌شود، بهترین سرنخ برای محل مشکل است.
تلفن بین Configuring IP و Registering گیر کرده و علت مشخص نیست؟
اگر چند تلفن هم‌زمان در مراحل مختلف Boot متوقف شده‌اند، بهتر است Voice VLAN، DHCP، TFTP و Call Server به‌صورت یک زنجیره بررسی شوند. تغییر تصادفی تنظیمات Endpoint معمولاً فقط تشخیص را سخت‌تر می‌کند.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
جمع‌بندی
برای Cisco Phone که روی Configuring IP یا Registering گیر کرده، مهم‌ترین کار پیدا کردن آخرین مرحله موفق است. اگر DHCP DORA کامل نشده، سراغ CUCM نروید. اگر IP دارید ولی TFTP پیدا نمی‌شود، DHCP Option، DNS و Routing را بررسی کنید. اگر Configuration File دریافت شده ولی تلفن Register نمی‌شود، حالا CUCM، SIP، MAC، Authentication و Trust اهمیت دارند.
با همین روش مرحله‌ای می‌توانید به‌جای تغییر هم‌زمان چند بخش شبکه، محل مشکل را از میان Voice VLAN، DHCP، DNS، TFTP و Call Control جدا کنید.
دیدگاه‌ها (۰)