Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
項目一覧
 

NorthStar Controllerトラブルシューティングガイド

このドキュメントでは、明らかな問題が NorthStar Controller に起因するかルータに起因するかを特定するための戦略と、NorthStar Controller に起因すると特定された問題のトラブルシューティング手法について説明します。

トラブルシューティングの調査を開始する前に、すべてのシステム プロセスが稼働していることを確認します。プロセスのサンプルリストを以下に示します。実際のプロセスのリストは異なる場合があります。

RUNNINGではなくSTOPPEDと表示されているプロセスを再起動します。

手記：

すべてのプロセスを停止、開始、または再起動するには、 service northstar stop、 service northstar start、および service northstar restart コマンドを使用します。

NorthStar Controller Web UI からシステム プロセスのステータス情報にアクセスするには、[ More Options>Administration ] に移動して [ System Health] を選択します。

各システムプロセスの現在のCPU使用率、メモリ使用率、仮想メモリ使用率、およびその他の統計情報が表示されます。 図 1 に例を示します。

手記：

この表示には、実行中のプロセスのみが含まれます。
図1:プロセスステータス表示 Process Status Display

表 1 に、[Process Status] テーブルに表示される各フィールドを示します。

表 1: プロセス ステータス フィールドの説明
フィールド の説明

過程

NorthStar Controller プロセスの名前。

PID

プロセス ID 番号。

利用者

このプロセスに関する情報にアクセスするために必要な NorthStar Controller ユーザー権限。

群

このプロセスに関する情報にアクセスするために必要な NorthStar Controller ユーザー グループのアクセス許可。

CPU%の

このプロセスで現在使用されている CPU の現在の割合を表示します。

記憶

このプロセスで現在使用されているメモリの割合を表示します。

仮想メモリ

このプロセスで使用されている現在の仮想メモリを表示します。

CPU 時間

プロセスの命令を処理するために CPU が使用された時間

CMDの

システム プロセスの特定のコマンド オプションを表示します。

トラブルシューティング情報は、次のセクションに表示されます。

NorthStar Controllerのログファイル

トラブルシューティング作業全体を通して、さまざまな NorthStar Controller ログ ファイルを表示すると役立つ場合があります。ログファイルにアクセスするには:

  1. NorthStar Controller Web UIにログインします。

  2. [ More Options > Administration ] に移動し、[ Logs] を選択します。

    NorthStar のシステム ログとメッセージ ファイルの一覧が表示されます (図 2 にその切り捨てられた例を示します)。

    図2:システムログファイルとメッセージファイルSample of System Log and Message Filesのサンプル

  3. 表示するログ・ファイルまたはメッセージ・ファイルをクリックします。

    ログファイルの内容がポップアップウィンドウに表示されます。

  4. ファイルを別のブラウザウィンドウまたはタブで開くには、ポップアップウィンドウで[ View Raw Log ]をクリックします。

  5. ポップアップ・ウィンドウを閉じ、ログ・ファイルおよびメッセージ・ファイルのリストに戻るには、ポップアップ・ウィンドウの右上隅にある「 X 」をクリックします。

表 2 は、PCS と PCE の問題の特定とトラブルシューティングに最も一般的に使用される NorthStar Controller ログ ファイルの一覧です。

表2:トップNorthStar Controllerトラブルシューティングログファイル

ログファイル

形容

場所

pcep_server.log

PCEP サーバーに関連するログ エントリ。PCEPサーバは、PCEPセッションを維持します。ログには、PCC と PCE 間の双方向の通信に関する情報が含まれています。

詳細な PCEP サーバ ロギングを設定するには、次の手順を実行します。

  1. NorthStar Controller CLI から pcep_cli を実行します。

  2. 「 set log-level all」と入力します。

  3. CTRL-Cを押して終了します。

/var/log/jnc

pcs.log

PCS に関連するログ エントリ。PCS はパスの計算を担当します。このログには、プロビジョニング・オーダーなど、PCSがToposerverから受信したイベントが含まれます。また、PCS の正常な起動を妨げる通信エラーや問題の通知も含まれています。

/opt/northstar/logs

toposerver.log

