CDP / LLDP Documentation Validation

このページのゴール

ネットワーク資料に記載された直接接続リンクと、CDPまたはLLDPで実際に観測した隣接情報を項目単位で比較し、「一致」「不一致」「確認情報不足」を区別できるようにします。

重要なのは、隣接機器が1つ表示されたから資料全体を正しいと判断したり、逆に1項目が異なるだけで資料全体を誤りと決めたりしないことです。

検証対象となるリンクを先に特定し、隣接機器の識別、自機器側ポート、隣接機器側ポート、役割、機種、管理アドレスなど、CDPやLLDPで直接確認できる項目を対応付けて評価します。

また、隣接情報が表示されない場合や、古いエントリがHoldtime中に残っている場合には、確認条件が不足していないかを考えます。

このページで学ぶこと

• 検証する直接接続リンクと比較項目を先に決める方法
• CDPまたはLLDPを利用できる条件を確認する考え方
• 自機器側ポートをネットワーク資料と比較する方法
• 隣接機器側ポートをネットワーク資料と比較する方法
• 隣接機器の識別情報を比較する方法
• CapabilityやPlatformを役割・機種の照合へ使う方法
• Management Addressを対応する管理情報の照合へ使う方法
• 各項目を「一致」「不一致」で個別評価する方法
• 証拠が足りないときに「確認情報不足」と判断する方法
• Holdtime中の古い隣接エントリを現在の接続証拠と混同しない方法
• CDPとLLDPの一致を相互補強として利用する方法
• CDPやLLDPで直接証明できる範囲とできない範囲を区別する方法

最初に検証対象のリンクを決める

ネットワーク資料を検証するとき、いきなり全機器・全設定を対象にしません。

まず、

どの直接接続リンクを検証するか

を決めます。

たとえば資料に、

リンクA
SW1 Gi1/0/8
↓
SW2 Gi1/0/1

リンクB
SW1 Gi1/0/9
↓
SW3 Gi1/0/1

とあるなら、どちらのリンクを確認しているのかを固定します。

1つのリンクに複数の比較項目がある

1本の直接接続リンクでも、確認できる項目は複数あります。

例：

隣接機器
→ SW2

自機器側ポート
→ SW1 Gi1/0/24

隣接機器側ポート
→ SW2 Gi1/0/1

役割
→ スイッチ

機種
→ C9300

管理アドレス
→ 10.0.0.2

これらを1つの結果へまとめず、項目ごとに照合します。

検証前に「何を比較するか」を決める

同じCDPやLLDP出力でも、目的によって見る項目は変わります。

たとえば、

接続先機器を確認したい
→ 隣接機器識別

配線ポートを確認したい
→ 自機器側ポート
→ 隣接機器側ポート

管理情報を確認したい
→ Management Address

です。

目的を決めずに全項目を眺めるより、検証対象を先に決めます。

CDPとLLDPで直接確認できる情報を使う

CDPやLLDPが直接扱う中心は、直接接続された隣接機器情報です。

したがって資料検証では、

隣接機器識別

ローカル側インターフェース

リモート側ポート識別子

Capability

Platform

Management Address

などを利用します。

CDPやLLDPで直接見えない情報まで同時に判定しない

資料に次のような情報が同時に書かれていても、

直接接続リンク
ACL
ルーティングポリシー
アプリケーション到達性

CDPやLLDPで直接確認する中心は直接接続リンクの隣接情報です。

ACL内容

ルーティングポリシー

エンドツーエンドのアプリケーション到達性

までCDPやLLDPだけで直接証明したとは扱いません。

CDPまたはLLDPを利用できる状態か確認する

期待する隣接機器が表示されない場合、

資料が誤り

と即断する前に、

そもそもその隣接機器発見プロトコルで確認できる状態か

を考えます。

CDPならCDPの有効状態、LLDPならLLDPの全体状態や送受信条件が関係します。

隣接情報がないことと配線不一致は同じではない

資料：

SW1 Gi1/0/24
↓
SW2 Gi1/0/1

確認：

show lldp neighbors
→ SW2が表示されない

この時点で、

資料のSW2記載
→ 不一致確定

とは判断しません。

LLDPの受信・送信条件を確認できていなければ、確認情報不足の可能性があります。

LLDPでAがBを学習するには方向条件がある

AがBをLLDP隣接機器として学習するには、

A側受信
+
B側送信

が必要です。

したがって、

A側受信
→ 有効

だけを確認しても、

B側送信
→ 未確認

なら、Bが表示されない理由を資料不一致へ確定できません。

CDPでも確認機能が使える状態かを見る

CDPで期待隣接機器が表示されない場合も、

CDP全体

対象インターフェース

相手機器側

の条件を考えます。

「隣接エントリなし」だけを資料不一致の直接証拠にはしません。

自機器側ポートを資料と照合する

資料：

SW1 Gi1/0/24
↓
SW2

SW1でCDPを確認：

Device ID        Local Intrfce     Port ID
SW2              Gig 1/0/24        Gig 1/0/1

自機器側の比較は、

資料
→ SW1 Gi1/0/24

観測
→ Local Intrfce Gi1/0/24

です。

一致しています。

Local Intrfceは自機器側として比較する

CDPのLocal Intrfceは、コマンドを実行した自機器側の接続ポートです。

したがって、

資料の自機器側ポート
↓
CDP Local Intrfce

を対応させます。

隣接機器側のPort IDと比較しません。

LLDPのLocal Intfも自機器側として比較する

LLDPの場合も同様です。

Device ID        Local Intf      Port ID
SW2              Gi1/0/24        Gi1/0/1

なら、

Local Intf
→ 自機器側

です。

資料のSW1側ポートと比較します。

自機器側ポートだけ不一致になる場合がある

資料：

SW1 Gi1/0/24
↓
SW2 Gi1/0/1

観測：

Device ID
→ SW2

Local Intrfce
→ Gi1/0/23

Port ID
→ Gi1/0/1

この場合、

隣接機器
→ 一致

自機器側ポート
→ 不一致

隣接機器側ポート
→ 一致

です。

資料全体を一括で「不一致」とだけ記録せず、不一致項目を特定します。

隣接機器側ポートを資料と照合する

資料：

SW1 Gi1/0/24
↓
SW2 Gi1/0/1

CDP：

Device ID
→ SW2

Local Intrfce
→ Gi1/0/24

Port ID
→ Gi1/0/2

この場合、

隣接機器側ポート
→ 不一致

です。

自機器側が一致していても、隣接機器側まで一致とは扱いません。

CDPのPort IDは隣接機器側ポートとして比較する

CDPでは、

Local Intrfce
→ 自機器側

Port ID
→ 隣接機器側

という方向を固定します。

資料の隣接機器側ポートとPort IDを比較します。

LLDPのPort IDは形式を確認してから比較する

LLDPではPort IDが必ずインターフェース名形式とは限りません。

たとえば、

Port ID Subtype
→ Interface Name

Port ID
→ Ethernet1/2

なら、資料の隣接機器側ポートと直接対応付けやすい状態です。

一方、

Port ID Subtype
→ MAC Address

Port ID
→ 00aa.bbcc.ddee

なら、その値をそのままポート名として比較しません。

LLDPの隣接機器側ポート比較ではサブタイプを確認する

資料：

隣接機器側ポート
→ Ethernet1/1

LLDP：

Port ID Subtype
→ Interface Name

Port ID
→ Ethernet1/2

この場合は、

隣接機器側ポート
→ 不一致

と判断できます。

サブタイプがInterface Nameなので、観測値を資料のインターフェース名へ対応付けられます。

Port IDがMAC形式なら追加情報を使う

資料：

隣接機器側ポート
→ GigabitEthernet1/0/48

LLDP：

Port ID
→ 00aa.bbcc.ddee

だけでは、直接ポート名として比較しにくい場合があります。

このとき、

Port ID Subtype

Port Description

を追加で確認します。

Port Descriptionで隣接機器側ポート対応を補強する

LLDP：

Port ID Subtype
→ Local

Port ID
→ 48

Port Description
→ GigabitEthernet1/0/48

なら、

Port ID単体
→ 数値

ですが、

Port Description
→ 資料上の隣接機器側ポートと対応

