<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css">body { font-family:'Times New Roman'; font-size:13px}</style>
</head>
<body text="#000000" bgcolor="#FFFFFF"><div>Hi Hunter</div><div><br></div><div>I run an ESXi host on a USDT system and use a USB3 LAN dongle to give me a seperate network for user/management traffic so I can use the onboard one for iSCSI. This was done following the artivle here:</div><div><br></div><div>https://www.virtuallyghetto.com/2016/03/working-usb-ethernet-adapter-nic-for-esxi.html</div><div><br></div><div>I note that that USB interface can be dropping packets all the time, not a big problem if the protocols can handle that and RDP etc suffers no real issues. But running something like TotalNetworkMonitor on a VM there you do see that there are up to 50% or so ping packets lost in its probes. </div><div><br></div><div>Could be that you are seeing a similar behaviour where the protocol doesn't handle lost packets too well...</div><div><br></div><div>regards</div><div>Dave</div><div><br></div><div><br></div><div><br></div><div>On Fri, 20 Jul 2018 03:15:34 +0100, Hunter Goatley <goathunter@goatley.com> wrote:<br></div><br><blockquote style="margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-left: 1ex">
Here's where we stand on our cluster communications errors: nothing
we did worked. We tried different ports on the switch. We tried
forcing 1Gbps. We tried forcing the port down to 10 Mbps. That
actually seemed to help slightly, in that we only lost
communications every 63 seconds or so, instead of every 15--60
seconds. But it would lose and re-establish connection to the
cluster every 63 seconds.<br>
<br>
So I decided to try setting up and using a TAP device, just to see
what would happen.<br>
<br>
Using the dedicated Ethernet card, it made no difference. It still
lost communications every 63 seconds.<br>
<br>
When I say dedicated Ethernet card, I probably should have stated
earlier that it's a USB -> Ethernet device plugged into the
system. I don't know what brand or model, but I can find out, if
anyone wants to know.<br>
<br>
So I decided to try tunneling through the "real" Ethernet port used
by the Linux system. After figuring out what to do for the missing
tunctl command under CentOS, I was able to set up a tunnel, and I
did "attach xq tap:tap0". I then booted the system and wonder of
wonders, miracle of miracles, it was seven minutes into the boot
(yes, it takes a long time, mounting a slew of disks that needed to
be rebuilt) before it lost communications. But it re-established
them immediately, and as of my typing this, it was been twenty-nine
minutes since that happened. No further drops. Normally, I wouldn't
think twenty-nine minutes is enough to prove anything, but when it
was dropping every 15--63 seconds for two solid days, this sounds
like a fix to me.<br>
<br>
So what does it mean? One thing it suggests is that the USB Ethernet
device may be buggy or bad. I mean, it seems to work OK for TCP/IP
communications, etc, but it sure sounds like it may be the part
responsible for the problems. Especially since tunneling through the
built-in Ethernet card seems to work and tunneling through the USB
device did not.<br>
<br>
These are the commands I used to set up the tap device for CentOS:<br>
<blockquote>
<pre>brctl addbr br0
ifconfig eno1 0.0.0.0 ; eno1 is the host's Ethernet device
ifconfig br0 XXX.XX.XX.XX up ; the IP address of the host system
brctl addif br0 eno1
brctl setfd br0 0
#tunctl -t tap0
ip tuntap add tap0 mode tap ; Replacement for tunctl on CentOS 7
brctl addif br0 tap0
ifconfig tap0 up
</pre>
</blockquote>
I then just did "xq attach tap:tap0" in the init file. I guess I
should set up a special MAC address, but I haven't yet, and so far,
nothing seems amiss.<br>
<br>
While I thought having a dedicated Ethernet device would be the
simplest thing, I can live with tunneling it through the shared
Ethernet device, especially since it works and the former does not.
;-)<br>
<br>
Thank you for all of your input over the past couple of days, and
thank you for all of your work on SIMH!<br>
<br>
Hunter<br>
<br>
</blockquote><br><br><br><div id="M2Signature"><div>-- </div><div><div><br></div></div></div></body></html>