이중 불일치

Duplex mismatch

이더넷 연결에서 이중 불일치는 두 개의 연결된 장치가 서로 다른 이중 모드에서 작동하는 상태, 즉 하나는 절반의 이중에서 작동하고 다른 하나는 전이중으로 작동하는 상태를 말한다. 이중 불일치의 효과는 비효율적으로 작동하는 연결고리다. 이중 불일치는 서로 다른 이중 모드에서 연결된 두 개의 네트워크 인터페이스를 수동으로 설정하거나 자동 협상을 수행하는 장치를 전이중 모드로 수동으로 설정된 장치에 연결함으로써 발생할 수 있다.[1]

자동 협상으로 인한 이중 불일치

자동 협상 세트로 설정된 장치가 자동 협상을 사용하지 않는 장치에 연결되면 자동 협상 프로세스가 실패하게 된다. 연결의 자동 조정 끝은 여전히 다른 쪽 끝의 속도를 정확하게 감지할 수 있지만, 이중 모드를 올바르게 감지할 수는 없다. 이더넷 허브와의 역호환성을 위해 표준은 이러한 조건에서 자동 협상 장치가 반 듀플렉스를 사용하도록 요구한다. 따라서, 연결의 자동 조정 끝은 비협상 피어가 전이중으로 잠겨 있는 동안 반이중으로 사용되며, 이는 이중 불일치다.

이더넷 표준과 주요 이더넷 장비 제조업체는 자동 협상을 활성화할 것을 권고한다.[2][3][4] 그럼에도 불구하고 네트워크 장비는 자동협상을 비활성화할 수 있도록 하며, 일부 네트워크에서는 모든 포트에서 자동협상을 비활성화하고 100Mbit/s의 고정모달성을 사용하며 전이중이 사용된다. 이는 종종 네트워크 관리자가 초기 자동 협상 규격과의 상호운용성 문제 때문에 자동 협상 도입 시 의도적으로 수행되었다. 고정된 작동 모드는 연결의 양쪽 끝이 동일한 설정으로 잠긴 경우 잘 작동한다. 그러나 이러한 네트워크를 유지하고 일관성을 보장하는 것은 어렵다. 자동 협상은 일반적으로 제조자의 기본 설정이기 때문에, 고정 포트 설정을 갖는 정책 환경에서 누군가가 조만간 실수로 자동 협업을 사용하기 위해 포트 세트를 떠날 것이 거의 확실하다.[5]

이중 불일치의 영향

이중 불일치에도 불구하고 연결을 통해 통신이 가능하다. 단일 패킷은 문제 없이 전송되고 인정된다. 그 결과, 1초 간격으로 단일 패킷과 그 결과의 수신확인이 네트워크에 아무런 문제를 일으키지 않기 때문에 단순한 ping 명령은 이중 불일치를 감지하지 못한다. 데이터를 천천히(매우 짧은 버스트) 전송하는 터미널 세션도 성공적으로 통신할 수 있다. 그러나, 어느 한쪽의 접속이 종료되는 순간, 네트워크는 갑자기 매우 낮은 속도로 느려진다. 네트워크가 다른 방식으로 작동하기 때문에, 원인은 그렇게 쉽게 드러나지 않는다.

이중 불일치는 연결의 양쪽 끝이 동시에 데이터 전송을 시도할 때 문제를 일으킨다. 이는 큰 데이터 전송의 경우 채널을 한 방향으로만 사용해도(높은 수준이나 사용자의 관점에서) 발생한다. 실제로, 대규모 데이터 전송이 TCP를 통해 전송될 때, 데이터는 여러 패킷으로 전송되며, 그 중 일부는 송신자에게 수신확인 패킷을 다시 트리거한다. 이로 인해 패킷이 동시에 양방향으로 전송된다.

이러한 조건에서 연결의 전이중 끝은 다른 패킷을 수신하는 동안 패킷을 전송한다. 이것이 정확히 전이중 연결의 포인트다. 한편, 반이중 끝은 송신하는 동안 들어오는 데이터를 받아들일 수 없다 – 충돌로 감지될 것이다. 반이중 장치는 현재의 데이터 전송을 중지하고 대신 잼 신호를 보낸 다음 CSMA/CD에 따라 나중에 재시도한다. 이로 인해 전이중 측에서 CRC 오류 또는 런트 프레임이 있는 불완전한 프레임을 수신하게 된다. 전이중 측에서 CSMA/CD가 비활성화되어 있어 충돌을 감지하지 못한다. 그 결과, 두 기기가 동시에 (거의) 전송을 시도하고 있을 때, 전이중 엔드에 의해 전송된 패킷은 가정된 충돌로 인해 폐기·분실되고, 반이중 장치에 의해 전송된 패킷은 프레임의 CRC 오류로 인해 지연·분실된다.[6]

