Кейс: Как мы спасли GPON-сеть на 1200 абонентов от коллапса за 72 часа
📋 TL;DR для занятых
| Клиент: | Региональный WISP, 1200+ абонентов, 4× OLT C-Data FD1616S |
| Симптомы: | Массовые жалобы на скорость, ночные mass-offline, деградация IPTV |
| Срок аудита: | 72 часа (удалённо + 1 выезд) |
| Найдено проблем: | 4 критических, 7 средней важности |
| Результат: | Жалобы ↓94%, SLA 99.9%, NPS вырос с 32 до 71 |
🚨 ЭТАП 1: ПРОБЛЕМА
К нам обратился технический директор WISP-провайдера из региона (NDA, назовём его "Телеком-Юг"). Ситуация была критическая:
- 📞 40-60 тикетов в день на "низкую скорость" при тарифах 100-500 Мбит/с
- 🌙 Каждую ночь с 02:00 до 04:00 массово отваливаются 100-200 ONT на 2-х PON-портах
- 📺 IPTV "рассыпается" при скачивании торрентов другими абонентами
- 😤 Отток абонентов вырос до 8% в месяц (норма для рынка — 2-3%)
- 💸 Выручка падает, маркетинг не справляется с негативом
Что уже пробовали (безрезультатно):
- Меняли SFP-модули на uplink (не помогло)
- Переобжимали коннекторы в муфтах (не помогло)
- Увеличивали полосу на BRAS (не помогло)
- Меняли ONT у "проблемных" абонентов (не помогло)
Штатный инженер сказал: "Оборудование C-Data — китайское, видимо, глючит. Надо менять на Eltex или Huawei". Это означало бы CAPEX в 3-4 млн рублей и простой сети на 2-3 недели.
Клиент дал нам 72 часа на удалённый аудит с условием: если не найдём корень проблем — аудит бесплатный.
🔬 ЭТАП 2: ДИАГНОСТИКА
Шаг 1. Анализ общей картины (первые 2 часа)
Подключились по SSH к OLT и начали со сбора общей статистики:
OLT(config)# show cpu
Utilization: 87% # КРИТИЧНО! Норма до 60%
# Температура
OLT(config)# show temperature
The temperature of the board: 68(C) # Высоко, но не критично
# Статус всех PON-портов
OLT(config-interface-gpon-0/0)# show port state all
# Поняли: PON 0/0/3 и 0/0/7 — в группе риска
Шаг 2. Анализ "проблемных" PON-портов (часы 2-6)
Сфокусировались на портах, с которых шли массовые жалобы:
OLT(config-interface-gpon-0/0)# show port ddm-info 3
Temperature(C): 42.1
TX power(dBm): -2.87 # КРИТИЧНО! Норма +2...+5 dBm
RX power(dBm): -18.32
# Оптика на втором проблемном порту
OLT(config-interface-gpon-0/0)# show port ddm-info 7
TX power(dBm): +3.12 # Норма
RX power(dBm): -21.45 # Норма
Шаг 3. Поиск Rogue ONT (часы 6-12)
Ночные mass-offline на порту 0/0/7 — классический симптом Rogue ONT (модема, который "светит" постоянно, глуша остальных). Проверили:
OLT(config-interface-gpon-0/0)# show anti-rogueont auto-detect switch
F/S Port Switch Interval(min)
0/0 7 disable -- # КРИТИЧНО! Функция отключена
# Активные алармы
OLT(config)# show alarm active all
ALARM15 Major 204 -- pon port link down
ALARM33 Warning 410 -- Rogue ONT detected on port 7
- На порту 0/0/7 есть активный Rogue ONT
- Функция
anti-rogueont auto-isolateотключена — сеть беззащитна - Ночью (когда легитимные ONT "спят") rogue-модем захватывает весь PON-порт, вызывая массовый offline
Шаг 4. Анализ QoS и IPTV-проблем (часы 12-20)
IPTV "рассыпался" при нагрузке — явный признак неправильного QoS. Проверили DBA-профили:
OLT(config)# show dba-profile all
Profile Profile Type Fix Assure Max Bind
ID Name (kbps)(kbps)(kbps) times
-------------------------------------------------------
10 DBA-Internet 4 0 0 102400 850
20 DBA-VoIP 4 0 0 51200 120 # ОШИБКА!
30 DBA-IPTV 4 0 0 204800 230
VoIP и IPTV используют Type 4 (Best Effort) DBA-профили. Это означает, что при загрузке канала торрентами, голос и видео не имеют гарантированной полосы и конкурируют с интернетом на равных.
Правильно:
- VoIP → Type 3 (Assure + Max) с гарантией 2-4 Мбит/с
- IPTV → Type 3 с гарантией 10-20 Мбит/с
- Internet → Type 4 (только Max)
Шаг 5. Поиск "тихих" проблем (часы 20-48)
Прошерстили всю сеть скриптами (Python + Netmiko) и нашли ещё 7 проблем средней важности:
| Проблема | Количество | Влияние |
|---|---|---|
| ONT с Rx < -27 dBm | 47 шт. | Периодические "тормоза" |
| Неправильный srv-profile (4 ETH вместо 1) | 23 ONT | Config state: failed |
| Отсутствие STP на uplink | 2 OLT | Риск петель |
| Бэкапы конфигов не делаются | Все 4 OLT | Риск потери конфигурации |
| SNMP выключен | Все 4 OLT | Нет мониторинга |
| NTP не настроен | 3 OLT | Логи бесполезны |
| Дефолтные пароли admin/admin | 2 OLT | Угроза взлома |
🛠 ЭТАП 3: РЕШЕНИЕ
Предоставили клиенту детальный отчёт с приоритизацией и приступили к исправлениям.
Исправление #1: Замена умирающего SFP (час 48)
Выезд инженера на площадку, замена SFP-модуля на PON 0/0/3:
OLT(config-interface-gpon-0/0)# show port ddm-info 3
TX power(dBm): +3.45 # ✅ Норма
RX power(dBm): -17.82 # ✅ Норма
Исправление #2: Включение anti-rogue защиты (час 49)
OLT(config-interface-gpon-0/0)# anti-rogueont auto-detect all enable interval 15
OLT(config-interface-gpon-0/0)# anti-rogueont auto-isolate all enable
# Через 20 минут OLT сам нашёл и изолировал rogue ONT
OLT(config)# show alarm active all
ALARM45 Major -- Rogue ONT isolated on port 7, ONT-ID: 23
Исправление #3: Корректировка DBA-профилей (час 50)
OLT(config)# dba-profile profile-id 21 profile-name DBA-VoIP-Fixed
OLT(config-dba-profile-21)# type3 assure 4096 max 10240
OLT(config-dba-profile-21)# commit
# Пересоздаём DBA для IPTV
OLT(config)# dba-profile profile-id 31 profile-name DBA-IPTV-Fixed
OLT(config-dba-profile-31)# type3 assure 20480 max 102400
OLT(config-dba-profile-31)# commit
# Массовая перевязка ONT на новые профили через Python-скрипт
# (120 VoIP + 230 IPTV абонентов перевязаны за 15 минут)
Исправление #4: Настройка базового мониторинга (часы 51-60)
OLT(config)# service snmp enable
OLT(config)# snmp-agent community read public
OLT(config)# snmp-agent trap zabbix 10.255.0.10 162 public
OLT(config)# ntp-service unicast-service ntp1.stratum2.ru
OLT(config)# syslog add 10.255.0.20 graylog-server
OLT(config)# syslog activate ip 10.255.0.20
OLT(config)# auto-backup period configuration enable
OLT(config)# auto-backup period configuration interval 1 time 03:00
OLT(config)# auto-backup server configuration tftp 10.255.0.20
Исправление #5: Устранение "тихих" проблем (часы 60-72)
Параллельно с основными работами:
- ✅ 47 ONT с Rx < -27 dBm — составили список для замены патч-кордов/сварки
- ✅ 23 ONT с неправильным srv-profile — перевязали на корректный через
ont modify - ✅ Включили STP на всех uplink:
stp enable - ✅ Сменили дефолтные пароли на всех OLT
- ✅ Настроили loopback-detection на всех GE-портах
📊 ЭТАП 4: РЕЗУЛЬТАТ
Через 72 часа после начала аудита и 2 недели наблюдения — следующие метрики:
| Метрика | До аудита | После аудита | Изменение |
|---|---|---|---|
| Тикеты на "скорость" | 40-60 / день | 2-4 / день | ↓ 94% |
| Mass-offline события | Еженочно | 0 за 2 недели | ↓ 100% |
| Загрузка CPU OLT | 87% | 34% | ↓ 53 п.п. |
| Жалобы на IPTV | 15-20 / день | 0-1 / день | ↓ 95% |
| SLA доступности сети | 96.2% | 99.94% | ↑ 3.74 п.п. |
| Отток абонентов | 8% / мес | 2.4% / мес | ↓ 70% |
| NPS (лояльность) | 32 | 71 | ↑ 122% |
💰 Экономический эффект для клиента (расчёт за год):
- 💸 СОХРАНЕНО: 3.8 млн ₽ на замене оборудования (Eltex не понадобился)
- 💸 СОХРАНЕНО: ~2.1 млн ₽ на удержании 67 абонентов, которые бы ушли
- 💸 СОХРАНЕНО: ~480 тыс. ₽ на ФОТ монтажников (меньше выездов)
- 📈 ПОЛУЧЕНО: +1.4 млн ₽ дополнительной выручки от новых подключений (репутация восстановлена)
Итого ROI аудита: ~7.8 млн ₽ за год при стоимости аудита 180 тыс. ₽
📝 Что получил клиент по итогу
Не просто "починили и ушли", а передали:
- 📄 Отчёт на 47 страниц с детальным описанием всех найденных проблем, их влияния и рекомендаций
- 📊 Excel-карту сети со всеми 1200+ ONT, их статусом, SN, уровнем сигнала и привязкой к адресу
- 📋 Runbook (инструкцию) для штатного инженера: "Что делать при типовых проблемах" с готовыми командами
- 🐍 Python-скрипты для автоматического сбора статистики и массовых операций
- 📈 Zabbix-шаблон для мониторинга всех 4-х OLT с алертами в Telegram
- 🎓 2-часовую сессию обучения для штатного инженера по типовым траблшутингам
💬 Отзыв клиента
"Мы полгода мучились, меняли железо, ругались с монтажниками. Думали — C-Data глючит. Ребята из Admin.su за 3 дня нашли то, что мы не видели год. Оказалось, оборудование отличное, просто сеть была настроена "как получилось".
Самое ценное — не просто починили, а объяснили почему так, дали инструменты и обучили нашего инженера. Теперь 80% проблем ловим сами по Zabbix ещё до того, как абонент позвонит."
🔍 Узнали свою ситуацию?
Если в вашей сети есть хотя бы один из этих симптомов — нужен аудит:
- ❗ Жалобы на скорость при "нормальных" тарифах
- ❗ Периодические mass-offline на PON-портах
- ❗ IPTV/VoIP "рассыпается" под нагрузкой
- ❗ CPU OLT постоянно выше 60%
- ❗ Нет мониторинга или он "для галочки"
- ❗ Инженер "тушит пожары" вместо развития сети
Бесплатная 30-минутная диагностика. Если не найдём проблем — не платите.
📚 Что читать дальше
- Шпаргалка CLI C-Data FD16xx — все команды
- Практический гайд по настройке GPON-сети
- Мониторинг GPON: Zabbix + Python + SNMP
- Сравнение OLT: C-Data vs Eltex vs Huawei vs ZTE
💡 Совет от инженера
Большинство проблем в GPON-сетях (по нашему опыту — 80%+) вызваны не "плохим железом", а:
- Отсутствием базового мониторинга (SNMP, Syslog, NTP)
- Неправильной архитектурой VLAN и DBA-профилей
- Отключенными функциями безопасности (anti-rogue, STP, loopback-detection)
- Накопившимися "тихими" проблемами (деградация оптики, неверные профили)
Регулярный аудит раз в 6-12 месяцев окупается многократно — как регулярное ТО автомобиля.
Комментариев 0