сетевуха Intel 82574L и bonding
evhen 9 января, 2012 - 01:55
проблема в том, что если канал на RTL8111 работает (по умолчанию) то, вся сеть на Intel 82574L не работает: пакеты получает, но не отправляет:
ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:1b:21:c4:08:2b
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:558 (558.0 B) TX bytes:0 (0.0 B)
Interrupt:16 Memory:fdac0000-fdae0000
RTL8111 встроенные, висят в bonding смотрят на один комп (bond0)
Ethernet Pro 100 - смотрит в тырнет (eth3)
Intel 82574L - смотрит на другие компы (eth0)
если bond0 вырубить, то eth0 работает нормально..
сетевуху в другой порт перетыкал - не помогло..
список сетевушек:
lspci|grep Eth 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03) 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03) 08:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 09:06.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 05)
cat /etc/udev/rules.d/70-persistent-net.rules
# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:c4:08:2b", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="6c:f0:49:e7:1a:ac", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="6c:f0:49:e6:f4:59", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:a0:c9:e3:53:aa", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"
cat /etc/conf.d/net
preup() {
# Adjusting the bonding mode / MII monitor
# Possible modes are : 0, 1, 2, 3, 4, 5, 6,
# OR
# balance-rr, active-backup, balance-xor, broadcast,
# 802.3ad, balance-tlb, balance-alb
# MII monitor time interval typically: 100 milliseconds
if [[ ${IFACE} == "bond0" ]] ; then
#BOND_MODE="balance-alb"
BOND_MODE="802.3ad"
BOND_MIIMON="100"
echo ${BOND_MODE} >/sys/class/net/bond0/bonding/mode
echo ${BOND_MIIMON} >/sys/class/net/bond0/bonding/miimon
einfo "Bonding mode is set to ${BOND_MODE} on ${IFACE}"
einfo "MII monitor interval is set to ${BOND_MIIMON} ms on ${IFACE}"
else
einfo "Doing nothing on ${IFACE}"
fi
iptables-restore < /etc/iptables.up.rules
return 0
}
modules="dhcpcd"
interfaces="bond0"
config_eth0="192.168.1.3 netmask 255.255.255.0 broadcast 192.168.1.255"
config_bond0="192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255"
slaves_bond0="eth1 eth2"
config_eth3=""
ifup_eth3="/root/iptables-rc.bond"
cat ~/iptables-rc.bond
iptables -F
iptables -t nat -F
#Setup default policies to handle unmatched traffic
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
#Copy and paste these examples ...
export WAN=eth3
export LAN=eth0
export LANB=bond0
#Then we lock our services so they only work from the LAN
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i ${LAN} ${LANB} -j ACCEPT
iptables -A INPUT -i ${LANB} -j ACCEPT
#(Optional) Allow access to our ssh server from the WAN
# iptables -A INPUT -p TCP --dport ssh -i ${WAN} -j ACCEPT
iptables -A INPUT -p TCP --dport 137:139 -i ${WAN} -j ACCEPT
iptables -A INPUT -p UDP --dport 137:139 -i ${WAN} -j ACCEPT
iptables -A INPUT -p TCP --dport 445 -i ${WAN} -j ACCEPT
iptables -A INPUT -p TCP --dport 20:21 -i ${WAN} -j ACCEPT
iptables -A INPUT -p UDP --dport 20:21 -i ${WAN} -j ACCEPT
iptables -A INPUT -p TCP --dport 2049:2049 -i ${WAN} -j ACCEPT
iptables -A INPUT -p UDP --dport 2049:2049 -i ${WAN} -j ACCEPT
#Finally we add the rules for NAT
iptables -A FORWARD -i ${LAN} -s 192.168.1.0/255.255.255.0 -j ACCEPT
iptables -A FORWARD -i ${LANB} -s 192.168.1.0/255.255.255.0 -j ACCEPT
iptables -A FORWARD -i ${WAN} -d 192.168.1.0/255.255.255.0 -j ACCEPT
iptables -A FORWARD -i ${WAN} -d 192.168.2.0/255.255.255.0 -j ACCEPT
iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE
#Tell the kernel that ip forwarding is OK
echo 1 > /proc/sys/net/ipv4/ip_forward
for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done
#This is so when we boot we don't have to run the rules by hand
/etc/init.d/iptables save
iptables-save > /etc/iptables.up.rules
»
- Для комментирования войдите или зарегистрируйтесь

.
Правильно, так и должно быть. Оно и не будет работать, ибо:
тогда такой вопрос: как
тогда такой вопрос:
как правильно организовать сеть, чтобы траффик ходил между eth0 и bond0 и ходил в тырнет через eth3 ?
.
bridge, если его можно настроить между bond и eth. Точно не знаю, не пробовал.
Для чего вообще bond в такой схеме? Эксперименты?
route
пропиши статические маршруты (для bond0 и eth0)
а лучше на подсети поделить и тогда просто маршрутизация
.
Позвольте полюбопытствовать, а статические маршруты это как? Или я что-то не так понял?
( . ) ( . )
К примеру к bond0 у вас подключен сервер 192.168.1.4, добавляем маршрут:
Предположим всё остальное что входит в сеть 192.168.1.0/24 подключено к eth0
Теперь пакеты на 192.168.1.4 будут идти через bond0 а в 192.168.1.0/24 через eth0
Ещё надо дать понять всем кто в сети 192.168.1.0/24, что на 192.168.1.4 надо ходить через 192.168.1.3
Поэтому на всех хостах добавляем маршрут:
а на 192.168.1.4:
Незабываем включить форвардинг:
Как-то так
.
Подробности можно было и опустить :)
Я понял суть идеи. Но тогда для того,
чтобы траффик ходил между eth0 и bond0на всех хостах за eth0 нужно прописывать статический маршрут к хостам за bond0 и наоборот. Как-то не совсем удобно выходит. По всему, brigdge будет удобнее, только вот не знаю, можно ли его поднять между bond и eth? Теоретически, не должно быть с этим проблем, но кто знает...
.
Гугль знает. И посмотрите здесь - может, найдёте что полезное (сам не читал за неимением времени)...
Мы тоже не всего читали Шнитке!.. © В. Вишневский
.
Между тем, довольно простой вопрос перерос в обсуждение возможных методик, а ТС куда-то исчез... :)
Я, как бы, всего лишь отвечал на вопросы ТС.
Мне не совсем понятен смысл схемы, описанной в титульном сообщении, а что касается bridge между bond и eth - теоретически не вижу препятствий, но практически не понимаю смысла.
.
Имхо, таковое уже стало некоей недоброй традицией...
Мы тоже не всего читали Шнитке!.. © В. Вишневский
никуда не исчез.. сделал 2
никуда не исчез..
сделал 2 подсети:
теперь, как я понимаю, должно всё работать...
чего не происходит :-(
в тырнет на eth3 ходят с обоих подсетей, а вот между собой - никак..
~ # cat ~/iptables-rc.bond iptables -F iptables -t nat -F #Setup default policies to handle unmatched traffic iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD DROP #Copy and paste these examples ... export WAN=eth3 export LAN=eth0 export LANB=bond0 #Then we lock our services so they only work from the LAN iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -i ${LAN} -j ACCEPT iptables -A INPUT -i ${LANB} -j ACCEPT #(Optional) Allow access to our ssh server from the WAN # iptables -A INPUT -p TCP --dport ssh -i ${WAN} -j ACCEPT iptables -A INPUT -p TCP --dport 137:139 -i ${WAN} -j ACCEPT iptables -A INPUT -p UDP --dport 137:139 -i ${WAN} -j ACCEPT iptables -A INPUT -p TCP --dport 445 -i ${WAN} -j ACCEPT iptables -A INPUT -p TCP --dport 20:21 -i ${WAN} -j ACCEPT iptables -A INPUT -p UDP --dport 20:21 -i ${WAN} -j ACCEPT iptables -A INPUT -p TCP --dport 2049:2049 -i ${WAN} -j ACCEPT iptables -A INPUT -p UDP --dport 2049:2049 -i ${WAN} -j ACCEPT # <<---- iptables -A FORWARD -i ${LAN} -s 192.168.1.0/255.255.255.0 -j ACCEPT iptables -A FORWARD -i ${LANB} -s 192.168.2.0/255.255.255.0 -j ACCEPT iptables -A FORWARD -i ${WAN} -d 192.168.1.0/255.255.255.0 -j ACCEPT iptables -A FORWARD -i ${WAN} -d 192.168.2.0/255.255.255.0 -j ACCEPT iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE #Tell the kernel that ip forwarding is OK echo 1 > /proc/sys/net/ipv4/ip_forward for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done #This is so when we boot we don't have to run the rules by hand /etc/init.d/iptables save iptables-save > /etc/iptables.up.rulesпри включении лога с eth0 при ping 192.168.2.5 почему-то у пакетов dst = 192.168.1.3:
.
Что за src на eth0? Или за ней есть еще какая-то сетка?
ip r?
Именно. eth0 смотрит в одну
Именно.
eth0 смотрит в одну сеть
bond0 в другую
eth3 в тырнет
Отключите
Отключите iptables
Везде проверьте маршруты.
Пингуйте из одной сети другую и смотрите tcpdump'ом что в это время на интерфейсах.
Возможные причины: нехватает маршрутов, "натится" между сетями
"SRC=192.168.6" надеюсь опечатка?
Ну и главное:
закомментируйте, предварительно записав туда нули
Непонимаю, при чём тут
Непонимаю, при чём тут маршруты:
если пакет из bond0 идёт к получателю в eth0, то зачем статическая маршрутизация? Ведь из-за разных подсетей NAT должен разрулить всё?