브리징 (이더넷) 루프를 진단하려면 어떻게해야합니까?


43

스패닝 트리가 실패했거나 스패닝 트리가없는 경우 이더넷 루프가 발생하면 문제의 위치를 ​​진단하는 가장 좋은 방법은 무엇입니까?

어느 스위치? 어떤 케이블? 등등.


어떤 대답이 도움이 되었습니까? 그렇다면 질문에 대한 답변이 계속 나오지 않도록 답변을 수락해야합니다. 또는 자신의 답변을 제공하고 수락 할 수 있습니다.
— Ron Maupin

답변:


31

좋아, 다음과 같은 토폴로지가 있다고 가정하십시오.

          SW1
         /   \
        /     \
       /       \
PC A--SW2-----SW3--PC B

어떤 이유로 브리징 루프가 있거나 STP가 비활성화되었거나 누군가가 잘못된 장소 등에 필터를 적용했습니다.

PC A는 PC B와 통신을 원합니다. PC B의 MAC에 대한 첫 번째 ARP 인 대상은 MAC ffff.ffff.ffff로 브로드 캐스트됩니다. 따라서 프레임은 SW1과 SW3으로갑니다. SRC MAC은 PC A입니다. SW1은 프레임을 SW3쪽으로 플러딩하고 SW3은 SW2에서 SW1로 오는 프레임을 플러딩합니다.

SW1과 SW3은 첫 번째 프레임이 들어 왔을 때 PC A의 MAC을 배웠습니다. 두 번째 프레임이 반대 방향에서 들어 오면 다시 학습해야합니다. 이러한 이벤트는 매우 빠르고 반복적으로 발생하므로 MAC 플 래핑에 대해 불평하는 로그 메시지가 표시됩니다. "MAC FLAP 0000.0000.0001은 Gi0 / 24와 Gi0 / 23 사이에서 퍼지고 있습니다"와 같은 것입니다. 이것은 루프가 있다는 좋은 신호입니다.

그러면 할 수있는 것은이 MAC을 추적하는 것입니다. 동일한 서브넷에있는 장치의 ARP 캐시를보고이 장치의 IP를 확인하십시오. 따라서 MAC을 사용하면 sh mac-address-table 또는 IP로 추적 할 수 있습니다. 어쩌면 모든 IP 목록과 연결 위치가있을 수 있습니다.

호스트가 DHCP 서버에서 IP 주소를 얻는 경우 호스트가 어디에서 왔는지 확인할 수도 있습니다. 옵션 82를 사용하면 큰 도움이됩니다.

다른 신호는 CLI가 매우 느리다는 것입니다. CPU로드가 매우 높습니다. 스위치는 ASIC에서 거의 모든 작업을 수행하므로 스위치의 CPU로드가 50 %를 초과하면 좋지 않을 수 있습니다. SNMP 모니터링을 구현하고 높은 CPU로드를 감시해야합니다. 또한 MAC 플랩 메시지를 찾으십시오. 스위치에 루프가 있으면 LED가 미친 것처럼 깜박일 것입니다.

루프로부터 보호하기 위해 할 수있는 일 :

  • STP를 활성화하십시오! (두)
  • CPU로드의 SNMP 모니터링
  • STP 토폴로지 변경과 같은 특정 이벤트에 대해 SNMP 트랩 사용
  • 포트에서 스톰 제어를 활성화하여 브로드 캐스트를 제한합니다
  • L2 토폴로지에서 VLAN을 너무 많이 사용하지 마십시오
  • 포트 보안 활성화 및 포트 당 MAC 주소 수 제한
  • DHCP를 실행하는 경우 Option82를 활성화하십시오

CPU로드 항목이 약간 놀랍습니다. 브리징 루프 중에는 이것을 보지 못했습니다. 프로브 커브 장비에 관한 모든 경험이 있지만. 그들에게 CLI는 결코 느리지 않은 것처럼 보였습니다.
— Paul Gear

흥미 롭군 HP가 Cisco와는 다른 일을했을 수도 있습니다. 영향을 줄 수있는 몇 가지 사항은 루프와 관련된 인터페이스 속도입니다. 유니 캐스트 또는 브로드 캐스트 인 경우 스위치에 VLAN에 SVI가 있는지 여부
— Daniel Dib

1
응-이상해 나는 스위치 IP 문제를 제외한 모든 것들이 실리콘에 있다고 생각했을 것이다.
— Paul Gear

실제로, 이제 생각해 보니, 영향을받는 VLAN에 스위치 IP가 없었 음을 거의 확신합니다. 해당 사이트의 모든 스위치 간 링크에는 관리 IP가없는 전송 VLAN에서 태그가 지정되지 않았습니다.
— Paul Gear

22

내 사용자 중 하나가 최근에 누군가의 책상에서 데스크탑 스위치를 빌 렸습니다. 스위치를 반환하자마자 근처의 느슨한 이더넷 끝을 모두 꽂았습니다. 이러한 케이블 중 하나는 네트워크에 연결되었고 다른 하나는 동일한 케이블의 두 끝이었습니다. 데스크톱 스위치가 네트워크에 연결되어 있고 자체 연결되었습니다. 스위치에는 STP가 없으므로 네트워크에서 들어오는 브로드 캐스트는 다른 케이블에서 양방향으로 루프됩니다. 물론, 루프 된 포트에서 브로드 캐스트가 수신 될 때마다 네트워크로 다시 복제됩니다. 이로 인해 HSRP가 완전히 열광하고 설계가 열악하여 캠퍼스 전체에서 OSPF 인접 장애가 발생했습니다.

문제의 첫 징후는 내 이메일로 전달 된 macflap이었습니다. 이것은 즉시 올바른 배선 실로 이어졌습니다. 여기에서 포트 LED, 인터페이스 pp 및 로그를 기반으로하는 제거 프로세스였습니다. 말할 것도없이 캠퍼스 전체를 재구성했습니다. 가장 좋은 예방 조치는 아마도 bpduguard입니다. 그 이후로 기능을 배포했으며 매우 간단했습니다. 내 이메일에서 오류가 발생한 syslog를 얻는 것은 결코 행복한 일이 아닙니다.


3
불행히도, 여러 스위치에 연결된 WIFI 액세스 포인트가있는 경우 MAC 플랩 로그 메시지는 쓸모가 없습니다. 한 AP에서 다음 AP로 로밍하는 사용자가 그러한 메시지를 유발하기 때문입니다. BPDU Guard (또는 이와 같은 메커니즘)는 액세스 스위치에서 반드시 사용해야합니다. 게으른 경우 "errdisable recovery cause bpduguard"문을 추가하여 5 분 후에 오류 비활성화 된 포트가 자동으로 전달 상태가되도록하므로 연결을 끊은 후 구성에서 포트를 재설정 할 필요가 없습니다. 문제를 일으키는 케이블
— Remi Letourneau

1
> 거기서부터 포트 LED를 기반으로 한 제거 과정이었습니다 ... Ahh, Das Blinkenlichten.
— Arthur Kay

11

대부분의 장비를 사용하면 CPU가 100 %로 촬영되며 중복 물리적 연결을 끊는 것만 가능합니다. CPU가 정지되면 링크를 하나씩 다시 연결하고 루프를 발생시키는 원인을 확인할 수 있습니다.

큰 섀시 (예 : 6500)의 경우 모든 블레이드를 뽑아 한 번에 하나씩 다시 연결해야했습니다. 블레이드를 알아 낸 후에는 모든 개별 링크 (16GBIC)를 모두 끌어와 한 번에 하나씩 다시 연결해야했습니다. 절대 재미 없어

일부 최신 장비에는 보호 된 CPU가있어이를 쉽게 처리 할 수 ​​있으므로 상자와 여전히 상호 작용할 수 있습니다. 이 시점에서 트래픽 카운터를보고 오작동 링크를 판별하는 것이 가능해집니다.


11

최근에 각 포트에서 브로드 캐스트 제한을 사용하는 회사에서 시작했습니다. 포트가 브로드 캐스트 할 때 포트 용량의 5 %를 초과하면 스위치가 포트를 ERRDISABLE에 넣습니다.

 storm-control broadcast level 5.00  
 storm-control action shutdown

한 그룹이 무선 네트워크를 LAN에 연결하는 장치를 연결하는 경향이있을 때 이것은 생명의 은인이었습니다.

귀하의 실제 질문에 대해서는 항상 수동적 인 것으로 나타났습니다.


9

iOS의 경우 :

포트간에 MAC 주소가 표시 될 수 있습니다. 다음에서 MAC_MOVE_NOTIFICATION오류를 찾습니다 .

sh logg

이제 포트를 찾으려면

sh int g0/1 controller

일반 중을 찾아 Multicast및 Broadcast번호. 모든 충돌은 잘못된 신호입니다.

마지막으로, CPU가 pwn되어 있기 때문에 로그인 할 수 없습니다 :)

sh proc cpu

스위치는 어떻게 작동합니까? L2 스위치 인 경우 ~ 10 % 이상은 원하지 않습니다.


9

관리되지 않거나 관리되지 않는 항목 (로그인 세부 정보 부족 또는 스위치 운영 체제에 대한 지식 등), 스위치 및 브리지 루프의 경우 루프를 수동으로 찾는 방법에 대해 설명합니다. 이것은 또한 "당신은 STP를 가지고 있지 않다"는 최초의 질문의 근본적인 바닥을 다룹니다.

이 루프의 오류 찾기를위한 기본 알고리즘은 STP와 유사합니다. 단, 포트 ID가있는 BPDU를 쉽게 보낼 수있는 것은 아닙니다.

  • 먼저, 패킷 덤프 / 스니핑 가능 장치를 스위치 중 하나의 포트에 연결하십시오. 이 장치는 이제 트리의 루트 장치가되었습니다.
    • 예를 들어 "캠퍼스"등을 통해 여러 위치에 오류를 배치해야하는 경우 휴대용 ssh 클라이언트를 사용하여 패킷 덤핑 시스템에 원격으로 로그인 할 수 있습니다.
      • 개인적으로 리눅스 랩톱을 화면에 tcpdump로 인터넷에 연결하고 ipad 또는 전화와 같이 ssh에 넣었습니다.
    • 원격으로 자신을 로그인 할 수없는 경우 친구를 사용하여 tcpdump를 시각적으로 모니터링하십시오. 링크 속도로 넘쳐서 루프 소스 장치를 향한 경로가 끊어 질 때마다 차이를 쉽게 알 수 있습니다.
  • 다음으로 루트 스위치에서 시작하여 트리를 기본적으로 다시 만들어야합니다.
    1. 루트 장치에 여러 개의 루핑 링크를 공급하는 시나리오가있을 수 있으므로 연결된 모든 포트를 동시에 한 번에 제거해야합니다.
    2. 포트를 하나씩 다시 연결하고 언제든지 패킷 버스트가 다시 나타나면이 포트를 따라 다른 쪽 끝의 연결된 스위치로 이동하십시오.
    3. 루프 된 포트를 찾을 때까지 1 단계를 반복하고 수동 트리에서 더 이상 반복 할 수 없습니다.
    4. 이 스위치의 루프 상황을 해결 한 후 트리의 위 스위치로 돌아가 2 단계를 재개하십시오.이 재귀는 루트 스위치에서 최종 케이블이 다시 연결될 때까지 계속 반복됩니다.

이것은 루프 포트에 대한 철저한 수동 검색입니다.

일반적으로 한 쌍의 포트가 루프로 연결되므로 모든 연결된 (링크) 포트를 먼저 제거한 다음 하나씩 다시 연결해야하는 철저하고 안전한 검색이 필요합니다. '트리'아래에 하나의 포트 쌍만 반복되는 경우 한 번에 하나의 포트를 연결 해제하여 찾을 수 있습니다.

