Сети Для Самых Маленьких
  • Сети для самых маленьких
  • 0. Планирование
    • 0. Документация сети
    • 1. Схемы сети
    • 2. IP-план
    • 3. Список VLAN
    • 4. План подключения оборудования по портам
    • 5. Заключение
  • 1. Подключение к оборудованию cisco
    • 0. Среда
    • 1. Способы подключения
    • 2. Управление по консоли
    • 3. Первичная настройка
    • 4. Настройка доступа
    • 5. Сброс пароля
  • 2. Коммутация
    • Теория
      • СКС, ЛВС, LAN
      • IP-адресация
      • Широковещательный домен
      • OSI
      • Путь пакета
      • VLAN
      • FAQ
    • Практика
      • Порты доступа (access)
      • Транковые порты (trunk)
      • Сеть управления и первичная настройка
      • Резюме
  • 3. Статическая маршрутизация
    • InterVlan Routing
    • Планирование расширения
    • Принципы маршрутизации
    • Настройка
    • Дополнительно
    • Материалы выпуска
  • 4. STP
    • Широковещательный шторм
    • STP
    • RSTP
    • MSTP
    • Агрегация каналов
    • Port security
    • Практика
    • Материалы выпуска
  • 5. ACL и NAT
    • Access Control List
      • Практика
    • NAT
      • Практика
    • Материалы выпуска
    • Бонусы
    • Спасибы
  • 6. Динамическая маршрутизация
    • Теория протоколов динамической маршрутизации
    • OSPF
      • Теория
      • Теория-2
      • Практика OSPF
      • Задача 1
      • Практика. Продолжение
      • Задача 2
      • Задача 3
    • EIGRP
      • Теория
      • Практика
      • Задача 4
    • Настройка передачи маршрутов между различными протоколами
    • Задача 5
    • Маршрут по умолчанию
    • Задача 6
    • Полезные команды для траблшутинга
    • Задача 7
    • Материалы
    • Полезные ссылки
  • 7. VPN
    • Введение в VPN
    • GRE
      • Абстрактная топология
      • Настройка
      • Механизм работы протокола
      • Итого
    • IPSec
      • Теория
        • Security Association
        • Трансформ-сет
      • Режимы работы IPSec
        • Туннельный режим работы IPSec
        • Практика
          • Настройка на локальной стороне
          • Настройка на обратной стороне
          • Настройка. Завершение
        • Задача 1
        • Теория
        • Задача 2
        • Транспортный режим работы IPSec
        • Задача 3
    • GRE over IPSec
      • Практика
      • Теория
      • Задача 4
      • Задача 5
    • IPSec VTI
    • DMVPN
      • Теория и практика DMVPN
      • OSPF
        • Практика
        • Теория
      • IPSec
      • NAT-Traversal
      • Задача 6
    • TShoot IPSec
    • MTU
    • Материалы выпуска
    • Полезные ссылки
  • 8. BGP и IP SLA
    • Автономные системы
    • PI и PA адреса
    • BGP
      • Теория
      • Установление BGP-сессии и процедура обмена маршрутами
      • Настройка BGP и практика
        • Настройка BGP и практика
        • Задача 1
        • Full View и Default Route
        • Задача 2
        • Looking Glass и другие инструменты
        • Control Plane и Data Plane
        • Выбор маршрута
        • Задача 3
      • Управление маршрутами
        • AS-Path ACL
        • Prefix List
        • Route Map
        • Задача 4
      • Балансировка и распределение нагрузки
        • Балансировка нагрузки
        • Задача 5
        • Распределение нагрузки
          • Исходящий
          • Задача 6
          • Входящий
        • AS-Path Prepend
        • MED
        • Анонс разных префиксов через разных ISP
        • BGP Community
        • Задача 7
        • Общая таблица по видам балансировки и распределения нагрузки
    • PBR
      • Теория
      • PBR
      • Практика
      • Задача 8
    • IP SLA
      • Настройка
      • Задача 9
      • Задача 10
    • Полезные ссылки
  • 8.1 IBGP
    • IBGP
    • Различия IBGP и EBGP
    • Проблема Эн квадрат
      • Route Reflector
        • Правила работы RR
        • Практика RR
          • Проблема резервирования
      • Конфедерации
    • Атрибуты BGP
      • Хорошо известные обязательные (Well-known Mandatory)
      • Хорошо известные необязательные (Well-known Discretionary)
      • Опциональные передаваемые/транзитивные (Optional Transitive)
      • Опциональные непередаваемые/нетранзитивные (Optional Non-transitive)
      • Community
        • Теория Community
        • Задача 7
        • Практика Community
        • Задача 8
        • Задача 9
      • Задача 6
    • Материалы выпуска
    • Задача 1
    • Задача 2
    • Практика
      • EBGP
      • iBGP
      • iBGP
      • Задача 3
      • Настройка внутренней маршрутизации. OSPF
      • Настраиваем BGP
      • Задача 4
      • Что мы можем улучшить?
      • Задача 5
      • Задача 6
      • Задача 7
      • Задача 8
      • Задача 9
    • Послесловие
  • 9. Multicast
    • Общее понимание Multicast
      • Пример I
      • Пример II
    • IGMP
      • Теория IGMP
      • Querier
      • Ещё пара слов о других версиях IGMP
      • Повторим ещё раз
      • И ещё раз
    • PIM
      • PIM Dense Mode
      • PIM Sparse Mode
      • Чтобы разобраться с тем, что такое PIM, обратимся к сети гораздо более сложной
      • Разбор полётов
        • RP
        • Бритва Оккама или отключение ненужных ветвей
        • SPT Switchover — переключение RPT-SPT
        • Задача 1
        • Задача 2
      • DR, Assert, Forwarder
      • Выбор RP
      • Завершение
    • SSM
    • BIDIR PIM
    • Мультикаст на канальном уровне
      • Мультикастовые MAC-адреса
      • IGMP Snooping
      • Задача 3
      • IGMP Snooping Proxy
      • Multicast VLAN Replication
    • Заключение
  • 10. Базовый MPLS
    • Что не так с IP?
    • Заголовок MPLS
    • Пространство меток
    • Что такое MPLS
    • Передача трафика в сети MPLS
    • Терминология
    • Распространение меток
      • Методы распространение меток
        • DU против DoD
        • Ordered Control против Independent Control
        • Liberal Label Retention Mode против Conservative Label Retention Mode
        • PHP
      • Протоколы распространения меток
        • LDP
          • Практика
        • Применение чистого MPLS в связке с BGP
        • RSVP-TE
          • Практика
    • ВиО
    • Полезные ссылки
    • Спасибы
  • 11. MPLS L3VPN
    • VRF, VPN-Instance, Routing Instance
      • VRF-Lite
    • MPLS L3VPN
      • Data Plane или передача пользовательских данных
      • Роль меток MPLS
        • Транспортная метка
        • Сервисная метка
      • Терминология
      • Control Plane или передача служебной (маршрутной) информации
      • Протоколы маршрутизации
      • MBGP
        • Route Distinguisher
        • Route Target)
    • Практика
      • VRF-Lite
      • MPLS L3VPN
      • Взаимодействие между VPN
    • Трассировка в MPLS L3VPN
    • Доступ в Интернет
      • NAT на CE
        • Практика
        • Теория
        • Повторим шаги настройки
      • VRF Aware NAT
        • Практика
        • Теория
      • Common Services
    • ВиО
    • Полезные ссылки
  • 12. MPLS L2VPN
    • О технологиях L2VPN
    • VPWS
      • Data Plane
      • Control Plane
      • Практика
      • Теория
      • Виды VPWS
    • VPLS
      • Data Plane
      • Control Plane
      • VPLS Martini Mode (targeted LDP)
        • Практика
        • Теория
      • VPLS Kompella Mode (BGP)
        • Обнаружение соседей или Auto-Discovery
        • Передача префиксов
        • Распределение меток и механизм Label Block
        • Практика
        • Теория
      • Martini vs. Kompella
      • Иерархический VPLS (H-VPLS)
        • Практика H-VPLS
        • Теория
    • Проблемы VPLS
    • Полезные ссылки
    • Спасибы
  • 12.1. MPLS EVPN
    • Вспоминаем VPLS
    • Базовая часть технологии EVPN
    • Лаборатория для тестов и конфигурации
    • Маршруты EVPN
      • Маршрут типа 3 (Inclusive Multicast Ethernet Tag Route)
      • Маршрут типа 2 (MAC/IP Advertisement Route)
        • Изучение MAC-адресов
      • Маршрут типа 1 (Ethernet Auto-Discovery Route)
        • Автоматический поиск multihomed PE и ESI label
        • MAC Mass Withdrawal
        • Aliasing label
      • Маршрут типа 4 (Ethernet Segment Route)
        • Механизм выбора DF
    • L3-функционал в EVPN
      • IRB synchronisation
      • Маршрутизация между bridge-доменами
      • Выход в другие VRF и внешние сети
    • Зачем это всё-таки нужно?
    • Заключение
  • 12.2. EVPN Multihoming
    • Практический пример
    • Проблемы Multihoming-га.
    • Что такое DF и зачем он нужен?
    • Зачем нужен маршрут типа 1 per-ESI?
    • Зачем нам маршрут типа 1, сгенерированный per-EVI?
    • А нужен ли нам MC-LAG в EVPN?
    • Заключение
  • 13. MPLS Traffic Engineering
    • Предпосылки появления MPLS TE
    • Принципы работы MPLS Traffic Engineering
    • Способы направления трафика в TE-туннель
    • Способы управления туннелями
  • 14. Packet Life
    • 0. Коротко о судьбе и пути пакета
    • 1. Уровни и плоскости
      • Forwarding/Data Plane
      • Control Plane
      • Management Plane
      • Краткий итог
    • 2. История способов обработки трафика
      • Что с тобой не так, IP?!
      • О дивный новый мир
    • 3. Типов-чипов
      • CPU — Central Processing Unit
      • RAM — Random Access Memory
      • CAM — Content-Addressable Memory
      • TCAM — Ternary Content-Addressable Memory
      • ASIC — Application Specific Integrated Circuit
      • Programmable ASIC
      • FPGA — Field Programmable Gate Array
      • NP — Network Processor
    • 4. Аппаратная архитектура коммутирующего устройства
      • Общая шина
      • Управляющий модуль
      • Интерфейсный модуль или линейная карта
        • PIC — Physical Interface Card
        • FE — Forwarding Engine
        • QoS или TM — Traffic Management
        • SerDes — Serializer, Deserializer
        • Распределённая плоскость управления (Distributed Control Plane)
      • Фабрика коммутации
    • 5. Путешествие длиною в жизнь
      • Транзитные пакеты
      • Локальные пакеты
    • Заключение
    • Спасибы
  • 15. QoS
    • 0. Чем определяется QoS?
      • Потери
      • Задержки
      • Джиттер
      • Неупорядоченная доставка
      • Полоса пропускания
    • 1. Три модели обеспечения QoS
      • Best Effort (BE)
      • IntServ
      • DiffServ
    • 2. Механизмы DiffServ
    • 3. Классификация и маркировка
      • Behavior Aggregate
      • Interface-based
      • Multi-Field
      • Маркировка внутри устройства
      • Рекомендации IETF (категории трафика, классы сервиса и модели поведения)
      • Короткий итог по классификации
    • 4. Очереди
    • 5. Предотвращение перегрузок
      • Tail Drop и Head Drop
      • RED — Random Early Detection
      • WRED — Weighted Random Early Detection
    • 6. Управление перегрузками
      • FIFO — First In, First Out
      • PQ — Priority Queuing
      • FQ - Fair Queuing
      • RR — Round-Robin
      • Короткий итог про механизмы диспетчеризации
    • 7. Ограничение скорости
      • Traffic Policing
      • Traffic Shaping
      • Шейпинг против полисинга
      • Практика Полисинг и шейпинг
      • Механизмы Leaky Bucket и Token Bucket
        • Алгоритм Leaky bucket
        • Алгоритм Token Bucket
      • Короткий итог по ограничению скорости
    • 8. Аппаратная реализация QoS
    • Полезные ссылки
    • Спасибы
  • Инструкция для контрибьютеров
