Глава 2. Label Distribution Protocols (RSVP, LDP)

RSVP

RSVP - resource reservation protocol - требует больше конфигурации для работы, чем LPD, но зато имеет больше полезных фич, таких как: TE, fast-failover, QoS, bandwidth reservation, LSP customization.

LSP установлена и имеет свой record route: список IP адресов интерфейсов, через которые проходит RSVP LSP, включая ingress и egress.

Второй preference у RSVP: Когда внутри протокола требуется сравнение маршрутов. RSVP auto mesh - preference 2 = 3. Если на сети будет построен RSVP туннель статический и auto-mesh, то предпочтительней будет статический. (preference 2: 1 < 3).

В LDP нет требования добавлять интерфейсы в protocols mpls, но family mpls включать нужно.

Принцип работы протокола

LDP - автоматом строит full mesh туннели до соседей. RSVP - не просто строит туннели, а использует для построения TE + используются механизмы защиты трафика: FastRerote, LinkProtection...

RSVP - протокол signaling.

RSVP инкапсулируется сразу в ip.

RSVP пакет стоит из объектов. Объект имеет тип, и поле данных.

Типы сообщений:

• Path: запрос, чтобы LSP была построена: от ingress
• Resv: Резервирует ресурсы для LSP: от egress
• PathTear: удаляет path state и сообщает об этом: от LSR, где упала LSP к downstream
• ResvTear: удаляет reservation state: от LSR, где упала LSP к upstream
• PathErr: сообщение с ошибкой: к upstream
• ResvErr: сообщение с ошибкой: к downstream

Объекты path message:

• SESSION_ID
• LABEL_REQUEST
• EXPLICIT_ROUTE: strict/loose list of routers
• RECORD_ROUTE: list of addresses of all routers in path
• SESSION_ATTRIBUTE
• RSVP_HOP: interface ip of router which send path message

Для работы RSVP нужно:

1. Включить протокол RSVP
2. Конфигурируем туннель только на ingress.

Ingress -> Egress: При построении туннеля на Ingress (A) создается ip-пакет pathMessage, который состоит из:

1. dst: ip dst (192.168.0.4), по метриками внутреннего протокола узнает где конечный роутер.
2. session ID - идентификатор rsvp сессии на control plane. Все rsvp роутеры, через которые строится туннель - ассоциируют все сообщения для туннеля по session ID. Генерируется ingress роутером, состоит из router ID + какое-то число.
3. label request: определяет поведение транзитных маршрутизаторов, заставляет резервировать метки для туннеля.

Transit router 1 (B): 1.Видит label request, выделяет (запоминает, но никуда не записывает) для туннеля метку из свободных, ассоциирует ее с session ID.

Transit router 2 (C):

1. Видит label request, выделяет (запоминает, но никуда не записывает) для туннеля метку из свободных, ассоциирует ее с session ID.

Egress router (D):

1. dst addres = его loopback => он последний. Резервирует метку 3 (по дефлоту).

Формирует ResvPath - основная его суть - проанонсировать зарезервированную метку предыдущему роутеру.

Egress -> Ingress: resvPath: session ID из PathMessage, label: (то, что он зарезервировал) 3.

Transit 2 (C):

1. По session ID определяет какую метку он зарезервировал (30).
2. Смотрит в label, видит 3. Понимает, что он должен передавать к egress пакет с меткой 3.
3. mpls.0: 30 swap 3 = 30 pop

Transit 1 (B):

1. По session ID определяет какую метку он зарезервировал (20).
2. Смотрит в label, видит 30. Понимает, что он должен передавать к egress пакет с меткой 30.
3. mpls.0: 20 swap 30

Ingress (A):

1. inet.0: 192.168.0.4: -> BGP, push 30

Туннель - это просто метки.

При падении линка между роутерами: Генерируются pathTear (в сторону ingress) и resvTear (в сторону egress), чтобы все транзитные роутеры освободили метки, а ingress понял, что этого туннеля больше нет.

В это время IGP пересчитал топологию, ingress router увидел next-hop для egress роутера и rsvp заново начал строить туннель.

Keepalive: Ingress роутер раз в 30 сек (по дефолту) обновляет состояние с помощью посылки pathMessage.