トポロジー・サーバーに関連するログ・エントリー。トポロジー・サーバーは、トポロジーの保守を担当します。これらのログには、PCS と Toposerver、Toposerver と NTAD、および Toposerver と PCE サーバーの間のイベントの記録が含まれます

/opt/northstar/logs

表3 は、トラブルシューティングにも役立つ追加のログファイルの一覧です。 表 3 のすべてのログ ファイルは、 /opt/northstar/logs ディレクトリの下にあります。

表3:NorthStar Controllerのトラブルシューティングのための追加ログファイル
ログファイル 形容

cassandra.msg

cassandra データベースに関連するイベントをログに記録します。

ha_agent.msg

HA コーディネーターのログ。

mlAdaptor.log

トランスポート コントローラー ログへのインターフェイス。

net_setup.log

構成スクリプトのログ。

nodejs.msg

nodejs に関連するイベントをログに記録します。

pcep_server.log

PCC と PCE 間の双方向の通信に関連するログ ファイル。

pcs.log

PCS に関連するログ ファイルには、PCS が Toposerver から受信したイベントと、Toposerver から PCS へのイベント (プロビジョニング注文を含む) が含まれます。このログには、通信エラーと、PCS の正常な起動を妨げる問題も含まれます。

rest_api.log

REST API 要求のログ ファイル。

toposerver.log

トポロジー・サーバーに関連するログ・ファイル。

PCS とトポロジ サーバー、トポロジ サーバーと NTAD、およびトポロジ サーバーと PCE サーバーの間のイベントの記録が含まれます

手記：

pcshandler.logファイルに転送されたメッセージは、pcs.logファイルにも転送されます。

Junos VM に関連するログを表示するには、ルーターへの telnet セッションを確立する必要があります。Junos VM のデフォルト IP アドレスは 172.16.16.2 です。Junos VMは、必要なBGP、ISIS、またはOSPFセッションの維持を担当します。

空のトポロジ

図 3 は、ルータから Toposerver への情報フローを示しており、その結果、NorthStar Controller UI にトポロジが表示されます。トポロジー表示が空の場合、このフローが中断された可能性があります。フローが中断された場所を見つけることは、問題解決プロセスの指針となります。

図 3: トポロジー情報フローTopology Information Flow

トポロジーはルーターを起点としています。NorthStar Controller がトポロジーを受信するには、ネットワーク内のルーターの 1 つから Junos VM への BGP-LS、ISIS、OSPF セッションが存在する必要があります。また、Junos VMとTopoServerの間に、確立されたNetwork Topology Abstractor Daemon(NTAD)セッションが存在する必要があります。

これらの接続を確認するには:

  1. NorthStar Controller CLIを使用して、次の例に示すように、ToposerverとJunos VM間のNTAD接続が正常に確立されたことを確認します。

    手記：

    ポート 450 は、Junos VM と Toposerver の接続に使用されるポートです。

    次の例では、NTAD 接続が確立されていません。

  2. Junos VM にログインして、NTAD がトポロジ エクスポートを有効にするように構成されているかどうかを確認します。以下のgrepコマンドは、Junos VMのIPアドレスを提供します。

    topology-export ステートメントがない場合、Junos VM は Toposerver にデータをエクスポートできません。

  3. Junos OS show コマンドを使用して、Junos VMとルーター間のBGP、ISIS、OSPFの関係がアクティブかを確認します。セッションがACTIVEでない場合、トポロジー情報をJunos VMに送信できません。

  4. Junos VM で、lsdist.0 ルーティングテーブルにエントリーがあるかどうかを確認します。

    lsdist.0 ルーティングテーブルに 0 しか表示されない場合、送信できるトポロジーはありません。トポロジ取得の設定については、『 NorthStar Controller Getting Started Guide 』のセクションを参照してください。

  5. lsdist.0 ルーティングテーブルに少なくとも 1 つのリンクがあることを確認します。Toposerver は、少なくとも 1 つの NTAD リンク イベントを受信した場合にのみ、初期トポロジを生成できます。他のノードとのIGP隣接関係のない単一のノードで構成されるネットワーク(たとえば、ラボ環境で可能な場合)では、Toposerverはトポロジを生成できません。 図4 は、初期トポロジを作成するためのToposerverのロジック・プロセスを示しています。

    図 4: トポロジーの初期作成Logic Process for Initial Topology Creationの論理プロセス

    この理由で初期トポロジを作成できない場合、toposerver.logは次の例のようなエントリを生成します。

NTADバージョン

SR LSPがプロビジョニングされておらず、pcs.logに次の例のようなメッセージが表示された場合:

NTADのバージョンが正しくない可能性があります。NTAD のバージョンについては、「 NorthStar Controller のインストール 」を参照してください。

不正なトポロジ

Toposerver の重要な機能の 1 つは、NTAD リンク イベントからの送信元と宛先の IPv4 Link_Identifiersを照合することによって、ルーターからの単方向リンク(インターフェイス)情報を双方向リンクに関連付けることです。NorthStar UIに表示されるトポロジが正しく表示されない場合は、Toposerverが双方向リンクの生成と保守をどのように処理するかを理解しておくと役立ちます。

双方向リンクの生成と維持は複雑なプロセスですが、いくつかの重要なポイントを次に示します。

  • 各双方向リンクを構成する 2 つのノードでは、最初に割り当てられた(したがって、ノード ID 番号が小さい)ノード ID にノード A が指定され、他のノードにノード Z が指定されます。

    手記：

    ノードIDは、Toposerverが最初にNTADからNodeイベントを受信したときに割り当てられます。

  • ノードIDがクリアされて再割り当てされるたびに(Toposerverの再起動時やネットワークモデルのリセット時など)、ノードIDとAとZの指定が変更される可能性があります。

  • Toposerverは、ネットワーク内のリンクが追加または変更されると、リンク更新メッセージを受信します。

  • Toposerverは、リンクがネットワークから削除されると、Link Withdrawalメッセージを受信します。

  • リンク更新メッセージとリンク取り消しメッセージは、ノードの動作ステータスに影響を与えます。

  • ノードの動作状態とプロトコル(IGP 対 IGP と MPLS)によって、リンクを使用して LSP のルーティングが可能かどうかが決まります。リンクを使って LSP をルーティングするには、そのリンクの運用ステータスが UP であり、かつ MPLS プロトコルがアクティブでなければなりません。

欠落しているLSP

トポロジは正しく表示されているのに LSP が欠落している場合は、図 5 に示すように、PCC から Toposerver への情報フローを確認します( 図 5 に示すように、トンネルが NorthStar Controller UI に追加される結果)。フローは PCC での設定から始まり、そこから LSP 更新メッセージが PCEP セッションを介して PCEP サーバーに渡され、次に Advanced Message Queuing Protocol (AMQP) 接続を介して Toposerver に渡されます。

図 5: LSP 情報フロー LSP Information Flow

これらの接続を確認するには:

  1. toposerver.logを見てください。ログは、PCEPサーバとの接続が失われたか、または正常に確立されなかったことを検出すると、15秒ごとにメッセージを出力します。次の例では、ToposerverとPCEPサーバ間の接続がダウンとしてマークされていることに注意してください。

  2. NorthStar Controller CLI を使用して、次の例に示すように、PCC と PCEP サーバ間の PCEP セッションが正常に確立されたことを確認します。

    手記：

    ポート 4189 は、PCC から PCEP サーバーへの接続に使用されるポートです。

    セッションが確立されたことがわかっていることは便利ですが、必ずしもデータが転送されたことを意味するわけではありません。

  3. PCEP サーバーが PCC から LSP について学習したかどうかを確認します。

    出力の右端の列には、学習されたLSPの数が表示されています。この数値が 0 の場合、LSP 情報は PCEP サーバーに送信されていません。その場合は、『 NorthStar Controller Getting Started Guide』の説明に従って、PCC 側の設定を確認してください。

LSP コントローラのステータス

LSP のコントローラステータスは、NorthStar Controller GUI の [Network Information] テーブルの [Tunnels] タブの [ Controller Status ] 列で確認できます。

表 4 に、コントローラのさまざまなステータスとその説明を示します。

表 4:LSP コントローラのステータス

コントローラのステータス

は、

失敗 しました

NorthStar Controller は LSP のプロビジョニングに失敗しました。

