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 > >

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 > > >

If you were to have an IPIP link that for some reason the route between ISP-A and ISP-B were terrible/dead, you could delete that route from ripd (or set a higher cost on it) and it would go to the default route, into EIGRP and find a better way to route to that subnet. On Sat, Jun 13, 2015 at 1:31 PM, Don Fanning <don(a)00100100.net> wrote:

How does DL and LX figure out which is the better route for your traffic? BGP just says your there and to send me traffic. EIGRP could talk between DL and LX and say, "I'm a faster route for YO2LOJ, make me the preference for traffic coming in." It would also allow you to load balance your traffic between DL and LX rather than having a fail over route and the time incurred by everyone sending BGP announcements during the shuffle of routes. On Sat, Jun 13, 2015 at 1:50 PM, Marius Petrescu <marius(a)yo2loj.ro> wrote:

So what you've done is replace IPIP with VPN (pptp/l2tp) as the primary circuits with IPIP as the fall back. You still have dropped packets while DL and LX converge their routing tables should one of those sites go down. If both sites go down, then you'll fail back to IPIP. Worse case scenario, sure. But not the most efficient or elegant solution. You would then lose traffic during that BGP convergence coming between non-44 and 44net. If you're doing repeater linking over 44net, those are lost conversations. On Sat, Jun 13, 2015 at 2:20 PM, Marius Petrescu <marius(a)yo2loj.ro> wrote:

On Sat, Jun 13, 2015 at 2:59 PM, Bryan Fields <Bryan(a)bryanfields.net> wrote: For someone who's on the ARDC technical committee, you seem to be pretty apt at shooting down solutions rather than implementing them. Yes. And you're also not the boss of my subnet either. How else do you proposed routing non-44net traffic into 44net without creating routing loops and without breaking the current infrastructure on a global scale? People already have tunnels. I'm talking about delivering traffic. Code or it didn't happen. Oh wait, spec isn't code.

On Sat, Jun 13, 2015 at 3:29 PM, Bryan Fields <Bryan(a)bryanfields.net> wrote: https://github.com/janovic/Quagga-EIGRP - you were saying? At least you'd be able to explain your position rather than be a lid about it all. And a solution for it. If you got a better one, by all means speak. You first. Yeah, and spec never stopped a developer from not following it or doing their own thing. Don't believe me? Ask Microsoft, Google or any other company. I don't have to cater to your chosen network vendor, I can create my own. Standards make sure that there is interoperability within guidelines. And as I recall, EIGRP is a standard. Which is why developers and system engineers every day develop around network issues. Just because you have good pipes, doesn't mean that you won't end up with shit on you. Websockets is a perfect example of getting around limitations of the network. P2P mesh was the invention of creating ad-hoc networks without centralized end points. Just because you don't have vendor support doesn't mean you should abandon something. It just means your original enough to build a solution for your needs.

On Sat, Jun 13, 2015 at 4:07 PM, Bryan Fields &lt;Bryan(a)bryanfields.net&gt; wrote: I'm not trying to buy a vendor. I'm trying to route packets. Leave your CFP's in my work email. If BGP announced subnets were to IGP between each other announcements from one another and UCSD, I don't see how there would be a problem. The protocol was designed by Cisco Systems <https://en.wikipedia.org/wiki/Cisco_Systems> as a proprietary protocol, available only on Cisco routers, but Cisco converted it to an open standard in 2013. https://en.wikipedia.org/wiki/Enhanced_Interior_Gateway_Routing_Protocol I won't fault you for having out of date knowledge... it's only been 2 years. Use OSPF for stubs. It's much more suited and better documented. Segment routing is a fix for a network management problem. Not an application or systems problem. Again, people can always just stick with IPIP and leave you out of the loop. Or just choose not to peer to your IGP and not have you announce their subnets.

On 13 Jun 2015, at 11:59 PM, Bryan Fields &lt;bryan(a)bryanfields.net&gt; wrote: Did you consider a /24 allocated for the purpose of anycast tunnel endpoints? Each BGP gateway could announce it alongside the 44/8 routes. This is how 6to4 (IPv6 Internet-overlay tunnelling) works...

On 14 Jun 2015, at 12:27 AM, Nigel Vander Houwen &lt;nigel(a)k7nvh.com&gt; wrote: Ah-hah! Thanks to your hint, I've just found this: https://www.hamwan.org/t/AMPRNet?structure=HamWAN I note the first red block... for a newbie trying to understand the current flame wa^H^H^H^H^H^H^H^Hlively discussion, this adds some context :-)