Powered by GitBook
On this page
  • Метрика пути MPLS TE
  • Ограничение по полосе пропускания
  • Offline Bandwidth
  • Auto-Bandwidth
  • Приоритеты туннелей
  • Практика
  • Explicit-Path
  • SRLG
  • Administrative Groups или Affinity
  • Практика
  1. 13. MPLS Traffic Engineering

Способы управления туннелями

PreviousСпособы направления трафика в TE-туннельNext14. Packet Life

Last updated 5 years ago

Итак, у нас достаточно способов, как повлиять на путь трафика с помощью TE:

Метрика пути MPLS 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

Метод, когда мы настраиваем статическое значение требуемой полосы, называется 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. Существует он и сейчас. Однако, следуя в ногу со временем, нужно быть более гибким и податливым.

Auto-Bandwidth

А 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 мы не можем сказать наверняка, какие туннели пострадают.

Explicit-Path

Как вы помните, 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

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

Administrative Groups или Affinity

Вот сейчас должно стать страшно. Мне страшно.

Итак, к данному моменту мы узнали про четыре инструмента управления трафиком:

Пока вы не согнулись под тяжестью знаний, расскажу вам такую историю. Огромнейшая сеть 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.

Теперь возьмём для примера три интерфейса.

То есть при построении LSP на каждом линке будет учитываться значение Attribute-Flag. По умолчанию значение Attribute-Flag на интерфейсе — 0x0. И в некотором смысле — это прискорбно — ведь результат операции «И» с маской будет отличаться от результата с Affinity, а значит мы должны настроить Attribute-Flag на всех интерфейсах.

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

Однако случаи комплексного внедрения Administrative Group даже на сетях российиских операторов имеются.

Практика

Очень очень короткая. Просто посмотрим, что работает. Короткая, потому что применение Affinity требует настройки Attribute-Flag на всех узлах и всех интерфейсах. А это то, чего меньше всего хочется, если честно.

Значение 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

И тогда туннель поднимется, не учитывая эти ограничения.

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

Подробнее о Auto-Bandwidth можно почитать в очень .

Идея Explicit-Path более чем полно была раскрыта в .

SRLG — Shared Risk Link Group. Ещё один способ повлиять на LSP и отличная идея против . Задача этой функции предотвратить построение основного и резервного LSP через линии, которые могут повредиться одновременно. Например, два волокна, которые физически проходят в одном кабеле, наверняка порвутся одним и тем же ковшом экскаватора.

Что это за команда, поговорим в разделе .

для OSPF, а для ISIS определяют TLV для Administrative Group, который передаётся IGP вместе с другими характеристиками линиями.

Mask: 0100 0110 Взяли только первые 8 бит для простоты. Заметьте, что это .

Attribute-Flag 0000 0100 — Не РРЛ, магистральный и не через Интернет. Attribute-Flag && Mask = 0000 0100 = Affinity && Mask — сюда можно пускать трафик.

