1. Storm Control - 트래픽 폭풍 방어의 기본기

여러분, 고속도로에서 차 한 대가 갑자기 역주행한다고 상상해보세요. 뒤에서 오던 차들이 피하려다 서로 부딪히고, 그 뒤로 줄줄이 충돌이 이어집니다. 한 대의 실수가 수십 대의 연쇄 사고로 번지는 거죠.

네트워크에서도 비슷한 일이 벌어집니다. 한 포트에서 비정상적으로 많은 브로드캐스트가 쏟아지면, 그 프레임을 모든 포트로 뿌리는 스위치 특성상 네트워크 전체가 먹통이 됩니다. 이걸 브로드캐스트 스톰(Broadcast Storm) 이라고 부릅니다.

앞서 [[02_L2 Security Fundamentals]]에서 다룬 5대 기둥(Port Security, DHCP Snooping, DAI, IPSG, STP 보안)은 의도적 공격에 대한 방어였습니다. 반면 Storm Control은 조금 결이 다릅니다. “공격”보다는 “사고”에 가까운 상황을 방어하는 기능이거든요.

2. 브로드캐스트 스톰은 어떻게 생기나?

현장에서 가장 자주 만나는 시나리오 몇 가지를 풀어서 이야기해보겠습니다. 공격자가 의도적으로 만드는 경우는 의외로 적고, 평범한 사고가 대부분이에요.

케이블 한 가닥, 회의실 하나가 사옥을 마비시킨다

가장 많이 듣는 사례는 회의실에서 시작합니다. 직원이 자기 노트북 옆자리에 동료를 앉히려고 책상 밑 멀티탭을 뒤지다가 회의실 벽면 LAN 포트 두 개를 자기 옆에 있던 5포트 허브의 두 포트에 동시에 꽂아버립니다. 그 두 LAN 포트는 둘 다 같은 액세스 스위치로 올라가는 상태였고, 그 사이에 STP가 끼어들 수 없는 dumb 허브가 다리 역할을 한 거죠. 브로드캐스트 한 프레임이 → 스위치 → 허브 → 다시 스위치 → 허브 → … 무한 루프. 몇 초 안에 부서 인터넷이 다 죽고, 콜센터에 “갑자기 다 끊겼어요” 전화가 폭주합니다.

비슷한 패턴으로 데이터센터에서 케이블 정리하다가 패치 패널 두 군데를 잘못 연결, 신규 입주 회사가 옆 사무실에서 끌어온 케이블을 자기 스위치에도 꽂아둔 채로 출근, IDF 정리하면서 미사용으로 알았던 두 포트가 사실 살아있던 트렁크였던 케이스 같은 것들이 있습니다. 공통점은 — STP가 보호 못 하는 구간에 L2 회로가 닫힌다는 거예요.

    [SW1] ─────── [SW2]
      │             │
      │             │
    [SW3] ─────── [SW4]

링이 닫히는 순간 한 프레임이 SW1 → SW2 → SW4 → SW3 → SW1… 무한 반복. STP가 정상 작동했다면 한 링크를 blocking으로 바꿔서 끊었겠지만, dumb 허브나 STP 비활성 장비가 끼면 보호 자체가 안 됩니다.

불량 NIC — “한 명 때문에 부서 전체가 인터넷 끊김”

이건 정말 자주 듣는 이야기입니다. 누군가 PC가 며칠 째 이상하다가, 어느 순간 네트워크 전체가 같이 느려지기 시작합니다. 운영자가 추적해 보면 그 PC의 NIC이 고장나서 정체불명의 브로드캐스트(또는 깨진 프레임)를 초당 수천 개씩 쏘고 있어요. 정작 PC 사용자는 자기 인터넷이 안 된다는 것밖에 모릅니다.

