Протокол обнаружения сетевых устройств на канальном уровне

Примеры

lldp eth0 mgmtip 192.168.103.35

 LLDP Local info on eth0
+---------------+-------------------------------------------------------------+
| ChassisID:    | IW-173332 (local)                                           |
| SysName:      | Lmn.6                                                       |
| SysDescr:     | Infinet Wireless R5000 WANFleX H11S01-MINTv1.90.29          |
| Caps:         | Repeater*, Bridge*, Router*                                 |
| PortID:       | 00:04:35:02:A5:14 (mac)                                     |
| PortDescr:    | eth0, Lmn.6                                                 |
| MFS:          | 1728 bytes                                                  |
| MgmtIP:       | 192.168.103.35                                              |
+---------------+-------------------------------------------------------------+

lldp forward enable

 LLDP Neighbors Table on eth0
+---------------+-------------------------------------------------------------+
|                     LLDP Mode: TxRx,  Forward: enabled                      |
+---------------+-------------------------------------------------------------+
| ChassisID:    | IW-220750 (local)                                           |
| SysName:      | Omx.3                                                       |
| SysDescr:     | Infinet Wireless R5000 WANFleX H08S01-MINTv1.90.29          |
| Caps:         | Repeater*, Bridge*, Router*                                 |
| PortID:       | 00:04:35:03:5E:4E (mac)                                     |
| PortDescr:    | eth0, Omx.3                                                 |
| MFS:          | 1728 bytes                                                  |
| MgmtIP:       | 192.168.103.36, 10.10.10.16                                 |
| Last report:  | 26 seconds ago, TTL 180 seconds, Age 01:04:58               |
+---------------+-------------------------------------------------------------+
| ChassisID:    | IW-260061 (local)                                           |
| SysName:      | Lmn.5                                                       |
| SysDescr:     | Infinet Wireless R5000 WANFleX H11S01-MINTv1.90.29          |
| Caps:         | Repeater*, Bridge*, Router*                                 |
| PortID:       | 00:04:35:03:F7:DD (mac)                                     |
| PortDescr:    | eth0, Lmn.5                                                 |
| MFS:          | 1728 bytes                                                  |
| MgmtIP:       | 192.168.103.37, 10.10.10.14                                 |
| Last report:  | 25 seconds ago, TTL 181 seconds, Age 01:04:57               |
+---------------+-------------------------------------------------------------+
| ChassisID:    | 00:04:35:07:A8:39 (mac)                                     |
| SysName:      | XG.6                                                        |
| SysDescr:     | XG WANFleX H12S10v1.7.1 IW-501817                           |
| Caps:         | Repeater*, Bridge*                                          |
| PortID:       | ge0 (local)                                                 |
| PortDescr:    | ge0, XG.6                                                   |
| MFS:          | 1728 bytes                                                  |
| MgmtIP:       | 10.10.10.13, 192.168.103.39                                 |
| Last report:  | 41 seconds ago, TTL 183 seconds, Age 01:04:56               |
+---------------+-------------------------------------------------------------+
| ChassisID:    | 00:04:35:07:A8:3A (mac)                                     |
| SysName:      | XG.5                                                        |
| SysDescr:     | XG WANFleX H12S10v1.7.1 IW-501818                           |
| Caps:         | Repeater*, Bridge*                                          |
| PortID:       | ge0 (local)                                                 |
| PortDescr:    | ge0, XG.5                                                   |
| MFS:          | 1728 bytes                                                  |
| MgmtIP:       | 192.168.103.38, 10.10.10.12                                 |
| Last report:  | 40 seconds ago, TTL 183 seconds, Age 01:04:54               |
+---------------+-------------------------------------------------------------+
| ChassisID:    | F8:F0:82:73:C0:3B (mac)                                     |
| PortID:       | 37 (local)                                                  |
| Last report:  | 17 seconds ago, TTL 120 seconds, Age 01:04:46               |
+---------------+-------------------------------------------------------------+

Discussion

There are both mandatory and optional LLDP TLVs defined. All compliant LLDP Data Units (LLDPDUs) must contain at a minimum the following four mandated TLVs in the following order :

• Chassis ID TLV (Type = 1)
• Port ID TLV (Type = 2)
• Time To Live TLV (Type = 3)
• End of LLDPDU TLV (Type = 0)

If the LLDPDU includes optional TLVs they will be inserted between the Time To Live TLV and End of LLDPDU TLV.

Optional TLVs include the Basic set of TLVS and the Organizationally Specific TLVS.

Besides the four mandated TLVs listed above the Basic set of LLDP TLVs also includes:

• Port Description TLV (Type = 4)
• System Name TLV (Type = 5)
• System Description TLV (Type = 6)
• System Capabilities TLV (Type = 7)
• Management Address TLV (Type = 8)

Organizationally Specific TLVs

The LLDP specification allows for various organizations to define and encode their own TLVs. These are called Organizationally Specific TLVs. All Organizationally Specific TLVs start with an LLDP TLV Type value of 127.

Organizationally Specific TLV (Type = 127)

The length field of an Organizationally Specific TLV is followed by a 3 octet (24 bit) organizationally unique identifier (OUI) value which is then followed by a 1 octet organizationally defined subtype.

The following organizations have published Organizationally Specific TLVs:

• 00-80-c2 — IEEE 802.1
• 00-12-0F — IEEE 802.3
• 00-12-BB — TIA TR-41 Committee — Media Endpoint Discovery (LLDP-MED, ANSI/TIA-1057)
• 00-0E-CF — PROFIBUS International (PNO) Extension for PROFINET discovery information
• 30-B2-16 — Hytec Geraetebau GmbH Extensions

LLDP specification defines the following set of IEEE 802.1 Organizationally Specific TLVs reference(02-Dec-2011):

• Port VLAN ID TLV (OUI = 00-80-c2, Subtype = 1)
• Port And Protocol VLAN ID TLV (OUI = 00-80-c2, Subtype = 2)
• VLAN Name TLV (OUI = 00-80-c2, Subtype = 3)
• Protocol Identity (OUI = 00-80-c2, Subtype = 4)
• VID Usage Digest (OUI = 00-80-c2, Subtype = 5)
• Management VID (OUI = 00-80-c2, Subtype = 6)
• Link Aggregation (OUI = 00-80-c2, Subtype = 7)
• Congestion Notification (OUI = 00-80-c2, Subtype = 8)
• ETS Configuration TLV (OUI = 00-80-c2, Subtype = 9)
• ETS Recommendation TLV (OUI = 00-80-c2, Subtype = A)
• Priority-based Flow Control Configuration TLV (OUI = 00-80-c2, Subtype = B )
• Application Priority TLV (OUI = 00-80-c2, Subtype = C)
• EVB TLV (OUI = 00-80-c2, Subtype = D)
• CDCP TLV (OUI = 00-80-c2, Subtype = E)
• Port extension TLV (OUI = 00-80-c2, Subtype = F)

Annex G of the LLDP specification defines the following set of IEEE 802.3 Organizationally Specific TLVs:

• MAC/PHY Configuration/Status TLV (OUI = 00-12-0f, Subtype = 1)
• Power Via MDI TLV (OUI = 00-12-0f, Subtype = 2)
• Link Aggregation TLV (OUI = 00-12-0f, Subtype = 3)
• Maximum Frame Size TLV (OUI = 00-12-0f, Subtype = 4)

The Telephone Industry Association specification ANSI/TIA-1057 (April 2006) defines the LLDP-MED specific TLVs. The formal LLDP-MED specification is freely available for download at:

TIA Online

The LLDP-MED specification defines the following set of TIA Organizationally Specific TLVs:

• LLDP-MED Capabilities TLV (OUI = 00-12-BB, Subtype = 1)
• Network Policy TLV (OUI = 00-12-BB, Subtype = 2)
• Location Identification TLV (OUI = 00-12-BB, Subtype = 3)
• Extended Power-via-MDI TLV (OUI = 00-12-BB, Subtype = 4)
• Inventory — Hardware Revision TLV (OUI = 00-12-BB, Subtype = 5)
• Inventory — Firmware Revision TLV (OUI = 00-12-BB, Subtype = 6)
• Inventory — Software Revision TLV (OUI = 00-12-BB, Subtype = 7)
• Inventory — Serial Number TLV (OUI = 00-12-BB, Subtype = 8)
• Inventory — Manufacturer Name TLV (OUI = 00-12-BB, Subtype = 9)
• Inventory — Model Name TLV (OUI = 00-12-BB, Subtype = 10)
• Inventory — Asset ID TLV (OUI = 00-12-BB, Subtype = 11)

The following links include some information regarding LLDP-MED.

XXX — Probably LLDP-MED section should be expanded and moved to seperate Wiki page.

The LLDP specification defines the following set of Hytec Organizationally Specific TLVs (Homepage: www.hytec.de, protocol documentation: HYTEC):

• Transceiver TLV (OUI = 30-B2-16, Subtype = 1)
• Trace TLV (OUI = 30-B2-16, Subtype = 2)

[править] Описание протокола

Каждое устройство, на котором включен LLDP, отправляет информацию о себе соседям независимо от того, отправляет ли сосед информацию о себе.
При обмене сообщениями LLDP, не используется механизм запрос/ответ.

