네트워크 장비 설정 자동화 완벽 가이드

GNS3 시뮬레이션 환경에서 Netmiko와 Nornir을 활용한 네트워크 장비 자동화 실무 가이드입니다. VLAN 설정부터 ACL 배포, SNMP 모니터링까지 초급 개발자도 쉽게 따라할 수 있도록 단계별로 설명합니다.

1. GNS3 네트워크 시뮬레이션 환경 구축

어느 날 김개발 씨가 네트워크팀 박시니어 선배에게 조언을 구했습니다. "선배님, 라우터 100대의 설정을 변경해야 하는데 하나씩 접속해서 바꿔야 하나요?" 박시니어 씨가 웃으며 답했습니다.

"아니요, 그럴 필요 없어요. 먼저 시뮬레이션 환경부터 만들어볼까요?"

GNS3는 가상으로 네트워크 장비를 구성하고 테스트할 수 있는 시뮬레이터입니다. 마치 레고 블록을 조립하듯이 라우터, 스위치를 배치하고 연결할 수 있습니다.

실제 장비 없이도 네트워크 구성을 실습하고 자동화 스크립트를 안전하게 테스트할 수 있는 환경을 제공합니다.

다음 코드를 살펴봅시다.

# GNS3 VM 설치 후 프로젝트 생성
# 필요한 패키지 설치
sudo apt-get update
sudo apt-get install python3-pip gns3-server gns3-gui

# GNS3 실행 및 Cisco IOS 이미지 추가
# Edit > Preferences > Dynamips > IOS routers > New
# 라우터 3대를 토폴로지에 배치하고 연결

# Python에서 GNS3 서버 접속 확인
import requests
gns3_server = "http://localhost:3080"
response = requests.get(f"{gns3_server}/v2/version")
print(f"GNS3 Server Version: {response.json()['version']}")

김개발 씨는 입사 2개월 차 DevOps 엔지니어입니다. 오늘 팀장님으로부터 전국 지점의 라우터 설정을 변경하라는 업무를 받았습니다.

장비 목록을 보니 무려 100대가 넘습니다. "이걸 하나씩 접속해서 설정을 바꾼다고요?" 막막함이 밀려왔습니다.

점심시간에 박시니어 선배에게 하소연했습니다. "선배님, 라우터 100대 설정 변경하는데 며칠 걸릴 것 같아요." 박시니어 씨가 커피를 한 모금 마시고는 웃으며 말했습니다.

"김개발 씨, 그래서 자동화가 필요한 거예요. 먼저 테스트 환경부터 만들어봅시다." 그렇다면 네트워크 자동화를 위한 테스트 환경은 어떻게 만들까요?

실제 라우터와 스위치를 수십 대 구매할 수는 없습니다. 비용도 비용이지만 공간도 문제입니다.

이럴 때 필요한 것이 바로 시뮬레이터입니다. 마치 비행기 조종사가 시뮬레이터로 연습하듯이, 네트워크 엔지니어도 가상 환경에서 먼저 테스트할 수 있습니다.

네트워크 시뮬레이터가 없던 시절에는 어땠을까요? 회사에서 실습용 장비를 별도로 구매해야 했습니다.

작은 스타트업에서는 엄두도 못 낼 일이었습니다. 더 큰 문제는 잘못된 설정을 테스트하다가 실제 네트워크를 다운시킬 위험이 있다는 점이었습니다.

한 번의 실수가 전사 네트워크 장애로 이어질 수 있었습니다. 바로 이런 문제를 해결하기 위해 GNS3가 등장했습니다.

GNS3를 사용하면 컴퓨터 한 대로 수십 대의 네트워크 장비를 가상으로 구성할 수 있습니다. 또한 실제 Cisco IOS를 그대로 사용하기 때문에 실무와 동일한 환경에서 테스트할 수 있습니다.

무엇보다 잘못 설정해도 실제 네트워크에 영향을 주지 않는다는 큰 이점이 있습니다. 설치 과정을 단계별로 살펴보겠습니다.

먼저 GNS3 공식 홈페이지에서 프로그램을 다운로드합니다. Windows, macOS, Linux 모두 지원됩니다.

설치 시 GNS3 VM도 함께 설치하는 것이 좋습니다. GNS3 VM은 실제 장비 이미지를 실행하는 가상 머신입니다.

다음으로 Cisco IOS 이미지를 추가해야 합니다. 이 부분이 중요한데, Cisco 공식 파트너사에서 제공받거나 개인 학습용 라이선스를 구매해야 합니다.

Edit 메뉴에서 Preferences로 들어가 Dynamips 섹션에서 IOS 이미지를 등록합니다. 이제 실제로 토폴로지를 만들어봅시다.

왼쪽 장비 목록에서 라우터를 드래그해서 캔버스에 배치합니다. 라우터 3대를 배치하고 케이블로 연결하면 기본적인 네트워크 구성이 완성됩니다.

마치 레고 블록을 조립하는 것처럼 직관적입니다. 실무에서는 어떻게 활용할까요?

예를 들어 전국 지점에 새로운 보안 정책을 적용해야 한다고 가정해봅시다. GNS3에서 지점 네트워크와 동일한 토폴로지를 구성하고, 자동화 스크립트를 먼저 테스트합니다.

문제없이 동작하는 것을 확인한 후에야 실제 장비에 적용하는 것입니다. 많은 기업의 네트워크팀에서 이런 방식으로 안전하게 작업합니다.

하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수는 너무 많은 장비를 한 번에 실행하는 것입니다.

GNS3는 실제 IOS를 에뮬레이션하기 때문에 CPU와 메모리를 많이 사용합니다. 컴퓨터 사양에 맞춰 적절한 개수의 장비만 실행해야 합니다.

일반적으로 8GB RAM에서는 라우터 5대 정도가 적당합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 도움으로 GNS3 환경을 구축한 김개발 씨는 신기한 듯 화면을 바라봤습니다. "와, 정말 실제 라우터처럼 동작하네요!" GNS3 환경을 제대로 구축하면 안전하게 네트워크 자동화를 학습하고 테스트할 수 있습니다.

여러분도 오늘 배운 내용으로 나만의 테스트 네트워크를 만들어 보세요.

실전 팁

💡 - GNS3 VM을 사용하면 성능이 더 좋습니다. 일반 설치보다 VM 설치를 권장합니다.

메모리가 부족하면 라우터 RAM 설정을 256MB로 낮춰보세요.
프로젝트를 자주 저장하세요. 시뮬레이터가 종종 불안정할 수 있습니다.

2. Netmiko로 네트워크 장비 접속

GNS3 환경을 구축한 김개발 씨가 다음 단계로 넘어가려 하자, 박시니어 선배가 말했습니다. "이제 Python으로 장비에 접속해 볼까요?" 김개발 씨는 의아했습니다.

"Python으로요? SSH 클라이언트로 접속하는 게 아니라고요?"

Netmiko는 네트워크 장비에 SSH로 접속하여 명령을 자동으로 실행할 수 있는 Python 라이브러리입니다. 마치 리모컨으로 TV를 조작하듯이, Python 코드로 라우터와 스위치를 제어할 수 있습니다.

Cisco, Juniper, Arista 등 다양한 벤더의 장비를 지원하며, 복잡한 SSH 연결 과정을 간단한 코드로 처리할 수 있습니다.

다음 코드를 살펴봅시다.

from netmiko import ConnectHandler

# 라우터 접속 정보 설정
router = {
    'device_type': 'cisco_ios',
    'host': '192.168.1.1',
    'username': 'admin',
    'password': 'cisco123',
    'port': 22,
}

# SSH 접속
connection = ConnectHandler(**router)

# 명령어 실행 및 결과 출력
output = connection.send_command('show ip interface brief')
print(output)

# 설정 명령어 실행
config_commands = ['interface GigabitEthernet0/0', 'ip address 10.0.0.1 255.255.255.0']
connection.send_config_set(config_commands)

# 연결 종료
connection.disconnect()

김개발 씨는 GNS3에서 라우터 3대를 실행해 놓았습니다. 이제 각 라우터에 접속해서 설정을 확인하고 변경해야 합니다.

일반적으로 PuTTY나 SecureCRT 같은 터미널 프로그램을 사용하겠지만, 박시니어 선배는 다른 방법을 제안했습니다. "김개발 씨, 터미널 프로그램으로 하나씩 접속하면 시간이 오래 걸려요.

우리는 개발자니까 코드로 자동화해봅시다." 선배의 말에 김개발 씨는 눈이 커졌습니다. "코드로 라우터에 접속한다고요?

그게 가능한가요?" 박시니어 선배가 노트북을 열며 말했습니다. "물론이죠.

Netmiko라는 멋진 도구가 있어요." 그렇다면 Netmiko는 정확히 무엇일까요? 쉽게 비유하자면, Netmiko는 네트워크 장비를 위한 자동 조종 장치와 같습니다.

자동차의 오토파일럿이 운전대를 대신 조작하듯이, Netmiko는 사람이 터미널에 입력할 명령어들을 자동으로 실행합니다. SSH 프로토콜의 복잡한 세부사항은 모두 감춰주고, 간단한 Python 코드만으로 장비를 제어할 수 있게 해줍니다.

Netmiko가 없던 시절에는 어땠을까요? 개발자들은 paramiko라는 저수준 SSH 라이브러리를 직접 사용해야 했습니다.

SSH 채널을 열고, 프롬프트를 기다리고, 출력을 파싱하는 모든 과정을 손수 코딩해야 했습니다. 코드가 길어지고 복잡했으며, 장비마다 프롬프트 형식이 달라서 예외 처리도 까다로웠습니다.

더 큰 문제는 에러 처리였습니다. 연결이 끊기거나 타임아웃이 발생하면 스크립트가 중단되기 일쑤였습니다.

바로 이런 문제를 해결하기 위해 Netmiko가 등장했습니다. Netmiko를 사용하면 복잡한 SSH 연결 로직을 단 몇 줄로 처리할 수 있습니다.

또한 Cisco, Juniper, Arista 등 주요 벤더의 장비 특성을 미리 파악하고 있어서 자동으로 적절한 방식으로 통신합니다. 무엇보다 간결한 API를 제공하여 초보자도 쉽게 사용할 수 있다는 큰 이점이 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 ConnectHandler를 import합니다.

이것이 Netmiko의 핵심 클래스입니다. 다음으로 라우터 접속 정보를 딕셔너리로 정의합니다.

device_type에는 장비 종류를, host에는 IP 주소를 입력합니다. ConnectHandler에 딕셔너리를 전달하면 자동으로 SSH 연결이 수립됩니다.

이 한 줄이 내부적으로 수십 줄의 SSH 로직을 처리합니다. 연결이 성공하면 send_command 메서드로 명령어를 실행할 수 있습니다.

show 명령어처럼 조회만 하는 경우에 사용합니다. 설정을 변경할 때는 send_config_set을 사용합니다.

자동으로 config 모드로 진입하고, 명령어들을 순서대로 실행한 후, 다시 일반 모드로 돌아옵니다. 마지막으로 disconnect로 연결을 깨끗하게 종료합니다.

