Отказоустойчивость и оптимизация в MPLS: различия между версиями

Материал из Juniper Exam Wiki
Перейти к навигации Перейти к поиску
Строка 211: Строка 211:


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


''Standby'' в конфигурации позволяет строить secondary LSP параллельно (по времени) с основным LSP.
''Standby'' в конфигурации позволяет строить secondary LSP параллельно (по времени) с основным LSP.
В конфиге можно задать standby как на уровне label-switched-path, так и относительно конкретного secondary.


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

Версия 18:54, 26 января 2017

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

Что происходит с метками: в случае падения линка, на 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. Кол-во потерянного трафика при аварии зависит от времени обнаружения падения ноды (или линка) и времени переключения на альтернативный путь.

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

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

Если у LSP, который защищен detour LSP, есть link-coloring ограничения, то detour их тоже унаследует.

Configuration

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

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

Для поверки работоспособности 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. Если один из линков или роутеров на основном пути упадет, трафик пойдет по secondary. Но как только primary path станет доступным, трафик вернется обратно на primary. Чтобы избежать возвращения трафика на primary path, можно настроить два или более secondary путей, не настраивая ни одного primary, в таком случае трафик будут переходить с одного secondary на другой secondary, только при падении secondary (исключаем переход трафика при восстановлении primary).

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

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

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

Если в конфигурации mpls path не указано дополнительных атрибутов (loose, strict...), то просто будет построен лучший путь. Всегда лучше задавать некие атрибуты, чтобы 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;