[Multi-Vendor의 숙명] VRF/VDOM 망 분리와 Flow 분석으로 '장애 원점' 찾는 법 (F-기관 통합 운영 사례)

🕵️‍♂️ 이런 분들을 위해 작성했습니다.

• Cisco, Juniper, Fortinet, Ahnlab 등 여러 벤더 장비가 뒤섞인 '스파게티 네트워크'를 운영 중인 IT 관리자
• 장애가 터지면 '어느 벤더 장비의 문제'인지 밝히느라 시간을 허비하는 엔지니어 (일명 '핑퐁 게임'에 지친 분)
• "네트워크가 느려요"라는 막연한 불만에 데이터로 원인을 제시하고 싶은 분
• VRF나 VDOM을 들어는 봤지만, 이걸 왜, 어떻게 운영에 활용해야 할지 막막한 분

들어가며: 문제의 시작과 우리의 목표 (Introduction & Goal)

History & Why: 왜 이 프로젝트가 필요했나요?

저희가 통합 유지보수를 담당하게 된 F-기관(공공/대학)은 지난 20년간의 IT 역사가 그대로 녹아있는 '네트워크 박물관'과 같았습니다. 🏛️

• Core(코어): 10년 전 도입한 Cisco 스위치
• Edge(엣지): 5년 전 추가된 Juniper 라우터
• Firewall(방화벽): Fortinet과 Ahnlab이 이중화(HA)로 구성
• Access(액세스): 각 건물마다 도입 시기가 다른 다양한 벤더의 L2 스위치들...

이 'Multi-Vendor' 환경의 가장 큰 숙명은 장애였습니다. 하나의 서비스(예: 학사정보시스템)가 느려지면,"Cisco 라우팅 문제다", "아니다, Fortinet 방화벽 정책 문제다", "Juniper의 세션 문제다"라며 원인을 찾는 데만 꼬박 하루가 걸렸습니다. 모든 장비가 하나의 거대한 라우팅 테이블을 공유하고 있어, 문제의 원점이 어디인지 추적하는 것이 불가능에 가까웠죠.

우리의 핵심 목표(Goal)는 장비를 교체하는 것이 아니었습니다. "기존의 복잡한 Multi-Vendor 환경을 그대로 둔 상태에서, '논리적 분리'와 '트래픽 가시성' 확보를 통해 장애의 근본 원인을 즉시 찾아낸다."

이를 위해 설정한 핵심 지표(Key Metric)는 단 하나였습니다.

• MTTR (Mean Time to Resolution, 평균 장애 해결 시간): 기존 평균 6시간 -> 1시간 이내로 80% 단축

Our Vision

우리의 비전은 '관제 가능한(Manageable) 네트워크'를 만드는 것이었습니다. 칠흑 같은 어둠 속에서 더듬거리며 장애 지점을 찾는 것이 아니라, 환한 조명(가시성) 아래에서 명확한 지도(논리적 분리)를 보고 원인을 찾는 것. 그것이 저희 M&O(운영)의 핵심 가치였습니다.

💥 핵심 과제와 해결 과정 (Challenges & Solutions)

The Problem: '하나의 거대한 실패 도메인'과 '칠흑 같은 가시성'

F-기관의 네트워크는 물리적으로도 복잡했지만, 논리적으로는 더 심각한 '단일 실패 도메인(Single Failure Domain)' 문제를 안고 있었습니다.

예를 들어, 학생용 Wi-Fi망(Guest)에서 발생한 대규모 트래픽(예: 토렌트)이, 교수 연구망(Internal)의 라우팅 테이블에 영향을 주어 전체 네트워크의 CPU가 폭주하는 상황이었습니다. 모든 트래픽이 논리적으로 분리되지 않고 하나의 '그릇'에 담겨 있었기 때문입니다.

graph TD
    subgraph Before: 하나의 그릇 - Multi-Vendor 혼돈의 라우팅 테이블
        direction TB
        
        C[Cisco Core L3 - 10년 전]
        J[Juniper Edge L3 - 5년 전]
        subgraph 방화벽 이중화 HA
            F[Fortinet Firewall ]
            A[Ahnlab Firewall ]
        end
        L2_1[Access L2 Guest - 다양한 벤더]
        L2_2[Access L2 Internal - 다양한 벤더]

        C ---|모든 경로 공유| J
        J ---|모든 경로 공유| F
        J ---|모든 경로 공유| A
        F ---|모든 경로 공유| A
        F ---|모든 경로 공유| C
        A ---|모든 경로 공유| C
        
        L2_1 -->|Guest Traffic| C
        L2_2 -->|Internal Traffic| C
        
        style C fill:#f99,stroke:#c00,stroke-width:2px
        style J fill:#f99,stroke:#c00,stroke-width:2px
        style F fill:#f99,stroke:#c00,stroke-width:2px
        style A fill:#f99,stroke:#c00,stroke-width:2px
        
        subgraph 하나의 거대한 실패 도메인
            L2_1 
            L2_2
        end

        classDef issue fill:#f99,stroke:#c00,stroke-width:2px
        class C,J,F,A issue
    end

