[2.0] bug with big frames and device virbr0

[Raizo62]

Hi

I use Live Raizo ;-)
Live Raizo contains a device called "Live Raizo" who is a "Cloud Nodes" connected to virbr0 interface.

I use linked VBOX with vdi which are stocked on a NFS server (then big frame).

On my lab, i put 1 device "LiveRaizo" and 2 "remotes" devices (vdi on nfs server) and 1 local device (Debian), connected to 2 ethernet switch

Then often with my students, GNS3 seems to lost communication with server (progress bar takes very long times).

I kill GNS3, and i reload the project : I don't see the bug (i think)
I put on the lab and connecte the device "Live Raizo" in last, i don't see the bug (i think)

And, on my office computer, this bug occured only one time.

Has you idea, or tests that i can do to help you to understand ?

[julien-duponchelle]

Could you post a screenshot?

[Raizo62]

yes, but you will just see the lab (there are no error message), but perhaps is it that you want to see?

[Raizo62]

kali, Cible2 and Cible3 have their vdi on a nfs server

[julien-duponchelle]

Do you have special configuration on your virb0 or it's the default from libvirt?

[Raizo62]

I have not installed libvirt. I have created this interface with "brctl addbr virbr0"
On other case (no big frame), this device seems to work.

[julien-duponchelle]

I think something leak from your GNS3 virtual network that conflict with the virtual network.

Perhaps one of your VirtualBox in the GNS3 network has the same mac address as the Live Raizo VM.

[Raizo62]

Perhaps one of your VirtualBox in the GNS3 network has the same mac address as the Live Raizo VM.

There are no "Live Raizo VM" : LiveRaizo-1 is a device "Cloud Node" using virbr0. With my student, LiveRaizo is the OS of the host.
All VM are VBox then, all their mac address must beginning by 08:00..
It is few probable that mac address of virbr0 is beginning also by 08:00
But, i will verify....

I think more a bug as the cloud bug (#1829) : A server crashed because big frames.
But i don't see why traffic incoming to eth0 will be see by the server who is monitoring virbr0

[julien-duponchelle]

I think it's not a good idea to name something virbr0 if it's not a device from libvirt. It's very confusing and could create bug with software like network manager who use the naming schema for detecting the type of network interface (for example a veth need to start by veth). And I can't guarantee this will work fine in the NAT node.

It's a bridge to your eth0?

[Raizo62]

I think that i create virbr0 with the same method used by libvirt : brctl (but i can be wrong).
I must do this because you have changed and added the nat device. I think that libvirt is, now, less powerfull that fast-nat (I can choose the IP of virbr0).

They are no bridge between virbr0 and eth0.

This morning, i have do a TP and no student signaled me this bug. But this lab used less "nfs" device that the first TP

[julien-duponchelle]

What is connected to this bridge?

[Raizo62]

virbr0 is created with the command "brctl addbr virbr0"
The device "LiveRaizo" is a "Cloud Nodes" connected to this virbr0 interface.
The device "LiveRaizo-1" is a LiveRaizo connected to Ethernet Switch as on the screenshot.

[julien-duponchelle]

But I don't understand the purpose of a bridge connected to nothing else than the GNS3 topology. Why not using tap interface?

[Raizo62]

For example, i can use a Web Browser on LiveRaizo to see web pages on virtual web server.
I don't use nat device because i don't use nat property (to not disturbed my students)
I could create a tap interface (as on old version of Live Raizo), but i had must create bridge interface for "nat device", then i use it :-)

[julien-duponchelle]

What do you have when you run:

brctl show
iptables -S
route

Perhaps the bug occur only if your NFS server as a common IP with something in your network, due to an isolation error.

[Raizo62]

I think not. I choose very attentively the IPs of my virtual network in my TP.

But, today, i have do an another TP (with only 1 nfs vdi). I have not see bug. Perhaps my bug was an edge effect of an another bug who was corrected.

Friday, i could do (perhaps) a test to verify if this bug occurs again.

[julien-duponchelle]

Ok I close for the moment, we will reopen if we have more details and a way to reproduce.