Рубрика «BGP»

Исследование устойчивости национальных сегментов сети Интернет за 2018 год - 1

Данное исследование объясняет каким образом отказ одной автономной системы (AS) влияет на глобальную связность отдельного региона, особенно в том случае когда речь идет о крупнейшем провайдере интернета (ISP) данной страны. Связность интернета на сетевом уровне обусловлена взаимодействием между автономными системами. По мере увеличения количества альтернативных маршрутов между AS возникает устойчивость к отказам и повышается стабильность интернета в данной стране. Однако, некоторые пути становятся более важными по-сравнению с остальными и наличие как можно большего числа альтернативных маршрутов в итоге является единственным жизнеспособным способом обеспечить надежность системы (в смысле AS).

Глобальная связность любой AS, независимо от того, представляет ли она второстепенного поставщика интернета или международного гиганта с миллионами потребителей услуг, зависит от количества и качества его путей к Tier-1 провайдерам. Как правило, Tier-1 подразумевает международную компанию, предлагающую глобальную услугу IP-транзита и подключение к другим Tier-1 операторам. Тем не менее, внутри данного элитного клуба нет обязательства поддерживать такую связь. Только рынок может придать мотивацию таким компаниям безоговорочно соединяться друг с другом, обеспечивая высокое качество обслуживания. Достаточный ли это стимул? Мы ответим на этот вопрос ниже в секции, посвященной связности IPv6.

Если провайдер интернета теряет связь с хотя бы одним из собственных Tier-1 соединений, он, вероятнее всего, окажется недоступен в некоторых частях Земли.
Читать полностью »

BGP — клей интернета. Для протокола, который нарисовали на двух салфетках в 1989 году одновременно удивительно и ужасно, что он обрабатывает почти все взаимодействия между ISP, являясь фундаментальной частью интернета.

У BGP плохая репутация главным образом из-за доверительного характера связей между пирами по дефолту и трудной задачи проверки легитимности маршрутов. Вот почему мы повсюду слышим о взломах BGP разной степени серьёзности: от смены маршрутизации всего YouTube до сервиса AWS Route 53.

Но чтобы понять природу этих взломов, следует понять топологию интернета. Начнём с одинокого маршрутизатора:

Играем в морской бой по BGP - 1

Читать полностью »

Зачем всё это делается в принципе и как оно устроено логически — описано в первой и второй статьях.
После их публикации я получил несколько вопросов от людей, которые пользуются VPN с не принадлежащих им ресурсов (например, приобретающих коммерческую услугу VPN). Этим людям раньше я советовал завести VPS для развертывания BGP-сервиса или каким-то еще образом получить доступ к серверу на Linux.

Но с сегодняшнего дня для них (и для всех остальных) есть более удобный вариант — на бесплатном сервисе antifilter.download появилась возможность автоматически настраивать BGP-сессию с вашим маршрутизатором.

Читать полностью »

Присутствие Route Target в BGP-анонсах между PE и CE - 1

Статья предполагает, что у читателя уже есть понимание основ MPLS L3VPN.

Привет. Допустим, вы — ISP. И как у любого достаточно крупного ISP, ядро вашей сети построено на базе IP/MPLS. Если совсем уж упрощать, то вашу сеть можно представить схемой, изображенной выше. Давайте также допустим, что вы, как ISP, продаете своим клиентам услугу L3VPN, которая на вашей сети реализуется в соответствии с RFC 4364 (BGP/MPLS IP VPNs). И в том случае, если клиенту L3VPN на некотором сайте недостаточно directly connected сети, и он хочет анонсировать другим сайтам дополнительные маршруты, то вы поднимаете между вашим оборудованием (PE) и оборудованием клиента (CE) BGP-сессию, посредством которой клиент может анонсировать желаемые маршруты. При всем этом какие-либо фильтры/политики вы к данной сессии не применяете, руководствуясь тем, что это, дескать, VPN клиента, и он волен в нем «гонять» все, что захочет (в пределах лимита по числу префиксов, например). А теперь внимание, вопрос: что произойдет, если в рамках этой BGP-сессии клиент будет анонсировать вам (провайдеру) маршруты, добавляя к ним Route Target Community? Это может быть, к примеру, результатом ошибки, либо желанием поэкспериментировать.
Читать полностью »

