[hub3]

Добрый день , коллеги .

Помогите разобратся в ситуации .

Собрана следующая схема

 

Конфигурация со стороны M7i

 

 

show configuration interfaces ge-1/3/0

flexible-vlan-tagging;

mtu 9000;

encapsulation flexible-ethernet-services;

unit 200 {

description "-= LSP1 SAKI =-";

vlan-id 200;

family inet {

address 10.0.2.0/31;

}

family mpls {

mtu 1538;

}

}

unit 300 {

description "-= LSP2 SAKI =-";

vlan-id 300;

family inet {

address 10.0.2.2/31;

}

family mpls {

mtu 1538;

}

}

 

 

show configuration protocols rsvp

load-balance bandwidth;

traceoptions {

file rsvp.log size 1m files 3;

}

interface ge-1/3/0.200;

interface ge-1/3/0.300;

interface lo0.0;

 

show configuration protocols mpls

path-mtu {

allow-fragmentation;

rsvp mtu-signaling;

}

traceoptions {

file mpls.log size 1m files 3;

}

label-switched-path Simf2Saki {

to 193.27.243.10;

bandwidth 100m;

priority 2 2;

primary Simf2Saki;

}

label-switched-path Simf2SakiB {

to 193.27.243.10;

bandwidth 100m;

priority 4 4;

primary Simf2SakiB;

}

path Simf2Saki {

10.0.2.1;

}

path Simf2SakiB {

10.0.2.3;

}

interface ge-1/3/0.200;

interface ge-1/3/0.300;

interface lo0.0;

 

traceoptions {

file ospf.log size 1m files 3;

}

traffic-engineering;

export EXPORT-TO-OSPF;

area 0.0.0.0 {

interface ge-0/0/0.803;

}

area 0.0.0.10 {

stub default-metric 10 no-summaries;

interface ge-1/3/0.300 {

interface-type p2p;

}

interface ge-1/3/0.200 {

interface-type p2p;

}

interface lo0.0;

}

 

Конфигурация со стороны ME

 

interface Loopback0

ip address 193.27.243.10 255.255.255.255

ip ospf 1 area 10

!

interface Tunnel0

description Saki2Simf

ip unnumbered Loopback0

load-interval 30

mpls traffic-eng tunnels

tunnel mode mpls traffic-eng

tunnel destination 195.3.244.10

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 2 2

tunnel mpls traffic-eng bandwidth 1000000

tunnel mpls traffic-eng path-option 1 dynamic bandwidth 1000000

tunnel mpls traffic-eng path-option 5 explicit name Saki2Simf bandwidth 1000000

tunnel mpls traffic-eng record-route

tunnel mpls traffic-eng path-selection metric te

tunnel mpls traffic-eng auto-bw frequency 600

tunnel mpls traffic-eng load-share 1

!

interface Tunnel1

description Saki2SimfB

ip unnumbered Loopback0

load-interval 30

tunnel mode mpls traffic-eng

tunnel destination 195.3.244.10

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 2 2

tunnel mpls traffic-eng bandwidth 100000

tunnel mpls traffic-eng path-option 1 dynamic

tunnel mpls traffic-eng path-option 5 explicit name Saki2SimfB bandwidth 100000

tunnel mpls traffic-eng record-route

tunnel mpls traffic-eng path-selection metric te

tunnel mpls traffic-eng auto-bw frequency 600

tunnel mpls traffic-eng load-share 1

!

 

interface Vlan200

description -= LSP1 =-

mtu 8978

ip address 10.0.2.1 255.255.255.254

ip ospf network point-to-point

ip ospf mtu-ignore

ip ospf 1 area 10

load-interval 30

carrier-delay msec 0

mpls ip

mpls mtu 2048

mpls traffic-eng tunnels

mpls traffic-eng administrative-weight 10

ip rsvp bandwidth 100000

ip rsvp signalling hello

!

interface Vlan300

description -= LSP2 =-

mtu 8978

ip address 10.0.2.3 255.255.255.254

ip ospf network point-to-point

ip ospf mtu-ignore

ip ospf 1 area 10

load-interval 30

carrier-delay msec 0

mpls ip

mpls mtu 2048

mpls traffic-eng tunnels

