tcpdump shfaq paketa 64 KB: offload dhe pika e kapjes

Kapja në një host mund të tregojë një paketë 64 KB në një ndërfaqe me MTU 1420, dhe përfundimi i qartë është që tuneli injoroi kufirin e madhësisë. Ky përfundim zakonisht është i gabuar. Pikat e kapjes në host ndodhen brenda rrugës së përpunimit, ku segmentimi, agregimi dhe puna me shumën kontrolluese mund të mos kenë ndodhur ende. Lexoni pozicionin e vëzhguesit përpara se të lexoni madhësinë e paketës.

Ku kapni ndryshon atë që shihni

Offload-i i transmetimit lejon stivën të dorëzojë një njësi të madhe te pajisja e rrjetit, e cila më vonë e pret në copa me madhësinë e telit. Agregimi i marrjes bën të kundërtën në rrugën hyrëse, duke bashkuar segmentet përpara se një vëzhgues në anën e hostit t'i shohë ato. Prandaj një kapje regjistron pamjen e brendshme të hostit në atë pikë, jo domosdoshmërisht kornizat në lidhje. Të dy mekanizmat varen nga pajisja dhe rruga.

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

Kapni në një pikë të dytë, në mënyrë ideale një marrës të pavarur ose një pasqyrë, përpara se ta trajtoni madhësinë si defekt. Nëse njësia e madhe shfaqet vetëm në hostin dërgues, teli mund të mos e ketë mbajtur kurrë. Dy pika vëzhgimi janë më të forta se një skedar i vetëm, sidomos kur pyetja është çfarë doli vërtet nga makina.

Ndani ndërfaqen e brendshme nga e jashtmja

Një tunel shton ndërfaqen e vet, dhe pamjet e jashtme dhe të brendshme ndryshojnë në kapsulim dhe në përpunim. Kapja në pajisjen e tunelit tregon paketën e brendshme; kapja në përshtatësin fizik tregon atë të jashtme. Madhësia, adresat dhe gjendja e shumës kontrolluese mund të ndryshojnë mes tyre për arsye që nuk kanë asnjë lidhje me një defekt.

Regjistroni cila ndërfaqe prodhoi çdo skedar. Një madhësi e parë në pajisjen e tunelit përshkruan paketën e brendshme, jo kornizën që përshtatësi dërgoi në fund. Përzierja e tyre në një analizë të vetme është mënyra se si një ndryshim normal kapsulimi bëhet mister.

Një paralajmërim për shumën kontrolluese është gjithashtu pozicional

Një kapje në anën e dërgimit mund të tregojë një fushë të shumës kontrolluese përpara se hardueri ta plotësojë atë, gjë që prodhon një paralajmërim që asnjë marrës nuk do ta shihte kurrë. Kjo është provë e ndryshme nga refuzimi i një pakete të dëmtuar nga një host i largët. Drejtimi dhe pika e kapjes vendosin cila nga të dyja është rasti juaj.

Kur një transferim real dështon, krahasoni vëzhgimet te një marrës ose në një pikë tjetër të rrugës. Mbani drejtimin, ndërfaqen dhe shtresën e kapsulimit bashkë me regjistrimin, sepse një pamje ekrani pa to nuk mund të interpretohet më vonë.

Çaktivizoni offload-in vetëm si provë të kontrolluar

Çaktivizimi i offload-it ndryshon performancën dhe përpunimin e paketave, prandaj nuk është reagimi i parë ndaj një shfaqjeje të çuditshme të madhësisë. Nëse e provoni, ndryshoni një cilësim dhe regjistroni fillimisht bazën. Një ekzekutim që ndryshon gjithashtu MTU-në, rregullat e firewall-it dhe profilin e klientit nuk mund t'ia atribuojë rezultatin offload-it. Rivendosni cilësimin më pas.

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

Një bllokim i vërtetë i një transferimi të madh është një pyetje më vete për MTU-në e rrugës dhe reagimin që merr aplikacioni. Njësia e agreguar e hostit as nuk vërteton as nuk hedh poshtë një kufi madhësie më poshtë, dhe një përqindje e ulët CPU nuk e identifikon offload-in si shkak.

Rezultati i dobishëm është një pikë kapjeje e shpjeguar plus një vëzhgim i përsëritshëm i aplikacionit. Kur këto ndahen, një ndryshim i MTU-së mund të synojë një kufizim real në vend të formës së një buferi të brendshëm.