Static LSP

Схема сети

Прежде всего можно настроить Static LSP. Это позволит понят как работает коммутация по меткам. Метод похож на статическую маршрутизацию. Мы просто указываем что нам нужно сделать с меткой (Push/Pop/Swap) и куда направить трафик.

Как пример, свяжем роутер RT.MSK.M34 и RT.SPB.LNX. Стоит помнить, что маршрут в данном случае придётся строить и в одну и в другую сторону. Минусы данного способа ясны. Из плюсов: Можно строить путь по любому пути.

Ради примера построим следующий путь:

RT.MSK.M34 <-> RT.SPB.STL <-> RT.SPB.LNX
RT.SPB.LNX <-> RT.SPB.OBV <-> RT.MSK.M8 <-> RT.MSK.M34

Путь RT.MSK.M34 <-> RT.SPB.LNX будет выглядеть так:

RT.MSK.M34

[e-mail].M34# show | compare 
[edit interfaces ge-0/0/0 unit 0] ##Включаем обработку MPLS-трафика на интерфейсах
+      family mpls;
[edit interfaces ge-0/0/3 unit 0]
+      family mpls;
[edit interfaces lo0 unit 0]
+      family mpls;
[edit protocols]
+   mpls {
+       static-label-switched-path M34-LNX { ##Указываем имя для статического LSR
+           ingress { ##Говорим, что это Ingress-LSR
+               next-hop 10.0.0.1; ##Указываем Next-Hop
+               to 192.168.0.8; ##Указываем FEC
+               push 1000001; ##Указываем, что для этого FEC мы добавляем метку
+           }                 ##с номером 1000001
+       }
+       interface all; ##Разрешаем работу протокола на всех интерфейсах
+   }

RT.SPB.STL

[e-mail]# show | compare 
[edit interfaces ge-0/0/3 unit 0]
+      family mpls;
[edit interfaces ge-0/0/4 unit 0]
+      family mpls;
[edit protocols]
+   mpls {
+       static-label-switched-path M34-LNX {
+           transit 1000001 {
+               next-hop 10.0.0.9;
+               pop;
+           }
+       }
+       interface all;
+   }

RT.SPB.LNX

+  protocols {
+      mpls {
+          interface all;
+      }
+  }
+  interfaces {
+      ge-0/0/2 {
+          unit 0 {    
+              family mpls;                
+          }
+      }
+      ge-0/0/4 {
+          unit 0 {    
+              family mpls;
+          }
+      }
+      lo0 {
+          unit 0 {
+              family mpls;
+          }
+      }
+  }

Тут мы навешиваем метку, передаём на RT.SPB.STL пакет, но на нём уже можно снимать метку, так как нет смысла её обрабатывать на Eggress Router.

Теперь отключим на M34 и посмотрим таблицу inet.3:

[e-mail].M34# show | compare 
[edit protocols]
!    inactive: isis { ... }

[e-mail].M34# run show route table inet.3             

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.0.8/32     *[MPLS/6/1] 00:15:53, metric 0
                    > to 10.0.0.1 via ge-0/0/3.0, Push 1000001

Как видим, у нас есть маршрут через MPLS. Однако, чтобы пустить трафик по статическому пути, нам нужно либо устроить Route-Leaking из таблицы inet.3 в inet.0, либо прописать на Ingress-роутере статический маршрут:

[e-mail].M34# show | compare 
[edit routing-options]
+   static {
+       route 192.168.0.8/32 {
+           static-lsp-next-hop M34-LNX;
+       }
+   }

[e-mail].M34# run show route 192.168.0.8/32 

inet.0: 28 destinations, 29 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.0.8/32     *[Static/5] 00:00:20
                    > to 10.0.0.1 via ge-0/0/3.0, Push 1000001
                    [IS-IS/18] 01:12:06, metric 20
                    > to 10.0.0.1 via ge-0/0/3.0

[e-mail]# show | compare 
[edit routing-options]
+   static {
+       route 192.168.0.1/32 {
+           static-lsp-next-hop LNX-M34;
+       }
+   }

[e-mail]# run show route 192.168.0.1/32 

