MPLS Traffic Engineering: часть 1

так буквально одну минутку начнем recharge nice share the screen

okay Ну что ж, у нас сегодня будет с вами последнее занятие. Мы сегодня поговорим об основах трафика джинниринга. Об основах трафика джинниринга. Конечно, не нужны будет такое количество маршрутизаторов, но тем не менее. Конечно, весь трафик джинниринга я вам сказать не успею. Я скорее дам введение, просто чтобы у вас было некоторое понимание о том, что это за зверь, с чем его едят и какие проблемы у нас в любом случае остается.

Давайте с вами рассмотрим вот такую ситуацию. Сейчас. Так, давайте с вами рассмотрим вот такую ситуацию. Вот такие крутые, построили новую MPLS-сеть. Скажем, она у нас вот такая. У нас вот есть вот здесь маршрутизатор, здесь маршрутизатор, здесь маршрутизатор, здесь. Раз, два, три.

Ну, например, вот такую сетку мы построили. Такую сетку мы построили. Представим, что, например, вот эти вот линки, нижние, нижние. Даже не нижние, давайте верхние, по-игому. Все линки, например, они равны 10G, скажем. Все линки 10G. Вот к этим вот, к бордерам-машрутизаторам у нас подключено большое количество заказчиков. Красный, зеленый, голубой, ну, в общем, и так далее. То есть, соответственно, вопрос к вам, ребят. Как у нас будет ходить трафик между...

То есть, как у нас будет ходить трафик между красными сайтами, между зелеными сайтами, между синими сайты? Нет, я имею в виду, через какие амортизаторы он будет ходить. Будет ли он ходить через верхний, будет ли он ходить через средний, будет ли трафик балансироваться как-то. Вы как считаете? Да. Да, Евгений абсолютно прав. Почему? Предположим, что вот это мои бордеры, скажем, это там машрутизаторы R1 и машрутизаторы R2. Что произойдет? По сути, железка скажет. Если мы летим внутри красной VRF, мы говорим там show.ip.route,

некий хост, некий хост h, скажем, VRF.rf. Этот маршрут нам скажет, что он известен через машрутизатор R2 посредством протокола BGP и находится в таблице global. То есть, находится в глобальной VRF. Далее мы резолвим, как добраться до R2. И, например, здесь у нас будет некий машрутизатор Rx. Здесь будет написано via машрутизатор Rx. Выходной интерфейс, скажем, там E00. То есть, как вы видите, у вас происходит некая поляризация трафика. То есть, пакеты все будут идти исключительно по пути, который определил ваш протокол машрутизации. В частности, протокол успеха. Это может быть проблемой.

То есть, в какой-то прекрасный момент времени вы можете обнаружить, например, что у вас... Скажем. Вот здесь вот много трафика летит. То есть, много синего трафика летит. И, скажем, много зеленого трафика летит. Вы начинаете просматривать утилизацию ваших интерфейсов. Замечаете, что на этом пути вы начинаете упираться просто в полку. То есть, интерфейсы у вас становятся полностью загружены. Хотя у вас есть в сети еще огромное количество линков, которые могут быть, скажем так, не утилизированы совершенно. То есть, у вас вот здесь оставшиеся черные линки, у них загрузка будет абсолютно нулевая. То есть, это первый кейс, когда вам, может быть, нужно будет подумать,

а есть ли какая-то возможность разбалансировать трафик, например, по остальным путям. Это первый кейс. Второй кейс, когда вы об этом можете задуматься. Предположим, что ваш красный заказчик, красный заказчик, например, это какой-то там суперзаказчик, которым вы должны обеспечить, скажем, например, минимальную задержку, там большую гарантированную полосу, ну что-то в таком духе. И вы решаете, и вы хотите, например, чтобы красный заказчик ходил по этому пути. А, например, для зеленого заказчика могут быть другие требования. Может быть, например, ему задержка не так страшна, но, например, ему нужно, чтобы, скажем, ну не знаю, он вас просит, чтобы у вас была максимальная надежность в каналах,

чтобы ваш трафик всегда ходил по наиболее надежным линкам. А ведь есть такая вероятность, что там, где быстрый путь, ну, например, там часто экскаваторщики работают. Вам нужно будет как-то сделать так, чтобы трафик зеленого заказчика, например, мог ходить вот здесь. Это раз. То есть это второй кейс, когда вам нужно будет подумать, как вам можно улучшить вашу топологию, и как раскидать трафик от кастера. Какие еще бывают интересные случаи? Представьте, что мы такие крутые, вот эту всю MPLS-ную сетку мы построили. У нас есть вот они, мужетизаторы R1, вот так, укрупненно, и мужетизаторы R2. По сути, между ними,

