- Объединение сетевых интерфейсов в Linux. Настройка bonding
- Агрегация сетевых интерфейсов в Ubuntu и Debian
- Режимы работы
- Объединение сетевых интерфейсов в CentOS, RHEL и Fedora
- Заключение
- Одновременная работа двух сетевых карт
- Русские форумы такие форумы?
- Re: Русские форумы такие форумы?
- Re: Русские форумы такие форумы?
- Re: Русские форумы такие форумы?
- Одновременная работа 2-х сетевых адаптеров Linux SUSE
Объединение сетевых интерфейсов в Linux. Настройка bonding
Объединение сетевых интерфейсов(Bonding) – это механизм, используемый Linux-серверами и предполагающий связь нескольких физических интерфейсов в один виртуальный, что позволяет обеспечить большую пропускную способность или отказоустойчивость в случае повреждения кабеля. В данном руководстве мы разберем реализацию объединения интерфейсов в Linux для Ubuntu/Debian и CentOS/RHEL/Fedora.
Агрегация сетевых интерфейсов в Ubuntu и Debian
Важно! Если у вас используется Ubuntu версии 17.10 и выше, то необходимо установить пакет ifupdown или настраивать агрегацию каналов нужно через netplan
Прежде всего нужно установить модуль ядра для поддержки объединения и при помощи команды modprobe проверить, загружен ли драйвер.
В более старых версиях Debian или Ubuntu может потребоваться установка пакета ifenslave:
Для создания связанного интерфейса из двух физических сетевых карт вашей системы выполните следующую команду. К сожалению, при использовании такого метода объединение интерфейсов не сохраняется после перезагрузки системы:
Для создания постоянного связанного интерфейса типа mode 0 (ниже мы разберем эти типы более подробно), нужно отредактировать файлы конфигурации сетевых интерфейсов. Откройте с помощью любого текстового редактора, например nano, файл /etc/network/interfaces , как показано в следующем фрагменте (замените IP-адрес, маску подсети, шлюз и DNS-серверы на используемые в вашей сети).
Чтобы активировать объединенный интерфейс, перезапустите сетевую службу, отключите физические интерфейсы и включите объединенный интерфейс, либо перезагрузите машину, чтобы ядро определило новый объединенный интерфейс.
Настройки связанного интерфейса можно проверить при помощи следующих команд:
Подробную информацию об объединенном интерфейсе можно получить, просмотрев содержимое следующего файла ядра командой cat:
Для отладки ошибок можно использовать команду tail
Проверку параметров сетевой карты можно выполнить при помощи инструмента mii-tool:
Режимы работы
mode=0 (balance-rr)
При этом методе объединения трафик распределяется по принципу «карусели»: пакеты по очереди направляются на сетевые карты объединённого интерфейса. Например, если у нас есть физические интерфейсы eth0, eth1, and eth2, объединенные в bond0, первый пакет будет отправляться через eth0, второй — через eth1, третий — через eth2, а четвертый снова через eth0 и т.д.
mode=1 (active-backup)
Когда используется этот метод, активен только один физический интерфейс, а остальные работают как резервные на случай отказа основного.
mode=2 (balance-xor)
В данном случае объединенный интерфейс определяет, через какую физическую сетевую карту отправить пакеты, в зависимости от MAC-адресов источника и получателя.
mode=3 (broadcast) Широковещательный режим, все пакеты отправляются через каждый интерфейс. Имеет ограниченное применение, но обеспечивает значительную отказоустойчивость.
mode=4 (802.3ad)
Особый режим объединения. Для него требуется специально настраивать коммутатор, к которому подключен объединенный интерфейс. Реализует стандарты объединения каналов IEEE и обеспечивает как увеличение пропускной способности, так и отказоустойчивость.
mode=5 (balance-tlb)
Распределение нагрузки при передаче. Входящий трафик обрабатывается в обычном режиме, а при передаче интерфейс определяется на основе данных о загруженности.
mode=6 (balance-alb)
Адаптивное распределение нагрузки. Аналогично предыдущему режиму, но с возможностью балансировать также входящую нагрузку.
Объединение сетевых интерфейсов в CentOS, RHEL и Fedora
Создайте новый файл bonding.conf в директории /etc/modprobe.d/ . Имя может быть любым, но расширение должно быть .conf. Вставьте в этот файл следующую строку:
Такая строка в файле /etc/modprobe.d/bonding.conf требуется для каждого bond интерфейса.
Для агрегации интерфейсов создайте в директории /etc/sysconfig/network-scripts/ файл конфигурации с именем ifcfg-bond0. Вот пример содержимого файла конфигурации (IP-адреса в вашей системе могут отличаться):
После создания объединённого интерфейса нужно настроить его и связанные с ним сетевые карты, добавив в файлы конфигурации директивы MASTER и SLAVE. Для всех связанных интерфейсов эти файлы могут быть почти одинаковыми. Например, у двух интерфейсов eth0 и eth1, связанных в один, они могут иметь следующий вид. Отредактируйте их, как показано ниже.
Для eth0
Значение этих директив следующее:
DEVICE: определяет имя устройства
USERCTL: определяет, может ли пользователь управлять интерфейсом (в данном случае нет)
ONBOOT: определяет, включать ли интерфейс при загрузке
MASTER: есть ли у этого устройства ведущий интерфейс (здесь это bond0)
SLAVE: работает ли это устройство каки ведомое
BOOTPROTO: Определяет получение IP-адреса по DHCP. При статическом IP-адресе устанавливается значение none
Перезагрузите сетевую службу и проверьте конфигурацию командой ifconfig.
Заключение
Объединение сетевых интерфейсов — удобный и функциональный механизм для обеспечения качественной и бесперебойной работы вашей сети. Надеемся, данное руководство было полезным. Более подробную информацию об используемых командах можно получить в соответствующих man-страницах.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Источник
Одновременная работа двух сетевых карт
Всем привет. Дебиан 9. Две сетевые карты
привязываю к ним интерфейсы eth0 и eth1
если в /etc/network/interfaces прописать сразу оба интерфейса, то активен и пингуется только eth0
если прописывать по отдельности, то работает и eth0 и eth1 соответственно.
auto eth0 iface eth0 inet static address 192.168.0.121 gateway 192.168.0.228 netmask 255.255.252.0
auto eth1 iface eth0 inet static address 192.168.0.122 netmask 255.255.252.0
Подозреваю, что дело в шлюзе, так? Вроде бы шлюз прописывается только для первого интерфейса, а для второго надо прописывать маршрут. Но никак не могу разобраться, как правильно. Подскажите, пожалуйста, что сделать, чтобы заработало )
Зачем две сетевые карты? Тем более в одной подсети IPv4? Если нужна избыточность, то нужна агрегация LACP, если нужно два айпишника, то можно привязать к одной сетевухе, алиасингом или еще чем-то.
Опечатка же во втором конфиге?
auto eth1 iface eth0 inet static address 192.168.0.122 netmask 255.255.252.0
Русские форумы такие форумы?
Только тут тебе расскажут, почему ты -мудак- не прав?
Раскажи чего ты хочешь этим добиться?
Чтобы понять почему идея гавно, надо чутка почитать как именно линукс роутит пакеты, в реальном мире, для каждого сконфигурированного интерфейса создаётся маршрут x.x.x.x/netmask означающий, что на адреса в этой подсети слать пакеты напрямую получателям, в твоём примере создастся: 192.168.0.0/22 dev eth0 proto kernel scope link src 192.168.0.121
Это значит, что всё исходящее в 192.168.0.0/22 должно уходить с eth0, а всё приходящее на eth0 из 192.168.0.0/22 адресовано нам. Когда ты создаешь второй интерфейс с адресом в той же сети, ещё один маршрут для подсети 192.168.0.0/22 создасться не может, т.к. её уже обслуживает eth0. Все входящие пакеты на 192.168.0.122 будут приходить на eth1, а в соотвествии с таблицей маршрутизации за 192.168.0.0/22 ответственный eth0, такие пакеты по дефолту считаются не парвильными и называются «марсианскими» (martian), если проверишь dmesg то наверняка увидишь там такие записи. Кароче в реальном мире твоя схема кривая и работать не должно, но обойти эти ограничения можно, но это ппц костыли и я бы за такое ими тебя и ***покарал***, например ты можешь включить Promiscuous режим на eth1, тогда ядро будет пропускать марсианские пакеты и твоё поделие начнёт подавать признаки жизни, но исходящий трафик всё равно будет ходить через eth0 по умолчанию.
Re: Русские форумы такие форумы?
На украинских форумах такая же история, на англоязычных ресурсах также песня.
но исходящий трафик всё равно будет ходить через eth0 по умолчанию
А что мешает сделать «ip ro add 192.168.0.32/28 dev eth1 scope link src 192.168.0.122» ? Пусть к .32-.47 ходят через eth1 !
PS любимые грабли нужно знать по именам: rp_filter, arp_accept, arp_announce, arp_filter, arp_ignore
Чёта не понял про грабли))) Я бы в ситуации ТС создал ещё одну таблицу маршрутизации в /etc/iproute2/rt_tables и загнал туда eth1 правилом. Хотя всё равно решение плохое и так делать не надо
Я бы в ситуации ТС создал ещё одну таблицу маршрутизации
Он пока с одной не разобрался.
В такой ситуации ТС может просто реализовать только статическую схему, в которой часть хостов в сети будет адресоваться через eth0, а часть через eth1, просто добавив маршруты. Например, dgw через eth1, а все остальное через eth0, или половину сети через один интерфейс, а остальных через другой.
Но ему нужно пройти грабли которые специально разложены на пути для тех, кто начинает использовать несколько самостоятельных интерфейсов в одной подсети. Это не запрещено, но ты должен доказать системе, что ты понимаешь на что подписался. Это как раз и нужно выразить через sysctl net.ipv4.conf.
Re: Русские форумы такие форумы?
А белорусы с казахами чё ?
Re: Русские форумы такие форумы?
- мудаком его никто не называл
- неправым тоже
- но, о ужас! презренные хелперы-помогаторы дерзнули объяснять, как может (должно) сделать и стали требовать дополнительных пояснений (ну, тупые, ага)
- да — «Русские форумы такие форумы» ©
Источник
Одновременная работа 2-х сетевых адаптеров Linux SUSE
Всем доброго дня!
Имеется вопрос от новичка в Linux. Имеем hypervisor VMware. Создано два адаптера:
- Bridget, связан с беспроводным адаптером ноутбука (для доступа в глобальную сеть)
- Host only, для общения host и guest только (локальная сеть)
В Linux, для второго адаптера задан статический ip, первый все параметры получает автоматически. Одновременно они работать не хотят, как например в Windows Server. То есть guest имеет доступ в сеть и пингует по статическому ip, host, по локальной сети. host, пингует guest по статическому ip, по локальной сети.
В Linux такое не получается, если включены оба адаптера, то идет только локальный пинг, guest доступа в сеть не имеет. Если отключить адаптер 2, то guset имеет доступ в глобальную сеть, но host не пингуется.
Вопрос, как можно организовать так, чтобы два адаптера работали нормально.
P.S. Поскольку «чайник», то рекомендации давать как можно подробнее (step-by-step), чтобы избежать других глупых вопросов с моей стороны.
9 из 10, что достаточно убрать «gateway» в настройках второго адаптера. Подробности и варианты слабо зависят от типа ОС.
P.S. Поскольку «чайник», то рекомендации давать как можно подробнее (step-by-step), чтобы избежать других глупых вопросов с моей стороны.
В Linux, если не использовать специальные механизмы, всё работает в соответствии с обычными правилами маршрутизации, которые, в общем-то, мало зависят от ОС.
А так — текст какой-то сумбурный и непонятный. Да ещё VMware, которая не Linux. что такое «гость» и при чём тут Linux? Показывай вывод «ip a» и «ip r».
# ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0:
mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0c:29:76:50:7e brd ff:ff:ff:ff:ff:ff inet6 fe80::20c:29ff:fe76:507e/64 scope link valid_lft forever preferred_lft forever 3: eth1:
mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0c:29:76:50:74 brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global eth1 valid_lft forever preferred_lft forever inet6 fe80::20c:29ff:fe76:5074/64 scope link valid_lft forever preferred_lft forever saphxe:
Действие ip r saphxe:
# ip r 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.21
VMware — используется для максимальной поддержки Linux. В Windows Server таких танцев нет, просто добавил адаптеры, и задал ip, все.
VMware — используется для максимальной поддержки Linux.
Так он в виртуалке что ли? А при чём тут тогда Notebook?
В Windows Server таких танцев нет, просто добавил адаптеры, и задал ip, все.
В Linux тоже. Остальные вопросы к VMware вероятно.
Под окошком ввода есть фраза «Внимание: прочитайте описание разметки Markdown или LORCODE», которая содержит пару ссылок. Читать же невозможно. «ip r» не показывает наличие маршрута по умолчанию. Это так задумано?
Хотел отредактировать сообщение, но его можно только удалить как я понял. На будущее исправлюсь, согласен что читать текст невозможно.
Linux на виртуалке, в качестве хоста используется Windows 10. По вопросу маршрута не скажу, таки как новичок.
Я вот фиг знает. На второй виртуалке Windows Server, с ним по дефолту никаких проблем. Подключил два адаптера, и все работает. В Linux, такая схема не работает.
Предполагаю что проблема в том, какой адаптер используется по умолчанию в системе. Настройку делал через приложение в YAST’е. Еще раз к среде, у меня две сети, внутренняя между виртуалкой и физической машиной, и вторая сеть, которая «ведет» во вне.
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever
2: eth0:
mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0c:29:76:50:7e brd ff:ff:ff:ff:ff:ff inet6 fe80::20c:29ff:fe76:507e/64 scope link valid_lft forever preferred_lft forever
3: eth1:
mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0c:29:76:50:74 brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global eth1 valid_lft forever preferred_lft forever inet6 fe80::20c:29ff:fe76:5074/64 scope link valid_lft forever preferred_lft forever saphxe:
2 — bridget адаптер, мост на физический wifi адаптер.
3 — виртуальный адаптер, для общения машин между собой, по статическому ip.
Источник