عیب‌یابی حلقه شبکه (Network Loop) و خطاهای STP در زیرساخت‌های سازمانی

حلقه شبکه (Network Loop) زمانی رخ می‌دهد که بین دو نقطه از یک شبکه اترنت بیش از یک مسیر فعال لایه ۲ وجود داشته باشد و فریم‌های broadcast تا ابد در آن بچرخند. نتیجه، طوفان roadcast CPUB نزدیک ۱۰۰٪ در سوئیچ‌ها و قطع تقریباً کامل شبکه است. سریع‌ترین راه رفع آن: پیدا کردن پورتی که نرخ broadcast غیرعادی دارد، جدا کردن بخش مشکوک (معمولاً یک کابل یا سوئیچ کوچک در لبه شبکه)، و سپس اصلاح علت با STP، BPDU Guard و Storm Control.

چرا عیب‌یابی حلقه شبکه مهارت حیاتی است؟

حلقه شبکه از معدود مشکلاتی است که می‌تواند در چند ثانیه یک شبکه سازمانی را از کار بیندازد. سرورها در دسترس نیستند، تلفن‌های IP قطع می‌شوند و حتی ورود به سوئیچ از راه SSH ممکن نیست. شایع‌ترین علت آن هم یک اتفاق ساده است: کسی دو سر یک کابل را به دو پورت یک سوئیچ کوچک وصل کرده است.

این راهنما برای مدیران شبکه، کارشناسان پشتیبانی و فعالان IT نوشته شده تا بتوانند بدون وابستگی به شخص دیگری، حلقه را تشخیص دهند، مهار کنند، ریشه‌یابی کنند و از تکرار آن جلوگیری کنند. دستورات اصلی برای سوئیچ‌های سیسکو آمده و معادل آن‌ها برای میکروتیک، هوآوی، HP/Aruba و جونیپر نیز در بخش جداگانه ذکر شده است. این مقابه در راه‌اندازی شبکه به صورت مجدد به شما کمک می‌کند.

ترتیب کار در یک نگاه: تشخیص ← مهار فوری ← ردیابی منبع ← رفع ریشه‌ای ← پیشگیری. اگر شبکه همین الان از کار افتاده، مستقیم به بخش «مهار فوری» بروید.

حلقه لایه ۲ چگونه کار می‌کند؟ (طوفان Broadcast)

در لایه ۳ هر بسته IP فیلد TTL دارد و پس از چند عبور از مسیریاب حذف می‌شود. فریم اترنت چنین فیلدی ندارد. بنابراین اگر مسیر بسته‌ای وجود داشته باشد، یک فریم می‌تواند بی‌نهایت بچرخد.

سوئیچ ها سه نوع فریم را به همه پورت‌های VLAN (به‌جز پورت ورودی) ارسال می‌کند:

• Broadcast مانند ARP request و DHCP discover
• Multicast که بدون IGMP snooping مثل broadcast پخش می‌شود
• Unknown Unicast وقتی MAC مقصد در جدول MAC نیست

در حلقه، سوئیچ A فریم را از دو پورت به سوئیچ B می‌فرستد، B آن را از هر دو پورت به A برمی‌گرداند و این چرخه ادامه می‌یابد. نکته کلیدی این است که هر دور، تعداد کپی‌ها را چند برابر می‌کند. به همین دلیل رشد ترافیک نمایی است و ظرف چند ثانیه پهنای باند و CPU اشباع می‌شود. این پدیده «Broadcast Storm» نام دارد.

عوارض ثانویه حلقه:

1. MAC Flapping: هر فریم در حال گردش باعث می‌شود سوئیچ MAC مبدأ را از پورت‌های مختلف یاد بگیرد و جدول MAC دائماً تغییر کند.
2. پر شدن CPU: بخشی از فریم‌ها باید توسط CPU پردازش شوند (ARP، BPDU، مدیریت).
3. افت ترافیک واقعی: فریم‌های سالم در صف پشت طوفان گیر می‌کنند و دور ریخته می‌شوند.

نکته مهم: وجود چند مسیر فیزیکی بین سوئیچ‌ها به‌خودی‌خود حلقه نیست. در طراحی درست، مسیر اضافه برای افزونگی (redundancy) وجود دارد و STP/RSTP یکی از مسیرها را مسدود می‌کند یا لینک‌ها در قالب LACP یک لینک منطقی می‌شوند. حلقه یعنی مسیر اضافه بدون کنترل باشد.

 

 

علائم حلقه شبکه: چطور بفهمیم حلقه داریم؟

هیچ علامتی به‌تنهایی اثبات قطعی نیست، اما ترکیب چند علامت از موارد زیر تقریباً قطعی است:

کجا ببینیم	چه چیزی را نشان می‌دهد	علامت
شکایت کاربران، پینگ بالا	طوفان broadcast	قطع یا کندی ناگهانی شبکه در یک یا چند VLAN
show processes cpu sorted	پردازش فریم‌های در گردش	CPU سوئیچ نزدیک ۹۰ تا ۱۰۰٪
مشاهده فیزیکی	ترافیک شدید روی همه پورت‌ها	LEDهای تمام پورت‌ها همزمان و سریع چشمک می‌زنند
show logging	یک MAC از دو پورت یاد گرفته می‌شود	پیام MAC flapping در لاگ
show interfaces	مسیر چرخش حلقه	نرخ broadcast بسیار بالا روی چند پورت
show spanning-tree detail	ناپایداری مسیرها	تغییرات مکرر توپولوژی STP
مانیتورینگ	CPU یا صف مدیریت اشباع	قطع و وصل شدن SSH یا SNMP به سوئیچ
show logging	سیستم حفاظتی فعال شده	لاگ‌های storm-control یا err-disable

تفاوت حلقه با مشکلات مشابه

هر کندی شبکه حلقه نیست. پیش از هر اقدام، این جدول را مرور کنید:

مشکل	نشانه متمایز	تفاوت با حلقه
خرابی کابل یا SFP	خطای CRC و input error بالا، flap شدن لینک	ترافیک broadcast عادی است
Duplex mismatch	collision و late collision، کندی روی یک لینک	فقط همان لینک آسیب می‌بیند
تداخل IP	قطع و وصل شدن یک دستگاه، لاگ duplicate IP	CPU و کل VLAN درگیر نمی‌شود
ازدحام معمولی	تأخیر و packet loss، بدون MAC flapping	CPU سوئیچ معمولاً عادی است
طوفان broadcast بدون حلقه	یک دستگاه معیوب یا بدافزار broadcast می‌فرستد	با جدا کردن همان دستگاه رفع می‌شود و MAC flapping ندارد
حمله ARP spoofing	MAC گیت‌وی از چند پورت دیده می‌شود	معمولاً CPU و پهنای باند اشباع نیست

قاعده سرانگشتی: CRC بالا یعنی مشکل فیزیکی، نه حلقه. broadcast بالا همراه با MAC flapping و CPU بالا یعنی حلقه.

علل رایج ایجاد حلقه در شبکه (به ترتیب شیوع)

1. اتصال دو پورت یک سوئیچ به هم: شایع‌ترین علت در شبکه‌های اداری. معمولاً سوئیچ کوچک غیرمدیریتی (Unmanaged) زیر میز یا در اتاق جلسه که کاربر یا نصاب هر دو سر یک کابل را به آن زده است. چنین سوئیچ‌هایی STP ندارند و حلقه را نمی‌بینند.
2. اتصال سوئیچ غیرمجاز از دو مسیر: سوئیچ یا هاب خانگی که از دو پریز دیواری به شبکه وصل شده است.
3. غیرفعال بودن STP یا پیکربندی نادرست آن: مثلاً no spanning-tree vlan X یا اختلاط نسخه‌های متفاوت STP بدون طراحی.
4. پیکربندی ناقص LACP/EtherChannel: یک سر لینک Port-Channel است و سر دیگر چند لینک مستقل. سوئیچ ساده‌تر آن‌ها را مسیر جدا می‌بیند و حلقه می‌شود.
5. لینک یک‌طرفه (Unidirectional Link): در فیبر نوری، اگر یکی از رشته‌های TX یا RX قطع شود، BPDU دریافت نمی‌شود، STP پورت را اشتباهاً Forwarding می‌کند و حلقه شکل می‌گیرد. UDLD و Loop Guard برای همین طراحی شده‌اند.
6. از دست رفتن BPDU: فیلتر شدن BPDU، سوئیچ‌هایی که BPDU را عبور نمی‌دهند یا CPU بسیار شلوغ.
7. تغییر ناخواسته Root Bridge: اضافه شدن سوئیچ جدید با Priority پایین‌تر (مثلاً دستگاهی از انبار با تنظیمات پیش‌فرض) و جابه‌جایی کل توپولوژی.
8. دستگاه‌هایی که بین دو پورت پل می‌زنند: سرور با دو کارت شبکه و bridge در سیستم‌عامل، هایپروایزر (VMware/Hyper-V/Proxmox) با vSwitch نادرست، دسترسی‌پوینت یا تلفن IP با دو پورت که هر دو به شبکه وصل شده‌اند.
9. ناسازگاری VLAN روی Trunkها: در PVST/MSTP اگر VLANی روی یک سر trunk مجاز و روی سر دیگر مجاز نباشد، توپولوژی STP هر VLAN متفاوت می‌شود و حلقه‌ای در یک VLAN خاص ایجاد می‌شود.
10. خطای کابل‌کشی در پچ‌پنل: پچ کردن اشتباه دو پورت پچ‌پنل که هر دو به یک سوئیچ می‌روند.

مهار فوری حلقه: اول شبکه را پایدار کنید، بعد تحلیل کنید

در طوفان واقعی، CPU سوئیچ‌ها اشباع است و SSH کار نمی‌کند. تحلیل دقیق باید بعد از مهار انجام شود. این ترتیب را رعایت کنید:

1. زمان و تغییرات اخیر را بپرسید. آیا کسی سوئیچ، کابل یا تلفن جدید وصل کرده؟ اختلال بلافاصله بعد از یک تغییر شروع شده؟ در اغلب موارد همین تغییر منبع حلقه است.
2. به کنسول وصل شوید. وقتی SSH قطع است، کابل کنسول (Serial/USB) تنها راه مطمئن است. ترجیحاً به سوئیچ Core یا سوئیچ توزیعِ بخش آسیب‌دیده.
3. کاهش دامنه: اگر نقشه شبکه دارید، لینک‌های Uplink بخش‌های دسترسی (Access) را یکی‌یکی از سوئیچ توزیع جدا کنید (shutdown یا کشیدن کابل). بخشی که با جدا شدنش شبکه اصلی آرام شد، محل حلقه است.
4. پورت‌های لبه را قطع کنید: سوئیچ‌های دسترسی مشکوک و هر پورتی که به سوئیچ کوچک، AP یا تلفن وصل است.
5. سوئیچ‌ها را ریبوت نکنید. ریبوت حلقه را رفع نمی‌کند؛ پس از بالا آمدن، طوفان دوباره شروع می‌شود.
6. در صورت نیاز Storm Control موقت فعال کنید تا سوئیچ زنده بماند:

interface GigabitEthernet1/0/1
storm-control broadcast level 1.00
storm-control multicast level 1.00
storm-control action shutdown

پورتی که حلقه را می‌سازد با این تنظیم به‌صورت خودکار err-disable می‌شود و اغلب همان پورت مقصر است.

هشدار: قبل از قطع کردن Uplink یا Trunk مطمئن شوید که سرورها و سرویس‌های حیاتی از مسیر دیگری دسترسی دارند. قطع اشتباه یک لینک اصلی می‌تواند اختلال را بدتر کند.

راه سریع فیزیکی

اگر شبکه کوچک است و دسترسی نرم‌افزاری ندارید: تمام سوئیچ‌های لبه را از بالا جدا کنید و یکی‌یکی دوباره وصل کنید. هر سوئیچی که با وصل شدنش طوفان برگشت، منبع حلقه است. سپس کابل‌های آن را یکی‌یکی چک کنید.

عیب‌یابی مرحله‌به‌مرحله حلقه شبکه با دستورات سیسکو

پس از مهار اولیه یا زمانی که دسترسی به سوئیچ ممکن است، این مراحل را به ترتیب دنبال کنید. نام اینترفیس‌ها و VLANها را با مقادیر واقعی جایگزین کنید. برخی دستورات به مدل و نسخه IOS یا IOS XE بستگی دارند.

مرحله ۱: تأیید وجود حلقه با CPU و شمارنده‌ها

show processes cpu sorted | exclude 0.00
show processes cpu history
show interfaces | include line protocol|broadcasts
show interfaces counters

دنبال نرخ بالای broadcast و multicast روی چند پورت همزمان و CPU بالا در پردازش‌هایی مثل ARP Input، Spanning Tree یا Hulc LED باشید.

مثال: اگر شمارنده broadcast یک پورت در ۱۰ ثانیه از ۱۰۰ هزار به ۵۰۰ هزار برسد، نرخ برابر ۴۰ هزار فریم در ثانیه است. در شبکه سالم، broadcast معمولاً چند ده تا چند صد فریم در ثانیه است.

مرحله ۲: پیدا کردن پورت با بیشترین ترافیک

show interfaces GigabitEthernet1/0/24 | include rate|broadcasts|multicasts|errors
clear counters
! چند ثانیه صبر کنید، سپس دوباره:
show interfaces counters

پورتی که بالاترین Input broadcast را دارد معمولاً مسیر ورود طوفان است. اگر پورت به سوئیچ دیگری می‌رود، همین مسیر را در آن سوئیچ ادامه دهید.

مرحله ۳: دنبال کردن مسیر از Core تا لبه

show cdp neighbors detail
show lldp neighbors detail
show interfaces trunk

از سوئیچ Core شروع کنید، پورت پرترافیک را پیدا کنید، همسایه را با CDP/LLDP شناسایی کنید، به آن سوئیچ بروید و تکرار کنید تا به سوئیچ لبه برسید. اگر CDP/LLDP روی همسایه خاموش است، با MAC address یا شماره پچ‌پنل مسیر را پیدا کنید.

مرحله ۴: بررسی MAC Flapping

show logging | include MACFLAP|MAC_MOVE
show mac address-table address aaaa.bbbb.cccc
show mac address-table dynamic vlan 10
show mac address-table count

پیام نمونه:

%SW_MATM-4-MACFLAP_NOTIF: Host aaaa.bbbb.cccc in vlan 10 is flapping between port Gi1/0/10 and port Gi1/0/24

یعنی این MAC از دو پورت دیده می‌شود. دو پورت نام‌برده معمولاً دو سر حلقه‌اند. اگر هر دو پورت به یک سوئیچ کوچک یا یک دستگاه می‌روند، همان‌جا را فیزیکی بررسی کنید.

MAC flapping همیشه حلقه نیست. سرور با اتصال دوگانه بدون LACP، Active-Active بودن NIC Teaming یا vMotion هم می‌تواند علت باشد.

مرحله ۵: بررسی دقیق STP

show spanning-tree summary
show spanning-tree root
show spanning-tree vlan 10
show spanning-tree detail | include ieee|occurr|from|is exec
show spanning-tree inconsistentports

چه چیزی را بررسی کنیم:

• Root Bridge همان سوئیچی است که در طراحی مشخص کرده‌اید؟ اگر Root یک سوئیچ لبه یا دستگاه ناشناس است، یعنی سوئیچ جدیدی با Priority پایین وارد شده.
• Topology Changes: شمارنده‌ای که چند بار در دقیقه زیاد می‌شود و آخرین پورتی که TC از آن آمده (from) منبع ناپایداری را نشان می‌دهد.
• پورت‌های Blocking/Alternate در جایی که انتظار دارید وجود دارند؟ اگر هیچ پورت Blocking در توپولوژی دارای مسیر اضافه نیست، احتمال حلقه یا غیرفعال بودن STP هست.
• inconsistentports: پورت‌هایی که Root Guard، Loop Guard یا BPDU Guard آن‌ها را مسدود کرده است.

مرحله ۶: بررسی لینک‌های اضافه، LACP و لینک یک‌طرفه

show etherchannel summary
show lacp neighbor
show udld neighbors
show interfaces GigabitEthernet1/0/1 transceiver detail

• در show etherchannel summary وضعیت P (bundled) یعنی عضو سالم است؛ I (stand-alone) یعنی پورت به گروه نپیوسته و ممکن است مسیر مستقل شود.
• لینک فیبر یک‌طرفه را با UDLD و توان نوری Rx/Tx در دستور transceiver شناسایی کنید.

مرحله ۷: بررسی لاگ و پورت‌های err-disable

show logging | include SPANTREE|STORM|ERR|LOOP
show interfaces status err-disabled
show errdisable recent
show storm-control

اگر BPDU Guard یا Storm Control فعال بوده، پورت مقصر با پیام bpduguard یا storm-control err-disable شده و دقیقاً همان پورت منبع مشکل را نشان می‌دهد.

مرحله ۸: تحلیل ترافیک با SPAN و Wireshark (در صورت نیاز)

monitor session 1 source interface GigabitEthernet1/0/24 both
monitor session 1 destination interface GigabitEthernet1/0/48

