LLDP

このページのゴール

Link Layer Discovery Protocol（LLDP）の出力から、直接接続された隣接機器の識別情報、自機器側インターフェース、隣接機器側ポート、機器の役割、管理情報を正しい方向で読み取れるようにします。

LLDPは特定ベンダー専用の仕組みとして扱わず、異なるベンダーの機器が混在する環境でも利用できる標準ベースの隣接機器発見プロトコルとして理解します。

さらに、LLDPでは送信と受信を別々に制御できるため、「自機器から相手が見える条件」と「相手から自機器が見える条件」が同じとは限りません。隣接機器が表示されない場合には、物理リンク、LLDP全体状態、自機器側受信、相手機器側送信を方向付きで切り分けます。

このページで学ぶこと

• LLDPで直接確認できる隣接範囲
• ベンダー非依存の隣接機器発見という位置付け
• 自機器側インターフェースの読み方
• Chassis IDとSystem Nameによる隣接機器識別
• Port IDを隣接機器側のポート識別子として読む方法
• Port IDをPort ID Subtypeと組み合わせて解釈する方法
• System CapabilitiesとManagement Addressの利用方法
• LLDP全体状態の確認方法
• LLDP送信と受信を方向別に考える方法
• 隣接機器が表示されない場合の切り分け
• Holdtimeと残存エントリの解釈
• LLDP-MEDの位置付け

LLDPは直接接続された隣接機器を発見する

LLDPはリンク上で隣接情報を交換するためのプロトコルです。

基本的な確認範囲は、

自機器
↓
直接接続された隣接機器

です。

次の接続を考えます。

SW1 Gi1/0/24
      |
      |
SW2 Gi1/0/1

SW1でLLDP隣接情報を確認すると、直接接続されたSW2の情報を取得できます。

2ホップ先を自機器のLLDPだけで直接発見したとは扱わない

次の接続を考えます。

SW1
 |
SW2
 |
SW3

SW1から見た直接隣接はSW2です。

SW1
↓
SW2

SW3はSW2を越えた先にあります。

SW1
↓
SW2
↓
SW3

SW1の通常のLLDP隣接情報だけから、SW3をSW1の直接隣接機器として扱いません。

IP到達性とLLDP隣接は別の意味

ある機器へIP通信できることと、その機器がLLDPで直接隣接していることは別の条件です。

IP到達可能
→ レイヤ3経路を通って到達している可能性がある

LLDP隣接情報
→ 直接接続リンク上で受信した隣接情報

したがって、IPアドレスへ到達できるからといって、LLDP上の直接隣接であるとは判断しません。

LLDPはベンダー非依存の隣接機器発見に利用できる

LLDPは特定ベンダーだけに限定された隣接機器発見として扱いません。

たとえば次のような組み合わせでも、双方がLLDPを実装し適切に送受信していれば隣接情報交換を利用できます。

Ciscoスイッチ
      |
      |
他ベンダースイッチ

Ciscoスイッチ
      |
      |
他ベンダーIP電話

Ciscoスイッチ
      |
      |
他ベンダーネットワーク機器

Cisco機器同士でもLLDPを利用できる

ベンダー非依存であることは、

Cisco機器では使わない

という意味ではありません。

Cisco機器同士でもLLDPを利用できます。

Cisco SW1
   |
   |
Cisco SW2

LLDP利用可能

「マルチベンダー環境で使える」と「Cisco機器同士では使えない」を混同しないことが重要です。

show lldp neighborsで隣接機器を要約表示する

代表的な確認コマンドは次です。

show lldp neighbors

代表的な出力イメージを考えます。

Device ID           Local Intf      Hold-time  Capability      Port ID
SW2                 Gi1/0/24        120        B,R             Gi1/0/1
PHONE-01            Gi1/0/15        115        T                00aa.bbcc.ddee

機種やソフトウェアによって表示形式は異なり得ますが、重要なのは項目の方向と意味です。

要約表示では項目を方向付きで読む

要約出力では、少なくとも次のように整理します。

隣接機器の識別
→ Device ID

