Отказоустойчивость и оптимизация в MPLS

Без включения каких-либо функций защиты: трафик будет дропаться каждый раз, когда будет падать LSP.

Время:

• PE должен обнаружить падение линка, оправить ResvTear к ingress роутеру.
• Ingress перестает отправлять Path и Resv, чтобы удалить LSP.
• LSP удаляется из inet.3 => L2VPN, L3VPN становятся нерабочими.
• ingress пытается установить новый LSP.
• Если новый LSP удается установить, то LSP добавляется в inet.3, L2VPN, L3VPN - начинают работать.
• Трафик пошел по новому LSP.

Для того, чтобы в случае возникновения аварии не было большого простоя, были внедрены некоторые механизмы защиты.

Link Protection

Защищает от падения линка между роутерами, участвующими в RSVP LSP. Когда сконфигурирован link protection, каждый роутер пытается найти обходной путь до следующего в LSP роутера.

Такой обходной путь называется next-hop bypass LSP. Каждый обходной путь устанавливается только после того, как будет построена LSP. Когда линк падает, то переход на альтернативный путь инициирует роутер, который зафиксировал падение линка и который является ближайшим к ingress роутеру.

Такой роутер-инициатор называют PLR - point of local repair. После того, как трафик пройдет по обходному пути, он вернется на путь изначального LSP. Когда PLR переключает трафик на bypass LSP, он сигнализирует об этом ingress роутеру. Ingress пытается найти и установить другой primary path для LSP.

Есть возможность сконфигурировать bypass руками.

Что происходит с метками: в случае падения линка, на PLR производится swap метки (согласно LSP), но сверху добавляется еще одна метка (push 30880 (top)) и пакет отправляется на egress интерфейс для bypass пути. Также bypass LSP использует PHP, поэтому на предпоследнем хопе верхняя метка будет снята и дальше пакет будет следовать меткам первоначального LSP.

Плюсы:

• Быстро отрабатывает
• Масштабируемость: для резервировании большого кол-ва LSP можно обойтись несколькими обходными next-hop bypass LSP.

Минусы:

• Для работы link protection требуется включение этой функции на всех роутерах, внутри протокола rsvp, которые будут участвовать в построении LSP.

Configuration

[edit protocols mpls]
label-switched-path dalwhinnie-to-oban {
       to 10.200.86.3;
       link-protection;
   }
[edit protocols rsvp]
interface all {
   link-protection;
}

Хорошей практикой является включение link protection внутри protocols RSVP на всех интерфейсах, внутри RSVP домена.

Смотрим что происходит с метками для обходного пути на PLR роутере.

glenlivet> show mpls lsp transit 
Transit LSP: 1 session
To              From            State   Rt Style Labelin Labelout LSPname 
10.200.86.3     10.200.86.5     Up       0  1 SE  300544   300624 dalwhinnie-to-oban

glenlivet> show route label 300544 detail     
mpls.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
300544 (1 entry, 1 announced)
       *RSVP   Preference: 7/1
               Next hop type: Router, Next hop index: 262147
               Address: 0x9440488
               Next-hop reference count: 2
               Next hop: 192.168.86.9 via ge-0/0/0.60 weight 0x1, selected
               Label-switched-path dalwhinnie-to-oban
               Label operation: Swap 300624
               Next hop: 192.168.86.45 via ge-0/0/0.40 weight 0x8001
               Label-switched-path Bypass->192.168.86.9
               Label operation: Swap 300624, Push 300320(top) 
               Label TTL action: prop-ttl, prop-ttl(top)
               State: <Active Int>
               Local AS:  1111 
               Age: 6:06 	Metric: 1 
               Task: RSVP
               Announcement bits (1): 0-KRT 
               AS path: I

На следующем роутере (в нашем случае предпоследнем на обходном пути): смотрим ту запись в таблице mpls.0, которая подписана как 300320(S=0). Эту запись смотрим, когда количество меток в пришедшем пакете >= 2. Если количество меток = 1, то смотрим запись без обозначения S=0.

mortlach> show route label 300320 detail 
mpls.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
300320 (1 entry, 1 announced)
       *RSVP   Preference: 7/1
               Next hop type: Router, Next hop index: 585
               Address: 0x934cfd0
               Next-hop reference count: 3
               Next hop: 192.168.86.50 via ge-0/0/0.80 weight 0x1, selected
               Label-switched-path Bypass->192.168.86.9
               Label operation: Pop
               State: <Active Int AckRequest>
               Age: 13:38 	Metric: 1 
               Task: RSVP
               Announcement bits (1): 0-KRT 
               AS path: I
300320(S=0) (1 entry, 1 announced)
       *RSVP   Preference: 7/1
               Next hop type: Router, Next hop index: 587
               Address: 0x934cf40
               Next-hop reference count: 2
               Next hop: 192.168.86.50 via ge-0/0/0.80 weight 0x1, selected
               Label-switched-path Bypass->192.168.86.9
               Label operation: Pop       
               State: <Active Int AckRequest>
               Age: 13:38 	Metric: 1 
               Task: RSVP
               Announcement bits (1): 0-KRT 
               AS path: I

Node-link Protection

Node-link protection для обхода упавшего роутера, участвующего в построении LSP, использует LSP next-next-hop bypass LSP, которая обеспечивает альтернативный путь к next-hop'у next-hop роутера.

Если топология сети не позволяет построить next-next-hop bypass LSP, или роутер является предпоследним в LSP, тогда роутер устанавливает просто next-hop bypass LSP. Если же топология сети не поддерживает и такой bypass LSP, то ничего не создается и роутер просто продолжает использовать изначальный LSP.

Одновременно роутер не будет строить next-next-hop bypass LSP и next-hop bypass LSP. Только что-то одно, в зависимости от топологии и возможностей оборудования.

При обнаружении падения узла, PLR просигнализирует об этому ingress роутеру и тот в свою очередь будет пытаться найти и установить новый primary LSP.

Next-next-hop bypass LSP также может обеспечить резерв для нескольких LSP.

Т.к. в случае с next-next-hop bypass строится отдельно LSP, то никаких махинаций с навешиванием дополнительных меток не происходит (как в link protection). Используются обычные операции: push, swap, pop.

Configuration

[edit protocols mpls]
label-switched-path dalwhinnie-to-oban {
       to 10.200.86.3;
       node-link-protection;
   }
[edit protocols rsvp]
interface all {
   link-protection;        - это требуется включать на всех роутерах в RSVP домене
}

Ниже в выводах команд show удалены лишние строки

Ingress router: После построения LSP, будет установлен обходной маршрут на случай падения соседнего роутера (glenlivet):

dalwhinnie> show mpls lsp ingress name dalwhinnie-to-oban detail 
10.200.86.3
 From: 10.200.86.5, State: Up, ActiveRoute: 0, LSPname: dalwhinnie-to-oban
 ActivePath:  (primary)
 Node/Link protection desired
 LSPtype: Static Configured
*Primary                    State: Up
   Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
192.168.86.5 S 192.168.86.9 S 192.168.86.25 S 
   Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
         10.200.86.6(flag=0x29) 192.168.86.5(flag=9 Label=299952) 10.200.86.1(flag=0x21) 192.168.86.9(flag=1 Label=300000) 10.200.86.3(flag=0x20) 192.168.86.25(Label=3)

dalwhinnie> show mpls lsp bypass 
Ingress LSP: 2 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
10.200.86.1     10.200.86.5     Up       0  1 SE       -   300720 Bypass->192.168.86.5->192.168.86.9

dalwhinnie> show mpls lsp bypass name Bypass->192.168.86.5->192.168.86.9 detail 
10.200.86.1
 From: 10.200.86.5, LSPstate: Up, ActiveRoute: 0
 LSPname: Bypass->192.168.86.5->192.168.86.9
 LSPtype: Static Configured
 Time left:    -, Since: Mon Oct 31 01:33:31 2016
 Type: Bypass LSP
   Number of data route tunnel through: 1
   Number of RSVP session tunnel through: 0
 Explct route: 192.168.86.29 192.168.86.1 192.168.86.41 192.168.86.50 
 Record route: <self> 192.168.86.29 192.168.86.1 192.168.86.41 192.168.86.50 

На транзитном: аналогично построится обходной путь на случай падения соседнего роутера (blair)

glenlivet> show mpls lsp bypass name Bypass->192.168.86.9->192.168.86.25 detail 
10.200.86.3
 From: 10.200.86.6, LSPstate: Up, ActiveRoute: 0
 LSPname: Bypass->192.168.86.9->192.168.86.25
 LSPtype: Static Configured
 Time left:    -, Since: Mon Oct 31 01:33:22 2016
 Type: Bypass LSP
   Number of data route tunnel through: 1
   Number of RSVP session tunnel through: 0
 Explct route: 192.168.86.45 192.168.86.21 192.168.86.33 192.168.86.38 
 Record route: <self> 192.168.86.45 192.168.86.21 192.168.86.33 192.168.86.38

На предпоследнем роутере: в связи с особенностями топологии (предпоследний роутер), будет создан не next-next-hop bypass, а next-hop bypass

blair> show mpls lsp bypass 
Ingress LSP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
10.200.86.3     10.200.86.1     Up       0  1 SE       -   299936 Bypass->192.168.86.25

blair> show mpls lsp bypass name Bypass->192.168.86.25 detail 
10.200.86.3
 From: 10.200.86.1, LSPstate: Up, ActiveRoute: 0
 LSPname: Bypass->192.168.86.25
 Time left:    -, Since: Mon Oct 31 00:22:03 2016
 Type: Bypass LSP
   Number of data route tunnel through: 1
   Number of RSVP session tunnel through: 0
 Explct route: 192.168.86.17 192.168.86.33 192.168.86.38 
 Record route: <self> 192.168.86.17 192.168.86.33 192.168.86.38

Разница между link protection и node-link protection:

• Node-link protection обеспечивает как link protection, так и node protection - в зависимости от топологии.
• Время реагирования на аварию в сети: link protection - PLR на основании hardware узнает, что упал линк и сразу переключит трафик на альтернативный путь. Node-link protection - распознает падение роутера, когда перестают приходить hello сообщения. То есть время реакции будет значительно отличаться.

Fast Reroute

На каждом промежуточном LSR создается LSP (detour) для обхода линка до следующей ноды и самой следующей ноды. Это проприетарный механизм Juniper. Кол-во потерянного трафика при аварии зависит от времени обнаружения падения ноды (или линка) и времени переключения на альтернативный путь.

При падении линка между узлами, роутер, ближайший к ingress сразу перестраивается на detour, построенный от себя. Потом сообщает ingress о падении линка и ingress в свою очередь переходит на какой-нибудь secondary path (не detour).

По умолчанию fast-reroute имеет ограничение в 6 хопов для построения path в сторону egress, но это значение можно менять (hop-count).

Также для detour можно задать резервирование полосы для detour LSP. Не обязательно величина bandwidth должна равняться той, что в настройках LSP.

set protocols mpls label-switched-path to-r6 fast-reroute (bandwidth 60m|bandwidth-percent 19)

По умолчанию detour LSP не наследует bandwidth. Чтобы наследовало - не знаю что нужно сделать, скорей всего задать такой же как в LSP.

При переходе на detour, в forwarding table нужно добавить next-hop, а это дополнительная задержка для оперативного перехода на detour.

Чтобы исключить это время, можно использовать балансировку (load balancing policy).

Отличия от node-link-protection:

• При работе механизма frr лейбл не добавляется в стек к пакету. Вместо этого PLR производит swap на другой лейбл.
• Каждый detour защищает только свою конкретную LSP, что делает эту технологию менее масштабируемой. Но для сглаживания этой ситуации: когда разные роутеры строят detour, то эти detour могут использовать (разделять) одни и те же линки с целью слиться обратно в изначальный LSP...

Если у LSP, который защищен detour LSP, есть link-coloring ограничения, то detour их тоже унаследует. Чтобы отключить это поведение: set protocols mpls label-switched-path to-r6 fast-reroute no-include-all

Configuration

Все настраивается только на ingress роутере.

[edit protocols mpls]
label-switched-path dalwhinnie-to-oban {
      to 10.200.86.3;
      fast-reroute;

[policy-options policy-statement lbalancing]
then {
   load-balance per-packet;
   accept
[routing-options forwarding-table] 
export lbalancing;

Для поверки работоспособности detour:

show rsvp session detail
...
Detour is Up
Detour Record route: <self> 192.168.86.29 192.168.86.1 192.168.86.13 192.168.86.33 192.168.86.38

На транзитном:

glenlivet> show rsvp session transit detail lsp name dalwhinnie-to-oban
...
Detour Record route: 192.168.86.6 <self> 192.168.86.45 192.168.86.42 192.168.86.13 192.168.86.33 192.168.86.38

Secondary path

Строим параллельно дополнительные path для LSP.

Primary path считается основным path. Если один из линков или роутеров на primary path упадет, трафик пойдет по secondary. Но как только primary path станет доступным, трафик вернется обратно на primary. Чтобы избежать возвращения трафика на primary path, можно настроить два или более secondary путей, не настраивая ни одного primary, в таком случае трафик будут переходить с одного secondary на другой secondary, только при падении secondary (исключаем переход трафика при восстановлении primary).

Все secondary - одинаковы, порядок их использования зависит от расположения в конфигурации.

Восстановление упавших линков производится по очереди как они упали, не одновременно.

Standby в конфигурации позволяет строить secondary LSP параллельно (по времени) с основным LSP.

В конфиге можно задать standby как на уровне label-switched-path, так и относительно конкретного secondary.

По дефолту все атрибуты primary path будут наследоваться secondary или standby path (priority/hold/bandwidth), если явно не указано другого поведения.

Можно изменить дефолтное поведение выбора активного пути:

• select uniconditional - более приоритетный - если хотя бы у одного path а рамках одной LSP будет задан этот параметр, то все path будут наследовать именно это поведение. Этот параметр позволяет оставаться активным даже тому path, который деградирует или вообще в состоянии down.
• select manual - это стандартный механизм, если path -> down, то активным выбирается другой path.

Если в конфигурации mpls path не указано дополнительных атрибутов (loose, strict, просто next-hop, ...), то просто будет построен лучший путь.

Всегда лучше задавать некие атрибуты, чтобы secondary не повторяли primary или друг друга.

Есть параметры, которые позволяют не сразу переходить на восстановленный primary LSP:

• retry-timer: время между попытками поднять упавший primary path. По умолчанию - 30 сек
• retry-limit: кол-во неудачных попыток поднять упавший primary path. По умолчанию - 0. Если лимит достигли, то требуется ручками рестарануть сигналинг.
• revert-timer: min время, кот primary path должен быть в состоянии up, до того как трафик перейдет на него. По дефолту - 60 сек. Если устанавливаем в 0, то не перестраивается впринцепе.

Минусы:

• Долгое реагирование, из-за того, что ingress принимает решение о переходе на secondary LSP.

Configuration

[edit protocols mpls]
 R1# show
 label-switched-path R1-to-R4 { 
	to 10.0.0.3; 
	primary via-blair; 
	secondary via-tormore { 
		standby; 
	}	 
} 
path via-tormore { 
	10.200.86.9 loose; 
}
 path via-blair { 
	192.168.10.15 strict; 
	192.168.10.4 strict; 
	192.168.10.55 strict; 
}


Проверка:

dalwhinnie> show mpls lsp name dalwhinnie-to-oban detail Ingress LSP: 2 sessions
...
*Primary via-blair State:Up
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 192.168.86.5 192.168.86.9 192.168.86.25 
Standby via-tormore State: Up
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 192.168.86.29 192.168.86.1 192.168.86.13 192.168.86.33 192.168.86.38

Loop-Free Alternates in IGPs

Подробно не рассматривается в книге. Этот метод может сделать привлекательным использование LDP для сети, которой нужны MPLS-службы (L2VPN, L3VPN, VPLS), но нет необходимости в Traffic Engineering. Конфигурируется добавлением опций «link-protection» или «node-link protection» в настройку интерфейса в протоколе ospf или IS-IS. При этом IGP на каждом роутере как-будто убирает из топологии линк (в случае с link protection) или ноду (node-link protection), пересчитывает маршруты с новой топологией и вставляет их в PFE.

Добавлением же опции «no-eligible-backup» можно предотвратить интерфейс от обслуживания бэкапного трафика.

Дополнительно требуется включить per-packet load-balancing чтобы все next-hop попали с таблицу форвардинга.

[edit protocols] 
ps@dalwhinnie# show ospf 
area 0.0.0.0 {
interface ge-0/0/0.0 {
               link-protection;
interface ge-0/0/1.0 { 
               node-link-protection;

[policy-options policy-statement lbalancing]
then {
   load-balance per-packet;
   accept
[routing-options forwarding-table] 
export lbalancing;

Priorities and Preemption

Процесс построения LSP может регулироваться приоритетами.

Разделяют 2 приоритета: setup priority, hold priority.

Setup priority должен быть сильнее (ближе к 0), чтобы LSP имела право вперед других построиться.

0 - более приоритетный, 7 - менее приоритетный

Дефолтные настройки: setup = 7, hold = 0. По сути это отсутствие вытеснения.

setup не может быть сильнее hold.

Нормальная практика указывать одинаковый setup и hold priority.

Чтобы не происходило жесткого вытеснения с потерей трафика на более слабых LSP, можно использовать soft preemption.

Soft-preemption: при (перед) вытеснением LSP, пытается переустановить эту LSP по новому пути. Если это удается сделать, то трафик переходит на новую LSP, только после этого кладется старая.

Ingress router выставляет soft-preemption flag в RRO. Если функция не поддерживается всеми роутерами на пути построения LSP, то все-равно LSP установится.

[edit protocols mpls label-switched-path to-oban]
+           priority 5 2;  (setup hold)

Optimization

Без включенной оптимизации LSP перестраиваются только во время изменения топологии.

По умолчанию, оптимизации отключена. Может быть произведена в ручном режиме или можно задать таймер, по которому она будет производиться автоматически.

Правила нормальной оптимизции:

1. CSPF метрика не должна быть выше
2. Если метрика одинакова, то кол-во хопов должно быть меньше.
3. Новый path не вызывает вытеснения.
4. Не должно происходить усугубление заторов, для этого сравнивается available bandwidth на старых и новых линках, начиная с более загруженных.
5. Уменьшает затор на 10%

Aggressive: оптимизация только на основании метрик IGP.

mortlach# set protocols mpls ?           
 optimize-aggressive  Run aggressive optimization algorithm based on IGP metric only
 optimize-timer       Periodical path reoptimizations (0..65535 seconds)

Adaptive mode

Меняет стиль резервирования полосы для LSP. Если указываем в настройках на уровне label-switched-path, то для резервирования bandwidth разных LSP можно использовать один физ линк. (общий линк для разных LSP.) Помогает избежать двойного подсчета одного и того же трафика на общем линке.

Но если задать adaptive на уровне primary или secondary path, то SE reservation будет работать только для primary или secondary path. То есть все-равно резервирование будет производиться дважды.

Работает по принципу make-before-break. То есть включает в себя и функции soft-preemption.

1. Устанавливает новый path с SE reservation (с тем же session ID).
2. Передает трафик в новый path
3. Кладет старый path

[edit protocols mpls label-switched-path test1]
set adaptive

Типа резервирования:

• Fixed filter (FF): каждый session/sender/LSP имеет свой идентификатор. Каждая LSP резервирует свою bandwidth на линке.
• Shared Explicit (SE): Каждый session/sender/LSP имеет свой идентификатор. Но каждая LSP делит резервирование bandwidth с другими LSP на одном линке.

Дополнительная информация

• Глава 2. Label Distribution Protocols (RSVP, LDP)
• Traffic engineering
• Реализация MPLS в ядре сети