44net May 2018

44net@mailman.ampr.org

33 participants
33 discussions

Network 44.190.0.0/16 - Further information
by Jann Traschewski 15 May '18

15 May '18

Description: The network 44.190.0.0/16 is available to host amateur radio internet services using direct BGP. Allocations will be made usually in /24 chunks. The focus of this network is to transfer data as direct as possible (no radio, no tunnels) to keep reliability high. AMPRNet systems with no dynamic routing protocol support are able to route 44.190.0.0/16 via their ISP. Background: AMPRNet allocations are not partitioned by connectivity type. Each individual network can either be of type "radio", "tunnel" or "direct". AMPRNet systems may be "dual homed" and have a line based and a radio connection, thus there needs to be a decision whether a packet should be forwarded by line or by radio. This _could_ be achieved by AMPRNet systems *with* dynamic routing protocols by learning the routes and treating each route by its type (or any other available "flag"). However this will _never_ be the case for AMPRNet systems *without* support for dynamic routing protocols. Endusers running a *radio* connection to AMPRNet infrastructure such as HAMNET User Acess Points, IPIP-Mesh Gateways or even direct-BGP Gateways might ask how to integrate the radio connection into their home-LAN to have permanent access using any device on their LAN. Unfortunately standard home routers do not provide dynamic routing protocols, but there is often the functionality to add additional static routes like "44.0.0.0/8 via radio" and "44.190.0.0/16 via ISP". Sometimes customers are *forced* to use the router provided by the ISP to access the Internet (such a requirement is prohibited by law in Germany). Those might have no functionality to set static routes at all and you might end up attaching another router to the router to gain more functionality... As of today the standard setup for "dual homed" AMPRNet systems *without* support for dynamic routing protocols is to add 44.0.0.0 netmask 255.0.0.0 via <radio device within the home-LAN>. Outbound connections to 44.x.x.x will be made by their radio with the source-44 address and outbound connections to the Internet will be made with the source address obtained from the ISP. This worked without any issues as long as there were no direct BGP allocations within the network44. Nowadays we have several amateur radio internet services provided on the Network44 by direct BGP and the accessibility for the above mentioned AMPRNet systems highly depends on a proper radio connection and the backbone infrastructure to transfer the packet to its destination. The idea of 44.190.0.0/16 is to give willing stakeholders the opportunity to improve the situation. Amateur radio internet services can be hosted in that range while AMPRNet systems can make use of the additional route 44.190.0.0/16 via their ISP. The following issue has much more impact: Once direct BGP allocations started within the Network44 we encountered situations of full incompatibility. It is the case for amateur radio internet services (e.g. Echolink) working with a directory to map callsigns to IP addresses. Echolink does learn the IP address of an Echolink station (respectively of the used Echolink Proxy or Relay) from the inbound connection to the directory service. This leads to the problem, that AMPRNet systems forwarding 44.0.0.0/8 to the radio device on the roof will not have a slow or weak connection to a Echolink station using direct BGP but even *no* connection at all. Since they are registered on the Echolink network with their IP address obtained from the ISP but appearing with their Network44 address used over radio at the Echolink station using direct BGP, the connection is dropped due to a mismatch between "IP address <-> callsign". This will not happen if Echolink Relay/Proxy Servers or Echolink Stations will make use of address space from 44.190.0.0/16 while AMPRNet systems route 44.190.0.0/16 via their ISP. There will be no IP mismatch anymore. I made a diagram explaining the situation: http://db0fhn.efi.fh-nuernberg.de/~dg8ngn/echolink-amprnet.pdf 73, Jann -- Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de Ham: DG8NGN / DB0VOX / DB0FOX / DB0ZM / DB0DBA / DB0HZS

11 19

DNS Web tool
by Brian 14 May '18

14 May '18

For those who use my Amprnet DNS management web tool, just a note to let you know it's been completely rewritten. Your login credentials will still work, and it still forces SSL/TLS, but now reCaptcha has been added. I tried to keep the look and feel of it somewhat similar to the old one. Don't be shocked when you see a captcha box on the screen now. -- Did you know that dolphins are so smart that within a few weeks of captivity they can train people to stand on the very edge of the pool and throw them fish? ----- 73 de Brian N1URO IPv6 Certified SMTP: n1uro-at-n1uro.ampr.org IPv4: 44.88.0/28 IPv6:2001:470:8a1e::/48 https://uronode.n1uro.com (dual stacked) https://n1uro.ampr.org (dual stacked)

1 0

Re: [44net] Network 44.190.0.0/16 - Further information
by Rob Janssen 13 May '18