自機器側ポート
→ Local Intf

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

残存時間
→ Hold-time

隣接機器の機能
→ Capability

Local IntfとPort IDを逆に読まないことが特に重要です。

Local Intfは自機器側のインターフェース

SW1で次の出力を得たとします。

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

この場合、

Local Intf
→ SW1 Gi1/0/24

です。

コマンドを実行した機器がSW1なら、Local IntfはSW1側です。

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

同じ出力で、

Port ID
→ Gi1/0/1

なら、これは隣接機器SW2が広告したポート識別子です。

接続関係は、

SW1 Gi1/0/24
      |
      |
SW2 Gi1/0/1

と読みます。

Local IntfとPort IDを逆にしない

出力：

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

正しい読み方：

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

誤った読み方：

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

まず、

Local
→ 自機器側

Port ID
→ 隣接機器側

と方向を固定してから値を読みます。

Chassis IDは隣接機器の筐体識別に使う

LLDP詳細情報ではChassis IDを確認できます。

例：

Chassis id: 0011.2233.4455

Chassis IDは隣接LLDPエージェントの筐体を識別する情報です。

機器名と同じ文字列が必ず表示されるとは限らないため、

Chassis ID
→ 筐体識別情報

として読みます。

System Nameは隣接機器名の照合に使える

LLDP詳細情報にSystem Nameが含まれる場合があります。

System Name: SW-ACCESS-02

ネットワーク資料に、

隣接機器名
→ SW-ACCESS-01

とあるなら、

System Name
→ SW-ACCESS-02

との不一致を確認できます。

System Nameはポート識別子ではなく、隣接機器の識別情報として扱います。

Chassis IDとSystem Nameは同じ情報ではない

両方とも隣接機器識別に役立ちますが、意味は同じではありません。

Chassis ID
→ 筐体を識別する値

System Name
→ 隣接機器のシステム名

たとえばChassis IDがMACアドレス形式で、System Nameがホスト名形式になることがあります。

片方だけを見て、もう片方の項目まで一致したと扱いません。

show lldp neighbors detailで詳細情報を確認する

より詳しい情報が必要なら、代表的に次を使用します。

show lldp neighbors detail

代表的な出力イメージ：

------------------------------------------------
Local Intf: Gi1/0/24
Chassis id: 0011.2233.4455
Port id: Gi1/0/1
Port Description: GigabitEthernet1/0/1
System Name: SW2

System Capabilities: B,R
Enabled Capabilities: B
Management Addresses:
    IP: 10.0.0.2

Time remaining: 108 seconds

ここでは、要約表示だけでは判断しにくい識別情報、ポート説明、機器能力、管理アドレスなどを確認できます。

詳細表示でも自機器側と隣接機器側を分ける

詳細表示でも方向は変わりません。

Local Intf
→ 自機器側

Port id
→ 隣接機器側が広告したポート識別子

例：

Local Intf: Gi1/0/24
Port id: Gi1/0/1

なら、

自機器
→ Gi1/0/24

隣接機器
→ Gi1/0/1

です。

Port IDは必ずインターフェース名になるとは限らない

LLDPのPort IDは、隣接機器側ポートを識別するための値です。

しかし、必ず次のようなインターフェース名になるとは限りません。

Gi1/0/1

たとえば、

00aa.bbcc.ddee

のようなMACアドレス形式や、数値などのローカル識別子として見える場合があります。

したがって、

Port ID
→ 必ずインターフェース名

とは判断しません。

Port ID Subtypeで識別子形式を解釈する

Port IDを正しく読むには、その識別子がどの種類として広告されているかを意識します。

概念的には、

Port ID
+
Port ID Subtype
↓
識別子の意味

です。

たとえば、

Port ID
→ 00aa.bbcc.ddee

のような値を見たとき、MACアドレス形式として広告されているなら、

インターフェース名ではない

と判断できます。

Port ID Subtypeが違えば見た目も変わり得る

同じ「隣接機器側ポートを識別する」という目的でも、広告される形式は異なり得ます。

インターフェース名形式

MACアドレス形式

ローカル識別子形式

などです。

そのため、見た目だけで意味を決めず、Port ID Subtypeが確認できる場合は組み合わせて解釈します。

数値Port IDをそのままインターフェース名へ変換しない

ネットワーク資料が、

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

としているのに、LLDPで、

Port ID
→ 48

と見えたとします。

このとき、

48
→ Gi1/0/48

と機械的に変換して一致と判断しません。

Port ID SubtypeやPort Descriptionなど追加情報を確認して対応付けます。

Port Descriptionは隣接機器側ポートの補助情報になる

詳細表示にPort Descriptionが含まれる場合があります。

Port id: 48
Port Description: GigabitEthernet1/0/48

このような場合、

Port ID
→ 48

Port Description
→ GigabitEthernet1/0/48

を組み合わせることで、隣接機器側ポートの対応を判断しやすくなります。

System Capabilitiesは隣接機器の役割確認に使う

LLDP詳細情報にはSystem Capabilitiesが含まれる場合があります。

例：

System Capabilities: B,R
Enabled Capabilities: B

ネットワーク資料に、

役割
→ スイッチ

と記録されているなら、隣接機器が広告する機能情報を照合材料として利用できます。

System Capabilitiesだけで機器名や接続ポートまで決めないことが重要です。

Capabilityは識別情報とは別に扱う

次の情報は役割が異なります。

System Name
→ 隣接機器名

Chassis ID
→ 筐体識別情報

System Capabilities
→ 機器機能

したがって、

System Name一致
→ Capabilityも一致

とは判断しません。

各項目を別々に読みます。

Management Addressは管理情報の照合に使う

LLDP詳細表示に管理アドレスが含まれる場合があります。

Management Addresses:
    IP: 10.10.10.2

ネットワーク資料に、

管理アドレス
→ 10.10.10.2

とあれば、この項目を照合できます。

ただし、

Management Address一致
→ 接続ポートも一致

ではありません。

Local Intf、Port ID、System Nameなどは別々に確認します。

管理アドレスをPort IDとして読まない

Management Addressは管理情報です。

Management Address
→ 管理用アドレス

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

という違いがあります。

管理アドレスが表示されていても、それを隣接機器側ポート名の代わりとして使いません。

LLDP全体の状態を確認する

隣接機器がどのインターフェースにも表示されない場合、LLDP全体の状態を確認します。

代表的な確認コマンド：

show lldp

環境により表示形式は異なりますが、LLDP全体が動作対象になっているかを判断する手掛かりになります。

lldp runは装置全体のLLDP有効化に関係する

Cisco IOS系では、装置全体のLLDP有効化に代表的に次を使用します。

lldp run

無効化された構成では、

no lldp run

となり得ます。

隣接機器が一切表示されない場合は、個別ポートだけを見る前に装置全体の状態も確認します。

全ポートで隣接機器が見えないときは全体状態を早く確認する

次の状況を考えます。

Gi1/0/1
→ 隣接機器なし

Gi1/0/2
→ 隣接機器なし

Gi1/0/3
→ 隣接機器なし

複数ポートの物理リンクがアップしているのにLLDP隣接情報が一切ないなら、

装置全体のLLDP状態

を早い段階で確認します。

3本すべての相手機器情報が同時に誤っていると即断しません。

LLDP送信と受信は別々の方向条件

LLDPでは送信と受信を分けて考えることが重要です。

Cisco IOS系では、インターフェース単位で代表的に、

lldp transmit

lldp receive

を扱います。

送信と受信は別条件です。

自機器Aが相手機器Bを学習する条件

AがBをLLDP隣接機器として学習するには、学習方向を次のように考えます。

B
LLDP送信
↓
リンク
↓
A
LLDP受信

必要な方向条件は、

B側送信
+
A側受信

です。

A側送信だけが有効でも、AはBの広告情報を受信できません。

相手機器Bが自機器Aを学習する条件

逆方向は別条件です。

A
LLDP送信
↓
リンク
↓
B
LLDP受信

必要なのは、

A側送信
+
B側受信

です。

したがって、

AからBが見える

