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
