Forwarded from linkmeup
Думаю не ошибусь, если скажу что на минувшем линкмитапе это был самый срачеобразующий доклад. Прям начиная с темы и так до упора.
Собственно, Дмитрий Ипатов и его рассказ о том как подготовиться к масштабной трансляции, насобирать разного, попробовать удивительного и выйти из ситуации победителем, на примере организации трансляции Евро24.
https://youtu.be/WJHBkAXhyW4
Собственно, Дмитрий Ипатов и его рассказ о том как подготовиться к масштабной трансляции, насобирать разного, попробовать удивительного и выйти из ситуации победителем, на примере организации трансляции Евро24.
https://youtu.be/WJHBkAXhyW4
YouTube
Как мы в Окко готовились транслировать Евро24. Дмитрий Ипатов
В прошлом году Okko транслировал Евро24. Подготовка и проведение события такого масштаба — это настоящий вызов как для инфраструктуры, так и для команды.
В своем докладе я расскажу о сложностях, с которыми мы столкнулись на разных этапах, о том, как адаптировались…
В своем докладе я расскажу о сложностях, с которыми мы столкнулись на разных этапах, о том, как адаптировались…
🔥21👏6 4🏆2❤1
Сегодня стартовала оффлайн часть ключевой отраслевой конференции по технологиям видео VideoTech 2025
СПб, 7-8 октября.
Отличная возможность обменяться опытом, рад буду пообщаться.
🎤 Будни сетевика 😊
СПб, 7-8 октября.
Отличная возможность обменяться опытом, рад буду пообщаться.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15
VideoTech 2025.pdf
4.5 MB
Время у меня было ограничено, и мне удалось послушать только четыре доклада:
1. Кирилл Медведев «DPDK в медиасерверах: снижение задержек и повышение пропускной способности».
Доклад был посвящён тому, почему традиционный сетевой стек Linux становится узким местом и как DPDK может помочь решить эту проблему. Кирилл рассказал об архитектуре DPDK, о недостатках классического стека Linux и о том, как DPDK их преодолевает. В целом, обсуждение свелось к интеграции DPDK и Nginx, разработанной в Selectel и в настоящее время доступной только в составе SelectelOS - Fginx. Отдельное спасибо за ссылку на статью "The Path of a Packet Through the Linux Kernel", которая описывает путь пакета в стеке Linux. Думаю, позже сделаю краткий обзор этой статьи.
2. Иван Бурцев «Скоростной и дешевый HW-транскодинг из подручных материалов».
Это история о том, как инженеры собрали железный транскодер себестоимостью 120 тысяч рублей в свободное от работы время. Иван немного рассказал о теории кодеров и декодеров, а также о производителях (Nvidia, Intel и др.) и причинах высокой стоимости готовых решений. В основе доклада была история как они выбирали все компоненты, где их брали и как собирали. В конце Иван показал их решение вживу, можно было пощупать.
Однако ни один ЦОД не пропустил их с этой железкой - где сертификация? Ждем новую историю.
3. Кирилл Шваков «CDN Кинескоп: к чему мы пришли через 6 лет».
Доклад был о устройстве CDN Kinescope, где обсуждались аппаратные компоненты серверов и программное обеспечение в их CDN. Интересно, что коллеги решили отказаться от стандартного решения на основе Nginx в пользу собственного, написанного на Go. Также они продолжают использовать HDD наряду с SSD для хранения "холодных" файлов, которые давно никто не смотрел. Обсуждали проблемы шардирования I/O на HDD и работу с большими файлами.
P.S. Они умеют раздавать более 100 Гбит/с с одной ноды, но это уже давно никого не удивляет 🙂
4. Александр Алексеев «Глубокое погружение в Forward Error Correction для WebRTC».
Доклад содержал много информации о математических моделях сетевых потерь, способах определения параметров FEC и интеграции с механизмами управления перегрузками (Congestion Control). Я не был целевой аудиторией для этого доклада, поэтому было сложно слушать, но разработчикам это точно будет интересно.
От автора доклада:
Когда стоит применять FEC
▶ В сетях с потерями и высоким RTT.
▶ При потерях, не вызванных перегрузкой канала собственным трафиком.
▶ Для сетевого бустинга.
Доклады - это хорошо, но самое интересное - пообщаться со спикерами после выступлений, где можно задать любые вопросы. Собственно, для этого я и хожу на конференции.
Креплю презы с выступлений.
🎤 Будни сетевика 😊
1. Кирилл Медведев «DPDK в медиасерверах: снижение задержек и повышение пропускной способности».
Доклад был посвящён тому, почему традиционный сетевой стек Linux становится узким местом и как DPDK может помочь решить эту проблему. Кирилл рассказал об архитектуре DPDK, о недостатках классического стека Linux и о том, как DPDK их преодолевает. В целом, обсуждение свелось к интеграции DPDK и Nginx, разработанной в Selectel и в настоящее время доступной только в составе SelectelOS - Fginx. Отдельное спасибо за ссылку на статью "The Path of a Packet Through the Linux Kernel", которая описывает путь пакета в стеке Linux. Думаю, позже сделаю краткий обзор этой статьи.
2. Иван Бурцев «Скоростной и дешевый HW-транскодинг из подручных материалов».
Это история о том, как инженеры собрали железный транскодер себестоимостью 120 тысяч рублей в свободное от работы время. Иван немного рассказал о теории кодеров и декодеров, а также о производителях (Nvidia, Intel и др.) и причинах высокой стоимости готовых решений. В основе доклада была история как они выбирали все компоненты, где их брали и как собирали. В конце Иван показал их решение вживу, можно было пощупать.
Однако ни один ЦОД не пропустил их с этой железкой - где сертификация? Ждем новую историю.
3. Кирилл Шваков «CDN Кинескоп: к чему мы пришли через 6 лет».
Доклад был о устройстве CDN Kinescope, где обсуждались аппаратные компоненты серверов и программное обеспечение в их CDN. Интересно, что коллеги решили отказаться от стандартного решения на основе Nginx в пользу собственного, написанного на Go. Также они продолжают использовать HDD наряду с SSD для хранения "холодных" файлов, которые давно никто не смотрел. Обсуждали проблемы шардирования I/O на HDD и работу с большими файлами.
P.S. Они умеют раздавать более 100 Гбит/с с одной ноды, но это уже давно никого не удивляет 🙂
4. Александр Алексеев «Глубокое погружение в Forward Error Correction для WebRTC».
Доклад содержал много информации о математических моделях сетевых потерь, способах определения параметров FEC и интеграции с механизмами управления перегрузками (Congestion Control). Я не был целевой аудиторией для этого доклада, поэтому было сложно слушать, но разработчикам это точно будет интересно.
От автора доклада:
Когда стоит применять FEC
▶ В сетях с потерями и высоким RTT.
▶ При потерях, не вызванных перегрузкой канала собственным трафиком.
▶ Для сетевого бустинга.
Доклады - это хорошо, но самое интересное - пообщаться со спикерами после выступлений, где можно задать любые вопросы. Собственно, для этого я и хожу на конференции.
Креплю презы с выступлений.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍23❤7🔥4
Продолжаем и заканчиваем историю про VRF в Linux.
Статистика по интерфейсу vrf-mgmt будет выглядеть так:
Необычно здесь то, что счетчик RX увеличивается, а TX - нет.
Сразу отметим, что в отличии от физических интерфейсов (eth0, eth1), интерфейс vrf-mgmt - виртуальный.
Почему так происходит.
▎Входящий трафик (RX)
1️⃣ Пакет приходит на интерфейс eth0, который привязан к VRF
2️⃣ Пакет попадает на интерфейс vrf-mgmt для маршрутизации
3️⃣ Увеличается счетчик RX, потому что пакет проходит через vrf-mgmt
4️⃣ Определяется получать и пакет отправляется приложению или другому хосту
▎Исходящий трафик (TX)
1️⃣ Приложение формирует пакет и отправляет его через VRF
2️⃣ FIB lookup в VRF - пакет должен уйти через eth0, при этом сам пакет VRF не обрабатывает (TX счетчик VRF не изменяется)
3️⃣ Пакет передается напрямую на eth0
4️⃣ И вот уже здесь TX счетчик eth0 увеличивается
Получается такая картина:
🎤 Будни сетевика 😊
Статистика по интерфейсу vrf-mgmt будет выглядеть так:
vrf-mgmt: flags=1217<UP,RUNNING,NOARP,MASTER> mtu 65575
ether 22:20:a7:a8:7f:f8 txqueuelen 1000 (Ethernet)
RX packets 36707747 bytes 26433447694 (26.4 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Необычно здесь то, что счетчик RX увеличивается, а TX - нет.
Сразу отметим, что в отличии от физических интерфейсов (eth0, eth1), интерфейс vrf-mgmt - виртуальный.
Почему так происходит.
▎Входящий трафик (RX)
1️⃣ Пакет приходит на интерфейс eth0, который привязан к VRF
2️⃣ Пакет попадает на интерфейс vrf-mgmt для маршрутизации
3️⃣ Увеличается счетчик RX, потому что пакет проходит через vrf-mgmt
4️⃣ Определяется получать и пакет отправляется приложению или другому хосту
▎Исходящий трафик (TX)
1️⃣ Приложение формирует пакет и отправляет его через VRF
2️⃣ FIB lookup в VRF - пакет должен уйти через eth0, при этом сам пакет VRF не обрабатывает (TX счетчик VRF не изменяется)
3️⃣ Пакет передается напрямую на eth0
4️⃣ И вот уже здесь TX счетчик eth0 увеличивается
Получается такая картина:
### Входящий трафик ###
[Сеть] → [eth0] → [VRF] → [Приложение]
↑
RX счетчик увеличивается здесь
### Исходящий трафик ###
[Приложение] → [VRF] → [eth0] → [Сеть]
↑
TX счетчик увеличивается здесь
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15👍6
bird_without_vrf.rtf
1.9 KB
Не получилось закончить историю с VRF в Linux.
В другом сценарии возникла необходимость поднять BGP с помощью Bird внутри VRF. Почему именно Bird, а не что-то другое? Все просто: он уже использовался на хосте. Скажем, что так исторически сложилось.
Для начала необходимо включить параметр l3mdev, чтобы Bird мог работать с интерфейсом внутри VRF:
Далее нужно адаптировать конфигурацию Bird для работы с VRF. В BGP анонсировались IP-адреса, назначенные на loopback, и эту схему необходимо было сохранить.
Вот изменения, которые были добавлены в конфигурацию Bird при запуске внутри VRF:
У меня никак не получилось заставить Bird увидеть префиксы, назначенные на loopback внутри VRF (я старался). Поэтому я просто перенес их на интерфейс vrf-prod. В этом случае Bird сразу же их увидит через protocol direct.
Прикладываю конфигурации: netplan, Bird без VRF и Bird с VRF.
🎤 Будни сетевика 😊
В другом сценарии возникла необходимость поднять BGP с помощью Bird внутри VRF. Почему именно Bird, а не что-то другое? Все просто: он уже использовался на хосте. Скажем, что так исторически сложилось.
Для начала необходимо включить параметр l3mdev, чтобы Bird мог работать с интерфейсом внутри VRF:
sysctl -w net.ipv4.tcp_l3mdev_accept=1
sysctl -w net.ipv4.udp_l3mdev_accept=1
Далее нужно адаптировать конфигурацию Bird для работы с VRF. В BGP анонсировались IP-адреса, назначенные на loopback, и эту схему необходимо было сохранить.
Вот изменения, которые были добавлены в конфигурацию Bird при запуске внутри VRF:
router id 169.254.69.11;
protocol device {
vrf "vrf-prod"; # <- добавить VRF
scan time 20;
}
protocol bfd {
vrf "vrf-prod"; # <- добавить VRF
interface "*" {
interval 500 ms;
multiplier 3;
};
}
protocol kernel {
vrf "vrf-prod"; # <- добавить VRF
kernel table 101; # <- добавить таблицу
learn;
metric 64;
scan time 20;
import all;
graceful restart;
export filter {
krt_prefsrc = 169.254.69.11;
accept;
};
merge paths yes;
}
protocol direct {
interface "vrf-prod"; # <- добавить VRF вместо лупбека
}
####
filter export_to_peer {
if source = RTS_DEVICE then {
accept;
}
reject;
}
filter import_from_peer {
if source = RTS_BGP then {
accept;
}
reject;
}
####
protocol bgp PEER_1 {
vrf "vrf-prod"; #<- добавить VRF
local as 4240300609;
neighbor 169.254.69.12 as 4240300161;
direct;
bfd;
export filter export_to_peer;
import filter import_from_peer;
}
protocol bgp PEER_2 {
vrf "vrf-prod"; #<- добавить VRF
local as 4240300609;
neighbor 169.254.69.13 as 4240300161;
direct;
bfd;
export filter export_to_peer;
import filter import_from_peer;
}
У меня никак не получилось заставить Bird увидеть префиксы, назначенные на loopback внутри VRF (я старался). Поэтому я просто перенес их на интерфейс vrf-prod. В этом случае Bird сразу же их увидит через protocol direct.
Прикладываю конфигурации: netplan, Bird без VRF и Bird с VRF.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14🔥3😁1
Эмулятор компьютерной сети для образовательных целей на базе ОС Linux.
Наткнулся на интересный проект для изучения основ сети- https://github.com/mimi-net/miminet.
С помощью этого инструмента можно собирать простые топологии, эмулировать поведение сети, запускать команды с сетевых устройств и даже задавать процент потерь в канале между ними, есть возможность скачать pcap с интерфейсов. Выглядит круто, но функционал сильно ограничен. Проект изначально задумывался как образовательная платформа для вузов, и думаю, что со своей изначальной задачей он справляется на отлично.
Чтобы не разворачивать локально, можно поизучать версию в паблике - https://miminet.ru/
Есть свежее описание на Habr’e
P.S. Название получилось запоминающееся 😉
Наткнулся на интересный проект для изучения основ сети- https://github.com/mimi-net/miminet.
С помощью этого инструмента можно собирать простые топологии, эмулировать поведение сети, запускать команды с сетевых устройств и даже задавать процент потерь в канале между ними, есть возможность скачать pcap с интерфейсов. Выглядит круто, но функционал сильно ограничен. Проект изначально задумывался как образовательная платформа для вузов, и думаю, что со своей изначальной задачей он справляется на отлично.
Чтобы не разворачивать локально, можно поизучать версию в паблике - https://miminet.ru/
Есть свежее описание на Habr’e
P.S. Название получилось запоминающееся 😉
GitHub
GitHub - mimi-net/miminet: Cute network emulation web-app for self-education and classes (based on mininet).
Cute network emulation web-app for self-education and classes (based on mininet). - mimi-net/miminet
👍13
Задача: настроить коммутаторы Juniper QFX на отправку syslog over TLS
Такое потребовалось в одном изолированном контуре, где все должно быть максимально БЕЗОПАСНО 🔐
3 шага для настройки
🔑 Шаг 1: Установка сертификата
Тут два варианта.
1. Получить сертификат от вашего CA
Указываем URL для получения сертификата:
Получаем сертификат:
Сертификат будет автоматически сохранён и использован.
2. Скачать уже готовый сертификат на устройство (например, через SCP)
Далее загружаем сертификат:
Проверяем, что сертификат был загружен:
🔑 Шаг 2: Создание ca-группы и ca-профиля
🔑 Шаг 3: Настройка syslog с TLS
10.15.24.37 - Syslog-сервер
Можно проверять логи на Syslog-сервере.
Документация Juniper: Syslog over TLS.
🎤 Будни сетевика 😊 | #Задача
Такое потребовалось в одном изолированном контуре, где все должно быть максимально БЕЗОПАСНО 🔐
3 шага для настройки
🔑 Шаг 1: Установка сертификата
Тут два варианта.
1. Получить сертификат от вашего CA
Указываем URL для получения сертификата:
set security pki ca-profile tls-syslog enrollment url http://your-ca-server/certsrv
Получаем сертификат:
request security pki ca-certificate enroll ca-profile tls-syslog
Сертификат будет автоматически сохранён и использован.
2. Скачать уже готовый сертификат на устройство (например, через SCP)
Далее загружаем сертификат:
request security pki ca-certificate load ca-profile tls-syslog filename /var/tmp/cert_ca.pem
Проверяем, что сертификат был загружен:
show security pki ca-certificate
LSYS: root-logical-system
CA profile: tls-syslog
Certificate identifier: tls-syslog
Issued to: Okko CA Certificate, Issued by: C = RU, ST = Saint-Petersburg, O = Okko, OU = Technical Department, CN = Okko CA Certificate
Validity:
Not before: 09-11-2025 14:32 UTC
Not after: 09- 9-2035 14:32 UTC
Public key algorithm: ecdsaEncryption(384 bits)
Keypair Location: Keypair generated locally
🔑 Шаг 2: Создание ca-группы и ca-профиля
set security pki ca-profile tls-syslog ca-identity tls-syslog
set security pki ca-profile tls-syslog revocation-check disable
set security pki trusted-ca-group tlsdetails ca-profiles tls-syslog
🔑 Шаг 3: Настройка syslog с TLS
10.15.24.37 - Syslog-сервер
set system syslog host 10.15.24.37 any any
set system syslog host 10.15.24.37 interactive-commands any
set system syslog host 10.15.24.37 port 1515
set system syslog host 10.15.24.37 source-address 10.1.25.130
set system syslog host 10.15.24.37 transport tls
set system syslog host 10.15.24.37 tlsdetails trusted-ca-group tls-syslog ca-profiles tls-syslog
set system syslog host 10.15.24.37 structured-data
set system syslog file interactive-commands interactive-commands any
set system syslog file messages any any
set system syslog file messages authorization info
set system syslog source-address 10.15.25.130
Можно проверять логи на Syslog-сервере.
Документация Juniper: Syslog over TLS.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍23🔥3👀3
redhat best practises.pdf
8.7 MB
Уже многие писали, что Иван Пепельняк открыл доступ к своим вебинарам Ansible для сетевых инженеров.
Напишу и я, но дополню докой от RedHat - Ansible Best Practices.
🎤 Будни сетевика 😊
Напишу и я, но дополню докой от RedHat - Ansible Best Practices.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19🔥10
ASR9000 Troubleshooting Architectures.pdf
13.6 MB
ASR9000 Troubleshooting Architectures
До перехода на Juniper в качестве бордеров у нас использовались Cisco ASR 9K. И вот однажды, при изменении ACL, мы столкнулись с такой ошибкой:
При дебаге очень помог этот документ, в котором подробно рассказывается о том:
• Как дебажить ошибки, связанные с TCAM
• Как посмотреть использование TCAM-таблицы
• Как узнать количество занятых записей
• Как оптимизировать ACL для минимизации использования записей
• Как определить, сколько записей использует конкретный ACL
• Как сделать compression ACL
Мы оптимизировали ряд старых ACL, а для самых жирных использовали compression.
При использовании compression нужно учитывать, что есть CVE-2023-20190:
Cisco IOS XR Software Compression ACL Bypass Vulnerability
🎤 Будни сетевика 😊
До перехода на Juniper в качестве бордеров у нас использовались Cisco ASR 9K. И вот однажды, при изменении ACL, мы столкнулись с такой ошибкой:
LC/0/0/CPU0:Oct 5 13:22:41.528 MSK: pfilter_ea[295]: %PKT_INFRA-FEA_DLL-3-TCAM_ERR : TCAM create region error: 'prm_server' detected the 'resource not available' condition 'TCAM resource exhausted.'
При дебаге очень помог этот документ, в котором подробно рассказывается о том:
• Как дебажить ошибки, связанные с TCAM
• Как посмотреть использование TCAM-таблицы
• Как узнать количество занятых записей
• Как оптимизировать ACL для минимизации использования записей
• Как определить, сколько записей использует конкретный ACL
• Как сделать compression ACL
Мы оптимизировали ряд старых ACL, а для самых жирных использовали compression.
При использовании compression нужно учитывать, что есть CVE-2023-20190:
Cisco IOS XR Software Compression ACL Bypass Vulnerability
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18👍8❤5
Интересный проект awesome-sysadmin.
Это репозиторий, который представляет собой отобранный список полезных бесплатных и открытых ресурсов для системных администраторов.
Основная его цель: Собрать в одном месте лучшие open-source инструменты и ресурсы для задач системного администрирования.
Репозиторий структурирован по категориям, охватывающим практически все аспекты работы системного администратора: автоматизация, резервное копирование, CI/CD, мониторинг, виртуализация, контейнеры и даже немножко сети (VPN, firewall и тд)
🎤 Будни сетевика 😊
Это репозиторий, который представляет собой отобранный список полезных бесплатных и открытых ресурсов для системных администраторов.
Основная его цель: Собрать в одном месте лучшие open-source инструменты и ресурсы для задач системного администрирования.
Репозиторий структурирован по категориям, охватывающим практически все аспекты работы системного администратора: автоматизация, резервное копирование, CI/CD, мониторинг, виртуализация, контейнеры и даже немножко сети (VPN, firewall и тд)
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - awesome-foss/awesome-sysadmin: A curated list of amazingly awesome open-source sysadmin resources.
A curated list of amazingly awesome open-source sysadmin resources. - awesome-foss/awesome-sysadmin
🔥16👍8 4 1
Обзор сетевых интерфейсов в Linux
Если выполнить команду ip link help на Linux-хосте, то в выводе (будет в самом низу) можно увидеть довольно большой список сетевых интерфейсов:
Есть две статьи, которые подробно описывают большинство из них:
1. Introduction to Linux interfaces for virtual networking
2. An introduction to Linux virtual interfaces: Tunnels
Интерфейсы, которые есть в выводе команды ip link help, но не упоминаются в этих статьях:
P.S. В списке 41 интерфейс, из которых только 10 я видел вживую и/или настраивал. У кого больше? 😅
🎤 Будни сетевика 😊
Если выполнить команду ip link help на Linux-хосте, то в выводе (будет в самом низу) можно увидеть довольно большой список сетевых интерфейсов:
TYPE := { amt | bareudp | bond | bond_slave | bridge | bridge_slave |
dsa | dummy | erspan | geneve | gre | gretap | gtp | ifb |
ip6erspan | ip6gre | ip6gretap | ip6tnl |
ipip | ipoib | ipvlan | ipvtap |
macsec | macvlan | macvtap |
netdevsim | nlmon | rmnet | sit | team | team_slave |
vcan | veth | vlan | vrf | vti | vxcan | vxlan | wwan |
xfrm | virt_wifi }
Есть две статьи, которые подробно описывают большинство из них:
1. Introduction to Linux interfaces for virtual networking
2. An introduction to Linux virtual interfaces: Tunnels
Интерфейсы, которые есть в выводе команды ip link help, но не упоминаются в этих статьях:
• amt - Automatic Multicast Tunneling, используется для мультикаста. Создает туннель между клиентом, находящимся в сети без мультикаста, и шлюзом, который находится в сети с мультикастом.
• bareudp - поддержка Bare UDP L3 инкапсуляции. Используется, например, для транспортировки MPLS поверх UDP, описано здесь.
• dsa - Distributed Switch Architecture. Очень подробно об этом можно прочитать тут.
• rmnet - устройство Qualcomm rmnet. Что это такое, описано здесь.
• wwan - Wireless Wide Area Network. Неплохое объяснение wwan-интерфейса в контексте GSM-модема.
• virt_wifi - виртуальный драйвер, симулирующий Wi-Fi устройство. Часто используется для тестирования сетевого стека без реального hardware.
P.S. В списке 41 интерфейс, из которых только 10 я видел вживую и/или настраивал. У кого больше? 😅
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13🔥7
Интернет на Камчатке
Я уже бывал на Камчатке в июне 2016 года - это была командировка на три недели. Мы тогда запускали систему-112 в Петропавловске-Камчатском, Елизово и Мильково. Приходилось настраивать серверы, MikroTik’и, АТС (потоки E1, SIP-транки) и рабочие места(комп + софт 112) во всех дежурно-диспетчерских службах (ЕДДС, 01, 02, 03).
В тот период все ждали «быстрого» Интернета, а именно подводной волоконно-оптической линии связи (ПВОЛС) Камчатка - Сахалин - Магадан. Пока ее не запустили, использовали спутниковую связь. Связь внутри города, по моим воспоминаниям, была неплохой, но между регионами или в Интернет приходилось работать с каналами через спутник, что означало задержки в 600-800 ms и периодические потери пакетов, которые также зависили еще и от погоды и/или положения спутника. И, как ни странно, системы работали - данные можно было передавать между центром и регионами, даже SIP-телефония функционировала, не идеально конечно, но вызовы проходили.
Что касается мобильного интернета, то я уже не помню подробностей, но по ощущениям его не было, а любые вызовы стоили дорого, в те времена еще был роуминг внутри одного оператора. Сейчас, находясь в селе Паратунка Елизовского района, speedtest на мобильном интернете Мегафон показывает: RX 117 Mb/s, TX 12Mb/s, ping 152 мс - для просмотра в FullHD хватит.
По открытым источникам, официально ПВОЛС был запущен в октябре-декабре 2016 года, но, думаю, был еще какой-то временной лаг, в течение которого «быстрый» интернет дошел до конечных пользователей. Сейчас зашел на сайты местных операторов и вижу предложения подключить интернет до 500 Мбит/с по технологии xPON.
Я нашел просто шикарную статью о строительстве подводной линии связи до Камчатки и данных с экскурсии на судно-кабелеукладчик Cable Innovator. Она не новая, но как-то прошла мимо меня.
P.S. На фото вулкан Корякский, 29 октября 2025г. Высота над уровнем моря 3456м, легко запомнить.
🎤 Будни сетевика 😊
Я уже бывал на Камчатке в июне 2016 года - это была командировка на три недели. Мы тогда запускали систему-112 в Петропавловске-Камчатском, Елизово и Мильково. Приходилось настраивать серверы, MikroTik’и, АТС (потоки E1, SIP-транки) и рабочие места(комп + софт 112) во всех дежурно-диспетчерских службах (ЕДДС, 01, 02, 03).
В тот период все ждали «быстрого» Интернета, а именно подводной волоконно-оптической линии связи (ПВОЛС) Камчатка - Сахалин - Магадан. Пока ее не запустили, использовали спутниковую связь. Связь внутри города, по моим воспоминаниям, была неплохой, но между регионами или в Интернет приходилось работать с каналами через спутник, что означало задержки в 600-800 ms и периодические потери пакетов, которые также зависили еще и от погоды и/или положения спутника. И, как ни странно, системы работали - данные можно было передавать между центром и регионами, даже SIP-телефония функционировала, не идеально конечно, но вызовы проходили.
Что касается мобильного интернета, то я уже не помню подробностей, но по ощущениям его не было, а любые вызовы стоили дорого, в те времена еще был роуминг внутри одного оператора. Сейчас, находясь в селе Паратунка Елизовского района, speedtest на мобильном интернете Мегафон показывает: RX 117 Mb/s, TX 12Mb/s, ping 152 мс - для просмотра в FullHD хватит.
По открытым источникам, официально ПВОЛС был запущен в октябре-декабре 2016 года, но, думаю, был еще какой-то временной лаг, в течение которого «быстрый» интернет дошел до конечных пользователей. Сейчас зашел на сайты местных операторов и вижу предложения подключить интернет до 500 Мбит/с по технологии xPON.
Я нашел просто шикарную статью о строительстве подводной линии связи до Камчатки и данных с экскурсии на судно-кабелеукладчик Cable Innovator. Она не новая, но как-то прошла мимо меня.
P.S. На фото вулкан Корякский, 29 октября 2025г. Высота над уровнем моря 3456м, легко запомнить.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥30👍12❤7 3🏆2
Рейтинг онлайн-кинотеатров для Камчатки: результаты личного эксперимента
Я провёл небольшое исследование, чтобы выяснить, в каких онлайн-кинотеатрах лучше всего смотреть фильмы на Камчатке. Для этого я оформил бесплатные пробные подписки в основных сервисах и проверил качество их работы. Методика была следующей: я запускал просмотр и в консоли разработчика браузера смотрел, с какого раздающего сервера приходит ссылка. Для каждого из этих серверов с помощью команды ping (с опцией -c 50) проверял RTT и TTFB (time to first byte, то есть время от отправки запроса до получения первого байта от сервера).
Эти метрики показались мне наиболее объективными для сравнения, поскольку тесты на скорость загрузки контента могут отличаться из-за разной длины сегментов. При этом, TTFB я проверял только после того, как убеждался, что сегмент отдаётся из кэша (HIT), чтобы получились максимально чистые результаты. Для TTFB брал от 10 до 15 значений и считал среднее. Все данные сведены в таблицу.
Наблюдения:
Чем меньше RTT и TTFB, тем ниже вероятность буферизации и подвисаний при просмотре. Однако, это технические метрики, отражающие работу инфраструктуры. Многие проблемы для конечного пользователя могут быть скомпенсированы самим видеоплеером, его настройками адаптивного битрейта (ABR) и алгоритмами предзагрузки сегментов. Но у тех сервисов, у которых высокий RTT и TTFB реально ощутимо дольше стартует просмотр и бывают зависания в процессе, но полноценный просмотр уже проверял не у всех.
Выводы: буду доверять техническим метрикам и смотреть Okko 😅
UPD: В комментах подсказали, как определить конкретную ноду у IVI - https://region.dfs.ivi.ru/ (Хабаровск)
🎤 Будни сетевика 😊
Я провёл небольшое исследование, чтобы выяснить, в каких онлайн-кинотеатрах лучше всего смотреть фильмы на Камчатке. Для этого я оформил бесплатные пробные подписки в основных сервисах и проверил качество их работы. Методика была следующей: я запускал просмотр и в консоли разработчика браузера смотрел, с какого раздающего сервера приходит ссылка. Для каждого из этих серверов с помощью команды ping (с опцией -c 50) проверял RTT и TTFB (time to first byte, то есть время от отправки запроса до получения первого байта от сервера).
Эти метрики показались мне наиболее объективными для сравнения, поскольку тесты на скорость загрузки контента могут отличаться из-за разной длины сегментов. При этом, TTFB я проверял только после того, как убеждался, что сегмент отдаётся из кэша (HIT), чтобы получились максимально чистые результаты. Для TTFB брал от 10 до 15 значений и считал среднее. Все данные сведены в таблицу.
Наблюдения:
• Wink использует CDN Ngenx и, судя по всему, не имеет собственной сети доставки контента
• RuTube и Premier работают через один и тот же CDN
• VK Видео использует CDN «Одноклассников»
• Интересно, что у Premier и RuTube, при использовании одного CDN, показатели TTFB существенно различаются. Я провел тесты несколько раз, ничего не меняется. Вероятно, раздача идёт с серверов разной «мощности».
• Если судить по RTT и TTFB, то наилучшие показатели у Okko, Кинопоиска, IVI и Kion.
• Судя по именам узлов, у Okko и Кинопоиска есть кэш-серверы в Хабаровске, а у Kion во Владивостоке. IVI использует Anycast, поэтому точное географическое положение их узлов определить невозможно, но думаю они также в Хабаровске и/или Владике. У остальных сервисов, скорее всего, все узлы расположены в Москве
Чем меньше RTT и TTFB, тем ниже вероятность буферизации и подвисаний при просмотре. Однако, это технические метрики, отражающие работу инфраструктуры. Многие проблемы для конечного пользователя могут быть скомпенсированы самим видеоплеером, его настройками адаптивного битрейта (ABR) и алгоритмами предзагрузки сегментов. Но у тех сервисов, у которых высокий RTT и TTFB реально ощутимо дольше стартует просмотр и бывают зависания в процессе, но полноценный просмотр уже проверял не у всех.
Выводы: буду доверять техническим метрикам и смотреть Okko 😅
UPD: В комментах подсказали, как определить конкретную ноду у IVI - https://region.dfs.ivi.ru/ (Хабаровск)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥29❤9👍6
Вот такие СМС мы получали на Камчатке за время отпуска:
Каждое такое сейсмособытие в городе ощущалось небольшими толчками.
P.S. На этом серия постов о Камчатке заканчивается 🙂
Сильный ветер, порывами до 50 м/с на юге Елизовского района в первой половине ночи и днём 28 октября 2025 года Тел. 112
Сообщается о сейсмособытии в 19.10. Магнитуда 6.2. Удаление от ПКГО 154 км. Все системы работают. Инф. на: 41.mchs.gov.ru, тел. 112
Сообщается о сейсмособытии в 20.44. Магнитуда 6.2. Удаление от ПКГО 186 км. Все системы работают. Инф. на: 41.mchs.gov.ru, тел. 112
Сообщается о сейсмособытии в 15:45. Магнитуда 6.2. Удаление от ПКГО 168 км. Все системы работают. Инф. на 41.mchs.gov.ru, тел. 112
Сообщается о сейсмособытии в 16:52. Магнитуда 6.3. Удаление от ПКГО 158 км. Все системы работают. Инф. на 41.mchs.gov.ru, тел. 112
Каждое такое сейсмособытие в городе ощущалось небольшими толчками.
P.S. На этом серия постов о Камчатке заканчивается 🙂
🔥15👍9
Как у вас началась рабочая неделя?
У меня она началась с новости о том, что ровно через неделю, 17 ноября, я буду выступать на Пиринговом форуме 2025.
Секция «Архитектура бесшовного опыта: от кэша до глобальной маршрутизации» обещает быть очень интересной!
Для тех, кто будет на форуме, буду рад обсудить что-нибудь или просто пообщаться.
🎤 Будни сетевика 😊
У меня она началась с новости о том, что ровно через неделю, 17 ноября, я буду выступать на Пиринговом форуме 2025.
Секция «Архитектура бесшовного опыта: от кэша до глобальной маршрутизации» обещает быть очень интересной!
Для тех, кто будет на форуме, буду рад обсудить что-нибудь или просто пообщаться.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17👍8