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
Если мы имеем к несколько путей для построения CSPF с одинаковой метрикой, то мы можем выбирать по какому пути строить LSP: выбрать ли нам наиболее загруженный путь (Most-Fill), либо наименее (Least-Fill). По-умолчанию путь выбирается по случайному правилу (Random).
Допустим, мы хотим построить путь из RT.SPB.MIR в RT.MSK.M34 c зарезервированной полосой в 250m. У нас есть 4 пути:
MIR - OBV - STL - M34 (Уже зарезервировано 150m)
MIR - OBV - M9 - M34 (Уже зарезервировано 900m)
MIR - OBV - M8 - M34 (Свободен весь гигабит)
MIR - LNX - STL - M34 (Уже зарезервировано 150m)
При необходимых 250мб/с сразу отметаем второй путь. Остаётся два. Попробуем сначала построить канал по правилу 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# 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:
MIR - OBV - STL - M34 (Уже зарезервировано 150m)
MIR - OBV - M9 - M34 (Уже зарезервировано 900m)
MIR - OBV - M8 - M34 (Свободен весь гигабит)
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
Перейдём к настройке и распределению цветов по линкам:
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# 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. У нас будет два пути:
LNX - STL - K12
K12 - LNX
Настраивать необходимо оба роутера. Настройка выглядит так:
[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;
[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;
Теперь мы видим соответствующие 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). Подробнее тут: .
