Настройка

Схема сети

Схема сети

Hostname	LoopBack/NET
RT.MSK.M34	192.168.0.1/49.0001.1921.6800.0001.00
RT.MSK.M8	192.168.0.2/49.0001.1921.6800.0002.00
RT.MSK.M9	192.168.0.3/49.0001.1921.6800.0003.00
RT.SPB.STL	192.168.0.4/49.0001.1921.6800.0004.00
RT.SPB.OBV	192.168.0.5/49.0001.1921.6800.0005.00
RT.SPB.MIR	192.168.0.6/49.0001.1921.6800.0006.00
RT.SPB.K12	192.168.0.7/49.0001.1921.6800.0007.00
RT.SPB.LNX	192.168.0.8/49.0001.1921.6800.0008.00

1. Базовый CSPF

Сразу вспомним нашу настройку RSVP:

[e-mail].M34# show protocols mpls 
path-mtu {
    allow-fragmentation;
    rsvp mtu-signaling;
}
no-cspf;
label-switched-path M34-LNX {
    to 192.168.0.8;
    corouted-bidirectional;
    bandwidth 150m;
    oam {
        bfd-liveness-detection {
            minimum-interval 1000;
            multiplier 3;
            failure-action teardown;
        }
    }
    ultimate-hop-popping;
    primary l_MIR-s_OBV,LNX;
}
path l_MIR-s_OBV,LNX {
    10.0.0.24 loose;
    10.0.0.25 strict;
    10.0.0.27 strict;
}                                       
interface all;

Видно, что ERO-=[loose MIR, strict OBV, LNX]. И по этому пути была зарезервировано 150m. Удалим этот явно заданный путь:

[e-mail].M34# show | compare 
[edit protocols mpls label-switched-path M34-LNX]
-     primary l_MIR-s_OBV,LNX;

Теперь трафик идёт по Best IGP Path (M34-STL-LNX):

[e-mail].M34# run traceroute mpls rsvp M34-LNX                           
  Probe options: retries 3, exp 7

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   300064  RSVP-TE     10.0.0.1         (null)           Success           
    2   299984  RSVP-TE     10.0.0.9         10.0.0.1         Egress            

  Path 1 via ge-0/0/3.0 destination 127.0.0.64

А теперь попробуем просто составить путь с полосой 900m от M34 до K12:

[e-mail].M34# show | compare 
[edit protocols mpls]
     label-switched-path M34-LNX { ... }
+    label-switched-path M34-K12 {
+        to 192.168.0.7;
+        corouted-bidirectional;
+        bandwidth 900m;
+        oam {
+            bfd-liveness-detection {
+                minimum-interval 1000;
+                multiplier 3;
+                failure-action teardown;
+            }
+        }
+    }

Посмотрим что произошло с нашей сессией:

[e-mail].M34# run show mpls lsp extensive 
Ingress LSP: 2 sessions

192.168.0.7
  From: 192.168.0.1, State: Dn, ActiveRoute: 0, LSPname: M34-K12
  Bidirectional
  ActivePath: (none)
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
  Primary                    State: Dn
    Priorities: 7 0
    Bandwidth: 900Mbps
    SmartOptimizeTimer: 180
    OAM state : BFD session not up LSP-ping not up
   11 May  8 15:52:34.105 Requested bandwidth unavailable[2 times]
   10 May  8 15:52:25.257 10.0.0.1: Requested bandwidth unavailable
    9 May  8 15:52:25.086 Deselected as active
    8 May  8 15:52:25.086 Originate Call
    7 May  8 15:52:25.085 Call was cleared by RSVP
    6 May  8 15:52:25.085 Session preempted
    5 May  8 15:52:25.085 10.0.0.0: Down
    4 May  8 15:50:28.932 Selected as active path
    3 May  8 15:50:28.914 Record Route:  10.0.0.1 10.0.0.3
    2 May  8 15:50:28.913 Up            
    1 May  8 15:50:28.849 Originate Call
  Created: Sat May  8 15:50:28 2021

Судя по логу, она просто не поднялась, так как мы не можем зарезервировать для этого LSP 900m. При этом остальные линки абсолютно свободны. А теперь включим CSPF на всех узлах. Просто удалим следующую команду со всех узлов:

delete protocols mpls no-cspf

Результат:

[e-mail].M34# run show mpls lsp              
Ingress LSP: 2 sessions
To              From            State Rt P     ActivePath       LSPname
192.168.0.7     192.168.0.1     Up     0 *                      M34-K12 Bidir
192.168.0.8     192.168.0.1     Up     0 *                      M34-LNX Bidir

[e-mail].M34# run show mpls lsp extensive    
Ingress LSP: 2 sessions

