Re: [44net] Multiple gateways for same route

Eric, Today, the list of tunnels, whether distributed by the encaps file or via RIP, are really just a list of whatever is configured in the portal.  Even though they may be distributed by RIP,  RIP is being used merely as a distribution mechanism.  The existence of an entry in the list tells you nothing about whether that tunnel is actually up or not -- only that it has been configured in the portal.  So, even if there were multiple RIP speakers, you'd get the same info except for the main gateway/default route. What I think you're describing is more like a route reflector such as are used in Internet BGP networks.  The clients would identify themselves to the main gateway, and the main gateway would reflect that info back to all other clients.  That would provide the dynamic routing that would be helpful.  And, if the clients could announce additional routes to the server, we could have dynamic alternate routes.  Couple that with regional reflectors and the option to listen to more than one reflector so you can get dynamic default route, and I think we've got something. The code for BGP route reflectors is public domain, so I wonder if it makes sense to adapt it to RIP.   Michael N6MEF Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: Eric Fort <eric.fort(a)gmail.com> Date: 08/27/2013 1:33 AM (GMT-08:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] Multiple gateways for same route (Please trim inclusions from previous messages) _______________________________________________ ok, multiple static routes to the same place I can see why not.  We do have dynamic routing available to us though via RIP.  Would RIP or another routing protocol not handle this in the case of the route being unreliable and drop that route?  Why must routes be persistent rather than dynamic? In a larger sense and I realize we're not there yet it would seem that rather than having to know the routes to all other 44net hosts from boot it would be much easier to have each area (for instance each /16 or maybe in some cases each /24) to have a designated router (say at .1) or possibly use multicast to discover one's local router.  thus the initial config is simplified as it has a single route to the 44net gateway for it's area from which it may discover via dynamic routing other routes.  no more need to manually distribute and update a routing table.  This seems to be something to work towards. On Thu, Aug 15, 2013 at 7:55 AM, <Bob(a)qbjnet.com> wrote: