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