우리는 우리가 생각하는 것이 됩니다

[Cisco WLC] AP Mode 종류

KIMJOORI — Wed, 1 Apr 2026 15:05:24 +0900

Cisco Wireless 환경에서는 AP(Access Point)가 단순히 무선 신호만 뿌려주는 장비가 아닙니다. 네 네트워크 설계 목적과 트래픽 처리 방식에 따라 다양한 AP Mode를 선택할 수 있으며, 이는 무선 인프라의 성능과 안정성에 결정적인 역할을 합니다.

이번 글에서는 Cisco AP Mode의 종류와 특징을 정리해 보겠습니다.

1. Local Mode

가장 기본적인 AP 모드입니다.

Client → AP → (CAPWAP Tunnel) → WLC → Network

트래픽이 AP에서 바로 나가지 않고 WLC를 통해 처리됩니다. 이 방식을 Central Switching이라고 합니다.

2. FlexConnect Mode

특히 원격 지점(Branch)의 Local AP를 본사 WLC에 연결할 때 사용합니다.

Client → AP → Local Switch → Network

Local Switching 하여 트래픽이 WLC까지 가지 않고 AP Level에서 바로 처리됩니다.

3. Monitor Mode

일반 AP처럼 와이파이 서비스 제공용이 아니라, 무선 보안 모니터링 전용 모드입니다.

이벤트 확인이나 악성 AP 탐지용 Sensor 장비로 동작합니다.

4. Sniffer Mode

AP를 무선 패킷 캡처 장비로 사용하는 모드입니다.

근처의 AP 트래픽을 탐지하여 와이어샤크와 같은 응용 프로그램으로 PC에서 캡처할 수 있습니다.

5. Mesh or Bridge Mode

유선 연결이 어려운 환경에서 AP끼리 무선으로 연결하는 방식입니다. 특정 채널로 Mesh Root AP와 연결합니다.

Point-to-Point 또는 Point-to-Multi-Point 통한 Bridge 구성을 통해 네트워크 커버리지를 물리적 제약 없이 확장합니다.

AP Mode 요약 비교

Mode	역할	특징
Local	기본 모드	Central Switching
Monitor	보안 감시	Rogue AP 탐지
FlexConnect	지점용	Local Switching
Sniffer	패킷 분석	와이어샤크 캡처
Mesh	무선 Bridge	유선 없이 AP 연결

끝.

C9800 WLC Redundancy System (HA)

KIMJOORI — Wed, 1 Apr 2026 14:08:23 +0900

기업 무선 네트워크에서 WLC(Wireless LAN Controller)는 모든 AP와 무선 정책을 중앙에서 제어하는 핵심 장비입니다. 따라서 WLC의 장애는 전체 무선 서비스 중단으로 이어질 수 있습니다. 이를 방지하기 위해 Active/Standby 이중화 구조를 제공합니다.

1. 주요 이중화 구성 요소 - RP, RMI, GW Check

C9800 이중화 시스템은 단순히 컨트롤러 두 대를 연결하는 것이 아니라, 다음과 같은 3단계 상태 체크 메커니즘을 사용합니다.

RP → 물리 장비 상태 확인
RMI → 네트워크 경로 상태 확인
GW Check → 실제 서비스 가능 상태 확인

즉, 물리 상태 → 네트워크 상태 → 서비스 상태까지 확인하는 구조입니다.

1) RP Port (Redundancy Port)

두 컨트롤러 간의 직접 연결되는 물리적 이중화 인터페이스입니다. 즉, Active WLC와 Standby WLC가 서로 상태 정보를 교환하는 전용 링크입니다.

2) RMI (Redundancy Management Interface)

관리 네트워크를 통해 수행되는 논리적 상태 확인 경로입니다. 즉, RP가 직접 연결이라면 RMI는 네트워크를 통한 간접 확인입니다.

RP가 끊어졌다고 해서 상대 장비가 죽었다고 단정할 수 없습니다. 이때 RMI Check를 통해 Dual Active 상태(Split Brain)를 방지합니다.

