Amir Jabbari
در تلفن‌های Cisco MPP، زمان معمولاً از NTP گرفته می‌شود و سپس Time Zone و Offset روی زمان UTC اعمال می‌شوند. به همین دلیل ممکن است خود NTP کاملاً سالم باشد اما تلفن دقیقاً ۱ ساعت یا ۳ ساعت و ۳۰ دقیقه اختلاف نشان دهد.
در این راهنما ابتدا مشخص می‌کنیم مشکل «همگام‌سازی زمان» است یا «نمایش زمان محلی»، سپس NTP، DHCP Option 42 و Option 2، Time Zone، DST و در نهایت اثر ساعت اشتباه روی Certificate و ارتباط‌های امن را بررسی می‌کنیم.
تشخیص سریع: اگر ساعت چند ساعت اختلاف ثابت دارد، معمولاً Time Zone یا DHCP Time Offset را بررسی کنید. اگر تاریخ کاملاً اشتباه است یا بعد از Boot روی یک تاریخ قدیمی می‌آید، NTP Reachability مهم‌تر است. اگر اختلاف دقیقاً یک ساعت است، DST اولین مظنون است.
تلفن Cisco ساعت را از کجا می‌گیرد؟
در Cisco MPP چند منبع می‌توانند روی زمان تلفن اثر بگذارند.
مهم‌ترین منبع NTP Server است. تلفن هنگام Boot تلاش می‌کند به Primary NTP Server وصل شود و زمان را همگام کند. در صورت استفاده از Secondary NTP، سرور دوم می‌تواند نقش پشتیبان داشته باشد.
همچنین بعضی شبکه‌ها NTP Server را از DHCP Option 42 و Time Offset را از DHCP Option 2 در اختیار تلفن قرار می‌دهند.
در بعضی Firmwareها و سناریوها SIP Date Header یا تنظیم دستی نیز می‌تواند زمان را تحت‌تأثیر قرار دهد، اما NTP معمولاً منبع اصلی و قابل‌اعتمادتر است.
فرق NTP با Time Zone چیست؟
این دو را با هم اشتباه نگیرید.
NTP زمان مرجع را معمولاً بر اساس UTC/GMT در اختیار تلفن می‌گذارد.
Time Zone مشخص می‌کند برای نمایش ساعت محلی چه مقدار به UTC اضافه یا از آن کم شود.
مثلاً اگر NTP ساعت UTC را درست بدهد ولی Time Zone روی GMT باشد، کاربری که در ایران است ساعت را ۳ ساعت و ۳۰ دقیقه عقب می‌بیند.
| بخش | کار | نشانه خرابی |
|---|---|---|
| NTP | همگام‌سازی تاریخ و زمان مرجع | تاریخ یا ساعت کاملاً نادرست |
| Time Zone | تبدیل UTC به زمان محلی | اختلاف چند ساعت ثابت |
| DST | تغییر فصلی ساعت | اختلاف دقیقاً یک ساعت |
| DHCP Time Offset | اعلام Offset توسط DHCP | Time Zone تلفن درست است ولی ساعت همچنان جابه‌جاست |
مرحله ۱: Primary و Secondary NTP Server را بررسی کنید
در راهنمای فعلی Cisco MPP، تنظیم NTP در رابط وب از بخش System انجام می‌شود.
مسیر:
Admin Login → Advanced → Voice → System
در بخش Optional Network Configuration این دو فیلد را بررسی کنید:
🔹 Primary NTP Server
🔹 Secondary NTP Server
هرکدام می‌توانند IP Address یا Hostname باشند.
نمونه Provisioning:
<Primary_NTP_Server ua="rw">192.0.2.10</Primary_NTP_Server>
<Secondary_NTP_Server ua="rw">192.0.2.11</Secondary_NTP_Server>IPهای بالا فقط نمونه مستندسازی هستند.
اگر NTP Server به‌صورت Hostname است، DNS هم وارد ماجرا می‌شود
اگر به‌جای IP نوشته‌اید:
ntp.example.netتلفن باید اول بتواند این نام را Resolve کند.
بنابراین اگر NTP کار نمی‌کند، DNS Server و DNS Server Order را نیز بررسی کنید.
در یک سیستم داخل همان شبکه می‌توانید تست اولیه بگیرید:
nslookup ntp.example.netمرحله ۲: NTP Reachability را بررسی کنید
داشتن آدرس درست NTP به این معنی نیست که تلفن واقعاً به آن دسترسی دارد.
NTP معمولاً از UDP Port 123 استفاده می‌کند.
بین Voice VLAN و NTP Server این موارد را بررسی کنید:
🔹 Routing
🔹 ACL
🔹 Firewall
🔹 VRF
🔹 NAT در صورت وجود
🔹 خود سرویس NTP روی Server
Ping موفق فقط ثابت می‌کند ICMP عبور می‌کند؛ موفق‌بودن Ping اثبات نمی‌کند UDP/123 هم باز است.
بهترین روش: Packet Capture روی زمان Boot
Capture را قبل از روشن‌شدن تلفن شروع کنید و منتظر درخواست NTP بمانید.
در Wireshark:
ntpیا:
udp.port == 123اگر Request از تلفن خارج می‌شود ولی Response نمی‌آید، مسیر شبکه یا NTP Server را بررسی کنید.
اگر هیچ Request دیده نمی‌شود، تنظیم NTP Server یا DHCP Option را بررسی کنید.
DHCP Option 42 چه نقشی دارد؟
Cisco MPP از DHCP Option 42 برای دریافت NTP Server پشتیبانی می‌کند.
یعنی DHCP Server می‌تواند علاوه بر IP و Gateway، آدرس NTP Server را نیز به Endpoint بدهد.
در Capture DHCP ACK بررسی کنید آیا Option 42 واقعاً وجود دارد یا نه.
در Wireshark:
dhcp || bootpبعد DHCP ACK را باز کنید و دنبال Option 42 بگردید.
DHCP Option 2 چیست؟
Option 2 برای Time Offset استفاده می‌شود.
این Option مشخص می‌کند زمان محلی چه Offsetی نسبت به UTC/GMT دارد.
اما یک نکته بسیار مهم در Cisco MPP وجود دارد: گزینه Ignore DHCP Time Offset.
اگر این گزینه روی Yes باشد، تلفن Time Offset ارسالی DHCP را نادیده می‌گیرد و از Time Zone و Time Offset محلی خودش استفاده می‌کند.
طبق مستندات فعلی Cisco، مقدار پیش‌فرض این گزینه Yes است.
چرا DHCP Time Offset درست است ولی ساعت تغییر نمی‌کند؟
اگر Option 2 را روی DHCP تنظیم کرده‌اید اما تلفن همان Time Zone خودش را استفاده می‌کند، احتمالاً:
Ignore DHCP Time Offset = Yes
است.
برای استفاده از Offset DHCP باید این رفتار را آگاهانه تغییر دهید.
در Provisioning:
<Ignore_DHCP_Time_Offset ua="na">Yes</Ignore_DHCP_Time_Offset>مرحله ۳: Time Zone را بررسی کنید
تنظیمات Time Zone در Cisco MPP معمولاً در مسیر زیر قرار دارند:
Admin Login → Advanced → Voice → Regional
در بخش Time موارد زیر را بررسی کنید:
🔹 Time Zone
🔹 Time Offset
🔹 Ignore DHCP Time Offset
🔹 Daylight Saving Time Enable
🔹 Daylight Saving Time Rule
🔹 Time Format
🔹 Date Format
تنظیم ساعت Cisco برای ایران در سال ۲۰۲۶
این بخش مهم است چون بسیاری از آموزش‌های قدیمی هنوز DST ایران را فعال می‌کنند.
در سال ۲۰۲۶، ایران روی UTC+3:30 قرار دارد و تغییر ساعت تابستانی ندارد.
بنابراین برای یک Cisco MPP در ایران، تنظیم پایه معمولاً باید شبیه این باشد:
<Time_Zone ua="na">GMT+03:30</Time_Zone>
<Time_Offset__HH_mm_ ua="na">00/00</Time_Offset__HH_mm_>
<Ignore_DHCP_Time_Offset ua="na">Yes</Ignore_DHCP_Time_Offset>
<Daylight_Saving_Time_Enable ua="na">No</Daylight_Saving_Time_Enable>اگر شبکه شما عمداً Time Offset را از DHCP مدیریت می‌کند، معماری ممکن است متفاوت باشد.
چرا تلفن دقیقاً یک ساعت جلو یا عقب است؟
اگر تاریخ درست است و اختلاف دقیقاً یک ساعت است، احتمال خرابی NTP کم‌تر می‌شود.
اول DST را بررسی کنید.
ممکن است Firmware یا Provisioning Template هنوز یک DST Rule قدیمی داشته باشد.
برای ایران در سال ۲۰۲۶ باید DST غیرفعال باشد.
اگر Daylight Saving Time Enable روی Yes مانده باشد، تلفن ممکن است در بخشی از سال یک ساعت جابه‌جا نمایش داده شود.
DST Rule در Cisco چگونه کار می‌کند؟
Cisco MPP اجازه می‌دهد شروع، پایان و مقدار تغییر ساعت با Rule تعریف شود.
ساختار کلی:
start=<start-time>;end=<end-time>;save=<save-time>مثلاً در کشورهایی که DST دارند، Rule می‌تواند یک ساعت به زمان اضافه کند.
اما اگر کشور شما DST ندارد، فعال‌کردن Rule قدیمی فقط خطا ایجاد می‌کند.
Time Zone درست است ولی ساعت هنوز اشتباه است
این ترتیب را بررسی کنید:
۱. NTP پاسخ می‌دهد؟
۲. NTP Server خودش ساعت صحیح دارد؟
۳. Time Zone درست است؟
۴. Time Offset اضافه‌ای تعریف نشده؟
۵. DHCP Option 2 روی تلفن اثر نمی‌گذارد؟
۶. DST اشتباه فعال نشده؟
۷. Provisioning بعد از Reboot تنظیمات را بازنویسی نمی‌کند؟
چرا تنظیم دستی ساعت بعد از مدتی برمی‌گردد؟
این رفتار طبیعی است.
Cisco صریحاً اعلام می‌کند NTP نسبت به زمان دستی اولویت دارد.
یعنی اگر ساعت را دستی مثلاً روی ۱۴:۰۰ بگذارید اما NTP بعداً ۱۰:۳۰ UTC را بفرستد و Time Zone تلفن نیز روی GMT باشد، تلفن دوباره ساعت دیگری نمایش خواهد داد.
بنابراین تنظیم دستی را بیشتر برای تست موقت استفاده کنید، نه حل دائمی مشکل NTP.
اگر همه تلفن‌ها زمان اشتباه دارند
اگر ده‌ها تلفن هم‌زمان ساعت اشتباه نشان می‌دهند، احتمال خراب‌شدن تک‌تک تلفن‌ها بسیار کم است.
در این حالت ابتدا این موارد مرکزی را بررسی کنید:
🔹 DHCP Option 42
🔹 DHCP Option 2
🔹 Provisioning Template
🔹 Primary NTP Server
🔹 Time Zone داخل cfg.xml
🔹 DST Rule
اگر فقط یک تلفن ساعت اشتباه دارد
یک تلفن سالم و خراب را کنار هم مقایسه کنید.
این موارد باید مقایسه شوند:
🔹 Firmware
🔹 Primary/Secondary NTP
🔹 Operational VLAN
🔹 DHCP ACK
🔹 Time Zone
🔹 Ignore DHCP Time Offset
🔹 DST
🔹 Provisioning Profile
اگر هر دو تلفن روی یک VLAN هستند ولی فقط یکی مشکل دارد، Profile اختصاصی Endpoint یا تنظیم محلی مهم‌تر می‌شود.
لاگ‌های Cisco ممکن است ساعت متفاوتی نشان دهند
یک نکته مهم برای عیب‌یابی: Cisco در راهنمای MPP اعلام می‌کند Timestamp بعضی Log و Status Messageها بر اساس UTC است و Time Zone نمایش تلفن روی آن‌ها اعمال نمی‌شود.
بنابراین اگر روی صفحه تلفن ساعت ۱۴:۰۰ است ولی Log ساعت ۱۰:۳۰ نشان می‌دهد، فوراً نتیجه نگیرید NTP خراب است.
برای مقایسه PRT، Syslog، PBX Trace و Packet Capture همیشه مشخص کنید هر Source از UTC استفاده می‌کند یا Local Time.
ساعت اشتباه چه اثری روی Certificate دارد؟
گواهی‌های TLS یک بازه اعتبار دارند؛ یعنی Certificate از زمانی مشخص معتبر می‌شود و در تاریخی مشخص منقضی می‌شود.
اگر ساعت Endpoint به‌شدت عقب یا جلو باشد، ممکن است Certificate از دید تلفن هنوز معتبر نشده یا منقضی‌شده به نظر برسد.
Cisco این موضوع را به‌طور مشخص در EAP-TLS برای Cisco IP Phone مستند کرده و هشدار می‌دهد ساعت داخلی نادرست می‌تواند Certificate Validation را با شکست روبه‌رو کند.
این مشکل در VoIP کجا خودش را نشان می‌دهد؟
بسته به Firmware و معماری، ساعت اشتباه می‌تواند روی سرویس‌های امن مختلف اثر بگذارد؛ از جمله:
🔹 EAP-TLS برای احراز هویت شبکه
🔹 HTTPS Provisioning
🔹 SIP TLS
🔹 ارتباط‌های مدیریتی HTTPS
🔹 Certificate Renewal
رفتار دقیق Certificate Validation به Firmware و نوع سرویس بستگی دارد، اما اگر هم‌زمان با تاریخ اشتباه، خطای TLS یا Certificate دارید، Time Sync را قبل از تعویض Certificate بررسی کنید.
چرا این موضوع بعد از ریبوت بیشتر دیده می‌شود؟
در زمان Boot، تلفن هنوز ممکن است NTP Sync نشده باشد.
اگر Certificate یا HTTPS Provisioning خیلی زود قبل از همگام‌شدن زمان انجام شود، بعضی پیاده‌سازی‌ها می‌توانند با مشکل اعتبار زمانی Certificate مواجه شوند.
در چنین سناریویی این ترتیب را در Capture بررسی کنید:
DHCP → DNS → NTP → HTTPS/TLS → SIP Registration
اگر HTTPS یا TLS قبل از NTP Fail می‌شود و بعد از Sync سالم می‌شود، زمان Endpoint سرنخ مهمی است.
DHCP Option 42 وجود دارد ولی تلفن از NTP دیگری استفاده می‌کند
اگر Primary NTP Server به‌صورت دستی یا از Provisioning روی تلفن تعریف شده، ممکن است انتظار شما از DHCP با تنظیم واقعی Endpoint یکی نباشد.
در این حالت به‌جای نگاه‌کردن صرف به Scope DHCP، روی خود تلفن یا Profile مقدار NTP را بررسی کنید.
Packet Capture نیز مشخص می‌کند تلفن واقعاً به کدام IP درخواست UDP/123 می‌فرستد.
اگر NTP Server داخلی دارید
داشتن NTP Server داخل شبکه Voice معمولاً برای محیط‌های سازمانی مناسب است، چون Endpoint برای زمان به اینترنت وابسته نمی‌شود.
اما خود NTP Server نیز باید با یک Source معتبر همگام باشد.
در غیر این صورت ممکن است همه تلفن‌ها با هم ساعت اشتباه ولی یکسان داشته باشند.
تست از یک ویندوز در همان VLAN
اگر یک سیستم ویندوزی در مسیر مشابه تلفن دارید، می‌توانید تست اولیه انجام دهید:
w32tm /stripchart /computer:192.0.2.10 /dataonly /samples:5موفقیت این تست ثابت نمی‌کند خود تلفن همان Route و Firewall Policy را دارد، اما برای بررسی سلامت NTP Server مفید است.
تست NTP روی لینوکس
اگر یک سرور لینوکسی با Chrony دارید، Sourceهای زمان را بررسی کنید:
chronyc sources -vو وضعیت کلی:
chronyc trackingجدول تشخیص سریع مشکل ساعت Cisco
| نشانه | احتمال بیشتر | اولین بررسی |
|---|---|---|
| تاریخ و ساعت کاملاً اشتباه | NTP Sync نشده | Primary NTP و UDP/123 |
| ۳:۳۰ ساعت اختلاف در ایران | Time Zone روی GMT | GMT+03:30 |
| دقیقاً ۱ ساعت اختلاف | DST | Daylight Saving Time Enable |
| DHCP Offset درست است ولی اعمال نمی‌شود | Ignore DHCP Time Offset | Yes/No بودن گزینه |
| همه تلفن‌ها زمان غلط یکسان دارند | NTP/DHCP/Provisioning مرکزی | Server و Template |
| ساعت دستی بعداً تغییر می‌کند | NTP دوباره Sync کرده | منبع NTP |
| Certificate/TLS ناگهان Fail می‌شود | Date/Time یا Trust | Clock، NTP و اعتبار Certificate |
مسیر پیشنهادی عیب‌یابی مرحله‌به‌مرحله
مرحله ۱: تاریخ و ساعت فعلی تلفن را ثبت کنید.
مرحله ۲: مشخص کنید اختلاف چند دقیقه، یک ساعت یا چند ساعت است.
مرحله ۳: Primary و Secondary NTP Server را روی خود تلفن بررسی کنید.
مرحله ۴: اگر NTP با Hostname تعریف شده، DNS را بررسی کنید.
مرحله ۵: UDP/123 را با Packet Capture بررسی کنید.
مرحله ۶: DHCP ACK را برای Option 42 و Option 2 ببینید.
مرحله ۷: Time Zone، Time Offset و Ignore DHCP Time Offset را بررسی کنید.
مرحله ۸: DST را با قوانین فعلی کشور تطبیق دهید.
مرحله ۹: اگر TLS یا Certificate مشکل دارد، زمان Endpoint را با Not Before و Not After گواهی مقایسه کنید.
مرحله ۱۰: بعد از اصلاح، تلفن را Resync یا Reboot کنید و Capture جدید بگیرید.
پرسش‌های رایج
چرا ساعت Cisco IP Phone چند ساعت عقب است؟
اگر تاریخ درست است اما اختلاف چند ساعت ثابت دارید، Time Zone را بررسی کنید. در ایران باید در سال ۲۰۲۶ زمان روی UTC+3:30 تنظیم شود.
DHCP Option 42 چیست؟
Option 42 برای اعلام NTP Server به کلاینت DHCP استفاده می‌شود و Cisco MPP از آن پشتیبانی می‌کند.
DHCP Option 2 چه کاری انجام می‌دهد؟
Option 2 Time Offset را اعلام می‌کند. Cisco می‌تواند این Offset را استفاده کند یا با گزینه Ignore DHCP Time Offset آن را نادیده بگیرد.
چرا ساعت را دستی تنظیم می‌کنم ولی دوباره تغییر می‌کند؟
NTP روی Cisco نسبت به تنظیم دستی اولویت دارد. بعد از Sync بعدی، زمان دریافتی از NTP دوباره اعمال می‌شود.
برای ایران DST باید روشن باشد؟
خیر. در سال ۲۰۲۶ ایران DST ندارد و UTC+3:30 را در تمام سال استفاده می‌کند.
چرا Log تلفن با ساعت صفحه فرق دارد؟
بعضی Log و Status Messageهای Cisco با UTC ثبت می‌شوند و Time Zone صفحه تلفن روی Timestamp آن‌ها اعمال نمی‌شود.
آیا ساعت اشتباه می‌تواند باعث خطای Certificate شود؟
بله. Cisco به‌طور مشخص برای EAP-TLS اعلام می‌کند ساعت داخلی غلط می‌تواند Certificate Validation را خراب کند. در ارتباط‌های TLS دیگر نیز اعتبار زمانی گواهی باید هنگام عیب‌یابی بررسی شود.
Ping به NTP Server دارم؛ پس NTP سالم است؟
نه لزوماً. Ping از ICMP استفاده می‌کند ولی NTP معمولاً روی UDP/123 است. Packet Capture بهترین راه برای دیدن Request و Response واقعی NTP است.
جمع‌بندی
برای تنظیم ساعت Cisco IP Phone ابتدا مشخص کنید مشکل در «دریافت زمان» است یا «تبدیل زمان به ساعت محلی». NTP Server زمان مرجع را فراهم می‌کند، Time Zone و Offset آن را محلی می‌کنند و DST در صورت فعال‌بودن می‌تواند یک ساعت دیگر به آن اضافه کند.
در MPP، DHCP Option 42 می‌تواند NTP Server و Option 2 می‌تواند Time Offset را ارائه کند، اما Ignore DHCP Time Offset تعیین می‌کند Offset DHCP اصلاً استفاده شود یا نه.
برای تلفن‌های داخل ایران در سال ۲۰۲۶، تنظیم پایه معمولاً GMT+03:30 با DST غیرفعال است. اگر هم‌زمان TLS، HTTPS Provisioning یا Certificate Validation مشکل دارد، ساعت و تاریخ Endpoint را قبل از تعویض Certificate بررسی کنید.
چند تلفن Cisco هم‌زمان ساعت اشتباه دارند؟ مشکل احتمالاً از یک تنظیم مرکزی است
اگر چند Cisco IP Phone هم‌زمان Time Zone نادرست دارند، NTP را پیدا نمی‌کنند یا بعد از ریبوت دوباره ساعتشان تغییر می‌کند، تغییر دستی تک‌تک تلفن‌ها راه‌حل مناسبی نیست. DHCP، NTP Server، Voice VLAN و Provisioning Profile باید یکجا بررسی شوند.
ایرانیکاسرور می‌تواند تنظیم NTP، DHCP Optionهای VoIP، Firewall و Profile تلفن‌ها را بررسی کند تا ساعت، Registration و ارتباط‌های TLS بدون تغییر دستی مداوم پایدار بمانند.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)