본문 바로가기

Cloud/AWS

Amazon VPC Route Server

Today Keys : VPC, Route, Server, BGP, table, 라우팅, Propagation, FIB, RIB, routing, peer, endpoint


이번 포스팅은 지난 4월 1일에 GA된 Amazon VPC Route Server에 대한 소개와 함께 직접 구성하여 테스트 해보는 내용입니다. 


Amazon VPC Route Server란?

▪ VPC 내에서 네트워크 가상 어플라이언스 간의 동적 라우팅을 간소화하기 위해 사용할 수 있는 완전 관리형 라우팅 제어 서비스

▪ BGP(Border Gateway Protocol)를 활용하여 네트워크 경로를 동적으로 학습하고, VPC 라우팅 테이블을 자동으로 갱신

▪ 사용자 지정 스크립트나 오버레이 네트워크 없이도 경로 학습 및 전파가 가능하도록 지원

▪ 가상 방화벽, IDS/IPS 등 네트워크 가상 어플라이언스(NVA)와의 통합을 간소화

 

VPC Route Server를 이해하기 위한 주요 구성 요소 및 용어

RIB (Routing Information Base)

▪ Route Server가 BGP 피어 등으로부터 학습한 모든 라우팅 정보를 저장하는 데이터베이스

▪ 네트워크의 최신 토폴로지를 반영하며 지속적으로 업데이트됨

▪ FIB에 반영할 최적 경로 선정을 위한 평가 기준 역할 수행


FIB (Forwarding Information Base)

▪ RIB에 저장된 정보 중에서 Route Server가 최적 경로로 판단한 경로만을 선별하여 저장

▪ 실제 VPC의 라우팅 테이블에 설치되는 경로 집합

▪ RIB에 변화가 생기면, FIB도 함께 재계산되어 최신 경로를 반영

 

Route Server Endpoint (라우트 서버 엔드포인트)

▪ AWS에서 관리하는 서브넷 내부 구성 요소

▪ Route Server와 BGP 피어 간의 BGP 세션을 직접 연결할 수 있도록 하는 인터페이스 역할

 

Route Server Peer (라우트 서버 피어)

▪ Route Server Endpoint와 AWS 내 배포된 장비(예: 가상 방화벽, NAT 장비 등) 간의 BGP 세션

▪ 다음 조건을 충족해야 함:

    - VPC 내에서 ENI(탄력적 네트워크 인터페이스)를 가질 것

    - BGP 프로토콜을 지원하고 세션을 직접 개시할 수 있을 것

 

Route Server Association (라우트 서버 연결)

▪ 특정 VPC와 Route Server 간에 BGP 기반 라우팅 동기화를 위한 연결 관계

▪ 이 연결을 통해 VPC 라우팅 테이블에 BGP 기반 동적 경로 전파 가능

 

Route Server Propagation (라우트 서버 전파)

▪ 활성화된 경우, FIB에 있는 경로를 지정된 라우팅 테이블에 자동으로 설치

▪ IPv4 및 IPv6 경로 전파를 모두 지원

▪ 장애 발생 시, 경로 철회(Withdraw)를 자동 반영하여 즉각적인 트래픽 Re-라우팅 가능


Amazon VPC Route 구성 테스트

다음은,  이번 포스팅에서 다룰 구성도입니다.

하나의 VPC 안에 Public Subent 2곳에는 네트워크 가상 어플라이언스(NVA) 역할을 할 ZIGI-Proxy를 2대 구성합니다.

VPC Route Server를 만들어서, ZIGI-VPC1에 연결하고, 

Private Subnet 2곳에는 VPC Route Server와 연결 할 Endpoint를 구성합니다.

가운데 Private Subnet에서는 VPC Router Server와 NVA (ZIGI-Proxy)간의 BGP 연동을 통해서, 

인터넷으로 가는 Default 경로를 Proxy1 으로 보낼지, Proxy2로 보낼지에 대한 라우팅 경로를 

라우팅 테이블에서 반영합니다.

 


VPC Route Server 설정

 

Router Server 생성

VPC 대시보드에서 Route Servers 메뉴로 들어가서, 

'Create route server' 버튼을 클릭합니다.

 

 

 

Route Server 이름을 ZIGI-RT라고 하고, 

Route Server에서 BGP 연동에 사용 할 ASN(AS Number)를 설정합니다. 

BGP ASN은 1-424967295까지 설정이 가능하지만, 

Private ASN인 4512–65534 (16-bit ASN) 혹은 4200000000–4294967294 (32-bit ASN)을 사용하는 것을 권고합니다.

본 포스팅에서는 나머지는 기본 값으로 두고 생성합니다.

참고로, Persist routes는 모든 BGP 세션이 종료된 이후에 경로가 라우팅 서버의 라우팅 Database로 유지 여부를 결정합니다. 

Enable SNS notifications은 BGP의 상태 값을 SNS 알림을 활성화 하게 합니다.

 

 

 

