Search Mailing List Archives
[mininet-discuss] Mininet 2.0.0 bug with MPTCP
wette at mail.upb.de
Sun Dec 1 12:03:22 PST 2013
Unfortunately, the bug is not limited to mininet 2.1. It's a kernel bug that seems to be present in any kernel version. However, i experience the bug less in newer kernel versions. I am currently running 3.11 and have to reboot less often.
Von meinem iPhone gesendet
> Am 01.12.2013 um 19:33 schrieb Josh Reese <reese5 at purdue.edu>:
> Hello. We are working on a project to build a data center topology inside of Mininet using MPTCP following in the style of this project:
> We have successfully patched our version of Mininet using the relevant MPTCP codes and are able to perform tests with the Fat Tree topology found here:
> We are in the process of designing some other topologies, namely a Dual Homed Fat Tree found in this work:
> The main difference, and challenge we are seeing right now, is that in this new topology hosts have 2 unique connections to edge nodes, as opposed to the 1 connection found in the Fat Tree. When we make this change, thus giving each host 2 ports, we notice that Mininet is unable to perform its cleanup properly. Specifically it will hang when trying to shut down its links and switches. In fact, we are seeing error similar to:
> [ 176.965603] unregister_netdevice: waiting for h1-eth0 to become free. Usage count = 1
> [ 185.508516] unregister_netdevice: waiting for lo to become free. Usage count = 2
> [ 187.245149] unregister_netdevice: waiting for h1-eth0 to become free. Usage count = 1
> [ 195.781125] unregister_netdevice: waiting for lo to become free. Usage count = 2
> [ 197.521721] unregister_netdevice: waiting for h1-eth0 to become free. Usage count = 1
> [ 206.053467] unregister_netdevice: waiting for lo to become free. Usage count = 2
> Which as suggested here: https://github.com/mininet/mininet/wiki/Mininet-2.1.0-Release-Notes point to some kernel bug. However, we are running Mininet 2.0.0. In addition we notice this only occurs when the hosts are given a second port to use. And, as noted on this page the only solution we can find is to reboot the system.
> We are wondering if the team there has any suggestions or ideas about this problem.
> mininet-discuss mailing list
> mininet-discuss at lists.stanford.edu
More information about the mininet-discuss