Virtual WAN のルーティングと向き合う(ラベル編)

azure
Published: 2023-12-06

はじめに

これまでのエントリでは、Virtual WAN の基本的な動作とルーティングの優先順位、ルーティングをいじるためのルートテーブルを取り扱いました

ここまでのざっくりとしたまとめは次の通りです。

  • Virtul Hub の中には、パケットの転送を担当する Virtual Hub ルータが存在する。
    • Virtual Hub を作るときに個数を指定する「ルーティングインフラストラクチャユニット」のこと
  • Virtual Hub ルータには、ベストパス選択アルゴリズムが存在する
  • Virtual Hub ルータには、パケットの転送先を決定するためのルートテーブルが存在する
    • 初期の状態だと、すべての接続は default という名のルートテーブルを利用する
    • Virtual Hub ルータに複数のルートテーブルを持たせることで、1つの Virtual Hub をマルチテナント的に利用できる
  • Virtual Hub と接続する VNET やオンプレ接続には「関連付け」と「伝達」が存在する
    • 「関連付け」は Virtual Hub ルータからルーティングを学習するための設定
    • 「伝達」は Virtual Hub ルータに対して経路を広報するための設定
  • 「関連付け」と「伝達」は、VNET とオンプレ接続で仕様が異なる
    • VNET の関連付け
      • 自分が接続する Virtual Hub 上に存在する1つのルートテーブルとのみ関連付けできる
      • 関連付けるルートテーブルは、default のルートテーブルでなくてもよい
    • オンプレ接続の関連付け
      • 自分が接続する Virtual Hub 上に存在する default のルートテーブルとのみ関連付けできる
    • VNET の伝達
      • 自分が接続する Virtual Hub 上に存在するルートテーブルだけでなく、自分が接続する Virtual WAN 上に存在する他の Virtual Hub 上のルートテーブルにも伝達できる
      • 複数のルートテーブルに対して伝達できる
    • オンプレ接続の伝達
      • 自分が接続する Virtual Hub 上に存在するルートテーブルとのみ関連付けできる
      • 複数のルートテーブルに対して伝達できる

この中の「オンプレ接続は、自分が接続する Virtual Hub 上に存在するルートテーブルにのみ伝達できる」という仕様のせいで、前回のエントリでは「オンプレ接続が異なるリージョンのルートテーブルに対して自分の経路を伝達できないため、障害時の迂回経路を用意できない」という困りごとにぶち当たりました。下図青点線が、ルートテーブルでは伝達できない障害時の迂回経路です。

障害時の迂回経路

そんな背景も踏まえて、今回はラベルを試します。

仮想ハブのルーティングについて

ラベルとは

ラベルとは、複数のルートテーブルを論理的にグルーピングできる仕組みです。複数のルートテーブルに同じラベルを設定することで、それらのルートテーブルが1つのグループとして扱われます。グルーピングはリージョンを超えられるので、東日本の Virtual Hub 上のルートテーブルと西日本の Virtual Hub 上のルートテーブルに同じラベルを振れます。なお、このラベルは「伝達」でのみ利用できます。

ラベルの動作確認

前回のエントリの検証環境をそのまま利用します。まずは東日本リージョンの「tenant1」ルートテーブルと西日本リージョンの「tenant1」ルートテーブルに「tenant1-label」ラベルを振ります。

ラベル振り

そして、オンプレミスから「tenant1-label」ラベルにのみ経路を伝達します。東西リージョンの「tenant1」ルートテーブルには経路を広報しません。複数のルートテーブルに対して経路を伝達したい時に何個もルートテーブルを選択しなくて良い点が、グルーピング機能であるラベルの良い点です。

オンプレ接続におけるラベルへの伝達

また奇数 VNET の伝達先を「tenant1-label」ラベルと「default」ラベルのみにします。ルートテーブルには伝達しません。

VNET におけるラベルへの伝達

その結果の各ポイントのルートテーブルは次の通りです。

東日本 Virtual Hub の Default ルートテーブル

オンプレ接続から Default のラベルに対して経路を伝達していないので、オンプレの経路が存在しません。

> Get-AzVhubEffectiveRoutes -subId aa9de0c7-adae-4ccc-b041-e4720761aa65 -vhubRgName eval-vwan -vhubName je-vhub -rtName defaultRouteTable

addressPrefixes : {10.3.2.0/24}
nextHops        : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet2
nextHopType     : Virtual Network Connection
routeOrigin     : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet2
asPath          : 

addressPrefixes : {10.3.1.0/24}
nextHops        : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
nextHopType     : Virtual Network Connection
routeOrigin     : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
asPath          : 

addressPrefixes : {10.4.1.0/24}
nextHops        : virtualHubs/jw-vhub
nextHopType     : Remote Hub
routeOrigin     : virtualHubs/jw-vhub
asPath          : 65520-65520

addressPrefixes : {10.4.2.0/24}
nextHops        : virtualHubs/jw-vhub
nextHopType     : Remote Hub
routeOrigin     : virtualHubs/jw-vhub
asPath          : 65520-65520

東日本 Virtual Hub の tenant1 ルートテーブル

東西の「tenant1」ルートテーブルをグルーピングしている「tenant1-label」ラベルに対してオンプレ接続と奇数 VNET が経路を伝達しているので、オンプレ接続と奇数 VNET のみ経路が存在します。偶数 VNET は存在しません。

> Get-AzVhubEffectiveRoutes -subId aa9de0c7-adae-4ccc-b041-e4720761aa65 -vhubRgName eval-vwan -vhubName je-vhub -rtName tenant1

addressPrefixes : {10.3.1.0/24}
nextHops        : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
nextHopType     : Virtual Network Connection
routeOrigin     : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
asPath          : 

addressPrefixes : {192.168.1.0/26}
nextHops        : vpnGateways/vpngwjehub
nextHopType     : VPN_S2S_Gateway
routeOrigin     : vpnGateways/vpngwjehub
asPath          : 65147

addressPrefixes : {10.4.1.0/24}
nextHops        : virtualHubs/jw-vhub
nextHopType     : Remote Hub
routeOrigin     : virtualHubs/jw-vhub
asPath          : 65520-65520

西日本 Virtual Hub の Default ルートテーブル

オンプレ接続から Default のラベルに対して経路を伝達していないので、オンプレの経路が存在しません。

 Get-AzVhubEffectiveRoutes -subId aa9de0c7-adae-4ccc-b041-e4720761aa65 -vhubRgName eval-vwan -vhubName jw-vhub -rtName defaultRouteTable

addressPrefixes : {10.3.1.0/24}
nextHops        : virtualHubs/je-vhub
nextHopType     : Remote Hub
routeOrigin     : virtualHubs/je-vhub
asPath          : 65520-65520

addressPrefixes : {10.3.2.0/24}
nextHops        : virtualHubs/je-vhub
nextHopType     : Remote Hub
routeOrigin     : virtualHubs/je-vhub
asPath          : 65520-65520

addressPrefixes : {10.4.2.0/24}
nextHops        : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet2
nextHopType     : Virtual Network Connection
routeOrigin     : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet2
asPath          : 

addressPrefixes : {10.4.1.0/24}
nextHops        : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet1
nextHopType     : Virtual Network Connection
routeOrigin     : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet1
asPath          : 

西日本 Virtual Hub の tenant1 ルートテーブル

東西の「tenant1」ルートテーブルをグルーピングしている「tenant1-label」ラベルに対してオンプレ接続と奇数 VNET が経路を伝達しているので、オンプレ接続と奇数 VNET のみ経路が存在します。偶数 VNET は存在しません。

> Get-AzVhubEffectiveRoutes -subId aa9de0c7-adae-4ccc-b041-e4720761aa65 -vhubRgName eval-vwan -vhubName jw-vhub -rtName tenant1

addressPrefixes : {192.168.1.0/26}
nextHops        : vpnGateways/vpngwjwhub
nextHopType     : VPN_S2S_Gateway
routeOrigin     : vpnGateways/vpngwjwhub
asPath          : 65147

addressPrefixes : {10.3.1.0/24}
nextHops        : virtualHubs/je-vhub
nextHopType     : Remote Hub
routeOrigin     : virtualHubs/je-vhub
asPath          : 65520-65520

addressPrefixes : {10.4.1.0/24}
nextHops        : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet1
nextHopType     : Virtual Network Connection
routeOrigin     : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet1
asPath          : 

オンプレミス

ルーティングが整ったので、オンプレミスから奇数 VNET の仮想マシンに対して Ping が飛びます。avg は3.368です。

root@omprevnet2vm:~# ping 10.3.1.4
PING 10.3.1.4 (10.3.1.4) 56(84) bytes of data.
64 bytes from 10.3.1.4: icmp_seq=1 ttl=64 time=4.41 ms
64 bytes from 10.3.1.4: icmp_seq=2 ttl=64 time=2.96 ms
64 bytes from 10.3.1.4: icmp_seq=3 ttl=64 time=3.34 ms
64 bytes from 10.3.1.4: icmp_seq=4 ttl=64 time=3.11 ms
64 bytes from 10.3.1.4: icmp_seq=5 ttl=64 time=3.00 ms
--- 10.3.1.4 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 2.962/3.368/4.411/0.542 ms

障害時の挙動

ラベルを利用することで、オンプレ接続は東西の Virtual Hub のルートテーブルに対して、自身の経路を広報できるようになりました。この構成であれば、迂回時のルーティングが挿入されるので、東日本側の VPN 接続が切れたとしても、西日本の VPN 接続経由で通信できるはずです。

障害を再現するために、東日本の Virtual Hub 上の S2S ゲートウェイとの BGP をシャットダウンします。

omprevnet2vm# conf terminal 
omprevnet2vm(config)# router bgp 65147
omprevnet2vm(config-router)# neighbor 10.1.0.12 shutdown 
omprevnet2vm(config-router)# neighbor 10.1.0.13 shutdown 
omprevnet2vm(config-router)# end
omprevnet2vm# show bgp ipv4 unicast summary 
BGP router identifier 192.168.1.4, local AS number 65147 vrf-id 0
BGP table version 35
RIB entries 11, using 2112 bytes of memory
Peers 4, using 2898 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
10.1.0.12       4      65515       144       131        0    0    0 00:00:10 Idle (Admin)        0 N/A
10.1.0.13       4      65515       147       131        0    0    0 00:00:07 Idle (Admin)        0 N/A
10.2.0.12       4      65515       184       160        0    0    0 02:36:15            5        1 N/A
10.2.0.13       4      65515       183       160        0    0    0 02:36:29            5        1 N/A

すると各ポイントの経路は次のようになります。

東日本 Virtual Hub の tenant1 ルートテーブル

通常時は、次の仮想ハブルータのベストパス選択アルゴリズムに従って、自分自身が BGP で学習したオンプレの経路が優先されます。

  1. 最長の経路
  2. Virtual Hub 上のスタティックルート
  3. 自分自身が BGP で学習した ExpressRoute の経路
  4. 自分自身が BGP で学習した S2S VPN の経路
  5. 異なる Virtual Hub から BGP で学習した S2S VPN の経路
  6. 異なる Virtual Hub から BGP で学習した ExpressRoute の経路
  7. BGP の AS-PATH が最も短い経路

ですが、障害によって自分自身の S2S ゲートウェイからオンプレ接続の経路が聞こえなくなるので、西日本側のオンプレ接続が「tenant1-label」ラベル経由で東日本の「tenant1」ルートテーブルに伝達している経路が浮かび上がってきます。その結果として、オンプレのアドレス帯のネクストホップが RemoteHub に変わります。

> Get-AzVhubEffectiveRoutes -subId aa9de0c7-adae-4ccc-b041-e4720761aa65 -vhubRgName eval-vwan -vhubName je-vhub -rtName tenant1

addressPrefixes : {10.3.1.0/24}
nextHops        : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
nextHopType     : Virtual Network Connection
routeOrigin     : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
asPath          : 

addressPrefixes : {192.168.1.0/26}
nextHops        : virtualHubs/jw-vhub
nextHopType     : Remote Hub
routeOrigin     : virtualHubs/jw-vhub
asPath          : 65520-65520-65147

