Структура курса и MPLS основы

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

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

это VPN. VPN-ы различны. VPN-ы могут быть как второго уровня, так и третьего. Мы там в течение курса еще чуть более подробно поговорим о том, что значит VPN-третий уровень, что VPN-второго уровня. Да, ну, по сути, это, условно говоря, вы можете арендовать услугу, скажем, сервис-провайдера для связанности ваших офисов, скажем, в Москве и Петербурге. Ну, и, упрощенно говоря, если там Москва и Питер будут находиться в одной подсетке, это, можно сказать, что VPN-второго уровня. Если они будут находиться в разных подсетках, это, собственно говоря, будет VPN-третий уровень. При этом, помимо VPN-а, часто используется такая технология, как Traffic Engineering, но в основном она используется сервис-провайдерами, по крайней мере, в Enterprise я не видел ни одной реальной имплементации. Суть Traffic Engineering заключается в максимальной утилизации

всех имеющихся линк. Как это делается? Опять же, я надеюсь, что хватит времени. Я, в принципе, хоть в адженде этого не анонсил, но что-то мне подсказывает, что у нас будет время поговорить с Traffic Engineering хотя бы о самом-самом базовом. Алексей, а расскажи, пожалуйста, что такое Traffic Engineering? Потому что в CCNA и CCNP тут понятие, в принципе, не встречается. То есть, я хочу более подробнее. Да, не переживай, сейчас буквально мы чуть-чуть попозже к этому перейдем, буквально, не знаю, в течение минут, наверное, 10, когда будем вспоминать о том, как передаются пакеты в классических сетях. Кстати, слушай, Нагентин, у меня к тебе вопрос. Я когда начал шарить, у меня пропал чат. Я не могу найти кнопку, как его вернуть. Все, нашел. Нашел, да, там наверху такая кнопка есть. Да, видимо, он очень сильно был скрыт на Mac'е, и я реально его искал-искал. Итак, давайте подумаем с вами о том,

какие у нас есть, ну, не то чтобы проблемы, а как передаются пакеты с данными. Да, ребят, сразу говорю, что, особенно те, кто слушал курсы у Иннокентия по CCNA, по CCNP, вы наверняка заметили, что наверняка Иннокентия делает различия на таких понятиях, как кадр, сегмент, пакет и прочее. Я в течение нашего курса под пакетом могу подразумевать, как, собственно говоря, как некие данные, да, плюс заголовки третьего, четвертого уровня, так и, собственно говоря, вот всю сущность вместе, что называется, фреймом. Просто для того, чтобы, ну, во-первых, чтобы не усложнять речь, а во-вторых, ну, я вам скажу честно, так большинство сетевых инженеров просто гораздо привычнее, и, ну, на работе на той же, да, мы все между собой используем искусственное понятие пакет. Так, предположим, что у нас есть некая сетка,

которая, например, состоит из нескольких муштизаторов. Вот, например, есть некие муштизаторы, R1, R2, R3, R4, R5 и R6. Предположим, что эти муштизаторы относятся к так называемому транзитному оператору связи. Что такое транзитный оператор связи? Да, то есть, по сути говоря, вот если у нас вот это все облачко является просто оператором, да, то есть, который вы часто, ну, можете наблюдать, который называется как ISP, интернет-сервис-провайдер, то, в общем-то, все сервис-провайдеры можно поделить на две большие категории, да, то есть это транзитные операторы и, скажем, некие операторы, которые могут сами представлять вам какой-либо контент. Транзитный оператор – это оператор, основная роль которого заключается просто

принять трафик где-то на входе и выплюнуть трафик где-то на выходе. То есть такой самый, знаете, классический оператор, который только можно придумать в своей жизни. То есть в том, что у него не хостится никаких сервисов, у него, условно говоря, нету там никаких видеосерверов, он не хостит у себя какую-то там условную там Яндекс.Клауд, ну, что-то в таком духе. Сколько вошло, столько вышло. Да, ну, в идеале, да, в идеале. Соответственно, есть еще провайдеры, которые иногда вы можете, знаете, особенно в России их, может быть, не так сильно называют. Есть такая подкатегория ASP, да, где A расшифровывается как Application, то есть это такой некий оператор, который вроде бы, с одной стороны, предоставляет услуги связи, например, конечным абонентам, каким-то интерпрайзам, но и помимо этого у него могут хоститься там какие-то приложения.

То есть, ну, например, там где-нибудь там, может быть, какие-то там видеосервисы, через него могут быть доступны. Суть в том, что какая-то часть трафика терминируется в области этого провайдера. Предположим, что мы решаем такую довольно-таки классическую задачу через провайдер. Вот у нас есть пакетик A, извините, у нас есть подсетка A, есть некая подсетка B, и нам нужно передать трафик из сети A в сеть B. Очевидно, очевидно, что внутри нашего сервис-провайдера, состоящего, например, из шести маршрутизаторов, на всех маршрутизаторах должен быть запущен какой-то протокол маршрутизации. Это может быть либо протокол динамической маршрутизации, либо статика. Здесь абсолютно не важно. Важно вот что. Важно же первое. У нас абсолютно все транзитные маршрутизаторы на сети, то есть что R1, что R3, что R5, что R6,

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

Соответственно, нашли там свой MAC-адрес, обработали пакетик, посмотрели IP-заголовок, сравнили destination IP-адрес со своей таблицей маршрутизации, нашли выходной интерфейс, да, и перекинули пакет дальше. То есть, по сути, решение, то есть, в общем, нам на каждом ходе приходится делать, принимать то или иное решение о маршрутизации трафика, да. То есть мы должны принять решение первое, можем ли мы этот пакет отмаршрутизировать, то есть, если мы его можем отмаршрутизировать, то куда? То куда? Я еще слышал, Алексей, что раньше маршрутизаторы принимали маршрутные решения для протокола IP с нефиксированным временем, недетерминированным временем. То есть пакет приходил, и заранее было неизвестно, сколько этот пакет будет обрабатываться маршрутизатором. Потому что маршрутизация был процесс итеративный. Ну, собственно говоря, да. Наверное, это было в те времена, когда маршрутизация осуществлялась с помощью CPU.

Слава богу, я не знаю, последнее время, последние, я не знаю, несколько, ну, десяток лет точно, большинство маршрутизаторов, скажем так, enterprise-класса, они более или менее аппаратные. То есть мы об этом еще с вами поговорим. То есть в том, что, естественно, когда пакет прилетает на маршрутизатор, он не отправляется на обработку центральному процессору, все решения, они заранее инсталируются в существующей линейной плате. Но единственное, конечно, такое свойство, оно, скажем так, не относится к таким маршрутизаторам, как к софтовым. Здесь я говорю о более-менее серьезных платформах. То есть, конечно, если вы возьмете там какой-нибудь маршрутизатор, условно говоря, там CSR1000V, кстати, на котором будет построена наша лабораторная работа, естественно, там все обрабатывается программно. У таких маршрутизаторов, как, скажем, ISR, там, G1, G2, G3,

которые по сути своей являются также абсолютно софтовыми роутерами, то есть, если вы его разберете, вы увидите там, по сути, X86-архитектуру, которую, в принципе, вы можете собрать там из своего настольного ПК. Ну, плюс там... Давай называйте еще свои номера микротик. Да, ну да, что-нибудь в таком духе. Ну ладно, я, на самом деле, немножко отвлекся. Но все в том, что мы принимаем решение о маршрутизации hop-by-hop, и это решение накладывается на то, что на всех транзит-коммунистизаторах, да, нам нужно знать о сети назначения, ну, сейчас о сети назначения BN, да, в нашем случае. А это приводит к интересному нюансу. Представьте, что вы, да, обслуживаете там какой-нибудь сервис-провайдер, какой-нибудь магистральный, условно говоря, какой-нибудь Ростелеком, и, собственно говоря, вы просто передаете пакет вот более маленьких провайдеров, да,

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

то есть, использовали шеститонники в качестве бордер-амортизаторов, то есть, поднимали на них БГП и принимали от них все префиксы от своих апплинков. И в какой-то момент люди начали замечать, что линейные карты начали крэшиться, уходить в unexpected атрибуты, почему-то там не все префиксы стали появляться. Случилась очень незанимательная вещь. В какой-то момент количество префиксов в интернете перевалило за 512 тысяч. А огромное количество линейных плат в себе смогут терминировать только 512 префиксов заинсталлировано. Ну, 512 тысяч, я имею в виду. Соответственно, вы должны понимать, что 900 тысяч префиксов, какой-нибудь, я не знаю, ISR 29 тысяч, наверное, не переварит. А если переварить, то переваривать их будет, на самом деле, очень-очень долго. То есть встает вопрос, на самом деле, о цене вот этого транзитного оборудования. То есть, ну, что-то, наверное, минимальное, который, минимальный план коммунистезатора, который на текущий момент может себе спокойно содержать

