Comment on page
Способы управления туннелями
Итак, у нас достаточно способов, как повлиять на путь трафика с помощью TE:
Первый самый очевидный способ — это метрики интерфейсов.
Как мы помним есть IGP-метрики, а есть TE-метрики. Вторые по умолчанию равны первым.
TE-метрика на линковых интерфейсах не только влияет на метрику туннеля с точки зрения IGP Shortcut, но и учитывается при построении LSP.
Для чего может понадобиться настраивать TE-метрику отличной от IGP? Например, есть линия с высоким значением задержки. Ей задаём бОльшее значение TE-метрики. Тогда: При построении туннелей для голосового трафика будем использовать TE-метрику, В туннелях для прочих данных — IGP.
Используется для этого команда
Router(config-if)#mpls traffic-eng administrative-weight значение TE-метрики
Чтобы указать туннелю, какую учитывать метрику:
Значение по умолчанию:
Router(config)# mpls traffic-eng path-selection metric {igp | te}
Конкретный туннель:
Router(config-if)# tunnel mpls traffic-eng path-selection metric {igp | te}
На практике мы познакомились с базовой функцией TE — возможностью строить MPLS туннели с резервированием ресурсов на всём протяжении LSP.
Но не беспокоит ли вас вот эта идея с Bandwidth? Не возвращаемся ли мы в каменный век, когда не было переподписки. Да и как вообще определять величину этого ограничения? А что делать с тем, что она плавает в течение суток на порядки?
Метод, когда мы настраиваем статическое значение требуемой полосы, называется Offline Bandwidth.
Идея в том, что есть некая программа стоимостью в трёшку на Патриарших прудах, которая по каким-то алгоритмам вычисляет для вашего трафика одну цифру, которую вам и нужно настроить на туннеле.
Полосу можно настроить для всего туннеля, как мы делали это выше на практике:
Router(config-if)#tunnel mpls traffic-eng bandwidth значение требуемой полосы
А можно для конкретного RSVP LSP:
Router(config-if)#tunnel mpls traffic-eng path-option 1 dynamic bandwidth значение требуемой полосы
Это значение может отличаться от того, что указано для туннеля и имеет более высокий приоритет.
При этом для другого LSP (path-option 2, например), значение может отличаться — мол, если уж не получается зарезервировать 8 Мб/с, давай хотя бы 5 попробуем?
У Offline Bandwidth есть два существенных минуса:
— Ручная работа, которой хороший инженер старается избегать.
— Неоптимальное использование ресурсов. Ну, назначим мы полосу в 300 Мб/с клиенту, зарезервируем на каждой линии, а на деле ему надо-то от силы 30. И только в пике, когда у него бэкапятся БД, нужно 300. Неаккуратненько.
Этот вариант практиковался на заре появления TE. Существует он и сейчас.
Однако, следуя в ногу со временем, нужно быть более гибким и податливым.
А Autobandwidth молодец.
Этот механизм отслеживает загрузку туннеля в течение определённого периода и потом адаптирует резервирование.
ТерминологияAdjust Interval — время, в течение которого маршрутизатор наблюдает за трафиком и отслеживает пики. Adjust Threshold — порог, после которого RSVP перезапрашивает резервирование.
Ближе к телу.
Например, Adjust Interval у нас 2 часа. Текущее значение зарезервированной полосы пропускания — 90 Мб/с.
Adjust Threshold — 20 Мб/с.
В первом интервале всплеск 119 Мб/с (до 119 Мб/с) — больше порога. Значит RSVP-TE пытается построить новый туннель с новыми значениями для полосы пропускания.
Во втором — 23Мб/с (до 142) — опять больше порога. Обновляем резервирование по возможности.
В третьем максимальное значение падает до 137 Мб/с — разница только 5. Ничего не происходит.
В четвёртом всплеск падает до 116 (разница 21) — RSVP сигнализирует новый LSP с пониженными требованиями по полосе.
Так, каждые два часа будет происходить проверка и, возможно, перестроение туннелей.
Чем короче Adjust Interval, тем, соответственно, чаще будет обновляться резервирование и более рационально использоваться доступная полоса пропускания.
Примерно так при двухчасовом интервале будет выглядеть 24-часовое поведение auto-bandwidth.
Уже заметили проблему?
Возьмём типичный профиль утреннего трафика:
И такая дребедень целый день.
Вот измерили мы в 8 утра всплеск — 200 Мб/с. И два часа держится это значение для туннеля. А за это время на работу уже пришёл народ и запустил ютуб — средняя ск орость уже 240, а всплески до 300. До 10 утра будет происходить тихая деградация. Тихая, потому что ни туннель, ни Auto-Bandwidth о ней не знают. А вот пользователи знают и их ИТшник тоже знает, уж поверьте.
Если же сильно уменьшать интервал юстировки, то на сети будут постоянно пересигналзироваться новые LSP.
Для решения этой и других проблем существуют механизмы Overflow и Underflow. Первый — для слежения за ростом трафика, второй — за снижением.
Если разница между текущим резервированием и всплесками трафика превосходит порог Overflow несколько раз подряд, RSVP TE будет пробовать построить новый LSP, не дожидаясь истечения Adjust Interval.
То же и для Underflow — RSVP-TE будет пересегнализировать LSP с более низкими требованиями, если заметил тенденцию к уменьшению объёма трафика.
И остаётся только одна, но серьёзная проблема.
Так уж устроен наш мир, что когда растёт трафик у одного абонента, обычно растёт и у другого. И может так статься, что когда придёт время снова увеличить резервирование, увеличить его будет уже некуда — всё занято. И тогда, если нет других путей, удовлетворяющих новым условиям, будет использоваться старый. И никому не будет дела до того, что его уже не хватает, что пакеты начали теряться, что клиент ищет номер директора, чтобы найти инженера, которому можно оторвать что-нибудь лишнее.
Для включения функции AutoBandwidth глобально и одновременно настройки Adjust Interval:
Router(config)#mpls traffic-eng auto-bw timers frequency [sec]
Далее для каждого туннеля отдельно нужно активировать AutoBandwidth. При этом можно задать другое значение для Adjust Interval, а также установить минимально и максимально возможные значения для резервируемой полосы.
Router(config)#tunnel mpls traffic-eng auto-bw max-bw Значение min-bw Значение
Для настройки Overflow:
Router(config)#tunnel mpls traffic-eng auto-bw [overflow-limit количество раз overflow-threshold Процент изменения]
Это механизм, который приоритезирует туннели: какой из них важнее. Он применим, как для случая Auto-Bandwidth в частности, так и для любого построения RSVP LSP вообще.
Всё предельно логично:
Setup Priority — приоритет установки RSVP LSP.
Hold Priority — приоритет удержания RSVP LSP.
Если полосы пропускания не хватает на узле, и у нового туннеля приоритет установки выше, чем приоритет удержания у старого, новый будет построен — старый сломан.
Оба имеют 8 значений: от 0 до 7. Для обоих 0 — это наивысший, 7 — наинизший.
Например, у нас есть туннель LSP1, у которого Hold priority 4.
Тут приходит запрос от RSVP-TE на LSP2 с Setup Priority 6 и Hold Priority тоже 6. Если полосы пропускания достаточно, то он просто построится. Если нет — то маршрутизатор не даст этого сделать — потому что уже существующий туннель приоритетнее нового (4>6).
Допустим, полосы достаточно и оба туннеля поднялись нормально.
И тут приходит новый запрос на LSP3 с Setup/Hold Priority 5. Это выше, чем у LSP2, но ниже, чем у LSP1. И ему полосы уже не хватает. LSP1 точно не будет тронут, потому что его Hold приоритет до сих пор самый высокий. И тогда есть два варианта:
- 1.Если сломать LSP2, полосы хватает для LSP3. В этом случае Setup приоритет LSP3 выше, чем Hold LSP2. Ingress PE LSP2 узнаёт, что его LSP вероломно разломали и будет искать новый путь — его удача, если он найдёт.
- 2.Если сломать LSP2, полосы всё равно не хватит для LSP3. LSP1 маршрутизатор не отдаст. И тогда LSP1 и LSP2 остаются, а Ingress PE LSP3 будет искать другие возможности для самореализации.
Касательно значений — обычно выбираются одинаковые для Setup и Hold. И не стоит настраивать Hold ниже, чем Setup. Во-первых это не логично. Во-вторых, может случиться ситуация, когда два туннеля войдут в петлю, когда они будут постоянно перебарывать друг друга — как только установится один, второй его сломает и построится сам, потом первый сломает второй итд.
Существует два режима замещения туннелей:
Hard preemption — LSP с более высоким приоритетом просто замещает LSP с низким. Даже если потом LSP с низким приоритето м найдёт новый путь, часть трафика будет потеряна.
Soft preemption — применяется механизм Make-Before-Break. Маршрутизатор через RSVP-TE сообщает Ingress LSR низкоприоритетного LSP, что нужно искать новый путь. LSP с высоким приоритетом ожидает, пока трафик низкоприоритетного LSP переключится на новый LSP.
При этом, если путь найти не удалось в течение некоторого времени, низкоприоритетный LSP всё равно ломается и строится высокоприоритетный.
Данные о приоритетах замещения пере даются в RSVP-TE PATH и учитываются при резервировании ресурсов на промежуточных узлах.
Если вы обратили внимание, то после настройки tunnel mpls traffic-eng badnwidth на туннельном интерфейсе, в конфигурации автоматически появляется строка tunnel mpls traffic-eng priority 7 7.
Дело в том, что без требований по полосе приоритеты не имеют никакого значения — через один узел можно проложить ско лько угодно туннелей — ведь полоса не резервируется — и команды нет.
Но, как только появилось требование, по полосе, приоритеты начинают играть роль.
7 — это значение по умолчанию — наименьшее.
Давайте на Linkmeup_R1 настроим новый туннель до 4.4.4.4 с более высоким приоритетом?
Linkmeup_R1(config)#interface Tunnel42
Linkmeup_R1(config-if)#ip unnumbered Loopback0
Linkmeup_R1(config-if)#tunnel mode mpls traffic-eng
Linkmeup_R1(config-if)#tunnel destination 4.4.4.4
Linkmeup_R1(config-if)#tunnel mpls traffic-eng priority 4 4
Linkmeup_R1(config-if)#tunnel mpls traffic-eng bandwidth 4000
Linkmeup_R1(config-if)#tunnel mpls traffic-eng path-option 1 dynamic
Необходимая полоса всего 4Мб/с. Поэтому туннель должен пройти по пути R1->R2->R3->R4.
Так и есть, вот его трассировка:
С Tunnel4 у них только один общий линк R3->R4, но его полоса пропускания только 10. А двум туннелям нужно 8+4=12.
Tunnel42 с приоритетом установки 4 выдавливает Tunnel4 с приоритетом удержания 7.
И тому приходится искать новый путь.
И он находится:
Сначала удаляется старый RSVP LSP Tunnel4 и сигнализируется новый по доступному пути
Потом RSVP-TE сигнализирует LSP для Tunnel42.
В этот момент вернёмся к Autobandwidth. Именно связка Tunnel priority + Autobandwidth даёт элегантное решение.
Одним ранним утром было трафика мало, autobandwidth подсчитал сколько именно его в каждом туннеле, и TE везде хватило пропускной способности.
Потом ближе к обеду трафик подрос, autobandwidth адаптировался, перерезервировал новые полосы — всё ещё хватает.
К вечеру один за другим туннели начинают вылетать, потому что TE не может зарезервировать новую полосу.
И тут важно, чтобы туннели жирных клиентов, IP-телефонии и канал для МВД никогда не падали. Тогда задаём для этих туннелей Hold priority выше, чем Setup priority других.
— При попытке низкоприоритетных зарезервировать новую полосу на интерфейсе, где её уже не хватает, он обломится.
— Высокоприоритетный наоборот вытеснит низкоприоритетный и займёт освободившуюся полосу.
Получается, что
- без Autobandwidth мы либо настраиваем требования полосы вручную на всей сети, либо вообще не делаем этого, пуская на самотёк,
- без Autobandwidth мы никогда не знаем, сколько реально трафика в туннеле,
- без Autobandwidth мы никак не можем его ограничить,
- без Tunnel priority мы не можем сказать наверняка, какие туннели пострадают.
Как вы помните, CSPF вычисляет кратчайший путь с учётом ограничений. Далее этот путь трансформируется в объект ERO (Explicit Route Object) сообщения RSVP-TE PATH, который явно сообщает, по какому пути этот PATH нужно передать.
Так вот если, вы хотите, чтобы какие-то узлы обязательно присутствовали или наоборот отсутствовали в этом пути, можно это явно указать в Explicit-Path, который станет одним из входных ограничений для CSPF.
Итак, мы вручную задаём, через какие узлы должен пролечь LSP, а через какие не должен.
RSVP-TE просит CSPF рассчитать маршрут с учётом Explicit-Path и других ограничений туннеля.
Если одно входит в противоречие с другим — беда, не будет LSP.
Explicit-Path — это строго локальное ограничение — только Ingress LSR о нём знает и не передаёт ни в анонсах IGP, ни в сообщениях RSVP-TE.
Настройка Explicit-path выполняется в два этапа:
1) Создание самого explicit-path с ограничениями:
Router(config)# ip explicit-path name Имя
Router(cfg-ip-expl-path)# next-address IP-адрес
Router(cfg-ip-expl-path)# exclude-address IP-адрес
...
2) Применение его к path-option на туннеле:
Router(config-if)#tunnel mpls traffic-eng path-option 1 explicit name Имя
SRLG — Shared Risk Link Group. Ещё один способ повлиять на LSP и отличная идея против плоских колец.
Задача этой функции предотвратить построение основного и резервного LSP через линии, которые могут повредиться одновременно.
Например, два волокна, которые физически проходят в одном кабеле, наверняка порвутся одним и тем же ковшом экскаватора.
SRLG-группа — группа интерфейсов, которые «разделяют риск». О! Группа риска.
Вручную (конечно, а как иначе маршрутизатор узнает, что это физически идентичные линии) настраиваются интерфейсы, которые являются членами одной SRLG-группы.
Информация о SRLG распространяется по сети вместе с анонсами IGP, как и доступная полоса или значение Attribute-Flag, и помещается потом в TEDB.
Далее CSPF должен учитывать эту информацию при расчёте кратчайших маршрутов.
Имеется два режима:
Force Mode заставляет CSPF учитывать данные SRLG обязательно — если иного пути нет, то резервный LSP не будет построен вообще.
Preffered Mode допускает построение запасных туннелей через SRLG-линии, если нет иных возможностей.
Режим задаётся на Ingress LSR.
Для добавления интерфейсов в одну группу риска на любых узлах вводится команда:
Router(config-if)# mpls traffic-eng srlg номер группы
А на Ingress PE включить проверку SRLG:
Router(config)# mpls traffic-eng auto-tunnel backup srlg exclude force/preffered
Вот сейчас должно стать страшно. Мне страшно.
Итак, к данному моменту мы узнали про четыре инструмента управления трафиком:
RFC3630 для OSPF, а для ISIS определяют TLV для Administrative Group, который передаётся IGP вместе с другими характеристиками линиями.
Пока вы не согнулись под тяжестью знаний, расскажу вам такую историю. Огромнейшая сеть linkmeup. Своя оптика, свои РРЛ пролёты, куски лапши, доставшиеся от купленных домонетов, куча арендованных каналов у разных операторов. И через всё это хозяйство MPLS, хуже того — TE-туннели. И для разных сервисов важно, чтобы они шли определённым путём. Например, трафик 2G ни в коем случае не должен идти через РРЛ-пролёты — проблемы с синхронизацией нас съедят. Трафик ШПД нельзя пускать через линии Балаган Телеком, потому что эти паразиты из 90-х берут деньги за объём пропущенного трафика. Разрешать строить туннели через сети доступа вообще запрещено категорически. И с этим нужно что-то делать.
Каждый раз, настраивая туннель, учитывать в Explicit Path все эти детали — с ума можно сойти.
Но, новая связка — удивительное спасение, которое решит все наши проблемы, просто нажмите кнопку «сделать хорошо».
Идея в том, что каждый интерфейс мы помечаем определёнными цветами.
А потом говорим, что вот этот туннель может идти по красным и фиолетовым линиям, но не может по зелёным, жёлтым и коричневым.
Marketing Bullshit! Непонятно? Мне тоже.
Итак.
Administrative Group (у Juniper: admin-group, у Cisco: Attribute-Flag) — это атрибут физического интерфейса, который может о писать 32 его дискретных характеристики.
Какой бит из 32 за что отвечает решает оператор самостоятельно.
Раз уж примеры у нас в консоли Cisco, то далее буду использовать термин Attribute-Flag наравне с Administrative group, что не совсем правильно.
Например, считаем с наименее значимых битов (с конца): первый бит в 1 означает, что это оптика второй бит в 1 означает, что это РРЛ третий бит в 0 означает, что это линия в сторону сети доступа, а 1 — магистральный интерфейс. четвёртый бит в 1 означает, что это аренда пятый бит в 1 означает, что это Балаган-Телеком шестой бит в 1 означает, что это Филькин-Сертификат седьмой бит в 1 означает, что это канал через интернет без гарантий. … десятый бит в 1 означает, что полоса пропускания меньше 500 Мб/с итд. я так могу все 32 утилизировать.
Affinity и маска — это требования туннеля к своему пути.
Какие отношения могут сложиться в этом треугольнике {Affinity, Mask, Attribute-Flag}?
(AFFINITY && MASK) == (ATTRIBUTE && MASK)
Если это равенство выполняется, туннель можно строить через этот интерфейс.
Рассмотрим на примере.
У нас есть 32 бита и политика — за что отвечает каждый из них (возьмём пример выше).
В Mask мы указываем, какие характеристики канала нас интересуют. Например, для туннеля с трафиком 2G важно
- 1.РРЛ это или нет
- 2.Магистральная линия или в сторону сегмента доступа
- 3.Канал через интернет или нет
Поэтому в маске выставляем 1 там, где важно, что стоит:
В Affinity мы указываем, что именно нам нужно.
- 1.Чтобы это не был РРЛ (0)
- 2.Чтобы это был магистральный линк (1)
- 3.Канал не через интернет (0)
Affinity: 0000 0100.
Выполняем операцию и получаем: 0000 0100.
Теперь возьмём для примера три интерфейса.
- 1.Attribute-Flag 0000 0100 — Не РРЛ, магистральный и не через Интернет. Attribute-Flag && Mask = 0000 0100 = Affinity && Mask — сюда можно пускать трафик.
- 2.Attribute-Flag 0100 0000 — Не РРЛ, но в сторону сегмента доступа, да ещё и через интернет. Attribute-Flag && Mask = 0100 0000 ≠ Affinity && Mask — сюда нельзя пускать трафик.
- 3.Attribute-Flag 0000 0101 — Оптика, не РРЛ, магистральный и не через Интернет. Attribute-Flag && Mask = 0000 0100 = Affinity && Mask — сюда можно пускать трафик. Не важно, оптика или нет — результат тот же.
То есть при построении LSP на каждом линке будет учитываться значение Attribute-Flag.
По умолчанию значение Attribute-Flag на интерфейсе — 0x0. И в некотором смысле — это прискорбно — ведь результат операции «И» с маской будет отличаться от результата с Affinity, а значит мы должны настроить Attribute-Flag на всех интерфейсах.
Соответственно, в пределах компании можно выработать политики, как помечать интерфейсы и как управлять трафиком. Можно возложить эту задачу даже на систему управления, чтобы работа инженера сводилась к расстановке галочек в графическом интерфейсе, а конфигурация затем применялась бы автоматически.
Но в любом случае это не умаляет человеческого фактора с одной стороны и просто непостижимой сложности отладки и обслуживания с другой.
Однако случаи комплексного внедрения Administrative Group даже на сетях российиских операторов имеются.
Другим примеров использования могли бы быть коды регионов или стран. Тогда можно было бы задавать через какую географию пропускать трафик.
В этом свете 32 бита оказывается очень мало, поэтому RFC 7308 определяет расширенные административные группы, количество бит в которых ограничено естественым пределом LSA или вообще MTU.
Очень очень короткая.
Просто посмотрим, что работает.
Короткая, потому что применение Affinity требует настройки Attribute-Flag на всех узлах и всех интерфейсах. А это то, чего меньше всего хочется, если честно.
Продолжаем с последней конфигурации, где у нас два туннеля.
Файл конфигурации.
Tunnel42 идёт по пути R1-R2-R3-R4. С ним и поиграем.
Значение Attribute-Flag по умолчанию 0x0. Поэтому его и возьмём в качестве Affinity — то есть все интерфейсы у нас подпадают под условие.
Кроме R3-R4, на котором мы настроим Attribute-Flag 0x1. Поскольку равенство не выполнится — CSPF не сможет строить кратчайший путь через этот линк.
Linkmeup_R1(config)#interface Tunnel4
Linkmeup_R1(config-if)#tunnel mpls trafаic-eng affinity 0x0 mask 0x1
Linkmeup_R3(config)#interface e0/0
Linkmeup_R3(config-if)#mpls trafаic-eng attribute-flags 0x1
И наблюдаем, как туннель пошёл в обход этого линка.
Однако при этом благополучно развалился Tunnel4. Значение Affinity по-умолчанию тоже 0x0, но маска 0xFFFF. Поэтому он тоже не вписался в перенастроенный линк R3-R4.
Но, мы могли бы настроить на нём маску 0x0 — не учитывать никакие биты Affinity и Attribute-Flag:
Linkmeup_R1(config)#interface Tunnel4
Linkmeup_R1(config-if)#tunnel mpls trafаic-eng affinity 0x0 mask 0x0
И тогда туннель поднимется, не учитывая эти ограничения.
Last modified 4yr ago