Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[mininet-discuss] In-Band Controller on Mininet

Jordi Palà jordipalasole at gmail.com
Wed Apr 9 03:16:14 PDT 2014


Hi Greg!

Now I'm trying to extend the topology with your configuration. I'm
implementing the conf on the next scenario:

                                host_2
                                    |
                                    |
                               switch_2
                                /         \
                               /           \
   host_1 --- switch_1            switch_3 --- host_3


The controller is host1. When I setup the configuration, the s2 and s1 are
working as expected. S3 is sending arp to 10.0.0.1 (controller) but s2
doesn't forward this arp to s1, so it can't establish the connection with
the controller. I've tried to add manually this arp rule, but s2 still
doesn't forward the tcp traffic to the controller.

I've seen in the following link that maybe I have to add some extra rules
in switch 2.

https://github.com/homework/openvswitch/blob/master/DESIGN

But I'm not sure the way they have to be added.

Again thanks for all, you're helping us so much.

Jordi


On Wed, Apr 9, 2014 at 10:35 AM, Jordi Palà <jordipalasole at gmail.com> wrote:

> Hello Greg,
>
> The problem is fixed!! It was an error of the VM. Now all is working OK!!
> Thank you very much for your effort!  :)
>
>
> On Mon, Apr 7, 2014 at 5:11 PM, Gregory Gee <gee.developer at gmail.com>wrote:
>
>> I haven't seen that error in my testing.  It seems to mean that the host
>> you are trying to start the controller in doesn't have an IP address on it
>> (run 'ifconfig' in the host).  Are you starting that controller from inside
>> one of the mininet hosts?  You shouldn't need to run sudo since you are
>> root already in the host.
>>
>> Greg
>>
>>
>>
>> On Mon, Apr 7, 2014 at 4:29 AM, Jordi Palà <jordipalasole at gmail.com>wrote:
>>
>>> Hello Greg,
>>>
>>> Thanks for all. We are trying to run your configuration but we have a
>>> problem with an IP address when we want to start the controller on host1.
>>> The output:
>>>
>>> sudo controller -v pctcp:6633
>>> Apr 04 04:09:22|00001|controller|ERR|pctcp:6633: connect: Address family
>>> not supported by protocol
>>> controller: no active or passive switch connections
>>>
>>> You mentioned that you had a problem with a IP MASK. We use the same
>>> configuration that you had used on the scripts of part1 and part2 (the
>>> first entry of the blog). Could you explain better the IP problem? I
>>> mean...what steps did you follow in order to solve it?
>>>
>>> Thanks,
>>>
>>> Jordi
>>>
>>>
>>>
>>> On Fri, Apr 4, 2014 at 5:45 AM, Gregory Gee <gee.developer at gmail.com>wrote:
>>>
>>>>
>>>>   I have finally been successful today running OVS in it's own network
>>>> namespace with the controller in-band.  You can see my progress and
>>>> conclusion at the links below.  I tried using the UserSwitch, but the
>>>> switch capabilities were too limited to get in-band control to work.  When
>>>> I tried using OVS, I ran into issues I just couldn't figure out.  Probably
>>>> related to all being in the root namespace.  I would have thought that
>>>> would work and maybe missing a small piece.  But when I ran each OVS in its
>>>> own namespace, I finally managed to get it to work.  Setup for getting each
>>>> OVS in a namespace was a pain.  it meant running an OVSDB and ovs-vswitchd
>>>> in each network namespace.   I'll need to figure out how to get what I did
>>>> into a custom switch class to make it easier for people to do.   But would
>>>> be glad if someone else gave it a try.
>>>>
>>>>
>>>> http://gregorygee.wordpress.com/2014/02/08/running-open-vswitch-in-network-namespace/
>>>>
>>>> http://gregorygee.wordpress.com/2014/04/03/running-open-vswitch-in-network-namespace-inband-controller/
>>>>
>>>> Greg
>>>>
>>>>
>>>>
>>>> On 31/03/2014 4:04 AM, Volkan YAZICI wrote:
>>>>
>>>> That blog post has some issues, search the mailing-list archive for
>>>> other in-band controller attempts. (Ahmad Soltani and I gave it a real
>>>> push, but we did not succeed.)
>>>>
>>>>
>>>> On Sun, Mar 30, 2014 at 10:19 PM, Jordi Palà <jordipalasole at gmail.com>wrote:
>>>>
>>>>> Hy,
>>>>>
>>>>>  We are trying to implement an In-Band control plane. We take this
>>>>> How-To:
>>>>> http://gregorygee.wordpress.com/2013/10/05/in-band-controller-with-mininet-part-2/
>>>>> .
>>>>> This script just start the external controller with an IP of a host,
>>>>> and then you have to start the controller service on that host.
>>>>>
>>>>>  With 1 switch the script goes well. We can see that there is OF
>>>>> traffic between the Controller and the SW1.
>>>>>
>>>>>  But when we add another switch (or two) with more hosts, we can see
>>>>> that the SW1 has OF traffic with controller but the other ones are NOT
>>>>> talking OpenFlow with Controller (but if we make a pingall, it's all ok).
>>>>>
>>>>>  If we get the dump-flows of every switch at the begining, before
>>>>> make a ping or something like that, we observe that SW1 has an extra arp
>>>>> route  to reach to the external controller (in this case, running on a
>>>>> certain host). The other switchs are empty.
>>>>>
>>>>>  We search on the .pys of mininet for a certain line that add this
>>>>> route but we didn't found it.
>>>>>
>>>>>  So, my question is: Does anybody know why Mininet only takes the SW1
>>>>> to add the route? Maybe, Is there some behavior that we ignore?
>>>>>
>>>>>  Thanks a lot!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  Once we run the script, we capture the traffic between
>>>>>
>>>>> _______________________________________________
>>>>> mininet-discuss mailing list
>>>>> mininet-discuss at lists.stanford.edu
>>>>> https://mailman.stanford.edu/mailman/listinfo/mininet-discuss
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> mininet-discuss mailing listmininet-discuss at lists.stanford.eduhttps://mailman.stanford.edu/mailman/listinfo/mininet-discuss
>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/mininet-discuss/attachments/20140409/1097f7cf/attachment.html>


More information about the mininet-discuss mailing list