Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LLDP packets are not received on bond interface #295

Closed
bhayanak opened this issue Aug 7, 2018 · 8 comments
Closed

LLDP packets are not received on bond interface #295

bhayanak opened this issue Aug 7, 2018 · 8 comments

Comments

@bhayanak
Copy link

bhayanak commented Aug 7, 2018

Hi Vincent,
First of all thank you for working on a great product.

I just migrated from centos 7.4. to 7.5, in centos 7.4 lldp packets were getting sent and received fine on bond interface. But with centos 7.5 i see only sent none received.

lldpcli show stat
-------------------------------------------------------------------------------
LLDP statistics:
-------------------------------------------------------------------------------
Interface:    bond0
  Transmitted:  3
  Received:     0
  Discarded:    0
  Unrecognized: 0
  Ageout:       0
  Inserted:     0
  Deleted:      0

i have ran lldp with -dddd option nothing suspicious as such, with -ddd i see a warning:
[WARN/interfaces] cannot get ethtool link information with GLINKSETTINGS (requires 4.9+): Operation not permitted

More output:

Aug 07 16:11:11 me lldpd[33089]: 2018-08-07T16:11:11 [INFO/main] protocol CDPv1 disabled
Aug 07 16:11:11 me lldpd[33089]: 2018-08-07T16:11:11 [INFO/main] protocol CDPv2 disabled
Aug 07 16:11:11 me lldpd[33089]: 2018-08-07T16:11:11 [INFO/main] protocol SONMP disabled
Aug 07 16:11:11 me lldpd[33089]: 2018-08-07T16:11:11 [INFO/main] protocol EDP disabled
Aug 07 16:11:11 me lldpd[33089]: 2018-08-07T16:11:11 [INFO/main] protocol FDP disabled
Aug 07 16:11:11 me lldpd[33089]: 2018-08-07T16:11:11 [INFO/event] libevent 2.0.21-stable initialized with epoll method
Aug 07 16:11:11 me lldpd[33089]: 2018-08-07T16:11:11 [INFO/snmp] enable SNMP subagent
Aug 07 16:11:11 me lldpd[33089]: 2018-08-07T16:11:11 [INFO/libsnmp] NET-SNMP version 5.7.2 AgentX subagent connected
Aug 07 16:11:11 me lldpd[33089]: 2018-08-07T16:11:11 [WARN/interfaces] cannot get ethtool link information with GLINKSETTINGS (requires 4.9+): Operation not permitted
Aug 07 16:11:11 me lldpd[33089]: 2018-08-07T16:11:11 [INFO/lldpctl] lldpd should resume operations

this is coming from https://github.com/vincentbernat/lldpd/blob/master/src/daemon/interfaces-linux.c
but not sure if that is the cause of failure and how to fix that. (On centos7.4 this warning is not seen)

Using options /etc/sysconfig/lldpd file to overwrite
-m !* -C bond0 -I bond0

checked with tcpdump and saw packets are sent but not received.

Now if i change interface pattern from bond to ethX i see packets are received/sent fine.

Expected outcome

lldpcli show neighbors details should show received lldp.

Current outcome

lldpcli show neighbors details shows empty.

Additional information

  • Output of lldpd -vv:
 [root@me ~]# lldpd -vv
lldpd 1.0.1
  Built on 2018-04-18T01:14:50Z

Additional LLDP features:    LLDP-MED, Dot1, Dot3, Custom TLV
Additional protocols:        CDP, FDP, EDP, SONMP
SNMP support:                yes
Old kernel support:          no (Linux 2.6.39+)
Privilege separation:        enabled
Privilege separation user:   lldpd
Privilege separation group:  lldpd
Privilege separation chroot: /run/lldpd/chroot
Configuration directory:     /etc

C compiler command: gcc -std=gnu99  -fdiagnostics-show-option -fdiagnostics-color=auto -pipe -Wall -W -Wextra -Wformat -Wformat-security -Wfatal-errors -Wcast-align -Winline -Wpointer-arith -fno-omit-frame-pointer -Wno-unused-parameter -Wno-missing-field-initializers -Wno-sign-compare -fstack-protector -fstack-protector-all -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic
Linker command:     /usr/bin/ld -m elf_x86_64  -Wl,-z,relro -Wl,-z,now  -Wl,-z,relro
  • Output of ps -fp $(pgrep -d, -x lldpd):
ps -wwfp $(pgrep -d, -x lldpd)
UID        PID  PPID  C STIME TTY          TIME CMD
root     57390     1  0 16:57 ?        00:00:00 /usr/sbin/lldpd -x -dddd -S xxx -m !* -C bond0 -I bond0
lldpd    57392 57390  0 16:57 ?        00:00:00 /usr/sbin/lldpd -x -dddd -S xxx -m !* -C bond0 -I bond0

  • Output of uname -sro:
Linux 3.10.0-862.3.2.el7.x86_64 GNU/Linux

  • Output of tcpdump -pni bond0 -vv -X ether host 01:80:c2:00:00:0e:
[root@me ~]# tcpdump -pni bond0 -vv -X ether host 01:80:c2:00:00:0e
tcpdump: listening on bond0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:00:48.576244 LLDP, length 146
        Chassis ID TLV (1), length 7
          Subtype MAC address (4): xxxx
          0x0000:  049c b654 9801 28
        Port ID TLV (2), length 7
          Subtype MAC address (3): xxxx
          0x0000:  039c b654 9801 28
        Time to Live TLV (3), length 2: TTL 120s
          0x0000:  0078
        System Name TLV (5), length 9: localhost
          0x0000:  6c6f 6361 6c68 6f73 74
        System Description TLV (6), length 74
          xxxx
          0x0000:  7b22 5552 4922 3a22 2f72 6573 742f 6170
          0x0010:  706c 6961 6e63 652f 6b69 6f73 6b2d 6469
          0x0020:  7370 6c61 7922 2c22 4950 223a 5b22 6665
          0x0030:  3830 3a3a 3932 6339 3a35 6563 643a 6236
          0x0040:  3665 3a32 6435 6422 5d7d
        System Capabilities TLV (7), length 4
          System  Capabilities [Bridge, WLAN AP, Router, Station Only] (0x009c)
          Enabled Capabilities [Station Only] (0x0080)
          0x0000:  009c 0080
        Port Description TLV (4), length 5: bond0
          0x0000:  626f 6e64 30
        Organization specific TLV (127), length 9: OUI IEEE 802.3 Private (0x00120f)
          Link aggregation Subtype (3)
            aggregation status [supported], aggregation port ID 0
          0x0000:  0012 0f03 0100 0000 00
        Organization specific TLV (127), length 9: OUI IEEE 802.3 Private (0x00120f)
          MAC/PHY configuration/status Subtype (1)
            autonegotiation [none] (0x00)
            PMD autoneg capability [unknown] (0x0000)
            MAU type unknown (0x0029)
          0x0000:  0012 0f01 0000 0000 29
        End TLV (0), length 0

Let me know if you want me to try something or need more information.
Thank you

@vincentbernat
Copy link
Member

vincentbernat commented Aug 7, 2018 via email

@bhayanak
Copy link
Author

bhayanak commented Aug 8, 2018

Thanks for quick reply.
As i mentioned above physical interface works fine.

I have been using bondX since long time and had no issues until i came to centos 7.5. Is that os specific or this lldp version specific?

below link also says bondig support is fine since kernel >2.6.27.
https://github.com/vincentbernat/lldpd/wiki/Status-of-bonding-support

Please help me understand the change in behavior.

Note: i have another code which expects packets on bond0(that's primary interface for me) and expected to send using same interface bond0 in my came.

Thanks in advance.

@vincentbernat
Copy link
Member

Bonding support is the ability to correctly receive packets on physical interfaces despite being attached to a bond interface. In the past, Linux made it very hard to grab packets before they were stolen by the bond device.

On the other side, who is sending LLDP packets?

@bhayanak
Copy link
Author

bhayanak commented Aug 8, 2018

Thanks i understood the bond part now.

On the other side, who is sending LLDP packets?

lldp packets are being sent by another machine which get to this machine(cent 7.5 machine) and it also send some other information which is received by first machine(which is working fine).

i still need to understand the behavior change.

@vincentbernat
Copy link
Member

LLDP packets are special by using a link-local target MAC address. These addresses are not expected to pass a bridge. It's far possible a kernel change added restrictions on MAC addresses that will be transmitted to the bond interface. As tcdump doesn't see the packet, lldpd cannot see it either. You can use -ni instead of -pni. If tcpdump starts seeing the packet, lldpd should see it too (as long as tcpdump is running). In this case, you can use configure system interface promiscuous to make lldpd work without tcpdump.

Other than that, I have no idea what has changed, but again, forcing lldpd to listen on a non-physical interface is not an expected configuration.

@bhayanak
Copy link
Author

bhayanak commented Aug 8, 2018

Thanks Vincent!
even after -ni option tcpdump is not able to see the lldp packets. i will look into 7.5 kernel side. I will consider to change it to real interface.
Thanks for your prompt help.

I wanted to know the meaning of below warning:
[WARN/interfaces] cannot get ethtool link information with GLINKSETTINGS (requires 4.9+): Operation not permitted

thanks in advance.

@vincentbernat
Copy link
Member

The warning is harmless and should be displayed only once. It means you may not get all the speeds available for Dot3 TLVs (anything above 10G).

@bhayanak
Copy link
Author

bhayanak commented Aug 9, 2018

Thanks Vincent. thanks for quick replies.

@bhayanak bhayanak closed this as completed Aug 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants