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

Материал из Juniper Exam Wiki
Перейти к навигации Перейти к поиску

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

При включении 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.

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

Ldp tunneling.png

  • Роутер 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

Ldp tunneling laba.png

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

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