slv700

Вы хоть поняли сами что там написано ? Просто включите этот режим и посмотрите ARP Table.

У Asus есть режим Access Point, Wireless Router, Repeater , MESH . Режимы MESH и Repeater - у ASUS принципиально разные по протоколу доступа , структуре фреймов ( кадров), бриджингу и др. ТС может подключить вайфай Asus в сеть не по кабелю к роутеру Микротик ( работа обоих Асусов в Access Point mode), а один Асус по кабелю к роутеру, а второй Асус -по радио к первому Асусу в режиме Repeater. Первый АСус можно перевести в режим Wireless Router и поднять на нем DHCP и NAT. Тогда Микротик роутер в сети становится не нужным.

Нормальный у Asus MESH , правильный, но конечно, как у всех несовместимый с другими вендорами. И никакой он не аналог Капсмана, не имеющего никакого отношения к MESH. У микротик есть свой типа MESH, но на самом деле WDS типа динамический, он тоже проприетарный. Причем WDS сейчас редко где используется, только у устаревшего Микротик.

Задачи расширяются и обьекты растут? Известно ли вам что сеть на домашних (SOHO) вайфай роутерах НЕ масштабируется ? Имеющиеся у вас на данный момент проблемы с конективити и аутентификацией клиентов -это только цветочки. Ягодки появятся с увеличением количества вайфай роутеров в сети с перекрытием их зон покрытия ( обслуживания клиентов). Как клиент при перемещении будет переключаться между вайфай роутерами? Для этого нужен роуминг. Ошибочно думать что роуминг нужен только для уменьшения времени переключения клиента. На самом деле роуминг больше нужен для обеспечения масштабирования ( расширения ) сети. Универсальным и эффективным решением задачи масштабирования является поддержка так называемого бесшовного роуминга ( handover) по стандарту OKC/802.11r/k/v без разрыва соединения клиента с сетью на L3 выше до уровня приложений. Но обычно SOHO вайфай ротуеры, в том числе Микротик , не поддерживают бесшовный роуминг. У SOHO вайфай, в том числе Микротик бывает есть костыль - так называемый псевдо-роуминг, заключающийся в дисконекте клиента от вайфай роутера/точки доступа при снижении сигнала ниже заданного порога и поиске ( с перебором частотных каналов) новой точки доступа. Это как то работает при небольшом количестве в сети вайфай роутеров ( точек доступа) с низкой плотностью их размещения и перекрытии их зон обслуживания. При плотном размещении дисконекты клиентов, метание клиентов ( даже если они стоят на месте) между точками доступа и перерывы в связи до 5 секунд приводят к хаосу в сети. Кроме того, при подключении клиента к новой точке доступа клиент вынужден проходить процедуру повторной аутентификации , редиректиться на стартовую страницу Splash Page ( в сети HotSpot ) и иметь др. неприятности. Для исключения этого у Микротик применяется типа контроллер, запоминющий MAC адреса клиентов сети и предотвращающий например повторную аутентификацию старых клиентов сети при смене ими точек доступа. Видимо с этой целью ТС и поставил CapsMAN. Но это решение не работает при защищенном доступе 802.1x - MAC клиентов зашифрованы. Не работает это и при применении в сети WDS, MESH, Repeater когда реальные MAC клиентов не видны Капсману. Так что меняйте этот Микротик на что то более технологически продвинутое, современное и эффективное. Устаревший Микротик и его костыли не потянут современные задачи и расширение сети.

MAC клиента сделать видимым через репитер нельзя. Репитер светит наружу своим сгенерированным виртуальным MAC - одним на всех клиентов репитера. На каких то старых моделях TP-Link ( или Длинк, точно не помню) сделать видимым наружу МАС клиентов репитера ( у тплинк называется повторитель ) было можно, но что там все рано работало криво и от этого решения вендор отказался. На Микротик никакими костылями этого сделать точно нельзя. Репитер в 99% случаев работает в бридже и не поддерживает DHCP сервер и NAT. Мне известна только одна модель вайфай роутера - Cambium Residential Access Point r195 W, r200 и другие R серии, которые в режиме Repeater (client точки доступа) раздают через свой DHCP сервер своим клиентам IP адреса и делают на них NAT. Микротик этого делать не может. Вообще задача ТС решается применением MESH. Но MESH у разных вендоров бывает разный, несмотря на то , что на него есть стандарт 802.11s. Лучше всего и правильно MESH реализован драйверами Qualcomm-Atheros 802.11ax/WiFi 6, называется EasyMESH или MESH на платформе Broadcom. В реализациях это может называться OneMESH ( TP-Link). AirMESH ( Asus) и др. А вот например у Xiaomi wi-fi 6 MESH на самом деле это режим Repeater. Поэтому лучше всего ТС решить свою задачу на вайфай точках доступа/роутерах Wi-F i6 на платформе Atheros или Broadcom c поддержкой MESH. Микротик для решения задачи ТС- неудачный выбор.

