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

정적 라우팅은 먼 곳의 장애를 어떻게 감지하고 백업 경로로 전환할까

Next Hop 해석과 Tracking 조건으로 정적 경로의 설치·전환·복귀를 설계하는 법

BY 주식회사 아이엠비즈니스플랫폼 PUB 2026-07-20 UPD 2026-10-26 READ 약 12분 VERIFY 표준·공식 자료 대조 $ subnet

Static Route는 운영자가 직접 설정했다고 해서 언제나 패킷을 전달할 수 있는 것은 아닙니다. Next Hop을 끝까지 해석할 수 있고 출력 인터페이스와 이웃 상태가 준비되어야 Route가 실제 전달에 쓰이며, 가까운 링크가 살아 있어도 먼 목적지는 끊길 수 있습니다. 이 글에서는 Floating Static과 Tracking이 주 경로 장애를 감지하고 전환·복귀하는 과정과 기존 세션에 미치는 영향까지 따라갑니다.

Static Route를 설정했는데도 라우팅 테이블에 설치되지 않을 수 있는 이유↑

0.0.0.0/0 via 192.0.2.1을 설정해도 라우터는 Next Hop 192.0.2.1을 해석할 수 있어야 경로를 사용할 수 있습니다. 직접 연결 네트워크에 있거나 다른 경로를 통해 재귀 조회가 가능해야 합니다.

다만 Ethernet 인터페이스가 Up 상태이고 Next Hop까지 ARP가 된다는 사실은 인터넷의 최종 목적지까지 정상이라는 뜻이 아닙니다. CPE와 ISP 장비 사이의 한 홉만 살아 있고 통신사 상위망이 끊긴 경우에도 Default Route는 계속 설치될 수 있습니다.

설정 파일에 Route가 있다는 사실과 RIB에 Active Route로 설치되었다는 사실을 구분해야 합니다. Next Hop이 현재 VRF에서 해석되지 않거나 연결 인터페이스가 Down 상태이면 Candidate만 남고 사용 Route가 되지 않을 수 있습니다. 같은 Prefix의 더 선호되는 Dynamic Route가 있으면 Static Route가 대기 상태로 보일 수도 있습니다. 구성, RIB와 FIB 세 화면을 나란히 봐야 현재 역할을 알 수 있습니다.

Next Hop 192.0.2.1에 ARP가 된다는 것은 첫 ISP 라우터까지 L2가 된다는 의미입니다. 그 라우터의 상위 BGP 장애나 인터넷 단절은 Local Static Route의 설치 조건을 바꾸지 않습니다. 이때 패킷은 살아 있는 인터페이스로 계속 나가 Blackhole이 됩니다. “링크 Up 상태이면 Route 설치 상태 유지”라는 제한된 감지 범위를 이해해야 Remote Probe나 동적 라우팅이 필요한 이유를 정확히 설명할 수 있습니다.

출력 인터페이스가 Up 상태라는 사실은 그 너머 목적지가 살아 있다는 증거가 아닙니다. Ethernet 스위치나 통신사 장비까지의 링크만 살아 있고 먼 Peer가 끊겨도 Static Route는 계속 선택될 수 있습니다. 따라서 설치 상태, Next-Hop Adjacency와 End-to-End 도달성은 별도 관찰값으로 남깁니다.

이 절의 근거 IETF RFC 1812

Ethernet에서는 출력 인터페이스만 적는 것보다 Next-Hop IP가 중요한 이유↑

Point-to-Point 링크에서는 출력 인터페이스만 지정해도 상대가 명확한 경우가 많습니다. 그러나 Ethernet 같은 Multi-Access 네트워크에서 Next Hop 없이 목적지 Prefix마다 직접 출력하도록 구성하면, 장비가 각 목적지를 On-Link로 보고 ARP를 시도하거나 Proxy ARP에 의존할 수 있습니다.

그래서 Multi-Access 환경에서는 실제 Next-Hop 주소를 명시하고, 그 주소의 이웃 정보 확인과 도달 경로를 함께 확인하는 편이 의도를 분명하게 만듭니다. 구체적인 설치 규칙과 Recursive 처리 방식은 Vendor와 OS에 따라 차이가 있습니다.