по сути, между ними вот три пути. Есть три логических пути. Вы, например, хотите, чтобы какой-то канал, например, был основным, а какой-то канал для основного канала был резервным. Предположим, что вот у верхнего канала суммарная метрика у нас 20, а у этих, ну, например, там 30-40. 30-40. Вы думаете, ага, давай-ка мы попробуем сделать так, чтобы резервным был путь вот средний. Был путь средний. А потом вдруг обнаруживаете, скажем, у вас пропал, условно говоря, вот этот вот линк, вот этот вот линк, и одновременно с этим, и одновременно с этим у вас пропадает и вот этот линк. То есть вы видите, то есть как только у вас, например, один линк падает, падает,

падает, например, и второй канал связи. Кто-нибудь сталкивается с такой ситуацией, ребята? То есть когда у вас вроде есть два независимых канала, которые, например, к вашему зданию приходят, но при определенных ситуациях падают они сразу оба. Такое часто случается, когда они физически идут там где-нибудь по каким-нибудь колодцам одним и тем же путем. Соответственно, да, если в этом конкретном колодце, на каком-то участке случается какая-то авария, у вас сразу попадает, собственно говоря, и основной канал, и резерв. Поэтому у вас может стать задача следующего рода. Вы можете захотеть покрасить, например, вы можете покрасить вот эти линки, условно, естественно, покрасить, одним цветом. И сказать, что, например,

если у нас на основном пути следования трафика есть какие-то оранжевые линки, то на бэкапном пути следования трафика таких оранжевых линков быть не должно. Вот эти все задачи, ну, на самом деле, не только их, еще есть, решает технология трафика инжиниринга. В частности, трафика инжиниринг поверх MPLS. В чем ее суть? В чем ее суть? Прежде всего, я вам хочу сказать, что MPLS трафик инжиниринг и сам MPLS – это две разные фичи, на самом деле, две разные технологии. Ну, например, скажем, для работы именно трафика инжиниринга вам совершенно не нужен LDP. То есть, ваша сетка, на самом деле, может спокойно жить без LDP-протокола, хотя наша классическая MPLS-сеть

целиком и полностью полагается на LDP. В чем суть? В чем суть трафика инжиниринга? Особо не вникает в стайли. Особо не вникает в стайли. У вас появляется некий новый протокол, который называется ресурс резервейшн протокол или появляется протокол RSVP. RSVP активируется на всех линках. То есть, это протокол, который работает на линках. Далее. У вас все маршрутизаторы, например, построили отношения со сетства

по этому протоколу. Что происходит дальше? Дальше происходит очень интересная вещь. Вы говорите, я хочу построить туннель между точками А и Б и пустить в него трафик. То есть, условно говоря, что может произойти? Вы говорите, я хочу построить туннель между... То есть, головой этого туннеля будет маршрутизатор R1, а окончанием этого туннеля будет маршрутизатор R2. При этом транзитные хопы, транзитные хопы, например, у меня должны быть вот такие вот. у меня должны быть вот такие. Соответственно, наша логическая топология становится какой? У нас между маршрутизаторами R1 и R2...

Ребят, сколько теперь будет логических каналов связи? 4. 4. Верхние, вот эти черные, черные, это LDP. Так или иначе. Этот зелененький канал связи, он построен по стрессам протокола RSVP. Такого мы рассмотрим. Соответственно, если маршрутизатор R1 хочет, чтобы пакет пошел до маршрутизатора R2 именно туннелем, именно туннелем, то он должен выставить пакет с какой-то новой меткой. С какой-то новой меткой. Единственное, что, ребят, дайте-ка я немножко изменю картинку,

потому что здесь вас может немножко смутить, а может быть не очень наглядно. Представьте, что у нас есть, например, вот так вот. Вот здесь еще один линк, здесь еще один линк. и мы, например, хотим трафик пускать вот так вот. Мы хотим трафик пускать вот так. Вопрос к вам. Предположим, предположим, у нас трафик должен дойти от R1 до R2 и при этом пройти вот зеленый путь. Вопрос к вам. Мы можем использовать для этого LDP-шную метку или нет? Что будет, если мы будем использовать LDP, то есть, если мы будем полагаться на протоком маршрутизации? Каким путем трафик пойдет? Он пойдет,

ну, наилучшим путем. Правильно? Тот, который был построен с помощью SPF. Естественно, что мы должны сделать? Мурсиатр R1 должен выслать пакет вот сюда, должен выслать пакет вот сюда. При этом, он должен поставить такую метку, чтобы следующий маршрутизатор откоммутировал пакет вот сюда. Далее, следующий маршрутизатор должен будет откоммутировать пакет вот сюда, и вот этот маршрутизатор должен будет откоммутировать пакет вот сюда. Встает основной вопрос, как маркетизаторы получат вот эти новые какие-то зеленые метки, непонятно. Как они их согласуют? Для этого