ことと、

BからAが見える

ことは独立して考えます。

双方向で互いに学習する条件

双方が互いを隣接機器として学習するには、両方向の送受信が成立する必要があります。

A送信
→ B受信

B送信
→ A受信

つまり概念的には、

A
送信 有効
受信 有効

B
送信 有効
受信 有効

が必要です。

片方向だけ隣接情報が見える状態はあり得る

たとえば、

A
送信 有効
受信 無効

B
送信 無効
受信 有効

なら、

A → B
広告可能

ですが、

B → A
広告されない

ため、BはAを学習できてもAはBを学習できない可能性があります。

lldp transmitを停止した場合の方向

インターフェースで、

no lldp transmit

となっている側は、そのインターフェースからLLDP広告を送信しません。

Aが、

no lldp transmit

なら、B側が受信可能でもAの情報はBへ届きません。

A送信
→ 停止

B受信
→ 有効

でも、BはAから新しいLLDP広告を受信できません。

lldp receiveを停止した場合の方向

インターフェースで、

no lldp receive

となっている側は、そのインターフェースでLLDP広告を受信しません。

Aが、

no lldp receive

なら、Bが送信していてもAはBを学習できません。

B送信
→ 有効

A受信
→ 停止

なので学習方向が成立しません。

送信と受信を逆に考えない

「AからBが見えない」という症状で確認する方向は、

A送信
+
B受信

ではありません。

AがBを学習したいので、

A受信
+
B送信

です。

この方向を先に固定すると、不要な設定変更を避けやすくなります。

インターフェース単位のLLDP状態を確認する

特定ポートだけ隣接機器が表示されない場合は、そのポートのLLDP状態を確認します。

代表的なコマンド：

show lldp interface

環境によっては対象インターフェースを指定して確認します。

show lldp interface GigabitEthernet1/0/10

送信と受信を別々に確認することが重要です。

他ポートが正常なら対象ポートへ絞る

次の状況を考えます。

Gi1/0/1
→ LLDP隣接機器あり

Gi1/0/2
→ LLDP隣接機器あり

Gi1/0/10
→ LLDP隣接機器なし

この場合、装置全体のLLDPが完全停止している可能性は下がります。

次に、

Gi1/0/10の物理状態

Gi1/0/10のLLDP受信状態

相手機器側ポートのLLDP送信状態

へ対象を絞ります。

隣接機器が見えない原因を1つに固定しない

LLDP隣接情報が表示されない原因は複数あります。

物理リンクが成立していない

LLDP全体が無効

自機器側の受信が無効

相手機器側の送信が無効

相手機器がLLDPを送信していない

などです。

「隣接機器なし」という結果だけで資料誤りを確定しません。

隣接機器不在の基本確認順

自機器Aから相手機器Bが見えない場合は、次の順で整理します。

対象リンクを特定
↓
物理リンク状態
↓
LLDP全体状態
↓
A側受信状態
↓
B側送信状態
↓
必要なら識別情報を再確認

方向付きで確認することが重要です。

物理リンクがアップでもLLDP隣接情報がない場合がある

次の状態は両立し得ます。

物理リンク
→ up

LLDP隣接情報
→ なし

たとえば、

自機器側受信
→ 無効

または、

相手機器側送信
→ 無効

なら、物理リンクが正常でもLLDP隣接情報は得られません。

LLDP隣接情報があるだけで現在のリンクアップを断定しない

逆方向の注意も必要です。

LLDPエントリ
→ あり

でも、

物理リンク
→ down

という状態が一時的にあり得ます。

Holdtimeによる既存エントリ残存を考えます。

Holdtimeは隣接情報の保持時間として読む

LLDPでは受信した隣接情報が一定時間保持されます。

概念的には、

LLDP広告受信
↓
隣接情報を保持
↓
保持時間中に新しい広告を受信
↓
保持時間を更新

です。

新しい広告を受信できなくなった場合、

保持時間満了
↓
古い隣接情報を削除

という流れを考えます。

Holdtimeの秒数そのものを目的にしない

重要なのは、

何秒か

を丸暗記することではなく、

既存エントリは一定時間残存し得る

という挙動です。

試験問題では、物理リンク状態とLLDPエントリの現在性を分けて考えられることが重要です。

リンクダウン直後にエントリが残る場合がある

次の状態を考えます。

show interfaces
→ Gi1/0/7 down/down

一方、

show lldp neighbors
→ Gi1/0/7の隣接機器エントリあり

なら、

現在もリンクアップ

と判断せず、

Holdtime中の残存エントリ

を疑います。

Local Intfと物理状態を対応付ける

LLDPエントリに、

Local Intf
→ Gi1/0/7

とあるなら、現在性を確認するときは自機器のGi1/0/7を調べます。

LLDP Local Intf
↓
自機器の対象インターフェース
↓
現在のインターフェース状態

Port IDを自機器側ポートとして確認しないようにします。

残存エントリと現在の隣接関係を分ける

ネットワーク資料を更新するときも、

LLDPエントリがある

だけで現在の配線を確定しません。

必要なら、

物理インターフェース状態

Holdtime

新しい広告を受信しているか

を組み合わせて現在性を判断します。

System Name不一致は機器識別の不一致として扱う

資料：

隣接機器
→ SW-ACCESS-01

LLDP詳細表示：

System Name: SW-ACCESS-02

この場合は、

隣接機器名
→ 不一致

と判断します。

Local IntfやPort IDまで同時に不一致と決めるのではなく、項目ごとに扱います。

System CapabilitiesとManagement Addressは別項目

詳細表示：

System Capabilities: B
Management Addresses:
    IP: 10.10.10.2

この2つは別の目的で使います。

System Capabilities
→ 機器機能の確認

Management Address
→ 管理情報の確認

一方が一致したからといって、もう一方まで一致とは扱いません。

LLDP-MEDはLLDPの拡張として認識する

LLDP-MEDは、音声・メディア端末などに関連する追加情報を交換できるLLDPの拡張として認識します。

このページでは、

LLDP-MED
→ 音声・メディア端末向けの追加情報を扱える拡張

という位置付けを押さえます。

LLDP-MEDが見えても物理リンク現在性を自動確定しない

LLDP-MED関連情報が表示されていても、

LLDP-MED情報あり
→ 現在も物理リンクが必ずup

とは判断しません。

LLDP隣接情報には保持時間があるため、現在性が必要なら物理インターフェース状態も確認します。

LLDP-MEDを見て音声VLAN設定全体を決め直さない

LLDP-MEDが音声・メディア端末向けの拡張であることと、

LLDP-MED情報が見える
↓
スイッチの音声VLAN設定を全面的に変更する

は同じではありません。

ここではLLDP-MEDを隣接確認を補助する拡張情報として扱います。

LLDP-MEDでレイヤ3経路全体を検証しない

LLDP-MEDもLLDPの隣接情報交換を拡張するものとして扱います。

LLDP-MED
→ ルータ越しの経路全体を直接発見

とは考えません。

基本は直接接続された隣接関係です。

シナリオ1：Ciscoスイッチ同士でLLDPを使う

接続：

Cisco SW1
   |
   |
Cisco SW2

判断：

Cisco同士
→ LLDP利用不可

ではありません。

双方でLLDPが適切に動作していれば利用できます。

シナリオ2：異なるベンダー間で隣接確認する

接続：

Ciscoスイッチ
      |
      |
他ベンダースイッチ

双方がLLDPを利用できるなら、

ベンダーが異なる
↓
LLDPで直接隣接情報を交換可能

と考えます。

シナリオ3：Local IntfとPort IDを読む

SW1で確認：

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

判断：

SW1側
→ Gi1/0/24

SW2側
→ Gi1/0/1

です。

シナリオ4：Port IDがMACアドレス形式

出力：

Port id: 00aa.bbcc.ddee

このとき、

Port id
→ 必ずインターフェース名

とは判断しません。

Port ID Subtypeが確認できるなら形式を確認し、必要に応じてPort Descriptionも利用します。

シナリオ5：数値Port IDを資料と照合する

