На случай, если ваша система будет себя вести иначе, чем Red Hat v.7.3 и ему подобные, например, откажется понимать параметр SLAVE и не «привяжет» интерфейсы eth0 и eth1 в качестве подчинённых к bond0, это можно сделать руками с помощью следующих команд:

# /sbin/ifconfig bond0 192.168.0.1 netmask 255.255.255.0 broadcast 192.18.0.255 up

# /sbin/ifenslave bond0 eth0

# /sbin/ifenslave bond0 eth1

В случае возникновения проблем с настройкой нестандартных конфигураций рекомендую обратиться к первоисточнику [2].

Теория. О режимах работы

Смысл организации объединённых каналов обычно очень прост: либо нужно повышение пропускной способности, либо увеличение надёжности, либо и то, и другое вместе. Несмотря на то, что идеология построения объединённых каналов относительно прозрачна, существует несколько различных режимов совместной работы.

n  Round robin, rr, 0. Круговой, основанный на последовательном использовании подчинённых интерфейсов для передачи через них пакетов в том порядке, как они были подключены. В этом режиме интерфейсы наиболее равномерно загружены.

n  XOR, 2. Режим, в котором подчинённый интерфейс для передачи конкретного пакета выбирается по формуле «(src hw addr XOR dst hw addr) % slave», где «src hw addr» и «dst hw addr» есть MAC-адреса отправителя и получателя, приведённые к целочисленному виду, а slave – число работающих подчинённых интерфейсов. Определение интерфейса для отправки пакетов напрямую зависит от адреса получателя. При такой схеме выбора происходит примерно равномерное распределение оппонентов информационного обмена по интерфейсам с их «виртуальной» взаимной привязкой друг к другу.

n  Active-backup, 1. Режим горячей замены. В каждый момент времени работает только один интерфейс. Если рабочий канал выходит из строя, то начинает использоваться какой-либо один резервный интерфейс (из соподчинённых главному) взамен «отказавшего». Данный режим используется в основном в системах повышенной надёжности.

Диагностика: «жив ли link?»

Когда все связи активны и система работает, как это от неё ожидается, может сложиться впечатление, что диагностика не нужна. Однако не используя её постоянно в рабочем режиме, сложно поймать тот момент, когда что-то перестало работать. Соответственно, можно пропустить мгновение, когда нужно начать более активно использовать другие соподчинённые интерфейсы, полностью отказавшись от сломанного. Если этого не сделать вовремя, то будет большой процент потерь пакетов, далее увеличение числа повторных передач и как следствие падение пропускной способности ниже, чем если бы работал только один интерфейс без настройки всяких linux bonding.

Существует два способа диагностирования (мониторинга) связанности:

n  с помощью статуса Media Independent Interface (MII);

n  c помощью ARP-запросов и ответов.

Несмотря на то что теоретически эти способы можно использовать вместе, на практике они не совмещаются. Видимо, разработчики этой части ядра сочли такую функциональность излишней. Расмотрим эти способы подробнее.

В первом случае небольшая схема на сетевой плате или часть основной микросхемы отслеживают состояние подключенности и режима работы сети. Какая скорость – 10 или 100 Мбит/c? Полный ли дуплекс? Есть ли связь вообще или нет? Эти данные с сетевой платы можно снимать и использовать в благих целях. Для применения этого режима диагностики ваша карта должна поддерживать функцию мониторинга MII-статуса, и эта функция должна быть включена. Часть ядра, отвечающая за bonding, исходя из этой информации, может принимать решение о целесообразности использования того или иного сетевого интерфейса для передачи данных. Дополнительно можно настроить периодичность, с которой осуществляется проверка. Рекомендуется использовать значение в 100 мс. Сильно уменьшать время не следует, так как это будет в значительной мере загружать систему. Увеличивать тоже особого смысла нет – может привести к росту числа повторных передач пакетов.