Передача меток через BGP

Итак, ребят, сейчас я хочу с вами перейти к такому моменту, как, помните, я вам говорил, то есть основная наша задача – попытаться все-таки как-то скрыть IP-адреса. Давайте рассмотрим такой пример. Такой пример. Предположим, что на мужетизаторе R2 есть некий интерфейс. Давайте я его подниму. Так-так-так, я создам loopback 22 какой-нибудь, пусть будет IP-адрес. 22.22.22.22. Пусть будет 0 и IP OSP.

Point-to-point. Point-to-point. Для чего я это делаю? Да, если вспомните, у меня включена генерация. Хотя можно было и это у нас не делать. Ну, не важно. Суть в том, что show MPLS forwarding table для префикса 22.22.22 мне показывает no label. То есть у меня нет никакой метки. Единственное, что проблема у меня, да, очевидно, вот здесь будет. Хорошо. У меня транзитные мужетизаторы. Транзитные мужетизаторы. Я буду знать об этом префиксе. Поэтому что мне нужно сделать на мужетизаторе R2? Show run section SPF. С вашего позволения, с вашего позволения, я дам следующее. Я уберу вот этот вот network.

Я напомню, что эта команда заставляет SPF анонсировать в своей лассейке первого типа вообще все IP-сети, которые на нем есть. Да, то есть я взял вот так 150, 0, 0, 0. 5, 0, network. Соответственно, Алексей добавляет две команды. Первая добавляет loopback 150, который есть на каждом из роутеров. А вторая транспортная, скажем, транспортная команда включает OSPF на тех интерфейсах, на которых у нас действительно есть соседи. Да, и, соответственно, теперь у меня на транзитных мужетизаторах, видите, нету. Единственное, у меня же Geek1. Но это, на самом деле, роли не играет. Это мой менеджмент интерфейс. Я его могу совершенно спокойно погасить. То есть это, на самом деле, просто show IP-out.

Это статический маршрут, который прилицет поддержку SPF, да, но к нам он для нас роли не играет. Итак, то есть у меня транзитные устройства, да, транзитные устройства ничего не знают об этом префикс. Сейчас, сейчас, ребят, я поднимаю BGP. Я поднимаю BGP между мужетизаторами R1 и R2. Здесь у меня будет BGP. Будет BGP. Я надеюсь, что как базово BGP поднять, вы знаете. То есть я подниму раутер BGP 100. На, соответственно, на мужетизаторе R1 я скажу вам. Ну, давайте так, давайте прям с концом. Мы выбираем. Раутер BGP 100. No BGP Default.

No BGP Default. IP-4. BGP. Раутер ID 150.1.1.1.1. Говорю. Neighbor. 150.2.2.2.2. Remote. X100. Neighbor. 150.2.2.2. Update Source. Webac.0. Address Family. IPv4. Neighbor. 150.2.2.2. Activate. Activate. И запихну network. А, не буду никакого. Итак, Showrun. Section BGP. Совершенно простейший BGP конфиг. Извини, я тебя перебью. Дело в том, что ты использовал команду No BGP Default, которая встречается только на CCIE. Если ты прокомментируешь эту команду, было бы здорово. Я, наверное, прям в деталях могу прокомментировать

несколько поисков, когда мы познакомимся с понятиями адресных семей. Но суть какая? Ребята, смотрите, BGP – это очень такой модульный протокол. И в самом простейшем случае вы можете BGP поднять, например, по IPv4 и, например, по IPv6. Дело в том, что по умолчанию, когда вы прописываете neighbor вот такого-то, IOS автоматически пытается построить сессию с этим neighbor для обмена IPv4 маршрутом. давая команду No BGP Default IPv4, вы говорите, что вы не хотите сразу сессию строить, и, например, в будущем вы захотите обмениваться с этим neighbor, скажем, не IPv4 маршрутами, а IPv6 маршрутами. Вот. И вот эта команда, которая дается в рамках адрес Family IPv4, говорит, активировать соседа 150.1.1.1 для обмена с ним маршрутами IPv4.