그럼에도 불구하고 일반적인 "완전 방호", 방법 또는 알고리즘은 위에서 설명한 내용이됩니다.


7

아야. 그러나 나는 이것에 갈 두 가지 방법을 생각할 수 있습니다 ...

눈알 : 스위치에 포트 표시기가 있으면 가장 활성화 된 포트를 눈으로 볼 수 있어야합니다. 그것들은 처음부터 시작하는 것들입니다. 케이블에 레이블이 붙어 있기 때문에 동일한 케이블을 사용하는 두 개의 스위치에서 두 개의 사용중인 포트를 찾는 낮은 연결 상태를 검색 할 수 있습니다.

SNMP 모니터링 : SNMP (또는 유사한) 사용 통계가있는 경우 가장 바쁜 스위치와 가장 바쁜 포트를 찾으십시오. 그런 다음 케이블을 살펴보십시오.

... 라벨이없는 케이블이있는 경우 가장 바쁜 포트를 확인하는 과정에서 추적 및 라벨링을 시작하십시오.


2
SNMP 트랩은 일반적으로 300 초마다 한 번만 수행되는 SNMP 폴링보다 낫습니다. 플러드 및 후속 중단은 너무 빨리 발생하여 SNMP에서 아무것도 모니터링하지 않을 수 있습니다. 그래도 여전히 도움이되지만 유지할 수없는 스위치에서 데이터를 다시 가져 오지 못하는 SNMP 모니터는 시작점을 제공 할 수 있습니다.
— generalnetworkerror

3

문제의 계층 2 도메인이 완전히 중단되었으며 CPU가 모두 페깅되어 있기 때문에 관리 액세스 권한이 없다는 점을 이해 하여이 질문에 대답하려고합니다.

브리징 루프 문제를 해결하는 가장 좋은 방법은 업 링크가 사라질 때까지 플러그를 뽑는 것입니다. 모든 액세스 스위치가 한 쌍의 분배 스위치에 연결된 표준 스위치 액세스 계층이 있다고 가정하십시오. 첫 번째 액세스 스위치로 이동하여 업 링크 플러그를 뽑습니다. 스위치 포트의 LED가 정신적으로 멈추는 경우 해당 스위치가 아니라 다시 연결 한 후 다음 스위치로 이동하십시오. 업 링크 플러그를 뽑고 LED가 계속 빠르게 깜박이는 스위치가 나올 때까지 반복하십시오. 이것은 루프가있는 스위치입니다.

이제 LED가 진정 될 때까지 최종 사용자 포트에서 연결 해제 프로세스를 시작하십시오. 연결이 끊어지면 마지막으로 문제가 발생한 포트였으며 케이블을 추적하고 사용자를 적절하게 쫓습니다.


2

솔직히 말해서, 장치에 원격으로 (또는 콘솔 케이블을 통해) 연결하면 장치가 매우 느리다는 것을 알 수 있습니다. CLI에 나오는 글자를 입력 할 때부터 지연됩니다.

Cisco 스위치 인 2 개의 쉬운 스위치가 인터페이스 통계를 살펴보면 100 % (또는 255/255)로 지속적으로 사용됩니다. 스위치를 다루면서 몇 년 동안 포트가 합법적으로 100 % 사용되는 것을 보지 못했습니다. 그 외에는 CPU 사용량 (일반적으로 "show process cpu history")을 확인하십시오. 루프 된 인터페이스는 일반적으로 고급 스위치를 실행하지 않는 한 CPU를 매우 세게 때립니다.

STP는 실제로 활성화되어야합니다!


2

이 문제는 미국의 다른 쪽 네트워크에서 발생했으며 전화를 통해 일부 수준의 분석가를 원격으로 도와 주어야했습니다. 이 문제는 몇 년 동안 네트워크에 천천히 추가 한 여러 브랜드의 스위치가 있다는 사실로 인해 더욱 복잡해졌습니다. 사무실을 옮길 때 각 포트가 어디로 갔는지 표시 한 다음 새 사무실에서 모든 것을 똑같은 방식으로 다시 연결하고 모든 것을 시작했습니다. 스패닝 트리에서 작동 한 소수의 스위치는 같은 방식으로 수렴하지 않았으며 모든 종류의 루프와 문제가있었습니다. 내가 모든 것을 고칠 때까지 관리되지 않은 스위치 3 개 이상이 나머지 인프라와 루프로 연결된 것으로 발견되었습니다.

관리되지 않는 각 스위치를 추적 할 수있는 방법은 nedi라는 도구를 사용하는 것입니다 (관리 할 수있는 스위치에서 lldp / cdp를 활성화했습니다). 나는 먼저 nedi로 맵을 생성했습니다. 그런 다음 맵에서 한 스위치에서 다른 스위치로의 연결을 표시 한 다음 다시 같은 스위치로 다시 연결 한 영역에서 네트워크 기술자가 현장의 회선을 수동으로 추적하도록했습니다. 루프와 관련된 인터페이스를 수동으로 종료하거나 현장 직원이 케이블을 뽑도록했습니다. 결국 나는 모든 미친 오프 브랜드 스위치에도 불구하고 네트워크를 정상적으로 작동시킬 수있었습니다.


1

여기서 수행 할 수있는 한 가지는 명령 show cdp neighbor또는을 사용하여 스위치에 연결된 시스템을 확인하는 것 show lldp neighbor입니다.

BPDU guard 명령을 사용하지 않고 누군가 우선 순위가 낮은 (또는 이전 mac-address) 악성 로그 스위치를 연결하면 새 장치가 스패닝 트리 루트로 협상하여 문제가 발생합니다.


0

내 경험상 항상 방금 꽂거나 닫지 않았거나 포트 채널에 추가 한 케이블이었습니다. 다른 사람이 해냈을 때 더 힘들어하고 즉시 주저하지 않습니다.


0

루프를 결정하는 것은 실제로 사용하는 스위치 브랜드에 달려 있습니다. 예를 들어, Extreme 스위치에서는 VLAN에서 elrp-client를 실행할 수 있으며 스위치는 기본적으로 해당 VLAN의 모든 포트에서 브로드 캐스트 프레임을 전송하고 그 중 어떤 포트에서 리턴되는지 확인합니다. 포트가 프레임을 다시 수신하여 루프 후보를 나타냅니다.

Cisco에서는 기본적으로 상태가 지워질 때까지 (또는 오류 상태를 지울 때까지) 일정 시간 동안 포트를 차단하기 때문에 폭풍 제어를 활성화 할 수 있습니다. 스패닝 트리 나 포워드 BPDU를 수행하지 않는 장치의 혼합 토폴로지에서 Cisco 스위치를 사용하는 경우에만 해당됩니다.


0

의심 할 여지없이 내가 찾은 가장 빠른 방법은 인터페이스의 패킷 / 초 속도를 모니터링하는 것입니다. 적절한 CLI 필터가있는 빠른 쇼 인터페이스에는 각 인터페이스와 패킷 / 초 속도가 나열됩니다. 루프 소스를 찾으려면 초고속 패킷 / 초 INPUT 속도의 유일한 인터페이스를 찾으십시오. 일반적인 사용 환경 프로파일이있는 일반적인 엔터프라이즈 환경에서는 항상 작동합니다. 인터페이스가 많은 6500에서 소스를 찾는 데 시간이 오래 걸리지 않습니다 ...


0

루프 도중, 엔드 스테이션에서 많은 브로드 캐스트 트래픽 (예 : ARP 요청)의 경우 CPU에 대한로드도 증가 할 수 있습니다 (예 : CPU에서 체크섬을 계산하는 저렴한 100Mbit / s realtek 카드를 사용하는 경우). 케이블 연결이 끊어지면 루프를 찾는 것이 물리적으로 가능하므로 링크가 2 개의 포트에서 즉시 끊어집니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.