adron2 Опубликовано 5 июля, 2012 (изменено) · Жалоба Здравствуйте. Есть непонятная проблема: Сетевуха: Intel Corporation 82574L Gigabit Network Connection Смущает наличие dropped:94532 Причем потерь траффика нет. Нагрузка порядка 150 мегабит. Но даже если нагрузку вообще снять то все равно 5-10 dropped за секунду накапливается. В принципе не мешает но просто интересно ) Ядро 3.4.4 driver: e1000e version: 2.0.0-NAPI firmware-version: 2.1-2 bus-info: 0000:02:00.0 eth0 Link encap:Ethernet HWaddr 00:25:90:70:2C:36 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:626317792 errors:61 dropped:94532 overruns:0 frame:61 TX packets:625476654 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:467447963513 (445793.1 Mb) TX bytes:469054198372 (447324.9 Mb) Interrupt:16 Memory:fba00000-fba20000 NIC statistics: rx_packets: 628572435 tx_packets: 627731197 rx_bytes: 469081948299 tx_bytes: 470693246407 rx_broadcast: 403503 tx_broadcast: 1779 rx_multicast: 119376 tx_multicast: 0 rx_errors: 61 tx_errors: 0 tx_dropped: 0 multicast: 119376 collisions: 0 rx_length_errors: 61 rx_over_errors: 0 rx_crc_errors: 0 rx_frame_errors: 0 rx_no_buffer_count: 0 rx_missed_errors: 0 tx_aborted_errors: 0 tx_carrier_errors: 0 tx_fifo_errors: 0 tx_heartbeat_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 tx_restart_queue: 0 rx_long_length_errors: 0 rx_short_length_errors: 61 rx_align_errors: 0 tx_tcp_seg_good: 134 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: 469081948299 rx_csum_offload_good: 318877167 rx_csum_offload_errors: 992 rx_header_split: 0 alloc_rx_buff_failed: 0 tx_smbus: 0 rx_smbus: 478571 dropped_smbus: 0 rx_dma_failed: 0 tx_dma_failed: 0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off rx-vlan-offload: on tx-vlan-offload: on ntuple-filters: off receive-hashing: on Есть предположение что какие то пакеты прилетают с сети которые не нравятся сетевухе и она их дропает. Но подтверждения пока не нашел. Изменено 5 июля, 2012 пользователем adron2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 5 июля, 2012 (изменено) · Жалоба наблюдал тоже самое - тоже никак не мешало (процент дропов 0,05%) Заменил на i82576 - дропов нуль.. Изменено 5 июля, 2012 пользователем white_crow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
passer Опубликовано 5 июля, 2012 · Жалоба А это не может быть трафик какого-то vlan'а построннего приблудившегося на порт или что-то что генерит сам свитч (CDP и т.п.) ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 5 июля, 2012 · Жалоба А это не может быть трафик какого-то vlan'а построннего приблудившегося на порт или что-то что генерит сам свитч (CDP и т.п.) ? Вот я тоже на это думаю. Свитч не мой. Так что понятия не имею как оно настроено. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 5 июля, 2012 · Жалоба Драйвер сетевой карты считает - что этот трафик не нужен Как узнать - что это за трафик - не представляю (до снифера он, видимо не дойдет....) Хотя меняешь сетевуху - и вдруг дропов = 0. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 5 июля, 2012 · Жалоба Драйвер сетевой карты считает - что этот трафик не нужен Как узнать - что это за трафик - не представляю (до снифера он, видимо не дойдет....) Хотя меняешь сетевуху - и вдруг дропов = 0. Вот вот. Очень умный драйвер ))) сам решает что дропать а что нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 5 июля, 2012 · Жалоба А вы в этот момент tcpdump запускали? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 5 июля, 2012 · Жалоба Вроде, с некоторого ядра в дропы попадают вылидные пакеты, которые не обработаны ядром - вроде неизвестных протоколов. еще ссылка: http://sourceforge.net/projects/e1000/files/e1000e%20stable/eeprom_fix_82574_or_82583/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 6 июля, 2012 (изменено) · Жалоба А вы в этот момент tcpdump запускали? Странно но когда запускаещь tcpdump дропы пропадают ) Изменено 6 июля, 2012 пользователем adron2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 6 июля, 2012 · Жалоба чудеса с e1000e продолжаются. У меня модуль в ядре который вызывает ip_local_out для отправки skb. Так вот сегодня с утра вылезла проблема. ip_local_out начал возвращать 1 вместо как положено 0. То есть ошибка. Причем эпизодически. Ни ошибок в статистике сетевухи на передачу при этом нет. Причем баг вылазил когда траффика совсем мало. Стоит нагрузить хотябы до 20 мегабит и все. Бага нет. Вылечил откатом на 1.9.5-k(родной драйвер для ядра 3.4.4). До этого стоял последний с сайта интеля version: 2.0.0-NAPI Что бы это могло быть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bel Опубликовано 6 июля, 2012 · Жалоба А вы в этот момент tcpdump запускали? Странно но когда запускаещь tcpdump дропы пропадают ) Если tcpdump запустакть без опции -p, то сетевая карта переводится в прозрачный режим (promiscuous), в котором она принимает все пакеты. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 6 июля, 2012 (изменено) · Жалоба да, я знал это : ) Я имеюю ввиду - что там тысячи пакетов полезных и 0,05% , которые типа "дропнуты" - как определить эти особенные пакеты среди всех дампнутых, я не знаю.. Изменено 6 июля, 2012 пользователем white_crow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bel Опубликовано 6 июля, 2012 (изменено) · Жалоба да, я знал это : ) Я имеюю ввиду - что там тысячи пакетов полезных и 0,05% , которые типа "дропнуты" - как определить эти особенные пакеты среди всех дампнутых, я не знаю.. Сделайте два дампа пакетов: в обычном и прозрачном режимах. Проанализируйте полученные дампы. Обратите внимание на другие протоколы и другие MAC адреса назначения. Изменено 6 июля, 2012 пользователем bel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 6 июля, 2012 (изменено) · Жалоба да, я знал это : ) Я имеюю ввиду - что там тысячи пакетов полезных и 0,05% , которые типа "дропнуты" - как определить эти особенные пакеты среди всех дампнутых, я не знаю.. Сделайте два дампа пакетов: в обычном и прозрачном режимах. Проанализируйте полученные дампы. Обратите внимание на другие протоколы и другие MAC адреса назначения. tcpdump -i eth0 -n -e -p И дропы пропадают. То есть уже что то конкретное есть. Что пакеты которые не нравятся e1000e адресованы на мак eth0 либо они броадкасты. Видимо как тут уже писали это просто пакет с неизвестным ядру протоколом. Что то из вот этого видимо: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 09:43:52.177887 00:15:5d:83:5a:2a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 91.197.131.27.137 > 91.197.131.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 09:43:52.508466 00:30:48:d6:8a:f5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.222.64.68 tell 91.222.64.1, length 46 09:43:52.623063 00:15:5d:83:5a:29 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 154: fe80::3dbf:e4db:67e7:b4f0.546 > ff02::1:2.547: dhcp6 solicit 09:43:52.673456 00:15:5d:06:42:27 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 150: fe80::6154:67c3:4275:685f.546 > ff02::1:2.547: dhcp6 solicit 09:43:52.821831 00:15:5d:83:5a:32 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 150: fe80::f0a3:f12d:7780:b285.546 > ff02::1:2.547: dhcp6 solicit 09:43:52.866410 00:16:d4:b1:86:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 93.171.240.95 tell 93.171.240.90, length 46 09:43:52.981414 00:16:d4:b1:86:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 93.171.240.56 tell 93.171.240.90, length 46 09:43:52.981420 c8:3a:35:3e:db:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 93.171.240.56 tell 93.171.240.14, length 46 09:43:53.043426 00:16:d4:b1:86:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 93.171.240.95 tell 93.171.240.90, length 46 09:43:53.090379 00:16:d4:b1:86:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 93.171.240.106 tell 93.171.240.90, length 46 09:43:53.090383 c8:3a:35:3e:db:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 93.171.240.106 tell 93.171.240.14, length 46 09:43:53.099774 00:30:48:d6:8a:f5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.222.64.190 tell 91.222.64.1, length 46 09:43:53.309704 00:30:48:f6:38:14 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.16.32.254 tell 172.16.32.17, length 46 09:43:53.363672 00:24:73:94:b3:92 > 01:80:c2:00:00:00, 802.3, length 64: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1w, Rapid STP, Flags [Forward], bridge-id 8000.00:24:73:94:b3:90.8001, length 47 09:43:53.536255 00:30:48:d6:8a:f5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.222.64.68 tell 91.222.64.1, length 46 09:43:53.655556 00:30:48:d6:8a:f5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.197.131.73 tell 91.197.131.1, length 46 09:43:53.675414 c8:3a:35:3e:db:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 93.171.240.20 tell 93.171.240.14, length 46 09:43:53.675416 00:16:d4:b1:86:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 93.171.240.20 tell 93.171.240.90, length 46 09:43:53.727711 00:30:48:d6:8a:f5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 146.120.90.101 tell 146.120.90.1, length 46 09:43:53.889734 00:30:48:d6:8a:f5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.222.64.190 tell 91.222.64.1, length 46 09:43:53.904799 00:30:48:d6:8a:f5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.197.131.79 tell 91.197.131.1, length 46 09:43:53.931065 b8:62:1f:50:34:35 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 93.171.242.1 tell 93.171.242.5, length 46 09:43:54.309684 00:30:48:f6:38:14 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.16.32.254 tell 172.16.32.17, length 46 09:43:54.317945 00:15:5d:83:5a:2a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.197.131.33 tell 91.197.131.27, length 46 09:43:54.499652 00:30:48:d6:8a:f5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.222.64.68 tell 91.222.64.1, length 46 09:43:54.506399 00:16:d4:b1:86:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 93.171.240.95 tell 93.171.240.90, length 46 09:43:54.560120 00:30:48:f6:36:83 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.16.32.254 tell 172.16.32.16, length 46 09:43:54.602768 00:25:90:70:29:a7 > 01:80:c2:00:00:0e, ethertype LLDP (0x88cc), length 118: LLDP, name (none).(none), length 104 Изменено 6 июля, 2012 пользователем adron2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bel Опубликовано 6 июля, 2012 · Жалоба То есть уже что то конкретное есть. Что пакеты которые не нравятся e1000e адресованы на мак eth0. Для меня это не очивидно. Это могут быть широковещательные или мультикастовые пакеты. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 6 июля, 2012 · Жалоба может кстати это быть ipv6 броадкаст пакеты. ipv6 я в ядре напрочь вырубил. И могу предположить что при получении таких пакетов может крутиться счетчик дропов. То есть уже что то конкретное есть. Что пакеты которые не нравятся e1000e адресованы на мак eth0. Для меня это не очивидно. Это могут быть широковещательные или мультикастовые пакеты. Да вы правы. Я тоже подумал про широковещательные или мультикастовые пакеты просто вы меня опередили своим постом ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 6 июля, 2012 · Жалоба В общем убрали проблему с дропами. Написал админу каталиста в который воткнута моя сетевуха. Попросил отдавать порт транком без нативного влана. После этого дропов стало 3 штуки за секуннду вместо 20-30. Дальше попросил выключить stp. И все. Дропы пропали. То есть как и предполагалось - дропы из за странных(неправильных) пакетов поступающих на сетевуху. Всем спасибо за помощь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 6 июля, 2012 · Жалоба Попросил отдавать порт транком без нативного влана. Чот туплю... а это разве возможно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bel Опубликовано 6 июля, 2012 · Жалоба adron2, что-то у Вас ARP запросы из разных подсетей. Это нормально? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 6 июля, 2012 · Жалоба У меня десктопный гигабит почему то tcp ack в влане начал считать плохими и дропал, пере посылка асков помогала, но удовольствия мало. Странно но когда запускаещь tcpdump дропы пропадают ) Это говорит о том, что отбрасываемые пакеты не мультикаст/броадкаст и не с вашим маком. Те там не ваш дст мак, и они почему то к вам долетели. Может быть с вланами что то, но далеко не факт что драйвер сетевухи озаботился настройкой аппаратного фильтра для вланов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bel Опубликовано 6 июля, 2012 · Жалоба У меня десктопный гигабит почему то tcp ack в влане начал считать плохими и дропал, пере посылка асков помогала, но удовольствия мало. TCP Offload было включено? Отключение TCP Offload помогало? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 6 июля, 2012 · Жалоба Ничего не помогало. Отпахала два года в домашнем серваке. Разницы относительно встроенного рт8111 не заметил, почти. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
passer Опубликовано 7 июля, 2012 · Жалоба далеко не факт что драйвер сетевухи озаботился настройкой аппаратного фильтра для вланов. Тем не менее, у меня с 574L в логах случается:[ 29.224058] 8021q: adding VLAN 0 to HW filter on device eth0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 12 июля, 2012 · Жалоба еще вот от этого дропает : Раз в минуту(четко каждые 60 секунд) прилетает вот такой пакет: 14:20:00.277863 00:24:73:94:b3:92 > 01:80:c2:00:00:0a, ethertype Unknown (0x88a7), length 190: 0x0000: 0003 0000 01b4 2217 0001 000e 0000 0000 ......"......... 0x0010: 0024 7394 b390 0007 0026 3343 6f6d 2042 .$s......&3Com.B 0x0020: 6173 656c 696e 6520 5377 6974 6368 2032 aseline.Switch.2 0x0030: 3932 382d 5346 5020 506c 7573 000e 0018 928-SFP.Plus.... 0x0040: 352e 3230 2052 656c 6561 7365 2031 3130 5.20.Release.110 0x0050: 3150 3032 0011 0017 5631 3030 5230 3031 1P02....V100R001 0x0060: 4230 3244 3030 3553 5030 3500 1000 0820 B02D005SP05..... 0x0070: 3131 3300 0c00 1411 0000 0000 0000 0000 113............. 0x0080: 0000 0000 0000 0000 0300 0b6e 742d 7377 ...........nt-sw 0x0090: 2d31 0002 0018 4769 6761 6269 7445 7468 -1....GigabitEth 0x00a0: 6572 6e65 7431 2f30 2f31 000b 0006 0003 ernet1/0/1...... Никто случаем не знает как на свитче выключить эту хрень? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 12 июля, 2012 · Жалоба Ищи "кластер" или близкое по смыслу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...