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 <[email protected]> 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
s2 = 11.0.0.2/32
controller = 11.0.0.100/8
An example ovs-vsctl show.
Bridge "s1"
Controller "tcp: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
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
