"Why did your router choose tunl0 as the next-hop when ***we don't announce any special route for 44.24.221.0/24?***

Your router seems to have made a routing mistake here. It should have chosen the default route (0.0.0.0/0) to send the packet since it has no special information about 44.24.221.0/24."

> It allows our microwave network to remain connected to the rest of > AMPRnet as long as we have at least 1 ISP that isn't dead.

I fully welcome you to investigate and escalate this apparent infraction on my part. --Bart

**The problem would also solved if he announces 209.189.196.68/32 on both ISP connections.**

(Please trim inclusions from previous messages) _______________________________________________ On 17/04/2014 21:25, K7VE - John wrote: or Ham Radio Friedrichshafen... 73 de Marc _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

We need to stay away from ARIN as much as we can, ie do everything via rwhois and DNS via AMPRnet servers, not ARIN. I'd even go so far to say that ARDC is basically it's own RIR not bound by *ANY *ARIN policy.

Regarding documentation and specifications, the WIKI was developed as a method to assemble documentation (see archives). About routing: 44/8 is a flat network, so I'm not certain how a static route to 44/8 would need to be documented (as AMPRGW would be that route on the Public Internet). In fact, my 44GW should be able to send to other gateways if one used:

(Please trim inclusions from previous messages) _______________________________________________ All, Bart definitely provides good technical leadership; and I agree that we need more folks on the board. I'll be forthright and honest though: - there must be collaboration, willingness, partnership and agreement to move things forward - we must also have folks that are willing to listen to all sides - we must have folks that are willing to help - they must also know about nonprofits in addition to networks and other technical matters - we need someone that's versed in ARIN policy (and perhaps the workings of the ISOC) as well. On those first three points, I will not argue; and honestly (and probably shockingly), I do think Bart would make a good Executive Director; but I do not think that he would make a good Board member. I simply do not see him as one willing to listen, partner or collaborate. All I've seen is willingness to tear down and rebuild the infrastructure from the ground up, all other nodes be damned, as long as HamWAN works. Having been on the board of a non profit, the an executive director of another non-profit, a CIO in government, CTO/board memebr in private industry and also as the current administrator of a governmental network that encompasses hundreds of miles of fiber, has over 300 points of presence and maintains nearly /18 worth of public and private address space, plus their services in the largest county in the state of Maryland, I'm worried on many fronts (and yes, throwing in my qualifications - more so to show I'm qualified to show genuine worry). I've asked Bart to contribute the changes he wishes me to implement on our nodes: - he wouldn't - so I drafted them myself, he would not confirm - I reminded him, he tells me that they shouldn't be necessary, edits the parameters - He then tells me he's contributed all the time he will to the matter - still no viable draft - Despite all this, I then implement the changes and he has yet to confirm they are working - Now he asks for a board position; but has not offered nor contributed one SUCCESSFUL structural improvement to ARDC's infrastructure I'll be the first to admit this tears me apart, because I've been following HamWAN for months, admire them and want to glean from their successes when we implement in the Washington, DC area (I'm on the MDC Section HSMM implementation task force). I have to say, though, I was shocked when I realized thier lead guy was the one wanting to tear current infrastructure apart simply to make HamWAN work with AMPRNet as he envisioned it, leaving connectivity gaps, not providing a routing 44GW, etc. Next, I understand he has his own ASN and therefore probably a pretty good infrastructure; but it is a commercial outfit. UCSD has been very gracious to HamRadio over the years, and anyone wanting to make such drastic moves will probably also want to move the AMPRNet NOC. Simply throwing one's hat into the ring without some promises on how you plan to "steer the ship" is not good for the whole of the Amateur Community Worldwide. Simply not having a Z in the ARIN whois totally misses the point that the Amateur Radio allocations existed before those numbering schemes existed; and as another stations said, probably not even bound by the Legacy Agreement, as it not a requirement that it be signed by those possessing their legacy allocations. Someone coming on board would also have to draft a plan to fill in financial gaps we're expriecing (please donate to ARDC); we don't need a leader, as we have one in Brain, we need someone that will help him; and frankly, that's his decision to make. Regarding how to do so, as I understand it, Brian is the only Director, he would call the annual meeting and vote as he is the only voting member. I'd just personally ask that we have some geographic diversity in case the West Coast floats off into the Pacific with the "proverbial bus." And I would ask those voting, that if one will not take the time to work on a implementation and testing of one simple script, will he magically have time to direct a world-wide amateur radio network? -KB3VWG _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

.... I hooked in with the HAMs because that used to be where all the innovation was. Unfortunately quite a bit of what I've discovered is basically IRC from 50 years ago (with a few exceptions of course).

(Please trim inclusions from previous messages) _______________________________________________ Oooo. I have all those qualifications. Also I'm quite interested in participating in the governance of a network. I would be open to a board position if folks had interest. On those first three points, I will not argue; and honestly (and Yes. I agree with this. Having been on the board of a non profit, the an Very impressive sir. :) I'm in Austin TX. Also for technical diversity, I have a pretty awesome NOC in Kansas City MO. So if you need alternate announce points for the space, let me know. And I would ask those voting, that if one will not take the time to Well put. _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

2) Traffic from the Internet (non-44.0.0.0/8) to your AMPR IPs gets encapsulated by amprgw and is delivered to your router's IPIP endpoint IP. src-IP=169.228.66.251, dst-IP=<your IPIP endpoint IP>, and is unencapsulated by your IPIP interface. The unencapsulated packets src-IP=! 44.0.0.0/8 dst-IP=<your 44net> get routed according to your main routing table.

3) Traffic from your 44net to the Internet has src-IP=<your 44net> dst-IP=<any, except valid 44nets>. It hits the ampr routing-mark mangle rule which in turn forces routing to lookup the ampr table. After missing all the valid 44nets, it hits the default route in the ampr table and is encapsulated with src-IP=<your IPIP endpoint IP>, dst-IP=169.228.66.251. This packet then hits your main routing table and uses your ISP default gateway.

4) Traffic from another AMPR GW to your AMPR GW gets IPIP encapsulated by the remote gateway and arrives as src-IP=<any, including 44.0.0.0/8> dst-IP=<your IPIP endpoint IP>. After your IPIP interface unencapsulates the packet, the src-IP=44.0.0.0/8 dst-IP=<your 44net>, and follows your main routing table for delivery.

5) Traffic from your 44net to another AMPR GW has src-IP=<your 44net> dst-IP=<one of the valid 44.0.0.0/8 nets> matches the mangle rule which forces it to use the ampr table. It then finds a 44net route in the ampr table and gets encapsulated before hitting the default route. The encapsulated packet has src-IP=<your IPIP endpoint IP> and dst-IP=<any, including 44.0.0.0/8>. It hits your main routing table and uses your ISP default gateway.

(Please trim inclusions from previous messages) _______________________________________________ On 10/04/2014 22:51, Bart Kus wrote: No your logic made a mistake. RTFM especially BCP 38. Most routers are not authorized to send traffic from 44/8 via their commercial Internet upstream. So any traffic from 44net towards the internet has to be routed to UCSD (or somewhere where no the ISP doesn't care potentially spoofed source addresses). If no specific full mesh route is found, the traffic will obviously follow the default route of the routing table handling 44net traffic.

Maybe it would be better to recommend to blackhole traffic for networks that aren't in the encap file via ip route add blackhole 44.0.0.0/8 That way the "default route" wouldn't catch traffic for 44nets that don't exist in the encap file.

(Please trim inclusions from previous messages) _______________________________________________ On 10/04/2014 23:23, Bart Kus wrote: > At step (c) the packet matched a route that is associated with an IPIP > tunnel. The inner headers are from-44.whatever and to-44.24.240.0/20. > When that match is made, the packet is IPIP encapsulated, and given new > outer src/dst IPs. The dst-IP in this case should be 44.24.221.1, and > the src-IP should be whatever local-address was configured for the IPIP > tunnel (which should be routable over his public ISP). Then the router > has to make a 2nd routing decision about how to deliver to 44.24.221.1. > In this case, it should match default route (0.0.0.0/0).

(Please trim inclusions from previous messages) _______________________________________________ On 10/04/2014 23:23, Bart Kus wrote: The default route for traffic with ORIGIN (read NOT necessary DESTINATION) inside 44/8 will be routed via IPIP to UCSD.

Routing via ISP without NAT won't work! Read BCP38. Before recommending NAT, please note we don't want NAT because we want to keep the 44net ORIGIN intact.

Read BCP38. Really read BCP38. Read BCP38 again.