Кто-то наверняка может спросить, а почему ты сказал сначала, что не надо обмениваться IPv4 маршрутами, а потом сказал, что надо обмениваться IPv4 маршрутами? Какая логика? Это конкретно в моем случае, да, то есть здесь можно было обойтись без нее. Просто дело в том, что мы, например, можем захотеть обмениваться IPv6 и не обмениваться IPv4. И, соответственно, BGP-шная сессия для обмена IPv4 нам будет просто не нужна. Да, и в этом случае мы просто сделаем так. Агресс Family IPv6 активировать. То есть сейчас это какой-то задел на будущее, потому что… Да, да, это исключительно, да. То есть на текущий момент, да. То есть вот эти команды, да, то есть одна команда выключает функционал, другая потом включает обратно. Это просто исключительно задел на будущий шаблон, чтобы у нас все конфигурации выглядели абсолютно одинаково. Нет.

Итак, show IP… Итак, show BGP, IPv4, Unicast, Summary. Как мы видим, у нас поднялась BGP-сессия, IPv4-сессия, поднялась с соседом 150222, удаленная номер автономной системы 100. И, соответственно, да, как вы знаете, вот эта последняя циферка 1 сигнализирует нам о том, сколько префиксов мы получили. Смотрим Unicast. То есть мы получили префикс 22222.0. То есть NXHOP 150222. Давайте попробуем запустить ping 2222222.0.

Сослубокно. Magic. Смотрите, ребят. То есть я запускаю ping на 2222222.0. А, например, транзитный мурциатор R5, show IP route. Он о нем ничего не знает. А ты уверен, что эти два роутера не находятся рядом друг с другом, и что трафик не идет просто в чистом IP-шном виде, например? Префикс 22222.0.6.1.0. Trace222.0.0.2.e. А в чистом IP-шном видео надеять не может, потому что она иначе была бы дрога к苻офизаторам R5. 2222222.0.0. Arts222.0.0.0.0.1. Обратите внимание, ребят, то есть что у меня происходит? Так, я не тот. Итак, что у меня происходит с пакетом?

пакет бежит с маршрутизатора R1 бежит на маршрутизатор R5. Я не буду здесь мультипассинг показывать. Дальше он бежит на маршрутизатор R3. Дальше он бежит на маршрутизатор 9. Дальше на 10. Дальше на 4. После этого на 6. И после этого на 2. Хотя транзитный маршрутизатор, как мы только с вами посмотрели, ничего о CT22 не знает. Как же так получилось? Обратите внимание, что у нас идут какие-то методы. Это, собственно говоря, для чего они нам и потребуют. Давайте посмотрим, что же на самом деле происходит на маршрутизаторе R1. Что конкретно маршрутизатор R1 делает с пакетом, который он будет отправлять на адрес 22?

Вы можете посмотреть команды show.ipcf. Обратите внимание, что... Ну, давайте вот интерфейс 2.18 я буду опускать. Суть в том, что у нас будет использоваться nexhop и будет использоваться 30-я метка. Собственно говоря, вот эту метку мы и видим в нашей трассе. Вопрос. Вопрос. Откуда мы могли получить 30-ю метку для префикса 22.22.22, если нам ее, маршрутизатор R5, сообщить никак не мог? Show. Show. Конечно. Давайте посмотрим. Show. Show. MPLS. Forwarding. Тейбл. Смотрите, давайте брать. Нас интересует столбец Outgoing.

Лейбл, очевидно. Нас интересует столбец Outgoing. Лейбл. Нас интересует, что это за 30-я метка, и что она вообще идентифицирует. Обратите внимание, вот она. Обратите внимание, с кем эта метка связана. Эта метка связана с префиксом 150.22.2.2. Как-то непонятно, откуда взялся 152.22 в этой ситуации. Давайте я сделаю вот так вот. Labels 30. Ну так. Что это за метка, да? И что вот это за префикс вообще такой, да? Почему вообще мы ставим метку, да, которая символизирует маршрутизатор R2, а не наш конейский предел? Смотрите. Show.i.p.route. Давайте посмотрим. Show.i.p.route.

