Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1 2 След.
RSS
Вопрос по STP routing при использовании mesh в качестве резерва., UniFi Network
 
Всем привет!

Моя сеть была стабильной больше года, а потом я обновился до Flex 2.5 (с US 8 60w) и всё пошло наперекосяк. Кроме железа, я немного по-другому подключил провода (upstream в #1, AP в #7, и downstream в #8). Теперь RSTP случайным образом блокирует связь между средними свитчами (красная линия) и перенаправляет весь сетевой трафик через два U6 pro (пунктирная линия). Когда это происходит, трафик по зеленой линии начинает течь в обратном направлении. Я знаю, что это не должно влиять, но решил упомянуть это для диагностики.

Хочется сохранить меширование как резервный вариант на случай проблем с проводным маршрутом, но я не могу понять, что нужно изменить. Да, я несколько раз пытался восстановить проводное соединение, и каждый раз оно возвращается к мешированию. Я также перезагружал свитчи, но это ничего не меняет (и я этого и не ожидал).

Несколько дополнительных данных:

*   Все порты имеют сеть по умолчанию (1), разрешают весь тегированный трафик и установлены в режим авто (что включает STP).
*   Я использую UniFi OS 4.2.9 и Network 9.1.120 на Cloud Key Plus.
*   В других местах выше по потоку нет проблем с STP между свитчами.

Если я перехожу на вкладку Ports, меню в верхнем левом углу, которое показывает список всех свитчей, не отображает их в порядке (ip, имя, MAC, приоритет и т.д.). Не знаю, плохой ли это дизайн интерфейса, пропускаю ли я что-то, или есть ли здесь связь с моими проблемами. Из четырех здесь показанных свитчей 8-150w указан первым, затем Flex 2.5g, затем 8-60w #2 и в последнюю очередь 8-60w #1. Другие свитчи, похоже, разбросаны до, между и после проблемных свитчей, о которых я говорю.

AP #1 имеет все 4 SSID, назначенные как на 2.4GHz, так и на 5GHz, в то время как у AP #2 ничего нет. Обычно у AP #2 есть дочерний AP, подключенный по мешу. AP #1 не должен использовать меш, если проводное соединение между 4 свитчами не разорвано.

В последнюю очередь, я почти уверен, что это не связано, но у нескольких моих AP TX повторы в диапазоне 20-35%. Два основных нарушителя подключены к 8-60w #2.

Любая помощь была бы замечательна, даже если это просто ссылка для лучшего понимания этого (что я, казалось, освоил).
 
Ну что, сдаюсь! Коммутаторы проверены и работают нормально на столе, а вот номер три сошёл с лестницы вниз (как назло). Новый номер три тоже работает на столе, а потом номер два начал выдавать проблемы с DNS после переустановки. Это я исправил, протестировал кабель - всё в порядке. Но в контроллере сообщалось, что порты upstream и downstream на коммутаторе номер три поменялись местами. Перезагружал, менял порты - много раз. Безрезультатно! Максимум, что получал - это кратковременный трафик и полу-постоянная "смерть" с мерцанием. Решил, что дело в кабеле. "Случайно" измерил длину – разница была в 6 метров. Подумал, что дело в неаккуратной обжимке. Заменил обжимки на каждом конце как минимум три раза, и почти каждый раз получал другую ошибку - замыкания, перекрещивания, обрывы и т.д. Единственное, что приходит мне в голову сейчас – кабель повреждён. Не очень хочется прокладывать более 60 метров кабеля, так что, видимо, возвращаюсь к внутренней mesh-сети. Точка-точка не подходит, так как расстояние между точками доступа всего около 6 метров. К сожалению, другого способа добраться туда, не повредив здание, не вижу. Спасибо всем за помощь и терпение.
 
В общем-то, это я и имел в виду. Кажется глупым делать коммутатор, питающийся по POE, но размещать последний порт именно так. По крайней мере, с моим Flex 2.5g, если вы используете порты 1 и 9 для передачи данных, то порт 9 блокируется, что снижает ваш POE ввод.

Редактирую: Оказывается, я могу использовать порт 9 только со скоростью 1 Гб/с. Знаю, что если бы было 2.5 Гб/с, STP (Spanning Tree Protocol) бы работал правильно. :)
 
Не уверен, что ты имеешь в виду. POE не участвует в расчете STP. Как правило, при расчете приоритета STP для коммутатора в первую очередь учитывается запрограммированный приоритет, затем скорость канала связи, а затем стоимость/приоритет порта.
 
Мне кажется логичным, что коммутатор, питающийся по POE, даст наилучший результат STP. Разве он не стал бы естественным выбором для подключения? Но потом я снова думаю, что доказал, как мало я знаю! 😵
 
Переместите нижний переключатель в положение верхнего, подключите с помощью проверенного хорошего провода-перемычки. Используйте те же порты. Начинайте с начала и двигайтесь наружу.
 
Мой Klein scout pro 3 показывает, что проводка верна. Кроме прокладки 60 метров нового кабеля, есть какие-нибудь предложения? Оба конца новые, но можно попробовать переделывать обжим. Может ли это быть частью (или, возможно, причиной?) других проблем с подключением? Например, один из моих вышестоящих коммутаторов не позволяет мне вносить изменения в конфигурацию порта. Другой коммутатор показывает RSTP только с одного конца. Я только что перезагрузил мои вышестоящие устройства, и теперь связь между 2 и 3 снова мертва!
 
Вот, собственно, в этом и был смысл... (подсказка: смайлик)
 
Порт бешено скачет вверх и вниз. Обычно, если бы это был STP, всё было бы медленнее, и это было бы залогировано. RSTP мог бы работать настолько быстро, но и его тоже бы залогировали. Сначала исключи кабель как причину.
 
Это не так работает STP. Скорость учитывается в формуле до номера порта.
 
В большинстве (UniFi) коммутаторов высокоскоростные порты восходящей и нисходящей связи – это порты с большими номерами. Стоит ли нумеровать порты справа налево? Может, это лучше оставить логикам.🤣
 
Я несколько раз пытался выложить обновление, но сайт выдает ошибку "failed to fetch". Пожалуйста, потерпите...
 
Извини, похоже, при каждой перезагрузке свитча логи стираются, выбирается случайная дата в прошлом, и начинается новый набор логов. Если я правильно помню, всё это связано с авторизацией, ключами, MAC-адресами и другими вещами, которые заставили меня подумать, что публиковать это не лучшая идея.

Сейчас он вернулся к сообщению об этом:

May 18 09:14:24 Shed860W daemon.info mcad: mcad[898]: ace_reporter.reporter_json(): immediately send user inform packet
May 18 09:14:27 Shed860W daemon.notice switch: TRAPMGR: Link Up: 0/4
May 18 09:14:27 Shed860W daemon.info switch: DOT1S: Port (4) inst(0) role changing from ROLE_DISABLED to ROLE_DESIGNATED
May 18 09:14:29 Shed860W daemon.notice switch: TRAPMGR: Link Down: 0/4
May 18 09:14:29 Shed860W daemon.info switch: DOT1S: Port (4) inst(0) role changing from ROLE_DESIGNATED to ROLE_DISABLED
May 18 09:14:32 Shed860W daemon.notice switch: TRAPMGR: Link Up: 0/4
May 18 09:14:32 Shed860W daemon.info switch: DOT1S: Port (4) inst(0) role changing from ROLE_DISABLED to ROLE_DESIGNATED
May 18 09:14:36 Shed860W daemon.info mcad: mcad[898]: ace_reporter.reporter_json(): immediately send user inform packet
May 18 09:14:49 Shed860W daemon.notice switch: TRAPMGR: Link Down: 0/4
May 18 09:14:49 Shed860W daemon.info switch: DOT1S: Port (4) inst(0) role changing from ROLE_DESIGNATED to ROLE_DISABLED
May 18 09:14:52 Shed860W daemon.notice switch: TRAPMGR: Link Up: 0/4
May 18 09:14:52 Shed860W daemon.info switch: DOT1S: Port (4) inst(0) role changing from ROLE_DISABLED to ROLE_DESIGNATED
May 18 09:14:53 Shed860W daemon.info mcad: mcad[898]: ace_reporter.reporter_json(): immediately send user inform packet
May 18 09:15:05 Shed860W daemon.notice switch: TRAPMGR: Link Down: 0/4
May 18 09:15:05 Shed860W daemon.info switch: DOT1S: Port (4) inst(0) role changing from ROLE_DESIGNATED to ROLE_DISABLED
May 18 09:15:08 Shed860W daemon.notice switch: TRAPMGR: Link Up: 0/4
May 18 09:15:08 Shed860W daemon.info switch: DOT1S: Port (4) inst(0) role changing from ROLE_DISABLED to ROLE_DESIGNATED

