modnyman

Во первых думаю не по этой причине данные протоколы до сих пор отсутствуют в ros. Во вторых уязвимости закрывают ведь со временем... Но вряд-ли это побудит добавить в прошивку поддержку данных протоколов. Так что не смотря на неудачный момент для пожелания, актуальность вопроса не снизится со временем. Разве не так?

Ещё пожелания принимаются? Что насчёт всяких 802.11r и 802.11k для полноценного роуминга?

Предложения и пожелания? Передайте пусть с тикетом 2017102922000739 разберутся. Пол года переписывались, когда дело дошло до "зайти на мою железку и посмотреть точно по моей инструкции" как воспроизвести проблему - они включили игнор мод.

Смогли. Все и так на радиусе и работает норм. Но! Монтажникам ведь надо иногда зайти на антенну у которой например пропала связь с бс, дабы продиагностировать... Я описал ситуацию в случае когда скомпрометирован данный пароль, или пароль для юзера локального с правами полиси.   В ссш сессии можно генерировать ответ и наблюдать его визуально. Всё-таки не ежедневная процедура. За несколько лет мне пришлось прибегнуть к ней 1 раз, при увольнении сотрудника... А по поводу учёта вообще - можно добавить строку кода и писать в файл результат. Я больше данную фичу использую для апдейта прошивок массового или для обновления конфига.

Долбится по адресам соответствующим критерию [/ip neighbor find]. Естественно можете более конкретизировать. Про ключи - ну, это вам немного теории лучше покурить. Там все не хитро, обычные rsa или dsa ключи. Позволяют авторизоваться без ввода пароля. Сгенерировать дело не хитрое, например в путти ген.

Как тогда выявлять перегрузку интерфейса? И не только перегрузку, а степень плачевности ситуации? "а вот на прием таким образом регулировать скорость не выйдет" ну, на этот случай fixed downlink теперь есть

"очень и очень большим" - можно в более конкретных значениях для pcq? И всётаки, какой в этом смысл если есть буфер драйвера? Да и какбы не имеет смысла накапливать пакеты в том числе слабых клиентов, так как весь их шедуленный трафик сожрет кучу эфирного времени и усугубит перегрузку, тогда как дроп - заставит поумерить аппетиты. И кстати всегда мучал вопрос - каков размер буфера драйвера? Не могу инфу нигде найти внятную. Да и кстати, суммарный то размер очереди не такой уж малый, 250 килобайт. А потоки в свою очередь не накапливают много пакетов.

@Timax Дело не хитрое Так как трафик везде у меня выходит даже с wlan c тегами, маркирую юникаст трафик вот так: /interface bridge filter add action=mark-packet chain=forward mac-protocol=vlan new-packet-mark=unicast out-interface=wlan1 packet-type=other-host vlan-encap=ip ВАЖНО: метод маркировки может отличаться, если точка является ещё и маршрутизатором - лучше брать трафик уже меченый под шейпер, если не шейпится тут - просто маркируйте в манглах весь айпи трафик. Дальше делаю дерево с родителем wlan интерфейсом: /queue tree add name=wlan1-tree parent=wlan1 /queue type add kind=pcq name=wireless-downlink pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-limit=10KiB pcq-src-address6-mask=64 pcq-total-limit=250KiB add kind=pfifo name=pfifo-downlink pfifo-limit=10 /queue tree add name=unicast packet-mark=unicast parent=wlan1-tree queue=wireless-downlink add name=non-unicast packet-mark=no-mark parent=wlan1-tree queue=pfifo-downlink Весь не маркированный трафик - не юникаст. Арпы там всякие, мультикасты... Нече ему делать в очереди с писикью классификатором. К вопросу почему такая короткая очередь: Хотелось бы узнать вообще мнение людей знакомых с теорией очередей, или просто знающих... Какую лучше длину очереди делать? Я брал общий размер из расчета на примерно 10 милисекунд при полной канальной утилизации, потом немного снизил и округлил. Длина на один поток взята минимальной, так как вообще не вижу смысла в этом месте шедулить трафик. Ведь за этой очередью следует очередь драйвера из которой осуществляется доступ к среде, агрегация кадров, смена порядка пакетов по 802.1p... Соответственно всё что задержалось в моем дереве - это перегрузка интерфейса, причем уже случившаяся. И тут возникает ещё аргумент не городить длинную очередь. Пакеты пойманные в дроп мы сможем отмониторить, и явно понять уровень перегрузки и построить график. Ну а дальше дело мониторинга. Всё что нам нужно есть в мибах кроме процента отброшенных пакетов. Но у нас есть oid-ы для общего числа пакетов и для числа дропов. По снятым значениям в заббиксе создаем ещё одно вычисляемое, где второе делим на первое и умножаем на 100. Ну и рисуем графики: Левый, левая шкала, зеленый график - дельта нагрузки в мегабитах. Левый, правая шкала, красный график - кол-во абонентов онлайн. Правый, левай шкала, желты график - дельта нагрузки в пакетах. Правый, плавая шкала, красный график - процент дропов - что есть в любом случае перегрузка. На слабо нагруженных базах дропов к слову нет вообще. Если увеличить длину очереди - не сказал бы что это особо увеличит скорость (хотя отчасти увеличит). Но пропадет информативность и время для "маневра", чтоб отреагировать на данную проблему. Да и вообще, я к этому решению довольно долго приходил, но пришлось прийти. Потому что бесит в микротике что невозможно понять когда иссякает емкость, не понять есть ли запас. Не понять когда абонент жалуется на скорость - не на базовой станции ли это? Срань полнейшая, почему из коробки это нельзя было сделать? Очень жажду любой критики и советов.