3) Default Gateway Check

WLC가 실제 서비스를 제공할 수 있는지 확인하는 기능입니다. 즉, 단순히 장비가 살아있는지 보는 것이 아니라 서비스 가능 여부를 확인합니다. 1초 간격으로 게이트웨이에 ICMP Ping을 전송합니다.

만약 RP 정상, CLI 접속 가능한 상황인데 Core Switch가 down 상태인 경우 클라이언트 트래픽이 외부로 나가지 못하기 때문에 장비는 살아 있지만 서비스 불능 상태입니다. 이러학 개념을 해결하기 위한 기능입니다.

2. RP + RMI + Gateway Check를 같이 쓰는 이유

RP, RMI, GW 세 가지 체크를 함께 사용하는 이유는 잘못된 Active 판단 방지와 서비스 가용성 확보 때문입니다.

체크 항목	확인 대상	목적
RP Check	장비 자체 생존	상태 동기화 및 Failover 준비
RMI Check	네트워크 경로	Split Brain 방지
GW Check	서비스 경로	Network isolation 방지

RP만 보면 장비 상태만 알 수 있습니다.
RMI까지 보면 네트워크 상태 확인 가능합니다.
Gateway Check까지 보면 실제 서비스 가능 상태까지 확인 가능합니다.

이 3단계를 통해 보다 안정적인 HA를 구현할 수 있습니다.

3. 이중화 구조 - VSS, HSRP

상단 스위치의 구조는 WLC 이중화의 안정성에 영향을 미칩니다.

1) VSS (Virtual Switching System)

VSS

두 개의 물리 스위치가 하나의 논리 스위치처럼 동작합니다.

Split link란 Active와 Standby WLC가 서로 다른 상위 네트워크 경로를 가지는 상황입니다. VSS에서는 두 스위치가 하나처럼 동작하기 때문에 이런 경로 분리 위험이 줄어듭니다. (VSS Pair - No Split Links)

2) HSRP 구조

HSRP

물리적 스위치 두 대가 각각 존재하며 가상 IP를 공유합니다.

끝.

C9800 WLC 모델 비교 (C9800-L / 40 / 80)

KIMJOORI — Wed, 1 Apr 2026 10:28:30 +0900

일반 기업 환경에서는 AP가 많아도 약 500대 수준이므로 중규모 WLC를 사용하며, 대학 캠퍼스처럼 AP가 수천 대인 환경에서는 대규모 WLC가 사용됩니다.

1. C9800-L Series (L-F / L-C)

- 소규모용 Wireless Controller

- Max AP: 250, 500

- Max Client: 5000,10000

- Max Throughput: 5 Gbps, 10 Gbps

- Rack Mount 시 Mount Kit 필요

- Redundancy 지원 (HA)

- Cisco IOS XE Software 사용

- Uplink Interface

L-C: 2x1/10G Copper
L-F: 2x1/10G Fiber

Cisco C9800-L 시리즈는 성능 차이보다는 업링크 인터페이스 타입에 따라 모델이 구분됩니다.

C9800-L-C는 Copper(RJ-45) 포트를 사용하는 모델이며, C9800-L-F는 Fiber(SFP+) 포트를 사용하는 모델입니다.

2. C9800-40

- 중규모용 Wireless Controller

- Max Access Point: 2000

- Max Client: 32000

- Max Throughput: 40 Gbps

- 1RU Rack Form Factor

- Redundancy 지원 (HA)

- Cisco IOS XE Software 사용

- Uplink Interface: 4x1/10G

3. C9800-80

- 대규모용 Wireless Controller

- Max Access Point: 6000

- Max Client: 64000

- Max Throughput: 80 Gbps

- 2RU Rack Form Factor

- Redundancy 지원 (HA)

- Cisco IOS XE Software 사용

- Uplink Interface: 8x1/10G

[Cisco Nexus] NX-OS 업그레이드

KIMJOORI — Wed, 1 Apr 2026 09:52:50 +0900

1. NXOS 이미지 확인 및 bootflash로 파일 복사

NX-OS 업그레이드를 위해 먼저 USB에 있는 NXOS 이미지를 Nexus 장비 내부 storage(bootflash)로 복사해야 합니다.

dir usb1:  
copy usb1:nxos64-msll.10.5.4.M.bin bootflash:
dir bootflash:

2. 설정 저장 (업그레이드 전 필수 작업)

NX-OS 업그레이드를 진행하기 전 반드시 현재 설정을 저장해야 합니다.

현재 적용된 설정(running-config)을 재부팅 후에도 유지되도록 startup-config에 저장하는 작업입니다.

copy running-config startup

3. NXOS 업그레이드 진행

bootflash에 복사한 NXOS 이미지를 이용하여 업그레이드를 진행합니다.

중간에 설치 진행 여부가 나오면 y를 입력해 업그레이드를 진행하면 됩니다. 업그레이드가 완료되면 장비가 reboot 됩니다.

install all nxos bootflash:nxos64-ms11.10.5.4.M.bin

4. 기존 NXOS 이미지 삭제

업그레이드 후 기존 이미지를 삭제하여 스토리지 공간을 확보하는 것이 좋습니다. delete 명령으로 삭제합니다.

dir | i bin

delete bootflash:nxos.9.3.8.bin

5. 업그레이드 버전 정보 확인 및 최종 저장

업그레이드 완료 후 버전을 확인하고, 마지막으로 설정을 다시 저장합니다.

show module
copy running-config startup-config

끝.

On-Premise WLC vs Cloud WLC 구조 (Central vs Local Switching)

KIMJOORI — Wed, 1 Apr 2026 09:34:00 +0900

기업 무선 네트워크는 컨트롤러 기반 아키텍처를 통해 다수의 AP를 중앙에서 효율적으로 관리하며 안정적인 무선 서비스를 제공합니다. 유선 네트워크와 달리 사용자는 물리적인 포트 연결 없이 AP Coverage 내에서 자유롭게 이동하며 네트워크를 사용할 수 있으며, 이러한 Mobility가 WLAN의 가장 큰 장점입니다.

기업 무선 네트워크의 기본적인 물리 구조는 다음과 같습니다.

Backbone(L3) - Access(L2 PoE Switch) - AP - Client

여기서 Access Switch는 AP 전원 공급을 위해 PoE(Power over Ethernet)를 사용하는 것이 일반적입니다.

이러한 구조에서 무선 네트워크 설계 시 가장 중요한 요소 중 하나는 WLC(Wireless LAN Controller)의 위치입니다.

WLC 위치에 따라 무선 네트워크 구조가 달라지며 운영 방식도 크게 달라집니다. 대표적인 구조는 크게 2가지입니다.

On-Premise WLC 구조 (Legacy Controller 구조)
Cloud WLC 구조 (Cloud Managed WLAN)

1. Legacy Controller 구조 (On-Premise WLC)

온프레미스 구조는 WLC가 기업 내부 네트워크(Core 또는 Distribution)에 위치하여 AP를 중앙에서 제어하는 전통적인 방식입니다. 이 구조에서는 AP가 독립적으로 동작하는 것이 아니라, WLC의 제어를 받습니다. 즉, AP는 무선 신호 송수신 역할을 담당하고, 인증/보안 정책/RF 관리 등 핵심 제어는 WLC에서 처리됩니다.

구조는 다음과 같습니다.

Client → AP → Access Switch → Backbone Switch → WLC → Firewall → Internet

이때 AP에서 WLC까지 사용자 데이터는 CAPWAP 터널로 캡슐화되어 전달됩니다. 이러한 구조를 Central Switching이라고 합니다. 즉, Control Traffic + Data Traffic 모두 WLC를 통과하는 구조입니다.

2. Cloud Controller 구조 (Cloud WLC)