192.168.0.7
  From: 192.168.0.1, State: Up, ActiveRoute: 0, LSPname: M34-K12
  Bidirectional
  ActivePath:  (primary)
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary                    State: Up
    Priorities: 7 0
    Bandwidth: 900Mbps
    SmartOptimizeTimer: 180
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 60)
 10.0.0.5 S 10.0.0.7 S 10.0.0.3 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          10.0.0.5 10.0.0.7 10.0.0.3
    OAM state : BFD session up  LSP-ping up
   17 May  8 15:58:49.464 Selected as active path
   16 May  8 15:58:49.446 Record Route:  10.0.0.5 10.0.0.7 10.0.0.3
   15 May  8 15:58:49.446 Up
   14 May  8 15:58:49.309 Originate Call
   13 May  8 15:58:49.309 CSPF: computation result accepted  10.0.0.5 10.0.0.7 10.0.0.3
   12 May  8 15:58:49.308 Clear Call
   11 May  8 15:58:34.174 Requested bandwidth unavailable[10 times]
   10 May  8 15:52:25.257 10.0.0.1: Requested bandwidth unavailable
    9 May  8 15:52:25.086 Deselected as active
    8 May  8 15:52:25.086 Originate Call
    7 May  8 15:52:25.085 Call was cleared by RSVP
    6 May  8 15:52:25.085 Session preempted
    5 May  8 15:52:25.085 10.0.0.0: Down
    4 May  8 15:50:28.932 Selected as active path
    3 May  8 15:50:28.914 Record Route:  10.0.0.1 10.0.0.3
    2 May  8 15:50:28.913 Up
    1 May  8 15:50:28.849 Originate Call
  Created: Sat May  8 15:50:28 2021

Оба пути построены. Не смотря на то, что в первый раз для пути M34-K12 построить LSP не удалось из-за того же ограничения по пропускной способности, произошёл выбор другого пути и сессия установилась. Теперь ERO=[M34 - M9 - STL - K12]. Весь путь построен при помощи Strict ERO, так нужно для нормального функционирования CSPF (для полного контроля над состоянием пути).

2. Tie Breaking Rules

Если мы имеем к несколько путей для построения CSPF с одинаковой метрикой, то мы можем выбирать по какому пути строить LSP: выбрать ли нам наиболее загруженный путь (Most-Fill), либо наименее (Least-Fill). По-умолчанию путь выбирается по случайному правилу (Random).

Допустим, мы хотим построить путь из RT.SPB.MIR в RT.MSK.M34 c зарезервированной полосой в 250m. У нас есть 4 пути:

1. MIR - OBV - STL - M34 (Уже зарезервировано 150m)

2. MIR - OBV - M9 - M34 (Уже зарезервировано 900m)

3. MIR - OBV - M8 - M34 (Свободен весь гигабит)

4. MIR - LNX - STL - M34 (Уже зарезервировано 150m)

При необходимых 250мб/с сразу отметаем второй путь. Остаётся два. Попробуем сначала построить канал по правилу Least-Fill:

[e-mail]# show | compare 
[edit protocols mpls]
+    label-switched-path MIR-M34 {
+        to 192.168.0.1;
+        corouted-bidirectional;
+        bandwidth 250m;
+        oam {
+            bfd-liveness-detection {
+                minimum-interval 1000;
+                multiplier 3;
+                failure-action teardown;
+            }
+        }
+        least-fill;
+    }

Проверяем:

[e-mail]# run show mpls lsp detail | find RRO    
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          10.0.0.24 10.0.0.20 10.0.0.10

Путь полчуился, как и ожидалось: MIR - OBV - M8 - M34. Но, логичнее было бы забить уже занятый канал. Вдруг, появится клиент, который хочет иметь у себя канал в 800m. Меняем:

[e-mail]# show | compare 
[edit protocols mpls label-switched-path MIR-M34]
-    least-fill;
+    most-fill;

Проверка:

[e-mail]# run show mpls lsp detail | find RRO 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          10.0.0.27 10.0.0.8 10.0.0.0

Был выбран путь MIR - LNX - STL - M34. Скорее всего потому, что на этом пути больше всего линков с уже зарезервированной пропускной способностью.

3. Administrative Groups (Link Colors)

CSPF позволяет помечать линки определёнными битами. И для каждого LSP мы можем указать какие типы линков можно использовать, какие нельзя использовать и какие обязательно использовать. Под административные группы выделено 32 бита. Каждый бит - это одна административная группа. Т.е. для каждой административной группы мы можем выделить только один бит. Стоит отметить, что интерфейсам, смотрящим друг на друга, можно задать разные биты или назвать одни и те же биты по разному. Делать этого по очевидным причинам не стоит.

Вспомним про пути из RT.SPB.MIR в RT.MSK.M34:

1. MIR - OBV - STL - M34 (Уже зарезервировано 150m)

2. MIR - OBV - M9 - M34 (Уже зарезервировано 900m)

3. MIR - OBV - M8 - M34 (Свободен весь гигабит)

