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
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.

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 
> <mailto: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
>     <mailto:mininet-discuss at lists.stanford.edu>
>     https://mailman.stanford.edu/mailman/listinfo/mininet-discuss
>
>
>
>
> _______________________________________________
> mininet-discuss mailing list
> mininet-discuss at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/mininet-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/mininet-discuss/attachments/20140403/90a8e26c/attachment.html>


More information about the mininet-discuss mailing list