AI 에이전트로 Cisco 라우터의 OSPF 장애를 조사 및 복구해 보았다

서론

네트워크 장비의 트러블슈팅(Troubleshooting)에서는 여러 대에 로그인하여 show 명령어를 실행하고, 출력 내용을 비교하며 원인을 좁혀나가는 경우가 자주 있습니다.

하지만 한 대씩 확인하다 보면 은근히 힘이 듭니다.

• 어떤 show 명령어를 봐야 할지 고민함
• 여러 대의 출력을 대조함
• OSPF나 BGP 상태를 통해 의심스러운 부분을 좁힘
• 필요하다면 설정을 변경하고, 변경 후의 상태를 확인함

이 기사에서는 OpenAI의 Codex로부터 MCP 서버인 ios-xe-mcp-server를 호출하여, Cisco IOS XE 라우터의 상태 확인, OSPF 분리 조사, 간단한 복구 작업까지 시도해 봅니다.

대상 독자는 Cisco IOS XE 라우터의 기본 조작이나 show 명령어, OSPF의 개요는 알고 있지만, Codex나 MCP 서버와의 연계는 이제부터 시도하려는 네트워크 엔지니어입니다.

AI 에이전트나 MCP 서버의 내부 구현을 깊게 파고들기보다는, "평소의 CLI 작업에 AI 에이전트를 도입하면 어디까지 맡길 수 있는가"를 검증합니다.

이 기사에서 다루는 내용은 다음과 같습니다.

• Codex에서 MCP 서버를 경유하여 Cisco IOS XE 라우터에 show 명령어를 실행한다
• 여러 대의 라우팅 정보를 한꺼번에 확인한다
• OSPF 네이버(Neighbor)가 형성되지 않은 부분을 조사한다
• 원인 지점에 설정을 투입하여 복구 확인까지 수행한다

AI 에이전트를 네트워크 운용에서 사용하는 이미지

AI 에이전트를 사용하면 네트워크 엔지니어가 불필요해진다기보다, "조사 절차를 함께 진행할 상대"가 늘어나는 느낌에 가깝습니다.

예를 들어, 다음과 같은 의뢰를 할 수 있습니다.

라우터 172.16.200.101, 172.16.200.102, 172.16.200.103에서
OSPF 네이버가 형성되지 않은 부분이 있습니다.
문제 지점을 특정하여 수정해 주세요.

사람이라면 우선 show ip ospf neighbor,
show ip interface brief,
show ip ospf interface brief,
show running-config interface ...

정도를 확인할 것입니다.

Codex도 마찬가지로 필요한 명령어를 선택하고, 여러 대의 결과를 비교하며, 의심스러운 부분을 추가로 확인해 나갑니다.

이번 검증에서는 최종적으로 rt3의 Ethernet0/1이 shutdown 되어 있음을 특정하고, no shutdown을 투입하여 OSPF 네이버의 복구까지 확인할 수 있었습니다.

네트워크 엔지니어 관점에서는 다음과 같은 사용법이 현실적이라고 느꼈습니다.

사용법	예시
상태 확인 보조	여러 대의 show ip route나 show ip ospf neighbor를 모아서 요약함
...

특히 편리한 점은 "하나의 명령어 결과만 보는" 것이 아니라, "여러 명령어 결과를 연관 지어 설명해 준다"는 점입니다.

사람이 판단하기 위한 재료 수집과 1차 정리를 맡긴다는 사용법이 적절해 보입니다.

검증 환경

이번에는 Cisco Modeling Labs (CML) 상의 Cisco IOS XE 라우터에, WSL 상의 Ubuntu 환경에서 SSH로 접속하여 검증하고 있습니다 (2026년 6월 17일 시점).

항목	버전	비고
Cisco IOS XE	17.18.2	CML 상에서 동작시키고 있는 가상 라우터
...

검증 환경에서는 라우터와 Codex 실행 환경을 관리 세그먼트 172.16.200.0/24에 연결해 두었습니다.

라우터에는 Ubuntu에서 SSH로 로그인할 수 있는 상태로 만들어 두었습니다.

검증 대상인 Cisco IOS XE 라우터는 다음 3대입니다.

IP 주소	호스트 이름	용도
172.16.200.101	rt1	rt1은 rt2와 연결
...

