Транспорт IP-MPLS (3)

Продолжаем говорить с вами про IP-сети в провайдерских сетях. И следующая тема, которая у нас есть теоретическая, это протокол BGP. То есть у нас осталось две большие темы рассмотреть здесь. Это BGP и MPLS. Вот первая, которая есть в абсолютно любой провайдерской сети. BGP — огромный толстый протокол. Мы его чуть-чуть рамочно изучаем в курсе ICND2. То есть буквально то, что он включается, и можно по нему протащить какие-то маршруты. Мы его чуточку более детально изучаем в курсе по роутингу. Ну и, соответственно, здесь мы тоже его, ну, в общем, в большом счету детально изучать не будем. Мы его посмотрим, что он есть, посмотрим, что он включается, посмотрим, какие режимы работы у него бывают. Но детали работы BGP, особенно в провайдерской сети, мы с вами детально разбирать не будем. Потому что этих деталей тупо банально очень много. И мы с вами просто закопаемся. То есть мы с вами ознакомимся, что BGP бывает, посмотрим на какие-то его особенности работы, и дальше уже на специфическом обособленном курсе, посвященном BGP в провайдерских сетях,

будем изучать детали его работы. BGP — это реально огромный толстый протокол. То есть только его можно изучать чисто неделю, без каких-либо особых проблем. Собственно говоря, мы так собираемся делать. BGP — протокол стандартный. То есть на него есть RFC, базовый RFC, актуальный на сегодня версии, это 4271. Но на самом деле вот это вот 4271 — это просто скелет протокола. А дальше он обвешивается всякими свистелками, перделками. И вот эти свистелки, перделки, они тоже все имеют свои отдельные RFC, то есть свои отдельные стандарты. Может быть гипотетически такое, что у вас конкретная железка будет работать по BGP. Да, BGP в ней поддерживается. Да, абсолютно стандартный. Но свистелок и перделок в ней не будет. То есть базовый такой BGP, который ничего толком не умеет. Как можно пойти в автосалон и купить там машину, и эта машина будет в минимальной-минимальной комплектации. Но зато она будет дешевая. А можно пойти в другой автосалон и купить там ту же самую машину, ту же самую модель, но, соответственно, обвешанную всякими дополнительными опциями, за которые вас попросят деньги,

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

был запущен протокол EGP, протокол классовый, протокол, который решал задачу синхронизации таблиц, но при этом он не отвечал требованиям, предъявляемым к современным протоколам динамической маршрутизации. Когда мы говорим, что у нас есть динамическая маршрутизация, мы решаем четыре задачи. Первая — это, во-первых, рассказать про то, какие сети подключены к нам непосредственно. Во-вторых, это узнать, какие сети подключены к кому-то еще. То есть узнать про то, что вообще сети какие-то другие существуют, помимо наших собственных. Третья — если есть один или более способов добраться до удаленной сети, надо выбрать среди них один наилучший и в скобочках, не содержащий петель. И четвертое — это то, что если вдруг у нас наиболее актуальный маршрут, наиболее выгодный маршрут перестает быть доступен, то надо переключиться на другой маршрут. Вот EGP — exterior gateway protocol, древний старющий протокол, он не умел работать с петлями. Он умел работать только в сетях с топологией звезда. Ну, соответственно, надежность таких сетей, она была, конечно, ниже Plyntus.

Но, тем не менее, оригинальный интернет, он работал именно так. То есть все связи соединялись между собой не как попало, а через некий централизованный узел, и вот EGP там вполне себя комфортно чувствовал. Не путайте, пожалуйста, EGP как класс протоколов динамической маршрутеризации, exterior gateway protocol, и конкретный протокол RFC827, exterior gateway protocol — это разные вещи, разные сущности. То есть EGP как класс протоколов — это просто все протоколы, которые умеют передавать данные между автономными системами. А конкретно протокол RFC827 — это вот конкретный протокол, у которого есть конкретный формат пакета, который умеет делать конкретные вещи. Это разные вещи, несмотря на то, что выглядят они абсолютно одинаково. То есть в обоих случаях называется это exterior gateway protocol. Это вам не это, как говорят в армии. Почему я на это внимание ваше обращаю? Потому что кое-где в конкретных реализациях BGP будут встречаться термины EGP, термин аббревиатуры EGP.

И вот надо будет понимать, что в некоторых случаях идет отсылка к конкретному протоколу, а в некоторых случаях к вообще всем протоколам динамической маршрутеризации, предназначенных для передачи данных между автономными системами в целом. Актуальная редакция BGP у нас будет иметь версию 4. То есть вот версия 4 — это тот BGP, с которым приходится работать сегодня. Этот BGP может работать с данными разной природы. И есть дополнительный RFC 4760, который указывает, что BGP у нас может быть многопротокольным. Multi-protocol extensions — это дополнительная свистелка или переделка, как угодно для BGP, которая позволяет перетаскивать данные разных так называемых адресных семейств. То есть мы можем сказать, что нас интересуют маршруты IPv4, маршруты IPv6, маршруты L3VPN, то есть пользовательские IP маршруты,

которые надо ставить в конкретную таблицу маршрутизации, а не в глобальную таблицу маршрутизации. Ну и разные другие. BGP будет работать принципиально иным образом по сравнению с теми протоколами, которые мы уже разобрали в курсе. То есть что RIP, что EGRP, что SPF разных версий — это все протоколы, которые предназначены были для работы внутри автономной системы. Они автоматически обнаруживали соседей, они использовали активный мультикаст для обнаружения соседей, они с кем попало дружить, лишь там по руль, пока надо было показать бы, и чтобы сосед был непротиворечивым настроем. BGP — это протокол, который не предназначен для того, чтобы с кем попало дружить. То есть BGP будет не использовать мультикастовое обнаружение соседей. Он будет просто заранее должен знать, с кем конкретно он может подружиться. Потому что если у вас есть ваша автономная система и есть соседняя автономная система, и у вас место стыка этих автономных систем хорошо известно, ваш роутер, который выполняет стык между автономными системами,

хорошо известен. Роутер соседа, который со стороны соседа смотрит на вашу автономную систему, тоже хорошо известен. IP-шники их известны заранее. Поэтому в BGP используется TCP-шное подключение на хорошо известные IP-адреса. Если вы хотите работать по BGP, то, как правило, в большинстве случаев вы с обеих сторон должны будете прописать IP-шники соседей заранее, до того, как начнется работа. И очень редко можно заставить BGP просто соглашаться с тем, что кто-то к нему подключается по TCP и начинает там BGP-шную сессию ставить. Не любое оборудование это поддерживает. Например, CISC поддерживает динамические группы. А вот оборудование некоторых других вендоров не поддерживает. То есть вы не можете взять и сказать, ну-ка, подключись к соседу, несмотря на то, что на соседе мы не прописаны в качестве соседа. Чаще всего мы прописываем именно на обоих роутерах, которые будут дружить между собой, связь заранее до установления соседства. На одном роутере говорим, как зовут соседа, на другом роутере говорим, как зовут соседа.

После этого поднимается связь. BGP ставит TCP-шную сессию на 179-й порт, и, соответственно, если у вас на обоих роутерах есть возможность установить соседство, кто-то, один из них, начинает сессию первый, ставит сессию на 179-й порт соседа, и из-под случайного динамического порта, и вот эта сессия начинает работать. То есть не то, что две разные сессии одновременно друг на друга роутеры ставят. Один поставил первый на 179-й порт соседа, дальше вот эта сессия нормальная, хорошая, главное, чтобы IP-шник, под которого она ставилась, был правильный. Есть нюанс, что, в принципе, гипотетически может быть такое, что TCP одновременно два роутера друг на друга будут ставить с 179-м портом сессию, то есть один роутер на другого отправит син-пакет, и еще пока не получил син-плюс-ак, и другой роутер тоже одновременно в этот момент с ним отправил син-пакет, и еще пока в ответ син-плюс-ак не получил. Сессии в этот момент ставятся обе, то есть все две сессии проходят трехэтапное рукопожатие син-плюс-ак-ак,

но потом одну из сессий один из роутеров пристреливает. То есть для работы нужна только одна сессия, если вдруг оба роутера случайно поставили друг на друга две, ну, значит, одну из них надо будет пожертвовать. BGP не создан для скорости работы, то есть BGP нигде не торопится, никуда не торопится, это не его задача. Мы говорили с вами, что RIP, например, протокол медленный, а OSPF по сравнению с RIP создавался как альтернатива, причем быстрая. И, допустим, EGRP тоже создавался как альтернатива, более быстрая, чем OSPF, более быстрая, чем RIP. Вот у BGP никогда не было вообще такой задачи быть быстрым протоколом. Он стабильный протокол, он создавался для того, чтобы перетаскивать маршруты между автономными системами. Если вдруг у вас автономной системы много, у вас маршрутов в этих системах тоже будет много, соответственно, если вдруг вы хотите взаимодействовать с ними, со всеми, вы должны будете сделать так, чтобы это большое количество маршрутов у вас не подавило своей массой.

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

условную циску, восьмисотую, носовать по BGP full view интернета. Можно ли это сделать? Можно. Выдержит ли железо? Не выдержит. Он просто задымится и сдохнет. Вряд ли задымится прям совсем, но он не выдержит, конечно, такого жестокого обращения, и скажет, что у меня места не хватает, просто в памяти я не могу удержать такое количество маршрутов, идите в байк. Ну или, например, там, не знаю, те же самые микротики. Вот у них операционная система одна и та же, и вы можете взять как CCR 1072, который огромная дура с 72-ядерным парацом, а сейчас уже, ну, дальше со 144-ядерными парацами есть. И есть какие-нибудь там, не знаю, маплайты, которые точкой доступа вообще-то, на ней тоже самая операционная система, точно тоже самое все работает, и вы, в принципе, можете взять и на эту маленькую точку доступа размером со спичечный коробок взять и носовать, там, не знаю, два full view попытаться. Можно попытаться это сделать, можно. Хватит у нее оперативки для того, чтобы full view удержать? Не хватит. Для работы BGP нужно будет задать стартовый параметр,

с которым у вас BGP будет работать, так называемый номер автономной системы. Эти самые номера автономных систем – это просто число. Изначально число 16-битное, но потом, в 2007 году, когда автономные системы стали заканчиваться, скажем, близиться к окончанию, номер автономной системы расширили до 32-бит. Есть два разных способа записать вот это вот самое 32-битное значение номера автономной системы. Можно просто взять и сказать, что у нас есть просто большое число, там, не знаю, миллиард. Это номер автономной системы. Номер. Это будет нотация AS Plane, то есть автономная система, записанная просто числом. 65 550, да, число. Либо вы можете использовать нотацию AS Dot. Это два 16-битных числа, которые будут разделены точкой. То есть, если, например, у нас есть автономная система, и она фактически будет не 65 550.

Вот это 65 550, это 65 536 плюс 14. Вот мы можем сказать, что, соответственно, старшие два байта мы записываем отдельно через точку, младшие два байта мы тоже записываем отдельно. В этом случае та же самая автономная система будет выглядеть как 1.14. То есть мы ее записали примерно в том же самом формате, как мы записываем IP-адреса, только там в IP-адреса IP-4 мы записываем как 4 8-разрядных значения разделенных точками, а здесь 2 16-разрядных 16-битных значения разделенных точкой. Смысл от этого не меняется, то есть автономная система — это просто число не более не менее. И существуют механизмы, как роутеры себя должны будут вести, если они поддерживают или они, если не поддерживают, 32-битные автономные системы. Современные роутеры все 32-битные автономные системы поддерживают. В интернете поддержка 32-битных систем обязательно с 2010 года.

Эти самые номера автономных систем обязаны быть уникальными, то есть каждая организация, каждый, назовем это сайт, обособленный сайт, который хочет вести взаимодействие в интернете, должен иметь свой собственный уникальный номер автономной системы. И, соответственно, за их уникальностью следит, ну, по большому счету, следит интернет-адрессинг-намбринг-эдженси. А в случае, если она сама не может это делать, она делегирует эти задачи, она по факту делегирует, занимаются этим делом региональные регистраторы. Те самые наши любимые. Ripe, Arin, Afreenik, Laknik и Apnik. В 5 штуках. Из всех этих самых номеров автономных систем есть некоторое количество специальных особенных значений, которые вы должны будете знать. Во-первых, в первом диапазоне, вот в этом вот, с нуля по 65535 номера автономных систем, зарезервирован номер 0,

зарезервирован последние 65535, вы их не можете вообще никак использовать. И последние 1024 номера, они будут... Не 1000, последние 1500 с копейками номеров... Нет, простите, 1024 значения, да. 1024 значения зарезервированы для специальных задач. Вот такой вот диапазон 64496-64511. Это... Небольшое количество номеров автономных систем, которые зарезервированы для того, чтобы вы в документации использовали их исключительно как образцово-показательные номера. То есть, как, допустим, в фильмах в Америке нельзя показывать настоящие телефонные номера. То есть, если кто-то там, главный герой звонит по телефону по какому-то, вот он не должен набирать настоящий номер, чтобы действительные обладатели этих самых номеров

не страдали от того, что кто-то потом решит позвонить по такому же номеру, который был показан в фильме. Так вот, та же самая история и с номерами автономных систем. Есть специальные образцово-показательные номера, которые нужно будет использовать, если вам нужно, допустим, вывести какую-то инструкцию. Вам нужно показать, что у вас есть какой-то гипотетический клиент, который должен следовать инструкции. Вот он в какой-то момент должен вбить свой номер. Вы в инструкции должны будете написать какой-то образцовый номер клиента. Но вот в этом случае вы как раз должны будете использовать в документации, в инструкциях вот эти вот самые номера. Здесь этих номеров немного. То есть их 16 штук. Вот тут вот. И плюс еще дополнительно есть диапазон так называемых частных номеров. С 64 512 по 65 534 штуки. 534 штуку не штуки, а штуку. Здесь у нас 1024, 1023 на самом деле.

Нет, я плохо считаю. Тысяча, ну короче тысяча с небольшим штук, тысяча что-то там. Тысяча что-то номеров. Эти номера можно использовать абсолютно любому желающему, так же как мы можем использовать абсолютно в любом случае частные номера по RFC 1918. Частные номера для IP адресов. То есть если мы хотим сказать, что у нас есть какая-то своя обособленная сеть, не связанная с интернетом, мы можем в этой сети использовать IP адреса из диапазонов 10.0.0.0.0 по 8-й маске, 172.16.0.0 по 12-й маске и 192.168.0.0 по 16-й маске. Вот эти вот частные IP адреса, они зарезервированы за любым желающим. Поэтому за любым желающим, следовательно, ни за кем не зарезервированы. И в интернет такие адреса выпускать нельзя. То же самое и с частными номерами автономных систем. Вот эти вот номера выпускать в интернет нельзя. В 32-битном диапазоне

зарезервирован номер, самый последний 65535.65535 в ISDOT нотации. И дополнительно для документации выделено еще 16 номеров. Вот такие вот. И для частного использования выделена последняя пачка. И пачка с ISPLANE нотации 4 миллиарда 200 миллионов. И дальше до самого конца. То есть это вот начиная с вот такого кривого значения, которое соответствует значению 4 миллиарда 200 миллионов. и по самое последнее 65535.65534. У BGP есть ряд особенностей, которые будут, скажем, определять его поведение. Этот самый протокол, он будет, во-первых, анонсировать свои сети, а во-вторых, понимать от соседей чужие какие-то сети, как можно добраться до других адресов,

до других автономных систем. BGP будет принимать чужие маршруты, и не всегда мы будем этим маршрутам доверять. То есть нам нужно будет реализовать какую-то политику, по которой мы будем доверять или не доверять конкретному префиксу, пришедшему от конкретного соседа. Связано это с тем, что если вы связываетесь с какой-то другой автономной системой, и вы получаете от соседа из другой автономной системы какой-то маршрут, совершенно не факт, что вы этому маршруту действительно будете верить. Например, если вы провайдер, и у вас есть... Так, где у меня рисовалка? Если вы провайдер, и у вас есть роутер, который смотрит на клиента, то есть вы провайдер Эдж-роутер, здесь у вас клиентский роутер CE, и вам клиент начинает рассказывать, что он знает все маршруты до всех сетей в мире. 0, 0, 0, 0, 0, слэш 0. Будете вы такому маршруту верить? Не будете. Клиент не может знать все маршруты до всех сетей в мире. Если это какой-то провайдер, которым вы платите за транзит,

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

Может быть такое, что он начнет вам выгружать целую пачку маршрутов, начнет рассказывать вам про весь интернет, побитые на слэш 32-й маске. Он вам этих маршрутов будет насовывать столько, что у вас кончится место в таблице маршрутизации, в оперативной памяти, и ваш роутер сдохнет. Ну, то есть вы должны будете реализовать политики, какие конкретно маршруты вы согласны принимать от соседей. Не всегда. Мы будем действовать так же, как в IGP, когда все маршруты, которые приходят, они все будут хорошие. Нет, маршруты могут быть нехорошие. В BGP это норма, что вы реализуете политики фильтрации и не допускаете в свою таблицу маршрутизации, какие попалы маршруты, от каких попало соседей. Когда BGP принимает маршруты, он хранит их все в таблице маршрутизации. То есть у вас может быть такое, что один и тот же маршрут два соседних роутера вам присылают. То есть, допустим, один рассказывает, что он знает маршрут до 8.888, и второй говорит, что знает маршрут до 8.888. Мы, допустим, оба эти маршрута допустили. Они у нас попали в таблицу BGP. И среди них BGP выбирает один лучший маршрут.

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

использовать в качестве лучшего. По умолчанию используются те атрибуты, которые содержатся в самом маршруте. То есть вы принимаете маршруты, и вместе с префиксом вы принимаете набор атрибутов. Но, соответственно, эти атрибуты никоим образом не отражают какие-то физические свойства этого маршрута, не отражают задержку прохождения данных по маршруту, не отражают BNB, которые мы привыкли использовать, допустим, в том же SPF или EGRP. То есть лучший — это не значит самый быстрый, не значит самый надежный, не значит самый выгодный, не значит самый, не знаю, толстый. Лучший — это какое-то другое. Лучший — вы должны будете сами определить, что значит BGP. Вы должны будете сами прописать политику, как конкретно роутер должен будет выбирать наилучший маршрут. Вы можете за счет выбора лучшего маршрута сказать, как трафик отправляется в какие-то другие сети. То есть когда вам по BGP рассказывают, как можно добраться до других сетей, вы можете сказать, вот этому мы верим больше, чем другому, в таблицу маршрутизации мы добавляем его,

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

соответственно, через провайдер 1. Но если у нас эти два провайдера или там, не знаю, 3, 4, 10 провайдеров в итоге смотрят в интернет, то в интернете может быть какая-то чужая автономная система, а в этой чужой автономной системе может быть компьютер, который является целью нашего общения. Ну, например, те же самые восьмерки, 8, 8, 8, 8. И вы, отправляя трафик до этого компьютера, направляете трафик через выгодный вам аплинк. Но вы не можете контролировать, как тот вражеский компьютер будет отправлять свой трафик. Он вполне возможно может отправлять трафик через тот аплинк, который вам не нравится. То есть вы не можете контролировать входящий трафик. Вы можете намекнуть в некоторых случаях, что при прочих равных не будет ли многоуважаемый Джин так любезен направлять трафик через один аплинк или через другой. Ну, то есть это именно не четкий контроль, а именно вы высказываете пожелания, а будет ли сосед следовать этим пожеланиям

