alternate outbound delivery path

[thelmt_ironport]

looking for a method to have a C150 relay mail through another C150 if it is unable to deliver outbound messages to the internet (ie. looses internet connectivity in one of our data centers).

Each device is in a seperate data center with seperate Internet providers and we have private links that they can communicate over internal interfaces.

Was thinking I could do it with SMTP routes, but I haven't been able to come up with anything that works yet.

Thanks for your ideas.

[shannon.hagan]

You can do it at the point that one of them fails - we do this all the time where I work.

On both boxes, setup a sender group with a relay policy to accept mail from the other system.

On the box that no longer has internet connectivity:
1) export current smtproutes (if you have any - so you can return it to the orginal list easily)
2) clear the list
3) create the ALL smtproutes as your other gateway
4) delivernow (then pick all)

Now - if you don't like getting called in the middle of the night:
While your normal routes are there:
smtproutes export smtproutes.txt
smtproutes clear
smtproutes new ALL
smtproutes export disaster_smtproutes.txt
smtproutes import smtproutes.txt

Train your 24x7 personnel to login to the box when there is an issue and type:
smtproutes import disaster_smtproutes.txt
commit

delivernow all
logout


And when the problem goes away:
smtproutes import smtproutes.txt
commit

delivernow all
logout

[thelmt_ironport]

Thanks Shannonh, I guess I should say I'm looking for a more automated solution to this within the devices themselves. None of us like getting woken up at 2am ;)

Seems to me there should be some method for doing this. For inbound mail there is althost, smtp routes and other means of directing deilivery, but I guess I'm a bit mystified that within AsynOS there is no options to shape/reroute the outbound traffic dynamically based off link state, destination host unreachable or non-response. Having this in place could give you an automatic second attempt at delivery from the partner device. Who knows, maybe there isn't much benefit to having a second delivery attmpt, but when it comes to the earlier situation of loosing your ISP/Circuit/Interface, having a setting for partner delivery if attempted delivery fails would be a elegant solution within the devices.

Other ideas?

[chhaag]

The nice thing about Shannon's solution is all of those commands can be run via ssh from another UNIX server.

$ ssh admin@yourESA.com smtproutes import disaster_smtproutes.txt
$ ssh admin@yourESA.com commit
$ ssh admin@yourESA.com delivernow

Assuming you have your ssh keys setup.

So if you have a monitoring server watching the connection tot he Internet, it could run those commands when it detects the link is down. And run the revert commands when connectivity is restored.

cheers

[thelmt_ironport]

I'll go play around with that and see what I come up with. If I can get it dialed in, I'll post up my solution.

thx