Будни сетевика

🩺 Network Doctor - TUI инструмент для анализа работы сети на разных уровнях. От многих подобных отличается подходом к проверке и выдаче результатов. Netdoc последовательно проверяет каждый этап подключения, фиксирует результат проверки каждого этапа и присваивает ему соответствующий статус. После диагностики утилита показывает на каком из этапов возникла проблема. https://github.com/heymaikol/network-doctor #tui #network #будничное

А еще у PTX дефолтные полисеры сильно меньше. Juniper ARP Policer on PTX Протокол | MX | QFX | PTX ---------|--------|-------|------ ARP | 20,000 | 500 | 500 NDPv6 | 20,000 | N/A | 500 ICMP | 20,000 | N/A | 500 BGP | 20,000 | 3,000 | 5,000 🎤 Будни сетевика 😊

Model: ptx10001-36mr Тестируем новую (для нас) железку от Juniper, ранее все маршрутизаторы были только MX серии. По архитектуре это совершенно разные устройства, что и объясняет их различия, но сегодня обращу внимание на работу Netflow, т.к. из-за этой особенности потребовалось вносить доработки в Uplink Load Balancer. Основное отличие в реализации Netflow на MX и PTX заключается в архитектуре обработки данных на уровне ASIC(чипсета). ▎Juniper MX Использует классический Flow Cache подход, когда пакет попадает в sampling, чипсет группирует пакеты в потоки непосредственно в аппаратном кеше, т.е. маршрутизатор внутри аггрегирует данные и отправляет их на Netflow-коллектор только при наступлении таймаутов (flow-active-timeout/flow-inactive-timeout). ▎Juniper PTX Каждый сэмпл - отдельный поток, т.е. каждый выбранный пакет мгновенно превращается в Netflow-запись и отправляется на коллектор. Для MX отображаются реальные значения Active Flows и таймеров, для PTX Active Flows и Flows Active Timed Out всегда равны 0. MX> show services accounting flow inline-jflow fpc-slot 0 Flow information FPC Slot: 0 Flow Packets: 2692382297, Flow Bytes: 3040860359420 Active Flows: 101908, Total Flows: 740827238 Flows Exported: 1744767364, Flow Packets Exported: 437229188 Flows Inactive Timed Out: 306581035, Flows Active Timed Out: 432142384 Total Flow Insert Count: 308684854 IPv4 Flows: IPv4 Flow Packets: 2692382297, IPv4 Flow Bytes: 3040860359420 IPv4 Active Flows: 101908, IPv4 Total Flows: 740827238 IPv4 Flows Exported: 1744767364, IPv4 Flow Packets exported: 437229188 IPv4 Flows Inactive Timed Out: 306581035, IPv4 Flows Active Timed Out: 432142384 IPv4 Flow Insert Count: 308684854 PTX> show services accounting flow inline-jflow fpc-slot 0 Flow information FPC Slot: 0 Flow Packets: 9809092522, Flow Bytes: 14372434625376 Active Flows: 0, Total Flows: 9809092522 Flows Exported: 37824750222, Flow Packets Exported: 1804568425 Flows Inactive Timed Out: 9809092005, Flows Active Timed Out: 0 IPv4 Flows: IPv4 Flow Packets: 9809092522, IPv4 Flow Bytes: 14372434625376 IPv4 Active Flows: 0, IPv4 Total Flows: 9809092522 IPv4 Flows Exported: 37824750222 IPv4 Flows Inactive Timed Out: 9809092005, IPv4 Flows Active Timed Out: 0 На скрине количество Netflow-сообщений, которые коллектор получает от MX и PTX примерно при равном количестве трафика на маршрутизаторах и input rate 1024, т.е. сэмплируется 1 пакет из 1024. 🎤 Будни сетевика 😊