А можно всётаки выдержку из документации с внятным описанием различий?

@x-rayd в чем различие между ап энд клиент и просто клиент?

@x-rayd Разъясните мне значения обоих параметров данной опции, возможно я изменю на ваш вариант)

Омнитик, 30 радиоклиентов. Прошивка обновлена 24 числа. Видно что процент дропов на интерфейсе упал. Более детально воскресенье: раньше на такой нагрузке было до 2 процентов дропов. /interface wireless set [ find default-name=wlan1 ] adaptive-noise-immunity=client-mode ampdu-priorities=0,1,2,3,6,7 area=******** band=5ghz-a/n \ channel-width=20/40mhz-Ce default-authentication=no default-forwarding=no disabled=no frequency=5680 frequency-mode=superchannel \ guard-interval=long hw-retries=3 keepalive-frames=disabled mode=ap-bridge multicast-helper=full nv2-cell-radius=10 nv2-preshared-key=******** \ nv2-qos=frame-priority nv2-queue-count=8 nv2-security=enabled radio-name=******** scan-list=5100-5850 ssid=******** tdma-period-size=auto \ wireless-protocol=nv2

Во первых как она передавать то будет, когда эфир занят? Это уже в любом случае коллизия, даже если они не рядом. Но!... Вы видимо не внимательны. Вопрос именно про nv2 и при подключении к одной AP. Я как бы почти уверен, что мешать не будут. Но хотелось бы мнение со стороны услышать.

Прошел месяц - следов их присутствия на оборудовании вообще нет. Кстати, подскажите кто-нибудь, если 2 антенны подключенные к одной базовой станции работающей в nv2 расположить на одной мачте - будут ли у них возникать проблемы с качеством приема и передачи сигнала? Если да, то по каким причинам?

на базе по парочке или одному, чисто по этому получилось четко выявить как это проявялется база как правило sa5 nv2 то есть даже AC не используется. работает в n. если сигнал лучше примерно -55, то проблем то и нету. при сигналах ниже, во время работы "живой" сети и предположительно на перегрузках возникают "фризы" периодом скачет ласт эктив до одной секунды и проваливается в минимум модуляция от базы к клиенту. проверено в разных локациях (регионах). списать на шум не получится. меняется антенна на обычный лайт - проблемы нет. причем коли это N режим - проблема либо хардварная (что мало вероятно) либо в драйвере чипа микротиковском. много где видел на форумах в том числе микротиковском, что жалуются на ацшки, но нигде не видел никакой конкретики. Что-то плохо, а что конкретно? Здесь тоже не ответили когда писал примерно той зимой. Вообще не нашел информации о наблюдениях проблем в виде показателей сигнала модуляций или перегрузок интерфейсов. Пришлось отрисовать заббиксом всё что рисовалось, вплоть временного графика процента дропов на очереди на интерфейсе. Картина стала совсем очевидной. Ну и началась долгая переписка, мол вот смотрите сюда и сюда, вот проблема, вот так проявляется.

Я смог воспроизвести у себя на сети проблемы с AC устройствами так, чтобы это отражалось в некоторых показателях состояния в реалтайме и в данных мониторинга. Переписка была долгой, сейчас будут разбираться удаленно, так как у себя они опять же проблему не смогли воспроизвести. Надеюсь что-то всё-таки решат. Но не об этом... в процессе переписки вот такое писали: Soon we will try to optimise the Nv2 wireless protocol to work more reliable with multiple wireless clients. If you have some suggestion which setups with multiple clients to test we might try to simulate them in the lab. Надеюсь это "Soon" будет действительно в обозримом будущем.

Делаю без сторонних средств так: :foreach i in=[/ip neighbor find] do={/system ssh command="/user set admin password=qwerty" address=[/ip neighbor get $i address]}; Естественно изначально во всех тиках есть пользователь рут с публичным rsa ключом. В тике с которого выполняю команду у тогоже пользователя есть приватный ключ. Обновляю прошивки кстати также централизованно. И меняю конфиги в случае необходимости. Аплодисменты :D

