네트워크 인프라 이해하기 · 제3부 · 다른 네트워크와 인터넷으로는 어떻게 나갈까

라우터는 여러 경로 중 패킷을 보낼 길을 어떻게 고를까

라우팅 문맥에서 RIB·FIB·Adjacency를 거쳐 실제 출력 인터페이스를 고르는 과정

라우터는 패킷의 목적지 IP와 가장 구체적으로 일치하는 Prefix를 FIB에서 찾아 다음 출구를 고릅니다. 그 FIB에는 Control Plane이 RIB에서 선택한 Route와 Next Hop을 실제 인터페이스·이웃 정보로 풀어낸 결과가 들어 있습니다. 이 글에서는 Prefix 비교부터 RIB·FIB 반영, 이웃 정보 확인과 Return Path까지 순서대로 따라가며 Route가 보여도 전달되지 않는 이유를 구분합니다.

라우터는 패킷을 받으면 Destination IP를 어느 라우팅 문맥에서 조회할까↑

일반적인 IP 전달에서 라우터는 수신한 패킷의 Destination IP를 FIB에서 조회합니다. 203.0.113.20이라는 주소 전체를 하나의 문자열처럼 찾는 것이 아니라, 이 주소가 어떤 Prefix 범위에 들어가는지 비교합니다.

Source IP, L4 포트, 입력 인터페이스까지 함께 보는 Policy-Based Routing이나 SD-WAN 정책도 있을 수 있습니다. 그러나 그런 별도 정책이 없다면 기본 경로 선택의 출발점은 목적지 IP입니다. 이 원칙을 먼저 잡아 두어야 ACL, NAT, QoS 같은 다른 기능과 라우팅 조회를 뒤섞지 않을 수 있습니다.

예를 들어 Destination이 203.0.113.20인 패킷이 VLAN 10 인터페이스로 들어오면 라우터는 먼저 그 인터페이스가 속한 VRF의 FIB를 조회합니다. 같은 Prefix가 다른 VRF에도 있어도 현재 라우팅 문맥이 다르면 후보가 아닙니다. Tunnel을 Decapsulation한 뒤에는 안쪽 Destination으로 다시 조회할 수 있으므로 캡처 지점과 패킷의 현재 헤더를 함께 알아야 어떤 테이블을 사용했는지 판단할 수 있습니다.

Policy-Based Routing은 출발지 주소, DSCP, L4 포트나 수신 인터페이스 같은 추가 조건으로 기본 Next Hop을 바꿀 수 있습니다. 일부 방화벽의 Service Routing은 장비 자체가 외부 서비스에 보내는 통신에 적용되는 기능입니다. SD-WAN 정책은 통과 패킷의 경로에도 영향을 줄 수 있습니다. 따라서 목적지 기반 Route 조회 결과와 실제 출력 인터페이스가 다르다고 라우팅 테이블이 틀렸다고 바로 결론 내리면 안 됩니다. 먼저 어떤 VRF와 정책이 이 패킷에 적용되었는지 확인한 뒤 기본 FIB 결과와 비교합니다.

기본 IP 라우팅은 목적지 IP를 조회 키로 사용합니다. Source IP는 Return Path, 보안 정책과 Policy-Based Routing에 중요하지만 일반적인 Destination-Based FIB Lookup의 첫 조회 키는 아닙니다. 진단 기록에는 수신 인터페이스와 VRF, 목적지, 적용된 정책, 실제 송신 인터페이스를 함께 적어 의도한 테이블을 조회했는지부터 확인합니다.

이 절의 근거 IETF RFC 1812 · IETF RFC 1122

RIB에서 고른 Route가 FIB에 들어가야 실제 패킷이 그 길로 나간다↑

Connected, Static, OSPF, BGP는 같은 Prefix에 대해 서로 다른 후보 경로를 제시할 수 있습니다. Control Plane은 이 후보를 Routing Information Base, 즉 RIB에 모으고 장비의 경로 선택 규칙과 정책에 따라 사용할 경로를 정합니다.

선택된 경로는 Forwarding Information Base, 즉 FIB에 반영됩니다. FIB는 매 패킷마다 복잡한 프로토콜 계산을 되풀이하지 않도록 전달에 필요한 형태로 최적화된 구조입니다. 장비에 따라 RIB·FIB의 이름과 구현은 다르지만, 경로를 계산하는 Control Plane과 패킷을 전달하는 Data Plane을 구분하면 장애 지점을 훨씬 빨리 좁힐 수 있습니다.

OSPF가 새 Route를 계산하면 곧바로 모든 패킷이 그 경로를 쓰는 것은 아닙니다. 프로토콜별 데이터베이스의 후보가 RIB 선택을 통과하고, 선택된 Prefix가 FIB에 반영되어야 합니다. Hardware 라우터라면 Line Card나 ASIC의 전달 테이블까지 반영되는 단계가 있을 수 있습니다. Control Plane Log에는 새 Route가 보여도 Data Plane 갱신이 늦거나 실패하면 실제 패킷은 이전 경로나 폐기 Entry를 사용할 수 있습니다.

반대로 프로토콜 세션이 잠시 흔들려도 Graceful Restart나 기존 FIB 보존 기능 때문에 패킷은 계속 전달될 수 있습니다. 이 상태는 Control Plane이 정상이라는 뜻이 아니라 Data Plane이 마지막 정보를 잠시 사용하는 것입니다. 장애 조사에서는 프로토콜 데이터베이스, RIB, FIB와 인터페이스 카운터를 같은 시각으로 수집합니다. 경로 계산 결과와 RIB·FIB의 Prefix·Next Hop을 대조하고 인터페이스 카운터의 변화를 확인하면 경로 학습, 선택, 설치와 실제 전달 중 어느 단계에서 어긋났는지 구분할 수 있습니다.

정상 상태에서는 RIB 변화가 FIB로 이어지지만 자원 부족, 프로그래밍 오류, 정책 또는 Hardware Offload 문제로 둘이 어긋날 수 있습니다. 따라서 “OSPF 데이터베이스에 LSA가 있다”, “BGP 테이블에 Prefix가 있다”, “RIB에 Route가 있다”는 각각 다른 단계의 증거입니다. 실제 전송 문제에서는 FIB Entry와 Adjacency까지 확인해야 Control Plane 학습과 Data Plane 전달을 연결할 수 있습니다.

이 절의 근거 IETF RFC 1812 · IETF RFC 3222

같은 목적지 프리픽스의 후보 경로는 출처와 메트릭을 비교한다↑

동일한 Prefix를 Static Route와 OSPF가 함께 알려 주면 장비는 먼저 경로 출처 사이의 선호도를 비교합니다. 일부 제조사는 이를 Administrative Distance, 다른 구현은 Preference 같은 이름으로 표현합니다. 값과 세부 순서는 제조사마다 다르므로 특정 숫자를 인터넷 공통 규칙처럼 외우면 안 됩니다.

같은 라우팅 프로토콜 안에서는 그 프로토콜이 정의한 Metric과 속성으로 최적 경로를 계산합니다. OSPF의 Cost와 BGP의 Path Attribute는 의미도 비교 방식도 다릅니다. Equal-Cost 경로를 여러 개 설치할 수 있는지, 몇 개까지 분산하는지도 장비와 설정에 따라 달라집니다.

10.20.30.0/24를 정적 설정과 OSPF 양쪽에서 제공한다면, 장비는 각 출처가 제시한 경로를 선호도에 따라 비교합니다. OSPF가 자기 후보 중 최적 경로를 계산하는 비용과 서로 다른 출처를 비교하는 우선순위는 같은 숫자가 아닙니다. 각 프로토콜의 선택 결과, RIB에 채택된 경로, FIB에 반영된 전달 정보를 차례로 확인합니다.

