Sure. I made these blog posts documenting my journey and how I
solved 'my issue'. :D
http://gregorygee.wordpress.com/2014/02/08/running-open-vswitch-in-network-namespace/
http://gregorygee.wordpress.com/2014/04/03/running-open-vswitch-in-network-namespace-inband-controller/
Actually, I think you saw reference to these in the Mininet mailing list.
Greg
On 04/04/2014 3:31 AM, Volkan YAZICI wrote:
Kudos Gregory! I think this in-band problem in mininet is equivalent
to Fermat's last theorem in math. Congrats again. BTW, it would be
awesome if you can share the steps that you took in a blog post.
On Fri, Apr 4, 2014 at 5:19 AM, Gregory Gee <gee.develo...@gmail.com
<mailto:gee.develo...@gmail.com>> wrote:
I figured out the problem I was having. It was a simple IP
address assignment issue. For the IP addresses that I gave the
internal bridge interfaces, I used a /32 prefix. I should have
given them the same /8 prefix that the host was using that had the
controller. Once I set the correct MASK, the controller started
getting control messages.
I got myself mixed up configuring the internal bridge interface
like a layer 3 loopback interface on a router instead of
configuring it like the IP address of an SVI/VLAN interface. I'm
glad that's all that needed to be done. I've finally been able to
complete my experiment of running multiple OVS on a host but each
in their own network namespace and talking to an inband controller
all inside Mininet.
Thanks for the push.
Greg
On 03/04/2014 10:47 AM, Ben Pfaff wrote:
OVS uses flooding and MAC learning to find the controller.
Yes, setting an IP is all that is needed.
On Thu, Apr 03, 2014 at 08:58:40AM -0400, Gregory Gee wrote:
So if there is no extra configuration required, how does
OVS know
which port to send the control traffic to the controller?
Are you
saying that setting an IP on the internal bridge interface
is all
that is required for inband control to work?
Greg
On 02/04/2014 5:02 PM, Ben Pfaff wrote:
OK.
No extra flows are needed, so this is a configuration
error or a bug.
On Wed, Apr 02, 2014 at 02:46:56PM -0400, Gregory Gee
wrote:
No, as you can see in the original email, the
11.0.0.1 and 11.0.0.2 are on
the bridge internal interface. Instead of the
interface being called br0
as in your example, they are called s1 and s2 in
my setup.
So I have the IP address set on the bridge
internal interface as needed.
What are the extra flows that I need to install
that tells OVS which port
to talk to the controller. My setup works fine if
I have the controller
out of band, but I can't figure out the extra
steps to make the controller
connection work if it is inband.
Greg
On Wed, Apr 2, 2014 at 12:06 AM, Ben Pfaff
<b...@nicira.com <mailto:b...@nicira.com>> wrote:
On Tue, Apr 01, 2014 at 10:49:16PM -0400,
Gregory Gee wrote:
I've been searching for quite a while
and experimenting but there
must be an extra step I am missing to get
a simple inband controller
example to work. Here is the simple
example topology.
s2---s1---controller
s1 = 11.0.0.1/32 <http://11.0.0.1/32>
s2 = 11.0.0.2/32 <http://11.0.0.2/32>
controller = 11.0.0.100/8
<http://11.0.0.100/8>
An example ovs-vsctl show.
Bridge "s1"
Controller "tcp:11.0.0.100:6633
<http://11.0.0.100:6633>"
fail_mode: secure
Port "s1-eth1"
Interface "s1-eth1"
Port "s1-eth2"
Interface "s1-eth2"
Port "s1-eth12"
Interface "s1-eth12"
Port "s1"
Interface "s1"
type: internal
ovs_version: "1.10.0"
# ovs-ofctl show s1
OFPT_FEATURES_REPLY (xid=0x2):
dpid:0000000000000001
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS
PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP
STRIP_VLAN SET_DL_SRC
SET_DL_DST SET_NW_SRC SET_NW_DST
SET_NW_TOS SET_TP_SRC SET_TP_DST
ENQUEUE
1(s1-eth1): addr:0a:a7:af:32:d9:7c
config: 0
state: 0
current: 10GB-FD COPPER
speed: 10000 Mbps now, 0 Mbps max
2(s1-eth2): addr:06:57:97:21:9f:d5
config: 0
state: 0
current: 10GB-FD COPPER
speed: 10000 Mbps now, 0 Mbps max
3(s1-eth12): addr:26:96:80:3e:77:12
config: 0
state: 0
current: 10GB-FD COPPER
speed: 10000 Mbps now, 0 Mbps max
LOCAL(s1): addr:36:21:10:be:02:43
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4):
frags=normal miss_send_len=0
# ifconfig s1
s1 Link encap:Ethernet HWaddr
36:21:10:be:02:43
inet addr:11.0.0.1
Bcast:255.255.255.255 Mask:0.0.0.0
UP BROADCAST RUNNING MTU:1500
Metric:1
RX packets:0 errors:0 dropped:0
overruns:0 frame:0
TX packets:0 errors:0 dropped:0
overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0
(0.0 B)
It looks like you put your IP address on a
physical (or virtualized
physical) interface. IP addresses need to be
on internal interfaces.
Please see the FAQ:
Q: I created a bridge and added my Ethernet
port to it, using commands
like these:
ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0
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.
You can restore functionality by moving
the IP address to an Open
vSwitch "internal" device, such as the
network device named after
the bridge itself. For example, assuming
that eth0's IP address is
192.168.128.5, you could run the commands
below to fix up the
situation:
ifconfig eth0 0.0.0.0
ifconfig br0 192.168.128.5
(If your only connection to the machine
running OVS is through the
IP address in question, then you would
want to run all of these
commands on a single command line, or put
them into a script.) If
there were any additional routes assigned
to eth0, then you would
also want to use commands to adjust these
routes to go through br0.
If you use DHCP to obtain an IP address,
then you should kill the
DHCP client that was listening on the
physical Ethernet interface
(e.g. eth0) and start one listening on the
internal interface
(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.
By the way, this issue is not specific to
physical Ethernet
devices. It applies to all network
devices except Open vswitch
"internal" devices.
_______________________________________________
discuss mailing list
discuss@openvswitch.org <mailto:discuss@openvswitch.org>
http://openvswitch.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
