ドキュメント負債
静的なドキュメントは嘘をつきます。年に数ラック以上のペースで成長するインフラにおいて、事務作業は真っ先に形骸化するものです。ぼやけたVisioの図面を凝視したり、Excelシートをあさったりした挙句、3ヶ月も前に誰にも知らせずサーバーの接続ポートが変更されていたことに気づく……そんな経験は数え切れません。物理的な配線こそが唯一の真実であるという状況では、手動の更新は負け戦です。
6ヶ月前、私は手動の構成図作成を完全に廃止しました。代わりにlldpdをベースにした自動検出システムを導入しました。このセットアップは、本番環境の数百のノードで一度もクラッシュすることなく稼働しています。LLDP（Link Layer Discovery Protocol）やCDP（Cisco Discovery Protocol）といったレイヤー2の検出プロトコルを使用することで、Linuxサーバーは自身の正確な場所を報告するようになります。接続先のスイッチ、使用しているポート、さらには管理用IPアドレスまで特定できるのです。
クイックスタート：5分で近接機器を確認する
ネットワークの可視性を高める最も手っ取り早い方法は、lldpdデーモンを使用することです。他にもツールはありますが、lldpdは非常に軽量（消費メモリ10MB未満）で、LLDP、CDP、FDP、SONMPなどほぼすべてのプロトコルに対応しているため、私はこれを好んで使っています。
1. インストール
DebianまたはUbuntuシステムの場合：
sudo apt update
sudo apt install lldpd -yRHEL、CentOS、またはAlmaLinuxの場合：
sudo dnf install epel-release -y
sudo dnf install lldpd -y2. 有効化と起動
sudo systemctl enable --now lldpd3. 近接機器の確認
デーモンが最初のパケット交換を行うまで30秒ほど待ちます。その後、以下のコマンドを実行します：
lldpcli show neighborsLLDPまたはCDPが有効なマネージドスイッチに接続されている場合、以下のような詳細情報が表示されます：
Interface: eth0, via: LLDP, RID: 1, Time: 0 day, 00:01:24
Chassis:
ChassisID: mac 00:25:90:7a:bc:de
SysName: Core-Switch-01
SysDescr: Cisco Nexus Operating System (NX-OS) Software
MgmtIP: 10.10.50.1
Capability: Bridge, Router
Port:
PortID: ifname Ethernet1/12
PortDescr: Server-Rack-A1-Node-05
VLAN: 100トポロジ検出の仕組み
レイヤー2の検出プロトコルは、IPアドレスを気にしません。これらは通常30秒おきに、小さなフレームをブロードキャストすることで動作します。これらのフレームにはType-Length-Value（TLV）ユニット、つまりホストの識別情報を含む小さなデータパケットが含まれています。これはデータリンク層で行われるため、サーバーのインターフェースにIPアドレスが割り当てられていなくても検出が可能です。
LLDP vs. CDP：なぜ両方使うのか？
LLDPは業界標準（IEEE 802.1AB）です。Arista、Juniper、HPなどの主要ベンダーはすべてこれをサポートしています。一方、CDPはCisco独自のレガシープロトコルです。私がlldpdを選ぶ理由は、その「バイリンガル」な性質にあります。古いCisco機器からのCDPフレームをキャプチャしつつ、同時に他の機器とはLLDPで通信できます。これにより、ハードウェアの更新時における「ベンダーロックイン」の悩みが解消されます。
lldpcliの威力
lldpcliツールは、バックグラウンドデーモンの管理インターフェースとして機能します。通常は自動化して使用しますが、トラブルシューティングの際には対話モードが非常に役立ちます。例えば、ケーブルの不良やポートチャネルの設定ミスが疑われる場合は、次を実行します：
lldpcli watchこれにより、検出イベントがライブで表示されます。ネットワークエンジニアがVLANを変更したりケーブルを差し替えたりすると、その更新内容がリアルタイムで画面に反映されます。より詳細なパケットレベルの調査が必要な場合は、tcpdumpによるパケット解析と組み合わせると、問題の切り分けがさらに効率化されます。
インベントリの自動化
1台のサーバーをマッピングするのは単なるテクニックですが、500台のサーバーをマッピングするのは「変革」です。このデータを大規模に活用するには、人間が読むテキスト形式から構造化データへと移行する必要があります。
JSONエクスポート
lldpcliにはJSON出力機能が組み込まれています。これは自動化スクリプトの基盤として最適です：
lldpcli -f json show neighborsPythonによる簡単な統合
私は、このデータをNetBoxや中央監視データベースに送るために、小さなPythonラッパーを使用しています。ネットワーク機器への接続自動化をさらに発展させたい場合は、PythonとNetmikoによるネットワーク自動化も参照してください。以下は、近接機器の情報を解析する基本的なスクリプトです：
import subprocess
import json
def get_network_neighbors():
try:
# コマンドを実行し、JSON出力をキャプチャする
result = subprocess.run(['lldpcli', '-f', 'json', 'show', 'neighbors'],
capture_output=True, text=True)
data = json.loads(result.stdout)
# lldpdのJSON構造をたどる
interfaces = data.get('lldp', {}).get('interface', {})
for iface_name, details in interfaces.items():
neighbor = details.get('chassis', [{}])[0]
port = details.get('port', [{}])[0]
print(f"インターフェース {iface_name} は {neighbor.get('name')} のポート {port.get('id')} に接続されています")
except Exception as e:
print(f"LLDPデータの解析エラー: {e}")
if __name__ == "__main__":
get_network_neighbors()データセンターの現場から学んだ教訓
1. 構成情報を漏洩させない
LLDPがパブリックなインターネットに公開されると、セキュリティリスクになります。内部の命名規則や管理用IPが、回線の反対側にいる誰にでもブロードキャストされてしまうからです。lldpdは必ず内部インターフェースのみに制限してください。設定で簡単に制限できます：
# 管理用およびバックエンドのNICのみで待受ける
sudo lldpcli configure system interface pattern eth1,eth22. 仮想化の罠
LLDPパケットは通常、Linuxブリッジで遮断されます。KVMやDockerを実行している場合、物理スイッチからは仮想マシンが見えず、仮想マシンからもスイッチが見えません。私の推奨は、フレームをゲスト仮想マシンにパススルーしようとするのではなく、ハイパーバイザーホスト自体でlldpdを実行することです。
3. 「沈黙する」スイッチへの対処
もしlldpcli show neighborsの結果が空であれば、スイッチ側に原因がある可能性が高いです。アンマネージド（非インテリジェント）スイッチはこれらのプロトコルをサポートしていません。Ciscoのハードウェアでは、グローバルコンフィギュレーションモードでlldp runを使用して明示的に有効にする必要がある場合があります。
4. NMSへの接続
オプションのSNMPサブエージェントを有効にすることで、LibreNMSやZabbixなどのツールが自動的にLLDPデータを取得できるようになります。これにより、ネットワーク全体の自己修復型マップが作成されます。ケーブルが移動すると、マップは数分以内に自動的に更新されます。
lldpdへの切り替えは、私のチームの障害対応のあり方を変えました。「これはどのポートだ？」と問いかけるのをやめ、すぐに問題の修正に取り掛かれるようになったのです。20分かかっていた手動の追跡作業が、わずか2秒のコマンド実行に変わりました。本番環境の障害において、ネットワーク障害のトラブルシューティングにかかる時間は「わずかな瞬き」か「重大なインシデント」かの分かれ目になります。
