13 Jun
2015
13 Jun
'15
4:27 p.m.
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(a)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(a)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(a)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(a)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
> > >