With "-M 4", LLDP-MED should be transmitted only if remote device sent an LLDP-MED TLV

[davidmonro]

I was trying to configure lldpd to emit location information but as soon as I enabled LLDP-MED (using the -M flag) my switch (a TP-LINK SG2210P) stopped showing LLDP neighbour information, and started showing discarded packets in LLDP traffic statistics.

I know the switch can deal with LLDP-MED since it does for my phones. I then tried installing lldpad on a box and it also can transmit LLDP-MED info that the switch understands. I then had a look at tcpdump and noted the following in packets emitted by lldpd:

Organization specific TLV (127), length 7: OUI ANSI/TIA (0x0012bb)
  LLDP-MED Capabilities Subtype (1)
    Media capabilities [LLDP-MED capabilities, network policy, location identification, extended power via MDI-PSE, extended power via MDI-PD, Inventory] (0x003f)
    Device type [network connectivity] (0x04)
  0x0000:  0012 bb01 003f 04

where my box running lldpad emits packets like this:

Organization specific TLV (127), length 7: OUI ANSI/TIA (0x0012bb)
  LLDP-MED Capabilities Subtype (1)
    Media capabilities [LLDP-MED capabilities, Inventory] (0x0021)
    Device type [endpoint class 1] (0x01)
  0x0000:  0012 bb01 0021 01

So my working hypothesis is that my switch is unhappy with capabilities being advertised which aren't then present (and is it even valid to support MDI-PSE and MDI-PD on the same port?).

Current code just enables them all, and adds telephone if it is class3 (see around line 1900 in src/daemon/lldpd.c

Cheers

David

[vincentbernat]

LLDP-MED specs say this is what is supported by the device but not what is currently enabled. So, a device supporting both MDI-PSE and MDI-PD on the same port, not at the same time, seems plausible. Notably, page 39:

NOTE – There is no need to explicitly send the set of enabled capabilities, since the receiver will
detect what is enabled by the LLDP-MED TLVs it is receiving. Doing so would provide no additional
value and would complicate the frame validation rules in the event of a mismatch.

Could you modify the source code to only send "inventory" and check if things are better with your device this way?

[davidmonro]

OK I'm wrong. My switch doesn't object to the LLDP-MED data from the unmodified code as long as the device class is 1. As soon as I set it to other numbers it stops working again. Which is odd since it definitely works with class III endpoints as I get data from my phones. (I hadn't tested class 1, I first noticed the problem on openwrt which sets it to 4 by default). I'll keep digging.

[davidmonro]

Oh ick. The version on my openwrt machine doesn't work with -M 1 either. I've just realized that my testing isn't against current code, my ubuntu machine is using 0.9.9 and the openwrt one is 1.0.1. I'll have to try building against the git version and see what it does.

[vincentbernat]

I don't think there is any difference between the two versions with respect to LLDP-MED.

[davidmonro]

So building from git I can reproduce the "breaks if -M is set to 2, 3 or 4" scenario. I'm not sure how easy it will be for me to get a tcpdump from one of the phones (not sure I've got an external power supply for any of them so can't get them booted without plugging them into a PoE switch... which won't forward the packets!)

[davidmonro]

Progress. I can get the switch to be happy with -M 2 and -M 3 if I supply
configure med policy application softphone-voice
(or presumably any other application). Which is probably correct; according to the document the Network Policy TLV subtype is mandatory for those classes.

[vincentbernat]

I can update the documentation to tell a user is expected to configure a policy if they enable these classes.

[davidmonro]

Oh I think I get it. -M 4 is probably broken; the document states that the network connectivity device should only transmit LLDP-MED information once it sees an LLDP-MED capable endpoint device. So if you have two network connectivity devices talking to each other, LLDP-MED should not happen at all. I can't see any code to implement this behaviour at the moment.

So in summary, I think there are two bugs:

1. If -M 2 or -M 3 is specified, it should be mandatory to have specified a MED policy of some sort

2. if -M 4 is specified, transmission of MED TLVs should not happen until a MED class 1, 2 or 3 endpoint has been seen down that port.

I'm happy for you to close this issue since I have workarounds for both (I don't really have any class 2 or 3 machines running lldpd, and my router can just not specify -M).

Cheers

David

[vincentbernat]

OK, I have fixed the first point with documentation and let me rename this issue for the second point.