Прошивка версии 3.7.x и коммутаторы NetGear полностью не работают.

Прошивка версии 3.7.x и коммутаторы NetGear полностью не работают., UniFi Network

adinstruments

Guest

13.02.2017 22:16:00

Всем привет! На прошлой неделе я обновил наши 16 AP-AC-PRO и внутренний контроллер до последних версий (контроллер v5.4.11 и прошивка UniFi 3.7.37). Последние три дня я провёл, разбираясь с проблемами беспроводной сети и странным поведением сети, а также откатывая обновления.

Кратко: похоже, есть серьёзная проблема совместимости между нашими основными коммутаторами NetGear и прошивкой UniFi 3.7.x. Эта проблема обсуждалась в той теме, но я решил создать отдельную, так как там она достаточно глубоко “зарыта”.

Итак, у нас такая конфигурация:
Сеть здания:
Первый уровень: стек из 2-х коммутаторов NetGear GS752TS
Второй уровень: стек из 5-ти коммутаторов NetGear GS752TS
Эти стеки связаны между собой 6-портовым LAG. На данный момент довольно простая структура.

UniFi:
16 x UAP AP-AC-PRO
Tough switch 8-портовый
Edge Switch 16 150W, который сгорел в пятницу (через 36 часов после обновления AP на v3.7.37

)

Проблемы, которые мы наблюдаем после обновления AP на версию v3.7.x:
AP начинает рассылать ESIS-all-multicast-announcements на адрес 01:80:c2:00:00:1c. Эти пакеты “застревают” в коммутаторах и продолжают циркулировать несколько часов, даже если устройство уже отключено от сети.
Через минуту-две после подключения AP таблица MAC-адресов коммутаторов портится: первый стек коммутаторов “думает”, что AP подключён через LAG, и второй стек коммутаторов тоже “считает”, что AP подключён через LAG. В результате AP теряет сеть.
Из-за проблемы с мультикастом таблицы MAC остаются в неправильном состоянии, пока мультикаст не исчезнет из сети (это может занять несколько часов), потом MAC-адрес вычищается. Если снова подключить AP, процесс повторяется.

Пока единственное решение для нас — откатить прошивку AP на v3.4.18, которая работает стабильно.

Не выразить словами, сколько времени и сил эта проблема у нас забрала!

@UBNT-Brandon
@UBNT-jeff

Вижу, что вы оба участвовали в предыдущей теме. Есть ли какие-то новые данные по этой проблеме?

Спасибо,
Рикки

broadld

Guest

14.08.2018 15:53:00

Мы применили правила ACL к портам, подключённым к точкам доступа, и к восходящим линиям, чтобы предотвратить циркуляцию пакета по сети. Похоже, что с некоторыми коммутаторами HP возникла проблема, из-за которой этот конкретный пакет постоянно «скачет» вверх и вниз по LAG. Ни малейшей идеи, почему HP до сих пор это не исправили, ведь Netgear очевидно признали проблему и выпустили новую прошивку, чтобы её исправить. Возможно, стоит открыть тикет в HP. Мы уже сделали это, и чем больше людей обратятся, тем сильнее будет давление на них, чтобы признать, что это неисправность некоторых их коммутаторов.

br0m

Guest

14.08.2018 14:34:00

После обновления старого контроллера Unifi сегодня у нас та же проблема на коммутаторах HP 1820 с прошивкой точки доступа 3.9.42. Вся прошивка обновлена до последней версии. Я пробовал без LAG на коммутаторах и с переключением LAG — без результата. Netgear выпустила обновление, а HP — нет. Кто-нибудь нашёл временное решение?

Matt_VS

Guest

01.05.2018 08:32:00

Большое спасибо — я целую вечность пытался найти причину, почему точечные точки доступа случайно отпадают от сети. У меня были пара стареньких коммутаторов Netgear с мультипутингом и LAG, подключённые к основным коммутаторам. Так как для моих коммутаторов нет новых прошивок, я заблокировал мультикаст-пакет на LAG, воспользовавшись этим документом Netgear KB 38810 — Добавление MAC ACL на полностью и умно управляемых коммутаторах. Всем спасибо за информацию и помощь.

broadld

Guest

23.04.2018 12:55:00

@peterdoo

Спасибо, что ответил. Странно, что коммутатор, на котором у нас проблема, имеет только один аплинк и не настроен как транк. Может, это какой-то другой коммутатор, не тот, что подключён к проблемной точке доступа, из-за которого этот пакет циркулирует. Наши поиски продолжаются!

peterdoo

Guest

23.04.2018 12:47:00

Да, именно это помогло в нашем случае. Мультикаст-пакет от, например, точки доступа на порту 1 switch1 будет передаваться по транку на switch2. Switch2 должен транслировать его на все порты. Для транка он решает отправить пакет только на порт 47 или порт 48 (обычно это решение зависит от IP и MAC-адресов пакета). Допустим, он решил транслировать его на порт 47 switch2. Если пакет пришёл со switch1 по транку на порт 47 switch2, то он не будет отправлен обратно по транку. Если же пакет пришёл со switch1 по транку на порт 48 switch2, то он будет транслирован обратно на switch1 через порт 47 switch2. В нашем случае пересечение портов гарантировало, что мультикаст-пакеты от одной точки доступа принимаются на другом порту транка и, следовательно, не транслируются обратно по тому же транку. Настоящая проблема с трансляцией этих пакетов обратно по транку заключается в том, что switch1 запоминает MAC-адрес точки доступа на порту транка и начинает пересылать пакеты, адресованные точке доступа, именно на транк, а не на порт, к которому подключена точка доступа. Проблема в том, что пересечение портов помогает только с некоторыми пакетами. Если у вас несколько источников мультикаста, то их пакеты могут поступать на разные порты свича, а не все на один порт транка. В таком случае пересечение портов лишь изменит, какая группа пакетов будет транслироваться обратно, но не устранит проблему целиком.