と判断できる可能性があります。

証拠の対応関係を明示して比較します。

隣接機器の識別情報を照合する

資料：

隣接機器
→ AP01

観測：

System Name
→ PHONE01

またはCDPで、

Device ID
→ PHONE01

なら、

隣接機器識別
→ 不一致

です。

機器名不一致とポート不一致を混同しない

たとえば、

資料隣接機器
→ AP01

観測隣接機器
→ PHONE01

でも、

自機器側ポート

が一致する場合があります。

この場合、

隣接機器識別
→ 不一致

自機器側ポート
→ 一致

と分けて記録します。

CDPのDevice IDを識別情報として使う

CDPでは、

Device ID

を隣接機器識別の主要な確認情報として利用できます。

資料に、

隣接機器
→ SW2

とあり、

Device ID
→ SW2

なら、その項目については一致です。

LLDPのSystem Nameを識別情報として使う

LLDPでは、

System Name

が隣接機器名の照合に使えます。

資料：

隣接機器
→ SW-ACCESS-01

LLDP：

System Name
→ SW-ACCESS-02

なら、その項目は不一致です。

Chassis IDは追加の識別情報として使える

LLDPではChassis IDも隣接機器識別の手掛かりです。

System Name
→ SW2

Chassis ID
→ 0011.2233.4455

のように複数の識別情報を取得できる場合があります。

資料で筐体識別情報も管理しているなら対応項目として比較できます。

Capabilityは役割情報として比較する

資料：

隣接機器の役割
→ Router

観測：

Capability
→ Switch

なら、

役割
→ 不一致

です。

機器名が一致していても、役割まで一致とは限りません。

識別情報一致とCapability一致を分ける

資料：

隣接機器
→ SW2

役割
→ Router

観測：

Device ID
→ SW2

Capability
→ Switch

なら、

隣接機器識別
→ 一致

Capability / 役割
→ 不一致

です。

一方の一致をもう一方へ拡張しません。

Platformは機種情報として比較する

CDPなどでPlatformを取得できる場合、資料の機種情報と比較できます。

資料：

機種
→ C8300

観測：

Platform
→ C9300

なら、

機種
→ 不一致

です。

CapabilityとPlatformを一括で扱わない

CapabilityとPlatformは同じ項目ではありません。

Capability
→ 機器の機能・役割

Platform
→ 機種

として分けます。

資料に両方あるなら、別々に照合します。

Management Addressは管理情報として比較する

資料：

管理IP
→ 10.0.0.2

CDPまたはLLDPの詳細情報：

Management Address
→ 10.0.0.2

なら、

管理アドレス
→ 一致

と評価できます。

Management Address一致だけで全体一致にしない

次のような状態を考えます。

Management Address
→ 一致

Capability
→ 不一致

Platform
→ 不一致

この場合、

管理アドレス
→ 一致

役割
→ 不一致

機種
→ 不一致

と項目単位で記録します。

Management Addressから隣接機器側ポートを推定しない

管理アドレスは管理情報です。

Management Address
→ 管理用アドレス

Port ID
→ 隣接機器側ポート識別子

です。

管理アドレスが一致しても隣接機器側ポートまで一致とは判断しません。

一致・不一致は項目単位で記録する

検証結果の基本は、

隣接機器識別
→ 一致

自機器側ポート
→ 一致

隣接機器側ポート
→ 不一致

Capability
→ 一致

Management Address
→ 一致

のように項目ごとに残すことです。

1項目の不一致で全項目を不一致にしない

隣接機器側ポートだけが異なる場合、

隣接機器側ポート
→ 不一致

ですが、

隣接機器識別

自機器側ポート

まで自動的に不一致にはしません。

観測した証拠に対応する項目だけを評価します。

1項目の一致で全項目を一致にしない

反対に、

隣接機器識別
→ 一致

だけを確認して、

資料全体
→ 一致

とは判断しません。

ポート、役割、Platform、Management Addressなどはそれぞれ確認します。

「資料全体の正誤」より「どの項目が違うか」を重視する

実務で資料を修正する場合も、

どこが違うか

が分からなければ修正できません。

したがって、

全体不一致

だけで終わらず、

隣接機器側ポートが不一致

Platformが不一致

のように具体的な項目へ分解します。

確認情報不足を不一致と区別する

観測できないからといって、必ず不一致とは限りません。

たとえば、

LLDP 隣接機器
→ 表示なし

隣接機器側lldp transmit
→ 未確認

なら、

資料の隣接機器
→ 不一致確定

ではなく、

確認情報不足

と判断するのが適切です。

未確認条件があるなら確定判定を保留する

LLDPでAからBが見えない場合、

A受信
→ 有効

B送信
→ 未確認

なら、Bが見えない原因が資料誤りなのか、B側送信停止なのか切り分けられていません。

この場合、

確認情報不足
→ B側送信状態を追加確認

とします。

物理リンク状態だけでも不十分な場合がある

自機器側インターフェース
→ up/up

でも、

LLDP 隣接機器
→ なし

という状態はあり得ます。

LLDPの送受信条件が未確認なら、

物理リンクup
→ 隣接機器は必ず表示される

とは判断できません。

隣接情報がないだけで隣接機器側ポート不一致にしない

隣接エントリがない状態では、

隣接機器側ポート
→ 観測できない

ことがあります。

この場合、

隣接機器側ポート
→ 不一致

ではなく、

隣接機器側ポート
→ 確認情報不足

となる場合があります。

Holdtime中の残存エントリに注意する

CDPやLLDPでは、受信済みの隣接情報が一定時間残る場合があります。

そのため、

隣接機器エントリ
→ あり

だけで、

現在もそのリンクがup

とは判断しません。

現在のインターフェース状態と隣接エントリを分ける

状態：

隣接機器エントリ
→ SW2あり

自機器側インターフェース
→ down/down

Holdtime
→ 残りあり

なら、

古いエントリが残存している可能性

を考えます。

古いエントリを現在の資料一致証拠にしない

資料：

現在
SW1 Gi1/0/24
↓
SW2 Gi1/0/1

隣接エントリ：

SW2
自機器側ポート Gi1/0/24
隣接機器側ポート Gi1/0/1

でも、自機器側インターフェースが現在ダウンなら、

現在の接続証拠

として即確定しません。

Holdtimeや再観測を確認します。

時間変化を確認すると現在性を判断しやすい

残存エントリが疑われる場合、

Holdtime

インターフェース状態

再観測

を組み合わせます。

古い情報が消えるのか、新しい広告で更新されるのかを確認すると、現在性を判断しやすくなります。

CDPとLLDPを相互補強に使える場合がある

同じ直接接続リンクでCDPとLLDPの両方を利用できる場合、両方の観測が一致すれば確認情報を補強できます。

例：

CDP Device ID
→ SW2

LLDP System Name
→ SW2

なら、

隣接機器識別
→ 両方で一致

です。

別プロトコルの一致は同一項目の確度を高める

CDP：

Local Intrfce
→ Gi1/0/24

LLDP：

Local Intf
→ Gi1/0/24

なら、

自機器側ポート
→ 両方で一致

と確認できます。

片方が見えないときもう片方を追加証拠にできる

LLDPでは期待隣接機器が見えないが、同じ直接接続リンクでCDPが利用できるとします。

LLDP
→ 隣接機器なし

CDP
→ SW2を確認

この場合、

CDP
→ 追加の直接接続確認情報

として使えます。

ただし、LLDPが見えない理由そのものは別途確認が必要です。

CDPが見えるからLLDP送信も有効とは限らない

CDPとLLDPは別プロトコルです。

CDP 隣接機器
→ 見える

から、

隣接機器側LLDP送信
→ 有効

とは断定できません。

CDPは接続存在の追加証拠にはなりますが、LLDP設定状態まで証明しません。

LLDPが見えるからCDPも有効とは限らない

逆も同じです。

LLDP 隣接機器
→ 見える

から、

CDP
→ 必ず有効

とは判断しません。

別々の隣接機器発見プロトコルとして扱います。

CDPとLLDPで異なる識別子形式が出る場合がある

同じ隣接機器でも、

CDP
→ Device ID

LLDP
→ System Name
→ Chassis ID

