Микротик. два доставчика. Балансиране.
И така, имаме рутер, който свързва нашата локална мрежа и два канала към интернет (основен ISP1 и резервен ISP2).
Нека да разгледаме какво можем да направим:
Ще ви предупредя веднага: въпреки факта, че в тази статия ще опиша всичко за mikrotik, няма да засягам темата за скриптовете
Разполагаме с резервен канал, към който може да се насочи трафик в случай, че основният откаже. Но как да накарам mikrotik да разбере, че каналът е паднал?
Най-простата резервация на канал
Най-простият отказ може да бъде конфигуриран с помощта на приоритета на маршрута (разстояние за mikrotik / cisco, метрика за linux / windows), както и механизма за проверка на наличността на шлюза - check-gateway.
конфигурация: прост отказ
check-gateway=ping за mikrotik се обработва по следния начин: Периодично (на всеки 10 секунди) шлюзът се проверява чрез изпращане на ICMP пакет (ping) към него. Пакетът се счита за изгубен, ако не се върне в рамките на 10 секунди. След два изгубени пакета шлюзът се счита за недостъпен. След получаване на отговор от шлюза, той става достъпен и броячът на изгубените пакети се нулира.
Осигуряване на отказ с по-задълбочен анализ на канала
В предишния пример всичко е наред, с изключение на ситуацията, когато шлюзът на доставчика е видим и пингован, но няма интернет зад него. Ще ни помогне много, ако можем да вземем решение относно жизнеспособността на доставчика, като пингваме не самия шлюз, а нещо зад него.
Знам два варианта за решаване на този инженерен проблем. Първият и най-често срещан е използването на скриптове, но тъй като не засягаме скриптове в тази статия, ще се спрем на втория. Това предполага не съвсем правилно използване на параметъра за обхват, но ще ни помогне да изследваме канала на доставчика по-дълбоко, отколкото преди шлюза. Принципът е прост: Вместотрадиционен шлюз по подразбиране=шлюз на доставчика, казваме на рутера, че шлюзът по подразбиране е един от always_available_hosts (например 8.8.8.8 или 8.8.4.4) и на свой ред е достъпен през шлюза на доставчика.
конфигурация: преход при срив с по-задълбочен анализ на канала
Сега нека да разгледаме какво се случва малко по-подробно: Номерът е, че шлюзът на ISP не знае, че 8.8.8.8 или 8.8.4.4 е рутер и ще насочи трафика по нормалния начин. Нашият mikrotik вярва, че по подразбиране целият интернет трафик трябва да се изпраща до 8.8.8.8, който не се вижда директно, но е достъпен през 10.100.1.254. И ако ping на 8.8.8.8 изчезне (нека ви напомня, че пътят до него е твърдо кодиран през шлюза от ISP1), тогава mikrotik ще започне да изпраща целия интернет трафик към 8.8.4.4 или по-скоро към рекурсивно дефинирания 10.200.1.254 (ISP2).
Но няколко пъти имах ситуация, при която интернет през шлюза на доставчика работи, но конкретен възел или мрежа не работи. В такива случаи горният метод не помага наистина и за да осигуря гладка работа, трябваше да проверя наличността на възела, който вече използваше скриптове. Между другото, ако някой знае решение за файлър за един външен хост без използване на скриптове и протоколи за динамично маршрутизиране, да сподели рецептата.
Балансиране на натоварването
Сега нека да разгледаме друга схема:
В него вторият втори канал вече не е резервен, а еквивалентен. Защо не използвате и двата канала едновременно, като по този начин увеличите пропускателната способност?
Първи стъпки с балансирането на натоварването
Второто нещо, което също е важно да разберете е, че трябва да разделите понятията входящ и изходящ трафик. Факт е, че за изходящия трафик рутерът може да реши кой път ще поеме, а входящият трафик за него е като „трафик на Шрьодингер“.Докато го няма, нашият микротик не знае през кой интерфейс ще дойде и когато дойде, вече е късно да промени интерфейса.
Трето, балансирането на връзката не е резервация. Това са две отделни функции.
Подготвяме се да приемем "трафика на Шрьодингер"
Споделяне на изходящ трафик
За да разпределим изходящия трафик между интерфейсите, просто трябва да поставим съответната маркировка за маршрут върху връзката. Трудността е, че трябва да решите на коя връзка да окачите етикета ISP1 и на коя ISP2.
Има няколко опции за разделяне на съединенията в групи:
1) Разделете изходящия трафик, като стегнете плътно марката
Можем да зададем правилата, които стриктно балансират трафика: Например, искаме да конфигурираме протоколите HTTP (80 порт), HTTPS (443 порт), POP (110 порт), SMTP (25 порт), които са важни за нас чрез ISP1, и да оставим целия останал трафик през втория доставчик:
конфигурация с балансиране на канали според твърдо кодирани правила
2) Разделете изходящия трафик, като изберете всяка N-та връзка
Можем да разделим връзките по ред. Първият отляво, вторият отдясно. Всичко е просто.
конфигурация с балансиране на канала на H връзка:
3) Разделете изходящия трафик с помощта на PCC (за класификатор на връзка)
PCC подхожда към разделянето на трафика малко по-сложно. Той разделя трафика на групи въз основа на информация за заглавката на TCP (src-адрес, dst-адрес, src-порт, dst-порт).
Конфигурация за балансиране на PPC канал:
Разделяме изходящия трафик с помощта на ECMP (многопътно маршрутизиране с равни разходи)
Според мен най-простият и вкусен вариант за разделяне на трафика:
конфигурация с балансиране на ECMP канал
Самият Mikrotik ще разделя трафика по шлюзове, като използва алгоритъма за кръгъл робот.
Между другото, във версия 6.X на RouterOS mikrotik счупи check-gateway в ECMP, така че използването на /ip route add gateway=10.100.1.254,10.200.1.254 check-gateway=ping конструкция е възможна и логична, но абсолютно безполезна. За да маркирате неактивни маршрути в ECMP, трябва да създадете допълнителни маршрути, които използват всеки от шлюзовете поотделно. С активиран check-gateway, разбира се. Маркирайки маршрут като неактивен, mikrotik го прави за всички.
И последната важна забележка относно скоростта на каналите
Да вземем 2 неравни канала, например 100 Mbps и 50 Mbps. Ние ги балансираме чрез Nth, PCC или ECMP. Каква е общата производителност?
Всъщност - някъде около 100 Mbps (най-слабият канал X пъти). Това се случва, защото mikrotik няма представа за честотната лента на каналите, не я измерва. Той просто разделя трафика на относително равни групи.
Можете да преодолеете този нюанс, като правилно проектирате групи от изходящ трафик, като вземете предвид честотната лента на каналите.
Например в ECMP това може да се направи чрез указване на по-бърз шлюз няколко пъти, като по този начин се увеличи честотата на неговото използване.
В PCC можете също да правите неравни групи:
Благодаря за вниманието.
Успех при настройването на безотказни системи за маршрутизиране.