Jump to content
Калькуляторы

dropped и e1000e

Здравствуйте. Есть непонятная проблема:

Сетевуха: 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

 

Есть предположение что какие то пакеты прилетают с сети которые не нравятся сетевухе и она их дропает. Но подтверждения пока не нашел.

Edited by adron2

Share this post


Link to post
Share on other sites

наблюдал тоже самое - тоже никак не мешало (процент дропов 0,05%)

Заменил на i82576 - дропов нуль..

Edited by white_crow

Share this post


Link to post
Share on other sites

А это не может быть трафик какого-то vlan'а построннего приблудившегося на порт или что-то что генерит сам свитч (CDP и т.п.) ?

Share this post


Link to post
Share on other sites

А это не может быть трафик какого-то vlan'а построннего приблудившегося на порт или что-то что генерит сам свитч (CDP и т.п.) ?

 

Вот я тоже на это думаю. Свитч не мой. Так что понятия не имею как оно настроено.

Share this post


Link to post
Share on other sites

Драйвер сетевой карты считает - что этот трафик не нужен

Как узнать - что это за трафик - не представляю (до снифера он, видимо не дойдет....)

Хотя меняешь сетевуху - и вдруг дропов = 0.

Share this post


Link to post
Share on other sites

Драйвер сетевой карты считает - что этот трафик не нужен

Как узнать - что это за трафик - не представляю (до снифера он, видимо не дойдет....)

Хотя меняешь сетевуху - и вдруг дропов = 0.

Вот вот. Очень умный драйвер ))) сам решает что дропать а что нет.

Share this post


Link to post
Share on other sites

Вроде, с некоторого ядра в дропы попадают вылидные пакеты, которые не обработаны ядром - вроде неизвестных протоколов.

 

еще ссылка: http://sourceforge.net/projects/e1000/files/e1000e%20stable/eeprom_fix_82574_or_82583/

Share this post


Link to post
Share on other sites

А вы в этот момент tcpdump запускали?

 

Странно но когда запускаещь tcpdump дропы пропадают )

Edited by adron2

Share this post


Link to post
Share on other sites

чудеса с e1000e продолжаются. У меня модуль в ядре который вызывает ip_local_out для отправки skb. Так вот сегодня с утра вылезла проблема. ip_local_out начал возвращать 1 вместо как положено 0. То есть ошибка. Причем эпизодически. Ни ошибок в статистике сетевухи на передачу при этом нет.

Причем баг вылазил когда траффика совсем мало. Стоит нагрузить хотябы до 20 мегабит и все. Бага нет.

Вылечил откатом на 1.9.5-k(родной драйвер для ядра 3.4.4).

До этого стоял последний с сайта интеля version: 2.0.0-NAPI

Что бы это могло быть?

Share this post


Link to post
Share on other sites

А вы в этот момент tcpdump запускали?

 

Странно но когда запускаещь tcpdump дропы пропадают )

Если tcpdump запустакть без опции -p, то сетевая карта переводится в прозрачный режим (promiscuous), в котором она принимает все пакеты.

Share this post


Link to post
Share on other sites

да, я знал это : )

Я имеюю ввиду - что там тысячи пакетов полезных и 0,05% , которые типа "дропнуты" - как определить эти особенные пакеты среди всех дампнутых, я не знаю..

Edited by white_crow

Share this post


Link to post
Share on other sites

да, я знал это : )

Я имеюю ввиду - что там тысячи пакетов полезных и 0,05% , которые типа "дропнуты" - как определить эти особенные пакеты среди всех дампнутых, я не знаю..

Сделайте два дампа пакетов: в обычном и прозрачном режимах.

Проанализируйте полученные дампы. Обратите внимание на другие протоколы и другие MAC адреса назначения.

Edited by bel

Share this post


Link to post
Share on other sites

да, я знал это : )

Я имеюю ввиду - что там тысячи пакетов полезных и 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

Edited by adron2

Share this post


Link to post
Share on other sites

То есть уже что то конкретное есть. Что пакеты которые не нравятся e1000e адресованы на мак eth0.

Для меня это не очивидно. Это могут быть широковещательные или мультикастовые пакеты.

Share this post


Link to post
Share on other sites

может кстати это быть ipv6 броадкаст пакеты. ipv6 я в ядре напрочь вырубил. И могу предположить что при получении таких пакетов может крутиться счетчик дропов.

 

То есть уже что то конкретное есть. Что пакеты которые не нравятся e1000e адресованы на мак eth0.

Для меня это не очивидно. Это могут быть широковещательные или мультикастовые пакеты.

Да вы правы. Я тоже подумал про широковещательные или мультикастовые пакеты просто вы меня опередили своим постом )

Share this post


Link to post
Share on other sites

В общем убрали проблему с дропами.

Написал админу каталиста в который воткнута моя сетевуха.

Попросил отдавать порт транком без нативного влана. После этого дропов стало 3 штуки за секуннду вместо 20-30.

Дальше попросил выключить stp. И все. Дропы пропали.

То есть как и предполагалось - дропы из за странных(неправильных) пакетов поступающих на сетевуху.

Всем спасибо за помощь.

Share this post


Link to post
Share on other sites

Попросил отдавать порт транком без нативного влана.

 

Чот туплю... а это разве возможно?

Share this post


Link to post
Share on other sites

adron2, что-то у Вас ARP запросы из разных подсетей. Это нормально?

Share this post


Link to post
Share on other sites

У меня десктопный гигабит почему то tcp ack в влане начал считать плохими и дропал, пере посылка асков помогала, но удовольствия мало.

 

Странно но когда запускаещь tcpdump дропы пропадают )

Это говорит о том, что отбрасываемые пакеты не мультикаст/броадкаст и не с вашим маком. Те там не ваш дст мак, и они почему то к вам долетели.

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

Share this post


Link to post
Share on other sites

У меня десктопный гигабит почему то tcp ack в влане начал считать плохими и дропал, пере посылка асков помогала, но удовольствия мало.

TCP Offload было включено?

Отключение TCP Offload помогало?

Share this post


Link to post
Share on other sites

Ничего не помогало. Отпахала два года в домашнем серваке. Разницы относительно встроенного рт8111 не заметил, почти.

Share this post


Link to post
Share on other sites
далеко не факт что драйвер сетевухи озаботился настройкой аппаратного фильтра для вланов.
Тем не менее, у меня с 574L  в логах случается:
[   29.224058] 8021q: adding VLAN 0 to HW filter on device eth0

Share this post


Link to post
Share on other sites

еще вот от этого дропает :

Раз в минуту(четко каждые 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...... 

Никто случаем не знает как на свитче выключить эту хрень?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this