/ 13.-mpls-traffic-engineering / sposoby-upravleniya-tunnelyami.md
sposoby-upravleniya-tunnelyami.md
1 # Способы управления туннелями 2 3 Итак, у нас достаточно способов, как повлиять на путь трафика с помощью TE: 4 5 1. [Метрика пути MPLS TE](http://linkmeup.ru/blog/302.html#MPLS-TE-METRIC) 6 2. [Ограничение по полосе пропускания](http://linkmeup.ru/blog/302.html#BANDWIDTH) 7 3. [Explicit-Path](http://linkmeup.ru/blog/302.html#EXPLICIT-PATH) 8 4. [SRLG](http://linkmeup.ru/blog/302.html#SRLG) 9 5. [Administrative Groups/Affinity](http://linkmeup.ru/blog/302.html#AFFINITY) 10 11 ## Метрика пути MPLS TE 12 13 Первый самый очевидный способ — это метрики интерфейсов. 14 [Как мы помним](http://linkmeup.ru/blog/302.html#METRIC) есть IGP-метрики, а есть TE-метрики. Вторые по умолчанию равны первым. 15 TE-метрика на линковых интерфейсах не только влияет на метрику туннеля с точки зрения IGP Shortcut, но и учитывается при построении LSP. 16 17 > Для чего может понадобиться настраивать TE-метрику отличной от IGP? 18 > Например, есть линия с высоким значением задержки. Ей задаём бОльшее значение TE-метрики. 19 > Тогда: 20 > При построении туннелей для голосового трафика будем использовать TE-метрику, 21 > В туннелях для прочих данных — IGP. 22 23 Используется для этого команда 24 25 ```text 26 Router(config-if)#mpls traffic-eng administrative-weight значение TE-метрики 27 ``` 28 29 Чтобы указать туннелю, какую учитывать метрику: 30 Значение по умолчанию: 31 32 ```text 33 Router(config)# mpls traffic-eng path-selection metric {igp | te} 34 ``` 35 36 Конкретный туннель: 37 38 ```text 39 Router(config-if)# tunnel mpls traffic-eng path-selection metric {igp | te} 40 ``` 41 42 [Cisco подробно про метрики](http://www.cisco.com/c/en/us/td/docs/ios/12_2s/feature/guide/fsmetric.html). 43 44 ## Ограничение по полосе пропускания 45 46 На практике мы познакомились с базовой функцией TE — возможностью строить MPLS туннели с резервированием ресурсов на всём протяжении LSP. 47 48 Но не беспокоит ли вас вот эта идея с Bandwidth? Не возвращаемся ли мы в каменный век, когда не было переподписки. Да и как вообще определять величину этого ограничения? А что делать с тем, что она плавает в течение суток на порядки? 49 50 ### **Offline Bandwidth** 51 52 Метод, когда мы настраиваем статическое значение требуемой полосы, называется Offline Bandwidth. 53 Идея в том, что есть некая программа стоимостью в трёшку на Патриарших прудах, которая по каким-то алгоритмам вычисляет для вашего трафика одну цифру, которую вам и нужно настроить на туннеле. 54 55 Полосу можно настроить для всего туннеля, как мы делали это выше на практике: 56 57 ```text 58 Router(config-if)#tunnel mpls traffic-eng bandwidth значение требуемой полосы 59 ``` 60 61 А можно для конкретного RSVP LSP: 62 63 ```text 64 Router(config-if)#tunnel mpls traffic-eng path-option 1 dynamic bandwidth значение требуемой полосы 65 ``` 66 67 Это значение может отличаться от того, что указано для туннеля и имеет более высокий приоритет. 68 69 При этом для другого LSP \(path-option 2, например\), значение может отличаться — мол, если уж не получается зарезервировать 8 Мб/с, давай хотя бы 5 попробуем? 70 71 У Offline Bandwidth есть два существенных минуса: 72 — Ручная работа, которой хороший инженер старается избегать. 73 — Неоптимальное использование ресурсов. Ну, назначим мы полосу в 300 Мб/с клиенту, зарезервируем на каждой линии, а на деле ему надо-то от силы 30. И только в пике, когда у него бэкапятся БД, нужно 300. Неаккуратненько. 74 75 Этот вариант практиковался на заре появления TE. Существует он и сейчас. 76 Однако, следуя в ногу со временем, нужно быть более гибким и податливым. 77 78 ### **Auto-Bandwidth** 79 80 А Autobandwidth молодец. 81 Этот механизм отслеживает загрузку туннеля в течение определённого периода и потом адаптирует резервирование. 82 83 > **Терминология** 84 > 85 > **Adjust Interval** — время, в течение которого маршрутизатор наблюдает за трафиком и отслеживает пики. 86 > **Adjust Threshold** — порог, после которого RSVP перезапрашивает резервирование. 87 88 Ближе к телу. 89 90  91 92 Например, Adjust Interval у нас 2 часа. Текущее значение зарезервированной полосы пропускания — 90 Мб/с. 93 Adjust Threshold — 20 Мб/с. 94 95 В первом интервале всплеск 119 Мб/с \(до 119 Мб/с\) — больше порога. Значит RSVP-TE пытается построить новый туннель с новыми значениями для полосы пропускания. 96 97 Во втором — 23Мб/с \(до 142\) — опять больше порога. Обновляем резервирование по возможности. 98 99 В третьем максимальное значение падает до 137 Мб/с — разница только 5. Ничего не происходит. 100 101 В четвёртом всплеск падает до 116 \(разница 21\) — RSVP сигнализирует новый LSP с пониженными требованиями по полосе. 102 103 Так, каждые два часа будет происходить проверка и, возможно, перестроение туннелей. 104 Чем короче Adjust Interval, тем, соответственно, чаще будет обновляться резервирование и более рационально использоваться доступная полоса пропускания. 105 106 Примерно так при двухчасовом интервале будет выглядеть 24-часовое поведение auto-bandwidth. 107 108  109 110 Уже заметили проблему? 111 Возьмём типичный профиль утреннего трафика: 112 113  114 115 И такая дребедень целый день. 116 117 Вот измерили мы в 8 утра всплеск — 200 Мб/с. И два часа держится это значение для туннеля. А за это время на работу уже пришёл народ и запустил ютуб — средняя скорость уже 240, а всплески до 300. До 10 утра будет происходить тихая деградация. Тихая, потому что ни туннель, ни Auto-Bandwidth о ней не знают. А вот пользователи знают и их ИТшник тоже знает, уж поверьте. 118 119 Если же сильно уменьшать интервал юстировки, то на сети будут постоянно пересигналзироваться новые LSP. 120 121 Для решения этой и других проблем существуют механизмы **Overflow** и **Underflow**. Первый — для слежения за ростом трафика, второй — за снижением. 122 Если разница между текущим резервированием и всплесками трафика превосходит порог Overflow несколько раз подряд, RSVP TE будет пробовать построить новый LSP, не дожидаясь истечения Adjust Interval. 123 То же и для Underflow — RSVP-TE будет пересегнализировать LSP с более низкими требованиями, если заметил тенденцию к уменьшению объёма трафика. 124 125 И остаётся только одна, но серьёзная проблема. 126 Так уж устроен наш мир, что когда растёт трафик у одного абонента, обычно растёт и у другого. И может так статься, что когда придёт время снова увеличить резервирование, увеличить его будет уже некуда — всё занято. И тогда, если нет других путей, удовлетворяющих новым условиям, будет использоваться старый. И никому не будет дела до того, что его уже не хватает, что пакеты начали теряться, что клиент ищет номер директора, чтобы найти инженера, которому можно оторвать что-нибудь лишнее. 127 128 Мы с этим будем бороться с помощью приоритезации туннелей, о которой [ниже](http://linkmeup.ru/blog/302.html#PREEMPT-PRIORITY). 129 130 Для включения функции AutoBandwidth глобально и одновременно настройки Adjust Interval: 131 132 ```text 133 Router(config)#mpls traffic-eng auto-bw timers frequency [sec] 134 ``` 135 136 Далее для каждого туннеля отдельно нужно активировать AutoBandwidth. При этом можно задать другое значение для Adjust Interval, а также установить минимально и максимально возможные значения для резервируемой полосы. 137 138 ```text 139 Router(config)#tunnel mpls traffic-eng auto-bw max-bw Значение min-bw Значение 140 ``` 141 142 Для настройки Overflow: 143 144 ```text 145 Router(config)#tunnel mpls traffic-eng auto-bw [overflow-limit количество раз overflow-threshold Процент изменения] 146 ``` 147 148 Подробнее о Auto-Bandwidth можно почитать в очень [честном документе](https://ripe64.ripe.net/presentations/52-mpls-autobandwidth.pdf). 149 150 ## Приоритеты туннелей 151 152 Это механизм, который приоритезирует туннели: какой из них важнее. Он применим, как для случая Auto-Bandwidth в частности, так и для любого построения RSVP LSP вообще. 153 154 Всё предельно логично: 155 **Setup Priority** — приоритет установки RSVP LSP. 156 **Hold Priority** — приоритет удержания RSVP LSP. 157 158 Если полосы пропускания не хватает на узле, и у нового туннеля приоритет установки выше, чем приоритет удержания у старого, новый будет построен — старый сломан. 159 160 Оба имеют 8 значений: от 0 до 7. Для обоих 0 — это наивысший, 7 — наинизший. 161 162 Например, у нас есть туннель LSP1, у которого Hold priority **4**. 163 Тут приходит запрос от RSVP-TE на LSP2 с Setup Priority **6** и Hold Priority тоже **6**. Если полосы пропускания достаточно, то он просто построится. Если нет — то маршрутизатор не даст этого сделать — потому что уже существующий туннель приоритетнее нового \(4>6\). 164 Допустим, полосы достаточно и оба туннеля поднялись нормально. 165 И тут приходит новый запрос на LSP3 с Setup/Hold Priority **5**. Это выше, чем у LSP2, но ниже, чем у LSP1. И ему полосы уже не хватает. LSP1 точно не будет тронут, потому что его Hold приоритет до сих пор самый высокий. И тогда есть два варианта: 166 167 1. Если сломать LSP2, полосы хватает для LSP3. В этом случае Setup приоритет LSP3 выше, чем Hold LSP2. Ingress PE LSP2 узнаёт, что его LSP вероломно разломали и будет искать новый путь — его удача, если он найдёт. 168 2. Если сломать LSP2, полосы всё равно не хватит для LSP3. LSP1 маршрутизатор не отдаст. И тогда LSP1 и LSP2 остаются, а Ingress PE LSP3 будет искать другие возможности для самореализации. 169 170 Касательно значений — обычно выбираются одинаковые для Setup и Hold. И не стоит настраивать Hold ниже, чем Setup. Во-первых это не логично. Во-вторых, может случиться ситуация, когда два туннеля войдут в петлю, когда они будут постоянно перебарывать друг друга — как только установится один, второй его сломает и построится сам, потом первый сломает второй итд. 171 172 Существует два режима замещения туннелей: 173 **Hard preemption** — LSP с более высоким приоритетом просто замещает LSP с низким. Даже если потом LSP с низким приоритетом найдёт новый путь, часть трафика будет потеряна. 174 **Soft preemption** — применяется механизм Make-Before-Break. Маршрутизатор через RSVP-TE сообщает Ingress LSR низкоприоритетного LSP, что нужно искать новый путь. LSP с высоким приоритетом ожидает, пока трафик низкоприоритетного LSP переключится на новый LSP. 175 При этом, если путь найти не удалось в течение некоторого времени, низкоприоритетный LSP всё равно ломается и строится высокоприоритетный. 176 177 Данные о приоритетах замещения передаются в RSVP-TE PATH и учитываются при резервировании ресурсов на промежуточных узлах. 178 179 ### Практика 180 181 Если вы обратили внимание, то после настройки tunnel mpls traffic-eng badnwidth на туннельном интерфейсе, в конфигурации автоматически появляется строка **tunnel mpls traffic-eng priority 7 7**. 182 Дело в том, что без требований по полосе приоритеты не имеют никакого значения — через один узел можно проложить сколько угодно туннелей — ведь полоса не резервируется — и команды нет. 183 Но, как только появилось требование, по полосе, приоритеты начинают играть роль. 184 7 — это значение по умолчанию — наименьшее. 185 186 Давайте на Linkmeup\_R1 настроим новый туннель до 4.4.4.4 с более высоким приоритетом? 187 188 ```text 189 Linkmeup_R1(config)#interface Tunnel42 190 Linkmeup_R1(config-if)#ip unnumbered Loopback0 191 Linkmeup_R1(config-if)#tunnel mode mpls traffic-eng 192 Linkmeup_R1(config-if)#tunnel destination 4.4.4.4 193 Linkmeup_R1(config-if)#tunnel mpls traffic-eng priority 4 4 194 Linkmeup_R1(config-if)#tunnel mpls traffic-eng bandwidth 4000 195 Linkmeup_R1(config-if)#tunnel mpls traffic-eng path-option 1 dynamic 196 ``` 197 198 Необходимая полоса всего 4Мб/с. Поэтому туннель должен пройти по пути R1->R2->R3->R4. 199 200  201 202 Так и есть, вот его трассировка: 203 204  205 206 С Tunnel4 у них только один общий линк R3->R4, но его полоса пропускания только 10. А двум туннелям нужно 8+4=12. 207 Tunnel42 с приоритетом установки 4 выдавливает Tunnel4 с приоритетом удержания 7. 208 И тому приходится искать новый путь. 209 И он находится: 210 211  212 213 Сначала удаляется старый RSVP LSP Tunnel4 и сигнализируется новый по доступному пути 214 215  216 217 Потом RSVP-TE сигнализирует LSP для Tunnel42. 218 219  220 221  222 223 В этот момент вернёмся к Autobandwidth. Именно связка Tunnel priority + Autobandwidth даёт элегантное решение. 224 Одним ранним утром было трафика мало, autobandwidth подсчитал сколько именно его в каждом туннеле, и TE везде хватило пропускной способности. 225 Потом ближе к обеду трафик подрос, autobandwidth адаптировался, перерезервировал новые полосы — всё ещё хватает. 226 К вечеру один за другим туннели начинают вылетать, потому что TE не может зарезервировать новую полосу. 227 И тут важно, чтобы туннели жирных клиентов, IP-телефонии и канал для МВД никогда не падали. Тогда задаём для этих туннелей Hold priority выше, чем Setup priority других. 228 — При попытке низкоприоритетных зарезервировать новую полосу на интерфейсе, где её уже не хватает, он обломится. 229 — Высокоприоритетный наоборот вытеснит низкоприоритетный и займёт освободившуюся полосу. 230 231 Получается, что 232 233 * без Autobandwidth мы либо настраиваем требования полосы вручную на всей сети, либо вообще не делаем этого, пуская на самотёк, 234 * без Autobandwidth мы никогда не знаем, сколько реально трафика в туннеле, 235 * без Autobandwidth мы никак не можем его ограничить, 236 * без Tunnel priority мы не можем сказать наверняка, какие туннели пострадают. 237 238 ## Explicit-Path 239 240 Идея Explicit-Path более чем полно была раскрыта в [10-м выпуске СДСМ](http://linkmeup.ru/blog/154.html#EXPLICIT-PATH). 241 242 Как вы помните, CSPF вычисляет кратчайший путь с учётом ограничений. Далее этот путь трансформируется в объект ERO \(Explicit Route Object\) сообщения RSVP-TE PATH, который явно сообщает, по какому пути этот PATH нужно передать. 243 Так вот если, вы хотите, чтобы какие-то узлы обязательно присутствовали или наоборот отсутствовали в этом пути, можно это явно указать в Explicit-Path, который станет одним из входных ограничений для CSPF. 244 245 Итак, мы вручную задаём, через какие узлы должен пролечь LSP, а через какие не должен. 246 RSVP-TE просит CSPF рассчитать маршрут с учётом Explicit-Path и других ограничений туннеля. 247 Если одно входит в противоречие с другим — беда, не будет LSP. 248 249 > Explicit-Path — это строго локальное ограничение — только Ingress LSR о нём знает и не передаёт ни в анонсах IGP, ни в сообщениях RSVP-TE. 250 251 Настройка Explicit-path выполняется в два этапа: 252 1\) Создание самого explicit-path с ограничениями: 253 254 ```text 255 Router(config)# ip explicit-path name Имя 256 257 Router(cfg-ip-expl-path)# next-address IP-адрес 258 259 Router(cfg-ip-expl-path)# exclude-address IP-адрес 260 261 ... 262 ``` 263 264 2\) Применение его к path-option на туннеле: 265 266 ```text 267 Router(config-if)#tunnel mpls traffic-eng path-option 1 explicit name Имя 268 ``` 269 270 ## SRLG 271 272 **SRLG** — Shared Risk Link Group. Ещё один способ повлиять на LSP и отличная идея против [плоских колец](http://lookmeup.linkmeup.ru/#term577). 273 Задача этой функции предотвратить построение основного и резервного LSP через линии, которые могут повредиться одновременно. 274 Например, два волокна, которые физически проходят в одном кабеле, наверняка порвутся одним и тем же ковшом экскаватора. 275 276 **SRLG-группа** — группа интерфейсов, которые «разделяют риск». О! Группа риска. 277 278 Вручную \(конечно, а как иначе маршрутизатор узнает, что это физически идентичные линии\) настраиваются интерфейсы, которые являются членами одной SRLG-группы. 279 Информация о SRLG распространяется по сети вместе с анонсами IGP, как и доступная полоса или значение Attribute-Flag, и помещается потом в TEDB. 280 Далее CSPF должен учитывать эту информацию при расчёте кратчайших маршрутов. 281 282 Имеется два режима: 283 **Force Mode** заставляет CSPF учитывать данные SRLG обязательно — если иного пути нет, то резервный LSP не будет построен вообще. 284 **Preffered Mode** допускает построение запасных туннелей через SRLG-линии, если нет иных возможностей. 285 Режим задаётся на Ingress LSR. 286 287 Для добавления интерфейсов в одну группу риска на любых узлах вводится команда: 288 289 ```text 290 Router(config-if)# mpls traffic-eng srlg номер группы 291 ``` 292 293 А на Ingress PE включить проверку SRLG: 294 295 ```text 296 Router(config)# mpls traffic-eng auto-tunnel backup srlg exclude force/preffered 297 ``` 298 299 Что это за команда, поговорим в разделе [FRR](http://linkmeup.ru/blog/302.html#LOCAL-PROTECTION). 300 301 ## Administrative Groups или Affinity 302 303 Вот сейчас должно стать страшно. Мне страшно. 304 305 Итак, к данному моменту мы узнали про четыре инструмента управления трафиком: 306 307 * [Метрика MPLS TE.](http://linkmeup.ru/blog/302.html#MPLS-TE-METRIC) 308 * [Требования к полосе пропускания канала и приоритет замещения.](http://linkmeup.ru/blog/302.html#BANDWIDTH) 309 * [Explicit-path.](http://linkmeup.ru/blog/302.html#EXPLICIT-PATH) 310 * [SRLG.](http://linkmeup.ru/blog/302.html#SRLG) 311 312 [RFC3630](https://tools.ietf.org/html/rfc3630) для OSPF, а для ISIS определяют TLV для Administrative Group, который передаётся IGP вместе с другими характеристиками линиями. 313 314 > Пока вы не согнулись под тяжестью знаний, расскажу вам такую историю. 315 > 316 > Огромнейшая сеть linkmeup. Своя оптика, свои РРЛ пролёты, куски лапши, доставшиеся от купленных домонетов, куча арендованных каналов у разных операторов. И через всё это хозяйство MPLS, хуже того — TE-туннели. 317 > 318 > И для разных сервисов важно, чтобы они шли определённым путём. 319 > Например, трафик 2G ни в коем случае не должен идти через РРЛ-пролёты — проблемы с синхронизацией нас съедят. 320 > Трафик ШПД нельзя пускать через линии Балаган Телеком, потому что эти паразиты из 90-х берут деньги за объём пропущенного трафика. 321 > Разрешать строить туннели через сети доступа вообще запрещено категорически. 322 > И с этим нужно что-то делать. 323 324 Каждый раз, настраивая туннель, учитывать в Explicit Path все эти детали — с ума можно сойти. 325 Но, новая связка — удивительное спасение, которое решит все наши проблемы, просто нажмите кнопку «сделать хорошо». 326 327 Идея в том, что каждый интерфейс мы помечаем определёнными цветами. 328 А потом говорим, что вот этот туннель может идти по красным и фиолетовым линиям, но не может по зелёным, жёлтым и коричневым. 329 Marketing Bullshit! Непонятно? Мне тоже. 330 331 Итак. 332 Administrative Group \(у Juniper: admin-group, у Cisco: Attribute-Flag\) — это атрибут физического интерфейса, который может описать 32 его дискретных характеристики. 333 Какой бит из 32 за что отвечает решает оператор самостоятельно. 334 Раз уж примеры у нас в консоли Cisco, то далее буду использовать термин Attribute-Flag наравне с Administrative group, что не совсем правильно. 335 336 > Например, 337 > считаем с наименее значимых битов \(с конца\): 338 > первый бит в 1 означает, что это оптика 339 > второй бит в 1 означает, что это РРЛ 340 > третий бит в 0 означает, что это линия в сторону сети доступа, а 1 — магистральный интерфейс. 341 > четвёртый бит в 1 означает, что это аренда 342 > пятый бит в 1 означает, что это Балаган-Телеком 343 > шестой бит в 1 означает, что это Филькин-Сертификат 344 > седьмой бит в 1 означает, что это канал через интернет без гарантий. 345 > … 346 > десятый бит в 1 означает, что полоса пропускания меньше 500 Мб/с 347 > итд. я так могу все 32 утилизировать. 348 349 **Affinity и маска** — это требования туннеля к своему пути. 350 Какие отношения могут сложиться в этом треугольнике {Affinity, Mask, Attribute-Flag}? 351 352 ```text 353 (AFFINITY && MASK) == (ATTRIBUTE && MASK) 354 ``` 355 356 Если это равенство выполняется, туннель можно строить через этот интерфейс. 357 358 Рассмотрим на примере. 359 У нас есть 32 бита и политика — за что отвечает каждый из них \(возьмём пример выше\). 360 361 В Mask мы указываем, какие характеристики канала нас интересуют. Например, для туннеля с трафиком 2G важно 362 363 1. РРЛ это или нет 364 2. Магистральная линия или в сторону сегмента доступа 365 3. Канал через интернет или нет 366 367 Поэтому в маске выставляем 1 там, где важно, что стоит: 368 369 Mask: 0100 0110 370 Взяли только первые 8 бит для простоты. 371 Заметьте, что это [Wildcard Mask](http://lookmeup.linkmeup.ru/#term602). 372 373  374 375 В Affinity мы указываем, что именно нам нужно. 376 377 1. Чтобы это не был РРЛ \(**0**\) 378 2. Чтобы это был магистральный линк \(**1**\) 379 3. Канал не через интернет \(**0**\) 380 381 Affinity: 0000 0100. 382 383 Выполняем операцию и получаем: 0000 0100. 384 385 Теперь возьмём для примера три интерфейса. 386 387  388 389  390 391  392 393 1. Attribute-Flag 0000 0100 — Не РРЛ, магистральный и не через Интернет. Attribute-Flag && Mask = 0000 0100 = Affinity && Mask — сюда можно пускать трафик.  394 2. Attribute-Flag 0100 0000 — Не РРЛ, но в сторону сегмента доступа, да ещё и через интернет. Attribute-Flag && Mask = 0100 0000 ≠ Affinity && Mask — сюда нельзя пускать трафик.  395 3. Attribute-Flag 0000 0101 — Оптика, не РРЛ, магистральный и не через Интернет. Attribute-Flag && Mask = 0000 0100 = Affinity && Mask — сюда можно пускать трафик. Не важно, оптика или нет — результат тот же.  396 397 То есть при построении LSP на каждом линке будет учитываться значение Attribute-Flag. 398 По умолчанию значение Attribute-Flag на интерфейсе — **0x0**. И в некотором смысле — это прискорбно — ведь результат операции «И» с маской будет отличаться от результата с Affinity, а значит мы должны настроить Attribute-Flag на всех интерфейсах. 399 400 Соответственно, в пределах компании можно выработать политики, как помечать интерфейсы и как управлять трафиком. Можно возложить эту задачу даже на систему управления, чтобы работа инженера сводилась к расстановке галочек в графическом интерфейсе, а конфигурация затем применялась бы автоматически. 401 Но в любом случае это не умаляет человеческого фактора с одной стороны и просто непостижимой сложности отладки и обслуживания с другой. 402 403 Однако случаи комплексного внедрения Administrative Group даже на сетях российиских операторов имеются. 404 405 Другим примеров использования могли бы быть коды регионов или стран. Тогда можно было бы задавать через какую географию пропускать трафик. 406 В этом свете 32 бита оказывается очень мало, поэтому [RFC 7308](https://tools.ietf.org/html/rfc7308) определяет расширенные административные группы, количество бит в которых ограничено естественым пределом LSA или вообще MTU. 407 408 Парень на пальцах [разжёвывает Affinity](http://blog.codergenie.com/blog/post/2014/01/02/MPLS-TE-Affinity.aspx) и в рот стопочкой складывает. 409 410 ### Практика 411 412 Очень очень короткая. 413 Просто посмотрим, что работает. 414 Короткая, потому что применение Affinity требует настройки Attribute-Flag на всех узлах и всех интерфейсах. А это то, чего меньше всего хочется, если честно. 415 416  417 418 Продолжаем с последней конфигурации, где у нас два туннеля. 419 [Файл конфигурации.](https://docs.google.com/document/d/e/2PACX-1vQKReT4OtpH0fELxXf2AekJakhdikx2UHMPNOaFJRvNv3ML82Wmme65AaGgBBjEs3Ft6em1jyaLEH9v/pub) 420 Tunnel42 идёт по пути R1-R2-R3-R4. С ним и поиграем. 421 422 Значение Attribute-Flag по умолчанию 0x0. Поэтому его и возьмём в качестве Affinity — то есть все интерфейсы у нас подпадают под условие. 423 Кроме R3-R4, на котором мы настроим Attribute-Flag 0x1. Поскольку равенство не выполнится — CSPF не сможет строить кратчайший путь через этот линк. 424 425 ```text 426 Linkmeup_R1(config)#interface Tunnel4 427 Linkmeup_R1(config-if)#tunnel mpls trafаic-eng affinity 0x0 mask 0x1 428 ``` 429 430 ```text 431 Linkmeup_R3(config)#interface e0/0 432 Linkmeup_R3(config-if)#mpls trafаic-eng attribute-flags 0x1 433 ``` 434 435 И наблюдаем, как туннель пошёл в обход этого линка. 436 437  438 439 Однако при этом благополучно развалился Tunnel4. Значение Affinity по-умолчанию тоже 0x0, но маска 0xFFFF. Поэтому он тоже не вписался в перенастроенный линк R3-R4. 440 Но, мы могли бы настроить на нём маску 0x0 — не учитывать никакие биты Affinity и Attribute-Flag: 441 442 ```text 443 Linkmeup_R1(config)#interface Tunnel4 444 Linkmeup_R1(config-if)#tunnel mpls trafаic-eng affinity 0x0 mask 0x0 445 ``` 446 447 И тогда туннель поднимется, не учитывая эти ограничения. 448