Cisco IOS 시스템 소프트웨어를 실행하는 Catalyst 스위치의 STP 문제 해결

다운로드 옵션

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

업데이트:2005년 9월 1일 (목)

문서 ID:28943

번역에 관하여

이 번역에 관하여

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

소개

이 문서에서는 STP(Spanning-Tree Protocol) 관련 문제를 해결하기 위해 Cisco IOS® 소프트웨어를 사용하는 지침을 제공합니다. Catalyst 6500/6000에만 적용되는 특정 명령이 있습니다.그러나 Cisco IOS 소프트웨어를 실행하는 모든 Cisco Catalyst 스위치에 대부분의 원칙을 적용할 수 있습니다.

대부분의 STP 트러블슈팅은 다음 세 가지 문제를 해결합니다.

전달 루프
STP 토폴로지 변경(TC) 비율이 높기 때문에 과도한 플러딩
통합 시간과 관련된 문제

브리징에는 특정 패킷이 여러 번 포워딩되는지 여부를 추적하는 메커니즘이 없으므로(예: 네트워크에서 너무 오래 순환되는 트래픽을 폐기하는 데 IP Time to Live [TTL]이 사용됨) 동일한 L2(Layer 2) 도메인에 있는 두 디바이스 간에는 하나의 경로만 존재할 수 있습니다.

STP의 목적은 STP 알고리즘을 기반으로 이중화된 포트를 차단하여 이중화된 물리적 토폴로지를 트리 형태의 토폴로지로 해결하는 것입니다.이중화 토폴로지의 포트가 차단되지 않고 트래픽이 무한정 원으로 원 안에 전달될 경우 포워딩 루프(예: STP 루프)가 발생합니다.

포워딩 루프가 시작되면 경로를 따라 가장 낮은 대역폭 링크가 혼잡할 수 있습니다. 모든 링크가 동일한 대역폭이면 모든 링크가 정체될 수 있습니다.이러한 혼잡은 패킷 손실을 야기하며 영향받는 L2 도메인에서 네트워크 중단 상황을 초래합니다.

과도한 홍수의 경우 증상은 분명치 않을 수 있다.일부 느린 링크는 플러딩된 트래픽으로 인해 혼잡해질 수 있으며, 이러한 혼잡한 링크의 디바이스 또는 사용자는 속도가 느려지거나 연결이 완전히 끊어질 수 있습니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

다양한 스패닝 트리 유형 및 구성 방법.자세한 내용은 STP 및 IEEE 802.1s MST 구성을 참조하십시오.
다양한 스패닝 트리 기능 및 구성 방법자세한 내용은 STP 기능 구성을 참조하십시오.

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

Catalyst 6500 with Supervisor 2 engine
Cisco IOS Software 릴리스 12.1(13)E

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

표기 규칙

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

STP가 실패하는 이유

STP는 운영 환경에 대해 특정 가정을 합니다.다음은 이 문서와 가장 관련이 있는 가정입니다.

두 브리지 사이의 각 링크는 양방향입니다.즉, A가 B에 직접 연결되면 A는 B가 전송한 것을 수신하고 B는 A가 전송한 것을 수신하며, B는 A가 전송한 것을 수신합니다(링크가 둘 사이에 있는 경우).
STP를 실행하는 각 브리지는 STP 패킷이라고도 하는 STP BPDU(Bridge Protocol Data Units)를 정기적으로 수신, 처리 및 전송할 수 있습니다.

이러한 가정이 논리적이고 분명한 것처럼 보이지만, 충족되지 않는 경우도 있습니다.이러한 상황은 대부분 일종의 하드웨어 문제와 관련이 있습니다.그러나 소프트웨어 결함은 STP 장애로 이어질 수도 있습니다.다양한 하드웨어 장애, 잘못된 구성 또는 케이블 연결은 대부분의 STP 오류를 발생시키는 반면, 소프트웨어 장애는 소수를 차지합니다.스위치 간에 불필요한 추가 연결 때문에 STP 장애가 발생할 수도 있습니다.이러한 추가 연결 때문에 VLAN은 다운 상태가 됩니다.이 문제를 해결하려면 스위치 간의 불필요한 연결을 모두 제거하십시오.

이러한 가정 중 하나가 충족되지 않으면 하나 이상의 브리지가 더 이상 BPDU를 수신하거나 처리하지 못할 수 있습니다.즉, 브리지(또는 브리지)가 네트워크 토폴로지를 검색할 수 없습니다.올바른 토폴로지를 알지 못하면 스위치에서 루프를 차단할 수 없습니다.따라서 플러딩된 트래픽은 루프된 토폴로지를 통해 순환하고 모든 대역폭을 사용하며 네트워크를 다운시킵니다.

스위치에서 BPDU를 수신하지 못하는 이유로는 불량 송수신기 또는 GBIC(Gigabit Interface Converter), 케이블 문제 또는 포트, 라인 카드 또는 수퍼바이저 엔진의 하드웨어 장애가 있습니다.STP 장애가 자주 발생하는 이유 중 하나는 브리지 간의 단방향 링크입니다.이러한 상황에서 하나의 브리지가 BPDU를 전송하지만 다운스트림 브리지는 수신하지 않습니다.스위치가 수신된 BPDU를 처리할 수 없기 때문에 오버로드된 CPU(99% 이상)에 의해 STP 프로세싱이 중단될 수도 있습니다.BPDU는 한 브리지에서 다른 브리지로 가는 경로를 따라 손상될 수 있으므로 적절한 STP 동작을 방지합니다.

포워딩 루프 외에도, 포트가 차단되지 않은 경우 특정 패킷만 차단 포트를 통해 잘못 전달되는 경우가 있습니다.대부분의 경우, 이는 소프트웨어 문제로 인해 발생합니다.이러한 동작은 "slow-loops"를 일으킬 수 있습니다. 즉, 일부 패킷은 루프되지만 링크가 혼잡하지 않을 수 있으므로 트래픽의 대부분은 여전히 네트워크를 통해 이동되고 있습니다.

이 문서의 나머지 섹션에서는 가장 일반적인 STP 관련 문제를 해결하는 지침을 제공합니다.

포워딩 루프 문제 해결

포워딩 루프는 원래(원인) 및 효과에 따라 크게 달라집니다.STP에 영향을 줄 수 있는 다양한 문제로 인해 이 문서에서는 전달 루프를 트러블슈팅하는 방법에 대한 일반적인 지침만 제공할 수 있습니다.

트러블슈팅을 시작하기 전에 다음 정보를 얻어야 합니다.

모든 스위치 및 브리지에 대해 자세히 설명하는 실제 토폴로지 다이어그램
해당(상호 연결) 포트 번호
STP 구성 세부 정보: 루트 및 백업 루트, 기본 비용 또는 우선 순위가 아닌 링크, 차단 포트 위치 등

일반적으로 문제 해결에는 다음 단계가 포함됩니다(상황에 따라 일부 단계가 필요하지 않을 수 있음).

루프를 식별합니다.

네트워크에서 포워딩 루프가 개발되면 일반적인 증상은 다음과 같습니다.
- 영향을 받는 네트워크 지역에 대한 연결 손실
- 영향을 받는 세그먼트 또는 VLAN에 연결된 라우터의 CPU 사용률이 높으므로 라우팅 프로토콜 네이버 플래핑 또는 HSRP(Hot Standby Router Protocol) 활성 라우터 플래핑 등의 다양한 증상이 발생할 수 있습니다.
- 높은 링크 사용률(대개 100%)
- 높은 스위치 백플레인 사용률(기본 사용률과 비교)
- 네트워크에서 패킷 루핑을 나타내는 Syslog 메시지(예: HSRP 중복 IP 주소 메시지)
- 지속적인 주소 재학습 또는 MAC 주소 플래핑 메시지를 나타내는 Syslog 메시지
- 많은 인터페이스에서 출력 드랍이 증가하는 경우
참고: 이러한 이유만으로 서로 다른 문제(또는 전혀 문제 없음)를 나타낼 수 있습니다. 그러나 이러한 중 다수가 동시에 관찰되면 네트워크에서 포워딩 루프가 발생할 가능성이 높습니다.

참고: 이를 확인하는 가장 빠른 방법은 스위치 백플레인 트래픽 사용률을 확인하는 것입니다.
```
cat# show catalyst6000 traffic-meter

  traffic meter =   13%  Never cleared
           peak =   14%  reached at 12:08:57 CET Fri Oct 4 2002
```
참고: Cisco IOS 소프트웨어가 포함된 Catalyst 4000은 현재 이 명령을 지원하지 않습니다.

현재 트래픽 레벨이 정상 수준보다 높거나 기준 수준을 알 수 없는 경우, 최근 피크 레벨이 달성되었는지, 현재 트래픽 레벨에 근접했는지 확인합니다.예를 들어 최대 트래픽 레벨이 15%이고 불과 2분 전에 도달했고 현재 트래픽 레벨이 14%인 경우, 이는 스위치가 비정상적으로 높은 부하 상태에서 작동함을 의미합니다.

트래픽 로드가 정상적인 수준이면 루프가 없거나 이 디바이스가 루프에 관련되어 있지 않음을 의미할 수 있습니다.하지만, 그것은 여전히 느린 루프에 관련될 수 있습니다.

루프의 토폴로지(범위)를 검색합니다.

네트워크 중단의 원인이 전달 루프라는 것이 확인되면 가장 우선순위가 높은 것은 루프를 중지하고 네트워크 작업을 복원하는 것입니다.루프를 중지하려면 루프에 포함된 포트를 알아야 합니다.링크 사용률이 가장 높은 포트를 확인합니다(초당 패킷 수). show interface Cisco IOS software 명령은 각 인터페이스의 사용률을 표시합니다.

사용률 정보 및 인터페이스 이름(빠른 분석용)만 표시하려면 Cisco IOS 소프트웨어 정규식 출력 필터링을 사용할 수 있습니다.show interface를 실행합니다. | include line|\/sec 명령을 사용하여 초당 패킷 통계와 인터페이스 이름만 표시합니다.

cat# show interface | include line|\/sec

GigabitEthernet2/1 is up, line protocol is down
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
GigabitEthernet2/2 is up, line protocol is down
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
GigabitEthernet2/3 is up, line protocol is up
  5 minute input rate 99765230 bits/sec, 24912 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
GigabitEthernet2/4 is up, line protocol is up
  5 minute input rate 1000 bits/sec, 27 packets/sec
  5 minute output rate 101002134 bits/sec, 25043 packets/sec
GigabitEthernet2/5 is administratively down, line protocol is down
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
GigabitEthernet2/6 is administratively down, line protocol is down
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
GigabitEthernet2/7 is up, line protocol is down
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
GigabitEthernet2/8 is up, line protocol is up
  5 minute input rate 2000 bits/sec, 41 packets/sec
  5 minute output rate 99552940 bits/sec, 24892 packets/sec

링크 사용률이 가장 높은 인터페이스에 특히 주의하십시오.이 예에서는 인터페이스 g2/3, g2/4 및 g2/8입니다.루프와 관련된 포트일 수 있습니다.

루프를 해제합니다.

루프를 중단하려면 관련 포트를 종료하거나 분리해야 합니다.루프를 중지할 뿐만 아니라 루프의 근본 원인을 찾아 수정하는 것도 매우 중요합니다.루프를 끊는 것이 비교적 쉽다.

참고: 후속 원인 분석을 지원하기 위해 모든 포트를 동시에 종료하거나 분리하지 않아도 됩니다.대신 한 번에 하나씩 차단합니다.일반적으로 디스트리뷰션 또는 코어 스위치와 같이 루프의 영향을 받는 어그리게이션 포인트에서 포트를 종료하는 것이 좋습니다.모든 포트를 한 번에 종료하고 일대일로 활성화하거나 다시 연결하면 작동하지 않을 수 있습니다.루프가 중지되고 문제가 되는 포트가 다시 연결된 후 바로 시작되지 않을 수 있습니다.따라서 어떤 특정 포트와의 장애 상관관계를 분석하기가 어려울 수 있습니다.

참고: 스위치를 재부팅하기 전에 정보를 수집하는 것이 좋습니다.그렇지 않으면 후속 근본 원인 분석이 매우 어렵습니다.

각 포트를 비활성화하거나 분리한 후 스위치 백플레인 사용률이 정상 수준으로 다시 설정되었는지 확인해야 합니다.

참고: 일반적으로 일부 포트는 루프를 유지하지 않고 루프를 사용하여 도착하는 트래픽을 플러딩하고 있습니다.이러한 플러딩 포트를 종료하면 백플레인 사용률이 약간 감소하지만 루프를 중지하지 않습니다.

다음 예제 토폴로지에서 루프는 스위치 A, B, D 사이에 있으므로 링크 AB, AD 및 BD는 계속 유지됩니다.이러한 링크를 종료하면 루프가 중지됩니다.AC, AE, BC 및 BE 링크는 루프로 들어오는 트래픽에 플러딩됩니다.

유지 보수 포트가 종료되면 백플레인 사용률이 정상 값으로 중단됩니다.어떤 포트의 종료를 통해 백플레인 사용률(및 기타 포트의 사용률)이 정상 수준으로 발생했는지 확인하는 것이 매우 중요합니다.

이때 루프가 중지되고 네트워크 운영이 개선되어야 합니다.그러나 루프의 원래 원인은 아직 해결되지 않았으므로 아직 해결되지 않은 문제가 있을 수 있습니다.

루프의 원인을 찾아서 수정합니다.

루프가 중지되면 루프가 시작된 이유를 확인해야 합니다.이유는 다양하기 때문에 이 과정이 가장 어려운 부분이기도 합니다.모든 경우에 적용되는 정확한 절차를 공식화하기는 어렵다.그러나 다음은 몇 가지 일반적인 지침입니다.

토폴로지 다이어그램을 조사하여 이중 경로를 찾습니다.여기에는 동일한 스위치로 다시 돌아오는 이전 단계에서 찾은 유지형 포트가 포함됩니다(경로 패킷이 루프를 수행하는 동안 발생). 이전 예제 토폴로지에서 이 경로는 AD-DB-BA입니다.
이중화 경로의 모든 스위치에 대해 다음 문제를 확인합니다.

스위치가 올바른 STP 루트를 알고 있습니까?

