[AlKov]

CentOS 6.9, ядро 3.10.108-1.el6.elrepo.x86_64, accel-ppp version 03d9f8c59b6375325d7dfef0313c8c54705cfe0b, QinQ, ip-unnumbered, сетевые карты - две набортные intel I210.

Непредсказуемо уходят в down ВСЕ IPoE интерфейсы, связанные с QinQ, включая "родителя"(eth0).

Что примечательно, второго интерфейса (eth1) это ни в малейшей степени не касается, хотя на нём также поднят vlan,

правда без второго тега - обычный 802.1q.
Происходит это в-основном в момент перевода сегмента сети с PPPoE-Dual access на IPoE, иногда - гораздо реже - уже в "только IPoE состоянии".
В логах - как системных, так и аццел-я - ничего, что бы могло пролить свет на причину.
Написал "сторожа", который следит за состоянием "родительского интерфейса", выполняя цикл "ifconfig eth0 up... ifconfig eth0.XXXX.YYYY up" после его отключения. После чего всё восстанавливается.
Добавил в "сторожа" запись  dmesg,  ifconfig eth0, ethtool -S eth0 (перед восстановлением интерфейсов).

В dmesg в момент отключения вообще ничего, проливающего свет, не пишется. В messages и kern.log - аналогично.

Такое ощущение, что на сервере в этот момент ШТАТНО выполняется команда ifconfig eth0 down, что соотв. приводит к отключению всех сабинтерфейсов.

Вот "свежий" журнал проблемы

Скрытый текст

Цитата

Tue Jun 12 11:16:01 MSK 2018 перезагрузка по причине отключения eth0
eth0      Link encap:Ethernet  HWaddr A4:BF:01:25:B5:35
          BROADCAST MULTICAST  MTU:1526  Metric:1
          RX packets:5657874962 errors:252 dropped:0 overruns:0 frame:252
          TX packets:7859823059 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10000
          RX bytes:2121981699879 (1.9 TiB)  TX bytes:9454277946102 (8.5 TiB)

NIC statistics:
     rx_packets: 5660054776
     tx_packets: 7859823033
     rx_bytes: 2150704111175
     tx_bytes: 9492654973046
     rx_broadcast: 2249911
     tx_broadcast: 423981
     rx_multicast: 2015235
     tx_multicast: 19630
     multicast: 2015235
     collisions: 0
     rx_crc_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 0
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     rx_long_length_errors: 252
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 0
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_long_byte_count: 2150704111175
     tx_dma_out_of_sync: 0
     lro_aggregated: 0
     lro_flushed: 0
     tx_smbus: 0
     rx_smbus: 2037749
     dropped_smbus: 0
     os2bmc_rx_by_bmc: 19630
     os2bmc_tx_by_bmc: 0
     os2bmc_tx_by_host: 19630
     os2bmc_rx_by_host: 0
     tx_hwtstamp_timeouts: 0
     rx_hwtstamp_cleared: 0
     rx_errors: 252
     tx_errors: 0
     tx_dropped: 0
     rx_length_errors: 252
     rx_over_errors: 0
     rx_frame_errors: 0
     rx_fifo_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_queue_0_packets: 558
     tx_queue_0_bytes: 44980
     tx_queue_0_restart: 0
     tx_queue_1_packets: 0
     tx_queue_1_bytes: 0
     tx_queue_1_restart: 0
     tx_queue_2_packets: 0
     tx_queue_2_bytes: 0
     tx_queue_2_restart: 0
     tx_queue_3_packets: 7859822501
     tx_queue_3_bytes: 9454277901122
     tx_queue_3_restart: 0
     rx_queue_0_packets: 5657874008
     rx_queue_0_bytes: 2121981197712
     rx_queue_0_drops: 0
     rx_queue_0_csum_err: 0
     rx_queue_0_alloc_failed: 0
     rx_queue_1_packets: 72
     rx_queue_1_bytes: 39600
     rx_queue_1_drops: 0
     rx_queue_1_csum_err: 0
     rx_queue_1_alloc_failed: 0
     rx_queue_2_packets: 828
     rx_queue_2_bytes: 435567
     rx_queue_2_drops: 0
     rx_queue_2_csum_err: 0
     rx_queue_2_alloc_failed: 0
     rx_queue_3_packets: 54
     rx_queue_3_bytes: 27000
     rx_queue_3_drops: 0
     rx_queue_3_csum_err: 0
     rx_queue_3_alloc_failed: 0

 

Вот это -

Цитата

RX ..... errors:252 .... frame:252

наблюдалось ещё до падения интерфейса.
После "восстановления" стало так

Цитата

RX ... errors:390 ... frame:390

На сабинтерфейсах этих ошибок нет.

 

Где искать "автора ifconfig ... down"  - в accel, или ОС?

 

P.S. Ещё один момент - в самом начале перевода абонентов с PPPoE на IPoE обнаружился вот этот баг  на коммутаторах D-Link.
Теоретически он может быть причиной проблемы?
Вполне возможно, что такой "кастрированный" пакет может и долетать до сервера с accel, несмотря на ACL (вырезают PPPoE, multicact и ipv6),
которые вполне могут его пропустить по причине не соответствия стандарту.
Правда сейчас функционал pppoe circuit id insertion в IPoE сегментах я везде отключил, но кто его знает, возможно при каких-то условиях он всё равно срабатывает..
Фикс для DES-3200 ещё не вышел, сделали только для DGS-3120, да и то, не до конца.

 

P.P.S. Более подробно - с "уклоном" на accel - тут

[NiTr0]

поставить для начала нормальные сетевки (те же 82576 копейки стоят). ну и нормальное (не патченное-перепатченное ископаемое с кучей бэкпортов из более свежих) ядро.

[AlKov]

27 минут назад, NiTr0 сказал:

поставить для начала нормальные сетевки (те же 82576 копейки стоят). ну и нормальное (не патченное-перепатченное ископаемое с кучей бэкпортов из более свежих) ядро.

Всё это, конечно, здОрово, но только теоретически..

1. Соглашусь, что 82576 - это чуть ли не единственная надёжная и проверенная временем сетевуха, но.. Увы - в прошлом веке..

Дело в том, что на данной материнке (Intel S1200SP) шина PCI-Ex живёт - как это ни странно - в процессоре (Xeon E3-1220 v6).

И будет ли 82576 работать лучше "родных" I210 при таком раскладе, совсем не известно..

 

2. Данное "ископаемое ядро" взято не с потолка, а с того же elrepo, где позиционируется стабильным для CentOS 6, которая и установлена.

Игры со сборкой ванильных ядер на CentOS мы уже проходили, увы - НЕ успешно..

 

Т.о. в итоге получаем того же кота в мешке, со всеми вытекающими..

А машина уже в продакшен, пока ещё не ахти какой (~350 абонентов), но с живыми людьми..

 

А мне сейчас хотелось бы для начала определиться с источником проблемы (accel, или CentOS), и уже только потом принимать решение, в какую сторону двигаться..

 

 

[rm_]

5 hours ago, AlKov said:

Такое ощущение, что на сервере в этот момент ШТАТНО выполняется команда ifconfig eth0 down

Небось какой-нибудь systemd или NetworkManager у вас там шалит.

[AlKov]

1 час назад, rm_ сказал:

Небось какой-нибудь systemd или NetworkManager у вас там шалит.

Нет, тут дело не в этих динозаврах.

Ни тот, ни другой не используются.

А NetworkManager так и вовсе отсутствует в штатном софте, да и ещё до того, как он пропал в "базовой комплектации", всегда отключался в первую очередь.

Вообще, ощущение такое, что от абонента прилетает какой-то изуродованный пакет, на который либо accel, либо ОС неадекватно реагируют.

Например, вместо того, чтобы отправить в down eth0.3612.2501, на который этот пакет прилетел, гасят сразу eth0.

Но это пока нЕчем ни подтвердить, ни отрицать..

Вот и ищу способы "поимки чёрной кошки".

[DDR]

Для "кошек" можете попробовать что-нибудь вроде rtmon -0 /var/log/netlink.log

[AlKov]

9 часов назад, DDR сказал:

Для "кошек" можете попробовать что-нибудь вроде rtmon -0 /var/log/netlink.log

Посмотрел, что могу из этого получить. Навскидку - практически ничего.

.....

2042: eth0.3898.2302@eth0.3898: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
250: eth0.3906.2501@eth0.3906: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
251: eth0.3898.1905@eth0.3898: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
252: eth0.3906.2305@eth0.3906: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
254: eth0.3869.703@eth0.3869: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
Timestamp: Wed Jun 13 09:36:36 2018 526588 us
172.16.15.65 dev eth0.3815.808 lladdr 90:72:82:11:8b:ae STALE
Timestamp: Wed Jun 13 09:36:36 2018 830584 us
172.16.14.186 dev eth0.3716.404 lladdr 84:16:f9:c5:96:19 STALE

.....

Что полезного по проблеме отсюда можно вытянуть?

[kayot]

17 часов назад, AlKov сказал:

Всё это, конечно, здОрово, но только теоретически..

1. Соглашусь, что 82576 - это чуть ли не единственная надёжная и проверенная временем сетевуха, но.. Увы - в прошлом веке..

Дело в том, что на данной материнке (Intel S1200SP) шина PCI-Ex живёт - как это ни странно - в процессоре (Xeon E3-1220 v6).

И будет ли 82576 работать лучше "родных" I210 при таком раскладе, совсем не известно..

 

2. Данное "ископаемое ядро" взято не с потолка, а с того же elrepo, где позиционируется стабильным для CentOS 6, которая и установлена.

Игры со сборкой ванильных ядер на CentOS мы уже проходили, увы - НЕ успешно..

 

Т.о. в итоге получаем того же кота в мешке, со всеми вытекающими..

А машина уже в продакшен, пока ещё не ахти какой (~350 абонентов), но с живыми людьми..

 

А мне сейчас хотелось бы для начала определиться с источником проблемы (accel, или CentOS), и уже только потом принимать решение, в какую сторону двигаться..

1. PCIe живет в процессоре еще со времен выхода архитектуры sandy bridge, совсем ничего странного. И никакой разницы нет, распаян сетевой чип на материнке или стоит в слоте. Попробуйте для начала проверенную карту.

2. Ядро с elrepo вовсе не гарантия стабильности, скорее наоборот. Я б вручную собрал что-то свежее. Ну или хотя бы igb-драйвер руками соберите свежий, i210 же на нем?

[TheUser]

17 часов назад, AlKov сказал:

А машина уже в продакшен, пока ещё не ахти какой (~350 абонентов), но с живыми людьми..

Как же вы без резерва запускаетесь в продакшн

А со стороны коммутатора что по ошибкам/логам?

Flow-control отключен?

[alibek]

Из линуксов мне более-менее подходящим кажется Debian.

CentOS ценен только из-за родства с RedHat. Да и версия 6.9 старовата, ИМХО.

[kayot]

@alibek 

Для линуксов дистрибутив особой роли не играет, любой можно приготовить как нужно.

[kayot@IPoE1 ~]$ cat /etc/redhat-release
CentOS release 6.8 (Final)
[kayot@IPoE1 ~]$ uname -a
Linux IPoE1.localdomain 3.18.42 #1 SMP Wed Sep 21 08:20:09 EEST 2016 x86_64 x86_64 x86_64 GNU/Linux
[kayot@IPoE1 ~]$ uptime
 11:26:38 up 507 days, 12:53,  1 user,  load average: 0.72, 0.86, 0.84
[kayot@IPoE1 ~]$ accel-cmd show stat | grep active
  active: 2008
[kayot@IPoE1 ~]$ ip link show | grep bond1 | wc -l
4335

Такой же IPOE-QinQ БРАС, accel-ppp. Аптайм ограничен профилактиками, 1.5 года на данный момент.

[AlKov]

1 час назад, kayot сказал:

1. PCIe живет в процессоре еще со времен выхода архитектуры sandy bridge, совсем ничего странного. И никакой разницы нет, распаян сетевой чип на материнке или стоит в слоте. Попробуйте для начала проверенную карту.

2. Ядро с elrepo вовсе не гарантия стабильности, скорее наоборот. Я б вручную собрал что-то свежее. Ну или хотя бы igb-драйвер руками соберите свежий, i210 же на нем?

Нет свободной 82576, надо заказывать. Да и никаких проблем до accel-я не было c I210, три машины работают на том же CentOS 6.9 и не кашляют.

Правда, на родном ядре. 3.10 в данном случае только из-за accel поставил, т.к. на родном не собирается он..

Плюс ко всему - ещё раз сделаю акцент - второй интерфейс (eth1), не связанный с accel и QinQ работает без проблем.

Через него трафик уходит на NAT/маршрутизатор.

Драйвер igb свежий - 5.3.5.4, под ядро пересобран.

 

To @TheUser  - коммутатор 100% не при делах, т.к. изначально проблема появилась когда сервер с accel был подключен к совсем другому коммутаторе,

Flow-control отключен. В логах его только down/up порта.  Падает только тот порт, который подключён к интерфейсу eth0 сервера с accel.

Т.е. "инициатива" отключения порта 100% со стороны сервера,  инициированная явно каким-то "странным" пакетом от клиентов.

Более склоняюсь к тому, что это проблема accel, т.к. со стороны ОС никаких сообщений о НЕштатных событиях нет, но девелоперы пока не подтверждают это..

Вот и пытаюсь понять/посмотреть, что это такое непотребное генерят клиенты..

 

[NiTr0]

19 часов назад, AlKov сказал:

Соглашусь, что 82576 - это чуть ли не единственная надёжная и проверенная временем сетевуха, но.. Увы - в прошлом веке..

с какой это радости?

 

19 часов назад, AlKov сказал:

Дело в том, что на данной материнке (Intel S1200SP) шина PCI-Ex живёт - как это ни странно - в процессоре (Xeon E3-1220 v6).

а что странного-то? ну в проце контроллер, и? причем это к сетевухе-то???

 

19 часов назад, AlKov сказал:

И будет ли 82576 работать лучше "родных" I210 при таком раскладе, совсем не известно..

а если бы pci-e контроллер был в отдельном чипе, общающемся с кмнем по QPI, что бы изменилось???

 

как минимум - на 82576 побольше буфер пакетов, ну и как работают на высоком pps дешевые i210 - вопрос. мож у них крышу сносит от флуда. хотя при этом должно быть что-то в dmesg но не факт.

 

если не хотите менять - как минимум свежий драйвер соберите. а лучше - со сежим ядром. ну и dmesg посмотрите.

 

19 часов назад, AlKov сказал:

Данное "ископаемое ядро" взято не с потолка, а с того же elrepo, где позиционируется стабильным для CentOS 6, которая и установлена.

оно давно протухло, и как/кемҐкакими патчами патчено - огромный вопрос.

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

тем более - "клон ынтырпрайза" совсем не значит "стабильно работает". я в свое время огребал на центоси 5 висы kvm-а после очередного прихода "свежих патчей"...

 

1 час назад, kayot сказал:

Ну или хотя бы igb-драйвер руками соберите свежий, i210 же на нем?

скорее e1000e. i210/211 - наследник 82574.

[GrandPr1de]

2 часа назад, NiTr0 сказал:

с какой это радости?

потому что кто-то не в курсе про i350

[Ivan_83]

ethtool в руки и отключаем фичи на сетевухе, всякие gre, tcp, vlan оффлоады. В вашем случае видимо vlan оффлоад точно, по остальным фичам лучше поискать тут на форуме, я точный сипсок не помню того что для роутера вредно.

[AlKov]

10 часов назад, Ivan_83 сказал:

ethtool в руки и отключаем фичи на сетевухе, всякие gre, tcp, vlan оффлоады. В вашем случае видимо vlan оффлоад точно, по остальным фичам лучше поискать тут на форуме, я точный сипсок не помню того что для роутера вредно.

Уже проходили.. Не помогает..

А вот на "вредный список" я бы всё же взглянул..

[NiTr0]

В 13.06.2018 в 15:11, GrandPr1de сказал:

потому что кто-то не в курсе про i350

ну пока их не щупал, да и как вышли - были сырыми (то ли дрова то ли железо).

 

а 82576 - они стоят копейки, продаются на каждом углу, и работают без нареканий. а что еще надо для исключения железных проблем?

 

можно было бы конечно и 82571 насоветовать, но они горячее.

[AlKov]

16 минут назад, NiTr0 сказал:

а 82576 - они стоят копейки, продаются на каждом углу, и работают без нареканий. а что еще надо для исключения железных проблем?

Ну про то, что работают без проблем - "за" двумя руками, а вот насчёт "копеек" и "на каждом углу" - готов поспорить.

Причём по обоим "пунктам".

Заказал три дня тому.. Нашлось только в одном месте и за 11500 руб. Это ежли шо, 1 150 000 копеек однако.. ;)

 

P.S. Ну и ближе к теме немного - мне почему-то больше думается, что причина живёт всё же где-то в accel, а не в железе/ОС.

Т.к. ещё раз повторюсь, в логах ОС пусто, от слова "совсем" и по ощущениям всё выглядит так, как будто кто-то выполнил команду "ifconfig eth0 down".

Плюс ко всему, похожая проблема уже была, но там accel загонял в down только конкретный vlan интерфейс. И она (проблема) подтверждалась на явно другом железе и возможно другой ОС.

Либо в моём случае имеет место какая-то программная "нестыковка" accel с ядром/ОС/драйвером сетевухи..

Больше всего в данном случае напрягает неизвестность причины проблемы - что такое может прилететь от клиентов/коммутаторов, чтобы нагнать такого страху на работающий софт..

[AlKov]

"Мнения разделились".. Причём, мои собственные.. :) 

Похоже, I210 действительно "дешманское г..."

Нагуглил очень близкую к моей тему, где в итоге обнаружилось следующее

Цитата

причина: первый ehternet интерфейс на этой материнке идет на прямую от чипсета–проца (soc n3700) – согласно схемы официального мануала материнской платы, а другие 3 интерфейса идут от проца к так называемому Pericom Semiconductor Device, а дальше уже распределяются на три ehternet контролера и mPCI. 

Отсюда можно сделать вывод, что...

В 13.06.2018 в 11:03, kayot сказал:

1. PCIe живет в процессоре еще со времен выхода архитектуры sandy bridge, совсем ничего странного. И никакой разницы нет, распаян сетевой чип на материнке или стоит в слоте.

.. далеко не факт...

Конечно, у автора другая материнка (супермикро какая-то), а у меня Intel S1200SPOR, но вряд ли архитектура сильно отличается.

Учитывая всё вышесказанное про ethernet на процессоре, не факт что 82576 решит проблему..

Но выбора нет.. Карту заказал, жду в конце этой недели..

 

P.S. @kayot , кстати, у Вас какие сетевые карты используются? 

 

P.P.S. Ещё одна необъяснимая фигня - пока не приехала 82576, решил апдейтнуть драйвер.

Захожу на intel download и вижу следующее..

Цитата

 

The igb-x.x.x.tag.gz is designed to work with Intel® 82575/6, 82580, I350, and I210/211-based Adapters/Connections under Linux*. The latest version and earlier versions of this driver are available from SourceForge*.

If your Intel® Network Adapter/Connection is not 82575/6, 82580, or I350-based, you should use one of the following drivers:

e1000e-x.x.x.x.tar.gz driver supports the Intel® PRO/1000 PCI-E* (82563/6/7, 82571/2/3/4/7/8, or 82583) based Gigabit Network Adapters

e1000.x.x.x.tar.gz support all PCI and PCI-X Intel® Gigabit Network Adapters/Connections
 

 

Интересно, и как это понимать?? Какое-то прям "вам шашечки, или ехать"!

[kayot]

4 минуты назад, AlKov сказал:

.. далеко не факт...

Факт. В той теме какая-то супер-компактная мать на атоме, pci-e линий недостаточно(даже pci-e слот физически 8х а реально 1х) и стоит коммутатор для подключения 4ех сетевок.

В вашей же плате и проце 20 линий, все подключено независимо напрямую к CPU.

 

8 минут назад, AlKov сказал:

кстати, у Вас какие сетевые карты используются?

На одном сервере 2х i340-t4(итого 8 портов в бондах) на 82580, на втором вообще бортовые броадкомы HPшного сервера вперемешку с внешней ET 82576. Ничего не отваливается.

[NiTr0]

2 часа назад, kayot сказал:

В вашей же плате и проце 20 линий, все подключено независимо напрямую к CPU.

а не факт к слову, обычно pci-e x1 2.0 и прочие набортные девайсы заводятся на южный мост (pch который).

 

таки да, угадал - интегрированные сетевки традиционно на линиях ЮМ висят: https://www.intel.com/content/dam/support/us/en/documents/server-products/S1200SP_TPS_AllSKU.PDF

не, в принципе не критично и почти ни на что не влияет, но все же...

[AlKov]

3 часа назад, NiTr0 сказал:

а не факт к слову, обычно pci-e x1 2.0 и прочие набортные девайсы заводятся на южный мост (pch который).

Вот и у меня такие же ощущения.. Остаётся только надеяться, что они ошибочны.

 

И Вы 100% правы насчёт

В 13.06.2018 в 12:59, NiTr0 сказал:

скорее e1000e. i210/211 - наследник 82574.

Вот только сейчас удосужился полистать даташит на i210.. А в нём аглицким по белому -

Цитата

Intel® 82574_82583 Gigabit Ethernet Controller to I210_I211 – Design Guide

И это называется "полный писец".. Обидно, что узнал об этом только сейчас..

Когда-то уже обжигался на 82574 -  это было нЕчто, как это дерьмо себя вело на сети!

Мда... Так глупо наступить на грабли молодости... :(

 

P.S. Вот ещё что нагуглилось в "связке" 82574 и отключение интерфейса.

Не особо верится, конечно, но.. Уж очень удачное совпадение двух - вернее даже трёх - "параметров".

[NiTr0]

В 18.06.2018 в 14:35, AlKov сказал:

Вот и у меня такие же ощущения.. Остаётся только надеяться, что они ошибочны.

не ошибочны, в ДШ есть схема.

 

в принципе пофиг, где контроллер висит, пока ширины DMI хватает.

 

В 18.06.2018 в 14:35, AlKov сказал:

Когда-то уже обжигался на 82574 -  это было нЕчто, как это дерьмо себя вело на сети!

да нормально они себя ведут, даже на брасах с 600-700 мбитами трафика. свои деньги отрабатывают, с рылтеками и прочими аферосами не сравнятся.

но учитывая цену 82576 - экономить на спичках не стоит. https://www.ebay.com/itm/Intel-82576EB-Dual-RJ45-Port-E1G42ET-PCI-E-X1-Gigabit-Server-Adapter-ROS-VMare/273085452445 или https://www.ebay.com/itm/Dual-Port-PCI-EX4-1Gbps-Intel-82576EB-E1G42ET-EF-E1G44ET-Gigabit-Server-Adapter/263753128226 с с шиной х4 (хотя там и х1 2.0 должно хватить с головой)

 

да, фирменный интел (или подделка под него) - немногим дороже https://www.ebay.com/itm/NEW-Dual-Port-PCI-EX4-Intel82576-E1G42ET-PRO-10-100-1000M-Server-Adapter/172175117383

[rm_]

По-моему вас не туда понесло, автор прав, если в dmesg пусто - проблема абсолютно точно не аппаратная.

[AlKov]

8 часов назад, NiTr0 сказал:

да нормально они себя ведут, даже на брасах с 600-700 мбитами трафика.

Ага, я тоже так думал (про I210) до некоторых пор.  И действительно, на двух серверах (Border/NAT) к ним (I210) у меня претензий никаких не было.

До того момента, пока они не оказались на L2 доступе (текущая тема).

Вот тут-то это г.. и всплыло..

Ну а насчёт конкретно 82574, "былин" хватает, кроме моих.

раз

два

три

Ну и ещё встречались "баллады" на "нерусских матах". 

Эх.. Если бы я удосужился внимательно прочесть даташит на I210, то даже бы и мысли не возникло пытаться их использовать.

 

Вот, пока писал, вспомнил свою последнюю "былину" про 82574 - периодически - раза два в месяц - вставал колом сервак на супермикре FreeBSD/mpd5/PPPoE (да-да, тот самый "L2 доступ").

Выглядело это вообще "красиво" - находясь в ступоре, железка реагировала только на кнопку "power", ни сеть, ни клаву не признавала.

На "борту" - как это всегда бывает в супер-пупер-микрах - великолепный винегрет - две РАЗНЫЕ сетевухи - 82574/82579.

Совсем немного задумался (т.к. сексуальный опыт с 82574 уже имелся).. И... Поставил 82576 и забыл про железку.

 

8 минут назад, rm_ сказал:

По-моему вас не туда понесло, автор прав, если в dmesg пусто - проблема абсолютно точно не аппаратная.

Если под "автором" подразумевается моя персона, то я уже так не думаю (см. выше). :-)