mpls traffic-eng administrative-weight 100

ip rsvp bandwidth 1000000

ip rsvp signalling hello

 

router ospf 1

router-id 193.27.243.10

area 10 stub

redistribute connected

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 10

!

Собственно вопрос

LSP поднимаются и со стороны Juniper и со стороны ME , проблема в том что трафик со стороны ME в сторону Juniper не попадает в тунель а со строны Juniper в сторону ME бежит по тунелю

 

show mpls lsp statistics

Ingress LSP: 2 sessions

To From State Packets Bytes LSPname

193.27.243.10 195.3.244.10 Up 1212 68322 Simf2Saki

193.27.243.10 195.3.244.10 Up 20561 30735751 Simf2SakiB

Total 2 displayed, Up 2, Down 0

 

Egress LSP: 2 sessions

To From State Packets Bytes LSPname

195.3.244.10 193.27.243.10 Up NA NA Saki2Simf

195.3.244.10 193.27.243.10 Up NA NA Saki2SimfB

Total 2 displayed, Up 2, Down 0

 

 

show mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

17 [T] Pop Label 195.3.244.10/32 0 Tu0 point2point

[T] Pop Label 195.3.244.10/32 0 Tu1 point2point

807 No Label l2ckt(1) 52110 Vl50 point2point

 

 

 

show ip cef

Prefix Next Hop Interface

0.0.0.0/0 195.3.244.10 Tunnel0

195.3.244.10 Tunnel1

[fomka31ru]

насколько помню цыску, варианта 2 - либо статик -> тунель, либо автороут инсталл

 

PS не люблю я эту циску

Edited February 16, 2015 by fomka31ru

[applx]

Добрый день , коллеги .

Помогите разобратся в ситуации .

Собрана следующая схема

 

Конфигурация со стороны M7i

 

 

show configuration interfaces ge-1/3/0

flexible-vlan-tagging;

mtu 9000;

encapsulation flexible-ethernet-services;

unit 200 {

description "-= LSP1 SAKI =-";

vlan-id 200;

family inet {

address 10.0.2.0/31;

}

family mpls {

mtu 1538;

}

}

unit 300 {

description "-= LSP2 SAKI =-";

vlan-id 300;

family inet {

address 10.0.2.2/31;

}

family mpls {

mtu 1538;

}

}

 

 

show configuration protocols rsvp

load-balance bandwidth;

traceoptions {

file rsvp.log size 1m files 3;

}

interface ge-1/3/0.200;

interface ge-1/3/0.300;

interface lo0.0;

 

show configuration protocols mpls

path-mtu {

allow-fragmentation;

rsvp mtu-signaling;

}

traceoptions {

file mpls.log size 1m files 3;

}

label-switched-path Simf2Saki {

to 193.27.243.10;

bandwidth 100m;

priority 2 2;

primary Simf2Saki;

}

label-switched-path Simf2SakiB {

to 193.27.243.10;

bandwidth 100m;

priority 4 4;

primary Simf2SakiB;

}

path Simf2Saki {

10.0.2.1;

}

path Simf2SakiB {

10.0.2.3;

}

interface ge-1/3/0.200;

interface ge-1/3/0.300;

interface lo0.0;

 

traceoptions {

file ospf.log size 1m files 3;

}

traffic-engineering;

export EXPORT-TO-OSPF;

area 0.0.0.0 {

interface ge-0/0/0.803;

}

area 0.0.0.10 {

stub default-metric 10 no-summaries;

interface ge-1/3/0.300 {

interface-type p2p;

}

interface ge-1/3/0.200 {

interface-type p2p;

}

interface lo0.0;

}

 

Конфигурация со стороны ME

 

interface Loopback0

ip address 193.27.243.10 255.255.255.255

ip ospf 1 area 10

!

interface Tunnel0

description Saki2Simf

ip unnumbered Loopback0

load-interval 30

mpls traffic-eng tunnels

tunnel mode mpls traffic-eng

tunnel destination 195.3.244.10

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 2 2

tunnel mpls traffic-eng bandwidth 1000000

tunnel mpls traffic-eng path-option 1 dynamic bandwidth 1000000

tunnel mpls traffic-eng path-option 5 explicit name Saki2Simf bandwidth 1000000

