Multipath Failures

Danita, when emails are stuck in the spool, what appears in the SMTP log when you try to force them to be sent?  Also, what do you observe that makes you say that all internet functions are "impaired?"  Please show a picture of the multipath rule for SMTP.

Cheers - Bob

On the issue of the mail queue, this was actually back before I was using the Astaro mail proxy.  This was just a postfix queue on another Linux server, and it would simply get 450 host down errors.  I'd wake up in the morning to a text message sent from the server complaining that I had 800 messages in the postfix mail queue, and the Astaro would show an "error" (but up) on the DSL line, and mail would not go out.

This week, after my retry of multipath, I had the following happen (both interfaces showing up, green, and okay at the time).

1.  VOIP phones would hear a dial tone, but we could hear no ringing or anything on the line.  The phones were, however, dialing and people on the other end were picking up and speaking.

2.  Web browsing was slow or just stopped.  For example, just putting a search string in the "google bar" at the top of Firefox and trying to search would take minutes.  It wouldn't just flat out say "no one's home" but it would be very very slow.

3.  Video streams from YouTube would stop, start, stop, start, etc.

I only have two multipath rules right now - they are pretty simple:

Source:  Any
Service: SMTP
Destination:  Any
By Interface: DSL

and

Source:  Any
Service:  Web Surfing
Destination:  Any
By Interface:  Cable

When things are "working" both of these rules work just fine.  Also, if I totally disable one of the interfaces, Astaro reroutes all of the traffic to the other interface without issue.   But I only had the system back on Multipath for something like 4 days before the  problems became so severe that I had to switch back to failover - which works perfectly, but kinda makes me wish I hadn't let Qwest talk me into the 1.5 > 7 meg upgrade :-)  On the other hand, when we would fail over from 12 Mbps to about 1.5 Mbps it was pretty painful, so the failover is better than nothing.  I just think it would be nice to use multipath if I wasn't having to babysit it so much!

I also have only one masquerading rule - Internal Network > Uplink Interfaces

Danita

The phenomenon you describe sounds like your Multipath Rules aren't working, and that the traffic is just being balanced.  Normally, when using the mail proxy and the web proxy, "Uplink Primary Addresses " will work for sure for the 'Source', but I don't know that the "Any" object will work.

Once you change that and you confirm that solves your issues, you might want to change the persistence to "by Source/Destination" for HTTP and to "by Destination" for SMTP.

Is it working now?

Cheers - Bob
PS I corrected "External (Address) to "Uplink Primary Addresses."  I just found a post by one of the Astaro developers last year confirming that the only proxy that passes original, internal IPs through Uplink Balancing is the HTTP/S Proxy.  The others, including SMTP, don't have an internal IP as the source of the packet.  I think "Any" should work with 7.5 or later though.

This is a bit confusing.  I have two different NICs of course related to the "External (Address)".  One is indeed named "External (Address)" as it was created originally by the wizard.  For this purpose it is my DSL line.  Later, when we added the Cable connection, I created a new configuration for it, of course, and it is defined as "Comcast (Address)". 

So, if I want all port 25 traffic to go out the DSL line, I can't see how defining the source as "External (Address)" (which is essentially the DSL line itself) works.  It would seem to me that the source should be "Internal" if anything.  I guess I need an educational moment here!

So that's the query right now on the SMTP.

Also, on the HTTP(S) traffic, while MOST of the traffic out via HTTP is indeed through the proxy, not all is, and some IP addresses are specifically excluded from the proxy and are allowed direct access without going through the transparent proxy.  So, again, the "External (Address)" doesn't readily make sense to me, and perhaps that's just because I really don't understand the terminology or something.  I would have thought that at a minimum, the source should be "Internal (Network)".

Is there some reading material on all of this other than just the help file that might clarify it for me?

Thanks.

Danita

There's a couple docs in the support center / knowledge base on multipath:
https://support.astaro.com/support/index.php/Category:Uplink_Balancing_and_Multipath

I previously found the examples in the "Multipath and Uplink Failover Guide" helpful.

Barry

Correction: I originally said "External (Address)" in Post #4 above, but I've corrected it to say "Uplink Primary Addresses."

You're right, I was just coming back to edit my post.  I was thinking of the QoS rules. "Any" should work with the Astaro SMTP Proxy; you could use "Internal (Network)" or the Host Definition for your internal mail server if you weren't using the Astaro Proxy.  Likewise, without the Astaro HTTP/S Proxy, you would want "Internal (Network)", but "Any" should be used with the Proxy.

What happens if you make the change in Persistence to "by Source/Destination" for HTTP and to "by Destination" for SMTP?

It would be interesting to see a few lines from the 'Content Filter HTTP/S' log when the problems are occuring.

Cheers - Bob

What happens if you make the change in Persistence to "by Source/Destination" for HTTP and to "by Destination" for SMTP?

How does making the persistence "by Destination" ensure that SMTP traffic will by default go out the DSL interface?.  The reason I made the persistence by Interface, is that is the only way I see to send all SMTP traffic out a desired interface.

Today we went all day without any hiccups, so I'll try to get the log entries during a failure the next time one pops up.  I should be around for a couple of weeks to monitor.  I just don't want to be away for my European vacation and have the traffic come to a screeching stop while I'm away!

Thanks!

Danita

I think the reason most people bind SMTP to one interface is because they have no RDNS record(s) for their other IP(s).

I hope you get problems while you're still on this side of the pond! [;)]

Cheers - Bob

Well, in my case, the reason for wanting specific types of traffic to go specific ways is really more "just cause I like it" :-) 

For example, our DSL line is of course slower than our cable line.  For that reason, I'd prefer HTTP traffic for internal users to go out the faster interface.  Conversely, SMTP traffic is generally smaller and less burdensome, and it will not benefit overall by using up the faster cable bandwidth.  So in my mind it makes sense to "prefer" HTTP traffic to utilize the faster interface, while keeping the smtp traffic out of the way of the kids wanting to stream hulu all night!  I have RDNS set up for all of my IP addresses, so it really doesn't matter which way the wind blows as far as the outbound traffic really goes for SMTP, other than my own personal preferences.

I did have one instance back when we were using Vonage (we changed to ViaTalk 18 months ago) where if I didn't tell the VOIP traffic to use the DSL (much slower at that time) line, we would have horrible VOIP results.  It was funny that sending the Vonage traffic over the cable was almost unworkable, while sending it over the DSL was perfection.  So, on my first try for multipath, I had a specific rule to force VOIP traffic to DSL.

I have a combined "home/business" network, so the needs of my users (children) are generally different than the needs of my customers!

Danita

That makes sense.  In V8.2, you'll be able to weight the use of the the two different links so that you can maximize throughput by using both connections.  I'm hoping to be able to roll that out to my customers at V8.202+ in August.

Cheers - Bob