Makes complete sense. EIGRP would work well then in having multiple non-44net end points for 44-net traffic. It's costing by the lowest latency. So if for some reason the path to one BGP gateway is higher, it would automatically route to a lower latency BGP gateway. How you route between other IPIP endpoints would be entirely up to you.
On Sat, Jun 13, 2015 at 1:19 PM, John Wiseman john.wiseman@cantab.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ The IPIP mesh doesn't have a single point of failure. Sites on the mesh can talk to each other quite happily without UCSD. Only access from non-44 internet addresses and from those who like to play at being an ISP is lost, and I'm quite happy without either.
But then I'm a radio ham first and foremost, not someone trying to show how clever I am at IP networking.
73, John G8BPQ
-----Original Message----- From: 44net-bounces+john.wiseman=cantab.net@hamradio.ucsd.edu [mailto:44net-bounces+john.wiseman=cantab.net@hamradio.ucsd.edu] On Behalf Of Don Fanning Sent: 13 June 2015 21:06 To: AMPRNet working group Subject: Re: [44net] Strange Broadcasts...
(Please trim inclusions from previous messages) _______________________________________________ Alright, let's take this a different route.
What would it take to make IPIP mesh more robust?
If BGP capable nodes were to announce and route for IPIP endpoints within it's endpoint, that would remove the SPOF at UCSD. IPIP would also get the benefit of possibly routing EIGRP between IPIP mesh sites so that if one BGP route were to have catastrophic failure, another BGP announced route would already be announced and EIGRP would route to that end point. Would mean a bit more traffic over RF reliant upstream networks but I think we have the technology for that.
The software package tinc does a fine job of creating dynamic self polling mesh vpn networks (example: CCC ChaosNET). If you were to employ the quagga suite on top of that, you could preference out your routes among the tinc endpoints. BGP would announce that the end point is available at whatever depending on the highest quality of the EIGRP link.
http://blog.ine.com/2009/05/01/understanding-unequal-cost-load-balancing/
On Sat, Jun 13, 2015 at 12:30 PM, Nigel Vander Houwen nigel@k7nvh.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Rob,
Thank you for making my point. The reason you can't use a 44/8 address
for
a tunnel endpoint is because routing is broken.
Nigel
On Jun 13, 2015, at 12:24, Rob Janssen pe1chl@amsat.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ Rob Janssen wrote:
When you put up a system that announces a BGP route on Internet, you
should also make
that system part of the IPIP mesh for the same subnet that you
advertise on BGP.
... with a tunnel endpoint address that is OUTSIDE network 44.0.0.0/8
Rob