authenticate the remote gateways by using a tunnel type that includes authentication such as open vpn. Eric On Tue, Aug 27, 2013 at 3:17 AM, Marc, LX1DUC &lt;lx1duc(a)rlx.lu&gt; wrote: > (Please trim inclusions from previous messages) > ______________________________**_________________ > The idea of route servers/route reflectors isn't bad at all. > > However as some host might connect from dynamic IP addresses you will need > to come up with something additional to authenticate the remote gateways. > > 73 de Marc > > > Quoting Michael E Fox - N6MEF &lt;n6mef(a)mefox.org&gt;rg>: > > (Please trim inclusions from previous messages) >> ______________________________**_________________ >> 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 &lt;eric.fort(a)gmail.com&gt; >> Date: 08/27/2013 1:33 AM (GMT-08:00) >> To: AMPRNet working group &lt;44net(a)hamradio.ucsd.edu&gt; >> 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, &lt;Bob(a)qbjnet.com&gt; wrote: >> >> (Please trim inclusions from previous messages) >>> ______________________________**_________________ >>> No they shouldn't both be allowed. There isn't a way to dynamically >>> choose >>> the >>> route based on whether one or the other connection is up. Packets sent to >>> the >>> down route are simply lost. >>> >>> Regards, >>> Bob >>> >>> >>> "Eric Fort &lt;eric.fort(a)gmail.com&gt; says:" >>> > (Please trim inclusions from previous messages) >>> > ______________________________**_________________ >>> > are these 2 entries for a single route or 2 separate routes to a single >>> > destination? It seems to me they are actually separate redundant >>> routes >>> to >>> > the same /21. should redundant routes not be allowed? It would seem >>> quite >>> > the reverse that redundancy being useful and importaint these ought to >>> be >>> > allowed to stand so long as they are valid routes to the specified /21. >>> > >>> > Eric >>> > AF6EP >>> > >>> > On Thu, Aug 15, 2013 at 2:54 AM, G1FEF &lt;chris(a)g1fef.co.uk&gt; wrote: >>> > >>> > > (Please trim inclusions from previous messages) >>> > > ______________________________**_________________ >>> > > Hi Marc, >>> > > >>> > > No, there should not be two entries for one route and the portal >>> should >>> > > not allow this to happen, so I will look into how it occurred and >>> amend the >>> > > code as necessary. >>> > > >>> > > Thanks, >>> > > Chris >>> >>> -- >>> /~\ The ASCII | Bob Brose N0QBJ >>> \ / Ribbon Campaign | http://www.qbjnet.com/ >>> X Help cure | mailto:bob@qbjnet.com >>> / \ HTML Email | public key at http://www.qbjnet.com/key.html >>> >>> There are only 10 types of people in the world: Those who understand >>> binary, and those who don't >>> ______________________________**___________ >>> 44Net mailing list >>> 44Net(a)hamradio.ucsd.edu >>> http://hamradio.ucsd.edu/**mailman/listinfo/44net<http://hamradio.ucsd.e… >>> http://www.ampr.org/donate.**html <http://www.ampr.org/donate.html> >>> >>>