Centos 7 vlan настройка

Обновлено: 04.07.2024

На серверах имеющих несколько сетевых интерфейсов каждый отдельно взятый интерфейс можно использовать под какую-то выделенную задачу, например отдельный интерфейс под трафик управления хостом и отдельный интерфейс под трафик периодического резервного копирования. Может возникнуть мысль о том, что такая конфигурация имеет свои плюсы, например, позволяет максимально жёстко разграничить утилизацию интерфейсов под особенности разных задач. Но на этом плюсы, пожалуй, и заканчиваются. Ибо при таком подходе может получиться так, что один интерфейс будет постоянно чем-то чрезмерно нагружен, а другой интерфейс будет периодически полностью простаивать. К тому же, в такой схеме каждый из физических интерфейсов будет выступать как конкретная сущность, при выходе из строя которой будет происходить остановка того или иного сетевого сервиса, жёстко связанного с этой сущностью. 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, значит балансировка исходящего трафика работает успешно.

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

Введение Настройка VLAN как виртуальный интерфейс Настройка VLAN как vlanX Введение Встречаются такие случаи, что операторы связи, к примеру «Билайн», подают городские номера в транке на отдельный интерфейс, так еще и в VLAN. Поэтому в этой статье рассмотрим, как настраивать VLAN на системе Centos 7. В семействе CentOS VLAN настраивается несколькими способами, как саб-интерфейс и […]

Введение

Встречаются такие случаи, что операторы связи, к примеру «Билайн», подают городские номера в транке на отдельный интерфейс, так еще и в VLAN. Поэтому в этой статье рассмотрим, как настраивать VLAN на системе Centos 7. В семействе CentOS VLAN настраивается несколькими способами, как саб-интерфейс и как vlanX.

Далее рассмотрим каждый из способов.

Настройка VLAN как виртуальный интерфейс

В данном примере и в последующих будет использоваться VLAN с номером 17.

Чтобы настроить VLAN, как саб-интерфейс, сперва необходимо подключится к консоли Linux. Для этого используя Putty подключимся на SSH порт к нашей консоли.

Подключение с помощью Putty

Подключившись к консоли, командой touch создадим файл конфигурации нашего виртуального интерфейса.

Проверим, создался файл или нет, для этого введем следующую команду:

Создание виртуального интерфейса

Откроем, созданный файл, любым текстовым редактором: nano, vim, ee, vi и т. д. И добавим туда следующие строки:

gateway указывается только если это у вас будет основной интерфейс, для выхода в сеть/интернет. Иначе его указывать не надо, пропадёт удалённый доступ к консоле из-за конфликта default gateways

А сейчас подробнее опишем каждые параметры:

ONBOOT – указывается значение yes или no. Означает, будет ли запускаться интерфейс при загрузке ОС.
TYPE – обозначение типа сетевого устройства.
VLAN – является ли интерфейс VLAN
DEVICE – имя интерфейса
BOOTPROTO – тип получения ip адреса
IPADDR – сетевой адрес устройства
NETMASK – маска подсети

Конфигурационный файл

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

Настройка VLAN как vlanX

В данном разделе действия аналогичны с предыдущим. Но опишем детально. Сперва создадим конфигурационный файл vlan интерфейса.

Проверим, создался файл или нет, для этого введем следующую команду:

Создание виртуального интерфейса

Откроем, созданный файл, любым текстовым редактором: nano, vim, ee, vi и т. д. И добавим туда следующие строки:

В отличии от прошлого раздела тут есть отличительные особенности

VLAN_NAME_TYPE — тип именования VLAN интерфейса
DEVICE – имя интерфейса
PHYSDEV – физический интерфейс, к которому привязан VLAN
VLAN_ID – номер VLAN

Конфигурация vlanX

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

Спасибо, за комментарий, уже поправили.

Остались вопросы?

Я - Першин Артём, менеджер компании Voxlink. Хотите уточнить детали или готовы оставить заявку? Укажите номер телефона, я перезвоню в течение 3-х секунд.

VoIP оборудование

Fanvil X3S
3 900 руб

Fanvil X3S
2 990 руб

ближайшие курсы

Курсы по Asterisk
последняя неделя
каждого месяца

Записаться

Новые статьи

Отправка уведомлений о звонках в Telegram

Настройка и подключение к Asterisk потока Е1 с использованием шлюза Yeastar TE

Управление внутренними номерами абонентов во FreePBX 14

ближайшие Вебинары

Mikrotik User Meeting: конференция по сетевым технологиям

10 доводов в пользу Asterisk

Распространяется бесплатно.

Asterisk – программное обеспечение с открытым исходным кодом, распространяется по лицензии GPL. Следовательно, установив один раз Asterisk вам не придется дополнительно платить за новых абонентов, подключение новых транков, расширение функционала и прочие лицензии. Это приближает стоимость владения станцией к нулю.

Безопасен в использовании.

Любое программное обеспечение может стать объектом интереса злоумышленников, в том числе телефонная станция. Однако, сам Asterisk, а также операционная система, на которой он работает, дают множество инструментов защиты от любых атак. При грамотной настройке безопасности у злоумышленников нет никаких шансов попасть на станцию.

Надежен в эксплуатации.

Время работы серверов некоторых наших клиентов исчисляется годами. Это значит, что Asterisk работает несколько лет, ему не требуются никакие перезагрузки или принудительные отключения. А еще это говорит о том, что в районе отличная ситуация с электроэнергией, но это уже не заслуга Asterisk.

Гибкий в настройке.

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

Имеет огромный функционал.

Во многом именно Asterisk показал какой должна быть современная телефонная станция. За многие годы развития функциональность Asterisk расширилась, а все основные возможности по-прежнему доступны бесплатно сразу после установки.

Интегрируется с любыми системами.

То, что Asterisk не умеет сам, он позволяет реализовать за счет интеграции. Это могут быть интеграции с коммерческими телефонными станциями, CRM, ERP системами, биллингом, сервисами колл-трекинга, колл-бэка и модулями статистики и аналитики.

Позволяет телефонизировать офис за считанные часы.

В нашей практике были проекты, реализованные за один рабочий день. Это значит, что утром к нам обращался клиент, а уже через несколько часов он пользовался новой IP-АТС. Безусловно, такая скорость редкость, ведь АТС – инструмент зарабатывания денег для многих компаний и спешка во внедрении не уместна. Но в случае острой необходимости Asterisk готов к быстрому старту.

Отличная масштабируемость.

Очень утомительно постоянно возвращаться к одному и тому же вопросу. Такое часто бывает в случае некачественного исполнения работ или выбора заведомо неподходящего бизнес-решения. С Asterisk точно не будет такой проблемы! Телефонная станция, построенная на Asterisk может быть масштабируема до немыслимых размеров. Главное – правильно подобрать оборудование.

Повышает управляемость бизнеса.

Asterisk дает не просто набор полезных функций, он повышает управляемость организации, качества и комфортности управления, а также увеличивает прозрачность бизнеса для руководства. Достичь этого можно, например, за счет автоматизации отчетов, подключения бота в Telegram, санкционированного доступа к станции из любой точки мира.

Снижает расходы на связь.

Связь между внутренними абонентами IP-АТС бесплатна всегда, независимо от их географического расположения. Также к Asterisk можно подключить любых операторов телефонии, в том числе GSM сим-карты и настроить маршрутизацию вызовов по наиболее выгодному тарифу. Всё это позволяет экономить с первых минут пользования станцией.

02.04.2020

CentOS, Linux

комментария 3

В этой статье мы покажем, как настроить тегированный интерфейс VLAN (виртуальной локальной сети) встроенными программными средствами Linux в операционных системах CentOS/Fedora/RedHat. Рассмотим настройку через subinterface, отдельный файл vlanX, а также с помощью инстументов NetworkManager и vconfig.

В операционных системах CentOS/Fedora/RedHat, есть два варианта настройки VLAN:

Использование subinterface (например eth12.7);
Использование отдельного файла vlanXX(vlan7).

VLAN (Virtual Local Area Network) позволяет разделить сеть на канальном уровне на несколько изолированных широковещательных доменов. С помощью VLAN вы можете настроить несколько сетей на одном физическом порту сервера., Маршрутизаторы, коммутаторы и сервера при использовании 802.1Q VLAN могут присваивать сетевым пакетам специальный тег (тегированный трафик) с номером VLAN (VLAN ID: от 0 до 4095).

Сегментирование сети (разделение устройств на изолированные группы);
Уменьшение количества сетевого оборудования;
Снижение нагрузки на сеть для уменьшения широковещательного трафика;
Улучшение безопасности и управляемости сети.

Создаем VLAN через subinterface

Если модуль уже загрузен, появится ошибка: modprobe: ERROR: could not insert '8021q': Module already in kernel .

Проверим, загрузился ли модуль:

Все ок, модуль 8021q имеется.

Так же нужно добавить данный модуль в автозагрузку при рестарте системы:

Создадим VLAN c ID 7 для сетевого интерфейса eth0. Добавляем конфигурационный файл ifcfg-eth0.7 (7 после точки это назначаемый номер VLAN). В этом файле содержится описание подинтерфейса VLAN.

И вписываем следующее содержимое:

Данный файл конфигурации связывает виртуальный интерфейс eth0.7 с физическим интерфейсом eth0. После создания файла конфигурации, нужно перезапустить сервис network:

Проверим сетевые настройки:

Как видим, сабинтерфейс с нужным нам VLAN7 добавлен.

Статистику интерфейса можно получить так (с помощью счетчиков пакетов можно убедиться, что VLAN интерфейс получает маркированный трафик) :

Чтобы выполнить ping с определенного интерфейса VLAN, используйте формат команды:

Настройка VLAN через отдельный файл vlanXX

Теперь попробуем создать VLAN с ID 8 через отдельный файл конфигурации:

Добавим в него следующие строки:

Обратите внимание, что файл конфигурации немного отличается от предыдущего. В данной настройке, нужно указывать строку «PHYSDEV», которая направляет конфигурационный файл на физический сетевой интерфейс.

После всех настроек, так же требуется перезагрузка сервиса network:

Если при перезапуске службы сетти вы получаете ошибку No suitable device found for this connection, проверьте что в конфигурационном файле ifcfg-vlan8 указано значение для опции VLAN_ID.

Нужный сетевой интерфейс с VLAN8 так же доступен.

Используем NetworkManager для настройки VLAN интерфейса

Начиная с 8 версии CentOS/RedHat по умолчанию сетью на сервере управляет NetworkManager. Ранее это инструмент так же был доступен, но большинство аминистраторов использовали привычный network.

Рассмотрим вариант настройки VLAN через NM. Создадим виртуальный интерфейс ens3.7 для VLAN 7 на физическом интерфейсе ens3 и зададим IP:

Чтобы проверить сетевые интерфейсы на сервере, используйте команду:

После настройки, выполните перезагрузку NetworkManager:

После перезапуска сервиса NM, интерфейс не пропал.

Вывести текущие настройки созданного VLAN интерфейса можно так:

Настройка временного VLAN с помощью утилиты vconfig

Создадим интерфейс с VLAN9:

Временный интерфейс c VLAN был создан.

P.S. На момент написания статьи, утилита vconfig была недоступна для дистрибутивов CentOS 8 и RedHat 8.

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

Настройка VLAN на CentOS

VLAN настроим на CentOS, на интерфейсе enp2s0. На моем хосте он предназначен для виртуальных машин. На нем создадим 15-й vlan (пропускает tagged-трафик "внутрь", исходящий трафик тегирует). Трафик виртуалок будет тегироваться 15-м vlan.

Сначала проверим, что на хосте загружен модуль ядра 8021q:

Если ничего нет, то подгружаем модуль:

В CentOS настройки сетевых интерфейсов находятся в файлах /etc/sysconfig/network-scripts/ifcfg-*

Изначально настройки сетевого интерфейса enp2s0 могли выглядеть так (файл /etc/sysconfig/network-scripts/ifcfg-enp2s0):

TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.88.150
NETMASK=255.255.255.0
GATEWAY=192.168.88.1
DNS1=192.168.88.1
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=enp2s0
UUID=0c47fee5-889c-4974-8704-fe597e7937df
DEVICE=enp2s0

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

enp2s0 -> VLAN 15 -> br15

Т.е. на базе сетевого интерфейса enp2s0 создается VLAN 15 (по сути, это отдельная сеть) и к этому VLAN-у доступ осуществляется через bridge br15 (название br15 взято просто для удобства). Виртуальные машины будут подключаться к бриджу br15, а не к конкретному физическому интерфейсу. Это может быть удобным в дальнейшем при изменении ролей интерфейсов, к примеру.

1. Оставим в описании файла интерфейса enp2s0 минимум сведений (по сути, только описание физического интерфейса):

TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
NAME=enp2s0
UUID=0c47fee5-889c-4974-8704-fe597e7937df
DEVICE=enp2s0

2. Создаем VLAN 15 (запись стандартная для Linux: имя_интерфейса.номер_vlan)

VLAN="yes"
VLAN_NAME_TYPE="VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD"
DEVICE="enp2s0.15"
PHYSDEV=enp2s0
BOOTPROTO="none"
ONBOOT="yes"
TYPE="Vlan"
BRIDGE=br15

3. Создаем новый bridge15, рассчитанный для нашей задачи (цель - подключение виртуальной машины к VLAN 15). Задаем бриджу IP-адрес и прочие настройки:

DEVICE=br15
TYPE=Bridge
BOOTPROTO=static
ONBOOT=yes
DELAY=0
DEFROUTE=no
IPV4_FAILURE_FATAL=no
IPV6INIT=no

где VLAN_NAME_TYPE задает формат названия сетевого интерфейса для VLAN: имя_интерфейса.номер_vlan

4. Хост надо перезагрузить, просто рестарта сетевых настроек ( systemctl restart NetworkManager.service ) недостаточно.

5. После перезагрузки хоста правим виртуальную машину - теперь она будет подключаться к сети VLAN 15:

(надо выключить виртуальную машину, иначе не применятся настройки сети)

Находим там секцию, похожую на:

Строку с mac-адресом удаляем, br1 меняем на br15. Сохраняем, запускаем виртуальную машину. По идее, если с транком все в порядке, виртуалка vm1 подключена через br15 к VLAN 15.

Аналогично можно понасоздавать vlan-ов сколько душе угодно. И на том же сетевом интерфейсе можно оставить и нетегированный трафик. Это как удобно.

Читайте также: