Postfix (Ubuntu 9.10 x64) said: 421 4.4.1 Connection timed out(in reply to end of DATA command)
in [Postfix]
|
Prev: Postfix (Ubuntu 9.10 x64) said: 421 4.4.1 Connection timed out (in reply to end of DATA command)
Next: Reject message
From: Stan Hoeppner on 28 May 2010 06:42 Ioannis Tsouvalas put forth on 5/28/2010 4:09 AM: > My guess so far is to go and lower the link speed between the Shorewall, > Postfix, and maybe even SBS2008, and that's because similar problems having > been encountered where the MTU is bigger than 1500. Now, the only reason I > haven't done it so far, is that the MTU is already set at 1500, and I'm not > sure if dropping the link to a lower speed or replacing the vmxnet3 with > vmxnet2 that supports lower speed, would do any good. 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
From: Mihira Fernando on 28 May 2010 07:40 On Fri, 28 May 2010 14:41:46 +0300 "Ioannis Tsouvalas" <tsouvalasi(a)atic.gr> wrote: > 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 > Are there any firewalls between the Postfix and Exchange Server ? Mihira.
From: Stan Hoeppner on 28 May 2010 08:55 Ioannis Tsouvalas put forth on 5/28/2010 6:41 AM: > 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, Per the list welcome messages, you should post the complete output of "postconf -n". This will aid members in solving your issue, if the cause of your problem is indeed related to your Postfix configuration. -- Stan
From: Stan Hoeppner on 28 May 2010 19:09 Wietse Venema put forth on 5/28/2010 9:37 AM: > Ioannis Tsouvalas: >>> >>> Ioannis Tsouvalas: >>>> 451 Requested action aborted: local error in processing >>>> 451 Temporary local problem - please try later > > These you can do nothing about, except perhaps retry when the remote > system is under less stress. > >>>> 421 4.4.1 Connection timed out (in reply to end of DATA command) >>>> 421 4.4.2 mxfront39.mail.yandex.net Error: timeout exceeded (in >>>> reply to end of DATA command) > > These could be a network-level problem such as broken IP path MTU > discovery, or TCP options that are mis-implemented by an and system > or by an intermediate system (such as a cheap firewall). IIRC from his initial post, Ioannis has 3 virtual machines atop ESXi: one a dedicated Ubuntu Shorewall instance, one running Ubuntu Shorewall (again) and Postfix, one running Microsoft SBS plus Exchange. A basic network diagram would be helpful at this point, although out of the scope of Postfix. At first glance this network setup seems an unnecessary mess of "geek toys", wrought with unneeded complexity for the sake of "neato!" complexity. Tandem packet firewalls across VMware guests? Ioannis, disable all the firewalls but for basic SPI NAT/PAT (if you're using NAT) on the dedicated Shorewall guest. Route TCP 25 inbound via a PAT rule to the Postfix guest. See if that eliminates the timeout and related TCP errors. -- Stan
From: Stan Hoeppner on 30 May 2010 13:54
Ioannis Tsouvalas put forth on 5/30/2010 9:47 AM: > Stan thanks for the reply, and please excuse me for the time interval in > between your post and my reply. "Geek" and "neato!" wasn't exactly what I > was aiming for, but still I appreciate that you identified the "geeky" > complexity of the idea that I had in my head on this implementation. I have > to admit that except the insight to get this thing going, you also did get > me searching through the dictionary! Nevertheless, based on the fact that I > highly appreciate anyone's time and thinking, I thought I should write back > first and then give it a try, so let me get back to you later on, today I > hope! > As far as the network diagram its hidden between the lines of my first post > (net,fw,dmz,loc - shorewall three interface firewall) but I will be more > thorough and descriptive if what I have at hand doesn't get me going. Hi Ioannis. Your Postfix errors seem to be TCP/IP related. All I'm suggesting is to eliminate everything possible that touches the packets in between Postfix and remote hosts. Once you've stripped all of it out and Postfix is working properly again, you can start adding things (f/w) back piece by piece until you break things again. This should help you identify the source of the problem. I.e. process of elimination. Also, reset all vmxnet devices to their default settings with the exception of custom VLANs you've created, assuming such custom VLANs are working properly. -- Stan |