[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