tcpdump 64 KB पॅकेट दाखवतो: ऑफलोड आणि कॅप्चर बिंदू

होस्टवर कॅप्चर केल्यास 1420 MTU असलेल्या इंटरफेसवर 64 KB पॅकेट दिसू शकते, आणि स्पष्ट निष्कर्ष असा की सुरूंगाने आपली आकारमर्यादा दुर्लक्षित केली। हा निष्कर्ष सहसा चुकीचा असतो। होस्टवरील कॅप्चर बिंदू प्रक्रिया मार्गाच्या आत असतात, जिथे विभाजन, एकत्रीकरण आणि चेकसमचे काम अजून झाले नसेल। पॅकेटचा आकार वाचण्यापूर्वी निरीक्षकाची स्थिती वाचा।

तुम्ही कुठे कॅप्चर करता यावर तुम्हाला काय दिसते ते बदलते

ट्रान्समिट ऑफलोड स्टॅकला मोठे एकक नेटवर्क उपकरणाकडे सोपवू देतो, जे नंतर ते तारेच्या आकाराच्या तुकड्यांमध्ये कापते। रिसीव्ह एकत्रीकरण आत येणाऱ्या मार्गावर उलटे करते आणि होस्ट बाजूच्या निरीक्षकाला ते दिसण्यापूर्वी विभाग जोडते। म्हणून कॅप्चर त्या बिंदूवरील होस्टचे अंतर्गत दृश्य नोंदवते, लिंकवरील फ्रेम्स आवश्यकच असे नाही। दोन्ही यंत्रणा उपकरण आणि मार्गावर अवलंबून असतात।

ethtool -k eth0 | grep -E 'tso|gso|gro'

आकार दोष मानण्यापूर्वी दुसऱ्या बिंदूवर, आदर्शपणे स्वतंत्र रिसीव्हर किंवा मिररवर कॅप्चर करा। मोठे एकक फक्त पाठवणाऱ्या होस्टवर दिसत असेल, तर तारेने ते कधीही वाहून नेले नसेल। दोन निरीक्षण बिंदू एका फाइलपेक्षा बलवान असतात, विशेषतः जेव्हा प्रश्न असतो की मशीनमधून प्रत्यक्षात काय बाहेर पडले।

अंतर्गत आणि बाह्य इंटरफेस वेगळे करा

सुरूंग स्वतःचा इंटरफेस जोडतो, आणि बाह्य आणि अंतर्गत दृश्ये एन्कॅप्स्युलेशन आणि प्रक्रियेत भिन्न असतात। सुरूंग उपकरणावरील कॅप्चर अंतर्गत पॅकेट दाखवते; भौतिक अडॅप्टरवरील कॅप्चर बाह्य पॅकेट दाखवते। आकार, पत्ते आणि चेकसमची स्थिती त्यांच्यात कोणत्याही दोषाशी संबंध नसलेल्या कारणांमुळे भिन्न असू शकते।

कोणत्या इंटरफेसने कोणती फाइल तयार केली ते नोंदवा। सुरूंग उपकरणावर दिसणारा आकार अंतर्गत पॅकेटचे वर्णन करतो, अडॅप्टरने शेवटी पाठवलेल्या फ्रेमचे नाही। दोन्हींना एकाच विश्लेषणात मिसळणे म्हणजे सामान्य एन्कॅप्स्युलेशन फरक कोडे बनतो।

चेकसम इशाराही स्थानाधारित असतो

पाठवण्याच्या बाजूचे कॅप्चर हार्डवेअर भरण्यापूर्वी चेकसम फील्ड दाखवू शकते, ज्यामुळे असा इशारा तयार होतो जो कोणत्याही रिसीव्हरला कधीही दिसणार नाही। हा दूरच्या होस्टने खराब झालेले पॅकेट नाकारण्यापेक्षा वेगळा पुरावा आहे। दिशा आणि कॅप्चर बिंदू ठरवतात की दोन्हींपैकी तुमच्याकडे कोणते आहे।

प्रत्यक्ष हस्तांतरण अयशस्वी झाल्यास रिसीव्हरवर किंवा मार्गाच्या दुसऱ्या बिंदूवरील निरीक्षणांची तुलना करा। दिशा, इंटरफेस आणि एन्कॅप्स्युलेशन स्तर नोंदीसोबत ठेवा, कारण त्यांशिवाय स्क्रीनशॉटचा नंतर अर्थ लावता येत नाही।

ऑफलोड फक्त नियंत्रित चाचणी म्हणून बंद करा

ऑफलोड बंद केल्याने कार्यक्षमता आणि पॅकेट प्रक्रिया बदलते, म्हणून विचित्र आकार दर्शनावर ही पहिली प्रतिक्रिया नाही। तुम्ही चाचणी केल्यास एक सेटिंग बदला आणि आधी आधाररेषा नोंदवा। MTU, फायरवॉल नियम आणि क्लायंट प्रोफाइलही बदलणारी रन निकाल ऑफलोडला देऊ शकत नाही। नंतर सेटिंग पुनर्संचयित करा।

ethtool -K eth0 tso off gro off
ping -M do -s 1400 example.com

मोठ्या हस्तांतरणाचा खरा अडथळा मार्गाच्या MTU आणि अनुप्रयोगाला मिळणाऱ्या अभिप्रायाबद्दलचा वेगळा प्रश्न आहे। होस्टचे एकत्रित एकक पुढील आकारमर्यादा सिद्ध करत नाही किंवा खंडन करत नाही, आणि कमी CPU टक्केवारी ऑफलोडला कारण म्हणून ओळखत नाही।

उपयुक्त निकाल म्हणजे स्पष्ट केलेला कॅप्चर बिंदू आणि पुनरावृत्तीय अनुप्रयोग निरीक्षण। हे वेगळे केल्यास MTU बदल आंतरिक बफरच्या आकाराऐवजी खऱ्या मर्यादेला लक्ष्य करू शकतो।