Устройство, использующее LLDP, хранит информацию о соседях, но не перенаправляет её дальше (независимо от того поддерживает ли устройство протокол LLDP).

Каждое устройство хранит информацию о соседях в MIB.
Поэтому эта информация может использоваться различными управляющими хостами с помощью протокола SNMP.

Например, ProCurve Manager использует информацию LLDP для построения топологии сети и сбора инвентарной информации.

Информация об устройстве, которая может передаваться с помощью LLDP:

• Имя устройства (System Name),
• Описание устройства (System Description),
• Идентификатор порта (Port ID),
• Описание порта (Port Description),
• Возможности устройства (System Capabilities),
• Управляющий адрес (Management Address),
• и др.

Принципы работы

Несколько коммутаторов на которых включен LLDP

Протокол работает только между непосредственно присоединенными устройствами.
Это значит, что, например, на рисунке:

• Коммутатор sw4 получит LLDP-информацию от двух соседей core_sw (через два порта) и sw5400;
• Коммутатор core_sw получит LLDP-информацию только от sw4 (но через оба порта);
• Коммутатор sw5400 получит LLDP-информацию только от sw4.

Сообщения LLDP могут передаваться через порты, которые заблокированы STP, но не передаются через порты, которые заблокированы 802.1X.

Формат кадра LLDP

Сообщения LLDP инкапсулируются в Ethernet-кадр и передаются через все активные линки.

Для LLDP зарезервирован multicast MAC-адрес — 01:80:C2:00:00:0E.
Это специальный зарезервированный MAC-адрес, который предполагает, что коммутаторы, получившие кадр с таким адресом получателя, не будут его передавать дальше.

LLDP передает информацию в сообщениях, которые называются LLDP Data Unit (LLDPDU).

В сообщениях LLDP содержатся несколько TLV (Type, Value, Length):

• Type — описывает тип информации, которая передается этой частью сообщения (7 бит);
• Length — размер поля Value (9 бит);
• Value — описывает определенную характеристику устройства.

LLDPDU состоит как минимум из четырёх обязательных TLV полей:

Формат LLDP Data Unit (LLDPDU)

• Chassis ID TLV (Type = 1);
• Port ID TLV (Type = 2);
• Time To Live TLV (Type = 3);
• End of LLDPDU TLV (Type = 0).

Между обязательными TLV (после первых трёх и перед последним) могут размещаться другие (опциональные) TLV, например:

• Port Description TLV (Type = 4);
• System Name TLV (Type = 5);
• System Description TLV (Type = 6);
• System Capabilities TLV (Type = 7).

[править] CDP на коммутаторах ProCurve

Коммутаторы ProCurve поддерживают протоколы LLDP и CDP.
Однако, LLDP-сообщения они могут и генерировать и принимать, а CDP — только принимать.

Настройки CDP на коммутаторе (по умолчанию CDP включен):

sw4(config)# sh cdp

 Global CDP information

  Enable CDP  : Yes (Receive Only)            


  Port CDP     
  ---- --------
  1    ennbled 
  2    enabled 
  3    enabled 
...
  23   enabled 
  24   enabled 

Информация о соседях CDP:

sw4(config)# sh cdp neighbors 

 CDP neighbors information

  Port Device ID                     | Platform                     Capability 
  ---- ----------------------------- + ---------------------------- -----------
  1    sw1                           | Cisco IOS Software, C3550... S          

Более подробная информация о соседях CDP:

sw4(config)# sh cdp neighbors detail 

 CDP neighbors information

  Port : 1   
  Device ID : sw1                                                           
  Address Type : IP          
  Address      : 192.168.25.207                                              
  Platform     : Cisco IOS Software, C3550 Software (C3550-IPSERVICESK9-M...
  Capability   : Switch                                                     
  Device Port  : FastEthernet0/11                                           
  Version      : Cisco IOS Software, C3550 Software (C3550-IPSERVICESK9-M...

Чистая загрузка

Некоторые пользователи утверждают, что они исправили проблемы с DNS, выполнив чистую загрузку. По их мнению, определенные сторонние службы мешали DNS, и после их обнаружения и отключения ошибка была устранена. Для выполнения чистой загрузки сделайте следующее:

• Нажмите «Windows + R» и введите «msconfig».
• Когда откроется окно «Настройки системы», зайдите в закладку «Services».
• Выберите «Скрыть все службы Майкрософт» и кликните на «Отключить все».
• Нажмите «Применить» и «ОК».

После перезагрузки компьютера работать будут исключительно службы Microsoft. Если ошибка не повторяется, значит ее причина – в одной из тех служб, которые вы прежде отключили.

Parameters

-AddressScope

Specifies an array of neighbor scopes of the adapter for which this cmdlet enables the LLDP agent.
The acceptable values for this parameter are:

• NearestNeighbor
• NearestNonTpmrBridge
• NearestCustomerBridge

-AsJob

Runs the cmdlet as a background job. Use this parameter to run commands that take a long time to complete.

The cmdlet immediately returns an object that represents the job and then displays the command prompt.
You can continue to work in the session while the job completes.
To manage the job, use the cmdlets.
To get the job results, use the Receive-Job cmdlet.

For more information about Windows PowerShell background jobs, see about_Jobs.

-CimSession

Runs the cmdlet in a remote session or on a remote computer.
Enter a computer name or a session object, such as the output of a New-CimSession or Get-CimSession cmdlet.
The default is the current session on the local computer.

-Confirm

Prompts you for confirmation before running the cmdlet.

-InputObject

Specifies the input to this cmdlet.
You can use this parameter, or you can pipe the input to this cmdlet.

-InterfaceIndex

Specifies an array of indexes of interfaces for which this cmdlet enables LLDP.

-NetAdapterName

Specifies an array of names of the interfaces for which this cmdlet enables LLDP.

-PassThru

Returns an object representing the item with which you are working.
By default, this cmdlet does not generate any output.

-ThrottleLimit

Specifies the maximum number of concurrent operations that can be established to run the cmdlet.
If this parameter is omitted or a value of is entered, then Windows PowerShell calculates an optimum throttle limit for the cmdlet based on the number of CIM cmdlets that are running on the computer.
The throttle limit applies only to the current cmdlet, not to the session or to the computer.

-WhatIf

Shows what would happen if the cmdlet runs.
The cmdlet is not run.

Compatibility with older kernels

If you have a kernel older than Linux 2.6.39, you need to compile
lldpd with to enable some compatibility functions:
otherwise, lldpd will only rely on Netlink to receive bridge, bond and
VLAN information.

For bonding, you need 2.6.24 (in previous version, PACKET_ORIGDEV
affected only non multicast packets). See:

Otherwise, a packet received on a bond will be affected to all
interfaces of the bond. In this case, lldpd will affect a received
randomly to one of the interface (so a neighbor may be affected to the
wrong interface).

On 2.6.27, we are able to receive packets on real interface for enslaved
devices. This allows one to get neighbor information on active/backup
bonds. Without the 2.6.27, lldpd won’t receive any information on
inactive slaves. Here are the patchs (thanks to Joe Eykholt):

On FreeBSD, only a recent 9 kernel (9.1 or more recent) will allow to
send LLDP frames on enslaved devices. See this bug report for more
information:

http://www.freebsd.org/cgi/query-pr.cgi?pr=138620

Some devices (notably Cisco IOS) send frames tagged with the native
VLAN while they should send them untagged. If your network card does
not support accelerated VLAN, you will receive those frames as long as
the corresponding interface exists (see below). However, if your
network card handles VLAN encapsulation/decapsulation (check with
), you need a recent kernel to be able to receive those
frames without listening on all available VLAN. Starting from Linux
2.6.27, lldpd is able to capture VLAN frames when VLAN acceleration is
supported by the network card. Here is the patch:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bc1d0411b804ad190cdadabac48a10067f17b9e6

On some other versions, frames are sent on VLAN 1. If this is not the
native VLAN and if your network card support accelerated VLAN, you
need to subscribe to this VLAN as well. The Linux kernel does not
provide any interface for this. The easiest way is to create the VLAN
for each port:

You can check both cases using tcpdump:

If the first command does not display received LLDP packets but the
second one does, LLDP packets are likely encapsulated into a VLAN:

In this case, just create VLAN 1 will fix the situation. There are
other solutions:

1. Disable VLAN acceleration on the receive side () but this may or may not work. Check if there are
   similar properties that could apply with .
2. Put the interface in promiscuous mode with .

The last solution can be done directly by (on Linux only) by
using the option .

On modern networks, the performance impact should be nonexistent.

LLDP Support in a Cluster Setup

In a cluster setup, the NetScaler GUI and NetScaler CLI display the LLDP neighbour configuration of all or specific cluster nodes when the GUI or CLI is accessed through the Cluster IP address (CLIP). Any change made to the global level LLDP mode is applied to the global level LLDP mode on each of the cluster nodes.

Consider an example of a cluster setup of three nodes, NS1, NS2, and NS3. Each of these nodes are connected to both routers Router-1 and Router-2. The following output is displayed when the show lldp neighbor -summary operation is performed on the Cluster CLI that is accessed through the Cluster IP address (CLIP) of the cluster setup. The output shows the LLDP neighbour information of all these nodes.