Pacotes descartados em todos os Linux e Unix

1

Eu tenho um problema. Eu tenho uma placa-mãe da Supermicro - X11SBA-LN4F. Existem 4 portas ethernet. Na primeira porta eu me conecto à internet. Na segunda porta, conecto-me à minha rede local.

Quando escrevo ifconfig ou netstat -i , vejo na minha segunda interface (minha rede local) pacotes descartados. Essa contagem é incrementada

em2       Link encap:Ethernet  HWaddr 0c:c4:7a:7b:91:3e
          inet addr:192.168.110.181  Bcast:192.168.110.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17441 errors:0 dropped:1380 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1226317 (1.2 MB)  TX bytes:0 (0.0 B)

Após minha pesquisa no google, descobri o seguinte: link

Beginning with kernel 2.6.37, it has been changed the meaning of dropped packet count. Before, dropped packets was most likely due to an error. Now, the rx_dropped counter shows statistics for dropped frames because of:

Softnet backlog full  -- (Measured from /proc/net/softnet_stat)
Bad / Unintended VLAN tags
Unknown / Unregistered protocols
IPv6 frames when the server is not configured for IPv6

If any frames meet those conditions, they are dropped before the protocol stack and the rx_dropped counter is incremented.

Primeiro de tudo, eu escrevi este comando:

tcpdump -vv -i em2

Enquanto este comando está em execução, a contagem de pacotes descartados na minha segunda interface é interrompida. Mas, quando eu aborto tcpdump , a contagem de pacotes descartados é incrementada novamente.

  • desativei o IPv6
  • Eu verifiquei todas as VLANs. Na porta tenho apenas uma VLAN Untag na rede local
  • Eu verifiquei o arquivo /proc/net/softnet_stat . Nesse arquivo eu tenho informações apenas da primeira coluna e isso é bom

    00000013 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00002fbc 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000f3 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000268f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  • Analisei por "tcpdump" todo o tráfego. Eu tenho apenas - ARP Request, Broadcats and Rip. E não é ruim

  • habilitei o modo promíscuo, mas isso não ajudou
  • verifiquei cabos e conectores
  • eu instalo o driver mais recente
  • Eu aumentei o tamanho dos caches de anel, mas isso não ajudou
  • E eu verifiquei todos os Unix e Linux: Zeroshell, Pfense, FreeBsd, Ubuntu Server (com kernel nativo & compilado por mim), CentOS (com kernel nativo & compilado por mim). Todos mostraram os mesmos sintomas.

    ethtool -i em2
    
    driver: igb
    version: 5.3.4.4
    firmware-version: 3.25, 0x800005d0
    bus-info: 0000:06:00.0
    supports-statistics: yes
    supports-test: yes
    supports-eeprom-access: yes
    supports-register-dump: yes
    supports-priv-flags: no
    

Todas as estatísticas nessa interface:

ethtool -S em2

NIC statistics:
     rx_packets: 29675
     tx_packets: 0
     rx_bytes: 2208735
     tx_bytes: 0
     rx_broadcast: 29636
     tx_broadcast: 0
     rx_multicast: 39
     tx_multicast: 0
     multicast: 39
     collisions: 0
     rx_crc_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 0
     tx_aborted_errors: 0
     tx_carrier_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
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 0
     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: 2208735
     tx_dma_out_of_sync: 0
     lro_aggregated: 0
     lro_flushed: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus: 0
     os2bmc_rx_by_bmc: 0
     os2bmc_tx_by_bmc: 0
     os2bmc_tx_by_host: 0
     os2bmc_rx_by_host: 0
     tx_hwtstamp_timeouts: 0
     rx_hwtstamp_cleared: 0
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_frame_errors: 0
     rx_fifo_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_queue_0_packets: 0
     tx_queue_0_bytes: 0
     tx_queue_0_restart: 0
     rx_queue_0_packets: 29675
     rx_queue_0_bytes: 2090035
     rx_queue_0_drops: 0
     rx_queue_0_csum_err: 0
     rx_queue_0_alloc_failed: 0

Onde está o meu problema? Por favor me ajude.

 ifconfig em2; ethtool -S em2


em2       Link encap:Ethernet  HWaddr 0c:c4:7a:7b:91:3e
          inet addr:192.168.110.181  Bcast:192.168.110.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15387 errors:0 dropped:1224 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1085031 (1.0 MB)  TX bytes:0 (0.0 B)

NIC statistics:
     rx_packets: 15387
     tx_packets: 0
     rx_bytes: 1146579
     tx_bytes: 0
     rx_broadcast: 15367
     tx_broadcast: 0
     rx_multicast: 20
     tx_multicast: 0
     multicast: 20
     collisions: 0
     rx_crc_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 0
     tx_aborted_errors: 0
     tx_carrier_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
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 0
     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: 1146579
     tx_dma_out_of_sync: 0
     lro_aggregated: 0
     lro_flushed: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus: 0
     os2bmc_rx_by_bmc: 0
     os2bmc_tx_by_bmc: 0
     os2bmc_tx_by_host: 0
     os2bmc_rx_by_host: 0
     tx_hwtstamp_timeouts: 0
     rx_hwtstamp_cleared: 0
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_frame_errors: 0
     rx_fifo_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_queue_0_packets: 0
     tx_queue_0_bytes: 0
     tx_queue_0_restart: 0
     rx_queue_0_packets: 15387
     rx_queue_0_bytes: 1085031
     rx_queue_0_drops: 0
     rx_queue_0_csum_err: 0
     rx_queue_0_alloc_failed: 0
    
por Valeriu 01.06.2016 / 09:26

1 resposta

2

Provavelmente, o que está acontecendo é que você está vendo o tráfego de broadcast do IPv6 na sua sub-rede, de acordo com o que você postou de uma saída do tcpdump aqui:

12:19:41.622297 IP6 (hlim 1, next-header UDP (17) payload length: 112) fe80::a4a0:460b:c99a:c992.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=455863 (elapsed-time 700) (client-ID hwaddr/time type 1 time 495735714 e03f49b54e07) (IA_NA IAID:65027913 T1:0 T2:0) (Client-FQDN) (vendor-class) (option-request vendor-specific-info DNS-server DNS-search-list Client-FQDN))

E de acordo com o que você escreveu em sua pergunta aqui:

Beginning with kernel 2.6.37, it has been changed the meaning of dropped packet count. Before, dropped packets was most likely due to an error. Now, the rx_dropped counter shows statistics for dropped frames because of:

Softnet backlog full -- (Measured from /proc/net/softnet_stat)

Bad / Unintended VLAN tags

Unknown / Unregistered protocols

IPv6 frames when the server is not configured for IPv6

If any frames meet those conditions, they are dropped before the protocol stack and the rx_dropped counter is incremented.

De sua saída e de sua pergunta, parece que você realmente tem o IPv6 desabilitado no servidor.

Isso me leva à conclusão de que os pacotes descartados que você está vendo provavelmente se devem ao tráfego de broadcast do IPv6 de outros hosts na rede.

Para testar isso, você pode reativar o IPv6 e ver se os pacotes descartados desaparecem. Se o fizerem, isso é inofensivo.

    
por 01.06.2016 / 11:32