Jump to content
Калькуляторы

MPLS TE MPLS TE между M7i и ME-3600X-24FS-M

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

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

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

 

Конфигурация со стороны 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

shema555.GIF

Share this post


Link to post
Share on other sites

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

 

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

Edited by fomka31ru

Share this post


Link to post
Share on other sites

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

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

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

 

Конфигурация со стороны 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 by applx

Share this post


Link to post
Share on other sites
а вы уверены в том что MPLS TE пашет с OSPF stub ;)

Абсолютно

Share this post


Link to post
Share on other sites

Команда

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

.

Share this post


Link to post
Share on other sites

Команда

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 не хочет .

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Какой трафик Вы пытаетесь передать в тоннель и почему Вы думаете, что он туда не идет?

Любой 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

Share this post


Link to post
Share on other sites

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

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

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

Edited by nnm

Share this post


Link to post
Share on other sites
Посмотрите лучше на интерфейсную статистику: 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 by hub3

Share this post


Link to post
Share on other sites

Насколько я понимаю видимость 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

Share this post


Link to post
Share on other sites
Чтобы послать 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

 

Share this post


Link to post
Share on other sites

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

 

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

 

 

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

Share this post


Link to post
Share on other sites
спасибо. а в последнем терме нужно писать " then load balance per-packet" ?

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

 

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Читаю очередную статью про 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 на туннеле в данной топологии?

Share this post


Link to post
Share on other sites

Читаю очередную статью про 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

Share this post


Link to post
Share on other sites

Читаю очередную статью про 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 не силён)

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this