Subject: Re: [44net] Strange Broadcasts... From: Don Fanning don@00100100.net Date: 06/13/2015 10:05 PM
To: AMPRNet working group 44net@hamradio.ucsd.edu
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.
No, it will just make the system more complicated. Especially when you introduce yet another routing protocol, even worse, a manufacturer proprietary protocol.
When you want to do something about a SPOF it is only required to do the RIP transmission from another system in parallel. E.g. from the system running the portal.
Rob
On Sun, Jun 14, 2015 at 12:26 PM, Rob Janssen pe1chl@amsat.org wrote:
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.
No, it will just make the system more complicated. Especially when you introduce yet another routing protocol, even worse, a manufacturer proprietary protocol.
You must have missed the response where I showed a open source implementation and reference that EIGRP is open standard.
When you want to do something about a SPOF it is only required to do the RIP transmission from another system in parallel. E.g. from the system running the portal.
RIP still doesn't solve routing loops that occur. RIP doesn't converge quickly (currently 44ripd takes 5+ minutes to send any new *static* change - if your firewall is configured to receive said packets from said source). RIP has no concept of bandwidth limitations or multiple paths for the same route (ie: load balanced connections with different ISP).
In the SPOF scenario you mention, traffic to/from non-44net would break and likely take a while to recover considering that all of the sudden an entire subnet shifted from San Diego to Western Europe - provided we work out with the portal's ISP that we'll be routing an entire /8 (more-less) of traffic through their network AS. Otherwise the AS that 44net lives on (7377) will still be telling the world that San Diego is the destination network for all 44net traffic not running their own BGP announced subnet.
My proposal wouldn't change the existing IPIP/ampr-rip44d/44net.txt scheme at all. There would be no change for the end users or the network operators. In fact, it would fix the separate BGP announced networks and lead to removing reliance upon AS7377 for all gateway traffic. Network changes could happen dynamically without putting additional burden on regional coordinators. In fact, it would increase resiliency by providing better paths for traffic to reach a network. Updates from EIGRP would go into rip44d or 44net.txt. Likewise, changes from the portal could propagate the same way.
BGP adjancies for 44/8 could also offer lower latency routing to non-44net (essentially becoming ISP's for 44net systems without NAT) should they be inclined to offer said services. Or the network operator can just stick with what works for them in it's current incarnation. Either way, no one is affected except at a very high level.
But again, my original question still stands: What would it take to make IPIP mesh more robust?
I'm not looking to change your way of doing things or take over your network. Hell, my subnets aren't even being announced due to problems in the portal (which one of these days, I'll look at the code and try and fix). But if no one asks the questions or provides solutions, then why do we even talk to each other?
-
Don Fanning -
Rob Janssen