- Mikrotik
- Failover
Я розглядаю розширений варіант з перевірками 4 хостів (2 через ISP1, і ще 2 інших хоста через ISP2). У загальних рисах ідея ясна, у мене все працює, але з доопрацюваннями, але не в них питання, а в ясності процесу. Про всяк випадок, я бачив статті і на Хабре і багато де ще.
Хочеться зрозуміти, що має бути додано до офіційного wiki, яке я навів вище.
Наводжу код (пронумеруйте рядки, ясна річ, в скрипті нумерації немає):
check-gateway = ping перевіряє доступність хоста, вказаного як шлюз (Host1A. Host2B, я використовував 8.8.8.8, 8.8.4.4 і ще два інших IP). Якщо він не доступний, то шлюз позначається як недіючий (офіц. Wiki: Periodically (every 10 seconds) check gateway by sending either ICMP echo request (ping) or ARP request (arp). If no response from gateway is received for 10 seconds, request times out. After two timeouts gateway is considered unreachable. After receiving reply from gateway it is considered reachable and timeout counter is reset.).
Які при цьому повинні бути прописані дефолтні маршрути?
Перше, що спадає на думку (default listing v.1):
не працюватимуть як failover, тому що навіть якщо ISP1 впаде і Host1A і Host1B стануть недоступними, це ніяк не відіб'ється на маршрутах по-замовчуванню (0.0.0.0/0).
Ось такий варіант (default listing v.2):
мені зрозумілий, він працює. Але він:
- працює зовсім не залежачи від рядків 6) -9), вони просто не потрібні при такому розкладі.
- не дає переваги перевірки доступності відразу двох хостів через ISP1 і інших двох хостів через ISP2
Якщо "доопрацювати" приклад з wiki, забезпечити дефолтні маршрути мітками ISP1 і ISP2 відповідно, то за допомогою Netwatch можна створити завдання, які при недоступності Host1A виконають щось на кшталт:
/ Ip route disable [find comment = "ISP1"]
а при доступності:
/ Ip route enable [find comment = "ISP1"]
Все здорово, і так теж працює.
Питання: чому в wiki за посиланням на початку взагалі нічого не сказано про дефолтні маршрути? Мається на увазі, що читає сам допрет, що треба якось викручуватися? Навіщо дані рядка 6) -9) - я так і не зрозумів їх реальне функціонування. Можете прояснити для мене ланцюжок?
123459. Так, бачив. Там теж саме, що мені зрозуміло і про що я вже писав:
# Вкажемо 2 default gateway через вузли шлях до яких вказано рекурсивно
/ Ip route add dst-address = 0.0.0.0 / 0 gateway = 8.8.8.8 distance = 1 check-gateway = ping
/ Ip route add dst-address = 0.0.0.0 / 0 gateway = 8.8.4.4 distance = 2 check-gateway = ping
Перевіряються ping-ами дефолтні маршрути. Соответсятвенно і вимикається при нагоді дефолтний маршрут. А мені не ясно, навіщо в wiki (посилання приводив на початку топіка) присутні рядки з 6 по 9 Як вони впливають на перемикання дефолтних маршрутів?
Олександр Романов. А ви routing-mark використовуєте?
У мене зараз так: якщо я в prerouting маркують пакети з lan-інтерфейсу як "routing-mark = ISP1", то трафік йде через ISP1, якщо "routing-mark = ISP2", трафік йде через ISP2.
Якщо не робити нічого з mangle, взагалі нікуди нічого не йде.
/ Ip route print detail where routing-mark = "ISP1"
0 A S dst-address = 0.0.0.0 / 0 gateway = 10.1.1.1 gateway-status = 10.1.1.1 recursive via GW1 ether1 distance = 1 scope = 30 target-scope = 10
routing-mark = ISP1
1 S dst-address = 0.0.0.0 / 0 gateway = 10.2.2.2 gateway-status = 10.2.2.2 recursive via GW2 ether2 distance = 2 scope = 30 target-scope = 1
routing-mark = ISP1
Працюю, в загальному.
MarvinD. Мангла потрібно маркувати пакети, що б маршрутизатор відповідав саме в той інтерфейс, в який пакет прийшов. Приклади є в доці і на Хабре. В іншому випадку можна не достукатися до роутера ззовні.
Фейловер на скриптах корисний тільки тим, що можна заскріптіть відправку емейлів при падінні основного каналу. Без скриптів падіння каналу можна не помітити, я так на резервному провайдера тиждень працював, поки від основного прова не впізнав, що у нас впав радиолінк%) При цьому з фейловером на скриптах є момент - як часто ви будете цей скрипт смикати? Раз в хвилину? Фейловер без скриптів перещелкнет канал при втраті 3х пінгів, це
10 секунд. При цьому при бажанні ніхто не заважає заскріптіть відправку емейла і через нетвоч.
poisons. я вважаю, що реалізація на скрипті краще хоча б тому, що можна пінгувати одні і ті ж хости. Можна реілізовивать більш складні умови, так наприклад я пінг 4 хоста і переключився на резервний канал, якщо хоча б 2 з них недоступні (але в той же час доступні через резервний). Можна оцінювати якість каналу, задаючи руками таймаут і розмір icmp пакетів, і перемикати на резервний канал, коли втрата пакетів перевищує якийсь поріг. Скрипт можна смикати так часто, як захочете. Я смикаю кожні 20 секунд. Можна і кожну секунду запускати з відповідними доопрацюваннями. Ну і найголовніше, немає ніяких віртуальних шлюзів, спеціальних маршрутів до якихось певних хостів (ось ви наприклад хочете пінгувати 8.8.8.8, ок, а що якщо хтось хоче використовувати його як DNS?), Немає неявних значень (частота і кількість пінгів при перевірки доступності шлюзу), ну і саме перемикання більш явно - змінюється дистанція маршрутів, а не відключаються якісь там віртуальні маршрути, через які трафік Рауса назад.