вот эти 200К, это что-то типа ISR 1001X. Что-то вот от этого нужно плясать. Ну, желательно, там, использовать, там, более старшие модели, там, что-то типа 1200. Ну, лично я рекомендую заказчикам в качестве бордеров. Ну, либо что-то более серьезное, там, по необходимости, там, какие-нибудь, скажем, My Star 9000. Ну, опять же, на самом деле, с таким ростом количества префиксов тоже возникают проблемы, потому что очень многие современные карты, там, на тех же, на тех же шеститонных, на тех же, там, я не знаю, о ISR-ах, у некоторых есть лимит миллион префиксов. Я уверен, что он скоро, как бы, будет, ну, перебит. Поэтому, в общем, это деньги. И представьте, да, что вам нужно, у вас сетка у провайдера может содержать, я не знаю, там, ну, например, 20 транзитных мартизаторов. И что нам делать? Ну, как бы, ставить 20 дорогих железок просто для того, чтобы они пакеты из одного, как бы, с одного интерфейса на другой перекладывали. Ну, наверное, это не очень.

Обратите внимание, обратите внимание, что, так, черный, представьте, что у меня есть сетки не только А и Б, да, но у меня есть, например, сетки С и Д, скажем. С и Д. То есть, это, вроде бы, хоть это и разные заказы, ну, скажем, разные владельцы могут быть у этих подсетей, но трафик, который бежит, например, из сети А в сеть Б и из сети С в сеть Д, у них, у такого трафика будет что-то общее. А в частности, общим у них что будет? У них будет выходная точка. У них будет выходная точка. То есть, сети Б и Д для нашего сервис-провайдера, они, как скажем так, могут быть скрыты за выходным амортизатором R6. Собственно говоря, на самом деле, задача MPLS, задача MPLS в том числе, примерно в следующем.

Попытаться разгрузить все наши транзитные амортизаторы. То есть, постараться убрать требования на терминацию вот этих 900 тысяч префиксов. Как этого можно достичь? Ну, очевидно, нам нужно какое-то решение, чтобы, когда пакет попадает на амортизатор R3, чтобы ему не пришлось анализировать IP-пакет, вернее, скажем так, чтобы ему не пришлось знать о сети назначения B и D. Самым очевидным решением, да, для этого является построение туннеля между амортизаторами R1 и R6. То есть, если вы построите любой абсолютно туннель между R1 и R6, это, например, может быть в самом простейшем виде может быть GRE-туннель, это может быть IP-to-IP-туннель, я не знаю, это может быть L2TP, в общем, ребята, это может быть все, что угодно. Например, вы строите GRE-туннель,

внутри этого GRE-туннеля запускается какой-нибудь протокол амортизации, например, тот же BGP. Соответственно, что у нас будет? Соответственно, если пакет летит из сети А в сеть Б, соответственно, на амортизаторе R1, он попадает, например, в этот, скажем, в этот GRE-туннель, к нему навешивается новый, к нему навешивается новый IP-заголовок, соответственно, вот у нас был новый IP-заголовок, то есть он за собой скрывает старый IP-заголовок, и таким образом мортизатор R1 выплевывает красный пакетик во внешний мир дальше. Соответственно, мортизатор R3, мортизатор R3, чтобы передать пакет по назначению, необходимо проанализировать только внешний IP-заголовок, у которого в качестве destination IP-адреса будет кто стоять, очевидно, будет выступать адрес мортизатора R6.

Но, таким образом, пакет спокойненько себе долетит до мортизатора R6, в нем снимется этот GRE-заголовок, и пакет спокойно отмортизируется внутрь сети Б. То есть, разница между такими двумя подходами заключается в том, что роутер R3 все равно анализирует IP-заголовок, но он при этом не должен хранить 900 тысяч префекций. Конечно, в этом случае ему, по сути, достаточно знать только о двух IP-адресах, условно говоря, то есть, это должны быть IP-адреса мортизатора R1 и мортизатор R6. В этом случае, соответственно, пакеты, которые бегают между сетями, которые терминируются за мортизаторами R1 и R6, они спокойно себе будут отмортизированы. Естественно, все транзитные мортизаторы также должны знать о том, как доставить пакеты либо до R1, либо до R6. Ну,