Equal-Cost 후보를 여러 개 FIB에 설치하면 해시 결과로 통신 흐름을 나눌 수 있지만, 두 경로의 MTU·Latency와 Stateful 장비 통과 여부가 다르면 애플리케이션 품질과 반환 경로 문제가 생길 수 있습니다. Unequal-Cost 분산은 별도 프로토콜·Vendor 기능일 수 있습니다. Route Source Preference를 바꾸는 설정은 해당 Prefix 하나가 아니라 많은 Route의 승자를 바꿀 수 있으므로, 원하는 예외는 가능한 좁은 정책으로 표현하고 장애 시나리오에서 다시 비교합니다.

동일한 우선순위와 비용의 여러 경로는 장비와 설정이 허용하면 ECMP로 함께 설치될 수 있습니다. BGP처럼 Attribute 비교 순서가 복잡하거나 Vendor 기본 Preference가 다른 경우도 있으므로 단일한 보편 순서를 암기하기보다 후보 Route, 탈락 사유와 최종 RIB/FIB Entry를 확인합니다. 운영 정책은 기본값에 기대지 말고 어느 Source를 우선할지 명시합니다.

이 절의 근거 IETF RFC 1812 · IETF RFC 3222

Route를 골랐어도 Next Hop의 인터페이스와 MAC을 찾지 못하면 패킷은 나가지 못한다↑

선택된 경로가 203.0.113.0/24 via 192.0.2.1이라고 끝나는 것은 아닙니다. 라우터는 192.0.2.1에 도달하는 경로를 다시 찾아 출력 인터페이스를 결정합니다. 이를 재귀 조회라고 부릅니다. Next Hop 자체가 해석되지 않으면 경로가 RIB에 보이더라도 FIB에 정상 설치되지 않거나 패킷을 전달하지 못할 수 있습니다.

Ethernet으로 내보낼 때는 Neighbor 테이블의 ARP 또는 IPv6 Neighbor Discovery 결과를 이용해 Next-Hop MAC을 알아야 합니다. 이 정보가 아직 없다면 먼저 이웃 정보 확인을 수행합니다. 결국 IP 경로 선택이 끝나도 출력 링크에 맞는 L2 헤더를 만들 수 있어야 실제 패킷이 움직입니다.

BGP Route가 203.0.113.0/24 via 192.0.2.9라고 알려 주면 라우터는 192.0.2.9가 어느 인터페이스로 도달 가능한지 다른 Route로 해석합니다. 이 Recursive Chain이 또 다른 Next Hop을 가리킬 수 있으며, 최종적으로 Connected 인터페이스에 도달해야 합니다. 중간 Route가 사라지면 원래 BGP Prefix가 프로토콜 테이블에 남아 있어도 FIB 설치가 실패하거나 Unresolved로 표시될 수 있습니다.

Ethernet 출력에서는 최종 Next-Hop IP에 대한 ARP·ND Entry에서 MAC 주소를 확인할 수 있어야 헤더를 만들 수 있습니다. Entry가 없으면 라우터가 Resolution 패킷을 보내는 동안 Data 패킷을 큐하거나 폐기할 수 있습니다. 인터페이스 Up, Route 존재, 이웃 정보 확인은 서로 다른 조건입니다. Next-Hop Ping이 실패할 때도 Route가 없는지, ARP가 답하지 않는지, ICMP만 정책으로 차단되는지 캡처와 Adjacency 상태로 나누어 확인합니다.

Next-Hop Route가 사라지거나 재귀 조회가 Loop를 만들면 상위 Prefix가 RIB에 보이더라도 사용할 수 없을 수 있습니다. ARP가 Incomplete인 동안 패킷은 이웃 주소 확인을 기다릴 수 있으며, 주소 확인에 실패하면 버려집니다. 터널 목적지로 가는 Route가 사라지거나 터널 자신을 가리키면 논리 Next Hop을 통한 전달도 실패할 수 있습니다. 진단에서는 목적지 Route의 Next Hop을 한 번 본 뒤 멈추지 말고, 재귀 Chain과 최종 Adjacency 상태를 끝까지 펼칩니다.

이 절의 근거 IETF RFC 1812 · IETF RFC 1122 · IETF RFC 3222

용어사전↑