14 Jun
2015
14 Jun
'15
2:26 p.m.
Subject:
Re: [44net] Strange Broadcasts...
From:
Don Fanning <don(a)00100100.net>
Date:
06/13/2015 10:05 PM
To:
AMPRNet working group <44net(a)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
14 Jun
14 Jun
5:35 p.m.
New subject: Strange Broadcasts...
On Sun, Jun 14, 2015 at 12:26 PM, Rob Janssen <pe1chl(a)amsat.org> wrote:
You must have missed the response where I showed a open source
implementation and reference that EIGRP is open standard.
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.
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?
3451
days inactive
3451
days old
1 comments
2 participants
participants (2)
-
Don Fanning -
Rob Janssen