Маршрутизація в декілька маршрутів у ядрах після 3.6


16

Як ви, напевно, всі знаєте, кеш маршруту ipv4 був видалений у версії ядра 3.6 Linux, що мало серйозний вплив на багатошлях. IPv4-код маршрутизації (на відміну від IPv6-одного) вибирає наступний перехід в круговому режимі, тому пакети від даного вихідного IP-адреси до IP-адреси призначення не завжди проходять через той самий наступний перехід. Перед тим, як кеш маршрутизації виправляв цю ситуацію, оскільки наступний перехід був обраний у кеш, і всі подальші пакети з того самого джерела до того самого пункту призначення проходили через наступний перехід. Тепер наступний хоп переобирається для кожного пакету, що призводить до дивних речей: з 2 рівними маршрутами за замовчуванням у таблиці маршрутизації, кожен із яких вказує на одного Інтернет-провайдера, я навіть не можу встановити TCP-з'єднання, тому що початковий SYN та остаточний ACK йти різними маршрутами,

Чи є відносно простий спосіб відновити нормальну поведінку багатошляхової маршрутизації, щоб наступний перехід вибирався за потоком, а не за пакетом? Чи є патчі навколо, щоб зробити IPv4 наступним хеш-вибором на основі хешу, як це для IPv6? Або як ви все з цим справляєтеся?


Чи є у вас налаштування "розділеного доступу", подібний до цього: lartc.org/howto/lartc.rpdb.multiple-links.html ? Якщо так, як виглядає ваш набір правил і маршрути?
Вабіт

спробуйте використати "ip route get 173.194.112.247" кілька разів та опублікуйте вихід
c4f4t0r

Дякую за смачне запитання. :) Перш за все, ви не привели нам приклад. Тож я гадаю, у вас є щось подібне ip ro add 8.8.8.8/32 nexthop via 1.2.3.4 nexthop via 1.2.3.5- це правильне припущення?
poige

Так, це правильно, але зазвичай це ip route додати 0,0.0.0/0 з декількома наступними стрибками.
Євген

Вабіт, так, саме так. "провайдер 1" і "провайдер2" у моєму випадку - це кордонні маршрутизатори, підключені до моєї внутрішньої мережі та мережі провайдера, і вони мають джерело NAT. У моєму внутрішньому маршрутизаторі у мене просто шлюз за замовчуванням з двома переходами, що вказують на провайдера1 та провайдера2, інших маршрутів немає. Правила брандмауера просто дозволяють деяким службам (наприклад, HTTP) для клієнтських машин і блокувати все інше.
Євген

Відповіді:


8

Якщо можливо, оновіть до ядра Linux> = 4.4 ....

Введено багатошарову маршрутизацію на основі хешу , яка багато в чому краща за поведінку попереднього рівня 3.6. Це на основі потоку, приймаючи хеш джерела і IP-адреси призначення (порти ігноруються), щоб підтримувати шлях стабільним для окремих з'єднань. Недоліком є ​​те, що я вважаю, що існували різні алгоритми / режими конфігурування, доступні до 3.6, але тепер ви отримаєте те, що вам дано! Ви можете використовувати вплив на вибір шляху, weightхоча.

Якщо ви в моїй ситуації, то ви насправді хочете, 3.6 >= behaviour < 4.4але це більше не підтримується.

Якщо ви зробите оновлення до> = 4.4, тоді це слід зробити без жодних інших команд:

ip route add default  proto static scope global \
nexthop  via <gw_1> weight 1 \
nexthop  via <gw_2> weight 1

Або за допомогою пристрою:

ip route add default  proto static scope global \
 nexthop  dev <if_1> weight 1 \
 nexthop  dev <if_2> weight 1

Для всіх, хто підходить до цього рішення - подивіться також: net.ipv4.fib_multipath_use_neigh для автоматичного відключення "скинутого" nexthop / шлюзу.
Ростислав Канділаров

6

"Відносно легко" - складний термін, але ви можете

  1. налаштувати таблиці маршрутизації для кожного з ваших посилань - одна таблиця на посилання, з одним шлюзом за замовчуванням
  2. використовуйте netfilter, щоб накреслити однакові позначки на всіх пакетах одного потоку
  3. використовувати таблицю правил ip для маршрутизації пакетів через різні таблиці маршрутизації залежно від позначки
  4. скористайтеся зваженим маршрутом в декількох наступних кількостях, щоб врівноважити пакети, які перебувають на першому сеансі, через ваші шлюзи / посилання.

Під час розсилки в мережі netfilter на цю тему відбулася дискусія, де я краду списки:

1. Правила маршрутизації (RPDB та FIB)

ip route add default via <gw_1> lable link1
ip route add <net_gw1> dev <dev_gw1> table link1
ip route add default via <gw_2> table link2
ip route add <net_gw2> dev <dev_gw2> table link2

/sbin/ip route add default  proto static scope global table lb \
 nexthop  via <gw_1> weight 1 \
 nexthop  via <gw_2> weight 1

ip rule add prio 10 table main
ip rule add prio 20 from <net_gw1> table link1
ip rule add prio 21 from <net_gw2> table link2
ip rule add prio 50 fwmark 0x301 table link1
ip rule add prio 51 fwmark 0x302 table link2
ip rule add prio 100 table lb

ip route del default

2. Правила брандмауера (використання ipset для примусового «потокового» режиму LB)

ipset create lb_link1 hash:ip,port,ip timeout 1200
ipset create lb_link2 hash:ip,port,ip timeout 1200

# Set firewall marks and ipset hash
iptables -t mangle -N SETMARK
iptables -t mangle -A SETMARK -o <if_gw1> -j MARK --set-mark 0x301
iptables -t mangle -A SETMARK -m mark --mark 0x301 -m set !
--match-set lb_link1 src,dstport,dst -j SET \
          --add-set lb_link1 src,dstport,dst
iptables -t mangle -A SETMARK -o <if_gw2> -j MARK --set-mark 0x302
iptables -t mangle -A SETMARK -m mark --mark 0x302 -m set !
--match-set lb_link2 src,dstport,dst -j SET \
          --add-set lb_link2 src,dstport,dst

# Reload marks by ipset hash
iptables -t mangle -N GETMARK
iptables -t mangle -A GETMARK -m mark --mark 0x0 -m set --match-set
lb_link1 src,dstport,dst -j MARK --set-mark 0x301
iptables -t mangle -A GETMARK -m mark --mark 0x0 -m set --match-set
lb_link2 src,dstport,dst -j MARK --set-mark 0x302

# Defining and save firewall marks
iptables -t mangle -N CNTRACK
iptables -t mangle -A CNTRACK -o <if_gw1> -m mark --mark 0x0 -j SETMARK
iptables -t mangle -A CNTRACK -o <if_gw2> -m mark --mark 0x0 -j SETMARK
iptables -t mangle -A CNTRACK -m mark ! --mark 0x0 -j CONNMARK --save-mark
iptables -t mangle -A POSTROUTING -j CNTRACK

# Reload all firewall marks
# Use OUTPUT chain for local access (Squid proxy, for example)
iptables -t mangle -A OUTPUT -m mark --mark 0x0 -j CONNMARK --restore-mark
iptables -t mangle -A OUTPUT -m mark --mark 0x0 -j GETMARK
iptables -t mangle -A PREROUTING -m mark --mark 0x0 -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark --mark 0x0 -j GETMARK

Можливо, ви хочете слідкувати за обговоренням списку розсилки netfilter для деяких варіантів вище.


Не впевнений, але, можливо, буде простіше u32отримати важливі параметри хешу, а потім "label" призначений для ip rule's
poige

Дякую, але це виглядає як досить складне рішення. Те, що я не зовсім розумію, - це те, що тут відповідає за "штампувати однакові позначки на всіх пакетах одного потоку"? Як працює ця магія ipset? Я подумав, що ipset - це лише набір конкретних IP-адрес, які є хешованими та можуть відповідати правилам.
Євген

Ви маєте рацію ipset- це просто створення наборів, які заповнюються за допомогою --add-setта співставляються проти використання --match-set- але це здебільшого для з'єднань у новому стані. Для встановлених з'єднань стану марка проставляється на пакетах, використовуючи --restore-markпараметр CONNMARKцілі - ця директива копіює позначення з'єднання в пакет. Позначення з'єднання попередньо встановлюється за --save-markдопомогою POSTROUTINGланцюга (там, де проходили б пакети, що належать до нових з'єднань). Сценарій здається мені занадто заплутаним, але він передає ідею.
Вабіт

1
Так, зараз я зрозумів. Останнє запитання: ви розумієте, чому розробники ядер не вводять хеш-наступний вибір переходу для ipv4? Чи є якась причина, щоб не реалізувати його разом із видаленням кеш-маршруту? Подібне рішення для ipv6 працює досить добре. Чи не все це магія підкреслення - це надмірне завдання для такого простого завдання?
Євген

1
@Eugene, на жаль, я далеко не достатньо близький до розробки стека IP (або взагалі розробки ядра Linux), щоб авторитетно відповісти на будь-які ваші запитання, але я б припускав, що багатошляхетність з використанням різних провайдерів з IPv4 вважається занадто багато кутовий корпус, щоб вкласти більше роботи. Використання netfilter CONNMARKs, очевидно, виглядає як неприємний хитрість, але, можливо, навіть розглядався як "корисний спосіб вирішення" у вирішенні питання про скасування кеш-коду маршруту.
Вабіт
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.