Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの目次
 

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

このドキュメントには、明らかな問題がNorthStarコントローラまたはルータに起因するものかどうかを判断するための戦略が含まれており、NorthStarコントローラに起因すると識別された問題のトラブルシューティング手法を提供します。

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

「実行中」ではなく「停止済み」と表示されているプロセスを再起動します。

メモ：

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

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

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

メモ：

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

表 1 に、「プロセス状況」テーブルに表示される各フィールドを示します。

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

プロセス

NorthStar Controller プロセスの名前。

Pid

プロセス ID 番号。

ユーザー

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

グループ

このプロセスに関する情報にアクセスするには、NorthStar Controllerユーザーグループの権限が必要です。

CPU%

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

メモリ

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

仮想メモリ

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

CPU 時間

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

Cmd

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

トラブルシューティング情報は、次のセクションで説明します。

NorthStar コントローラのログ ファイル

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

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

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

    NorthStar システムのログおよびメッセージ・ファイルのリストが表示されます。その切り捨てられた例を 図 2 に示します。

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

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

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

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

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

表 2 に、PCS および PCE の問題の特定とトラブルシューティングに最もよく使用される NorthStar Controller ログ ファイルを示します。

表 2: 上位 NorthStar コントローラのトラブルシューティング ログ ファイル

ログ ファイル

説明

場所

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

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

/opt/northstar/logs

toposerver.log

トポロジー・サーバーに関連したログ項目。トポロジー・サーバーは、トポロジーの保守を担当します。これらのログには、PCS とトポサーバー、トポサーバーと NTAD、およびトポサーバーと PCE サーバー間のイベントのレコードが含まれています

/opt/northstar/logs

表 3 に、トラブルシューティングに役立つその他のログ ファイルを示します。 表 3 のすべてのログ・ファイルは、 /opt/northstar/logs ディレクトリーの下にあります。

表 3: NorthStar コントローラのトラブルシューティング用の追加ログ ファイル
ログ ファイル 説明

cassandra.msg

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

ha_agent.msg

HA コーディネーター ログ

mlAdaptor.log

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

net_setup.log

構成スクリプト ログ。

nodejs.msg

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

pcep_server.log

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

pcs.log

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

rest_api.log

REST API リクエストのログファイル。

toposerver.log

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

PC とトポロジー・サーバー、トポロジー・サーバーと NTAD、およびトポロジー・サーバーと PCE サーバー間のイベントのレコードが含まれます。

メモ：

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

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

空のトポロジ

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

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

トポロジーはルーターから始まります。NorthStar Controllerがトポロジーを受信するには、ネットワーク内のルーターの1つからJunos VMへのBGP-LS、ISIS、またはOSPFセッションが必要です。また、Junos VMとToposerverの間には、確立されたネットワークトポロジー抽象デーモン(NTAD)セッションが必要です。

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

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

    メモ：

    ポート450は、Junos VMからトポサーバーへの接続に使用されるポートです。

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

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

    topology-exportステートメントが指定されていない場合、Junos VM はデータをトポサーバーにエクスポートできません。

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

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

    lsdist.0のルーティングテーブルにゼロしか表示されない場合、送信できるトポロジーはありません。トポロジー取得の設定に関する 『NorthStar Controllerスタートアップガイド 』セクションを参照してください。

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

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

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

NTADバージョン

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

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

不正なトポロジー

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

双方向リンクの生成と維持は複雑なプロセスですが、以下の重要なポイントをご紹介します。

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

    メモ：

    ノード ID は、トポサーバーが最初に NTAD からノード イベントを受信するときに割り当てられます。

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

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

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

  • リンク更新およびリンク取り消しメッセージは、ノードの運用状況に影響を与えます。

  • ノードの運用ステータスとプロトコル(IGP 対 IGP と MPLS)によって、リンクを使用して LSP をルーティングできるかどうかが決まります。リンクを使用してLSPをルーティングするには、動作ステータスUPとMPLSプロトコルの両方がアクティブである必要があります。

LSPの欠落

