第5章 デバッグ

5.1. ログの特定

5.1.1. OpenDaylight ログへのアクセス

OpenDaylight のログは、全 OpenDaylight ノードの /opt/opendaylight/data/log/ ディレクトリーに保管されています。OpenDaylight は、そのログを karaf.log ファイルに保管します。

最新のログは、karaf.log という名前で、それよりも前のログには karaf.log.1 というように番号が付きます。

5.1.2. Karaf シェルを使用した OpenDaylight ログへのアクセス

ログにアクセスするもう 1 つの方法として、OpenDaylight ノード上の Karaf シェルにログインする方法があります。

  1. Karaf アカウントに接続します。

      $ ssh -p 8101 karaf@localhost
  2. NetVirt 上でトレースレベルのロギングを有効化します。

      $ log set TRACE org.opendaylight.netvirt
  3. Karaf シェル内のログを tail する必要がある場合には、以下のコマンドを実行します。

      $ log:tail

詳細情報

  • Karaf シェルは、任意の OpenDaylight 機能で異なるロギングレベルを有効にするのに役立ちます。FATAL、ERROR、WARN、INFO、DEBUG、TRACE のレベルから選択することができます。
  • TRACE を有効にすると、大量のログ情報を受信することになります。

5.1.3. OpenStack Networking のログへのアクセス

ネットワーク関連の OpenStack コマンドが失敗した場合には、まず最初に neutron のログを確認すべきです。このログは、各 neutron ノードの /var/log/neutron ディレクトリー内の server.log に保管されます。

server.log ファイルには、OpenDaylight との通信に関するエラーも記載されます。neutron エラーが OpenDaylight との対話に起因している場合には、OpenDaylight ログを確認して、エラーの原因を特定する必要もあります。

5.2. ネットワークエラーのデバッグ

ネットワークでエラーが発生したにも拘らず (例: インスタンスの接続できないなど)、OpenStack コマンドを発行してもエラーが報告されなかったり、neutron のログにも記載されない場合には、OVS ノードを検査してネットワークトラフィックと OpenFlow のフローを確認すると役立つ場合があります。

  1. ネットワークエラーが発生したノードに (superuser として) ログインします。
  2. br-int スイッチに関する情報を表示します。

    # ovs-ofctl -O openflow13 show br-int
  3. 出力を確認します。以下の例と同じような内容が表示されるはずです。

    OFPT_FEATURES_REPLY (OF1.3) (xid=0x2): dpid:0000e4c153bdb306
    n_tables:254, n_buffers:256
    capabilities: FLOW_STATS TABLE_STATS PORT_STATS GROUP_STATS QUEUE_STATS
    OFPST_PORT_DESC reply (OF1.3) (xid=0x3):
     1(br-ex-patch): addr:ae:38:01:09:66:5b
         config:     0
         state:      0
         speed: 0 Mbps now, 0 Mbps max
     2(tap1f0f610c-8e): addr:00:00:00:00:00:00
         config:     PORT_DOWN
         state:      LINK_DOWN
         speed: 0 Mbps now, 0 Mbps max
     3(tun1147c81b59c): addr:66:e3:d2:b3:b8:e3
         config:     0
         state:      0
         speed: 0 Mbps now, 0 Mbps max
     LOCAL(br-int): addr:e4:c1:53:bd:b3:06
         config:     PORT_DOWN
         state:      LINK_DOWN
         speed: 0 Mbps now, 0 Mbps max
    OFPT_GET_CONFIG_REPLY (OF1.3) (xid=0x5): frags=normal miss_send_len=0
  4. br-int スイッチの統計を一覧表示します。

    # ovs-ofctl -O openflow13 dump-ports br-int
  5. 出力を確認します。以下の例と同じような内容が表示されるはずです。

    OFPST_PORT reply (OF1.3) (xid=0x2): 4 ports
      port LOCAL: rx pkts=101215, bytes=6680190, drop=0, errs=0, frame=0, over=0, crc=0
               tx pkts=0, bytes=0, drop=0, errs=0, coll=0
               duration=90117.708s
      port  1: rx pkts=126887, bytes=8970074, drop=0, errs=0, frame=0, over=0, crc=0
               tx pkts=18764, bytes=2067792, drop=0, errs=0, coll=0
               duration=90117.418s
      port  2: rx pkts=1171, bytes=70800, drop=0, errs=0, frame=0, over=0, crc=0
               tx pkts=473, bytes=44448, drop=0, errs=0, coll=0
               duration=88644.819s
      port  3: rx pkts=120197, bytes=8776126, drop=0, errs=0, frame=0, over=0, crc=0
               tx pkts=119408, bytes=8727254, drop=0, errs=0, coll=0
               duration=88632.426s

詳細情報

  • ステップ 3 で、この OVS ノードで 3 つのポートが作成されたのがわかります。1 番目のポートはブリッジ br-ex に送信されるパッチポートで、このシナリオでは、外部ネットワークの接続に使用されます。2 番目のポートは、tap ポートで、DHCP エージェントインスタンスに接続されます (これは、ホストはコントローラーなのでわかります。コントローラーではなく、Compute ロール上の場合には、インスタンスとなります)。3 番目のポートは、テナントトラフィック用に作成された VXLAN トンネルポートです。
  • 各ポートの用途を理解したら、ポートの統計を調べて、ポートがトラフィックの送受信を確実に行なっていることを確認します (ステップ 4 を参照)。
  • ステップ 5 の出力から、各ポートがパケットを受信 (rx pkts) および送信 (tx pkts) していることを確認できます。

5.2.1. OpenFlow のフローを使用した高度なデバッグ

OpenFlow に精通している上級ユーザーの場合には、スイッチ上のフローを検査して、トラフィックがどこでドロップするかを検出するのが次のレベルのデバッグです。

  1. フローを一覧表示してヒットしたパケット数を確認するには、以下のコマンドを入力します。

    # ovs-ofctl -O openflow13 dump-flows br-int
  2. コマンドの出力を確認して、必要な情報を取得します。

    OFPST_FLOW reply (OF1.3) (xid=0x2):
     cookie=0x8000000, duration=90071.665s, table=0, n_packets=126816, n_bytes=8964820, priority=1,in_port=1 actions=write_metadata:0x20000000001/0xffffff0000000001,goto_table:17
     cookie=0x8000000, duration=88967.292s, table=0, n_packets=473, n_bytes=44448, priority=4,in_port=2 actions=write_metadata:0x40000000000/0xffffff0000000001,goto_table:17
     cookie=0x8000001, duration=88954.901s, table=0, n_packets=120636, n_bytes=8807869, priority=5,in_port=3 actions=write_metadata:0x70000000001/0x1fffff0000000001,goto_table:36
     cookie=0x8000001, duration=90069.534s, table=17, n_packets=126814, n_bytes=8964712, priority=5,metadata=0x20000000000/0xffffff0000000000 actions=write_metadata:0xc0000200000222e0/0xfffffffffffff
    ffe,goto_table:19
     cookie=0x8040000, duration=90069.533s, table=17, n_packets=126813, n_bytes=8964658, priority=6,metadata=0xc000020000000000/0xffffff0000000000 actions=write_metadata:0xe00002138a000000/0xffffffff
    fffffffe,goto_table:48
     cookie=0x8040000, duration=88932.689s, table=17, n_packets=396, n_bytes=36425, priority=6,metadata=0xc000040000000000/0xffffff0000000000 actions=write_metadata:0xe00004138b000000/0xfffffffffffff
    ffe,goto_table:48
注記

上記の出力は長いため途中から省略されています。

5.2.2. OpenFlow でのパケットのトラバース

理解すべき重要な点として、パケットに対して実行されるネットワーク機能は複数の異なる OpenFlow テーブルに分かれ、パケットはそれらのテーブルをゼロから順番に通過していくことが挙げられます。受信パケットはテーブル 0 に着信し、次に OpenFlow のパイプライン を経て進み、ポートから送信されて OpenDaylight のコントローラーに到達するか、ドロップされます。パケットは、処理の必要があるネットワーク機能に応じて、1 つまたは複数のテーブルをスキップする場合があります。テーブルの全体図と各テーブルが対応するネットワーク機能を以下に示します。

図5.1 OpenDaylight NetVirt OpenFlow の パイプライン

OpenDaylight NetVirt OpenFlow Pipeline