Intel X700系列网卡（i40e驱动）收不到LLDP包问题
在我们的机房服务器上，启用了LLDPD服务，通过LLDP协议实现网络层的自动发现，从而根据收到的消息绘制网络拓扑关系。
之前的大部分机器一直工作正常，也没有多关注，然而今天突然发现有一批机器工作不太正常，因为后期的工作依赖这个拓扑关系，如果关系不正确，后面的工作就没办法进行，所以遇到不正常的机器还是需要具体分析一下为什么。
正常情况下，启动lldpd服务，并调用lldpctl可以看到网卡连接到的交换机信息：
]# lldpctl
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface: eth0, via: LLDP, RID: 1, Time: 27 days, 04:05:23
Chassis:
ChassisID: mac ff:ff:ff:ff:ff:ff
SysName: sw1.ichenfu.com
SysDescr: H3C Comware Platform Software...
H3C S6850-56HF
Copyright (c) 2004-2019 New H3C Technologies Co., Ltd. All rights reserved.
Capability: Bridge, on
Capability: Router, on
Port:
PortID: ifname Twenty-FiveGigE1/0/10
PortDescr: Twenty-FiveGigE1/0/10 Interface
TTL: 121
MFS: 9416
PMD autoneg: supported: yes, enabled: yes
MAU oper type: unknown
MDI Power: supported: no, enabled: no, pair control: no
Device type: PD
Power pairs: signal
Class: class 0
VLAN: 1, pvid: yes可以看到机器的eth0网口连接到了sw1.ichenfu.com这个交换机的Twenty-FiveGigE1/0/10这个口。
但是在出问题的机器上，执行lldpctl却什么也不会显示，第一反应，先重启试试，于是重启了lldpd进程，发现也不行，又尝试重启机器，还是不行。更奇怪的是，让网络组看了一下这台交换机底下其他的机器，都是正常的，这就很奇怪了。既然不知道怎么回事，那就抓个包试试：
]# tcpdump -ieth0 ether proto 0x88cc
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:26:35.251321 LLDP, length 133: node1-ichenfu-com
17:27:05.252325 LLDP, length 133: node1-ichenfu-com
17:27:35.254324 LLDP, length 133: node1-ichenfu-com
17:28:05.254863 LLDP, length 133: node1-ichenfu-com出问题的机器，发现抓包只能看到本机发出去的LLDP包，看不到交换机发出的LLDP包。
]# tcpdump -ieth0 ether proto 0x88cc
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:26:35.251321 LLDP, length 133: node2-ichenfu-com
17:26:40.693320 LLDP, length 337: sw1.ichenfu.com
17:27:05.252325 LLDP, length 133: node2-ichenfu-com
17:27:10.692902 LLDP, length 337: sw1.ichenfu.com
17:27:35.254324 LLDP, length 133: node2-ichenfu-com
17:27:40.693446 LLDP, length 337: sw1.ichenfu.com
17:28:05.254863 LLDP, length 133: node2-ichenfu-com正常的机器上，可以看到本机发出去的和交换机发出来的LLDP包。
难不成交换机发的包被丢了？在这个时候，注意到了一个细节，出问题的机器，网卡是Intel Corporation Ethernet Connection X722，而没有问题的网卡是Intel Corporation 82599ES 10-Gigabit，难道是网卡问题？
于是打开Google，先用X722 LLDP类似关键词搜索了一下，好像没有搜到什么有用的信息，想了想，是不是和驱动有关呢？因为Intel在X700系列使用的驱动是i40e，所以尝试用关键词i40e LLDP再搜索，搜到了关键的信息，来自Redhat的知识库Intel X710 series NICs (i40e) do not receive LLDP frames。看了一下其中的内容：
Intel 700 series NICs run an LLDP agent in firmware that will process and “absorb” any LLDPDU frames received from the switch. The frames are therefore never visible to the OS.
Intel 700 系列网卡在固件中会运行一个LLDP agent，这个agent会处理所有从交换发出的LLDP报文，这样在操作系统层面就再也看不到这个报文了。
好吧，这个特性确实有点坑啊。不过，Redhat也提供了相应的解决方案：
当Kernel版本大于等于kernel-3.10.0-957.el7，也就是CentOS 7.6版本的默认内核时，可以调用ethtool --set-priv-flags eth0 disable-fw-lldp on通知网卡驱动关闭内置的LLDP agent。
如果内核小于这个版本，那就需要tricky一点的做法了：echo "lldp stop" > /sys/kernel/debug/i40e/<pci bus address>/command。
由于我们的系统版本刚好是CentOS 7.6，所以直接执行ethtool --set-priv-flags eth0 disable-fw-lldp on，再执行ethtool --show-priv-flags eth0|grep disable-fw-lldp确认生效。
执行完成，发现恢复了：
]# lldpctl
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface: eth0, via: LLDP, RID: 1, Time: 27 days, 04:05:23
Chassis:
ChassisID: mac ff:ff:ff:ff:ff:ff
SysName: sw1.ichenfu.com
SysDescr: H3C Comware Platform Software...
H3C S6850-56HF
Copyright (c) 2004-2019 New H3C Technologies Co., Ltd. All rights reserved.
Capability: Bridge, on
Capability: Router, on
Port:
PortID: ifname Twenty-FiveGigE1/0/11
PortDescr: Twenty-FiveGigE1/0/10 Interface
TTL: 121
MFS: 9416
PMD autoneg: supported: yes, enabled: yes
MAU oper type: unknown
MDI Power: supported: no, enabled: no, pair control: no
Device type: PD
Power pairs: signal
Class: class 0
VLAN: 1, pvid: yes这么一看，Intel还是挺坑的啊，为啥要在网卡搞个这玩意。。即使都是以太网卡，不同的厂商以及芯片之间，行为上还是会有一些区别的。