В мире сетевых технологий есть одно слово, без которого никакой Интернет невозможен — это маршрутизация.

По сути, маршрутизация - это поиск пути до некоторой точки назначения.

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

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

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

Однако даже при такой вроде бы понятной и гармоничной организации возникает опасность, знакомая любому путешественнику. Вы ее наверняка испытывали на себе, когда пытались найти человека или место в незнакомой местности. И даже если вы знаете дорогу - все равно есть шанс заблудиться. В сети такое тоже случается. Давайте попробую проиллюстрировать.
Жил в деревне плотник Иван. Пришел к нему как-то раз сосед Петр и говорит:
- Представляешь! Кузнец то перебрался на новое место! Теперь до него через мой двор можно напрямки добраться!
- Окак! Обязательно всем об этом расскажу, ответил Иван.
С тех пор стал он направлять всех, кто спросит его за кузнеца - к Петру. Но вот беда, Петр занятой и к тому же забывчивый. Вылетело у него из головы как до кузнеца добраться...
- Да не знаю я! У Ивана переспросите, не к тому он вас отправил! - отвечал Петр, уставший пуще прежнего от наплыва желающих найти кузнеца.
Получился замкнутый круг — Иван направляет к Петру, а Петр обратно к Ивану, пока терпение у людей не кончится. Все это время деревенские сидят без гвоздей и подков, а кузнец без работы.
Эта напасть в мире сетей называетяс маршрутизационная петля — когда маршрут как бы «замыкается», и пакеты данных начинают ходить по кругу, так и не доходя до нужного адреса.
Петли — серьёзная проблема, способная привести к катастрофическим сбоям. Поэтому протоколы маршрутизации снабжают защитой от петель. В диком Интернете без этого никак.
Еще до активного роста Интернета под это готовился фундамент.
Предлагалось разделить сеть на автономные системы — как города с собственными правилами и контролем. Внутри одной автономной системы (любой провайдет интернета, например) всё работает по своим законам. Но «города» должны общаться, иначе данные не дойдут из одного угла Интернета в другой.
Для общения между «городами» был разработан протокол EGP (Exterior Gateway Protocol) — один из первых протоколов, специально предназначенных для так называемой “внешней” маршрутизации.
EGP хоть и справлялся со своей задачей, но имел жёсткое ограничение: он работал по принципу дерева.
Существовал один центральный узел - корень, который рассылал всю актуальную маршрутную информацию. Если одна “ветка” ломалась — часть сети оказывалась в изоляции.
Очень скоро выяснилось, что Интернет не мог себе позволить централизованного управления и количество узлов и соответственно маршрутной информации, становилось все больше.

К концу 1980-х сетевики буквально «по уши» стояли в болоте нерешённых задач. Всё чаще казалось, что Интернет вот-вот развалится.
Нужно было что-то решать.
Весной 1989 года в Остине на 12-й конференции IETF собрались самые светлые умы мира сетей, обсудить проблемы и предложить возможные решения.
С угрозой системного коллапса на горизонте, двое инженеров, Яков Ректер из IBM и Кирк Лоухид из тогда еще молодого стартапа CISCO начали наспех чертить идеи решения на обороте салфетки, испачканной кетчупом.
Результатом обеда, наверно самого продуктивного за всю историю, стал черновик протокола с простой идеей: пусть автономные системы обмениваются маршрутами напрямуюи пусть каждая автономка сама решает, кому доверять и куда отправлять трафик.
«протокол двух салфеток», как они в шутку его окрестили, вскоре станет основным средством для решения проблем маршрутизации в Интернете.
Border Gateway Protocol, или просто BGP. Уже спустя несколько месяцев, в июне 1989 года, был опубликован первый официальный документ — RFC 1105, где подробно описывалось, как именно будет работать этот новый протокол.
На момент выхода документа уже имелись первые реализации BGP. Они испытывались на маршрутизаторах Cisco совместно с инженерами компании Merit.
Давайте в общих чертах разберемся, как же он работал.
Буквально все, ради чего мы затеваем такие сложности - это иметь возможность доставить видео с котиками в любую точку мира, где есть Интернет!

