Se pare că o parte a rețelei nu permite cadre Ethernet mai mari de 1510 de octeți (excluzând suma de control), ceea ce face ca MTU permis să fie de 1496 de octeți în loc de 1500 de octeți standard și, astfel, cadrele care conțineau inițial o sarcină utilă de 1500 de octeți sunt eliminate.
Motivul exact al reducerii MTU nu este relevant pentru această întrebare. Întrebarea este aici de ce un Windows Server 2019 este capabil să se recupereze din aceste pachete scăpate pentru niste conexiuni, dar nu altele. După cum am înțeles, ceea ce văd aici pare a fi „detecția găurii negre PMTU”, dar de ce se întâmplă detectarea găurii negre PMTU pentru unele conexiuni, dar nu pentru altele?
Clienții 10.246.54.143 și 10.246.54.157 sunt ambii în același segment LAN la un site la distanță, unde există problema MTU. Ambele inițiază conexiuni la serverul 10.8.4.45.
În ambele cazuri, strângerea de mână TCP inițială este în regulă, apoi problema MTU este lovită atunci când serverul trimite câteva pachete mari.
Când se întâmplă acest lucru pe o conexiune de la 10.246.54.157, după câteva retransmisii ale pachetelor mari, serverul pare să renunțe și să încerce în schimb cu o încărcătură IP de doar 576 de octeți, care funcționează și totul decurge de acolo:
(Interesant, pachetele mari trimise de client ajung)
Apoi, când 10.246.54.143 încearcă să se conecteze, pachetele mari sunt abandonate și au loc retransmisii, dar în acest caz serverul nu încearcă niciodată cu o dimensiune mai mică a pachetului și, prin urmare, conexiunea nu se poate forma niciodată complet:
Aplicația server (ascultă pe portul 5002) este aceeași în ambele cazuri. Este scris în Java.
De ce serverul nu încearcă niciodată cu pachete mai mici pentru conexiunea de la 10.246.54.143?
Toate sunt direcționate pe aceleași interfețe și routere, cu excepția bitului cel mai apropiat de clienți, unde sunt atașați la diferite comutatoare.