Потому что точка доступа видит своего клиента ( репитер/ретраслятор ) и клиентов репитера под одним MAC, но с разными IP адресами. Поэтому аутентификация по MAC не работает. Нужно использовать другие типы аутентификации.

Это зависит от того для чего вам в этой схеме CAPsMAN. Для чего он вам там нужен ? На точке доступа Микротик на одном радио можно поднять раздачу, на другом - WDS. Поднять на одном wireless интерфейсе WDS и раздачу на вайфай Микротик нельзя ( на оборудовании других вендоров можно, но это MESH - типа динамический WDS). Также на одном wireless интерфейсе Микротик обычно нельзя поднять Repeater ( у Микротик это называется station-pseudobridge) и раздачу по wireless ( на оборудовании других вендоров можно), раздача возможна по Ethernet. Но это нужно проверять для каждой прошивки и это зависит ( IMHO и нужны дополнительные исследования) от точки доступа, на какой платформе MIPS или ARM работает бриджинг. В целом, эта задача нетривиальная для Микротик вайфай, как то там сделано все заумно и застарело. На современном оборудовании других вендоров ( необязательно премиальных Enterprise Access Point) такая задача решается легко, недорого и эффективно.

У вас нет никакого MESH. Проверьте , что ваши устройства AC-68U работают ТОЧНО в режиме Access Point, а не в Wi-Fi router, Repeater, AirMesh или MediaBridge. В случае Asus AC-68U в типовых настройках режима Access Point устройство и его вайфай клиенты получают IP адрес с внешнего DHCP сервера, в вашем случае с Mikrotik. Настройте правильно этот сервер на Микротик. Также на Микротик должен быть поднят NAT - трансляция публичного IP адреса в частные IP адреса вашей локальной сети, которые раздает DHCP сервер Микротик. Для проверки причины отвала клиентов от сети (по IP соединению , не по вайфай) смотрите на Микротик - какие и кому выданы IP адреса DCHP Leases и соответствие MAC и IP в ARP table. Если на Микротик все настроили правильно , но отвалы клиентов продолжаются, посмотрите , что происходит в ARP table Микротик. Если в момент потери клиентом соединения по IP сети,этот клиент не присутствует в ARP table Микротик ( а до этого был там) , то значит глючит софт Asus ( такое у него случается). Тогда обращайтесь в 4pda.ру, там наверняка знают о проблеме. И увеличьте DHCP lease time , по крайней мере проблема будет появляться реже.

А где тут узел MESH ? И вообще зачем нужен этот MESH в данной схеме?

Ну сколько можно говорить про тесты синтетическим трафиком в том числе iperf ? Я в таблице четко указал скорось в тестах UDP, в TCP на 10-15% меньше. Там же в таблице про скорость в тестах 300/600 Mbps в 40/80 Мгц правильно указано про ваш ubnt 5ac airmax? Проблема в том , что это только в тестах. В практике эксплуатации все не так красиво. Я еще раз говорю всем. В современном радио проведение тестов UDP/TCP - необходимое , но недостаточное условие оценки реальной пропускной способности канала . Только реальный трафик может показать реальную пропускную способность канала на тех или иных устройствах. И реальный трафик -это не торрентом загружать канал . Это должен быть трафик от сотен юзеров. В чем проблема показать нужный трафик хотя бы для одной из тысяч инсталяций? Нет таких инсталляций, ни одной ? Если нет,вообще нет ни одного случая, значит не может устройство пропускать трафик с заявленной скоростью.

Это все туфта и я обьяснил почему. Выложите пруфы - суточные графики загрузки трафиком с порта свича с линка в реальной коммерческой эксплуатации, а не тесты и не вашу галиматью.

Общая тенденция сейчас такая. У наших заказчиков -провайдеров есть очень много линков в поселки , установленные года 3-5 назад , в основном на Микротик 5, намного реже на Rocket 5AC/PB 5AC. В последнее время в связи с ковидом и ростом популярности OTT платформ ТВ ( спутниковые ТВ каналы у нас зачем то начали кодировать) значительно ( раза в два+ ) вырос трафик и пропускной способности каналов на этих устройствах ( max 220-230 Mbps) начало не хватать для поселков на 100-150+ дворов. Оптику тянуть в такие поселки нерентабельно, поэтому требуется апгрейд оборудования с получением пропускной способности радиоканала 300-400+ Mbps. Вот и смотрите, какой оборудование способно решить эту задачу.

Это результаты практической эксплутации , полученные за несколько лет от десятков наших заказчиков- больших и малых провайдеров ( FTTH, PON, BWA). Если у кого есть цифры реальной скорости больше , то пожалуйста, выкладывайте скрины как пруф. Тогда скорректируем таблицу.

Вот сравнительные данные по пропускной способности наиболее популярного оборудования, используемого для построения каналов точка-точка в диапазоне частот 5 ГГц. Надеюсь, это даст исчерпывающий ответ на вопрос ТС и даст определенное понимание предмета для людей, желающих строить беспроводные каналы точка-точка. PS Таблица моя, основана на моем и моих заказчиков знаниях и опыте работы с оборудованием ШБД.

CSMA RTS/CTS вместо OFDMA. Для этого шедулер ТД должен работать одновременноо в двух разных протоколах множественного доступа - случайный по временни доступ CSMA и frequency+time division.Я лично так не думаю, это слишком сложно в релизации и не задокументировано, что совместимость со старыми устройствами обеспечивается именно таким образом. Мой прогноз скорее положительный по работе именно по так называемой проблеме со скрытым узлом. Больше у меня сомнений в нагрузочной способности - сколько max клиентов тянет и с какой общей нагрузкой по трафику по крайней мере на дешевой платформе Atheros 802.11ax. На SDR 802.11ax ( Cambium cnPilotXirrus) сомнений в этом нет. Так что будем смотреть.

Да, это баг в линкпланере.

Это для Force 200 и то только для 40Мгц. Для Force 400 - 34 км для любой ширины канала и это есть ограничение в конфигурации реальных устройств.

А что в RouterOS можно генерировать трафик с заданным профилем ( пакеты разной длины) ? И там проблема не только в размерах пакетов, но и в типе трафика. Я уже говорил, что у 4-х ядерной платформs ARM Atheros есть акселератор NSS, для работы которого оптимизирован драйвер Atheros. В самых первых релизах 802.11ac wave 2 драйвер обрабатывал ( преобразовывал из Ethernet в Wireless фреймы) в NSS только обычные пакеты Ethernet, тегированные пакеты VLAN,туннель L2TP и еще что то , и был какой то баг ( тормоза) в PPPoE, вообще не обрабатывался QinQ и некоторые другие типы трафика. И можете себе представать что в любом синтетичеcком UDP/TCP тесте линк на Atheros 802.11ac wavw 2 пропускал в 80 МГц 550+ Mbps, а когда запустили реальный трафик c PPPoE, то получили полку в этих самых 220Mbps - то есть акселератор NSS на трафике PPPoE не работал. Или например бондинг PTP550 802.11ac wave 2 ( MU-MIMO 4x4) неадекватно распределял между двумя каналами MIMO 2x2 трафик MPLS ( и канал тормозился) и при этом замечательно распределял нагрузку между каналами в синтетических тестах. Аналогичная история была c тестами 802.11ax. Синтетика выдавала в 80 Мгц - 900Mbps. Запускаем реальный трафик - упираемся в те же 220 Mbps. Начали разбираться - увидели что идет тегированный трафик QinQ, а родной драйвер Atheros его на то время не обрабатывал. Убрали теги QinQ - и о чудо !!! полка 220М ушла. Что еще плохо обрабатывает NSS Atheros? Никто заведомо заранее не знает и это можно понять просто запустив реальный трафик на котором будет работать канал.

Ограничение режима ePTP Force 400C/425 - 34км. TDD для точка-точка нужен в основном для синхронизации, а также бондинга двух каналов на одну антенну как в PTP550. TDD на 802.11ax появится вместе с ePMP 4000/5000 в конце 2021.