など、使う識別項目が異なります。

文字列の表面だけでなく、どの項目を比較しているかを確認します。

プロトコル間で隣接機器側ポートを比較するときは意味を合わせる

CDP：

Port ID
→ Gi1/0/1

LLDP：

Port ID Subtype
→ Interface Name

Port ID
→ Gi1/0/1

なら、

隣接機器側ポート
→ 同じ意味の識別子として相互補強

できます。

一方、LLDPのPort IDがMAC Address形式なら、直接文字列一致を要求しません。

隣接機器発見情報の証拠範囲を守る

CDPやLLDPで直接確認しやすいのは、

直接隣接機器

自機器側ポート

隣接機器側ポート識別子

識別情報

Capability

Platform

Management Address

などです。

これらを超える事項まで直接証明したとは扱いません。

エンドツーエンド到達性はCDPやLLDPだけで証明しない

たとえば、

SW1
↓
SW2
↓
Router
↓
Server

という構成で、

SW1とSW2のCDP 隣接機器
→ 正常

でも、

Server アプリケーション
→ 到達可能

まで証明したことにはなりません。

ルーティングポリシーは別の検証手段が必要

資料に、

ルーティングポリシー

が記載されていても、CDPやLLDPの隣接機器情報だけでその妥当性は直接検証しません。

このページでは、

隣接機器発見情報で直接確認できる項目

と、

別手段が必要な項目

を分けます。

ACL内容も隣接機器発見情報の直接検証対象ではない

隣接機器情報から、

ACLのpermit / deny内容

まで直接証明することはできません。

資料にACL情報があっても、それは別の確認方法が必要です。

ネットワーク図全体の作図方法は扱わない

このページの目的は、

既存資料
+
CDP / LLDP観測
↓
項目単位で照合

です。

ネットワーク図をゼロから作図する手順そのものは扱いません。

シナリオ1：自機器側ポートだけ不一致

資料：

SW1 Gi1/0/24
↓
SW2 Gi1/0/1

CDP：

Device ID
→ SW2

Local Intrfce
→ Gi1/0/23

Port ID
→ Gi1/0/1

判定：

隣接機器識別
→ 一致

自機器側ポート
→ 不一致

隣接機器側ポート
→ 一致

シナリオ2：隣接機器側ポートだけ不一致

資料：

SW1 Gi1/0/24
↓
SW2 Gi1/0/1

CDP：

Device ID
→ SW2

Local Intrfce
→ Gi1/0/24

Port ID
→ Gi1/0/2

判定：

隣接機器識別
→ 一致

自機器側ポート
→ 一致

隣接機器側ポート
→ 不一致

シナリオ3：隣接機器識別が不一致

資料：

SW1 Gi1/0/10
↓
AP01

観測：

System Name
→ PHONE01

判定：

隣接機器識別
→ 不一致

自機器側ポートなど別項目は別に評価します。

シナリオ4：Capabilityだけ異なる

資料：

隣接機器
→ SW2

役割
→ Router

観測：

Device ID
→ SW2

Capability
→ Switch

判定：

識別情報
→ 一致

Capability / 役割
→ 不一致

シナリオ5：Management Addressだけ一致

資料：

役割
→ Router

Platform
→ C8300

管理IP
→ 10.0.0.2

観測：

Capability
→ Switch

Platform
→ C9300

Management Address
→ 10.0.0.2

判定：

Management Address
→ 一致

Capability / 役割
→ 不一致

Platform
→ 不一致

シナリオ6：LLDPのPort IDがMAC Address形式

資料：

隣接機器側ポート
→ Ethernet1/1

LLDP：

Port ID Subtype
→ MAC Address

Port ID
→ 00aa.bbcc.ddee

この時点では文字列を直接比較しません。

Port Description

などを追加確認し、資料の隣接機器側ポートへ対応付け可能か判断します。

シナリオ7：LLDP未表示だが隣接機器側送信未確認

資料：

隣接機器
→ SW2

LLDP：

SW2
→ 表示なし

確認済み：

自機器側受信
→ 有効

未確認：

隣接機器側送信
→ 不明

判定：

確認情報不足