Serial Point-to-Point 링크처럼 상대가 하나뿐이면 출력 인터페이스만으로 다음 전달 대상이 분명합니다. Ethernet에서는 하나의 인터페이스에 여러 Neighbor가 있으므로 203.0.113.0/24 via Ethernet1만 지정하면 장비가 각 Destination을 Directly Connected처럼 ARP할 수 있습니다. Destination 수가 많으면 ARP Entry와 Broadcast가 늘고, Proxy ARP를 해 주는 상위 라우터가 없으면 전달되지 않습니다.

Next-Hop IP를 함께 지정하면 라우터는 그 주소에 대한 이웃 정보를 확인하고 그 Neighbor에게 Prefix 트래픽을 보냅니다. 일부 플랫폼의 Fully Specified Static Route는 인터페이스와 Next Hop을 모두 요구하거나 재귀 조회 제한에 사용됩니다. 동일한 CLI 모양이라도 설치·Resolution 동작은 OS마다 다를 수 있습니다. 운영자는 Route 출력에서 실제 Resolved 인터페이스와 Adjacency가 무엇인지 확인해 설정 의도를 검증해야 합니다.

인터페이스와 Next Hop을 모두 쓰는 Fully Specified Route가 필요한 상황도 있지만 정확한 문법과 처리 방식은 플랫폼별로 확인해야 합니다. 핵심은 FIB가 Destination Prefix를 최종 Egress와 Adjacency로 변환할 수 있는가입니다. Static 설정 줄만 검토하지 말고 Next-Hop IP의 Connected Prefix, ARP/Neighbor 상태와 실제 Destination MAC을 함께 확인합니다.

이 절의 근거 IETF RFC 1812 · Cisco Static Route Next Hop

주 Route가 사라질 때까지 Floating Static Route는 어떻게 대기할까↑

주·백업 경로는 같은 목적지 Prefix를 가리킵니다. 백업 Route는 주 Route보다 낮은 선호도로 두어 평소에는 선택되지 않게 합니다.

많은 플랫폼은 더 큰 Administrative Distance를 후순위로 판단하지만, 다른 Preference 체계를 쓰는 장비도 있습니다. 숫자의 방향은 해당 장비 문서에서 확인해야 합니다. 주 경로가 RIB에서 사라지면 이 후순위 후보가 선택되므로 Floating Static Route라고 부릅니다.

핵심은 백업이 기다리고 있다는 사실보다 주 경로가 언제 사라지는가입니다. 주 인터페이스가 실제로 Down 상태가 되거나 Next Hop을 해석할 수 없으면 자연스럽게 철회될 수 있습니다. 반면 멀리 떨어진 장애는 별도 감지가 없다면 주 경로의 설치 조건을 바꾸지 못합니다.

주 경로가 OSPF로 배운 0.0.0.0/0이고 백업 Static도 같은 /0이라면 두 후보만 선호도 비교를 합니다. 백업이 0.0.0.0/0인데 주 경로가 더 구체적인 203.0.113.0/24라면 그 /24가 살아 있는 동안 특정 트래픽은 여전히 주 경로를 사용합니다. Failover 설계에서는 “회선 하나”가 아니라 실제로 경쟁하는 Prefix Set을 맞춰야 합니다.

Floating Route의 Next Hop도 백업 경로로 쓰일 때 해석 가능해야 합니다. 백업 회선을 평소 완전히 차단해 Recursive Route가 준비되지 않으면 주 경로 철회 뒤에도 경로 설치가 지연될 수 있습니다. ARP 정보가 없으면 경로가 설치되어도 실제 전달은 지연될 수 있습니다. 반대로 주 Route가 단순 인터페이스 Up 조건으로 계속 남으면 백업은 영원히 떠오르지 않습니다. 주 후보의 제거 Trigger와 백업 후보의 설치 준비를 별도 시험해야 합니다.

백업 Route는 존재만 해서는 충분하지 않습니다. Next Hop이 실제로 도달 가능하고, 반대편에도 Return Route가 있으며, 방화벽·NAT와 회선 용량이 필요한 트래픽을 처리해야 합니다. 주 경로 복귀 시 즉시 원복할지 안정 시간을 둘지 정하지 않으면 Flap 구간에서 경로가 반복 전환될 수 있습니다.

이 절의 근거 IETF RFC 1812 · Cisco Static Route Next Hop

멀리 있는 회선 장애를 Probe가 감지하면 Tracking이 Route를 바꾼다↑

일부 장비는 ICMP Echo, TCP 연결, DNS 응답처럼 정의한 Probe를 주기적으로 실행하고 결과를 Tracking Object에 반영합니다. Static Route를 이 Object와 연결하면 연속 실패 시 주 경로를 제거하고, 회복 시 다시 설치할 수 있습니다. 기능명은 IP SLA, RPM, Track 등으로 다릅니다.

Probe 대상은 단순히 ISP Next Hop만 고르기보다 실제로 보호하려는 경로를 대표해야 합니다. 다만 하나의 공인 IP만 검사하면 그 서버의 장애를 회선 장애로 오판할 수 있습니다. 여러 대상, 실패 횟수, Timeout, 복귀 지연을 조합해 순간 손실과 실제 장애를 구분해야 합니다. BFD는 짧은 주기로 인접 경로 장애를 감지하는 별도 프로토콜이며, 임의 애플리케이션의 정상 여부를 확인하는 범용 Probe와 같지는 않습니다.

시험 패킷이 실제로 주 회선을 통해 나가는지 확인해야 합니다. 출발지 인터페이스를 지정하는 것만으로 송신 경로까지 고정되는 것은 아닙니다. 백업 경로로 우회한 시험 요청이 성공하면 주 회선이 복구됐다고 잘못 판단할 수 있으므로, 대상별 경로나 정책도 함께 확인합니다. ISP 게이트웨이·인터넷의 특정 IP·업무 서비스는 서로 다른 구간을 검사하므로, 보호할 서비스와 외부 대상의 장애 가능성을 고려해 시험 대상과 판단 조건을 정합니다.

예를 들어 3초 간격 Probe가 세 번 연속 실패하면 장애, 다섯 번 연속 성공하면 복구 상태로 판단하고 30초 Hold-Down 상태를 둘 수 있습니다. 숫자는 환경 요구와 플랫폼 기능에 맞춰 정하지만 실패와 복구 기준을 다르게 두는 Hysteresis가 Flap을 줄입니다. Probe 패킷의 QoS, VRF, NAT와 Return Path도 실제 User 트래픽과 같거나 의도적으로 다르다는 점을 기록해야 “Probe 성공”의 범위를 해석할 수 있습니다.

검사 대상 하나가 점검 중이거나 ICMP를 제한하면 회선 전체를 실패로 오판할 수 있습니다. 여러 대상과 조건을 조합하거나 통신사 BFD·라우팅 프로토콜을 사용하는 대안을 비교합니다. 감지 간격, 연속 실패 횟수, 전환 지연, 복귀 안정 시간을 서비스 요구와 Control Plane 부하에 맞춰 정하고 Probe 자체의 Route가 전환과 순환 의존하지 않는지 검토합니다.

이 절의 근거 IETF RFC 5880 · IETF RFC 5881 · Cisco ISP Failover with IP SLA

도해에서 확인할 내용 IP SLA Probe가 대상 198.51.100.1의 ICMP 응답 시간 초과를 감지한 뒤, AD 1의 주 Static Route를 제거하고 사용 가능한 AD 10의 Floating Static Route를 선택하는 두 단계를 확인합니다. 게이트웨이의 응답만으로 원격 업무 서비스까지 검증한 것은 아니므로 도해 아래의 탐지·전환·서비스 복구 시험 항목을 구분해 읽습니다.

↔ 도해는 좌우로 움직여 볼 수 있습니다.

백업 Route로 전환되어도 기존 TCP 세션이 끊길 수 있다↑

Failover 뒤 새 패킷은 백업 인터페이스로 전달되지만 기존 TCP 세션은 끊길 수 있습니다. 출발지 공인 IP가 달라지거나 NAT Mapping과 방화벽 상태가 다른 장비에만 존재하면, 기존 연결의 주소·포트 조합이 달라지거나 전환 장비에서 패킷이 폐기되어 상대 서버와의 통신이 중단될 수 있습니다.

장애가 해소되자마자 주 회선으로 돌아가는 Failback은 경로가 짧게 흔들리는 현상을 만들 수 있습니다. Tracking에 Hold-Down이나 복귀 지연을 두고, Stateful 장비 사이의 상태 동기화와 양방향 경로를 함께 설계해야 합니다. Route 전환이 성공하는 것과 기존 세션이 이어지는 것은 서로 다른 문제입니다.

