<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> <META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.14"> <TITLE>OT - fault tolerant default router for Nagios host. [SEC=UNCLASSIFIED]</TITLE> </HEAD> <BODY>  Dear Folks, I am writing to request comments on a proposal to reduce the risk of loss of Network visibility/spurious alerts etc caused by the failure of the Nagios host's default gateway. When the Nagios host is connected via multiple links, it is still necessary to ensure that data flow either both links or that somehow traffic is diverted to the other links. Solutions I have rejected include 1 Link teaming/bonding - immature in Linux 2 HSRP/VRRP - don’t want to change network structure to suit Nagios and I can't afford fibre links from Nag to a core switch in the 'other' data centre. Otherwise this is a fine solution 3 Load sharing - half the traffic will be dropped if a link fails Here is what I think is the best fit: an application layer (non kernel) fault tolerant router. This could be implemented by 1 a Nag service check of the reachability of the default router 2 an event handler (run by sudo) that replaces the default router if the check returns CRITICAL HARD. Your comments are very welcome. Thank you, Yours sincerely. Classification: UNCLASSIFIED </BODY> </HTML>