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は、プロセスステータステーブルに表示される各フィールドについて説明しています。

表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がトポサーバーから受信したイベントが含まれます。また、PCS の正常な起動を妨げる通信エラーや問題の通知も含まれています。

/opt/northstar/logs

toposerver.log

トポロジーサーバーに関連するログエントリー。トポロジーサーバーは、トポロジーの維持管理を担当します。これらのログには、PCSとトポサーバー、トポサーバーとNTAD、およびトポサーバーと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、IS-IS、または OSPF セッションを維持する責任があります。

空のトポロジー

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

図3:トポロジー情報フローNetwork topology diagram with Toposerver connected to Junos VM via NTAD and Junos VM connected to Router using BGP-LS, IS-IS, OSPF protocols.

トポロジーはルーターを起点としています。NorthStar Controllerがトポロジーを受信するには、ネットワーク内のルーターの1つからJunos VMへのBGP-LS、IS-IS、またはOSPFセッションが必要です。また、Junos VMとトポサーバーの間には、確立されたネットワークトポロジーアブストラクタデーモン(NTAD)セッションも必要です。

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

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

    注:

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

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

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

    topology-export ステートメントが欠落している場合、Junos VM はデータをトポサーバーにエクスポートできません。

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

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

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

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

    図4:トポロジーの初期作成Flowchart of NTAD process: Start with Send Refresh to NTAD. If NTAD link event exists, send initial topology to PCS. If not, wait 5 seconds and repeat.のロジックプロセス

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

NTADバージョン

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

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

誤ったトポロジー

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

双方向リンクの生成とメンテナンスは複雑なプロセスですが、重要なポイントをいくつか紹介します。

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

    注:

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

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

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

  • リンクがネットワークから削除されると、トポサーバーはリンク取り消しメッセージを受け取ります。

  • リンク更新とリンク撤回メッセージは、ノードの運用ステータスに影響します。

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

LSPの欠落

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

図5:LSP情報フローNetwork architecture diagram showing communication between Toposerver using AMQP, PCEP Server, and PCC using PCEP.

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

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

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

    注:

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

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

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

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

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

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

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

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

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

次のことを示します。

失敗しました

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

保留中

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

PCC_PENDING

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

NETCONF_PENDING

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

PRPD_PENDING

PCSは、BGPルートをプロビジョニングするために、BGPプロビジョニングオーダーを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接続クライアント(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 に示します。以下は、対応するトポサーバーログエントリーのサンプルであり、NorthStarが認識する場合と認識できない可能性のあるPCC_SYNC_COMPLETEメッセージとPCEP IPアドレスの両方を示しています。

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

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

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

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

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

ノードがPCEP対応として正しく確立されたら、LSPのプロビジョニングを開始できます。Web UIネットワーク情報テーブル(コントローラステータス列)のトンネルタブに表示されるように、LSPコントローラのステータスに保留中または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 Controllerは計画されたプロパティに基づいて計算します。

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

注:

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

PCS が Toposerver と同期していません

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

注意:

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

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

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

  • 再同期により、実稼働システムに影響を与えます。

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

  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でネットワークモデルのリセットを実行すると、データベースに加えた変更が失われることに注意することが重要です。マルチユーザー環境では、1 人のユーザーが他のユーザーの知らないうちにネットワーク モデルをリセットする可能性があります。リセットが要求されると、要求はPCSサーバーからトポサーバーに送信され、PCSログには以下が反映されます。

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

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

図7:モデルリクエストNetwork topology diagram showing PCS sending a topology reset request to Toposerver. Toposerver forwards REQ_TOPO_SYNC_FORCE to Junos VM and REQ_LSP_TOPO_SYNC to PCEP Server.をリセットする

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

図8は、Junos VMとPCEPサーバーからトポサーバーとPCSへのトポロジー更新の復帰を示しています。

図8:ネットワークモデルNetwork topology diagram with PCS server at top connected to Toposerver. Junos VM links via NTAD EOR. PCEP Server links via LSP_TOPO_SYNC_END identifier g043506.リセットを使用したモデル更新

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

図 9: 同期ネットワーク モデル Network topology synchronization with PCS at top sending sync request to central Toposerver. Junos VM on left sends REQ_TOPO_SYNC_FORCE. PCEP Server on right sends REQ_LSP_TOPO_SYNC and LSP_TOPO_SYNC_END. Arrows show flow of requests and responses. を使用した同期要求とモデル更新

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

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

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

注:

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

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

図10:Webブラウザコンソールとデバッグメッセージ Screenshot of browser developer tools console showing logged JavaScript objects related to network data with LSP details and action value 2.

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

図11:Google Chromeコンソールへのアクセス Web browser menu screenshot showing options like New Tab, History, Bookmarks, and expanded More Tools with Extensions and Developer Tools.

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

帯域幅サイジングスケジュールタスクを実行しても、帯域幅サイジングが有効になっているすべての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コンテナログにアクセスします。ネイティブGBPは、JTIデータ収集に使用されます。

統計データが 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. スーパーバイザーの 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でデバイスプロファイル(管理>デバイスプロファイル)ページに移動します。

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

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

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

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

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

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

関連ドキュメント