Cloud WLC 구조는 WLC가 기업 내부가 아니라 Cloud 상에 위치하는 구조입니다. 이 구조에서는 기업 내부에는 AP만 존재하고 관리 기능은 Cloud Controller에서 수행됩니다. 즉, AP → Internet → Cloud WLC 형태로 관리 트래픽이 전달됩니다.

구조는 다음과 같습니다.

관리 경로: AP → Switch → Router → Internet → Cloud WLC
데이터 경로: Client → AP → Switch → Firewall → Internet

사용자 데이터는 Cloud를 거치지 않고 내부에서 바로 인터넷으로 나갑니다. 이러한 구조를 Local Switching이라고 합니다.

끝.

[Wireless] Roaming (로밍)

KIMJOORI — Tue, 31 Mar 2026 11:00:29 +0900

Roaming이란 무엇인가

로밍은 STA(Station, 클라이언트)가 여러 BSS(Basic Servicd Set) 사이를 이동하면서 기존 네트워크 연결을 유지한 채 다른 AP로 연결을 전환하는 과정입니다. 즉, 사용자가 이동하면서 현재 AP 신호가 약해지면 더 좋은 신호를 가진 AP로 자동으로 연결을 변경합니다.

로밍은 기본적으로 Client-driven 방식으로 동작하며, 클라이언트가 신호 세기(RSSI), SNR, Noise 등의 무선 환경을 기반으로 로밍 시점을 판단합니다.

로밍 동작 과정은 다음과 같습니다.

로밍 프로세스

기본적인 로밍은 다음과 같은 단계로 이루어집니다.

1) Scanning (탐색): 현재 AP 신호가 약해지면 클라이언트는 주변의 새 AP 후보를 찾습니다.

2) Authentication (인증): 클라이언트는 대상 AP와 802.11 인증 메시지를 교환합니다.

3) Reassociation (재연결): 클라이언트는 이전 AP와의 연결을 끊고 새 AP로 결합(Association) 요청을 보냅니다.

4) 4-way handshake (키 교환): 데이터 암호화를 위한 고유 키인 PTK(Pairwise Transient Key)를 생성하고 교환합니다.

802.11r (Fast BSS Transition, FT)

일반 로밍에서는 새로운 AP 연결 시 보안 인증이 다시 수행되어 지연이 발생합니다. 이를 개선하기 위한 표준이 802.11r입니다.

802.11r

802.11r은 최초 인증 시 생성된 PMK-R0(Pairwise Master Key)라는 최상위 키를 기반으로 주변 AP들에 전달될 PMK-R1 키들을 미리 생성합니다. 따라서 로밍 시 전체 802.1X 인증을 다시 수행하지 않고 빠르게 연결됩니다.

일반적인 로밍에서는 새로운 AP로 이동할 때마다 802.1X 인증과 RADIUS 서버 통신이 다시 수행되지만, 802.11r에서는 RADIUS 서버까지 가지 않고도 컨트롤러나 AP 수준에서 이미 계산된 키(PMK-R1)를 가지고 있으므로 802.1X 인증 과정을 다시 수행하지 않습니다. 이를 통해 로밍 지연 시간을 크게 줄일 수 있으며 실시간 서비스(VoIP, 화상회의 등)에서도 안정적인 통신을 유지할 수 있습니다.

끝.

[Wireless] 802.11 WLAN 구조 - BSS, DS, ESS, MBSS

KIMJOORI — Tue, 31 Mar 2026 09:46:36 +0900

1. 802.11 BSS (Basic Service Set)

무선 네트워크의 가장 기본적인 단위로, 하나의 AP와 해당 AP에 연결된 무선 클라이언트로 구성된 논리적 서비스 영역입니다. 쉽게 말해, AP 하나가 제공하는 Wi-Fi 커버리지 영역 전체가 하나의 BSS입니다.

BSS

BSS는 SSID와 BSSID로 구성되어 있습니다.

