네트워크 인터페이스가 패킷을 삭제하는 이유를 찾는 방법은 무엇입니까?

Linux에서 패킷이 삭제 된 다양한 이유에 대한 통계를 얻는 방법이 있습니까?

여러 서버의 모든 네트워크 인터페이스 (오픈 수세 12.3)에, ifconfig그리고 netstat -i리셉션에서 손실 된 패킷을보고하고있다. 내가 할 때 tcpdump삭제 된 패킷 수의 증가가 중지되어 인터페이스 대기열이 가득 차서 데이터를 삭제하지 않는다는 것을 의미합니다. 따라서 이런 일이 발생하는 다른 이유가 있어야합니다 (예 : 인터페이스가이 멀티 캐스트 그룹의 일부가 아닌 멀티 캐스트 패킷 수신).

그러한 정보는 어디서 찾을 수 있습니까? (/ proc? / sys? 일부 로그?)

통계 예 (/ sys / class / net / <dev> / statistics 및 ethtool 출력 병합) :

alloc_rx_buff_failed: 0
collisions: 0
dropped_smbus: 0
multicast: 1644
rx_align_errors: 0
rx_broadcast: 23626
rx_bytes: 1897203
rx_compressed: 0
rx_crc_errors: 0
rx_csum_offload_errors: 0
rx_csum_offload_good: 0
rx_dropped: 4738
rx_errors: 0
rx_fifo_errors: 0
rx_flow_control_xoff: 0
rx_flow_control_xon: 0
rx_frame_errors: 0
rx_length_errors: 0
rx_long_byte_count: 1998731
rx_long_length_errors: 0
rx_missed_errors: 0
rx_multicast: 1644
rx_no_buffer_count: 0
rx_over_errors: 0
rx_packets: 25382
rx_short_length_errors: 0
rx_smbus: 0
tx_aborted_errors: 0
tx_abort_late_coll: 0
tx_broadcast: 7
tx_bytes: 11300
tx_carrier_errors: 0
tx_compressed: 0
tx_deferred_ok: 0
tx_dropped: 0
tx_errors: 0
tx_fifo_errors: 0
tx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_heartbeat_errors: 0
tx_multicast: 43
tx_multi_coll_ok: 0
tx_packets: 63
tx_restart_queue: 0
tx_single_coll_ok: 0
tx_smbus: 0
tx_tcp_seg_failed: 0
tx_tcp_seg_good: 0
tx_timeout_count: 0
tx_window_errors: 0

시도해보십시오 /sys/class/net/eth0/statistics/ (예 :) eth0, 완벽하지는 않지만 전송 / 수신 및 캐리어, 창, fifo, crc, 프레임, 길이 (및 몇 가지 더 많은) 유형의 오류로 오류를 분류합니다.

드롭은 "무시"와 동일하지 않으며, netstat인터페이스 레벨 통계를 표시합니다. 상위 레벨 (계층 3, IP 스택)에서 무시한 멀티 캐스트 패킷은 드롭으로 표시되지 않습니다 (일부에서는 "필터링 됨"으로 표시 될 수 있음) NIC 통계). 다양한 오프로드 기능으로 인해 통계가 다소 복잡 할 수 있습니다.

다음과 ethtool같은 경우 더 많은 통계를 얻을 수 있습니다 .

# ethtool -S eth0
 rx_packets: 60666755
 tx_packets: 2206194
 rx_bytes: 6630349870
 tx_bytes: 815877983
 rx_broadcast: 58230114
 tx_broadcast: 9307
 rx_multicast: 8406
 tx_multicast: 17
 rx_errors: 0
 tx_errors: 0
 tx_dropped: 0
 multicast: 8406
 collisions: 0
 rx_length_errors: 0
 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
 [...]

일부 통계는 정확한 의미와 마찬가지로 NIC 드라이버에 따라 다릅니다. 위는 인텔에서 온 것 e1000입니다. 소수의 드라이버를 살펴본 결과 일부는 다른 드라이버보다 더 많은 통계를 수집합니다 (ethtool에 사용할 수있는 통계는 예를 들어 drivers/net/ethernet/intel/e1000/e1000_ethtool.crummage해야하는 경우 별도의 소스 파일에 보관되는 경향이 있음 ).

ethtool -i eth0드라이버 세부 정보를 표시 lspci -v하지만 약간의 혼란으로 출력 이 더 자세해야합니다.

업데이트 에서 tg3.c기능을 tg3_rx()가능성에 보이는 것을 한 곳에서만있다 tp->rx_dropped++, 하지만 코드에 산재 해 goto의, 그래서와 명백한 즉, 무엇보다 여러 가지 다른 원인이있을 수 있습니다 goto drop_it 또는 goto drop_it_no_recycle. 드롭 카운터는 드라이버에서 유지 관리하는 몇 안되는 장치 중 하나이며 나머지는 장치 자체에서 유지 관리합니다.

내가 처리해야 할 드라이버 소스는 3.123입니다. 가장 좋은 추측은 다음 코드입니다.

           if (len > (tp->dev->mtu + ETH_HLEN) &&
                skb->protocol != htons(ETH_P_8021Q)) {
                    dev_kfree_skb(skb);
                    goto drop_it_no_recycle;
            }

MTU를 확인하십시오. 가능한 원인은 점보 프레임 또는 캡슐화를 허용하기 위해 약간 큰 이더넷 프레임 입니다. 왜 tcpdump동작을 변경할 수 있는지 설명 할 수 없으며 인터페이스 MTU를 변경하는 것으로 알려져 있지 않습니다. 또한 TSO / LRO 가 활성화 된 tcpdump경우 MTU보다 큰 패킷을 "볼 수 있습니다" ( 설명 ).