モチベ
- 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を指している
おわり
- オンプレ側のスイッチの設定が済んでしまえば、あとは対象のサービスにアクセスする際に透過的に閉域でアクセスするというだけの話
- 意図せずクロスアドバタイズ構成になってしまう罠に気を付けなければ！
GitHubで編集を提案
Discussion