[ovs-discuss] Working simple inband example ?
Ben Pfaff
blp at nicira.com
Thu Apr 3 14:47:55 UTC 2014
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 <blp at 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
> >>>>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.
> >>>
>
More information about the discuss
mailing list