📡 네트워크 한 입에

Chapter 05네트워크 계층 — 제어 평면

4장에서 우리는 라우터의 데이터 평면을 들여다봤다. 들어온 패킷을 헤더 한 줄 보고 어디로 내보낼지 1나노초 단위로 결정하는, 그 빠르고 단순한 세계 말이다. 그런데 거기엔 한 가지 의문이 남는다. 그 라우터의 전달 테이블(forwarding table)은 도대체 누가 채워 넣는가?

그게 바로 이번 장의 주인공, 제어 평면(control plane)이다. 제어 평면은 "이 목적지로 가려면 어느 인터페이스로 내보내야 하나?"라는 질문에 답을 만들어 라우터들에게 나눠 주는 영역이다. 길찾기 알고리즘이 돌아가고, 라우터들끼리 정보를 주고받고, 정책이 작동하고, 가끔은 멀리 있는 컨트롤러가 명령을 내리기도 한다.

이 장에서는 길찾기의 두 가지 큰 갈래(링크 상태와 거리 벡터)부터 시작해서, 자율 시스템 내부에서 쓰이는 OSPF, AS와 AS 사이의 외교 프로토콜인 BGP, 그리고 분산을 깨고 등장한 SDN까지 차례로 본다. 끝으로 ICMP와 SNMP — 인터넷이 자기 몸 상태를 진단하고 운영자가 그 안을 들여다보는 도구들 — 도 함께 살핀다.

한 문장 미리보기

데이터 평면이 "주소 보고 옆 라우터에 넘기는 손"이라면, 제어 평면은 "그 손이 어디로 넘겨야 할지 결정해 주는 머리"다.

5.1 라우팅 알고리즘

네트워크에서 길찾기를 한다는 건, 추상적으로 보면 그래프 위에서 최단 경로를 찾는 일과 같다. 각 라우터를 정점(vertex)으로, 라우터 사이의 직접 링크를 간선(edge)으로 두고, 그 간선마다 비용(cost)을 매긴다. 비용은 대역폭의 역수일 수도 있고, 지연일 수도 있고, 운영자가 그냥 "이 회선은 비싸니까 비용 1000"이라고 박아 놓은 숫자일 수도 있다.

그래프가 정해지면 문제는 하나다: 출발 라우터에서 모든 목적지 라우터까지의 최소 비용 경로를 어떻게 계산하느냐. 인터넷이 실제로 쓰는 알고리즘은 크게 두 부류로 나뉜다. 링크 상태(LS, link state)와 거리 벡터(DV, distance vector).

그래프 추상화

예를 들어 다음과 같은 6개 라우터로 된 작은 망이 있다고 하자. 숫자는 링크 비용이다.

5 (A)---------(B) | \ | \ | \2 | \3 1| \ |3 \ | (C) | (D) | / \ | / | 4 \1 |1 2 | / \ | / (E)-------(F) 4

여기서 A에서 F까지의 최단 경로를 구한다고 하면, 후보가 여러 개다. A → B → F (5+3=8), A → C → F (2+1=3), A → E → F (1+4=5). 최단은 A → C → F, 비용 3. 사람 눈에는 한눈에 보이지만, 라우터에게는 누가 어떻게 알려주느냐가 문제다.

링크 상태(LS) — 다 같이 지도를 그리자

링크 상태 알고리즘의 발상은 단순하다. "각자가 자기 주변 링크 정보만 알면 되니까, 그걸 모두에게 뿌리자. 그러면 모두가 같은 지도를 갖게 되고, 그 지도 위에서 각자 다익스트라(Dijkstra) 돌리면 된다."

구체적으로 각 라우터는 (1) 자기에게 직접 연결된 이웃들과 그 링크 비용을 측정하고, (2) 그 정보를 플러딩(flooding)으로 망 전체에 뿌린다. 모든 라우터는 결국 똑같은 링크 상태 데이터베이스(LSDB)를 갖게 되고, 거기서 다익스트라 알고리즘으로 자기 기준 최단 경로 트리를 계산한다.

다익스트라의 큰 줄기를 의사코드로 적으면 이렇다.

