BGP 세션이 VPC 라우트 테이블에 나타나지 않는 이유

반복되는 이야기는 EC2 VPN 어플라이언스의 라우팅 데몬이 BGP가 올라오면 VPC에 원격 프리픽스를 가르쳐 준다는 것입니다. 그중 절반은 사실입니다. 세션은 올라오지만 그것 때문에 VPC 라우트 테이블에서는 아무것도 바뀌지 않으며, 그래서 첫 증상은 보통 서브넷이 조용히 트래픽을 블랙홀로 떨어뜨리는 것입니다.

여기서 두 가지 다른 것이 혼동됩니다. 라우트 서버와의 피어링과, 라우트를 테이블에 설치하는 것입니다.

신화: BGP를 올리면 VPC가 프리픽스를 배운다

BGP는 두 화자 사이의 대화이며, 이 설계에서 화자는 어플라이언스의 라우팅 데몬과 AWS가 소유한 서브넷에 배치하는 VPC Route Server 엔드포인트입니다. 그 대화는 프리픽스를 운반합니다. 워크로드 서브넷의 라우트 테이블은 건드리지 않는데, 그 테이블은 각각에서 활성화해야 하는 전파를 통해서만 배우기 때문입니다. 그 전까지 VPC 패브릭은 어플라이언스가 아는 것을 전혀 모릅니다.

설정 단계가 분리된 데는 이유가 있습니다. 연결하고, 엔드포인트를 만들고, 피어링한 다음 전파를 활성화합니다.

Route Server는 컨트롤 플레인이지 터널이 아니다

Route Server는 패킷 하나도 암호화하지 않고, 전달하지 않고, 검사하지 않습니다. 어플라이언스와 BGP를 교환하고 그 결과 프리픽스를 수신하도록 구성된 라우트 테이블에 넘기기 위해 존재합니다. 데이터 플레인은 변하지 않습니다. 패킷은 여전히 어플라이언스의 네트워크 인터페이스로 나가 VPN을 통과하고 같은 길로 돌아옵니다.

즉 전달 인스턴스의 소스 및 목적지 확인은 여전히 중요합니다. 인스턴스가 이제 다른 누군가에게 보내는 트래픽을 전달하고 있기 때문입니다.

보안 그룹과 서브넷 제어도 전달되는 흐름에 적용됩니다. Route Server는 트래픽을 버리는 어플라이언스가 그것을 전달하게 만들지 않으며, 원격 쪽의 누락된 반환 라우트를 고치지도 않습니다.

전파는 VPC 단위가 아니라 라우트 테이블 단위다

라우트 서버를 VPC에 연결하는 것과 라우트 테이블에서 전파를 활성화하는 것은 두 가지 결정이며, 서브넷이 하는 일을 바꾸는 것은 두 번째뿐입니다. 라우트 테이블이 여섯 개인 VPC는 하나에서 전파된 프리픽스를 받고 나머지 다섯에서는 받지 않을 수 있으며, 이는 허브 서브넷에 정확히 맞는 동작이고 «절반만 작동한다»는 혼란스러운 결과를 만드는 원인입니다. 전파가 켜져 있는 곳에서도 경쟁 라우트가 이길 수 있습니다. VPC 라우트 선택은 가장 긴 프리픽스를 선호하고, 길이가 같으면 전파된 라우트보다 정적 라우트를 선호하기 때문입니다. 그 선호는 조용히 적용됩니다.

어플라이언스가 광고하는 프리픽스 목록이 아니라 특정 서브넷의 유효 테이블을 확인하십시오. API가 그 질문에 직접 답합니다. aws ec2 associate-route-server 과 aws ec2 enable-route-server-propagation --route-table-id <id> 은 사람들이 잊는 두 단계이고, aws ec2 describe-route-tables --route-table-ids <id> 는 프리픽스가 route server 항목으로 도착했는지 보여 줍니다.

어플라이언스는 여전히 모든 패킷을 운반한다

도달 가능성을 광고하는 것은 그것을 갖는 것과 같지 않다. BGP 세션은 어플라이언스의 VPN이 내려가 있어도 설정된 채로 남을 수 있고, 절대 바뀌지 않는 정적 광고는 트래픽을 죽은 경로로 계속 끌어당깁니다. Route Server는 BFD 같은 장애 감지를 지원하지만, 그것은 피어의 생존을 시험하는 것이지 피어 뒤의 모든 것의 건강이 아닙니다.

광고를 실제 원격 라우트에 묶으십시오. 터널과 원격 네트워크가 올라와 있을 때 프리픽스를 알리고, 아닐 때 철회하십시오.

프리픽스를 철회하고 무슨 일이 일어나는지 보라

단계별로 시험하고, 마지막 단계를 제거로 만드십시오. 광고가 도착하는지, 프리픽스가 의도한 각 테이블에 나타나는지, 어플라이언스가 다음 홉인지, 전달이 활성 터널을 지나는지, 원격 끝이 응답하는지 확인하십시오. 그런 다음 시험용 프리픽스를 철회하거나 승인된 터널을 닫고, 트래픽이 설계가 말하는 곳으로 움직이는지 관찰하십시오. 시험이 열려 있는 동안 이전과 이후 테이블을 기록하십시오.

라우트를 두 번째 어플라이언스로 옮겨도 그것이 운반하던 세션은 옮겨지지 않습니다. NAT와 방화벽 상태는 첫 장치에 남기 때문입니다.

열두 개 프리픽스의 고정 집합에는 VPC 테이블의 정적 라우트가 여전히 더 저렴한 답입니다. Route Server는 프리픽스 목록이 실제로 바뀌고 철회 정책을 당직자에게 설명할 수 있을 때 제자리를 얻습니다.