IPoE всмыле

Туннель понимать маршрутизатором.. Чего у него нет?

Запуск скрипта 1 раз в минуту, это изнасилование МТ. По статистике потеря основного канала 3-8 раз в неделю.

Смотря какого скрипта. Не нахожу это "насилием". ЦПУ от чека роута не загнётся

Вы в любом случае будете делать костыли. Способов явно определить работает логическая часть статус мало. И впн все сделает не запуская сто тысяч раз эту задачку.

К сожалению костылей не избежать, но не в ущерб работе. загрузке ЦП и т.д.

Туннель понимать маршрутизатором.. Чего у него нет?

он выше писал технологию подключения к провайдиру IPoE

Смотря какого скрипта. Не нахожу это "насилием". ЦПУ от чека роута не загнётся

условие я ему уже подсказал

Смотря какого скрипта. Не нахожу это "насилием". ЦПУ от чека роута не загнётся

в неделю 10080 запусков скрипта, сработает всего 4-8 раз... не просто насилие. изнасилование.

кстати вот и решение. впн по каналу основного провайдера до любого внешнего сервера и нужные действия на on-up и on-down

Поддержу, неплохое решение. Просто впн, траф в нём гонять даже не надо

он выше писал технологию подключения к провайдиру IPoE

А у меня к провайдеры ППТП, но это не мешает мне иметь еще 5 активных туннелей, пара из которых нужны для фиксации состояния оборудования. И оттого, что вы поднимете туннель и НЕ будете загонять туда трафик использование Вашего процессора будет 0

Разработчики точно не будут рассматривать предложение ? ведь согласитесь, предложени очень перспективное !!!

Поддержу, неплохое решение. Просто впн, траф в нём гонять даже не надо

не совсем, netwatch лучше, позже про него вспомнил)

тут и сервер не нужен

можно гугл пинговать

может стоит в МТ предложение накатать ? Как думаете ?

Пишите. Если им не отправлять предложений, система будет сильно более скучная

А если в перерыве между пингами Вы переведетесь на резервный канал, как нетвотч это поймет?

Пишите. Если им не отправлять предложений, система будет сильно более скучная

Буду писать. Вспомнился фильм "Побег из Шоушенка", писал каждую неделю.... :)

да, с возможностью указания задержки исполнения в секундах

Задержка исполнения — это :delay N

А если в перерыве между пингами Вы переведетесь на резервный канал, как нетвотч это поймет?

шлюз нужно пинговать поэтому) так как у него щас юзается проверка пингом в маршруте там пинг идет до шлюза и переход работает нормально

давайте netwatch заюзайте будет попроще

Нетвотч — почти шедулер. Те же периодические проверки. И их нужно ставить реже 20 секунд, иначе он отработает раньше роутинга и флашнет коннекшны раньше переключения маршрутов

шлюз нужно пинговать поэтому) так как у него щас юзается проверка пингом в маршруте там пинг идет до шлюза и переход работает нормально

Если у провайдера проблемы с доступом наверх, то шлюз будет отлично пинговаться, а интернет работает не будет

Если у провайдера проблемы с доступом наверх, то шлюз будет отлично пинговаться, а интернет работает не будет

+ рекурсивные маршруты

Если у провайдера проблемы с доступом наверх, то шлюз будет отлично пинговаться, а интернет работает не будет

это козе понятно, ну если и ваш тонел не ляжет а у прова проблемы тоже самое будет))

Я не хочу для решения данной задачи поднимать тунели Ой, кажись не мне

А чем не нравится решение-то? Немного костыльно, но 1) проц не жрёт 2) запускает скрипты по евенту. 3) ?????? 4) PROFIT

это козе понятно, ну если и ваш тонел не ляжет а у прова проблемы тоже самое будет))

Если интернет не работает и впн-сервер в интернете, то он отлично ляжет

Или Вы считаете, что впн только до провайдера бывает?

в неделю 10080 запусков скрипта, сработает всего 4-8 раз... не просто насилие. изнасилование.

Если скрипт насилует файлосистему — то да, а если чекает что-л в оперативке — ИМХО, нет. Насколько процентов загружен ЦПУ Вашего МТ, что Вы так трясётесь за ресурсы?

А чем не нравится решение-то? Немного костыльно, но 1) проц не жрёт 2) запускает скрипты по евенту. 3) ?????? 4) PROFIT

Алергия на костыли...

Если интернет не работает и впн-сервер в интернете, то он отлично ляжет

я имел в веду технологию подключения до прова по VPN

А я имел в виду в принципе технологию впн

Или Вы считаете, что впн только до провайдера бывает?

по поводу вашего решения это возможно, но не идеально, ваш vpn сервер тоже может леч, который в интернете

Если скрипт насилует файлосистему — то да, а если чекает что-л в оперативке — ИМХО, нет. Насколько процентов загружен ЦПУ Вашего МТ, что Вы так трясётесь за ресурсы?

Когда наступит момент использовать ресурсы. а их нет. что тогда

Да. Купите тот, который не ляжет

Когда наступит момент использовать ресурсы. а их нет. что тогда

Поменяете тик на более мощный

Алергия на костыли...

Хорошая черта. Но ИМХО, если есть куда поднять клиент-серверный туннель — то использование этого костыля наиболее оптимально.

на 30 магазинах ?

Давайте так: 1) Сколько трафика от каждого магазина? 2) Что за железка в магазинах? 3) Что за железка в центральном филиале (если топология звезда)?

на 30 магазинах ?

Уважаемый. Я сейчас еще раз перечитал этот тред. Вы ГДЕ-НИБУДЬ указали задачу в целом? Как у Вас эти магазины стыкуются? Какие аппаратные средства? Какие тики хотя бы стоят? А теперь Вы обвиняете меня, что я хреново прочитал Ваши мысли?

Хорошая черта. Но ИМХО, если есть куда поднять клиент-серверный туннель — то использование этого костыля наиболее оптимально.

Думаю построить решение на snmp, не обойтись без сторонней помощи в своем сегменте сети но работать должно.

Думаю построить решение на snmp, не обойтись без сторонней помощи в своем сегменте сети но работать должно.

И логиниться с заббикса и флашить коннекшны по ссх? Нуууу, такое....

Уважаемый. Я сейчас еще раз перечитал этот тред. Вы ГДЕ-НИБУДЬ указали задачу в целом? Как у Вас эти магазины стыкуются? Какие аппаратные средства? Какие тики хотя бы стоят? А теперь Вы обвиняете меня, что я хреново прочитал Ваши мысли?

1. Мне кажется вы слишком впечатлительны. 2. Я никого ни в чем не обвинял. 3. Все поисывал ранее.

1. Мне кажется вы слишком впечатлительны. 2. Я никого ни в чем не обвинял. 3. Все поисывал ранее.

Как у вас соединены магазины? Звездой с центральным офисом?

И логиниться с заббикса и флашить коннекшны по ссх? Нуууу, такое....

нет, есть мелкий сервер слушающий трапы, а далее по технологии

Как у вас соединены магазины? Звездой с центральным офисом?

полносвязная

И логиниться с заббикса и флашить коннекшны по ссх? Нуууу, такое....

Ребята принимают хотелки на английском ?

дополнительно создайте топик на форуме, мы плюсанем )

дополнительно создайте топик на форуме, мы плюсанем )

Да, спасибо... нашел.

полносвязная

Прекрасно. У Вас полноценный влан на всю сеть магазинов, которых 30 штук. Ваша задача обеспечить подключение АТС к центральному офису? Где какая железка стоит?

Прекрасно. У Вас полноценный влан на всю сеть магазинов, которых 30 штук. Ваша задача обеспечить подключение АТС к центральному офису? Где какая железка стоит?

Магазины RouterBOARD 750Gr3, офис Kerio Control

Не комельфо конечно... но пока так

Магазины RouterBOARD 750Gr3, офис Kerio Control

Даже не парьтесь за ресурсы хекса. Дайте ему хоть чем-нибудь позаниматься 😊

Даже не парьтесь за ресурсы хекса. Дайте ему хоть чем-нибудь позаниматься 😊

и так 60% ^

Это сколько же Вы трафика гоняете‽

Магазины RouterBOARD 750Gr3, офис Kerio Control

Даже если Вы шифровать будете туннель без трафика хекс справится. Даже с трафиком справится. И керио потянет.

video cams, rdp, smb и т.д.

Даже если Вы шифровать будете туннель без трафика хекс справится. Даже с трафиком справится. И керио потянет.

в центральном офисе нет МТ, Kerio, связать их можно но не хотелось бы... бэст-эффорд это ccr, иду к этому но не летом

Это сколько же Вы трафика гоняете‽

В сентябре прошлого года в сургуте mtcne, мы с вами общались по этому поводу ;)

Господа. Столкнулся с тем, что hap ac не может пропихнуть по wifi 802.11 ac больше 300 Мбит/с. Прошивка 6.41.4 (скоро обновлю до 6.42 :) ) В качестве клиента ноут с MIMO 3x3, spatial streams больше 1 точно. Конфиг стандартный. Wifi ap bridge. WPA2 + aes ccm. На 80МГц ноут почему-то отказывается коннектиться, поэтому тестировал на 40МГГц. Тест выполнялся iperf-ом. Сервер подключен к LAN-порту кабелем, порт в том же бридже, что и вафля. Результат на скриншоте ниже. Проц практически кладется (в пиках 90%, на скрине 73%) и iperf регистрирует некоторую потерю пакетов (небольшую, но есть.) Вот и вопрос: почему? Виноват aes и слабый проц в hap ac?

Коллеги подскажите. Как правильно поступать с forward untracked в схемах с несколькими каналами? Возможна асинхронная маршрутизация( При одном канале я такое нещадно дропал. А тут пришлось разрешить, но как то коробит

Не путаете ли Вы untracked с invalid?

А должен? Invalid это битый или "непонятный" пакет untracked это пакет отсутствующий в таблице конекшенов. Когда пакет ушёл в один канал , а вернулся "по воле судьбы сам того не желая" из другого - то получается что его нет в таблице . Таких пакетов не много (пока марщрутизацию в каналах никто не трясёт) Каналы - vpn тунели. Маршрутизация статика

Раз антреккеда нет в коннтреке – значит он 100% избегает ната со всеми вытекающими из него проблемами. И статут антрекед берётся только в случае, если вы к каким-то пакетам в raw-фаерволе применили action=no-track

А раз вы сами попросили пакеты избегать коннтрека, какой смысл их дропать?

Эмммм....логично Сам себя передумал

Спасибо

не находили откуда winbox для последних RC брать? на сайте 3.13 только нашел *) winbox - improved authentication process excluding man-in-the-middle possibility (Winbox v3.14 required);

@skr1p7 https://www.mikrotik.com/download/share/winbox.exe

@skr1p7 https://www.mikrotik.com/download/share/winbox.exe

спасибо

Нетвотч — почти шедулер. Те же периодические проверки. И их нужно ставить реже 20 секунд, иначе он отработает раньше роутинга и флашнет коннекшны раньше переключения маршрутов

эээ... так то у него задача в том, что бы выполнить определенный набор команд (в вашем случае переключить маршрут на резервный) если указанный хост перестал отвечать. как он может отработать позже роутинга?