です。

資料不一致を確定しません。

シナリオ8：エントリはあるがインターフェースはダウン

CDP：

隣接機器
→ SW2

インターフェース：

Gi1/0/24
→ down/down

Holdtime：

残りあり

判定：

古いエントリの可能性
↓
現在の接続証拠として即確定しない

です。

シナリオ9：LLDPは見えないがCDPでは一致

資料：

SW1 Gi1/0/24
↓
SW2

LLDP：

隣接機器
→ 表示なし

CDP：

Device ID
→ SW2

Local Intrfce
→ Gi1/0/24

判定：

LLDP
→ 確認情報不足

CDP
→ 資料を補強する直接接続確認情報

と分けます。

シナリオ10：CDPとLLDPの識別情報が一致

CDP：

Device ID
→ SW2

LLDP：

System Name
→ SW2

資料：

隣接機器
→ SW2

判定：

隣接機器識別
→ CDPとLLDPの両方で一致

です。

シナリオ11：CDPとLLDPで隣接機器側ポート表現が異なる

CDP：

Port ID
→ GigabitEthernet1/0/1

LLDP：

Port ID Subtype
→ Local

Port ID
→ 1

Port Description
→ GigabitEthernet1/0/1

この場合、Port Descriptionを使えば同じ隣接機器側ポートへ対応付けられる可能性があります。

単純なPort ID文字列一致だけで不一致にしません。

シナリオ12：エンドツーエンド到達性まで証明しようとする

資料：

SW1
↓
SW2
↓
Router
↓
Server

CDPで、

SW1
↓
SW2

が資料どおりでも、

Server アプリケーション
→ 正常

とは証明していません。

隣接機器発見情報の証拠範囲を超えています。

シナリオ13：リンクBだけを直接補強する

資料：

リンクA
SW1 Gi1/0/8
↓
SW2

リンクB
SW1 Gi1/0/9
↓
SW3

CDP：

Local Intrfce
→ Gi1/0/9

Device ID
→ SW3

この観測が直接補強するのは、

リンクB

です。

Gi1/0/8のリンクAまで同時に確認したとは扱いません。

シナリオ14：古いエントリを再観測する

前回：

隣接機器
→ SW2

現在：

インターフェース
→ down/down

エントリ：

まだSW2が残る

確認：

Holdtime

時間経過後の再観測

を使い、現在性を確認します。

よくある誤り

隣接機器が表示されないだけで資料不一致にする

隣接機器発見プロトコルの利用条件が未確認なら、確認情報不足の可能性があります。

識別情報が一致したら全項目一致とする

自機器側ポート、隣接機器側ポート、Capability、Platform、Management Addressなどは別項目です。

隣接機器側ポートだけ異なるのに全項目不一致にする

観測した不一致は隣接機器側ポートだけとして記録し、ほかの一致項目は保持します。

Port IDがMAC形式なのに直接隣接機器側ポート名と比較する

Port ID SubtypeやPort Descriptionを確認します。

Management Address一致だけで接続全体を一致にする

管理アドレスと接続ポート・役割・機種は別項目です。

Holdtime中のエントリを現在のリンク証拠にする

現在のインターフェース状態とエントリの更新状況を確認します。

CDPが見えるのでLLDP送信も有効と考える

CDPとLLDPは別プロトコルです。

LLDPが見えないので物理リンク断と決める

LLDP受信・送信条件が不成立でも隣接情報は見えません。

CDPとLLDPの文字列が違うだけで不一致にする

同じ意味の項目か、識別子形式が同じかを確認します。

CDPやLLDPでエンドツーエンド到達性まで証明する

隣接機器発見情報は直接隣接機器確認を中心に使います。

問題での判断パターン

パターン1：最初に何をするか問われる

直接接続リンクを特定
↓
比較する項目を決める

を選びます。

パターン2：隣接機器が表示されない

プロトコル利用条件
↓
自機器側条件
↓
隣接機器側条件

を確認し、未確認なら確認情報不足とします。

パターン3：自機器側ポートを比較する

CDP：

Local Intrfce

LLDP：

Local Intf

を自機器側ポートとして比較します。

