Segment Routing چیست؟ چالشها و راهنمای پیادهسازی عملی SR-MPLS و SRv6
با رشد سرویسهای ابری، توسعه مراکز داده، افزایش تعداد شعب سازمانی و نیاز به تضمین سطح سرویس، شبکههای امروزی باید بتوانند ترافیک را با دقت بیشتری هدایت کنند. در چنین محیطی، استفاده صرف از کوتاهترین مسیر مبتنی بر پروتکلهای IGP همیشه پاسخگوی نیازهای مهندسی ترافیک نیست.
در معماریهای سنتی، معمولاً از پروتکلهایی مانند LDP برای توزیع Label و از RSVP-TE برای ایجاد مسیرهای مهندسیشده استفاده میشود. LDP برای ایجاد مسیرهای Label-Switched ساده مناسب است، اما کنترل محدودی روی انتخاب مسیر دارد. RSVP-TE نیز امکانات قدرتمندی برای Traffic Engineering فراهم میکند، ولی نگهداری Tunnelهای متعدد، تبادل پیامهای سیگنالینگ و مدیریت State در طول مسیر، در شبکههای بسیار بزرگ پیچیدگی زیادی ایجاد میکند.
Segment Routing یا SR با تغییر رویکرد، کنترل مسیر را به مبدأ نزدیک میکند. در این روش، مسیر مورد نظر با مجموعهای از Segmentها توصیف میشود و شبکه میانی عمدتاً بر اساس اطلاعات IGP و SIDها بسته را Forward میکند. این مدل باعث کاهش نیاز به سیگنالینگ مستمر، سادهتر شدن عملیات شبکه و فراهمشدن امکان پیادهسازی Traffic Engineering مقیاسپذیر میشود.
در این مقاله، مفاهیم اصلی SR-MPLS و SRv6، انواع Segmentها، تفاوت آنها با LDP و RSVP-TE، مزایا و چالشهای پیادهسازی و یک سناری سناریوی عملی Traffic Engineering بررسی میشود.
چرا شبکههای مدرن به روشهای جدید مسیریابی نیاز دارند؟
زیرساخت شبکه در سازمانهای بزرگ، اپراتورها و مراکز داده، دیگر مجموعهای از چند روتر و لینک ساده نیست. این شبکهها معمولاً شامل موارد زیر هستند:
- چندین لایه Core و Aggregation
- لینکهای موازی بین روترها
- چند مسیر بین مراکز داده
- ارتباط با چند اپراتور
- سرویسهای حساس به تأخیر
- سرویسهای Voice، Video و Cloud
- VPNهای متعدد
- نیاز به بازیابی سریع پس از خرابی
در چنین محیطی، انتخاب مسیر فقط بر اساس کوتاهترین مسیر IGP ممکن است باعث شود همه جریانهای ترافیکی از یک مسیر عبور کنند؛ درحالیکه مسیرهای دیگری ظرفیت آزاد دارند.
برای حل این مشکل، فناوریهای مختلفی طی سالها توسعه یافتهاند. MPLS-TE مبتنی بر RSVP یکی از راهکارهای شناختهشده بود. در این مدل، برای هر مسیر مهندسیشده، یک Tunnel ایجاد میشود و با استفاده از پیامهای Path و Resv، منابع مسیر رزرو و State مربوط به Tunnel در تجهیزات نگهداری میشود.
Segment Routing تلاش میکند همین قابلیتهای مهندسی ترافیک را با معماری سادهتر و وابستگی کمتر به سیگنالینگ پیادهسازی کند.
چرا روشهای سنتی مسیریابی IP دیگر پاسخگوی نیاز ما نیستند؟
در یک شبکه IP معمولی، روتر بر اساس جدول مسیریابی تصمیم میگیرد بسته را به کدام Next-Hop ارسال کند. اگر چند مسیر وجود داشته باشد، انتخاب مسیر معمولاً بر اساس Metric، Administrative Distance و سایر معیارهای پروتکل مسیریابی انجام میشود.
این مدل برای بسیاری از شبکهها مناسب است؛ اما در سناریوهای زیر محدودیت دارد:
- نیاز به عبور ترافیک از مسیر مشخص
- جلوگیری از عبور ترافیک حساس از لینک پرتنش
- انتخاب مسیر بر اساس تأخیر یا Packet Loss
- تقسیم ترافیک میان مسیرهای مختلف
- عبور از چند نقطه امنیتی یا سرویس زنجیرهای
- ایجاد مسیرهای متفاوت برای کلاسهای مختلف سرویس
در این شرایط، مدیر شبکه باید کنترل بیشتری از مسیر Forwarding داشته باشد.
بررسی پروتکل LDP؛ کاربردها و محدودیتهای آن در شبکههای بزرگ
LDP یا Label Distribution Protocol برای توزیع Labelهای MPLS میان روترها استفاده میشود. در یک شبکه MPLS، LDP معمولاً Label را بر اساس مسیرهای محاسبهشده توسط IGP توزیع میکند.
بهصورت ساده:
عدم امکان کنترل مستقیم روی مسیر ترافیک
LDP معمولاً مسیر IGP را دنبال میکند. اگر مدیر شبکه بخواهد ترافیک از یک مسیر غیرکوتاهترین عبور کند، LDP بهتنهایی ابزار مناسبی نیست.
چالش عدم هماهنگی (همگرایی) LDP و IGP
LDP و IGP باید با یکدیگر هماهنگ شوند. اگر IGP سریعتر از LDP همگرا شود، ممکن است در یک بازه کوتاه، ناسازگاری میان جدول IP و Label ایجاد شود.
پیچیدگیهای عیبیابی و مدیریت عملیاتی
در شبکههایی با چند پروتکل، VPN، مسیرهای متعدد و نیاز به Fast Convergence، عیبیابی تعامل میان IGP، LDP و MPLS دشوار میشود.
محدودیت در Traffic Engineering
LDP بیشتر برای ایجاد مسیرهای Label بر اساس Routing معمولی طراحی شده است و Traffic Engineering پیشرفته را بهصورت مستقیم فراهم نمیکند.
بررسی پروتکل RSVP-TE؛ مزایا و دردسرهای نگهداری State در روترها
RSVP-TE برای ایجاد مسیرهای مهندسیشده در MPLS استفاده میشود. در این مدل، مبدأ Tunnel مسیر مورد نظر را مشخص میکند و پیامهای سیگنالینگ در طول مسیر حرکت میکنند.
مراحل کلی عبارتاند از:
- ارسال پیام Path از مبدأ
- بررسی منابع در روترهای میانی
- ارسال پیام Resv از مقصد به سمت مبدأ
- ایجاد Label و رزرو منابع
- نگهداری State مربوط به Tunnel
RSVP-TE امکانات مهمی دارد، از جمله:
- Explicit Path
- Constraint-Based Routing
- Bandwidth Reservation
- Fast Reroute
- مسیرهای پشتیبان
اما در شبکههای بزرگ با مشکلاتی مواجه میشود.
چالش افزایش بیرویه تعداد Tunnelها
اگر برای هر مقصد، کلاس سرویس یا مسیر خاص یک Tunnel ایجاد شود، تعداد Tunnelها میتواند بهسرعت افزایش یابد.
فشار شدید بر حافظه و CPU روترهای Core
هر روتر در طول مسیر باید اطلاعات Tunnel را نگهداری کند. افزایش تعداد Tunnelها به مصرف حافظه، CPU و منابع کنترلی منجر میشود.
وابستگی زیاد به سیگنالینگ و پیامهای مداوم
تغییرات توپولوژی، قطع لینک و تغییر منابع میتواند باعث ارسال پیامهای جدید و بازسازی Tunnelها شود.
پیچیدگی بالا در عیبیابی و رفع مشکل
در RSVP-TE باید همزمان وضعیت IGP، RSVP، Tunnel، Label، منابع لینک و مسیرهای پشتیبان بررسی شود.
ایده انقلابی Segment Routing؛ مسیریابی هوشمند از مبدأ
Segment Routing یک مدل Source Routing است. در این مدل، مبدأ یا کنترلکننده، مسیر مورد نظر را بهصورت دنبالهای از Segmentها مشخص میکند.
برای مثال:
Segment List = [SID_A, SID_B, SID_C]
این فهرست میتواند به این معنا باشد:
- رسیدن به روتر A
- عبور از همسایگی یا لینک مشخص B
- پایان مسیر در روتر C
در SR، لازم نیست هر روتر میانی برای هر مسیر، یک Tunnel مستقل را با پیامهای سیگنالینگ ایجاد کند. مبدأ مسیر را تعیین میکند و روترهای میانی Segmentها را اجرا میکنند.
مفهوم SID به زبان ساده
SID یا Segment Identifier شناسهای است که یک رفتار مشخص را در شبکه نمایندگی میکند.
برخی رفتارهای ممکن عبارتاند از:
- رسیدن به یک Prefix
- عبور از یک لینک یا Adjacency
- اجرای یک رفتار سرویس
- عبور از یک Node مشخص
- پایاندادن به مسیر
- اعمال Function در SRv6
SIDها در SR-MPLS معمولاً بهصورت Label و در SRv6 بهصورت IPv6 Address نمایش داده میشوند.
معرفی انواع SID در تکنولوژی Segment Routing
Prefix-SID چیست و چه کاربردی دارد؟
Prefix-SID به یک Prefix در جدول IGP مرتبط است. وقتی بسته با Prefix-SID مشخص Forward میشود، شبکه تلاش میکند آن را به روتر یا Prefix مربوط برساند.
برای مثال:
Router R2 Loopback: 10.255.0.2/32
Prefix-SID: 16002
در این مثال، Label 16002 میتواند برای رسیدن به Loopback روتر R2 استفاده شود.
Prefix-SID معمولاً بهصورت Global Segment تعریف میشود و در سطح Domain قابل استفاده است.
Node-SID؛ شناسه اختصاصی روترها
Node-SID نوعی Prefix-SID است که یک روتر را نمایندگی میکند. وقتی ترافیک به سمت Node-SID هدایت میشود، بسته از کوتاهترین مسیر IGP به آن Node میرسد.
در عمل، Node-SID یکی از مهمترین انواع Segment برای ساخت مسیرهای SR است.
Adjacency-SID؛ کنترل دقیق مسیر بر اساس لینکها
Adj-SID یک ارتباط یا لینک مشخص میان دو همسایه را نمایندگی میکند.
فرض کنیم روتر R1 به دو مسیر برای رسیدن به R3 دسترسی دارد:
R1 ---- R2 ---- R3
\ /
----- R4 ----
اگر بخواهیم بسته حتماً از لینک R1 به R2 عبور کند، میتوانیم از Adjacency-SID آن لینک استفاده کنیم.
Adj-SID برای موارد زیر کاربرد دارد:
- عبور اجباری از یک لینک
- Traffic Engineering دقیق
- انتخاب مسیر غیرکوتاهترین
- ایجاد مسیرهای خاص در توپولوژی
Anycast-SID؛ ایجاد مسیرهای پشتیبان و توزیعشده
یک Anycast-SID میتواند به چند Node اختصاص پیدا کند. ترافیک به نزدیکترین عضو گروه هدایت میشود.
این مدل برای پیادهسازیهایی مانند موارد زیر مفید است:
- Anycast Gateway
- سرویسهای توزیعشده
- مسیرهای پشتیبان
- افزایش انعطافپذیری سرویس
Binding-SID؛ سادهسازی سیاستهای پیچیده شبکه
Binding-SID نماینده یک Policy یا مسیر از پیش تعریفشده است. بهجای آنکه کل Segment List در هر نقطه وارد شود، میتوان یک SID را به یک Policy اختصاص داد.
این روش به کاهش طول Segment List و سادهسازی مدیریت Policyها کمک میکند.
Service-SID در SRv6؛ ترکیب مسیریابی با ارائه سرویس
در SRv6، یک SID میتواند یک Function خاص را اجرا کند. برای مثال:
- عبور از Firewall
- اعمال Service Chaining
- رسیدن به یک سرویس خاص
- انجام عملیات End, End.X یا End.DX6
SR-MPLS چگونه کار میکند؟
در SR-MPLS، Segmentها با Labelهای MPLS نمایش داده میشوند. مبدأ یک Stack از Labelها را به بسته اضافه میکند.
نمونه مفهومی:
[SID-Adjacency-R1-R2]
[SID-Node-R4]
[SID-Node-Destination]
روترها Label بالای Stack را بررسی میکنند:
- اگر Label مربوط به خودشان باشد، آن را Pop میکنند.
- اگر Label مربوط به یک Adjacency باشد، بسته را از لینک مشخص عبور میدهند.
- سپس Segment بعدی اجرا میشود.
مزایای SR-MPLS
- استفاده از زیرساخت MPLS موجود
- سازگاری مناسب با سرویسهای MPLS VPN
- کاهش وابستگی به LDP
- عدم نیاز به RSVP-TE در بسیاری از سناریوها
- پیادهسازی سادهتر نسبت به ایجاد Tunnelهای متعدد
- قابلیت استفاده در شبکههای IPv4 و IPv6
نحوه کارکرد SRv6؛ مزایا، معایب و چالشهای فنی
در SRv6، Segmentها در قالب IPv6 Segment Identifier یا SID قرار میگیرند. این SIDها معمولاً IPv6 Addressهایی هستند که علاوه بر شناسایی مقصد، رفتار خاصی را نیز مشخص میکنند.
فهرست Segmentها در SRH یا Segment Routing Header قرار میگیرد.
ساختار مفهومی:
IPv6 Header
+
Segment Routing Header
+
Original Payload
هر Node بر اساس SID فعال، رفتار مشخصی انجام میدهد.
برای نمونه:
2001:db8:100::1
2001:db8:200::5
2001:db8:300::9
ممکن است Segmentهای فوق به ترتیب نماینده:
- رسیدن به یک روتر
- عبور از یک لینک مشخص
- اجرای یک Function سرویس
باشند.
مزایای SRv6
- فضای آدرسدهی بسیار بزرگ
- امکان تعریف Network Function
- قابلیت Service Chaining
- مناسب برای شبکههای IP و Cloud Native
- امکان پیادهسازی رفتارهای قابل برنامهریزیتر
- حذف نیاز به Label Space سنتی MPLS
چالشهای SRv6
- افزایش اندازه Header
- نیاز به پشتیبانی سختافزاری و نرمافزاری
- مصرف بیشتر منابع در برخی تجهیزات
- پیچیدگی امنیتی مرتبط با Segment List
- نیاز به برنامهریزی دقیق IPv6 Addressing
مقایسه کامل LDP ،RSVP-TE و Segment Routing در یک نگاه (جدول مقایسهای)
| ویژگی | LDP | RSVP-TE | Segment Routing |
| هدف اصلی | توزیع Label بر اساس IGP | ایجاد مسیر TE | مسیریابی مبتنی بر Segment |
| نیاز به سیگنالینگ | دارد | زیاد | بسیار کمتر |
| کنترل مسیر | محدود | بالا | بالا |
| State در Core | متوسط | زیاد | کمتر |
| مقیاسپذیری | مناسب تا متوسط | پیچیده در مقیاس بزرگ | مناسبتر |
| Fast Reroute | وابسته به طراحی | قوی | با TI-LFA |
| وابستگی به Tunnel | غیرمستقیم | زیاد | |
| وابستگی به Tunnel | غیرمستقیم | زیاد | مبت |
| مناسب برای Network Programming | محدود | محدود | بسیار مناسب، بهخصوص SRv6 |
Traffic Engineering بدون سیگنالینگ پیچیده
در SR، یک مسیر مهندسیشده میتواند بهصورت Segment List تعریف شود.
فرض کنیم توپولوژی شبکه به شکل زیر باشد:
مسیر IGP معمولی از R1 به R6 ممکن است چنین باشد:
R1 → R2 → R5 → R6
اما بهدلیل شلوغی لینک R2-R5، میخواهیم ترافیک حساس از مسیر زیر عبور کند:
R1 → R3 → R4 → R5 → R6
در SR، میتوان Policy زیر را تعریف کرد:
Segment List:
- Adj-SID(R1 → R3)
- Node-SID(R4)
- Node-SID(R5)
- Node-SID(R6)
در این مدل:
- Segment اول ترافیک را از لینک R1 به R3 عبور میدهد.
- Node-SID مربوط به R4، بسته را به R4 میرساند.
- Node-SIDهای بعدی ادامه مسیر را مشخص میکنند.
- روترهای Core نیازی به نگهداری Tunnel مستقل برای هر جریان ندارند.
سناریوی عملی و سناریوسازی پیادهسازی SR-MPLS
در یک سناریوی آزمایشگاهی، چهار روتر داریم:
R1 ---- R2 ---- R4
| |
+--- R3-+
فرضیات:
- پروتکل IGP: IS-IS یا OSPF
- Transport: MPLS
- فناوری Segment Routing: SR-MPLS
- هدف: عبور ترافیک R1 به R4 از طریق R3
- مسیر عادی IGP: R1 → R2 → R4
- مسیر مهندسیشده: R1 → R3 → R4
گام اول: فعالسازی IGP
ابتدا باید ارتباط IGP میان روترها برقرار شود. Loopback هر روتر باید در IGP Advertise شود.
نمونه مفهومی Cisco IOS-XE:
router ospf 10
router-id 10.255.0.1
segment-routing mpls
network 10.255.0.1 0.0.0.0 area 0
network 10.0.12.0 0.0.0.3 area 0
network 10.0.13.0 0.0.0.3 area 0
ساختار دقیق دستورات بر اساس نسخه IOS-XE و پلتفرم سختافزاری متفاوت است و باید با مستندات همان نسخه تطبیق داده شود.
گام دوم: اختصاص Prefix-SID
برای هر Loopback، یک Prefix-SID اختصاص داده میشود:
R1 Loopback: 10.255.0.1/32 → SID 16001
R2 Loopback: 10.255.0.2/32 → SID 16002
R3 Loopback: 10.255.0.3/32 → SID 16003
R4 Loopback: 10.255.0.4/32 → SID 16004
گام سوم: بررسی توزیع SID
پس از فعالسازی SR، باید بررسی شود که روترها اطلاعات SID یکدیگر را دریافت کردهاند.
موارد قابل کنترل:
- وضعیت Adjacency
- وجود Prefix-SID
- صحت Label Stack
- ارتباط MPLS در Interfaceها
- وجود مسیر در LFIB
- نصب SR Policy
گام چهارم: تعریف مسیر مهندسیشده
در طراحی ساده، Policy میتواند بهصورت زیر تعریف شود:
Headend: R1
Endpoint: R4
Preferred Path: R1 → R3 → R4
در طراحی پیشرفتهتر، میتوان معیارهایی مانند موارد زیر را اضافه کرد:
- حداقل تأخیر
- حداکثر Packet Loss
- ظرفیت باقیمانده
- رنگ لینک
- سطح سرویس
- اولویت برنامه کاربردی
مفهوم SR Policy و روشهای مدیریت حرکت ترافیک
SR Policy مجموعهای از قوانین است که مشخص میکند ترافیک مشخص چگونه در شبکه حرکت کند.
یک Policy معمولاً شامل موارد زیر است:
- Headend
- Endpoint
- Color
- Candidate Path
- Segment List
- Preference
- وزن یا اولویت
- مسیر پشتیبان
نمونه مفهومی:
Policy Name: VOICE-LOW-LATENCY
Headend: R1
Endpoint: R6
Color: 100
Preference: 200
Segment-List: R1-R3, R4, R5, R6
برای یک سرویس دیگر میتوان Policy متفاوتی تعریف کرد:
Policy Name: BACKUP-HIGH-CAPACITY
Headend: R1
Endpoint: R6
Color: 200
Preference: 100
Segment-List: R1-R2, R5, R6
در این مثال، ترافیک Voice مسیر کمتأخیر و ترافیک Backup مسیر پرظرفیت را انتخاب میکند.
مدیریت هوشمند مسیرها با استفاده از کنترلر مرکزی و PCE
در شبکههای بزرگ، تعریف دستی Segment List همیشه مناسب نیست. به همین دلیل، میتوان از PCE یا کنترلر مرکزی استفاده کرد.
کنترلر میتواند اطلاعات زیر را دریافت کند:
- توپولوژی شبکه
- ظرفیت لینکها
- تأخیر
- Packet Loss
- وضعیت خرابی
- نیازمندی سرویسها
- اولویت برنامهها
سپس بهترین مسیر را محاسبه و SR Policy را به Headend ارسال کند.
این معماری باعث میشود:
Telemetry → تولید → مسیر تحلیل Policy → نتیجه پایش → روتر به ارسال
در این روش، شبکه میتواند بر اساس وضعیت واقعی لینکها تصمیم بگیرد، نه فقط بر اساس Metric ثابت IGP.
اتوماسیون و مدیریت Segment Routing با زبان پایتون (Python)
Python میتواند برای کارهای زیر استفاده شود:
- دریافت وضعیت SR Policy
- بررسی SIDهای توزیعشده
- جمعآوری آمار Interfaceها
- تحلیل تأخیر و Packet Loss
- تشخیص عدم انطباق Policy
- تولید گزارش
- ارسال تغییرات از طریق API
- اعتبارسنجی مسیر پس از اعمال Policy
نمونه ساده برای ساختار تحلیل داده:
from dataclasses import dataclass
from typing import List
@dataclass
class LinkMetric:
source: str
destination: str
latency_ms: float
loss_percent: float
utilization_percent: float
def calculate_score(link: LinkMetric) -> float:
return (
link.latency_ms * 0.5
+ link.loss_percent * 10
+ link.utilization_percent * 0.2
)
links = [
LinkMetric("R1", "R2", 12, 0.2, 75),
LinkMetric("R1", "R3", 8, 0.1, 40),
LinkMetric("R3", "R4", 10, 0.1, 45),
]
for link in links:
print(link.source, link.destination, calculate_score(link))
در محیط واقعی، دادهها میتوانند از منابع زیر دریافت شوند:
- NETCONF
- RESTCONF
- gNMI
- Telemetry
- SNMP
- API کنترلر
- خروجی CLI ساختاریافته
روشهای اعتبارسنجی و تست مسیر پس از اعمال SR Policy
اعمال Policy بدون اعتبارسنجی نتیجه، رویکرد کاملی نیست. پس از ایجاد Policy باید موارد زیر بررسی شوند:
- آیا Policy فعال شده است؟
- آیا مسیر Candidate مورد نظر انتخاب شده؟
- آیا Segment List قابل اجراست؟
- آیا همه SIDها Resolve شدهاند؟
- آیا بسته از مسیر مورد انتظار عبور میکند؟
- آیا تأخیر و Loss مطابق SLA است؟
- آیا مسیر پشتیبان آماده است؟
ابزارهای بررسی میتوانند شامل موارد زیر باشند:
show segment-routing traffic-eng policy
show segment-routing mpls
show ip route
show mpls forwarding-table
traceroute mpls
نام و قالب دستورات بسته به سیستمعامل و پلتفرم ممکن است متفاوت باشد.
بازیابی سریع شبکه هنگام قطعی (Fast Reroute) با تکنولوژی TI-LFA
یکی از قابلیتهای مهم Segment Routing، استفاده از Topology Independent Loop-Free Alternate یا TI-LFA است.
در صورت قطع لینک یا Node، روتر میتواند بدون انتظار برای همگرایی کامل شبکه، بسته را از مسیر پشتیبان عبور دهد.
هدف TI-LFA این است که:
- از ایجاد Loop جلوگیری کند.
- زمان بازیابی را کاهش دهد.
- نیاز به Tunnelهای پشتیبان متعدد را کم کند.
- مسیر پشتیبان را بر اساس توپولوژی محاسبه کند.
سناریوی ساده:
مسیر اصلی:
R1 → R2 → R4
در صورت خرابی R1-R2:
R1 → R3 → R4
روتر R1 میتواند با استفاده از Segmentهای مناسب، ترافیک را موقتاً از مسیر جایگزین عبور دهد.