или не будет, это контролировать уже невозможно. BGP – это протокол, который основан на политиках. То есть политика, как выбрать лучший маршрут, какие маршруты принять от соседа, какие маршруты отправить соседу. Опять же, вы не хотите отправлять маршруты соседу все подряд. Представьте себе, что есть ваша автономная система и автономная система соседа. Вот, например, два роутера, ESP1 и ESP2. Что будет, если ESP1 отправит внезапно маршрут восьминулевку соседу второму? Ну, второй сосед может ей воспользоваться гипотетически. Весь трафик будет направлять через линк между двумя провайдерами, а дальше этот трафик по этому маршруту, он будет направляться через ваш аплинк, который платный. То есть зачем это делать? Этого не надо делать. Поэтому маршруты, какие попало, в сторону соседа анонсировать не нужно. Нужно анонсировать только четкие, выбранные маршруты по определенным заданным критериям. Поэтому вы в любом случае и для приема маршрутов от соседей, и отправки маршрутов к конкретному соседу, и для каких-то правил модификации маршрутов,

потому что BGP это тоже нужно иногда будет делать, и для управления теми префиксами, которые вы используете, чтобы там какие-то префиксы были более выгодны для соседа, какие-то менее выгодны для соседа, и для того, чтобы указать, какие маршруты в принципе в BGP должны присутствовать, вы везде будете писать политики. BGP — это протокол, который основан на политиках. Такой очень политизированный протокол. В любом случае BGP будет работать по принципу distance vector. То есть у него единица передачи информации, это маршрут с некоторым набором метрик. Но иногда BGP будет называть специальным термином path vector протокол, или path vector алгоритм, который он будет использовать. это не просто distance vector протокол. Это будет указание, что какие-то наборы сетей доступны через определенный путь, через некоторое количество автономных систем. И вам рассказывают, соответственно, что вот некоторое количество сетей доступно через вот такую вот, не знаю, вот такую трассу.

Вы, когда принимаете такие апдейты, вы говорите, окей, я знаю, что до каких-то сетей теперь можно будет добраться. В принципе, можно будет здесь сказать, что анонсируется некий поднабор сетей, и вам рассказывают, что вот есть вот такая вот сеть, и она доступна по этой трассе. Но по этой же трассе доступны и некоторые другие сети. То есть здесь рассказывают про какую-то одну сеть, здесь какую-то другую, здесь какую-то третью, и вот эта вот сеть, она тоже как бы есть. Действительно, BGP, единица передачи информации, будет так называемая NLRI, Network Layer Reachability Information, что на уровне сети мы можем некоторый набор сетей, некоторый набор префиксов, достать одним образом. Но это на самом деле никоим образом не влияет на результат. Все равно BGP будет работать по принципу distance vector. То есть он принимает на маршрут с одной стороны, с каким-то набором метрик, дальше смотрит, как мы знаем соседа, прибавляем к тому, что анонсировал сосед, вектор метрик, как мы знаем соседа, и дальше пересылаем это

всем остальным. Так что BGP — это distance vector протокол, просто очень сильно усложненный. Усложненный настолько, что действительно он будет очень и очень значительно отличаться по внешнему виду от, например, тех же самых RIP или EGRP, но сама логика работы у него примерно все-таки та же самая. БГП каждый раз, когда будет получать некоторое количество лучших маршрутов, он будет выбирать среди них один лучший маршрут, будет добавлять этот маршрут в таблицу маршрутизации, и дальше именно тот маршрут, который он сам использует, сам добавил в таблицу маршрутизации, будет анонсировать дальше. За некоторыми исключениями у вас будет вести себя BGP всегда именно так. То есть он никогда не анонсирует какие-то маршруты, если их у него нет в таблице маршрутизации. Есть оговорка здесь, что некоторые реализации ведут себя иначе. Они позволяют анонсировать даже то, чего у вас в таблице маршрутизации нет. Но в любом случае

вы не можете анонсировать не самый выгодный маршрут. Вы должны будете анонсировать самый выгодный маршрут и только его. Вы не можете сказать, что у меня в таблице маршрутизации есть какой-то маршрут и сказать, как он выглядит, при этом анонсировать его со свойствами какого-то соседа, который не самый выгодный. Если вы, например, находитесь в автономной системе 64501, и вы видите, что у вас есть сетка 192.0.2.0, то есть про нее можно узнать вот так, или про нее можно узнать вот так. Вот вы можете сказать, что самый выгодный способ добраться до этой сети – это пойти через вот такого соседа. И свойства маршрута, которые вам здесь пробегают, они вам рассказывают какой-то набор атрибутов. Вот именно его, именно этот набор атрибутов вы пересылаете дальше в 64500-ую автономку. Вы не рассказываете про те атрибуты, которые вы видели в 64503 автономке. То есть то, что пришло, самое выгодное. Вот вы это и анонсируете дальше. В каждом NLRI, в каждом вот указании,

что что-то в сети доступно, BGP будет рассказывать про атрибуты, через какое, с какими свойствами доступен указанный префикс, указанный набор префиксов. И там будет, среди прочего, указываться так называемый ISPath – атрибут списка автономных систем, через который проходит путь трафика до оригинальной сети. И этот атрибут будет выглядеть следующим образом. У нас есть некая сетка, она зарождается в автономной системе 64504. Дальше эта автономная система начинает рассказывать, у меня зародилась моя собственная сеть, она не через какие другие автономные системы не проходит. 64502 автономка говорит, о, я получил информацию от 64504 автономки, начинает рассказывать, у меня такая сеть есть, доступна через меня, и я, соответственно, рассказываю вам, что сеть доступна через автономку 64504, а потом через меня. То же самое делает вот эта вот автономка. Она говорит, я знаю, как добраться до удаленной сети.

Рассказывает про это всем. И 64501 автономка выбирает, среди этого всего наилучший маршрут, говорит, наилучший маршрут, вот, допустим, вот такой вот будет, и рассказывает про то, как добраться до удаленной сети. Для того, чтобы добраться до удаленной сети в 64500 автономки, нужно пройти через 64501 автономку, потом выйти в 64502, и потом оно зародилось в 64504. То есть это фактически можно читать просто как текстовую строчку, в которой через запятую номера автономных систем перечислены. Ну и вот рассказывает про то, какая сеть там доступна. Кстати, здесь опечатка. Не 192.168, 192.0.0. В BGP, как уже было сказано, используется TCP для работы. То есть вам не требуется использовать какой-то механизм переотправки данных. TCP все, что потерялось по дороге, переотправит заново. Может быть, у него потребуется на это достаточно много времени, но BGP никуда не торопится. Что-то потерялось? TCP есть достаточно много времени

для того, чтобы данные передоставили. Все равно потом BGP скажет, окей, я принял какую-то информацию к сведению, я потом, когда у меня будет свободное время, ее обработаю. TCP устанавливает сессию на конкретный IP-шник соседа, поэтому вы должны будете прописывать вручную соседей. Как правило, реализации TCP, простите, реализации BGP не позволяют подключаться к себе с IP-адресов, которые не прописаны в явном виде, как заранее известные соседи. Но у TCP есть одна особенность. Он поставил сессию, и дальше, если ничего не происходит, он ничего не посылает. Поэтому для того, чтобы у вас была функциональность, примерно соответствующая Hello-пакетам в OSPF, в EJRP, в том же самом SIS, когда мы знаем, что сосед живой, потому что он нам постоянно что-то присылает. В BGP есть специальные keep-life сообщения. То есть это фактически пустое сообщение, которое нужно для того, чтобы в TCP-шной сессии постоянно бегали какие-то данные

и увеличивались секвенс номера. Вот. И, соответственно, вот эти вот keep-life сообщения, они нужны просто для того, чтобы вы понимали, что сосед живой. Иначе может быть такое, что вы поставили сессию TCP-шную, сосед работает, работает, работает, и потом, не знаю, взял, завис. И вот что с этим делать? Если у вас просто TCP-шная сессия висит, вы про то, что он завис, не узнаете. В норме в TCP-шной сессии никакие служебные данные не бегают. Но keep-life сообщения, они позволяют узнавать, что сосед, по крайней мере, по BGP не висит. У BGP достаточно много атрибутов. Я вам рассказал про список автономных систем по пути или атрибуты S-Path. Вообще этих атрибутов там целая пачка. Есть варианты атрибутов стандартные, есть атрибуты нестандартные. И некоторые из этих атрибутов позволяют указать приоритетность того или иного маршрута. То есть вы можете сказать, что если вдруг у нас про одну и ту же сеть приходит какой-то маршрут, вот мы этому маршруту доверять будем или не будем.

Есть вариант приоритета указать для своей автономной системы. То есть вы принимаете какой-то маршрут от соседа и указываете. Этот маршрут будет более приоритетный. этот маршрут будет менее приоритетный. Вы можете выставить приоритет, которому должен будет следовать сосед. Не то, что должен, может захотеть, если следовать какому-то приоритету, вот приоритет может быть прочитан в определенном атрибуте. Сразу здесь можно будет заметить, что, например, вот первый вариант атрибута, это local preference атрибут, это вы сами проставляете атрибут для себя, и вы этому атрибуту, конечно же, будете следовать безукоризненно. А вот атрибут, который проставляет приоритет в соседской автономной системе, это атрибут при прочих равных. То есть он намного более слабый атрибут по сравнению с вышеуказанным local preference. Med, multi-discriminator, это такой слабенький-слабенький атрибут. Практически никогда не срабатывает. Есть атрибут, который называется next hop. И это очень простой атрибут.

Когда вы выбираете какой-то маршрут в таблице маршрутизации как самый лучший, именно то, что прописано в этом атрибуте, будет ставиться в таблице маршрутизации в качестве next hop. Фишка в том, что в некоторых случаях этот атрибут не меняется. У вас есть роутер, он пересылает данные другому роутеру, он пересылает данные третьему роутеру, он пересылает данные другому четвертому роутеру. Может быть такое, что у вас по BGP отправляется какой-то маршрут, у него прописано. Я знаю сеть 10.0.0.0 по 24 маске. Атрибут next hop будет 172.16.0.1. И этот маршрут без каких-либо изменений, в эти NLRI, вот такой, а next hop у него вот такой. Этот маршрут без изменений передается через транзитные роутеры. Я сейчас не говорю, что это всегда так происходит, как вот на картинке, что у меня три роутера друг другу пересылают информацию, и они не изменяют этот самый атрибут next hop. Но такое может произойти при определенном поведении.

Мы с вами обязательно разберем чуть дальше, как именно это происходит. Но вот один из вариантов, что у вас здесь вот есть IBGP-шное соседство, здесь есть еще одно IBGP-шное соседство, здесь есть третье. Например, здесь два роутер-рефлектора стоят. И такое поведение можно будет встретить. И вот этот вот роутер, он в таблицу маршрутизации будет натурально добавлять вот этот вот адрес. То есть это какой-то роутер вот здесь, который присылает маршрут и указывает, что меня зовут 172.16.0.1. Вот этот вот маршрутизатор будет указывать, что есть сетка 10.0.0.0. slash 24, доступная через next hop 172.16.0.1. Он должен для того, чтобы поставить такой маршрут, естественно, знать, что вот здесь вот такой IP-шник присутствует. В IBGP-протоколах у нас такого никогда не было. То есть маршруты присылают соседи, и next hop'ами мы прописываем этих соседей, которые присылают нам такие маршруты. А в IBGP это норма, что нам присылают какой-то маршрут, и вот мы только на основании того, что написано в самом маршруте,

в самом наборе атрибутов, устанавливаем маршрут в таблицу маршрутизации. Мы не смотрим на то, кто это прислал. Главное, чтобы политики отработали, разрешили пройти такому маршруту, и дальше то, что в маршруте написано, то и используем в качестве источника для таблицы маршрутизации. Есть атрибут, который указывает на то, откуда взялся в оригинале маршрут. То есть, может быть, есть маршруты, которые нативно в IBGP зародились. Может быть, есть маршруты, которые зародились в IBGP из другого протокола динамической маршрутизации, тот самый EGP, старый древний протокол. Может быть, какие-то еще маршруты есть. Один из вариантов атрибутов — это вот такой вот интересный атрибут, который указывает, что это вообще такое, откуда оно взялось. так ну про прописывание и пишников и номеров автономок на все надо прописывать заранее когда мы говорим про биджи пир у нас есть два роутера первый и второй роутер один роутер

р2 мы указываем что у нас между ними есть какая-то связь у них есть какие-то и пишники например 1001 1002 мы проверяем что связь между ними есть пинги пингуются дальше на r1 прописываем что у нас есть сосед 1002 на р2 прописываем что нас есть сосед 1001 указываем какие номера автономных систем у соседа то есть если у нас автономка там 65000 1 а у соседа шестьде participated на р2 за заранее указать указывание просто что соседа 1002 со с Pilick ани м保оп материала 2022 не просто сосед 1001 а соседов автомобилка finsca глагин apple отличником 10 если у вас все хорошо там сесси устанавливается устанавливается, может быть, одновременно установится две сессии, после чего один из роутеров свою пристрелит, и дальше начинается нормальная работа. Сессия ставится сначала TCP-шная, но мало ли кто у вас подключается на 179-й порт. Надо сначала проверить, что там подключился не телнет на 179-й порт, а вот именно BGP.

Поэтому сначала идет сообщение open, потом после того, как open проходит в обе стороны, дальше начинается нормальная работа. Периодически у вас бегают сообщения keep-life, которые просто нужны, чтобы занимать среду, чтобы было видно, что сосед живой. Если вы хотите отправить какое-то мясо о том, что какая-то сеть доступна или какая-то сеть недоступна, или какая-то сеть изменилась, вы посылаете сообщение update, в них передаются, собственно, сами маршруты. И после чего самое последнее сообщение, notification, такое имеет абсолютно безобидное название, но на самом деле это агония. То есть это последнее сообщение в рамках сессии, что я с тобой больше не дружу, я хочу закрыть с тобой сессию. Вот. Начинается все с open, заканчивается все notification. В перерыве между началом и концом сессии бегают keep-life периодически, и когда возникает какое-то желание чего-то рассказать, бегают апдейты. BGP — это протокол, который нужен для протаскивания маршрутов.

Но, соответственно, он создан для работы в определенных условиях. В тех случаях, когда маршрутов, которые будут присылаться между соседями, будет а. много, и B. Они будут самые разные. То есть есть какие-то маршруты, которые доверенные, с которыми мы должны работать. Есть маршруты, которые недоверенные, которые нам присылают либо по ошибке, либо с умышленной какой-то целью, убедительства. Мы такие маршруты недоверенные должны будем отбрасывать. Более того, мы не должны будем отправлять некоторым соседям некоторые маршруты, которые мы не хотим показывать ему. Тоже важная задача в BGP, и тоже мы ее будем решать. Как уже было сказано, все это делается с помощью политик, но BGP — это протокол, который изначально создавался для работы с политиками. То есть IGP протоколы, тот же самый RIP, OSPF, они не предназначены для работы с политиками. Они доверяют всему. Да, вы можете сказать, давайте напишем там фильтр, какие конкретно маршруты мы по EGP принимаем, какие не принимаем.

Но это происходит потому, что вы хотите, скажем, принять-то все, а дальше уже каким-то образом обрабатывать принятые маршруты. Вы не ожидаете, что вам сосед по EGP начнет рассказывать про какую-то новую сетку, которая прям совсем не в вашей сети, или напротив, начнет рассказывать про какую-то сетку, которая в вашей сети, для того, чтобы hijackнуть ваш трафик. В BGP это проблема. То есть такая проблема есть, с ней приходится бороться. И наличие этой проблемы автора протокола заложили изначально. В случае с OSPF такой проблемы не бывает, потому что все роутеры в OSPF находятся под вашим контролем. Никогда никакой роутер внезапно не начнет hijackить ваш трафик. А если начнет, то вы имеете возможность на него зайти и поправить его поведение. Поэтому на уровне OSPF сказать, что некий роутер не может вам присылать некоторые маршруты, вы такое не делаете обычно. У BGP есть два режима работы. Режим работы между разными автономными системами. Это режим будет называться EBGP или External BGP.

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

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

А EBGP — это режим работы, когда сосед с нами в одной автономке, и мы с этим соседом себя немножко по-другому ведем. Чуть-чуть ему доверяем. Так. Когда у нас есть BGP, он может работать либо в режиме EBGP, либо в режиме IBGP. Вы не можете повлиять на то, какой именно режим BGP будет использовать. Можете сделать это только косвенно, указав, какой номер автономной системы будет у соседа, если вы контролируете этого самого соседа. В норме вы этого не контролируете. То есть вы либо говорите, что соседний роутер ваш, и тогда у вас используется режим IBGP, либо вы указываете автономку соседа, потому что вы не можете наврать с автономкой соседа, вы укажете, какой у него будет номер, и вы будете использовать, соответственно, режим EBGP. EBGP — экстериор BGP и соседство. Это соседство между пирами разных автономных систем. И предполагается, что у вас оба пира

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

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

это какие автономные системы находятся на пути в удаленную сеть, и NextHop. Оба атрибута мы с вами уже видели, что такое. Он выставляет NextHop на тот IP-шник, с которого у него ставится сессия. То есть вот EBGP-шная сессия ставится с одного IP-шника на другой IP-шник. Он проставляет NextHop самого себя, и он проставляет в ISPath, добавляет к тому, что там уже было, свой номер автономной системы. Если сетка А зародилась напрямую в автономке сотой, то роутер R1, отправляя в сторону роутера R2 по BGP указание, что сеть А существует, в ISPath прописывает число 100. То есть вот здесь все роутеры, которые находятся, они знают, что ISPath пустой, а R1 тоже знает, что ISPath пустой, но отправляя по EBGP роутеру R2 эту сетку, он добавляет туда число 100. R2, принимая такой маршрут, видит, что в сотой автономной системе зародилось какой-то маршрут.

IBGP — это соседство между пирами внутри одной автономки. маршруты не меняются, атрибуты не модифицируются, в том числе не модифицируется NextHop, в том числе не модифицируется ISPath. То есть если, например, на роутер R1 по EBGP приходит какая-то сеть А, у нее есть какой-то ISPath, у нее есть какой-то NextHop, R1 дальше соседям по IBGP эту сетку пересылает, он не трогает атрибуты ISPath и NextHop. То, что ему сосед EBGP отправил, вот он то рассказывает всем своим соседям. Для того, чтобы все заработало, чтобы сосед R2 получил такой маршрут и понял, что с ним надо делать, нужно, чтобы NextHop, который проставлен в этом маршруте, был бы доступен. Есть еще один нюанс. Нюанс заключается в том, что внутри автономной системы IBGP соседи получают какие-то маршруты, и они их другим своим IBGP-шным же соседям

не передают. Поэтому у вас внутри автономной системы все IBGP-шные роутеры по умолчанию должны быть связаны между собой по схеме каждый с каждым. Это не означает, что у вас от каждого с каждым должен быть прямой провод. Это должен быть именно каждый с каждым IBGP-шное соседство. То есть если у вас, например, есть три роутера, которые в цепочку связаны между собой проводами, R1, R2, R3, у них есть какие-то IP-шники. Здесь один IP-шник, здесь другой IP-шник, там здесь третий, здесь четвертый. Значит, у вас IBGP-шные соседства должны строиться по схеме каждый с каждым. Первый с вторым, второй с третьим, третий с первым. Безусловно, для того, чтобы первый с третьим мог построить IBGP-шную связь, IP-шник, на который R1 будет подключаться, чтобы достать до роутера R3, должен быть ему известен. То есть вы же не должны будете сказать, мы с адреса 10.0.1.1 смотрим на соседа 10.0.1.2. Сосед 10.0.1.2,

это 10.0.2.1 айп-шник имеет, у него R3 будет 10.0.2.2. Вот все вот эти вот IP-адреса должны быть известны роутеру R1. И поэтому R1 должен будет ставить сессию, TCP-шную, на вот какой-то IP-шник, принадлежащий роутеру R3. Возможно, на вот этот вот адрес. Не обязательно на этот адрес, но как гипотеза, да, что может быть идет на этот адрес сессия. С адреса 10.0.1.1 на адрес 10.0.2.2. Естественно, по умолчанию у нас эти IP-шники там не видны. То есть если мы просто соединяем роутеры между собой проводами, как узнать, как добраться до 10.0.2. Да никак. Вам потребуется дополнительный протокол. Например, OSPF. То есть IBGP, если у вас роутеров больше, чем там два или три, или сколько там их может быть, требует фактически для своей работы дополнительный протокол, чтобы просто обеспечить IBGP возможность работы. То есть IGP — это у нас либо OSPF,

либо SIS, либо что-нибудь еще. Если вы используете сеть предприятия, вы можете использовать EGRP. Но если мы говорим про провайдерские сети, IGP — это либо OSPF, либо ASIS. Мы запускаем на этих роутерах OSPF. OSPF притаскивает нам IPшники, которые у нас на интерфейсах висят. Может быть, у нас будут какие-то лупбэки. Здесь лупбэк, здесь лупбэк, здесь лупбэк. OSPF дружит по физическим интерфейсам, притаскивает IPшники лупбэков. Дальше вы с этих лупбэков напрямую ставите сессию. По схеме каждый на каждого. Не обязательно количество физических интерфейсов будет у вас совпадать с количеством сессий. Сессию у вас столько же, сколько соседей, сколько всего соседних роутеров в вашей автономной системе вообще. Ну, не обязательно напрямую соседнюю подключенной, а просто сколько всего роутеров вообще. Столько у вас будет соседств. А вот, например, здесь картинка как раз такая, когда физически у нас есть одно соседство, про R1 и R2, например. Вот мы видим, что R1 дружит по OSPF с одним роутером R2,

а по BGP он дружит и с R2, и с R3. Вот. Естественно, что если роутеров мало, это в принципе реализуемо. Если роутеров много, то есть у вас, например, не знаю, 100 роутеров BGP, то схему каждый на каждого реализовать будет достаточно проблематично, потому что безумное количество административной работы для того, чтобы поддерживать все это в актуальном состоянии, добавляется новый роутер, надо на него 101 комплект соседств прописать. И на всех остальных 100 роутеров, на 101 роутере, нужно будет прописать ответные части. Это нереалистичный объем работы. Если у вас крупный провайдер, то чаще всего мы в таких случаях будем каким-то образом эту схему упрощать. Про упрощение чуть дальше будет разговор. Там есть несколько вариантов, как это именно можно будет сделать. Мы с вами будем говорить про роутерефлекторы. Если говорить про альтернативные варианты, то еще бывает такая штука, как BGP-шная конфедерация. То есть фактически вы в некоторых случаях

IBGP-шное сообщение можете превратить во что-то наподобие EBGP-шного. И там уже не требуется связь каждый с каждым. Если у нас есть чистое нативное IBGP-шное взаимодействие, то, как уже было сказано, атрибуты при отправке по IBGP не меняются. Если у нас есть роутер R1 и роутер R2, которые друг с другом связаны по EBGP, они друг к другу пересылают маршруты, они проставляют атрибут NextHop в свой IP-шник, с под которого ставится сессия, и они добавляют к атрибуту ISPath номер своей автономной системы. При передаче по IBGP эти маршруты передаются в неизменном виде. Сосед R1 прислал на R2 некую сетку и говорит, я знаю про сеть 203.0.13.0.24. Вертемаске NextHop у нее будет 10.001 и автономная система по пути ISPath у нас будет 64.501. R2 принимает такой маршрут и отсылает его в неизменном виде дальше.

Говорит, ISPath у такого маршрута будет как раз 64.501. Но NextHop тоже 10.001. Если R3 принимает такой маршрут, он его А дальше по IBGP уже никому не передает, а Б он должен знать, кто такой вот этот самый 10.001. У него должен быть маршрут до этого адреса. Если у него маршрута такого не будет, он такой маршрут в таблицу маршрутизации добавить не сможет и использовать его тоже не сможет. И даже соседу по EBGP этот маршрут он анонсировать уже тоже не сможет, если сосед будет в другой автономке. То есть маршрут анонсировать соседу можно только в том случае, если мы его сами добавили в таблицу маршрутизации. Если мы его не смогли добавить в таблицу маршрутизации, он у нас не лучший, мы про него соседу рассказать не можем. В некоторых ситуациях вы можете добавить адрес NextHop'ов ваших соседей всех других автономных системах в динамическую маршрутизацию. Например, не знаю, в OSPF.

У вас здесь же работает OSPF рядышком, или ISIS. Вот вы можете взять и добавить в OSPF все NextHop'ы, которые у вас по факту есть. Можно так сделать, и тогда у вас R3 будет знать, что приходит какой-то маршрут по BGP, у него NextHop 10.01, и он знает, как добраться до 10.01. Надо проставить наиболее короткий маршрут до этого адреса. Вот. Или альтернативный вариант. Можно будет можно будет не добавлять этот адрес в OSPF или в IGP протокол более строго. Можно будет заставить ваш транзитный роутер, который пограничник ваш, поменять этот самый NextHop, сказать, что адрес NextHop'а следует поменять на свой собственный. Сессия между R2 и R3 у нас ставится из-под какого-то адреса. Следующее, мы должны поставить сессию с адреса 192.168.01. Вот, значит, NextHop'а будет 192.168.01.

Как будто бы это было соседство EBG-пишное. В этом случае R3 сможет принять такой маршрут, сможет добавить его в таблицу с маршрутизацией, потому что такой маршрут у него точно уже есть. Тот IP-шник, из-под которого ставится сессия, он точно соседу известен, ну, хотя бы потому, что сессия все-таки была поставлена, по которой все это дело прибежало. Так что адрес точно известен. Нюансы заключаются в том, что если у вас роутеров IBG-пишных много, если вы, допустим, вот здесь вот еще какие-то роутеры будете иметь, у вас между пограничником и этими всеми роутерами будут протянуты отдельные сессии, и если вы принимаете какой-то вот маршрут от соседа EBG-пишного, вам проще будет, на самом деле, сказать, что давайте мы вбросим этот лупбек, ну, или этот адрес, в условный SPF, чтобы все роутеры узнали, как до него будет добраться. Тогда они просчитают наиболее короткие маршруты до этого адреса,

и когда мы скажем, что у нас NextHop для внешнего маршрута будет 10.001, вот этот вот роутер скажет, у нас есть EBG-пишный маршрут на NextHop 10.001. один такой маршрут, который у нас есть, самый лучший, это самая лучшая точка выхода из нашей автономной системы до указанного префикса. Но они просчитают самый короткий способ, как можно добраться до этого IP-шника. И если таких способов будет, например, два, если у SPF скажет, что вот до этого вот IP-шника может набраться двумя разными способами через два разных интерфейса, у вас в таблицу маршрутизации будет добавляться два разных способа добраться до этого NextHop. И трафик, по факту, до одного и того же префикса 203.0.113.1, который в таблице маршрутизации будет известен один раз, будет балансироваться. Потому что до транзитного NextHop, до которого мы ставим маршрут, есть два разных выхода. В принципе, можно такого же поведения достичь,

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

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

давайте мы свяжем их, там, допустим, вот первый свяжем со вторым, первый свяжем с третьим, первый свяжем с четвертым, да, а второй свяжем с третьим, второй с четвертым, третий с четвертым. Звучит все на словах хорошо, по факту сталкиваемся мы с проблемой. Проблема заключается в том, что для того, чтобы связать, допустим, первый и второй роутер, мы должны будем не просто сказать свяжись, пожалуйста, с роутером номер два, а мы должны будем i-be-шник прописать. Какой именно IP-адрес здесь нужно использовать? Вот у нас на роутере R1 4 адреса. Первый, второй, третий, четвертый. На роутере R2 их тоже 4. Прописывать все IP-шники между первым и вторым по схеме каждый на каждый — это безумие. Прописывать, сказать, нам хватит только, допустим, 10.0.112.1 и 10.0.112.2 — это значит обрекать себя на отказ в случае, если откажет один линк, что у нас связь между R1 и R2 отвалится. Даже несмотря на то, что трафик между ними гипотетически все равно может пойти в обход через второй линк, все равно связи у вас здесь не будет.

Можно, конечно, сказать, давайте мы порт-ченел здесь соберем, допустим, два этих параллельных линка, агрегируем в один канал, но все равно с этим агрегатом все равно что-то может произойти. Трафик может пойти в обход, но он по факту не пойдет, потому что IP-шники мы привязали, те, которые вязают на физических интерфейсах. Для того, чтобы избавиться от этой проблемы, в IBGP принято действовать следующим образом. Вы сессии в IBGP ставите не с физических IP-шников. Вы поднимаете на каждом роутере лупбеки, запускаете внутри всей вашей физической сети и на лупбеках тоже какой-то IGP протокол, OSPF или ASAS, и дальше сессии ставите с этих самых виртуальных IP-шников, с лупбека на лупбек. Эти лупбеки всегда заведомо живые, с ними ничего не случится. Если есть хоть какой-то, хоть косой, хоть кривой способ доставить трафик от одного узла до другого, OSPF вам его притащит и сделает это хорошо. Если вы в OSPF не засовываете много маршрутов, он работает прекрасно.

Если вы в ASAS засовываете немного маршрутов, сколько у вас роутеров, столько лупбеков есть, больше вам не нужно. Он у вас будет работать прекрасно. Отказ отдельного физического канала на связь между двумя роутерами не повлияет. BGP-шная сессия останется живой, она у вас не флакнет. Маршруты останутся живыми, NextHop'ы останутся живыми. NextHop'ами у нас будут те самые лупбеки или адреса, которые известны за ними. Ну и, соответственно, если у вас связь между двумя роутерами поломается, то, значит, трафик просто пойдет в обход. При этом таблица маршрутизации с точки зрения BGP-шных маршрутов не изменится. Изменится только маршрут у OSPF. И они же повлекут за собой изменение трассы по пути пакетов. Вот в IBGP принято устраивать соседство именно таким образом. Если у вас роутеров много, то вы должны будете каким-то образом заботиться тем, чтобы не пришлось делать безумное количество настроек, безумное количество соседств прописывать. Мы с вами рассматриваем, как уже было сказано, только один вариант, как это сделать.

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

нарушать требования работы IBGP. Так, дальше. Обычно этих роутеров ставится парой. То есть здесь роутер-рефлектор 1, роутер-рефлектор 2. Вы указываете, что у вас есть пара роутер-рефлекторов. Если один из них сдохнет, второй будет работать. И затем вы, естественно, не обязаны следовать физической топологии того, как у вас сходит трафик. Вы просто говорите, что у вас на всех этих роутерах есть какой-то протокол динамической браштизации, например, условно там... Что у нас там бывает? ОСПФ. И вы говорите, что у нас есть роутер 1. Этот роутер знает, как добраться до роутер-рефлектора 1. Вот он строит сессию с ним. Здесь показана пунктирная линия, что R1 связан с роутер-рефлектором 1. R1 связан с роутер-рефлектором 2. Сессия ставится. При этом трафик, по факту, не ходит между ними напрямую. То есть не нужен прямой провод от роутера 1 до роутер-рефлектора 1. Он может ходить как-то в обход. Здесь на картинке показана кривая косая схема,

которая, конечно, не является образцом показателями дизайном сети провайдера, при которой у нас все IBGP-шные роутеры связаны в кольцо. А вот эти два роутер-рефлектора подключены вот таким вот аппендиксом к одному из них. Но это как пример сети, в которой у вас неважно, как физически рлинки организованы между роутерами, но вот они вот как-то вот так вот выглядят. И, соответственно, роутер 1 связывается по IBGP с двумя роутер-рефлекторами. Роутер 2 связывается по IBGP с двумя роутер-рефлекторами. Третий связывается с двумя роутер-рефлекторами. и вот так далее. Каждый роутер строит отдельную IBGP-шную сессию только с своими роутерефлекторами. И после того, как у вас эти сессии ставятся, на роутере R1 зарождается какой-то маршрут из внешнеавтономной системы. Он его по IBGP присылает на свой роутерефлектор. Роутерефлектор отражает его на все остальные IBGP-шные роутеры, на все остальные пограничники.

Нам не нужно на R1 связываться напрямую с R2, с R3, с R4, с R5 и так далее. Мы строим только два соседства с роутерефлекторами. На роутерефлекторах, да, все клиенты должны быть прописаны. Причем на роутерефлекторах нужно будет явно в виде указывать, что соседу нужно будет отражать IBGP-шные маршруты, прописывать настройку роутерефлектора клиента. Вот. Вот. Заметьте, что трафик через роутерефлекторы ходить не обязан. То есть после того, как у нас есть какой-то маршрут, ну, допустим, вот R1 получает маршрут до сети 10.0.0.0.24, он говорит, я про эту сетку рассказываю роутерефлектору 1 и второму тоже. Роутерефлектор 1 рассказывает про эту сетку роутерефлектору 2, ну, простите, роутеру 2, но он при этом, как и порядочный IBGP-шный роутер, атрибуты маршрута не меняет.

То, что у нас есть сетка 10.0.0.0.24 маски, она приходит с NextHop, не знаю, 10.1.1.1. И R2 видит этот самый NextHop 10.1.1.1. Дальше, если мы говорим, допустим, что мы его бросили в OSPF, у нас по OSPF эти роутеры связаны через физические линки, и, соответственно, R2 говорит, как бы мне проще всего добраться до 10.1.1.1. Надо пойти в сторону роутера R1, и дальше он разберется, как с этим трафиком работать. Через роутерефлекторы трафик обычно не ходит. По этой причине роутерефлектор может быть, например, просто виртуалка, которая у вас где-то висит на каком-то гипервизоре. И единственное, зачем она нужна, это просто хранить на себе маршруты. Что где-то маршрут зародился, он пришел на эту виртуалку, она дальше как диспетчер всем остальным пограничникам это все разбросала. Очень часто используются под роутерефлекторы роутеры, которые, ну, может быть, достаточно мощные,

то есть у них достаточно неплохой процессор, но при этом у них нет большого количества интерфейсов. То есть просто стоит отдельная коробка, вот так вот на палке висит, да, роутер на палочке. На нее приходят все маршруты. Если вдруг что-то где-то происходит, то она, соответственно, про все эти изменения рассказывает всем остальным. Так, далее. Будет ли это единая точка отказа? Нет, не будет, потому что, ну, можно же два роутерефлектора поставить. Вот на картинке я сделал какую-то неудачную штуку, что если роутерефлектор один отвалится, второй, ну, соответственно, тоже отвалится. Но никто вам не мешает, например, вот так вот сделать связь. То есть если один отваливается, второй продолжает работать. Физическая топология и связанности IBGP-шных соседств с роутерефлекторами не обязаны никаким образом совпадать. Есть нюанс, что если вы построите схему с двумя роутерефлекторами немножко специфически, то вы можете в IBGP получить петлю.

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

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

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

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

либо, не знаю, какой-нибудь тот же опять же SPF запустить, чтобы лупбек соседа был виден. Ну, то есть сразу возникают усложнения какие-то. А во-вторых, вам нужно будет решить проблему с TTL, потому что BGP для защиты от левых подключений, пакеты, которые будут отправляться в сторону соседа, будут отправляться с TTL, равным единичке. И многие операционные системы, если вы поднимаете лупбек, например, та же самая Cisco, в EBGP они будут расценивать это как вот такое вот поведение, что трафик, который приходит с TTL, равным единичке, через физические интерфейсы, вот если нужно будет его обработать на IP-шник лупбека, то он как бы подвергается маршрутизации на самого себя. И в этот момент, в момент маршрутизации на самого себя, из TTL вычитается копеечка, TTL обращается в ноль, и пакет пристреливается с криком «Он протух по дороге». Поэтому, чтобы такого не было, вы должны будете либо вашему отправителю сказать, что пакеты надо отправлять с TTL, ну, например, двоечкой,

и тогда эта штука будет называться EBGP Multihop. Вот. Ничего он не рисует. EBGP Multihop. Вы указываете, что пакеты отправляются с TTL двоечкой, троечкой, и тем самым разрешаете получателю запустить маршрутизацию для пакета, вычесть копеечку, и из оставшегося пакета с оставшимся TTL-ом единичкой что-то ценное получить. Либо альтернативный вариант. Вы можете сказать, что вам хочется использовать механизм EBGP Detail Security. В принципе, его можно использовать даже, если у вас просто прямой провод между двумя роутерами. Механизм заключается в следующем. Вы отправляете пакеты, и вы их отправляете с TTL-ом 255. И получатель, когда получает такие пакеты, должен будет указать, какого размера пакеты он согласен принимать. То есть EBGP Multihop — это про то, какой вы TTL отправляете, а EBGP Detail Security — это про то, что вы отправляете TTL всегда 255,

и указываете, какой TTL вы можете принять. После того, как вы, например, принимаете пакет после маршрутизации, у вас TTL превратится в 254, и вы указываете там, BGP Detail Security, разрешаю принимать пакеты с TTL-ом 254. Это вас защитит от того, что кто-то издалека отправит вам пакет, и этот пакет пройдет через несколько роутеров, зайдет на ваш маленький несчастный роутер и дальше каким-то образом повредит сессию с легитимным соседом. Понятное дело, если вы используете просто обычный EBGP Multihop, вы ничего вернуть соседу гадкому не сможете, но при этом принять какой-то трафик от злоумышленника, который вам выбрасывает лишние данные, вы гипотетически можете. То есть это небольшая уязвимость в части, скажем, приема пакетов. А вот BGP Detail Security указывает, что некоторые пакеты, которые приходят сильно издалека, они в принципе не могут прийти с TTL слишком большим. Если вы в прямом проводе с соседом,

