сетевуха 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 ходят с обоих подсетей, а вот между собой - никак..
при включении лога с 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 должен разрулить всё?