Много каналов про сетевиков не бывает, поэтому сегодня рекомендация группы @Networks_anyone и канала @Network_history_NFA. В группе очень залипательны «Турниры по администрированию» (вопросы не сложные), а в канале публикуют небольшие сетевые заметки и квизы. 🎤 Будни сетевика 😊

Заставляем Pulumi летать: тюнинг параллельности и in‑memory кэширование для VMware Cloud Director Коллега (DevOps) рассказывает про перевод управления VMware Cloud Director на Pulumi и поиск узких мест для ускорения его(IaC’a) работы. 🎤 Будни сетевика 😊

Я опять взялся за старое и в рамках подготовки к полугодовому Performance Review сделал шуточное видео про разницу грейдов. P.S. Во время съемок никто не пострадал. 🎤 Будни сетевика 😊

Demystifying Multi-Tier Gateways in VMware NSX Техническое руководство по архитектуре маршрутизации в VMware NSX, а именно по multi-tier топологии - как работают логические маршрутизаторы, как пакеты проходят через разные компоненты и как это можно диагностировать. Пригодится, если придется дебажить проблемы в NSX. 🎤 Будни сетевика 😊

"Обезопасили" префиксы нашей ASN 211609 средствами RPKI У себя тоже настроили фильтрацию. RPKI (Resource Public Key Infrastructure) - это система безопасности для защиты маршрутизации в Интернете от подмены origin-AS (hijacking). ▎Как это работает 1. Regional Internet Registries (RIPE, ARIN, APNIC и др.) выдают криптографические сертификаты владельцам IP-блоков. 2. Владелец IP-блоков, желающий защитить свои префиксы, создает ROA-запись (Route Origin Authorization), в которой указывает, какая именно автономная система (ASN) имеет право анонсировать конкретный префикс, и подписывает её своим приватным ключом. Пример ROA: Prefix: 178.18.217.0/24 Max Length: 24 Origin AS: AS211609 3. Все ROA публикуются в RPKI-репозиториях (глобальных хранилищах). 4. Специальный сервер(RPKI Validator) загружает все ROA со всего мира, проверяет их криптографические подписи и сроки действия сертификатов. Из всего, что правильно подписано и не просрочено формирует VRP (Validated ROA Payload). 5. Маршрутизаторы получают VRP через протокол RTR (RPKI-to-Router), при получении BGP update проверяется соответствие origin AS и префикса и в случае несоотвествия такой префикс отбрасывается (но в зависимости от настроек это может быть просто предупреждение в логах). Маршрутизаторы не умеют сами проверять сложные цепочки сертификатов, именно поэтому они получают от валидаторов уже готовые списки (VRP). Так выглядит VRP на Juniper MX: >show validation database Prefix Origin-AS Session State 1.0.0.0/24-24 13335 10.1.47.36 valid 1.0.0.0/24-24 13335 10.1.47.37 valid 1.0.0.0/24-24 13335 10.77.19.36 valid 🎤 Будни сетевика 😊

Next-generation LLM Inference Network: How ZCube Alleviates Network Bottlenecks? Коллега подкинул свежую статью про сети для LLM. Китайские инженеры из Z.ai, Harnets.AI и университета Цинхуа разработали новую архитектуру ZCube, в которой заменили классический Clos на плоскую топологию и получили: • Экономия: Минус 33% на коммутаторах и оптике. • Скорость: +15% пропускной способности инференса. • Задержка: TTFT (Time to First Token) снизился на 40.6% (P99). ▎В чем магия (коротко) Раньше в ROFT (Rail-Optimized Fat-Tree) трафик KV Cache шел асимметрично, перегружая одни и те же Leaf-коммутаторы. Возникали локальные «заторы» и PFC-паузы. ZCube просто убирает уровень Spine-коммутаторов и использует гибрид single-rail / multi-rail подключения. Диаметр сети - 2 хопа, а балансировка нагрузки практически идеальная. В проде работает уже больше двух недель. Подробней с красивыми схемами - по ссылке выше. 🎤 Будни сетевика 😊