Сервис BGPMon зафиксировал попытку подстановки фиктивного BGP-маршрута для перенаправления трафика подсети 1.1.1.0/24, в которой находится созданный компанией Cloudflare общедоступный DNS-сервер с поддержкой DNS-over-TLS и DNS-over-HTTPS.

image

Трафик был направлен в автономную систему AS58879, анонсировавшую префикс 1.1.1.0/24 для своей сети. Читать полностью »

Перечитал я трезвым взглядом свой предыдущий пост и понял, что новичкам через все эти нагромождения апдейтов и обсуждений в комментариях (которые местами были даже полезнее, чем сам пост) продираться будет затруднительно.

Поэтому здесь я приведу сжатую пошаговую инструкцию, как обходить блокировки, если у вас есть:

  • линукс-машина (ubuntu) вне поля блокировок;
  • роутер Mikrotik, на который вы уже подняли VPN-туннель до этой линукс-машины;
  • настроенный NAT на этом туннеле, позволяющий вам работать через него;
  • желание.

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

Те, кто уже всё сделал по мотивам предыдущего поста, в этом полезной информации не почерпнут.

Читать полностью »

Ну ладно, про «полюбил» — это преувеличение. Скорее «смог сосуществовать с».

Как вы все знаете, с 16 апреля 2018 года Роскомнадзор крайне широкими мазками блокирует доступ к ресурсам в сети, добавляя в "Единый реестр доменных имен, указателей страниц сайтов в сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространение которой в Российской Федерации запрещено" (по тексту — просто реестр) по /10 иногда. В результате граждане Российской Федерации и бизнес страдают, потеряв доступ к необходимым им совершенно легальным ресурсам.

После того, как в комментариях к одной из статей на Хабре я сказал, что готов помочь пострадавшим с настройкой схемы обхода, ко мне обратились несколько человек с просьбой о такой помощи. Когда у них всё заработало, один из них порекомендовал описать методику в статье. Поразмыслив, решил нарушить свое молчание на сайте и попробовать в кои-то веки написать что-то промежуточное между проектом и постом в Facebook, т.е. хабрапост. Результат — перед вами.

Читать полностью »

Около года назад я заприметил интереснейшую и увлекательную серию лекций Эдди Мартина, который потрясающе доходчиво, благодаря своей истории и примерам из реальной жизни, а также колоссальному опыту в обучении, позволяет приобрести понимание довольно сложных технологий.

Тренинг FastTrack. «Сетевые основы». «Основы маршрутизации». Эдди Мартин. Декабрь, 2012 - 1

Мы продолжаем цикл из 27 статей на основе его лекций:

Тренинг FastTrack. «Сетевые основы». «Понимание модели OSI». Часть первая. Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Понимание модели OSI». Часть вторая. Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Понимание архитектуры Cisco». Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Основы коммутации или свитчей». Часть первая. Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Основы коммутации или свитчей». Часть вторая. Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Свитчи от Cisco». Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Область использования сетевых коммутаторов, ценность свитчей Cisco». Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Основы беспроводной локальной сети». Часть первая. Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Основы беспроводной локальной сети». Часть вторая. Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Продукция в сфере беспроводных локальных сетей». Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Ценность беспроводных локальных сетей Cisco». Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Основы маршрутизации». Эдди Мартин. Декабрь, 2012

И вот двенадцатая из них.
Читать полностью »

imageСлева вы наблюдаете аватар savannah.gnu.org, где лежит репозиторий Quagga. Нам показалось, что он подходит к событию.

Примерно две недели назад команда Qrator Radar столкнулась с интересным сетевым инцидентом, выяснение обстоятельств которого вылилось во внутреннее расследование-исследование, с поиском пострадавших и виновных, а также попытками исправить ситуацию. 30.09.2017 наша команда обратила внимание на необычно большое количество «мигающих» BGP-сессий.
Читать полностью »

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

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

Ericsson SmartEdge

notification msg sent (nbr 192.0.2.1, context 0x40030044 32 bytes, repeated 89 times, code 3/4 (update: attribute flags error) - 
0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 0003 02ed 5bdc 3f01

Cisco, то же с другой стороны

NOTIFICATION received from 192.0.2.2 (External AS 64496):
code 3 (Update Message Error) subcode 4 (attribute flags error),
Data: e0 07 08 00 03 02 ed 5b dc 3f 01

Попробуем разобрать это руками как написано в RFC4721. Не будем искать причину — просто разбор заголовков. Будет много цитат и, скорее всего, ничего нового для тех кто уже это умеет делать. Для остальных читаем дальше.Читать полностью »