Grande número de pacotes “MAC CTRL” - porta de rede defeituosa?

Question

Eu tenho um servidor que exibe um comportamento estranho em uma de suas portas de rede. Parece incapaz de processar / responder a qualquer tráfego (ping etc.). Abaixo está o que está listado usando 'ifconfig' (endereço estático atribuído 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

Existe um grande número de 'bytes TX'. Se esta porta estiver diretamente em outra máquina, os bytes TX continuam a aumentar rapidamente, e o Wireshark pega o seguinte.

Captura do Wireshark

Os únicos pacotes que não são absurdos são os ocasionais do meu laptop (como o pacote 28). Não tenho certeza do que são esses pacotes CTRL MAC ou se isso é um efeito colateral de outra coisa.

FWIW abaixo é a captura no formato de texto 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|

Isso parece ocorrer independentemente da porta ser configurada para obter um endereço DHCP (que não pode ser obtido apesar de estar em uma rede servida por DHCP) ou endereço estático.

Ele está fazendo isso com o sistema operacional instalado do CentOS 6.6 (inicializando como modo de usuário único e inicializando normalmente), e quando iniciado em um CD / USB usando o CentOS 6.8, então não tenho certeza se este é um específico do CentOS 6.X questão, embora não seja feito até agora. Este mesmo servidor tem uma segunda porta Ethernet (eth1) que parece estar operando normalmente.

ETA ethtool outputs como aconselhado por grawity, eth0 é a porta defeituosa

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

Não consegue ver nada que esteja errado? Vou olhar para os quadros de pausa com ethtool.

    

Answer 1

Os quadros "Pausa" às vezes são usados para controle de fluxo em nível de Ethernet.

Você pode ver o uso deles sendo negociado com a velocidade em ethtool . O mais estranho aqui é que eth0 afirma que não suporta pausar quadros, mas oferece seu uso mesmo assim :

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

É claro que a NIC não deve estar enviando quadros de pausa a menos que esteja recebendo muitos dados - e, obviamente, se ela diz que os quadros de pausa não são suportados, realmente não deveriam estar enviando nenhum ...

Tente desativar isso com ethtool -A eth0 rx off tx off . (Pode ser um bug de driver ou um problema de hardware; não tenho ideia.) Como alternativa, desative o controle de fluxo no switch para essa porta específica.