то все, что он будет отправлять с TTL-255, максимально возможным, будет доходить до вас с TTL-255, максимально же возможным. Если приходят какие-то пакеты не с TTL-255, это заведомый фрод, такие пакеты надо сразу выкинуть. Эти механизмы не существуют одновременно, то есть вы должны будете выбрать либо один, либо другой. По умолчанию все пакеты отправляются с TTL-255, равным единичке. Если вы хотите сказать, что по EBGP вы будете дружить с соседом, которому требуется все-таки запустить маршрутизацию, или вы, например, дружите с роутер-рефлектором соседа, поэтому у вас EBGP-шное соседство ставится на роутере не с напрямую подключенным соседом, а с каким-то дальним роутером, который находится где-то непонятно где. Вот вы в этом случае должны будете дружить с ним, вы должны будете ему по EBGP-мультихоп разрешить отправлять пакеты с TTL-255, не единичкой, а там двойкой, тройкой, а он уже будет отправлять пакеты свои, BGP-шные, в сторону роутера R2, с которым вы непосредственно подключены. Схема кривая-косая и используется на практике очень редко.

Чаще всего роутеры по EBGP дружат напрямую между собой через физические интерфейсы. Если вы включаете TTL-секьюрити, то в этом случае вы говорите, отправляем пакеты не с минимально возможным TTL, чтобы они через много роутеров не прошли до получателя, а наоборот с максимальным. Они в этом случае могут пройти куда угодно, но они же пойдут по той трассе, которую мы указываем, в любом случае они куда попало не пойдут. А вот принимающая сторона сможет при этом проконтролировать, что отправили такие пакеты именно мы. Оба механизма, если вы задействуете, нужно будет проверить, что они корректно работают. То есть если EBGP Multihop в принципе можно включить только с одной стороны, в некоторых случаях это будет допустимо, хотя чаще всего надо с двух сторон включать, то в TTL-секьюрити надо прямо в обязательном порядке включать с обеих сторон. Потому что если вы с одной стороны не включаете TTL-секьюрити, вы отправляете пакеты с маленьким TTL,

с другой стороны, когда вы включаете TTL-секьюрити, вы разрешаете прием пакетов только с большим TTL. То есть эти две процедуры, они несовместимы между собой. Так, в любом случае, как бы мы ни дружили по EBGP или по IBGP, у нас роутеры соседей проходят через некоторые состояния. Так же, как в SPF у нас есть состояние соседства, та же самая история есть и в BGP. Мы заранее можем сказать, что мы в любом случае в таблице соседей будем знать всех своих соседей на перечет. То есть так как в SPF мы говорили, там начинается все, если мы обнаружим соседей автоматически, с того, что сосед присылает нам hello-сообщение, мы его заносим в табличку соседей автоматом. Здесь такого нету, здесь мы всех соседей знаем на перечет, если только не используем динамический групп, опять же. И dynamic neighbors. И начинается все с того, что у нас будет состояние idle, и это означает, что мы не пытаемся установить соседство с соседним роутом.

То есть мы знаем IP-шник его, но мы даже не хотим этого делать, не хотим пытаться отправлять ему первый самый син-пакет. Idle означает, что либо у нас нет маршрута до IP-шника соседа, либо мы попытались с ним повзаимодействовать, но у нас почему-то не получилось. И мы сейчас сидим, ждем и отдыхаем, потому что BGP протокол неспешный. Если ему торопиться некуда, он попытался что-то сделать, посидел, попытался, снова что-то сделал, снова посидел, попил кофе, снова попытался. Idle означает, что мы не пытаемся прямо сейчас работать с соседом. Это означает, в принципе, что сосед может попытаться подключиться к нам, и мы, возможно, установим с ним соседские взаимоотношения, но мы прямо сейчас активно не хотим с ним работать. Active будет означать, что мы, в принципе, не против были бы с ним подружиться прямо сейчас. Мы отправили TCP-SYN, но не получили SYN плюс SAC. То есть актив, это значит, мы пытаемся до него достучаться, а он нам, собак, страшно не отвечает.

Не отвечает по TCP. То есть мы с ним TCP-шную сессию поставить не можем. Если мы видим состояние connect, это значит, что мы получили SYN пакет, и мы отправили в ответ SYN плюс SAC и ждем корректный SAC в ответ на наш SYN плюс SAC. То есть, в принципе, состояние connect очень редко можно будет увидеть, потому что оно очень-очень быстро проходит. В нормальной ситуации, если нам кто-то SYN пакет прислал, мы в ответ ему послали, что да, все хорошо, давай с тобой дружить, и в ответ нам приходит, окей, все хорошо, давай начинать работать. В каких ситуациях можно будет увидеть connect, который висит в длительном состоянии? Это если кто-то вас пытается похакать, и кто-то вам посылает SYN пакеты с подмененным адресом. В этом случае у вас все адреса, которые будут указаны в качестве источника, они вот, если действительно соседства такие будут прописаны, будут висеть в состоянии connect. Но вероятность этого небольшая,

как вы понимаете. Если у нас... Мы отправили SYN пакет. В ответ пришел SYN плюс SAC. Мы отправили SAC. Дальше мы немедленно отправляем сообщение open. И если мы отправили сообщение open, то сосед переходит в стадию open send. В этом состоянии сосед может тоже зависнуть. Если мы видим, что у нас сообщение open отправлено, но не получено в ответ другое сообщение open, значит, с той стороны, на 179-й порт, нам ответила какая-то другая железка, не BGP-шный роутер. Мало ли почему он захотел ответить на 179-й порт. Или мы на 179-й порт с кем-то там попытались установить сессию TCP-шную, и нам это удалось. Кто-то телнетом взял, попробовал, набрал телнет, там, 1001-й, пробил 179. И у нас сессия поставилась. Мы в эту сессию выплюнули open, но, естественно, из телнета нам open обратно не приходит. Поэтому мы сидим, ждем некоторое время, после чего говорим, не пришло сообщение open, сбрасываемся обратно в idle. Если пришло сообщение open,

то сессия практически установлена. Мы дальше внутри этой сессии ждем keep-live, и как только первый keep-live проходит, мы переходим в состояние established. То есть open confirm — это все хорошо. В общем, уже никаких специальных действий с сессией делать не нужно. Единственное, что может быть такое, что если мы одновременно с двух роутеров попытались друг на друга поставить сессии, вот для чего вот это open confirm будет нужно. Если у нас есть один роутер и второй роутер, между ними есть линк. Один роутер поставил линк на сессию на второго, и другой на первого. Это произошло одновременно. Соответственно, один open отправил сообщение, второй open отправил сообщение. Один open отправил сообщение, и второй open отправил сообщение. Вот они должны будут по этим open сообщениям понять, что это на самом деле две параллельные сессии абсолютно одинаковые. В одной из них пройдет keep-live, а в другой из них пройдет notification. И та, в которой пройдет notification, сессия будет пристрелена. Ну, а вторая сессия будет нормально работать. Establish — значит, все в порядке, сессия установлена, с ней никаких проблем нету,

это не встречная сессия, которую надо пристрелить. И дальше в этой сессии пойдет обмен апдейтами. Если у нас что-то идет не по плану, то есть в списке соседей мы видим, что соседство не устанавливается, что может послужить проблемой. Либо не ставится TCP-шная сессия, либо не ставится BGP-шная сессия, поверх установленной TCP-шной, либо мы где-то ошиблись в настройках и неправильно настроили наш BGP. Если не ставится TCP-шная сессия, проблемы там могут быть в IP-адресах. Либо не на тот IP-шник дружим, либо не с того IP-шника дружим, либо не то прописали в настройках. То есть, допустим, мы хотим дружить на лупбек соседа с нашего лупбека. Нам нужно прописать, и что сессия идет на лупбек соседа, не просто на какой-то IP-шник соседа, а именно на его лупбек. И надо указать, что адрес источника будет наш лупбек, потому что именно наш лупбек прописан у него в качестве соседа. Какая классическая ошибка?

Два роутера, на них прописаны лупбеки, здесь лупбек, здесь лупбек, прямая связь между ними. Один роутер R1 говорит, я хочу дружить с лупбеком. Указывает просто IP-шник лупбека в качестве получателя, в качестве другой стороны, но не прописывает адрес источника. Здесь у нас на R1 такая настройка, и на R2 такая же настройка. То же самое. Он говорит, я хочу подружиться с лупбеком соседа. Абсолютно классическая детская ошибка. Ни на одном роутере не указан адрес, из-под которого идет соседство в качестве адреса соседа. Поэтому на обоих роутерах прописано, что адрес соседа должен быть лупбек, но вот это вот, физические IP-шники, из которых по факту идет сессия, они в качестве соседа не прописаны. Поэтому у вас сессия не поставится. Надо, чтобы хотя бы один роутер поставил в качестве адреса источника в сессии свой лупбек. Тогда сессия будет ставиться вот такая вот, и у того, кто проставил свой лупбек в качестве источника, все сложится. Он поставит сессию на соседа.

По-хорошему, конечно, имеет смысл ставить на обоих роутерах адрес источника лупбек. Ну, в принципе, достаточно только одного. Может быть такое, что вы недоизучите адрес лупбека, там, не знаю, в IGP. То есть вы забудете лупбек запихать в SPF. Ну, тоже достаточно детская ошибка. Не очень часто встречается, однако. Может быть такое, что вы укажете неправильный номер автономки соседа. То есть если у вас сессия ставится, то в этой сессии должны пройти два сообщения open. Одно в одну сторону, другое в другую. И в этих сообщениях open показывается, какой IP-шник соседа, естественно, и какой номер автономки. Если вы пропишите, что сосед у вас будет жить в автономке, не знаю, 65000-001, а по факту сессия идет с сообщением open, и там показывается какой-то другой номер автономки, ну, это сообщение не примется, и сессия будет пристрелена. Поэтому аккуратно смотрите на то, какие настройки должны быть,

аккуратно смотрите на то, какие настройки вы по факту прописали. Где-то есть несоответствие, как следствие сессия не уставится. Далее. Далее. Если BGP у нас работает, BGP никоим образом не предназначен для балансировки трафика. То есть, если мы говорим в OSPF, у нас, например, нормальная задача, это если есть два одинаково хороших способа доставить трафик в удаленную сеть, в OSPF пусть балансирует трафик. Да. BGP не предназначен для балансировки. В пределах автономной системы балансировка не нужна, потому что BGP указывает на точку выхода из автономки. Точка выхода у нас будет всего одна, и до этой точки выхода, которая указана в качестве адреса NextHop, балансировать трафик будет тот же самый OSPF. То есть, мы в таблицу маршрутизации ставим IP-шник NextHop, а как до него добраться, сбалансировка или без сбалансировки, уже это не BGP-шная задача. В то же время, несколько точек выхода из автономной системы ставит очень плохая идея,

очевидно, совершенно плохая идея, потому что мы не можем контролировать, что трафик, который пойдет через разные точки выхода из автономной системы, будет идти по сравнимым трассам. То есть, когда у нас есть, например, роутер, и вот у него есть одна точка выхода из автономки, и другая точка выхода из автономки, здесь какой-то набор провайдеров, здесь какой-то набор провайдеров, и вот у нас некий сервер, с которым мы хотим вести взаимодействие. Если часть трафика пойдет налево, а часть трафика пойдет направо до одного и того же сервера, это будет очень-очень большая беда, потому что здесь задержка слева и задержка справа, они вообще никаким образом не связаны между собой. Здесь может быть задержка, не знаю, 1 миллисекунда, а здесь задержка может быть 100 миллисекунд. Это, соответственно, сразу жуткий реордеринг, секвенсинг, все на свете. Задержки разные, потери разные. То есть BGP никогда, ни в каких обстоятельствах, не сделает вам так, чтобы трафик шел через разные автономные системы до одной и той же точки в сети. Он может там иногда держать маршрут про запас,

иногда какие-то маршруты ставить, допустим, в таблицу маршрутизации, когда они будут такие полудохлые, но они будут на всякий случай, если вдруг основной маршрут живет, они не работают. Если маршрут дохнет, он там ставит запасной маршрут. Но так, чтобы активно два маршрута смотрели в две разные стороны, BGP не делает никогда. Он всегда выбирает один маршрут и ставит его в таблицу маршрутизации. И только по одному маршруту, по факту, из BGP будет ходить трафик. Вы должны будете знать алгоритм, по которому BGP выбирают наилучший маршрут, и как отче наш. Иногда его называют Best Path Selection, иногда можно встретить аббревиатуру BPS. Я сам, когда вижу аббревиатуру, я всегда очень пугаюсь. Мне говорят, ну, расскажи типа про BPS в BGP. Я говорю, что? Каково BGP? Вы что? В смысле, какой BPS? Ну, как выбор лучшего маршрута? А, Best Path Selection, окей. Вот. Но это очень простая, на самом деле, вещь. Нужно запомнить ряд атрибутов, в каком порядке будут сравниваться на роутерах, если вдруг роутер принимает несколько разных маршрутов от соседей.

Атрибуты, которые штатно есть в BGP по стандарту, они достаточно простые. Первый атрибут — это NextHop. Мы с ним уже сталкивались. Второй атрибут — это AS Path. Тоже мы с ним уже сталкивались. Это список автономок, через которые проходит трафик до удаленной системы. На самом деле, AS Path — это не один атрибут, а целых четыре. Но мы не будем углубляться в том, как они устроены между собой. Просто как список автономок — список автономок. Дальше. Атрибут Local Preference. Это атрибут указывает на приоритет маршрута в нашей своей локальной автономной системе. Local намекает на то, что где-то у нас в своей автономной системе работает. И этот preference намекает на то, что с его помощью можно указать, какой маршрут лучше, какой хуже. Local Preference вы назначаете с помощью политик. BGP, как мы уже говорили, работает по политикам. Поэтому если вдруг к нам приходят два маршрута до одной и той же сети, неважно, на каких роутерах они приходят, главное, что они все будут находиться в одной автономной системе. Вы проставляете эти самые Local Preference и дальше начинаете распространять эти маршруты по сети.

Все остальные роутеры в пределах автономки будут получать либо один самый выгодный маршрут с уже правильным Local Preference, либо два маршрута с... Один с хорошим Local Preference, другой с плохим. И в этом случае они плохой Local Preference будут игнорировать, хороший Local Preference будут использовать, ставить в таблицу маршрутизации и рассылать всем остальным соседям. MultiExit Discriminator тоже про приоритет, но это рекомендация соседним роутерам в соседней автономной системе, насколько выгодный или невыгодный способ доставки трафика вы предоставляете в свою автономную систему. То есть если у вас есть ваша автономная система и автономная система соседа и два пограничника, которые между вашими автономками есть, вот это ваше... Ваше. Вот это вот чужая. Чужая. Вот. Вы можете сказать, что есть некая сетка, сеть А, про которую ваши оба пограничника рассказывают.

И в одном случае вы говорите, приоритет будет 100, в другом случае приоритет будет 200. Вот у кого меньше МЕД, тот и лучше. То есть трафик в сторону вашей автономной системы из автономки соседа будет идти через тот пограничник, который заявил МЕД меньший. Но есть нюанс, что этот атрибут сравнивается в самую последнюю очередь по умолчанию. То есть если соседний роутер использует настройки по умолчанию, если нигде никаких политик не сделано, тогда они сравнивают мультитекс с дискриминатором. Если где-то прописана хоть какая-то политика, сразу все это перестает работать. И по определению МЕД не работает между разными автономными системами. То есть если вы в одну автономку вещаете один МЕД, в другой другой, это не работает. МЕД сравнивается только в пределах соседней автономки и не передается дальше. Код происхождения маршрута когда-то давным-давно был важен, сейчас уже абсолютно не важен, поэтому мы по нему поговорим на отдельном слайде. Но он такой декоративный атрибут. И комьюнити — это дополнительные возможности, которые BGP предоставляет.

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

и NextHop у него какой-то кривой, вы этот маршрут сразу выбрасываете. Можно до этого маршрута, до этого NextHop балансировать трафик. Никто вам не запрещает это делать. То есть, например, если у нас есть наш роутер, есть два роутера соседа и есть какая-то выходная точка, как можно добраться до удаленной сети. У нас вот так вот все это дело связано. Здесь IBGP-шная связь. Приходит какая-то сеть А. И, соответственно, эти роутеры все имеют IBGP-шное full-меж взаимодействие. В этом случае роутер, допустим, R1, говорит, я знаю, как можно добраться до сети, я вижу сеть А, ко мне приходят два варианта IBGP-шных маршрута с одинаковыми свойствами через... Простите, ко мне приходит один маршрут IBGP-шный. Я неправильно здесь сказал, да? У нас сессии IBGP-шные, они у нас вот так вот выглядят. Вот так вот и вот так вот.

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

уже будет балансироваться через два разных шлюза. NextHop меняется, если вы получаете какой-то маршрут по EBGP, тогда сосед-отправитель вам этот самый атрибут проставляет в свой собственный адрес. Либо NextHop меняется, если вы сами придумываете маршрут. То есть если роутер R1 в своей автономной системе говорит, я хочу рассказать про сеть B. В этом случае он анонсирует эту сетку и говорит, я придумал эту сеть, посылайте по трафик до этой сети до меня, я дальше разберусь, как в эту сеть отправить трафик дальше. То есть либо свои локальные импортированные маршруты, либо EBGP-шные анонсы. Второй атрибут, который мы с вами разбирали, и давайте сейчас с ним познакомимся более детально, это будет ASPath. Список автономок, через который прошел маршрут. Физически, как уже сказано, это на самом деле четыре разных атрибута, которые нужны для того, чтобы работать с длинными автономками, с короткими автономками,

в пределах конфедерации, без конфедерации, ну и там сложно все. Если мы делаем еще суммарные маршруты, там так называемые аббегированные маршруты, там тоже добавляются свои усложнения, в общем там физическая природа этого атрибута, она сложная. Но, когда мы сработаем с этим атрибутом по простому какому-то алгоритму, мы просто берем и говорим, что там текстовая строчка, в которой просто записываются номера автономных систем. Когда у нас по BGP мы получаем маршрут, мы его либо получаем по IBGP и дальше пересылаем куда-то, если мы ротинг-ректор, мы не меняем этот атрибут, либо мы по EBGP получаем этот маршрут и пересылаем дальше по IBGP, мы опять же не меняем этот атрибут, либо мы по EBGP рассказываем про эту сетку куда-то дальше, и тогда мы в эту текстовую строчку спереди, так называемым препендингом, добавляем номер своей автономной системы. Фактически в подавляющем большинстве автономных систем этот атрибут записывается как текстовая строчка с номерами автономных через запятую. Вот, там, например, у нас есть какой-то роутер,

который в автономной системе номер один рассказывает про то, что есть какая-то сетка. Он рассказывает про эту сетку, говорит, я придумал такой маршрут, и это маршрут в автономной системе нашей. Роутер R12 говорит, окей, я понял, что это маршрут в автономной системе нашей, я сейчас по EBGP расскажу роутеру 21 и добавляет туда к пустой строке номер автономки 1. Дальше 21 роутер говорит, окей, все хорошо, я пересылаю это дальше по IBGP, атрибуты не меняю. R22 говорит, окей, я рассказываю про это 31 роутеру, который находится в другой автономке, поэтому я добавляю туда номер своей автономной системы. R22 получил в таблицу маршрутизации маршрут с номером автономной системы 1 одним-единственным в SPAV, а про эту сетку дальше рассказывает уже, что сначала надо пройти до второй автономной системы, потом выйти в первую, и можно будет попасть в сеть назначения, то есть 2,1. То же самое происходит вот по вот этому маршруту. Сначала 11 роутер рассказывает по IBGP 41,

