Tunnel Flapping , iBGP 루프백 경로 재귀 트러블 슈팅

JISA-2 Tunnel Flapping 발생 원인과 상세 분석

이번 문제는 단순히 터널이 끊어진 현상이 아니라, 이전 구성 변경 과정에서 생긴 라우팅 우선순위 조정과 OSPF 디폴트 경로 재분배가 복합적으로 작용한 결과였다.

1) 초기 설계 배경

본사(HQ)와 지사(JISA)는 VTI 기반 IPSec VPN으로 연결되어 있었고, BGP를 터널 위에 올려서 본사–지사 간 동적 라우팅을 자동화하려는 목표로 구성되었다.
지사 내부에서는 OSPF를 사용하여 L2JS-1,2 장비로 디폴트 경로를 내려주는 구조였다.

2) BGP Distance 변경 이유

JISA-1, JISA-2에서는 OSPF가 동작 중이었고, default-information originate 명령을 통해 L2JS-1,2로 기본 게이트웨이를 배포하였다.
이때 JISA-2가 JISA-1로부터 OSPF로 재분배된 디폴트 경로를 받게 되었고, JISA-2의 기본 경로를 BGP를 통해서 받아들이도록 하기 위해 다음 명령이 적용되었다:이는 iBGP의 AD 값을 90으로 낮춰서 OSPF(110)보다 우선하게 만든 설정이었다. 즉, BGP 경로를 우선시해 디폴트 게이트웨이를 제어하려는 조정이었다.

distance bgp 20 90 200

3) 플래핑 발생 과정

테스트를 위해 KT 회선을 일부러 다운시켜, SKT 회선을 통한 VTI IPSec VPN 전환이 정상 작동하는지 확인하였다.
이후 KT 회선을 복구하자, OSPF를 통해 전파된 디폴트 경로가 다시 활성화되면서 두 JISA 라우터가 동시에 KT 방향(기본 회선) 을 향하게 되었다.
하지만 이 시점에서 iBGP의 AD(90)가 OSPF보다 낮아 경로 우선권을 계속 가져가려는 현상이 발생하였고, BGP가 스스로를 통해 Loopback을 참조하는 불안정한 재귀 구조가 만들어졌다.
결과적으로 터널(VTI) 경로와 BGP 세션이 짧은 간격으로 끊겼다 붙는 “Flapping” 현상이 반복된 것.

JISA-1과 JISA-2가 서로의 Loopback(/32)을 iBGP(AD=90)로 학습 중이었다.
OSPF 경로도 존재하지만, AD가 더 낮은 iBGP가 항상 우선 선택되면서 RIB에 iBGP 경로가 설치됨.
iBGP 세션이 유지되는 동안은 정상 통신이 가능하지만, 세션이 잠시라도 끊기면 Loopback 경로가 사라지고, 다시 iBGP가 재수립되는 악순환 구조였다.
즉, 완전한 루프는 아니지만 세션 상태에 따라 경로가 흔들리는 불안정한 구조였다.

JISA-2:
 ip route 60.60.60.9 255.255.255.255 65.65.65.2 name TUN20-DST
Edge-2:
 ip route 65.65.65.1 255.255.255.255 60.60.60.10 name TUN20-PEER

→ ISP(SK Telecom) 라우팅이 흔들려도 터널 목적지로의 경로는 항상 존재하여 VTI가 안정 유지됨.

router bgp 64514
 no distance bgp 20 90 200
 distance bgp 20 200 200

→ 이제 OSPF(AD 110)가 iBGP(AD 200)보다 우선되어 Loopback 경로는 OSPF가 관리. → iBGP는 OSPF 경로를 기반으로 세션을 유지하게 되어 더 이상 자기 참조 현상이 발생하지 않음.

clear ip bgp * soft in

→ 변경된 AD를 반영하여 경로를 재선택.

show ip route 60.60.60.9   -> static, distance 1
show interface tunnel20    -> up/up (안정)
show ip route 192.168.2.5  -> ospf 1, distance 110

→ 플래핑 현상 사라짐.

iBGP AD를 200으로 복귀시키자 플래핑이 완전히 사라졌다.
원인은 iBGP가 OSPF보다 우선권을 가져가면서 경로 재선택이 반복된 것이었다.
현재 구조에서는 OSPF가 안정적으로 루프백 도달성을 보장하고, BGP는 OSPF 기반 위에서만 작동하므로 터널 및 세션 모두 안정적으로 유지된다.