eth0:0 is a child of the parent, eth0. If the physical interface itself
dies, they both go down. You also cannot manually take down (ifdown
<interface>) eth0 without also taking down eth0:0. They function together
as eth0. However, when you have a multi-wan setup in this situation (which
is a real life setup in this case), the interface is binding to two ip
addresses with two different network routes. iproute2 routing entries are
utilized to direct in/out traffic to the correct network gateway,
depending on origination, and a failover script changes the default
outbound gateway from the parent's to the child's if a particular server
beyond the parent's gateway cannot be detected via the parent.
This is not an issue with the actual interface going down, but with the
route becoming unavailable on the parent (eth0) when the service
provider's network goes down on the parent. What I've discovered is that
Qmail remote natively binds to the ip address of the parent here unless
otherwise instructed, disregarding the default outbound gateway no matter
what. Hence the need for bindroutes or senderip, which I do believe can be
utilized to solve my problem.
So, the original question, I do believe, applies. There may be other
solutions, e.g. additional routing entries placed in failover script as
well to route traffic from one network to the other network, but either
way, I need to get qmail traffic to go out the child interface ip address
here instead of getting stuck in the queue on the parent interface ip
address. bindroutes and/or senderip should work as one solution though,
perhaps the simplest, unless I have to re-patch to use them.
Thanks!
Tim
On Thu, October 6, 2011 2:52 pm, Michael J. Colvin wrote:
Maybe I'm missing something, but other than administratively taking eth0
down, and leaving eth0:0 up, how would eth 0 go down and NOT take eth0:0
with it?
IE, a cable being bad, or the switch port that patch cable is plugged
into
going bad, is going to take eth0 AND eth0:0 down. They're both part of
the
same physical port, no?
Now, if you had eth0 and eth1, both different physical ports, with
different
physical connections, I could see what you're trying to accomplish...
Two
ip addresses doesn't necessarily mean two separate connections, just
because
you've bound them to a physical Ethernet interface and a virtual/sub
interface...
Mike
-----Original Message-----
From: Tim Pleiman [mailto:[email protected]]
Sent: Thursday, October 06, 2011 10:13 AM
To: [email protected]
Subject: [qmailtoaster] Is Qmailtoaster patched to be able to use these
Qmail Control Files?
I now have a toaster server with multiple ip addresses bound to the WAN
Nic. Qmail-smtpd automatically listens on both ip addresses inbound
(eth0
and eth0:0), but by default qmail-remote binds to only the first (eth0)
outbound.
In a situation where eth0 is down (with only eth0:0 available), this
causes qmail-remote to hold messages in queue until eth0 becomes
available
again. Are the following qmail control options available for
qmail-remote--e.g. patched into the toaster distribution? If so, what
would be the best configuration utilizing these control options--e.g. to
always have qmail-remote bind to the IP address on eth0 when available,
but to automatically fail to the IP address on eth0:0 when eth0 is not
available? Or would I need a script to update one of these control files
that executes automatically during a failover to the IP on eth0:0 when
the
IP on eth0 is not available?
bindroutes (qmail-remote)
Any mail sent from an specific source IP address will be sent from the
given IP address.
The entry in bindroutes looks like this:
source ip:ip
Example for bindroutes:
# network 10.x.x.x
10.:1.2.3.4
# network 10.10.x.x
10.10.:1.2.3.4
# network 10.10.10.x
10.10.10.:1.2.3.4
# host 10.10.10.10
10.10.10.10:1.2.3.4
# rest
:1.2.3.4
# don't send any mail to this
1.2.3.4:
If qmail-remote is not able to bind to that IP address then the message
will stay in the queue until the problem has been corrected.
senderip overwrites bindroutes.
and/or
senderip (qmail-remote)
Any mail sent from an email address in the given domain will be sent
from
the given IP address.
The entry in senderip looks like this:
domain:ip
If qmail-remote is not able to bind to that IP address then the message
will stay in the queue until the problem has been corrected.
--
Tim Pleiman
Bravo Systems Technologies
"Advanced Open Source Solutions for Business"
Chicago, IL USA
----------------------------------------------------------------------------
-----
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and
installations.
If you need professional help with your setup, contact them today!
----------------------------------------------------------------------------
-----
Please visit qmailtoaster.com for the latest news, updates, and
packages.
To unsubscribe, e-mail:
[email protected]
For additional commands, e-mail:
[email protected]
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and
installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and
packages.
To unsubscribe, e-mail:
[email protected]
For additional commands, e-mail:
[email protected]
--
Tim Pleiman
Bravo Systems Technologies
"Advanced Open Source Solutions for Business"
Chicago, IL USA
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and
installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and
packages.
To unsubscribe, e-mail:
[email protected]
For additional commands, e-mail:
[email protected]
