Alexey Dvorkin

Да, отключена.

Да, конечно. Эти коммутаторы и сейчас используются, просто mesh идет не через них. Про spanning-tree там было две записи: spanning-tree mode rstp spanning-tree shutdown Могу прислать всю конфигурацию, если это будет полезно. Насколько я понял из замечания на сайте Keenetic, надо было включить spanning-tree в режим stp и задать ему минимальный приоритет. Просто отключения как на SNR-S2985G-24T было недостаточно. VLAN на портах были прописаны явно, mesh собирался без проблем и не выдавал никаких ошибок. Меня удивляет, что wi-fi работал, но работал плохо. STP это все-таки управляющий протокол и не должен влиять на скорость.

Ну да, STP мы не трогали. Но кадры, естественно, он пропускал: все VLAN-ы на Keenetic были настроены на портах коммутатора с теми же параметрами тегов.

Естественно, все настроено, для всех VLAN (switchport mode trunk). Иначе вообще соединения не было бы. Во втором случае VLAN был только один и порты были в access.

SNR-S5210G-24FX Ethernet Managed Switch eNOS software, Compiled on 12/11/24 13:44:09 (189f2482) Copyright (C) 2024 NAGTECH LLC All rights reserved CPU Mac F8:F0:82:D6:38:90 Vlan MAC F8:F0:82:D6:38:8F SoftWare Version 1.13.0 BootRom Version 1.2 (Dec 15 2022 - 15:58:49) HardWare Version 1.1.0 При подключении точек доступа через этот коммутатор wi-fi сеть, собранную в mesh-систему, начинает работать крайне нестабильно: резко снижается скорость (до 20-30 Мбит/с), пинги даже до шлюза идут с большими задержками. При этом на порту коммутатора нет никаких ошибок или потерь, диагностика Keenetic ничего не выявляет. Перезагрузка коммутатора помогает, но лишь минут на пять. При этом, если исключить этот коммутатор из цепочки "контроллер-точки" или заменить его на любой другой (например, SNR-S2985G-24T), то все проблемы пропадают. Если не использовать wi-fi, а подключиться проводами через тот же коммутатор, то проблем тоже не наблюдается. Сложности появляются именно в сочетании SNR-S5210G-24FX и mesh от Keenetic. Конфигурация сети mesh: контролер Keenetic Peak (KN-2710) и 14 точек доступа Voyager Pro (KN-3510) с последними прошивками. Возможно это можно было бы списать на неисправность конкретного устройства или ошибки в конфигурации сети, но ТОЧНО такая же ситуация наблюдалась и у другого клиента, где собрана сеть Keenetic mesh в другой конфигурации и с другим оборудованием: контролер Keenetic Giga (KN-1010) и в режиме точек доступа Giga (KN-1011) - 2 шт и Hero 4G (KN-2311) и тоже с последними версиями прошивок. Информация о коммутаторе: SNR-S5210G-24FX-UPS Ethernet Managed Switch eNOS software, Compiled on 02/10/25 10:27:13 (d945d5e1) Copyright (C) 2025 NAGTECH LLC All rights reserved CPU Mac f8:f0:82:d6:39:d2 Vlan MAC f8:f0:82:d6:39:d1 SoftWare Version 1.14.0 BootRom Version 1.9 (Feb 10 2025 - 10:24:28) HardWare Version 1.1.0 Сейчас из схем сетей исключены коммутаторы SNR-S5210G-24FX, поскольку от клиентов поступали постоянные жалобы, особенно на работу VOIP, поэтому что-то проверить или протестировать не сможем. И возвращаться пока не планируем. Но такое поведение коммутатора вызывает резонное недоверие к нему. Если удастся воспроизвести данную ситуацию и найти ее причину, то было бы здорово знать решение на будущее.

Проблема возникла один раз. Но я особо-то и не следил, просто случайно заметил, что бекапы перестали делаться. Перезагрузил, прослежу, если повторится - обязательно заведу заявку.

SoftWare Version 1.13.0 BootRom Version 1.2 (Dec 15 2022 - 15:58:49) HardWare Version 1.1.0 Где-то полутора месяца назад, похоже, подвисла сессия TFTP, поскольку на команду copy running-config tftp tftp://x.x.x.x/ получаю ошибку % Error: The copy task has worked, try it again later Других пользовательских сессий на коммутаторе нет. До этого команда прекрасно обрабатывалась примерно пару недель после загрузки. То есть это точно не результат перепрошивки. Есть ли возможность посмотреть/снять данный процесс? Предполагаю, что перезагрузка поможет, но хотелось бы разобраться в ситуации, а не просто ребутить коммутатор каждые пару недель.

