스위치 포트 및 인터페이스 문제 해결

다운로드 옵션

PDF (484.3 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (114.4 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (157.6 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2022년 7월 28일 (목)

문서 ID:12027

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서에서는 포트 또는 인터페이스에 문제가 발생하는 이유를 확인하는 방법에 대해 설명합니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서는 Cisco IOS® 시스템 소프트웨어에서 실행되는 Catalyst 스위치에 적용됩니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 규칙을 참조하십시오.

참고: 툴 및 웹 사이트에 액세스하려면 등록된 Cisco 클라이언트여야 합니다.

물리적 레이어 문제 해결

문제 해결을 위해 LED 사용

스위치에 물리적으로 액세스할 수 있는 경우 save 링크 상태를 제공하거나 오류 상태(빨간색 또는 주황색인 경우)를 나타낼 수 있는 포트 LED를 확인하는 시간. 다음 표에서는 이더넷 모듈 또는 고정 컨피그레이션 스위치의 LED 상태 표시기를 설명합니다.

플랫폼	URL
Catalyst 6000 시리즈 스위치	이더넷 모듈 LED
Catalyst 4000 시리즈 스위치	이더넷 모듈 LED
Catalyst 3750 Series Switch	전면 패널 LED
Catalyst 3550 Series 스위치	전면 패널 LED
Catalyst 2950/2955 시리즈 스위치	전면 패널 LED
Catalyst 2900/3500XL 시리즈 스위치	전면 패널 LED
Catalyst 1900 및 2820 시리즈 스위치	전면 패널 LED

양쪽 모두 링크가 있는지 확인합니다. 한쪽의 선이 끊어져 있거나 포트가 종료 상태이면, 한쪽에 링크 표시등이 켜지고 다른 쪽에는 켜지지 않는 문제가 발생할 수 있습니다.

링크 표시등은 케이블이 온전히 작동한다고 보증하지 않습니다. 케이블에 물리적 스트레스가 발생하여 최소 수준으로 작동할 수도 있습니다. 일반적으로 포트에서 패킷 오류가 빈번하거나 포트 플랩 현상(링크가 끊겼다가 다시 연결됨)이 계속된다면 이러한 상황으로 볼 수 있습니다.

케이블 및 연결의 양쪽을 모두 확인합니다.

포트의 링크 표시등이 켜지지 않으면 다음과 같은 가능성을 고려할 수 있습니다.

가능한 원인	정정 작업
케이블이 연결되지 않음	스위치에서 정상 작동이 확인된 디바이스에 케이블을 연결합니다.
잘못된 포트	케이블의 양쪽 끝이 정확한 포트에 꽂혀 있는지 확인합니다.
디바이스에 전원이 들어오지 않음	양쪽 디바이스의 전원이 모두 켜져 있는지 확인합니다.
잘못된 케이블 유형	선택한 케이블을 확인합니다. Catalyst 스위치 케이블 가이드를 참조하십시오.
불량 케이블	의심스로운 케이블을 정상 작동이 확인된 케이블로 바꿉니다. 커넥터의 핀이 부러지거나 없어졌는지 확인합니다.
느슨한 연결	연결이 느슨한지 확인합니다. 케이블이 잭에 있는 것처럼 보이지만 실제로는 그렇지 않은 경우도 있습니다. 케이블을 분리하고 다시 끼웁니다.
패치 패널	결함 있는 패치 패널 연결을 제거합니다. 가능하다면 패치 패널을 우회하는 방식으로 제외합니다.
미디어 컨버터	결함 있는 미디어 컨버터(파이버-구리 등) 제거: 파이버-구리 등 가능하다면 미디어 컨버터를 우회하는 방식으로 이를 제외합니다.
불량 또는 잘못된 GBIC(Gigabit Interface Convertor)	의심스러운 GBIC를 정상 작동이 확인된 GBIC로 바꿉니다. 해당 GBIC 유형에 대한 하드웨어 및 소프트웨어 지원을 확인합니다.
포트 또는 모듈 포트 불량, 인터페이스 또는 모듈이 활성화되지 않음	의심스러운 포트 또는 모듈을 트러블슈팅하기 위해 케이블을 정상 작동이 확인된 포트로 이동합니다. Cisco IOS의 show interface 명령을 사용하여 errdisable, disable 또는 shutdown 상태를 확인합니다. show module 명령으로 하드웨어 문제일 수 있는 결함을 표시할 수 있습니다. 자세한 내용은 이 문서의 대표적인 포트 및 인터페이스 문제 섹션을 참조하십시오.

이더넷 구리 및 파이버 케이블

연결하려는 연결 유형에 맞는 케이블이 있는지 확인합니다. 카테고리 3 구리 케이블은 10Mbps UTP(Unshielded Twisted Pair) 연결에 사용할 수 있지만 10/100 또는 10/100/1000Mbps UTP 연결에는 사용할 수 없습니다. 10/100Mbps 또는 10/100/1000Mbps 연결에는 반드시 Category 5, category 5e 또는 Category 6 UTP를 사용합니다.

경고: Category 5e 및 Category 6 케이블은 구성에 사용되는 재료의 유전 특성 때문에 높은 수준의 정전기를 저장할 수 있습니다. 모듈에 케이블을 연결하기 전에 반드시 안정적이고 안전하게 케이블을 접지합니다. 특히 새 케이블을 연결할 때는 각별히 주의해야 합니다.

파이버 케이블의 경우 해당 거리 및 사용되는 파이버 포트 유형에 적합한 케이블인지 확인합니다. 두 가지 옵션은 SMF(single mode fiber) 또는 MMF(multimode fiber)입니다. 함께 연결된 디바이스의 포트가 둘 다 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 Switch Cable Guide를 참조하십시오.

기가비트 이더넷 문제 해결

디바이스 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)	구리/파이버 유형	코어 크기¹(미크론)	모달 대역폭(MHz/km)	케이블 거리²
WS-G54831000Base - T(구리)		Category 5 UTP Category 5e UTP Category 6 UTP			328ft(100m)
WS-G54841000BASE-SX³	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	MMF⁴SMF	62.5 50.0 50.0 8.3/9/10	500 400 500-	1804ft(550m) 1804ft(550m) 1804ft(550m) 6.2마일(10km)
WS-G54871000BASE-ZX⁵	1550	MMF SMF⁶	8.3/9/10 8.3/9/10		70km(43.5마일)⁷⁶².1마일(100km)

멀티 모드 광섬유 케이블에 지정된 숫자는 코어 지름을 나타냅니다. 단일 모드 광섬유 케이블의 경우, 8.3미크론이 코어 지름입니다. 9 마이크론 및 10 마이크론의 값은 투광성을 갖는 섬유 부분의 직경인 모드 필드 직경(MFD)을 의미한다. 이 영역은 섬유 코어와 클래딩을 덮는 작은 부분으로 구성됩니다. MFD는 코어 지름, 레이저 파장, 코어와 피복 간 굴절률 차이의 함수입니다.
거리는 파이버 손실에 따라 결정됩니다. 여러 스플라이스와 표준 이하의 Fiber-Optic 케이블로 케이블 거리가 줄어듭니다.
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.3 z-1998)보다 더 광범위합니다. 링크 협상을 활성화하면 시스템은 플로우 제어, 듀플렉스 모드, 원격 결함 정보를 자동 협상합니다. 링크의 양쪽 끝에서 링크 협상을 활성화하거나 비활성화해야 합니다. 링크의 양쪽 끝이 같은 값으로 설정되어야 합니다. 그렇지 않으면 링크를 연결할 수 없습니다. IEEE 802.3 z 표준이 승인되기 전에 생산된 디바이스에 연결할 때 문제가 발생했습니다. 어떤 디바이스도 기가비트 자동 협상을 지원하지 않는 경우 기가비트 자동 협상을 비활성화합니다. 그러면 링크가 강제로 켜집니다. 카드 펌웨어가 10/100/1000BASE-T-TX 링크/포트가 꺼져 있음을 소프트웨어에 알리는 데 300밀리초가 걸립니다. 300밀리초 기본 디바운스 타이머는 펌웨어 폴링 타이머에서 라인카드까지이며, 300밀리초 단위로 발생합니다. 이 링크가 1G(1000BASE-T-TX) 모드에서 실행되는 경우, 10밀리초마다 기가비트 동기화가 수행되므로 링크 중단을 더 빨리 탐지할 수 있습니다. GigabitEthernet over Fiber와 구리에서 GigabitEthernet을 실행할 때의 링크 장애 감지 시간은 다릅니다. 이 탐지 시간 차이는 IEEE 표준을 기반으로 합니다.

경고: 자동 협상을 비활성화하면 링크 삭제 또는 물리적 레이어 문제가 숨겨집니다. 이는 IEEE 802.3z를 지원할 수 없는 구형 기가비트 NIC와 같은 엔드 디바이스를 사용하는 경우에만 필요합니다. 꼭 필요한 경우를 제외하고 스위치 간 자동 협상을 비활성화하지 마십시오. 물리적 레이어 문제가 드러나지 않은 채로 STP 루프가 발생할 수 있습니다. 대안으로, 벤더에 문의하여 소프트웨어/하드웨어 업그레이드를 통해 IEEE 802.3z 기가비트 자동 협상을 지원하는 방법도 있습니다.

기가비트이더넷 시스템 요구 사항 및 GBIC(Gigabit Interface Converter), CWDM(Coarse Wavelength Division Multiplexing), SFP(Small Form-Factor Pluggable) 시스템 요구 사항은 다음을 참조하십시오.

일반적인 컨피그레이션 정보 및 문제 해결 방법에 대한 추가 정보는 이더넷 10/100/1000MB 하프/풀 듀플렉스 자동 협상 구성 및 문제 해결을 참조하십시오.

연결 vs 비연결

대부분의 Cisco 스위치에는 notconnect 상태의 포트가 있습니다. 즉, 현재 아무 장치에도 연결되어 있지 않지만 다른 운영 장치에 제대로 연결되어 있으면 연결할 수 있습니다. 정상인 케이블을 비연결 상태의 스위치 포트 2개에 연결할 경우, 두 포트 모두 링크 표시등이 녹색으로 바뀌고 포트 상태는 연결됨으로 나타나야 합니다. 즉, L1(Layer 1)이 연결되면 포트가 작동함을 의미합니다.

Cisco IOS의 경우 show interfaces 명령을 사용하여 인터페이스가 작동 중인지, 회선 프로토콜이 작동(연결됨)되었는지 확인할 수 있습니다. 첫 번째 업은 인터페이스의 물리적 레이어 상태를 나타냅니다. 회선 프로토콜 작동 메시지는 인터페이스의 데이터 링크 계층 상태를 표시하고 인터페이스에서 keepalive를 보내고 받을 수 있음을 나타냅니다.

Router#show interfaces fastEthernet 6/1
FastEthernet6/1 is down, line protocol is down (notconnect)

!--- The interface is down and line protocol is down.
!--- 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 interface가 up/line protocol up(connected)을 표시하지만 두 명령 중 하나의 출력에서 오류가 증가하는 것을 볼 수 있는 경우 이 문서의 공통 포트 및 인터페이스 문제 섹션을 참조하십시오.

Cisco IOS에 대한 가장 일반적인 포트 및 인터페이스 명령 문제 해결

이 표에서는 수퍼바이저에서 Cisco IOS 시스템 소프트웨어를 실행하는 스위치에서 포트 또는 인터페이스 문제를 해결하는 데 사용되는 가장 일반적인 명령을 보여줍니다.

참고: 다음 표의 오른쪽 열에는 명령이 수행하는 작업에 대한 간략한 설명이 나와 있으며 플랫폼당 사용의 예외가 나열됩니다.

Cisco 디바이스에서 지원되는 명령의 출력이 있는 경우 Cisco CLI Analyzer를 사용하여 잠재적인 문제 및 해결 방법을 표시할 수 있습니다.

Cisco IOS 명령	설명
show version	이 명령은 소프트웨어 이미지 이름 및 버전 정보, 시스템 메모리 크기 등 Cisco 라우터와 유사한 출력을 표시합니다. 소프트웨어/하드웨어 비호환성(Release NotesorSoftware Advisor) 및 버그(Software Bug Toolkit 사용) 검색에 유용합니다.
show module	이 명령은 스위치에 있는 카드, 실행 중인 소프트웨어의 버전, 모듈의 상태를 표시합니다. 오케이, 결함 등등. 모듈 또는 포트의 하드웨어 문제를 진단하는 데 유용합니다. show module 명령으로 하드웨어 문제를 해결하는 방법에 대한 자세한 내용은 이 문서의 포트 또는 인터페이스 상태가 사용 안 함으로 설정되었거나 종료되었거나 하드웨어 문제 섹션을 참조하십시오.
show run-config	이 명령은 스위치의 현재 컨피그레이션 파일을 표시합니다. 변경 사항 `saved` write memory 명령을 사용하여 Cisco IOS의 컨피그레이션에 연결합니다. 이를 사용하면 모드/포트 또는 인터페이스의 컨피그레이션 오류가 문제를 일으킬 수 있는지 확인하는 데 유용합니다.
show interfaces	show interface 명령은 스위치 포트의 관리 및 운영 상태, 입력 및 출력 패킷, 버퍼 실패, 오류 등을 표시합니다.
clear counters	clear counters 명령을 사용하여 트래픽 및 오류 카운터를 0으로 만들면 문제가 일시적인지, 카운터가 계속 증가하는지 확인할 수 있습니다. 참고: Catalyst 6500/6000 Series 스위치는 clear counterscommand 명령을 사용하여 인터페이스의 비트 카운터를 지우지 않습니다. 이 스위치에서 비트 카운터를 지우려면 다시 로드할 수밖에 없습니다.
show interfaces counters	Catalyst 6000, 4000, 3550, 2950 및 3750 시리즈에서 사용할 명령입니다.
show counters interface show controller ethernet-controller	show counters interface 명령은 Catalyst 6000 시리즈용 소프트웨어 버전 12.1(13)E에만 도입되었으며 32비트 및 64비트 오류 카운터를 표시합니다. 2900/3500XL, 2950/2955, 3550, 2970 및 3750 시리즈 스위치의 Cisco IOS의 경우 how controllers Ethernet-controller 명령은 폐기된 프레임, 지연된 프레임, 정렬 오류, 충돌 등을 표시합니다.
show interfaces counters	Catalyst 6000, 4000, 3550, 2950 및 3750 시리즈에서 사용할 명령입니다.
진단 표시 게시물 표시	명령 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용 가장 일반적인 포트 및 인터페이스 문제 해결 명령 섹션에 설명되어 있습니다.

참고: 다양한 플랫폼과 릴리스에 걸쳐 카운터의 구현에 차이가 있을 수 있다. 카운터의 값은 정확한 편이지만, 설계상 고도로 정밀하지는 않습니다. 트래픽의 정확한 통계를 얻으려면, 스니퍼를 사용하여 필요한 인그레스 및 이그레스 인터페이스를 모니터링하는 것이 좋습니다.

어떤 카운터에서 지나치게 많은 오류가 발생한다면 대개는 문제가 있는 것입니다. 반이중 설정에서 작업할 경우 일부 데이터 링크 오류는 FCS(Frame Check Sequence), 정렬, 실행 및 충돌 카운터에서 증가합니다. 일반적으로 하프 듀플렉스 연결에서는 전체 트래픽 대비 오류의 비율이 1%라면 괜찮습니다. 입력 패킷 대비 오류의 비율이 2~3%를 초과할 경우 성능 저하가 나타날 수 있습니다.

하프 듀플렉스 환경에서는 스위치 및 연결된 디바이스가 정확히 동시에 회선을 감지하고 전송하는 바람에 충돌이 발생할 수 있습니다. 충돌이 발생할 경우 프레임이 와이어에 완전히 복사되지 않아 프레임이 프래그먼트화되므로 런트, FCS 및 정렬 오류가 발생할 수 있습니다.

풀 듀플렉스에서 작동하는 경우 FCS, CRC(Cyclic Redundancy Checks), 맞춤, 런트 카운터의 오류를 최소화해야 합니다. 링크가 풀 듀플렉스에서 작동하는 경우 충돌 카운터는 활성화되지 않습니다. FCS, CRC, 맞춤 또는 런트 카운터가 증가하는 경우 듀플렉스 불일치가 일어났는지 확인합니다. 듀플렉스 불일치는 스위치가 풀 듀플렉스에서, 연결된 디바이스는 하프 듀플렉스에서 작동하는 경우 또는 그 반대의 상황을 가리킵니다. 듀플렉스 불일치가 일어나면 성능이 매우 느려지고 간헐적으로 연결되고 연결이 끊기기도 합니다. 풀 듀플렉스에서 데이터 링크 오류가 발생하는 또 다른 이유로는 불량 케이블, 결함 있는 스위치 포트, NIC 소프트웨어/하드웨어 문제 등이 있습니다. 자세한 내용은 이 문서의 대표적인 포트 및 인터페이스 문제 섹션을 참조하십시오.

Cisco IOS용 인터페이스 표시

show interfaces card-type {slot/port} 명령은 Supervisor의 Cisco IOS에서 오류 카운터와 통계를 표시하는 데 사용되는 명령입니다. 이 명령(Catalyst 6000, 4000, 3550, 2970 2950/2955 및 3750 Series 스위치)의 대체 명령은 인터페이스 오류 카운터만 표시하는 how interfacecard-type <slot/port>counters errors 명령입니다. 오류 카운터 출력에 대한 설명은 표 1을 참조하십시오.

참고: 2900/3500XL Series 스위치의 경우 show interfacescard-type {slot/port} 명령과 show controllers Ethernet-controller 명령을 사용합니다.

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 interface 명령 출력은 다음 순서대로 설명되어 있습니다.

up, line protocol is up(connected) - 첫 번째 up은 인터페이스의 물리적 레이어 상태를 나타냅니다. 회선 프로토콜 가동 메시지는 인터페이스의 데이터 링크 계층 상태를 표시하고 인터페이스에서 keepalive를 보내고 받을 수 있음을 나타냅니다.
MTU - 기본적으로 이더넷의 MTU(Maximum Transmission Unit)는 1500바이트입니다(프레임의 최대 데이터 부분).
전이중, 100Mb/s - 전이중 및 100Mbps는 인터페이스의 현재 속도 및 이중 설정입니다. 여기서는 이 결과를 얻기 위해 autoneg를 사용했는지 여부를 알 수 없습니다. 다음과 같이 how interfaces fastEthernet 6/1 statuscommand를 사용하여 이를 표시합니다.

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 명령을 사용하여 인터페이스 통계를 재설정합니다.

참고: 라우팅(예: 로드 및 안정성)에 영향을 줄 수 있는 변수는 카운터가 지워질 때 지워지지 않습니다.

입력 대기열 - 입력 대기열의 패킷 수입니다.Size/max/drops= 대기열의 현재 프레임 수/대기열에서 프레임 삭제를 시작하기 전에 유지할 수 있는 최대 프레임 수/최대 대기열 크기를 초과하여 삭제된 실제 프레임 수Flushes는 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 interface 명령 출력의 카운터와 VLAN 인터페이스에 대한 카운터는 다릅니다.VLAN 인터페이스에 대한 show interface의 출력에서 입력 패킷 카운터는 해당 패킷이 CPU에서 처리되는 레이어 3(L3)인 경우 증가합니다. 레이어 2(L2) 스위칭된 트래픽은 CPU에 도달하지 않으며 VLAN 인터페이스의 how 인터페이스 카운터에 계산되지 않습니다. 적절한 물리적 인터페이스에 대한 how interface 출력에 포함됩니다.

show interfaces <card-type> <slot/port> counters errorscommand는 Cisco IOS에서 인터페이스 오류의 출력만 표시하는 데 사용됩니다. 오류 카운터 출력에 대한 설명은 표 1을 참조하십시오.

Router#sh 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. Catalyst 6000 및 4000 Series의 show interfaces<card-type> <x/y> counters에 대한 Cisco IOS 오류 카운터 출력입니다.

카운터(알파벳순)	오류 카운터를 증가시키는 문제 및 일반적인 원인
맞춤-오류	설명:show interfaces counters errors error. 정렬 오류는 8진수의 짝수로 끝나지 않고 CRC(순환 중복 검사)가 잘못된 수신 프레임 수의 카운트입니다.일반적인 원인:이러한 오류는 일반적으로 이중 불일치 또는 물리적 문제(예: 케이블, 잘못된 포트 또는 잘못된 NIC)로 인해 발생합니다. 케이블이 포트에 처음 연결되면 이러한 오류 중 일부가 발생할 수 있습니다. 또한 포트에 연결된 허브가 있는 경우 허브에 있는 다른 장치 간의 충돌로 인해 이러한 오류가 발생할 수 있습니다.플랫폼 예외:정렬 오류는 Catalyst 4000 Series Supervisor I(WS-X4012) 또는 Supervisor II(WS-X4013)에서 계산되지 않습니다.
babbles	설명: show interfaces 카운터는 전송 jabber 타이머가 만료되었음을 나타냅니다. jabber는 1518옥텟보다 긴 프레임(프레임 비트를 제외하지만 FCS 옥텟을 포함)이며, 짝수 옥텟(정렬 오류)으로 끝나지 않거나 FCS 오류가 있습니다.
Carri-Sen	설명:show interfaces counters errors error. Carri-Sen(carrier sense) 카운터는 이더넷 컨트롤러가 하프 듀플렉스 연결에서 데이터를 전송하고자 할 때마다 증가합니다. 컨트롤러는 전선을 감지하여 전송하기 전에 전선이 통화 중이 아닌지 확인합니다.일반적인 원인:반이중 이더넷 세그먼트에서는 정상입니다.
collisions	설명:show interfaces 카운터 인터페이스가 미디어로 프레임을 전송하기 전에 충돌이 발생한 횟수입니다.일반 원인:충돌은 반이중으로 구성된 인터페이스에 대해 일반적이지만 전이중 인터페이스에서는 볼 수 없습니다. 충돌이 크게 증가한다면, 링크 사용량이 많다는 뜻입니다. 또는 연결된 디바이스와 듀플렉스가 일치하지 않을 수도 있습니다.
CRC	설명:show interfaces 카운터 이는 트래픽을 시작하는 LAN 스테이션 또는 원단 장치에 의해 생성된 CRC가 수신된 데이터에서 계산된 체크섬과 일치하지 않을 때 증가합니다.일반적인 원인:이는 일반적으로 LAN 인터페이스 또는 LAN 자체의 노이즈 또는 전송 문제를 나타냅니다. CRC 개수가 많으면, 대개는 충돌이 원인이지만 물리적 문제(예: 케이블링, 불량 인터페이스 또는 NIC) 또는 듀플렉스 불일치를 의미할 수도 있습니다.
deferred	설명:show interfaces 카운터 미디어가 사용 중이어서 대기한 후 성공적으로 전송된 프레임 수입니다.일반적인 원인:일반적으로 이 현상은 캐리어가 프레임을 전송하려고 할 때 이미 사용 중인 반이중 환경에서 나타납니다.
입력 일시 중지	설명:show interfaces 카운터 Increment in pause 입력 카운터는 수신 버퍼가 거의 꽉 찼을 때 연결된 디바이스에서 트래픽 일시 중지를 요청함을 의미합니다.일반적인 원인:이 카운터는 스위치가 프레임을 수락하므로 정보 제공을 위해 증가합니다. 연결된 디바이스에서 트래픽을 수신할 수 있을 때 pause packets가 중지됩니다.
드리블 조건의 입력 패킷	설명:show interfaces 카운터 드리블 비트 오류는 프레임이 너무 길다는 것을 나타냅니다.일반적인 원인:이 프레임 오류 카운터는 스위치에 프레임이 허용되므로 정보를 제공하기 위해 증가합니다.
Excess-Col	설명: show interfaces counters errors error. 과도한 충돌로 인해 특정 인터페이스에서 전송이 실패하는 프레임의 수입니다. 어떤 패킷에서 연속으로 16회 충돌이 있으면 과도한 충돌로 간주합니다. 그런 다음 패킷이 삭제됩니다. 일반적인 원인: 과도한 충돌은 일반적으로 세그먼트의 로드를 여러 세그먼트로 분할해야 함을 나타내지만 연결된 디바이스와의 이중 불일치를 나타낼 수도 있습니다. 풀 듀플렉스로 구성된 인터페이스에서는 충돌이 나타나서는 안 됩니다.
FCS-Err	설명: show interfaces counters errors error. 프레임 확인 시퀀스(FCS) 오류가 있지만 프레임 오류가 없는 유효한 크기 프레임 수입니다. 일반적인 원인: 일반적으로 케이블링, 잘못된 포트 또는 잘못된 NIC(네트워크 인터페이스 카드)와 같은 물리적 문제이지만 이중 불일치를 나타낼 수도 있습니다.
프레임	설명: show interfaces 카운터. 잘못 수신된 패킷 중 CRC 오류와 정수가 아닌 옥텟(정렬 오류)이 있는 패킷 수입니다. 일반적인 원인: 일반적으로 충돌이 발생했거나 케이블링, 잘못된 포트 또는 NIC와 같은 물리적 문제가 발생한 결과이지만 이중 불일치를 나타낼 수도 있습니다.
Giants	설명: show interfaces 및 show interfaces counters 오류. 수신된 프레임이 최대 IEEE 802.3 프레임 크기(점보 이더넷이 아닌 경우 1518바이트)를 초과하고 FCS(Frame Check Sequence)가 잘못되었습니다. 일반적인 원인: 대부분의 경우 NIC가 잘못되었기 때문입니다. 문제가 되는 장치를 찾아 네트워크에서 제거해 보십시오. 플랫폼 예외: Catalyst Cat4000 Series는 Cisco IOS Previous to software Version 12.1(19)EW를 실행하며 프레임 >1518바이트 동안 증가합니다. 12.1(19)EW 이후에 show interface의 giant는 프레임이 잘못된 FCS와 함께 1518바이트 이상 수신된 경우에만 증가합니다.
무시됨	설명: sh interfaces counter. 인터페이스 하드웨어가 내부 버퍼에서 부족하게 실행되었기 때문에 인터페이스에서 무시한 수신된 패킷 수입니다. 일반적인 원인: 브로드캐스트 스톰과 노이즈 버스트로 인해 무시된 개수가 증가할 수 있습니다.
Input errors	설명: show interfaces counter. 일반적인 원인: runts, giants, no buffer, CRC, frame, overrun 및 ignored count가 포함됩니다. 다른 입력 관련 오류 때문에 입력 오류 카운트가 증가할 수도 있으며, 일부 데이터그램에서 둘 이상의 오류가 발생할 수 있습니다. 따라서 이 합계는 열거된 입력 오류 카운트의 합계와 일치할 수 없습니다. 레이어 2 스위치포트에 연결된 레이어 3 인터페이스의 입력 오류 섹션도 참조하십시오.
Late-Col	설명: show interfaces 및 show interfaces counters errors 오류. 전송 프로세스 후반에 특정 인터페이스에서 충돌이 탐지된 횟수입니다. 10Mbit/s 포트의 경우 패킷 전송에서 512비트 시간(bit-time) 이후입니다. 10Mbit/s 시스템에서 512비트 시간은 51.2마이크로초에 해당합니다. 주원인: 이 오류는 여러 상황 중에서도 듀플렉스 불일치를 의미할 수 있습니다. 이중 불일치 시나리오에서는 늦은 충돌이 반이중 측에서 나타납니다. 반이중 측이 전송함에 따라 전이중 측은 자신의 차례를 기다리지 않고 동시에 전송하게 되어 늦은 충돌이 발생하게 된다. 지연 충돌은 이더넷 케이블 또는 세그먼트가 너무 길다는 의미일 수도 있습니다. 풀 듀플렉스로 구성된 인터페이스에서는 충돌이 나타나서는 안 됩니다.
lost carrier	설명: show interfaces counter. 전송 중에 캐리어가 손실된 횟수입니다. 일반적인 원인: 잘못된 케이블을 확인하십시오. 양쪽의 물리적 연결을 확인합니다.
Multi-Col	설명: show interfaces counters errors error. 인터페이스가 프레임을 미디어에 성공적으로 전송하기 전에 여러 충돌이 발생한 횟수입니다. 일반적인 원인: 반이중으로 구성된 인터페이스의 경우 충돌이 일반적이지만 전이중 인터페이스에서는 충돌을 볼 수 없습니다. 충돌이 크게 증가한다면, 링크 사용량이 많다는 뜻입니다. 또는 연결된 디바이스와 듀플렉스가 일치하지 않을 수도 있습니다.
no buffer	설명:show interfaces 카운터. 버퍼 공간이 없기 때문에 삭제된 수신 패킷 수입니다.일반적인 원인:무시된 수와 비교합니다. 대개 이러한 이벤트는 브로드캐스트 스톰이 원인일 수 있습니다.
no carrier	설명:show interfaces 카운터 전송에 캐리어가 없는 횟수입니다.일반적인 원인:잘못된 케이블이 있는지 확인하십시오. 양쪽의 물리적 연결을 확인합니다.
Out-Discard	설명:오류가 탐지되지 않았음에도 삭제하도록 선택한 아웃바운드 패킷 수입니다.일반적인 원인:이러한 패킷을 삭제하는 한 가지 가능한 이유는 버퍼 공간을 확보하기 위한 것일 수 있습니다.
출력 버퍼 실패 출력 버퍼 스왑 아웃	설명:show interfaces 카운터 실패한 버퍼 수와 교체된 버퍼 수입니다.일반적인 원인:포트로 전환된 트래픽의 비율이 높아서 트래픽 양을 처리할 수 없을 때 포트가 패킷을 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 카운터 인터페이스에서 데이터그램을 최종적으로 전송하지 못하게 한 모든 오류의 합계입니다.일반적인 원인:이 문제는 출력 큐 크기가 낮기 때문입니다.
overrun	설명:수신기 하드웨어가 수신된 데이터를 하드웨어 버퍼로 전달할 수 없는 횟수입니다.일반적인 원인:트래픽의 입력 속도가 데이터를 처리하는 수신기의 기능을 초과했습니다.
packets input/output	설명:show interfaces 카운터 인터페이스에서 수신하고 전송한 오류 없는 패킷의 총개수입니다. 인터페이스를 통해 트래픽이 제대로 이동하는지 확인하는 데 유용하므로 이러한 카운터의 증분을 모니터링합니다. bytes 카운터에는 시스템에서 수신하고 전송한 오류 없는 패킷의 데이터 및 MAC 캡슐화가 모두 포함됩니다.
Rcv-Err	설명: Catalyst 6000 Series 전용 - show interfaces counters error.일반적인 원인:플랫폼 예외를 참조하십시오.플랫폼 예외:Catalyst 5000 Seriesrcv-err = 수신 버퍼 오류. 예컨대 runt, giant 또는 FCS-Err는 rcv-err 카운터를 증가시키지 않습니다. 5K의 rcv-err 카운터는 과도한 트래픽이 발생한 경우에만 증가합니다. OnCatalyst 4000 Seriesrcv-err = 모든 수신 오류의 합입니다. 즉, Catalyst 5000과 달리 rut, giant 또는 FCS-Err과 같은 오류를 인터페이스에 수신할 때 rcv-err 카운터가 증가합니다.
Runts	설명:show interfaces 및 show interface counters 오류. 수신된 프레임이 최소 IEEE 802.3 프레임 크기(이더넷의 경우 64바이트)보다 작고 CRC가 잘못되었습니다.일반적인 원인:이중 불일치와 연결된 장치의 잘못된 케이블, 포트 또는 NIC와 같은 물리적 문제 때문일 수 있습니다.플랫폼 예외:Cisco IOSPrevious를 실행하는 Catalyst 4000 Series소프트웨어 버전 12.1(19)EW, runt = Undersize. Undersize = 64바이트보다 작은 프레임입니다. runt 카운터는 64바이트보다 작은 프레임을 수신한 경우에만 증가했습니다. 12.1(19)EW부터는 runt = 프래그먼트(fragment)입니다. 프래그먼트는 64바이트보다 작고 불량 CRC가 있는 프레임입니다. 그 결과 이제는 불량 CRC가 있는 64바이트 미만의 프레임이 수신될 때 표시 인터페이스 카운터와 프래그먼트 카운터 표시 인터페이스 카운터 오류가 증가합니다.Cisco Catalyst 3750 Series SwitchesCisco IOS 12.1(19)EA1 이전 릴리스에서 Catalyst 3750의 트렁크 인터페이스에 dot1q를 사용하는 경우, Catalyst 3750에서 61~64바이트이며 q 태그를 포함하는 유효한 dot1q 캡슐화된 패킷이 제대로 전달되더라도 Catalyst 3750에서 크기가 작은 프레임으로 계산되므로 표시 인터페이스 출력에서 실행 수를 확인할 수 있습니다. 아울러 이 패킷은 수신 통계에서 해당 카테고리(유니캐스트, 멀티캐스트 또는 브로드캐스트)에 보고되지 않습니다. 이 문제는 Cisco IOS 릴리스 12.1(19)EA1 또는 12.2(18)SE 이상에서 해결되었습니다.
Single-Col	설명:show interfaces counters errors error. 인터페이스가 미디어로 프레임을 전송하기 전에 한 번의 충돌이 발생한 횟수입니다.일반 원인:충돌은 반이중으로 구성된 인터페이스의 경우 정상이지만 전이중 인터페이스에서는 볼 수 없습니다. 충돌이 크게 증가한다면, 링크 사용량이 많다는 뜻입니다. 또는 연결된 디바이스와 듀플렉스가 일치하지 않을 수도 있습니다.
throttles	설명:show interfaces. 아마도 버퍼 또는 프로세서 오버로드로 인해 포트의 수신기가 비활성화된 횟수입니다. throttles 카운터 값 뒤에 별표(*)가 나타나면 명령이 실행될 때 인터페이스가 제한됨을 의미합니다.일반적인 원인:프로세서 오버로드를 증가시킬 수 있는 패킷에는 옵션이 있는 IP 패킷, 만료된 TTL, 비 ARPA 캡슐화, 프래그먼트화, 터널, ICMP 패킷, MTU 체크섬 실패 패킷, RPF 실패, IP 체크섬 및 길이 오류가 포함됩니다.
underruns	설명:스위치에서 처리할 수 있는 것보다 빠르게 송신기가 실행된 횟수입니다.일반적인 원인:한 인터페이스에서 다른 여러 인터페이스의 트래픽 버스트가 한꺼번에 많은 양의 트래픽이 발생하는 높은 처리량이 발생하는 상황에서 발생할 수 있습니다. underruns와 함께 인터페이스 재설정이 일어날 수 있습니다.
UnderSize	설명:show interfaces counters errors error . 수신된 프레임 크기가 64바이트의 최소 IEEE 802.3 프레임 크기(프레임 비트 제외, FCS 옥텟 포함)보다 작으며 잘 형성되어 있습니다.일반적인 원인:이러한 프레임을 전송하는 장치를 확인하십시오.
Xmit-Err	설명:show interfaces counters errors error. 내부 Tx(송신) 버퍼가 가득 찼음을 나타냅니다.일반적인 원인:Xmit-Err의 일반적인 원인은 낮은 대역폭 링크로 전환된 고대역폭 링크의 트래픽 또는 단일 아웃바운드 링크로 전환된 여러 인바운드 링크의 트래픽일 수 있습니다. 예를 들어, 기가비트 인터페이스에서 대량의 트래픽 버스트가 들어오고 100Mbps 인터페이스로 스위칭되는 경우, 이로 인해 100Mbps 인터페이스에서 Xmit-Err이 증가할 수 있습니다. 이는 인바운드 대역폭과 아웃바운드 대역폭의 속도가 일치하지 않아 해당 인터페이스의 출력 버퍼에 과도한 트래픽이 발생하기 때문입니다.

Cisco IOS용 인터페이스 카운터 표시

다음 출력에 표시된 대로 포트의 인바운드 및 아웃바운드 트래픽(유니캐스트, 멀티캐스트 및 브로드캐스트 트래픽)을 모니터링하려면 다음은 Supervisor에서 Cisco IOS를 실행할 때 show interfaceCard-type {slot/port} counterscommand를 사용하는 방법입니다.

참고: 표 1에 설명된 Cisco IOSshow interface counters errorscommand에 Out-Discard 카운터가 있습니다.

Router#sh 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용 카운터 인터페이스 표시

Catalyst 6000 Series용 Cisco IOS 소프트웨어 버전 12.1(13)E에만 도입된 show counters interfecard-type {slot/port} 명령은 포트 및 인터페이스에 대한 보다 자세한 통계를 제공합니다. 이 명령은 포트 또는 인터페이스당 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 충돌로 계산될 수 있습니다.
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) 카운터가 증가할 수 있습니다. 포트가 액세스 포트이고 포트가 ISL(Inter-Switch Link Protocol) 트렁크 포트에 연결된 경우, No dest 카운터의 값이 매우 큽니다. 모든 인바운드 ISL 패킷이 포워딩되지 않기 때문입니다. 이는 잘못된 컨피그레이션입니다. STP(Spanning Tree Protocol)에 의해 포트가 차단되는 경우, 대부분 패킷이 포워딩되지 않아 No dest 패킷이 됩니다. 포트에서 방금 링크를 확보했다면, (1초 미만의) 매우 짧은 순간에는 인바운드 패킷이 포워딩되지 않습니다. 포트가 VLAN에 홀로 있고 스위치의 다른 어떤 포트도 이 VLAN에 속해 있지 않다면, 모든 인바운드 패킷이 삭제되고 카운터가 증가합니다. 패킷이 수신된 포트에서 패킷의 목적지 주소를 확인하는 경우에도 이 카운터가 증가합니다. 포트 0/1에서 목적지 MAC 주소 X로 패킷을 수신했고, MAC 주소 X가 포트 0/1에 상주함을 스위치가 이미 알고 있다면, 카운터를 늘리고 패킷을 폐기합니다. 이는 다음과 같은 상황에서 일어날 수 있습니다. 허브가 포트 0/1에 연결되어 있고 이 허브에 연결된 워크스테이션에서 같은 허브에 연결된 다른 워크스테이션에 패킷을 전송하는 경우, 목적지 MAC가 같은 포트에 있으므로 포트 0/1는 이 패킷을 어디로도 포워딩하지 않습니다. 이는 스위치가 포트 0/1에 연결되어 있고 MAC 주소를 학습하기 위해 모든 포트에 패킷을 플러딩하기 시작하는 경우에도 발생할 수 있습니다. 고정 주소가 같은 VLAN의 또 다른 포트에 설정된 상태에서 수신 포트에 대해 어떤 고정 주소도 설정되지 않았다면 패킷은 삭제됩니다. 예컨대 MAC 주소 X에 대한 고정 맵이 포트 0/2에서 구성되어 포트 0/3에 트래픽을 포워딩하는 경우, 포트 0/2에서 패킷을 수신해야 합니다. 그렇지 않으면 패킷이 삭제됩니다. 포트 0/2와 같은 VLAN에 속한 다른 포트에서 패킷이 전송되는 경우 이 패킷은 삭제됩니다. 포트가 보안 포트라면 허용되지 않은 소스 MAC 주소가 있는 패킷은 포워딩되지 않으며, 카운터가 증가합니다.
No dest, multicast	No destination multicast는 포트에서 다른 어떤 포트로도 포워딩하지 않은 멀티캐스트 패킷의 수입니다.
No dest, broadcast	No destination broadcast는 포트에서 다른 어떤 포트로도 포워딩하지 않은 브로드캐스트 패킷의 수입니다.
Alignment errors	Alignment errors는 수신한 프레임 중에서 짝수 개수의 옥텟으로 끝나지 않고 불량 CRC가 있는 프레임의 수입니다.	정렬 오류는 와이어에 완전히 복사되지 않은 프레임으로 인해 프레임이 조각화되기 때문입니다. 정렬 오류는 반이중, 이중 불일치, 잘못된 하드웨어(NIC, 케이블 또는 포트) 또는 옥텟으로 끝나지 않고 잘못된 FCS를 갖는 프레임을 생성하는 연결된 디바이스에서의 충돌로 인해 발생합니다.
FCS errors	FCS error 카운트는 이더넷 프레임에서 불량 체크섬(CRC 값)과 함께 수신된 프레임의 수입니다. 이러한 프레임은 삭제되고, 다른 포트에 전파되지 않습니다.	FCS 오류는 반이중, 이중 불일치, 불량 하드웨어(NIC, 케이블 또는 포트) 또는 옥텟으로 끝나지 않고 불량 FCS를 갖는 프레임을 생성하는 연결된 디바이스에서의 충돌로 인해 발생합니다.
Undersize frames	이 값은 64옥텟 길이 미만(프레임 비트 제외, FCS 포함)이며 FCS 값이 양호한 수신된 총 패킷 수입니다.	이는 연결된 디바이스에 의해 불량 프레임이 생성되었음을 의미합니다. 연결된 디바이스가 올바르게 작동하는지 확인합니다.
Oversize frames	포트에서 네트워크로부터 수신한 패킷 중에서 1514바이트를 초과하는 패킷의 수입니다.	이는 결함 있는 하드웨어, dot1q 또는 ISL 트렁킹 컨피그레이션 문제를 나타낼 수 있습니다.
Collision fragments	길이가 64 옥텟 미만(프레임 비트는 제외되지만 FCS 포함)이고 잘못된 FCS 값을 갖는 총 프레임 수입니다.	이 카운터의 값이 증가한다면, 포트가 하프 듀플렉스로 구성되었음을 의미합니다. 양방향을 전이중으로 설정합니다.
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 스위치에 연결된 디바이스에서 패킷 삭제를 방지하려면 스위치에 연결된 디바이스의 고속 이더넷 인터페이스에서 eip cefcommand를 실행합니다.

%INTR_MGR-DFC1-3-INTR: Queueing Engine (Blackwater) [1]: FIC Fabric-A Received Unexpected Control Code

스위치 패브릭에서 패킷을 수신할 때 이 패킷의 패브릭 헤더에 있는 CRC 값이 Blackwater ASIC의 FIC(Fabric Interface Controller) 하위 블록에서 계산한 CRC 값과 일치하지 않으면 이 오류 메시지가 나타납니다. 이는 전송 중에 패킷이 손상되어 Blackwater가 손상된 패킷을 수신했음을 의미합니다.

Command Rejected: [Interface] not a Switching Port

L3 인터페이스와 L2 스위치포트를 모두 지원하는 스위치에서 "Command rejected: [interface] not a switching port"는 레이어 3 인터페이스로 구성된 포트에서 레이어 2와 관련된 명령을 입력하려고 할 때 표시됩니다.

인터페이스를 레이어 3 모드에서 레이어 2 모드로 변환하려면 interface configuration commandswitchport를 실행합니다. 이 명령을 실행한 다음 포트에서 레이어 2 속성을 구성합니다.

대표적인 포트 및 인터페이스 문제

포트 또는 인터페이스 상태가 Disable(비활성화) 또는 Shutdown(종료)

포트 연결 실패의 확실한 원인이지만 간과하기 쉬운 문제 중 하나가 스위치의 잘못된 컨피그레이션입니다. 포트에서 주황색 표시등이 계속 켜져 있으면, 사용자 인터페이스를 통해 또는 내부 프로세스에 의해 스위치 내부의 소프트웨어에서 포트를 종료한 것입니다.

