.. заглавие: Пример за маршрутизиране на сегменти — SR-MPLS и SRv6
.. slug: segment-routing-primer
.. дата: 2026-04-07 12:00:00 UTC
.. тагове: сегментно маршрутизиране, sr-mpls, srv6, mpls, трафик-инженеринг, мрежа
.. категория: Статии
.. връзка:
.. описание: Практическо ръководство за архитектура на маршрутизиране на сегменти, стекове с етикети SR-MPLS, SRv6 SIDs и заглавка на маршрутизиране на сегменти, инженеринг на трафика на SR-TE и сравнение с RSVP-TE.
.. тип: текст
<style>
.calc-container { max-width: 860px; margin: 20px auto; padding: 20px; }
.calc-header { margin-bottom: 30px; padding: 25px; background: linear-gradient(135deg, #667eea 0%, #764ba2 100%); border-radius: 12px; box-shadow: 0 4px 6px rgba(0,0,0,0.1); color: white; }
.calc-header h2 { margin-top: 0; color: white; font-size: 28px; margin-bottom: 10px; }
.calc-header p  { margin: 10px 0; opacity: 0.95; font-size: 15px; }
.result-section { background: white; border: 1px solid #e0e0e0; border-radius: 8px; margin-top: 20px; overflow: hidden; box-shadow: 0 2px 4px rgba(0,0,0,0.05); }
.section-content { padding: 20px; background: #fafafa; }
@media (max-width: 768px) { .calc-header h2 { font-size: 22px; } .calc-container { padding: 10px; } }
.article-body { padding: 24px; background: white; line-height: 1.8; font-size: 15px; color: #333; }
.article-body h3 { color: #2d6a2d; border-bottom: 2px solid #4CAF50; padding-bottom: 6px; }
.article-body a { color: #2d6a2d; }
.article-body a:hover { color: #4CAF50; }
.callout { background: #e8f5e9; border-left: 4px solid #4CAF50; padding: 12px 16px; border-radius: 6px; margin: 16px 0; font-size: 14px; }
.callout.warn { background: #fff8e0; border-color: #f0a500; }
pre, .code-block { background: #1e1e2e; color: #cdd6f4; padding: 14px 18px; border-radius: 8px; font-family: 'Courier New', monospace; font-size: 13px; overflow-x: auto; line-height: 1.5; margin: 12px 0; white-space: pre; }
table { width: 100%; border-collapse: collapse; margin: 16px 0; font-size: 14px; }
th { background: #2d6a2d; color: white; padding: 10px 12px; text-align: left; }
td { padding: 8px 12px; border-bottom: 1px solid #e0e0e0; vertical-align: top; }
tr:nth-child(even) td { background: #f5f5f5; }
</style>
<div class="calc-container">
<div class="calc-header">
<h2>Праймер за маршрутизиране на сегменти — SR-MPLS и SRv6</h2>
<p>Маршрутизиране на източника без състояние на поток: как SR замества RSVP-TE, какво правят Node-SID и Adj-SID, как SRv6 кодира инструкции в IPv6 адреси и къде SR-TE се вписва в инженеринга на трафика.</p>
</div>
<div class="result-section">
<div class="section-content article-body">
<h3 id="rsvp-problem">1. Проблемът с RSVP-TE</h3>
<p>RSVP-TE (Протокол за резервиране на ресурси — Инженеринг на трафика,<a href="https://www.rfc-editor.org/rfc/rfc3209" target="_blank">RFC 3209</a>) активира явен контрол на пътя в MPLS мрежи, но въведе значителна оперативна сложност:</p>
<ul>
<li><strong>Състояние на поток:</strong>Всеки LSP изисква състояние на всеки рутер по пътя (RSVP PATH и RESV съобщения). В мрежа с хиляди LSP транзитните рутери поддържат огромни таблици с меко състояние, които трябва да се обновяват непрекъснато.</li>
<li><strong>Сигнализация на главата:</strong>Входящият (главен) рутер сигнализира пътя чрез RSVP. Всяка промяна на топологията изисква повторно сигнализиране, създавайки допълнителни разходи за конвергенция.</li>
<li><strong>Мащабируемост:</strong>Броят на LSP нараства с O(N²) за пълна мрежа и всеки LSP консумира LFIB записи на всеки транзитен рутер.</li>
<li><strong>Сложност на бързото пренасочване:</strong>RSVP-FRR (RFC 4090) защитава LSP с предварително изчислени обходни маршрути или тунели за обход на съоръженията – функция, която работи, но добавя още един слой на състоянието.</li>
</ul>
<p>Маршрут на сегмента (<a href="https://www.rfc-editor.org/rfc/rfc8402" target="_blank">RFC 8402</a>) елиминира изцяло състоянието на потока в транзитните възли. Изходният рутер кодира целия път на пренасочване като подреден списък от<em>сегменти</em>в самата заглавка на пакета. Транзитните маршрутизатори обработват само активния сегмент и не се нуждаят от LSP състояние.</p>
<h3 id="sr-architecture">2. SR архитектура (RFC 8402)</h3>
<p>A <em>сегмент</em>е инструкция, която казва на рутер как да препрати пакета – може да означава „отидете до този възел“, „излезте в тази конкретна съседство“ или „приложете това VPN търсене“. Сегментите се идентифицират чрез сегментни идентификатори (SID). Подреден списък от SID е<em>списък със сегменти</em>(или SID-списък). Активният сегмент се обработва при всеки скок; когато обработката приключи, сегментът се премахва и следващият става активен.</p>
<p>Съществуват две инстанции на равнина на данни:</p>
<ul>
<li><strong>SR-MPLS</strong>: SIDs са MPLS етикети. Списъкът със сегменти е стек от етикети. Обратно съвместим със съществуващ MPLS хардуер.</li>
<li><strong>SRv6</strong>: SID са 128-битови IPv6 адреси. Списъкът със сегменти се пренася в заглавката за маршрутизиране на сегменти (SRH, заглавка на разширение IPv6). IPv6-роден; не се изисква MPLS.</li>
</ul>
<h3 id="sr-mpls">3. SR-MPLS: Node-SID, Adj-SID и SRGB</h3>
<p>SR-MPLS (<a href="https://www.rfc-editor.org/rfc/rfc8660" target="_blank">RFC 8660</a>) дефинира два основни типа SID, рекламирани от IS-IS (<a href="https://www.rfc-editor.org/rfc/rfc8667" target="_blank">RFC 8667</a>) или OSPF (<a href="https://www.rfc-editor.org/rfc/rfc8665" target="_blank">RFC 8665</a>) като TLV разширения:</p>
<table>
<tr><th>Тип SID</th><th>Обхват</th><th>Стабилност</th><th>Значение</th></tr>
<tr><td><strong>Node-SID</strong></td><td>Глобален (SRGB)</td><td>Упорит</td><td>„Доставете до този възел, като използвате най-краткия IGP път.“ Всеки рутер има един Node-SID за loopback/router-ID. Всички рутери в SR домейна трябва да програмират този етикет.</td></tr>
<tr><td><strong>Съседство-SID</strong>(Adj-SID)</td><td>Локален (SRLB или динамичен)</td><td>Ефимерно (на сесия)</td><td>„Препратете този специфичен интерфейс към този конкретен съсед.“ Използва се за насочване на пакет към определена връзка, независимо от най-краткия път.</td></tr>
<tr><td><strong>Anycast-SID</strong></td><td>Глобален</td><td>Упорит</td><td>Споделя се от набор от възли (напр. група за произволно предаване на отражатели на маршрути или PoP точки на център за данни). Пакетите се доставят до най-близкия член.</td></tr>
</table>
<p>The<strong>SRGB</strong>(Глобален блок за маршрутизиране на сегмент) е диапазонът на етикетите, запазен за глобално значими SID. Общата стойност по подразбиране е 16000–23999 (Cisco, Juniper), въпреки че може да се конфигурира. Node-SID са кодирани като<em>стойности на индекса</em>(напр. индекс 100) и се разрешава до етикет чрез добавяне на индекса към базата SRGB (напр. 16000 + 100 = етикет 16100). Всички рутери трябва да използват един и същ SRGB, за да бъдат глобалните SIDs последователни — несъответстващите SGRB между доставчици или конфигурации причиняват неправилно етикетиране.</p>
<div class="callout warn">
<strong>Adj-SID са локални и не са стабилни при рестартиране или прекъсване на връзката.</strong>Никога не използвайте Adj-SID в статична SR политика или го запазвайте в оперативни скриптове. Използвайте Node-SID за стабилни пътища и Adj-SID само в рамките на динамично изчислени SR-TE пътища, където контролерът проследява текущите стойности.</div>
<p><strong>Пример за стек с етикети SR-MPLS</strong>— изпращане на трафик от R1 към R5 през R3 (явна точка), като се избягва директният път R1→R5:</p>
<pre>Ingress R1 pushes: [Node-SID(R3)] [Node-SID(R5)]
  R1→R2: outer label = SID(R3), inner = SID(R5)
  R2→R3: pops SID(R3) (PHP or explicit-null)
  R3 sees top label = SID(R5); forwards on shortest path to R5
  R5 pops SID(R5); delivers to local application</pre>
<h3 id="srv6">4. SRv6: SID като IPv6 адреси</h3>
<p>SRv6 (<a href="https://www.rfc-editor.org/rfc/rfc8986" target="_blank">RFC 8986</a>) кодира SID като 128-битови IPv6 адреси, структурирани като:</p>
<pre>| Locator (e.g., /48) | Function (operator-defined, typically 16 bits) | Argument (remaining bits) |</pre>
<ul>
<li><strong>Локатор</strong>: Маршрутизиран IPv6 префикс, присвоен на възела. Транзитните маршрутизатори се насочват към този префикс нормално. Локаторът е обявен в IGP.</li>
<li><strong>функция</strong>: Идентифицира конкретната операция, която да се извърши в крайната точка на SID. Примери: End (препращане към следващия SID), End.X (препращане към специфична съседност), End.DT4 (decap и IPv4 търсене в таблица — използва се за IPv4 VPN), End.DX2 (decap и L2 кръстосано свързване).</li>
<li><strong>Аргумент</strong>: Незадължителен допълнителен контекст за функцията (напр. идентификатор на поток за ентропия).</li>
</ul>
<p>Списъкът със сегменти се носи в<strong>СРЗ</strong>(Заглавка за маршрутизиране на сегмент,<a href="https://www.rfc-editor.org/rfc/rfc8754" target="_blank">RFC 8754</a>) — заглавка на разширение IPv6 със следваща заглавка = 43 (заглавка за маршрутизиране), тип на маршрутизация = 4. SRH съдържа:</p>
<ul>
<li>Сегмент отляво (SL): индекс в списъка със сегменти, сочещ към активния SID</li>
<li>Етикет: съвет за класификация на потока</li>
<li>Списък на сегменти [0..n]: подредените SID (последният SID е дестинацията)</li>
</ul>
<p>Във всеки SR-съзнаващ възел, ако IPv6 дестинацията съвпада с локален SID, възелът изпълнява функцията на SID, намалява сегмента отляво и копира списъка със сегменти [сегмент отляво] в IPv6 DA преди препращане.</p>
<h3 id="sr-te">5. Трафик Инженеринг със SR-TE</h3>
<p>SR-TE (<a href="https://www.rfc-editor.org/rfc/rfc9256" target="_blank">RFC 9256</a>— SR Policy Architecture) заменя RSVP-TE LSP с<em>SR политики</em>, всяка дефинирана от:</p>
<ul>
<li><strong>Главна станция</strong>: Входящият възел, който инстанцира политиката</li>
<li><strong>Цвят</strong>: 32-битов идентификатор, използван за свързване на трафик (чрез разширена общност на BGP Color) с правилата</li>
<li><strong>Крайна точка</strong>: Целевият възел</li>
<li>Един или повече<strong>кандидатски пътища</strong>, всеки с претеглен списък със сегменти</li>
</ul>
<p>Пътищата на кандидатите се изчисляват от централната станция (използвайки локален CSPF/PCE) или се разпространяват от централизиран SR-PCE/контролер през PCEP (<a href="https://www.rfc-editor.org/rfc/rfc5440" target="_blank">RFC 5440</a>) или BGP SR политика (вижте<a href="https://www.rfc-editor.org/rfc/rfc9256" target="_blank">RFC 9256</a>§8). Това елиминира напълно RSVP сигнализиращата равнина, като същевременно запазва изричния контрол на пътя.</p>
<p><strong>Следващ хоп по заявка (ODN)</strong>е функция SR-TE, при която централната станция автоматично инстанцира SR политика, когато пристигне BGP маршрут с конкретна цветна общност, без предварително осигуряване — позволявайки автоматизирано управление на трафика за VPN и CDN префикси.</p>
<h3 id="comparison">6. SR-MPLS срещу SRv6 срещу RSVP-TE</h3>
<table>
<tr><th></th><th>SR-MPLS</th><th>SRv6</th><th>RSVP-TE</th></tr>
<tr><td>Равнина на данни</td><td>MPLS етикет стек</td><td>IPv6 + заглавка на разширение SRH</td><td>MPLS етикет стек</td></tr>
<tr><td>Състояние на поток при транзит</td><td>Няма</td><td>Няма</td><td>Да (меко състояние на RSVP)</td></tr>
<tr><td>Сигнален протокол</td><td>IGP (IS-IS/OSPF) разширения</td><td>IGP разширения</td><td>RSVP-TE (PATH/RESV)</td></tr>
<tr><td>HW съвместимост</td><td>Всеки MPLS HW</td><td>Изисква ASIC, поддържащ SRv6</td><td>Всеки MPLS HW</td></tr>
<tr><td>Разход за пакет</td><td>4 B на етикет</td><td>8 + 16n B (SRH с n SID)</td><td>0 (MPLS етикет вече е в стека)</td></tr>
<tr><td>VPN поддръжка</td><td>Чрез MPLS VPN етикети</td><td>End.DT4/DT6/DX2 SID функции</td><td>Чрез MPLS VPN етикети</td></tr>
<tr><td>Бързо пренасочване</td><td>TI-LFA (независим от топологията, без предварителна конфигурация)</td><td>TI-LFA</td><td>RSVP-FRR (предварително осигурен байпас)</td></tr>
<tr><td>Зрялост на внедряване</td><td>Широко разпространен в SP/DC</td><td>отглеждане; Поддръжката на ASIC все още се развива</td><td>Зрял, но западащ</td></tr>
</table>
<h3 id="references">Референции</h3>
<ul>
<li><a href="https://www.rfc-editor.org/rfc/rfc8402" target="_blank">RFC 8402</a>— Архитектура на сегментно маршрутизиране</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8660" target="_blank">RFC 8660</a>— Сегментно маршрутизиране с MPLS Data Plane</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8665" target="_blank">RFC 8665</a>— OSPF разширения за сегментно маршрутизиране</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8667" target="_blank">RFC 8667</a>— IS-IS разширения за маршрутизиране на сегменти</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8669" target="_blank">RFC 8669</a>— Разширения SID на префикса за маршрутизиране на сегменти за BGP</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8754" target="_blank">RFC 8754</a>— Заглавка за маршрутизиране на IPv6 сегмент (SRH)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8986" target="_blank">RFC 8986</a>— Сегментно маршрутизиране през IPv6 (SRv6) мрежово програмиране</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc9252" target="_blank">RFC 9252</a>— BGP услуги за наслагване, базирани на сегментно маршрутизиране през IPv6 (SRv6)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc9256" target="_blank">RFC 9256</a>— Архитектура на политиките за маршрутизиране на сегменти</li>
<li><a href="https://datatracker.ietf.org/wg/spring/documents/" target="_blank">Работна група IETF SPRING</a>— Изходно маршрутизиране на пакети в мрежа (активни SR чернови)</li>
</ul>
</div>
</div>
</div>