Как вы все, наверное, знаете, кэш маршрутов ipv4 был удален в ядре 3.6 Linux, что серьезно повлияло на многопутевую маршрутизацию. Код маршрутизации IPv4 (в отличие от IPv6) выбирает следующий переход циклически, поэтому пакеты от данного исходного IP-адреса к данному IP-адресу назначения не всегда проходят через тот же следующий переход. До версии 3.6 кэш маршрутизации исправлял эту ситуацию, поскольку следующий переход, после выбора, оставался в кэше, и все последующие пакеты из того же источника в то же место назначения проходили этот следующий переход. Теперь следующий переход повторно выбирается для каждого пакета, что приводит к странным вещам: с 2 одинаковыми по умолчанию маршрутами в таблице маршрутизации, каждый из которых указывает на одного интернет-провайдера, я даже не могу установить TCP-соединение, потому что начальный SYN и окончательный ACK идти по разным маршрутам,
Есть ли относительно простой способ восстановить нормальное поведение многолучевой маршрутизации, чтобы следующий переход выбирался для каждого потока, а не для каждого пакета? Существуют ли исправления, позволяющие сделать выбор следующего перехода IPv4 на основе хеша, как это делается для IPv6? Или как вы все с этим справляетесь?
ip ro add 8.8.8.8/32 nexthop via 1.2.3.4 nexthop via 1.2.3.5
этого правильного предположения?Ответы:
Если возможно, обновите ядро до Linux> = 4.4 ....
Была введена многопутевая маршрутизация на основе хеша , которая во многих отношениях лучше, чем поведение до 3.6. Он основан на потоке и использует хэш IP-адресов источника и назначения (порты игнорируются), чтобы поддерживать постоянный путь для отдельных соединений. Недостатком является то, что я считаю, что до 3.6 были доступны различные алгоритмы / режимы конфигурации, но теперь вы получаете то, что вам дают !. Вы можете использовать повлиять на выбор пути,
weight
хотя.Если вы находитесь в моей ситуации, то вы действительно хотите,
3.6 >= behaviour < 4.4
но это больше не поддерживается.Если вы обновляете до> = 4.4, это должно сработать без других команд:
Альтернативно по устройству:
источник
«Относительно легко» - сложный термин, но вы можете
В списке рассылки netfilter была дискуссия на эту тему, где я краду списки из:
1. Правила маршрутизации (RPDB и FIB)
2. Правила брандмауэра (использование ipset для включения режима «потока» LB)
Возможно, вы захотите проследить за обсуждением списка рассылки netfilter для некоторых вариантов выше.
источник
u32
получить важные параметры хэшируются , а затем «ярлык» назначен наip rule
«Sipset
- это просто создание наборов, которые заполнены с использованием--add-set
и сопоставлены с использованием--match-set
- но это в основном для соединений в состоянии NEW. Для соединений с УСТАНОВЛЕННЫМ состоянием отметка помечается на пакетах с использованием--restore-mark
параметраCONNMARK
цели - эта директива копирует отметку соединения в пакет. Метки соединения предварительно устанавливаются с использованием--save-mark
вPOSTROUTING
цепи (где пакеты , принадлежащие к новым соединениям будут проходить через). Сценарий кажется мне слишком запутанным, но он передает идею.