인터페이스의 ifconfig 출력 컨텍스트 내에 ‘캐리어 오류’가 무엇인지에 대한 명확한 정의를 찾지 못했습니다. Google에서 검색 한 결과 실제로 큰 정의 나 문제를 일으키는 문제 목록이 없습니다.
나는 문맥에서 가정했는데, 이것은 이더넷 신호에 관한 것이 잘못되었음을 의미합니다. 상호 연결 케이블에 문제가 있거나 네트워크 인터페이스 / 포트가이 문제를 일으키는 것으로 의심됩니까?
이 카운터가 바뀌는 것을 거의 보지 못했지만 오늘 아침에 고객이 연락하여 네트워크 문제를 언급했습니다. 캐리어 카운터는 초당 약 200 씩 증가합니다. 그들은 최근 내가 관리하는 Linux 박스에 연결하는 장비를 약간 수정했습니다. 나는 그들에게 문제를 일으키는 원인에 대해 좀 더 구체적인 세부 사항을 줄 수 있기를 원합니다.
eth0 Link encap:Ethernet HWaddr 00:1b:21:f3:ea:ae
inet addr:172.16.0.9 Bcast:172.16.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13386121 errors:0 dropped:0 overruns:0 frame:0
TX packets:21255715 errors:1701 dropped:0 overruns:0 carrier:1031707
collisions:1313642 txqueuelen:1000
RX bytes:2467874046 (2.2 GiB) TX bytes:3820141165 (3.5 GiB)
따라서 ‘캐리어 오류’란 무엇이며 일반적인 오류는 무엇입니까?
답변
신호 변조에 문제가있는 경우 반송파 오류가 발생합니다.
이것은 하나 나타낼 수 이중 불일치 , 또는 물리적 케이블 / 커넥터에 문제가.
자동 협상을 다시 시작하고 이더넷 커넥터를 확인하면 문제를 해결할 수 있습니다.
답변
양쪽 끝에 서지 보호 장치가있는 두 건물 사이에 cat5e 이더넷 케이블이 있고 Linux를 기반으로하는 RouterOS에서보고 한대로 때때로 캐리어 오류가 발생합니다. 나는 우리가 단일 캐리어 오류없이 겨울 내내 갈 수 있기 때문에 대부분이 번개에 의한 것이라고 생각합니다. 그러면 봄이 오면 번개 폭풍이 생겨 20-30 개가 더있을 것입니다.
다른 쪽의 Cisco는 show int를 수행 할 때 “입력 오류”로보고합니다.
어쨌든 그들은 아무런 문제를 일으키지 않는 것 같습니다.
이더넷 보호 장치의 16V 이상을 접지에 고정시키는 서지 보호 장치의 부작용으로 생각됩니다. 이것이 이더넷 신호에 미치는 영향은 반송파 오류로 나타날 수 있습니다.
대부분의 경우 항복 전압이 높거나 서지 방지기를 전혀 사용하지 않는 서지 보호기는 장비 손상 위험이 증가함에 따라 발생하는 반송파 오류 수를 줄일 수 있습니다. IEEE 사양에 따라 이더넷 쌍에서 접지까지 1500V 절연이 실제로 있는지 테스트하는 것은 장비가 아니라 서지 보호기를 통해 서지 전압을 접지하는 것입니다.
답변
캐리어 오류는 OSI 모델의 물리적 수준에서 발생하는 문제에서 비롯됩니다. 에러는 시그널링을 처리하는 칩에 의해 발생된다 (반송파는 0과 1을 형성하도록 변조된다). 피어 간의 신호가 중단되면 “캐리어”오류가 발생합니다.
일반적으로 칩에 NLP (Normal Link Pulse)가 수신되지 않으면 반송파 오류가 발생합니다. NLP의 지속 시간은 100ns이므로 약간의 전기 중단이 발생해도 오류가 발생합니다. 해결 방법은 일반적으로 물리적 링크의 무결성을 확인하여 링크가 EMR 소스 근처에서 실행되지 않도록합니다.
잘못된 구성 (또는 빠른 링크 펄스 / FLP를 사용하는 자동 구성이 중단 된 경우)에도 동일한 증상이 발생할 수 있습니다. 자동 협상이 성공하면 반송파 오류가 중지됩니다. 자동 구성을 사용하지 않으면 잘못 구성하면이 숫자가 계속 증가합니다.
허브 패킷 충돌을 사용하면 동일한 증상이 발생할 수 있지만 스위치 대 허브의 가격으로 인해 오래된 장비 문제 만 발생합니다.