Вы когда в логи обоих маршрутизаторов смотрели - прям вобще вобще ничё не смущало?

Попадалось именно такое поведение не раз и не только на хексах. Причины всегда были - либо физика кабеля, либо не до конца догоревший в грозу удаленный порт, который в свою очередь мог неделю работать лишь чутулю подсыпая ошибок, потом начать валиться каждые N секунд (при том роняя все туннели, ospf, ... но это уже совсем другая история). И вообще это не редкость например когда кабель метров скажем 150 одна железка может пробить, другая не может. У меня нет углубленных познаний в стандарты физики эзернета (вольтажей там и прочей чувствительности), но на практике не все йогурты одинаково полезны. Это я к чему про метраж... у вас хоть и не 150 метров, но мало ли где есть не явная проблема. Место изгиба например, где вносится дополнительное сопротивление.

в ченджлогах рк сборок есть пунктик *) wireless - added "allow-signal-out-off-range" option for Access List entries (CLI only); в вики пока нет описания, но есть на форуме... вобщем дергать не будет если воспользуешься. а в остальном мне добавить нечего, сам сделал бы также.

Никто не подскажет? Даже Saab не предложит поставить 2 микротика?)) Не, ну серьезно... Может замудрено сильно описал... Вопрос коротко состоит в том, моно ли каким либо способом применять 2 действия к пакету (нетмап и срцнат) после определения маршрута (а точнее интерфейса, через который пакет выйдет с маршрутизатора)?

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

Это талант, чтоб в тексте так акцент изобразить. Глаза думал сломаются. Я так понял один провайдер с гуглокешем, второй - без. Раздайте всем днсы того кто с гуглкешем (так как на них все эти гуглокеши и завязаны). Возьмите в райпе все префиксы того, кто с гуглокешем. Роутите по этим префиксам всех в этот аплинк, независимо от того, куда клиента пнула балансировка по аплинкам. Файловера в таком случае не ждите полноценного. При падении этого аплинка - упадут все. По большому счету всё банально просто...

если аплинков больше одного, или скорость линка аплинка больше скорости линка даунлинка - это микроберсты. если есть проблемы с iptv или voip - нужно уже добираться до кольцевого буфера сетевой карты (не уверен что это возможно на вашем железе) и делать QoS по 802.1p, предварительно раздав классы. если такой возможности нет - делайте дерево на интерфейс (скорее не влан а эзернет) или просто вешайте pfifo, с расчётом максимально возможных берстов. в случае с деревом должно получиться обеспечить qos, а если pfifo - в худшем случае получите вместо микроберстов микроджиттер)). поправьте если где не прав, с qos-ом знаком не так давно и не в полной мере. не парьте себе мозги пингами или бтестами. у пинга слишком высок интервал у бтеста полоса ровная только кашу в голове создадите так ничего и не поняв и не поправив. вобщем проблема то не страшная и не проблема вовсе... это не баг, это фича))

Представим ситуацию: Есть 2 аплинка. Локальные пользователи натятся в оба канала (алгоритм разброса не важен). Есть 2 таблицы маршрутизации, с файловерами. В чём встает вопрос: Сейчас у многих провайдеров есть свои гуглкеши итд итп. Желание их использовать принуждает днс запросы направлять именно на серверы провайдера через которого локальный пользователь смаршрутизировался согласно балансировке. Дело не хитрое: Пользователям раздали вместо днсов 2 фейковых адреса. Отмаркировали в мангл прероутинге и отправили исходящий трафик в нужную таблицу маршрутизации. Согласно Packet_Flow_v6 цепочка дстнат обрабатывается после прероутинга. Ну и отлично, согласно окраске трафика сделали 4 правила нетмапа (по 2 на днс адреса аплинка со своих 2 фейковых). Ну и на выходе они ещё и срцнат сделали. Всё казалось бы отлично - само разбалансировалось, у днс запросов подменяется как назначение (для подстановки нужных днсов), так и источник (срцнат). НО Как только упадет какой-то из аплинков - днс запросы всех с упавшего, будут пропрежнему мапиться в днсы упавшего, но по факту вылетать с неупавшего. Естественно на них никто и не ответит. Задача: Делать срц нат и дст нат после routing decision (мое предположение что именно после него). Срц нат раньше делать нельзя я так понимаю (опять же не отработает файловер и много чего необходимого в форвард). Но и нетмап становится необходимо перенести в цепочку срц нат. Вопрос: Можно ли как-то это сделать? Модно ли примерить одновременно и нетмап и маскарад в цепочке срц нат? 2 экшна я так понимаю нельзя применить к пакету в таблице нат. В других цепочках то что необходимо сделать - сделать нельзя. Единственное за что можно зацепиться - не доконца понимаю все экшны в цепочках нат... Есть у кого идеи как такое провернуть? Или может есть более элегантные способы. Наскриптить не предлагайте, сам напишу, но это будет наипоследнейшим вариантом.