tcpdump montras 64 KB-paketojn: offload kaj kaptopunkto

Kapto ĉe gastiganto povas montri paketon de 64 KB sur interfaco kun MTU 1420, kaj la evidenta konkludo estas, ke la tunelo ignoris sian grandlimon. Tiu konkludo kutime estas malĝusta. Kaptpunktoj ĉe la gastiganto troviĝas interne de la prilabora vojo, kie segmentado, agregado kaj kontrolsuma laboro eble ankoraŭ ne okazis. Legu la pozicion de la observanto antaŭ ol legi la grandecon de la paketo.

Kie vi kaptas, ŝanĝas tion, kion vi vidas

Sendoffload lasas la stakon transdoni grandan unuon al la reta aparato, kiu poste tranĉas ĝin en dratgrandajn pecojn. Riceva agregado faras la malon sur la enira vojo, kunigante segmentojn antaŭ ol observanto ĉe la gastiganta flanko vidas ilin. Kapto do registras la internan vidon de la gastiganto ĉe tiu punkto, ne nepre la kadrojn sur la ligilo. Ambaŭ mekanismoj dependas de la aparato kaj de la vojo.

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

Kaptu ĉe dua punkto, ideale ĉe sendependa ricevilo aŭ spegulo, antaŭ ol trakti la grandecon kiel difekton. Se la granda unuo aperas nur ĉe la sendanta gastiganto, la drato eble neniam portis ĝin. Du observpunktoj estas pli fortaj ol unu dosiero, precipe kiam la demando estas, kio efektive forlasis la maŝinon.

Apartigu la internan kaj la eksteran interfacojn

Tunelo aldonas sian propran interfacon, kaj la ekstera kaj la interna vidoj diferencas en enkapsuligo kaj en prilaborado. Kapto sur la tunela aparato montras la internan paketon; kapto sur la fizika adaptilo montras la eksteran. Grando, adresoj kaj kontrolsuma stato povas diferenci inter ili pro kialoj, kiuj havas nenion komunan kun difekto.

Notu, kiu interfaco produktis ĉiun dosieron. Grando vidata sur la tunela aparato priskribas la internan paketon, ne la kadron, kiun la adaptilo finfine sendis. Miksi ilin en unu analizo estas kiel normala enkapsuliga diferenco fariĝas mistero.

Kontrolsuma averto ankaŭ estas pozicia

Kapto ĉe la senda flanko povas montri kontrolsuman kampon antaŭ ol la aparataro plenigas ĝin, kio produktas averton, kiun neniu ricevilo iam vidus. Tio estas alia pruvo ol fora gastiganto, kiu rifuzas difektitan paketon. La direkto kaj la kaptopunkto decidas, kiun el la du vi havas.

Kiam reala transdono malsukcesas, komparu observojn ĉe ricevilo aŭ ĉe alia punkto de la vojo. Konservu direkton, interfacon kaj enkapsuligan tavolon kun la registraĵo, ĉar ekrankopio sen ili ne povas esti interpretata poste.

Malŝaltu offload nur kiel kontrolatan teston

Malŝalti offload ŝanĝas rendimenton kaj paketprilaboradon, do ĝi ne estas la unua respondo al stranga granda montrado. Se vi testas ĝin, ŝanĝu unu agordon kaj unue registru la bazlinion. Rulo, kiu ankaŭ ŝanĝas MTU, fajroŝirmilajn regulojn kaj la klientan profilon, ne povas atribui la rezulton al offload. Restarigu la agordon poste.

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

Vera halto de granda transdono estas aparta demando pri la MTU de la vojo kaj la retrosciigo, kiun la aplikaĵo ricevas. Agregita unuo de gastiganto nek pruvas nek malpruvas grandlimon pli malsupre, kaj malalta CPU-procento ne identigas offload kiel la kaŭzon.

La utila rezulto estas klarigita kaptopunkto plus ripetebla aplikaĵa observo. Kun tiuj apartigitaj, ŝanĝo de MTU povas celi realan limigon anstataŭ la formon de interna bufro.