13 May '18

> Each 44.190.x.0/24 subnet arranges its own BGP advertising, > so there isn't just one point. They are spread all over the > world. > - Brian Note that due to this, the approximate location in IP geolocation databases has to be set for each of the /24 subnets. The default location for 44.0.0.0/8 is San Diego, California, USA. I have set the location for 44.137.0.0/16 to Amsterdam, Netherlands and other country ip coordinators have done similar for their countries. And of course an individual amateur can set a more accurate location for their smaller subnet. It comes into play for some services that use IP location aware DNS to direct users to a geographically closest (and hopefully this translates to closest in network topology) service. With all the 44.190.0.0/16 networks located in San Diego this of course isn't going to work. Echolink is such a service that users IP geolocation. You can enter an address from your subnet in lookup services like this: https://www.iplocation.net/ It shows what some of the more important services return for your location. And when clicking on the link for each service it is usually easy to submit location data for a subnet to that service provider. Rob

5 5

Re: [44net] OT: Recommendations for a small to medium size router for a multi-purpose repeater site
by Rob Janssen 12 May '18

12 May '18

> One thing I'm unclear on with Mikrotik is their different generations of > hardware. I DO want to make sure I get the newer generation so, in > theory, I get the longer supported OS support. Does anyone know if the > CCR1009-7G-1C-1Splus is a new generation of hardware or is it older? > Regarding buying a box that can run "The Dude" on an internal SSD, do > Wifi, or other stuff on the side. That was something I was planning on > running on a separate machine with say TICK, Zabbix, etc. Not sure but > I seriously worry if something goes south in that system, can it harm > the router. That's NOT acceptable in my book. The CCR1009-7G-1C-1Splus is the latest model in the CCR series, but the RB1100AHx4 is a newer router that could well be the root of more new models in the future. Of course one never knows such things for sure, but the Tilera TILE processors in the CCR series appear to have less current development than the processor used in the 1100. I would expect MikroTik to support the CCR in software updates at least for some years. Remember that all MikroTik routers include software support for the support lifetime of the device, no need for a separate support contract for that. The selection also depends on the network architecture. The RB1100AHx4 has two hardware switch chips each driving 5 ports so you can have hardware switching between those ports, while the CCR series ports are all independent router ports, they are expected to be connected to an external switch when you want hardware switching. So the CCR is a true router while the RB1100AHx4 is a router-switch combination. And the CCR has an SFP and SFP+ slot for fiber etc. The CCR does not have internal M.2 SSD like the RB1100AHx4 Dude edition, but it has a slot for an SDHC card and a USB port that both can be used for external storage. Rob

1 0

OT: Recommendations for a small to medium size router for a multi-purpose repeater site
by David Ranch 12 May '18

12 May '18

Hello Everyone, Considering there is a good chunk of routing-savvy HAMs here, I thought I'd use you as a sounding board on what would be a good router to buy. Specifically, I have a project to consolidate the current adhoc setup of three consumer grade "routers" to one larger, better router. I'm considering something like a: https://mikrotik.com/product/CCR1009-7G-1C-1Splus <https://mikrotik.com/product/CCR1009-7G-1C-1Splus> or maybe https://mikrotik.com/product/rb1100ahx4 <https://mikrotik.com/product/rb1100ahx4> I'm looking for something that is: - very stable - offer long term software updates (a support contract might be fine) - Has strong support for IPv4 NAT (to better the consumer routers mentioned above) for the three IPs we have onsite - maybe some L2 segmenting and vlan'ing support for traffic isolation - has performance to grow into - has a decent GUI UI for others in the club who can't / won't cope with a CLI - ACLs to limit incoming traffic to specific hosts (say limit RDP traffic to just some people to some hosts, etc) - maybe.. just maybe support SSL VPNs or IPSEC - maybe dual power supplies - stretch goal: native support for IPv6 - I have no need for dynamic routing protocols. This is a single site and statics are fine For background on our needs, the site supports a multi-RF link repeater system has: - two unique IRLP nodes (low use) - one Echolink node (low use) - one WIresX enabled Yaesu System Fusion repeater (decent use) - One three band Icom Dstar stack (1.2Ghz DD system as well) (decent use) - One Internet enabled Motorola DMR repeater (decent use) - backhaul of rarely used multi-county 3.4Ghz wifi network - other random needs for remote management (SSH, RDP, etc) I believe something like a Miktrotik would be fine for our low-end needs but maybe something from Ubiquiti or others would be fine. I'm perfectly comfortable with a CLI and I'm decently versed in Mikrotik (a bit weird of a UI), IOS (but I don't want to pay for Cisco prices, JUNOS (same point), etc. I personally think a lot of the lower tier vendor's products have come a LONG way so I don't need/want/care for "carrier" grade. If you have any other recommendations for a quality but not too expensive router, I'd love to hear it! --David KI6ZHD