inet.0: 28 destinations, 29 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.0.1/32     *[Static/5] 00:00:09
                    > to 10.0.0.22 via ge-0/0/2.0, Push 1000005
                    [IS-IS/18] 00:00:09, metric 20
                    > to 10.0.0.8 via ge-0/0/4.0

Проверка прохождения трафика от LNX к M34:

[e-mail]# run traceroute 192.168.0.1 
traceroute to 192.168.0.1 (192.168.0.1), 30 hops max, 40 byte packets
 1  10.0.0.22 (10.0.0.22)  3.588 ms  0.948 ms  0.650 ms
     MPLS Label=1000005 CoS=0 TTL=1 S=1
 2  10.0.0.20 (10.0.0.20)  4.459 ms  1.301 ms  1.192 ms
     MPLS Label=1000006 CoS=0 TTL=1 S=1
 3  192.168.0.1 (192.168.0.1)  5.360 ms  1.843 ms  2.219 ms

Т.е. видно, что трафик ходит именно по тому пути, который мы для него установили.

Проверка LSP:

[e-mail]# run show mpls static-lsp extensive 
Ingress LSPs:
LSPname: LNX-M34, To: 192.168.0.1
  State: Up
  Nexthop: 10.0.0.22 Via ge-0/0/2.0
  LabelOperation: Push, Outgoing-label: 1000005
  Created: Fri Apr 23 13:40:53 2021
  Bandwidth: 0 bps
  Statistics: Packets 293, Bytes 17531
Total 1, displayed 1, Up 1, Down 0

[e-mail]# run show mpls static-lsp extensive 
Ingress LSPs:
Total 0, displayed 0, Up 0, Down 0

Transit LSPs:
LSPname: LNX-M34, Incoming-label: 1000005
  State: Up, Sub State: Traffic via primary but unprotected
  Nexthop: 10.0.0.20 Via ge-0/0/4.0
  LabelOperation: Swap, Outgoing-label: 1000006
  Created: Fri Apr 23 13:45:37 2021
  Bandwidth: 0 bps
  Statistics: Packets 256, Bytes 16662
Total 1, displayed 1, Up 1, Down 0

Также стоит обратить внимание на таблицы inet.3 и mpls.0:

[e-mail]# run show route table inet.3  

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.0.1/32     *[MPLS/6/1] 01:33:45, metric 0
                    > to 10.0.0.22 via ge-0/0/2.0, Push 1000005

[edit]
[e-mail]# run show route table mpls.0    

mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0                  *[MPLS/0] 01:44:56, metric 1
                      to table inet.0
0(S=0)             *[MPLS/0] 01:44:56, metric 1
                      to table mpls.0
1                  *[MPLS/0] 01:44:56, metric 1
                      Receive
2                  *[MPLS/0] 01:44:56, metric 1
                      to table inet6.0
2(S=0)             *[MPLS/0] 01:44:56, metric 1
                      to table mpls.0
13                 *[MPLS/0] 01:44:56, metric 1
                      Receive

[e-mail]# run show route table mpls.0 

mpls.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0                  *[MPLS/0] 01:40:44, metric 1
                      to table inet.0
0(S=0)             *[MPLS/0] 01:40:44, metric 1
                      to table mpls.0
1                  *[MPLS/0] 01:40:44, metric 1
                      Receive
2                  *[MPLS/0] 01:40:44, metric 1
                      to table inet6.0
2(S=0)             *[MPLS/0] 01:40:44, metric 1
                      to table mpls.0
13                 *[MPLS/0] 01:40:44, metric 1
                      Receive
1000005            *[MPLS/6] 01:40:44, metric 1
                    > to 10.0.0.20 via ge-0/0/4.0, Swap 1000006

Тут видно, что если таблица inet.3 хранится на Ingress-Router'ах, то mpls.0 заполнена чем-то помимо служебных меток только на транзитных. Логично, что роутер может быть Ingress/Egress/Transit для разных LSP одновременно.

Из вывода таблиц можно сделать вывод, что inet.3 нужна для определения FEC и, в основном, для операции Push, а mpls.0 уже для коммутации по меткам, не оглядываясь на таблицу маршрутизации. Т.е. на сетевой уровень мы смотрим только в начале пути.

Приводить конфигурацию настройки статического LSP не имеет смысла, так как тут всё довольно очевидно.