Способы направления трафика в 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 — сокращённый путь.

Червоточина Фламма

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

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

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

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

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

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

Метрика 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. Настроить непосредственно метрику туннельного интерфейса:

   • Её можно указать статически. Независимо от того, что там у нас на физических интерфейсах, у Туннеля будет его собственная. При вычислении метрики маршрута, она будет суммироваться к остальным участкам.

   • Можно указать абсолютной. Для всех маршрутов, которые доступны через туннель метрика будет одинаковой — вообще никакие физические интерфейсы между началом туннеля и точкой назначения значения иметь не будут.

   • Можно задать её относительно метрики IGP. Например, больше на 5 попугаев, или меньше на 7.

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

Ну и вообще рекомендую ресурс: 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, только автоматически.

Практика

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

Нам нужно обеспечить 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.

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

1. Настраиваем 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 генерирует только короткие. Поскольку конфигурация полностью одинаковая, для других узлов не привожу.

1. Настраиваем 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) Сразу после этого видим, что туннель поднялся. То есть CSPF рассчитал маршрут с учётом нашего ограничения, RSVP PATH успешно сигнализировал путь, а RSVP RESV зарезервировал ресурсы на всём пути.

Трассировка показывает, что путь проложен ровно так, как мы этого хотели. А в сообщении RSVP PATH можно увидеть, что он несёт информацию о требуемой полосе. В дампе вы можете видеть начало объекта 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

1. Создаём 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 Если сейчас попробуем пропинговать, то облом — ничего не будет. Обратите внимание, что BGP распространил маршруты VPN вместе с их метками, но нет передачи данных. Это потому, что пока нет привязки к транспортному LSP, а без этого нет никакого смысла и в метках VPN.

1. Направляем в него трафик через 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

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

Итак, что произошло?

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 — она будет транспортной.

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

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

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

Если у нас не останется путей, удовлетворяющих заданным условиям — беда — 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, о котором в конце.