LINUX.ORG.RU
ФорумAdmin

Не получается разделить два сетевых моста.

 ,


0

1

Есть две сетевые eth0 и eth1 и два сетевых моста.

/etc/sysconfig/network/ifcfg-br0

BOOTPROTO='static'
BRIDGE='yes'
BRIDGE_FORWARDDELAY='0'
BRIDGE_PORTS='eth0'
BRIDGE_STP='off'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='192.168.1.177/24'
MTU=''
NETWORK=''
PREFIXLEN='24'
REMOTE_IPADDR=''
STARTMODE='auto'

/etc/sysconfig/network/ifcfg-br1

BOOTPROTO='static'
BRIDGE='yes'
BRIDGE_FORWARDDELAY='0'
BRIDGE_PORTS='eth1'
BRIDGE_STP='off'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='192.168.1.166/24'
MTU=''
NETWORK=''
PREFIXLEN='24'
REMOTE_IPADDR=''
STARTMODE='auto'
NAME=''

/etc/sysconfig/network/ifcfg-eth0

BOOTPROTO='none'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR=''
MTU=''
NAME='DGE-530T Gigabit Ethernet Adapter (rev 11)'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
NETMASK=''
PREFIXLEN=''

/etc/sysconfig/network/ifcfg-eth1

BOOTPROTO='none'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR=''
MTU=''
NAME='RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
NETMASK=''
PREFIXLEN=''

Проблема заключается в следующем: Подключаем сетевой кабель к eth1 (192.168.1.166) и включаем компьютер. После этого из сети пингуется только 166 и не пингуется 177 (это правильно). Затем в сетевую eth0 подключается ноут не связанный с локалкой. После этого с ноута 177 адрес не пингуется (а должен), а из локалки начинает пинговаться (а не должен). Дальнейшие манипуляции с подключениями/отключениями кабелей на ситуацию не влияют.

opensuse 42.3

Вобще по умолчанию ядро отвечает на arp-запросы на все адреса, являющиеся локальными (назначенные на сетевые интерфейсы). Так что:

и не пингуется 177 (это правильно)

Как бы не правильно, пинговаться должно было, но просто тот линк был down и адреса как бы не было назначено.

Что касается прописывания маршрута в одну сеть на два сетвых интерфейса, то это бесполезно. Вы явно делаете что-то не так, наверное, вам нужен один бридж, два ip-адреса на нём и фильтрация в ebtables/iptables...

mky ★★★★★
()
Ответ на: комментарий от mky

Вы явно делаете что-то не так

Согласен. Вообще eth0 адреса не имеет и нужен только для KVM, но проблема в том, что внутри виртуалок интерфейсы работают так же криво. Т.е. все контейнеры работают через одну сетевую (ту которая первая подключилась), хотя в настройках для них указанны разные мосты. И при отключении первой сетевой линк пропадает и у всех.

Как бы не правильно

При отсутствии настроенных мостов, работает именно как надо (есть кабель - есть пинг, нет кабеля - нет пинга).

comrade82
() автор топика
Ответ на: комментарий от comrade82

Соглашусь с mky «Вы явно делаете что-то не так»

Вообще eth0 адреса не имеет

Что правильно. Но вот далее не понятно

и нужен только для KVM

Вам нужно два бриджа или все-таки один? И если два то зачем на них прописываете адреса из одной подсети?

anc ★★★★★
()
Ответ на: комментарий от anc

Вам нужно два бриджа или все-таки один?

Нужно два.

зачем на них прописываете адреса из одной подсети?

Адрес у eth0 появился в процессе поиска решения изначальной проблемы (виртуалки работали только через одну сетевую, не обращая внимания на настройки). А поскольку на НГ праздниках в оборудовании крайне ограничен, то пришлось взять адреса из одной подсети. В итоге ломаю голову именно над последним вопросом.

Вообще думал, что решение должно быть в BRIDGE_PORTS='eth0' или BRIDGE_PORTS='eth0 eth1', но практика показывает, что это вообще не работает.

comrade82
() автор топика
Ответ на: комментарий от comrade82

А поскольку на НГ праздниках в оборудовании крайне ограничен, то пришлось взять адреса из одной подсети.

Так может не стоит делиться своей головной болью с другими? Не у вас одного праздники. :) Давайте натуральную задачу.

anc ★★★★★
()
Ответ на: комментарий от anc

Давайте натуральную задачу.

ОК. Например имеем свич с одним гигабитным портом и хотим его отдать именно на гигабитную сетевую (для чего-то очень нагруженного) или наоборот хотим разгрузить сетевую для хорошего пинга, а сделать всё это нужно в одной подсети.

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

comrade82
() автор топика
Ответ на: комментарий от comrade82

Что есть слово «свич»? Неведомая штука на другом конце наших проводов? Если да, то можно реализовать не вызывая петли eb[ip]tables iproute2 netns etc но опять-таки нужна конкретика. Кратко, интерфейс не должен отвечать на arp запрос об ip с интерфейса на котором его(ip) нет, и соответственно с этого интерфейса не должно ничего улетать с ip(из той же сети) которого там нет.

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

Неведомая штука на другом конце наших проводов?

Штука объединяющая много компьютеров в локальную сеть. Например TL-SL2210.

опять-таки нужна конкретика

Конкретика заключается только в работе двух сетевых мостов со своими сетевыми картами с ip из одной подсети. Могу сформулировать еще проще (хоть и более нелепо). Представим что один из сетевых кабелей (из сетевой 166) перегрызает мышь. В моём случае подключиться к компьютеру по второму кабелю, подключенному во вторую сетевую, подчинённую второму мосту с ip 177, будет невозможно. Но до того как первый кабель повреждён работать с 177 адресом можно.

comrade82
() автор топика
Ответ на: комментарий от comrade82

Могу сформулировать еще проще (хоть и более нелепо). Представим что один из сетевых кабелей (из сетевой 166) перегрызает мышь.

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

anc ★★★★★
()
Ответ на: комментарий от comrade82

Возвращаемся к началу темы. Вот вы воткнули ноут не связанный с локалкой во второй линк 177. Пингуете с ноута 177, а ответ уходит с линка 166. Во всяком случае думаю именно так и есть, можете проверить tcpdump

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.