Два провайдера: отказоустойчивость и распределение нагрузки

Раздел для тех, кто начинает знакомиться с MikroTik
Правила форума
Как правильно оформить вопрос.
Прежде чем начать настройку роутера, представьте, как это работает. Попробуйте почитать статьи об устройстве интернет-сетей. Убедитесь, что всё, что Вы задумали выполнимо вообще и на данном оборудовании в частности.
Не нужно изначально строить Наполеоновских планов. Попробуйте настроить простейшую конфигурацию, а усложнения добавлять в случае успеха постепенно.
Пожалуйста, не игнорируйте правила русского языка. Отсутствие знаков препинания и неграмотность автора топика для многих гуру достаточный повод проигнорировать топик вообще.

1. Назовите технологию подключения (динамический DHCP, L2TP, PPTP или что-то иное)
2. Изучите темку "Действия до настройки роутера".
viewtopic.php?f=15&t=2083
3. Настройте согласно выбранного Вами мануала
4. Дочитайте мануал до конца и без пропусков, в 70% случаев люди просто не до конца читают статью и пропускают важные моменты.
5. Если не получается, в Winbox открываем терминал и вбиваем там /export hide-sensitive. Результат в топик под кат, интимные подробности типа личных IP изменить на другие, пароль забить звездочками.
6. Нарисуйте Вашу сеть, рисунок (схему) сюда. На словах может быть одно, в действительности другое.
Закрыто
Аватара пользователя
Barvinok
Сообщения: 104
Зарегистрирован: 28 фев 2012, 23:21

Приглядись к первой странице.
Я писал(а):Из статьи "Маршрутизация без скриптов" я взял на заметку проверку работоспособности канала пингуя не провайдерский шлюз, а удалённый хост.


aabbyr
Сообщения: 3
Зарегистрирован: 06 сен 2012, 18:25

aabbyr писал(а):
Как быть в таком случае?


Это был риторический вопрос. Смысл в том, что "check-gateway=ping" не выход из положения.


Аватара пользователя
Barvinok
Сообщения: 104
Зарегистрирован: 28 фев 2012, 23:21

Вот я сейчас не понял.
Ты задавал вопрос не ради ответа, а просто упражняясь в риторике?

Если на то пошло, то прохождение пинга до яндекса так же не служит залогом успешной работы по HTTP с этим самым яндексом. Я полагаю более надёжным признаком возможность/невозможность установки TCP-соединения.
Тут можно развернуть ещё одно исследование (кстати, не хочешь проделать здесь эту работу?).
Я же собирал внимание читающих именно на способах распределении нагрузки по двум каналам: ECMP, PCC, NTH...


aabbyr
Сообщения: 3
Зарегистрирован: 06 сен 2012, 18:25

В риторике не упражнялся. В теме статьи меня больше заинтересовала "отказоустойчивость", поэтому хотел обратить Ваше внимание на строчку "check-gateway=ping". И пропустил ссылку на статью "Advanced Routing Failover without Scripting". Приношу свои извинения.


Аватара пользователя
Barvinok
Сообщения: 104
Зарегистрирован: 28 фев 2012, 23:21

Ты прав. В названии темы действительно заявлена отказоустойчивость. Изначально я полагал, что она сама собой достигается использованием двух каналов, но как оказалось, не всё так просто.
То, что для конечного пользователя определяется, как "у меня не работает интернет", может иметь множество причин:
  • Тупо обрыв линии (тут "check-gateway=ping" на высоте);
  • Неполадки на маршруте или не оплачен провайдер. "check-gateway=ping" не прокатывает, поскольку шлюз пингуется;
  • Не доступен или плохо работает DNS-сервер;
  • Где-то срабатывают фильтры по протоколам на определённые порты. Пинги проходят, а HTTP не коннектится;
  • Значение MTU. Выглядит так, будто интернет то работает, то нет;
  • Может ещё что-то
Об этом надо крепко думать и писать скрипты (или искать готовые).


wolf_ktl
Сообщения: 417
Зарегистрирован: 25 июн 2013, 18:12

