Вопрос: Необходим ли 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 таки бывает, такая конструкция к разворачиванию в реальной сети не рекомендуется :)
This entry was originally posted in my livejournal
В 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 таки бывает, такая конструкция к разворачиванию в реальной сети не рекомендуется :)
This entry was originally posted in my livejournal
