MikroTik, load balancing, ECMP, recursive failover, port source route

load-balance

MikroTik, load balancing, ECMP, recursive failover, port source route

Никога не съм бил привърженик на load balancing но истината е, че по някой път се налага. Обикновенно това се случва в домашни условия или в малък офис. Решението да имаш два независими един от друг доставчика на Интернет винаги е било по добро от един на бизнес тарифа защото въпроса обикновенно освен до добра свързаност към глобалната мрежа опира и до отказоусточивост. Естествено това което ще покажа тук не е идеално решение защото според мен в load balancing такова няма, но е база в която ако се пипне тук там може да задоволи малък брой потребители.

конфигуриране на DNS

Като начало трябва да добавим DNS сървъри които са независими и от двата ни доставчика на Интернет защото ако падне някой от тях или ще ни се влоши връзката или въобще няма да имаме Интернет. В случая ще използваме сървърите на open dns като вече доказали се с надежност.

/ip dns
set allow-remote-requests=yes servers=208.67.222.222,208.67.220.220

маркиране на изходящия трафик с routing mark

Тъй като за load balancing ще използваме ECMP което не е най интелигентното решение но за сметка на това пък е много просто трябва да маркираме част от изходящия трафик. Трафик който трябва да сме сигурни, че излиза през единия ни доставчик за да нямаме проблем с протоколи като www,ssl,mail,voip,ssh и др които изискват аутентикация или пък следят източника на пакети. Разбира се в тези правила може да се добавят и портове на игри или други приложения ако е нужно това.

/ip firewall mangle
add action=mark-routing chain=prerouting dst-port=20-23,25,80-81,110,143,443,465,585,587 new-routing-mark=SRC-ROUTE1 protocol=tcp
add action=mark-routing chain=prerouting dst-port=993,995,2222,2526,4444,5060-5061,8080,8291 new-routing-mark=SRC-ROUTE1 protocol=tcp
add action=mark-routing chain=prerouting dst-port=5060-5061,10000-20000 new-routing-mark=SRC-ROUTE1 protocol=udp

routing-mark

конфигуриране на NAT

Стандартно трябва да маскираме и двата ни доставчика на Интернет.

/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
add action=masquerade chain=srcnat out-interface=ether2

конфигуриране на load balancing

Часта с routinga идва малко сложна поради което ще и обърна малко по сериозно внимание защото освен ECMP ще използваме и recursive failover както и на самият load balancing така и на изходящия трафик който маркирахме да минава само през единия доставчик. Идеята вече я споменах ОТКАЗОУСТОЧИВОСТ. При правилна конфигурация ако падне единия доставчик свързаноста ще се изгуби за 10-20 секунди което е в рамките на търпимото.

/ip route
add distance=1 dst-address=8.8.4.4/32 gateway=10.125.3.1 scope=10
add distance=1 dst-address=8.8.8.8/32 gateway=85.118.95.33 scope=10
add check-gateway=ping distance=1 gateway=8.8.4.4,8.8.8.8

В първите два реда рутираме двата хоста на google през двата ни доставчика за да знае рутера ни къде се намират те. Респективно 8.8.8.8 през първия и 8.8.4.4 през втория ни доставчик. В третия ред правим три неща едновременно:

1. с gateway=8.8.4.4,8.8.8.8 създаваме load balancing с политика ECMP.
3. тъй като маршрута по подразбиране gateway е 8.8.4.4,8.8.8.8 а не на доставчиците ние създадохме recursive route
2. с check-gateway=ping следим дали ще падне някой от хостовете на google които на практика вече са нашите маршрути по подразбиране.

Допълнително подсигуряване с маршрут по подразбиране

Какво ще стане обаче ако по някаква причина изгубим достъп и до двата хоста на google ? Ясно е, че Интернет ще има след рутера а ние не, защото ще ни паднат маршрутите по подразбиране. Затова трябва да се подсигурим с още един такъв с по висока метрика distance=2 който ще се активира само ако паднат google хостовете които са с метрика distance=1.

/ip route
add distance=2 gateway=85.118.95.33

failover на маркирания трафик

/ip route
add check-gateway=ping distance=1 gateway=8.8.8.8 routing-mark=SRC-ROUTE1
add check-gateway=ping distance=2 gateway=8.8.4.4 routing-mark=SRC-ROUTE1
add distance=3 gateway=85.118.95.33 routing-mark=SRC-ROUTE1

Последното което трябва да направим е същото но с маркирания изходящ трафик който конфигурирахме в ip firewall mangle с routing-mark=SRC-ROUTE1. Тук трябва да следим само метриките, първия ред е маршрут на изходящия трафик по подразбиране, втория ще се активира ако падне първия а третия ако паднат двата google хоста. По този начин имаме failover не само на load balancing но и на маркирания трафик.

load-balancing

Тест на конфигурацията

На срииншота по долу виждаме зона 1 bridge което е LAN мрежата на рутера а в зона 2 трафика който преминава и през двата ни доставчика ether1 и ether2.

interface

по тънки настройки

Може би някой ще зададе въпроса какво ще стане ако единия доставчик предлага два пъти по голяма скорост от другия ?. В ECMP има решение за този казус, нарича се тежест (weight). В реда с маршрута по подразбиране трябва да повторим два пъти gateway по този начин.

/ip route
add check-gateway=ping distance=1 gateway=8.8.4.4,8.8.4.4,8.8.8.8

В случая през доствчик 2 с маршрут 8.8.4.4 ще преминават два пъти повече пакети от 8.8.8.8 като това няма да засяга маркирания трафик.

ECMP

тест от страна на потребителя

При изходящ порт 80 винаги трябва да излизам с адреса на първия доставчик.
ipaddress

traceroute към dir.bg
mtr-dir.bg

traceroute към mail.bg
mtr-mil.bg

още маршрути от рутера

Тъй като споменах, че ECMP е малко “прост” в случай, че отвън искам да достъпя рутера ще се появи проблем от рода на постоянно появяване и изчезване. Това е така защото той разпределя пакетите според тежеста която сме му задали. За да гарантирам, че определен хост в случая 85.118.95.126 ще го вижда безпроблемно в Интернет ще създам още един маршрут.

ip route add dst-address=85.118.95.126 gateway=85.118.95.33

конфигурирне на DMZ

Често попадаме в ситуация в която имаме нужда от пренасочване на портове или от DMZ. Видеонаблюдения, локален сървър който искаме да достъпваме от Интернет и др. ИП адреса който ще използвам от локалната мрежа ще е 192.168.1.42 рутирайки го към доставчик 1 същия през който маркирахме изходящия трафик.

/ip firewall mangle
add action=mark-routing chain=prerouting new-routing-mark=SRC-ROUTE1 src-address=192.168.1.42

Мисля, че е важно да добавя, че изходящия трафик на адреса 192.168.1.42 винаги ще излиза през първия доставчик и за да e достъпен той например на порт 10000 от интернет трябва да добавим правило в NAT.

/ip firewall nat
add chain=dstnat in-interface=ether1 protocol=tcp dst-port=10000 action=dst-nat to-addresses=192.168.1.42 to-ports=10000

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

This Post Has 6 Comments

  1. Милко Стоянов

    Много полезна статия. Имам един въпрос.
    Статията започва с това, че не сте привърженик на load balancing. Кое е за предпочитане ако все пак разполагаме с два доставчика? Става въпрос за офис с около 20 компютъра. Оставам с впечатление, че и failover не е за предпочитане. Благодаря предварително.

  2. Самуил Арсов

    Специално за Load Balancing, нищо му няма, просто е по специфичен. За ~20-на компютъра – да, за всеки един можеш да добавиш някакво правило за нуждите му (написано е вече горе https, ssh, smtps и други). Ако работното ти място е зад рутера още по добре макар, че диагностиката също е по трудна. Но ако си на отдалечено място и ти се обадят по тела да ти кажат, че нещо не работи трябва да си малко “шаман” за да оправиш нещата.

    Failover е много по интуитивен ако нещо не работи, знаеш , че всичките пакети трябва да минат от тук, а не от тук и търсиш проблема на едно място за разлика от Load Balancing в който icmp (пинг) върви през първия доставчик а a https през втория и човека по тела ти казва, че не отваря сайтове и ти не си там на неговото PC но имаш достъп до рутера който не те устройва защото в Load Balancing е създал рутираща таблица да препраща пакети от клиента и тя не важи за самия рутер. Нарочно дадох точно този пример защото това е най често срещаната грешка в Load Balancing (това което вижда клиента и това което вижда рутера е нормално да не е едно и също).

    Общо взето не е въпрос на вкус (харесва ? – не харесва ?) а въпрос на правилно решение което преобладава към – по малко клиенти Load Balancing / повече клиенти Fajlover.

  3. Милко Стоянов

    Много благодаря за отговора. Категорично след Вашия коментар ще използвам Failover, тъй като аз съм извън офиса на въпросната фирма и ще действам отдаличено, което както казахте ще е малко по-трудоемко. При Failover обаче се натъквам на следния проблем: Когато физически паде интерфейса микротика превключва на другия доставчик, но ако спре връзката някаде преди нашия рутер не ще да отрази загубата на интернет. Това как се решава и решава ли се? Благодаря предварително.

  4. NetIs

    Тоест всичко досега се е чупило при мен само заради тъпия https. Благодарение на тази статия заработи нормално един офис с десетина компютъра и още толкова телефони зад него с балансиране на трафика. Найстина полезно !

  5. Николай

    А може ли да се замени вместо статичен IP адрес за WAN1/2 да се ползва само ether1, ether2. Т.е. доставчиците ни дават публични динамични адреси.

    примерно:
    /ip route
    add distance=1 dst-address=8.8.4.4/32 gateway=ether1 scope=10
    add distance=1 dst-address=8.8.8.8/32 gateway=ether2 scope=10
    add check-gateway=ping distance=1 gateway=8.8.4.4,8.8.8.8

    и т.н.