Коммутатор SNR-S2985G-24T SoftWare Version V702R101C009 В конфигурации появилась строчка "ip dhcp mode special enable", которая не описана в документации. Хотелось бы узнать что за "special mode" и нужна ли она мне? На всякий случай удалил ее из конфигурации.

SNR-S5210G-24FX-UPS SoftWare Version 1.11.1 Запрос по snmp на ifInDiscards (OID .1.3.6.1.2.1.2.2.1.13.5028) на порту xe4 (в него вставлен модуль SFP на 1 Гб/с) постоянно растет из-за отброшенных пакетов. В документации указано, что это может происходить из-за "переполнения буфера пакетов". Трафик на порту небольшой. Стоит ли считать, что проблема существует и если "да", то как очистить/увеличить буфер пакетов?

Тогда еще вопрос. Можно ли узнать ограничение скорости на порту через SNMP? На оборудовании SNR это OID 1.3.6.1.4.1.40418.7.100.3.2.1.9 и 1.3.6.1.4.1.40418.7.100.3.2.1.10. На коммутаторе SNR-S5210G-24FX-UPS между ветками .5 и .12 - пустота.

@Evgeniy Rychkov Спасибо за информацию. А в roadmap нет планов начинать нумерацию портов не с 5001, а, как и на остальных коммутаторах (не только вашего производства), с 1? У нас от этого вся статистика слетела: она просто не ожидает, что на коммутаторе может быть 5000+ портов.

SNR-S5210G-24FX-UPS SoftWare Version 1.11.1 Существует ли какой-нибудь OID для сохранения конфигурации во flash по SNMP (аналог команды write через консоль)?

Я не нашел лучшего варианта, чем стандартный шаблон для Linux.

Есть ли обновленная версия шаблона для последней версии dpi (11.3) и zabbix (6.0)? Если нет, то какой шаблон лучше всего использовать для мониторинга?

Сдались вот с такой конфигурацией (внутренняя нумерация 4-значная, из города приходит 7 цифр: 123XXXX): PROFIL [1] { TYPE = AIR_COMMON nSormModule = 127 sModulePlaces = "ScyyBMzd5offTR0RkhBVHhcH7k=+5w+++" set_sormRoutech = ( "1-99 4" ) set_synchro = ( "1" ) sormInternationalNumbers = 8 sormLocalNetworkNumbers = 6 sormLocalNumbers = 5 sormSpecialNumbers = 9 sormZoneNetworkNumbers = 7 } PROFIL [2] { TYPE = AIR_MODULE wide = 64 } PROFIL [3] { TYPE = PCM_DSS1 side = 0 } PROFIL [4] { TYPE = SIG_DSS1 } PROFIL [5] { TYPE = PCM_IP } PROFIL [6] { TYPE = PCM_SORM mode = 1 order_268 = YES side = 1 } PROFIL [7] { TYPE = SIG_SORM } PROFIL [8] { TYPE = PCM_NONE } <...> ROUTE [4] { NAME = "SORM_R" RECORD "????????????????????" AON "**********" : AON "7**********" REPEAT RECORD "????????????????????" AON "8**********" : AON "7-**********" REPEAT RECORD "????????????????????" AON "****" : AON "7495123****" REPEAT RECORD "123****" : "7495123---****" REPEAT RECORD "****" : "7495123****" REPEAT RECORD "8**********" : "7-**********" REPEAT RECORD "810**********??????????" : "---*************************" REPEAT RECORD "????????????????????????" DIROUT } ROUTE [5] { NAME = "SORM_L" RECORD "****" : "495123****" DIROUT } ROUTE [6] { NAME = "SORM_N" RECORD "8495*******" : "-**********" DIROUT RECORD "8496*******" : "-**********" DIROUT RECORD "8498*******" : "-**********" DIROUT RECORD "8499*******" : "-**********" DIROUT } ROUTE [7] { NAME = "SORM_Z" RECORD "8**********" : "-**********" DIROUT } ROUTE [8] { NAME = "SORM_I" RECORD "1**********??????????" - "6**********??????????" DIROUT RECORD "8**********??????????" - "9**********??????????" DIROUT } ROUTE [9] { NAME = "SORM_S" RECORD "0*" DIROUT RECORD "1**" DIROUT } Главная сложность оказалась в осознании того, что обработка таблиц СОРМ происходит слева направо (то есть первой должна стоять таблица преобразования номеров routech).