Replies: 1 comment 3 replies
-
|
I am not 100% sure to understand your setup, but LLDP is a link local protocol so it should not be transmitted through bridges. The bond is of no consequence here. |
Beta Was this translation helpful? Give feedback.
-
|
I understand that it's link local. Basically, what I want to see is that connected ports from the Linux host are visible in the neighbors list on my switch. Right now it is not happening if I run lldpd on physical interfaces if these interfaces are part of the bond/bridge. It works if I run lldpd on the bridge itself, but from what I understand this is not the right way to do it. Happy to clarify any questions about the setup, just let me know what would be useful. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Check with tcpdump if you see the packets going out on the physical interface. |
Beta Was this translation helpful? Give feedback.
-
|
OK, I think I figured out what's happening here. I could swear it used to work with pretty much the same setup before, and I was right :) So TL;DR, the LLDP packet from the host seems to be too large. After some testing, 1507 bytes works (switch shows neighbor as expected), and 1522 and above (current setup is about 1750 or so) does not - so I assume 1518 is the max. This is mostly due to vlan names TLV payload, more on that later. This is weird, because both enp1s0 on Linux, and corresponding port on the switch have jumbo frames enabled (mtu 9000 and 9216, respectively). I know that regular connections over that link can handle 9k frames. So not sure what is going on here. It is possible that switch implementation simply drops all LLDP frames larger than 1518 bytes, or it could be something else. Looking at lldpd code, it would attempt to re-transmit packet without vlan TLVs if the packet is too large - but in this case it looks at MTU on the interface (9000), and rightfully assumes that the packet is not too large. Which brings me to the question on how to address this. While I can probably solve it in this particular case with writing a shorter list of vlans on the bridge instead of 1-100, is there another way to do it? It is not uncommon to see 2-4094 as vlan setup... Can you disable vlan TLVs from config? The closest I could find in the docs is 'configure [ports ethX [,…]] lldp custom-tlv [add | replace] oui oui subtype subtype [oui-info content]', but I have no idea how to use it in this case... Any pointers? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi everyone, I think I fundamentally misunderstand something as I've been struggling with proper setup for LLDP over bridge over bond in Linux. So here is general setup:
switchB -> Linux host pve100 [enp1s0->bond0->vmbr0->vmbr0.99]
enp1s0 is a physical interface, bond0 is a, well, bond :), in this case with a single interface. VLAN-aware bridge vmbr0 has only one port - bond0. And the IP is set on VLAN 99 of that bridge. So networking works just fine. switchB is a manged switch (TP-Link Omada something) that supports LLDP. I primarily use LLDP for network mapping purposes.
On another node where network setup is just eth0, with no bonds or bridges, LLDP neighbors show both on switch and on Linux host no problem.
So for pve100 I assumed that I need to run lldpd on enp1s0 directly (and all members of the bond if there are more than one). If I do that, then I see my switch in lldpcli show nei on pve100, but the switch doesn't see any LLDP neighbors.
Exact same thing happens if I run lldpd on bond0 - neighbors on host, no neighbors on switch.
If I run lldpd on vmbr0, then it is the opposite - I immediately see proper neighbor on the switch, but see no neighbors on the host anymore.
The last part can be addressed by adjusting MAC filtering on vmbr0:
echo 16384 > /sys/class/net/vmbr0/bridge/group_fwd_mask
With that setup, I am able to see neighbors on both ends. But I seriously doubt that this is intended setup. The last thing I want to see is issues with MAC flapping when there is more than one interface in bond0. BTW, bond0 has forced local MAC address (hwaddr), so it doesn't match any of the MACs of underlying interfaces (if that matters).
So how lldpd is supposed to be run in such a setup (e.g., with bridge over bonded interfaces)?
P.S. Probably a separate topic, but I expected that setting up 'configure system bond-slave-src-mac-type zero' would have an impact at some of these configurations, but looking at tcpdump it never changed MACs in LLDP packets, certainly not to zeros...
Beta Was this translation helpful? Give feedback.
All reactions