Как связать on-prem с облачной инфраструктурой
(часть 1 из 4)

В зарубежных облачных сервисах есть варианты:

0️⃣ Public Internet — арендуем публичный IP-адрес, назначаем на виртуальную машину в облаке. Это позволяет организовать доступ из on-prem в облачную инфраструктуру по этому IP, в принципе можно поднять с ним GRE/IPSec. Для полноценного Site-to-Site слабовато, но в целом почему бы и нет?

1️⃣ Managed IPSec — быстрый и дешевый(относительно 2️⃣ и 3️⃣ ) способ создания Site-to-Site соединения, предоставляемый как сервис. Однако производительность будет зависеть от возможностей вашего оборудования on-prem и лимитов виртуального маршрутизатора в облаке, а скорость поднятия связности только от вас, а именно, как быстро вы сможете подружить IPSec между on-prem и облаком.

2️⃣ Partner или Hosted подключение — подключение через сети операторов-партнеров, которые уже имеют настроенные сетевые стыки и интеграции с облачными провайдерами. Обычно выделяемая полоса составляет от 50 Mbps до 10 Gbps. В России таких услуг не встречал, но они доступны во многих популярных облаках за пределами страны.

3️⃣ Dedicated подключение — выделенная линия от вашей инфраструктуры до точки подключения к облаку. Организация этой линии лежит на вас(если у вас нет оборудования в том же ДЦ, если есть, то кроссировку все равно придется проложить), но скорость подключения может варьироваться от 1 до 400 Gbps на порт.


▎Про IPSec

Все цифры в таблице актуальны для одного туннеля, но если облачный провайдер позволяет создать второй туннель и настроить ECMP с использованием протоколов маршрутизации, то конечная скорость может быть выше.

При этом у всех облачных провайдеров разные лимиты на количество туннелей и их ограничения. Например, в AWS можно создать 50 Site-to-Site подключений в одном регионе, а с включенным ECMP это по 2.5Gbps на каждое подключение, т.е. в теории могло бы получиться 125Gbps, но больше 50Gbps получить все равно не выйдет:

The maximum bandwidth of a combined (using ECMP) set of VPNs is 50 Gb/s

Часть провайдеров в документации указывают pps(max packets per second), но верно подмечают, что могут быть нюансы:

There are many factors that can affect realized bandwidth through a Site-to-Site VPN connection, including but not limited to: packet size, traffic mix (TCP/UDP), shaping or throttling policies on intermediate networks, internet weather, and specific application requirements.

Например, Google:

250,000 packets per second is roughly equivalent to 1 Gbps to 3 Gbps, depending on the average packet size within the tunnel.

И не забываем про рекомендации на счет MTU/MSS при использовании разных
алгоритмов шифрования.

▎Про IPv6:

1. AWS сообщает, что нельзя использовать external ipv6 для установки туннелей, но внутри туннелей уже можно, но это не серьезно.

2. Google утверждает, что умеет строить туннели на ipv6, но только в схеме с HA, в classic VPN - нет.

3. Azure признает, что VPN Gateway пока не поддерживает ipv6, возможно тут слишком мало голосов за эту фичу. Надо поднажать, кому актуально.

4. Alibaba Cloud скромно говорят, что у них есть ipv6 Gateway, но он может только выпустить VM в Интернет по ipv6, но не более того.

5. Oracle заявляют, что поддерживают ipv6 и можно обмениваться трафиком между on-prem и cloud по ipv6, но судя по всему построить туннель на ipv6 не получится:

CPE device's public IP address. (The address must be IPv4, but IPv6 traffic is supported)

Скажу честно, не люблю IPv6, но при случаю подмечаю кто и как его использует. Интересно наблюдать со стороны.

Итого, если нужен «самый крутой IPSec», то выбираем Google Cloud!

Как связать on-prem с облачной инфраструктурой
(часть 2 из 4)

Каждый облачный провайдер предлагает свои сетевые сервисы(названия у всех свои), которые позволяют устанавливать прямые соединения между локальной on-prem инфраструктурой и облаком. Подключение может осуществляться через операторов-партнеров (Hosted/Partner) или напрямую к оборудованию облака (Dedicated).

▎Про Hosted/Partner подключение

