[ovs-discuss] Working simple inband example ?
Ben Pfaff
blp at nicira.com
Wed Apr 2 21:02:25 UTC 2014
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