L2 네트워크의 모든 스위치는 공통 STP 루트에 동의해야 합니다.이는 브리지가 특정 VLAN 또는 STP 인스턴스에서 STP 루트에 대해 서로 다른 ID를 지속적으로 표시할 때 발생하는 문제의 분명한 증상이다.지정된 VLAN의 루트 브리지 ID를 표시하려면 show spanning-tree vlan vlan-id 명령을 실행합니다.

cat# show spanning-tree vlan 333

MST03
  Spanning tree enabled protocol mstp
  Root ID    Priority    32771
             Address     0050.14bb.6000
             Cost        20000
             Port        136 (GigabitEthernet3/8)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32771  (priority 32768 sys-id-ext 3)
             Address     00d0.003f.8800
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role Sts Cost      Prio.Nbr Status
---------------- ---- --- --------- -------- ------------------------
Gi3/8            Root FWD 20000     128.136  P2p
Po1              Desg FWD 20000     128.833  P2p

루프와 관련된 포트가 이전 단계에서 설정되었기 때문에 VLAN 번호는 포트에서 찾을 수 있습니다.해당 포트가 트렁크이면 트렁크의 모든 VLAN이 관련된 경우가 많습니다.이러한 경우가 아니면(예: 단일 VLAN에서 루프가 발생한 것으로 보이는 경우) show 인터페이스를 실행해 볼 수 있습니다. | include L2|line|broadcast 명령(Supervisor 1은 VLAN별 스위칭 통계를 제공하지 않으므로 Catalyst 6500/6000 Series 스위치의 Supervisor 2 이상 엔진에만 해당) VLAN 인터페이스만 확인합니다.스위치드 패킷이 가장 많은 VLAN은 루프가 발생한 경우가 가장 많습니다.

cat# show int | include L2|line|broadcast

Vlan1 is up, line protocol is up
  L2 Switched: ucast: 653704527 pkt, 124614363025 bytes - mcast:
         23036247 pkt, 1748707536 bytes
     Received 23201637 broadcasts, 0 runts, 0 giants, 0 throttles
Vlan10 is up, line protocol is up
  L2 Switched: ucast: 2510912 pkt, 137067402 bytes - mcast:
         41608705 pkt, 1931758378 bytes
     Received 1321246 broadcasts, 0 runts, 0 giants, 0 throttles
Vlan11 is up, line protocol is up
  L2 Switched: ucast: 73125 pkt, 2242976 bytes - mcast:
         3191097 pkt, 173652249 bytes
     Received 1440503 broadcasts, 0 runts, 0 giants, 0 throttles
Vlan100 is up, line protocol is up
  L2 Switched: ucast: 458110 pkt, 21858256 bytes - mcast:
         64534391 pkt, 2977052824 bytes
     Received 1176671 broadcasts, 0 runts, 0 giants, 0 throttles
Vlan101 is up, line protocol is up
  L2 Switched: ucast: 70649 pkt, 2124024 bytes - mcast:
         2175964 pkt, 108413700 bytes
     Received 1104890 broadcasts, 0 runts, 0 giants, 0 throttles

이 예에서는 VLAN 1이 가장 많은 브로드캐스트 및 L2 스위치 트래픽을 고려합니다.

루트 포트가 올바르게 식별되었습니까?

루트 포트는 루트 브리지에 대한 비용이 가장 낮아야 합니다(낮은 속도 포트의 비용이 증가하므로 홉의 경우 경로 하나가 짧지만 비용 측면에서 더 긴 경우도 있음).

지정된 VLAN의 루트로 간주되는 포트를 확인하려면 show spanning-tree vlan vlan 명령을 실행합니다.

cat# show spanning-tree vlan 333

MST03
  Spanning tree enabled protocol mstp
  Root ID    Priority    32771
             Address     0050.14bb.6000
             Cost        20000
             Port        136 (GigabitEthernet3/8)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32771  (priority 32768 sys-id-ext 3)
             Address     00d0.003f.8800
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role Sts Cost      Prio.Nbr Status
---------------- ---- --- --------- -------- ------------------------
Gi3/8            Root FWD 20000     128.136  P2p
Po1              Desg FWD 20000     128.833  P2p

BPDU는 루트 포트 및 차단해야 하는 포트에서 정기적으로 수신됩니까?

BPDU는 hello 간격(기본적으로 2초)마다 루트 브리지에 의해 전송됩니다. 루트가 아닌 브리지는 루트에서 수신되는 BPDU를 수신, 처리, 수정 및 전파합니다.

BPDU를 수신하는지 확인하려면 show spanning-tree interface interface detail 명령을 실행합니다.

cat# show spanning-tree interface g3/2 detail

Port 130 (GigabitEthernet3/2) of MST00 is backup blocking
   Port path cost 20000, Port priority 128, Port Identifier 128.130.
   Designated root has priority 0, address 0007.4f1c.e847
   Designated bridge has priority 32768, address 00d0.003f.8800
   Designated port id is 128.129, designated path cost 2000019
   Timers: message age 4, forward delay 0, hold 0
   Number of transitions to forwarding state: 0
   Link type is point-to-point by default, Internal
   Loop guard is enabled by default on the port
   BPDU: sent 3, received 53

cat# show spanning-tree interface g3/2 detail

Port 130 (GigabitEthernet3/2) of MST00 is backup blocking
   Port path cost 20000, Port priority 128, Port Identifier 128.130.
   Designated root has priority 0, address 0007.4f1c.e847
   Designated bridge has priority 32768, address 00d0.003f.8800
   Designated port id is 128.129, designated path cost 2000019
   Timers: message age 5, forward delay 0, hold 0
   Number of transitions to forwarding state: 0
   Link type is point-to-point by default, Internal
   Loop guard is enabled by default on the port
   BPDU: sent 3, received 54

참고: 명령의 두 출력 간에 BPDU 하나가 수신되었습니다(카운터는 53에서 54로 이동).

표시된 카운터는 STP 프로세스 자체에서 유지 관리하는 카운터입니다.즉, 수신 카운터가 증가하면 물리적 포트에서 수신한 BPDU뿐만 아니라 STP 프로세스에서 수신한 BPDU도 증가합니다.

수신된 BPDU 카운터가 루트 대체 포트 또는 백업 포트로 예정된 포트에서 증가하지 않는 경우 포트에서 멀티캐스트를 수신하는지 확인합니다(BPDU는 멀티캐스트로 전송). show interface interface counters 명령을 실행합니다.

cat# show interface g3/2 counters

Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
Gi3/2           14873036             2         89387             0

Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
Gi3/2          114365997         83776        732086            19

cat# show interface g3/2 counters

Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
Gi3/2           14873677             2         89391             0

Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
Gi3/2          114366106         83776        732087            19

(STP 포트 역할에 대한 간단한 설명은 Loop Guard 및 BPDU Skew Detection Features를 사용하는 Spanning-Tree Protocol Enhancements의 Brief Summary of STP port roles 섹션에서 확인할 수 있습니다.)

수신된 BPDU가 없으면 포트가 오류를 계산하지 않는지 확인합니다.show interface counters errors 명령을 실행합니다.

cat# show interface g4/3 counters errors

Port     Align-Err    FCS-Err   Xmit-Err    Rcv-Err UnderSize OutDiscards
Gi4/3        0          0          0          0         0           0

