멀티캐스트 · MPLS · LISP

VPP의 멀티캐스트 처리(IGMPv3/MLDv2/BIER), MPLS 및 SR-MPLS 레이블 스위칭, LISP 컨트롤 평면, BFD 빠른 장애 감지 등 L3 제어 평면 확장 기능을 정리합니다.

이 문서의 범위: VPP의 멀티캐스트 처리, MPLS/SR-MPLS 레이블 스위칭, LISP 컨트롤 평면, BIER 비트 인덱스 복제 등 L3 제어 평면 및 확장 라우팅 기능을 한 곳에 정리합니다. 기본 L2/L3 노드와 FIB는 데이터 경로 (L2~L4)에서 먼저 확인해 주시기 바랍니다.

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
모델: VPP MFIB는 (*, 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 replicate

멀티캐스트 트러블슈팅

증상별 체크리스트:
  • 수신자는 가입했는데 트래픽이 오지 않음 — 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)를 지원합니다.

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 config

IGMP 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)를 낮춥니다.

BIER — 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 imp

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 tunnel

MPLS 포워딩 경로 내부

수신 패킷이 MPLS로 식별되면 mpls-input 노드가 top-of-stack 레이블을 읽어 mpls_lookup으로 진입합니다. 매칭된 MPLS 엔트리는 DPO로 다음 중 하나를 가집니다:

ECMP는 레이블 스택 해시로 분산하고, FRR은 backup path DPO를 미리 설치해 링크 장애 시 즉시 전환합니다.

MPLS 트러블슈팅

  • 레이블 드롭 (mpls-input error) — 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 결과가 달라집니다. uniform vs pipe 모드를 명확히 합니다.

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 1000
SRv6와의 관계: SRv6(오버레이 — SRv6)는 IPv6 패킷 헤더 자체에 세그먼트 리스트를 넣고, SR-MPLS는 MPLS 레이블 스택으로 같은 개념을 표현합니다. 둘은 상호 배타적이지 않으며, 데이터센터는 SRv6를, 기존 MPLS 백본은 SR-MPLS를 선호하는 경향이 있습니다.

LISP — 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.1

LISP-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 status

LISP 트러블슈팅

  • 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)·4784(echo)·6784(multihop)를 양방향으로 허용하는지 확인합니다.
  • 간헐적 flapping — detect-mult가 너무 낮거나, CPU 오버커밋으로 워커가 주기적으로 지연되는 경우입니다. show runtime에서 BFD 노드 벡터 크기와 지터를 확인합니다.
  • Echo 모드 활성화 실패 — 양단 모두 echo 지원 확인 후, 패킷이 송신자에게 그대로 되돌아오는 L3 경로가 존재하는지(즉, 상대가 loopback 포워딩을 허용하는지) 검증합니다.