トポロジーが正しく表示されているにもかかわらずLSPが欠落している場合は、 図5に示すように、PCCからトポサーバーへの情報フローを確認します。その結果、NorthStar Controller UIにトンネルが追加されています。フローは PCC での設定から始まり、LSP アップデート メッセージが PCEP セッションを介して PCEP サーバに渡され、次に AMQP(アドバンスト メッセージ キューイング プロトコル)接続を介してトポサーバに渡されます。

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

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

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

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

    メモ：

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

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

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

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

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

LSP Controller Status のコントローラステータスは、(NorthStar コントローラ GUI の)ネットワーク情報テーブル の トンネル タブの 列で確認できます。

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

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

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

は、

失敗 しました

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

保留 中

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

PCC_PENDING

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

NETCONF_PENDING

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

PRPD_PENDING

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

SCHEDULED_DELETE

PCS は LSP の削除をスケジュールしました。PCS は削除プロビジョニング順序を PCC に送信します。

SCHEDULED_DISCONNECT

PCS は LSP を切断するようにスケジュールしました。LSP はシャットダウン ステータスに移行します。LSP は、永続状態が関連付けられた 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 コントローラは、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

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

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

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

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

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

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

LSP が保留中またはPCC_PENDING状態でスタックしている

ノードがPCEP対応として正しく確立されると、LSPのプロビジョニングを開始できます。LSP コントローラのステータスは、Web UI ネットワーク情報テーブル(コントローラのステータス列)の トンネル タブに表示されるように、保留中または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 からのアクションを待機していないことを示します。その後、動作ステータス([運用ステータス]列)がトンネルの状態を示すインジケータになります。

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使用率を選択した場合、トポロジマップには、計画されたプロパティに基づいてNorthStarコントローラによって計算される計画された使用率が反映されます。

Web UI のより優れたトラブルシューティング ツールは、[ダッシュボード] ビューの [ネットワーク モデル監査] ウィジェットです。[RSVP 使用率のリンク] 行項目は、ライブ使用率と計画使用率の間に不一致があるかどうかを反映します。存在する場合は、Web UI から [ネットワーク モデルの同期] を実行して Administration 、> System Settingsに移動し、結果のウィンドウの右上隅をクリックして Advanced Settings みることができます。

メモ：

右上隅のボタンが と Advanced Settingsを切り替えますGeneral Settings。

PCS がトポサーバーと同期していない

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

注意：

次の手順に従うことに注意してください。

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

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

  • 再同期により本番システムに影響する。

  1. PCE サーバーを停止し、PCC が残留 LSP をすべて削除するまで 10 秒間待ちます。

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

  3. トポサーバーを再起動します。

    メモ：

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

消える変化

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

メモ：

右上隅のボタンが と Advanced Settingsを切り替えますGeneral Settings。

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

図 6: 同期操作 Synchronization Operations

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

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

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

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

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

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

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

トポロジを最初からやり直す場合は [ネットワーク モデルのリセット] を使用する必要がありますが、稼働中のネットワークと同期するときにユーザー プランニング データを失いたくない場合は、代わりに [ネットワーク モデルの同期] 操作を実行します。この操作では、PCS は引き続きトポロジ同期を要求しますが、Toposerver は既存の要素を削除しません。 図 9 は、PC から 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 Browser Console with Debugging Messagesを含む Web ブラウザー コンソール

コンソールへのアクセスはブラウザによって異なります。 図 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 サーバから PC に通知されているかどうかを判断するには、PCS ログにアクセスしてライブ統計通知情報を確認します。

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

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

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

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

リモート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. グループステートメントにワーカーを追加します。

      ベスト プラクティス:

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

    5. スーパーバイザーで を再起動します collector:* group 。

    6. ワーカー 1、ワーカー 2、およびワーカー 3 のスーパーバイザーの状態を表示して、それらが稼働していることを確認します。

    7. 出力にいくつかの worker 1 プロセスが表示され、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のデバイスプロファイル(デバイスプロファイル>管理)ページに移動します。

    2. デバイスリストで、ルーターを選択し、 変更 をクリックします。

      [デバイスの変更] ページが表示されます。

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

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

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

      [デバイス プロファイル(Device Profile)] ページにリダイレクトされ、変更が保存されたことを示す確認メッセージが表示されます。

関連ドキュメント