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 <[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
