Пульс пропал / Отключился после обновления до 3.2.1.

Пульс пропал / Отключился после обновления до 3.2.1., UniFi Network

rkennard

Guest

16.07.2014 23:15:00

У меня 6 локаций с 8 UAP-LR. Контроллер установлен на основной локации. Вчера я обновился с версии 2.4.6 на 3.2.1, и все AP на удаленных площадках начали показывать "heartbeat missed" и отключаться. Через несколько минут AP снова подключается. AP, расположенные в той же локации и в той же подсети с контроллером, работают отлично. Я попробовал забыть AP и потом снова принять его. Настроил DNS, чтобы "unifi" указывал на мой контроллер. Удалил установку, установил новую и восстановил из резервной копии. Не знаю, что еще попробовать.

gmartine

Guest

26.05.2015 13:44:00

@UBNT-MikeD

@PrisonMoose
Ошибки все еще видны. Посмотри на эту тему https://community.ui.com/questions/dd221737-2423-430a-808d-4c52693d384f. Буду продолжать обновлять эту тему по мере появления новых находок. Действительно странно, что даже с новым провайдером облачных сервисов у вас все еще возникают эти проблемы.

PrisonMoose

Guest

25.05.2015 23:37:00

@gmartine

Какие-нибудь новости? Проблема всё ещё возникает после отключения IPv4 Offload? У меня была точно такая же проблема с 3.2.10 и AWS ещё некоторое время назад. Я обновился до 4.6 и столкнулся с той же проблемой. Заметил, однако, что мой TS8 тоже фиксировал падения на ссылках для каждого AP. Конечно, при более детальном рассмотрении оказалось, что падения ссылок коррелируют с падениями, которые видит контроллер. Я забросил свой экземпляр AWS и вернулся к контроллеру, установленному на локальной площадке, и проблема исчезла. Вчера ночью я решил попробовать облачный контроллер ещё раз, на этот раз с DigitalOcean. Я настроил VM Ubuntu 14.04 и запустил один из удобных скриптов, которые нашёл на форуме. После того, как я немного понаблюдал за своим контроллером, я начал видеть злополучные "пропущенные heartbeat", за которыми следовало "Disconnected" на минуту или две. У меня тоже есть ERL между моим коммутатором (больше не TS8) и провайдером пропускной способности, поэтому я был бы заинтересован в результате отключения IPv4 offload.

gmartine

Guest

21.05.2015 19:46:00

@UBNT-Bryan

@UBNT-Tai

@andyc

Вот небольшое обновление по этому вопросу. Я открыл два обращения в службу поддержки: 151769 и 179784. Первое было закрыто. Я его переоткрыл, и это создало второе. Сегодня я получил письмо, в котором говорилось, что одной из возможных причин потери информационных пакетов может быть IPv4 offload в моем ERL. После отключения IPv4 offload у меня была только одна ошибка за три часа. Просто к сведению.

gmartine Guest	#5 10.03.2015 18:29:00 @UBNT-Bryan Контроллер перезагрузили в любом случае.

andyc Guest	#6 10.03.2015 18:24:00 😳

UI-Team Guest	#7 10.03.2015 18:08:00 Эта конкретная конфигурация находится в контроллере, а не на устройствах, поэтому повторное развертывание не требуется, но нужно перезагрузить контроллер.

CodyLoco

Guest

26.03.2015 23:54:00

Просто чтобы уточнить, проблема с AWS, с которой я столкнулся, заключалась в случайном завершении сессии UI (через несколько секунд) и необходимости повторного входа в UI. В моем случае, обновление с t2.micro на t2.small эту проблему решает… По самeму сердцебиениям никаких проблем не заметил, если только они не в моих логах…

UI-Team

Guest

26.03.2015 23:24:00

@gmartine

Можешь, пожалуйста, запустить сниффер из другого экземпляра, а не прямо на экземпляре с контроллером? Похоже, что TCP-фреймы, которые не видит сниффер, не видит и контроллер. Но сторонний наблюдатель должен их увидеть.

UI-Team

Guest

#10

26.03.2015 23:14:00

@
@gmartine, мы тоже видим эти потерянные пакеты даже на нашем AWS.

@CodyLoco развернул 4.6.3 на VM на http://www.softlayer.com/ и не видит этих проблем. У него также есть виртуальные машины на бесплатном тарифном плане AWS, где потерянные пакеты остаются. Сейчас предлагается выявить причину с помощью инструментов генерации трафика и поработать с AWS, чтобы понять, где может происходить эта потеря пакетов.

gmartine

Guest

#11

26.03.2015 23:09:00

@UBNT-Bryan

Да. Это тот же самый сервер AWS t2.micro instance. Странно. Кажется, как ты и говорил, ты потерял тот же сегмент, и, скорее всего, ретрансляция не дошла? Обновление инстанса до чего-то с большим количеством сетевых ресурсов не решило проблему. Это было предложение от Amazon, так как сетевые ресурсы общие. Обрати внимание, у меня только один AP в контроллере.

UI-Team

Guest

#12

26.03.2015 22:43:00

@gmartine

Спасибо за этот захват. Во всех трёх случаях отсутствует предпоследний TCP-сегмент. На этом же месте есть TCP Window Update от сервера, что указывает на возможную слишком медленную обработку данных из сети. Вопрос: захват делался на той же машине, где запущен контроллер?

gmartine

Guest

#13

25.03.2015 18:56:00

@UBNT-Bryan

Привет, Bryan. Без проблем. Вот еще один трассировка пакетов, показывающая проблему. Посмотри на следующие TCP потоки. Пожалуйста, скачай файл по ссылке: https://drive.google.com/a/wayuutech.com/file/d/0Bwy8Y9Zn513CYnhhaGxhX29NNk0/view?usp=sharingtcp.stream eq 37tcp.stream eq 60tcp.stream eq 63. Буду рад попробовать файл. Я уже совсем запутался. AWS предположили, что у меня могут быть проблемы с моим инстансом AWS. Я обновил инстанс, но ничего не изменилось, ошибки остались. Я сейчас настроил MTU на сервере на 1500, но все еще вижу ошибки.

UI-Team

Guest

#14

25.03.2015 18:31:00

@gmartine

Спасибо, что собрали этот сниффер-захват. Я не вижу никаких информов от AP, так как самый большой фрейм в захвате — всего 208 байт, этого недостаточно для информа. Я могу воспроизвести ошибку таймаута получения информа, но только на очень медленной ссылке, а у вас её нет, поэтому ваш случай полезен для отладки. Если возможно, я хотел бы предоставить вам файл ace.jar, который можно просто заменить, и он будет содержать дополнительные сообщения для отладки, которые могут помочь найти проблему.

noanz Guest	#15 25.03.2015 13:26:00 Есть какие-нибудь новости по этому вопросу?

gmartine

Guest

#16

10.03.2015 18:06:00

@andyc

Вот дамп сетевого трафика, который я захватил между облачным сервером и точкой доступа в момент возникновения проблемы. Я ничего подозрительного не вижу. Не знаю почему, но у меня проблемы с публикацией pcap-файла. ***Форум не любит pcap-файлы***. Я его заархивировал. Поехали!

UI-Team Guest	#17 10.03.2015 18:06:00 Да, это то же самое значение для Linux.

andyc Guest	#18 10.03.2015 17:46:00 Ну, если ты можешь пинговать без потерь, как видишь, это не связано с MTU. Честно говоря, я в тупике.

gmartine

Guest

#19

10.03.2015 17:19:00

@andyc

Спасибо, Энди! Мой MTU равен 1500 по всей сети. Вот ping с установленным флагом DF (do-not-frag). Хост, с которого я отправляю ping, находится в середине облака Unifi и моего AP-PRO. Поэтому я не могу воспроизвести какие-либо проблемы с MTU.

wayuu@felipe:~$ sudo ping -M do -s 1472 192.168.1.10
PING 192.168.1.10 (192.168.1.10) 1472(1500) bytes of data.
1480 bytes from 192.168.1.10: icmp_req=1 ttl=64 time=0.519 ms
1480 bytes from 192.168.1.10: icmp_req=2 ttl=64 time=0.441 ms
1480 bytes from 192.168.1.10: icmp_req=3 ttl=64 time=0.427 ms
1480 bytes from 192.168.1.10: icmp_req=4 ttl=64 time=0.439 ms
^C
--- 192.168.1.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.427/0.456/0.519/0.042 ms

wayuu@felipe:~$ sudo ping -M do -s 1472 ec2-54-175-189-107.compute-1.amazonaws.com
PING ec2-54-175-189-107.compute-1.amazonaws.com (54.175.189.107) 1472(1500) bytes of data.
1480 bytes from ec2-54-175-189-107.compute-1.amazonaws.com (54.175.189.107): icmp_req=1 ttl=53 time=26.4 ms
1480 bytes from ec2-54-175-189-107.compute-1.amazonaws.com (54.175.189.107): icmp_req=2 ttl=53 time=27.5 ms
1480 bytes from ec2-54-175-189-107.compute-1.amazonaws.com (54.175.189.107): icmp_req=3 ttl=53 time=26.1 ms
^C1480 bytes from ec2-54-175-189-107.compute-1.amazonaws.com (54.175.189.107): icmp_req=4 ttl=53 time=27.4 ms

--- ec2-54-175-189-107.compute-1.amazonaws.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 26.183/26.907/27.534/0.624 ms
Я все еще могу понизить MTU. Дайте знать.

andyc Guest	#20 10.03.2015 17:06:00 Ты упоминал MTU ранее – пробовал уменьшить MTU на точке доступа до 1000, просто чтобы проверить, нет ли у тебя проблемы с MTU на соединении? Я сталкивался с этим только на VPN, но стоит попробовать, учитывая, что ты периодически теряешь пакеты. Cheers, Andrew

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