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

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

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

Cisco Secure Firewall Management Center Software Authentication Bypass Vulnerability

Понятно, что не стоит выставлять в Интернет то, чего там быть не должно, но иметь CVSS Score: 10.0 все равно неприятно. Кому актуально, наверно стоит обновиться 🙂

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

Сети в Kubernetes: руководство для сетевого инженера

Статья не даст полного понимания как работают сети в Kubernetes, скорее это справочник по основным подходам.

Интересно, как местами автор пытается провести параллели между сущностями из мира Kubernetes и сетями, например:

Service Mesh — это как развертывание IPS/IDS на каждом сегменте сети. Да, это дает полную видимость и контроль. Но это стоит ресурсов, и если у вас небольшая сеть — overhead не оправдан.

P.S. Скорее всего, статья была отформатирована с помощью нейронки, но тем не менее, мне понравилась.

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

Закрываем тему сетей в Kubernetes докой от Isovalent - Kubernetes Networking and Cilium An Instruction Manual for the Network Engineer. Она уже публиковалась в различных каналах, креплю на случай, если кто пропустил.

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

Network Performance in the Linux Kernel, Getting the most out of the Hardware

Доклад и презентация от Bootlin.

Доклад про то, как организована высокопроизводительная работа с сетью в ядре Linux. Автор объясняет, как пакет проходит через систему (от патчкорда до приложения) и какие есть механизмы, чтобы эффективно использовать многоядерные процессоры.

▎Что отметил (без какой-то структуры)

Верхнеуровнего про путь пакета

Пакет попадает в NIC, далее MAC-контроллер с помощью DMA записывает его в оперативную память, не нагружая CPU. После записи данных NIC посылает сигнал (IRQ), чтобы сообщить CPU о новом пакете. Есть NAPI - современный механизм, который отключает прерывания на время обработки пачки пакетов. Вместо одного прерывания на пакет, ядро обрабатывает их пачками, что снижает нагрузку на CPU.

Описываются механизмы

🟢 RSS (Receive Side Scaling): Аппаратный механизм. Сетевая карта сама хэширует заголовки пакета (5-tuple) и на основе хэша раскладывает их по разным очередям. Каждая очередь привязана к своему ядру CPU.

🟢RPS (Receive Packet Steering): То же, что и RSS, но программно в ядре. Полезно, если у сетевой карты мало очередей.

🟢RFS (Receive Flow Steering): Улучшение RPS. Следит за тем, на каком ядре работает приложение и направляет пакеты именно на это ядро для попадания в кэш.

🟢XPS (Transmit Packet Steering): То же самое, но для отправки пакетов, чтобы очередь на отправку была привязана к нужному ядру.

🟢Механизмы Offloading: Чтобы ядро делало меньше работы, часть задач перекладывается на сетевую карту:

- Checksum: Проверка целостности заголовков сетевой картой на лету, ядро оставляет поля пустыми

- Filtering: Аппаратная фильтрация до того, как они попадут в ядро. Приводятся примеры MAC и VLAN filtering.

🟢Data insertion and segmentation: Сетевая карта может добавлять VLAN-теги на лету

🟢TSO (TCP Segmentation Offload): Сетевая карта сама нарезает большие куски данных на мелкие TCP-сегменты. Хорошее описание как это работает тут.

🟢XDP (eXpress Data Path): Самый быстрый путь обработки. BPF выполняется прямо в драйвере сетевой карты, как только пакет появился в памяти. Это позволяет дропать или перенаправлять пакеты с большой скоростью, до того как ядро начнет их полноценно обрабатывать.

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