BGP セッションのトラブルシューティング
BGP プロトコルとピアを検証するためのチェックリスト
目的
表 1 は、ネットワーク内の Juniper Networks ルーターで BGP（Border Gateway Protocol）が正しく設定されているか、内部 BGP（Border Gateway Protocol）と外部 BGP（Border Gateway Protocol）セッションが正しく確立されているか、外部ルートが正しく広告および受信されているか、BGP パス選択プロセスが正しく機能しているかを確認するためのリンクとコマンドを提供します。
アクション
タスク |
コマンドまたはアクション |
|---|---|
| BGP ピアの検証 | |
|
|
|
|
|
|
|
|
| BGP ルートとルート選択を調べる | |
|
|
|
|
|
|
|
|
| フォワーディング テーブルのルートを調べる |
|
BGP ピアの検証
目的
すべてのルーターが BGP 用に正しく設定されていると仮定すれば、IBGP および EBGP セッションが正しく確立されているか、外部ルートが正しく告知および受信されているか、BGP パス選択プロセスが正しく機能しているかを確認することができます。
図 1は、このトピックで使用する BGP ネットワークトポロジーの例を示しています。
ネットワークは、外部と内部のピアで構成される 2 つの直接接続された AS で構成されています。外部ピアは、共有インターフェイスを通じて直接接続され、EBGP を実行します。内部ピアは、IBGP を通じて、ループバック（lo0）インターフェイスを介して接続されます。AS 65001 は OSPFを、AS 65002 は IS-IS を、基本的な IGP として実行しています。IBGP ルーターは直接接続されている必要はなく、基盤となる IGP によってネイバー同士が到達できるようになっています。
AS 65001 の 2 つのルーターは、それぞれ AS 65002 への 1 つの EBGP リンク（R2とR4）を持ち、その上で集約されたプレフィックスをアナウンスしています。100.100.1.0、 100.100.2.0、 100.100.3.0、および 100.100.4.0。また、R1およびR5は、一部のルートに対して、それぞれ 5 と 10 の複数の出口識別子（MED）値を注入しています。
両方の AS の内部ルーターは、フルメッシュ の IBGP トポロジーを使用しています。ネットワークがコンフェデレーションやルートリフレクターを使用していないため、フルメッシュが必要となります。そのため、IBGP を介して学習したルートは、他の内部ネイバーには配布されません。例えば、R3がR2からルートを学習した場合は、 R3 は、そのルートを R6 に配信しません。ルートは IBGP 経由で学習されるため、R6 がルートを学習するには、 R2に直接 BGP 接続する必要があります。
完全メッシュ・トポロジーでは、外部の BGP 情報を受信したボーダルーターのみが、その情報を AS 内の他のルーターに配信します。受信側のルーターは、その情報を自分の AS 内の他の IBGP ルーターに再配布しません。
AS 65002 の見方では、以下のセッションをアップする必要があります:
AS 65002の 4 台のルーターは、お互いに IBGP セッションを確立している必要があります。
R2はR1と EBGP セッションを確立しているはずです。R4はR5と EBGP セッションを確立しているはずです。
BGP ピアを検証するには、以下の手順に従います：
内部ルータで BGP を検証する
目的
内部ルーターの BGP 構成を確認します。
アクション
内部ルーターの BGP 構成を確認するには、次の Junos OS コマンドライン インターフェイス (CLI) コマンドを入力します。
user@host> show configuration
以下のサンプル出力は、R3のBGP設定用です。
出力例
コマンド名
user@R3> show configuration
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.1.23.2/30;
}
family iso;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.36.1/30;
}
family iso;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.3/32;
}
family iso {
address 49.0002.1000.0000.0003.00;
}
}
}
}
routing-options {
[...Output truncated...]
router-id 10.0.0.3;
autonomous-system 65002;
}
protocols {
bgp {
group internal {
type internal;
local-address 10.0.0.3;
neighbor 10.0.0.2;
neighbor 10.0.0.4;
neighbor 10.0.0.6;
}
}
isis {
level 1 disable;
interface all {
level 2 metric 10;
}
interface lo0.0;
}
}
user@R6> show configuration |
[Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.1.46.2/30;
}
family iso;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.36.2/30;
}
family iso;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.6/32;
}
family iso {
address 49.0003.1000.0000.0006.00;
}
}
}
}
routing-options {
[Output truncated...]
router-id 10.0.0.6;
autonomous-system 65002;
}
protocols {
bgp {
group internal {
type internal;
local-address 10.0.0.6;
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
}
}
isis {
level 1 disable;
interface all {
level 2 metric 10;
}
interface lo0.0;
}
}
意味
サンプル出力は、ルーター R3 および R6 での基本的な BGP 設定を示しています。ローカルAS(65002)と1つのグループ(internal)が両方のルーターに設定されています。 R3 には、[protocols bgp group group] 階層レベルに含まれる 3 つの内部ピア(10.0.0.2、10.0.0.4、および 10.0.0.6)があります。 R6 には、次の 3 つの内部ピアもあります。10.0.0.2、10.0.0.3、および10.0.0.4。基盤となる IGP プロトコルは IS-IS(中間システム - 中間システム)であり、関連するインターフェイスは IS-IS を実行するように設定されています。
この設定では、ルータIDの重複の問題を回避するために、ルータIDが手動で設定されていることに注意してください。
ボーダールータで BGP を検証する
目的
境界ルーターの BGP 構成を検証するには。
アクション
境界ルーターの BGP 構成を検証するには、次の Junos OS CLI 運用モード コマンドを入力します。
user@host> show configuration
サンプル出力
コマンド名
次のサンプル出力は、AS 65002からの2つの境界ルーターR2とR4上のBGP設定を対象としています。
user@R2> show configuration
[...Output truncated...]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.1.12.2/30;
}
family iso;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.23.1/30;
}
family iso;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.24.1/30;
}
family iso;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.2/32;
}
family iso {
address 49.0002.1000.0000.0002.00;
}
}
}
}
routing-options {
[...Output truncated...]
router-id 10.0.0.2;
autonomous-system 65002;
}
protocols {
bgp {
group internal {
type internal;
export next-hop-self;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
neighbor 10.0.0.6;
}
group toR1 {
type external;
import import-toR1;
peer-as 65001;
neighbor 10.1.12.1;
}
}
isis {
level 1 disable;
interface all {
level 2 metric 10;
}
interface lo0.0;
}
}
policy-options {
policy-statement next-hop-self {
term change-next-hop {
from neighbor 10.1.12.1;
then {
next-hop self;
}
}
}
policy-statement import-toR1 {
term 1 {
from {
route-filter 100.100.1.0/24 exact;
}
then {
local-preference 200;
}
}
}
user@R4> show configuration
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.1.46.1/30;
}
family iso;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.1.45.1/30;
}
family iso;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.24.2/30;
}
family iso;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.4/32;
}
family iso {
address 49.0001.1000.0000.0004.00;
}
}
}
}
routing-options {
[...Output truncated...]
router-id 10.0.0.4;
autonomous-system 65002;
}
protocols {
bgp {
group internal {
type internal;
local-address 10.0.0.4;
export next-hop-self;
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.6;
}
group toR5 {
type external;
peer-as 65001;
neighbor 10.1.45.2;
}
}
isis {
level 1 disable;
interface all {
level 2 metric 10;
}
interface lo0.0;
}
}
policy-options {
policy-statement next-hop-self {
term change-next-hop {
from neighbor 10.1.45.2;
then {
next-hop self;
}
}
}
意味
サンプル出力は、境界ルーター R2 および R4 での基本的な BGP 構成を示しています。どちらのルーターにも、[routing-options]階層レベルにAS(65002)が含まれています。各ルーターには、[protocols bgp group group] 階層レベルに含まれる 2 つのグループがあります。外部ピアは、ルーターに応じて、 toR1 または toR5のいずれかの外部グループに含まれます。内部ピアは internal グループに含まれます。基盤となる IGP プロトコルは、両方のルーターで IS-IS であり、関連するインターフェイスは IS-IS を実行するように設定されています。
両方のルーターの設定では、重複したルーターIDの問題を回避するためにルーターIDが手動で設定されており、BGPネクストホップ到達可能性の問題を回避するために next-hop-self ステートメントが含まれていることに注意してください。
広告された BGP ルートの検証
目的
設定した特定のルートがネイバーにアドバタイズされているかどうかを判断できます。
アクション
指定された BGP ネイバーへのアドバタイズ用に準備されたルーティング情報を確認するには、次の Junos OS CLI 運用モード コマンドを入力します。
user@host> show route advertising-protocol bgp neighbor-address
出力例
コマンド名
user@R2> show route advertising-protocol bgp 10.0.0.4\ inet.0: 20 destinations, 22 routes (20 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 100.100.1.0/24 Self 5 200 65001 I * 100.100.2.0/24 Self 5 100 65001 I * 100.100.3.0/24 Self 100 65001 I * 100.100.4.0/24 Self 100 65001 I
意味
サンプル出力は、 R2 からネイバーの 10.0.0.4 (R4)にアドバタイズされたBGPルートを示しています。inet.0 routing テーブルにある合計 22 のルートのうち、20 がアクティブな宛先です。hiddenルートまたはhold-down状態にあるルートはありません。ルートは、アクティブと宣言される前の hold-down ステートに存在し、ルーティング ポリシーによって拒否されたルートは hidden ステートにすることができます。表示される情報には、ルーティング テーブルが BGP ルーティング プロトコルにエクスポートしたルートが反映されます。
ルータで特定の BGP ルートを受信していることを確認する
目的
特定のBGPネイバーを介して受信され、ローカルルーターからネイバーにアドバタイズされたルーティング情報を表示します。
アクション
ルータで特定の BGP ルートを受信したことを確認するには、次の Junos OS CLI 運用モード コマンドを入力します。
user@host> show route receive-protocol bgp neighbor-address
出力例
コマンド名
user@R6> show route receive-protocol bgp 10.0.0.2 inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 100.100.1.0/24 10.0.0.2 5 200 65001 I * 100.100.2.0/24 10.0.0.2 5 100 65001 I 100.100.3.0/24 10.0.0.2 100 65001 I 100.100.4.0/24 10.0.0.2 100 65001 I iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) user@R6> show route receive-protocol bgp 10.0.0.4 inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 100.100.3.0/24 10.0.0.4 100 65001 I * 100.100.4.0/24 10.0.0.4 100 65001 I iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
意味
サンプル出力では、 R2 からの 4 つの BGP ルートと、 R4からの 2 つの BGP ルートが表示されています。R2からの4つのルートのうち、アスタリスク(*)で示されるように、ルーティングテーブルでアクティブになっているのは2つだけで、R4から受信した両方のルートがルーティングテーブルでアクティブです。すべてのBGPルートはAS 65001を経由してきました。
BGPルートとルート選択を調べる
目的
BGPが同じ宛先プレフィックスに複数のルートを受信した場合、BGPパス選択プロセスを調べて、単一のアクティブなパスを決定できます。
このネットワークで示図 2しているはR1、同じ宛先プレフィックスへの2つのルートとを受R4信し、その結果に対して同じ集約ルートR2とを通R5知R2し送信R4,します。R2とR4 のルート選択プロセスは、受信した2つのBGPルートのどちらがアクティブかを判別して、他の内部ルーターにアドバタイズされます。（R3とR6）
ルーターがBGPルートをインストールする前に、BGP属next-hop 性に到達可能か確認する必要があります。BGPネクストホップが解決できない場合、ルートはインストールされません。BGPルートがルーティング テーブルにインストールされている場合、複数のルートが同じ宛先プレフィックスに存在する場合は、パス選択プロセスを実行する必要があります。BGP パス選択プロセスは、以下の順で実行されます。
ルーティングテーブルのルート優先度が比較されます。例えば、OSPFとBGPルートが特定の宛先に対して存在する場合、OSPFルートはアクティブルートとして選択されます。これは、OSPFルートのデフォルト優先度値が110であり、BGPルートのデフォルト優先度値が170であるためです。
ルートは、ローカルプリファレンス値で比較されます。ローカルプリファレンス値が最も高いルートが優先されます。例として、ローカルプリファレンスの選択を確認するを参照してください。
ASパス属性が、評価されます。より短いASパスが優先されます。
起点コードが評価されます。
I (IGP) < E (EGP) < ? (Incomplete)最も低い起点コード（）が優先されます。MED値が評価されます。デフォルトでは、いずれかのルートが同じネイバーASからアドバタイズされる場合、最小のMED値が優先されます。MED値がない場合は、MEDが0と解釈されます。例として、マルチ出口識別子ルートの選択を確認するを参照してください。
ルートは、EBGPまたはIBGPを介して学習されたかどうかが評価されます。EBGPが学習したルートは、IBGPが学習したルートよりも優先されます。例として、EBGP over IBGPの選択を確認するを参照してください
ルートがIBGPから学習された場合、IGPコストが最も低いルートが優先されます。例として、IGPコストの選択を確認するを参照してください。IBGPピアへの物理ネクストホップは、以下の3つのルールに従ってインストールされます：
BGPがとのルー
inet.3ティングテーブルinet.0を確認した後、最も低いルートの物理ネクストホップが優先されます。
inet.0とinet.3のルーティングテーブルの優先値が同じ場合、ルーティングテーブルinet.3のルートの物理ネクストホップが使用されます。
同じルーティングテーブルに優先値が同じものが存在する場合、より多くのパスを持つルートの物理ネクストホップがインストールされます。
ルートリフレクションのクラスタリスト属性が評価されます。最短の長さのクラスタリストが優先されます。クラスタリストがないルートは、クラスタリストの長さが0と見なされます。
ルーターIDが評価されます。ルーターIDが最も低いピアからのルート（通常はループバックアドレス）が優先されます。
ピアアドレス値が調べられます。最も低いピアIPアドレスのピアが優先されます。
BGPが同じ宛先プレフィックスに複数のルートを受信した場合の、単一のアクティブなパスを決定するには、以下のJunos OS CLIの運用モードコマンドを入力します：
user@host> show route destination-prefix < detail >
以下の手順は、BGPが同じ宛先プレフィックスに複数のルートを受信した場合、1つのルートが、シングル、アクティブなパスとして選択される場合に表示される非アクティブな理由を示しています：
ローカル プリファレンス セレクションを検証する
目的
ルートを調べて、ローカルプリファレンスが単一のアクティブなパスの選択基準であるかどうかを判断すること。
アクション
ルートを調べて、ローカルプリファレンスが単一のアクティブなパスの選択基準であるかどうかを判断するには、次のJunos OS CLI操作モードコマンドを入力します。
user@host> show route destination-prefix < detail >
出力例
コマンド名
user@R4> show route 100.100.1.0 detail
inet.0: 20 destinations, 24 routes (20 active, 0 holddown, 0 hidden)
100.100.1.0/24 (2 entries, 1 announced)
*BGP Preference: 170/-201
Source: 10.0.0.2
Next hop: 10.1.24.1 via so-0/0/3.0, selected
Protocol next hop: 10.0.0.2 Indirect next hop: 8644000 277
State: <Active Int Ext>
Local AS: 65002 Peer AS: 65002
Age: 2:22:34 Metric: 5 Metric2: 10
Task: BGP_65002.10.0.0.2+179
Announcement bits (3): 0-KRT 3-BGP.0.0.0.0+179 4-Resolve inet.0
AS path: 65001 I
Localpref: 200
Router ID: 10.0.0.2
BGP Preference: 170/-101
Source: 10.1.45.2
Next hop: 10.1.45.2 via so-0/0/2.0, selected
State: <Ext>
Inactive reason: Local Preference
Local AS: 65002 Peer AS: 65001
Age: 2w0d 1:28:31 Metric: 10
Task: BGP_65001.10.1.45.2+179
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.5
意味
サンプル出力は、 R4 が 100.100.1.0 route の 2 つのインスタンスを受信したことを示しています。1つは 10.0.0.2 (R2)から、もう1つは 10.1.45.2 (R5)から。 R4 、アスタリスク(*)で示されるように、アクティブなパスとして R2 からのパスを選択しました。選択は、 Localpref フィールドに含まれるローカルプリファレンス値に基づきます。ローカルプリファレンス値が 最も高い パスが優先されます。この例では、ローカルプリファレンス値が高いパスは、 R2、200からのパスです。
R5からのルートが選択されていない理由は、[Inactive reason] フィールド (この場合は Local Preference) にあります。
2 つのパスは、同じ隣接ネットワークからのものであることに注意してください。AS 65001として。
複数出口の識別ルート選択を検討する
目的
ルートを調べて、MEDが単一のアクティブなパスの選択基準であるかどうかを判断すること。
アクション
ルートを調べて、MEDがシングルでアクティブなパスの選択基準であるかどうかを判断するには、次のJunos OS CLI操作モードコマンドを入力します。
user@host> show route destination-prefix < detail >
出力例
コマンド名
user@R4> show route 100.100.2.0 detail
inet.0: 20 destinations, 24 routes (20 active, 0 holddown, 0 hidden)
100.100.2.0/24 (2 entries, 1 announced)
*BGP Preference: 170/-101
Source: 10.0.0.2
Next hop: 10.1.24.1 via so-0/0/3.0, selected
Protocol next hop: 10.0.0.2 Indirect next hop: 8644000 277
State: <Active Int Ext>
Local AS: 65002 Peer AS: 65002
Age: 2:32:01 Metric: 5 Metric2: 10
Task: BGP_65002.10.0.0.2+179
Announcement bits (3): 0-KRT 3-BGP.0.0.0.0+179 4-Resolve inet.0
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.2
BGP Preference: 170/-101
Source: 10.1.45.2
Next hop: 10.1.45.2 via so-0/0/2.0, selected
State: <NotBest Ext>
Inactive reason: Not Best in its group
Local AS: 65002 Peer AS: 65001
Age: 2w0d 1:37:58 Metric: 10
Task: BGP_65001.10.1.45.2+179
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.5
意味
サンプル出力は、 R4 が 100.100.2.0 route の 2 つのインスタンスを受信したことを示しています。1つは 10.0.0.2 (R2)から、もう1つは 10.1.45.2 (R5)から。 R4 、アスタリスク(*)で示されるように、アクティブなルートとして R2 からのパスを選択しました。選択は、[ Metric: ] フィールドに含まれる MED 値に基づきます。MED値が最も小さいパスが優先されます。この例では、MED値が最も小さいパス(5)は、 R2からのパスです。2 つのパスは、同じ隣接ネットワークからのものであることに注意してください。AS 65001として。
非アクティブなパスが選択されていない理由が [ Inactive reason: ] フィールドに表示されます。この場合は Not Best in its group。この文言が使用されるのは、Junos OSがデフォルトで決定論的なMED選択プロセスを使用するためです。
EBGP over IBGP の選択について検討する
目的
ルートを調べて、単一のアクティブなパスの選択基準として IBGP よりも EBGP が選択されているかどうかを判別します。
アクション
ルートを調べて、シングルでアクティブなパスの選択基準として IBGP よりも EBGP が選択されているかどうかを確認するには、次の Junos OS CLI 操作モード コマンドを入力します。
user@host> show route destination-prefix < detail >
出力例
コマンド名
user@R4> show route 100.100.3.0 detail
inet.0: 20 destinations, 24 routes (20 active, 0 holddown, 0 hidden)
100.100.3.0/24 (2 entries, 1 announced)
*BGP Preference: 170/-101
Source: 10.1.45.2
Next hop: 10.1.45.2 via so-0/0/2.0, selected
State: <Active Ext>
Local AS: 65002 Peer AS: 65001
Age: 5d 0:31:25
Task: BGP_65001.10.1.45.2+179
Announcement bits (3): 0-KRT 3-BGP.0.0.0.0+179 4-Resolve inet.0
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.5
BGP Preference: 170/-101
Source: 10.0.0.2
Next hop: 10.1.24.1 via so-0/0/3.0, selected
Protocol next hop: 10.0.0.2 Indirect next hop: 8644000 277
State: <NotBest Int Ext>
Inactive reason: Interior > Exterior > Exterior via Interior
Local AS: 65002 Peer AS: 65002
Age: 2:48:18 Metric2: 10
Task: BGP_65002.10.0.0.2+179
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.2
意味
サンプル出力は、 R4 が 100.100.3.0 ルートの 2 つのインスタンスを受信したことを示しています。1つは 10.1.45.2 (R5)から、もう1つは 10.0.0.2 (R2)から。 R4 、アスタリスク(*)で示されるように、アクティブなパスとして R5 からのパスを選択しました。この選択は、IBGPから学習したルートよりも、EBGPピアから学習したルートを優先して行われます。 R5 はEBGPピアです。
EBGP または IBGP ピアからパスを受け取ったかどうかは、 Local As および Peer As フィールドを調べることで判断できます。例えば、 R5 からのルートは、ローカルASが65002で、ピアASが65001であり、EBGPピアからルートを受信していることを示しています。R2からのルートは、ローカルとピアASの両方が65002であり、IBGPピアから受信されたことを示しています。
非アクティブなパスが選択されていない理由が [ Inactive reason ] フィールドに表示されます。この場合は Interior > Exterior > Exterior via Interior。この理由の文言は、2つのルーターから同じルートを受信したときに適用される優先の順序を示しています。厳密に内部ソース(IGP)から受信したルートが最初に優先され、次に外部ソース(EBGP)から受信したルートが優先され、最後に外部ソースから受信され内部で受信されたルート(IBGP)が優先されます。そのため、EBGPルートはIBGPルートよりもアクティブパスとして選択されます。
IGP コスト選択を検討する
目的
ルートを調べて、単一のアクティブなパスの選択基準として IBGP よりも EBGP が選択されているかどうかを判別します。
アクション
ルートを調べて、シングルでアクティブなパスの選択基準として IBGP よりも EBGP が選択されているかどうかを確認するには、次の Junos OS CLI 操作モード コマンドを入力します。
user@host> show route destination-prefix < detail >
出力例
コマンド名
user@R6> show route 100.100.4.0 detail
inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden)
100.100.4.0/24 (2 entries, 1 announced)
*BGP Preference: 170/-101
Source: 10.0.0.4
Next hop: 10.1.46.1 via so-0/0/1.0, selected
Protocol next hop: 10.0.0.4 Indirect next hop: 864c000 276
State: <Active Int Ext>
Local AS: 65002 Peer AS: 65002
Age: 2:16:11 Metric2: 10
Task: BGP_65002.10.0.0.4+4120
Announcement bits (2): 0-KRT 4-Resolve inet.0
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.4
BGP Preference: 170/-101
Source: 10.0.0.2
Next hop: 10.1.46.1 via so-0/0/1.0, selected
Next hop: 10.1.36.1 via so-0/0/3.0
Protocol next hop: 10.0.0.2 Indirect next hop: 864c0b0 278
State: <NotBest Int Ext>
Inactive reason: IGP metric
Local AS: 65002 Peer AS: 65002
Age: 2:16:03 Metric2: 20
Task: BGP_65002.10.0.0.2+179
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.2
意味
サンプル出力は、 R6 が 100.100.4.0 ルートの 2 つのインスタンスを受信したことを示しています。1つは 10.0.0.4 (R4)から、もう1つは 10.0.0.2 (R2)から。 R6 、アスタリスク(*)で示されるように、アクティブなルートとして R4 からのパスを選択しました。選択はIGPメトリックに基づいており、[ Metric2 ]フィールドに表示されます。IGPメトリックが最も低いルートが優先されます。この例では、IGPメトリック値が最も低いパスは、IGPメトリック値が10の R4からのパスであり、 R2 からのパスのIGPメトリックは20です。2 つのパスは、同じ隣接ネットワークからのものであることに注意してください。AS 65001として。
非アクティブなパスが選択されなかった理由が [ Inactive reason ] フィールドに表示されます。この場合は IGP metric。
BGP レイヤーを確認するためのチェックリスト
問題点
説明
このチェックリストでは、MPLS (Multiprotocol Label Switching) ネットワークの BGP 構成を確認するための手順とコマンドを提供します。チェックリストには、BGP 設定の概要と、BGP 設定に使用するコマンドの詳細情報へのリンクが記載されています。（「表 2」を参照してください。）
ソリューション
タスク |
コマンドまたはアクション |
|---|---|
| BGP レイヤーの確認 | |
|
|
|
|
|
|
|
|
|
|
次の一連のコマンドは、このトピックで説明した特定の問題に対処するものです。
|
|
|
BGP レイヤーの確認
目的
ラベルスイッチパス（LSP）を設定してそれが稼働していることを確認し、BGPを設定してセッションが確立していることを確認した後、BGP が LSP を使用してトラフィックを転送していることを確認します。
図 3 は、階層化 MPLS モデルの BGP レイヤーを示しています。
BGP レイヤーを確認する際には、ルートが存在していてアクティブであることを確認し、さらに重要なこととして、ネクストホップが LSP であることを確認します。BGP は MPLS LSP を使用してトラフィックを転送するため、LSP が確立されていなければ BGP レイヤーをチェックする意味がありません。BGP レイヤーでネットワークが機能していない場合、LSP は設定通りに機能しません。
図 4は、このトピックで使用する MPLS ネットワークを示しています。
そので示すネットワークは、直接接続されているすべてのインターフェイスが、他のすべての類似したインターフェイスにパケットを受信および送信できる、完全にメッシュ化された設定図 4です。このネットワークの LSP はR1、イングレスルーターからトランジットルーターを経てR3、イグレスルーターに至るように設定されていますR6。さらに、リバース LSP は、R6からR3を経てR1に至るように設定されており、双方向トラフィックを作成します。
そのに示したクロスは、LSP を介したトラフィックの転送に BGP が使用されていないことを示図 4しています。LSP が正常に機能しない理由としては、LSP の宛先 IP アドレスが BGP のネクストホップと一致していないか、BGP が正しく設定されていないことが考えられます。
BGP レイヤーを確認するには、次の手順に従います。
- BGP トラフィックが LSP を使用していることを確認する
- BGP セッションの確認
- BGP の設定を確認する
- BGP ルートを調べる
- 受信した BGP ルートの検証
- ネットワークの問題解決に向けた適切な対応
- BGP トラフィックが再び LSP を使用していることを確認する
BGP トラフィックが LSP を使用していることを確認する
目的
トラブルシューティング モデルのこのレベルでは、BGP と LSP は稼働していても、BGP トラフィックが LSP を使用してトラフィックを転送していない可能性があります。
アクション
BGP トラフィックが LSP を使用していることを確認するために、イングレス ルーターから次の Junos OS CLI(コマンドライン インターフェイス)運用モード コマンドを入力します。
user@host> traceroute hostname
出力例
コマンド名
user@R1> traceroute 100.100.6.1 traceroute to 100.100.6.1 (100.100.6.1), 30 hops max, 40 byte packets 1 10.1.13.2 (10.1.13.2) 0.653 ms 0.590 ms 0.543 ms 2 10.1.36.2 (10.1.36.2) 0.553 ms !N 0.552 ms !N 0.537 ms !N user@R6> traceroute 100.100.1.1 traceroute to 100.100.1.1 (100.100.1.1), 30 hops max, 40 byte packets 1 10.1.36.1 (10.1.36.1) 0.660 ms 0.551 ms 0.526 ms 2 10.1.13.1 (10.1.13.1) 0.568 ms !N 0.553 ms !N 0.536 ms !N
意味
サンプル出力では、BGP トラフィックが LSP を使用していないため、MPLS ラベルが出力に表示されないことを示しています。BGPトラフィックはLSPを使用する代わりに、内部ゲートウェイプロトコル(IGP)を使用して、 R6 および R1用のBGPネクストホップLSPイグレスアドレスに到達しています。Junos OS のデフォルトでは、BGP ネクストホップが LSP イグレス アドレスと等しい場合、BGP トラフィックに LSP が使用されます。
BGP セッションの確認
目的
BGPとそのネイバーに関するサマリー情報を表示して、自律システム(AS)内のピアからルートを受信しているかどうかを確認します。BGP セッションが確立されると、ピアは更新メッセージを交換します。
アクション
BGP セッションが稼働していることを確認するには、イングレスルーターから次の Junos OS CLI 運用モードコマンドを入力します。
user@host> show bgp summary
サンプル出力1
コマンド名
user@R1> show bgp summary Groups: 1 Peers: 6 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 1 1 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 10.0.0.2 65432 11257 11259 0 0 3d 21:49:57 0/0/0 0/0/0 10.0.0.3 65432 11257 11259 0 0 3d 21:49:57 0/0/0 0/0/0 10.0.0.4 65432 11257 11259 0 0 3d 21:49:57 0/0/0 0/0/0 10.0.0.5 65432 11257 11260 0 0 3d 21:49:57 0/0/0 0/0/0 10.0.0.6 65432 4 4572 0 1 3d 21:46:59 Active 10.1.36.2 65432 11252 11257 0 0 3d 21:46:49 1/1/0 0/0/0
サンプル出力2
コマンド名
user@R1> show bgp summary Groups: 1 Peers: 5 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 1 1 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 10.0.0.2 65432 64 68 0 0 32:18 0/0/0 0/0/0 10.0.0.3 65432 64 67 0 0 32:02 0/0/0 0/0/0 10.0.0.4 65432 64 67 0 0 32:10 0/0/0 0/0/0 10.0.0.5 65432 64 67 0 0 32:14 0/0/0 0/0/0 10.0.0.6 65432 38 39 0 1 18:02 1/1/0 0/0/0
意味
サンプル出力 1 では、Down Peers: 1 フィールドで示されているように、1 つのピア(エグレス ルーター 10.0.0.6)が確立されていないことがわかります。最後の列(State|#Active/Received/Damped)は、ピア 10.0.0.6 がアクティブであることを示しており、確立されていないことを示しています。他のすべてのピアは、アクティブ、受信、および減衰ルートの数で示されるとおりに確立されます。例えば、ピア 10.0.0.2 の 0/0/0 は、ルーティング テーブルでアクティブまたは受信された BGP ルートがなく、BGP ルートが減衰していないことを示します。 1/1/0 ピア 10.1.36.2 は、1 つの BGP ルートがアクティブで、ルーティング テーブルで受信され、BGP ルートがダンピングされなかったことを示します。
イングレス ルーターの show bgp summary コマンドの出力に、ネイバーがダウンしていることが示されている場合は、BGP の設定を確認します。BGP 設定の確認については、次を参照してください: BGP 設定を確認する。
サンプル出力 2 は、 ネットワークの問題解決のための適切なアクションの実行でR1 と R6 での BGP 設定が修正された後のイングレス ルーター R1 からの出力を示しています。すべての BGP ピアが確立され、1 つのルートがアクティブで受信されます。減衰された BGP ルートはありません。
show bgp summary コマンドの出力に、ネイバーは稼働しているがパケットが転送されていないことが示されている場合は、エグレス ルーターから受信したルートを確認します。エグレス ルーターの受信ルートを確認する方法については、次を参照してください: 受信した BGP ルートを確認する。
BGP の設定を確認する
目的
BGPをルーターで実行するには、ローカルAS番号を定義し、少なくとも1つのグループを設定し、グループ内の少なくとも1つのピアに関する情報(ピアのIPアドレスとAS番号)を含める必要があります。BGP が MPLS ネットワークの一部である場合、LSP をネクストホップとして BGP ルートをインストールするためには、LSP に BGP ネクストホップと等しい宛先 IP アドレスが設定されていることを確認する必要があります。
アクション
BGP の設定を確認するには、次の Junos OS CLI 運用モード コマンドを入力します。
user@host> show configuration
サンプル出力1
コマンド名
user@R1> show configuration
[...Output truncated...]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.1.12.1/30;
}
family iso;
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.15.1/30;
}
family iso;
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.1.13.1/30;
}
family iso;
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.143/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.1/32;
}
family iso {
address 49.0004.1000.0000.0001.00;
}
}
}
}
routing-options {
[...Output truncated...]
route 100.100.1.0/24 reject;
}
router-id 10.0.0.1;
autonomous-system 65432;
}
protocols {
rsvp {
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path R1-to-R6 {
to 10.0.0.6; <<< destination address of the LSP
}
inactive: interface so-0/0/0.0;
inactive: interface so-0/0/1.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
export send-statics; <<< missing local-address statement
group internal {
type internal;
neighbor 10.0.0.2;
neighbor 10.0.0.5;
neighbor 10.0.0.4;
neighbor 10.0.0.6;
neighbor 10.0.0.3;
neighbor 10.1.36.2; <<< incorrect interface address
}
}
isis {
level 1 disable;
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface all {
level 2 metric 10;
}
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface lo0.0; {
passive
}
}
}
}
policy-options {
policy-statement send-statics {
term statics {
from {
route-filter 100.100.1.0/24 exact;
}
then accept;
}
}
}
サンプル出力2
コマンド名
user@R6> show configuration
[...Output truncated...]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.1.56.2/30;
}
family iso;
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.46.2/30;
}
family iso;
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.1.26.2/30;
}
family iso;
family mpls;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.36.2/30;
}
family iso;
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.148/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.6/32;
address 127.0.0.1/32;
}
family iso {
address 49.0004.1000.0000.0006.00;
}
}
}
}
routing-options {
[...Output truncated...]
route 100.100.6.0/24 reject;
}
router-id 10.0.0.6;
autonomous-system 65432;
}
protocols {
rsvp {
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path R6-to-R1 {
to 10.0.0.1; <<< destination address of the reverse LSP
}
inactive: interface so-0/0/0.0;
inactive: interface so-0/0/1.0;
inactive: interface so-0/0/2.0;
interface so-0/0/3.0;
}
bgp {
group internal {
type internal;
export send-statics; <<< missing local-address statement
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
neighbor 10.0.0.5;
neighbor 10.0.0.1;
neighbor 10.1.13.1; <<< incorrect interface address
}
}
isis {
level 1 disable;
interface all {
level 2 metric 10;
}
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface so-0/0/3.0;
interface lo0.0 {
passive;
}
}
}
}
policy-options {
policy-statement send-statics {
term statics {
from {
route-filter 100.100.6.0/24 exact;
}
then accept;
}
}
}
意味
サンプル出力は、イングレス ルーター R1 とエグレス ルーター R6での BGP 設定を示しています。どちらの設定でも、ローカルAS(65432)、1つのグループ(internal)、および6つのピアが設定されています。基盤となる内部ゲートウェイ プロトコルは IS-IS であり、関連するインターフェイスは IS-IS を実行するように設定されています。
この設定では、重複する RID の問題を回避するために RID を手動で設定し、BGP で設定したすべてのインタフェースに [edit interfaces type-fpc/pic/port unit logical-unit-number] 階層レベルの family inet ステートメントが含まれています。
イングレス ルーター R1 とエグレス ルーター R6 の出力例では、BGP プロトコル設定に内部グループの local-address ステートメントがないことがわかります。local-address ステートメントが設定されている場合、BGP パケットは、BGP ピアがピアリングしているアドレスであるローカル ルーター ループバック(lo0)インターフェイス アドレスから転送されます。local-address ステートメントが設定されていない場合、BGP パケットは発信インターフェイス アドレスから転送されますが、これは BGP ピアがピアリングしているアドレスと一致しず、BGP は立ち上がりません。
イングレスルーターでは、local-address ステートメントの IP アドレス(10.0.0.1)は、[edit protocols mpls label-switched-path lsp-path-name] 階層レベルの to ステートメントのエグレス ルーター(R6)の LSP に設定されたアドレスと同じである必要があります。BGP は、LSP アドレスと同じこのアドレスを使用して、BGP トラフィックを LSP 経由で転送します。
また、 R1 のBGP設定には、 R6用の2つのIPアドレス、インターフェイスアドレス(10.1.36.2)とループバック(lo0)インターフェイスアドレス(10.0.0.6)が含まれているため、LSP宛先アドレス(10.0.0.6)がBGPネクストホップアドレス(10.1.36.2)と一致しません。また、 R6 のBGP設定には、 R1用の2つのIPアドレス、インターフェイスアドレス(10.1.13.1)とループバック(lo0)インターフェイスアドレスが含まれているため、リバースLSP宛先アドレス(10.0.0.1)がBGPネクストホップアドレス(10.1.13.1)と一致しません。
この場合、両方のルーターのBGP設定に local-address ステートメントがなく、LSP宛先アドレスがBGPネクストホップアドレスと一致しないため、BGPはLSPを使用してトラフィックを転送していません。
BGP ルートを調べる
目的
BGPが同じ宛先に複数のルートを受信した場合、BGPパス選択プロセスを調べて、単一のアクティブなパスを決定できます。このステップでは、リバースLSP R6-to-R1を調べ、そのLSPのイングレスルーターを R6 します。
アクション
BGP ルートとルート選択を調べるには、次の Junos OS CLI 運用モード コマンドを入力します。
user@host> show route destination-prefix detail
サンプル出力1
コマンド名
user@R6> show route 100.100.1.1 detail
inet.0: 30 destinations, 46 routes (29 active, 0 holddown, 1 hidden)
100.100.1.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Source: 10.1.13.1
Next hop: via so-0/0/3.0, selected
Protocol next hop: 10.1.13.1 Indirect next hop: 8671594 304
State: <Active Int Ext>
Local AS: 65432 Peer AS: 65432
Age: 4d 5:15:39 Metric2: 2
Task: BGP_65432.10.1.13.1+3048
Announcement bits (2): 0-KRT 4-Resolve inet.0
AS path: I
Localpref: 100
Router ID: 10.0.0.1
サンプル出力2
コマンド名
user@R6> show route 100.100.1.1 detail
inet.0: 30 destinations, 46 routes (29 active, 0 holddown, 1 hidden)
100.100.1.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Source: 10.0.0.1
Next hop: via so-0/0/3.0 weight 1, selected
Label-switched-path R6-to-R1
Label operation: Push 100000
Protocol next hop: 10.0.0.1 Indirect next hop: 8671330 301
State: <Active Int Ext>
Local AS: 65432 Peer AS: 65432
Age: 24:35 Metric2: 2
Task: BGP_65432.10.0.0.1+179
Announcement bits (2): 0-KRT 4-Resolve inet.0
AS path: I
Localpref: 100
Router ID: 10.0.0.1
意味
サンプル出力 1 では、R6 and R1のBGP設定が正しくない場合、BGPネクストホップ(10.1.13.1)が[edit protocols mpls label-switched-path label-switched-path-name]階層レベルの to ステートメントのLSP宛先アドレス(10.0.0.1)と等しくないことを示しています。
R1 と R6 の設定を修正した後のサンプル出力 2 では、BGP ネクストホップ(10.0.0.1)と LSP 宛先アドレス(10.0.0.1)が同じであり、BGP が LSP を使用して BGP トラフィックを転送できることを示しています。
受信した BGP ルートの検証
目的
リバース LSP R6-to-R1用のイングレス ルーターであるルーター R6 で受信したルーティング情報を表示します。
アクション
エグレスルーターで特定のBGPルートが受信されたことを確認するには、次のJunos OS CLI運用モードコマンドを入力します。
user@host> show route receive protocol bgp neighbor-address
サンプル出力1
コマンド名
user@R6> show route receive-protocol bgp 10.0.0.1 inet.0: 30 destinations, 46 routes (29 active, 0 holddown, 1 hidden) <<< missing route inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) __juniper_private1__.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
サンプル出力2
コマンド名
user@R6> show route receive-protocol bgp 10.0.0.1 inet.0: 30 destinations, 46 routes (29 active, 0 holddown, 1 hidden) Prefix Nexthop MED Lclpref AS path * 100.100.1.0/24 10.0.0.1 100 I inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) __juniper_private1__.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
意味
サンプル出力 1 は、R1 と R6 の BGP 設定が正しくない場合、イングレスルーター R6(リバース LSP R6-to-R1)が inet.0 ルーティング テーブルに BGP ルートを受信しないことを示しています。
サンプル出力 2 は、R1 と R6 の BGP 設定が ネットワークの問題解決のための適切なアクションの実行を使用して修正された後、inet.0 ルーティング テーブルにインストールされた BGP ルートを示しています。
ネットワークの問題解決に向けた適切な対応
問題点
説明
適切なアクションは、切り分けた問題の種類によって異なります。この例では、 R2 に設定されたスタティックルートが[routing-options]階層レベルから削除されます。その他の適切なアクションには、次のものが含まれます。
ソリューション
ローカルルーターの設定を確認し、必要に応じて編集します。
中間ルーターをトラブルシューティングします。
リモートホストの設定を確認し、必要に応じて編集します。
ルーティングプロトコルのトラブルシューティングを行います。
その他の考えられる原因を特定します。
この例の問題を解決するには、次の Junos OS CLI コマンドを入力します。
[edit]
user@R2# delete routing-options static route destination-prefix
user@R2# commit and-quit
user@R2# show route destination-prefix
サンプル出力
[edit]
user@R2# delete routing-options static route 10.0.0.5/32
[edit]
user@R2# commit and-quit
commit complete
Exiting configuration mode
user@R2> show route 10.0.0.5
inet.0: 22 destinations, 24 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.5/32 *[BGP/170] 3d 20:26:17, MED 5, localpref 100
AS path: 65001 I
> to 10.1.12.1 via so-0/0/0.0
意味
サンプル出力は、[routing-options] 階層から削除されたスタティックルートと、コミットされた新しいコンフィギュレーションを示しています。これで、 show route コマンドの出力に、アスタリスク(*)で示されるように、優先ルートとしてBGPルートが表示されます。
BGP トラフィックが再び LSP を使用していることを確認する
目的
エラーを修正するために適切な処置を行った後、BGP トラフィックが LSP を使用していること、および BGP レイヤーの問題が解決されたことを確認するために、LSP を再度確認する必要があります。
アクション
BGP トラフィックが LSP を使用していることを確認するために、イングレスルーターから次の Junos OS CLI 運用モードコマンドを入力します。
user@host> traceroute hostname
出力例
コマンド名
user@R1> traceroute 100.100.6.1
traceroute to 100.100.6.1 (100.100.6.1), 30 hops max, 40 byte packets
1 10.1.13.2 (10.1.13.2) 0.858 ms 0.740 ms 0.714 ms
MPLS Label=100016 CoS=0 TTL=1 S=1
2 10.1.36.2 (10.1.36.2) 0.592 ms !N 0.564 ms !N 0.548 ms !N
user@R6> traceroute 100.100.1.1
traceroute to 100.100.1.1 (100.100.1.1), 30 hops max, 40 byte packets
1 10.1.36.1 (10.1.36.1) 0.817 ms 0.697 ms 0.771 ms
MPLS Label=100000 CoS=0 TTL=1 S=1
2 10.1.13.1 (10.1.13.1) 0.581 ms !N 0.567 ms !N 0.544 ms !N
意味
サンプル出力は、MPLS ラベルが LSP を介してパケットを転送するために使用されていることを示しています。MPLS Label=100016TTL=1S=1出力に含まれるのは、ラベル値（）、寿命時間値（）、スタックビット値（）です。
MPLS Labelこのフィールドは、特定の LSP へのパケットを識別するために使用される。これは 20 ビット フィールドで、最大値は (2^^20-1) で、約 1,000,000 です。
TTL(Time-to-live)値には、このMPLSパケットがネットワークを通過できるホップ数の制限が含まれています(1)。ホップごとにデクリメントされ、TTL値が1を下回るとパケットは廃棄される。
S=1スタック最下段のビット値（）は、スタックの最後のラベルであり、このMPLSパケットに1つのラベルが関連付けられていることを示す。Junos OSのMPLS実装は、Mシリーズ・ルーターで3、Tシリーズ・ルーティング・プラットフォームで最大5のスタッキング深さをサポートしています。MPLSラベルスタックの詳細については、RFC 3032「MPLS Label Stack Encoding」を参照してください。
サンプル出力にMPLSラベルが表示されるのは、その経路のBGPネクストホップがLSPイグレスアドレスであるBGP宛に traceroute コマンドが発行されているためです。Junos OSは、BGPネクストホップがLSPイグレスアドレスと等しい場合、デフォルトでBGPトラフィックにLSPを使用します。
BGP ネクストホップが LSP の出口アドレスと等しくない場合、BGP トラフィックは LSP を使用しないため、Check BGP セッションの出力例に示されているように、traceroute コマンドの出力に MPLS ラベルは表示されません。
送信または受信した BGP パケットを表示する
アクション
BGP プロトコルの送信または受信パケットのトレースを設定するには、次の手順に従います。
設定モードでは、次の階層レベルに移動します。
[edit] user@host# edit protocol bgp traceoptions
送信、受信、または送信と受信の両方のパケット情報を表示するようにフラグを設定します。
[edit protocols bgp traceoptions] user@host# set flag update sendまたは
[edit protocols bgp traceoptions] user@host# set flag update receive
または
[edit protocols bgp traceoptions] user@host# set flag update
設定の確認：
user@host# show
たとえば、以下のように表示されます。
[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update send;
または
[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update receive;
または
[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update send receive;
設定をコミットします。
user@host# commit
詳細メッセージの入ったファイルの内容を表示する。
user@host# run show log filenameたとえば、以下のように表示されます。
[edit protocols bgp traceoptions] user@host# run show log bgplog Sep 13 12:58:23 trace_on: Tracing to "/var/log/bgplog" started Sep 13 12:58:23 BGP RECV flags 0x40 code ASPath(2): <null> Sep 13 12:58:23 BGP RECV flags 0x40 code LocalPref(5): 100 Sep 13 12:58:23 BGP RECV flags 0xc0 code Extended Communities(16): 2:10458:3 [...Output truncated...]
フォワーディング テーブルのルートを調べる
目的
接続障害などの問題が発生した場合、ルーティング プロトコル プロセスが正しい情報をフォワーディング テーブルにリレーしたことを確認するために、フォワーディング テーブルのルートを調べる必要がある場合があります。
アクション
転送テーブルにインストールされている経路のセットを表示するには、次の Junos OS CLI 運用モード コマンドを入力します。
user@host> show route forwarding-table
サンプル出力
コマンド名
user@R2> show route forwarding-table Routing table: inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 10 1 10.0.0.2/32 intf 0 10.0.0.2 locl 256 1 10.0.0.3/32 user 1 10.1.23.0 ucst 282 4 so-0/0/1.0 10.0.0.4/32 user 1 10.1.24.0 ucst 290 7 so-0/0/3.0 10.0.0.6/32 user 1 10.1.24.0 ucst 290 7 so-0/0/3.0 10.1.12.0/30 intf 1 ff.3.0.21 ucst 278 6 so-0/0/0.0 10.1.12.0/32 dest 0 10.1.12.0 recv 280 1 so-0/0/0.0 10.1.12.2/32 intf 0 10.1.12.2 locl 277 1 10.1.12.3/32 dest 0 10.1.12.3 bcst 279 1 so-0/0/0.0 10.1.23.0/30 intf 0 ff.3.0.21 ucst 282 4 so-0/0/1.0 10.1.23.0/32 dest 0 10.1.23.0 recv 284 1 so-0/0/1.0 10.1.23.1/32 intf 0 10.1.23.1 locl 281 1 10.1.23.3/32 dest 0 10.1.23.3 bcst 283 1 so-0/0/1.0 10.1.24.0/30 intf 0 ff.3.0.21 ucst 290 7 so-0/0/3.0 10.1.24.0/32 dest 0 10.1.24.0 recv 292 1 so-0/0/3.0 10.1.24.1/32 intf 0 10.1.24.1 locl 289 1 10.1.24.3/32 dest 0 10.1.24.3 bcst 291 1 so-0/0/3.0 10.1.36.0/30 user 0 10.1.23.0 ucst 282 4 so-0/0/1.0 10.1.46.0/30 user 0 10.1.24.0 ucst 290 7 so-0/0/3.0 100.100.1.0/24 user 0 10.1.12.0 ucst 278 6 so-0/0/0.0 100.100.2.0/24 user 0 10.1.12.0 ucst 278 6 so-0/0/0.0 100.100.3.0/24 user 0 10.1.12.0 ucst 278 6 so-0/0/0.0 100.100.4.0/24 user 0 10.1.12.0 ucst 278 6 so-0/0/0.0 [...Output truncated...]
意味
サンプル出力では、転送テーブルにインストールされたネットワーク層のプレフィックスとそのネクスト ホップが表示されます。出力には、コマshow route detail ンドと同じネクストホップ情報（ネクストホップ アドレスとインターフェイス名）が含まれます。追加情報には、宛先タイプ、ネクストホップ タイプ、このネクストホップへの参照数、内部ネクストホップ データベースのインデックスが含まれます。(内部データベースには、パケット 転送 エンジンがインターフェースから送信されるパケットを適切にカプセル化するために使用する追加情報が含まれています。このデータベースは、ユーザーがアクセスすることはできません。
さまざまなフラグとタイプのフィールドの意味の詳細については、 ルーティング ポリシー、ファイアウォール フィルター、および Traffic Policers User Guideを参照してください。
例：PTX シリーズパケットトランスポートルーターのデフォルト BGP ルーティングポリシーの上書き
この例では、PTX シリーズパケットトランスポートルーターなどで、デフォルトのルーティングポリシーを上書きする方法を示しています。
要件
この例では、Junos OS Release 12.1 以降が必要です。
概要
デフォルトでは、PTX シリーズルーターは、転送テーブルに BGP ルートをインストールしません。
PTX シリーズルーターでは、アクthen acceptションでfrom protocols bgp条件を設定しても、他の Junos OS ルーティングデバイスのような通常の結果にはなりません。PTX シリーズルーター上で、以下のルーティングポリシーを設定すると、BGP ルートは転送テーブルにインストールされません。
user@host# show policy-options
policy-statement accept-no-install {
term 1 {
from protocol bgp;
then accept;
}
}
user@host# show routing-options
forwarding-table {
export accept-no-install;
}
user@host> show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 36 2
転送テーブルに BGP ルートはインストールされていません。これは予期される動作です。
この例では、のアクthen install-to-fibションを使用して、デフォルトの BGP ルーティングポリシーを効果的に上書きする方法を示しています。
設定
CLIクイック構成
この例をすばやく設定するには、次のコマンドをコピーしてテキストファイルに貼り付け、改行を削除して、ネットワーク構成に合わせて必要な詳細を変更し、[edit]階層レベルのCLIにコマンドをコピー＆ペーストしてください。
set policy-options prefix-list install-bgp 66.0.0.1/32 set policy-options policy-statement override-ptx-series-default term 1 from prefix-list install-bgp set policy-options policy-statement override-ptx-series-default term 1 then load-balance per-prefix set policy-options policy-statement override-ptx-series-default term 1 then install-to-fib set routing-options forwarding-table export override-ptx-series-default
選択した BGP ルートを転送テーブルにインストール
ステップバイステップでの手順
次の例では、設定階層のいくつかのレベルに移動する必要があります。CLIのナビゲーションについては、Junos OS CLIユーザーガイドの 設定モードでCLIエディターを使用する を参照してください。
選択した BGP ルートを転送テーブルにインストールするには、次の手順に従います：
転送テーブルにインストールするプレフィックス一覧を設定します。
[edit policy-options prefix-list install-bgp] user@host# set 66.0.0.1/32
ルーティングポリシーを設定し、プレフィックスリストを条件として適用します。
[edit policy-options policy-statement override-ptx-series-default term 1] user@host# set from prefix-list install-bgp user@host# set then install-to-fib user@host# set then load-balance per-prefix
ルーティングポリシーを転送テーブルに適用します。
[edit routing-options forwarding-table] user@host# set export override-ptx-series-default
結果
設定モードから、show policy-options および show routing-options コマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。
user@host# show policy-options
prefix-list install-bgp {
66.0.0.1/32;
}
policy-statement override-ptx-series-default {
term 1 {
from {
prefix-list install-bgp;
}
then {
load-balance per-prefix;
install-to-fib;
}
}
}
user@host# show routing-options
forwarding-table {
export override-ptx-series-default;
}
デバイスの設定が完了したら、設定モードから commit を入力します。
検証
設定が正常に機能していることを確認します。
その選択したルートが転送テーブルにインストールされていることを確認
目的
設定されたポリシーが、デフォルトのポリシーに上書きされていることを確認してください。
アクション
動作モードからshow route forwarding-tableコマンドを入力します。
user@host> show route forwarding-table destination 66.0.0.1
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
66.0.0.1/32 user 0 indr 2097159 3
ulst 2097156 2
5.1.0.2 ucst 574 1 et-6/0/0.1
5.2.0.2 ucst 575 1 et-6/0/0.2
意味
この出力は、66.0.0.1/32 へのルートが、転送テーブルにインストールされていることを示しています。
BGP の状態遷移イベントのログ
目的
Border Gateway Protocol（ボーダ・ゲートウェイ・プロトコル、略称 : BGP）の状態遷移は、ネットワークの問題を示しており、ログを取って調査する必要があります。
アクション
BGP の状態遷移イベントをシステムログに記録するには、次の手順に従います。
設定モードでは、次の階層レベルに移動します。
[edit] user@host# edit protocol bgpシステムログの設定：
user@host# set log-updown
設定の確認：
user@host# show
設定をコミットします。
user@host# commit
意味
ほとんどの BGP のセッション問題を診断するには、BGP の状態遷移イベントからのログメッセージで十分ですが、BGP セッションの 6 つの状態を一表 3覧にして説明します。
BGP の状態 |
説明 |
|---|---|
Idle |
これは、接続の最初の状態です。BGP は、管理者が始める開始イベントを待ちます。開始イベントとは、ルータ設定による BGP セッションの確立や、既存セッションのリセットなどです。開始イベントの後、BGP はリソースを初期化し、接続再試行タイマーをリセットし、TCP トランスポート接続を開始し、リモートピアから開始される接続のリッスンを開始します。BGP はその後、Connect状態を遷移させます。 エラーが発生した場合、BGP はそのIdle状態にフォールバックします。 |
Connect |
BGP は、トランスポートプロトコルの接続が完了するのを待ちます。TCP トランスポート接続が成功すると、状態は次のように遷移しますOpenSent。 トランスポート接続が成功しない場合、状態は次のように遷移しますActive。 接続再試行タイマーが終了した場合、Connect状態はそのままで、タイマーがリセットされ、トランスポート接続が開始されます。 それ以外のイベントでは、状態が戻ってしまいますIdle。 |
Active |
BGP は、トランスポートプロトコル接続を開始することで、ピアを取得しようとします。 成功すると、状態は次のように遷移しますOpenSent。 接続再試行タイマーが終了すると、BGP は接続タイマーを再起動し、 Connect状態をフォールバックします。BGP は、他のピアから開始される可能性のある接続を待ち受けます。この状態は、ストップイベントなどの他のイベントが発生した場合Idle 、戻ることがあります。 ConnectActive 一般的に、ネイバーの状態がおよび間で反転している場合は、TCP トランスポート接続に問題があることを示しています。このような問題は、TCP の再送が多い場合や、ネイバーがピアの IP アドレスに到達できない場合などに発生します。 |
OpenSent |
BGP は、ピアからオープンメッセージを受信します。このOpenSent 状態では、BGP は自律システム（AS）番号とピアの AS 番号を比較し、ピアが同じ AS（内部 BGP）に属しているか、異なる AS に属しているか（外部 BGP）を認識します。 オープンメッセージが正しいかどうかをチェックします。受け入れられない AS のバージョン番号が悪いなどのエラーが発生した場合、BGP はエラー通知メッセージを送信し、元に戻りますIdle。 ホールドタイマーの終了やストップイベントなど、その他のエラーが発生した場合、BGP は対応するエラーコードを含む通知メッセージを送信し、 Idle状態にフォールバックします。 エラーが発生しない場合、BGP はキープアライブメッセージを送信し、キープアライブタイマーをリセットします。この状態では、ホールドタイムがネゴシエーションされます。ホールドタイムが 0 の場合、ホールドタイマーとキープアライブタイマーは再起動しません。 TCP トランスポートの切断が検出されると、状態はフォールバックしますActive。 |
OpenConfirm |
BGP は、キープアライブまたは通知メッセージを待ちます。 キープアライブを受信した場合、状態はEstablishedになり、ネイバーネゴシエーションは完了します。システムが更新メッセージまたはキープアライブメッセージを受信すると、ホールドタイマーを再起動します。（ネゴシエーションされたホールドタイマーは 0 ではないと仮定）。 通知メッセージを受信した場合、状態はフォールバックします Idle。 システムは、キープアライブタイマーによって設定されたレートで、定期的にキープアライブメッセージを送信します。トランスポートの切断通知があった場合や、ストップイベントに応じた場合、状態はフォールバックします Idle。他のイベントに応じて、システムは有限状態機械（FSM）のエラーコードを含む通知メッセージを送信し、元の状態に戻りますIdle。 |
Established |
これは、ネイバーネゴシエーションの最終状態です。この状態では、BGP はピアと更新アケットを交換し、ホールドタイマーが、ゼロに設定されていない場合は、更新メッセージまたはキープアライブメッセージの受信時に再起動されます。 システムが通知メッセージを受信すると、状態はフォールバックしますIdle。 更新メッセージは、属性の欠落、属性の重複などのエラーがないかチェックされます。エラーが発生した場合、ピアに通知が送信され、状態はフォールバックしますIdle。 BGP は、ホールドタイマーが切れたとき、トランスポートプロトコルから切断通知を受信したとき、ストップイベントを受信したとき、またはその他のイベントに応答したIdleときに戻ります。 |
より詳細な BGP プロトコルのパケット情報を得るためには、BGP 特有のトレースを設定します。詳細については、トラッキングエラーの条件を満たすためのチェックリストをご覧ください。
BGP 固有のオプションを設定する
目的
予期しない事象や問題が発生した場合、または BGP 確立の問題を診断する場合、BGP に固有のオプションを設定することで、より詳細な情報を表示することができます。また、特定の BGP ピアまたはピア グループに対してトレースを設定することも可能です。詳しくは、Junos System Basics Configuration Guide をご覧ください。
詳細な BGP プロトコル情報の表示
アクション
BGP プロトコル情報を詳細に表示するには、次の手順を実行します。
設定モードでは、次の階層レベルに移動します。
[edit] user@host# edit protocol bgp traceoptions
詳細な BGP プロトコル メッセージを表示するために、 フラグを設定します。
[edit protocols bgp traceoptions] user@host# set flag update detail
設定の確認：
user@host# show
以下はその一例です。
[edit protocols bgp traceoptions] user@host# show flag update detail;
設定をコミットします。
user@host# commit
詳細メッセージの入ったファイルの内容を表示する。
user@host# run show log filename以下はその一例です。
[edit protocols bgp traceoptions] user@pro5-a# run show log bgp Sep 17 14:47:16 trace_on: Tracing to "/var/log/bgp" started Sep 17 14:47:17 bgp_read_v4_update: receiving packet(s) from 10.255.245.53 (Internal AS 10458) Sep 17 14:47:17 BGP RECV 10.255.245.53+179 -> 10.255.245.50+1141 Sep 17 14:47:17 BGP RECV message type 2 (Update) length 128 Sep 17 14:47:17 BGP RECV flags 0x40 code Origin(1): IGP Sep 17 14:47:17 BGP RECV flags 0x40 code ASPath(2): 2 Sep 17 14:47:17 BGP RECV flags 0x80 code MultiExitDisc(4): 0 Sep 17 14:47:17 BGP RECV flags 0x40 code LocalPref(5): 100 Sep 17 14:47:17 BGP RECV flags 0xc0 code Extended Communities(16): 2:10458:1 [...Output truncated...]
意味
表 4 は、BGP に固有のトレース フラグの一覧と、一部のフラグの出力例を示しています。また、特定の BGP ピアまたはピア グループに対してトレースを設定することも可能です。詳しくは、Junos System Basics Configuration Guide をご覧ください。
トレース フラグ |
説明 |
出力例 |
|---|---|---|
aspath |
ASパス正規表現操作 |
機能なし。 |
damping |
ダンピング操作 |
Nov 28 17:01:12 bgp_damp_change: Change event Nov 28 17:01:12 bgp_dampen: Damping 10.10.1.0 Nov 28 17:01:12 bgp_damp_change: Change event Nov 28 17:01:12 bgp_dampen: Damping 10.10.2.0 Nov 28 17:01:12 bgp_damp_change: Change event Nov 28 17:01:12 bgp_dampen: Damping 10.10.3.0 |
keepalive |
BGP キープアライブ メッセージ |
Nov 28 17:09:27 bgp_send: sending 19 bytes to 10.217.5.101 (External AS 65471) Nov 28 17:09:27 Nov 28 17:09:27 BGP SEND 10.217.5.1+179 -> 10.217.5.101+52162 Nov 28 17:09:27 BGP SEND message type 4 (KeepAlive) length 19 Nov 28 17:09:28 Nov 28 17:09:28 BGP RECV 10.217.5.101+52162 -> 10.217.5.1+179 Nov 28 17:09:28 BGP RECV message type 4 (KeepAlive) length 19 |
open |
BGP オープン パケット |
Nov 28 18:37:42 bgp_send: sending 37 bytes to 10.217.5.101 (External AS 65471) Nov 28 18:37:42 Nov 28 18:37:42 BGP SEND 10.217.5.1+179 -> 10.217.5.101+38135 Nov 28 18:37:42 BGP SEND message type 1 (Open) length 37 |
packets |
すべての BGP プロトコル パケット |
Sep 27 17:45:31 BGP RECV 10.0.100.108+179 -> 10.0.100.105+1033 Sep 27 17:45:31 BGP RECV message type 4 (KeepAlive) length 19 Sep 27 17:45:31 bgp_send: sending 19 bytes to 10.0.100.108 (Internal AS 100) Sep 27 17:45:31 BGP SEND 10.0.100.105+1033 -> 10.0.100.108+179 Sep 27 17:45:31 BGP SEND message type 4 (KeepAlive) length 19 Sep 27 17:45:31 bgp_read_v4_update: receiving packet(s) from 10.0.100.108 (Internal AS 100) |
update |
パケットの更新 |
Nov 28 19:05:24 BGP SEND 10.217.5.1+179 -> 10.217.5.101+55813 Nov 28 19:05:24 BGP SEND message type 2 (Update) length 53 Nov 28 19:05:24 bgp_send: sending 65 bytes to 10.217.5.101 (External AS 65471) Nov 28 19:05:24 Nov 28 19:05:24 BGP SEND 10.217.5.1+179 -> 10.217.5.101+55813 Nov 28 19:05:24 BGP SEND message type 2 (Update) length 65 Nov 28 19:05:24 bgp_send: sending 55 bytes to 10.217.5.101 (External AS 65471) |
BGP セッション確立の問題を診断する
目的
BGP セッション確立の問題をトレースします。
アクション
BGP セッション確立の問題をトレースするには、次の手順に従います。
設定モードでは、次の階層レベルに移動します。
[edit] user@host# edit protocol bgpBGPオープンメッセージを設定します。
[edit protocols bgp] user@host# set traceoptions flag open detail
設定の確認：
user@host# show
以下はその一例です。
[edit protocols bgp] user@host# show traceoptions { file bgplog size 10k files 10; flag open detail; }設定をコミットします。
user@host# commit
詳細メッセージの入ったファイルの内容を表示する。
user@host#run show log filenameたとえば、以下のように表示されます。
[edit protocols bgp] user@hotst# run show log bgplog
Sep 17 17:13:14 trace_on: Tracing to "/var/log/bgplog" started Sep 17 17:13:14 bgp_read_v4_update: done with 201.0.0.2 (Internal AS 10458) received 19 octets 0 updates 0 routes Sep 17 17:13:15 bgp_read_v4_update: receiving packet(s) from 201.0.0.3 (Internal AS 10458) Sep 17 17:13:15 bgp_read_v4_update: done with 201.0.0.3 (Internal AS 10458) received 19 octets 0 updates 0 routes Sep 17 17:13:44 bgp_read_v4_update: receiving packet(s) from 201.0.0.2 (Internal AS 10458) [...Output truncated...]
IS-IS 固有のオプションを設定
目的
予期しないイベントや問題が発生した場合、または IS-IS 隣接関係の確立の問題を診断したい場合、IS-IS に固有のオプションを設定することでより詳細な情報を表示できます。
IS-IS オプションを設定するには、以下の手順に従います。
詳細な IS-IS プロトコル情報の表示
アクション
IS-IS メッセージを詳細にトレースするには、次の手順を実行します。
詳細な IS-IS プロトコル メッセージを表示するために、 フラグを設定します。
[edit protocols isis traceoptions] user@host# set flag hello detail
設定を確認します。
user@host# show
以下はその一例です。
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello detail;
設定をコミットします。
user@host# commit
詳細メッセージが入っているファイルの内容を表示する。
user@host# run show log filename以下はその一例です。
user@host# run show log isislog
Nov 29 23:17:50 trace_on: Tracing to "/var/log/isislog" started Nov 29 23:17:50 Sending PTP IIH on so-1/1/1.0 Nov 29 23:17:53 Sending PTP IIH on so-1/1/0.0 Nov 29 23:17:54 Received PTP IIH, source id abc-core-01 on so-1/1/0.0 Nov 29 23:17:54 from interface index 11 Nov 29 23:17:54 max area 0, circuit type l2, packet length 4469 Nov 29 23:17:54 hold time 30, circuit id 6 Nov 29 23:17:54 neighbor state up Nov 29 23:17:54 speaks IP Nov 29 23:17:54 area address 99.0008 (1) Nov 29 23:17:54 IP address 10.10.10.29 Nov 29 23:17:54 4396 bytes of total padding Nov 29 23:17:54 updating neighbor abc-core-01 Nov 29 23:17:55 Received PTP IIH, source id abc-core-02 on so-1/1/1.0 Nov 29 23:17:55 from interface index 12 Nov 29 23:17:55 max area 0, circuit type l2, packet length 4469 Nov 29 23:17:55 hold time 30, circuit id 6 Nov 29 23:17:55 neighbor state up Nov 29 23:17:55 speaks IP Nov 29 23:17:55 area address 99.0000 (1) Nov 29 23:17:55 IP address 10.10.10.33 Nov 29 23:17:55 4396 bytes of total padding Nov 29 23:17:55 updating neighbor abc-core-02
意味
表 5 は、IS-IS に固有の設定が可能なトレース フラグの一覧と、一部のフラグの出力例を示しています。
トレース フラグ |
説明 |
出力例 |
|---|---|---|
csn |
完全なシーケンス番号 PDU(CSNP) |
Nov 28 20:02:48 Sending L2 CSN on interface so-1/1/0.0Nov 28 20:02:48 Sending L2 CSN on interface so-1/1/1.0 detailオプション付き。 Nov 28 20:06:08 Sending L2 CSN on interface so-1/1/1.0Nov 28 20:06:08 LSP abc-core-01.00-00 lifetime 1146Nov 28 20:06:08 sequence 0x1c4f8 checksum 0xa1e9Nov 28 20:06:08 LSP abc-core-02.00-00 lifetime 411Nov 28 20:06:08 sequence 0x7435 checksum 0x5424Nov 28 20:06:08 LSP abc-brdr-01.00-00 lifetime 465Nov 28 20:06:08 sequence 0xf73 checksum 0xab10Nov 28 20:06:08 LSP abc-edge-01.00-00 lifetime 1089Nov 28 20:06:08 sequence 0x1616 checksum 0xdb29Nov 28 20:06:08 LSP abc-edge-02.00-00 lifetime 1103Nov 28 20:06:08 sequence 0x45cc checksum 0x6883 |
hello |
ハローパケット |
Nov 28 20:13:50 Sending PTP IIH on so-1/1/1.0Nov 28 20:13:50 Received PTP IIH, source id abc-core-01 on so-1/1/0.0Nov 28 20:13:53 Received PTP IIH, source id abc-core-02 on so-1/1/1.0Nov 28 20:13:57 Sending PTP IIH on so-1/1/0.0Nov 28 20:13:58 Received PTP IIH, source id abc-core-01 on so-1/1/0.0Nov 28 20:13:59 Sending PTP IIH on so-1/1/1.0 |
lsp |
リンクステートPDU(LSP) |
Nov 28 20:15:46 Received L2 LSP abc-edge-01.00-00, interface so-1/1/0.0Nov 28 20:15:46 from abc-core-01Nov 28 20:15:46 sequence 0x1617, checksum 0xd92a, lifetime 1197Nov 28 20:15:46 Updating L2 LSP abc-edge-01.00-00 in TEDNov 28 20:15:47 Received L2 LSP abc-edge-01.00-00, interface so-1/1/1.0Nov 28 20:15:47 from abc-core-02Nov 28 20:15:47 sequence 0x1617, checksum 0xd92a, lifetime 1197 |
lsp-generation |
リンクステートPDU生成パケット |
Nov 28 20:21:24 Regenerating L1 LSP abc-edge-03.00-00, old sequence 0x682Nov 28 20:21:27 Rebuilding L1, fragment abc-edge-03.00-00Nov 28 20:21:27 Rebuilt L1 fragment abc-edge-03.00-00, size 59Nov 28 20:31:52 Regenerating L2 LSP abc-edge-03.00-00, old sequence 0x689Nov 28 20:31:54 Rebuilding L2, fragment abc-edge-03.00-00Nov 28 20:31:54 Rebuilt L2 fragment abc-edge-03.00-00, size 256Nov 28 20:34:05 Regenerating L1 LSP abc-edge-03.00-00, old sequence 0x683Nov 28 20:34:08 Rebuilding L1, fragment abc-edge-03.00-00Nov 28 20:34:08 Rebuilt L1 fragment abc-edge-03.00-00, size 59 |
packets |
すべてのIS-ISプロトコルパケット |
機能なし。 |
psn |
部分シーケンス番号 PDU(PSNP)パケット |
Nov 28 20:40:39 Received L2 PSN, source abc-core-01, interface so-1/1/0.0Nov 28 20:40:39 Received L2 PSN, source abc-core-02, interface so-1/1/1.0Nov 28 20:41:36 Sending L2 PSN on interface so-1/1/1.0Nov 28 20:41:36 Sending L2 PSN on interface so-1/1/0.0Nov 28 20:42:35 Received L2 PSN, source abc-core-02, interface so-1/1/1.0Nov 28 20:42:35 LSP abc-edge-03.00-00 lifetime 1196Nov 28 20:42:35 sequence 0x68c checksum 0x746dNov 28 20:42:35 Received L2 PSN, source abc-core-01, interface so-1/1/0.0Nov 28 20:42:35 LSP abc-edge-03.00-00 lifetime 1196Nov 28 20:42:35 sequence 0x68c checksum 0x746dNov 28 20:42:49 Sending L2 PSN on interface so-1/1/1.0Nov 28 20:42:49 LSP abc-core-01.00-00 lifetime 1197Nov 28 20:42:49 sequence 0x1c4fb checksum 0x9becNov 28 20:42:49 Sending L2 PSN on interface so-1/1/0.0Nov 28 20:42:49 LSP abc-core-01.00-00 lifetime 1197Nov 28 20:42:49 sequence 0x1c4fb checksum 0x9bec |
spf |
最短パス優先(SPF)計算 |
Nov 28 20:44:01 Scheduling SPF for L1: ReconfigNov 28 20:44:01 Scheduling multicast SPF for L1: ReconfigNov 28 20:44:01 Scheduling SPF for L2: ReconfigNov 28 20:44:01 Scheduling multicast SPF for L2: ReconfigNov 28 20:44:02 Running L1 SPFNov 28 20:44:02 L1 SPF initialization complete: 0.000099s cumulative timeNov 28 20:44:02 L1 SPF primary processing complete: 0.000303s cumulative timeNov 28 20:44:02 L1 SPF result postprocessing complete: 0.000497s cumulative timeNov 28 20:44:02 L1 SPF RIB postprocessing complete: 0.000626s cumulative timeNov 28 20:44:02 L1 SPF routing table postprocessing complete: 0.000736s cumulative time |
関連項目
送信または受信した IS-IS プロトコル パケットの表示
送信または受信した IS-IS プロトコル パケットのみにトレースを設定するには、次の手順に従います。
送信、受信、または送信と受信の両方のパケットを表示するようにフラグを設定します。
[edit protocols isis traceoptions] user@host# set flag hello send
または
[edit protocols isis traceoptions] user@host# set flag hello receive
または
[edit protocols isis traceoptions] user@host# set flag hello
設定を確認します。
user@host# show
以下はその一例です。
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello send;
または
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello receive;
または
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello send receive;
設定をコミットします。
user@host# commit
詳細メッセージが入っているファイルの内容を表示する。
user@host# run show log filename以下はその一例です。
user@host# run show log isislog Sep 27 18:17:01 ISIS periodic xmit to 01:80:c2:00:00:15 (IFL 2) Sep 27 18:17:01 ISIS periodic xmit to 01:80:c2:00:00:14 (IFL 2) Sep 27 18:17:03 ISIS periodic xmit to 01:80:c2:00:00:15 (IFL 2) Sep 27 18:17:04 ISIS periodic xmit to 01:80:c2:00:00:14 (IFL 2) Sep 27 18:17:06 ISIS L2 hello from 0000.0000.0008 (IFL 2) absorbed Sep 27 18:17:06 ISIS periodic xmit to 01:80:c2:00:00:15 (IFL 2) Sep 27 18:17:06 ISIS L1 hello from 0000.0000.0008 (IFL 2) absorbed
関連項目
IS-ISリンクステートPDUの詳細な分析
IS-IS リンクステート PDU を詳細に分析するには、以下の手順に従います。
IS-IS オープン メッセージを設定します。
[edit protocols isis traceoptions] user@host# set flag lsp detail
設定を確認します。
user@host# show
以下はその一例です。
[edit protocols isis traceoptions] user@host# show file isislog size 5m world-readable; flag error; flag lsp detail;
設定をコミットします。
user@host# commit
詳細メッセージが入っているファイルの内容を表示する。
user@host# run show log filename以下はその一例です。
user@host# run show log isislog Nov 28 20:17:24 Received L2 LSP abc-core-01.00-00, interface so-1/1/0.0 Nov 28 20:17:24 from abc-core-01 Nov 28 20:17:24 sequence 0x1c4f9, checksum 0x9fea, lifetime 1199 Nov 28 20:17:24 max area 0, length 426 Nov 28 20:17:24 no partition repair, no database overload Nov 28 20:17:24 IS type 3, metric type 0 Nov 28 20:17:24 area address 99.0908 (1) Nov 28 20:17:24 speaks CLNP Nov 28 20:17:24 speaks IP Nov 28 20:17:24 dyn hostname abc-core-01 Nov 28 20:17:24 IP address 10.10.134.11 Nov 28 20:17:24 IP prefix: 10.10.10.0/30 metric 1 up Nov 28 20:17:24 IP prefix: 10.10.10.4/30 metric 5 up Nov 28 20:17:24 IP prefix: 10.10.10.56/30 metric 5 up Nov 28 20:17:24 IP prefix: 10.10.10.52/30 metric 1 up Nov 28 20:17:24 IP prefix: 10.10.10.64/30 metric 5 up Nov 28 20:17:24 IP prefix: 10.10.10.20/30 metric 5 up Nov 28 20:17:24 IP prefix: 10.10.10.28/30 metric 5 up Nov 28 20:17:24 IP prefix: 10.10.10.44/30 metric 5 up Nov 28 20:17:24 IP prefix 10.10.10.0 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 1 Nov 28 20:17:24 IP prefix 10.10.10.4 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.10.10.56 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.10.10.52 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 1 Nov 28 20:17:24 IP prefix 10.10.10.64 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.10.10.20 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.10.10.28 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.10.10.44 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IS neighbors: Nov 28 20:17:24 IS neighbor abc-core-02.00 Nov 28 20:17:24 internal, metrics: default 1 [...Output truncated...] Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IS neighbor abc-brdr-01.00 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IS neighbor abc-core-02.00, metric: 1 Nov 28 20:17:24 IS neighbor abc-esr-02.00, metric: 5 Nov 28 20:17:24 IS neighbor abc-edge-03.00, metric: 5 Nov 28 20:17:24 IS neighbor abc-edge-01.00, metric: 5 Nov 28 20:17:24 IS neighbor abc-edge-02.00, metric: 5 Nov 28 20:17:24 IS neighbor abc-brdr-01.00, metric: 5 Nov 28 20:17:24 IP prefix: 10.10.134.11/32 metric 0 up Nov 28 20:17:24 IP prefix: 10.11.0.0/16 metric 5 up Nov 28 20:17:24 IP prefix: 10.211.0.0/16 metric 0 up Nov 28 20:17:24 IP prefix 10.10.134.11 255.255.255.255 Nov 28 20:17:24 internal, metrics: default 0 Nov 28 20:17:24 IP prefix 10.11.0.0 255.255.0.0 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.211.0.0 255.255.0.0 Nov 28 20:17:24 internal, metrics: default 0 Nov 28 20:17:24 Updating LSP Nov 28 20:17:24 Updating L2 LSP abc-core-01.00-00 in TED Nov 28 20:17:24 Analyzing subtlv's for abc-core-02.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Analyzing subtlv's for abc-esr-02.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Analyzing subtlv's for abc-edge-03.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Analyzing subtlv's for abc-edge-01.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Analyzing subtlv's for abc-edge-02.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Analyzing subtlv's for abc-brdr-01.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Scheduling L2 LSP abc-core-01.00-00 sequence 0x1c4f9 on interface so-1/1/1.0
関連項目
OSPP- 固有のオプションを設定
目的
予期しないイベントや問題が発生した場合、または OSPF ネイバーの確立の問題を診断したい場合、OSPF に固有のオプションを設定することでより詳細な情報を表示できます。
OSPP オプションを設定するには、以下の手順に従います。
OSPF セッション確立の問題を診断する
アクション
OSPF メッセージを詳細にトレースするには、以下の手順に従います。
設定モードでは、次の階層レベルに移動します。
[edit] user@host# edit protocols ospf traceoptions
OSPF Hello メッセージを設定します。
[edit protocols ospf traceoptions] user@host# set flag hello detail
設定の確認：
user@host# show
以下はその一例です。
[edit protocols ospf traceoptions] user@host# show file ospf size 5m world-readable; flag hello detail;
設定をコミットします。
user@host# commit
詳細メッセージの入ったファイルの内容を表示する。
user@host# run show log filename以下はその一例です。
user@host# run show log ospf
Dec 2 16:14:24 Version 2, length 44, ID 10.0.0.6, area 1.0.0.0 Dec 2 16:14:24 checksum 0xf01a, authtype 0 Dec 2 16:14:24 mask 0.0.0.0, hello_ivl 10, opts 0x2, prio 128 Dec 2 16:14:24 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Dec 2 16:14:24 OSPF sent Hello (1) -> 224.0.0.5 (so-1/1/2.0) Dec 2 16:14:24 Version 2, length 44, ID 10.0.0.6, area 1.0.0.0 Dec 2 16:14:24 checksum 0xf01a, authtype 0 Dec 2 16:14:24 mask 0.0.0.0, hello_ivl 10, opts 0x2, prio 128 Dec 2 16:14:24 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Dec 2 16:14:26 OSPF rcvd Hello 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) Dec 2 16:14:26 Version 2, length 48, ID 10.10.134.12, area 0.0.0.0 Dec 2 16:14:26 checksum 0x99b8, authtype 0Dec 2 16:14:26 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1 ec 2 16:14:26 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Dec 2 16:14:29 OSPF rcvd Hello 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0) Dec 2 16:14:29 Version 2, length 48, ID 10.108.134.11, area 0.0.0.0 Dec 2 16:14:29 checksum 0x99b9, authtype 0Dec 2 16:14:29 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1 Dec 2 16:14:29 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0
意味
表 6 は、OSPF トレース フラグの一覧を示し、一部のフラグの出力例を示します。
トレース フラグ |
説明 |
出力例 |
|---|---|---|
database-descripttion |
すべてのデータベース記述パケット |
Dec 2 15:44:51 RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.29 (so-1/1/0.0) state changed from Full to Down Dec 2 15:44:51 RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Full to Down Dec 2 15:44:55 RPD_OSPF_NBRUP: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Init to ExStart Dec 2 15:44:55 OSPF sent DbD (2) -> 224.0.0.5 (so-1/1/1.0) Dec 2 15:44:55 Version 2, length 32, ID 10.0.0.6, area 0.0.0.0 Dec 2 15:44:55 checksum 0xf76b, authtype 0 Dec 2 15:44:55 options 0x42, i 1, m 1, ms 1, seq 0xa009eee, mtu 4470 Dec 2 15:44:55 OSPF rcvd DbD 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) Dec 2 15:44:55 Version 2, length 32, ID 10.10.134.12, area 0.0.0.0 Dec 2 15:44:55 checksum 0x312c, authtype 0 Dec 2 15:44:55 options 0x42, i 1, m 1, ms 1, seq 0x2154, mtu 4470 |
error |
OSPF エラーパケット |
Dec 2 15:49:34 OSPF packet ignored: no matching interface from 172.16.120.29 Dec 2 15:49:44 OSPF packet ignored: no matching interface from 172.16.120.29 Dec 2 15:49:54 OSPF packet ignored: no matching interface from 172.16.120.29 Dec 2 15:50:04 OSPF packet ignored: no matching interface from 172.16.120.29 Dec 2 15:50:14 OSPF packet ignored: no matching interface from 172.16.120.29 |
event |
OSPF の状態遷移 |
Dec 2 15:52:35 OSPF interface ge-2/2/0.0 state changed from DR to DR Dec 2 15:52:35 OSPF interface ge-3/1/0.0 state changed from DR to DR Dec 2 15:52:35 OSPF interface ge-3/2/0.0 state changed from DR to DR Dec 2 15:52:35 OSPF interface ge-4/2/0.0 state changed from DR to DR Dec 2 15:53:21 OSPF neighbor 10.10.10.29 (so-1/1/0.0) state changed from Full to Down Dec 2 15:53:21 RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.29 (so-1/1/0.0) state changed from Full to Down Dec 2 15:53:21 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Full to Down Dec 2 15:53:21 RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Full to Down Dec 2 15:53:25 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Down to Init Dec 2 15:53:25 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Init to ExStart Dec 2 15:53:25 RPD_OSPF_NBRUP: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Init to ExStart Dec 2 15:53:25 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from ExStart to Exchange Dec 2 15:53:25 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Exchange to Full Dec 2 15:53:25 RPD_OSPF_NBRUP: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Exchange to Full |
flooding |
リンク状態フラッディングパケット |
Dec 2 15:55:21 OSPF LSA Summary 10.218.0.0 10.0.0.6 flooding on so-1/1/0.0 Dec 2 15:55:21 OSPF LSA Summary 10.218.0.0 10.0.0.6 flooding on so-1/1/1.0 Dec 2 15:55:21 OSPF LSA Summary 10.218.0.0 10.0.0.6 on no so-1/1/2.0 rexmit lists, no flood Dec 2 15:55:21 OSPF LSA Summary 10.218.0.0 10.0.0.6 on no so-1/1/3.0 rexmit lists, no flood Dec 2 15:55:21 OSPF LSA Summary 10.245.0.1 10.0.0.6 on no so-1/1/2.0 rexmit lists, no flood Dec 2 15:55:21 OSPF LSA Summary 10.245.0.1 10.0.0.6 on no so-1/1/3.0 rexmit lists, no flood |
hello |
Hello パケット |
Dec 2 15:57:25 OSPF sent Hello (1) -> 224.0.0.5 (ge-3/1/0.0) Dec 2 15:57:25 Version 2, length 44, ID 10.0.0.6, area 2.0.0.0 Dec 2 15:57:25 checksum 0xe43f, authtype 0 Dec 2 15:57:25 mask 255.255.0.0, hello_ivl 10, opts 0x2, prio 128 Dec 2 15:57:25 dead_ivl 40, DR 10.218.0.1, BDR 0.0.0.0 Dec 2 15:57:25 OSPF rcvd Hello 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) Dec 2 15:57:25 Version 2, length 48, ID 10.10.134.12, area 0.0.0.0 Dec 2 15:57:25 checksum 0x99b8, authtype 0 Dec 2 15:57:25 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1 Dec 2 15:57:25 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Dec 2 15:57:27 OSPF sent Hello (1) -> 224.0.0.5 (ge-3/2/0.0) Dec 2 15:57:27 Version 2, length 44, ID 10.0.0.6, area 2.0.0.0 Dec 2 15:57:27 checksum 0xe4a5, authtype 0 Dec 2 15:57:27 mask 255.255.0.0, hello_ivl 10, opts 0x2, prio 128 Dec 2 15:57:27 dead_ivl 40, DR 10.116.0.1, BDR 0.0.0.0 Dec 2 15:57:28 OSPF rcvd Hello 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0) Dec 2 15:57:28 Version 2, length 48, ID 10.10134.11, area 0.0.0.0 Dec 2 15:57:28 checksum 0x99b9, authtype 0 Dec 2 15:57:28 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1 Dec 2 15:57:28 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 |
lsa-ack |
リンク状態確認パケット |
Dec 2 16:00:11 OSPF rcvd LSAck 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0) Dec 2 16:00:11 Version 2, length 44, ID 10.10.134.11, area 0.0.0.0 Dec 2 16:00:11 checksum 0xcdbf, authtype 0 Dec 2 16:00:11 OSPF rcvd LSAck 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) Dec 2 16:00:11 Version 2, length 144, ID 10.10.134.12, area 0.0.0.0 Dec 2 16:00:11 checksum 0x73bc, authtype 0 Dec 2 16:00:16 OSPF rcvd LSAck 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) Dec 2 16:00:16 Version 2, length 44, ID 10.10.134.12, area 0.0.0.0 Dec 2 16:00:16 checksum 0x8180, authtype 0 |
lsa-request |
リンク状態要求パケット |
Dec 2 16:01:38 OSPF rcvd LSReq 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0) Dec 2 16:01:38 Version 2, length 108, ID 10.10.134.11, area 0.0.0.0 Dec 2 16:01:38 checksum 0xe86, authtype 0 |
lsa-update |
リンクステート更新パケット |
Dec 2 16:09:12 OSPF built router LSA, area 0.0.0.0 Dec 2 16:09:12 OSPF built router LSA, area 1.0.0.0 Dec 2 16:09:12 OSPF built router LSA, area 2.0.0.0 Dec 2 16:09:13 OSPF sent LSUpdate (4) -> 224.0.0.5 (so-1/1/0.0) Dec 2 16:09:13 Version 2, length 268, ID 10.0.0.6, area 0.0.0.0 Dec 2 16:09:13 checksum 0x8047, authtype 0 Dec 2 16:09:13 adv count 7 Dec 2 16:09:13 OSPF sent LSUpdate (4) -> 224.0.0.5 (so-1/1/1.0) Dec 2 16:09:13 Version 2, length 268, ID 10.0.0.6, area 0.0.0.0 Dec 2 16:09:13 checksum 0x8047, authtype 0 Dec 2 16:09:13 adv count 7 |
packets |
すべての OSPF パケット |
機能なし。 |
packet-dump |
選択したパケットタイプの内容をダンプします。 |
機能なし。 |
spf |
SPF 計算 |
Dec 2 16:08:03 OSPF full SPF refresh scheduled Dec 2 16:08:04 OSPF SPF start, area 1.0.0.0 Dec 2 16:08:04 OSPF add LSA Router 10.0.0.6 distance 0 to SPF list Dec 2 16:08:04 SPF elapsed time 0.000525s Dec 2 16:08:04 Stub elapsed time 0.000263s Dec 2 16:08:04 OSPF SPF start, area 2.0.0.0 Dec 2 16:08:04 OSPF add LSA Router 10.0.0.6 distance 0 to SPF list Dec 2 16:08:04 SPF elapsed time 0.000253s Dec 2 16:08:04 Stub elapsed time 0.000249s Dec 2 16:08:04 OSPF SPF start, area 0.0.0.0 Dec 2 16:08:04 OSPF add LSA Router 10.0.0.6 distance 0 to SPF list Dec 2 16:08:04 OSPF add LSA Router 10.10.134.11 distance 1 to SPF list Dec 2 16:08:04 IP nexthop so-1/1/0.0 0.0.0.0 Dec 2 16:08:04 OSPF add LSA Router 10.10134.12 distance 1 to SPF list Dec 2 16:08:04 IP nexthop so-1/1/1.0 0.0.0.0 |
OSPFリンク状態アドバタイズパケットの詳細分析
アクション
OSPF リンク状態アドバタイズメント パケットを詳細に分析するには、以下の手順に従います。
設定モードでは、次の階層レベルに移動します。
[edit] user@host# edit protocols ospf traceoptions
OSPF リンクステート パッケージを設定します。
[edit protocols ospf traceoptions] user@host# set flag lsa-update detail
設定の確認：
user@host# show
以下はその一例です。
[edit protocols ospf traceoptions] user@host# show file ospf size 5m world-readable; flag hello detail; flag lsa-update detail;
設定をコミットします。
user@host# commit
詳細メッセージの入ったファイルの内容を表示する。
user@host# run show log filenameたとえば、以下のように表示されます。
user@host# run show log ospf
Dec 2 16:23:47 OSPF sent LSUpdate (4) -> 224.0.0.5 (so-1/1/0.0) ec 2 16:23:47 Version 2, length 196, ID 10.0.0.6, area 0.0.0.0 Dec 2 16:23:47 checksum 0xcc46, authtype 0 Dec 2 16:23:47 adv count 6 Dec 2 16:23:47 OSPF sent LSUpdate (4) -> 224.0.0.5 (so-1/1/1.0) Dec 2 16:23:47 Version 2, length 196, ID 10.0.0.6, area 0.0.0.0 Dec 2 16:23:47 checksum 0xcc46, authtype 0 Dec 2 16:23:47 adv count 6