05-07-2013 04:50 AM
recently we have seen a slow response time when relaying from some servers through our C170/C160-kluster.
I ran a test program to send a simple message from an trusted client and resonse time were 20 seconds(!) to even get a prompt from the either of our two Iromport mailservers, and also an additional 20 seconds sending the actual text in the message.!!
What is the issue here, it should be much faster!!??
Normal mailflow is approx 2000-3000 messages per hour through the system and does not seem to be affected by the above behaviour
Someone to can hint me towards a solution?
Note. SSH logins are also extremely slow, login prompt are quick but after entering the username it takes about 15 seconds for the password prompt to appear. Related problem?
05-09-2013 05:23 AM
Hi Ulrik,
what you are describing sounds very much like a network related issue. What you should check on the appliances is the duplex, speed and interface settings. On the CLI run:
> etherconfig
Choose the operation you want to perform:
- MEDIA - View and edit ethernet media settings.
- VLAN - View and configure VLANs.
- LOOPBACK - View and configure Loopback.
- MTU - View and configure MTU.
[]> media
Also run netstat to check for any collisions.
Also, send yourself a support request using the supportrequest command, or via GUI: Help and Support. Once receivd in your inbox open the XML file and check the netstat output. It should be in more detail then you can run it on the CLI. Look for netstat -s and check the retransmission rate which could be an issue and slow down the performance. Further you should also check in your network such as cables, switch and firewall.
Best regards,
Enrico
05-13-2013 05:06 AM
Hi, thanks for the comment from Enrioco/Andreas.
The slow SMTP is a DNS reverse lookup issue, we had 20 seconds and its now set to 0 (zero) eg no timeout expected at all. (Made a support case about it and got help with the reverse timeout rather quickly).
There are no apparent network problems, both nodes seem to work fine without any errors/retransmissions.
No perfomace issues on firewall/switches either.
The SSH delay remains and i now have a separate case about this and hopefully we can sort out this as well.
May be some built in behavior in the ssh-server with resolving the connecting host and some delay in this...
Kind Regards
Ulrik
05-10-2013 02:13 AM
Hello Ulrik,
check your DNS for possible delays, the behavior with the prompts may indicate that reverse DNS hostname resolution may be lacking, this would also explain the slow SSH log in.
Another possibility would be a firewall with packet inspection running between the client you test with and the ESA.
To find out if any of this is the case, simply log on to the CLI of the appliance, and start an smtp communication with the IP of your listener. I.e:
CLI: telnet 10.10.10.10 25
Trying 10.10.10.10...
Connected to mail.example.com.
Escape character is '^]'.
220 mail.test ESMTP
mail from: test@example.com
250 sender <test@example.com> ok
If the banners return quickly here, you most likely have a problem with DNS resolution or packet inspection. To test DNS resolution, run nslookup with a host that is unlikely to be in your cache right now (or clear the dns cache with dnsflush)
CLI> nslookup pottery.com
A=54.243.105.88 TTL=30m
A=75.101.142.70 TTL=30m
CLI> nslookup 75.101.142.70
PTR=ec2-75-101-142-70.compute-1.amazonaws.com TTL=30m
Response times should get you a good idea if the issue is DNS related. In this case, check your DNS settings and make sure if you have a local DNS server configured that this is not the problem. You also may check routes in the network settings (not SMTP routes I mean). If the responses are quick though, then you definitely want to check if you have a slow firewall inbetween the testing client and the ESA
Hope that helps,
Andreas
05-13-2013 05:25 AM
Hi , thanks for your comments.
The SMTP delay was a reverse timeout issue. The delay is now 0 and is very quick in handling the SMTP connections. And the firewall is not a source of delay/slowness.
I've seen some reverse lookup messages in the system_logs related to connections from internal relayers and management server ssh connections
It seems that the appliance try to make a reverse lookup to the specified DNS-servers (which are setup as forwarding DNS only), and it fails since the internal names is not present on the external dns zone.
Even when i'm define explicit internal zones/servers to use it still tries to resolve the connecting host on the external DNS servers.
Is this "normal behavior" or so to speak by design?
Kind Regards
/Ulrik
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide