이더넷 인터페이스 오류

ISP의 멀티플렉서에 연결되는 Ubuntu 서버 이더넷 인터페이스에 오류가 표시됩니다. 스냅 샷은 다음과 같습니다.

          RX packets:204564288 errors:3193970 dropped:0 overruns:0 frame:3138402
          TX packets:29305799 errors:38752 dropped:0 overruns:0 carrier:38762
          collisions:2205053 txqueuelen:1000

Ubuntu 인터페이스는 전이중 가능하지만 반이중 연결 만 협상합니다. 다른 장치 (라우터)를 MUX에 연결했을 때 이러한 오류도 표시되었습니다. 할당 된 대역폭은 50mbps이지만 20mbps 만 얻습니다. ISP는 MUX에서 장치 (이더넷 스위치 또는 허브 모양)를 변경하기를 꺼려합니다. ISP 엔지니어는 내 측면에서 결함이 있다고 비난합니다. 그러나 3 개 이상의 장치를 확인했는데 모두 오류가 표시되었습니다. 따라서 Linux에서 해당 오류의 원인을 자세히 조사하는 데 사용할 수있는 도구가 있습니까? 아니면 오류를 제거하기 위해 서버 인터페이스를 재구성하기 위해 할 수있는 작업이 있습니까?

ISP 이더넷 PHY에서 본질적으로 자동 협상을 비활성화하는 100-Full로 ISP 하드 코딩으로 인해 이중 불일치가 발생할 가능성이 큽니다.

ISP가 100-Full로 설정되어 있고 사용자 측이 자동 / 자동 (직감이지만 일반적인 것)으로 유지되면 사용자 측의 자동 협상은 인터페이스를 100-Half (ISP 측과의 이중 불일치)로 구성합니다. 100-Full로 유지됩니다.

고치다

Ethernet PHY를 100-Full로 또는 특히 ISP가 설정 한대로 하드 코딩하여 문제를 해결할 수 있습니다. 대부분의 ISP는 100-Full을 사용합니다.

추가 세부 사항

100-Full에서 100-Half의 이중 불일치로 100-Full면은 CSMA / CD를 비활성화하고 CSMA / CD는 100-Half면에 계속 적용됩니다. 100- 풀 사이드는 매체가 비어 있는지 여부에 관계없이 전송합니다. 100-Half 측은 CSMA / CD에서 정의한대로 CSMA / CD 점검 및 백 오프를 수행합니다. 그렇기 때문에 50Mb / s 인터넷 회로에서 20Mb / s 만 달성 할 수 있습니다 . 100-Half 쪽 충돌 감지로 인한 CSMA / CD 백 오프는 처리량을 제한합니다.

ISP에 맞게 인터페이스를 100-Full로 하드 코딩하면 양쪽에서 CSMA / CD가 비활성화되므로 백 오프 및 충돌 감지가 비활성화되고 50Mb / s 인터넷 회로 데이터 속도에 훨씬 근접한 숫자를 달성해야합니다.

역사

많은 ISP는 이더넷 PHY 핸드 오프를 하드 코딩하여 훨씬 안정적인 시간을 보냈습니다. 최초의 802.3u 100 Mb / s 고속 이더넷 표준이 발표되었을 때 속도와 자동 이중 협상이 있었지만 필수는 아닙니다 . 표준에 의해 자동 협상 이 필요할 때는 802.3z 1Gb / s 기가비트 이더넷 표준 이 되었습니다.

많은 네트워크 엔지니어는 자동 협상에 대한 오해를 가지고 있습니다. 가장 큰 오해는 한 쪽만 자동 협상을 구현하는 경우 자동 협상이 속도와 이중을 적절히 협상 할 수 있다는 것입니다. 당신이 본 것처럼 이것은 거짓입니다.

한 쪽이 100Full로 하드 코딩 된 경우 자동 협상을 실행하는 다른 쪽은 항상 100Mb / s 부분을 파악하는 것 같습니다. 한쪽이 10-Full로 하드 코딩 된 경우와 동일합니다. 자동 협상을 실행하는 다른 쪽은 10Mb / s 부분을 알아낼 수 있습니다. 링크 속도를 결정하는 기능은 병렬 감지 라는 기능에서 비롯 되며 일치하는 항목을 찾을 때까지 로컬에서 지원되는 모든 링크 속도에서 수신 된 물리 계층 신호를 시도합니다. 그러나 병렬 감지 는 속도에 대해서만 작동하며 이중 일치에는 적합하지 않습니다. 인터페이스가 자동 협상을 통해 다른 쪽을 결정할 수없는 경우 항상 반이중으로 되돌아 가기 때문에 이중 불일치가 발생할 수 있습니다.

비누 상자

한 번에 자동 협상에 대한 지원이 부족하여 해결하려는만큼 많은 문제가 발생했습니다. 그 당시이 네트워크 엔지니어의 견해로는 지나갔습니다. 자동 협상 문제가 여전히 존재하지만 지난 5 년 동안 자동 협상 이 구성 되어 발생하는 문제의 수는 자동 협상이 비활성화되어있어 본 문제의 수를 줄입니다.

나는 ISP가 이더넷 핸드 오프를 자동 / 자동으로 바꾸려고하지 않았다. 대부분의 케이블 및 DSL 모뎀 및 게이트웨이에서는 이것이 문제가되지 않습니다. 이더넷 핸드 오프 기능이있는 NxT1 및 파이버 관리 CPE 라우터는이 문제가 일반적으로 발생합니다. 문제는 네트워크 관리자가 먼저 문의해야한다는 것입니다.

ISP는 100-Full로 하드 코딩 하여 의무를 부여했습니다 . 문서화되고 계속되어야하는 의무. 자동 협상은 현재 안정적이고 수년 동안 사용되어 왔으며이 문제를 해결해주는 기술입니다. 앞에서 언급했듯이 자동 협상으로 인한 문제의 수는 2011 년에 비활성화 된 문제로 인해 발생하는 문제의 수보다 훨씬 큽니다.이 문제를 해결하기위한 기술이 있습니다. 아마도 초기 TCP SYN, MSS를 수동으로 설정하고 모든 TCP 가상 회로에 대한 수신 창을 관리해야합니까? 꼬마 야

랜트 오프.