А теперь вспоминаем нашу аналогию с городами. У нас есть города и дороги между ними — при этом внутри каждый город со своими улицами и правилами.
Города - это наши автономные системы. Автономная система - это уникальное число, прям как названия городов, с ее помощью наш город представляется другим городам.
BGP это автобусная станция нашего города, она оперирует маршрутами или префиксами.
Маршрут — это как указание на конкретную улицу в городе.
Внутри города конечно же все знают, как доставить котиков из точки А до точки Б. Но вот чтобы отправить их в другой город - нужно узнать, какие дороги туда ведут, и через какие города лучше всего проехать, чтобы котики оказались в нужном месте как можно быстрее!
Но просто так в другой город не попасть, если не знаешь дороги. Городам нужно обменяться этими знаниями.
Чтобы начать обмен, нужно наладить стабильную и надёжную связь между городами. Тут на помощь приходит протокол TCP — можно представить его как рейсовый автобус номер 179, который стабильно курсирует между двумя городами, доставляя сообщения без потерь. Градоначальники, которые у каждого города свои, согласовывают правила работы и делают это независимо друг от друга.
Как только такой автобус начинает курсировать - можно начинать обмениваться маршрутами.
И вот что интересно: каждый город, через который проходит маршрут, ставит на него свою печать со своим наименованием — номер автономной системы.
На протяжении всего пути префикс собирает целую цепочку подписей: кто из городов передавал эту дорогу дальше. Эта цепочка называется AS-path — путь автономных систем. У AS-Path важная роль - предотвращение петель маршрутизации.
Получив списки маршрутов от соседей, автобусная станция обязана выбрать из них лучшие, по которым наши котики смогут отправиться туда, где их больше всего ждут.
При этом у каждого города свои критерии: кто-то предпочитает короткие пути, кто-то — надёжные или дешёвые. Это и есть знаменитая гибкость политик маршрутизации в BGP.

В итоге информация о маршрутах обновляется со всего мира — и у каждого города в расписании появляются пути, ведущие практически в любую точку глобальной сети. Такая полная таблица маршрутов даже получила особое имя среди инженеров — Full View.
Так работает BGP: с одной стороны — простые соглашения между соседями, с другой — хитрая математика, способная управлять без преувеличения миллионами маршрутов.
После появления первого рабочего протокола его быстро начали дорабатывать и развивать, чтобы идти в ногу с растущими масштабами и сложностью Интернет-структуры. Вскоре появился BGP версии 2, потом 3, а затем — и 4-я версия, именно она сейчас лежит в основе мировой маршрутизации.
При этом, 4-я версия привнесла новшество, которое определило судьбу Интернета на десятилетия вперед.
С самых первых дней существования интернета распределение адресов было важной административной задачей — всего-то нужно было следить за тем, чтобы две сети случайно не начали использовать один и тот же IP-адрес. Сначала эта задача была совсем простой: вести список выданных адресов. Этим добровольно занимался Джон Постел, который, как гласит легенда, записывал всё в обычный бумажный блокнот.

Спустя еще некоторое время, объём работы стал настолько большим, что он уже не помещался в блокнот доктора Постела. Для этой задачи была создана организация IANA (Internet Assigned Numbers Authority — Администрация по присвоению номеров Автономных систем и распределению адресного пространства в интернете.
В октябре 1992 года IETF опубликовал RFC 1366, где предложил раздробить систему выдачи на регионы. И по сей день остается 5 таких регистраторов, разбросанных по ключевым регионам планеты.
Вся история становления регистраторов конечно же требует отдельного выпуска.
Вернемся в наш инженерный хаос. Пока в сетях царила так называемая классовая адресация, сети выдавались довольно свободно — любая организация, подавшая простой запрос, получала заветный префикс. Но к концу 1980-х, на все том же фоне стремительного роста интернета, начали проявляться две серьёзные проблемы:
- Первая - сама система классовой IP адресации. В ней адресное пространство делилось на три класса - A, B, C. Каждый класс делился на префиксы определенного размера. Прям как если бы в нашем городе все улицы могли быть только длиной 250 метров, 65 километров или длиной с половину экватора.

Основная причина, зачем нужно было что-то менять, - не существовало класса подходящего размера для организаций среднего масштаба. Класс C слишком мал, а класс B — слишком велик и большинству организаций не нужен, а класс А в реальности не был нужен никому.
- Вторая, но не менее важная причина - таблицы маршрутизации становились слишком большими. Программное и аппаратное обеспечение (а также люди, которые всё это настраивают) на момент 1993 года уже не справлялись с управлением.
Еще одной потенциальной проблемой было исчерпание пространства IPv4 адресов, но первые и вторая проблема угрожали стать критичными в ближайшие 3 года, поэтому действовать (снова!) нужно было быстро.
В том же 1993 году было опубликовано решение, новый способ описания сетей - CIDR (Classless Inter-Domain Routing — на русском звучит не менее страшно - бесклассовая междоменная маршрутизация).
Он предлагал отказаться от “классов” и давал больше гибкости. Но для этого нужно было изменить несколько вещей.
1. работу маршрутизаторов и протоколов
2. процесс выдачи и назначения IP-адресов.
В классовом мире маршрутизатор легко мог понять, к какому классу относится IP адрес (A, B или C), а класс однозначно указывал на размер префикса.

С появлением CIDR это стало невозможно — теперь, на примере городов, нужно было точно указывать, где заканчивается “улица” и начинается “дом” в IP-адресе. Эта “граница” называется длинной префикса. К счастью, на тот момент в интернете был всего один широко используемый протокол маршрутизации — BGP, и поддержку CIDR в нем быстро доработали, что стало последним гвоздем в крышку гроба классовой IP адресации.
Уже в 1994 году наблюдалось существенное снижение роста маршрутных записей – протокол перестал быть экспоненциально раздутым, как это было в начале десятилетия.
Вам может показаться, что весь интернет, как будто бы, собран из костылей, которые появляются как ответ на архитектурные ошибки - это так и есть.
А все потому, что прогнозы тех лет сильно отстали от реальности.

Тем не менее, BGP изначально хоть и был таким же костылем, хотя более гуманно его назвать хаком, но он был ДЕЙСТВЕННЫМ хаком, решающим целый спектр проблем здесь и сейчас.
Как заметил Яков Ректер, один из создателей BGP: «Этот протокол сделал возможным Интернет без центра управления. Именно в этом — его главная сила».
Сетевое сообщество встретило BGP достаточно позитивно, хотя и осторожно.
Ситуация с EGP напоминала маршрутку: один маршрут, один водитель, никаких вариантов.
А вот BGP — это как первая личная машина. Да, подвеска жёсткая, тормоза не предел мечтаний и иногда руль уводит в сторону, но кто будет жаловаться, когда наконец ты сам решаешь, куда ехать?

Постепенно BGP доказал свою надёжность. По мере роста Интернет-трафика и добавления новых сетей, BGP удавалось масштабироваться.
Под конец XX века BGP окончательно утвердился как де-факто стандарт внешней маршрутизации. Рост сети от сотен тысяч до сотен миллионов хостов шёл рука об руку с ростом числа записей в таблице BGP. Например, в 1994 году в Интернете насчитывалось около 15000 тысяч маршрутов, а сейчас – их уже больше миллиона!
У таблицы всех маршрутов BGP даже есть свое название - Full View.
BGP проектировался на несколько порядков меньшее число маршрутов, чем мы имеем сегодня, но до сих пор успешно справляется с их обработкой.
Но есть увесистая ложка дегтя в этой бочке меда. BGP – протокол сложный, требующий внимательной и точной настройки. Выпуск был бы не полным, если не поведать про истории, как с помощью BGP можно отправить в небытие половину глобального интернета.
Оригинал описания проблемы даже не требует пересказа, я вам его просто зачитаю.

1997 год. Самый обычный день. Интернет — только начинавший развиваться по сравнению с современными стандартами. Операторы сетей (в основном!) доверяли друг другу. Люди беспокоились, что закончится IP-пространство. Операторы сетей волновались, что процессорные мощности их маршрутизаторов перегружаются обработкой полной таблицы маршрутизации — около 45 000 записей.
И вдруг, Интернета не стало. Провайдеры по всему миру бросились на поиски причины проблемы. И нашли. Весь Интернет 1997-го года сосредоточился в одной точке — на хиленьком маршрутизаторе Bay Networks в AS 7007.
Причина проблемы была устранена быстро — сошедший с ума маршрутизатор отключили от сети. Но это не решило собственно проблему — маршрутизаторы по всему Интернету продолжали выходить из строя.
Кто посылал анонсы? Как можно было остановить это безумие? Неужели Интернету, склееному изолентой, пришёл конец?
Через несколько часов всё улеглось, а Сетевые Операторы всей планеты собрались для обсуждания последствия этой аварии и каким образом её можно было предотвратить. Это был момент, когда Интернет изменился навсегда. Но, в отличие от многих других изменений, это прошло незамеченным для большинства обычных пользователей.
А вот более заметный для простого обывателя случай. 24 февраля 2008 года правительство Пакистана решило заблокировать YouTube. Провайдер Pakistan Telecom начал анонсировать сети видеосервиса с более специфичной длиной префикса, /24 вместо /22. Это как почтовые индексы: чем длиннее, тем точнее адрес и тем он предпочтительнее.
Из-за отсутствия фильтрации у аплинка, которым был провайдер PCCW, ложные маршруты быстро разошлись по всему миру и настоящие префиксы с длинной /22 отошли на скамейку запасных. YouTube стал недоступен почти на полтора часа. Это был случай неумышленного BGP-hijack или перехвата, по простому, вызванный ошибкой конфигурации.
В том же 2008 году бразильский оператор CTBC решил повторить опыт AS 7007 и начал раздавать Full View своим пир-соседям так, как будто эти маршруты принадлежат ему. Но в этот раз спасла грамотная фильтрация на стороне аплинков и система оповещений. Анонсы не ушли дальше, а инцидент стал примером того, как вовремя отработанные фильтры могут спасти глобальную сеть.
А может ли что-то покрупнее пропасть из глобального Интернета? Например, Facebook? Организация Meta, а также её продукты Instagram и Facebook, признаны экстремистскими на территории РФ.

Конечно может!
4 октября 2021 года внезапно перестал работать Facebook, Instagram и все внутренние сервисы компании Meta. Проблема оказалась в BGP — из-за ошибочной команды были удалены маршруты, анонсирующие сети DNS-серверов Meta во внешний мир. Весь остальной Интернет просто “перестал знать”, как добраться до их серверов. Попытки сотрудников решить проблему осложнились тем, что внутренняя сеть и системы доступа тоже зависели от недоступных DNS-ов. Meta вернулся в сеть только спустя шесть часов. Это был один из самых показательных примеров «самоотключения» в результате ошибочной конфигурации в современной истории BGP.
Были и другие крупные аварии, которые не причинили сильно большого урона в масштабах Интернета. Было большое количество инцидентов среднего размера и бесчисленное множество мелких неприятностей с неправильными анонсами, которые никогда не выходили за пределы аплинк-провайдера.
Но даже такие инциденты не поколебали основы протокола. BGP был и остается единственным, способным справиться с растущими требованиями Интернета.
Почему вообще такое стало возможно? проблема BGP в том, что он появился в те времена, когда безопасность не была важной задачей. Предполагалось, что участники сети будут честно сотрудничать ради её стабильности.
BGP работает на доверии: каждая AS считается добросовестной и объявляет только свои маршруты, с принадлежащими ей префиксами и правильной их длиной.

Со временем в других интернет-протоколах появились механизмы защиты (например, TLS для безопасного веб-сёрфинга), но у BGP таких встроенных средств нет.
Но разработки в эту сторону ведутся.
RPKI (Resource Public Key Infrastructure) — это система, которая помогает удостовериться, что тот, кто объявляет префиксы в BGP в Интернете, действительно имеет на это право.
Можно сравнить эту систему с холодильником в общежитии или офисе. Вы получаете право пользоваться общим холодильником (интернетом), складываете еду на определенную полку (публикуете ресурсы), но обязаны определенным образом подписывать еду, чтобы ее не забрал кто-то еще.
На основе этой системы разрабатывают и пытаются внедрять два дополняющих себя метода:
BGPsec — это расширение BGP добавляет цифровые подписи к маршрутам, чтобы можно было проверить, действительно ли маршрут прошёл через указанные AS (автономные системы) и никто его по пути не подделал.

Однако BGPsec не может обнаружить утечку маршрутов — ситуации, когда маршруты передаются не по «правильной» иерархии, например когда маршрут проходит через одну автономку несколько раз, по той или иной причине.
Предотвратить такое призвана ASPA (Autonomous System Provider Authorization). - ее смысл заключается в валидации AS-Path.

Единственный нюанс тут в том, что уже недостаточно что-то придумать и затем разработать, нужно убедить всех, что внедрение того стоит. И что забавно, сам BGP этому препятствует, потому что при всех НО и ЕСЛИ, он просто работает.
BGP далеко не единственный, что заставляет работать Интернет, но он отлично иллюстрирует тот факт, что Интернет склеен не усилиями людей, хотя без них тоже не обошлось, а в результате “болтовни” бездумных маршрутизирующих автоматов.
Благодаря работе таких «шестеренок», мы с вами можем любоваться котиками практически в любой точке мира.
Выпуск подготовил ведущий Ковальчук Артём, склеил скотчем и добавил лоска звукорежиссер Алексей Попов.