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
Thu Apr 3 20:45:35 PDT 2014

   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 
> <mailto:jordipalasole at>> wrote:
>     Hy,
>     We are trying to implement an In-Band control plane. We take this
>     How-To:
>     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
>     <mailto:mininet-discuss at>
> _______________________________________________
> mininet-discuss mailing list
> mininet-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the mininet-discuss mailing list