44net

44net@mailman.ampr.org

4 participants
3198 discussions

Re: [44net] D-Star
by K7VE - John 23 Mar '16

23 Mar '16

Let me explain the whole 10.x.x.x thing for D-STAR. Icom created this to meet concerns of the Japanese postal service, to help mitigate the concerns of TCP/IP over D-STAR displacing the ISP monopoly. In D-STAR, the digital data mode transports Ethernet packets (and in turn TCP/IP) as a payload to D-STAR packets. Routing is done based on the D-STAR addresses which are call signs plus an optional "Terminal ID", essentially an 8 octet address. If you are using the Icom G2 (or V1) gateway software it talks to the Icom RP-2C controller over Ethernet using 172.16.0.x addresses. On the controller you can add up to 4 modules. A module can be a D-STAR voice repeater (2m, 70cm, 23cm) or D-STAR data access point (23cm 128kbps). In theory then you could have up to 4 D-STAR data access points (model RP-2D). As traffic from the RP-2D modules come into the gateway, it assumes it has a unique IP address in the 10.x.x.x range (assigned by a registration process), but routes according the D-STAR addresses. The IP addresses are registered to attempt avoidance of address collisions. So if I as 10.10.10.1 (K7VE) want to contact NN1XYZ (10.3.2.1), the gateway software sends the Ethernet packets from D-STAR address K7VE to D-STAR address NN1XYZ. The 10.x.x.x addresses are also NATed out to the Internet if the destination address is not in the 10.x.x.x range. None of this is used if you are only doing Digital Voice over D-STAR. Everything is routed by callsign and the voice packets do not encapsulate any TCP/IP or Ethernet content (well you could but it is not standard). Now the reality is G2 is closed and largely stagnant, it also runs on Centos 5.x which is losing update support, many data facilities have security concerns if you are hosting with them. The larger network is now running on ircDDB (ircddb.net) using ircddbgateway (see Yahoo! group by the same name). ircDDBGateway is Open Source and is pretty agnostic on Linux distributions as well as being available as a Windows application. ircDDBGateway supports the Icom controller as well as a variety of alternate controller options. I would strongly encourage any new D-STAR install to use ircDDBGateway (or another ircDDB based gateway). You don't have to use the Icom addressing scheme. The RP2C can be on a LAN address. Client stations of the RP2D (ID-1 radios) can then use LAN/DHCP addresses (including 44-net). -- ------------------------------ 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>

2 1

Re: [44net] D-Star
by Rob Janssen 23 Mar '16

23 Mar '16

> This is the local IP setting of the gateway. > It expects to be connected to a router with 10.0.0.1/8 witch will NAT to the > Internet. > In other words, the D-STAR device has a default route via 10.0.0.1, that's > all. > No conflicts here. Well, I agree with Pedja that it is an extremely unfortunate choice and that it would have been much more convenient when it supported 44-net addresses or even an arbitrary address on the LAN. We are running several D-Star repeaters and this requirement makes it very difficult to share resources. Even running multiple D-Star gateways on the same ESX system is more difficult than it ought to be (when a single router is running in another VM). Also note that this program has other strange requirements. It requires an ancient CentOS distribution, for example. That is why we want to put it in some ESX VMs. Rob

1 0

protocol 0002 is buggy
by Poland AMPRNet Co-ord. - Janusz HF1L (ex.SP1LOP) 22 Mar '16

22 Mar '16

Hi everyone.. I have a problem, from 3 months I use Debian 7.9 kernel 3.13.3 in part hamradio use jnos 2.0j and from the very beginning I have a problem in kern.log I have all the time such data: /var/log/kern.log ... Mar 20 08:03:07 server kernel: [1908060.719531] protocol 0002 is buggy, dev bcsf0 Mar 20 08:03:07 server kernel: [1908060.865694] protocol 0002 is buggy, dev bcsf0 Mar 20 08:03:07 server kernel: [1908060.885101] protocol 0002 is buggy, dev bcsf1 ... Mar 20 20:13:16 server kernel: [1951869.497517] protocol 0002 is buggy, dev ax0 Mar 20 20:13:18 server kernel: [1951871.496945] protocol 0002 is buggy, dev ax0 Mar 20 20:14:26 server kernel: [1951939.652479] protocol 0002 is buggy, dev ax0 Mar 20 20:15:53 server kernel: [1952026.478022] protocol 0002 is buggy, dev ax0 Mar 20 20:16:12 server kernel: [1952045.710541] protocol 0002 is buggy, dev ax0 Does anyone know how to fix that such messages was not ?. -- 73 de Janusz HF1L (ex.SP1LOP) ===== Janusz J. Przybylski, HF1L ==================== Poland AMPRNet Co-ordinator [44.165/16] from Mar 2003 =====================================================