<p align="center">그림 1: Guest 트래픽 장애가 Internal 트래픽에 영향을 주는 단일 라우팅 테이블 구조</p>

The Solution 1: 논리적 격리 (VRF & VDOM)

우리는 이 '하나의 그릇'을 여러 개의 '작은 그릇'으로 나누는 작업에 착수했습니다. 이것이 바로 '논리적 망 분리'입니다.

• 라우터/스위치 (Cisco, Juniper): VRF (Virtual Routing and Forwarding) 기술을 적용했습니다.
  • VRF-Internal (내부망), VRF-Guest (손님망), VRF-IoT (설비망)
  • 이제 각 VRF는 자신만의 독립된 라우팅 테이블을 가집니다. VRF-Guest에서 발생한 라우팅 오류는 절대로 VRF-Internal에 영향을 주지 못합니다.
• 방화벽 (Fortinet): VDOM (Virtual Domains) 기술을 적용했습니다.
  • Fortinet 방화벽 1대를 논리적으로 Root-VDOM, Internal-VDOM, Guest-VDOM 등으로 쪼갰습니다.
  • 각 VDOM은 독립된 방화벽 정책과 라우팅 테이블을 가집니다.

이를 통해 저희는 '장애 전파 범위(Blast Radius)'를 획기적으로 축소했습니다.

graph TD
    subgraph After: VRF-VDOM으로 논리적으로 격리된 Multi-Vendor
        direction TB
        
        subgraph 물리 장비 - 동일
            C[Cisco Core]
            J[Juniper Edge]
            subgraph 방화벽 이중화 HA
                F[Fortinet Firewall]
                A[Ahnlab Firewall]
            end
        end

        subgraph 논리적 망 분리 - 가상 라우터-방화벽
            direction LR
            
            subgraph VRF-Internal - 내부망
                C_VRF_I[Cisco VRF Internal]
                J_VRF_I[Juniper VRF Internal]
                F_VDOM_I[Fortinet VDOM Internal]
            end

            subgraph VRF-Guest - 손님망
                C_VRF_G[Cisco VRF Guest]
                J_VRF_G[Juniper VRF Guest]
                F_VDOM_G[Fortinet VDOM Guest]
            end
        end
        
        L2_1[Access L2 Guest] -->|Guest Traffic| C_VRF_G
        L2_2[Access L2 Internal] -->|Internal Traffic| C_VRF_I

        %% Logical connections within VRFs
        C_VRF_I ---|Internal Routing| J_VRF_I
        J_VRF_I ---|Internal Routing| F_VDOM_I
        C_VRF_G ---|Guest Routing| J_VRF_G
        J_VRF_G ---|Guest Routing| F_VDOM_G

        style C_VRF_I fill:#bbf,stroke:#00a,stroke-width:2px
        style J_VRF_I fill:#bbf,stroke:#00a,stroke-width:2px
        style F_VDOM_I fill:#bbf,stroke:#00a,stroke-width:2px
        style C_VRF_G fill:#bbf,stroke:#00a,stroke-width:2px
        style J_VRF_G fill:#bbf,stroke:#00a,stroke-width:2px
        style F_VDOM_G fill:#bbf,stroke:#00a,stroke-width:2px
    end

<p align="center">그림 2: 동일한 물리 장비 위에서 VRF/VDOM으로 망을 분리 (Guest망 장애가 Internal망과 완벽히 격리됨)</p>

The Solution 2: 트래픽 가시성 확보 (Flow Analysis)

논리적 분리로 '어느 망'에서 문제가 생겼는지는 알게 되었지만, '그 망의 누가 문제를 일으키는지'는 여전히 알 수 없었습니다.

이때 필요한 것이 Flow 분석입니다.

• SNMP (Ping, PRTG/Zabbix 등): "링크가 죽었는가? (UP/DOWN)"만 알려줍니다.
• Flow (NetFlow, j-Flow, s-Flow): "링크가 살아있는데, '누가(Source IP)', '누구에게(Dest IP)', '무엇을(Port)', '얼마나(Bytes)' 보내고 있는가?"를 알려줍니다.

우리는 이기종 환경의 모든 L3 장비(Cisco, Juniper, Fortinet)에서 각자의 Flow(NetFlow, j-Flow 등) 데이터를 수집하여 통합 Flow 분석기(Collector)로 전송했습니다.

"학사정보시스템이 느려요" (VRF-Internal 문제 확인) -> "Flow 분석기를 보니, 특정 IP(10.1.1.5)가 비정상적인 트래픽을 유발하고 있습니다." 이렇게 장애의 '원점'을 IP 단위로 특정할 수 있게 되었습니다.

🏛️ 우리가 선택한 기술과 아키텍처 (Solution Overview)

Why this Stack?

• Why VRF & VDOM? (논리적 격리)
  • 이것은 Multi-Vendor M&O의 핵심입니다. 하드웨어를 교체하지 않고도, 복잡한 네트워크를 관리 가능한 작은 단위로 쪼갤 수 있는 유일한 방법입니다.
  • VRF(라우터)와 VDOM(방화벽)은 이름과 벤더는 다르지만 '독립된 라우팅/정책 테이블을 제공한다'는 동일한 철학을 공유합니다. 이를 통해 '장애 전파 범위(Blast Radius)'를 최소화했습니다.
• Why Flow Analysis (vs. SNMP)?
  • SNMP는 '장애의 결과(링크 단절)'만 보지만, Flow는 *'장애의 원인(트래픽 급증)'을 봅니다.
  • "네트워크가 느리다"는 막연한 불만은 대부분 SNMP로는 잡히지 않는 '성능 저하' 문제입니다. 이 문제의 90%는 Flow 분석을 통해서만 원인을 규명할 수 있습니다. '누가' 트래픽을 유발하는지 아는 것은 운영의 핵심입니다.

📈 주요 성과와 비즈니스 임팩트 (Result)

'논리적 분리'와 '가시성 확보'라는 두 가지 운영 기술은 F-기관의 IT 운영을 근본적으로 변화시켰습니다.

정량적 성과

• MTTR 80% 단축 달성: "네트워크가 안 돼요"라는 신고 접수 시,
  1. 어느 VRF/VDOM의 문제인지 (10분)
  2. 해당 망의 Flow를 분석해 어느 IP/서비스가 문제인지 (20분)
  3. 해당 장비 접속 및 조치 (30분) -> 기존 평균 6시간 이상 걸리던 장애가 평균 1시간 이내로 해결되었습니다.
• 보안 이벤트 대응 속도 향상: 이상 트래픽(DDoS, 웜) 발생 시, Flow 분석을 통해 즉시 공격 근원지 IP를 파악하고 방화벽에서 차단하는 시간이 '일' 단위에서 '분' 단위로 단축되었습니다.

정성적 효과

• '핑퐁 게임'의 종식: "Cisco 장비 로그엔 이상 없습니다. VRF-Guest 쪽 Juniper 장비의 Flow를 확인해 주세요."처럼, 데이터에 기반한 명확한 커뮤니케이션이 가능해졌습니다.
• 예방 정비(Proactive M&O) 실현: 장애가 터진 후에 대응하는 것이 아니라, Flow 트래픽 추이를 분석하여 "이번 주말에 VRF-Internal의 백본 대역폭 증설이 필요합니다"와 같은 선제적인 조치가 가능해졌습니다. 👌
• IT팀의 신뢰도 향상: "원인을 모르겠다"가 아닌, "원인은 A이며, 조치는 B"라고 명확하게 답변할 수 있게 되어 현업 부서의 신뢰를 회복했습니다.

마무리하며: 우리의 경험이 당신에게 주는 가치 (Conclusion)

F-기관의 Multi-Vendor 사례는 "좋은 장비를 사는 것(구축)"만큼, 가진 장비를 제대로 운영하는 것(M&O)이 중요함을 보여줍니다. 장비가 아무리 복잡하게 얽혀있어도, 논리적으로 분리(VRF/VDOM)하고 훤히 들여다볼(Flow) 수만 있다면, 그 네트워크는 '관리'될 수 있습니다.

이 프로젝트를 통해 얻은 교훈은 "복잡성은 통제하는 것이지, 피하는 것이 아니다"라는 것입니다.

💡 Call to Action: 당신을 위한 제언

이 글을 읽고 비슷한 고민을 하고 계신 분들께 두 가지 실질적인 조언을 드리고 싶습니다.

1. 당신의 네트워크 '그릇'을 나누세요: 지금 당장 Core 장비에서 Guest Wi-Fi 트래픽만이라도 별도의 VRF(또는 VDOM)로 분리해 보세요. 그것만으로도 전체 네트워크 안정성이 최소 2배는 향상될 것입니다.
2. SNMP를 넘어 Flow를 보세요: PRTG, Zabbix로 UP/DOWN만 보고 있다면, 당신은 '장님 코끼리 만지기'를 하고 있는 것입니다. NetFlow/s-Flow를 활성화하고 Flow Collector(분석기)를 도입하여 '누가' 트래픽을 쓰는지 눈을 떠야 합니다.

Future

F-기관의 안정화된 네트워크는 이제 '자동화'라는 다음 단계로 나아가고 있습니다. Flow 분석을 통해 탐지된 이상 트래픽 IP를, 사람이 아닌 SOAR(보안 자동화) 솔루션이 자동으로 API를 통해 VDOM 방화벽에서 차단하는 '지능형 운영'을 준비하고 있습니다.

긴 글 읽어주셔서 감사합니다. 여러분의 복잡한 네트워크 속에서도 '질서'를 찾으시길 바랍니다.