در Wireshark این فیلترها کاربردی‌اند:

• stp برای مشاهده BPDUها
• dst == ff:ff:ff:ff:ff:ff برای فریم‌های broadcast
• arp برای بررسی طوفان ARP
• src == aa:bb:cc:dd:ee:ff برای دنبال کردن یک MAC خاص

اگر یک فریم با همان MAC مبدأ و همان محتوا بارها دیده شود، یعنی در حلقه می‌چرخد.

مرحله ۹: رفع و اعتبارسنجی

پس از پیدا کردن منبع:

1. کابل اضافه یا سوئیچ غیرمجاز را جدا کنید، یا پورت را shutdown کنید.
2. اگر پورت err-disable شده، پس از رفع علت: shutdown سپس no shutdown.
3. دوباره بررسی کنید: CPU، نرخ broadcast، MAC flapping، شمارنده Topology Change و ارتباط کاربران.
4. تا ۱۵ دقیقه شبکه را زیر نظر بگیرید و مطمئن شوید طوفان برنگشته است.
5. علت، زمان و اقدام را مستند کنید.

 

سناریوهای رایج حلقه و راه‌حل هر کدام

راه‌حل	نشانه تشخیص	سناریو
کابل را جدا کنید؛ BPDU Guard و Storm Control روی پورت‌های کاربر فعال کنید	شروع طوفان همزمان با اتصال کابل؛ پورت لبه با broadcast بالا؛ MAC flapping	سوئیچ کوچک با دو سر کابل به خودش
حذف دستگاه؛ Port Security یا محدودیت تعداد MAC؛ BPDU Guard	سوئیچ ناشناس در CDP/LLDP یا جدول MAC	سوئیچ غیرمجاز از دو مسیر
پیکربندی یکسان دو سر (mode، VLAN، سرعت)؛ مدتی لینک‌ها را shutdown کنید تا اصلاح شود	یک سر P و سر دیگر I یا بدون Port-Channel	EtherChannel ناقص
تعویض فیبر یا SFP؛ UDLD aggressive و Loop Guard فعال کنید	هشدار UDLD یا نبود BPDU روی پورت؛ توان نوری Rx صفر	لینک فیبر یک‌طرفه
حذف سوئیچ جدید یا تنظیم Priority؛ Root Guard روی پورت‌های رو به لبه	show spanning-tree root سوئیچ غیرمنتظره را نشان می‌دهد	تغییر Root Bridge
Teaming درست (LACP یا Active-Backup)؛ غیرفعال کردن bridge در سیستم‌عامل	MAC یک سرور از دو پورت دیده می‌شود	سرور با NIC Teaming یا bridge
بررسی اتصال دو uplink به یک VLAN بدون Teaming؛ جلوگیری از عبور BPDU از VM	حلقه با روشن شدن یک VM خاص	vSwitch در هایپروایزر
قطع پریز اضافه؛ BPDU Guard	حلقه با اتصال تلفن به دو پریز	پورت‌های دوگانه تلفن IP یا AP
یکسان کردن Allowed VLAN دو سر؛ استفاده از MSTP یکسان	حلقه فقط در یک VLAN؛ show interfaces trunk اختلاف را نشان می‌دهد	ناسازگاری VLAN در Trunk
بازبینی پچ‌پنل با نقشه؛ برچسب‌گذاری درست	شروع حلقه پس از جابه‌جایی کابل	پچ اشتباه در پچ‌پنل

عیب‌یابی حلقه در تجهیزات غیرسیسکو (میکروتیک، هوآوی، HP/Aruba، جونیپر)

منطق عیب‌یابی در همه برندها یکی است: شمارنده‌ها، MAC flapping، وضعیت STP، همسایه‌ها. فقط دستورات فرق می‌کنند. نام دستورات بسته به مدل و نسخه نرم‌افزار ممکن است کمی متفاوت باشد؛ در صورت خطا از راهنمای رسمی همان نسخه استفاده کنید.

میکروتیک (RouterOS)

/interface bridge print
/interface bridge port print
/interface bridge monitor bridge1
/interface monitor-traffic ether2
/tool torch interface=ether2 port=any protocol=any
/log print where topics~”bridge” or topics~”stp”

• torch ترافیک زنده را نشان می‌دهد؛ حجم بالای broadcast یا MAC مقصد FF:FF:FF:FF:FF:FF نشانه طوفان است.
• نسخه STP پل را روی RSTP بگذارید: /interface bridge set bridge1 protocol-mode=rstp.
• پورت‌های رو به کاربر را edge کنید و BPDU Guard فعال کنید (در نسخه‌های پشتیبانی‌کننده): /interface bridge port set [find interface=ether3] edge=yes bpdu-guard=yes.
• حفاظت حلقه: /interface ethernet set ether3 loop-protect=on. اگر RouterOS حلقه را ببیند پورت را موقتاً غیرفعال می‌کند.

هوآوی (VRP)

display cpu-usage
display interface brief
display stp brief
display stp
display mac-address
display logging
display mac-address flapping record

پیکربندی پیشگیری:

system-view
stp mode rstp
stp bpdu-protection
loopback-detection enable
interface GigabitEthernet0/0/1
stp edged-port enable
loopback-detection enable
broadcast-suppression 1

HP / Aruba (ArubaOS-Switch و ProVision)

show spanning-tree
show spanning-tree detail
show interfaces brief
show logging
show loop-protect

پیکربندی پیشگیری:

loop-protect 1-24
loop-protect disable-timer 300
spanning-tree 1-24 admin-edge-port
spanning-tree bpdu-protection 1-24

جونیپر (Junos)

show spanning-tree bridge
show spanning-tree interface
show ethernet-switching table
show interfaces ge-0/0/1 extensive
show log messages | match “l2ald|rstp|loop”

پیکربندی پیشگیری:

set protocols rstp interface ge-0/0/1 edge
set protocols rstp bpdu-block-on-edge

در سوئیچ‌های جونیپر ساختار Storm Control بسته به خانواده سخت‌افزار (ELS یا غیر ELS) فرق می‌کند؛ از مستندات همان مدل استفاده کنید.

سوئیچ‌های مدیریتی ارزان‌تر (TP-Link، D-Link و مشابه)

در بسیاری از آن‌ها قابلیت Loopback Detection یا Loop Prevention در منوی تنظیمات وجود دارد. آن را روی پورت‌های کاربر فعال کنید؛ سوئیچ فریم تست می‌فرستد و اگر برگردد، پورت را می‌بندد. اگر این قابلیت ندارید، حداقل STP/RSTP و Storm Control را روشن کنید.

پیشگیری از حلقه شبکه: ابزارها و پیکربندی استاندارد

پیشگیری باید چندلایه باشد: طراحی درست، پروتکل (STP)، حفاظت پورت و مانیتورینگ. هیچ‌کدام جایگزین دیگری نیست.

ابزارهای حفاظتی و کاربرد هرکدام

کجا فعال شود	کاربرد	ابزار
همه سوئیچ‌ها	جلوگیری از حلقه با بلاک کردن مسیر اضافه؛ همگرایی سریع‌تر از STP کلاسیک	RSTP / MSTP
پورت‌های Access کاربر	پورت کاربر اگر BPDU دریافت کند (یعنی سوئیچ وصل شده) err-disable می‌شود	PortFast + BPDU Guard
پورت‌های Core/توزیع رو به لبه	جلوگیری از تغییر ناخواسته Root Bridge	Root Guard
پورت‌های Uplink غیر Designated	جلوگیری از Forwarding شدن پورت وقتی BPDU قطع شده	Loop Guard
لینک‌های فیبر بین سوئیچ‌ها	تشخیص لینک یک‌طرفه فیبر	UDLD
پورت‌های Access و در صورت نیاز Uplink	محدود کردن broadcast/multicast/unknown unicast؛ بستن پورت متخلف	Storm Control
پورت‌های Access	ارسال فریم تست و بستن پورتی که آن را برمی‌گرداند (به‌ویژه برندهای غیرسیسکو)	Loopback Detection
سراسری	بازگردانی خودکار پورت پس از زمان مشخص	Errdisable Recovery
پورت‌های Access	محدود کردن تعداد MAC روی پورت؛ جلوگیری از سوئیچ غیرمجاز	Port Security

پیکربندی نمونه روی سوئیچ‌های سیسکو

سراسری:

spanning-tree mode rapid-pvst
spanning-tree extend system-id
spanning-tree loopguard default
udld enable

errdisable recovery cause bpduguard
errdisable recovery cause storm-control
errdisable recovery interval 300

Root Bridge اصلی و ثانویه (روی سوئیچ‌های Core):

! Core اصلی
spanning-tree vlan 1-4094 priority 4096
! Core ثانویه
spanning-tree vlan 1-4094 priority 8192

پورت‌های کاربر (Access):

interface range GigabitEthernet1/0/1-44
switchport mode access
spanning-tree portfast
spanning-tree bpduguard enable
storm-control broadcast level 1.00
storm-control multicast level 1.00
storm-control action shutdown

پورت‌های Core که به سوئیچ‌های لبه می‌روند:

interface TenGigabitEthernet1/1/1
spanning-tree guard root

نکات مهم پیکربندی:

• مقدار level 1.00 برای Storm Control یک نقطه شروع است. بر اساس نرخ واقعی broadcast شبکه خودتان تنظیم کنید، وگرنه ترافیک مشروع (مثلاً DHCP یا ARP زیاد در VLAN بزرگ) پورت را می‌بندد.
• BPDU Guard را روی لینک‌های بین سوئیچ‌ها فعال نکنید.
• زمان بازیابی خودکار err-disable را خیلی کوتاه نگذارید؛ در غیر این صورت پورت مشکل‌دار هر چند ثانیه حلقه را دوباره راه می‌اندازد.
• PortFast را فقط روی پورت دستگاه نهایی بزنید، نه
• Port Security (مثلاً حداکثر ۲ تا ۳ MAC) جلوی وصل شدن سوئیچ‌های کوچک را می‌گیرد؛ در محیط‌هایی با تلفن IP یا VM تعداد را متناسب انتخاب کنید.

بهترین روش‌های طراحی و نگهداری

1. RSTP یا MSTP را به STP کلاسیک ترجیح دهید.
2. Root Bridge را دستی تعیین کنید و یک Root ثانویه هم داشته باشید.
3. دامنه لایه ۲ را کوچک نگه دارید: هر چه VLAN و سوئیچ بیشتری در یک دامنه باشد، حلقه آسیب بیشتری می‌زند.
4. مسیریابی تا لبه (Routed Access) یا فناوری‌هایی مثل Stack، VSS، vPC، MLAG و EVPN-VXLAN وابستگی به STP را کم می‌کنند.
5. سوئیچ غیرمدیریتی در شبکه سازمانی ممنوع باشد یا فقط با BPDU Guard روی پورت متصل باشد.
6. پورت‌های بلااستفاده را shutdown کنید و در یک VLAN بلااستفاده بگذارید.
7. از VLAN 1 برای ترافیک کاربران استفاده نکنید و Allowed VLAN در Trunkها را صریح تعریف کنید.
8. مستندسازی: نقشه توپولوژی، برچسب پورت و پچ‌پنل، و ثبت هر تغییر کابل‌کشی.
9. مانیتورینگ و هشدار: با SNMP، Syslog و ابزارهایی مثل Zabbix، PRTG یا LibreNMS روی این موارد هشدار بگذارید: افزایش ناگهانی نرخ broadcast نسبت به خط پایه، CPU بالا، پیام MAC flapping، افزایش Topology Change و رخدادهای err-disable.
10. آموزش کاربران و نصابان که هیچ سوئیچ یا کابل اضافه‌ای بدون هماهنگی وصل نشود.

جدول خلاصه: علامت، علت احتمالی و اقدام

اقدام اول	علت محتمل	علامت مشاهده‌شده
جدا کردن آن کابل یا سوئیچ	حلقه در لبه	طوفان ناگهانی بعد از وصل کابل یا سوئیچ
بررسی دو پورت و دستگاه پشت آن‌ها	حلقه یا دو مسیر برای یک دستگاه	MAC flapping بین دو پورت
حذف سوئیچ، تنظیم Priority، Root Guard	سوئیچ جدید با Priority پایین	Root Bridge غیرمنتظره
بررسی Allowed VLAN دو سر	ناسازگاری VLAN در Trunk	حلقه فقط در یک VLAN
تعویض کابل یا SFP	مشکل فیزیکی	CRC و خطای زیاد بدون broadcast بالا
UDLD؛ تعویض فیبر یا ماژول	لینک یک‌طرفه	پورت‌های فیبر بدون BPDU
Teaming درست یا LACP	Teaming نادرست	یک MAC در دو پورت سرور
پیدا کردن و حذف مسیر اضافه	حلقه فیزیکی هنوز وجود دارد	تکرار حلقه پس از ریبوت