資料：

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

LLDP：

Port id: 48
Port Description: GigabitEthernet1/0/48

判断：

Port idだけを機械的にインターフェース名へ変換

せず、

Port IDの形式
+
Port Description

を使って対応付けます。

シナリオ6：System Nameが資料と異なる

資料：

隣接機器名
→ SW-ACCESS-01

LLDP：

System Name: SW-ACCESS-02

判断：

隣接機器識別
→ 不一致

です。

シナリオ7：機器役割と管理アドレスを確認する

LLDP：

System Capabilities: B
Management Addresses:
    IP: 10.10.10.2

資料：

役割
→ スイッチ

管理アドレス
→ 10.10.10.2

役割と管理アドレスを、それぞれ対応する項目として照合します。

シナリオ8：全ポートで隣接機器が見えない

状態：

複数物理リンク
→ up

LLDP隣接情報
→ すべてなし

早い段階で確認する候補：

show lldp

装置全体でLLDPが有効かを確認します。

シナリオ9：1ポートだけ隣接機器が見えない

状態：

Gi1/0/1
→ 隣接機器あり

Gi1/0/2
→ 隣接機器あり

Gi1/0/10
→ 隣接機器なし

確認：

Gi1/0/10の物理状態

show lldp interface GigabitEthernet1/0/10

さらに、AからBが見えないなら、

A側受信

と、

B側送信

を確認します。

シナリオ10：Aで受信有効、Bで送信停止

状態：

A
lldp receive
→ 有効

B
lldp transmit
→ 無効

AがBを学習できるか考えます。

必要条件は、

A受信
+
B送信

なので、

B送信が無効
↓
AはBから新しいLLDP広告を受信できない

と判断します。

シナリオ11：A送信とB受信だけ有効

状態：

A送信
→ 有効

B受信
→ 有効

この条件で成立する方向は、

A
↓ 広告
B

です。

したがって、BがAを学習する方向には使えます。

AがBを学習するには、

B送信
+
A受信

が別に必要です。

シナリオ12：リンクダウン直後もLLDPエントリが残る

状態：

Gi1/0/7
→ down/down

show lldp neighbors
→ Gi1/0/7の隣接情報あり

判断：

Holdtime中の残存エントリ

を考慮します。

現在の物理リンク状態はGi1/0/7の実状態を優先して確認します。

シナリオ13：2ホップ先をLLDPで探そうとする

接続：

SW1
 |
Router
 |
SW3

SW1からSW3は直接接続ではありません。

SW1のLLDP
↓
通常の直接隣接としてSW3を学習

とは扱いません。

シナリオ14：LLDP-MED情報が表示されるIP電話

詳細表示でIP電話からLLDP-MED関連情報が広告されているとします。

判断：

LLDP-MED
→ 音声・メディア端末向け拡張情報

として隣接確認を補助します。

これだけで音声VLAN設定全体を再構成したり、レイヤ3経路を判断したりしません。

よくある誤り

LLDPは他ベンダー機器専用だと考える

ベンダー非依存であるため、Cisco機器を含む複数ベンダー環境で利用できます。

Cisco機器同士でも利用できます。

Local Intfを隣接機器側ポートだと考える

Local Intfはコマンドを実行した自機器側です。

Port IDを必ずインターフェース名だと考える

Port IDは隣接機器側のポート識別子です。

識別子形式はPort ID Subtypeにより異なり得ます。

Port IDの数値を勝手にポート名へ変換する

Port ID SubtypeやPort Descriptionを確認し、識別子の意味を判断します。

Management Addressを隣接機器側ポートとして読む

Management Addressは管理情報です。

ポート識別はPort IDなどを利用します。

AからBが見えないときA送信だけ確認する

AがBを学習する方向では、

A受信
+
B送信

を確認します。

物理リンクがupならLLDPも必ず見えると考える

LLDP全体状態、受信状態、相手送信状態により、リンクupでも隣接情報がない場合があります。

LLDPエントリがあればリンクupと考える

Holdtime中の残存エントリの可能性があります。

