Будни сетевика
Open in Telegram
Блог про сети, CDN, менеджмент, интересные наблюдения, рабочие задачи и немного о том, как живут сетевики. Для связи - @ipatov_ds.
Show more315
Subscribers
No data24 hours
+17 days
+430 days
Data loading in progress...
Similar Channels
No data
Any problems? Please refresh the page or contact our support manager.
Tags Cloud
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
June '25
June '25
+4
in 0 channels
May '25
+134
in 0 channels
Get PRO
April '250
in 0 channels
Get PRO
March '25
+137
in 0 channels
Get PRO
February '250
in 0 channels
Get PRO
January '250
in 2 channels
Get PRO
December '24
+46
in 0 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 22 June | 0 | |||
| 21 June | +1 | |||
| 20 June | +1 | |||
| 19 June | 0 | |||
| 18 June | 0 | |||
| 17 June | 0 | |||
| 16 June | 0 | |||
| 15 June | 0 | |||
| 14 June | 0 | |||
| 13 June | 0 | |||
| 12 June | 0 | |||
| 11 June | 0 | |||
| 10 June | 0 | |||
| 09 June | 0 | |||
| 08 June | 0 | |||
| 07 June | 0 | |||
| 06 June | +1 | |||
| 05 June | 0 | |||
| 04 June | +1 | |||
| 03 June | 0 | |||
| 02 June | 0 | |||
| 01 June | 0 |
Channel Posts
+9
Будни сетевика в деревне!
Задача: запустить бортовой УАЗик 3303 после годового простоя.
Инструкция в 22 шага.
1. Заряжаем аккумулятор, тут все просто - берем акум, берем зарядное устройство, соединяем их вместе и оставляем наедине часа на три.
2. Проверяем уровень масла в двигателе.
3. Доливаем тосол.
4. Меняем свечи зажигания, лучше поставить новые, но если их нет, то можно прокалить и почистить имеющиеся. Тут я подготовился и привез новые.
5. Устанавливаем аккумулятор, а на его место сразу ставим на зарядку запасной, будьте уверены - он пригодится.
6. Установлен штатный топливный насос ручной подкачки, поэтому перед первым пуском помогаем ему руками накачать бензин в карбюратор.
Можно запускать двигатель!
7. Пробуем и видим дым под приборкой, прям нормально так дыма! Быстро снимаем клемму аккумулятора и пытаемся вытолкать его из деревянного гаража, чтобы не спалить все вокруг.
9. Снимаем крышку приборной панели, находим обуглившиеся провода, дальше изолента делает свое дело.
10. Разряжаем аккумулятор в безуспешных попытках запустить двигатель, что в принципе, ожидаемо - см. п.5.
11. Берем с зарядки запасной аккумулятор, устанавливаем.
12. Можно пробовать снова, но в этот раз откручиваем крышку воздушного фильтра, чтобы был доступ к карбюратору и немножко подливаем напрямую в него бензина, почти как впрыск закиси азота в форсаже 😅
13. На 3-4 секунды мотор возвращается к жизни, но из-за плохо качающего топливного насоса(но это я так думаю) надо повторить предудущий пункт 3-4 раза.
14. При условии, что еще не залили свечи к этому моменту двигатель должен запуститься.
15. Мотор тарахтит (или работает как часы) пару минут, обнаруживаем протекающий топливный шланг, запасного нет.
16. Но к счастью, протечка у самого места присоединения к топливному фильтру, поэтому можно его обрезать на 2см и вернуть на место, длины все еще хватает!
17. Ну все, поехали! Включаем первую передачу, а она не включается и вторая не включается и вообще никакая не включается. При этом в гараж год назад он заехал сам!
18. Просим шестилетнего сына понажимать на педаль сцепления, а сами лезем под УАЗик посмотреть на цилиндр сцепления и убедиться, что его надо снять и выкинуть на помойку, потому что он вообще не шевелится. 2-3 удара молотком приводят его в чувство, но только на два выжима сцепления.
19. Снимаем цилиндр сцепления, ставим новый (был в запасе).
20. Ищем, а где же у УАЗика находится бачок жидкости цилидра сцепления. Выясняем, что он прям «под носом».
21. Заливаем тормозную жидкость в бачок, ищем кого-то постарше - нужно прокачать систему.
22. Пока кто-то жмет на педаль спепления, лезем под УАЗик и спускаем воздух из системы.
Ну теперь-то можно ехать, да? Да!
Инструкция не универсальна и может отличаться от одного экземпляра к другому.
P.S. Но это не вся история, потому что без проблем он ездил только 7 дней, дальше приключения продолжились. Если тут такое интересно, то будет вторая часть, а также история про мотоцикл Восход 3М.
| 2 |  Посещать Linkmeetup всей командой сетевиков (ну, почти всей) стало для нас уже традицией. В нашем отделе есть три беларуса, и в этот раз возникла идея приехать к ним на B.E.E.R — Best Engineering Event in Republic — и заодно что-нибудь рассказать.
Место проведения: Минск, Dipservice Hall, 26 июля.
Доклад принят, начинаю подготовку.
По сути, это будет обновленная версия моего предыдущего доклада. За прошедшие 1,5 года объемы трафика увеличились в 4 раза, и сейчас мы можем раздавать более 100 Gb/s с одной ноды, появились новые алгоритмы работы нашего CDN-балансировщика, так что есть чем поделиться. | 415 |
| 3 |  На 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. | 451 |
| 4 | Нужен был инструмент для генерации трафика в одну сторону, без ожидания ответов. Схема не предполагала, что удаленная сторона может отвечать, поэтому 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. | 512 |
| 5 | Коллеги из DevOps рассказывают, почему мы начали переходить с Terraform на Pulumi.
Также добавлю ссылку на блог GitGuardian, где попытались доступно и пошагово разобраться в выборе между Terraform и Pulumi.
P.S. Terraform и Pulumi — это два инструмента в области «Infrastructure as Code», используемые для автоматизации управления облачными ресурсами, оба имеют открытый исходный код
https://habr.com/ru/companies/okko/articles/908960/ | 392 |
| 6 |  Как неожиданно и приятно, очень приятно.
«Лучший доклад Linkmeetup 2025» — благодарю зрителей за высокую оценку. В этот раз было представлено множество мощных докладов, что добавляет ценности полученной оценке. Жду записей, чтобы посмотреть те доклады, что пропустил.
На фото — команда сетевиков Okko (правда, только 80%), которая и сделала все то, о чем я говорил.
P.S. Хорошо это или плохо я еще не понял, но наш CDN изначально строили и продолжают развивать сетевики, сейчас даже продуктовая часть находится в наших руках. Фокус у части инженеров в процессе полностью сместился в серверную часть, но изначально это «базовые» сетевики, в какой-то момент перешедшие на темную сторону. | 428 |
| 7 | С нескрываемым удовольствием сообщаю, что у нас опять произошла отличная рубка за звание лучшего доклада линкмитапа. То есть программа получилась достаточно ровная и без явных перекосов.
В плотнейшей борьбе у финиша были и истории про лабораторные тесты от Сергея Бочарникова, и выбор между Быстро или Безопасно от Игоря Панарина и Андрея Иванова, активно в затылок всем дышала история про Network as Code от Александра Игнатова. Плотной группой шли доклады про DWDM, дичь в мультимедиа сетях, балансировку терабита на межсетевых экранах и так далее.
Но с отрывом буквально в несколько голосов лучшим докладом признаётся история от Дмитрия Ипатова, и как они в Окко готовились транслировать Евро24 и справились с нагрузкой в млн пользователей.
P.S. Презентации все выложим.
P.P.S. Записи тоже все выложим.
P.P.P.S. По срокам - КТТС. Точнее не будет. | 277 |
| 8 | Как и обещал, выкладываю презентацию с доклада.
Уложиться в отведенные 30 минут было непросто, и мне пришлось сократить первоначальный вариант примерно на 20%. Некоторые моменты не удалось раскрыть полностью, поэтому, если остались вопросы, пишите в личку.
Большое спасибо организаторам за мероприятие и за доверие быть спикером — всё прошло на высшем уровне!
P.S. Трафика от нас меньше не станет, так что если кто-то понял, что ему нужен кэш-сервер Okko, тоже пишите 🙂 | 908 |
| 9 |  +2Обещал рассказать о том, что помогает мне переключаться с рабочих задач. У меня есть проблема, описанная здесь, поэтому мне нужен триггер для переключения, желательно жесткий.
В моем случае таким триггером стало купание в холодной, а лучше в ледяной воде! Нет, я не профессиональный морж, который может долго находиться в холодной воде — цель здесь совсем другая. Это про перенастройку мышления, очистку, перезагрузку и преодоление себя — нет, с каждым разом легче не становится, все также непросто лезть в прорубь. Это про закаливание и общение: как семьями, так и только в мужской компании.
Когда я только начал, мы делали прорубь зимой ручной пилой и переодевались в сугробе 🥶 Времена меняются: за три года у нас появились электропила, электробур (бур + шуруповерт), походная баня с печкой, вторая баня с двумя печками и парогенераторами, отдельная палатка для переодевания или чаепития, самовар и множество других вещей: веники, ковшики, коврики, масла, травы, соли и т.д.
Нам стало так хорошо, что возникла идея поделиться этим опытом со всеми 😅
И вероятно, в ближайшем будущем появится коммерческая версия нашего клуба для всех желающих.
Про пользу и вред данного мероприятия можно почитать здесь. Как всегда, главное — делать все с умом!
P.S. О запуске открытой версии клуба сообщу отдельно. | 606 |
| 10 | С праздником!
Все знают о Попове и радио, но не все знают о профессоре М.А. Бонч-Бруевиче.
Я учился в «Бонче», поэтому предлагаю вам ознакомиться с достижениями этого ученого, в честь которого назван наш СПБ ГУТ.
P.S. На логотипе не улыбочки, а радиоволны!
https://www.sut.ru/university/about/istoriya/professor-mihail-aleksandrovich-bonch-bruevich | 432 |
| 11 |  Мир, Труд, Май!
Две недели до Linkmeetup 25 — самое время начинать работу над презентацией!
Шучу, я так не умею. Мне нужно еще 2-3 дня на доработки, но в целом всё почти готово.
Не раз слышал на конференциях фразы вроде: «Доделывал слайды прямо в самолёте». Конечно, ситуации бывают разные, но лично я считаю, что лучше об этом не говорить. Как слушатель, я тогда ловлю себя на мысли, что докладчик, возможно, не уделил подготовке достаточно времени — а значит, и моё внимание для него не так уж важно. | 444 |
| 12 | В IT Q2(второй квартал) — это спринт с горящим факелом жопой из бюджетных баталий, техдолга, подготовки к отпускам, конференций и перфоманс-ревью. Если в Q1 — это планирование, а в Q4 — подведение итогов, то Q2 — фаза максимальной реализации, и поэтому он такой сложный.
И тут как раз попалась статья про усталость.
P.S. В следующем посте я расскажу о способе переключения контекста с рабочих задач, который я нашел для себя.
https://habr.com/ru/articles/865660/ | 509 |
| 13 | Статья отражает мои мысли когда я пробовал разворачивать кластер Kubernetes пару лет назад. Помню, что где-то на RBAC мозг уже начал ломаться и с тех пор уже не стал прежним.
А вот это прям в точку:
Кубер унижает человеческое достоинство разными способами и на разных этапах. Это часть опыта от пользования продуктом. Так задумано.
https://habr.com/ru/companies/h3llo_cloud/articles/902188/ | 494 |
| 14 | RTT Москва <-> Алматы, Казахстан
L2VPN от провайдера:
RTT min/avg/max = 48.049 / 48.235 / 48.447 ms
Интернет:
RTT min/avg/max = 53.303 / 53.768 / 54.336 ms
Сойдет! 🙂 | 407 |
| 15 | Коллеги, есть у кого отзывы «с полей» про железку Juniper qfx5130?
https://www.juniper.net/us/en/products/switches/qfx-series/qfx5130-ethernet-switches.html | 441 |
| 16 |  Как связать 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. Сейчас в РФ использовать зарубежные облака стало практически невозможно и независимо от того как будут дальше развиваться события, думаю никто их уже не будет использовать как раньше(или убедите меня в обратном). Поэтому осталось посмотреть, а что там есть из вариантов подключения к «нашим» облакам. | 500 |
| 17 |  Конференция ТСС’25
Коллеги, кто тоже добрался до Алтая, рад буду пообщаться. | 389 |
| 18 |  Как связать 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 | 493 |
| 19 |  Как связать 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! | 403 |
| 20 | В продолжении предыдущего поста.
Я опубликовал статью на Habr, и в комментариях один коллега напомнил, что кроме Python существуют и другие инструменты, такие как awk.
Да, есть множество способов решить одну и ту же задачу, но вариант с awk действительно оказался проще, поэтому я добавил его в статью. | 407 |
