tcpdump 64 KB پیکٹ دکھاتا ہے: offload اور گرفت کا مقام

میزبان پر گرفت 1420 MTU والے انٹرفیس پر 64 KB کا پیکٹ دکھا سکتی ہے، اور واضح نتیجہ یہ ہے کہ سرنگ نے اپنی حجم کی حد نظرانداز کی۔ یہ نتیجہ عام طور پر غلط ہوتا ہے۔ میزبان پر گرفت کے مقامات پروسیسنگ کے راستے کے اندر ہوتے ہیں، جہاں تقسیم، یکجائی اور چیکسم کا کام ابھی نہ ہوا ہو۔ پیکٹ کا حجم پڑھنے سے پہلے مشاہدہ کرنے والے کی پوزیشن پڑھیں۔

آپ کہاں گرفت کرتے ہیں، یہ بدلتا ہے کہ آپ کیا دیکھتے ہیں

ٹرانسمٹ offload اسٹیک کو یہ اجازت دیتا ہے کہ وہ بڑی اکائی نیٹ ورک ڈیوائس کے حوالے کرے، جو بعد میں اسے تار کے حجم کے ٹکڑوں میں کاٹتی ہے۔ ریسیو یکجائی اندر آنے والے راستے پر اس کے برعکس کرتی ہے اور حصوں کو جوڑ دیتی ہے اس سے پہلے کہ میزبان کی طرف کا مشاہدہ کرنے والا انہیں دیکھے۔ اس لیے گرفت اس مقام پر میزبان کا اندرونی منظر ریکارڈ کرتی ہے، لنک کے فریم ضروری نہیں۔ دونوں طریقے ڈیوائس اور راستے پر منحصر ہیں۔

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

حجم کو خرابی سمجھنے سے پہلے دوسرے مقام پر گرفت کریں، بہتر ہے کوئی آزاد وصول کنندہ یا آئینہ ہو۔ اگر بڑی اکائی صرف بھیجنے والے میزبان پر نظر آئے، تو ممکن ہے تار نے اسے کبھی نہ اٹھایا ہو۔ دو مشاہدے کے مقامات ایک فائل سے زیادہ مضبوط ہیں، خاص طور پر جب سوال یہ ہو کہ مشین سے واقعی کیا نکلا۔

اندرونی اور بیرونی انٹرفیس الگ کریں

سرنگ اپنا انٹرفیس شامل کرتی ہے، اور بیرونی اور اندرونی منظر encapsulation اور پروسیسنگ میں مختلف ہیں۔ سرنگ ڈیوائس پر گرفت اندرونی پیکٹ دکھاتی ہے؛ فزیکل اڈاپٹر پر گرفت بیرونی پیکٹ دکھاتی ہے۔ حجم، پتے اور چیکسم کی حالت ان کے درمیان ایسی وجوہ سے مختلف ہو سکتی ہے جن کا کسی خرابی سے کوئی تعلق نہیں۔

ریکارڈ کریں کہ کون سا انٹرفیس کون سی فائل بناتا ہے۔ سرنگ ڈیوائس پر نظر آنے والا حجم اندرونی پیکٹ بیان کرتا ہے، نہ کہ وہ فریم جو اڈاپٹر نے آخر میں بھیجا۔ ایک ہی تجزیے میں دونوں کو ملانا ہی عام encapsulation فرق کو معمہ بناتا ہے۔

چیکسم کی تنبیہ بھی مقام پر منحصر ہے

بھیجنے کی طرف کی گرفت چیکسم کا فیلڈ ہارڈویئر کے بھرنے سے پہلے دکھا سکتی ہے، جس سے ایسی تنبیہ بنتی ہے جو کوئی وصول کنندہ کبھی نہیں دیکھے گا۔ یہ دور کے میزبان کی جانب سے خراب پیکٹ مسترد کرنے سے مختلف ثبوت ہے۔ سمت اور گرفت کا مقام طے کرتے ہیں کہ آپ کے پاس دونوں میں سے کون سا ہے۔

جب حقیقی منتقلی ناکام ہو، تو وصول کنندہ پر یا راستے کے کسی اور مقام پر مشاہدات کا موازنہ کریں۔ سمت، انٹرفیس اور encapsulation کی تہہ ریکارڈ کے ساتھ رکھیں، کیونکہ ان کے بغیر اسکرین شاٹ بعد میں بیان نہیں کیا جا سکتا۔

offload صرف کنٹرول شدہ جانچ کے طور پر بند کریں

offload بند کرنا کارکردگی اور پیکٹ پروسیسنگ بدلتا ہے، اس لیے عجیب حجم کی نمائش پر یہ پہلا ردعمل نہیں ہے۔ اگر آپ جانچ کریں، تو ایک سیٹنگ بدلیں اور پہلے بنیادی حالت ریکارڈ کریں۔ جو رن MTU، فائر وال قواعد اور کلائنٹ پروفائل بھی بدلے، وہ نتیجہ offload سے منسوب نہیں کر سکتا۔ بعد میں سیٹنگ بحال کریں۔

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

بڑی منتقلی کا حقیقی رکنا راستے کی MTU اور ایپلیکیشن کو ملنے والی رائے کے بارے میں الگ سوال ہے۔ میزبان کی یکجا شدہ اکائی نیچے کی حجم کی حد کو نہ ثابت کرتی ہے نہ رد، اور کم CPU فیصد offload کو سبب کے طور پر نہیں پہچانتا۔

مفید نتیجہ واضح کیا گیا گرفت کا مقام اور ایپلیکیشن کا دہرانے کے قابل مشاہدہ ہے۔ جب یہ الگ ہوں، تو MTU کی تبدیلی اندرونی بفر کی شکل کے بجائے حقیقی پابندی کو نشانہ بنا سکتی ہے۔