Good News! Our friends in the CAIDA research group at UCSD have come up
with a new machine for amprgw, quite a bit newer than the existing one,
and with faster CPU, more cores, and more memory. It also has RAIDed
disk and dual power supplies, although unlike the current amprgw, it
won't be on a UPS.
(There isn't a UPS in the new building where the new machine is located.
Luckily our power is pretty reliable; besides buying utility power,
UCSD also generates its own from solar and natural gas sources. And we
don't have lightning storms very often here in the almost-desert.)
There will be some minor differences between the machines, of course,
although small enough that I hope to move all the services over from
the old machine to the new one over the next several weeks.
The primary difference is that the gateway will have a NEW ADDRESS
and a slighly DIFFERENT NAME. Instead of being known as
'AMPRGW.SYSNET.UCSD.EDU' as the current one on address 169.228.66.251
is known, the new machine will be 'AMPRGW.UCSD.EDU' (no 'sysnet' in the
name), and will be on address 169.228.34.84. You should probably adjust
your firewalls soon, letting both machines in for a while, as they will
both be operating at the same time as services are moved from old to
new. Do not move your tunnel endpoints to the new machine quite yet;
that won't work until the routing software is installed and reconfigured
for the new address. I'll let you know what it's ready for that.
- Brian
I can find where the new amprgw info is documented.
Shouldn't the old/new hostname, external IP address and cut-over date appear
prominently somewhere?
Michael
N6MEF
> Yes, it's on the same box, but because the two boxes are on physically
> different networks, I can configure them both to be 44.0.0.1 without
> conflict. One of them won't get any packets except those originating
> on its own physical network, but they won't conflict. That's what I've
> done; when the 44/8 route next hop is moved from old amprgw to new amprgw,
> which machine serves 44.0.0.1 to the outside will automatically change.
I think when you announce 44.0.0.1 with the new gw address on the gateways
list (encap, RIP) and keep the 44.0.0.0/8 BGP pointed to the old box, users
with a tunnel will connect to the new box and those connecting from internet
will get the old box, without any conflict or need to re-route things inside
the campus network. That makes it possible to test tunnels two-way.
But it is not that important, it will probably work right away and obvious
mistakes will be found and fixed within one or some days, which is good enough.
I have been doing quite some rebuilding lately, short downtimes sometimes
are unavoidable when working within hobby constraints.
Rob
Yes, thanks.M
Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------From: Brian Kantor <Brian(a)UCSD.Edu> Date: 5/26/17 18:31 (GMT-08:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] documentation of gateway move
(Please trim inclusions from previous messages)
_______________________________________________
I assume you meant "can't".
Updates to the wiki are in progress.
I think there ought to be an 'amprgw' page on the wiki, but there
isn't one yet. I'll try to get to writing one soon.
- Brian
old address: 169.228.66.251
old hostname: amprgw.sysnet.ucsd.edu
New address: 169.228.34.84
New hostname: AMPRGW.UCSD.EDU
Cutover date: TBD
On Fri, May 26, 2017 at 06:20:34PM -0700, Michael Fox - N6MEF wrote:
> I can find where the new amprgw info is documented.
> Shouldn't the old/new hostname, external IP address and cut-over date appear
> prominently somewhere?
> Michael
> N6MEF
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
> I've already tested the 44.0.0.1 address using loopback and it
> works ok, and I've tested inbound using 44.128.0.1, and it
> works ok too. I think things will be ok.
> I don't like to bother the campus networking people more than I have to.
Ah, I thought that 44.0.0.1 was running on the same machine as amprgw and
would be moved as well... so that ciould be done before. Apparently it is
a different box.
Rob
> Don't most hosts and routers ignore ICMP Redirects
> out of security concerns these days?
Certainly for such external addresses. Locally on the LAN it usually works.
(e.g. when you have two routers and one sends redirects to the address of the other,
both in the local subnet)
Rob
> - brought back option -r, to allow using multicast sockets by default
> and raw sockets as a backup for systems with multicast issues. This will
> hopefully sort out the firewall filtering inability on previous releases
> since 1.13.
I had to put back the -r option that I had cleaned up from my start script
as it still does not work with the multicast socked on Debian Linux with
kernel 3.16. I remember it failed after some kernel update and it apparenty is
still broken. However, I do not mind using the -r option, only want to
remind people that they may need to put it back.
Rob
We do not send outgoing traffic via amprgw so no change is necessary, but I updated
the address on our info page (that says "use our address instead of 169.228.66.251 as your default gw").
It would probably be a good idea to change the route for 44.0.0.1 before the incoming routes
are switched over, so it can be tested from the inside.
Rob
All,
It's my understanding that there are multiple copies of the original
Startampr script on the Internet. What I have not noticed until alerted
by two operators that attempted to implement those copies in their
devices, are the following:
- Scripts NOT distributed from my site at http://44.60.44.10 ON AMPRNET
include the misuse of the -a argument to run the RIP44 daemon(s).
- The syntax used on the Internet scripts ('use -a argument to remove
your allocation from the table' by a. specifying WAN IP IN rip44d; vs
b. specifying 44 allocation CIDR IP as in ampr-ripd, are reversed.
- This appears to be a documentation bug made by a copier who used my
original scripts (made for rip44d) and converted them to work for ampr-ripd.
- if you use my scripts placing lookups for your local 44 LAN in the
main table, this issue wouldn't affect you
73,
-Lynwood
KB3VWG
> >/Everyone is free to use the -g option if needed /> Yes, but is eth0.2 a valid entry?
The parameter of -g is an IP address. It it not the IP address of an interface but of the gateway to the internet.
So specifying an interface like eth0.2 does not make sense.
You could use something like this:
.... -g `ip route list | grep '^default' | sed -e 's/.*via //' -e 's/ .*//'`
Rob
