1 Sep
2015
1 Sep
'15
12:39 a.m.
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.
--
73! Yours faithfully,
Rihard RU3DSH.
1 Sep
1 Sep
8:32 a.m.
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
11:20 p.m.
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.
--
73! Yours faithfully,
Rihard RU3DSH.
2 Sep
2 Sep
7 a.m.
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
5:21 p.m.
02.09.15 9:00, Gustavo Ponza wrote:
that was the 'stone age' :)
You may refer to the docs on Maiko site:
http://www.langelaar.net/projects/jnos2/documents/
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.
5:38 p.m.
On Wed, Sep 2, 2015 at 9:21 AM, Richard RU3DSH <ru3dsh(a)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
5:50 p.m.
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
3 Sep
3 Sep
9:16 a.m.
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
8:49 a.m.
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
3167
days inactive
3170
days old
8 comments
5 participants
participants (5)
-
Gustavo Ponza -
Marius Petrescu -
marius＠yo2loj.ro
-
Richard RU3DSH -
Tom Hayward