ARP 브로드 캐스트 플러딩 네트워크 및 높은 CPU 사용량

20

여기 누군가를 바라는 것은 우리가 직면 한 문제에 대한 통찰력을 가질 수 있습니다. 현재 Cisco TAC가이 사례를보고 있지만 근본 원인을 찾기 위해 고심하고 있습니다.

제목에 ARP 브로드 캐스트 및 높은 CPU 사용량이 언급되어 있지만이 단계에서 ARP 브로드 캐스트가 관련되어 있는지 또는 관련성이 없는지 확실하지 않습니다.

원래 문제는 INE 온라인 커뮤니티에 게시 되었습니다

중복 설정이없는 단일 링크로 네트워크를 분리했습니다. 스타 토폴로지로 생각하십시오.

사리:

하나의 스택에 3750x 스위치, 4를 사용합니다. 버전 15.0 (1) SE3. Cisco TAC는이 특정 버전의 CPU 또는 ARP 버그에 대해 알려진 문제가 없음을 확인합니다.
연결된 허브 / 비 관리 스위치
재로드 된 코어 스택
기본 경로 "Ip route 0.0.0.0 0.0.0.0 f1 / 0"이 없습니다. 라우팅에 OSPF 사용
데스크톱 장치에 사용되는 VLAN 1, VLAN 1의 대용량 브로드 캐스트 패킷이 있습니다. 192.168.0.0/20을 사용
Cisco TAC는 / 20을 사용하는 데 아무런 문제가 없다고 말했지만 다른 방송 도메인은 있지만 여전히 작동해야합니다.
Wi-Fi, 관리, 프린터 등은 모두 서로 다른 VLAN에 있습니다.
스패닝 트리는 Cisco TAC 및 CCNP / CCIE 인증 전문가에 의해 검증되었습니다. 모든 중복 링크를 종료했습니다.
코어 구성이 Cisco TAC에서 확인되었습니다.
대부분의 스위치에 기본 ARP 시간 초과가 있습니다.
우리는 Q & Q를 구현하지 않습니다.
새로운 스위치가 추가되지 않았습니다 (적어도 우리는 아는 바 없음).
에지 스위치는 2950이므로 동적 arp 검사를 사용할 수 없습니다
우리는 show interfaces | inc line | broadcast는 많은 수의 브로드 캐스트가 어디에서 오는지 알아 내지 만, Cisco TAC와 2 명의 다른 엔지니어 (CCNP & CCIE)는 네트워크에서 발생하는 문제 (많은 mac flap에서와 같이) 때문에 이것이 정상적인 동작임을 확인했습니다. 더 큰 방송의 원인). 에지 스위치에서 STP가 올바르게 작동하는지 확인했습니다.

네트워크 및 스위치의 증상 :

다수의 MAC 플랩
ARP 입력 프로세스를위한 높은 CPU 사용량
엄청나게 많은 ARP 패킷, 빠르게 증가하고 표시
Wiresharks는 수백 대의 컴퓨터가 ARP Broadcast로 네트워크를 침수하고 있음을 보여줍니다
테스트 목적으로, 우리는 약 80 대의 데스크탑 머신을 각각 다른 VLAN으로 설정했지만이를 테스트하여 높은 CPU 또는 ARP 입력과 눈에 띄는 차이를 만들지 않았습니다.
다른 AV / 맬웨어 / 스파이웨어를 실행했지만 네트워크에 바이러스가 보이지 않습니다.
sh mac address-table count, vlan 1에서 예상되는 약 750 개의 서로 다른 mac 주소를 보여줍니다.

#sh processes cpu sorted | exc 0.00%
CPU utilization for five seconds: 99%/12%; one minute: 99%; five minutes: 99%

 PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
  12   111438973    18587995       5995 44.47% 43.88% 43.96%   0 ARP Input
 174    59541847     5198737      11453 22.39% 23.47% 23.62%   0 Hulc LED Process
 221     7253246     6147816       1179  4.95%  4.25%  4.10%   0 IP Input
  86     5459437     1100349       4961  1.59%  1.47%  1.54%   0 RedEarth Tx Mana
  85     3448684     1453278       2373  1.27%  1.04%  1.07%   0 RedEarth I2C dri

