일반 고려사항

VPC의 모든 접두사와 클래식 네트워크의 모든 서브넷은 트랜짓 게이트웨이에 연결되므로, 이들 간에 중복이 발생하지 않도록 하는 것이 중요합니다. Transit Gateway에 연결할 VPC를 작성하는 경우 겹치지 않는 VPC 접두부로 VPC를 작성해야 합니다.

• IBM Cloud Transit Gateway은(는) IBM Cloud Transit Gateway 위치에 나열된 지역에서 Transit Gateway 프로비저닝을 지원합니다.
• 워크로드에 적합한 위치에 Transit Gateway를 작성하십시오. 예를 들어, us-south(댈러스) 지역에 있는 두 개의 VPC와 eu-de(프랑크푸르트) 지역에 있는 하나의 VPC를 연결할 경우 us-south 지역에 게이트웨이를 작성하는 것이 워크로드에 가장 효율적일 수 있습니다.
• 클래식 액세스 VPC를 트랜짓 게이트웨이에 직접 연결할 수 없습니다. 클래식 리소스를 연결하려면 IBM Cloud 클래식 인프라 연결을 사용하십시오. 그러면 클래식 액세스 VPC의 모든 리소스가 자동으로 연결됩니다.
• Transit Gateway는 네트워크 트래픽이 Transit Gateway를 통해 플로우되기 전에 두 개 이상의 연결이 필요합니다. 45일이상 동안 두 개 미만의 연결이 있는 전송 게이트웨이는 재확보될 수 있습니다 (일시중단된 후 30일후에 삭제됨).
• VPC, Direct Link 또는 기존 인프라를 여러 개의 로컬 게이트웨이와 하나의 글로벌 게이트웨이에 연결할 수 있습니다.
• Transit Gateway 및 해당 연결이 사용 가능하게 되려면 프로비저닝한 후 몇 분이 걸릴 수 있습니다.
• Transit Gateway 연결의 이름을 지정할 때 구체적으로 지정하십시오. 계정 전체의 리소스에 연결할 때 연결 이름을 지정해야 합니다. Transit Gateway와 같은 계정에 있는 리소스에 연결할 때 VPC 이름 또는 'classic'이라는 단어가 기본 선택이 되고 수정할 수 있습니다.
• IBM Cloud Transit Gateway은(는) 멀티 테넌트 애플리케이션으로, 소프트웨어의 단일 인스턴스 및 해당 지원 인프라가 여러 고객에게 서비스를 제공합니다. 따라서 대역폭 사용을 모니터하는 것이 중요합니다. 대역폭을 너무 많이 사용하는 경우, Transit Gateway 인스턴스가 일시중단될 수 있습니다. 이러한 경우가 의심되면 Transit Gateway 인스턴스 연결 상태를 확인하여 Suspended 상태인지 확인하십시오. 해당하면 지원에 문의하여 복구하십시오.
• 다음 ASN은 Transit Gateway GRE (Generic Routing Encapsulation) 및 Direct Link 연결에서 차단됩니다. AS 경로의 알려진 라우트에 포함되지 않도록 어플라이언스에서 이러한 ASN을 사용하지 마십시오. 이러한 ASN이 포함되어 있으면 네트워크가 제대로 작동하지 않습니다.

0, 13884, 36351, 64512, 64513, 65100, 65200-65234, 65402-65433, 65500, 65516, 65519, 65521, 65531 및 4201065000-4201065999

ECMP 고려 사항

• ECMP(Equal-Cost Multi-Path)를 계획할 때는 처리량이 직접 연결 수에 비례하여 선형적으로 증가하지 않는다는 점을 유의해야 합니다. 예를 들어, ECMP를 지원하는 트랜짓 게이트웨이에 10 GB 직접 연결 두 개를 연결한다고 해도, 처리량이 20 GB가 되는 것은 아닙니다. 10 GB보다 많지만 20 GB보다는 적은 처리량을 보게 됩니다. 이는 ECMP가 스트림별 또는 소스별로 작동하기 때문인데, 즉 트래픽이 단일 엔드포인트에서 발생하는 경우 두 링크가 아닌 한쪽 링크를 우선적으로 사용하게 될 가능성이 높다는 뜻입니다. 더 균형 잡힌 처리량을 확보하려면 여러 소스에서 트래픽을 유입시키는 것이 좋습니다. 이렇게 하면 사용 가능한 직접 연결 경로에 부하가 더 고르게 분산되기 때문입니다.

