سالمبودن Ping و Traceroute همیشه به معنای سلامت کامل مسیر شبکه نیست. اگر Path MTU مسیر کاهش یافته باشد و پیام ICMP Fragmentation Needed نیز توسط ACL یا Firewall مسدود شود، بستههای کوچک عبور میکنند؛ اما بعضی ارتباطهای TCP هنگام Login، دانلود فایل یا انتقال دادههای حجیم با Timeout مواجه میشوند.
در این تجربه واقعی از پروژههای تتیسنت، نحوه شناسایی و رفع این مشکل پنهان MTU و PMTUD را بررسی میکنیم.
خلاصه تجربه واقعی عیبیابی مشکل MTU در شبکه
| مشخصه پروژه | توضیحات |
|---|---|
| نوع محتوا | تجربه واقعی عیبیابی شبکه |
| مشکل گزارششده | Timeout در Login، دانلود و انتقال داده |
| وضعیت تستهای اولیه | Ping و Traceroute سالم |
| علت اصلی | ناهماهنگی MTU و اختلال PMTUD |
| تجهیزات اصلی | Cisco Catalyst 9300 و Catalyst 9500 |
| راهکار نهایی | اصلاح ACL، هماهنگسازی MTU و تنظیم TCP MSS |
نشانههای اولیه مشکل MTU
ساعت حدود ۹:۳۰ صبح بود که اولین تماس از واحد مالی ثبت شد. سامانه ERP باز میشود، اما هنگام دریافت گزارش Excel خطا میدهد.
چند دقیقه بعد، واحد منابع انسانی نیز مشکل مشابهی را گزارش کرد. صفحه ورود سامانه باز میشود، اما بعد از وارد کردن نام کاربری، صفحه در حالت Loading باقی میماند.
در نگاه اول، مشکل به Application Server، پایگاه داده یا Firewall شباهت داشت. اما بررسی اولیه شرایط عجیبی را نشان میداد:
- سرور کاملاً در دسترس بود.
- Ping بدون Packet Loss پاسخ میداد.
- Traceroute مسیر طبیعی را نشان میداد.
- ارتباط TCP برقرار میشد.
- صفحه اصلی نرمافزار باز میشد.
- فقط بعضی عملیاتها مانند دانلود فایل، ورود به سامانه یا انتقال دادههای بزرگ با Timeout مواجه میشدند.
تیم Application اعلام کرد که Server سالم است. تیم Security نیز هیچ Drop مشخصی روی Firewall مشاهده نکرد. اما کاربران همچنان نمیتوانستند بهدرستی از سامانه استفاده کنند.
این دقیقاً همان نوع مشکلی است که میتواند ساعتها تیمهای مختلف را درگیر کند؛ زیرا ابزارهای متداول نشان میدهند شبکه سالم است اما شبکه تنها برای بستههای کوچک سالم است.
علت اصلی مشکل؛ ناهماهنگی MTU و اختلال در PMTUD
علت اصلی مشکل، ناهماهنگی MTU در مسیر و اختلال در عملکرد Path MTU Discovery بود.
توپولوژی شبکه در این پروژه
MTU در شبکه LAN برابر 1500 بایت بود، اما به دلیل اضافهشدن Headerهای Tunnel، حداکثر اندازه قابلانتقال در بخشی از مسیر کمتر از 1500 بایت شده بود.
در حالت طبیعی، PMTUD باید اندازه مناسب بسته را شناسایی کند؛ اما یک ACL روی مسیر، پیام ضروری ICMP مربوط به Fragmentation Needed را مسدود کرده بود.
بستههای بزرگ چگونه در مسیر متوقف میشدند؟
- مبدأ بسته بزرگ را با DF Bit ارسال میکرد.
- یکی از تجهیزات مسیر نمیتوانست بسته را بدون Fragmentation عبور دهد.
- به دلیل فعالبودن DF Bit، تجهیز اجازه Fragment کردن بسته را نداشت.
- تجهیز پیام ICMP Fragmentation Needed تولید میکرد.
- این پیام در مسیر برگشت Drop میشد.
- مبدأ متوجه نمیشد باید اندازه بسته را کاهش دهد.
- بستههای بزرگ Retransmit میشدند و ارتباط در نهایت Timeout میشد.
علت اصلی قطع ارتباط TCP با وجود Ping سالم چه بود؟
ping 10.20.30.40
Ping پیشفرض Payload کوچکی دارد و بهراحتی از مسیری با MTU کمتر از 1500 عبور میکند. بنابراین موفقبودن Ping فقط وجود مسیر و امکان رفتوبرگشت بسته کوچک را اثبات میکند؛ نه عبور Packet نزدیک به 1500 بایت با DF Bit.
تست MTU با DF Bit در تجهیزات Cisco
برای بررسی واقعی MTU باید اندازه بسته و DF Bit کنترل شود:
ping 10.20.30.40 size 1500 df-bit
تست Path MTU در Windows
در Windows نیز میتوان آزمون مشابهی انجام داد:
ping 10.20.30.40 -f -l 1472
عدد 1472 از رابطه زیر بهدست میآید:
1472 + 20-byte IPv4 Header + 8-byte ICMP Header = 1500 Bytes
اگر آزمون ناموفق بود، اندازه را مرحلهبهمرحله کاهش دهید:
ping 10.20.30.40 -f -l 1464
ping 10.20.30.40 -f -l 1450
ping 10.20.30.40 -f -l 1400
ping 10.20.30.40 -f -l 1360
نتیجه آزمایش MTU
نتیجه تست Path MTU در مسیر شبکه
| اندازه Payload | نتیجه |
|---|---|
| 1472 | Failed |
| 1464 | Failed |
| 1450 | Failed |
| 1400 | Failed |
| 1360 | Success |
بنابراین Path MTU واقعی تقریباً برابر بود با:
1360 + 28 = 1388 Bytes
این نتیجه نشان داد مسیر برای بستههای کوچک سالم است، اما بستههای بزرگتر از حدود 1388 بایت با DF Bit عبور نمیکنند.
تفاوت Interface MTU، IP MTU و Path MTU چیست؟
Interface MTU: حداکثر اندازه Frame یا Packet قابلپشتیبانی روی یک Interface است. فرمانهای متداول:
show interfaces
show interfaces GigabitEthernet1/0/48
show interfaces mtu
IP MTU: حداکثر اندازه Packet لایه سوم روی یک Interface Routed یا SVI است:
show running-config interface Vlan100
show interfaces Vlan100
Path MTU: کوچکترین MTU موجود در کل مسیر میان مبدا و مقصد است. حتی اگر تمام Interfaceهای Catalyst مقدار 1500 داشته باشند، Tunnel، MPLS، PPPoE، SD-WAN، Firewall یا Load Balancer میتواند Path MTU را کاهش دهد.
چرا فقط بعضی Applicationها مشکل داشتند؟
یک صفحه ساده با بستههای کوچک بارگذاری میشود، اما Login، TLS Exchange، پاسخ حجیم API یا دانلود فایل ممکن است Segmentهای بزرگتری تولید کند. بنابراین الگوی زیر بسیار معنادار است:
مقایسه عملکرد سرویسها زمان بروز مشکل MTU
| آزمون یا سرویس | نتیجه |
|---|---|
| Ping معمولی | موفق |
| Traceroute | موفق |
| TCP Three-Way Handshake | موفق |
| بازشدن صفحه اولیه | موفق |
| Login یا ارسال فرم | ناموفق |
| دانلود فایل بزرگ | ناموفق |
| انتقال Backup | بسیار کند یا قطع |
| SSH با فرمانهای ساده | موفق |
| نمایش خروجی حجیم در SSH | متوقف یا کند |
اثبات مشکل MTU با Packet Capture و SPAN
monitor session 1 source interface GigabitEthernet1/0/10 both
monitor session 1 destination interface GigabitEthernet1/0/24
نشانههای مشکل PMTUD در Wireshark
در Wireshark معمولاً علائم زیر دیده میشود:
- TCP Retransmission
- TCP Dup ACK
- Previous segment not captured
- TCP Spurious Retransmission
- Packet با Total Length نزدیک 1500 و DF Bit فعال
- نبود پیام ICMP Fragmentation Needed در مسیر برگشت
ICMP Black Hole چگونه ساخته میشود؟
PMTUD در IPv4 به پیام ICMP Destination Unreachable، Type 3 Code 4 وابسته است. اگر تمام ICMPها در ACL یا Firewall مسدود شوند، بسته بزرگ Drop میشود اما مبدأ دلیل آن را نمیفهمد و همان اندازه را دوباره ارسال میکند.
نمونه ACL ایجادکننده ICMP Black Hole
ip access-list extended WAN-IN
deny icmp any any
permit ip any any
پس از اعمال Policy امنیتی مناسب، باید پیامهای ضروری ICMP اجازه عبور داشته باشند. Syntax دقیق بسته به پلتفرم و IOS-XE متفاوت است.
بررسی ACL، Counter و مسیر Forwarding
show access-lists
show ip access-lists
show running-config | section access-list
show running-config interface Vlan100
show ip route 10.20.30.40
show ip cef 10.20.30.40 detail
show adjacency detail
روش صحیح بررسی Counter این است که مقدار اولیه ثبت شود، آزمون MTU چند بار اجرا شود و سپس افزایش Match Counter روی ACEهای مرتبط بررسی شود.
نقش TCP MSS در رفع مشکل MTU
در Ethernet با MTU برابر 1500، مقدار MSS معمولاً 1460 است:
1500 – 20-byte IPv4 Header – 20-byte TCP Header = 1460
در برخی طراحیها میتوان MSS را در نقطه مناسب Adjust کرد:
interface Vlan100
ip tcp adjust-mss 1348
اما مقدار صحیح باید براساس Encapsulation واقعی محاسبه شود. MSS Adjustment روی UDP اثری ندارد و جایگزین طراحی صحیح MTU و عبور ICMP ضروری نیست.
Root Cause نهایی پروژه و اقدامات اصلاحی
- کاهش MTU در Tunnel به دلیل Headerهای GRE و IPsec
- مسدودشدن پیام ICMP Fragmentation Needed توسط Rule امنیتی قدیمی
- اصلاح ACL و Firewall Policy برای عبور ICMP ضروری
- یکسانسازی MTU در طراحی Tunnel
- تنظیم حسابشده TCP MSS
- مستندسازی MTU در Overlay و Underlay
- افزودن تست MTU به Runbook عیبیابی
Runbook پیشنهادی برای عیبیابی MTU و PMTUD
- الگوی مشکل را مشخص کنید. آیا فقط فایلهای بزرگ، Login یا Site خاصی مشکل دارد؟
- MTU را با DF Bit و اندازههای مختلف آزمایش کنید.
- مسیر Forwarding را با show ip route و show ip cef پیدا کنید.
- MTU تمام Interfaceها و Tunnelهای مسیر را بررسی کنید.
- ACL و Firewall Counterها را قبل و بعد از تست مقایسه کنید.
- Packet Capture بگیرید و DF Bit، Retransmission، ICMP و TCP MSS را بررسی کنید.
- پس از اصلاح، عملیات واقعی مانند Login، Download و Upload را دوباره آزمایش کنید.
نتیجه پس از رفع مشکل MTU و PMTUD
پس از اصلاح Firewall Policy و فراهمکردن امکان عبور پیام ICMP Fragmentation Needed، مبدأ توانست Path MTU صحیح را شناسایی کند.
همچنین MTU مسیر Tunnel بازبینی و TCP MSS متناسب با Encapsulation واقعی تنظیم شد. در آزمایش نهایی، ورود به سامانه، دریافت گزارش Excel، دانلود فایل و انتقال دادههای حجیم بدون Timeout انجام شدند.
بیشتر بخوانید: EPLD در سوئیچ Nexus چیست؟ راهنمای آپدیت در NX-OS
عیبیابی تخصصی شبکه با تتیسنت
اختلالهایی مانند Timeoutهای پراکنده، بازشدن ناقص سامانهها، کندی انتقال فایل، Retransmissionهای مکرر و قطعی برخی ارتباطهای TCP معمولاً با تستهای سادهای مانند Ping و Traceroute قابلشناسایی نیستند.
تیم فنی تتیسنت با تجربه طراحی، پیادهسازی و عیبیابی زیرساختهای شبکه سازمانی، مسیر ارتباط را از لایه Access تا Core، Firewall، Tunnel، دیتاسنتر و سرور بررسی میکند تا علت اصلی اختلال، بهجای راهکارهای موقت، بهصورت دقیق شناسایی و برطرف شود.
برای دریافت مشاوره تخصصی، بررسی اختلالهای شبکه و انتخاب راهکار مناسب زیرساخت سازمان میتوانید با کارشناسان تتیسنت به شماره 02191009322 تماس بگیرید.
سوالات متداول MTU و PMTUD
1. آیا تنظیم TCP MSS مشکل MTU را بهطور کامل حل میکند؟
خیر. تنظیم TCP MSS میتواند از تولید Segmentهای بزرگ TCP جلوگیری کند، اما روی UDP تأثیری ندارد و جایگزین اصلاح MTU، طراحی Tunnel و عبور پیامهای ضروری ICMP نیست.
2. چرا TCP Handshake موفق است اما انتقال داده انجام نمیشود؟
بستههای SYN، SYN-ACK و ACK معمولاً کوچک هستند و میتوانند از مسیر عبور کنند. مشکل زمانی ظاهر میشود که پس از برقراری Session، بستهها یا Segmentهای بزرگتر ارسال شوند.
3. Path MTU Discovery چیست؟
Path MTU Discovery یا PMTUD مکانیزمی است که کوچکترین MTU موجود در مسیر میان مبدأ و مقصد را شناسایی میکند تا بستهها بدون نیاز به Fragmentation ارسال شوند.