addressPrefixes : {10.4.1.0/24}
nextHops        : virtualHubs/jw-vhub
nextHopType     : Remote Hub
routeOrigin     : virtualHubs/jw-vhub
asPath          : 65520-65520

オンプレ接続からラベルではなくルートテーブルに伝達していた際の、東日本の Virtual Hub 上の「tenant1」ルートテーブルの状態は次の通りでした。西日本のオンプレ接続は西日本の Virtual Hub 上の「tenant1」ルートテーブルにのみ経路を広報していたため、東日本のオンプレ接続で障害が発生するとオンプレ宛ての経路が消失していました。

Get-AzVhubEffectiveRoutes -subId aa9de0c7-adae-4ccc-b041-e4720761aa65 -vhubRgName vwaneval -vhubName je-vhub -rtName tenant1   

addressPrefixes : {10.4.1.0/24}
nextHops        : virtualHubs/jw-vhub
nextHopType     : Remote Hub
routeOrigin     : virtualHubs/jw-vhub
asPath          : 65520-65520

addressPrefixes : {10.3.1.0/24}
nextHops        : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
nextHopType     : Virtual Network Connection
routeOrigin     : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
asPath          : 

オンプレ

東日本の Virtual Hub との BGP が切れているため、西日本の Virtual Hub からのみ経路を学習します。

# show ip bgp 
BGP table version is 35, local router ID is 192.168.1.4, vrf id 0
Default local pref 100, local AS 65147
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

    Network          Next Hop            Metric LocPrf Weight Path
 *= 10.2.0.0/16      10.2.0.12                              0 65515 i
 *>                  10.2.0.13                              0 65515 i
 *> 10.3.1.0/24      10.2.0.12                              0 65515 65520 65520 e
 *=                  10.2.0.13                              0 65515 65520 65520 e
 *> 10.3.2.0/24      10.2.0.12                              0 65515 65520 65520 e
 *=                  10.2.0.13                              0 65515 65520 65520 e
 *= 10.4.1.0/24      10.2.0.12                              0 65515 i
 *>                  10.2.0.13                              0 65515 i
 *= 10.4.2.0/24      10.2.0.12                              0 65515 i
 *>                  10.2.0.13                              0 65515 i
 *> 192.168.1.0/26   0.0.0.0                  0         32768 i

Displayed  6 routes and 11 total paths

東西の Virtual Hub のルーティングが整っているため、オンプレから奇数 VNET に対して Ping が飛びます。ただし「オンプレ→西日本の Virtual Hub →東日本の Virtual Hub →東日本の奇数 VNET」という東西を横断する経路になるため、レイテンシーが悪化(avg=21.133)していることが分かります。

root@omprevnet2vm:~# ping 10.3.1.4
PING 10.3.1.4 (10.3.1.4) 56(84) bytes of data.
64 bytes from 10.3.1.4: icmp_seq=1 ttl=63 time=25.6 ms
64 bytes from 10.3.1.4: icmp_seq=2 ttl=63 time=19.3 ms
64 bytes from 10.3.1.4: icmp_seq=3 ttl=63 time=19.6 ms
64 bytes from 10.3.1.4: icmp_seq=4 ttl=63 time=19.7 ms
64 bytes from 10.3.1.4: icmp_seq=5 ttl=63 time=22.3 ms
64 bytes from 10.3.1.4: icmp_seq=6 ttl=63 time=20.0 ms
--- 10.3.1.4 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5008ms
rtt min/avg/max/mdev = 19.386/21.133/25.650/2.254 ms

まとめ

リージョンをまたいで複数のルートテーブルをグルーピングできるラベルを利用した経路の伝達を試しました。VNET 接続から見ると、伝達先のルートテーブルが多い場合に設定をシンプルにできるというメリットがあります。ラベルを使わなくてもできることが、ラベルを使うと効率よく実現できる形です。一方オンプレ接続から見ると、ルートテーブルでは実現できない「他の Virtual Hub のルートテーブルにも経路を伝達する」を実現できるありがたい機能です。要件に応じてルートテーブルとラベルを使い分けましょう。