Holdtimeの秒数だけを暗記する

重要なのはエントリが一定時間残存し得ることです。

LLDP-MEDを音声VLAN設定そのものと考える

LLDP-MEDは追加情報を交換する拡張として認識します。

音声VLAN設定そのものと同一視しません。

問題での判断パターン

パターン1：LLDPの発見範囲を問われる

直接接続された隣接機器

を選びます。

2ホップ先や同一IPサブネット全体を直接発見する仕組みとして扱いません。

パターン2：ベンダー非依存性を問われる

標準ベース
↓
異なるベンダー間でも利用可能

と判断します。

Cisco機器同士でも利用できます。

パターン3：自機器側ポートを問われる

Local Intf
→ 自機器側

です。

パターン4：隣接機器側ポートを問われる

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

です。

パターン5：Port IDがMACアドレスや数値に見える

Port ID Subtype

を確認し、必要に応じて、

Port Description

も利用します。

パターン6：隣接機器名を問われる

System Name

や、

Chassis ID

を識別情報として利用します。

パターン7：役割と管理情報を問われる

System Capabilities
→ 機器機能

Management Address
→ 管理情報

と分けます。

パターン8：全ポートで隣接機器が見えない

LLDP全体状態

を早い段階で確認します。

パターン9：AがBを学習するための方向を問われる

A受信
+
B送信

です。

パターン10：リンクダウン直後もエントリがある

Holdtime
↓
残存エントリ

を考えます。

パターン11：LLDP-MEDの位置付けを問われる

音声・メディア端末向けの追加情報を扱えるLLDP拡張

として認識します。

確認コマンドと目的を対応させる

show lldp neighbors
→ 隣接機器の要約情報
→ Local Intf
→ Port ID
→ Capability
→ Hold-time

show lldp neighbors detail
→ Chassis ID
→ System Name
→ Port ID
→ Port Description
→ System Capabilities
→ Management Address
→ 詳細な隣接情報

show lldp
→ LLDP全体状態の確認

show lldp interface
→ インターフェース単位のLLDP状態
→ 送信・受信状態の確認

目的に応じてコマンドを使い分けます。

LLDP隣接情報を読む基本手順

LLDPを確認するときは、次の順に整理します。

確認対象の自機器を特定
↓
show lldp neighbors
↓
Local Intfで自機器側ポートを確認
↓
Port IDで隣接機器側識別子を確認
↓
必要ならPort ID Subtypeを確認
↓
System NameやChassis IDで隣接機器を確認
↓
System Capabilitiesで役割を確認
↓
Management Addressで管理情報を確認

Port IDがそのままポート名に見えない場合は、

Port ID Subtype
+
Port Description

も利用します。

隣接機器不在時の判断手順

自機器Aから相手機器Bが見えない場合は、

対象リンクを特定
↓
物理リンク状態
↓
LLDP全体状態
↓
A側受信
↓
B側送信
↓
必要なら反対方向も確認
↓
Holdtimeによる残存情報の有無を確認

と整理します。

重要なのは、

AがBを学習
→ A受信 + B送信

という方向です。

まとめ

LLDPは、直接接続された隣接機器の情報をベンダー非依存に交換できる隣接機器発見プロトコルです。

基本の読み方は、

Local Intf
→ 自機器側インターフェース

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

System Name
→ 隣接機器名

Chassis ID
→ 筐体識別情報

System Capabilities
→ 機器機能

Management Address
→ 管理情報

です。

Port IDは必ずインターフェース名になるとは限らないため、必要に応じてPort ID SubtypeやPort Descriptionを組み合わせます。

送受信方向では、

AがBを学習
→ A受信 + B送信

を基準にします。

隣接情報が見えない場合は、物理リンク、LLDP全体状態、自機器側受信、相手機器側送信を順に切り分けます。

また、LLDPエントリはHoldtime中に残存し得るため、エントリの存在だけで現在の物理リンクを断定しません。

LLDP-MEDは音声・メディア端末向けの追加情報を扱えるLLDP拡張として認識し、隣接機器情報の読み取りを補助するものとして扱います。