Тут писал про Capirca - Multi-platform ACL generation system. Теперь рассказываю про ее форк - Aerleon. ▎Что нового? 1. Три формата описания правил • Классический Capirca policy • YAML (удобнее на мой взгляд + легко валидировать через yamllint) • Python native 2. Появилось API • aclgen для генерации ACL • aclcheck для проверки • cgrep для поиска различной инфы по политикам 3. Один файл политики на несколько платформ/вендоров • Можно генерировать ACL сразу под разные платформы из одной политики 4. Плагины • Поддержку новых вендоров/платформ можно добавлять через плагины, а не изменяя основной код Capirca 5. Гибкие источники данных • Вместо .net и .svc в Capirca появились Json, CSV, FQDN и возможность подключить к IPAM. 6. Конвертер pol2yaml • Помогает переехать с Capirca на YAML-формат Aerleon. 7. Документация • https://aerleon.readthedocs.io/en/latest/ Capirca - отличный инструмент, который в свое время закрыл большинство наших задач по ACL. Но её главная проблема была в сложности интеграции с другими системами и инструментами. У Aerleon для этого есть всё. И бонус - история названия: What Does Aerleon Mean? Aerleon is a fork of the Capirca project, which was originally intended to be named after the planet Caprica from Battlestar Galactica. Unfortunately, there was a typo error in the initial release of the project to the public. In recognition of the project's origins, we have chosen a different planet from Battlestar Galactica and made a slight alteration to its spelling, as a respectful nod to the source of this fork. P.S. Будем планировать переезд с Capirca на Aerleon. 🎤 Будни сетевика 😊

Поступает традиционный частый вопрос про линкмитап – до какого дня идёт приём докладов? Отвечаем всё так же традиционным ответом – у нас нет фиксированной даты. Мы считаем, что инициативу надо поощрять, поэтому, если к нам приходят с хорошим докладом, мы не маринуем его автора в неизвестности, а сразу берём. И вот, кстати, первый доклад есть. Уже несколько раз выступавший у нас знаток сетей для тяжёлого медиаконтента Дмитрий Ипатов из Окко снова в деле и выступит с докладом о том, как они разработали свой балансировщик аплинков. Программу будем собирать тут – https://linkmeetup.ru/neindoklady Билет покупать здесь – https://linkmeetup.ru/#tickets

inspect-cert-chain - утилита для просмотра цепочки сертификатов. Удобно, не нужно возиться с командами OpenSSL. 🎤 Будни сетевика 😊

DUO мы не используем, но при обновлении на 23 версию Junos поймали аналогичную ошибку на keycloak-radius-plugin. Воркэраунды рабочие. P.S. Без подключения к виртуальной частной сети страничка не откроется. 🎤 Будни сетевика 😊

🔥 Инфраструктура в фокусе - митап от OkkoTechTeam! Если вы работаете с инфраструктурой, DevOps, reliability или просто хотите глубже разобраться в современных инфраструктурных практиках - ждём вас на вечернем митапе с докладами, живым общением и нетворкингом с видом на Финский залив. В программе: 🛠 Сергей Небошинский (Okko) Как внедрить Infrastructure as Code для VMware Cloud Director с помощью Pulumi: зачем уходить от «кликов», как строить переиспользуемые модули, работать с VCD-провайдером и поддерживать IaC в production. 📊 Андрей Синицын (Звук) Почему большинство дашбордов бесполезны и как сделать так, чтобы они действительно отвечали на вопросы, а не просто показывали графики. Практика, примеры и чеклист. 🔐 Александр Скоков (Okko) Безопасное проксирование HTTPS-трафика: TLS termination, inspection, контроль доступа, логирование и защита внутренних сервисов. Архитектура, типовые ошибки и production-практики. Приходите сами и зовите коллег - будет много практики, обсуждений и полезных знакомств. Будет полезно: - DevOps и SRE-инженерам - Backend-разработчикам - Инфраструктурным инженерам Всем, кто строит и поддерживает production-системы. 📍 Offline + online-трансляция 🪪 Для прохода в офис нужен паспорт Регистрация по ссылке. До встречи на митапе🙌🏼

Еще один митап. Спикеры - мои коллеги, занимающиеся инфраструктурой, должно быть интересно/полезно. Оффлайн СПб, Савушкина 126 + онлайн-трансляция. 21 мая, 18:30

Всем привет! У нас тут пятый митап намечается, на этот раз в Москве. Для тех кто никогда не был, вот вам короткое саммари зачем вам туда идти: - встретиться и пообщаться с вашими друзьями, коллегами, знакомыми, ну или найти новых); - послушать буквально тройку технических докладов (детали ищите тут) и за пивом/пиццей/колой обсудить зачем, как и почему; - принять участие в КВИЗе и выиграть сумасшедшие призы (они у нас за первые три места); - забрать мерч, в этот раз помимо всякого, мы придумали для вас липучки-стяжки, собственно они на фото выше. Регистрация: https://forms.gle/GBAyKCv5yRnHWAS48 Подписаться на канал 🍻

На днях попалась Рецензия на книгу «Сети Linux. Модели и приложения». Заказал тут, за пару дней доехала до ближайшего ПВЗ, сегодня забрал. Решил почитать какую-нибудь профессиональную литературу «держа ее в руках», как раньше, помните? Пока не прочитал, рекомендовать не буду, но по рецензии, кмк, можно определиться. 🎤 Будни сетевика 😊

Кто я такой, чтобы отучившись 5 лет по специальности «Сети связи» не написать про профессиональный праздник работников отрасли связи - День радио! В честь праздника рекомендую прочитать труд от «До нас дошло» про историю телеграфа. https://habr.com/ru/articles/1031792/

Juniper MX SNMP DDoS protection configuration В Junos OS Release 22.3R1 уменьшили значение дефолтного полисера для SNMP в 200 раз: Enhanced bandwidth and burst policer value (MX Series and EX9200 Series)—We've updated the default bandwidth value from 20000 to 100 pps and burst policer value from 20000 to 100 packets for SNMP traffic. Намерения вроде были благие: This enhancement avoids the CPU usage of eventd and snmpd reaching more than 100%. Earlier to this release, when the system receives a violated traffic for SNMP along with other protocols traffic, the CPU usage of eventd and snmpd was reaching more than 100% with an error. Мы такого поведения не замечали, видимо нам везло 🤷 После обновления закономерно можно начать ловить различные ошибки, связанные с SNMP - провалы на графиках по некоторым item и таймауты в логах системы мониторинга. Проверяем счетчики: > show ddos-protection protocols snmp Protocol Group: SNMP Aggregate policer configuration: Bandwidth: 100 pps Burst: 100 packets System-wide information: Received: 5964285 Arrival rate: 0 pps Dropped: 723 Max arrival rate: 100 pps Видно, что упираемся в полисер 100 pps и есть Dropped: 723. Max arrival rate, кстати, не будет показывать значение выше установленного полисера, т.е. 100 в нашем случае. Вернуть все взад можно командами: set system ddos-protection protocols snmp aggregate bandwidth 2000 set system ddos-protection protocols snmp aggregate burst 2000 Проверка > show ddos-protection protocols snmp * = User configured value Protocol Group: SNMP Aggregate policer configuration: Bandwidth: 2000 pps* Burst: 2000 packets* Максимальный pps, который видел у нас - Max arrival rate: 1022 pps, поэтому 20K, которые раньше были по дефолту возможно и многовато. Да и 1022 pss так-то много для одной системы мониторинга, но в нашем случае по факту их было три - Zabbix, Observium (побаловаться) и доп внутренняя система. P.S. Если Juniper надоел, вы скажите - напишу про … Eltex? 🙂 🎤 Будни сетевика 😊