22.22.22.22. Обратите внимание, что этот маршрут нам известен посредством протокола БГП. И он нам известен через кого? Через next hop 150.22.2. То есть, по сути, по сути, мы знаем, что префикс 22.22.22. Вот он. Скрывается за next hop 150.22.2. То есть, мы знаем, что чтобы достичь префикса 22.22, нам нужно как-то пакет направить в сторону маршрутизатора 150.22.2.2. А для маршрутизатора 150.22.2.2. У нас есть меточка номер 30, которая связана с этим next hop. Ребята, вот эта меточка 30 получена посредством какого протокола? Все правильно.

Да, все правильно. То есть, смотрите. Дело в том, что мы знаем о префиксе 150.22.2.2. Мы знаем об этом протоколе посредством SPF. И, соответственно, на маршрутизаторе R2 включена LDP рассылка. И в итоге меточка LDP для префикса 152.22.2. Добегает до маршрутизатора R1. И дальше маршрутизатор R1 будет использовать одну и ту же метку, чтобы достичь всех сетей, чтобы достичь все сети, которые находятся за маршрутизатором R2. Давайте сделаем вот что. Я создам новый loopback, интерфейс loopback 122, например. IP-адрес 122.122.122.122.122. Раутер BGP 100. Адрес FMI IPv4. Network 122.122.122.122.122.

Наверное, только так. Mask. Mask. Итак. Show IPvGP. То есть вот у меня есть он. Есть он. И, соответственно, если я сделаю трассу на 122.122.122.122.122. Source loopback. Non-numeric. Брать внимание, используется абсолютно та же самая метка 30. 30. То есть show IPvC. И show IPvC. 122.122.122.122. Брать внимание, абсолютно одна и та же метка будет 30. А все почему? Потому что оба этих префикса используют один и тот же NextHop. То есть таким образом, смотрите, сколько бы ни было префиксов, то есть сколько бы префиксов мы не узнавали через R2,

нам, чтобы все эти префиксы адресовать с точки зрения data plane, нам будет достаточно использовать одну и ту же лгипиметру. Более корректно, наверное, было бы show IPvC. А не show IPvC показать, потому что он же берет метку с таблицы маршрутизации, а не с таблицы BGP. Согласен, согласен. Но здесь не шибко важно. На самом деле из этой таблицы видно, что это будет BGP-шный маршрут, поскольку у нас здесь нету флага R. То есть если бы у нас был маршрут, например, условно говоря, EGP-шный, который бы наш маршрут перебивал, мы бы здесь увидели бы флаг RIP fail. Вопросы есть у вас, ребята? В принципе, можно сказать таким образом, что метка 30 в этой ситуации обозначает точку выхода,

а не конкретный префикс. Да. Да, это действительно указание на то, как мы хотим выйти из нашего MPV-собока. И, собственно говоря, вот такое, то есть вот такое вот туннелирование, это в литературе вы можете видеть название MPLS-туннелирование. Да. То есть когда мы трафик инкапсулируем внутрь MPLS-а, ну, естественно, наше транзитное устройство, да, у нашей сети назначения абсолютно ничего не знают. Естественно, когда мышки зато получают пакет, да, он оперирует, он оперирует только, ну, смотрит только на ту метку, на которой находится между стандартными L2 и L3 заголовком. Эта концепция очень похожа на то, что было во Frame Relay в свое время, когда, ну, точнее, коммутаторы Frame Relay, они оперировали только понятием входной интерфейс-входная метка

и выходной интерфейс-выходная метка. Они получают с одной стороны какой-то пакет, ну, кадр Frame Relay, если хотите, у которого стоит какая-то метка, они смотрят соответствие входной метки входного интерфейса и выходной метки выходного интерфейса, обменивают метку и пересылают все это дальше. Да. Я даже помню, я когда сдавал преподавательский экзамен с CSI, даже приходилось настраивать Frame Relay коммутатор на базе IOS. Frame Relay коммутатор или коммутацию Frame Relay на маршрутизаторе? Потому что, насколько мне известно, ЦИСК никогда не делала Frame Relay коммутатор. Да, я имею в виду, ну, да, проходилось настраивать Frame Relay коммутацию на раутеры. Хорошие были времена, когда Frame Relay был даже в CSI, но, к счастью, этого больше уже нет. Ну, его, да. Ну, его. Это Lego, если оно нам не нужно. Мы будем бороздить просторы Вселенной на наших кораблях будущего.

