라우트 우선순위 설정 예

• /32 접두부 및 우선순위가 1 인 라우트와 목적지가 /31 이고 우선순위가 0 인 라우트가 있는 경우, /32 가 먼저 사용됩니다 (가장 긴 접두부 일치). 즉, 정확히 동일한 접두부를 갖는 둘 이상의 라우트가 있는 경우에만 우선순위가 중요합니다.
• 0.0.0.0/0 (기본 라우트) 가 있는 세 개의 라우트가 있는 경우 우선순위가 가장 높은 라우트만 사용됩니다. 선택한 라우트가 제거되면 (예를 들어, 자동화를 통해) 나머지 두 라우트에서 가장 높은 우선순위가 선택됩니다.
• 사용자 지정 라우팅 테이블에 특정 접두사가 포함된 경로가 하나만 있는 경우 해당 경로는 우선 순위에 관계없이 항상 사용됩니다. 모든 특정 접두사에 대해 최상의 경로 선택이 수행되고 우선 순위가 가장 높은 경로를 선택합니다.

동일 비용 다중 경로 (ECMP) 라우팅은 두 라우트가 동일한 대상 및 우선순위를 갖는 경우 (동일한 대상을 갖는 두 라우트에 대해 ECMP가 사용되는 현재 동작 확장) 사용됩니다. 라우팅 테이블에서 최대 두 개의 라우트가 동일한 대상 및 우선순위를 가질 수 있습니다. 예를 들어, 사용자 정의 라우팅 테이블에 우선순위가 1 인 하나의 라우트와 우선순위가 4 (ECMP) 인 다른 두 개의 라우트가 동일한 대상을 갖는 세 개의 라우트가 있는 경우, 우선순위가 1 인 라우트가 선택되고 ECMP 라우트가 무시됩니다 (ECMP 없음). 이제 동일한 대상 및 우선순위를 갖는 두 라우트가 가장 높은 우선순위를 갖는 경우, 시스템은 이 두 라우트를 선택하고 ECMP를 수행합니다. 그런 다음 이러한 라우트 중 하나가 삭제되면 여전히 존재하는 라우트가 선택되고 ECMP가 수행되지 않습니다.

라우트 우선순위 제한사항은 제한사항 및 지침 을 참조하십시오.

광고 라우트 고려사항

경로를 광고할 때 다음 고려 사항에 유의하세요.

• VPC에 할당된 루트 주소 접두사 외부의 경로를 광고할 수 있으므로 외부 네트워크나 VPC 외부에 있는 네트워크를 Direct Link 또는 Transit Gateway.

• 여러 Transit Gateway 또는 Direct Link가 VPC에 연결된 경우 개별적으로 경로 필터링을 사용할 수 있습니다. Transit Gateway 또는 Direct Link 어떤 경로가 어떤 연결에 광고되는지 미세 조정하는 연결입니다.

• 여러 경로가 서로 다른 우선순위를 가진 대상 접두사에 공지되는 경우 우선순위가 더 높은(낮은 우선순위 값) 경로가 기본 경로로 사용되고 우선순위가 낮은(높은 우선순위 값) 경로가 백업으로 사용됩니다.

• 다음과 같은 두 가지 다른 경로를 광고하는 경우 172.16.0.0/31 ~을 통해 10.1.1.0 그리고 172.16.0.0/32 ~을 통해 10.1.2.0, 경로는 /32 접두사는 항상 경로보다 우선합니다./31 접두사. 이는 "가장 긴 접두부 일치" 규칙 세트와 일치합니다. 호스트 대상에 대한 긴 접두사는 항상 좁은 접두사보다 선호됩니다.