broadld Guest	#7 23.04.2018 07:20:00 Как я уже говорил в первом посте, один переключается на другой.

nrinzema Guest	#8 19.04.2018 21:13:00 Было бы полезно прояснить кабельную разводку и топологию ваших сетей. Это LACP между коммутаторами или LACP между коммутатором и двумя портами на самом AP? - Нейт

peterdoo

Guest

22.10.2017 23:14:00

У меня такая же проблема с коммутаторами HP 1810-24G (J9450A). Когда коммутатор подключён через LACP с объединением 2 портов, и он получает мультикаст-пакет быстрого роуминга от транка, то он отражает его обратно на коммутатор, откуда пакет пришёл, но уже через второй порт LACP-транка. Оттуда пакет снова попадает на точку доступа, с которой он изначально пришёл. В логах точки доступа (SSH cat /var/log/messages) появляется сообщение «br0: received packet on eth0 with own address as source address», и иногда точка доступа перестаёт отвечать на пинг. Решение в этом случае — поменять местами два кабеля транка. Коммутатор очевидно всегда отправляет проблемный мультикаст-пакет через один и тот же порт транка, но при этом посылает его только если пакет не пришёл через этот же порт. Я долгое время не наблюдал проблему, пока вчера мы не изменили порядок подключения кабелей, и транк, видимо, оказался перепутан.

RedTechie

Guest

#10

31.05.2017 22:25:00

На самом деле у меня хорошие новости! Netgear выпустила обновление прошивки, которое устранило проблему с неконтролируемыми пакетами широковещательной рассылки. Смотрите по этой ссылке: https://community.netgear.com/t5/Smart-Plus-Click-Switches/STP-Leak-using-Broadcast-packet-01-80-c2-00-00-1c/m-p/1293373#M6194 Обязательно обновите прошивку вашего коммутатора до последней версии. 😀

EricE Guest	#11 31.05.2017 22:19:00 Это не единственные обходные пути. Их можно заменить 😀 У меня осталось всего две — и не терпится от них избавиться. Netgear всегда был ужасен в плане обновления прошивок.

Auzy1 Guest	#12 31.05.2017 22:08:00 Но играя роль адвоката дьявола, на большинстве других беспроводных точек доступа можно выбрать, включать ли функцию быстрого роуминга или нет...

Borwn

Guest

#13

31.05.2017 21:56:00

Привет, @RedTechie, можешь быстро объяснить, как это внедрить? У меня есть 2 XS712T, которые сейчас влияют на AP. Я добавил ACL на основе MAC-адреса источника, но ничего не изменилось. Я не совсем понимаю, как реализовать то, что ты предложил.

UI-Team Guest	#14 06.03.2017 23:15:00 Да, это верно. Наша реализация не требует поддержки со стороны клиента. Мы добавим эту поддержку позже, потому что большая часть преимуществ достигается и без её участия.

broadld

Guest

#15

19.04.2018 06:15:00

У нас тоже возникают такие проблемы с коммутаторами HP.

@peterdoo

Можешь объяснить, что именно ты сделал, чтобы решить эту проблему? Мне сложно понять твое объяснение. Если у тебя есть транк, ты имеешь в виду, что вместо транка, идущего от одного коммутатора к другому 47–47 и 48–48, нужно настроить 47–48 и 48–47? Спасибо, Дейв.

broadld

Guest

#16

18.10.2018 10:03:00

Нет, это нужно применять ко всем портам, подключенным к каждому WAP. Тогда пакет блокируется прямо у источника. После этого ACL должен быть применён на LAG, чтобы поймать любые порты, которые могли быть пропущены!

justanit Guest	#17 18.10.2018 09:59:00 Итак, мне просто нужно применить этот ACL на порт, который идет с Netgear на Unifi (канал вниз к коммутатору Unifi), и тогда всё будет отлично, верно?

broadld

Guest

#18

18.10.2018 09:50:00

Привет! Мы применили ACL к порту, подключенному к ACL, и к LAG, чтобы предотвратить распространение пакетов, если они всё же выходят наружу. ACL блокирует пакеты на основе MAC-адреса назначения. MAC-адрес назначения — 0180-c200-001c. Это именно тот MAC-адрес, из-за которого возникает бесконечный цикл. Очевидно, что ACL будет настроен по-разному на тех коммутаторах, которые подключены к вашим точкам доступа. Надеюсь, это поможет.

justanit Guest	#19 18.10.2018 09:40:00 @broadld Можешь показать ACL? Какие пакеты нужно блокировать? Информация нужна срочно.

justanit Guest	#20 15.10.2018 14:01:00 @Matt_VS Можешь показать ACL, как именно ты отфильтровал только проблемный мультикаст? Этот мультикаст идет на порты, которые не входят в состав LAG?

Читают тему (гостей: 1)