Сети для самых матёрых. Часть тринадцатая. MPLS Traffic Engineering25.09.2017 17:33

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

Однако сеть linkmeup выросла до размеров федерального оператора. Возможность управления трафиком и быстрого восстановления сервисов стали очень важным требованием в MPLS-сети.
Пора внедрять Traffic Engineering.

7905261bcc814c89928efb9f2a93df51.jpg

Содержание выпуска:
  • Предпосылки появления MPLS TE
  • Принципы работы MPLS TE
  • Способы направления трафика в TE-туннели
  • Способы управления туннелями
    • Метрики
    • Ограничения по полосе пропускания
    • Приоритеты туннелей
    • Explicit-Path
    • SRLG
    • Affinity и Attribute-Flag

  • Обеспечение надёжности и сходимость
    • Path Protection
    • Local Protection — Fast ReRoute
  • MPLS QoS
    • MPLS TE IntServ
    • MPLS TE DiffServ
    • Режимы работы MPLS QoS
  • Упрощение настройки туннелей
  • Заключение
  • Полезные ссылки



Зачем вообще может понадобиться инжиниринг трафика?


Приведу простой пример.
Конвергентная сеть мобильного оператора.

7f06de08484e4acea0a89dc61a06659c.png

Два типа трафика:

  • Мобильный
  • ШПД


Левое плечо — широкий оптический канал 10G. Правое — резерв через арендованную линию — 1G.
Общий объём трафика — 2,5 Гб/с, мобильного: 800 Мб/с.
В случае разрыва основного канала, нужно переключить на резервный только мобильный трафик и сделать это за 50 мс.

Подумайте, можем ли мы сделать это стандартными средствами? Разделить трафик разных сервисов разными VPN, безусловно, можем, но направить разными маршрутами — нет.

Без использования ТЕ весь трафик перенаправится в правое плечо, а там, кто бы мог предположить, не хватает пропускной способности — начнутся отбрасывания.

Кроме того, скорость сходимости OSPF или ISIS даже при использовании BFD исчисляется десятками мс, но после этого ещё и транспортные LSP должны перестроиться. В наши дни это уже не пройдёт незамеченным для абонентов.

Принципы работы MPLS Traffic Engineering
Какие же функции по управлению трафиком предоставляет MPLS Traffic Engineering?

  • Расширяет возможности стандартных IGP, позволяя маршрутизировать трафик разных классов разными способами.
  • Передаёт трафик через сеть, используя коммутацию MPLS, что означает поддержку всяческих VPNов.
  • При построении маршрута учитывает заданные ограничения, например, какие ресурсы необходимы этому классу трафика и сколько их доступно на всех узлах и линиях по пути, или по каким линиям нельзя строить туннели.
  • Быстрое перестроение путей в соответствии с требованиями в случае аварии.
  • Периодическая оптимизация путей.


Базовые механизмы работы MPLS TE были рассмотрены в выпуске СДСМ 10, куда я вас и шлю за подробным рассмотрением. А здесь приведу лишь короткую сводку.


Data Plane


С точки зрения передачи данных TE несколько отличается от LDP. Жирным выделены отличия:

  1. В TE-туннель трафик нужно поместить насильно, тогда как в LDP он попадает автоматически
    Juniper здесь — исключение.
  2. Первый маршрутизатор навешивает внешнюю MPLS-метку (PUSH LABEL)
  3. Транзитные маршрутизаторы смотрят на какой интерфейс поступил пакет и значение метки и, поменяв её на новую согласно таблице меток, отправляют её в выходной интерфейс (SWAP LABEL)
  4. Предпоследний маршрутизатор снимает транспортную метку (POP LABEL, PHP — зависит от реализации и настроек)
  5. В случае обрыва на пути трафик можно спасти путём перенаправления пакетов в заранее подготовленный туннель.



Control Plane


А вот в плане управления отличия гораздо более значительные. C ними всю оставшуюся дорогу и будем разбираться.

