728x90
반응형
1. BGP PIC(Prefix Independent Convergence) Core
- PIC는 Data Plane Convergence Time을 줄이는 기능
- Core 라우터 장애 발생 시, IGP가 BGP Next-Hop에 대한 New Best-Path를 찾는 Convergence Time을 단축
- Core 라우터 장애 발생 시, BGP Next-Hop은 변경되지 않고 IGP가 New Path를 찾는 경우에 도움
- BGP PIC Core는 간단히 참고만 하면 된다고 판단
- PIC 학습이 필요하지만 시간이 없으면 '4) Introduction to Hierarchical FIB' 부분만 학습하는 것을 권장
- 옛날 장비에서 BGP Prefix는 Recursed Next-Hop과 OIF가 있는 Flat FIB에 설치되므로 Next-Hop이 변경되면 FIB 테이블에서 많은 정보를 변경
- Hierarchical FIB는 BGP Next-Hop 및 IGP Next-Hop을 따로 저장하여 IGP Next-Hop이 변경되어도 테이블 전체를 변경할 필요가 없어져 Data Plane에서 Convergence Time 단축
2. BGP PIC Core Sample Configuration
1) BGP PIC Core Sample Configuration 구성도
- 테스트 장비
- 에뮬레이터 : EVE-NG
- 라우터 : Cisco IOL I86BI_LINUX-ADVENTERPRISEK9-M, Version 15.5(2)T
- OSPF에 포함되는 Interface는 모두 Point-to-Point로 구성
- AS1에는 R5가 Route-Reflector가 되도록 구성
- R1이 R4로 향하는 경로 중, 선호하는 Next-Hop이 R3가 되도록 R6의 Loopback Interface Cost을 크게 설정
2) BGP Basic Configuration
3) Introduction to BGP PIC Core
- R1에서 BGP로 학습한 두 개의 NLRI의 Next-Hop은 3.3.3.3
- R1→R4로 통신하고자 할 때, 현재 트래픽 경로는 R1→R2→R3→R4를 사용
- BGP Next-Hop인 3.3.3.3은 OSPF를 통해 학습하였으며 BGP Next-Hop에 도달하기 위해 Next-Hop이 1.1.2.2이며 OIF는 e0/2를 사용
- 옛날 네트워크 장비는 Recursive Lookup을 통한 라우팅 처리
- BGP로 학습한 4.4.4.4/32에 도달하기 위해 BGP Next-Hop을 3.3.3.3을 사용하며 3.3.3.3/32으로 통신하려면 Next-Hop이 1.1.2.2이며 OIF는 e0/2를 사용
- 현재 BGP NLRI가 2개뿐이지만 대형 네트워크처럼 몇 백만 개의 NLRI를 학습했다면 문제 발생
- 이유는 아래 참고
- R2인 Provider 장비 Failure 시, R1에 발생되는 영향을 알기 위해 Debug를 설정
- R2 장비 Failure를 구현하기 위해 모든 인터페이스를 Shutdown
- R2 Failure 후, R1에서 BGP Next-Hop인 3.3.3.3으로 가는 New Best-Path를 탐색
- 3.3.3.3/32로 통신하기 위한 New Next-Hop인 1.1.5.5(R5)로 Reconvergence 하여 설치
- BGP도 업데이트되었음을 확인
- BGP Next-Hop이 변경되지 않았으므로 BGP 테이블에는 변경된 내용이 없는 상태
- OSPF는 3.3.3.3으로 통신하기 위해 Next-Hop은 1.1.5.5를, OIF는 e0/1를 사용
- BGP로 학습한 NLRI에 대한 FIB 항목도 New Next-Hop 및 OIF를 반영하여 변경
- 3.3.3.3/32에 도달하기 위해 New Path를 파악하고 FIB의 항목을 New Next-Hop으로 업데이트
- 대형 네트워크에서 수백만 개의 NLRI가 있을 경우, 하나씩 업데이트를 받아야 하며 해당 작업에는 오랜 시간(min)이 소요
- Flat FIB 구조를 Hierarchical FIB 구조로 변경하여 Convergence Time이 오래 걸리는 문제 보완 가능
4) Introduction to Hierarchical FIB
- Flat FIB 구조는 Prefix와 Next-Hop / OIF 사이에 1:1 관계이므로 Next-Hop이 변경되면 FIB의 각 Prefix를 탐색하여 Next-Hop을 업데이트를 해야 하므로 많은 CPU Cycles을 필요로 하는 시간 소모적인 프로세스
- 위와 같은 문제를 개선하기 위해 Hierarchical FIB 구조를 사용
- Hierarchical FIB 구조를 사용하면 BGP Next-Hop과 IGP Next-Hop을 별도로 저장
- IGP Next-Hop이 변경될 때 영향을 받는 FIB 부분만 변경하면 된다는 큰 이점 존재
- BGP Next-Hop에서 Pointer를 'R3 via 1.1.2.2'에서 'R3 via 1.1.5.5'로 변경만 필요
- BGP Prefix 또는 BGP Next-Hop은 미변경
- Convergence Time은 IGP가 New Next-Hop을 찾는 Convergence Time에 따라 결정
- Hierarchical FIB 구조 장점
- FIB 메모리 사용량 감소
- IGP Next-Hop이 변경될 때 BGP Prefix 및 BGP Next-Hop이 변경되지 않으므로 필요한 CPU Cycles 수 감소
- Hierarchical FIB는 거의 모든 Cisco 플랫폼에서 지원
- Cisco IOS XR 및 NX-OS에서는 기본적으로 지원
- Cisco IOS에서는 아래 명령어로 활성화 가능
- Hierarchical FIB를 활성화하는 명령어는 위와 같이 간단하지만 IGP Convergence Time에 의존하므로 전체적인 Convergence Time을 단축하기 위해 BFD 또는 FRR과 같은 기술 구현이 필요
728x90
반응형
'네트워크 > BGP' 카테고리의 다른 글
BGP PIC Edge(Backup Path) (0) | 2024.08.25 |
---|---|
BGP Additional Paths (0) | 2024.08.21 |
BGP Next-Hop Address Tracking (0) | 2024.08.19 |
BGP Load Balancing with DMZ Link Bandwidth Sample Configuration(Cisco IOL) (0) | 2024.08.17 |
BGP Load Balancing with Multipath Sample Configuration(Cisco IOL) (0) | 2024.08.15 |
BGP Load Balancing with IGP and Static Routing Sample Configuration(Cisco IOL) (0) | 2024.08.13 |
Introduction to BGP Load Balancing (1) | 2024.08.11 |
MPLS L3 VPN BGP AS-Override Sample Configuration(Cisco IOL) (0) | 2024.08.09 |