Russian Users MikroTik | Форум пользователей MikroTik

sarge писал(а):4) Именно натуральная статика и есть, никакой динамики и ppoe. Просьба прояснить про рекурсивную маршрутизацию, с чем ее едят?

Рекурсивная маршрутизация - это встроенный в роутер функционал, помогающий понять, жив ли канал на логическом (IP) уровне
(то есть жив ли канал за провайдером!!!)

То есть Вы берёте какой-то внешний адрес (крупной фирмы, системы) и этот IP-адрес будет как эталон.
Делаете так, чтобы этот эталон был доступен только одного провайдера, и уже формируете рекурсивный маршрут,
который и будет действителен (рабочий) пока эталонный адрес доступен (пингуется).
Как эталонный адрес становиться не доступный, маршрут считается не рабочим и соответственно,
роутер его не использует (переходит на второй канал) (при использовании дистанс).
Как эталонный адрес будет снова через первого провайдера доступен и если приоритеты Вы не меняли,
то роутер снова перейдёт на первого провайдера.

Объяснил слегка не технически, но как бы дать саму сущность понимания.
В интернете найдёте как это делать....это не сложно при статическом интернет-подключении.

Нетвотч это слишком примитивно. Рекурсивная лучше, но, для меня, все равно недостаточный функционал. К тому же, при dhcp или pppoe все равно скрипт нужен.
По этому я за скрипт. Скриптом намного гибче получается решение. Можно, например, изменить периодичность проверки, проверять несколько адресов, мониторить качество канала, отправлять уведомления или выполнять другие действия при разных событиях.

algerka писал(а):.....К тому же, при dhcp или pppoe все равно скрипт нужен.

Ну я заранее спросил у ТС какой тип подключения, и он сказал что у него старая добрая статика,
при старой доброй примитивной статике и при поставленных задачах (желаниях) - рекурсивная маршрутизация проще будет,
поэтому только тогда я её и посоветовал!

Я бы не советовал рекурсивную маршр. при рррое/dhcp и так далее....поэтому, в целом то понятно, что скрипт лучше,
гибче, и так далее, но на каждую задачу всё же должно быть своё решение и решение не сверх сложное(не за облачное).

algerka писал(а):Нетвотч это слишком примитивно. Рекурсивная лучше, но, для меня, все равно недостаточный функционал. К тому же, при dhcp или pppoe все равно скрипт нужен.
По этому я за скрипт. Скриптом намного гибче получается решение. Можно, например, изменить периодичность проверки, проверять несколько адресов, мониторить качество канала, отправлять уведомления или выполнять другие действия при разных событиях.

А чем скрипт лучше чем рекурсивные маршруты?
По моему как раз таки если статика то рекурсивные маршруты рулят.

enzain писал(а):А чем скрипт лучше чем рекурсивные маршруты?
По моему как раз таки если статика то рекурсивные маршруты рулят.

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

KARaS'b писал(а):

enzain писал(а):А чем скрипт лучше чем рекурсивные маршруты?
По моему как раз таки если статика то рекурсивные маршруты рулят.

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

Дважды должен не ответить шлюз.
И перерыв 10 секунд.

enzain писал(а):

algerka писал(а):Нетвотч это слишком примитивно. Рекурсивная лучше, но, для меня, все равно недостаточный функционал. К тому же, при dhcp или pppoe все равно скрипт нужен.
По этому я за скрипт. Скриптом намного гибче получается решение. Можно, например, изменить периодичность проверки, проверять несколько адресов, мониторить качество канала, отправлять уведомления или выполнять другие действия при разных событиях.

А чем скрипт лучше чем рекурсивные маршруты?
По моему как раз таки если статика то рекурсивные маршруты рулят.

Я же написал что скриптом "гибче" получается. Возможно я плохо знаком с механизмом рекурсивной маршрутизации, тогда ответьте мне, если знаете, как при использовании рекурсивной маршрутизации сделать:
1. отправку сообщения при переключении на резервный канал ?
2. как сделать чтобы не возвращаться на основной канал, если задержки на нем до нужного узла более 100мс или потери более 1%, при этом проинформировать администратора что канал есть, но качество его плохое ?
3. как сделать чтобы при появлении основного канала, в первые три минуты на него пустить не критичный трафик, а если в течении этого времени канал будет приемлемого качества, только тогда на него возвращать основной трафик?

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

Браво, Александр! Сжато, точно и доходчиво! Конечно, скрипт позволяет развернуться администратору. Главное, чтобы этому администратору хватило знаний для разумной реализации скриптового переключения.
Рекурсивка хороша лишь простотой реализации и использованием для проверки внешнего шлюза. И выполняется пользователем с начальным уровнем знаний почти полным копипастом.
И тот и другой способ имеют право на жизнь. Скриптовый более пригоден для организаций покрупнее, рекурсивная маршрутизация для мелких контор и для дома.

algerka писал(а):Я же написал что скриптом "гибче" получается. Возможно я плохо знаком с механизмом рекурсивной маршрутизации, тогда ответьте мне, если знаете, как при использовании рекурсивной маршрутизации сделать:
1. отправку сообщения при переключении на резервный канал ?
2. как сделать чтобы не возвращаться на основной канал, если задержки на нем до нужного узла более 100мс или потери более 1%, при этом проинформировать администратора что канал есть, но качество его плохое ?
3. как сделать чтобы при появлении основного канала, в первые три минуты на него пустить не критичный трафик, а если в течении этого времени канал будет приемлемого качества, только тогда на него возвращать основной трафик?
Да и, при большом кол-ве маршрутизаторов с различными провайдерами и типами подключений, проще сделать один универсальный скрипт, чем в каждом городе придумывать свое решение.

1) Круто, и ещё раз круто....хотел бы посмотреть/пощупать такой скрипт
2) если заниматься аутсорсингом(или работать в такой компании) и админить
только микротики в конторах и иметь 100-200 контор, везде по 2-4 провайдера,
то да, скрипт и аналитика нужна.
3) как говориться - к каждой задачи своё решение, то есть не надо решать простую ситуацию через сложное,
не всегда стоит оно того (затраты времени/настройка)
4) если роутер стоит дома/в мини-офисе и даже если провайдеров хоть куча подключено,
но если у провайдеров спутник один на всех в городе/районе - там "умный скрипт тут будет слегка излишен,
каналы на спутниках скачут и очень по пингам нестабильны, также бывает так,
канал по задержкам хороший, а по отзывчивости сайтов - ужаснее, то есть при спутнике анализ сложен,
порой можно работать спокойно при 800-900мс, а при 550-600 материться и ругаться....
поэтому анализ сложен и не имеет закономерности порой в такой(их) ситуациях.

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