Dear colleagues!
From the information on the site wiki.ampr.org, implies that the construction of the AMPR-Net node require support of protocol RIPv2. At the same time, from the same source, it follows that the standard systems with support RIPv2 are not suitable for this case.
From this we can conclude that RIPv2 used in an unusual way.
*Where can I get an introduction to this non-standard system that allows to understand the technical sense?*
Looking archive mailing list, I received some fragmentary information. I realized that RIP is not used to compare alternative routes for efficiency, but for accounting for the dynamic addresses. However, all the circumstances I not grasped.
I think that every first administrator, thinking through the design of the node, asks this question. And surely, somewhere there must be a document drawn up for those interested. I was very surprised, when not to find the answer to this question in the FAQ.
If he's still there, and I was looking bad, forgive me, and specify its location. If not - please help me and tell me about this non-standart solution.
Advance very grateful.
Hi Rihard,
Regarding the usage of RIPv2, here are some details...
To be able to set up our mesh network, we need to know, for each mesh partner, the subnet with its mask and the gateway, to which we need to send the encapsulated traffic. That means, e.g. traffic to 44.182.20.0/24 needs to be encapsulated via ipencap (IP protocol 4) and sent to 89.122.215.236. On the reverse side, all encapsulated traffic from 44.182.20.0/24 comes in and needs to be decapsulated.
Decapsulation works for all incoming traffic, but to be able to encapsulate traffic, we need to tell the IPIP driver, which is point to multipoint capable, to which destination to encapsulate to. This is done by setting up special routes in the system. Assuming the tunnel interface is tunl0, this goes something like: ip route add 44.182.20.0/24 via 89.122.215.236 dev tunl0 onlink
Now, to gather the needed info for setting up these tunnels, there was the traditional way, by getting the encap.txt file manually, and parsing it via a script (called munge script).
To automate this and to adapt to fact changing gateway IPs, there was a need to get this data automatically to the GW's. And it would have been nice to get some authentication, to be sure the data is genuine. Here comes RIPv2 into play. The data carried by RIPv2 is exactly what we need: A list of subnet IPs, netmasks and a gateway IPs. And there is simple password authentication available, too.
In a standard way, RIP packages give you subnet routing infos but the gateway to which data has to be sent is the IP of tha machine which sent that data. In RIPv2, the gateway information is used only to optimize routing. So, in a standard RIP way, the info would translate to: ip route add 44.182.20.0/24 via 44.0.0.1 Which is obviously wrong, since it does not define the proper gateway device and encapsulation endpoint. Freely translated, this will get all of your outgoing 44net traffic being encapsulated and sent to 44.0.0.1, where it will be dropped.
Here come tools like ampr-ripd into play: They listen to the RIP information sent every 5 minutes by ampr-gw (44.0.0.1), check its authenticity by password and dynamically generate the proper routes for the P2MP tunnel interface, which is not possible by standard RIPv2 handling.
I hope this clarified the issue.
Marius, YO2LOJ
Hello, Marius!
Thank you very much for your explanation. If I understand you correctly, this is not quite the usual mechanism is made to minimize the inconvenience of the used tunneling technology.
Apparently, we are talking about the tunnels in the style of RFC-1853, a.k.a. NOS IPIP. Are they still used in common practice? Now is not 1993. The times of the legendary ka9q.exe long gone and there are many good solutions. That works through the NAT, allows clients to use a dynamic address and have reliable authorization.
Why still KA9Q/NOS? This is good old British tradition?
And I have a different question - why each network node must constantly keep and update a full map of the routes during the entire network? Unforgettable encap.txt from my youth... What topological model is implemented in a network now?
I'm sorry for a lot of questions, but I was expecting something other.
Hi Rihard,
Now is not 1993. The times of the legendary ka9q.exe long gone and there are many good solutions. That works through the NAT, allows clients to use a dynamic address and have reliable authorization.
Why still KA9Q/NOS? This is good old British tradition?
that was the 'stone age' :) You may refer to the docs on Maiko site:
http://www.langelaar.net/projects/jnos2/documents/
73, gus i0ojj
02.09.15 9:00, Gustavo Ponza wrote:
that was the 'stone age' :) You may refer to the docs on Maiko site:
Thank you, Gustavo!
Thank you for the link you sent. I found there are many different details about the package JNOS.
But my question was somewhat different story.
I was surprised that each node AMPR-Net should have a complete and updated map of the network routing. And I asked about what kind of network topology is now.
By the way, in my opinion, JNOS too, in a sense, the "stone age". Well, or "bronze". I guess now no one uses AX.25 or NETROM. Why routing overlay network use very specific daemon, judge for duplicating the functionality of the operating system?
Why for routing of tunnels used very specific daemon, which duplicate the functionality of the operating system? (It I about JNOS.) Why spend so much each user forces on obtaining technical information, which only need a router of backbone? (It I about file encap.txt and his updating through a variety of extraordinary ways.)
73, gus i0ojj
73! Yours faithfully, Rihard RU3DSH.
On Wed, Sep 2, 2015 at 9:21 AM, Richard RU3DSH ru3dsh@ogogon.org wrote:
I was surprised that each node AMPR-Net should have a complete and updated map of the network routing. And I asked about what kind of network topology is now.
AMPRNet is a mesh. Each gateway advertised in the encap/RIP must be directly routable on the Internet. When you have traffic for their subnet, it is encapsulated and then addressed to their gateway. This allows the traffic to take the shortest internet path between your two ISPs. If everything were routed through a central router, the paths would be significantly longer, there would be a potential for congestion, and there would be a single point of failure.
Tom KD7LXL
I would not call that one "stone age". It is just the only VPN type which allows a decent P2MP operation. And the topology is a complete mesh. And the mesh concept is actually more modern than you think: see WDS networks, redundant links between AS, backup links between providers, internet of things... Stone age was the classic architecture, with backbone routers, mesh IS the future.
The basic idea in a mesh is redundancy, and no single point of failure. And a complete mesh actually has no point of failures execept the nodes themselves. Our biggest problem is actualy the fact that we have a single encap information provider, the last element which is NOT in the mesh.
And the biggest issue is exactly what you say: "which only need a router of backbone". One single router, one single backbone, one single device, centralized costs.
Who pays for the equipment, who hosts and maintains it, and who ensures the bandwidth for all the 44net traffic to pass through it? In a mesh, each user has to ensure only his own bandwidth needs, on a on demand base.
So IMHO, this network is actually extremely modern. It was out of its time 20 years ago, and slowly enters mainstream now. Actually the mainstream alligns to our network...
73s de Marius, YO2LOJ
Hi Marius and all,
I would not call that one "stone age". It is just the only VPN type which allows a decent P2MP operation. And the topology is a complete mesh. And the mesh concept is actually more modern than you think: see WDS networks, redundant links between AS, backup links between providers, internet of things... Stone age was the classic architecture, with backbone routers, mesh IS the future.
Very correct. Years before the new 'portal.ampr.org' creation I proposed and just reiterate the proposal now, to build a *subsidiary* JNOS2 mesh to support, as general purpose, the amprnet/hamradio activities :)
What do you thing about it?
73, gus i0ojj
Hi Richard,
I was surprised that each node AMPR-Net should have a complete and updated map of the network routing. And I asked about what kind of network topology is now.
just replayed by Marius.
By the way, in my opinion, JNOS too, in a sense, the "stone age". Well, or "bronze". I guess now no one uses AX.25 or NETROM.
The AX.25, the Netrom, and even the Rose are currently used by ham community nowadays together with the Flexnet, INP3 etc.; and the actual JNOS2 was improved enough by featuring the B1F and the B2F compression protocols, the INP3 and several packet drivers too; furthermore it can speak to linux machine by means the 'tun0' tunnel and through the very improved AXIP/AXUDP methods allowing a full operation (as for my concerns) to any ham site operating with a dynamic IP address! :)
Why for routing of tunnels used very specific daemon, which duplicate the functionality of the operating system? (It I about JNOS.)
Owning a commercial IP address, the actual JNOS2 is able, per se, to automatically catch the ucsd RIP2 broadcast and manage them by the venerable standard 'encap' interface and so automatically manage the *encap routes* without any other external daemon... TNX to Maiko.
Linux and rip44d daemons make the same things allowing the dynamic IP address owners to participate to the 44-net mesh: TNX to Heikki/Hessu and Marius for their good jobs!
Why spend so much each user forces on obtaining technical information, which only need a router of backbone? (It I about file encap.txt and his updating through a variety of extraordinary ways.)
Replyed by Marius, too
73, gus i0ojj
-
Gustavo Ponza -
Marius Petrescu -
marius＠yo2loj.ro
-
Richard RU3DSH -
Tom Hayward