Перейти к содержимому
Калькуляторы

modnyman

Пользователи
  • Публикации

    31
  • Зарегистрирован

  • Посещение

О modnyman

  • Звание
    Абитуриент
  1. Предложения и пожелания компании MikroTik

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

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

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

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

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

    Как тогда выявлять перегрузку интерфейса? И не только перегрузку, а степень плачевности ситуации? "а вот на прием таким образом регулировать скорость не выйдет" ну, на этот случай fixed downlink теперь есть
  7. Оптимизация NV2 в ROS 6.42rc46 и nv2-downlink-ratio и fixed-downlink

    "очень и очень большим" - можно в более конкретных значениях для pcq? И всётаки, какой в этом смысл если есть буфер драйвера? Да и какбы не имеет смысла накапливать пакеты в том числе слабых клиентов, так как весь их шедуленный трафик сожрет кучу эфирного времени и усугубит перегрузку, тогда как дроп - заставит поумерить аппетиты. И кстати всегда мучал вопрос - каков размер буфера драйвера? Не могу инфу нигде найти внятную. Да и кстати, суммарный то размер очереди не такой уж малый, 250 килобайт. А потоки в свою очередь не накапливают много пакетов.
  8. Оптимизация NV2 в ROS 6.42rc46 и nv2-downlink-ratio и fixed-downlink

    @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. Ну и рисуем графики: Левый, левая шкала, зеленый график - дельта нагрузки в мегабитах. Левый, правая шкала, красный график - кол-во абонентов онлайн. Правый, левай шкала, желты график - дельта нагрузки в пакетах. Правый, плавая шкала, красный график - процент дропов - что есть в любом случае перегрузка. На слабо нагруженных базах дропов к слову нет вообще. Если увеличить длину очереди - не сказал бы что это особо увеличит скорость (хотя отчасти увеличит). Но пропадет информативность и время для "маневра", чтоб отреагировать на данную проблему. Да и вообще, я к этому решению довольно долго приходил, но пришлось прийти. Потому что бесит в микротике что невозможно понять когда иссякает емкость, не понять есть ли запас. Не понять когда абонент жалуется на скорость - не на базовой станции ли это? Срань полнейшая, почему из коробки это нельзя было сделать? Очень жажду любой критики и советов.
  9. Оптимизация NV2 в ROS 6.42rc46 и nv2-downlink-ratio и fixed-downlink

    А можно всётаки выдержку из документации с внятным описанием различий?
  10. Оптимизация NV2 в ROS 6.42rc46 и nv2-downlink-ratio и fixed-downlink

    @x-rayd в чем различие между ап энд клиент и просто клиент?
  11. Оптимизация NV2 в ROS 6.42rc46 и nv2-downlink-ratio и fixed-downlink

    @x-rayd Разъясните мне значения обоих параметров данной опции, возможно я изменю на ваш вариант)
  12. Оптимизация NV2 в ROS 6.42rc46 и nv2-downlink-ratio и fixed-downlink

    Омнитик, 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
  13. Микротик выпустил AC WAVE-2 девайсы!

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

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

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