Bart:
I won't go over the multiple suggestions you mentioned and then withdrew
to leave me with an optional inability to not connect to you, as some
can be referenced in earlier emails. It seems to me like selective
forgetfulness - as telling me 4 different methods and expecting me to
keep your thoughts together is laughable. I consult engineers that are
CCIEs because what you told me makes no sense, and it makes no sense to
them either. As I've noted to you:
ip rule add from <your 44net> table ampr
Is not a complete script; you refused to answer a single question I
posed (situations that need NAT, forwarding traffic not matching a route
in the 44 table, not being able to forward packets to other 44GWs,
etc.), instead, you said you'll offer no more time, and reappear seeking
a board position. I stated that I added the following for testing:
ip rule from all to 44.24.221.1 lookup main
now you insult my intelligence instead of inquiring if Chris will add
your route so you can test - perhaps it's because 44.24.221.1 is not
valid a endpoint destination, but you refuse to agree, despite having
been told many times before (how can an IP inside a network [44/8] be
the endpoint to a location inside same network [44/8]???). Also, be
advised, there have been other suggestions on how to solve this BGP
problem (i.e. running a 44GW in the traditional manner, announcing a non
44 address), perhaps you can think about those as well.
- It's been said that ARDC is not a club; and learning the Internet,
RIRs, ICAN, ISOC, etc. and the Legacy IP concepts on-the-job is not good
in this scenario when running such a vital organization to Ham Radio and
the Internet, internationally
- the fact is most folk don't simply wish to not have connectivity to
certain parts of AMPRNet if the subnet has a way to connect; these
networks are not "OUR networks," it's one network, a 44/8 that's been
called AMPR net since 1991 - you are the first station I've met not
willing to collaborate
- Most folk seem to recognize community collaboration as the
decision-making process within AMPRNet, I don't see how being on the
board of the organization that owns 44/8 changes what you're looking to
do; then all you have to do is say "other stations be damned" if you
still don't get your way - I mentioned this already, it's that that far
from being 100% accurate
- Regarding your ASN(s), you announce 44.24.221.0/24 at AS54688. Now,
this AS54688 (named THRESHOLD COMMUNICATIONS,INC.) only announces
44.12.6.0/24, 44.24.240.0/20 and 44.34.128.0/21, **not 44.0.0.0/8,**
which is the only way you could, as you say:
eliminate the single point of failure we now have with
UCSD.
AS54688 only has one peer, that is AS7752...(also named THRESHOLD
COMMUNICATIONS,INC.)! This is odd because you stated:
This does not mean that the name
on the ASN is the owner of HamWAN.
I would agree, given it's a nonprofit; but the point I was clearly tying
to make is that 44/8's home is UCSD and if you decided to break that
relation and then also had a falling out with Threshold Communications,
(or ARIN decided to argure), we'd be "up the creek without a paddle" if
you made a hasty and major decision to move 44/8's NOC (a term meaning
Network Operations CENTER - 44/8 is centered at UCSD regardless if yits
just a:
it's a simple peering point where 44/8 is
announced
You offer no respect, care or concern about the fact that UCSD allows
traffic from an entire /8 to use its bandwidth FOR FREE. Now, in order
to eliminate that single point of failure, you'd have to run a second
AMPRGW-like device, and that device would need a TO and FROM IP route
statement...similar to a script I've asked you to review.
I just don't totally agree that you're that concerned for AMPRNet, ARDC
or 44/8.
-KB3VWG