У меня есть сервер, который отображает странное поведение на одном из своих сетевых портов. Кажется, он не может обработать / ответить на любой трафик (пинг и т.д.) Ниже приведено то, что перечислено с использованием 'ifconfig' (назначенный статический адрес 10.100.0.80)

eth0      Link encap:Ethernet  HWaddr 00:18:7D:0E:53:8B
          inet addr:10.100.0.80  Bcast:10.255.255.255  Mask:255.0.0.0
          inet6 addr: fe80::218:7dff:fe0e:538b/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:802 errors:0 dropped:799 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:57099 (55.7 KiB)  TX bytes:2410880 (2.2 MiB)
          Interrupt:16

Там очень большое количество байтов TX. Если этот порт находится непосредственно на другом компьютере, байты TX продолжают быстро увеличиваться, и Wireshark обнаруживает следующее.

Захват проволочной акулы

Единственные пакеты, которые не являются ерундой, являются случайными от моего ноутбука (как пакет 28). Я не уверен, что эти пакеты MAC CTRL или побочный эффект чего-то еще.

FWIW ниже - захват в текстовом формате K12.

+---------+---------------+----------+
14:59:22,793,169   ETHER
|0   |01|80|c2|00|00|01|00|18|7d|0e|53|8b|88|08|00|01|1f|ff|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|

+---------+---------------+----------+
14:59:22,797,366   ETHER
|0   |01|80|c2|00|00|01|00|18|7d|0e|53|8b|88|08|00|01|1f|ff|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|

+---------+---------------+----------+
14:59:22,801,559   ETHER
|0   |01|80|c2|00|00|01|00|18|7d|0e|53|8b|88|08|00|01|1f|ff|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|

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

Он делает это как с установленной ОС CentOS 6.6 (загрузка в однопользовательском режиме и загрузка обычно), так и при загрузке на live CD/USB с использованием CentOS 6.8, поэтому не уверен, что это CentOS 6.Х конкретная проблема, хотя это не сделано до сих пор. Этот же сервер имеет второй порт Ethernet (eth1), который работает нормально.

ETA выводит ethtool в соответствии с рекомендациями grawity, eth0 - неисправный порт

ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Half 1000baseT/Full
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: off
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: yes

ethtool eth1
Settings for eth1:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: No
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: off
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: yes

Там нет ничего, что могло бы быть неправильно? Я посмотрю на кадры паузы с помощью ethtool.

|источник

1 ответ1

0

Кадры "Пауза" иногда используются для управления потоком на уровне Ethernet.

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

Settings for eth0:
        Supported pause frame use: No                       <- what eth0 supports
        Advertised pause frame use: Symmetric               <- what eth0 offers
        Link partner advertised pause frame use: Symmetric  <- what your switch offers

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

Попробуйте отключить это с помощью ethtool -A eth0 rx off tx off. (Это может быть ошибка драйвера или аппаратная проблема; я понятия не имею.) В качестве альтернативы отключите управление потоком на коммутаторе для этого конкретного порта.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .