Chupaka писал(а): ↑13 ноя 2019, 15:58
А вы не хотите просто per-connection-classifier=both-addresses-and-ports сменить на per-connection-classifier=src-address? Если не хотите - то сделайте два набора правил:
1) порты 80/tcp,443/tcp - per-connection-classifier=src-address
2) всё остальное - per-connection-classifier=both-addresses-and-ports
Проблема возникает потому, что несколько соединений даже к одному IP могут пойти через разные каналы.
Сделал по вашей рекомендации.
Гляньте своим профессиональным глазом, так правильно будет? И где правильно поставить passthrough=yes или no
В три правила comment="Per Connection Classifier" и дальше добавьте connection-mark=none, чтобы они не перемаркировывали то, что вы в "Per Connection Classifier HTTPS HTTP" уже намаркировали.
joker писал(а): ↑14 ноя 2019, 11:42И где правильно поставить passthrough=yes или no
Ну, если дальнейшая обработка пакета в данной цепочке не требуется после срабатывания заданного правила - тогда =no, если дальше что-то ещё должно с пакетом произойти (навесить, например, routing mark вдобавок к только что накинутой connection mark) - тогда =yes
Chupaka писал(а): ↑14 ноя 2019, 14:51
В три правила comment="Per Connection Classifier" и дальше добавьте connection-mark=none, чтобы они не перемаркировывали то, что вы в "Per Connection Classifier HTTPS HTTP" уже намаркировали.
Если я сделаю в 3-х правилах под комментарием "Per Connection Classifier" action=mark-connection new-connection-mark=no-mark , то следующие 3 правила action=mark-routing не будут иметь смысла. Маркированных коннекшинов не будет и в роутинг не чего будет загонять.
А вы так не делайте Вы сделайте так, как я написал: connection-mark=no-mark, а не new-connection-mark=no-mark. Т.е. не снимать метку, а НЕ обрабатывать коннекшены, на которых уже есть метка. Ну и routing-mark оставить просто ISP2-WAN2, не надо создавать никаких 80_443-ISP2-WAN2
Chupaka, подскажите, правильно ли я понимаю, что если в данном примере у одного из провайдеров случатся проблемы (шлюз доступен, но трафик дальше него не идёт), то Тик всё равно будет продолжать слать трафик на этого провайдера? Как тогда можно решить проблему с отказоустойчивостью в PCC?
Эх, идея правильная, реализация, к сожалению, в случае с ByFly не сработает из-за "особенностей" RouterOS Там надо сделать так: создать PPP Profile (скопировать текущий), указать ему в Remote Address 77.88.8.3, навесить на подключение pppoe-out1_ByFly и убрать маршрут "add dst-address=77.88.8.3 gateway=pppoe-out1_ByFly scope=10"
Ясно, спасибо. Из Вашего опыта - одного узла на линк в рекурсивном маршруте достаточно для определения "мёртвого" провайдера? И вообще, что лучше - использовать рекурсивные маршруты с несколькими узлами на линк или использовать дополнительные скрипты?
Для определения "мёртвого" - определённо достаточно. Больше одного надо для определения "живого", когда пингуемый узел недоступен по своей собственной причине, и провайдер не виноват Вы поработайте в таком режиме, если что-то не понравится - тогда и будете доделывать, согласно новым требованиям.