// 출발 노드 u, 모든 노드 집합 N, 비용 c(x,y)
function Dijkstra(u, N):
    D[u] = 0
    for each v in N where v != u:
        D[v] = c(u,v) if neighbor(u,v) else INF
        prev[v] = u  if neighbor(u,v) else null
    S = { u }                       // 확정된 집합

    while S != N:
        // 아직 확정 안 된 것 중 D 값이 가장 작은 노드 w 선택
        w = argmin { D[v] : v not in S }
        S = S ∪ { w }
        // w를 거쳐 가는 경로로 이웃 v를 갱신할 수 있나?
        for each neighbor v of w not in S:
            if D[w] + c(w,v) < D[v]:
                D[v] = D[w] + c(w,v)
                prev[v] = w
    return D, prev

위 그래프에서 A를 출발점으로 다익스트라를 한 단계씩 굴려 보자. 표는 이미 확정된 집합 S와 현재 시점의 거리 추정치 D를 보여 준다.

단계 S(확정 집합) D(A) D(B) D(C) D(D) D(E) D(F) ---- ------------------ ---- ---- ---- ---- ---- ---- 0 {A} 0 5 2 inf 1 inf 1 {A,E} 0 5 2 inf 1 5 ← E 확정, F는 1+4=5 2 {A,E,C} 0 5 2 inf 1 3 ← C 확정, F가 2+1=3으로 단축 3 {A,E,C,F} 0 5 2 5 1 3 ← F 확정, D가 3+2=5 4 {A,E,C,F,D} 0 5 2 5 1 3 5 {A,E,C,F,D,B} 0 5 2 5 1 3 ← 끝

마지막 행이 A에서 모든 노드까지의 최단 비용이다. prev[]를 따라가면 실제 경로도 나온다. 이걸로 A의 라우팅 테이블에서 "F로 가려면 다음 홉은 C"라는 식의 결론이 만들어진다.

왜 빠른가

다익스트라는 망에 노드가 N개일 때 단순 구현이 O(N²), 우선순위 큐를 쓰면 O((N+E) log N)이다. 한 AS 안의 라우터 수는 보통 수천 개를 넘지 않으니, 이 정도면 1초 이내에 충분히 다 돈다.

거리 벡터(DV) — 이웃의 말을 믿어라

거리 벡터는 발상이 다르다. "누가 전체 지도를 그려? 그냥 이웃이 자기가 아는 거리 벡터를 알려 주면, 그걸 보고 내 거리 벡터를 갱신하자."

이 아이디어는 벨만-포드(Bellman-Ford) 식으로 표현된다. 노드 x에서 목적지 y까지의 최소 비용 Dx(y)는 다음을 만족한다.

Dx(y) = minv { c(x,v) + Dv(y) }    (v는 x의 이웃)

풀이하면, "x가 y로 가는 최선의 길은, x의 이웃 v들 각각에 대해 (x → v로 가는 비용) + (v가 알고 있는 v → y 비용)를 모두 따져, 그 중 가장 작은 것"이다. 각 라우터는 이 식으로 자기 거리 벡터 Dx(·)를 끊임없이 다시 계산한다.

실행 모델은 이렇다. (1) 각 라우터는 자기 거리 벡터를 이웃에게 보낸다. (2) 이웃의 벡터를 받으면 자기 벡터를 위 식으로 갱신한다. (3) 자기 벡터가 바뀌면 다시 이웃에게 보낸다. 자체 종료(self-terminating). 망이 안정되면 모두가 옳은 답에 수렴한다.

장점은 분명하다. 각자 이웃하고만 이야기하면 된다. 메시지 부담이 작고, 분산 환경에 잘 맞는다. 단점도 분명하다. 누가 누구의 이웃인지, 누가 옳은 정보를 들고 있는지 보증이 없다.

카운트-투-인피니티 — DV의 나쁜 꿈

거리 벡터의 악명 높은 결함이 count-to-infinity다. 간단한 시나리오를 보자. A —1— B —1— C라는 직선 망에서 모두가 안정 상태에 있다. 그러던 어느 날 A–B 링크가 끊어졌다고 하자.

시점 A의 D(C) B의 D(C) C의 D(C) ----- -------- -------- -------- 초기 2 (via B) 1 (via C) 0 t1 링크 끊김. B는 곧 D(C)=inf로 가야 하는데... t2 A는 자기 벡터를 B에게 광고하면서 "나 C까지 2"라고 말함 t3 B는 그 말을 듣고 "어? A 거쳐 가면 1+2=3"이라고 갱신 t4 A는 B의 새 벡터를 듣고 "B 거쳐 가면 1+3=4" t5 B는 다시 "A 거쳐 가면 1+4=5" ... 계속 천천히 1씩 늘면서 무한대로 기어감