рассмотрим такую ситуацию. У нас есть маркетизатор R1, маркетизатор R2, ну и здесь какие-то маркетизаторы. Р3, R4 и R5. Итак, с чего все начинается? Мы когда хотим построить туннель до R2, мы говорим, что этот туннель должен соответствовать каким-то требованиям. Этими требованиями могут быть, например, минимальная полоса пропускания на канале, скажем, 10 мегабит. То есть на минимальном линке не должно быть менее 10 мегабит. Это раз. Второе, скажем, на канале не должно быть оранжевых линков. Помните, мы в самом начале линки красили? Это два. Третье, я не знаю. Например, этот линк, например, этот туннель обязательно должен пройти через маркетизатор R4.

То есть у нас появляются некие дополнительные требования к этому туннелю. У нас появляются некие требования. Муртизатор, который предъявляет эти требования к туннелю, подает их на свою… Как бы он… Вот у него есть ОСПФная база данных, LSDB. На основе этой LSDB у нас построена таблица маркетизации. Так вот, мы можем несколько модифицировать наш ОСПФ протокол. Мы на самом деле можем ввести в него дополнительные LSA, которые, в которых будет содержаться информация, которая сможет описать наши дополнительные требования. Вот такие LSA у ОСПФ называются…

Описать-то можно, то есть требований можно сделать довольно-таки много. Соответственно, на основе вот этих требований, то есть и классической ОСПФной базы данных, по сути, мы получаем некий результат. Некий результат. Некий результат. В частности, для маркетизатора R1, это может быть результат такой, что наша цепочка, которая удовлетворяет нашим требованиям, состоит из следующих маркетизаторов. Например, R1, R3, R4, R5 и R2. Далее, маркетизатор R1 должен просигнализировать маркетизатору R2 о том,

что он сейчас хочет построить туннель. То есть сказать маркетизатору R2 о том, друг, пожалуйста, в ближайшее время от меня ожидай трафик, который будет характерен какому-то туннелю, не классической таблице маркетизации, а нашему туннелю с дополнительными требованиями. Маркетизатор R1, когда понимает, что ему нужно построить туннель, он резервирует для этого дополнительную МПЛСную метку. В частности, будет метка, скажем, будет 10. Плюс он высылает в сторону маркетизатора первого из этой цепочки, он высылает, я не помню, как правильно называется сообщение, по-моему, оно называется пасс. Пасс. Суть в том, что внутри этого пасса содержатся некие требования для туннеля.

Некие требования для туннеля. Моркетизатор R3 получает такое сообщение через интерфейс и дальше проверяет, может ли он удовлетворить этим требованиям или нет. Если может, то он у себя генерирует некую метку, например, 30. Пока что держит ее в памяти. И высылает это сообщение дальше. Собственно говоря, это сообщение высылается вот так вот по цепочке. Так вот по цепочке. Оно высылается до тех пор, пока не дойдет до конечного адресата. Дело в том, что внутри вот этого сообщения обязательно будет указан конечный адресат, например, моркетизатор R2. Обязательно. Если моркетизатор R2, если у него есть возможность на себе затерминировать этот туннель,

например, ресурс есть, он понимает, что дерево посчитано верно, то он отвечает всем моркетизаторам. И ответное сообщение доходит до моркетизатора R1. Соответственно, теперь с точки зрения дата плейна у нас что происходит? Когда прилетает пакет на моркетизатор R1 с данными, моркетизатор смотрит свою таблицу форвардинга. Ага, что он пил из форвардинга-тейла. И теперь он уже будет добавлять для пакета вот эту меточку сгенерированную. Будет здесь передаваться пакет с меткой 10. Далее на моркетизаторе R3 метка 10 заменится на метку 30. На моркетизаторе R4 метка 30 заменится на метку 40. Это 40 заменится на 50.

И там в конце концов 50 заменится на 20. Вот такая метка называется Traffic Engineering метка. Это не LDP-шная метка. По сути, у вас последовательность моркетизаторов в цепочке может быть абсолютно любой. И расположены они могут быть как угодно. Конечная цепочка будет зависеть только от того, какой результат вы получите в зависимости от накладывания ваших требований на существующую топологию сети. Это раз. Ну, либо же при желании вы вот эти все транзитные хопы можете задать руками. То есть вы туннель. Получается, что вы туннель можете построить как динамически, так и статически. Виктор, нет. Она используется вместо LDP-метки.

