reply Stan Hoeppner put forth on 5/28/201 5:42 AM:
>The vmxnet 'NIC' is a virtual device, strictly a software driver. The >vmxnet driver communicates with the ESX kernel at the speed of system >memory, which on modern servers is over 10x faster than the 10 Gbe >signaling rate. There is no such thing as "link speed" in this >scenario as the interfaces are all software. Ethernet link speed, more >correctly called a link pulse synchronization, is generated by hardware >devices called PHYs. Link pulse is a hardware phenomenon. It doesn't >exist in phantom software drivers, in this case the vmxnet drivers. >Your issue is unrelated to the vmxnet "link speed" settings, unless >there is a bug in the vmxnet driver code. If you send an email from an >instance of Postfix running on a Linux guest to an instance of Exchange >running on a Windows guest, both guests running on the same ESX >physical machine, any communication between the two MTAs will occur via >direct memory copy. The data will never be sent to the physical NIC in >the server. The communication takes place through the ESX virtual >ethernet switch, which again is strictly software. > >-- >Stan Stan thanks for the reply, as well as the insight regarding the difference between soft and hard nic devices. The only reason I'm pointing out the link pulse as well as the MTU, is that my search so far points me towards that direction. Now if there is a bug within the driver, then I guess more communication errors would have occurred, and the issue wouldn't be isolated on the smtp communication. That unfortunately, leads me back to where I started, without even some hope on getting closer to the solution. Looking forward to further insight, - Ioannis __________ Information from ESET Smart Security, version of virus signature database 5152 (20100528) __________ The message was checked by ESET Smart Security. http://www.eset.com