• 현재 Transit Gateway 또는 Direct Link의 중복 라우트에 플래그를 지정하는 메커니즘은 없습니다. 그만큼 Transit Gateway 선호하는 대로 가장 구체적인 접두사와 가장 짧은 AS 경로를 사용하여 최상의 경로를 선택합니다. 그렇지 않으면, Transit Gateway 먼저 수신한 경로를 선택합니다. 이 경로는 VPC 측에서 가장 오래된 경로가 아닐 수 있으며, Transit Gateway 내부적으로 새로 고쳐집니다.

• VPN 게이트웨이에서 광고되는 경로는 VPN 유형에 따라 다릅니다. 정책 기반 VPN 게이트웨이는 동적으로 경로를 광고하지 않습니다. VPN 정책에 정의된 CIDR 접두사만 전파되며, 라우팅 테이블은 VPN 게이트웨이로부터의 경로를 수락하도록 구성되어야 합니다. BGP를 사용하는 경로 기반 VPN 게이트웨이는 경로를 동적으로 광고합니다.

  VPN 연결을 포함하는 라우팅 테이블에서 경로를 광고할 때는, 해당 VPN 게이트웨이 유형이 의도된 경로 전파 동작을 지원하는지 확인하십시오.

사용 사례 1: 엣지 프록시 방화벽

사용 사례 2: 공용 로드 밸런서

사용 사례 3: VPN

VPN 게이트웨이를 VPC 라우팅 테이블에서 다음 홉으로 사용하기 위해 게이트웨이가 전용 서브넷에서 작성됩니다. 이 서브넷은 VPN 게이트웨이만을 위해 사용되며, 0.0.0.0/0 라우트가 있고 다음 홉이 VPN 연결인 경우 다른 라우팅 테이블을 사용하여 VPN 게이트웨이 서브넷과 연관됩니다.

예를 들어, 다음과 같습니다.

• 서브넷 A는 가상 서버를 호스팅하는 데 사용되고 기본 라우팅 테이블과 연관됩니다. 0.0.0.0/0 라우트가 있고 다음 홉은 VPN 연결입니다.
• 서브넷 B는 VPN 게이트웨이를 호스팅하는 데 사용되고 새로운 라우팅 테이블(라우팅 테이블 B)을 작성합니다. 이것은 서브넷 B를 라우팅 테이블 B와 연관시킵니다. 기본적으로 라우팅 테이블 B에는 라우트가 필요하지 않습니다.

경로 0.0.0.0/0 가 설정되어 있고 다음 홉이 VPN 연결인 경우, 서브넷 간 연결을 확보하려면 다음과 같은 위임 경로를 추가할 수 있습니다:

destination CIDR==zone3 VPC prefix, action==delegate, location==zone1
destination CIDR==zone1 VPC prefix, action==delegate, location==zone3

일반 제한사항

• 현재는 수신(트래픽 소스에 연결됨) 및 송신(서브넷에 연결됨) 트래픽 모두에 대해 사용자 정의 라우팅 테이블을 사용할 수 없습니다. 또한 기본 사용자 정의 라우팅 테이블은 수신 트래픽 소스와 연결될 수 없습니다.
• 현재 비대칭 라우팅으로 인해 리턴 트래픽이 실패할 수 있습니다. 이 문제는 ECMP 정적 라우트에 의존하는 모든 서비스에 영향을 줍니다. 예를 들어, VPC A에서 대상이 10.134.39.64/26 인 두 개의 ECMP 라우트를 작성하고 다음 홉이 각각 192.168.2.4 및 192.168.2.5 라고 가정합니다. 이러한 다음 홉은 NFV 디바이스 IP 주소입니다. VPC의 인스턴스 A에서 트래픽을 보낼 때 패킷은 다음 홉 중 하나로 무작위로 라우팅되며, 반대편의 ECMP 해시 알고리즘으로 인해 반환 트래픽이 전달 트래픽과 동일한 경로를 따른다는 보장이 없습니다. . 이 현상을 _비대칭 라우팅_이라고 합니다. 비대칭 라우팅이 발생하면 라우팅 자체에 문제가 있는 것은 아니지만, 보안 그룹은 하나의 경로에서만 트래픽을 보기 때문에 보안 그룹 규칙이 이 트래픽을 허용하더라도 보안 그룹은 트래픽을 삭제합니다. 일반적으로 ECMP 경로는 사용하지 않는 것이 좋습니다.
• 사용자 정의 라우트에서 다음 홉 IP 주소에 도달할 수 있는지 여부는 전달 트래픽에 라우트를 사용할지 여부를 결정하는 요인이 아닙니다. 이 경우 연결할 수 없는 다음 홉 IP 주소에 대한 트래픽이 전달되지 않을 수 있으므로 동일한 접두부(그러나 다른 다음 홉 IP 주소)를 가진 여러 라우트를 사용할 때 문제가 발생할 수 있습니다.
• IBM Cloud VPC를 사용하면 IANA 특수 목적 범위 및 IBM Cloud 서비스에 할당된 특정 범위를 제외한 경우, VPC 내에서 RFC-1918 및 IANA에 등록된 IPv4 주소 공간을 사적으로 사용할 수 있습니다. 엔터프라이즈 내에서, 그리고 VPC 내에서 IBM Cloud Transit Gateway 또는 IBM Cloud Direct Link와 함께 IANA 등록 범위를 사용할 경우 각 구역에서 사용자 정의 라우트를 설치해야 합니다. 자세한 정보는 IANA 등록 IP 지정을 위한 라우팅 고려사항을 참조하십시오.
• 동일한 대상에 대해 서로 다른 2개의 공지 경로가 존재하는 경우 다음 제한 사항이 적용됩니다.
  • 두 경로의 다음 홉이 동일한 영역에 있는 경우 우선 순위가 더 높은 경로(즉,priority )가 기본 경로로 사용되며 우선순위가 낮은 경로(즉,priority )이 백업 경로로 사용됩니다. 두 라우트의 우선순위가 동일하면 ECMP를 사용하여 두 라우트에서 동일하게 트래픽을 라우트합니다.
  • 두 라우트의 다음 홉이 서로 다른 구역에 있는 경우 Transit Gateway 또는 Direct Link 라우터가 최적의 라우트를 선택합니다. 이 경우에는 가장 오래된 광고 라우트입니다.

라우트 우선순위

동일한 대상 CIDR/접두어를 갖는 다중 라우트가 존재하는 경우, 우선순위 값이 가장 높은 라우트가 사용됩니다. 대상 CIDR/접두어및 우선순위가 동일한 라우트는 ECMP 라우팅을 사용합니다.

송신 라우트

송신 사용자 정의 경로의 경우 대상 경로를 추가할 때 구역을 선택해야 합니다. 그러나 다음 홉이 동일한 구역에 있을 필요는 없습니다. 수신 사용자 정의 라우트의 경우 다음 홉은 동일한 구역에 있어야 합니다.

동일 비용 다중 경로(ECMP)

암시적 라우터는 ECMP 라우팅(동일한 대상을 가진 라우트가 여러 개 있지만 다음 홉 주소가 다른 경우)을 수행하지만 다음과 같은 제한사항이 있습니다.

• 이는 deliver 작업이 있는 라우트에만 적용됩니다.
• 구역당 두 개의 동일한 대상 라우트만 허용되며 각 라우트는 서로 다른 다음 홉 주소를 가져야 합니다.
• ECMP를 사용하면 리턴 경로가 동일한 경로를 사용하지 않을 수 있습니다.
• ECMP는 IP 주소의 다음 홉 유형만 지원합니다.

수신 라우트