비슷하게 싸구려 IP 폰 펌웨어 버그, 드라이버 업데이트 실패한 가상화 호스트, 서버 NIC 본딩(LACP) 설정 꼬임도 같은 패턴을 만듭니다. 공격자도 없고 악의도 없는데, 한 단말기의 하드웨어/소프트웨어 결함이 L2 도메인 전체를 마비시키죠.

바이러스·웜 — 부수 효과로서의 폭주

오래된 사례지만 여전히 회자되는 게 2003년 SQL Slammer입니다. UDP 패킷 376바이트짜리 공격 코드 하나가 자기 자신을 감염된 호스트에 복사해서 다시 뿌리는 식으로 15분 만에 전 세계 7만 5천 대 서버를 감염시켰는데, 감염된 서버가 같은 서브넷에 무차별 스캔을 뿌리면서 사내 LAN의 브로드캐스트 도메인이 함께 죽었습니다. 한국에서도 이때 인터넷이 사실상 마비됐고, 이후 모든 사내망 설계에서 “Storm Control은 기본”이라는 인식이 퍼졌어요.

요즘은 직접 브로드캐스트를 무차별 뿌리는 웜이 줄어든 대신, 스캐닝 봇넷·랜섬웨어 lateral movement 단계에서 ARP·SMB 브로드캐스트가 비정상적으로 많이 발생하는 패턴이 종종 잡힙니다. 의도적 폭주가 목적은 아니지만 결과적으로 Storm Control이 발동되면서 첫 경보가 울리는 케이스도 있어요.

설정 실수 — 야근의 단골

운영자가 야근하다가 만든 사고도 빼놓을 수 없습니다. SPAN(포트 미러링) 세션을 잘못 설정해서 미러 포트가 다시 같은 스위치 입력으로 루프, 테스트 환경에서 쓰던 STP 비활성 명령(no spanning-tree)을 운영 장비에 그대로 적용, 트렁크 native VLAN을 헷갈려서 같은 VLAN을 두 경로로 동시에 흘림 같은 것들. 새벽에 이런 변경을 푸시한 다음 출근하면 사무실에 도착하기 전부터 콜센터가 울고 있습니다.

이 모든 사고의 공통점은 — 임계값을 넘는 브로드캐스트/멀티캐스트가 발생하면 무조건 차단한다는 단순한 규칙 하나로 90% 이상 막을 수 있다는 점입니다. 그게 Storm Control이에요.

3. Storm Control의 원리

Storm Control은 스위치 포트별로 “초당 브로드캐스트가 대역폭의 몇 %를 넘으면 차단” 하는 간단한 기능입니다.

포트 대역폭이 1Gbps인데 브로드캐스트가 10Mbps(1%)를 넘기 시작하면 “뭔가 이상하다”고 판단해서 초과분을 드롭합니다.

세 가지 제어 대상

브로드캐스트는 값을 가장 낮게 잡습니다. 정상 네트워크에서 브로드캐스트가 1%를 넘는 경우는 거의 없기 때문입니다.

스위치 부하 — ASIC이 일하니까 거의 0

📎 ASIC이 뭔가요?

ASIC = Application-Specific Integrated Circuit, 한국어로 “주문형 집적회로”. 한 가지 일만 죽어라 잘하도록 설계된 전용 칩입니다.

	CPU (범용 프로세서)	ASIC (전용 칩)
비유	만능 요리사 — 어떤 요리든 가능, 시간 걸림	라면 자판기 — 라면만, 30초 컷
처리 방식	인스트럭션을 하나씩 해석·실행	회로 자체가 그 일을 하는 모양으로 새겨짐
속도	일반적	line-rate (1Gbps~100Gbps)
변경	소프트웨어로 가능	하드웨어 굳어짐, 수정 불가

네트워크 장비에서 패킷 포워딩, MAC 룩업, ACL 매칭, QoS 분류, Storm Control 카운팅은 다 ASIC이 담당합니다. CPU는 라우팅 프로토콜 연산·관리·예외 처리만 해요. 그래서 “이 기능은 ASIC이 한다 = 부하 거의 없다”가 성립합니다.