Ran은 다른 스위치와 코어 자체에서 mac 주소 테이블을 보여 주며 (예 : 코어가 데스크탑에 직접 연결되어있는 것처럼), 인터페이스에 여러 가지 MAC 하드웨어 주소가 인터페이스에 등록되어 있음을 알 수 있습니다. 하나의 컴퓨터에만 연결 :

 Vlan    Mac Address       Type        Ports
 ----    -----------       --------    -----
    1    001c.c06c.d620    DYNAMIC     Gi1/1/3
    1    001c.c06c.d694    DYNAMIC     Gi1/1/3
    1    001c.c06c.d6ac    DYNAMIC     Gi1/1/3
    1    001c.c06c.d6e3    DYNAMIC     Gi1/1/3
    1    001c.c06c.d78c    DYNAMIC     Gi1/1/3
    1    001c.c06c.d7fc    DYNAMIC     Gi1/1/3

플랫폼 tcam 활용률 표시

 CAM Utilization for ASIC# 0                      Max            Used
                                              Masks/Values    Masks/values

  Unicast mac addresses:                       6364/6364       1165/1165
  IPv4 IGMP groups + multicast routes:         1120/1120          1/1
  IPv4 unicast directly-connected routes:      6144/6144        524/524
  IPv4 unicast indirectly-connected routes:    2048/2048         77/77
  IPv4 policy based routing aces:               452/452          12/12
  IPv4 qos aces:                                512/512          21/21
  IPv4 security aces:                           964/964          45/45

우리는 이제 다른 사람이이 이상하고 기괴한 문제의 원인이나 근본 원인을 식별 할 수있는 아이디어가없는 한, 한 번에 각 영역을 격리하기 위해 엄청난 양의 가동 중지 시간이 필요한 단계에 있습니다.

해결되었습니다.

이 문제는 ConfigMrg Wake-Up Proxy 서비스 인 SCCM 2012 SP1에서 발생합니다 . '기능'에는 기존 SCCM 2012 RTM이 없습니다.

정책 내에서이 기능을 해제 한 후 4 시간 내에 CPU 사용량이 꾸준히 감소했습니다. 4 시간이 지나면 ARP 사용량은 1-2 %에 불과했습니다!

요약하면이 서비스는 MAC 주소 스푸핑을 수행합니다. 그것이 얼마나 큰 혼란을 초래했는지 믿을 수 없습니다.

아래는 게시 된 문제와의 관계를 이해하는 것이 중요하다고 생각하는 Microsoft Technet의 전문입니다.

관심있는 사람은 아래에 기술 정보가 있습니다.

Configuration Manager는 소프트웨어 업데이트 및 응용 프로그램과 같은 필수 소프트웨어 (예 : 기존 웨이크 업 패킷 및 AMT 전원 켜기 명령)를 설치하려는 경우 절전 모드에서 컴퓨터를 웨이크 업하기 위해 LAN (LAN) 기술을 지원합니다.

Configuration Manager SP1부터는 웨이크 업 프록시 클라이언트 설정을 사용하여 기존 웨이크 업 패킷 방법을 보완 할 수 있습니다. 웨이크 업 프록시는 피어 투 피어 프로토콜과 선택된 컴퓨터를 사용하여 서브넷의 다른 컴퓨터가 깨어 있는지 확인하고 필요한 경우 깨 웁니다. 사이트가 Wake On LAN으로 구성되고 클라이언트가 Wake-up 프록시로 구성되면 프로세스는 다음과 같이 작동합니다.

Configuration Manager SP1 클라이언트가 설치되어 있고 서브넷에서 절전 모드가 아닌 컴퓨터는 서브넷의 다른 컴퓨터가 활성 상태인지 확인합니다. 5 초마다 TCP / IP ping 명령을 서로 전송하여이를 수행합니다.