Attribute-Flag 0100 0000 — Не РРЛ, но в сторону сегмента доступа, да ещё и через интернет. Attribute-Flag && Mask = 0100 0000 ≠ Affinity && Mask — сюда нельзя пускать трафик.

Attribute-Flag 0000 0101 — Оптика, не РРЛ, магистральный и не через Интернет. Attribute-Flag && Mask = 0000 0100 = Affinity && Mask — сюда можно пускать трафик. Не важно, оптика или нет — результат тот же.

Другим примеров использования могли бы быть коды регионов или стран. Тогда можно было бы задавать через какую географию пропускать трафик. В этом свете 32 бита оказывается очень мало, поэтому определяет расширенные административные группы, количество бит в которых ограничено естественым пределом LSA или вообще MTU.

Парень на пальцах и в рот стопочкой складывает.

Продолжаем с последней конфигурации, где у нас два туннеля. Tunnel42 идёт по пути R1-R2-R3-R4. С ним и поиграем.

Метрика пути MPLS TE
Ограничение по полосе пропускания
Explicit-Path
SRLG
Administrative Groups/Affinity
Как мы помним
Cisco подробно про метрики
ниже
честном документе
10-м выпуске СДСМ
плоских колец
FRR
Метрика MPLS TE.
Требования к полосе пропускания канала и приоритет замещения.
Explicit-path.
SRLG.
RFC3630
Wildcard Mask
RFC 7308
разжёвывает Affinity
Файл конфигурации.