Новая рубрика - вопрос от подписчика:

Подскажите, по своей практике какие средние задержки между могут возникать между ДЦ в рамках города Москвы? или может вы уже писали на подобную тему?

Условно есть задача развернуть различные сервисы (kubernetes, kafka и тп) в рамках нескольких ДЦ для отказоустойчивости. вот интересно каки средние показатели сети, как проходит долго условно ping и тп.

я не сетевой инженер, но интересно было бы почитать, чтобы понимать какие есть нюансы.

Пробую ответить.

▎Точки замера
• Физические ЦОДы: Москва, Linxdatacenter, ул. 8 Марта, д.14, Москва, IXcellerate North, Алтуфьевское ш., д. 33Г, СПБ, Linxdatacenter, ул.Репищева 20А, СПБ, Dataline, ул. Жукова д.43

• Частные облака: Москва, DataPro-3, ул. Рябиновая 53, стр. 3, Москва, Ixcellerate Five, ул.Подольских Курсантов, д. 15Б

• Публичные облака: Москва, DataPro I, ул. Авиамоторная, 69, Москва, DataPro II, 74 км МКАД, вл. 3

• Наши отдельно стоящие сетевые железки: Москва (M9).

▎Существующая связность
• Между всеми физическими ЦОДами - провайдерский L2VPN, поверх него натянут DCI на базе EVPN
• Между ЦОДами в СПб дополнительно помимо L2VPN есть темные волокна, собственно замеры через них
• Выделенные каналы (сервис Direct Connect) из ЦОДов Linxdatacenter (Мск/СПб) в публичные/частные облака

▎Как читать таблицу
• Строка - откуда запускался ping
• Столбец - куда запускался ping
• Значение - задержка (RTT) в миллисекундах

▎Итоги
Между всеми ЦОДами в Москве (в том числе между облачными) RTT от 1 до 2ms, между СПб и МСК 8-9ms (через провайдерский L2VPN). В других облаках и/или физ ЦОДах МСК/СПБ значения должны быть того же порядка.

Стоит учитывать, что в облачную инфраструктуру из физического ЦОДа просто так не попадешь. Как связать on-prem (физ ЦОД) с облачной инфраструктурой писал тут:
Часть 1 | Часть 2 | Часть 3

Были планы еще на Часть 4, но она осталась в черновиках, планировал поискать инфы про РФ облака и доступные сетевые сервисы по подключению к ним.

В комменты кину табличку в Excel.

🎤 Будни сетевика 😊 #Вопрос

List of Network Simulators and Emulators

Навигатор по opensource-инструментам для эмуляции и симуляции сетей, к большинству из них есть практические руководства от автора.

Разделены по категориям:
• Для инженеров: GNS3, EVE-NG, Containerlab, CORE.
• Для разработчиков и DevOps: Mininet, Kathara, ns-3, Netlab.
• Для беспроводных и IoT-сетей: Cooja (Contiki), Colosseum, Mininet-WiFi.
• Для обучения: Filius, Educational Network Simulator.

Про некоторые я услышал впервые.
В комментариях по ссылке можно найти попытку объяснить разницу между симуляторами и эмуляторами - в принципе так я на этот блог и вышел 🙂

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

Топ-10 инструментов для управления лог-файлами в 2026 году

Отдельно планирую рассказать, как у нас устроен сбор и анализ логов сетевых железок.

И было бы интересно послушать, кто что использует у себя в инфре.

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

Со всей ответственностью заявляю, что если вы планируете развернуть EVPN/VXLAN IP Fabric на Juniper (или фабрика уже у вас есть), то лучше книги вам не найти. Мы постоянно используем её в качестве справочника.

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

Why content providers need IPv6

Автор объяснил, зачем нам (контент провайдеру) нужен IPv6.
Спасибо 🙂

Однако в планах на 2026 год пока что ничего про IPv6 замечено не было 🤷 Причины все те же, что я писал тут. Замкнутый круг - никто не смотрит киношки по IPv6, мы и не настраиваем, а возможно никто не смотрит, потому что мы не настроили.

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

Задача: в алертах от zabbix при падении BGP-сессий с провайдерами видеть их имена, а не только IP-адреса

Пример того, что хотелось:

router_name: PROVIDER_NAME@IP_ADDRESS is DOWN

На тот момент у нас во всех ЦОДах в качестве бордеров были Cisco ASR9001.

Через SNMP нельзя вытащить имена провайдеров, которые вы настроили в конфигурации маршрутизатора - в BGP-MIB просто нет объекта с description пира. Соотвественно алерты будут приходить на падение BGP-сессий с указанием только IP-адресов. Необходимо было добавить как раз понятные имена провайдеров, чтобы сразу по алерту было видно с кем упала сессия и надо ли действовать ASAP или подождет. Это были попытки облегчить себе жизнь в период, когда еще не было выделенных спецов для мониторинга инф-ры 24/7. Сейчас спецы появились, но все уже привыкли к удобным именам.

Был изобретен следующий велосипед.

1️⃣ Создаем файлик router.peers, в котором указываем соотвествие IP-адреса BGP-пира из конфигурации маршрутизатора и имени. Формат JSON:

{
"router1": {
"NAME_ISP1": ["172.17.11.12"],
"NAME_ISP2": ["172.17.11.13"],
"NAME_ISP3": ["172.17.11.14"]
},
"router2": {
"NAME_ISP1": ["172.17.11.22"],
"NAME_ISP2": ["172.17.11.23"],
"NAME_ISP3": ["172.17.11.24"]
}
}

2️⃣ Пишем скрипт bgp_peer_parser.py, который будет парсить этот файлик:

#!/usr/bin/python3
import json, sys

path = '/etc/zabbix/set/router.peers'
method = str(sys.argv[1])
mx = str(sys.argv[2])

if method == 'discovery':
with open(path, 'r') as f:
data = f.read()
try:
data = json.loads(data)
except:
print(‘Problem with JSON’)
sys.exit(1)
try:
discovery = {}
discovery["data"] = []
for each in data[mx]:
for ip in data[mx][each]:
peer = {"{#PEER_NAME}":str(each),"{#PEER_IP}":str(ip)}
discovery['data'].append(peer)
discovery = json.dumps(discovery)
print(discovery)
except:
print(‘0’)
sys.exit(1)

3️⃣ Копируем скрипт на хост и в конфиге zabbix_agent хоста, на котором будет выполняться скрипт указываем:

UserParameter=router[*],/etc/zabbix/externalscripts/bgp_peer_parser.py $1 $2
где router - это имена ваших сетевых железок в zabbix.

Можно выполнять с самого zabbix-сервер.

Приложил в комменты шаблон для zabbix с созданными Disccovery Rules, где отслеживаются состояние BGP-сессий и два триггера на Admin Down и Down.

Получатся вот такие алерты:

Router1
High: NAME_ISP1@172.17.11.12 is DOWN
Operational data: Active (3), 2, Hold Timer Expired (1024)

Недостатки очевидны:
• Нужно следить за актуальностью файлика маппинга IP в Name и менять руками
• Нужно следить, чтобы никто не сломал структуру файла, например не пропустил запятую, потому что узнаете вы об этом уже позже, когда заббикс поругается и новые алерты не будут работать. В нашем случае, т.к. файлик лежал в репозитории, то включили проверку на файл в репе - если сломал, то не сможешь смержить изменения.

Плюсы:
• Универсальное решение для любого вендора. Когда мы переезжали с Cisco ASR на Juniper MX ничего менять не пришлось.

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

Проверил, на текущей версии Junos в MIB ничего похожего на BGP peer description не появилось 🤷

🎤 Будни сетевика 😊 #Задача

Сеть, с которой всё начинается: как устроен Underlay в MWS Cloud Platform

Статья от автора канала Заметки сетевого архитектора - Романа Помазанова.

Стоит читать, если вам интересно про:

В этой статье я подробно расскажу об Underlay-сети — том самом физическом фундаменте нового облака MWS. Мы разберём, почему мы приняли стратегическое решение спроектировать её с чистого листа, отказавшись от следования традиционным, зачастую излишне сложным вендорским подходам. Поговорим о принципах, которые легли в основу архитектуры: простоте, отказоустойчивости и масштабируемости. И наконец, заглянем «под капот»: посмотрим на leaf-spine фабрику, на протоколы BGP и IPv6, которые стали её нервной системой, и на то, как мы управляем этой сложной распределённой системой с помощью автоматизации и мониторинга.

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

https://github.com/qzeleza/kvas/

Проверил на домашнем Keenetic Extra (KN-1711) v4.3.6.3 - в первом приближении работает, на сколько стабильно посмотрим дальше.

Данное решение использую для доступа к разрешенным ресурсам, заблокированных по инициативе иностранных компаний (например, ChatGPT, GitHub) 😉

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

Netflix Live Origin

Техническая статья инженеров Netflix о том, как устроен их Live Origin - собственный origin server для облачного стриминга Live-трансляций.

Основные моменты:

🔍Live Origin - это "брокер", который находится между облачными pipeline'ами (которые готовят видео) и собственным CDN Netflix (Open Connect). Он решает, какой контент и как отправить зрителям и может работать с двумя pipeline'ами одновременно. Если в одном из них появляется битый сегмент (кусочек видео), Origin автоматически выбирает целый сегмент из второго pipeline'а, чтобы зритель не заметил проблему.

🔍Пишут (без подробностей), что допилили кэширование в Nginx для Live до милисекундной точности (millisecond grain caching).

🔍Netflix отказался от использования стандартного S3 для Live, так как нужна была сверхвысокая доступность и низкая задержка. Сделали гибридное решение на базе Cassandra (для надежной записи) и EVCache (для быстрого чтения). Здесь им помог KeyValue Storage Abstraction (их внутренняя разработка) - некий промежуточный слой абстракции, который умеет «чанковать» большие видео сегменты и раскладывать их по Cassandra, если я правильно уловил суть.

🔍Есть автоматическое горизонтальное масштабирование Live Origin (EC2 в AWS), но т.к. не все ресурсы можно быстро увеличить, например пропускную способность каналов, то при высоких нагрузках приоритет отдается критическим для пользователя запросам, а те что напрямую на пользователя не влияют могут выполниться позже. Внедрили TTL-кэш опять же для снижения нагрузки в момент критических нагрузок. Также все запросы Live под нагрузкой приоритетней чем DVR (записи, перемотки).

🔍Live Origin умно кэширует ошибки (404), чтобы не долбить базу данных запросами несуществующих сегментов. Длительность сегментов постоянна (2 сек), поэтому CDN знает точное время их появления.

🔍Пиковая нагрузка в 65 млн была в 2024г во время боя Тайсона и Д. Пола - тут мое почтение.

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

Просто красивая картинка

Вверху перепутали местами подписи к Cooling Fans и Network Switches.

Тут вспомнился случай, когда пришли коммутаторы вместо Air Flow IN -> Air Flow OUT. Поставщик не предупредил, а мы не проверили и замонтажили как обычно. Но бдительные специалисты в ЦОД быстро нас вычислили с помощью тепловизора

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

How Container Filesystem Works: Building a Docker-like Container From Scratch

Tutorial: Как создать контейнер с помощью утилит Linux unshare, mount и pivot_root

Было интересно почитать о процессе, но сам я не пробовал это делать.

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