BGP Next-Hop Address Tracking

1. Introduction to BGP Next-Hop Address Tracking

• BGP NLRI에 대하여 Next-Hop에 도달할 수 있는 정보가 있어야 Valid Route로 인식
• BGP Scanner는 Scanner Interval마다 Next-Hop까지 도달 가능성을 확인하고 Best-Path 계산을 수행
  • Cisco IOS Default BGP Scanner Timer : 60s
• Scanner Interval 간격 동안 Next-Hop에 문제가 발생된 후에 해결되지 않는다면 다음 Scanner가 동작될 때까지 Blackhole 및 Routing Loop과 같은 문제 발생 가능
• BGP Next-Hop Tracking은 라우팅 테이블에서 Next-Hop 변경이 감지되면 Next-Hop Scan을 예약하여 BGP Table의 Next-Hop을 조정하여 BGP Convergence Time을 단축하는 기능
  • 라우팅 테이블에서 Next-Hop 변경을 감지한 후 Next-Hop Scan의 Default Delay는 5s
  • 라우팅 테이블의 변경 사항을 감지하기 때문에 Event-Base에 포함
• Next-Hop Tracking을 Dampening과 함께 사용하면 라우팅 테이블에서 계속 변경되는 Next-Hop에 대한 Scan Delay가 증가

 

 

2. BGP Next-Hop Address Tracking Sample Configuration

1) BGP Next-Hop Address Tracking Sample Configuration 구성도

• 테스트 장비
  
  • 에뮬레이터 : EVE-NG
  • 라우터 : Cisco IOL I86BI_LINUX-ADVENTERPRISEK9-M, Version 15.5(2)T
• R1↔R2, R1↔R3 간에 iBGP Session
• R2 및 R3는 1.2.3.0/24 네트워크를 OSPF가 아닌 BGP로 광고
• iBGP Session을 생성하기 위해 각 라우터의 Loopback Interface는 OSPF로 광고
• R1 장비에서 1.2.3.0/24 네트워크의 Next-Hop의 상태가 변경될 때 Next-Hop Tracking 동작을 확인하는 것이 목표

 

2) OSPF Configuration

 

3) iBGP Configuration

 

4) Scanner 확인

• Cisco는 기본적으로 60s마다 Scanner가 실행
• Debug를 활성화하면 60s마다 실행되는 것을 확인 가능
• Next-Hop 상태 변동 시, BGP Scanner에 의존하기에 너무 느리다는 문제 발생

 

5) Next-Hop Tracking

• Next-Hop Tracking은 기본적으로 활성화되어 있으므로 설정 불필요
• 위 두 개의 설정은 라우팅 테이블에서 Next-Hop 상태 변경 확인 시, Scanner가 5s 안에 시작되는 기능이 Enable 되어 있다는 것

 

• Next-Hop Tracking 실행 여부를 확인하기 위해 위 두 가지의 Debug를 활성화
• 첫 번째 Debug는 라우팅 테이블의 변경 사항을 확인
• 두 번째 Debug는 Next-Hop Tracking이 수행할 작업을 확인

 

• 현재 R1의 BGP 테이블 상태이며 1.2.3.0/24 네트워크는 R2와 R3로 광고 받았지만 R-ID가 가장 낮은 R2를 Bets-Path로 선출

 

• OSPF는 2.2.2.2/32가 사라졌다는 것을 파악하는 즉시 라우팅 테이블에서 삭제
• OSPF Event 직후 BGP가 Next-Hop Scanner를 5초 안에 Schedules
• 해당 5초가 만료되면 Next-Hop Address를 3.3.3.3(R3)으로 변경하고 해당 변경 내용을 라우팅 테이블에 추가
• 60s마다 실행되는 BGP Scanner보다 Convergence Time 단축

 

• R1은 Next-Hop이 3.3.3.3을 사용하여 1.2.3.0/24로 도달
• 아직 BGP 테이블에 Next-Hop이 2.2.2.2인 정보가 존재하는 이유는 BGP Hold Down Timer가 아직 만료되지 않았기 때문

 

• 현재 BGP 테이블 확인 후, Next-Hop 3.3.3.3이 유효하지 않도록 R3의 Loopback Interface를 Shutdown

 

• OSPF는 네트워크 변경을 감지하고 2.2.2.2/32는 라우팅 테이블에서 제거
• BGP는 5초 안에 Next-Hop Scan을 schedules 하고 라우팅 테이블에서 1.2.3.0/24를 삭제

 

• 아직 BGP 테이블에 Next-Hop이 3.3.3.3인 정보가 존재하는 이유는 BGP Hold Down Timer가 아직 만료되지 않았기 때문

 

 

6) Next-Hop Tracking Dampening

• Next-Hop Tracking이 Enable이 되어 있어 있으므로 Next-Hop 상태 변경 시, 5s 안에 Schedule 발생
• Next-Hop 네트워크가 Flapping이 발생되면, BGP 테이블의 정보가 수시로 변경되는 문제 발생
• 이러한 문제가 발생하지 않도록 Next-Hop Tracking은 Dampening을 지원
  • Dampening 동작과 Penalty에 대한 내용은 Dampening 글을 참고
• Next-Hop 상태가 변경될 때마다 Penalty를 추가