Это хекс. Он тестит ццр. Ему плохо ))

Гг

Кто кого тестит - эт еще вопрос

ктов итоге победил то? хекс или ццр?

Дружба

я так понял CCR тупо генерил трафик на интерфейсах. Оно и лилось в интерфейсы хекса, дальше никуда не шло наверное. Такая себе чистая синтетика. Да и опять же. Я не говорил что там у ХЕКСа только 5 гигабит. я говорил что ВЫШЕ 5 ГИГАБИТ ИТАК НАФИГ НЕ НУЖНО ? Конечно можно придумать ситуации когда будет входить в езернет и через него же выходить, но это такая редкость что ее я упустил

Не совсем так. Ццр генерит траф таким образом, чтобы при отправке на хекс он вернулся. Остюда замеры лострейта и джиттера. Так что это не бессвязный поток пакетов вникуда

а, ясно. А как это достигнуто? Просто интересно

Traffic generator. Пордобно описан в вики

А если, допустим, в таблице mangle сделать действие jump в новую цепочку superchain, то, будет ли пакеты в таблице filter попадать в цепочку superchain, если там она тоже будет создана. Другими словами: связаны ли между собой искусственно созданные (при помощи действия jump) цепочки в таблицах filter и mangle?

Не связаны, что очевидно.

А почему очевидно?

это разные таблицы, нет?

Я понял, спасибо

подскажите в чем может быть дело. с компа за микротиком делаю ping 8.8.8.8 -l 1480. переключаю на другой канал, с того же компа максимум 1552. пакеты с большим размером теряет. больше 1472 пакеты уходят в фрагментацию на обоих линках, т.е. получается mtu 1500.

ютуб сбоит, с левого компа делал пакеты 30000 до 8.8.8.8 без потерь

Подскажите как можно из 1-ого isp в 2-ой isp сделать port forward?

подскажите в чем может быть дело. с компа за микротиком делаю ping 8.8.8.8 -l 1480. переключаю на другой канал, с того же компа максимум 1552. пакеты с большим размером теряет. больше 1472 пакеты уходят в фрагментацию на обоих линках, т.е. получается mtu 1500.

странный тетст например у меня 8.8.8.8 размером пакета больше 64 не пингуется

Подскажите как можно из 1-ого isp в 2-ой isp сделать port forward?

это из первого прова во второй? обычно форвардят во внутреннюю сеть. не пойму для чего может быть нужно

а ya.ru и проходит 3000

ютуб сбоит, с левого компа делал пакеты 30000 до 8.8.8.8 без потерь

а ось какая на компе?

шиндовс

может не в сетевом обмене дело?

8

я бы полез в wireshark и посмотрел нет ли ретрансмитов

если они есть - то там обычно ясно, почему они есть

а если ретрансмитов нет, то дело не в межсетевом взаимодействии

это оч грубый анализ, но хотябы укажет куда смотреть

ютуб сбоит, с левого компа делал пакеты 30000 до 8.8.8.8 без потерь

с других компов через оба канала нормально ютуб показывает и проблема только на одном?

проблема, можно сказать, на всех компах выражена

Serj Ага, из первого провайдера во второй провайдер, надо перенапралять отределый трафик если на определеном порту

с других компов через оба канала нормально ютуб показывает и проблема только на одном?

если поднимаешь vpn (frigate) расширение например, или турбо, то все хорошо

проблема, можно сказать, на всех компах выражена

через обоих провайдеров?

да.

если режу мсс в мангле, то все ок. но не навсегда))

Нечего запрещать ICMP type 3.

дык и не запрещал)

Докажи.

скрин доказал

Скриншот можешь себе в анус засунуть. Там не все поля видны. Print, export.

imcp протокол не затрагивается.

Конечно, ведь такого протокола не существует.

если режу мсс в мангле, то все ок. но не навсегда))

проверь маршруты через обоих провайдеров, совпадений по хопам нет?

проверь маршруты через обоих провайдеров, совпадений по хопам нет?

провы разные. подсети не пересекаются, сейчас хопы проверю

Serj, /ip firewall export в студию.

