For some time we have been hosting Echolink proxies and relays on the system that is the gateway for 44.137.0.0/16 (BGP routed) in Amsterdam, Netherlands. We use a /24 subnet for that. Such proxies and relays facilitate the use if Echolink by users and repeaters that are behind NAT or are otherwise firewalled. About 100 repeaters around the world use our proxies, and over 600 users of the mobile app use our relays.
Each Echolink proxy and relay requires a different IPv4 address. This can be a static address on internet, but often people have no /24 to spare for such things. AMPRnet provides the required address space. (unfortunately with an unintended side-effect, but in general it works well)
For performance of the Echolink system it would be best when there are more places with a similar setup, distributed around the globe. Are there other BGP-routed sites outside Europe where such a service could be run?
I have written a C program for this, that uses considerably less resources than the original Java software. On a 2.67GHz XEON server it causes a load around 0.05 for our 200 proxies and 10 relays. Of course it makes some network traffic, about 3 GB/day for the relays and similar for the proxies.
When you have your gateway located in a suitable datacenter and are interested in such a setup to facilitate Echolink, please send me an e-mail and I can provide more info. Maybe we could even get the whole echolink.org infra hosted on AMPRnet space, which would solve the problem there now is with partially connected AMPRnet networks. (when the directory server is on AMPRnet, the problem with NAT between HAMNET and internet disappears)
Rob
On 19.04.2018 10:50, Rob Janssen wrote:
when the directory server is on AMPRnet, the problem with NAT between HAMNET and internet disappears
I'm afraid, it would raise new issues...
For those who are planning to provide echolink proxy services (or any other useful internet based amateur radio services) within the AMPRNet by direct BGP, please ask for an /24-allocation within 44.190.0.0/16.
We will promote to all HAMNET users and sysops to route 44.190.0.0/16 to their ISP rather than to their radio device on the roof.
Best case would be to host such services on non-44 IP-space at all.
73, Jann
Hi Jann,
Le 19/04/2018 à 16:12, Jann Traschewski a écrit :
For those who are planning to provide echolink proxy services (or any other useful internet based amateur radio services) within the AMPRNet by direct BGP, please ask for an /24-allocation within 44.190.0.0/16.
We will promote to all HAMNET users and sysops to route 44.190.0.0/16 to their ISP rather than to their radio device on the roof.
Is that what you briefly talked about in your email a few weeks ago ?
Could you explain a little bit how this could work ? You'll probably announce the 44.190.0.0/16 from some location in Germany, but how could I host some machines (ie 44.190.199.0/24) in my location without direct BGP announcement ? How would incoming requests to 44.190.199.1 be forwarded to my public ISP IP ?
We are in the process of getting a subnet for direct BGP announcement for Corsica, but we would like to try to be compatible with all the existing (and future) routing methods.
73 de TK1BI
I actually have some server resources where I was considering hosting a large echolink proxy service for echolink users however I have run into issues getting fiber providers to bring the ip’s in for me to use.. So I am not sure what my next step should be considering returning my ip’s if I can’t seem to follow through.
By the way I have to use Java for minecraft servers so my 12 core 24 thread should easily handle a bunch of proxy servers.. However if you have some thing that is Linux based and works well I would be all ears to help out the community using the newer code if willing to share..
Loren Tedford (KC9ZHV) Phone Main: 1+ (631) 686 – 8878 Option 1 Fax: 1-618-551-2755 Email: loren@lorentedford.com Email: KC9ZHV@KC9ZHV.com http://www.lorentedford.com http://www.kc9zhv.com http://forum.kc9zhv.com http://hub.kc9zhv.com http://Ltcraft.net http://voipham.com
From: Rob Janssen Sent: Thursday, April 19, 2018 3:52 AM To: 44net@mailman.ampr.org Subject: [44net] Echolink proxy/relay hosting
For some time we have been hosting Echolink proxies and relays on the system that is the gateway for 44.137.0.0/16 (BGP routed) in Amsterdam, Netherlands. We use a /24 subnet for that. Such proxies and relays facilitate the use if Echolink by users and repeaters that are behind NAT or are otherwise firewalled. About 100 repeaters around the world use our proxies, and over 600 users of the mobile app use our relays.
Each Echolink proxy and relay requires a different IPv4 address. This can be a static address on internet, but often people have no /24 to spare for such things. AMPRnet provides the required address space. (unfortunately with an unintended side-effect, but in general it works well)
For performance of the Echolink system it would be best when there are more places with a similar setup, distributed around the globe. Are there other BGP-routed sites outside Europe where such a service could be run?
I have written a C program for this, that uses considerably less resources than the original Java software. On a 2.67GHz XEON server it causes a load around 0.05 for our 200 proxies and 10 relays. Of course it makes some network traffic, about 3 GB/day for the relays and similar for the proxies.
When you have your gateway located in a suitable datacenter and are interested in such a setup to facilitate Echolink, please send me an e-mail and I can provide more info. Maybe we could even get the whole echolink.org infra hosted on AMPRnet space, which would solve the problem there now is with partially connected AMPRnet networks. (when the directory server is on AMPRnet, the problem with NAT between HAMNET and internet disappears)
Rob
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hi Rob,
I'd be willing to host something on my gear in my Vancouver Datacenter. Only issue is I only have a single /24 at the moment and it's mostly used up by our radio network. I agree with Jann's comment that it would be useful to have these services located within a dedicated allocation to prevent Ampr-Internet routing complexity.
Chris
On 4/19/2018 1:50 AM, Rob Janssen wrote:
For some time we have been hosting Echolink proxies and relays on the system that is the gateway for 44.137.0.0/16 (BGP routed) in Amsterdam, Netherlands. We use a /24 subnet for that. Such proxies and relays facilitate the use if Echolink by users and repeaters that are behind NAT or are otherwise firewalled. About 100 repeaters around the world use our proxies, and over 600 users of the mobile app use our relays.
Each Echolink proxy and relay requires a different IPv4 address. This can be a static address on internet, but often people have no /24 to spare for such things. AMPRnet provides the required address space. (unfortunately with an unintended side-effect, but in general it works well)
For performance of the Echolink system it would be best when there are more places with a similar setup, distributed around the globe. Are there other BGP-routed sites outside Europe where such a service could be run?
I have written a C program for this, that uses considerably less resources than the original Java software. On a 2.67GHz XEON server it causes a load around 0.05 for our 200 proxies and 10 relays. Of course it makes some network traffic, about 3 GB/day for the relays and similar for the proxies.
When you have your gateway located in a suitable datacenter and are interested in such a setup to facilitate Echolink, please send me an e-mail and I can provide more info. Maybe we could even get the whole echolink.org infra hosted on AMPRnet space, which would solve the problem there now is with partially connected AMPRnet networks. (when the directory server is on AMPRnet, the problem with NAT between HAMNET and internet disappears)
Rob
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
That is what the block 44.190.0.0 is set aside for. The intent is to divide it up into /24s to be BGP-routed directly to the Internet, and people who otherwise would send 44.x.x.x traffic via radio or tunnel should insert a special routing rule that directs 44.190.0.0/16 to their ISP instead of the radio or tunnels, if they can. - Brian
On Thu, Apr 19, 2018 at 08:25:31AM -0700, Christopher S. Munz-Michielin wrote:
I agree with Jann's comment that it would be useful to have these services located within a dedicated allocation to prevent Ampr-Internet routing complexity. Chris
Thanks for posting this. I didn't know.
Michael N6MEF
-----Original Message----- From: 44Net 44net-bounces+n6mef=mefox.org@mailman.ampr.org On Behalf Of Brian Kantor Sent: Thursday, April 19, 2018 8:48 AM To: AMPRNet working group 44net@mailman.ampr.org Subject: Re: [44net] Echolink proxy/relay hosting
That is what the block 44.190.0.0 is set aside for. The intent is to divide it up into /24s to be BGP-routed directly to the Internet, and people who otherwise would send 44.x.x.x traffic via radio or tunnel should insert a special routing rule that directs 44.190.0.0/16 to their ISP instead of the radio or tunnels, if they can.
- Brian
On Thu, Apr 19, 2018 at 08:25:31AM -0700, Christopher S. Munz-Michielin wrote:
I agree with Jann's comment that it would be useful to have these services located within a dedicated allocation to prevent Ampr-Internet routing complexity. Chris
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Yes, it's just getting started and so we haven't written it up yet.
It's really only applicable to people who DON'T use the tunnel system at their end user equipment and DO route all of 44.0.0.0/8 via a low-bandwidth/high-delay link, and who DON'T have some other arrangement in place. Primarily to accomodate HamNet end-users in Germany, outside of some regions of Europe, it's just a bunch of non-region-specific BGP-connected subnets. - Brian
On Thu, Apr 19, 2018 at 10:08:44AM -0700, Michael Fox - N6MEF wrote:
Thanks for posting this. I didn't know.
Michael N6MEF
On 4/19/18 11:48 AM, Brian Kantor wrote:
That is what the block 44.190.0.0 is set aside for. The intent is to divide it up into /24s to be BGP-routed directly to the Internet, and people who otherwise would send 44.x.x.x traffic via radio or tunnel should insert a special routing rule that directs 44.190.0.0/16 to their ISP instead of the radio or tunnels, if they can.
- Brian
Brian,
I'd suggested this and the TAC team voted on this being a good idea 3 years ago. No action was taken by anyone on the board to do anything with it at that time. The TAC team largely gave up attempting to work with ARDC at that time due to the in action.
What changed? It's a bit concerning that policy and operational changes are handled in such an obscure and closed manner.
Essentially, it's time had come. There was a demonstrated need, and an available block of addresses. - Brian
On Thu, Apr 19, 2018 at 01:28:52PM -0400, Bryan Fields wrote:
Brian,
I'd suggested this and the TAC team voted on this being a good idea 3 years ago. No action was taken by anyone on the board to do anything with it at that time. The TAC team largely gave up attempting to work with ARDC at that time due to the in action.
What changed? It's a bit concerning that policy and operational changes are handled in such an obscure and closed manner.
-- Bryan Fields
727-409-1194 - Voice http://bryanfields.net
Hey Brian,
Thanks for the clarification, I was unaware of the purpose of that block.
How would I go about requesting a /23 or /24 from 44.190.0.0/16 to assist with Rob's project?
Chris
On 4/19/2018 8:48 AM, Brian Kantor wrote:
That is what the block 44.190.0.0 is set aside for. The intent is to divide it up into /24s to be BGP-routed directly to the Internet, and people who otherwise would send 44.x.x.x traffic via radio or tunnel should insert a special routing rule that directs 44.190.0.0/16 to their ISP instead of the radio or tunnels, if they can.
- Brian
On Thu, Apr 19, 2018 at 08:25:31AM -0700, Christopher S. Munz-Michielin wrote:
I agree with Jann's comment that it would be useful to have these services located within a dedicated allocation to prevent Ampr-Internet routing complexity. Chris
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Just apply for it via the normal Portal method. Jann is the coordinator. - Brian
On Thu, Apr 19, 2018 at 10:47:34AM -0700, Christopher S. Munz-Michielin wrote:
Hey Brian,
Thanks for the clarification, I was unaware of the purpose of that block.
How would I go about requesting a /23 or /24 from 44.190.0.0/16 to assist with Rob's project?
Chris
On 4/19/2018 8:48 AM, Brian Kantor wrote:
That is what the block 44.190.0.0 is set aside for. The intent is to divide it up into /24s to be BGP-routed directly to the Internet, and people who otherwise would send 44.x.x.x traffic via radio or tunnel should insert a special routing rule that directs 44.190.0.0/16 to their ISP instead of the radio or tunnels, if they can.
- Brian
On Thu, Apr 19, 2018 at 08:25:31AM -0700, Christopher S. Munz-Michielin wrote:
I agree with Jann's comment that it would be useful to have these services located within a dedicated allocation to prevent Ampr-Internet routing complexity. Chris
On Apr 19, 2018, at 10:54, Brian Kantor Brian@BKantor.net wrote:
Just apply for it via the normal Portal method. Jann is the coordinator.
I just applied for a /24 out of 44.190/16, to help with this endeavor.
I’ll be announcing the prefix out of a commercial datacenter in Fremont, CA under ASN 7247.
73, -jav k4jh
On 20/04/18 01:48, Brian Kantor wrote:
That is what the block 44.190.0.0 is set aside for. The intent is to divide it up into /24s to be BGP-routed directly to the Internet, and people who otherwise would send 44.x.x.x traffic via radio or tunnel should insert a special routing rule that directs 44.190.0.0/16 to their ISP instead of the radio or tunnels, if they can.
The problem I have with this is when traffic is routed via the regular ISP, the source address is no longer 44.x, it's the public IP of the NAT router. I'd like to see BGP announced subnets also directly accessible via a tunnel for those of us running IPIP tunnels. I'll soon be in a good position to test, as I now have both a direct BGP connected subnet and a tunnelled one at different sites. Obviously, I have a vested interest in getting the routing right for my own purposes.
The way I see it, the 44.190 and other directly connected space still need a tunnel interface and routing to communicate transparently with the tunnelled parts of AMPRnet (and avoid the delays of the main gateway). What I'd like to know is what is the best practice for doing this, that won't result in traffic that gets addresses mangled by NAT at one end?
I have a general idea, but as you know, the devil is in the detail. :)
On Sat, Apr 21, 2018 at 4:51 AM, Tony Langdon vk3jed@vkradio.com wrote:
The problem I have with this is when traffic is routed via the regular ISP, the source address is no longer 44.x, it's the public IP of the NAT router.
Why should I as an Echolink relay operator be expected to go through the additional effort of configuring IPIP just so you can enjoy the novelty of both ends of the connection having 44/8 addresses? Your IPIP encapsulated packet will still have your ISP's address and will take the same path regardless. I understood that one of the motivations of the 44.190/16 prefix was to allow end users to easily configure their routing policy correctly to avoid tunneling to UCSD first (which isn't the end of the world since Javier and I are setting up our relays also in California).
-- Kenneth Finnegan http://blog.thelifeofkenneth.com/
If all you're running are Echolink proxies and relays, sure, I get your argument, the issue of NAT at the source isn't a big deal and simply routing 44.190.0.0/16 via the NAT router at each end user is a good solution, but for those of us who WANT to do something more than merely run proxies on those addresses, I'd like to be able to get my routing right, so NAT doesn't bite me in the bum when I attempt to set something else up.
On Sat, Apr 21, 2018 at 11:57 PM, Kenneth Finnegan < kennethfinnegan2007@gmail.com> wrote:
On Sat, Apr 21, 2018 at 4:51 AM, Tony Langdon vk3jed@vkradio.com wrote:
The problem I have with this is when traffic is routed via the regular ISP, the source address is no longer 44.x, it's the public IP of the NAT router.
Why should I as an Echolink relay operator be expected to go through the additional effort of configuring IPIP just so you can enjoy the novelty of both ends of the connection having 44/8 addresses? Your IPIP encapsulated packet will still have your ISP's address and will take the same path regardless. I understood that one of the motivations of the 44.190/16 prefix was to allow end users to easily configure their routing policy correctly to avoid tunneling to UCSD first (which isn't the end of the world since Javier and I are setting up our relays also in California).
-- Kenneth Finnegan http://blog.thelifeofkenneth.com/
Wasn't the idea to 44.190.0.0/16 subnets available via BGP? If so, why would there be NAT?
On Sat, Apr 21, 2018 at 1:29 PM, Tony Langdon vk3jed@vkradio.com wrote:
If all you're running are Echolink proxies and relays, sure, I get your argument, the issue of NAT at the source isn't a big deal and simply routing 44.190.0.0/16 via the NAT router at each end user is a good solution, but for those of us who WANT to do something more than merely run proxies on those addresses, I'd like to be able to get my routing right, so NAT doesn't bite me in the bum when I attempt to set something else up.
On Sat, Apr 21, 2018 at 11:57 PM, Kenneth Finnegan < kennethfinnegan2007@gmail.com> wrote:
On Sat, Apr 21, 2018 at 4:51 AM, Tony Langdon vk3jed@vkradio.com
wrote:
The problem I have with this is when traffic is routed via the regular ISP, the source address is no longer 44.x, it's the public IP of the
NAT
router.
Why should I as an Echolink relay operator be expected to go through the additional effort of configuring IPIP just so you can enjoy the novelty
of
both ends of the connection having 44/8 addresses? Your IPIP encapsulated packet will still have your ISP's address and will take the same path regardless. I understood that one of the motivations of the 44.190/16 prefix was to allow end users to easily configure their routing policy correctly to avoid tunneling to UCSD first (which isn't the end of the world since Javier and I are setting up our relays also in California).
-- Kenneth Finnegan http://blog.thelifeofkenneth.com/
On 22/04/18 07:44, K7VE - John wrote:
Wasn't the idea to 44.190.0.0/16 subnets available via BGP? If so, why would there be NAT?
Well, I'm not talking about the 44.190 end, but if I host some service on my 44.190 for net 44, then if I am routing 44.190.8.x via my ISP, there will be NAT on my end. As I said to someone else, if all I'm doing is hosting Echolink proxies and relays, it's a non issue, but if I want to use the server for something else, it could be an issue.
Le 19/04/2018 à 17:25, Christopher S. Munz-Michielin a écrit :
I agree with Jann's comment that it would be useful to have these services located within a dedicated allocation to prevent Ampr-Internet routing complexity.
That's already what most people do. Some time ago, I had a look at the D-Star hosts file : only 1% of the IPs were using 44.0.0.0 space.
My personal opinion is that amateur radio guys should use amateur radio IP addresses whenever possible. And amateur radio network operators should make ise of those IP easier for everybody.
Our approach here in Corsica is to consider our AMPR allocation as we could consider an enterprise network : - Some machines are "private" (in the "amateur radio" meaning). These will be on "LAN". - Some other machines, such as a WEB server (or D-Star repeater), need public Internet access. These would be put in a "DMZ"
Then, we'll split our allocation into LANs and DMZs. Access rules will be managed by firewalls. But IP routing will be direct, with no more NAT or dual-addressing. That's a first step to what we'll have to do when we decide to migrate to IPv6, HI :-)
73 de TK1BI
It functions OK that 44 NL subnet.
My server IR0AAB-R at 44.134.32.240 receives every days several call coming from a 44.137.75.xxx subnet specially by using their Echolink for Android from any part of the world :)
73 and ciao, gus i0ojj/ir0aab
On 04/19/2018 10:50 AM, Rob Janssen wrote:
For some time we have been hosting Echolink proxies and relays on the system that is the gateway for 44.137.0.0/16 (BGP routed) in Amsterdam, Netherlands. We use a /24 subnet for that. Such proxies and relays facilitate the use if Echolink by users and repeaters that are behind NAT or are otherwise firewalled. About 100 repeaters around the world use our proxies, and over 600 users of the mobile app use our relays.
Each Echolink proxy and relay requires a different IPv4 address. This can be a static address on internet, but often people have no /24 to spare for such things. AMPRnet provides the required address space. (unfortunately with an unintended side-effect, but in general it works well)
For performance of the Echolink system it would be best when there are more places with a similar setup, distributed around the globe. Are there other BGP-routed sites outside Europe where such a service could be run?
I have written a C program for this, that uses considerably less resources than the original Java software. On a 2.67GHz XEON server it causes a load around 0.05 for our 200 proxies and 10 relays. Of course it makes some network traffic, about 3 GB/day for the relays and similar for the proxies.
When you have your gateway located in a suitable datacenter and are interested in such a setup to facilitate Echolink, please send me an e-mail and I can provide more info. Maybe we could even get the whole echolink.org infra hosted on AMPRnet space, which would solve the problem there now is with partially connected AMPRnet networks. (when the directory server is on AMPRnet, the problem with NAT between HAMNET and internet disappears)
Rob
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Rob,
I like to help with this as well. Please let me know the details on how to setup your C program.
I'm going to request for a /24 from the 44.190/16, and I'll announce it from Seatle via IONSwitch.
-bn 0216331C
On Thu, Apr 19, 2018 at 1:50 AM, Rob Janssen pe1chl@amsat.org wrote:
For some time we have been hosting Echolink proxies and relays on the system that is the gateway for 44.137.0.0/16 (BGP routed) in Amsterdam, Netherlands. We use a /24 subnet for that. Such proxies and relays facilitate the use if Echolink by users and repeaters that are behind NAT or are otherwise firewalled. About 100 repeaters around the world use our proxies, and over 600 users of the mobile app use our relays.
Each Echolink proxy and relay requires a different IPv4 address. This can be a static address on internet, but often people have no /24 to spare for such things. AMPRnet provides the required address space. (unfortunately with an unintended side-effect, but in general it works well)
For performance of the Echolink system it would be best when there are more places with a similar setup, distributed around the globe. Are there other BGP-routed sites outside Europe where such a service could be run?
I have written a C program for this, that uses considerably less resources than the original Java software. On a 2.67GHz XEON server it causes a load around 0.05 for our 200 proxies and 10 relays. Of course it makes some network traffic, about 3 GB/day for the relays and similar for the proxies.
When you have your gateway located in a suitable datacenter and are interested in such a setup to facilitate Echolink, please send me an e-mail and I can provide more info. Maybe we could even get the whole echolink.org infra hosted on AMPRnet space, which would solve the problem there now is with partially connected AMPRnet networks. (when the directory server is on AMPRnet, the problem with NAT between HAMNET and internet disappears)
Rob
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
-
Bao Nguyen -
Brian Kantor -
Bryan Fields -
Christopher S. Munz-Michielin -
Gustavo Ponza -
Jann Traschewski -
Javier Henderson -
K7VE - John -
Kenneth Finnegan -
Loren Tedford -
Michael Fox - N6MEF -
Rob Janssen -
Tony Langdon -
Toussaint OTTAVI