Linux vlan on bond

Вики IT-KB

Пошаговые руководства, шпаргалки, полезные ссылки.

Инструменты пользователя

Инструменты сайта

Боковая панель

Как создать Bond c поддержкой VLAN в Debian GNU/Linux 9 (Stretch)

На данной странице мы рассмотрим простой пример объединения нескольких физических сетевых интерфейсов в виртуальный LACP Bond-интерфейс с поддержкой VLAN в Debian GNU/Linux 9 (Stretch). В нашем примере рассмотрено создание Bond-интерфейса на сервере HP ProLiant DL380 G5 (сервер имеет два интегрированных сетевых адаптера 1Gbps, для работы которых в Debian требуется non-free firmware bnx2) c дополнительно установленным двух-портовым сетевым адаптером HP NC360T PCI Express Dual Port Gigabit Server Adapter. Таким образом, в общей сложности мы будем объединять в Bond четыре сетевых интерфейса.

Устанавливаем пакеты, которые потребуются для работы bond-интерфейса.

Пример уже настроенного конфигурационного файла /etc/network/interfaces :

После настройки сетевой конфигурации перезапускаем службу поддержки сети (либо можно перезагрузить сервер, если тому нет противопоказаний):

Проверяем статус Bond-интерфейса:

Дополнительные источники информации:

Проверено на следующих конфигурациях:

Версия ОС
Debian GNU/Linux Stretch 9.2.1

Автор первичной редакции:
Алексей Максимов
Время публикации: 12.04.2018 09:49

Источник

Вики IT-KB

Пошаговые руководства, шпаргалки, полезные ссылки.

Инструменты пользователя

Инструменты сайта

Боковая панель

Как создать Bond c поддержкой VLAN в Debian GNU/Linux 10 (Buster)

На данной странице мы рассмотрим простой пример объединения нескольких физических сетевых интерфейсов в виртуальный LACP Bond-интерфейс с поддержкой VLAN в Debian GNU/Linux 10 (Buster). В нашем примере рассмотрено создание Bond-интерфейса на сервере HP ProLiant DL380 G6. Этот сервер имеет четыре интегрированных сетевых адаптера 1Gbps, для работы которых в Debian требуется non-free firmware bnx2. Таким образом, в общей сложности мы будем объединять в Bond четыре сетевых интерфейса.

Устанавливаем пакеты, которые потребуются для работы bond-интерфейса.

Пример уже настроенного конфигурационного файла /etc/network/interfaces :

После настройки сетевой конфигурации перезапускаем службу поддержки сети (либо можно перезагрузить сервер, если тому нет противопоказаний):

Проверяем статус Bond-интерфейса:

Дополнительные источники информации:

Проверено на следующих конфигурациях:

Версия ОС
Debian GNU/Linux Buster 10.0

Автор первичной редакции:
Алексей Максимов
Время публикации: 18.06.2019 11:28

Источник

Настройка Network Bonding с LACP между CentOS Linux 7.2 и коммутатором Cisco 3560G

На серверах имеющих несколько сетевых интерфейсов каждый отдельно взятый интерфейс можно использовать под какую-то выделенную задачу, например отдельный интерфейс под трафик управления хостом и отдельный интерфейс под трафик периодического резервного копирования. Может возникнуть мысль о том, что такая конфигурация имеет свои плюсы, например, позволяет максимально жёстко разграничить утилизацию интерфейсов под особенности разных задач. Но на этом плюсы, пожалуй, и заканчиваются. Ибо при таком подходе может получиться так, что один интерфейс будет постоянно чем-то чрезмерно нагружен, а другой интерфейс будет периодически полностью простаивать. К тому же, в такой схеме каждый из физических интерфейсов будет выступать как конкретная сущность, при выходе из строя которой будет происходить остановка того или иного сетевого сервиса, жёстко связанного с этой сущностью. C точки зрения повышения доступности и балансировки нагрузки, более эффективными методом использования нескольких сетевых интерфейсов сервера является объединение этих интерфейсов в логические сущности с использованием технологий Network Bonding и Network Teaming.

В этой заметке на конкретном примере мы рассмотрим то, как с помощью технологии Network Bonding в ОС CentOS Linux 7.2 можно организовать объединение физических сетевых интерфейсов сервера в логический сетевой интерфейс (bond), а уже поверх него создать виртуальные сетевые интерфейсы под разные задачи и сетевые службы с изоляцией по разным VLAN. Агрегирование каналов между коммутатором и сервером будет выполняться с помощью протокола Link Aggregation Control Protocol (LACP) регламентированного документом IEEE 802.3ad. Использование LACP, с одной стороны, обеспечит высокую доступность агрегированного канала, так как выход из строя любого из линков между сервером и коммутатором не приведёт к потери доступности сетевых сервисов сервера, и с другой стороны, обеспечит равномерную балансировку нагрузки между физическими сетевыми интерфейсами сервера. Настройка в нашем примере будет выполняться как на стороне коммутатора (на примере коммутатора Cisco Catalyst WS-C3560G), так и на стороне Linux-сервера с двумя сетевыми интерфейсами (на примере сервера HP ProLiant DL360 G5 с контроллерами Broadcom NetXtreme II BCM5708/HP NC373i)

Настройка конфигурации LACP на коммутаторе Cisco

Активация механизмов LACP на коммутаторе Cisco сводится к созданию виртуальной группы портов channel-group и включению в эту группу нужных нам портов коммутатора.

Очищаем существующую конфигурацию портов коммутатора, которые будем включать в channel-group (в нашем примере это будут порты 21 и 22 ):

Создаём channel-group и включаем в неё нужные нам порты коммутатора, предварительно эти отключив порты:

Вносим изменения в свойства появившегося виртуального интерфейса Port-channel2:

Изменения в свойствах первого порта-участника channel-group вносим минимальные, так как основные параметры наследуются портом с виртуального интерфейса channel-group:

Вносим изменения в свойства второго порта-участника channel-group:

Не забываем сохранить изменения:

Проверяем итоговую конфигурацию портов:

Проверяем статус подключения портов:

До тех пор, пока на стороне нашего Linux-сервера не будет настроен LACP, статус портов будет отображаться как suspended/notconnect, а после настройки статус должен будет измениться на connected (это можно будет проверить позже):

Проверяем внутренний статус LACP:

Здесь аналогично, до тех пор, пока на стороне нашего Linux-сервера не будет настроен LACP, статус LACP будет соответствующий, а после настройки статус должен будет измениться:

Теперь можем перейти к настройке Network Bonding с LACP на стороне Linux-сервера.

Настройка Network Bonding c LACP в CentOS Linux 7.2

Проверим наличие модуля поддержки bonding (команда должна отработать без ошибок):

В ниже представленном примере мы рассмотрим сценарий настройки логического bond-интерфейса bond0 (master-интерфейс), членами которого будут два имеющихся в сервере физических интерфейса enp3s0 и enps5s0 (slave-интерфейсы). А затем на созданном bond-интерфейсе мы создадим дочерний VLAN-интерфейс, имеющий доступ к изолированной тегированной сети с определённым номером VLAN. Всю настройку мы будем выполнять путём прямой правки файлов интерфейсов.

Создадим файл с конфигурацией нового агрегирующего интерфейса bond0 :

Наполним файл параметрами бонда bond0 :

Опции BONDING_OPTS можно передавать и через файл /etc/modprobe.d/bonding.conf , но вместо этого лучше использовать файлы ifcfg-bond*. Исключением здесь является лишь глобальный параметр max_bonds. Это замечание описано в документе Create a Channel Bonding Interface .

Получить информацию о всех возможных опциях BONDING_OPTS и вариантах их значений можно в документе Using Channel Bonding .

В нашем примере используется несколько опций:

• mode= 802.3ad , который определяет режим работы bond-а (bonding policy). В нашем случае выбран режим с использованием протокола LACP. Этот режим для корректной работы должен поддерживаться и коммутатором, к которому подключаются сетевые интерфейсы bond-а.
• lacp_rate= fast , который заставляет bonding-интерфейс отсылать пакеты LACPDU ежесекундно, в то время как значение по умолчанию slow , которое определяет 30-секундный интервал.
• xmit_hash_policy= layer2+3 , который определяет режим вычисления хешей при организации балансировки нагрузки между интерфейсами бонда. Эта опция используется только для режимов работы бонда (ранее описанный mode) поддерживающих балансировку нагрузки, таких как balance-xor и 802.3ad . Значение layer2+3 говорит о том, что для вычисления хешей будут использоваться как MAC адреса получателей/отправителей пакета, так и их IP адреса, если это возможно. Значение по умолчанию для этой опции – layer2 , что определяет вычисление хеша только по MAC-адресам.
• miimon= 100 , который определяет количество миллисекунд для мониторинга состояния линка с помощью механизмов MII, который, к слову говоря, должен поддерживаться физическим сетевым контроллером. Значение опции miimon по умолчанию – 0, что значит, что данный функционал не используется.

Чтобы проверить то, может ли наш сетевой контроллер работать с MII, можно выполнить:

Значение yes в данном случае говорит о поддержке MII.

Если вы используете режим active-backup bonding, то есть рекомендация настраивать дополнительную опцию bond-интерфейса: fail_over_mac= 1 . Как я понял, это нужно для того, чтобы использовать для bond в качестве основного MAC-адреса, MAC-адрес backup-интерфейса, что позволит сократить время потери соединений в процессе fail-over.

Создадим файл с конфигурацией slave-интерфейсов, то есть физических Ethernet-портов, которые будут участниками bond0 (файл скорее всего уже существует, так что просто отредактируем его под свою задачу):

Второй slave-интерфейс настраиваем по аналогии:

Параметры файла аналогичные за исключением параметров DEVICE и NAME

Если используется служба NetworkManager, то перезагрузим её конфигурацию с учётном созданных/изменённых файлов ifcfg-* :

Перезапускаем slave-интерфейсы:

Если отдельное отключение/включение интерфейсов приводит к ошибкам (это возможно в случае если ранее подключения контролировались службой NetworkManager), то перезапускаем сеть полностью:

Убедимся в том, что созданные интерфейсы успешно запущены со статусом UP и заданными нами настройками, например обратим внимание на размер MTU.

Итак, bond создан и запущен в работу, и теперь переходим к созданию виртуальных интерфейсов с поддержкой VLAN поверх нашего bond-а.

Проверим наличие модуля поддержки VLAN (команда должна отработать без ошибок)

Под каждый отдельный VLAN-интерфейс создаём конфигурационные файлы в каталоге /etc/sysconfig/network-scripts по типу ifcfg-bond номер бонда > . номер VLAN-а > . Например создадим конфигурационный файл для bond-интерфейса bond0 с VLAN 2

Попробуем поднять созданный VLAN-интерфейс или опять-же просто перезапускаем сеть:

Чтобы разнообразные сетевые службы, используемые на нашем сервере приняли во внимание изменение сетевой конфигурации, можно перезапустить их, либо просто перезагрузить сервер.

Убедимся в том, что VLAN-интерфейс поднялся с указанными нами настройками:

Аналогичным образом мы можем создать на сервере столько выделенных виртуальных VLAN интерфейсов, сколько потребуется для разделения трафика между разными задачами и сетевыми службами исполняемыми на сервере.

Проверяем статус работы bond0 :

Если в секции 802.3ad info значение параметра Partner Mac Address не содержит MAC-адреса коммутатора, а вместо этого видно значение 00:00:00:00:00:00, это значит то, что обмен пакетами LACPDU с коммутатором по какой-то причине не выполняется (либо на стороне коммутатора неправильно настроен LACP, либо коммутатор вовсе его не поддерживает)

На этом этапе агрегированный LACP линк между коммутатором и сервером можно считать настроенным. На стороне коммутатора убедимся в том, что вывод ранее упомянутых команд изменился:

Теперь можно переходить к заключительному этапу – проверкам нашего LACP соединения на предмет устойчивости соединения при отказе любого из портов на стороне коммутатора/сервера а также на предмет корректности балансировки нагрузки.

Проверка высокой доступности соединения

Теперь попробуем проверить устойчивость нашего LACP-соединения. Для этого запустим с любой сторонней системы, например с рабочей станции администратора, ping IP-адреса bond-интерфейса сервера

Подключимся к коммутатору Cisco и выполним отключение одного из портов, входящих в группу channel-group, обеспечивающей со стороны коммутатора LACP-соединение.

Убедимся в том, что запущенная утилита ping не отражает факт потери пакетов. Если всё в порядке, включим отключенный порт коммутатора, а затем отключим второй порт входящий в группу channel-group:

Снова проверим, что ping не имеет потерь пакетов. Если всё в порядке, включим отключенный порт коммутатора и будем считать, что наше LACP-соединение Cisco channel-group Linux bond успешно отрабатывает ситуацию потери соединения на любом из интерфейсов коммутатора, входящих в channel-group. Аналогичную проверку можно выполнить и со стороны Linux сервера попеременно отключая интерфейсы входящие в bond:

Здесь между включением первого интерфейса и отключением второго для чистоты эксперимента нужно сделать небольшую паузу (5-7 секунд), чтобы LACP-линк смог полностью перестроиться для того, чтобы не было потерь пакетов. Если же эту паузу не сделать, то несколько пакетов может таки потеряться, но потом соединение всё-же будет автоматически восстановлено.

Проверка балансировки нагрузки соединения

Чтобы проверить факт того, что трафик действительно распределяется по интерфейсам bond-а, воспользуемся немного более сложной процедурой тестирования, для которой используем три компьютера, то есть сам наш сервер KOM-AD01-VM32 (IP: 10.1.0.32 ) и любые два Linux-компьютера, например KOM-AD01-SRV01 (IP: 10.1.0.11 ) и KOM-AD01-SRV02 (IP: 10.1.0.12 ). Установим на все три компьютера две утилиты — iperf (для тестирования скорости) и nload (для отображения нагрузки интерфейсов в реальном времени).

Начнем с проверки входящего трафика.

Установим на проверяемом сервере KOM-AD01-VM32 утилиты iperf и nload а затем на время теста выключим брандмауэр (либо можете создать разрешающее правило для порта, который будет слушать запущенный серверный iperf, по умолчанию это TCP 5001). Запустим утилиту iperf в режиме сервера (с ключом -s), то есть ориентированную на приём трафика:

Здесь же, но в отдельной консоли, запустим утилиту nload, которая в реальном времени будет показывать нам статистические значения нагрузки на интерфейсы. В качестве параметров укажем названия интерфейсов, за нагрузкой которых нужно следить:

Затем выполняем отсылку трафика с помощью iperf (в режиме клиента) с компьютеров KOM-AD01-SRV01 и KOM-AD01-SRV02 (запустим одинаковую команду одновременно на обоих этих компьютерах):

В качестве параметров iperf укажем следующие значения:

• -c – работа в режиме клиента (отсылка трафика)
• 10.1.0.32 — IP адрес сервера, на который клиент iperf будет посылать трафик ( KOM-AD01-VM32 )
• -t 600 – время, в течение которого будет выполняться отсылка трафика (600 секунд)
• -i 2 — интервал в секундах для вывода статистической информации об отсылке трафика на экран (каждые 2 секунды)
• -b 100m – размер пропускной способности сети, которую будет пытаться задействовать iperf при отсылке трафика (в нашем случае 100 мегабит/с)

После того, как iperf в режиме клиента начнёт работу на обоих серверах, переходим на проверяемый сервер KOM-AD01-VM32 и наблюдаем за статистикой nload. На начальном экране увидим статистику по входящему и исходящему трафику по первому интерфейсу ( enp3s0 ). Обращаем внимание на значения по входящему трафику:

Чтобы увидеть статистику по следующему интерфейсу ( enp5s0 ) просто нажмём Enter:

Как видим, скорость на обоих интерфейсах распределена равномерно и равна примерно 100 мегабит/с, значит балансировка входящего трафика работает успешно.

Далее, по аналогичной методике, протестируем механизм балансировки нагрузки для трафика исходящего с нашего подопытного сервера KOM-AD01-VM32 . Для этого iperf будет запускаться на компьютерах KOM-AD01-SRV01 / KOM-AD01-SRV02 в режиме сервера, принимающего трафик. Запустим одинаковую команду на обоих этих компьютерах, не забывая при этом про необходимость открытия порта для сервера iperf:

А на компьютере KOM-AD01-VM32 утилиту iperf запускаем в режиме клиента, отправляющего трафик на компьютеры KOM-AD01-SRV01 / KOM-AD01-SRV02 , используя при этом запуск из двух разных консолей:

Запускаем на компьютере KOM-AD01-VM32 третью консоль и наблюдаем за ситуацией в nload

На этот раз обращаем внимание на исходящий трафик на первом интерфейсе…

…и исходящий трафик на втором интерфейсе…

Как видим, трафик распределён по разным интерфейсам нашего bond-a, значит балансировка исходящего трафика работает успешно.

Если ранее на время теста отключался брандмауэр, то по окончанию теста не забываем включить его обратно:

Дополнительные источники информации:

Источник