참고: 이 플랫폼의 포트 LED 중 일부는 STP와 관련하여 다르게 작동합니다. 예를 들어 Catalyst 1900/2820은 STP 블록 모드에 있을 때 포트를 주황색으로 바꿉니다. 이러한 경우 주황색 표시등은 STP의 정상적인 기능을 나타낼 수 있습니다. Catalyst 6000/4000에서는 STP 차단 모드에서 포트 표시등이 주황색으로 바뀌지 않습니다.

포트 또는 모듈이 어떤 이유로든 비활성화되었거나 꺼져 있지 않은지 확인하십시오. 링크의 한쪽 또는 다른 쪽에서 포트 또는 모듈이 수동으로 종료된 경우, 포트를 다시 활성화할 때까지 링크가 작동하지 않습니다. 양쪽의 포트 상태를 확인합니다. show run interfaceccommand를 사용하여 인터페이스가 ashutdownstate인지 확인합니다.

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} statuscommand를 보면

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 loggingcommand는 errdisable 상태와 관련된 오류 메시지(정확한 메시지 형식은 다름)도 표시합니다.

errdisable로 인해 Wheb 포트 또는 인터레이스가 종료되는 것을 Cisco IOS의 원인이라고 합니다. 이 문제의 원인은 PAgP 플랩을 일으키는 EtherChannel 오컨피그레이션, 이중 불일치, BPDU 포트 가드 및 포트패트가 동시에 구성된 경우, 단방향 링크를 탐지하는 UDLD 등이 있습니다.

errdisable 복구 옵션을 구성하지 않는 한 포트 또는 인터페이스를 수동으로 다시 활성화하여 errdisable 상태에서 벗어나게 해야 합니다. Cisco IOS 소프트웨어에서는 errdisable 상태에서 구성 가능한 시간을 보낸 후 자동으로 포트를 다시 활성화할 수 있습니다. 요컨대 errdisable에서 복구하도록 인터페이스를 구성하더라도 근본 원인이 규명되지 않으면 문제가 재발합니다.

참고: Cisco IOS를 실행하는 스위치의 errdisable 상태에 대한 자세한 내용은 Recover Errdisable Port State on Cisco IOS Platforms를 참조하십시오.

이 표에서는 스위치에서 errdisable 상태를 확인하고 문제를 해결하는 데 사용되는 명령의 예를 보여줍니다. Cisco IOS 플랫폼에서 Recover Errdisable Port State(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이 사라지는 경우입니다. 인터페이스가 thewitchportcommand를 사용하는 레이어 2 스위치포트로 구성된 경우 이 문제가 발생할 수 있습니다.

레이어 2 스위치의 모든 포트는 VLAN에 속해 있습니다. L2 스위치포트로 구성된 레이어 3 스위치의 모든 포트 역시 VLAN에 속해 있어야 합니다. 그 VLAN이 삭제되면 포트 또는 인터페이스가 비활성화됩니다.

참고: 일부 스위치에서는 이러한 상황이 발생할 경우 각 포트에서 주황색 표시등이 계속 켜져 있습니다.

show vlanto verify와 함께 show interfacescard-type {slot/port} switchportcommand를 사용합니다.

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 트렁크 프로토콜) 이해 및 구성을 참조하십시오.

참고: switchport access vlan <vlan> 명령을 사용하여 포트를 액세스 포트로 구성한 후에도 show interface <interface> switchportcommand의 출력에 트렁크 포트로 표시된 경우 포트를 액세스 포트로 만들기 위해 witchport mode accesscommand를 실행합니다.

업링크 포트 또는 인터페이스 상태가 Inactive(비활성)임

Catalyst 4510R 시리즈 스위치에서 10기가비트 이더넷 및 기가비트 이더넷 SFP 업링크 포트 모두를 활성화하기 위해 이용할 수 있는 컨피그레이션 옵션이 있습니다. 10기가비트 이더넷 및 기가비트 이더넷 SFP 인터페이스를 동시에 사용하려면 hw-module uplink select allcommand를 실행합니다. 명령을 실행한 후 스위치를 다시 부팅합니다. 그렇지 않으면 show interface status module <module number> 명령의 출력에 업링크 포트가 비활성으로 표시됩니다.

Cisco IOS Software Release 12.2(25)SG는 Catalyst 4500 Switch에서 10기가비트 이더넷 및 기가비트 이더넷 SFP 인터페이스의 동시 사용을 지원합니다.

참고: Catalyst 4503, 4506 및 4507R 시리즈 스위치에서는 이 기능이 자동으로 활성화됩니다.

