]> git.ipfire.org Git - thirdparty/lldpd.git/commitdiff
README: add a word about `--enable-oldies`
authorVincent Bernat <vincent@bernat.im>
Sun, 4 Oct 2015 06:58:53 +0000 (08:58 +0200)
committerVincent Bernat <vincent@bernat.im>
Sun, 4 Oct 2015 06:58:53 +0000 (08:58 +0200)
README.md

index 1051aac2b7e5c4d40afa042e62a335b95b061a5b..64477cc6a5c9b90e0911b794df2c0caa7d03f98a 100644 (file)
--- a/README.md
+++ b/README.md
@@ -126,6 +126,19 @@ EDP, CDP, FDP or SONMP frame on this interface. Informations collected
 through EDP/CDP/FDP/SONMP are integrated with other informations and
 can be queried with `lldpcli` or through SNMP.
 
+More information:
+ * http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol
+ * http://standards.ieee.org/getieee802/download/802.1AB-2005.pdf
+ * http://wiki.wireshark.org/LinkLayerDiscoveryProtocol
+
+Compatibility with older kernels
+--------------------------------
+
+If you have a kernel older than Linux 2.6.39, you need to compile
+lldpd with `--enable-oldies` to enable some compatibility functions:
+otherwise, lldpd will only rely on Netlink to receive bridge, bond and
+VLAN information.
+
 For bonding, you need 2.6.24 (in previous version, PACKET_ORIGDEV
 affected only non multicast packets). See:
 
@@ -133,7 +146,9 @@ affected only non multicast packets). See:
  * http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8032b46489e50ef8f3992159abd0349b5b8e476c
 
 Otherwise, a packet received on a bond will be affected to all
-interfaces of the bond.
+interfaces of the bond. In this case, lldpd will affect a received
+randomly to one of the interface (so a neighbor may be affected to the
+wrong interface).
 
 On 2.6.27, we are able to receive packets on real interface for bonded
 devices. This allows one to get neighbor information on active/backup
@@ -150,7 +165,7 @@ information:
 
  * http://www.freebsd.org/cgi/query-pr.cgi?pr=138620
 
-Some devices (notably Cisco IOS) send frames on tagged with the native
+Some devices (notably Cisco IOS) send frames tagged with the native
 VLAN while they should send them untagged. If your network card does
 not support accelerated VLAN, you will receive those frames as long as
 the corresponding interface exists (see below). However, if your
@@ -195,11 +210,6 @@ using the option `configure system interface promiscuous`.
 
 On modern networks, the performance impact should be nonexistent.
 
-More information:
- * http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol
- * http://standards.ieee.org/getieee802/download/802.1AB-2005.pdf
- * http://wiki.wireshark.org/LinkLayerDiscoveryProtocol
-
 Development
 -----------