Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 2 subscribers
  • Views 4931 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Climbing Concurrent Connections

Biffa
I've been experiencing problems with an ASL4.022 install as detailed  here 

To save the read, the symptoms were packet loss between the firewall and the router and huge lots of concurrent connections with 4+ day timeouts not dropping.

Basically I implemented QoS on SMTP reserving 512K for all other traffic turning my 2Mb/2Mb link into a 2Mb/512K link (for web browsers) which is working pretty well.

What happens is once a day a daily email is sent out to around 40K subscribers via IIS5's SMTP server on Win2k.

All the 4+day timeout connection traffic is from the SMTP server through the firewall to the various SMTP servers its connecting to sending the emails.

After the mail run, I go onto the mail server and do netstat commands to see the current connections its not showing any connections, I can even reboot the server and disable the SMTP server so I am SURE there are no connections from that machine out through the firewall (or pull the network cable) makes no difference, Astaro still has the connections showing.

The first time the mail goes out the Concurrent connections jumps from a normal 2-300 up to 2K+ and stays there till the next mail goes out, then it jumpst to 4K+ and I imagine if I keep it up it will jump 2K each time till some of the old connections eventually timeout after 4 or 5 days.

Why is Astaro keeping these connections alive even though the initiating machine isn't?

Has this issue been addressed in v5 of ASL, I can try upgrading and see if it fixes it however I'd prefer not to.

Or is it a IIS SMTP bug?

Any insight would be appreciated or I should I call support? 


This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to Biffa
    Ok, I've had a new router from the ISP, I've upgraded to ASL 5 on the firewall and the problem still persists.

       

    As you can see after each days email goes out the conncurrent connections grows and doesn't drop down to low numbers.  [:S]
  • 0 in reply to Biffa
    Hi Biffa,

    This looks to me like not correctly shutdown TCP connections.
    Once a TCP connection is established, the timeout for this Connection is appr. 4 days.
    If your mail clients , for any reason not disconnect TCP connections, they will be visible for those 4 days.

    If you have exactly the same mail behavior every day, i expect that the number will not climb after 4 days.

    in order to verify my thesis, plz take a look at the connection tracking table.

    log in as root and execute:

    cat /proc/net/ip_conntrack | less -S

    i think the third column shows the timeout value in seconds until the connection gets deleted from the connection tracking table.

    In all cases this is not concerning, as ASL can easily handle 16.000 concurrent connections in the smallest license and it easily scales up to 1.500.000 concurrent connections.

    regards
    Gert
  • 0 in reply to Gert Hansen
    Gert,

    Just curious, but is the 4 day limit what is coded into ASL?  I haven't bothered to look it up, but I could swear that the timeout for a TCP session is 2 hours.  I know I've run into some issues before where other firewall products remove a connection from the state table after 1 hour, so when the OS still thinks the connection is valid for an additional hour, the firewall ends up blocking the traffic.  The solution for that problem is to set the keepalives in the OS, so that idle connections are kept alive.

    Anyway, long story short, I'm just curious where the 4 days comes from?

    Thanks.
  • 0 in reply to Moby
    Well its the IIS5 SMTP server sending the emails, the timeout for Outgoing connections is set to 5 minutes on both incoming and outgoing connections.  [:S]

    The strange thing is that I get alot of collisions on the NIC connected to the router (with a crossover cable).

    The performance degradation is only on inbound traffic as well, with performance dropping on inbound to 56k modem speeds wheras the outbound speed stays the same.

    (tested with various bandwidth speed testers online, although mainly the adslguide.org.uk speetest)

    I've had a new router from the ISP and the problem still persists. Not sure really where to go from here with it. Today I'm going to try using the firewall as a relay rather than sending the emails through the packet filter, see if that helps. [:S]
  • 0 in reply to Biffa
    [UPDATE]
    Had the ISP's "trouble shooter" out today and there is a problem on the line between us and the exchange, they are going to replace the line. 
    [/UPDATE]
  • 0 in reply to Biffa
    HI Biffa, 

    those are good news.

    Just for completeneess, the default timeout for established TCP connections is 4 days.
    If you close the connection properly, the timeout is set down to 1, which that times out imidiatly.

    Now if the brocken line dropper certain packets, it can be that the connection tracking did never receive a connection shutdown, and therefore were active for 4 days.

    regards
    Gert
  • 0 in reply to Gert Hansen
    Thanks Gert,

    Perhaps a feature request should be if the connection is dead it should drop it in less time?
  • 0 in reply to Biffa
    Sorry to necro a really old thread, but I stumbled across it b/c I was having a similiar issue and wanted to add something to it that helped me figure out my issue.

    I, too, was having a concurrent connection daily report that would slowly climb up to the 12k range (and we only have 20 users and a few servers here). It would peak out and then suddenly drop to zero and start climbing again. I issued the following command at the CLI 

    sudo cat /proc/net/ip_conntrack | grep ESTABLISHED > log.txt


    Grabbed the log using WinSCP, brought it into Excel and was able to see the offending IP address. It was one of our network monitoring products.