Что я вижу на последней картинке в статье с переключениями терминала в 5 ГГц:
После шага 4 лучший кандидат для ТСД — канал в DFS-диапазоне (60), ТСД выбирает точку с уровнем хуже, но без DFS (40);
Все окружающие ТД — тоже в DFS, поэтому клиент висит до последнего, дожидается, наконец, точку на канале 44 и шестым шагом цепляется к ней;
В нижней части плана пока я не понял поведение клиента, если честно. Но в качестве рабочих гипотез предложил бы следующее:
Исключить каналы DFS (52-144 включительно) из ЧТП. Да, повысит уровень соканальных помех, но я не верю, что у вас одна ТСД жрёт постоянно 50+ мегабит;
Проверить, работает ли 11k в обеих ипостасях должным образом (то есть, в биконах есть репорты, и если клиент просит список соседей — он его получает ненулевым).
У точки может и не быть адреса, который будет виден пользователю и который можно попинговать "из воздуха". Даже так — по-хорошему, у точки такого адреса быть и не должно.
Виктор Платов — как раз и есть лицо вайфайной циски в России. Или, во всяком случае, был им. То есть, ближе к производителю в России не было никого. Но пруфы — это всегда хорошо, согласен.
Первый и пятый канал всё-таки пересекаются, даже если рейты 11b отключены. Legacy Preamble никто не отменял. Другой вопрос - насколько это важно.
Навскидку вижу минимум пять косяков, которые ещё осталось доисправить и которые, прямо скажем, противоречат всем best practices (а если у какого-то вендора не противоречат - то грустно оборудованием такого вендора пользоваться). Но статья классная, как ни крути - можно использовать как стартер на тех же собеседованиях. За это, безусловно, спасибо, апвоутнул.
Кстати, "на схеме" не видно антенн, потому что схемы не видно. Можно её как-то разместить? Интересно глянуть было бы.
прежде всего я бы рекомендовал посмотреть в сторону Ruijie Networks, затем DCN, у Maipu же, пожалуй, лучше не надо.
Но почему? У Maipu мне понравился работающий (в тех пределах, где я мог это оттестировать) RRM с вполне логичными настройками (да и вообще, возможностью его настроить). С DCN я бы был поосторожнее: помнится ещё прикол, когда контроллер на сто ТД после подключения ста ТД работать отказался, хехехе. К сожалению, это в лабе не оттестировать (по понятным причинам), да и, например, к себе ещё жду это железо.
А вообще, как всегда, в вайфае всё зависит от решаемых задач. Просто на Ruijie сети уже строились (и работают), а на Maipu — пока нет. Но аргументация всё-таки не помешала бы.
the exportation or reexportation, sale, or supply, directly or indirectly, from the United States or by U.S. persons, wherever located, to the Russian Federation of services, software, hardware, or technology incident to the exchange of communications over the internet, such as instant messaging, videoconferencing, chat and email, social networking, sharing of photos, movies, and documents, web browsing, blogging, web hosting, and domain name registration services, that is prohibited by the RuHSR, is authorized.
Я не особо хорош в чтении таких документов, и поправьте меня, если ошибаюсь, но вот, к примеру, обычный такой коммутатор доступа. Он же никак не подтягивается к этому документу. Для блоггинга, видеоконференций и веб-хостинга притянуть коммутатор доступа как необходимое оборудование можно лишь за такие длинные уши, что они могут оборваться. То есть, по сути, речь про ВКС, сервера какие-нибудь. Так?
Вообще, если помеху приходится искать во время сёрви - значит, её искать уже поздно :) Вы не думали для таких задач раскидывать сенсоры по объекту, собирать с них информацию и алярмить по достижению порогов? По-моему, у всех вендоров уже такие есть, с разным набором фич, выбирай - не хочу.
Это не жалобы, это очередное напоминание людям — хватит слушать кашель маркетологов на тему кекобитов, в реальной жизни в реальных применениях найти 160 свободных мегагерц в эфире вряд ли получится. Скорее всего, получится то, что измерено. Вот в этом смысл. Революций в очередной раз не будет, твёрдо и чётко.
Поставил минус за низкое качество материала. Количество фактических неточностей впечатляет.
Тот факт, что Вы пишете про CCNP Wireless, если честно, немного пугает. Неужели он у Вас есть, и Вы ни разу не попробовали, ну, к примеру, поставить две точки с одним SSID на 36 и 161 канал и запикапить процесс роуминга, чтобы не писать про "только после этого отключается от текущей точки доступа и переключается на новую точку доступа "?
О, про видимость с карьерной техники — это очень близкая тема.
Я спроектировал и участвовал в пусконаладке БШПД на двух карьерах. Баланс между "поднять антенну повыше, чтобы ловила получше" и "спрятать антенну получше, чтобы жила подольше" очень увлекательный и шаткий, а безэмоциональное пренебрежение механиков к "чужим" проводам — пугающее и утомляющее. Устройства, рассчитанные на работу в -60 градусов, при встрече с настоящими -60, с замёрзшей водичкой и ветерком, а не стерильным комфортом климатической камеры, грустнеют и расстраиваются.
Это один из тех моих проектов, в которые ты попадаешь, потому что на берегу не осознаёшь всей нетривиальности картины, но, благополучно выплыв, испытываешь неподдельную гордость за результат своих трудов. Так что, Фёдор, примите искренние слова уважения.
Ну так Вы спросили — я ответил. До сих пор ждём стандарта и наблюдаем чудесные несоответствия между клиентами на четвёртой версии черновика и ТД на второй.
Проверяли айперфом — вот что.
Очень малое количество приложений накапливает как можно больше данных, чтобы пихнуть их в одной зелёной части, сэкономив на всём оверхэде. Iperf этим известен (поэтому в вайфае он покажет жирнее, чем будет на самом деле почти в любом другом приложении). SMB умеет примерно так же вести себя — пофиг на задержку, пусть копится в буфере, потом вытолкаем в воздух одним куском, получим большие чиселки. А вот если поснимать кадры из воздуха на реально работающей сети, где люди и ютьюб смотрят, и по зуму говорят, и соцсети скроллят — то средняя длина payload как раз в районе 300 байт и будет.
То есть, если Вы планируете сеть, в которой один клиент будет пользоваться айперфом — да, ориентир в 75% Вы точно пробьёте. Если же это будет, к примеру, 4 клиента по 25 потоков (числа наугад, не обессудьте, просто описываю ситуацию) — уже нет, возможность копить данные на отправку потеряется, и оверхэд начнёт влиять сильнее.
Джет делал, мягко говоря, не честное сравнение. Я писал часть своих вопросов к тому тестированию, остановился на восьми нюансиках — всё равно ответа не получил, смысл продолжать.
Обязательно предложу. Обещаю.
Что я вижу на последней картинке в статье с переключениями терминала в 5 ГГц:
После шага 4 лучший кандидат для ТСД — канал в DFS-диапазоне (60), ТСД выбирает точку с уровнем хуже, но без DFS (40);
Все окружающие ТД — тоже в DFS, поэтому клиент висит до последнего, дожидается, наконец, точку на канале 44 и шестым шагом цепляется к ней;
В нижней части плана пока я не понял поведение клиента, если честно. Но в качестве рабочих гипотез предложил бы следующее:
Исключить каналы DFS (52-144 включительно) из ЧТП. Да, повысит уровень соканальных помех, но я не верю, что у вас одна ТСД жрёт постоянно 50+ мегабит;
Проверить, работает ли 11k в обеих ипостасях должным образом (то есть, в биконах есть репорты, и если клиент просит список соседей — он его получает ненулевым).
Из требований я понял, что, по сути, это teltonika моделей 9xx без аккумулятора. Автор, успехов в проекте!
У точки может и не быть адреса, который будет виден пользователю и который можно попинговать "из воздуха". Даже так — по-хорошему, у точки такого адреса быть и не должно.
Это половина нужной диагностики, потому что контроллер (и сама вайфай-сеть) видит клиента, так скажем, с другой стороны.
Хорошо, когда есть сенсоры вайфая, активный мониторинг — вот тут можно будет сравнить клиентскую статистику с эталонной клиентской статистикой.
Ну, если не одно — то близко к тому, Meraki официально в России никогда не присутствовали, так что все ТД были ввезены конкретными физическими лицами.
Да, я спросил лично Виктора, точно ли это не увод пароля — пока информации не получил.
Виктор Платов — как раз и есть лицо вайфайной циски в России. Или, во всяком случае, был им. То есть, ближе к производителю в России не было никого. Но пруфы — это всегда хорошо, согласен.
Первый и пятый канал всё-таки пересекаются, даже если рейты 11b отключены. Legacy Preamble никто не отменял. Другой вопрос - насколько это важно.
Навскидку вижу минимум пять косяков, которые ещё осталось доисправить и которые, прямо скажем, противоречат всем best practices (а если у какого-то вендора не противоречат - то грустно оборудованием такого вендора пользоваться). Но статья классная, как ни крути - можно использовать как стартер на тех же собеседованиях. За это, безусловно, спасибо, апвоутнул.
Кстати, "на схеме" не видно антенн, потому что схемы не видно. Можно её как-то разместить? Интересно глянуть было бы.
Но почему? У Maipu мне понравился работающий (в тех пределах, где я мог это оттестировать) RRM с вполне логичными настройками (да и вообще, возможностью его настроить). С DCN я бы был поосторожнее: помнится ещё прикол, когда контроллер на сто ТД после подключения ста ТД работать отказался, хехехе. К сожалению, это в лабе не оттестировать (по понятным причинам), да и, например, к себе ещё жду это железо.
А вообще, как всегда, в вайфае всё зависит от решаемых задач. Просто на Ruijie сети уже строились (и работают), а на Maipu — пока нет. Но аргументация всё-таки не помешала бы.
Меня вот что смущает (источник)
Я не особо хорош в чтении таких документов, и поправьте меня, если ошибаюсь, но вот, к примеру, обычный такой коммутатор доступа. Он же никак не подтягивается к этому документу. Для блоггинга, видеоконференций и веб-хостинга притянуть коммутатор доступа как необходимое оборудование можно лишь за такие длинные уши, что они могут оборваться. То есть, по сути, речь про ВКС, сервера какие-нибудь. Так?
Истории забавные, спасибо.
Вообще, если помеху приходится искать во время сёрви - значит, её искать уже поздно :) Вы не думали для таких задач раскидывать сенсоры по объекту, собирать с них информацию и алярмить по достижению порогов? По-моему, у всех вендоров уже такие есть, с разным набором фич, выбирай - не хочу.
>Многометровые стены из плотной листвы и побегов сильно поглощают радиосигнал
Идею закопать точки доступа в проходах не рассматривали?
Это не жалобы, это очередное напоминание людям — хватит слушать кашель маркетологов на тему кекобитов, в реальной жизни в реальных применениях найти 160 свободных мегагерц в эфире вряд ли получится. Скорее всего, получится то, что измерено. Вот в этом смысл. Революций в очередной раз не будет, твёрдо и чётко.
Поставил минус за низкое качество материала. Количество фактических неточностей впечатляет.
Тот факт, что Вы пишете про CCNP Wireless, если честно, немного пугает. Неужели он у Вас есть, и Вы ни разу не попробовали, ну, к примеру, поставить две точки с одним SSID на 36 и 161 канал и запикапить процесс роуминга, чтобы не писать про "только после этого отключается от текущей точки доступа и переключается на новую точку доступа "?
О, про видимость с карьерной техники — это очень близкая тема.
Я спроектировал и участвовал в пусконаладке БШПД на двух карьерах. Баланс между "поднять антенну повыше, чтобы ловила получше" и "спрятать антенну получше, чтобы жила подольше" очень увлекательный и шаткий, а безэмоциональное пренебрежение механиков к "чужим" проводам — пугающее и утомляющее. Устройства, рассчитанные на работу в -60 градусов, при встрече с настоящими -60, с замёрзшей водичкой и ветерком, а не стерильным комфортом климатической камеры, грустнеют и расстраиваются.
Это один из тех моих проектов, в которые ты попадаешь, потому что на берегу не осознаёшь всей нетривиальности картины, но, благополучно выплыв, испытываешь неподдельную гордость за результат своих трудов. Так что, Фёдор, примите искренние слова уважения.
www.ieee802.org/11/Reports/802.11_Timelines.htm
Очень малое количество приложений накапливает как можно больше данных, чтобы пихнуть их в одной зелёной части, сэкономив на всём оверхэде. Iperf этим известен (поэтому в вайфае он покажет жирнее, чем будет на самом деле почти в любом другом приложении). SMB умеет примерно так же вести себя — пофиг на задержку, пусть копится в буфере, потом вытолкаем в воздух одним куском, получим большие чиселки. А вот если поснимать кадры из воздуха на реально работающей сети, где люди и ютьюб смотрят, и по зуму говорят, и соцсети скроллят — то средняя длина payload как раз в районе 300 байт и будет.
То есть, если Вы планируете сеть, в которой один клиент будет пользоваться айперфом — да, ориентир в 75% Вы точно пробьёте. Если же это будет, к примеру, 4 клиента по 25 потоков (числа наугад, не обессудьте, просто описываю ситуацию) — уже нет, возможность копить данные на отправку потеряется, и оверхэд начнёт влиять сильнее.
Обязательно предложу. Обещаю.