• 제한 사항: 단일 라우터의 직접 링크에는 ECMP가 작동하지 않습니다. 대신, 동일한 접두사를 광고하는 라우터에 한해 직접 링크를 통해 여러 라우터에서 지원됩니다.

• 알려진 제한 사항입니다: 새로운 트랜짓 게이트웨이는 4방향 ECMP를 지원하지만 기존 게이트웨이는 지원 케이스를 열어 지원을 요청하지 않는 한 이 기능을 사용할 수 없습니다.

  트랜짓 게이트웨이에서 ECMP 기능을 사용하지 않으려면 지원 케이스를 열어 거부 목록에 추가하면 게이트웨이에서 이 기능을 사용하지 않도록 설정할 수 있습니다.

가격 책정 고려사항

Transit Gateway 프로비저닝 페이지에 있는 IBM Cloud 비용 견적 도구는 네트워크 연결 유형을 해석할 수 없습니다. 신뢰할 수 있는 비용 견적을 얻으려면 예상되는 환승 게이트웨이 및 연결 수를 입력하십시오. 중복 GRE를 작성하는 경우 각 터널은 연결 한계 에 대해 계산되는 개별 연결입니다.

클래식 인프라 연결 고려사항

• Transit Gateway를 사용하여 VPC를 IBM Cloud 클래식 인프라에 연결하려면 VRF(Virtual Routing and Forwarding)에 대한 클래식 계정이 사용으로 설정되고 IBM Cloud 계정에 연결되어 있어야 합니다. VRF에 대한 계정을 사용으로 설정하는 방법에 대한 정보는 VRF 및 서비스 엔드포인트 사용을 참조하십시오.

• VPC와 클래식 인프라를 Transit Gateway에 연결할 때 VPC의 모든 접두부는 10.0.0.0/8 영역의 IP 주소를 사용하는 클래식 인프라 VRF에 표시됩니다. 기존 인프라와의 연결을 원활하게 하려면, VPC에서 10.0.0.0/14, 10.200.0.0/14, 10.198.0.0/15 및 10.254.0.0/16 블록과 중복되는 접두사를 사용하지 마십시오. 또한 클래식 인프라 서브넷의 주소도 사용하지 마십시오. 클래식 인프라 서브넷의 목록을 보려면 모든 서브넷 보기를 참조하십시오.

• 클래식 가상 서버 인스턴스에는 사설(eth0) 및 공용(eth1) 네트워크 인터페이스가 둘 다 있습니다. 현재 이 인터페이스의 라우팅 테이블은 기본 게이트웨이를 공용 인터페이스(eth1)로 가리킵니다. 개인용 인터페이스를 통해 다른 VPC에서 서브넷을 라우팅하기 위해 라우팅 항목을 추가해야 할 수 있습니다.

• Transit Gateway의 위치 또는 지정된 라우팅 유형에 관계없이 이 연결을 통해 MZR에 걸쳐 있는 모든 IBM Cloud 클라우드 인프라 네트워크에 액세스할 수 있습니다.

• 이 데이터 센터에 있는 클래식 인프라 리소스는 Transit Gateway를 통해 VPC 리소스에 연결됩니다.

• 클래식 인프라가 트랜짓 게이트웨이에 연결되면, 해당 계정에 연결된 모든 클래식 액세스 VPC도 함께 포함됩니다. 이는 이러한 VPC의 서브넷이 클래식 인프라 VRF와 연결되어 있기 때문입니다. 이 방법은 전체 클래식 인프라를 Transit Gateway(특정 Classic Access VPC 대신)에 연결하여 Transit Gateway를 Classic Access VPC에 연결하는 유일한 방법입니다.

• 동일한 데이터 센터에 있는 클래식 연결은 Transit Gateway와 다른 지역에 있는 경우 서로 통신할 수 없습니다.

접두사 필터링 고려 사항

• 접두사 필터는 레거시 GRE 터널 연결을 제외한 모든 Transit Gateway 연결 유형에 대해 지원됩니다. GRE 연결의 경우, 접두사 필터링은 중복 GRE 및 바인딩되지 않은 GRE 연결 유형 모두에 대해 지원됩니다.
• GRE가 아닌 연결의 경우 네트워크 소유자가 접두사 필터를 추가할 수 있습니다. GRE 연결의 경우 Transit Gateway 소유자만 접두사 필터를 추가하거나 수정할 수 있으며, 이는 교차 계정 연결에서 중요한 고려 사항입니다.
• 교차 계정 연결의 경우, 해당 연결의 계정 소유자만 접두부 필터를 수정할 수 있습니다. 다른 계정은 해당 연결을 볼 수 있지만, 필터를 수정할 수는 없습니다.
• 다른 계정에서 들어오는 접두사를 필터링할 수 없습니다.
• 중복 GRE 및 VPN 게이트웨이 연결의 경우 접두사 필터는 최상위 수준 연결에서만 구성할 수 있습니다. 이러한 연결 아래의 개별 터널은 별도의 접두사 필터를 지원하지 않으며, 최상위 수준에서 적용되는 모든 필터가 관련된 모든 터널에 적용됩니다.
• 목록의 접두부 필터는 순차적으로 처리됩니다. 언제든지 순서를 수정할 수 있습니다.
• 연결 범위 옵션으로 ‘다른 계정의 네트워크에 연결 요청’을 선택하면, 해당 연결의 네트워크 소유자가 아니기 때문에 접두사 필터를 설정할 수 없습니다. 접두사 필터는 네트워크를 소유한 계정에서 구성해야 합니다. GRE 연결의 경우 연결을 만들 때 Transit Gateway 소유자만 접두사 필터를 설정할 수 있습니다.
• 접두부 필터 서브넷 마스크는 특정되어 있습니다. 예를 들어, ‘ 10.10.20.0/24 ’로 정의된 규칙은 ‘ 10.10.20.0/28 ’ 서브넷이나 그 외의 다른 서브넷 접두사와는 일치하지 않습니다.
• Transit Gateway에 대한 접두부 서비스 한계를 검토하십시오.

GRE(Generic Routing Encapsulation) 연결 고려사항

특정 GRE 연결에 대한 다음 고려사항을 검토하십시오.

Direct Link 연결 관련 고려 사항

온프레미스 네트워크가 IBM Cloud의 다른 네트워크에 연결할 수 있도록 Transit Gateway에 대한 Direct Link 연결을 작성할 수 있습니다. Direct Link가 Transit Gateway에 연결되면 온프레미스 네트워크가 다른 모든 Transit Gateway 연결에 대한 액세스 권한을 받습니다. 마찬가지로, Transit Gateway에 연결된 다른 모든 네트워크가 온프레미스 네트워크에 액세스할 수 있습니다. Direct Link 연결은 실제 또는 가상 교차 연결에 대해 표준 Direct Link 오퍼링과 동일한 프로세스를 따릅니다. 연결이 Transit Gateway에서 삭제되면 Transit Gateway가 Direct Link에 연결되지 않은 것처럼 작동합니다.

Transit Gateway 연결에 대한 동일한 네트워크 서브넷 고려사항이 Direct Link 연결에도 적용됩니다. 성공적인 연결을 보장하려면, Direct Link 에 연결된 네트워크에서 다른 연결과 중복되는 접두사를 사용하지 마십시오.

Power Virtual Server 연결 고려사항

Power Virtual Server 인스턴스를 Transit Gateway에 연결할 수 있습니다. 이를 통해 Power Virtual Server 을 다운스트림 대중교통 게이트웨이에 직접 연결할 수 있습니다. Power Virtual Server 가 트랜짓 게이트웨이에 연결되면, Power Virtual Server 서비스 인스턴스는 모든 다운스트림 트랜짓 게이트웨이 리소스 및 서비스에 액세스할 수 있게 됩니다. 마찬가지로, 트랜짓 게이트웨이에 연결된 모든 하위 네트워크는 Power Virtual Server 인스턴스에 액세스할 수 있습니다.

Power Virtual Server 연결은 로컬 또는 글로벌 라우팅을 사용할 수 있습니다. 그러나 대중교통 게이트웨이와 동일한 지역에 있는 Power Virtual Server 인스턴스만 로컬 라우팅을 사용할 수 있습니다. 또한 Power Virtual Server 인스턴스는 로컬 라우팅을 사용하여 여러 전송 게이트웨이에 연결할 수 있지만 글로벌 라우팅을 사용하는 하나의 전송 게이트웨이에만 연결할 수 있습니다. 다운스트림 서비스는 Transit Gateway 유형을 기반으로 라우트 환경 설정을 준수합니다.

트랜짓 게이트웨이 연결에 적용되는 네트워크 서브넷 관련 고려 사항은 Power Virtual Server 연결에도 동일하게 적용됩니다. 성공적인 연결을 보장하려면 Power Virtual Server 인스턴스에서 다른 연결과 겹치는 접두사를 사용하지 마세요. Transit Gateway 에서는 노출되는 접두사를 제한하는 접두사 필터링과 연결이 생성된 후 중복되는 접두사를 확인할 수 있는 라우팅 테이블 보고서를 제공합니다.

VPN 게이트웨이 연결 고려 사항

IBM Cloud 에서 온프레미스 또는 외부 네트워크가 다른 네트워크와 연결할 수 있도록 트랜짓 게이트웨이에 VPN 게이트웨이 연결을 만들 수 있습니다. VPN 게이트웨이는 트랜짓 게이트웨이 아키텍처 내에서 스포크 역할을 수행하여 터널 복잡성을 줄이면서 여러 네트워크에서 효율적인 피어링을 지원합니다. 이 설계는 이중화 GRE 터널을 통해 eBGP 동적 라우팅을 사용하여 확장 가능하고 탄력적인 연결성을 제공합니다.

• 각 VPN 게이트웨이 연결은 VPN 게이트웨이와 트랜짓 게이트웨이 사이에 4개의 중복 GRE 터널을 자동으로 프로비저닝합니다. IBM 는 동적 라우팅을 위해 eBGP 세션을 실행하여 이러한 터널을 관리합니다. 온프레미스 연결은 보안 통신을 위해 eBGP over IPsec 터널을 사용합니다. VPN 게이트웨이 연결을 생성, 삭제, 이름 변경은 가능하지만, 개별 GRE 터널은 수정하거나 제거할 수 없습니다.

• 요금은 연결당 4개의 GRE 터널 비용과 데이터 트래픽 요금을 기준으로 합니다.

• VPN 게이트웨이 연결은 기본적으로 전송 게이트웨이당 4개, 영역당 2개로 제한됩니다.

• VPN 게이트웨이 연결은 접두사 필터링을 지원하지 않습니다. 귀하는 BGP 세션의 경로 필터링을 관리할 책임이 있습니다.

• 언제든지 동적 또는 정적 VPN 연결을 만들 수 있습니다. 정적 연결은 트랜짓 게이트웨이 부착 여부와 관계없이 작동합니다. 동적 연결을 사용하려면 트래픽이 흐르기 전에 VPN 게이트웨이를 전송 게이트웨이에 연결해야 합니다.

• VPN 게이트웨이를 전송 게이트웨이에 연결한 후에는 로컬 ASN을 변경할 수 없습니다.

