There is a mechanism, it's the point to point tunnels. Most gateways
support that.
The routing table is designed to match for point to point gateways before
going to the default AMPR gateway at UCSD.
>From a configuration perspective, the easy configuration approach is to
first route everything through UCSD to make sure one has mastered local
gateway tunneling configuration. Then the local configuration should be
expanded to perform direct tunneling to AMPR hosts/gateways and the UCSD
gateway should be the lowest priority route.
Assi
-----Original Message-----
From: 44Net [mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On
Behalf Of R P
Sent: Saturday, March 26, 2016 9:18 AM
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] Testers/Consideration/Inquiry - Coordinating the
Private AS Numbers
(Please trim inclusions from previous messages)
_______________________________________________
..snip...
If there was a mechanism to allow the traffic to go to any local 44
gateway and then the packet will go to the local Internet the trip
would be much shorter
but i dont know how it can be done these days that every IPS block Source
44 Net address from passing through as for 44 net to 44 net trafic it look
ok because it tunnel direct to the gateway and not passing through AMPRGW
the only thing I can think off is to put a secondary portal for
redundancy .
Ronen - 4Z4ZQ
http://www.ronen.org
> - I'm not certain how one can reach portal.ampr.org before establishing
> an Internet connection first
Of course portal.ampr.org should be run on a net-44 address and preferably
have radio connectivity, but for reasons unknown to me it isn't. As the
worldwide AMPRnet over radio is just a dream, it would not be likely that
everyone would be able to reach that system without internet any day.
You would need internet anyway to search and visit a webshop to buy the
equipment you need to be on radio...
> - You stated: "This is not a task of AMPRGR but of portal.ampr.org..."
> The Portal is simply a backend to configure AMPRGW itself; and
> specifically in the case of IPIP tunnels using RIP44. In the future it
> plans to add DNS functionality, but keep in mind, this is just merely a
> website
I am bringing this up only because I get the feeling that you don't understand
the topology of the network and the components involved very well.
The title of your initial message is also very indicative of that. What you
brought up has zero to do with AS numbers and the issue of coordinating AS
numbers was already handled to everyone's satisfaction a couple of months ago.
> - I'm not sure how a DNS zone file relates to real-time connectivity to
> a network
Not to the connectivity directly, but certainly to the usability.
It appears that one of your goals is to use AMPRnet without internet connection
and that is not really practical when you don't have a DNS on it. There is
a DNS server 44.0.0.1 but for most people it will be unreachable when they
don't have some internet tunnel.
> - AMPRGW is not the ideal route to all subnets because it is not the
> most geographically closest AMPRNet node with an Internet connection. If
> other nodes were setup in the manner I'd like to test, any node willing
> to establish a session could potentially be a closer node
I advise you to study the network topology before proposing to change it.
Traffic to another amprnet node does NOT flow through AMPRGW.
> - You note again "we have a full mesh:" ***Then please test by pinging
> MY gateway VIA N1URO's***. In your testing, do not connect directly to
> me or use AMPRGW. I will DOWN my tunl0 interface and only connect to
> another AMPR station with AMPRGW connectivity - via RF or over a VPN
> connection.
> + it's my understanding this would fail - STAR
> + you imply that it should work - MESH
This is not what defines a star versus a mesh. When you disconnect yourself
from the mesh and do not update the routing to be reachable via someone else's
connection, of course you will be unreachable. What makes it a mesh is that
the reliance on AMPRGW that you bring forward all the time IS NOT THERE.
The pings I send to your gateway directly travel from my internet connection
to yours, NOT via AMPRGW.
We use a multi-level subnet system here. We route the entire country
subnet to a single gateway which has radio and VPN connectivity to users in the
country. Those users can also have their own IPIP gateway when they like.
In that case the traffic for their subnet will flow directly to them, but when
they stop that the traffic will go to our gateway and then to them via radio.
Of course there is no "alive" detection in the current IPIP gateway system,
so a route will not disappear from the announcements just because the internet
connection of that gateway is broken. So you will have to disable the gateway
first (functionality that has been removed from the portal.ampr.org system
for reasons totally unclear to me, you now just have to delete the subnets)
Rob
Hi,
Many years ago we used as main application the terminal to the connections of
the BBS
Currently we use modern solutions in hamradio network such as WIFI and main
application which we use is web browser to see many WWW pages
On our club www page we have small collections urls to others
http://sp2pmk.ampr.org
but it is not good solution
In Europe we have a system with a database of web sites, search engines based
on yacy:
http://search.db0sda.ampr.org/http://web.oe2xzr.ampr.at/http://44.134.190.114/lsp_map.cgi
etc
How to find others www pages outside Europe for examaple in US or others
places
Anybody know or exist similar solution in US ?
It will be fine to travel via 44/8 network and see and read other www
hamradio pages individual or club station. Sometimes we can find on
hamradio amprnet/hamnet www pages interesting information or solution.
--
Waldek sp2ong
There isn't a whole lot of entries in the wiki services list. I am
not sure how many net 44 users are on this list and or know about
that. I personally find wiki markup coding a pain as its not native
to me. Another thing is maybe some people would rather share service
details after a portal login rather than somewhere that gets scraped
by google.
To me it sort of make sense to briefly explain what your doing in the
network allocation area and/or gateway areas of the portal.
In my quest, one thing that caught my eye was this Michigan repeater
linking/microwave project. Mostly because they are closer to me in
Wisconsin.
https://w8cmn.net/tiki-index.php?page=Mi6WAN-MAIN
I recall someone on this list no that long ago from overseas was doing
a similar project with Asterisk/app_rpt and 802.11.
Elsewhere (reddit/slashdot) I recently read about the Mid-Atlantic IP
Network ( I think they aren't using 44net though), same type of thing.
I like the idea, and have been looking to try the Asterisk/Allstar
RTCM to add a voted receive site, but transported over a microwave IP
link.
We just did a tower climb today here in Wisconsin and replaced some
damaged 802.11 gear. And had an offer from a broadcast group for some
tower space. I am hoping 2016 is the year things take off a bit
locally.
Steve
Thanks for the info. Looks like the info I need to use it for our purposes.
Some time back there was a resource list that Jim Fuller maintained
that was handy to list what was all out there.
>HiHi
>Not the whole one, for shure.
>Just your "local area" and then report to the yacy network.
>
>Have a look here after google translated it for you ;-)
>http://www.amateurfunk-wiki.de/index.php/Suchmaschine
>
>73
>2MIC
No, and I'll admit that. That is why I'd like to hear more about how
to configure yacy.
But since there isn't a search engine or otherwise way yet to get an
idea what is on the amprnet and what people are doing on the address
space, I couldn't really think of any other way.
The links below will only be active for a short time, as it's really
only meant for 44net folks to get an idea.
Steve
>> http://kb9mwr.ampr.org/public/nmap/030516routed.txt
>> http://kb9mwr.ampr.org/public/nmap/030516nmap.txt
>
>> I am not to familiar with it, how do it get it to crawl the amprnet?
>
>Is this wise?
>- Brian
I don't understand your consideration of "moving from a star to a mesh".
We ALREADY have a mesh! There is no load to be removed from AMPRGW other
than the routing from/to internet for those that are not directly BGP routed on internet.
When you want a solution for the "single point of failure" for RIP announcements, the
simple solution would be to deploy a second RIP annoucer elsewhere, that sends the
same information as AMPRGW, and takes over when AMPRGW does not send those
announcements. Of course it still needs to be fed with the same topology information,
so it could be tricky to get a solution that does not have any single point of failure, but
your solution of doing BGP over tunnels instead has such information embedded in
the static configuration of all the peers, which is even more difficult to manage.
So it is not really clear to me what such a change really would achieve what we do
not already have.
What is the status of usage of AMPRnet addresses in HSMM? In the past they used
RFC1918 addresses that were automatically allocated. I believe newer versions can
use static addresses that could als well be from NET-44. Is this already in wide use?
Rob
> a.) then how would a new or offline IPIP station connect if AMPRGW were DOWN at the time?
This is not a task of AMPRGR but of portal.ampr.org
> b.) then how do I get routes from AMPRNet without a DIRECT CONNECTION tunl0 connection to AMPRGW?
As I wrote is is possible to deploy a second system that does the RIP announcements
> c.) what if I can directly reach 2 or more AMPR subnets (but not the Internet)?
We already have a large network of radiolinks running here in Europe, and I think also in some
other areas of the world. It does not rely much on the internet, except for DNS. I download
the ampr.org DNS zonefile daily so I have it available when we are offline.
> a.) AMPRGW is currently the only route announcer (but you address that elsewhere)
I think it is important because it is the only weak spot I can see.
> b.) Next, it's not the ideal route to all subnets
Why not?
> c.) this solution addresses the possibility of redundancy to other subnets, as well as AMPRGW
I don't understand. There already is full redundancy. We have a full mesh.
> In planning, it would probably be an alternative to IPIP, and not a replacement. Ideally, there could be a few regional gateways, other stations connecting to one or more regional gateway and to other end-user gateways.
That is how we run the network here. What is your proposed change?
Rob