То есть, суть в том, что если мы вернемся к верхней картинке, к верхней картинке, у нас будет LDP-шная метка. Например, по LDP метка, скажем, это 200. А TE метка – это метка 20. Соответственно, если мы хотим, чтобы трафик пошел верхним путем, то мы, потому что R1 выкидывает метку 200, и дальше у нас все происходит по классическим LDP-шным правилам. Если же мы выкидываем метку 20, то поскольку мы знаем о метке 20, наш сосед знает о нашей метке 20, то есть мы ее согласовали по РСВП, то такой пакет спокойно пролетит нужным нам путем через туннель. Через трафик инженер. Опять же, эта метка нужна только для того, чтобы маркетизаторы понимали, как коммутировать трафик

согласно не LDP-сигнализации, а сигнализации другого протокола, который может учитывать дополнительные пути, которые существуют в нашей тополоне. Идея понятна, что такое трафик инжиниринг? В таком базовом варианте. Или нужны какие-то дополнительные пояснения? Олин. Илиcan Stellen Declarationa? Скажите.

Now. Ну, давайте с вами рассмотрим пример. Виктор, давай, наверное, на твой вопрос отвечу первым. По сравнению с изменением костов в успех, в чем преимущество? Ну, смотри, дело в том, что ты, если меняешь косты успехные, максимум что-то сможешь, это добиться равномерной балансировки. Но с помощью трафика инжиниринга, поскольку ты туннель можешь построить, он может проходить абсолютно через любые амортизаторы, абсолютно в любой последовательности. Соответственно, ты, например, любых своих заказчиков можешь помещать в нужные тебе туннели.

У тебя, скажем, красный заказчик может ходить одним путем, зеленый заказчик может ходить другим путем, синий – третьим путем. Ну, такой самый простейший случай. Василий, смотри, нет, метки, метки, они передаются в протоколе RSVP. То есть у нас вот этот протокол RSVP работает на линке end-to-end, то есть между всеми амортизаторами. И метки резервируются, метки резервируются, когда RSVP рассылает свои служебные сообщения. OPQ-LSA нам нужны только для того, что если мы используем динамические, то есть если мы хотим вот эти туннели строить в динамическом режиме, например. Ну, там не то, что в динамическом режиме. Скажем, если мы хотим наше требование передать на вход OSPF протоколу, чтобы он посчитал для нас какие-то, чтобы он посчитал возможности, есть у нас вообще, например, такие пути или нет,

то для этого нам нужно учитывать, ну, как минимум, например, какие линки насколько загружены. А вот эта информация уже передается в OPQ-LSA между амортизаторами. Ну, Василий, да, как вариант, при этом эту полосу можно зарезервировать абсолютно на любом пути. То есть не только на пути, который был выбран OSPF, но абсолютно на любых линках между железками. То есть вот как вот в нашей картинке показывают, видите, у нас зеленый туннель уходит вниз, на такой, на интерконект. Давайте с вами посмотрим на примере. Посмотрим на примере. Так.

Так, у нас есть с вами вот такая вот топол... О, нет, это нехорошая топология. Вот давайте у нас есть вот такая физическая топология. У нас есть вот такая топология, уже нам всеми с вами знакомы. Предположим, предположим, ну, мы, в принципе, это легко организуем, мы это легко организуем. Мы можем добавить каким-нибудь еще здесь интерконект линки, скажем. Можем добавить... можем добавить линки вот так. Ну, как вариант. Например, мы попробуем сделать так, чтобы, например, трафик от марштизатора R2 до марштизатора, ну, скажем, R4,

чтобы этот трафик, например, ходил вот так. Чтобы этот трафик ходил вот так. Давайте попробуем это сделать. Попробуем это сделать. Так, давайте только сообразим, какие нам понадобятся устройства. Я просто хочу лишний закрыть. Нам потребуется R1... То есть нам потребуется 6 марштизаторов. 6 марштизаторов.

Мне потребуется создать дополнительные, да, дополнительные линки между R5 и R6 для начала. Давайте их создадим. Так, на марштизаторе R5 создаем интерфейс G2.56. И создаем интерфейс между R5 и R5. интерфейс G2.56. Сделаем интерфейс G2.56. Сделаем интерфейс G2.56. Далее идем на 6-й.

Создаем интерфейс G2.56. И между R5 и R5.56. И между R5 и R6. И между R5 и R6. И между R5 и R5.56. Теперь мы вновь на 4-й. Сделаем интерфейс G2.56. И с помощью R5.56. Далее идем на 4-й. Далее идем на 4-й. Далее идем на 4-й. Здесь 2-45. Далее идем на 4-й. Далее идем на 4-й. Далее идем на 4-й. 2-45. И здесь 2-44. И здесь 2-34. и идем наконец на третий интерфейс g2.36