• 현재 공용 인그레스 라우팅(public internet 트래픽 선택)은 콘솔에서만 사용할 수 있습니다. CLI및 API가 다가오고 있습니다.
• 각 Ingress 소스 유형은 VPC당 최대 하나의 Ingress 라우팅 테이블과 연관될 수 있지만 VPC에는 여러 Ingress 라우팅 테이블이 있을 수 있으며 각 Ingress 라우팅 테이블에는 하나 이상의 Ingress 유형이 연관될 수 있습니다.
• 특정 트래픽 소스의 Ingress 트래픽은 해당 소스와 연관된 사용자 정의 라우팅 테이블의 라우트를 사용하여 라우팅됩니다.
• 수신 트래픽 소스와 연관된 사용자 정의 라우팅 테이블에 있고 deliver 작업이 적용된 사용자 정의 라우트는 라우트가 추가된 가용성 구역에서 VPC의 주소 접두부 중 하나에 포함된 다음 홉 IP가 있어야 합니다. 또한 다음 홉 IP는 라우트가 대상으로 지정되는 VPC 및 가용성 구역의 가상 서버 인터페이스에 구성되어야 합니다.
• 특정 트래픽 소스의 Ingress 트래픽은 해당 소스와 연관된 사용자 정의 라우팅 테이블의 라우트를 사용하여 라우팅됩니다. 사용자 정의 라우팅 테이블에 일치하는 경로가 없으면 VPC 시스템 라우팅 테이블을 사용하여 라우팅이 계속됩니다. 삭제 조치가 있는 사용자 정의 라우팅 테이블의 기본 라우트를 사용하면 이 동작을 피할 수 있습니다.
• 대상 IP (FIP) 가 있는 사용자 정의 라우트를 포함하는 Ingress 사용자 정의 라우팅 테이블은 FIP가 연관된 가상 서버 인스턴스와 동일한 구역에 정의되어야 합니다.
• 공용 인터넷 route_internet_ingress 소스 유형이 활성화된 경우 IBM Cloud VPN 게이트웨이에 바인딩된 플로팅 IP는 인그레스 라우팅 테이블에서 사용자 지정 경로의 대상으로 사용할 수 없습니다.

고유한 접두부 길이

사용자 정의 라우팅 테이블당 최대 14개의 고유 접두부 길이를 사용할 수 있습니다. 하나의 고유한 접두부만으로 간주되는 동일한 접두부를 가진 라우트가 여러 개 있을 수 있습니다. 예를 들어, /28 접두부가 있는 다중 라우트가 있을 수 있습니다. 이 접두사 길이는 하나의 고유한 접두사로 간주됩니다.

VPN

• 정적 경로 기반 VPN 연결에 대한 경로를 생성할 때는 다음 홉의 VPN 연결 ID를 입력해야 합니다. VPN 게이트웨이는 라우팅 테이블이 연관된 서브넷과 동일한 구역에 있어야 합니다. VPN 게이트웨이를 라우팅 테이블과 연관된 서브넷과 다른 구역에서 다음 홉으로 정의하는 것은 권장되지 않습니다.
• 경로 기반 VPN의 경우, VPN 경로의 다음 홉으로 사설 IP 주소를 사용하지 마십시오. VPN이 다시 시작되거나 IP가 변경되면 IP 주소를 가리키는 경로가 끊어지고 연결이 실패할 수 있습니다. VPN 연결 이름(ID)을 항상 다음 홉으로 사용하십시오. 이렇게 하면 VPN이 재연결될 때 경로가 자동으로 업데이트됩니다.
• 다음 홉으로서 VPN 연결이 있는 라우트는 VPN 연결이 활성 상태인 경우에만 유효합니다. 이 라우트는 VPN 연결이 끊기면 라우팅 검색 중에 검색되지 않습니다.
• VPN 연결과 연결된 다음 홉이 있는 사용자 정의 라우트가 포함된 사용자 정의 라우팅 테이블은 수신 트래픽 소스와 연결할 수 없습니다.
• 사용자 정의 라우트는 라우트 기반 VPN에서만 지원됩니다. 정책 기반 VPN을 사용하는 경우 기본 라우팅 테이블의 VPN 서비스에 의해 자동으로 라우트가 작성됩니다.