Jump to content
Калькуляторы

nkusnetsov

Активный участник
  • Posts

    644
  • Joined

  • Last visited

Everything posted by nkusnetsov


  1. Возможно, в зависимости от модели микротика. Также от способа подключения к провайдеру и используемых протоколов. Описывайте задачу подробнее. Угадывать некогда.
  2. Когда у вас ещё много таких устройств, делать логирование на локальный диск - плохая идея. Переходите на action=remote и используйте syslog-сервер.
  3. Давайте попробуем конкретизировать состояние. Что в момент возникновения проблемы видно на стороне AP? Что в момент возникновения проблемы видно на стороне station? Флаг "R" в статусе беспроводного интерфейса есть? С обеих сторон? В registration-Table видны маки? Если да, то изменяется ли счётчик "Rx/Tx Frames" (скрытая колонка таблицы) ? Если проблема проявилась на клиенте (station), то другие клиенты должны нормально работать с AP, это так?
  4. @XGate , routerboot тоже обновляли с прошивкой?
  5. Плохая идея одинаково называть и очередь, и тип "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
  6. Сессии обрывать не будет. Таймаут применяется для сессий, в которых не передаются пакеты. Например, когда клиент отключился не передав TCP-Fin или момент завершения не удалось отследить трекингом, соединение считается условно "работающим" и хранится в таблице в течение указанного таймаута.   Там вообще 1 день (24 часа) по-умолчанию. 20 минут предложенные мной, это тоже с некоторым избытком. но уж чтобы человек был уверен, что не навредит.
  7. При наличии NAT включение conntrack обязательно. Но его необходимо тюнить. Дефолтное время tcp-established-timeout (1 day) надо уменьшать. Хотя бы до 00:20:00 (20 min).
  8. Начиная с 2017 года, с версии 6.41 не нужно создавать НЕСКОЛЬКО бриджей. В системе реализован bridge vlan filtering - новая идеология позволяющая разделять потоки фреймов по Vlan внутри одного bridge. Сформулируйте для начала цель уровня выше, для чего хотели делить трафик на два бриджа?
  9. @MikroUser , вам необходимо проделать следующее: 1) обязательно отказаться от порочной практики обращаться к серверу по IP-адресу. Так делают только криворукие 1Сники. 2) настроить split-DNS 3) обращаться к серверу по DNS (FQDN)
  10. Локальный IP пингуется независимо от состояния интерфейса. Это давным-давно так. В 6.3х точно уже было.
  11. @mitai1 , научитесь читать. Прочитайте сообщение от infery - там всё описано.
  12. Тогда по L3 балансировать проще. Если скорость у двух линков сильно разнится, можно грубо по ECMP балансировать. Тоньше можно по N-th packet балансироваться. Если хочется таки "прозрачный L2" за мост, но с балансировкой тоньше - пробросить EoIP между loopback и его несущий GRE разбалансировать по N-th между линками. Будет L2 сбалансированный по L3.
  13. @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.
  14. @alibek , если вы тестируете изнутри сети, то не сработает, т.к. in-interface изнутри сети другой, и для прохода "изнутри-внутрь" нужен nairpin nat. Если тестируете извне - важен порядок правил и не режется ли чего в forward. И не натится ли лишнего в src-nat Для тестирования изнутри сети лучше использовать: /ip firewall nat add action=dst-nat chain=dstnat comment=WAP1 dst-port=65101 dst-address=<public-ip> protocol=tcp to-addresses=10.20.0.101 to-ports=80 /ip firewall nat add action=masquerade chain=srcnat comment=hairpin-nat dst-port=80 src-address=10.20.0.0/24 dst-addtress=10.20.0.101 protocol=tcp
  15. @fanger , сейчас припрётся slv700 и начнёт топить за самонаводящуюся по[д]зорную трубу от cambium.
  16. Писать в техподдержку support@mikrotik.com прилагать серийный номер устройства и software-ID. Может быть, пойдут вам навстречу.
  17. А, ну тогда всё действительно сложнее. Как вариант, в микротике можно скриптом периодически активные маршруты из main переносить в именованые таблицы. Но это всё-же костыли.
  18. Правильно ли я понимаю, что "белые" IP у Вас только в количестве 3шт., на интерфейсах подключенных к провайдерам? Локальные сервисы находятся на локальных "серых" адресах? давайте абстрактный пример с адресацией подобной используемой Вами попробуем разобрать.
  19. @LostSoul , автоматом никак. У себя делаю альтернативные таблицы содержащие только другой default gateway. Они для исходящего трафика. Обычно только входящему трафику, нужны connected маршруты. Его запускаю в main по-умолчанию (или VRF, но это отдельная песня). Исходящий тоже по-умолчанию идёт по main. Только отдельным видам исходящего нужен альтернативный шлюз. Тогда его можно и пометить в mangle. Или PBR запилить.   Конкретно у Вас для чего хочется дублировать main? Выше уровнем какая задача?
  20. @LostSoul , может стОит подумать и изготовить из радиопрозрачного пластика одну похожую плитку? По слепку плитки отлить похожую цветом настенную панельку. Тем более, если висеть будет не на уровне глаз, а высоко-далеко.
  21. @LostSoul , общей частью обычно служит "main". Она может служить для обработки входящего извне трафика, например, при "пробросе портов". Исходящий же, обрабатывается по PBR, либо маркировками. Если я Вас правильно понял. Вот, тут можно глянуть еще : http://mum.mikrotik.com/presentations/RU18M/presentation_6157_1554717194.pdf
  22. @VolanD666 , вполне себе производится "Routing Adjustment" после Mangle-Output. Именно так и разруливается трафик самого роутера между несколькими аплинками.
  23. Для active/active лучше подниматься на L3 и балансировать нагрузку там. Если два параллельных моста, то самый простой ECMP уже даст плюс. Зная особенности работы и пропускной способности обоих мостов, можно попротокольно балансировать и вообще как угодно.