Port  Single-Col Multi-Col  Late-Col Excess-Col Carri-Sen   Runts    Giants
Gi4/3       0         0         0          0         0        0         0

BPDU는 물리적 포트에서 수신되지만 STP 프로세스에는 연결되지 않을 수 있습니다.이전 두 예에서 사용된 명령에 일부 멀티캐스트가 수신되고 오류가 증가하지 않는 경우 BPDU가 STP 프로세스 레벨에서 삭제되고 있는지 확인합니다.Catalyst 6500에서 remote command switch test spanning-tree process-stats 명령을 실행합니다.

cat# remote command switch test spanning-tree process-stats

------------------TX STATS------------------
 transmission rate/sec     = 2
 paks transmitted          = 5011226
 paks transmitted (opt)    = 0
 opt chunk alloc failures  = 0
 max opt chunk allocated   = 0
------------------RX STATS------------------
 receive rate/sec          = 1
 paks received at stp isr  = 3947627
 paks queued at stp isr    = 3947627
 paks dropped at stp isr   = 0
 drop rate/sec             = 0
 paks dequeued at stp proc = 3947627
 paks waiting in queue     = 0
 queue depth               = 7(max) 12288(total)
--------------PROCESSING STATS---------------
 queue wait time (in ms)   = 0(avg) 540(max)
 processing time (in ms)   = 0(avg) 4(max)
 proc switch count         = 100
 add vlan ports            = 20
 time since last clearing  = 2087269 sec

이 예에서 사용되는 명령은 STP 프로세스 통계를 표시합니다.드롭 카운터가 증가하지 않고 수신된 패킷이 증가하는지 확인하는 것이 중요합니다.

수신된 패킷이 증가하지 않지만 물리적 포트가 멀티캐스트를 수신하는 경우, 스위치 대역 내 인터페이스(CPU의 인터페이스)에서 패킷을 수신하는지 확인합니다. 원격 명령 스위치 show ibc를 실행합니다. Catalyst 6500/6000에서 | i rx_input 명령:

cat# remote command switch show ibc | i rx_input

rx_inputs=5626468, rx_cumbytes=859971138

cat# remote command switch show ibc | i rx_input

rx_inputs=5626471, rx_cumbytes=859971539

이 예에서는 출력 간에 대역 내 포트가 23개의 패킷을 수신했음을 보여줍니다.

참고: 이러한 23개의 패킷은 BPDU 패킷만이 아닙니다.대역 내 포트에서 수신한 모든 패킷에 대한 전역 카운터입니다.

BPDU가 로컬 스위치 또는 포트에서 삭제되고 있다는 표시가 없는 경우 링크 반대쪽의 스위치로 이동하여 해당 스위치가 BPDU를 전송하는지 확인해야 합니다.

BPDU는 루트가 아닌 지정된 포트에서 정기적으로 전송됩니까?

포트 역할에 따라 포트가 BPDU를 전송하지만 네이버가 수신하지 않는 경우 BPDU가 실제로 전송되고 있는지 확인합니다.show spanning-tree interface interface interface detail 명령을 실행합니다.

cat# show spanning-tree interface g3/1 detail

Port 129 (GigabitEthernet3/1) of MST00 is designated forwarding
   Port path cost 20000, Port priority 128, Port Identifier 128.129.
   Designated root has priority 0, address 0007.4f1c.e847
   Designated bridge has priority 32768, address 00d0.003f.8800
   Designated port id is 128.129, designated path cost 2000019
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 0
   Link type is point-to-point by default, Internal
   Loop guard is enabled by default on the port
   BPDU: sent 1774, received 1

cat# show spanning-tree interface g3/1 detail

Port 129 (GigabitEthernet3/1) of MST00 is designated forwarding
   Port path cost 20000, Port priority 128, Port Identifier 128.129.
   Designated root has priority 0, address 0007.4f1c.e847
   Designated bridge has priority 32768, address 00d0.003f.8800
   Designated port id is 128.129, designated path cost 2000019
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 0
   Link type is point-to-point by default, Internal
   Loop guard is enabled by default on the port
   BPDU: sent 1776, received 1

이 예에서는 출력 간에 2개의 BPDU가 전송되었습니다.

참고: STP 프로세스는 BPDU를 유지 관리합니다.보낸 카운터입니다.즉, 카운터는 BPDU가 물리적 포트로 전송되어 결국 전송되었음을 나타냅니다.포트 카운터가 전송된 멀티캐스트 패킷에 대해 증가하고 있는지 확인합니다.show interface interface counters 명령을 실행합니다.이를 통해 BPDU가 외부로 나가는지 여부를 확인할 수 있습니다.

cat# show interface g3/1 counters

Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
Gi3/1          127985312         83776        812319            19

Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
Gi3/1          131825915          3442        872342           386

cat# show interface g3/1 counters

Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
Gi3/1          127985312         83776        812319            19

Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
Gi3/1          131826447          3442        872346           386

이러한 모든 단계를 통해 BPDU가 수신, 전송 또는 처리되지 않는 스위치나 링크를 찾는 것이 좋습니다.

그러나 STP가 포트에 대한 올바른 상태를 계산했을 가능성은 낮지만 컨트롤 플레인 문제로 인해 포워딩 하드웨어에서 이 상태를 설정할 수 없었습니다.하드웨어 레벨에서 의심되는 차단 포트가 차단되지 않은 경우 루프를 생성할 수 있습니다.네트워크에서 이러한 문제가 의심되는 경우 Cisco 기술 지원에 추가 지원을 요청하십시오.

이중화를 복원합니다.

루프를 일으키는 디바이스 또는 링크가 발견되면 이 디바이스가 네트워크에서 격리되거나 파이버 또는 GBIC 교체와 같은 문제 해결을 위한 조치를 취해야 합니다. 3단계에서 연결이 끊긴 중복 링크를 복원해야 합니다.

루프를 일으키는 많은 조건이 매우 일시적이고, 간헐적이며 불안정할 수 있기 때문에 루프를 발생시키는 장치나 링크에 대해 가능한 최소한의 조작만 하는 것이 중요합니다.즉, 문제 해결 중에 또는 문제 해결 후에 조건이 지워지면 해당 조건이 다시 발생하기 전에 시간이 걸릴 수 있습니다.상태가 다시 발생하지 않을 수도 있습니다.Cisco Technical Support에서 더 자세히 조사할 수 있도록 모든 노력을 기울여야 합니다.스위치를 재설정하기 전에 조건에 대한 정보를 수집하는 것이 중요합니다.상태가 사라지면 루프의 근본 원인을 확인하는 것이 종종 불가능합니다.루프를 트리거하는 디바이스 또는 링크를 찾으려면 중요한 성과이지만, 동일한 유형의 또 다른 장애 시 루프가 다시 발생하지 않도록 해야 합니다.자세한 내용은 이 문서의 Securing the Network Against Forwarding Loops 섹션을 참조하십시오.

과도한 토폴로지 변경으로 인한 플러딩 문제 해결

TC 메커니즘의 역할은 전달 토폴로지가 변경된 후 L2 포워딩 테이블을 수정하는 것입니다.TC가 완료되면 특정 포트를 통해 이전에 액세스할 수 있었던 일부 MAC 주소에 다른 포트를 통해 액세스할 수 있기 때문에 연결 중단을 방지하기 위해 이 작업이 필요합니다.TC는 TC가 발생하는 VLAN의 모든 스위치에서 포워딩 테이블 에이징 시간을 단축합니다.따라서 주소를 재학습하지 않으면, 수신 MAC 주소에 패킷이 도달하도록 에이징 아웃 및 플러딩이 발생합니다.