что в нашей сети, в нашей автономке зародился какой-то маршрут, просто свой номер автономной системы указывает. R41 рассказывает 42, при этом неизменяемый атрибут. 42 рассказывает 51, добавляя номер автономки 4, 51 рассказывает 52, ничего не модифицирует, 52 рассказывает 31, добавляет свой номер автономной системы. Здесь, кстати, опечатка на слайде 5, 4, 1. И здесь начинает работать один из механизмов, которые используются для SPAV. Этот механизм заключается в том, что если к нам приходят два разных маршрута из двух разных автономных систем, то мы сравниваем, у кого короче список автономных систем. У кого короче, тот лучше. То есть чем через меньшее количество автономных систем проходит трафик до удаленной сети, тем более приоритетный маршрут. У кого длинная строчка, тот, соответственно, проходит через много разных транзитных автономных систем. Мы такому маршруту по умолчанию не очень сильно доверяем.

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

Это просто один из способов сказать, что вот нам надо каким-то образом сравнивать маршруты между собой, и количество автономок, это, в принципе, неплохой алгоритм, как не имея вообще никакой информации о качестве доставки данных, предположить, что в одном случае при прочих равных, соответственно, один маршрут будет более приоритетный или менее приоритетный, чем другой. Вот такое вот правило. Так, ну и, соответственно, вот наш роутер 31 получает от 22-го один маршрут с указанием автономных систем 2 и 1, то есть длина IS-path будет 2, и от 52-го роутера тот же самый маршрут, но, соответственно, с IS-path 5, 4, 1. То есть он в этом случае понимает, что здесь у нас длина IS-path 3, здесь у нас длина IS-path 2. В этом случае он говорит, этому мы не доверяем. Соответственно, доверяем только тому, у которого IS-path короче. Дальше начинает рассказывать про только тот маршрут, который уже выгодный. Про невыгодные маршруты мы не рассказываем.

31-го роутер рассказывает 32-му, опять же, не меняя атрибут, про то, как можно доставить трафик в дальнюю сеть. 32-й роутер, если будет рассказывать про эту сеть каким-то другим роутером в других автономных системах, он, опять же, свой номер автономки запрепендит и расскажет про то, что трафик выходит в третью автономку, потом идет через вторую, потом через первую. Этот самый атрибут IS-path, во-первых, нужен для того, чтобы выбирать, скажем, более короткие маршруты. Маршруты. Но короткие здесь не в смысле по задержке или по, там, не знаю, физическому расстоянию или по какому-то еще, просто вот как-то один из механизмов, как можно выбрать из двух маршрутов более правильный. Второй механизм – это будет, соответственно, защита от кольца. Если вдруг мы принимаем какой-то маршрут, который указывает в IS-path номер нашей собственной автономки, мы его в любом случае выбрасываем. То есть независимо от того, знаем мы такой маршрут на самом деле,

сами или не знаем. Если мы сами такой маршрут знаем, что в норме должно, конечно же, быть, мы скажем, окей, у нас есть маршрут, который мы знаем изначально. Возможно, с пустым IS-path, возможно, там, с IS-path, не знаю, длины один, ну, короче, более короткий IS-path. И мы принимаем от кого-то еще маршрут, соответственно, с более длинным IS-path. Ну, естественно, что мы его отбросим просто потому, что у нас есть более короткий. Но если вдруг мы рассказываем про какую-то сеть дому соседу, потом тот рассказывает про другую, потом тот рассказывает по третью, может быть такое, что в какой-то момент адреса, которые мы анонсируем, они немножко модифицируются. То есть может быть такое, что мы рассказываем про какую-то маленькую сетку, дальше вот оно вот так вот через петлю прошло, через петлю провайдеров, и в какой-то момент там где-то возникла агрегация. И в этой самой агрегации нам возвращается другая сеть, то есть у нас маршрут до другой сети. Но при этом в этом маршруте до другой сети все равно в ISPAS будет указана наша собственная автономка. Вот мы такому маршруту тоже верить не будем. Мы его отбросим. То есть никогда

ни при каких условиях вы не принимаете от соседа маршрут, у которого указана своя собственная автономная система. Это защита от петли между автономками. Очень простой механизм. Так, по поводу local preference. Это атрибут, которым мы можем влиять на приоритеты. Атрибут local preference позволяет вам указывать, какой из нескольких способов выхода из автономной системы будет более приоритетным. Обычно этот local preference назначается на пограничном роутере, который получает определенный маршрут. Вот удобный сценарий, как можно использовать этот local preference. У нас есть наша автономная система. В ней у нас есть два пограничника. R1 и R2. И, соответственно, это все смотрит на два разных провайдера. В принципе, это можно сделать и с одним пограничником, который на двух разных соседей, на двух разных пиров из двух разных автономок смотрят.

Но, по большому счету, с двумя это будет более интересно. Если мы хотим влиять на то, через какой апплинк трафик будет выходить до определенной сети, если мы в своей автономной системе хотим направить трафик куда-то вот, например, здесь вот у нас есть некая сетка, и мы хотим сказать, что трафик должен ходить через верхний апплинк, но через нижний. В этом случае на маршрут до указанной сети, которая приходит от верхнего апплинка, мы должны будем назначить local preference больше, чем на другой. По умолчанию local preference назначается 100. Ну, соответственно, вот если у нас есть маршрут, который приходит от провайдера номер 2, router R2 будет говорить, окей, у меня есть eBGP-шный маршрут, который я рассказываю своим соседям и рассказывает, у меня есть маршрут за 100 копеек. Ну, не за 100 копеек, маршрут с local preference 100. То же самое будет происходить на верхнем роутере R1, но, соответственно, он будет назначать другой local preference. В любом случае сам local preference не

передается, но мы говорим, что вот, окей, у нас приходит какой-то маршрут, и мы ему назначаем local preference 150. И этот 150 preference будет распространяться на все остальные роутеры. В этом случае даже сам роутер R2, сказав, что знает сетку с local preference 100, но получив указание, что сосед знает сетку с local preference 150, будет направлять трафик через этого самого соседа. То есть он не будет направлять трафик в eBGP-шный мир. В соседнюю автономку он будет в своей автономной системе передавать этот трафик на роутер R1 и далее через более пригодный, более дешевый, например, или более выгодный апплинк до указанной сети. То есть это такой классический механизм, как можно в своей автономной системе сказать, через какой апплинк мы ходим до другой автономки. Local preference для этого специально выделенный стандартный атрибут. Через другие атрибуты гипотетически тоже можно как-то это попытаться поделать, но это все атрибуты будут

уже нестандартные. Вот если мы хотим стандартным способом работать, то мы используем local preference. В eBGP-шной связи local preference не передается. Он передается только по iBGP-шной связи, ну и поэтому никто не узнает, что какие-то маршруты вы считаете более или менее приоритетными за пределами вашей автономки. Роутер провайдера второго, он вам со своей стороны честно присылает маршрут, ну а то, что вы этим маршрутом не пользуетесь, ну не пользуетесь, не пользуетесь. Что касается руления выходом из вашей автономной системы и, простите, входом в вашу автономную систему, то для этого local preference не подходит, потому что вы должны будете local preference указывать, какие маршруты вы выбираете. Вы не можете с помощью local preference проконтролировать, какие маршруты выбирают соседние автономные системы. Если вдруг у вас есть несколько вариантов, как направить трафик в вашу автономную

систему, то в любом случае вы анонсируете маршруты по обоим вашим соседствам. Например, в нашем случае у нас есть автономная система здесь и автономная система здесь. Наша автономка слева, и у нас есть канал более приоритетный и менее приоритетный. Например, вот этот вот более быстрый канал, он, не знаю, гигабитный или 10-гигабитный, или 100-гигабитный, не суть важна, это канал 100-мегабитные, запасной. Вот мы хотим в этом случае, чтобы весь трафик по умолчанию ходил через верхний линк. Мы направляем указание, что у нас есть какая-то сетка за нашей спиной, и эта сетка имеет МЕД Мультиэкзин Дискриминатор 50. Через нижний линк мы тоже направляем этот маршрут, но мы указываем там МЕД 100. МЕД передается соседу, которому мы указываем, что мы его отправляем, и плюс он передается по IBGP-шным связям, но дальше по EBGP-шным связям за пределы автономки соседа он передаваться не будет. Поэтому мы указываем на своем соседстве, что у нас МЕД 50 здесь и МЕД 100 здесь. Это передается по связи, которую мы указываем. Дальше все вот эти вот роутеры в соседней автономке этот самый МЕД увидят, но в другие автономные системы МЕД передаваться не будет. Он просто срежется. Этот атрибут никому не будет показываться.

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

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

и Ростелеком не имеет никаких предпочтений, как возвращать трафик в нашу автономку, то мы можем в один линк поставить МЕД побольше, в другой поменьше, трафик будет ходить через тот линк, где МЕД поменьше. Но только из Ростелекома. Через один линк, который мы укажем, который смотрит на соседнюю автономку Ростелекома. Но эта задача достаточно редкая, поэтому МЕД используется нечасто. Для того, чтобы контролировать, как трафик будет возвращаться в вашу автономку, вместо МЕДа в ситуации, когда у вас есть два разных апплинка, две разные автономки соседней, и вы хотите возвращать трафик через одну автономку, но не через другую, для этого можно использовать техники, которые не дают вам гарантированный результат, но тем не менее они работают в случае, когда у вас есть два разных апплинка. Одна техника будет предполагать использование атрибута комьюнити, который мы сейчас чуть попозже посмотрим, а другая будет использовать возможность искусственно удлинить ISPath.

Как мы помним, если у нас приходят два разных маршрута до одной и той же сети из двух разных автономок, то ISPath проверяет, что у кого короче, тот и лучше, у кого длиннее, тот плохо. Так вот, если вы возьмете и в менее выгодную автономку отправите маршрут с искусственно удлиненным ISPath, то есть добавите туда лишние какие-то номера автономок, чтобы она искусственно становилась хуже, то в этом случае вы можете сделать так, чтобы сосед пренебрегал маршрутом, полученным с невкусным ISPath. Иногда эта техника работает, иногда нет. Но это достаточно слабая техника в том смысле, что она довольно редко все-таки работает. Чаще всего, если вы как клиент хотите дружить с провайдером или вы как провайдер хотите дружить с каким-то аплинком и направлять трафик по одному линку, а не по другому, то вы будете использовать комьюнити. Комьюнити — это механизм расширения функциональности BGP. Так же, как, допустим, поле options в IP или в TCP предусматривает,

что у нас есть какие-то вещи стандартные, которые можно сделать с помощью штатного заголовка, а есть нестандартные. Вот комьюнити — это такой вот механизм, как можно добавить в BGP чего-нибудь, чего мы не знаем сами, чего хотим. Это фактически метки, которые вы можете повесить на маршрут. Это не какие-то просто, не знаю, метки типа теги. Это именно, если хотите, можно сказать, раскрашивание маршрутов. То есть на каждый маршрут можно повесить несколько этих самых меток, несколько комьюнити. Причем на самом деле комьюнити изначально, которые были придуманы, они были достаточно неудобны в использовании, они были коротенькие, и штатный механизм, который был предложен в 97-м году для этих самых комьюнити, выглядел как то, что вы на каждый маршрут могли повесить метки формата двухбайтовое число, двухбайтовое число через двоеточие. То есть фактически это было 32-битное число, и можно его рассматривать как монолитное 32-битное число, но вообще оригинальное значение этого 32-битного числа было такое,

что вы в верхнюю, в старшие два байта, в старшие один байт, нет, два байта, в старшие два байта вписывали номер автономной системы. Либо своей автономной системы, либо автономной системы того, кому вы это все дело адресовали. То есть вы проставляете какие-то метки, и вы указываете, что вот эта метка адресована получателю этого маршрута в автономной системе такой-то. И дальше вы могли указать оставшиеся два байта, просто какое-то значение, что вот 17, например. То, как получатель такой метки должен трактовать число 17, комьюнити никак не специфицирует, но вы можете, например, договориться, сказать, что если я отправляю маршрут в сторону соседа, и я проставляю value 17, то получатель такой метки будет, не знаю, каким-то образом, там, не знаю, local preference для этого маршрута выставлять искусственно побольше. То есть вот таким вот образом вы можете договориться

с определенной автономкой, что если вы раскрасите специально для этой автономки трафик, то тогда получатель такого... не трафик, а маршруты. Получатель такого маршрута сможет каким-то образом эти маршруты обработать специальным образом. Но эта штука будет основана на договоренностях, естественно. Очень быстро сразу стало понятно, что, во-первых, вот эти вот номера автономных систем, они стали 32-битные, а во-вторых, value, которую можно вписать, 2-байтовая, оно, в общем, не самое ширное. По размеру становится достаточно компактное. И если хочется много возможностей чего-нибудь проставить, то 16-бит для этого просто откровенно мало. Поэтому появились Extended Communities. Штука примерно тогда же появилась, когда появился BGP четвертой версии. По-прежнему работает с 16-битными номерами автономок, но позволяет указать несколько меток разного типа. И, соответственно, эти метки будут 6-байтовые, что, конечно, уже сильно лучше, чем 4-байтовые метки. То есть вы указываете 16-битный номер автономки

и дальше какое-то вложение. Вложения уже могут быть разные, и они могут быть достаточно большие. То есть у них вы можете написать существенно больше различных вариантов указаний, что с этим делать. Но автономки были по-прежнему 16-битные. Начиная с 2010 года, как вы помните, в интернете используются 32-битные автономки. Поэтому по факту вы должны будете каким-то образом все равно трактовать это первое поле 16-бит не как номер автономной системы, а просто как дополнительный 16-бит, который можно присобачить к комьюнити. И, опять же, должны будете договариваться, как трактовать вот эти вот самые первые 16-бит, как трактовать все оставшееся, то, что там в экстрендатор комьюнити передается. Буквально недавно, то есть около года, что ли, назад, был стандартизирован вариант large communities, который указывает именно 32-битные номера автономных систем. То есть в интернете уже 10 лет, как используются 32-битные автономки, но для комьюнити, вот для того, чтобы в стартовом,

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

но по факту их чаще всего транзитные роутеры не счищают. При этом то, что вы внутрь комьюнити напишете, это исключительно ваша, скажем, фантазия больная может указывать, что там внутри будет храниться. Для того, чтобы правильно обрабатывать эти комьюнити, нужны какие-то договоренности. То есть нужно будет сказать, что если я вписываю номер комьюнити такой-то, то значит это обозначает вот такое-то. Если я указываю номер комьюнити другой, то это обозначает что-то другое. Никаких стандартных особенно договоренностей нету за очень небольшими исключениями. Стандартные метки — это стандартный комьюнити, простите, комьюнити no export. Это означает, что если вы порождаете какой-то маршрут и вешаете на него комьюнити no export, то в этом случае он распространяется в пределах вашей автономной системы, но не уходит EBGP-шным соседям. То есть это стандартное поведение. Любой роутер, который находится на границе автономок, пограничник, он такой маршрут, принимая по IBGP-шной связи или как-то еще, он не будет его анонсировать по EBGP.

Комьюнити no advertise не будет анонсировать такой маршрут никому. То есть вы маршрут принимаете, дальше вешаете на него no advertise, он у вас в таблице маршрутизации есть, а вы его никому больше не показываете. Иногда это бывает интересно. И, наконец, комьюнити black hole. Это очень интересная штука. Она предполагает, что вы анонсируете маршрут с вашим соседем, и ваши соседи должны будут, получив такой маршрут, установить NextHop в 0.0. То есть маршрут устанавливается в таблицу маршрутизации, вы его присылаете, он устанавливается в таблицу маршрутизации у соседей, но вместо того, чтобы смотреть на NextHop IP-шника, который вы присылаете, указывается NextHop интерфейс 0.0. И трафик, идущий на этот IP-шник, он будет отбрасываться. Это стандартный способ, как можно защититься, например, от DDoS-атаки. У вас есть роутер, так почему мне не рисует опять ничего, роутер, у которого есть аплинк, на этот аплинк приходит DDoS. То есть много-много-много-много трафика.

Вы хотите, чтобы у вас ваш клиент, на который идет DDoS, соответственно, перестал бы вызывать этот самый DDoS. То есть у вас есть клиент, вы провайдер, у вас есть клиент-клиент, здесь есть какой-то сервер. У этого сервера есть IP-шник. 10.0.0.1. DDoS идет именно на этот самый IP-шник. Вы не можете справиться с таким вот объемом трафика. У вас вот этот вот интерфейс перегружен. У вас помимо этого клиента есть еще куча других клиентов. Если вы этого клиента просто отключаете, DDoS от этого никуда не денется. Он будет точно так же продолжать литься на ваш интерфейс, забирая все ваши ресурсы и отключая тем самым остальных клиентов от нормальной работы. Поэтому для того, чтобы у вас все продолжало работать, вы отправляете сообщение вашему аплинку с указанием. Занулировайте мне, пожалуйста, вот именно IP-шник 10.0.1. Вы посылаете 10.0.1. 10.0.0.1. Слэш 32. И указываете метку 666.

Это стандартное обозначение для Blackfall метки. То есть автономная система 65535, специальная служебная автономка, и 666 – это значение метки. Тем самым вы, продолжая анонсировать все те же самые маршруты, продолжая анонсировать всю сетку, которую вам изначально ваш проблемный клиент анонсирует, то есть это у вас никуда не девается, добавляете к набору анонсируемых маршрутов тот проблемный IP-шник, который указан с 666 меткой, ваш аплинк такой маршрут принимает, и он у себя в таблице маршрутизации, продолжая добавлять маршрут до клиента в целом, добавляет также маршрут и до отдельного IP-шника. Но при этом он у себя ставит маршрут 0.0, следовательно, весь трафик DDoS, который сваливается на него, он дальше никуда не пересылает. И ваш интерфейс освобождается, ваши клиенты, все остальные продолжают работать, и все остальные IP-шники этого клиента тоже продолжают работать. То есть вот такой вот механизм, это позволяет вашему аплинку сказать,

чтобы он перестал на вас лить DDoS до некоторых определенных IP-шников. Естественно, что это требует договоренности, чтобы ваш аплинк такие комьюнити, а, принимал от вас, б, обрабатывал бы их таким образом. Но обычно это комьюнити достаточно стандартные, и чаще всего аплинки такие штуки реализуют. Можно встретить и другие договоренности, то есть естественно, что именно этими тремя комьюнити договоренности не ограничиваются. Например, комьюнити, которые используются в автономной системе московской точки обмена трафиком, msk.ax, можно посмотреть по вот такой вот ссылке. Вот пример того, какие комьюнити используются на msk.ax. То есть если мы отправляем некий маршрут, и мы указываем, что мы хотим заблокировать его, мы указываем вот такой вот blackhole комьюнити, достаточно стандартный. Если мы хотим использовать технику asprepend,

и мы хотим использовать ее на msk.ax, мы не должны будем заниматься этим самостоятельно. Мы в этом случае посылаем маршрут с указанием комьюнити, и сама точка обмена трафиком будет эти самые маршруты препендить. То есть это защищает точку обмена трафиком от того, что комьюнити будет, не комьюнити, а препендинг будет использоваться как-то беспорядочно, но при этом вот такой вот механизм позволит хоть как-то контролировать этот процесс и убедиться, что препендинг будет осуществляться в рамках каких-то разумных мерок. Можно будет дополнительно там, не знаю, local preference указать. То есть если, опять же, вы анонсируете в сторону соседа некий маршрут, и сосед сказал, что если вы проставляете вот такой вот local preference, например, 50, то вы, проставляя в маршруте комьюнити с указанием вот такого вот номера, заставляете вашего соседа поставить local preference 50.