손실된 패킷은 TCP 프로토콜이 오류 복구를 수행하도록 강제하지만 재전송된 패킷이 원래 패킷과 정확히 같은 방식으로 손실되기 때문에 초기(스트림링된) 복구 시도는 실패한다. 결국, TCP 전송 창은 꽉 차게 되고 TCP 프로토콜은 이전에 전송된 데이터가 인정될 때까지 더 이상의 데이터 전송을 거부한다. 이는 다시, 재전송과 수신확인만을 남겨두고, 연결을 통한 새로운 트래픽을 정지시킬 것이다. 재전송 타이머는 시도 사이에 점진적으로 길어지기 때문에, 결국 연결에 역방향 트래픽이 없을 때 재전송이 발생하고, 최종적으로 승인이 수신된다. 이렇게 하면 TCP 트래픽이 다시 시작되며, 이는 스트리밍이 재개되면서 즉시 패킷 손실을 야기한다.

최종 결과는 작동 중이지만 이중 불일치 때문에 극도로 낮은 성능을 보이는 연결이다. 이중 불일치의 증상은 ping 명령으로 잘 작동하는 것처럼 보이지만, 데이터 전송 처리량이 매우 낮아서 쉽게 "잠금"하는 연결이다. 효과적인 데이터 전송 속도는 비대칭적일 가능성이 높으며, 절반의 이중에서 다른 것보다 훨씬 더 나쁜 성능을 보인다. 일반적인 절반의 이중 작업에서는 늦은 충돌이 일어나지 않는다. 그러나 이중 불일치에서 링크의 반이중 측에서 보이는 충돌은 종종 늦은 충돌이다. 일반적으로 전이중 쪽은 프레임 검사 시퀀스 오류 또는 런트 프레임을 등록한다.[7][8] 이러한 표준 이더넷 통계를 보면 문제를 진단하는 데 도움이 될 수 있다.

합리적으로 예상할 수 있는 것과 반대로, 연결의 양쪽은 적절한 작동을 위해 동일하게 구성되어야 한다. 즉, 한쪽을 자동(속도 또는 이중 또는 둘 다)으로 설정하고 다른 쪽을 고정(속도 또는 이중 또는 둘 다)으로 설정하면 속도 불일치, 이중 불일치 또는 둘 다로 이어질 수 있다. 이중 불일치는 양 끝에 자동 협상(사용 가능한 경우 및 작동 중인 경우)을 활성화하거나 양 끝에 동일한 설정을 적용(구성 인터페이스 허용)하여 수정할 수 있다. 한쪽 끝에는 잠금 설정이 있고 다른 한쪽 끝에는 자동 협상(예: 관리되지 않는 스위치에 연결된 자동 협상 기능이 손상된 오래된 장치)이 있는 경우, 절반의 이중화 장치를 사용해야 한다. 모든 최신 LAN 장비는 자동 협상이 가능하고 다양한 호환성 문제가 해결되었다. 이중 불일치를 방지하는 가장 좋은 방법은 자동 협상을 사용하고 자동 협상을 사용하지 않거나 올바르게 자동 협상하지 않는 레거시 장비를 교체하는 것이다.

참조

  1. ^ "Switch Port Duplex Mismatch". Archived from the original on 2011-07-14. Retrieved 2011-02-15.
  2. ^ "Configuring and Troubleshooting Ethernet 10/100/1000Mb Half/Full Duplex Auto-Negotiation". Cisco. Retrieved 2012-01-12. Cisco recommends to leave auto-negotiation on for those devices compliant with 802.3u.
  3. ^ Jim Eggers and Steve Hodnett (July 2004). "Ethernet Autonegotiation Best Practices" (PDF). Sun Microsystems. Archived from the original (PDF) on 2011-05-20. Using autonegotiation is the IEEE 802.3 standard and customers are encouraged to follow the "intent" of IEEE 802.3u/z standards and implement autonegotiation in their Ethernet environments.
  4. ^ Rich Hernandez (2001). "Gigabit Ethernet Auto-Negotiation". Dell. Retrieved 2012-01-12.
  5. ^ "Autonegotiation on Ethernet – It Works, It Should Be Mandatory!". 2010-03-10. Retrieved 2012-10-12.
  6. ^ Gary A. Donahue (2007). Network Warrior. O'Reilly. p. 21. ISBN 978-0-596-10151-0.
  7. ^ US 6580697, "고급 이더넷 자동 협상"
  8. ^ Jim Eggers and Steve Hodnett (July 2004). "Ethernet Autonegotiation Best Practices" (PDF). Sun Microsystems. Retrieved 2011-02-18.

외부 링크