Wenn LLDP nicht wie erwartet funktioniert, bekommt man leider standardmäßig sehr wenig Informationen vom lldpd. In diesem Artikel soll gezeigt werden, wie man an Fehlermeldungen von lldpd kommt. Außerdem sollen die Behandlung von Fehlern bei lldpd kurz besprochen werden.
Der lldpd wird beim Booten des Virtual-I/O-Servers über das Skript /etc/rc.vnet gestartet (Eintrag in der /etc/inittab). Der lldpd läuft als Dienst unter Kontrolle des System Resource Controllers SRC. Für das Troubleshooting empfiehlt es sich den lldpd-Dienst zu beenden und den Daemon manuell zu starten. Der Daemon besitzt einige nicht dokumentierte Optionen, darunter auch die Optionen „-d“ und „-v“. Die Option „-d“ erlaubt es den Daemon im Vordergrund zu starten. Die Option „-v“ ist nur gültig bei Verwendung der Option „-d“ und sorgt für eine Ausgabe von Meldungen (insbesondere Fehlermeldungen) des lldpd über die Standard-Ausgabe:
/usr/sbin/lldpd [-A] [-d [-v]] -A Akzeptieren aller unterstützten LLDP-Multicast-Adressen -d im Vordergrund starten (Debugging) -v Meldungen auf Standard-Ausgabe
Meldungen des lldpd werden standardmäßig über syslog (Facility daemon) mitprotokolliert. Über den SRC wird der lldpd per default ohne Argumente gestartet.
Wir stoppen den Dienst zunächst und starten dann den Daemon mit den Optionen „-d –v“ manuell auf der Kommandozeile. Hierzu werden root-Rechte benötigt (oem_setup_env):
padmin > oem_setup_env # stopsrc -s lldpd 0513-044 The lldpd Subsystem was requested to stop. # lldpd -d -v lldpd: 0810-013 starting lldpd lldpd: 0810-016 waiting for incoming message or signal …
In einem zweiten Fenster starten wir eine Abfrage nach der Liste der Ports auf denen LLDP verwendet wird:
padmin> oem_setup_env # lldpctl show portlist lldpctl: 0812-001 lldpd is currently not managing any ports #
Auf unserem System wird im Moment auf keinem Port LLDP verwendet. Interessant ist die Ausgabe des lldpd:
lldpd: 0810-024 unix domain connection received lldpd: 0810-016 waiting for incoming message or signal lldpd: 0810-020 unix domain message received lldpd: 0810-070 received GETPORTLIST request lldpd: 0810-016 waiting for incoming message or signal
Man kann in der Ausgabe sehen, das über einen Unix-Domain Socket (/var/run/lldpdsock), eine Verbindung aufgebaut wird und die Liste der Ports abgefragt wird (GETPORTLIST).
Als nächstes aktivieren wir LLDP auf dem Shared Ethernet Adapter ent15. Das kann dauerhaft über Setzen des Attributs lldpsvc=yes und das Kommando lldpsync gemacht werden, oder manuell über das Kommando lldpctl:
# lldpctl add ent15 lldpctl: 0812-005 successfully added port ent15 #
Auch hier werfen wir einen kurzen Blick auf die Ausgabe des lldpd:
lldpd: 0810-024 unix domain connection received lldpd: 0810-016 waiting for incoming message or signal lldpd: 0810-020 unix domain message received lldpd: 0810-076 received ADDPORT request lldpd: 0810-023 sending LLDPDU on port ent15 lldpd: 0810-079 port ent15 added successfully lldpd: 0810-016 waiting for incoming message or signal …
Auch hier sieht man wieder eine Verbindung über den Unix-Domain Socket und zusätzlich das Hinzufügen des Ports (ADDPORT). Außerdem wird dann sofort von dem lldpd ein LLDP-Paket gesendet.
Einige Sekunden später sollte dann auch schon vom angebundenen Switch ein oder mehrere LLDP-Pakete gekommen sein, hier die zugehörige Ausgabe des lldpd:
lldpd: 0810-016 waiting for incoming message or signal lldpd: 0810-022 LLDPDU received on port ent15 lldpd: 0810-040 processing frame lldpd: 0810-043 neighbor LLDPDU is valid lldpd: 0810-047 updating existing neighbor lldpd: 0810-048 starting rxInfoTTL timer (120 seconds) on port ent15 lldpd: 0810-008 checking EVB status
Der Switch sollte damit nun auf dem Virtual-I/O-Server bekannt sein! Wir überprüfen dies, indem wir die Nachbar-Information mit dem Kommando lldpctl abfragen:
# lldpctl show neighbor ent15 MSAP: XX:XX:XX:XX:XX:XX Eth101/1/5 Received on port: ent15 TLVs: Chassis ID: XX:XX:XX:XX:XX:XX (MAC address) Port ID: Eth101/1/5 (locally assigned) TTL: 120 Port Description: Ethernet101/1/5 System Name: switch01 System Description: Cisco Nexus Operating System (NX-OS) Software 9.2(2) ... #
Wie die Ausgabe zeigt, handelt es sich in diesem Fall um einen Cisco Switch. Die Meldungen des lldpd aufgrund des Kommandos sind die folgenden:
lldpd: 0810-016 waiting for incoming message or signal lldpd: 0810-020 unix domain message received lldpd: 0810-073 received GETNEIGHBOR request
Als nächstes schauen wir uns einen Fall an, bei dem LLDP nicht erfolgreich aktiviert werden kann. Wir zeigen dies am Beispiel eines weiteren Shared Ethernet Adapters, ent10. Auch hier aktivieren wir zunächst wieder manuell LLDP auf dem Adapter:
# lldpctl add ent10 lldpctl: 0812-005 successfully added port ent10 #
Das sieht zunächst ganz gut aus, und auch die Meldungen von lldpd stimmen zuversichtlich:
lldpd: 0810-024 unix domain connection received lldpd: 0810-016 waiting for incoming message or signal lldpd: 0810-020 unix domain message received lldpd: 0810-076 received ADDPORT request lldpd: 0810-023 sending LLDPDU on port ent10 lldpd: 0810-079 port ent10 added successfully
Wartet man allerdings einige Zeit (maximal 2 Minuten), und versucht dann die Informationen zum Nachbarn (Switch) anzeigen zu lassen, bekommt man die folgende Fehlermeldung:
# lldpctl show neighbor ent10 lldpctl: 0812-003 failed to get neighbor information on port ent10 lldpctl: 0812-013 neighbor information is not available for port ent10 #
Eine Möglichkeit ist natürlich das der Switch keine LLDP-Pakete versendet. In dem Fall gibt es natürlich auch keine Informationen über den Switch mittels LLDP.
Wir schauen uns die Ausgabe des lldpd an und finden dort in regelmäßigen Abständen die folgenden Meldungen für ent10:
lldpd: 0810-016 waiting for incoming message or signal lldpd: 0810-022 LLDPDU received on port ent10 lldpd: 0810-040 processing frame lldpd: 0810-050 not sent to LLDP multicast address lldpd: 0810-042 frame was discarded
Ein LLDP-Paket ist offensichtlich eingetroffen (LLDPDU received on port ent10), wurde verarbeitet (processing frame) und dann verworfen (frame was discarded), da es nicht an die LLDP Multicast-Adresse gesendet wurde.
Wir schauen uns die LLDP-Pakete auf dem Shared Ethernet Adapter ent10 mit tcpdump genauer an. Dazu bringen wir das zugehörige Interface zunächst „up“:
# chdev -l en10 -a state=up en10 changed #
Um dann tcpdump auf dem Interface starten zu können. Wir interessieren uns hier nur für LLDP Pakte (Typ/Proto ist dann 0x88cc):
# tcpdump -i en11 -e -n -v ether proto 0x88cc tcpdump: WARNING: BIOCPROMISC: Operation not supported on socket tcpdump: listening on en11, link-type EN10MB (Ethernet), capture size 262144 bytes 12:19:43.103134 XX:XX:XX:XX:XX:XX > 01:80:c2:00:00:0e, ethertype LLDP (0x88cc), length 345: LLDP, length 331 Chassis ID TLV (1), length 7 Subtype MAC address (4): XX:XX:XX:XX:XX:XX Port ID TLV (2), length 12 Subtype Local (7): Eth120/1/17 Time to Live TLV (3), length 2: TTL 120s Port Description TLV (4), length 16: Ethernet120/1/17 System Name TLV (5), length 25: switch13 System Description TLV (6), length 149 Cisco Nexus Operating System (NX-OS) Software\0x0aTAC support: http://www.cisco.com/tac\0x0aCopyright (c) 2002-2014, Cisco Systems, Inc. All rights reserved. System Capabilities TLV (7), length 4 System Capabilities [Bridge] (0x0004) Enabled Capabilities [Bridge] (0x0004) Management Address TLV (8), length 12 Management Address length 5, AFI IPv4 (1): X.X.X.X Interface Index Interface Numbering (2): 83886080 …
Der Switch sendet die LLDP-Pakete an die Multicast-Adresse 01:80:c2:00:00:0e, der lldpd-Daemon erwartet die Pakete standardmäßig allerdings über die Multicast-Adresse 01:80:c2:00:00:00. Eine Anfrage beim IBM Support ergab, das der lldpd-Daemon mit der (nicht dokumentierten) Option „-A“ dazu gebracht werden kann auch die Multicast-Adresse 01:80:c2:00:00:0e zu berücksichtigen. Wir probieren dies gleich aus, indem wir den lldpd stoppen (Control-C) und dann erneut starten und zusätzlich die Option „-A“ angegeben:
(Control-C) # lldpd -d -v -A lldpd: 0810-013 starting lldpd lldpd: 0810-016 waiting for incoming message or signal
Wie vorhin, fügen wir den Adapter ent10 wieder manuell zur Portliste hinzu:
# lldpctl add ent10 lldpctl: 0812-005 successfully added port ent10 #
Nach kurzer Zeit kommt dann auch vom lldpd-Daemon die Meldung über eingehende LLDP-Pakete und diesmal dann auch die Bestätigung das diese gültig sind:
lldpd: 0810-016 waiting for incoming message or signal lldpd: 0810-022 LLDPDU received on port ent10 lldpd: 0810-040 processing frame lldpd: 0810-043 neighbor LLDPDU is valid lldpd: 0810-047 updating existing neighbor lldpd: 0810-048 starting rxInfoTTL timer (120 seconds) on port ent10 lldpd: 0810-008 checking EVB status
Wir stoppen tcpdump und entfernen das Interface en10 wieder:
# rmdev -l en10 en10 Defined #
Da der lldpd-Daemon beim Booten per SRC gestartet wird, fügen wir das Argument “-A” für den lldpd in der ODM hinzu:
# chssys –s lldpd –a –A 0513-077 Subsystem has been changed. #
Das Problem sollte damit behoben sein. Wir stoppen den interaktiv gestarteten lldpd-Daemon und aktivieren lldpd wieder über den SRC:
(Control-C) Beenden des lldpd # startsrc -s lldpd 0513-059 The lldpd Subsystem has been started. Subsystem PID is 23396416. # ps -ef|grep lldpd root 21954710 22609950 0 12:36:33 pts/0 0:00 grep lldpd root 23396416 7209188 0 12:36:28 - 0:00 /usr/sbin/lldpd -A #
Der lldpd-Daemon wurde jetzt mit der Option „-A“ gestartet.
Für alle Shared Ethernet Adapter bei denen LLDP verwendet werden soll, sollte das Attribute lldpsvc=yes gesetzt werden. Diese werden dann beim Booten automatisch dem lldpd-Daemon bekannt gemacht:
# chdev –l ent10 –a lldpdvc=yes ent11 changed #
Mit dem Kommando lldpsync kann man die so konfigurierten Shared Ethernet Adapter aber auch manuell beim lldpd-Daemon registrieren:
# lldpsync #
(Bei neueren IOS-Versionen reicht schon das Setzen des Attributes, das Starten von lldpsync ist dann nicht notwendig.)
# lldpctl show portlist ent15 ent10 #