4. MIR - LNX - STL - M34 (Уже зарезервировано 150m)

Сейчас используется 4-й вариант. Предположим, что нам нужно избежать именно того, чтобы LSP строился через LNX. И, вообще, самые надёжные пути - это [MIR - OBV - STL - M34] и [MIR - OBV - M9 - M8 - M34]. Для этого можно пометить линки "цветами" и задать политику построения LSP по этим "цветам".

Распределим цвета по линкам:

Назначим цветам биты:

Цвет	Порядковый номер бита
GOLD	0
RED	1
GREEN	2
PURPLE	29
BLUE	30
WHITE	31

Перейдём к настройке и распределению цветов по линкам:

[e-mail].M34# show | compare 
[edit protocols mpls]
+   admin-groups {
+       GOLD 0;
+       RED 1;
+       GREEN 2;
+       PURPLE 29;
+       BLUE 30;
+       WHITE 31;
+   }
[edit protocols mpls]
     interface all { ... }
+    interface ge-0/0/0.0 {
+        admin-group [ GOLD RED GREEN ];
+    }
+    interface ge-0/0/1.0 {
+        admin-group BLUE;
+    }
+    interface ge-0/0/3.0 {
+        admin-group PURPLE;
+    }

А теперь зададим ограничения:

[e-mail]# show | compare 
[edit protocols mpls label-switched-path MIR-M34]
+     admin-group {
+         include-any [ RED GOLD ];
+         exclude [ BLUE PURPLE ];
+     }

Есть три параметра, которыми можно задать ограничения:

• exclude - Не строить LSP по линкам, помеченным соответствующим цветом

• include-all - Строить LSP только если линк помечен всеми указанными цветами (Логическое И)

• include-any - Строить LSP если линк помечен одним из указанных цветов (Логическое ИЛИ)

Результат коммита:

[e-mail]# run show mpls lsp detail | find RRO                          
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          10.0.0.24 10.0.0.20 10.0.0.10

Теперь LSP идёт по пути MIR - OBV - M8 - M34.

А теперь разорвём какой-нибудь линк на пути и посмотрим на перестроение:

[e-mail]# run show mpls lsp detail | find RRO    
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          10.0.0.24 10.0.0.14 10.0.0.12 10.0.0.10

Теперь путь следующий: MIR - OBV - M9 - M8 - M34, как и ожидалось.

Ради примера построим ещё один LSP: LNX - M9, который будет использовать линки с фиолетовым и синим цветом одновременно.

[e-mail]# show | compare 
[edit protocols mpls]
+  label-switched-path LNX-M9 {
+      to 192.168.0.3;
+      corouted-bidirectional;
+      bandwidth 50m;
+      admin-group include-all [ BLUE PURPLE ];
+      oam {
+          bfd-liveness-detection {
+              minimum-interval 1000;
+              multiplier 3;
+              failure-action teardown;
+          }
+      }
+  }

LSP: LNX - STL - M34 - M9

[e-mail]# run show mpls lsp detail | find RRO 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          10.0.0.8 10.0.0.0 10.0.0.5

4. Asymmetric LSP

Сразу перейдём к настройке LSP от LNX к K12. У нас будет два пути:

1. LNX - STL - K12

2. K12 - LNX

Настраивать необходимо оба роутера. Настройка выглядит так:

RT.SPB.K12

[edit protocols mpls label-switched-path K12-LNX]
[e-mail].K12# show 
to 192.168.0.8;
bandwidth 25m;
admin-group include-all [ BLUE GOLD ];
ultimate-hop-popping;

RT.SPB.LNX

Теперь мы видим соответствующие LSP в Ingress и Egress:

[e-mail].K12# run show mpls lsp 
Ingress LSP: 1 sessions
To              From            State Rt P     ActivePath       LSPname
192.168.0.8     192.168.0.7     Up     0 *                      K12-LNX
Total 1 displayed, Up 1, Down 0

Egress LSP: 2 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
192.168.0.7     192.168.0.1     Up       0  1 FF       3        - M34-K12 Bidir
192.168.0.7     192.168.0.8     Up       0  1 FF  299888        - LNX-K12
Total 2 displayed, Up 2, Down 0

Проверка:

[e-mail].K12# run traceroute mpls rsvp K12-LNX 
  Probe options: retries 3, exp 7

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   299984  RSVP-TE     10.0.0.19        (null)           Egress            

[e-mail]# run traceroute mpls rsvp LNX-K12    
  Probe options: retries 3, exp 7

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   300144  RSVP-TE     10.0.0.8         (null)           Success           
    2   299888  RSVP-TE     10.0.0.3         10.0.0.8         Egress            

Также у RSVP есть дполнительные фишки, по типу переноса inet.3 в inet.0 с различными параметрами (Так автоматически происходит с BGP-маршрутами, например, а можно весь трафик пускать по MPLS). Подробнее тут: Traffic-Engineering.