nkusnetsov

عن طريق اختيار المستخدم في نقطة الاتصال لكل مستخدم سرعته الخاصة

Возможно, в зависимости от модели микротика. Также от способа подключения к провайдеру и используемых протоколов. Описывайте задачу подробнее. Угадывать некогда.

Когда у вас ещё много таких устройств, делать логирование на локальный диск - плохая идея. Переходите на action=remote и используйте syslog-сервер.

Студенты пишут курсовичек.

Давайте попробуем конкретизировать состояние. Что в момент возникновения проблемы видно на стороне AP? Что в момент возникновения проблемы видно на стороне station? Флаг "R" в статусе беспроводного интерфейса есть? С обеих сторон? В registration-Table видны маки? Если да, то изменяется ли счётчик "Rx/Tx Frames" (скрытая колонка таблицы) ? Если проблема проявилась на клиенте (station), то другие клиенты должны нормально работать с AP, это так?

@XGate , routerboot тоже обновляли с прошивкой?

Плохая идея одинаково называть и очередь, и тип "PCQ_ALL". По классификатору "по src+dst address + port." лимит ставится не на каждого клиента, а на каждое отдельное его соединение. Клиент открывший 100 соединений, получит ёмкость больше, чем клиент открывший 10 соединений. Насколько помню, если очередь имеет дочерние очереди, она перестаёт сама работать на ограничение отдельных клиентов. Она лишь "забирает трафик" для группы дочерних очередей. Чтобы работало, Вам надо создать еще одну общую дочернюю очередь и расположить ниже: /queue simple add max-limit=5M/20M name=PCQ_ALL queue=PCQ_ALL/PCQ_ALL target=\ 192.168.90.0/24,192.168.91.0/24 add disabled=yes max-limit=1M/3M name=0227 parent=PCQ_ALL target=\ 192.168.90.147/32 add max-limit=5M/20M name=other parent=PCQ_ALL target=\ 192.168.90.0/24,192.168.91.0/24

Сессии обрывать не будет. Таймаут применяется для сессий, в которых не передаются пакеты. Например, когда клиент отключился не передав TCP-Fin или момент завершения не удалось отследить трекингом, соединение считается условно "работающим" и хранится в таблице в течение указанного таймаута.   Там вообще 1 день (24 часа) по-умолчанию. 20 минут предложенные мной, это тоже с некоторым избытком. но уж чтобы человек был уверен, что не навредит.

При наличии NAT включение conntrack обязательно. Но его необходимо тюнить. Дефолтное время tcp-established-timeout (1 day) надо уменьшать. Хотя бы до 00:20:00 (20 min).

Начиная с 2017 года, с версии 6.41 не нужно создавать НЕСКОЛЬКО бриджей. В системе реализован bridge vlan filtering - новая идеология позволяющая разделять потоки фреймов по Vlan внутри одного bridge. Сформулируйте для начала цель уровня выше, для чего хотели делить трафик на два бриджа?

@MikroUser , вам необходимо проделать следующее: 1) обязательно отказаться от порочной практики обращаться к серверу по IP-адресу. Так делают только криворукие 1Сники. 2) настроить split-DNS 3) обращаться к серверу по DNS (FQDN)

Локальный IP пингуется независимо от состояния интерфейса. Это давным-давно так. В 6.3х точно уже было.

@mitai1 , научитесь читать. Прочитайте сообщение от infery - там всё описано.

Тогда по L3 балансировать проще. Если скорость у двух линков сильно разнится, можно грубо по ECMP балансировать. Тоньше можно по N-th packet балансироваться. Если хочется таки "прозрачный L2" за мост, но с балансировкой тоньше - пробросить EoIP между loopback и его несущий GRE разбалансировать по N-th между линками. Будет L2 сбалансированный по L3.

@npokypop , про MSTP правильно - своя логическая топология будет у каждого vlan. Но тогда следом встаёт вопрос - как разбросать между двумя vlan, и желательно с учётом качества линков. Динамический замер качества и перестроение работают при active/backup. При active/active пропорцию для балансировки, если скорость линков может изменяться, автоматически посчитать - задача нетривиальная. Гораздо проще для балансировки, если исходить из некоей заранее рассчитанной, гарантированной скорости линка. Касательно загрузки процессора - она незначительно вырастет. Из эфира в кабель и обратно весь трафик всегда идет через CPU(bridge) и современные процы справляются. Справочно, при выборе оборудования можно глянуть в строку таблицы "bridging 25 bridge filters". Железки на 716MHz ARM начинают упираться в CPU при пакетной нагрузке ~220-240 kpps. Это неплохой результат. MIPSBE на 650MHz деградирует значительно раньше, при ~60-70 kpps.