Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
第6章 プロバイダーネットワークのトラブルシューティング
仮想ルーターとスイッチのデプロイメントは、ソフトウェア定義ネットワーク (SDN) としても知られており、一見すると (デプロイメントが) 複雑化しているように感じる場合がありますが、OpenStack Networking のネットワークの接続性をトラブルシュートする診断プロセスは、物理ネットワークの診断プロセスとよく似ています。VLAN を使用する場合は、仮想インフラストラクチャーは、全く別の環境ではなく、物理ネットワークのトランク接続による広帯域化と考えることができます。
本項の構成
- 基本的な ping 送信テスト
- VLAN ネットワークのトラブルシューティング
- テナントネットワーク内からのトラブルシューティング
6.1. 基本的な ping 送信テスト
ping コマンドは、ネットワーク接続の問題解析に役立つツールです。ping コマンドで返される結果は、ネットワーク接続に関する基本的な指標として機能しますが、実際のアプリケーショントラフィックをブロックするファイアウォールなど、すべての接続性の問題を完全に除外するわけではありません。ping コマンドは、指定の宛先にトラフィックを送信することで機能し、次に ping 送信の試行に問題がなかったかどうかを報告します。
ping コマンドは、ICMP トラフィックが途中にあるファイアウォールを通過できることを想定します。
ping テストは、ネットワークの問題が発生しているマシンから実行すると最も有効です。そのため、マシンが完全にオフラインの場合には、VNC 管理コンソール経由でコマンドラインに接続する必要がある場合があります。
たとえば、以下の ping のテストコマンドを成功させるには、複数のネットワークインフラストラクチャー層を検証する必要があります。つまり、名前の解決、IP ルーティング、ネットワークスイッチのすべてが正常に機能していなければなりません。
$ ping www.redhat.com PING e1890.b.akamaiedge.net (125.56.247.214) 56(84) bytes of data. 64 bytes from a125-56.247-214.deploy.akamaitechnologies.com (125.56.247.214): icmp_seq=1 ttl=54 time=13.4 ms 64 bytes from a125-56.247-214.deploy.akamaitechnologies.com (125.56.247.214): icmp_seq=2 ttl=54 time=13.5 ms 64 bytes from a125-56.247-214.deploy.akamaitechnologies.com (125.56.247.214): icmp_seq=3 ttl=54 time=13.4 ms ^C
ping コマンドの結果のサマリーが表示されたら、Ctrl-c で ping コマンドを終了することができます。パケットロスがない場合は、タイムリーかつ安定した接続であることが分かります。
--- e1890.b.akamaiedge.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 13.461/13.498/13.541/0.100 ms
さらに、テストする宛先によっては、ping テストの結果は非常に明確な場合があります。たとえば、以下の図では、VM1 において何らかの接続性の問題が発生しています。接続が可能な宛先を青の番号で示しています。また、成功結果または失敗結果から導かれた結論を記載しています。
1. インターネット: 一般的な最初のステップは、www.redhat.com などのインターネットロケーションに ping テストを送信します。
- 成功: このテストは、送信元と送信先の間にあるさまざまなネットワークポイントすべてが期待通りに機能していることを示します。これには、仮想/物理インフラストラクチャーが含まれます。
- 失敗: 遠隔にあるインターネットロケーションへの ping テストは、さまざまな部分で失敗する可能性があります。ネットワーク上の他のマシンがインターネットに正常に ping 送信できる場合には、インターネット接続は機能していることが分かり、使用しているマシンにもう少し近い箇所でトラブルシューティングを行う必要があります。
2. 物理ルーター: これは、外部の宛先にトラフィックを転送するために、ネットワーク管理者が指定したルーターインターフェースです。
- 成功: 物理ルーターに ping テストを行って、ローカルネットワークと基盤のスイッチが機能しているかどうかを検証することができます。このパケットは、ルーターを通過しないため、デフォルトのゲートウェイにルーティングの問題があるかどうかは分かりません。
- 失敗: これは、VM1 とデフォルトゲートウェイの間で問題があることを示しています。ルーター/スイッチがダウンしているか、不正なデフォルトゲートウェイを使用している可能性があります。機能していることを確認済みの別のサーバーと、設定内容を比較してください。また、ローカルネットワーク上の別のサーバーに ping 送信を試行してみてください。
3. Neutron ルーター: これは、Red Hat OpenStack Platform が仮想マシントラフィックの転送に使用する仮想 SDN (ソフトウェア定義ネットワーク) ルーターです。
- 成功: ファイアウォールが ICMP トラフィックを許可し、ネットワークノードがオンラインの状態です。
- 失敗: インスタンスのセキュリティーグループで、ICMP トラフィックが許可されているかどうかを確認してください。また、ネットワークノードがオンラインで、必要なサービスすべてが実行中であることをチェックし、L3 エージェントのログ (/var/log/neutron/l3-agent.log) を確認してください。
4. 物理スイッチ: 物理スイッチは、同じ物理ネットワーク上にあるノード間のトラフィックを管理する役割を果たします。
- 成功: 仮想マシンが物理スイッチへ送信したトラフィックは、仮想ネットワークインフラストラクチャーを通過する必要があります。つまり、このセグメントが想定通りに機能していることが分かります。
- 失敗: 必要な VLAN をトランク接続するように、物理スイッチポートは設定されていますか？
5. VM2: 同じコンピュートノード上にある、同じサブネットの仮想マシンに ping 送信を試行します。
- 成功: VM1 上の NIC ドライバーと基本的な IP 設定が機能しています。
- 失敗: VM1 のネットワーク設定を検証します。問題がない場合には、VM2 のファイアウォールが単に ping トラフィックをブロックしている可能性があります。また、仮想スイッチが正しく設定されていることをチェックし、Open vSwitch (または Linux Bridge) のログファイルを確認します。
6.2. VLAN ネットワークのトラブルシューティング
OpenStack Newtorking は、VLAN ネットワークをトランク接続して SDN スイッチに到達することができます。VLAN のタグ付けがされたプロバイダーネットワークに対するサポートがあると、仮想インスタンスを物理ネットワークにあるサーバーのサブネットと統合することができます。
VLAN プロバイダーネットワークへの接続のトラブルシューティングを行うには、ネットワークの作成時に指定したゲートウェイ IP に ping 送信をしてみてください。たとえば、以下のコマンドでネットワークを作成します。
# neutron net-create provider --provider:network_type=vlan --provider:physical_network=phy-eno1 --provider:segmentation_id=120 # neutron subnet-create "provider" --allocation-pool start=192.168.120.1,end=192.168.120.253 --disable-dhcp --gateway 192.168.120.254 192.168.120.0/24
この場合には、定義済みのゲートウェイの IP 192.168.120.254 に ping を送信してください。
これに失敗した場合には、関連付けられた VLAN (ネットワーク作成時に定義済み) へのネットワークフローがあることを確認してください。上記の例では、OpenStack Networking は VLAN 120 をプロバイダーネットワークにトランク接続するように設定されています。このオプションは --provider:segmentation_id=120 のパラメーターを使用して設定します。
ブリッジインターフェース (今回の場合は br-ex という名前) の VLAN フローを確認します。
# ovs-ofctl dump-flows br-ex NXST_FLOW reply (xid=0x4): cookie=0x0, duration=987.521s, table=0, n_packets=67897, n_bytes=14065247, idle_age=0, priority=1 actions=NORMAL cookie=0x0, duration=986.979s, table=0, n_packets=8, n_bytes=648, idle_age=977, priority=2,in_port=12 actions=drop
6.2.1. VLAN 設定とログファイルの確認
- OpenStack Networking (neutron) エージェント: openstack コマンドを使用して、すべてのエージェントが稼働しており、正しい名前で登録されていることを確認します。
(overcloud)[stack@undercloud~]$ openstack network agent list +--------------------------------------+--------------------+-----------------------+-------+----------------+ | id | agent_type | host | alive | admin_state_up | +--------------------------------------+--------------------+-----------------------+-------+----------------+ | a08397a8-6600-437d-9013-b2c5b3730c0c | Metadata agent | rhelosp.example.com | :-) | True | | a5153cd2-5881-4fc8-b0ad-be0c97734e6a | L3 agent | rhelosp.example.com | :-) | True | | b54f0be7-c555-43da-ad19-5593a075ddf0 | DHCP agent | rhelosp.example.com | :-) | True | | d2be3cb0-4010-4458-b459-c5eb0d4d354b | Open vSwitch agent | rhelosp.example.com | :-) | True | +--------------------------------------+--------------------+-----------------------+-------+----------------+
- /var/log/containers/neutron/openvswitch-agent.log を確認します。このログでは、作成プロセスで ovs-ofctl コマンドを使用して VLAN のトランク接続が設定されたことが確認できるはずです。
-
/etc/neutron/l3_agent.ini ファイルで external_network_bridge を確認します。ここで値がハードコードされている場合は、L3 エージェント経由でプロバイダーネットワークを使用できず、必要なフローが作成されないので、この値は
external_network_bridge = ""のようになるはずです。 - /etc/neutron/plugin.ini ファイルで network_vlan_ranges を確認します。プロバイダーネットワークを使用している場合には、数字の VLAN ID を指定する必要はありません。VLAN を分離したテナントネットワークを使用している場合にのみ、ここに ID を指定する必要があります。
-
OVS エージェントの設定ファイルのブリッジマッピングを検証し、
phy-eno1にマッピングされているブリッジが存在することと、eno1に適切に接続されていることを確認します。
6.3. テナントネットワーク内からのトラブルシューティング
OpenStack Networking では、テナントトラフィックはすべて、ネットワークの名前空間に含まれます。これにより、テナントは、テナント間の干渉なしにネットワークの設定が可能になります。たとえば、ネットワーク名前空間を使用することで異なるテナントが干渉することなしに 192.168.1.1/24 の同じサブネット範囲を指定することができます。
テナントネットワークのトラブルシューティングを開始するには、まず対象のネットワークがどのネットワーク名前空間に含まれているかを確認します。
1. openstack コマンドを使用して全テナントネットワークを一覧表示します。
# (overcloud)[stack@osp13-undercloud ~]$ openstack network list +--------------------------------------+-------------+-------------------------------------------------------+ | id | name | subnets | +--------------------------------------+-------------+-------------------------------------------------------+ | 9cb32fe0-d7fb-432c-b116-f483c6497b08 | web-servers | 453d6769-fcde-4796-a205-66ee01680bba 192.168.212.0/24 | | a0cc8cdd-575f-4788-a3e3-5df8c6d0dd81 | private | c1e58160-707f-44a7-bf94-8694f29e74d3 10.0.0.0/24 | | baadd774-87e9-4e97-a055-326bb422b29b | private | 340c58e1-7fe7-4cf2-96a7-96a0a4ff3231 192.168.200.0/24 | | 24ba3a36-5645-4f46-be47-f6af2a7d8af2 | public | 35f3d2cb-6e4b-4527-a932-952a395c4bb3 172.24.4.224/28 | +--------------------------------------+-------------+-------------------------------------------------------+
この例では、web-servers ネットワークを検証します。web-server の行の id の値をメモしてください (この例では 9cb32fe0-d7fb-432c-b116-f483c6497b08 です)。この値は、ネットワーク名前空間に追加されており、次のステップで特定がしやすくなります。
2. ip コマンドを使用してネットワーク名前空間をすべて一覧表示します。
# ip netns list qdhcp-9cb32fe0-d7fb-432c-b116-f483c6497b08 qrouter-31680a1c-9b3e-4906-bd69-cb39ed5faa01 qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b qdhcp-a0cc8cdd-575f-4788-a3e3-5df8c6d0dd81 qrouter-e9281608-52a6-4576-86a6-92955df46f56
この結果では、web-server のネットワーク ID と一致する名前空間が存在します。この例では、qdhcp-9cb32fe0-d7fb-432c-b116-f483c6497b08 と表示されています。
3. この名前空間内でコマンドを実行して web-servers ネットワークの設定を検証します。これには、トラブルシューティングのコマンドの先頭に ip netns exec (名前空間) を追加します。例を以下に示します。
a) web-servers ネットワークのルーティングテーブルを表示する場合:
# ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.24.4.225 0.0.0.0 UG 0 0 0 qg-8d128f89-87 172.24.4.224 0.0.0.0 255.255.255.240 U 0 0 0 qg-8d128f89-87 192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0 qr-8efd6357-96
b) web-servers ネットワークのルーティングテーブルを表示する場合:
# ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.24.4.225 0.0.0.0 UG 0 0 0 qg-8d128f89-87 172.24.4.224 0.0.0.0 255.255.255.240 U 0 0 0 qg-8d128f89-87 192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0 qr-8efd6357-96
6.3.1. 名前空間内での高度な ICMP テストの実行
1. tcpdump コマンドを使用して ICMP トラフィックを取得します。
# ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b tcpdump -qnntpi any icmp
次のステップを実行するまで何も出力が表示されない可能性があります。
2. 別のコマンドラインウィンドウで、外部ネットワークへの ping テストを実行します。
# ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b ping www.redhat.com
3. tcpdump セッションを実行するターミナルで、ping テストの詳細結果を確認します。
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
IP (tos 0xc0, ttl 64, id 55447, offset 0, flags [none], proto ICMP (1), length 88)
172.24.4.228 > 172.24.4.228: ICMP host 192.168.200.20 unreachable, length 68
IP (tos 0x0, ttl 64, id 22976, offset 0, flags [DF], proto UDP (17), length 60)
172.24.4.228.40278 > 192.168.200.21: [bad udp cksum 0xfa7b -> 0xe235!] UDP, length 32トラフィックの tcpdump 分析を実行する際には、インスタンスではなくルータインターフェース方向の応答パケットが確認される場合があります。これは、qrouter によりリターンパケットで DNAT が実行されるため、想定通りの動作です。
