virtualbox.org

Hello. I am from Russia, sorry for my bad english

I have a problem:
Me have a host in Win2003R2 and guest virtual machine Win2003R2

in guest machine i use programm "PRTG Traffic Grapher V6" he have many sensors (750+)
Which means a lot of packets per second.
And the network interface on the guest (virtual) machine stops flowing traffic for a few minutes, a couple of minutes the traffic begins to walk again, but then again permanently blocked.
If you use a network bridge instead of NAT, then there is no such problem, but I want that kind of NAT.

I cannot imagine why you want to run this in NAT mode. You are trying to monitor traffic on the network. Why would you run it from a machine which is only indirectly connected to the network via NAT? Clearly NAT can't handle the volume of traffic.

But why can not cope? There's really little traffic, kilobits. Just a lot of small packets to different hosts.
As if triggered some kind of firewall and restricts traffic for a while, even ping the gateway does not pass to the guest machine (that is to 10.0.2.2)

in Vbox.log:

..............................................
21:36:52.548369 NAT: link up
21:36:58.741703 NAT: link up
21:37:48.224347 NAT: link up
21:37:54.444865 NAT: link up
21:39:00.067851 NAT: link up
21:39:10.335423 NAT: link up
21:39:16.474474 NAT: link up
21:40:20.252432 NAT: link up
21:40:30.459788 NAT: link up
21:40:42.687890 NAT: link up
21:40:52.888123 NAT: link up
21:41:01.059072 NAT: link up
21:41:17.500711 NAT: link up
21:41:40.075750 NAT: link up
21:41:46.253487 NAT: link up
21:41:52.361296 NAT: link up
21:41:58.542534 NAT: link up
21:42:08.896877 NAT: link up
21:42:19.159991 NAT: link up
21:42:33.521514 NAT: link up
21:42:39.669421 NAT: link up
21:42:56.041914 NAT: link up
21:43:02.175416 NAT: link up
21:43:08.348092 NAT: link up
21:43:18.690913 NAT: link up
21:44:00.374758 NAT: link up
21:44:06.683877 NAT: link up
21:44:16.908772 NAT: link up
21:44:27.175033 NAT: link up
21:44:37.349349 NAT: link up
21:44:47.569446 NAT: link up
21:44:59.811336 NAT: link up
..............................................

how debug this?:)

I have read a few posts on the forum of persons with the more recent versions of Virtualbox (perhaps 4.3.22 & onward) having network issues. I have nothing definite to suggest except to re-title your post to remove the guest type & add that NAT drops out and Bridged stays connected - this may attract others who may have solved the problem. Look through the first couple of pages on the forums to find these other posts, maybe a suggestion is available. Also, drop back to 4.3.12 temporarily and see if the issue goes away.

Please try with the following test build: https://www.virtualbox.org/download/tes ... 78-Win.exe

Yes, there are some rather bad NAT regressions in 4.3.22 and 4.3.24. Even 4.3.26 isn't lint clean for some users, which the above build tries to address. If there is still some hiccup, please provide VBoxSVC.log (in %USERPROFILE%\.VirtualBox) as it contains the information triggering the link flaps.

mcdemon wrote:But why can not cope? There's really little traffic, kilobits. Just a lot of small packets to different hosts.
As if triggered some kind of firewall and restricts traffic for a while, even ping the gateway does not pass to the guest machine (that is to 10.0.2.2)

Do you mean that you cannot ping 10.0.2.2 from the guest?

mcdemon wrote: in Vbox.log:

..............................................
21:36:52.548369 NAT: link up
21:36:58.741703 NAT: link up
21:37:48.224347 NAT: link up
21:37:54.444865 NAT: link up
..............................................

Is that complete fragment of the log or just some selected lines? If it's stuck in infinite "link up" that this may be a bug in E1k driver. Ticket 13236 is probably the same problem, though there's no specific info there.

I was able to reproduce this "infinite link up" problem myself only a few times, not reliably and it would take some 2-3 hours to trigger, so I was unable to do much progress in debugging it. If you see it and can trigger it reliably, I'd be interested in your traffic patterns that trigger it.

klaus wrote:Please try with the following test build: https://www.virtualbox.org/download/tes ... 78-Win.exe

Yes, there are some rather bad NAT regressions in 4.3.22 and 4.3.24. Even 4.3.26 isn't lint clean for some users, which the above build tries to address. If there is still some hiccup, please provide VBoxSVC.log (in %USERPROFILE%\.VirtualBox) as it contains the information triggering the link flaps.

link not worked

I have reproduced the issue again on 4.3.26 and post the log files

vushakov wrote:

mcdemon wrote:But why can not cope? There's really little traffic, kilobits. Just a lot of small packets to different hosts.
As if triggered some kind of firewall and restricts traffic for a while, even ping the gateway does not pass to the guest machine (that is to 10.0.2.2)

Do you mean that you cannot ping 10.0.2.2 from the guest?

Yes. While when there is a problem, the gateway also not ping.

vushakov wrote:

mcdemon wrote: in Vbox.log:

..............................................
21:36:52.548369 NAT: link up
21:36:58.741703 NAT: link up
21:37:48.224347 NAT: link up
21:37:54.444865 NAT: link up
..............................................

Is that complete fragment of the log or just some selected lines? If it's stuck in infinite "link up" that this may be a bug in E1k driver. Ticket 13236 is probably the same problem, though there's no specific info there.

I was able to reproduce this "infinite link up" problem myself only a few times, not reliably and it would take some 2-3 hours to trigger, so I was unable to do much progress in debugging it. If you see it and can trigger it reliably, I'd be interested in your traffic patterns that trigger it.

Do you happen to speak Russian? Very hard for me to answer in English

mcdemon wrote: Yes. While when there is a problem, the gateway also not ping.

Since you can reproduce the problem in a few minutes, please, could you run a test build with some additional debug logging enabled? I have uploaded it here.

You will need to use something like Debug View to get the logs from the kernel.

Please, start Debug View with run as Administrator, then start your VM. After you have reproduced the problem, please, provide the VM's VBox.log file and the log from Debug View.

mcdemon wrote: Do you happen to speak Russian? Very hard for me to answer in English

Yes