لب عملی: پیکربندی سیاست داده متمرکز SD-WAN برای مسیریابی آگاه-از-برنامه

این لب عملی یک کلاس SLA که آستانه‌های قابل‌قبول loss، latency، و jitter را مشخص می‌کند تعریف می‌کند، یک سیاست داده متمرکز که ترافیک صوتی را تطبیق می‌دهد و آن کلاس SLA را با یک رنگ انتقال ترجیحی اعمال می‌کند پیکربندی می‌کند، و تصمیمات مسیریابی آگاه-از-برنامه گرفته‌شده به‌طور متمرکز به‌جای از طریق route-map های به‌ازای-هر-دستگاه را نشان می‌دهد.

سیاست متمرکز در SD-WANمسیریابی آگاه-از-برنامهرنگ ترجیحی کلاس SLA

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

هدف لب

تعریف یک کلاس SLA که آستانه‌های حداکثر قابل‌قبول loss، latency، و jitter برای ترافیک با کیفیت-صوتی را مشخص می‌کند، پیکربندی یک سیاست داده متمرکز که ترافیک صوتی را تطبیق می‌دهد و آن کلاس SLA را با یک رنگ انتقال ترجیحی اعمال می‌کند، و تأیید اینکه ترافیک صوتی به‌سمت مسیر منطبق هدایت می‌شود در حالی که سایر ترافیک از مسیر پیش‌فرض استفاده می‌کند.

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

Policy-Based Routing، پیش‌تر در این مجموعه پوشش داده شد، نیازمند پیکربندی یک route-map روی هر روتر جداگانه برای هدایت ترافیک خاص بود. سیاست داده متمرکز SD-WAN یک نتیجه از نظر مفهومی مشابه به دست می‌آورد — هدایت ترافیک بر اساس معیار فراتر از مسیریابی ساده مبتنی‌بر-مقصد — اما یک‌بار روی کنترل‌کننده نوشته می‌شود و به‌طور خودکار به هر دستگاه لبه مرتبط پوش می‌شود.

توپولوژی لب

Edge1 (سایت 100) دو انتقال دارد:
  رنگ biz-internet (تأخیر بالاتر)
  رنگ mpls (تأخیر پایین‌تر، ترجیحی برای صدا)

Edge2 (سایت 200) از طریق هر دو رنگ دسترس‌پذیر

هدف: ترافیک صوتی (UDP 16384-32767) باید
انتقال mpls را وقتی SLA را برآورده می‌کند
ترجیح دهد

وظیفه ۱: تعریف یک کلاس SLA

یک کلاس SLA که حداکثر loss، latency، و jitter قابل‌قبول برای ترافیک با کیفیت-صوتی را مشخص می‌کند بساز.

وظیفه ۲: ساخت یک سیاست داده متمرکز که ترافیک صوتی را تطبیق می‌دهد

یک سیاست داده که بازه پورت UDP معمولاً استفاده‌شده برای ترافیک صوتی RTP را تطبیق می‌دهد تعریف کن.

وظیفه ۳: اعمال کلاس SLA با یک رنگ ترجیحی

عمل سیاست را طوری پیکربندی کن که کلاس SLA را اعمال کند، و رنگ mpls را وقتی SLA برآورده می‌شود ترجیح دهد.

وظیفه ۴: اعمال سیاست روی سایت مرتبط

سیاست متمرکز را روی دستگاه‌های لبه سایت 100 اعمال کن.

وظیفه ۵: تأیید دنبال‌کردن مسیر ترجیحی توسط ترافیک صوتی

ترافیک الگوی-صوتی تولید کن و تأیید کن از انتقال mpls استفاده می‌کند، در حالی که سایر ترافیک به استفاده از انتخاب مسیر پیش‌فرض ادامه می‌دهد.

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

-- پیکربندی سیاست متمرکز
-- (از نظر مفهومی روی کنترل‌کننده وارد‌شده،
--  اینجا در شکل CLI سیاست نشان‌داده‌شده):

policy
 sla-class VOICE-SLA
  loss 1
  latency 150
  jitter 30

 data-policy VOICE-STEERING
  vpn-list VPN-1
   sequence 10
    match
     source-data-prefix-list ANY
     dscp 46
    action accept
     set-service sla-class VOICE-SLA preferred-color mpls

policy
 apply-policy site-list SITE-100
  data-policy VOICE-STEERING from-service

Edge1# show sdwan policy from-vsmart

...
data-policy VOICE-STEERING
  vpn-list VPN-1
    sequence 10
      match: dscp 46
      action: accept, sla-class VOICE-SLA,
              preferred-color mpls
-- تأیید می‌کند سیاست نوشته‌شده-به‌طور-متمرکز
-- پوش داده شده و روی این لبه فعال است، بدون
-- هیچ پیکربندی سیاست محلی CLI‌ای که روی خود
-- Edge1 تایپ شده باشد

IPPhone1> [یک تماس برقرار می‌کند، و ترافیک
           RTP علامت‌گذاری‌شده DSCP EF/46
           تولید می‌کند]

Edge1# show sdwan app-route stats

TLOC-COLOR   LOSS   LATENCY   JITTER   SLA-CLASS
mpls          0       28ms      3ms    VOICE-SLA (met)
biz-internet  0       95ms     18ms    VOICE-SLA (met)
-- هر دو مسیر در حال حاضر SLA را برآورده
-- می‌کنند، اما mpls رنگ ترجیحی پیکربندی‌شده
-- است، پس ترافیک صوتی به‌طور خاص به‌سمت آن
-- هدایت می‌شود

Edge1# show sdwan policy app-route-stats | include mpls

...voice flow matched, using tloc mpls...
-- تأیید می‌کند ترافیک علامت‌گذاری‌شده-صوتی
-- مسیر mpls را همان‌طور که مورد نظر است دنبال
-- می‌کند

OtherApp-PC> [ترافیک غیر-صوتی تولید می‌کند]

Edge1# show ... (جریان غیر-صوتی)
...default path selection applied, not
subject to VOICE-STEERING policy...
-- ترافیک نامنطبق به استفاده از انتخاب مسیر
-- معمولی ادامه می‌دهد، تحت‌تأثیر سیاست خاص-صدا
-- نیست

نکته کلیدی

سیاست داده متمرکز SD-WAN یک‌بار نوشته می‌شود و به‌طور خودکار به هر لبه قابل‌اعمال توزیع می‌شود، در تضاد با لب PBR قبلی جایی که همان منطق route-map باید دستی روی هر روتری که نیاز به همان رفتار هدایت داشت تکرار می‌شد — این تمرکز دقیقاً چیزی است که مسیریابی آگاه-از-برنامه سازگار را در سراسر ده‌ها یا صدها سایت عملی می‌کند، چون یک تغییر سیاست واحد روی کنترل‌کننده به هرجا که اعمال می‌شود منتشر می‌شود بدون لمس پیکربندی‌های دستگاه منفرد.

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

مقالات مرتبط

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

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

ادامه

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

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

ادامه

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

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

ادامه

لب عملی: پیکربندی 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 پوشش‌داده‌شده در لب قبلی که اجازه می‌دهد سوئیچ‌ها بسیار دورتر از هم قرار بگیرند مقایسه می‌کند.

ادامه