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

Gregory Gee gee.developer at gmail.com
Mon Apr 7 08:11:46 PDT 2014


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/20140407/b910de34/attachment-0001.html>


More information about the mininet-discuss mailing list