Долго ли коротко ли длилась история linkmeup, но компания росла, развивалась. Счёт маршрутизаторов уже на десятки, свои опто-волоконные линии, развитая сеть по городу. И было принято решение оформлять компанию, как провайдера и предоставлять услуги доступа в Интернет для сторонних в том числе организаций.
Сама по себе задача административная — лицензии там, поиск клиентской базы, реклама, поставить СОРМ.
Разумеется, с технической стороны тоже нужны приготовления — просчитать ресурсы, мощности, порты, подготовить политику QoS. Но всё это (за исключением QoS) — рутина.

Мы же хотим поговорить о другом — IBGP. Возможно, тема покажется вам несколько притянутой за уши, мол, внутренний BGP — прерогатива достаточно крупных провайдеров.
Однако это не так, сейчас iBGP задействуется в ентерпрайзах чуть ли не чаще, чем в провайдерах. С целью исключительно внутренней маршрутизации. Например, ради VPN — очень популярное приложение на базе BGP в корпоративной среде. К примеру, возможность организовать периметры, изолированные на L3, на уже используемой инфраструктуре очень ценна. А префиксов-то может быть каких-то полсотни, а то и десяток. Вовсе никакой не Full View, однако все равно удобно.

Возможно, к нашей сети Linkmeup это не имеет по-прежнему отношения, но обойти стороной такую концепцию будет совершенно непростительно. Поэтому предположим, что сеть достаточно велика, и у нас есть необходимость в BGP в ядре.

Сегодня обсудим

• Когда нужен IBGP
• В чём отличия от EBGP
• Route Reflector’ы
• Конфедерации
• Нерассмотренные в основной статье атрибуты BGP

Традиционное видео


Задачки в этом выпуске не относятся напрямую к IBGP, это, скорее, по BGP в целом. Интересно будет как новичкам поломать голову, так и старожилам размяться

Mozilla выпустила инструмент, который наверняка многим облегчит жизнь: это фреймворк RR под Linux для записи и последующего воспроизведения хода выполнения программы. Воспроизведение происходит абсолютно детерминированно, то есть с теми же регистрами и адресами памяти — и неизменно с тем же сбоем (если он был). Другими словами, можно бесконечно гонять тесты, а как только появится баг — не спеша его изучить в офлайне, прокрутив запись сколько угодно раз. Записываются все деревья процессов и потоков.

RR создан для точного воспроизведения багов, которые проявляют себя непредсказуемо. В таких случаях при отладке стандартными средствами нет смысла запускать программу снова: не факт, что баг опять проявится. Эта проблема постоянно портит жизнь разработчикам. Вот почему в Mozilla решили создать такой фреймворк.

Однажды коллега поделился размышлениями об API для распределённых вычислительных кластеров, а я в шутку ответил: «Очевидно, что идеальным API был бы простой вызов telefork(), чтобы твой процесс очнулся на каждой машине кластера, возвращая значение ID инстанса». Но в итоге эта идея овладела мной. Я не мог понять, почему она такая глупая и простая, намного проще, чем любой API для удалённой работы, и почему компьютерные системы, кажется, не способны на такое. Я также вроде бы понимал, как это можно реализовать, и у меня уже было хорошее название, что является самой трудной частью любого проекта. Поэтому я приступил к работе.

За первые выходные сделал базовый прототип, а второй уикенд принёс демку, которая могла телефоркнуть процесс на гигантскую виртуальную машину в облаке, прогнать рендеринг трассировки путей на множестве ядер, а затем телефоркнуть процесс обратно. Всё это завёрнуто в простой API.

На видео показано, что рендеринг на 64-ядерной VM в облаке завершается за 8 секунд (плюс 6 секунд на телефорк туда и обратно). Тот же рендеринг локально в контейнере на моём ноутбуке занимает 40 секунд: