Linux rx length error

ИТ База знаний

Курс по Asterisk

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Ethtool: как изменить скорость, дуплекс и находить неполадки сетевой карты в Linux

Настраиваем дуплексную связь

Конфигурация вашей сетевой карты напрямую влияет, насколько эффективно взаимодействуют ваши сервера.

Онлайн курс по Linux

Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps

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

В этой статье вы узнаете, как изменить настройки скорости, дуплекса и автосогласования в Linux с помощью команд ethtool .

Что такое полудуплекс, полный дуплекс и автосогласование?

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

Когда режим устройства находится в полнодуплексном режиме (Full-duplex), он также может отправлять и получать пакеты одновременно.

Автосогласование (Auto-Negotiation) — это механизм, с помощью которого устройство автоматически выбирает наиболее эффективный режим передачи на основе характеристик своих аналогов. Рекомендуется оставить автосогласование включенным, поскольку оно позволяет устройствам выбирать наиболее эффективные средства для передачи данных.

Что такое дуплексное несоответствие?

Такое происходит когда устройство с включенным автосогласованием подключается к устройству, которое не использует автосогласование. Конец соединения с активным автосогласованием все еще может определить скорость другого конца, но не может правильно определить дуплексный режим. Как правило, конец соединения с автоматическим согласованием будет использовать полудуплекс, тогда как другой конец может быть в дуплексном режиме. Эта ситуация считается дуплексным несоответствием (duplex mismatch).

Несоответствие дуплекса не прекращает связь полностью. Передача отдельных пакетов и небольших объемов данных не вызывают больших проблем. Однако при отправке большого объема данных с любого конца скорость значительно падает. Соединение работает, но производительность снижается, поскольку скорость передачи данных асимметрична и может привести к потере пакетов.

Как использовать команду Ethtool для настройки параметров сетевого адаптера

Ethtool — это команда конфигурации платы сетевого интерфейса, которая позволяет вам получать информацию и изменять настройки сетевого адаптера. Эти настройки включают скорость, дуплекс, автосогласование и многие другие параметры.

Помимо этого, ethtool используется для:

1. Получения идентификационной и диагностической информации
2. Получения расширенной статистики устройства
3. Контроля контрольной суммы
4. Контроля размеров кольца DMA и модерации прерываний
5. Контроля выбора очереди приема для устройств с несколькими очередями
6. Обновления прошивки во флеш-памяти

Для установки ethtool используйте следующие команды:

Чтобы продолжить, вам нужно знать имя вашей сетевой карты.

Чтобы найти имя вашей сетевой карты, введите в командном терминале следующую команду:

Вывод покажет нам имя сетевой карты устройства.

Теперь, когда вы определили имя устройства, проверьте текущие настройки скорости, автосогласования и дуплексного режима с помощью команды: ethtool имя_устройства .

В нашем конкретном примере команда выглядит так:

Выходные данные показывают, что текущая скорость равна 1000 Мбит/с, что дуплекс находится в режиме «Full», и что автосогласование включено.

Изменение настроек сетевого адаптера

Команда ethtool –s может использоваться для изменения текущих настроек путем определения значений скорости speed , дуплекса duplex и автосогласования autoneg в следующем формате:

Например, чтобы установить скорость 1000 Мбит/с, дуплексный режим — «полный», а автоматическое согласование — «включено», команда будет выглядеть так:

Команда ethtool [имя_устройства] необходима для подтверждения того, что изменения были применены.

Сохранение настроек

Изменения, сделанные с помощью Ethtool, по умолчанию отменяются после перезагрузки системы.

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

Добавьте нужные значения в виде строки в конце файла, используя следующий синтаксис:

Сохраните изменения и выйдите из файла.

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

Просмотр статистики интерфейса

Если вы хотите получить статистику о вашей сетевой карте, введите команду:

Вывод этой команды будет выглядеть так:

Использование приведенной выше команды — отличный способ устранения проблем с конкретной сетевой картой.

Физическое расположение конкретного сетевого адаптера

