Signed-off-by: Chris Luke <[email protected]> --- AUTHORS | 1 + FAQ | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-------- NEWS | 2 ++ 3 files changed, 80 insertions(+), 10 deletions(-)
diff --git a/AUTHORS b/AUTHORS index 218fe76..1f03203 100644 --- a/AUTHORS +++ b/AUTHORS @@ -21,6 +21,7 @@ Brian Kruger [email protected] Bruce Davie [email protected] Bryan Phillippe [email protected] Casey Barker [email protected] +Chris Luke [email protected] Chris Wright [email protected] Chuck Short [email protected] Damien Millescamps [email protected] diff --git a/FAQ b/FAQ index 75d9e6b..546b505 100644 --- a/FAQ +++ b/FAQ @@ -509,9 +509,9 @@ Q: I created a bridge and added my Ethernet port to it, using commands and as soon as I ran the "add-port" command I lost all connectivity through eth0. Help! -A: A physical Ethernet device that is part of an Open vSwitch bridge - should not have an IP address. If one does, then that IP address - will not be fully functional. +A: In the default Open vSwitch model, a physical Ethernet device that + is part of an Open vSwitch bridge should not have an IP address. + If one does, then that IP address will not be fully functional. You can restore functionality by moving the IP address to an Open vSwitch "internal" device, such as the network device named after @@ -534,12 +534,28 @@ A: A physical Ethernet device that is part of an Open vSwitch bridge (e.g. br0). You might still need to manually clear the IP address from the physical interface (e.g. with "ifconfig eth0 0.0.0.0"). - There is no compelling reason why Open vSwitch must work this way. - However, this is the way that the Linux kernel bridge module has - always worked, so it's a model that those accustomed to Linux - bridging are already used to. Also, the model that most people - expect is not implementable without kernel changes on all the - versions of Linux that Open vSwitch supports. + This was the way that the Linux kernel bridge module always worked, + so it's a model that those accustomed to Linux bridging are already + used to. + + Alternatively, Linux kernels since 2.6.39 allow packets that were + delivered to a module to be passed back to the kernel as though the + datapath never saw it. + + To install a flow explicitly directing packets back to the kernel, + use the Open vSwitch specific 'action=back_to_kernel', for example: + + # LLDP + ovs-ofctl add-flow br0 dl_type=0x88cc,action=back_to_kernel + # ARP + ovs-ofctl add-flow br0 arp,action=back_to_kernel + # ICMP + ovs-ofctl add-flow br0 ip,nw_proto=1,action=back_to_kernel + + It's worth mentioning that this method will also have an impact on IP + addresses configured on the bridge internal port; you must consider + carefully what packets you want the kernel to process on the kernel + native port and which you want it to handle on Open vSwitch ports. By the way, this issue is not specific to physical Ethernet devices. It applies to all network devices except Open vswitch @@ -652,7 +668,58 @@ A: On Linux kernels before 3.11, the OVS GRE module and Linux GRE module can then reload the OVS module following the directions in INSTALL, which will ensure that dependencies are satisfied. - +Q: If I run an LLDP daemon on my Linux machine it doesn't work quite + as expected. I want to the daemon to see LLDP messages from the + physical ports. How do I do that? + +A: See the first answer in this section for a related issue, but there's + a more specific issue at work here too. + + Receiving packets + + There's broadly two ways the LLDP daemon can have the kernel deliver + LLDP frames to it. One way works before the Open vSwitch kernel hook, + the other works after it. + + The first method, where the LLDP daemon receives all traffic for a + given port, means that because the kernel does this before the hook + that OVS uses, the daemon will always receive the LLDP frames it is + looking for, regardless of any Open vSwitch configuration. This is + what "lldpd" http://vincentbernat.github.io/lldpd/ does. + + The second method is for the daemon to ask for all the packets of a + specific link layer protocol, which for LLDP is ethertype 0x88cc. + Since this is done after the hook that OVS uses, the daemon will only + ever see packets if Open vSwitch is configured to return those + packets to the kernel. This is what "lldpad" http://open-lldp.org/ + does. See the 'back_to_kernel' note in the answer to the first + question in this section for an example of how to configure this. + + The packet delivery methods in use can be seen using procfs: + + $ cat /proc/net/ptype + Type Device Function + ALL tap1 packet_rcv+0x0/0x410 # + ALL tap0 packet_rcv+0x0/0x410 # These are "lldpd" + ALL eth0 packet_rcv+0x0/0x410 # + ALL eth0 packet_rcv+0x0/0x410 + 0800 ip_rcv+0x0/0x320 + 0011 llc_rcv+0x0/0x380 [llc] + 0004 llc_rcv+0x0/0x380 [llc] + 0806 arp_rcv+0x0/0x140 + 88cc br0 packet_rcv+0x0/0x410 # + 88cc tap1 packet_rcv+0x0/0x410 # These are 'lldpad' + 88cc tap0 packet_rcv+0x0/0x410 # + 88cc eth0 packet_rcv+0x0/0x410 # + 86dd ipv6_rcv+0x0/0x3e0 + + Sending packets + + Open vSwitch does not intercept any outbound packets generated by the + host. If your packets aren't going out, you should check things like + "iptables" for rules that would block the packets. + + Quality of Service (QoS) ------------------------ diff --git a/NEWS b/NEWS index 8689f5c..b60eb2f 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,8 @@ Post-v2.1.0 --------------------- - The "ovsdbmonitor" graphical tool has been removed, because it was poorly maintained and not widely used. + - Add flow action 'back_to_kernel' to datapath and OpenFlow that can + return packets to the kernel as though OVS never saw them. v2.1.0 - xx xxx xxxx --------------------- -- 1.7.9.5 _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
