개념

vtysh

            +-----------------------+
            |  vtysh (통합 CLI)     |
            +-----------+-----------+
                        | ZAPI
    +-------------------+-------------------+
    | zebra  <--- Unix sockets ----> bgpd   |
    |  ^          (ZAPI)              ^     |
    |  |                               |    |
    |  |                               |    |
    |  +-- Netlink (kernel RIB/FIB) ---+    |
    +---------------------------------------+
            Linux kernel (ip route/FIB)

vtysh는 FRRouting(FRR) · Quagga 라우팅 스택에서 제공하는 통합 CLI 프론트엔드입니다. 개별 데몬(bgpd, ospfd, zebra 등)을 각각 telnet · VTY 포트를 열어 접속할 필요 없이 하나의 셸 안에서 모든 라우팅 프로세스를 제어 · 구성할 수 있게 해 줍니다.

vtysh <<-EOF

위 블록이 실행되면 vtysh 프로세스가 한 번만 띄워져 내부에서 연속 명령을 수행하고 종료합니다. 따라서 컨테이너 부팅 시 라우팅 설정이 일괄 적용되고, 별도의 bgpd.conf 편집이나 데몬 재시작이 필요 없습니다. _seongtki-2

Route-Reflector 스크립트 역시 같은 방식으로 BGP Peer-Group과 RR 지시자를 한 번에 넣습니다.

주요 모드 & 기본 명령

비-대화식 팁 :

1. 짧은 조회만 할 땐 vtysh -c 'show bgp l2vpn evpn'.

2. 설정 자동화는 과제처럼 Here-Doc 이 가장 안정적입니다.

파일 기반 구성과의 관계

• vtysh 에서 입력한 설정은 동시에 각 데몬별 conf 파일(예: /etc/frr/bgpd.conf, ospfd.conf)에도 기록됩니다.

• 반대로 파일을 직접 고친 뒤 systemctl reload frr(또는 데몬별 재시작)를 해도 vtysh에 즉시 반영됩니다.

FRR(FRRouting) 와 zebra

| 구분 | FRR (FRRouting) | zebra | | ——— | ————————————————————————————————————————————————————————- | ————————————————————————————————————— | | 본질 | ● 오픈소스 라우팅 소프트웨어 스위트
• BGP, OSPF, IS-IS, RIP, PIM, LDP, EVPN … 등 각종 프로토콜 데몬 모음
• 리눅스, _BSD, 컨테이너, 가상 라우터, 화이트박스 스위치_에서 사용 | ● FRR (과거 Quagga·Zebra 프로젝트) 내부의 핵심 데몬
• “Routing Information Base (RIB) · FIB 관리자” 역할 | | 역사 | • 1996 ‘Zebra’ → 2005 ‘Quagga’ → 2016 ‘FRRouting’로 포크·발전
• 대형 벤더(구글·메타·엔비디아·클라우드플레어 등)와 커뮤니티가 공동 유지 | • 원래 Zebra 프로젝트의 메인 데몬 이름.
• FRR/Quagga로 넘어오면서도 프로세스 이름은 그대로(zebra) | | 주요 구성 | zebra + 각 프로토콜 데몬
    bgpd (= BGP) · ospfd · isisd · pimd … | • 커널 라우팅 테이블(넷링크)과 프로토콜 데몬 사이 단일 RIB 유지
