برای پاسخ عملی به سؤال SPAN چیست، باید آن را فراتر از یک قابلیت ساده Port Mirroring ببینیم. SPAN در سوئیچ سیسکو راهی برای ساخت نسخه‌ای از ترافیک یک یا چند Port یا VLAN و تحویل آن به ابزارهایی مانند Wireshark یا IDS است؛ بدون آنکه تحلیلگر مستقیماً در مسیر اصلی ارتباط قرار بگیرد. در این مقاله، مثال‌های اصلی Local SPAN ،RSPAN و ERSPAN بر مبنای Cisco Catalyst 9300 و Cisco IOS XE 17.17.x نوشته و با راهنمای رسمی همین نسخه تطبیق داده شده‌اند؛ با این حال، ظرفیت Sessionها، جزئیات ASIC و بعضی قابلیت‌ها بین مدل‌ها و نسخه‌های IOS XE یا NX-OS متفاوت است و باید پیش از استقرار عملی بررسی شود.
SPAN چیست و چگونه در سوئیچ‌های Cisco کار می‌کند؟
SPAN مخفف Switched Port Analyzer است؛ قابلیتی در سوئیچ‌های Cisco که نسخه‌ای از ترافیک ورودی، خروجی یا دوطرفه یک یا چند Port یا VLAN را به Destination Port می‌فرستد تا ابزارهایی مانند Wireshark یا IDS بتوانند بسته‌ها را برای مانیتورینگ، تحلیل و عیب‌یابی بررسی کنند.
در حالت معمول، بسته اصلی همچنان مسیر Switching یا Forwarding طبیعی خود را طی می‌کند و سوئیچ نسخه‌ای از ترافیک انتخاب‌شده را برای Session مانیتورینگ تولید می‌کند. Cisco صراحتاً بیان می‌کند که SPAN کپی ترافیک Source را به مقصد تحلیل می‌فرستد و این فرایند، Switching ترافیک اصلی روی Source Port یا Source VLAN را تغییر نمی‌دهد.
فناوری Port Mirroring چیست و چه ارتباطی با SPAN دارد؟
Port Mirroring چیست؟ Port Mirroring اصطلاح عمومی برای کپی‌کردن ترافیک از یک نقطه شبکه به نقطه‌ای است که ابزار تحلیل به آن متصل است. در محصولات Cisco ،SPAN نام رایج این سازوکار است. به همین دلیل عباراتی مانند تنظیم Port Mirroring سیسکو و Cisco SPAN Configuration معمولاً به یک نیاز عملی اشاره می‌کنند: رساندن نسخه‌ای از Packetها به یک Network Analyzer بدون قرار دادن Analyzer در مسیر Inline.
این ویژگی برای Network Traffic Analysis ،Packet Capture، تحلیل مشکلات TCP و DNS، مشاهده رفتار برنامه‌ها و تغذیه حسگرهای امنیتی Passive کاربرد دارد. Destination Port برای این هدف اختصاصی می‌شود و در Catalyst 9300 مرجع این مقاله، هنگام فعال بودن SPAN مانند یک پورت عادی کاربر عمل نمی‌کند.
مکانیزم کپی‌برداری از ترافیک شبکه در SPAN چگونه است؟
فرض کنید یک سرور به GigabitEthernet1/0/1 متصل است و لپ‌تاپ تحلیلگر روی GigabitEthernet1/0/24 قرار دارد:
- بسته‌ای از سرور وارد یا از آن خارج می‌شود.
- Gi1/0/1 به‌عنوان Source Port در SPAN Session تعریف شده است.
- سوئیچ، مطابق جهت انتخاب‌شده یعنی rx، tx یا both، نسخه‌ای از Packet را برای Session می‌سازد.
- ترافیک اصلی مسیر عادی خود را ادامه می‌دهد.
- نسخه Mirror شده از Destination Port خارج می‌شود و کارت شبکه لپ‌تاپ آن را برای Wireshark دریافت می‌کند.
این تفاوت مهم است: Wireshark در این سناریو دریافت‌کننده نسخه مشاهده‌ای ترافیک است، نه یک Hop الزامی در مسیر اصلی ارتباط.
تفاوت ترافیک اصلی با ترافیک Mirror شده
نباید فرض کرد که Stream خروجی SPAN در تمام شرایط، نسخه‌ای بدون افت و بیت‌به‌بیت کامل از ترافیک اصلی است. Cisco هشدار می‌دهد که اگر Destination Port از نظر ظرفیت Oversubscribed شود، بسته‌های Mirror شده ممکن است Drop شوند. همچنین محل نمونه‌برداری نسبت به پردازش‌هایی مانند ACL و QoS به جهت Rx/Tx و رفتار پلتفرم وابسته است.
برای مثال، اگر Source هم‌زمان 800 Mbps ترافیک ورودی و 700 Mbps ترافیک خروجی داشته باشد و both مانیتور شود، جریان بالقوه Mirror حدود 1.5 Gbps است. فرستادن این حجم به یک Destination یک‌گیگابیتی می‌تواند باعث از‌دست‌رفتن بخشی از Capture شود؛ حتی اگر ترافیک اصلی کاربران بدون مشکل Forward شود.
اجزای اصلی SPAN و نحوه انتخاب ترافیک برای مانیتورینگ
برای خواندن صحیح دستورات آموزش SPAN در سیسکو باید چهار مفهوم Source، Destination، Session و Direction را از یکدیگر جدا کنیم. Cisco در Catalyst 9300 اجازه می‌دهد Source یک یا چند Interface یا یک یا چند VLAN باشد، اما Source Port و Source VLAN را نمی‌توان در یک Session واحد با هم ترکیب کرد.
Source Port ترافیک پورت را برای پایش انتخاب می‌کند؛ Source VLAN ترافیک VLAN را پایش می‌کند. محدودیت‌های Routed Traffic به سوئیچ و نسخه نرم‌افزار وابسته‌اند. Destination Port نسخه‌های Mirror شده را به ابزارهایی مانند Wireshark یا Sensor امنیتی می‌فرستد. هنگام فعال بودن SPAN، این پورت برای Forwarding استفاده نمی‌شود و نمی‌تواند Source یا مقصد Session دیگری باشد. SPAN Session، Sourceها، جهت ترافیک و Destination را تعریف می‌کند. در Catalyst 9300 با IOS XE 17.17.x، ۶۶ Session و حداکثر هشت Source Session مستند است؛ این اعداد برای همه مدل‌های Cisco معتبر نیستند.
تفاوت جهت‌های ترافیک Rx، Tx و Both
Direction مشخص می‌کند چه بخشی از ترافیک Source کپی شود. Rx ترافیک دریافتی، Tx ترافیک ارسالی و Both هر دو جهت را شامل می‌شود. در Catalyst 9300، Both حالت پیش‌فرض است. Rx SPAN تا حد ممکن Packet را پیش از مراحل پردازش می‌بیند؛ Tx SPAN نسخه ترافیک را پس از پردازش خروجی ارائه می‌دهد. Rx برای بررسی درخواست‌های ورودی، Tx برای مشاهده پاسخ‌ها و Both برای تحلیل TCP دوطرفه کاربرد دارد. اثر ACL، QoS، Routing و Drop Point به جهت و سخت‌افزار وابسته است؛ بنابراین رفتار در پلتفرم‌های Cisco یکسان نیست.
انواع SPAN در تجهیزات Cisco؛ تفاوت Local SPAN، RSPAN و ERSPAN
در تجهیزات Cisco، سه روش اصلی برای انتقال ترافیک مانیتورینگ وجود دارد: Local SPAN ،RSPAN و ERSPAN. تفاوت آن‌ها به محل Source، محل Analyzer و مسیر انتقال ترافیک Mirror شده مربوط است.
Local SPAN چیست؟
Local SPAN ترافیک را در همان سوئیچ یا Stack سازگار از Source به Destination منتقل می‌کند. برای مثال، می‌توان ترافیک سرور متصل به Catalyst 9300 را به پورتی متصل به سیستم Wireshark فرستاد. این روش ساده است و به انتقال ترافیک Mirror از طریق شبکه نیاز ندارد؛ اما Analyzer باید در محدوده همان دستگاه یا Stack قرار داشته باشد.
RSPAN چیست؟
RSPAN امکان مانیتورینگ ترافیک بین چند سوئیچ در یک شبکه Layer 2 را فراهم می‌کند. در این روش، ترافیک Mirror شده از طریق RSPAN VLAN و Trunkها به سوئیچ مقصد منتقل می‌شود. این VLAN باید با تنظیم remote-span تعریف شود و در مسیرهای Trunk مجاز باشد. برخلاف Local SPAN، مقصد در این روش می‌تواند روی سوئیچ دیگری قرار بگیرد.
ERSPAN چیست؟
ERSPAN ترافیک Mirror شده را با استفاده از GRE روی شبکه IP قابل مسیریابی منتقل می‌کند؛ بنابراین برای اتصال شعب، Campusها و دیتاسنترهای جدا مناسب است. در این روش، نیازی به گسترش VLAN تا مقصد نیست.
بااین‌حال، GRE به‌تنهایی رمزنگاری یا احراز هویت فراهم نمی‌کند. همچنین باید سربار Encapsulation و محدودیت MTU مسیر را در طراحی در نظر گرفت.
آموزش تنظیم Local SPAN یا Port Mirroring در سوئیچ Cisco
در این سناریو، پیکربندی Local SPAN روی Cisco Catalyst 9300 با IOS XE 17.17.x انجام می‌شود. سرور به پورت GigabitEthernet1/0/1 و سیستم تحلیلگر مجهز به Wireshark به پورت GigabitEthernet1/0/24 متصل است. جهت مانیتورینگ نیز both انتخاب می‌شود تا ترافیک ورودی و خروجی کپی شود.
پیش‌نیازهای پیکربندی SPAN
پیش از شروع، مدل سوئیچ، نسخه نرم‌افزار، وضعیت Source Interface و آزادبودن Destination Port را بررسی کنید. همچنین سرعت پورت مقصد، ظرفیت کارت شبکه تحلیلگر و حجم ترافیک مورد انتظار اهمیت دارند. در بار بالا ممکن است حجم ترافیک Mirror شده از ظرفیت دریافت سیستم تحلیلگر بیشتر شود.
مراحل تنظیم SPAN با دستورات CLI
مرحله اول: انتخاب Source Interface
ابتدا وارد حالت پیکربندی شوید و پورت سرور را به‌عنوان Source تعیین کنید:
enable
configure terminal
monitor session 1 source interface GigabitEthernet1/0/1 bothدر این دستور، عدد 1 شناسه Session و گزینه both مشخص‌کننده مانیتورینگ هر دو جهت Rx و Tx است.
مرحله دوم: تعیین Destination Interface
پورت متصل به سیستم تحلیلگر را به‌عنوان مقصد تعریف کنید:
monitor session 1 destination interface GigabitEthernet1/0/24
endدر Local SPAN، Source و Destination باید از Session ID یکسان استفاده کنند. در پلتفرم مرجع، Destination باید یک پورت فیزیکی باشد و هنگام فعال‌بودن SPAN، برای انتقال عادی ترافیک کاربران استفاده نمی‌شود.
بررسی وضعیت SPAN Session
برای مشاهده تنظیمات Session، دستور زیر را اجرا کنید:
show monitor session 1در خروجی، نوع Session، پورت Source، جهت ترافیک و Destination را بررسی کنید. سپس دریافت واقعی Packetها را روی کارت شبکه تحلیلگر تأیید کنید.
محصول پیشنهادی جهت خرید سوئیچ سیسکو
مانیتورینگ VLAN و فیلترکردن ترافیک
با source vlan ترافیک VLAN مشخص مانیتور می‌شود؛ اما filter vlan برای محدودکردن VLANهای قابل مانیتور روی Source Trunk کاربرد دارد.
monitor session 5 source vlan 10
monitor session 5 destination interface GigabitEthernet1/0/24برای فیلترکردن VLANهای 10 و 20 روی Trunk:
monitor session 6 source interface GigabitEthernet1/0/48 both
monitor session 6 filter vlan 10 , 20
monitor session 6 destination interface GigabitEthernet1/0/24طبق مستندات Catalyst 9300، Source VLAN و Filter VLAN را نمی‌توان در یک Session ترکیب کرد. همچنین گزینه encapsulation replicate در Session سازگار، برای حفظ Encapsulation اصلی روی خروجی Mirror استفاده می‌شود.
حذف SPAN Session
پس از پایان مانیتورینگ، Session غیرضروری را حذف کنید:
configure terminal
no monitor session 1
endپیش از حذف، شناسه Session را بررسی کنید تا تنظیمات Session دیگری ناخواسته حذف نشود.
آموزش راه‌اندازی RSPAN در دو سوئیچ Cisco
سناریو:
Switch A سرور را روی Gi1/0/1 دارد.
Switch B لپ‌تاپ Wireshark را روی Gi1/0/24 دارد.
دو سوئیچ از طریق شبکه Trunk لایه ۲ به هم متصل‌اند و VLAN 901 برای RSPAN در نظر گرفته می‌شود.
پیش‌نیازهای پیکربندی RSPAN و ایجاد VLAN اختصاصی
RSPAN باید روی تجهیزات مشارکت‌کننده پشتیبانی شود و RSPAN VLAN در مسیر Layer 2 از Source تا Destination وجود داشته باشد. اگر Trunkها Allowed VLAN List دارند، VLAN 901 باید از مسیر لازم حذف نشده باشد. Cisco می‌گوید RSPAN Traffic روی Trunkها حمل می‌شود و ویژگی remote-span باید برای VLAN تعریف شود.
ساخت RSPAN VLAN با دستور remote-span
هدف: تبدیل VLAN 901 به VLAN اختصاصی RSPAN.
configure terminal
vlan 901
remote-span
exitاین تنظیم را روی Switchهای لازم در مسیر اعمال کنید. برای VLANهای Extended Range، Cisco صراحتاً نیاز به پیکربندی دستی روی Source، Destination و Intermediate Deviceها را ذکر می‌کند؛ VLAN 901 در Normal Range است، اما نحوه Propagation آن به وضعیت VTP شبکه وابسته است.
برای راستی‌آزمایی:
show vlan id 901
show interfaces trunkاولی وجود VLAN را بررسی می‌کند و دومی کمک می‌کند ببینید VLAN 901 روی Trunk موردنظر حمل می‌شود یا خیر. Cisco show vlan id را در Workflow رسمی ایجاد RSPAN VLAN برای Verification آورده است.
تنظیم RSPAN Source Session در سوئیچ مبدأ
هدف: کپی ترافیک دوطرفه سرور و قرار دادن آن در RSPAN VLAN 901.
configure terminal
monitor session 1 source interface GigabitEthernet1/0/1 both
monitor session 1 destination remote vlan 901
endدر اینجا Destination یک Physical Port نیست؛ خروجی Session به RSPAN VLAN فرستاده می‌شود. Syntax destination remote vlan برای Catalyst 9300 IOS XE 17.17.x در راهنمای رسمی مستند شده است.
راستی‌آزمایی:
show monitor session 1Source ،Direction و Remote VLAN باید با طراحی تطبیق داشته باشند.
تنظیم RSPAN Destination Session در سوئیچ مقصد
روی Switch B، VLAN 901 Source Remote است و Gi1/0/24 مقصد Analyzer:
configure terminal
monitor session 2 source remote vlan 901
monitor session 2 destination interface GigabitEthernet1/0/24
endCisco برای RSPAN Destination، source remote vlan و سپس Destination Physical Port را مستند می‌کند.
چرا Session مبدأ 1 و مقصد 2 هستند؟ Session IDها تنظیم محلی هر Device هستند؛ ارتباط بین Source Session و Destination Session در RSPAN با RSPAN VLAN برقرار می‌شود، نه با یک شماره Session مشترک سراسری. این نتیجه مستقیماً از معماری Cisco است که Source و Destination Session را روی Deviceهای جدا و با RSPAN VLAN به یکدیگر متصل می‌کند.
بررسی عملکرد RSPAN و رفع مشکلات ارتباطی
مسیر عیب‌یابی را از نزدیک‌ترین نقطه به Source آغاز کنید:
show monitor session 1
show vlan id 901
show interfaces trunkو روی Switch B:
show monitor session 2
show vlan id 901
show interfaces trunkاگر Sessionها درست باشند ولی Capture خالی بماند، بررسی کنید VLAN 901 واقعاً روی تمام Trunkهای موردنیاز حمل می‌شود، remote-span روی Deviceهای لازم تعریف شده و Native VLAN اشتباه انتخاب نشده باشد.
نکته مهم برای تحلیل 802.1Q: در Catalyst 9300 IOS XE 17.17.x، Cisco مستند می‌کند که در RSPAN، VLAN ID اصلی با RSPAN VLAN ID جایگزین می‌شود و بسته در Destination به‌صورت Untagged ارائه می‌شود. پس RSPAN این پلتفرم را راهی تضمین‌شده برای حفظ Original VLAN Tag ندانید.
آموزش پیکربندی ERSPAN در سوئیچ Cisco
سناریو این است که یک شعبه می‌خواهد Mirror Traffic سرور خود را از طریق Routed IP Network به مرکز مانیتورینگ بفرستد. اینجا Extend کردن VLAN بین سایت‌ها لازم نیست؛ ERSPAN از IP/GRE استفاده می‌کند.
پیش‌نیازهای ERSPAN و انتقال ترافیک از طریق شبکه IP
ابتدا باید مطمئن شوید مدل سخت‌افزار و IOS XE موردنظر ERSPAN Source و در صورت نیاز Destination را پشتیبانی می‌کنند. بین Origin و Destination باید Route معتبر وجود داشته باشد و تجهیزات امنیتی مسیر، GRE را مسدود نکنند. Cisco در Catalyst 9300 مرجع تصریح می‌کند غیرفعال‌کردن IP Routing باعث توقف ERSPAN IPv4 می‌شود.
MTU نیز باید در طراحی دیده شود؛ ERSPAN Header به Packet اصلی اضافه می‌شود. روی IOS XE 17.17.x، Cisco MTU قابل تنظیم برای ERSPAN و رفتار Truncation را مستند کرده است. علاوه بر آن، GRE به‌تنهایی محرمانگی ایجاد نمی‌کند، پس عبور Capture حساس از شبکه‌های کم‌اعتماد باید با کنترل‌های امنیتی متناسب طراحی شود.
نحوه ایجاد ERSPAN Source Session
نمونه زیر برای Catalyst 9300، IOS XE 17.17.x با Syntax رسمی تطبیق داده شده است. آدرس‌های 192.0.2.10 و 198.51.100.20 از TEST-NETهای رزروشده برای مستندسازی هستند و نباید به‌عنوان IP واقعی یک شبکه Production در نظر گرفته شوند. RFC 5737 محدوده‌های 192.0.2.0/24 و 198.51.100.0/24 را برای مثال‌های مستنداتی اختصاص داده است.
تعریف Source Interface و ERSPAN ID
monitor session 3 type erspan-source یک ERSPAN Source Session ایجاد می‌کند و Source Interface مشخص می‌کند چه ترافیکی Mirror شود. erspan-id 100 Flow را برای تطبیق با سمت Destination مشخص می‌کند؛ Cisco تأکید می‌کند همان ERSPAN ID باید در Destination Session نیز استفاده شود.
تعیین Destination IP و فعال‌سازی Session
configure terminal
monitor session 3 type erspan-source
source interface GigabitEthernet1/0/1 rx
destination
erspan-id 100
ip address 198.51.100.20
origin ip address 192.0.2.10
exit
no shutdown
end
show monitor session 3در این مثال:
- source interface … rx فقط ترافیک دریافت‌شده روی Gi1/0/1 را مانیتور می‌کند.
- ip address 198.51.100.20 مقصد Outer IP برای ERSPAN است.
- origin ip address 192.0.2.10 Source IP ترافیک ERSPAN را تعیین می‌کند.
- no shutdown ضروری است، زیرا ERSPAN Session جدید به‌صورت پیش‌فرض در حالت Shutdown ایجاد می‌شود.
در شبکه واقعی باید هر دو IP را با آدرس‌های واقعی و Routeable طراحی خود جایگزین کنید؛ TEST-NETها برای Production نیستند.
تنظیم ERSPAN Destination و دریافت ترافیک
ERSPAN Destination Session در سوئیچ گیرنده GRE/ERSPAN را Terminate می‌کند، Flow موردنظر را بر اساس پارامترهای Session می‌شناسد، Decapsulation را انجام می‌دهد و ترافیک مانیتورشده را به Destination Interface محلی تحویل می‌دهد. در Catalyst 9300 IOS XE 17.17.x، Cisco Destination Session IPv4 را رسماً پشتیبانی و Syntax آن را مستند کرده است.
برای سناریوی آموزشی، فرض می‌کنیم 198.51.100.20 آدرس یک Interface یا Loopback محلی روی Catalyst مقصد است و Analyzer به Gi1/0/24 متصل شده است:
configure terminal
monitor session 4 type erspan-destination
destination interface GigabitEthernet1/0/24
source
erspan-id 100
ip address 198.51.100.20
no shutdown
end
show monitor session 4Cisco تصریح می‌کند Destination IP در ERSPAN Destination Session باید آدرس Local Interface یا Loopback روی Switch مقصد باشد و با آدرسی که Source به‌عنوان مقصد ERSPAN استفاده می‌کند تطابق داشته باشد. ERSPAN ID نیز در Source و Destination باید هماهنگ باشد.
شماره Session محلی لزوماً با Source یکسان نیست؛ در این مثال Source Session شماره 3 و Destination Session شماره 4 است، اما erspan-id 100 و Destination IP ارتباط منطقی Flow را تعیین می‌کنند. در هر Device، ERSPAN Session ID باید در فضای Session محلی Unique باشد.
اگر مقصد یک سیستم تحلیلگر مستقل باشد، وجود Cisco ERSPAN Destination Session الزام معماری نیست؛ Host یا Appliance گیرنده باید بتواند Packetهای GRE/ERSPAN را دریافت و Decode/Decapsulate کند. Wireshark برای ERSPAN Dissector رسمی دارد و فیلدهای ERSPAN را قابل تحلیل می‌کند، اما رسیدن Packet به Capture Interface همچنان به OS، Routing و نحوه دریافت GRE روی Host وابسته است.
تفاوت پیاده‌سازی ERSPAN در Cisco Catalyst و Nexus
وجود واژه ERSPAN در هر دو خانواده به معنی یکسان‌بودن Syntax، Scale و Hardware Support نیست. مثال‌های این مقاله برای Catalyst 9300 و IOS XE 17.17.x هستند؛ در Nexus 9000، باید NX-OS System Management Guide مربوط به Release و ASIC دقیق دستگاه را مبنا قرار دهید.
این تفاوت عملی است: راهنمای NX-OS 10.6(x) برای بعضی Nexusهای مبتنی بر Silicon One محدودیت‌هایی مانند عدم پشتیبانی از ERSPAN Type III یا Destination/Termination را مستند کرده، در حالی که Catalyst 9300 IOS XE 17.17.x هم erspan-source و هم erspan-destination و انتخاب Header Type III را در CLI خود مستند می‌کند. بنابراین کپی‌کردن دستورهای IOS XE به NX-OS یا برعکس روش قابل اعتمادی نیست.
ERSPAN Type II و Type III چه تفاوتی دارند؟
در Catalyst 9300 مرجع، Type II حالت پیش‌فرض است و با header-type 3 می‌توان Type III را برای Session سازگار انتخاب کرد. Type III Header برای حمل Metadata توسعه‌یافته‌تر طراحی شده و در پیاده‌سازی‌های پشتیبان می‌تواند اطلاعات زمانی را نیز حمل کند.
در Nexus 9000، Cisco برای بعضی پلتفرم‌های پشتیبان Type III، Timestamp مبتنی بر PTP و Granularity مشخص را مستند کرده است؛ در عین حال همان راهنما نشان می‌دهد Support Matrix بین مدل‌ها متفاوت است. بنابراین «Type III همیشه Timestamp دقیق دارد» گزاره‌ای بیش از حد کلی است؛ باید مدل، ASIC و Release بررسی شود.
تفاوت SPAN ،RSPAN و ERSPAN چیست؟
Local SPAN ترافیک را به Destination Port روی همان Device یا Stack سازگار می‌رساند. RSPAN Mirror Traffic را با RSPAN VLAN در یک مسیر Layer 2 و روی Trunkها بین سوئیچ‌ها منتقل می‌کند. ERSPAN Mirror Traffic را داخل GRE روی شبکه IP قابل مسیریابی حمل می‌کند و برای مقصدهای دورتر مناسب است.
جدول مقایسه SPAN، RSPAN و ERSPAN
| ویژگی | SPAN | RSPAN | ERSPAN |
|---|---|---|---|
| محل مقصد مانیتورینگ | همان Device یا Stack سازگار | سوئیچ دیگری در دامنه Layer 2 | مقصد قابل دسترسی روی بستر IP |
| روش انتقال | Destination Port محلی | RSPAN VLAN | GRE/ERSPAN روی IP |
| نیاز به Trunk بین سوئیچ‌ها | خیر | معمولاً بله | خیر |
| امکان عبور از شبکه IP مسیریابی‌شده | به‌صورت Local SPAN خیر | خیر | بله |
| میزان پیچیدگی راه‌اندازی | کم | متوسط | بیشتر |
| کاربرد اصلی | عیب‌یابی محلی | مانیتورینگ چندسوئیچی L2 | شعب، سایت‌های دور و شبکه‌های Routed |
این مقایسه بر معماری مستند Cisco استوار است؛ محدودیت‌های Scale و Feature Support همچنان به Platform وابسته‌اند.
برای مانیتورینگ شبکه SPAN بهتر است یا RSPAN و ERSPAN؟
Local SPAN را زمانی انتخاب کنید که Source و Analyzer روی همان سوئیچ یا Stack قابل دسترسی‌اند. مثال: تیم NOC برای بررسی Packet Loss یک سرور VMware، لپ‌تاپ را موقتاً به همان Access Switch متصل می‌کند.
RSPAN زمانی منطقی است که Analyzer روی سوئیچ دیگری قرار دارد اما هر دو نقطه از طریق یک دامنه Layer 2 و Trunkهای کنترل‌شده به هم می‌رسند. مثال: Sensor امنیتی در اتاق NOC است و چند Access Switch همان Campus باید ترافیک انتخابی را به آن برسانند.
ERSPAN وقتی مناسب‌تر است که Source و Monitoring Center در Subnetها یا Siteهای مختلف هستند و IP Routing بین آن‌ها برقرار است. مثال: شعبه تهران Mirror Traffic یک لینک را به پلتفرم تحلیل مرکزی دیتاسنتر می‌فرستد، بدون آنکه VLAN مانیتورینگ تا مرکز Stretch شود.
انتخاب نهایی فقط بر اساس فاصله نیست؛ پهنای باند Mirror، MTU، Security، ظرفیت Destination و Feature Support سخت‌افزار نیز باید در تصمیم لحاظ شوند.
آموزش تحلیل ترافیک SPAN با نرم‌افزار Wireshark
پس از پیکربندی سوئیچ، مرحله بعد این است که مطمئن شوید Packetها واقعاً روی Analyzer قابل Capture و تحلیل هستند. Wireshark بین Capture Filter و Display Filter تفاوت روشنی قائل می‌شود و این تفاوت هنگام Troubleshooting مهم است.
اتصال سیستم مانیتورینگ به Destination Port
NIC سیستم تحلیلگر را مستقیماً به Destination Port وصل کنید و در Wireshark همان Interface فیزیکی را انتخاب کنید. برای Captureهای حجیم، سرعت NIC، Performance سیستم، سرعت Storage و Capture Buffer اهمیت دارند؛ Drop در Host می‌تواند با Drop روی SPAN Destination اشتباه گرفته شود.
همچنین مانیتورینگ شبکه باید با مجوز سازمانی انجام شود، زیرا Packet Capture ممکن است Metadata و Payload حساس را در خود داشته باشد. NIST تصریح می‌کند Duplicate و Centralize کردن Network Traffic می‌تواند اطلاعاتی فراتر از نیاز امنیتی درباره کاربران آشکار کند.
شروع Packet Capture در Wireshark
انتخاب Network Interface و شروع Capture
در صفحه Capture Interface، NIC متصل به Destination Port را انتخاب کنید. اگر Interface دیگری مانند Wi-Fi یا VPN را انتخاب کنید، حتی با SPAN صحیح Capture موردنظر را نخواهید دید. سپس Capture را آغاز و با یک جریان شناخته‌شده، مانند DNS Query یا اتصال TCP آزمایشی، صحت دریافت Packet را بررسی کنید.
فیلتر کردن بسته‌های DNS، TCP و HTTP
فیلترهای زیر Display Filter هستند:
dns
tcp
httpWireshark اجازه می‌دهد نام یک Protocol مستقیماً به‌عنوان Display Filter استفاده شود؛ مثلاً tcp تنها Packetهایی را در نمای فعلی نشان می‌دهد که TCP در آن‌ها Decode شده است. Display Filter بسته را از فایل Capture حذف نمی‌کند؛ فقط مشخص می‌کند چه Packetهایی نمایش داده شوند.
در مقابل، Capture Filter پیش از ذخیره‌سازی تعیین می‌کند چه Packetهایی Capture شوند و از Syntax مبتنی بر libpcap استفاده می‌کند؛ مثلاً:
tcp port 443بنابراین tcp در Display Filter و tcp port 443 در Capture Filter از دو زبان فیلتر متفاوت استفاده می‌کنند.
بررسی یک سناریوی واقعی اختلال ارتباطی
فرض کنید کاربران می‌گویند اتصال به یک Server «گاهی کند» است. SPAN را روی Port سرور فعال می‌کنیم و در Wireshark Session TCP را بررسی می‌کنیم. اگر چند Retransmission همراه با Gap زمانی، Duplicate ACK یا الگوی تکرارشونده مشاهده شود، این شواهد می‌تواند نشان دهد بخشی از Segmentها به‌موقع به گیرنده نرسیده‌اند.
اما وجود یک TCP Retransmission به‌تنهایی ثابت نمی‌کند مشکل از شبکه است. Packet ممکن است در مسیر از دست رفته باشد، Capture خودِ SPAN ممکن است Packet را Drop کرده باشد، Analyzer ممکن است Capture Drop داشته باشد یا رفتار Endpoint دخیل باشد. نتیجه معتبر باید با Sequence/ACK، زمان‌بندی، Counterهای Interface، Logهای Endpoint و Capture از نقاط دیگر همبسته شود.
در سناریوی DNS نیز صرف دیدن یک Query بدون Response برای محکوم‌کردن DNS Server کافی نیست؛ ابتدا باید مطمئن شوید SPAN هر دو جهت را Capture کرده، Capture Filter پاسخ را حذف نکرده و مسیر برگشت در نقطه مشاهده شما قابل رؤیت است.
محدودیت‌ها و نکات مهم امنیتی هنگام استفاده از SPAN
SPAN ابزار قدرتمندی است، اما «فعال است، پس همه Packetها را می‌بینم» فرض قابل اعتمادی نیست. خود Cisco درباره Oversubscription، رفتار Rx/Tx، VLAN Tagging و محدودیت Destination هشدارهای مشخصی دارد.
تأثیر SPAN بر عملکرد سوئیچ و احتمال Packet Loss
در Catalyst 9300، Cisco SPAN را به‌گونه‌ای توصیف می‌کند که Forwarding عادی Source را مختل نمی‌کند، اما Destination Oversubscribed می‌تواند Packet Mirror را Drop کند. همچنین مانیتورکردن تعداد زیادی Source، حجم زیادی از ترافیک کپی‌شده ایجاد می‌کند.
بنابراین Packet Loss در Capture الزاماً مساوی Packet Loss در Production Path نیست. هنگام Incident Analysis باید Counterهای Interface، ظرفیت Destination و Drop Statistics Analyzer را نیز بررسی کنید.
محدودیت سرعت و ظرفیت Destination Port
Oversubscription زمانی رخ می‌دهد که نرخ مجموع Mirror Traffic بیشتر از ظرفیت خروجی Destination باشد.
مثال ساده:
- Rx روی Source: 700 Mbps
- Tx روی Source: 600 Mbps
- Direction: both
- ترافیک Mirror بالقوه: 1.3 Gbps
- Destination: 1 Gbps
در این وضعیت، Destination نمی‌تواند در یک بازه پایدار تمام 1.3 Gbps را روی Link یک‌گیگابیتی ارسال کند. Cisco نیز Oversubscription Destination را به‌عنوان یکی از علت‌های Drop/Loss در SPAN مستند کرده است.
این موضوع نشان می‌دهد حتی یک Source یک‌گیگابیتی می‌تواند هنگام مانیتورکردن Both، از نظر مجموع Rx+Tx برای Destination یک‌گیگابیتی بیش از ظرفیت تولید کند.
مسائل امنیتی مربوط به کپی‌برداری از ترافیک
PCAP می‌تواند DNS Query، Metadata ارتباطات، Tokenها، Protocolهای Cleartext یا سایر داده‌های حساس را در خود داشته باشد. NIST هشدار می‌دهد Network Monitoring که داده را Duplicate و Centralize می‌کند ممکن است اطلاعات خصوصی کاربران را بیش از نیاز تحلیل در معرض ابزارها یا Administratorها قرار دهد.
در طراحی عملی، دسترسی به SPAN Configuration و PCAP را بر اساس Least Privilege محدود کنید، Retention مشخص داشته باشید، فایل‌های Capture حساس را در Storage محافظت‌شده نگه دارید و انتقال آن‌ها را امن کنید. برای ERSPAN نیز تصور نکنید GRE امنیت ایجاد می‌کند؛ Cisco تصریح می‌کند GRE به‌تنهایی Confidentiality و Authentication ندارد.
تفاوت SPAN با Network TAP چیست؟
SPAN نسخه Traffic را داخل Switch تولید می‌کند؛ Network TAP یک نقطه مشاهده فیزیکی/اپتیکی در مسیر Link فراهم می‌کند. Passive Fiber TAPهای تجاری می‌توانند بدون وابستگی به SPAN Port، یک Visibility Point دائمی ایجاد کنند؛ در مقابل نصب آن‌ها به طراحی فیزیکی، هزینه، Optical Budget یا نوع Media وابسته است.
| معیار | SPAN | Network TAP |
|---|---|---|
| روش اتصال | قابلیت داخلی Switch | سخت‌افزار روی مسیر/Link |
| هزینه و استقرار | معمولاً ساده‌تر؛ از پورت سوئیچ استفاده می‌کند | سخت‌افزار و نصب جداگانه می‌خواهد |
| احتمال از دست‌رفتن نسخه مشاهده‌ای | با Oversubscription مقصد ممکن است | به نوع TAP و معماری خروجی/aggregation وابسته است |
| انعطاف تغییر Source | بالا و مبتنی بر Configuration | وابسته به محل نصب فیزیکی |
| کاربرد مناسب | Troubleshooting و Monitoring انعطاف‌پذیر | Visibility دائمی یا سناریوهای نیازمند Capture Fidelity بالاتر |
Cisco احتمال Drop روی SPAN Destination Oversubscribed را مستند می‌کند؛ از سوی دیگر، سازندگان TAPهای Passive مانند Keysight معماری خود را برای Visibility مستقل از SPAN طراحی می‌کنند. این به معنی «برتری مطلق TAP» نیست؛ انتخاب به هدف، Budget، Media، Fail-Safety، Scale و معماری Capture وابسته است.
عیب‌یابی مشکلات رایج SPAN، RSPAN و ERSPAN در Cisco
در Troubleshooting، بهتر است از Configuration و Physical Layer شروع کنید و سپس به VLAN، Routing، GRE و Analyzer برسید. این ترتیب از جستجوی تصادفی مشکل جلوگیری می‌کند.
چرا هیچ ترافیکی در Destination Port مشاهده نمی‌شود؟
ابتدا بررسی کنید Source واقعاً Traffic دارد و Session صحیح است:
show monitor session 1Source Interface، Direction و Destination را با طراحی تطبیق دهید. سپس مطمئن شوید Wireshark روی NIC درست Capture می‌کند. SPAN Session نیز زمانی فعال می‌شود که Destination و حداقل یکی از Sourceهای لازم فعال باشند.
اگر rx انتخاب کرده‌اید اما به دنبال Packetهای خروجی هستید، یا برعکس، مشکل ممکن است فقط Direction باشد. both برای Troubleshooting دوطرفه معمولاً دید کامل‌تری می‌دهد، البته با مصرف ظرفیت بیشتر.
چرا بخشی از بسته‌ها در SPAN از دست می‌روند؟
سه نقطه را جداگانه بررسی کنید: Source/ASIC، Destination Link و Analyzer. اگر مجموع Traffic از ظرفیت Destination بیشتر باشد، Drop در Mirror قابل انتظار است. اگر Destination ظرفیت کافی دارد، ممکن است Capture Buffer، CPU، Storage یا NIC Analyzer عامل باشد. Cisco به‌طور مشخص Oversubscription Destination را یکی از علت‌های Lost/Dropped Mirror Packets می‌داند.
همچنین از روی یک Capture ناقص نتیجه نگیرید که Production Flow نیز همان Packetها را از دست داده است.
محصول پیشنهادی جهت خرید سوئیچ سیسکو
چرا RSPAN یا ERSPAN ترافیک را به مقصد نمی‌رساند؟
برای RSPAN بررسی کنید VLAN به‌عنوان remote-span تعریف شده، روی Trunkهای لازم حمل می‌شود و Source/Destination Session به همان RSPAN VLAN اشاره می‌کنند.
برای ERSPAN، Source Session باید no shutdown شده باشد، Destination IP Route داشته باشد، GRE در مسیر مجاز باشد، ERSPAN ID در صورت استفاده از Destination Session تطابق داشته باشد و Destination IP سمت گیرنده روی Interface یا Loopback مناسب تعریف شده باشد. MTU نیز باید با مسیر سازگار باشد.
| مشکل | علت احتمالی | اقدام پیشنهادی |
|---|---|---|
| نبود ترافیک در Capture | Session، Source/Destination، Direction یا NIC اشتباه | show monitor session و بررسی Interface انتخابی Wireshark |
| عبور نکردن RSPAN VLAN | VLAN 901 روی Trunk مجاز نیست یا remote-span ناقص است | show vlan id 901 و show interfaces trunk |
| اختلال در انتقال ERSPAN | Route، GRE، ERSPAN ID، Destination IP یا Session Shutdown | بررسی Routing/Firewall و show monitor session |
| Packet Loss | Destination Oversubscription یا Analyzer ضعیف | کاهش Sourceها/Direction یا افزایش ظرفیت Capture |
کاربردهای واقعی SPAN در مانیتورینگ و امنیت شبکه
ارزش SPAN زمانی مشخص می‌شود که Packet-level Evidence را در کنار Monitoring و Logها قرار دهید؛ نه زمانی که Capture را به‌تنهایی منبع قطعی حقیقت فرض کنید.
تحلیل ترافیک مشکوک و اتصال سیستم‌های IDS
SPAN می‌تواند نسخه Traffic را به یک Passive IDS بدهد تا Sensor الگوهای مخرب را تشخیص دهد، بدون آنکه خود Sensor الزاماً Inline باشد. NIST، IDS و IPS را در خانواده Intrusion Detection and Prevention Systems بررسی می‌کند؛ تفاوت معماری مهم این است که یک Passive Sensor عمدتاً مشاهده و Alert می‌کند، در حالی که IPS در مسیر Forwarding می‌تواند برای Prevention به‌صورت Inline طراحی شود.
برای IDS، کیفیت Mirror مهم است: Packet Loss روی SPAN ممکن است Visibility Sensor را کاهش دهد. در عین حال، قرار نداشتن Sensor Passive در مسیر اصلی می‌تواند ریسک تبدیل آن به Bottleneck مستقیم Forwarding را کاهش دهد.
عیب‌یابی ارتباطات سرور و کلاینت
فرض کنید Client گاهی برای اتصال TCP به Server Timeout می‌گیرد. با SPAN دوطرفه روی Server Port می‌توانید بررسی کنید SYN وارد شده، SYN/ACK خارج شده و ACK برگشته است یا نه. اگر تنها SYNهای متعدد دیده شوند، این یک سرنخ است؛ اما برای یافتن محل Drop باید Firewall Log، Interface Counter و در صورت نیاز Capture نقطه دوم را نیز بررسی کرد.
برای DNS نیز مقایسه Query، Response Code، Latency و تکرار Queryها می‌تواند نشان دهد اختلال بیشتر به DNS Resolution نزدیک است یا Transport؛ با این شرط که Capture Point واقعاً هر دو جهت ارتباط را ببیند.
مانیتورینگ ترافیک بین شعب سازمانی و دیتاسنتر
اگر Source و Sensor در چند Switch یک Campus لایه ۲ هستند، RSPAN می‌تواند Mirror را از طریق RSPAN VLAN منتقل کند. اگر شعب و دیتاسنتر با Routing به هم متصل‌اند و Stretch Layer 2 منطقی نیست، ERSPAN گزینه معماری مناسب‌تری است، مشروط به ظرفیت WAN، MTU، امنیت و Support تجهیزات.
در WANهای محدود، ارسال حجم بالای Raw Mirrored Traffic ممکن است بخش مهمی از پهنای باند را مصرف کند؛ در چنین شرایطی باید Source، Direction و Scope Capture را عمداً محدود کرد.
سوالات متداول درباره SPAN و Port Mirroring
آیا SPAN و Port Mirroring یک فناوری هستند؟
Port Mirroring نام عمومی آینه‌سازی ترافیک است و SPAN نام قابلیت Cisco برای این کاربرد است. در عمل، هر دو برای ارسال نسخه Traffic از Source به ابزار مانیتورینگ استفاده می‌شوند.
تفاوت اصلی SPAN و RSPAN چیست؟
Local SPAN Source و Destination را روی همان Device یا Stack نگه می‌دارد؛ RSPAN ترافیک Mirror را با یک RSPAN VLAN و Trunkهای Layer 2 به سوئیچ دیگری منتقل می‌کند.
آیا ERSPAN به شبکه لایه ۲ نیاز دارد؟
خیر. ERSPAN برای حمل Mirror Traffic از GRE روی IP قابل مسیریابی استفاده می‌کند؛ بنابراین برخلاف RSPAN، وجود یک دامنه Layer 2 مشترک از Source تا Destination الزامی نیست.
کلام آخر؛ انتخاب روش مناسب Port Mirroring در شبکه Cisco
برای جمع‌بندی پاسخ SPAN چیست، انتخاب روش را از محل Analyzer شروع کنید: Local SPAN برای مانیتورینگ محلی روی همان Device یا Stack، RSPAN برای جابه‌جایی Mirror Traffic در یک دامنه Layer 2 با RSPAN VLAN و ERSPAN برای انتقال آن از طریق Routed IP Network مناسب است. قبل از استقرار، Model و Software Release دقیق، ظرفیت Source و Destination، احتمال Oversubscription، نحوه حفظ VLAN Tag، MTU و Security داده‌های Capture را بررسی کنید؛ به‌ویژه در ERSPAN، GRE را Encryption تلقی نکنید و Syntax IOS XE را با NX-OS مخلوط نکنید.
انتخاب تجهیزات مناسب، تنها به خرید یک مدل خاص محدود نمی‌شود؛ بلکه به انتخاب کانفیگی متناسب با نیاز واقعی سازمان بستگی دارد. در ماهان شبکه ایرانیان، کارشناسان فنی با بررسی تعداد کاربران، نوع نرم‌افزارهای سازمانی، نیازهای پردازشی و بودجه شما، مناسب‌ترین مدل و کانفیگ را پیشنهاد می‌دهند. اگر برای خرید سرور اچ پی یا سایر تجهیزات شبکه جهت ارتقاء زیرساخت خود به راهنمایی نیاز دارید، پیش از تصمیم‌گیری با کارشناسان ما مشورت کنید تا با اطمینان، راهکاری متناسب با نیاز امروز و توسعه آینده کسب‌وکار خود انتخاب کنید.
