Subject: Re: [44net] Strange Broadcasts... From: Bryan Fields Bryan@bryanfields.net Date: 06/14/2015 09:48 PM
To: AMPRNet working group 44net@hamradio.ucsd.edu
On 6/14/15 3:35 PM, Rob Janssen wrote:
Your problem is that you want to try to talk us into believing that we have a problem with reliability, while for most of us it is clear that we first and foremost have a problem with existance. The amateur digital network is nearly dead, we are trying to revive it and make it thrive like it did in the early days, a network built and operated by hobbyists, and you are continuously trying to impress us with your knowledge about professional networks and your concerns about failure modes.
Rob, take a chill pill.
Take a look at the HamWAN, HAMNET, and what I'm doing here in the bay area. It's very much alive, and we're educating people about high-speed ham packet networks everyday. I had over 200 people at the TAPR forum at Dayton this year for my talk.
I am not talking about the work you do locally but about the way you approach "us" after you have found some problem with your gateway implementation. Not even mainly about the discussion that just has started, but about a similar discussion that was started about the same topic some time ago. You continuously refer to Brian's system at UCSD as "broken", and I don't like that attitude. Especially not because it really is possible to fit in your system to co-exist in the network as it is now, as is demonstrated by our gateway.
Rob
On 6/15/15 3:34 PM, Rob Janssen wrote:
You continuously refer to Brian's system at UCSD as "broken", and I don't like that attitude.
But it is broken! It's a fact, and while you may find it unpleasant, it's the truth. It's not a dig at Brian, UCSD or ARDC, or you.
I've asked for details on it, and have driven some discussions on how we can fix it. Tim's diagram (shim box) is one of the best ways we can deal with it with out making any changes to the gateway.
From what I understand (again there are no public docs on it), is the amprgw
software is not using kernel mode devices for any of the IPIP tunnels or the kernel routing tables. This complicates what we can do on the amprgw box in terms of tunneling traffic off of it.
Eventually I'd say we move away from the UCSD amprgw as it stands now to more of a distributed model, but I'm in favor of small steps to make routing work.
44net should be end to end, not segmented into IPIP and BGP connectivity islands. We've seen a large growth of BGP connected subnets in the last 2 years. I think it was about 11 when I got my assignment, and now we're at 53 or 54. It's clear where the growth is :)
73's