[ovs-discuss] Working simple inband example ?

Volkan YAZICI volkan.yazici at gmail.com
Fri Apr 4 07:31:18 UTC 2014


Kudos Gregory! I think this in-band problem in mininet is equivalent to
Fermat's last theorem in math. Congrats again. BTW, it would be awesome if
you can share the steps that you took in a blog post.


On Fri, Apr 4, 2014 at 5:19 AM, Gregory Gee <gee.developer at gmail.com> wrote:

>
>  I figured out the problem I was having.  It was a simple IP address
> assignment issue.  For the IP addresses that I gave the internal bridge
> interfaces, I used a /32 prefix.  I should have given them the same /8
> prefix that the host was using that had the controller. Once I set the
> correct MASK, the controller started getting control messages.
>
>   I got myself mixed up configuring the internal bridge interface like a
> layer 3 loopback interface on a router instead of configuring it like  the
> IP address of an SVI/VLAN interface.  I'm glad that's all that needed to be
> done.  I've finally been able to complete my experiment of running multiple
> OVS on a host but each in their own network namespace and talking to an
> inband controller all inside Mininet.
>
> Thanks for the push.
>
> Greg
>
>
> On 03/04/2014 10:47 AM, Ben Pfaff wrote:
>
>> 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.
>>>>>>
>>>>>>
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20140404/945b9bb1/attachment-0002.html>


More information about the discuss mailing list