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

nkusnetsov

Активный участник
 Просмотреть профиль  Активность

  • Публикации

    644

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

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем nkusnetsov

  1. Опубликовано · Изменено пользователем nkusnetsov · Жалоба на ответ

    В 06.05.2022 в 09:03, aymanalnooah сказал:

    وКак я могу разрешить клиентам выбирать подходящую для них скорость интернета на странице точки доступа в Mikrotik, помогите пожалуйста

    FB_IMG_1651802869857.jpg

     

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

  2. Опубликовано · Жалоба на ответ

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

  5. Опубликовано · Изменено пользователем nkusnetsov · Жалоба на ответ

    18 часов назад, XGate сказал:

    но по радио соединение более не устанавливается.

    Давайте попробуем конкретизировать состояние. Что в момент возникновения проблемы видно на стороне AP?
    Что в момент возникновения проблемы видно на стороне station?

    Флаг "R" в статусе беспроводного интерфейса есть?  С обеих сторон?

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

  7. Опубликовано · Жалоба на ответ

    В 14.02.2020 в 13:16, xphoenix сказал:

    /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

    Плохая идея одинаково называть и очередь, и тип "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

  8. Опубликовано · Изменено пользователем nkusnetsov · Жалоба на ответ

    10 часов назад, rdmitrich сказал:

    Будет обрывать tcp сессии через 20 минут

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

     

    2 часа назад, Pinkbyte сказал:

    Вам точно нужны TCP-сессии, где не бегают keepalive-ы аж 20 минут?! :

    Там вообще 1 день (24 часа) по-умолчанию. 20 минут предложенные мной, это тоже с некоторым избытком. но уж чтобы человек был уверен, что не навредит.

  9. Опубликовано · Изменено пользователем nkusnetsov · Жалоба на ответ

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

     

  10. Опубликовано · Жалоба на ответ

    В 17.12.2019 в 11:34, ShyLion сказал:

    Нужно траффик в нативном вилане без тега  призмлить в бридж bridge1, траффик в вилане Y в бридж bridgeY.

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

  11. Опубликовано · Изменено пользователем nkusnetsov · Жалоба на ответ

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

    3) обращаться к серверу по DNS (FQDN) 

  12. Опубликовано · Жалоба на ответ

    В 17.09.2019 в 14:21, msdt сказал:

    В последних версиях RouterOS ip-адрес на интерфейсе продолжает пинговаться, даже если линка в дауне. Интересно, это баг или официально объявленное изменение поведеения?

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

  14. Опубликовано · Жалоба на ответ

    20 часов назад, npokypop сказал:

    скорость линков мы знаем. Понятное дело что система будет не динамическая а статическая

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


     

  15. Опубликовано · Изменено пользователем nkusnetsov · Жалоба на ответ

    @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.

  16. Опубликовано · Изменено пользователем nkusnetsov · Жалоба на ответ

    @alibek , если вы тестируете изнутри сети, то не сработает, т.к. in-interface изнутри сети другой, и для прохода "изнутри-внутрь" нужен nairpin nat.
    Если тестируете извне - важен порядок правил и не режется ли чего в forward. И не натится ли лишнего в src-nat
     

     

    6 часов назад, alibek сказал:

    /ip firewall nat add action=dst-nat chain=dstnat comment=WAP1 dst-port=65101 in-interface=pppoe-out1 protocol=tcp to-addresses=10.20.0.101 to-ports=80

    Для тестирования изнутри сети лучше использовать:
    /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 

  19. Опубликовано · Изменено пользователем nkusnetsov · Жалоба на ответ

    А, ну тогда всё действительно сложнее.
    Как вариант, в микротике можно скриптом периодически активные маршруты из main переносить в именованые таблицы.

    Но это всё-же костыли.

  20. Опубликовано · Изменено пользователем nkusnetsov · Жалоба на ответ

    24 минуты назад, LostSoul сказал:

    сть multihomed сервер ( на нем IP трех разных провайдеров ) 

    Правильно ли я понимаю, что "белые" IP у Вас только в количестве 3шт., на интерфейсах подключенных к провайдерам?
    Локальные сервисы находятся на локальных "серых" адресах?
    давайте абстрактный пример с адресацией подобной используемой Вами попробуем разобрать.

     

  21. Опубликовано · Изменено пользователем nkusnetsov · Жалоба на ответ

    @LostSoul , автоматом никак.
    У себя делаю альтернативные таблицы содержащие только другой default gateway. Они для исходящего трафика.
    Обычно только входящему трафику, нужны connected маршруты. Его запускаю в main по-умолчанию (или VRF, но это отдельная песня).
    Исходящий тоже по-умолчанию идёт по main.

    Только отдельным видам исходящего нужен альтернативный шлюз. Тогда его можно и пометить в mangle. Или PBR запилить.

     

    1 час назад, LostSoul сказал:

    получить main и две дублирующих ее таблицы роутинга , чтоб в них было все как в main но другой default gateway?

     

    Конкретно у Вас для чего хочется  дублировать main? Выше уровнем какая задача?

  22. Опубликовано · Изменено пользователем nkusnetsov · Жалоба на ответ

    @LostSoul , может стОит подумать и изготовить из радиопрозрачного пластика одну похожую плитку? По слепку плитки отлить похожую цветом настенную панельку. Тем более, если висеть будет не на уровне глаз, а высоко-далеко. 

  23. Опубликовано · Жалоба на ответ

    @LostSoul , общей частью обычно служит "main". Она может служить для обработки входящего извне трафика, например, при "пробросе портов". Исходящий же, обрабатывается по PBR, либо маркировками.
    Если я Вас правильно понял.
    Вот, тут можно глянуть еще : http://mum.mikrotik.com/presentations/RU18M/presentation_6157_1554717194.pdf

  25. Опубликовано · Изменено пользователем nkusnetsov · Жалоба на ответ

    Для active/active лучше подниматься на L3 и балансировать нагрузку там. Если два параллельных моста, то самый простой ECMP уже даст плюс. Зная особенности работы и пропускной способности обоих мостов, можно попротокольно балансировать и вообще как угодно.