# Настройка

![Схема сети](/files/-M_BcYHQgxhb_4phCAY9)

![Схема сети](/files/-M_BiuwHaQczwqQcP6cN)

| 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:

```
root@RT.MSK.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. Удалим этот явно заданный путь:

```
root@RT.MSK.M34# show | compare 
[edit protocols mpls label-switched-path M34-LNX]
-     primary l_MIR-s_OBV,LNX;
```

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

```
root@RT.MSK.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:

```
root@RT.MSK.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;
+            }
+        }
+    }
```

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

```
root@RT.MSK.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
```

Результат:

```
root@RT.MSK.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

root@RT.MSK.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

![](/files/-M_LYqy25ds-Ko8fvFz3)

Если мы имеем к несколько путей для построения 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:

```
root@RT.SPB.MIR# 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;
+    }
```

Проверяем:

```
root@RT.SPB.MIR# 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. Меняем:

```
root@RT.SPB.MIR# show | compare 
[edit protocols mpls label-switched-path MIR-M34]
-    least-fill;
+    most-fill;
```

Проверка:

```
root@RT.SPB.MIR# 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 по этим "цветам".

![](/files/-M_LYut_9aA_ENu8FXJy)

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

![](/files/-M_LbClosmmq0u5ocRAt)

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

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

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

```
root@RT.MSK.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;
+    }
```

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

```
root@RT.SPB.MIR# 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 если линк помечен одним из указанных цветов (Логическое **ИЛИ**)

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

```
root@RT.SPB.MIR# 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.

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

```
root@RT.SPB.MIR# 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, который будет использовать линки с фиолетовым и синим цветом одновременно.

```
root@RT.SPB.LNX# 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

```
root@RT.SPB.LNX# 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

![](/files/-M_Mi9gRxtZOQf4sEoZY)

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

1. LNX - STL - K12
2. K12 - LNX

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

{% tabs %}
{% tab title="RT.SPB.K12" %}

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

{% endtab %}

{% tab title="RT.SPB.LNX" %}

```
[edit protocols mpls label-switched-path LNX-K12]
root@RT.SPB.LNX# show 
to 192.168.0.7;
bandwidth 25m;
admin-group include-all [ PURPLE BLUE ];
ultimate-hop-popping;
```

{% endtab %}
{% endtabs %}

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

```
root@RT.SPB.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
```

Проверка:

```
root@RT.SPB.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            

root@RT.SPB.LNX# 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](http://juniper-exam.ru/wiki/Traffic_engineering).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://netlabs.gitbook.io/juniper/12-cspf-dynamic-te/nastroika.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.