Catalyst 스위치 인터페이스 증가분의 지연된 카운터

이 문제는 해당 스위치로 향하는 트래픽 로드가 너무 많아 프레임이 폐기되기 때문에 발생합니다. 대개 지연된 프레임은 미디어가 사용 중이었기 때문에 대기했다가 성공적으로 전송된 프레임의 수입니다. 이는 일반적으로 캐리어가 프레임을 전송하려고 할 때 이미 사용 중인 반이중 환경에서 나타납니다. 그러나 풀 듀플렉스 환경에서도 해당 스위치로 향하는 로드가 너무 많으면 이 문제가 발생합니다.

해결 방법은 다음과 같습니다.

협상 불일치를 방지하기 위해 링크의 양쪽 끝을 풀 듀플렉스로 하드코딩합니다.
결함 없는 케이블 및 패치 코드를 사용하도록 케이블 및 패치 패널 코드를 바꿉니다.

참고: Supervisor 720의 GigabitEthernet에서 Deferred Counter 오류가 증가하는 경우 해결 방법으로 인터페이스에서 속도 협상을 켭니다.

때때로 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을 억제한다는 것입니다.

참고: PortFast는 또한 포트에서 스패닝 트리 계산을 우회하므로 호스트 포트에서만 사용하기에 적합합니다.

