Столкнулся с необходимостью выполнить агрегацию портов на убунте, для увеличения общей пропускной способности сети.

Связать необходимо свитч EdgeCore 4626 и линуксовый сервак, на котором работает pppoed для терминации клиентов. Решили связать 2 гигабитных езернета в агрегациию, для получения 2 гигабит суммарной пропускной способности. Для сервака приобрели карточку Intel на 4 головы с чипом 82576. 2 головы включались в один свитч EdgeCore и смотрели в интернет, а вторые 2 в другой свитч EdgeCore и смотрели в сторону локальной сети. Сервер функционирует под управление Ubuntu 10.04 LTS.

В качестве типа бондинга был выбран тип 0 - round robin балансировка, т.е. пакеты будут отправляться по очереди в различные интерфейсы с сервера в сторону свитча.

Здесь стоит уточнить о выборе типа бондинга. Указания типа бондинга определяет то, как с стороны сервера в сторону свитча будут отправляться пакеты, т.е. управление исходящим трафиком. Для управления входящим необходимо настраивать политики агрегирования на свитче.

На свитче же, в моем случае, я выбрал режим агрегирования On, в этом режиме есть различные способы балансировки нагрузки между интерфейсами свитча добавленных в агрегирование. Здесь тоже указывается политика обработки исходящего, по отношению к свитчу трафика - входящий на сервер.

Можно выбрать один из 6-ти способов балансировки:

  dst-ip       Destination ip address
  dst-mac      Destination MAC address
  dst-src-ip   Destination and source ip address
  dst-src-mac  Destination and source MAC address
  src-ip       Source ip address
  src-mac      Source MAC address
 

к первому свитчу подключаются внешний канал сервера - интернет. На этих интерфейсах сервера будет только один мак адрес - мак адрес моего маршрутизатора, в качестве dst-mac будет один мак адрес - адрес сервера, и, в большинстве случая dst-ip - ip адрес моего сервера. Поэтому здесь я выбрал метод балансировки src-ip. src-ip - это ip адрес тех ресурсов, которые запрашивают мои пользователи и они как раз и являются единственным постоянно меняющейся переменной.

 

Настройка bonding на свитчах

Настройки бондинга на первом свитче:

conf
port-group 1
int e1/1-2
port-group 1 mode on
exit
int Port-Channel 1
description agregation-to-inet
load-balance src-ip

На втором свитче все по другому. К нему подключаются локальные интерфейсы сервера. Трафик в основном исходящий от сервера к клиентам. Так как у меня используется pppoe соединение, то метод балансировки по ip отпал сразу. Из-за того, что src-mac на портах свитча будет один - мак сервера, то и балансировку выбрал на свитче dst-mac - это мак адрес клиентов, подключенных к серверу по pppoe.

Настройки бондинга на втором свитче:

conf
port-group 1
int e1/1-2
port-group 1 mode on
exit
int Port-Channel 1
description agregation-to-local
load-balance dst-mac

С свитчами пока все, их можно оставить в покое и перейти к серверу.

 

Настройка bonding на linux сервере

При настройке сервера возникли проблемы. Если все оставить по умолчанию, то тогда при поднятии pppoe туннеля неправильно работал шейпер - клиент получал только 10к скорости вместо 10М. Начал копать что не так.  Обнаружилось, что без использования туннеля все ок и все прекрасно работает, проблема возникала только при работе в туннеле.

В итоге обнаружил, что карточка использует драйвер igb, который на моем ядре 2.6.32-26-generic-pae неправильно работала с туннелями. Порылся по форумам и нашел решение дял моей проблемы - отключение некоторых режимов у сетевой карты:

ethtool -K eth1 tso off tx off sg off gro off

После этого все начало работать так как нужно.

 

Ниже привожу рабочий конфиг сервера, с использованием бондинга 2-го типа (проверял также тип 5, все работает, так что можно смело юзать).

Первым делом включаем бондинг в ядре. Добавлем в файл /etc/modules следующие строки:

bonding mode=0 miimon=100 max_bonds=2

max_bonds определяет сколько виртуальных bond интерфейсов необходимо создать, в моем случае - 2. Один для интернета, второй для локальной сети.

Далее правим файл /etc/network/interfaces

auto bond0
iface bond0 inet static
hwaddress ether 00:00:90:05:51:b0
address xxx.xxx.xxx.xxx
netmask xxx.xxx.xxx.xxx
network xxx.xxx.xxx.xxx
broadcast xxx.xxx.xxx.xxx
gateway xxx.xxx.xxx.xxx
ns-nameservers xxx.xxx.xxx.xxx
post-up ifenslave bond0 eth1 eth3
pre-down ifenslave -d bond0 eth1 eth3

auto bond1
iface bond1 inet static
hwaddress ether 00:00:90:05:51:00
address 10.7.7.1
netmask 255.255.255.0
network 10.7.7.0
post-up ifenslave bond1 eth4 eth5
pre-down ifenslave -d bond1 eth4 eth5

auto vlan3
iface vlan3 inet static
vlan-raw-device bond1
address 0.0.0.0
netmask 255.255.255.255

auto vlan4
iface vlan4 inet static
vlan-raw-device bond1
address 0.0.0.0
netmask 255.255.255.255

В моем случае поднимается 2 вируальных интерфейса bond0 и bond1. Bond0 - смотрит наружу и имеет реальный адрес, а bond1 в внутреннюю сеть. На bond1 поднимаются сабинтерфейсы vlan. Здесь необходимо обратить внимание на то, что для bond интерфейсов необходимо поменять мак адреса, так если этого не сделать, то бонд интерфейс будет использовать мак адрес одного из реальных eth интерфейсов.

Команда ifenslave указывает какие интерфейсы следует связывать.

Хоть bond1 и смотрит внутрь сети и служит для поднятия сабинтерфейсов vlan, я на него повесил серый адрес, так как без него были проблемы с поднятием сабинтерфейса.

Необходимые изменения в сетевых интерфейсах я добавил в файл /etc/rc.local, который обрабатывается последним при старте системы. Вот директивы, которые я в него добавил:

ethtool -K bond1 gro off
ethtool -K bond0 gro off
ethtool -K eth4 gro off
ethtool -K eth5 gro off
ethtool -K eth1 gro off
ethtool -K eth3 gro off
ethtool -K eth4 tso off tx off sg off
ethtool -K eth5 tso off tx off sg off
ethtool -K eth1 tso off tx off sg off
ethtool -K eth3 tso off tx off sg off

 

Эти директивы позволяют добиться правильности работы шейпера при pppoe туннеле и бондинге. Без этого шейпер просто "сходил с ума" и неправильно резал скорость для клиентов. Правка параметров работы интерфейсов через ethtool понадобилась мне на карточках интел, возможно, на других картах этого делать не нужно.

Далее просто перегружаем машину и проверяем что все ок.

 

Разные типы бондинга на интерфейсах одного сервера

Позже возникла необходимость использовать разные типы бондинга на интерфейсах сервера. Дело в том, что у меня один бондинг смотрит в мир, а другой в локалку и для балансировки траффика необходимо использовать разный тип агрегирования. Имейте ввиду, что с сервера, можно влиять только на исходящий траффик от сервера к свитчу. Если нужно влиянть на балансировку входящего траффика на сервер, то настраивается режим балансировки для исходящего траффика с свитча в сторону сервера на самом свитче. Балансировка при бондинге производится только на исходящий траффик. Вы можете выбрать тип бондинга On и настраивать на одной стороне балансировку на основании src-ip а на другой стороне src-mac, таким образом у вас будет баланситься и входящий и исходящий траффик, как вам нужно. При этом файл interfaces принял такой вид:

auto bond0
iface bond0 inet static
hwaddress ether 00:00:90:05:51:b0
address xxx.xxx.xxx.xxx
netmask xxx.xxx.xxx.xxx
network xxx.xxx.xxx.xxx
broadcast xxx.xxx.xxx.xxx
gateway xxx.xxx.xxx.xxx
ns-nameservers xxx.xxx.xxx.xxx

slaves eth1 eth3
bond-mode 0
bond-miimon 100

 

auto bond1
iface bond1 inet static
hwaddress ether 00:00:90:05:51:00
address 10.7.7.1
netmask 255.255.255.0
network 10.7.7.0
slaves eth4 eth5
bond-mode 2
bond-miimon 100

 

auto vlan3
iface vlan3 inet static
vlan-raw-device bond1
address 0.0.0.0
netmask 255.255.255.255

auto vlan4
iface vlan4 inet static
vlan-raw-device bond1
address 0.0.0.0
netmask 255.255.255.255

 

Вместо post-up ifenslave и pre-down ifenslave теперь используется директива slaves, с помощью которой задаются интерфейсы, которые будут связываться. bond-mode и bond-miimon  определяют тип и параметры самого бондинга.

Надеюсь, кому-то этот материал поможет поднять агрегирование и у себя на сервере.

В качестве базового материала брал ман вот здесь