한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

듀플렉스 불일치 Duplex mismatch

원인 ID rt-duplex · 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라

한쪽은 자동 협상, 다른 쪽은 속도·듀플렉스를 고정해 두면 한쪽이 반이중으로 동작하며 부하가 걸릴 때마다 충돌로 패킷을 잃습니다.

왜 장비 한쪽만 속도·듀플렉스를 고정 설정 → 그러면 한쪽은 전이중, 다른 쪽은 반이중으로 동작해 충돌·늦은 충돌 발생 → 화면에서는 평소엔 멀쩡하다가 트래픽이 늘면 그 장비를 지나는 사람 모두가 멈췄다 몰아치기

증상: 멈춤, 몰아치기
요인: 손실
누가 겪나: 서버 전체, 특정 장소·채널
언제: 사람이 몰릴 때, 저녁 피크 시간
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라
인프라팀 할 일: 양쪽 모두 자동 협상 또는 양쪽 모두 같은 값으로 고정. 네트워크: 스위치 포트 상태에서 속도·듀플렉스 확인, 포트 카운터에서 반이중 쪽은 늦은 충돌, 전이중 쪽은 CRC 오류·너무 짧은 프레임(runt)이 느는지 확인. 서버 장비·OS: ethtool로 속도·듀플렉스 확인.
수치 감각: 1Gbps 구리선은 자동 협상이 필수이고 10Gbps 이상에는 반이중이 아예 없습니다. 그래서 요즘은 주로 100Mbps 이하의 오래된 장비, 관리용 포트, 일부 회선 연결 구간에서 생깁니다.
그래프에서는: 인원·부하를 따라 오름 · 포트 늦은 충돌·CRC 오류 수, 재전송률
확인할 곳: 링크 양쪽의 실제 속도·듀플렉스를 봄. 서버는 인터페이스 이름만 붙여 실행한 ethtool, 스위치는 포트 상태나 SNMP의 dot3StatsDuplexStatus. 늦은 충돌(서버 tx_window_errors, 스위치 dot3StatsLateCollisions)과 CRC 오류도 함께 봄
이러면 맞음: 한쪽은 반이중, 다른 쪽은 전이중으로 나옴. 트래픽이 늘 때마다 반이중 쪽은 늦은 충돌, 전이중 쪽은 CRC 오류가 함께 늘어남
이러면 아님: 양쪽 속도·듀플렉스가 같고 CRC만 늘면 “물리 오류”. 10Gbps 이상 링크는 반이중이 없으니 이 원인에서 뺌
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처

Linux Base Driver for Intel(R) Ethernet Network Connection Linux kernel
1000BASE-T 규격은 자동 협상을 요구함
IEEE 802.3ae 10 Gigabit Ethernet: HSSG Objectives IEEE
10기가비트 이더넷은 전이중만 지원
IEEE P802.3ba Objectives IEEE
40·100기가비트 이더넷도 전이중만 지원
Interface statistics Linux kernel
tx_window_errors는 늦은 충돌(late collision)로 실패한 전송 수, rx_crc_errors는 CRC 오류로 받은 패킷 수
ethtool(8) — Linux manual page ethtool
ethtool -s의 speed·duplex·autoneg로 속도·듀플렉스·자동 협상 설정, 인터페이스 이름만 주면 현재 설정을 보여 줌
RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
dot3StatsDuplexStatus(halfDuplex·fullDuplex로 현재 듀플렉스 표시), dot3StatsLateCollisions(늦은 충돌 수)

듀플렉스 불일치 Duplex mismatch

출처

함께 보면 좋은 원인

같은 층: TCP 재전송의 근본 원인

같은 증상(멈춤)의 다른 층 원인