ВиО

В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.

В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.