Терминология
LSP — Label Switched Path — вообще говоря, любой путь через сеть MPLS, но порой подразумевают LDP LSP. Однако мы не будем столь категоричны — при необходимости я буду указывать, что имею в виду именно LDP LSP.
RSVP LSP — соответственно LSP, построенный с помощью RSVP TE с учётом наложенных ограничений. Может также иногда называться CR-LSP — ConstRaint-based LSP.
Туннелем мы будем называть один или несколько MPLS LSP, соединяющих два LSR-маршрутизатора. Метка MPLS — это по сути туннельная инкапсуляция.
В случае LDP — каждый LSP — это отдельный туннель.
В случае RSVP туннель может состоять из одного или нескольких LSP: основной, резервный, best-effort, временный.
Говоря TE-туннель, мы будем подразумевать уже конкретно MPLS Traffic Engineering туннель, построенный RSVP-TE.
TEDB — Traffic Engineering Data Base — тот же LSDB протоколов IS-IS/OSPF, но с учётом ресурсов сети, которые интересны модулю TE.
CSPF — Constrained Shortest Path First — расширение алгоритма SPF, которое ищет кратчайший путь с учётом наложенных ограничений.

Итак, MPLS TE хочет строить LSP с учётом требуемых ресурсов и пожеланий оператора, поэтому столь простой LDP с его лучшим маршрутом тут не у дел.

И его место занимает RSVP-TE — наследник отвергнутого стеком TCP/IP протокола RSVP.
TE работает в тесном симбиозе с IGP. Хотя правильнее это называть паразитизмом. Он вынуждает их (OSPF или IS-IS) служить себе: переносить нужную ему информацию и тем самым наполнять TEDB.

Процесс выглядит следующим образом:

  1. IGP собирает со всей сети информацию:
     — о линиях и сетях,
     — о метриках,
     — о доступных ресурсах,
     — о характеристиках линий.
    И заполняет TEDB, где всё это отражено.
  2. Когда RSVP-TE хочет построить LSP до какого-то узла, он просто обращается к CSPF и говорит: «Хочу кратчайший маршрут до точки G с вот этими ограничениями». Ограничения могут быть следующими:
     — требуемая полоса пропускания,
     — определённый путь или линии,
     — характеристики линии.
  3. Из запроса RSVP-TE CSPF берёт ограничения, а из TEDB — реальную информацию о сети. И выдаёт маршрут… или не выдаёт, если ограничения удовлетворить не удалось.
  4. Когда маршрут получен, RSVP-TE отправляет RSVP PATH в эту точку G с запросом на резервирование ресурсов.
  5. А точка G возвращает RSVP RESV — так резервируются ресурсы на всём пути. И если RESV вернулся с хорошими новостями, RSVP LSP/туннель поднимается.


Всё это подробно и в красках в статье СДСМ10. А ещё там же самый простой пример на практике.

Далее мы будем ходить вокруг да около вот этой схемы:

93c32ee2c49145d4b3bb6877bd485ca3.png

У нас есть L3VPN-клиент, офисы которого подключены к Linkmeup_R1 и Linkmeup_R4.


Способы направления трафика в TE-туннель
В отличие от LDP LSP, по которым трафик бежит по умолчанию и так, в TE-туннели трафик нам нужно направить.

И есть для этого следующие способы:

  1. Статический маршрут
  2. PBR
  3. IGP Shortcut
  4. Tunnel-policy*
  5. Или всё-таки автоматом в туннель попадёт?*


Статический маршрут


Самый простой в понимании и самый сложный в обслуживании способ.

Linkmeup_R1(config) ip route 4.4.4.4 255.255.255.255 Tunnel 4


PBR


По сути тот же статический маршрут.

Linkmeup_R1(config) ip access-list extended lennut
Linkmeup_R1(config-ext-nacl)) permit ip 172.16.0.0 0.0.0.255 172.16.1.0 0.0.0.255

Linkmeup_R1(config) route-map lennut permit 10
Linkmeup_R1(configconfig-route-map) match ip address lennut
Linkmeup_R1(config-route-map) set interface Tunnel4

