This topic is to discuss the following lesson:
I’m on a 2960 and the Port Description only shows the interface name e.g. “GigabitEthernet0/1”, instead of the description. Any ideas why?
Hi Laura,
What about the Port ID? does it show anything? I’ve seen some examples where the port ID and port description were swapped.
Rene
Port id shows the interface as Gi0/1. so basically im getting the remote int info but not the description.
Hmm it might be related to the IOS version then. On my 3560 it worked out of the box after enabling LLDP globally and setting a description on the interface.
for the record, im running IOS 12.2(50)
Hi Lazaros,
Would you please explain TLVs in detail?
And how end devices (like IP phones) use LLDP for VLAN assignment or PoE requirements?
Hello Muhammad
A Type Length Value (TLV) is an encoding scheme used to add optional additional elements within a communications protocol. It is a general scheme that is used for various protocols, including LLDP. Each TLV, as its name suggests, includes three fields:
- Type code - this is a code that is used to specify what kind of information is included in this TLV. For example, for LLDP, a code of 2 means the TLV contains information about the Port ID.
- Length - This value indicates the length of the field containing the value, in bytes.
- Value - this field contains the value of the TLV. If the Type code is 2, then you can expect to see the Port ID in this field.
TLVs for LLDP exist within the LLDP frame structure. Each TLV consists of a 7 bit type field, a 9 bit Length field, and a 0 to 511 bit Value field, depending on the type of TLV. Below is an example of an LLDP frame:
There are four mandatory TLVs that all LLDP packets must carry, and these are seen in the above image. These are:
- Chassis ID TLV, type 1
- Port ID TLV type 2
- TTL TLV type 3
- End of LLDP PDU type 0 (this TLV always goes at the end to indicate the end of the frame).
In between, there may be additional optional TLVs added. Various such types of optional TLVs include Port description, System name, System description, System capabilities, and management address. Custom TLVs can also be created, using type number 127 where each vendor can specify their own information within the value field.
Now LLDP itself does not contain the capability of negotiating additional information such as PoE management and VLAN assignments, and this capability was added as an enhancement known as Media Endpoint Discovery or MED, resulting in the enhanced protocol LLDP-MED.
The MED enhancement has been standardized by the Telecommunications Industry Association in standard number ANSI/TIA-1057. In the following image, you can see a wireshark capture of an LLDP-MED frame which includes the four additional facilities of negotiation, including media, network policy, location ID and PoE negotiation. The PoE negotiation information is expanded in the image, and information such as power type, power source and power priority, which are exchanged between devices, can clearly be seen.
I hope this has been helpful!
Laz
2 Likes
Hello team,
Please clarify me how to configure an interface to accept LLDP packets without enabling the interface to send the LLDP packets?
Thanks
Hello Boris
LLDP is a protocol whose purpose is to exchange information between devices at Layer 2. As such, in order for it to function correctly, it must have bidirectional communication between devices. LLDP has no configuration parameters that would enable an interface to accept LLDP frames but not to send them.
However, if you want to, you can use a MAC address access list and block outbound traffic to the 01:80:c2:00:00:0e MAC address which is the multicast destination MAC address used by LLDP.
A similar functionality is available on Cisco small business series switches where, if LLDP is disabled globally on a switch, you can either configure it for LLDP flooding, which floods and forwards all LLDP frames received out of all ports, or LLDP filtering, which blocks all LLDP frames. More info about this can be found here, but I’m not sure that this is really what you were looking for.
If this information doesn’t address your concern, can you tell us a little more about what you actually want to achieve with such a configuration and why? That way we can also discuss alternatives to what you need or want.
I hope this has been helpful!
Laz
2 Likes
Hello Laz,
Thank you for explanation. I’ve read a question below about LLDP:
Which command configures an interface to accept LLDP packets without enabling the interface to
send the packet?
possible answers:
- lldp receive
- lldp transmit
- lldp tlv-select
I want to understand what is the right answer and why. Please clarify me.
Thanks
Hello Boris
I stand corrected. I haven’t actually used LLDP in a production environment, so I was not aware of these configuration parameters, so thank you for the heads up. It seems that LLDP can be enabled or disabled globally on a switch by issuing the lldp run command in global configuration mode. If you do this, then you don’t need to configure anything at the interface level by default, as receive, transmit, and tlv-select are all enabled by default.
However, once globally enabled, if you choose to adjust the operation of LLDP at the interface level, you can disable either the sending, or the receiving of LLDP packets by issuing the following commands, respectively: no lldp transmit, no lldp receive.
The lldp tlv-select command is used with additional parameters to specify which TLVs should be enabled or disabled. Enabling takes place without the “no” before the command while disabling is done with the “no”. For example, the following command disables the LLDP TLV for sharing the system name of a device:
no lldp tlv-select system-name
This way you can selectively choose what information is actually exchanged using LLDP.
Now to get to your question, it does seem a bit odd. This is because Cisco documentation seems to indicate that you must first enable LLDP globally in order for it to function. I’ve also tested it on lab equipment as well. I tried keeping LLDP globally disabled, and applied only the lldp receive command on an interface. When I attempted to view LLDP neighbors, I got a response saying “LLDP is not enabled”.
In order to achieve what the question is asking for, you must first enable LLDP globally, and then disable transmit like so:
Device(config)#lldp run
Device(config)#interface fastethernet 0/0
Device(config-if)#no lldp transmit
This would result in what the question is asking for. I just tried this, and the device that only receives LLDP packets does indeed detect a neighbour, while the other one has zero neighbour entries, since it is not receiving anything.
I hope this has been helpful!
Laz
3 Likes
Hello Laz,
Great explanation! Thank you very much.
1 Like
Hello,
I hope I am in the right forum. How can I use lldp to determine the IP address of the neighbor in the same way as with show cdp neighbor detail
Hello Carsten
By default, LLDP doesn’t share the IP address of the device with LLDP neighbors. As can be seen in this lesson, the default information is specific:
However, LLDP uses various attributes that can be shared, which contain specific values and descriptions. These are referred to as TLVs or Type Length Values. In order for a device to share IP addresses or other parameters, you must enable this capability using the lldp med-tlv-select command, and specify which TLVs you want to share. What can be shared is platform and IOS specific, so you will find that various platofrms have different options here.
You can see what is available for the Catalyst 3560 for example, in the following Cisco documentation:
I hope this has been helpful!
Laz