tunnel mpls traffic-eng record-route

tunnel mpls traffic-eng path-selection metric te

tunnel mpls traffic-eng auto-bw frequency 600

tunnel mpls traffic-eng load-share 1

!

interface Tunnel1

description Saki2SimfB

ip unnumbered Loopback0

load-interval 30

tunnel mode mpls traffic-eng

tunnel destination 195.3.244.10

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 2 2

tunnel mpls traffic-eng bandwidth 100000

tunnel mpls traffic-eng path-option 1 dynamic

tunnel mpls traffic-eng path-option 5 explicit name Saki2SimfB bandwidth 100000

tunnel mpls traffic-eng record-route

tunnel mpls traffic-eng path-selection metric te

tunnel mpls traffic-eng auto-bw frequency 600

tunnel mpls traffic-eng load-share 1

!

 

interface Vlan200

description -= LSP1 =-

mtu 8978

ip address 10.0.2.1 255.255.255.254

ip ospf network point-to-point

ip ospf mtu-ignore

ip ospf 1 area 10

load-interval 30

carrier-delay msec 0

mpls ip

mpls mtu 2048

mpls traffic-eng tunnels

mpls traffic-eng administrative-weight 10

ip rsvp bandwidth 100000

ip rsvp signalling hello

!

interface Vlan300

description -= LSP2 =-

mtu 8978

ip address 10.0.2.3 255.255.255.254

ip ospf network point-to-point

ip ospf mtu-ignore

ip ospf 1 area 10

load-interval 30

carrier-delay msec 0

mpls ip

mpls mtu 2048

mpls traffic-eng tunnels

mpls traffic-eng administrative-weight 100

ip rsvp bandwidth 1000000

ip rsvp signalling hello

 

router ospf 1

router-id 193.27.243.10

area 10 stub

redistribute connected

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 10

!

Собственно вопрос

LSP поднимаются и со стороны Juniper и со стороны ME , проблема в том что трафик со стороны ME в сторону Juniper не попадает в тунель а со строны Juniper в сторону ME бежит по тунелю

 

show mpls lsp statistics

Ingress LSP: 2 sessions

To From State Packets Bytes LSPname

193.27.243.10 195.3.244.10 Up 1212 68322 Simf2Saki

193.27.243.10 195.3.244.10 Up 20561 30735751 Simf2SakiB

Total 2 displayed, Up 2, Down 0

 

Egress LSP: 2 sessions

To From State Packets Bytes LSPname

195.3.244.10 193.27.243.10 Up NA NA Saki2Simf

195.3.244.10 193.27.243.10 Up NA NA Saki2SimfB

Total 2 displayed, Up 2, Down 0

 

 

show mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

17 [T] Pop Label 195.3.244.10/32 0 Tu0 point2point

[T] Pop Label 195.3.244.10/32 0 Tu1 point2point

807 No Label l2ckt(1) 52110 Vl50 point2point

 

 

 

show ip cef

Prefix Next Hop Interface

0.0.0.0/0 195.3.244.10 Tunnel0

195.3.244.10 Tunnel1

 

 

 

а вы уверены в том что MPLS TE пашет с OSPF stub ;)

Edited February 16, 2015 by applx

[hub3]

а вы уверены в том что MPLS TE пашет с OSPF stub ;)

Абсолютно

[dazgluk]

Команда

tunnel mpls traffic-eng autoroute announce

засовывает в OSPF, adjastency до 195.3.244.10 сквозь ваши туннели, OSPF кост этих adjastency, равен наименьшему OSPF косту по реальным линкам. Соответственно в текущем виде, у вас должен получиться equal-cost multipath по трем LSP, нормальному LDPшному, и двумя туннельными. Чтобы это изменить нужно сделать так, чтобы OSPF cost анонсируемых туннелей был меньше чем реальный OSPFвный кост, делается это например так:

tunnel mpls traffic-eng autoroute metric relaitve -1

Возможно конечно, вы изменили это дефолтное поведение командами

tunnel mpls traffic-eng path-selection metric te
mpls traffic-eng administrative-weight 100

.

[hub3]

Команда

tunnel mpls traffic-eng autoroute announce

засовывает в OSPF, adjastency до 195.3.244.10 сквозь ваши туннели, OSPF кост этих adjastency, равен наименьшему OSPF косту по реальным линкам. Соответственно в текущем виде, у вас должен получиться equal-cost multipath по трем LSP, нормальному LDPшному, и двумя туннельными. Чтобы это изменить нужно сделать так, чтобы OSPF cost анонсируемых туннелей был меньше чем реальный OSPFвный кост, делается это например так:

tunnel mpls traffic-eng autoroute metric relaitve -1

Возможно конечно, вы изменили это дефолтное поведение командами

tunnel mpls traffic-eng path-selection metric te
mpls traffic-eng administrative-weight 100

.

Изменил

mpls traffic-eng administrative-weight - заменяем метрику IGP

tunnel mpls traffic-eng path-selection metric te - используем метрику administrative-weight при выборе туннеля

 

Но проблема в том , что трафик бежит по raw ip и никаким образом использовать lsp не хочет .

[dazgluk]

Тогда смотрите sh ip ospf database, с какой метрикой анонсируется маршрут через TE туннель, с какой - через raw ip.

Так или иначе autoroute annaunce всего лишь запихивает полученный MPLS TE туннель в OSPF database

[nnm]

Какой трафик Вы пытаетесь передать в тоннель и почему Вы думаете, что он туда не идет?

[hub3]

Какой трафик Вы пытаетесь передать в тоннель и почему Вы думаете, что он туда не идет?

Любой ipv4 , где destanations any , те все что уходит в default gateway согласно

0.0.0.0/0 195.3.244.10 Tunnel0

195.3.244.10 Tunnel1

Считаю что не идет , потому что я его не вижу на Juniper

show mpls lsp statistics

 

Egress LSP: 2 sessions

To From State Packets Bytes LSPname

195.3.244.10 193.27.243.10 Up NA NA Saki2Simf

195.3.244.10 193.27.243.10 Up NA NA Saki2SimfB

Total 2 displayed, Up 2, Down 0

 

Я его не вижу на ME36

show mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

17 [T] Pop Label 195.3.244.10/32 0 Tu0 point2point

[T] Pop Label 195.3.244.10/32 0 Tu1 point2point

807 No Label l2ckt(1) 52110 Vl50 point2point

[nnm]

На оборудовании Cisco и Juniper по умолчанию включен PHP. Т.е. tail-end маршрутизатор для LSP анонсирует для него implicit null метку. И на последнем хопе в LSP метка не используется. По этой причине egress маршрутизатор не может идентифицировать входящий трафик, как трафик, пришедший из LSP. Именно поэтому в статистике Juniper-а стоит NA.

Командочка show mpls forwarding-table показывает статистику про трафик, который был скоммутирован по меткам. Т.е. чтобы там не было нулей устройство должно делать MPLS транзит. У Вас оно скорее всего не так.

Посмотрите лучше на интерфейсную статистику: show int tun1 Не знаю, как на ME, но на 76 и программных оно правду показывало.

Edited February 18, 2015 by nnm

[hub3]

Посмотрите лучше на интерфейсную статистику: show int tun1 Не знаю, как на ME, но на 76 и программных оно правду показывало.

 

MPLS коммутации по дороге нет , Juniper и ME включены "друг в друга" 2 вланами растянутыми по физике двух разных транспортных опрераторов .

 

Насколько я понимаю видимость Juniper c ME через тунель есть

 

 

ping mpls ipv4 195.3.244.10/32

 

 

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Total Time Elapsed 8 ms

 

show interfaces tunnel 1 summary

 

*: interface is up

IHQ: pkts in input hold queue IQD: pkts dropped from input queue

OHQ: pkts in output hold queue OQD: pkts dropped from output queue

RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec)

TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec)

TRTL: throttle count

 

Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL

-----------------------------------------------------------------------------------------------------------------

* Tunnel1 0 0 0 0 0 0 0 0 0

 

 

#show interfaces tunnel 0 summary

 

*: interface is up

IHQ: pkts in input hold queue IQD: pkts dropped from input queue

OHQ: pkts in output hold queue OQD: pkts dropped from output queue

RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec)

TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec)

TRTL: throttle count

 

Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL

-----------------------------------------------------------------------------------------------------------------

