لب عملی: پیکربندی SXP برای انتشار اطلاعات SGT

هدف لب

پیکربندی SXP بین یک سوئیچ با سخت‌افزار قادر-به-SGT و یک سوئیچ دوم فاقد آن قابلیت، تأیید اینکه binding های SGT-به-IP در سراسر جلسه SXP منتشر می‌شوند، و تأیید اینکه سوئیچ دریافت‌کننده همچنان می‌تواند سیاست SGACL را با وجود اینکه هرگز یک تگ SGT درون‌خطی روی سیم نمی‌بیند اعمال کند.

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

لب SGT پوشش‌داده‌شده پیش‌تر در این مجموعه به تگ‌گذاری درون‌خطی تکیه کرد، جایی که SGT مستقیماً درون هر فریم جاسازی‌شده سفر می‌کند — قابلیتی که پشتیبانی سخت‌افزاری خاصی نیاز دارد. SXP مسئله گسترش سیاست مبتنی‌بر-SGT به سوئیچ‌ها، روترها، یا فایروال‌هایی که این سخت‌افزار تگ‌گذاری درون‌خطی را ندارند حل می‌کند، با انتشار اطلاعات binding SGT-به-IP به‌جای آن به‌صورت خارج-باند.

توپولوژی لب

Switch1 (قادر-به-SGT، تگ‌گذاری درون‌خطی،
         پیکربندی‌شده با اختصاصات SGT از لب
         SGT قبلی)
  ---- جلسه SXP ---- Switch2 (سخت‌افزار
                        قدیمی، نمی‌تواند
                        تگ‌های SGT درون‌خطی را
                        روی آپ‌لینک‌هایش حمل کند)

Employee-PC (SGT 10) به Switch1 متصل می‌شود
نقطه اعمال روی Switch2 برای ترافیک مقصدش یک
سرور آنجا وجود دارد

وظیفه ۱: پیکربندی Switch1 به‌عنوان یک SXP Speaker

Switch1 را طوری پیکربندی کن که SXP صحبت کند، و binding های SGT-به-IP یادگرفته‌شده محلی‌اش را به Switch2 تبلیغ کند.

وظیفه ۲: پیکربندی Switch2 به‌عنوان یک SXP Listener

Switch2 را طوری پیکربندی کن که مراقب به‌روزرسانی‌های SXP از Switch1 باشد.

وظیفه ۳: تأیید برقراری جلسه SXP

تأیید کن اتصال SXP بین دو سوئیچ به یک حالت برقرارشده می‌رسد.

وظیفه ۴: تأیید انتشار Binding های SGT-به-IP

تأیید کن Switch2 binding SGT-به-IP Employee-PC را از طریق SXP یاد می‌گیرد، با وجود اینکه هرگز یک تگ SGT درون‌خطی نمی‌بیند.

وظیفه ۵: تأیید کارکرد اعمال SGACL روی Switch2

همان سیاست SGACL از لب قبلی را روی Switch2 اعمال کن و تأیید کن با استفاده از binding یادگرفته‌شده-با-SXP به‌درستی اعمال می‌شود.

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

Switch1(config)# cts sxp enable
Switch1(config)# cts sxp default password SxpKey2026
Switch1(config)# cts sxp connection peer [آدرس Switch2] password default mode local speaker

-- "speaker" یعنی Switch1 binding هایش را به
-- همتا تبلیغ می‌کند -- انتظار ندارد binding
-- ای را روی این جلسه بازپس دریافت کند

Switch2(config)# cts sxp enable
Switch2(config)# cts sxp default password SxpKey2026
Switch2(config)# cts sxp connection peer [آدرس Switch1] password default mode local listener

-- "listener" یعنی Switch2 فقط binding ها را
-- دریافت می‌کند، و با نقش speaker که Switch1
-- با آن پیکربندی شد تطبیق دارد

Switch1# show cts sxp connections

SXP Peer IP    Source IP      Conn Status
[آدرس Switch2] [آدرس Switch1]  On
-- اتصال برقرار شد، تأیید‌شده با وضعیت "On"

Switch2# show cts sxp sgt-map

SGT   IP Address
10    192.168.100.10
-- Switch2 SGT (10) Employee-PC نگاشت‌شده به
-- آدرس IP‌اش را صرفاً از طریق جلسه SXP یاد
-- گرفت -- هیچ سخت‌افزار تگ‌گذاری درون‌خطی‌ای
-- در هیچ‌جای این مسیر انتشار درگیر نبود

Switch2(config)# cts role-based sgt-map [آدرس SharedServer] sgt 30
Switch2(config)# ip access-list role-based DENY-GUESTS
Switch2(config-rb-acl)# deny ip
Switch2(config-rb-acl)# exit
Switch2(config)# cts role-based permissions from 20 to 30 DENY-GUESTS

-- ساختار سیاست یکسان با لب SGT قبلی، اعمال‌شده
-- روی یک سوئیچ که هرگز اصلاً یک تگ SGT
-- درون‌خطی برای این ترافیک مدیریت نمی‌کند

Guest-PC> ping SharedServer
-- (binding SGT 20 Guest-PC نیز از طریق SXP
--  از Switch1 منتشر شد)

Request timed out.
Success rate is 0 percent (0/5)
-- اعمال روی Switch2 به‌درستی کار می‌کند، با
-- استفاده فقط از اطلاعات binding یادگرفته‌شده-
-- با-SXP به‌جای هر تگ درون‌خطی حمل‌شده در خود بسته

نکته کلیدی

SXP انتشار اطلاعات binding SGT-به-IP را از خود مکانیزم تگ‌گذاری درون‌خطی جدا می‌کند — یک سوئیچ که SXP را به‌عنوان یک listener اجرا می‌کند می‌تواند سیاست SGACL را با استفاده از جستجوهای مبتنی‌بر-IP در برابر binding های یادگرفته‌شده اعمال کند، کاملاً مستقل از اینکه آیا قابلیت سخت‌افزاری برای خواندن یا نوشتن یک تگ SGT درون‌خطی دارد، که SXP را به مکانیزم استاندارد برای گسترش تفکیک مبتنی‌بر-SGT در سراسر یک محیط مخلوط از زیرساخت قادر-به-SGT و قدیمی تبدیل می‌کند.