4 3

Re: [44net] ports / Protocoles needed to be opened for a gateway ?
by Rob Janssen 21 Mar '16

21 Mar '16

> IRLP: > TCP 22 - SSH Not a good idea at all to open this port to the world! Rob

2 1

ports / Protocoles needed to be opened for a gateway ?
by R P 20 Mar '16

20 Mar '16

Hi Does anyone know what ports \ protocols needed to be open to allow ipip tunneling ? The Idea is not to place the gateway in the DMZ in a home internet connection when the gateway sit there / Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

3 2

Re: [44net] DNS cleanup
by Rob Janssen 20 Mar '16

20 Mar '16

> It's getting the legacy allocations into the portal that's not > making me happy. Admittedly, the process is painful but I didn't > think there'd be too many since we've had several years to get > things in. Rob's point about needing some kind of bulk update > process is well taken, and I'll look into that. I think what I need is some way to feed a list of subnet/callsign pairs into the portal (using a tab-separated file, XML file, json file, or whatever the implementer feels most happy with) and it can create the subnet allocations and set the type and the description of the subnet (to that callsign), but leave the owner unset. Then, when this particular OM creates a portal account and is validated and accepted the normal way, those dangling subnet allocations would be automatically attached to his account without me having to approve them. Alternatively, rudimentary accounts could be created automatically so the subnets could be attached to them immediately, but the completion with the details asked when this particular call is registering would be deferred until that happens. Important is that I can make bulk changes (like addition of a thousand entries) as a coordinator without having to go through the current process of "registrant fills a webform, I receive a mail and have to go to the portal and add/change some fields to approve it" for each and every of those subnets. It would be nice if there also is a way to process a callsign or allocation change this way (delete old still dangling subnet allocations and create new ones with different address or different callsign from a batch file). This because we are in the process of building new nodes and need to renumber some areas, which could contain entries that are not yet claimed by the owner. Furthermore I would like to have the capability, as a coordinator, to change the address and owner of an already allocated subnet. I can now change the type, description and notes of an allocation, but not the address or user it is allocated to. (this would not need to be a batch operation, just an addition to the existing "Coordinator: Network Allocations" screen would suffice) Rob

1 0

Re: [44net] BGP community values
by Rob Janssen 20 Mar '16

20 Mar '16

> Just a thought, if the lowest link on the route to a destination has 1 single link at 10kbps this will also be the maximum speed you > can achieve over that path towards this specifc destinatio , so there is no need to multiply the different communities. Ok... In that case a (small) number of communities could be used and a filter list to match them from slow to fast and assign some preference value. However, this will not be enough to make a consistent and optimal set of routes I'm afraid. We'll see how it works out once we encounter this situation in practice and can check if it leads to unwanted routes and this change would improve it. > BTW we use eBGP between sites but we combine this with BGP confederation. This brings the benefit of eBGP > (only BGP sessions with link peers) and keeps AS PATHs short towards our external peers. I still have to find the limits of the AS PATH length (hard or practical). Looking this up after a mention in a direct mail I found that there apparently is or was an implementation limit in Cisco routers at a path length of 256 that destabilized the internet 7 years ago. We are not anywhere near such lengths. However, I am aware that longer path lengths probably mean more data traffic between peers and maybe a little more memory and CPU use, so it could be worthwile to keep these down a bit. > We also opted for a single routing protocol versus OSPF within the internal network with iBGP overlay and eBGP on the edge. Ok, that is what I am doing for now as well, it has to be kept a bit simple not only for me but also for other people who like to install a node and configure it themselves. Rob

1 0

Re: [44net] BGP community values
by Rob Janssen 20 Mar '16

20 Mar '16

