/ 13.-mpls-traffic-engineering / sposoby-napravleniya-trafika-v-te-tunnel.md
sposoby-napravleniya-trafika-v-te-tunnel.md
1 # Способы направления трафика в TE-туннель 2 3 В отличие от LDP LSP, по которым трафик бежит по умолчанию и так, в TE-туннели трафик нам нужно направить. 4 И есть для этого следующие способы: 5 6 1. [Статический маршрут](http://linkmeup.ru/blog/302.html#STATIC-ROUTE) 7 2. [PBR](http://linkmeup.ru/blog/302.html#PBR) 8 3. [IGP Shortcut](http://linkmeup.ru/blog/302.html#SHORTCUT) 9 4. [Tunnel-policy\*](http://linkmeup.ru/blog/302.html#TUNNEL-POLICY) 10 5. [Или всё-таки автоматом в туннель попадёт?\*](http://linkmeup.ru/blog/302.html#JUNIPER) 11 12 ## Статический маршрут 13 14 Самый простой в понимании и самый сложный в обслуживании способ. 15 16 ```text 17 Linkmeup_R1(config)#ip route 4.4.4.4 255.255.255.255 Tunnel 4 18 ``` 19 20 ## PBR 21 22 По сути тот же статический маршрут. 23 24 ```text 25 Linkmeup_R1(config)#ip access-list extended lennut 26 Linkmeup_R1(config-ext-nacl))#permit ip 172.16.0.0 0.0.0.255 172.16.1.0 0.0.0.255 27 Linkmeup_R1(config)#route-map lennut permit 10 28 Linkmeup_R1(configconfig-route-map)#match ip address lennut 29 Linkmeup_R1(config-route-map)#set interface Tunnel4 30 Linkmeup_R1(config)#interface Ethernet0/3 31 Linkmeup_R1(config-if)#ip policy route-map lennut 32 ``` 33 34 ## IGP Shortcut 35 36 Этот способ наиболее распространённый и поддерживается почти всеми производителями. 37 Маршрутизатор рассматривает туннель, как виртуальный интерфейс. И через этот интерфейс удалённые маршрутизаторы словно бы непосредственно подключены к локальному, а не находятся в десятках хопов. Этакая телекоммуникационная червоточина. Она и называется — shortcut — сокращённый путь. 38 39  40 41 Но протоколы IGP по умолчанию не хотят этого видеть и используют для отправки трафика физический интерфейс. 42 43 С помощью IGP Shortcut \(в цисконародье AutoRoute Announce\) мы вынуждаем протокол маршрутизации на Ingress LSR рассматривать туннель как обычную линию — Egress LSR будто бы подключен непосредственно. А соответственно и все сети, находящиеся за Egress LSR, будут доступны через туннель. 44 45 Таким образом всё, чьей точкой назначения является этот маршрутизатор, или узлы за ним, будет отправлено в туннель. В том числе и VPN-пакеты. 46 47  48 49 Таким образом туннель становится обычным интерфейсом, и, как у любого другого интерфейса у него должна быть метрика. 50 51 ### **Метрика туннеля** 52 53 Во-первых, есть два типа метрик: 54 55 **Метрика IGP** — хорошо известная нам из курса базовой маршрутизации метрика интерфейсов. 56 **Метрика TE** — та метрика, которая будет использована при расчёте метрики TE-туннеля. 57 58 * По умолчанию, TE=IGP. 59 * По умолчанию, используется TE. 60 * По умолчанию, метрика туннеля равна сумме TE-метрик всех линий от Ingress до Egress **по кратчайшему IP-пути** \(а не по тому, по которому туннель идёт\). То есть метрики обычных IP-маршрутов и маршрутов через туннель будут одинаковыми, даже если туннель фактически намного длиннее. Почему выбирается по кратчайшему пути? Логично, чтобы метрика туннеля должна перебить метрику лучшего IP-пути. 61 * При равенстве метрик маршрутизатор выберет именно туннель, поскольку IGP shortcut именно это и подразумевает. 62 63 > Если есть IP-пути, которые **не имеют общих сегментов** с туннельным LSP, и при этом их метрики равны, будет иметь место балансировка. 64 65 Во-вторых, у нас есть следующие способы управления метрикой туннеля: 66 67 1. Изменить значение метрики TE на физических интерфейсах. 68 2. Указать MPLS TE использовать IGP метрику вместо TE. 69 3. Соответственно, изменить IGP метрику физического интерфейса. 70 4. Настроить непосредственно метрику туннельного интерфейса: 71 * Её можно указать статически. Независимо от того, что там у нас на физических интерфейсах, у Туннеля будет его собственная. При вычислении метрики маршрута, она будет суммироваться к остальным участкам. 72 * Можно указать абсолютной. Для всех маршрутов, которые доступны через туннель метрика будет одинаковой — вообще никакие физические интерфейсы между началом туннеля и точкой назначения значения иметь не будут. 73 * Можно задать её относительно метрики IGP. Например, больше на 5 попугаев, или меньше на 7. 74 75 Вот человек очень доступно объясняет, как работают метрики. 76 77 {% embed url="https://youtu.be/eLLSMsgYiNQ" caption="" %} 78 79 {% embed url="https://youtu.be/GXGzcF8oQrU" caption="" %} 80 81 {% embed url="https://youtu.be/OFho6er9Bcw" caption="" %} 82 83 Ну и вообще рекомендую ресурс: [labminutes.com/video/sp](http://labminutes.com/video/sp) 84 85 > #### Forwarding adjacencies 86 > 87 > Forwarding adjacencies — штука сходной c IGP Shortcut природы с той лишь \(существенной\) разницей, что туннель теперь будет анонсироваться Ingress LSR IGP-соседям, как обычный линк. Соответственно, все окружающие маршрутизаторы будут учитывать его в своих расчётах SPF. 88 > IGP Shortcut же влияет только на таблицу маршрутизации на Ingress LSR, и окружающие соседи про этот туннель не знают. 89 90 ## Tunnel-policy\* 91 92 _\*Этот способ зависит от производителя — у кого-то есть, у кого-то нет._ 93 Tunnel-policy применяется для перенаправления исключительно трафика VPN в туннели. 94 То есть в режиме настройки VPN \(не важно, L2 или L3\) указывается какой туннель должен быть использован. 95 Существует две возможности: 96 97 1. **Tunnel binding mode**. В зависимости от Egress PE выбирать конкретный туннель. Применимо только к RSVP LSP. 98 2. **Select-Seq mode**. Тунель будет выбираться в порядке, указанном в конфигурации. Это может быть TE-туннель, LDP-туннель, с балансировкой или без. 99 100 ## Особенности Juniper 101 102 У джуна зачастую свой подход \(ещё сегодня в этом убедитесь\). Так у него существует несколько таблиц маршрутизации: 103 104 1. IP routing table \(inet.0\) 105 2. MPLS routing table \(inet.3\) 106 3. MPLS forwarding table \(mpls.0\). 107 108 При помещении VPN-маршрутов в таблицу IP-маршрутизации BGP сверяется с таблицей MPLS inet.3. Если в ней он находит LSP до Next Hop'а маршрутра VPN, то автоматически трафик загоняется в этот LSP. Никаких дополнительных действий не требуется. 109 Это в некотором смысле похоже на микс Tunnel-Policy и IGP Shortcut, только автоматически. 110  111 112 ## Практика 113 114 Всё та же сеть, но с ограничениями по пропускной способности. 115 116  117 118 Нам нужно обеспечить L3VPN клиенту. 119 У клиента есть требования: 8 Мб/с. Вынь да положь. 120 Направляем трафик в туннель через Auto-Route. 121 122 > В лаборатории ограничение интерфейса — 10000 кб/с. Поэтому при задании требований туннеля и доступных полос, отталкиваемся исключительно от этой цифры. 123 124 Поехали! 125 Итак, начнём с того, что никакого LDP — только RSVP-TE. То есть LSP нет, пока мы не настроим туннель. 126 Хоть мы всё это уже и делали в прошлый раз, но начнём настройку сначала. 127 128 1. Базовая конфигурация уже имеется \(IP+IGP\) [Файл конфигурации.](https://docs.google.com/document/d/1F03GvVpAd97kEOf7X4oR9rA4FdK50rWOz3HwOxfhuMs/pub) 129 2. Включаем возможности TE 130 131 ```text 132 Linkmeup_R1(config)#mpls traffic-eng tunnels 133 ``` 134 135 И заодно на всех интерфейсах сразу настроим ограничение по полосе пропускания 136 137 ```text 138 Router(config-if)#ip rsvp bandwidth значение_ограничения 139 ``` 140 141 При указании требования по полосе для туннеля данная команда является обязательной — полосу нужно задать явно, иначе IGP эту информацию не анонсирует, а CSPF соответственно не будет учитывать эту линию и не вычислит путь под требования туннеля. 142 На схеме выше я обозначил, какие из интерфейсов имеют ограничение в 5Мб/с. Если не подписано, то ограничения нет — ставим 10. 143 144 > Следует всегда помнить, что это только референсное значение для расчёта пути TE, и фактически команда **никак не ограничивает**реальную скорость TE-трафика, через интерфейс. 145 146 ```text 147 Linkmeup_R1(config)#interface FastEthernet 0/0 148 Linkmeup_R1(config-if)#mpls traffic-eng tunnels 149 Linkmeup_R1(config-if)#ip rsvp bandwidth 5000 150 Linkmeup_R1(config)#interface FastEthernet 0/1 151 Linkmeup_R1(config-if)#mpls traffic-eng tunnels 152 Linkmeup_R1(config-if)#ip rsvp bandwidth 10000 153 ``` 154 155 > Обратите внимание, что команда **ip rsvp bandwidth** указывает полосу только в одном направлении. То есть если мы настроили её на интерфейсе E0/0 в сторону Linkmeup\_R2, то это означает, что в 5Мб/с ограничена полоса только для исходящего трафика. 156 > Чтобы ограничить в другую сторону, нужно настроить интерфейс E0/1 со стороны Linkmeup\_R2. 157 158 [Конфигурация других узлов](https://docs.google.com/document/d/e/2PACX-1vSSQFUiDrLOPnmI2sVmNHk7Ci-3yTaliUbnLYCt6j1V7Gcbsrgxe_xfjukKhQu6wMj_fYJ212-i4ztI/pub) 159 160 1. Настраиваем IS-IS на возможность сбора и передачи TE данных 161 162 ```text 163 Linkmeup_R1(config)#router isis 164 Linkmeup_R1(config-router)# metric-style wide 165 Linkmeup_R1(config-router)# mpls traffic-eng router-id Loopback0 166 Linkmeup_R1(config-router)# mpls traffic-eng level-1 167 ``` 168 169 Команда metric-style wide — обязательна, напоминаю. Дело в том, что TE использует новые TLV с расширенными метками, а по умолчанию ISIS генерирует только короткие. 170 Поскольку конфигурация полностью одинаковая, для других узлов не привожу. 171 172  173 174 1. Настраиваем TE-туннель. 175 176 ```text 177 Linkmeup_R1(config)#interface Tunnel4 178 Linkmeup_R1(config-if)#description To Linkmeup_R4 179 Linkmeup_R1(config-if)#ip unnumbered Loopback0 180 Linkmeup_R1(config-if)#tunnel mode mpls traffic-eng 181 Linkmeup_R1(config-if)#tunnel destination 4.4.4.4 182 Linkmeup_R1(config-if)#tunnel mpls traffic-eng bandwidth 8000 183 Linkmeup_R1(config-if)#tunnel mpls traffic-eng path-option 1 dynamic 184 ``` 185 186 Здесь мы указали, что туннель строим до узла 4.4.4.4, требуется 8 Мб/с, а LSP строится динамически \(без Explicit-Path\) 187 Сразу после этого видим, что туннель поднялся. 188  189 То есть CSPF рассчитал маршрут с учётом нашего ограничения, RSVP PATH успешно сигнализировал путь, а RSVP RESV зарезервировал ресурсы на всём пути. 190 191 > Трассировка показывает, что путь проложен ровно так, как мы этого хотели. 192 >  193 > 194 > А в сообщении RSVP PATH можно увидеть, что он несёт информацию о требуемой полосе. 195 >  196 > В дампе вы можете видеть начало объекта ERO с перечислением всех узлов по пути будущего RSVP LSP и запрос резервирования полосы пропускания. 197 > Здесь стоит 1000000 Байтов в секунду или ровно 8 Мегабит в секунду \(если мы не путаем Мега с Меби\). Величина эта дискретная и меняется с некоторым шагом. В случае данной лабы — это 250 кб/с. 198 > 199 > Можете поиграться с параметрами и увидеть, как туннель реагирует на изменения в сети. 200 201 То же самое на обратной стороне: 202 203 ```text 204 Linkmeup_R4(config)#interface Tunnel1 205 Linkmeup_R4(config-if)#description To Linkmeup_R1 206 Linkmeup_R4(config-if)#ip unnumbered Loopback0 207 Linkmeup_R4(config-if)#tunnel mode mpls traffic-eng 208 Linkmeup_R4(config-if)#tunnel destination 1.1.1.1 209 Linkmeup_R4(config-if)#tunnel mpls traffic-eng bandwidth 8000 210 Linkmeup_R4(config-if)#tunnel mpls traffic-eng path-option 1 dynamic 211 ``` 212 213 1. Создаём VPN \([см. как](http://linkmeup.ru/blog/204.html)\) 214 215 ```text 216 Linkmeup_R1(config)#ip vrf TARS 217 Linkmeup_R1(config-vrf)# rd 64500:200 218 Linkmeup_R1(config-vrf)# route-target export 64500:200 219 Linkmeup_R1(config-vrf)# route-target import 64500:200 220 Linkmeup_R1(config-vrf)# interface Ethernet0/3 221 Linkmeup_R1(config-if)# description To TARS_1 222 Linkmeup_R1(config-if)# ip vrf forwarding TARS 223 Linkmeup_R1(config-if)# ip address 172.16.0.1 255.255.255.0 224 Linkmeup_R1(config-if)# router bgp 64500 225 Linkmeup_R1(config-router)# neighbor 4.4.4.4 remote-as 64500 226 Linkmeup_R1(config-router)# neighbor 4.4.4.4 update-source Loopback0 227 Linkmeup_R1(config-router)# address-family vpnv4 228 Linkmeup_R1(config-router-af)# neighbor 4.4.4.4 activate 229 Linkmeup_R1(config-router-af)# neighbor 4.4.4.4 send-community both 230 Linkmeup_R1(config-router)# address-family ipv4 vrf TARS 231 Linkmeup_R1(config-router-af)# redistribute connected 232 ``` 233 234 **Настройка на Linkmeup\_R4** 235 Если сейчас попробуем пропинговать, то облом — ничего не будет. 236 Обратите внимание, что BGP распространил маршруты VPN вместе с их метками, но нет передачи данных. 237 Это потому, что пока нет привязки к транспортному LSP, а без этого нет никакого смысла и в метках VPN. 238 239 1. Направляем в него трафик через IGP Shortcut. 240 241 Для этого достаточно одной команды на обоих PE: 242 243 ```text 244 Linkmeup_R1(config)#interface Tunnel4 245 Linkmeup_R1(config-if)#tunnel mpls traffic-eng autoroute announce 246 ``` 247 248 ```text 249 Linkmeup_R4(config)#interface Tunnel1 250 Linkmeup_R4(config-if)#tunnel mpls traffic-eng autoroute announce 251 ``` 252 253 При необходимости можно также настроить метрику туннельного интерфейса: 254 255 ```text 256 Linkmeup_R1(config-if)#tunnel mpls traffic-eng autoroute metric relative -5 257 ``` 258 259 ```text 260 Linkmeup_R4(config-if)#tunnel mpls traffic-eng autoroute metric relative -5 261 ``` 262 263  264  265 266  267 268 1. Есть пинг, есть счастье!  269 270 > Итак, что произошло? 271 > 272 > 1. Сначала мы настроили базовую поддержку TE, а\) Включили поддержку TE в глобальном режиме, б\) Включили функцию TE на магистральных интерфейсах, г\) Указали доступную пропускную способность физических интерфейсов, д\) Заставили IGP анонсировать данные TE. **На этом шаге IGP уже составил TEDB.** 273 > 2. Создали туннель \(прямой и обратный\): а\) Указали точку назначения, б\) Режим работы — TE, в\) Указали требуемую полосу, г\) Разрешили строить LSP динамически. **На этом шаге сначала CSPF вычисляет список узлов, через которые нужно проложить LSP. Выхлоп этого процесса помещается в объект ERO. потом RSVP-TE с помощью сообщений PATH и RESV резервирует ресурсы и строит LSP.** Но этого ещё недостаточно для практического использования туннеля. 274 > 3. Настроили L3VPN \([см. как](http://linkmeup.ru/blog/204.html)\). Когда MP-BGP обменялся маршрутными данными VRF, Next Hop'ом для этих маршрутов стал Loopback адрес удалённого PE. Однако маршруты из таблицы BGP не инсталлируются в таблицу маршрутизации данного VRF, поскольку трафик в LSP мы пока не запустили. 275 > 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 — она будет транспортной. 276 > 277 >  278 >  279 > На этой иллюстрации решительно нечего выделить — всё абсолютно прекрасно — вся информация о TE-туннеле в одной команде. 280 281 Сейчас путь от R1 до R4 выглядит так: R1->R5->R2->R6->**R3->R4** — всё из-за этих чёртовых ограничений. 282 283 Теперь начинаем баловаться. 284 Попробуем разорвать наш рабочий линк R3->R4, пока длится непрерывный пинг. 285  286 LSP перестроился на R1->R5->R2->R6->R3->**R7**->R4 с потерей одного пакета. Это время может значительно увеличиться, если физического падения линии не будет на маршрутизаторах. 287 288 > Что при этом происходило? 289 > 290 > 1. Сначала R1 через сообщение RSVP PATH ERROR узнал о том, что линия испорчена. 291 > 2. R1 отправил RSVP PATH TEAR по направлению к 4.4.4.4, а обратно идущий RSVP RESV TEAR удалил LSP. 292 > 3. Тем временем на R1 CSPF рассчитал новый маршрут в обход сломанного линка. 293 > 4. Потом RSVP-TE сигнализировал новый LSP R1->R5->R2->R6->R3->R7->R4  294 295 Если у нас не останется путей, удовлетворяющих заданным условиям — беда — LSP не будет. 296 Например, выключим линию R2-R5 и наблюдаем падения TE-туннеля на R1 без его дальнейшего восстановления 297 298 ## Переоптимизация туннелей 299 300 Если линк R3->R4 восстановится, туннель перестроится обратно? 301 Да. Но не скоро. Пролетит много пакетов, прежде чем Ingress PE шевельнёт своим RSVP. \(На самом деле зависит от производителя\) 302 Это называется переоптимизацией туннелей \(Tunnel reoptimization\). С некоторой периодичностью Ingress PE заставляет CSPF проверить, а не появилось ли более оптимальных маршрутов. 303 304 1. CSPF находит новый путь, удовлетворяющий всем условиям. В нашем случае R1->R5->R2->R6->**R3->R4**. 305 2. Ingress PE сигнализирует новый RSVP LSP, отправляя RSVP PATH. 306 3. Получив RSVP RESV, он понимает, что новый LSP готов. 307 4. Отправляет RSVP PATH TEAR, чтобы сломать старый LSP. 308 5. Когда RSVP RESV TEAR возвращается — всё закончено. 309 310 То есть сначала он строит новый RSVP LSP, пускает туда трафик и только потом ломает старый. Этот механизм называется Make-Before-Break, о котором [в конце.](http://linkmeup.ru/blog/302.html#MBB) 311