- play_arrow 概要
- play_arrow 運用、管理、および管理機能
- play_arrow ルーターのイーサネットOAMと接続障害管理
- play_arrow ルーターのリンク障害管理
- play_arrow スイッチのイーサネットOAMリンク障害管理
- play_arrow スイッチのイーサネットOAM接続障害管理
- play_arrow イーサネット フレーム遅延
- play_arrow ルーター向けイーサネット サービス OAM(ITU-TY.1731)
-
- play_arrow SNMP を使用したネットワーク監視
- SNMP アーキテクチャと SNMP MIB の概要
- Junos OSでのSNMP実装を理解する
- Junos OS で SNMP を設定する
- SNMP応答時間の向上のための管理デバイス上のオプションの構成
- SNMPカバレッジを強化するエンタープライズ固有のユーティリティMIB
- ネットワーク管理システム設定を最適化し最良の結果を生む
- SNMP 要求を受け入れるインターフェイス
- ルーティングインスタンスのSNMPを設定する
- SNMPリモート操作を設定する
- SNMPトラップ
- Junos OS でサポートされている SNMP トラップ
- SNMP アクティビティのトレース
- SNMPグループのアクセス権限
- SNMPv3でのローカルエンジンIDの設定
- SNMPv3の設定
- SNMPv3認証タイプと暗号化タイプを設定する
- SNMPv3 トラップ
- SNMPv3 インフォーム
- SNMPコミュニティ
- MIB ビュー
- Junos OSおよびJunos OS EvolvedでサポートされているSNMP MIB
- Junos OS SNMP FAQ
- play_arrow SNMPアラームとイベントによるリモートネットワーク監視(RMON)
- play_arrow アカウンティング オプション
- play_arrow 監視オプション
- play_arrow インターフェイスアラーム
- play_arrow IP 監視
- play_arrow sFlow監視技術
- play_arrow ルーターとスイッチのアダプティブ サンプリング
- play_arrow パケットフローアクセラレータ診断ソフトウェア
-
- play_arrow 一般的なセキュリティ機能の監視
- play_arrow パフォーマンス管理
- play_arrow ポート ミラーリング
- play_arrow ポートミラーリングとアナライザー
- ポートミラーリングとアナライザー
- ポートミラーリングとアナライザーの設定
- ポートミラーリングインスタンスの設定
- 物理インターフェイスでのポートミラーリングの設定
- 論理インターフェイスでのポートミラーリングの設定
- 複数の宛先に対するポートミラーリングの設定
- リモート宛先のポート ミラーリングの設定
- ポートミラーリングのローカルおよびリモート分析の設定
- 1:スイッチ上の複数の宛先へのNポートミラーリング
- 例：ファミリーanyとファイアウォールフィルターを使用したポートミラーリングの設定
- ポート ミラーリングの監視
- レイヤー3転送トラフィックのレイヤー2ヘッダーによるパケットミラーリングの設定
- ポートミラーリングのトラブルシューティング
-
- play_arrow システム ログ メッセージ
- play_arrow 設定ステートメントと運用コマンド
セキュリティデバイスのトラブルシューティング
論理システムセキュリティポリシーでの DNS 名前解決のトラブルシューティング(プライマリ管理者のみ)
問題点
説明
セキュリティポリシーで使用されているアドレス帳エントリー内のホスト名のアドレスが正しく解決されない可能性があります。
原因
通常、動的ホスト名を含むアドレス帳エントリーは、SRXシリーズファイアウォールで自動的に更新されます。DNS エントリに関連付けられた TTL フィールドは、ポリシー キャッシュでエントリを更新するまでの時間を示します。TTL値が期限切れになると、SRXシリーズファイアウォールはアドレス帳エントリーのDNSエントリーを自動的に更新します。
ただし、SRXシリーズファイアウォールがDNSサーバーから応答を取得できない場合(たとえば、DNSリクエストまたは応答パケットがネットワークで失われたり、DNSサーバーが応答を送信できない場合)、アドレス帳エントリ内のホスト名のアドレスが正しく解決されない可能性があります。これにより、セキュリティ ポリシーまたはセッションの一致が見つからないため、トラフィックがドロップする可能性があります。
ソリューション
プライマリ管理者は、 show security dns-cache コマンドを使用して、SRXシリーズファイアウォールのDNSキャッシュ情報を表示できます。DNS キャッシュ情報を更新する必要がある場合、プライマリ管理者は clear security dns-cache コマンドを使用できます。
これらのコマンドは、論理システム用に設定されたデバイスのプライマリ管理者のみが使用できます。このコマンドは、ユーザー論理システムまたは論理システム用に設定されていないデバイスでは使用できません。
関連項目
リンクサービスインターフェイスのトラブルシューティング
リンクサービスインターフェイスの設定の問題を解決するには:
- 構成要素リンクに適用されるCoSコンポーネントの決定
- マルチリンクバンドルのジッターと遅延の原因を特定する
- LFIとロードバランシングが正しく動作しているかどうかを確認する
- ジュニパーネットワークスデバイスとサードパーティデバイス間のPVCでパケットがドロップされる理由を特定する
構成要素リンクに適用されるCoSコンポーネントの決定
問題点
説明
マルチリンクバンドルを設定していますが、MLPPPカプセル化されていないトラフィックがマルチリンクバンドルの構成要素リンクを通過しています。すべてのCoSコンポーネントを構成要素リンクに適用していますか、それともマルチリンクバンドルに適用していますか?
ソリューション
スケジューラマップは、マルチリンクバンドルとその構成要素リンクに適用できます。スケジューラ マップで複数の CoS コンポーネントを適用できますが、必要なコンポーネントのみを設定します。送信の不要な遅延を避けるために、構成要素リンクの設定をシンプルに保つことをお勧めします。
表 1 は、マルチリンクバンドルとその構成要素リンクに適用されるCoSコンポーネントを示しています。
Cosコンポーネント | マルチリンクバンドル | 構成要素リンク | 説明 |
|---|---|---|---|
類別詞 | ◯ | なし | CoS分類は、送信側ではなく、インターフェイスの受信側で行われるため、構成要素リンクに分類子は必要ありません。 |
転送クラス | ◯ | なし | 転送クラスはキューに関連付けられており、キューはスケジューラ マップによってインターフェイスに適用されます。キューの割り当ては、構成要素リンク上で事前に決定されています。マルチリンクバンドルのQ2からのすべてのパケットは構成リンクのQ2に割り当てられ、他のすべてのキューからのパケットは構成リンクのQ0にキューイングされます。 |
スケジューラマップ | ◯ | ◯ | 次のように、マルチリンクバンドルと構成要素リンクにスケジューラマップを適用します。
|
ユニット単位のスケジューラまたはインターフェイスレベルのスケジューラのシェーピングレート | なし | ◯ | ユニット単位のスケジューリングはエンドポイントでのみ適用されるため、このシェーピング レートは構成要素リンクにのみ適用します。以前に適用された設定は、構成要素リンク設定で上書きされます。 |
送信レートの正確なシェーピングまたはキューレベルのシェーピング | ◯ | なし | 構成要素リンクに適用されたインターフェイスレベルのシェーピングは、キューのシェーピングよりも優先されます。したがって、マルチリンクバンドルにのみ送信レートの正確なシェーピングを適用します。 |
ルールの書き換え | ◯ | なし | フラグメンテーション中に、書き換えビットがパケットからフラグメントに自動的にコピーされます。したがって、マルチリンクバンドルで設定した内容は、フラグメント上で構成要素リンクに伝送されます。 |
仮想チャネル グループ | ◯ | なし | 仮想チャネルグループは、マルチリンクバンドルの前にのみパケットに適用されるファイアウォールフィルタールールによって識別されます。したがって、仮想チャネルグループ設定を構成要素リンクに適用する必要はありません。 |
関連項目
マルチリンクバンドルのジッターと遅延の原因を特定する
問題点
説明
ジッターと遅延をテストするには、IP パケットの 3 つのストリームを送信します。すべてのパケットのIP優先度設定は同じです。LFIとCRTPを設定した後、輻輳していないリンクでも遅延が増加しました。どうすればジッターと遅延を低減できるでしょうか。
ソリューション
ジッターと遅延を減らすには、次の手順を実行します。
各構成要素リンクでシェーピング レートが設定されていることを確認します。
リンク サービス インターフェイスでシェーピング レートが設定されていないことを確認します。
設定したシェーピング レートの値が物理インターフェイスの帯域幅と等しいことを確認します。
シェーピング レートが正しく設定されていてもジッターが続く場合は、ジュニパーネットワークス技術支援センター(JTAC)にお問い合わせください。
LFIとロードバランシングが正しく動作しているかどうかを確認する
問題点
説明
この場合、複数のサービスをサポートする単一のネットワークがあります。ネットワークは、データと遅延の影響を受けやすい音声トラフィックを送信します。MLPPP と LFI を設定した後、音声パケットがネットワーク全体に送信され、遅延やジッターがほとんどないことを確認します。音声パケットがLFIパケットとして扱われ、ロードバランシングが正しく行われているかどうかは、どうすれば確認できますか。
ソリューション
LFI が有効な場合、データ(非 LFI)パケットは MLPPP ヘッダーでカプセル化され、指定されたサイズのパケットにフラグメント化されます。遅延センシティブ音声(LFI)パケットは PPP カプセル化され、データ パケット フラグメント間でインターリーブされます。キューイングとロード バランシングは、LFI パケットと非 LFI パケットで異なる方法で実行されます。
LFI が正しく実行されたことを確認するために、パケットが設定通りにフラグメント化およびカプセル化されていることを確認します。パケットが LFI パケットとして扱われるか、非 LFI パケットとして扱われるかがわかったら、ロード バランシングが正しく実行されたかどうかを確認できます。
Solution Scenario- ジュニパーネットワークスの 2 つのデバイス、R0 と R1 が、2 つのシリアル リンク(se-1/0/0 と se-1/0/1)を集約したマルチリンク バンドル lsq-0/0/0.0で接続されているとします。R0 および R1 では、MLPPP と LFI がリンク サービス インターフェイスで有効になっており、フラグメンテーションしきい値は 128 バイトに設定されています。
この例では、パケット ジェネレーターを使用して音声ストリームとデータ ストリームを生成しました。パケット キャプチャ機能を使用して、着信インターフェイス上のパケットをキャプチャして分析できます。
次の 2 つのデータ ストリームがマルチリンク バンドルで送信されました。
200 バイトの 100 データ パケット(フラグメンテーションしきい値より大きい)
60 バイトの 500 データ パケット(フラグメンテーションしきい値より小さい)
次の 2 つの音声ストリームがマルチリンク バンドルで送信されました。
送信元ポート 100 からの 200 バイトの音声パケット 100 個
送信元ポート 200 からの 200 バイトの音声パケット 300 個
LFI とロード バランシングが正しく実行されていることを確認するには、次の手順に従います。
この例では、コマンド出力の重要な部分のみが表示され、説明されています。
パケットのフラグメント化を検証します。運用モードから
show interfaces lsq-0/0/0コマンドを入力して、ラージ パケットが正しくフラグメント化されていることを確認します。content_copy zoom_out_mapuser@R0#> show interfaces lsq-0/0/0 Physical interface: lsq-0/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 29 Link-level type: LinkService, MTU: 1504 Device flags : Present Running Interface flags: Point-To-Point SNMP-Traps Last flapped : 2006-08-01 10:45:13 PDT (2w0d 06:06 ago) Input rate : 0 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface lsq-0/0/0.0 (Index 69) (SNMP ifIndex 42) Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Multilink-PPP Bandwidth: 16mbps Statistics Frames fps Bytes bps Bundle: Fragments: Input : 0 0 0 0 Output: 1100 0 118800 0 Packets: Input : 0 0 0 0 Output: 1000 0 112000 0 ... Protocol inet, MTU: 1500 Flags: None Addresses, Flags: Is-Preferred Is-Primary Destination: 9.9.9/24, Local: 9.9.9.10Meaning—出力には、マルチリンクバンドルでデバイスを通過するパケットの概要が表示されます。マルチリンクバンドルに関する次の情報を確認します。通過パケットの総数 = 1000
トランジットフラグメントの総数 = 1100
フラグメント化されたデータ パケットの数 = 100
マルチリンクバンドルで送信されたパケットの総数(600 + 400)は、送信パケットの数(1000)と一致し、パケットがドロップされなかったことを示しています。
トランジット フラグメントの数がトランジット パケットの数を 100 上回っており、100 個のラージ データ パケットが正しくフラグメント化されたことを示しています。
Corrective Action- パケットが正しくフラグメント化されていない場合は、フラグメンテーションしきい値の設定を確認してください。指定されたフラグメンテーションしきい値より小さいパケットはフラグメント化されません。パケットのカプセル化を検証します。パケットが LFI パケットとして扱われるか、非 LFI パケットとして扱われるかを知るには、カプセル化タイプを決定します。LFI パケットは PPP カプセル化され、非 LFI パケットは PPP と MLPPP の両方でカプセル化されます。PPPカプセル化とMLPPPカプセル化ではオーバーヘッドが異なるため、パケットのサイズも異なります。パケット サイズを比較して、カプセル化タイプを決定できます。
小さなフラグメント化されていないデータ パケットには、PPP ヘッダーと 1 つの MLPPP ヘッダーが含まれています。大きなフラグメント データ パケットでは、最初のフラグメントには PPP ヘッダーと MLPPP ヘッダーが含まれていますが、連続するフラグメントには MLPPP ヘッダーのみが含まれています。
PPP および MLPPP カプセル化は、パケットに以下のバイト数を追加します。
PPP カプセル化は 7 バイトを追加します。
4 バイトのヘッダー + 2 バイトのフレーム チェック シーケンス (FCS)+ アイドル状態またはフラグを含む 1 バイト
MLPPP カプセル化により、6 から 8 バイトが追加されます。
4バイトのPPPヘッダー+2〜4バイトのマルチリンクヘッダー
図 1 は、PPP および MLPPP ヘッダーに追加されたオーバーヘッドを示しています。
図 1: PPP および MLPPP ヘッダー
CRTP パケットの場合、カプセル化のオーバーヘッドとパケット サイズは LFI パケットの場合よりもさらに小さくなります。詳細については、「 例: 圧縮リアルタイムトランスポートプロトコルの設定.
表 2 は、それぞれ 70 バイトのデータ パケットと音声パケットのカプセル化オーバーヘッドを示しています。カプセル化後、データ パケットのサイズは音声パケットのサイズよりも大きくなります。
表 2: PPPおよびMLPPPカプセル化オーバーヘッド パケット タイプ
カプセル化
初期パケット サイズ
カプセル化オーバーヘッド
カプセル化後のパケット サイズ
音声パケット(LFI)
PPP
70 バイト
4 + 2 + 1 = 7 バイト
77 バイト
短いシーケンスのデータフラグメント(非LFI)
ティッカー
70 バイト
4 + 2 + 1 + 4 + 2 = 13 バイト
83 バイト
長いシーケンスを持つデータフラグメント(非LFI)
ティッカー
70 バイト
4 + 2 + 1 + 4 + 4 = 15 バイト
85 バイト
運用モードから、
show interfaces queueコマンドを入力して、各キューの送信パケットのサイズを表示します。送信されたバイト数をパケット数で割ってパケットのサイズを取得し、カプセル化タイプを決定します。ロードバランシングを検証します。運用モードから、マルチリンクバンドルとその構成要素リンクに
show interfaces queueコマンドを入力し、パケットに対してそれに応じてロードバランシングが行われているかどうかを確認します。content_copy zoom_out_mapuser@R0> show interfaces queue lsq-0/0/0 Physical interface: lsq-0/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 29 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 600 0 pps Bytes : 44800 0 bps Transmitted: Packets : 600 0 pps Bytes : 44800 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps … Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 400 0 pps Bytes : 61344 0 bps Transmitted: Packets : 400 0 pps Bytes : 61344 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 0 0 pps Bytes : 0 0 bps …content_copy zoom_out_mapuser@R0> show interfaces queue se-1/0/0 Physical interface: se-1/0/0, Enabled, Physical link is Up Interface index: 141, SNMP ifIndex: 35 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 350 0 pps Bytes : 24350 0 bps Transmitted: Packets : 350 0 pps Bytes : 24350 0 bps ... Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 100 0 pps Bytes : 15272 0 bps Transmitted: Packets : 100 0 pps Bytes : 15272 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 19 0 pps Bytes : 247 0 bps Transmitted: Packets : 19 0 pps Bytes : 247 0 bps …content_copy zoom_out_mapuser@R0> show interfaces queue se-1/0/1 Physical interface: se-1/0/1, Enabled, Physical link is Up Interface index: 142, SNMP ifIndex: 38 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 350 0 pps Bytes : 24350 0 bps Transmitted: Packets : 350 0 pps Bytes : 24350 0 bps … Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 300 0 pps Bytes : 45672 0 bps Transmitted: Packets : 300 0 pps Bytes : 45672 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 18 0 pps Bytes : 234 0 bps Transmitted: Packets : 18 0 pps Bytes : 234 0 bpsMeaning—これらのコマンドの出力は、リンク サービス インターフェイスとその構成リンクの各キューで送信され、キューイングされたパケットを示しています。 表 3 に、これらの値の概要を示します。(送信されたパケット数はすべてのリンクでキューに入れられたパケットの数と等しいため、この表にはキューに入れられたパケットのみが表示されます)。表 3: - キューで送信されたパケット数 キューに入れられたパケット
バンドル lsq-0/0/0.0
構成要素リンク se-1/0/0
構成要素リンク se-1/0/1
説明
Q0 のパケット
600
350
350
構成リンクを通過するパケットの総数(350+350 = 700)が、マルチリンクバンドルでキューイングされたパケット数(600)を超えました。
Q2のパケット
400
100
300
構成要素リンクを通過するパケットの総数は、バンドル上のパケット数と等しくなりました。
第3四半期のパケット
0
19
18
構成リンクの Q3 を通過するパケットは、構成リンク間で交換されるキープアライブ メッセージ用です。したがって、バンドルのQ3ではパケットはカウントされませんでした。
マルチリンクバンドルで、次のことを確認します。
キューに入れられたパケットの数は、送信された数と一致します。番号が一致する場合、パケットはドロップされませんでした。キューに入れられたパケットの数が送信された数よりも多い場合、バッファが小さすぎるため、パケットはドロップされました。構成要素リンクのバッファサイズは、出力段での輻輳を制御します。この問題を修正するには、構成リンクのバッファー サイズを増やします。
Q0(600)を通過するパケット数は、マルチリンクバンドルで受信した大小のデータパケットの数(100+500)と一致します。数値が一致する場合、すべてのデータ パケットは Q0 を正しく通過しています。
マルチリンクバンドルでQ2を通過するパケット数(400)は、マルチリンクバンドルで受信した音声パケットの数と一致します。番号が一致する場合、すべての音声LFIパケットはQ2を正しく通過しています。
構成要素リンクで、次のことを確認します。
Q0(350+350)を通過するパケットの総数は、データパケットとデータフラグメント(500+200)の数と一致します。番号が一致する場合、フラグメンテーション後のすべてのデータパケットは、構成リンクのQ0を正しく通過しました。
パケットは両方の構成リンクを通過しており、LFI以外のパケットでロードバランシングが正しく実行されたことを示しています。
構成要素リンク上でQ2(300+100)を通過するパケットの総数は、マルチリンクバンドル上で受信した音声パケットの数(400)と一致します。番号が一致する場合、すべての音声LFIパケットはQ2を正しく通過しています。
送信元ポート
100からの LFI パケットはse-1/0/0を通過し、送信元ポート200からの LFI パケットはse-1/0/1を通過しました。したがって、すべてのLFI(Q2)パケットは送信元ポートに基づいてハッシュされ、両方の構成リンクを正しく通過しました。
Corrective Action- パケットが 1 つのリンクのみを通過した場合は、次の手順で問題を解決します。物理リンクが
up(動作可能)か、down(使用不可)かを判断します。使用できないリンクは、PIM、インターフェイス ポート、または物理接続の問題(リンク層エラー)を示します。リンクが動作している場合は、次の手順に進みます。分類子が非LFIパケットに対して正しく定義されているか検証します。非LFIパケットがQ2にキューイングされるように設定されていないことを確認します。Q2 にキューイングされたパケットはすべて LFI パケットとして扱われます。
LFI パケット内で、以下の値の少なくとも 1 つが異なることを確認します。送信元アドレス、宛先アドレス、IP プロトコル、送信元ポート、または宛先ポート。すべての LFI パケットに同じ値が設定されている場合、パケットはすべて同じフローにハッシュされ、同じリンクを通過します。
結果を使用して負荷分散を検証します。
ジュニパーネットワークスデバイスとサードパーティデバイス間のPVCでパケットがドロップされる理由を特定する
問題点
説明
ジュニパーネットワークスのデバイスとサードパーティ製デバイスでT1、E1、T3、またはE3インターフェイス間のPVC(恒久仮想回線)を設定しようとしていますが、パケットが破棄され、pingに失敗します。
ソリューション
サードパーティ製デバイスがジュニパーネットワークスのデバイスと同じ FRF.12 をサポートしていない場合、または別の方法で FRF.12 をサポートしていない場合、PVC 上のジュニパーネットワークスのデバイス インターフェイスは、FRF.12 ヘッダーを含むフラグメント パケットを破棄し、「ポリシングされた破棄」としてカウントすることがあります。
回避策として、両方のピアにマルチリンクバンドルを設定し、マルチリンクバンドルにフラグメンテーションしきい値を設定します。
セキュリティポリシーのトラブルシューティング
ルーティングエンジンとパケット転送エンジン間のポリシーの同期
問題点
説明
セキュリティ ポリシーは、ルーティング エンジンとパケット転送エンジンに保存されます。セキュリティポリシーは、設定をコミットする際にルーティングエンジンからパケット転送エンジンにプッシュされます。ルーティング エンジンのセキュリティ ポリシーがパケット転送エンジンと同期していない場合、設定のコミットは失敗します。コア ダンプ ファイルは、コミットが繰り返し試行された場合に生成される場合があります。非同期は、次の原因で発生する可能性があります。
ルーティング エンジンからパケット転送エンジンへのポリシー メッセージは、転送中に失われます。
ルーティング エンジンのエラー(ポリシー UID の再利用など)。
環境
ルーティングエンジンとパケット転送エンジンのポリシーは、コンフィギュレーションをコミットするために同期している必要があります。ただし、特定の状況下では、ルーティング エンジンとパケット転送エンジンのポリシーが同期しなくなり、コミットが失敗することがあります。
症状
ポリシー構成が変更され、ポリシーが同期していない場合、次のエラーメッセージが表示されます。 error: Warning: policy might be out of sync between RE and PFE <SPU-name(s)> Please request security policies check/resync.
ソリューション
セキュリティ ポリシーが同期していない場合は、 show security policies checksum コマンドを使用してセキュリティ ポリシーのチェックサム値を表示し、 request security policies resync コマンドを使用してルーティング エンジンとパケット転送エンジンのセキュリティ ポリシーの設定を同期します。
関連項目
セキュリティ ポリシーのコミット失敗の確認
セキュリティ ポリシーのコミットの検証
問題点
説明
ポリシー構成のコミットの実行時に、システムの動作が正しくないことに気付いた場合は、次の手順を使用してこの問題のトラブルシューティングを行います。
ソリューション
動作 show コマンド:セキュリティポリシーの操作コマンドを実行し、出力に表示される情報が期待したものと一致していることを確認します。そうでない場合は、構成を適切に変更する必要があります。
traceoptions - ポリシー設定で
traceoptionsコマンドを設定します。この階層の下にあるフラグは、showコマンド出力のユーザー分析に従って選択できます。使用するフラグを決定できない場合は、フラグ オプションallを使用してすべてのトレース ログをキャプチャできます。content_copy zoom_out_mapuser@host#
set security policies traceoptions <flag all>
また、ログをキャプチャするために、オプションのファイル名を設定することもできます。
user@host# set security policies traceoptions <filename>
trace オプションでファイル名を指定した場合は、/var/log/<filename> でログファイルを検索し、ファイルにエラーが報告されていないかどうかを確認できます。(ファイル名を指定しなかった場合、デフォルトのファイル名がイベントされます。)エラー メッセージには、障害の場所と適切な理由が示されます。
トレース・オプションを設定した後、誤ったシステム動作の原因となった設定変更を再コミットする必要があります。
