답변:
질문을 순서대로 해결하려면 :
이중 불일치가 발생하는 이유를 완전히 이해하려면 기술이 어떻게 발전했는지 이해해야합니다.
원래 모든 이더넷은 반이중이었습니다. 전이중이 그림에 들어갔을 때 누군가는 장치 (특히 반이중 및 전이중 장치)가 어떻게 통신하고 자동 협상을했는지에 대해 자신들이 서로 동의 할 수 있어야한다고 현명하게 결정했습니다.
그러나 이전 반이중 장치 중 어느 것도 자동 협상하도록 설계되지 않았으므로 표준을 작성할 때 다른 쪽이 협상에 참여하지 않으면 자동 협상 장치에서 표준을 작성해야합니다. 다른 쪽의 장치는 반이중 만 가능해야하기 때문에 반이중 모드입니다.
다른 사람들이 지적했듯이 자동 협상은 초기에 항상 잘 작동하지 않았으므로 많은 장치가 정적 속도 및 이중 설정 (종종 100 / 풀)으로 구성되었으며 협상 장치가 이러한 장치에 연결된 경우 이중 불일치가 발생합니다.
문제에 관해서는, 이중 불일치는 반이중 모드에서 실행하는 것보다 훨씬 나쁠 수 있습니다. 한 쪽 (전이중)은 현재 수신 중이라도 언제든지 전송할 수 있다고 생각하기 때문입니다. 반이중면은이를 충돌로 간주하고 다시 꺼지지 만 전이중면은 계속 전송합니다.
전이중 쪽이 많은 양의 데이터를 전송하는 경향이있는 경우, 반이중 쪽이 전송되기 전에 매체가 지워지기를 기다리면서 반이중 쪽을 "고갈"시켜서 프레임이 대기 상태가되어 결국 삭제됩니다.
대체로 나쁜 상황에 처해 있고 고쳐야 할 상황입니다.
불일치를 감지하는 경우 오류를 찾을 수 있습니다. 전이중 측면에서는 일반적으로 많은 런트와 종종 CRC 오류가 표시됩니다 (공급 업체는 때때로 다른 용어를 사용할 수 있음). 반이중면에는 종종 충돌 및 버퍼 오류가 나타납니다. 적절한 관리 시스템은 예상보다 많은 수의 오류를 생성하는 인터페이스 목록을 제공 할 수 있어야합니다.
요즘 가장 일반적인 원인은 한 시스템 (네트워크 또는 최종 장치)이 수동으로 구성되고 다른 시스템은 자동으로 연결되는 링크입니다.
자동 협상 초기 (전이중 10Mb 및 고속 이더넷)에서 장치가 올바르게 협상하지 못하는 경우는 드물지 않았습니다.
이로 인해 (및 다른 관성 관련 이유로) 많은 대기업 및 SP 네트워크는 일부 또는 모든 링크를 수동으로 구성해야했습니다.
요즘에는이 를 수행 할만한 근거 가 없으며 실제로 기가비트 이더넷 (최소한의 구리) 자동 협상이 필요하며 올바르게 작동하는 장치는이를 비활성화 할 수 없습니다. 예를 들어 gig 링크에서 일부 Cisco 키트 "비활성화"자동 협상을 통해 자동 협상 프로세스에서 허용되는 값이 제한되는 경우가 있습니다 (예기치 않은 인터페이스 속도를 경고하지 않는 경우 유용 할 수 있음) & 이중).
불일치는 링크의 한쪽이 명시 적으로 구성되고 다른 쪽이 자동 협상으로 설정된 경우에 가장 자주 발생합니다. 장치가 별도의 관리 상태에 있으면 상대방이 통신하지 않고 설정을 확인하지 못할 수 있습니다. 네트워크 연결에 미치는 영향은 사용량이 적은 링크에서 눈에 띄지 않고로드 량이 많은 링크에서 심각합니다. 가능하면 불일치를 해결하려는 노력은 일반적으로 가치가 있습니다. Cisco 스위치에서 255 미만의 인터페이스 안정성 표시기는 불일치를 발견하는 좋은 방법입니다. 이 값을 SNMP로 폴링하여 대규모 불일치를 감지 할 수 있습니다.