5 5

Re: [44net] OT: Recommendations for a small to medium size router for a multi-purpose repeater site
by Rob Janssen 12 May '18

12 May '18

> The power can be provided by a picopsu 150 watt is usely more then enough The CCR1009 (a router with 9-core 1200 MHz TILE CPU, 1 10Gbps and 8 1Gbps ports) consumes 20 watt in actual use. It comes with dual (redundant) powersupplies, dual (redundant) fans (or passively cooled) and is ready to use for $495 The RB1100 is even less, $299 without or $349 with the 60GB disk option. Rob

2 1

Re: [44net] OT: Recommendations for a small to medium size router for a multi-purpose repeater site
by Rob Janssen 11 May '18

11 May '18

> I would go with a small itx pc with dual gygabit nic and a 4 port pcie gygabit nic. that give you 6 nic in a box. > Run this under Openwrt, or opensense or pfsense. You could even run miKrotiK OS > you can have a small ssd in there and 4 gig of ram to be sure all is ok and this setup would be able to do all of your need and even more. Of course it also uses more power, and takes more effort to construct and install. It can sometimes be useful to have more flexibility, but for general router usage it usually is overkill. Those MikroTik boxes work after unpacking and some basic config tasks. However you can still spend hours and hours to make them do a lot more :-) Rob

4 5

Re: [44net] OT: Recommendations for a small to medium size router for a multi-purpose repeater site
by Rob Janssen 11 May '18

11 May '18

I agree with what Marius wrote. Those models will perform very well in a network like that. We use a CCR1009 in our gateway for the 44.137.0.0/16 network (BGP routed on internet) and use it to provide VPN services to users and nodes inside the country, and to feed the radio network as well. The RB1100AHx4 should be equally capable of that. I would avoid the RB3011, should there be a tight budget or should there be a need for smaller devices at other places in the network it is better to use models like RB750Gr3 or the proven RB2011. As with any router and in fact with any device connected to internet, you will have to make sure it runs uptodate software (software can be upgraded for free as long as the device gets software updates, which will be quite some time for these models) and also you have to configure it in a reasonably secure way, e.g. make sure the management interfaces (telnet, ssh, webfig, winbox) are only accessible for your own people and not for the internet at large. This can be done by restricting them to certain interfaces, subnets, individual addresses on internet, and/or by using a VPN for management access. Keeping the management ports (22,23,80,8291) open on internet has proven to be a recipe for disaster. Rob

1 0

Wrong portal entry 44.151.31.6
by Marius Petrescu 11 May '18

11 May '18

Hello, There is a problematic entry in the portal which needs our attention: 44.151.31.6 / 32 via 44.151.31.6, according to the portal allocated to F1SXO, France, Occitanie, Haute Garonne The problem is that the RIP entry 44.151.31.6 via 44.151.31.6 is wrong, ilogical, and creates a routing loop. On Mikrotik routers, this will sow as a flapping of the ampr-44.151.31.6 interface. The solution for the moment is to filter that entry in the RIP filters and delete the 2 routes to it and its associated interface by hand. I had no time to check the behavior on ampr-ripd and amprd systems but is basically lead to the flapping of the route. After correcting this issue in the portal, on these systems, a remove of the static route 44.151.31.6 via default gw should be necessary (ampr-gw and amprd do not remove those static routes - known problem). The final solution is to correct the entry in the portal. Marius, YO2LOJ

2 2

Setting up a tunnel to my BGP's 44net range
by Tony Langdon 09 May '18

09 May '18

Now that my BGP announced 44.x range is up and running, I'd like to be able to make it transparently accessible for tunneled networks. I just need to double check a few things. First, I know I'd need to run ampr-ripd on the box. I also have non-44 net addresses to use as the ipip encap endpoint. What else do I need to do? Do I need to advertise the subnet as "tunneled" in addition to direct in the portal? Anything else? Reason for this is I'm likely to be running services other than Echolink proxies, which may require peer-peer connectivity. Currently, 44.x tunneled addresses connecting to the system would go via their local router, which most likely involves NAT. And on a similar note, is there a way to exclude other directly connected subnets capable of IPIP tunneling from using a tunnel? (since that's obviously not required!) -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

3 6

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net May 2018