> For the complete documentation index, see [llms.txt](https://linkmeup.gitbook.io/sdsm/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://linkmeup.gitbook.io/sdsm/10.-base-mpls/04.-faq.md).

# ВиО

**В1:** Чем отличаются RSVP TE LSP и LDP LSP?

> Строго говоря, с точки зрения как вышестоящиех протоколов, так и самого MPLS таких понятий нет вообще. LSP — он и есть LSP — это просто путь коммутации меток.\
> Можно выделить термин CR-LSP (ConstRaint-based LSP) — он строится RSVP TE. В этом плане разница в том, что CR-LSP удовлетворяет условиям заданным в туннельном интерфейсе.

**В2:** Как соотносятся Explicit Path и ERO?

> Если для туннеля задан Explicit Path, то RSVP формирует ERO, учитывая требования Explicit Path. При этом даже если вы в Explicit-Path пропишите каждый узел до Egress LSR, RSVP всё равно загонит данные в CSPF.

**В3:** Если один из промежуточных узлов не будет поддерживать LDP (RSVP TE) или протокол будет выключен на интерфейсе/платформе, будет ли построен LSP так, например, чтобы на этом узле он переходил в IP, а потом на следующем снова в MPLS?

> В случае RSVP TE Ingress LSR не будет иметь данного узла в TED и не сможет выстроить путь до Egress LSR, соответственно не пошлёт Path, соответственно, не будет и меток и LSP.\
> Трафик через туннель передаваться не сможет.\
> \
> Если же речь о LDP, то ситуация интереснее. Например, если на R2 выключить LDP на интерфейсе FE0/0 (в сторону R5), то\
> 1\) на R1 будет метка для FEC 6.6.6.6/32. Причём их будет 2: одна через R2, другая — через R3, поскольку согласно таблице маршрутизации лучший — через R2, то и LSP будет лежать в сторону R2.\
> 2\) на R2 метка будет, но только одна — в сторону 1.1.1.1. Это не лучший путь, поэтому он не будет использован. То есть здесь LSP от R1 к FEC 6.6.6.6/32 прекращает своё существование.\
> 3\) на R5 метка для FEC 6.6.6.6/32 будет\
> \
> То есть, вроде бы, мы получаем разорванный LSP: {R1-R2, R5-R6}. Но на самом деле, это не так. LSP на то и Label Switched, чтобы на протяжении всего пути на нём менялись метки, а у нас получается от R1 до R2 MPLS, от R2 до R5 IP, а от R5 до R6 опять MPLS. **LSP для FEC 6.6.6.6/32 здесь нет**. Обычный трафик тут пройдёт, в принципе, но если говорить о каких-то применениях MPLS, таких, например, как VPN, то это работать не будет.

**В4:** Хорошо, зачем нужен MPLS будет понятно из следующих статей — пока это вообще какая-то искусственная ерунда, чтобы усложнить жизнь инженера, но зачем мне MPLS TE-то? Ведь трафик можно направить нужным мне путём с помощью метрик IGP.

> Начнём с того, что это тема будущих выпусков. Но…\
> Вообще говоря, если вы хотите определять путь, по которому пойдёт трафик, то это действительно можно сделать путём хитрой настройки стоимости линков, интерфейсов итд. Но обслуживание такой системы доставит вам те ещё хлопоты с одной стороны, а с другой у вас всё равно не получится направить два разных потока разными путями. То есть если стоит задача разгрузить сеть путём распределения трафика, то с помощью метрик вы просто перенесёте проблему с одного плеча на другое.\
> А вот если у вас будет несколько разных LSP и вы сможете направить в них трафик, то это пожалуйста. Хотя в плане простоты поддержки TE тоже вызывает вопросы.\
> \
> Ну и вообще подумайте, если вам нужны для двух клиентов гарантированные каналы 40 Мб/с и 50 Мб/с соответственно, как вы будете отслеживать утилизацию линий? Ну хорошо, один раз вы вычислили и настроили каким-то чудесным образом маршрутизацию и QoS так, чтобы обеспечить нужный уровень услуги, но вдруг у вас срезают в трёх местах 3 километра оптики разом и вы неделю не можете починить. И у вас даже есть три резервных канала по 50Мб/с, но трафик обоих клиентов попёр в одно место, наплевав на все ваши формальные [SLA](http://lookmeup.linkmeup.ru/#term433).

**В5:** Так чем всё-таки отличаются метки Explicit Null и Implicit Null? Нужно ли мне о них действительно знать?

> Нужно. Первоначально предполагается, что по сети MPLS пакет всегда **коммутируется** по меткам от первого до последнего LSR. А на последнем пролёте метка будет «0», чтоб Egress LSR сразу знал, что её нужно снять. Эта метка позволяет не потерять приоритет, заданный в поле TC заголовка MPLS, который копируется по мере передачи пакета по сети. В итоге даже последний маршрутизатор обработает данные в правильных очередях.\
> \
> В концепции с использованием метки «3» решили отказаться от лишних действий на Egress LSR. Если вас не волнует QoS (или вы скопировали приоритет, например, в поле DSCP), то острой нужды в транспортной метке на последнем пролёте нет — главное отправить в правильный интерфейс, а там Egress LSR разберётся. Если там был чистый IP-пакет — отдать его процессу IP, если был какой-нибудь E1, передать поток в нужный интерфейс, если стек меток, то сделать lookup в LFIB и посмотреть, какие дальнейшие действия нужно предпринять.

**В6:** Для одного FEC LSR всегда будет выделять одну и ту же метку всем своим соседям?

> Существует понятие пространства меток:
>
> * пространство меток интерфейса
> * пространство меток слота
> * пространство меток платформы
>
> Если метки специфичны для каждого интерфейса, тогда для одного FEC в разные порты **могут** быть отправлены разные метки.\
> И наоборот — если метки специфичны для платформы (читай всего LSR), то маршрутизатор во все порты для одного FEC **обязан** отправить одинаковые метки.\
> В примерах ниже вы увидите, что у нас для одного FEC отправляются одинаковые метки разным соседям, но это ещё не говорит о том, как организовано пространство меток. Это вещь сугубо индивидуальная и завязана на аппаратном обеспечении.

Важно понимать, что технология MPLS никак не регламентирует протокол распространения меток, но конечные результаты на конкретной сети вполне могут различаться при использовании разных протоколов. Вышестоящие протоколы и приложения используют LSP безотносительно того, кем и как они построены.\
Кстати нередко в современных сетях встречается сценарий LDP over TE. В этом случае RSVP-TE используется для организации транспорта и реализации Traffic Engineering, а LDP для обмена метками VPN, например.\
Ingress LSR, записывая в заголовок MPLS первую метку, определяет весь путь пакета. Промежуточные маршрутизаторы просто меняют одну метку на другую. Содержимое может быть совершенно любым. Как раз вот эта мультипротокольность позволяет MPLS служить основой для разнообразных сервисов VPN.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://linkmeup.gitbook.io/sdsm/10.-base-mpls/04.-faq.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.