Для подключения обычно доступны следующие скорости: 50 Mbps, 100 Mbps, 200 Mbps, 300 Mbps, 400 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, 5 Gbps и 10 Gbps. В документации AWS также упоминается про 25 Gbps.

Процесс подключения достаточно прост:

1. Найдите провайдера, который предлагает услугу подключения к облаку.
2. Подключитесь к выбранному оператору.
3. Сообщите провайдеру данные вашего аккаунта в облаке.
4. Ожидайте, пока провайдер активирует новое подключение в вашем аккаунте.
5. Подтвердите новое подключение в вашем аккаунте.
6. Настройте виртуальный маршрутизатор и интерфейсы в облаке, а также BGP.
7. Настройте BGP на маршрутизаторе в вашей on-prem инфраструктуре.

Существуют варианты с L2 и L3. В случае с L2VPN BGP-сессия устанавливается с виртуальным маршрутизатором в облаке, а для L3VPN — с маршрутизатором оператора, предоставившего канал. Однако не все провайдеры всегда предлагают выбор между L2 и L3. Приходится брать то, что есть!

Одно Hosted подключение соответствует одному виртуальному интерфейсу, то есть одному VLAN. Если требуется несколько VLAN, придется заказывать дополнительное Hosted подключение или переходить на Dedicated.

▎Про IPv6

В документации утверждается, что пириться по IPv6 можно со всеми.

Ссылки на партнерские включения по регионам присутствия:
1. AWS Direct Connect partners
2. Google Cloud partners
3. Azure Express Route partners
4. Alibaba Cloud Express Connect partners
5. Oracle Cloud Fast Connect partners

Конференция ТСС’25

Коллеги, кто тоже добрался до Алтая, рад буду пообщаться.

Как связать on-prem с облачной инфраструктурой
(часть 3 из 4)

▎Про Dedicated подключение

В зависимости от облака для подключения доступны варианты от 1 до 400 Gbps. Все поддерживают LAG, но есть ограничения:
100/400G x 2
10G x 8

Только AWS пишет про поддержку 400Gbps.


Процесс подключения достаточно прост:

