README: more about Cisco sending LLDP frames on VLAN 1

diff --git a/README.md b/README.md
index b3f5bdf9ff58d77d8415b02d4da5c257644d9577..c558e4e460b86de62403c177aad6995538dae0e8 100644 (file)
--- a/README.md
+++ b/README.md
@@ -148,20 +148,23 @@ information:
 
  * http://www.freebsd.org/cgi/query-pr.cgi?pr=138620
 
-Some devices (notably Cisco IOS) send frames on the native VLAN while
-they should send them untagged. If your network card does not support
-accelerated VLAN, you will receive those frames as well. However, if
-your network card handles VLAN encapsulation/decapsulation (check with
+Some devices (notably Cisco IOS) send frames on 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
+network card handles VLAN encapsulation/decapsulation (check with
 `ethtool -k`), you need a recent kernel to be able to receive those
 frames without listening on all available VLAN. Starting from Linux
 2.6.27, lldpd is able to capture VLAN frames when VLAN acceleration is
 supported by the network card. Here is the patch:
- http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bc1d0411b804ad190cdadabac48a10067f17b9e6
 
-On some versions, frames are sent on VLAN 1. If your network card
-support accelerated VLAN, you need to subscribe to this VLAN as
-well. The Linux kernel does not provide any interface for this. The
-easiest way is to create the VLAN for each port:
+ * http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bc1d0411b804ad190cdadabac48a10067f17b9e6
+
+On some other versions, frames are sent on VLAN 1. If this is not the
+native VLAN and if your network card support accelerated VLAN, you
+need to subscribe to this VLAN as well. The Linux kernel does not
+provide any interface for this. The easiest way is to create the VLAN
+for each port:
 
     ip link add link eth0 name eth0.1 type vlan id 1
     ip link set up dev eth0.1
@@ -176,7 +179,16 @@ second one does, LLDP packets are likely encapsulated into a VLAN:
 
     10:54:06.431154 f0:29:29:1d:7c:01 > 01:80:c2:00:00:0e, ethertype 802.1Q (0x8100), length 363: vlan 1, p 7, ethertype LLDP, LLDP, name SW-APP-D07.VTY, length 345
 
-In this case, just create VLAN 1 will fix the situation.
+In this case, just create VLAN 1 will fix the situation. There are
+other solutions:
+
+ 1. Disable VLAN acceleration on the receive side (`ethtool -K eth0
+    rxvlan off`) but this may or may not work. Check if there are
+    similar properties that could apply with `ethtool -k eth0`.
+ 2. Put the interface in promiscuous mode with `ip link eth0 set
+    promisc on`.
+
+On modern networks, the performance impact should be nonexistent.
 
 More information:
  * http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol