LINUX.ORG.RU
Форум — Admin  

Intel 82546GB - нет доступа на хост-машину через bridge- интерфейсы

 


0

1

Всем доброго времени суток!

В распоряжении сервер, который работает под CentOS 6.5 x86_64 комплектации Minimal + были доустановлены пакеты наподобие bridge-utils, apcupsd и такого плана. После установки системы она была обновлена (yum update) 24.12.2013 (kernel 2.6.32-431.1.2.0.1.el6.x86_64).

Hardware:

Мат. плата: ASUS P8B-M (URL)

Процессор: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz (URL)

Сеть - 4 интерфейса Intel, на мат. плате: 1) eth0-br0 Intel Corporation 82574L Gigabit Network Connection

2) eth1-br1 Intel Corporation 82574L Gigabit Network Connection

HP NC7170 PCI-X Dual Port 1000T Gigabit Server Adapter

3) eth2-br2 Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)

4) eth3-br3 Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)

HP NC7170 PCI-X вставлена в единственный PCI слот мат. платы.

На хост-машине крутятся виртуалки KVM, которые включены в сеть через интерфейсы типа brX. Вывод утилиты ifconfig: 

br0       Link encap:Ethernet  HWaddr AC:22:0B:XX:XX:XX
          inet addr:192.168.1.253  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::ae22:bff:fe8a:d7bd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1015960 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2974 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:85047707 (81.1 MiB)  TX bytes:322859 (315.2 KiB)

br1       Link encap:Ethernet  HWaddr AC:22:0B:XX:XX:XX
          inet addr:172.20.1.253  Bcast:172.20.1.255  Mask:255.255.255.0
          inet6 addr: fe80::ae22:bff:fe8a:d7be/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:427077 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11551 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:24694614 (23.5 MiB)  TX bytes:847559 (827.6 KiB)

br2       Link encap:Ethernet  HWaddr 00:1A:4B:XX:XX:XX
          inet addr:172.20.2.253  Bcast:172.20.2.255  Mask:255.255.255.0
          inet6 addr: fe80::21a:4bff:fe06:3e1c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17738 errors:0 dropped:0 overruns:0 frame:0
          TX packets:56 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1044289 (1019.8 KiB)  TX bytes:3976 (3.8 KiB)

br3       Link encap:Ethernet  HWaddr 00:1A:4B:XX:XX:XX
          inet addr:172.20.3.253  Bcast:172.20.3.255  Mask:255.255.255.0
          inet6 addr: fe80::21a:4bff:fe06:3e1d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:276310 errors:0 dropped:0 overruns:0 frame:0
          TX packets:424 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:16556143 (15.7 MiB)  TX bytes:33441 (32.6 KiB)

eth0      Link encap:Ethernet  HWaddr AC:22:0B:XX:XX:XX
          inet6 addr: fe80::ae22:bff:fe8a:d7bd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:160737312 errors:0 dropped:0 overruns:0 frame:0
          TX packets:240118258 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:34946475333 (32.5 GiB)  TX bytes:296969688044 (276.5 GiB)
          Interrupt:16 Memory:df300000-df320000

eth1      Link encap:Ethernet  HWaddr AC:22:0B:XX:XX:XX
          inet6 addr: fe80::ae22:bff:fe8a:d7be/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:154657961 errors:0 dropped:0 overruns:0 frame:0
          TX packets:84687832 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:174022321150 (162.0 GiB)  TX bytes:21236834056 (19.7 GiB)
          Interrupt:17 Memory:df200000-df220000

eth2      Link encap:Ethernet  HWaddr 00:1A:4B:XX:XX:XX
          inet6 addr: fe80::21a:4bff:fe06:3e1c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:230237128 errors:0 dropped:0 overruns:0 frame:0
          TX packets:179550159 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:219398039354 (204.3 GiB)  TX bytes:101852760105 (94.8 GiB)

eth3      Link encap:Ethernet  HWaddr 00:1A:4B:XX:XX:XX
          inet6 addr: fe80::21a:4bff:fe06:3e1d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:310332 errors:0 dropped:0 overruns:0 frame:0
          TX packets:806 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:30858593 (29.4 MiB)  TX bytes:107706 (105.1 KiB)
Интерфейсы eth1-eth3 подключены по 4-м жилам к коммутатору D-Link DES-3828, на котором накручены VLAN и интерфейсы с сетями 172.20.X.X/24 и находятся в одной подсети 172.20.X.X/16.

Доп. информация:

cat /etc/proc/interrupts 