CML/WSL 검증 환경은 아래 기사에서 작성하였으므로 참고하시기 바랍니다.

전체 구성

먼저, 이번에 등장하는 도구들의 역할입니다.

요소	역할
Codex	사람의 의뢰를 받아 필요한 확인 명령어와 다음 작업을 생각하는 AI 에이전트
...

이번 흐름은 다음과 같습니다.

• ios-xe-mcp-server

를 실행 - Codex에 MCP 서버를 등록한다

• Codex에서 MCP 도구를 호출한다
• MCP 서버가 Netmiko를 통해 Cisco IOS XE 라우터로 SSH 접속한다
• Codex가 획득한 결과를 읽고, 다음 확인이나 수정을 진행한다

이미지로 표현하자면, Codex가 직접 라우터에 로그인하는 것이 아니라 MCP 서버를 경유합니다.

MCP 서버가 라우터에 SSH로 로그인하여, show 명령어나 설정 명령어를 실행합니다.

ios-xe-mcp-server가 제공하는 주요 도구는 다음 두 가지입니다.

MCP 도구	할 수 있는 일
show_command	Cisco IOS XE 라우터에 SSH 접속하여, 지정한 show 명령어를 실행한다
config_command	Cisco IOS XE 라우터에 SSH 접속하여, 지정한 설정 명령어를 입력한다

IOS_XE_READ_ONLY=true로 설정하면, 설정 변경용인 config_command는 사용할 수 없게 됩니다.

먼저 읽기 전용으로 show_command만 테스트해 보고, 필요할 때 설정 변경을 허용하는 방식으로 진행하는 것이 안전합니다.

MCP 서버를 준비하기

먼저, MCP 서버로 동작하는 Python 스크립트 ios_xe_mcp_server.py를 로컬에서 실행합니다.

본래는 Docker에서 실행할 수 있지만, 이번에는 내용을 확인하기 쉽도록 Python 스크립트를 직접 실행합니다.

Python 실행 환경은 패키지 매니저인 uv로 준비했습니다.

uv 설치 방법

uv 설치 방법은 공식 사이트 등을 확인해 주세요.

여기서는 Ubuntu 26.04에 Python 3.14.6을 uv로 설치합니다.

# uv 설치
$ curl -LsSf https://astral.sh/uv/install.sh | sh
# 설치 가능한 Python 목록 표시
...

# GitHub 리포지토리 복사
$ git clone https://github.com/pamosima/network-mcp-docker-suite.git
$ cd network-mcp-docker-suite/ios-xe-mcp-server/
...

SSH로 로그인할 때의 인증 정보는 환경 변수에서 읽어옵니다.

이번에는 검증용으로 동일한 디렉토리에 .env 파일을 생성했습니다.

$ cat <<EOL > .env
IOS_XE_USERNAME=cisco
IOS_XE_PASSWORD=cisco
...

주요 환경 변수는 다음과 같습니다.

ios-xe-mcp-server는 검증 환경에서의 이용을 상정하고 있으며, 접속 대상 라우터별 개별 인증 정보가 아니라 공통의 사용자 이름과 비밀번호를 환경 변수에서 읽어옵니다.

환경 변수	기본값	설명
IOS_XE_USERNAME	미설정	Cisco IOS XE 라우터에 SSH 로그인하는 사용자 이름
...	true로 설정하면 읽기 전용 모드가 된다
MCP_HOST	0.0.0.0	HTTP로 동작시킬 경우의 대기 IP 주소
MCP_PORT	8003	HTTP로 동작시킬 경우의 TCP 포트 번호

MCP 서버 단독으로 show 명령어 확인하기

Codex와 연동하기 전에, MCP 서버 단독으로 Cisco IOS XE 라우터에 명령어를 실행할 수 있는지 확인합니다.

$ uv run fastmcp call ios_xe_mcp_server.py show_command command="show ip route" host="172.16.200.101"

show ip route 결과가 JSON 형식으로 반환되면 성공입니다.

ios_xe_mcp_server.py는 FastMCP와 Netmiko로 만들어졌으며, 명령어를 실행할 때마다 대상 라우터로 SSH 로그인을 수행합니다.

실행 결과 예시

