कैसे पता करें कि नेटवर्क इंटरफ़ेस पैकेट क्यों छोड़ रहा है?

Question

क्या विभिन्न कारणों के पैकेट गिराए जाने के बारे में आंकड़े प्राप्त करने के लिए लिनक्स पर एक तरीका है?

कई सर्वरों पर सभी नेटवर्क इंटरफेस (ओपनएसयूएसईएस 12.3) पर, ifconfigऔर netstat -iरिसेप्शन पर गिराए गए पैकेट की रिपोर्ट कर रहे हैं। जब मैं एक करता हूं tcpdump, तो गिराए गए पैकेटों की संख्या बढ़नी बंद हो जाती है, जिसका अर्थ है कि इंटरफेस कतारों से भरा नहीं है और डेटा को छोड़ रहा है। तो अन्य कारण भी होने चाहिए कि ऐसा क्यों हो रहा है (उदाहरण के लिए मल्टीकास्ट pkts प्राप्त हुआ, जबकि इंटरफ़ेस इस मल्टीकास्ट समूह का हिस्सा नहीं है)।

मुझे ऐसी जानकारी कहां मिल सकती है? (/ खरीद? / sys? कुछ लॉग?)

आंकड़ों का उदाहरण (/ sys / वर्ग / नेट / <dev> / सांख्यिकी और एथलेट आउटपुट का विलय):

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

Comments

यह भी देखें कि क्या वास्तव में एक ifconfig RX पैकेट है? और कैसे पैकेट गिरा पाया जाए

— मोनिका - एम। श्रोडर

Answer 1

कोशिश करें /sys/class/net/eth0/statistics/ (यानी के लिए eth0), यह सही नहीं है, लेकिन यह त्रुटियों को संचारित / प्राप्त करके और वाहक, खिड़की, पंद्रह, सीआरसी, फ्रेम, लंबाई (और कुछ और) प्रकार की त्रुटियों से टूट जाता है।

ड्रॉप्स "अनदेखा" के समान नहीं हैं, netstatइंटरफ़ेस स्तर के आंकड़े दिखाएं, एक उच्च स्तर (परत 3, आईपी स्टैक) द्वारा अनदेखा किया गया एक मल्टीकास्ट पैकेट एक बूंद के रूप में नहीं दिखाएगा (हालांकि यह कुछ पर "फ़िल्टर्ड" के रूप में दिखाई दे सकता है) एनआईसी आँकड़े)। विभिन्न ऑफलोड सुविधाओं से आंकड़े कुछ हद तक जटिल हो सकते हैं।

आपके पास अधिक आँकड़े हो सकते हैं 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
 [...]

कुछ आंकड़े एनआईसी चालक पर निर्भर करते हैं, जैसा कि सटीक अर्थ होगा। ऊपर एक इंटेल से है e1000। मुट्ठी भर ड्राइवरों को देखने के बाद, कुछ दूसरों की तुलना में कई अधिक आंकड़े एकत्र करते हैं (एथलेट के लिए उपलब्ध आंकड़े अलग-अलग स्रोत फ़ाइल में रखे जाते हैं, उदाहरण के लिए drivers/net/ethernet/intel/e1000/e1000_ethtool.c, यदि आपको अफवाह करने की आवश्यकता है)।

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;
            }

एमटीयू की जांच करें, संभावित कारण जंबो फ्रेम हैं, या इनकैप्सुलेशन के लिए थोड़े ओवरसाइज्ड ईथरनेट फ्रेम हैं । मैं यह नहीं समझा tcpdumpसकता कि व्यवहार में बदलाव क्यों हो सकता है, यह इंटरफ़ेस MTU को बदलने के लिए नहीं जाना जाता है। ध्यान दें कि आप "बड़े" पैकेट को देख सकते हैं, तो MTU tcpdumpअगर TSO / LRO सक्षम है ( स्पष्टीकरण )।

Comments

आपके प्रस्तावित उत्तर के लिए धन्यवाद। Sysfs आँकड़ों द्वारा दी गई जानकारी या ethtool -Sइसके समान (कम से कम मेरे सिस्टम पर) है और मुझे केवल गिरे हुए पैकेटों की संख्या के बारे में जानकारी मिलती है। मैं अपनी पोस्ट को आउटपुट के साथ अपडेट करूंगा।

— Huygens

मैंने ड्राइवर स्रोत कोड (tg3.c) की जाँच की है और वीएलएएन त्रुटि और गलत सॉकेट बफर लंबाई के लिए केवल संदर्भ पाया है। मुझे नहीं पता कि इससे क्या निष्कर्ष निकाला जा सकता है ...

— Huygens

अपडेट के लिए धन्यवाद, दुःख की बात है कि मैं दूसरी बार +1 नहीं कर सकता;; अगर tcpdump अपने MTU (1500) से बड़े फ्रेम या फ्रेम की रिपोर्ट कर रहा है तो;

— ह्यूजेंस

मेरे पास TSO और LRO 'है'। Tcpdump मेरे MTU से बड़े फ़्रेमों की रिपोर्ट करता है, लेकिन मुझे यह देखना होगा कि क्या यह LRO के कारण है ... मैं सोमवार को देखूंगा। सप्ताह के अंत में होने का समय अब।

— Huygens

यदि tg3एक मॉड्यूल है और आप वास्तव में इसके निचले भाग में जाना चाहते हैं, तो आप कुछ घटनाओं को रिकॉर्ड करने के लिए printk()-जैसे netdev_info()का उपयोग कर सकते हैं , आपके लिए कॉपी करने के लिए पहले से ही कोड में उदाहरण हैं। संरचना के include/linux/skbuff.hलिए देखें sk_buff(दिल की बेहोशी के लिए नहीं)। tg3_rx()मॉड्यूल में संबंधित स्थानों पर कुछ कॉल छिड़कें , मॉड्यूल को फिर से

— बनाएं