Barvinok писал(а):Ты прав. В названии темы действительно заявлена отказоустойчивость. Изначально я полагал, что она сама собой достигается использованием двух каналов, но как оказалось, не всё так просто.
То, что для конечного пользователя определяется, как "у меня не работает интернет", может иметь множество причин:
  • Тупо обрыв линии (тут "check-gateway=ping" на высоте);
  • Неполадки на маршруте или не оплачен провайдер. "check-gateway=ping" не прокатывает, поскольку шлюз пингуется;
  • Не доступен или плохо работает DNS-сервер;
  • Где-то срабатывают фильтры по протоколам на определённые порты. Пинги проходят, а HTTP не коннектится;
  • Значение MTU. Выглядит так, будто интернет то работает, то нет;
  • Может ещё что-то
Об этом надо крепко думать и писать скрипты (или искать готовые).



Да было бы шикарно иметь такой скрипт


Аватара пользователя
Barvinok
Сообщения: 104
Зарегистрирован: 28 фев 2012, 23:21

Буду рассуждать.
1. Значение MTU явно задаются руками при настройке маршрутизатора, ежели в том будет необходимость. Т.е. мы изначально добиваемся работоспособности обоих каналов и больше к вопросу MTU не возвращаемся.

То же касается и DNS-серверов. Время от времени их нужно проверять на способность исполнять свои обязанности. Если не способен - вычёркивать из списка используемых. К сожалению в RouterOS отсутствует команда, подобная nslookup, пока не знаю, чем его заменить из наличествующего арсенала.
Но несомненно одно: используемый DNS-сервера должны действительно работать!


2. Можно ли считать прохождение пинга надёжным знаком того, что канал жив? Ну, в целом то да. Но возможен случай, когда ICMP-трафик проходит, а TCP - нет. У меня на домашнем Би-Лайне именно так: даже с выключенным L2TP-соединением пинги в интернет ходят через Билайновский интранет. TCP и UDP разумеется нет.
Но если такой ерунды не происходит, то в 9 из 10 случаев пинг удалённых серверов можно считать хорошим знаком.

3. Рассмотрим случай возможности/невозможности установить TCP-подключение на 80-й порт yandex.ru. Можно ли с уверенностью сказать, что если такое соединение устанавливается, то канал жив? Вероятно.
А если это прокси провайдера с сообщением о неуплате? Пинги к внешним серверам в этом случае, кстати, тоже могут ходить! Засада...
Значит нам нужно проверить не просто возможность подключения к некоему серверу, но и убедиться, что он отдаёт нам ожидаемую страницу! Т.е. нам придётся парсить HTML...
Мы можем использовать кусок кода из Dynamic DNS Update Script.

Код: Выделить всё

# get the current IP address from the internet (in case of double-nat)
/tool fetch mode=http address="checkip.dyndns.org" src-path="/" dst-path="/dyndns.checkip.html"
:delay 1
:local result [/file get dyndns.checkip.html contents]

# parse the current IP result
:local resultLen [:len $result]
:local startLoc [:find $result ": " -1]
:set startLoc ($startLoc + 2)
:local endLoc [:find $result "</body>" -1]
:local currentIP [:pick $result $startLoc $endLoc]
:log info "UpdateDynDNS: currentIP = $currentIP"

Мы можем сравнить полученный ip-адрес с нашим адресом на интерфейсе и если они совпадают - канал точно работает!
Но только при условии наличия белого адреса, разумеется. Если у вас на внешнем интерфейсе серые адреса нужно будет чуть по другому.

А если указанный сайт недоступен, можно ли с такой же уверенностью сказать, что канал упал? Не можем, поскольку:
а) может упасть сам checkip.dyndns.org;
б) ещё причина могла крыться в недоступности DNS-сервера. Т.е. канал то жив, но имя checkip.dyndns.org не преобразуется в ip-адрес. Но поскольку мы изначально эту возможность предусмотрели и приняли меры, то "б" вычёркиваем.

Что-то ещё? Вроде бы нет...
Тогда нужен запасный путь - второй подобный сайт с предсказуемым содержимым страницы. В конце концов можно закачать произвольный файл на хостинг собственного сайта! Я уверен, что у подавляющего большинства здесь присутствующих такой уютненький хостинг имеется.

Вот такие мысли. Что скажите, уважаемые?


wolf_ktl
Сообщения: 417
Зарегистрирован: 25 июн 2013, 18:12

Barvinok писал(а):Буду рассуждать.

3. Рассмотрим случай возможности/невозможности установить TCP-подключение на 80-й порт yandex.ru. Можно ли с уверенностью сказать, что если такое соединение устанавливается, то канал жив? Вероятно.
А если это прокси провайдера с сообщением о неуплате? Пинги к внешним серверам в этом случае, кстати, тоже могут ходить! Засада...
Значит нам нужно проверить не просто возможность подключения к некоему серверу, но и убедиться, что он отдаёт нам ожидаемую страницу! Т.е. нам придётся парсить HTML...
Мы можем использовать кусок кода из Dynamic DNS Update Script.

Код: Выделить всё

# get the current IP address from the internet (in case of double-nat)
/tool fetch mode=http address="checkip.dyndns.org" src-path="/" dst-path="/dyndns.checkip.html"
:delay 1
:local result [/file get dyndns.checkip.html contents]

# parse the current IP result
:local resultLen [:len $result]
:local startLoc [:find $result ": " -1]
:set startLoc ($startLoc + 2)
:local endLoc [:find $result "</body>" -1]
:local currentIP [:pick $result $startLoc $endLoc]
:log info "UpdateDynDNS: currentIP = $currentIP"

Мы можем сравнить полученный ip-адрес с нашим адресом на интерфейсе и если они совпадают - канал точно работает!
Но только при условии наличия белого адреса, разумеется. Если у вас на внешнем интерфейсе серые адреса нужно будет чуть по другому.

А если указанный сайт недоступен, можно ли с такой же уверенностью сказать, что канал упал? Не можем, поскольку:
а) может упасть сам checkip.dyndns.org;
б) ещё причина могла крыться в недоступности DNS-сервера. Т.е. канал то жив, но имя checkip.dyndns.org не преобразуется в ip-адрес. Но поскольку мы изначально эту возможность предусмотрели и приняли меры, то "б" вычёркиваем.

Что-то ещё? Вроде бы нет...
Тогда нужен запасный путь - второй подобный сайт с предсказуемым содержимым страницы. В конце концов можно закачать произвольный файл на хостинг собственного сайта! Я уверен, что у подавляющего большинства здесь присутствующих такой уютненький хостинг имеется.

Вот такие мысли. Что скажите, уважаемые?


Ну можно заморочиться и воспользоваться и checkip.dyndns.org и no-ip.org ... одновременно )))


Аватара пользователя
Barvinok
Сообщения: 104
Зарегистрирован: 28 фев 2012, 23:21

По моему мы тут дурака валяем.
Интернет полон всякими потоковыми сервисами и мусорным трафиком. Зачем генерить свой, если можно использовать то, что есть?
Запустите /tool sniffer или /ip firewall connection и вы увидите, что какие-то добрые люди постоянно сканируют ваши порты и пытаются вам что-то прислать.
Это будет похоже на шум океана или большого города.
Если этот шум вдруг прекратился - значит канал пал (второй вариант - ядерный апокалипсис - я пока не рассматриваю).
Осталось только это как-то выразить в коде...


Однако, если вы находитесь за NATом провайдера (серый адрес), то шум большого Интернета до вас долетать не будет.
В этом случае можно положиться на UDP-протокол, который я незаслуженно обошёл вниманием.
При блокировке интернета ICMP может продолжать гулять. Но UDP перекрывается провайдером наравне с TCP. Можно, к примеру, слать запросы к NTP-серверам. Если ответы приходят - интернет жив!
Но хранители времени не любят, когда их часто тревожат и могут вас очень скоро забанить.

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

Да много чего ещё есть - это же ИНТЕРНЕТ!

Буду думать, как бы это покрасивше всё оформить.
Последний раз редактировалось Barvinok 22 сен 2013, 10:13, всего редактировалось 4 раза.


aabbyr
Сообщения: 3
Зарегистрирован: 06 сен 2012, 18:25

по поводу отказоустойчивости интересная статья
Скрипт автора пингует три разных узла. Интернет на интерфейсе считается нерабочим, если приходит менее 2/3 ответов
http://www.pvsm.ru/sistemnoe-administrirovanie/5083


Закрыто