INFO:server_module:Loaded credentials for user: cisco
INFO:server_module:Secure mode: Credentials loaded from environment only
INFO:server_module:🔑 Enable secret configured for privilege escalation
...

MCP 서버를 시작하기

단일 테스트가 완료되었다면, MCP 서버를 시작합니다.

$ uv run ios_xe_mcp_server.py

실행 결과 예시

$ uv run ios_xe_mcp_server.py
INFO:__main__:Loaded credentials for user: cisco
INFO:__main__:Secure mode: Credentials loaded from environment only
...

서버 시작이 완료되면 다음 URL에서 MCP 서버에 접속할 수 있습니다.

AI 에이전트가 MCP 클라이언트로 호출하는 것을 가정하고 있기 때문에, 웹 브라우저로 열어도 일반적인 웹 페이지는 표시되지 않습니다.

웹 브라우저로 접근했을 때의 예시

{"jsonrpc":"2.0","id":"server-error","error":{"code":-32600,"message":"Not Acceptable: Client must accept text/event-stream"}}

Codex에 MCP 서버 등록하기

Codex 설정 파일에 MCP 서버를 등록합니다.

여기서는 ios_xe_mcp_server_http라는 이름으로 등록했습니다.

~/.codex/config.toml이 이미 있는 경우, 다음 설정을 추가합니다.

파일이 없는 경우, 새로 생성하여 같은 내용을 작성합니다.

[mcp_servers.ios_xe_mcp_server_http]
url = "http://127.0.0.1:8003/mcp"
startup_timeout_sec = 20
...

설정을 반영하기 위해, 이미 Codex를 실행 중인 경우 한 번 종료했다가 다시 시작합니다.

또한, 이전 단계에서 시작한 MCP 서버는 별도의 터미널에서 계속 실행 상태로 유지해 둡니다.

등록되었는지 확인합니다.

$ codex mcp list
Name Url Bearer Token Env Var Status Auth
ios_xe_mcp_server_http http://127.0.0.1:8003/mcp - enabled Unsupported

Name과 Url이 표시되고, Status가 enabled로 되어 있으면 준비 완료입니다.

Codex 실행하기

모든 준비가 완료되면 Codex를 실행합니다.

/mcp를 입력하면 사용 가능한 MCP 서버 목록을 볼 수 있습니다.

MCP 서버로 ios_xe_mcp_server_http가 등록되어 있고, 툴에 config_command와 show_command가 표시되면 OK입니다.

$ codex

명령줄 실행 결과

$ codex
╭────────────────────────────────────────────────────────╮
│ >_ OpenAI Codex (v0.140.0) │
...

사용법 1: 경로 정보를 한 번에 확인하기

우선 가벼운 예시로, 두 대의 라우터에서 show ip route를 가져와 내용을 요약해 달라고 요청합니다.

Codex에 다음과 같이 요청했습니다.

ios_xe_mcp_server_http로부터 Cisco IOS XE 라우터의 show ip route 상태를 가져와 보고해 줘.
대상 호스트는 172.16.200.101과 172.16.200.102야.

MCP 서버의 툴을 호출할 때는, Codex 측에서 실행 허가 확인이 표시됩니다.

여기서는 “Allow for this session”를 선택하고, 이 세션 동안 동일한 툴 호출을 허용했습니다.

매번 확인하고 싶은 경우에는 “Allow”를 선택합니다.

실행 명령 확인 화면

• Calling ios_xe_mcp_server_http.show_command({"host":"172.16.200.101","command":"show ip route"})
Field 1/1 (1 required unanswered)
Allow the ios_xe_mcp_server_http MCP server to run tool "show_command"?
...

Codex는 MCP 서버의 show_command 툴을 사용하여, 2대의 장비에 대해 show ip route를 실행했습니다.

Called ios_xe_mcp_server_http.show_command({
"host": "172.16.200.101",
"command": "show ip route"
...

데이터를 취득한 후, 다음과 같이 요약해 주었습니다.

172.16.200.101
- 디폴트 루트 (Default Route): 없음
- 직접 연결 (Directly Connected):
...

이 예시만 보더라도, 여러 대의 출력 결과를 복사하여 붙여넣고 읽어야 하는 작업을 상당히 줄일 수 있습니다.

“디폴트 루트가 있는가”, “OSPF로 무엇을 학습하고 있는가”, “직접 연결된 세그먼트는 무엇인가”와 같은 관점에서 첫 번째 요약(Summary)을 만들어 주는 것이 편리합니다.

특히 여러 대의 show ip route 결과를 나란히 놓고 읽어야 하는 상황에서는 초기 파악이 매우 수월해집니다.

사용법 2: OSPF 상태를 대략적으로 확인하기

다음으로, 조금 막연한 요청을 해보겠습니다.

172.16.200.101, 172.16.200.102, 172.16.200.103의 OSPF 상태를 확인해서 보고해줘

이 요청에 대해 Codex는 다음 명령어들을 선택했습니다.

show ip ospf neighbor
show ip ospf interface brief
show ip interface brief
show ip protocols

처음부터 모든 명령어를 고정적으로 실행하는 것이 아니라, 취득한 결과를 보면서 추가 확인을 진행한다는 점이 포인트입니다.

예를 들어, 172.16.200.103에서는 OSPF 네이버 (Neighbor)가 표시되지 않았습니다.

그 후, show ip ospf interface brief와 show ip interface brief를 확인하여, Ethernet0/1이 administratively down/down 상태임을 찾아냈습니다.

요약 결과는 다음과 같은 내용이었습니다.

소견
- 172.16.200.101과 172.16.200.102 사이의 OSPF 인접성 (Adjacency)은 정상적으로 FULL 상태입니다.
- 172.16.200.102에서 172.16.200.103 측으로 추정되는 192.168.1.4/30 세그먼트에서는,
...

이처럼 단순히 명령어 결과를 표시하는 것에 그치지 않고, 여러 대의 상태를 대조하여 “어디가 의심스러운지”까지 언어화해 줍니다.

막연하게 물어봐도 필요한 관점으로 내용을 전개해 주는 것은 AI 에이전트다운 활용법입니다.

한편, 실제 출력 확인과 최종 판단은 사람이 수행한다는 전제를 두는 것이 중요합니다.

사용법 3: 문제 지점을 특정하여 수정하기

마지막으로, 설정 변경까지 포함하여 요청했습니다.

172.16.200.101, 172.16.200.102, 172.16.200.103에서
OSPF 네이버가 형성되지 않은 곳이 있습니다.
문제 지점을 특정하여 수정해 주세요.

Codex는 먼저 3대의 장비에서 OSPF 네이버와 인터페이스 상태를 확인했습니다.

show ip ospf neighbor
show ip interface brief
show ip ospf interface brief
...

조사 결과, 172.16.200.103의 Ethernet0/1에는 OSPF 설정이 들어가 있으나, 인터페이스가 shutdown 되어 있음을 확인했습니다.

interface Ethernet0/1
description rt2,Et0/2
ip address 192.168.1.6 255.255.255.252
...

원인이 명확해졌으므로, Codex는 MCP 서버의 설정 변경용 툴을 사용하여 다음 설정을 투입했습니다.

interface Ethernet0/1
no shutdown

그 후, OSPF 네이버 (Neighbor) 상태와 도달성을 확인하고 있습니다.

172.16.200.102:
- 192.168.0.3 FULL via Ethernet0/2
- 192.168.0.1 FULL via Ethernet0/1
...

여기까지를 수동으로 수행할 경우, 명령어 선정, 여러 대의 비교, 원인 설명, 수정 후 확인을 위한 메모 작성까지 상당한 시간이 소요됩니다.

AI 에이전트를 사용하면 작업자는 "의뢰", "승인", "결과 확인"에 집중하기 쉬워집니다.

물론, 운영 환경(Production)에서 설정 변경까지 맡기기 위해서는 추가적인 메커니즘이 필요합니다.

이번 사례는 어디까지나 검증 환경에서 "조사부터 복구 확인까지 일련의 작업으로서 진행할 수 있는가"를 시험해 본 것입니다.

Codex가 실행한 흐름의 발췌

1. 3대의 OSPF 네이버 확인
- 172.16.200.101: 192.168.0.2와 FULL
- 172.16.200.102: 192.168.0.1과 FULL
...

사용해 보며 느낀 주의점

편리한 한편, 네트워크 운용에 그대로 도입하기에는 주의할 점도 있습니다.

변경 계열 명령어는 신중하게 다룰 것

이번 사례에서는 no shutdown뿐이었지만, AI 에이전트에게 설정 변경 권한을 부여할 경우에는 신중하게 설계해야 합니다.

최소한 다음과 같은 대책이 필요합니다.

• 처음에는 읽기 전용 (Read-only)으로 사용
• 설정 변경 전에 반드시 사람이 내용을 확인
• 대상 기기나 실행 가능한 명령어를 제한
• 실행 로그를 남김
• 운영 환경 투입 전에 검증 환경에서 테스트

MCP 서버 측의 IOS_XE_READ_ONLY=true는 처음에 시도할 때의 최소한의 방어 기능이 됩니다.

다만, 그것만으로 충분하다고 생각하지 말고, 검증 환경에서 사용하는 것에 그치는 것이 무난합니다.

AI의 요약을 맹신하지 말 것

AI 에이전트는 취득한 명령어 결과를 바탕으로 설명을 해줍니다.

하지만 최종 판단은 네트워크 엔지니어가 수행해야 합니다.

특히 다음과 같은 상황에서는 실제 CLI 출력이나 설계 자료와 대조하여 확인해야 합니다.

• 경로 제어 (Routing Control) 변경
• 이중화 구성 (Redundancy) 전환
• ACL이나 NAT 등 통신 영향이 큰 설정
• 여러 거점이나 운영 환경에 영향을 주는 작업

AI 에이전트는 "판단을 통째로 맡기는 상대"가 아니라, "조사와 정리를 가속하는 상대"로 사용하는 것이 좋아 보입니다.

프롬프트는 작업 지시로서 작성할 것

AI 에이전트에게 의뢰할 때는 평소의 작업 의뢰와 유사한 형태로 작성하면 다루기 쉽습니다.

예를 들어, 다음과 같은 정보를 넣으면 의도한 범위 내에서 조사하기가 수월해집니다.

• 대상 기기의 IP 주소
• 확인하고 싶은 프로토콜이나 증상
• 설정 변경을 허용할지 여부
• 변경 후에 확인해 주길 바라는 항목

읽기만으로 테스트하고 싶다면, "설정 변경은 하지 말고, show 명령어만으로 조사해 줘"라고 명시하면 안심할 수 있습니다.

요약

이 기사에서는 Codex와 ios-xe-mcp-server를 사용하여, Cisco IOS XE 라우터의 상태 확인, OSPF 분리(Troubleshooting), 간단한 설정 수정까지를 시도했습니다.

네트워크 엔지니어에게 AI 에이전트의 활용처는 다음과 같은 작업이라고 느꼈습니다.

• 여러 대의 show 명령어 결과를 정리
• 취득 결과로부터 다음에 봐야 할 관점을 도출
• 문제 지점의 가설 수립
• 수정 후 확인 항목을 누락 없이 실행
• 작업 결과를 리포트로 남김

한편, 설정 변경까지 맡기는 경우에는 읽기 전용 모드, 승인 플로우, 로그 저장, 명령어 제한을 세트로 고려해야 합니다.

우선은 검증 환경에서 show 명령어 취득과 리포트 작성부터 시작해 보는 것이 쉬울 것이라고 생각합니다.

그 후에 어디까지를 AI 에이전트에게 맡기고, 어디서부터를 사람이 판단할 것인지를 결정해 나가는 것이 현실적입니다.

참고 문헌

• Cisco IOS XE용 MCP 서버를 Containerlab로 시도해 보았다
• network-mcp-docker-suite on Cisco DevNet
• network-mcp-docker-suite on GitHub
• IOS XE MCP Server

부록: Cisco IOS XE 라우터의 컨피그 (Config)

참고용으로 rt1, rt2, rt3의 전체 컨피그도 올려둡니다.

내용이 길기 때문에, 본문만 읽으실 예정이라면 열어보지 않으셔도 괜찮습니다.

동일한 구성을 재현하고 싶거나, 인터페이스 설정(interface setting)을 자세히 확인하고 싶은 경우에만 참조해 주세요.

rt1의 전체 컨피그

version 17.18
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
...

rt2의 전체 컨피그

version 17.18
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
...

rt3의 전체 컨피그

version 17.18
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
...

Discussion