Но честно говоря, везде полный бардак. Сейчас работаю над предоставлением пользователям доступа к вторичной сети, а потом, скорее всего, сделаю сброс до заводских настроек и вручную пересоблю/обновлю всё на стенде.
 
Что за логи?
 
Ну, кажется, я в глубокой заднице. Я понизил версию всех доступных мне коммутаторов из контроллера. Отключил соединение между коммутаторами 2 и 3, перезагрузил их обоих. Ничего не помогло, поэтому я снова включил мешинг и переподключил дочерний AP. Через несколько минут мешинг перестал работать. Я отключил родительский AP, отсоединил кабель между коммутаторами 2 и 3. Я убрал коммутатор 3 на верстак и понизил его версию. После того, как оба коммутатора 2 и 3 полностью перезагрузились, я подключил кабель сначала к 3, а потом к 2. Индикатор загорелся зеленым примерно на 15 секунд, а потом погас. В логах появилось куча новой информации, которую я не понял. У меня заканчивалось время незапланированного простоя, поэтому я снова включил мешинг. Он попросил меня переподключить дочерний AP. Я больше не могу заставить мешинг работать. Я перезагрузил все свое оборудование UniFi от роутера и ниже. Коммутатор 2 показывает несколько старых клиентов, серыми, как призрачные устройства. Карта моей сети показывает, что все клиенты подключены. Страница устройств показывает несколько AP, расположенных ниже, как имеющие моим IP-адресом в качестве родительского. О, и я только что заметил, что когда я подключаю дочерний AP к моему верстачным коммутатору, он отображается как коммутатор #3. Думаю, я просто сброшу все к заводским настройкам после того, что я называю коммутатором #1.
 
Вот с чего бы я тоже начал. Нет особой необходимости использовать обновление 7.1, если у вас нет конкретной проблемы, которую оно призвано решить.
 
Я не знаю ответов на эти вопросы. Может, кто-то другой знает. Мне кажется, вам стоит откатиться на предыдущие версии Unifi-коммутаторов, которые сейчас на 7.1.26, потому что эта прошивка начинает сбоить, как только вы начинаете выстраивать больше пары уровней. Для порядка я всегда люблю, чтобы все мои устройства работали на одной и той же прошивке, но не знаю, насколько это на самом деле важно.
 
Спасибо. Да, после возвращения одного коммутатора на стенд и просмотра сотен строк ошибок. К такому же выводу я пришёл (благодаря Google). Наверное, я не до конца понял, что в 7.1.26 так много проблем с STP. Оба проблемных коммутатора теперь с 7.0.50, но я жду подходящего момента, чтобы остановить сеть. Похоже, правильным действием будет: выключить меширование, включить оба коммутатора, подключить кабель (сейчас он просто отключен на коммутаторе выше по потоку, потому что до коммутатора ниже сложнее добраться).

P.S. Забыл спросить, стоит ли мне понижать версию ПО на всех коммутаторах? Два основных коммутатора работают на 7.1.26 и, кажется, справляются с STP нормально. Flex 2.5g, как обычно, на другой прошивке, поэтому я думаю, что проблема началась именно там (кажется, я был на 7.1.25 для первого коммутатора). Многие коммутаторы ниже по потоку также работают на 7.1.25 (нет проблем с STP или возможных петель). Если я собираюсь делать полную понижающую версию, лучше делать это сверху вниз или снизу вверх?
 
В таком случае, если вы используете 7.1.26, попробуйте откатиться до 7.0.50, как уже упоминалось. 7.1.26, похоже, имеет массу проблем с STP, если соединять коммутаторы цепочкой.
 
Спасибо за заботу, но, к сожалению, у меня тоже есть избыточное переключение в сети выше. Медленно разбираюсь с поиском неисправностей, смотрю логи и т.д., но время, когда я могу остановить сеть, ограничено.
Страницы: 1 2 След.
Читают тему (гостей: 1)