[ovs-discuss] kvm and open vSwitch, basic connectivity not working

Jesse Gross jesse at nicira.com
Tue Feb 9 15:44:43 UTC 2010


On Tue, Feb 9, 2010 at 9:25 AM, Todd Deshane <deshantm at gmail.com> wrote:

> The output of ovs-vswitchd ovs-vswitchd.conf is now quieter:
> Feb 09 09:07:47|00001|cfg|INFO|using "ovs-vswitchd.conf" as
> configuration file, ".ovs-vswitchd.conf.~lock~" as lock file
> Feb 09 09:07:47|00002|ofproto|INFO|using datapath ID 002320dc5ff5
> Feb 09 09:07:47|00003|bridge|INFO|created bridge internalbr on dp0
> Feb 09 09:07:47|00004|bridge|INFO|created port dummy0 on bridge internalbr
> Feb 09 09:07:47|00005|bridge|INFO|created port tap0 on bridge internalbr
> Feb 09 09:07:47|00006|bridge|INFO|created port tap1 on bridge internalbr
> Feb 09 09:07:47|00007|ofproto|INFO|datapath ID changed to 8efae2549dde
>
>
This looks a lot better so far.


> the output of ovs-dpctl show (seems similar)
> dp0:
>        flows: cur:0, soft-max:512, hard-max:262144
>        ports: cur:4, max:1024
>        groups: max:16
>         lookups: frags:0, hit:585, missed:227, lost:0
>         queues: max-miss:100, max-action:100
>        port 0: internalbr (internal)
>        port 1: dummy0
>        port 2: tap0
>        port 3: tap1
>
>
Normally when you create a bridge, you should include the bridge local port.
 For example:

bridge.internalbr.port=internalbr

Not only can it cause problems if it is not included but you shouldn't need
to use dummy0 since that line will create the bridge.


>
> On thing I tried this time is ovs-ofctl show, which show addresses,
> but I noticed that the addresses don't match up with the mac address
> of the VMs. Are these addresses auto-generated by the switch?
>
>
These addresses are created by the tap driver that kvm uses.  The tap
devices are merely the backends of the Ethernet devices in the VMs and do
not actually generate any traffic themselves.  It is normal and not a
problem that the addresses are different.


>
> So, I still don't have connectivity on Ubuntu, I'll test on Fedora
> next, but I am unsure what else I can test/debug.
>
> Any ideas?
>

 The best debugging tools are often the dump flows commands as they show
what is actually happening to the packets.  While pinging between VMs, can
you run:

ovs-ofctl dump-flows internalbr
ovs-dpctl dump-flows internalbr

This will show what is happening in userspace and the kernel respectively.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20100209/0cb98336/attachment-0002.html>


More information about the discuss mailing list