パターン4：隣接機器側ポートを比較する

CDP：

Port ID

LLDP：

Port ID
+
Port ID Subtype
+
必要ならPort Description

を利用します。

パターン5：隣接機器識別を比較する

CDP：

Device ID

LLDP：

System Name

Chassis ID

を利用します。

パターン6：役割や機種を比較する

Capability
→ 役割

Platform
→ 機種

として分けます。

パターン7：管理IPを比較する

Management Address

を対応する管理情報項目へ使います。

パターン8：1項目だけ異なる

異なる項目だけ不一致

として記録し、他項目の一致は保持します。

パターン9：必要条件が未確認

確認情報不足

として追加確認へ進みます。

パターン10：エントリはあるがインターフェースダウン

Holdtime
↓
古いエントリの可能性

を考えます。

パターン11：CDPとLLDPが同じ内容を示す

同じ項目の確認情報を相互補強

として利用できます。

パターン12：アプリケーション到達性を問われる

CDP / LLDPだけでは直接証明しない

と判断します。

検証結果の記録例

資料：

隣接機器
SW2

自機器側ポート
Gi1/0/24

隣接機器側ポート
Gi1/0/1

役割
Switch

Platform
C9300

管理IP
10.0.0.2

観測：

Device ID
SW2

Local Intrfce
Gi1/0/24

Port ID
Gi1/0/2

Capability
Switch

Platform
C9300

Management Address
10.0.0.2

記録：

隣接機器識別
→ 一致

自機器側ポート
→ 一致

隣接機器側ポート
→ 不一致

役割
→ 一致

Platform
→ 一致

Management Address
→ 一致

このように、資料全体へ1つだけの判定を付けるのではなく、項目ごとの結果を残します。

確認情報不足の記録例

資料：

隣接機器
→ SW2

LLDP：

SW2
→ 表示なし

確認済み：

自機器側インターフェース
→ up/up

自機器側LLDP受信
→ 有効

未確認：

隣接機器側LLDP送信
→ 不明

記録：

隣接機器識別
→ 確認情報不足

追加確認
→ 隣接機器側LLDP送信

これなら、証拠不足を資料不一致へ誤変換しません。

CDPとLLDPを併用する基本手順

同じ直接接続リンクで両方利用できる場合は、

CDP
↓
Device ID
Local Intrfce
Port ID
Capability
Platform

LLDP
↓
System Name
Local Intf
Port ID
Port ID Subtype
System Capabilities
Management Address

のように、意味が対応する項目を比較します。

一致する項目は相互補強へ利用できます。

異なる形式の項目は、意味を対応付けてから比較します。

ネットワーク資料検証の基本手順

実際の判断は次の順で整理します。

1. 検証する直接接続リンクを特定
2. 比較する項目を決める
3. CDP / LLDPを利用できる条件を確認
4. 隣接機器識別を比較
5. 自機器側ポートを比較
6. 隣接機器側ポートを比較
7. Capability / Platformを比較
8. Management Addressを比較
9. 各項目を一致 / 不一致 / 確認情報不足へ分類
10. Holdtimeとインターフェース状態から情報の現在性を確認
11. 必要ならCDPとLLDPを相互補強に使う
12. 隣接機器発見情報の証拠範囲を超えていないか確認

まとめ

CDPやLLDPによるネットワーク資料検証では、最初に検証する直接接続リンクと比較項目を決めます。

次に、

隣接機器識別

自機器側ポート

隣接機器側ポート

Capability

Platform

Management Address

をそれぞれ対応する観測情報と比較します。

判定は、

一致

不一致

確認情報不足

の3つを使い分けます。

隣接機器が表示されないだけで資料不一致と決めず、CDPやLLDPの利用条件を確認します。

また、Holdtime中に古い隣接エントリが残る場合があるため、現在のインターフェース状態や再観測を使って情報の現在性を確認します。

CDPとLLDPの両方が利用できる場合は、同じ直接接続リンクについて一致する項目を相互補強に使えます。ただし、どちらも直接隣接機器情報を中心とした証拠であり、ACL、ルーティングポリシー、エンドツーエンドのアプリケーション到達性まで直接証明するものではありません。