* Tunnel0 0 0 0 0 0 0 0 0 0

Edited February 20, 2015 by hub3

[nnm]

Насколько я понимаю видимость Juniper c ME через тунель есть

Возможно :)

 

ping mpls ipv4 195.3.244.10/32

 

Только проверяется это другой командой. Суффикс ipv4 значит, что Вы хотите использовать LDP FEC. Чтобы послать MPLS пинг в тоннель нужно писать что-то вроде tunnel-te <имя тоннеля>

Подробности вот здесь: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mpls/command/mp-cr-book/mp-m4.html#wp1468850429

[hub3]

Чтобы послать MPLS пинг в тоннель нужно писать что-то вроде tunnel-te <имя тоннеля>

ping mpls traffic-eng tunnel 0 verbose

 

Type escape sequence to abort.

! size 100, reply addr 195.3.244.10, return code 3

! size 100, reply addr 195.3.244.10, return code 3

! size 100, reply addr 195.3.244.10, return code 3

! size 100, reply addr 195.3.244.10, return code 3

! size 100, reply addr 195.3.244.10, return code 3

 

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

Total Time Elapsed 8 ms

 

 

ping mpls traffic-eng tunnel 1 verbose

 

Type escape sequence to abort.

! size 100, reply addr 195.3.244.10, return code 3

! size 100, reply addr 195.3.244.10, return code 3

! size 100, reply addr 195.3.244.10, return code 3

! size 100, reply addr 195.3.244.10, return code 3

! size 100, reply addr 195.3.244.10, return code 3

 

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

Total Time Elapsed 4 ms

 

[rdntw]

Читаю очередную статью про RSVP-TE, в 100й раз повторяется что для определенного типа трафика мы можем организовать защищенный канал, предоставить ему QoS, проложить через определённые узлы.

 

Но как это достигается когда у нас, например, между двумя PE просигнализирована одна RSVP LSP и есть два клиента которые купили допустим L3VPN на этой паре PE, причем трафик только одного нужно отправить "оптимальным" путем по дорогому линку к примеру. Ведь нужно как-то промаппить этот VPN к защищенному LSP, а другой отправить по обычному.

 

 

В Juniper есть политика в forwarding table на export где такое возможно, но как мне кажется это не best-pracice. а в циске есть что-то подобное?

И вообще правильно ли я понял логику...

[fomka31ru]

1. Можно использовать difserv-te. Но я чесно не видел, чтобы SP использовали эту схему

2. Использовать на джуне экспопт на fib это нормальная практика.

[rdntw]

1. Можно использовать difserv-te. Но я чесно не видел, чтобы SP использовали эту схему

почему ж везде тыкают в эту фичу...

2. Использовать на джуне экспопт на fib это нормальная практика.

 

спасибо. а в последнем терме нужно писать " then load balance per-packet" ?

[fomka31ru]

спасибо. а в последнем терме нужно писать " then load balance per-packet" ?

 

А это смотря чего добиваетесь

[rdntw]

А это смотря чего добиваетесь

ну это необходимо для FRR как я понял. Чтобы в FIB находилось 2 nh.

[g3fox]

Читаю очередную статью про RSVP-TE, в 100й раз повторяется что для определенного типа трафика мы можем организовать защищенный канал, предоставить ему QoS, проложить через определённые узлы.

 

Но как это достигается когда у нас, например, между двумя PE просигнализирована одна RSVP LSP и есть два клиента которые купили допустим L3VPN на этой паре PE, причем трафик только одного нужно отправить "оптимальным" путем по дорогому линку к примеру. Ведь нужно как-то промаппить этот VPN к защищенному LSP, а другой отправить по обычному.

 

 

В Juniper есть политика в forwarding table на export где такое возможно, но как мне кажется это не best-pracice. а в циске есть что-то подобное?

И вообще правильно ли я понял логику...

 

В MPLS и TE не силён, но по-идее статически VPN-ы можно прибить к тоннелям вот так. Оно?

[rdntw]

В MPLS и TE не силён, но по-идее статически VPN-ы можно прибить к тоннелям вот так. Оно?

в принципе да, но думал что это фича более распространена и используема.

[helpdesk]

Читаю очередную статью про RSVP-TE, в 100й раз повторяется что для определенного типа трафика мы можем организовать защищенный канал, предоставить ему QoS, проложить через определённые узлы.

 

Но как это достигается когда у нас, например, между двумя PE просигнализирована одна RSVP LSP и есть два клиента которые купили допустим L3VPN на этой паре PE, причем трафик только одного нужно отправить "оптимальным" путем по дорогому линку к примеру. Ведь нужно как-то промаппить этот VPN к защищенному LSP, а другой отправить по обычному.

 

 

В Juniper есть политика в forwarding table на export где такое возможно, но как мне кажется это не best-pracice. а в циске есть что-то подобное?

И вообще правильно ли я понял логику...

 

В MPLS и TE не силён, но по-идее статически VPN-ы можно прибить к тоннелям вот так. Оно?

 

чет бред в статье:

 

LDP Adjacency over MPLS TE:

 

Since LDP was enabled on MPLS TE tunnels, LDP forms adjacency over TE tunnels. This is important for label exchange for Loopback prefixes 11.2.2.2/32 and 22.2.2.2/32 on PE3 router, and 11.1.1.1/32 and 22.1.1.1/32 on PE1 router

 

Зачем включать mpls ip на туннеле в данной топологии?

[zstas]

Читаю очередную статью про RSVP-TE, в 100й раз повторяется что для определенного типа трафика мы можем организовать защищенный канал, предоставить ему QoS, проложить через определённые узлы.

 

Но как это достигается когда у нас, например, между двумя PE просигнализирована одна RSVP LSP и есть два клиента которые купили допустим L3VPN на этой паре PE, причем трафик только одного нужно отправить "оптимальным" путем по дорогому линку к примеру. Ведь нужно как-то промаппить этот VPN к защищенному LSP, а другой отправить по обычному.

 

 

В Juniper есть политика в forwarding table на export где такое возможно, но как мне кажется это не best-pracice. а в циске есть что-то подобное?

И вообще правильно ли я понял логику...

 

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-3/mpls/configuration/guide/b_mpls_cg43xasr9k/b_mpls_cg43asr9k_chapter_0100.html#con_1325561

[g3fox]

Читаю очередную статью про RSVP-TE, в 100й раз повторяется что для определенного типа трафика мы можем организовать защищенный канал, предоставить ему QoS, проложить через определённые узлы.

 

Но как это достигается когда у нас, например, между двумя PE просигнализирована одна RSVP LSP и есть два клиента которые купили допустим L3VPN на этой паре PE, причем трафик только одного нужно отправить "оптимальным" путем по дорогому линку к примеру. Ведь нужно как-то промаппить этот VPN к защищенному LSP, а другой отправить по обычному.

 

 

В Juniper есть политика в forwarding table на export где такое возможно, но как мне кажется это не best-pracice. а в циске есть что-то подобное?

И вообще правильно ли я понял логику...

 

В MPLS и TE не силён, но по-идее статически VPN-ы можно прибить к тоннелям вот так. Оно?

 

чет бред в статье:

 

LDP Adjacency over MPLS TE:

 

Since LDP was enabled on MPLS TE tunnels, LDP forms adjacency over TE tunnels. This is important for label exchange for Loopback prefixes 11.2.2.2/32 and 22.2.2.2/32 on PE3 router, and 11.1.1.1/32 and 22.1.1.1/32 on PE1 router

 

Зачем включать mpls ip на туннеле в данной топологии?

VPN-ы прибиты к лупам. Эти-же лупы в кач-ве unnambered ифейсов для TE. В кач-ве BGP-NH для впн-ов используются адреса этих лупов.

То есть ими нужно обменяться чтобы построился FEC через тоннель.

Вроде так?

(повторюсь: в MPLS не силён)

[helpdesk]

Нет, не так. ТЕ туннель - односторонний.

mpls ip внутри тоннеля нужен в другом случае с другой топологией.

[g3fox]

Нет, не так. ТЕ туннель - односторонний.

mpls ip внутри тоннеля нужен в другом случае с другой топологией.

 

Да, действительно. Я начал думать об одном, а в итоге пришёл к чему-то совершенно постороннему.

Я почему-то подумал, что LSP будет строиться поверх тоннеля, рассмотрев его как обычный тоннель.