Ну, с одной стороны корабли будущего, а с другой стороны концепция обмена метками в MPLS, ну, именно в SWAP меток. Это в чистом виде коммутация Frame Relay. Вопрос. Пакеты со служебной информацией BGP прячутся за MPLS меткой. Ты имеешь в виду TCP-сессию, да, BGPшную? Если я правильно понимаю. Ты знаешь, я никогда не смотрел Dump, но мой ответ будет скорее да, чем нет, потому что BGP – это не что иное, просто как Application. И, соответственно, BGP будет подчиняться тем же правилам, что вот 150.222. То есть мы будем использовать... То есть, собственно говоря, мы берем BGP-данные, инкапсулируем их внутрь TCP, инкапсулируем внутрь IP и прячем внутрь 30-й метки.

А у тебя, случайно, нет тут в AirShark, чтобы показать, как выглядят пакеты, которые инкапсулируются в MPLS? Я попробую. Просто было бы как раз здесь очень удобно посмотреть, что и боевые данные, которые идут по MPLS, ну, например, там, PING, и та же самая BGP-сессия действительно упаковываются, действительно помечаются метками и обрабатываются. Скорее всего, это в UBM. Я не дам гарантии, что мы здесь... По-моему, в верле должен быть встроенный... Должен быть встроенный в AirShark. Наверное, это в VIRL сервере. Я не вижу. Мы можем это сделать, например, завтра, когда, скажем, будет немножко больше времени на подготовку. Ну, да, то есть мне это нужно будет просто посмотреть, да, потому что я где-то видел, что ребята запускают в AirShark напрямую из верла, но вопрос в дело в том,

что у меня VIRL как бы... Он не совсем открыт, потому что у меня есть некая оболочка, да, и у меня доступ к этому верлу только через эту оболочку. Ну, ребят, я посмотрю, можно ли запустить, можно ли запустить. Вот. И постараюсь там к следующему занятию вам дать ответ. Можно ли снифть пакеты или нельзя. Что еще ты нам сегодня интересного расскажешь? Ты знаешь, по сути, вот эти... То, что мы прошли на прошлом занятии, то, что мы прошли сегодня, это было... Это и было моим планом на... На эти два занятия. То есть мы вчера прошли просто чуть-чуть больше, чем я планировал. Вот. Так что, пожалуй, на сегодня у меня все, потому что мы, по сути, мы, на самом деле, вплотную подошли к понятию MPLS VPN, и мне бы не хотелось бы его начинать там и закончить, там, если он говорит, через 10 минут.

Я просто предлагаю этому посвятить завтра все занятия разбросанных концепций. То есть что такое? То есть, на самом деле, мы с вами сейчас смогли построить абсолютно базовый такой MPLS VPN, да, то есть мы когда смогли проконулировать трафик. Завтра же мы с вами уже будем поговорить о том, как мы можем разделять наших кастомеров. Это прекрасная тема для завтра. Слушай, мне пришла в голову сейчас идея, поскольку у нас есть еще немножко времени, может быть, включить тот снифер, который есть в Илусе, ну, или хотя бы даже просто дебаг какой-нибудь, показать, что CISC умеет показывать сегменты, которые через нее проходят. Да, теоретически это сделать можно. Давай попробуем на мужецизаторе, например, на мужецизаторе R5. Скажем, дебаг интерфейс E2.15. Тлик-тлик-тлик-тлик. А, дебагол?

Нет, это мне не нужно. Успел он их отдебать. Сейчас его будет еще некоторое время, наверное, колбасить. Давайте я посмотрю, может, у меня есть какой-нибудь. А, мужецизатор. Мужецизатор R9. Вполне подойдет. У него всего один интерфейс. Дебаг MPLS. Дебаг MPLS paid. Ну и запустить как? Да, давай. Давай, с мужецизатора R1. Pink. Set 22. 150.222, скорее всего, не через... Нет, он через R9 в любом случае будет проходить.

