AWS VPC PeeringからTransit Gatewayへ移行時のパケロス

これは何

AWS VPC Peeringでメッシュ構造になっている各VPCを、Transit Gatewayでpeeringさせることとなった。 その際、Transit GatewayにMTU 8500の上限があるがパスMTU検出はないため、ジャンボフレームを利用出来るEC2インスタンス間の疎通において、移行時にパケットをドロップする状態になりえるという備忘録。

Transit Gatewayの基本

以下のページを見てもらうのが良い。

クロスアカウントな AWS Transit Gateway を、絵で見て（完全に）理解する。 | DevelopersIO

Transit Gatewayはざっくり言うと、異なるVPCの接続のみならず、DirectConnectやVPNもTransitGatewayに集約出来る、クラウドルーター。

VPC PeeringからTransit Gatewayへの移行

[AWS Black Belt Online Seminar] AWS Transit Gateway 資料及び QA 公開 | Amazon Web Services ブログ にあるような、VPC Peeringによるメッシュ構造となっている箇所について、Transit Gatewayへの移行を行った。Direct Connectによる接続等もある場合には、Transit Gatewayへ集約を行うのが望ましい。

移行作業の基本としては、以下のようになる

• 前提として、VPC_AとVPC_BがVPC Peeringで接続されている
  • この際、VPC_Aのvpc route tableではVPC_Bへの経路にVPC Peeringが使われるように設定しており、VPC_Bも同様の設定がある
• Transit Gateway側の準備として、以下のことを行う
  • Transit Gatewayを1つたてて、transit gateway route tableをVPC_AとVPC_B用に作成する
  • Transit Gatewayにvpc attachmentをVPC_AとVPC_B用に作成して、上記route tableへassociationする
  • VPC_A用のroute tableにはVPC_Bへの経路をpropagationし、VPC_B用のroute tableにはVPC_Aへの経路をpropagationする
• 最終的に切り替え作業として、以下の作業を行う
  • ① VPC_Aのvpc route tableでVPC_Bへの経路をVPC Peeringから、Transit Gateway vpc attachmentへ切り替える
  • ② VPC_Bのvpc route tableでVPC_Aへの経路をVPC Peeringから、Transit Gateway vpc attachmentへ切り替える

VPC PeeringからTransit Gatewayへの移行におけるMTUの制限

基本的に上記の移行作業で移行は完了するのだが、今回上記①と②の作業で時間差を設けてしまったために、通信が不安定になる事象を踏んだ。

前提として、以下の設定が存在する

• AWSのEC2インスタンスでは EC2 インスタンスのネットワークの最大送信単位 (MTU) - Amazon Elastic Compute Cloud にある通り、9001 MTUまでサポートされている。
• VPC PeeringにはMTUの上限は無い
• Transit Gatewayは8500バイトのMTUをサポートしており、8500バイトを超えるパケットはドロップされる
  • トランジットゲートウェイのクォータ - Amazon Virtual Private Cloud
• Transit GatewayにはパスMTU検出の機能は無い

Networkに明るい人ならば上記の前提で、どのようになったか想像はつくだろうが、一から説明する。 ここで重要になるのは、MSSクランプ(送信したMSSと受信したMSSの小さい方を選択する)が適用された場合に、各インスタンスがMSSとして何を選択するかだ。

1. 双方向でVPC Peeringを用いた通信の場合
   • VPC_Aのインスタンスも、VPC_Bのインスタンスも、MTU 9001 (MSS 8961)が選択される
   • 結果として、VPC_AからVPC_Bへの通信も、VPC_BからVPC_Aへの通信もMTU 9001 (MSS 8961)で問題なく行える
2. 双方向でTransit Gatewayを用いた通信の場合
   • VPC_Aのインスタンスも、VPC_Bのインスタンスも、MTU 8500 (MSS 8460)が選択される
   • TCPのハンドシェイクにおいて、当初VPC_AのインスタンスもVPC_BのインスタンスもMTU 9001 (MSS 8961)で接続しようとするが、Transit Gatewayが8500バイトを超えるパケットをドロップすることから、お互い受信するのはMSS 8460となるため、MTU 8500 (MSS 8460)が選択される
   • 結果として、VPC_AからVPC_Bへの通信も、VPC_BからVPC_Aへの通信もMTU 8500 (MSS 8460)で問題なく行える
3. VPC_AからVPC_Bへの経路はTransitGatewayで、VPC_BからVPC_Aへの経路はVPC Peeringで行う場合
   • 今回の①の作業が完了してから、②を実行するまでが、この状態となる
   • VPC_AのインスタンスはMTU 9001 (MSS 8961)を選択する
     • VPC_Aのインスタンスから送信する際はMTU 9001 (MSS 8961)で送信を行い、VPC_Bのインスタンスから届くものもVPC Peering経由ではMTU 9001 (MSS 8961)になるため、VPC_AはMTU 9001 (MSS 8961)が選択されてしまう
   • VPC_BのインスタンスはMTU 8500 (MSS 8460)を選択する
     • VPC_Bのインスタンスから送信する際はMTU 9001 (MSS 8961)で送信を行うが、VPC_Aのインスタンスから届くものはTransit Gateway経由となるためMTU 8500 (MSS 8460)が選択される
   • この結果、VPC_AのインスタンスからVPC_Bのインスタンスに送るパケットのみドロップされる可能性がある

仮に上記の状態で不安定となったならば、該当インスタンスのMTUを sudo ifconfig eth0 mtu 8500 のように設定すれば問題なく通信は行えるようになるだろう。また、通常のTCPを用いる通信に限って言えば、双方向でTransit Gatewayを用いた通信になるとこまで作業しきってしまえば、特に問題はない。

仮にTCPではなくUDPなどで通信する要件が出た場合には、パケットがドロップされる可能性があるが、その場合は双方のインスタンスに対してMTUを細かく設定したりする必要はある。