> AFAICT making a difference between routes learned via radio, tunnel or the AMPR IPIP mesh > has most importance within your local AS. You may forward those annoucements by any mean to another AS. > For example, you may learn a route via tunnel bit forward it via radio to another AS. This other AS may > learn that same route via tunnel and your radio link. So the question may come up if that other AS should > prefer a direct route via tunnel ot a route learned via radio whcih ultimately still goes via a tunnel. > From a HAM perspective you might want to prefer the longer route via radio but then you will eventually > have to pay for the bandwidth used by that other AS, but this might not be relevant in your case. I have been varying what is an AS, but at the moment I am using the simple "one site is one AS". This means everything is eBGP and there is no interior routing protocol. Of course one could define larger areas and use iBGP within them, but it will be very difficult to set up a reasonable system because geographical boundaries and management group boundaries are very different here, and also difficult to predict. Some people may want to do everything themselves, others will leave the management to me. And of course we like "simple" deployment without the headaches of setting up peering with an increasing number of routers within the AS. With eBGP you only need to peer with the routers you link to. I have read that in other countries OSPF is used as IGP and eBGP on top of that as an inter-AS protocol. That is most likely too difficult to deploy here, except when we exclusively use OSPF inside the country and BGP at the links to our neighbors. The way I see it now is that we use eBGP to exchange the routes between our nodes inside the country and our gateway, where we distribute 3 routes (0.0.0.0/0, 44.0.0.0/8 and 44.137.0.0/16) that can be used as "default" easily selectable with a filter, and the /22 or lower subnets are exchanged as defined in our IP plan. When we make links to our neighboring countries Germany and Belgium, we will only send them the aggregated route to 44.137.0.0/16 and not the route to 44.0.0.0/8 or 0.0.0.0/0. When we receive /15 or smaller routes from them we announce them inside our network and also to the other neighboring country, so we can also carry transit traffic from Belgium to Germany and v.v. We are not going to route traffic towards internet for them, neither direct nor tunneled. > What may be of interest in a more universal way, might be the available bandwidth on the route. > A route which goes over multiple links (whatever kind) of which one has one link limited to 50kbps > might be worth to be used as a secondary route over a route which has the slowest link at 1 Mbps, regardless of the technology. > So may we should define "well known communities" which define the link speed over which they are learned. > Those pseudo well known communities could start by X: followed by the bandwidth class. For example: > 0:1 = 10kbps > 0:2 = 100 kbps > 0:3 = 1 Mbps > 0:4 = 10 Mbps > Etc The problem with eBGP is that there is no other metric than hop count to select preference of a route, all other selections have to be made by local static configuration or derived from community values. In the automatic routing protocols we used before, like NET/ROM, the metric of a path is calculated from the metrics of the individual links, and assigning a metric corresponding the the quality of each link would influence the selection of that link as part of a long path. 3 fast link hops could be preferred over one slow one. Not so in eBGP. You can influence the path by introducing "artificial" extra hops on slow or bad links, so that for example a 10kbps link counts as 3 hops, and is not used when two other faster hops can reach the same destination, but of course this works very coarsely. A system as depicted above could only be used at the next hop, but it would not be easy to assign such values to every link and then calculate an aggregate metric of all the hops to the destination. Routers can match community values using a direct compare and often a simple pattern match on the decimal representation of the numbers (e.g. when the value is 1234 you can match on 1??? to select the values that start with a 1 when written in decimal), but operations like multiplying community values to achieve a new value to be used as a preference are not available. That means you would need long and complicated matching tables to do anything with information like you propose. Rob

2 1

cleanup?
by Rob Janssen 19 Mar '16

19 Mar '16

What is the status of the "to-be-deleted.txt" cleanup? There are 14946 entries that were announced to be deleted early march, but looking at the current zonefile it appears that only about 1524 have been deleted at this time... (I have deleted about 1000 entries, that were not on that list, in 44.137 myself) Rob

3 4

DNS cleanup
by Brian Kantor 19 Mar '16

19 Mar '16

With the kind cooperation of Neil Johnson, I've identified nearly 15000 entries in the AMPR.ORG DNS that I feel can go away. What was done was to create a list of valid subnets of network 44 by combining the encap list, the list of BGP-advertised subnets, and extracting all the connected or end-user subnets listed in the portal. We then made a list of all the DNS entries that no longer fall into any of those subnets. This is nearly half the "A" records in the DNS. That list is available for review by anonymous FTP from hamradio.ucsd.edu. The file is called "to-be-deleted.txt". I encourage everyone who has a DNS entry to fetch a copy of the file and make sure that we haven't accidently included any entries that need to remain in the DNS. Please let me know of any such entries and I can remove them from the list. Assuming our scheme worked, around the beginning of next month, March, I will process the list and remove those entries from the DNS. We still have a long ways to go but this will help. Thank you. - Brian

7 13

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net