🚅

Azure ExpressRoute Microsoft Peeringを繋ぐ時の話

zukako

2023/07/16に公開

モチベ

ExpressRoute Private Peeringはよく利用されているものの、Microsoft Peeringの雰囲気も掴んでおきたい

Microsoft Peeringとは？

Microsoft 365やAzureのPaaSサービスに対して、パブリックIP帯ながらも専用線(不特定のインターネットを通らない)で接続することができるサービス

Microsoft 365 は、インターネット経由で安全かつ確実にアクセスできるように作られています。したがって、特定のシナリオに限り、ExpressRoute の使用が推奨されます。

保有しているパブリックIPアドレスのみを利用してMicrosoftクラウドサービスに接続

Microsoft オンラインサービス (Microsoft 365 および Azure PaaS サービス) への接続は、Microsoft ピアリング経由で行われます。 Microsoft ピアリングルーティングドメイン経由で、ご使用の WAN と Microsoft クラウドサービスの双方向接続を実現できます。お客様または接続プロバイダーが所有するパブリック IP アドレスのみを使用して Microsoft クラウドサービスに接続する必要があり、定義されてするすべての規則を遵守する必要があります。

やること

以下のような環境が出来上がるイメージ

Microsoft Peeringの用意

ここは審査も入るので容易ではないが、諸々手続きをしてプロビジョニングする
ルートフィルターをアタッチしておく
- ルートフィルターで明示的に広報するサービスを選択しておく必要がある
- ここでは、Azure Storage Japan Eastのみを広報するように設定

オンプレ側スイッチの設定

※AS番号やMSEE側のアドレスは状況により異なるためあくまで参考程度に

Micorosft Peering側での設定値に合わせてこの辺の設定を入れる

Router(config)#int Gi8.715
Router(config-subif)#encapsulation dot1Q 715
Router(config-subif)#ip address 219.99.131.241 255.255.255.252

Pingで疎通確認し、MSEEまでの到達を確認する

Router#ping 219.99.131.242
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 219.99.131.242, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

BGPのneighborの設定を入れる

Router(config)#router bgp 65150
Router(config-router)#nei 219.99.131.242 remote-as 12076
Router(config-router)#nei 219.99.131.242 local-as 9999
Router(config-router)#nei 219.99.131.242 soft-reconfiguration inbound

動作確認

MSEE側から受け取っている経路を確認する

Router#show ip bgp nei 219.99.131.242 received-routes
BGP table version is 241, local router ID is 10.100.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  13.73.8.16/28    219.99.131.242                         0 9999 12076 ?
 *>  13.73.8.32/28    219.99.131.242                         0 9999 12076 ?
 *>  20.38.116.0/23   219.99.131.242                         0 9999 12076 ?
 *>  20.60.172.0/23   219.99.131.242                         0 9999 12076 ?
 *>  20.60.248.0/23   219.99.131.242                         0 9999 12076 ?
 *>  20.150.85.0/24   219.99.131.242                         0 9999 12076 ?
 *>  20.150.105.0/24  219.99.131.242                         0 9999 12076 ?
 *>  20.209.22.0/23   219.99.131.242                         0 9999 12076 ?
 *>  23.98.57.64/26   219.99.131.242                         0 9999 12076 ?
 *>  40.115.169.32/28 219.99.131.242                         0 9999 12076 ?
 *>  40.115.175.16/28 219.99.131.242                         0 9999 12076 ?
 *>  40.115.175.32/28 219.99.131.242                         0 9999 12076 ?
 *>  40.115.227.80/28 219.99.131.242                         0 9999 12076 ?
 *>  40.115.229.16/28 219.99.131.242                         0 9999 12076 ?
     Network          Next Hop            Metric LocPrf Weight Path
 *>  40.115.229.32/28 219.99.131.242                         0 9999 12076 ?
 *>  40.115.231.64/27 219.99.131.242                         0 9999 12076 ?
 *>  40.115.231.112/28
                       219.99.131.242                         0 9999 12076 ?
 *>  40.115.231.128/28
                       219.99.131.242                         0 9999 12076 ?
 *>  52.239.144.0/23  219.99.131.242                         0 9999 12076 ?

Total number of prefixes 19

東日本のストレージアカウントがホストされているパブリックIP空間一覧が広報されてきていて、Next hopはERCircuit上で定義しているサブネット内のアドレスになっている
つまり、パブリックIPアドレス帯だけど、閉域を通っていることになる
BGPで広報されてきたアドレス帯を一つ指定して、詳細を見てみる

Router#show ip bgp 13.73.8.16/28
BGP routing table entry for 13.73.8.16/28, version 230
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  9999 12076, (received & used)
    219.99.131.242 from 219.99.131.242 (40.90.1.208)
      Origin incomplete, localpref 100, valid, external, best
      Community: 12076:52012
      rx pathid: 0, tx pathid: 0x0

確かにルートフィルタで設定したコミュニティ値=12076:52012を持つルートが広報されていて、これはAzure Storage Japan Eastを指している

Microsoft Peering利用時の注意

既定で”クロスアドバタイズ”の構成になっている!?

なんとなくPrivate Peeringで同じスイッチとつながったAzure VNET内に存在するVMのEffective Routeを見てみると、Microsoft Peeringの経路が流れ込んできていた
MS PeeringとPrivate Peeringが両方存在する状態だと、Azure VMが見る経路にもMS Peeringの経路が載る
- よって、本来ExpressRouteを通さなくていいであろうAzure VMからAzure PaaS向けの通信もERを通る形になる
- これを避けるためには、オンプレのスイッチ側でルートマップを書く必要がある
L2サービスの場合は自分で明示的にオンプレ側ルータのConfigにルートマップを書く必要がある
L3サービスの場合は、経路を折り返して広報するのが既定である場合もしくは変更できない場合もあるので要注意

おわり

オンプレ側のスイッチの設定が済んでしまえば、あとは対象のサービスにアクセスする際に透過的に閉域でアクセスするというだけの話
意図せずクロスアドバタイズ構成になってしまう罠に気を付けなければ！

GitHubで編集を提案

Microsoft (有志)Publication

Microsoft Azureをはじめとする最新技術情報をお届けします。 ※このPublicationは日本マイクロソフトまたは米Microsoft所属社員による個人の見解であり、所属する組織の公式見解ではありません。 ※Publicationに参加希望の社員は @07JP27までご連絡ください。

モチベ

Microsoft Peeringとは？

やること

Microsoft Peeringの用意

オンプレ側スイッチの設定

動作確認

おわり

Discussion