Linkmeup_R1(config) interface Ethernet0/3
Linkmeup_R1(config-if) ip policy route-map lennut


IGP Shortcut


Этот способ наиболее распространённый и поддерживается почти всеми производителями.
Маршрутизатор рассматривает туннель, как виртуальный интерфейс. И через этот интерфейс удалённые маршрутизаторы словно бы непосредственно подключены к локальному, а не находятся в десятках хопов. Этакая телекоммуникационная червоточина. Она и называется — shortcut — сокращённый путь.

2433d7e1e7f2aee2f249aeb19c6d2e24.jpg
Червоточина Фламма

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

С помощью IGP Shortcut (в цисконародье AutoRoute Announce) мы вынуждаем протокол маршрутизации на Ingress LSR рассматривать туннель как обычную линию — Egress LSR будто бы подключен непосредственно. А соответственно и все сети, находящиеся за Egress LSR, будут доступны через туннель.

Таким образом всё, чьей точкой назначения является этот маршрутизатор, или узлы за ним, будет отправлено в туннель. В том числе и VPN-пакеты.

7855cafef3cd49aca84e43f7599f8efa.png

Таким образом туннель становится обычным интерфейсом, и, как у любого другого интерфейса у него должна быть метрика.

Метрика туннеля


Во-первых, есть два типа метрик:

Метрика IGP — хорошо известная нам из курса базовой маршрутизации метрика интерфейсов.
Метрика TE — та метрика, которая будет использована при расчёте метрики TE-туннеля.

  • По умолчанию, TE=IGP.
  • По умолчанию, используется TE.
  • По умолчанию, метрика туннеля равна сумме TE-метрик всех линий от Ingress до Egress по кратчайшему IP-пути (а не по тому, по которому туннель идёт). То есть метрики обычных IP-маршрутов и маршрутов через туннель будут одинаковыми, даже если туннель фактически намного длиннее.
    Почему выбирается по кратчайшему пути? Логично, чтобы метрика туннеля должна перебить метрику лучшего IP-пути.
  • При равенстве метрик маршрутизатор выберет именно туннель, поскольку IGP shortcut именно это и подразумевает.
    Если есть IP-пути, которые не имеют общих сегментов с туннельным LSP, и при этом их метрики равны, будет иметь место балансировка.


Во-вторых, у нас есть следующие способы управления метрикой туннеля:

  1. Изменить значение метрики TE на физических интерфейсах.
  2. Указать MPLS TE использовать IGP метрику вместо TE.
  3. Соответственно, изменить IGP метрику физического интерфейса.
  4. Настроить непосредственно метрику туннельного интерфейса:


Вот человек очень доступно объясняет, как работают метрики.



Ну и вообще рекомендую ресурс: labminutes.com/video/sp

Forwarding adjacencies


Forwarding adjacencies — штука сходной c IGP Shortcut природы с той лишь (существенной) разницей, что туннель теперь будет анонсироваться Ingress LSR IGP-соседям, как обычный линк. Соответственно, все окружающие маршрутизаторы будут учитывать его в своих расчётах SPF.

IGP Shortcut же влияет только на таблицу маршрутизации на Ingress LSR, и окружающие соседи про этот туннель не знают.


Tunnel-policy*


*Этот способ зависит от производителя — у кого-то есть, у кого-то нет.
Tunnel-policy применяется для перенаправления исключительно трафика VPN в туннели.
То есть в режиме настройки VPN (не важно, L2 или L3) указывается какой туннель должен быть использован.

Существует две возможности:

  1. Tunnel binding mode. В зависимости от Egress PE выбирать конкретный туннель. Применимо только к RSVP LSP.
  2. Select-Seq mode. Тунель будет выбираться в порядке, указанном в конфигурации. Это может быть TE-туннель, LDP-туннель, с балансировкой или без.


Особенности Juniper


У джуна зачастую свой подход (ещё сегодня в этом убедитесь). Так у него существует несколько таблиц маршрутизации:

  1. IP routing table (inet.0)
  2. MPLS routing table (inet.3)
  3. MPLS forwarding table (mpls.0).


При помещении VPN-маршрутов в таблицу IP-маршрутизации BGP сверяется с таблицей MPLS inet.3. Если в ней он находит LSP до Next Hop’а маршрутра VPN, то автоматически трафик загоняется в этот LSP. Никаких дополнительных действий не требуется.

Это в некотором смысле похоже на микс Tunnel-Policy и IGP Shortcut, только автоматически.

ed9171a72bb64f42b90721664fbd4153.png

Практика


Всё та же сеть, но с ограничениями по пропускной способности.

f84ae3a9bb574ddcbb5c336f2c126345.png

Нам нужно обеспечить L3VPN клиенту.
У клиента есть требования: 8 Мб/с. Вынь да положь.
Направляем трафик в туннель через Auto-Route.

В лаборатории ограничение интерфейса — 10000 кб/с. Поэтому при задании требований туннеля и доступных полос, отталкиваемся исключительно от этой цифры.

Поехали!

Итак, начнём с того, что никакого LDP — только RSVP-TE. То есть LSP нет, пока мы не настроим туннель.

Хоть мы всё это уже и делали в прошлый раз, но начнём настройку сначала.

  1. Базовая конфигурация уже имеется (IP+IGP)
    Файл конфигурации.
  2. Включаем возможности TE 
    Linkmeup_R1(config) mpls traffic-eng tunnels

    И заодно на всех интерфейсах сразу настроим ограничение по полосе пропускания
    Router(config-if) ip rsvp bandwidth значение_ограничения

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

    На схеме выше я обозначил, какие из интерфейсов имеют ограничение в 5Мб/с. Если не подписано, то ограничения нет — ставим 10.

    Следует всегда помнить, что это только референсное значение для расчёта пути TE, и фактически команда никак не ограничивает реальную скорость TE-трафика, через интерфейс.

    Linkmeup_R1(config) interface FastEthernet 0/0
Linkmeup_R1(config-if) mpls traffic-eng tunnels 
Linkmeup_R1(config-if) ip rsvp bandwidth 5000

Linkmeup_R1(config) interface FastEthernet 0/1
Linkmeup_R1(config-if) mpls traffic-eng tunnels 
Linkmeup_R1(config-if) ip rsvp bandwidth 10000

    Обратите внимание, что команда ip rsvp bandwidth указывает полосу только в одном направлении. То есть если мы настроили её на интерфейсе E0/0 в сторону Linkmeup_R2, то это означает, что в 5Мб/с ограничена полоса только для исходящего трафика.
    Чтобы ограничить в другую сторону, нужно настроить интерфейс E0/1 со стороны Linkmeup_R2.

    Конфигурация других узлов

    Linkmeup_R2(config) mpls traffic-eng tunnels 

Linkmeup_R2(config)  interface FastEthernet 0/0
Linkmeup_R2(config-if)  mpls traffic-eng tunnels 
Linkmeup_R2(config-if)  ip rsvp bandwidth 5000

Linkmeup_R2(config)  interface FastEthernet 0/1
Linkmeup_R2(config-if)  mpls traffic-eng tunnels 
Linkmeup_R2(config-if)  ip rsvp bandwidth 10000

Linkmeup_R2(config)  interface FastEthernet 0/2
Linkmeup_R2(config-if)  mpls traffic-eng tunnels 
Linkmeup_R2(config-if)  ip rsvp bandwidth 10000

Linkmeup_R2(config)  interface FastEthernet 0/3
Linkmeup_R2(config-if)  mpls traffic-eng tunnels 
Linkmeup_R2(config-if)  ip rsvp bandwidth 10000


    
Linkmeup_R3(config) mpls traffic-eng tunnels 

Linkmeup_R3(config)  interface FastEthernet 0/0
Linkmeup_R3(config-if)  mpls traffic-eng tunnels 
Linkmeup_R3(config-if)  ip rsvp bandwidth 10000

Linkmeup_R3(config)  interface FastEthernet 0/1
Linkmeup_R3(config-if)  mpls traffic-eng tunnels 
Linkmeup_R3(config-if)  ip rsvp bandwidth 10000