سوالات متداول درباره حلقه شبکه

حلقه شبکه (Network Loop) چیست؟

حلقه شبکه وضعیتی است که فریم‌های اترنت از طریق چند مسیر فعال لایه ۲ مدام می‌چرخند. چون فریم TTL ندارد، broadcast ها تا ابد می‌مانند و تکثیر می‌شوند و شبکه از کار می‌افتد.

مهم‌ترین نشانه حلقه شبکه چیست؟

قطع یا کندی ناگهانی شبکه، CPU بالای سوئیچ، نرخ broadcast بسیار زیاد و پیام‌های MAC flapping. وجود هم‌زمان این چند علامت تقریباً حلقه را تأیید می‌کند.

چطور بفهمم کدام پورت حلقه ایجاد کرده؟

پورت با بیشترین نرخ broadcast ورودی، پورتی که err-disable شده (BPDU Guard یا Storm Control) و دو پورتی که در پیام MAC flapping آمده‌اند را بررسی کنید. با CDP/LLDP مسیر را از Core تا سوئیچ لبه دنبال کنید.

آیا STP همیشه جلوی حلقه را می‌گیرد؟

نه. STP فقط اگر روی همه سوئیچ‌ها درست کار کند و BPDU عبور کند مؤثر است. سوئیچ غیرمدیریتی، لینک یک‌طرفه، از دست رفتن BPDU یا پیکربندی اشتباه STP را بی‌اثر می‌کند. به همین دلیل BPDU Guard، Loop Guard، UDLD و Storm Control لازم‌اند.

فرق BPDU Guard و Root Guard چیست؟

BPDU Guard روی پورت کاربر است و با دریافت هر BPDU پورت را می‌بندد. Root Guard روی پورت‌های رو به لبه است و اجازه نمی‌دهد سوئیچ پایین‌دست Root Bridge شود، اما پورت را کاملاً قطع نمی‌کند و فقط آن را در حالت ناسازگار نگه می‌دارد.

آیا حلقه شبکه با ریبوت سوئیچ برطرف می‌شود؟

نه. تا زمانی که مسیر فیزیکی اضافه وجود دارد، بعد از بالا آمدن سوئیچ، حلقه دوباره شروع می‌شود. باید منبع حلقه حذف شود.

آیا می‌توان بدون دسترسی به سوئیچ حلقه را پیدا کرد؟

بله، به‌صورت فیزیکی: سوئیچ‌های لبه را از Uplink جدا کنید و یکی‌یکی وصل کنید. سوئیچی که با وصل شدنش طوفان برگشت، محل حلقه است.

آیا Storm Control به‌تنهایی کافی است؟

نه. Storm Control اثر حلقه را محدود می‌کند اما علت را برطرف نمی‌کند و اگر مقدار آن بد تنظیم شود، ترافیک مشروع را هم قطع می‌کند. آن را کنار STP و BPDU Guard استفاده کنید.

تفاوت حلقه لایه ۲ و لایه ۳ چیست؟

در لایه ۳ بسته‌های IP فیلد TTL دارند و پس از چند عبور حذف می‌شوند، پس طوفان پایدار نمی‌شود. در لایه ۲ چنین مکانیزمی وجود ندارد و حلقه ادامه می‌یابد.

جمع‌بندی

عیب‌یابی حلقه شبکه سه اصل دارد: اول مهار، بعد ردیابی، سپس رفع و پیشگیری. برای تشخیص به نرخ broadcast، CPU، لاگ MAC flapping و وضعیت STP تکیه کنید. منبع حلقه را با دنبال کردن مسیر از Core تا لبه یا با پورت‌های err-disable‌شده پیدا کنید. در بیشتر شبکه‌ها ریشه مشکل یک کابل یا سوئیچ کوچک در لبه است.

برای جلوگیری از تکرار: RSTP و Root Bridge دستی، PortFast با BPDU Guard روی پورت‌های کاربر، Root Guard، Loop Guard، UDLD روی فیبر، Storm Control متناسب با شبکه، مانیتورینگ و مستندسازی دقیق. اگر پس از اجرای این مراحل مشکل ادامه داشت، نقشه توپولوژی، خروجی show spanning-tree detail و لاگ‌های MAC flapping را برای تحلیل دقیق‌تر در اختیار کارشناس پشتیبانی‌ شبکه یا پشتیبانی سازنده قرار دهید.