А должен? Invalid это битый или "непонятный" пакет untracked это пакет отсутствующий в таблице конекшенов. Когда пакет ушёл в один канал , а вернулся "по воле судьбы сам того не желая" из другого - то получается что его нет в таблице . Таких пакетов не много (пока марщрутизацию в каналах никто не трясёт) Каналы - vpn тунели. Маршрутизация статика

Если у Вас маршрутизация статическая, значит Вы знаете все подсети находящиеся за вашим маршрутизатором. В этом случае, недурно бы пропускать через форвард только пакеты пришедшие извне и адресованые вашей внутренней сети. Например, чтобы не стать транзитом между двумя провайдерами. Опять же все зависит от политики прохождения трафика. Как пользователи "видят" мир. Если через nat, то там untracked быть не может.

В любом случае оценивая критерии "src-ip"+"in-interface"+"dst-ip" можно более-менее обезопаситься.

Если у Вас маршрутизация статическая, значит Вы знаете все подсети находящиеся за вашим маршрутизатором. В этом случае, недурно бы пропускать через форвард только пакеты пришедшие извне и адресованые вашей внутренней сети. Например, чтобы не стать транзитом между двумя провайдерами. Опять же все зависит от политики прохождения трафика. Как пользователи "видят" мир. Если через nat, то там untracked быть не может.

Не знаю подсети)) Vpn смотрят в инет! и в случае проблемы с каналом или сервером перебрасывают пакеты на другой сервер и они выходят с другого туннеля PS с помощью Александра ужо всё решил

Интересно, как при статической маршрутизации Вы не зная подсетей её настроили?

эээ... так то у него задача в том, что бы выполнить определенный набор команд (в вашем случае переключить маршрут на резервный) если указанный хост перестал отвечать. как он может отработать позже роутинга?

время принятия решения о недоступности шлюза от 11 до 20 секунд. настройте частоту опроса в нетвотче 30 секунд - вот вам нетвотч не успевает за роутингом. настройте частоту 2 секунду - вот роутинг не успевает за нетвотчем

время принятия решения о недоступности шлюза от 11 до 20 секунд. настройте частоту опроса в нетвотче 30 секунд - вот вам нетвотч не успевает за роутингом. настройте частоту 2 секунду - вот роутинг не успевает за нетвотчем

1. ставишь статический роут до проверяемого хоста (например 8.8.4.4) через основной канал 2. добавляешь этот хост в нетвотч. 3. выставляешь требуемый интервал и таймаут в зависимости от говенности основного канала. 4. когда 8.8.4.4 перестает отвечать через основной канал, по событию on-down ставишь дистеншн резервного канала меньше основного. 5. когда 8.8.4.4 начинает снова отвечать, в событии on-up возвращаешь как было. кто тут за кем должен успеть? я не пойму

ну в идеале в пункте 1 Вы выставляете Check Gateway = ping. И тогда в момент падения канала у Вас основной шлюз становится unreacheble. И все маршруты с этим шлюзом становятся неактивными. А активным становится маршрут со следующим по величине дистансом. И все это работает в рамках таблицы маршрутизации и без костылей в виде нетвотча. Единственно, что для принятия шлюза недоступным надо 3 потярянных пинга с частотой 10 секунд.

ну в идеале в пункте 1 Вы выставляете Check Gateway = ping. И тогда в момент падения канала у Вас основной шлюз становится unreacheble. И все маршруты с этим шлюзом становятся неактивными. А активным становится маршрут со следующим по величине дистансом. И все это работает в рамках таблицы маршрутизации и без костылей в виде нетвотча. Единственно, что для принятия шлюза недоступным надо 3 потярянных пинга с частотой 10 секунд.

доступность провайдерского гейта - это гарантия, что за ним все в порядке?

вникните в тему рекурсивной маршрутизации. Там как раз есть идея о проверке хостов ЗА провайдером

вникните в тему рекурсивной маршрутизации. Там как раз есть идея о проверке хостов ЗА провайдером

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

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

20 секунд максимум. И это не костыль. И работает гибче