1. Найдите ЦОД(PoP), где можно подключиться к облаку
2. Создайте новое подключение в консоли облака в данной точке присутствия
3. Дождитесь пока запрос на новое подключение будет выполнен
4. Скачайте Letter of Authorization and Connecting Facility Assignment (LOA-CFA, тут будут координаты портов для включения
5. Закажите кроссировку(и) в ЦОДе, данные будут в LOA
6. Настройте виртуальный маршрутизатор и интерфейсы в облаке (и BGP)
7. Настройте BGP на маршрутизаторе в вашей on-prem инфраструктуре

Далее возможны варианты по построению отказоустойчивых схем, например подключение к Direct Connect в разных AZ.

В комменты кину пример LOA из далекого 2020 г.

▎Про IPv6

В документации утверждается, что пириться по IPv6 можно со всеми.

P.S. Сейчас в РФ использовать зарубежные облака стало практически невозможно и независимо от того как будут дальше развиваться события, думаю никто их уже не будет использовать как раньше(или убедите меня в обратном). Поэтому осталось посмотреть, а что там есть из вариантов подключения к «нашим» облакам.

Коллеги, есть у кого отзывы «с полей» про железку Juniper qfx5130?

https://www.juniper.net/us/en/products/switches/qfx-series/qfx5130-ethernet-switches.html

RTT Москва <-> Алматы, Казахстан

L2VPN от провайдера:
RTT min/avg/max = 48.049 / 48.235 / 48.447 ms

Интернет:
RTT min/avg/max = 53.303 / 53.768 / 54.336 ms

Сойдет! 🙂

Статья отражает мои мысли когда я пробовал разворачивать кластер Kubernetes пару лет назад. Помню, что где-то на RBAC мозг уже начал ломаться и с тех пор уже не стал прежним.

А вот это прям в точку:

Кубер унижает человеческое достоинство разными способами и на разных этапах. Это часть опыта от пользования продуктом. Так задумано.

https://habr.com/ru/companies/h3llo_cloud/articles/902188/

В IT Q2(второй квартал) — это спринт с горящим факелом жопой из бюджетных баталий, техдолга, подготовки к отпускам, конференций и перфоманс-ревью. Если в Q1 — это планирование, а в Q4 — подведение итогов, то Q2 — фаза максимальной реализации, и поэтому он такой сложный.

И тут как раз попалась статья про усталость.

P.S. В следующем посте я расскажу о способе переключения контекста с рабочих задач, который я нашел для себя.

https://habr.com/ru/articles/865660/

Мир, Труд, Май!

Две недели до Linkmeetup 25 — самое время начинать работу над презентацией!

Шучу, я так не умею. Мне нужно еще 2-3 дня на доработки, но в целом всё почти готово.

Не раз слышал на конференциях фразы вроде: «Доделывал слайды прямо в самолёте». Конечно, ситуации бывают разные, но лично я считаю, что лучше об этом не говорить. Как слушатель, я тогда ловлю себя на мысли, что докладчик, возможно, не уделил подготовке достаточно времени — а значит, и моё внимание для него не так уж важно.

С праздником!

Все знают о Попове и радио, но не все знают о профессоре М.А. Бонч-Бруевиче.

Я учился в «Бонче», поэтому предлагаю вам ознакомиться с достижениями этого ученого, в честь которого назван наш СПБ ГУТ.

P.S. На логотипе не улыбочки, а радиоволны!

https://www.sut.ru/university/about/istoriya/professor-mihail-aleksandrovich-bonch-bruevich

Как и обещал, выкладываю презентацию с доклада.

Уложиться в отведенные 30 минут было непросто, и мне пришлось сократить первоначальный вариант примерно на 20%. Некоторые моменты не удалось раскрыть полностью, поэтому, если остались вопросы, пишите в личку.

Большое спасибо организаторам за мероприятие и за доверие быть спикером — всё прошло на высшем уровне!

P.S. Трафика от нас меньше не станет, так что если кто-то понял, что ему нужен кэш-сервер Okko, тоже пишите 🙂

Как неожиданно и приятно, очень приятно.

«Лучший доклад Linkmeetup 2025» — благодарю зрителей за высокую оценку. В этот раз было представлено множество мощных докладов, что добавляет ценности полученной оценке. Жду записей, чтобы посмотреть те доклады, что пропустил.

На фото — команда сетевиков Okko (правда, только 80%), которая и сделала все то, о чем я говорил.

P.S. Хорошо это или плохо я еще не понял, но наш CDN изначально строили и продолжают развивать сетевики, сейчас даже продуктовая часть находится в наших руках. Фокус у части инженеров в процессе полностью сместился в серверную часть, но изначально это «базовые» сетевики, в какой-то момент перешедшие на темную сторону.

Коллеги из DevOps рассказывают, почему мы начали переходить с Terraform на Pulumi.

Также добавлю ссылку на блог GitGuardian, где попытались доступно и пошагово разобраться в выборе между Terraform и Pulumi.

P.S. Terraform и Pulumi — это два инструмента в области «Infrastructure as Code», используемые для автоматизации управления облачными ресурсами, оба имеют открытый исходный код

https://habr.com/ru/companies/okko/articles/908960/

Нужен был инструмент для генерации трафика в одну сторону, без ожидания ответов. Схема не предполагала, что удаленная сторона может отвечать, поэтому iperf не подходил. Также необходимо было управлять скоростью, например, на уровне 100, 200, 500 или 1000 Mbps. Первым попавшимся под руку инструментом оказался hping3.

Трафик генерировался с виртуальной машины (4 ГБ RAM, 8 CPU, Ubuntu 24, NIC на ESXi 25G x2).

У hping3 есть флаг --flood, который позволяет отправлять пакеты с максимальной скоростью без задержки между ними. Запускаем тест и для начала проверим его возможности:

hping3 --udp -p 5000 -d 9000 --flood <ip>

Максимальная скорость составила 2.1 Gbps, что связано с однопоточной архитектурой hping3, которая не позволяет полноценно загружать многоядерные процессоры. Этот инструмент работает через стандартный стек Linux и не использует DPDK или другие "ускорители". Каждый пакет проходит через системные вызовы (sendto()), что создает высокую нагрузку на CPU. Но скорости выше 2 Gb/s не требовалось; градаций от 100 Mb/s до 1 Gb/s было достаточно.

Чтобы управлять скоростью трафика, я решил поэкспериментировать с размером пакета (-d) и интервалом отправки пакетов (-i). Попробовал честно рассчитать необходимые значения:

100 Mbit = 12,500,000 bytes
12,500,000 / 1472 (размер пакета) = 8491 пакетов/сек → интервал 1/8491 = 0.0001178 сек = 118 µs (микросекунды)

Запускаем с интервалом u118:

hping3 --udp -p 5000 -d 1472 -i u118 <ip>

На выходе получаем скорость: 75.17 Mbps. В целом, выглядит правдоподобно. Предполагаю, что сетевые карты и драйверы добавляют задержки, особенно в виртуальных средах, поэтому точности ожидать не приходится.

Далее я опытным путем подобрал значения интервалов для достижения требуемых скоростей:

hping3 --udp -p 5000 -d 1472 -i u95 <ip>
Speed: 99.17 Mbps 

hping3 --udp -p 5000 -d 1472 -i u35 <ip>
Speed: 208.31 Mbps 

hping3 --udp -p 5000 -d 1472 -i u4 <ip>
Speed: 989.28 Mbps

В принципе, со своей задачей hping3 справился, но изначально он создавался для задач анализа сетевой безопасности (или наоборот 🙂)

Приведу примеры, когда он может пригодиться.


▎Тесты на защиту от DDoS

icmp-флуд
hping3 --icmp --flood <ip>

tcp-флуд
hping3 -S -p 80 --flood <ip>

udp-флуд
hping3 --udp -p 53 --flood -d 1000 <ip>

▎Spoofing (подделка src ip/mac)

ip spoofing
hping3 -a <bad_ip> -S -p 22 <ip>

mac spoofing
hping3 --spoof 00:11:22:33:44:55 -p 80 <ip>

▎Сканирование

tcp syn-сканирование(аналог nmap)
hping3 -S -p 80 <ip>

Сканирование диапазона портов
hping3 -S -p 1-1000 <ip>

▎Проверка IPS/IDS

Вставим SQL-инъекцию в пакет, сработает ли IDS?
echo "SELECT * FROM users" | hping3 -p 80 -E /dev/stdin <ip>

Тест на переполнение буфера.
Проверим падает ли сервис при отправке огромного пакета:
hping3 -p 80 --data 10000 <ip>

Ну и наконец, раз инструмент называется hping3, должен быть и обычный ping:

hping3 -1 <ip>

Выводы: hping3 отлично подходит для задач тестирования фаерволов, анализа IPS/IDS и проверки устойчивости к DoS-атакам. Однако для задач точного измерения скорости лучше использовать другие инструменты, например, iperf.

P.S. На последнем Linkmeetup 25 узнал о Trex. Да, первый раз услышал 🤷. По описанию — мощный инструмент с многопоточностью и низкой нагрузкой на CPU за счет DPDK оптимизаций; можно генерировать трафик свыше 100G. Вероятно, в следующий раз попробую его. Но в пользу hping3 скажу, что он не требует конфигурационных файлов — установил и используй в CLI.

На Linkmeetup25(тут преза) я рассказывал о том, как и зачем мы использовали weighted equal-cost multipath (WECMP).

Вот ссылки на документацию Juniper:

1. Load Balancing for a BGP Session - решение для балансировки между серверами разной производительности

2. BGP Link-Bandwidth Community - решение для балансировки между аплинками разной емкости

Настройки точно работают на Juniper MX204, MX304 и MX10003.

P.S. Возможно, скоро проверим на Juniper PTX.

Посещать Linkmeetup всей командой сетевиков (ну, почти всей) стало для нас уже традицией. В нашем отделе есть три беларуса, и в этот раз возникла идея приехать к ним на B.E.E.R — Best Engineering Event in Republic — и заодно что-нибудь рассказать.

Место проведения: Минск, Dipservice Hall, 26 июля.

Доклад принят, начинаю подготовку.

По сути, это будет обновленная версия моего предыдущего доклада. За прошедшие 1,5 года объемы трафика увеличились в 4 раза, и сейчас мы можем раздавать более 100 Gb/s с одной ноды, появились новые алгоритмы работы нашего CDN-балансировщика, так что есть чем поделиться.