26 Mar
2016
26 Mar
'16
6:07 p.m.
Rob,
I forgot to include you in my thanks, I appreciate your comments as well.
- I'm not proposing that the Portal be ran on a 44 address. I'm stating
that the Portal is not a necessary physical component for all possible
networking solutions, albeit a logical one. In fact, the Portal is a
Great help, but not NEEDED physically to ensure network connectivity
(i.e. in comparison to a fiber cable extending to AMPRGW's NIC, or
AMPRGW's CPU(s)). I also pose that if you consider the Portal in this
manner, then both AMPRGW and the Portal must be online to maintain the
AMPRNet "mesh."
* - Solutions to simply make a hot-standby GW or a second RIP44
announcer could help here
- Unless I don't understand the premise - I not grasping your premise
that the Portal website somehow ensures [physical] connectivity of the
nodes, AMPRGW (and our individual GWs) physically provide this, the
Portal - their logical connection. Were AMPRGW or the Portal
down/unavailable (or its email counterpart), no new nodes could join the
'AMPRNet mesh' dynamically. Likewise, in an IPENCAP tunnel mode using
RIP44, AS Numbers don't apply (I agree). Again, I am proposing a test of
another, second, routing schematic entirely (this would REQUIRE some ASN
coordination amongst participants in the test or implementation, now or
in the future - as there's many scenarios where the the Number couldn't
be duplicated).
* - Solutions include saving copies of the route table geographically
local, this again is not 'real-time' nor dynamic.
- Available DNS servers are listed on the Wiki, there are quite a few on
AMPRNet. I'm not proposing that we not have 'some Internet tunnel.' I am
proposing a TEST of something additional to IPENCAP tunnels w/ RIP44.
- You stated: "I advise you to study the network topology before
proposing to change it. Traffic to another amprnet node does NOT flow
through AMPRGW."
I'm aware of this; but you insist, that somehow, we're a full mesh
(physically), despite not being able to send traffic in that manner
without some master first bootstrapping the nodes (logically). Again,
I'm just suggesting test of an alternative.
- "This is not what defines a star versus a mesh...The pings I send to
your gateway directly travel from my Internet connection to yours, NOT
via AMPRGW."
Correct again, I'm aware of this...so if we're a full mesh...I'm
proposing a method where AMPRGW is not necessary (or not the single
point of failure) for: a.) 'bootstrapping', b.) route announcements, c.)
route updates, and d.) possibly even connection to the Internet AND e.)
BGPed nodes. In fact, my proposal could eventually provide Internet
without need for: i.) a single [point-of-failure] master GW and its
logical 'network assembler' (the Portal), ii.) a multi-level subnet, or
iii.) connection to Commercial Internet
- "We use a multi-level subnet system here. We route the entire
country subnet to a single gateway which has radio and VPN connectivity
to users in the country. Those users can also have their own IPIP
gateway when they like."
That's really cool!!! This is also a very good solution!!! I don't think
any regions in my area have a setup in that manner!
- Lynwood
KB3VWG