멀티캐스트 · MPLS · LISP
VPP의 멀티캐스트 처리(IGMPv3/MLDv2/BIER), MPLS 및 SR-MPLS 레이블 스위칭, LISP 컨트롤 평면, BFD 빠른 장애 감지 등 L3 제어 평면 확장 기능을 정리합니다.
VPP 멀티캐스트 개요
VPP는 IPv4/IPv6 멀티캐스트를 일급 지원합니다. 멀티캐스트 수신자 목록은 MFIB (Multicast FIB)에 저장되며, IGMPv3/MLDv2 프로토콜로 동적으로 갱신됩니다. 패킷 복제는 데이터 평면에서 수행되며, BIER 같은 대안 모델도 플러그인으로 제공됩니다.
vpp# show ip mfib
vpp# show ip6 mfib
vpp# set interface ip mfib <if> forward accept
vpp# show ip igmp snoop(*, G)와 (S, G) 두 가지 매칭을 지원하며, 각 엔트리에 대해 "어느 인터페이스로 들어온 트래픽을 어떤 인터페이스 벡터로 복제해 나갈지"를 지시합니다. 유니캐스트 FIB와 별개의 트리로 유지됩니다.
MFIB 내부 구현과 복제 경로
MFIB 엔트리는 내부적으로 mfib_entry_t 구조체로 표현되며, 각 엔트리는 Replication List(복제 대상 인터페이스 집합)를 DPO로 들고 있습니다. 멀티캐스트 패킷이 ip4-mfib-forward-lookup 노드에서 매칭되면 ip4-mfib-forward-rpf가 Reverse Path Forwarding 검증을 수행한 뒤 ip4-replicate 노드가 버퍼를 복제합니다. 복제는 버퍼 헤더만 재사용(zero-copy clone)하고 데이터는 공유하므로, 수신 인터페이스 수가 늘어도 메모리 대역폭 증가는 완만합니다.
# (*,G) 및 (S,G) 엔트리 확인
vpp# show ip mfib 239.1.1.1
vpp# show ip mfib 239.1.1.1 detail
vpp# show ip mfib summary
# 복제 DPO 추적
vpp# show replicateMFIB 출력 해석 가이드
show ip mfib 239.1.1.1 detail 출력 예시와 각 필드 의미입니다.
vpp# show ip mfib 239.1.1.1 detail
# (*,G) 와일드카드 엔트리 — 소스에 무관하게 그룹 239.1.1.1로 오는 패킷에 적용
(*,239.1.1.1)
Flags: C # C = Connected (로컬 인터페이스에 수신자 있음)
RPF: # (*,G)는 RPF 검사를 소스별 유니캐스트 FIB로 수행
Interfaces:
GigabitEthernet0/8/0 Flags: A NS # A=Accept(IIF: 이 인터페이스로 들어온 패킷 수신), NS=Not-Signal
GigabitEthernet0/9/0 Flags: F NS # F=Forward(OIF: 이 인터페이스로 복제 전송)
GigabitEthernet0/10/0 Flags: F NS # F=Forward(OIF: 두 번째 출력 인터페이스)
# (S,G) 소스-지정 엔트리 — 192.0.2.10에서 오는 239.1.1.1 패킷에 적용
(192.0.2.10,239.1.1.1)
Flags: C # C = Connected
RPF: GigabitEthernet0/8/0 192.0.2.10 # RPF 인터페이스 + 예상 소스 next-hop
RPF-CHECK: PASS # 소스 192.0.2.10의 역방향 경로가 GE0/8/0으로 확인됨
Interfaces:
GigabitEthernet0/8/0 Flags: A NS # IIF: 패킷이 들어오는 인터페이스
GigabitEthernet0/9/0 Flags: F NS # OIF: 수신자 1로 복제 출력
GigabitEthernet0/10/0 Flags: F NS # OIF: 수신자 2로 복제 출력
GigabitEthernet0/11/0 Flags: F NS # OIF: 수신자 3로 복제 출력트래픽이 도착하지만 MFIB에서 포워딩되지 않는 시나리오 디버깅 단계:
show ip mfib 239.1.1.1 detail— 엔트리 존재 여부와 IIF/OIF 인터페이스 목록, Flags 확인show ip fib <source-ip>— RPF 역방향 경로 확인: 소스 IP로 향하는 유니캐스트 경로가 IIF와 일치하는지 검증show ip neighbor— ARP/neighbor 테이블에 OIF의 next-hop 주소가 해석(resolve)되어 있는지 확인; 미해석 시 패킷이 OIF에서 드롭됨show errors | grep mfib— 드롭 원인 카운터 확인:ip4-mfib-forward-rpf드롭이면 RPF 실패,ip4-replicate드롭이면 OIF 문제
정상 MFIB 엔트리 vs RPF 실패 엔트리 비교:
### 정상 엔트리 — RPF PASS, OIF 복제 정상 동작
vpp# show ip mfib 239.1.1.1 detail
(192.0.2.10,239.1.1.1)
RPF: GigabitEthernet0/8/0 192.0.2.10
RPF-CHECK: PASS
Interfaces:
GigabitEthernet0/8/0 Flags: A NS
GigabitEthernet0/9/0 Flags: F NS
### RPF 실패 엔트리 — 소스가 예상치 않은 인터페이스로 유입됨
vpp# show ip mfib 239.1.1.1 detail
(192.0.2.10,239.1.1.1)
RPF: GigabitEthernet0/8/0 192.0.2.10 # 역방향 경로는 GE0/8/0 기대
RPF-CHECK: FAIL # 패킷이 GE0/9/0으로 들어와 RPF 불일치 → 드롭
Interfaces:
GigabitEthernet0/8/0 Flags: A NS
GigabitEthernet0/9/0 Flags: F NS
# RPF 실패 카운터 확인
vpp# show errors | grep mfib
ip4-mfib-forward-rpf 1234 RPF check failed # 이 카운터 증가 = RPF 드롭 발생
# 역방향 경로 확인 — RPF 인터페이스와 일치해야 함
vpp# show ip fib 192.0.2.10
ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ]
192.0.2.10/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:0 index:6 buckets:1 ]
[0] [@14]: ipv4 via 192.0.2.1 GigabitEthernet0/8/0: ... # GE0/8/0 이어야 RPF PASS멀티캐스트 트러블슈팅
- 수신자는 가입했는데 트래픽이 오지 않음 —
show ip mfib에서 해당 그룹의 Replication List에 downstream 인터페이스가 포함되어 있는지 확인합니다. IGMP 가입은 성공했지만 MFIB에 반영되지 않는 경우가 많습니다. - RPF check fail 카운터 증가 —
show errors에서ip4-mfib-forward-rpf의 drop을 확인합니다. 소스가 도달 가능한 유니캐스트 경로(역방향)와 일치하지 않으면 드롭됩니다.show ip fib <source>로 역방향 경로를 검증합니다. - 브릿지 도메인에서 트래픽이 모든 포트로 플러딩 — IGMP Snooping이 꺼져 있거나, Querier가 없어 스누핑 테이블이 비어 있을 가능성이 큽니다.
show ip igmp snoop으로 그룹별 포트 멤버십을 확인합니다.
IGMPv3 · MLDv2 그룹 관리
IGMP(IPv4)와 MLD(IPv6)는 호스트가 멀티캐스트 그룹에 가입/탈퇴하겠다고 라우터에 알리는 프로토콜입니다. VPP의 igmp 플러그인은 v1/v2/v3과 source-specific multicast(SSM)를 지원합니다.
IGMP v1 / v2 / v3 기능 비교
| 기능 | IGMPv1 | IGMPv2 | IGMPv3 |
|---|---|---|---|
| 그룹 탈퇴 | 없음 (타임아웃) | Leave Group | Leave Group + SSM |
| SSM (Source-Specific Multicast) | 미지원 | 미지원 | 지원 |
| RFC | 1112 | 2236 | 3376 |
| VPP 지원 | 없음 | 있음 | 있음 |
IGMPv3 CLI 예시
vpp# igmp proxy enable
vpp# set interface ip igmp <upstream-if> enable
vpp# set interface ip igmp <downstream-if> enable host
vpp# show igmp configIGMP Snooping
L2 브릿지 도메인에서 IGMP Snooping은 멀티캐스트 패킷이 그룹 가입자가 있는 포트로만 전달되도록 제어합니다. show ip igmp snoop 명령으로 BD별 스누핑 상태를 확인할 수 있습니다. VPP는 IGMP Query 패킷을 관찰해 Querier를 식별하고, Report를 받은 포트만 그룹 멤버로 등록합니다. Querier가 없으면 스누핑 테이블이 타임아웃으로 비워져 사실상 플러딩으로 동작합니다 — 운영 환경에서는 별도 IGMP Querier 역할을 하는 장비가 반드시 있어야 합니다.
IGMP 호스트 상태 머신
IGMPv3 호스트는 그룹별로 Non-Member → Delaying Member → Idle Member 상태를 가집니다. Query 수신 시 랜덤 지연 후 Report를 보내며, 다른 호스트의 Report를 먼저 관찰하면 자신의 Report를 억제(Report Suppression)합니다. 이는 Query 폭주 시 라우터 CPU 보호에 효과적이지만, 디버깅 시에는 show igmp config로 호스트 상태 전이를 추적해야 합니다.
IGMP 트러블슈팅
- Report 수신되는데 MFIB 갱신 안 됨 —
show igmp config에서 인터페이스가router모드로 활성화되어 있는지 확인합니다.host모드는 자신이 가입자일 때만 사용합니다. - SSM (S,G) join이 (*,G)로 잡힘 — IGMPv3에서만 source filter가 전달됩니다. v2 Report가 섞이면 소스 정보가 사라지므로 모든 라우터/호스트가 v3인지 확인합니다.
- Fast-leave 설정 후에도 지연 — Last-Member-Query 단계가 필요해 보통 1~2초가 남습니다. 즉시 탈퇴가 필요하면 fast-leave와 함께 LMQI(Last Member Query Interval)를 낮춥니다.
IGMP v2/v3 혼용 및 상태 머신
실제 네트워크에서는 v2와 v3 구현이 혼재하는 경우가 많습니다. IGMPv3 수신자가 있는 세그먼트에 IGMPv2 Querier가 등장하면, v3 멤버는 자동으로 v2 모드로 다운그레이드됩니다. 이는 RFC 3376의 하위 호환 규칙에 따른 것이며, 다운그레이드된 상태는 Older Version Querier Present Timeout(기본 400초) 동안 유지됩니다. 결과적으로 네트워크 전체가 최저 버전에 맞춰 동작하게 됩니다.
IGMP v2 상태 전이 다이어그램 (RFC 2236 기준):
그룹에 관심 없음
│
┌─────────────▼─────────────┐
│ Non-member │
└─────────────┬─────────────┘
│ 가입 의사 / Query 수신
▼
┌─────────────────────────────┐
│ Delaying Member │◄──── Query 수신 시
│ (랜덤 타이머 대기 중) │ 타이머 재설정
└──────┬──────────────┬───────┘
│ │
타이머 만료 │ │ 다른 호스트의 Report 수신
→ Report 전송 │ │ (Report Suppression)
▼ ▼
┌─────────────────────────────┐
│ Idle Member │
│ (멤버십 유지, 대기 상태) │
└─────────────┬───────────────┘
│ Leave Group 전송 또는
│ 그룹 관심 없어짐
▼
Non-member- 소스 필터링 불가: IGMPv3의 핵심 기능인
INCLUDE/EXCLUDE소스 필터링은 v3 Report에서만 전달됩니다. v2 Querier가 존재하거나 v2 모드로 다운그레이드된 환경에서는 소스 정보가 사라지며, (S,G) 엔트리가 생성되지 않고 (*,G)로 처리됩니다. SSM(Source-Specific Multicast)을 사용하는 서비스가 있다면 모든 장비가 v3인지 반드시 확인해야 합니다. - Report Suppression 비활성화: IGMPv3는 Report Suppression을 하지 않습니다. v2 환경에서는 한 호스트의 Report를 관찰하면 나머지는 억제하지만, v3에서는 모든 호스트가 독립적으로 응답합니다. 혼용 환경에서는 예측하기 어려운 Query 응답 패턴이 발생할 수 있습니다.
IGMP Querier 장애 시나리오 및 해결: 네트워크에 IGMP Querier가 없으면 호스트들이 더 이상 Report를 보내지 않으며, 라우터/스위치의 스누핑 테이블이 순차적으로 타임아웃되어 비워집니다. 결과적으로 모든 멀티캐스트 멤버십이 만료되고 트래픽이 차단됩니다. 진단 및 해결 절차:
# 1. 현재 Querier 및 스누핑 상태 확인
vpp# show ip igmp snoop
# Querier 항목이 비어 있거나 타이머가 매우 큰 경우 Querier 부재 의심
# 2. IGMP 설정 상태 및 Query 인터벌 확인 (FRR/BIRD 연동 시)
router# show ip igmp
router# show ip igmp interface
# General Query Interval 기본값 125초, 타이머 만료 시 그룹 재질의
# 3. Query interval 단축으로 빠른 재가입 유도
router(config-if)# ip igmp query-interval 30
# 인터벌을 줄이면 Querier 부재 탐지 속도가 빨라지고 멤버십 재구축 시간 단축
# 4. VPP 인터페이스에 Querier 역할 수동 지정
vpp# set interface ip igmp <if> enable
# VPP를 router 모드로 활성화하면 Query 발송 주체 역할 가능
# 5. 멤버십 복구 확인
vpp# show ip igmp snoop
vpp# show ip mfibBIER — Bit Indexed Explicit Replication
BIER(RFC 8279)는 전통적 멀티캐스트 트리 대신 패킷 헤더의 비트 마스크로 수신 라우터를 지정해 복제하는 방식입니다. 중간 라우터는 그룹 상태(state)를 유지할 필요가 없어 확장성이 뛰어납니다. VPP는 bier 플러그인으로 BIER 인코딩/디코딩, BFR(Bit-Forwarding Router) 역할, BIER over MPLS·SRv6 전송을 지원합니다.
vpp# bier table add bsl 256 sub-domain 0 set 0
vpp# bier route add <prefix> next-hop <ip> bp <bit-position>
vpp# show bier fib
vpp# show bier disp
vpp# show bier impBIER 도메인 설계 및 출력 해석
BSL(Bit String Length)은 도메인에 수용할 수 있는 BFER 수를 결정하며, 값이 클수록 BIER 헤더 크기가 증가합니다. 운영 환경에 맞는 BSL을 선택하는 기준은 아래 표를 참고합니다.
| BSL | 헤더 크기 | 최대 노드 수 | 권장 시나리오 |
|---|---|---|---|
| 64 | 8B | 64노드 | 소규모 랩·PoC 환경. MTU 부담 최소. |
| 128 | 16B | 128노드 | 중소형 클러스터. 일반 1500B MTU 운용 가능. |
| 256 | 32B | 256노드 | 데이터센터 중간 규모. Jumbo frame 권장. |
| 512 | 64B | 512노드 | 대규모 멀티캐스트 망. Jumbo frame 필수. |
show bier fib, show bier disp, show bier imp 세 명령의 출력 예시와 각 필드 의미입니다.
vpp# show bier fib
# BIER FIB: 각 bit-position(bp)에 대한 underlay next-hop 매핑
BIER-FIB: sub-domain:0 set:0 bsl:256
bp:1 via: 192.0.2.1 GigabitEthernet0/8/0 weight:1 # bp 1번 BFER → GE0/8/0 통해 192.0.2.1로 전달
bp:2 via: 192.0.2.2 GigabitEthernet0/9/0 weight:1 # bp 2번 BFER → GE0/9/0 통해 192.0.2.2로 전달
bp:3 via: 192.0.2.3 GigabitEthernet0/10/0 weight:1 # bp 3번 BFER → GE0/10/0 통해 192.0.2.3으로 전달
vpp# show bier disp
# BIER Disposition: 이 노드가 BFER일 때 페이로드를 어디로 넘길지 지정
BIER-DISP: sub-domain:0 set:0 bsl:256
etype:ipv4 dpo:[ip4-lookup:0] # IPv4 페이로드 → 일반 ip4-lookup으로 전달
etype:ipv6 dpo:[ip6-lookup:0] # IPv6 페이로드 → ip6-lookup으로 전달
vpp# show bier imp
# BIER Imposition: 송신 시 패킷에 설정될 BitString과 next-hop 집합
BIER-IMP: sub-domain:0 set:0 bsl:256
bitstring: 0x0000000000000000000000000000000000000000000000000000000000000007
# bitstring의 하위 비트 3개(bit 0~2)가 1 → bp 1·2·3 세 BFER에 복제
via: GigabitEthernet0/8/0 192.0.2.1 (bp:1) # 첫 번째 복제 경로
via: GigabitEthernet0/9/0 192.0.2.2 (bp:2) # 두 번째 복제 경로
via: GigabitEthernet0/10/0 192.0.2.3 (bp:3) # 세 번째 복제 경로| 필드 | 위치 | 설명 |
|---|---|---|
sub-domain | FIB / DISP / IMP 공통 | BIER 도메인 내 하위 집합 식별자. 여러 sub-domain을 분리 운용할 때 사용합니다. |
set | FIB / DISP / IMP 공통 | 동일 sub-domain 안에서 BSL별로 나뉜 Set Identifier. BSL이 크면 여러 Set으로 분할됩니다. |
bsl | FIB / DISP / IMP 공통 | Bit String Length. 64·128·256·512 중 하나. 클수록 더 많은 BFER를 한 도메인에 수용합니다. |
bp | BIER FIB | Bit Position. 해당 BFER에 할당된 고유 번호. BitString의 bp번째 비트가 1이면 이 BFER로 전달합니다. |
via | BIER FIB | 해당 bp에 도달하기 위한 underlay next-hop IP와 출력 인터페이스. |
etype | BIER DISP | BIER 페이로드 유형 (ipv4 / ipv6 / mpls 등). Disposition 시 이 타입에 맞는 DPO로 넘깁니다. |
dpo | BIER DISP | 페이로드를 전달할 DPO(Data-Path Object). 보통 ip4-lookup 또는 ip6-lookup. |
bitstring | BIER IMP | 현재 패킷에 담긴 BitString 값. 각 비트가 1인 위치가 수신 대상 BFER를 나타냅니다. |
언리졸브된 next-hop 에러 증상 및 해결: show bier fib에서 특정 bp의 via 항목이 표시되지 않거나 next-hop이 unresolved로 나타나면, BIER underlay(unicast FIB)에 해당 경로가 없는 것입니다.
# 1. BIER FIB에서 미해석 next-hop 확인
vpp# show bier fib
BIER-FIB: sub-domain:0 set:0 bsl:256
bp:4 via: 192.0.2.4 # 인터페이스 없음 → unresolved 상태
# 2. underlay unicast FIB에서 해당 주소 경로 확인
vpp# show ip fib 192.0.2.4
ipv4-VRF:0, fib_index:0
192.0.2.4/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:0 index:9 buckets:1 ]
[0] [@14]: ipv4 via 192.0.2.254 GigabitEthernet0/11/0: ...
# 위와 같이 해석된 경로가 있어야 BIER FIB next-hop이 정상 등록됨
# 3. 경로가 없으면 정적 경로 또는 라우팅 프로토콜로 추가
vpp# ip route add 192.0.2.4/32 via 192.0.2.254 GigabitEthernet0/11/0show bier disp에 etype 엔트리가 없으면 Disposition이 설정되지 않은 것이므로 이 노드는 BFER 역할을 수행할 수 없습니다. bier route add가 올바른 sub-domain·set·bsl 조합으로 입력됐는지, 그리고 underlay FIB에 next-hop 경로가 해석되어 있는지를 함께 확인합니다.
BIER 헤더와 복제 동작
BIER 헤더는 BSL(BitString Length), Sub-domain, Set Identifier, BitString 네 필드로 구성됩니다. BSL 256 기준으로 32바이트 비트 스트링이 붙으며, 각 비트는 특정 Egress BFER(Bit-Forwarding Egress Router)를 지시합니다. 중간 BFR은 자신의 BIFT(Bit Index Forwarding Table)를 참조해 비트가 가리키는 next-hop 집합별로 패킷을 분할하고, 각 복사본에서는 해당 next-hop 경로의 비트만 남기고 나머지는 0으로 마스킹합니다. 이로써 동일 next-hop으로 가는 여러 BFER들이 한 번의 복제로 도달합니다.
BIER 트러블슈팅
- BFER가 패킷을 수신하지 못함 —
show bier fib로 해당 bit-position의 next-hop이 올바른지, 그리고show bier disp로 disposition 엔트리가 etype별로 등록되어 있는지 확인합니다. - 중간 BFR에서 드롭 — BSL 값이 다른 BIFT끼리 만나면 호환되지 않습니다. 도메인 전체가 동일한 BSL·sub-domain을 쓰는지 확인합니다.
- MPLS/SRv6 전송 시 파싱 실패 — BIER는 보통 MPLS 레이블 또는 SRv6 함수 뒤에 실립니다. 캡슐화 순서가 송수신 양단에서 일치해야 합니다.
MPLS · SR-MPLS
VPP는 Multi-Protocol Label Switching을 mpls 네임스페이스에서 별도 FIB로 관리합니다. Label Edge Router(LER)와 Label Switching Router(LSR) 역할을 모두 지원하며, PHP(Penultimate Hop Popping), ECMP, Fast Reroute(FRR) 같은 운영 기능도 제공합니다. Segment Routing for MPLS(SR-MPLS)는 상위에서 SID 리스트를 통해 경로를 지정합니다.
MPLS FIB 구성
vpp# mpls table add 0
vpp# set interface mpls <if> enable
vpp# mpls local-label add 100 eos ip4-lookup-in-table 0
vpp# ip route add 10.0.0.0/24 via 192.168.1.1 <if> out-labels 200
vpp# show mpls fib
vpp# show mpls tunnelMPLS 포워딩 경로 내부
수신 패킷이 MPLS로 식별되면 mpls-input 노드가 top-of-stack 레이블을 읽어 mpls_lookup으로 진입합니다. 매칭된 MPLS 엔트리는 DPO로 다음 중 하나를 가집니다:
- Swap —
mpls-output노드에서 레이블을 교체하여 next-hop으로 전달합니다. - Pop + Lookup — 마지막 LSR이 레이블을 제거하고 내부 IP 헤더로
ip4-lookup/ip6-lookup을 재실행합니다(PHP). - Push — LER가 IP 패킷에 out-label을 붙여 MPLS 경로에 주입합니다.
ECMP는 레이블 스택 해시로 분산하고, FRR은 backup path DPO를 미리 설치해 링크 장애 시 즉시 전환합니다.
MPLS 트러블슈팅
- 레이블 드롭 (
mpls-inputerror) —show mpls fib에 해당 local-label이 없거나, 인바운드 인터페이스에서set interface mpls <if> enable이 빠진 경우입니다. - PHP 후 IP 라우팅 실패 — Pop 이후
ip4-lookup-in-table이 지정한 테이블에 경로가 있어야 합니다. MPLS와 IP VRF 테이블 매핑을 재확인합니다. - TTL copy-mode 혼선 — MPLS 진입 시 IP TTL을 MPLS TTL로 복사할지, 고정값으로 할지에 따라 traceroute 결과가 달라집니다.
uniformvspipe모드를 명확히 합니다.
SR-MPLS 정책
SR-MPLS는 IPv6가 아닌 환경에서 segment routing을 실현합니다. 정책은 binding SID로 식별되며, 트래픽을 특정 SID 리스트로 라우팅합니다.
vpp# sr mpls policy add bsid 1000 next 2001 next 2002 next 2003
vpp# sr mpls steer l3 10.0.0.0/24 via sr policy bsid 1000LISP — Locator/ID Separation Protocol
LISP(RFC 6830)는 IP 주소를 EID(Endpoint Identifier)와 RLOC(Routing Locator)로 분리합니다. 모바일성·멀티호밍·세그먼트 간 연결에 유리합니다. VPP는 lisp 플러그인으로 ITR/ETR/MR/MS 역할과 Map-Request/Map-Reply 컨트롤 평면, LISP-GPE 캡슐화를 지원합니다.
vpp# lisp enable
vpp# lisp eid-table add vni 0 eid 10.1.0.0/16
vpp# lisp locator-set add-del name ls1 iface <if> p 1 w 1
vpp# lisp map-register enable
vpp# lisp map-server add 192.0.2.1LISP-GPE (Generic Protocol Extension)
LISP-GPE는 LISP 헤더에 next-protocol 필드를 추가해 이더넷 프레임, MPLS 패킷, NSH 서비스 헤더 등을 실을 수 있게 확장합니다. VPP는 lisp-gpe 노드로 이를 인코딩·디코딩합니다.
LISP 컨트롤 평면 흐름
ITR(Ingress Tunnel Router)이 EID → RLOC 매핑이 없는 패킷을 받으면, 패킷을 임시로 큐에 넣고 Map-Request를 Map-Resolver에 보냅니다. Map-Resolver는 ETR 쪽으로 요청을 포워딩하고, ETR(또는 Map-Server)은 Map-Reply를 ITR에게 직접 전달합니다. 수신된 매핑은 VPP의 Map-Cache에 저장되어 TTL 동안 재사용됩니다. 매핑이 없으면 lisp-input에서 drop 카운터가 증가합니다.
vpp# show lisp map-cache
vpp# show lisp eid-table
vpp# show lisp pitr
vpp# show lisp statusLISP 트러블슈팅
- Map-Reply가 오지 않음 — ETR 쪽
lisp map-register가 enable이어도 Map-Server가 해당 EID를 수락했는지, 그리고 양쪽이 같은 인증 키(HMAC)를 쓰는지 확인합니다. - EID 간 통신 비대칭 — 한쪽 맵 캐시는 채워져 있고 다른 쪽은 비어 있을 수 있습니다. 양단 모두에서
show lisp map-cache를 확인합니다. - RLOC 이동 후 수렴 지연 — VPP는 SMR(Solicit-Map-Request)을 발송해 이전 ITR의 캐시를 무효화합니다. 방화벽이 SMR을 차단하면 TTL 만료까지 수렴이 지연됩니다.
BFD — Bidirectional Forwarding Detection
BFD(RFC 5880)는 밀리초 단위로 인접 장비의 장애를 감지하는 경량 프로토콜입니다. BGP·OSPF 같은 라우팅 프로토콜이 수 초~수십 초가 걸려 감지하는 장애를 수십 밀리초 내에 포착해 빠른 경로 전환을 가능하게 합니다.
vpp# bfd udp session add interface <if> local-addr 10.0.0.1 peer-addr 10.0.0.2 desired-min-tx 100000 required-min-rx 100000 detect-mult 3
vpp# show bfd sessions위 설정은 100ms × 3배 = 300ms 안에 장애를 감지합니다. 실제 운영에서는 라우팅 프로토콜(FRR/BIRD)과 연동해 경로 fail-over를 자동화합니다.
Echo mode
BFD에는 asynchronous와 echo 두 모드가 있습니다. Echo 모드는 로컬이 보낸 패킷을 상대가 되돌려 주기만 하므로 상대 CPU를 덜 쓰고 더 공격적인 타이머(수십 ms)가 가능합니다. 단, 상대도 echo를 지원해야 합니다.
BFD 세션 상태 머신
BFD 세션은 AdminDown → Down → Init → Up 4개 상태로 전이합니다. 각 패킷 헤더의 My Discriminator, Your Discriminator, 상태 필드를 통해 쌍방 상태를 교환하며, detect-mult × required-min-rx 동안 패킷이 수신되지 않으면 Down으로 전환됩니다. VPP는 밀리초 정밀 타이머를 위해 별도 워커 스레드에서 BFD 이벤트를 처리하여 벡터 포워딩 지연에 영향받지 않게 합니다.
BFD 트러블슈팅
- 세션이 Init에서 Up으로 올라가지 않음 — 한 방향만 패킷이 도달하는 경우입니다. 방화벽/ACL이 UDP 3784(control)·3785(echo)·4784(multihop)를 양방향으로 허용하는지 확인합니다.
- 간헐적 flapping —
detect-mult가 너무 낮거나, CPU 오버커밋으로 워커가 주기적으로 지연되는 경우입니다.show runtime에서 BFD 노드 벡터 크기와 지터를 확인합니다. - Echo 모드 활성화 실패 — 양단 모두 echo 지원 확인 후, 패킷이 송신자에게 그대로 되돌아오는 L3 경로가 존재하는지(즉, 상대가 loopback 포워딩을 허용하는지) 검증합니다.
BFD 패킷 TOS/DSCP 설정 (VPP 25.10 신기능)
VPP 25.10부터 BFD UDP 패킷의 IP TOS 바이트(IPv4) 또는 트래픽 클래스(IPv6)를 전역으로 설정할 수 있습니다. BFD 제어 패킷이 네트워크 장비에서 DSCP 기반 우선 처리를 받도록 마킹할 때 유용합니다.
- 신규 바이너리 API:
bfd_udp_set_tos/bfd_udp_get_tos— 전역 단일 값으로 모든 세션에 적용됩니다. CLI 명령은 없으며 API 전용입니다. - 기본값:
0xC0(소스 코드BFD_UDP_DEFAULT_TOS기준). DSCP EF(Expedited Forwarding)를 원하면0xB8을 설정합니다.
BFD + BGP 페일오버 연동
BFD 세션을 BGP 이웃과 연동하면 BGP keepalive 타이머(기본 180초)를 기다리지 않고 수십 밀리초 내에 이웃 장애를 감지해 경로를 전환할 수 있습니다. VPP에서 BFD 세션을 생성하고, FRR/BIRD 같은 라우팅 데몬에서 해당 BGP 이웃에 BFD 연동을 선언합니다.
# 1. VPP에서 BFD UDP 세션 생성 (bfd-key-id로 인증 키 연결)
vpp# bfd udp session add interface GigabitEthernet0/8/0 \
local-addr 10.0.0.1 peer-addr 10.0.0.2 \
desired-min-tx 100000 required-min-rx 100000 detect-mult 3 \
bfd-key-id 1
# 2. FRR BGP 데몬에서 해당 이웃에 BFD fall-over 선언
router(config-router)# neighbor 10.0.0.2 fall-over bfd
# BGP 이웃 10.0.0.2가 BFD Down을 수신하면 즉시 BGP 세션 해제 → 경로 철회
# 3. 멀티홉 BGP 이웃 (eBGP over multiple hops)
vpp# bfd udp session add interface GigabitEthernet0/8/0 \
local-addr 10.0.0.1 peer-addr 203.0.113.1 \
desired-min-tx 300000 required-min-rx 300000 detect-mult 3 \
multihop
# 멀티홉 세션은 UDP 4784 포트를 사용
# 4. 세션 상태 확인
vpp# show bfd sessionsBFD 에코 모드 활성화/비활성화 결정: 에코 모드는 로컬이 보낸 패킷을 상대가 그대로 되돌려 주기 때문에 더 낮은 타이머(수십 ms)로 빠른 감지가 가능합니다. 그러나 방화벽이나 ACL이 에코 패킷(UDP 3785, 소스 = 목적지 = 로컬 주소)을 차단하거나 대칭 경로가 보장되지 않는 환경에서는 에코 모드가 동작하지 않으므로 비활성화해야 합니다.
# 에코 모드 비활성화 (방화벽이 에코 패킷 차단 시)
vpp# bfd udp session mod interface GigabitEthernet0/8/0 \
local-addr 10.0.0.1 peer-addr 10.0.0.2 \
desired-min-echo-tx 0
# desired-min-echo-tx 0 = 에코 모드 사용 안 함show bfd sessions 출력 해석:
vpp# show bfd sessions
# 각 필드 의미
Index State If Local Remote Tx(us) Rx(us) DMult Demand
0 Up GigE0/8/0 10.0.0.1 10.0.0.2 100000 100000 3 No
# ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
# 세션 ID 현재 상태 인터페이스 로컬 주소 피어 주소 Tx간격 Rx간격 감지배수 Demand모드
# State 값과 의미:
# AdminDown : 관리자가 세션을 비활성화함
# Down : 연결 없음 또는 초기 협상 전
# Init : 로컬이 Down 상태에서 상대의 BFD 패킷을 수신한 상태 (단방향 수신)
# Up : 양방향 BFD 패킷 수신 확인, 세션 정상
# Tx(us) / Rx(us): 협상된 송신/수신 간격 (마이크로초)
# DMult: detect-mult — 이 배수만큼 Rx 간격 동안 패킷이 없으면 Down
# Demand: Demand 모드 활성화 여부 — Yes이면 주기 전송 없이 Poll 방식으로 동작Init 상태는 로컬이 상대의 BFD 패킷을 수신했으나 상대가 로컬 패킷을 아직 수신하지 못한 단방향 상태입니다. 양방향 수신이 확인되어야 Up으로 전이합니다. 다음 순서로 방화벽/ACL을 확인합니다:
- UDP 3784 양방향 허용 여부 확인 — BFD 제어 패킷(Control)은 UDP 3784를 사용합니다. 로컬 → 피어, 피어 → 로컬 양방향이 모두 열려 있어야 합니다.
- UDP 3785 에코 패킷 허용 여부 — 에코 모드 사용 시 UDP 3785도 개방되어야 합니다. 에코 패킷은 소스 IP = 목적지 IP(로컬 주소)로 전송되므로 방화벽의 anti-spoofing 규칙에 의해 차단될 수 있습니다.
- 멀티홉 세션: UDP 4784 허용 여부 — 멀티홉 BFD는 UDP 4784를 사용합니다. 단일 홉 세션과 별도로 ACL을 확인합니다.
- TTL/Hop Limit 확인 — 단일 홉 BFD는 TTL=255로 전송하며 수신측도 TTL=255를 기대합니다. NAT나 프록시가 TTL을 변경하면 패킷이 거부됩니다.
- 패킷 캡처로 실제 도달 여부 검증 —
tcpdump -i <if> udp port 3784로 양단에서 패킷 유입/유출을 직접 확인합니다.
BFD 포트 참조: 제어 패킷 UDP 3784, 에코 패킷 UDP 3785, 멀티홉 제어 UDP 4784