실무에서는 어떻게 활용할까요? 예를 들어 전국 100개 지점의 라우터에서 인터페이스 상태를 확인해야 한다고 가정해봅시다.

Netmiko로 각 라우터에 순차적으로 접속하여 show 명령을 실행하고, 결과를 엑셀 파일로 저장하는 스크립트를 만들 수 있습니다. 수동으로 하면 하루 종일 걸릴 작업을 10분 만에 끝낼 수 있습니다.

많은 통신사와 대기업에서 이런 방식으로 일일 점검 작업을 자동화하고 있습니다. 하지만 주의할 점도 있습니다.

초보자들이 흔히 하는 실수는 비밀번호를 코드에 하드코딩하는 것입니다. 보안상 매우 위험합니다.

환경 변수나 설정 파일을 사용하여 민감한 정보를 관리해야 합니다. 또한 장비에 접속할 때 적절한 타임아웃을 설정해야 합니다.

기본값이 너무 짧으면 명령 실행 중에 연결이 끊길 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 코드를 따라 작성한 김개발 씨는 눈을 반짝이며 말했습니다. "와, 정말 자동으로 명령이 실행되네요!

이거 정말 유용한데요?" Netmiko를 제대로 이해하면 네트워크 장비 관리 업무를 획기적으로 자동화할 수 있습니다. 여러분도 오늘 배운 내용을 실제 환경에 적용해 보세요.

실전 팁

💡 - pip install netmiko로 간단히 설치할 수 있습니다.

비밀번호 대신 SSH 키 인증을 사용하면 더 안전합니다.
enable 모드가 필요한 경우 secret 파라미터를 추가하세요.

3. Nornir 프레임워크 이해

김개발 씨가 신이 나서 코드를 작성하다가 문제에 부딪혔습니다. "선배님, 라우터가 100대인데 이걸 하나씩 for 문으로 돌려야 하나요?" 박시니어 선배가 미소를 지으며 답했습니다.

"좋은 질문이에요. 그래서 Nornir를 사용하는 거죠."

Nornir는 네트워크 자동화를 위한 Python 프레임워크입니다. 마치 오케스트라 지휘자가 여러 악기를 동시에 지휘하듯이, Nornir는 수백 대의 네트워크 장비를 병렬로 제어합니다.

인벤토리 관리, 병렬 실행, 결과 집계 등 자동화에 필요한 모든 기능을 체계적으로 제공합니다.

다음 코드를 살펴봅시다.

from nornir import InitNornir
from nornir_netmiko.tasks import netmiko_send_command
from nornir_utils.plugins.functions import print_result

# Nornir 초기화 (config.yaml 파일 사용)
nr = InitNornir(config_file="config.yaml")

# 모든 장비에 명령 실행 (병렬 처리)
def get_interface_status(task):
    # 각 장비에서 인터페이스 상태 조회
    result = task.run(task=netmiko_send_command, command_string="show ip interface brief")
    return result

# 작업 실행
results = nr.run(task=get_interface_status)

# 결과 출력
print_result(results)

# 특정 그룹만 선택하여 실행
branch_routers = nr.filter(role="branch")
branch_results = branch_routers.run(task=get_interface_status)

김개발 씨는 Netmiko로 라우터 한 대에 접속하는 데 성공했습니다. 하지만 실무에서는 수십, 수백 대의 장비를 관리해야 합니다.

단순히 for 문을 돌려서 순차적으로 처리하면 너무 오래 걸립니다. 100대 라우터에 명령을 실행하는데 각각 10초씩 걸린다면 총 1000초, 즉 16분이 넘게 소요됩니다.

김개발 씨가 고민에 빠져 있을 때, 박시니어 선배가 다가왔습니다. "김개발 씨, 한 대씩 처리하면 시간이 너무 걸려요.

병렬로 처리해야죠." 김개발 씨는 고개를 갸우뚱했습니다. "병렬요?

멀티스레딩을 직접 구현해야 하나요?" "아니요, 그럴 필요 없어요. Nornir라는 프레임워크가 모든 걸 해줍니다." 그렇다면 Nornir는 정확히 무엇일까요?

쉽게 비유하자면, Nornir는 택배 물류 센터의 자동 분류 시스템과 같습니다. 택배 기사 한 명이 모든 물건을 직접 배달하는 대신, 자동 시스템이 여러 기사에게 동시에 물건을 분배하여 배송합니다.

이처럼 Nornir도 여러 장비에 작업을 동시에 분배하고, 결과를 수집하여 정리해줍니다. Nornir가 없던 시절에는 어땠을까요?

개발자들은 Python의 threading이나 multiprocessing 모듈을 직접 사용해야 했습니다. 스레드 풀을 만들고, 작업을 큐에 넣고, 결과를 취합하는 모든 과정을 손수 구현해야 했습니다.

코드가 복잡해지고, 에러 처리도 까다로웠습니다. 더 큰 문제는 장비 목록 관리였습니다.

100대의 라우터 정보를 어디에 어떻게 저장할지, IP 주소가 바뀌면 어떻게 업데이트할지 고민이 많았습니다. 바로 이런 문제를 해결하기 위해 Nornir가 등장했습니다.

Nornir를 사용하면 인벤토리 파일에 장비 정보를 체계적으로 관리할 수 있습니다. YAML 형식으로 호스트명, IP 주소, 접속 정보, 그룹 등을 정의하면 됩니다.

또한 작업을 자동으로 병렬 처리하여 실행 시간을 획기적으로 단축합니다. 무엇보다 플러그인 시스템을 통해 Netmiko, NAPALM 등 다양한 도구와 쉽게 연동할 수 있다는 큰 이점이 있습니다.

코드 구조를 단계별로 살펴보겠습니다. 먼저 InitNornir로 프레임워크를 초기화합니다.

config.yaml 파일에는 인벤토리 파일 경로, 병렬 처리 옵션 등이 정의되어 있습니다. 초기화가 완료되면 nr 객체가 생성됩니다.

다음으로 작업 함수를 정의합니다. get_interface_status 함수는 각 장비에서 실행될 작업을 담고 있습니다.

task.run을 호출하면 실제 Netmiko 명령이 실행됩니다. 이 함수는 각 장비마다 별도의 스레드에서 동시에 실행됩니다.

nr.run을 호출하면 마법이 일어납니다. Nornir가 인벤토리의 모든 장비에 대해 작업 함수를 병렬로 실행합니다.

100대 장비라도 거의 동시에 명령이 전달되므로 실행 시간은 가장 느린 장비 한 대의 시간과 거의 같습니다. filter 메서드를 사용하면 특정 조건의 장비만 선택할 수 있습니다.

예를 들어 "지점 라우터만", "서울 리전만" 같은 조건으로 필터링할 수 있습니다. 이것이 인벤토리 기반 관리의 핵심입니다.

실무에서는 어떻게 활용할까요? 예를 들어 전국 200개 지점의 라우터에 보안 패치를 적용해야 한다고 가정해봅시다.

Nornir로 모든 라우터에 동시에 새 IOS 이미지를 업로드하고, 재부팅을 예약할 수 있습니다. 순차 처리하면 몇 시간 걸릴 작업을 20분 만에 끝낼 수 있습니다.

실제로 통신사들은 야간 유지보수 시간에 이런 방식으로 대규모 장비를 업데이트합니다. 하지만 주의할 점도 있습니다.

초보자들이 흔히 하는 실수는 병렬 처리 개수를 제한하지 않는 것입니다. 1000대의 장비에 동시에 접속하면 네트워크와 컴퓨터 리소스가 부족할 수 있습니다.

config.yaml에서 num_workers 값을 적절히 설정해야 합니다. 일반적으로 20-50 정도가 안정적입니다.

또한 작업이 실패한 장비를 체크해야 합니다. 일부 장비가 다운되어 있거나 인증 실패가 발생할 수 있습니다.

results.failed_hosts로 실패한 장비 목록을 확인하고 별도로 처리해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

Nornir를 실행해본 김개발 씨는 감탄했습니다. "와, 100대 라우터가 거의 동시에 응답하네요!

이게 병렬 처리의 힘이군요." Nornir를 제대로 이해하면 대규모 네트워크 환경에서도 효율적으로 자동화 작업을 수행할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - hosts.yaml과 groups.yaml 파일로 인벤토리를 체계적으로 관리하세요.

num_workers를 조절하여 동시 접속 수를 제어할 수 있습니다.
results.failed_hosts로 실패한 장비를 확인하고 재시도 로직을 구현하세요.

4. VLAN 설정 자동화 playbook

어느 날 팀장님이 김개발 씨를 불렀습니다. "김 대리, 신규 사무실 30개 층에 각각 다른 VLAN을 설정해야 하는데 내일까지 가능할까요?" 김개발 씨는 식은땀이 났습니다.

하지만 이제는 Nornir가 있었습니다.

VLAN 설정 자동화는 스위치에 여러 개의 VLAN을 일괄적으로 생성하고 포트에 할당하는 작업입니다. 마치 아파트 각 층에 우편함을 설치하는 것처럼, 네트워크를 논리적으로 분리하여 보안과 관리를 향상시킵니다.

Nornir를 활용하면 수십 대의 스위치에 VLAN 설정을 동시에 배포할 수 있습니다.

다음 코드를 살펴봅시다.

from nornir import InitNornir
from nornir_netmiko.tasks import netmiko_send_config

# Nornir 초기화
nr = InitNornir(config_file="config.yaml")

def configure_vlans(task, vlan_data):
    # VLAN 설정 명령어 생성
    config_commands = []

    for vlan_id, vlan_name in vlan_data.items():
        config_commands.extend([
            f'vlan {vlan_id}',
            f'name {vlan_name}',
        ])

    # 포트에 VLAN 할당
    config_commands.extend([
        'interface GigabitEthernet0/1',
        'switchport mode access',
        'switchport access vlan 10',
    ])

    # 설정 적용
    result = task.run(task=netmiko_send_config, config_commands=config_commands)
    return result

# VLAN 정보 정의
vlans = {10: 'SALES', 20: 'ENGINEERING', 30: 'HR', 40: 'GUEST'}

# 모든 스위치에 VLAN 설정
results = nr.run(task=configure_vlans, vlan_data=vlans)

김개발 씨는 팀장님의 지시에 당황했습니다. 30개 층, 각 층마다 3대의 스위치, 총 90대의 스위치에 VLAN을 설정해야 합니다.

수동으로 하면 이틀은 걸릴 작업입니다. 하지만 김개발 씨는 이제 Nornir와 Netmiko를 알고 있었습니다.

김개발 씨가 자리에 앉아 코드를 작성하기 시작했습니다. 옆자리 이신입 사원이 물었습니다.

"선배님, 90대나 되는데 어떻게 내일까지 다 하실 거예요?" 김개발 씨가 자신 있게 답했습니다. "자동화하면 30분이면 돼요." 그렇다면 VLAN 자동화는 어떻게 구현할까요?

먼저 VLAN의 개념을 이해해야 합니다. VLAN은 Virtual LAN의 약자로, 물리적으로는 같은 스위치에 연결되어 있지만 논리적으로는 분리된 네트워크입니다.

마치 한 건물 안에서도 층별로 출입 카드를 달리하는 것과 같습니다. 영업팀은 10층, 개발팀은 20층처럼 분리하여 보안을 강화할 수 있습니다.

VLAN 자동화가 없던 시절에는 어땠을까요? 네트워크 관리자가 각 스위치에 일일이 접속하여 명령어를 입력해야 했습니다.

"vlan 10", "name SALES"를 90번 반복해야 했습니다. 더 큰 문제는 오타였습니다.

피곤한 상태에서 반복 작업을 하다 보면 VLAN 번호를 잘못 입력하거나 이름을 틀리게 쓰는 실수가 발생했습니다. 이런 실수는 나중에 네트워크 문제로 이어졌습니다.

바로 이런 문제를 해결하기 위해 VLAN 설정 자동화가 필요합니다. 자동화를 사용하면 VLAN 정보를 딕셔너리나 YAML 파일에 정의하고, 모든 스위치에 동일하게 배포할 수 있습니다.

또한 설정 템플릿을 재사용하여 나중에 새로운 지점이 생겨도 쉽게 적용할 수 있습니다. 무엇보다 사람의 실수를 없앨 수 있다는 큰 이점이 있습니다.

코드의 핵심 부분을 분석해보겠습니다. configure_vlans 함수는 각 스위치에서 실행될 작업을 정의합니다.

먼저 빈 리스트 config_commands를 만들고, vlan_data 딕셔너리를 순회하며 VLAN 생성 명령어를 추가합니다. for 문을 사용하여 여러 개의 VLAN을 한 번에 처리합니다.

다음으로 특정 포트에 VLAN을 할당하는 명령어를 추가합니다. "switchport mode access"는 해당 포트를 액세스 모드로 설정하고, "switchport access vlan 10"은 VLAN 10에 할당합니다.

실무에서는 포트 정보도 인벤토리에서 가져와서 동적으로 생성합니다. netmiko_send_config는 Netmiko의 send_config_set을 Nornir 작업으로 래핑한 것입니다.

자동으로 config 모드로 진입하고, 모든 명령을 실행한 후, 변경사항을 저장합니다. 실무에서는 더 복잡한 시나리오가 있습니다.

예를 들어 트랙크 포트 설정이 필요할 수 있습니다. 스위치 간 연결에는 여러 VLAN 트래픽이 함께 지나가야 하므로 "switchport mode trunk"를 사용합니다.

또한 allowed VLAN 리스트를 지정하여 보안을 강화합니다. 코드로 구현하면 이렇습니다.

인벤토리에 각 스위치의 업링크 포트 정보를 저장하고, 해당 포트에는 trunk 설정을, 일반 포트에는 access 설정을 적용합니다. 조건문으로 포트 타입을 구분하여 다른 명령어를 생성하면 됩니다.

설정 검증도 중요합니다. VLAN을 생성한 후에는 실제로 잘 적용되었는지 확인해야 합니다.

"show vlan brief" 명령으로 VLAN 목록을 조회하고, 예상한 VLAN이 모두 존재하는지 검증합니다. Python의 정규표현식을 사용하여 출력을 파싱하고, 누락된 VLAN이 있으면 경고를 출력합니다.

하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수는 기존 설정을 확인하지 않고 무조건 새로 생성하는 것입니다.

이미 존재하는 VLAN에 다른 이름을 덮어쓰면 문제가 발생할 수 있습니다. 따라서 먼저 "show vlan" 으로 기존 설정을 조회하고, 없는 경우에만 생성하는 로직이 필요합니다.

또한 VLAN 번호 범위를 체크해야 합니다. Cisco 스위치는 VLAN 1-4094까지 지원하지만, 1, 1002-1005는 예약되어 있습니다.

잘못된 VLAN 번호를 사용하면 설정이 실패합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

코드를 완성한 김개발 씨는 실행 버튼을 눌렀습니다. 30분 후, 90대의 스위치 모두에 VLAN이 설정되었습니다.

팀장님이 놀라며 물었습니다. "벌써 다 했어요?" 김개발 씨가 웃으며 답했습니다.

"자동화의 힘입니다." VLAN 설정 자동화를 제대로 구현하면 대규모 네트워크 구축 프로젝트도 빠르게 완료할 수 있습니다. 여러분도 오늘 배운 내용을 실전에 활용해 보세요.

실전 팁

💡 - VLAN 정보를 YAML 파일로 관리하면 유지보수가 쉽습니다.

trunk 포트와 access 포트 설정을 명확히 구분하세요.
설정 후 반드시 show vlan으로 검증하는 단계를 추가하세요.

5. ACL 규칙 일괄 배포

보안팀에서 긴급 공지가 왔습니다. "특정 IP 대역에서 악성 트래픽이 발견되었습니다.

모든 라우터에 차단 규칙을 즉시 적용해주세요." 김개발 씨는 침착하게 노트북을 열었습니다. "이제 이런 상황도 자동화로 처리할 수 있어요."

ACL 규칙 일괄 배포는 방화벽 정책을 여러 네트워크 장비에 동시에 적용하는 작업입니다. 마치 건물 모든 층의 출입문에 새로운 보안 규칙을 동시에 적용하는 것과 같습니다.

악성 IP 차단, 특정 포트 제한, 내부 네트워크 보호 등 다양한 보안 정책을 신속하게 배포할 수 있습니다.

다음 코드를 살펴봅시다.

from nornir import InitNornir
from nornir_netmiko.tasks import netmiko_send_config

nr = InitNornir(config_file="config.yaml")

def deploy_acl(task, acl_name, acl_rules):
    # ACL 설정 명령어 생성
    config_commands = [f'ip access-list extended {acl_name}']

    # 각 규칙 추가
    for seq, rule in enumerate(acl_rules, start=10):
        config_commands.append(f'{seq} {rule}')

    # 인터페이스에 ACL 적용
    config_commands.extend([
        'interface GigabitEthernet0/0',
        f'ip access-group {acl_name} in',
    ])

    # 설정 배포
    result = task.run(task=netmiko_send_config, config_commands=config_commands)
    return result

# ACL 규칙 정의
block_malicious = [
    'deny ip 192.168.100.0 0.0.0.255 any log',
    'deny tcp any any eq 23 log',
    'permit ip any any',
]

# 모든 라우터에 ACL 배포
results = nr.run(task=deploy_acl, acl_name='BLOCK_MALICIOUS', acl_rules=block_malicious)

김개발 씨의 메신저에 보안팀 박보안 님의 메시지가 떴습니다. "김개발님, 192.168.100.0/24 대역에서 DDoS 공격이 감지되었습니다.

전체 라우터에서 이 대역을 차단해주세요. 긴급입니다!" 일반적인 상황이라면 패닉에 빠질 만합니다.

회사에는 라우터가 150대나 있습니다. 하지만 김개발 씨는 침착했습니다.

지난주에 박시니어 선배에게 ACL 자동화를 배웠기 때문입니다. "괜찮아요.

10분이면 모든 라우터에 적용할 수 있어요." 그렇다면 ACL이란 무엇이며, 왜 자동화가 필요할까요? ACL은 Access Control List의 약자로, 네트워크 트래픽을 허용하거나 차단하는 규칙 목록입니다.

쉽게 비유하자면, 건물 경비실의 방문자 명단과 같습니다. 경비원이 명단을 보고 출입을 허가하거나 거부하듯이, 라우터는 ACL을 보고 패킷을 통과시키거나 차단합니다.

ACL 자동화가 없던 시절에는 어땠을까요? 보안 사고가 발생하면 네트워크팀 전체가 비상 소집되었습니다.

팀원들이 라우터 목록을 나눠 가지고, 각자 수십 대씩 접속하여 수동으로 ACL을 설정했습니다. 한 대당 5분씩 걸린다면 150대는 750분, 즉 12시간 이상 소요됩니다.

그동안 공격은 계속되고, 서비스는 마비됩니다. 더 큰 문제는 일관성이었습니다.

여러 사람이 나눠서 작업하다 보면 ACL 규칙을 조금씩 다르게 입력하는 경우가 있었습니다. 어떤 라우터는 log 옵션을 빠뜨리고, 어떤 라우터는 순서 번호가 달랐습니다.

이런 불일치는 나중에 트러블슈팅을 어렵게 만들었습니다. 바로 이런 문제를 해결하기 위해 ACL 규칙 일괄 배포가 필요합니다.

자동화를 사용하면 ACL 규칙을 코드로 정의하고, 모든 라우터에 동일하게 배포할 수 있습니다. 또한 배포 기록이 남기 때문에 나중에 "누가 언제 어떤 규칙을 적용했는지" 추적할 수 있습니다.

무엇보다 긴급 상황에서 신속하게 대응할 수 있다는 큰 이점이 있습니다. 코드의 작동 방식을 자세히 살펴보겠습니다.

deploy_acl 함수는 ACL 이름과 규칙 리스트를 매개변수로 받습니다. 먼저 "ip access-list extended" 명령으로 ACL을 생성합니다.

extended 타입을 사용하면 출발지/목적지 IP, 포트, 프로토콜 등 세밀한 제어가 가능합니다. 다음으로 enumerate 함수를 사용하여 각 규칙에 순서 번호를 부여합니다.

10부터 시작하여 10씩 증가합니다. 이렇게 하면 나중에 중간에 규칙을 추가하기 쉽습니다.

예를 들어 10번과 20번 사이에 15번을 추가할 수 있습니다. 첫 번째 규칙 "deny ip 192.168.100.0 0.0.0.255 any log"는 악성 IP 대역에서 오는 모든 트래픽을 차단합니다.

log 옵션을 붙이면 차단된 패킷이 시스로그에 기록되어 나중에 분석할 수 있습니다. 두 번째 규칙 "deny tcp any any eq 23 log"는 모든 Telnet 트래픽을 차단합니다.

Telnet은 암호화되지 않아 보안에 취약하므로 차단하는 것이 좋습니다. 마지막 규칙 "permit ip any any"는 명시적으로 허용된 트래픽을 통과시킵니다.

Cisco ACL은 기본적으로 암묵적 거부 정책이므로, 마지막에 허용 규칙을 추가하지 않으면 모든 트래픽이 차단됩니다. ACL을 생성한 후에는 인터페이스에 적용해야 합니다.

"ip access-group" 명령으로 GigabitEthernet0/0 인터페이스의 인바운드 방향에 ACL을 적용합니다. in은 인터페이스로 들어오는 트래픽, out은 나가는 트래픽을 의미합니다.

실무에서는 더 복잡한 시나리오가 있습니다. 예를 들어 시간 기반 ACL을 사용할 수 있습니다.

근무 시간에만 특정 서비스를 허용하거나, 야간에는 모든 외부 접속을 차단하는 정책을 구현할 수 있습니다. time-range 명령과 조합하여 사용합니다.

또한 오브젝트 그룹을 활용하면 ACL을 더 읽기 쉽게 만들 수 있습니다. IP 주소 목록을 "MALICIOUS_IPS"라는 이름으로 그룹화하고, ACL에서 이 이름을 참조합니다.