Вот действительно полезный трюк, который предлагает ethtool : допустим у вас есть сервер с несколькими сетевыми картами, и одна из них работает со сбоями, но вы не уверены, какая именно это карта. Вы можете использовать ethtool , чтобы заставить мигать индикатор сетевого адаптера, чтобы определить, какой сетевой адаптер вам нужен. Скажем, если вы хотите мигать светодиодом устройства Ethernet enp0s3 в течение 15 секунд — команда для этого будет выглядеть так:

Светодиод начнет мигать, чтобы вы знали, с какой картой вы имеете дело.

Тестирование сетевой карты

Команда ethtool предлагает пару удобных тестов, которые вы можете запустить на сетевой карте:

1. Online — тесты nvram и тест ссылок
2. Offline — тестирует регистр, память, loopback, прерывание

Давайте запустим онлайн-тест на нашей сетевой карте. Эта команда выглядит так:

После выполнения команда покажет нам результаты:

Учтите, что некоторые устройства не поддерживают offline тестирование.

Информация о драйвере

Чтобы узнать имя драйвера и связанную информацию о драйвере используйте:

Заключение

Следуя этому руководству, вы успешно изменили настройки своей сетевой карты с помощью команд ethtool . Вы также лучше поняли, как режимы автосогласования и дуплекса влияют на производительность сервера. И заодно узнали пару интересных функций команды ethtool .

Мини — курс по виртуализации

Знакомство с VMware vSphere 7 и технологией виртуализации в авторском мини — курсе от Михаила Якобсена

Источник

Dropped packets Linux/Unix на интерфейсе в локальной сети

Добрый день. Существует проблема. Купили материнскую плату – X11SBA-LN4F. Вроде бы прекрасна для организации шлюза доступа в интернет, есть 4 гигабитных порта, BMC для IPMI, потребляет не больше 20 Ватт. На этом плюсы закончились. Ситуация: в первый порт у меня вставлен интернет, во второй локальная сеть. На порту с интернет все нормально, на порту локальной сети, какая-то ерунда. Может проработать день/два и отвалиться линк в локальную сеть, в логах тишина (помогает только рестарт службы). И регулярно я наблюдаю dropped packets в «ifconfig» или «netstat -i» и число этих пакетов регулярно растет.

Сетевая карточка Intel I210-AT

Поиски по решению моей проблемы, привели к этому сайту https://www.novell.com/support/kb/doc.php?id=7007165

Первое, что я сделал, это запустил tcpdump

Самое интересное, что когда я запускаю tcpdump, счетчик дропнутых пакетов не наблюдается. Но когда я останавливаю мониторинг tcpdump, пакеты дропаются опять.

Что я делал: — проверял vlan, у меня кинут на мой проблемный порт нетегированный VLAN и все; — отключал IPv6; — проверял /proc/net/softnet_stat

Как видно значения только в первой колонке, что есть хорошо

— проверял кабеля и коннекторы; — пробовал на разных портах и коммутаторах подымать интерфейс в локальную сеть; — включал promiscuous mode, пакеты все равно дропались; — устанавливал самые последние драйвера; — увеличивал ring caches size; — анализировал tcpdump (там идет ARP, Broadcats, Rip, IPX, IP6); — отключал jumbro frame везде и проверял mtu в tcpdump, не было размера фрейма больше 300; — проверял разные дистрибутивы (Zeroshell, Pfense, FreeBsd, Ubuntu Server (с родным ядром и собранным мною), CentOS (с родным ядром и собранным мною); — прошивал эту материнскую плату на последнюю что есть прошивку; — правил iptables нет вообще!

При чем на нашем другом шлюзе (и на других машинах в сети), через который я сижу и Вам сейчас пишу – все нормально. Подскажите пожалуйста, сижу уже не первую неделю, хочу заставить ее работать. Куда копать ? Может кто-то, если есть время захочет свежим взлядом взглянуть, могу даже доступ SSH дать, только с моим контролем =) Спасибо за Ваше внимание и терпение, что прочитали все это.

Раз сетевуха не говорит об ошибках, значит дропает ядро. посмотри на «netstat -s» — там где-то должны быть ненулевые счетчики ошибок.

Я бы отключит для начала sg gso tso gro lro через «ethtool -K»

Судя по версии драйвера у тебя интеловские драйвера. А с оригинальным драйвером igb из ядра не пробовал (только ядро нужно не 2.6, а что-нибудь свежее типа 3.18/4.4)?

А не пробовал гонять трафик через iperf3 в локалке ? Может проблема проявится более стабильно.

все пробовал

Ядро – 4.2.0-36-generic; Сделал ethtool -K em3 sg off gso off tso off gro off lro off; С оригинальным драйвером из ядра и пробовал; iperf3 прошел тест

в качестве апа

Спасибо за Ваше внимание и терпение, что прочитали все это.

спасибо за нетупую тему на ЛОРе.

гигабитная кароточка

кстати, на машине, где гигабитная карточка, выдает такую интересную картину

добавлю к iperf

кстати, после нескольких запусков iperf я смог вручную «положить» сетевой интерфейс. а не ждать как раньше сутки/двое. в логах есть такое:

а почему оно в режиме 100Mbit? Так и должно быть ?

Интересный рецепт «Please try booting the kernel with the pcie_aspm=off kernel parameter.»

Проблема встречается регулярно, но общего рецепта решения нет.

А в настройках биоса никто не ковырялся ? Нет ли разгона и не используется ли какие-нибудь режимы энергосбережения cpu/chpset ?

bios нет. пробовал

Конечно делал. В Bios ничего такого нет

я один раз столкнулся с проблемой, когда интеловская 10Г сетевушка не инитилась драйвером со странной диагностикой. И только после сброса настройки биоса в начальное состояние она стала работать.

Интересно то, что eth0 работает, а eth1 — глючит. А в чем разница ? Оба подключены на гигабит? Как распределены irq между ядрами? Если eth1 принудительно перевести в 100Мбит, то проявится ли проблема ?

Попробуй (используя iperf3 в режиме udp) постепенно повышать скорость начиная со 100Мбит. Если проблема начнет проявлятся с какой-то скорости, то вероятно это следствие проблемы нехватки производительности (N3700 6W TDP явно не шустрый)

устанавливал самые последние драйвера

1. Самые последние у них (intel) Date: 5/31/2016 — при учете перечисленного вами выше и того что прошло меньше двух дней, может те были еще не самые последние? 🙂
2. Самые последние != самые лучшие, у них там из предыдущих веток еще есть

проверял разные дистрибутивы (Zeroshell, Pfense, FreeBsd, Ubuntu Server (с родным ядром и собранным мною), CentOS (с родным ядром и собранным мною);

Версии дистров пробовали именно те которые «типа» должны работать согласно таблички сайта supermicro ?

проблема локализирована

проблема локализирована. поставив свою локалку в первый порт, и запустив iperf я убедился, что она не падает, даже после минуты теста. переставил свой интернет в порт 2 и запустил тест на iperf уже через внешний ip-адрес – упал через пять секунд.

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

Источник

Interface statistics¶

Overview¶

This document is a guide to Linux network interface statistics.

There are three main sources of interface statistics in Linux:

standard interface statistics based on struct rtnl_link_stats64 ;

protocol-specific statistics; and

driver-defined statistics available via ethtool.

Standard interface statistics¶

There are multiple interfaces to reach the standard statistics. Most commonly used is the ip command from iproute2 :

Note that -s has been specified twice to see all members of struct rtnl_link_stats64 . If -s is specified once the detailed errors won’t be shown.

ip supports JSON formatting via the -j option.

Protocol-specific statistics¶

Protocol-specific statistics are exposed via relevant interfaces, the same interfaces as are used to configure them.

ethtool¶

Ethtool exposes common low-level statistics. All the standard statistics are expected to be maintained by the device, not the driver (as opposed to driver-defined stats described in the next section which mix software and hardware stats). For devices which contain unmanaged switches (e.g. legacy SR-IOV or multi-host NICs) the events counted may not pertain exclusively to the packets destined to the local host interface. In other words the events may be counted at the network port (MAC/PHY blocks) without separation for different host side (PCIe) devices. Such ambiguity must not be present when internal switch is managed by Linux (so called switchdev mode for NICs).

Standard ethtool statistics can be accessed via the interfaces used for configuration. For example ethtool interface used to configure pause frames can report corresponding hardware counters:

General Ethernet statistics not associated with any particular functionality are exposed via ethtool -S $ifc by specifying the —groups parameter:

Driver-defined statistics¶

Driver-defined ethtool statistics can be dumped using ethtool -S $ifc , e.g.:

uAPIs¶

procfs¶

The historical /proc/net/dev text interface gives access to the list of interfaces as well as their statistics.

Note that even though this interface is using struct rtnl_link_stats64 internally it combines some of the fields.

sysfs¶

Each device directory in sysfs contains a statistics directory (e.g. /sys/class/net/lo/statistics/ ) with files corresponding to members of struct rtnl_link_stats64 .

This simple interface is convenient especially in constrained/embedded environments without access to tools. However, it’s inefficient when reading multiple stats as it internally performs a full dump of struct rtnl_link_stats64 and reports only the stat corresponding to the accessed file.

Sysfs files are documented in Documentation/ABI/testing/sysfs-class-net-statistics .

netlink¶

rtnetlink ( NETLINK_ROUTE ) is the preferred method of accessing struct rtnl_link_stats64 stats.

Statistics are reported both in the responses to link information requests ( RTM_GETLINK ) and statistic requests ( RTM_GETSTATS , when IFLA_STATS_LINK_64 bit is set in the .filter_mask of the request).

ethtool¶

Ethtool IOCTL interface allows drivers to report implementation specific statistics. Historically it has also been used to report statistics for which other APIs did not exist, like per-device-queue statistics, or standard-based statistics (e.g. RFC 2863).

Statistics and their string identifiers are retrieved separately. Identifiers via ETHTOOL_GSTRINGS with string_set set to ETH_SS_STATS , and values via ETHTOOL_GSTATS . User space should use ETHTOOL_GDRVINFO to retrieve the number of statistics ( .n_stats ).

ethtool-netlink¶

Ethtool netlink is a replacement for the older IOCTL interface.

Protocol-related statistics can be requested in get commands by setting the ETHTOOL_FLAG_STATS flag in ETHTOOL_A_HEADER_FLAGS . Currently statistics are supported in the following commands:

debugfs¶

Some drivers expose extra statistics via debugfs .

struct rtnl_link_stats64В¶

The main device statistics structure.

Definition

Members

Number of good packets received by the interface. For hardware interfaces counts all good packets received from the device by the host, including packets which host had to drop at various stages of processing (even in the driver).

Number of packets successfully transmitted. For hardware interfaces counts packets which host was able to successfully hand over to the device, which does not necessarily mean that packets had been successfully transmitted out of the device, only that device acknowledged it copied them out of host memory.

Number of good received bytes, corresponding to rx_packets.

For IEEE 802.3 devices should count the length of Ethernet Frames excluding the FCS.

Number of good transmitted bytes, corresponding to tx_packets.

For IEEE 802.3 devices should count the length of Ethernet Frames excluding the FCS.

Total number of bad packets received on this network device. This counter must include events counted by rx_length_errors, rx_crc_errors, rx_frame_errors and other errors not otherwise counted.

Total number of transmit problems. This counter must include events counter by tx_aborted_errors, tx_carrier_errors, tx_fifo_errors, tx_heartbeat_errors, tx_window_errors and other errors not otherwise counted.

Number of packets received but not processed, e.g. due to lack of resources or unsupported protocol. For hardware interfaces this counter may include packets discarded due to L2 address filtering but should not include packets dropped by the device due to buffer exhaustion which are counted separately in rx_missed_errors (since procfs folds those two counters together).

Number of packets dropped on their way to transmission, e.g. due to lack of resources.

Multicast packets received. For hardware interfaces this statistic is commonly calculated at the device level (unlike rx_packets) and therefore may include packets which did not reach the host.

For IEEE 802.3 devices this counter may be equivalent to:

Number of collisions during packet transmissions.

Number of packets dropped due to invalid length. Part of aggregate “frame” errors in /proc/net/dev .

For IEEE 802.3 devices this counter should be equivalent to a sum of the following attributes:

Receiver FIFO overflow event counter.

Historically the count of overflow events. Such events may be reported in the receive descriptors or via interrupts, and may not correspond one-to-one with dropped packets.

The recommended interpretation for high speed interfaces is — number of packets dropped because they did not fit into buffers provided by the host, e.g. packets larger than MTU or next buffer in the ring was not available for a scatter transfer.

Part of aggregate “frame” errors in /proc/net/dev .

This statistics was historically used interchangeably with rx_fifo_errors.

This statistic corresponds to hardware events and is not commonly used on software devices.

Number of packets received with a CRC error. Part of aggregate “frame” errors in /proc/net/dev .

For IEEE 802.3 devices this counter must be equivalent to:

Receiver frame alignment errors. Part of aggregate “frame” errors in /proc/net/dev .

For IEEE 802.3 devices this counter should be equivalent to:

Receiver FIFO error counter.

Historically the count of overflow events. Those events may be reported in the receive descriptors or via interrupts, and may not correspond one-to-one with dropped packets.

This statistics was used interchangeably with rx_over_errors. Not recommended for use in drivers for high speed interfaces.

This statistic is used on software devices, e.g. to count software packet queue overflow (can) or sequencing errors (GRE).

Count of packets missed by the host. Folded into the “drop” counter in /proc/net/dev .

Counts number of packets dropped by the device due to lack of buffer space. This usually indicates that the host interface is slower than the network interface, or host is not keeping up with the receive packet rate.

This statistic corresponds to hardware events and is not used on software devices.

Part of aggregate “carrier” errors in /proc/net/dev . For IEEE 802.3 devices capable of half-duplex operation this counter must be equivalent to:

High speed interfaces may use this counter as a general device discard counter.

Number of frame transmission errors due to loss of carrier during transmission. Part of aggregate “carrier” errors in /proc/net/dev .

For IEEE 802.3 devices this counter must be equivalent to:

Number of frame transmission errors due to device FIFO underrun / underflow. This condition occurs when the device begins transmission of a frame but is unable to deliver the entire frame to the transmitter in time for transmission. Part of aggregate “carrier” errors in /proc/net/dev .

Number of Heartbeat / SQE Test errors for old half-duplex Ethernet. Part of aggregate “carrier” errors in /proc/net/dev .

For IEEE 802.3 devices possibly equivalent to:

Number of frame transmission errors due to late collisions (for Ethernet — after the first 64B of transmission). Part of aggregate “carrier” errors in /proc/net/dev .

For IEEE 802.3 devices this counter must be equivalent to:

Number of correctly received compressed packets. This counters is only meaningful for interfaces which support packet compression (e.g. CSLIP, PPP).

Number of transmitted compressed packets. This counters is only meaningful for interfaces which support packet compression (e.g. CSLIP, PPP).

Number of packets received on the interface but dropped by the networking stack because the device is not designated to receive packets (e.g. backup link in a bond).

Notes for driver authors¶

Drivers should report all statistics which have a matching member in struct rtnl_link_stats64 exclusively via .ndo_get_stats64 . Reporting such standard stats via ethtool or debugfs will not be accepted.

Drivers must ensure best possible compliance with struct rtnl_link_stats64 . Please note for example that detailed error statistics must be added into the general rx_error / tx_error counters.

The .ndo_get_stats64 callback can not sleep because of accesses via /proc/net/dev . If driver may sleep when retrieving the statistics from the device it should do so periodically asynchronously and only return a recent copy from .ndo_get_stats64 . Ethtool interrupt coalescing interface allows setting the frequency of refreshing statistics, if needed.

Retrieving ethtool statistics is a multi-syscall process, drivers are advised to keep the number of statistics constant to avoid race conditions with user space trying to read them.

Statistics must persist across routine operations like bringing the interface down and up.

Kernel-internal data structures¶

The following structures are internal to the kernel, their members are translated to netlink attributes when dumped. Drivers must not overwrite the statistics they don’t report with 0.

Источник