Второй способ более медленный, зато более надёжный и может работать с древними сетевыми картами, не поддерживающими мониторинг на основе MII-статуса.

Для этого способа используется какой-либо отдельный IP-адрес рабочего компьютера или адрес шлюза, которые всегда должны быть в сети в рабочем состоянии. Периодически на этот адрес посылаются ARP-запросы, на которые согласно требованиям, предъявляемым к хостам [5], должны отсылаться ARP-ответы. Если вдруг запросы перестали уходить или перестали приходить ответы – значит пропала связанность и канал следует исключить из использования во избежание потери пакетов. Простой пример конфигурации сети, где этот метод сработает лучше, чем мониторинг MII-статуса, представлен на рисунке 5. Например, во время переезда внутри здания некоторое устройство, ранее сообщавшееся с сервером Linux напрямую двумя каналами Ethernet, оказалось сильно отнесено (более чем на 180 метров). Благодаря особенностям организации сети, Ethernet стало невозможным использование столь длинного сегмента без ретрансляторов, в результате чего было принято решение о применении двух коммутаторов посередине с целью обеспечения связи устройства с сервером. Сервер как работал в режиме объединения каналов с диагностикой в виде мониторинга MII-статуса, так и продолжает работать. Теперь, если произойдёт сбой на участке, отмеченном красным крестиком (между коммутатором 1 и устройством) (см. рис. 5), сервер об этом не узнает. Так как связь на участке «eth0 – коммутатор 1» есть, сервер будет продолжать посылать по данному каналу пакеты, которые будут успешно теряться на коммутаторе.

Если в данной схеме использовать мониторинг по ARP-запросам и ответам, то, не получив ответа от устройства, сервер поймёт, что связность в этом направлении нарушена и откажется от использования испорченного канала.

Рисунок 5. Пример, где мониторинг MII статуса неприменим

Параметры, передаваемые модулю

Чуть выше без пояснений были выбраны следующие параметры: miimon=100 mode=0 downdelay=2000 updelay=5000. Давайте рассмотрим более подробно эти и другие параметры, с помощью которых можно менять режим работы.

mode

Параметр, выбирающий режим работы, возможные значения: 0,1,2 для Round robin, XOR, active backup соответственно.

miimon

Число мс (тип integer) – как часто производится мониторинг MII статуса. 0 – мониторинг отключен. Рекомендуемое значение 100 мс.

downdelay

Задержка в мс (тип integer) с того момента, как было обнаружено, что связь пропала, до того, как данный канал перестанет использоваться. Задержка нужна, чтобы отфильтровывать кратковременные сбои. Например, после переключения патчкорда в течение нескольких секунд совсем не обязательно терять связь на минуту или больше. По умолчанию используется 0 – нет задержки.

updelay

То же самое, что и downdelay, но определяющее задержку по включению, на тот случай, если какой-нибудь switch или hub «не до конца включились». Напряжение на порт подано, а пакеты ещё корректно не принимаются. Если в этот момент передать данные – они потеряются, а если немного подождать, то этого не случится.

arp_interval

С какой периодичностью в мс (тип integer) осуществлять ARP-мониторинг. Значение 0 означает что ARP-мониторинг выключен.

arp_ip_target

IP-адрес, по которому осуществлять ARP-мониторинг (в случае если arp_interval>0). Если с данного адреса нет ARP-ответов, то значит канал, по которому посылались запросы, не работает.

Linux bonding на практике