실제 Cisco 칩 이름 예시:

• Catalyst 2960/3750: EARL 시리즈
• Catalyst 9300/9500: UADP (Unified Access Data Plane)
• Nexus 9000: CloudScale

같은 의미로 Hardware switching ↔ Software switching 용어도 자주 씁니다 (하드웨어 = ASIC, 소프트웨어 = CPU).

자주 받는 질문: “모든 액세스 포트에 storm-control 걸면 스위치 CPU 안 죽어요?” — 결론은 거의 부하 없습니다. 이유는 하드웨어 ASIC 단에서 패킷 카운터를 돌리기 때문입니다.

ASIC이 입구에서 broadcast·multicast·unknown unicast 카운터를 돌리고, 임계값 초과 시 그 포트 방향만 차단하는 흐름. CPU는 위반 시점에만 syslog·SNMP trap 발사로 잠깐 끼어듦.

ASIC은 line-rate로 처리하니까 1Gbps든 100Gbps든 카운팅 자체는 무료. 다른 L2 보안 기능과 비교하면 차이가 명확합니다:

진짜 CPU가 끼어드는 시점은 임계값을 넘어 위반이 발생할 때만 — syslog 생성, SNMP trap 발사, action shutdown이면 err-disable 처리. 평상시는 ASIC만 돌고 CPU는 잠잠합니다.

오히려 storm-control이 없으면 broadcast가 모든 포트에 flooding되면서 각 호스트 NIC·CPU가 같이 죽습니다. ASIC가 입구에서 막아주는 게 망 전체 부하로 보면 압도적으로 적어요. “보안 강화 + 운영 부담 없음”이 동시에 성립해서 현업 표준으로 자리잡은 이유입니다.

실 장비에서 ASIC 사용량 확인하기

진짜 ASIC이 얼마나 차 있는지 보고 싶다면 IOS-XE 기반 Catalyst(9000·3850·3650 등) 에서 다음 명령어로 들여다볼 수 있습니다:

! 모델 식별 → 데이터시트로 ASIC 종류 역추적
SW1# show inventory

! 포트 ↔ ASIC 매핑 (어느 포트가 어느 ASIC 칩에 묶였나)
SW1# show platform software fed switch active port summary

! ASIC TCAM 테이블 사용량 (MAC·라우트·ACL 등 자원 차 있는 정도)
SW1# show platform hardware fed switch active fwd-asic resource tcam utilization

마지막 명령 출력 예 (Catalyst 3850-24T, 정상 운영 상태):

CAM Utilization for ASIC [0]
 Table                       Max Values   Used Values
 Unicast MAC addresses       32768/512    26/22
 Connected routes            16384/7168   30/32
 QoS ACEs                    2560         86
 Security ACEs               3072         133
 Control Plane Entries       512          208       ← 40%

각 테이블이 70~80%를 넘기 시작하면 자원 압박 신호. Storm Control처럼 ASIC 룰을 추가하는 기능을 더 켜도 되는지 판단할 때 참고합니다. 일반적으로 액세스 스위치는 자원이 많이 비어 있어 storm-control 추가가 ASIC 자원에 큰 부담을 주지 않습니다.

4. 설정 예시

⚠️ 시뮬레이터 환경(IOSv) 주의

GNS3·EVE-NG·CML 등에서 흔히 쓰는 IOSv L2 이미지는 storm-control 명령을 지원하지 않습니다. 실제 Catalyst 스위치의 storm-control은 ASIC 단에서 패킷 카운팅을 하는데, 가상화 이미지로는 이 하드웨어 동작을 흉내내기 어려워서 빠진 것으로 보입니다.

인터페이스 모드에서 storm-control ? 입력 시 % Unrecognized command가 나오면 미지원 환경이에요. 확인:

SW1# show version | include System image

vios-l2-adventerprise... 이름이 보이면 IOSv L2. 실 장비라면 c2960-..., c3750-..., cat9k_iosxe... 등이 보입니다.

우회: 시뮬레이터에선 개념·명령어만 익히고, 실제 시연이 필요하면 Cisco Modeling Labs(CML)의 IOL 이미지나 실 Catalyst 장비를 쓰세요. L2 보안 5대 기둥(Port Security·DHCP Snooping·DAI·IPSG·BPDU Guard)은 IOSv에서 정상 동작합니다.

참고로 3장에서 본 ASIC 진단 명령(show platform hardware fed ..., show platform software fed ...)도 같은 이유로 IOSv에선 빈 응답이거나 더미 값입니다 — 진짜 ASIC이 없으니 의미 있는 출력이 나오지 않아요.

기본 설정 - 액세스 포트

SW1(config)# interface range gigabitEthernet 0/1 - 24
SW1(config-if-range)# storm-control broadcast level 1.00
SW1(config-if-range)# storm-control multicast level 2.00
SW1(config-if-range)# storm-control action shutdown

옵션 의미:

• level 1.00: 포트 대역폭의 1%를 초과하면 동작
• action shutdown: 초과 시 포트를 err-disabled로 전환 (errdisable recovery와 연동)
• action trap (기본): 로그/SNMP trap만 보내고 드롭만 수행 (포트는 살아있음)

단위 - pps(초당 패킷 수)로도 지정 가능

SW1(config-if)# storm-control broadcast level pps 1k

“초당 1,000 패킷을 초과하면 제한”. 이건 대역폭이 아니라 절대 패킷 수 기준입니다. 저속 링크 환경에 유용합니다.

절대값 + 복구 임계값 (rising/falling)

SW1(config-if)# storm-control broadcast level 1.00 0.50

• rising (1.00): 1%를 넘으면 차단 시작
• falling (0.50): 0.5% 아래로 내려오면 차단 해제

hysteresis 효과로 경계선에서 on/off 깜빡임을 방지합니다. 운영 안정성이 올라가는 꿀팁.

📎 hysteresis(히스테리시스) 효과란?

한국어로 “이력 현상”. 어떤 상태가 켜지는 임계값과 꺼지는 임계값을 일부러 다르게 둬서 경계선 근처 진동을 막는 기법입니다.

에어컨 비유 — 만약 정확히 22°C에서 컴프레서를 켜고 끄게 만들면:

21.99°C → OFF → 22.01°C → ON → 21.99°C → OFF → ON → ... 1초에 수십 번 반복

컴프레서가 깜빡거리며 수명 박살. 그래서 실제 에어컨은:

• 22.5°C에서 켜짐 (rising)
• 21.5°C에서 꺼짐 (falling)

이 1°C 갭이 hysteresis. 한 번 켜지면 진짜로 식을 때까지 끄지 않고, 한 번 꺼지면 진짜 더워질 때까지 켜지 않음.

Storm Control에서: rising 1.00 / falling 0.50을 두면, 트래픽이 1% 근처에서 진동해도 0.5% 아래로 떨어져야 차단 해제. 만약 두 값이 같으면 0.99%↔1.01% 진동에 syslog·SNMP trap·err-disable 토글이 폭주합니다.

같은 원리가 쓰이는 다른 예: 온도조절기, 슈미트 트리거(전자회로), STP forward delay(시간 기반), BGP route flap damping. 핵심은 “경계선에서 떨고 있는 시스템을 안정시키는 표준 패턴”.

5. 확인 명령어

현재 설정 상태

SW1# show storm-control
Interface  Filter State     Upper        Lower        Current
---------  -------------    -----------  -----------  -----------
Gi0/1      Forwarding       1.00%        1.00%        0.00%
Gi0/2      Forwarding       1.00%        1.00%        0.00%

Current가 Upper에 근접하면 스톰 전조 신호입니다.

타입별로 확인

SW1# show storm-control broadcast
SW1# show storm-control multicast
SW1# show storm-control unicast

6. Storm Control을 어디에 걸어야 하나?

기본 원칙은 단순합니다 — 사용자 PC가 붙는 모든 액세스 포트에는 거의 무조건 걸자입니다. 회의실 LAN, 사무실 데스크탑, IP 폰, 프린터까지. 이런 자리에서는 정상 트래픽 중 브로드캐스트가 1%를 넘는 경우가 거의 없으니, 임계값 박아두고 잊으면 됩니다. 서버 포트도 기본적으로는 걸어주는 게 좋습니다 — 다만 서버 종류에 따라 정상 멀티캐스트가 많을 수 있으니 그쪽만 임계값을 살짝 더 풀어주는 식으로 조정하세요.

문제가 되는 자리는 트렁크 포트입니다. 트렁크는 여러 VLAN의 정상 트래픽이 한꺼번에 흐르기 때문에, 액세스 포트와 같은 임계값을 잡으면 평상시 운영에서 자동 차단이 자주 발생해요. 굳이 걸려면 broadcast는 그대로 1%로 두되 multicast는 5~10%로 넉넉히 분리해서 잡거나, 아예 트렁크는 빼고 액세스만 거는 게 무난합니다. 비슷한 맥락으로 IPTV·영상회의·실시간 방송 시스템이 많은 환경에서는 멀티캐스트가 정상적으로도 많이 흐르니, 멀티캐스트 임계값을 더 높이거나 storm-control을 아예 건너뛰기도 합니다. L3 스위치의 업링크 포트도 같은 이유로 신중해야 합니다 — OSPF·EIGRP의 라우팅 업데이트나 HSRP·VRRP의 게이트웨이 이중화 메시지가 전부 멀티캐스트로 흐르기 때문에 너무 빡빡한 임계값을 걸면 정상 컨트롤 트래픽이 차단됩니다.

절대 걸면 안 되는 자리도 있습니다. 포트 미러링(SPAN)의 destination 포트가 그 자리예요. 분석 장비로 보내는 미러 트래픽은 의도적으로 모든 트래픽이 몰리는 자리입니다. 여기에 storm-control을 걸면 운영자가 트래픽 분석하려는 순간 포트가 차단돼 버려요. 분석 자체를 막아버리는 셈이라 절대 안 됩니다. 다만 SPAN source 포트는 일반 액세스 포트와 동일하게 걸어도 무관합니다 — 미러는 source 포트의 ingress 처리가 아니라 별도 메커니즘으로 복사되기 때문에 storm-control 동작에 영향을 주지 않아요.

7. 현업 적용 시 주의점

action shutdown은 양날의 검입니다

action shutdown을 걸어두면 스톰이 한 번 발동되는 순간 해당 포트가 완전히 err-disabled로 내려갑니다. 네트워크가 자연스럽게 복구되더라도 포트는 여전히 죽어 있어요. 운영자가 수동으로 no shutdown을 쳐주거나, 전역 설정으로 자동 복구를 미리 걸어둬야 합니다.

SW1(config)# errdisable recovery cause storm-control
SW1(config)# errdisable recovery interval 300

이건 5분 뒤 자동 복구 설정. 보안 엄격성을 우선한다면 수동 복구를 유지하고, 운영 편의를 우선한다면 자동 복구로 가는 거죠. 둘 사이의 트레이드오프는 정답이 따로 있는 게 아니라 조직 정책에 따라 결정하시면 됩니다. 금융권·정부망은 수동 쪽이 많고, 일반 기업 사무실은 자동 쪽이 많습니다.

잘못 설정하면 정상 업무가 끊깁니다

현업에서 가장 자주 듣는 사고 패턴 하나 — “보안 설정했다가 영업부 VoIP 전화 다 터졌어요.” 멀쩡히 운영되던 회사망에서 운영자가 storm-control을 잘못 박은 다음 날 아침, 영업부 출근하자마자 전화가 안 됩니다. 알고 보니 SIP 시그널링과 VoIP 멀티캐스트가 평소에도 임계값에 가깝게 흐르고 있었던 거죠.

