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] More than 256 ovs switches

Gary Brown uvugdbrown at gmail.com
Tue Dec 3 22:35:50 PST 2013


Thank you for your reply, Bob.
I did not know about the ability to set the datapath id, which is what I
will do.  I was also expecting to do my own controller, but needed a way to
detect which switch I was dealing with, and your datapath id answer will
fit the bill perfectly, and answers my question I submitted a few minutes
ago about the correlation between switch name and datapath id (none, unless
one makes it so by setting the datapath id).
Thanks for the answers!

Gary D. Brown



On Tue, Dec 3, 2013 at 11:21 PM, Bob Lantz <rlantz at cs.stanford.edu> wrote:

> The default controller will certainly not work, as it implements an
> Ethernet bridge without STP (which you don't want anyway since it would
> remove most of your links!) I expect you will need to create your own
> controller. Which should be relatively straightforward and fun for a torus
> topology.
>
> I also recommend starting with a very small topology, like 4x4 rather than
> 16x16, and getting your controller working with that topology first.
>
> Regarding dpid, you can probably set it yourself using something like
> addSwitch( 's%d' % num, dpid=('%016x' % num ) )
>
> Depending on your kernel, you may also wish to deactivate IPv6 in each of
> your mininet hosts to avoid lots of neighbor discovery packets.
>
>
> On Dec 3, 2013, at 9:45 PM, Gary Brown <uvugdbrown at gmail.com> wrote:
>
> Thank you to everyone who replied to me privately.
> I have not run a controller, so I assume the default controller is
> operational.
> So far, all I had done was define a 3D torus topology in Mininet using a
> topo module I wrote, which worked fine for a smaller network as long as the
> quantity of vSwitches does not seem to exceed 128-132 or so.
> However, when running Mininet from a putty window and while it was setting
> the ARP table for the hosts (one host per vSwitch) to prevent an ARP storm,
> my putty windows (I had two open) would get a "PuTTY Fatal Error" message
> of "Network error: Software caused connection abort".  At that point they
> were completely non-responsive and I had to close them.
> When I tried to reconnect with a new putty window, I got a "Network error:
> Connection timed out" error and could only use the VM console.
> Through the console I later found Mininet (mn) was still running along
> with 576 "bash" processes (one per 288 hosts and 288 vSwitches) and
> according to top, ovs-vswitchd was consuming ~75% of the CPU and
> ovsdb-server was consuming the remaining 25%, which probably explained the
> putty windows failing.
> I found when I ran Mininet in the VM console window, that I had no problem
> creating many switches.  It appears when creating the static ARP tables
> after creating the hosts and then creating the switches and their links
> that the OVS daemons mentioned above basically kill the VM's performance
> and I lose the non-console windows, which was not apparent until I
> attempted to hit a key (e.g. ctrl-c) in a window and it timed out.
> Mininet is creating the large number of switches I wanted; I just cannot
> do it from any window excepts the VM's console window as the other windows
> do not get any CPU cycles in a timely manner.
> After discovering this problem and finding I have to use the VM's console,
> I have been able to create large numbers of switches.  To use other windows
> to the VM, I just have to wait until after Mininet has finished creating
> the hosts and switches and linked everything up before I can use
> non-console windows successfully.  The fact the windows became unresponsive
> had appeared to me as a Mininet failure, when in fact, it had not failed at
> all, just the windows had.
> Well, just another odd set of facts learned!
>
> --
> Gary D. Brown
>
>
> On Tue, Dec 3, 2013 at 8:10 PM, Brian O'Connor <bocon at cs.stanford.edu>wrote:
>
>> Sorry, fixLimits is actually called the first time a Mininet object is
>> instantiated (either using "mn" or in a custom script).
>>
>> If you are using a custom script and you are using a Mininet object, you
>> should be able to create 500+ switches (although it might take awhile).
>>
>> If you are using the lower level API (creating Host and Link objects
>> directly), then you may need to call fixLimits to limit the file descriptor
>> limit.
>>
>> - Brian
>>
>>
>> On Tue, Dec 3, 2013 at 7:04 PM, Brian O'Connor <bocon at cs.stanford.edu>wrote:
>>
>>> Hi Gary,
>>>
>>> The limit appears to be related to the file descriptor limit.
>>>
>>> When you invoke "mn" from the command line, we run util.fixLimits to
>>> increase the number of allowed file descriptors.
>>>
>>> If you are running a custom Python script, you can try:
>>>
>>> from mininet.util import fixLimits
>>> fixLimits()
>>>
>>> - Brian
>>>
>>>
>>>
>>> On Thu, Nov 28, 2013 at 7:19 AM, Gary Brown <uvugdbrown at gmail.com>wrote:
>>>
>>>> I am trying to recreate an actual network topology experiment I did
>>>> this past summer that requires 288 vSwitches, but when I use Mininet to
>>>> create the network, I get an exception at about 256 switches (highly
>>>> suspicious) and Mininet cleans everything up and quits.
>>>> I have seen posts on this mailing list indicating people are creating
>>>> experiments with more than 256 switches, up to 1024 and even 1200.  My
>>>> online searching has indicated ovs switches have a limit of 256 switches
>>>> (see Limits at bottom of webpage at
>>>> http://openvswitch.org/cgi-bin/ovsman.cgi?page=vswitchd%2Fovs-vswitchd.8
>>>> ).
>>>> Has anyone been able to create more than 256 ovs switches and if so,
>>>> how did you do so, or at least how did you raise the limit?
>>>> I am using the standard Mininet 2.1.0 VM running Ubuntu 13.04 inside
>>>> VirtualBox 4.2.18 r88780 on a Windows 7 laptop with Core i7 (Ivy Bridge)
>>>> and 32 GB of memory.
>>>>
>>>> --
>>>> Gary
>>>> M.S. student, University of Utah
>>>>
>>>> _______________________________________________
>>>> mininet-discuss mailing list
>>>> 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
>
>
>


-- 
Gary D. Brown
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/mininet-discuss/attachments/20131203/6679d71f/attachment-0001.html>


More information about the mininet-discuss mailing list