Is there a simple way to suspend routing from mirrorshades to my segments?
Without putting an invalid IP (BAD), or canceling the allocation, I don't
see a simple option. I am currently doing a network upgrade and will looe
AMPRNet support for a while. Obviously, I can just leave it as is and the
host machines will just ignore the traffic.
Thanks,
Assi
> I don't think git or subversion existed back then
According to Wikipedia, SCCS was developed in 1972 and RCS in 1982.
However, in those days most of us could not afford a Unix machine.
It was only end 1992 when I built a system running Linux and all of this
became much easier. I became coordinator in 1996, and my predecessor
PA0GRI had used Unix at home much earlier than me.
(I think he had a Unix system on packet radio in 1988 or so)
He developed the scripts used to send update mails to the robot, which I
continue to use. These just save a copy of the mails sent to the robot.
That is about 5MB now. Does not seem much, but there have been times this
was most of the harddisk capacity of a computer... :-)
Rob
Is there any history maintained of the address assignments? I've been
thinking it would be interesting if I could pick up the date of my
first use back around 1990 in Colorado.
73
Bill, WA7NWP
All,
ASNs 64,512 to 65,534 of the original 16-bit AS range, and 4,200,000,000
to 4,294,967,294 of the 32-bit range are commonly used amongst persons
on the same network to coordinate routing, etc.
While, it's not yet feasible, there is much research into technologies
(e.g. space elevators), willingness of sponsors for
satellites/availability/etc., and availability of machines, embedded
devices, network cards, etc. tinkering into consumer-grade hardware
capable of multi homing and routing. Also, lets recall, some of our
operators have access to carrier-grade devices as well.
Considerations:
- those on BGP'd islands of the Public Internet (announcing their
allocations with LOAs/Public ASNs,etc.) would still be so (this is no
different than stations with allocations that use their allocations in a
manner that would not route back to AMPR anyway), they must be
considered as those taking allocations to use without AMPR connection,
but there are more options for current and future connectivity with BGP
- RIP44 can still remain in use. In addition, there are multiple methods
to remove your own routes and those of others. You simply remove the
route of those you peer with, change metrics, etc.
- My router (and, I would assume those of many others that have been
flashed, etc.) are capable of forwarding packets, regardless of
source/destination IP. We could test the possibility of switching from a
star (reliance on AMPRGW's 100% uptime for 'real-time' route updates) to
a mesh, where we peer with those who choose, have a large connection,
are physically interconnected to one another, etc.
- (in the future) anyone, including those on the Public Internet, could
volunteer to announce more specific routes for IPIP allocations (with
the proper authorization requested by the allocation holder) and then
maintain a tunnel, RF link, etc. - could connect to someone who could
provide the AMPRGW.
- there is a movement in many areas to establish HSMM in many regions of
the world, but there have been many hindrances to their ability to a.)
interconnect beyond their island-of-connectivity and 2.) not rely on the
same factor/conditions that could cause a loss of commodity Internet
connectivity in order to reach other subnets
- in these considerations, AMPRNet's 100% reliance on AMPRGW and not
devising methods not to rely on the commodity Internet for Islands of
interconnectivity could cause issues in a real emergency scenario
Goal:
- to attempt to alleviate load/reliance on AMPRGW
- provide redundancy
- test the possibility to geographical alternatives to AMPRGW
- consider test the need of issuance of private ASN space for these purposes
TEST:
I'm looking for anyone currently using IPIP only that's GEOGRAPHICALLY
CLOSER (I am connected to the Internet through Verizon via
Ashburn/Wash.DC) to me than AMPRGR, AND/OR a BGP's station willing to
coordinate establishment of a point-to-point VPN tunnel, over which we
will announce our own allocations and/or those in the AMPR test subnet.
I am willing to assist with documentation, graphing etc.
To-do:
- Establish sessions
- setup test hosts
- test multihoming, availability, etc.
- test route prioritization, etc.
- lastly, test (with permission) loss of a stations default route via
tunl0 and using the other session
- test with stations who may be located physically nearby (fiber, RF, etc.)
***Please let me know your thoughts, opinions, etc.***
73,
- Lynwood
KB3VWG
> Subject:
> Re: [44net] IP assignment history
> From:
> Jay Nugent <jjn(a)nuge.com>
> Date:
> 03/27/2016 08:49 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Greetings,
> I have ALL of my IP Address/Hostname requests (with all contact information for those end users) going back to at least March of 1998 and probably even YEARS further back than that (saved on a different hard disk), from when I was the AMPRnet IP
> Address Coordinator for 44.102/16 in the state of Michigan.
>
> I also have a copy of each and every ENCAP.TXT file saved from the 1st of the every month, also going back to at least March 1998 and probably for years further back that that.
>
> Doesn't *EVERY* IP Coordinator have good archival records of their activities, and that of their 'customers' for which they serve? Just poking a little fun here... :)
I have copies of the mails sent to the DNS robot since January 1994 and also copies of most of the requests received from the users.
Unfortunately I have not kept an easily accessible list of contact information. It would be possible to construct it from the request
mails, but it would be a lot of work.
I'm a bit surprised that the processed robot mails are not saved, but maybe now they are...
(disk space has become much cheaper than it was back then)
Rob
> I tend to agree that currently when i now go to any Israeli commercial site from the 44 net ip the packet travel to UCSD and then back to UCSD and by tunnel to me again and this is a long trip
> 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
To solve this you need to talk to people at an ISP who want to announce the 44.138.0.0/16 block on internet
on their routers just like they do for the address block you use at home, then forward the traffic on that
block to your internet router. Similarly you forward the outgoing traffic to internet via their router.
When you have found an ISP who would be prepared to do that, at a cost you can afford, then you write a
letter to Brian asking for permission to do that and then you tell them to set it all up.
(NOT BEFORE YOU HAVE THE PERMISSION FROM Brian!)
Your own router then receives all traffic for that address block directly from internet and you can route
parts of it to others via radio, VPN, or whatever you like.
Please note you will have a constant traffic of several Mbit/s from only the bad guys that are
portscanning and the reflection from the bad guys using your addresses as spoofed source address, and
this is increasing all the time.
So don't do this from your home, put your router in a datacenter where you have 100 Mbit/s or more.
We have done this here for the 44.137.0.0/16 network and there are other places where this is done.
I can ping google from a 44-address and have reply times under 10ms.
This also enables us to run repeaters with echolink, DMR, D-Star etc etc on 44-net addresses.
Rob
> Perhaps consider ways that RIP44 could be updated:
> - to bootstrap one another in the case of a failure of AMPRGW (election
> of a master to send RIP44 announcements, participation in elections
> disabled by default)
> - allow possibility for addition of routes while 'acting AMPRGW' is
> offline (re-elections with time-stamping/flagging)?
> - ability to resume normal operations (AMPRGW is automatically
> elected/flagged/timestamps-recognized as master/signals send end of
> elections)
> Ideas?
This is all completely unnecessary.
The only thing you need to do to have redundancy in the RIP announcements
is setup another RIP announcer that gets the same database information and
sends the same announcements.
Currently they are sent at 5 minute intervals, an efficient solution would
be to modify the existing announce to use 10 minute intervals and setup a
second one to use 10 minute intervals with a 5 minute offset from the first.
When both are up, the users see no change. When one is down, the update
interval halves but everything remains running.
Rob
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