مهمترین چالشهای عملیاتی در پیادهسازی Segment Routing
مهمترین چالشهای عملیاتی در پیادهسازی Segment Routing
پشتیبانی سختافزاری
همه تجهیزات شبکه از SR-MPLS یا SRv6 پشتیبانی نمیکنند. باید موارد زیر بررسی شوند:
- مدل دقیق روتر
- نسخه IOS-XE یا IOS-XR
- قابلیت ASIC
- پشتیبانی Line Card
- محدودیت تعداد SID
- پشتیبانی از SR Policy
- قابلیت TI-LFA
برنامهریزی SID
اختصاص SID باید منظم و قابل مدیریت باشد. استفاده پراکنده یا تکراری از SIDها میتواند باعث خطاهای عملیاتی شود.
تعامل با تجهیزات قدیمی
در شبکههای واقعی، ممکن است همه روترها SR را پشتیبانی نکنند. بنابراین طراحی Migration و Boundary اهمیت زیادی دارد.
طول Segment List
هرچه مسیر دقیقتر باشد، ممکن است Segment List طولانیتر شود. در SR-MPLS این موضوع با تعداد Labelها و در SRv6 با اندازه Header مرتبط است.
امنیت Segment Routing
اگر کاربران غیرمجاز بتوانند Segment List دلخواه ایجاد کنند، ممکن است مسیرهای امنیتی دور زده شوند یا ترافیک به نقاط نامناسب هدایت شود.
کنترلهای امنیتی لازم عبارتاند از:
- محدودسازی دسترسی به API
- احراز هویت کنترلرها
- اعتبارسنجی Policyها
- فیلترکردن SIDهای مجاز
- ثبت تغییرات
- تفکیک نقشها
- مانیتورینگ مسیرهای غیرعادی
راهنمای گامبهگام مهاجرت (Migration) از LDP و RSVP-TE به Segment Routing
مهاجرت یکباره معمولاً پرریسک است. رویکرد مناسب، مهاجرت مرحلهای است.
مرحله اول: ارزیابی زیرساخت
- بررسی پشتیبانی تجهیزات
- بررسی نسخه نرمافزار
- مستندسازی توپولوژی
- شناسایی سرویسهای حساس
- بررسی وابستگی VPNها
مرحله دوم: فعالسازی SR در بخشی از Core
در ابتدا میتوان SR را روی چند روتر آزمایشی فعال کرد و رفتار آن را بررسی نمود.
مرحله سوم: اجرای همزیستی
در دوره انتقال، ممکن است بخشی از شبکه از LDP و بخش دیگر از SR استفاده کند. باید تعامل آنها بهطور دقیق آزمایش شود.
مرحله چهارم: انتقال Traffic Engineering
پس از اطمینان از عملکرد SR، مسیرهای TE جدید با SR Policy ایجاد میشوند.
مرحله پنجم: کاهش وابستگی به RSVP-TE
Tunnelهای قدیمی بهصورت مرحلهای بازنشسته میشوند.
مرحله ششم: حذف تدریجی LDP
پس از حذف تدریجی LDP
پس از انتقال کامل سرو، LDP میتواند از بخشهای مورد نظر حذف شود.
کاربرد Segment Routing در مراکزداده (Data Center) مدرن
در دیتاسنترهای مدرن، معماری Spine-Leaf و پروتکلهایی مانند BGP EVPN/VXLAN رایج هستند. Segment Routing میتواند در بخش Underlay یا بین دیتاسنترها استفاده شود.
کاربردهای احتمالی:
- انتخاب مسیر بین Spineها
- مهندسی ترافیک East-West
- اتصال چند دیتاسنتر
- Service Chaining
- مسیرهای متفاوت برای Storage و Application
- ایجاد مسیرهای کمتأخیر
- مدیریت ترافیک بین سایتها
در یک معماری دیتاسنتر، استفاده از SR بهتنهایی کافی نیست و باید با Overlay، EVPN، سیاستهای امنیتی و نیازمندیهای برنامهها هماهنگ شود.
سناریوی پیشنهادی برای یک سازمان بزرگ
فرض کنیم سازمان دارای سه دیتاسنتر است:
DC1 ---- Core-1 ---- DC2
\ /
------- DC3 -------
سرویسهای سازمان به سه گروه تقسیم شدهاند:
ترافیک Voice
- حساس به تأخیر
- حساس به Jitter
- نیازمند مسیر پایدار
ترافیک Application
- حساس به Loss
- نیازمند دسترسی پایدار به پایگاه داده
ترافیک Backup
- مصرفکننده پهنای باند
- دارای اولویت پایینتر
- قابل انتقال در ساعات خلوت
برای هر گروه میتوان SR Policy جداگانه ساخت:
VOICE:
کمترین Latency
APPLICATION:
کمترین Packet Loss
BACKUP:
مسیر با ظرفیت آزاد بیشتر
کنترلر یا سامانه Python میتواند بهصورت دورهای شرایط لینکها را دریافت کند و در صورت تغییر وضعیت، Candidate Path جدید را فعال نماید.
چکلیست عملیاتی پیادهسازی
پیش از اجرا
- بررسی Compatibility
- تهیه Backup
- مستندسازی SIDها
- تعریف محدوده آزمایش
- مشخصکردن Rollback Plan
- شناسایی مسیرهای حیاتی
- اندازهگیری Baseline
هنگام اجرا
- فعالسازی مرحلهای
- بررسی Adjacencyها
- بررسی Prefix-SID
- بررسی Labelها یا SRH
- تست مسیر یا SRH
- تست مسیرهای عادی
- تست Policyها
- بررسیدادها
پس از اجرا
- اعتبارسنجی End-to-End
- تست خرابی لینک
- بررسی TI-LFA
- مقایسه Latency و Loss
- بررسی مصرف منابع
- تحلیل هشدارها
- بهروزرسانی مستندات
سخن پایانی
Segment Routing رویکردی نوین برای سادهسازی و مقیاسپذیرکردن مسیریابی مهندسیشده در شبکههای بزرگ است. در معماریهای سنتی، LDP مسیرهای Label را عمدتاً بر اساس مسیر IGP ایجاد میکند و RSVP-TE برای کنترل دقیق مسیر به سیگنالینگ و نگهداری State گسترده نیاز دارد.
در مقابل، Segment Routing با استفاده از Source Routing، مسیر را بهصورت مجموعهای از Segmentها تعریف میکند. Prefix-SID و Node-SID برای رسیدن به مقصدها، Adj-SID برای عبور اجباری از لینک مشخص و Binding-SID برای نمایش Policyهای پیچیدهتر بهکار میروند.
در SR-MPLS، Segmentها با Label نمایش داده میشوند و امکان استفاده از زیرساخت MPLS موجود فراهم است. در SRv6، Segmentها در قالب IPv6 SID و SRH پیادهسازی میشوند و علاوه بر مسیریابی، قابلیت Network Programming و Service Chaining را نیز ارائه میکنند.
مهمترین مزیت Segment Routing، کاهش پیچیدگی کنترلی در Core و فراهمکردن Traffic Engineering بدون وابستگی گسترده به سیگنالینگ RSVP است. بااینحال، موفقیت پروژه به پشتیبانی تجهیزات، برنامهریزی SID، طراحی مهاجرت، امنیت Policyها و توانایی تیم عملیاتی در عیبیابی بستگی دارد.
بهترین رویکرد، مهاجرت مرحلهای و مبتنی بر آزمایش است. سازمان باید ابتدا زیرساخت خود را ارزیابی کند، SR را در بخش محدودی فعال نماید، مسیرهای مهندسیشده را آزمایش کند و سپس بهتدریج وابستگی به LDP و RSVP-TE را کاهش دهد.
در نهایت، Segment Routing فقط یک جایگزین برای LDP یا RSVP-TE نیست؛ بلکه میتواند پایهای برای شبکههای قابلبرنامهریزی، خودکار، مبتنی بر سیاست و آماده برای نیازهای نسل آینده باشد.