resvMessage должен пройти по тому же пути, что и pathMessage. Но маршрутизация может быть не симметричной. отличие resv и path: dst add - не loopback конечных роутеров, а адрес предыдущего роутера из ERO (также предотвращает зацикливание).

Туннель может устанавливаться с требованиями к полосе. Задается в bandwith - передается в объекте TSpec.

Если RSVP не может установить туннель, то на проблемном участке генерируется pathErr - сообщение с кодом ошибки. Bandwith - только для сигнализации, реально полосу не ограничивает.

Если нужно провести траблшутинг, лучше делать тут:

set protocol rsvp traceoptions file RSVP-trouble flag all detail

RSVP поддерживает mtu discovery и fragmentstion на ingress роутере.

RSVP поддерживает аутентификацию (MD5)

RSPV может использовать Gracefull restart.

RSVP может работать как point-to-multipoint => можно исключить из ядра всякие multicast протоколы.

Configuration

1. Включаем family mpls на интерфейсах, смотрящих в ядро. Эта настройка позволяет отправлять и получать пакеты с метками.

[edit interfaces]
   set ge-0/0/2.0 family mpls
   set ge-0/0/3.0 family mpls

2. Настраиваем LSP. И добавляем нужные интерфейсы в protocols mpls. Это позволяет запустить на указанных интерфейсах mpls и появиться в TED, как возможный ресурс для использования.

[edit protocols mpls]
	set label-switched-path R1-to-R5 {
		to 10.200.86.3;
	}
	interface ge-0/0/2.0;
	interface ge-0/0/3.0;

3. Добавляем в протокол RSVP нужные интерфейсы.

[edit protocols rsvp]
	set interface ge-0/0/2.0
	set interface ge-0/0/3.0

4. На остальных роутерах требуется включить family mpls и добавить интерфейсы в protocols rsvp.

RSVP auto-mesh

Когда на сети используется RSVP, но для конкретных функций (L3VPN, VPLS, ...) требуется full-mesh, то чтобы не прописывать все LSP руками, можно использовать RSVP-full-mesh.

Строится, когда:

• От PE пришел iBGP маршрут (inet.0, VPLS, L3VPN)
• IP PE из определенного диапазона.

