6.3. プロジェクトネットワーク内からのトラブルシューティング

OpenStack Networking では、プロジェクトが互いに干渉を生じさせることなくネットワークを設定できるように、すべてのプロジェクトトラフィックはネットワークの名前空間に含まれます。たとえば、ネットワークの名前空間を使用することで、異なるプロジェクトが 192.168.1.1/24 の同じサブネット範囲を指定しても、テナント間で干渉は生じません。

プロジェクトネットワークのトラブルシューティングを開始するに、まず対象のネットワークがどのネットワーク名前空間に含まれているかを確認します。

  1. openstack network list コマンドを使用して、すべてのプロジェクトネットワークを一覧表示します。 

    # (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-servers 行の id の値 (9cb32fe0-d7fb-432c-b116-f483c6497b08) を書き留めてください。この値がネットワークの名前空間に追加されているので、次のステップで名前空間の特定が容易になります。

  2. ip netns list コマンドを使用して、ネットワークの名前空間をすべて一覧表示します。 

    # 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-servers のネットワーク ID と一致する名前空間が表示されます。上記の例では、名前空間は qdhcp-9cb32fe0-d7fb-432c-b116-f483c6497b08 です。

  3. 名前空間内でトラブルシューティングのコマンド ip netns exec <namespace> を実行し、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 が実行されるので、これは想定どおりの動作です。