Всем привет!

У нас планируется вчетвертый раз наш неповторимый и уникальный митап для инженеров в духе бара - LIKE A BAR.

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

Кто: инженеры, сочувствующие, не более 50 человек.
Что: уютная атмосфера встречи с друзьями, доклады, пиво, пицца, инженерный открытый микрофон.
Когда: 26.03.2026 18:30.
Где: Санкт-Петербург, Арсенальная улица дом 2, лофт "Agava". Справа от нас скалодром "Эль Капитан".

Спикеры:

Роман Карауланов - MWS, с докладом "От скриптов к единому сервису автоматизации сети"

Егор Зимин - B4COM, придёт с темой «ПМИ глазами инженера TAC"

Сергей Савелов - Окко, «Отказоустойчивый Netbox»

Если вы хотите принять участие, то вот тут:
регистрация: https://forms.gle/XjKEaDB78WKvVQKc7
чат в TG: https://t.me/likeabar
ссылка на мой канал с которого всё и пошло: https://t.me/like_a_bus_channel

Для тех кто хочет поддержать: https://pay.cloudtips.ru/p/7b527096,
либо кнопка "задонатить" выше и ниже статьи.

А если вы хотите подробностей и не понимаете, зачем вам это все нужно, то для вас написал чуть больше текста.

Тут всё началось...

Итак, в середине 2024 года, после ряда выступлений на различных мероприятиях, я решил начать вести свой блог, т.к. заметил у людей большой интерес к тематике сетевой инфраструктуры.

Достаточно быстро набралось несколько сотен человек и мне показалось, что хорошо бы на основе канала собрать какую-то часть из этих людей в оффлайне. Собственно, не стал далеко ходить и предложил эту идею коллегам из маркетинга.

Так и родился наш первый митап, который прошёл в офисе Rubytech, 12 декабря 2024 года. На него пришло порядка 25 человек, было 3 доклада, пицца, пиво, вот это вот всё в общем.

Вот немного фоток:

В общем, мероприятие прошло хорошо и недолго думая, спустя каких-то 4 месяца, я решил, что надо повторять.

Митап #2

К нему я уже подошёл с каким-никаким но опытом, сделали чуть лучше логистику, тайминги и прочее.

А 17 апреля 2025 года он у нас и состоялся!

Пришло около 40 человек, была привычная пицца, пиво, снеки. И конечно же доклады! Всё также три (практика показала, что больше не стоит, это в самый раз):

Ну и вот вам какие-то доказательства!

Мы попытались что-то записывать, но очень быстро стало понятно, что на скорую руку это не сделать, и отказались от этой идеи.

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

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

Митап #3 или LIKE A BAR

Т.к. я больше не был связан с кем-то корпоративными обязательствами, то решил полностью изменить название в пользу того духа, который всегда преследовал. А именно LIKE A BAR.

Скажу так, что я думал, будто бы уже готов, но оказалось всё чуть-чуть иначе. Эта подготовка была очень сложная. Как минимум поиск площадки, пришлось потратить примерно 5-6 полных выходных, чтобы найти нужную. Плюс, мы решили попробовать сделать какой-никакой но мерч!

Это были наши бирдекели, собственно вот:

Плюс Полина замутила полноценную афишу-стенд, которую мы поставили на входе в наш импровизированный бар:

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

11 декабря 2025 года, состоялся наш третий митап, он же LIKE A BAR #3.

На этот раз пришло около 45 человек, при этом интересно то, что было много новых лиц.

Конечно же были доклады.

Дима Долгополов из B4COM, рассказал про архитектуру их софта, и конкретно про перспективное направление BCOM-X:

Аркадий Марисенков из Окко, выступил с докладом о том, как работает их CDN и почему он такой крутой.

Ваня Федоров из MWS, коротко прошёлся по теории и показал на практике что такое N8N, и как он помогает решать задачу по логированию событий.

И вот вам просто разные фотки:

А ещё Ваня Чернышков притащил вывеску для бара и торжественно мне ещё подарил! Это просто пушка!

Ну и что дальше?

А дальше то, что я сделал опрос на канале, и решил, что пора нашему бару на выезд, а именно в Северную Столицу.

И вот мы запланировали 26 марта 2026 года провести LIKE A BAR #4, уже в Санкт-Петербурге.

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

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

Ну и если теперь вы поняли зачем вам это всё и хочется прийти, то вам сюда!

На этом всё! До встречи в LIKE A BAR!

По счастливой случайности, мой друг, коллега, соратник и вообще отличный парень - находился там и смог побыть репортёром! Огромное ему спасибо!

В этот раз, если доверять агенде докладов, да и вообще общему настрою маркетологов Cisco, основной упор был на 3 темы:

- SRv6;
- AI;
- Automation.

