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 परिवर्तनले आन्तरिक बफरको आकारको सट्टा वास्तविक सीमालाई लक्षित गर्न सक्छ।