Linkmeup_R3(config)  interface FastEthernet 0/2
Linkmeup_R3(config-if)  mpls traffic-eng tunnels 
Linkmeup_R3(config-if)  ip rsvp bandwidth 10000

Linkmeup_R3(config)  interface FastEthernet 0/3
Linkmeup_R3(config-if)  mpls traffic-eng tunnels 
Linkmeup_R3(config-if)  ip rsvp bandwidth 10000


    
Linkmeup_R4(config) mpls traffic-eng tunnels 

Linkmeup_R4(config)  interface FastEthernet 0/0
Linkmeup_R4(config-if)  mpls traffic-eng tunnels 
Linkmeup_R4(config-if)  ip rsvp bandwidth 10000

Linkmeup_R4(config)  interface FastEthernet 0/1
Linkmeup_R4(config-if)  mpls traffic-eng tunnels 
Linkmeup_R4(config-if)  ip rsvp bandwidth 10000


    
Linkmeup_R5(config) mpls traffic-eng tunnels 

Linkmeup_R5(config)  interface FastEthernet 0/0
Linkmeup_R5(config-if)  mpls traffic-eng tunnels 
Linkmeup_R5(config-if)  ip rsvp bandwidth 10000

Linkmeup_R5(config)  interface FastEthernet 0/1
Linkmeup_R5(config-if)  mpls traffic-eng tunnels 
Linkmeup_R5(config-if)  ip rsvp bandwidth 5000

Linkmeup_R5(config)  interface FastEthernet 0/2
Linkmeup_R5(config-if)  mpls traffic-eng tunnels 
Linkmeup_R5(config-if)  ip rsvp bandwidth 10000

Linkmeup_R5(config)  interface FastEthernet 0/3
Linkmeup_R5(config-if)  mpls traffic-eng tunnels 
Linkmeup_R5(config-if)  ip rsvp bandwidth 10000


    
Linkmeup_R6(config) mpls traffic-eng tunnels 

Linkmeup_R6(config)  interface FastEthernet 0/0
Linkmeup_R6(config-if)  mpls traffic-eng tunnels 
Linkmeup_R6(config-if)  ip rsvp bandwidth 10000

Linkmeup_R6(config)  interface FastEthernet 0/1
Linkmeup_R6(config-if)  mpls traffic-eng tunnels 
Linkmeup_R6(config-if)  ip rsvp bandwidth 10000

Linkmeup_R6(config)  interface FastEthernet 0/2
Linkmeup_R6(config-if)  mpls traffic-eng tunnels 
Linkmeup_R6(config-if)  ip rsvp bandwidth 10000

Linkmeup_R6(config)  interface FastEthernet 0/3
Linkmeup_R6(config-if)  mpls traffic-eng tunnels 
Linkmeup_R6(config-if)  ip rsvp bandwidth 10000


    
Linkmeup_R7(config) mpls traffic-eng tunnels 

Linkmeup_R7(config)  interface FastEthernet 0/0
Linkmeup_R7(config-if)  mpls traffic-eng tunnels 
Linkmeup_R7(config-if)  ip rsvp bandwidth 10000

Linkmeup_R7(config)  interface FastEthernet 0/1
Linkmeup_R7(config-if)  mpls traffic-eng tunnels 
Linkmeup_R7(config-if)  ip rsvp bandwidth 10000

Linkmeup_R7(config)  interface FastEthernet 0/3
Linkmeup_R7(config-if)  mpls traffic-eng tunnels 
Linkmeup_R7(config-if)  ip rsvp bandwidth 10000



  3. Настраиваем IS-IS на возможность сбора и передачи TE данных
    Linkmeup_R1(config) router isis 
Linkmeup_R1(config-router)  metric-style wide
Linkmeup_R1(config-router)  mpls traffic-eng router-id Loopback0
Linkmeup_R1(config-router)  mpls traffic-eng level-1

    Команда metric-style wide — обязательна, напоминаю. Дело в том, что TE использует новые TLV с расширенными метками, а по умолчанию ISIS генерирует только короткие.

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

    0d05b3161ae147be99bc00102ea746c4.png

  4. Настраиваем TE-туннель.
    Linkmeup_R1(config) interface Tunnel4
Linkmeup_R1(config-if) description To Linkmeup_R4
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 bandwidth 8000
Linkmeup_R1(config-if) tunnel mpls traffic-eng path-option 1 dynamic

    Здесь мы указали, что туннель строим до узла 4.4.4.4, требуется 8 Мб/с, а LSP строится динамически (без Explicit-Path)

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

    fe40890a53464c718671b20636afe977.png

    То есть CSPF рассчитал маршрут с учётом нашего ограничения, RSVP PATH успешно сигнализировал путь, а RSVP RESV зарезервировал ресурсы на всём пути.

    Трассировка показывает, что путь проложен ровно так, как мы этого хотели.

    124a79e949d94a028d4df08e81d3d752.png

    А в сообщении RSVP PATH можно увидеть, что он несёт информацию о требуемой полосе.

    a189f9575a9946b58fd9c19785796da2.png

    В дампе вы можете видеть начало объекта ERO с перечислением всех узлов по пути будущего RSVP LSP и запрос резервирования полосы пропускания.
    Здесь стоит 1000000 Байтов в секунду или ровно 8 Мегабит в секунду (если мы не путаем Мега с Меби). Величина эта дискретная и меняется с некоторым шагом. В случае данной лабы — это 250 кб/с.

    Можете поиграться с параметрами и увидеть, как туннель реагирует на изменения в сети.

    То же самое на обратной стороне: 
    Linkmeup_R4(config) interface Tunnel1
Linkmeup_R4(config-if) description To Linkmeup_R1
Linkmeup_R4(config-if) ip unnumbered Loopback0
Linkmeup_R4(config-if) tunnel mode mpls traffic-eng
Linkmeup_R4(config-if) tunnel destination 1.1.1.1
Linkmeup_R4(config-if) tunnel mpls traffic-eng bandwidth 8000
Linkmeup_R4(config-if) tunnel mpls traffic-eng path-option 1 dynamic

  5. Создаём VPN (см. как)
    Linkmeup_R1(config) ip vrf TARS
Linkmeup_R1(config-vrf)  rd 64500:200
Linkmeup_R1(config-vrf)  route-target export 64500:200
Linkmeup_R1(config-vrf)  route-target import 64500:200

Linkmeup_R1(config-vrf)  interface Ethernet0/3
Linkmeup_R1(config-if)  description To TARS_1
Linkmeup_R1(config-if)  ip vrf forwarding TARS
Linkmeup_R1(config-if)  ip address 172.16.0.1 255.255.255.0

Linkmeup_R1(config-if)  router bgp 64500
Linkmeup_R1(config-router)  neighbor 4.4.4.4 remote-as 64500
Linkmeup_R1(config-router)  neighbor 4.4.4.4 update-source Loopback0

Linkmeup_R1(config-router)  address-family vpnv4
Linkmeup_R1(config-router-af)   neighbor 4.4.4.4 activate
Linkmeup_R1(config-router-af)   neighbor 4.4.4.4 send-community both

Linkmeup_R1(config-router)  address-family ipv4 vrf TARS
Linkmeup_R1(config-router-af)   redistribute connected

    Настройка на Linkmeup_R4

    Linkmeup_R4(config) ip vrf TARS
Linkmeup_R4(config-vrf) rd 64500:200
Linkmeup_R4(config-vrf) route-target export 64500:200
Linkmeup_R4(config-vrf) route-target import 64500:200

Linkmeup_R4(config-vrf) interface Ethernet0/3
Linkmeup_R4(config-if) description To TARS_2
Linkmeup_R4(config-if) ip vrf forwarding TARS
Linkmeup_R4(config-if) ip address 172.16.1.1 255.255.255.0
Linkmeup_R4(config-if) mpls traffic-eng tunnels

Linkmeup_R4(config-if) router bgp 64500
Linkmeup_R4(config-router) neighbor 1.1.1.1 remote-as 64500

Linkmeup_R4(config-router) address-family vpnv4
Linkmeup_R4(config-router-af) neighbor 1.1.1.1 activate
Linkmeup_R4(config-router-af) neighbor 1.1.1.1 send-community both

Linkmeup_R4(config-router-af) address-family ipv4 vrf TARS


    Если сейчас попробуем пропинговать, то облом — ничего не будет.
    Обратите внимание, что BGP распространил маршруты VPN вместе с их метками, но нет передачи данных.
    Это потому, что пока нет привязки к транспортному LSP, а без этого нет никакого смысла и в метках VPN.
  6. Направляем в него трафик через IGP Shortcut.
    Для этого достаточно одной команды на обоих PE: 
    Linkmeup_R1(config) interface Tunnel4
Linkmeup_R1(config-if) tunnel mpls traffic-eng autoroute announce

    Linkmeup_R4(config) interface Tunnel1
Linkmeup_R4(config-if) tunnel mpls traffic-eng autoroute announce

    При необходимости можно также настроить метрику туннельного интерфейса: 
    Linkmeup_R1(config-if) tunnel mpls traffic-eng autoroute metric relative -5

    Linkmeup_R4(config-if) tunnel mpls traffic-eng autoroute metric relative -5

    cc77f22c909141e19f2ba5d9f1637a25.png

    924cda9523d245189c073ddacd0d74c4.png

    6729fb52febe4ddeba64e4e1b96ea266.png

  7. Есть пинг, есть счастье!

    496610cf6e5b4656b21f1ef2f9d7cb7b.png


Итак, что произошло?
  1. Сначала мы настроили базовую поддержку TE,
    а) Включили поддержку TE в глобальном режиме,
    б) Включили функцию TE на магистральных интерфейсах,
    г) Указали доступную пропускную способность физических интерфейсов,
    д) Заставили IGP анонсировать данные TE.

    На этом шаге IGP уже составил TEDB.

  2. Создали туннель (прямой и обратный):
    а) Указали точку назначения,
    б) Режим работы — TE,
    в) Указали требуемую полосу,
    г) Разрешили строить LSP динамически.

    На этом шаге сначала CSPF вычисляет список узлов, через которые нужно проложить LSP. Выхлоп этого процесса помещается в объект ERO. потом RSVP-TE с помощью сообщений PATH и RESV резервирует ресурсы и строит LSP.

    Но этого ещё недостаточно для практического использования туннеля.

  3. Настроили L3VPN (см. как).
    Когда MP-BGP обменялся маршрутными данными VRF, Next Hop’ом для этих маршрутов стал Loopback адрес удалённого PE.
    Однако маршруты из таблицы BGP не инсталлируются в таблицу маршрутизации данного VRF, поскольку трафик в LSP мы пока не запустили.
  4. Заставили IGP рассматривать TE-туннель, как возможный выходной интерфейс.
    Это не влечёт никаких изменений в других частях сети — исключительно локальное действие — IGP только меняет таблицу маршрутизации этого узла.

    Теперь LoopBack удалённого PE стал доступен через туннель, а маршруты добавились в таблицу маршрутизации VRF.

    То есть когда IP-пакет приходит от клиента,
    а) он получает метку VPN (16).
    б) из FIB VRF TARS ему известно, что для данного префикса пакет должен быть отправлен на адрес 4.4.4.4
    в) До 4.4.4.4 есть TE-туннель (Tunnel 4) и известна его пара выходной интерфейс/метка — Ethernet0/1, 18 — она будет транспортной.


b33cf0966b6445d8b89c9a70d0dced34.png

e7a759c8cdd447feb4d50fa0376b0c9a.png
На этой иллюстрации решительно нечего выделить — всё абсолютно прекрасно — вся информация о TE-туннеле в одной команде.



Сейчас путь от R1 до R4 выглядит так: R1→R5→R2→R6→R3→R4 — всё из-за этих чёртовых ограничений.

Теперь начинаем баловаться.
Попробуем разорвать наш рабочий линк R3→R4, пока длится непрерывный пинг.

5dd824ba687d4f82bd0018d5b8d109a7.png

LSP перестроился на R1→R5→R2→R6→R3→R7→R4 с потерей одного пакета. Это время может значительно увеличиться, если физического падения линии не будет на маршрутизаторах.

Что при этом происходило?
  1. Сначала R1 через сообщение RSVP PATH ERROR узнал о том, что линия испорчена.
  2. R1 отправил RSVP PATH TEAR по направлению к 4.4.4.4, а обратно идущий RSVP RESV TEAR удалил LSP.
  3. Тем временем на R1 CSPF рассчитал новый маршрут в обход сломанного линка.
  4. Потом RSVP-TE сигнализировал новый LSP R1→R5→R2→R6→R3→R7→R4

    637cadf4478848f68bb9028b614c0893.png


Если у нас не останется путей, удовлетворяющих заданным условиям — беда — LSP не будет.

Например, выключим линию R2-R5 и наблюдаем падения TE-туннеля на R1 без его дальнейшего восстановления.

Переоптимизация туннелей


Если линк R3→R4 восстановится, туннель перестроится обратно?
Да. Но не скоро. Пролетит много пакетов, прежде чем Ingress PE шевельнёт своим RSVP. (На самом деле зависит от производителя)
Это называется переоптимизацией туннелей (Tunnel reoptimization). С некоторой периодичностью Ingress PE заставляет CSPF проверить, а не появилось ли более оптимальных маршрутов.

  1. CSPF находит новый путь, удовлетворяющий всем условиям. В нашем случае R1→R5→R2→R6→R3→R4.
  2. Ingress PE сигнализирует новый RSVP LSP, отправляя RSVP PATH.
  3. Получив RSVP RESV, он понимает, что новый LSP готов.
  4. Отправляет RSVP PATH TEAR, чтобы сломать старый LSP.
  5. Когда RSVP RESV TEAR возвращается — всё закончено.


То есть сначала он строит новый RSVP LSP, пускает туда трафик и только потом ломает старый. Этот механизм называется Make-Before-Break, о котором в конце.

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

  1. Метрика пути MPLS TE
  2. Ограничение по полосе пропускания
  3. Explicit-Path
  4. SRLG
  5. Administrative Groups/Affinity


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


Cisco подробно про метрики.

Ограничение по полосе пропускания


На практике мы познакомились с базовой функцией 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 перезапрашивает резервирование.

Ближе к телу.

299626449a714e3395c9604f8ba21afd.png

Например, Adjust Interval у нас 2 часа. Текущее значение зарезервированной полосы пропускания — 90 Мб/с.
Adjust Threshold — 20 Мб/с.

В первом интервале всплеск 119 Мб/с (до 119 Мб/с) — больше порога. Значит RSVP-TE пытается построить новый туннель с новыми значениями для полосы пропускания.

Во втором — 23Мб/с (до 142) — опять больше порога. Обновляем резервирование по возможности.

В третьем максимальное значение падает до 137 Мб/с — разница только 5. Ничего не происходит.

В четвёртом всплеск падает до 116 (разница 21) — RSVP сигнализирует новый LSP с пониженными требованиями по полосе.

Так, каждые два часа будет происходить проверка и, возможно, перестроение туннелей.
Чем короче Adjust Interval, тем, соответственно, чаще будет обновляться резервирование и более рационально использоваться доступная полоса пропускания.

Примерно так при двухчасовом интервале будет выглядеть 24-часовое поведение auto-bandwidth.

59436beea7644000a6b5161c17bc9bd9.png

Уже заметили проблему?
Возьмём типичный профиль утреннего трафика:

3ba8c2076fa6486881a194c052d4c6d2.png
И такая дребедень целый день.

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

Приоритеты туннелей


Это механизм, который приоритезирует туннели: какой из них важнее. Он применим, как для случая 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.

Дело в том, что без требований по полосе приоритеты не имеют никакого значения — через один узел можно прол

© Habrahabr.ru