tcpdump აჩვენებს 64 KB პაკეტებს: offload და აღების წერტილი

ჰოსტზე აღებამ შეიძლება აჩვენოს 64 KB პაკეტი 1420 MTU-ის მქონე ინტერფეისზე, და აშკარა დასკვნაა, რომ გვირაბმა უგულებელყო თავისი ზომის ზღვარი. ეს დასკვნა ჩვეულებრივ მცდარია. ჰოსტზე აღების წერტილები დამუშავების გზის შიგნითაა, სადაც სეგმენტაცია, აგრეგაცია და საკონტროლო ჯამის სამუშაო შეიძლება ჯერ არ მომხდარიყო. წაიკითხეთ დამკვირვებლის მდებარეობა, სანამ წაიკითხავთ პაკეტის ზომას.

სად იღებთ, ცვლის იმას, რასაც ხედავთ

გადაცემის offload საშუალებას აძლევს სტეკს დიდი ერთეული გადასცეს ქსელურ მოწყობილობას, რომელიც მოგვიანებით დაჭრის მას მავთულის ზომის ნაწილებად. მიღების აგრეგაცია პირიქით აკეთებს შესვლის გზაზე და აერთიანებს სეგმენტებს, სანამ ჰოსტის მხარეს დამკვირვებელი დაინახავს მათ. ამიტომ აღება აღრიცხავს ჰოსტის შიდა ხედს ამ წერტილში, არა აუცილებლად ბმულზე არსებულ ჩარჩოებს. ორივე მექანიზმი დამოკიდებულია მოწყობილობაზე და გზაზე.

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

მეორე წერტილში იღეთ, იდეალურად დამოუკიდებელ მიმღებზე ან სარკეზე, სანამ ზომას ხარვეზად ჩათვლით. თუ დიდი ერთეული მხოლოდ გამომგზავნ ჰოსტზე ჩანს, შესაძლოა მავთულმა ის არასოდეს ატარა. ორი დაკვირვების წერტილი უფრო ძლიერია, ვიდრე ერთი ფაილი, განსაკუთრებით მაშინ, როცა კითხვაა, რა დატოვა რეალურად მანქანამ.

გამოყავით შიდა და გარე ინტერფეისები

გვირაბი ამატებს საკუთარ ინტერფეისს, და გარე და შიდა ხედები განსხვავდება ინკაფსულაციითა და დამუშავებით. გვირაბის მოწყობილობაზე აღება აჩვენებს შიდა პაკეტს; ფიზიკურ ადაპტერზე აღება აჩვენებს გარე პაკეტს. ზომა, მისამართები და საკონტროლო ჯამის მდგომარეობა შეიძლება განსხვავდებოდეს მათ შორის ისეთი მიზეზებით, რომლებსაც ხარვეზთან კავშირი არ აქვთ.

ჩაწერეთ, რომელმა ინტერფეისმა შექმნა თითოეული ფაილი. გვირაბის მოწყობილობაზე დანახული ზომა აღწერს შიდა პაკეტს, არა იმ ჩარჩოს, რომელიც ადაპტერმა საბოლოოდ გაგზავნა. მათი შერევა ერთ ანალიზში ის გზაა, რომლითაც ჩვეულებრივი ინკაფსულაციის სხვაობა საიდუმლოდ იქცევა.

საკონტროლო ჯამის გაფრთხილებაც პოზიციურია

გაგზავნის მხარეს აღებამ შეიძლება აჩვენოს საკონტროლო ჯამის ველი, სანამ ტექნიკა შეავსებს მას, რაც წარმოქმნის გაფრთხილებას, რომელსაც ვერც ერთი მიმღები ვერასოდეს დაინახავდა. ეს განსხვავებული მტკიცებულებაა, ვიდრე დაზიანებული პაკეტის დაშორებული ჰოსტის მიერ უარყოფა. მიმართულება და აღების წერტილი წყვეტს, რომელი გაქვთ ამ ორიდან.

როცა რეალური გადაცემა ვერ ხერხდება, შეადარეთ დაკვირვებები მიმღებზე ან გზის სხვა წერტილში. შეინახეთ მიმართულება, ინტერფეისი და ინკაფსულაციის შრე ჩანაწერთან ერთად, რადგან მათ გარეშე ეკრანის სურათი მოგვიანებით ვერ იქნება განმარტებული.

გამორთეთ offload მხოლოდ როგორც კონტროლირებული ტესტი

offload-ის გამორთვა ცვლის წარმადობას და პაკეტების დამუშავებას, ამიტომ ეს არ არის პირველი რეაქცია უცნაურ ზომის ჩვენებაზე. თუ ტესტავთ, შეცვალეთ ერთი პარამეტრი და ჯერ ჩაწერეთ საწყისი მდგომარეობა. გაშვება, რომელიც ასევე ცვლის MTU-ს, ფაირვოლის წესებსა და კლიენტის პროფილს, ვერ მიაწერს შედეგს offload-ს. შემდეგ აღადგინეთ პარამეტრი.

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

დიდი გადაცემის ნამდვილი შეჩერება ცალკე კითხვაა გზის MTU-სა და იმ უკუკავშირზე, რომელსაც აპლიკაცია იღებს. ჰოსტის აგრეგირებული ერთეული არც ამტკიცებს და არც უარყოფს ქვემოთ ზომის ზღვარს, და დაბალი CPU პროცენტი offload-ს მიზეზად არ ადგენს.

სასარგებლო შედეგია განმარტებული აღების წერტილი და განმეორებადი აპლიკაციის დაკვირვება. მათი გამოყოფით, MTU-ის ცვლილებამ შეიძლება დაუმიზნოს რეალურ შეზღუდვას და არა შიდა ბუფერის ფორმას.