TC는 포트의 STP 상태를 STP 전달 상태로 또는 STP 전달 상태로 변경함으로써 트리거됩니다.TC가 끝나면 특정 대상 MAC 주소가 오래되었더라도 플러딩이 오래 지속되어서는 안 됩니다.주소는 MAC 주소가 만료된 호스트에서 오는 첫 번째 패킷에 의해 다시 학습됩니다.TC가 반복적으로 발생할 때 짧은 간격으로 문제가 발생할 수 있습니다.이 스위치는 지속적으로 포워딩 테이블을 빠르게 에이징하므로 플러딩이 거의 일정하게 지속됩니다.

참고: Rapid STP 또는 Multiple STP(IEEE 802.1w 및 IEEE 802.1s)를 사용하면 TC는 포트 상태를 포워딩으로 변경하고 지정된 역할에서 루트로 역할 변경을 통해 트리거됩니다.Rapid STP를 사용하면 L2 포워딩 테이블이 802.1d와 달리 즉시 플러시되어 에이징 시간이 단축됩니다.포워딩 테이블을 즉시 플러싱하면 연결이 더 빠르게 복원되지만 플러딩이 더 많이 발생할 수 있습니다.

TC는 잘 구성된 네트워크에서 드문 이벤트여야 합니다.스위치 포트의 링크가 작동 또는 중단될 경우, 포트의 STP 상태가 전달으로 변경되고 나면 TC가 발생합니다.포트가 플래핑되면 반복적인 TC와 플러딩이 발생합니다.

STP portfast 기능이 활성화된 포트는 전달 상태로 이동할 때 TC를 유발하지 않습니다.프린터, PC 및 서버와 같은 모든 엔드 디바이스 포트에서 포트 컨피그레이션을 수행하면 TC가 낮은 수준으로 제한되어야 하며 적극 권장합니다.TC에 대한 자세한 내용은 스패닝 트리 프로토콜 토폴로지 변경 이해를 참조하십시오.

네트워크에 반복 TC가 있는 경우 이러한 TC의 소스를 식별하고 이를 줄이기 위한 조치를 취하여 플러딩을 최소한으로 설정해야 합니다.

802.1d에서는 TC 이벤트에 대한 STP 정보가 특수한 유형의 BPDU인 TCN(TC Notification)을 통해 브리지에 전파됩니다.TCN BPDU를 수신하는 포트를 따를 경우 TC를 시작하는 디바이스를 찾을 수 있습니다.

플러딩이 STP TC에 의해 발생하는지 확인

일반적으로 느린 성능으로 인한 플러딩, 혼잡하지 않은 링크의 패킷 삭제, 로컬 세그먼트에 없는 동일한 대상에 여러 유니캐스트 패킷을 표시하는 패킷 분석기를 확인할 수 있습니다.

유니캐스트 플러딩에 대한 자세한 내용은 스위치드 캠퍼스 네트워크의 유니캐스트 플러딩을 참조하십시오.

Cisco IOS 소프트웨어를 실행하는 Catalyst 6500/6000에서 포워딩 엔진 카운터(Supervisor 2 엔진에만 해당)를 확인하여 플러딩의 양을 예측할 수 있습니다.remote 명령 스위치 show earle statistics를 실행합니다. | i MISS_DA|ST_FR 명령:

cat# remote command switch show earl statistics | i MISS_DA|ST_FR

         ST_MISS_DA     =       18                      530308834
         ST_FRMS        =       97                      969084354

cat# remote command switch show earl statistics | i MISS_DA|ST_FR

         ST_MISS_DA     =       4                       530308838
         ST_FRMS        =       23                      969084377

이 예에서 첫 번째 열은 이 명령을 마지막으로 실행한 이후의 변경 사항을 표시하고 두 번째 열은 마지막 재부팅 이후의 누적 값을 표시합니다.첫 번째 줄에는 플러딩된 프레임의 양이 표시되고 두 번째 줄에는 처리된 프레임의 양이 표시됩니다.두 값이 함께 근접하거나 첫 번째 값이 높은 속도로 증가하면 스위치가 트래픽을 플러딩하고 있는 것일 수 있습니다.그러나 카운터가 세분화되지 않으므로 플러딩을 확인하는 다른 방법과만 함께 사용할 수 있습니다.포트나 VLAN이 아닌 스위치당 카운터가 하나씩 있습니다.목적지 MAC 주소가 포워딩 테이블에 없는 경우 스위치가 항상 플러딩되므로 일부 플러딩 패킷을 보는 것은 정상입니다.이는 스위치가 아직 학습되지 않은 목적지 주소의 패킷을 수신하는 경우입니다.

TC의 소스 추적

과도한 플러딩이 발생하는 VLAN에 대해 VLAN 번호가 알려진 경우 STP 카운터를 확인하여 TC의 수가 높거나 정기적으로 증가하는지 확인합니다.show spanning-tree vlan id detail 명령을 실행합니다(이 예에서는 VLAN 1이 사용됨).

cat# show spanning-tree vlan 1 detail

VLAN0001 is executing the ieee compatible Spanning Tree protocol
  Bridge Identifier has priority 32768, sysid 1, address 0007.0e8f.04c0
  Configured hello time 2, max age 20, forward delay 15
  Current root has priority 0, address 0007.4f1c.e847
  Root port is 65 (GigabitEthernet2/1), cost of root path is 119
  Topology change flag not set, detected flag not set
  Number of topology changes 1 last change occurred 00:00:35 ago
          from GigabitEthernet1/1
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0, aging 300

VLAN 번호를 모르는 경우 패킷 분석기를 사용하거나 모든 VLAN에 대한 TC 카운터를 확인할 수 있습니다.

과도한 TC를 방지하기 위한 조치 수행

토폴로지 변경 카운터 수를 모니터링하여 정기적으로 증가하고 있는지 확인할 수 있습니다.그런 다음 표시된 포트에 연결된 브리지로 이동하여 마지막 TC(이전 예시 포트 GigabitEthernet1/1)를 수신하고 해당 브리지에 대해 TC가 제공된 위치를 확인합니다.STP portfast가 활성화되지 않은 엔드 스테이션 포트를 찾거나 플랩 링크가 발견될 때까지 이 프로세스를 반복해야 합니다.TC가 여전히 다른 소스에서 오는 경우 전체 절차를 반복해야 합니다.링크가 최종 호스트에 속하는 경우 TC를 생성하지 않도록 포트 빠른 기능을 구성해야 합니다.

참고: Cisco IOS 소프트웨어 STP 구현에서는 VLAN의 포트에서 TCN BPDU를 수신한 경우에만 TC에 대한 카운터가 증가합니다.설정된 TC 플래그가 있는 일반 컨피그레이션 BPDU를 수신하면 TC 카운터가 증가하지 않습니다.즉, TC가 플러딩의 원인으로 의심될 경우 해당 VLAN의 STP 루트 브리지에서 TC의 소스를 추적하는 것이 가장 좋습니다.TC의 양 및 출처에 대한 가장 정확한 정보를 제공합니다.

통합 시간 관련 문제 해결

STP의 실제 작업이 예상 동작과 일치하지 않는 경우가 있습니다.가장 자주 발생하는 두 가지 문제는 다음과 같습니다.

STP 컨버전스 또는 재컨버전스가 예상보다 오래 걸립니다.
결과 토폴로지가 예상과 다릅니다.

대부분의 경우 이러한 동작이 발생하는 이유는 다음과 같습니다.

실제 토폴로지와 문서화된 토폴로지가 일치하지 않습니다.
STP 타이머의 일관성 없는 컨피그레이션, STP 지름 초과 또는 포트 빠른 컨피그레이션 오류 등의 잘못된 컨피그레이션
컨버전스 또는 재컨버전스 중 오버로드된 스위치 CPU
소프트웨어 결함

앞에서 언급한 것처럼, 이 문서는 STP에 영향을 줄 수 있는 다양한 문제로 인해 트러블슈팅을 위한 일반적인 지침만 제공할 수 있습니다.

컨버전스가 예상보다 오래 걸리는 이유를 이해하려면 STP 이벤트의 순서를 검토하여 무엇이 발생하고 어떤 순서로 이루어졌는지 확인합니다.Cisco IOS 소프트웨어의 STP 구현에는 특수한 로깅(포트 불일치와 같은 특정 이벤트 제외)이 없으므로 Cisco IOS 소프트웨어 STP 디버깅 기능을 사용하여 현재 상황을 파악할 수 있습니다.

STP의 경우 Cisco IOS 소프트웨어를 실행하는 Catalyst 6500/6000이 있으면 SP(Switch Processor)(또는 Supervisor)에서 프로세스가 수행되므로 SP에서 디버그를 활성화해야 합니다.Cisco IOS 소프트웨어 브리지 그룹의 경우 RP(Route Processor)에서 처리가 수행되므로 MSFC(RP)에서 디버그를 활성화해야 합니다.

STP 디버깅 명령

많은 STP debug 명령은 개발 엔지니어링 용도로 사용됩니다.Cisco IOS 소프트웨어의 STP 구현에 대한 자세한 지식 없이는 다른 사람에게 의미 있는 출력을 제공하지 않습니다.일부 디버그는 포트 상태 변경, 역할 변경, TC와 같은 이벤트, 수신 및 전송된 BPDU의 덤프 등 즉시 읽을 수 있는 출력을 제공할 수 있습니다.이 섹션에서는 모든 디버그에 대한 전체 설명을 제공하지 않고 가장 자주 사용되는 디버그를 간략하게 소개합니다.

참고: debug 명령을 사용할 때 필요한 최소 디버그를 활성화합니다.실시간 디버그가 필요하지 않으면 출력을 콘솔에 인쇄하지 않고 로그에 기록합니다.과도한 디버그는 CPU를 오버로드하고 스위치 작업을 중단할 수 있습니다.디버그 출력을 콘솔 또는 텔넷 세션 대신 로그에 전달하려면 logging console 정보를 실행하고 전역 컨피그레이션 모드에서 no logging monitor 명령을 실행합니다.

일반 이벤트 로그를 보려면 PVST(Per VLAN Spanning-Tree) 및 Rapid-PVST에 대해 debug spanning-tree event 명령을 실행합니다.이는 STP의 현재 상황에 대한 일반적인 정보를 제공하는 첫 번째 디버그입니다.

MST(Multiple Spanning-Tree) 모드에서는 debug spanning-tree event 명령을 실행하지 않습니다.따라서 debug spanning-tree mstp roles 명령을 실행하여 포트 역할 변경 사항을 확인합니다.

포트 STP 상태 변경 사항을 보려면 debug spanning-tree switch state 명령을 debug pm vp 명령과 함께 실행합니다.

cat-sp# debug spanning-tree switch state

Spanning Tree Port state changes debugging is on

cat-sp# debug pm vp

Virtual port events debugging is on
Nov 19 14:03:37: SP:     pm_vp 3/1(333): during state forwarding, got event 4(remove)
Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333):
  forwarding -> notforwarding

port 3/1 (was forwarding) goes down in vlan 333

Nov 19 14:03:37: SP: *** vp_fwdchange: single: notfwd: 3/1(333)
Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333): notforwarding -> present
Nov 19 14:03:37: SP: *** vp_linkchange: single: down: 3/1(333)
Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333): present -> not_present
Nov 19 14:03:37: SP: *** vp_statechange: single: remove: 3/1(333)
Nov 19 14:03:37: SP:     pm_vp 3/2(333): during state notforwarding,
  got event 4(remove)
Nov 19 14:03:37: SP: @@@ pm_vp 3/2(333): notforwarding -> present
Nov 19 14:03:37: SP: *** vp_linkchange: single: down: 3/2(333)

Port 3/2 (was not forwarding) in vlan 333 goes down

Nov 19 14:03:37: SP: @@@ pm_vp 3/2(333): present -> not_present
Nov 19 14:03:37: SP: *** vp_statechange: single: remove: 3/2(333)

Nov 19 14:03:53: SP:     pm_vp 3/1(333): during state not_present,
  got event 0(add)
Nov 19 14:03:53: SP: @@@ pm_vp 3/1(333): not_present -> present
Nov 19 14:03:53: SP: *** vp_statechange: single: added: 3/1(333)
Nov 19 14:03:53: SP:     pm_vp 3/1(333): during state present,
  got event 8(linkup)
Nov 19 14:03:53: SP: @@@ pm_vp 3/1(333): present ->
  notforwarding
Nov 19 14:03:53: SP: STP SW: Gi3/1 new blocking req for 0 vlans
Nov 19 14:03:53: SP: *** vp_linkchange: single: up: 3/1(333)

Port 3/1 link goes up and blocking in vlan 333

Nov 19 14:03:53: SP:     pm_vp 3/2(333): during state not_present,
  got event 0(add)
Nov 19 14:03:53: SP: @@@ pm_vp 3/2(333): not_present -> present
Nov 19 14:03:53: SP: *** vp_statechange: single: added: 3/2(333)
Nov 19 14:03:53: SP:     pm_vp 3/2(333): during state present,
  got event 8(linkup)
Nov 19 14:03:53: SP: @@@ pm_vp 3/2(333): present ->
  notforwarding
Nov 19 14:03:53: SP: STP SW: Gi3/2 new blocking req for 0 vlans
Nov 19 14:03:53: SP: *** vp_linkchange: single: up: 3/2(333)

Port 3/2 goes up and blocking in vlan 333

Nov 19 14:04:08: SP: STP SW: Gi3/1 new learning req for 1 vlans
Nov 19 14:04:23: SP: STP SW: Gi3/1 new forwarding req for 0 vlans
Nov 19 14:04:23: SP: STP SW: Gi3/1 new forwarding req for 1 vlans
Nov 19 14:04:23: SP:     pm_vp 3/1(333): during state notforwarding,
  got event 14(forward_notnotify)
Nov 19 14:04:23: SP: @@@ pm_vp 3/1(333): notforwarding ->
  forwarding
Nov 19 14:04:23: SP: *** vp_list_fwdchange: forward: 3/1(333)

Port 3/1 goes via learning to forwarding in vlan 333

STP가 특정 방식으로 동작하는 이유를 이해하려면 스위치에서 수신하여 전송하는 BPDU를 확인하는 것이 유용합니다.

cat-sp# debug spanning-tree bpdu receive

Spanning Tree BPDU Received debugging is on
Nov  6 11:44:27: SP: STP: VLAN1 rx BPDU: config protocol = ieee,
  packet from GigabitEthernet2/1  , linktype IEEE_SPANNING ,
  enctype 2, encsize 17
Nov  6 11:44:27: SP: STP: enc 01 80 C2 00 00 00 00 06 52 5F 0E 50 00 26 42 42 03
Nov  6 11:44:27: SP: STP: Data 0000000000000000074F1CE8470000001380480006525F0E4
  080100100140002000F00
Nov  6 11:44:27: SP: STP: VLAN1 Gi2/1:0000 00 00 00 000000074F1CE847 00000013
  80480006525F0E40 8010 0100 1400 0200 0F00

이 디버그는 PVST, Rapid-PVST 및 MST 모드에 대해 작동합니다.그러나 BPDU의 내용은 디코딩하지 않습니다.그러나 BPDU가 수신되었는지 확인하는 데 사용할 수 있습니다.

BPDU의 내용을 보려면 PVST 및 Rapid-PVST용 debug spanning-tree switch rx process 명령과 함께 debug spanning-tree switch rx decode 명령을 실행합니다.MST용 BPDU의 내용을 보려면 debug spanning-tree mstp bpdu-rx 명령을 실행합니다.

cat-sp# debug spanning-tree switch rx decode

Spanning Tree Switch Shim decode received packets debugging is on

cat-sp# debug spanning-tree switch rx process

Spanning Tree Switch Shim process receive bpdu debugging is on

Nov  6 12:23:20: SP: STP SW: PROC RX: 0180.c200.0000<-0006.525f.0e50 type/len 0026
Nov  6 12:23:20: SP:     encap SAP linktype ieee-st vlan 1 len 52 on v1 Gi2/1
Nov  6 12:23:20: SP:     42 42 03 SPAN
Nov  6 12:23:20: SP:     CFG P:0000 V:00 T:00 F:00 R:0000 0007.4f1c.e847 00000013
Nov  6 12:23:20: SP:     B:8048 0006.525f.0e40 80.10 A:0100 M:1400 H:0200 F:0F00

Nov  6 12:23:22: SP: STP SW: PROC RX: 0180.c200.0000<-0006.525f.0e50 type/len 0026
Nov  6 12:23:22: SP:     encap SAP linktype ieee-st vlan 1 len 52 on v1 Gi2/1
Nov  6 12:23:22: SP:     42 42 03 SPAN
Nov  6 12:23:22: SP:     CFG P:0000 V:00 T:00 F:00 R:0000 0007.4f1c.e847 00000013
Nov  6 12:23:22: SP:     B:8048 0006.525f.0e40 80.10 A:0100 M:1400 H:0200 F:0F00

MST 모드의 경우 다음 debug 명령을 사용하여 자세한 BPDU 디코딩을 활성화할 수 있습니다.

cat-sp# debug spanning-tree mstp bpdu-rx

Multiple Spanning Tree Received BPDUs debugging is on
Nov 19 14:37:43: SP: MST:BPDU DUMP [rcvd_bpdu Gi3/2 Repeated]
Nov 19 14:37:43: SP: MST:   Proto:0 Version:3 Type:2 Role: DesgFlags[   F    ]
Nov 19 14:37:43: SP: MST:   Port_id:32897 cost:2000019
Nov 19 14:37:43: SP: MST:   root_id  :0007.4f1c.e847 Prio:0
Nov 19 14:37:43: SP: MST:   br_id    :00d0.003f.8800 Prio:32768
Nov 19 14:37:43: SP: MST:   age:2 max_age:20 hello:2 fwdelay:15
Nov 19 14:37:43: SP: MST:   V3_len:90 PathCost:30000 region:STATIC rev:1
Nov 19 14:37:43: SP: MST:   ist_m_id :0005.74
Nov 19 14:37:43: SP: MST:BPDU DUMP [rcvd_bpdu Gi3/2 Repeated]
Nov 19 14:37:43: SP: MST:   Proto:0 Version:3 Type:2 Role: DesgFlags[   F    ]
Nov 19 14:37:43: SP: MST:   Port_id:32897 cost:2000019
Nov 19 14:37:43: SP: MST:   root_id  :0007.4f1c.e847 Prio:0
Nov 19 14:37:43: SP: MST:   br_id    :00d0.003f.8800 Prio:32768
Nov 19 14:37:43: SP: MST:   age:2 max_age:20 hello:2 fwdelay:15
Nov 19 14:37:43: SP: MST:   V3_len:90 PathCost:30000 region:STATIC rev:1
Nov 19 14:37:43: SP: MST:   ist_m_id :0005.7428.1440 Prio:32768  Hops:18
  Num Mrec: 1
Nov 19 14:37:43: SP: MST: stci=3  Flags[ F    ] Hop:19 Role:Desg [Repeated]
Nov 19 14:37:43: SP: MST:         br_id:00d0.003f.8800 Prio:32771 Port_id:32897
  Cost:2000028.1440 Prio:32768  Hops:18  Num Mrec: 1
Nov 19 14:37:43: SP: MST: stci=3  Flags[ F    ] Hop:19 Role:Desg [Repeated]
Nov 19 14:37:43: SP: MST:         br_id:00d0.003f.8800 Prio:32771 Port_id:32897
  Cost:20000

참고: Cisco IOS Software 릴리스 12.1.13E 이상에서는 STP에 대한 조건부 디버그가 지원됩니다.즉 포트별 또는 VLAN별로 수신 또는 전송된 BPDU를 디버깅할 수 있습니다.

디버그 조건 vlan vlan_num 또는 debug 조건 인터페이스 인터페이스 명령을 실행하여 디버그 출력 범위를 인터페이스별 또는 VLAN별로 제한합니다.

포워딩 루프로부터 네트워크 보호

Cisco는 STP가 특정 장애를 올바르게 처리할 수 없는 상황을 해결하기 위해 포워딩 루프로부터 네트워크를 보호할 수 있는 다양한 기능과 향상된 기능을 개발했습니다.

STP의 문제 해결은 특정 장애의 원인을 찾아내고 찾아내는 데 도움이 되지만, 이러한 개선 사항의 구현은 네트워크를 포워딩 루프로부터 보호하는 유일한 방법입니다.

포워딩 루프로부터 네트워크를 보호하는 방법은 다음과 같습니다.

모든 스위치 간 링크에서 UDLD(Unidirectional Link Detection)를 활성화합니다.UDLD에 대한 자세한 내용은 Unidirectional Link Detection Protocol 기능 이해 및 구성을 참조하십시오.
모든 스위치에서 Loop Guard를 활성화합니다.Loop Guard에 대한 자세한 내용은 Loop Guard 및 BPDU Skew Detection 기능을 사용한 Spanning-Tree Protocol Enhancements를 참조하십시오.

UDLD 및 Loop Guard를 활성화하면 포워딩 루프의 가능한 원인 중 대부분을 제거합니다.포워딩 루프를 생성하지 않고 문제의 링크(또는 결함이 있는 하드웨어에 종속된 모든 링크)가 종료되거나 차단됩니다.

참고: 이 두 기능은 다소 이중화되어 보이지만 각각 고유한 기능을 갖습니다.따라서 두 기능을 동시에 사용하여 최고 수준의 보호를 제공합니다.UDLD 및 루프 가드를 자세히 비교하려면 루프 가드와 단방향 링크 탐지를 참조하십시오.

공격적이든 정상적인 UDLD를 사용해야 하는지에 대한 다른 의견이 있다.적극적인 UDLD는 일반 모드 UDLD에 비해 루프를 더 많이 보호하지 않습니다.적극적인 UDLD는 포트 고정 시나리오를 탐지합니다(링크가 작동하지만 연결된 트래픽 블랙홀은 없는 경우). 이와 같이 추가된 기능의 단점은 일관된 장애가 없을 경우 적극적인 UDLD가 링크를 비활성화할 수 있다는 것입니다.종종 사람들은 UDLD hello 간격의 수정을 적극적인 UDLD 기능과 혼동합니다.잘못된 것입니다.타이머는 두 UDLD 모드 모두에서 수정할 수 있습니다.

참고: 드문 경우이지만 적극적인 UDLD는 모든 업링크 포트를 종료할 수 있으며, 이는 기본적으로 네트워크의 나머지 부분으로부터 스위치를 격리합니다.예를 들어, 두 업스트림 스위치에서 모두 CPU 사용률이 매우 높고 적극적인 모드 UDLD를 사용하는 경우 이 문제가 발생할 수 있습니다.따라서 스위치에 대역 외 관리가 없는 경우 errordisable-timeouts를 구성하는 것이 좋습니다.
모든 엔드 스테이션 포트에서 포트 속도를 활성화합니다.

네트워크의 성능에 영향을 줄 수 있는 TC의 양과 후속 플러딩의 양을 제한하려면 portfast를 활성화해야 합니다.엔드 스테이션에 연결하는 포트에서만 이 명령을 사용합니다.그렇지 않으면 실수로 토폴로지 루프가 데이터 패킷 루프를 유발하여 스위치 및 네트워크 작동을 방해할 수 있습니다.

주의: no spanning-tree portfast 명령을 사용할 때는 주의해야 합니다.이 명령은 포트별 portfast 명령만 제거합니다.이 명령은 전역 컨피그레이션 모드에서 spanning-tree portfast default 명령을 정의하고 포트가 트렁크 포트가 아닌 경우 portfast를 암시적으로 활성화합니다.portfast를 전역으로 구성하지 않으면 no spanning-tree portfast 명령은 spanning-tree portfast disable 명령과 동일합니다.
EtherChannel을 양쪽의 권장 모드(지원되는 경우) 및 무음 옵션으로 설정합니다.

권장 모드는 PAgP(Port Aggregation Protocol)를 활성화하여 채널링 피어 간의 런타임 일관성을 보장합니다.따라서 루프를 추가로 보호할 수 있습니다. 특히 채널 재구성(예: 링크가 채널에 연결되거나 나가는 경우, 링크 장애 감지) 동안 루프를 추가로 보호할 수 있습니다. 기본 제공되는 Channel Misconfiguration Guard는 기본적으로 활성화되어 있으며 채널 오구성 또는 기타 조건 때문에 포워딩 루프를 방지합니다.이 기능에 대한 자세한 내용은 EtherChannel 불일치 탐지 이해를 참조하십시오.
스위치 간 링크에서 자동 협상(지원되는 경우)을 비활성화하지 마십시오.

자동 협상 메커니즘은 원격 장애 정보를 전달할 수 있으며, 원격 측에서 장애를 탐지하는 가장 빠른 방법입니다.원격지에서 장애가 감지되면 링크가 계속 펄스를 수신하더라도 로컬 측에서 링크를 중단합니다.UDLD와 같은 상위 수준의 탐지 메커니즘과 비교했을 때 자동 협상은 매우 빠른(마이크로초) 반면 UDLD의 엔드 투 엔드 커버리지(예: 전체 데이터 경로)는 없습니다.CPU — 포워딩 로직—port1—port2—포워딩 로직—CPU 대 port1—port2). 적극적인 UDLD 모드는 장애 탐지와 관련하여 자동 협상 기능과 유사한 기능을 제공합니다.링크의 양쪽에서 협상이 지원되면 적극적인 모드 UDLD를 활성화할 필요가 없습니다.
STP 타이머를 조정할 때는 주의해야 합니다.

STP 타이머는 상호 및 네트워크 토폴로지에 따라 달라집니다.타이머에 대한 임의 수정에서 STP가 제대로 작동하지 않을 수 있습니다.STP 타이머에 대한 자세한 내용은 스패닝 트리 프로토콜 타이머 이해 및 조정을 참조하십시오.
서비스 거부 공격이 가능한 경우 Root Guard를 사용하여 네트워크 STP 경계를 보호하십시오.

Root Guard 및 BPDU Guard를 사용하면 외부의 영향으로부터 STP를 보호할 수 있습니다.이러한 공격이 발생할 가능성이 있는 경우 네트워크를 보호하기 위해 Root Guard 및 BPDU Guard를 사용해야 합니다.Root Guard 및 BPDU Guard에 대한 자세한 내용은 다음 문서를 참조하십시오.
- 스패닝 트리 프로토콜 루트 가드 향상
- 스패닝 트리 Portfast BPDU 가드 개선
포트 고속 지원 포트에서 BPDU Guard를 활성화하여 포트에 연결된 무단 네트워크 디바이스(예: 허브, 스위치, 브리징 라우터)의 영향을 받지 않도록 합니다.

Root Guard가 올바르게 구성된 경우 이미 STP가 외부에서 영향을 받는 것을 방지합니다.BPDU Guard가 활성화된 경우, BPDU를 수신하는 포트가 종료됩니다(상위 BPDU뿐만 아니라). BPDU Guard는 syslog 메시지를 생성하고 포트를 종료하므로 이러한 사고를 조사해야 하는 경우 이 방법이 유용할 수 있습니다.포트 고속 지원 포트 2개가 직접 또는 허브를 통해 연결되어 있는 경우, 루트나 BPDU Guard가 단거리 루프를 차단하지 않는다는 점에 유의해야 합니다.
관리 VLAN에서 사용자 트래픽을 방지합니다.관리 VLAN은 전체 네트워크가 아니라 빌딩 블록에 포함되어 있습니다.

스위치 관리 인터페이스는 관리 VLAN에서 브로드캐스트 패킷을 수신합니다.브로드캐스트 스톰이나 잘못된 애플리케이션과 같은 과도한 브로드캐스트가 발생할 경우 스위치 CPU가 오버로드되어 STP 작업이 왜곡될 수 있습니다.
예측 가능한(하드코딩된) STP 루트 및 백업 STP 루트 배치.

STP 루트 및 백업 STP 루트가 구성되어야 컨버전스가 장애 발생 시 예측 가능한 방식으로 발생하며 모든 시나리오에서 최적의 토폴로지를 구축할 수 있습니다.예측할 수 없는 루트 스위치 선택을 방지하려면 STP 우선순위를 기본값으로 두지 마십시오.