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 পরিবর্তন অভ্যন্তরীণ বাফারের আকৃতির বদলে প্রকৃত সীমাবদ্ধতাকে লক্ষ্য করতে পারে।