배경

Oracle Cloud 오사카 리전이 GA했습니다!
이것은, 도쿄-오사카간의 접속 시험해 보고 싶다. 어차피라면, 리모트 피어링으로 폐역 접속 시험하고 싶다.

원격 피어링을 위해서는 먼저 각 지역에서 DRG를 만들어야합니다.

좋아, 만들자!



무려. . Service Limit에 걸렸다. . 게다가, SR로 확장 의뢰해도 현상 5개가 상한이라고 하는(인전해) ※ 늘릴 수 있는 것 같은(미확정). 확실히, 여기( 서비스 제한 )를 봐도 늘릴 수 없는 제한은 쓰지 않는다.

그런가, DRG는 그런 부담없이 사용해 놀 수 있는 것이 아닌가. 이것은 공유 환경이 필요하다. 그래서 여러 VCN간에 도쿄-오사카의 원격 피어링을 공유할 수 있는 방법을 검증했다.

만든 것

여러가지 조사한 결과, DRG를 복수 VCN에서 공유하기 위해서는 Transit Routing을 이용한 Hub & Spoke 구성으로 할 필요가 있다는 결론이 되었습니다.



각 VCN에 대해 라우팅을 구성해야하므로 각 VCN에 할당하는 CIDR 블록을 관리하고 번호를 매길 필요가 있습니다.

참고로 한 링크

Oracle Cloud : VCN Transit Routing에서 Hub and Spoke 구성을 시도했습니다.

포인트

절차는 번잡하기 때문에 포인트만

CIDR 번호 매기기

라우팅을 의식해야 하므로 도쿄와 오사카에서 중복되지 않는 범위의 CIDR을 할당합니다.
라우팅 설정이 단순해지도록 다음과 같이 결정했습니다.

도쿄측의 VCN CIDR 블록

10.0.0.0/16 ~ 10.127.0.0/16을 할당한다.
(제 2 옥텟의 선두 비트가 0)

오사카 측의 VCN CIDR 블록

10.128.0.0/16 ~ 10.255.0.0/16을 할당한다.
(제 2 옥텟의 선두 비트가 1)

DRG의 VCN

위와 다른 주소 대역을 적절하게.

구성

HUB용 VCN

다음을 오사카와 도쿄에서 2 세트 만듭니다
· DRG
· 리모트 피어링 접속
도쿄와 오사카 각각에서 작성한 후, 「접속의 확립」으로 피어링
(왜, 도쿄 측에서 했더니, 왠지 ap-osaka-1이 풀다운에 나오지 않았기 때문에 오사카 측에서 실시했다)
· VCN (만든 DRG 부착)
　・Local Peering GW (Spoke의 수만)
・루트표×2 (DRG 할당용과 Local Peering GW 할당용)

　- 도쿄 측
루트 테이블 (DRG 할당 용)에는 다음 항목이 등록됩니다.
10.0.0.0/16 → LPG -000- # 10.0.0.0/16의 패킷을 LPG -000-에 전달
10.1.0.0/16 → LPG -001- # 10.1.0.0/16의 패킷을 LPG -001-로 전달

루트 테이블 (Local Peering GW 할당 용)에는 다음 항목이 등록됩니다.
10.128.0.0/9 → DRG -Tokyo- # 10.128.0.0/9(오사카의 CIDR)의 패킷을 DRG -Tokyo-에 전송

　- 오사카 측

루트 테이블 (DRG 할당 용)에는 다음 항목이 등록됩니다.
10.128.0.0/16 → LPG -128- # 10.128.0.0/16의 패킷을 LPG -128-로 전달
10.129.0.0/16 → LPG -129- # 10.129.0.0/16의 패킷을 LPG -129-로 전달

루트 테이블 (Local Peering GW 할당 용)에는 다음 항목이 등록됩니다.
　　10.0.0.0/9 → DRG -Osaka- # 10.0.0.0/9(도쿄의 CIDR)의 패킷을 DRG -Osaka-에 전달

Spoke용 VCN

Spoke용 VCN별로 다음 세트를 만듭니다.
· VCN
· · Subnet
　　- 루트표
　　→오사카측 CIDR로 향하는 패킷을 Local Peering GW에 전달하는 설정
　　- 보안 목록
　　→ 잉글스・에그레스에, 오사카측 CIDR과의 통신 허가 설정
・Local Peering GW
　 → 작성 후 Hub의 Local Peering GW와 Peering합니다.

결과

통신 할 수있었습니다 !!

[opc@tokyo2 ~]$ ping 10.129.2.2
PING 10.129.2.2 (10.129.2.2) 56(84) bytes of data.
64 bytes from 10.129.2.2: icmp_seq=1 ttl=62 time=7.86 ms
64 bytes from 10.129.2.2: icmp_seq=2 ttl=62 time=7.83 ms
64 bytes from 10.129.2.2: icmp_seq=3 ttl=62 time=7.83 ms
64 bytes from 10.129.2.2: icmp_seq=4 ttl=62 time=7.87 ms
64 bytes from 10.129.2.2: icmp_seq=5 ttl=62 time=7.84 ms
64 bytes from 10.129.2.2: icmp_seq=6 ttl=62 time=7.85 ms
64 bytes from 10.129.2.2: icmp_seq=7 ttl=62 time=7.85 ms
64 bytes from 10.129.2.2: icmp_seq=8 ttl=62 time=7.85 ms