Вы видимо по своей душевной простоте не понимаете , что речь идет не о медотике тестирования, а о том, что ТС хочет на PowerBeam 5AC на 3 км получить как заявлено в спецификациях 450Mbps. Это невозможно получить на PowerBeam 5AC ( и вообще в UBNT 5AC Airmax) ни в синтестическом тесте ( при любой методике тестирования ) , ни тем более на реальном трафике на любой дальности. Его потолок на реальном трафике 220Мbps даже если какой то синтетический тест покажет 300-350Мbps. И тот, кто хочет знать почему имеется такая разница, то поинтересуется , а как собственно тестируется канал, то есть методикой тестирования. А кто не хочет это знать по разным причинам, тот предпочтет попить пиво. Ясень пень, что реальный трафик может быть любой и 10Мbps и 100Мbps. Но речь идет о другом - об измерении максимальной пропускной способности канала реальным трафиком. А это значит. что при измерении нужно подать в канал максимально возможный реальный трафик пока он не упрется в полку. Главное в любой задаче - постановка задачи, а именно целевая фукция и критерии достижения требуемых значений параметров этой самой целевой функции. Это знает любой настоящий инженер, даже если он любитель попить пивка в свободное от работы время. В нашем случае целевая фунция - пропускная способность канала, а критерий - получение ее максимального значения на реальном трафике. В этом состоит цель тестирования и в данном случае не на синтетическом, а на реальном трафике. И в этом состоит ответ на второй и главный вопрос ТС "Какую реальную скорость можно на нём получить?" Ответ- ту, какую устройство покажет в тестах на максимальном реальном трафике.Тесты на максимальном синтетическом трафике покажут ложный результат. Какую же максимальную реальную скорость можно получить на реальном трафике? Мой ответ таков- для 5ГГц устройств на платформе Atheros 802.11ac - max 220-230 Mbps одинаково что в канале 40 Мгц, что в 80 Мгц. А это вся линейка UBNT 5AC Airmax и Mikrotik NV2 на MIPS и ARM 802.11ас ( например NetMetal 5 на MIPSBE 802.11ac ). Овет на вопрос, а какие устройста 5 Ггц дадут максимальную реальную скорость на реальном трафике больше 300-400 Mbps? Ответ : 1) устройства на платформе Atheros 802.11ac wave 2 ( а это Сambium, Radwin) 2) устройства на платформе Atheros 802.11ax ( Cambium) 3) устройства не на платформе Atheros - Cambium PTP450i, Сambium PTP670, UBNT AF5x HD, Infinet Vector 5 и др.). Это все. Тему можно закрывать.

Вот у вас 95% кабельных каналов связи, именно для тестирования таких каналов и предназначено ( типа сертифицировано ) ваше измерительное оборудование, в частности Fluke. В большинсте случаев это измерительное оборудование непригодно для тестирования радиоканалов и при их использовании получаются неадекватные результаты. Примеры такой неадекватности есть. Например известные в youtube примеры тестирования радиоканалов венгерской фирмой AccessPoint оборудованием EXFO по методике RFC 2544. Получаемые результаты в тестах этим прибором и другим, например Iperf и BT Mikrotik, отличаются в разы. Почему имеется такое различие я объяснял много раз здесь на форуме , да и самим венграм ( я с ними знаком). Возможно есть в измерительном оборудовании , в частности Fluke, режимы, предназначенные производителем для тестирования именно радиоканалов. Однако Fluke всего лишь производитель и он может делать режимы работы своего оборудования , соответвующие RFC. Других каких то сертифицированных требований к методике тестирования нет. Нет организаций, производищих такую сертификацию соответствия требованиям RFC. Но RFC для тестирования радиоканалов ( не релеек microwave) на базе wifi чипсета нет. Поэтому никакого сертифицированного для тестирования радиоканалов оборудования не существует. И все ваши тесты радиоканалов таким типа сертифицированным оборудованием совершенно определенно являются неадекватными и результаты недостоверными. Мои требования к тестирования радиоканалов просты.Я просто говорю что применение популярных ранее методик и инструментария, в частности OOKLA speedtest, Iperf TCP/UDP, ixChariot, Bandwidth Test Mikrotik, встроенные в радио оборудование MAC и UDP линк тесты есть необходимое , но недостаточное условие адекватной оценки пропускной споснобности радиоканала. А вот тестирование радиоканалом реальным трафиком есть необходимое и достаточное условие для адекватной (статиститески точной ) оценки пропускной способности ( и других параметров ) радиоканала. И я объяснил почему я так считаю и привел практические примеры применения таких тестов, подтверждающие мое утверждение, что именно так и есть в практике применения разного типа радиоборудования и инструментария их тестирования. Так я вам и говорю десятый раз, что ваше типа сертифицированное для тестирования кабельных каналов измерительное оборудование при применении для радиоканалов дает недостоверный ( ложный) результат, что никак не подтверждает соответствие предьявляемым к каналу заказчиком требованиям, в частности к пропускной способности радиоканала. ЗЫ У вас в голове каша, вы не понимаете логические взаимосвязи в предметной области радиооборудования и оценки параметров его работы. Натягивание совы на глобус типа применения sdwan Сisco для измерения пропускной способности радиоканалов связи - чушь, бред сивой кобылы :)

Есть понятие испытаний, цель которых -оценка степени соответствия обьетка испытаний ( в нашем случае это радиоканал) требуемым параметрам. Процесс испытаний состоит из нескольких этапов, первый их которых -измерение определенных параметров канала посредством тестов. Заключительный этап - опытная экплуатация обьекта ( в нашем случае работа канала на реальном трафике) , которая для особо ответственных систем может длиться годами. Для каждого этапа применяются соответcтвующее измерительное оборудование и методика статистической оценки параметров обьекта испытаний ( в нашем случае радиоканала). Я утверждаю, что 1) любой канал передачи данных перед сдачей заказчику в экплуатацию должен пройти все необходимые этапы испытаний. 2) нет универсального измерительного инструмента и методики испытаний для любого типа канала связи, и особенно радиоканала. 3) результаты испытаний на каждом этапе могут отличаться друга от друга. В случае испытаний радиоканала- это происходит чаще вследствие частой неадекватности оценки измерительным оборудованием параметров радиоканала и неадекватной методики статистической оценки ( имеющей место вследстие некоментентности людей, проводящих испытания в особенностях работы радиоканала) параметров канала. Это придумал не я. Это изучается в ВУЗе в соответующей дисциплинах. Об этом знают все разработчики оборудования - обьекта испытаний,которые сдают обьект заказчику. И я лично все это делал и не только в кабельных и радиоканалах коммерческого применения. Я здесь в теме хочу сказать лишь одно - ( третий пункт) результаты опытной экплуатации ( на реальном трафике) радиоканала , который может проводиться даже в течении только десятков минут может сильно отличаться от результатов тестирования на предыдущих этапах. И поэтому этот этап ОБЯЗАТЕЛЕН и остается обязательным основным критерием соответствия канала заявленным характеристикам. В случае оптического канала, или Ethernet таких различий может не быть, но вот в радиоканале это часто имеет место быть. И это особо касается любителей радиооборудования UBNT, где несоответствие декларируемых заявленных характеристик реальной работе оборудования в реальных условиях экплуатации имеет место быть в 99% случаев. Это проверено 12 летней практикой эксплуатации тысячами ( лично мне известны сотни ) провайдеров. UBNT - чемпион мира по забегам на столе ( тестам в идеальных условиях). К реальной практике эксплутации это не имеет НИКАКОГО отношения. Больше ничего я сказать не хочу, не надо мне приписывать всякую чушь и потом с этим бороться.

Чем же Сisco может помочь в тестировании радиоканалов? Если вы говорите что сеть построена на Cisco ( коммутаторы и роутеры ) то какое это имеет отношение к измерениям пропускной способности радиоканалов? Если у вас в голове есть эта ложная логическая взаимосвязь, то что мне думать о вас и вашей кометентности? Ну вы точно от сохи :)

С чего бы ?   Если там есть профайл с тестами радио, то не вопрос. Вы не понимаете физической природы измерений вообще, что и как измеряется в тестах ( испытаниях) радиоканала. Поэтому несете ахинею пионера, тестирующего свою сеть из говна и палок.   У нас есть свои "газпромы", мы знаем больше их самих что и как им нужно.   Ну и хорошо. Я совершенно определенно знаю разницу и между ррл и старым инфинет и камбиум и убиками. Лучше вникайте в то, что я вам говорю, а не бодайтесь не понимая природы некоторых вещей.

Кто завлял про "полностью RFC"? Это вы о чем :) Видели 3 моих варианта тестов и реального трафика? Если они у вас совпадают, то есть смысл вам подумать почему, потому что не должно быть этого, никак. А на убнт ( я так понял ваш конек :) соответствие канала спецификациям оборудования - это нонсенс. Кто сказал, что нужно сразу пускать по только что поднятому каналу коммерческий трафик? Сначала конечно тесты, начиная с встроенного Link test и дальше пройти все изложенные мною выше 3 этапа. При этом измеряется не только скорость, но и другие параметры канала связи, и на каждое измерение есть своя методика. Реальный трафик- финальная стадия.