Media Endpoint Discovery is an enhancement of LLDP, known as LLDP-MED, that provides the following facilities:
Auto-discovery of LAN policies (such as VLAN, Layer 2 Priority and Differentiated services (Diffserv) settings) enabling plug and play networking.
Device location discovery to allow creation of location databases and, in the case of Voice over ...
802.1AB defines several (3) multicast addresses for LLDP that a compliant switch should not forward.
That said, an unmanaged switch with no specific handling for multicast will very likely treat LLDP (and any multicast traffic) as broadcast and spam it to every port.
LLDP is not a layer 2 equivalent of RIP.
RIP is a routing protocol, advertising routes between routers.
LLDP is a device discovery protocol, so neighboring devices can learn about each other.
Switches make their forwarding decisions independently, so there is no need to advertise MAC address tables between them.
Link Layer Discovery (IEEE-802.1AB-2005) provides the base capabilities for discovery, but was seen as insufficent for IP Telephony and Real Time Video. So the LLDP-MED initiative was formed by HP, Mitel and Avaya in 2004. What does LLDP-MED provide?
Interoperability > provide vendor independent management capabilities, enabling different convergence ...
You could ask why Windows, or MacOS, or linux supports LLDP. When you list the LLDP neighbors on your switch, where do you think it got that information?
LLDP has two parts: a sender, and a receiver. Devices that don't have an LLDP sending process will have nothing shown on the switch (an LLDP receiver.) Likewise, that device will know nothing of the switch ...
You can check the MAC address table on the switch to see on what port you learned the MAC address of the Fortigate's management interface.
It should be possible to enable LLDP on the Fortinet as of FortiOS 5.2 as well according to their documentation:
config system interface
set lldp-transmission enable
You can enable ...
LLDP-MED is an LLDP extension that is specifically aimed at IP phones. LLDP itself is extensively used to identify various network equipment, especially switches and routers.
In theory, LLDP extensions could be used to e.g. select the end node VLAN, but usually DHCP vendor extensions are used as DHCP is better suited: it uses a request-response model, so ...
No. A MAC address table is only relevant for the switch that has the table. The MAC address table relates a MAC address to the interface where it was seen. Switch A has no use to know that a MAC Address X was seen on Interface 1 of Switch B. Switch A does need to know that it has seen the MAC Address X on its own Interface 48 (possibly, Switch A's connection ...
It depends on the hardware involved. Juniper for example will drop the LLDP packets when there is no native VLAN configured (a VLAN in which all untagged traffic will be forwarded in).
Cisco for example will always send the LLDP tagged in VLAN 1. Juniper itself sends the LLDP untagged.
So it highly depends on your gear.
Without some level of administrative privilege, the short answer is that this is not possible with any degree of accuracy.
As you pointed out, using ping time and or packet loss is dubious at best. You cannot account for where the latency/loss is being introduced, so it is at best a very shaky guess without having some knowledge of the network architecture....
This depends on the switch in question and the extent of its SNMP MIB-mapped functions.
Usually, a switch would provide access to its MAC table (SAT) as well as to the LLDP data is has gathered.
A server is just another MAC node for a switch, so there's no special ways to query for those.
You might be able to access LLDP data through e.g. lldpRemSysName ...
LLDP is only transmitted on a connected link. Any further bridging or tunneling does not/should not (usually) forward LLDP packets. When normal communication is working but there's no LLDP reception there's something in between filtering it (or LLDP isn't sent out at all, check tx statistics).
Firstly, it does look very much like you have had a broadcast/multicast storm and an external loop would do it. So, some sort of mitigation with spanning tree, loop protection, multicast rate limiting sounds like a plan.
With LLDP, the packets are sent to addresses in the IEEE reserved multicast range, which should not be forwarded by an intermediate switch....
It's there in later versions. 15.0 supports it on my 2960S's. And yes, system-description is the TLV:
SysDescr: Cisco IOS Software, C2960S Software (C2960S-UNIVERSALK9-M), Version 15.0(2)SE3
I'm curious why the admins think hiding the IOS version is in any way a security enhancement?
[If I find the specific command reference that lists when it was ...
IEEE PoE commonly uses MDI negotiation first (PLC = physical layer classification) - to enable a PD to power up. The MDI uses signature resistors.
Often, MDI PoE is overridden by LLDP (MED) TLV (DLC = data link layer classification) once the device is powered up.
Whether MDI or LLDP have priority can be configured on most switches. Which current classes ...
LLDP is a "Link Layer Discovery Protocol". The protocol advertises itself on links, and populates its own database from other senders. Routers and or switches (or even your home PC) can be connected to each other, and exchange LLDP information.
A router understands "layer 2" as well as "layer 3". Routers, as you probably know, speaks arp, which is a "layer ...
You will need to add those VLANs to the Dell Switch. The commands to do so are likely the same (or you could try managing the device via the web browser which is likely easier if you are not comfortable.)
Once you have created those VLANs on the switch, you need to make sure the connection between the Dell and the HP is a trunk link. There are access ports ...
RIP is a routing protocol that is used, generally speaking, to connect new networks dynamically without adding routes at every routing point in the network. This is exclusively a Layer 3+ concept.
It wouldn't actually even make sense to distribute a CAM table. Any device within the L2 broadcast domain is permitted to have an entry for the same MAC address. ...
Trying to compare the two protocols is really comparing apples and oranges. They are two separate protocols for two separate jobs.
As Zac67 points out, LLDP is widely supported by business network devices, but it is limited to the link. It uses a layer-2 multicast address which will not be forwarded beyond the interface.
DLEP is used between a router and ...
I haven't seen a device supporting DLEP yet. LLDP is widely supported but only works on the link level, so it would discover only directly connected devices. LLDP messages from devices behind (802.1D compliant) switches will not reach you. However, given access to the discovered devices you could use SNMP to query their LLDP database and work your way ...
You would need some form of script to do this in a sane manner - it would need to log into the switch, check the LLDP neighbor and update the port description.
I question the point of this though, since you have this information in LLDP already, and it is automatically updated when someone re-patches their device, unlike the script method which would have ...
Summarizing the conversation of this post the command
interface GigabitEthernet 0/5
Was not doing anything since LLDP was enabled globally already. This would however allow you to disable LLDP on an interface and have it enabled on every other port. I don't see a huge use for enabling it on just one port other than being explicit but maybe someone else can ...
No. LLDP is a link protocol. Like the other link protocols, it only exists on the link, and it will not be forwarded to another link.
Specifically, LLDP is to tell you that information for other devices on the link. That fails if the information is forwarded to a different link.
I finally found a way to activate the CDP compatibility on a HP V1910-24G Switch:
> [MySwitch] lldp compliance cdp
And then I activate the cdp in the proper interfaces
> [interface 1] lldp compliance admin-status cdp txrx