Slow smtp connection response when relaying through ironport C170/C160...

[Ulrik Rosen]

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?

[Enrico Werner]

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

[Ulrik Rosen]

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

[Andreas Mueller]

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

[Ulrik Rosen]

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