이더넷 패딩 한눈에 보기
짧은 메시지가 더 긴 프레임으로 나타날 수 있는 이유는 무엇인가?
이더넷은 최소 MAC 프레임 형식을 충족하기 위해 FCS 앞에 패딩을 추가할 수 있습니다. 패딩은 IPv4 패킷 외부에 있으며 애플리케이션 데이터가 되어서는 안 됩니다. 캡처 소프트웨어는 패딩 이전의 처리를 관찰하거나 FCS 없이 레코드를 수신할 수 있으므로, 표시된 길이만으로는 크기 미달 전송을 입증할 수 없습니다. 관찰 지점과 길이 규칙을 확인하십시오.
외부 프레임 구성
패딩은 외부 형식을 충족할 뿐 애플리케이션 의미를 추가하지 않습니다.
관찰자 위치 파악
소프트웨어는 물리 링크와 다른 단계를 볼 수 있습니다.
내부 경계 준수
IPv4의 경우 패딩을 데이터로 취급하지 말고 IP 총 길이를 사용하십시오.
카운트 확인
길이에 포함되는 헤더, 태그 및 FCS 바이트를 명시하십시오.
캡처 확인
방향, 오프로드, 보존 길이 및 FCS 설정을 기록하십시오.
파서 확인
상위 계층 길이가 유효한 애플리케이션 콘텐츠를 정의하는지 확인하십시오.
선택 및 검증 체크리스트 — 펼치기
| 검사 | 확인할 사항 | 검증 방법 |
|---|---|---|
| 프레임 규칙 | 헤더, 태그 및 FCS | 카운트의 정확한 시작과 끝을 문서화하십시오. |
| 관찰 지점 | NIC, 와이어 또는 수신기 이전 | 인터페이스 및 수집 설정을 보존하십시오. |
| 캡처 완전성 | 원본 대 보존 길이 | 잘림 및 수집 한도를 확인하십시오. |
| 프로토콜 경계 | 유효한 IP 또는 기타 프로토콜 길이 | 지정된 길이와 파서 동작을 검사하십시오. |
| 결함 증거 | 카운터, 방향 및 시간 | 양단의 알려진 트래픽을 연관시키십시오. |
개념적 예시이며 축척이 아니고, 특정 제품 구현의 측정값이나 주장이 아닙니다.
PLC가 짧은 상태 메시지를 보내지만 이더넷을 통해 전송되는 콘텐츠는 더 깁니다. 캡처는 60 바이트를 보여주는 반면, 문서는 64 바이트 최소 프레임을 설명합니다. 스위치가 4바이트를 제거했다고 즉시 결론 내리지 마십시오. 애플리케이션 메시지, 이더넷 캡슐화 및 소프트웨어 캡처는 서로 다른 관찰 계층입니다. 패딩을 올바른 위치에 두면 겉보기 모순이 설명됩니다.
메시지, IP 패킷 및 이더넷 프레임 분리
애플리케이션은 상태, 명령 또는 측정값에 관심이 있지만, 전송에는 네트워크 장비가 인식할 수 있는 정보가 필요합니다. 메시지를 메모, IP 패킷을 그 봉투, 이더넷 프레임을 이 링크를 위한 외부 포장으로 생각하십시오. 이 비유는 계층을 설명할 뿐 세 개의 물리적 상자를 의미하지 않습니다. 와이어는 연속적인 비트 시퀀스를 전달합니다.
여기서 사용된 일반적인 태그 없는 이더넷 예시에서 MAC 프레임은 목적지 주소부터 프레임 검사 시퀀스(FCS)까지 이어집니다. MAC 주소는 링크상의 송신자나 수신자를 식별하며, FCS은 수신기가 전송 오류를 검사하도록 돕습니다. 프리앰블은 프레임 앞에 오고, 프레임 간 갭은 전송 사이의 유휴 시간입니다. 둘 다 이 64 바이트 카운트에 포함되지 않습니다.
최소값은 외부 MAC 프레임에 적용되며 모든 PLC 명령의 길이에 적용되는 것은 아닙니다. 문서나 캡처를 읽을 때 먼저 카운트가 시작되고 끝나는 위치를 확립하십시오. 애플리케이션 데이터, 헤더 및 FCS을 혼합하면 일반적인 캡슐화가 추가 애플리케이션 콘텐츠처럼 보일 수 있습니다.
프레임 검사 시퀀스 형성 전에 패딩 추가
제공된 상위 계층 콘텐츠가 너무 짧으면 이더넷 전송 처리는 해당 콘텐츠 뒤, FCS 앞에 패딩을 추가합니다. 이는 보호 포장과 같습니다. 메모에 단어를 추가하지 않고 공간만 차지합니다. 소프트웨어, 드라이버 또는 하드웨어가 특정 작업을 수행하는지는 네트워크 인터페이스나 임베디드 구현에 따라 다릅니다.
의도적으로 경계를 정한 예시를 고려하십시오. 14 바이트의 태그 없는 이더넷 헤더가 28 바이트 IPv4 패킷을 전달합니다. 해당 IP 패킷은 일반 IPv4 헤더와 UDP 헤더로 구성될 수 있으며 UDP 애플리케이션 페이로드는 없습니다. 18 패딩 바이트와 4바이트 FCS을 추가하면 64 바이트 MAC 프레임이 생성됩니다. 이는 구조를 보여줄 뿐 FCTEL 장치의 측정값이 아닙니다.
패딩은 이더넷 체크섬으로 보호되는 콘텐츠에 포함됩니다. FCS이 형성된 후에는 임의로 변경할 수 없습니다. 수신기는 애플리케이션 메시지만이 아니라 수신한 프레임을 검사합니다. 순서를 이해하기 위해 CRC 계산은 필요하지 않습니다. 필요한 프레임 콘텐츠를 형성한 다음 해당 검사 값을 생성하면 됩니다.
패딩이 추가 애플리케이션 데이터가 되어서는 안 됩니다
IPv4의 경우, IP 헤더의 총 길이 필드는 IP 패킷 길이를 정의하며, 여기에는 헤더와 데이터가 포함되지만 외부 이더넷 패딩은 제외됩니다. 수신기는 IP 부분을 상위 계층으로 전달하여 추가 해석을 수행합니다. RFC 894는 패딩을 IP 패킷과 명시적으로 분리하며, 설명하는 캡슐화에 필요할 때 0바이트 패딩을 지정합니다.
상위 계층 파서는 캡처된 나머지 모든 이더넷 바이트를 애플리케이션 콘텐츠로 취급해서는 안 됩니다. 명령에 외부 패킹을 덧붙이지 말고 프로토콜 길이와 경계를 검증해야 합니다. 또한 모든 후행 0을 단순히 삭제해서도 안 됩니다. 0은 유효한 데이터일 수 있기 때문입니다. 경계는 바이트의 시각적 모양이 아니라 프로토콜에 의해 결정됩니다.
다른 계층 2 프로토콜은 자체 캡슐화 규칙이 필요하며, IPv4 총 길이를 모든 프로토콜에 기계적으로 적용할 수는 없습니다. 패딩은 비공개 제어 명령이나 초기화되지 않은 메모리를 담아서는 안 됩니다. 실용적인 습관은 외부 프레임 경계와 내부 메시지 경계를 별도로 검증하는 것입니다.
소프트웨어가 60바이트 또는 그보다 적게 표시할 수 있는 이유
캡처 소프트웨어가 반드시 완전한 와이어 표현을 수신하는 것은 아닙니다. 많은 인터페이스가 해당 4바이트를 운영 체제에 전달하지 않고 수신 FCS을 검사합니다. 따라서 소프트웨어는 와이어상의 완전한 64바이트 MAC 프레임에 해당하는 60바이트를 기록할 수 있습니다. Wireshark 문서는 이 차이를 강조합니다. 60만 표시된 길이로는 크기 미달 전송을 입증할 수 없습니다.
전송 측 캡처는 하드웨어가 패딩과 FCS을 추가하기 전의 다른 지점을 관찰할 수 있습니다. 하드웨어가 이후 유효한 전송 프레임을 생성하더라도 그 기록은 60바이트보다 짧을 수 있습니다. 송신 화면, 수신 화면, 물리 링크 관찰은 서로 다른 관점입니다. 두 표시 길이만 비교해서는 그 사이의 장비가 콘텐츠를 제거했다고 입증할 수 없습니다.
또한 원본 길이와 캡처 길이를 구분해야 합니다. 수집기는 각 프레임의 시작 부분만 보존할 수 있으므로 모든 원본 바이트가 반드시 저장되는 것은 아닙니다. 캡처 설정, FCS 전달, 방향 및 오프로드 동작을 확인한 다음 피어 증거와 비교하십시오. 물리 와이어 표현을 입증하려면 명시된 수집 조건을 갖춘 적절한 테스트 방법이 필요합니다.
VLAN 처리가 하나의 고정된 패딩 개수를 의미하지는 않습니다
18 패딩 바이트는 앞선 예시에만 해당합니다. 콘텐츠 길이, 태깅 및 캡슐화 처리가 다르면 필요한 양도 달라집니다. VLAN 태그는 헤더 영역의 일부를 차지하므로 이미 포함된 경우 두 번 계산하지 마십시오. 최소 프레임 크기와 최대 전송 단위(MTU)도 서로 다른 개념입니다.
스위치는 프레임을 수신하고 전달 대상을 식별하며 다음 링크에 적절한 출력을 형성합니다. 태그를 추가하거나 제거하는 장비는 출력 요구 사항을 유지해야 합니다. 참조된 Cisco 문제 해결 문서는 태그 제거 시 패딩이 다시 필요한 특정 플랫폼 사례를 보여줍니다. 이는 처리 경계를 설명하는 데 도움이 되며 모든 스위치의 보편적인 내부 구현을 의미하지는 않습니다.
완전한 짧은 메시지의 정상 패딩은 결함이 아닙니다. 실제 크기 미달 프레임, 손상된 링크로 인한 비정상 전송, 수집 중 단축된 캡처 기록은 각각 다른 조사가 필요합니다. 포트 카운터 이름과 조건은 장비마다 다릅니다. 기록이 짧아 보인다는 이유만으로 스위치를 교체하는 것보다 카운터를 캡처 시간 및 방향과 연관시키는 것이 더 유용합니다.
이 구분을 산업용 스위치 연결에 적용하기
공개된 FCTEL 미니 DIN 레일 5포트 패스트 이더넷 스위치 페이지에는 5개의 이더넷 전기 포트와 10/100M 적응이 나열되어 있습니다. 이는 PLC 및 HMI 연결 시나리오에 실제 제품 기반을 제공합니다. 그러나 캡처 기능, 포트 미러링, 특수 패딩 제어 또는 특정 오류 임계값을 입증하지는 않습니다. 선택한 구성은 해당 문서와 대조하여 확인하십시오.
한 터미널이 짧은 상태 메시지를 반복 전송하고 다른 터미널이 더 큰 파일을 전송하는 경우, 애플리케이션 바이트 수만으로는 포트 부하를 설명할 수 없습니다. 각 프레임은 필요한 간격을 포함하여 캡슐화와 전송 기회도 소비합니다. 많은 소형 메시지는 처리 및 링크 자원을 사용할 수 있습니다. 복잡한 공식이 필요하다고 보기보다 프레임 속도, 실제 트래픽 및 애플리케이션 주기 관찰부터 시작하십시오.
투명하게 전송된 애플리케이션이 후행 바이트를 얻는 것처럼 보이면 먼저 프로토콜 경계와 파서를 확인하십시오. 소스, 변환기 및 목적지가 각각 관찰하는 내용을 비교하십시오. 이더넷 패딩을 직렬 메시지의 일부로 자동 간주하거나 패딩을 없애기 위해 장비 모드를 변경하지 마십시오. 먼저 영향을 받는 계층을 확립하십시오.
세 가지 질문으로 현장 조사의 범위를 좁히기
첫째, 관찰 지점을 식별하십시오. 소스 전송 전, 피어 수신 후 또는 스위치가 제공한 복사본입니다. 둘째, 길이 규칙을 문서화하십시오. 포함된 헤더, FCS 가용성 및 완전한 프레임이 보존되었는지 여부입니다. 셋째, 동일한 애플리케이션 트래픽에 대해 프로토콜 길이, 페이로드 및 오류 카운터를 연관시키십시오. 60바이트를 보여주는 단일 스크린샷으로는 충분하지 않습니다.
비교를 위해 격리된 테스트 환경이나 승인된 유지보수 시간에 알려진 짧은 메시지를 사용하십시오. 양쪽 끝의 원본 캡처와 수집 매개변수를 보존하십시오. 애플리케이션이 유효한 콘텐츠만 추출하고 일반 통신이 계속되는지 확인하십시오. 이러한 테스트는 해당 구성과 경로를 검증하며, 하나의 도구 표시가 모든 인터페이스와 스위치를 정의하지는 않습니다.
마지막으로 이상 현상이 포트, 케이블 또는 캡처 방법을 따라가는지 관찰하십시오. 주석이 달린 스크린샷만이 아니라 원시 증거를 보존하십시오. 원리는 간단합니다. 외부 프레임에는 최소 형식이 있고, 내부 애플리케이션에는 자체 길이 경계가 있으며, 캡처 소프트웨어는 처리 단계 중 하나를 기록합니다. 이 세 가지를 분리해 두면 실제 결함을 찾는 데 도움이 됩니다.
출처 및 제품 근거
Wireshark: 이더넷; IETF RFC 894, 1984년 4월; Cisco 패딩 문제 해결 문서, 16년 2021월 업데이트. 일반 메커니즘은 플랫폼별 명령이나 결함 결론을 다른 장비로 전이하지 않습니다. 제품 근거: FCTEL 미니 DIN 레일 5포트 고속 이더넷 스위치, 중국어 페이지. 선택한 버전을 확인하십시오. 삽화는 AI 지원으로 만든 일반 개념입니다.
중국어 기술 문서에서 번역: 중국어 원문 읽기.
일반적인 실무 질문
60 바이트 캡처는 유효하지 않은 짧은 프레임인가?
반드시 그렇지는 않습니다. 일반적인 캡처는 4바이트 FCS을 생략합니다. 관찰 지점, 원본 길이 및 캡처 길이를 확인하십시오.
패딩이 새로운 PLC 명령이 되는가?
그래서는 안 됩니다. 파서는 외부 패딩을 추가 애플리케이션 데이터로 취급하지 말고 상위 계층 프로토콜 길이를 사용해야 합니다.
모든 짧은 메시지에 18 패딩 바이트가 필요한가?
아니요. 18바이트는 이 문서의 태그 없는 예시에만 적용되며, 실제 패딩은 원본 콘텐츠와 캡슐화에 따라 결정됩니다.
범위 및 추가 자료
일반적인 이더넷 패딩 및 캡처 개념이며, 측정값이나 모델별 보장 동작이 아닙니다.