Сами доклады транслировались вот тут https://www.youtube.com/live/pDYTT5ju2sQ, а расписание можно было найти по ссылке https://www.ciscolive.com/emea.html

Помимо всего прочего, Cisco представила свои чипы Silicone one, которые существуют в разных версиях:

• A-Series: Feature Rich Access

• K-Series: Feature Rich Router
• E-Series: Feature Rich Switch

• P-Series: Domain Interconnect and Core Router
• G-Series: AI Scale Switch

Подробнее можно вот тут поискать - https://www.cisco.com/site/us/en/products/networking/silicon-one/index.html

Плюс, были представлены некоторые из коробок, собранные на базе вышеописанных чипов.

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

А вот так теперь выглядит настройка гитары, правда я не понимаю причем тут Cisco... Если кто-то в курсе, просвятите, пожалуйста.

Конечно же, было много всякого разного по теме Segment Routing. Ниже какие-то фотографии слайдов с доклада Алексея Горового, презентация доклада с предыдущего Live доступна вот тут https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2025/pdf/BRKSP-2551.pdf

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

Естественно, когда речь идёт про Cisco, все сразу же вспоминают её прекрасные обучающие материалы. Огромное количество инженеров, не только сетевиков, изучали сети по курсам CCNA и конкретно Cisco Packet Tracer. И конечно же, компания не могла обойти эту тему на своей конференции.

На Live была представлена целая библиотека / книжный магазин, где можно пошуршать по полкам и найти заветную книжку.

А вот они все!

Плюс, ко всему прочему, Cisco предлагает очень крутую штуку Walk-in-labs.

Суть понятна из названия, но давайте вместе чуть-чуть перенесёмся туда и попытаемся представить какого это.

То есть ты просто бродишь себе такой, шаришься в попытке найти баночку колы.

Находишь её.

И тут внезапно, тебе на глаза попадается стойка регистрации и куча стендов!

Проходишь регистрацию, выбираешь себе какой-то топик.
Тебе выдают комп с преднастроенной лабой и выжимкой теории.
Садишься и лабишь.
Очень быстро и по делу.

Вот тут весь список лаб, которые были представлены, только без самих виртуалок - https://wilassistant.com/lablist.

Отдельным бонусом является то, что тут же есть и прокторы, т.е. вы можете сдать экзамен. Наверное на CCIE придётся регистрировать заранее, но любой уровня written, кажется не проблема. Ну пушка, в общем.

Вот какой-то промо ролик от самой Cisco.

Чтобы вы понимали масштабы мероприятия, то со слов организаторов, в этот раз приняло участие более 21 тысячи человек.

Ну, это много.

И в завершение, устроили какую-то afterparty, с музыкой и т.д

В итоге, Cisco Live подошёл к концу, как и мой обзор. Если вы там были - искренне завидую, крутейшее мероприятие для инженеров.

Сам я последний раз был разве что на российском урезанном варианте Cisco Connect в 2018 году.

Надеюсь, что когда-то и у нас появятся конференции подобных масштабов!

Спасибо и подписывайтесь в мою телегу - https://t.me/like_a_bus_channel!

В общем, недавно вводили в эксплуатацию один сервис, построенный на базе Ubuntu 22.04.5 LTS

В какой-то момент обратили внимание, что есть всплески по conntrack и мы упираемся в потолок. Проявляется очень просто, не устанавливаются новые TCP сессии идущие через наш хост. В общем нужно увеличить количество возможных соединений.

Управляется это через параметр net.nf_conntrack_max, который по дефолту имеет значение 262144.

Сначала просто поменяли в рантайме через sysctl:

Соединения сразу выросли, но понятное дело, всё это живо только до ребута. Надо персистить.
Делается это через управление файликами *.conf внутри /etc/sysctl.d/, то есть создаёте новый и туда прописываете нужные параметры, они при запуске системы будут считываться sysctl и всё будет корректно настраиваться:

Но, если вот в такой конструкции перезагрузить хост, то после запуска вы увидите опять всё те же значения conntrack, которые были по дефолту - 262144.

Если посмотреть логи, то внутри будет ошибка, что файл не найден:

Спустя какое-то время, я догадался что это происходит по той причине, что модуль nf_conntrack загружается ПОСЛЕ того, как sysctl настраивает систему, ну и собственно поэтому последний не может его настроить.
Отсюда делаем вывод, что надо nf_conntrack загружать ДО того как sysctl начнёт настраивать.

Делается это через вот этот конфиг файл - /etc/modules-load.d/modules.conf:

Теперь после перезагрузки хост поднимается сразу с корректными параметрами conntrack.

Последнее, что нужно сделать - это отредактировать параметр hashsize для наших соединений. Собственно размер этого хеша, напрямую влияет на скорость поиска внутри и соответственно нагрузку на CPU. Есть рекомендация выставлять размер hashsize в соответствии с правилом max_conntrack/8, что в моём случае равняется 524288.

Для этого выставляем нужное значение в файле /sys/module/nf_conntrack/parameters/hashsize

Всё, теперь система спокойно переживёт ребут и сможет единомоментно устанавливать до 4млн сессий.

Немного ссылок:
https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt
https://manpages.debian.org/unstable/conntrackd/conntrackd.conf.5.en.html

Подписаться на канал (https://t.me/like_a_bus_channel) ⭐️

Рассказ будет про моё заключительное дежурство в 2025 году, и выпало оно ровно на 30 декабря!

Началось всё с того, что в какой-то момент времени, коробка начала сыпать вот такое в лог:

Ну ошибка и ошибка. Влияния никакого нет, по крайней мере мы его не наблюдаем. На всякий посмотрели все текущие сессии BFD – с ними порядок. Проверили всякие параметры, CPU, RAM, FIB/RIB – тоже ок.

Ладно, вроде ничего страшного не происходит, но хочется же всё-таки разобраться из-за чего такая штука возникает. Посовещались с коллегами и сообща поняли, что ошибку генерит не просто BFD, а наиболее вероятен сценарий, когда свич ждёт single-hop, а ему прилетает пакет с откусанным TTL, т.е. 253 вместо 255 (HopLimit – это и есть TTL в IPv6).

Так-так-так. Получается, если коммутатор начинает расценивать данный пакет как multihop, то поднимает его на CPU, где отбрасывает и генерит сообщение нам в лог.

Отлично, осталось теперь найти того, кто может такое посылать.

Пошли смотреть в лог и нашли время, когда впервые появилось это сообщение в логе. Ничего другого рядом не было. Ни новых нейборов, ни флапов портов, ничего. Выходит какой-то триггер был не тут, а где-то на внешнем участке.

Ладно, следующим шагом поиска отправителя, является дамп трафика. Благо собрать его можно сразу на общем интерфейсе шине, который идёт в сторону CPU.

Делается это вот так:

Наверное стоит тут рассказать, что такое порт broadcom0, на котором мы собираем дамп. В моем понимании - это некий общий порт, в который сведены все физические интерфейсы и куда попадает весь входящий трафик, который идёт в сторону CPU.
То есть, свич получает BGP Update на интерфейсе ce1, он его перенаправляет в интерфейс broadcom0, или допустим он получает ARP - тоже самое, пакет уходит туда же. Аналогичная ситуация будет и с тем, если он получит BFD для multihop сессии.
При этом, если речь идёт про исходящий, то используется другой интерфейс - broadcom2.

Тут появляется небольшой нюанс, если попытаться открыть дамп трафика, который мы собрали, то там внутри будет абракадабра нечитабельная. Причина в том, что архитектура построена таким образом, что пакет дополнительно оборачивается в оверхед, который составляет размер в 100 байт.
Вы спросите зачем? Однозначного ответа у меня нет, но могу предположить, что делается это для того, чтобы разделять таким образом трафик, идущий от конкретного интерфейса и таким образом правильно его обработать, а затем отправить обратно.

В любом случае, мы знаем, что оверхед для входящего - это всегда ровно 100 байт. А значит, если мы их срежем, то получим наш чистый, незамутненный дамп. К слову, для исходящего оверхед уже другой - 48 байт.

Для этого у нас есть утилитка editcap:

Отлично, дамп получили, качаем его с коробки себе локально и открываем через wireshark.

Ок, сортируем по тому принципу, который обозначили выше, а именно - это IPv6, это BFD и у пакета HopLimit - 253, получаем вот такой фильтр - (bfd && ipv6) && (ipv6.hlim == 253).

Ура! Вот они, наши ожидаемые BFD, выходит мы оказались изначально правы, что лог генерится этими самыми сообщениями.

Теперь дело осталось за малым, понять кто же это всё-таки был и починить. Тут мы немного поковырялись с разными идеями и догадками, пока наконец не пришли к самой простой из имеющихся - посмотреть в наш Akvorado! Благо sFlow со всех коробок собирается.

Указали адреса источника и получателя в качестве фильтра и вуаля - виновник найден! Им оказался один из лифов. Отлично, пойдём туда и посмотрим, что же с ним не так...

Опа, а вот и любопытный лог, который совпадает минута в минуту со временем, когда у нас появилась ошибка. Выясняется, что это подключили новый сервер, который собственно и отправлял в сторону свича BFD, только вот destination адрес был неверно указан и свич его у себя не находил и посылал дальше по фабрике. Ну а там уже пакет доходил до коммутатора, где уже по счастливой случайности оказался тот самый destination адрес!

Т.е. окончательная цепочка выглядела вот так:

SRV —> LeafX --> Spine1 --> LeafY

Сообщили коллегам, которые занимаются серверами, они в свою очередь подтвердили, что действительно такое есть, тотчас поправили и ошибка пропала!