다른 컴퓨터에서 응답이 없으면 잠자기 상태 인 것으로 간주됩니다. 깨어 난 컴퓨터는 서브넷의 관리자 컴퓨터가됩니다.

컴퓨터가 절전 모드 이외의 이유 (예 : 컴퓨터가 꺼져 있거나 네트워크에서 제거되었거나 프록시 웨이크 업 클라이언트 설정이 더 이상 적용되지 않음)로 인해 응답하지 않을 수 있으므로 컴퓨터는 현지 시간으로 매일 오후 2시에 웨이크 업 패킷을 보냈습니다. 응답하지 않는 컴퓨터는 더 이상 잠자기 상태가 아니며 웨이크 업 프록시에 의해 깨어나지 않습니다.

웨이크 업 프록시를 지원하려면 각 서브넷에 대해 최소 3 대의 컴퓨터가 깨어 있어야합니다. 이를 위해 세 개의 컴퓨터가 결정적으로 서브넷의 보호 컴퓨터로 선택됩니다. 즉, 일정 기간 동안 사용하지 않으면 절전 모드 또는 최대 절전 모드로 구성된 전원 정책이 구성되어 있어도 깨어 있습니다. Guardian 컴퓨터는 예를 들어 유지 관리 작업의 결과로 종료 또는 재시작 명령을 적용합니다. 이 경우 나머지 보호자 컴퓨터는 서브넷의 다른 컴퓨터를 깨워서 서브넷에 계속 3 개의 보호자 컴퓨터를 갖습니다.

관리자 컴퓨터는 네트워크 스위치에 대기중인 컴퓨터의 네트워크 트래픽을 자신에게 리디렉션하도록 요청합니다.

재 지정은 대기중인 컴퓨터의 MAC 주소를 소스 주소로 사용하는 이더넷 프레임을 브로드 캐스트하는 관리자 컴퓨터에 의해 달성됩니다. 이렇게하면 대기중인 컴퓨터가 관리자 컴퓨터와 같은 포트로 이동 한 것처럼 네트워크 스위치가 작동합니다. 또한 관리자 컴퓨터는 대기중인 컴퓨터가 ARP 캐시에서 항목을 최신 상태로 유지할 수 있도록 ARP 패킷을 보냅니다. 또한 관리자 컴퓨터는 대기중인 컴퓨터 대신 ARP 요청에 응답하고 대기중인 컴퓨터의 MAC 주소로 응답합니다.

이 프로세스 동안 대기중인 컴퓨터의 IP-MAC 매핑은 동일하게 유지됩니다. 웨이크 업 프록시는 다른 네트워크 어댑터가 다른 네트워크 어댑터에 의해 등록 된 포트를 사용하고 있음을 네트워크 스위치에 알리면 작동합니다. 그러나이 동작은 MAC 플랩이라고하며 표준 네트워크 작동에는 이례적입니다. 일부 네트워크 모니터링 도구는이 동작을 찾고 무언가 잘못되었다고 가정 할 수 있습니다. 따라서이 모니터링 도구는 웨이크 업 프록시를 사용할 때 경고를 생성하거나 포트를 종료 할 수 있습니다. 네트워크 모니터링 도구 및 서비스에서 MAC 플랩을 허용하지 않으면 웨이크 업 프록시를 사용하지 마십시오.

관리자 컴퓨터에 대기중인 컴퓨터에 대한 새 TCP 연결 요청이 표시되고 대기중인 컴퓨터가 대기 모드로 전환되기 전에 대기중인 포트에 대한 요청 인 경우, 관리자 컴퓨터는 대기 상태의 컴퓨터에 웨이크 업 패킷을 보낸 다음 이 컴퓨터의 트래픽 리디렉션을 중지합니다.

잠자기 컴퓨터가 웨이크 업 패킷을 수신하여 깨우기합니다. 보내는 컴퓨터가 자동으로 연결을 다시 시도하고 이번에는 컴퓨터가 깨어 있고 응답 할 수 있습니다.