• ARP/ND 프로그래밍, interface state 감시, 정책(ECMP, preference) 결정 | | 동작 흐름 | 1️⃣ 인터페이스 up/down·주소 변동 감지 → zebra
2️⃣ zebra 가 각 프로토콜 데몬에 ZAPI(소켓)로 이벤트 전파
3️⃣ 프로토콜 데몬이 계산한 경로를 zebra 로 보냄
4️⃣ zebra 가 “최적 경로” 선별 → 커널 FIB install | 즉, zebra 는
• 프로토콜 간 경로 경쟁(BGP vs. OSPF) arbitrator
• 커널과 사용자가 보는 실제 Forwarding Table(FIB)의 최종 책임자 | | CLI | vtysh 로 접속하면 zebra + 각 데몬을 한 셸에서 다룸 | zebra 자체 CLI(zebra#)도 존재하지만, 실무에서는 vtysh 로 통합 사용 | | 과제 맥락 | • 우리가 작성한 스크립트에서 vtysh <<EOF … EOF 블록은 FRR 전반 설정
• BGP EVPN(Route Type 2/3)과 OSPF 모두 FRR 안에 포함 | • Leaf·Spine 모두 zebra 가 모든 인터페이스·경로를 커널에 반영
• 핑·VXLAN 캡슐 트래픽이 실제로 흐르는 이유는 zebra 가 FIB 를 밀어 넣었기 때문 |

핵심 요약

• FRR = BGP·OSPF·EVPN 등 다수 프로토콜 데몬 + zebra 로 이루어진 오픈소스 라우터 제품군

• zebra = FRR 내부 중앙 RIB/FIB 관리자로, 커널과 다른 데몬 사이 허브·조정자 역할

• 과제 스크립트에서 vtysh 로 입력하는 모든 설정은 결국 zebra가 커널에 실제 경로를 프로그래밍하기 때문에 호스트 간 VXLAN 트래픽이 올바르게 전달됩니다.

OSPF

Open Shortest Path First==의 약자입니다. OSPF는 동적 라우팅 프로토콜 중 하나이며, 링크 상태 라우팅 프로토콜의 대표적인 예시입니다. 이는 네트워크의 링크 상태를 감시하여 최단 경로를 계산하고 이를 통해 라우팅 정보를 결정합니

코드

역할 : underlay IP 라우팅(OSPF) + overlay 제어(BGP EVPN) 를 한 곳에서 반사.
특징 : Leaf 를 자동 수용하기 위해 Peer‑Group + bgp listen 기법 사용.

EVPN 발표 RR : neighbor ibgp route-reflector-client Leaf : advertise-all-vni

OSPF Area 0

• OSPF(Open Shortest Path First)는 링크 상태 IGP입니다.
• Area = 라우팅 정보의 스코프(경계).
• Area 0 = 백본. 모든 다른 Area 는 반드시 0 을 통해 상호 연결.
• 이번 과제 목표 : 스파인(RR)과 모든 Leaf 를 Area 0 하나로 묶어 underlay 경로를 단순화.

ASN 1, iBGP, router bgp 1

• ASN = Autonomous System Number.
• router bgp 1 → 이 장비는 AS 1 소속임을 선언.
• iBGP(internal BGP) = AS 내부에서 맺는 BGP 세션(AS 번호가 같음).
• iBGP 는 Full‑Mesh 가 원칙 → 모두가 모두와 연결해야 경로가 돌지 않음.
  • 스케일 문제를 해결하려고 Route‑Reflector 를 씀.

Route‑Reflector(RR)

• iBGP 규칙 : iBGP 로 받은 경로는 다른 iBGP 이웃에게 다시 보내면 안 된다.
• RR 는 예외 권한을 받아 클라이언트 간 경로를 ‘반사’(재배포) 할 수 있는 노드.
  • RR == 메시지를 모아 다른 인원에게 재전달.

EVPN & address‑family l2vpn evpn

• EVPN = Ethernet VPN. BGP 가 MAC·IP·VNI 정보를 라우팅 경로(NLRI) 로 싣도록 정의.
• address-family l2vpn evpn = BGP 세션에서 AFI 25 / SAFI 70(EVPN) 공간에 들어가겠다는 뜻.
• 여기서만 advertise-all-vni, route-reflector-client 같은 EVPN 전용 명령을 쓴다.\

VXLAN VNI 10 (데이터플레인) vs EVPN (컨트롤플레인)

• VXLAN : L2 프레임을 UDP 4789 로 캡슐화해 IP 망 위를 흘린다.
• VNI = VXLAN Network Identifier(24 bit) → VLAN 처럼 L2 도메인 구분.
• 컨트롤플레인 : “MAC A 는 VTEP‑IP 1.1.1.2 쪽에 있다” 같은 메타데이터를 EVPN(Route Type 2) 로 전파.
• 데이터플레인 : 실제 트래픽을 VXLAN 캡슐로 전송.

Loopback 인터페이스 vs eth0/1/2

• Loopback 은 장비의  고정 주소. BGP TCP 세션도 Loopback ↔ Loopback 로 맺어 두면, 어느 한쪽 물리 인터페이스가 바뀌어도 세션이 지속된다

EVPN NLRI (Network Layer Reachability Information)

OSPF Area 0 로 IP 기반 토대를 깔고,
iBGP(AS 1) 세션을 Loopback ↔ RR 로 맺은 뒤,
Route‑Reflector 가 EVPN Type 2/3 경로를 반사하여
Leaf‑VTEP 들이 VXLAN VNI 10 상에서 L2 통신을 자동으로 완성한다.

Underlay ↔ Overlay

컨트롤 플레인 연결 — “BGP EVPN”

1. OSPF 가 먼저 Underlay IP 경로(Loopback 포함)를 만듭니다.
2. 그 경로를 이용해 BGP TCP 세션이 열립니다.
3. address-family l2vpn evpn 블록 때문에 같은 세션 안에서
   Type 2 (MAC/IP), Type 3 (Inclusive Multicast) … NLRI 가 오갑니다.
   → Overlay 위치 정보(“VNI 10 의 MAC-A 는 VTEP 1.1.1.2”) 가 전 세계 Leaf 로 퍼짐.

즉 EVPN 설정이 “Underlay 위에서 Overlay 메타데이터를 교환하도록 BGP를 확장”하는 역할을 합니다.

이터 플레인 연결 — “VXLAN 터널링”

• Leaf-2 가 EVPN Type 2 를 보고 MAC-A → VTEP-IP 1.1.1.2 (Leaf-1) 를 FDB 에 기록.

• Host-2 → MAC-A 프레임이 나오면

1. Leaf-2 가 프레임을 VXLAN 헤더 + UDP 4789 + IP(1.1.1.2) 로 캡슐,

2. Underlay IP 라우팅(OSPF) 이 그 패킷을 Leaf-1 로 전달,

3. Leaf-1 이 디캡슐·브리지 → Host-1 수신.

Overlay 트래픽이 물리·IP 경로를 전혀 모른 채 목적지에 도달하는 이유가 바로 이 구조입니다.

BGP EVPN 설정이 “Underlay에 올라탄 컨트롤-플레인 다리(Bridge)”,
VXLAN 캡슐화가 “Underlay에 올라탄 데이터-플레인 다리” 역할을 하며
둘 다 VTEP(Leaf) 안에서 만납니다.

(1) Host-1 전원 ON → ARP Request “20.1.1.1 is-at MAC-A” 브로드캐스트
        │
(2) Leaf-1 브리지(br0)   ▶  MAC-A 를 FDB(local) 에 학습 (bridge-learning)
        │      ↑ Netlink FDB_NOTIFY
(3) zebra (FRR)          ▶  “새 local MAC, VNI 10” 이벤트 수신
        │      ↑ ZAPI
(4) bgpd (EVPN AF)       ▶  Type 2 UPDATE 작성:
        │                     NLRI = {VNI 10, MAC-A, (선택)IP 20.1.1.1}
        │                     Next-Hop = 1.1.1.2 (Leaf-1 Loopback)
        ├─►  Route-Reflector(RR)  (iBGP)
        │            │
        │            └─► Leaf-2 / Leaf-3  (Reflect)
(5) Remote bgpd        ▶  NLRI 수신 → zebra 로 전달
        │
(6) Remote zebra       ▶  `bridge fdb append <MAC-A> dst 1.1.1.2 dev vxlan10`
        │
(7) Host-2 가 MAC-A 로 L2 프레임 전송 → Leaf-2 가 FDB 조회
        ▼
VXLAN Encapsulation (dst IP = 1.1.1.2) → Underlay → Leaf-1 → Host-1