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]