망이 잘못된 방향으로 천천히 망가진다. 이걸 막기 위한 잔재주가 여럿 있다. 스플릿 호라이즌(split horizon)은 "B를 거쳐 학습한 경로를 다시 B에게 광고하지 않는다"는 규칙이다. 포이즌 리버스(poisoned reverse)는 "그 경로의 비용을 무한대로 광고한다"는 약간 더 강한 변형이다. 이 둘로도 못 잡는 사이클은 남아 있어서 RIP 같은 DV 계열 프로토콜은 따로 hop count 한도(보통 15)를 쳐서 폭주를 끊는다.

LS vs DV 한눈 비교

축링크 상태(LS)거리 벡터(DV)
지식 범위각 라우터가 망 전체 토폴로지를 안다이웃이 알려 준 요약만 안다
광고 대상모두에게 플러딩이웃에게만
광고 내용나의 링크 상태(이웃과 비용)나의 거리 벡터(목적지별 비용)
계산받은 정보로 다익스트라 한 번벨만-포드 식으로 점진 갱신
수렴 속도비교적 빠르고 예측 가능망 크기와 토폴로지에 따라 들쭉날쭉
장애 전파플러딩으로 빠르게 알려짐잘못된 정보가 천천히 퍼질 수 있음(C2I)
대표 프로토콜OSPF, IS-ISRIP, EIGRP(변종), BGP(경로 벡터)

5.2 AS 내부 라우팅 — OSPF

인터넷은 한 덩어리가 아니다. 사실 매우 잘게 쪼개져 있다. 각 통신사·기업·대학교가 자기 네트워크를 자기 정책대로 굴리고, 그 단위를 자율 시스템(Autonomous System, AS)이라고 부른다. AS마다 고유 번호(ASN, AS Number)가 있고, AS 안쪽 라우팅과 AS 사이 라우팅은 다른 프로토콜로 처리한다.

AS를 굳이 가르는 이유는 두 가지다. 첫째, 규모 문제. 전 세계 라우터가 다 한 다익스트라 안에 들어가면 그래프가 너무 커진다. 둘째, 자율성 문제. KT 안의 라우팅 정책을 SK가 알아야 할 이유가 없다. AS는 정보 은닉의 단위다.

OSPF가 하는 일

OSPF(Open Shortest Path First)는 IGP의 사실상 표준 중 하나다. 이름에 답이 있다 — 최단 경로 먼저(SPF). 다익스트라 기반 링크 상태 프로토콜이다. AS 내부에서 라우터들이 같은 LSDB를 공유하도록 만들고, 각자 그 위에서 다익스트라를 돌린다.

OSPF가 동작하는 큰 그림은 이렇다.

  1. 이웃 발견. Hello 패킷을 주기적으로 보내서 누가 옆에 살아 있는지 확인한다.
  2. 인접성 형성(adjacency). 일정 조건을 만족한 이웃과는 데이터베이스를 동기화한다.
  3. LSA 광고. 자기 링크 상태를 LSA(Link State Advertisement)로 만들어 영역 안에 플러딩.
  4. LSDB 동기화. 모두가 같은 데이터베이스를 갖도록.
  5. SPF 계산. LSDB가 바뀔 때마다 다익스트라를 다시 돌려 라우팅 테이블을 갱신.

영역(Area) — 큰 AS를 더 쪼갠다

대학 캠퍼스 정도라면 라우터 몇십 대로 끝나지만, 큰 통신사 AS는 라우터가 수천 대다. 다익스트라가 아무리 빨라도 LSDB 자체가 너무 커지면 메모리도 메시지도 부담이다.

OSPF는 이걸 영역(area)으로 쪼개서 푼다. 모든 영역은 백본 영역(area 0)에 붙고, 비백본 영역의 라우터는 자기 영역 안의 토폴로지만 자세히 안다. 영역 간 정보는 영역 경계 라우터(ABR, Area Border Router)가 요약해서 넘긴다.

┌─────────────── Area 0 (백본) ─────────────┐ │ R1 ─── R2 ─── R3 │ │ │ │ │ │ │ [ABR] [ABR] [ABR] │ └────┬──────┬──────┬───────────────────────┘ │ │ │ ┌──── Area 1 ──┴── Area 2 ──┴── Area 3 ────┐ │ R4-R5 R6-R7 R8-R9 │ └──────────────────────────────────────────┘

