VPN 게이트웨이 포트의 듀플렉스 불일치: 양쪽 끝을 읽으십시오
속도는 협상하지만 듀플렉스는 협상하지 않는 10/100 포트는 부하 시 오류를 만듭니다. 양쪽 끝에서 동작 모드를 읽고 시간으로 구분한 카운터를 비교하십시오.
터널을 통한 파일 복사가 일 초쯤 멈췄다가 다시 진행되고, VPN 로그에는 아무것도 남지 않는다. 애플리케이션은 네트워크를 탓하고, 네트워크는 애플리케이션을 탓하며, 스위치 포트는 열한 달째 켜져 있다. 이 안내는 그 멈춤에서 시작해 물리 링크 쪽으로 바깥을 향한다. 포트가 실제로 무엇을 하는지, 반대편 끝이 무엇을 하는지, 그리고 지켜보는 동안 카운터가 무엇을 했는지 확인한다. 누군가 듀플렉스 설정을 건드리기 전에 해 둘 가치가 있다.
포트가 아니라 멈춤에서 시작하십시오
증상을 검증할 수 있는 형태로 적으십시오. 대량 전송 중 약 일 초의 정지는 연결이 재설정되는 것과 다른 문제이고, 한 시간에 한 번 생기는 멈춤은 몇 초마다 생기는 것과 다르다. 작업 부하와 방향, 대략적인 간격을 기록하십시오.
그런 다음 인터페이스를 보면서 재현하십시오. 물리적 문제는 해당 작업 부하 동안 카운터가 움직이는 모습으로 나타나고, 카운터를 전혀 움직이지 않는 문제는 링크 계층 위에 있을 가능성이 높다. 일 초가 아니라 일 분을 관찰하십시오. 이런 결함은 나타나기 전에 지속적인 트래픽이 필요한 경우가 많다. 유휴 상태의 모니터링은 부하에서만 나쁘게 동작하는 링크에 대해 아무것도 증명하지 못한다.
이것이 중요한 이유는 듀플렉스 불일치에 서명이 있기 때문이다. 부하 시에만, 트래픽 방향으로만 오류가 나타나고 작은 ping과 대화형 세션은 완벽하게 유지된다. 유휴 트래픽에서도 실패한다면 먼저 다른 곳을 찾아보십시오.
양쪽 끝에서 동작 모드를 읽으십시오
저장된 구성은 동작 상태가 아니다. 포트가 자동 협상으로 구성되어 있어도 절반 듀플렉스로 끝날 수 있고, 상대가 한 번도 동의하지 않은 고정 속도로 구성될 수도 있다. 링크가 지금 양쪽에서 무엇을 하고 있는지 읽으십시오.
ethtool eth0 ethtool -S eth0 | grep -iE 'error|drop|collision|fcs' ip -s link show eth0
속도, 듀플렉스, 자동 협상 여부를 적고, 인접 스위치나 공급자 포트에서 같은 세 가지 사실을 얻으십시오. 한쪽만으로는 아무것도 알 수 없다. 불일치는 설정이 아니라 관계이기 때문이다. 두 줄을 티켓에 나란히, 읽은 시각과 함께 적으십시오. 이 연습의 가치 절반은 두 판독값이 한곳에 모이는 데 있다.
반대편 끝을 읽을 수 없다면 이것을 진단할 수 없다. 소유자에게 동작 모드와 카운터를 요청하거나, 자기 쪽을 바꾸기 전에 접근을 마련하십시오.
10/100 절반 듀플렉스 사례는 어떻게 보이는가
10/100 구리 링크에서는 자동 협상하는 쪽이 강제 설정된 상대의 속도를 감지할 수 있지만 그 듀플렉스 설정은 배우지 못한다. 병렬 감지는 신호에서 속도를 결정하고, 듀플렉스는 협상되지 않고 가정되므로 한쪽은 절반 듀플렉스에 머물고 다른 쪽은 전이중으로 동작할 수 있다.
Cisco의 자동 협상 지침 이 바로 그 사례를 설명한다. 이것은 어디서나 협상을 끄라는 주장이 아니며, 기가비트 구리 링크에 대해서는 유용한 말을 하지 않는다. 거기서는 듀플렉스가 고정이고 링크가 올라오려면 자동 협상이 필요하다.
관찰 가능한 증거는 한 방향에만 존재하는 오류의 혼합이다. 전이중 쪽의 FCS 또는 CRC 오류, 절반 듀플렉스 쪽의 충돌 또는 지연 충돌, 그리고 부하에서 무너지는 처리량인데 유휴 시 지연은 정상으로 유지된다. 그 비대칭이 서명이다. 단지 과다 가입된 링크는 양방향에서 그리고 항상 나빠진다.
양쪽 끝을 함께 바꾸되 되돌릴 길을 두십시오
듀플렉스 수정은 조정된 변경이지 국소적 변경이 아니다. 반대편의 동의 없이 자기 쪽을 강제하는 것은 동작하는 링크를 깨진 링크로 만드는 방법이며, CLI가 명령을 받아들였다는 것은 구문이 유효했다는 것만 증명한다.
sudo ethtool -s eth0 speed 100 duplex full autoneg off ethtool eth0
그런 것을 실행하기 전에 플랫폼이 그 조합을 지원하는지, 반대편이 같은 시간 창에서 변경되는지 확인하십시오. 장치를 관리할 독립적인 경로를 유지하십시오. 바꾸려는 포트가 바로 당신의 관리 세션을 실어 나르는 포트일 수 있다.
많은 현대 링크에서 올바른 답은 무엇인가를 강제하는 대신 양쪽 끝에서 자동 협상을 켜 두는 것이다. 강제는 특정 기술의 특정 불일치에 대한 치료이지 일반적인 개선이 아니다. 특히 기가비트 구리는 링크가 올라오려면 자동 협상이 필요하므로 10/100 조언은 그대로 옮겨지지 않는다.
카운터가 더 나은 쪽으로 움직였는지 확인하십시오
변경 후 양쪽 끝에서 동작 상태를 다시 읽고 서로 일치하는지 확인하십시오. 그다음 멈춤을 일으킨 것과 같은 작업 부하를 실행하고 수명 누적 총계가 아니라 카운터 차이를 비교하십시오. 일 년 동안 쌓인 총계로는 지난 십 분에 무슨 일이 있었는지 알 수 없기 때문이다.
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs' ip -s link show eth0 ping -f -c 200 10.90.0.1
같은 부하에서 새 오류가 없는 링크가 바로 빠져 있던 증거다. 여전히 오류가 나는 링크, 또는 카운터가 처음부터 전혀 움직이지 않은 링크는 듀플렉스 논쟁을 더 깊이 파는 대신 다음 경계로 보낸다. 두 결과 모두 진전이며, 이는 구성 파일이 줄 수 있는 것보다 크다. 첫 판독값이 맞아 보였다고 두 번째 판독을 건너뛰지 마십시오.
변경 전후 숫자를 시각과 함께 티켓에 적으십시오. 그 기록이 «VPN이 더 좋아진 것 같다»를 다음 엔지니어가 딛고 설 수 있는 무엇으로 바꾼다.