SSID (Service Set Identifier): 무선 네트워크의 이름으로, 사용자가 Wi-Fi 검색 시 보이는 논리적 식별자입니다. 반드시 고유할 필요는 없고, ESS 구성 시 여러 AP가 동일 SSID 사용이 가능합니다.
BSSID (Basic Service Set Identifier): AP의 무선 인터페이스 (Radio Interface) MAC 주소로, 각 AP를 구분하는 물리적 식별자입니다. AP는 Beacon 프레임을 통해 BSSID를 광고하며, 클라이언트는 이를 통해 연결할 AP를 결정합니다. 동일 SSID라도 AP가 다르면 BSSID는 서로 다릅니다.

BSS는 단일 AP 기반 구조이므로 다음과 같은 한계가 존재합니다.

Coverage 문제: AP 하나의 신호만으로는 전체 층이나 건물을 커버할 수 없으므로 여러 개의 AP가 필요합니다.
Bandwidth 문제: 무선은 Half-Duplex(반이중, 동시 송수신 불가)로 동작하기 때문에 사용자가 많아질수록 속도가 감소합니다.

2. DS (Distribution System)

AP가 연결되는 유선 네트워크 인프라입니다. 802.11 표준에서는 AP가 연결되는 상위 유선 네트워크를 DS라고 부르며, 이를 통해 서로 다른 BSS(AP) 간 트래픽 전달 및 외부 인터넷 연결이 이루어집니다. 즉, DS는 무선 네트워크의 백본 역할을 합니다.

3. 802.11 ESS (Extended Service Set)

ESS

넓은 서비스 지역을 커버하기 위해 동일한 SSID를 가진 여러 개의 BSS를 하나의 DS에 연결한 구조입니다. 즉, 여러 AP에 같은 SSID를 설정하여 하나의 무선 네트워크처럼 동작하도록 만든 구조입니다.

예를 들어, 1번 AP(BSS 1)와 2번 AP(BSS 2)의 이름을 모두 'Office_WiFi'로 설정하고 유선망(DS)에 연결하면, 사용자는 이동 중에도 끊김 없이 하나의 네트워크처럼 사용하게 됩니다.

Roaming(로밍)

로밍은 사용자가 이동할 때 신호가 약해지면 자동으로 다른 AP로 재접속되는 과정입니다. 사용자는 현재 어느 AP에 연결되어 있는지 의식하지 않고 통신할 수 있습니다.

끊김 없는 로밍을 위해 인접 AP 간 신호 범위를 보통 15~20% 정도 겹치게 설계합니다. 각 AP는 자체 BSS를 제공하고 간섭 방지를 위해 서로 다른 채널을 사용합니다.

802.11 MBSS (Mesh Basic Service Set)

MBSS

유선 배선이 어려운 환경에서 AP들끼리 무선으로 연결하여 네트워크를 확장하는 방식입니다.

Mesh는 RAP과 MAP으로 구성되어 있습니다.

RAP (Root AP): 최소 하나 이상의 AP는 반드시 유선 스위치(DS)에 연결되어야 합니다. 전체 Mesh 네트워크의 관문 역할을 수행하며 무선으로 연결된 다른 AP들의 외부 인터넷으로 나가는 트래픽을 처리합니다.
MAP (Mesh AP): 유선 연결 없이 전원만 공급받아 설치됩니다. 무선 백 홀(Backhaul)을 통해 다른 RAP 또는 MAP와 연결됩니다. 백 홀은 AP와 AP 사이를 연결하는 무선 전용 링크입니다.

끝.

Cisco Meraki 솔루션 개요

KIMJOORI — Mon, 30 Mar 2026 16:17:51 +0900

왜 기업들이 Meraki를 사용하는가?

기존 IT 환경에서는 다음과 같은 한계가 존재합니다.

장비별 서로 다른 관리 환경
복잡한 운영 환경
네트워크 상태 가시성 부족
트래픽 및 사용자 데이터 분석 어려움

즉, 장비가 많아질수록 운영 복잡도가 증가하는 문제가 발생합니다. Meraki는 이러한 문제를 해결하기 위해 클라우드 기반 통합 관리 플랫폼으로 설계되었습니다.

