Search Mailing List Archives
[mininet-discuss] ovs-vswitchd support?
rlantz at cs.stanford.edu
Thu Oct 27 10:31:32 PDT 2011
Comments inline - I'd suggest followup on mininet-dev if anyone is interested.
On Oct 27, 2011, at 12:46 AM, Parantapa Bhattacharya wrote:
> On Thu, Oct 27, 2011 at 1:37 AM, Bob Lantz <rlantz at cs.stanford.edu> wrote:
>> Hmm, I like it!
>> Good things it preserves from mininet:
>> - use of python as configuration language (this is key)
>> - hosts as shells in network namespaces
>> Good things it adds:
>> - built-in native interfaces
>> - namespace support in pure-ish python (crafty! though I wonder how you pick the library)
>> - vswitchd support
>> - actual class for links
> Thanks :)
>> Using the multiprocessing module is interesting. I didn't use call() since it fails with large numbers of file descriptors.
> Did you try close_fds parameter for call? Anyway i didn't hit the
> limit so it didn't bother me.
I do that, but the issue is with the parent, not the child.
>> One thing I'm puzzled by though: if you want to make it small, why use the Linux bridge at all? Open vSwitch replaces it, particularly with its bridge compatibility module.
> Mininet uses mnexec to call unshare, and execs bash for the shell. In
> python you can call native c libraries (shared not static) using
> ctypes module. So i just called unshare from my python shell using
> ctypes module.
1. Perhaps my wording was unclear - by "pick" I did not mean "load" but rather "select or identify", that is, how might you *identify the library's name* in a cross-platform, non-hard-wired way?
2. That doesn't answer the question: why include support for the linux bridge if you don't need to?
>> It reminds me of my original implementation(s) of Mininet, which just had the basic functionality in about 200 lines of code. Perhaps we (Mininet devs) can think a bit about reorganizing ("refactoring") the code to make it more modular so that a minimal core of code can be used standalone (this is almost true at the moment because of the different API layers, but the code is intermixed in the actual files.)
> It would really be appreciated. It would make submitting patches to
> mininet so much easier.
Patches/pull requests are still appreciated. ;-)
>> Heheh, I agree the screen hack isn't ideal. If you can create an elegant replacement, I'd be interested. In theory, one should be able to simply use a unix domain socket, but I wasn't able to get that to work immediately when I tried it a while back.
> I had actually two solutions. But both had some problems. First,
> inside the network namespace you create a custom pty pair and attach
> its master to a shell. On the root namespace you create a dummy
> terminal and attach the slave side of the pty pair to it (in xterm you
> can use -Sccn, on urxvt you can use -pty-fd, i didn't find options in
> other terminals). This works real well and there is no overhead of
> sockets or anything. But the again the terminal cannot know when the
> shell exits and the shell cannot know if the terminal exits. So if you
> accidentally close one you have to manually close the other which is
> quite irritating. The solution is to monitor both processes (across
> the namespaces) and close one if other exits. But i was to lazy to
> write that part :P
> The other solution is to use X forwarding. It is easy to have it if
> the network is properly set up. But that's mostly difficult to have in
> the mininet scenario. Since network access to root namespace is cut
> off we have to use other methods of IPC. I find named pipes very
> useful for this. Basically one needs couple of named pipes and two
> processes (i used socat) for forwarding on either side per X using
> program. On the plus side this allows any X using program to be run.
> So one can use gnome-terminal or xfce4-terminal and even firefox or
> wireshark. But has a very high overhead. It also has the same problem
> of cross namespace process monitoring.
It's easy to bridge to the root namespace (see hwintf.py and sshd.py) -
>> I think we can improve the topology support in mininet; currently we have a couple of mechanisms to do the same thing, which may not be optimal.
> I feel generating a topology is extremely easy since python is the
> configuration language and should be left to the users. Any fixed
> number of topologies is good for a fixed number of purpose. But it
> only increases code size and people complain when their required
> topology is not there. I was working with a few who were also working
> on mininet. And they were already writing their custom topologies. I
> think mininet is best for managing programmable network namespaces and
> it should stick to that.
Parametrized topologies are extremely useful; a library of topologies is also extremely useful; neither one prevents you building your own. One might also argue that having a mapping between graphs which can be computed upon, plotted, etc. is also useful.
>> On Oct 25, 2011, at 10:28 PM, Parantapa Bhattacharya wrote:
>>> I had tried to include ovs-vswitchd support in OVS some time back. But
>>> i found somthings in mininte that i disliked. So i cooked up a little
>>> version of my own which i called Piconet. Please check it if you like.
>>> Parantapa Bhattacharya
>>> mininet-discuss mailing list
>>> mininet-discuss at lists.stanford.edu
> Parantapa Bhattacharya
More information about the mininet-discuss