AWS VGW 서브넷 경로가 VPN 터널 하나를 고를 수 없는 이유
가상 프라이빗 게이트웨이로 향하는 서브넷 경로는 터널 중 하나를 지정할 수 없습니다. 실제 선호가 사는 곳은 AS_PATH, 터널 상태, 정적 경로입니다.
두 개의 Site-to-Site VPN 연결이 하나의 가상 프라이빗 게이트웨이에서 종료되고 같은 지사 접두사를 알립니다. 서브넷 경로 테이블에는 해당 접두사에 대한 항목이 하나 있고 그것은 게이트웨이를 가리키며, 터널을 지목하는 필드는 없습니다. 그래서 연결 사이의 선호는 콘솔이 라우팅이라고 부르지 않는 곳에서 결정됩니다. 어느 계층이 결정을 소유하는지 아는 것이 작동하는 대기 경로와 아무것도 하지 않는 변경의 차이입니다.
두 계층이 관여합니다: 어떤 게이트웨이인지 말하는 VPC 경로와 게이트웨이 자체의 터널 선택입니다. 둘을 혼동하면 경로 테이블에서는 옳아 보이지만 패킷을 하나도 움직이지 않는 변경이 됩니다.
하나처럼 보이는 두 계층
서브넷 경로는 한 가지 질문에 답합니다, 즉 이 목적지에는 어느 연결인가. 그 대상은 가상 프라이빗 게이트웨이며 메트릭은 같은 테이블의 다른 경로와만 경쟁합니다. 그 항목에는 터널 하나와 터널 둘을, 또는 연결 A와 연결 B를 구분하는 것이 없습니다. 더 구체적인 접두사는 다른 목적지 일치일 뿐이며 더 세밀한 경로 선택이 아닙니다.
게이트웨이는 다음 질문에 답합니다, 그 접두사에 대해 보유한 터널 중 지금 어느 것이 트래픽을 나르는가. 이 결정은 터널 상태와 고객 게이트웨이에서 받은 BGP 속성에서 나오며 서브넷 경로 테이블에는 결코 나타나지 않습니다.
VGW가 실제로 비교하는 것
상태가 먼저입니다. 내려간 터널이나 올라오지 않은 BGP 세션은 어떤 속성도 살펴보기 전에 집니다. 그래서 이미 실패하는 연결에 경로를 앞에 붙여도 아무것도 바뀌지 않습니다.
같은 접두사에 대한 유효한 경로 중에서 AWS는 더 짧은 AS_PATH를 선호합니다. 두 경로의 길이가 같으면 MED를 비교하며, 경로의 첫 AS에 관한 문서화된 조건을 따릅니다. 속설이 아니라 공개된 순서를 읽으십시오, 속설은 보통 상태 단계와 정적 경로 예외를 빠뜨립니다. 한 가지 결과로 백업 연결에 세 번 앞에 붙이면 기본 연결이 엄격히 더 짧아지며, 이것이 선호를 표현하는 일반적인 방법입니다.
앞에 붙이기, 그리고 그것이 아무것도 하지 않을 때
앞에 붙이기는 고객 게이트웨이의 나가는 광고에서 일어나며 AWS 내부에서는 일어나지 않습니다. AWS가 피하기를 바라는 접두사에 자신의 ASN을 두세 번 추가하면 AWS는 그 연결에 더 긴 경로를 봅니다. 기본 연결은 앞에 붙이지 않은 광고를 유지합니다. 두 연결이 같은 ASN에서 같은 횟수로 광고한다면 선호를 전혀 표현하지 않은 것입니다.
변경 후 AWS 쪽에서 받은 경로를 확인하십시오. 고객 장비를 한 번도 떠나지 않은 앞에 붙이기는 AWS가 무시한 것과 똑같이 보입니다.
정적 경로는 논증 전체를 무시합니다
연결이 정적 라우팅을 쓰면 길게 만들 AS_PATH가 없습니다. AWS는 정적 VPN 경로를 같은 접두사에 대해 BGP로 학습한 경로보다 우선한다고 문서화하므로 혼합 설계는 완전히 동적인 설계처럼 동작하지 않습니다. 먼저 라우팅 유형을 정하고 그다음 그에 존재하는 선호 메커니즘을 고르십시오.
같은 접두사를 광고하는 두 정적 연결에서는 유용한 지렛대가 접두사입니다, 즉 사용하려는 연결에서 더 구체적인 범위를 광고하고, 어느 경로가 이기는지가 아니라 어느 목적지가 일치하는지를 바꾸었음을 받아들이십시오.
트랜짓 게이트웨이가 다른 답인 이유
트랜짓 게이트웨이는 VPN 연결 전반에 걸쳐 동일 비용 다중 경로를 지원하므로 두 연결이 하나가 대기하는 대신 트래픽을 나눌 수 있습니다. 그 설계는 장애 표면이 다릅니다, 흐름이 터널에 퍼지고 한 터널이 내려가도 부하의 일부만 이동합니다. VGW 방식을 트랜짓 게이트웨이에, 또는 그 반대로 복사하면 어느 플랫폼도 충족하지 못하는 기대가 생깁니다.
메커니즘보다 모델을 먼저 고르십시오, 고정된 선호를 가진 활성과 대기, 또는 ECMP를 가진 활성과 활성입니다.
설정한 뒤 무엇을 확인할지
네 가지를 순서대로 확인하십시오. 서브넷 테이블이 여전히 접두사를 의도한 게이트웨이로 해석합니다. 게이트웨이가 두 터널을 모두 올라온 상태로 표시합니다. 피하려는 연결에서 받은 AS_PATH가 다른 쪽보다 깁니다. 그리고 그 서브넷의 인스턴스에서 나온 실제 흐름이 예상 터널을 지나며, 초록 상태에서 추론하지 않고 양쪽 끝에서 관찰됩니다.
그다음 승인된 장애 조치 시험을 실행하고 살아남은 경로가 서비스를 나르는지 보십시오. 구성 차이에만 존재하는 선호는 아직 선호가 아닙니다.