• VPN을 Direct Link 연결의 백업으로 구성하려면 Direct Link 경로가 선호되는지 확인해야 합니다. 이를 위해 온프레미스 디바이스에서 AS 경로 사전 추가 또는 MED(다중 출구 판별기)와 같은 메커니즘을 활용할 수 있습니다.

• VPN 게이트웨이 연결을 생성할 때 GRE 터널 IP 주소에 대한 CIDR 블록을 정의해야 합니다. 추가 델리게이트-VPC 경로가 필요하지 않으므로 RFC 1918 비공개 주소 범위를 사용하는 것이 좋습니다. CIDR 블록은 최소 /27 이상이어야 하며, 트랜짓 게이트웨이에 구성된 다른 연결 CIDR과 겹치지 않아야 합니다.

  표준 사설 IP 범위(10.0.0.0/8, 172.16.0.0/12, 또는 192.168.0.0/16)를 벗어난 VPN 게이트웨이에 CIDR을 할당하는 경우, 적절한 트래픽 흐름을 사용하려면 VPC 라우팅 테이블에 수동으로 경로를 추가해야 합니다(VPN 게이트웨이와 동일한 영역에 있음). 다음과 같은 두 가지 옵션이 존재합니다.

  • 목적지가 전체 VPN 할당 CIDR(예: 100.31.128.0/18)로 설정된 단일 경로를 추가하고 동작을 Delegate-VPC로 설정합니다.
  • 각 VPN 터널의 로컬 게이트웨이 IP(예: 100.31.128.1/32)를 대상으로 하는 4개의 개별 경로를 추가하고 동작을 Delegate-VPC로 설정합니다.

  첫 번째 옵션은 더 간단한 반면, 두 번째 옵션은 고급 네트워크 설계 또는 문제 해결에 선호될 수 있는 보다 세분화된 라우팅 제어를 제공합니다.

VPC 고려사항

• IBM Cloud VPC에서는 RFC-1918 및 IANA에 등록된 IPv4 주소 공간을 VPC 내에서 사적으로 사용할 수 있도록 허용하며, IANA 특수 목적 범위 및 IBM Cloud 서비스에 할당된 특정 범위에 대해서는 일부 예외가 적용됩니다. IBM Cloud Transit Gateway와 관련된 VPC 및 엔터프라이즈 내에서 IANA 등록 범위를 사용하는 경우 각 구역에 사용자 정의 라우트를 설치해야 합니다. 자세한 정보는 IANA 등록 IP 지정을 위한 라우팅 고려사항을 참조하십시오.

• 단일 Transit Gateway 또는 여러 Transit Gateway를 작성하여 둘 이상의 IBM Cloud VPC와 상호 연결할 수 있습니다. 또한 IBM Cloud 클래식 인프라를 Transit Gateway에 연결하여 클래식 인프라 자원과 원활한 통신을 제공할 수 있습니다. 자세한 정보는 VPC 상호 연결을 참조하십시오.

• VPC의 베어메탈은 지원되지 않습니다.

라우팅 고려사항

• Transit Gateway에 대한 모든 연결은 서로 연결되므로 로컬 또는 글로벌 라우팅이 각 게이트웨이에 적합한지 결정하기 전에 상호 연결할 모든 리소스를 신중히 고려하십시오.

  두 라우팅 옵션에서 시작되는 라우팅은 사설 IBM Cloud 네트워크를 떠나지 않으며 성능을 위해 최적화됩니다.

• 게이트웨이를 사용하여 동일한 다중 구역 지역(MZR)에 있는 VPC를 연결하려면 로컬 라우팅을 사용하여 동일한 MZR(예: us-south(댈러스)) 내의 액세스 가능한 모든 리소스에 대한 연결을 제공하십시오.

  

• Transit Gateway를 사용하여 로컬로 서로 다른 MZR 간에 VPC를 연결하려는 경우, 동일한 MZR의 VPC에 로컬 게이트웨이를 사용하고 MZR 전체의 VPC에는 글로벌 게이트웨이를 사용하십시오. 또한 고가용성(HA) 시나리오를 따르는 예제를 사용할 수 있습니다. VPC A 및 B의 모든 데이터를 VPC C 및 D에 복제할 수 있습니다. 미국 남부 지역에 문제가 발생하면 미국 동부로 연결 라우트가 재설정됩니다.

  

  지정된 라우팅 유형과 상관없이 IBM Cloud Transit Gateway 에서 모든 MZR에 있는 클래식 인프라에 연결할 수 있습니다. 그러려면 Transit Gateway에 Classic Connection을 추가하기만 하면 됩니다.

• 프로비저닝 후 게이트웨이의 라우팅 유형을 편집할 수 있습니다. 그러나 라우팅 유형을 ‘글로벌’에서 ‘로컬’로 변경하려면, 먼저 모든 글로벌 연결(즉, 게이트웨이와 동일한 위치에 있지 않은 리소스에 대한 연결)을 제거해야 합니다. IBM Cloud 클래식 인프라에 대한 연결은 항상 로컬로 간주됩니다.

• 로컬 라우팅에서 글로벌 라우팅으로 변경할 경우, 관련 글로벌 연결에 대한 요금이 모두 청구됩니다. 라우팅 유형이 변경되는 경우에도 네트워크 트래픽에는 영향을 미치지 않습니다.

라우트 보고서 고려사항

• 경로 보고서에 표시되는 AS 경로는 단일 영역의 관점을 제공합니다. 소스 또는 목적지가 서로 다른 영역에 걸쳐 있는 경우 경로 길이가 달라질 수 있습니다. 예를 들어, DAL10 와 DAL12 에 있는 두 개의 직접 링크가 있는데, 둘 다 VPC 또는 클래식 환경에 연결된 DAL 기반 트랜짓 게이트웨이를 향한 동일한 AS 경로 길이를 광고한다고 가정해 보겠습니다. DAL10 가상 서버 인스턴스에서 호출하는 경우:

  • DAL10 직접 링크가 선호됩니다.
  • DAL12 에서 시작하는 연결의 경우 DAL12 직접 링크가 선호됩니다.
  • DAL13 의 경우 게이트웨이가 ECMP 라우팅을 사용하도록 설정되어 있거나 단일 직접 링크가 사용된다고 가정합니다. 그러나 BGP가 재설정되는 동안 다른 직접 링크로 전환될 수 있습니다.

• 겹치는 라우트는 Transit Gateway 구성 시 흔히 발생하는 문제입니다. 두 개 이상의 연결 경로가 겹치는 경우 트래픽이 의도한 대로 라우팅되지 않을 수 있습니다. 자세한 정보는 라우트 충돌 주소 지정 을 참조하십시오.

• 새 가상 연결 (VPC, 클래식 인프라 또는 Direct Link) 이 활성 상태에 도달하면 전송 게이트웨이가 라우트를 학습할 수 있도록 5분을 허용하십시오. 모든 라우트를 학습하기 전에 라우트 보고서를 생성하면 부분 라우트 보고서가 생성됩니다.

• 연결이 0.0.0.0/0 라우트를 표시하는 경우 겹치는 접두부를 계산할 때 해당 라우트가 무시됩니다.

• 언제든지 게이트웨이당 하나의 보고서만 사용 가능합니다. 새 보고서를 생성하면 이전 보고서가 삭제됩니다.

• 연결을 추가하거나 제거하면 이전 라우트 보고서가 정확하지 않을 수 있습니다. 따라서 해당 연결 내에서 경로를 업데이트하는 경우 새 경로 보고서를 생성하는 것이 좋습니다.

• 접두사 필터에 의해 하나 이상의 경로가 거부된 경우 해당 경로는 경로 보고서에 표시되지 않습니다.

서비스 한계

IBM Cloud Transit Gateway를 사용하는 동안 다음 서비스 한계에 유의하십시오.

서비스 한계를 확장해야 하는 경우 IBM 지원 센터 케이스를 열 수 있습니다.