IPTV, VoIP 시그널링, Zoom·Teams 같은 대규모 회의 솔루션은 멀티캐스트와 브로드캐스트를 생각보다 많이 씁니다. 평소 비율을 모르고 임계값을 너무 빡빡하게 잡으면 정상 통화가 차단당해버려요. 그래서 적용 전에 반드시 트래픽 프로파일링을 해야 합니다.

SW1# show interfaces gigabitEthernet 0/1 counters broadcast
SW1# show interfaces gigabitEthernet 0/1 counters multicast

며칠 데이터를 모아서 평균과 피크 둘 다 확인한 다음, 그 값의 2~3배 여유를 두고 임계값을 설정하는 게 안전합니다. “1%가 권장값이래”라고 무작정 박지 말고 우리 환경의 실측을 기반으로 잡으세요.

로깅 없으면 의미 없습니다

action을 shutdown으로 두든 trap으로 두든, Syslog와 SNMP trap은 반드시 같이 걸어둬야 합니다. Storm Control이 발동된 순간을 놓치면 “왜 그 포트가 죽어 있지?”라는 원인 분석부터 막히고, 사고 재현도 어려워요. 알림이 NMS로 올라가야 운영자가 인지하고 대응할 수 있습니다.

SW1(config)# logging trap warnings
SW1(config)# snmp-server enable traps storm-control
SW1(config)# snmp-server host <NMS IP> public

설정해놓고 잊고 살 수 있는 기능이긴 하지만, 발동되는 그 순간만큼은 운영자에게 즉시 알려야 합니다. 그래야 진짜 사고인지, 임계값 잘못 잡아서 오탐인지 빨리 판단할 수 있어요.

8. 완성형 액세스 포트 설정 (Storm Control 포함)

[[02_L2 Security Fundamentals]]의 배치 체크리스트에 Storm Control을 얹으면 이렇게 됩니다.

interface gigabitEthernet 0/1
 description to-USER-PC
 switchport mode access
 switchport access vlan 10
 switchport nonegotiate
 switchport port-security
 switchport port-security maximum 2
 switchport port-security mac-address sticky
 switchport port-security violation restrict
 spanning-tree portfast
 spanning-tree bpduguard enable
 ip verify source
 ip arp inspection limit rate 15
 storm-control broadcast level 1.00
 storm-control multicast level 2.00
 storm-control action shutdown
 no cdp enable

이 설정이 엔터프라이즈 액세스 포트의 현실적 기본값입니다. 감사에서도 이 수준이면 트집 잡을 구석이 거의 없습니다.

9. 결론

• Storm Control은 “공격”보다 “사고” 대응 기능입니다. 루프, 불량 NIC, 설정 실수로 발생하는 브로드캐스트 스톰을 포트 단위로 차단합니다.
• 브로드캐스트 1%, 멀티캐스트 2%, 유니캐스트 5% 가 일반적인 현업 출발점입니다. 환경에 맞춰 조정하세요.
• action shutdown은 엄격한 보안 환경, action trap은 운영 중심 환경으로 판단합니다.
• 트렁크 포트, SPAN 포트, 멀티캐스트 다용 환경에서는 임계값 조정 또는 생략을 고려하세요.
• Storm Control은 L2 보안 5대 기둥과 독립적이지만, 실무 체크리스트에는 반드시 포함됩니다. 감사에서도 단골 확인 항목입니다.
• 8장의 통합 코드 블록 한 묶음이 그 자체로 운영 표준입니다. Port Security · BPDU Guard · IPSG · DAI rate limit · Storm Control이 한 인터페이스 설정 안에 다 들어 있는 형태가 엔터프라이즈 액세스 포트의 골든 템플릿이에요.

브로드캐스트 스톰 한 번이면 수백 명이 업무를 멈추는 게 현실입니다. 5분 설정으로 그 위험을 막을 수 있다면 안 할 이유가 없습니다.