لب عملی: پیکربندی ERSPAN در سراسر یک شبکه مسیریابی‌شده

این لب عملی Encapsulated RSPAN (ERSPAN) را برای آینه‌کردن ترافیک در سراسر یک شبکه مسیریابی‌شده-لایه-۳ به‌جای یک ترانک لایه ۲ واحد پیکربندی می‌کند، و مفهوم RSPAN از لب قبلی را فراتر از مرزهای یک VLAN یا دامنه سوئیچ‌شده واحد گسترش می‌دهد.

کپسوله‌سازی GRE در ERSPANآینه‌سازی ترافیک لایه ۳نظارت بین-دامنه-مسیریابی‌شده

~4 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

هدف لب

پیکربندی ERSPAN روی یک دستگاه منبع برای کپسوله‌کردن ترافیک آینه‌شده درون GRE و مسیریابی آن در سراسر یک شبکه لایه ۳ به یک دستگاه مقصد دوردست، و تأیید اینکه یک ابزار گرفتن متصل بسیار فراتر از دسترس هر ترانک واحدی همچنان ترافیک آینه‌شده را دریافت می‌کند.

هدف لب (چرا مهم است)

RSPAN، پوشش‌داده‌شده در لب قبلی، همچنان اساساً به یک دامنه لایه ۲ واحد محدود است — VLAN RSPAN باید گام-به-گام در سراسر هر سوئیچ میانی ترانک شود. ERSPAN این محدودیت را کاملاً با کپسوله‌کردن ترافیک آینه‌شده درون GRE، پیش‌تر در این مجموعه بحث شد، حذف می‌کند، و اجازه می‌دهد در سراسر هر توپولوژی لایه ۳ به یک مقصد هرجا از طریق IP دسترس‌پذیر مسیریابی شود.

توپولوژی لب

Switch1 (منبع ERSPAN)
  Gi1/0/1 ---- PC-A (ترافیک برای نظارت)
  Loopback0: 10.0.0.1/32 (IP منبع ERSPAN)

Switch2 (مقصد ERSPAN، چند گام مسیریابی‌شده
         دورتر از Switch1، بدون ترانک لایه ۲
         مستقیم بینشان)
  Loopback0: 10.0.0.2/32 (IP مقصد ERSPAN)
  Gi1/0/10 ---- Capture-Laptop

مسیریابی زیربنا از‌قبل دسترس‌پذیری بین دو
loopback را فراهم می‌کند

وظیفه ۱: تأیید دسترس‌پذیری زیربنا

تأیید کن دو آدرس loopback می‌توانند در سراسر شبکه مسیریابی‌شده به یکدیگر برسند.

وظیفه ۲: پیکربندی جلسه منبع ERSPAN روی Switch1

یک جلسه monitor با Gi1/0/1 به‌عنوان منبع، کپسوله‌شده به ERSPAN با یک flow ID یکتا و IP مقصد، پیکربندی کن.

وظیفه ۳: پیکربندی جلسه مقصد ERSPAN روی Switch2

یک جلسه monitor روی Switch2 که ترافیک ERSPAN را با flow ID منطبق دریافت می‌کند و به پورت گرفتن محلی فوروارد می‌کند پیکربندی کن.

وظیفه ۴: تأیید آینه‌شدن ترافیک در سراسر شبکه مسیریابی‌شده

ترافیک روی PC-A تولید کن و تأیید کن لپ‌تاپ گرفتن متصل به Switch2 آن را دریافت می‌کند، با وجود اینکه هیچ اتصال لایه ۲ مستقیمی بین دو سوئیچ نیست.

وظیفه ۵: بررسی کپسوله‌سازی روی سیم

تأیید کن ترافیک آینه‌شده واقعاً از شبکه به‌صورت بسته‌های IP کپسوله‌شده-با-GRE بین دو آدرس loopback عبور می‌کند.

راه‌حل و تأیید

Switch1# ping 10.0.0.2 source loopback0

!!!!!
Success rate is 100 percent (5/5)
-- دسترس‌پذیری زیربنا پیش از پیکربندی ERSPAN تأیید شد

Switch1(config)# monitor session 1 type erspan-source
Switch1(config-mon-erspan-src)# source interface gigabitethernet1/0/1
Switch1(config-mon-erspan-src)# destination
Switch1(config-mon-erspan-src-dst)# erspan-id 100
Switch1(config-mon-erspan-src-dst)# ip address 10.0.0.2
Switch1(config-mon-erspan-src-dst)# origin ip address 10.0.0.1

-- erspan-id به‌عنوان یک شناسه جلسه عمل
-- می‌کند که چند جلسه هم‌زمان ERSPAN سفرکننده
-- بین همان یا جفت‌های دستگاه متفاوت را متمایز
-- می‌کند -- هر دو انتها باید روی این مقدار توافق کنند

Switch2(config)# monitor session 1 type erspan-destination
Switch2(config-mon-erspan-dst)# destination interface gigabitethernet1/0/10
Switch2(config-mon-erspan-dst)# source
Switch2(config-mon-erspan-dst-src)# erspan-id 100
Switch2(config-mon-erspan-dst-src)# ip address 10.0.0.2

-- جلسه مقصد مراقب ترافیک ERSPAN آدرس‌شده به
-- loopback خودش (10.0.0.2) است، که با erspan-id
-- پیکربندی‌شده تطبیق دارد، سپس آن را
-- de-encapsulate می‌کند و فریم‌های اصلی را از
-- پورت گرفتن محلی فوروارد می‌کند