Можно, например, сказать, мы посылаем два разных маршрута через два разных линка. В одном мы просим проставить local preference 50, в другом мы просим проставить local preference 100. Естественно, работать будет тот маршрут, в котором проставлен local preference 100. Чаще всего пиры, которые дружат по BGP, они имеют вот такие вот наборы договоренностей, которые где-то зафиксированы, либо в каком-то документе, либо просто в устной форме вам скажут, ну давай присылай нам вот такой вот комьюнити, а мы в зависимости от этого проставим там либо local preference, либо асприппендинг для тебя сделаем, либо что-то еще. Ну вот как образец вы можете это дело посмотреть. Так, далее. Код происхождения маршрута в BGP означает примерно ничего. То есть когда-то давным-давно эта штука использовалась для защиты от петли, как ни странно. У вас в коде происхождения указывается, где взялся в оригинале маршрут. Если вы указываете код происхождения 0, это значит, что маршрут изначально появился в BGP в некоторой автономной системе,

и исходный префикс принадлежал изначально этой самой автономной системе. То есть у вас интернет состоит из автономных систем, одна автономная система, вторая автономная система, третья автономная система. И вот где-то зародился некий узел, некий префикс, и вот он дальше начинает разбегаться по BGP, по интернету. Блин, простите. Я не знаю, что у меня такое происходит, но компьютер у меня явно себя ведет некорректно. И этот самый код происхождения 0 означает, что это фактически нормальный в оригинале зародившийся в BGP маршрут, ниоткуда не переложенный. Если вы видите там число 1, это означает, что маршрут изначально взялся не в BGP. Значит, у нас есть какой-то роутер, который в BGP этот маршрут анонсирует, он его придумывает, он его вбрасывает в BGP, но он сам его знает не потому, что этот префикс видит в своей автономной системе, а он этот маршрут видит в протоколе EGP, который очень древний, который совсем не нужен в современном мире. И, соответственно, вот это вот EGP, это не экстериор-гитвый протокол, как класс протоколов, а именно конкретное самое название протокола.

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

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

Далее, далее, далее. Все атрибуты, которые есть в BGP, они будут иметь некие свойства. И вот эти вот самые свойства нужно будет знать. Я не уверен, что на экзамене вас это будут спрашивать, но, по крайней мере, на следующем уровне, на CCNP, эти самые свойства надо будет знать как урченаж. Свойств на самом деле всего четыре. То есть атрибут может быть либо well-known mandatory. Это значит, что все узлы обязаны его распознавать, обязаны его корректно читать. Даже самые-самые-самые старые роутеры все равно обязаны его уметь воспринимать. И в абсолютно любом апдейте этот атрибут должен присутствовать. Well-known mandatory атрибут — это абсолютно всегда присутствующий атрибут. Абсолютно все роутеры его должны уметь читать. Например, нельзя отправить апдейт, в котором не будет NextHop. И нельзя отправить такой апдейт, в котором есть NextHop, который кто-то не поймет, что это NextHop. То есть NextHop — это что-то, что все обязательно должны будут уметь читать.

IcePass — то же самое. Нельзя отправить апдейт, в котором не указано IcePass вообще, или IcePass кто-то транзитный не поймет. Потому что IcePass — это основной атрибут, который в любом случае всеми должен поддерживаться. Well-known discretionary attribute — это атрибут, который все обязаны поддерживать, но он не обязательно передается в совершенно произвольном апдейте. Как, например, LocalPreference. Он не передается в EBGP. Он передается только в IBGP. Поэтому в некоторых апдейтах LocalPreference может отсутствовать. Да. Его все равно все обязаны воспринимать. То есть если он указан, любой узел должен понимать, что это такое. Поэтому этот атрибут well-known. Но он необязательный. Как минимум, в EBGP его быть не может. А в IBGP он, напротив, быть обязан. Поэтому не во всех абдейтах он есть. И он по этой причине дискретно. Дискретно. Опциональный транзитивный атрибут. Означает, что атрибут может не пониматься каким-то транзитным роутером,

но если какой-то транзитный роутер его не понимает, он все равно должен передать его дальше. Опциональный транзитивный атрибут — это, например, тот самый community. То есть черт его знает, что там вы в community понаписали, какие вы метки проставили. Даже если вдруг транзитный роутер вообще не знает, что такое community, даже если он не знает, что такое расширенный community или large community 32-битный, он все равно должен дальше это передать, потому что следующему узлу цепочки этот community уже может быть интересен. То есть необязательно уметь его обрабатывать для того, чтобы получить пользу от этого атрибута. Вы не понимаете, как его обрабатывать, но вы-то просто дальше передайте его по цепочке, кто-то дальше поймет. Но и, соответственно, community почти всегда при передаче сохраняется, почти всегда присутствует, но он совершенно не обязан присутствовать и совершенно не обязан быть обработан на совершенно любом роутере. Поэтому community атрибут опциональный и транзитивный. И последний тип атрибутов — это опциональный нетранзитивный. То есть если атрибут даже и указан, он совершенно не обязан поддерживаться всеми узлами.

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

они тоже будут исходить из того, что вы со своей стороны использовали MED именно… использовали маршрут с меньшим MED. Если вы не выбрали маршрут с меньшим MED, потому что вы не понимаете, как он устроен, остальные роутеры вообще в этом случае про MED ничего не должны знать. Как будто и вы тоже про него ничего не узнали. Вы в этом случае MED просто скрываете. Вот. Опциональный нетранзитивный атрибут может отсутствовать. Он не обязан присутствовать в любом апдейте. может быть удален при передаче и не обязан, даже если он присутствует, корректно обрабатываться всеми узлами. Вот. Такая вот штука. Атрибуты у нас соответственно NextHop, ISPath, Community, MED, Origin и LocalPreference. Это атрибуты, которые предусмотрены стандартным 42.71. И если у нас есть некоторое количество маршрутов, которые идут до одной и той же сети,

соответственно, стандарт предписывает нам использовать алгоритм выбора лучшего маршрута в следующий. Во-первых, мы можем добавить в таблицу маршрутизации много разных маршрутов до разных сетей. Но мы не можем в таблицу маршрутизации добавить лучшие маршруты, которые будут смотреть до одной и той же сети. Маршрут можно добавить только один. Best Path Selection намекает на то, что лучшим одним маршрутом будет выбран некоторый маршрут по какому-то предсказуемому алгоритму. Нельзя добавить несколько маршрутов и объявить их все лучшими. В качестве лучшего маршрута может быть маршрут выбран только, если у него Next� Atlanta правильный. То есть если нам присылает какой-то сосед апдейт, и в этом апдейте указан NextHyрас элемент, который мы не резолвем, такой маршрут не может стать лучшим. Поэтому такие маршруты сразу отбрасываются. Равным образом отбрасываются маршруты, которые содержат наш собственный ISPath. То есть если приходит какой-то маршрут, и в нем указан наш собственный ISPath,

то такие маршруты тоже сразу отбрасываются. Есть исключения, когда это правило будет нарушаться, но это именно надо специально сказать, что именно в этом случае мы такое правило нарушаем в силу каких-то причин. Дальше. Если маршруты реализовываются в NextHop, если маршрут не содержит своей собственной автономки, маршрут доступный, в принципе, неплохой. Дальше мы сравниваем Local Preference. Local Preference — наиболее сильный атрибут. То есть если вы указываете, что у нас есть два маршрута до некоторой сети, и у одного из них проставлен Local Preference, и у другого проставлены Local Preference, и они разные, мы предпочитаем маршруты с большим Local Preference, числово большим. Если Local Preference приходит по умолчанию, назначается 100. Дальше. Если два или более маршрутов есть, у которых Local Preference получился одинаковый, то мы работаем по алгоритму дальше. Берем маршруты, у которых более короткий айспав. То есть просто числово количество айспав меньше.

Здесь сравнивается не длина строки в символах, а длина строки в запятых, если хотите, сколько номеров автономок там есть в строке. Опять же, меньше — лучше. Если вдруг есть несколько апдейтов, в которых пришли маршруты с одинаковым количеством автономок, тогда сравнивается код происхождения. Самый выгодный способ, откуда можно взять маршрут, — это код происхождения 0, то есть маршрут нативно зародился в BGP. Следующий код происхождения — это EGP, то есть известно, откуда он пришел, просто из плохого протокола, который ненадежный. И самый-самый последний способ получения маршрутов — это непонятно откуда. Вот в этом случае, если там стоит инкомплит, то есть код происхождения 2, это наименее доверенные маршруты. Если мы взяли несколько маршрутов, и у них одинаково маленький Origin, то дальше сравнивается Med. Выбираются маршруты, которые получены из одной и той же автономки, и у которых Med будет самый маленький.

Если Med вообще нет, то предполагать его значение наименьшим возможным. То есть если Med не указан, то это лучше, чем если Med указан, и он, допустим, один. Если Med не указан у нескольких маршрутов или указан, но у двух маршрутов Med одинаковый, и получены из одной и той же автономки эти маршруты, то дальше начинают сравниваться свойства этих маршрутов, которые не в атрибутах записаны, а получены самостоятельно роутером, исходя из того, через каких соседей он эти маршруты получил. Следующий шаг — это мы сравнили все свойства маршруту самостоятельно, которые были указаны соседам. Дальше мы начинаем фактически сравнивать самих соседей, которые нам это прислали. Проверяем, что маршруты EBGP-шные заведомо лучше, чем IBGP-шные. Здесь используется техника горячей картошки. Hot Potato Routing. Если у нас есть два маршрута, один из них получен по EBGP, второй по IBGP,

то это означает, что маршрут EBGP-шный в принципе такой же по хорошей стиле и плохости, по атрибутам, как маршрут IBGP-шный. Но если мы маршрут EBGP-шные видим, значит, маршрут пришел из другой автономки, если мы видим при этом маршрут IBGP-шный, это значит, что он тоже пришел из другой автономки в нашу автономку, а потом сосед в нашей автономке прислал этот маршрут нам. Нет смысла посылать этот маршрут по нашему собственному линку, соседу, чтобы сосед дальше выплюнул это все наружу. Потому что нет никакого приоритета в этом смысле у соседа. Мы лучше его сразу выплюнем наружу и не будем занимать наш внутренний лин. Поэтому маршруты EBGP-шные на шестом шаге будут предпочитаться маршрутам IBGP-шным. Если маршруты оба EBGP-шные, или там 2, 3, 10 маршрутов EBGP-шных мы сравниваем, при том, что все атрибуты у них одинаковые, или все маршруты будут IBGP-шные, неважно. В этом случае мы смотрим на NextHop

и берем в таблицу маршрутизации, проверяем метрику до того маршрута, который содержит в себе NextHop. То есть нам присылает сосед указание, что если хочешь ходить до какой-то сетки, ходи через меня, в предположении, что у нас маршрут будет, соответственно, IBGP-шные. В этом случае смотрим, сколько стоит добраться до каждого NextHop. И берем тот, у которого метрика IGP-шная, то есть метрика в таблице маршрутизации будет меньше. Например, мы до пограничника считаем, сколько стоит добраться по SPF. Нам прислали 2 пограничника 2 разных маршрута, мы говорим, окей, до одного пограничника по SPF стоит добраться 10 копеек, до другого 11. Вот NextHop, которые прописаны там. Соответственно, мы ходим через того, у которого метрика 10. Если у нас 2 EBGP-шных соседа, то в этом случае, опять же, сравниваем, кто из них находится ближе. Ну, метрика там для коннект-маршрутов обычно не используется, но, тем не менее, если вдруг она там будет,

будем сравнивать ее. Если не получилось выбрать на этом этапе более выгодный маршрут, дальше начинаем уже просто подбрасывать монетку, говорим, у нас 2 почти одинаковых маршрута, у них вообще все одинаковое. Они оба получены либо по EBGP, либо по IBGP, у них одинаковое расстояние до NextHop. Нам нужно просто каким-то образом среди них выбрать один. Мы не можем бросить монетку, потому что это будет недетерминированный результат. Мы каждый раз будем получать разные результаты. А вот если мы будем брать, например, роутер ID больший, то тогда мы будем всегда получать один и тот же результат. Поэтому на восьмом шаге мы говорим, окей, мы понимаем, что разницы с топологической точки зрения между маршрутами нет, поэтому мы берем просто маршруты, полученные от соседа с большим роутер ID. Если два маршрута получены от одного и того же соседа, просто по двум разным проводам, то тогда мы будем сравнивать айпишники соседей, которые нам это дело прислали. У кого больше, тот и прав. С помощью такого механизма вы всегда из некоторого набора маршрутов

выбираете один маршрут, который будет самый выгодный. То есть нельзя сделать так, чтобы у вас пришло два выгодных маршрута, после этого Best Path. Два самых выгодных. Он всегда будет получаться один самый выгодный, даже если вам придется фактически подбрасывать монетку. Ну и этот маршрут вы добавляете в таблицу маршрутизации, и именно этот маршрут вы начинаете рассказывать своим соседям. Пожалуйста, не путайте то, что здесь указано, с стандартной цисковской формулой null omni, потому что это выбор маршрута по RFC 4271. Здесь сравнивается next hold, проверяется, что он резолвится. Здесь сравнивается local preference. Здесь не сравнивается то, что маршрут локальный или не локальный. То есть вторая буковка L в null omni формуле, которая в цисковских курсах есть, ее здесь нет. Здесь чего-то тоже еще нет.

Чего-то тут еще нет, чего-то еще нет. Забыл, чего тут еще нет. Ну, в общем, дальше у нас будет в курсе цисковская формула. Я вам про нее отдельно расскажу. Так. Ну и заканчиваем мы говорить про BGP, про теорию BGP. Дальше будем уже переходить к MPS и потом к практике. Если у вас есть BGP-шное соседство, то вы можете защититься от попытки подключения к вашему роутеру от всяких левых узлов. Так. Кстати, вижу на слайде здесь ошибку. Вот RFC не 592, там четырехзначный 59 чего-то там. Может быть 20, может быть что-то еще. К сожалению, тут ошибка, да. BGP-шная аутентификация будет осуществляться не так же, как в OSPF, не так же, как в EGP, не так же, как в ISIS. У нас, поскольку используется TCP, то вы можете использовать штатный механизм, который называется TCP Authentication Option. И это означает, что каждый сегмент, который TCP будет отправлять,

он будет подписываться цифровой подписью. Это делает сам стек TCP. Это делает не BGP, а именно TCP. И вы можете использовать в Authentication Option либо алгоритмы, соответственно, MD5, либо SHA-1, либо какие еще захотите, такие, в общем, и используйте. Если вы будете работать с оборудованием, которое использует старый механизм аутентификации, то вы можете встретить другой вариант. Это не Authentication Option с 59 каким-то там RFC, а TCP MD5 Signature Option. Это более старая штука. Смысл у нее заключается в том же самом, что в каждом сегменте, который вы отправляете, вкладывается хэш от содержимого этого сегмента и некоторого пароля. Но механизм, как генерится этот самый хэш, он будет, соответственно, более слабый. И в случае с старым вот этим механизмом MD5, естественно, хэш будет только MD5. Например, если вы на CISC включаете аутентификацию

с помощью штатного механизма, когда вы указываете neighbor и password, там используется как раз устаревший вариант. И если вы хотите переключить CISC в более новый вариант Authentication Option, вам следует использовать ключевые цепочки. Так. Ну и последнее, что касается динамической маршрутизации, что все маршруты, которые мы принимаем, мы их просчитываем, что некоторые из них будут лучше, некоторые из них будут не лучше. Мы в итоге должны будем добавить в таблицу маршрутизации. Если у нас есть провайдерский сценарий, в некоторых случаях этих таблиц маршрутизации мы можем хотеть иметь несколько. И эта штука реализуется на оборудовании с помощью концепции VRF – Virtual Routing and Forwarding. Смысл заключается в точно том же самом, что и на свитчах мы можем взять и разделить один большой мега-виртуальный широкопрещательный домен на несколько маленьких широкопрещательных доменах. В любом случае у нас на железе

выполняется маршрутизация или коммутация. Но в случае с VLAN-ами мы делаем фактически вместо одного свитча несколько маленьких. В случае с VRF мы делаем вместо одного роутера несколько маленьких. Если мы делаем VLAN без транков, то мы в этом случае говорим, что у нас все интерфейсы, например, будут аксессовые, указываем каждый аксессовый интерфейс, в какой VLAN будет смотреть. Та же самая история с VRF. Если мы не делаем взаимодействие между VRF-ами, мы просто указываем, что определенный интерфейс будет смотреть в определенную таблицу маршрутизации. У нас на одном виртуальном роутере будет связь с несколькими интерфейсами, на другом роутере с несколькими другими интерфейсами тоже будет связь. В принципе, можно будет сделать сценарий, который называется VRF Lite, при котором вы просто разделяете ваш роутер на несколько, вот этот интерфейс и этот интерфейс смотрят на один роутер, Вот этот и вот этот на другой роутер. Связи между ними в принципе нет. Если вы хотите организовать связь с каким-то другим роутером, на котором тоже сделать связь в нескольких VRF,

такая же вот картинка здесь будет, мне просто лень рисовать. Один виртуальный роутер, другой виртуальный роутер. Вы поднимаете связь между ними по каким-то отдельным интерфейсам. Эти интерфейсы можно сделать, например, субинтерфейсами. То есть вы внутрь VRF можете отдать субинтерфейс. Пожалуйста, никаких проблем. У CISC есть фирменная CISC-овская штука, которая называется Easy Virtual Network. Когда вы можете взять и сделать 802.1Q-шный транк, вместо того, чтобы поднимать кучу 802.1Q-шных субинтерфейсов, вы можете сказать, что давайте сделаем так, чтобы номер 802.1Q-шного VLAN соответствовал бы в физическом интерфейсе номеру VRF. И мы каждый VRF таким образом пронумеруем. Но все-таки это достаточно экзотическая штука. Чаще всего в провайдерах, если мы говорим про VRF, то взаимодействие между роутерами осуществляется не по нескольким разным субинтерфейсам,

и не с помощью вот этого самого Easy Virtual Network, CISC-овского, а с использованием MPLS. С помощью такой штуки вы можете организовать, например, услугу L3VPN, когда провайдер оказывает услугу VPN-у клиенту, и клиент отправляет какие-то маршруты, например, по OSPF на провайдерский роутер. Провайдерский роутер эти OSPF-ские маршруты берет, запихивает в таблицу маршрутизации, которая соответствует только этому клиенту, и никому больше. И дальше все роутеры-пограничники, которые смотрят на именно этого клиента, будут обмениваться маршрутами, не путая эти маршруты клиентские, с маршрутами других клиентов. То есть они живут как бы отдельно и обособлено. Если мы говорим, например, про BGP, то у BGP репликация будет каждого клиента отдельно и независимо друг от друга. В принципе, все протоколы, которые мы в курсе, ну не все, ладно, но OSPF и BGP, протоколы, которые мы рассматривали, умеют работать с VRF, вы можете взять и сказать,

