Wired Intelligent Edge

I have two switches of this type: HP J9573A E3800-24G-PoE+-2SFP+ Switch, revision KA.15.03.3015, ROM KA.15.05 (/ws/swbuildm/KA_15_03/code/build/tam(KA_15_03))

The identical switches are named kragmaki and kronmaki and are connected by port 26 on each switch using a 10G fibre connection with SR tranceivers.

Port 1-24 on each switch are connected to different machines using 1G TP RJ45, some of them support lldp.

Port 25 on each switch are connected to machines with 10G network cards using direct attach cables.

Lldp works as expected for port 1-24 and port 26 on both switches, but lldp data behaves bad for port 25 on both switches.

The switches clears some lldp data for port 25 every 30th second.

Strace of lldpd on connected computer shows that computer sends every 30th second by default. After each such transmission the switch remembers the entry until it clears data next time, strace of lldpd shows that this is not done because of any data sent.

Configuring lldpd to send data more often than every 30th second (like every second) makes the switch remote-device lldp table contain the right data for a bigger amount of time, but still data is cleared every 30th second until next lldp packet arrives.

kronmaki# show lldp info remote-device

LLDP Remote Devices Information

LocalPort | ChassisId                 PortId PortDescr SysName

--------- + ------------------------- ------ --------- ----------------------

1         | 18 03 73 2d eb 14         18 ... eth0      siamang.somedomain.tld

3         | 14 fe b5 ef 52 6c         14 ... eth0      husarapa.somedomain...

5         | 00 21 9b 3a e7 86         00 ... eth0      sifak.somedomain.tld

6         | 00 23 ae 73 1b be         00 ... eth0      grobian.somedomain.tld

8         | 18 03 73 3e ab b3         18 ... eth0      cheetah.somedomain.tld

9         | 00 15 c5 c9 f2 13         00 ... eth0      pctaket.somedomain.tld

11        | 90 b1 1c 68 b5 9b         90 ... eth0      saki.somedomain.tld

15        | 00 21 9b 3a eb 97         00 ... eth0      nilsson.somedomain.tld

19        | 00 1a a0 df 8b 09         00 ... eth0      bonobo.somedomain.tld

22        | 00 13 72 a0 3f 1c         00 ... eth0      nicke.somedomain.tld

24        | 00 0f 20 8c 08 c0         24     24        SOMESWITCH01 (apswi...

25        | 00 0a f7 38 78 80         00 ...

26        | 00 9c 02 d8 4d 80         26     26        kragmaki

kronmaki# show lldp info remote-device

LLDP Remote Devices Information

LocalPort | ChassisId                 PortId PortDescr SysName

--------- + ------------------------- ------ --------- ----------------------

1         | 18 03 73 2d eb 14         18 ... eth0      siamang.somedomain.tld

3         | 14 fe b5 ef 52 6c         14 ... eth0      husarapa.somedomain...

5         | 00 21 9b 3a e7 86         00 ... eth0      sifak.somedomain.tld

6         | 00 23 ae 73 1b be         00 ... eth0      grobian.somedomain.tld

8         | 18 03 73 3e ab b3         18 ... eth0      cheetah.somedomain.tld

9         | 00 15 c5 c9 f2 13         00 ... eth0      pctaket.somedomain.tld

11        | 90 b1 1c 68 b5 9b         90 ... eth0      saki.somedomain.tld

15        | 00 21 9b 3a eb 97         00 ... eth0      nilsson.somedomain.tld

19        | 00 1a a0 df 8b 09         00 ... eth0      bonobo.somedomain.tld

22        | 00 13 72 a0 3f 1c         00 ... eth0      nicke.somedomain.tld

24        | 00 0f 20 8c 08 c0         24     24        SOMESWITCH01 (apswi...

25        | 00 0a f7 38 78 80         00 ... eth0      sumpapa.somedomain.tld

26        | 00 9c 02 d8 4d 80         26     26        kragmaki

kronmaki# show lldp info remote-device

LLDP Remote Devices Information

LocalPort | ChassisId                 PortId PortDescr SysName

--------- + ------------------------- ------ --------- ----------------------

1         | 18 03 73 2d eb 14         18 ... eth0      siamang.somedomain.tld

3         | 14 fe b5 ef 52 6c         14 ... eth0      husarapa.somedomain...

5         | 00 21 9b 3a e7 86         00 ... eth0      sifak.somedomain.tld

6         | 00 23 ae 73 1b be         00 ... eth0      grobian.somedomain.tld

8         | 18 03 73 3e ab b3         18 ... eth0      cheetah.somedomain.tld

9         | 00 15 c5 c9 f2 13         00 ... eth0      pctaket.somedomain.tld

11        | 90 b1 1c 68 b5 9b         90 ... eth0      saki.somedomain.tld

15        | 00 21 9b 3a eb 97         00 ... eth0      nilsson.somedomain.tld

19        | 00 1a a0 df 8b 09         00 ... eth0      bonobo.somedomain.tld

22        | 00 13 72 a0 3f 1c         00 ... eth0      nicke.somedomain.tld

24        | 00 0f 20 8c 08 c0         24     24        SOMESWITCH01 (apswi...

25        | 00 0a f7 38 78 80         00 ...

26        | 00 9c 02 d8 4d 80         26     26        kragmaki

kronmaki#

Unlike ports with connected machines lacking lldp support port 25 is allways listed in the table. The mac address and the PortID of the connected machines are also allways right, but PortDescr and SysName becomes empty strings.

Is there any setting in the switch I can change to avoid this behavior with cleared data in the lldp remote device table?

regards Henrik

From my tests it seems as if the problem is in the switch. If you have any idea how to narrow this down, please let me know.

It would be interesting to alter connections to see if the problem follows port 25 or if the problem follows the DA connected machines. It would also be interesting to test a newer firmware to see if that helps. Unfortunately these switches are used in production and any test interrupting their function has to be avoided. If I knew that something like a firmware update would help I could schedule that in maybe some month.

I have tried to alter lldpMessageTxInterval from its default 30s on one switch by using snmpset on 1.0.8802.1.1.2.1.1.1.0, but it does not seem as those 30s were the what appears to be 30s interval for lldp data to be cleared on any of the switches.

regards Henrik

Actually, the problem isn't the 3800, as the TTL for LLDP entries is determined by the *sending* device.

so in this case, you need to look at the device "sumpapa.somedomain.tld" and find out why it is sending LLDP tx with a low TTL.

Thanks for your reply!

Using tcpdump I can see that the first four bytes sent and received on both sumpapa and other machines connected are:

01 80 c2 00

where I assume that the TTL value are the "c2 00" bytes. This seems like a standard TTL value sent both by switches and my computers which are all running lldpd with default settings.

Only the machine connected by DA 10G gets cleared lldp data.

I have also tried to configure a shorter tx-interval in lldpd and can then see how lldp packets are sent more often from sumpapa and still with "c2 00" in the TTL bytes. But even when lldp packets are sent more often lldp data are cleared every 30th second in the switch. Also, when lldp data are cleared in the switch not all data are cleared, the ChassisID (mac address) and the PortID are still there.

(edit)

To study the lldp packages I used the command

tcpdump -i eth0 -s 1500 -XX -c 3 'ether proto 0x88cc'

regards Henrik

I don't think you are looking at the TTL, the first 12 bytes are going to be destination then source MAC addresses, so the 0200 you are looking at is the middle of the destination address.

Also, the ethertype is in the L2 frame header (2 bytes), and then only after that you get the LLDP bytes, of which the TTL is the 3rd pair (so bytes 5 & 6 of the payload).

Can you save your tcpdump as a pcap file?

If so, you can then open it with Wireshark, and wireshark will show you exactly where the TTL is, like this one:

(7x8+8=120).

Sorry about reading the wrong TTL bytes, I misunderstood page 7 of http://www.ieee802.org/1/files/public/docs2002/LLDP%20Overview.pdf

Looking at the TTL values in wireshark I can see that they are 120 which makes sense as this is tx-interval*tx-hold (30*4). Decreasing tx-interval to something like 5 also gives a decreased TTL like 20.

I attach the .pcap file, even though it is rather small I had to zip it to get an extension which is allowed on this forum.

regards Henrik

Attachment(s)

sumpapa.zip   703 B 1 version

sumpapa definitely seems to be sending a good TTL, but if the LLDP advertisement isn't being retained properly, I would still be more inclined to look at the Linux side of things than the switch.

I did some work in a science organisation that had a whole heap of different Unix and Linux machines and I noticed many of them seemed to be running LLDP, and I also noticed the information provided wasn't exactly the same as what I expected to see from switches. As I wasn't very interested in where the servers were, I didn't really look into it. I now wish I had!

If you want to rule out it being some peculiarity of the switchport type in use for sumpapa, are you able to patch sumpapa into a switch using a standard switchport instead and see what that gives?

...or, do you have any other switches with SFP+ ports you can test it on, like a 5400 or 5900 for example?

Thanks for the suggested tests!

Unfortunately I do not have any other switches with SFP+ -ports, but one of the machines connected to a SFP+ port also has RJ45 interfaces. I connected one of the RJ45 interfaces (eth2) to port 22 on switch kragmaki and assigned eth2 a temporary IP address. I also used lldpcli on the machine to give the command "update". I don't know if the update command was necessary, but the link did not come up until eth2 got an IP address.

After this the RJ45 port 22 behaves good as other RJ45 ports connected to other machines, but the SFP+ port still behaves like before:

kragmaki# show lldp info remote-device

LLDP Remote Devices Information

LocalPort | ChassisId                 PortId PortDescr SysName

--------- + ------------------------- ------ --------- ----------------------

1         | 78 2b cb 66 50 ff         78 ... eth0      guereza.somedomain....

2         | 78 2b cb 66 50 ff         78 ... eth1      guereza.somedomain....

3         | 78 2b cb 4c 50 79         78 ... eth0      gibbon.somedomain.t...

6         | 00 13 d4 01 61 f5         00 ... eth0      babian.somedomain.t...

11        | 00 1d 09 f0 97 9a         00 ... eth0      tamarin.somedomain....

12        | 1c c1 de 1d 60 76         1c ... eth1      langur.somedomain.t...

15        | 00 1d 09 f0 95 7e         00 ... eth0      gorilla.somedomain....

19        | 00 14 22 1b 5f c1         00 ... eth0      ateles.somedomain.tld

22        | b8 ca 3a f8 f7 82         b8 ... eth2      javaapa.somedomain....

25        | b8 ca 3a f8 f7 82         b8 ... eth0      javaapa.somedomain....

26        | a0 b3 cc f4 5f 00         26     26        kronmaki

kragmaki# show lldp info remote-device

LLDP Remote Devices Information

LocalPort | ChassisId                 PortId PortDescr SysName

--------- + ------------------------- ------ --------- ----------------------

1         | 78 2b cb 66 50 ff         78 ... eth0      guereza.somedomain....

2         | 78 2b cb 66 50 ff         78 ... eth1      guereza.somedomain....

3         | 78 2b cb 4c 50 79         78 ... eth0      gibbon.somedomain.t...

6         | 00 13 d4 01 61 f5         00 ... eth0      babian.somedomain.t...

11        | 00 1d 09 f0 97 9a         00 ... eth0      tamarin.somedomain....

12        | 1c c1 de 1d 60 76         1c ... eth1      langur.somedomain.t...

15        | 00 1d 09 f0 95 7e         00 ... eth0      gorilla.somedomain....

19        | 00 14 22 1b 5f c1         00 ... eth0      ateles.somedomain.tld

22        | b8 ca 3a f8 f7 82         b8 ... eth2      javaapa.somedomain....

25        | b8 ca 3a f8 f7 82         b8 ...

26        | a0 b3 cc f4 5f 00         26     26        kronmaki

Maybe I should also mention that the clearing of LLDP data seems unsyncronized to anything else I have measured so far. Even though it seems to happen about every 30th second on both switches it does not happen at the same time on both switches. If one switch clears lldp data at time t1 and the other switch clears lldp data at time t2 and the machines send new lldp data at times t3 and t4 all events (unless the machines are configured otherwise) happen with 30 s period, but the order of these events and the times between the events seems random.

regards Henrik

Once again I used tcpdump to capture two files:

tcpdump -i eth0 -s 1500 -XX -c 2 'ether proto 0x88cc' -w javaapa_eth0.pcap
tcpdump -i eth2 -s 1500 -XX -c 2 'ether proto 0x88cc' -w javaapa_eth2.pcap

I studied their content in wireshark and found the following differences:

The source (Mac) differs a byte 82 vs 86, this seems OK to me as there are different mac adresses on eth0 and eth2.

In the LLDP part of the message I also found the following differences:

The Port Subtype again differs a byte 82 vs 86, this is the mac adresses again.

The Port Description differs a byte 30 vs 32, this is the difference between eth0 and eth2.

The Auto negotiation differs a byte 00 vs 03, the 10G interface only has one fixed speed.

The Auto negotioation capabilities differs two bytes 8000 vs 6c01, again because 10G only has one speed.

The Operational MAU Type differs two bytes 0021 vs 001e, this is 10GigBaseR vs 1000BaseTFD.

In short all the differences seems OK to me. However, I do agree that regardless of the cause of the problem it is a lot easier to track the problem and maybe also fix the problem from the client machines with all their tools and access to sources for anything from the kernel to lldpd.

regards Henrik

Attachment(s)

javaapa_eth.zip   703 B 1 version

Some more testing...

Configuring lldpd on the client to send both lldp and cdp packages gives two entries in the neighbour list:

kronmaki# show lldp info remote-device

 LLDP Remote Devices Information

  LocalPort | ChassisId                 PortId PortDescr SysName              
  --------- + ------------------------- ------ --------- ----------------------
  3         | 14 fe b5 ef 52 6c         14 ... eth0      husarapa.dynamics.s...
  5         | 00 21 9b 3a e7 86         00 ... eth0      sifak.dynamics.saab.se
  6         | 00 23 ae 73 1b be         00 ... eth0      grobian.dynamics.sa...
  7         | 18 03 73 2d eb 14         18 ... eth0      siamang.dynamics.sa...
  8         | 18 03 73 3e ab b3         18 ... eth0      cheetah.dynamics.sa...
  9         | 00 15 c5 c9 f2 13         00 ... eth0      pctaket.dynamics.sa...
  11        | 90 b1 1c 68 b5 9b         90 ... eth0      saki.dynamics.saab.se
  15        | 00 21 9b 3a eb 97         00 ... eth0      nilsson.dynamics.sa...
  16        | 00 11 11 ae 83 95         00 ... eth0      lori.dynamics.saab.se
  19        | 00 1a a0 df 8b 09         00 ... eth0      bonobo.dynamics.saa...
  22        | 00 13 72 a0 3f 1c         00 ... eth0      nicke.dynamics.saab.se
  23        | 00 04 76 a0 d6 4e         00 ... eth0      uakari.dynamics.saa...
  24        | 00 0f 20 8c 08 c0         24     24        HP227-Lab3-F (apswi...
  25        | sumpapa.dynamics.saab.se  eth0                                  
  25        | 00 0a f7 38 78 80         00 ... eth0      sumpapa.dynamics.sa...
  26        | 00 9c 02 d8 4d 80         26     26        kragmaki             

Above the first row 25 is from CDP and the second row 25 is from LLDP without any missing data. As the parts missing in the cdp entry seemed to be the same as the parts that got lost from the lldp entry I took a closer look:

kronmaki# show lldp info remote-device 25

 LLDP Remote Device Information Detail

  Local Port   : 25
  ChassisType  : local              
  ChassisId    : sumpapa.dynamics.saab.se
  PortType     : local 
  PortId       : eth0                    
  SysName      :                                
  System Descr : Slackware 14.1 Linux 3.10.17 #1 SMP Thu Feb 20 17:15:54 C...
  PortDescr    :                                                            
  Pvid         :                         

  System Capabilities Supported  :
  System Capabilities Enabled    :

  Remote Management Address
     Type    : ipv4
     Address : 148.2.96.108

------------------------------------------------------------------------------
  Local Port   : 25
  ChassisType  : mac-address        
  ChassisId    : 00 0a f7 38 78 80       
  PortType     : mac-...
  PortId       : 00 0a f7 38 78 80       
  SysName      : sumpapa.dynamics.saab.se       
  System Descr : Slackware 14.1 Linux 3.10.17 #1 SMP Thu Feb 20 17:15:54 C...
  PortDescr    : eth0                                                       
  Pvid         :                         

  System Capabilities Supported  : bridge, wlan-access-point, router
  System Capabilities Enabled    : station-only

  Remote Management Address
     Type    : ipv4
     Address : 148.2.96.108
     Type    : ipv6
     Address : fe80::20a:f7ff:fe38:7880

Above we have CDP data and LLDP data without any missing data.

Unfortunately the parts missing from CDP does not seem to be the same that gets lost from LLDP, with some lost LLDP data looks like this:

kronmaki# show lldp info remote-device 25

 LLDP Remote Device Information Detail

  Local Port   : 25
  ChassisType  : mac-address        
  ChassisId    : 00 0a f7 38 78 80       
  PortType     : mac-...
  PortId       : 00 0a f7 38 78 80       
  SysName      :                                
  System Descr :                                                            
  PortDescr    :                                                            
  Pvid         :                         

  System Capabilities Supported  :
  System Capabilities Enabled    :

  Remote Management Address

Above "System Descr" and "Remode Management Address" data are both missing even though those data exist in the CDP entries. So the missing data does not seem to be related to CDP in any way.

However, when doing these tests I did note one interesting thing: Killing lldpd on the client "sumpapa" will make the CDP entry go away from the neighbours table as expected, but the LLDP entry will become incomplete but not go away. After half an hour the incomplete LLDP entry is still there, so far I have not tried with lldpd killed for any longer time.

Killing lldpd on any other client connected to port 1-24 will make the entire LLDP entry go away as expected.

regards Henrik

After the weekend without any lldpd running on the client the incomplete entry was still on the neighbour list. However, when killing lldpd on the client connected by DA to the other switch the entry dissapeared from the neighbour list as expected. Restarting lldpd without CDP on sumpapa which had its entries stuck in the list on the switch and killing lldpd again made the entries dissapear from the list. It seems as if the entries were stuck because of CDP.

However, I still don't know why lldp entries of clientes connected by DA lose half of their data every 30 seconds or how to avoid that.

regards Henrik

Today I tried to upgrade firmware from version KA.15.03.3015 to KA.15.17.0007 which is the latest firmware at the time of this writing. Unfortunately the LLDP bug is still there,  every 30th second some of the LLDP data is cleared.

Upgrading firmware did not help.

regards Henrik

Let me try to rephrase my question:

Has anyone successfully run some kind of LLDP software on a PC connected to a HP 3800 switch by SFP+ DA cable without any problems with the switch losing some LLDP data every 30th second? If so, what kind of DA cable were you using?

My machines connected with 1 m HP X242 DA cables (J9281B) to HP 3800 switches provide LLDP data to the switches, but the switches throws away some LLDP data (PortDescr and SysName shown in table below, but also System Description, System Capabilities and Remote Management Address) every 30th second:

kronmaki# show lldp info remote-device 

 LLDP Remote Devices Information

  LocalPort | ChassisId                 PortId PortDescr SysName               
  --------- + ------------------------- ------ --------- ----------------------
  3         | 14 fe b5 ef 52 6c         14 ... eth0      husarapa.dynamics.s...
  5         | 00 21 9b 3a e7 86         00 ... eth0      sifak.dynamics.saab.se
  6         | 00 23 ae 73 1b be         00 ... eth0      grobian.dynamics.sa...
  7         | 18 03 73 2d eb 14         18 ... eth0      siamang.dynamics.sa...
  8         | 18 03 73 3e ab b3         18 ... eth0      cheetah.dynamics.sa...
  9         | 00 15 c5 c9 f2 13         00 ... eth0      pctaket.dynamics.sa...
  11        | 90 b1 1c 68 b5 9b         90 ... eth0      saki.dynamics.saab.se 
  13        | 98 90 96 b5 28 3e         98 ... eth0      bilou.dynamics.saab.se
  15        | 00 21 9b 3a eb 97         00 ... eth0      nilsson.dynamics.sa...
  16        | 00 11 11 ae 83 95         00 ... eth0      lori.dynamics.saab.se 
  19        | 00 1a a0 df 8b 09         00 ... eth0      bonobo.dynamics.saa...
  22        | 00 1e 4f ba 4e a5         00 ... eth0      nicke.dynamics.saab.se
  23        | 00 04 76 a0 d6 4e         00 ... eth0      uakari.dynamics.saa...
  24        | 00 0f 20 8c 08 c0         24     24        HP227-Lab3-F (apswi...
  25        | 00 0a f7 38 78 80         00 ... eth0      sumpapa.dynamics.sa...
  26        | 00 9c 02 d8 4d 80         26     26        kragmaki              
 

kronmaki# show interfaces transceiver 

Transceiver Technical Information:

                     Product      Serial             Part
 Port    Type        Number       Number             Number
 ------- ----------- ------------ ------------------ ----------
 25      SFP+DA1     J9281B       CN2465L1PX         8121-1151 
 26      SFP+SR      J9150A       CN29DRN6DY         1990-4065 


kronmaki# show lldp info remote-device 

 LLDP Remote Devices Information

  LocalPort | ChassisId                 PortId PortDescr SysName               
  --------- + ------------------------- ------ --------- ----------------------
  3         | 14 fe b5 ef 52 6c         14 ... eth0      husarapa.dynamics.s...
  5         | 00 21 9b 3a e7 86         00 ... eth0      sifak.dynamics.saab.se
  6         | 00 23 ae 73 1b be         00 ... eth0      grobian.dynamics.sa...
  7         | 18 03 73 2d eb 14         18 ... eth0      siamang.dynamics.sa...
  8         | 18 03 73 3e ab b3         18 ... eth0      cheetah.dynamics.sa...
  9         | 00 15 c5 c9 f2 13         00 ... eth0      pctaket.dynamics.sa...
  11        | 90 b1 1c 68 b5 9b         90 ... eth0      saki.dynamics.saab.se 
  13        | 98 90 96 b5 28 3e         98 ... eth0      bilou.dynamics.saab.se
  15        | 00 21 9b 3a eb 97         00 ... eth0      nilsson.dynamics.sa...
  16        | 00 11 11 ae 83 95         00 ... eth0      lori.dynamics.saab.se 
  19        | 00 1a a0 df 8b 09         00 ... eth0      bonobo.dynamics.saa...
  22        | 00 1e 4f ba 4e a5         00 ... eth0      nicke.dynamics.saab.se
  23        | 00 04 76 a0 d6 4e         00 ... eth0      uakari.dynamics.saa...
  24        | 00 0f 20 8c 08 c0         24     24        HP227-Lab3-F (apswi...
  25        | 00 0a f7 38 78 80         00 ...                                 
  26        | 00 9c 02 d8 4d 80         26     26        kragmaki              

The lost LLDP data is not only lost at the switch CLI, but also from SNMP data retreived from the switch. I have only seen this problem on machines connected by SFP+ DA cables and I have only tried HP X242 cables.

regards Henrik

At first I thought that my LLDP problem was caused by a bug in the switch, now I think that the problem is caused by a feature in the NIC driver...

Both machines connected with DA cables have Broadcom NICs using the bnx2x driver. It seems as if also eth2 on machine javaapa is using the bnx2x driver, but the problem does not show on eth2 connected by RJ45. The problem only shows up on eth0 connected by DA SFP+ cables.

It seems as if the problem is caused by the NIC driver sending lldp packets. Those lldp packets sent by the NIC driver cannot be seen by tcpdump. Looking at the source of the bnx2x driver I can see that lldp and dcbx is mentioned. I don't fully understand what this is for, but it seems as if it is somehow negotiated between the switch and NIC if such dcbx lldp packages should be sent from the NIC.

I haven't found any option to disable those lldp dcbx messages from the NIC driver. Would it be possible to disable dcbx on the switch?

Why did I start looking at the NIC driver source? In yet another attempt to debug the problem I found the edomtset easter egg which gave me some more useful commands: lldpShow and lldpRecordsClear.

With lldpShow I could see that with all lldp data in place for port 25 the last received lldp packet had a lldpdu-len of 197. With some lldp data missing the lldpdu-len was 75. Looking with tcpdump and wireshark I could see that all sent lldp packets had length 211 where the size of the lldp part was 197. Something was obviously making up lldp packages with lldpdu-len of 75 and it wasn't the lldpd software running on the machine.

With lldpRecordsClear I could empty the lldp table on the switch. After that was run I sometimes got a complete first lldp packet with lldpdu-len of 197 and sometimes a shorter packet with lldpdu-len of 75. As the shorter packet contained the right mac address I assumed it wasn't made up by the switch.

Killing lldpd on the machine first cleared the lldp entry of port 25 in the switch, but then it was refilled by those incomplete shorter lldp packets with lldpdu-len 75. So it seems as if the NIC is sending lldp packets with lldpdu-len 75 every 30th second and those packages cannot be seen by tcpdump/wireshark.

It would really be nice to get rid of those short lldp packets sent by the NIC when I have lldpd sending more complete packets with data like system name and system description.

regards Henrik

Problem solved!

Disabling DCB in the NIC solved the problem. To disable DCB the machines had to be rebooted and by pressing CTRL-S at the right moment I got into the Broadcom NIC setup. I found a pdf file describing how to get into the NIC setup:

The problem was that the NIC was sending LLDP packets with DCB contents but those packets were lacking system information which lldpd was sending. When a DCB LLDP packet came from the NIC some contents from lldpd were cleared.

regards Henrik