PC-A> ping 192.168.1.1

-- Capture-Laptop متصل به Switch2، در حال
-- اجرای Wireshark:

گرفتن Wireshark نشان می‌دهد:
  ICMP Echo Request از MAC/IP خود PC-A
  ICMP Echo Reply مقصدش MAC/IP خود PC-A
-- با وجود اینکه Switch2 چند گام مسیریابی‌شده
-- دورتر است بدون هیچ VLAN یا ترانک مشترکی که
-- آن را به Switch1 اصلاً متصل کند، لپ‌تاپ
-- گرفتن همچنان یک کپی کامل از ترافیک PC-A را
-- دریافت می‌کند

-- بررسی ترافیک خام روی یک روتر میانی در طول
-- مسیر (مفهومی):

IntermediateRouter# show ip traffic | include GRE
-- بسته‌های GRE مشاهده‌شده در حال جریان از
-- 10.0.0.1 به 10.0.0.2 -- که تأیید می‌کند
-- فریم‌های اترنت آینه‌شده درون بسته‌های IP
-- کپسوله‌شده-با-GRE سوار می‌شوند، دقیقاً
-- همان‌طور که تونل‌های GRE پیش‌تر در این
-- مجموعه انواع ترافیک دیگر را برای مسیریابی
-- در سراسر یک شبکه IP کپسوله می‌کنند

نکته کلیدی

استفاده ERSPAN از کپسوله‌سازی GRE، همان مکانیزم تونل‌زنی پیش‌تر در این مجموعه برای گسترش لایه ۲ یا ساخت overlay های نقطه-به-نقطه، چیزی است که آینه‌سازی ترافیک از راه دور را کاملاً از هر نیازمندی مجاورت لایه ۲‌ای آزاد می‌کند — RSPAN از لب قبلی همچنان به یک مسیر ترانک‌شده برای VLAN اختصاصی‌اش نیاز داشت، در حالی که ERSPAN فقط به دسترس‌پذیری IP معمولی بین منبع و مقصد نیاز دارد، که آن را به انتخاب درست هروقت ترافیک تحت‌نظارت و نقطه گرفتن با یک شبکه لایه ۳ چند-گام و مسیریابی‌شده جدا شده‌اند تبدیل می‌کند.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

لب عملی: پیکربندی مسیریابی Stub در EIGRP

این لب عملی یک روتر شعبه را به‌عنوان یک stub در EIGRP پیکربندی می‌کند، و تأیید می‌کند فقط مسیرهای متصل و خلاصه خودش را تبلیغ می‌کند در حالی که روتر hub به‌درستی از پرس‌وجوکردن stub در طول یک تغییر توپولوژی در جای دیگری از شبکه اجتناب می‌کند.

ادامه

لب عملی: پیکربندی حالت Named در EIGRP

این لب عملی یک پیکربندی EIGRP کلاسیک موجود را به حالت named EIGRP بازپیکربندی می‌کند، و عبارات network و پیکربندی خاص-اینترفیس را در یک سلسله‌مراتب address-family ساختاریافته‌تر سازمان‌دهی می‌کند، و تعادل عملکردی با سبک پیکربندی کلاسیک استفاده‌شده در سراسر لب‌های EIGRP قبلی این مجموعه را تأیید می‌کند.

ادامه

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

این لب عملی Remote SPAN (RSPAN) را با استفاده از یک VLAN RSPAN اختصاصی حمل‌شده در سراسر یک ترانک پیکربندی می‌کند، و اجازه می‌دهد ترافیک آینه‌شده روی یک سوئیچ توسط یک دستگاه گرفتن متصل به یک سوئیچ کاملاً متفاوت نظارت شود، و مفهوم SPAN محلی پوشش‌داده‌شده در یک لب قبلی را در سراسر شبکه گسترش می‌دهد.

ادامه

لب عملی: پیکربندی In-Service Software Upgrade (ISSU) روی یک Stack

این لب عملی یک In-Service Software Upgrade را در سراسر یک stack StackWise انجام می‌دهد، و ایمیج IOS هر عضو را یکی‌یکی ارتقا می‌دهد در حالی که stack در سراسر آن به فوروارد‌کردن ترافیک ادامه می‌دهد، و صفر خرابی را در مقایسه با رویکرد مخل reload استفاده‌شده در لب‌های ارتقای IOS قبلی تأیید می‌کند.

ادامه

لب عملی: پیکربندی Stacking سنتی StackWise در Catalyst

این لب عملی stacking سنتی Catalyst (StackWise) را در سراسر سه سوئیچ با استفاده از کابل‌های stack پیکربندی می‌کند، و نیازمندی تک-لایه و مجاورت فیزیکی‌اش را با جفت StackWise Virtual پوشش‌داده‌شده در لب قبلی که اجازه می‌دهد سوئیچ‌ها بسیار دورتر از هم قرار بگیرند مقایسه می‌کند.

ادامه

لب عملی: پیکربندی StackWise Virtual

این لب عملی دو سوئیچ فیزیکی را با استفاده از یک Stackwise Virtual Link اختصاصی به یک سوئیچ منطقی StackWise Virtual واحد پیکربندی می‌کند، و تأیید می‌کند هر دو عضو به‌عنوان یک صفحه کنترل واحد ارائه می‌شوند و شکست یک عضو رفتار failover قابل‌پیش‌بینی فعال می‌کند.

ادامه