[BAZA-1@Dir-615] > tool traceroute thg.ru routing-table=MARK_ether1 # ADDRESS LOSS SENT LAST AVG BEST WORST 1 10.0.33.1 0% 5 0.8ms 0.9 0.7 1 2 91.213.59.246 0% 5 0.7ms 0.8 0.7 1.1 3 91.213.59.250 0% 5 0.7ms 0.7 0.7 0.8 4 10.254.0.2 0% 5 0.6ms 0.8 0.6 1 5 91.213.59.30 0% 5 1ms 0.9 0.8 1 6 5.53.117.65 0% 5 9.3ms 9.3 9.2 9.4 7 193.239.72.13 0% 5 10.9ms 10.8 10.6 10.9 8 195.208.208.91 0% 5 21.8ms 22.2 21.8 22.5 9 10.169.246.37 0% 4 23.4ms 24 23.4 24.5 10 158.250.234.121 0% 4 22.4ms 22.5 22.1 23.1 11 194.67.128.198 0% 4 23.8ms 23 22.7 23.8 [BAZA-1@Dir-615] > tool traceroute thg.ru routing-table=MARK_ether2 # ADDRESS LOSS SENT LAST AVG BEST WORST 1 10.220.0.2 0% 8 0.6ms 0.7 0.6 1.1 2 176.122.98.249 0% 8 1.9ms 13.4 1.2 97.3 3 176.122.108.141 0% 8 0.9ms 5.9 0.8 41.1 4 176.122.112.17 0% 8 5ms 6.3 4.9 15.7 5 31.28.26.100 0% 8 5.3ms 5.1 5 5.3 6 10.10.13.186 0% 8 17.3ms 20.9 15.5 51 7 89.188.100.190 0% 8 14.8ms 23.7 14.8 84.1 8 194.190.254.238 0% 8 21ms 21.7 21 23.6 9 158.250.234.121 0% 8 21.6ms 21.5 21.2 21.7 10 194.67.128.198 0% 8 22ms 22.2 21.9 22.7

так у тебя со всеми ресурсами проблемы?

почему к thg.ru проверяешь?

проблемы с https в основном

пинги тестил до thg в том числе. все одинакого

а проблемы не пару недель назад начались?

проблемы с https в основном

и проверь маршрут до того сайта где у тебя гарантированно проблемы а то thg.ru - не попадает под выборку, https там нет

[BAZA-1@Dir-615] > tool traceroute youtube.com routing-table=MARK_ether2 # ADDRESS LOSS SENT LAST AVG BEST WORST 1 10.220.0.2 0% 6 0.6ms 0.8 0.6 1.3 2 176.122.98.249 0% 6 1.3ms 1.3 1.1 1.6 3 176.122.103.141 0% 6 10ms 11.1 9.5 18.2 4 176.122.123.153 0% 6 16.9ms 11.7 9.9 16.9 5 176.122.102.204 0% 6 9.4ms 10.7 9.4 16.3 6 108.170.248.146 0% 6 9.7ms 9.8 9.7 9.9 7 209.85.241.196 0% 5 24.8ms 33.5 24.8 44.6 8 66.249.94.181 0% 5 24.6ms 24.9 24.5 26 9 216.58.214.206 0% 5 25ms 24.8 24.5 25.1 [BAZA-1@Dir-615] > tool traceroute youtube.com routing-table=MARK_ether1 # ADDRESS LOSS SENT LAST AVG BEST WORST 1 10.0.33.1 0% 8 1.1ms 0.9 0.7 1.5 2 91.213.59.246 0% 8 0.7ms 0.9 0.7 1.5 3 91.213.59.250 0% 8 0.7ms 0.8 0.7 0.9 4 10.254.0.2 0% 8 0.7ms 0.7 0.6 0.8 5 91.213.59.30 0% 8 0.8ms 1 0.8 1.9 6 5.53.117.65 0% 8 9.2ms 9.2 9.1 9.3 7 91.204.213.6 0% 8 9.3ms 10.1 9.2 11 8 108.170.248.146 0% 8 9.9ms 10.2 9.5 13.2 9 209.85.241.196 0% 8 45.6ms 44.3 43.5 45.7 10 66.249.94.181 0% 7 43.4ms 43.5 43.4 43.6 11 216.58.214.206 0% 7 43.7ms 43.5 43.2 43.7

из моей теории паранойи. на точках обмена ставят оборудование по перехвату траффика ) через пару недель успокоится, все баги пофиксят )) косвенно это подтверждается тем, что идя через прокси или впн у тебя все ок

из моей теории паранойи. на точках обмена ставят оборудование по перехвату траффика ) через пару недель успокоится, все баги пофиксят )) косвенно это подтверждается тем, что идя через прокси или впн у тебя все ок

Тогда бы change-mss не помогало. Я уже ему сказал - PMTUD сломано.

Но он же уперся, баран.

108.170.248.146 - точка входа в гугл, скорее всего google global cache

Тогда бы change-mss не помогало. Я уже ему сказал - PMTUD сломано.

как вариант, да

но может быть и совпадение. поставил mss, а в это время и так все ок работает.

про параноидальую теорию - это я выдумал от безисходности, когда в сходной ситуации ломался tcp из москвы до германии.

а потом внезапно снова заработал без каких либо действий с моей стороны

проблемы с https в основном

вообщем ничего мне больше рекомендовать кроме как wireshark и изучать трафик. скорее всего увидишь ретрансмиты и там можно будет что либо предположить по результатам "ловли"

ERROR: S client not available

Тогда бы change-mss не помогало. Я уже ему сказал - PMTUD сломано.

я понял что ты имеешь в виду, я не блокирую icmp. на разных аплинках зарезано по разному.

Serj, /ip firewall export в студию.

Serj, /ip firewall export в студию.

ну ок. держи портянку

Pastebin

Serj, /ip firewall export в студию.

/ip firewall filter add action=drop chain=input dst-port=53 in-interface-list=wan protocol=tcp add action=drop chain=input dst-port=53 in-interface-list=wan protocol=udp add action=add-src-to-address-list address-list=torrent_limit address-list-timeout=30m chain=forward connection-limit=80,32 dst-port=!80,443,8080 protocol=tcp src-address=!172.16.0.0/24 tcp-flags=syn add action=drop chain=forward comment=Flood_Killer src-address-list=BLOCKED_FLOOD add action=add-src-to-address-list address-list=BLOCKED_FLOOD address-list-timeout=3m chain=forward comment=Block_Flood connection-limit=35,32 dst-port=80 protocol=tcp src-address-list=OFF_Users add action=accept chain=forward comment=Server src-address=172.16.0.5 add action=accept chain=forward comment=Server2 dst-address=172.16.0.5 add action=accept chain=forward comment=WhiteList dst-address-list=WhiteHosts add action=drop chain=forward connection-limit=40,32 dst-port=!80,443,8080 protocol=tcp src-address-list=torrent_limit tcp-flags=syn add action=drop chain=forward connection-limit=40,32 protocol=udp src-address-list=torrent_limit add action=accept chain=forward comment=Users src-address-list=Users add action=accept chain=forward comment=Users2 dst-address-list=Users add action=drop chain=forward comment=Blocked_Users src-address-list=All_Drop add action=drop chain=forward comment=Blocked_Users2 dst-address-list=All_Drop /ip firewall mangle add action=change-mss chain=forward comment="Clamp MSS to 1472" in-interface=ether1 new-mss=1300 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1301-65535 add action=change-mss chain=forward comment="Clamp MSS to 1472" new-mss=1300 out-interface=ether1 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1301-65535 add action=change-mss chain=forward comment="Clamp MSS to 1472" in-interface=ether2 new-mss=1300 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1301-65535 add action=change-mss chain=forward comment="Clamp MSS to 1472" new-mss=1300 out-interface=ether2 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1301-65535 add action=change-mss chain=forward comment="Clamp MSS to 1472" in-interface=gorodok new-mss=1300 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1301-65535 add action=change-mss chain=forward comment="Clamp MSS to 1472" new-mss=1300 out-interface=gorodok passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1301-65535 add action=mark-routing chain=prerouting comment=LanBallance_ether1 dst-address=!172.16.0.5 new-routing-mark=LanBallance_MARK_ether1 passthrough=yes src-address-list=LanBallance_ether1 add action=mark-routing chain=prerouting comment=LanBallance_ether2 dst-address=!172.16.0.5 new-routing-mark=LanBallance_MARK_ether2 passthrough=yes src-address-list=LanBallance_ether2 add action=mark-connection chain=input in-interface=ether1 new-connection-mark=INPUT_wan1 add action=mark-routing chain=output connection-mark=INPUT_wan1 new-routing-mark=LanBallance_MARK_ether1 passthrough=yes add action=mark-routing chain=prerouting connection-mark=INPUT_wan1 in-interface-list=!wan new-routing-mark=LanBallance_MARK_ether1 passthrough=yes add action=mark-connection chain=input in-interface=ether2 new-connection-mark=INPUT_wan2 passthrough=yes add action=mark-routing chain=output connection-mark=INPUT_wan2 new-routing-mark=LanBallance_MARK_ether2 passthrough=yes add action=mark-routing chain=prerouting connection-mark=INPUT_wan2 in-interface-list=!wan new-routing-mark=LanBallance_MARK_ether2 passthrough=yes add action=mark-connection chain=input in-interface=gorodok new-connection-mark=INPUT_wan3 passthrough=yes add action=mark-routing chain=output connection-mark=INPUT_wan3 new-routing-mark=LanBallance_MARK_gorodok passthrough=yes add action=mark-routing chain=prerouting connection-mark=INPUT_wan3 in-interface-list=!wan new-routing-mark=LanBallance_MARK_gorodok passthrough=yes /ip firewall nat add action=dst-nat chain=dstnat dst-port=80 in-interface=gorodok protocol=tcp to-addresses=172.16.0.5 to-ports=80