Meraki는 기존 Cisco 장비처럼 CLI 중심으로 운영하는 방식이 아니라, 클라우드 기반 대시보드를 통해 전체 네트워크를 중앙 관리하는 솔루션입니다.

즉, 회사 전체 네트워크 인프라를 한 화면에서 운영하고 모니터링할 수 있는 플랫폼입니다. 특히 지점이 여러 곳이거나, 스위치, 방화벽, 무선 AP를 통합 관리해야 하는 환경에서 매우 효율적이기 때문에 기업 네트워크 환경에서 많이 사용하고 있습니다.

Meraki의 논리적 기본 구조

Meraki는 크게 Organization → Network → Device의 3단계 논리적 구조로 구성됩니다.

1) Organization (조직)

Organization은 가장 상위 개념으로, 기업 전체 네트워크를 의미합니다. 전체 관리 정책 및 공통 설정이 적용되는 영역입니다. 주요 관리 항목은 다음과 같습니다.

Admin: 관리자 계정 및 권한 관리
License: 라이선스 상태 및 만료 관리
Firmware: 펌웨어 버전 관리 및 업그레이드 설정

2) Network (네트워크)

Network는 지점이나 서비스 단위로 구성되는 논리적 그룹입니다.(예: 서울 본사, 부산 지사 등) 이 영역 안에 실제 운영되는 장비들이 포함됩니다. 대표 장비는 다음과 같습니다.

Switch
Firewall
AP(Access Point)

3) Device (장비)

Device는 실제로 현장에 설치되는 물리적인 네트워크 장비입니다. 주요 장비는 다음과 같습니다.

장비 종류	역할 및 기능
MX (Security Appliance & SD-WAN)	Router, Firewall, VPN, SD-WAN, NAT
MS (Switches)	VLAN, Trunk, STP, L3 Routing
MR (Wireless)	SSID, 인증, Guest WiFi, Roaming
MV ( Smart Camera )	클라우드 기반 보안 감시 및 영상 분석
MT (IOT Sensors)	IoT 환경 센서 (온도, 습도 등)

Meraki 핵심 특징

1) 운영 편의성

웹 브라우저 기반의 대시보드 제공
클라우드 기반 중앙관리 플랫폼 (관리/제어용 하드웨어 설치 불필요)

2) 확장성

제한 없는 성능 제공, 병목 현상 없는 구조 (Bottleneck-Free)
Zero Touch Provisioning: 장비에 전원과 인터넷만 연결하면 클라우드에서 수분 내 구축 가능

3) 신뢰성

다수의 데이터센터 운영을 통해 높은 가용성 제공
클라우드 대시보드(Control Plane) 접속 불가 시에도 네트워크(Data Plane) 정상 동작

4) 보안

어떠한 사용자 트래픽도 클라우드로 전송되지 않음
자동 펌웨어 및 보안 업데이트 지원 (업데이트 일정 설정 가능)

[Wireshark] ARP Packet 분석

KIMJOORI — Mon, 30 Mar 2026 13:42:59 +0900

ARP Request 패킷 분석

ping

ARP 패킷을 분석하기 위해 VPC에서 대상 IP로 Ping 테스트를 진행했습니다.

Ping을 수행하면 ICMP 패킷이 바로 전송되는 것이 아니라, 먼저 목적지 IP에 해당하는 MAC 주소를 알아내기 위한 ARP 과정이 선행됩니다.

ARP Request / Reply 확인

ARP Request/Reply 확인

Wireshark로 캡처한 결과 ARP Request와 ARP Reply 패킷 2개가 확인되었습니다.

No. 15 (ARP Request): "192.168.10.65의 MAC 주소가 무엇인지 192.168.10.66에게 알려줘"
No. 16 (ARP Reply): "내가 192.168.10.65이고, 내 MAC 주소는 aa:bb:cc:00:01:00이다"

즉, ARP는 IP 주소를 MAC 주소로 변환하기 위한 프로토콜입니다.

ARP Request 패킷 주요 필드 분석

Hardware type: Ethernet (1) → 현재 네트워크가 이더넷 기반 L2 네트워크임을 의미합니다.
Protocol type: IPv4 (0x0800) → ARP가 IPv4 주소를 MAC 주소로 변환하기 위한 프로토콜임을 나타냅니다.
Hardware size: 6 → MAC 주소 길이는 6바이트(48bit)
Protocol size: 4 → IP 주소 길이는 4바이트(32bit)
Opcode: request (1) → ARP Request 패킷임을 의미 (Reply는 2)
Sender 정보 → ARP 요청을 보내는 장비의 MAC(00:50:79:66:68:36)과 IP(192.168.10.66)
Target 정보 → 우리가 찾고자 하는 대상, IP는 192.168.10.65로 지정되어 있지만, Target MAC address는 브로드캐스트(ff:ff:ff:ff:ff:ff)로 설정되어 전송됩니다.

Target MAC 주소를 모르기 때문에 ARP는 네트워크 내의 모든 장비에게 물어봐야 하므로 Destination MAC 주소를 브로드캐스트 주소(ff:ff:ff:ff:ff:ff)로 설정하여 전송합니다.

ARP Request/Reply 과정이 끝나면 송신자(10.66)는 자신의 ARP Table(ARP Cache)에 192.168.10.65 -> aa:bb:cc:00:01:00 정보를 저장합니다. 이후 동일 대상과 통신할 때는 ARP Request를 다시 수행하지 않고 저장된 MAC 정보를 사용하여 바로 통신합니다.

ARP 동작 흐름 (ARP → ICMP)

1) Ping 실행

2) ARP Request Broadcast 전송

3) ARP Reply 수신

4) ARP Table 저장

5) ICMP Echo Request 전송

6) ICMP Echo Reply 수신

끝.

OSPF MD5 Authentication 설정 및 Wireshark 패킷 분석

KIMJOORI — Mon, 30 Mar 2026 11:17:08 +0900

OSPF MD5 인증 설정 (Cisco CLI)

설정할 인터페이스에 들어가서 아래 두 명령어를 통해 간단히 설정할 수 있습니다.

OSPF MD5 인증 설정

ip ospf authentication message-digest

→ 해당 인터페이스에서 OSPF MD5 인증 활성화

ip ospf message-digest-key 1 md5 joori

→ 인증 Key ID: 1, 암호화 방식: md5, Password: joori

인증 불일치 발생 시 Neighbor Down 확인

OSPF Neighbor 성립 조건 중 하나는 인증 방식(Type)과 키(Key)의 일치입니다.

한쪽 라우터에만 인증을 설정한 결과, 일정 시간 동안 유효한 Hello를 받지 못해 'Neighbor Down: Dead Timer Expired'가 발생하였고, show ip ospf neighbor 명령 결과 해당 네이버(2.2.2.2)가 사라진 것을 확인했습니다.

양쪽 장비 인터페이스에 모두 동일한 Key ID와 Password로 인증을 설정한 결과, Neighbor가 복구된 것을 확인할 수 있습니다.

Wireshark를 통한 MD5 인증 패킷 확인

인증이 적용된 OSPF 패킷을 와이어샤크로 뜯어보면, Authentication 필드가 아래와 같이 변경된 것을 확인할 수 있습니다.

Wireshark에서 OSPF 인증 확인

Auth Type: Cryptographic (2) → 숫자 '2'는 MD5 인증이 적용되었음을 의미
Auth Crypt Key id: 1 → 설정 시 입력한 Key ID 값
Auth Crypt Data Length: 16 → MD5 해시 결과물인 16byte(128bit) 데이터 길이
Auth Sequence Number → 패킷의 순서를 관리하여 Reply Attack(재전송 공격) 방지
Auth Crypt Data → 설정 시 입력한 패스워드가 포함된 실제 MD5 해시값

끝.