ペンディング

PCS は PCEP サーバーに LSP プロビジョニング命令を送信しました。PCS は PCEP サーバからの応答を待っています。

PCC_PENDING

PCEP サーバーが PCC に LSP プロビジョニング注文を送信しました。PCS は PCC からの応答を待っています。

NETCONF_PENDING

PCS が LSP プロビジョニング注文を netconfd に送信しました。PCS は netconfd からの応答を待っています。

PRPD_PENDING

PCS は、BGP ルートをプロビジョニングするために LSP プロビジョニング注文を PRPD クライアントに送信しました。PCS は PRPD クライアントからの応答を待っています。

SCHEDULED_DELETE

PCS は LSP を削除するようにスケジュールしています。PCS は、削除プロビジョニング命令を PCC に送信します。

SCHEDULED_DISCONNECT

PCS は LSP を切断するようにスケジュールしています。LSP はシャットダウン ステータスに移行します。LSP は、Persist 状態に関連付けられた NorthStar データストアに保持され、CSPF 計算では使用されません。

NoRoute_Rescheduled

PCS は LSP のパスを見つけられていません。PCS は LSP を定期的にスキャンし、ルーティングされていない LSP のパスを見つけようとし、再プロビジョニングをスケジュールします。

FRR_DETOUR_Rescheduled

PCS は LSP を迂回し、LSP の再プロビジョニングを再スケジュールしました。

Provision_Rescheduled

PCS は、LSP がプロビジョニングされるようにスケジュールしています。

Maint_NotHandled

LSP は NorthStar によって管理されていないため、LSP は進行中のメンテナンス イベントの一部ではありません。

Maint_Rerouted

PCS はメンテナンスのため、LSP を再ルーティングしました。

Callsetup_Scheduled

PCS は、イベントの開始時に LSP をプロビジョニングする必要があります。

Disconnect_Scheduled

PCS は、イベント終了時に LSP を切断しなければなりません。

パスが見つかりません

PCS は LSP のパスを見つけることができませんでした。

ダウンした LSP で見つかったパス

PCEP サーバーは LSP がダウンしていることを報告しましたが、PCS は LSP のパスを見つけました。

パスインクルードループ

SR-LSP には 1 つ以上のループがあります。

Maint_NotReroute_DivPathUp

LSP は、スタンバイ パスがすでに稼働しているため、メンテナンス イベントによって再ルーティングされません。

Maint_NotReroute_NodeDown

メンテナンスイベントはLSPのエンドポイントに対するものであるため、LSPは再ルーティングされません。

PLANNED_LSP

LSP はプロビジョニングする必要がありますが、まだプロビジョニング キューに入っていません。

PLANNED_DISCONNECT

LSP は切断する必要がありますが、まだプロビジョニング キューに入っていません。

PLANNED_DELETE

LSP は削除する必要がありますが、まだプロビジョニング キューに入っていません。

Candidate_ReOptimization

PCS は、再最適化の候補として LSP を選択しました。

アクティブ化(used_by_primary)

LSP のセカンダリ パスがアクティブ化されます。

Time_Expired

LSP のスケジュールされたウィンドウが終了しました。

PCEP_Capability_not_supported

PCEPがデバイスでサポートされていないか、サポートされている場合でも、PCEPが設定されていないか、無効になっているか、またはデバイス上で誤って設定されている可能性があります。

非アクティブ化

NorthStar Controller によってセカンダリ LSP が非アクティブ化されました。

NS_ERR_NCC_NOT_FOUND

NorthStar Controller は、Netconf Connection Client(NCC)を使用してデバイスへの Netconf 接続を確立できません。回避策:NorthStar サーバで Netconf を再起動します。

[root@pcs-1 templates]# supervisorctl restart netconf
netconf:netconf: stopped
netconf:netconf: started

SR LSP プロビジョニングには LSP ステートフル SR 機能が必要です

SR LSPをプロビジョニングするには、CLIを使用してJunosデバイスで次のコマンドを設定する必要があります。

set protocols pcep pce <name> spring-capability

PCEPに対応していないPCC

