Forum Discussion

cmoates's avatar
cmoates
Icon for Nimbostratus rankNimbostratus
Dec 14, 2010

Multiple remote connections, return first responder?

This may be a post for the iRules section, but I wasn't sure, so I figured I'd start here.

 

 

I'm trying to send SMTP mail to a remote provider (unrelated to my company, just trying to send mail). We send this provider a lot of mail, and their servers are frequently broken. They have two IP addresses to connect to, and often, one of them will not respond at all. This means I have to wait for a TCP timeout before I can retry, significantly delaying delivery and tying up threads on my end.

 

 

 

Unfortunately, the remote provider has no desire to rectify this issue. So I'm trying to figure out if I can have some sort of internal role IP which my clients connect to on the F5. The F5 then attempts connections to both IP's simultaneously, and whichever responds first, is handed back to the local client. The other session is dropped.

 

 

 

I'm just not really sure where to start with this. Any suggestions?

 

 

 

Cheers,

 

Chris

 

config
design

6 Replies

Sort By
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Dec 14, 2010
    Hmmm...

     

     

    While you could do something with a local VS and over0riding their MX record at your own DNS servers, in that path lies madness... Especially when they move their servers...

     

     

    Do you not run a local SMTP relay internally? Remember SMTP isn't a real-time protocol...

     

     

     

    H

     

     

  • Chris_Miller's avatar
    Chris_Miller
    Icon for Altostratus rankAltostratus
    Dec 15, 2010
    Could probably make a pool containing the two IPs and some sort of health check?
  • cmoates's avatar
    cmoates
    Icon for Nimbostratus rankNimbostratus
    Dec 15, 2010
    I can't make a VS with remote IP's though, can I?

     

     

    And yes, SMTP isn't a real time protocol, and I'm reducing the time I'll wait for a TCP connection to help mitigate the issue, but what happens is that I'll end up with so many of these in my outbound queue that no mail is delivered to anyone, while the threads all spin on a TCP timeout.

     

  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Dec 15, 2010
    Yeah, remote poolmembers are fine. As long as you use SNAT (Or as long as the route back to the client is returned via the f5).

     

     

    H
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Dec 15, 2010
    Posted By cmoates on 12/15/2010 08:41 AM

     

     

     

    And yes, SMTP isn't a real time protocol, and I'm reducing the time I'll wait for a TCP connection to help mitigate the issue, but what happens is that I'll end up with so many of these in my outbound queue that no mail is delivered to anyone, while the threads all spin on a TCP timeout.

     

     

    Mmm... What sort of software are you using for your MTA? FWIW I used to run postfix with hundreds of thousands of emails per day... For slow sites, you can usually set a maximum number of connections to use.. e.g. 1... (AOL was usually pretty bad sometimes for this).

     

     

    postfix will also remember about bad relays... And will extend the time between attempts for ones that are continually bad.

     

     

     

     

     

     

    H

     

     

  • cmoates's avatar
    cmoates
    Icon for Nimbostratus rankNimbostratus
    Dec 16, 2010
    We make one initial attempt to deliver mail internally in our application before tossing it off to an MTA to sit in retry-land. While you and I may both know that SMTP isn't real time, the vast majority of the unwashed masses have gotten used to the fact that it operates like a real-time service most of the time, and so we're trying our best to accommodate them, while still maintaining our sanity. Since it's very rare that this provider's primary and secondary MX's are unavailable at the same time, I thought the F5 might provide a nice solution whereby minimal app changes are required.