จะหาสาเหตุได้อย่างไรว่าทำไมอินเตอร์เฟซเครือข่ายจึงทิ้งแพ็กเก็ต?

มีวิธีใดบ้างใน Linux ที่จะได้รับสถิติเกี่ยวกับสาเหตุต่างๆที่แพ็กเก็ตถูกทิ้ง?

ในอินเทอร์เฟซเครือข่ายทั้งหมด (openSUSE 12.3) บนเซิร์ฟเวอร์หลายเครื่องifconfigและnetstat -iกำลังรายงานแพ็กเก็ตที่ส่งไปที่แผนกต้อนรับ เมื่อฉันทำtcpdumpจำนวนแพ็คเก็ตที่ถูกทิ้งจะหยุดเพิ่มขึ้นซึ่งหมายความว่าคิวการเชื่อมต่อไม่เต็มและทำให้ข้อมูลลดลง ดังนั้นจะต้องมีเหตุผลอื่น ๆ ว่าทำไมสิ่งนี้จึงเกิดขึ้น (เช่นรับ multicast pkts ในขณะที่ส่วนต่อประสานไม่ได้เป็นส่วนหนึ่งของกลุ่ม multicast นี้)

ฉันจะหาข้อมูลดังกล่าวได้จากที่ไหน? (/ proc? / sys? มีบันทึกบ้าง)

ตัวอย่างสถิติ (ผสานของ / sys / class / net / <dev> / สถิติและเอาต์พุต 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.cถ้าคุณต้องการค้นหา)

ethtool -i eth0จะแสดงรายละเอียดไดรเวอร์ผลลัพธ์ของlspci -vควรมีรายละเอียดมากขึ้นแม้ว่าจะมีความยุ่งเหยิงบ้าง

การปรับปรุง ในtg3.cการทำงานtg3_rx()มีเพียงหนึ่งในสถานที่ที่น่าจะมีtp->rx_dropped++, แต่รหัสที่เกลื่อนไปด้วยgotos จึงมีสาเหตุอื่น ๆ อีกหลายกว่าที่เห็นได้ชัดคืออะไรหรือ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 โปรดทราบว่าคุณอาจ "เห็น" แพ็คเก็ตที่มีขนาดใหญ่กว่านั้น MTU ด้วยtcpdumpถ้าเปิดใช้งานTSO / LRO ( คำอธิบาย )