No Ronen, I don't think a UPS is worth having. If there was one there already, I'd ask to be plugged into it, but because rack space is a premium in that data center, we really can't have our own.

And we really don't have power problems here in San Diego. I can't remember the last time we had a power failure here at UCSD. I'm sure it was a few years ago. System uptimes in excess of a year are common.

Thanks for asking. - Brian

On Thu, May 25, 2017 at 10:50:02AM +0000, R P wrote:

Do you want or think it will be good if you will have a UPS ? Will you be able to place there a UPS for us ? If answer are Yes maybe we all donate money for UPS .... you just give us what to buy or how much to donate

The current version of the encap file shows a route to 44.128.0.0/16 via the new amprgw address of 169.228.34.84:

route addprivate 44.128/16 encap 169.228.34.84

RIP should already be advertising it. I don't believe this will cause any problems.

Your gateways and firewalls can start learning it, and I can use it to debug the new installation. What we'll do is change the routing at the UCSD border to direct traffic for that one /16 subnet to the new amprgw instead of the old one right away, and after everything appears to be working properly, we'll change the route for the entire 44.0.0.0/8. Both systems already have a secondary address of 44.0.0.1, so that changeover will be automatic.

Of course, the people announcing their own subnets via BGP won't be affected by this change. - Brian

On Thu, May 25, 2017 at 08:45:58AM -0400, lleachii--- via 44Net wrote:

At that time, can we seed a dummy /32 address with a route to the NEW_AMPRGW

• from the AMPR Test Subnet or from 44.0.0.0/24?

This will allow the new address to enter our tables, especially for those running dynamic firewalls against the Encap list - since it's TBD if the router/GW will move last, or sometime before the completed migration.

So..basically on that day, something like:

• Brian changes GWs at the TBD time
• We all change our default route (if in use)
• the route to 44.0.0.1 changes
• the dummy route is removed

I have a concern that many gateway operators won't get the notification that the amprgw gateway is changing address. If you know someone who operates a gateway and DOESN'T subscribe to this mailing list, please let them know about the upcoming change.

And it would be really cool if someone could browse the wiki and update the information on amprgw. I'm afraid that its address may be hardcoded in some of the 'how-to' pages. - Brian

On Fri, May 26, 2017 at 11:28:51AM -0700, Brian Kantor wrote:

I've installed the routing software on the new amprgw machine and tested it, and it's working properly. In anticipation of moving the inbound route for 44/8 from the old amprgw to the new one, it is time for people to start using the AMPRGW.UCSD.EDU (169.228.34.84) address for their outgoing tunnel endpoint.

That will require people who have a firewall to adjust their firewall rules and any default routes they're using.

However, it is still necessary to allow the old amprgw.SYSNET.ucsd.edu (169.228.66.251) in past your firewalls, as up until the moment that we switch the 44/8 route from old to new, inbound traffic from the Internet will still be coming from that old address.

Please make the change and test it as soon as practical so that you don't get caught by the switch. Be sure to let me know if you lose connectivity when you switch over to using the new machine for outbound traffic, and we'll try to figure out what went wrong.

I anticipate a week or so before we can make the switch, so please keep it in mind.

Thank you!

• Brian

Excellent. Thank you. - Brian

On Fri, May 26, 2017 at 04:14:24PM -0400, lleachii--- via 44Net wrote:

Working on the Wiki.

• KB3VWG

Sorry, no.

I don't have any way to set up anycasting without requesting some changes from the campus infrastructure folks that I'm hesitant to ask for, especially as they'd be short term only.

As for long-term, the old server will be repurposed as soon as we're through with it, so it won't be around to participate. (In a sense, we're lucky we've had it as long as we have.) - Brian

On Fri, May 26, 2017 at 01:23:29PM -0700, Tom Hayward wrote:

Can you anycast the old address from the new server so there's no "cutoff" during the transition?

Hey Brian,

What about configuring an ICMP direct on the old IP to point to the new IP?

--David KI6ZHD

On 05/26/2017 02:03 PM, Brian Kantor wrote:

(Please trim inclusions from previous messages) _______________________________________________ What I can do is leave the old server up at its old address and have it continue forwarding packets that are still sent to it from people who didn't get the word, and contact them to get them to update before I have to shut down the old machine. We'll send their inbound traffic to them from the new machine, but it's anybody's guess if they'll get it because of firewalling.

I really can't do anything about the outbound addresses being different though, since the two machines are on distinctly different subnets and I can't change the campus backbone. I've already had to hassle the campus networking folks to get the RPF disabled, and I really don't like to bother them.

• Brian

Brian,

Nope...that shouldn't be blocked.

I need to read up...I believe what I understood David to ask is: if someone continues to send IPENCAP packets to Old_AMPRGW, configure it to send an ICMP Redirect in the future.

This should WORK, since the device sent the packet. I'm not sure what an OS will do, though; or if the OS is handling the packet as normal (i.e. some raw modes).

This is not considering a scenario if the OP EXPLICITLY blocks ICMP (which in that case, it would fail anyway). My configuration should have received the ICMP Type 5 (I believe 5.1) packet in return for the IPENCAP I sent to Old_AMPRGW, I just don't know how LEDE would respond.

- KB3VWG

Don't most hosts and routers ignore ICMP Redirects out of security concerns these days?

Yes, but only AFTER the change, since the RIP broadcasts and the incoming internet connections are still via the old gateway.

(It could be fixed to work in the current config, but the change is quite big, and will have to be undone after the new config is working)

On 27.05.2017 00:11, R P wrote:

(Please trim inclusions from previous messages) _______________________________________________ What do i need to do in my MikroTik ?

Just to change the Destination of the tunnel ?

---

From: 44Net 44net-bounces+ronenp=hotmail.com@hamradio.ucsd.edu on behalf of Brian Kantor Brian@UCSD.Edu Sent: Friday, May 26, 2017 11:28 AM To: 44net@hamradio.ucsd.edu Subject: Re: [44net] Good News! and some changes coming

(Please trim inclusions from previous messages) _______________________________________________ I've installed the routing software on the new amprgw machine and tested it, and it's working properly. In anticipation of moving the inbound route for 44/8 from the old amprgw to the new one, it is time for people to start using the AMPRGW.UCSD.EDU (169.228.34.84) address for their outgoing tunnel endpoint.

The statistics are still being served from the old gateway system. - Brian

On Fri, May 26, 2017 at 09:44:04PM +0000, R P wrote:

Brian what about the statistics ? where are they taken now from ?

No issues with turning them on as long as the RIP content is the same...

For the mikrotiks and possible others using individual tunnels , they can be switched only if you DO turn on the new sender, since they have defined tunnel endpoints and do not "cross-listen" for RIP.

Amprd was designed from the beginning to update its default route according to the gateway of 44.0.0.1 automatically, so it will expect a 44.0.0.1 via 169.228.34.84 and use the new one without any intervention.

I assumed this could happen some day so there is no hard coded reference for the gateway IP in any of the tools.

Sorry for the late response.

Marius, YO2LOJ

On 27.05.2017 01:24, Brian Kantor wrote:

(Please trim inclusions from previous messages) _______________________________________________ I can turn on the RIP sender in the new gateway any time, but I don't know about the wisdom of having both sending at the same time, even though they'll send the same content. Marius, what do you think?

• Brian

On Sat, May 27, 2017 at 12:29:46AM +0300, Marius Petrescu wrote:

...

Yes, but only AFTER the change, since the RIP broadcasts and the incoming internet connections are still via the old gateway.

---

44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

Brian,

If you haven't consider this...make sure that the cron jobs aren't configured to execute on both machines at the same time. I'm not sure how you configured the intervals, but if you're able to set them 60-180 seconds apart, that should work.

My machine (and others that receive IPENCAP from ANY) may exhibit odd behavior if receiving duplicate routes...especially while the RIP44 daemon is executing the routes.

This also make me think about the ICMP Redirect thing...how bout changing the password to the routes on Old_AMPRGW, that will be a first phase-out for OPs running RIP44, as they should observe they can't send traffic to us any longer. After that, the only remaining OPs on Old_AMPRGW would be those who use the Munge Script method. At some point, you will turn off Old_AMPRGW anyway, something should have been noticed by that point in time.

- Lynwood KB3VWG

No issues with turning them on as long as the RIP content is the same...

On 27/05/2017 11:11 PM, Brian Kantor wrote:

(Please trim inclusions from previous messages) _______________________________________________ The only things that might collide on users systems are the RIP transmissions, and I already have them separated in time by three seconds, that's three times the length of the transmission.

I'm in the process of sending an email to the registered email address of every single gateway registered with the portal which will tell them about the changes coming. I feel that this is necessary because a lot of them don't subscribe to the 44net mailing list, despite my strong recommendation that they do so.

We'll see how many complaints I get.

That would be helpful. I have been (mostly) following the discussions here, but because things tend to get a bit fragmented on the mailing list as details come out over time it is difficult for me to follow. Having it all in one email will definitely help, then I can sit down and make all the necessary changes.