Is it the following problem from the FAQ?
Q1: Some of the traffic that I'd expect my OpenFlow controller to see
doesn't actually appear through the OpenFlow connection, even
though I know that it's going through.
Q2: Some of the OpenFlow flows that my controller sets up don't seem
to apply to certain traffic, especially traffic between OVS and
the controller itself.
A: By default, Open vSwitch assumes that OpenFlow controllers are
connected "in-band", that is, that the controllers are actually
part of the network that is being controlled. In in-band mode,
Open vSwitch sets up special "hidden" flows to make sure that
traffic can make it back and forth between OVS and the controllers.
These hidden flows are higher priority than any flows that can be
set up through OpenFlow, and they are not visible through normal
OpenFlow flow table dumps.
Usually, the hidden flows are desirable and helpful, but
occasionally they can cause unexpected behavior. You can view the
full OpenFlow flow table, including hidden flows, on bridge br0
with the command:
ovs-appctl bridge/dump-flows br0
to help you debug. The hidden flows are those with priorities
greater than 65535 (the maximum priority that can be set with
OpenFlow).
The DESIGN file at the top level of the Open vSwitch source
distribution describes the in-band model in detail.
If your controllers are not actually in-band (e.g. they are on
localhost via 127.0.0.1, or on a separate network), then you should
configure your controllers in "out-of-band" mode. If you have one
controller on bridge br0, then you can configure out-of-band mode
on it with:
ovs-vsctl set controller br0 connection-mode=out-of-band
On Thu, Jul 12, 2012 at 10:58:35PM +0530, Neha Jatav wrote:
> I'm sorry Ben, I didn't copy paste the ovs-vsctl show result previously; I
> manually typed it. But its actually configured. This is the exact output:
>
> [neha@doorsingdog-dx ~]$ sudo ovs-vsctl show
> 15b36cfd-2b20-4459-abb0-26396a692ab4
> Bridge "ovsbr0"
> Controller "tcp:127.0.0.1:6633"
> Port "ovsbr0"
> Interface "ovsbr0"
> type: internal
> Port "vnet2"
> Interface "vnet2"
> Port "vnet0"
> Interface "vnet0"
> Port "vnet1"
> Interface "vnet1"
> ovs_version: "1.4.0"
>
>
> Can you please answer it now?
>
>
> On 7/12/12 10:52 PM, "Ben Pfaff" <[email protected]> wrote:
>
> >On Thu, Jul 12, 2012 at 10:49:14PM +0530, Neha Jatav wrote:
> >> I am running NOX controller with a python script that prints out the
> >> destination mac and the source mac for each packet arriving at the now
> >> controller and then floods it out. So here's what happening:
> >>
> >> With em1 connected, all the packets that arrive at em1 are coming to the
> >> controller and printing out the details. However, without em1 connected
> >>to
> >> the OVS, when I have the following setup:
> >> ____ ____
> >> / VM1\______br0_______/ VM3\
> >> \____/ | \____/
> >> |
> >> _|_
> >> /VM2\
> >> \___/
> >>
> >> VM1 & VM2 are of the same subnet. They can ping each other. The ping
> >> packets aren't seen at the controller probably because they are in the
> >> same subnet and they don't need a flow table entry.
> >
> >That doesn't make sense. OpenFlow doesn't make any distinction on
> >this basis.
>
> Ok.
> >
> >> VM3 is in a different subnet. So, when I ping from VM1 to VM3 or
> >> viceversa, they aren't reachable to each other. However, the packets do
> >> not arrive at the controller at all. Could you suggest me what might
> >> possibly be wrong.
> >>
> >> This is how the bridge looks:
> >>
> >> $sudo ovs-vsctl br0 show
> >> Bridge "br0"
> >> Port "vnet1"
> >> Interface "vnet1"
> >> Port "br0"
> >> Interface "br0"
> >> type: internal
> >> Port "vnet0"
> >> Interface "vnet0"
> >> Port "vnet2"
> >> Interface "vnet2"
> >> ovs_version: "1.4.0"
> >
> >No controller is configured.
>
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