Serj, /ip firewall export в студию.

add action=dst-nat chain=dstnat dst-port=10070 in-interface=gorodok protocol=tcp to-addresses=172.16.107.44 to-ports=10070 add action=dst-nat chain=dstnat dst-port=10075 in-interface=gorodok protocol=tcp to-addresses=172.16.107.44 to-ports=10075 add action=dst-nat chain=dstnat dst-port=10076 in-interface=gorodok protocol=udp to-addresses=172.16.107.44 to-ports=10076 add action=dst-nat chain=dstnat dst-port=42 in-interface=gorodok protocol=tcp to-addresses=172.16.101.48 to-ports=42 add action=dst-nat chain=dstnat dst-port=2525 in-interface=gorodok protocol=tcp to-addresses=172.16.101.48 to-ports=2525 add action=netmap chain=dstnat comment="WEB-CAP" dst-address=!172.16.0.5 dst-address-list=!WhiteHosts dst-port=80 protocol=tcp src-address-list=OFF_Users to-addresses=172.16.0.5 to-ports=81 add action=netmap chain=dstnat comment="2WEB-CAP" dst-address=!172.16.0.5 dst-address-list=!WhiteHosts dst-port=80 protocol=tcp src-address-list=!Users to-addresses=172.16.0.5 to-ports=82 add action=masquerade chain=srcnat comment="USERS NAT" out-interface=ether1 src-address-list=All_Drop add action=masquerade chain=srcnat comment="USERS NAT" out-interface=ether2 src-address-list=All_Drop

Увидел что то подозрительное?

А ты как трафик балансишь между isp ?

Адресными листами

Адресными листами

Конфиг сейчас глазами не осилить, но часть правил вызывает подозрение включенным passthrough где его по логике не должно быть.

/stat@combot

combot.org/chat/-1001062683398

Сейчас больше похоже на то, что проблема не у провайдеров, а у тебя в конфиге. Попробуй упростить конфигурацию до одного провайдера, и проверить, нет ли проблем.

Если проблемы исчезли - то изучай конфиг )

Когда один пров постабильнее работает

Но я не менял ничего когда проблема началась

Спасибо, попробую

Тип в accounting затирается входящий интерфейс?

Нет

Пакет уже прибыл

И он мог придти как от output так и от forward

А в output могут быть пакеты где in интерфейс отсутствует как таковой

Пакет порожден local process

По этому по in в построутинге фильтровать никак.

А если пакет пришел из forward, то фильтровать в построутинге по in можно?

Как и в preroutinge нельзя использовать out - не известно как пакет выйдет, решение о маршрутизации ещё не принято

А если пакет пришел из forward, то фильтровать в построутинге по in можно?

В форварде и фильтруй

С прероутингом я понял

Ну, вообщем логично, спасибо.