Он через R9 в любом случае будет проходить, поскольку R9 просто стоит прям вот. Он стоит прям на пути следования. Вот он. Но как-то подозрительно на нем нет никакой активности. Да. Ну, на самом деле, show MPLS interfaces. Show MPLS forwarding table. Вот видишь, у нас количество байт 17601. А терминал монитор там есть или что-то там в духе? Да, сейчас посмотрим. Да, почему-то он их не чекает. Так, и что мы сейчас... Так. Цена монитора. Вообще, когда... Console already monitors. Дебаг интерфейс D2.39.

Так. Так. Это OSPF. Я знаю, что в Иусе это прям хорошо видно. Он прям показывает, что к нему пришла такая-то меточка и ушла такая-то меточка. Не знаю. Честно. Сходу вам... А может, ты запустишь какой-нибудь пинг, и мы увидим эти самые пинги? Ну, пинки-то я могу запустить. Нет, с дебагом я не веду. Да это я понял. Но... Сейчас, давай. Дебагом. Дебагом. Плс. Пэкет.

Дебагом. Плс. Пи. Вот. Не надо. Ну, по сути, здесь дебага-то больше нечего, на самом деле. Пинг. Пусть будет 22, 22, 22, 22. Сурсов. Бэк. Ноль. Пит. Упс. Многовато, видимо. Нет, нету. Я не уверен, что... Понимаешь, теоретически можно было бы отключить сет в момент, когда разрушится MPoS. Не скажу сходу, как это дебажить. Ну, тогда ставим это на завтра, и заодно и вешаг покажем, и штатный дебаг. Я посмотрю, да, можно ли. Да, ну, видишь, у меня довольно много пакетов.

Я не уверен, что оно прям постоянно обновляется. Хотя вот, ну, вот видишь, вот они. Идут. Было 134, да, стало там 196 тысяч. То есть видно, что, как бы, количество пакетов увеличивается. Ну, видишь, и причем оно, видишь, увеличивается в две стороны, да? То есть в сторону за 3R1 и в сторону за 3R2, да? То есть эхо-реквесты и эхо-реплай. Иногда говорят, что в случае, если мы запускаем какой-то трафик через MPLS, то есть в этом случае строятся два LSP. Один туда, другой обратно. Что это два независимых туннеля друг с другом никак не связаны. Да, конечно. То есть, смотрите, мы когда... То есть у нас... Мы трафик всегда, на самом деле, любой посылаем в одну сторону. Да, то есть он у нас идет по пути от точки А до точки Б. Соответственно, путь от точки А до точки Б характеризуется LSP, да, от А до Б. Дело в том, что обратный путь, он не обязательно будет проходить по тем же самым каналам связи.

Да? Ну, конечно, в большинстве случаев это так, да, в большинстве случаев это так, но это необязательное условие. Поэтому, на самом деле, ребята, обратный пакет может быть совершенно другим путем и будет характеризоваться абсолютно другим LSP. Окей, тогда на сегодня я предлагаю закругляться. Вопрос был про... Есть, да. Вопрос от Булата. А что лейбл, это включается в implicit null метки? Можно же увидеть в mplsldp bindings или что-то путаю. Блад, смотри, тут дело такое. Есть так называемый implicit null и есть explicit null. По сути, implicit null – это когда у тебя явно передается метка, которая символизирует число 0. Для этого зарезервирована метка номер 3. Неявный 0, да, неявный 0. Так, я, наверное, немножко запутался в терминологии.

Implicit – это неявный, да, explicit – это явный. Соответственно, когда мы используем неявный 0, мы на самом деле просто берем и снимаем верхнюю метку, когда передаем пакет к последнему хопу. Эта тема, я не уверен, что у меня хватит времени, я прям уж очень подробно рассмотреть, она очень подробно рассматривается в книжках, которые так или иначе охватывают mpls quility of service. То есть, по сути, дело вот в чем. В стандартной имплементации, в стандартной имплементации, давайте, сколько у нас там есть, еще пару минут. У нас есть еще пару минут. При стандартной настройке у нас получается следующее. У нас есть R1, например, R2, R3 и R4. Соответственно, вот у нас на R4 есть некий префикс X. Если вы на мастеризаторе R3 посмотрите show mpls forwarding table для префикса X,

