스위치 포트 및 인터페이스 문제 해결
목차
소개
이 문서에서는 포트 또는 인터페이스에서 문제가 생기는 이유를 파악하는 방법에 대해 설명합니다.
사전 요구 사항
요구 사항
이 문서에 대한 특정 요건이 없습니다.
사용되는 구성 요소
이 문서는 Cisco IOS® 시스템 소프트웨어에서 실행하는 Catalyst 스위치에 적용됩니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
표기 규칙
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.
물리적 레이어 문제 해결
LED를 활용하여 문제 해결
스위치에 물리적으로 액세스할 수 있는 경우 save 링크 상태를 제공하거나 오류 상태(빨간색 또는 주황색인 경우)를 나타낼 수 있는 포트 LED를 확인하는 데 걸리는 시간입니다. 다음 표에서는 이더넷 모듈 또는 고정 컨피그레이션 스위치의 LED 상태 표시기를 설명합니다.
| 플랫폼 | URL |
| Catalyst 6000 시리즈 스위치 |
|
| Catalyst 4000 시리즈 스위치 |
|
| Catalyst 3750 Series Switch |
|
| Catalyst 3550 Series 스위치 |
|
| Catalyst 2950/2955 시리즈 스위치 |
|
| Catalyst 2900/3500XL 시리즈 스위치 |
|
| Catalyst 1900 및 2820 시리즈 스위치 |
양쪽 모두 링크가 있는지 확인합니다. 한쪽의 선이 끊어져 있거나 포트가 종료 상태이면, 한쪽에 링크 표시등이 켜지고 다른 쪽에는 켜지지 않는 문제가 발생할 수 있습니다.
링크 표시등은 케이블이 온전히 작동한다고 보증하지 않습니다. 케이블에 물리적 스트레스가 발생하여 최소 수준으로 작동할 수도 있습니다. 일반적으로 포트에서 패킷 오류가 빈번하거나 포트 플랩 현상(링크가 끊겼다가 다시 연결됨)이 계속된다면 이러한 상황으로 볼 수 있습니다.
케이블 및 연결의 양쪽을 모두 확인합니다.
포트의 링크 표시등이 켜지지 않으면 다음과 같은 가능성을 고려할 수 있습니다.
| 가능한 원인 | 정정 작업 |
| 케이블이 연결되지 않음 |
스위치에서 정상 작동이 확인된 디바이스에 케이블을 연결합니다. |
| 잘못된 포트 |
케이블의 양쪽 끝이 정확한 포트에 꽂혀 있는지 확인합니다. |
| 디바이스에 전원이 들어오지 않음 |
양쪽 디바이스의 전원이 모두 켜져 있는지 확인합니다. |
| 잘못된 케이블 유형 |
선택한 케이블을 확인합니다. Catalyst Switch 케이블 가이드를 참조하십시오. |
| 불량 케이블 |
의심스로운 케이블을 정상 작동이 확인된 케이블로 바꿉니다. 커넥터에서 핀이 파손되었거나 빠져 있는지 확인합니다. |
| 느슨한 연결 |
연결이 느슨한지 확인합니다. 케이블이 잭에 장착된 듯 보이지만 그렇지 않은 경우도 있습니다. 케이블을 분리하고 다시 끼웁니다. |
| 패치 패널 |
결함 있는 패치 패널 연결을 제거합니다. 가능하다면 패치 패널을 우회하는 방식으로 제외합니다. |
| 미디어 컨버터 |
결함 있는 미디어 컨버터 제거: 파이버-구리 등 가능하다면 미디어 컨버터를 우회하는 방식으로 이를 제외합니다. |
| 불량 또는 잘못된 GBIC(Gigabit Interface Convertor) |
의심스러운 GBIC를 정상 작동이 확인된 GBIC로 바꿉니다. 해당 GBIC 유형에 대한 하드웨어 및 소프트웨어 지원을 확인합니다. |
| 포트 또는 모듈 포트 불량, 인터페이스 또는 모듈이 활성화되지 않음 |
의심스러운 포트 또는 모듈을 트러블슈팅하기 위해 케이블을 정상 작동이 확인된 포트로 이동합니다. Cisco IOS의 show interface 명령을 사용하여 errdisable, disable 또는 shutdown 상태를 확인합니다. show module 명령으로 하드웨어 문제일 수 있는 결함을 표시할 수 있습니다. 자세한 내용은 이 문서의 대표적인 포트 및 인터페이스 문제 섹션을 참조하십시오. |
이더넷 구리 및 파이버 케이블
사용하려는 연결 유형에 맞는 케이블인지 확인합니다. 범주 3 구리 케이블은 10Mbps UTP(Unshielded Twisted Pair) 연결에 사용할 수 있으나, 10/100Mbps 또는 10/100/1000Mbps UTP 연결에 사용해서는 안 됩니다. 10/100Mbps 또는 10/100/1000Mbps 연결에는 반드시 Category 5, category 5e 또는 Category 6 UTP를 사용합니다.
파이버 케이블의 경우 해당 거리 및 사용되는 파이버 포트 유형에 적합한 케이블인지 확인합니다. SMF(싱글 모드 파이버)와 MMF(멀티 모드 파이버)의 두 가지 옵션이 있습니다. 함께 연결된 디바이스의 포트가 둘 다 SMF 또는 MMF 포트인지 확인합니다.
이더넷 및 고속 이더넷 최대 전송 거리
| 트랜시버 속도 | Cable Type | 듀플렉스 모드 | 스테이션 간 최대 거리 |
| 10Mbps |
Category 3 UTP |
풀, 하프 |
328ft(100m) |
| 10Mbps |
MMF |
풀, 하프 |
1.2마일(2km) |
| 100Mbps |
Category 5 UTP Category 5e UTP |
풀, 하프 |
328ft(100m) |
| 100Mbps |
Category 6 UTP |
풀, 하프 |
328ft(100m) |
| 100Mbps |
MMF |
하프 |
1312ft(400m) |
| 전체 |
1.2마일(2km) |
||
| 100Mbps |
SMF |
하프 |
1312ft(400m) |
| 전체 |
6.2마일(10km) |
여러 유형의 케이블/커넥터, 케이블 요구 사항, 옵티컬 요구 사항(거리, 유형, 패치 케이블 등), 서로 다른 케이블을 연결하는 방법, 대부분의 Cisco 스위치 및 모듈에 쓰이는 케이블 유형에 대한 자세한 내용은 Catalyst 스위치 케이블 가이드를 참조하십시오.
기가비트 이더넷 문제 해결
디바이스 A가 기가비트 링크를 통해 디바이스 B에 연결되어 있는데 링크가 켜지지 않으면, 다음 절차를 수행합니다.
단계별 절차
-
디바이스 A와 디바이스 B가 같은 GBIC, 단파장(SX), 장파장(LX), 장거리(LH), 확장 파장(ZX) 또는 구리 UTP(TX)를 사용하는지 확인합니다. 두 디바이스 모두 같은 유형의 GBIC를 사용하여 링크를 설정해야 합니다. SX GBIC는 SX GBIC와 연결해야 합니다. SX GBIC는 LX GBIC와 연결되지 않습니다. 자세한 내용은 모드-컨디셔닝 패치 코드 설치 참고 사항에서 확인하십시오.
-
GBIC별 거리 및 사용된 케이블이 이 표의 내용과 부합하는지 확인합니다.
1000BASE-T 및 1000BASE-X 포트 케이블링 사양
| GBIC |
파장(nm) |
구리/파이버 유형 |
코어 크기1(미크론) |
모달 대역폭(MHz/km) |
케이블 거리2 |
| WS-G54831000Base - T(구리) |
Category 5 UTP Category 5e UTP Category 6 UTP |
328ft(100m) |
|||
| WS-G54841000BASE-SX3 |
850 |
MMF |
62.5 62.5 50.0 50.0 |
160 200 400 500 |
722ft(220m) 902ft(275 m) 1640ft(500m) 1804ft(550m) |
| WS-G54861000BASE-LX/LH |
1310 |
MMF4SMF |
62.5 50.0 50.0 8.3/9/10 |
500 400 500- |
1804ft(550m) 1804ft(550m) 1804ft(550m) 6.2마일(10km) |
| WS-G54871000BASE-ZX5 |
1550 |
MMF SMF6 |
8.3/9/10 8.3/9/10 |
43.5마일(70km)762.1마일(100km) |
-
멀티 모드 광섬유 케이블에 지정된 숫자는 코어 지름을 나타냅니다. 단일 모드 광섬유 케이블의 경우, 8.3미크론이 코어 지름입니다. 9미크론 및 10미크론 값은 MFD(mode-field diameter)이며, 광 전송인 파이버 부위의 지름입니다. 이 영역은 파이버 코어 및 클래딩을 덮는 작은 부분으로 구성됩니다. MFD는 코어 지름, 레이저 파장, 코어와 피복 간 굴절률 차이의 함수입니다.
-
거리는 파이버 손실에 따라 결정됩니다. 스플라이스가 많고 광섬유 케이블이 표준에 미달하면 케이블 거리가 줄어듭니다.
-
MMF에만 사용합니다.
-
62.5미크론 지름 MMF와 함께 LX/LH GBIC를 사용하는 경우, 링크의 트랜스밋 엔드 및 리시브 엔드 모두에서 GBIC와 MMF 케이블의 사이에 모드-컨디셔닝 패치 코드(CAB GELX-625 또는 동급)를 설치해야 합니다. 모드-컨디셔닝 패치 코드는 링크 거리가 328피트(100m)보다 짧거나 984피트(300m)보다 길 때 필수 조건입니다. 모드-컨디셔닝 패치 코드가 있으면, 짧은 MMF 길이에서 수신기가 과용되지 않고 긴 MMF 거리에서 차등 모드 지연이 줄어듭니다. 자세한 내용은 모드-컨디셔닝 패치 코드 설치 참고 사항에서 확인하십시오.
-
SMF에만 사용합니다.
-
분산-편이 단일 모드 광섬유 케이블.
-
링크의 각 끝에 8dB 감쇠기가 설치된 상태에서 ZX GBIC의 최소 링크 거리는 6.2마일(10km)입니다. 감쇠기가 없을 경우 최소 링크 거리는 24.9마일(40km)입니다.
3. 두 디바이스 중 하나에 여러 기가비트 포트가 있는 경우 포트를 서로 연결합니다. 이렇게 각 디바이스를 테스트하고, 기가비트 인터페이스가 올바르게 작동하는지 확인합니다. 예컨대 스위치에 기가비트 포트 2개가 있다고 가정합니다. 기가비트 포트 1을 기가비트 포트 2에 연결합니다. 링크가 켜집니까? 그렇다면 포트는 정상입니다. STP는 포트에서 차단하고 어떤 루프도 방지합니다(포트 1 리시브(RX)가 로트 2 트랜스밋(TX)에 연결, 포트 1 TX가 포트 2 RX에 연결).
4. SC 커넥터에서 단일 연결 또는 3단계에 장애가 발생하면 포트를 다시 자체 루프하십시오(포트 1 RX는 포트 1 TX로 이동). 포트가 켜집니까? 그렇지 않으면, 포트 결함일 수 있으므로 TAC에 문의하십시오.
5. 단계 3과 4는 정상적으로 수행되지만 장치 A와 B를 연결할 수 없는 경우 두 장치를 연결하는 케이블로 포트를 루프합니다. 케이블에 결함이 없는지 확인합니다.
6. 각 장치가 기가비트 자동 협상을 위한 802.3z 사양을 지원하는지 확인합니다. 기가비트 이더넷에는 10/100 이더넷에 사용되는 절차(기가비트 자동 협상 사양: IEEE Std 802.3z-1998)보다 더 광범위한 자동 협상 절차가 있습니다. 링크 협상을 활성화하면 시스템은 플로우 제어, 듀플렉스 모드, 원격 결함 정보를 자동 협상합니다. 링크의 양쪽 끝에서 링크 협상을 활성화하거나 비활성화해야 합니다. 링크의 양쪽 끝이 같은 값으로 설정되어야 합니다. 그렇지 않으면 링크를 연결할 수 없습니다. IEEE 802.3 z 표준이 승인되기 전에 생산된 디바이스에 연결할 때 문제가 발생했습니다. 어떤 디바이스도 기가비트 자동 협상을 지원하지 않는 경우 기가비트 자동 협상을 비활성화합니다. 그러면 링크가 강제로 켜집니다. 카드 펌웨어가 10/100/1000BASE-T-TX 링크/포트가 꺼져 있음을 소프트웨어에 알리는 데 300밀리초가 걸립니다. 300밀리초 기본 디바운스 타이머는 펌웨어 폴링 타이머에서 라인카드까지이며, 300밀리초 단위로 발생합니다. 이 링크가 1G(1000BASE-T-TX) 모드에서 실행되는 경우, 10밀리초마다 기가비트 동기화가 수행되므로 링크 중단을 더 빨리 탐지할 수 있습니다. 구리에서 GigabitEthernet을 실행할 때와 파이버에서 GigabitEthernet을 실행할 때 링크 실패 탐지 시간이 달라집니다. 이 탐지 시간 차이는 IEEE 표준을 기반으로 합니다.
GigabitEthernet 시스템 요구 사항과 GBIC(Gigabit Interface Converter), CWDM(Coarse Wavelength Division Multiplexing) 및 SFP(Small Form-Factor Pluggable) 시스템 요구 사항은 다음 문서를 참조하십시오.
일반적인 설정 정보 및 문제 해결 방법에 관한 추가 정보에 대해서는 이더넷 10/100/1000MB 하프(half)/풀 듀플렉스(full-duplex) 자동 협상의 설정 및 문제 해결을 참조하십시오.
연결 vs 비연결
대부분 Cisco 스위치는 notconnect 상태의 포트가 있습니다. 이는 현재 어디에도 연결되지 않았지만, 가동 중인 다른 디바이스와의 연결이 양호한 경우 연결될 수 있다는 뜻입니다. 정상인 케이블을 비연결 상태의 스위치 포트 2개에 연결할 경우, 두 포트 모두 링크 표시등이 녹색으로 바뀌고 포트 상태는 연결됨으로 나타나야 합니다. 즉, L1(Layer 1)이 연결되면 포트가 작동함을 의미합니다.
Cisco IOS에서는 show interfaces 명령을 사용하여 인터페이스가 up, line protocol is up (connected) 상태인지 확인할 수 있습니다. 첫 번째 up은 인터페이스의 물리적 레이어 상태를 나타냅니다. line protocol up 메시지는 인터페이스의 데이터 링크 레이어 상태를 보여주며, 인터페이스에서 keepalive를 보내고 받을 수 있음을 나타냅니다.
Router#show interfaces fastEthernet 6/1 FastEthernet6/1 is down, line protocol is down (notconnect)!--- Reasons: In this case, !--- 1) A cable is not properly connected or not connected at all to this port. !--- 2) The connected cable is faulty. !--- 3) Other end of the cable is not connected to an active port or device. !--- Note: For gigabit connections, GBICs need to be matched on each !--- side of the connection. !--- There are different types of GBICs, depends on the cable and !--- distances involved: short wavelength (SX), !--- long-wavelength/long-haul (LX/LH) and extended distance (ZX). !--- An SX GBIC needs to connect with an SX GBIC; !--- an SX GBIC does not link with an LX GBIC. Also, some gigabit !--- connections require conditioning cables, !--- that depend on the lengths involved.
Router#show interfaces fastEthernet 6/1 FastEthernet6/1 is up, line protocol is down (notconnect)
!--- The interface is up (or not in a shutdown state), but line protocol down. !--- Reason: In this case, the device on the other side of the wire is a !--- CatOS switch with its port disabled.
Router#show interfaces fastEthernet 6/1 status Port Name Status Vlan Duplex Speed Type Fa6/1 notconnect 1 auto auto 10/100BaseTX
show interfaces에 up/line protocol up(connected)이 표시되지만 두 명령의 출력에서 오류가 증가하는 경우 이 문서의 Common Port and Interface Problems 섹션을 참조하십시오.
Cisco IOS의 대표적인 포트 및 인터페이스 명령 문제 해결
다음 표에서는 Supervisor에서 Cisco IOS 시스템 소프트웨어를 실행하는 스위치의 포트 또는 인터페이스 문제를 해결하는 데 가장 많이 쓰이는 명령을 소개합니다.
Cisco 디바이스에서 지원되는 명령을 실행하여 출력을 얻는 경우, Cisco CLI Analyzer를 활용하여 잠재적인 문제와 해결 방법을 표시할 수 있습니다.
| Cisco IOS 명령 | 설명 |
| show version |
이 명령은 Cisco 라우터와 비슷한 출력, 즉 소프트웨어 이미지 이름, 버전 정보, 시스템 메모리 크기 등을 표시합니다. 소프트웨어/하드웨어 비호환성 검색(릴리스 노트 또는 Software Advisor 사용) 및 버그 검색(버그 검색 도구 사용)에 유용합니다. 
참고: 등록된 Cisco 사용자만 내부 Cisco 툴 및 정보에 액세스할 수 있습니다. |
| show module |
이 명령은 스위치에 있는 카드, 실행 중인 소프트웨어의 버전, 모듈의 상태(정상, 결함 등)를 표시합니다. 모듈 또는 포트에서 하드웨어 문제를 진단하는 데 도움이 됩니다. show module 명령으로 하드웨어 문제를 해결하는 방법에 대한 자세한 내용은 이 문서의 포트 또는 인터페이스 상태가 사용 안 함으로 설정되었거나 종료되었거나 하드웨어 문제 섹션을 참조하십시오. |
| show run-config |
이 명령은 스위치의 현재 설정 파일을 표시합니다. 변경 사항 |
| show interfaces |
show interface 명령은 스위치 포트의 관리 및 운영 상태, 입출력 패킷, 버퍼 실패, 오류 등을 표시합니다. |
| clear counters |
트래픽과 오류 카운터를 0으로 만들려면 clear counters 명령을 사용하여 문제가 일시적인지, 카운터가 계속 증가하는지 확인할 수 있습니다.
참고: Catalyst 6500/6000 Series 스위치에서는 clear counters명령으로 인터페이스의 비트 카운터를 지우지 않습니다 . 이 스위치에서 비트 카운터를 지우려면 다시 로드할 수밖에 없습니다. |
| show interfaces counters |
Catalyst 6000, 4000, 3550, 2950 및 3750 시리즈에서 사용하는 명령입니다. |
| show counters interface show controllers ethernet-controller |
show counters interface 명령은 Catalyst 6000 시리즈용 소프트웨어 버전 12.1(13)E에만 도입되었으며 32비트 및 64비트 오류 카운터를 표시합니다. 2900/3500XL, 2950/2955, 3550, 2970 및 3750 시리즈 스위치의 Cisco IOS의 경우 show controller Ethernet-controller 명령은 폐기된 프레임, 지연된 프레임, 정렬 오류, 충돌 등을 표시합니다. |
| show interfaces counters |
Catalyst 6000, 4000, 3550, 2950 및 3750 시리즈에서 사용하는 명령입니다. |
| show diagnostic(s) show post |
명령 show diagnostic은 Catalyst 6000 Series의 경우 12.1(11b)E에 도입되었고, show diagnostics(s 포함)는 Catalyst 4000 Series에 도입되었습니다. 2900/3500XL, 2950/2955, 3550, 2970 및 3750 시리즈 스위치에서 동등한 명령은 show post이며 스위치 POST의 결과를 표시합니다. Catalyst 스위치에서 발생하는 하드웨어 관련 오류의 문제 해결에 대한 자세한 내용은 이 문서의 하드웨어 문제 섹션을 참조하십시오. |
Cisco IOS의 특정 포트 및 인터페이스 카운터 출력에 대한 이해
대부분 스위치는 포트 또는 인터페이스에서 발생하는 패킷 및 오류를 추적하는 방법이 있습니다. 이러한 유형의 정보를 찾기 위해 많이 사용하는 명령이 이 문서의 Cisco IOS의 대표적인 포트 및 인터페이스 문제 해결 명령 섹션에 나와 있습니다.
어떤 카운터에서 지나치게 많은 오류가 발생한다면 대개는 문제가 있는 것입니다. 하프 듀플렉스(half duplex) 설정에서 작동할 때 FCS(Frame Check Sequence), alignment, runts, collision 카운터에서 일부 데이터 링크 오류가 증가하는 것은 정상입니다. 일반적으로 하프 듀플렉스 연결에서는 전체 트래픽 대비 오류의 비율이 1%라면 괜찮습니다. 입력 패킷 대비 오류의 비율이 2~3%를 초과할 경우 성능 저하가 나타날 수 있습니다.
하프 듀플렉스 환경에서는 스위치 및 연결된 디바이스가 정확히 동시에 회선을 감지하고 전송하는 바람에 충돌이 발생할 수 있습니다. 충돌이 발생하면, 프레임이 회선으로 완전히 복사되지 않아 runts, FCS, alignment 오류가 발생할 수 있습니다. 그러면 프레임이 프래그먼트화됩니다.
풀 듀플렉스에서 작동하는 경우 FCS, CRC(Cyclic Redundancy Checks), 맞춤, 런트 카운터의 오류를 최소화해야 합니다. 링크가 풀 듀플렉스에서 작동하는 경우 충돌 카운터는 활성화되지 않습니다. FCS, CRC, 맞춤 또는 런트 카운터가 증가하는 경우 듀플렉스 불일치가 일어났는지 확인합니다. 듀플렉스 불일치는 스위치가 풀 듀플렉스에서, 연결된 디바이스는 하프 듀플렉스에서 작동하는 경우 또는 그 반대의 상황을 가리킵니다. 듀플렉스 불일치가 일어나면 성능이 매우 느려지고 간헐적으로 연결되고 연결이 끊기기도 합니다. 풀 듀플렉스에서 데이터 링크 오류가 발생하는 또 다른 이유로는 불량 케이블, 결함 있는 스위치 포트, NIC 소프트웨어/하드웨어 문제 등이 있습니다. 자세한 내용은 이 문서의 대표적인 포트 및 인터페이스 문제 섹션을 참조하십시오.
Cisco IOS의 show interfaces
show interfaces card-type {slot/port}명령은 Supervisor에서 Cisco IOS에 사용되는 명령이며 오류 카운터 및 통계를 표시합니다. 이 명령(Catalyst 6000, 4000, 3550, 2970 2950/2955 및 3750 시리즈 스위치의 경우)의 대안은 인터페이스 오류 카운터만 표시하는 show interfacecard-type <slot/port> counters errors 명령입니다. 오류 카운터 출력에 대한 설명은 표 1을 참조하십시오.
Router#sh interfaces fastEthernet 6/1
FastEthernet6/1 is up, line protocol is up (connected)
Hardware is C6k 100Mb 802.3, address is 0009.11f3.8848 (bia 0009.11f3.8848)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Full-duplex, 100Mb/s
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:14, output 00:00:36, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
show interfaces 명령의 출력에서 이 지점까지의 내용을 순서대로 설명하면 다음과 같습니다.
-
up, line protocol is up (connected) - 첫 번째 up은 인터페이스의 물리적 레이어 상태를 나타냅니다. line protocol up 메시지는 인터페이스의 데이터 링크 레이어 상태를 보여주며, 인터페이스에서 keepalive를 보내고 받을 수 있음을 나타냅니다.
-
MTU - 기본적으로 이더넷의 MTU(Maximum Transmission Unit)는 1500바이트입니다(프레임의 최대 데이터 부분).
-
Full-duplex, 100Mb/s - 인터페이스의 현재 듀플렉스 설정 및 속도는 풀 듀플렉스(full-duplex) 및 100Mbps입니다. 여기서는 이 결과를 얻기 위해 autoneg를 사용했는지 여부를 알 수 없습니다. show interfaces fastEthernet 6/1 status 명령을 사용하여 다음을 표시합니다.
Router#show interfaces fastEthernet 6/1 status Port Name Status Vlan Duplex Speed Type Fa6/1 connected 1 a-full a-100 10/100BaseTX
!--- Autonegotiation was used to achieve full-duplex and 100Mbps.
-
Last input, output - 인터페이스에서 마지막 패킷을 성공적으로 수신하거나 전송한 시점 이후에 경과한 시간, 분, 초입니다. 이는 무반응 인터페이스에서 실패한 시점을 파악하는 데 유용합니다.
-
Last clearing of show interface counters - 스위치를 마지막으로 리부팅한 이후 clear counters 명령을 마지막으로 실행한 시간입니다. clear counters 명령을 사용하여 인터페이스 통계를 재설정합니다.
-
Input queue - 입력 대기열의 패킷 수입니다.Size/max/drops= 대기열의 현재 프레임 수 / 프레임 삭제를 시작하기 전에 대기열이 유지할 수 있는 최대 프레임 수 / 최대 대기열 크기를 초과하여 삭제된 실제 프레임 수 플러시는 Cisco IOS를 실행하는 Catalyst 6000 Series에서 SPD(Selective Packet Discard) 삭제를 계산하는 데 사용됩니다. 플러시 카운터는 사용할 수 있지만 Cisco IOS를 실행하는 Catalyst 4000 Series에서는 증분되지 않습니다. SPD는 CPU가 오버로드될 때 우선 순위가 낮은 패킷을 빠르게 삭제하는 메커니즘입니다.
save우선 순위가 높은 패킷의 일부 프로세스 용량. show interface 명령 출력의 플러시 카운터는 라우터의 IP 프로세스 대기열에 대해 선택적 패킷 삭제 정책을 이행하는 SPD의 일환으로 증가합니다. 따라서 프로세스 스위칭된 트래픽에만 적용됩니다.SPD의 목적은 IP 입력 대기열이 꽉 차더라도 라우팅 업데이트, keepalive와 같은 중요한 제어 패킷이 삭제되지 않게 하는 것입니다. IP 입력 대기열의 크기가 최소 임계값과 최대 임계값의 사이에 있으면, 특정 삭제 확률에 따라 일반 IP 패킷이 삭제됩니다. 이러한 임의 삭제를 SPD 플러시라고 합니다.
-
Total output drops - 출력 대기열이 꽉 차서 삭제된 패킷의 수입니다. 일반적인 원인은 고대역폭 링크에서 더 낮은 대역폭 링크로 스위칭되는 트래픽 또는 여러 인바운드 링크에서 단일 아웃바운드 링크로 스위칭되는 트래픽입니다. 예를 들어 대량의 트래픽 플로우가 기가비트 인터페이스에 도달하여 100Mbps 인터페이스로 스위칭되는 경우, 그로 인해 100Mbps 인터페이스에서 출력 삭제가 증가할 수 있습니다. 이는 인바운드 대역폭과 아웃바운드 대역폭의 속도가 일치하지 않아 해당 인터페이스의 출력 대기열에 과도한 트래픽이 발생하기 때문입니다.
-
Output queue - 출력 대기열에 있는 패킷의 수입니다. Size/max는 현재 대기열에 있는 프레임의 수/대기열이 꽉 차서 프레임 삭제를 시작해야 하는 시점까지 수용 가능한 최대 프레임 수입니다.
-
5 minute input/output rate - 지난 5분간 인터페이스에서 확인한 평균 입출력 속도입니다. 정확한 읽기(예: 트래픽 버스트를 더 잘 탐지하고 load-interval <seconds> interface 명령을 실행하려면 더 짧은 시간을 지정합니다.
오류 카운터 출력에 대한 설명은 표 1을 참조하십시오.
!--- ...show interfaces command output continues.
1117058 packets input, 78283238 bytes, 0 no buffer
Received 1117035 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
285811 packets output, 27449284 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
show interfaces <card-type> <slot/port> counters errors 명령은 Cisco IOS에서 인터페이스 오류의 출력만 표시하는 데 사용됩니다. 오류 카운터 출력에 대한 설명은 표 1을 참조하십시오.
Router#show interfaces fastEthernet 6/1 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Fa6/1 0 0 0 0 0 0 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants Fa6/1 0 0 0 0 0 0 0
표 1. show interface 또는 show interface에 대한 Cisco IOS 오류 카운터 출력 < card-type> <x/y> 는 Catalyst 6000 및 4000 Series의 오류를 측정합니다.
| 카운터(알파벳순) | 오류 카운터를 늘리는 문제 및 일반적인 원인 |
| 맞춤-오류 |
설명: show interfaces counters errors. 정렬 오류는 수신된 프레임 수 중 짝수 옥텟으로 끝나지 않고 CRC(Cyclic Redundancy Check)가 잘못된 프레임 수의 카운트입니다. 일반적인 원인: 일반적으로 이중 불일치나 물리적 문제(예: 케이블링, 잘못된 포트 또는 잘못된 NIC)가 원인입니다. 케이블이 포트에 처음 연결되면 이러한 오류 중 일부가 발생할 수 있습니다. 또한 포트에 연결된 허브가 있는 경우, 허브에 있는 다른 디바이스 간의 충돌로 인해 이러한 오류가 발생할 수 있습니다. 플랫폼 예외: 맞춤 오류는 Catalyst 4000 시리즈 Supervisor I(WS-X4012) 또는 Supervisor II(WS-X4013)에서 카운트되지 않습니다. |
| babbles |
설명: show interfaces counter. 트랜스밋 Jabber 타이머가 만료되었음을 나타냅니다. Jabber는 1518 octet보다 길고(프레임 비트는 제외하지만 FCS octet은 포함함), 짝수 개수의 octet으로 끝나지 않거나(맞춤 오류) 불량 FCS 오류가 있는 프레임입니다. |
| Carri-Sen |
설명: show interfaces counters errors. Carri-Sen(carrier sense) 카운터는 이더넷 컨트롤러가 하프 듀플렉스(half duplex) 연결에서 데이터를 보내려고 할 때마다 증가합니다. 컨트롤러가 회선을 감지하고, 전송하기 전에 사용 중이 아닌지를 확인합니다. 일반적인 원인: 하프 듀플렉스(half duplex) 이더넷 세그먼트에서는 정상적인 상황입니다. |
| collisions |
설명: show interfaces counter. 인터페이스에서 미디어에 성공적으로 프레임을 전송하기 전에 충돌이 발생한 횟수입니다. 일반적인 원인: 하프 듀플렉스(half duplex)로 설정된 인터페이스에서는 충돌이 정상이지만, 풀 듀플렉스(full-duplex) 인터페이스의 경우 나타나서는 안 됩니다. 충돌이 크게 증가한다면, 링크 사용량이 많다는 뜻입니다. 또는 연결된 디바이스와 듀플렉스가 일치하지 않을 수도 있습니다. |
| CRC |
설명: show interfaces counter. 트래픽을 발생시키는 LAN 스테이션 또는 최종단 디바이스에서 생성된 CRC가 수신된 데이터에서 계산된 체크섬과 일치하지 않을 때 증가합니다. 일반적인 원인: 대개 LAN 인터페이스 또는 LAN 자체의 노이즈 또는 전송 문제를 나타냅니다. CRC 개수가 많으면, 대개는 충돌이 원인이지만 물리적 문제(예: 케이블링, 불량 인터페이스 또는 NIC) 또는 듀플렉스 불일치를 의미할 수도 있습니다. |
| deferred |
설명: show interfaces counter. 미디어가 사용 중이었기 때문에 대기했다가 성공적으로 전송된 프레임의 수입니다. 일반적인 원인: 통신 사업자가 이미 사용 중인 상태에서 프레임 전송을 시도하는 하프 듀플렉스(half duplex) 환경에서 주로 나타납니다. |
| 입력 일시 중지 |
설명: show interfaces counter. pause input 카운터가 증가하면 수신 버퍼가 거의 찼을 때 연결된 디바이스의 트래픽 요청이 일시 중지하는 것을 의미합니다. 일반적인 원인: 이 카운터는 스위치에서 프레임을 허용하므로 정보 제공의 목적으로 증가합니다. 연결된 디바이스에서 트래픽을 수신할 수 있을 때 pause packets가 중지됩니다. |
| input packets with dribble condition |
설명: show interfaces counter. dribble 비트 오류는 프레임이 너무 길 때 나타납니다.일반적인 원인: 이러한 프레임 오류 카운터는 스위치에서 프레임을 허용하므로 정보 제공의 목적으로 증가합니다. |
| Excess-Col |
설명: show interfaces counters errors. 과도한 충돌로 인해 특정 인터페이스에서 전송이 실패하는 프레임의 수입니다. 어떤 패킷에서 연속으로 16회 충돌이 있으면 과도한 충돌로 간주합니다. 그런 다음 패킷은 삭제됩니다. 일반적인 원인: 과도한 충돌은 대개 세그먼트의 로드를 여러 세그먼트로 분할할 필요성을 나타냅니다. 또는 연결된 디바이스와의 듀플렉스 불일치를 가리킬 수도 있습니다. 풀 듀플렉스로 구성된 인터페이스에서는 충돌이 나타나서는 안 됩니다. |
| FCS-Err |
설명: show interfaces counters errors. FCS(Frame Check Sequence) 오류가 있지만 프레임 오류는 없는, 유효한 크기의 프레임 개수입니다. 일반적인 원인: 대개 케이블링, 불량 포트 또는 불량 NIC(Network Interface Card)와 같은 물리적 문제지만 듀플렉스 불일치를 나타내는 것일 수도 있습니다. |
| 프레임 |
설명: show interfaces counter. CRC 오류가 있고 옥텟 개수가 정수가 아닌(맞춤 오류), 잘못 수신된 패킷의 수입니다. 일반적인 원인: 대개 충돌 또는 물리적 문제(예: 케이블링, 불량 포트 또는 NIC)가 원인이지만, 듀플렉스 불일치를 의미할 수도 있습니다. |
| Giants |
설명: show interfaces 및 show interfaces counters errors. 최대 IEEE 802.3 프레임 크기(비 점보 이더넷은 1518바이트)를 초과하고 불량 FCS(Frame Check Sequence)가 있는, 수신된 프레임입니다. 일반적인 원인: 대개는 불량 NIC가 원인입니다. 문제의 디바이스를 찾아 네트워크에서 제거하십시오. 플랫폼 예외: Cisco IOS Previous to software Version 12.1(19)EW를 실행하는 Catalyst Cat4000 Series는 프레임 당 1518바이트 이상 증가하는 자이언트 카운터입니다. 12.1(19)EW부터는 1518바이트를 초과하고 불량 FCS가 있는 프레임을 수신할 때만 show interfaces의 giant가 증가합니다. |
| 무시됨 |
설명: show interfaces counter. 인터페이스 하드웨어의 내부 버퍼가 부족해진 까닭에 인터페이스에서 무시한 수신된 패킷의 수입니다. 일반적인 원인: 브로드캐스트 스톰 및 소음 버스트 때문에 ignored 카운트가 증가할 수 있습니다. |
| Input errors |
설명: show interfaces counter. 일반적인 원인: 여기에는 runts, giants, no buffer, CRC, frame, overrun, ignored 카운트가 포함됩니다. 다른 입력 관련 오류 때문에 입력 오류 카운트가 증가할 수도 있으며, 일부 데이터그램에서 둘 이상의 오류가 발생할 수 있습니다. 따라서 이 합계는 열거된 입력 오류 카운트의 합계와 일치할 수 없습니다. 레이어 2 스위치포트에 연결된 레이어 3 인터페이스의 입력 오류 섹션도 참조하십시오. |
| Late-Col |
설명: show interfaces 및 show interfaces counterserr. 전송 프로세스의 후반에 특정 인터페이스에서 충돌이 탐지되는 횟수입니다. 10Mbit/s 포트의 경우 패킷 전송에서 512비트 시간(bit-time) 이후입니다. 10Mbit/s 시스템에서 512비트 시간은 51.2마이크로초에 해당합니다. 일반적인 원인: 이 오류는 여러 상황 중에서도 듀플렉스 불일치를 의미할 수 있습니다. 듀플렉스 불일치 시나리오의 경우 하프 듀플렉스(half duplex)에서 지연 충돌이 나타납니다. 하프 듀플렉스(half duplex) 측이 전송하고 있을 때 풀 듀플렉스(full-duplex) 측은 순서를 기다리지 않고 동시에 전송합니다. 그로 인해 지연 충돌이 발생합니다. 지연 충돌은 이더넷 케이블 또는 세그먼트가 너무 길다는 의미일 수도 있습니다. 풀 듀플렉스로 구성된 인터페이스에서는 충돌이 나타나서는 안 됩니다. |
| lost carrier |
설명: show interfaces counter. 반송파가 전송 중에 사라진 횟수입니다. 일반적인 원인:케이블이 불량인지 확인합니다. 양쪽의 물리적 연결을 확인합니다. |
| Multi-Col |
설명: show interfaces counters errors. 인터페이스에서 미디어에 성공적으로 프레임을 전송하기 전에 다중 충돌이 발생한 횟수입니다. 일반적인 원인: 하프 듀플렉스(half duplex)로 설정된 인터페이스에서는 충돌이 정상이지만, 풀 듀플렉스(full-duplex) 인터페이스의 경우 나타나서는 안 됩니다. 충돌이 크게 증가한다면, 링크 사용량이 많다는 뜻입니다. 또는 연결된 디바이스와 듀플렉스가 일치하지 않을 수도 있습니다. |
| no buffer |
설명: show interfaces counter. 버퍼 공간이 없어 삭제한 수신된 패킷의 수입니다. 일반적인 원인: ignored 카운트와 비교됩니다. 대개 이러한 이벤트는 브로드캐스트 스톰이 원인일 수 있습니다. |
| no carrier |
설명: show interfaces counter. 전송에 반송파가 없던 횟수입니다. 일반적인 원인:케이블이 불량인지 확인합니다. 양쪽의 물리적 연결을 확인합니다. |
| Out-Discard |
설명: 오류가 탐지되지 않았는데도 폐기 대상으로 선택된 아웃바운드 패킷의 개수입니다. 일반적인 원인: 버퍼 공간을 비우기 위해 이러한 패킷을 폐기할 때도 있습니다. |
| output buffer failures output buffers swapped out |
설명: show interfaces counter. 실패한 버퍼의 수 및 스왑 아웃된 버퍼의 수입니다. 일반적인 원인: 포트에 스위칭되는 트래픽의 속도가 빠르고 포트에서 그 트래픽의 양을 처리할 수 없으면, 포트는 Tx 버퍼에 패킷을 버퍼링합니다. Tx 버퍼가 가득 차면 포트가 패킷을 삭제하기 시작하며, 그러면 underruns 및 output buffer failure 카운터가 증가합니다. output buffer failure 카운터 증가는 포트가 저조한 속도로 또는 듀플렉스로 실행되거나 너무 많은 트래픽이 포트를 통과하는 것을 의미할 수도 있습니다. 이를테면 1gig 멀티캐스트 스트림 하나가 100Mbps 포트 24개에 포워딩된다고 가정합니다. 이그레스 인터페이스가 오버서브스크립션되는 경우 output buffer failure가 Out-Discard와 함께 증가하는 것은 정상입니다. 문제 해결 정보는 이 문서의 지연된 프레임(Out-Lost 또는 Out-Discard) 섹션을 참조하십시오. |
| output errors |
설명: show interfaces counter. 인터페이스에서 데이터그램의 최종 전송을 막는 모든 오류의 합계입니다. 일반적인 원인: 이 문제는 출력 대기열의 크기가 작기 때문에 발생합니다. |
| overrun |
설명: 수신기 하드웨어에서 수신된 데이터를 하드웨어 버퍼에 전달하지 못한 횟수입니다. 일반적인 원인:트래픽 입력 속도가 수신기의 데이터 처리 능력을 초과했습니다. |
| packets input/output |
설명: show interfaces counter. 인터페이스에서 수신하고 전송한 오류 없는 패킷의 총개수입니다. 트래픽이 올바르게 인터페이스를 지나 이동하는지 여부를 확인하는 데 유용하므로 이러한 카운터 증가를 모니터링합니다. bytes 카운터에는 시스템에서 수신하고 전송한 오류 없는 패킷의 데이터 및 MAC 캡슐화가 모두 포함됩니다. |
| Rcv-Err |
설명: Catalyst 6000 Series 전용 - show interfaces counters error. 일반적인 원인: 플랫폼 예외를 참조하십시오.플랫폼 예외: Catalyst 5000 Series rcv-err = 수신 버퍼 실패. 예컨대 runt, giant 또는 FCS-Err는 rcv-err 카운터를 증가시키지 않습니다. 5K의 rcv-err 카운터는 과도한 트래픽이 발생한 경우에만 증가합니다. Catalyst 4000 Series에서 rcv-err = 모든 수신 오류의 합계. Catalyst 5000과 달리 인터페이스에서 runt, giant 또는 FCS-Err와 같은 오류를 수신할 때 rcv-err 카운터가 증가합니다. |
| Runts |
설명: show interfaces 및 show interfaces counters errors. 수신된 프레임이 최소 IEEE 802.3 프레임 크기(이더넷의 경우 64바이트)보다 작고 CRC가 잘못되었습니다. 일반적인 원인: 이중 불일치와 연결된 장치의 잘못된 케이블, 포트 또는 NIC와 같은 물리적 문제로 인해 발생할 수 있습니다. 플랫폼 예외: Catalyst 4000 Series는 소프트웨어 버전 12.1(19)EW 이전 버전의 Cisco IOS를 실행하며, runt = 초소형입니다. Undersize = 64바이트보다 작은 프레임입니다. runt 카운터는 64바이트보다 작은 프레임을 수신한 경우에만 증가했습니다. 12.1(19)EW부터는 runt = 프래그먼트(fragment)입니다. 프래그먼트는 64바이트보다 작고 불량 CRC가 있는 프레임입니다. 따라서 이제는 64바이트보다 작고 불량 CRC가 있는 프레임을 수신하면, show interfaces에서 runt 카운터가, show interfaces counters errors에서는 fragments 카운터가 증가합니다. Cisco Catalyst 3750 Series Switch Cisco IOS 12.1(19)EA1 이전 릴리스에서 Catalyst 3750의 트렁크 인터페이스에 dot1q를 사용할 경우 Catalyst 3750에서 61~64바이트이며 q-tag를 포함하는 유효한 dot1q 캡슐화된 패킷이 Catalyst 3750에서 크기가 작은 프레임으로 계산되므로 이러한 패킷이 올바르게 전달되더라도 런트가 show interface 출력 화면에 표시될 수 있습니다. 아울러 이 패킷은 수신 통계에서 해당 카테고리(유니캐스트, 멀티캐스트 또는 브로드캐스트)에 보고되지 않습니다. 이 문제는 Cisco IOS 릴리스 12.1(19)EA1 또는 12.2(18)SE 이상에서 해결되었습니다. |
| Single-Col |
설명: show interfaces counters errors. 인터페이스에서 미디어에 성공적으로 프레임을 전송하기 전에 단일 충돌이 발생한 횟수입니다. 일반적인 원인: 하프 듀플렉스(half duplex)로 설정된 인터페이스에서는 충돌이 정상이지만, 풀 듀플렉스(full-duplex) 인터페이스의 경우 나타나서는 안 됩니다. 충돌이 크게 증가한다면, 링크 사용량이 많다는 뜻입니다. 또는 연결된 디바이스와 듀플렉스가 일치하지 않을 수도 있습니다. |
| throttles |
설명: show interfaces. 아마도 버퍼 또는 프로세서 오버로드로 인해 포트의 수신기가 비활성화된 횟수입니다. throttles 카운터 값 다음에 별표(*)가 나타나면, 명령이 실행될 때 인터페이스가 스로틀됨을 의미합니다. 일반적인 원인: 프로세서 오버로드를 증가시킬 패킷으로는 옵션을 포함한 IP 패킷, 만료된 TTL, 비 ARPA 캡슐화, 프래그먼트화, 터널, ICMP 패킷, MTU 체크섬 실패를 포함한 패킷, RPF 실패, IP 체크섬, 길이 오류 등이 있습니다. |
| underruns |
설명: 송신기가 스위치에서 처리 가능한 수준보다 빠른 속도로 실행된 횟수입니다. 일반적인 원인: 이는 처리량이 많은 상황, 즉 다른 여러 인터페이스에서 보낸 대량의 버스트 트래픽이 어떤 인터페이스에 동시에 도달한 경우에 발생할 수 있습니다. underruns와 함께 인터페이스 재설정이 일어날 수 있습니다. |
| UnderSize |
설명: show interfaces counters errors. 최소 IEEE 802.3 프레임 크기인 64바이트보다 작지만(프레임 비트는 제외, FCS octet은 포함), 올바른 형식인 수신된 프레임입니다. 일반적인 원인: 이 프레임을 전송하는 디바이스를 확인합니다. |
| Xmit-Err |
설명: show interfaces counters errors. 내부 전송(Tx) 버퍼가 가득 찼음을 의미합니다. 일반적인 원인: Xmit-Err의 주 원인 중 하나는 고대역폭 링크에서 더 낮은 대역폭 링크로 스위칭되는 트래픽 또는 여러 인바운드 링크에서 단일 아웃바운드 링크로 스위칭되는 트래픽입니다. 예를 들어 대량의 버스트 트래픽이 기가비트 인터페이스에 도달하여 100Mbps 인터페이스로 스위칭되는 경우, 그로 인해 100Mbps 인터페이스에서 Xmit-Err가 증가할 수 있습니다. 이는 인바운드 대역폭과 아웃바운드 대역폭의 속도가 일치하지 않아 해당 인터페이스의 출력 버퍼에 과도한 트래픽이 발생하기 때문입니다. |
Cisco IOS의 show interfaces counters
유니캐스트, 멀티캐스트 및 브로드캐스트 트래픽에 대해 다음 출력에 표시되는 대로 포트의 인바운드 및 아웃바운드 트래픽을 모니터링합니다. show interfaces card-type {slot/port} counters 명령은 수퍼바이저에서 Cisco IOS를 실행할 때 사용합니다.
Router#show interfaces fas 6/1 counters Port InOctets InUcastPkts InMcastPkts InBcastPkts Fa6/1 47856076 23 673028 149 Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts Fa6/1 22103793 17 255877 3280 Router#
!--- Cisco IOS counters used to monitor inbound and outbound unicast, multicast !--- and broadcast packets on the interface.
Cisco IOS의 show counters interface
show counters interface card-type {slot/port} 명령은 Cisco IOS 소프트웨어 버전 12.1(13)E에서 Catalyst 6000 시리즈에만 도입되었으며, 포트 및 인터페이스에 대한 보다 자세한 통계를 제공합니다. 이 명령은 포트 또는 인터페이스당 32비트 및 64비트 오류 카운터를 표시합니다.
Cisco IOS의 Show Controller Ethernet-Controller
Catalyst 3750, 3550, 2970, 2950/2955, 2940 및 2900/3500XL 스위치의 경우 명령 show controller ethernet-controller를 사용하여 Catalyst 6000 시리즈 스위치의 출력과 유사한 트래픽 카운터 및 오류 카운터 출력을 표시합니다.
3550-1#show controller ethernet-controller fastEthernet 0/1
!--- Output from a Catalyst 3550.
Transmit FastEthernet0/1 Receive
0 Bytes 0 Bytes
0 Unicast frames 0 Unicast frames
0 Multicast frames 0 Multicast frames
0 Broadcast frames 0 Broadcast frames
0 Discarded frames 0 No dest, unicast
0 Too old frames 0 No dest, multicast
0 Deferred frames 0 No dest, broadcast
0 1 collision frames
0 2 collision frames 0 FCS errors
0 3 collision frames 0 Oversize frames
0 4 collision frames 0 Undersize frames
0 5 collision frames 0 Collision fragments
0 6 collision frames
0 7 collision frames 0 Minimum size frames
0 8 collision frames 0 65 to 127 byte frames
0 9 collision frames 0 128 to 255 byte frames
0 10 collision frames 0 256 to 511 byte frames
0 11 collision frames 0 512 to 1023 byte frames
0 12 collision frames 0 1024 to 1518 byte frames
0 13 collision frames
0 14 collision frames 0 Flooded frames
0 15 collision frames 0 Overrun frames
0 Excessive collisions 0 VLAN filtered frames
0 Late collisions 0 Source routed frames
0 Good (1 coll) frames 0 Valid oversize frames
0 Good(>1 coll) frames 0 Pause frames
0 Pause frames 0 Symbol error frames
0 VLAN discard frames 0 Invalid frames, too large
0 Excess defer frames 0 Valid frames, too large
0 Too large frames 0 Invalid frames, too small
0 64 byte frames 0 Valid frames, too small
0 127 byte frames
0 255 byte frames
0 511 byte frames
0 1023 byte frames
0 1518 byte frames
3550-1#
!--- See the next table for additional counter output for 2900/3500XL Series switches.
| 카운터 | 설명 | 가능한 원인 |
| 전송 프레임 |
||
| Discarded frames |
불충분한 리소스 때문에 전송 시도가 중단된 프레임의 총개수입니다. 이 합계에는 모든 목적지 유형의 프레임이 포함됩니다. |
인터페이스의 트래픽 로드가 너무 많아 프레임이 폐기됩니다. 이 필드에서 패킷의 수가 증가하는 경우 인터페이스의 트래픽 로드를 줄입니다. |
| Too old frames |
스위치를 통과하여 이동하는 데 2초 넘게 걸린 프레임의 수입니다. 이런 까닭에 스위치에 의해 폐기되었습니다. 이는 극한의 스트레스 조건에서만 일어납니다. |
이 스위치에 대한 트래픽 로드가 너무 많아 프레임이 폐기됩니다. 이 필드에서 패킷의 수가 증가하는 경우 스위치 로드를 줄입니다. 이 스위치에 대한 트래픽 로드를 줄이기 위해 네트워크 토폴로지 수정이 필요할 수도 있습니다. |
| Deferred frames |
네트워크 미디어의 트래픽 때문에 첫 번째 전송 시도가 지연된 프레임의 총 개수입니다. 이 합계에는 나중에 오류 없이 전송되었고 충돌에 영향받지 않은 프레임만 포함됩니다. |
이 스위치로 향하는 트래픽 로드가 너무 많아 프레임이 폐기됩니다. 이 필드에서 패킷의 수가 증가하는 경우 스위치 로드를 줄입니다. 이 스위치에 대한 트래픽 로드를 줄이기 위해 네트워크 토폴로지 수정이 필요할 수도 있습니다. |
| Collision frames |
collision frames 카운터는 패킷 전송을 시도하여 성공하지 못했으나 다음 시도에 성공한 횟수입니다. 만약 2 collision frames 카운터가 증가했다면, 스위치가 패킷 전송을 2번 시도하여 실패했지만, 3번째 시도에 성공한 것입니다. |
인터페이스의 트래픽 로드가 너무 많아 프레임이 폐기됩니다. 이 필드에서 패킷의 수가 증가하는 경우 인터페이스의 트래픽 로드를 줄입니다. |
| Excessive collisions |
지연 충돌이 16회 연속으로 발생하면 excessive collisions 카운터가 증가합니다. 패킷 전송이 16회 시도된 다음 패킷이 삭제되고 카운터가 증가합니다. |
이 카운터가 증가한다면 배선 문제, 네트워크 과부하 또는 듀플렉스 불일치를 의미할 수 있습니다. 네트워크 과부하는 공유 이더넷에 디바이스가 너무 많아 발생할 수도 있습니다. |
| Late collisions |
두 개의 디바이스에서 동시에 전송하는데 어느 쪽의 연결에서도 충돌을 탐지하지 않으면 지연 충돌에 해당합니다. 이는 네트워크의 한 쪽 끝에서 다른 쪽으로 신호를 전파하는 데 걸리는 시간이 전체 패킷을 네트워크에 넣는 데 걸리는 시간보다 길기 때문에 발생합니다. 지연 충돌을 일으키는 두 디바이스는 전체 패킷을 네트워크에 넣을 때까지 다른 쪽 디바이스에서 전송한다는 사실을 알지 못합니다. 첫 64바이트 슬롯 시간이 지날 때까지는 송신기에서 지연 충돌을 탐지하지 않습니다. 이는 64바이트보다 긴 패킷의 전송에서만 탐지되기 때문입니다. |
지연 충돌은 케이블링이 잘못되었거나 네트워크의 허브 수가 기준에 어긋나기 때문에 발생합니다. 불량 NIC도 지연 충돌의 원인이 될 수 있습니다. |
| Good (1 coll) frames |
정확히 하나의 충돌이 발생했고 그런 다음 성공적으로 전송된 프레임의 총 개수입니다. |
하프 듀플렉스 환경에서의 충돌은 정상적인 동작입니다. |
| Good (>1 coll) frames |
2-15회의 충돌이 발생했고 그런 다음 성공적으로 전송된 프레임의 총 개수입니다. |
하프 듀플렉스 환경에서의 충돌은 정상적인 동작입니다. 이 카운터의 상한에서 증가하는 프레임은 15회 충돌을 초과하여 Excessive collisions로 카운트될 수 있습니다. |
| VLAN discardframes |
CFI 비트가 설정된 까닭에 인터페이스에서 삭제된 프레임의 수입니다. |
이더넷 정규 프레임 형식에서는 802.1q 프레임의 TCI에 있는 CFI(Canonical Format Indicator) 비트가 0으로 설정됩니다. CFI 비트가 1로 설정되어 있다면, RIF(Routing Information Field) 또는 토큰 링 비정규 프레임이 있어 폐기되었음을 의미합니다. |
| 수신 프레임 |
||
| No bandwidth frames |
2900/3500XL에만 해당합니다.포트가 네트워크에서 패킷을 수신했으나 스위치에 해당 패킷을 수신할 리소스가 없었던 횟수입니다. 이는 스트레스 조건에서만 일어나지만, 여러 포트에 버스트 트래픽이 있을 때 발생할 수 있습니다. 따라서 No bandwidth frames의 값이 작아도 걱정할 필요 없습니다. 그렇다 하더라도 수신된 프레임의 1%보다 훨씬 적어야 합니다. |
인터페이스의 트래픽 로드가 너무 많아 프레임이 폐기됩니다. 이 필드에서 패킷의 수가 증가하는 경우 인터페이스의 트래픽 로드를 줄입니다. |
| No buffers frames |
2900/3500XL에만 해당합니다.포트가 네트워크에서 패킷을 수신했으나 스위치에 해당 패킷을 수신할 리소스가 없었던 횟수입니다. 이는 스트레스 조건에서만 일어나지만, 여러 포트에 버스트 트래픽이 있을 때 발생할 수 있습니다. 따라서 No buffers frames의 값이 작아도 걱정할 필요 없습니다. 그렇다 하더라도 수신된 프레임의 1%보다 훨씬 적어야 합니다. |
인터페이스의 트래픽 로드가 너무 많아 프레임이 폐기됩니다. 이 필드에서 패킷의 수가 증가하는 경우 인터페이스의 트래픽 로드를 줄입니다. |
| No dest, unicast |
No destination unicast는 포트에서 다른 어떤 포트로도 포워딩하지 않은 유니캐스트 패킷의 수입니다. |
다음과 같은 경우에 No dest, (unicast, multicast, broadcast) 카운터가 증가할 수 있습니다.
|
| No dest, multicast |
No destination multicast는 포트에서 다른 어떤 포트로도 포워딩하지 않은 멀티캐스트 패킷의 수입니다. |
|
| No dest, broadcast |
No destination broadcast는 포트에서 다른 어떤 포트로도 포워딩하지 않은 브로드캐스트 패킷의 수입니다. |
|
| Alignment errors |
Alignment errors는 수신한 프레임 중에서 짝수 개수의 옥텟으로 끝나지 않고 불량 CRC가 있는 프레임의 수입니다. |
맞춤 오류는 프레임이 회선으로 완전히 복사되지 않아 발생하는데, 그러면 프레임이 프래그먼트화됩니다. 맞춤 오류의 원인으로는 하프 듀플렉스(half duplex)에서의 충돌, 듀플렉스 불일치, 불량 하드웨어(NIC, 케이블 또는 포트), octet으로 끝나지 않고 불량 FCS가 있는 프레임을 생성하는 연결된 디바이스를 들 수 있습니다. |
| FCS errors |
FCS error 카운트는 이더넷 프레임에서 불량 체크섬(CRC 값)과 함께 수신된 프레임의 수입니다. 이러한 프레임은 삭제되고, 다른 포트에 전파되지 않습니다. |
FCS 오류의 원인으로는 하프 듀플렉스(half duplex)에서의 충돌, 듀플렉스 불일치, 불량 하드웨어(NIC, 케이블 또는 포트), octet으로 끝나지 않고 불량 FCS가 있는 프레임을 생성하는 연결된 디바이스를 들 수 있습니다. |
| Undersize frames |
길이가 64octet보다 짧고(프레임 비트 제외, FCS 포함) 양호한 FCS 값을 가진 수신 패킷의 총개수입니다. |
이는 연결된 디바이스에 의해 불량 프레임이 생성되었음을 의미합니다. 연결된 디바이스가 올바르게 작동하는지 확인합니다. |
| Oversize frames |
포트에서 네트워크로부터 수신한 패킷 중에서 1514바이트를 초과하는 패킷의 수입니다. |
이는 결함 있는 하드웨어, dot1q 또는 ISL 트렁킹 컨피그레이션 문제를 나타낼 수 있습니다. |
| Collision fragments |
길이가 64octet보다 짧고(프레임 비트 제외, FCS 포함) 불량 FCS 값을 가진 프레임의 총개수입니다. |
이 카운터의 값이 증가한다면, 포트가 하프 듀플렉스로 구성되었음을 의미합니다. 듀플렉스를 풀 듀플렉스(full-duplex)로 설정합니다. |
| Overrun frames |
수신기 하드웨어에서 수신된 데이터를 하드웨어 버퍼에 전달하지 못한 횟수입니다. |
트래픽 입력 속도가 수신기의 데이터 처리 능력을 초과했습니다. |
| VLAN filtered frames |
프레임에 수록된 VLAN 정보의 유형 때문에 필터링되는 프레임의 총개수입니다. |
802.1Q 태그가 지정된 프레임을 필터링하도록 포트를 구성할 수 있습니다. 802.1Q 태그를 포함한 프레임을 수신하면 프레임이 필터링되고 이 통계의 값이 증가합니다. |
| Source routed frames |
소스 경로 비트가 네이티브 프레임의 소스 주소에 설정된 상황으로 인해 폐기된 수신 프레임의 총개수입니다. |
이러한 유형의 소스 라우팅은 토큰 링 및 FDDI에 대해서만 정의됩니다. IEEE 이더넷 사양에서는 어떤 이더넷 프레임에도 이 비트를 설정할 수 없습니다. 따라서 스위치는 이러한 프레임을 폐기합니다. |
| Valid oversize frames |
길이가 시스템 MTU를 초과하고 양호한 FCS 값을 가진 수신 프레임의 총개수입니다. |
이 통계 값은 설정된 시스템 MTU를 초과하지만 Q-in-Q 또는 MPLS 캡슐화를 허용하기 위해 1518바이트에서 늘릴 수 있는 프레임을 카운트합니다. |
| Symbol error frames |
기가비트 이더넷(1000 Base-X)은 8B/10B 인코딩을 사용하여 MAC 하위 레이어(레이어 2)의 8비트 데이터를 회선을 통해 전송할 10비트 기호로 변환합니다. 포트에서 기호를 수신하면 그 기호(10비트)로부터 8비트 데이터를 추출합니다. |
Symbol error는 인터페이스가 수신되었으나 정의되지 않은(잘못된) 기호를 탐지함을 의미합니다. 소량의 기호 오류는 무시할 수 있습니다. 기호 오류의 양이 많다면 불량 디바이스, 케이블 또는 하드웨어를 의미할 수 있습니다. |
| Invalid frames, too large |
giant 프레임, 즉 최대 IEEE 802.3 프레임 크기(비 점보 이더넷은 1518바이트)를 초과하고 불량 FCS(Frame Check Sequence)가 있는, 수신된 프레임입니다. |
대개는 불량 NIC가 원인입니다. 문제의 디바이스를 찾아 네트워크에서 제거하십시오. |
| Invalid frames, too small |
runt 프레임, 즉 64바이트보다 작고(FCS 비트 포함, 프레임 헤더 제외) FCS 오류 또는 맞춤 오류 중 하나를 포함하는, 수신된 프레임입니다. |
듀플렉스 불일치 및 물리적 문제(예: 연결된 디바이스의 불량 케이블, 포트, NIC)가 원인일 수 있습니다. |
대표적인 시스템 오류 메시지
Cisco IOS 시스템 메시지 형식의 경우 실행하는 소프트웨어 릴리스에 대한 메시지 및 복구 절차 가이드를 참조할 수 있습니다. 예를 들어, Cisco IOS 릴리스의 메시지 및 복구 절차를 볼 수 있습니다.
%AMDP2_FE-3-UNDERFLO
프레임이 전송될 때 컨트롤러 칩 로컬 버퍼의 로컬 버퍼가 불충분한 데이터를 수신하면 이 오류 메시지가 나타납니다. 출력 속도에 보조를 맞출 만큼 빠르게 칩으로 데이터를 전송할 수 없습니다. 대개는 일시적인 상황이며, 시스템 내의 일시적인 피크 로드에 따라 달라집니다. 이 문제는 고속 이더넷 인터페이스에서 과다한 트래픽을 처리할 때 발생합니다. 트래픽 레벨이 약 2.5Mb에 도달하면 이 오류 메시지를 수신합니다. 이 트래픽 레벨 제한은 하드웨어 제약 때문입니다. 그런 까닭에 Catalyst Switch에 연결된 디바이스에서 패킷을 삭제할 가능성이 있습니다.
대개 시스템이 자동으로 복구되면서 해결됩니다. 추가 작업은 필요하지 않습니다. 스위치가 이더넷 인터페이스에 부담을 주는 경우 속도 및 듀플렉스 설정을 확인합니다. 또한 스니퍼 프로그램을 사용하여 라우터 고속 이더넷 인터페이스를 드나드는 패킷을 분석합니다. Catalyst 스위치에 연결된 디바이스에서 패킷을 삭제하는 것을 방지하려면 스위치에 연결된 디바이스의 고속 이더넷 인터페이스에서 ip cef 명령을 실행합니다.
%INTR_MGR-DFC1-3-INTR: 대기 엔진(Blackwater) [1]: FIC 패브릭-A가 예기치 않은 제어 코드를 수신함
스위치 패브릭에서 패킷을 수신할 때 이 패킷의 패브릭 헤더에 있는 CRC 값이 Blackwater ASIC의 FIC(Fabric Interface Controller) 하위 블록에서 계산한 CRC 값과 일치하지 않으면 이 오류 메시지가 나타납니다. 이는 전송 중에 패킷이 손상되어 Blackwater가 손상된 패킷을 수신했음을 의미합니다.
Command Rejected: [Interface] not a Switching Port
L3 인터페이스와 L2 스위치포트를 모두 지원하는 스위치에서는 레이어 3 인터페이스로 구성된 포트에서 레이어 2와 관련된 명령을 입력하려고 할 때 "Command rejected: [interface] not a switching port"라는 메시지가 표시됩니다.
레이어 3 모드에서 레이어 2 모드로 인터페이스를 전환하려면 인터페이스 컨피그레이션 명령 switchport를 실행합니다. 이 명령을 실행한 다음 포트에서 레이어 2 속성을 구성합니다.
대표적인 포트 및 인터페이스 문제
포트 또는 인터페이스 상태가 Disable(비활성화) 또는 Shutdown(종료)
포트 연결 실패의 확실한 원인이지만 간과하기 쉬운 문제 중 하나가 스위치의 잘못된 컨피그레이션입니다. 포트에서 주황색 표시등이 계속 켜져 있으면, 사용자 인터페이스를 통해 또는 내부 프로세스에 의해 스위치 내부의 소프트웨어에서 포트를 종료한 것입니다.
포트 또는 모듈이 어떤 이유로든 비활성화되었거나 꺼져 있지 않은지 확인하십시오. 링크의 한쪽 또는 다른 쪽에서 포트 또는 모듈이 수동으로 종료된 경우, 포트를 다시 활성화할 때까지 링크가 작동하지 않습니다. 양쪽의 포트 상태를 확인합니다. show run interface 명령을 사용하여 인터페이스가 종료 상태에 있는지 확인합니다.
Switch#show run interface fastEthernet 4/2 ! interface FastEthernet4/2 switchport trunk encapsulation dot1q switchport mode trunk shutdown duplex full speed 100 end
!--- Use the no shut command in config-if mode to re-enable this interface.
스위치를 재부팅한 직후 포트가 셧다운 모드가 되었다면 포트 보안 설정이 원인일 수 있습니다. 해당 포트에서 유니캐스트 플러딩이 활성화되었다면 리부팅한 다음 포트가 종료될 수 있습니다. 유니캐스트 플러딩을 비활성화하는 것이 좋습니다. 그러면 MAC 주소 제한에 도달하더라도 포트에서 플러딩이 일어나지 않습니다.
포트 또는 인터페이스 상태가 errDisable임
기본적으로 특정 오류가 탐지되면 스위치 내부의 소프트웨어 프로세스에서 포트 또는 인터페이스를 종료할 수 있습니다.
Cisco IOS에 대한 show interfacecard-type {slot/port} status 명령을 보면
Router#show interface fastethernet 2/4 status Port Name Status Vlan Duplex Speed Type Gi2/4 err-disabled 1 full 1000 1000BaseSX
!--- The show interfaces card-type {slot/port} status command for Cisco IOS !--- displays a status of errdisabled. !--- The show interfaces status errdisabled command shows all the interfaces !--- in this status.
Cisco IOS에 대한 show logging 명령은 errdisable 상태와 관련된 오류 메시지도 표시합니다(정확한 메시지 형식은 다름).
errdisable로 인한 웹 포트 또는 인터페이스 셧다운을 Cisco IOS에서는 원인으로 간주합니다. 이것의 원인으로는 PAgP 플랩을 유발하는 잘못된 EtherChannel 설정, 듀플렉스 불일치, 동시에 설정된 BPDU port-guard와 portfast, 단방향 링크를 탐지하는 UDLD 등이 있습니다.
errdisable recovery 옵션을 구성하지 않은 경우 errdisable 상태를 해제하려면 포트 또는 인터페이스를 수동으로 다시 활성화해야 합니다. Cisco IOS 소프트웨어에서는 errdisable 상태에서 구성 가능한 시간을 보낸 후 자동으로 포트를 다시 활성화할 수 있습니다. 요컨대 errdisable에서 복구하도록 인터페이스를 구성하더라도 근본 원인이 규명되지 않으면 문제가 재발합니다.
다음 표에서는 스위치에서 검증을 설정하고 errdisable 상태를 문제 해결하는 데 쓰이는 명령의 예시를 보여줍니다. Cisco IOS 플랫폼에서 Errdisable 포트 상태 복구 명령에 대한 자세한 내용을 보려면 링크로 이동하십시오.
| 작업 | Cisco IOS errdisable 명령 |
|---|---|
| 구성 | errdisable 탐지 원인 |
| 구성 | errdisable 복구 원인 |
| 구성 | errdisable recovery interval <timer_interval_in_seconds> |
| 검증 및 트러블슈팅 | show errdisable detect |
| 검증 및 트러블슈팅 | show interfaces status err-disabled |
포트 또는 인터페이스 상태가 Inactive(비활성)임
Cisco IOS를 실행하는 스위치에서 비활성 포트가 생기는 대표적인 원인 중 하나는 포트가 속한 VLAN이 사라진 경우입니다. 이는 인터페이스가 switchport 명령을 사용하는 레이어 2 스위치포트로 구성된 경우 발생할 수 있습니다.
레이어 2 스위치의 모든 포트는 VLAN에 속해 있습니다. L2 스위치포트로 구성된 레이어 3 스위치의 모든 포트 역시 VLAN에 속해 있어야 합니다. 그 VLAN이 삭제되면 포트 또는 인터페이스가 비활성화됩니다.
show interfaces card-type {slot/port} switchport 명령을 show vlan과 함께 사용하여 확인을 수행합니다.
Router#show interfaces fastEthernet 4/47 switchport Name: Fa4/47Switchport: Enabled Administrative Mode: static access Operational Mode: static access Administrative Trunking Encapsulation: negotiate Operational Trunking Encapsulation: native Negotiation of Trunking: Off Access Mode VLAN: 11 ((Inactive))
!--- FastEth 4/47 is inactive. Router#show vlan VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1 default active Gi1/1, Gi2/1, Fa6/6 10 UplinkToGSR's active Gi1/2, Gi2/2
!--- VLANs are displayed in order and VLAN 11 is not available.
30 SDTsw-1ToSDTsw-2Link active Fa6/45
VLAN을 삭제한 스위치가 VTP 도메인을 위한 VTP 서버일 경우, 그 도메인의 모든 서버 및 클라이언트 스위치 역시 VLAN 테이블에서 해당 VLAN이 제거됩니다. VTP 서버 스위치에서 해당 VLAN을 다시 VLAN 테이블에 추가하면, 그 도메인에서 복원된 VLAN에 속한 스위치의 포트가 다시 활성화됩니다. VLAN 자체가 삭제되더라도 포트는 자신이 속한 VLAN을 기억하고 있습니다. VTP에 대한 자세한 내용은 VTP(VLAN Trunk Protocol) 이해 및 설정을 참조하십시오.
업링크 포트 또는 인터페이스 상태가 Inactive(비활성)임
Catalyst 4510R 시리즈 스위치에서 10기가비트 이더넷 및 기가비트 이더넷 SFP 업링크 포트 모두를 활성화하기 위해 이용할 수 있는 컨피그레이션 옵션이 있습니다. 10기가비트 이더넷 및 기가비트 이더넷 SFP 인터페이스를 동시에 사용할 수 있게 하려면 hw-module uplink select all 명령을 실행합니다. 명령을 실행한 후 스위치를 다시 부팅합니다. 그렇지 않으면 show interface status module <module number> 명령의 출력에 업링크 포트가 비활성 상태로 표시됩니다.
Cisco IOS Software Release 12.2(25)SG는 Catalyst 4500 Switch에서 10기가비트 이더넷 및 기가비트 이더넷 SFP 인터페이스의 동시 사용을 지원합니다.
Catalyst 스위치 인터페이스의 Deferred Counter(지연된 카운터)가 증가
이 문제는 해당 스위치로 향하는 트래픽 로드가 너무 많아 프레임이 폐기되기 때문에 발생합니다. 대개 지연된 프레임은 미디어가 사용 중이었기 때문에 대기했다가 성공적으로 전송된 프레임의 수입니다. 통신 사업자가 이미 사용 중인 상태에서 프레임 전송을 시도하는 하프 듀플렉스(half duplex) 환경에서 주로 나타납니다. 그러나 풀 듀플렉스 환경에서도 해당 스위치로 향하는 로드가 너무 많으면 이 문제가 발생합니다.
해결 방법은 다음과 같습니다.
-
협상 불일치를 방지하기 위해 링크의 양쪽 끝을 풀 듀플렉스로 하드코딩합니다.
-
결함 없는 케이블 및 패치 코드를 사용하도록 케이블 및 패치 패널 코드를 바꿉니다.
때때로 set timer [value] from vlan [vlan no] 실패
이 문제는 EARL(Encoded Address Recognition Logic)에서 VLAN에 대한 CAM 에이징 시간을 필요한 값(초)으로 설정하지 못할 때 발생합니다. 여기서 VLAN 에이징 시간이 이미 fast aging(빠른 에이징)으로 이미 설정되어 있습니다.
VLAN이 이미 빠른 에이징으로 설정되어 있으면, EARL에서 VLAN을 빠른 에이징으로 설정할 수 없으며 에이징 타이머 설정 프로세스가 차단됩니다. 기본 CAM 에이징 시간은 5분입니다. 즉, 스위치는 학습한 MAC 주소의 테이블을 5분마다 비웁니다. 이러한 방법으로 MAC 주소 테이블(CAM 테이블)이 최신 항목을 포함할 수 있습니다.
빠른 에이징에서는 CAM 에이징 시간을 사용자가 지정하는 시간(초)으로 임시 설정합니다. 이는 TCN(Topology Change Notification) 프로세스와 함께 사용됩니다. 토폴로지가 변경되었을 때 CAM 테이블을 더 빨리 비우려면 이 값이 필요하므로 토폴로지 변경을 보완할 수 있다는 개념입니다.
스위치에서 CAM 에이징 시간을 확인하려면 show cam aging 명령을 실행합니다. TCN과 빠른 에이징은 상당히 드문 편입니다. 따라서 이 메시지의 심각도 레벨은 3입니다. VLAN에서 빠른 에이징이 자주 일어난다면 그 이유를 확인하십시오.
TCN이 일어나는 가장 대표적인 이유는 클라이언트 PC가 스위치에 직접 연결되었기 때문입니다. PC를 켜거나 끌 때 스위치 포트 상태가 바뀌므로 스위치에서 TCN 프로세스를 시작합니다. 이는 연결된 디바이스가 PC임을 스위치가 인식하지 못하기 때문입니다. 스위치는 포트가 상태를 변경한 것만 알고 있습니다.
Cisco는 이 문제를 해결하기 위해 호스트 포트를 위한 PortFast 기능을 개발했습니다. PortFast의 장점은 호스트 포트에 대해 TCN을 억제한다는 것입니다.
트렁킹 모드 불일치
링크의 양쪽에서 트렁킹 모드를 확인합니다. 양쪽이 동일한 모드에 있는지 확인하십시오(동일한 방법으로 양쪽 트렁킹: ISL 또는 802.1q. 또는 둘 다 트렁킹 아님). 한 포트에서 트렁킹 모드를 (auto 또는 desirable이 아닌) on으로 설정하고 다른 쪽 포트에서는 트렁킹 모드를 off로 설정하면 이들은 통신할 수 없습니다. 트렁킹은 패킷의 형식을 변경합니다. 포트끼리 링크에서 사용하는 형식이 같아야 합니다. 그렇지 않으면 상대방을 이해할 수 없습니다.
Cisco IOS에서는 show interfaces card-type {mod/port} trunk 명령을 사용하여 트렁킹 설정 및 네이티브 VLAN을 확인합니다.
Router#show interfaces fastEthernet 6/1 trunk Port Mode Encapsulation Status Native vlan Fa6/1 desirable 802.1q trunking 1 Port Vlans allowed on trunk Fa6/1 1-4094 !--- Output truncated.
각종 트렁킹 코드, 지침, 제한 사항에 대한 자세한 내용은 다음 문서를 참조하십시오.
Jumbo, Giant, Baby Giant
이더넷 프레임의 데이터 부분에 있는 MTU(Maximum Transmission Unit)는 기본적으로 1500바이트입니다. 전송된 트래픽 MTU가 지원되는 MTU를 초과할 경우 스위치는 패킷을 포워딩하지 않습니다. 또한 하드웨어 및 소프트웨어에 따라, 일부 스위치 플랫폼에서는 포트 및 인터페이스 오류 카운터가 증가합니다.
-
Jumbo 프레임은 IEEE 이더넷 표준의 일부로 정의되지 않아 벤더에 따라 달라집니다. L2 헤더 및 CRC(Cyclic Redundancy Check)를 포함하여 1518바이트인 표준 이더넷 프레임보다 큰 임의의 프레임으로 정의할 수 있습니다. Jumbo는 프레임 크기가 더 크며, 대개 9000바이트를 초과합니다.
-
Giant 프레임은 이더넷 프레임의 최대 크기를 초과하고(1518바이트보다 큼) 불량 FCS가 있는 프레임으로 정의됩니다.
-
Baby Giant 프레임은 이더넷 프레임의 최대 크기보다 약간 큽니다. 대개는 최대 1600바이트 크기의 프레임을 의미합니다.
Catalyst Switch의 Jumbo 및 Baby Giant 지원은 스위치 플랫폼에 따라 다릅니다. 스위치 내의 모듈별로 다를 수도 있습니다. 소프트웨어 버전도 하나의 요인입니다.
시스템 요구 사항, 점보 및 초대형 문제의 구성 및 문제 해결에 대한 자세한 내용은 Catalyst 스위치에서 점보/초대형 프레임 지원 구성을 참조하십시오.
엔드 디바이스를 Ping할 수 없음
먼저 직접 연결된 스위치에서 전송된 ping으로 엔드 디바이스를 확인합니다. 그런 다음 포트별, 인터페이스별, 트렁크별로 거슬러 올라가면서 연결 문제의 원인을 찾습니다. 각 스위치의 CAM(Content-Addressable Memory) 테이블에서 엔드 디바이스의 MAC 주소를 확인할 수 있어야 합니다.
show mac address-table dynamic 명령을 사용하거나 interface 키워드를 대체합니다.
Router#show mac-address-table interface fastEthernet 6/3 Codes: * - primary entry vlan mac address type learn qos ports ------+----------------+--------+-----+---+-------------------------- * 2 0040.ca14.0ab1 dynamic No -- Fa6/3
!--- A workstation on VLAN 2 with MAC address 0040.ca14.0ab1 is directly connected !--- to interface fastEthernet 6/3 on a switch running Cisco IOS.
스위치에 CAM 테이블에 있는 디바이스의 MAC 주소가 있는 게 확인되면, 이 디바이스가 ping하려는 위치와 같은 또는 다른 VLAN에 있는지 확인합니다.
엔드 디바이스가 ping하려는 위치와 다른 VLAN에 있다면 L3 스위치 또는 라우터에서 이 디바이스의 통신을 허용하도록 구성해야 합니다. 엔드 디바이스 및 라우터/L3 스위치의 L3 주소 지정이 올바르게 구성되어 있어야 합니다. IP 주소, 서브넷 마스크, 기본 게이트웨이, 동적 라우팅 프로토콜 설정, 고정 경로 등을 확인합니다.
시작 지연을 해결하기 위해 Switchport Host 사용
스테이션에서 스위치를 통해 연결할 때 기본 서버와 통신할 수 없다면, 문제는 물리적 레이어 링크가 켜진 후 스위치 포트가 활성화되려 할 때 스위치 포트 활성화 지연과 관련된 것일 수 있습니다. 경우에 따라 50초까지 지연되기도 합니다. 일부 워크스테이션은 서버를 찾기 위해 이렇게 오랫동안 기다릴 수 없어 포기합니다. 이러한 지연은 STP, 트렁킹 협상(DTP), EtherChannel 협상(PAgP) 때문에 발생합니다. 이 모든 프로토콜은 해당 프로토콜이 필요하지 않은 액세스 포트에 대해 비활성화할 수 있습니다. 그러면 네이버 디바이스와의 링크를 설정하고 몇 초 후에 스위치 포트 또는 인터페이스에서 패킷 포워딩을 시작합니다.
Cisco IOS에서는 switchport host 명령을 사용하여 채널링을 비활성화하고 spanning-tree portfast를 활성화하고 switchport nonegotiate 명령을 사용하여 DTP 협상 패킷을 끌 수 있습니다. interface-range 명령으로 여러 인터페이스에서 한꺼번에 이 작업을 수행할 수 있습니다.
Router6k-1(config)#interface range fastEthernet 6/13 - 18 Router6k-1(config-if-range)#switchport Router6k-1(config-if-range)#switchport host switchport mode can be set to access spanning-tree portfast can be enabled channel group can be disabled !--- Etherchannel is disabled and portfast is enabled on interfaces 6/13 - 6/18. Router6k-1(config-if-range)#switchport nonegotiate !--- Trunking negotiation is disabled on interfaces 6/13 - 6/18. Router6k-1(config-if-range)#end Router6k-1#
Cisco IOS에서는 global spanning-tree portfast default 명령을 사용하여 레이어 2 액세스 스위치포트로 설정된 임의의 인터페이스에 portfast를 자동 적용할 수 있습니다. 해당 소프트웨어 릴리스의 명령 참조에서 이 명령을 사용할 수 있는지를 확인하십시오. 또한 인터페이스별로 spanning-tree portfast 명령을 사용할 수 있는데, 그러려면 트렁킹 및 etherchannel을 각각 꺼야 워크스테이션 시작 지연을 해결할 수 있습니다.
속도/듀플렉스, 자동 협상 또는 NIC 문제
맞춤 오류, FCS 오류 또는 지연 충돌이 많이 발생한다면 다음 중 하나를 의미할 수 있습니다.
-
듀플렉스 불일치
-
케이블 불량 또는 손상
- NIC 카드 문제
듀플렉스 불일치
속도/듀플렉스와 관련하여 자주 발생하는 문제 중 하나는 두 스위치 간에, 스위치와 라우터 간에, 스위치와 워크스테이션 또는 서버 간에 듀플렉스 설정이 일치하지 않는 것입니다. 속도 및 듀플렉스를 수동으로 하드 코딩하는 경우에 또는 두 디바이스 간에 자동 협상 문제가 있을 때 이러한 상황이 발생할 수 있습니다.
CDP(Cisco Discovery Protocol)가 활성화된 Cisco 디바이스끼리 일치하지 않을 경우 콘솔에 또는 두 디바이스의 로깅 버퍼에 CDP 오류 메시지가 나타납니다. CDP는 오류를 탐지하고 인접한 Cisco 디바이스의 포트 및 시스템 통계를 확인하는 데에도 유용합니다. CDP는 Cisco의 독점 기술이며, 잘 알려진 MAC 주소인 01-00-0C-CC-CC-CC에 패킷을 전송할 때 작동합니다.
이 예에서는 Cisco IOS를 실행하는 두 Catalyst 6000 Series 스위치 간의 이중 불일치로 인한 로그 메시지를 보여줍니다. 일반적으로 이러한 메시지를 통해 어디에서 무엇이 일치하지 않은지를 알 수 있습니다.
Jun 2 11:16:45 %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet6/2 (not half duplex), with TBA04251336 3/2 (half duplex).
Cisco 네이버 디바이스에 대한 CDP 정보를 표시하려면 show cdp neighbors card-type <slot/port> detail 명령을 사용합니다.
Router#show cdp neighbors fastEthernet 6/1 detail ------------------------- Device ID: TBA04251336 Entry address(es): IP address: 10.1.1.1 Platform: WS-C6006, Capabilities: Trans-Bridge Switch IGMP Interface: FastEthernet6/1, Port ID (outgoing port): 3/1 Holdtime : 152 sec Version : WS-C6006 Software, Version McpSW: 6.3(3) NmpSW: 6.3(3) Copyright (c) 1995-2001 by Cisco Systems !--- Neighbor device to FastEth 6/1 is a Cisco Catalyst 6000 Switch !--- on port 3/1 running CatOS. advertisement version: 2 VTP Management Domain: 'test1' Native VLAN: 1 Duplex: full !--- Duplex is full. Router#
한쪽에서 자동 속도/듀플렉스를 설정하고 다른 쪽에서는 100/풀 듀플렉스(full-duplex)를 설정하는 것도 잘못된 설정이므로 듀플렉스 불일치가 일어날 수 있습니다. 스위치 포트에서 지연 충돌을 많이 수신하는 경우, 대개는 듀플렉스 불일치 문제이며 그 결과 포트가 errdisable 상태가 될 수 있습니다. 하프 듀플렉스(half duplex)에서는 임의의 시간이 아니라 특정 시간에만 패킷을 전송하므로, 잘못된 시간에 수신된 패킷을 충돌로 카운트합니다. 다른 요인 때문에 지연 충돌이 일어나기도 하지만, 듀플렉스 불일치가 가장 대표적인 이유입니다. 항상 연결의 양쪽을 속도/듀플렉스 자동 협상으로 설정합니다. 또는 양쪽에서 속도/듀플렉스를 수동으로 설정합니다.
속도 및 이중 설정과 기타 정보를 표시하려면 show interfaces <card-type> <slot/port> status 명령을 사용합니다. 필요하다면 인터페이스 설정 모드에서 speed 및 duplex 명령을 사용하여 양쪽을 10 또는 100, 하프 또는 풀 듀플렉스로 하드코딩합니다.
Router#show interfaces fastEthernet 6/1 status Port Name Status Vlan Duplex Speed Type Fa6/1 connected 1 a-full a-100 10/100BaseTX
status 옵션 없이 theshow interfaces 명령을 사용할 경우 속도 및 듀플렉스에 대한 설정이 표시되지만 이 속도 및 듀플렉스가 자동 협상을 통해 달성되었는지 여부는 알 수 없습니다.
Router#show interface fas 6/1
FastEthernet6/1 is up, line protocol is up (connected)
Hardware is C6k 100Mb 802.3, address is 0009.11f3.8848 (bia 0009.11f3.8848)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Full-duplex, 100Mb/s
!--- Full-duplex and 100Mbps does not tell you whether autoneg was used to achieve this.
!--- Use the sh interfaces fas 6/1 status command to display this.
케이블 불량 또는 손상
케이블이 조금이라도 손상되었거나 기능 장애가 있는지 항상 확인하십시오. 케이블이 물리적 계층에서 연결하기에 양호한 상태이더라도 배선 또는 커넥터가 조금이라도 훼손되면 패킷이 손상됩니다. 구리 또는 파이버 케이블을 확인하거나 교체합니다. 파이버 연결에서는 GBIC(분리 가능한 경우)를 교체합니다. 소스와 목적지 사이에 불량 패치 패널 연결 또는 미디어 컨버터가 있으면 제거합니다. 케이블을 다른 포트 또는 인터페이스에 시험적으로 적용하여 사용 가능한지 그리고 문제가 계속되는지를 확인합니다.
자동 협상 및 NIC 카드 문제
Cisco 스위치와 특정 서드파티 NIC 카드 간에 문제가 발생할 때도 있습니다. 기본적으로 Catalyst Switch 포트 및 인터페이스는 자동 협상으로 설정되어 있습니다. 랩톱을 비롯한 각종 디바이스도 자동 협상으로 설정되는 게 일반적이지만, 자동 협상과 관련된 문제가 생길 수 있습니다.
자동 협상 문제를 해결하기 위해서는 대개 양쪽 모두를 하드 코딩하는 게 좋습니다. 자동 협상과 하드 코딩 설정 모두 작동하지 않는다면 NIC 카드의 펌웨어나 소프트웨어에 문제가 있을 수 있습니다. 제조업체의 웹 사이트에서 사용 가능한 최신 버전으로 NIC 카드 드라이버를 업그레이드하여 이 문제를 해결하십시오.
속도/이중 및 자동 협상 문제를 해결하는 방법에 대한 자세한 내용은 이더넷 10/100/1000MB 하프/풀 듀플렉스 자동 협상 구성 및 문제 해결을 참조하십시오.
서드파티 NIC 문제 해결 방법에 대한 자세한 내용은 Cisco Catalyst 스위치와 NIC의 호환성 문제 트러블슈팅을 참조하십시오.
스패닝 트리 루프
STP(Spanning Tree Protocol) 루프가 포트 또는 인터페이스 문제와 비슷한 형태로 심각한 성능 문제를 야기할 수 있습니다. 이러한 상황에서는 같은 프레임이 대역폭을 계속 차지하고 있기 때문에 정상적인 트래픽에서 거의 사용하지 못합니다.
STP 루프 보호 기능은 레이어 2 포워딩 루프(STP 루프)를 막는 추가적인 보호 장치입니다. STP 루프는 이중화 토폴로지의 STP 차단 포트가 forwarding 상태로 잘못 전환될 때 발생합니다. 대개는 물리적 이중화 토폴로지의 포트 중 하나가(STP 차단 포트가 아닐 수도 있음) 더는 STP BPDU를 수신하지 못하는 것이 원인입니다. 이 작업에서 STP는 포트 역할에 따라 지속적인 BPDU 수신 또는 전송에 의존합니다. 지정된 포트가 BPDU를 전송하고, 지정되지 않은 포트에서 BPDU를 수신합니다.
물리적 이중화 토폴로지의 포트 중 하나에서 더는 BPDU를 수신하지 않으면, STP는 그 토폴로지에 루프가 없다고 가정합니다. 결국 대체 또는 백업 포트의 차단 포트가 지정되어 forwarding 상태가 됩니다. 이러한 상황에서 루프가 생성됩니다.
루프 가드 기능은 추가 확인을 수행합니다. BPDU가 지정되지 않은 포트에서 수신되지 않고 루프 가드가 활성화되어 있으면, 해당 포트는 수신 listening/learning/forwarding 상태가 아니라 STP loop-inconsistent block 상태로 바뀝니다. 루프 가드 기능이 없으면 포트는 지정된 포트 역할로 가정합니다. 포트가 STP 포워딩 상태가 되어 루프가 생깁니다. 루프 가드 기능에 대한 자세한 내용은 Configure STP with Loop Guard and BPDU Skew Detection(루프 가드 및 BPDU 스큐 탐지를 사용하여 STP 구성)을 참조하십시오.
이 문서에서는 STP가 실패할 수 있는 이유, 문제의 근본 원인 규명을 위해 확인할 정보, STP 위험을 최소화하는 설계 유형을 다룹니다.
단방향 링크 때문에 루프가 생길 수도 있습니다. 자세한 내용은 이 문서의 UDLD: 단방향 링크 문제 섹션을 참조하십시오.
UDLD: 단방향 링크
단방향 링크는 트래픽이 하나의 방향으로 이동하지만 인그레스 방향으로 수신되지 않는 링크입니다. 스위치는 링크 인그레스 방향이 불량임을 알지 못합니다(포트는 링크가 정상적으로 작동한다고 생각합니다).
손상된 파이버 케이블 또는 기타 케이블링/포트 문제 때문에 이 단방향 통신이 일어날 수 있습니다. 이처럼 부분적으로 작동하는 링크 때문에 스위치가 링크의 부분적인 장애를 알지 못해 STP 루프와 같은 문제가 생길 수 있습니다. UDLD는 단방향 링크를 탐지하면 포트를 errdisable 상태로 전환할 수 있습니다. 단방향 링크를 허용하지 않는 스위치 간 포인트 투 포인트 연결을 위해 Cisco IOS를 실행하는 스위치에서 udld aggressive-mode 명령을 설정할 수 있습니다(릴리스 노트에서 명령 사용 가능 여부 확인). 이 기능은 찾기 어려운 단방향 링크 문제를 파악하는 데 유용합니다.
UDLD에 대한 컨피그레이션 정보는 UDLD 프로토콜 기능 구성을 참조하십시오.
지연된 프레임(Out-Lost 또는 Out-Discard)
지연된 프레임 또는 Out-Discard(일부 플랫폼에서는 Out-Lost라고도 함)가 많다면, 스위치의 출력 버퍼가 가득 차서 스위치에서 이 패킷을 삭제해야 함을 의미합니다. 이는 해당 세그먼트가 저조한 속도 또는 듀플렉스로 실행되고 있거나 이 포트를 지나는 트래픽이 너무 많다는 신호일 수 있습니다.
OutDiscards를 보려면 show interfaces counters error 명령을 사용합니다.
Router#show interfaces counters error Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Fa7/47 0 0 0 0 0 0 Fa7/48 0 0 0 0 0 2871800 Fa8/1 0 0 0 0 0 2874203 Fa8/2 103 0 0 103 0 2878032 Fa8/3 147 0 0 185 0 0 Fa8/4 100 0 0 141 0 2876405 Fa8/5 0 0 0 0 0 2873671 Fa8/6 0 0 0 0 0 2 Fa8/7 0 0 0 0 0 0
!--- The show interfaces counters errors command shows certain interfaces !--- that increment in large amounts OutDiscards while others run clean.
출력 버퍼 실패의 일반적인 원인을 조사합니다.
트래픽 양에 비해 저조한 속도/듀플렉스
네트워크에서 이 포트의 현재 속도/듀플렉스 설정에서 처리하기에는 너무 많은 패킷을 이 포트에 전송할 수 있습니다. 여러 고속 포트에서 (대개는 더 느린) 단일 포트로 전송하는 경우에 이러한 상황이 생길 수 있습니다. 이 포트에서 중단되는 디바이스를 더 빠른 미디어로 이동할 수 있습니다. 예를 들어 포트가 10Mbps라면 이 디바이스를 100Mbps 또는 기가비트 포트로 이동합니다. 토폴로지를 변경하여 프레임을 다른 방식으로 라우팅할 수 있습니다.
혼잡 문제: 세그먼트가 너무 혼잡함
세그먼트가 공유되는 경우, 이 세그먼트의 다른 디바이스에서 너무 많이 전송하여 스위치에서 전송하지 못할 수 있습니다. 가급적 데이지 체인 허브를 사용하지 마십시오. 혼잡 때문에 패킷 손실이 일어날 수 있습니다. 패킷 손실 때문에 전송 레이어에서 재전송이 일어나고, 그러면 사용자는 애플리케이션 레벨에서 레이턴시를 경험하게 됩니다. 10Mbps 링크를 100Mbps 또는 기가비트 이더넷 링크로 업그레이드할 수 있습니다(가능한 경우). 혼잡한 세그먼트의 일부 디바이스를 덜 혼잡한 세그먼트로 이동할 수 있습니다. 네트워크에서 혼잡 방지를 우선순위에 두십시오.
애플리케이션
사용되는 애플리케이션의 트래픽 전송 특성 때문에 출력 버퍼 문제가 발생할 수 있습니다. 32K 윈도우 크기의 UDP(user datagram protocol)를 사용하는 기가비트 연결 서버에서 보낸 NFS 파일 전송이 이러한 문제를 일으킬 수 있는 애플리케이션 설정의 예입니다. 이 문서에서 소개한 다른 제안(속도/듀플렉스 확인, 링크의 물리적 오류 확인, 모든 트래픽이 정상적인 유효한 트래픽인지 확인 등)을 고려하고 시도했다면, 애플리케이션에서 보내는 유닛 크기를 줄이면 이 문제를 완화할 수 있습니다.
소프트웨어 문제
"이상"으로 간주할 수 있는 동작이 표시되는 경우, 특정 시스템으로 동작을 격리할 수 있습니다. 그리고 지금까지 살펴본 모든 제안 사항을 확인했다면, 소프트웨어 또는 하드웨어 문제를 의미할 수도 있습니다. 일반적으로 하드웨어를 업그레이드하는 것보다 소프트웨어를 업그레이드하는 것이 더 쉽습니다. 먼저 소프트웨어를 변경합니다.
show version 명령을 사용하여 dir flash : 또는 dir bootflash: (플랫폼에 따라 다름) 명령과 함께 현재 소프트웨어 버전을 확인하여 업그레이드에 사용 가능한 플래시 메모리를 확인합니다.
Router#show version Cisco Internetwork Operating System Software Cisco IOS (tm) Catalyst 4000 L3 Switch Software (cat4000-IS-M), Version 12.1(13)EW, EA RLY DEPLOYMENT RELEASE SOFTWARE (fc1) TAC Support: http://www.cisco.com/tac Copyright (c) 1986-2002 by cisco Systems, Inc. Compiled Fri 20-Dec-02 13:52 by eaarmas Image text-base: 0x00000000, data-base: 0x00E638AC ROM: 12.1(12r)EW Dagobah Revision 71, Swamp Revision 24 trunk-4500 uptime is 2 weeks, 2 days, 6 hours, 27 minutes System returned to ROM by redundancy reset System image file is "bootflash:cat4000-is-mz.121-13.EW.bin"
!--- Typical Cisco IOS show version output. Router#dir bootflash: Directory of bootflash:/ 1 -rw- 8620144 Mar 22 2002 08:26:21 cat4000-is-mz.121-13.EW.bin 61341696 bytes total (52721424 bytes free)
!--- Verify available flash memory on switch running Cisco IOS.
소프트웨어 업그레이드 방법
Cisco 스위치용 소프트웨어를 업그레이드하는 방법에 대한 자세한 내용은 링크로 이동하여 플랫폼을 선택하고 소프트웨어 설정 섹션을 참조하십시오.
하드웨어 소프트웨어 비호환성
소프트웨어가 하드웨어와 호환되지 않는 경우도 있습니다. 새로운 하드웨어가 출시되어 소프트웨어의 특별한 지원이 필요한 경우에 그렇습니다. 소프트웨어 호환성에 대한 자세한 내용은 Software Advisor 툴을 사용하십시오.
소프트웨어 버그
운영 체제에 버그가 있을 수 있습니다. 최신 소프트웨어 버전을 로드하여 이 문제가 해결될 때가 많습니다. 소프트웨어 버그 툴킷을 사용하여 알려진 소프트웨어 버그를 검색할 수 있습니다.
손상된 이미지
이미지가 손상되었을 수 있습니다. 손상된 이미지의 복구에 대해서는 플랫폼 스위치를 선택하고 문제 해결 섹션을 참조하십시오.
하드웨어 문제
Cisco IOS를 실행하는 Catalyst 6000 및 4000 Series 스위치에 대한 show module의 결과를 확인합니다.
스위치의 POST 결과에서 스위치의 일부에 대해 실패가 표시되었는지 확인합니다. 모듈 또는 포트에 대한 테스트가 실패하면 테스트 결과에 ' F '가 표시됩니다.
Cisco IOS의 경우 Cat6000과 같은 모듈형 스위치에서 show diagnostics 명령을 사용합니다. 모듈당 POST 결과를 보려면 show diagnostics module <module> 명령을 사용합니다.
ecsj-6506-d2#sh diagnostic module 3
Current Online Diagnostic Level = Minimal
!--- The diagnostic level is set to minimal which is a shorter,
!--- but also less thorough test result.
!--- You may wish to configure diagnostic level complete to get more test results.
Online Diagnostic Result for Module 3 : MINOR ERROR
Online Diagnostic Level when Line Card came up = Minimal
Test Results: (. = Pass, F = Fail, U = Unknown)
1 . TestLoopback :
Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
----------------------------------------------------------------------------
. . . . . . . . . . . . . . . . . . F F F F F F
!--- Notice the MINOR ERROR test result and failed loopback test which means
!--- these ports are currently unusable.
!--- Use the hw-module{mod}reset command or, if necessary, physically reseat the
!--- module to try and fix this problem.
!--- If these steps fail, open a case with Cisco Technical Support.
Cisco IOS를 실행하는 Catalyst 스위치의 하드웨어 문제를 해결하는 방법에 대한 자세한 내용은 Cisco Switches 지원 페이지로 이동하여 플랫폼을 선택하고 Troubleshooting > Hardware 섹션을 참조하십시오. 필드 알림과 관련하여 발생할 수 있는 문제에 대해서는 LAN/ATM 스위치에 대한 Field Notices(필드 알림)를 참조하십시오.
레이어 2 스위치포트에 연결된 레이어 3 인터페이스의 입력 오류
기본적으로 모든 레이어 2 포트는 dynamic desirable 모드에 있습니다. 따라서 레이어 2 포트는 트렁크 링크 구성을 시도하고 원격 디바이스에 DTP 패킷을 보냅니다. 레이어 3 인터페이스가 레이어 2 스위치포트에 연결되어 있으면 이 프레임을 해석할 수 없습니다. 그로 인해 Input 오류와 WrongEncap 오류가 발생하고 Input 대기열에서 삭제가 일어납니다.
이 문제를 해결하려면, 요구 사항에 따라 스위치포트 모드를 static access 또는 trunk 로 변경합니다.
Switch2(config)#interface fastEthernet1/0/12 Switch2(config-if)#switchport mode access
또는
Switch2(config)#interface fastEthernet1/0/12
Switch2(config-if)#switchport trunk encapsulation dot1q
Switch2(config-if)#switchport mode trunk
Rx-No-Pkt-Buff 카운터 및 입력 오류가 빠르게 증가
WS-X4448-GB-RJ45, WS-X4548-GB-RJ45, WS-X4548-GB-RJ45V와 같은 블레이드가 있는 포트에서는 Rx-No-Pkt-Buff 카운터가 증가할 수 있습니다. 또한 일부 패킷 삭제 증가는 정상적인 동작이며, 버스트 트래픽의 결과입니다.
이러한 유형의 오류는 특히 해당 링크를 통과하는 트래픽이 많거나 해당 인터페이스에 연결된 디바이스(예: 서버)가 있는 경우에 빠르게 증가합니다. 트래픽 로드가 많으면 포트가 오버서브스크립션됩니다. 그러면 입력 버퍼가 소진되고 Rx-No-Pkt-Buff 카운터 및 입력 오류가 빠르게 증가합니다.
스위치에서 패킷 버퍼가 부족해져 패킷을 완전히 수신하지 못하면, 패킷이 삭제될 때마다 이 카운터가 증가합니다. 이 카운터는 수퍼바이저에 있는 스위칭 ASIC의 내부 상태를 나타내며, 반드시 오류 조건을 의미하는 것은 아닙니다.
Pause 프레임
포트의 수신 파트(Rx)에서 Rx FIFO 대기열이 차고 상위 워터마크에 도달하면 포트의 전송 파트(Tx)에서 pause 프레임을 생성하기 시작하며, 여기서 interval 값이 언급됩니다. 원격 디바이스는 pause 프레임에 언급된 interval 값에 따라 패킷 전송을 중지하거나 줄일 것입니다.
Rx에서 Rx 대기열을 지우거나 이 interval 내에서 하위 워터마크에 도달할 수 있는 경우, Tx는 interval을 0(0x0)으로 언급하는 특수 pause 프레임을 보냅니다. 그러면 원격 디바이스에서 패킷 전송을 시작할 수 있습니다.
Rx가 계속 대기열에서 작동하고 있는 경우, interval 시간 값이 만료되면 Tx는 새 interval 값을 가진 새 pause 프레임을 다시 보냅니다.
Rx-No-Pkt-Buff가 0이거나 증가하지 않고 TxPauseFrames 카운터가 증가한다면, 스위치에서 pause 프레임을 생성하고 원격 엔드가 수용하며, 그에 따라 Rx FIFO 대기열이 소진되었음을 의미합니다.
Rx-No-Pkt-Buff가 증가하고 TxPauseFrames도 증가한다면, 원격 엔드가 pause 프레임을 무시하고(플로우 제어를 지원하지 않음) pause 트래픽에 상관없이 계속 트래픽을 보내고 있다는 뜻입니다. 이러한 상황을 해결하려면 속도 및 듀플렉스를 수동으로 구성합니다. 또한 필요하다면 플로우 제어를 비활성화합니다.
인터페이스에서 발생하는 이러한 유형의 오류는 오버서브스크립션된 포트의 트래픽 문제와 관련 있습니다. WS-X4448-GB-RJ45, WS-X4548-GB-RJ45, WS-X4548-GB-RJ45V 스위칭 모듈은 오버서브스크립션된 포트 48개가 있는데, 각각 포트 8개가 포함된 그룹 6개로 구성됩니다.
-
포트 1, 2, 3, 4, 5, 6, 7, 8
-
포트 9, 10, 11, 12, 13, 14, 15, 16
-
포트 17, 18, 19, 20, 21, 22, 23, 24
-
포트 25, 26, 27, 28, 29, 30, 31, 32
-
포트 33, 34, 35, 36, 37, 38, 39, 40
-
포트 41, 42, 43, 44, 45, 46, 47, 48
각 그룹에 있는 포트 8개는 공통 회로를 사용하므로, 사실상 이 그룹은 내부 스위치 패브릭과의 단일 비 차단 풀 듀플렉스(full-duplex) 기가비트 이더넷 연결로 멀티플렉싱됩니다. 포트 8개로 이루어진 그룹별로 수신되는 프레임은 버퍼링되었다가 내부 스위치 패브릭과의 공통 기가비트 이더넷 링크로 보내집니다. 어떤 포트에서 수신된 데이터의 양이 버퍼 용량을 초과하기 시작하면, 플로우 제어에서 원격 포트에 pause 프레임을 보내 일시적으로 트래픽을 중지하여 프레임 손실을 방지합니다.
임의의 그룹에서 수신된 프레임이 1Gbps 대역폭을 초과할 경우, 디바이스에서 프레임을 삭제하기 시작합니다. 이러한 삭제는 실제 인터페이스가 아닌 내부 ASIC에서 이루어지므로 확실히 드러나지 않습니다. 이로 인해 디바이스 전반의 패킷 처리 속도가 느려질 수 있습니다.
Rx-No-Pkt-Buff는 총트래픽 속도와 상관없습니다. 모듈 ASIC의 Rx FIFO 버퍼에 저장된 패킷의 양에 따라 달라집니다. 이 버퍼의 크기는 16KB에 불과합니다. 일부 패킷이 이 버퍼를 채우면 짧은 버스트 트래픽 플로우로 카운트됩니다. 따라서 WS-X4548-GB-RJ45가 8:1 오버서브스크립션된 모듈이므로 이 ASIC 포트 그룹의 총트래픽 속도가 1Gbps를 초과하면 각 포트의 Rx-No-Pkt-Buff가 카운트될 수 있습니다.
이 인터페이스를 통해 방대한 양의 트래픽을 전달해야 하는 디바이스가 있다면, 그룹별로 1개의 포트를 사용하는 것을 고려해보십시오. 그러면 단일 그룹을 공유하는 공통 회로가 이 트래픽의 양에 영향을 받지 않습니다. 기가비트 이더넷 스위칭 모듈이 완전히 활용되고 있지 않다면, 포트 그룹 전반의 포트 연결을 균형적으로 조정하면서 가용 대역폭을 극대화할 수 있습니다. 예를 들어, WS-X4448-GB-RJ45 10/100/1000 스위칭 모듈에서는 같은 그룹에 속한 포트, 이를테면 1, 2, 3, 4, 5, 6, 7, 8을 연결하기에 앞서 서로 다른 그룹에 속한 포트, 이를테면 4, 12, 20, 30(임의의 순서)을 연결할 수 있습니다. 그래도 문제가 해결되지 않으면 포트 오버스크립션이 없는 모듈을 고려해야 합니다.
알 수 없는 프로토콜 삭제 이해
알 수 없는 프로토콜 삭제는 인터페이스의 카운터입니다. 라우터/스위치에서 인식하지 못하는 프로토콜이 원인입니다. 이 show run interface 명령의 예는 GigabitEthernet 0/1 인터페이스에서 알 수 없는 프로토콜 삭제를 보여줍니다.
Switch#show run interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is BCM1125 Internal MAC, address is 0000.0000.0000 (via 0000.0000)
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:05, output 00:00:03, output hang never
Last clearing of "show interface" counters 16:47:42
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
3031 packets input, 488320 bytes, 0 no buffer
Received 3023 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 63107 multicast, 0 pause input
0 input packets with dribble condition detected
7062 packets output, 756368 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
2015 unknown protocol drops
4762 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
알 수 없는 프로토콜 삭제는 대개 이 패킷을 수신하는 인터페이스가 해당 프로토콜 유형에 대해 구성되지 않았기 때문에 일어납니다. 또는 라우터가 인식하지 못하는 임의의 프로토콜일 수도 있습니다. 만약 2개의 라우터가 연결되어 있는데 한쪽 라우터 인터페이스에서 CDP를 비활성화하면 해당 인터페이스에서 알 수 없는 프로토콜 삭제가 일어납니다. 이제 CDP 패킷은 인식되지 않으며, 따라서 삭제됩니다.
스위치와 라우터 간의 트렁킹
스위치와 라우터 사이의 트렁크 링크 때문에 스위치포트가 중단될 수 있습니다. 스위치포트를 비활성화했다가 활성화하면 트렁크가 살아날 수 있으나, 결국 스위치포트가 다시 중단될 수 있습니다.
이 문제를 해결하려면 다음 단계를 수행합니다.
-
스위치와 라우터 간에 CDP(Cisco Discovery Protocol)가 실행되고 둘 다 상대방을 인식할 수 있는지 확인합니다.
-
라우터의 인터페이스에서 Keepalives를 비활성화합니다.
-
두 디바이스 모두에서 트렁크 캡슐화를 재구성합니다.
keepalives가 비활성화되면 CDP는 링크를 활성화하여 정상적으로 작동하게 합니다.
오버서브스크립션으로 인한 연결 문제
WS-X6548-GE-TX 또는 WS-X6148-GE-TX 모듈을 사용할 때, 개별 포트 사용률 때문에 연결 문제가 생기거나 주변 인터페이스에서 패킷 손실이 일어날 수 있습니다. 오버서브스크립션에 대한 자세한 내용은 인터페이스/모듈 연결 문제를 참조하십시오.
SPA 모듈의 하위 인터페이스
SPA 모듈에서 802.1Q로 하위 인터페이스를 만들면, 같은 VLAN을 스위치에서 사용할 수 없습니다. 하위 인터페이스에 캡슐화 dot1q가 있으면 이제 시스템에서 해당 VLAN을 사용할 수 없습니다. 6500 또는 7600 내부에서 VLAN을 할당하고 그 하위 인터페이스를 유일한 멤버로 설정하기 때문입니다. 이 문제를 해결하려면 하위 인터페이스 대신 트렁크 포트를 생성합니다. 그러면 모든 인터페이스에서 VLAN을 볼 수 있습니다.
출력 삭제 트러블슈팅
일반적으로 출력 삭제는 QoS가 설정된 상태에서 특정 패킷 클래스에 충분한 대역폭을 제공하지 않는 경우에 일어날 수 있습니다. 하드웨어가 초과 서브스크립션인 상황에서도 발생합니다.
여기서도 Catalyst 6500 시리즈 스위치의 인터페이스 GigabitEthernet 8/9에서 상당한 양의 출력 삭제가 이루어집니다.
Switch#show interface GigabitEthernet8/9
GigabitEthernet8/9 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 0013.8051.5950 (bia 0013.8051.5950)
Description: Connection To Bedok_Core_R1 Ge0/1
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 18/255, rxload 23/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is SX
input flow-control is off, output flow-control is off
Clock mode is auto
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:28, output 00:00:10, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/3/0 (size/max/drops/flushes); Total output drops: 95523364
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 94024000 bits/sec, 25386 packets/sec
5 minute output rate 71532000 bits/sec, 24672 packets/sec
781388046974 packets input, 406568909591669 bytes, 0 no buffer
Received 274483017 broadcasts (257355557 multicasts)
0 runts, 0 giants, 0 throttles
3 input errors, 2 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
749074165531 packets output, 324748855514195 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
이 문제를 분석하려면 다음 명령의 출력을 수집합니다.
-
show fabric utilization detail
-
show fabric errors
-
show platform hardware capacity
-
show catalyst6000 traffic-meter
-
show platform hardware capacity rewrite-engine drop
Show interface 명령 출력의 Last Input Never
이 show interface 명령의 예에서는 TenGigabitEthernet1/15 인터페이스의 Last input never를 보여줍니다.
Switch#show interface TenGigabitEthernet1/15
TenGigabitEthernet1/15 is up, line protocol is up (connected)
Hardware is C6k 10000Mb 802.3, address is 0025.84f0.ab16 (bia 0025.84f0.ab16)
Description: lsnbuprod1 solaris
MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 10Gb/s
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:17, output hang never
Last clearing of "show interface" counters 2d22h
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 46000 bits/sec, 32 packets/sec
52499121 packets input, 3402971275 bytes, 0 no buffer
Received 919 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
118762062 packets output, 172364893339 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
인터페이스에서 마지막 패킷을 성공적으로 수신하고 라우터에서 로컬로 처리한 후 경과한 시간(시간, 분, 초)을 표시합니다. 이는 무반응 인터페이스에서 실패한 시점을 파악하는 데 유용합니다. 이 카운터는 패킷의 빠른 스위칭이 아니라 프로세스 스위칭이 일어날 때에만 업데이트됩니다. Last input never는 상대편 엔드포인트 또는 터미널에 대한 성공적인 인터페이스 패킷 전송이 없었음을 의미합니다. 대개는 해당 엔터티와 관련된 패킷 전송이 없었다는 뜻입니다.
관련 정보
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
2.0 |
03-Nov-2023 |
재인증 |
1.0 |
04-Dec-2001 |
최초 릴리스 |
피드백