ZIGI-RT라는 이름으로 VPC Route Server가 다음과 같이 생성되었습니다. 

 

Route Server를 VPC에 연결

이제 Route Server를 VPC에 연결합니다. 

'Associate route server'를 선택합니다. 

 

 

 

Router Server를 'ZIGI-VPC'라는 이름의 VPC에 연결합니다. 

Route Server는 1개의 VPC에만 연결이 가능하고, 

VPC는 최대 5개의 Router Server 연결이 가능합니다.  (Support Center를 통해서 한도 증가 가능)

 

 

 

Route Server의 경로(Route) 정보를 전파할 서브넷 설정

Route Server에서 Route 정보를 전파(Propagations)할 서브넷을 설정합니다. 

Route Server와 BGP를 연동해서 받은 네트워크 대역 정보를 Route Server의 Propagations에서 설정한 서브넷으로 광고를 하게 됩니다. 

ZIGI-RT라는 Route Server의 Propagations 메뉴에서 'Enable propagation'을 클릭합니다

 

 

 

Pri-RT1이라는 Route table에 네트워크 대역을 광고하기 위해서 선택합니다

 

 

 

Route Server Endpoint 생성

Route Server와 VPC를 연결하고 난 이후에는 VPC Route Server의 Endpoint를 생성합니다. 

Route Server와 네트워크 가상 어플라이언스 역할을 하는 ZIGI-Proxy 간의 BGP 연동은 이 Endpoint를 통하게 됩니다.

즉, Route Server와 BGP Peer(여기에서는 ZIGI-Proxy) 간의 BGP 연결을 지원하는 관리형 구성 요소가 Endpoint입니다.

 

 

 

Route Server Endpoint의 이름으로는 ZIGI-RT-EP1으로 하고, 

앞서 만든 Route Server를 선택합니다. 

그리고, Endpoint를 생성 할 Subnet을 지정합니다. 

 

 

 

이중화를 위해서 서브넷 당 2개의 Endpoint를 만들어야 하지만

본 포스팅에서 가용영역 2개에서 서브넷 당 1개의 Endpoint를 만들었습니다.  

 

 

 

Route Server BGP Peer 설정

이제 Route Server Endpoint에서 ZIGI-Proxy와 BGP 연동을 위해,

Route Servrer peers를 추가 합니다. 

ZIGI-RT-EP1의 Endpoint에서 Route server peers 메뉴에서, 

'Create route server peer' 을 선택합니다.

 

 

 

ZIGI-RT-EP1 Endpoint와 BGP를 연결한 Peer의 이름을 'ZIGI-RS-Peer1'로 하고, 

Route servrer endpoint ID를 선택합니다. 

ZIGI-Proxy1와 BGP 연동을 하기 때문에, 

ZIGI-Proxy1의 IP 주소를 Peer address와 

ZIGI-Proxy1에서 사용 할 ASN인 64520을 입력합니다. 

나머지는 기본 값으로 두고 peer를 생성합니다.

 

 

 

처음 Peer를 만들면, State는 pending 상태에서 시간이 지난 후에 Availabe로 바뀌고, 

BGP status는 'down'상태가 됩니다. 

 

 

 


네트워크 가상 어플라이언스 구성

 

이제 Route Servrer  Endpoint외 BGP를 연동 할 네트워크 가상 어플라이언스 역할을 하는 ZIGI-Proxy1의 설정을 하겠습니다.

본 포스팅에서 ZIGI-Proxy1에서 BGP 구성을 위해서 FRR(FRRouitng)을 사용합니다. 

 

 

먼저 frr 사용을 위해서 패키지를 설치합니다.

frr 패키지 설치

sudo apt update
sudo apt install frr frr-pythontools

frr설치 후에는 BGP 사용을 위해서 BGP 데몬 활성화 및 BGP 설정에 필요한 값을 입력합니다.

 

구성 파일 경로 및 설정 값

/etc/frr/daemons : BGP 데몬을 활성화

bgpd=yes

 

/etc/frr/frr.conf : BGP 설정

   - BGP 연동은 Route Server Endpoint와 하기 때문에,

     neighbor 주소에  Route Server Endpoint의 IP주소(10.0.2.117, 10.0.2.173)를 입력합니다. 

   - Remote-as는 Route Server 생성 시에 설정한 ASN인 64530을 입력합니다.

hostname zigi-bgp-router
password zebra
!
router bgp 64520
 bgp router-id 10.0.0.13
 neighbor 10.0.2.117 remote-as 64530
 neighbor 10.0.2.117 update-source enX0
 neighbor 10.0.2.117 ebgp-multihop 2
 neighbor 10.0.2.173 remote-as 64530
 neighbor 10.0.2.173 update-source enX0
 neighbor 10.0.2.173 ebgp-multihop 2
 address-family ipv4 unicast
   redistribute static
   neighbor 10.0.2.117 default-originate
   neighbor 10.0.2.173 default-originate
 exit-address-family
 no bgp ebgp-requires-policy
!
line vty
!

 

설정을 하고 나면, FRR 서비스를 가동합니다.

 

FRR 서비스 기동

sudo systemctl enable frr
sudo systemctl restart frr

 

Security Group 추가

BGP는 TCP 179를 사용하기 때문에,

ZIGI-Proxy1의 Security Group에서 Inbound rules로 Router Server Endpoint IP를 TCP 179 Port로 추가합니다.

 

 

네트워크 가상 어플라이언스에서 BGP 연동 확인

모든 설정이 완료되고 나면, 

ZIGI-Proxy1 서버에서 다음과 같이 BGP가 연동된 것을 확인 할 수 있습니다.

 

 

Route Server에서 BGP 연동 확인

Route Server에서도 Router Server peers의 BGP Status가 'Up'으로 된 것을 확인 할 수 있습니다.

 

 

 

이중화 테스트를 위해서, ZIGI-Proxy2를 추가로 생성한 이후에 

2개의 가용 영역의 서브넷에서 1개씩 생성한 Endpoint와의 BGP 연결을 모두 하고 나면, 

다음과 같이 4개의 BGP 연결이 된 것을 볼 수 있습니다.  

 

 

 

Route Server의 라우팅 정보 확인

 

Route Servrer에서 Route 메뉴를 보면, 

Route Server Endpoint에서 BGP를 통해서 광고 받은 네트워크 대역 정보를 확인 할 수 있습니다.

ZIGI-Proxy1, ZIGI-Proxy2를 통해서 default 경로(0.0.0.0/0)을 광고 받고 있는 것을

다음과 같이 확인 할 수 있습니다. 

 

Route Status를 보면, in-fib와 in-rib로 표기 되어 있고

in-fib에서만 Route installation details에서 경로가 인스톨 된 것을 볼 수 있습니다.

RIB(Routing Information Base)는 BGP Peer를 통해서 광고 받은 대역에 대한 데이터베이스 정보이고, 

FIB(Forwarding Information Base)는 RIB 중에서 가장 최적의 경로를 찾은 것이고, 이 정보가 서브넷에 전파되는 것입니다.

 

 

 

 

Route Server를 통해 업데이트 된 Private Subnet의 라우팅 테이블 확인

 

이제 앞서 Route Servrer의 Propagation에서 설정한 Pri-RT1 라우팅 테이블을 보면, 

ZIGI-Proxy에서 광고한 Default 경로(0.0.0.0/0)가 라우팅 테이블에 추가 된 것을 볼 수 있습니다.

Targer으로는 eni-~5d81로 잡혀 있는 데, 이 ENI는 ZIGI-Proxy1(10.0.0.81)의 ENI입니다.

 

 


VPC Route Server를 통한 라우팅 경로 전파 이중화 점검

 

그럼 지금부터 이중화 점검을 해보겠습니다.

현재 가장 Default 경로에 대한 최적 경로는 ZIGI-Proxy1과 Endpoint2와 연결된 경로로 되어 있습니다.

이제 ZIGI-Proxy1과 Endpoint2간의 BGP 연동을 Security Gruop에서 정책을 지워서 차단합니다. 

정책 삭제 이후에는 Proxy에서 BGP 세션을 초기화 합니다.

 

이제 ZIGI-Proxy1과 Endpoint2의 BGP가 'down'된 것을 볼 수 있습니다.

 

 

 

Route Server에서 전파되는 경로를 확인해 보면, 

1개의 라우팅 정보에 대한 Database가 삭제되었지만,

ZIGI-Proxy1와 Endpoint1의 정보가 FIB로 변경되어서 라우팅 테이블에 install된 것을 볼 수 있습니다. 

경로를 전파받는 라우팅 테이블에서는 실제 Target인 ZIGI-Proxy1이 변경되지 않았기 때문에 변화가 없습니다.

 

 

 

이제 ZIGI-Proxy1의 Down을 가정하기 위해서, ZIGI-Proxy1과 Endpoint1 간의 BGP를 동일한 방식으로 차단합니다. 

다음과 같이 ZIGI-Proxy1과 Endpoint1과의 BGP 상태가 'Down'으로 변경된 것을 볼 수 있습니다.

 

 

 

Route Server에서 전파되는 경로를 확인해 보면, 

추가로 1개의 라우팅 정보에 대한 Database가 삭제되었고,

ZIGI-Proxy2와 Endpoint2의 정보로 FIB로 변경된 것을 볼 수 있습니다.

 

 

이제 ZIGI-Route에서 라우팅 정보를 전파받은 Pri-RT1 라우팅 테이블을 보면, 

Default 경로(0.0.0.0/0)의 Targer이 eni-~8d15로 변경된 것을 볼 수 있습니다.

이 ENI가 ZIGI-Proxy2(10.0.0.179)의 ENI입니다.