Tom,
If I understand you correctly, even if the portal allowed you to enter a 44 address as an IPIP endpoint, my 44GW (and many others) would be able to send traffic to it.
Since I wrote a script that quite a few people with Ubuntu Linux Gateways use (which was designed to closely mimic AMPRGW's behavior), here is what would occur (I cannot confirm this for other gateways using different OSes or scripts):
see: http://kb3vwg-013.ampr.org/startampr
- the gateways using the KB3VWG Linux script are set to use a custom routing table if the SRC or DST address is 44.0.0.0/8
- the rip44 then adds all 44 routes to the 44 routing table
- so, as you wish a.) rip44 would add your tunneled subnet (44.24.240.0/20) to routing table 44 with an endpoint address as 44.24.221.1 b.) a host in my subnet sends your subnet a packet and is received by my router c.) it looks up the endpoint destination on table 44 and finds that it's 44.24.221.1 d.) my router will look in the routing table for 44.24.221.1 finds
**44.24.221.1 via 169.228.66.251 dev tunl0** *****which would be **INVALID*****
e.) **INVALID***My GW sends an encapsulated packet to AMPRGW, and it's received on it's WAN interface. ***AMPRGW should not receive encapsulated packets from 44 hosts destined to 44 hosts*** Routing loops can occur.
- there have been IPIP tunnels in the past with 44 addresses, they were considered invalid configurations. To the Internet, 44 net is a flat /8 network and all subnets must be reachable at a non-44 address; which leads me to my last point
- I'm not sure why you keep insisting that AMPR routing is "broken" or has "funky 44net issues," you are requesting something that was not intended in the design, as was mentioned before tunnels msut be reachable with non-44 address, BGP routed subnets must still maintain a IPIP GW.
- This same topic was presented in April 2012, check the archive " ***"This will also means that any Operator that wishes to BGP should also consider also running the AMPR standard rip44d on the same device, if the intention is to make all 44/8 addresses equally reachable from any PoP, eventually, as is the intend purpose of BGP."***
- it was my intention update the script to include a block of IPENCAP from 44.0.0.0/8 SRC addresses...until I read your posts today
73,
Lynwood KB3VWG
Tom wrote:
Forget AMPRGW. I understand there is a routing issue at UCSD that breaks 44net routing for AMPRGW. But I'm not asking about AMPRGW! I'm asking about routing from all the IPIP gateways, none of which have 44net endpoints at the moment.
Since none of the current IPIP gateways have 44net endpoints, you cannot say with certainty that it won't work until the portal lets us try it.
Tom KD7LXL
my first sentence should read:
"If I understand you correctly, even if the portal allowed you to enter a 44 address as an IPIP endpoint, my 44GW (and many others) would ***NOT*** be able to send traffic to it."
Bart,
That realization you posit is INCORRECT:
AMPR IPs packets do one of 2 things at a 44GW: 1.) if a valid DST 44 address, go to a destination via IPIP to another 44GW 2.) all others use default gateway - go via IPIP to the AMPRGW ~~~ the request proposes an ***INVALID*** or STATIC option 3.) - ***if a 44 address, go to the 44 address via IPIP to the AMPRGW***
you asked:
"Why did your router choose tunl0 as the next-hop when ***we don't announce any special route for 44.24.221.0/24?***
Because within AMPR, 44.24.221.0/24 is an invalid IP subnet and is choosing the default route, which is also invalid at AMPRGW.
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."
Not accurate, it made a CORRECT routing decision, it selected the ***Default AMPR Route***
As I noted:
- the gateways using the KB3VWG Linux script (and most devices using rip44) are set to use a custom routing table if the SRC and/or DST address is 44.0.0.0/8
- the default route for AMPR host to reach the Internet is: ip route add default dev tunl0 via 169.228.66.251 onlink table 44
I don't want to belabor the group on this, as I had to discover this by trial and error when developing the script; your only options are to:
- develop an Amateur Radio custom Linux kernel and IP command; or - have every station add a static route for you (which should only be used for subnets local to the GW)
73,
Lynwood KB3VWG
Bart,
- NO router in AMPR by default speaks BGP, they speak some form of what can be termed RIP44 - ALL outbound traffic leaving or destined to AMPR GWs via the Public Internet are sent via IPENCAP - every valid 44/8 address has a corresponding rip44 announcement - every 44IP announcement has a corresponding non-44 IP DST to send that IPENCAP traffic to - IF RUNNING BGP, YOU MUST STILL SPEAK IPENCAP and RIP44 with a non44 IP, BGP only speaks to the Public Internet - altering one of the conditions above would cause issues somewhere within AMPR
***e.g. If I send your 44.24.240.0/20 traffic directly to 44.24.221.1 the traffic SRC address is a non-44 IP; and therefore would not return to my GW ~or~ has a SRC of 44.0.0.0 and is dropped by the first hop***
I think you have totally misunderstood, adding the entry will not 'magically' allow every other AMPR gateway to send traffic to 44.24.240.0/20. There is no way within the AMPR routing announcements to specify use of the non AMPR interface - unless a static route is manually entered on every station wishing to contact 44.24.240.0/20. You may be multihomed, but most AMPR GWs are not.
AMPRGW is NOT "broken."
I would probably leave the UCSD communication broken instead, until UCSD fixes the routing issue. We'd still enjoy the benefits of redundant tunnel termination for every other AMPRnet. Can you make the database change to configure 44.24.221.1 as the gateway for 44.24.240.0/20?
Bart,
I've read over your suggested reconfiguration; and I am willing to test it; but please answer/provide the following:
- please provide this information in Linux syntax for the iptables mangle and ip rule (feel free to reference http://linux.die.net/man/8/ip and http://linux.die.net/man/8/iptables) confirm: iptables -t mangle -A PREROUTING -s 44.60.44.0/24 -j MARK --set-mark 1 ip rule add fwmark 1 table 44
- please clarify a problem presented by No.4 where routing loops can occur
- please clarify an inconsistency in your document where you state in the beginning that a mangle rule is needed, and the end where you state I need to change the IP rule from dst=44.0.0.0/8 || src=44.0.0.0/8 ~to~ src=<my 44 subnet> (I'm gathering you meant removing both src and dst ip rules completely and replacing it with the two commands above)
- (please be advised, this breaks the ability for any 44GW to forward traffic to other 44GWs, for testing, in an emergency, or otherwise)
- Also, I perform my iptables work in a web GUI, this breaks my ability to simplify setup via script and allow others to firewall as they wish; but I'm willing to forgo that for testing purposes
Lastly, it isn't usually good practice to tell someone else to test something; but as I said, I'm willing, if you provide this information in Linux syntax.
73,
KB3VWG
Bart,
Don brought up some good points. In addition:
- non Linux-kernel routers (e.g. JNOS and TNOS) would not be able to route to you as they would need to be reprogrammed and recompiled (FYI, JNOS and TNOS is the most commonly used AMPR Network OS)
- (bad practice) packets destined for invalid 44IPs are now forwarded on to AMPRGW instead of dropped by the local GW (recall, only BGP subnets who DO NOT want to run RIP44 and IPENCAP would need this reconfiguration and only your subnet needs this exception)
-KB3VWG
This is a legacy setting that emerged from the munge script and just perpetuated, and actually had no side effects, except the fact that 44.0.0.1 is not reachable from a ampr machine. And it wrongly gave birth to the idea that unknown networks would be forwrded by the amprgw using it as a default gateway.
73s de Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii@aol.com Sent: Friday, April 11, 2014 06:22 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] Portal doesn't allow IPIP anycast via 44net
...
- (bad practice) packets destined for invalid 44IPs are now forwarded on to AMPRGW instead of dropped by the local GW (recall, only BGP subnets who DO NOT want to run RIP44 and IPENCAP would need this reconfiguration and only your subnet needs this exception)
-KB3VWG _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Jann,
Are you saying that the rip44 protocol needs to be edited, and if so, how? Speaking with a few of my network engineering colleagues, the only way is to have rip44 specify which interface to use; and since RIP44 is not the only method of receiving the route table, it wouldn't provide a 100% fix.
It's much easier, and doesn't require a total reconfiguration of AMPR to simply have Bart run a 44GW speaking rip 44 using his Public IP address as the GWip - be advised that he is required to do so under the Terms of Service:
|3. What we don't do |ARDC DOES NOT provide network services.
|7c. Directly routed subnets shall make provision to in turn supply connectivity to other hams in their area (by e.g., "tunnels" or |other means).
|Definition: "AMPRNet" means the network 44/8; that is, all Internet IP addresses from 44.0.0.0 through 44.255.255.255.
- Since I do not see an AMPRNet route for 44.24.221.1 on AMPRNet, this address is (currently) only an Internet address.
I also have colleagues looking over Bart's suggestion to use mangle instead of ip rule SRC or DST =44/8; and the main thing is that it breaks the ability of 44GWs to route traffic to other 44GWs without AMPRGW.
I think the best way might be to patch Marius ampr-ripd if we will ever see 44.24.240.0/20 via 44.24.221.1 on the RIP-broadcasts we get from AMPRGW.
Bryan F,
TOS section 7c requires him to provide an AMPRNet connection for AMPR devices local to him; but not necessarily via rip44. Since its not valid at this time to tunnel to a 44subnet via a 44 address, I don't see how he's in compliance (save via RF, which is their local AMPRNet anyway).
Bart also mentioned:
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.
**The problem would also solved if he announces 209.189.196.68/32 on both ISP connections.**
-Lynwood KB3VWG
I fully welcome you to investigate and escalate this apparent infraction on my part.
--Bart
On 4/11/2014 9:26 AM, lleachii@aol.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Bryan F,
TOS section 7c requires him to provide an AMPRNet connection for AMPR devices local to him; but not necessarily via rip44. Since its not valid at this time to tunnel to a 44subnet via a 44 address, I don't see how he's in compliance (save via RF, which is their local AMPRNet anyway).
Bart also mentioned:
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.
**The problem would also solved if he announces 209.189.196.68/32 on both ISP connections.**
-Lynwood KB3VWG
All,
I'll drop my line of discussion about the AMMPRNet rules requiring BGP announced subnets to provide connectivity; this isn't a mater of law, hence the entire community's here putting our heads together on how to accommodate Bart's request without breaking the consistency of the rest of AMPRNet, or some stations simply not having connectivity to him.
Per Bart's recommendation, I evaluated simply removing or somehow editing Line 47 or 48 in my startampr http://44.60.44.13/startampr_v1.1 script, it will not work without complex configuration beyond a plug and play script (and I had to reference notes when developing to understand why) . If I add a line for his subnet, the issue is solved:
+ ip rule add to 44.24.221.1/32 table main priority 43
***I added the following line, but rip44 deletes it when it receives the first announcement*** + ip route add 44.24.240.0/20 via 44.24.221.1 dev tunl0 onlink table 44
I've found many other issues with this configuration, but I won't list them as it will still result in a working connection to Bart. Lastly, the issues are not solved that even if he's permitted to add the route, the issue is not fixed with other 44GWs
Feel free to test: http://44.60.44.10/tools
*** Pinging from my tool to 44.24.221.1 does not work, as it requires masquerade to be setup, the first hop appears to be dropping the packet (as it should).
- Lynwood KB3VWG
On 11/04/2014 18:26, lleachii@aol.com wrote:
**The problem would also solved if he announces 209.189.196.68/32 on both ISP connections.**
https://labs.ripe.net/Members/dbayer/visibility-of-prefix-lengths
Prefixes longer than /24 are rarely visible on the internet.
73 de Marc
Maiko,
I see mostly HTTP (tcp/80) RDP (tcp/3389), Telnet (tcp/23), DNS (udp/53) and ping (ICMP type 8), just common port scans on the net. Mostly Advansed Persistent Threat gangs looking for vunerable machines via already compromised devices. They've been prevalent on the Internet since Mandiant exposed the ongoing "cyberwar."
N1URO is correct, HTTPS probing was probably started when Heartbleed was announced...
...if you have records of connections before it was made public on April 8th (as I recall), that information may be useful...you may have discovered someone who knew/exploited the HTTPS/OpenSSL threat pre zero-day.
-KB3VWG
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
and one correction - there are 3 board members
Nigel,
Of the 193 member states that make up the ITU on the planet, and the 191 that permit Amateur Radio; not all of of them are able to run the latest and fastest technology; nor do they necessarily have the ability to import it. Next, I personally didn't ask Bart to engage in "fiddling with legacy code," he OFFERED to solve an issue with a script running via the current Linux kernel.
In fact, I developed that script for Linux with the help of Brian and PE1CHL - after determining it was probably easier to simply use the routing built into the Linux Kernel than install a *NOS program on top. I then had to do alot of learning about AMPR so I did not "break" others ability to connect to me. I then went through months of testing until I was sure the script functions without causing security issues or breaking others use of AMPRNet. Further, I worked on the firewall scripts so a station's 44GW didn't have to be directly connected to their Internet-facing interface. Basically, I'm saying that I didn't quit or decide to lobby for a board position, I worked at solving what I perceived as the issue needing a solution; that's what most people try to do. After I inquired more about Bart's proposed solution and offered to re-write my entire station router script, he stated he did not want to contribute any more time to the problem. Now he reappears lobbying for a board position in lieu of working to fix his perceived "issues" with ARDC - citing old technology and old ideas; all one can be left to assume is he want's to disamble AMPRNet for the 190 other states on the planet, control 44/8 and ARDC - still not offering anything to the software, processes or services within AMPR until he has control; basically, a HSMM Radio coup.
I'm not sure if your grasp of the situation came from observing only the April 2014 chat, the archives or directly from conversation with Bart; but it is true that some users operate versions of router NOS that run on DOS; but others use Cisco, Linux Kernel, Microtik, etc - and they all work together; there's no need to take over AMPR to "fix" the "situation."
-KB3VWG
On Thu, Apr 17, 2014 at 11:08 AM, lleachii@aol.com wrote:
most people try to do. After I inquired more about Bart's proposed solution and offered to re-write my entire station router script, he stated he did not want to contribute any more time to the problem. Now he reappears lobbying for a board position in lieu of working to fix his perceived "issues" with ARDC - citing old technology and old ideas; all one can be
I believe Bart got frustrated with the lack of change-management and specifications in AMPR. How your script is written depends on these things.
It seems that to be allowed/compliant in AMPR, it just has to work with the existing system. But what is the existing system? There are a lot of existing systems and most of them are not documented. For example, we learned via the mailing list that many AMPR gateways have a static route to 44/8. This isn't documented in the encap file, it's just added by their scripts. Where is the specification for this? Little details like this are important when trying to figure out how to write script to route to other AMPR systems. Until we know all these details, it's not worth writing more software.
Where is the official specification? The wiki links to a couple scripts on third party sites. These are current implementations, not specs, and they aren't identical. Which one do we trust? What is AMPR/ARDC's policy for creating, accepting, and publishing specifications?
I'm curious if you have done a survey: what percentage of AMPR allocations can you route to from your gateway? I've been meaning to write some software to test from ours. I expect the results to be disappointing.
Tom KD7LXL
My thoughts.
ARDC is a non-profit California corporation and it has been financially supported by Brian Kantor with a few contributions from others. It isn't a club. It doesn't have members. It doesn't have stock holders. It is the steward for the 44.x.x.x address space and through volunteers it administers the address space and sets policy for its use.
Everyone should make periodic donations for the services it provides, but the noble goal has been to avoid a "pay to play" model. In other words, it provides services and if you find them valuable then you contribute time and/or money. A lot of people contribute time, we need more that contribute money.
http://www.ampr.org/donate.html
Should the ARDC evolve into a club with members and dues is certainly open for discussion, and if that were to happen, with the agreement of the current management, then a formation committee should be tasked to define governance and a transition plan. This work would involve a series of working sessions and a presentation at a public meeting at a venue like the Digital Communication Conference, where it could be formally voted into existence.
I have been around AMPRnet since nearly the beginning and have been an area coordinator for several years in two different geographical areas. I, too, think we should be moving forward with the network and using common technologies and practices of the Internet, such as BGP, anycast, delegated DNS (forward and reverse), etc. to adapt to new a changing applications while preserving our Amateur Radio only charter. I have advocated a model of using BGP and the Internet to sew together regional networks into a complete fabric and that those regional networks could then address "last mile" issues with IPIP or VPN tunnels as appropriate. I'd like to see this formalized and adopted sooner rather than later.
As to Bart's "candidacy" for a Director's position. That is premature, based on the current governance and structure of ARDC. Frankly, I think Bart has accomplished a lot in the last couple of years from a technical point of view. I happen to live in the area where HamWan is being developed and the progress seems to be constant. The problem is, Bart, like many driven technology experts, can come off as dismissive and narrow-minded, and that isn't productive. He would better serve in a technical advisory position with others that serve in similar roles.
------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays
I don't think the current format of the ARDC was an attempt at a "power grab" by anyone.
My guess it was the easiest, fastest, and least expensive way to form a public entity to hold on to the 44.0.0.0/8 space when ARIN created their "Legacy" address allocation policies.
As for not being official "Legacy" address space, signing an LRSA with ARIN is problematic for many legacy address holders because it is not clear wether the rights one gets and gives up is worth it. Plus it can incur paying enormous annual fees (in the tens of thousands of dollars range) to ARIN.
Also keep in mind that UCSD is being very generous by advertising themselves as the gateway for a /8 of traffic. They do so because it can be useful for their research purposes. We need to be careful that any major changes that are made to the 44.0.0.0/8 topology do not prematurely disrupt that relationship, or we could lose connectivity to the whole IP-IP tunnel space, and I doubt there are any institutions that would be willing to take over that role for no cost.
-Neil
On Thu, Apr 17, 2014 at 2:40 PM, Marc, LX1DUC lx1duc@laru.lu wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 17/04/2014 21:25, K7VE - John wrote:
a public meeting at a venue like the Digital Communication Conference
or Ham Radio Friedrichshafen...
73 de Marc _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Tom,
I agree that the lack of change management can be frustrating; but again, that's something we as a community would have to implement - changing leadership doesn't directly solve that.
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:
44.0.0.0/8 via <my GW IP> dev tunl0 onlink
I used that method (during testing) for a while until I developed the script. The packets should route onward to you and the return trip would take your specified route. That is a basic understanding of routing.
To answer your question about a survey, the last I manually checked (when I tested connectivity with the Linux script), I could route reach 100% of those AMPR gateways being tested and others in the route table. I am able to perform a survey of the entire 44/8, but until I know all hosts that should be online, those only available locally, and those reachable only on AMPR, it would be difficult to compile the data network-wide with any level of accuracy.
-KB3VWG
I'm in 100% agreement with Brian F. - ARDC "OWNS" 44/8. This is entering history before my time; but when the original "Internet" (as least, what we call "the Internet") was divided up by it's IPv4 address space, Amateur Radio received 44/8. So I would assume that the "Internet Registry" (see RFC1174 https://tools.ietf.org/html/rfc1174 and the very obsolete RFC1366 https://tools.ietf.org/html/rfc1366) who was controlled by IANA allocated that space, as their list reads:
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml
044/8 Amateur Radio Digital Communications 1992-07 whois.arin.net LEGACY
It should also be noted that it does not read "ALLOCATED," "RESERVED," Future Use," "Administered by ARIN" or anything - it simply exist in IANA's database as 44/8.
My assumption then would be "some technical white paper must exist." Now, read 'Internet numbers' - RFC1166 - July 1990 https://tools.ietf.org/html/rfc1166 (which obsoleted 'Assigned numbers' - RFC790 of September 1981 and: 820, 870, 900, 923, 943, 960, 990, 997, 1117 1120) you will find:
R 44.rrr.rrr.rrr AMPRNET [PK28] [PK28] Karn, Phil KARN@THUMPER.BELLCORE.COM
That appears the be the current RFC referencing IP addresses; and 44/8 has existed in technical documentation and has been allocated as 'AMPRNet' since RFC790. Prior to RFC790, 44/8 was unassigned (see RFC776 - January 1981). Ham Radio from that time onward has been on par with the likes of the US Army, UK Armed Forces, Eli Lily, Apple, HP, Halliburton, CSC, Xerox, Ford, MIT, AT&T, IBM, General Electric, etc. They "OWN" their IPv4 space!!!
As I mentioned previously, an understanding of The Internet Society (ISOC.org) is necessary (membership is free). Read: http://www.computerworld.com/s/article/9200359/Protect_your_pre_1997_IP_addr... for more information on the "Legacy Internet" IPv4 space.
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.
-KB3VWG Member ISOC
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
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:
Where is the wiki located? What is the URL?
I asked this question in my first post to the list and never got an answer. Wasn't sure if this was intentional (are "outsiders" not permitted to access the wiki)?
On Fri, Apr 18, 2014 at 9:37 AM, charles@thefnf.org wrote:
Where is the wiki located? What is the URL?
http://wiki.ampr.org/index.php/Main_Page
Tom KD7LXL
P.S. Still waiting on my credentials so I can document some things.
Hello All,
I've stayed relatively quiet through these various conversations, but I feel like it's probably time to throw my hat in. In the interests of full disclosure I'm a board member of the HamWAN project, and work closely with Bart (as well as the other board members and administrators) in the administration of the organization and the network.
Frankly, and this is my opinion, not those of anyone else, the way AMPR is presently run, with everything centered around EXTREME legacy ideas and equipment is a hindrance. HamWAN as a network and as an organization strives to build on the best methods and technologies used on the internet at large. They exist for a reason, and those reasons include that they work, that they're reliable, that they're redundant, that they're scalable, and any number of other positive things.
We try our best to bring these sorts of positive features to our network, and share them with anyone else who wants them. We document our work on our wiki, I know Tom Hayward has published scripts to get the IPIP tunnel infrastructure running on Mikrotik devices which we use on our edge routers, and more.
I agree with you, Bart pushes for new and better technologies and practices, but that doesn't mean that he ignores what's already there, or that what's already there needs to go away.
UCSD is very gracious to host the AMPRGW, but it's a HUGE problem for anyone in 44 space who wants to do their own BGP announcements like we do. Especially in light of the recent conversations about tunnel end points. Considering they're not aware of any more specific announcements of 44/8 space. If this one thing were to get fixed, that would solve a world of problems. Including a BGP based network's need for IPIP at all. A legacy client on IPIP could route through the AMPRGW, it would know it's not responsible for X network, and route over the public internet LIKE EVERY OTHER DEVICE ON THE PLANET. Yes there are hindrances to getting this to work, but Bart is a dynamo about getting things solved.
Additionally, ham radio has a large streak of holding on to the past, and is resistant to change. While not all past things are bad or need to be forgotten, we seriously need to look to the future. I've seen a LOT of talk on this list (and many others) in one way or another disparaging new experimentation and technology, and we really need to remember that's where amateur radio came from. That is our roots! And in my personal opinion, if that opinion is to be maintained, and we're all going to be so resistant to change, then I'm inclined to allow AMPR to sit as an IPIP island, and not make a significant effort to pull this legacy and sometimes extremely burdensome support into the modern networks.
Again, this is all my opinion, but I don't think it's fair to characterize how Bart would be as a board member or director, based on his wanting to improve the network as a whole, rather than run around in circles fiddling with legacy code that might sort of get it working instead of solving the real problems.
Thanks, Nigel VH K7NVH
(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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 2014-04-17 12:23, Nigel Vander Houwen wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hello All,
Frankly, and this is my opinion, not those of anyone else, the way AMPR is presently run, with everything centered around EXTREME legacy ideas and equipment is a hindrance.
Yes. I agree. That's been my assessment as well.
HamWAN as a network and as an organization
strives to build on the best methods and technologies used on the internet at large. They exist for a reason, and those reasons include that they work, that they're reliable, that they're redundant, that they're scalable, and any number of other positive things.
Right. I've been very impressed with HamWAN. I discovered it one day, and 5 minutes on the site and I was incredibly impressed.
UCSD is very gracious to host the AMPRGW, but it's a HUGE problem for anyone in 44 space who wants to do their own BGP announcements like we do.
Would you mind expanding on that a bit?
Especially in light of the recent conversations about tunnel end points. Considering they're not aware of any more specific announcements of 44/8 space.
Is there a network map somewhere? I'm not quite getting how it's currently setup. Seems like there are some islands of space, various actual physical links, vpns over the internet etc. It's really quite hard to wrap my head around.
Additionally, ham radio has a large streak of holding on to the past, and is resistant to change.
Yes. That's been evident to me as well. Though some are really cutting edge (like the south texas baloon launch team).
Wand we really need to remember that's
where amateur radio came from. That is our roots!
Yes. Agreed. I've been saddened by that. 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).
On 2014-04-18 10:23, charles@thefnf.org wrote:
.... 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).
Now you are being too kind (grin).
I want to say there is hope here. This is one of the few amateur radio forums/mailing lists, where spelling and grammatical errors are rare. Even typos are uncommon here.
-- Dean AE7Q
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.
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 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.
Yes. I agree with this.
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).
Very impressive sir. :)
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."
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 work on a implementation and testing of one simple script, will he magically have time to direct a world-wide amateur radio network?
Well put.
For all of you gmail users wishing to opt-out of this mess... here's a great way! https://support.google.com/mail/answer/47787?hl=en
Cheers!
On Fri, Apr 18, 2014 at 12:17 PM, charles@thefnf.org wrote:
(Please trim inclusions from previous messages) _______________________________________________
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.
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
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.
Yes. I agree with this.
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).
Very impressive sir. :)
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."
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
work on a implementation and testing of one simple script, will he magically have time to direct a world-wide amateur radio network?
Well put.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 04/10/2014 02:26 PM, lleachii@aol.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Bart,
That realization you posit is INCORRECT:
AMPR IPs packets do one of 2 things at a 44GW: 1.) if a valid DST 44 address, go to a destination via IPIP to another 44GW 2.) all others use default gateway - go via IPIP to the AMPRGW
the request proposes an ***INVALID*** or STATIC option 3.) - ***if a 44 address, go to the 44 address via IPIP to the AMPRGW*** you asked: > "Why did your router choose tunl0 as the next-hop when ***we don't > announce any special route for 44.24.221.0/24?*** Because within AMPR, 44.24.221.0/24 is an invalid IP subnet and is choosing the default route, which is also invalid at AMPRGW. > 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." Not accurate, it made a CORRECT routing decision, it selected the ***Default AMPR Route*** As I noted: - the gateways using the KB3VWG Linux script (and most devices using rip44) are set to use a custom routing table if the SRC and/or DST address is 44.0.0.0/8 - the default route for AMPR host to reach the Internet is: ip route add default dev tunl0 via 169.228.66.251 onlink table 44
The problem is the "SRC == 44/8 || DST == 44/8" routing table selection. Consider the following alternative architecture:
1) Create an "ampr" routing table with all the announced 44nets and their gateways 2) Add 1 static route to the "ampr" routing table: default via 169.228.66.251 dev tunl0 3) Define a mangle rule (RouterOS format - still Netfilter-based architecture):
/ip firewall mangle add chain=prerouting action=mark-routing new-routing-mark=ampr src-address=<your 44net>
4) Define a routing rule (RouterOS format - still Netfilter-based architecture):
/ip route rule add routing-mark=ampr action=lookup table=ampr
The above should handle the following cases:
1) Your normal Internet traffic from non-AMPR IPs goes out using your main table and ISP's default gateway. You can also add NAT here, but let's not get into that in this email.
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.
I believe the above scenarios fully work through every conceivable routing permutation here, and demonstrate correct functionality. The actual change required is minimal, since you've already got the ampr table defined by your software. It's simply the removal of the dst==44/8 clause and the replacing of the src==44/8 clause with src==<your 44net>.
Having said all that, I haven't actually implemented/tested this design since my AMPR allocation is announced via BGP. Please do let me know if it works out for you! It should retain present functionality and make you 44net-anycast compatible going forward.
--Bart
I don't want to belabor the group on this, as I had to discover this by trial and error when developing the script; your only options are to:
- develop an Amateur Radio custom Linux kernel and IP command; or
- have every station add a static route for you (which should only be used for subnets local to the GW)
73,
Lynwood KB3VWG
On Thu, Apr 10, 2014 at 6:17 PM, Bart Kus me@bartk.us wrote:
- 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.
The problem being here is that amprgw.sysnet.ucsd.edu doesn't route and would effectively mean that all traffic not going to BGP destinations would go through UCSD for which I don't think UCSD would enjoy happening as it's increased utilization of a link and would also mean packets destined to say a european 44net subnet would travel to UCSD first before reaching said european 44net network - increasing additional network traffic both ways as well as increasing latency making the trip halfway around the world should the traffic come from the same destination country.
- 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.
Same reasons as above but in the opposite direction.
- 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.
Would never reach my network as it would technically be routed to part 2 above and dropped on the floor as you didn't specify amprgw would be unencapsulating traffic. Same issues apply from above apply as well.
- 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.
That's fine... but I would never receive your ACK to my SYN due to part 4 and 2 above.
On 11.04.2014 03:17, Bart Kus wrote:
Having said all that, I haven't actually implemented/tested this design since my AMPR allocation is announced via BGP. Please do let me know if it works out for you! It should retain present functionality and make you 44net-anycast compatible going forward.
I'm pretty sure it will work like you described for normal Linux/Mikrotik Gateways.
However I still see an issue with my Gateway which it seems is not easy to solve: - My Gateway is speaking to !44/8 using the ISP with its commercial IP address.
- My Gateway is speaking to other AMPR IPIP Gateways using IPIP tunneling with its 44 ip address.
- My Gateway is speaking to 44/8 (which will include the direct BGP connected 44 Gateways) using another IPIP tunnel to a special Gateway (which is able to send source44 packets to the internet) using its 44 ip address. <- I will do this since I want to use my 44net IP address while I'm speaking to other 44net amateur radio stations...
So far everything is fine. Now I have a new requirement to use 44.24.221.1 as an IPIP gateway for 44.24.240.0/20. In this case I *don't* want to use IPIP in IPIP :) Challenge accepted ;)
As for now I did put a static route to 44.24.221.1 via my ISP gateway. I think the best way might be to patch Marius ampr-ripd if we will ever see 44.24.240.0/20 via 44.24.221.1 on the RIP-broadcasts we get from AMPRGW.
73, Jann
On 04/10/2014 01:24 PM, lleachii@aol.com wrote:
Tom,
If I understand you correctly, even if the portal allowed you to enter a 44 address as an IPIP endpoint, my 44GW (and many others) would be able to send traffic to it.
Since I wrote a script that quite a few people with Ubuntu Linux Gateways use (which was designed to closely mimic AMPRGW's behavior), here is what would occur (I cannot confirm this for other gateways using different OSes or scripts):
see: http://kb3vwg-013.ampr.org/startampr
the gateways using the KB3VWG Linux script are set to use a custom routing table if the SRC or DST address is 44.0.0.0/8
the rip44 then adds all 44 routes to the 44 routing table
so, as you wish
a.) rip44 would add your tunneled subnet (44.24.240.0/20) to routing table 44 with an endpoint address as 44.24.221.1 b.) a host in my subnet sends your subnet a packet and is received by my router c.) it looks up the endpoint destination on table 44 and finds that it's 44.24.221.1 d.) my router will look in the routing table for 44.24.221.1 finds
**44.24.221.1 via 169.228.66.251 dev tunl0** *****which would be **INVALID*****
OK, let me stop your email right here. 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.
Does that realization clear things up?
--Bart
e.) **INVALID***My GW sends an encapsulated packet to AMPRGW, and it's received on it's WAN interface. ***AMPRGW should not receive encapsulated packets from 44 hosts destined to 44 hosts*** Routing loops can occur.
there have been IPIP tunnels in the past with 44 addresses, they were considered invalid configurations. To the Internet, 44 net is a flat /8 network and all subnets must be reachable at a non-44 address; which leads me to my last point
I'm not sure why you keep insisting that AMPR routing is "broken" or has "funky 44net issues," you are requesting something that was not intended in the design, as was mentioned before tunnels msut be reachable with non-44 address, BGP routed subnets must still maintain a IPIP GW.
This same topic was presented in April 2012, check the archive "
***"This will also means that any Operator that wishes to BGP should also consider also running the AMPR standard rip44d on the same device, if the intention is to make all 44/8 addresses equally reachable from any PoP, eventually, as is the intend purpose of BGP."***
- it was my intention update the script to include a block of IPENCAP from 44.0.0.0/8 SRC addresses...until I read your posts today
73,
Lynwood KB3VWG
Tom wrote:
Forget AMPRGW. I understand there is a routing issue at UCSD that breaks 44net routing for AMPRGW. But I'm not asking about AMPRGW! I'm asking about routing from all the IPIP gateways, none of which have 44net endpoints at the moment.
Since none of the current IPIP gateways have 44net endpoints, you cannot say with certainty that it won't work until the portal lets us try it.
Tom KD7LXL
On 10/04/2014 22:51, Bart Kus wrote:
OK, let me stop your email right here. 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.
Does that realization clear things up?
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.
73 de Marc
On 04/10/2014 02:11 PM, Marc, LX1DUC wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 10/04/2014 22:51, Bart Kus wrote:
OK, let me stop your email right here. 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.
Does that realization clear things up?
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.
No mistake on my end. Please read KB3VWG's email more carefully, I'm including the relevant text here for re-examination:
===QUOTE=== - so, as you wish a.) rip44 would add your tunneled subnet (44.24.240.0/20) to routing table 44 with an endpoint address as 44.24.221.1 b.) a host in my subnet sends your subnet a packet and is received by my router c.) it looks up the endpoint destination on table 44 and finds that it's 44.24.221.1 d.) my router will look in the routing table for 44.24.221.1 finds ===/QUOTE===
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).
Does this clear things up?
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.
No no no! You will be killing all traffic to BGP-only 44nets. Let us never utter this again. :)
--Bart
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).
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.
73 de Marc
On 10/04/2014 23:33, Marc, LX1DUC wrote:
(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 disregard this message, I was reading the previous message and replying to this one.
Your proposed setup could work for internal 44net traffic. But due to restrictions with routing setup of 44/8 @ UCSD, traffic from the commercial internet wouldn't necessarily always reach you. In cases where traffic is not routed to according to your BGP announcement, traffic would go to UCSD where it would end up in a routing loop.
Additionally some check would need to added to the portal 44GW should only be allowed to have a 44net address if that address is part of an independent BGP announce. Tunneling of a 44net to a 44GW which itself is only reachable via another 44GW and tunnel is probably not desirable.
73 de Marc
On 04/10/2014 02:46 PM, Marc, LX1DUC wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 10/04/2014 23:33, Marc, LX1DUC wrote:
(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 disregard this message, I was reading the previous message and replying to this one.
Your proposed setup could work for internal 44net traffic. But due to restrictions with routing setup of 44/8 @ UCSD, traffic from the commercial internet wouldn't necessarily always reach you. In cases where traffic is not routed to according to your BGP announcement, traffic would go to UCSD where it would end up in a routing loop.
If the traffic is not respecting our 44.24.240.0/20 BGP announcement, then there has been an Internet routing error. We can work on any such edge cases as they come up, but 99% of the time things will route OK.
Additionally some check would need to added to the portal 44GW should only be allowed to have a 44net address if that address is part of an independent BGP announce. Tunneling of a 44net to a 44GW which itself is only reachable via another 44GW and tunnel is probably not desirable.
I think a simpler/stricter check might be to make sure the 44GW is (1) part of an allocated 44net, and (2) that 44net is not configured with a gateway at all, and (3) the 44GW is not in the range of any of the 44nets being presently configured with said gateway.
Furthermore, if the 44net which contains the 44GW ever wishes to configure a gateway for itself, it should be denied until all its IPs are not in service as 44GWs for other 44nets.
This is a fair bit of logic, which is why I asked to have our 44.24.221.1 gateway configured manually first and only then have the portal work done. It'll probably take a while to implement the right logic here.
--Bart
On 04/10/2014 02:33 PM, Marc, LX1DUC wrote:
(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).
The default route for traffic with ORIGIN (read NOT necessary DESTINATION) inside 44/8 will be routed via IPIP to UCSD.
The Internet, in general, does not care about your source IP when making routing decisions. Routing tables work on destination IP information.
I suspect you're referring to a specific case of policy-based routing rules that have been deployed at UCSD and are causing breakage. That's a separate problem I'll deal with later. UCSD is not necessary for the success of the IPIP tunnel mesh communications.
Any potential traffic for 44.24.240.0/20 should never touch UCSD. It's either sent directly via Internet, or via the IPIP tunnel mesh. Traffic to/from UCSD itself may have a problem due to aforementioned routing weirdness @ UCSD, which we'll look at later.
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.
I'm not sure why you're bringing up NAT. If you're terminating your IPIP tunnels on your edge router the de/encapsulation and communication can take place entirely without engaging NAT. Your edge router would hold your public IP, and can associate the IPIP tunnels with it. If you're terminating the tunnels inside your network instead, then yes, you'll need some forwarding rules and NAT. I would suggest terminating on your edge router for simplest config.
Read BCP38. Really read BCP38. Read BCP38 again.
What is it you think I'm missing here that's in BCP38?
--Bart
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).
I think the issues still come because of BCP38.
44GW have access to the commercial Internet and 44net, so you need to apply source and destination based routing rules. In general you will
1) handle traffic with an ORIGIN within 44/8 in a dedicated routing table 2) handle traffic with a DESTINATION within 44/8 in a dedicated routing table
So once the IPIP packet towards your 44GW has been created and the SOURCE is a commercial IP address and the DESTINATION is a 44net address. Rule 2) from above will kick in. As your network 44.24.221.0/24 is not in the encap file, there is no route in the dedicated routing table and as such the traffic travel via the default route in the dedicated routing table. That default route within the dedicated routing table goes via UCSD because of BCP38.
So what you are asking is to ignore routing rule (ip rule NOT ip route) once a packet has been encapsulated into IPIP. This seems to be difficult using the current code, there might be a possibility using iptables and packet marking. Another solution would be to specifically exclude your 44GW ip address (44.24.221.1) from rule 2) (and 1) if I happen to apply the same implementation than yours).
73 de Marc
-
Bart Kus -
Brian Kantor -
charles＠thefnf.org -
Dean Gibson AE7Q -
Don Fanning -
Jann Traschewski -
K7VE - John -
lleachii＠aol.com -
Marc, LX1DUC -
Marius Petrescu -
Neil Johnson -
Nigel Vander Houwen -
Ryan Elliott Turner -
Tom Hayward