트렁킹 모드 불일치

링크의 양쪽에서 트렁킹 모드를 확인합니다. 양쪽의 모드가 같아야 합니다. 즉, 둘 다 ISL 또는 802.1q의 동일한 방법으로 트렁킹하거나 둘 다 트렁킹하지 않습니다. 한 포트에서 트렁킹 모드를 (auto 또는 desirable이 아닌) on으로 설정하고 다른 쪽 포트에서는 트렁킹 모드를 off로 설정하면 이들은 통신할 수 없습니다. 트렁킹은 패킷의 형식을 변경합니다. 포트가 링크에서 어떤 형식을 사용하는지 또는 서로 이해하지 못하는지에 대해 일치해야 합니다.

Cisco IOS의 경우 trunking 컨피그레이션과 네이티브 VLAN을 확인하려면 show interfacescard-type {mod/port} trunkcommand를 사용합니다.

Router#sh 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 dynamiccommand를 사용하거나 interfacekeyword를 대체합니다.

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.

스위치가 실제로 디바이스의 MAC 주소를 CAM 테이블에 가지고 있다는 것을 알게 되면, 이 디바이스가 ping을 시도하는 곳과 동일한 VLAN에 있는지 아니면 다른 VLAN에 있는지를 확인합니다.

엔드 디바이스가 Ping을 시도하는 곳과 다른 VLAN에 있는 경우 디바이스가 통신할 수 있도록 L3 스위치 또는 라우터를 구성해야 합니다. 엔드 디바이스 및 라우터/L3 스위치의 L3 주소 지정이 올바르게 구성되어 있어야 합니다. IP 주소, 서브넷 마스크, 기본 게이트웨이, 동적 라우팅 프로토콜 컨피그레이션, 고정 경로 등을 확인합니다.

Switchport 호스트를 사용하여 시작 지연 수정

스테이션이 스위치를 통해 연결할 때 기본 서버와 통신할 수 없는 경우, 물리적 레이어 링크가 시작된 후 활성화하려고 할 때 문제가 스위치 포트에서 지연될 수 있습니다. 경우에 따라 50초까지 지연되기도 합니다. 일부 워크스테이션은 서버를 찾기 위해 이렇게 오래 기다릴 수 없으며, 그 후 포기합니다. 이러한 지연은 STP, 트렁킹 협상(DTP), EtherChannel 협상(PAgP) 때문에 발생합니다. 이 모든 프로토콜은 해당 프로토콜이 필요하지 않은 액세스 포트에 대해 비활성화할 수 있습니다. 그러면 네이버 디바이스와의 링크를 설정하고 몇 초 후에 스위치 포트 또는 인터페이스에서 패킷 포워딩을 시작합니다.

Cisco IOS에서는 switchPort host 명령을 사용하여 채널링을 비활성화하고 spanning-tree portfast를 활성화하고 switchport nonegotiatecommand를 사용하여 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 defaultcommand를 사용하여 레이어 2 액세스 스위치 포트로 구성된 인터페이스에 portfast를 자동으로 적용할 수 있는 옵션이 있습니다. 해당 소프트웨어 릴리스의 명령 참조에서 이 명령을 사용할 수 있는지를 확인하십시오. 인터페이스당의 Spanning-tree portfastcommand를 사용할 수도 있지만, 이 경우 워크스테이션 시작 지연을 해결하기 위해 트렁킹 및 etherchannel을 별도로 꺼야 합니다.

참고: 시작 지연을 수정하는 방법에 대한 자세한 내용은 Portfast 및 기타 명령을 사용하여 워크스테이션 시작 연결 지연 수정을 참조하십시오.

속도/이중, 자동 협상 또는 NIC 문제

맞춤 오류, FCS 오류 또는 지연 충돌이 많이 발생한다면 다음 중 하나를 의미할 수 있습니다.

듀플렉스 불일치
케이블 불량 또는 손상
NIC 카드 문제

듀플렉스 불일치

두 스위치 간, 스위치와 라우터 간 또는 스위치와 워크스테이션이나 서버 간의 듀플렉스 설정이 일치하지 않는 경우가 속도/듀플렉스의 일반적인 문제입니다. 이 문제는 속도와 양방향을 수동으로 하드코딩하거나 두 디바이스 간의 자동 협상 문제로 인해 발생할 수 있습니다.

CDP(Cisco Discovery Protocol)가 활성화된 Cisco 디바이스끼리 일치하지 않을 경우 콘솔에 또는 두 디바이스의 로깅 버퍼에 CDP 오류 메시지가 나타납니다. CDP는 오류를 탐지하고 인접한 Cisco 디바이스의 포트 및 시스템 통계를 확인하는 데에도 유용합니다. CDP는 Cisco의 독점 기술이며 잘 알려진 MAC 주소 01-00-0C-CC-CC-CC로 패킷을 전송할 때 작동합니다.

이 예에서는 두 Catalyst 6000 시리즈 스위치 간의 듀플렉스 불일치 때문에 생성된 로그 메시지를 보여줍니다. 하나는 CatOS를, 다른 하나는 Cisco IOS를 실행합니다. 일반적으로 이러한 메시지를 통해 어디에서 무엇이 일치하지 않은지를 알 수 있습니다.

2003 Jun 02 11:16:02 %CDP-4-DUPLEXMISMATCH:Full/half duplex mismatch detected on port 3/2
!--- CatOS switch sees duplex mismatch.

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 IOS switch sees duplex mismatch.

Cisco 네이버 디바이스에 대한 CDP 정보를 표시하려면 show cdp neighbor-type <slot/port> detailcommand를 사용합니다.

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#

한쪽 면에 auto speed/duplex를 설정하고 반대쪽 면에는 100/Full-duplex를 설정하는 것 역시 잘못된 컨피그레이션이므로 듀플렉스가 일치하지 않을 수 있습니다. 스위치 포트에서 늦은 충돌이 많이 발생하는 경우, 이는 일반적으로 이중 불일치 문제를 나타내며 결과적으로 포트가 errdisable 상태가 될 수 있습니다. 하프 듀플렉스 측은 임의의 시간이 아닌 특정 시간에만 패킷을 예상하므로, 잘못된 시간에 수신된 패킷을 충돌로 계산합니다. 이중 불일치 외에도 늦은 충돌의 다른 원인이 있지만, 이는 가장 일반적인 이유 중 하나이다. 항상 연결의 양쪽을 속도/듀플렉스를 자동 협상하도록 설정하거나 양쪽에서 속도/듀플렉스를 수동으로 설정합니다.

속도와 이중 설정 및 기타 정보를 표시하려면 show interfaces <card-type> <slot/port> statuscommand를 사용합니다. 필요에 따라 인터페이스 컨피그레이션 모드에서 thespeedandduplexcommands를 사용하여 양쪽을 10 또는 100과 절반 또는 전체로 하드코딩합니다.

Router#show interfaces fasstEthernet 6/1 status
Port    Name               Status       Vlan       Duplex  Speed Type
Fa6/1                      connected    1          a-full  a-100 10/100BaseTX

statusoption 없이 theshow interfaces 명령을 사용하면 속도 및 이중화 설정이 표시되지만 이 속도 및 이중화가 자동 협상을 통해 달성되었는지 여부는 알 수 없습니다.

Router#sh int 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 문제를 해결하는 방법에 대한 자세한 내용은 Troubleshooting Cisco Catalyst Switches to NIC Compatibility Issues를 참조하십시오.

스패닝 트리 루프

STP(Spanning Tree Protocol) 루프가 포트 또는 인터페이스 문제와 비슷한 형태로 심각한 성능 문제를 야기할 수 있습니다. 이러한 상황에서는 같은 프레임이 대역폭을 계속 차지하고 있기 때문에 정상적인 트래픽에서 거의 사용하지 못합니다.

STP 루프 보호 기능은 레이어 2 포워딩 루프(STP 루프)를 막는 추가적인 보호 장치입니다. STP 루프는 이중화 토폴로지의 STP 블록 포트가 전달 상태로 잘못 전환될 때 생성됩니다. 이는 일반적으로 물리적으로 이중화된 토폴로지의 포트 중 하나(반드시 STP 블록 포트일 필요는 없음)가 더 이상 STP BPDU를 수신하지 않기 때문에 발생합니다. 이 작업에서 STP는 포트 역할에 따라 지속적인 BPDU 수신 또는 전송에 의존합니다. 지정된 포트가 BPDU를 전송하고, 지정되지 않은 포트에서 BPDU를 수신합니다.

물리적 이중화 토폴로지의 포트 중 하나에서 더는 BPDU를 수신하지 않으면, STP는 그 토폴로지에 루프가 없다고 가정합니다. 결국 대체 또는 백업 포트의 차단 포트가 지정되고 전달 상태로 전환됩니다. 이러한 상황에서 루프가 생성됩니다.

루프 가드 기능은 추가 확인을 수행합니다. BPDU가 지정되지 않은 포트에서 수신되지 않고 루프 가드가 활성화된 경우, 해당 포트는 수신/학습/포워딩 상태가 아닌 STP 루프 불일치 블록 상태로 이동합니다. 루프 가드 기능이 없으면 포트는 지정된 포트 역할로 가정합니다. 포트가 STP 포워딩 상태가 되어 루프가 생깁니다. 루프 가드 기능에 대한 자세한 내용은 Loop Guard 및 BPDU Skew Detection 기능을 사용하는 스패닝 트리 프로토콜 개선 사항을 참조하십시오.

이 문서에서는 STP가 실패할 수 있는 이유, 문제의 근본 원인 규명을 위해 확인할 정보, STP 위험을 최소화하는 설계 유형을 다룹니다.

단방향 링크 때문에 루프가 생길 수도 있습니다. 자세한 내용은 이 문서의 'UDLD: 단방향 링크 문제' 섹션을 참조하십시오.

UDLD: 단방향 링크

단방향 링크는 트래픽이 일방적으로 나가는 링크이지만 인그레스 방향에서는 트래픽이 수신되지 않습니다. 스위치는 링크 인그레스 방향이 잘못되었음을 알지 못합니다(포트가 링크가 작동하고 있다고 생각함).

손상된 파이버 케이블 또는 기타 케이블링/포트 문제 때문에 이 단방향 통신이 일어날 수 있습니다. 이처럼 부분적으로 작동하는 링크 때문에 스위치가 링크의 부분적인 장애를 알지 못해 STP 루프와 같은 문제가 생길 수 있습니다. UDLD는 단방향 링크를 탐지하면 포트를 errdisable 상태로 전환할 수 있습니다. udld aggressive-mode 명령은 단방향 링크를 허용할 수 없는 스위치 간의 포인트-투-포인트 연결을 위해 Cisco IOS를 실행하는 스위치에서 구성할 수 있습니다(명령 가용성은 릴리스 정보에서 확인). 이 기능은 찾기 어려운 단방향 링크 문제를 파악하는 데 유용합니다.

UDLD에 대한 컨피그레이션 정보는 UDLD(Unidirectional Link Detection Protocol) 기능 이해 및 구성을 참조하십시오.

지연된 프레임(Out-Lost 또는 Out-Discard)

지연된 프레임 수가 많거나 Out-Discard(일부 플랫폼에서는 Out-Lost라고도 함)가 있는 경우, 스위치 출력 버퍼가 가득 찼으므로 스위치에서 이러한 패킷을 삭제해야 합니다. 이는 해당 세그먼트가 저조한 속도 또는 듀플렉스로 실행되고 있거나 이 포트를 지나는 트래픽이 너무 많다는 신호일 수 있습니다.

OutDiscards를 보려면 theshow interfaces counters errorcommand를 사용합니다.

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 versioncommand를 사용하여 dir 플래시와 함께 현재 소프트웨어 버전을 확인합니다. ordir bootflash: 업그레이드에 사용 가능한 플래시 메모리가 있는지 확인합니다.

Router#show version
Cisco Internetwork Operating System Software
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과 같은 모듈형 스위치에서 commandshow 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.

참고: Catalyst 3750, 3550, 2970, 2950/2955 및 2900/3500XL Series 스위치의 경우, hw 상태에 대해 단순 통과 또는 실패를 나타내는 how postcommand를 사용합니다. POST 결과를 이해하는 데 이 스위치의 LED를 활용합니다.

Cisco IOS를 실행하는 Catalyst 스위치의 하드웨어 문제를 해결하는 방법에 대한 자세한 내용은 Cisco Switches 지원 페이지로 이동하여 플랫폼을 선택하고 Troubleshooting > Hardware섹션을 참조하십시오. Field Notice와 관련된 가능한 문제는 LAN 및 ATM 스위치의 Field Notices를 참조하십시오.

레이어 2 스위치포트에 연결된 레이어 3 인터페이스의 입력 오류

기본적으로 모든 레이어 2 포트는 비동적 권장 모드이므로 레이어 2 포트는 트렁크 링크 구성을 시도하고 DTP 패킷을 원격 디바이스로 전송합니다. 레이어 3 인터페이스가 레이어 2 스위치포트에 연결되어 있으면 이 프레임을 해석할 수 없습니다. 그로 인해 Input 오류와 WrongEncap 오류가 발생하고 Input 대기열에서 삭제가 일어납니다.

이를 해결하려면 요구 사항에 따라 스위치 포트의 모드를 static accessortrunkas로 변경합니다.

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개 포트는 내부 스위치 패브릭에 대한 단일 비블록 전이중 기가비트 이더넷 연결로 그룹을 효과적으로 멀티플렉싱하는 공통 회로를 사용합니다. 포트 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

알 수 없는 프로토콜 삭제는 일반적으로 이러한 패킷이 수신된 인터페이스가 이 유형의 프로토콜에 대해 구성되지 않았거나 라우터가 인식하지 못하는 프로토콜일 수 있으므로 삭제됩니다. 예를 들어, 두 개의 라우터가 연결되어 있고 한 라우터 인터페이스에서 CDP를 비활성화하면 해당 인터페이스에서 알 수 없는 프로토콜이 삭제됩니다. 이제 CDP 패킷은 인식되지 않으며, 따라서 삭제됩니다.

스위치와 라우터 간의 트렁킹

스위치와 라우터 사이의 트렁크 링크 때문에 스위치포트가 중단될 수 있습니다. 스위치포트를 비활성화했다가 활성화하면 트렁크가 살아날 수 있으나, 결국 스위치포트가 다시 중단될 수 있습니다.

이 문제를 해결하려면 다음 단계를 수행합니다.

스위치와 라우터 간에 CDP(Cisco Discovery Protocol)가 실행되고 둘 다 상대방을 인식할 수 있는지 확인합니다.
라우터의 인터페이스에서 Keepalives를 비활성화합니다.
두 디바이스 모두에서 트렁크 캡슐화를 재구성합니다.

keepalives가 비활성화되면 CDP는 링크를 활성화하여 정상적으로 작동하게 합니다.

오버서브스크립션으로 인한 연결 문제

WS-X6548-GE-TX 또는 WS-X6148-GE-TX 모듈을 사용할 때, 개별 포트 사용률 때문에 연결 문제가 생기거나 주변 인터페이스에서 패킷 손실이 일어날 수 있습니다. 오버서브스크립션에 대한 자세한 내용은 인터페이스/모듈 연결 문제를 참조하십시오.

SPA 모듈의 하위 인터페이스

SPA 모듈에서 802.1Q로 하위 인터페이스를 생성한 후에는 동일한 VLAN을 스위치에서 사용할 수 없습니다. 하위 인터페이스에 캡슐화 dot1q가 있으면 6500 또는 7600에서 내부적으로 VLAN을 할당하고 해당 하위 인터페이스를 유일한 멤버로 만들기 때문에 시스템에서 해당 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 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 인터페이스에 마지막으로 입력한 내용을 보여 줍니다.

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

인터페이스에서 마지막 패킷을 성공적으로 수신하고 라우터에서 로컬로 처리한 후 경과한 시간(시간, 분, 초)을 표시합니다. 이는 무반응 인터페이스에서 실패한 시점을 파악하는 데 유용합니다. 이 카운터는 패킷이 빠르게 전환되는 경우가 아니라 프로세스가 전환되는 경우에만 업데이트됩니다. 마지막 입력은 다른 엔드포인트 또는 터미널로 인터페이스 패킷이 성공적으로 전송되지 않았음을 의미합니다. 대개는 해당 엔터티와 관련된 패킷 전송이 없었다는 뜻입니다.