jm-boley
commented
9 years ago This sounds very similar to the problem I was experiencing, the switch misbehaving under load, though I didn't have the crashing symptoms you're experiencing. I'd try checking /var/log/messages to see if the TCP stack or anything else is logging any errors that coincide. Grepping for ofdatapath might give you some results in that case. In mine, I found that the switch was trying to push out packets that exceeded the MTU, so you might want to see if yours is doing something similar. I'd also try running iperf in UDP mode (-u) to see if the crashing persists. If it doesn't then our cases may have a similar root cause.
If you're at all familiar with the linux system call API, running strace -ff -o <trace file name> mn <options> might not be a bad idea. Since the process seems to be crashing you could try grepping for SIGCHLD, any child process that exits with a non-zero status code (e.g., you'll often see 1) is usually failing out. That should put you on the trail of the child process that's dying and let you zero in on whatever system calls it's trying to make that are failing. You might also try grepping for SIGKILL or SIGTERM just in case it's being killed off by another process, though I'm not aware of any that would off the top of my head.
Anyway, best of luck.
lyndon160
aneesalnajjar
fr6nco
In mininet, using the CPqD switch I run two hosts connected together through one switch. This switch is controlled by a ryu simple switch 13.
After doing an iperf or large wget between two hosts communication fails and the switch has to be restarted for any communication to continue.
Pings and wget of small files work fine.