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 01:35:31 PDT 2014


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/6363dc71/attachment-0001.html>


More information about the mininet-discuss mailing list