собственно говоря, вот таким образом, с помощью простейшего горе-туннеля вы можете сделать концепцию такую фрикора, то есть, когда у вас транзитные мортизаторы могут быть довольно-таки бюджетными, глупыми, особо ни о чем не знать, не обладать каким-то серьезным требованием по памяти, по масштабируемости и прочее. У вас может на самом деле возникнуть вопрос, да, вообще для чего нам еще какой-то MPLS придумать, если у нас есть ГРЕ, да, давайте его как бы использовать. Как я сказал, как я сказал в самом начале, основное распространение MPLS получил посредством своей возможности строить различные VPN-ы, строить различные VPN-ы. С помощью ГРЕ, с помощью ГРЕ, нам, например, очень сложно сделать, будет сделать выделенный VPN для, то есть, например, у нас вот сеть С и сеть

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

совершенно спокойно может быть пересекающееся адресное пространство. И вот с таким подходом здесь будут проблемы. Я надеюсь, как вы все знаете, амортизатор вам не даст назначить на два интерфейса IP-адреса из одной и той же подсети. Ну, вернее, скажем так, некоторые железки дадут, например, такие как Cisco Nexus, но при этом один из интерфейсов, который сконфигурирован позже, он будет всегда находиться в состоянии administrative shutdown. То есть, суть в том, что два функционирующих интерфейса с IP-адресами из одной и той же подсети вы не получите. Это раз. Второе, второе, с помощью горея-туннелей вот так вот, вы можете сделать VPN-ы третьего уровня. То есть, это когда у вас сайт например, Москвы, да, офис Москвы и офис Петербурга находятся в разных подсетях. Однако,

с помощью вот горея без всяких дополнительных примочек сделать VPN второго уровня, ну, скажем так, сложно. А почему сложно? Казалось бы, горея позволяет себя инкапсулировать любой трафик, в том числе и кадры Ethernet. То есть, твое дело забриджить просто два интерфейса и все. Вот. Может быть, их можно, конечно, забриджить. Но, насколько я понимаю, у нас могут быть, у нас возникнут проблемы, во-первых, с масштабируемостью. И, честно говоря, я не очень представляю, как это будет работать в PROD. Нам придется, в любом случае, если мы будем делать бриджинг, нам придется строить огромное количество горея туннелей, которое, как минимум, будет равно количеству L2 VPN-ов наших заказчиков. А если кто-то захочет VPLS, то есть... А если кто-то захочет у себя сделать, скажем, мультипоинт,

то есть, у него может быть не два офиса, а, скажем, 10 офисов. И всем между ними нужна связанность. Да. Или связанность нужна не всем, а, скажем, связанность, может быть, нужно организовать связанность подопологии Hub & Spoke, то есть, когда у нас есть некий центр, есть ярко выраженные Spoke, то есть, такие маленькие офисы, тут могут возникнуть проблемы. По сути, MPLS решает эти задачи, то есть, обе эти задачи, то есть, построение масштабируемых VPN-ов второго и третьего уровня. Он как-то автоматизирует создание тоннелей? А вот об этом вы узнаете в следующем занятии. О том, как работает Control Plane, как работает Data Plane, потому что, как таковых, туннели, естественно, там строятся. И я не могу сказать, что они полностью автоматизированы

из коробки, нужна некая работа администратора, но, по сути, вся работа администратора будет заключаться в том, что нам нужно будет просто, то есть, нам нужно будет настроить некую базовую связанность между нашими марштизаторами, между теми марштизаторами, на которых будут терминироваться непосредственно сервисы, то есть, где будут наши заказчики сидеть. А дальше нам нужно просто будет указать, то есть, сказать всем марштизаторам, вот, на тебе сидит заказчик, условно говоря, А, на тебе сидит заказчик, Б. и будь добр организовать туннельчики между всеми заказчиками А. Мы чуть попозже с вами, наверное, через одно или через два занятия увидим на практике, как это делать. А что ты говоришь, похоже на магию? Ну, а ты знаешь, когда ты учишь что-то новое, оно всегда похоже на магию, это точно так же, как я впервые, когда увидел ИС-Ай, вообще, когда я в первый раз увидел с ДНС, я тоже подумал, что это магия.

Но когда разбираешься в технических аспектах работы, на самом деле ты понимаешь, что все решения, которые применяются в сетях, они так или иначе похожи. Да, где-то используются разные типы ингапсуляции, где-то используются разные протоколы для контрплейн-сигнализации, используются датаплейн разный, но, по сути, везде принцип более-менее один и тот же. То есть, независимо от того, какой тип технологии надо выбирать, например, MPLS для L2 VPN, либо это может быть VXLAN, либо это может быть OTV. Логика, логика одна и та же. sailоризация, их гор� comercial, fue творческие realise, воссийская, за свое России,