ISP-A에서는 Source NAT 주소가 198.51.100.8이고, ISP-B에서는 203.0.113.8이라고 하겠습니다. 장애 전환 뒤 기존 TCP 흐름의 패킷이 새 공인 주소로 변환되면 서버가 보는 주소·포트 조합이 달라져 기존 연결과 일치하지 않습니다. 클라이언트는 응답을 받지 못하거나 연결이 종료되어 다시 접속해야 할 수 있습니다. 클라이언트가 반드시 다른 주소·포트의 응답을 받는다는 뜻은 아닙니다. NAT 주소가 같더라도 전환할 방화벽에 세션 상태가 없거나 응답 경로가 이전 장비를 향하면 기존 연결이 끊길 수 있습니다.

따라서 SLA를 “Route 전환 3초”라고만 적지 말고 새 세션이 복구되는 시간과 기존 세션이 유지되는지를 나눠 기록합니다. 음성·영상 UDP 통신, 장시간 데이터베이스 연결, VPN 터널은 손실에 다르게 반응합니다. 상태 동기화가 있어도 TCP Sequence Number와 Timer, 애플리케이션의 재연결까지 End-to-End로 시험합니다. Failback은 경로와 주소를 다시 한 번 바꾸므로 업무 시간에 자동으로 복귀할지 운영자가 승인할지도 정책으로 정합니다.

따라서 전환 시험은 Ping만으로 끝내지 않고 신규 연결과 장시간 기존 연결을 나눠 측정합니다. 외부에서 보이는 Source Tuple, Return Path, NAT/방화벽 상태 동기화, TCP 재전송과 애플리케이션 복구 시간을 기록합니다. 설계 목표가 “새 연결은 수초 내 복구”인지 “기존 세션 무중단”인지에 따라 필요한 장비 상태와 회선 구성이 달라집니다.

이 절의 근거 IETF RFC 3022 · IETF RFC 9293

장애 시험 전에 무엇을 실패로 보고 언제 복귀할지 표로 정한다↑

상황: ISP-A 상위망 장애 때 백업 Route가 선택되지 않거나 두 경로가 반복해서 바뀝니다.

주 Static Route가 설치되는 정확한 조건과 Recursive Next Hop을 확인합니다.
링크, ARP, ISP Next Hop, 외부 목적지 중 어느 구간까지 살아 있는지 분리해 측정합니다.
Probe의 Source 인터페이스와 Return Path가 의도한 회선을 통과하는지 확인합니다.
실패 횟수, Timeout, Hold-Down, Failback 지연을 기록하고 순간 패킷 손실에 대한 동작을 시험합니다.
Failover 전후 RIB·FIB·NAT Translation Table·방화벽 상태를 같은 시각으로 수집합니다.
새 세션과 기존 세션을 나누어 성공 여부를 검증하고 운영 문서에 예상 중단 범위를 남깁니다.

시험표의 행에는 물리 링크 Down, ISP Next Hop 무응답, 상위 인터넷 단절, 높은 패킷 손실, Probe 대상 하나의 장애와 Tracking Process 실패를 둡니다. 열에는 감지 신호, 주 Route 제거 시간, 백업 설치, NAT·방화벽 상태, 새 통신 흐름과 기존 통신 흐름 결과를 둡니다. 정상 조건뿐 아니라 어떤 장애를 감지하지 않기로 했는지도 적으면 설계의 범위를 분명히 할 수 있습니다.

각 시나리오를 실행할 때 RIB·FIB가 바뀐 시각, Probe 로그, 인터페이스 카운터와 패킷 캡처 시각을 맞춥니다. 복구 단계에서는 주 회선이 불안정하게 Up·Down 상태가 될 때 Hold-Down이 작동하는지, 백업 경로의 트래픽이 빠져나간 뒤 세션이 어떻게 되는지 확인합니다. 시험 후 설정을 원복하고 Route Preference와 Probe Source 설정이 원래 값인지 검증합니다. 문서화된 표는 이후 장애에서 기대 동작과 실제 동작을 바로 비교하는 기준이 됩니다.

각 시험은 검출 시간, RIB/FIB 변경, 첫 성공 패킷과 완전 복구 시각을 공통 시계로 남깁니다. 이 결과를 기준으로 Timer와 Runbook을 조정하면 “자동 절체됨”이라는 설정 설명을 재현 가능한 운영 조건으로 바꿀 수 있습니다.

이 절의 근거 IETF RFC 5880 · Cisco ISP Failover with IP SLA