참조 : http://technet.microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClients

여기에 게시하고 문제 해결 프로세스를 도와 주신 모든 분들께 감사드립니다.

— 콜드 T
소스

당신은 대답에 필수 요소를 넣지 않았습니다. 어떻게 그 기능을 끄겠습니까?

— Overmind

10

ARP / 브로드 캐스트 폭풍

데스크톱 장치에 사용되는 VLAN 1, VLAN 1의 대용량 브로드 캐스트 패킷이 있습니다. 우리는 192.168.0.0/20을 사용합니다 ...

Wiresharks는 수백 대의 컴퓨터가 ARP 브로드 캐스트로 네트워크를 침수하고 있음을 보여줍니다 ...

ARP 입력 프로세스가 높기 때문에 스위치가 ARP를 처리하는 데 많은 시간을 소비하고 있습니다. ARP 플러딩의 가장 일반적인 원인 중 하나는 스위치 사이의 루프입니다. 고리가 있다면 위에서 언급 한 맥 플랩을 얻을 수도 있습니다. ARP 홍수의 다른 가능한 원인은 다음과 같습니다.

IP 주소 구성 오류
arp 스푸핑 과 같은 layer2 공격

먼저 위에서 언급 한 잘못된 구성이나 layer2 공격의 가능성을 제거하십시오. 가장 쉬운 방법 은 리눅스 컴퓨터에서 arpwatch 를 사용하는 것입니다 ( 노트북 에서 livecd 를 사용해야하는 경우에도 ). 구성이 잘못되었거나 layer2 공격이있는 경우 arpwatch는 syslog에 다음과 같은 메시지를 표시합니다. syslog에는 동일한 IP 주소를 놓고 싸우는 mac 주소가 나열됩니다.
Oct 20 10:31:13 tsunami arpwatch: flip flop 192.0.2.53 00:de:ad:85:85:ca (00:de:ad:3:d8:8e)

"플립 플롭"이 보이면 mac 주소의 소스를 추적하고 이들이 동일한 IP를 놓고 싸우는 이유를 찾아야합니다.

다수의 MAC 플랩

스패닝 트리는 Cisco TAC 및 CCNP / CCIE 인증 전문가에 의해 검증되었습니다. 모든 중복 링크를 종료했습니다.

내가 기억하고 싶은 것보다 더 많은 시간을 보낸 사람이라고 말하면, 모든 중복 링크를 발견했다고 가정하지 말고 스위치 포트가 항상 작동하도록하십시오.

스위치 포트 사이에 많은 수의 맥 플랩이 있으므로, 위반자가 어디에 있는지 찾기가 어렵습니다 (많은 arp를 전송하는 2 ~ 3 개의 맥 주소를 찾더라도 소스 맥 주소는 포트간에 계속 펄럭입니다). 에지 포트 당 mac-addresses에 대해 엄격한 제한을 적용하지 않는 경우 케이블을 수동으로 뽑지 않으면 이러한 문제를 추적하기가 매우 어렵습니다. 스위치 루프는 네트워크에서 예상치 못한 경로를 야기하며 일반적으로 데스크탑 스위치 포트가되어야하는 것에서 간헐적으로 학습 된 수백 개의 Mac을 사용할 수 있습니다.

mac-moves를 느리게하는 가장 쉬운 방법은입니다 port-security. 다운 스트림 스위치없이 단일 PC에 연결된 Vlan 1의 모든 액세스 스위치 포트에서 cisco 스위치에서 다음 인터페이스 수준 명령을 구성하십시오.

switchport mode access
switchport access vlan 1
!! switchport nonegotiate disables some Vlan-hopping attacks via Vlan1 -> another Vlan
switchport nonnegotiate
!! If no IP Phones are connected to your switches, then you could lower this
!!   Beware of people with VMWare / hubs under their desk, because 
!!   "maximum 3" could shutdown their ports if they have more than 3 macs
switchport port-security maximum 3
switchport port-security violation shutdown
switchport port-security aging time 5
switchport port-security aging type inactivity
switchport port-security
spanning-tree portfast
!! Ensure you don't have hidden STP loops because someone secretly cross-connected a 
!!   couple of desktop ports
spanning-tree bpduguard enable

대부분의 mac / ARP 플러딩 사례에서이 구성을 모든 에지 스위치 포트 (특히 포트 패스트가있는 포트)에 적용하면 구성이 세 개의 mac-address를 초과하는 포트를 종료하고 비밀리에 비활성화되기 때문에 정상 상태로 돌아갑니다. 루프 된 포트 패스트 포트. 포트 당 3 개의 mac은 데스크탑 환경에서 잘 작동하는 숫자이지만 10으로 올릴 수도 있습니다. 이 작업을 수행 한 후에는 레이어 2 루프가 끊어지고 빠른 맥 플랩이 중단되며 진단이 훨씬 쉬워집니다.

브로드 캐스트 스톰 (mac-move) 및 플러딩 (임계 값)과 관련된 포트를 추적하는 데 유용한 또 다른 전역 명령 ...

mac-address-table notification mac-move
mac address-table notification threshold limit 90 interval 900

완료 한 후 선택적 clear mac address-table으로 전체 CAM 테이블에서 치유를 가속화 하기 위해 수행 하십시오.

Ran은 다른 스위치와 코어 자체에서 mac 주소 테이블을 보여 주며 (예 : 코어가 데스크탑에 직접 연결되어있는 것처럼), 인터페이스에 여러 가지 MAC 하드웨어 주소가 인터페이스에 등록되어 있음을 알 수 있습니다. 하나의 컴퓨터에만 연결되어 있습니다 ...

이 전체 답변은 3750에 문제를 일으키는 버그가 없다고 가정합니다 (그러나 wireshark는 범람중인 PC를 나타냅니다). 해당 PC에 VMWare가없는 경우 Gi1 / 1 / 3에 컴퓨터가 하나만 연결되어 있으면 우리에게 보여주는 내용이 분명히 잘못되었습니다.

기타 생각

우리가 가진 대화를 기반으로, 아마도 명백한 언급은 할 필요가 없지만, 앞으로의 방문객을 위해 나는 ...

Vlan1에 사용자를 배치하는 것은 일반적으로 나쁜 생각입니다 (난장판을 물려 받았을 수도 있음을 이해합니다)
TAC가 말한 내용에 관계없이 192.168.0.0/20은 너무 커서 너무 커서 레이어 2 공격의 위험없이 단일 스위치 도메인에서 관리 할 수 없습니다. 서브넷 마스크가 클수록 ARP는 인증되지 않은 프로토콜이므로 라우터는 최소한 해당 서브넷에서 유효한 ARP를 읽어야하므로 이와 같은 레이어 2 공격에 더 많이 노출됩니다.
layer2 포트의 스톰 제어는 일반적으로 좋은 생각입니다. 그러나 이와 같은 상황에서 스톰 제어를 사용하면 나쁜 트래픽으로 좋은 트래픽을 가져옵니다. 네트워크가 치료 된 후 에지 포트 및 업 링크에 일부 폭풍 제어 정책을 적용하십시오.

— 마이크 페닝 턴
소스

1

실제로, 그의 사기는 최대치가 아닙니다. 첫 번째 열은 최대 값이고 두 번째 열은 현재 사용량입니다. 마스크 대 값 부분을 무시할 수 있습니다. 여기에서 "단순한"arp 폭풍처럼 들리지만 그의 토폴로지와 실제 트래픽에 대한 지식이 없으면 그 이유를 알 수 없습니다.

2

