Daniel Ginsburg (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} dbg) wrote,@ 2006-12-10 21:22:00 |
|
Безделушки (неинтересно никому, кроме отдельных маньяков)
Вопрос: Необходим ли link-state IGP, чтобы сделать MPLS TE?
Кого ни спроси, ответ не задержится ни на миллисекунду: "Да, конечно!". Да еще как на идиота посмотрят.
Разберемся?
Для чего же нужен link-state IGP, такой как OSPF или IS-IS, в MPLS TE?
В MPLS TE есть три этапа:
1) Вычисление пути для туннеля. На этом этапе решается вопрос по какому пути в сети мы хотим проложить LSP (label switched path).
2) Установка LSP. На этом этапе прокладывается туннель, здесь происходит сигнализация, раздаются метки и проч.
3) Форвардинг трафика. Когда LSP просигналился, по тоннелю можно запускать живой трафик.
Так на каких этапах нам нужен link-state протокол?
1) Вычисление пути.
Здесь link-state протокол очень в кассу. Фундаментальное свойство link-state протоколов состоит в том, они распространяют информацию о топологии сети и свойствах ее компонентов по всем узлам сети (для особо придирчивых оговоримся: в пределах области), а вычисление маршрутов происходит локально на каждом узле с помощью алгоритма SPF (shortest path first).
Благодаря так называемым TE-расширениям, link-state протокол может распространить не только информацию о наличии определенных линков и их стоимости, но и многое другое: доступную пропускную способность, "цвета" линков, дополнительные метрики и т.п. Имея эту информацию, сведенную в так называемую TED (traffic engineering database), узел может вычислять пути для своих TE-туннелей с помощью алгоритма CSPF (constrained shortest path first). Ничего особо хитрого в этом CSPF нет - за вычетом некоторых подробностей, это тот же обычный SPF, который при вычислении пути просто выкидывает линки, не удовлетворяющие заданным условиям.
Но кто сказал, что CSPF - единственный способ вычислять TE-пути? Никто не сказал. Информацию о сети можно собирать и вычислять пути можно очень разными способами. Например, это может делать наша NMS.
2) Установка LSP.
Здесь центральную роль играет протокол RSVP опять таки с соотвествующими TE-расширениями (про CR-LDP можно забыть, его похоронили). Даже если сконфигурить явно заданный путь, большинство реализаций все равно стремятся проверить его по своей TED - вдруг мы чего не того наконфигуряли, чего ж зря соседей дергать своим RSVP. Но кто сказал, что такая проверка обязательна? Никто не сказал. Ведь при RSVP-сигнализации все равно происходит admission control, т.е. никто не даст нам насигнались лишнего.
3) Форвардинг.
Когда TE-туннель установлен, надо как-то в него завернуть наш трафик. Есть ровно три способа это сделать:
* Статический маршрут. Очень просто: ip route тру-ля-ля тра-ля-ля Tunnel666 и поехали.
* Policy based routing. Опять таки просто:
* Заставить наш IGP поднапрячься. Здесь есть два подварианта: вычисления на head-end'е туннеля, и анонсирование туннеля другим узлам с тем, чтобы они приняли его во внимание в своих вычислениях. Здесь участие link-state протокола опять важно. Поскольку никаких adjacencies по TE-тоннелю не формируется и по нему никто ничего не анонсирует, в SPF встраивается специальный случай: когда SPF доходит до узела, являющегося концом (tail end) установленного туннеля, он заменяет вычисленный путь на туннель и продолжает вычисления как обычно. В результате этого трафик к tail-end'у и узлам, находящимся за ним, пойдет через тоннель.
Итого:
Необходим ли link-state protocol на этапе вычисления пути? С ним лучше, чем без него, но можно и обойтись.
Необходим ли link-state protocol на этапе установки LSP? С ним лучше, чем без него, но можно и обойтись.
Необходим ли link-state protocol на этапе использования тоннеля? С ним лучше, чем без него, но можно и обойтись.
В заключение покажем фокус. MPLS traffic engineering с EIGRP в качестве IGP. Можно было бы вообще на статике все сделать, но я поленился. Полное унижтожение IGP остается в качестве упражения читателю ;)
Ключевая фича в нашем фокусе это Verbatim Path Support. Что делает эта фича? Очень просто - она отключает сверку явно сконфигурированного TE-пути с traffic engineering database, что позволяет обойтись без нее совсем.
Вот топология и адресация нашего стенда:
Чисто для проверки того, что у нас получился настоящий MPLS, а не какое-нибудь фуфло, я сконфигурил MPLS VPN: один vrf под названием VPN1, на каждом роутере по одному лупбэку в этом vrf с адресами 10.0.x.1/32, где x - номер роутера.
Строим full mesh TE-туннелей:
R1-R2
R1-R3
R1-R2-R4
R2-R1
R2-R4
R2-R4-R3
R3-R1
R3-R4
R3-R1-R2
R4-R2
R4-R3
R4-R3-R1
Вот конфиги (немножко покоцанные для краткости):
R1:
R2:
R3:
R4:
Проверяем?
В TED пусто.
В TED пусто, а туннельчики-то вот они, стоят, как родные.
Попингаем?
Попинговали? Теперь потрейсим.
Все често - MPLS настоящий.
В заключение скажу: несмотря на то, что мы установили, что TE без link-state IGP таки бывает, такая конструкция к разворачиванию в реальной сети не рекомендуется :)
Вопрос: Необходим ли link-state IGP, чтобы сделать MPLS TE?
Кого ни спроси, ответ не задержится ни на миллисекунду: "Да, конечно!". Да еще как на идиота посмотрят.
Разберемся?
Для чего же нужен link-state IGP, такой как OSPF или IS-IS, в MPLS TE?
В MPLS TE есть три этапа:
1) Вычисление пути для туннеля. На этом этапе решается вопрос по какому пути в сети мы хотим проложить LSP (label switched path).
2) Установка LSP. На этом этапе прокладывается туннель, здесь происходит сигнализация, раздаются метки и проч.
3) Форвардинг трафика. Когда LSP просигналился, по тоннелю можно запускать живой трафик.
Так на каких этапах нам нужен link-state протокол?
1) Вычисление пути.
Здесь link-state протокол очень в кассу. Фундаментальное свойство link-state протоколов состоит в том, они распространяют информацию о топологии сети и свойствах ее компонентов по всем узлам сети (для особо придирчивых оговоримся: в пределах области), а вычисление маршрутов происходит локально на каждом узле с помощью алгоритма SPF (shortest path first).
Благодаря так называемым TE-расширениям, link-state протокол может распространить не только информацию о наличии определенных линков и их стоимости, но и многое другое: доступную пропускную способность, "цвета" линков, дополнительные метрики и т.п. Имея эту информацию, сведенную в так называемую TED (traffic engineering database), узел может вычислять пути для своих TE-туннелей с помощью алгоритма CSPF (constrained shortest path first). Ничего особо хитрого в этом CSPF нет - за вычетом некоторых подробностей, это тот же обычный SPF, который при вычислении пути просто выкидывает линки, не удовлетворяющие заданным условиям.
Но кто сказал, что CSPF - единственный способ вычислять TE-пути? Никто не сказал. Информацию о сети можно собирать и вычислять пути можно очень разными способами. Например, это может делать наша NMS.
2) Установка LSP.
Здесь центральную роль играет протокол RSVP опять таки с соотвествующими TE-расширениями (про CR-LDP можно забыть, его похоронили). Даже если сконфигурить явно заданный путь, большинство реализаций все равно стремятся проверить его по своей TED - вдруг мы чего не того наконфигуряли, чего ж зря соседей дергать своим RSVP. Но кто сказал, что такая проверка обязательна? Никто не сказал. Ведь при RSVP-сигнализации все равно происходит admission control, т.е. никто не даст нам насигнались лишнего.
3) Форвардинг.
Когда TE-туннель установлен, надо как-то в него завернуть наш трафик. Есть ровно три способа это сделать:
* Статический маршрут. Очень просто: ip route тру-ля-ля тра-ля-ля Tunnel666 и поехали.
* Policy based routing. Опять таки просто:
route-map PBR match this match that set interface Tunnel666
* Заставить наш IGP поднапрячься. Здесь есть два подварианта: вычисления на head-end'е туннеля, и анонсирование туннеля другим узлам с тем, чтобы они приняли его во внимание в своих вычислениях. Здесь участие link-state протокола опять важно. Поскольку никаких adjacencies по TE-тоннелю не формируется и по нему никто ничего не анонсирует, в SPF встраивается специальный случай: когда SPF доходит до узела, являющегося концом (tail end) установленного туннеля, он заменяет вычисленный путь на туннель и продолжает вычисления как обычно. В результате этого трафик к tail-end'у и узлам, находящимся за ним, пойдет через тоннель.
Итого:
Необходим ли link-state protocol на этапе вычисления пути? С ним лучше, чем без него, но можно и обойтись.
Необходим ли link-state protocol на этапе установки LSP? С ним лучше, чем без него, но можно и обойтись.
Необходим ли link-state protocol на этапе использования тоннеля? С ним лучше, чем без него, но можно и обойтись.
В заключение покажем фокус. MPLS traffic engineering с EIGRP в качестве IGP. Можно было бы вообще на статике все сделать, но я поленился. Полное унижтожение IGP остается в качестве упражения читателю ;)
Ключевая фича в нашем фокусе это Verbatim Path Support. Что делает эта фича? Очень просто - она отключает сверку явно сконфигурированного TE-пути с traffic engineering database, что позволяет обойтись без нее совсем.
Вот топология и адресация нашего стенда:
Чисто для проверки того, что у нас получился настоящий MPLS, а не какое-нибудь фуфло, я сконфигурил MPLS VPN: один vrf под названием VPN1, на каждом роутере по одному лупбэку в этом vrf с адресами 10.0.x.1/32, где x - номер роутера.
Строим full mesh TE-туннелей:
R1-R2
R1-R3
R1-R2-R4
R2-R1
R2-R4
R2-R4-R3
R3-R1
R3-R4
R3-R1-R2
R4-R2
R4-R3
R4-R3-R1
Вот конфиги (немножко покоцанные для краткости):
R1:
! hostname R1 ! ip vrf VPN1 rd 65534:1 route-target export 65534:1 route-target import 65534:1 ! mpls traffic-eng tunnels ! interface Tunnel2 ip unnumbered Loopback0 tunnel destination 10.0.2.0 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name R2-primary verbatim ! interface Tunnel3 ip unnumbered Loopback0 tunnel destination 10.0.3.0 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name R3-primary verbatim ! interface Tunnel4 ip unnumbered Loopback0 tunnel destination 10.0.4.0 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name R4-primary verbatim ! interface Loopback0 ip address 10.0.1.0 255.255.255.255 ! interface Loopback1 ip vrf forwarding VPN1 ip address 10.0.1.1 255.255.255.255 ! interface TenGigabitEthernet1/1 mtu 9216 ip address 10.0.12.1 255.255.255.0 load-interval 30 carrier-delay msec 0 mpls traffic-eng tunnels ! interface TenGigabitEthernet1/2 mtu 9216 ip address 10.0.13.1 255.255.255.0 load-interval 30 carrier-delay msec 0 mpls traffic-eng tunnels ! router eigrp 1 network 10.0.0.0 0.0.255.255 no auto-summary ! router bgp 65534 bgp router-id 10.0.1.0 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor rr peer-group neighbor rr remote-as 65534 neighbor rr update-source Loopback0 neighbor 10.0.2.0 peer-group rr neighbor 10.0.3.0 peer-group rr ! address-family vpnv4 neighbor rr send-community both neighbor rr next-hop-self neighbor 10.0.2.0 activate neighbor 10.0.3.0 activate exit-address-family ! address-family ipv4 vrf VPN1 redistribute connected no synchronization exit-address-family ! ip route 10.0.2.0 255.255.255.255 Tunnel2 ip route 10.0.3.0 255.255.255.255 Tunnel3 ip route 10.0.4.0 255.255.255.255 Tunnel4 ! ip explicit-path name R2-primary enable next-address 10.0.12.2 ! ip explicit-path name R3-primary enable next-address 10.0.13.3 ! ip explicit-path name R4-primary enable next-address 10.0.12.2 next-address 10.0.24.4 !
R2:
! hostname R2 ! ip vrf VPN1 rd 65534:1 route-target export 65534:1 route-target import 65534:1 ! mpls traffic-eng tunnels ! interface Tunnel1 ip unnumbered Loopback0 tunnel destination 10.0.1.0 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name R1-primary verbatim ! interface Tunnel3 ip unnumbered Loopback0 tunnel destination 10.0.3.0 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name R3-primary verbatim ! interface Tunnel4 ip unnumbered Loopback0 tunnel destination 10.0.4.0 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name R4-primary verbatim ! interface Loopback0 ip address 10.0.2.0 255.255.255.255 ! interface Loopback1 ip vrf forwarding VPN1 ip address 10.0.2.1 255.255.255.255 ! interface TenGigabitEthernet1/1 mtu 9216 ip address 10.0.24.2 255.255.255.0 load-interval 30 carrier-delay msec 0 mpls traffic-eng tunnels ! interface TenGigabitEthernet1/2 mtu 9216 ip address 10.0.12.2 255.255.255.0 load-interval 30 carrier-delay msec 0 mpls traffic-eng tunnels ! router eigrp 1 network 10.0.0.0 0.0.255.255 no auto-summary ! router bgp 65534 bgp router-id 10.0.2.0 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor rr-client peer-group neighbor rr-client remote-as 65534 no neighbor rr-client transport path-mtu-discovery neighbor rr-client update-source Loopback0 neighbor other-rr peer-group neighbor other-rr remote-as 65534 no neighbor other-rr transport path-mtu-discovery neighbor other-rr update-source Loopback0 neighbor 10.0.1.0 peer-group rr-client neighbor 10.0.3.0 peer-group other-rr neighbor 10.0.4.0 peer-group rr-client ! address-family vpnv4 neighbor rr-client send-community both neighbor rr-client route-reflector-client neighbor rr-client next-hop-self neighbor other-rr send-community both neighbor other-rr next-hop-self neighbor 10.0.1.0 activate neighbor 10.0.3.0 activate neighbor 10.0.4.0 activate exit-address-family ! address-family ipv4 vrf VPN1 redistribute connected no synchronization exit-address-family ! ip route 10.0.1.0 255.255.255.255 Tunnel1 ip route 10.0.3.0 255.255.255.255 Tunnel3 ip route 10.0.4.0 255.255.255.255 Tunnel4 ! ip explicit-path name R1-primary enable next-address 10.0.12.1 ! ip explicit-path name R3-primary enable next-address 10.0.24.4 next-address 10.0.34.3 ! ip explicit-path name R4-primary enable next-address 10.0.24.4 !
R3:
! hostname R3 ! ip vrf VPN1 rd 65534:1 route-target export 65534:1 route-target import 65534:1 ! mpls traffic-eng tunnels ! interface Tunnel1 ip unnumbered Loopback0 tunnel destination 10.0.1.0 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name R1-primary verbatim ! interface Tunnel2 ip unnumbered Loopback0 tunnel destination 10.0.2.0 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name R2-primary verbatim ! interface Tunnel4 ip unnumbered Loopback0 tunnel destination 10.0.4.0 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name R4-primary verbatim ! interface Loopback0 ip address 10.0.3.0 255.255.255.255 ! interface Loopback1 ip vrf forwarding VPN1 ip address 10.0.3.1 255.255.255.255 ! interface TenGigabitEthernet1/1 mtu 9216 ip address 10.0.13.3 255.255.255.0 load-interval 30 carrier-delay msec 0 mpls traffic-eng tunnels ! interface TenGigabitEthernet1/2 mtu 9216 ip address 10.0.34.3 255.255.255.0 load-interval 30 carrier-delay msec 0 mpls traffic-eng tunnels ! router eigrp 1 network 10.0.0.0 0.0.255.255 no auto-summary ! router bgp 65534 bgp router-id 10.0.3.0 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor rr-client peer-group neighbor rr-client remote-as 65534 no neighbor rr-client transport path-mtu-discovery neighbor rr-client update-source Loopback0 neighbor other-rr peer-group neighbor other-rr remote-as 65534 no neighbor other-rr transport path-mtu-discovery neighbor other-rr update-source Loopback0 neighbor 10.0.1.0 peer-group rr-client neighbor 10.0.2.0 peer-group other-rr neighbor 10.0.4.0 peer-group rr-client ! address-family vpnv4 neighbor rr-client send-community both neighbor rr-client route-reflector-client neighbor rr-client next-hop-self neighbor other-rr send-community both neighbor other-rr next-hop-self neighbor 10.0.1.0 activate neighbor 10.0.2.0 activate neighbor 10.0.4.0 activate exit-address-family ! address-family ipv4 vrf VPN1 redistribute connected no synchronization exit-address-family ! ip route 10.0.1.0 255.255.255.255 Tunnel1 ip route 10.0.2.0 255.255.255.255 Tunnel2 ip route 10.0.4.0 255.255.255.255 Tunnel4 ! ip explicit-path name R1-primary enable next-address 10.0.13.1 ! ip explicit-path name R2-primary enable next-address 10.0.13.1 next-address 10.0.12.2 ! ip explicit-path name R4-primary enable next-address 10.0.34.4 !
R4:
! hostname R3 ! ip vrf VPN1 rd 65534:1 route-target export 65534:1 route-target import 65534:1 ! mpls traffic-eng tunnels ! interface Tunnel1 ip unnumbered Loopback0 tunnel destination 10.0.1.0 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name R1-primary verbatim ! interface Tunnel2 ip unnumbered Loopback0 tunnel destination 10.0.2.0 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name R2-primary verbatim ! interface Tunnel3 ip unnumbered Loopback0 tunnel destination 10.0.3.0 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name R3-primary verbatim ! interface Loopback0 ip address 10.0.4.0 255.255.255.255 ! interface Loopback1 ip vrf forwarding VPN1 ip address 10.0.4.1 255.255.255.255 ! interface TenGigabitEthernet1/1 mtu 9216 ip address 10.0.34.4 255.255.255.0 load-interval 30 carrier-delay msec 0 mpls traffic-eng tunnels ! interface TenGigabitEthernet1/2 mtu 9216 ip address 10.0.24.4 255.255.255.0 load-interval 30 carrier-delay msec 0 mpls traffic-eng tunnels ! router eigrp 1 network 10.0.0.0 0.0.255.255 no auto-summary ! router bgp 65534 bgp router-id 10.0.4.0 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor rr peer-group neighbor rr remote-as 65534 no neighbor rr transport path-mtu-discovery neighbor rr update-source Loopback0 neighbor 10.0.2.0 peer-group rr neighbor 10.0.3.0 peer-group rr ! address-family vpnv4 neighbor rr send-community both neighbor rr next-hop-self neighbor 10.0.2.0 activate neighbor 10.0.3.0 activate exit-address-family ! address-family ipv4 vrf VPN1 redistribute connected no synchronization exit-address-family ! ip route 10.0.1.0 255.255.255.255 Tunnel1 ip route 10.0.2.0 255.255.255.255 Tunnel2 ip route 10.0.3.0 255.255.255.255 Tunnel3 ! ip explicit-path name R1-primary enable next-address 10.0.34.3 next-address 10.0.13.1 ! ip explicit-path name R2-primary enable next-address 10.0.24.2 ! ip explicit-path name R3-primary enable next-address 10.0.34.3 !
Проверяем?
R1#show mpls traffic-eng topology Signalling error holddown: 10 sec Global Link Generation 0 R2#show mpls traffic-eng topology Signalling error holddown: 10 sec Global Link Generation 0 R3#show mpls traffic-eng topology Signalling error holddown: 10 sec Global Link Generation 0 R4#show mpls traffic-eng topology Signalling error holddown: 10 sec Global Link Generation 0
В TED пусто.
R1#show mpls traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 3273 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 273 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
R1_t2 10.0.2.0 - Te1/1 up/up
R1_t3 10.0.3.0 - Te1/2 up/up
R1_t4 10.0.4.0 - Te1/1 up/up
R2_t1 10.0.1.0 Te1/1 - up/up
R3_t1 10.0.1.0 Te1/2 - up/up
R3_t2 10.0.2.0 Te1/2 Te1/1 up/up
R4_t1 10.0.1.0 Te1/2 - up/up
Displayed 3 (of 3) heads, 1 (of 1) midpoints, 3 (of 3) tails
R2#show mpls traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 1092 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 192 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
R2_t1 10.0.1.0 - Te1/2 up/up
R2_t3 10.0.3.0 - Te1/1 up/up
R2_t4 10.0.4.0 - Te1/1 up/up
R1_t2 10.0.2.0 Te1/2 - up/up
R1_t4 10.0.4.0 Te1/2 Te1/1 up/up
R3_t2 10.0.2.0 Te1/2 - up/up
R4_t2 10.0.2.0 Te1/1 - up/up
Displayed 3 (of 3) heads, 1 (of 1) midpoints, 3 (of 3) tails
R3#show mpls traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 1879 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 79 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
R3_t1 10.0.1.0 - Te1/1 up/up
R3_t2 10.0.2.0 - Te1/1 up/up
R3_t4 10.0.4.0 - Te1/2 up/up
R1_t3 10.0.3.0 Te1/1 - up/up
R2_t3 10.0.3.0 Te1/2 - up/up
R4_t1 10.0.1.0 Te1/2 Te1/1 up/up
R4_t3 10.0.3.0 Te1/2 - up/up
Displayed 3 (of 3) heads, 1 (of 1) midpoints, 3 (of 3) tails
R4#show mpls traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 2542 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 142 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
R4_t1 10.0.1.0 - Te1/1 up/up
R4_t2 10.0.2.0 - Te1/2 up/up
R4_t3 10.0.3.0 - Te1/1 up/up
R1_t4 10.0.4.0 Te1/2 - up/up
R2_t3 10.0.3.0 Te1/2 Te1/1 up/up
R2_t4 10.0.4.0 Te1/2 - up/up
R3_t4 10.0.4.0 Te1/1 - up/up
Displayed 3 (of 3) heads, 1 (of 1) midpoints, 3 (of 3) tailsВ TED пусто, а туннельчики-то вот они, стоят, как родные.
Попингаем?
R1#ping vrf VPN1 10.0.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms R1#ping vrf VPN1 10.0.3.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.3.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms R1#ping vrf VPN1 10.0.4.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.4.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms R2#ping vrf VPN1 10.0.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms R2#ping vrf VPN1 10.0.3.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.3.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms R2#ping vrf VPN1 10.0.4.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.4.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms R3#ping vrf VPN1 10.0.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms R3#ping vrf VPN1 10.0.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms R3#ping vrf VPN1 10.0.4.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.4.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms R4#ping vrf VPN1 10.0.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms R4#ping vrf VPN1 10.0.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms R4#ping vrf VPN1 10.0.3.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.3.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Попинговали? Теперь потрейсим.
R1#trace vrf VPN1 10.0.4.1 Type escape sequence to abort. Tracing the route to 10.0.4.1 1 10.0.12.2 [MPLS: Labels 22/16 Exp 0] 4 msec 0 msec 0 msec 2 10.0.4.1 0 msec * 0 msec R2#trace vrf VPN1 10.0.3.1 Type escape sequence to abort. Tracing the route to 10.0.3.1 1 10.0.24.4 [MPLS: Labels 22/16 Exp 0] 0 msec 0 msec 0 msec 2 10.0.3.1 0 msec * 0 msec R3#trace vrf VPN1 10.0.2.1 Type escape sequence to abort. Tracing the route to 10.0.2.1 1 10.0.13.1 [MPLS: Labels 22/16 Exp 0] 0 msec 0 msec 0 msec 2 10.0.2.1 0 msec * 0 msec R4#trace vrf VPN1 10.0.1.1 Type escape sequence to abort. Tracing the route to 10.0.1.1 1 10.0.34.3 [MPLS: Labels 22/16 Exp 0] 4 msec 0 msec 0 msec 2 10.0.1.1 0 msec * 0 msec
Все често - MPLS настоящий.
В заключение скажу: несмотря на то, что мы установили, что TE без link-state IGP таки бывает, такая конструкция к разворачиванию в реальной сети не рекомендуется :)