IP가 추가되거나 변경되어도 ACL 규칙 자체는 수정할 필요가 없습니다. 검증 단계도 필수입니다.

ACL을 배포한 후에는 "show ip access-lists" 명령으로 실제로 적용되었는지 확인합니다. 또한 "show ip interface"로 어떤 인터페이스에 어떤 ACL이 적용되었는지 검증합니다.

자동화 스크립트에 이런 검증 로직을 추가하면 더욱 안전합니다. 하지만 주의할 점도 있습니다.

초보자들이 흔히 하는 실수는 ACL 순서를 잘못 정하는 것입니다. ACL은 위에서 아래로 순차적으로 평가되므로, 가장 구체적인 규칙을 위에, 일반적인 규칙을 아래에 배치해야 합니다.

예를 들어 "permit ip any any"를 맨 위에 두면 아래의 모든 deny 규칙이 무시됩니다. 또한 방향을 잘못 설정하는 경우도 많습니다.

외부에서 들어오는 트래픽을 차단하려면 in 방향에 적용해야 합니다. out 방향에 적용하면 효과가 없습니다.

인터페이스의 역할과 트래픽 흐름을 정확히 이해해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

코드를 실행한 김개발 씨는 5분 후 박보안 님에게 메시지를 보냈습니다. "150대 라우터 모두에 ACL 적용 완료했습니다.

차단 로그는 시스로그 서버에서 확인하실 수 있습니다." 박보안 님이 놀라며 답했습니다. "벌써요?

대단하네요!" ACL 규칙 일괄 배포를 제대로 구현하면 보안 사고에 신속하게 대응할 수 있습니다. 여러분도 오늘 배운 내용을 실전에 활용해 보세요.

실전 팁

💡 - ACL 규칙은 YAML 파일로 관리하면 버전 관리가 쉽습니다.

log 옵션을 추가하여 차단된 트래픽을 기록하세요.
배포 전에 테스트 환경에서 먼저 검증하는 습관을 들이세요.

6. SNMP 설정 및 모니터링 연동

팀장님이 김개발 씨를 불렀습니다. "라우터들의 CPU와 트래픽을 실시간으로 모니터링하고 싶은데 가능할까요?" 김개발 씨는 고개를 끄덕였습니다.

"SNMP로 모니터링 시스템과 연동하면 됩니다."

SNMP 설정 및 모니터링 연동은 네트워크 장비의 상태 정보를 수집하고 모니터링 시스템과 연결하는 작업입니다. 마치 건물 전체에 센서를 설치하여 온도와 습도를 중앙에서 관리하는 것과 같습니다.

CPU 사용률, 인터페이스 트래픽, 에러 카운트 등 다양한 정보를 자동으로 수집하여 장애를 조기에 발견할 수 있습니다.

다음 코드를 살펴봅시다.

from nornir import InitNornir
from nornir_netmiko.tasks import netmiko_send_config, netmiko_send_command

nr = InitNornir(config_file="config.yaml")

def configure_snmp(task, community, location, contact):
    # SNMP 설정 명령어
    config_commands = [
        f'snmp-server community {community} RO',
        f'snmp-server location {location}',
        f'snmp-server contact {contact}',
        'snmp-server enable traps snmp linkdown linkup',
        'snmp-server enable traps cpu threshold',
        'snmp-server host 10.0.0.100 version 2c public',
    ]

    # 설정 적용
    task.run(task=netmiko_send_config, config_commands=config_commands)

    # 설정 검증
    result = task.run(task=netmiko_send_command, command_string='show snmp')
    return result

# 모든 라우터에 SNMP 설정
results = nr.run(
    task=configure_snmp,
    community='public',
    location='Seoul HQ',
    contact='netops@company.com'
)

김개발 씨가 입사한 지 3개월이 지났습니다. 이제 네트워크 자동화에도 자신감이 생겼습니다.

그런데 새로운 과제가 생겼습니다. 팀장님이 "장비 상태를 실시간으로 볼 수 있으면 좋겠다"고 말씀하신 것입니다.

김개발 씨는 박시니어 선배에게 조언을 구했습니다. "선배님, 라우터 150대의 CPU와 트래픽을 어떻게 모니터링해야 할까요?" 박시니어 선배가 웃으며 답했습니다.

"SNMP를 설정하고 Zabbix나 Prometheus 같은 모니터링 시스템과 연동하면 됩니다." 그렇다면 SNMP란 무엇일까요? SNMP는 Simple Network Management Protocol의 약자로, 네트워크 장비의 정보를 수집하고 관리하는 표준 프로토콜입니다.

쉽게 비유하자면, 네트워크 장비에 설치된 계측기와 같습니다. 자동차 계기판이 속도와 연료량을 보여주듯이, SNMP는 CPU 사용률, 메모리, 인터페이스 트래픽 등 다양한 정보를 제공합니다.

SNMP가 없던 시절에는 어떻게 모니터링했을까요? 관리자가 주기적으로 각 장비에 접속하여 "show" 명령어를 실행하고 화면을 눈으로 확인해야 했습니다.

문제는 이것이 실시간이 아니라는 점입니다. 밤에 CPU가 100%로 치솟아도 다음 날 아침에 접속하기 전까지는 알 수 없었습니다.

고객이 먼저 장애를 신고하는 경우도 많았습니다. 더 큰 문제는 추세 분석이 불가능하다는 점이었습니다.

트래픽이 점점 증가하고 있는지, CPU 사용률이 특정 시간대에 높아지는지 파악할 수 없었습니다. 데이터를 수집하고 그래프로 그리는 것은 꿈도 꾸지 못했습니다.

바로 이런 문제를 해결하기 위해 SNMP가 만들어졌습니다. SNMP를 사용하면 모니터링 시스템이 주기적으로 장비에 정보를 요청하고 자동으로 수집합니다.

또한 트랩 기능으로 장애가 발생하면 즉시 알림을 받을 수 있습니다. 무엇보다 수집된 데이터를 데이터베이스에 저장하여 장기적인 추세를 분석할 수 있다는 큰 이점이 있습니다.

코드를 단계별로 분석해보겠습니다. configure_snmp 함수는 SNMP 설정에 필요한 매개변수를 받습니다.

community는 SNMP 인증에 사용되는 문자열로, 일종의 비밀번호입니다. RO는 Read-Only를 의미하여 정보 조회만 가능하고 설정 변경은 불가능합니다.

location과 contact 정보를 설정하면 나중에 장비 위치와 담당자를 쉽게 파악할 수 있습니다. 대규모 환경에서는 "Seoul-B1-Rack03" 같은 상세한 위치 정보를 입력합니다.

snmp-server enable traps 명령은 특정 이벤트 발생 시 트랩을 전송하도록 설정합니다. linkdown과 linkup은 인터페이스가 다운되거나 올라올 때 알림을 보냅니다.

cpu threshold는 CPU 사용률이 임계값을 초과하면 알림을 보냅니다. snmp-server host 명령은 트랩을 받을 모니터링 서버를 지정합니다.

10.0.0.100이 Zabbix나 Prometheus 서버의 IP 주소입니다. version 2c는 SNMP 버전을 의미하며, v3를 사용하면 더 강력한 보안을 제공합니다.

설정 후에는 show snmp 명령으로 검증합니다. SNMP가 제대로 활성화되었는지, 어떤 community가 설정되었는지 확인할 수 있습니다.

모니터링 시스템과의 연동은 어떻게 할까요? Zabbix를 예로 들면, 웹 인터페이스에서 각 라우터를 호스트로 추가합니다.

SNMP 템플릿을 적용하면 자동으로 CPU, 메모리, 인터페이스 트래픽 등의 아이템이 생성됩니다. 이 아이템들이 주기적으로 데이터를 수집하여 그래프로 표시합니다.

Prometheus의 경우 SNMP Exporter를 사용합니다. SNMP Exporter가 장비에서 정보를 수집하면 Prometheus가 이를 스크랩하여 저장합니다.

Grafana로 대시보드를 만들면 실시간으로 모든 장비의 상태를 한눈에 볼 수 있습니다. 알림 설정도 중요합니다.

CPU 사용률이 80%를 넘으면 경고 알림을, 90%를 넘으면 위험 알림을 보내도록 설정합니다. 이메일, Slack, SMS 등 다양한 채널로 알림을 받을 수 있습니다.

김개발 씨 팀에서는 Slack 채널로 알림을 받아서 즉시 대응하고 있습니다. 실무에서는 보안도 고려해야 합니다.

SNMP v2c의 community string은 평문으로 전송되므로 도청 위험이 있습니다. 실제 운영 환경에서는 SNMP v3를 사용하는 것이 좋습니다.

v3는 암호화와 인증을 지원하여 훨씬 안전합니다. 또한 ACL로 SNMP 접근을 제한해야 합니다.

모니터링 서버의 IP만 SNMP에 접근할 수 있도록 설정합니다. 외부에서 무단으로 정보를 수집하는 것을 방지할 수 있습니다.

하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수는 너무 짧은 폴링 간격을 설정하는 것입니다.

1초마다 모든 장비를 폴링하면 네트워크와 CPU에 부담을 줄 수 있습니다. 일반적으로 1-5분 간격이 적절합니다.

중요한 메트릭만 짧은 간격으로, 나머지는 긴 간격으로 수집합니다. 또한 모니터링 시스템의 용량을 고려해야 합니다.

150대 장비에서 각각 100개의 메트릭을 수집하면 하루에 수백만 개의 데이터 포인트가 생성됩니다. 충분한 저장 공간과 처리 능력을 확보해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. SNMP 설정을 완료하고 Zabbix 대시보드를 띄운 김개발 씨는 뿌듯했습니다.

150대 라우터의 상태가 실시간으로 그래프에 표시되었습니다. 팀장님이 흡족한 표정으로 말했습니다.

"이제 장애가 발생하기 전에 미리 대응할 수 있겠군요." SNMP 설정과 모니터링 연동을 제대로 구현하면 네트워크 장애를 조기에 발견하고 안정적인 서비스를 제공할 수 있습니다. 여러분도 오늘 배운 내용을 실전에 활용해 보세요.

실전 팁

💡 - SNMP v3를 사용하면 보안이 훨씬 강화됩니다.

ACL로 모니터링 서버 IP만 SNMP 접근을 허용하세요.
폴링 간격을 적절히 설정하여 장비와 네트워크 부하를 관리하세요.

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#Python#GNS3#Netmiko#Nornir#NetworkAutomation#DevOps,네트워크,자동화

네트워크 장비 설정 자동화 완벽 가이드