이렇게 하면 각 영역 내 라우터의 LSDB는 그 영역만 담는다. 다른 영역 정보는 ABR이 요약해 준 형태로 받기 때문에, 망이 커져도 한 라우터가 들고 있어야 할 정보는 거의 일정하게 유지된다.

왜 LS인가

한 AS 안은 보통 한 조직이 운영한다. 즉, 모두가 같은 정책 아래 있고, 토폴로지 정보를 공유해도 문제될 게 없다. 그래서 "전체 지도를 다 같이 그리자"는 LS 방식이 잘 어울린다. 반대로 AS와 AS 사이에서는 그 가정이 안 통한다 — 이게 다음 절의 BGP가 LS 대신 경로 벡터 방식을 택한 이유다.

OSPF 패킷은 IP 위에 직접 얹힌다(프로토콜 번호 89). TCP나 UDP를 쓰지 않는다. 메시지 자체에 서열 번호와 체크섬이 있고, 인접한 두 라우터끼리 신뢰성 있는 LSA 교환을 자체적으로 처리한다. 또 인증을 지원해 가짜 LSA로 영역을 흔드는 공격을 막는다.

5.3 AS 간 라우팅 — BGP

AS 안에서는 다 같은 편이다. 하지만 KT와 SK, AWS와 Cloudflare처럼 AS와 AS 사이는 다르다. 각자 자기 이익이 있고, 어떤 트래픽은 받고 어떤 트래픽은 안 받는다. 어떤 이웃은 친구이고, 어떤 이웃은 손님이고, 어떤 이웃은 경쟁자다.

이 외교 관계 위에서 돌아가는 프로토콜이 BGP(Border Gateway Protocol)다. BGP는 인터넷의 풀(glue)이다. 사실 인터넷이 "인터넷"인 이유는 이 프로토콜 때문이라고 해도 과장이 아니다.

eBGP와 iBGP

BGP는 두 얼굴을 가진다.

AS 100 AS 200 ┌─────────────────┐ ┌─────────────────┐ │ │ │ │ │ R1 ──── R2 ════╪═══════════════╪═══ R5 ──── R6 │ │ │ ║ │ eBGP │ ║ │ │ │ │ iBGP ║ iBGP │ (다른 AS와) │ iBGP║ │ │ │ │ ║ │ │ ║ │ │ │ R3 ──── R4 ════╪═══════════════╪═══ R7 ──── R8 │ │ │ │ │ └─────────────────┘ └─────────────────┘ (━━ 물리 링크, ══ BGP 세션, ══ iBGP는 AS 내부 풀-메시 또는 RR로)

BGP 세션은 TCP 포트 179 위에서 돈다. 이웃과 명시적으로 설정하고, 한번 연결되면 서로 자기가 도달할 수 있는 접두사(prefix)들과 그 속성을 광고한다.

경로 광고에 따라붙는 속성들

BGP는 거리 벡터의 사촌인 경로 벡터(path vector) 프로토콜이다. 단순히 "거리 N"이 아니라 "이 접두사로 가는 경로는 AS 100 → AS 200 → AS 300 순서로 거쳐 간다"라는 경로 그 자체를 광고한다. 가장 중요한 속성은 다음 두 가지다.

이 외에도 LOCAL_PREF, MED, COMMUNITIES 같은 속성이 정책의 손잡이로 쓰인다.

정책 라우팅 — 이건 비즈니스다

BGP의 진짜 매운 부분은 정책이다. 두 AS가 BGP로 이어진다고 해서 모든 트래픽을 다 받는다는 뜻은 아니다. 관계는 보통 세 가지다.

이 관계가 BGP의 광고 수출 정책으로 코드화된다. 흔히 말하는 "valley-free 라우팅" 같은 규칙이 여기서 나온다 — 트래픽이 한번 위로(provider) 올라가면 다시 내려갔다 또 올라가면 안 된다는 식의.

정치가 끼는 순간

2008년 파키스탄 ISP가 자국 내에서 YouTube를 막으려고 BGP에 잘못된 광고를 흘렸는데, 그 광고가 전 세계로 퍼지면서 진짜 YouTube로 가던 트래픽이 파키스탄으로 빨려 들어간 유명한 사건이 있다. BGP는 광고를 액면가로 믿는 게 기본이다. 이 신뢰 가정 때문에 RPKI, BGPsec 같은 보강책이 계속 추가되고 있다.

경로 선택 우선순위

같은 접두사로 가는 광고가 여러 개 들어오면, 라우터는 다음 우선순위로 하나를 고른다(대략적인 일반 순서다, 구현마다 약간 다르다).

  1. LOCAL_PREF: 운영자가 정한 선호도. 가장 큰 값이 이긴다. 가장 위에 있다는 게 핵심. 정책이 알고리즘을 이긴다.
  2. AS-PATH 길이: 짧을수록 좋다.
  3. 오리진 타입: IGP > EGP > incomplete.
  4. MED(Multi-Exit Discriminator): 이웃 AS가 "여러 입구 중 이쪽이 더 좋아"라고 표시해 준 값.
  5. eBGP > iBGP.
  6. iBGP의 경우 IGP 비용이 가장 가까운 출구 — 핫 포테이토 라우팅(hot-potato routing)이라 부른다. "내 AS에서 빨리 빠져나가게 해 줘".
핫 포테이토 비유

뜨거운 감자는 빨리 옆 사람에게 넘기고 싶다. 외부로 가는 트래픽도 마찬가지다. 운영자 입장에선 자기 AS 안에서 들고 다닐수록 자기 회선만 닳는다. 그래서 자기 AS에서 가장 가까운 출구(=IGP 비용 최소)로 빨리 던지려 한다.

5.4 SDN 제어 평면

지금까지 본 OSPF/BGP는 모두 분산 제어 평면이다. 라우터들이 서로 떠들면서 각자 자기 테이블을 채운다. 이 모델은 견고하고 인터넷 규모로 검증됐지만, 단점도 분명하다. 라우터마다 복잡한 제어 소프트웨어가 살아 있어야 하고, 정책을 바꾸려면 여러 라우터를 동시에 만져야 하고, 실험적인 새 라우팅 아이디어를 넣기가 어렵다.

SDN(Software-Defined Networking)의 발상은 이렇다. "제어 평면을 라우터에서 떼어 내, 한 군데(논리적으로)에 집중하자. 데이터 평면은 단순한 매치—액션 기계로 두고."

논리적 중앙집중 컨트롤러

SDN 모델에서 라우터/스위치는 전달 장치(forwarding device)로만 일한다. 어디로 보낼지는 외부의 컨트롤러(controller)가 결정해서, 매치-액션 룰의 형태로 내려보낸다.

┌─────────────────────────────────────────────────────────┐ │ 네트워크 운영 애플리케이션 (라우팅, 부하분산, 보안 등) │ └────────────────────┬────────────────────────────────────┘ │ 노스바운드 API ┌────────────────────▼────────────────────────────────────┐ │ SDN 컨트롤러 (논리적 중앙) │ │ - 토폴로지 뷰 - 경로 계산 - 정책 결정 │ └────────────────────┬────────────────────────────────────┘ │ 사우스바운드 API (예: OpenFlow) ┌────────────┼────────────┐ ▼ ▼ ▼ [SW1] [SW2] [SW3] ← 단순 매치-액션 스위치

"논리적 중앙"이라고 한 이유가 있다. 컨트롤러를 진짜 한 대로 두면 그게 죽는 순간 네트워크가 무너진다. 그래서 실제로는 여러 대의 컨트롤러가 클러스터로 묶여서 상태를 공유한다(Raft, Paxos 같은 합의 알고리즘 위에서). 외부에서 보면 한 덩어리로 보이는, 그러나 안에선 분산된 시스템이다.

OpenFlow와 사우스바운드

컨트롤러와 스위치 사이의 통신을 사우스바운드 API라 부른다. 가장 잘 알려진 표준이 OpenFlow다. 4장에서 본 매치-액션 테이블이 바로 이 OpenFlow가 정의한 모델 위에서 자란 것이다.

OpenFlow 채널의 핵심 메시지를 거칠게 묶으면 이렇다.

이 채널은 보통 TLS로 보호된 TCP 위에서 돈다. 컨트롤러가 스위치에 절대적인 권한을 갖기 때문에, 채널이 가짜로 가로채지면 그 자체로 네트워크 전체를 탈취당하는 셈이다.

분산 vs SDN — 무엇이 다른가