실제 질문은 왜 호스트가 처음에 많은 ARP를 보내는 지입니다. 이것이 응답 될 때까지 스위치는 계속해서 arp storm을 다루는 데 어려움을 겪게됩니다. 넷 마스크 불일치? 호스트 arp 타이머가 낮습니까? "인터페이스"경로가있는 하나 이상의 호스트 ? 루즈 무선 브리지 어딘가? "무심한 arp"는 미쳤다고? DHCP 서버 "사용 중"프로빙? 스위치 나 레이어 2에서는 문제가되지 않습니다. 나쁜 일을하는 호스트가 있습니다.

내 디버깅 프로세스는 모든 것을 분리하고 한 번에 하나씩 포트가 다시 연결될 때 면밀히 관찰합니다. (나는 그것이 이상적인 곳에서 몇 마일 떨어져 있다는 것을 알고 있지만 어느 시점에서 손실을 줄이고 가능한 모든 소스를 물리적으로 격리하려고 시도해야합니다.) 그런 다음 선택 포트가 왜 많은 arp를 생성하는지 이해하기 위해 노력할 것입니다.

(많은 호스트가 리눅스 시스템 일까? 리눅스는 매우 바보 같은 ARP 캐시 관리 시스템을 가지고있다. 단 몇 분 안에 엔트리를 "재확인"한다는 사실은 나의 책에서 깨졌다. 소규모 네트워크에서는 그다지 문제가되지 않지만 / 20은 소규모 네트워크가 아닙니다.)

— 리키 빔
소스

1

이것은 당면한 문제와 관련이있을 수도 있고 아닐 수도 있지만 적어도 거기에서 버릴만한 가치가 있다고 생각했습니다.

우리는 현재 원격 사이트의 일부에 3750x를 쌓았습니다. 주로 15.0.2 (SE0에서 4까지, 천천히 마이그레이션하는 SE0에는 일부 FRU 버그가 있습니다).

일상적인 IOS 업데이트 중에 15.0.2에서 15.2-1 (가장 최근의 SE)로 가면서 사용량이 적을 때 CPU가 평균 약 30 %에서 60 % 이상으로 상당히 증가한 것을 알 수있었습니다. 구성 및 IOS 변경 로그를 검토했으며 Cisco의 TAC와 협력하고 있습니다. TAC에 따르면 이들은 이것이 IOS 15.2-1 버그라고 생각하는 시점에있는 것 같습니다.

CPU 증가를 계속 조사하면서 ARP 테이블이 완전히 채워져 네트워크 불안정을 초래할 정도로 대량의 ARP 트래픽이 발생하기 시작했습니다. 이를위한 임시 버팀목은 음성 및 데이터 VLAN에서 ARP 시간 초과를 기본값 (14400)에서 300으로 수동으로 되 돌리는 것입니다.

ARP 타임 아웃을 줄인 후, 우리는 몇 주 정도 안정되어 IOS 15.0.2-SE4로 돌아 왔고 기본이 아닌 ARP 타임 아웃을 제거했습니다. 우리의 CPU 사용률은 ~ 30 %로 낮아지고 ARP 테이블 문제는 존재하지 않습니다.

재미있는 이야기 ... 공유해 주셔서 감사합니다. 버그가 추가되어 OP 노출 여부를 쉽게 파악할 수 있습니다. 참고로 ARP 타임 아웃을 CAM 타이머보다 낮게 유지하는 것이 좋습니다.

— Mike Pennington

의견에 감사하지만 원래 문제를 고려하여 현재 스택에서 낮은 IOS 버전을 사용하고 있으며 일정 기간 동안 상당히 안정적입니다. @MikePennington 기본적으로 ARP 시간 초과는 4 시간으로 설정되고 CAM 시간 초과는 5 분입니까? 그렇지 않습니까?

— 콜드 T

@ColdT, 이것이 내가 언급 한 이유입니다. 일부 HSRP 사례의 경우 Cisco의 CAM / ARP 타이머가 기본적으로 작동하지 않습니다 . 설득력있는 이유가 없다면 arp timeout 240스위치를 향한 모든 SVI / L3 인터페이스에 내 설정을 지정하십시오 .