[ovs-discuss] Leaking packets from one bridge to another or how can I isolate networks with OVS?

[Peter Schmitt]

Hi,

thank you very much for your help. I finally found the solution to this.
It was a qemu related problem. I use multiple NICs per KVM and tap
devices for the network connectivity:

-net nic,model=e1000,macaddr=XX:XX:XX:XX:XX:XX -net
tap,script=/path/to/ovs-ifup.sh,downscript=/path/to/ovs-ifdown.sh
-net nic,model=e1000,macaddr=YY:YY:YY:YY:YY:YY -net
tap,script=/path/to/ovs-ifup.sh,downscript=/path/to/ovs-ifdown.sh

What happens now is that qemu implicitly creates a network hub and
connects all tap devices and virtual nics to this hub which leads to the
effect I've seen.
The solution is to "connect" these entries by using the vlan parameter
(which has nothing to do with 802.1q). It simply tells qemu which nic in
the guest belongs to which
tap device in the host-system:

-net nic,model=e1000,macaddr=XX:XX:XX:XX:XX:XX,vlan=0 -net
tap,script=/path/to/ovs-ifup.sh,downscript=/path/to/ovs-ifdown.sh,vlan=0
-net nic,model=e1000,macaddr=YY:YY:YY:YY:YY:YY,vlan=1 -net
tap,script=/path/to/ovs-ifup.sh,downscript=/path/to/ovs-ifdown.sh,vlan=1

A detailed description can be found here:
http://lists.gnu.org/archive/html/qemu-discuss/2014-06/msg00067.html

So this is entirely not an OVS related problem I had, but it seemed like
that in the first place. I just want to post my solution here, so that
it may be of help for someone else with similar problems :)

Best regards,
Peter


On 21.08.2015 16:17, Ben Pfaff wrote:
> On Fri, Aug 21, 2015 at 08:41:29AM +0200, Peter Schmitt wrote:
>> Hi,
>> thank you for the answer. Yes I saw that, but that does not explain why
>> I see
>> ARP requests from the host network on br1000. Maybe I did not explain
>> this quite well.
>>
>> Assume I have my normal home network here being 192.168.0.0/24. All my hosts
>> are connected to this network, and also the KVM host machine.
>> Now I start ovs, pox and some KVMs on the KVM host machine.
>> The br0 on ovs is also in the network 192.168.0.0/24. The network between
>> my KVM machines is 10.0.0.0/24 on br1000. With the setup described below,
>> I can see ARP requests from two different hosts in the 192.168.0.0/24
>> network (not the IP address of the KVM host) on my KVM appliances in the
>> 10.0.0.0/24 network.
>> That would (in my understanding) mean, that the KVM forwards ARP requests
>> for some reason to the second bridge or there is anything fishy with
>> ovs. I don't
>> have any bridges or anything configured on the KVM host.
>> The strange thing is that if I remove the interface of my KVM from the
>> br0 in ovs,
>> the ARP requests disappear on br1000.
>>
>> I hope this got a little bit clearer now. I don't think this might be
>> related to the ES Model,
>> or am I wrong here?
> OK, if it's not the ES model, then you can trace the path of a packet
> through your system hop-by-hop to figure out what's happening.  The FAQ
> has some info:
>
> ### Q: I have a sophisticated network setup involving Open vSwitch, VMs or
>    multiple hosts, and other components.  The behavior isn't what I
>    expect.  Help!
>
> A: To debug network behavior problems, trace the path of a packet,
>    hop-by-hop, from its origin in one host to a remote host.  If
>    that's correct, then trace the path of the response packet back to
>    the origin.
>
>    Usually a simple ICMP echo request and reply ("ping") packet is
>    good enough.  Start by initiating an ongoing "ping" from the origin
>    host to a remote host.  If you are tracking down a connectivity
>    problem, the "ping" will not display any successful output, but
>    packets are still being sent.  (In this case the packets being sent
>    are likely ARP rather than ICMP.)
>
>    Tools available for tracing include the following:
>
>    - "tcpdump" and "wireshark" for observing hops across network
>      devices, such as Open vSwitch internal devices and physical
>      wires.
>
>    - "ovs-appctl dpif/dump-flows <br>" in Open vSwitch 1.10 and
>      later or "ovs-dpctl dump-flows <br>" in earlier versions.
>      These tools allow one to observe the actions being taken on
>      packets in ongoing flows.
>
>      See ovs-vswitchd(8) for "ovs-appctl dpif/dump-flows"
>      documentation, ovs-dpctl(8) for "ovs-dpctl dump-flows"
>      documentation, and "Why are there so many different ways to
>      dump flows?" above for some background.
>
>    - "ovs-appctl ofproto/trace" to observe the logic behind how
>      ovs-vswitchd treats packets.  See ovs-vswitchd(8) for
>      documentation.  You can out more details about a given flow
>      that "ovs-dpctl dump-flows" displays, by cutting and pasting
>      a flow from the output into an "ovs-appctl ofproto/trace"
>      command.
>
>    - SPAN, RSPAN, and ERSPAN features of physical switches, to
>      observe what goes on at these physical hops.
>
>    Starting at the origin of a given packet, observe the packet at
>    each hop in turn.  For example, in one plausible scenario, you
>    might:
>
>    1. "tcpdump" the "eth" interface through which an ARP egresses
>       a VM, from inside the VM.
>
>    2. "tcpdump" the "vif" or "tap" interface through which the ARP
>       ingresses the host machine.
>
>    3. Use "ovs-dpctl dump-flows" to spot the ARP flow and observe
>       the host interface through which the ARP egresses the
>       physical machine.  You may need to use "ovs-dpctl show" to
>       interpret the port numbers.  If the output seems surprising,
>       you can use "ovs-appctl ofproto/trace" to observe details of
>       how ovs-vswitchd determined the actions in the "ovs-dpctl
>       dump-flows" output.
>
>    4. "tcpdump" the "eth" interface through which the ARP egresses
>       the physical machine.
>
>    5. "tcpdump" the "eth" interface through which the ARP
>       ingresses the physical machine, at the remote host that
>       receives the ARP.
>
>    6. Use "ovs-dpctl dump-flows" to spot the ARP flow on the
>       remote host that receives the ARP and observe the VM "vif"
>       or "tap" interface to which the flow is directed.  Again,
>       "ovs-dpctl show" and "ovs-appctl ofproto/trace" might help.
>
>    7. "tcpdump" the "vif" or "tap" interface to which the ARP is
>       directed.
>
>    8. "tcpdump" the "eth" interface through which the ARP
>       ingresses a VM, from inside the VM.
>
>    It is likely that during one of these steps you will figure out the
>    problem.  If not, then follow the ARP reply back to the origin, in
>    reverse.