LoginSignup
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Azuroinアディクシィ株式会社

Azure Network Watcherと診断ツールを駆使したハイブリッド接続トラブルシューティング

Last updated at Posted at 2025-08-28

オンプレミス環境とAzureを結ぶハイブリッドネットワークにおいて、ExpressRoute での接続に不具合が発生すると、多層にわたる要素（オンプレ側ルーター、回線キャリア、Microsoft Edgeルータ、Azureの構成など）が絡むため、切り分け作業が非常に困難になりがちです。

本稿ではとくにBGPセッション不通・確立失敗を中心に、上級者向けのトラブルシュート方法をAzure Network Watcherを活用する観点から深く解説します。

BGPに関する高度なポイント（ASNのカスタマイズ、MD5認証、VPN併用など）にも触れつつ、具体的なパケットレベルの検証方法やAzureポータル/CLI/PowerShellでの診断手順を詳細に記載します。

0. 事前チェック（Network Watcher 有効化／Agent／SAS）〉

  1. 事前チェック（Network Watcher 有効化／Agent／SAS）

Network Watcher が対象リージョンで有効か確認します。最近は VNet 作成/更新時に自動有効化されますが、過去にオプトアウトしている場合は手動有効化が必要です（Portal/CLI/PowerShell いずれも可）。

VM には Network Watcher Agent VM 拡張機能が必要です。Packet Capture／Connection Monitor／Connection Troubleshoot は Agent 前提で動作します（Portal からの実行時は未導入なら自動インストールされます）。

Packet Capture を Azure Storage に保存する場合：
同一リージョンの Storage アカウントを指定し、Shared Key アクセスが有効（SAS 利用の前提）であることを確認。
SAS（Shared Access Signature）トークンを用意し、コンテナー単位・書き込み権限（Write）・短い有効期限で発行するのが推奨です（SAS の生成手順はポータルから実施可）

1. ExpressRoute ＋ BGP接続の基礎知識

1.1 プライベートピアリングとルーター間の eBGP ハンドシェイク
Private Peeringは最も一般的なExpressRoute利用形態で、VNetとオンプレミス間のプライベートアドレスの交換に使われます。

オンプレ側でCEルーターやPEルーター（キャリアとの境界）からeBGPセッションを張り、Azure側のMSEE（Microsoft Edge Router）と経路交換を行います。

上級の視点としては、以下のようなトピックが挙げられます:

Azure側ASN変更: 既定 12076 以外のASNをAzure側に設定可能（サポート要リクエスト）だが、フェイルオーバーシナリオなどで複雑化するので要注意。

オンプレ側ASN: Private ASを使うかPublic ASを使うかで、BGPが広告時に書き換えを行うかどうかの違い。AllowASオプションを使わないとAzure側で自ASN認定され却下される可能性がある。

複数回線・複数リージョン: BGPをActive/Activeにして負荷分散、あるいはPrimary/BackupにしてAS-path/LocalPrefで切り替えるなどの高度制御。

1.2 TCP/179 通信と Keepalive/Holdタイム調整
BGPのコントロールプレーンはTCP/179でパケット交換するため、このポートが双方で正しく許可されないとセッションが確立しません。

AzureのMSEE側ホールドタイムは既定60/180秒（keepalive=60秒、hold=180秒）でオンプレと交渉されますが、オンプレ側ルーターであまりに短いタイマーを指定するとセッションフラップが起こりやすいです。

また、高速切り替えが欲しい場合は**BFD（Bidirectional Forwarding Detection）**を使い、数百ミリ秒程度で故障検知しBGPに通知する手法がありますが、ExpressRouteではキャリア区間でBFDが有効かどうか制限があるため、プロバイダーに確認が必要です。

1.3 Azure ネイティブなARP/Routeテーブル公開
PowerShell/CLIで Get-AzExpressRouteCircuitARPTable や Get-AzExpressRouteCircuitRouteTable を使ってMSEEのARP/Route情報を確認すると、L2-ARPレベルでの問題かBGP-レイヤでの問題かを切り分けられます。

ARPテーブルが空ならL2不達、ARPがOKで RouteTableが空ならBGPで経路が学習されていないことを示します。

2. Azure Network Watcher の高度機能と内部挙動

2.1 Connection Troubleshoot: プラットフォームレベルでの包括的診断
Connection TroubleshootはNetwork Watcherの中心機能の一つで、実行時に以下の流れで診断を行っています:

対象VMにインストールされたエージェント（またはAzureプラットフォームエージェント）が指定の宛先（FQDN/IP＋ポート）へ実際にパケットを送信する。

Azure 制御プレーンがNSGやUDRの評価を行い、AllowedかBlockedか、次のホップはどこか等を判断。

該当ポートへの到達に成功したか/失敗したかをレポートし、失敗ならどの段階でブロックされたかを可視化する。

実体験として、BGPのPeer IP（オンプレ側）宛にTCP/179を指定し疎通テストを行うと、「NSGで許可/拒否」「UDR不一致」「宛先IPへのルートが存在しない」などの情報が直ちに表示されます。

また中間ホップを検知し、プロバイダGWなどは不透明の場合が多いですが、Azure環境内でNVAを通していればその経路も表示されます。

上級テクニックとして、この機能は検証用の追加VMをスポークVNetに作成し利用するケースが多いです。

ExpressRouteゲートウェイ自体にはConnection Troubleshootを直接実行することはできないため、GWと同じサブネットにテスト用VMを置くか、あるいはスポークVNetにVMを置いてUDRでNVA/Gatewayに行かせる形で擬似的にゲートウェイとの通信を試みます。

2.2 IP Flow Verify: NSGルールマッチと対称ルーティングチェック
IP Flow VerifyはNSGの評価結果を即座に返すため、例えば「VMがOutbound方向にtcp/179で送信しようとした時、NSGでどのルールが適用されるか」を知るのに便利です。

加えてINBOUNDとOUTBOUNDを逆に指定してテストすることで、非対称ルーティングの可能性を洗い出す助けにもなります。
注意点としては、IP Flow VerifyはUDRによる次ホップが無効/誤設定されていても「Allowed」と出る場合があります。

あくまでNSGベースの評価が中心で、UDR結果は単純に「次のホップがGateway/Internet…」程度しか出力されないことがあります。必ずNext HopやEffective Routes機能と併せて、ルーティング要因を確認することが重要です。

2.3 Packet Capture: 内部的にはWindows Filtering Platform or Linux iptables Hook
Azure VMに拡張インストールされるNetwork Watcherエージェントは、WindowsならWFP(Windows Filtering Platform)フック、Linuxならiptablesに似たフックを使ってカーネルレベルでパケットを転送/複製し、ストレージに保存します。

ユーザが覚えておきたいのは、
パケットキャプチャはホストOSではなくゲストOSレベルで行われるため、ゲストネットワークスタックの前後のトラフィックが対象。

ExpressRoute GatewayやNVAなどPaaS/NVA系リソースにはこのキャプチャは使えない（自前カーネルにエージェントを導入できない）

大量パケットが流れるとログサイズが急増するため、取得フィルタをちゃんと設定（TCPポート179のみとか）しないと運用が難しい。

パケット解析のコツとしては、SYN / SYN+ACK / ACKの3段ハンドシェイクが見えるか見えないか、Reset(RST)が返ってくるかなどを主に注目します。

BGPセッション不通の場合、しばしば送信元からSYNが一切来ていない（Inboundなし）、またはSYNには応答しているが戻りがない/ACKが来ない、などのパターンに分かれます。

Note：Packet Capture と SAS／保存先の実務メモ
保存先は「Storage アカウント」「VM ローカル」「両方」から選択可。Storage 保存時は以下を満たす必要があります：
① 対象 VM から Storage へのアウトバウンド 443 到達性、
② Storage 側で Shared Key アクセスが有効（SAS トークン要求）、
③ 同一リージョン。
SAS トークンは**コンテナーに対して必要権限（Write/Read）**を付与し、短期・用途限定で発行します（ポータルの「コンテナー → SAS の生成」から）。SAS URL を本文やチケットに張る場合は閲覧者を限定しましょう。
取得ファイルは、既定では network-watcher-logs コンテナー配下の規定パスに保存されます（Blob パスをログに控えておくと後でダウンロードが容易）。

Portal から開始した場合、必要な Agent 拡張は自動導入されます（手動で維持する場合は最新版への更新も検討）。

2.4 Connection Monitor: 持続監視で断続的問題を捕捉
Connection Monitorは上記の診断を定期・継続的に実行し、時系列での可用性をモニタリングする仕組みです。

BGPセッションは一度確立すると常時Establishedを期待するものですが、キャリアトラブルやオンプレ側ルータリセットなどで断続的に落ちるケースがあります。

Connection Monitorで30秒おきにtcp/179テストを仕掛けるようにすると、BGPが一瞬切れたタイミングも検出可能で、Azure Monitorアラートに紐づけるとメールやWebhookで通知を受け取れます。

大規模環境ではこれが非常に有用で、「朝5時頃から5分間だけBGPフラップが続いた」等の現象を可視化できます。オンプレミス装置のログと付き合わせることで根本原因（CronジョブでFirewallルールリロードされた等）を推察しやすくなります。

3. トラブルシューティング高度手順

3.1 ルータ観点での BGP Low-Level 確認
オンプレ側ルータでの高度な確認としては、debug ip bgp events / debug ip tcp packets（Cisco例）などでBGP handshakeの内部メッセージをリアルタイムに観察します。

特に "BGP: sending OPEN to neighbor" とか "BGP: neighbor x.x.x.x active - TCP connection failed" のログが見えれば、TCP SYNを送ったのに応答がなかったことが明確になります。

Azure側MSEE上の詳細ログはユーザーは直接見られませんが、PowerShellコマンドでARP/Routeテーブルを確認し、AzureサポートにVMログやMSEE内部ログの確認を依頼する形で対応します。

Network WatcherはあくまでゲストVM側の視点が主体です。

3.2 ASパス/LocalPref/Weight と ExpressRouteのルート選択
BGPセッション自体は確立するが、意図した経路が選ばれず通信不可になるケースもあるため、以下を注意：

ExpressRoute Gatewayがデフォルトルートを学習した際にルートプリファレンスが変わり通信がオンプレ経由に…→結果的にループやブラックホールが発生。

オンプレ側でLocalPrefを高く設定し、Azureからの送信が想定外経路を優先 → BGPフラップ。

Network WatcherツールのNext Hopで、VMから宛先への最終的な経路選択をすぐに把握でき、間違って別経路（インターネットなど）になっていないか確認可能。

3.3 ExpressRoute over NVA / Virtual WAN シナリオ
さらに高度なシナリオとして、Virtual WANやサードパーティNVAを介したExpressRouteルーティングがある。
これらの場合、BGPセッション自体はVWANハブやNVAが終端し、VNet側はBGPでなくUDRやStaticルートを使う構成となる。

トラブルシュートはVWANのRouting IntentやNVAのBGP設定、そしてNetwork WatcherのConnection Troubleshoot（NVA経由でトラフィックを通す設定）を組み合わせる必要があり、より複雑になります。

この場合でも共通するのはTCP/179が双方向に通るか、NVAへのUDRが誤っていないかといった原則的アプローチです。

Network WatcherのTopologyを見てNVAがどのサブネットにあり、VMとの接続がどうなっているかを可視化し、誤配線があればそこから原因を絞れます。

3.4 再現性のある事例と回避策
Case: ピアIPを誤設定（/30の上下逆）

Azure側ARPTABLEに“incomplete”表示 → IP Flow Verifyで送信先がNo route → オンプレ側でSYN宛先が存在せず。

対策：/30セグメントのプライマリ/セカンダリ IPを正しく設定し直す。

Case: パケットMTU不整合 → BGPフラップ

VPN併用やDirectServerReturn構成でMTUが低下、BGP Keepaliveが断片化し片方向ドロップ。Network WatcherキャプチャでDFフラグ付きパケットがICMP Fragmentation neededを受け取ってるのを検知。

対策：MSS clampingやMTU調整でBGPトラフィックがフラグメントされる状況を回避。

4. サポート連携時の高度テクニック

4.1 Azureサポートに提供すべきエビデンス
上級者はAzureサポートとの連携をスムーズに行うため、以下の資料を用意すると非常に効果的です:

ExpressRoute Circuit名称, ServiceKey – Microsoftが回線状態を内部で特定する鍵。

PowerShell出力 – Get-AzExpressRouteCircuitARPTableやRouteTable, Get-AzExpressRouteCircuitPeerings, Get-AzExpressRouteCircuitの実行結果をテキストファイルで添付。

Network Watcher Connection Troubleshoot結果 – “Allowed/Blocked”や中間ホップ情報をスクショor JSONで提示。

PacketCapture .pcap – Azure側VMで取得したtcp/179のキャプチャファイルを共有。

オンプレルータ logs – show ip bgp neighbor detail や debug ip bgp eventsの出力、Idle/Activeエラーの具体的ログ。

サポートに依頼する際は「どのような症状が、何時から、どの程度の頻度」といった詳細とともに、上記エビデンスを添付すると問題箇所を非常に絞り込みやすくなります。

Packet Capture の保存先（Blob の完全パスと SAS 有効期限）— 解析側が直接ダウンロードできるように記載。

4.2 回線キャリアとのクロス連携
ExpressRouteの場合、回線キャリア(Equinix/EPS/NTT/など)がL2部分を提供し、その先がMicrosoft MSEEにつながっているため、キャリア区間でARPやVLANタグが不通になるとAzureサポートだけでは把握しきれないことがあります。
ポイント:

キャリアが監視している“CEルータ～PEルータ間”のリンク可用性ログを取り寄せ、同じ時間帯に欠損がなかったか突き合わせ。

必要であればキャリアのNOCとAzureサポートのエンジニアがカンファレンスで同時にトレースする場面もある。

まとめと推奨運用プロセス

Azure Network Watcher の機能（Connection Troubleshoot, IP Flow Verify, Packet Capture, など）を活用することで、複雑なExpressRoute+BGPトラブルの原因を論理的に絞り込めるようになります。

以下を総合的に実践することを推奨します:

1.基礎構成の正確さ
ExpressRouteのPeer IP, VLAN ID, ASN, MD5キーなど、基本要素に誤りがないか初期導入時に細心の注意を払う。

2.監視の徹底

・BGP可用性メトリクスにアラート設定し、セッションDownを即検知。

・Connection Monitorで定期的にTCP/179などの疎通を試し、断続的な障害を記録。

3.トラブルシュート時の段階的アプローチ

・Azure側ステータス/ARP/Routeチェック → オンプレ側BGPログ → Network Watcherツールでパケットの有無を確認 → 必要に応じてパケットキャプチャでTCPレベルを可視化

4.証跡とドキュメント

・運用手順書に「ExpressRoute BGP障害時の調査ステップ」を記載し、取り得るツールのコマンド例（PowerShell / CLI / PortalのGUI）を明示化

・サポートへの問い合わせ時にコマンド結果ログや pcap ファイルをまとめて提出するとタイムロスが少ない

5.事前演習と定期レビュー

・DR演習の一環で「意図的にBGPピア1本を止めてフェイルオーバー確認」などを年1回実施し、Network Watcherの使いこなしを慣れておく。

・ACL/Firewall設計変更があればTCP/179の許可が残っているかなど影響を再チェック。

以上を実行することで、ハイブリッドネットワークにおけるExpressRouteの可用性とトラブルへの対応スピードを大幅に高められます。

ネットワークはクラウドとオンプレが交錯することで複雑度が増しますが、Network Watcherの包括的診断機能をフルに活用すれば、エンジニアがどこでパケットがドロップしているかを素早く掴み、対処可能となるはずです。

参照リンク集

公式ドキュメント（Network Watcher 本体）

診断ツール（オンデマンド）

連続監視（Connection Monitor）

パケットキャプチャ & エージェント

ルーティング/NSGの状況確認（補助）

ExpressRoute の切り分け（BGP/ARP/経路）

プラットフォーム特殊 IP（ヘルスプローブ/VM エージェント等）

参考（SAS トークン）

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?