라우팅 테이블 (longest prefix match, metric, Policy Routing)

라우팅 테이블 참고 이미지

솔직히 저는 라우팅 테이블을 처음 다룰 때 "경로만 있으면 패킷은 알아서 간다"고 믿었습니다. 그 믿음이 완전히 틀렸다는 걸 장애 상황에서 식은땀을 흘리며 깨달았습니다. 라우팅 테이블은 단순한 경로 목록이 아니라 여러 규칙이 충돌하고 경쟁하는 의사결정 구조입니다. 이 글은 그 구조를 제가 실제로 부딪혀 보며 이해한 방식으로 풀어봅니다.

longest prefix match, 이론과 실전의 간극

일반적으로 라우터는 목적지 IP에 맞는 경로를 찾아 패킷을 전달한다고 알려져 있습니다. 맞는 말이지만, 경로가 여러 개일 때 어떤 기준으로 고르는지는 생략되는 경우가 많습니다. 라우터는 longest prefix match 알고리즘을 사용합니다. longest prefix match란 목적지 IP와 겹치는 네트워크 주소 중 서브넷 마스크가 가장 긴, 즉 가장 좁고 구체적인 경로를 우선 선택하는 방식입니다.

예를 들어 목적지가 192.168.1.50일 때 라우팅 테이블에 192.168.0.0/16과 192.168.1.0/24가 함께 있다면, 라우터는 반드시 /24를 선택합니다. /24가 /16보다 더 좁은 범위를 지정하기 때문입니다. 이 원칙 자체는 교과서에서도 배우는 내용이지만, 실무에서 이게 어떤 위력을 발휘하는지는 한번 손에 잡혀봐야 실감이 납니다.

BGP 블랙홀 라우팅에서 /32 호스트 경로를 주입해 특정 IP의 트래픽만 null 인터페이스로 버리는 방식도 이 원칙을 극단적으로 활용한 사례입니다. /32는 단일 호스트를 정확히 지정하는 가장 긴 프리픽스이기 때문에, 다른 어떤 경로보다 우선 선택됩니다. 이론으로 배울 때는 그냥 알고리즘 중 하나였는데, 실제로 DDoS 대응 상황에서 이 원칙을 손으로 써보면 추상적 개념이 완전히 달리 보입니다.

metric과 AD, "경로가 있는데 왜 안 가냐"의 진짜 원인

제가 실무에서 가장 당황했던 순간은 ip route show 명령어로 경로를 확인했는데 분명히 있는데도 패킷이 목적지에 닿지 않던 상황이었습니다. "경로가 있으면 다 된다"는 믿음이 처음으로 흔들린 날이었습니다.

원인은 두 가지 경로가 동시에 존재하면서 서로 충돌하고 있었던 것입니다. 하나는 OSPF로 학습된 올바른 경로였고, 다른 하나는 오래전에 수동으로 등록한 정적 경로였습니다. 문제는 metric 값이었습니다. metric이란 특정 경로를 통해 목적지까지 도달하는 데 드는 비용을 수치화한 값으로, 낮을수록 우선 적용됩니다. 오래된 정적 경로의 metric이 낮게 설정되어 있었고, OSPF가 학습한 정확한 경로를 눌러버리고 있었습니다.

여기에 AD(Administrative Distance)도 관여했습니다. AD란 라우팅 정보의 출처 신뢰도를 나타내는 값으로, 정적 경로는 기본적으로 낮은 AD 값(높은 신뢰도)을 가집니다. 그러다 보니 OSPF가 아무리 최신 정보를 가져와도 정적 경로가 우선 채택되는 상황이 벌어진 것이었습니다.

이 경험에서 느낀 게 하나 있습니다. 누군가 오래전에 남긴 정적 경로가 나중에 도입된 동적 라우팅 프로토콜을 조용히 무력화하고 있었던 건데, 이런 시한폭탄이 레거시 환경에는 생각보다 많이 숨어 있습니다. 인수인계 문서에도 당연히 없습니다. 라우팅 테이블을 전수 검토해서 정적 경로가 어디에 얼마나 박혀 있는지 파악하는 작업이 인수인계 직후에 반드시 필요하다는 교훈을 그때 얻었습니다.

라우팅 경로 선택에 영향을 미치는 요소를 정리하면 다음과 같습니다. prefix 길이는 길수록(더 구체적일수록) 우선이고, AD는 낮을수록 신뢰도가 높아 먼저 선택되며, metric은 낮을수록 경로 비용이 낮다고 판단해 우선 선택됩니다. 또한 라우팅 프로토콜 종류에 따라 static, OSPF, BGP 각각 기본 AD 값이 다릅니다. 이 세 가지가 복합적으로 작용한다는 걸 머리로는 알고 있었지만, 직접 장애를 만나보기 전까지는 진짜로 체감하기 어렵습니다.

ip route show만 믿으면 안 되는 이유, Policy Routing

문제를 발견하지 못했던 데는 또 다른 이유가 있었습니다. ip route show 명령어가 기본 라우팅 테이블만 보여준다는 점입니다. 저는 그것만 확인하고 "경로 있음, 정상"으로 판단해버렸습니다.

실제로 ip route show table all과 ip rule show를 함께 실행하고 나서야 문제가 보였습니다. Policy-Based Routing, 줄여서 PBR 테이블이 따로 존재했고, 특정 조건의 패킷은 기본 테이블이 아니라 별도 테이블의 경로를 따라가고 있었습니다. Policy-Based Routing이란 목적지 IP 외에 출발지 IP, 포트, 인터페이스 등 다양한 조건에 따라 다른 라우팅 테이블을 적용하는 방식을 말합니다. 일반적인 destination-based routing과는 다른 계층입니다.

현대 Linux 시스템은 단일 라우팅 테이블이 아니라 여러 테이블을 우선순위 규칙(ip rule)으로 연결한 구조로 동작합니다. 솔직히 이건 예상 밖이었습니다. 교과서에서 배운 라우팅 테이블이 단 하나의 표처럼 설명되어 있었기 때문에, 실무에서 여러 테이블이 레이어처럼 쌓여 있다는 구조는 직접 마주치기 전까지 상상도 못 했습니다.

이게 개인적으로 불편하게 느껴지는 이유가 하나 있습니다. 문서 어디에도 "ip route show 하나로는 부족합니다. 반드시 table all과 ip rule을 함께 보세요"라고 명시적으로 가르쳐주는 곳이 없습니다. 실무에서 스스로 부딪혀서 배우거나, 아니면 이미 그 삽질을 한 사람에게 배우는 수밖에 없습니다. 공식 문서는 기능을 설명하지만 이런 함정은 잘 짚어주지 않습니다.

ip route show 하나만 믿고 "이상 없음"을 결론 내리는 건, 지도의 첫 페이지만 보고 길을 다 안다고 하는 것과 같습니다. 제가 그 실수를 했고, 덕분에 확실히 기억하게 됐습니다.

BGP 블랙홀 라우팅, longest prefix match의 실전 활용

이 원칙이 가장 극적으로 느껴졌던 경험은 RTBH(Remote Triggered Black Hole) 설정 작업이었습니다. RTBH란 DDoS 공격처럼 특정 IP로 몰리는 이상 트래픽을 감지했을 때, BGP를 통해 해당 IP에 대한 /32 호스트 경로를 네트워크 전체에 전파하고, 그 경로의 next hop을 null 인터페이스로 지정해 트래픽을 버리는 기법입니다.

일반적으로 DDoS 대응은 장비 앞단에서 필터링한다고 알려져 있지만, 대규모 공격에서는 필터링 장비 자체가 버티지 못하는 경우가 있습니다. RTBH는 그보다 상류, 즉 라우터 레벨에서 해당 트래픽이 아예 네트워크 안으로 들어오지 못하게 막는 방식입니다. 이 접근이 가진 핵심 강점은 속도입니다. 정책을 적용하는 즉시 네트워크 전체에 전파되기 때문에, 개별 장비 설정을 하나씩 바꾸는 것보다 훨씬 빠릅니다.

여기서 /32가 핵심입니다. 공격 대상 IP 하나를 /32로 지정하면 longest prefix match 원칙에 의해 다른 어떤 경로보다 이 경로가 우선 선택됩니다. 정상 트래픽은 기존 경로를 그대로 타고, 공격 대상 IP로 향하는 트래픽만 null 인터페이스로 빨려 들어가 버려집니다. 이론으로 배울 때는 그냥 알고리즘 중 하나였는데, 이 작업을 직접 해보면서 longest prefix match가 네트워크 운영 전략에서 얼마나 실질적인 도구인지를 체감했습니다.

다만 RTBH의 한계도 명확합니다. 트래픽을 버리는 것이기 때문에 공격 대상 서버에 대한 정상 트래픽도 함께 차단됩니다. DDoS 공격을 막는 대신 서비스 자체를 잠시 중단하는 셈입니다. 공격 규모가 인프라 전체를 위협하는 수준이라면 감수할 수 있는 트레이드오프이지만, 이를 선택하는 판단은 기술적 문제가 아니라 운영 철학의 문제입니다.

라우팅을 "지도"에 비유하는 경우가 많은데, 저는 그 비유가 절반만 맞다고 생각합니다. 지도는 경로를 보여주지만 우선순위를 다투지는 않습니다. 라우팅 테이블은 prefix 길이, metric, AD, 정책 규칙이 동시에 경합하는 의사결정 엔진에 더 가깝습니다.

라우팅 테이블을 제대로 읽으려면 ip route show 하나로는 부족합니다. ip route show table all로 모든 테이블을 확인하고, ip rule show로 정책 우선순위까지 파악하는 것이 실무에서 필요한 최소한의 습관입니다. 처음엔 복잡하게 느껴지지만, 한 번 구조를 이해하고 나면 "왜 패킷이 엉뚱한 곳으로 가는지"를 논리적으로 추적할 수 있게 됩니다. 장애 상황에서 그 차이는 생각보다 큽니다.

---

출처

• Cisco IOS Routing Table — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/
• Linux ip-route man page — https://man7.org/linux/man-pages/man8/ip-route.8.html
• RFC 1812 — Requirements for IP Version 4 Routers — https://datatracker.ietf.org/doc/html/rfc1812
• Juniper Networks Routing Table Documentation — https://www.juniper.net/documentation/
• Computer Networking: A Top-Down Approach, Kurose & Ross (Pearson)