축전통적 분산(OSPF/BGP)SDN
제어 위치각 라우터 안외부 컨트롤러(논리적 중앙)
장치 복잡도높음(라우팅 SW + 정책 처리)낮음(매치-액션만)
일관성 모델결국 수렴(eventual)컨트롤러가 일관성을 적극 관리
혁신 속도표준화 속도에 묶임컨트롤러 SW 갱신으로 빠르게 적용
장애 양상일부 라우터 장애 격리 잘 됨컨트롤러 장애 시 영향이 큼(클러스터로 완화)
대표 사용처인터넷 백본, 일반 ISP데이터 센터, WAN(예: 사내 광역망)
현실은 하이브리드

전 세계 인터넷은 여전히 BGP 기반이고, 앞으로도 그럴 것이다. 하지만 한 회사의 데이터 센터 내부, 한 조직의 사내 광역망은 점점 SDN 모델로 가고 있다. 구글이 자기 백본망을 SDN으로 바꿨다는 사례가 잘 알려진 예다. "제어를 어디에 둘 것인가"는 더 이상 양자택일이 아니라, 도메인별로 골라 쓰는 도구가 됐다.

5.5 ICMP — 인터넷의 진단

네트워크 계층에는 패킷을 나르는 IP만 있는 게 아니다. ICMP(Internet Control Message Protocol)가 IP 옆에서 같은 계층을 차지한다. ICMP는 IP가 일을 하다가 마주친 문제를 호스트와 라우터에게 알리는 작은 시그널 시스템이다.

메시지 형식과 흔한 타입

ICMP 메시지는 IP 패킷의 페이로드로 실린다(프로토콜 번호 1). 헤더는 단순하다 — 타입(Type), 코드(Code), 체크섬, 그리고 타입에 따라 의미가 달라지는 가변 데이터.

ICMPv6는 같은 자리를 차지하지만 더 많은 일을 한다. IPv4에서 ARP가 하던 이웃 발견 역할도 ICMPv6 안의 NDP(Neighbor Discovery Protocol)가 한다.

ping — 살아 있나?

ping은 가장 단순한 ICMP 사용 사례다. 호스트가 목적지에 Echo Request(타입 8)를 보내고, 응답으로 Echo Reply(타입 0)가 돌아오면 "살아 있다"고 판단한다. 왕복 시간(RTT)도 함께 측정한다.

방화벽이 ICMP를 차단해 버리면 ping이 안 가는 호스트도 많다 — 그럼 살아 있어도 응답이 안 온다는 말이다. 즉, ping의 침묵이 곧 호스트의 사망을 의미하지는 않는다.

traceroute — TTL 트릭

traceroute는 훨씬 영리하다. 목적지까지 가는 경로의 라우터 목록을 보여 주는데, 그 방법이 멋있다. TTL(Time To Live, IPv6에선 Hop Limit) 필드를 일부러 낮게 설정한 패킷을 차례로 보내는 트릭이다.

  1. TTL=1로 패킷을 보낸다. 첫 번째 라우터가 받자마자 TTL을 0으로 깎아 버려 패킷을 폐기하고, 발신자에게 ICMP Time Exceeded(타입 11)를 보낸다. 발신자는 그 응답의 출처 IP에서 첫 번째 라우터의 주소를 안다.
  2. TTL=2로 다시 보낸다. 첫 번째 라우터를 통과하고 두 번째에서 폐기, 두 번째 라우터가 응답.
  3. TTL을 1씩 늘려가며 반복하면 경로상의 모든 라우터를 차례로 알아낼 수 있다.
  4. 마침내 목적지에 도달하면, 목적지는 보통 닫힌 UDP 포트로 보낸 프로브에 대해 ICMP Port Unreachable(타입 3, 코드 3)을 돌려준다 — 그게 종료 신호다.
출발지(A) ─────────── R1 ─────── R2 ─────── R3 ─────── 목적지(B) TTL=1 ──┐ ▼ R1: TTL=0! → ICMP Time Exceeded ────────────────▶ A (R1 발견) TTL=2 ─────────▶ ▼ R2: TTL=0! → ICMP Time Exceeded ───────▶ A (R2 발견) TTL=3 ──────────────────▶ ▼ R3: TTL=0! → ICMP Time Exceeded ──▶ A (R3 발견) TTL=4 ─────────────────────────────▶ B (닫힌 포트) → ICMP Port Unreachable ▶ A (끝!)

실제 출력은 이런 모양이다(IP는 가상).

$ traceroute www.example.com
traceroute to www.example.com (203.0.113.42), 30 hops max
 1  10.0.0.1            0.823 ms   0.751 ms   0.812 ms
 2  192.0.2.1           1.412 ms   1.388 ms   1.401 ms
 3  198.51.100.5       12.041 ms  11.992 ms  12.103 ms
 4  198.51.100.17      14.220 ms  14.187 ms  14.250 ms
 5  * * *                                                ← 응답 없음(차단/유실)
 6  203.0.113.40       21.553 ms  21.510 ms  21.601 ms
 7  203.0.113.42       21.892 ms  21.844 ms  21.910 ms

각 줄에 같은 TTL로 보통 3번씩 보내서 RTT 세 개를 잰다. 별표(*)는 그 라우터가 응답을 안 줬다는 뜻 — ICMP 차단이 흔한 이유다. 또 traceroute가 보여 주는 경로가 반드시 양방향 동일하지는 않다. 인터넷은 보통 비대칭이다.

실전 팁

traceroute가 어느 홉에서 멈추거나 RTT가 갑자기 튀어 오르면, 그 지점이 의심 구간이다. 다만 라우터들이 응답 패킷 생성을 일부러 낮은 우선순위로 처리하는 경우가 많아서, 중간 RTT가 좀 높은 건 그 라우터 자체의 문제가 아니라 응답 처리 지연일 수도 있다 — 진짜 병목은 보통 그 다음 홉부터 일관되게 RTT가 높아진다.

5.6 SNMP와 네트워크 관리

망을 굴리는 사람 입장에서, 라우터가 살아 있느냐만 중요한 게 아니다. 인터페이스마다 트래픽이 얼마나 흐르는지, 큐가 꽉 찼는지, CPU가 비명을 지르는지, 어떤 링크에 에러가 쌓이는지 — 이런 걸 끊임없이 봐야 한다. 이 영역을 네트워크 관리(network management)라고 부르고, 인터넷이 가장 오래 쓰는 도구가 SNMP(Simple Network Management Protocol)다.

관리 모델 — 매니저와 에이전트

SNMP의 그림은 단순하다.

┌──────────────┐ ┌────────────────┐ │ 매니저(NMS) │ ── SNMP GET / SET ──▶ │ 라우터 │ │ (운영자) │ │ ┌──────────┐ │ │ │ ◀── GET-RESPONSE ──── │ │ 에이전트 │ │ │ │ │ └──────────┘ │ │ │ ◀── TRAP / INFORM ──── │ ┌──────────┐ │ │ │ │ │ MIB │ │ └──────────────┘ │ └──────────┘ │ └────────────────┘

SNMP 동작 — 폴링과 트랩

SNMP는 두 가지 흐름으로 일한다.

주요 메시지 타입을 한 번 더 정리하면:

SNMP는 보통 UDP 포트 161(에이전트 수신), 162(매니저의 트랩 수신) 위에서 돈다. UDP를 쓰는 이유는 가벼움 — 1초마다 수천 개 장비를 폴링해야 하는 대규모 망에서 TCP 핸드셰이크는 부담이다.

버전은 v1, v2c, v3가 있다. v1과 v2c는 인증을 평문 "커뮤니티 문자열"로 한다 — 내부망 외에는 절대 쓰면 안 되는 수준의 보안이다. v3는 사용자별 인증과 메시지 무결성, 암호화를 제대로 정의했다.

SET은 위험하다

SNMP SET을 쓰면 매니저가 장비 설정을 바꿀 수 있다. 위력은 크지만, 한 번 잘못 쓰면 인터페이스를 셧다운하거나 라우팅을 망칠 수 있다. 그래서 실무에서는 읽기 전용 권한으로만 SNMP를 쓰고, 설정 변경은 NETCONF/RESTCONF나 별도의 설정 관리 도구로 미는 게 보통이다.

그리고 텔레메트리

SNMP는 30년 넘게 잘 살아남았지만, 한계도 분명하다. 폴링 주기가 길면(보통 1분~5분) 짧은 스파이크를 놓치고, 짧으면 매니저가 장비를 두드려 죽인다. 그래서 최근에는 모델 기반 스트리밍 텔레메트리(streaming telemetry)가 떠오르는 추세다 — YANG으로 정의된 데이터 모델을 gNMI/gRPC 같은 채널로 장비가 매니저에게 밀어 보내는 방식이다. 폴링이 아니라 구독. 큰 데이터센터·통신사부터 차례로 넘어가는 중이고, SNMP는 한동안 둘이 공존할 가능성이 크다.

한 줄 요약