라우팅: 길 찾기

라우터는 다음 한 걸음만 정한다

7장에서 IP 주소가 네트워크 부분과 호스트 부분으로 나뉜다는 것을 보았다. 라우터(router)는 서로 다른 네트워크를 잇는 장비로, 패킷이 들어오면 목적지 IP 주소를 보고 어느 출구(인터페이스)로, 바로 다음 어느 장비(다음 홉)에게 넘길지 정한다. 라우터 하나를 지나는 것을 홉(hop)이라 한다. 전체 경로는 아무도 계획하지 않는다. 홉마다의 결정이 이어져 경로가 된다. 이를 홉 단위 전달(hop-by-hop forwarding)이라 한다.

그래서 라우터의 일은 두 층으로 나뉜다.

• 데이터 평면(data plane): 패킷마다 하는 일. 목적지 주소로 표를 찾고, TTL을 1 줄이고(7장), 출력 포트로 내보낸다. 이것을 포워딩(forwarding)이라 한다. 대형 라우터는 전용 칩(17장)으로 초당 수십억 개의 패킷을 처리하므로 패킷 하나에 쓸 수 있는 시간은 나노초 단위다.
• 제어 평면(control plane): 표를 만드는 일. 이웃 라우터와 라우팅 프로토콜 메시지를 주고받아 망의 모양을 알고, 목적지마다 가장 좋은 길을 계산한다. 이것이 좁은 뜻의 라우팅이다. CPU 위의 소프트웨어가 하며, 망이 바뀔 때 몇 밀리초~몇 초에 걸쳐 일한다.

라우팅 테이블과 최장 접두사 일치

라우팅 테이블(routing table)의 각 줄은 “이 주소 덩어리(프리픽스)로 가는 패킷은 이 다음 홉으로”라는 규칙이다. 목적지 주소 하나가 여러 줄에 동시에 걸릴 수 있다. 예를 들어 10.1.2.200은 10.0.0.0/8에도, 10.1.0.0/16에도, 10.1.2.0/24에도 속한다. 이때 라우터는 가장 긴 프리픽스, 즉 가장 구체적인 규칙을 고른다. 이를 최장 접두사 일치(longest prefix match)라 한다. “서울시 → 대전 허브”보다 “서울시 강남구 테헤란로 → 강남 센터”가 더 정확한 지시이기 때문이다.

어느 줄에도 안 걸리는 패킷을 위해 거의 모든 라우터에는 0.0.0.0/0 줄이 있다. 프리픽스 길이 0, 즉 비교할 비트가 하나도 없으므로 모든 주소와 일치하지만 가장 짧아서 다른 일치가 없을 때만 뽑힌다. 이를 기본 경로(default route)라 한다. 집 공유기의 라우팅 테이블은 사실상 “우리 집 192.168.0.0/24는 안으로, 나머지(0/0)는 통신사로” 두 줄뿐이다.

표는 누가 만드나: 거리 벡터와 링크 상태

가장 단순한 방법은 관리자가 손으로 적는 정적 라우팅(static routing)이다. 집 공유기의 기본 경로나 작은 지점의 “나머지는 본사로” 한 줄처럼 길이 하나뿐인 곳에 딱 맞다. 하지만 링크가 끊겨도 표는 그대로라 패킷은 끊긴 길로 계속 간다. 라우터가 수십 대를 넘으면 사람이 따라갈 수 없다. 그래서 라우터들이 서로 정보를 주고받아 표를 스스로 만드는 동적 라우팅을 쓴다. 방식은 크게 둘이다.

• 거리 벡터(distance vector): 각 라우터는 “목적지별 거리” 목록(벡터)을 주기적으로 이웃에게만 보낸다. 받은 라우터는 “이웃까지 비용 + 이웃이 말한 거리” 중 가장 작은 것을 자기 거리로 삼는다. 이 반복 계산이 벨만-포드 알고리즘(Bellman-Ford)이다. 대표가 1988년 표준화된 RIP인데, 거리를 홉 수로 세고 16을 “무한대(갈 수 없음)”로 정해 15홉보다 큰 망은 다루지 못한다.
• 링크 상태(link state): 각 라우터는 “나와 내 이웃 사이의 링크와 비용”을 담은 광고(LSA)를 망 전체에 퍼뜨린다(flooding). 결국 모든 라우터가 똑같은 망 지도를 갖고, 각자 자기를 뿌리로 하는 최단 경로 트리를 다익스트라 알고리즘(Dijkstra)으로 계산한다. 대표가 기업·통신사 내부망의 표준인 OSPF와 대형 통신사가 많이 쓰는 IS-IS다.

링크가 끊기면: 경로 수렴

링크가 끊기거나 라우터가 꺼지면 모든 라우터의 표가 새 현실에 맞게 다시 일치해야 한다. 이 상태에 이르는 것을 수렴(convergence)이라 한다. 수렴 중에는 라우터마다 서로 다른 표를 들고 있어서 패킷이 버려지거나, 두 라우터가 서로에게 패킷을 떠넘기는 고리가 잠시 생긴다(이때 TTL이 패킷을 구한다, 7장). 수렴이 빠를수록 장애가 짧다.

아래 시뮬레이터에서 두 방식을 직접 비교해 보자. 링크 상태 모드는 다익스트라가 거리가 가장 가까운 라우터부터 하나씩 확정해 가는 순서를 단계별로 보여 준다. 거리 벡터 모드는 모든 라우터가 한 라운드에 한 번씩 이웃과 거리표를 바꿔 보는 과정을 보여 준다.

‘무한대로 세기 보기’를 눌러 보자. H는 G와만 연결된 막다른 라우터다. G–H 링크가 끊기면 G는 H로 갈 길이 없어야 맞다. 그런데 G의 이웃 E는 방금 전까지 “H까지 3”이라고 말하고 있었다. 그 길이 사실 G 자신을 거치는 길이라는 것을 G는 모른다. 그래서 G는 “E를 거치면 5”라고 믿고, E는 G의 새 말을 듣고 7로, 다시 G가 9로… 두 라우터가 서로의 낡은 소문을 근거로 거리를 조금씩 올리며 16(∞)에 닿을 때까지 패킷을 주고받는다. 이것이 무한대로 세기(count to infinity) 문제다. RIP이 무한대를 16이라는 작은 수로 정한 이유이기도 하다.

망들의 망: 자율 시스템과 BGP

OSPF는 한 회사 안에서는 훌륭하지만 인터넷 전체에 쓸 수는 없다. 세상 모든 링크를 하나의 지도에 담을 수도 없고, 무엇보다 통신사들은 서로 경쟁 회사다. 내 망의 내부 구조를 경쟁사에 보여 줄 이유도, 남의 트래픽을 공짜로 실어 줄 이유도 없다. 그래서 인터넷은 두 층으로 라우팅한다.

하나의 회사(또는 기관)가 한 가지 라우팅 정책으로 운영하는 네트워크 묶음을 자율 시스템(Autonomous System, AS)이라 하고, 전 세계에서 유일한 AS 번호를 받는다. 통신사, 클라우드, 대학, 큰 콘텐츠 회사가 각각 AS다. 지금 인터넷 라우팅에 나타나는 AS는 약 7~8만 개다. AS 안에서는 OSPF·IS-IS 같은 내부 프로토콜을 쓰고, AS와 AS 사이는 단 하나의 프로토콜 BGP(Border Gateway Protocol)로 잇는다.

BGP는 경로 벡터 방식이다. 이웃 AS에게 “208.65.152.0/22에는 AS 3491 → AS 36561을 거쳐 갈 수 있다”처럼 프리픽스와 함께 지나갈 AS 목록 전체를 알린다. 받은 AS는 목록에 자기 번호가 있으면 고리이므로 버린다(무한대로 세기를 피하는 방법). 그리고 가장 짧은 경로가 아니라 정책으로 고른다. “돈을 받는 고객 경로 > 무료로 주고받는 피어 경로 > 돈을 내는 상위 회사 경로” 순으로 선호하는 식이다. 그 결과 전 세계 BGP 테이블에는 IPv4 프리픽스가 약 100만 개, IPv6가 약 20만 개 넘게 올라 있고, 인터넷 핵심 라우터는 이 표 전체를 들고 다닌다.

BGP 사고와 RPKI

BGP는 1989년, 서로 아는 연구 기관 몇십 곳이 인터넷을 운영하던 시절에 설계됐다. 그래서 “이웃이 알려 준 경로는 믿는다”가 기본이다. 어떤 AS가 실수로든 고의로든 남의 프리픽스를 “내 것”이라고 광고하면 그 거짓말이 이웃의 이웃으로 퍼진다. 이를 경로 하이재킹(hijack)이라 하고, 받은 경로를 넘기면 안 되는 곳으로 넘기는 실수를 경로 누출(route leak)이라 한다.

가장 유명한 사건은 2008년 2월이다. 파키스탄 정부가 국내에서 유튜브를 막으라고 지시하자, 파키스탄 텔레콤(AS 17557)은 유튜브 주소 208.65.153.0/24를 자기 망 안의 빈 곳으로 보내는 경로를 만들었다. 이 경로가 실수로 상위 트랜짓 회사 PCCW(AS 3491)로 광고되었고, PCCW는 걸러내지 않고 전 세계에 퍼뜨렸다. 유튜브 자신은 더 큰 208.65.152.0/22를 광고하고 있었으므로, 전 세계 라우터는 최장 접두사 일치에 따라 더 구체적인 /24, 즉 파키스탄 쪽을 골랐다. 유튜브는 약 두 시간 동안 세계 대부분에서 접속되지 않았다.

이를 막는 장치가 RPKI(Resource Public Key Infrastructure)다. 주소 주인이 지역 레지스트리를 통해 “208.65.152.0/22는 AS 36561만 광고할 수 있고, /22보다 잘게 쪼개면 안 된다”는 전자 서명된 증명(ROA)을 올려 둔다. 라우터는 받은 경로를 이 증명과 대조해 맞지 않으면(Invalid) 버린다. 이를 ROV(Route Origin Validation)라 한다. 2025년 무렵 IPv4 경로의 절반 남짓이 ROA로 보호되고, 대형 트랜짓 회사 상당수가 ROV를 하지만, 시뮬레이터에서 보듯 중간에 검증하지 않는 AS가 하나라도 있으면 그 뒤쪽은 여전히 속는다. 또 ROV는 “출발 AS”만 확인하므로 경로 중간을 위조하는 공격은 막지 못해, 경로 전체를 검증하는 기술(BGPsec, ASPA)이 준비되고 있다.

페이스북 사건은 하이재킹이 아니라 스스로 경로를 거둔 사고다. 인터넷에서 어떤 주소로 가는 길은 누군가 BGP로 “여기 있다”고 광고해야만 존재한다. 광고가 사라지면 서버가 멀쩡히 켜져 있어도 세상에서 사라진다.

traceroute: 경로를 엿보는 TTL 트릭

내 패킷이 어떤 라우터들을 거쳐 가는지 직접 볼 수 있다. 1987년 반 제이콥슨(Van Jacobson)이 만든 traceroute(윈도우는 tracert)는 7장의 TTL을 영리하게 이용한다. TTL을 1로 정해 보내면 첫 라우터가 TTL을 0으로 만들고 패킷을 버리면서 “시간 초과(ICMP Time Exceeded)” 메시지를 돌려준다. 그 메시지의 출발지 주소가 바로 첫 번째 라우터다. TTL을 2로 보내면 두 번째 라우터가, 3이면 세 번째가 정체를 드러낸다. 목적지에 닿으면 목적지가 다른 종류의 응답(포트 도달 불가 또는 Echo Reply)을 보내므로 끝난 것을 안다. 홉마다 보통 세 번씩 보내 왕복 시간(RTT)을 잰다.

애니캐스트: 같은 주소, 여러 장소

보통 IP 주소 하나는 기기 하나를 가리킨다(유니캐스트). 그런데 BGP는 “이 프리픽스는 여기 있다”는 광고만 믿는다. 그렇다면 서울, 도쿄, 프랑크푸르트의 서버가 똑같은 프리픽스를 동시에 광고하면? 각 지역의 라우터는 자기에게 가장 가까운(AS 경로가 짧은) 광고를 고르므로, 사용자는 저절로 가장 가까운 서버로 간다. 이것이 애니캐스트(anycast)다.

DNS 루트 서버는 이름이 13개(a~m)뿐이지만 애니캐스트로 전 세계 약 1,900곳 이상에 복제되어 있다. 1.1.1.1, 8.8.8.8 같은 공용 DNS와 대부분의 CDN(10장)도 애니캐스트를 쓴다. 단점도 있다. 경로가 도중에 바뀌면 같은 연결의 패킷이 다른 서버로 갈 수 있어서, 짧은 질의응답(DNS, UDP)에 특히 잘 맞고 긴 TCP 연결에는 조심스럽게 쓴다.