что у вас взаимодействие для определенной таблицы будет происходить в конкретном протоколе. То есть маршруты OSPF посчитал и положил в таблицу номер один, в таблицу клиента номер один. Или там BGP тоже взял, посчитал какие-то маршруты самые выгодные и положил в таблицу маршрутизации VRF клиента номер два. Кроме того, если мы говорим именно про BGP, то BGP умеет передавать маршруты по одной и той же сессии с одним и тем же соседним роутером с пометкой, из какого VRF они прибежали. То есть в BGP вы можете взять, построить единую BGP-шную сеть в ядре и дальше сказать, вот мы соседним роутером будем рассказывать про то, какие у нас есть маршруты, и некоторые маршруты мы будем говорить, что это наши собственные маршруты, некоторые маршруты – это клиента номер один, некоторые маршруты – клиента номер два. соседний роутер не перепутает, в какую таблицу маршрутизации складывать какие маршруты. Ну и дальше с использованием MPLS

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

MPLS создавался как технология ускорения работы IP, но впоследствии выяснилось, что ускорить работу IP можно и другими способами. Например, если вы используете аппаратное ускорение Cisco CF, Cisco Express Forwarding, то вы фактически сложность работы маршрутизации сводите к той же самой сложности, что есть в MPLS. Поэтому для ускорения работы MPLS сегодня не используется. Но MPLS сегодня используется ради каких-то других механизмов, которые в нем появились. Это, в частности, трафик инжиниринг, когда вы можете внутри сети MPLS направить трафик по каким-то известным трассам, которые не будут зависеть от заголовка IP. И эти трассы будут автоматически перестраиваться со соблюдением определенных критериев, которые вы к ним предъявляете. Например, есть такая штука, как MPLS traffic engineering. Вы можете сказать, что, допустим, трафик телефонный должен ходить по определенной трассе через более дорогой интерфейс,

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

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

вы такой пакет пропускаете без особых проблем через свою сеть. Выглядеть это будет следующим образом. Вы берете данные, которые вы хотите отправить через сеть MPLS. Изначально она разрабатывалась для протокола IP, поэтому я покажу на примере протокола IP. У нас есть какой-то пакет. Этот пакет состоит из... Так, где моя рисовалка-то? Рисовалка. Вот, этот пакет состоит из IP-шного заголовка плюс какого-то там вложения, например, UDP и данных. Дальше все это дело, возможно, приходит на кастомерский роутер. Кастомерский роутер пересылает это все дело нам на провайдерский роутер. То есть здесь идет просто обычная маршрутизация IP. Роутер кастомера умеет работать с IP-пакетами, умеет работать с маршрутизацией и знает, где какие маршруты используются. То есть он выполняет маршрутизацию по-честному. Дальше он направляет IP-пакет на наш провайдерский роутер, но наш провайдерский роутер

не очень хочет делать все прям совсем по-честному. И даже если ему придется сделать что-то по-честному, он не хочет, чтобы все роутеры, все те провайдеры сделали это натурально все по-честному. Поэтому он здесь создает VRF. Дальше. Трафик, который попадает в этот VRF, он, соответственно, должен будет отправляться на какой-то другой роутер. На этот пакет вешается специальная метка и кадр или пакет, IP-пакет, в нашем случае с дополнительной меткой отправляется на соседний роутер, роутер P. Обратите внимание на вот эти вот буковки. CE – это Customer Edge, то есть кастомерская железка, а PE – это Provider Edge. Это уже наша провайдерская железка, которая немножко знает о кастомере, но в целом она также умеет работать и с MPLS. Пакет отправляется на роутер, который P-роутер, и вот этот вот п-роутер, он уже не пограничный роутер, он уже ничего не знает о кастомере, и он ничего не знает о содержимом этого пакета, об IP-вложении. Он ориентируется исключительно на метку mpls, по этой метке

он перекладывает содержимое дальше, соответственно, на другой п-роутер. Другой п-роутер анализирует эту метку, перекладывает содержимое дальше. пересылает все это дело по цепочке, и вот так до тех пор, пока это все дело не приходит на последний провайдер Edge роутера, который, в свою очередь, уже обрабатывая обычные IP-пакеты, отправляет этот пакет дальше в сторону кастомера. Вот таким вот образом можно будет добиться того, чтобы у вас вот эти внутренние роутеры, внутри провайдерской сети, они бы целиком и полностью были изолированы от кастомерских пакетов. Они бы вообще не видели вот эти эти маршруты 1001, 1002, 1002, 1001. У них этого всего бы просто, в принципе, не было. Для того, чтобы обеспечить работу с метками, используется достаточно простой заголовок, 32-битный, в котором будет 20-битная метка, то есть это просто число 20-битное, от 0 до 16 миллионов,

нет, не 16 миллионов, 16 миллионов и 24 степени. Да, 16 миллионов, да, простите, 16 миллионов, 777 тысяч, 216, ну вот так. И, соответственно, дальше у нас идет 3 битика, поле, которое называется Traffic Class. До 2009 года это поле официально называлось эксп, типа экспериментальное поле, которое непонятно зачем нужно, и каждый волен его якобы использовать по своему желанию. С 2009 года это поле официально переименовано и называется Traffic Class. Вы туда можете записать 3 битика. Эти 3 битика могут использоваться как либо как IP precedence, либо как Class of Service, то есть как хотите, так используйте. Иногда можно использовать эти 3 битика, как 1 битик указывает на приоритет, 2 битик указывает на управление перегрузкой. То есть там разные механизмы есть, но главное, что вот в эти 3 битика можно вписать какие-то вот разные значения и использовать их для Quality of Service.

Затем, если вы хотите, вы можете навесить несколько меток. Вот, например, здесь на рисунке нарисовано, как будто мы навешали всего одну метку. Каждый раз, когда мы передаем содержимое MPLS соседнему роутеру, у нас вот здесь вот фигурирует только одна метка MPLS. Но, в принципе, этих меток может быть много. Может быть одна метка, может быть две метки. Вот, например, здесь заголовок, не заголовок, содержимое плюс метки указано как раз, когда меток 2. Их может быть больше, может быть 3, может быть 4. То есть в определенных ситуациях можно встретить и 3, и 4 метки действительно. Чаще всего их будет в районе как раз 2. Ну, и дальше все это дело отправляется на канальном уровне, например, в Ethernet в сторону получателя. Так вот, если мы говорим про то, что у нас всего одна метка, эта метка будет находиться ближе всего к оригинальному вложению. То есть она находится вплотную к началу заголовка IP-пакета

в нашем случае. В этом случае этот битик, вот этот вот, один битик, или вот этот вот один битик, одно и то же, он будет выставляться в единичку. Типа метка, которая находится в самой последней в стеке. Если там всего одна метка, то она же самая первая, она же самая последняя в bottom of stack. Если у вас есть несколько меток, то у одной, самой близкой к оригинальному заголовке метка, здесь будет проставлена единичка. У всех остальных, если тут несколько меток, то, соответственно, стоят нолики. Делается это специально для того, чтобы транзитный роутер, понимая, что на каком-то интерфейсе его ждут кадры, приходящие с белыми заголовками, понимал, если он обрабатывает какую-то метку, есть ли там еще дополнительные метки, или их уже нету, или дальше уже начинается само мясо. Ему это будет достаточно важно, и для этого как раз вот признак bottom of stack у него и используется. То есть по содержимому не всегда можно догадаться, что там метка есть или ее нет. Дальше.

Последнее поле, которое здесь есть, это поле TOTEL. Оно указывает на то же самое, что в IPv4 мы привыкли использовать в TOTEL. Это каждый раз, когда мы пропускаем пакет через роутер, через маршрутизацию, у нас из этого поля вычитается копеечка. То есть если вы кладете в MPLS чего-нибудь и отправляете это дальше на MPLS-ную сеть, то вы проставляете там некое значение TOTEL, и дальше копеечка вычитается, вычитается, вычитается, вычитается. Если TOTEL обнулился у MPLS-ной метки, то, соответственно, эта MPLS-ная метка считается протухшей, и содержимое ее выбрасывается. Может быть в этом случае роутер, который встретил такой протухший кадр, такое протухшее содержимое, он как-то отреагирует на это, может быть, не отреагирует, то есть там уже начинаются нюансы. Если мы говорим именно про вложение IP в MPLS, то при входе в MPLS-ную сеть IngressRouter должен будет проставить поле TOTEL в наружной метке,

равное TOTEL-ю самого пакета. То есть приходит пакет, у него там TOTEL, не знаю, 17. В этом случае вот здесь вот 17-е IP-вложение, оно уже никоим образом меняться не будет, но в MPLS-ной метке, соответственно, здесь будет проставлено сначала 16, потом 15, и потом IngressRouter, который снимает последнюю метку, он восстанавливает значение IP-TTL в пакете, делает так, чтобы, соответственно, у нас здесь вот это вот число, простите, оно бы фактически восстанавливалось, как будто бы никакого MPLS-а у нас нет. То есть в какой-то момент вот этот вот роутер, который снимает MPLS-ную метку, он заменит число 17 на 15 или на 14. Это поведение можно по-разному настраивать, то есть есть роутер, который такое делает, есть роутер, который такое не делает, то есть там немножко бардак в этом смысле, но и в любом случае с MPLS-ом, с TTL-ем там есть свои нюансы, которые имеют смысл,

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

пакет с MPLS-ной меткой, он должен был бы принять MPLS-ную метку, прочитать ее, понять, что с ней делать, увидеть, что этот пакет адресован в сторону кастомерского роутера, дальше снять эту метку и проанализировать то, что там внутри IP-вложения есть. И дальше он бы сказал, ага, внутри вот этого вот IP-вложения надо дальше промаршрутизировать по правилам IP. Поэтому он сначала бы проанализировал MPLS-ную метку, а потом бы проанализировал IP-шную метку, IP-шный заголовок. Это двойная работа. Для того, чтобы ему не делать половину этой работы, MPLS-ную метку ему предварительно срезают. Когда предпоследний роутер отправляет в сторону последнего роутера какой-то пакет, который только что прокоммутировался с помощью заголовка MPLS-а, предпоследний роутер срезает последнюю метку и отправляется в содержимое последнего роутера уже без метки. Последний роутер получает просто IP-пакет и дальше его обрабатывает по правилам просто обычной IP-маршрутизации. Эта штука называется PHP.

Penultimate предпоследний hop-popping. Предпоследний роутер снимает метку, чтобы последний роутер не делал работу дважды. В MPLS у нас будет использоваться определенная терминология. Эту терминологию надо будет запомнить, и на экзамене она будет встречаться, в реальной жизни постоянно тоже встречается. LSP, Label Switch Path. Это фактически трасса пакета, к которой будет идти некий пакет. То есть, если у нас есть IP-пакет, он идет здесь вот на кастомерском роутере, перекладывается в сторону провайдерского по IP-правилам. Дальше провайдер Edge у нас роутер будет принимать IP-пакет и дальше разворачивает его в туннель MPLS. Вот этот вот туннель MPLS он строится раз, два, три, четыре, три роутера друг на друга смотрят по MPLS. И, соответственно, LSP — это как раз вот эта вот часть туннеля, которая будет соответствовать по ходу IP-пакета через LSP.

Ну или не IP-пакета. Здесь еще один, кстати, термин отсутствует. FEC. Форму на этой эквивалентной класс. Про него отдельно сейчас расскажу. В общем, у нас IP-пакет, который приходит на наш провайдерский роутер, он заворачивается в MPLS-ную трубу. Вот эта MPLS-ная труба и называется LSP. Это последовательность роутеров и последовательность меток, которые пакет будет проходить при прохождении трафика через сеть MPLS. В нашем случае LSP будет состоять из прохода через PE-пешный, PE-пешный, PE-пешный роутер и метки, которые здесь будут. Вот здесь метка будет, вот здесь метка будет, вот здесь там. Может быть, будет метка, может быть, не будет. В принципе, можно будет сказать, что когда у нас работает PHP, то метка тоже есть, просто она такая прозрачная, невидимая. Еще иногда называют ее implicit null. Но про это будем дальше. Каждый роутер, который выполняет работу с MPLS-ом, так или иначе, будет называться словом PLS-R, label switch router. Это роутер, который вбрасывает трафик в MPLS,

который forwarded трафик в MPLS-у, который принимает трафик в MPLS-у и дальше отправляет его в сторону кастомера. При этом первый роутер в цепочке будет называться ingress PLS-R, то есть тот роутер, который входит как бы в label switch path. И выходной роутер будет называться ingress LS-R. Это будет роутер, на котором туннель заканчивается, дальше на туннеле трафик выходит и направляется по цепочке в сторону кастомера. Оба эти роутера вместе называются edge LS-R, то есть первый и последний роутер на концах туннеля. Термин fec будет означать forwarding equivalency class. Forwarding equivalency class. На самом деле там дальше на следующем слайде есть. Equivalency class. Это набор IP-пакетов или набор просто пакетов, произвольных пакетных данных, которые следует обрабатывать одним образом. То есть мы строим LSP для некоторого набора пакетных данных,

которые пойдут по этому самому LSP. Ну или, хотите, называйте это туннель. Построили туннель, дальше в этот туннель мы собираемся запихивать пакетные данные одной и той же природы и одного и того же назначения. То есть они должны пойти по одной и той же трассе. Вот совокупность таких пакетов мы будем называть словом fec. Можно будет сказать, что в нашем случае, например, если мы строим MPLS для обработки только чисто исключительно IPV4 трафика, и мы используем какие-то такие стандартные протоколы типа LDP, то в этом случае fec будет, например, IPV4 префикс. Мы говорим, что у нас совокупность пакетов, которые будут отправляться по туннелю, будет соответствовать некоторому префиксу. То есть если у нас есть пакеты, которые идут на одни и те же IPV4 адреса назначения, ну, например, у них IP-адреса назначения будут 10, 1, 1, 0, 24, то вот fec будет вот этот префикс. Так, как будут работать роутеры,

которые выполняют коммутацию на основе меток? У нас есть наш туннель, который мы построили. Вот он, это LSP. Дальше. Входящий роутер получает какой-то пакет. Этот пакет на рисунке нарисован IP-шный, он может быть IPV4, может быть IPV6, может быть произвольной природы. То есть никто не мешает вам взять и сказать, давайте отель в ячейки засунуть в MPLS. Никаких проблем нету, в MPLS можно засунуть все, что угодно. Есть такой стандарт, который называется ATOM. Вот, маленькая буковка O. И они транспорт over MPLS. То есть в MPLS засунуется все, что угодно. В нашем случае у нас простая ситуация. Мы засунуем в MPLS IPV4 пакеты. Входящий роутер принимает IPV4 пакет, понимает, что этот пакет адресован в MPLS-ный туннель и навешивает некоторую метку. Дальше. Следующий роутер в цепочке принимает такой пакет с MPLS-ной меткой, перекладывает его по некоторому правилу дальше,

но при этом заменяет метку. У него есть табличка, в которой написано, что принимаем с одной стороны, с какими метками, и куда выплевываем, с какими метками исходящими. Метки по дороге могут меняться. Это нормально. То есть нигде не написано, что эти метки обязаны сохраняться. Здесь на картинке нарисованы похожие. На самом деле никто вам не решает сказать, что здесь метка будет, не знаю, 1.7.3, а здесь 3.5.9. Они могут меняться. Чаще всего меняются. Дальше. В нашем случае вот этот вот pair-оутер принимает MPLS-ный пакет с меткой 359 и говорит, я должен передать по цепочке в сторону PE-шного роутера вот этого вот. Этот роутер будет называться egress-роутер. Ну и, соответственно, предпоследний роутер будет выполнять penalty made-hop-popping, и в этом случае он ставит пустую метку. То есть здесь вот у нас ничего нет. Это как будто пустая метка implicit nu, которая идет в сторону PE-шного роутера. PE-шный роутер не видит эту полупрозрачную метку. Он получает просто обычный IP-пакет, и forward по правилам IP-пакета.

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

Если у нас есть указание, что мы предпоследний роутер в цепочке, то есть следующий роутер в цепочке будет aggressive router, то в этом случае мы меняем метку на пустую. То есть фактически мы ту метку, которая нам приходила, снимаем, и вот этот термин, снимаем метку, отправляем дальше, кадр уже без метки, будет называться термин pop. То есть swap метки, это взяли, поменяли метку на другую, pop это поменяли метку на прозрачную. Для того, чтобы все работало, вам нужно будет таблицу, что меняем на что меняем, каким-то образом пополнить. Есть протоколы, которые это делают вполне себе неплохо. Мы с вами будем в рамках курса изучать протокол LDP, который очень популярный, который используется для построения транспорта MPLS, и в принципе очень неплохой для этого, то есть он хорошо с этим справляется, и в большинстве, особенно небольших провайдеров, используется именно он. Но в принципе таблицу меток можно пополнять и другими протоколами, в частности, если вы хотите использовать Traffic Engineering, MPLS-TE,

то у вас будет RSVP пополнять эти самые метки, можно будет заставить BGP пополнять метки, то есть для определенных задач BGP действительно будет протаскивать вам наборы меток. LDP – протокол стандартный, этот самый протокол, как уже было сказано, LDP – синхронизирует таблицы меток. Но это не то, что синхронизирует, это не то, что как таблица маршрутизации, у нас все таблицы должны быть одинаковые, если там где-то чего-то нету, то, соответственно, там таблица маршрутизации у нас считается неполноценной. LDP может рассказывать про какие-то метки, которые в MPLS будут интересны. Метки назначаются на FEC, на Forwarding Evalence Class. Мы можем считать, что FEC в нашем случае – это просто IP маршруты, то есть, например, у нас есть какой-то вот роутер, он рассказал про какую-то сеть, которая у него присутствует, дальше все роутеры, зная, что определенная сеть присутствует,

начинают рассказывать, какие метки они хотят использовать для этой сети. Это не протокол динамической маршрутизации. То есть важно то, что LDP не является заменой OSPF, заменой SAS, заменой RIP. То есть это не протокол, который рассказывает про маршруты. Это протокол, который рассказывает про метки на маршруты, которые должны в таблице маршрутизации откуда-то появиться. Поэтому отдельно у вас работает процедура пополнения таблицы маршрутизации, она обязательная. После того, как вы пополнили таблицу маршрутизации, LDP может рассказать, какие метки для этих паршютов нужно будет использовать. Исторически это все дело придумано CISC-ой. Как водится, у нас многие технологии придуманы изначально CISC-ой, потом они были стандартизированы. Изначально эта штука называлась Tag Distribution Protocol, был фирменный CISC-ский протокол, потом его CISC-а релизнула и запилила в RFC. Ну и переименовала. LDP стал называться, Label Distribution Protocol. Работает LDP следующим образом. Он будет сначала обнаруживать соседей автоматически по UDP.

Он будет использовать Multicast на адрес Routra 224.002 по UDP на 646-ой порт. То есть он обнаруживает соседей, устанавливает с ними соседские отношения, отправляет им Hello-пакеты, поддерживает связь в актуальном состоянии. Дальше он по TCP. На этих соседей ставит TCP-шную сессию и по TCP-шной сессии уже передает все метки, которые ему хочется передавать. То есть лайфхак. Вы не можете надеяться на то, что TCP у вас обязательно уведомит о том, что сосед сдох, но вы можете использовать одновременно и TCP, и UDP для работы в рамках одного конкретного протокола. TCP поддерживает надежную передачу данных, а UDP поддерживает соседство сессию в актуальном состоянии. Для того, чтобы TCP работал IP-шник соседа, мы должны знать. Но вот мы мультикастом нащупываем адреса соседей, и после того, как убеждаемся, что сосед есть, по TCP начинаем на него выгружать все наши метки. LDP работает так, что он означает на каждый IP,

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

То есть у них в таблице маршрутизации есть маршруты. Роутер, допустим, вот этот вот, сказал, у меня в таблице маршрутизации есть маршрут, я рассказываю всем своим соседям, что если вдруг вы по этому маршруту будете посылать трафик именно мне, пожалуйста, заворачивайте его в MPLS на метку 793. Точно так же делают все роутеры. И все присланные соседями метки, даже если вы не собираетесь им пользоваться, вы все равно храните его в памяти своего LDP. Вот у нас есть роутер, он породил какую-то сеть. Вот у нас сеть зародилась. Дальше начинает работать протокол, который уведомит всех соседей про то, что такая сеть существует. То есть отдельно у нас работает протокол динамической маршрутизации, и отдельно у нас работает MPLS. Вот у нас SPF начинает, не знаю, к примеру, SPF, может BGP, может что угодно. Реплицируется таблица маршрутизации, и все роутеры начинают знать про то, что такая сеть существует. Дальше. После того, как все роутеры узнали, что такая сеть существует,

начинает работать LDP. Он у всех примерно одновременно просыпается и говорит, о, у нас тут плевая сетка нарисовалась в таблице маршрутизации. Давайте каждый из нас придумает совершенно произвольную метку, назначит ее для сети X, которая есть у нас в таблице маршрутизации, и расскажет своим соседям, что если вдруг вы хотите посылать трафик для сети X в сторону меня, почему-то вы хотите это сделать, используйте, пожалуйста, вот такую-то метку. Каждая из них придумывает метку абсолютно независимо от соседей. То есть это какое-то случайное число. Один придумал метку 900, другой придумал метку 1000, третий придумал метку 1001. Это все трафик до одной и той же сети, просто до разных хостов. И дальше начинают рассказывать соседям. Все дружно одновременно начинают рассказывать друг другу, если ты посылаешь трафик мне, посылай трафик с такой меткой до этой сети. Все роутеры хранят информацию обо всех метках, которые они получают от всех соседей. Дальше. Смотрите, какая магия происходит. Каждый роутер смотрит, чего там в таблице маршрутизации написано.

Если в таблице маршрутизации написано, что, например, вот на этом вот роутере трафик до сети X надо посылать вон туда, то мы смотрим, какой next hop у нас в таблице маршрутизации есть. Принимаем решение, что next hop в таблице маршрутизации у нас роутер P. Это OSPF отработал, к примеру. И дальше говорим, если роутер P сказал, что трафик в сторону сети X надо посылать с меткой вот этой вот синенькой, то мы все будем помечать синенькой меткой. То же самое делает роутер P. Он говорит, чего дальше у меня говорит на OSPF делать? У меня next hop по OSPF это вот этот вот роутер. Соответственно, он мне рассказал, как надо в его сторону до этой сети трафик посылать. Рассказал, он говорит, заворачивай мне трафик в зеленую метку. Поэтому если вот этот роутер P будет посылать трафик в сторону другого, он будет посылать трафик уже оборачивая зеленой меткой. Поэтому он будет получать трафик с синей меткой и отправлять дальше в другой интерфейс с зеленой. То же самое будет происходить на вот этомся роутере. Он знает, что этот роутер попросил его использовать оранжевую метку.

Он говорит, next hop у меня как раз тот, который попросил использовать оранжевую метку. Я буду использовать оранжевую метку на этом интерфейсе. Выходной интерфейс выбирается с помощью таблицы маршрутизации, а метка выбирается с помощью того, что вы копаетесь в списке всех-всех-всех анонсов по LDP, которые вам прислали все соседи, и выбираете ровно тот анонс, который пришел от NextHob на заказанную вами сеть. Ну и получается, что трафик у нас начинает ходить вот таким вот образом. Приходит IP-пакет, дальше каждый роутер выбирает, какой NextHob у нас используется, какую метку он попросил использовать и отправляет трафик дальше с указанной меткой. Обратите внимание на то, что я вот здесь вам говорил, что должен по идее работать PHP, и фактически в этом случае вот этот вот самый последний роутер, он говорит, я придумал метку, которую мне надо использовать, но, ребята, имейте в виду, что я последний игре с роутером, поэтому я должен буду обрабатывать пакеты по их нативному IP-шному заголовку, поэтому, пожалуйста, я вам по LDP прошу,

если вы будете посылать мне трафик до этой сети, используйте, пожалуйста, в явном виде прозрачную метку. То есть он по LDP говорит, не надо мне посылать трафик с метками. Можно встретить другую ситуацию, когда вам кто-то вообще ничего не говорит. В этом случае вы тоже трафик будете не помечать ничем, потому что вы принимаете трафик и дальше отправляете его без метки. Но вот есть implicit null, а есть просто отсутствие метки как таковой. Вот в нашем случае последний роутер в цепочке для того, чтобы работал PHP, сказал, посылайте мне, пожалуйста, пустую метку. И вот здесь вот, вот эта вот оранжевая метка, она на самом деле будет пустой, прозрачной. В нашем случае, да, вот так вот как-то вот это и будет работать. Изначально профит от работы вот такого механизма был в том, что коммутация у вас выполнялась по меткам. Потому что одно дело, когда вы на вот этом вот роутере принимаете IP-пакет, смотрите, какой IP-адрес у него в качестве получателя, находите NextHop, смотрите, где доступен NextHop, рекурсивный его резолвите.

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

то она катастрофически по сравнению с оригинальной, нативной, чистой маршрутизацией ускоряет работу. Изначально эта штука придумана была как ускорение работы. То есть даже если вы используете тысячу маршрутов, 10 тысяч маршрутов таблицы маршрутизации, все равно это на самом деле работу ускоряло очень сильно, потому что нативная маршрутизация на 10 тысяч маршрутах и MPLS на 10 тысяч маршрутах – это была очень и очень большая разница по скорости. Сегодня скорости нет. Сегодня скорость заключается в том, что вы, если используете чистую маршрутизацию, вы включаете ЦЭФ условный, ну или аналогичные технологии от других вендоров. И они по скорости абсолютно совпадают с MPLS. То есть там то же самое фактически работает. Мы смотрим на то, что с одной стороны прибежало, по какому-то очень простому критерию оцениваем, оно не оно, и дальше у нас уже готовые указания, куда это девать и какой заголовок проставить. Поэтому классический MPLS для классической маршрутизации очень сильно ускорял работу. Современный MPLS и современный ЦЭФ

вообще никаким образом работу не ускоряет. Но в MPLS можно навешивать не одну метку, а несколько. И иметь таким образом Traffic Engineering, и иметь таким образом VPN. И для сегодняшних сетей, в сегодняшнем применении, используется MPLS именно для того, чтобы у вас работали вот эти вот всякие вкусняшки. Вкусняшки Traffic Engineering, вкусняшки VPN, вкусняшка изоляция трафика на уровне таблиц маршрутизации. Если вы используете MPLS, у вас на вот этих вот роутерах вообще маршрутов нету, на которые бы стоило им посмотреть. То есть вы можете не показывать в вашу сеть ядра кастомерские маршруты, если вы используете MPLS. Это тоже очень на самом деле серьезное преимущество. То есть вот здесь вот у вас не нужно смотреть на вот эти заголовки, если вы используете MPLS. Представьте себе, что вы провайдер современный, и у вас есть как минимум картинка интернета, там 800 тысяч маршрутов. Помимо того, что есть картинка интернета, у вас есть, ну не знаю, мы как Ростелеком,

у вас клиентов, ну скажем, миллион. Каждый из миллиона клиентов вам присылает свои маршруты до своих частных сеточек, а кое-каку даже и до публичных. И вам надо не смешивать их между собой. И у вас из миллиона клиентов, ну например, 100 тысяч маршрутов до сети в по 2, 168, 0, 0, по 24 маске. И вот вам надо не спутать их. Вам надо сделать так, чтобы трафик на вот этих вот роутерах до этих клиентов ходил, причем чтобы это все действительно происходило обособленно и независимо. И делать 100 тысяч или там миллион субинтерфейсов с VRF Lite было бы очень тяжело. А так вы просто на каждый клиентский поток данных делаете свой отдельный туннель, делаете свои отдельные метки, и они у вас будут видеть вот эти транзитные роутеры только MPLS-метки. MPLS-метки обрабатываются очень легко, их может храниться довольно много. Главное, что там у нас в принципе не может случиться такого, что кадр из одного туннеля LSP попадет в другой туннель LSP.

То есть трафик разных клиентов у нас в принципе не может при этом перемешаться. Так что да, VPN-ы, изоляция своей сети ядра, трафик инжиниринг — это вот основные задачи, почему сегодня MPLS все используют. Еще раз подчеркну, как работает LDP. Он назначает метки локально, то есть вы придумываете в начале работы на все маршруты, которые у вас есть, таблицы маршрутизации, для которых LDP должен работать, метки, и анонсируете эти метки соседям. Вы говорите нам, дорогой сосед, если ты хочешь отправить трафик мне до сети 10.00, используй метку номер 177. Вы эту метку сами только что придумали. Может быть, своим соседям вы рассказали одну и ту же метку. Может быть, вы на одного соседа сказали, используй метку 177, на другого соседа метку 188. Но главное, чтобы у вас не получилось так, что на одном и том же интерфейсе у вас трафик до одной и той же сети ходил бы,

трафик с одними и тем же метками ходил бы до разных сетей. То есть если у вас, например, вот что-то вот такого плана, два роутера через свитч, вы не будете говорить одному, что, пожалуйста, используй 177-ю метку для одной сети, а другому 177-ю метку для другой сети. То есть вы можете сказать, что если ты хочешь отправлять трафик до сети X, здесь используй метку 177, а здесь используй метку 178, так оно покатит. Вы в любом случае скажете, что все, что пришло со 177-ю, мы направляем туда, и со 188-ю тоже направляем туда. Либо вы можете сказать, что вот я на этом интерфейсе придумал 177-ю метку, и вы всем рассказываете, что используете 177-ю метку. Это куда более частая штука. Но вы не можете сказать, что если ты хочешь отправлять трафик до сети X, используй 177-ю метку здесь, и трафик до сети Y, используй 177-ю метку здесь. Тогда вы не сможете отличить трафик одного клиента от другого. У вас эти метки спутаются. Ну, в общем, логично, да? Вот. Дальше вы рассказываете соседям,

чего надо использовать, какие метки надо использовать, для какого фека. Либо вы можете сказать, присылай мне трафик помеченной меткой, либо вы можете сказать, не присылай мне трафик размеченной, потому что я последний роутер в цепочке. В этом случае вы посылаете implicit, ну, пустую метку. Вы говорите, я хочу получить трафик без метки. Либо вы можете не прислать ничего, то есть если у вас LDP, например, не запущен или что-то еще случилось, вы в этом случае не присылаете ничего, и трафик для вас не маркируется по MPLS. Опять же. Все вот эти вот указания, какие пакеты надо будет помечать, какие метками хранятся в базе всех пользователей, и дальше выбираются из этих полученных анонсов те метки, которые присланы от NextHop. То есть если у нас есть, давайте вернусь на предыдущий слайд, если у нас есть, например, вот этот вот роутер, он получает указание по SPF,

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

анонсировали по LDP соседу, сосед пометил в таблице маршруризации вас как NextHop и взял вашу придуманную вами метку, для того, чтобы трафик, помеченный этой меткой, направлять в вашу сторону по MPLS. AgressLabel, выходящая метка, это метка, которую вам прислал ваш NextHop, он ее придумал, он ее вам анонсировал, сказал, если ты хочешь посылать мне трафик до CTX, посылай его с вот такой меткой, и вы в соответствии с его пожеланиями себя ведете, отправляете ему трафик с этой меткой. Так, да, по поводу того, для чего сегодня используется MPLS, вот здесь простенький сценарий с двумя услугами L2VPN и L3VPN. Если вы хотите использовать услугу L3VPN, то вы прикидываетесь одним большим мегароутером, то есть вот это вот, это такой один большой мегароутер. Клиент дружит с вашими Edge ЛСРами по протоколу динамической маршрутизации,

то есть вот здесь у нас есть клиент, он говорит, я знаю 7100, посылай трафик до меня, до этой сети 10000-8. И вот здесь тоже у нас происходит. Посылаем мне трафик до 122-168-10-24. Маршруты у нас разбегаются по этой сети, BGP дальше отвечает за то, чтобы не смешать маршруты между собой. На вот этих вот роутерах у нас есть понимание, что есть маршрут вот этот вот, соответственно, в сторону MPLS-ного туннеля. И дальше BGP назначает метки. BGP говорит, для того, чтобы обрабатывать трафик вот этого голубого клиента надо помечать весь трафик, который входит вот в этот вот туннель, специальной голубой меткой. И у нас все IP-пакеты, которые отправляются в сторону вот этого вот выходного ЛСРа, они помечаются голубой меткой. Это просто обычная метка, и назначается она по BGP чаще всего. Дополнительно к тому мы говорим,

что вот этот вот LSP, который строится между двумя входящими и выходящими ЛСРом, Ingress и LKVS, там у нас тоже работает MPLS, и, соответственно, нам нужно будет еще транспортную метку точно так же делать. Вот этот вот следующий роутер в цепочке, как в NextHop для определенного forwarding performance-класс, сказал, присылай трафик мне, помечай мне его синей меткой. Поэтому мы назначаем и голубую метку для указания VRF, и синюю транспортную метку для указания того, кто следующий в цепочке, то есть как нам быстро проформировать такой трафик. Этот роутер говорит, все, что пришло ко мне с синей меткой, я перекладываю дальше с розовой меткой, потому что меня об этом попросил следующий роутер в цепочке. Следующий роутер в цепочке говорит, все, что пришло ко мне с розовой меткой, я перекладываю дальше, но следующий роутер попросил меня поставить прозрачную метку, сделать или implicit null, Поэтому я следующий кадр отправляю без дополнительных меток. То есть я просто то, что ко мне пришло, наружную метку срезаю, а все, что внутри, какое-то содержимое, я в него не обращаю внимания,

я его прям дальше без изменения отсылаю в сторону выходного роутера. Выходной роутер получает IP-пакет с указанием VRF. Это указание — это просто обычная голубая метка, обычная метка MPLS. Там у нее какое-то число, не знаю, 911. Вот вы прочитали это число, говорите, а, так это тот самый голубой клиент. И говорите, окей, содержимое мы отправляем по таблице VRF, голубого, в сторону клиента вот этого роутера. Если у нас есть какой-то другой роутер, другого клиента, который, может быть, точно такую же сетку прислал, 112.168.1.0.24, то есть точно такой же, как здесь, только другой. Опять у нас BGP ставят сессию, опять говорит, у нас есть рыжий клиент. Мы отправляем метку, что если ты хочешь отправлять трафик в VRF рыжего клиента, маркируй его, пожалуйста, числом 123. У нас маркируется исходящий IP-пакет с числом 123, как VRF-ная метка. И поскольку все это дело дальше должно уйти на тот же самый

Egress роутер, точно так же, как в предыдущем случае, снаружи навешивается синяя метка. Как мы уже знаем, если что-то приходит от левого роутера с синей меткой, оно перекладывается дальше с розовой меткой. То же самое здесь. Как только мы принимаем что-то слева с розовой меткой, мы перекладываем это дальше с implicit node, с пустой меткой. То есть здесь вот эти вот правила транспорта, они точно такие же для всех клиентов, для всех VRF. И выходной роутер видит, что приходит трафик с рыжей меткой. Он говорит, это рыжая метка назначена для того, чтобы показать, что трафик относится к клиенту рыжему VRF, и трафик направляется по таблице маршрутизации между VRF. То есть вот такая вот штуковина, она работает и, в принципе, неплохо себе работает. Можно будет ориентироваться, на самом деле, на эту схему и для маршрутизации, ну, для бриджинга кадров. То есть если у вас есть какие-то кадры из Эрнета, которые вы получаете с одной стороны, вы их можете бриджить

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

Эта штука называется L2VPN. Конкретно это L2VPN, который я вам сейчас показал, с псевдопроводом, это E-Line, в терминологии NetResort Network Forum. На самом деле что-то очень похожее, я вам уже рассказывал на этом курсе, и я вам говорил, что FrameRelay стал основой для Эрнета. Во FrameRelay у нас как это все дело выглядело, что есть интерфейс, есть интерфейс, интерфейс, и вот там у нас DLCI-ки были. Эти DLCI-ки могут меняться. И мы купили PVC-шку между роутером первым и вторым, и, соответственно, вот у нас указание, что если мы хотим отправить с роутера R1 трафик на R2, мы должны указывать DLCI-ку 912. На транзитном роутере у нас есть указание, что все, что пришло с 912 DLCI-кой, надо отправить в сторону, в сторону, в сторону, в сторону, в сторону, на роутера R2. Ну, кастомер, да. То же самое и в другой PVC-шке.

Если мы хотим с роутера R1 отправить трафик на R3, мы должны указывать другую DLCI-ку, там, 913-ю. Эти обе DLCI-ки придумал роутер R9, если вы хотите, да, то есть они прописаны на роутере R9. И на R9 прописаны правила коммутации. Что если что-то приходит с 912, перекладываем вот такой интерфейс в 212. Если что-то приходит с 913, перекладываем в 313. При этом трафик, который идет туда, и трафик, который идет обратно. Это два разных потока трафика, и, соответственно, нам нужны правила коммутации туда и правила коммутации обратно. Ну, соответственно, да. что можно сделать так, что трафик, который идет туда и трафик пройдет обратно, они коммутируются по-разному. В MPLS все то же самое. Обратите внимание на то, что таблицы здесь одинаковые. Вот эта вот часть и вот эта вот часть — это все одно и то же. Здесь одинаковые цифры. Если у нас есть четыре роутера, которые должны отправлять друг другу MPLS-ные пакеты, мы отправляем пакет по трассе от роутера R1 до роутера R3,

маркируем его 912 меткой. Здесь у нас идет указание, что все, что пришло отсюда с 912 меткой, мы отправляем с указанием в 212 метки дальше по одному интерфейсу. 913 метка пришла на том же самом интерфейсе. Мы его отправляем по другой трассе. То есть MPLS фактически здесь целиком полностью заимствовала эту идею, развила эту идею, и на транспортном уровне идея MPLS полностью повторяется в Frame Relay. Вопрос только в том, как назначаются эти вот метки, потому что во Frame Relay они фактически руками назначались. В MPLS у нас есть автоматический механизм их назначения. И в MPLS мы можем делать несколько меток, благодаря чему получать услуги MPLS-MPN, благодаря чему получать трафик-инженеринг. На этом все. Теорию, которую я хотел рассказать, я вам рассказал. Дальше нам нужно будет приступать к практике. Спасибо. Спасибо. Спасибо.