tcpdump가 64 KB 패킷을 표시할 때: 오프로드와 캡처 지점

호스트에서 캡처하면 MTU가 1420인 인터페이스에서 64 KB 패킷이 보일 수 있고, 당연한 결론은 터널이 크기 제한을 무시했다는 것입니다. 그 결론은 대개 틀립니다. 호스트의 캡처 지점은 처리 경로 안쪽에 있어 세그멘테이션, 집계, 체크섬 작업이 아직 일어나지 않았을 수 있습니다. 패킷 크기를 읽기 전에 관측자의 위치를 먼저 읽으십시오.

어디서 캡처하느냐가 보이는 것을 바꿉니다

전송 오프로드는 스택이 큰 단위를 네트워크 장치에 넘기게 하고, 장치는 나중에 그것을 와이어 크기 조각으로 자릅니다. 수신 집계는 들어오는 경로에서 반대로 하여 호스트 쪽 관측자가 보기 전에 세그먼트를 합칩니다. 따라서 캡처는 그 지점에서 호스트의 내부 모습을 기록하며, 링크 위의 프레임과 반드시 같지는 않습니다. 두 메커니즘 모두 장치와 경로에 의존합니다.

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

크기를 결함으로 다루기 전에 두 번째 지점, 이상적으로는 독립 수신기나 미러에서 캡처하십시오. 큰 단위가 보내는 호스트에서만 나타난다면 와이어가 그것을 실제로 운반하지 않았을 수 있습니다. 두 관측 지점은 파일 하나보다 강하며, 특히 질문이 기계에서 실제로 무엇이 나갔는가일 때 그렇습니다.

안쪽과 바깥쪽 인터페이스를 분리하십시오

터널은 자체 인터페이스를 추가하고, 바깥쪽과 안쪽 모습은 캡슐화와 처리에서 다릅니다. 터널 장치에서 캡처하면 안쪽 패킷이 보이고, 물리 어댑터에서 캡처하면 바깥쪽 패킷이 보입니다. 크기, 주소, 체크섬 상태는 결함과 무관한 이유로 둘 사이에서 다를 수 있습니다.

어느 인터페이스가 각 파일을 만들었는지 기록하십시오. 터널 장치에서 본 크기는 안쪽 패킷을 설명하며, 어댑터가 마침내 보낸 프레임이 아닙니다. 둘을 한 분석에서 섞는 것이 평범한 캡슐화 차이를 미스터리로 만드는 방법입니다.

체크섬 경고도 위치에 따라 달라집니다

전송 쪽 캡처는 하드웨어가 채우기 전의 체크섬 필드를 보여 줄 수 있고, 그러면 어떤 수신기도 결코 보지 못할 경고가 생깁니다. 이는 원격 호스트가 손상된 패킷을 거부하는 것과 다른 증거입니다. 방향과 캡처 지점이 둘 중 어느 것인지를 결정합니다.

실제 전송이 실패하면 수신기나 경로의 다른 지점에서 관측을 비교하십시오. 그것이 없으면 나중에 스크린샷을 해석할 수 없으므로 방향, 인터페이스, 캡슐화 계층을 기록과 함께 남기십시오.

오프로드는 통제된 시험으로만 끄십시오

오프로드를 끄면 성능과 패킷 처리가 바뀌므로 이상한 크기 표시에 대한 첫 대응은 아닙니다. 시험한다면 설정 하나만 바꾸고 먼저 기준선을 기록하십시오. MTU, 방화벽 규칙, 클라이언트 프로필까지 바꾸는 실행은 결과를 오프로드에 돌릴 수 없습니다. 나중에 설정을 되돌리십시오.

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

큰 전송의 실제 정체는 경로 MTU와 애플리케이션이 받는 피드백에 관한 별개의 질문입니다. 호스트의 집계된 단위는 하류의 크기 제한을 증명하지도 반증하지도 않으며, 낮은 CPU 비율은 오프로드를 원인으로 지목하지 않습니다.

유용한 결과는 설명된 캡처 지점과 재현 가능한 애플리케이션 관측입니다. 이 둘을 분리하면 MTU 변경이 내부 버퍼의 모양 대신 실제 제약을 겨냥할 수 있습니다.