🌐 Load Balancing i Failover na MikroTik – Kompletny przewodnik krok po kroku

Współczesna infrastruktura sieciowa wymaga nie tylko wysokiej dostępności usług, ale również ich niezawodności, elastyczności i odporności na awarie. W przypadku routerów MikroTik, które pracują w środowiskach domowych, korporacyjnych oraz ISP, coraz częściej oczekuje się funkcji równoważenia obciążenia (Load Balancing) oraz automatycznego przełączania połączenia przy awarii (Failover).

RouterOS oferuje wiele metod realizacji tych funkcji — od prostych, statycznych routingu opartych na distance lub routing-mark, aż po zaawansowane konfiguracje z użyciem netwatch, check-gateway, PCC i ECMP.

Ten artykuł to kompleksowy przewodnik konfiguracji Load Balancing i Failover na MikroTik. Od podstaw, przez mechanizmy działania, aż po przykładowe skrypty i strategie najlepszych praktyk.

🎯 Cele i założenia

Zakładamy następującą strukturę fizyczną:

Każde z połączeń ma własne IP oraz bramę. Zakładamy także, że oba łącza mają dostęp do internetu.

⚙️ Metody Load Balancing i Failover

🔧 Przykład: Prosty Failover z check-gateway

Najprostsza forma Failoveru polega na ustawieniu dwóch domyślnych tras (default route) z różnymi priorytetami.

/ip route
add dst-address=0.0.0.0/0 gateway=192.0.2.1 check-gateway=ping distance=1
add dst-address=0.0.0.0/0 gateway=198.51.100.1 check-gateway=ping distance=2

🟢 check-gateway=ping – RouterOS sam pingnie bramę. Jeśli nie odpowie – trasa zostanie oznaczona jako nieaktywna.

🔁 Prosty Load Balancing z ECMP (Equal Cost Multi-Path)

/ip route
add dst-address=0.0.0.0/0 gateway=192.0.2.1,198.51.100.1

MikroTik automatycznie będzie balansował ruch, ale per-destination. Nie działa dobrze z NAT – ponieważ każde połączenie może mieć inny IP.

🔍 Load Balancing z PCC (Per Connection Classifier)

Najlepsza metoda do Load Balancing z NAT to użycie PCC – dzieli ruch per-źródło, per-cel lub per-port.

🎯 Cel: 50/50 Load Balancing + Failover

/ip firewall mangle
add chain=prerouting in-interface=ether3 per-connection-classifier=both-addresses:2/0 action=mark-connection new-connection-mark=ISP1_conn
add chain=prerouting in-interface=ether3 per-connection-classifier=both-addresses:2/1 action=mark-connection new-connection-mark=ISP2_conn

add chain=prerouting connection-mark=ISP1_conn in-interface=ether3 action=mark-routing new-routing-mark=to_ISP1
add chain=prerouting connection-mark=ISP2_conn in-interface=ether3 action=mark-routing new-routing-mark=to_ISP2

/ip route
add gateway=192.0.2.1 routing-mark=to_ISP1 check-gateway=ping
add gateway=198.51.100.1 routing-mark=to_ISP2 check-gateway=ping

/ip route
add dst-address=0.0.0.0/0 gateway=192.0.2.1 distance=1
add dst-address=0.0.0.0/0 gateway=198.51.100.1 distance=2

📌 Powyższa konfiguracja dzieli ruch NAT pomiędzy dwóch dostawców. Jeśli jeden padnie – cały ruch przejmie drugi.

🧠 Netwatch – dynamiczny failover przez skrypty

Jeśli chcesz pełnej kontroli i monitorowania konkretnego hosta (np. 8.8.8.8):

/tool netwatch
add host=8.8.8.8 interval=10s timeout=2s up-script="/ip route enable [find comment=ISP1]" down-script="/ip route disable [find comment=ISP1]"

💡 Netwatch umożliwia wykonywanie dowolnych skryptów, np. wysyłanie e-maili, zmiana tras, itp.

📋 Porównanie metod

🧱 Błędy i pułapki

1. ❌ Nieużywanie check-gateway – trasa zostanie uznana za aktywną, mimo awarii
2. ❌ Brak oznaczenia połączeń w NAT – prowadzi do zrywania sesji
3. ❌ Zbyt szybkie przełączanie w Netwatch – fałszywe pozytywy/negatywy
4. ❌ Nieodpowiednie routing-mark w NAT – częsty problem z dostępem z zewnątrz
5. ❌ Nieprzemyślane DNS – powoduje problemy z rozwiązywaniem adresów, jeśli nie ma synchronizacji

✅ Dobre praktyki

• Zawsze testuj konfigurację z lokalnego hosta – unikniesz odcięcia dostępu
• Używaj komentarzy w trasach i regułach, np. comment=ISP1
• Do monitorowania używaj adresów zewnętrznych (nie bramy ISP)
• W przypadku PCC, unikaj łączenia z usługami wymagającymi sticky sessions (np. bankowość)

🧠 Zaawansowane: Failover tylko dla ruchu HTTP

Możesz stworzyć reguły NAT + mangle, które pozwolą tylko ruchowi HTTP korzystać z drugiego łącza — reszta idzie przez podstawowy link.

🎯 Podsumowanie

Konfiguracja Load Balancing i Failover na MikroTik może być prosta lub ekstremalnie zaawansowana — zależnie od potrzeb i środowiska. Dzięki potężnym narzędziom jak PCC, Netwatch, routing-mark, można zbudować redundantne, skalowalne i wysoce dostępne rozwiązania sieciowe, które sprawdzą się w domowym biurze, jak i w data center.

Kluczowa jest jednak znajomość mechanizmów działania, poprawna kolejność konfiguracji i testowanie scenariuszy awarii, zanim wystąpią naprawdę.

Polecane wpisy

Konfiguracja MikroTik – Część 47: MikroTik jako lokalny serwer DNS z filtrowaniem treści i cache’owaniem odpowiedzi

Konfiguracja MikroTik – Część 47: MikroTik jako lokalny serwer DNS z filtrowaniem treści i cache’owaniem odpowiedzi 🔍 Wprowadzenie W większości Czytaj dalej

Omówienie zalet IPv6 w porównaniu z IPv4

Omówienie zalet IPv6 w porównaniu z IPv4 Co to jest IPv6? IPv6 (Internet Protocol version 6) to najnowsza wersja protokołu Czytaj dalej