Search Mailing List Archives
[mininet-discuss] In-Band Controller on Mininet
jordipalasole at gmail.com
Mon Apr 7 01:29:06 PDT 2014
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.
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?
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.
> 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:
>> We are trying to implement an In-Band control plane. We take this
>> 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
> mininet-discuss mailing listmininet-discuss at lists.stanford.eduhttps://mailman.stanford.edu/mailman/listinfo/mininet-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mininet-discuss