0:        181          0          0          0   IO-APIC-edge      timer
  1:          2          0          0          0   IO-APIC-edge      i8042
  3:          2          0          0          0   IO-APIC-edge
  4:          2          0          0          0   IO-APIC-edge
  8:          1          0          0          0   IO-APIC-edge      rtc0
  9:          0          0          0          0   IO-APIC-fasteoi   acpi
 12:          4          0          0          0   IO-APIC-edge      i8042
 16:         28          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb1
 19:     230633          0          0          0   IO-APIC-fasteoi   ata_piix, ata_piix
 20:  168571999          0          0          0   IO-APIC-fasteoi   eth2
 21:     227746          0          0          0   IO-APIC-fasteoi   eth3
 23:        124          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb2
 24:        342          0          0          0  HPET_MSI-edge      hpet2
 25:          0          0          0          0  HPET_MSI-edge      hpet3
 26:          0          0          0          0  HPET_MSI-edge      hpet4
 27:          0          0          0          0  HPET_MSI-edge      hpet5
 30:  140780253          0          0          0   PCI-MSI-edge      eth0-rx-0
 31:  212335356          0          0          0   PCI-MSI-edge      eth0-tx-0
 32:          2          0          0          0   PCI-MSI-edge      eth0
 33:   87282042          0          0          0   PCI-MSI-edge      eth1-rx-0
 34:   82358034          0          0          0   PCI-MSI-edge      eth1-tx-0
 35:          2          0          0          0   PCI-MSI-edge      eth1
NMI:      45346      41773      44018      36816   Non-maskable interrupts
LOC:  160097992  126081215  198375164  103966291   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:      45346      41773      44018      36816   Performance monitoring interrupts
IWI:          0          0          0          0   IRQ work interrupts
RES:   59871254  104272004   95495779   92920403   Rescheduling interrupts
CAL:   26630872    1099860   26666884    1097463   Function call interrupts
TLB:       1588       2330       2629       3919   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:        344        344        344        344   Machine check polls
ERR:          0
MIS:          0
Файл ifcfg-eth2 (файлы аналогичны для всех интерфейсов ethX): 
DEVICE=eth2
HWADDR=00:1A:4B:XX:XX:XX
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none
IPV6INIT=no
NAME="System eth2"
BRIDGE="br2"
Файл ifcfg-br2 (файлы аналогичны для всех интерфейсов brX): 
DEVICE=br2
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Bridge
BOOTPROTO=static
IPADDR=172.20.2.253
GATEWAY=172.20.2.1
NETMASK=255.255.255.0
DEFROUTE=no
IPV6INIT=no
IPV4_FAILURE_FATAL=yes
NAME="System br2"
Проблема: с интерфейсами eth0 и eth1 и всем, что с ними связано, проблем нет, а с остальными наблюдается следующая ситуация. Доступ к виртуалкам через eth2 (br2) и eth3 (br3) есть, а на саму хост-машину - нет (в том числе пинг-запросы). Но почему я упомянул коммутатор? Если из консоли DES-3828 запустить ping на адреса br2 и br3 - ответы приходят. Во всех других случаях ответов нет.

После несложных манипуляций с интерфейсами eth2 и eth3 утилитой ethtool ее вывод выглядит так: 

Settings for eth2:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: umbg
        Wake-on: d
        Current message level: 0x00000007 (7)
                               drv probe link

Features for eth2:
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off

Settings for eth3:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: d
        Wake-on: d
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

Features for eth3:
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off
Но ситуация не изменилась. Прошу помощи. Спасибо!



Последнее исправление: romarioschneider (всего исправлений: 3)
← Сделать копию удаленного CentOS
способы ethernet-соединений компьютеров и свичей →

1. Самое тупое - файрволл?

2. У меня с почти такой же картой PCI-X 82546EB в PCI слоте были жесточайшие глюки, не завелась толком. Даже баг писал http://sourceforge.net/p/e1000/bugs/342/

Но у тебя то вроде кое-как работает, так что дело в ином.

3. Может дублируются айпишники где-то? После пинга со свича посмотри на нем АРП - маки правильные?

blind_oracle ★★★★★
()

Пробовал на этих картах поднять адреса первых двух сеток и воткнуть в другие порты на длинке?

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

1. Самое тупое - файрволл?

Правила iptables одинаковы для всех интерфейсов + все тестирования проводил после 

 service iptables stop

2. У меня с почти такой же картой PCI-X 82546EB в PCI слоте были жесточайшие глюки, не завелась толком. Даже баг писал http://sourceforge.net/p/e1000/bugs/342/

До обновления CentOs сервер работал на десктопной мат. плате AsRock Z77. Там было то же, что и у тебя. Сетевуха HP NC7170 PCI-X Dual Port 1000T Gigabit Server Adapter внезапно начинала терять пакеты и работать на скорости ~4 Mbps. Такая же картина наблюдалась на плате AsRock чипсета, (точно не помню), Z66: 

[   87.148614] irq 21: nobody cared (try booting with the "irqpoll" option)
-[   87.148663] Pid: 1506, comm: which Not tainted 3.0.32-VMSTOR2-SCST-2.2-REV4314 #1
-[   87.148725] Call Trace:
-[   87.148764]  <IRQ>  [<ffffffff81079e2f>] ? __report_bad_irq+0x2f/0xd0
-[   87.148839]  [<ffffffff8107a034>] ? note_interrupt+0x164/0x210
-[   87.148890]  [<ffffffff81182ead>] ? blk_done_softirq+0x6d/0x80
-[   87.148937]  [<ffffffff8107808a>] ? handle_irq_event_percpu+0x7a/0x140
-[   87.148986]  [<ffffffff81078183>] ? handle_irq_event+0x33/0x60
-[   87.149036]  [<ffffffff8107a669>] ? handle_fasteoi_irq+0x49/0xe0
-[   87.149085]  [<ffffffff81003ec5>] ? handle_irq+0x15/0x20
-[   87.149131]  [<ffffffff81003693>] ? do_IRQ+0x53/0xd0
-[   87.149179]  [<ffffffff813dfa53>] ? common_interrupt+0x13/0x13
-[   87.149227]  <EOI>  [<ffffffff81088e01>] ? find_get_page+0x31/0x90
-[   87.149303]  [<ffffffff81088de8>] ? find_get_page+0x18/0x90
-[   87.149350]  [<ffffffff81089df8>] ? filemap_fault+0x98/0x430
-[   87.149398]  [<ffffffff810a45c2>] ? __do_fault+0x52/0x4b0
-[   87.149449]  [<ffffffff810a3259>] ? free_pgtables+0x49/0xd0
-[   87.149498]  [<ffffffff810a4aad>] ? handle_pte_fault+0x8d/0xb50
-[   87.149548]  [<ffffffff813dfa4e>] ? common_interrupt+0xe/0x13
-[   87.149595]  [<ffffffff8101fa57>] ? do_page_fault+0x137/0x3c0
-[   87.149645]  [<ffffffff810aa1fa>] ? mmap_region+0x24a/0x5d0
-[   87.149693]  [<ffffffff810a9697>] ? get_unmapped_area+0x87/0x120
-[   87.149739]  [<ffffffff813dfc5f>] ? page_fault+0x1f/0x30
-[   87.149784] handlers:
-[   87.149825] [<ffffffff8127dd60>] e1000_intr
-[   87.149894] Disabling IRQ #21
После недельного брождения по форумам выяснено, что глобальная проблема чипсетов из этой серии и ситуация не единична. Как не странно, проблему тогда решили сборкой ванильного ядра 3.8.7, отправкой в down одного из портов сетевухи (второй, который оставил рабочим, работал отлично) и использованием параметра irqpool. После этого данные строки и лаги трафика появлялись все так же внезапно, но намного реже. Вот в такой конфигурации система проработала 9 месяцев, а вышеуказанные строки в логах появились всего, где-то, раз 6. Но уже перед заменой железа на серверное ранее отключенный порт сетевухи был поднят и наблюдалась ситуация, которая сейчас наблюдается в описании проблемы. Сейчас, после обновления железа, проблем с прерываниями с моей стороны не замечено.

3. Может дублируются айпишники где-то? После пинга со свича посмотри на нем АРП - маки правильные?

Проверил. Все четко - соответствующие динамические MACи.

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

+добавляю инфу о драйвере:

ethtool -i eth2 

driver: e1000
version: 8.0.35-NAPI
firmware-version: N/A
bus-info: 0000:06:01.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
ethtool -i eth3 
driver: e1000
version: 8.0.35-NAPI
firmware-version: N/A
bus-info: 0000:06:01.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

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

Пробовал на этих картах поднять адреса первых двух сеток и воткнуть в другие порты на длинке?

Нет. В одном из предыдущих комментариев я написал, что эта ситуация наблюдалась ранее с одним из портов сетевухи. Он, как раз, был подключен к сети 172.20.3.0/24. В свою очередь, порт сети 172.20.2.0/24 отлично работал на карте D-Link DGE-528T.
Поднять адреса первых сеток можно, но нужно подождать момент, так как система in Production. По этой же причине нельзя поменять порты на D-Linkе. Потом отпишусь.

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

Как все сложно. Не думали поднять бонд на все 4 линка? Упростится администрирование и возрастет скорость доступа.

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

Как все сложно. Не думали поднять бонд на все 4 линка? Упростится администрирование и возрастет скорость доступа.

Вот как раз перед апгрейдом системы планировал поднимать бондинг на 3 интерфейса, но погуглив инфу по этому поводу пришел к выводу, что в моей ситуации (виртуалки с бриджами) нет гарантий корректной работы такой конфигурации. Задача состояла в скорейшем обновлении железа. Поэтому времени и возможностей для тестов не было. Сейчас готовлю десктопную машину для тестов - т.е. Ваше утверждение актуально.
После отправки предыдущего ответа подумал, что надо подключиться к проблемным интерфейсам через другой девайс (например, мой ноутбук Lenovo) и проверить доступ. Раньше всего это получится сделать завтра 30.12.

romarioschneider
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Сделать копию удаленного CentOS
Admin
способы ethernet-соединений компьютеров и свичей →