Toposerver は、ノードを PCEP 対応にするために、TED からのトポロジ内のノードに PCEP セッションを関連付けます。このToposerver機能は、PCCがPCEPセッションを確立するために使用するIPアドレスが、ToposerverによってTEDから自動的に学習されたIPアドレスではなかった場合に妨げられます。たとえば、管理IPアドレスを使用してPCEPセッションが確立されている場合、ToposerverはTEDからそのIPアドレスを受信しません。

PCCがPCEPセッションを正常に確立すると、ToposerverにPCC_SYNC_COMPLETEメッセージを送信します。このメッセージは、同期が完了したことを NorthStar に知らせます。次に、対応する toposerver ログ エントリの例を示します。NorthStar が認識する場合と認識しない場合がある PCC_SYNC_COMPLETE メッセージと PCEP IP アドレスの両方を示しています。

認識されない IP アドレスの問題を修正するためのいくつかのオプションは次のとおりです。

  • More Options > Administration > Device Profileに移動して、NorthStar Web UIのデバイスプロファイルに認識されないIPアドレスを手動で入力します。

  • ルータから発信されるLSPが少なくとも1つあることを確認し、ToposerverがPCEPセッションをTEDデータベース内のノードに関連付けることができるようにします。

IPアドレスの問題が解決され、ToposerverがPCEPセッションをトポロジ内のノードに正常に関連付けることができるようになると、PCSログに表示されるように、PCEP IPアドレスをノード属性に追加します。

LSP が PENDING または PCC_PENDING 状態でスタック

ノードが PCEP 対応として正しく確立されたら、LSP のプロビジョニングを開始できます。Web UI ネットワーク情報テーブル(Controller Status] 列)の [Tunnels] タブに見られるように、LSP コントローラのステータスが PENDING または PCC_PENDING と表示されることがあります。このセクションでは、これらのステータスを解釈する方法について説明します。

LSP がプロビジョニングされると、PCS サーバーは LSP のすべての要件を満たすパスを計算し、プロビジョニング順序を PCEP サーバーに送信します。このプロセスの実行中は、次の例のようなログ メッセージが PCS ログに表示されます。

この時点で LSP コントローラのステータスは PENDING です。これは、プロビジョニング順序が PCEP サーバに送信されたが、確認応答がまだ受信されていないことを意味します。LSP が PENDING でスタックしている場合、問題は PCEP サーバーにあることを示唆しています。PCEPサーバにログインし、トラブルシューティングに役立つ可能性のある追加情報を提供できる詳細なログメッセージを設定できます。

また、PCEP サーバには、有用な情報を表示できるさまざまな show コマンドがあります。Junos OS構文と同様に、「 show ? 」と入力すると、 show コマンドオプションが表示されます。

PCEP サーバーは、プロビジョニング順序を正常に受信すると、次の 2 つのアクションを実行します。

  • 注文が PCC に転送されます。

  • 確認応答が PCS に返送されます。

PCEPサーバーログには、次の例のようなエントリーが表示されます。

LSP コントローラのステータスが PCC_PENDING に変わり、PCEP サーバがプロビジョニング注文を受信して PCC に転送したが、PCC がまだ応答していないことを示します。LSP が PCC_PENDING でスタックしている場合、PCC に問題があることを示唆しています。

PCC がプロビジョニング注文を正常に受信すると、PCEP サーバーに応答が送信され、PCEP サーバーは応答を PCS に転送します。PCS はこの応答を受信すると、LSP コントローラのステータスを完全にクリアし、LSP が完全にプロビジョニングされ、PCEP サーバーまたは PCC からのアクションを待機していないことを示します。その後、動作ステータス([Op Status] 列)がトンネルの状態を示すインジケータになります。

PCS ログには、次の例のようなエントリが表示されます。

アクティブでない LSP

LSP プロビジョニング順序が正常に送信されて確認され、コントローラのステータスがクリアされた場合でも、LSP が稼働していない可能性があります。LSP の動作ステータスが DOWN の場合、PCC は LSP にシグナルを送ることができません。このセクションでは、LSP の動作ステータスが DOWN になる理由として考えられるものをいくつか説明します。

使用率は、DOWN でスタックしている LSP に関連する重要な概念です。利用には 2 つのタイプがあり、それらは特定の時点で互いに異なっている可能性があります。

  • ライブ利用—このタイプは、ネットワーク内のルーターがLSPパスを通知するために使用します。この種類の利用は、NTAD を介して TED から学習されます。次の例のような PCS ログ エントリが表示される場合があります。特に、リンクのRSVP使用率をアドバタイズする予約可能な帯域幅(reservable_bw)エントリーに注意してください。

  • 計画利用率—このタイプは、NorthStar Controller 内でパス計算に使用されます。この使用率は、ルーターがLSPをアドバタイズし、LSP帯域幅とLSPが使用するパスをNorthStarに伝えるときに、PCEPから学習されます。次の例のような PCS ログ エントリが表示される場合があります。特に、リンクのRSVP使用率をアドバタイズする帯域幅(bw)およびレコードルートオブジェクト(RRO)エントリに注意してください。

2 つの利用が互いに十分に異なっていて、パスの正常な計算またはシグナリングに干渉が生じる可能性があります。たとえば、計画された使用率がライブ使用率よりも高い場合、パス計算の問題が発生し、PCS はパスの余地がないと見なしてパスを計算できません。ただし、計画された使用率は実際のライブ使用率よりも高いため、余地が十分にある可能性があります。

また、計画稼働率が稼働稼働率よりも低くなる可能性もあります。その場合、PCCはスペースがないと判断してパスをシグナリングしません。

Web UI トポロジー・マップで使用率を表示するには、「トポロジー」ビューの左ペインにある「オプション」にナビゲートします。[RSVP ライブ使用率(RSVP Live Utilization)] を選択した場合、トポロジ マップにはルータからのライブ使用率が反映されます。[RSVP 使用率(RSVP Utilization)] を選択した場合、トポロジ マップには、計画されたプロパティに基づいて NorthStar Controller によって計算された計画された使用率が反映されます。

Web UI のより優れたトラブルシューティング ツールは、[ダッシュボード(Dashboard)] ビューの [ネットワークモデル監査(Network Model Audit)] ウィジェットです。[Link RSVP Utilization] 行項目は、稼働中の使用率と計画された使用率の間に不一致があるかどうかを反映します。ある場合は、Web UI から [ Administration > System Settings] に移動し、表示されるウィンドウの右上隅にある [ Advanced Settings ] をクリックして、ネットワーク モデルの同期を実行してみてください。

手記：

右上隅のボタンは、 General Settings と Advanced Settingsの間で切り替わります。

PCS が Toposerver と同期していない

PCS が Toposerver と同期しなくなり、LSP の状態が一致しなくなった場合、同期を復元するには、PCEP プロトコルを非アクティブ化してから再アクティブ化する必要があります。NorthStar サーバーで次の手順を実行します。

注意：

以下の手順に従ってください。

  • 問題のある PCC だけでなく、すべての PCC の PCEP セッションを強制終了します。

  • その結果、すべてのユーザー データが失われ、再入力が必要になります。

  • 再同期により本番システムに影響を与えます。

  1. PCE サーバーを停止し、10 秒待ってから、PCC が残っている LSP をすべて削除できるようにします。

  2. PCE サーバを再起動します。

  3. Toposerver を再起動します。

    手記：

    Toposerverを再起動する別の方法は、NorthStar Controller Web UI(Administration > System Settings、Advanced)からネットワークモデルのリセットを実行することです。 Sync Network Model および Reset Network Model 操作の詳細については、「消える変更」セクションを参照してください。

消える変更

Web UI では、トポロジーをライブ ネットワークと同期するための 2 つのオプションを使用できます。これらのオプションにアクセスできるのはシステム管理者のみで、最初に [ Administration > System Settings] に移動し、表示されるウィンドウの右上隅にある [ Advanced Settings ] をクリックすることでアクセスできます。

手記：

右上隅のボタンは、 General Settings と Advanced Settingsの間で切り替わります。

図 6 は、表示される 2 つのオプションを示しています。

図 6: 同期操作 Synchronization Operations

Web UI で [ネットワーク モデルのリセット(Reset Network Model)] を実行すると、データベースに加えた変更が失われることに注意することが重要です。マルチユーザー環境では、1 人のユーザーが他のユーザーに気付かれることなくネットワーク モデルをリセットする可能性があります。リセットが要求されると、要求は PCS サーバーから Toposerver に送信され、PCS ログには次の内容が反映されます。

Toposerverログには、データベース要素が削除されていることが反映されます。

次に、Toposerverは、トポロジーノードとリンクを取得するためにJunos VMとの同期を要求し、LSPを取得するためにPCEPサーバーとの同期を要求します。このようにして、Toposerver はトポロジを再学習しますが、ユーザーの更新は失われます。 図 7 は、トポロジー リセット要求から Junos VM および PCEP Server との同期要求までのフローを示しています。

図 7: モデル要求Reset Model Requestのリセット

同期要求を受信すると、Junos VM と PCEP サーバーは、現在のライブ ネットワークを反映したトポロジー更新を返します。PCS ログには、データベースに追加される次の情報が表示されます。

図 8 は、Junos VM と PCEP Server から Toposerver と PCS にトポロジー更新が返される様子を示しています。

図 8: [ネットワーク モデルのリセット] を使用したモデルの更新 Model Updates Using Reset Network Model

トポロジを最初からやり直す場合は [ネットワーク モデルのリセット] を使用する必要がありますが、実際のネットワークとの同期時にユーザー計画データを失いたくない場合は、代わりに [ネットワーク モデルの同期] 操作を実行します。この操作では、PCS はトポロジ同期を要求しますが、Toposerver は既存の要素を削除しません。 図 9 は、PCS から Junos VM および PCEP サーバへのフローと、アップデートが TopoServer に返されるフローを示しています。

図 9: 同期ネットワーク モデル Synchronization Request and Model Updates Using Sync Network Modelを使用した同期要求とモデルの更新

クライアント側の問題の調査

問題の原因を探していて、システムのサーバー側で見つからない場合は、クライアント側で見つけるのに役立つデバッグフラグがあります。このフラグにより、サーバーとクライアントの間で交換された内容に関する詳細メッセージが Web ブラウザー・コンソールに表示されます。たとえば、更新が Web UI に反映されないことに気付く場合があります。これらの詳細なメッセージを使用すると、サーバーが実際に更新を送信しないなど、サーバーとクライアント間の通信ミスの可能性を特定できます。

このデバッグ フラグを有効にするには、Web UI の起動に使用する URL を次のように変更します。

手記：

すでにWeb UIを使用している場合は、ログアウトする必要はありません。URLに ?debug=true を追加して、 Enterを押すだけです。UI が再読み込みされます。

図 10 は、詳細なデバッグ メッセージを含む Web ブラウザー コンソールの例を示しています。

図 10: デバッグ メッセージを含む Web ブラウザー コンソール Web Browser Console with Debugging Messages

コンソールへのアクセスはブラウザによって異なります。 図 11 は、Google Chrome でコンソールにアクセスする例を示しています。

図11:Google ChromeコンソールAccessing the Google Chrome Consoleへのアクセス

帯域幅サイジングのスケジュールされたタスクの不完全な結果

帯域幅サイジングのスケジュールされたタスクを実行しても、帯域幅サイジングが有効なすべてのLSPの統計が発行されない場合は、スケジュールされた期間にすべての帯域幅サイジングが有効なLSPのトラフィック統計が収集されているかどうかを確認します。トラフィック統計が利用できない場合、そのLSPの帯域幅統計はサイズ変更できません。

NorthStar Collector の Web UI を使用して、トラフィック統計が収集されているかどうかを判断できます。

  1. ネットワーク情報テーブルの [トンネル] タブを開きます。

  2. サイズ変更されていない LSP を選択します。

  3. 右クリックして[ View LSP Traffic]を選択します。

  4. 左上隅の [ custom ] をクリックし、スケジュール期間を指定して、[ Submit] をクリックします。

NorthStarとHealthBotの統合のトラブルシューティング

NorthStar で HealthBot へのデバイスの更新に失敗した場合は、まず NorthStar Web アプリケーション サーバーのログにエラーがないかどうかを確認します。

HealthBot API サーバー ログには、HealthBot へのデバイスの更新に失敗した場合に役立つ情報も表示されることがあります。