# 네트워크 장비 설정 자동화 완벽 가이드 GNS3 시뮬레이션 환경에서 Netmiko와 Nornir을 활용한 네트워크 장비 자동화 실무 가이드입니다. VLAN 설정부터 ACL 배포, SNMP 모니터링까지 초급 개발자도 쉽게 따라할 수 있도록 단계별로 설명합니다. --- ## 목차 1. [GNS3_네트워크_시뮬레이션_환경_구축](#gns3-네트워크-시뮬레이션-환경-구축) 2. [Netmiko로_네트워크_장비_접속](#netmiko로-네트워크-장비-접속) 3. [Nornir_프레임워크_이해](#nornir-프레임워크-이해) 4. [VLAN_설정_자동화_playbook](#vlan-설정-자동화-playbook) 5. [ACL_규칙_일괄_배포](#acl-규칙-일괄-배포) 6. [SNMP_설정_및_모니터링_연동](#snmp-설정-및-모니터링-연동) --- ## 1. GNS3_네트워크_시뮬레이션_환경_구축 어느 날 김개발 씨가 네트워크팀 박시니어 선배에게 조언을 구했습니다. "선배님, 라우터 100대의 설정을 변경해야 하는데 하나씩 접속해서 바꿔야 하나요?" 박시니어 씨가 웃으며 답했습니다. "아니요, 그럴 필요 없어요. 먼저 시뮬레이션 환경부터 만들어볼까요?" **GNS3**는 가상으로 네트워크 장비를 구성하고 테스트할 수 있는 시뮬레이터입니다. 마치 레고 블록을 조립하듯이 라우터, 스위치를 배치하고 연결할 수 있습니다. 실제 장비 없이도 네트워크 구성을 실습하고 자동화 스크립트를 안전하게 테스트할 수 있는 환경을 제공합니다. 다음 코드를 살펴봅시다. ```python # GNS3 VM 설치 후 프로젝트 생성 # 필요한 패키지 설치 sudo apt-get update sudo apt-get install python3-pip gns3-server gns3-gui # GNS3 실행 및 Cisco IOS 이미지 추가 # Edit > Preferences > Dynamips > IOS routers > New # 라우터 3대를 토폴로지에 배치하고 연결 # Python에서 GNS3 서버 접속 확인 import requests gns3_server = "http://localhost:3080" response = requests.get(f"{gns3_server}/v2/version") print(f"GNS3 Server Version: {response.json()['version']}") ``` 김개발 씨는 입사 2개월 차 DevOps 엔지니어입니다. 오늘 팀장님으로부터 전국 지점의 라우터 설정을 변경하라는 업무를 받았습니다. 장비 목록을 보니 무려 100대가 넘습니다. "이걸 하나씩 접속해서 설정을 바꾼다고요?" 막막함이 밀려왔습니다. 점심시간에 박시니어 선배에게 하소연했습니다. "선배님, 라우터 100대 설정 변경하는데 며칠 걸릴 것 같아요." 박시니어 씨가 커피를 한 모금 마시고는 웃으며 말했습니다. "김개발 씨, 그래서 자동화가 필요한 거예요. 먼저 테스트 환경부터 만들어봅시다." 그렇다면 네트워크 자동화를 위한 테스트 환경은 어떻게 만들까요? 실제 라우터와 스위치를 수십 대 구매할 수는 없습니다. 비용도 비용이지만 공간도 문제입니다. 이럴 때 필요한 것이 바로 **시뮬레이터**입니다. 마치 비행기 조종사가 시뮬레이터로 연습하듯이, 네트워크 엔지니어도 가상 환경에서 먼저 테스트할 수 있습니다. 네트워크 시뮬레이터가 없던 시절에는 어땠을까요? 회사에서 실습용 장비를 별도로 구매해야 했습니다. 작은 스타트업에서는 엄두도 못 낼 일이었습니다. 더 큰 문제는 잘못된 설정을 테스트하다가 실제 네트워크를 다운시킬 위험이 있다는 점이었습니다. 한 번의 실수가 전사 네트워크 장애로 이어질 수 있었습니다. 바로 이런 문제를 해결하기 위해 **GNS3**가 등장했습니다. GNS3를 사용하면 컴퓨터 한 대로 수십 대의 네트워크 장비를 가상으로 구성할 수 있습니다. 또한 실제 Cisco IOS를 그대로 사용하기 때문에 실무와 동일한 환경에서 테스트할 수 있습니다. 무엇보다 잘못 설정해도 실제 네트워크에 영향을 주지 않는다는 큰 이점이 있습니다. 설치 과정을 단계별로 살펴보겠습니다. 먼저 GNS3 공식 홈페이지에서 프로그램을 다운로드합니다. Windows, macOS, Linux 모두 지원됩니다. 설치 시 GNS3 VM도 함께 설치하는 것이 좋습니다. GNS3 VM은 실제 장비 이미지를 실행하는 가상 머신입니다. 다음으로 Cisco IOS 이미지를 추가해야 합니다. 이 부분이 중요한데, Cisco 공식 파트너사에서 제공받거나 개인 학습용 라이선스를 구매해야 합니다. Edit 메뉴에서 Preferences로 들어가 Dynamips 섹션에서 IOS 이미지를 등록합니다. 이제 실제로 토폴로지를 만들어봅시다. 왼쪽 장비 목록에서 라우터를 드래그해서 캔버스에 배치합니다. 라우터 3대를 배치하고 케이블로 연결하면 기본적인 네트워크 구성이 완성됩니다. 마치 레고 블록을 조립하는 것처럼 직관적입니다. 실무에서는 어떻게 활용할까요? 예를 들어 전국 지점에 새로운 보안 정책을 적용해야 한다고 가정해봅시다. GNS3에서 지점 네트워크와 동일한 토폴로지를 구성하고, 자동화 스크립트를 먼저 테스트합니다. 문제없이 동작하는 것을 확인한 후에야 실제 장비에 적용하는 것입니다. 많은 기업의 네트워크팀에서 이런 방식으로 안전하게 작업합니다. 하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수는 너무 많은 장비를 한 번에 실행하는 것입니다. GNS3는 실제 IOS를 에뮬레이션하기 때문에 CPU와 메모리를 많이 사용합니다. 컴퓨터 사양에 맞춰 적절한 개수의 장비만 실행해야 합니다. 일반적으로 8GB RAM에서는 라우터 5대 정도가 적당합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 도움으로 GNS3 환경을 구축한 김개발 씨는 신기한 듯 화면을 바라봤습니다. "와, 정말 실제 라우터처럼 동작하네요!" GNS3 환경을 제대로 구축하면 안전하게 네트워크 자동화를 학습하고 테스트할 수 있습니다. 여러분도 오늘 배운 내용으로 나만의 테스트 네트워크를 만들어 보세요. **실전 팁** 💡 - GNS3 VM을 사용하면 성능이 더 좋습니다. 일반 설치보다 VM 설치를 권장합니다. - 메모리가 부족하면 라우터 RAM 설정을 256MB로 낮춰보세요. - 프로젝트를 자주 저장하세요. 시뮬레이터가 종종 불안정할 수 있습니다. --- ## 2. Netmiko로_네트워크_장비_접속 GNS3 환경을 구축한 김개발 씨가 다음 단계로 넘어가려 하자, 박시니어 선배가 말했습니다. "이제 Python으로 장비에 접속해 볼까요?" 김개발 씨는 의아했습니다. "Python으로요? SSH 클라이언트로 접속하는 게 아니라고요?" **Netmiko**는 네트워크 장비에 SSH로 접속하여 명령을 자동으로 실행할 수 있는 Python 라이브러리입니다. 마치 리모컨으로 TV를 조작하듯이, Python 코드로 라우터와 스위치를 제어할 수 있습니다. Cisco, Juniper, Arista 등 다양한 벤더의 장비를 지원하며, 복잡한 SSH 연결 과정을 간단한 코드로 처리할 수 있습니다. 다음 코드를 살펴봅시다. ```python from netmiko import ConnectHandler # 라우터 접속 정보 설정 router = { 'device_type': 'cisco_ios', 'host': '192.168.1.1', 'username': 'admin', 'password': 'cisco123', 'port': 22, } # SSH 접속 connection = ConnectHandler(**router) # 명령어 실행 및 결과 출력 output = connection.send_command('show ip interface brief') print(output) # 설정 명령어 실행 config_commands = ['interface GigabitEthernet0/0', 'ip address 10.0.0.1 255.255.255.0'] connection.send_config_set(config_commands) # 연결 종료 connection.disconnect() ``` 김개발 씨는 GNS3에서 라우터 3대를 실행해 놓았습니다. 이제 각 라우터에 접속해서 설정을 확인하고 변경해야 합니다. 일반적으로 PuTTY나 SecureCRT 같은 터미널 프로그램을 사용하겠지만, 박시니어 선배는 다른 방법을 제안했습니다. "김개발 씨, 터미널 프로그램으로 하나씩 접속하면 시간이 오래 걸려요. 우리는 개발자니까 코드로 자동화해봅시다." 선배의 말에 김개발 씨는 눈이 커졌습니다. "코드로 라우터에 접속한다고요? 그게 가능한가요?" 박시니어 선배가 노트북을 열며 말했습니다. "물론이죠. Netmiko라는 멋진 도구가 있어요." 그렇다면 Netmiko는 정확히 무엇일까요? 쉽게 비유하자면, Netmiko는 네트워크 장비를 위한 **자동 조종 장치**와 같습니다. 자동차의 오토파일럿이 운전대를 대신 조작하듯이, Netmiko는 사람이 터미널에 입력할 명령어들을 자동으로 실행합니다. SSH 프로토콜의 복잡한 세부사항은 모두 감춰주고, 간단한 Python 코드만으로 장비를 제어할 수 있게 해줍니다. Netmiko가 없던 시절에는 어땠을까요? 개발자들은 **paramiko**라는 저수준 SSH 라이브러리를 직접 사용해야 했습니다. SSH 채널을 열고, 프롬프트를 기다리고, 출력을 파싱하는 모든 과정을 손수 코딩해야 했습니다. 코드가 길어지고 복잡했으며, 장비마다 프롬프트 형식이 달라서 예외 처리도 까다로웠습니다. 더 큰 문제는 에러 처리였습니다. 연결이 끊기거나 타임아웃이 발생하면 스크립트가 중단되기 일쑤였습니다. 바로 이런 문제를 해결하기 위해 **Netmiko**가 등장했습니다. Netmiko를 사용하면 복잡한 SSH 연결 로직을 단 몇 줄로 처리할 수 있습니다. 또한 Cisco, Juniper, Arista 등 주요 벤더의 장비 특성을 미리 파악하고 있어서 자동으로 적절한 방식으로 통신합니다. 무엇보다 간결한 API를 제공하여 초보자도 쉽게 사용할 수 있다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 **ConnectHandler**를 import합니다. 이것이 Netmiko의 핵심 클래스입니다. 다음으로 라우터 접속 정보를 딕셔너리로 정의합니다. device_type에는 장비 종류를, host에는 IP 주소를 입력합니다. **ConnectHandler**에 딕셔너리를 전달하면 자동으로 SSH 연결이 수립됩니다. 이 한 줄이 내부적으로 수십 줄의 SSH 로직을 처리합니다. 연결이 성공하면 **send_command** 메서드로 명령어를 실행할 수 있습니다. show 명령어처럼 조회만 하는 경우에 사용합니다. 설정을 변경할 때는 **send_config_set**을 사용합니다. 자동으로 config 모드로 진입하고, 명령어들을 순서대로 실행한 후, 다시 일반 모드로 돌아옵니다. 마지막으로 disconnect로 연결을 깨끗하게 종료합니다. 실무에서는 어떻게 활용할까요? 예를 들어 전국 100개 지점의 라우터에서 인터페이스 상태를 확인해야 한다고 가정해봅시다. Netmiko로 각 라우터에 순차적으로 접속하여 show 명령을 실행하고, 결과를 엑셀 파일로 저장하는 스크립트를 만들 수 있습니다. 수동으로 하면 하루 종일 걸릴 작업을 10분 만에 끝낼 수 있습니다. 많은 통신사와 대기업에서 이런 방식으로 일일 점검 작업을 자동화하고 있습니다. 하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수는 비밀번호를 코드에 하드코딩하는 것입니다. 보안상 매우 위험합니다. **환경 변수**나 **설정 파일**을 사용하여 민감한 정보를 관리해야 합니다. 또한 장비에 접속할 때 적절한 타임아웃을 설정해야 합니다. 기본값이 너무 짧으면 명령 실행 중에 연결이 끊길 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 코드를 따라 작성한 김개발 씨는 눈을 반짝이며 말했습니다. "와, 정말 자동으로 명령이 실행되네요! 이거 정말 유용한데요?" Netmiko를 제대로 이해하면 네트워크 장비 관리 업무를 획기적으로 자동화할 수 있습니다. 여러분도 오늘 배운 내용을 실제 환경에 적용해 보세요. **실전 팁** 💡 - pip install netmiko로 간단히 설치할 수 있습니다. - 비밀번호 대신 SSH 키 인증을 사용하면 더 안전합니다. - enable 모드가 필요한 경우 secret 파라미터를 추가하세요. --- ## 3. Nornir_프레임워크_이해 김개발 씨가 신이 나서 코드를 작성하다가 문제에 부딪혔습니다. "선배님, 라우터가 100대인데 이걸 하나씩 for 문으로 돌려야 하나요?" 박시니어 선배가 미소를 지으며 답했습니다. "좋은 질문이에요. 그래서 Nornir를 사용하는 거죠." **Nornir**는 네트워크 자동화를 위한 Python 프레임워크입니다. 마치 오케스트라 지휘자가 여러 악기를 동시에 지휘하듯이, Nornir는 수백 대의 네트워크 장비를 병렬로 제어합니다. 인벤토리 관리, 병렬 실행, 결과 집계 등 자동화에 필요한 모든 기능을 체계적으로 제공합니다. 다음 코드를 살펴봅시다. ```python from nornir import InitNornir from nornir_netmiko.tasks import netmiko_send_command from nornir_utils.plugins.functions import print_result # Nornir 초기화 (config.yaml 파일 사용) nr = InitNornir(config_file="config.yaml") # 모든 장비에 명령 실행 (병렬 처리) def get_interface_status(task): # 각 장비에서 인터페이스 상태 조회 result = task.run(task=netmiko_send_command, command_string="show ip interface brief") return result # 작업 실행 results = nr.run(task=get_interface_status) # 결과 출력 print_result(results) # 특정 그룹만 선택하여 실행 branch_routers = nr.filter(role="branch") branch_results = branch_routers.run(task=get_interface_status) ``` 김개발 씨는 Netmiko로 라우터 한 대에 접속하는 데 성공했습니다. 하지만 실무에서는 수십, 수백 대의 장비를 관리해야 합니다. 단순히 for 문을 돌려서 순차적으로 처리하면 너무 오래 걸립니다. 100대 라우터에 명령을 실행하는데 각각 10초씩 걸린다면 총 1000초, 즉 16분이 넘게 소요됩니다. 김개발 씨가 고민에 빠져 있을 때, 박시니어 선배가 다가왔습니다. "김개발 씨, 한 대씩 처리하면 시간이 너무 걸려요. 병렬로 처리해야죠." 김개발 씨는 고개를 갸우뚱했습니다. "병렬요? 멀티스레딩을 직접 구현해야 하나요?" "아니요, 그럴 필요 없어요. Nornir라는 프레임워크가 모든 걸 해줍니다." 그렇다면 Nornir는 정확히 무엇일까요? 쉽게 비유하자면, Nornir는 **택배 물류 센터의 자동 분류 시스템**과 같습니다. 택배 기사 한 명이 모든 물건을 직접 배달하는 대신, 자동 시스템이 여러 기사에게 동시에 물건을 분배하여 배송합니다. 이처럼 Nornir도 여러 장비에 작업을 동시에 분배하고, 결과를 수집하여 정리해줍니다. Nornir가 없던 시절에는 어땠을까요? 개발자들은 Python의 **threading**이나 **multiprocessing** 모듈을 직접 사용해야 했습니다. 스레드 풀을 만들고, 작업을 큐에 넣고, 결과를 취합하는 모든 과정을 손수 구현해야 했습니다. 코드가 복잡해지고, 에러 처리도 까다로웠습니다. 더 큰 문제는 장비 목록 관리였습니다. 100대의 라우터 정보를 어디에 어떻게 저장할지, IP 주소가 바뀌면 어떻게 업데이트할지 고민이 많았습니다. 바로 이런 문제를 해결하기 위해 **Nornir**가 등장했습니다. Nornir를 사용하면 **인벤토리 파일**에 장비 정보를 체계적으로 관리할 수 있습니다. YAML 형식으로 호스트명, IP 주소, 접속 정보, 그룹 등을 정의하면 됩니다. 또한 작업을 자동으로 병렬 처리하여 실행 시간을 획기적으로 단축합니다. 무엇보다 **플러그인 시스템**을 통해 Netmiko, NAPALM 등 다양한 도구와 쉽게 연동할 수 있다는 큰 이점이 있습니다. 코드 구조를 단계별로 살펴보겠습니다. 먼저 **InitNornir**로 프레임워크를 초기화합니다. config.yaml 파일에는 인벤토리 파일 경로, 병렬 처리 옵션 등이 정의되어 있습니다. 초기화가 완료되면 nr 객체가 생성됩니다. 다음으로 **작업 함수**를 정의합니다. get_interface_status 함수는 각 장비에서 실행될 작업을 담고 있습니다. task.run을 호출하면 실제 Netmiko 명령이 실행됩니다. 이 함수는 각 장비마다 별도의 스레드에서 동시에 실행됩니다. **nr.run**을 호출하면 마법이 일어납니다. Nornir가 인벤토리의 모든 장비에 대해 작업 함수를 병렬로 실행합니다. 100대 장비라도 거의 동시에 명령이 전달되므로 실행 시간은 가장 느린 장비 한 대의 시간과 거의 같습니다. **filter** 메서드를 사용하면 특정 조건의 장비만 선택할 수 있습니다. 예를 들어 "지점 라우터만", "서울 리전만" 같은 조건으로 필터링할 수 있습니다. 이것이 인벤토리 기반 관리의 핵심입니다. 실무에서는 어떻게 활용할까요? 예를 들어 전국 200개 지점의 라우터에 보안 패치를 적용해야 한다고 가정해봅시다. Nornir로 모든 라우터에 동시에 새 IOS 이미지를 업로드하고, 재부팅을 예약할 수 있습니다. 순차 처리하면 몇 시간 걸릴 작업을 20분 만에 끝낼 수 있습니다. 실제로 통신사들은 야간 유지보수 시간에 이런 방식으로 대규모 장비를 업데이트합니다. 하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수는 병렬 처리 개수를 제한하지 않는 것입니다. 1000대의 장비에 동시에 접속하면 네트워크와 컴퓨터 리소스가 부족할 수 있습니다. config.yaml에서 **num_workers** 값을 적절히 설정해야 합니다. 일반적으로 20-50 정도가 안정적입니다. 또한 작업이 실패한 장비를 체크해야 합니다. 일부 장비가 다운되어 있거나 인증 실패가 발생할 수 있습니다. **results.failed_hosts**로 실패한 장비 목록을 확인하고 별도로 처리해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. Nornir를 실행해본 김개발 씨는 감탄했습니다. "와, 100대 라우터가 거의 동시에 응답하네요! 이게 병렬 처리의 힘이군요." Nornir를 제대로 이해하면 대규모 네트워크 환경에서도 효율적으로 자동화 작업을 수행할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - hosts.yaml과 groups.yaml 파일로 인벤토리를 체계적으로 관리하세요. - num_workers를 조절하여 동시 접속 수를 제어할 수 있습니다. - results.failed_hosts로 실패한 장비를 확인하고 재시도 로직을 구현하세요. --- ## 4. VLAN_설정_자동화_playbook 어느 날 팀장님이 김개발 씨를 불렀습니다. "김 대리, 신규 사무실 30개 층에 각각 다른 VLAN을 설정해야 하는데 내일까지 가능할까요?" 김개발 씨는 식은땀이 났습니다. 하지만 이제는 Nornir가 있었습니다. **VLAN 설정 자동화**는 스위치에 여러 개의 VLAN을 일괄적으로 생성하고 포트에 할당하는 작업입니다. 마치 아파트 각 층에 우편함을 설치하는 것처럼, 네트워크를 논리적으로 분리하여 보안과 관리를 향상시킵니다. Nornir를 활용하면 수십 대의 스위치에 VLAN 설정을 동시에 배포할 수 있습니다. 다음 코드를 살펴봅시다. ```python from nornir import InitNornir from nornir_netmiko.tasks import netmiko_send_config # Nornir 초기화 nr = InitNornir(config_file="config.yaml") def configure_vlans(task, vlan_data): # VLAN 설정 명령어 생성 config_commands = [] for vlan_id, vlan_name in vlan_data.items(): config_commands.extend([ f'vlan {vlan_id}', f'name {vlan_name}', ]) # 포트에 VLAN 할당 config_commands.extend([ 'interface GigabitEthernet0/1', 'switchport mode access', 'switchport access vlan 10', ]) # 설정 적용 result = task.run(task=netmiko_send_config, config_commands=config_commands) return result # VLAN 정보 정의 vlans = {10: 'SALES', 20: 'ENGINEERING', 30: 'HR', 40: 'GUEST'} # 모든 스위치에 VLAN 설정 results = nr.run(task=configure_vlans, vlan_data=vlans) ``` 김개발 씨는 팀장님의 지시에 당황했습니다. 30개 층, 각 층마다 3대의 스위치, 총 90대의 스위치에 VLAN을 설정해야 합니다. 수동으로 하면 이틀은 걸릴 작업입니다. 하지만 김개발 씨는 이제 Nornir와 Netmiko를 알고 있었습니다. 김개발 씨가 자리에 앉아 코드를 작성하기 시작했습니다. 옆자리 이신입 사원이 물었습니다. "선배님, 90대나 되는데 어떻게 내일까지 다 하실 거예요?" 김개발 씨가 자신 있게 답했습니다. "자동화하면 30분이면 돼요." 그렇다면 VLAN 자동화는 어떻게 구현할까요? 먼저 VLAN의 개념을 이해해야 합니다. **VLAN**은 Virtual LAN의 약자로, 물리적으로는 같은 스위치에 연결되어 있지만 논리적으로는 분리된 네트워크입니다. 마치 한 건물 안에서도 층별로 출입 카드를 달리하는 것과 같습니다. 영업팀은 10층, 개발팀은 20층처럼 분리하여 보안을 강화할 수 있습니다. VLAN 자동화가 없던 시절에는 어땠을까요? 네트워크 관리자가 각 스위치에 일일이 접속하여 명령어를 입력해야 했습니다. "vlan 10", "name SALES"를 90번 반복해야 했습니다. 더 큰 문제는 **오타**였습니다. 피곤한 상태에서 반복 작업을 하다 보면 VLAN 번호를 잘못 입력하거나 이름을 틀리게 쓰는 실수가 발생했습니다. 이런 실수는 나중에 네트워크 문제로 이어졌습니다. 바로 이런 문제를 해결하기 위해 **VLAN 설정 자동화**가 필요합니다. 자동화를 사용하면 VLAN 정보를 딕셔너리나 YAML 파일에 정의하고, 모든 스위치에 동일하게 배포할 수 있습니다. 또한 설정 템플릿을 재사용하여 나중에 새로운 지점이 생겨도 쉽게 적용할 수 있습니다. 무엇보다 사람의 실수를 없앨 수 있다는 큰 이점이 있습니다. 코드의 핵심 부분을 분석해보겠습니다. **configure_vlans** 함수는 각 스위치에서 실행될 작업을 정의합니다. 먼저 빈 리스트 config_commands를 만들고, vlan_data 딕셔너리를 순회하며 VLAN 생성 명령어를 추가합니다. for 문을 사용하여 여러 개의 VLAN을 한 번에 처리합니다. 다음으로 특정 포트에 VLAN을 할당하는 명령어를 추가합니다. "switchport mode access"는 해당 포트를 액세스 모드로 설정하고, "switchport access vlan 10"은 VLAN 10에 할당합니다. 실무에서는 포트 정보도 인벤토리에서 가져와서 동적으로 생성합니다. **netmiko_send_config**는 Netmiko의 send_config_set을 Nornir 작업으로 래핑한 것입니다. 자동으로 config 모드로 진입하고, 모든 명령을 실행한 후, 변경사항을 저장합니다. 실무에서는 더 복잡한 시나리오가 있습니다. 예를 들어 트랙크 포트 설정이 필요할 수 있습니다. 스위치 간 연결에는 여러 VLAN 트래픽이 함께 지나가야 하므로 "switchport mode trunk"를 사용합니다. 또한 allowed VLAN 리스트를 지정하여 보안을 강화합니다. 코드로 구현하면 이렇습니다. 인벤토리에 각 스위치의 업링크 포트 정보를 저장하고, 해당 포트에는 trunk 설정을, 일반 포트에는 access 설정을 적용합니다. 조건문으로 포트 타입을 구분하여 다른 명령어를 생성하면 됩니다. **설정 검증**도 중요합니다. VLAN을 생성한 후에는 실제로 잘 적용되었는지 확인해야 합니다. "show vlan brief" 명령으로 VLAN 목록을 조회하고, 예상한 VLAN이 모두 존재하는지 검증합니다. Python의 정규표현식을 사용하여 출력을 파싱하고, 누락된 VLAN이 있으면 경고를 출력합니다. 하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수는 기존 설정을 확인하지 않고 무조건 새로 생성하는 것입니다. 이미 존재하는 VLAN에 다른 이름을 덮어쓰면 문제가 발생할 수 있습니다. 따라서 먼저 "show vlan" 으로 기존 설정을 조회하고, 없는 경우에만 생성하는 로직이 필요합니다. 또한 VLAN 번호 범위를 체크해야 합니다. Cisco 스위치는 VLAN 1-4094까지 지원하지만, 1, 1002-1005는 예약되어 있습니다. 잘못된 VLAN 번호를 사용하면 설정이 실패합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 코드를 완성한 김개발 씨는 실행 버튼을 눌렀습니다. 30분 후, 90대의 스위치 모두에 VLAN이 설정되었습니다. 팀장님이 놀라며 물었습니다. "벌써 다 했어요?" 김개발 씨가 웃으며 답했습니다. "자동화의 힘입니다." VLAN 설정 자동화를 제대로 구현하면 대규모 네트워크 구축 프로젝트도 빠르게 완료할 수 있습니다. 여러분도 오늘 배운 내용을 실전에 활용해 보세요. **실전 팁** 💡 - VLAN 정보를 YAML 파일로 관리하면 유지보수가 쉽습니다. - trunk 포트와 access 포트 설정을 명확히 구분하세요. - 설정 후 반드시 show vlan으로 검증하는 단계를 추가하세요. --- ## 5. ACL_규칙_일괄_배포 보안팀에서 긴급 공지가 왔습니다. "특정 IP 대역에서 악성 트래픽이 발견되었습니다. 모든 라우터에 차단 규칙을 즉시 적용해주세요." 김개발 씨는 침착하게 노트북을 열었습니다. "이제 이런 상황도 자동화로 처리할 수 있어요." **ACL 규칙 일괄 배포**는 방화벽 정책을 여러 네트워크 장비에 동시에 적용하는 작업입니다. 마치 건물 모든 층의 출입문에 새로운 보안 규칙을 동시에 적용하는 것과 같습니다. 악성 IP 차단, 특정 포트 제한, 내부 네트워크 보호 등 다양한 보안 정책을 신속하게 배포할 수 있습니다. 다음 코드를 살펴봅시다. ```python from nornir import InitNornir from nornir_netmiko.tasks import netmiko_send_config nr = InitNornir(config_file="config.yaml") def deploy_acl(task, acl_name, acl_rules): # ACL 설정 명령어 생성 config_commands = [f'ip access-list extended {acl_name}'] # 각 규칙 추가 for seq, rule in enumerate(acl_rules, start=10): config_commands.append(f'{seq} {rule}') # 인터페이스에 ACL 적용 config_commands.extend([ 'interface GigabitEthernet0/0', f'ip access-group {acl_name} in', ]) # 설정 배포 result = task.run(task=netmiko_send_config, config_commands=config_commands) return result # ACL 규칙 정의 block_malicious = [ 'deny ip 192.168.100.0 0.0.0.255 any log', 'deny tcp any any eq 23 log', 'permit ip any any', ] # 모든 라우터에 ACL 배포 results = nr.run(task=deploy_acl, acl_name='BLOCK_MALICIOUS', acl_rules=block_malicious) ``` 김개발 씨의 메신저에 보안팀 박보안 님의 메시지가 떴습니다. "김개발님, 192.168.100.0/24 대역에서 DDoS 공격이 감지되었습니다. 전체 라우터에서 이 대역을 차단해주세요. 긴급입니다!" 일반적인 상황이라면 패닉에 빠질 만합니다. 회사에는 라우터가 150대나 있습니다. 하지만 김개발 씨는 침착했습니다. 지난주에 박시니어 선배에게 ACL 자동화를 배웠기 때문입니다. "괜찮아요. 10분이면 모든 라우터에 적용할 수 있어요." 그렇다면 ACL이란 무엇이며, 왜 자동화가 필요할까요? **ACL**은 Access Control List의 약자로, 네트워크 트래픽을 허용하거나 차단하는 규칙 목록입니다. 쉽게 비유하자면, 건물 경비실의 **방문자 명단**과 같습니다. 경비원이 명단을 보고 출입을 허가하거나 거부하듯이, 라우터는 ACL을 보고 패킷을 통과시키거나 차단합니다. ACL 자동화가 없던 시절에는 어땠을까요? 보안 사고가 발생하면 네트워크팀 전체가 비상 소집되었습니다. 팀원들이 라우터 목록을 나눠 가지고, 각자 수십 대씩 접속하여 수동으로 ACL을 설정했습니다. 한 대당 5분씩 걸린다면 150대는 750분, 즉 12시간 이상 소요됩니다. 그동안 공격은 계속되고, 서비스는 마비됩니다. 더 큰 문제는 **일관성**이었습니다. 여러 사람이 나눠서 작업하다 보면 ACL 규칙을 조금씩 다르게 입력하는 경우가 있었습니다. 어떤 라우터는 log 옵션을 빠뜨리고, 어떤 라우터는 순서 번호가 달랐습니다. 이런 불일치는 나중에 트러블슈팅을 어렵게 만들었습니다. 바로 이런 문제를 해결하기 위해 **ACL 규칙 일괄 배포**가 필요합니다. 자동화를 사용하면 ACL 규칙을 코드로 정의하고, 모든 라우터에 동일하게 배포할 수 있습니다. 또한 배포 기록이 남기 때문에 나중에 "누가 언제 어떤 규칙을 적용했는지" 추적할 수 있습니다. 무엇보다 긴급 상황에서 신속하게 대응할 수 있다는 큰 이점이 있습니다. 코드의 작동 방식을 자세히 살펴보겠습니다. **deploy_acl** 함수는 ACL 이름과 규칙 리스트를 매개변수로 받습니다. 먼저 "ip access-list extended" 명령으로 ACL을 생성합니다. extended 타입을 사용하면 출발지/목적지 IP, 포트, 프로토콜 등 세밀한 제어가 가능합니다. 다음으로 **enumerate** 함수를 사용하여 각 규칙에 순서 번호를 부여합니다. 10부터 시작하여 10씩 증가합니다. 이렇게 하면 나중에 중간에 규칙을 추가하기 쉽습니다. 예를 들어 10번과 20번 사이에 15번을 추가할 수 있습니다. 첫 번째 규칙 "deny ip 192.168.100.0 0.0.0.255 any log"는 악성 IP 대역에서 오는 모든 트래픽을 차단합니다. **log** 옵션을 붙이면 차단된 패킷이 시스로그에 기록되어 나중에 분석할 수 있습니다. 두 번째 규칙 "deny tcp any any eq 23 log"는 모든 Telnet 트래픽을 차단합니다. Telnet은 암호화되지 않아 보안에 취약하므로 차단하는 것이 좋습니다. 마지막 규칙 "permit ip any any"는 명시적으로 허용된 트래픽을 통과시킵니다. Cisco ACL은 기본적으로 **암묵적 거부** 정책이므로, 마지막에 허용 규칙을 추가하지 않으면 모든 트래픽이 차단됩니다. ACL을 생성한 후에는 **인터페이스에 적용**해야 합니다. "ip access-group" 명령으로 GigabitEthernet0/0 인터페이스의 인바운드 방향에 ACL을 적용합니다. in은 인터페이스로 들어오는 트래픽, out은 나가는 트래픽을 의미합니다. 실무에서는 더 복잡한 시나리오가 있습니다. 예를 들어 **시간 기반 ACL**을 사용할 수 있습니다. 근무 시간에만 특정 서비스를 허용하거나, 야간에는 모든 외부 접속을 차단하는 정책을 구현할 수 있습니다. time-range 명령과 조합하여 사용합니다. 또한 **오브젝트 그룹**을 활용하면 ACL을 더 읽기 쉽게 만들 수 있습니다. IP 주소 목록을 "MALICIOUS_IPS"라는 이름으로 그룹화하고, ACL에서 이 이름을 참조합니다. IP가 추가되거나 변경되어도 ACL 규칙 자체는 수정할 필요가 없습니다. **검증 단계**도 필수입니다. ACL을 배포한 후에는 "show ip access-lists" 명령으로 실제로 적용되었는지 확인합니다. 또한 "show ip interface"로 어떤 인터페이스에 어떤 ACL이 적용되었는지 검증합니다. 자동화 스크립트에 이런 검증 로직을 추가하면 더욱 안전합니다. 하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수는 ACL 순서를 잘못 정하는 것입니다. ACL은 위에서 아래로 순차적으로 평가되므로, 가장 구체적인 규칙을 위에, 일반적인 규칙을 아래에 배치해야 합니다. 예를 들어 "permit ip any any"를 맨 위에 두면 아래의 모든 deny 규칙이 무시됩니다. 또한 **방향**을 잘못 설정하는 경우도 많습니다. 외부에서 들어오는 트래픽을 차단하려면 in 방향에 적용해야 합니다. out 방향에 적용하면 효과가 없습니다. 인터페이스의 역할과 트래픽 흐름을 정확히 이해해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 코드를 실행한 김개발 씨는 5분 후 박보안 님에게 메시지를 보냈습니다. "150대 라우터 모두에 ACL 적용 완료했습니다. 차단 로그는 시스로그 서버에서 확인하실 수 있습니다." 박보안 님이 놀라며 답했습니다. "벌써요? 대단하네요!" ACL 규칙 일괄 배포를 제대로 구현하면 보안 사고에 신속하게 대응할 수 있습니다. 여러분도 오늘 배운 내용을 실전에 활용해 보세요. **실전 팁** 💡 - ACL 규칙은 YAML 파일로 관리하면 버전 관리가 쉽습니다. - log 옵션을 추가하여 차단된 트래픽을 기록하세요. - 배포 전에 테스트 환경에서 먼저 검증하는 습관을 들이세요. --- ## 6. SNMP_설정_및_모니터링_연동 팀장님이 김개발 씨를 불렀습니다. "라우터들의 CPU와 트래픽을 실시간으로 모니터링하고 싶은데 가능할까요?" 김개발 씨는 고개를 끄덕였습니다. "SNMP로 모니터링 시스템과 연동하면 됩니다." **SNMP 설정 및 모니터링 연동**은 네트워크 장비의 상태 정보를 수집하고 모니터링 시스템과 연결하는 작업입니다. 마치 건물 전체에 센서를 설치하여 온도와 습도를 중앙에서 관리하는 것과 같습니다. CPU 사용률, 인터페이스 트래픽, 에러 카운트 등 다양한 정보를 자동으로 수집하여 장애를 조기에 발견할 수 있습니다. 다음 코드를 살펴봅시다. ```python from nornir import InitNornir from nornir_netmiko.tasks import netmiko_send_config, netmiko_send_command nr = InitNornir(config_file="config.yaml") def configure_snmp(task, community, location, contact): # SNMP 설정 명령어 config_commands = [ f'snmp-server community {community} RO', f'snmp-server location {location}', f'snmp-server contact {contact}', 'snmp-server enable traps snmp linkdown linkup', 'snmp-server enable traps cpu threshold', 'snmp-server host 10.0.0.100 version 2c public', ] # 설정 적용 task.run(task=netmiko_send_config, config_commands=config_commands) # 설정 검증 result = task.run(task=netmiko_send_command, command_string='show snmp') return result # 모든 라우터에 SNMP 설정 results = nr.run( task=configure_snmp, community='public', location='Seoul HQ', contact='netops@company.com' ) ``` 김개발 씨가 입사한 지 3개월이 지났습니다. 이제 네트워크 자동화에도 자신감이 생겼습니다. 그런데 새로운 과제가 생겼습니다. 팀장님이 "장비 상태를 실시간으로 볼 수 있으면 좋겠다"고 말씀하신 것입니다. 김개발 씨는 박시니어 선배에게 조언을 구했습니다. "선배님, 라우터 150대의 CPU와 트래픽을 어떻게 모니터링해야 할까요?" 박시니어 선배가 웃으며 답했습니다. "SNMP를 설정하고 Zabbix나 Prometheus 같은 모니터링 시스템과 연동하면 됩니다." 그렇다면 SNMP란 무엇일까요? **SNMP**는 Simple Network Management Protocol의 약자로, 네트워크 장비의 정보를 수집하고 관리하는 표준 프로토콜입니다. 쉽게 비유하자면, 네트워크 장비에 설치된 **계측기**와 같습니다. 자동차 계기판이 속도와 연료량을 보여주듯이, SNMP는 CPU 사용률, 메모리, 인터페이스 트래픽 등 다양한 정보를 제공합니다. SNMP가 없던 시절에는 어떻게 모니터링했을까요? 관리자가 주기적으로 각 장비에 접속하여 "show" 명령어를 실행하고 화면을 눈으로 확인해야 했습니다. 문제는 이것이 **실시간**이 아니라는 점입니다. 밤에 CPU가 100%로 치솟아도 다음 날 아침에 접속하기 전까지는 알 수 없었습니다. 고객이 먼저 장애를 신고하는 경우도 많았습니다. 더 큰 문제는 **추세 분석**이 불가능하다는 점이었습니다. 트래픽이 점점 증가하고 있는지, CPU 사용률이 특정 시간대에 높아지는지 파악할 수 없었습니다. 데이터를 수집하고 그래프로 그리는 것은 꿈도 꾸지 못했습니다. 바로 이런 문제를 해결하기 위해 **SNMP**가 만들어졌습니다. SNMP를 사용하면 모니터링 시스템이 주기적으로 장비에 정보를 요청하고 자동으로 수집합니다. 또한 **트랩** 기능으로 장애가 발생하면 즉시 알림을 받을 수 있습니다. 무엇보다 수집된 데이터를 데이터베이스에 저장하여 장기적인 추세를 분석할 수 있다는 큰 이점이 있습니다. 코드를 단계별로 분석해보겠습니다. **configure_snmp** 함수는 SNMP 설정에 필요한 매개변수를 받습니다. community는 SNMP 인증에 사용되는 문자열로, 일종의 **비밀번호**입니다. RO는 Read-Only를 의미하여 정보 조회만 가능하고 설정 변경은 불가능합니다. location과 contact 정보를 설정하면 나중에 장비 위치와 담당자를 쉽게 파악할 수 있습니다. 대규모 환경에서는 "Seoul-B1-Rack03" 같은 상세한 위치 정보를 입력합니다. **snmp-server enable traps** 명령은 특정 이벤트 발생 시 트랩을 전송하도록 설정합니다. linkdown과 linkup은 인터페이스가 다운되거나 올라올 때 알림을 보냅니다. cpu threshold는 CPU 사용률이 임계값을 초과하면 알림을 보냅니다. **snmp-server host** 명령은 트랩을 받을 모니터링 서버를 지정합니다. 10.0.0.100이 Zabbix나 Prometheus 서버의 IP 주소입니다. version 2c는 SNMP 버전을 의미하며, v3를 사용하면 더 강력한 보안을 제공합니다. 설정 후에는 **show snmp** 명령으로 검증합니다. SNMP가 제대로 활성화되었는지, 어떤 community가 설정되었는지 확인할 수 있습니다. 모니터링 시스템과의 연동은 어떻게 할까요? Zabbix를 예로 들면, 웹 인터페이스에서 각 라우터를 호스트로 추가합니다. SNMP 템플릿을 적용하면 자동으로 CPU, 메모리, 인터페이스 트래픽 등의 **아이템**이 생성됩니다. 이 아이템들이 주기적으로 데이터를 수집하여 그래프로 표시합니다. Prometheus의 경우 **SNMP Exporter**를 사용합니다. SNMP Exporter가 장비에서 정보를 수집하면 Prometheus가 이를 스크랩하여 저장합니다. Grafana로 대시보드를 만들면 실시간으로 모든 장비의 상태를 한눈에 볼 수 있습니다. **알림 설정**도 중요합니다. CPU 사용률이 80%를 넘으면 경고 알림을, 90%를 넘으면 위험 알림을 보내도록 설정합니다. 이메일, Slack, SMS 등 다양한 채널로 알림을 받을 수 있습니다. 김개발 씨 팀에서는 Slack 채널로 알림을 받아서 즉시 대응하고 있습니다. 실무에서는 **보안**도 고려해야 합니다. SNMP v2c의 community string은 평문으로 전송되므로 도청 위험이 있습니다. 실제 운영 환경에서는 **SNMP v3**를 사용하는 것이 좋습니다. v3는 암호화와 인증을 지원하여 훨씬 안전합니다. 또한 **ACL**로 SNMP 접근을 제한해야 합니다. 모니터링 서버의 IP만 SNMP에 접근할 수 있도록 설정합니다. 외부에서 무단으로 정보를 수집하는 것을 방지할 수 있습니다. 하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수는 너무 짧은 **폴링 간격**을 설정하는 것입니다. 1초마다 모든 장비를 폴링하면 네트워크와 CPU에 부담을 줄 수 있습니다. 일반적으로 1-5분 간격이 적절합니다. 중요한 메트릭만 짧은 간격으로, 나머지는 긴 간격으로 수집합니다. 또한 모니터링 시스템의 **용량**을 고려해야 합니다. 150대 장비에서 각각 100개의 메트릭을 수집하면 하루에 수백만 개의 데이터 포인트가 생성됩니다. 충분한 저장 공간과 처리 능력을 확보해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. SNMP 설정을 완료하고 Zabbix 대시보드를 띄운 김개발 씨는 뿌듯했습니다. 150대 라우터의 상태가 실시간으로 그래프에 표시되었습니다. 팀장님이 흡족한 표정으로 말했습니다. "이제 장애가 발생하기 전에 미리 대응할 수 있겠군요." SNMP 설정과 모니터링 연동을 제대로 구현하면 네트워크 장애를 조기에 발견하고 안정적인 서비스를 제공할 수 있습니다. 여러분도 오늘 배운 내용을 실전에 활용해 보세요. **실전 팁** 💡 - SNMP v3를 사용하면 보안이 훨씬 강화됩니다. - ACL로 모니터링 서버 IP만 SNMP 접근을 허용하세요. - 폴링 간격을 적절히 설정하여 장비와 네트워크 부하를 관리하세요. --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: DevOps,네트워크,자동화

언어: Python

태그: Python, GNS3, Netmiko, Nornir, NetworkAutomation, DevOps,네트워크,자동화

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

네트워크 장비 설정 자동화 완벽 가이드

목차

1. GNS3 네트워크 시뮬레이션 환경 구축

2. Netmiko로 네트워크 장비 접속

3. Nornir 프레임워크 이해

4. VLAN 설정 자동화 playbook

5. ACL 규칙 일괄 배포

6. SNMP 설정 및 모니터링 연동

이 카드뉴스가 포함된 코스

서버 운영 기본: 30분 복구 자동화 완전 정복

댓글 (0)

함께 보면 좋은 카드 뉴스

Helm 마이크로서비스 패키징 완벽 가이드

보안 아키텍처 구성 완벽 가이드

AWS Organizations 완벽 가이드

AWS KMS 암호화 완벽 가이드

AWS Secrets Manager 완벽 가이드