вы увидите там такое название, как popping. Pin Ultimate Hop Popping. По сути, это говорит нам о том, что нам необходимо снять mpls-ную метку. Более строго говоря, нам необходимо снять mpls-ную верхнюю метку. То есть, бывают случаи, когда у нас придется более одной mpls-ной метки в пакете. То есть, мы снимаем верхнюю mpls-ную метку и передаем ее в сторону мастеризатора R4. Дело в том, что сам mpls-ный пакет состоит из некоторых частей. То есть, первая часть mpls-ного пакета – это непосредственно сама метка. Далее есть один бит, который называется stockbit. Он может принимать значение 0 или 1. По сути, он нам характеризует то, как бы последняя эта метка в mpls-ном стеке или нет. Дальше, дальше. Здесь есть experimental. То есть, у нас есть 3 бита.

0.1.2. Извини, я тебя сразу перебью. Оно уже лет 20, как не называется, experimental. Книжки, которые говорят, что это экспериментальное поле, они немножко устарели. Поле называется классов сервис так же, как в изернете. Я с тобой буду не согласен. Почему? Потому что даже в последней версии EOS я создам policy.mac. Policy.mac.experimental. Class. Class. Default. То, что в EOS называется это поле так, означает, что авторы EOS тоже не всегда обновляют номенклатуру своих полей. Да. Стоят на пилос эксперимент. По сути своей, это просто некий 3 бита. 0.1.2, которые могут использоваться для… Ну, в частности, они могут использоваться в принципе для чего угодно, но в основном они используются для киллитер сервис. Для киллитер сервис. Соответственно, здесь вы должны понимать, что, соответственно, то есть снимается, да, то есть у нас снимается…

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

То есть он, по сути, понимает, что эта метка была поставлена только для того, чтобы вот он смог проанализировать experimental биты. Если вы используете неявный ноль, да, то эта метка просто снимается за хоб до. Вот и все. Вот. Еще вопросы? Есть еще такое мнение, что концепция PHP, вот эта Penalty Made Hope Popping, она нужна для не столько quality of service, сколько для того, чтобы немножко разгрузить последний роутер в цепочке, который является выходной точкой. Потому что если этого не делать... Да, говори. Может быть, и было когда-то актуально, когда мурсизаторы были слабенькими программами, а сейчас все равно в любом случае все программится на асике, и там, ну, как бы обсчитать первый раз вот это все дело и запушить, конечно, решение на линейную плату,

ну, потом обрабатываться уже без разницы. Один лукап для этого нужно было сделать или два, поскольку все равно как бы на линейке это делается за один поиск. Безусловно. Просто придумывалось это все тогда, когда на роутерах были килобайты, ну ладно, мегабайты памяти и килогерцы частоты. Поэтому для них, для тех роутеров 20-30 градусов было актуально. Да, и с кем все правильно, то есть транзитный роутер анализирует исключительно наши меточки. То есть они не заглядывают в поле IP-хедера. И на это дает нам возможность того, что, да, вот у нас вот в моем конкретном примере, да, на транзитном мурсизаторах не было вот префиксов этих 22-х и 122-х. Немножко прокомментирую. Здесь неправильно говорить про второе и третье уровни, поскольку модель VCI не относит протоколы к уровню. Дальше, в общем, роутеры, безусловно, обрабатывают заголовки Ethernet. Они определяют, им адресован этот пакет или не им по MAC-адресу. Дальше они не заглядывают в IP-заголовок или в то, что вы положили в MPLS,

потому что это не обязано быть IP, это может быть все что угодно. Это может быть E1, это может быть ATM, это может быть IPv6, это может быть Ethernet кадр. То есть им все равно, что там внутри лежит, они не анализируют содержимое этого вложения. Но они смотрят на IPLS-нометку, которая простая и которая обрабатывается роутером за один лукап таблицы.