[edit routing-options]
dynamic-tunnels {
   tunnel-1 {
       rsvp-te tunnel-1 {
           label-switched-path-template {
               default-template;
           }
           destination-networks {
               10.200.86.0/26;

В книге описано, что просто туннель не поднимется (лаба на mx80), т.к. требуется маршрут до Lo PE с меткой в inet.0. Решение: Нужно временно включить LDP и set protocols mpls traffic-engineering bgp-igp-both-ribs, ждем пока построятся RSVP LSP, потом отключаем LDP.

Но по факту в лабе завелось и без дополнительных манипуляций с LDP (лаба на vSRX). =)

В итоге, когда приходят пакеты по iBGP, то до protocol next-hop (Lo PE, который должен попадать в dest-networks) автоматически поднимается туннель.

bgp.l3vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.200.86.3:1212:12.12.12.12/32
                  *[BGP/170] 12:34:36, localpref 100, from 10.200.86.3
                     AS path: I
                   > to 192.168.86.1 via ge-0/0/0.30, label-switched-path 10.200.86.3:dt-rsvp-tunnel-1

bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.200.86.9:1515:1:1/96
                  *[BGP/170] 12:16:54, localpref 100, from 10.200.86.9
                     AS path: I
                   > to 192.168.86.1 via ge-0/0/0.30, label-switched-path 10.200.86.9:dt-rsvp-tunnel-1

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.200.86.0/26     *[Tunnel/300] 12:10:07
                     Tunnel
10.200.86.3/32     *[RSVP/7/3] 00:03:04, metric 4
                   > to 192.168.86.1 via ge-0/0/0.30, label-switched-path 10.200.86.3:dt-rsvp-tunnel-1
10.200.86.9/32     *[RSVP/7/3] 00:03:04, metric 5
                   > to 192.168.86.1 via ge-0/0/0.30, label-switched-path 10.200.86.9:dt-rsvp-tunnel-1

lagavulin> show mpls lsp name 10.200.86.3:dt-rsvp-tunnel-1 detail
Ingress LSP: 2 sessions
10.200.86.3
 From: 10.200.86.7, State: Up, ActiveRoute: 0, LSPname: 10.200.86.3:dt-rsvp-tunnel-1
 ActivePath:  (primary)
 PathDomain: Inter-domain
 LSPtype: Dynamic Configured
 LoadBalance: Random
 Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary                    State: Up
   Priorities: 7 0
   SmartOptimizeTimer: 180
   Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 4)
192.168.86.1 S 192.168.86.41 S 192.168.86.50 S 192.168.86.25 S
   Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
         192.168.86.1 192.168.86.41 192.168.86.50 192.168.86.25

• Можно добавлять разные фичи TE:

[edit protocols mpls]
label-switched-path default-template {
   template;
   link-protection;

• Если до одного и того же Lo PE есть динамический и статический LSP, то будет выбран статический, т.к. у него preference 2 меньше:

inet.3: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden)
10.200.86.3/32     *[RSVP/7/1] 00:00:26, metric 4
                   > to 192.168.86.1 via ge-0/0/0.30, label-switched-path lagavulin-to-oban
                   [RSVP/7/3] 00:02:32, metric 4
                   > to 192.168.86.1 via ge-0/0/0.30, label-switched-path 10.200.86.3:dt-rsvp-tunnel-1

• Если по iBGP перестают прилетать маршруты, то туннель через 15 минут умрет:

lagavulin> show dynamic-tunnels database
Table: inet.3
Destination-network: 10.200.86.0/26
Tunnel to: 10.200.86.9/32 (expires in 00:14:46 seconds)
 Reference count: 0
 Next-hop type: rsvp-te
   10.200.86.9:dt-rsvp-tunnel-1

P2MP

В случае использования P2P LSP, source PE должен расплодить несколько копий трафика и послать по разным LSP.

В случае использования P2MP: source PE отправляет трафик, копирование трафика происходит на определенном transit роутере, где происходит дальнейшее разветвление путей передачи трафика (branch point).

Таким образом уменьшится число копий трафика в сети. Копирование будет происходить только на branch points.

Сам туннель будет состоять также из 3 RSVP сессий.

Ingress посылает path message с session ID - одинаковый для всех leaf, label request, передаем router-ID удаленного роутера.

При построении отдельного Leaf - на всех транзитных роутерах будет выделена одна и та же метка.

Мы руками задаём от какого PE к какому строить туннель, потому что только мы знаем где расположен source.

Config

Задаем на ingress PE:

dalwhinnie> show configuration protocols mpls
no-cspf;
label-switched-path dalwhinnie-to-oban {
   to 10.200.86.3;
   p2mp p2mp1;
   primary via_glenlivet;
label-switched-path dalwhinnie-to-macduff {
   to 10.200.86.8;
   p2mp p2mp1;
   primary via_glenlivet;
label-switched-path dalwhinnie-to-talisker {
   to 10.200.86.4;
   p2mp p2mp1;
   primary via_glenlivet;
path via_glenlivet {
   10.200.86.6 loose;

dalwhinnie> show mpls lsp p2mp ingress
Ingress LSP: 1 sessions
P2MP name: p2mp1, P2MP branch count: 3
To              From            State Rt P     ActivePath       LSPname
10.200.86.3     10.200.86.5     Up     0 *     via_glenlivet    dalwhinnie-to-oban
10.200.86.8     10.200.86.5     Up     0 *     via_glenlivet    dalwhinnie-to-macduff
10.200.86.4     10.200.86.5     Up     0 *     via_glenlivet    dalwhinnie-to-talisker

glenlivet> show mpls lsp p2mp transit
Transit LSP: 5 sessions
P2MP name: p2mp1, P2MP branch count: 3
To              From            State   Rt Style Labelin Labelout LSPname
10.200.86.3     10.200.86.5     Up       0  1 SE  300144   300032 dalwhinnie-to-oban
10.200.86.8     10.200.86.5     Up       0  1 SE  300144   300256 dalwhinnie-to-macduff
10.200.86.4     10.200.86.5     Up       0  1 SE  300144   300256 dalwhinnie-to-talisker

mortlach> show mpls lsp p2mp transit
Transit LSP: 2 sessions
P2MP name: p2mp1, P2MP branch count: 2
To              From            State   Rt Style Labelin Labelout LSPname
10.200.86.8     10.200.86.5     Up       0  1 SE  300256        3 dalwhinnie-to-macduff
10.200.86.4     10.200.86.5     Up       0  1 SE  300256        3 dalwhinnie-to-talisker

blair> show mpls lsp p2mp transit
Transit LSP: 1 sessions
P2MP name: p2mp1, P2MP branch count: 1
To              From            State   Rt Style Labelin Labelout LSPname
10.200.86.3     10.200.86.5     Up       0  1 SE  300032        3 dalwhinnie-to-oban

LDP

LDP - label distribution protocol - намного более простой в настройке, но малофункциональный сигнальный протокол, по сравнению с RSVP.

Типы сообщений:

• Discovery: = hello multicast 224.0.0.2 на 646 порт.
• Session: после обмена hello, роутер с бОльшим ip устанавливает TCP сессию со вторым роутером с помощью session Messages.
• Advertisement: создание, изменение и удаление меток по запросу от соседей.
• Notification: error и другая информаци о соседях.

Поддерживает MD5 аутентификацию, gracefull restart.

Соседство

При включении LDP на роутере, он пытается установить соседство со всеми роутерами, на которых настроен LDP. Mulicast на UDP 646 шлют hello пакеты (раз в 5 сек, dead interval = 15 сек). Другой роутер слушает hello на этом же порту, отвечает hello, т.о. устанавливается соседство. Также происходит и поддержание соседства. Если сосед не отвечает 15 сек, то соседство рвется.

Инициатором построения туннелей выступает egress роутер. ingress роутером будет каждый роутер на сети с настроенным LDP.

Роутер (A) анонсирует свой Lo соседнему роутеру (В). Этот анонс попадает в inet.3. Т.к. B - прямой сосед А, и между ними однохоповый туннель, то анонс от А придет с меткой 3.

Роутер B начинает анонсировать Lo роутера А остальным своим соседям (C,D), чтобы те начали строить туннели до роутера А. На роутерах C,D анонс от B поместится в inet.3, с push метка. А на роутере B в таблице mpls.0 - появляется запись для туннеля с swap.

В итоге - full mesh на сети. На всех роутерах в inet.3 будет Lo роутера А.

Установление LDP LSP нельзя контролировать, они следуют кратчайшему пути по IGP.

> show ldp neighbor

Для исключения петель:

• На каждом роутере для каждого соседа создается 2 LDP database: на вход и на выход. LDP database, поступившая на вход, сравнивается с топологией IGP. В inet.3 попадает тот анонс, который пришел с того же next-hop, что указан для пришедшего Lo.
• То, что пришло и не совпало с IGP - сохраняется, но не используется. Liberal protection.

Без настроенного link-state IGP (OSPF или ISIS) LDP работать не будет! Скорость перестроения - зависит от перестроения по IGP.

После того, как установилось соседство - между роутерами устанавливается TCP сессия для обмена метками и пакетами по unicast.

> show ldp session 

Заполняется mpls.0 Заполняется inet.3.

Если роутера имеют 2 линка между собой, то установится 2 соседства. Но сессия будет установлена одна.

На сессии можно включить authentification md5.

Cisco

В Cisco дефолтное поведение немного другое. Анонсируются не только Lo, а полностью таблица маршрутизации и сразу вставляется в GRT (global routing table).

Чтобы на Juniper получить такое же поведение:

1. Пишем egress-policy: где указано что требуется анонсировать из таблицы маршрутизации по протоколу LDP. Policy применяется как egress policy к протоколу LDP.
2. На всех остальных роутерах требуется перенести inet.3 в inet.0.

Это может понадобиться только в случае, если мы делаем редистрибьюцию внешних префиксов во внутренний протокол. - чего провайдер делать не должен.

Configuration

1. Включаем family mpls:

[edit interfaces]
set ge-0/0/2.0 family mpls
set ge-0/0/3.0 family mpls
set Lo0.0 family mpls

2. Добавляем интерфейсы в protocols ldp

[edit protocols ldp]
	set interface ge-0/0/2.0
	set interface ge-0/0/3.0
	set interface Lo0.0

3. Если нужен не full-mesh в LDP домене, то настраиваются статические сессии. Можно с аутентификацией, можно без:

[edit protocols ldp]
 set session 10.200.86.7 authentication-key pass

4. На остальных роутерах в mpls домене делаем все тоже самое.

Можно проверить что будет происходить с меткой на каждом хопе LDP LSP:

show route protocol ldp 10.200.86.7
show ldp router
show route table inet.3  - если нет Lo нужного нам роутера, то проверяем есть ли Lo в inet.0 (IGP)

Среди полезных настроек, которые используются практически во всех провайдерских сетях:

• set protocols ldp track-igp-metric- использование вместо дефолтной метрики LDP метрики IGP протокола.
• set protocols ldp explicit-null - снятие метки на последнем роутер. То есть последний роутер будет слать от себя label 0. Полезно, когда на сети используется QOS.
• set protocols isis/ospf ldp-synchronization. Настраиваете в IGP протоколах. Работает только на p2p линках. Дает возможность IGP протоколу адвертайзить линк с максимальной метрикой, пока LDP туннель не простроится через этот линк. Таким образом линк не пропадет из топологии IGP, но и будет самым не выгодным для передачи трафика по нему.

[edit configuration protocols isis] 
interface ge-0/0/0.114 {
   ldp-synchronization;
   point-to-point;

• set protocols ldp deaggregate - по одному и тому же пути будет строиться несколько LSP.

По умолчанию в Jun при передачи нескольких префиксов в LDP, эти префиксы привязываются к одной метке и агрегируются в один FEC (equivalence forwarding class). Одна метка = одна LSP.

Deaggregate убивает это поведение и для каждого префикса будет биндиться своя метка (а значит и LSP).

дефолтное:

vlad@r5> show route protocol ldp 
172.30.5.1/32      *[LDP/9] 00:01:18, metric 20
                   > to 172.30.0.29 via ge-0/0/0.145, Push 300032
192.168.1.0/24     *[LDP/9] 00:01:18, metric 30
                   > to 172.30.0.29 via ge-0/0/0.145, Push 300032

set deaggregate:

vlad@r5> show route protocol ldp    
172.30.5.1/32      *[LDP/9] 00:00:14, metric 20
                   > to 172.30.0.29 via ge-0/0/0.145, Push 300272
192.168.1.0/24     *[LDP/9] 00:00:14, metric 30
                   > to 172.30.0.29 via ge-0/0/0.145, Push 300240

• по дефолту в ldp передается только адрес lo роутера. Если нужно объявить еще какие-то префиксы, то можно сделать это с помощью policy. Но нужно не забыть добавить в него lo ip!!.

[edit protocols ldp]
  egress-policy export-ldp;
[edit policy-options policy-statement export-ldp] 
term 1 {
   from {
       protocol direct;
       route-filter 192.168.1.0/24 exact;
       route-filter 172.30.5.1/32 exact;
   then accept;

> show route protocol ldp    
inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) 
192.168.1.0/24     *[LDP/9] 00:00:09, metric 20
                   > to 172.30.0.13 via ge-0/0/0.123, Push 0

Обычно не стоит вопрос о том какой протокол использовать. Оба протокола друг друга просто дополняют. У двух протоколов разные preference, поэтому BGP будет выбирать RSVP, как более приоритетный.

LDP tunneling

Комбинация LDP и RSVP. Core - RSVP + TE, доступ - LDP.

Процесс построения

• Роутер A (PE) - LDP. Egress: начинает анонсировать себя с меткой 3 в сторону B.
• Роутер B (PE) - LDP + RSVP. Анонс LoA с меткой 20 в сторону C. B: mpls.0: 20 pop -> A
• Роутер C (P) - RSVP (с LDP-tunneling). Анонс LoA с меткой 30 в сторону E. С: mpls.0: 30 swap 20 -> B.
• Роутер D (P) - между E<>C - RSVP LSP, где D - предпоследний роутер.
• Роутер E (P) - LDP + RSVP. Анонс LoA с меткой 40 в сторону F. E: mpls.0: 40 swap 30 -> C. Но C не direct connected, а доступен через туннель => идем смотреть в inet.3. E: inet.3: LoC push 100 -> D. => E: mpls.0: 40 swap 30 push 100
• Роутер F (PE) - LDP. Ingress: inet.3: LoA: push 40 -> E.

В обратную сторону строится точно также.

Когда туннель построен, между ingress (C) и egress (E) роутерами RSVP LSP установится LDP соседство! Устанавливается по UDP 646 на Lo P (берется из конфигурации туннеля), не hello механизм, но тоже работает’’.

Обязательно на P роутерах включить в LDP Lo, чтобы поднялся туннель C - E.

Схема работает только в пределах области.

При включенном LDP tunneling будут видны скрытые маршруты в inet.3

Можно использовать, когда не все устройства в сети поддерживают RSVP, но на ядре требуется TE. Также TE как таковой не требуется вообще на PE, нужно только на ядре, на P роутерах. Поэтому RSVP можно запустить только на ядре, а PE будут подцепляться по LDP.

При конфигурации может возникнуть проблема с переносом маршрутов из inet.3 в inet.0 (на PE роутерах). Решается как обычно: set protocols mpls traffic-engineering bgp-ibgp-both-ribs. Или любым другим способом.

Configuration

PE (LDP + RSVP):

[protocols mpls]
   traffic-engineering bgp-igp-both-ribs;
   label-switched-path talisker-to-oban {
      to 10.200.86.3;
      ldp-tunneling;
[protocols ldp]
   interface ge-0/0/0.70;
   interface ge-0/0/0.120;
   interface all;

С другой стороны на PE:

[protocols mpls]
   traffic-engineering bgp-igp-both-ribs;
   label-switched-path oban-to-talisker {
      to 10.200.86.4;
      ldp-tunneling;

Проверка

Между крайних PE, на которых настроено туннелирование, установили соседство между собой по LDP:

talisker> show ldp neighbor
Address            Interface          Label space ID         Hold time
10.200.86.3        lo0.0              10.200.86.3:0            42

На PE, к которому подключается CE:

macduff> show route 10.200.86.1
inet.0: 30 destinations, 40 routes (30 active, 0 holddown, 0 hidden)
10.200.86.1/32     *[LDP/9] 00:19:03, metric 1
                   > to 192.168.86.13 via ge-0/0/0.70, Push 300016
                   [OSPF/10] 00:19:03, metric 4
                   > to 192.168.86.13 via ge-0/0/0.70

talisker> show route label 300016 detail
mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
300016 (1 entry, 1 announced)
       *LDP    Preference: 9
               Next hop type: Router, Next hop index: 548
               Address: 0x934c3b8
               Next-hop reference count: 2
               Next hop: 192.168.86.33 via ge-0/0/0.120 weight 0x1, selected
               Label-switched-path talisker-to-oban
               Label operation: Swap 299776, Push 299968(top)
               Label TTL action: prop-ttl, prop-ttl(top)
               State: <Active Int NhAckRequest>
               Local AS:  1111
               Age: 19:37      Metric: 1
               Task: LDP
               Announcement bits (1): 0-KRT
               AS path: I
               Prefixes bound to route: 10.200.86.1/32

tormore> show route label 299968 detail
mpls.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
299968(S=0) (1 entry, 1 announced)
       *RSVP   Preference: 7/1
               Next hop type: Router, Next hop index: 581
               Address: 0x934d258
               Next-hop reference count: 2
               Next hop: 192.168.86.38 via ge-0/0/0.130 weight 0x1, selected
               Label-switched-path talisker-to-oban
               Label operation: Pop
               State: <Active Int AckRequest>
               Local AS:  1111
               Age: 1:09:29    Metric: 1
               Task: RSVP
               Announcement bits (1): 0-KRT
               AS path: I

oban> show route label 299776 detail
mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
299776 (1 entry, 1 announced)
       *LDP    Preference: 9
               Next hop type: Router, Next hop index: 544
               Address: 0x934c568
               Next-hop reference count: 2
               Next hop: 192.168.86.26 via ge-0/0/0.110, selected
               Label operation: Pop
               State: <Active Int>
               Local AS:  1111
               Age: 26:53      Metric: 1
               Task: LDP
               Announcement bits (1): 0-KRT
               AS path: I
               Prefixes bound to route: 10.200.86.1/32

Дополнительная информация

• Глава 2. RSVP
• Глава 1. Основы MPLS и VPN
• Traffic engineering