RPM プローブ データと LDP デマンド統計の収集が機能しているかどうかを確認するには、IAgent コンテナー ログにアクセスします。IAgent は RPM データ(リンク遅延)に使用され、LDP は統計情報の収集を要求します。

JTI LSP およびインターフェイス統計のデータ収集が機能しているかどうかを確認するには、fluentd コンテナー ログにアクセスします。JTIデータ収集にはネイティブGBPが使用されます。

統計データが HealthBot サーバーから PCS に通知されているかどうかを確認するには、PCS ログにアクセスして、ライブの統計通知情報を確認します。

NorthStar Controllerデバッグファイルの収集

NorthStar Controllerの問題を解決できない場合は、NorthStar Controllerデバッグユーティリティで生成されたデバッグファイルをJTACに転送して評価することをお勧めします。現在、すべてのデバッグファイルは 、u/wandl/tmp ディレクトリの下のサブディレクトリにあります。

デバッグ ファイルを収集するには、NorthStar Controller CLI にログインし、 コマンド u/wandl/bin/system-diagnostic.sh filename を実行します。

出力が生成され、filename.tbz2 デバッグ ファイルの /tmp ディレクトリから利用できます。

リモート syslog

ほとんどの NorthStar プロセスは、 /etc/rsyslog.conf で定義されている rsyslog を使用します。rsyslogの使用の詳細については、Linuxシステムで実行されている特定のrsyslogバージョンの http://www.rsyslog.com/doc を参照してください。

SNMP 収集の規模を大きくする

  1. 5 分のポーリング間隔内で SNMP 収集の規模を拡大するには、以下のタスクを実行します。

    1. vi などのテキスト編集ツールを使用して、 supervisord_snmp_slave.conf ファイルを開いて編集します。

      構成ファイルが開きます。

    2. 次のコマンドを追加して、スレッドの数を 100 から 200 に増やします。

    3. 前のワーカーを複製して、ワーカー (worker3 など) を追加します。

    4. group ステートメントにワーカーを追加します。

      ベスト プラクティス:

      追加できるワーカーの数は、CPU のコア数以下である必要があります。

    5. supervisord で collector:* group を再起動します。

    6. worker1、worker2、および worker3 の supervisorctl ステータスを表示して、それらが稼働していることを確認します。

    7. 出力にいくつかの worker1 プロセスが表示され、worker2 と worker3 のそれぞれに 1 つの親プロセスのみが表示されることを確認します。

  2. スケーラビリティを高めるためにスレッド数を増やすには、次のタスクを実行します。

    1. vi などのテキスト編集ツールを使用して、 data_gateway.py ファイルを開いて編集します。

      構成ファイルが開きます。

    2. プール内のスレッド数を 10 から 20 に増やします。

    3. collector_main:data_gatewayプロセスを停止し、プロセスを再起動します。

  3. スループットを向上させてスケーラビリティを高めるには、次のタスクを実行します。

    1. vi などのテキスト編集ツールを使用して、 es_publisher.cfg ファイルを開いて編集します。

      構成ファイルが開きます。

    2. 次のパラメータを設定します。

      手記：

      1 回の操作で ElasticSearch データベース (batch_size) に送信されるレコードの最大数は 5000 ですが、SNMP 統計 (pool_size) を収集するために実行できるスレッド プール内のスレッドの最大数は 20 です。

  4. ポーリングごとにより多くのルータインタフェースからデータを収集するには、以下のタスクを実行します。

    1. NorthStar Controller GUI の [Device Profile]([Administration] > [Device Profile])ページに移動します。

    2. [デバイス リスト(Device List)] で、ルータを選択して [ 変更(Modify)] をクリックします。

      [Modify Device(s)] ページが表示されます。

    3. 「ユーザー定義プロパティー」タブの「名前」列で、プロパティーの名前を 「bulk_size」に指定します。[値] 列で、バルク サイズを 100 に設定します。

      バルクサイズは、ネットワークがポーリングされるたびに収集されるインターフェイスの数を示します。

    4. [ 変更] をクリックします。

      [Device Profile] ページにリダイレクトされ、変更が保存されたことを示す確認メッセージが表示されます。

関連資料